hostname modifications user are overwritten by ec2init

Bug #514492 reported by Scott Moser
30
This bug affects 5 people
Affects Status Importance Assigned to Milestone
cloud-init (Ubuntu)
Fix Released
Medium
Scott Moser
Nominated for Hardy by Eric Hammond
Nominated for Karmic by Eric Hammond
Lucid
Fix Released
Medium
Scott Moser

Bug Description

Binary package hint: ec2-init

As reported http://groups.google.com/group/ec2ubuntu/browse_thread/thread/c9373df4fae7ae27
ec2-init sets hostname ('hostname <x>') on every boot, which means the user's modifications dont stick. This is even the case if they update /etc/hostname

I tihnk that calling 'hostname' on ec2 should only happen on the first boot, and the selected hostname be written to /etc/hostname.

Subsequent boots would then read and set hostname from /etc/hostname as it should.

ProblemType: Bug
Architecture: i386
Date: Fri Jan 29 20:41:09 2010
DistroRelease: Ubuntu 10.04
Ec2AMI: ami-1bb45872
Ec2AMIManifest: ubuntu-images-testing-us/ubuntu-lucid-daily-i386-server-20100129.manifest.xml
Ec2AvailabilityZone: us-east-1c
Ec2InstanceType: m1.small
Ec2Kernel: aki-60cb2609
Ec2Ramdisk: ari-0bb45862
Package: ec2-init 0.5.1-0ubuntu1
PackageArchitecture: all
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: User Name 2.6.32-301.4-ec2
SourcePackage: ec2-init
Uname: Linux 2.6.32-301-ec2 i686

Related branches

Revision history for this message
Scott Moser (smoser) wrote :
Scott Moser (smoser)
Changed in ec2-init (Ubuntu):
status: New → Triaged
importance: Undecided → Low
Revision history for this message
Eric Hammond (esh) wrote :

With some software packages (e.g., Puppet) it's important for a hostname to be set correctly or the system may not function. I believe this is important enough to fix in future Hardy and Karmic AMIs.

Changed in ec2-init (Ubuntu):
importance: Low → Medium
Scott Moser (smoser)
Changed in ec2-init (Ubuntu Lucid):
status: Triaged → Fix Committed
Revision history for this message
Scott Moser (smoser) wrote :

this is fix-released in cloud-init 0.5.4-0ubuntu1 or later (lucid)

affects: ec2-init (Ubuntu Lucid) → cloud-init (Ubuntu Lucid)
Changed in cloud-init (Ubuntu Lucid):
assignee: nobody → Scott Moser (smoser)
status: Fix Committed → Fix Released
Revision history for this message
nateaune (natea) wrote :

Scott - I agree with Eric that setting the hostname and persisting it is critical for many packages. Varnish is another one that expects to find a directory called: /var/lib/varnish/<hostname>/

After rebooting the EC2 instance, Varnish fails to start up with this error message:

$ sudo /etc/init.d/varnish restart
 * Stopping HTTP accelerator
   ...fail!
 * Starting HTTP accelerator
   ...fail!
Error: (-sfile) "/var/lib/varnish/domU-12-31-39-00-20-C2/varnish_storage.bin" does not exist and could not be created

$ hostname
domU-12-31-39-00-20-C2

$ ls /var/lib/varnish/
domU-12-31-38-04-E1-A2

As you can see the hostname changed after reboot, so Varnish can no longer find the directory, as it uses "uname -n" to determine what directory to look in.

from /etc/default/varnish:

INSTANCE=$(uname -n)

DAEMON_OPTS="-a :6081 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,1G"

any chance that you will fix this for Karmic, as you have already done for Lucid?

Revision history for this message
Scott Moser (smoser) wrote :

I don't really understand how a reboot *changed* the hostname. I'm aware that karmic images will set the hostname to the value of found in instance metadata on every boot, but I would have thought that would be persistent (although annoyingly arbitrary).

On EBS instances, I could see this change taking place, or possibly if you're using elastic IPs. There are no official Ubuntu EBS images for karmic though.

The EBS issue actually makes me think that what we have in Lucid is still not ideal, as cloud-init will write the value of the first boot to /etc/hostname and then never touch it again. On a stop-instances/start-instances cycle, this would result in incorrect hostname on the second boot. It might make sense to re-set hostname /etc/hostname contained the previous value (ie, was unchanged by a user). The end result would be that if a user wanted a persistent hostname they could write a *different* value to /etc/hostname and it would stick. The other option would be to just leave it as is in lucid, and if the 'hostname' changes, then a user needs to change it (this is similar to how "regular" installs work, its set once at install, if it changes user is in charge).

Regarding fixing this in karmic/hardy, I will see if its something that could easily be done. ec2-init is slightly different than cloud-init in this area.

Revision history for this message
JasonGiedymin (jason-giedymin) wrote :

Thanks Scott!

Revision history for this message
jon.marston@englishcentral.com (jon-marston) wrote :

my use case is to have a ebs backed lucid instance that is running torque I start and stop. It's critical that the /etc/hostname have the correct value when I start the instance again. I'm hitting the bug as described in Scott Moser's comment from 2010-04-08.

What I'm seeing is that when i restart the instance, attach an elastic ip address, and reboot, the old hostname value is still in /etc/hostname and is reported by /etc/hostname.

What is best way to automate getting the correct hostname? Manually copying and pasting values from elasticfox is errorprone and won't scale. I'm wary of using ec2-init because I only want the hostname value reset correctly.

Revision history for this message
jon.marston@englishcentral.com (jon-marston) wrote :

correction to previous comment

What I'm seeing is that when i restart the instance, attach an elastic ip address, and reboot, the old hostname value is still in /etc/hostname and is reported by echo `hostname`

Revision history for this message
Scott Moser (smoser) wrote :

@jon.marston
  Can you please describe what behavior you would like? I've opened bug 596993, as this bug is closed. I'd greatly appreciate it if you would add your comments there, and explain what you think would be the right behavior.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.