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.baum...@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 simplelxc. >> 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. bekir -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADJ2DMJPtCVCiSZoMHsdedsR4zg6VxR5fdzxO-nTAdW=80g...@mail.gmail.com
