Using 3rd Parties to keep up with package evolution?

One of the great thing about CentOS is it’s long term support / lifecycle. But this come often with a lack of new software and end even with unsupported version, such as PHP5 for an example.

While Centos8 sound like to be at the bleeding edge, because it is the new kid in town, in 5 years this story would probably repeat itself and users would prefer to have PHP9 over PHP7.

So I’m thinking what’s about creating Nethserver 8 with 3rd parties repo for packages like Apache, PHP and MariaDB so it will not age too badly.

Example of aging
not aging too badly HestiaCP took this way by installing package from 3rd parties.
aging badly let’s talk about Yunohost which have a hard time to let go PHP 7.0.

Dev perspective
It’s probably require a tighter follow up between minor update but would be probably a smaller step when would be time to jump in Nethserver 9.

SysAdmin/Power User perspective
This obviously my point of view and I’m definitely not a coder/developer but from a point of view of a SysAdmin/Power User that sound great.

What do you think ?

CentOS keeps the same major/minor versions of (at least) any significant packages through a release’s life cycle, which does result in some pretty old versions of software. They do backport security fixes for those packages, though, so you aren’t left with vulnerable software. And for packages where you might really want a newer version (like PHP or MariaDB), Software Collections let you install newer versions alongside the default packages.

I’d be concerned that using third-party repos for core packages would result in a less-stable (and/or less-secure) core system (particularly for PHP, whose devs appear to treat backward compatibility as–at most–an afterthrought), though I do understand wanting to be able to use current software. What problem does your suggestion solve that Software Collections doesn’t?

1 Like

As in many such cases it is a trade-off between stability/availablility and usability. At the end of the lifecycle, we do notice several applications that you want to run on CentOS/NethServer hit dependency problems because the version of, for instance php, is not supported by the application anymore due to EOL of the php version shipped by CentOS/NethServer.
Yes the shipped version is still safe because of backported security patches, but is not usable anymore because an application can’t rely on backporting security patches on ALL distro’s the application can run on.
And to be honest, I don’t blame the application builders to not support php versions that are officially EOL.
It’s all about the RH philosophy not to change those parts during the lifecycle of a CentOS version.

We have to keep in mind why CentOS has been chosen as a base for NethServer in the first place. There are a few reasons you can come up with and hostoric is one of them. Since NethServer is a fork of SME-server and that was built on CentOS, it makes sense to stay on CentOS for NethServer so not every single module needs a rewrite.
Most important reason is the stability of the underlying OS. CentOS might be old, but it is rockstable and very reliable.
Having said this, I am getting this brainwave.
I can imagine there are some users that would like a more bleeding edge version of NethServer.
What if we try to install NethServer on Fedora server? Would the NethServer RPM’s work on that? Would new applications that require newer or even bleeding edge versions of, for instance, php be easier to install in fedora based Nethserver?
@dev_team I am curious to your responses. (could this be a discussion topic for coming fosdem community gathering?

1 Like

Using Fedora as base for NethFedoraServer experience seems not complying to the goals of the project.
And now development is commonly focused in Cockpit management.

One container to rule them all!

CentOS 8 has the concept of application streams to have more recent releases of a software. Something like Software Collection (SCL)… well SCL should be still there but nobody knows for how long.

But the real RHEL answer for such scenarios is now Podman a container engine alternative to Docker.

SCL almost solves the problem, but many SCL software suffer of a poor product life cycle (Product Life Cycle of Red Hat Software Collections for Red Hat Enterprise Linux 7 - Red Hat Customer Portal). Of course, you still have the same problem with containers, but at least it’s dev fault :stuck_out_tongue:

I don’t think it can work, Fedora has many special things. Also, things change very very fast and it’s not good for an enterprise scenario.

Of course! :wink:

In the best case scenario Nethserver offer network services such a Gateway, Firewall, IPS, Samba, than relay the apps layer to Containers (PodMan or Docker)
On this subject:

  • What happen with the Netfilter and Docker integration ?
  • Do you follow PodMan evolution, would be easier to use and have a better documentation than SELinux ?
  • Would PodMan be easier to integrate than docker with netfilter ?

I’m gonna put my daughter on this coloring book

but not everything is in SCL
just take if I look at Netdata package it use NodeJS 6
which is not even documented anymore

and redis-server 3 is considered as an historical version

1 Like

Docker has big problems with Shorewall, Podman should ease the integration process.

You still need SELinux even if running Podman. The documentation seems good enough.

I hope so