The behavior that strips off the FQDN for send-hostname was added for https://bugzilla.redhat.com/show_bug.cgi?id=694758#c25.  The decision to only use the short name is fairly old too, as a result of https://bugzilla.redhat.com/show_bug.cgi?id=697877.

It also looks like our internal DHCP client allows the full FQDN, but we should strive to be consistent between internal & dhclient.

But there's some additional confusion here.  The "-H" dhclient option maps directly to the send-hostname config item, and here the dhclient manpage says:

"Specify the host-name option to send to the DHCP server.  The host-name string only contains the client's hostname prefix, to which the server will append the ddns-domainname  or  domain-name options, if any, to derive the fully qualified domain name of the client."

Which of course implies that send-hostname should only take a short name, not an FQDN.  Which was probably the reason we started stripping the domain off the hostname in the first place.  Other parts say that it's permissible (but not preferred) to send the FQDN with send-hostname.

Our RHEL7 old 'network' service initscripts also chop DHCP_HOSTNAME down to a short name, per:

https://git.fedorahosted.org/cgit/initscripts.git/commit/?id=60ddb21fcdfb0594a35978aa0b04af4527c46d6e

So at least in this respect, NM and 'network' service initscripts agree.  I'm not 100% sure that this behavior is correct, but we need to at least agree on the right behavior between the two, and make them consistent.

Hey Dan,

I apologize, I'm not sure how I missed those older bugs when I filed this. Thank you for pointing them out.

I'll have to double check what is actually happening but I found that the FQDN in DHCP_HOSTNAME was passed by the RHEL 7 network service scripts, not the cut down hostname....


# nmcli con down eth0
# systemctl stop NetworkManager

# rpm -q initscripts
initscripts-9.49.24-1.el7.x86_64

# grep DHCP_HOSTNAME /etc/sysconfig/network-scripts/ifcfg-eth0 
DHCP_HOSTNAME=text.example.com

# ifup eth0

# ps aux | grep dhclient
root     11161  0.0  1.2 103736 12700 ?        Ss   09:38   0:00 /sbin/dhclient -H test.example.com -1 -q -lf /var/lib/dhclient/dhclient-b307d861-4fe2-4185-bfef-7211d9d47516-eth0.lease -pf /var/run/dhclient-eth0.pid eth0


So, the network service scripts pass the FQDN to the -H option of dhclient. As was pointed out in bz694758, it looks like this behaviour is incorrect per the dhclient man page:

       -H <host-name>
              Specify  the  host-name  option to send to the DHCP
              server.  The host-name  string  only  contains  the
              client's  hostname prefix, to which the server will
              append the ddns-domainname or domain-name  options,
              if  any,  to derive the fully qualified domain name
              of the client.  The -H option cannot be  used  with
              the -F option.


If we're going to pass the entire thing, it should be using -F?

       -F <fqdn.fqdn>
              Specify  the  fqdn.fqdn  option to send to the DHCP
              server.  This option cannot be  used  with  the  -H
              option.  The fqdn.fqdn option must specify the com‐
              plete domain name of the  client  host,  which  the
              server may use for dynamic DNS updates.



I sorta lean towards making NM do the same thing that the network service scripts do now, as it has seemingly been done that way for so long... but at the end of the day it *appears* it has been wrong all along. Though, what NM in RHEL 7 does appears to be a more correct behaviour.


How about having both NM and network service scripts send host-name if the DHCP_HOSTNAME is a bare hostname and send fqdn.fqdn (-F) if DHCP_HOSTNAME is a FQDN?



Thank you again,

Patrick

(In reply to Patrick Talbert from comment #4)

> How about having both NM and network service scripts send host-name if the
> DHCP_HOSTNAME is a bare hostname and send fqdn.fqdn (-F) if DHCP_HOSTNAME is
> a FQDN?

This seems the right thing to do, but I wonder if this new change in
behavior could break some existing setups. Probably no, because
sending '-F host.domain' should be equivalent to sending '-H host',
maybe except in the cases in which the client domain is different from
server domain. But the new behavior would be more correct anyway.

And also, while the change to support this in NM is trivial for
dhclient, the internal (systemd-networkd based)	DHCP client doesn't
support the fqdn option at the moment; if we decide to go this way we
need to introduce this feature and merge it upstream.

Dan,

Can you think of a workaround for this in RHEL 7 which still allows the use of NetworkManager? I don't think a dispatcher script can affect the dhclient config file NM generates before it is used, no? It would be awesome if it could....


The customer here is anxious for a fix but obviously it still needs to be determined what that would even be so I can't really provide any type of time line.


I suggested:

1. Disabling NetworkManager

2. Setting the FQDN in the /etc/hostname file (hostnamectl) as NM will defer to that (right??)

3. Change the DHCP server settings (ha!)



Shoot, I guess a dispatcher script could set the hostname to the value of DHCP_HOSTNAME after the interface comes up? ugh....


Thank you,

Patrick

Looking at RHEL7 scripts, it may seem that DHCP_HOSTNAME gets stripped
in network-functions:expand_config(), but actually the function is not
called when the address is dynamic and so the final result is that the
dhclient invocation:

 DHCLIENTARGS="${DHCLIENTARGS} -H ${DHCP_HOSTNAME:-${HOSTNAME%%.*}} ...

only strips the system hostname. Probably this is a bug, as it seems
that the purpose of commit:

  https://git.fedorahosted.org/cgit/initscripts.git/commit/?id=60ddb21fcdfb0594a35978aa0b04af4527c46d6e&context=30&ignorews=0&ss=0

was to strip also DHCP_HOSTNAME.


So I think we have two options:

 1. change NM to behave like init scripts and avoid stripping
    DHCP_HOSTNAME; HOSTNAME would be still stripped

 2. change both NM and init scripts to send the fqdn option when
    HOSTNAME (or DHCP_HOSTNAME) is a FQDN.

I would prefer 2. as 1. looks inconsistent and also not compliant with
RFCs. Dan, what do you think?


(In reply to Patrick Talbert from comment #6)
>
> Can you think of a workaround for this in RHEL 7 which still allows the use
> of NetworkManager? I don't think a dispatcher script can affect the dhclient
> config file NM generates before it is used, no? It would be awesome if it
> could....
>
> 2. Setting the FQDN in the /etc/hostname file (hostnamectl) as NM will defer
> to that (right??)

I don't think this will work as NM will remove the domain part before
passing it to dhclient.

As a workaround you can try to set dhcp=internal in the [main] section
of /etc/NetworkManager/NetworkManager.conf since the internal DHCP
client doesn't strip the hostname.

(In reply to Beniamino Galvani from comment #9)
> Looking at RHEL7 scripts, it may seem that DHCP_HOSTNAME gets stripped
> in network-functions:expand_config(), but actually the function is not
> called when the address is dynamic and so the final result is that the
> dhclient invocation:
> 
>  DHCLIENTARGS="${DHCLIENTARGS} -H ${DHCP_HOSTNAME:-${HOSTNAME%%.*}} ...
> 
> only strips the system hostname. Probably this is a bug, as it seems
> that the purpose of commit:
> 
>  
> https://git.fedorahosted.org/cgit/initscripts.git/commit/
> ?id=60ddb21fcdfb0594a35978aa0b04af4527c46d6e&context=30&ignorews=0&ss=0
> 
> was to strip also DHCP_HOSTNAME.
> 
> 
> So I think we have two options:
> 
>  1. change NM to behave like init scripts and avoid stripping
>     DHCP_HOSTNAME; HOSTNAME would be still stripped
> 
>  2. change both NM and init scripts to send the fqdn option when
>     HOSTNAME (or DHCP_HOSTNAME) is a FQDN.
> 
> I would prefer 2. as 1. looks inconsistent and also not compliant with
> RFCs. Dan, what do you think?

I originally thought #1, because DHCP_HOSTNAME is explicitly set by the user and is only used for DHCP, and thus you could think of it as an admin override and the admin knows what they are doing.

But I think you're right with #2 and that's the best path forward.  So lets see if the initscripts people are OK with this?  It seems clear that the intention back in 2010 was to strip the hostname anyway.

Obviously we cannot strip the hostname for IPv6 though, since that's not allowed by the relevant DHCPv6 RFCs (#4704, https://tools.ietf.org/html/rfc4704).  So this could present a problem in the ifcfg files, where DHCP_HOSTNAME is used for DHCPv4 and DHCPv6.  If the admin wants to use a short hostname for DHCPv4, then we could not also send that with DHCPv6.  But I think that's OK.

(In reply to Dan Williams from comment #10)
> But I think you're right with #2 and that's the best path forward.  So lets
> see if the initscripts people are OK with this?  It seems clear that the
> intention back in 2010 was to strip the hostname anyway.

Okay, I opened bug 1260552 against initscripts, let's see which is
their opinion.

> Obviously we cannot strip the hostname for IPv6 though, since that's not
> allowed by the relevant DHCPv6 RFCs (#4704,
> https://tools.ietf.org/html/rfc4704).  So this could present a problem in
> the ifcfg files, where DHCP_HOSTNAME is used for DHCPv4 and DHCPv6.  If the
> admin wants to use a short hostname for DHCPv4, then we could not also send
> that with DHCPv6.  But I think that's OK.

Yes, I guess there's nothing we can do to solve this.

As suggested in bug 1260552, solution #2 would change behavior and
possibly break working setups.

A more conservative approach is to add a new 'ipv4.dhcp-fqdn'
property, mutually exclusive with 'ipv4.dhcp-hostname', so that system
administrator can choose which of the two options to send. When
'ipv4.dhcp-fqdn' is not set the old behavior is retained.

Pushed branch bg/dhcp-send-fqdn-rh1255507 for review. While at this, I
also made the different DHCP clients behave the same way WRT stripping
of hostname (first 2 commits). The changes to libsystemd-network will
need to be submitted upstream.

Adding a new option for this looks like a good idea to me. The patchset seems all good to me too apart from one tiny nitpick:

systemd: add support for "Client FQDN" DHCP option

+        host_len = strlen(hostname);
+        if (host_len + 2 > len)
+               return -1;
 ^^^^^^^^ whitespace error?

> ifcfg-rh: support DHCP_FQDN variable
+ if (value && strlen (value)) {
Let's use "if (value && *value) {" instead

Other than that the branch look good to me.

>> systemd: add support for "Client FQDN" DHCP option

whitespace error:

+        host_len = strlen(hostname);
+        if (host_len + 2 > len)
+         return -1;


>> ifcfg-rh: support DHCP_FQDN variable

This commit should come before the nmcli commit.


+         value = nm_setting_ip4_config_get_dhcp_fqdn (NM_SETTING_IP4_CONFIG (s_ip4));
+         if (value)
+              svSetValue (ifcfg, "DHCP_FQDN", value, FALSE);


IMO the "if (value)" is harmful. svSetValue() would remove the key if value is unset, which is exactly what we want.
Similar for hostname above.

(In reply to Thomas Haller from comment #15)
> +         value = nm_setting_ip4_config_get_dhcp_fqdn (NM_SETTING_IP4_CONFIG
> (s_ip4));
> +         if (value)
> +              svSetValue (ifcfg, "DHCP_FQDN", value, FALSE);
>
>
> IMO the "if (value)" is harmful. svSetValue() would remove the key if value
> is unset, which is exactly what we want.
> Similar for hostname above.

Right; I fixed this by clearing DHCP_FQDN before calling write_ip4_setting().

Also, fixed the other comments above and repushed the branch.

Patrick,

just to check before proceeding, would a new ipv4.dhcp-fqdn connection
property solve the customer issue? When that property is set NM will
send the property value in the FQDN option; instead if the property is
empty the stripped hostname (from ipv4.dhcp-hostname or the
system-configured one) will be sent in the hostname property (as it is
now).

The approach of adding the new option sounds OK to me; there isn't any way to autodetect this so it's the best we can do.

Merged to master:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=9b1d195600721bac1ce6df6e5b284847a11b071c

Created attachment 1162459 [details]
[PATCH] dhcp: let users override FQDN dhclient options

Patch LGTM, but could you add a testcase for it too?

Created attachment 1162587 [details]
[PATCH v2] dhcp: let users override FQDN dhclient options

(In reply to Dan Williams from comment #31)
> Patch LGTM, but could you add a testcase for it too?

Fixed in v2.

(In reply to Beniamino Galvani from comment #32)
> Created attachment 1162587 [details]
> [PATCH v2] dhcp: let users override FQDN dhclient options
> 
> (In reply to Dan Williams from comment #31)
> > Patch LGTM, but could you add a testcase for it too?
> 
> Fixed in v2.

fqdn_opts leaks the strings.


otherwise, lgtm

(In reply to Thomas Haller from comment #34)

> fqdn_opts leaks the strings.

Fixed and applied to master:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=f940428c659eb9bd797da4545dd000bfa18ca99c

and nm-1-2:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-1-2&id=30f53e7e22628fb04d80dec978123b9b3653b89d

+    /**
+     * NMSettingIP4Config:dhcp-fqdn:
+     *
+     * Since: 1.0.6


this is not correct, because dhcp-fqdn is not (upstream) 1.0.6 API. If the Since tag allows arbitrary names, I would say something like "Since: 1.0.6-rhel7.2".

which 7.2.z batch will this be included in?

Woot!  I can confirm for MS DHCP servers, using the RHEL 7.3 Z-stream packages (Thanks Red Hat support for the backport-sauce), that this works with the following settings, some of which my be redundant:

/etc/sysconfig/network-scripts/ifcfg-$iface
DHCP_HOSTNAME="host.ad.college.edu"
DHCP_FQDN="host.ad.college.edu"
^^ this alone does not fix^^

nmcli con modify enp0s31f6 ipv4.dhcp-fqdn host.ad.college.edu
^^this is probably the only needed thing to fix w/ z-stream 7.3 packages^^

Results:
# nmcli con show enp0s31f6 | grep host.ad.college.edu
ipv4.dhcp-fqdn:     host.ad.college.edu


# cat /var/lib/NetworkManager/dhclient-enp0s31f6.conf
# Created by NetworkManager

send fqdn.fqdn "host.ad.college.edu"; # added by NetworkManager
send fqdn.encoded on;
send fqdn.server-update on;


# dig +short host.ad.college.edu
10.123.456.789

                  
RPMs that fixed the problem for me:
Aug 10 16:37:43 Updated: 1:NetworkManager-libnm-1.0.6-31.el7_2.x86_64
Aug 10 16:37:45 Updated: 1:NetworkManager-1.0.6-31.el7_2.x86_64
Aug 10 16:37:45 Updated: 1:NetworkManager-tui-1.0.6-31.el7_2.x86_64
Aug 10 16:37:46 Updated: 1:NetworkManager-wifi-1.0.6-31.el7_2.x86_64
Aug 10 16:37:47 Updated: 1:NetworkManager-team-1.0.6-31.el7_2.x86_64
Aug 10 16:37:48 Updated: 1:NetworkManager-adsl-1.0.6-31.el7_2.x86_64
Aug 10 16:37:49 Updated: 1:NetworkManager-glib-1.0.6-31.el7_2.x86_64
Aug 10 16:37:50 Updated: 1:NetworkManager-config-server-1.0.6-31.el7_2.x86_64

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2581.html

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days