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.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- 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/4f270bd1.9060...@progress-technologies.net
