Opened 16 years ago

Closed 16 years ago

#44 closed defect (fixed)

Hostname set over DHCP should be reasonable

Reported by: broder Owned by: broder
Priority: major Milestone: Demo-able
Component: dhcp Version:
Keywords: Cc:

Description

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.

Attachments (3)

dhcpserver.py.diff (2.6 KB) - added by broder 16 years ago.
Here's a new version - this one adds the domain_search option
dhcpserver.py.2.diff (2.6 KB) - added by broder 16 years ago.
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.
dhcpserver.py.3.diff (2.6 KB) - added by broder 16 years ago.
Fixing bugs and not using sets

Download all attachments as: .zip

Change History (11)

comment:1 Changed 16 years ago by 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.

comment:2 Changed 16 years ago by 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.

comment:3 Changed 16 years ago by 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.

Changed 16 years ago by broder

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

comment:4 follow-up: Changed 16 years ago by 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.

comment:5 in reply to: ↑ 4 ; follow-up: Changed 16 years ago by 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.

Changed 16 years ago by 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.

Changed 16 years ago by broder

Fixing bugs and not using sets

comment:6 in reply to: ↑ 5 Changed 16 years ago by broder

  • Owner changed from quentin to broder
  • Status changed from new to accepted

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.

comment:7 Changed 16 years ago by broder

  • Milestone set to Demo-able

comment:8 Changed 16 years ago by broder

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

Note: See TracTickets for help on using tickets.