Release candidate: ISO 7.7.1908 rc1

The NethServer 7.7.1908 rc1 ISO is ready for testing!

Please download it from:
The ISO will be available until the final release.

List of changes since 7.7 was freezed:

To upgrade an existing NethServer 7.6, execute:

yum update --enablerepo=nethserver-testing nethserver-subscription
signal-event software-repos-upgrade

Thanks to all @dev_team!
Now it’s your turn @quality_team: please test and report here!


A post was merged into an existing topic: ARM development: next steps

No codename for this RC? Ok, it’s a minor upgrade… but still I love codenames for new releases… :slight_smile:


Codename: tarallino


See also


First Installation went well;

And as I saw cockpit was installed by default went straight to port 9090. I do not know if it is expected behavior but i did not get a wizzard. And found the hints to complete the installation not so user friendly, for instance it kept on insisting to change the ssh port for 22 to something else.

So went back to the old setup on port 980.

Installed ad- accountprovider, fileserver ips and basic-firewall (ui) successfully.

Although I get these messages went suricata reloads:

... systemd[1]: [/usr/lib/systemd/system/suricata.service:17] Unknown lvalue 'MemoryDenyWriteExecute' in section 'Service'
... systemd[1]: [/usr/lib/systemd/system/suricata.service:18] Unknown lvalue 'LockPersonality' in section 'Service'
... systemd[1]: [/usr/lib/systemd/system/suricata.service:19] Unknown lvalue 'ProtectControlGroups' in section 'Service'
... systemd[1]: [/usr/lib/systemd/system/suricata.service:20] Unknown lvalue 'ProtectKernelModules' in section 'Service'

Did not look into this further, it could be a miss-configuration on my side or my own home-brew mail-module gets in the way (although it does not touch the ips configuration…)


also find evebox to be very verbose in the systemlog, about every minute:

... evebox[1476]: 2019-10-02 14:26:26 (purger.go:62) <Info> -- Deleting events prior to 2019-09-01T14:26:26.446264+0200
... evebox[1476]: 2019-10-02 14:26:26 (purger.go:101) <Info> -- Purged 0 events in 171.908µs
... evebox[1476]: 2019-10-02 14:26:28 (evefileprocessor.go:176) <Info> -- Total: 0; last minute: 0; EOFs: 60
... evebox[1476]: 2019-10-02 14:27:26 (purger.go:62) <Info> -- Deleting events prior to 2019-09-01T14:27:26.447119+0200
... evebox[1476]: 2019-10-02 14:27:26 (purger.go:101) <Info> -- Purged 0 events in 501.135µs
... evebox[1476]: 2019-10-02 14:27:28 (evefileprocessor.go:176) <Info> -- Total: 0; last minute: 0; EOFs: 60
... evebox[1476]: 2019-10-02 14:28:26 (purger.go:62) <Info> -- Deleting events prior to 2019-09-01T14:28:26.448317+0200
... evebox[1476]: 2019-10-02 14:28:26 (purger.go:101) <Info> -- Purged 0 events in 188.302µs
... evebox[1476]: 2019-10-02 14:28:28 (evefileprocessor.go:176) <Info> -- Total: 0; last minute: 0; EOFs: 60
1 Like

This was a design choice done months ago, nobody complained until now :smiley:
The idea is to not block the user with not really necessary configurations and enforce the changes when needed (like changing the default host name when installing an account provider).
Maybe we can improve the hints, any suggestion?

Remember that you can disable the hints from the settings page.

This an upstream cosmetic issue. I know @filippo_carletti would like to report it.

It’s good, it says everything is working :smiley: I do not really it either, maybe we can ask upstream.

Aha, it is a good thing i did not find any bugs nor regressions :smiley:

It kind of makes the journalctl useless (imagine all running sevices do this :cold_sweat:) , will investigate:
IIRC the systemd-unit of evebox is configured to read the environment from sysconfig, perhaps we can tweak that a little bit better.


It should be fixed soon:


I’m getting appetite on both, tarallino and Nethserver 7.7 :grinning:


Did a first install. A all in one box with red and green network.
Every thing went good.
Used the “old” server manager to complete installation with wizard.

I like this hint to new server-manager:

After installation these updates were available:

After that I went to new server-manager.
Hint about rot access of server-manager. Switched it of.
All thing now tried in cockpit.
Update => no errors in log
Installed from softwarecenter:
Backup data, bandwidth monitor, Basic FW, DPI, fail2ban, file server, IPS, netdata, opanvpn, reports, sogo, statistics, webfilter, webproxy => no errors in log
Started all services
suricata gives a lot of warnings about unknown values (see @mark_nl post) , but no errors
Installed lokal AD => no erros
User creation => no errors
file server testshare => o.k.

Will play a little bit further and report if I find something.

So all in all really impressive for a rc1. No errors so far.
Thank you very much for your great work @dev_team!! :+1: :+1: :+1:


tested so far:
update some test VM almost clean, no errors
update test VM with nextcloud, ok
update test VM with zabbix, openvpn OK
update appliance with Firewall, Nextcloud, openvpn: ok

to try tomorrow (hopefully):
update 7.6 with AD, and proxy
test clean installs and packages
Tnx @dev_team for tarallino :grin::vulcan_salute:


this RC is good for me “to take in production” :smiley: ;

It took a long time to say goodbye to the last running (mail) service still running on the old centos 6 based clearOS box :pensive:


It served me well for many years, there is a bit of tragedy in progress… :cry: ;
And joy with the brand my new (kopano) mail setup :smiley:

This RC looks good to go for me :+1:
and as promised tomorrow (late evening CET) we have running for armhfp/aarch64 RC’s too


Thank you all for your tests!
I think we are going to release the final in the first days of next week!



i cant log in via cockpit with the admin user. Error Authentication failed Timeout. Same problem wit a normal user. Same Error. Only root can log in. Fresh Installation with LDAP, WebTOP and Nextcloud. Can somebody help?



You need to enable the “Shell” option: it’s a change introduced in the latest upstream Cockpit version.
See: Accessing the Server Manager — NethServer 7 Final

1 Like

I think this shouldn’t be enabled by default at administrator and admin user.
It doesn’t make sense to create an admin without priviliges, IMO.

Honestly, this could be considered a regression, but it’s an upstream decision, there is no way to change such behavior.

This is why since NS 7, the admin is disabled by default and it’s there only for users coming from NS 6.
The preferred user to access all Server Managers is root.

1 Like

Thanks for your explanation! :+1:

Hi Giacomo,

you are a good teacher. Exactly this was the solution.



1 Like