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. > > 3. Added option to set static IP to the container > Should be fine. I'll leave discussion over this for the -devel list... > > 4. Added a script to create a bunch of containers and setup the hosts files > > so that they can be accessed via hostname. > I don't understand where this fits into the template. Are you intending > this as a separate tool or a part of the template? Please send it > separately and we can discuss. That has nothing to do with the CentOS template itself but is one of those higher level scripts I was referring to above. > > All the above changes are disabled by default, i.e. one need to pass extra > > option to enable them. > > > > Let me know if those changes can be contributed back to upstream. Thanks! > Definately. Please sent patches with a Signed-off-by to the lxc-devel > mailing list, and we'll gratefully review. I've review the patch and will comment on that side of the house shortly with my views. Every time this comes up, we return to the question of a uniform view of the templates and their parameters. Requests for templates features should be framed with a view of all appropriate templates and reuse as much of the code and paradigms from the other templates as possible. > -serge My 0.02 euro. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | [email protected] /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
_______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
