[lxc-devel] [PATCH] Update Fedora and CentOS templates for common conf includes.

[Serge Hallyn]

Quoting Stéphane Graber (stgraber at ubuntu.com):
> On Wed, Jan 22, 2014 at 11:38:29AM -0500, Michael H. Warfield wrote:
> > On Wed, 2014-01-22 at 10:35 -0500, Stéphane Graber wrote: 
> > > On Wed, Jan 22, 2014 at 09:29:23AM -0500, Michael H. Warfield wrote:
> > > > On Tue, 2014-01-21 at 20:25 -0500, Stéphane Graber wrote: 
> > > > > On Tue, Jan 21, 2014 at 11:56:56AM -0500, Michael H. Warfield wrote:
> > > > > > Update Fedora and CentOS templates for common conf includes.
> > > > > > 
> > > > > > This updates the Fedora and CentOS templates to utilize a common
> > > > > > included config.  This is largely based on the changes in the Oracle
> > > > > > template with some exceptions.
> > > > > > 
> > > > > > Dropping of setpcap (present in the Oracle template) is commented out in
> > > > > > the Fedora template.  It seems to cause problems, such as large login
> > > > > > delays with Fedora 20 containers (but not Fedora 19 - strange).
> > > > > > 
> > > > > > The Fedora template is further modified to disable systemd-journald.service
> > > > > > as it is unnecessary in a container and causes serious problems when
> > > > > > running in a Fedora 20 container.
> > > > > > 
> > > > > > The Fedora template is also updated to default to Fedora 20 when running
> > > > > > on a non-Fedora host.
> > > > > > 
> > > > > > Regards,
> > > > > > Mike
> > > > > > 
> > > > > > Signed-off-by: Michael H. Warfield <mhw at WittsEnd.com>
> > > > > 
> > > > > Acked-by: Stéphane Graber <stgraber at ubuntu.com>
> > > > > 
> > > > > I'll setup builds for CentOS 6.5 on amd64 and i386 and for Fedora 19 and
> > > > > 20 also on amd64 and i386.
> > > > > 
> > > > > I believe Fedora 20 also supports armhf but that one may need a bit more
> > > > > work to get going (do you know if your template works with armhf?).
> > > > 
> > > > Fedora does support armhf in mainline now.  Previously it was in aux.
> > > > The template was definitely working with Raspberry Pi armhf with
> > > > Fedora18.  That was before they created the "Pidora" respin which broke
> > > > the Fedora template thanks to the name change and some repo changes.
> > > > Since then, I've also done that distro agnostic bootstrap coding.  I
> > > > wouldn't be surprised if it was broken, but it should be close.  I'll
> > > > have to give it a shot on one of my RPi's.
> > > > 
> > > > Regards,
> > > > Mike
> > 
> > > The image build worked at least, I still need to actually test the
> > > resulting images to make sure they work though.
> > 
> > > Btw, any chance of getting -A working before 1.0 release?
> > 
> > Oooo...  Ouch...  Yeah, that place holder has been in there since long
> > before I first stuck my nose in there.  I can only foresee two cases
> > where that would even be possible.
> > 
> > Build i386 on x86_64 host
> > 
> > Build arm (software floating point - arm3, arm4, arm5) on armhfp
> > (hardware floating point - arm6+) host.  Except, arm is not in mainline,
> > only armhfp is, so it's doubtful this could be done in the short term.
> > 
> > I can see where the first case would be useful to you for building
> > download templates.  I'm not so sure how useful the second one would be.
> > 
> > Other cases would require hardware emulation.
> > 
> > I can't guarantee anything but I'll look at it, at least for the i386 on
> > x86_64 case.  It might be possible in the limited case to kick something
> > out quickly.  The CentOS template may actually be more complicated than
> > the Fedora template because I did the bootstrap logic and everything is
> > done in chrooted environments in the Fedora template that should cover
> > the arch jump.
> > 
> > ITMT, I've pinged Fredric over at Suse, privately, to see what we can
> > get done with the opensuse template.  You listed it as broken for your
> > download template due to a requirement of zypper (it also requires
> > "build") plus it needed conversion to use the common config includes and
> > you needed a base container tarball, iirc.
> > 
> > It's got more problems than that.  Using a prebuild OpenSUSE starting
> > container on my Fedora host, I've been able to build containers for
> > OpenSUSE 12.3 and 13.1 (latest) but both have systemd problems and
> > doubtlessly need autodev set up (the autodetection logic still keeps us
> > out of trouble and keeps us from blowing up a systemd host).  It's also
> > set up for a hardcoded version (12.3) with no version option.  :-P
> > 
> > That one needs some attention paid too it.  Ideally, maybe Fredric or
> > one of the other Suse guys can dig into it.  I've had my nose into it
> > just deep enough to think a lot of the yum logic SHOULD work and deep
> > enough to go "oh here there be dragons".
> > 
> > Regards,
> > Mike
> 
> I also just tested the Fedora template in unprivileged LXC and not too
> surprisingly systemd blows up to pieces, so I have removed Fedora from
> index-user so that lxc-download doesn't show it as available for
> unprivileged containers.
> 
> The little debugging I've done seems to indicate that:
>  - lxc.autodev doesn't work unprivileged

Yeah without looking at the code right now ISTR that the setup_autodev
only does mknod, and I did recently mention on the list that it needs
to fall back to create+mount --bind in the unrpivileged case.

Unprivileged case here won't mean geteuid() != 0 bc that will fail for
nested :)  we'll just have to try and mknod of /dev/null and if that
fails we know we have to bind-mount.

>  - systemd tries to mount things it's not allowed to
>  - it's possible to workaround some of the issue by mounting a tmpfs on
>    /dev but then LXC fails because of missing /dev/pts.
> 
> -- 
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com



> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel