Upstart missing from centos6 line

[centos]

Upstart missing from centos6 line

[dimaspivak]

Any just FWIW, simply doing yum install upstart as part of our Dockerfile doesn't seem to resolve things, since there appears to be an issue with doing docker run -d --privileged=true -h HOSTNAME on the resultant image (the hostname doesn't actually get set). This wasn't the case (and continues to not be the case) for the centos6.6 tag.

[jperrin]

That part is very interesting, because beyond the missing upstart package the only thing I've done different was to use anaconda itself to create the tarball vs ami_creator. They should be doing the same things, but one is a part of the distro and the other is an obsolete tool that's not maintained.

[dimaspivak]

So just as an update, this issue still occurs and can be reproduced as follows:

1. Create a Dockerfile that installs upstart, openssh-server, and passwd (for setting the root password)

FROM centos:6.7

RUN yum update -y && yum install -y upstart openssh-server passwd
RUN echo "password" | passwd root --stdin

2. Build image: docker build -t testbrokenhostname .
3. Start a container from the image in daemon mode with command /sbin/init and specifying a hostname of first on the command line, saving the IP address into a variable:

THE_FIRST_IP_ADDRESS=$(docker inspect --format '{{ .NetworkSettings.IPAddress }}' $(docker run -d --hostname=first testbrokenhostname /sbin/init))

4. ssh "${THE_IP_ADDRESS}"
5. Run hostname and note that you see first
6. Exit out (^D) and start up a second container, this time in privileged mode:

THE_SECOND_IP_ADDRESS=$(docker inspect --format '{{ .NetworkSettings.IPAddress }}' $(docker run -d --privileged --hostname=second testbrokenhostname /sbin/init))

7. ssh "${THE_SECOND_IP_ADDRESS}"
8. Note that running hostname returns something like localhost.localdomain instead of second, which was specified.

As noted previously, in centos:6.6, which includes upstart, this isn't an issue. Perhaps there's something else missing from this image?

[dimaspivak]

Some investigating and I've found some workarounds (and think I understand where the problem is coming in). Basically, the centos6.6 and centos6.7 tarballs are very different insofar as their /etc/sysconfig/network-scripts/ifcfg-eth0 files. In particular, the centos6.7 one has the following:

DEVICE="eth0"
BOOTPROTO="dhcp"
HWADDR="52:54:00:49:CA:52"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
MTU="1500"
NM_CONTROLLED="yes"
ONBOOT="yes"
TYPE="Ethernet"
UUID="5b9d5724-dc26-45c6-bca5-916bbc484794"

while centos6.6 is much simpler:

DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=on

As it turns out, overwriting the file from centos6.7 with this simpler version fixes things for me. Perhaps the kickstart scripts' updated network arguments (--activate --onboot=on was added between centos-6.6.ks and centos-6.ks) could be the culprit?

[jperrin]

This is something I'll look into fixing in the next build of the '6' container. the minor point containers (6.6, 6.7 etc) don't get updates by design. If/when 6.8 comes around, it should be resolved there as well.

[dimaspivak]

Thanks, Jim. I think I understand now that this shows up because, in privileged mode (or with CAP_SYS_ADMIN as an allowed capability), the container is able to run the /etc/rc.d/rc.sysinit script, which, in part, sources /etc/sysconfig/network (which contains a HOSTNAME=localhost.localdomain line). Where /etc/sysconfig/network-script/ifcfg-eth0 comes into play here is unclear to me, though, so if you ever do figure out this part of the puzzle, I'd love to hear it.

[mengesb]

@jperrin I'm currently using centos:6 in my kitchen-dokken work on chef-compliance, and I can verify with you that in privileged mode (needed because of sysctl settings) the hostname is still not set; however in centos:7 this does work.