[CentOS-devel] CentOS-6.4 OpenStack testing cloud images

[Juerg Haefliger]

Hi KB,

Sorry for the delayed response, I wasn't subscribed to the devel list.
I'm also replying to some of the comments that other users posted.
Sorry for messing up the thread.

I tested your image in OpenStack Havana with KVM so my comments are
very much OpenStack centric.


> Hi,

> CentOS-6.4 i386 and x86_64 images targetting OpenStack are now available
> for testing at http://dev.centos.org/centos/hvm/ Images are available
> for KVM, Hyper-V, VMware, Xen and any other HVM hypervisor.  Although,
> the 6.x kernel has the pv support enabled, so should work fine under
> paravirt Xen as well.

> Images are published as raw, qcow2 qcow2compressed and vpc ( vhd ) for
> both i386 and x86_64 CentOS-6.4 The images represent media versions, and
> have not had an update run against them. Its highly recommended that in
> testing, please check this version *then* do a yum update and repeat
> tests to ensure that there is no test result change in the 6.4+updates
> tree's.

> Keeping in line with the general CentOS Cloud strategy, ie to help
> people migrate or investigate cloud instances, we expect the images to
> represent as close as possible to a real machine CentOS install ( ie. no
> cloud specific user, people use root to login, selinux is enabled ).

I'd prefer a non-root default user to be inline with the other
community images. IMHO it's a convenience to not have to create a
non-root user after spinning up an instance. But cloud-init will take
care of all that for you, if you configure it correctly, which doesn't
seem to be the case in your image. I.e., cloud-init creates a
'cloud-user' and disables root login but for some reason the
cloud-user is not allowed to sudo (should be handled by cloud-init) so
there's no way to gain root permissions.

In general, the cloud environment has no business in mocking with a
guest image. Yes, OpenStack is still injecting keys but that is likely
to change (I believe). It should be up to the instance to configure
itself which is what we have cloud-init for. In terms of users, I vote
for:
- A 'centos' default user without a password (no console login) and
password-less sudo permissions. This follows Fedora and Ubuntu and to
some degree Debian conventions. IIRC Debinan uses 'admin' as the
default user.
- Disabled root login and certainly no standard well-known password
which is simply a security disaster waiting to happen.

I'm not too crazy about SSH password access and cloud-init disables
that as well (unless you tell it not to).

In general, a cloud image should be as locked-down as possible to
reduce the risk of somebody else taking over your instance before you
can get to it. Providing SSH key access is the preferred method.
Everything else can be enabled later or when the instance is launched
(for example by providing a configuration script that cloud-init
executes on first boot). Similarly, selinux should be enabled by
default. The firewall can be discussed. I think it's not required
since the cloud environment already provides that functionality and
you have to specifically open ports to get access to your instance.

As for console logins, why would we want that in the base image? Can
somebody give a use case? I just don't see it as useful. We have SSH
access and as mentioned everything else required/desired should be
enabled/configured once the instance is up. If SSH access doesn't work
after first boot, then there's something fundamentaly broken and
console access will most likely not work either.

LVM: What's the rational for using LVM? It's not like we can just add
another disk to the instance and add it to the volume. IMHO it just
adds unnecessary overhead and breaks the growroot functionality.
dracut-modules-growroot (which I maintain in EPEL) doesn't support
LVM.

swap: Providing a swap device in a cloud image is debatable as well.
Some clouds charge for IOs and you don't want to pay for swap activity
so the cloud images I'm aware of don't have a predefined swap device.
Again, it can always be added later if need be.

console: As mentioned by others, please add 'console=tty1' to the
kernel commandline to get some messages on the virtual console:
'console=tty1 console=ttyS0' (See
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1016695 for
the rational to use tty1 instead of tty0).

If you try to make this image as close to regular CentOS as possible,
you might confuse other cloud users that are used to certain things in
other cloud images. Although those 'things' are not standardized and
we're not required to follow them. It's a balancing act, I guess.


> CentOS-6.4-i386-Minimal-OpenStack.image.qcow2c.bz2
> CentOS-6.4-x86_64-Minimal-OpenStack.image.qcow2.bz2

Why the bzip2 compression on top of qcow compression? It doesn't
create much smaller files and requires and extra step after
downloading the images. No big deal, though.


> Enjoy!

Good work!

...Juerg