The timezone had to contain a / (only ‘UTC’ as a timezone was not allowed, even though it is a valid timezone)
Network Config in IncrediblePBX does not work
@NerdUno: In the thread about this module in the IncrediblePBX forum, you mentioned that the network configuration still doesn’t work even with your fix. Unfortunately, I can’t reproduce your problem with the error message (bonding_masters). If you install the new version of the deb file and possibly apply your fix, are there still issues with the network and/or DNS configuration?
DNS and Time Zone now work fine and are accurate. Network config still defaults to bonding_masters with all remaining entries blank. Using ip a would accurately return the network data since it’s using a Bridged interface to obtain a DHCP address from the host machine, i.e. the Proxmox server’s network card. This is the way most virtual machine platforms work.
That’s not an completely accurate statement. Ubuntu has used netplan by default since 17.10 but there are certain conditions that could make it fall back to /etc/network/interfaces.
Live ISO + Minimal Install: It generally ignores certain packages for a small footprint, netplan.io is generally one skipped. If that is the case, Proxmox will fallback to /etc/network/interfaces
The only way that netplan wouldn’t be used is if something during the install process told it not to. Even would cloud-init based installs, you can configure cloud-init to use /etc/network/interfaces
This goes back to what I said earlier about how the OS is installed. Minimal installs will skip packets like netplan.io, making it so /etc/network/interfaces gets used. If there is a Proxmox OS template using the legacy method, the install config specifically calls for /etc/network/interfaces to be used or something was preseeded for the install.
What it sounds like here is that current install process ends up skipping netplan.io being installed and reverts to /etc/network/interfaces. Systemadmin wants to use Netplan for network management. It is seeing no yaml file created or an empty /etc/netplan/ directory and is trying to pull the network config from /etc/network/interfaces and it’s sucking in the bonding_masters setting which isn’t valid in Netplan (it’s bond:) and thus it fails to load netplan properly.
Might be trying to do too many things in the Network Config option. If it’s a bridged network (bonding_masters is a big hint), then you’re not going to be able to change the network settings without crashing things including the GUI. So display the correct info with ip a and call it a day. Gotta wonder if there is much of anything you could safely do to a network setup from within the GUI that wouldn’t require a reboot. Maybe Network Info would be a better use of the real estate.
This is only a big hint if ENI is how the network is being managed. Netplan, networkd and NetworkManager all use something different to define the bonded interfaces. You would need to determine the network management method and then determine if there’s bonded interfaces the proper way.
However, your issue has shed light on some things. I ran some of the C++ code through some AI validation and checkers. I’ve only done 3 or 4 files and while they all came back with overall good marks, there are some critical and severe bugs in the code of all files checked so far. It ranges from sanitation, validation, some logic based stuff, race conditions, silent errors and some other things.
The issue you are having is due to there being no validation checks on existing netplan configurations and running netplan get against an empty result when grabbing a non-existing yaml file.
Still reviewing the rest of the files but I’d make sure you have backups or some sort of direct access to systems while messing with the networking stuff.
I am not sure if I might have misunderstood you. However, systemadmin checks which method the network is configured with when accessing it (/etc/network/interfaces, netplan, NetworkManager, or systemd-networkd). So if the netplan.io package was not installed during the installation and thus /etc/network/interfaces is being used, systemadmin should recognize this and correspondingly not use netplan. However, the error message indicates that netplan is being used (or at least that systemadmin mistakenly believes it is).
Can you send me the specific results or name the AIs used, so I can fix the bugs? Or do you mean with the last sentence I quoted that you are working or want to work on the bug fixes?
@NerdUno: Does the ‘Interface’ bonding_masters have an IP address assigned to it in your virtual machine?
I’ve set up a virtual machine under Proxmox with Ubuntu 22.04 and IPBX2027, and I couldn’t reproduce the error. I’m seeing three interfaces displayed (the ‘physical’ ens18, bond0, and bonding_masters). Only the bond0 interface has been assigned an IP address.
So I’m wondering if I really need to reproduce the error or if the actual bug is that the ‘Interface’ bonding_masters is displayed in the web interface. What is this interface used for? Is it only necessary for internal OS functions, or is it typically assigned an IP address?"
Sorry, but this discussion is now officially above my pay grade. As I noted above, I think it would be much safer in SystemAdmin to DISPLAY network settings rather than allowing users to MODIFY them. This is an invitation to disaster IMHO.
We always use minimal installs, but we add lots of components. No file in /etc/netplan with iPBX 2027-U (Ubuntu 22.04 with FreePBX 16)* until we generate incrediblepbx.yaml. With iPBX 2025-U (Ubuntu 24.04 with FreePBX 17), /etc/netplan has 50-cloud-init.yaml. We simply cloned the 2025 entry for 2027:
network:
ethernets:
ens18:
dhcp4: true
version: 2
There was no Ubuntu 24.04 or FreePBX 17 when iPBX 2027-U was released.
Unfortunately, before I checked the directory, I had already interacted with the web interface and the binaries directly to produce the error message from NerdUno. Therefore, I cannot say whether the bonding_masters.yaml was created by the installer or as a result of my tests. If the file was created by the installer, I also do not know how the file looked prior to my tests.
I am currently in the process of installing a new VM to find this out and will post the results here
As I mentioned in my last post, I created a second virtual machine under Proxmox to investigate the error message. The web interface shows the three interfaces again, but in the /etc/netplan folder, there is only the file 00-installer-config.yaml with the following content:
# This is the network config written by 'subiquity'
network:
bonds:
bond0:
dhcp4: true
interfaces:
- ens18
parameters:
mode: balance-rr
ethernets:
ens18: {}
version: 2
The file /etc/netplan/bondingmasters on the first virtual machine was apparently created by my tests. It seems more and more to me that the real bug is that bonding masters is recognized as an interface by the system admin module and displayed in the web interface. Therefore, I have created a new version of the module that fixes the following bugs:
eMail: After submitting the form most fields are displayed in the local tab
eMail: Input Validation only done in Remote Display
Network: If bonding is used, an interface ‘bonding_masters’ is displayed in the web ui
Please note that bonding is still not supported at this time, as the source code of the binaries and the PHP code need to be modified for it to work. I will implement these adjustments, but I cannot provide a date yet.
Unfortunately not. Since I have never dealt with bonding before, I need to first find out how to configure bonding with the four different configuration options (/etc/network/interfaces, netplan, NetworkManager, and systemd-networkd) in order to adjust the C++ files and the PHP code accordingly. I hope to make as much progress as possible by Wednesday, as I will then have to work continuously until May 27th, and I won’t be able to work on the project during night shifts.
