Running FreePBX 17 / sysadmin 17.0.3.7 on Debian 12 (Vultr cloud image, cloud-init 23.4.4, ifupdown). Hitting a reproducible issue where the server loses its IPv4 address and can only be recovered from console.
Cloud-init writes the network config to /etc/network/interfaces.d/50-cloud-init, covering both interfaces (public NIC via DHCP, VPC NIC static).
The sysadmin module’s hooks/rename-interface renames that file to a per-interface name — on my box, enp1s0. The content is unchanged; it’s a straight rename, confirmed by matching inode content and ctime.
At the next boot, cloud-init recreates 50-cloud-init. Since /etc/network/interfaces sources interfaces.d/*, ifup now reads two files describing the same interfaces. The second pass fails:
ifup[780]: RTNETLINK answers: File exists
ifup[620]: ifup: failed to bring up enp8s0
networking.service: Main process exited, code=exited, status=1/FAILURE
Because networking.service is a oneshot and dhclient is forked inside its cgroup, the failure takes dhclient down with it. No DHCP client remains running, so the lease on enp1s0 is never renewed, and the address disappears at expiry — typically ~24h after boot. sshd is still listening and the console looks normal, but SYNs arrive with no local address to match, so connections time out silently.
The hook fires during any sysadmin-module activity, not just installation. In my case it ran when I opened asterisk-version-switch and quit without changing anything:
sysadmin-hook[100835]: sysadmin hook started - ["sysadmin_manager","sysadmin.rename-interface"]
sysadmin-hook[100835]: Running '.../sysadmin/hooks/rename-interface' via pcntl_exec
The file’s ctime is one second later.
modules/firewall/Network.class.php has:
php
public function getInterfaceConfig($int) {
// TODO: Portable-ize this.
return $this->getRedhatInterfaceConfig($int);
}
public function getRedhatInterfaceConfig($int) {
...
if (is_readable("/etc/network/interfaces.d/$int")) {
So the modules expect RHEL-style per-interface config files, mapped onto Debian paths. That works on an appliance install where nothing else manages the directory, but is colliding with cloud-init on Vultr image of Debian 12.
My questions are:
- Is there a supported way to tell sysadmin not to manage network config on cloud instances?
- Would it be reasonable for
rename-interfaceto skip the rename when a cloud-init-managed config is present, or to detect the datasource? - Is anyone else running FreePBX 17 on Debian 12 cloud images seeing this? It seems like it would affect any cloud-init deployment, not just Vultr.
Right now, I’ve worked around the issue by creating a guard script that runs at boot (ordered before networking.service) and every 5 minutes via cron, moving any non-50-cloud-init file out of interfaces.d/. It works, but it’s fighting the module rather than configuring it, so I’d rather do this properly if there’s a supported path.