2

Okay community, let's see if we can figure this one out, cause I'm out of answers.

Where I work I am setting up a bunch of RedHat Enterprise Linux servers. There is a collection of RHEL6 and RHEL7 servers.


On the RHEL6 servers, I am using the standard network configuration tool by configuring it in /etc/sysconfig/network-scripts/ifcfg-eth0 and a dhclient configuration file in /etc/dhclient-eth0.conf. Everything works properly, I am assigned the custom FQDN by our DNS servers (e.g. hostname.ad.company.tld) and when the DHCP lease is up, it is renewed automatically.


Here is the issue:

In RHEL7, NetworkManager is enabled by default. On our Kickstart, I have removed NetworkManager and went back to configuring network and dhcp the way it is done in RHEL6. All of the configuration is the same (sans using /etc/sysconfig/network-scripts/ifcfg-ens192 instead of eth0) and works fine for the first DHCP lease.

Once the lease is up, it seemingly doesn't renew it until I issue a systemctl restart network command.


I have looked and looked and I am coming up short. There must be something different in RHEL7 or something not configured when you disable NetworkManager, but I cannot for the life of me figure it out.

Anyone have any thoughts?

As I know these usually help, I'll post my RHEL7 configuration files, and the snippet from the logs where it loses the DHCP lease.


/etc/sysconfig/network-scripts/ifcfg-ens192

# Generated by dracut initrd
DEVICE="ens192"
ONBOOT=yes
NETBOOT=yes
UUID="c23045ff-7b60-4dff-b052-30a61923a852"
IPV6INIT=yes
BOOTPROTO=dhcp
HWADDR="00:0c:29:b6:d8:cc"
TYPE=Ethernet
NAME="ens192"
NM_CONTROLLED=no

/etc/dhclient-ens192.conf

send host-name "hostname";
send fqdn.fqdn "hostname.ad.company.tld";
send fqdn.server-update off;

/var/log/messages

Jun 27 23:06:09 sa-kbwiki01 avahi-daemon[591]: Withdrawing address record for 129.89.78.221 on ens192.
Jun 27 23:06:09 sa-kbwiki01 avahi-daemon[591]: Leaving mDNS multicast group on interface ens192.IPv4 with address xxx.xx.xx.xxx.
Jun 27 23:06:09 sa-kbwiki01 avahi-daemon[591]: Interface ens192.IPv4 no longer relevant for mDNS.
cjmaio
  • 31
  • 1
  • 1
  • 3
  • That log snippet doesn't show your DHCP lease being lost. Keep looking, there should be other more relevant entries. – Michael Hampton Jul 02 '14 at 15:24
  • From what I recall hearing pre-launch is that networkManager is not the same PoS it was years ago and Red Hat more or less forces you to learn to live with it. Having said that, the [documentation](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Configure_IP_Networking.html#sec-When_to_Use_Dynamic_Interface_Settings) mentions that NetworkManager has been made responsible for starting dhclient, so it could be that without NM, dhclient is run with the `-1` option and doesn't become a daemon. – HBruijn Jul 02 '14 at 15:36
  • @MichaelHampton I do not see anything else in /var/log/messages. Other things that use the network are operating fine until that line, at which point everything starts saying no network available. – cjmaio Jul 02 '14 at 15:59
  • @HBruijn That gives me somewhere to start... though when doing a `ps aux | grep dhclient` I do see that the `-1` flag is being set... is there anywhere else that dhclient would log to other than `/var/log/messages`? – cjmaio Jul 02 '14 at 16:00
  • Yeah, NM is fairly safe to use these days unless you have a _very_ complicated setup. I do wonder why you're running Avahi though. – Michael Hampton Jul 02 '14 at 16:01
  • @MichaelHampton Avahi is started/installed by default when installing Samba. The reason I switched from NM was because how the IT group above us has the DHCP servers setup, I need to request to have `hostname.ad.company.tld` instead of the default, `hostname.internal.company.tld`. I usually do that by setting the dhclient congiuration, which got ignored when using NetworkManager. By chance, I disabled NetworkManager and got that working, so I've been doing it ever since. – cjmaio Jul 02 '14 at 16:05
  • Well, here's some more information. dhclient is started properly with the `-1` flag... but at some point is dying. On a machine that had already lost network connectivity, I ran `ps aux | grep dhclient` and it saw nothing. After restarting network, I ran the command again and saw dhclient with the flag. So at some point, dhclient is dying. Searching `/var/log/messages` for that seems to turn up nothing, eventually I just see nothing for dhclient in the logs. – cjmaio Jul 02 '14 at 16:16
  • The manual isn't very clear on the result of setting the `-1` flag, other than it will only try once to get an ip-address. Does dhclient still renew the lease or will dhclient stop after the lease expires? I don't know... – HBruijn Jul 02 '14 at 16:33
  • Are the machines Physical or Virtual? – Itai Ganot Jul 17 '14 at 07:14
  • @ItaiGanot they are virtual machines, in an ESXi environment. – cjmaio Jul 17 '14 at 18:48
  • If you reboot the problematic virtual machine, does the network interface start successfully when the machine is back up? – Itai Ganot Jul 18 '14 at 12:48
  • @ItaiGanot - correct – cjmaio Jul 30 '14 at 21:49

2 Answers2

1

I ended up figuring out the issue.

There is a flag you can set in your kickstart file, biosdevname=0, which is supposedly supposed to revert RHEL7 into using the old ethernet naming standard, e.g. eth0

It didn't do that, seemed to have no effect. I thought I had removed it, but I guess not.

It must have told the installer to setup things incorrectly. When I removed that from the kickstart, and built the machine again, I no longer had the issue of dhclient dying.

cjmaio
  • 31
  • 1
  • 1
  • 3
  • 1
    It _also_ has to be added to your kernel command line in your grub configuration. I don't know if anaconda does this for you. – Michael Hampton Jul 30 '14 at 22:00
1

To revert to regular interface names, it's as simple as

sed -i '
  /CMDLINE/s/ /net.ifnames=0/
  ' /etc/default/grub
grub2-mkconfig -o /boot/grub2/grub.cfg
init 6

Don't look at the /etc/grub tree, though: it's now been made horrendously complicated so it's a risky toxic mess like systemd.

user2066657
  • 336
  • 2
  • 13