Hostname set over DHCP should be reasonable

[broder]

Currently in an Ubuntu installer if you accept the default value for hostname taken from DHCP, your FQDN gets set to <servername>.servers.csail.mit.edu.servers.csail.mit.edu

If it's not possible to fix this easily, then it should be documented somewhere that users can see it.

[broder]

Given that the DHCP protocol does not allow us to specify hostname, domainname, and FQDN such that the FQDN != hostname + '.' + domainname, I think that the domainname served by the DHCP server should vary based on what the FQDN of the hostname is.

The patch that I attached does this. I'll apply it if nobody objects.

[broder]

I watched my own laptop's interaction with MITnet's DHCP servers - although the OFFERs and ACKs never included the hostname for me, my REQUESTs did. They did not use the FQDN, so I don't use the FQDN as the hostname in my patch.

[quentin]

The spec (​RFC2132) is very clear on the hostname field:

3.14. Host Name Option

This option specifies the name of the client. The name may or may not be qualified with the local domain name (see section 3.17 for the preferred way to retrieve the domain name). See RFC 1035 for character set restrictions.

I don't think it's a good idea to cite what Apple's DHCP client does, as the hostname it provided in the REQUEST probably came from your computer's settings and didn't have an associated domain name to begin with.

[broder]

Here's a new version - this one adds the domain_search option

[ecprice]

quentin: Regardless of the RFC, it needs to work. Feel free to complain to upstream dhcp clients.

broder:

• list('mit.edu') is not the same as mit.edu?, and you want the latter.
• "'key' in options" is more Pythonic than "options.has_key('key')"
  • You can also condense some of line 64 by making optionsdomain_search? a set, and always adding domain_name to it.
• You typo "domain_name" as "domainname" a couple times
• I don't understand the RFC3397 stuff.

[quentin]

Replying to ecprice:

quentin: Regardless of the RFC, it needs to work. Feel free to complain to upstream dhcp clients.

I think our biggest problem is a Debian installer bug; it does the demonstrably wrong thing.

Given these inputs: hostname: foo.servers.csail.mit.edu domainname: mit.edu

One might construct the FQDN foo.servers.csail.mit.edu, and one might construct the FQDN foo.servers.csail.mit.edu.mit.edu. The Debian installer constructs the FQDN foo.servers.csail.mit.edu.servers.csail.mit.edu, which is complete garbage.

broder:

• You can also condense some of line 64 by making optionsdomain_search? a set, and always adding domain_name to it.

The list of search domains is ordered, so it can't be represented as a set.

[broder]

Ok - here's round 3, which should fix the bugs that Eric pointed out. I agree that the formatting of the RFC3397 field is screwy, but it was very clear from the spec that that's what the frames are supposed to look like, and when I looked at my own DHCP traffic, fields like the domain_name were not encoded like that. *shrug* I don't get it.

[broder]

Fixing bugs and not using sets

[broder]

Replying to quentin:

I think our biggest problem is a Debian installer bug; it does the demonstrably wrong thing.

I really don't care who is at fault. We need to make our software work around what other software does. If that means settling for slightly less than ideal functionality, then that's what we need to do.

[broder]

Ok. I have committed and deployed my patch to fix this. One of two things happens depending on whether or not the DHCP client advertises support for the domain-search option.

If the domain-search option is not supported:

Set the host-name to an unqualified hostname Set the domain-name to 'servers.csail.mit.edu' (or 'mit.edu', if appropriate)

If the domain-search option is supported:

Set the host-name to the VM's fully-qualified domainname Do not set the domain-name Set the search path to mit.edu?

As best as I can tell, this will Do The Right Thing (or as close to The Right Thing as we can) for etch, lenny, and gutsy, both the installed OS and their installers. I have not tested it with anything else, but I suspect that it should work in the general case.