GNOME Bugzilla – Bug 563654
[enh] dispatcher event for DHCP lease change
Last modified: 2011-06-15 09:09:57 UTC
dhclient has a feature allowing people to update DNS servers by manually sending their fully qualified domain name to the DNS server, this is configurable by adding "send fqdn*" to dhclient.conf. However this feature will not work when using NetworkManager. This has a simple explanation, yet maybe not a simple solution. Basically, this is how it works : dhclient runs, gets its lease from DHCP server, executes dhclient-script (this is the important part), while dhclient-script is being executed, dhcilent itself "pauses" and waits for dhclient-script to finish. When the dhclient-script is finished with all of what it does, creating resolv.conf among other things, dhclient continues from the "pause" and now tries to update the DNS server with the fqdn options you have specified in the dhclient.conf. However, if NetworkManager is being used, dhclient will not "pause" and create resolv.conf, it will just execute, get the lease, run the nm-dhcp-client.action and then try to update the dns and finish. This is causing the problem. Because NetworkManager hasn't created the resolv.conf YET, the DNS update from dhclient will always fail. (because it doesn't know which DNS to try to update, and will result in a error "connection refused") NetworkManager is always creating the resolv.conf after dhclient has finished and therefore this feature of dhclient will fail. (always) It can be discussed why this update is being done through dhclient and that it should be done from somewhere else, however this is a feature that dhclient has and i therefore think that it should be available when using NetworkManager too. Going around this issue may be possible by adding dispatcher scripts that manually, through nsupdate, do the updates to the DNS, however that is not a good solution becouse there is no way of trigging these scripts when the lease gets updated. And, in my case, that means that i have no way telling the DNS server to refresh my entry when the dhcplease gets renewed, that will cause the entry to be deleted after 2 days (because the dns-server deletes the entries if not updated in a certain time) and therefore it's not a workable solution. (for me) I do understand that this setup may not be that common and optimized, however this is the setup we have at our workplace and it works fine if dhclient is handled right. Best Regards. Patrik Martinsson, Sweden.
Quick question: does 'nsupdate' do anything you need?
Yes, manually update the dns through 'nsupdate' works flawless. However if you are suggesting to use 'nsupdate' scripting-wise i think that is the wrong way to go. And, if i script it i need someway to determine when the lease gets renewed, which NetworkManager do not provide, if i have understood it correctly ? 'nsupdate' will only work thou if there is an resolv.conf present of course.
right, what I'm suggesting here is two things: 1) a new dispatcher event when the DHCP lease changes 2) you write a dispatcher script that uses nsupdate when the DHCP lease changes would that work?
Yes, that would work. I still have to say i would preferably seen dhclient do the work, since it inbuilt in there. However if that is not possible, this is a solution i can live with. /Patrik
Created attachment 168262 [details] [review] adds a dispatcher event on dhcp_renewal state.
Hello, The patch above solves this issue. It's a tiny patch that adds a dispatcher event on the dhcp_renew state and updates the manpage accordingly. This is useful if you want to for e.g. use nsupdate to dynamically update dns-entries. You probably want to do that everytime a lease is renewed. What you also could do (what i used to) is to use a cron-job that runs with tighter interval than the dns-server uses to hold entries, however that method is quite messy and not preferred. I'm no programmer so go easy on me if I missunderstood anything in the coding part. (one line) :) /Patrik Martinsson, Sweden.
9b54cb1ec617ea8bff86d6d74c06cef5a51e26c9 (master) ca2dfc0ae7d1d935c6f378ae090d8681190b37a0 (0.8.x) I changed the events to dhcp4-change and dhcp6-change and moved the event emission after the new lease has actually been applied to the device, but otherwise it's basically the same patch. Thanks!
FYI this change is approved for RHEL 6.1.
Ah, thats great to hear ! Thanks, keep up the good job.
Hello again Dan, I hate to open this again but this doesn't seem to work as expected. Test case, - I've set the dhcp-lease time to 60 sec. - I've placed a script called dhcp-lease.sh /etc/NetworkManager/dispatcher.d/ containing, #!/bin/bash echo "$1 => $2 => $(date)" >> /tmp/test-case - I've started the NetworkManager deamon with NetworkManager --no-daemon --log-level=DEBUG - I'm tailing the /tmp/test-case log with, tail -f /tmp/test-case. Here's what's happening, At connection NetworkManager shows this, DHCPREQUEST on eth0 to 255.255.255.255 port 67 (xid=0x278f7cc1) DHCPACK from XX.XX.X.X (xid=0x278f7cc1) bound to XX.XX.X.XX -- renewal in 29 seconds. NetworkManager[25350]: <info> (eth0): DHCPv4 state changed preinit -> reboot NetworkManager[25350]: <debug> [1308125937.632588] [nm-device.c:1397] dhcp_state_changed(): (eth0): new DHCPv4 client state 7 NetworkManager[25350]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) scheduled... NetworkManager[25350]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) started... NetworkManager[25350]: <info> address XX.XX.X.XX NetworkManager[25350]: <info> prefix 16 (255.255.0.0) NetworkManager[25350]: <info> gateway XX.XX.X.X NetworkManager[25350]: <info> hostname 'XXXXX.XX' NetworkManager[25350]: <info> nameserver 'XX.XX.X.XX' NetworkManager[25350]: <info> nameserver 'XX.XX.X.XX' NetworkManager[25350]: <info> domain name 'XXXX.XX' NetworkManager[25350]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) scheduled... NetworkManager[25350]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) complete. NetworkManager[25350]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) started... NetworkManager[25350]: <info> (eth0): device state change: 7 -> 8 (reason 0) NetworkManager[25350]: <info> Policy set 'System eth0' (eth0) as default for IPv4 routing and DNS. NetworkManager[25350]: <info> Activation (eth0) successful, device activated. NetworkManager[25350]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) complete. And the log looks like this, eth0 => up => Wed Jun 15 10:18:57 CEST 2011 After 29 sec (when lease is beeing renewed) NM shows following, DHCPREQUEST on eth0 to XX.XX.X.XX port 67 (xid=0x278f7cc1) DHCPACK from XX.XX.X.XX (xid=0x278f7cc1) bound to XX.XX.X.XX -- renewal in 26 seconds. NetworkManager[25350]: <info> (eth0): DHCPv4 state changed reboot -> renew NetworkManager[25350]: <debug> [1308125966.38565] [nm-device.c:1397] dhcp_state_changed(): (eth0): new DHCPv4 client state 8 NetworkManager[25350]: <info> address XX.XX.X.XX NetworkManager[25350]: <info> prefix 16 (255.255.0.0) NetworkManager[25350]: <info> gateway XX.XX.X.XX NetworkManager[25350]: <info> hostname 'XXXXX.XX' NetworkManager[25350]: <info> nameserver 'XX.XX.X.XX' NetworkManager[25350]: <info> nameserver 'XX.XX.X.XX' NetworkManager[25350]: <info> domain name 'XXXXX.XX' And the log looks like this (as expected), eth0 => dhcp4-change => Wed Jun 15 10:19:26 CEST 2011 After the 26 seconds (when lease is beeing renewed again) NM shows following, DHCPREQUEST on eth0 to XX.XX.X.XX port 67 (xid=0x278f7cc1) DHCPACK from XX.XX.X.XX (xid=0x278f7cc1) bound to XX.XX.X.XX -- renewal in 30 seconds. And in the log, nothing shows up. After the 30 seconds (when lease is beeing renewed again) NM shows following, DHCPREQUEST on eth0 to 172.16.0.150 port 67 (xid=0x325c680c) DHCPACK from 172.16.0.150 (xid=0x325c680c) bound to 10.64.7.109 -- renewal in 25 seconds. And again, in the log, nothing shows up, no matter how many renewals I go through. Now, my guess is, without having looked at the code, that NM triggers on dhcp-state-changes, which is kind of what we want, but not necessarily always the case. It looks like NM doesn't trigger on eg. "renewal" if the previous state was "renewal", since NM only triggers on a state change, however this is just a pure guess from my side atm. Summary, on why this feature is needed, This feature was implemented due to that it was not possible (in earlier versions) to update a dns when using NM as you used to be able to do when only using dhclient. However I do recall that I tried this a couple of months ago and if I remember correctly I think it worked as expected. So, therefore, this feature may not be for everyone (since it seems to work just fine, again, if I remember correctly, with the inbuilt "send fqdn.fqdn" from dhclient, *if* you configure it correctly). *However again*, the inbuilt feature of dhclient to update the dns only works if the dns allows insecure updates *or* secure updates with TSIG, this is probably enough for most people, *but* if you are in a Windows environment. and the dns require a GSS-TSIG (kerberos) update, you're not able to use this feature, and *therefore* you would need another way (eg. nsupdate-gss.pl from samba) to update the dns-entry, and it's likely that you would want to do that at every lease-renewal (so you don't need to have a cron-job doing it eg. every 12 hour). Best regards, Patrik Martinsson, Sweden.