Hi, when I add a new alias IP on a bridge via Cloudmin’s “System configuration → Network Interfaces”, it breaks the corresponding netplan configuration, rendering it unable to boot so at next reboot we end up in big trouble.
The config error is the addition of those lines in the .yaml netplan file below the route section :
even while the parameters and interface section is already here, it keeps adding them and the interfaces declaration is obviously buggy as hell and breaks netplan at next reboot, cutting off the server from the Internet
If I add more alias IP it keeps adding those 4 stupid and broken lines each time, with different value for the ARRAY.
Please fix this since it makes Cloudmin basically dangerous to use for server admin !
Right, so that is quite a significant issue. I’d guess this is related to the underlying Webmin functionality. Certainly one that @Jamie should be made aware of?
Sure, those are physical hosts, so they all have Webmin installed to be managed by the Cloudmin master.
Also the issue arise the same when I modify the network interfaces from Cloudmin master or when I open the Webmin on managed system, via the Cloudmin master tunneling, and add the IP in the Webmin networking module of the physical host.
Ubuntu 20.04 and 22.04
I found several problems with netplan using webmin and virtualmin.
Netplan differs from 20.04 to 22.04
22.04 need 0600 not 0644
When adding a new IPv6 to a virtual server, sometimes put /64 in the first IPV6 in the netplan.
If the system reboots, it can only be recovered in rescue mode.
The system modifies netplan ipv6 by adding " " to the existing ipv6 in the original nameserver address ‘2001.2637.221::1’ changes to “‘2001.2637.221::1’” on reboot, not pinging, only in rescue mode can recovery be achieved
If a virtual server deleted, ipv6 address is deleted ok, but “/64” in the end stay in netplan file.
Netplan reads all files in /etc/netplan, why not create a file like 234_example.com with ipv6, instead of making changes to the default file?
like
netplan try can’t be used with a bridged network configuration, which the mandatory default for VM hosting…
So we are bound with apply & pray… and loosing access to the server in case of problem
Only way out in this case is rebooting in rescue and blindly searching what went wrong…