[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#657678: ITP: simplelxc -- Minimalist package to create LXC guests and then manage them simply.

Hi Daniel;

I have some more questions below. I'm sorry about long posts.

lxc-debconf is not included in upstream. Is there anywhere other
than source lxc package to investigate/participate/generate patches
about lxc-debconf.

On Sat, Jan 28, 2012 at 19:53, Daniel Baumann
<daniel.baumann@progress-technologies.net> wrote:
>> ...
> that's not a problem either; we can have debconf priority automatically
> set to critical and frontend to non-interactive based on e.g. the
> invokation name; such as 'lxc-create -t debian-simple'. if you insist,
> this can even be a shortcut be in /usr/bin for that.
> ...
>> * Simplelxc access to and controls continer's hostname, ipaddress and
>>   continer ssh authorized key when needed. (info, list, create and
>>   copy)
> i think that's wrong; users should use lxc-console, or configure openssh
> themselfs. it should not be the job of any lxc container creation script
> to /configure/ services.
>> Actually in my opinion many of these are shouldn't be done by lxc.
>> But a wrapper like simplelxc is much more suitible for this.
> why?

simplelxc is trying to isolate users from any kind of problems which
prevents them to use it, using ssh with a key makes it easy to login
to a continer without thinking about what the user/pass is, I thought
that it should be easy to get in to the container and run some command
in it if needed 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.

You have a point about configuring services, but existing lxc creation
script in both upstream and Debian package is also doing similar
things. Seems like simplelxc adds only an ssh-key in
addition. lxc-debconf configures sources list, locales, networking,
hostname, tzdata, rootpw, nameserver on creation. 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? 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. Instead of going on with simplelxc, maybe I can
help lxc upstream/package for creation process and I should write a
kind of helper tool for other needs if they are still needed. What do
you think about this?

And also there is an other similar package "lxctl", which you are
also the maintainer of, leads me the way simplelxc is going. In my
opinion simplelxc seems like a light and user friendly version of
lxctl which targets pc users rather than servers.

>> My intention is not to replace lxc creation and mangement utils in lxc
>> package but when I've started to develop simplelxc idea
> but that's basically what you're proposing.

Do you think same for lxctl?

> there are so called lxc templates (the scripts that setup a container,
> for debian, using debootstrap). the one in debian, named lxc-debconf and
> accessible through 'lxc-create -t debian' or 'lxc-create -t progress' is
> rather sophisticated. it allows to completely non-interactively create
> containers with a preseed file, or asking all questions to the user
> through debconf at the same time if he uses to make use of that.
> to make lxc-debconf behave exactely like simplelxc, there are only a
> handful of lines required, and you get all the rest that it /can/ do and
> what it does best for free. rather than making use of that, and
> extending lxc-debconf, you need to replicate and maintain all the basics
> of creating a debian based container from scratch.
> or, to put it arrogantly over exagerating: it's not a good idea to try
> to rewrite lxc-debconf just because you don't like one default in it's
> option.

This is a bit harsh, but, yes :) I can say that this is halfly true
with one note: Rather "I don't like it" it is "I coldn't trust
it". I'm not saying this to disturb you but lxc-debian changed a lot
in last few months and I didn't understand the main purpose of the
tool and there is a need for a more stable and working solution.

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 :)

The right place to ask this question is the upstream but you are the
maintainer also, I think you have an idea (and I'm still asocial).
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.

> regarding maintainability: lxc-debconf is quite mature as it's tested in
> many, many use cases. i had a look at your creation method, and i must
> say it's inherently insecure, even the most basic things are missing to
> prevent taking over the host system from within the container. if you
> intend to continue simplelxc, i suggest you have a look at what
> lxc-debconf does (and reuse that).

This seems a bit offensive.  I've started with copying the core of
lxc-debian script. But 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. But you are still
right about maintainability and security issues. I will be copying the
solutions in the core lxc package constantly if I want to go on with

>> But at first I was not sure about lxc-debconf
>> development speed, it does not coming from upstream
> once lxc-debconf works also for ubuntu systems (there are two things
> missing for that, the ubuntu specific defaults in lxc-debconf itself,
> and upstart support in linux-container; both will happen in a couple of
> weeks) and thus replacing lxc-ubuntu too, i'll work on mainlining it
> upstream.

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.  Do upstream developers know that you are developing this?
May be it's just the way it is evolved in time. I'm not experienced in
this kind of situations about open source projects.

>> Then it asks confusing questions like preseed file, distribution,
>> archives, mirrors, archive areas for many users who are not familiar
>> with debian. But many users just want to get a running container don't
>> want to know which dist ribution they are using or not interested in
>> using mirrors.
> like i said; making the debconf priority in a 'simple' wrapper isn't a
> problem, that way it would be reduced to the following:
>  lxc-create -t debian-simple -n example.org
> and users would not see any question at all, while the same code is
> running in the 'background'.
> and right, the debconf texts should be explaining what it's all about
> and what values should be entered for what reasons. just didn't got
> arround doing that yet, patches welcome :).

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.


Reply to: