Yeah, that’s a different problem than the one we’ve been able to reproduce (which is that some debug messages didn’t get turned off), but the problem you’re seeing is much more serious and it’s good we had debug messages to trigger misbehavior so it’d be easier to see immediately after update!
Wait, are you really sourcing that directory twice!?
I didn’t sourced anything, this is the default file from a zero-minute fresh installation
2 Likes
I’m gonna guess that’s the problem. I’m trying to figure out if anything we would do would trigger it, but I can’t imagine we’d ever do that.
But, you definitely don’t need two identical source-directory lines.
I’m gonna test and see if that causes the problem on my test system…I bet it does (it’s still a bug, but your config file shouldn’t look like that, either).
@Jamie, if user has source-directory instead of standard source, i.e. source-directory /etc/network/interfaces.d/* instead of source /etc/network/interfaces.d/* then we are gotten stuck in an infinite loop!
Edit2: Ilia just pointed out to me that the two source-directory lines we’re talking about are not identical, which changes everything. Well, changes most things.
You should change both lines (do not delete either) to use source syntax instead of source-directory. Or shut down webmin and wait until we roll a fix.
Sorry for the confusion. Dang. This is weird stuff. I guess /run/network/interfaces.d is network mounted block storage that the hosting provider manages.
Based on Ilia’s testing, you can just change the
source-directory
lines to
source /etc/network/interfaces.d/*
source /run/network/interfaces.d/*
That’s the workaround to using 2.011 without it getting messy. You’ll still get a few extra log entries every five minutes, but they are mostly harmless (I see a half dozen lines every five minutes on my test system).
We’ll fix that bug as soon as we understand it.
1 Like
this is what I did on my prod server. the problem occured on today’s update, not before, the host didn’t changed anything lately (same debian 11 image)
We know, it is specific to Webmin 2.011, which was just released. The config is nonsensical, but Webmin should not choke on it; we’ll fix that.
1 Like
another small bug I see on this version is with awstats config. Mail to root every 10m after the cronjob :
Error while processing /etc/awstats/awstats.conf
Error: SiteDomain parameter not defined in your config/domain file. You must edit
it for using this version of AWStats.
Setup ('/etc/awstats/awstats.conf' file, web server or permissions) may be wrong.
Check config file, permissions and AWStats documentation (in 'docs' directory).
Populating the SiteDomain parameter on the config file dont fix the problem.
I’m on a fresh install with the -m -b LEMP parameters
Please don’t switch subjects, and just start a new thread for a new topic!
The fix for the problem is here, please double-check:
Infact, I really doubt that contemporary Debian systems (many users) would have this source-directory option instead of source. But it’s good to have it fixed. We will release a new Webmin update as soon as possible!
New topics for new questions, please.
How does that cause an infinite loop, unless one of the files in /etc/network/interfaces.d sources the same files again?
I added Track files already included to avoid include loops · webmin/webmin@3bdc75b · GitHub to prevent include loops…
1 Like
while loop was never interrupted as none of the options were recognized … a bit risky!
@Jamie Well, this would not solve the initial problem, and I could easily make it fail again (with latest patches applied) by adding some incorrect option name to the config file (could be a result of a typo), i.e:
sourse-directory /etc/network/interfaces.d
Aside from refactoring the code, the easier and straight-forward solution to this problem would be using a persistent private variable defined with state keyword, where we could just make sure that an incoming file was already read and return () if it were…
1 Like
But if there is an unknown option line, the loop will exit at error("Error reading file $network_interfaces_config: unexpected line '$line'");
@Jamie, this is true, however it would only happens if you call it on the UI, on contrary when it’s run in the background it doesn’t stop …
@Jamie, check this patch:
Also, are you sure that your $done = { } won’t be reset every time you call get_interface_defs sub?
Also, I have taken a deeper look, ran tests and found out that files were read more than once with the current code and made this patch to solve it:
For the proof of concept, try to test it by adding an extra include line to /etc/network/interfaces, like source-directory /etc/network/interfaces.d, also make sure that interfaces.d/ contains a file, e.g. 50-cloud-init with content:
auto lo
iface lo inet loopback
auto enp0s5
iface enp0s5 inet dhcp
Latest patch fixes the problem of re-reading the files twice.
I’m gonna point out that if it can only read the file once, it can lead to interpreting the configuration differently from what the network config system sees.
Picture this in /etc/network/interfaces:
source /etc/network/interfaces.d/*
auto eth0
iface eth0 inet dhcp
source /etc/network/interfaces.d/*
And, interfaces.d contains a file with:
auto eth0
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
gateway 192.168.1.254
If we’re enforcing reading the file once, we will believe dhcp is being used to configure eth0, but we will be wrong. This will be a static interface as defined in /etc/network/interfaces.d/eth0.
This would be a deranged thing to do. But, we’ve seen that deranged things happen…we already saw multiple source-directory directives in a user’s config above.
This is a very good point, Joe.
Although, the goal of this patch was not to change the logic. This patch and the code before produce the same results, despite where you put source keyword.
Even if we go more back and remove the patch that Jamie made a few days ago (which wouldn’t work without using state or globals), it still produces the same data structure.
The only difference with the latest patch is that it doesn’t redundantly run the code twice, e.g.:
The first group (4x files) is the old code and the new group (2x) files is the new code. Both variants return the same data structures:
1-ret
[
[
'lo',
'inet',
'loopback',
[],
'/etc/network/interfaces.d/50-cloud-init',
8
],
[
'enp0s5',
'inet',
'dhcp',
[],
'/etc/network/interfaces.d/50-cloud-init',
10
]
]
2-ret
[
[
'lo',
'inet',
'loopback',
[],
'/etc/network/interfaces.d/50-cloud-init',
8
],
[
'enp0s5',
'inet',
'dhcp',
[],
'/etc/network/interfaces.d/50-cloud-init',
10
],
[
'lo',
'inet',
'loopback',
[],
'/etc/network/interfaces',
10
],
[
'enp0s5',
'inet',
'dhcp',
[],
'/etc/network/interfaces',
13
],
[
'enp0s5',
'inet6',
'auto',
[],
'/etc/network/interfaces',
15
]
]
I don’t know if putting source under other directives in /etc/network/interfaces actually change anything for the system, neither if it’s a correct way.
1 Like