Hello developers,
currently it seems that you have to update the OS under NS 8 manually via putty. Will there be a solution in the future, so that you can do the same as in NS 7?
Regards…
Uwe
Hello developers,
currently it seems that you have to update the OS under NS 8 manually via putty. Will there be a solution in the future, so that you can do the same as in NS 7?
Regards…
Uwe
The answer thus far has been to use the underlying OS’ mechanisms for this, but surely there’s a way to automate routine system updates. Under Debian, that’d be using the unattended-upgrades
package; I’m not sure if yum-cron
is still the way to do it with an EL-based distro.
https://dnf.readthedocs.io/en/latest/automatic.html
Dnf automatic works pretty well
I still do not know if we are going to provide a cronjob for it, but Steph pointed out a good tool.
For sure we have plans to offer public mirrors of the distribution to lower the risk of breaking updates.
on all my laptops I use dnf automatic upgrade on fedora, never have an issue, with a subscription repository it would be nice and secured enough
Just for the record,
Usually, it’s a good practice to apply security updates as soon as possible. But, even if NethServer depends on few packages, not all system administrators feel confident about automatic updates.
and:
Note
It’s not recommended to enable automatic updates on CentOS Stream, since it is considered a preview of next RHEL stable release. Updates could bring major releases of podman and SELinux policies introducing unexpected bugs.
I assume this is meant for debian also. In IT there have been, still are, and will be always dependencies between OS and apps/programs. Therefore “never touch a running system” is still valid, for sure.
It’s something new to me to build entire server with multiple dockers/container and clusters with this kind of disclaimer. Server are meant to be as stable as possible - of course always including the latest security updates for the OS at release time.
For sure we have plans to offer public mirrors of the distribution to lower the risk of breaking updates.
What does that mean exactly? Who will decide when it’s time to update? No more the maintainers of the underlying distro? Holding back security updates released for the underlying OS for not breaking the server/docker/container? Yes, I got it - the admin can decide to update…, and in case roll back…
I read somewhere in the marketing speech for NS8 with the new structure of being more independent from a distribution, specially with containers/dockers, there will be more security. All we be more stable and safer ever. Obviously not when it comes to security updates which can break the whole server.
I wrote this already a few months ago in a very early thread. The disadvantage of this construction is always the dependency of the underlying OS.
I’d think that’s highly unlikely. CentOS Stream is the exact opposite of the stable enterprise OS one would want as the basis for your server. But Debian is exactly that stable OS, as is EL, and as have been the EL clones (I don’t know that we have enough information to make a judgement on them now, after RH’s recent user-hostile moves). Automatic updates in Debian, Rocky, Alma, etc., should be safe. But…
I think we should remove CentOS Stream from our set of officially supported distributions. It is still good for development, as it is the “preview release” always aligned at the last dev’s commit. Some times however the last commit still needs some fix, so it is not polished enough for production.
Yes, for just the time to test them, like for any other package update. But as security updates do not affect stability, probably they are that kind of update that can be tested and released really fast.
Note that public mirrors will be offered only for Rocky Linux, that is used to build the VM image.
Nothing is impossible, but this seems to me unlikely to happen, for a security update.
I can’t see a real disadvantage here. Containers add more software, but they add also more isolation.
…but we had problems with minor updates (7.2, 7.3, 7.4…)! The idea of public mirrors for Rocky Linux comes straight from it.
3 posts were split to a new topic: Container security on NS8