Quoting Michael H. Warfield ([email protected]): > 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 ([email protected]): > > > 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 _______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
