Re: [lxc-users] Convert LXC Guests from privileged to unprivileged

[Wolfgang Bumiller]

> fwiw lxd also ships with 'fuidshift' which has the same functionality.

After a quick glance over the code I only see it handling file ownership.
What about ACLs? (And perhaps other extra attributes I'm unaware of.)

I was thinking the most "complete" conversion happens when you tar up the
container in one namespace, with -p --acls --numeric-owner --xattrs etc.
and then unar it in the other namespace. This however fails to extract
device nodes into user namespaces... ;-/

(Offtopic: I'm still puzzled by the fact that mknod doesn't work in a
usernamespace. There's a capability for _just_ _that_ after all, and
there's the devices cgroup. I'd much rather have a rule that a non-zero
user starting a userns doesn't gain CAP_SYS_MKNOD unless it's already
there.)

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] setproctitle error doing an lxc-start

[Peter Steele]

On 12/02/2015 03:01 PM, Stéphane Graber wrote:

On Wed, Dec 02, 2015 at 02:56:51PM -0800, Peter Steele wrote:

 From the searches I've done this seems to be a known issue but I'm
not clear what the solution is. I'm using LXC 1.1.5 under CentOS 7.1
and created a container using

# lxc-create -t centos -n test1

This completed without issues. I followed this up with a start command:

# lxc-start -n test1
lxc-start: utils.c: setproctitle: 1461 Invalid argument - setting
cmdline failed
lxc-start: lxc_start.c: main: 344 The container failed to start.
lxc-start: lxc_start.c: main: 346 To get more details, run the
container in foreground mode.
lxc-start: lxc_start.c: main: 348 Additional information can be
obtained by setting the --logfile and --logpriority options.

I had earlier been using LXC 1.0.7 and did not get this error when I
ran lxc-start. Do I need to role back or is there a workaround?

Peter

The setproctitle error can be ignored, we've silenced it later. It
doesn't actually affect container startup at all, so your failure is
coming from something else.

Please follow the recommendations in the error message and re-run your
lxc-start with the -F flag to get the actual error message.
I realized the issue at 3:00 am (couldn't sleep). The default centos 
template is configured to use lxcbr0 whereas my servers have br0. I just 
changed the container's config to use br0 instead and the container came 
up without issues (other than this setproctitle error that apparently 
can be ignored).


The important thing is that udev is not running, unlike my earlier 
tests, so I'm making progress.


___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] Juju, LXD, Snappy, Raspberry pi

[Matthew Williams]

Me again folks,

Just for fun:

Now that lxd provider support is in juju, and there is a snap for lxd. I
wondered if it would be possible to use juju to deploy lxd units on a
raspberry pi 2.

Here's the result:
http://blog.mattyw.net/blog/2015/12/02/juju-lxd-snappy-pi/

Matty
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Juju, LXD, Snappy, Raspberry pi

[Matthew Williams]

Hi Sam,

That's a very good point, in theory that is possible yes, It's actually one
of the other experiments I'm trying, I've not as yet been able to setup
port forwarding on snappy to be able to access the containers from outside
the pi, or been able to get the containers to get a dhcp address from my
home router, but these are things I'm also playing with

Matty

On Thu, Dec 3, 2015 at 1:50 PM, Samuel Cozannet <
samuel.cozan...@canonical.com> wrote:

> Hi Matthew,
>
> Great stuff, thanks for sharing :)
>
> Quick question, if you set the LXD provider to work remotely, do you
> really need to compile Juju to run on the rpi? Can't it run from the
> laptop, with a rpi2 being just the target?
>
> Thx,
> Sam
>
>
> --
> Samuel Cozannet
> Cloud, Big Data and IoT Strategy Team
> Business Development - Cloud and ISV Ecosystem
> Changing the Future of Cloud
> Ubuntu   / Canonical UK LTD  /
> Juju 
> samuel.cozan...@canonical.com
> mob: +33 616 702 389
> skype: samnco
> Twitter: @SaMnCo_23
> [image: View Samuel Cozannet's profile on LinkedIn]
> 
>
> On Thu, Dec 3, 2015 at 2:19 PM, Matthew Williams <
> matthew.willi...@canonical.com> wrote:
>
>> Me again folks,
>>
>> Just for fun:
>>
>> Now that lxd provider support is in juju, and there is a snap for lxd. I
>> wondered if it would be possible to use juju to deploy lxd units on a
>> raspberry pi 2.
>>
>> Here's the result:
>> http://blog.mattyw.net/blog/2015/12/02/juju-lxd-snappy-pi/
>>
>> Matty
>>
>> --
>> Juju mailing list
>> j...@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Converting from libvirt lxc

[Peter Steele]

On 12/02/2015 08:47 PM, Fajar A. Nugraha wrote:
On Thu, Dec 3, 2015 at 1:14 AM, Peter Steele > wrote:



On 12/02/2015 07:23 AM, Fajar A. Nugraha wrote:

On Wed, Dec 2, 2015 at 9:49 PM, Peter Steele mailto:pwste...@gmail.com>>wrote:

On 12/01/2015 08:25 PM, Fajar A. Nugraha wrote:

Is there a reason why you can't install a centos7 container
using the download template? It would've been MUCH easier,
and some of the things you asked wouldn't even be an issue.




lxc-create -t centos -n test1

to create a container using the centos default settings. The
resulting config file doesn't look a whole lot different than my
manually crafted version.



You DID notice that repeatedly say "DOWNLOAD template"? as in someting 
like


# lxc-create -t download -n c7 -- -d centos -r 7 -a amd64

The template was downloaded automatically when I ran the lxc-create 
command the first time. Is there a difference in how the download is 
done using the command you've listed above?




Short version: if you use 
http://copr.fedoraproject.org/coprs/thm/lxc1.1/ , you need to do some 
things first:

- edit /etc/sysconfig/lxc, USE_LXC_BRIDGE="true"
- systemctl enable lxc-net
- systemctl enable lxc
- systemctl start lxc-net
- brctl show
- ip ad li lxcbr0
If you HAVE lxcbr0 with the default ip 10.0.3.1 (you can change this 
later), you're all set. If not, doublecheck your setup.
If you're asking "where's the docs that mention this", as the package 
manager :)


The alternative is to configure your own bridge and configure your 
containers to use that. After you get the bridge working, you can 
start and monitor its boot progress with something like this:


That's exactly what I did. I realized this later that the default centos 
container assumes you have a lxcbr0 defined (I had hit this issue 
before). My servers use br0 so I just changed my test container's config 
and it came up fine. Most importantly, the udev service was not running. 
So I tweaked the lxc config I had in my custom install process to more 
closely match what was used in my standalone test and my containers are 
now coming up fine, or at least udev is no longer running. The /dev 
directory still has more entries than my libvirt containers (for 
example, /dev/snd is still present), but at least there are no udev 
errors in /var/log/messages.


There *are* other issues (our software isn't running properly), but I 
think the major container issues have been resolved. I changed a few 
things, including the version of LXC that I'm using, so it's hard to say 
what the culprit was with regards to this udev issue.



# lxc-start -n c7;lxc-console -n c7 -t 0

The benefit of using this approach instead of "lxc-start -F" is that 
you can detach the console session later using "ctrl-a q". Note that 
you can NOT login on this console yet, as by default the root password 
is not set. From another shell session, you need to do


# lxc-attach -n c7 -- passwd

Then you can login from the console session. You'll then see on the 
container (I tested this just now on up-to-date centos7)


[root@c7 ~]# ls /dev
console  core  fd  full  hugepages  initctl  log  lxc  mqueue  null 
 ptmx  pts  random  shm  stderr  stdin  stdout  tty  tty1  tty2  tty3 
 tty4  urandom  zero


Apparently this works even without lxfs.

If you DO manage to get lxcfs installed and working later (disclaimer: 
I've only use it on ubuntu and debian), you'll be able to get some 
additional benefits like the container only seeing its allocated 
resources (set using "lxc.cgroup" settings on lxc config file). For 
example, if "lxc.cgroup.cpuset.cpus = 0", then the container will only 
use cpu0, and "htop" or "cat /proc/cpuinfo" will only show 1 cpu even 
when your host has multiple cpus.


That would definitely be nice. Libvirt does a reasonably good job in 
this area but it is far from complete, with /proc/cpuinfo being one of 
the weak points. I'll definitely have to check out lxcfs.


___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Converting from libvirt lxc

[Fajar A. Nugraha]

On Thu, Dec 3, 2015 at 9:27 PM, Peter Steele  wrote:

> On 12/02/2015 08:47 PM, Fajar A. Nugraha wrote:
>
> On Thu, Dec 3, 2015 at 1:14 AM, Peter Steele  wrote:
>
>>
>> On 12/02/2015 07:23 AM, Fajar A. Nugraha wrote:
>>
>> On Wed, Dec 2, 2015 at 9:49 PM, Peter Steele  wrote:
>>
>>> On 12/01/2015 08:25 PM, Fajar A. Nugraha wrote:
>>>
>>> Is there a reason why you can't install a centos7 container using the
>>> download template? It would've been MUCH easier, and some of the things you
>>> asked wouldn't even be an issue.
>>>
>>>
>>>
> lxc-create -t centos -n test1
>>
>> to create a container using the centos default settings. The resulting
>> config file doesn't look a whole lot different than my manually crafted
>> version.
>>
>
>
> You DID notice that repeatedly say "DOWNLOAD template"? as in someting like
>
> # lxc-create -t download -n c7 -- -d centos -r 7 -a amd64
>
> The template was downloaded automatically when I ran the lxc-create
> command the first time. Is there a difference in how the download is done
> using the command you've listed above?
>
>

centos template -> download lost of packages (i.e. RPM) one by one using
yum, and then install it

download template -> download one big tar.xz file (plus several small
config files), and then extract it. MUCH faster, and works for unpriv
containers as well (not sure what the current state of unpriv containers on
centos though)

However I was actually more concerned about the fact that the templates are
maintained separately, so there could be some difference in the resulting
container/config. The download template works (I've tested it), while
(based on your previous output) the centos template doesn't provide the
desired /dev entries.


> The alternative is to configure your own bridge and configure your
> containers to use that. After you get the bridge working, you can start and
> monitor its boot progress with something like this:
>
> That's exactly what I did. I realized this later that the default centos
> container assumes you have a lxcbr0 defined (I had hit this issue before).
> My servers use br0 so I just changed my test container's config and it came
> up fine. Most importantly, the udev service was not running. So I tweaked
> the lxc config I had in my custom install process to more closely match
> what was used in my standalone test and my containers are now coming up
> fine, or at least udev is no longer running. The /dev directory still has
> more entries than my libvirt containers (for example, /dev/snd is still
> present), but at least there are no udev errors in /var/log/messages.
>
>

Which is why I suggested the download template.

I also tested using the resulting config with rootfs replaced by a "native"
centos7 install (to be exact, a disk clone of minimal centos7 install on
virtualbox), still result in the desired /dev entries (i.e. minimal /dev
entries, no /dev/snd).




> There *are* other issues (our software isn't running properly), but I
> think the major container issues have been resolved.
>


Which is?




> I changed a few things, including the version of LXC that I'm using, so
> it's hard to say what the culprit was with regards to this udev issue.
>
>

IIRC systemd containers are only supported on lxc-1.1.x, so upgrading lxc
probably has a big part in that.


>
> If you DO manage to get lxcfs installed and working later (disclaimer:
> I've only use it on ubuntu and debian), you'll be able to get some
> additional benefits like the container only seeing its allocated resources
> (set using "lxc.cgroup" settings on lxc config file). For example, if
> "lxc.cgroup.cpuset.cpus = 0", then the container will only use cpu0, and
> "htop" or "cat /proc/cpuinfo" will only show 1 cpu even when your host has
> multiple cpus.
>
> That would definitely be nice. Libvirt does a reasonably good job in this
> area but it is far from complete, with /proc/cpuinfo being one of the weak
> points. I'll definitely have to check out lxcfs.
>
>

It should be easier now since latest lxcfs shouldn't need cgmanager anymore.

And the usual generic suggestion, if you encounter kernel or
namespace-related problems, testing latest kernel from kernel-ml (
http://elrepo.org/tiki/kernel-ml) might help.

-- 
Fajar
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Convert LXC Guests from privileged to unprivileged

[Serge Hallyn]

Quoting Wolfgang Bumiller (w.bumil...@proxmox.com):
> > fwiw lxd also ships with 'fuidshift' which has the same functionality.
> 
> After a quick glance over the code I only see it handling file ownership.
> What about ACLs? (And perhaps other extra attributes I'm unaware of.)

Good point.  Patch for lxd's fuidshift appreciated :)

> I was thinking the most "complete" conversion happens when you tar up the
> container in one namespace, with -p --acls --numeric-owner --xattrs etc.
> and then unar it in the other namespace. This however fails to extract
> device nodes into user namespaces... ;-/
> 
> (Offtopic: I'm still puzzled by the fact that mknod doesn't work in a
> usernamespace. There's a capability for _just_ _that_ after all, and

Capabilities are targeted at a user namespace, while devices are always
owned by the initial user namespace.  (Or put another way that Greg will
appreciate, devices are not namespaced, and "never will be")

So that capability is basically worthless in a userns.

> there's the devices cgroup. I'd much rather have a rule that a non-zero

Devices cgroup was supposed to be a short-term hack until devices namespace
came around.  It's not a device ns in itself.  (Then it was decreed that
devices ns won't happen, so we still have the devices cgroup)

> user starting a userns doesn't gain CAP_SYS_MKNOD unless it's already
> there.)
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Converting from libvirt lxc

[Peter Steele]

On 12/03/2015 07:25 AM, Fajar A. Nugraha wrote:
On Thu, Dec 3, 2015 at 9:27 PM, Peter Steele >wrote:


On 12/02/2015 08:47 PM, Fajar A. Nugraha wrote:


centos template -> download lost of packages (i.e. RPM) one by one 
using yum, and then install it


download template -> download one big tar.xz file (plus several small 
config files), and then extract it. MUCH faster, and works for unpriv 
containers as well (not sure what the current state of unpriv 
containers on centos though)


However I was actually more concerned about the fact that the 
templates are maintained separately, so there could be some difference 
in the resulting container/config. The download template works (I've 
tested it), while (based on your previous output) the centos template 
doesn't provide the desired /dev entries.


I just did a test using the download approach and it worked nicely, 
obviously much cleaner than downloading the rpms individually. The 
containers created from the two approaches seem to be identical, as far 
as a cursory glance is concerned, with identical config files.


Which is why I suggested the download template.

I also tested using the resulting config with rootfs replaced by a 
"native" centos7 install (to be exact, a disk clone of minimal centos7 
install on virtualbox), still result in the desired /dev entries (i.e. 
minimal /dev entries, no /dev/snd).


I can't really use the downloaded template for our rootfs, as I 
explained earlier. We already have a process that generates a custom 
centos tar ball with the specific set of packages that we need in our 
containers. Our tarball includes other third party packages as well, 
such as supervisord and ctdb. I've used the downloaded template's config 
file to create a custom config for our containers. The container 
specific portion of the config looks something like this:


lxc.utsname = pws-vm-03
lxc.rootfs = /hf/cs/vm-03/rootfs
lxc.network.veth.pair = vm-03
lxc.network.hwaddr = fe:d6:e8:dc:c8:db
lxc.rootfs = /hf/cs/vm-03/rootfs
lxc.cgroup.memory.limit_in_bytes = 1073741824
lxc.cgroup.memory.memsw.limit_in_bytes = 2147483648
lxc.include = /var/lib/hf/lxc.conf

and the settings that are common to all containers (lxc.conf) include 
the following:


lxc.autodev = 1
lxc.devttydir = lxc
lxc.tty = 4
lxc.pts = 1024
lxc.kmsg = 0
lxc.arch = x86_64

# Networking defaults
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0

# Remove capabilities we don't want in containers
lxc.cap.drop = mac_admin mac_override sys_time sys_module

# Set the pivot directory
lxc.pivotdir = lxc_putold

# Control Group devices: all denied except those white-listed
lxc.cgroup.devices.deny = a
## Allow any mknod (but not reading/writing the node)
lxc.cgroup.devices.allow = c *:* m
lxc.cgroup.devices.allow = b *:* m
## /dev/null
lxc.cgroup.devices.allow = c 1:3 rwm
## /dev/zero
lxc.cgroup.devices.allow = c 1:5 rwm
## /dev/full
lxc.cgroup.devices.allow = c 1:7 rwm
## /dev/tty
lxc.cgroup.devices.allow = c 5:0 rwm
## /dev/random
lxc.cgroup.devices.allow = c 1:8 rwm
## /dev/urandom
lxc.cgroup.devices.allow = c 1:9 rwm
## /dev/tty[1-4] ptys and lxc console
lxc.cgroup.devices.allow = c 136:* rwm
## /dev/ptmx pty master
lxc.cgroup.devices.allow = c 5:2 rwm

# Setup the default mounts
lxc.mount.auto = cgroup:mixed proc:mixed sys:mixed
lxc.mount.entry = /sys/fs/fuse/connections sys/fs/fuse/connections none 
bind,optional 0 0


As you can see this was largely pulled from centos.common.conf and 
common.conf.I assume something isn't quite right since I see more 
entries under /dev than I do when I'm running under libvirt, using the 
same custom tarball. I'll be satisfied with this for now though as long 
as the extra entries aren't causing issues.


There *are* other issues (our software isn't running properly),
but I think the major container issues have been resolved.


Which is?

Well, mainly the udev issue, plus the fact that the containers booted 
*really* slowly.


I changed a few things, including the version of LXC that I'm
using, so it's hard to say what the culprit was with regards to
this udev issue.



IIRC systemd containers are only supported on lxc-1.1.x, so upgrading 
lxc probably has a big part in that.

Yeah, things definitely started working better after I upgraded.


___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Convert LXC Guests from privileged to unprivileged

[Dietmar Maurer]

> On December 3, 2015 at 5:56 PM Serge Hallyn  wrote:
> 
> 
> Quoting Wolfgang Bumiller (w.bumil...@proxmox.com):
> > > fwiw lxd also ships with 'fuidshift' which has the same functionality.
> > 
> > After a quick glance over the code I only see it handling file ownership.
> > What about ACLs? (And perhaps other extra attributes I'm unaware of.)
> 
> Good point.  Patch for lxd's fuidshift appreciated :)

Would it make sense to ship such binary with LXC (we do not use LXD at all)?

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Convert LXC Guests from privileged to unprivileged

[Serge Hallyn]

Quoting Dietmar Maurer (diet...@proxmox.com):
> 
> 
> > On December 3, 2015 at 5:56 PM Serge Hallyn  wrote:
> > 
> > 
> > Quoting Wolfgang Bumiller (w.bumil...@proxmox.com):
> > > > fwiw lxd also ships with 'fuidshift' which has the same functionality.
> > > 
> > > After a quick glance over the code I only see it handling file ownership.
> > > What about ACLs? (And perhaps other extra attributes I'm unaware of.)
> > 
> > Good point.  Patch for lxd's fuidshift appreciated :)
> 
> Would it make sense to ship such binary with LXC (we do not use LXD at all)?

I've thought about moving the one from my nsexec bzr tree over a few times
over the years.  But I think the download template, and the ease of doing
lxc-usernsexec tar zxf made it never quite needed enough to do it.

I'd prefer not to have two completely separate codebases for the same tool :),
but it sounds like it would make sense for you, so if you send a patch to
do so, +1.  (We also could simply make the uidmap go code from lxd a separate
package and have lxc optionally go get and build that.)

-serge
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Converting from libvirt lxc

[Neil Greenwood]

On 3 December 2015 17:10:29 GMT+00:00, Peter Steele  wrote:
>
>I can't really use the downloaded template for our rootfs, as I 
>explained earlier. We already have a process that generates a custom 
>centos tar ball with the specific set of packages that we need in our 
>containers. Our tarball includes other third party packages as well, 
>such as supervisord and ctdb. I've used the downloaded template's
>config 

I am not an expert with LXC, but I think you can get your tarball working using 
'-t download' a.k.a. the download template. You would use petercentos rather 
centos as the template to download, and provide a petercentos configuration 
that points to your tarball. Obviously you will use your company name in the 
production version :-)

Neil 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] NFS mounts and unprivileged containers

[Matthew Green]

I'm in the process of moving away from ESXI VMs and over to containers (as
everything was all on Ubuntu) and I've hit a bit of a problem.

I decided that I'd look to go for unprivileged containers for the extra
security but a couple of my containers require NFS mounts and I just can't
get them to work.

I've changed the apparmor settings to allow NFS mounts, and it works fine
with privileged containers, but nothing I try will make the unprivileged
containers mount an NFS export.

Can anyone provide a definitive statement on whether this just a limitation
of unprivileged containers? Or am I doing something wrong?

Thanks,

Matt
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Converting from libvirt lxc

[Peter Steele]

On 12/03/2015 11:27 AM, Neil Greenwood wrote:

On 3 December 2015 17:10:29 GMT+00:00, Peter Steele  wrote:

I can't really use the downloaded template for our rootfs, as I
explained earlier. We already have a process that generates a custom
centos tar ball with the specific set of packages that we need in our
containers. Our tarball includes other third party packages as well,
such as supervisord and ctdb. I've used the downloaded template's
config

I am not an expert with LXC, but I think you can get your tarball working using 
'-t download' a.k.a. the download template. You would use petercentos rather 
centos as the template to download, and provide a petercentos configuration 
that points to your tarball. Obviously you will use your company name in the 
production version :-)

Neil
That's where I'd like to get to eventually. That said, since this is all 
part of an automated process and no one actually runs lxc-create 
interactively (it's all done in Python scripts), it doesn't really 
matter if our custom tar ball gets installed as an official formal 
template. The lxc-create command works quite well using "none" for the 
template, as long as the rootfs is put in place through some other 
means. Since we're transitioning from libvirt to LXC and need to keep 
both frameworks in play for a while, it's easier in our code to install 
rootfs explicitly rather than having lxc-create do it.


Peter

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] NFS mounts and unprivileged containers

[Fajar A. Nugraha]

On Fri, Dec 4, 2015 at 4:07 AM, Matthew Green  wrote:

> I'm in the process of moving away from ESXI VMs and over to containers (as
> everything was all on Ubuntu) and I've hit a bit of a problem.
>
> I decided that I'd look to go for unprivileged containers for the extra
> security but a couple of my containers require NFS mounts and I just can't
> get them to work.
>
> I've changed the apparmor settings to allow NFS mounts, and it works fine
> with privileged containers, but nothing I try will make the unprivileged
> containers mount an NFS export.
>
> Can anyone provide a definitive statement on whether this just a
> limitation of unprivileged containers? Or am I doing something wrong?
>
>

I believe all mounts in unpriv containers needs to happen on the host.

Can you mount your nfs share on the host, and use lxc.mount.entry to make
it available to the container? Of course, you need to deal with uid
differences as well (root is container is not uid 0 on the host).

-- 
Fajar
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Converting from libvirt lxc

[Fajar A. Nugraha]

On Fri, Dec 4, 2015 at 12:10 AM, Peter Steele  wrote:

> There *are* other issues (our software isn't running properly), but I
>> think the major container issues have been resolved.
>>
>
> Which is?
>
> Well, mainly the udev issue, plus the fact that the containers booted
> *really* slowly.
>
>
>
>
Are you STILL experiencing slow booting? If yes, can you please test using
a clean setup (e.g. in fresh-installl under virtualbox)?

My test with the download template result in fast-booting container. I
wonder if you can run some test on a clean setup:

- host clean centos 7 install on virtualbox, lxc-1.1.5, containers created
fully from download template -> you should achieve same result as mine. If
NOT, then we can start working on that, as it should be a bug in lxc

- host clean centos 7 install on virtualbox, same lxc config as earlier,
but with rootfs replaced with your custom rootfs. I'm GUESSing this is
where things could be different. If this is SLOW for you while the earlier
one is fast, then the problem lies somewhere in your rootfs.

- If it IS still slow, and the boot process shows systemd is somehow
involved in the slowness, you can try my systemd-224 RPMs, and see if it
makes it better:
https://goo.gl/XpKFxS
https://www.mail-archive.com/lxc-users@lists.linuxcontainers.org/msg03829.html
(you should only need step "5" and "7")

Of course, the above is assuming you can work with a COPY of your rootfs
(since upgrading systemd would be a slightly complicated process to undo)

-- 
Fajar
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Converting from libvirt lxc

[Fajar A. Nugraha]

On Fri, Dec 4, 2015 at 12:10 AM, Peter Steele  wrote:

> I've used the downloaded template's config file to create a custom config
> for our containers.
>


Also, are you SURE this is based on download template's config?


> The container specific portion of the config looks something like this:
>
>
>

> lxc.autodev = 1
>


That is not common.conf (though I'm not sure whether it matters)


>
> lxc.kmsg = 0
>

Neither is that. Though it should be the default value


>
>
> # Remove capabilities we don't want in containers
> lxc.cap.drop = mac_admin mac_override sys_time sys_module
>
>
centos.common.conf also has  lxc.cap.drop = sys_nice sys_pacct sys_rawio.
You don't have that.

lxc.cgroup.devices.allow = c 5:0 rwm
>



> lxc.cgroup.devices.allow = c 136:* rwm
> ## /dev/ptmx pty master
> lxc.cgroup.devices.allow = c 5:2 rwm
>
>
you' re missing 5:1 (console), 10:229 (fuse). Both are in common.conf.



> # Setup the default mounts
> lxc.mount.auto = cgroup:mixed proc:mixed sys:mixed
> lxc.mount.entry = /sys/fs/fuse/connections sys/fs/fuse/connections none
> bind,optional 0 0
>
> As you can see this was largely pulled from centos.common.conf and
> common.conf. I assume something isn't quite right since I see more
> entries under /dev than I do when I'm running under libvirt, using the same
> custom tarball. I'll be satisfied with this for now though as long as the
> extra entries aren't causing issues.
>
>
>
Is there a reason why you didn't test simply using the same config, which
also does the "includes" instead of copying SOME of them? Is there a reason
wht you don't copy ALL of them? It should be easier to start with a known
good setup, then do incremental changes.

-- 
Fajar
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users