[lxc-users] Made a few enhancements to centos templates

[Serge Hallyn]

Quoting Michael H. Warfield (mhw at WittsEnd.com):
> I'm going to make a few comments here and respond to the patch over in
> the -devel list in a bit.
> 
> For openers...  We should be thinking about changes like these in terms
> of all the templates.  Every time this comes, the templates are
> diverging from each other.  It's already a bit of a mess of conflicting
> short parameters and divergent long parameters.
> 
> Just a couple of months ago, we were discussing -r vs -R for "revision".
> Some templates use -R.  Some use -r.  Consensus was leaning toward -r
> (CentOS, Fedora, and Oracle use -R) but then Dwight noted that "-r"
> conflicted with the Oracle template's use of the -r parameter for the
> separate rootfs.  But, changing that to -p path for that results in a
> conflict with his use of -p for packages.  The discussion died down and
> no decisions were made.  I'm already leery of adding new command line
> options (comments have been made about API issues), especially ones
> which are not congruent with the other templates.
> 
> On Tue, 2014-03-11 at 22:40 -0500, Serge Hallyn wrote:
> > Quoting Mingjiang Shi (mrjewes at gmail.com):
> > > Hi All,
> > > I use the Linux container to build test environment for my project, so I
> > > made the following enhancements to the centos templates to make it easier
> > > for me.
> > > 1. Added option to not expire the root password
> 
> > yes please.
> 
> Question is, how?  When I did the code and set that up, we were having a
> discussion on how to harden that initial password, which is abysmally
> weak in most templates.  I added some tuning "knobs" and information
> output to harden those passwords.  I used tuning knobs (variables which
> could be overridden from the environment) in order to avoid some of the
> "feaping creaturisms" (creaping featurisms) [everybody loves their pet
> features] that seem to be a potential problem.
> 
> Some people had mentioned templates for the passwords and starting with
> the password expired.  Both options got a positive response and no
> negative feedback, so them both went in, along with allowing shell
> expansions in the password template.
> 
> I can easily add this as another "tuning knob", for password expiration,
> which could be customized on a site or host basis (or run by run basis
> from the environment).  I'm not convinced that adding another command
> line option is the best course of action here, but I could be convinced.
> The other templates (other than CentOS and Fedora) haven't even adopted
> a hardened password scheme yet, afaict.
> 
> > > 2. Added option to copy my host ssh public key to the container so that I
> > > can ssh the my containers without using password
> 
> > yes please.
> 
> This has been discussed several times in the past as well with people
> arguing both sides.  Personally, it is something I use, but I do it
> purely in post creating processing (along with additional user
> accounts).  I also, generally, disable "passwords" on the root user, so
> auth_keys are mandatory, but that requires modifying
> the /etc/ssh/sshd_config, which I'm not included to do in the template
> unless there's a good reason.
> 
> Ubuntu has this by specifying an authorized_keys file to be copied into
> the root user but uses a different parameter (-S) than you do (-s) and
> functions differently than your patch on the -devel list.  The Gentoo
> template appears to do the same thing as the Ubuntu template but I think
> I see a bug in that code that would prohibit it from even working but,
> since I can't build Gentoo containers on my Fedora hosts, I can't really
> confirm that now.
> 
> I'm not totally convinced that operation should be an internal,
> integral, part of the template itself.  It seems more like something
> that should be left broken out in a higher level, since it can easily be
> done "after the fact".  But I could be convinced as long as we all have
> a common way of going about it.

It becomes harder though as you complicate the backing store.

>From my pov, useful things to support include:

1. A stupid simple known password.  Once your lab is properly set up
you can script the fetching of generated passwords, but while you're
setting it up (in a secure network :) it can be a pain.

2. ssh-keys.  *preferably* with password-ed ssh disabled.

3. pre-generated password, with immediate expiry and password
stored on the host fs being optional.

I see the 'root_password' environment variable as an ok way to
implement (1) using (3).

We should support this for all (feasible) templates;  using the exact
same environment variables for each template;  each template should
continue to support the command line options it currently does;  if
any template which finds command line options specified also find
environment variable tuning knobs should print a warning.

Thoughts?  Does someone (or a team) want to take the job of
converting it all?  :)

-serge