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
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!
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
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.
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
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.
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.
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
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…