hostname handling needs improvement for elastic-ip and ebs start-stop

Bug #596993 reported by Scott Moser
32
This bug affects 5 people
Affects Status Importance Assigned to Milestone
cloud-init (Ubuntu)
Fix Released
Medium
Scott Moser
Lucid
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: cloud-init

as seen in bug 514492, the /etc/hostname file is written by cloud-init only once per instance.

As mentioned in bug 514492 comment 5, this behavior of the cloud-images is now similar to regular installs. that is, on first boot (ie, similar to initial install) the hostname is set to the value found in 'local-hostname' of the metadata service.
It is never modified by cloud-init after that.

If the user takes an action that results that hostname no longer being valid, then they will need to update the hostname field.

That hostname could become invalid (or at least incorrect) in one of the following ways:
a.) EBS based instance is stopped and started. It will then get a new IP address, and also a new 'local-hostname'.
b.) user associated an elastic-IP address. In my limited testing, this will not change the value of local-hostname, as the local-ipv4 is not updated. Instead, routing magic is applied to make the elastic-IP address go to that local ipv4 address.

I'm opening this bug as a place holder to come up with a better way to address at least 'a' above. My first thought is to have cloud-init write /etc/hostname and /etc/hostname.cloud-init with the same value. Then, on each boot, compare hostname.cloud-init and hostname. If they are different, do nothing (assume the user modified /etc/hostname). If they are the same, then get 'local-hostname' from the metadata service and update both.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: cloud-init 0.5.12-0ubuntu1
ProcVersionSignature: User Name 2.6.32-305.9-ec2 2.6.32.11+drm33.2
Uname: Linux 2.6.32-305-ec2 i686
Architecture: i386
Date: Mon Jun 21 18:36:02 2010
Ec2AMI: ami-fa2dc593
Ec2AMIManifest: ubuntu-images-testing-us/ubuntu-maverick-daily-i386-server-20100621.manifest.xml
Ec2AvailabilityZone: us-east-1b
Ec2InstanceType: m1.small
Ec2Kernel: aki-078e676e
Ec2Ramdisk: unavailable
PackageArchitecture: all
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: cloud-init

Related branches

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

suggested fix would solve the problem use case I described in 514492. :)

I have a ebs lucid instance that is running openpbs/torque which is stopped and later restarted. It's critical that the /etc/hostname have the correct value when the instance is restarted.

In the case, I would not have altered the /etc/hostname or /etc/hostname.cloud-init, so upon a reboot the hostname would be retrieved from the instance meta data and updated.

Scott Moser (smoser)
Changed in cloud-init (Ubuntu):
assignee: nobody → Scott Moser (smoser)
importance: Undecided → Medium
status: New → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cloud-init - 0.5.12-0ubuntu4

---------------
cloud-init (0.5.12-0ubuntu4) maverick; urgency=low

  * handle hostname managing better with ebs root. (LP: #596993)
 -- Scott Moser <email address hidden> Wed, 07 Jul 2010 11:54:10 -0400

Changed in cloud-init (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
Gerry Reno (greno-verizon) wrote :

This fix is needed for Lucid as well.

I have a clustered filesystem that fails because of this bug. It relies upon the hostname value always being set correctly.

Revision history for this message
Gerry Reno (greno-verizon) wrote :

As the ec2 meta-data, local-hostname, returns the long form of hostname,
I would also propose that an enhancement that a new ec2 meta-data attribute be added:

     local-shortname

that would return the short version of hostname such as is returned from 'hostname -s' on a properly configured system.

This would make it easier for users to get the hostname format that they need.

Revision history for this message
Gerry Reno (greno-verizon) wrote :

When hostname is properly working on a system all of the following commands should work as expected:

#uname -n
#hostname -a
#hostname -s
#hostname -d
#hostname -f
#hostname

Source: http://www.debianadmin.com/change-hostname-or-server-name-of-a-linux-machine.html

Revision history for this message
Gerry Reno (greno-verizon) wrote :

Running the following commands appears to correctly set all the forms of hostname on my Lucid ec2 instance:

echo "$(curl -s http://169.254.169.254/latest/meta-data/local-hostname)" | sed 's:\..*$::' > /etc/hostname

/sbin/sysctl -w kernel.hostname="$(curl -s http://169.254.169.254/latest/meta-data/local-hostname | sed 's:\..*$::')"

logout/login shell

root@ip-10-XXX-181-59:~# uname -n
ip-10-XXX-181-59
root@ip-10-XXX-181-59:~# hostname -s
ip-10-XXX-181-59
root@ip-10-XXX-181-59:~# hostname -d
ec2.internal
root@ip-10-XXX-181-59:~# hostname -f
ip-10-XXX-181-59.ec2.internal
root@ip-10-XXX-181-59:~# hostname
ip-10-XXX-181-59
root@ip-10-XXX-181-59:~# echo $HOSTNAME
ip-10-XXX-181-59
root@ip-10-XXX-181-59:~# cat /etc/hostname
ip-10-XXX-181-59
root@ip-10-XXX-181-59:~# /sbin/sysctl -n kernel.hostname
ip-10-XXX-181-59

Revision history for this message
Gerry Reno (greno-verizon) wrote :

Now since my cluster filesystem starts real early in the bootup (S20) I need the hostname to be set correctly even earlier.

So that would probably require some upstart job to run at S10.

So now I need to see how cloud-init is doing this and if it is early in the bootup.

Revision history for this message
Scott Moser (smoser) wrote : Re: [Bug 596993] Re: hostname handling needs improvement for elastic-ip and ebs start-stop

On Thu, 20 Jan 2011, Gerry Reno wrote:

> Running the following commands appears to correctly set all the forms of
> hostname on my Lucid ec2 instance:
>
> echo "$(curl -s http://169.254.169.254/latest/meta-data/local-hostname)"
> | sed 's:\..*$::' > /etc/hostname
>
> /sbin/sysctl -w kernel.hostname="$(curl -s http://169.254.169.254/latest
> /meta-data/local-hostname | sed 's:\..*$::')"

Gerry,
   Please open a new bug for whatever you see is not functioning correctly
in uname/hostname output. The first step is to get it fixed in the
development release (natty) then we can work on backporting.
   We can pull back the behavioral change made in this bug back to lucid,
but for other issues, please open new bugs.
   Thank you for your interest.
   Scott

Revision history for this message
Gerry Reno (greno-verizon) wrote :

Scott,
   I just tested a recent Maverick AMI and it does indeed correctly set the hostname to the newly assigned internal domain name after a stop/start sequence. So no need to open any other bugs on that score.
+ uname -n
ip-10-117-39-235
+ hostname -s
ip-10-117-39-235
+ hostname -d
ec2.internal
+ hostname -f
ip-10-117-39-235.ec2.internal
+ hostname
ip-10-117-39-235
+ echo ip-10-117-39-235
ip-10-117-39-235
+ cat /etc/hostname
ip-10-117-39-235
+ /sbin/sysctl -n kernel.hostname
ip-10-117-39-235

Now the question is how early in the boot process does cloud-init run?

With the changes in this bug, how can we make another boot process wait until cloud-init has completed setting up the hostname?

Revision history for this message
Gerry Reno (greno-verizon) wrote :

cloud-init does a lot of things. I guess what I'm looking for is whether cloud-init could be made to emit events as it works such that other upstart jobs can listen for those events and then use them to trigger their startup as opposed to waiting for the entire cloud-init process to complete.

eg:
cloud-init: initctl emit hostname

myjob: start on hostname

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in cloud-init (Ubuntu Lucid):
status: New → Confirmed
Revision history for this message
W. Andrew Loe III (loe) wrote :

Will these changes be backported to lucid?

Revision history for this message
Rolf Leggewie (r0lf) wrote :

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".

Changed in cloud-init (Ubuntu Lucid):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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