Bug 702735

Summary: [regression] NetworkManager 0.8.999-1 breaks dhclient dispatch script API
Product: [Fedora] Fedora Reporter: James Ralston <ralston>
Component: dhcpAssignee: Jiri Popelka <jpopelka>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 15CC: dcbw, jpopelka
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: dhcp-4.2.1-7.P1.fc15 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-19 01:08:49 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description James Ralston 2011-05-06 15:18:35 EDT
The changelog for NetworkManager-0.8.999-1 contains this line:

* Tue May 03 2011 Dan Williams <dcbw@redhat.com> - 0.8.999-1
- core: enhance dispatcher script environment to include IPv6 and VPN details

Unfortunately, this enhancement also contains a regression: NetworkManager no longer passes all of the expected dhclient variables that dhclient dispatch scripts (in /etc/dhcp/dhclient.d) depend on.

Examples of variables that are no longer set in 0.8.999-1:

new_broadcast_address
new_domain_name_servers
new_host_name
new_ip_address
new_network_number
new_ntp_servers
new_server_name
new_smtp_servers
new_subnet_mask

Now, it is certainly true that the values from some of these variables can inferred/reconstructed by the new variables that NetworkManager now sets. For example, IP4_NAMESERVERS can be used instead of new_domain_name_servers.

But other variables aren't so easy to translate. For example, the IP4_ADDRESS_* variables can be used to determine all of (new_ip_address, new_network_number, new_broadcast_address, new_subnet_mask), but that is highly non-trivial to do from the shell.

And some data is missing entirely. For example, it is now impossible for the dhclient dispatch scripts to determine the NTP servers (new_ntp_servers), the SMTP servers (new_smtp_servers), the DHCP server that answered it (new_server_name), or even its new hostname (new_host_name)!

Now, one could argue that the dhclient dispatch variables are somewhat hackish, and don't play nicely with IPv6. I won't necessarily argue that point.

But the fact is, the dhclient dispatch variables represent a published and well-known API. When NetworkManager executes the dhclient dispatch scripts, it *MUST* do so in conformance with that API (or as close to it as is reasonably possible).

I would argue that this is a F15 release blocker.
Comment 1 Dan Williams 2011-05-09 02:26:22 EDT
I've tried reverting to NetworkManager-0.8.998-4.git20110427.fc15.x86_64 and that doesn't work either.  So that indicates that the recent NM change was not the culprit.  What version of NM and dhcp were you running previously?

In NM 0.8.999, I see the correct environment variables getting from nm-dispatcher.action to /etc/NetworkManager/dispatcher.d/11-dhclient, but then 11-dhclient (from the dhcp package) doesn't seem to be able to convert the variables and stick them in the environment for subscripts; the bits:

eval "$(
declare | LC_ALL=C grep '^DHCP4_[A-Z_]*=' | while read opt; do
    optname=${opt%%=*}
    optname=${optname,,}
    optname=new_${optname#dhcp4_}
    optvalue=${opt#*=}
    echo "$optname=$optvalue"
done
)"

which are supposed to do that work fine until the "echo xxx" statement, which doesn't actually stuff the new_XXXX variables into the environment of subscripts (or even itself) despite the conversion from NM -> dhclient naming having gone fine.  I modified 11-dhclient to print out the environment it is given, and that is as expected, yet a script called by 11-dhclient (placed in /etc/dhcp/dhclient.d/) does not receive the changed variable names.  Even more debugging of 11-dhclient indicates that everything in that block except the 'echo' statement performs as expected.

I did testcases with the change of NM dispatcher behavior from 0.8.998 to 0.8.999 to ensure that the existing script environment did *not* change, and given that and the information above, I'm thinking this is more an 11-dhclient script problem instead of an NM problem...  dhcp guys, anything here look suspicious to you?
Comment 2 Dan Williams 2011-05-09 02:33:54 EDT
Yeah, this isn't an NM problem.  We want this change made to 11-dhclient:

 eval "$(
 declare | LC_ALL=C grep '^DHCP4_[A-Z_]*=' | while read opt; do
     optname=${opt%%=*}
     optname=${optname,,}
     optname=new_${optname#dhcp4_}
     optvalue=${opt#*=}
-    echo "$optname=$optvalue"
+    echo "export $optname=$optvalue"
 done
 )"

which will get the right thing done for subscript environments.  I wonder how this was apparently working before?
Comment 3 Jiri Popelka 2011-05-09 08:58:55 EDT
Thank you, Dan.
Comment 4 Fedora Update System 2011-05-09 09:02:20 EDT
dhcp-4.2.1-7.P1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/dhcp-4.2.1-7.P1.fc15
Comment 5 Fedora Update System 2011-05-09 18:37:59 EDT
Package dhcp-4.2.1-7.P1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dhcp-4.2.1-7.P1.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/dhcp-4.2.1-7.P1.fc15
then log in and leave karma (feedback).
Comment 6 Fedora Update System 2011-05-19 01:08:44 EDT
dhcp-4.2.1-7.P1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.