Has anybody gotten in a jam where the network interface stops working as if it was missing when it’s not? If so I’m eager to know the cause.
Sequence of events:
installed a Let’s Encrypt certificate with wildcard option
Postfix and Dovecot stopped after copying the certs
Dovecot restarted but Postfix refused
Rebooted but still no Postfix and Webmin’s start button threw numerous errors
realized there’s no network
Webmin’s network interface page showed no v4 IPs as active on eth0. It did show as active 127.0.0.1 on lo and the default IPv6 address on eth0. I couldn’t ping in or out. Even with an intact resolv.conf and ifcfg-eth0 file known to work, ifdown, ifup and nmcli commands bombed with “cannot load /etc/sysconfig/network-scripts/ifcfg-eth0”.
Eventually I got everything working again but it was tough.
I noticed the same issue with CentOS 8 (CentOS 8: DHCP acquired IPv4 address not shown in Web?Virtualmin) and your observation of the “cannot load…” message may explain why.
CentOS <=7 uses eth0 for the main LAN interface name, but CentOS 8 uses the name ens3 and Webmin 1.942 does not show the acquired IPv4 address (but does show the IPv6 address).
This has other effects too - Virtualmin does not find the default IPv4 address for virtual servers. Ilya explains how to overcome these issues in the post linked above, but it owuld be nice to have Webmin/Virtualmin notice the IPv4 address.
For search purposes the error was actually “Could not load file…” rather than “Cannot load…” Either way, I didn’t really learn much about the error before the interface bounced back. I have a different installation now but as I recall, eth0 came back to life after enabling every dynamic addressing scheme I could think of including the provider’s auto-config network tool. Once the v4 IPs showed up in Webmin I tailored the ifcfg-eth0 file back to static addressing and the server chugged along as if nothing happened. In all I think I rebooted five times.
While researching the problem I came across older Virtualmin posts about similar situations but with different errors.
“No Ethernet interface could be automatically found on your system”
“Virtualmin could not work out the system’s default IP”
and a log entry saying “parent interface eth0 does not exist”
I also came across the workaround of specifying a default server IP in Virtualmin instead of the interface. But like you said, that’s just a workaround for a lower level problem that I think can be attributed to the OS.
One interesting but dubious idea is that Network Manager may choke on loopback definitions in an interface file.
It’s dubious because I normally use DNS1=127.0.0.1 and let Network Manager write it to resolv.conf after a restart. When my busted network rebounded this DNS entry was omitted and I was using the provider’s resolvers, although I’ve since put the local resolver back without any new problems. Perhaps it’s better to manually edit them and leave NM out of it?
This specific error seems to trace back to older releases of CentOS/RHEL. So I’m going to chalk it up as a never-fixed bug and do what everybody else does: blame Network Manager and systemd and move on.
That’s interesting but I can’t get over thinking that the interface name change (from CentOS7 to 8) is a key factor.
I’m running VPS instances (not dedicated hardware) that must clearly use virtual Ethernet interfaces.
FWIW CentOS 8 installation was offered by the cloud provider, meaning I did not download and use the CentOS ISO.
So far, everything about the server works correctly, it is only Web/Virtualmin that does not “know” the IP address - and only IPv4 is unknown, IPv6 is correctly displayed. (But IPv6 appears rarely used).
So I looked to try to find why the interface name has changed. I don’t have a RedHat subscription to read https://access.redhat.com/solutions/3709641 which appears to promise an answer.
I first found an article about renaming the Ubuntu 16.04 network interface
which indicates that the starting name of eth0 is renamed to ens* by GRUB.
Sure enough dmesg on my CentOS 8 shows
dmesg | grep -i eth
[ 3.045187] virtio_net virtio0 ens3: renamed from eth0
and “ip a” displays the correct information for interfaces loopback and ens3.
which offers a comprehensive explanation of how to avoid renaming the interface.
But it leaves the question “Is it a good idea to change CentOS default behaviour?”
I would prefer to leave CentOS 8 alone and ask Webmin to report the interface(s) that it finds.
BTW does your CentOS have an interface named ens3 or might this vary depending on the underlying virtualization system?
I must be computing in a cloister because I didn’t even know about new interface names.
My Webmin server is a KVM VPS and the provider’s CentOS 7/8 Kickstart images are a bit different from official images, which I assume is the same at most server farms. Mainly ext4 instead of XFS; how kernels are provisioned; and the provider’s repos with alternate official mirrors.
Add to that traditional network nomenclature. My CentOS 8 interface has always been eth0 and ifcfg-eth* syntax is the same as CentOS 7. Using a raw disk image for installing official CentOS is an option so I reckon that’s when I might run into the interface name change. Some providers must be holding on to conventional names for backward compatibility, and/or to maintain forward-compatibility with auto-config features.
I usually feel more in control with static addressing but sometimes I think about going full DHCP and SLAAC and throw caution to the wind. If Webmin is agreeable to dymanic changes, resolvers in particular, I think I could get into it.
Thanks for the heads up about virtio ens3 eth0, this info is definitely something to keep in mind down the road. I’d like to get my hands on that Red Hat article but the other links are a good start.
Edit:
The only difference with virtualization types I’m experienced with are Virtuozzo and OpenVZ. I think they used ‘vnet’ to name the interface. Are these VMs still a thing? because that was 15+ years ago before Xen and KVM changed everything with autonomous kernels and such.
I used the term “virtualization” loosely! I’m using vultr and KVM is the underlying system.
I chose to go with DHCP and SLAAC since the IP addresses are pretty much guaranteed and it makes it eeasier to move the instance if I ever need to.
I did not even think that the provider’s image might not be the stock ISO, but I see that it’s probably true. My CentOS8 is also ext4 rather than XFS whcih I believe is the default. Thanks for pointing it out.
Now on to my other project of LDAP in readiness for trying to find a simple CalDAV/CardDAV server!
Thanks for the tip. I was thinking of Radicale, easier now that CentOS 8 has Python 3, but I’ll look at Nextcloud. I’ll stop now since I’m getting off topic.