[lxc-devel] Predictable root passwords in LXC templates

[Stéphane Graber]

On Thu, Jun 18, 2015 at 03:52:08PM -0500, Major Hayden wrote:
> On 06/18/2015 02:30 PM, Serge Hallyn wrote:
> > Quoting Stéphane Graber (stgraber at ubuntu.com):
> >> > I think ideally, I'd like for:
> >> > 
> >> >  - All templates to default to no password at all (no an empty password)
> >> >  - All templates to support a common set of environment variables or/and
> >> >    arguments to have passwords generated for them or to use passwords
> >> >    provided by the user
> >> >  - Have a way (possibly optional) for those credentials to be written
> >> >    down into a text file in the container's directory (for use by scripts).
> >> >  - Print a generic message to the user, advising them of any credential
> >> >    that was generated and that they can use lxc-attach to interact with the
> >> >    container without them.
> > That all sounds perfect.
> 
> Feel free to shoot down the idea, but since the LXC codebase already has some python in it, could we use something like Ansible to do the actual configuration of each container?  Ansible can take actions on a chroot as if it was a remote machine and its list of dependencies is fairly short.  This would allow us to steer clear of bash scripts which can become cumbersome over time.
> 
> What I'm suggesting is:
> 
>   1) Do the initial build with a template (install pkgs, basic configuration)
>   2) Complete the remainder of the configuration using Ansible
> 
>   -- OR --
> 
>   1) Have Ansible build the chroot and then configure it
> 
> We're already looking at making significant changes to each of the templates to make them more uniform and it seems like we'd be better suited to get into a framework which makes it easier to maintain uniformity over time.

Hi,

I'd rather not. In a perfect world, and we're getting closer and closer
to that, LXC wouldn't have to touch any file in the container, outside
of standard files as needed for user accounts and provisioning (with
cloud-init if available).

LXC touching any other file inside the chroot, as some templates are
doing today is generally a very very bad idea when you want your
containers to behave exactly like a regular installed system. Problems
typically include package upgrades stepping over the changes you've
made, or upgrades to the next version of the distribution failing very
badly due to files that shouldn't be there, ...


So I think we should aim at reducing the amount of differences between
the templates and their container configurations, for changes that they
are performing to the chroots that aren't strictly post-install
configuration, make sure that we have bugs open with those distros to
properly handle containers and so aim at getting rid of any such
supporting code.


With Ubuntu, we got to the point where we do not do any
container-specific configuration to the rootfs. That means you can boot
your container into a VM by installing a kernel inside it or you can
boot your VM's filesystem inside a container, no changes required and
everything is just detected and works by default.

That's where I'd like to see all the other distros go.
As painful as it was, the work to get systemd to play nice with LXC is
helping quite a lot in that regard for other distros. With recent
systemd (which most distros don't ship yet), everything should just work
out of the box and no configuration changes should be required to the
container anymore.

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20150618/4e06e325/attachment-0001.sig>