Re: [lxc-devel] [Lxc-users] Working LXC templates? EUREAKA! I think I've got it!
On Sun, 2013-09-15 at 16:17 -0700, Tony Su wrote: > Hello Michael, > > First a comment on problems with systemd you descrbe. > I probably have run into many of the things you itemized, but since my > time is usually focused on something I'm trying to use LXC and not LXC > itself, I usually just drop any further attempts and move on to find a > workaround(eg consoles) or use a different technology(x server issue). > > Regarding many of the issues you describe though, I wonder if they > couldn't be addressed with more strict enforcement of using namespaces > (and less often cgroups). I've read how namespaces are supposed to be > an extremely powerful means of isolating processes and yet I don't see > any obvious indications it's being done consistently... by either > prepending to standard process or service names (if the goal is to > easily identify the namespace) or using a random string (if the goal > is better security so exploits can't anticipate commonly used > namespaces). > > In fact, I think I see this namespace issue in various parts of the > template you created. If I understand what is happening, there are > numerous places where you create special nodes on the HostOS instead > of > (a) using the existing HostOS nodes but using namespaces to isolate > Container processes > (b) creating nodes entirely within the Container which would make the > Container entirely portable but lose the benefit perhaps of the better > ways nodes are created and mounted today(eg tmpfs in RAM). > > Diving more into your template code, I applaud your effort, it's > significant and no minor effort. > > As of this moment, I've mainly been perusing what I might call "HostOS > Container Pre-Install," the part which precedes the actual > installation and relies on components running in the HostOS only. This > would be your script approx lines 0-410. > 1. I like your method of identifying whether the OS is Fedora, and > additionally whether is ARM or not. That was an effort working on my Raspberry Pi's. > 2. It looks like you're configuring networking binding directly to > eth0. I would recommend instead supporting the use of Linux Bridge > devices, make declaration of a bridge device name as one of the early > Global Parameters, then if exists to bind to that device by name. Your > code to bind to the physical interface is less flexible but can be a > default option if no bridge device is specified. Original code. I haven't really looked it it. As far as bridges and all go, much of that is in the greater LXC setup and the default settings in /etc/lxc/default.conf and outside of our control. > 3. Interesting that you include an option for "nm controlled" yet at > least initially I don't see where your code might rely on this > setting. My code does not. In the back of my mind, the setting for NetworkMangler control is something that is used internally to the container and we're merely setting a default value. > 4. mknod I'll have to take a closer look whether and why you appear to > be setting up various consoles, some /dev/ nodes, an explicit console > path, more. I've generally been under the impression that a full > install automatically creates these. Peeking a bit ahead of where I've > been reading your script, I notice your install method uses a > pre-built squashfs image, perhaps these are a special requirement > because your chosen squashfs image doesn't include these by default or > requires those nodes to already exist? > 5. Your use of yum will work in the RH family plus various others like > openSUSE but I don't think it's native to distros like the Debian > family. IMO there is no special benefit to using a package manager > specific to the HostOS to download bootstrap images and packages, they > aren't too relevant to the overall apps running in the HostOS and I > think we should avoid installing non-native packages in any OS. For > that reason, I've been looking at pycurl, curl and wget which are > generic apps common to all distros which can accomplish the simple > task of retrieving the bootstrap objects. (See the template I included > as an attachment which uses pycurl and finds fedora repos rather than > installing a pre-built img) Because yum (and rpm) are no ONLY and EVER executed in a chrooted environment, they are executing in a Fedora context and independent of the host environment. That's the whole point, it never execute the distro-dependent components in the host environment and only execute distro-agnostic (independent) components in the host environment. > A small FYI - > Although the Fedora template distributed with openSUSE which I've > included as an attachment to this message it > might be useful to see a different way of obtaining and installing > Fedora bootstrap packages so I've included it as an attachment to this > message. I've said this before. Take it to the bank. The template that is distributed with OpenSuse is OUT OF DATE AND WILL NOT WORK! In fact, the ent
Re: [lxc-devel] [PATCH] lxc-create: conside create succeed when container is already created
Quoting Qiang Huang (h.huangqi...@huawei.com): > On 2013/9/17 11:27, Serge Hallyn wrote: > > Quoting Qiang Huang (h.huangqi...@huawei.com): > >> On 2013/9/16 12:23, Stéphane Graber wrote: > >>> On Mon, Sep 16, 2013 at 11:37:02AM +0800, Qiang Huang wrote: > Sometimes we use: > lxc-create -n xxx -f config > to copy config to the default lxcpath with the rootfs already > exist. > But we will get error right now, so fix this. > >>> > >>> Hmm, I'm not sure I understand. > >>> > >>> Running "lxc-create -n xxx -f config" when xxx already exists is an > >>> error and should return an error code so the current code seems > >>> perfectly right to me. > >> > >> Well, it did works this way in the former lxc_create version. > >> > >> We used to use LXC this way: > >> - We made a template(rootfs, config and fstab) manually. > > > >>From here, can you just write a script 'lxc-homebrew' which > > copies the rootfs+config+fstab into place, and call > > > > lxc-create -t homebrew -n c1 > > > > ? > > > > If you want to just copy the stuff in by hand, you can > > do that. You don't *have* to run lxc-create if you've done > > everything by hand. > > OK, thanks Serge. > > So we are still not supposed to use lxc-create without -t option? I just don't see the point, and I worry that people using the common case will end up accidentally deleting existing container data. Well, the current code says /* container is already created if we have a config and rootfs.path is accessible */ if (lxcapi_is_defined(c) && c->lxc_conf && c->lxc_conf->rootfs.path && access(c->lxc_conf->rootfs.path, F_OK) == 0) goto out; Maybe what we want to do is add a '&& access(c->configfile, F_OK) to that test? I think that would give you what you want, and I think it's what I really meant to say. > Is lxc-create only used for creating templates? For running template scripts. Near as I can tell the only thing you want lxc-create to do is to copy a file (the config file). That just seems like way overkill. -serge -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Lxc-users] Working LXC templates? EUREAKA! I think I've got it!
Regarding
LXC and the use of Linux Bridge devices for configured networking,
At least on openSUSE, LXC is not configured with any /etc/lxc/* by
default, and possibly because I also have libvirt configured to
support LXC (although that is not working on my system).
>From what I've seen though, I cannot see why configuring networking
should be in a general lxc configuration file, or even if it should
exist I see it as reaasonable to configure within a template(why not
point the build to a pre-existing virtual network complete with its
own configuration?).
In any case as I noted before, pointing the Container interface to a
pre-existing virtual Linux Bridge device instead of a physical
interface in the template should be nearly trivial. If you wanted to
support bridge creation and configuration, that'd be a big project
outside the scope of what I'm describing.
yum and chroot. H. From what I can see, at the point you invoke
yum, nothing has yet been downloaded so any functionality you invoke
must exist in the HostOS. Despite running in the chroot environment, I
can't see how yum can work unless it's also present in the HostOS.
Maybe if I test this on a distro that doesn't support yum natively
I'll find different, but based purely on perusing the code I can't see
how it would work otherwise.
line 155
chroot ${rootfs_path} yum --releasever=${release} -y install fedora-release
Requirement for GPG keys
Again, based at this point purely on perusing and not actually testing
the code on an appropriately set up system, unless the repo is
configured without keys or the retrieval utility is configured not to
require key verification, I don't see how you've avoided this
requirement, particularly in this case you're using "yum" which is a
repo client utility. This is aside from verifying the downloaded image
whose integrity could be verified easily by invoking and comparing
checksum values if desired. I'd recommend no verification, though
because it would add maintenance issues. A superior solution might be
a file transfer transport that automatically does checksum (like
torrent but that opens up potential issues since some ISPs block
torrent indiscriminitately).
Regards,
Tony
On Tue, Sep 17, 2013 at 6:34 AM, Michael H. Warfield wrote:
> On Sun, 2013-09-15 at 16:17 -0700, Tony Su wrote:
>> Hello Michael,
>>
>> First a comment on problems with systemd you descrbe.
>> I probably have run into many of the things you itemized, but since my
>> time is usually focused on something I'm trying to use LXC and not LXC
>> itself, I usually just drop any further attempts and move on to find a
>> workaround(eg consoles) or use a different technology(x server issue).
>>
>> Regarding many of the issues you describe though, I wonder if they
>> couldn't be addressed with more strict enforcement of using namespaces
>> (and less often cgroups). I've read how namespaces are supposed to be
>> an extremely powerful means of isolating processes and yet I don't see
>> any obvious indications it's being done consistently... by either
>> prepending to standard process or service names (if the goal is to
>> easily identify the namespace) or using a random string (if the goal
>> is better security so exploits can't anticipate commonly used
>> namespaces).
>>
>> In fact, I think I see this namespace issue in various parts of the
>> template you created. If I understand what is happening, there are
>> numerous places where you create special nodes on the HostOS instead
>> of
>> (a) using the existing HostOS nodes but using namespaces to isolate
>> Container processes
>> (b) creating nodes entirely within the Container which would make the
>> Container entirely portable but lose the benefit perhaps of the better
>> ways nodes are created and mounted today(eg tmpfs in RAM).
>>
>> Diving more into your template code, I applaud your effort, it's
>> significant and no minor effort.
>>
>> As of this moment, I've mainly been perusing what I might call "HostOS
>> Container Pre-Install," the part which precedes the actual
>> installation and relies on components running in the HostOS only. This
>> would be your script approx lines 0-410.
>
>> 1. I like your method of identifying whether the OS is Fedora, and
>> additionally whether is ARM or not.
>
> That was an effort working on my Raspberry Pi's.
>
>> 2. It looks like you're configuring networking binding directly to
>> eth0. I would recommend instead supporting the use of Linux Bridge
>> devices, make declaration of a bridge device name as one of the early
>> Global Parameters, then if exists to bind to that device by name. Your
>> code to bind to the physical interface is less flexible but can be a
>> default option if no bridge device is specified.
>
> Original code. I haven't really looked it it. As far as bridges and
> all go, much of that is in the greater LXC setup and the d
Re: [lxc-devel] [PATCH RFC] split up use of process_lock, and make process_lock return void
I have a rather large patch which does a great deal to improve the concurrency. The last deadlock I was getting was actually due to sometimes fork()ing with process_lock() held. In the child, which no longer shares with the parents, that will never get raised. I will test a bit more and hopefully send out a patch tomorrow. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
