No, static green, maybe I should change to red? From internet only necessary ports are allowed. It’s a provided managed host with minimal centos and I installed NethServer on it.
OK restarting shorewall and httpd today in the morning just made my httpd virtualhost mirror work again. During the day I noticed that SoGO has white screen after login, roundcube login not working(storage error), Webtop login not working(loading animation forever) and EAS also dead.
So I restarted dovecot in the evening and now all is working again. Maybe you can see something in the following output(I faked public IP to 1.2.3.100), I’ll try a reboot of the server later. Could not find a dovecot error in the logs…
[root@nethserver ~]# db networks show
eth0=ethernet
bootproto=none
gateway=1.2.3.1
ipaddr=1.2.3.100
netmask=255.255.255.0
role=green
ppp0=xdsl-disabled
AuthType=auto
FwInBandwidth=
FwOutBandwidth=
Password=
name=PPPoE
provider=xDSL provider
role=red
user=
[root@nethserver ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether da:b2:2d:94:32:04 brd ff:ff:ff:ff:ff:ff
inet 1.2.3.100/24 brd 1.2.3.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 0000::0000:0000:0000:3604/64 scope link
valid_lft forever preferred_lft forever
3: ip_vti0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1
link/ipip 0.0.0.0 brd 0.0.0.0
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
link/ether 52:54:00:1f:3b:48 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 1000
link/ether 52:54:00:1f:3b:48 brd ff:ff:ff:ff:ff:ff
EDIT:
I removed webvirtmgr package, rebooted and everything works now. No firewall error in dashboard anymore. But I still have this virtual bridge. Maybe providers internal network for backup?
Thanks for your help!
I don’t know anymore. Is there a way to check it? May I remove libvirt if I don’t use webvirtmgr?
If the provider needs it he will communicate I think…
Update worked without issue. But there were no warning about updating to new version.
Machine is a VM ported form NS6 to NS7.3 via rsync and than updated via softwarecenter to 7.4.
Accountprovider is local AD
Installed Modules:
The warning appears when upstream (CentOS) releases a new minor version, which is a situation that created some issues in the past. Here we are releasing the NethServer 7.4, which is tested by our @quality_team and 100% safe (hopefully), so no banner is required.
Do you think there is a bug in SOGo configuration? Sorry I didn’t read that topic, I’m quite busy now. I’d really appreciate if someone files a bug here or on GitHub with reproducible steps!
You are right, I removed libvirt and on next reboot the virbr0 was away. I searched the net and 192.168.122.1 seems to be a default libvirt bridge. Thanks again!
I’ve updated to 7.4 final yesterday, but without a reboot. The password is still cleartext, not binary.
Did you have done a reboot after that?
I can’t do at the moment.
On an updated LDAP Nethserver 7.4 I have no binary password too and it works after reboot.
On a fresh installed AD NS 7.4 I have binary password and it works after reboot.
Sorry, I don’t have an updated AD NS 7.4. Maybe it’s like already created passwords stay in cleartext.
The upstream samba package was updated from 4.4 to 4.6 in CentOS 7.4. I suppose they changed the random password generation algorithm…
On our side, about one year ago we disabled the automatic SSSD password renewal function, introduced in 7.3 that breaks non-sssd aware modules (like SOGo, WebTop, Roundcube…).
I think we should stop to use the machine password to browse Samba AD LDAP and always require a dedicated account, like we do with MS AD. Local AD provider can generate it automatically.
No, as long as individual configuration templates and applications support binary data.
Hello. I decided to write about the problem after the update: I get the following
systemd-219-42.el7_4.4.x86_64 conflicts with dracut <033-499
Do you have any tips on how to solve the problem?
actual dracut version is 033-502, so I think dracut will be updated and the conflict is gone…
In which situation do you get this error? On Update? Just found in /var/log/messages?