Description of Problem: neat writes the existing resolv.conf into the default Profile the first time it runs. This resolv.conf is then applied across the board even if the interfaces are changed or receive a new DHCP configuration. This is probably a combination of the initscripts and neat's use of the default profile. An example of this is the resolv.conf is set once, and reappears even after the machine has been moved and received a new DHCP configuration. Essentially, neat/initscripts is not allowing DHCP to do its job setting the nameserver configuration. How Reproducible: Always Steps to Reproduce: 1. Start up neat, noting that the existing resolv.conf is copied into the default profile. 2. now shut down, move the machine, get a new DHCP configuration. 3. Note that while the IP address is correct, the resolv.conf is the old one from the previous configuration. Actual Results: resolv.conf becomes static. Expected Results: DHCP should be able to replace/modify resolv.conf as necessary, that is part of its job. Additional Information:
An addendum to this bug -- I cannot make neat accept a DHCP delivered resolv.conf at all. Apparently, after a resolv.conf has been written to the default profile, dhcpcd is always run with the flag that prevents the writing of /etc/resolv.conf, even if no resolv.conf exists anywhere. The only way to recover from this scenario is to run dhcpcd manually, get the file in place in /etc/resolv.conf, delete the default resolv.conf, and then run neat to copy the correct resolv.conf to the default profile. This sets it again for this setting, but you have to do this every time to get the correct resolv.conf in place for each DHCP connection.
This defect is considered SHOULD-FIX for Fairfax.
This bug is related to the usernetctl problem and other tools who require the files generated by neat not to be symlinks. As we will switch to either hardlinks or to real copies of the files this should be fixed in the next version as well. I'll mark it as DUPLICATE of another symlink bug of neat, although it is only similar, not the same... Read ya, Phil *** This bug has been marked as a duplicate of 51081 ***