Auto network configuration

This topic has come up before peripherally but I don't see a clear and final directive on the topic. In Debian/Ubuntu, the NIC ID eth0 was replaced long ago with ens3, but ISPConfig still shows "Do not enable this option if your network interface is not eth0". That message is cryptic and perhaps misleading. Let's improve on it.

In the doc we see this:

Network Configuration: If you check this, ISPConfig will automatically configure your system with the network settings from the IP Address, Netmask, Gateway, Hostname, and Nameservers fields. It will also automatically configure all IP addresses that are defined under System >System > Server IP addresses. Please note that this automatic network configuration works only on Debian/Ubuntu and only if you have one network card which must be eth0. It is recommended to not check this checkbox and configure your network settings manually.​

I have been struggling for several days with network interfaces randomly dropping. I stumbled on this thread which describes a similar issue, as I was trying to figure out if this is caused by eth0/ens3 being hardcoded somewhere (in ISPConfig or anywhere else). I'm not going to change my NIC ID as that could cause other problems. I turned on the auto net configuration early in testing. It butchered my config files which took a long time to figure out and fix.

"Ah" you say, "the doc does tell us 'It is recommended to not check this checkbox and configure your network settings manually.', so why did you enable it?"​

Well, since I do have Ubuntu with one NIC, and the doc is years old, I thought/hoped that the doc and UI text were simply out of date with the current functionality.

So, in the productive interest of ensuring clear and accurate documentation in the future:

- Is "eth0" still a requirement for Debian/Ubuntu? Or is the default "ens3" acceptable?

- Is auto-configuration actively being improved?

- Is auto-configuration still actively discouraged?

- Why is this warning "It is recommended to not check this checkbox and configure your network settings manually" only in for-fee documentation and not on the page where someone can easily click it? Queue HHGTTG "the plans have been available in the local planning office..." If the checkbox does bad things in a new installation, why is it still there?

- I'm wondering if that checkbox should simply be removed, given that as documented it only applies to a limited subset of installations, and it doesn't seem to work for that subset anyway. I mean, there have been a lot of changes related to DNS, resolv.conf, systemd-resolve, etc. Rather than being a simple checkbox, maybe it should be a link to a script where the top comments say "This is what we think should be done to auto-config your system using parameters defined in ISPConfig. Modify as required, implement at your own risk, and please MR helpful improvements." The difference between that and MR's to ISPConfig core is that such a script would not be directly integrated with the package.

If the answer to these questions is "just look in the forum, it's been discussed", as I've said, I've been struggling with issues for days, setting up DNS/BIND9, dealing with resolve conflicts, checking sync between NS1/NS2, checking ufw and external firewall. I'm literally working on this stuff every minute of my day. If I've missed notes on this topic, I apologize. But in all candor, I really wish the answers were already in current ISPConfig docs so that I didn't need to read the interwebs to find hints about every detail. And yes, I understand ISPConfig is responsible for setting configuration changes, not for the effect of those changes, admin-inflicted issues, or component failures. But ISPConfig does a lot more for us under the covers - that's it's value. The problem is that there is little documentation to explain what it's doing and why. It's a black box that we need to trust, and then read the code ourselves for more details. I'm trying to get some information from outside of the code, outside of random forum posts, and into someplace accessible to users ... like a user guide. Thanks for your patience and feedback.

 

It is not default. The old eth0, eth1 etc system was replaced with the current system to ensure interface name stays the same. WIth this new system, rebooting or adding a new interface card does not change the interface name. The interface name is constructed from constant attributes of the devices, I'm sure it is explained in detail somewhere but I do not know how it works.
Anyway, the interface name on your particular system may well be ens3, but on some other system it is something else. For example on my desktop computer it is enp35s0.

 

Thanks for the clarifications. Personally I think it's bad UX to make it look like a feature might be available to someone if they do something to conform. It unnecessarily creates a potential for issues.
Here's a great way to solve this with no pain. Set network_config_warning_txt in Languages:

This is easily changed by sites that choose to support the feature. I have not yet seen detail about what happens during an update to text modified in Language settings, if there is a language merge on update, etc.

For an even more UX-friendly approach, perhaps a prompt could be added to the install/update that asks if that feature should be enabled. With this, only sites that want the feature will get it, and all others will be discouraged with the message above if they set it.

HTH

 

About my DNS issues, they are all now resolved. (LOL, see what I did there?)
Yeah, this is all related to these network settings. I'm not asking for answers in the following, just explaining a few of the challenges I had:

For nameservers, I've had to figure out if or how ISPConfig modifies files related to resolv.conf for a system configured for DNS - and what happens if the resolvconf is and is not installed.

Also, the nameservers for my primary system are 8.8.8.8 , 8.8.4.4 while for all other systems including secondary DNS the nameservers are 10.0.0.9 , 10.0.0.13 , 8.8.8.8 , 8.8.4.4
But ISPConfig doesn't modify /etc/bind/named.conf.options with that detail. I still need to pull the plug on my NS1 to see if NS2 resolves when its forwarders show 127.0.0.53 ; 8.8.8.8 ; 8.8.8.4.
Under the DNS tab it looks like ISPConfig is working with BIND9, but comparing my options files in NS1 and NS2 it's apparent that it's not, at least with details like dnssec and recursion. And BIND logging is not defined or rendered in ISPC ... OK, I might take a shot at adding that as an enhancement, because without logging data it's tough to know if external requests are even hitting the server. (Tip: journalctl)
I'm still researching nuances of when system-resolved, resolv.conf, /etc/hosts, and other name resolution components are used in an environment with a secondary DNS ... and important for this discussion, what ISPConfig does and doesn't do in this topology. And completely on-topic with this thread, I did have to recover from checking that box in a test system before I knew more about this topic. (Yeah, I know, mea culpa...)

The settings page suggests two options for a firewall, ufw or bastille. It does not include an option to disable the selected option. There was a question as to whether a default ufw installation allowed both TCP and UDP on port 53. Part of my problem was that my higher-level firewall permitted TCP but wasn't set to allow UDP. I didn't realize this until I turned off ufw and still had DNS failures. And I have to remember to check the status of ufw because it's not included in the Monitor.

None of this is a criticism. I'm loving ISPConfig. I'm pointing out stuff that you guys are very familiar with, that works for you, but which is still cryptic and time consuming for someone else getting started. I think this noob perspective is helpful because when you lose it you start to get aggravated with noob questions in this forum, and that's not good for anyone. (We can all get aggravated with people who expect to be a sysadmin by loading software without doing their homework ... oh, and people who click things without knowing what they are. )

The effort that @Taleman put into his DNS tutorial IS valuable, as are all of his forum posts helping people with fixing DNS issues!! (I know he's questioned the value of taking the time to write for people who don't read ... don't we all...) I need to read it a few more times now that I've been through all of this. In all of this, I'm learning a ton about details that I've not had to address in the past. And I see places where I might like to contribute to improving ISPConfig in code or docs where I've stumbled ... if I can just get my damned network setup and free up some time.

Thanks guys!

 

Maybe I'm missing a key point. What's special about "eth0"? Or was that just another way of clarifying when the Jessie-era underpinnings were in place to support the functionality? If someone changes the device ID from ens3 to eth0, is this feature "supported"? From what @till just said, no. If we're talking about a break between Jessie and Stretch (and whatever Ubuntu version that implies) and not "eth0" then this all makes more sense. I've not seen that point actually stated anywhere.

I had the impression that the switch, from persistent interface names (eth0) to predictable (location-based), was older, but it happened starting with Stretch in June 2017. So now I understand that this still applies to a lot of systems - But not new systems. This Auto Network Configuration option has no meaning in a new installation on a system installed after 2017. Maybe that's the point of the warning, but ... why not just say so?

Great info on this topic here: https://wiki.debian.org/NetworkInterfaceNames

Thanks for the discussion