NetworkManager does not use dhclient-exit-hooks.d

I can confirm this bug in intrepid.
I'm using a similar script in /etc/dhcp3/dhclient-exit-hooks.d to make a ddnsupdate in my network and it is no more executed in intrepid. It was in gutsy and hardy.
Removing network-manager or managing the relative interface in /etc/network/interfaces solves the problem.
To reproduce the bug it is sufficient to activate the debug script in either /etc/dhcp3/dhclient-enter-hooks.d or /etc/dhcp3/dhclient-exit-hooks.d. The /tmp/dhclient-script.debug file is not created.

why do you need this? would using resolvconf and its hook mechanism enough? we support resolvconf properly in intrepid.

My use case: Johan needs to access his laptop for doing backups and for remote desktop services. :)

I can think of a few reasons why resolvconf is suboptimal:
- It is not the standard/recommended solution for DNSSEC, which is optimally integrated with dhclient
- It requires additional packages for something that should be working already
- It is not supported by canonical

Also, a few questions arise, mostly from my rather outdated experiences with resolvconf:
- Would it require modifying the script?
- Would it work with both DHCP and PPP (see my side note)?
- Are all necessary variables available to the script?
- Ease of use: can I simply drop a similar script (which adapts to any host) in a folder?
- Is it aware of DHCP lease changes (reports new IP) or is it only concerned with DNS servers changes?

Resolvconf may well be a good workaround.

Confirming this bug on KUbuntu Intrepid AMD64.

This also breaks automatic setting of WINS servers (/etc/dhcp3/dhclient-enter-hooks.d/samba), which is necessary for proper SMB networking if the network setup is non-trivial. In my case, I have a Samba server in a different subnet that isn't accessible unless the 'wins server' option is set in the smb.conf, either manually or by the script above.

I googled around for a bit, but found nothing on how to replicate this functionality with resolvconf.

NM runs dhclient with its own configs (from 'ps'):
/sbin/dhclient -d -sf /usr/lib/NetworkManager/nm-dhcp-client.action -pf /var/run/dhclient-eth0.pid -lf /var/run/dhclient-eth0.lease -cf /var/run/nm-dhclient-eth0.conf eth0

ifup runs dhclient with the defaults:
dhclient3 -e IF_METRIC=100 -pf /var/run/dhclient.eth0.pid -lf /var/lib/dhcp3/dhclient.eth0.leases eth0

Looking at the differences and named files, we can tell the following relevant things:
- NM uses a different script file, which is an ELF executable - NOT OK
- NM uses a different config file, which is created from /etc/dhcp3/dhclient.conf - OK

That gives us no simple solution to change NMs behaviour. I consider the functionality to be broken and a regression looking at the networking as a whole. After all, it worked before.

Now that it has been shown in detail, and it is easy reproduce, it would be nice to get some input from the devs? Confirm? Importance?

Three confirmed reports.

It turns out NetworkManager has its own mechanism for this. It took me a while (almost no documentation...) to figure it out.

NM uses a dispatcher much like dhclient-exit-hooks.d. Instead of separate directories, the script is always started, and given two arguments: interface and action (which is one of up, down, vpn-up or vpn-down). Everything else is available as environment variables. The scripts are located in /etc/NetworkManager/dispatcher.d and run in alphabetical order.

That part was easy, so we can basically migrate any scripts to follow the new behaviour. It may even simplify things by consolidating ppp/vpn/eth/whatever actions. I updated my script accordingly.

These environment variables were given in my case (anonymized).
IP4_DOMAINS=domain.name
DHCP4_SUBNET_MASK=255.255.248.0
DHCP4_DOMAIN_NAME=domain.name
IP4_NAMESERVERS=ns1-ip ns1-ip
DHCP4_DHCP_SERVER_IDENTIFIER=dhcp-server-ip
DHCP4_DHCP_LEASE_TIME=7200
DHCP4_EXPIRY=1229611878
DHCP4_NETWORK_NUMBER=network-ip (first in block, the one often ending with .0)
IP4_NUM_ADDRESSES=1
DHCP4_ROUTERS=gateway-ip
IP4_NUM_ROUTES=0
IP4_ADDRESS_0=my-ip/netmaskbitcount gateway-ip
DHCP4_BROADCAST_ADDRESS=broadcast-ip (last in block, the one often ending with .255)
DHCP4_IP_ADDRESS=my-ip
DHCP4_DHCP_MESSAGE_TYPE=5
DHCP4_DOMAIN_NAME_SERVERS=ns1-ip ns1-ip
PWD=/
DHCP4_TIME_OFFSET=7200

It may be possible to simply link the script to the dispatcher, or write a simple wrapper which renames variables for it. But it sure breaks any setup relying purely on dhcp or ppp hooks.

Johan Ehnberg wrote:
> My use case: Johan needs to access his laptop for doing backups and for
> remote desktop services. :)
>
> I can think of a few reasons why resolvconf is suboptimal:
> - It is not the standard/recommended solution for DNSSEC, which is optimally integrated with dhclient
> - It requires additional packages for something that should be working already
> - It is not supported by canonical
>
> Also, a few questions arise, mostly from my rather outdated experiences with resolvconf:
> - Would it require modifying the script?
> - Would it work with both DHCP and PPP (see my side note)?
> - Are all necessary variables available to the script?
> - Ease of use: can I simply drop a similar script (which adapts to any host) in a folder?
> - Is it aware of DHCP lease changes (reports new IP) or is it only concerned with DNS servers changes?
>
> Resolvconf may well be a good workaround.
>
>
if the resolvconf abilities are not enough you can also stuff in a NM
dispatcher.d script (see: /etc/NetworkManager/dispatcher.d/)

Alexander,

My question is, why is NM presuming to bypass the standard dhclient actions? There are other packages that have specifically been integrated with dhclient, and this integration is completely ignored when using NM. If the /sbin/dhclient-script default action is unsuitable, shouldn't we try to fix that - reducing complexity and divergence betwen the NM and non-NM use cases?

I ran into this bug when trying to figure out why my DHCP-provided WINS settings were not being recognized by my laptop. There are also hooks to tell the ntp package to use a local ntp server; a total of 7 different packages have hooks for this interface. The interface exists for a reason, it would be nice to not have to reimplement the axle.

Also, having a look at the environment variables exposed to scripts in /etc/NetworkManager/dispatcher.d, the WINS variables are *not* exposed, only the basic TCP/IP options are; so this doesn't help samba or ntp.

I encountered this bug too when debugging why the ntp information from the DHCP server was ignored by the clients. Since all the information from the DHCP server is not propagated by NetworkManager, the /etc/NetworkManager/dispatcher.d/* scripts do not help. All the necessary scripts/config already exists in /etc/network/*, dhclient works well with them. I don't see the point that NetworkManager duplicates/bypass this functionality, it should be modified to manage the standard scripts. It would make integration of packages easier instead of having to deal with both the "standard scripts" and the "NetworkManager scipts".

I agree with Denis Benoit's last comment, and I have a little more to add. The reason that /etc/NetworkManager/dispatcher.d/* scripts do not provide the wealth of information as input that a dhclient-enter/exit-hook script can take. According to the NetworkManagerDispatcher man page, only two parameters are given: network interface name., and "pre-up/post-up".

Meanwhile, the dhclient-hooks have access to a plethora of variables from the dhcp server, such as the NTP servers. I have scripts, for example, that set up ntpdate correctly based on the NTP server given from DHCP. This won't function now with Network Manager.

Also, Denis' point can't be overstated: NetworkManger is causing a regression on well-known working functionality without a justification. Is there really some reason that NetworkManagerDispatcher can't ensure that old scripts aren't broken?

Finally, please note that while the ticket summary mentions DNSSEC specifically, it is not the only program impacted by this. I suggest removing specific reference to DNSSEC from the summary to help prevent possible duplicate bug filings.

A possible workaround, as well as additional confirmation of the bug, is mentioned here: http://www.webtatic.com/blog/2009/03/workaround-so-networkmanager-runs-dhclient-hooks/

From the site:

"Sadly NetworkManager fails to call any hooks on dhcp renew, which is what my script needed. It only calls its hooks, which are located in /etc/NetworkManager/dispatcher.d/, when the interface is brought up or down.

I’ve made a modified dhclient-script, which when set as the dhclient script, will call the enter hooks, then call NetworkManager’s dhclient script, then call the exit hooks. This effectively gives the intended effect of allowing NetworkManager to run with the old dhcp hooks available."

He then attaches the following script.

Summary changed to reflect the broader impact of this bug.

I have to chime in here. It's entirely frustrating when a good, working, API stablizes only to be discarded because something supposedly shiny and new comes along. That would be all well and good except new is not so shiny.

Seriously folks, as others have said, the dhclient script and it's run-parts dir are a well accepted standard which many software packages have bought into to make dynamic host configuration both robust and reliable. And now network manager comes along with an immature, less-featureful interface and you want to throw away the years of investment into dhclient's script?

To what gain? That's what I really want to know. You'd get no argument from me about supplementing the dhclient standard with network manager if you wish, but it's wholly unacceptable to simply drop the dhclient script standard and all of the functionality it brings to the table with the neutered, watered down network manager "dispatch" functionality.

This appears to be yet another case of Ubuntu looking to make change just for the sake of making change, without fully thinking through the ramifications of the change. This is the whole "update-manager"/libnotify debacle all over again. Are we going to also have to wait 3 releases or more to achieve the same functionality that was prematurely removed?

If you guys want to change things, assuming the final product of the change is progress, that's fine and dandy, just, please, stop lumbering your users with half-baked changes and don't foist them on your users until they are feature complete. Nobody wants a car with no engine, or no wheels, etc. When the feature is complete, then and only then, introduce it into stable releases.

With all respect for the good work that's gone into NetworkManager, I have to agree with Brian. Every other package that provides a dhclient script is potentially affected by this problem and may or may not be able to provide an equivalent NetworkManager dispatch script. A quick check of the affected packages in Jaunty gives:

$ apt-file -x search 'etc/dhcp3/(enter|exit)-hooks.d' | sed -e 's_:.*__' | sort -u
avahi-autoipd
dhcp3-client
ebox-network
ntp
ntpdate
resolvconf
samba-common
sendmail-base
whereami

At least some of these are going to fail to work with NetworkManager. For one example of that, see https://bugs.launchpad.net/ubuntu/+source/whereami/+bug/486406 . And of course that doesn't even address all of the custom dhclient hook scripts developed by sysadmins, such as in the original report here, all of which will break with NetworkManager.

Anyone who runs into this problem and searches for a solution pretty quickly encounters the workaround mentioned in #16. It appears to be widely used. Is that how we want people to be operating, by applying someone's workaround script that they find on the net? And at the same time, doesn't it suggest that there should be a straightforward fix?

Thanks for your work on NetworkManager.
Andrew.

We are approaching Lucid quite quickly and this bug has gone 3 months without an update.

Can we please get this issue resolved? You have broken very useful functionality for a lot of users. It would be nice to get it restored again.

With this stupid change, network manager doesn't even use the "ntp server" variable sent to it from the dhcp server.

C'mon folks. This is basic, really basic, autoconfiguration functionality. It makes ntp in environements where they don't let machines communicate outside of the network useless, as the hardcoded value in /etc/ntp.conf no longer works in such environments.

Sure, I could simply change the value that goes into /etc/ntp.conf but that gets awfully tiresome on a laptop that roams from one network to another and needs a different value for each network. This is *exactly* why DHCP has the ability to give this information to the client. Except that Ubuntu/Canonical, in their infinite wisdom have decided that this use-case is stupid and just neutered it.

Not everyone works is wide open Internet environment folks. The sooner you can learn that and remember it when you are making infrastructure-impacting changes, the better your product will be for everyone.

Brian,

I take NM and correct application behavior as importantly as you do. It *is* frustrating to see things not working properly, and while I am slightly biased, perhaps I can offer some details here.

Ubuntu and Canonical didn't exactly make the decisions regarding how NetworkManager was to handle interfacing with dhclient: upstream, so the NetworkManager developers themselves did. For various reasons this may have caused dhclient's scripts to no longer be run in Ubuntu, and the exit hooks to still work in other distributions, but blaming people (at Canonical, or upstream) for this is certainly not the constructive way to correct the situation :)

Has this been brought up upstream yet? Also, as the suggested changes (attached script and blog post) seem safe, it could be feasible to implement them, but it probably needs a little more checking first.

On Tue, 2010-04-06 at 04:18 +0000, Mathieu Trudel wrote:
> Brian,

Hi,

> Ubuntu and Canonical didn't exactly make the decisions regarding how
> NetworkManager was to handle interfacing with dhclient: upstream, so the
> NetworkManager developers themselves did.

Fair enough. But as an integrator and the party who is "upstream" from
your users, IMHO, you should be advocating for them.

> For various reasons this may
> have caused dhclient's scripts to no longer be run in Ubuntu, and the
> exit hooks to still work in other distributions, but blaming people (at
> Canonical, or upstream) for this is certainly not the constructive way
> to correct the situation :)

Well, except that the (Ubuntu) bug has been open for a long time and
nothing has been done about it.

> Has this been brought up upstream yet?

I would have hoped that in your position as advocating for your users,
you would have opened one. I don't see anything open so I opened bug
615073 at bugzilla.gnome.org.

> Also, as the suggested changes
> (attached script and blog post)

Which attached script. There are a few.

> seem safe, it could be feasible to
> implement them, but it probably needs a little more checking first.

It would be nice to see this implemented, yes.

Sadly this bug has sat around, idle, for long enough that it will
probably not make Lucid. :-(

I have added some comments to the previously mentioned, bug 615073 at bugzilla.gnome.org.

In that bug I have pasted an example of gluing a NM dispatch script to a dhclient "e{nter,xit}" script. It's really quite simple. Of course the real solution is to migrate the needed scripts properly to NM's dispatcher, but in the meanwhile, can somebody include some glue scripts in the Ubuntu NM to do what I have done but for all of the needed scripts? I don't know which scripts in the dhclient e{nter,xit} hooks we still need.

> Of course the real solution is to migrate the needed scripts properly to NM's dispatcher

That's only a proper solution if NM's dispatcher is fixed to provide the information that these scripts need. It currently provides a much more limited set of functionality compared with the dhclient interface.

On Fri, 2010-04-09 at 15:00 +0000, Steve Langasek wrote:
>
> That's only a proper solution if NM's dispatcher is fixed to provide the
> information that these scripts need. It currently provides a much more
> limited set of functionality compared with the dhclient interface.

While I'm not necessarily disagreeing with you, but perhaps you can
expand on what you think NM should be providing to dispatcher scripts
that it's not already. Unless we can detail what we think is missing,
the developers won't know.

Did you look at what I added to the upstream (gnome) bug? At least for
the NTP script case, I was able to shim between NM and the dhclient
script. It would have been trivial to simply port the script to NM
properly but I was more interested at the time in demonstrating a shim
interface. Well, that and being lazy. :-)

Just another bump to say I implemented an nsupdate script in dispatcher.d and was dismayed to find it doesn't work when DHCP renews and gets a different IP. I'll be implementing the workaround and hoping this bug gets fixed in the next release despite the Gnome team's apparent apathy.

This problem also affect the /etc/samba/dhcp.conf which is not updated to add the information about the wins server

FWIW:

I created an executable script in /etc/NetworkManager/dispatcher.d owned by a normal user, and it was not executed.

Only after a a "chown root:root" of the script, it was executed. So apparantly root needs to be owner of the script?

Is this as it should be?

Should be fixed in Precise.

On 12-06-23 05:11 AM, Thomas Hood wrote:
> Should be fixed in Precise.

As of which release? I have 0.9.4.0-0ubuntu4.1 installed and I see no
evidence of /etc/dhcp/dhclient-exit-hooks.d/debug (after both having
changed the 'RUN=' from "no" to "yes" and even changing the permissions
to 755) being run for example.

My apologies, I confused this bug with another one.

On 12-06-23 12:42 PM, Thomas Hood wrote:
> My apologies, I confused this bug with another one.

So then you will correct the Fix Released (and whatnot flags)?

Setting to Triaged/Medium; the next steps are fairly straightforward: we should fix the dispatcher to include the variables that would be missing to provide the same functionality as the dhclient hooks. As a minimum WINS and NTP settings need to be provided, but we should look at the list of packages that provide hook scripts and possibly add a dispatcher equivalent to them.

On Wed, Jul 18, 2012 at 02:02:12PM -0000, Mathieu Trudel-Lapierre wrote:
> but we should look at the list of packages that provide hook scripts and
> possibly add a dispatcher equivalent to them.

That implies that each package which wants to have hooks run on dhcp
configuration would need to support two different interfaces. I don't think
that's at all sensible. NM should just be fixed to support the existing
dhclient interface.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

I have run into this problem several times now. Always the problem is that the provided ntp-servers from dhcp is not used. In an enterprise environment I believe that it is quite common, that workstations don't have unrestricted access to the internet. In this case the result is that workstations will never update the system clock unless ntp is manually configured either by editing /etc/default/ntpdate or by installing and configuring ntpd.

This is a problem for me. I need to set and read DHCP vendor-class-id and nis-domain parameters. I do not believe these parameters are supported in NetworkManager.

I've encountered this problem lately as well. Impressive that it's reported since 2009 with no fixes :-/

So, one thing to note is that dispatcher.d only works for "up" and "down" actions, but it doesn't work for obtaining new leases on an interface that is already up, which dhclient hooks do.

Has this been fixed in versions posterior to 14.04?
Or is it waiting to reach "extra-hot" status?