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.
There is a new version of the systemadmin module, which solves the following issues:
Network:
– Support for editing network-bonds was added
– You could create new (virtual) devices. Currently, only bonds are supported, but there may be a requirement in the future to support other virtaul devices (e.g. VLANs)
Packet Capture
– Support for port ranges
– Icons on the overview page are bigger
– Changed Stop-icon on the overview-page
– Added default value for Packet count
– Added tooltips and included a warning for ‘Max file size’ Max file count’ and ‘Packet count’
Please note that both parts (the binaries and the PHP files) need to be updated. You will need to download the files from both of the repositories mentioned above and follow the installation instructions from the repositories
In regards to the updates made to netplan.cpp there are still major issues and it seems things I highlighted where not addressed in general (sanitation, validity checks, spelling, etc)
Critical Bugs
Unvalidated exec() result and unsafe pop_back()
filename.pop_back() is called without checking if the string is empty, which can crash the program.
Incorrect YAML path in netplan set command for routes
“+type+”.“+interface+”.routes=… is missing network. prefix (e.g., should be “network.bonds.eth0.routes”).
Typo in YAML key
nameservers.addresse: null should be nameservers.addresses.
Multiple files possible in grep, but only one is expected
grep -l may return multiple filenames separated by newlines; only the first is used, and the rest are ignored or misparsed.
Security Issues
Shell command injection vulnerability
Unsanitized user input (e.g., interface, filename, ipv4_address) is passed directly into shell commands.
Functional Issues
Redundant or duplicate netplan apply executions
std::system("/usr/sbin/netplan apply"); is called 2–3 times in a single run without clear need.
Failure to check results of std::system()
Commands may fail silently because their return codes are ignored.
Static interface assignment may override IPv6 when both are provided
dhcp4/dhcp6 and static settings are written in isolation; YAML merging may not behave as intended.
Multiple calls to netplan set overwrite or conflict
Writing addresses, parameters, and nameservers in separate netplan set calls may overwrite each other.
Sorry for the delay - i’ve had to work again. I will work on the reported issues but i can’t say for now how long it will take. Some of the reported issues or their solutions are mutually exclusive – for example, #9 and #13. Either I have many ‘netplan set’ commands in a row, or I have to concatenate the parameters using ‘variable += “parameter value”’. Or did I misunderstand you?
Did you see that the user input validation is done in network.cpp? But you’re right, I overlooked that I still need to validate the interface name and the mode there. I’ll add the missing tests
Not relying on the PATH variable was a conscious decision on my part, since the commands are executed with root privileges. Depending on which path in the PATH variable the respective command is found first, that program will be used. I simply saw the risk that someone could, for example, put /tmp first in their PATH variable and create a shell script named “grep” under /tmp, which might contain a command like ‘rm -rf /’. With relying on the PATH variable, this shell script would be executed instead of /usr/bin/grep. But since this is a CMake project, I will define variables for the paths and have them replaced at compile time.
Honestly, I think you need to take a moment and reevaluate this module before you continue work on it. I am saying that base on a statement you made in the very first post of this thread.
At this point, the choice of using C++ for this has made it so that you are the only one that can support, develop and maintain this module in the long run. It is outside the scope of how development is done in the open source modules for FreePBX. There really isn’t going to be anyone that can take this over in its current form.
The code that exists now needs to be heavily overhauled to be close to production ready and you are the only one that can do that. So I’m not really sure how much time you have for development and maintenance of this module but at this point I can’t see anyone right now in the community taking it over. I’d have more hope of the community picking it up if it was PHP, NodeJS or anything already being used by FreePBX but C++ is a real deal breaker.
I’m just saying this because it would really suck for you to put in the hours for this only to see it become abandonware once you step away.
