Lock to "current release" enabled by default from 7.5

davidep · May 18, 2018, 12:07pm

Free as freedom

Free software is not free beer

And so on…

stephdl · May 18, 2018, 3:05pm

Or go back to the ns6 behavior, copy all needed dependencies in the ns repository… A script could be done and copy all updates of our rpm used from epel to our testing branch.

Once validated by a dev, we could move update from testing to base/netforge, then we can update safely our version. For those who want all the last options, epel could be enabled by default

Of course it is tests, works, time consumer.

davidep · May 18, 2018, 6:18pm

This is the point. It’s not sustainable from my point of view. The result in ns6 was that those packages were never updated!

stephdl · May 18, 2018, 6:58pm

Maybe because the script to download updates and push to testing doesn’t exist

From my point of view, earthquake comes from the minor release, hence ns should stuck on a version

giacomo · May 19, 2018, 6:53pm

I agree with both of you, the way we managed updates in NS 6 was the safest one but we almost always had non-updated packages even in case of security releases. This is the main reason we decided together to directly access upstream updates.

Probably the safest solution is to bring back NS 6 way but with a fully automated process which must include automated testing.
Thus we need:

lots of scripts to check upstream repositories and grab latest available RPMs
once the RPMs are download, everything should enter into a testing pipeline to check new installations and updated machines
hundreds of tests to check all the features
multiple scenarios for each feature (for example, we need also to simulate remote networks to check all the firewall stuff)
if all tests are passed, the new packages can be released to YUM repositories
an hardware infrastructure which can handle all this stuff running almost every hour of every day

Of course, such solution needs a huge huge huge work, at least months for multiple developers.
And during these months we will have no time to develop new features, unless we double (at least) the number of involved developers. Also, I’m pretty sure this approach is not really good for the business

I know, I’m a little bit catastrophic but I want to highlight that we need to find balance between multiple requirements and resources.

I think that the subscription project, which we designed and launched together, is (for now) the best solution to have a good balance between security and stability. We spent lot of development hours to design and implement it, and we released it totally as free software (AGPL license). So anyone can install it for its own server or (better, IMHO), sustain the project and buy a subscription from Nethesis which includes excellent professional support.

As further step, we could simplify the “lock procedure” documented by Davide so anyone is free to choose the solution which best fits his/her own needs.

giacomo · May 22, 2018, 2:07pm

Take a look and share your opinion: "NS Release Lock" implementation

/cc @pike @alefattorini @GG_jr @danb35 @robb @dz00te @m.traeumner @stephdl

giacomo · May 22, 2018, 5:17pm

We would like to share with you some ideas about the new “NS Release Lock” feature implementation.

Goal

Users must be able to choose if they want to lock their installation to a specific NethServer and CentOS release. For example, when installing NethServer 7.5.1708 the system will never jump nor to NethServer 7.6.x nor to CentOS 7.6.x even if the user pushes the Software Center > Updates > Download and Install button.

Assumptions

The user will need to explicitly enable or disable NS Release Lock from the Software Center
If enabled, NS Release Lock will be forced regardless of the user is acting from the Web interface or from the command line

Limitations

Some third-party repositories don’t support accessing RPMs using a minor release like 7.5.1804 but only using a major release like 7. Actually, this limitation is present for epel, centos-sclo-rh and centos-sclo-sclo.
Such repositories must be enabled during package installation otherwise YUM will not be able to resolve package dependencies.

Proposal

Third party repositories (epel, centos-sclo-rh, centos-sclo-sclo) will be always disabled for updates from Software Center and yum-cron.
Third party repositories will be always enabled when yum is used from the command line.

When Ns Release Lock is enabled, the following repositories are available (where ce stands for CentOS):

ce-base
ce-updates
ce extras

These repositories will point to a fixed CentOS release, the configuration will be stored inside /etc/yum.repos.d/NsReleaseLock.repo.

The features will be controlled from a prop, something like:

config setprop sysconfig NsReleaseLock enabled

NS Release Lock is mutually exclusive with #subscription: when a subscription is enabled, NSReleaseLock will be disabled.

The user will also be able to select a custom CentOS mirror, by editing /etc/yum.repos.d/NsReleaseLock.repo.

yum-cron will have access to a special repository configuration stored inside /etc/nethserver/yum-update.d/ and enabled using reposdir options inside /etc/yum/yum-cron.conf.

The same special configuration is applied to manual updates from Software Center.

Minor version releases

At some time CentOS will release a new minor version (and NethServer will follow).
Few days after such release, CentOS usually disables access to old repositories and moves all packages inside vault.centos.org.
The NethServer team will notify the users about the new release.

Technically speaking, NS team will release a new version of nethserver-subscription inside the old release: if subscription[NsRelease] will be different from sysconfig[Version] a new banner will appear inside the Software Center with instructions to update.

davidep · May 22, 2018, 1:33pm

How could it look like from the user perspective?

The initial idea is to move the “Automatic updates” (yum-cron) setup under a new Configuration tab/button in “Software center” page. Then add a “Software update policy” section to control the NsReleaseLock prop value.

Here are some examples, please comment!

Software update policy 1

Software update policy 2

Software update policy 3

Separate “Configure” button

robb · May 22, 2018, 2:20pm

I agree that, if a release lock feature is implemented, 3rd party repositories will be disabled because thos still can mess up the install.
I think it is a must have feature on production servers. (and yes, home servers are “production” too)

Is there a ‘howto’ so a user is taken by the hand how to (temporarily) enable 3rd party repositories to be able to install rpm’s from those repo’s?

davidep · May 22, 2018, 2:38pm

With NsReleaseLock=enabled EPEL and SCLo are enabled when software is installed, disabled when it’s updated: no user action is required!

stephdl · May 22, 2018, 2:47pm

do you have some cold case about bad updates of epel…quite sure that SCLo is a really low profile

alefattorini · May 22, 2018, 2:49pm

Why @davidep and @giacomo are thinking about changing the current situation?
Because we care of our people.
Noticing that a lot of users are questioning NethServer stability is a blow to the heart. Improving the upgrade process has become a priority

Subscription were born to offer additional services not to fix NethServer issues. There was a misunderstanding here and we’d like to shed light on that

giacomo · May 22, 2018, 2:53pm

Shorewall in the past, nut just now, ucarp (this is used internally) few time ago.

flatspin · May 22, 2018, 4:38pm

This is important! It was not only a missunderstanding, it also was or still is a misfunctionality IMO.

May I ask @giacomo the following: when a user installs NS from iso, she/he can lock the release to the release of the iso? In the actual case the iso is 7.4, so directly after base installation the user can lock the release and then update to the latest version of this specific release (actually to kernel 3.10.693.21)? Did I understanf this correct?

If this is so, this would be the feature which is needed to install a stable evaluationcopy of NS and that would be perfect!

Thanks a lot!

GG_jr · May 22, 2018, 4:41pm

3rd party repositories including @stephdl epositories and @mrmarkuz repositories?

When NS Release Lock is enabled, I think that those repositories should be enabled because the modules developed by @stephdl and @mrmarkuz were tested for that version of NS.

Or, these repositories will be along with NS repositories for the locked version?

Other question for these two repositories: can be along with NS repositories, for any version of NS (same reasons as above)?

stephdl · May 22, 2018, 7:16pm

In fact I face the same problem, I develop for a specific version of epel (most of time), and remi (php-scl). If the epel version introduced a breaking change (could be possible), Probably I won’t be aware before someone shouts.

I will assume it and produce quickly a solution but the bad will be there…this is a an advocacy for the locked update topic.

At the contrary if I could accept to lock epel, for remi I will prefer it to be enabled all the time. I would love too to get my repo enabled all the time, because I could add some features, or repair some bugs that I have introduced…like we could see at https://community.nethserver.org/t/php-scl-cant-select-version-for-virtual-host/9905.....the fix was available, but the update was locked by the subscription.

Epel is also a repository with a lot of updates, enduser, sysadmin, often want the last version, I have had lastly some demands about wordpress, because epel is in late, available is wordpress-4.9.5, and actually on the wordpress site it is wordpress-4.9.6. Hopefully I could answer to two people (in one week), but not after 3000, or I could loose my calm

So definitively if the update from epel or any third repository is difficult, not possible, manual, it will drive to issues, phone calls and free brain time.

Well it is not simple to find the good balance between bad and good, a lot of scenarios must be tested/found, but sure that davidep and giacomo are aware.

Well, put all our rpms to nethforge, but it is not good for the dev’s egometer

GG_jr · May 22, 2018, 7:26pm

Thanks for the reply Stephane!
Detailed, professional, wise!
As usual from you!

Kind regards,
Gabriel

m.traeumner · May 23, 2018, 7:18am

I think these repos should be automatically disabled too if NS Release is locked, but I think the possibility to enable them manually could be a solution. I’m thinking about a whitelisting, where you can enter additional repos to activate (with a big warning please).

@giacomo, @davidep I like your idea of release lock, it’s the next way to nethservers system stability.

Stefano_Zamboni · May 23, 2018, 7:29am

well, ATM we have some broken servers…

you have to decide between having a rock solid stable distro (i.e. all the involved rpms available from your repos) with a subscription plan that makes some sense and a full upstream compliant one (i.e. unwanted/untested upgrades)

and more, you have to educate people about upgrades… that’s all