Re: PATCH/Feature request

[Dan Williams <dcbw redhat com>]

On Thu, 2012-01-26 at 00:00 +0100, Oncaphillis wrote:
> On 01/25/2012 09:19 PM, Dan Williams wrote:
>  > On Mon, 2012-01-23 at 10:18 +0100, Oncaphillis wrote:
>  >> Hi,
>  >>
>  >> Please find attached a patch against the current git
>  >> which re-enables DHCP/DNS Name transmission including
>  >> domain suffix as an option.
>  >>
>  >> I have a rather dim DSL router with DHCP function
>  >> which doesn't accept any domain specific options
>  >> but allows for the transmission of a full hostname
>  >> via the "send host-name" command. I use the domain name
>  >> to distinguish between my VPN connection and the rest
>  >> of the world. So I used to add the full hostname
>  >> for NetworkManager. Now it chops off the
>  >> domain suffix before transmission.
>  >>
>  >>    The attached patch adds a property "dhcp-with-domain"
>  >> to NetworkManager  which disables this behaviour when true.
>  >>
>  >>    In addition the ifcfg-rh plugin enables this feature
>  >> if it finds the DHCP_WITH_DOMAIN=yes line in the corresponding
>  >> ifcfg-xxx file.
>  >
>  > Just to clarify, you used to set your persistent system hostname to say
>  > "mycomputer.foobar.org" and NM used to send that entire hostname to the
>  > router, correct?
> 
>    Yes -- I was pretty sure that sending a FQDN breaks some rules but
> it used to work on my router and allows me to give all my home
> machine my own private domain.
> 
>  > I know we changed it a while ago to only send the
>  > hostname excluding the domain portion.  However, I think we should only
>  > strip the hostname when we're using the system hostname.  If the user
>  > manually specifies a name in dhclient-<xxx>.conf or in the connection
>  > settings, then I think we should send exactly what the user entered.
> 
>   Does 'should' mean that it is current behaviour ? That doesn't seem
> to be the case. Explicitly setting DHCP_HOSTNAME in the ifcfg-<xxx> file 
> doesn't change anything at all. The domain gets chopped of.
> nm-dhcp-dhclient-util.c  doesn't seem to care where the hostname came 
> from and if it has been provided with a valid hostname it filters
> out any "send host-name" statements in the /etc/dhclient-<xxx>.conf
> file.

By "should" I meant that it doesn't do that, but we should fix it to do
so.  Sorry for the ambiguous terminology.

>  > That needs a bit of work though; we need to adjust the NMDhcpClient
>  > class to take two hostnames to the client_start() function, one for the
>  > system hostname and one for the hostname from the
>  > NMSettingIP4Config/NMSettingIP6Config.  Then internally
>  > nm-dhcp-dhclient.c would know whether to strip the system hostname (if
>  > the hostname from settings is missing) or to use the configured hostname
>  > verbatim.  The original bug for stripping the hostname is rh#694758.
>   And then you still have to decide if you allow the send host-name
> command to take place with the FQDN or to build your own sequence
> of fqdn commands (which my router doesn't seem to understand).

The end goal here is to update your DDNS entries, right?  AFAIK that's
what the FQDN option is typically used for.  Is that what you'd use the
hostname option for as well?

<rant>It kinda sucks that dhclient doesn't pick which one to use; ie if
it had a policy like "if the hostname given ends in a . then it's
fully-qualified and we send FQDN" then we wouldn't need to choose
between FQDN and hostname.  Second, there's the whacky options for FQDN
like encoded and server-update which of course we have no idea what to
do with and aren't going to expose in any UI.

Dan

> thanks or the reply
> 
> Sebastian
> 
> 
> 
> _______________________________________________
> networkmanager-list mailing list
> networkmanager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list