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
It definitely does. I wasn’t guessing. The old Debian network scripts are just shell scripts. They run as they parse…and if you source something twice, it gets run twice.
“Correct” isn’t what I’m talking about. I’m just talking about what happens.
Edit: But, whether we should care a whole lot about a network configuration system that is deprecated and will be gone in a couple more years, and which we never handled in a way that would work with a config file like my example, is the question. If it’s a lot of work, we should not. I just reckon it ought to be known that our behavior is different from the system network tools…in case it comes up, there’s an easy solution (don’t do ridiculous things in the config files, like include the same file multiple times).
1 Like
Absolutely, agreed.
Also, I have run tests before having two source includes, one at the top and the other at the bottom of the main interfaces file.
So, after I removed one from the top, and started to call one only at the bottom of the file, the final data structures have changed actually, which is expected, and I think this is the right way to do.
Example of 2-new-ret – called only with source /etc/network/interfaces.d/* at the bottom of the file:
[
[
'lo',
'inet',
'loopback',
[],
'/etc/network/interfaces',
9
],
[
'enp0s5',
'inet',
'dhcp',
[],
'/etc/network/interfaces',
12
],
[
'enp0s5',
'inet6',
'auto',
[],
'/etc/network/interfaces',
14
],
[
'lo',
'inet',
'loopback',
[],
'/etc/network/interfaces.d/50-cloud-init',
8
],
[
'enp0s5',
'inet',
'dhcp',
[],
'/etc/network/interfaces.d/50-cloud-init',
10
]
]
I faced the same issue after the upgrade. I changed below line:
source-directory /etc/network/interfaces.d
to:
source-directory /etc/network/interfaces.d/*
and commented the other source-directory line. But it made my server inaccessible. I could connect to the server using KVM and reverted the line to what it was while keeping the second line commented. The server became accessible but the log file was getting filled again. I just downgraded to 2.001. I hope the problem is resolved.
That is not what I suggested. source-directory is the directive we don’t handle correctly, and your change made it break in the system network, too. So, your change makes it not work anywhere.
I said to change it to source /etc/network/interfaces.d/* because we correctly parse that (and it means the same thing).
Thanks Joe.
I don’t know if it is a good idea for me to upgrade again and test the solution as it is a production server. Do you suggest to upgrade or it is better to wait for the new version?
There is also a dot in your new post before the ending star character. Does it make a difference?
Sorry, you’re right. It’s just *. It’s a shell file glob, not a regular expression. I edited my comment. (but, the comment marked “Solution” was, and remains, correct)
1 Like
Hi @Joe ,
yesterday I had the same issue and reverted to the prevoius version of webmin.
The configuration that @virtualbob posted is the same that I have.
To have a context, it is a “Public Cloud” instance launched on OVH Cloud. Maybe it is an OVH custom configuration…
1 Like