[lxc-users] Several relatively new user questions:

[Ranjib Dey]

1) im doing most of the stuff using chef right now. i was using it in hosts
earlier, now inside container as well. one difference i am trying to adopt
is do the in-container change management from the host. i.e. the hosts's
chef client act as master to chef client's running inside the containers
its hosting. this way i get to reuse my existing chef scripts for user,
packages, services, external integrations etc.
2) iirc busybox is a smaller, minimalist distro. you can opt for ubuntu or
rel derived distros minimal installation as well. in fact the templates the
lxc ships with is fairly small. theres a ssh only template as well.




On Sat, Dec 7, 2013 at 7:05 PM, Galen Brownsmith <galens at capaccess.org>wrote:

> I've had less luck than I would expect with web searches for these
> questions, so I figure asking would be the best remaining option.
>
>
> 1) Are there any existing tools/scripts to help manage the user accounts
> on the host system and on a container?
> For instance, I have my webserver running in an LXC container.  I would
> like the container to be aware of the user accounts on my primary system,
> so that User-relative URLS would work (http://foo.bar/~username ), but
> there is no need for many system accounts to be present on the container
> (lp, uucp, dbus, pulse) as there is no desktop/those services would never
> be needed.
>
> I would like for, on container start, is to generate an /etc/passwd file
> containing the relevant system accounts (www-data, apache, root), and all
> the users.  In additionally, for the users, I would like it to replace the
> login shell for users not in the wheel group, with /bin/nologin.
> (similarly, I'd like to generate a shadow file with only the root and
> wheel-group users' passwords, and the samge for /etc/groups and
> /etc/gshadow).  Ideally, on container shutdown, it would detect any new
> system accounts, re-assign them a UID to ensure uniqueness, chown any
> relevant files to the new UID, and store the new system account on the
> host, but that may be more than necessary.  I would, ideally, not have to
> track separate passwords for the same account by distinct virtual machine,
> but that is what I may end up having to do.
>
>
> Alternatively, is there a better strategy?  I know there is the automatic
> UID renumbering options, but that disassociates a user's access rights
> on-the-container from their files-on-the-host.  I could also presumably do
> something with LDAP, but I'm trying to avoid requiring an LDAP server on my
> home/desktop system.
>
>
> 2) Does anyone have a documented list of the minimal package requirements
> for for an LXC container by distribution?  I'm certain there are packages
> installed that are unnecessary, but I don't know debian/ubuntu well enough
> to know which packages are safe to remove and which aren't.  I've tried
> going through the packages by hand, but that isn't terribly efficient and
> can still result in removing packages I shouldn't.
> (Similarly, is there a list of the minimal container-safe init scripts?
> Some are obvious, but other's aren't)
>
>
>
>
> Thanks,
>
> -- G
>
> For what it is worth, My system architecture:
> Base system: Fedora 19, LXC 0.9.0, Intel Core 2 Quad x86_64, 3.11.7 kernel
> Containers: ubuntu 13.10 (4 - ssh host, webserver /LAMP stack, mail host,
> media server)
>
>
> ----------------------------------------------------------------------
> That's the news from the Mystic River, where all the alliums are strong,
> all the degu are good looking, and all the stuffed animals are above
> average.
> "May the ducks of your life quack ever harmoniously" - A. Yelton
> galens at capaccess.org galens at marphod.net marphod at gmail.com & others
>
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20131208/54cc339b/attachment.html>