Yes.
@stephdl already requested me yesterday in a private chat 
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…
3 Likes
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.
2 Likes
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…
2 Likes
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 updatefrom 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! 
)
1 Like
Software update policy 5 (final?)
- The first time Software center is opened, the following screen appears. It happens on new installations and existing ones, too:
- Picking one is mandatory, otherwise a validation error occurs:
- After Save the Software center page is displayed as usual. Press the
Configurebutton to go to the previous form again, to change policy or yum-cron settings
Please comment!
This version for software updates gives only 2 options
-stay to current release
-update to newer release
IMO should be possible to:
-stay to current stable release
-update to a newer stable release (dropdown with the list of supported stable)
-update to latest packages available (including tests)
I know that could be a bit tricky but i think that this kind of approach could help to manage the situation for next stable release (7.6) or major version (nethserver 8)
This approach could also help to choose the upgrade path in case of different situations.
For instance, a sysadmin which want to test full upgrade of production enviroment with the latest stable release…
That’s only a hint… 
2 Likes
We can’t cover all the needs but we can try to give people a choice
- being conservative (update just my release) stable mode
- being brave (update all) edge mode
For me, if we explain that well it’s a good balance.
As we know, making a complex interface with a lot of choices confuses people.
5 Likes
No no! The two options are two ways of updating the system in the same release
I want to add it as a yellow banner with a button that appears when a new minor is available: what do you think?
1 Like
Although I usually like being brave, when it comes to my NethServer installation at home - I have to treat it as Production class which means I do need to be a little conservative with it.
1 Like
Ok let’s give a name to the available choices. A name is important to understand what we’re talking about and for documentation references. I don’t like “brave”, I’d prefer “expert” because one must understand what is being updated. It gets the best of security fixes and updates. “Conservative” still needs some expertise but is less error-prone.
So this is my proposal
- Conservative
- Expert
I’ll send a screenshot soon
About stable/edge mode: both policies are stable in the same way IMO. It depends on how they are used.
Make that all repositories that are not able to differentiate between minor / point updates. The goal is to not break a running server because of upstream point updates.
But if you are expert but can’t differentiate between updates (choose what to update and what not), there is not much ‘expert’ about updating. Then it’s more like rolling dice.
Wouldn’t it be feasible to have an option to allow and disallow updates on a per-package basis?
3 Likes
We discussed that Feature in the past and I agree with @giacomo here Cherry pick updates in Software Center - #9 by giacomo :
To be able to cherry pick updates, you need a deep understanding of rpm packages interactions and system libraries.
That proposal was not able block dependencies, so I abandoned it because it solves the problem partially.
What changes with “software update policy” is the set of repositories enabled during updates.
I’d name it “expert” because it requires some expertise about what’s happening, as we learned during the past week, when some people just pressed “update” even if a “new distribution is available” warning was displayed. The “conservative” policy would make that kind of mistake impossible.
…but please suggest other names! I’m sure my proposal can be improved!
Both policies wouldn’t save us from a badlock-like regression coming from upstream. If that happens again in the future, the only thing that can help is a careful review (and backup) before updating.
1 Like
Come on guys, if you’re able to choose what updates to select, you’re enough expert do it by from the command line line. It’s just a couple of commands to learn! 
1 Like