[Lxc-users] Fwd: Working LXC templates?

[Tony Su]

---------- Forwarded message ----------
From: Tony Su <tonysu at su-networking.com>
Date: Wed, Sep 4, 2013 at 10:23 AM
Subject: Re: [Lxc-users] Working LXC templates?
To: mhw at wittsend.com
Cc: Frederic Crozat <fcrozat at suse.com>, lxc-users
<lxc-users at lists.sourceforge.net>, lxc-devel at lists.sourceforge.net


Thx for the thoughts, Michael...

Would like to know specifically what you believe is incompatible
running 0.8.0 with systemd.

I have not noticed any issues running openSUSE 12.2 (systemd v44?) and
openSUSE 12.3 (systemd v195) on an openSUSE Host.

I've been able to run systemd commands (typically systemctl and
journalctl) from within the Containers without an issue most of the
time without issue and in the rare cases something didn't work I've
typically guessed it was just a potential security issue.

I'm guessing that running systemd both fundamentally and using its
various associated commands should not be an issue by simply applying
namespaces (personally have been speculating on the use of simple
random strings instead of user-readable text strings for security
reasons).

Based on the various templates I've tried, this issue is likely
related to how complete and self-contained the container template is,
the less it bind mounts or otherwise re-uses the Host system beyond
/proc I consider the template more agnostic. Binding Host resources is
what causes agnostic problems despite its various benefits.

The reason why a specific repo URL wouldn't be useful is because
interestingly Fedora's installation only looks up a Host which based
on the install's world-wide location and type of proposed installation
returns a recommended URL pointing to some repo mirror. This means
that there is no point testing against any of the mirror URLs, they
should all operate the same way. The URL I provided should be the only
relevant and critical URL the install template needs to use correctly.

As for why the authentication (GPG?) check isn't working, I haven't
dived into exactly what package is being used... But IMO it would make
sense in this pre-install environment, the Host's function is being
used and openSUSE does require User verification (unless the "silent"
switch is invoked which now that I'm thinking about it could be the
answer to my specific situation but may not address other distros).
Hmmmm... so, maybe I have something to experiment with...

Thx,
Tony









On Wed, Sep 4, 2013 at 6:40 AM, Michael H. Warfield <mhw at wittsend.com> wrote:
>
> This issue really belongs on -devel since it's a template development
> issue that really impacts all the template writers.
>
> On Tue, 2013-09-03 at 09:26 -0700, Tony Su wrote:
> > Thx all for the replies,
>
> > - lxc-version returns 0.8.0. Looking around, there might be a more current
> > unstable, but AFAIK it's the most recently released stable.
>
> This is not going to work.  0.8.0 will not support systemd in a
> container, which all recent supported versions of Fedora are going to
> require.  0.8.0 may be the more recently released stable "FROM OpenSuse"
> but it is not the more recently release stable from LXC.  The most
> recently released stable from LXC is 0.9.0 and even that doesn't have
> some of the necessary patches to the Fedora Template.  Your best bet
> would be to built from the stage branch in git.
>
> You may need to wait until we release 1.0.0 and I'll take some of your
> thoughts into consideration for the Fedora template but I have no way to
> test them on OpenSuse at this time.  Once we release 1.0.0, you'll still
> have the problem with what OpenSuse releases as their stable.  We have
> no control over what they decide and do.
>
> > - I'd have to re-run to get the SSL error again but I think I've described
> > its error accurately, no further explanation except that the identity of
> > the remote server cannot be authenticated. This would lead me to guess that
> > the server is not registered properly with a public CA (eg using a CA root
> > that isn't in a bootstrap Fedora) so guessing that perhaps an option should
> > be offered that allows over-riding authentication? SSL encryption of course
> > should still be implemented for security.
>
> Well, I can give you an argument if the error was described accurately
> enough.  I didn't see any site names I could test to see what the root
> CA is.  Without that, I can't tell you why you're seeing that error.  I
> understand fully what the error is (having my own private CA for private
> activities) but I can't determine the origin without knowing the source.
>
> <WAG - Wild Ass Guess>
>
> I suspect that their certs are properly signed by a CA particular to the
> Fedora Project and properly contained in the Fedora rpm root store, so
> it may really be yet another cross distribution issue that depends on
> the distribution peculiar packages and configurations.
>
> Since there's probably no need (I see no need) for the Fedora
> Repositories to be "registered properly with a public CA" (and pay the
> extra expense), I would say the term "properly" is missued in this case.
> The rpms are all signed by the Fedora Project and their gpg key so,
> integrity shouldn't be an example unless someone intercepts the original
> rootfs build and provides a trojaned package with the gpg keys.
>
> </WAG>
>
> Since this is an inter-distribution issue, I'm not sure what the proper
> solution would be (assuming my WAG is true) or what LXC can do to
> address it.  I also don't know why Ubuntu / Debian is not experiencing
> this problem either.  But, without some example names of specific sites
> exhibiting this problem (I don't run OpenSuse) I have no way to
> investigate further.
>
> Yeah, we could probably add an option to the template to ignore the SSL
> check or to use and alternate rootca store (if we can avoid the
> catch-22) but it may be better to investigate a more generic,
> distribution agnostic, solution to these types of problems.
>
> I do think it is an issue with the whole "distribution agnostic
> template" problem that may require some help from the distros or some
> innovative ideas of how we can bootstrap distros using distro agnostic
> tools (like stone knives and bear skins style install of the rootfs
> using nothing more than tar, gzip, gpg, and curl or wget).
>
> > - The lxc-create issue is definitely there. At first, I encountered it
> > using the openSUSE YAST LXC container applet. but then when I invoked
> > lxc-create from a console, but the "help" verifies it supports few options
> > and not these. But, as I described if the template requires parameters,
> > it's also possible to simply provide them in the script instead of at
> > runtime as command switches (but might not be apparent at first to someone
> > reading your script).
> >
> > Tony
>
> Regards,
> Mike
> --
> Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
>    /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
>    NIC whois: MHW9          | An optimist believes we live in the best of all
>  PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!