Bug#657678: ITP: simplelxc -- Minimalist package to create LXC guests and then manage them simply.
On 01/30/2012 09:26 PM, Bekir Dogan wrote:
> I have some more questions below. I'm sorry about long posts.
you're welcome, no problem.
> lxc-debconf is not included in upstream. Is there anywhere other
> than source lxc package to investigate/participate/generate patches
> about lxc-debconf.
i'm maintaining it (within the debian lxc source package) in a git repo
at http://vcs.progress-linux.org/?p=users/daniel/packages/lxc.git
> using ssh with a key makes it easy to login
> to a continer without thinking about what the user/pass is
personally, i think it is not too much to ask from a user to specify and
remember one passwort for a container. but ymmv.
> I thought that it should be easy to get in to the container and run some command
> in it if needed
there's lxc-attach and lxc-execute for the one or other case (some of
them depend on not yet mainlined kernel patches; but anyhow, this will
get solved at some point).
> which lxc-console can't do but ssh can, for example
> restarting sshd from host system. But this is not that important,
> lxc-consle should be enough.
well, using lxc-console requires one login at the first use. i might be
possible to do that non-interactively if needed, not sure. if that would
be possible, one could (even without the current restrictions of
lxc-execute/lxc-attach) do stuff within the container.
> You have a point about configuring services, but existing lxc creation
> script in both upstream and Debian package is also doing similar
> things.
i beg to differ; they only configure the minimal required things to make
a chroot 'bootable' as a container for lxc.
> lxc-debconf configures sources list, locales, networking,
> hostname, tzdata, rootpw, nameserver on creation.
just to be precise, most of the things that get done *within* the chroot
gets configured by linux-container, which is the only way to do this
properly and upgrade safe (not just for package updates, but also for
entire debian release dist-upgrades).
> But why not update
> these on cloning or why not show some handy parameters in "lxc info"
> of "lxc list". Or will I need to write my own scripts to collect this
> kind of information?
i'm not sure i understand what you mean, can you rephrase?
> If so, in this manner we should write a helper program
> to manage creation and management of containers along with some core
> services in it.
you mean like factoring out the 'common' things from lxc-debconf so that
it can be used by others? if so, then that doesn't make much sense imho.
lxc-debconf is debian specific, there is nothing in it that will be
usefull for non-debian based distributions.
handling the different debian distributions/derivatives is only a matter
of a different defaults, everything else stays the same anyway.
so.. factoring out wouldn't gain anything, imho.
> And also there is an other similar package "lxctl", which you are
> also the maintainer of, leads me the way simplelxc is going.
eventually, in my personal opition, lxctl will go away when lxc-debconf
supports those things that lxctl does and lxc-debconf doesn't (the
templating is a tad more customizable).
>> but that's basically what you're proposing.
>
> Do you think same for lxctl?
yes, absolutely.
> This is a bit harsh, but, yes :)
i didn't mean to, i just tried to make my point 'clear'. i hope you're
not offended.
> lxc-debian changed a lot
> in last few months and I didn't understand the main purpose of the
> tool and
sure, it's debian-unstable :)
lxc-debconf (see TODO file for more information) is done, there are a
few cosmetic and minor enhancments planed, but otherwise.. it's ready
for wheezy...
> there is a need for a more stable and working solution.
...please note that there are two things on the side, one is
lxc-debconf, and the other one is the packages in debian itself. as it
currently stands, not even wheezy will be released with all the bugs
fixed to work properly as a container for lxc. this is sad, especially
since i've filled bugs about it 1.5 years ago already. but that's out of
my hands. and also, it's not the task of lxc-debconf to fix bugs in
debian. it should create containers, not more, not less. if debian
doesn't work nicer in a container, then, well, that's a bug in the
respective package, but not in lxc-debconf.
> I should talk with you and upstream before developing simplelxc. But
> as many tech guys, I am also a bit asocial to prefer communication
> instead of creating a new project. (This can be my main excuse and
> mistake :)
sure, not that i blame you for anything :) i just wanted to make you
aware, that, in order to safe everyones time and work, it would be
better to not 'reinvent the wheel' once again.
> Which of these is true for lxc upstream?
> * only the userspace part of lxc in kernel, or
> * userspace part AND core management tools, or
> * userspace part AND management tools to manage the lxc containers in
> the host. "management" in the meaning of managing containers along
> with the core services on it, like networking, name resolution.
the second.
though, to avoid misunderstandings since you've written about that
above.. lxc also contains the scripts in order to create containers for
certain linux distributions.
in the case of debian, that naturally does have to include e.g.
populating /etc/apt/sources.list*, as this is a required step in order
to create a debian(based) container. and networking is essential as
well. but certainly, it's not the job of the template to e.g. configure
openssh, or apache, or any other service, unless the service is required
in order to 'boot' the container and have the network access enabled.
> in the case of simplelxc containers, security
> is not one of the primary issues, containers are not accessible from
> outside from the host, they are behind ip masquerade in the
> host. Simplelxc is not a solution for shared systems or production
> environments. Just for testing something in your pc.
if you want to test something, then it's vital that whatever you're
resting is not able to trash your host system. as it currently stands,
you can easily get root access on the host system if you have root
access in a container created by simplelxc.
such misconfiguration is not acceptable, both from an 'outside' point of
view, and absolutely not from a debian point of view. this is an rc bug,
and we will not include a package in a debian release having such flaws.
(again, no offence intended).
> Seems like you've forked the upstream with the "debian/local" in the
> package. I'm wondering why don't you develop lxc-debconf with
> upstream.
first, because daniel lezcado is terribly busy and i don't want to waste
his time with merge requests unless lxc-debconf has matured a bit in
debian itself (like i said in my previous mail).
second, although daniel is doing a good job as lxc maintainer, he's not
experienced enough with debian to make the debian template scripts good
enough.
third, lxc-debconf will not replace lxc-debian upstream wise, it will be
an addition that can, on debian systems, be used and should be used as a
replacement (it uses debconf, and if you e.g. want to create a debian
container on a fedora system, you would also require debconf to be
installed, not just debootstrap only; which might not necessarily
desirable).
fourth, lxc-debconf should also mainly replace the current lxc-ubuntu
(upstream wise), and, like i said in the previous mail, there's no point
yet upstreaming lxc-debconf as it not yet handles ubuntu.
but, like i said in the previous mail, i'll upstream it once it can
replace lxc-ubuntu as well.
> Do upstream developers know that you are developing this?
yes.
> I can't find a vcs, so what is the correct way of generating patches
> and sending them. Is it enough to use the source package in unstable
> repo to generate patch and post it to you.
i'd prefere patches (or, even better, a remote repo to merge from) based
on the debian branch from here:
http://vcs.progress-linux.org/?p=users/daniel/packages/lxc.git
--
Address: Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email: daniel.baumann@progress-technologies.net
Internet: http://people.progress-technologies.net/~daniel.baumann/
Reply to: