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…)
EDIT:
also find evebox to be very verbose in the systemlog, about every minute:
This was a design choice done months ago, nobody complained until now
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 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
It kind of makes the journalctl useless (imagine all running sevices do this ) , 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.
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.
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!!
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
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?
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.