Free as freedom
Free software is not free beer
And so on…
Free as freedom
Free software is not free beer
And so on…
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.
This is the point. It’s not sustainable from my point of view. The result in ns6 was that those packages were never updated!
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
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:
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.
Take a look and share your opinion: "NS Release Lock" implementation
We would like to share with you some ideas about the new “NS Release Lock” feature implementation.
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.
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
Such repositories must be enabled during package installation otherwise YUM will not be able to resolve package dependencies.
Third party repositories (
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):
These repositories will point to a fixed CentOS release, the configuration will be stored inside
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
yum-cron will have access to a special repository configuration stored inside
/etc/nethserver/yum-update.d/ and enabled using
reposdir options inside
The same special configuration is applied to manual updates from Software Center.
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.
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!
Separate “Configure” button
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?
NsReleaseLock=enabled EPEL and SCLo are enabled when software is installed, disabled when it’s updated: no user action is required!
do you have some cold case about bad updates of epel…quite sure that SCLo is a really low profile
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
Shorewall in the past, nut just now, ucarp (this is used internally) few time ago.
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!
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)?
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 PHP-SCL - can't select version for Virtual Host…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
Thanks for the reply Stephane!
Detailed, professional, wise!
As usual from you!
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).
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