<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:10.0pt;
font-family:"Aptos",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-GB" link="#467886" vlink="#96607D" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">Wow!!
</span><span style="font-size:11.0pt;font-family:"Apple Color Emoji";mso-fareast-language:EN-US">😳</span><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">Lots of midnight oil in there Michael. Well done all involved – this looks like an exciting move forward!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">Kind regards<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">Colin<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt">
<b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Blueonyx <blueonyx-bounces@mail.blueonyx.it> on behalf of Michael Stauber via Blueonyx <blueonyx@mail.blueonyx.it><br>
<b>Date: </b>Sunday, 9 June 2024 at 09:47<br>
<b>To: </b>BlueOnyx General Mailing List <blueonyx@mail.blueonyx.it><br>
<b>Subject: </b>[BlueOnyx:27020] Upcoming BlueOnyx 5211R changes<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt">Hi all,<br>
<br>
The last couple of weeks the code for BlueOnyx 5211R has seen some <br>
massive changes which we are about to release in the next week or two.<br>
<br>
They will first hit the [BlueOnyx-5211R-Testing] YUM repository and <br>
after further tests they will appear in the regular 5211R YUM repository.<br>
<br>
<br>
List of changes:<br>
================<br>
<br>
Sauce::Service notification light:<br>
-----------------------------------<br>
<br>
After saving in the changes it can take small moment until the changes <br>
are applied and all relevant services have been restarted. So far the <br>
GUI didn't give any indication if the changes were now applied or if <br>
something was still working on that in the background.<br>
<br>
This has now been addressed. See the attached image. In the upper right <br>
corner a spinning circle of dots will appear when GUI triggered Network <br>
service changes are pending and are being processed. A help text will <br>
also appear and indicate which services are currently awaiting their <br>
restart.<br>
<br>
This spinning circle and the helptext will turn invisible again once the <br>
pending transactions are completed.<br>
<br>
<br>
Network configuration changes:<br>
-------------------------------<br>
<br>
The network configuration of BlueOnyx has always consisted of a set of <br>
legacy scripts that go back to the Cobalt days. Back then (from a Linux <br>
administrators perspective) you had to configure the network "on foot". <br>
Like write various "ifcfg" config files, configure the routes yourself, <br>
deal with NAT and what not.<br>
<br>
These days? NetworkManager actually does it all - if you let it.<br>
<br>
Over the years we have modified our scripts extensively and also made <br>
them somewhat NetworkManager conforming. But not quite due to a lot of <br>
legacy baggage.<br>
<br>
Therefore the "network stack" of BlueOnyx 5211R has now seen a complete <br>
rewrite that properly uses NetworkManager and "nmcli" to configure the <br>
network.<br>
<br>
The old eth0:X network aliases for each secondary IP? They're gone. All <br>
IPs are now bound to the primary network interface directly.<br>
<br>
The /etc/syconfig/network-scripts/ifcfg-eth* files? They're gone now as <br>
well. The network configuration is instead persistently stored in <br>
NetworkManager.<br>
<br>
Or better said: The network Constructors and Handlers of BlueOnyx will <br>
now poll CODB for what the network configuration *should* be. And then <br>
they will then use "nmcli" to apply these settings to NetworkManager.<br>
<br>
These scripts are even so clever that they don't blindly apply the <br>
configuration every time. Instead they compare what the configuration <br>
*should* be (according to CODB) and compare it with the currently active <br>
network configuration. If there are discrepancies? Then *only* the <br>
network interfaces with the pending changes are updated. Which cuts down <br>
on the amount of network restarts required.<br>
<br>
<br>
/root/network_settings.sh:<br>
---------------------------<br>
<br>
The BlueOnyx 5211R network settings configuration script now also uses <br>
"nmcli" conforming methods to apply the network settings.<br>
<br>
But beyond that it now also gives you three choices for which kind of <br>
network configuration you can set up:<br>
<br>
1 Traditional eth0 primary interface (default)<br>
2 Bridged br0 network (for Incus Containers)<br>
3 DHCP<br>
<br>
The first options is the same as your network on BlueOnyx always has <br>
been. So no surprises there.<br>
<br>
The second option sets up a bridged network interface called 'br0' and <br>
it will assign the primary network interface to it as 'slave'. All IPs <br>
get bound to 'br0'.<br>
<br>
Like the text says: This option is only relevant if you want to use your <br>
BlueOnyx to run Incus Containers. More on that further down.<br>
<br>
The third option is DHCP. BlueOnyx has supported DHCP for a couple of <br>
years now, but it wasn't advertised, transparent or thoroughly integrated.<br>
<br>
The way this works now is this: You *can* set up your BlueOnyx to use <br>
DHCP. If there is a DHCP server in the same network, then your BlueOnyx <br>
ought to receive one IPv4 and/or IPv6 IP address from it. Alongside with <br>
the DNS it is supposed to use as resolver.<br>
<br>
These single DHCP obtained IPv4 and/or IPv6 IPs will be the only IPs <br>
that you can use to create Vsites. Should the DHCP server assign you <br>
different IPs in the future? Then the Vsites will automatically switch <br>
to the new IPs.<br>
<br>
For the most part this feature will be of no practical interest to most <br>
of you. But some who want to run BlueOnyx in certain clouds might <br>
appreciate the new ease of use and thorough integration.<br>
<br>
Reconfiguration of the network settings from "traditional eth0" to 'br0' <br>
over to DHCP and back is always possible via /root/network_settings.sh.<br>
<br>
DHCP *and* bridged network cannot be used together, though. It wouldn't <br>
serve any practical purpose either. After all: A bridge is intended to <br>
be used by more than a single DHCP obtained IP.<br>
<br>
<br>
Network device names (ethX):<br>
-----------------------------<br>
<br>
BlueOnyx had "old style" ethX network devices hardcoded in the network <br>
scripts and even some of the GUI pages. Therefore it couldn't cope with <br>
"en[p|s|o]"-style network interfaces. For that reason the ISO installer <br>
and installation scripts always modified the Grub boot configuration to <br>
force the server back to use ethX style interface names.<br>
<br>
This is no longer necessary, as the new network scripts can deal with <br>
those eventualities. We now even cover 'wlan', 'waan', 'bond' and 'veth'.<br>
<br>
<br>
Disk Quota:<br>
------------<br>
<br>
In the past having at least a /home partition WITH enabled user- and <br>
group- disk quota was a *must* *have* for BlueOnyx. Alternatively: If no <br>
dedicated /home partition was present, then disk quota was required to <br>
be enabled for the / partition instead.<br>
<br>
However: Some clouds and/or container based virtualisation solutions <br>
don't offer native file system disk quotas on a per user and per group <br>
level.<br>
<br>
The absence of disk quota meant that BlueOnyx would not be able to <br>
create Vsites OR Users. And even if it could create them: It would be <br>
unable to display disk usage or enforce disk quota limits.<br>
<br>
This has now been addressed as well:<br>
<br>
Disk quota is now optional.<br>
<br>
If it is present and works? Then it will be used like always. But if it <br>
is absent or not working? In that case BlueOnyx will fall back to <br>
alternate methods to accurately (and quickly!) determine the current <br>
disk usage of Vsites and Users.<br>
<br>
But what if a Vsite or User goes over-quota? Then there is nothing that <br>
stops him form consuming more space than allowed? Or even fill up a <br>
whole partition by himself?<br>
<br>
Well, not quite. \o/<br>
<br>
We extended the GUI code so that upon reaching the disk quota limits <br>
features of Users and Vsites will be deactivated automatically:<br>
<br>
- An over-quota User can no longer receive emails. They will bounce with<br>
the error message "ERROR:5.2.2:550 User is over quota"<br>
<br>
- An over-quota User can no longer use FTP to create or append files.<br>
All he can do (if he has FTP enabled) is to login and delete files.<br>
<br>
- If a Vsite itself goes over-quota? All emails will bounce. FTP gets<br>
'write' access removed and PHP will be reconfigured so that creation<br>
of files via PHP will be prohibited.<br>
<br>
This doesn't affect Perl scripts, so they could still be used to create <br>
files or do stuff that lets the disk usage grow further. However: Web <br>
facing Perl scripts are getting so rare these days that we can perhaps <br>
ignore this for now. Optionally one might want to turn Perl scripts off <br>
if disk quota is not available.<br>
<br>
<br>
Aventurin{e} 6110R / Incus:<br>
===========================<br>
<br>
Above I said I'd mention Incus again and here we are.<br>
<br>
The OpenVZ 7 based Aventurin{e} 6109R is in need of a successor and that <br>
will be Aventurin{e} 6110R. HOWEVER: This will NOT be shipped as a <br>
separate ISO image.<br>
<br>
Instead: Aventurin{e} 6110R will be a PKG that can be installed onto a <br>
BlueOnyx 5211R.<br>
<br>
That BlueOnyx 5211R then needs to be configured to use bridged network <br>
(i.e.: 'br0' will be the primary interface). Then you can use a special <br>
menu in the BlueOnyx 5211R GUI (included in the PKG) to create and <br>
manage Linux containers.<br>
<br>
You can still run Vsites on such a BlueOnyx, but generally and for <br>
security reasons we would discourage that.<br>
<br>
Incus is a fork of the LXD project and it provides the ability to create <br>
and manage Linux Containers. It can additionally also run VMs (via <br>
Qemu). Incus itself is rather new, but shares many commonalities with <br>
its predecessor LXD and adds some new and interesting features on top of <br>
that.<br>
<br>
If you're already familiar with LXD or come from Aventurin{e} 6109R or <br>
OpenVZ 7 you should feel right at home with it.<br>
<br>
As is Incus has a very long list of OS templates that cover many Linux <br>
flavors and distributions. All the popular Linux distributions are <br>
present and accounted for in various versions. And (in the close future) <br>
it will also be possible to run VMs with it on an AlmaLinux/RockyLinux 9 <br>
host, but for the moment that isn't an option yet.<br>
<br>
So with an Aventurin{e} 6110R PKG installed on your BlueOnyx 5211R you <br>
will be able to offer Linux Containers running a multitude of possible <br>
Linux OS's in them. Each Container is isolated against any other <br>
Container and has its own IP address and network configuration and <br>
resource limits.<br>
<br>
Even there various network related options will be possible: Static IP <br>
addresses that are available from the outside or static or dynamic IP <br>
addresses that are only reachable from the host node itself. Unless you <br>
configure NAT or Proxy for those.<br>
<br>
That would for example allow to have one dedicated and publicly <br>
reachable Container that does firewalling and routing and the rest of <br>
the Containers are in a private network and only reachable through the <br>
firewall-container.<br>
<br>
Incus has means and methods integrated for cloning, snapshotting, <br>
templating, clustering, migrations as well as for backup and restore of <br>
Containers (and VMs).<br>
<br>
<br>
Migration path OpenVZ 7 or 6109R -> Incus / 6110R:<br>
---------------------------------------------------<br>
<br>
Short answer: Yes. Will be provided.<br>
<br>
We're working on a script (other than Easy-Migrate) that will export <br>
Containers from OpenVZ 7 based nodes and will convert them to Incus CTs.<br>
<br>
Like Easy-Migrate this will most likely work in a "Pull" fashion. So you <br>
start it on the target system and it will use SSH and RSYNC to fetch the <br>
configuration and data. With the gathered information an Incus CTs is <br>
created on the target system and that will be populated with the data <br>
from the source CT.<br>
<br>
<br>
Release date Aventurin{e} 6110R:<br>
---------------------------------<br>
<br>
No promises on that yet. The general idea is to have a wrap of the <br>
initial code base around August and then it will go into testing with <br>
selected sponsors. A general release will then follow after suggestions <br>
and possible additional feature requests have been implemented.<br>
<br>
<br>
BlueOnyx 5210R:<br>
================<br>
<br>
How much of this will be ported to BlueOnyx 5210R?<br>
<br>
Uhm ... not much, sorry.<br>
<br>
The Sauce::Service notification light:<br>
---------------------------------------<br>
<br>
Yes. That will be ported.<br>
<br>
The change that makes disk quota optional:<br>
-------------------------------------------<br>
<br>
Yes. That will be ported.<br>
<br>
<br>
The network related changes?<br>
-----------------------------<br>
<br>
Only partially. Generally speaking: BlueOnyx 5210R has a lot of OpenVZ 7 <br>
related baggage in its network handling routines. And in OpenVZ 7 <br>
containers we don't have NetworkManager. So if 5210R were to receive the <br>
updated network handling code from 5211R, that code would need a hell of <br>
a lot of exceptions to *still* make it work "the old way" in OpenVZ 7 <br>
containers. Therefore we will only release a "light" version that makes <br>
some minimal changes that won't affect the overall network functionality.<br>
<br>
<br>
Incus support?<br>
---------------<br>
<br>
No. The Aventurin{e} 6110R PKG will only be available for BlueOnyx <br>
5211R. The older kernel and libraries on EL8 make this extremely <br>
unlikely and it wouldn't be a good match to begin with.<br>
<br>
<br>
Wrapping up:<br>
============<br>
<br>
Phew ... that was a long message. Thanks for reading this far and I hope <br>
you're also excited about the upcoming changes.<br>
<br>
Let me know if you have any questions.<br>
<br>
-- <br>
With best regards<br>
<br>
Michael Stauber<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>