I would love to see a feature to exclude a specific update. In the MS world this is available for a long time when using WSUS. A stage between downloading and applying updates for your local clients.
This also introduces the need for a large local repository where all updates will be stored, but especially for commercial environments, this will give a sysadmin a lot more control over any updates (either server, or client)
what do you think about expanding the yellow tab “The new distribution release 7.5 is available. Review the updates before applying them!” with some more explicit and more infos?
in something like:
"The new distribution release 7.5 is available, actual NethServer version 7.5 alpha2. Since the versions are not the same please review the updates before applying them or wait for a stable version"
well, feel free to correct my poor English 
another thing not related but that i would like to see in Updates tab:
a repository column or better group updates for repository (just like updates in proxmox)
ok, finished download of 75beta, time to test 
3 Likes
I’m on the same page, that was my idea too. Being more specific about alpha/beta stage
1 Like
I want to go back to the original Feature request because I think the banner is not enough. At least I want to make another attempt…
The core of the problem lives in the two layers of repositories:
- NethServer
- CentOS/EPEL - “upstream”
The lower layer send updates continuously in a reasonably stable manner. But we learned by experience that under some circumstances “earthquakes” occurs:
- severe security fixes
- minor releases checkpoints
The best solution to deal with this we can provide so far is the Subscription model: a private infrastructure that overlays the public one.
This feature proposal has the following limit:
We could mitigate the effect of their different release cycle by enabling them only when software is installed, not updated. In commands
yum install
yum update --disablerepo=epel
The nsrelease lock plus this enhancement would provide a better stability also on the public upstream infrastructure.
I’m sure we can improve it further!
5 Likes
Ok but this not in opposite with the initial NS statement (before the subscription)?
Free for anyone?
I think the subscription must be only for:
"Over the past few months our community members have asked a lot about professional support service on NethServer. Even if our community support is amazing,they have pointed out problems like these:
I need professional support when I don’t have anyone to call
I need support when I’m in a rush and I can’t wait.
I’m managing a critical infrastructure and community support is not enough for my needs
my boss doesn’t trust open source /nerds without a company behind them
I need to assure management that there is a certain level of official support if and when its required."
1 Like
NethServer is still free for anyone. And not only that.
It’s Free, Open Source and above all developed in the open and community-driven.
Do you remember this problem?
Nethesis just tried to answer offering a service that is able to minimize problem on critical installations
Setting up a service like this is not free and that’s why the subscriptions that we crafted as always in the open trying to collect all the feedback and advice.
Looooong discussions 
1 Like
I think it sounds a little bit unlucky. The version without subscription is stable too. The nethserver updates are tested before they are published. Main updates are published at a test repository and the developers post it at the community to ask for help testing.
The second one are upstream updates which are tested from Cent OS and only passed through to the customer.
The subscription offers stable updates, because they offer updates one week later than the community version. There is a second infrastructure where the updates are saved. And if the community version went well they are offered to the subscription customers.
It’s the same way like it worked with the enterprise version at the past.
1 Like
I do!
Maybe the way in which is formulated this:
" … #subscription model: a private infrastructure that overlays the public one."
is not the best.
As I said, the only difference should be the support services, not the updates!
In my opinion.
EDIT:
Everyone wants and need to have a stable and safe product.
This comes and from the updates.
Not everyone is able to administer the server. Here the subscription comes.
Bear with DavideP 
it doesn’t overlay anything. And it’s all Open Source Dartagnan
We all want a stable, safe AND UPDATED product
1 Like
Probably a bad choice of words!
Overlays is not about contents or features. What is added is the update auditing and extra review!
Don’t forget the bold word, man… 
Free as freedom
Free software is not free beer
And so on…
1 Like
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.
3 Likes
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
1 Like
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.
3 Likes
Take a look and share your opinion: "NS Release Lock" implementation
/cc @pike @alefattorini @GG_jr @danb35 @robb @dz00te @m.traeumner @stephdl
1 Like
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-basece-updatesce 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.
9 Likes
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
3 Likes
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?