[Lxc-users] [lxc-devel] Working LXC templates? EUREAKA! I think I've got it!

[Tony Su]

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.

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.

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.

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)

A small FYI -
Although the Fedora template distributed with openSUSE which I've
included as an attachment to this message <does not work as is> 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 made the two following modifications
1. line 33 - added "release=18"
The comments in this script describe passing the release number as an
option to "lxc-create" but is not supported in openSUSE. Despite
unable to pass as a command line option, passing within the template
with this line works. BTW - If no release is specified, Fedora
defaults to earliest release in the repos(which is 14) rather than
latest.
2. Line 153 - The template hardcodes the RELEASE_URL string which is
created by appending a hardcoded string to the MIRROR_URL string, but
it appears that Fedora restructured their repos since this template
was created. Now, an "/f/" has to be inserted into the RELEASE_URL
(initial letter of the word "fedora").

Additional - Especially when connecting to repos of a Distro different
than the HostOS, GPG authentication keys are not yet installed. Have
been investigating whether it's possible to simply download ahead of
time and install into the default Key Ring or something more is
required. If this approach is feasable, then this needs to be added
early to the template script, but maybe a better method is for the
User to be prompted for an interactive answer to confirm key
installation.

Tony

On Sat, Sep 14, 2013 at 3:35 PM, Tony Su <tonysu at su-networking.com> wrote:
> Cool.
>
> I'll block some significant time to look at what you built over the next 3
> days.
>
> Tony
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lxc-fedora18
Type: application/octet-stream
Size: 11411 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20130915/37c8d7f4/attachment.obj>