This forced mechanism comes with great responsibility and dependency on Nethserver infrastructure. I am not really sure I like this enforced replacement of public mirrors of DNF sources and if this is a role Nethesis should play…
I Rather ‘simply see’. specific Nethsesis (commercial) specific repository NEXT to the global mirror infrastructure (Non commercial) of Rocky Linux.
Or am I misreading?
Hi @LayLow
Very simple to solve: Just use Debian as base, and you are no more a playball of RH/IBM.
Who cares about Rocky, Alma or Oracle?
For me, there’s absolutely NO Reason to continue using RHEL based clones anymore!
My 2 cents
Andy
In NS7 it is the same: mirrors are already handled by mirrorlist.nethserver.org
If you look past threads you notice that during CentOS 7 minor releases we got issues, so by time we delivered our safety harness around upstream mirrors.
Nethesis has chosen Rocky as official distro for its customers. I’d say, if one thinks to buy paid support, Rocky Linux becomes a requirement.
As a developer, I prefer Rocky Linux because it delivers new versions of Podman at every minor release (here comes back the need of a safety harness).
I understand there are also many other points to prefer Debian instead, I think they were discussed in another thread.
Fair enough
For NS7 we have upstream repos and mirrors + NethServer’s public repos and mirrors. On top of that, Nethesis customers with paid subscription have tech support and alternative repos with delayed updates -in some way similar to the approach taken by Manjaro vs “pure” Arch Linux- as a means to contain upstream packages bugs and keep OS and server stable (a double-edged sword in case of 0-day vulnerabilities, but fixes could also be pushed to repos by Nethesis security team -if there’s any- without much delay).
With NS8 traditional rpm packages updates are less relevant than they used to be on NS7.
Only a few requirements for NS8: podman, systemd (and firewalld), wireguard, python, openssl…
But those few packages are crucial to the core of NS8, hence the “safety harness” option.
Besides podman / systemd version upgrades et al, there are other packages (kernel, etc.) that could cause havoc among servers.
Currently (in this context) NS8 rocky’s mirrorlist points to default Rocky mirrors but in the future that could change (maybe just for customers using paid subscription based support).
Same as with NS7, user is in control of which repos are enabled (can edit / add repo files), but have to understand the benefits and tradeoffs of those changes.
Although NS8 is build around containers, it (sort of) expects to partially “take control” of the underlying OS to make it its play-field/sandbox. For instance, the use of users and home folders.
Some users would expect a higher degree of separation from the OS, and the ability to build a cluster of mixed OS nodes (even though it’s already a step-forward from NS7 where there is no easy clustering option).
As a precaution, developers will encourage installation of NS8 on a clean OS and deter NS users from installing other software solutions alongside NS8 (on the same OS) to prevent unexpected scenarios. Of course, we can install OS updates, nano, mc, nmap and other tools, but maybe not a full-blown web-server with conflicting ports (hypothetical example).