Lock to "current release" enabled by default from 7.5

It is also a complete mirroring of NethServer and upstream repositories to take consistent snapshots of them. It is an infrastructure and needs maintenance. Everyone can run an instance of it on its own because it’s AGPL code.

As I understood well, we can enable it just for our repositories but it doesn’t ensure that packages updated by EPEL and others would break the system. Right?

Just another proposal
Are we able to differentiate a “Normal” upgrade from a new “minor release”? In this case we can show a message like:
"Clicking on upgrade you will upgrade your system to the (version) alpha/beta x"
I don’t know if it’s technical doable
It would be just an aestetic change but will make user aware of that

We already have this fantastic feature :wink: Look at Upstream updates awareness section in NethServer 7.4 released

Documented here


Can we say something like “New 7.5 alpha1 is available” ?

Too late to save lives :frowning:

About the updates and how is better to do the updates, we talk every time when something goes wrong because of updates.

Every time, the same thing: CentOS updates vs NS updates.

Cherry pick updates in Software Center

I’m not programmer and I don’t know what means to do something like this:
Two kind of updates on Software Center:

  • Updates for CentOS, selectable with checkboxes
  • Updates for NethServer, selectable with checkboxes

Is this very hard to do?
Will be less troubles in this way?
What do you thing?

Sorry for bother you again with this …

Kind regards,


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

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


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!


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."

( http://www.nethserver.org/blog-nethserver/ )

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

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.

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 :slight_smile: it doesn’t overlay anything. And it’s all Open Source https://nethesis.github.io/dartagnan/

We all want a stable, safe AND UPDATED product :slight_smile:

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… :wink:

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.


This is the point. It’s not sustainable from my point of view. The result in ns6 was that those packages were never updated!