Hide Forgot
Description of problem: I have a server that has no vga console, but NetworkManager still runs the network. This server also has a static ip. I used system-config-network to update the DNS Search Path which works until I reboot. In which case NetworkManager blows away anything that system-config-network set up. Version-Release number of selected component (if applicable): F13 How reproducible: always Steps to Reproduce: 1. Set up a box with a static ip 2. boot into that box 3. run system-config-network 4. Go into DNS tab 5. Update DNS search path 6. File->save 7. reboot box 8. update to DNS search path is gone Actual results: Update made by system-config-network is gone after reboot Expected results: the update should still be valid. Additional info: Found that if I update by hand the /etc/sysconfig/network-scripts/ifcfg-eth0 to add DOMAIN=... Then it works. This may be that system-config-network should update the scripts as well and this is not NetworkManager's fault. But the two should work nicely together. I can see how this can confuse, annoy and irritate customers doing this. Not everyone logs into a box via the console. Especially, servers need this functionality. I did not find any way to tell NetworkManager to update this for me via ssh. I had to spend hours searching around to even find the DOMAIN= name, as I first guessed at "DNS_SEARCH_PATH" as I can't find any good documentation on the ifcfg-eth0 formats.
It's kind of NM's fault, but it's really more the fault of the system not having a place to store this information out-of-band. The problem is that /etc/resolv.conf is a composite of information from various sources, DHCP, VPN, PPP, static, etc. And s-c-n doesn't have anywhere else to store that information, so it stuffs it into /etc/resolv.conf directly. When something comes along (NM) that needs to find that information, it has no idea whether that information is transient or was put there by you manually. The way this actually is handled (and has been for a long time) is to put the searches you want into the DOMAIN field of the ifcfg file for that connection, like this: DOMAIN="search1.foo.com search2.foo.com" and they'll show up in the 'searches' field in resolv.conf perfectly every time NM brings the connection up. We've got some explanatory text that gets put into /etc/resolv.conf when no nameservers are defined to explain a related problem, but perhaps we could put something into resolv.conf unconditionally about this sort of thing?
Yeah, documentation helps, especially when the documentation is near the location that needs the changes. I was just giving feedback to what I would think a customer would do as well, as it was what I would expect. If I use system-config-network and hit save, I would expect it to just work. Maybe if there was a way to detect that NM is running, and warn that NM may overwrite the saved settings on next reboot, that would have helped. A "See /etc/sysconfig/network-scripts/ifcfg-eth0" or something. And then in that file it would be nice to see what options are available, with a description of what they do. Sure having some comments in /etc/resolve.conf would have helped too. Thanks
I tried adding the DOMAIN=... setting on Fedora 14 but I got no DNS servers or search domains filled in, only the comments: # No nameservers found; try putting DNS servers into your # ifcfg files in /etc/sysconfig/network-scripts like so: # # DNS1=xxx.xxx.xxx.xxx # DNS2=xxx.xxx.xxx.xxx # DOMAIN=lab.foo.com bar.foo.com Is there a way to make this work so that only the search domains are modified?
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.