Lock to "current release" enabled by default from 7.5

Why @davidep and @giacomo are thinking about changing the current situation?
Because we care of our people. :family_man_woman_girl_boy:
Noticing that a lot of users are questioning NethServer stability is a blow to the heart. :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 :flashlight:


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!

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)?

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 :smiley:

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!

Kind regards,

1 Like

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.


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

1 Like


@stephdl already requested me yesterday in a private chat :smiley: And the answer today is yes, we are working on it.

I would like to not add such feature in the UI, but we are going to define an API for template-customs or extra repos.

1 Like

I can agree on your statement except for this part. CentOS updates are tested and stable, but need to be handled with care when minor distro releases or other exceptional circumstances occur. Educating people about how to deal with them is not enough.

Wherever possible, we must avoid the possibility of making errors with Server Manager. This is the goal of Server Manager in general, and of this #feature in particular.

I know that centos updates are stable and tested… on plain centos.
if you upgrade a NS maybe they are not.

and I disagree on educating people… we’re talking to “sysadmins”… not windows users.

A so called sysadmin should know that:

  • if you see many updates, don’t apply them on production server without rewieving them
  • tests on VM are mandatory if your server is mission critical (see above)
  • backup is your friend
  • a linux server with data is not a toy
  • don’t (generally speaking) trust what you see on a web interface… if you have doubts, ask your CLI

as I told in a private message, hiding a server management behind a fine web GUI is ok, but you’d never hide to final users that they are using a server, not a play station, otherwise you’re going the same path M$ and Apple designed in the past “be a sysadmin with next -> next -> next -> finish”… is all ok when it works (99% of times), but it becomes a nightmare when something goes wrong.

(rob, some work for you, I think)

1 Like

That’s fine for me.

Yes that’s right, but I’ve seen people here, who are not sysadmins. Give them a chance to use nethserver too. I think the way we go with a simple gui and and the chance to do much more configuration at the terminal is OK.
Another idea is a switch between expert and non expert for the gui, which enables or disables some functions. For example Fritz!OS does it.

you got the point: if we aim this product to everybody, nothing that could be potentially destructive must be available from the GUI…

think about an unexperienced user that uses NS at the office…


Software update policy 4

I’ll go with separate configuration button. Please tell me if text labels are good! Further information can be available also from the Help button and the manual.


Then why have the GUI at all? After all, we’re talking to sysadmins, they shouldn’t need one. But that’s the point of this project, isn’t it? It certainly was the point of e-smith/SME Server: to provide a stable, secure Linux server distro that could be competently administered by someone who isn’t a professional sysadmin. “You’re a sysadmin, you should know better than to install the updates that show up in our update manager” is a cop-out.

Dan, my friend, I’m not against the web gui, at all

I’m against the message that “linux is easy as 1,2,3”: many times here I saw people coming with no knowledge at all about DNS, DHCP, security and linux asking for help…
the answers, other than a given solution, rarely told users “please, read carefully all the documentation” or a quickier “RTFM”

IOW, we’re giving fishes but doing nothing to learn fishing… and that’s bad, 'cause you’ll have many users doing worng thing and damages

all my POV, as usual

probably i miss something… but are we sure that we did’nt need updates from epel furing the 7.5 release cycle?
i’m quite sure, for example (but my memory is worse than my english) that during the 7.4 cycle we need an update of shorewall (i’ve had the problem because on arm32 not all epel package are available as for x64)

i must also admit that i use update from gui only for testing so for me is ok, but, do you think is too complicated to make a check like
" Apply update from third part repositories only if [nsrelease==centosrelease] "?
i mean, keep enabled repo until the available centos is the same version of the ns version installed…


Yes it’s too complicated for me. At least I didn’t find any feasible way to do it.

@giacomo remembers it! We hope it is a rare situation, but if will happen again the solutions are:

  • temporarily switch to the “update all” policy, or
  • run yum update from the command line

Also we (developers) should add a “RPM require” in spec files for specific versions expecially for EPEL and other third party dependencies.

I think a wise method of using this new feature is:

  • start with “update all” policy
  • review and apply updates
  • when CentOS releases a new minor version enable the version lock
  • wait for the upgrade button to appear
  • upgrade
  • revert to “update all” policy and reiterate

This feature does not solve all possible stability issues of NethServer, but is a good improvement IMO.

The biggest problem is that you wan’t be able to install anything requires an EPEL package when CentOS release a new minor.

By the way, a solution exists, you need a full EPEL mirror … and you con do it it with a Dartagnan installation (or a Nethesis subscription of course! :stuck_out_tongue: )

1 Like