3

I have a number of Hardy hosts that seem to get an invalid hostname placed in their /etc/hosts during the installation process.

There's a line in /etc/hosts on a freshly built, unmodified host that looks like this 

127.0.1.1  hostname.subdomain.domain.subdomain.domain hostname.subdomain.domain

The first hostname in that list is invalid.

This causes problems when programs run hostname -f or an equivalent and get "hostname.subdomain.domain.subdomain.domain" which is an invalid, unresolvable hostname.

uname -n returns "hostname.subdomain.domain"

On Lucid hosts, the entries look like this:

127.0.1.1  hostname.subdomain.domain hostname

which is pretty much what I was expecting and would like to happen.

Both our Hardy and Lucid machines are built via pxeboot and pressed files. I've scanned through our preseed config for:

  • Anything that looks it might change the hostname
  • Anything that might change /etc/hosts

I've not found anything.

It is possible for me to manipulate /etc/hosts en masse via puppet, but I would much prefer to understand the cause of the problem and fix it at source.

Jorge Castro
  • 73,907
bleach
  • 51

1 Answers1

1

I can think of two places to look:

If these are client installations using the casper live cd environment, it sounds like this is set within that environment. Grab either a cd or an iso image, take the casper/initrd.lz file and uncompress it:

lzma -dc -S .lz initrd.lz | cpio -imvd --no-absolute-filenames

Most configuration is set in scripts/casper-bottom. You may find a clue in there.

See here for more details on how to manipulate a CD:

https://help.ubuntu.com/community/LiveCDCustomization

If not, I'd next go looking into the Ubiquity installer, I reckon you can look at the files and code if you boot a Live CD. If this is done at install time, Ubiquity is where it would be done.

roadmr
  • 34,862
  • 9
  • 84
  • 94
  • Thanks. It wasn't actually a live cd install, but off the alternate install.

    I've actually realised that fixing this behaviour is probably undesirable, since it would involve simultaneously fixing all the code in our apps that depends on the old behaviour :)

    My conclusion is that this is something that we'll deal with when porting apps onto Lucid and all I've done is update our internal docs on porting things to Lucid.

     – bleach Jan 27 '12 at 12:59