I think I’ve found a bug with DHCP in replica nodes with 5.0. Let me explain my setup first:
- We have a main office and several branches, connected via site-to-site VPNs. The VPN & firewall setup is done via dedicated devices, not managed via Univention.
- In the main office there’s a main node and a “local” server, set up as a backup node.
- Each remote branch has a local server, set up as a replica node.
- All servers provide DHCP for its local network, with a separate subnet for each site. The only servers sharing a DHCP range are those of the main site.
- All of the nodes are running up-to-date Univention 5.0
- While the VPNs are up everything works: all servers see each other and replicate their configuration from the main/backup nodes. If any VPN goes down there’s no immediate problem, as the local replica retains its setup.
Now, the problem I noticed is this: when one of the branches’ VPN is down AND there’s a need to reboot the local replica server, that server DOES NOT serve DHCP until it’s been able to connect to the main site. Until then, that replica behaves as if the DHCP service had been installed but not fully configured: the system contiously tries to start the service and syslog shows those retries failing because an “error” in the configuration. When the VPN is restored and the replica resyncs with the main servers, that DHCP configuration is automatically restored and the service starts by itself.
My guess is that the DHCP configuration is reset to a blank after each reboot, instead of retaining its last known setup.