[lxc-users] Fwd: Security consequences of lxc.id_map not mapping a specific uid and gid

[Christian Brauner]

Hello,

I run unprivileged containers and I want them to have access to video and
sound devices. Hence, I  the following in my ~/.config/lxc/default.conf as
suggested on Stéphane's blog:

# Container specific configuration
lxc.id_map = u 1001 101001 64535
lxc.id_map = g 1001 101001 64535
# uid and gid 1000 isn’t translated so that the container can access the
# X socket and dri and snd and video0 devices
lxc.id_map = u 0 10 1000
lxc.id_map = g 0 10 1000
lxc.id_map = u 1000 1000 1
lxc.id_map = g 1000 1000 1

I was wondering compared to an unprivileged container where I simply
map:

lxc.id_map=u 0 10 65536
lxc.id_map=g 0 10 65536

1) Am I significantly more vulnerable when I preserve the uid/gid of my
unprivileged user on the host for my user in the container?

2) And is there a different solution which would allow me to grant
access to the sound and video devices in /dev/snd and /dev/dri to the
user in my unprivileged container while still preserving the standard
mapping:

lxc.id_map=u 0 10 65536
lxc.id_map=g 0 10 65536

3) During container bootup of e.g. Debian Wheezy/Stable is constantly
complaining in the following manner (log output below) and I would like to
now if this can be avoided:



INIT: version 2.88 booting
Using makefile-style concurrent boot in runlevel S.
Cleaning up temporary files... /tmp.
mount: permission denied
mount: permission denied
mount: permission denied
mount: permission denied
mount: permission denied
Mount point '/dev/console' does not exist. Skipping mount. ... (warning).
Mount point '/dev/full' does not exist. Skipping mount. ... (warning).
Mount point '/dev/null' does not exist. Skipping mount. ... (warning).
Mount point '/dev/random' does not exist. Skipping mount. ... (warning).
Mount point '/dev/tty' does not exist. Skipping mount. ... (warning).
Mount point '/dev/urandom' does not exist. Skipping mount. ... (warning).
Mount point '/dev/zero' does not exist. Skipping mount. ... (warning).
Mount point '/dev/video0' does not exist. Skipping mount. ... (warning).
Mount point '/dev/fb0' does not exist. Skipping mount. ... (warning).
Mount point '/dev/console' does not exist. Skipping mount. ... (warning).
Mount point '/dev/tty1' does not exist. Skipping mount. ... (warning).
Mount point '/dev/tty2' does not exist. Skipping mount. ... (warning).
Mount point '/dev/tty3' does not exist. Skipping mount. ... (warning).
Mount point '/dev/tty4' does not exist. Skipping mount. ... (warning).
udev requires hotplug support, not started ... failed!
 failed!
Activating lvm and md swap...done.
Checking file systems...fsck from util-linux 2.20.1
done.
Mounting local filesystems...done.
/etc/init.d/mountall.sh: 59: kill: Illegal number: 4 1
Activating swapfile swap...done.
Cleaning up temporary files
Setting kernel variables ...done.
Configuring network interfaces...done.
Cleaning up temporary files
Setting up ALSA...Invalid card number.
Usage: amixer  [command]
Available options:
  -h,--help   this help
  -c,--card N select the card
  -D,--device N   select the device, default 'default'
  -d,--debug  debug mode
  -n,--nocheckdo not perform range checking
  -v,--versionprint version of this program
  -q,--quiet  be quiet
  -i,--inactive   show also inactive controls
  -a,--abstract L select abstraction level (none or basic)
  -s,--stdin  Read and execute commands from stdin sequentially
Available commands:
  scontrols   show all mixer simple controls
  scontents  show contents of all mixer simple controls (default command)
  sset sID P  set contents for one mixer simple control
  sget sIDget contents for one mixer simple control
  controlsshow all controls for given card
  contentsshow contents of all controls for given card
  cset cID P  set control contents for one control
  cget cIDget control contents for one control


Best,
Christian

System Information:

Arch Linux with user namespace supported kernel.
lxc 1.0.7

this script:

cgroups are created with printf '\n\033[42mCreating cgroup
hierarchy\033[m\n\n' &&
for d in /sys/fs/cgroup/*; do
f=$(basename $d)
echo "looking at $f"
if [ "$f" = "cpuset" ]; then
echo 1 | sudo tee -a $d/cgroup.clone_children;
elif [ "$f" = "memory" ]; then
echo 1 | sudo tee -a $d/memory.use_hierarchy;
fi
sudo mkdir -p $d/$USER
sudo chown -R $USER $d/$USER
# add current process to cgroup
echo $$ > $d/$USER/tasks
done
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] Fwd: Security consequences of lxc.id_map not mapping a specific uid and gid

[Christian Brauner]

> Quoting Christian Brauner (christianvanbrau...@gmail.com):
> > Hello,
> > 
> > I run unprivileged containers and I want them to have access to video and
> > sound devices. Hence, I  the following in my ~/.config/lxc/default.conf as
> > suggested on Stéphane's blog:
> > 
> > # Container specific configuration
> > lxc.id_map = u 1001 101001 64535
> > lxc.id_map = g 1001 101001 64535
> > # uid and gid 1000 isn’t translated so that the container can access the
> > # X socket and dri and snd and video0 devices
> > lxc.id_map = u 0 10 1000
> > lxc.id_map = g 0 10 1000
> > lxc.id_map = u 1000 1000 1
> > lxc.id_map = g 1000 1000 1
> > 
> > I was wondering compared to an unprivileged container where I simply
> > map:
> > 
> > lxc.id_map=u 0 10 65536
> > lxc.id_map=g 0 10 65536
> > 
> > 1) Am I significantly more vulnerable when I preserve the uid/gid of my
> > unprivileged user on the host for my user in the container?
> 
> That depends on the threats you worry about, I guess.  Short answer is
> yes.  So if you run a browser as that user in the container, and the
> browser succumbs to say a malicous flash binary, the binary has the
> rights to further proceed on the system with your uid.
> 
> I do believe it's worthwhile, still.  First, there's a huge difference
> in what it can do as a next step if it's your uid, versus if it is running
> as the host's root uid.  Secondly, it will at this point still be confined
> by apparmor and namespacing.  Now if you next bind-mount your host user's
> homedir into the container, then you should be ready to kiss anything in
> your homedir goodbye.  But if you don't do that, then the fact that the
> exploit is running as your uid shouldn't be all *that* bad.  Probably
> the easiest next step for it would be to exploit ownership of the X dir,
> i.e. to snoop your keyboard.
> 
> > 2) And is there a different solution which would allow me to grant
> > access to the sound and video devices in /dev/snd and /dev/dri to the
> > user in my unprivileged container while still preserving the standard
> > mapping:
> > 
> > lxc.id_map=u 0 10 65536
> > lxc.id_map=g 0 10 65536
> 
> You could forward sound devices using pulseaudio over the network
> instead.  Similarly you could forward X session to 10.0.3.1:0, but
> that will get you slower video.
> 

I actually found a nicer solution. I use setfacl to set permissions on
specific devices to specific user. Let's say I wanted my container user
which I assigned uid 1000 in the container (i.e. 101000 as seen from the
host) to access the Xsocket, sound, video and framebuffer devices. Then
I would do:
setfacl -R -m "u:101000:r" /tmp/.X11-unix/X0
setfacl -R -m "u:101000:rw" /dev/snd/*
setfacl -R -m "u:101000:rw" /dev/dri/*
setfacl -R -m "u:101000:rw" /dev/video0
setfacl -R -m "u:101000:rw" /dev/fb0
This way the container user can only access  exactly those files/devices
I make available and not everything that my local user on the host has
access to.


> > 3) During container bootup of e.g. Debian Wheezy/Stable is constantly
> > complaining in the following manner (log output below) and I would like to
> > now if this can be avoided:
> > 
> > 
> > 
> > INIT: version 2.88 booting
> > Using makefile-style concurrent boot in runlevel S.
> > Cleaning up temporary files... /tmp.
> > mount: permission denied
> > mount: permission denied
> > mount: permission denied
> > mount: permission denied
> > mount: permission denied
> > Mount point '/dev/console' does not exist. Skipping mount. ... (warning).
> > Mount point '/dev/full' does not exist. Skipping mount. ... (warning).
> > Mount point '/dev/null' does not exist. Skipping mount. ... (warning).
> 
> Hm, that's interesting.  The /dev/full (etc) bind mount entries should
> end in ",create=file" which should prevent this.
> 
> Could you show the container configuration file (and any files which are
> lxc.included, recursively)?
> 
Yes, of course:

1) config:

# Template used to create this container:
# /usr/share/lxc/templates/lxc-download
# Parameters passed to the template: -d debian -r wheezy -a amd64
# For additional config options, please look at
# lxc.container.conf(5)

# Distribution configuration
lxc.include = /usr/share/lxc/config/debian.common.conf
lxc.include = /usr/share/lxc/config/debian.userns.conf
lxc.arch = x86_64

# Container specific configuration

[lxc-users] systemd-based unprivileged containers

[Christian Brauner]

Hello,

I'm using unprivileged lxc containers. Currently I'm trying to use
Debian Jessie. Which provides me with a few riddles. When I start the
container I get two error messages:

[chb@conventiont ~]$ lxc-start -n jessie -l DEBUG -o jessie
lxc-start: conf.c: mk_devtmpfs: 1318 Permission denied - Unable to
create /dev/.lxc for autodev
Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not
permitted

1) "lxc-start: conf.c: mk_devtmpfs: 1318 Permission denied - Unable to
create /dev/.lxc for autodev": I understand that unprivileged containers
do not have permissions to set up folders under /dev. Is there a
recommended way to solve this problem?

2) "Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not
permitted": What is goin on here and how can I solve this?

Here is the error log (container config files below):

  lxc-start 1418564089.500 INFO lxc_start_ui - lxc_start.c:main:265 - 
using rcfile /home/chb/.local/share/lxc/jessie/config
  lxc-start 1418564089.500 INFO lxc_confile - 
confile.c:config_idmap:1325 - read uid map: type u nsid 0 hostid 10 range 
65536
  lxc-start 1418564089.500 INFO lxc_confile - 
confile.c:config_idmap:1325 - read uid map: type g nsid 0 hostid 10 range 
65536
  lxc-start 1418564089.501 WARN lxc_log - log.c:lxc_log_init:316 - 
lxc_log_init called with log already initialized
  lxc-start 1418564089.502 WARN lxc_cgmanager - cgmanager.c:cgm_get:954 
- do_cgm_get exited with error
  lxc-start 1418564089.503 DEBUGlxc_conf - conf.c:lxc_create_tty:3665 - 
allocated pty '/dev/pts/2' (5/6)
  lxc-start 1418564089.503 DEBUGlxc_conf - conf.c:lxc_create_tty:3665 - 
allocated pty '/dev/pts/3' (7/8)
  lxc-start 1418564089.503 DEBUGlxc_conf - conf.c:lxc_create_tty:3665 - 
allocated pty '/dev/pts/4' (9/10)
  lxc-start 1418564089.503 DEBUGlxc_conf - conf.c:lxc_create_tty:3665 - 
allocated pty '/dev/pts/5' (11/12)
  lxc-start 1418564089.503 INFO lxc_conf - conf.c:lxc_create_tty:3676 - 
tty's configured
  lxc-start 1418564089.503 DEBUGlxc_start - start.c:setup_signal_fd:247 
- sigchild handler set
  lxc-start 1418564089.503 DEBUGlxc_console - 
console.c:lxc_console_peer_default:500 - opening /dev/tty for console peer
  lxc-start 1418564089.503 DEBUGlxc_console - 
console.c:lxc_console_peer_default:506 - using '/dev/tty' as console
  lxc-start 1418564089.503 DEBUGlxc_console - 
console.c:lxc_console_sigwinch_init:179 - 2708 got SIGWINCH fd 17
  lxc-start 1418564089.503 DEBUGlxc_console - 
console.c:lxc_console_winsz:88 - set winsz dstfd:14 cols:84 rows:49
  lxc-start 1418564089.912 INFO lxc_start - start.c:lxc_init:443 - 
'jessie' is initialized
  lxc-start 1418564089.912 DEBUGlxc_start - start.c:__lxc_start:1058 - 
Not dropping cap_sys_boot or watching utmp
  lxc-start 1418564089.912 INFO lxc_start - start.c:lxc_spawn:802 - 
Cloning a new user namespace
  lxc-start 1418564089.912 INFO lxc_cgroup - cgroup.c:cgroup_init:62 - 
cgroup driver cgmanager initing for jessie
  lxc-start 1418564090.110 NOTICE   lxc_start - start.c:do_start:656 - 
switching to gid/uid 0 in new user namespace
  lxc-start 1418564090.116 DEBUGlxc_conf - conf.c:setup_rootfs:1611 - 
mounted '/home/chb/.local/share/lxc/jessie/rootfs' on '/usr/lib/lxc/rootfs'
  lxc-start 1418564090.116 INFO lxc_conf - conf.c:setup_utsname:900 - 
'jessie' hostname has been setup
  lxc-start 1418564090.116 DEBUGlxc_conf - conf.c:setup_hw_addr:2557 - 
mac address '00:16:3e:3a:f1:12' on 'eth0' has been setup
  lxc-start 1418564090.116 DEBUGlxc_conf - conf.c:setup_netdev:2784 - 
'eth0' has been setup
  lxc-start 1418564090.116 INFO lxc_conf - conf.c:setup_network:2805 - 
network has been setup
  lxc-start 1418564090.116 DEBUGlxc_conf - conf.c:check_autodev:3906 - 
Set exec command to /sbin/init
  lxc-start 1418564090.116 INFO lxc_conf - conf.c:check_autodev:3920 - 
Container with systemd init detected - enabling autodev!
  lxc-start 1418564090.116 INFO lxc_conf - conf.c:mount_autodev:1418 - 
Mounting /dev under /usr/lib/lxc/rootfs
  lxc-start 1418564090.116 ERRORlxc_conf - conf.c:mk_devtmpfs:1318 - 
Permission denied - Unable to create /dev/.lxc for autodev
  lxc-start 1418564090.116 DEBUGlxc_conf - conf.c:mount_check_fs:1250 - 
entering mount_check_fs for /home/chb/.local/share/lxc/jessie/rootfs.dev
  lxc-start 1418564090.116 DEBUGlxc_conf - conf.c:mount_autodev:1449 - 
Mounting tmpfs to /home/chb/.local/share/lxc/jessie/rootfs.dev
  lxc-start 1418564090.117 INFO lxc_conf - conf.c:mount_autodev:1476 - 
Mounted /dev under /usr/lib/lxc/rootfs
  lxc-start 1418564090.117 DEBUGlxc_conf - conf.c:mount_entry:2106 - 
mounted 'proc' on '/usr/lib/lxc/rootfs/proc', type 'proc'
  lxc-start 1418564090.117 DEBUGlxc_conf - conf.c:mount_entry:2106 - 
mount

[lxc-users] Security consequences of lxc.id_map not mapping a specific uid and gid

[Christian Brauner]

Hello,

I do the following in my ~/.config/lxc/default.conf:

# Container specific configuration
lxc.id_map = u 1001 101001 64535
lxc.id_map = g 1001 101001 64535
# uid and gid 1000 isn’t translated so that the container can access the
# X socket and dri and snd and video0 devices
lxc.id_map = u 0 10 1000
lxc.id_map = g 0 10 1000
lxc.id_map = u 1000 1000 1
lxc.id_map = g 1000 1000 1

I was wondering compared to an unprivileged container where I simply
map:

lxc.id_map=u 0 10 65536
lxc.id_map=g 0 10 65536

1) Am I significantly more vulnerable when I preserve the uid/gid of my
unprivileged user on the host for my user in the container?

2) And is there a different solution which would allow me to grant
access to the sound and video devices in /dev/snd and /dev/dri to the
user in my unprivileged container while still preserving the standard
mapping:

lxc.id_map=u 0 10 65536
lxc.id_map=g 0 10 65536

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

Re: [lxc-users] lxc-users Digest, Vol 58, Issue 2

[Christian Brauner]

> Date: Tue, 20 Jan 2015 11:35:50 +0100
> From: Thouraya TH 
> To: LXC users mailing-list 
> Subject: Re: [lxc-users] lxc-users Digest, Vol 56, Issue 7

Hello Thouraya,

please, please follow the little advise sent out with every mailing list
summary:

When replying, please edit your Subject line so it is more specific
than "Re: Contents of lxc-users digest..."

It would make skimming through the digest easier if one could identify
what your thread is going to be about without having to scroll through
the whole digest.

Sorry for the off-topic remark!

Best,
Christian

> 
> 2015-01-09 13:00 GMT+01:00 :
> 
> > Send lxc-users mailing list submissions to
> > lxc-users@lists.linuxcontainers.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> > or, via email, send a message with subject or body 'help' to
> > lxc-users-requ...@lists.linuxcontainers.org
> >
> > You can reach the person managing the list at
> > lxc-users-ow...@lists.linuxcontainers.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of lxc-users digest..."
> >
> > Today's Topics:
> >
> >1. Re: Snapshot size (Tycho Andersen)
> >2. Re: Snapshot size (Tycho Andersen)
> >
> >
> > -- Message transféré --
> > From: Tycho Andersen 
> > To: LXC users mailing-list 
> > Cc:
> > Date: Thu, 8 Jan 2015 07:19:52 -0700
> > Subject: Re: [lxc-users] Snapshot size
> > On Sun, Jan 04, 2015 at 07:42:38PM +0100, Thouraya TH wrote:
> > > Hello,
> > >
> > > On what depends the size of a checkpoint of a container? the size of
> > data that
> > > are in the container ?
> >
> > The size of the RAM, lxc-checkpoint is a frontend for CRIU, and CRIU
> > dumps only memory state (well, and "ghost" file state).
> >
> > > if i increase the size of data in a container, the snapshot's size
> > increase
> > > ?
> >
> >
> > *If there is more data in RAM, the CRIU images will be bigger.*
> 
> 
> Hello,
> @Tycho: I'm so sorry, i can't find the right option to send my reply
> correctly to the list.
> 
> *1)*
> I try to increase data size in the container like that:
> 
>root@worker:/home# vim MyTestFile.txt
>root@worker:/home# du -sh MyTestFile.txt
>4.0KMyTestFile.txt
>root@worker:/home# truncate -s 16M MyTestFile.txt
>root@worker:/home# du --apparent-size -h MyTestFile.txt
>   16MMyTestFile.txt
> 
> Then Dumping Process: in ImGLXC1Worker directory
> 
>root@g-3:/home/ImGLXC1Worker# du -sh
>*7.9M   * .
>root@g-3:/home/ImGLXC1Worker# du -h
>   7.9M.
> 
> 
> *2)*  i have increased the size from *16M to 160M*
> 
>   root@worker:/home# truncate -s *160M* MyTestFile.txt
>   root@worker:/home# du --apparent-size -h MyTestFile.txt
>   160MMyTestFile.txt
> 
>  Then Dumping Process: in a new ImGLXC1Worker2 directory
>   root@griffon-38:/home/ImGLXC1Worker2# du -sh
>   *7.7M *
> 
> Have you an explanation please ?
> 
> Thanks a lot for help.
> Best regards.
> 
> 
> >
> > Tycho
> >
> > > Thanks a lot for answer.
> > > Best Regards.
> >
> > > ___
> > > lxc-users mailing list
> > > lxc-users@lists.linuxcontainers.org
> > > http://lists.linuxcontainers.org/listinfo/lxc-users
> >
> >
> >
> >
> > -- Message transféré --
> > From: Tycho Andersen 
> > To: LXC users mailing-list 
> > Cc:
> > Date: Thu, 8 Jan 2015 07:20:05 -0700
> > Subject: Re: [lxc-users] Snapshot size
> > On Mon, Jan 05, 2015 at 11:25:13AM +0530, Ashish Bunkar wrote:
> > > Hi
> > > What is your OS, because in my environment lxc-chekpoint is depreciated
> > > command now ?
> >
> > It is?
> >
> > Tycho
> >
> > > Thanks & Regards
> > > Ashish Bunkar
> > > Contact No.- +91-7259183696
> > >
> > > On 01/05/2015 12:12 AM, Thouraya TH wrote:
> > > >Hello,
> > > >
> > > >On what depends the size of a checkpoint of a container? the size of
> > data
> > > >that are in the container ?
> > > >if i increase the size of data in a container, the snapshot's size
> > > >increase ?
> > > >
> > > >Thanks a lot for answer.
> > > >Best Regards.
> > > >
> > > >
> > > >___
> > > >lxc-users mailing list
> > > >lxc-users@lists.linuxcontainers.org
> > > >http://lists.linuxcontainers.org/listinfo/lxc-users
> > >
> >
> > > ___
> > > lxc-users mailing list
> > > lxc-users@lists.linuxcontainers.org
> > > http://lists.linuxcontainers.org/listinfo/lxc-users
> >
> >
> >
> > ___
> > lxc-users mailing list
> > lxc-users@lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> >


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

[lxc-users] Unprivileged Systemd-based Containers

[Christian Brauner]

Hello,

questions like this have been asked here before but none of them has
received a reply. See:


https://lists.linuxcontainers.org/pipermail/lxc-users/2014-November/008082.htmlA

and


https://lists.linuxcontainers.org/pipermail/lxc-users/2014-December/008155.html

(1) Is it possible to run systemd-based distros as unprivileged containers?

(2) When I try to use

lxc-create -t download

no fully systemd-based distros seem to come up (Fedora, Archlinux, OpenSuse
etc.; Ubuntu Vivid provides upstart and systemd I think). See:

[chb@conventiont ~]$ lxc-create -t download -n any
Setting up the GPG keyring
Downloading the image index

---
DISTRELEASE ARCHVARIANT BUILD
---
centos  6   amd64   default 20150126_02:16
centos  6   i386default 20150126_02:16
debian  wheezy  amd64   default 20150125_22:42
debian  wheezy  armel   default 20150120_22:42
debian  wheezy  armhf   default 20150125_22:42
debian  wheezy  i386default 20150125_22:42
oracle  6.5 amd64   default 20150125_11:40
oracle  6.5 i386default 20150125_11:40
plamo   5.x amd64   default 20150125_21:36
plamo   5.x i386default 20150125_21:36
ubuntu  lucid   amd64   default 20150126_03:49
ubuntu  lucid   i386default 20150126_03:49
ubuntu  precise amd64   default 20150126_03:49
ubuntu  precise armel   default 20150124_03:49
ubuntu  precise armhf   default 20150126_03:49
ubuntu  precise i386default 20150126_03:49
ubuntu  trusty  amd64   default 20150126_03:49
ubuntu  trusty  arm64   default 20150126_03:49
ubuntu  trusty  armhf   default 20150126_03:49
ubuntu  trusty  i386default 20150126_03:49
ubuntu  trusty  ppc64el default 20150126_03:49
ubuntu  utopic  amd64   default 20150126_03:49
ubuntu  utopic  arm64   default 20150126_03:49
ubuntu  utopic  armhf   default 20150126_03:49
ubuntu  utopic  i386default 20150126_03:49
ubuntu  utopic  ppc64el default 20150126_03:49
ubuntu  vivid   amd64   default 20150126_03:49
ubuntu  vivid   arm64   default 20150126_03:49
ubuntu  vivid   armhf   default 20150126_03:49
ubuntu  vivid   i386default 20150126_03:49
ubuntu  vivid   ppc64el default 20150126_03:49
---

Distribution: 

How can I get hold of systemd-based distros like Fedora, Archlinux
and OpenSuse if downloading them is not an option and the templates
do not work with unprivileged containers?

(3) With the current git version (build today 2015-01-26T11:55:36+0100)
the command

lxc-start -n CONTAINER

does not show a boot screen like it used to do but rather starts the
container in daemon mode and I have to use

lxc-attach -n CONTAINER -- /bin/bash

to enter it.
Is this expected behaviour?

(4) By chance I had a Debian Jessie container left from a long time ago
which I downloaded as an unprivileged container. If I start it with

lxc-start -n jessie

it starts but it only show

/sbin/init

in its process tree and systemd is pretty much unusable.

If I start it with

lxc-start -n jessie -F

to restore the old boot process (see (3)) it hangs with the error message
that it failed to mount

/sys/fs/cgroup

Presupposing that your answer to (1) is "yes", how can I get it to boot
correctly and have a usable systemd?

System Info:

--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig

Distro:
Arch Linux \r (\l)

Kernel:
Linux conventiont 3.18.3-ChB #1 SMP PREEMPT Mon Jan 19 21:12:11 UTC 2015 x86_64 
GNU/Linux

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

[lxc-users] Unprivileged Systemd-based Containers

[Christian Brauner]

Hi,

thanks Dirk!

> But there seems to be another solution with LXFS:
> 
>https://linuxcontainers.org/lxcfs/introduction/
> 
> This is what it says:
> 
>  + A cgroupfs-like tree which is container aware and works 
>using CGManager.
>  
>  + A set of files which can be bind-mounted over their /proc 
>originals to provide CGroup-aware values.

I just tried it. Downloaded it, unpacked it:

./configure && make && sudo make install

Then I followed the github lxcfs explanation:

sudo mkdir -p /var/lib/lxcfs
sudo lxcfs -s -f -o allow_other /var/lib/lxcfs

but if I run an unprivileged container with:

lxc-start -n jessie -F

it still gives me

[chb@conventiont lxcfs]$ lxc-start -n jessie -F
Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted

I use LXC's master from github so according to the lxcfs github page it should
work. Does someone know what is going on?

Here is the output from:

lxc-start -n jessie -F -l DEBUG -o AAA:

  lxc-start 1422272908.485 INFO lxc_start_ui - lxc_start.c:main:264 - 
using rcfile /home/chb/.local/share/lxc/jessie/config
  lxc-start 1422272908.485 WARN lxc_confile - 
confile.c:config_pivotdir:1770 - lxc.pivotdir is ignored.  It will soon become 
an error.
  lxc-start 1422272908.486 INFO lxc_confile - 
confile.c:config_idmap:1379 - read uid map: type u nsid 0 hostid 10 range 
65536
  lxc-start 1422272908.486 INFO lxc_confile - 
confile.c:config_idmap:1379 - read uid map: type g nsid 0 hostid 10 range 
65536
  lxc-start 1422272908.487 WARN lxc_log - log.c:lxc_log_init:316 - 
lxc_log_init called with log already initialized
  lxc-start 1422272908.488 WARN lxc_cgmanager - cgmanager.c:cgm_get:962 
- do_cgm_get exited with error
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:298 - processing: .reject_force_umount  # comment 
this to allow umount -f;  not recommended.
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:371 - Adding non-compat rule for reject_force_umount 
action 0
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:do_resolve_add_rule:192 - Setting seccomp rule to reject force umounts

  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:382 - Adding compat rule for reject_force_umount 
action 0
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:390 - Adding non-compat rule bc nr1 == nr2 (-1, -1)
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:do_resolve_add_rule:192 - Setting seccomp rule to reject force umounts

  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:298 - processing: .[all].
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:298 - processing: .kexec_load errno 1.
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:371 - Adding non-compat rule for kexec_load action 
327681
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:382 - Adding compat rule for kexec_load action 327681
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:395 - Really adding compat rule bc nr1 == nr2 (283, 
246)
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:298 - processing: .open_by_handle_at errno 1.
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:371 - Adding non-compat rule for open_by_handle_at 
action 327681
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:382 - Adding compat rule for open_by_handle_at action 
327681
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:395 - Really adding compat rule bc nr1 == nr2 (342, 
304)
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:298 - processing: .init_module errno 1.
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:371 - Adding non-compat rule for init_module action 
327681
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:382 - Adding compat rule for init_module action 327681
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:395 - Really adding compat rule bc nr1 == nr2 (128, 
175)
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:298 - processing: .finit_module errno 1.
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:371 - Adding non-compat rule for finit_module action 
327681
  lxc-start 1422272908.488 WARN lxc_seccomp - 
seccomp.c:do_resolve_add_rule:209 - Seccomp: got negative # for syscall: 
finit_module
  lxc-start 1422272908.488 WARN lxc_seccomp - 
seccomp.c:do_resolve_add_rule:210 - This syscall will NOT be blacklisted
  lxc-start 1422272908.488 INFO lxc_seccomp - 
seccomp.c:parse_c

Re: [lxc-users] Unprivileged Systemd-based Containers

[Christian Brauner]

Hello Dirk,

right, totally missed that. I tried it with the line

lxc.include =  lxc.include = /usr/local/share/lxcfs/00-lxcfs.conf

(after creating and making 00-lxcfs.conf executable obviously) in my .config.
And got:

  lxc-start 1422277724.347 INFO lxc_conf - conf.c:run_script_argv:344 - 
Executing script '@LXCFSSHAREDIR@/lxc.mount.hook' for container 'jessie', 
config section 'lxc'
  lxc-start 1422277724.352 ERRORlxc_conf - conf.c:run_buffer:324 - 
Script exited with status 127
  lxc-start 1422277724.352 ERRORlxc_conf - conf.c:lxc_setup:3772 - 
failed to run mount hooks for container 'jessie'.
  lxc-start 1422277724.352 ERRORlxc_start - start.c:do_start:699 - 
failed to setup the container
  lxc-start 1422277724.352 ERRORlxc_sync - sync.c:__sync_wait:51 - 
invalid sequence number 1. expected 2
  lxc-start 1422277724.417 ERRORlxc_start - start.c:__lxc_start:1099 - 
failed to spawn 'jessie'
  lxc-start 1422277724.420 ERRORlxc_start_ui - lxc_start.c:main:344 - 
The container failed to start.
  lxc-start 1422277724.420 ERRORlxc_start_ui - lxc_start.c:main:348 - 
Additional information can be obtained by setting the --logfile and 
--logpriority options.

Not including

lxc.include =  lxc.include = /usr/local/share/lxcfs/00-lxcfs.conf

in my .config gives even with LXC 1.1 (lxc-1.1.0.rc2.1.gab35147-1) gives:

Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted

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

[lxc-users] Unprivileged Systemd-based Containers

[Christian Brauner]

Hello,

I had a typo in my `00-lxcfs.conf`. After correcting this I can boot an
unprivileged systemd-based jessie container.

One question remains: How can I create unprivileged containers for
fedora and OpenSuse?

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

[lxc-users] How can I receive images for unprivileged fedora and opensuse containers?

[Christian Brauner]

Hello,

Is there a way to get unprivileged systemd-based images for e.g. fedora
and opensuse? There do not seem to be any downloadable images so far.

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

[lxc-users] Block devices not permitted on file system

[Christian Brauner]

Hello,

booting unprivileged ubuntu trusty and vivid container I get the
following messaged when shutting them down:

umount: /dev/zero: block devices are not permitted on filesystem
umount: /dev/urandom: block devices are not permitted on filesystem
umount: /dev/tty: block devices are not permitted on filesystem
umount: /dev/random: block devices are not permitted on filesystem
umount: /dev/null: block devices are not permitted on filesystem
umount: /dev/full: block devices are not permitted on filesystem
umount: /dev/console: block devices are not permitted on filesystem

that goes for basically all device bind-mounts:

umount: /dev/fb0: block devices are not permitted on filesystem
umount: /dev/video0: block devices are not permitted on filesystem
umount: /dev/dri: block devices are not permitted on filesystem
umount: /dev/snd: block devices are not permitted on filesystem
umount: /dev/zero: block devices are not permitted on filesystem
umount: /dev/urandom: block devices are not permitted on filesystem
umount: /dev/tty: block devices are not permitted on filesystem
umount: /dev/random: block devices are not permitted on filesystem
umount: /dev/null: block devices are not permitted on filesystem
umount: /dev/full: block devices are not permitted on filesystem
umount: /dev/console: block devices are not permitted on filesystem

Can someone explain this?

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

Re: [lxc-users] Block devices not permitted on file system

[Christian Brauner]

On Sun, Feb 01, 2015 at 12:00:01PM +, 
lxc-users-requ...@lists.linuxcontainers.org wrote:
> Date: Sun, 1 Feb 2015 07:38:57 +
> From: Serge Hallyn 
> To: LXC users mailing-list 
> Subject: Re: [lxc-users] Block devices not permitted on file system
> 
> Quoting Christian Brauner (subroutinec...@gmail.com):
> > Hello,
> > 
> > booting unprivileged ubuntu trusty and vivid container I get the
> > following messaged when shutting them down:
> > 
> > umount: /dev/zero: block devices are not permitted on filesystem
> 
> Apparently this is an error emitted by umount.c in util-linux when it
> gets a -EACCES.  My guess is that your underlying fs has real blockdevs,
> and the fs is MS_NODEV, and umount is somehow finding that unmounting
> the file mounted over those files would violate MS_NODEV.  I say somehow
> bc I don't see the code doing that check.
> 
> Though it's also possible that umount is misdiagnosing the EACCES.
> Just to be sure, you could try booting the container without apparmor:
> 
> lxc.aa_profile = unconfined
> 
> and see if that still does it.
That won't help as I'm on an Archlinux box which does not use Apparmor and I
did not compile it into my kernel. My lxc version is 1.1, cgmanger 0.35, lxcfs
0.5

At least the output of findmnt does not show any "nodev" for /dev/sda2:

[chb@conventiont ~]$ findmnt
TARGET   SOURCEFSTYPE  OPTIONS
//dev/sda2[/@] btrfs   
rw,relatime,compress-force=lzo,space_cache,autodefrag
├─/proc  proc  proc
rw,nosuid,nodev,noexec,relatime
│ └─/proc/sys/fs/binfmt_misc systemd-1 autofs  
rw,relatime,fd=28,pgrp=1,timeout=300,minproto=5,maxproto=5,direct
│   └─/proc/sys/fs/binfmt_misc   binfmt_misc   binfmt_misc rw,relatime
├─/sys   sys   sysfs   
rw,nosuid,nodev,noexec,relatime
│ ├─/sys/kernel/security securityfssecurityfs  
rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/cgroup   tmpfs tmpfs   rw,mode=755
│ │ ├─/sys/fs/cgroup/systemd cgroupcgroup  
rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd
│ │ ├─/sys/fs/cgroup/cpu,cpuacct cgroupcgroup  
rw,nosuid,nodev,noexec,relatime,cpu,cpuacct
│ │ ├─/sys/fs/cgroup/devices cgroupcgroup  
rw,nosuid,nodev,noexec,relatime,devices
│ │ ├─/sys/fs/cgroup/freezer cgroupcgroup  
rw,nosuid,nodev,noexec,relatime,freezer
│ │ ├─/sys/fs/cgroup/hugetlb cgroupcgroup  
rw,nosuid,nodev,noexec,relatime,hugetlb,release_agent=/run/cgmanager/agents/cgm-release-agent.hugetlb
│ │ ├─/sys/fs/cgroup/cpuset  cgroupcgroup  
rw,nosuid,nodev,noexec,relatime,cpuset,clone_children
│ │ ├─/sys/fs/cgroup/blkio   cgroupcgroup  
rw,nosuid,nodev,noexec,relatime,blkio
│ │ ├─/sys/fs/cgroup/memory  cgroupcgroup  
rw,nosuid,nodev,noexec,relatime,memory
│ │ ├─/sys/fs/cgroup/debug   cgroupcgroup  
rw,nosuid,nodev,noexec,relatime,debug
│ │ ├─/sys/fs/cgroup/net_cls cgroupcgroup  
rw,nosuid,nodev,noexec,relatime,net_cls
│ │ └─/sys/fs/cgroup/perf_event  cgroupcgroup  
rw,nosuid,nodev,noexec,relatime,perf_event,release_agent=/run/cgmanager/agents/cgm-release-agent.perf_event
│ ├─/sys/fs/pstore   pstorepstore  
rw,nosuid,nodev,noexec,relatime
│ ├─/sys/firmware/efi/efivarsefivarfs  efivarfs
rw,nosuid,nodev,noexec,relatime
│ ├─/sys/kernel/debugdebugfs   debugfs rw,relatime
│ ├─/sys/fs/fuse/connections fusectl   fusectl rw,relatime
│ └─/sys/kernel/config   configfs  configfsrw,relatime
├─/dev   dev   devtmpfs
rw,nosuid,relatime,size=4035240k,nr_inodes=1008810,mode=755
│ ├─/dev/shm tmpfs tmpfs   rw,nosuid,nodev
│ ├─/dev/pts devptsdevpts  
rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ ├─/dev/hugepages   hugetlbfs hugetlbfs   rw,relatime
│ └─/dev/mqueue  mqueuemqueue  rw,relatime
├─/run   run   tmpfs   
rw,nosuid,nodev,relatime,mode=755
│ └─/run/user/1000   tmpfs tmpfs   
rw,nosuid,nodev,relatime,size=807664k,mode=700,uid=1000,gid=1000
├─/tmp   tmpfs tmpfs   rw
├─/boot  /dev/sda1 vfat
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro
└─/var/lib/docker/btrfs  /dev/sda2[/@/var/lib/docker/btrfs]

> 

Re: [lxc-users] Block devices not permitted on file system

[Christian Brauner]

On Sun, Feb 01, 2015 at 12:00:01PM +, 
lxc-users-requ...@lists.linuxcontainers.org wrote:
> From serge.hallyn at ubuntu.com  Sun Feb  1 15:48:08 2015
> From: serge.hallyn at ubuntu.com (Serge Hallyn)
> Date: Sun, 1 Feb 2015 15:48:08 +
> Subject: [lxc-users] Block devices not permitted on file system
> In-Reply-To: <20150201142655.ga1...@gmail.com>
> References: 
>  <20150201142655.ga1...@gmail.com>
> Message-ID: <20150201154808.GB16770@ubuntumail>
> 
> Quoting Christian Brauner (christianvanbrauner at gmail.com):
> > On Sun, Feb 01, 2015 at 12:00:01PM +, lxc-users-request at 
> > lists.linuxcontainers.org wrote:
> > > Date: Sun, 1 Feb 2015 07:38:57 +
> > > From: Serge Hallyn 
> > > To: LXC users mailing-list 
> > > Subject: Re: [lxc-users] Block devices not permitted on file system
> > > 
> > > Quoting Christian Brauner (subroutinecall at gmail.com):
> > > > Hello,
> > > > 
> > > > booting unprivileged ubuntu trusty and vivid container I get the
> > > > following messaged when shutting them down:
> > > > 
> > > > umount: /dev/zero: block devices are not permitted on filesystem
> > > 
> > > Apparently this is an error emitted by umount.c in util-linux when it
> > > gets a -EACCES.  My guess is that your underlying fs has real blockdevs,
> > > and the fs is MS_NODEV, and umount is somehow finding that unmounting
> > > the file mounted over those files would violate MS_NODEV.  I say somehow
> > > bc I don't see the code doing that check.
> > > 
> > > Though it's also possible that umount is misdiagnosing the EACCES.
> > > Just to be sure, you could try booting the container without apparmor:
> > > 
> > > lxc.aa_profile = unconfined
> > > 
> > > and see if that still does it.
> > That won't help as I'm on an Archlinux box which does not use Apparmor and I
> > did not compile it into my kernel. My lxc version is 1.1, cgmanger 0.35, 
> > lxcfs
> > 0.5
> 
> Ah, well that's just as helpful :)
> 
Haha, nice :)
> Which kernel version are you using?
> 
3.18.5 downloaded and compiled directly from kernel.org with userns
support compiled in. Additionally, I compiled in (not as module!) btrfs,
FUSE and Overlay.

> > At least the output of findmnt does not show any "nodev" for /dev/sda2:
> 
> Is this from the host or container?  (looks like the host;  if it is,
> can you show /proc/1/mountinfo in the container?)
> 
This was from the host side. I will use Debian wheezy as an example as
it is currently up, it's the same with Ubuntu Trusty and Oracle.
Containers with systemd as init running unprivileged are not a problem
because they use lxcfs's fuse fs:

Here is the output of /proc/1/mountinfo from an unprivileged Debian
Wheezy container:
root@wheezy:~# cat /proc/1/mountinfo 
138 139 0:17 /@/home/chb/.local/share/lxc/wheezy/rootfs / rw,relatime master:1 
- btrfs /dev/sda2 rw,compress-force=lzo,space_cache,autodefrag
247 138 0:82 / /dev rw,nodev,relatime - tmpfs none 
rw,size=100k,mode=755,uid=10,gid=10
248 138 0:84 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
249 248 0:84 /sys /proc/sys ro,nosuid,nodev,noexec,relatime - proc proc rw
250 248 0:84 /sysrq-trigger /proc/sysrq-trigger ro,nosuid,nodev,noexec,relatime 
- proc proc rw
251 138 0:85 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
252 251 0:85 / /sys ro,nosuid,nodev,noexec,relatime - sysfs sysfs rw
253 252 0:85 / /sys/devices/virtual/net rw,nodev,relatime - sysfs sysfs rw
254 253 0:85 /devices/virtual/net /sys/devices/virtual/net 
rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
255 252 0:40 / /sys/fs/fuse/connections rw,relatime master:28 - fusectl fusectl 
rw
256 247 0:5 /console /dev/console rw,nosuid,relatime master:2 - devtmpfs dev 
rw,size=4035240k,nr_inodes=1008810,mode=755
257 247 0:5 /full /dev/full rw,nosuid,relatime master:2 - devtmpfs dev 
rw,size=4035240k,nr_inodes=1008810,mode=755
258 247 0:5 /null /dev/null rw,nosuid,relatime master:2 - devtmpfs dev 
rw,size=4035240k,nr_inodes=1008810,mode=755
259 247 0:5 /random /dev/random rw,nosuid,relatime master:2 - devtmpfs dev 
rw,size=4035240k,nr_inodes=1008810,mode=755
260 247 0:5 /tty /dev/tty rw,nosuid,relatime master:2 - devtmpfs dev 
rw,size=4035240k,nr_inodes=1008810,mode=755
261 247 0:5 /urandom /dev/urandom rw,nosuid,relatime master:2 - devtmpfs dev 
rw,size=4035240k,nr_inodes=1008810,mode=755
262 247 0:5 /zero /dev/zero rw,nosuid,relatime master:2 - devtmpfs dev 
rw,size=4035240k,nr_inodes=1008810,mode=755
263 252 0:86 / /sys/fs/cgroup rw,nodev,relatime - tmpfs cgroup 
rw,size=12k,mode=755,uid=10,gid=10
264 263 0:23 /cgmanager /sys/fs/cgroup/cgmanag

[lxc-users] OOMScoreAdjust= in dbus.service on systemd-based unprivileged containers

[Christian Brauner]

Hello,

In the past I had troubles getting systemd-based unprivileged containers
such as Archlinux or Debian Jessie to boot. On the other hand some
systemd-based unpriv. containers such as Ubuntu Vivid worked fine and
out of the box. (But I remember Stephane once saying that they were
somehow patched.)

With a little trick I can now also get Archlinux unpriv. containers
booting out of the box, meaning I pacstrap a file-system and then use
uidmapshift to map ids and gids or create a privileged one with the LXC
template and then uidmapshift them.

For this to work the dbus.service file in the unpriv.  Archlinux
container under /usr/lib/systemd/system/ must be patched. It contains
the entry:

OOMScoreAdjust=-900

where OOMScoreAdjust

"Sets the adjustment level for the Out-Of-Memory killer for executed
processes. Takes an integer between -1000 (to disable OOM killing
for this process) and 1000 (to make killing of this process under
memory pressure very likely). See proc.txt for details."

(I won't get into detail here as all the relevant parts can be found
under: https://www.kernel.org/doc/Documentation/filesystems/proc.txt)

The OOMScoreAdjust score of each process can be seen by doing

cat /proc/PID/oom_adj
cat /proc/PID/oom_score
cat /proc/PID/oom_score_adj

E.g. the values for dbus-daemon on an Archlinux host will look like
this:

cat /proc/PID/oom_adj

will be -15 (It is only there for backwards compatibility with older
kernels where the oom adjustement was made there.).

cat /proc/PID/oom_adj_score

will be -900 as specified in dbus.service on Archlinux.

Finally,

cat /proc/PID/oom_score

will be 0.

Both values, -15 and -900 make dbus one of the few processes that is
killed last when out of memory.

All unprivileged containers I have run so far (Ubuntu Vivid, Debian
Jessie) even though they may have the line OOMScoreAdjust in their
dbus.service file do not adjust this value meaning when they boot they
show 0 on all three fields under proc.

When disabling OOMScoreAdjust in the Archlinux dbus.service file of the
unpriv. container the boot will be immediately succesfull and all three
values under proc will show 0 just as for an Ubuntu Vivid or Debian
Jessie unpriv. container.

So it seems that during boot systemd in Archlinux is trying to adjust
the oom score under its /proc tree for dbus but somehow fails.

Maybe this will help some people. Should I also file this on LXC github?

Best,
Christian


pgprfTGB3DMis.pgp
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] OOMScoreAdjust= in dbus.service on systemd-based

[Christian Brauner]

unprivileged containers (Serge Hallyn)
Reply-To: 
In-Reply-To: 

On Thu, Feb 05, 2015 at 04:54:55PM +, 
lxc-users-requ...@lists.linuxcontainers.org wrote:
> Date: Thu, 5 Feb 2015 15:58:45 +
> From: Serge Hallyn 
> To: LXC users mailing-list 
> Subject: Re: [lxc-users] OOMScoreAdjust= in dbus.service on systemd-based
>  unprivileged containers
> 
> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg26524.html
> 
> ?
I did not see this. Systemd 218-1 on Archlinux does not yet include this
patch as no new system version has been released.

Best,
Christian

> 
> Quoting Christian Brauner (christianvanbrau...@gmail.com):
> > Hello,
> > 
> > In the past I had troubles getting systemd-based unprivileged containers
> > such as Archlinux or Debian Jessie to boot. On the other hand some
> > systemd-based unpriv. containers such as Ubuntu Vivid worked fine and
> > out of the box. (But I remember Stephane once saying that they were
> > somehow patched.)
> > 
> > With a little trick I can now also get Archlinux unpriv. containers
> > booting out of the box, meaning I pacstrap a file-system and then use
> > uidmapshift to map ids and gids or create a privileged one with the LXC
> > template and then uidmapshift them.
> > 
> > For this to work the dbus.service file in the unpriv.  Archlinux
> > container under /usr/lib/systemd/system/ must be patched. It contains
> > the entry:
> > 
> > OOMScoreAdjust=-900
> > 
> > where OOMScoreAdjust
> > 
> > "Sets the adjustment level for the Out-Of-Memory killer for executed
> > processes. Takes an integer between -1000 (to disable OOM killing
> > for this process) and 1000 (to make killing of this process under
> > memory pressure very likely). See proc.txt for details."
> > 
> > (I won't get into detail here as all the relevant parts can be found
> > under: https://www.kernel.org/doc/Documentation/filesystems/proc.txt)
> > 
> > The OOMScoreAdjust score of each process can be seen by doing
> > 
> > cat /proc/PID/oom_adj
> > cat /proc/PID/oom_score
> > cat /proc/PID/oom_score_adj
> > 
> > E.g. the values for dbus-daemon on an Archlinux host will look like
> > this:
> > 
> > cat /proc/PID/oom_adj
> > 
> > will be -15 (It is only there for backwards compatibility with older
> > kernels where the oom adjustement was made there.).
> > 
> > cat /proc/PID/oom_adj_score
> > 
> > will be -900 as specified in dbus.service on Archlinux.
> > 
> > Finally,
> > 
> > cat /proc/PID/oom_score
> > 
> > will be 0.
> > 
> > Both values, -15 and -900 make dbus one of the few processes that is
> > killed last when out of memory.
> > 
> > All unprivileged containers I have run so far (Ubuntu Vivid, Debian
> > Jessie) even though they may have the line OOMScoreAdjust in their
> > dbus.service file do not adjust this value meaning when they boot they
> > show 0 on all three fields under proc.
> > 
> > When disabling OOMScoreAdjust in the Archlinux dbus.service file of the
> > unpriv. container the boot will be immediately succesfull and all three
> > values under proc will show 0 just as for an Ubuntu Vivid or Debian
> > Jessie unpriv. container.
> > 
> > So it seems that during boot systemd in Archlinux is trying to adjust
> > the oom score under its /proc tree for dbus but somehow fails.
> > 
> > Maybe this will help some people. Should I also file this on LXC github?
> > 
> > Best,
> > Christian


pgpyFhdbMQHAF.pgp
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] OOMScoreAdjust= in dbus.service on systemd-based

[Christian Brauner]

I hope so, I've just patched my systemd source code and it's currently
compiling. :) One thing I'm currently not clear about is whether the
host or the container systemd needs to be patched... I'll go with the
host. :)

Christian


pgpDtTzFVYnMk.pgp
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Block devices not permitted on file system

[Christian Brauner]

> Quoting Christian Brauner (christianvanbrauner at gmail.com):
> > On Sun, Feb 01, 2015 at 12:00:01PM +, lxc-users-request at 
> > lists.linuxcontainers.org wrote:
> > This was from the host side. I will use Debian wheezy as an example as
> > it is currently up, it's the same with Ubuntu Trusty and Oracle.
> > Containers with systemd as init running unprivileged are not a problem
> > because they use lxcfs's fuse fs:
> >
> > Here is the output of /proc/1/mountinfo from an unprivileged Debian
> > Wheezy container:
> > root at wheezy:~# cat /proc/1/mountinfo
> > 138 139 0:17 /@/home/chb/.local/share/lxc/wheezy/rootfs / rw,relatime 
> > master:1 - btrfs /dev/sda2 rw,compress-force=lzo,space_cache,autodefrag
> > 247 138 0:82 / /dev rw,nodev,relatime - tmpfs none 
> > rw,size=100k,mode=755,uid=10,gid=10
>
> Ok, so I'm just guessing as I haven't found the code that would be
> doing this, but the nodev here may be the trigger.  I want to find
> some time to test myself with newest kernel, hopefully next week.

Thanks so much for investigating this, and of course in general for all the
help here! :)


pgpYf2MGL1G8H.pgp
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] OOMScoreAdjust= in dbus.service on systemd-based

[Christian Brauner]

On Thu, Feb 05, 2015 at 09:25:12PM +0100, Christian Brauner wrote:
> I hope so, I've just patched my systemd source code and it's currently
> compiling. :) One thing I'm currently not clear about is whether the
> host or the container systemd needs to be patched... I'll go with the
> host. :)
> 
> Christian

I think this is the patch on cgit for systemd you were talking about,
Serge?
http://cgit.freedesktop.org/systemd/systemd/patch/?id=d5243d628624038567c576e9b69c1d775eb05a05

I downloaded and succesfully applied it but systemd stills seems to be
hanging no matter if I patch the host or the container... I'm just
compiling it again to make sure I made no mistake. Did you already have
the chance to test it yourself?

Christian


pgprZvXEB6vPQ.pgp
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] OOMScoreAdjust= in dbus.service on systemd-based

[Christian Brauner]

On Thu, Feb 05, 2015 at 10:14:37PM +0100, Christian Brauner wrote:
> On Thu, Feb 05, 2015 at 09:25:12PM +0100, Christian Brauner wrote:
> > I hope so, I've just patched my systemd source code and it's currently
> > compiling. :) One thing I'm currently not clear about is whether the
> > host or the container systemd needs to be patched... I'll go with the
> > host. :)
> > 
> > Christian
> 
> I think this is the patch on cgit for systemd you were talking about,
> Serge?
> http://cgit.freedesktop.org/systemd/systemd/patch/?id=d5243d628624038567c576e9b69c1d775eb05a05
> 
> I downloaded and succesfully applied it but systemd stills seems to be
> hanging no matter if I patch the host or the container... I'm just
> compiling it again to make sure I made no mistake. Did you already have
> the chance to test it yourself?
> 
> Christian

Starting the container without OOMScoreAdjust commented out gives me
(when I strace /sbin/init from the host):

epoll_wait(4, {{EPOLLIN, {u32=3, u64=3}}}, 29, 0) = 1
clock_gettime(CLOCK_BOOTTIME, {2116, 108967782}) = 0
read(25, "\1\0\0\0\0\0\0\0", 8) = 8
timerfd_settime(25, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={2062, 
78585}}, NULL) = 0

Christian


pgpuuZ05nbcNx.pgp
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] OOMScoreAdjust= in dbus.service on systemd-based

[Christian Brauner]

On Thu, Feb 05, 2015 at 10:19:15PM +0100, Christian Brauner wrote:
> On Thu, Feb 05, 2015 at 10:14:37PM +0100, Christian Brauner wrote:
> > On Thu, Feb 05, 2015 at 09:25:12PM +0100, Christian Brauner wrote:
> > > I hope so, I've just patched my systemd source code and it's currently
> > > compiling. :) One thing I'm currently not clear about is whether the
> > > host or the container systemd needs to be patched... I'll go with the
> > > host. :)
> > > 
> > > Christian
> > 
> > I think this is the patch on cgit for systemd you were talking about,
> > Serge?
> > http://cgit.freedesktop.org/systemd/systemd/patch/?id=d5243d628624038567c576e9b69c1d775eb05a05
> > 
> > I downloaded and succesfully applied it but systemd stills seems to be
> > hanging no matter if I patch the host or the container... I'm just
> > compiling it again to make sure I made no mistake. Did you already have
> > the chance to test it yourself?
> > 
> > Christian
> 
> Starting the container without OOMScoreAdjust commented out gives me
> (when I strace /sbin/init from the host):
> 
> epoll_wait(4, {{EPOLLIN, {u32=3, u64=3}}}, 29, 0) = 1
> clock_gettime(CLOCK_BOOTTIME, {2116, 108967782}) = 0
> read(25, "\1\0\0\0\0\0\0\0", 8) = 8
> timerfd_settime(25, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={2062, 
> 78585}}, NULL) = 0
> 
> Christian

If I boot with the OOMScoreAdjust in dbus.service enabled with the patched
applied on the host and in the container and strace /sbin/init again I get:

open("/sys/fs/cgroup/systemd/user.slice/user-1000.slice/session-c1.scope/chb/arch/system.slice/dbus.service/cgroup.procs",
 O_RDONLY|O_CLOEXEC) = 32
fstat(32, {st_mode=S_IFREG|0644, st_size=5, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fa470213000
read(32, "232\n", 4096) = 4
close(32)   = 0
munmap(0x7fa470213000, 4096)= 0
open("/dev/console", O_WRONLY|O_NOCTTY|O_CLOEXEC) = 32
ioctl(32, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
{B38400 opost isig icanon echo ...}) = 0
ioctl(32, TIOCGWINSZ, {ws_row=49, ws_col=84, ws_xpixel=681, ws_ypixel=747}) = 0
writev(32, [{"[", 1}, {"\33[32m  OK  \33[0m", 15}, {"] ", 2}, {"Started D-Bus 
System Message Bus"..., 33}, {"\n", 1}], 5) = 52
close(32)   = 0
sendmsg(30, {msg_name(0)=NULL, 
msg_iov(9)=[{"PRIORITY=6\nSYSLOG_FACILITY=3\nCOD"..., 131}, 
{"UNIT=dbus.service", 17}, {"\n", 1}, {"MESSAGE_ID=39f53479d3a045ac8e117"..., 
43}, {"\n", 1}, {"MESSAGE=Started D-Bus System Mes"..., 41}, {"\n", 1}, 
{"RESULT=done", 11}, {"\n", 1}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) 
= 247
epoll_ctl(4, EPOLL_CTL_DEL, 3, NULL)= 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 32
setsockopt(32, SOL_SOCKET, SO_PASSCRED, [0], 4) = 0
setsockopt(32, SOL_SOCKET, 0x22 /* SO_??? */, [0], 4) = 0
getsockopt(32, SOL_SOCKET, SO_RCVBUF, [212992], [4]) = 0
setsockopt(32, SOL_SOCKET, 0x21 /* SO_??? */, [8388608], 4) = -1 EPERM 
(Operation not permitted)
setsockopt(32, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0
getsockopt(32, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0
setsockopt(32, SOL_SOCKET, 0x20 /* SO_??? */, [8388608], 4) = -1 EPERM 
(Operation not permitted)
setsockopt(32, SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0
connect(32, {sa_family=AF_LOCAL, sun_path="/var/run/dbus/system_bus_socket"}, 
33) = 0
getsockopt(32, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0
fstat(32, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
getsockopt(32, SOL_SOCKET, SO_ACCEPTCONN, [0], [4]) = 0
getsockname(32, {sa_family=AF_LOCAL, NULL}, [2]) = 0
geteuid()   = 0
sendmsg(32, {msg_name(0)=NULL, msg_iov(3)=[{"\0AUTH EXTERNAL ", 15}, {"30", 2}, 
{"\r\nNEGOTIATE_UNIX_FD\r\nBEGIN\r\n", 28}], msg_controllen=0, msg_flags=0}, 
MSG_DONTWAIT|MSG_NOSIGNAL) = 45
recvmsg(32, 0x7fffe704ddd0, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 
EAGAIN (Resource temporarily unavailable)
ppoll([{fd=32, events=POLLIN}], 1, {24, 99978}, NULL, 8^CProcess 11517 
detached
 



pgp0o46jTvZCT.pgp
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] OOMScoreAdjust= in dbus.service on systemd-based

[Christian Brauner]

Patching the containers systemd with:

From: Lennart Poettering 
Date: Thu, 8 Jan 2015 23:12:16 +0100
Subject: core: make EPERM errors when applying OOM adjustment for forked
 processes non-fatal

This should be useful for user namespaces.
---
 src/core/execute.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/core/execute.c b/src/core/execute.c
index 5e4135e..22b7862 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -1359,12 +1359,16 @@ static int exec_child(ExecCommand *command,
 }

 if (context->oom_score_adjust_set) {
-char t[16];
+char t[DECIMAL_STR_MAX(context->oom_score_adjust)];

-snprintf(t, sizeof(t), "%i", context->oom_score_adjust);
-char_array_0(t);
+/* When we can't make this change due to EPERM, then
+ * let's silently skip over it. User namespaces
+ * prohibit write access to this file, and we
+ * shouldn't trip up over that. */

-if (write_string_file("/proc/self/oom_score_adj", t) < 0) {
+sprintf(t, "%i", context->oom_score_adjust);
+err = write_string_file("/proc/self/oom_score_adj", t);
+if (err < 0 && err != -EPERM && err != -EACCES) {
 *error = EXIT_OOM_ADJUST;
 return -errno;
 }

works

On Thu, Feb 05, 2015 at 10:51:26PM +0100, Christian Brauner wrote:
> On Thu, Feb 05, 2015 at 10:19:15PM +0100, Christian Brauner wrote:
> > On Thu, Feb 05, 2015 at 10:14:37PM +0100, Christian Brauner wrote:
> > > On Thu, Feb 05, 2015 at 09:25:12PM +0100, Christian Brauner wrote:
> > > > I hope so, I've just patched my systemd source code and it's currently
> > > > compiling. :) One thing I'm currently not clear about is whether the
> > > > host or the container systemd needs to be patched... I'll go with the
> > > > host. :)
> > > > 
> > > > Christian
> > > 
> > > I think this is the patch on cgit for systemd you were talking about,
> > > Serge?
> > > http://cgit.freedesktop.org/systemd/systemd/patch/?id=d5243d628624038567c576e9b69c1d775eb05a05
> > > 
> > > I downloaded and succesfully applied it but systemd stills seems to be
> > > hanging no matter if I patch the host or the container... I'm just
> > > compiling it again to make sure I made no mistake. Did you already have
> > > the chance to test it yourself?
> > > 
> > > Christian
> > 
> > Starting the container without OOMScoreAdjust commented out gives me
> > (when I strace /sbin/init from the host):
> > 
> > epoll_wait(4, {{EPOLLIN, {u32=3, u64=3}}}, 29, 0) = 1
> > clock_gettime(CLOCK_BOOTTIME, {2116, 108967782}) = 0
> > read(25, "\1\0\0\0\0\0\0\0", 8) = 8
> > timerfd_settime(25, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={2062, 
> > 78585}}, NULL) = 0
> > 
> > Christian
> 
> If I boot with the OOMScoreAdjust in dbus.service enabled with the patched
> applied on the host and in the container and strace /sbin/init again I get:
> 
> open("/sys/fs/cgroup/systemd/user.slice/user-1000.slice/session-c1.scope/chb/arch/system.slice/dbus.service/cgroup.procs",
>  O_RDONLY|O_CLOEXEC) = 32
> fstat(32, {st_mode=S_IFREG|0644, st_size=5, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7fa470213000
> read(32, "232\n", 4096) = 4
> close(32)   = 0
> munmap(0x7fa470213000, 4096)= 0
> open("/dev/console", O_WRONLY|O_NOCTTY|O_CLOEXEC) = 32
> ioctl(32, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
> {B38400 opost isig icanon echo ...}) = 0
> ioctl(32, TIOCGWINSZ, {ws_row=49, ws_col=84, ws_xpixel=681, ws_ypixel=747}) = > 0
> writev(32, [{"[", 1}, {"\33[32m  OK  \33[0m", 15}, {"] ", 2}, {"Started D-Bus 
> System Message Bus"..., 33}, {"\n", 1}], 5) = 52
> close(32)   = 0
> sendmsg(30, {msg_name(0)=NULL, 
> msg_iov(9)=[{"PRIORITY=6\nSYSLOG_FACILITY=3\nCOD"..., 131}, 
> {"UNIT=dbus.service", 17}, {"\n", 1}, {"MESSAGE_ID=39f53479d3a045ac8e117"..., 
> 43}, {"\n", 1}, {"MESSAGE=Started D-Bus System Mes"..., 41}, {"\n", 1}, 
> {"RESULT=done", 11}, {"\n", 1}], msg_cont

[lxc-users] List of bind-mount options

[Christian Brauner]

Hello,

is there a list of all possible options that an lxc bind-mount entry

lxc.mount.entry

it seems they are not necessarily the same as for fstab. E.g.

create=dir
create=file

I'm also unclear about "optional" and "none". Such a list would be
really good.

Best,
Christian


pgpSiQJxJzyrf.pgp
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] lxc.mount.entry bind mounts not respected on tmpfs filesystems

[Christian Brauner]

When an init such as systemd mounts a folder as a tmpfs during startup and the
lxc defines a bind-mount on the same folder in the containers config it will be
overmounted on container startup. Here is an example. Create an archlinux (or
fedora) container with:

sudo lxc-create -t archlinux -n arch

define a bind-mount on /tmp in the containers config in:

/var/lib/lxc/arch/config

with

lxc.mount.entry=/tmp/.X11-unix tmp/.X11-unix none ro,bind,create=dir 0 0

to mount the X0 socket of the X-server for e.g. graphical output. Now boot the
container. Altough lxc creates the bind-mount as can be seen e.g. from the
logs, the X0 socker will not show up under /tmp/.X11-unix as systemd's
tmp.mount unit mounts /tmp as a tmpfs over lxc's bind mount. This can be
verified in two steps. By doing

findmnt --target /tmp

in the container. This will show:

[root@arch ~]# findmnt --target /tmp/
TARGET SOURCE FSTYPE OPTIONS
/tmp   tmpfs  tmpfs  rw

And then by unmounting /tmp with:

umount /tmp

After this, the X0 socket will show up under /tmp/.X11-unix. I think Ubuntu has
a downstream patch because tmp is somehow treated differently on Debian-based
distros. (It must either be
Bring-tmpfiles.d-tmp.conf-in-line-with-Debian-defaul.patch or
Don-t-mount-tmp-as-tmpfs-by-default.patch as seen in the source code of
systemd_218-7ubuntu1.debian.tar.xz.) But for any other distro not using this
downstream patch this is a problem. When you want to have the default behavior
of having /tmp cleaned out on shutdown or reboot it is neither a good option to
disable nor to mask the service. Maybe, there is a workaround such that lxc' s
bind-mounts are respected/reflected even when on a mountpoint that gets mounted
as tmpfs during boot?

I also filed this as a github issue but a) I'm unsure whether it's lxc's job or
upstream systemd-related and b) is there an easy workaround apart from
disabling/masking tmp.mount or doing umount /tmp everytime after the container
has been started.

Christian


pgpvwsUzFQGYm.pgp
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] lxc.mount.entry bind mounts not respected on tmpfs filesystems

[Christian Brauner]

> On Sat, Feb 07, 2015 at 06:44:31PM +0100, Christian Brauner wrote:
> > When an init such as systemd mounts a folder as a tmpfs during startup and 
> > the
> > lxc defines a bind-mount on the same folder in the containers config it 
> > will be
> > overmounted on container startup. Here is an example. Create an archlinux 
> > (or
> > fedora) container with:
> > 
> > sudo lxc-create -t archlinux -n arch
> > 
> > define a bind-mount on /tmp in the containers config in:
> > 
> > /var/lib/lxc/arch/config
> > 
> > with
> > 
> > lxc.mount.entry=/tmp/.X11-unix tmp/.X11-unix none ro,bind,create=dir 0 0
> > 
> > to mount the X0 socket of the X-server for e.g. graphical output. Now boot 
> > the
> > container. Altough lxc creates the bind-mount as can be seen e.g. from the
> > logs, the X0 socker will not show up under /tmp/.X11-unix as systemd's
> > tmp.mount unit mounts /tmp as a tmpfs over lxc's bind mount. This can be
> > verified in two steps. By doing
> > 
> > findmnt --target /tmp
> > 
> > in the container. This will show:
> > 
> > [root at arch ~]# findmnt --target /tmp/
> > TARGET SOURCE FSTYPE OPTIONS
> > /tmp   tmpfs  tmpfs  rw
> > 
> > And then by unmounting /tmp with:
> > 
> > umount /tmp
> > 
> > After this, the X0 socket will show up under /tmp/.X11-unix. I think Ubuntu 
> > has
> > a downstream patch because tmp is somehow treated differently on 
> > Debian-based
> > distros. (It must either be
> > Bring-tmpfiles.d-tmp.conf-in-line-with-Debian-defaul.patch or
> > Don-t-mount-tmp-as-tmpfs-by-default.patch as seen in the source code of
> > systemd_218-7ubuntu1.debian.tar.xz.) But for any other distro not using this
> > downstream patch this is a problem. When you want to have the default 
> > behavior
> > of having /tmp cleaned out on shutdown or reboot it is neither a good 
> > option to
> > disable nor to mask the service. Maybe, there is a workaround such that 
> > lxc' s
> > bind-mounts are respected/reflected even when on a mountpoint that gets 
> > mounted
> > as tmpfs during boot?
> > 
> > I also filed this as a github issue but a) I'm unsure whether it's lxc's 
> > job or
> > upstream systemd-related and b) is there an easy workaround apart from
> > disabling/masking tmp.mount or doing umount /tmp everytime after the 
> > container
> > has been started.
> > 
> > Christian
> 
> There isn't really anything LXC can do to prevent over-mounting. You
> could drop the capability and thus prevent systemd from mounting
> anything, but I'm pretty sure that'd just fail your container boot
> entirely.
> 
> One thing that may however work, depending on how clever systemd is, is to 
> add:
> lxc.mount.entry = tmpfs /tmp tmpfs defaults
>

That actually does work with a slight modification:

lxc.mount.entry = tmpfs tmp tmpfs defaults

systemd seems smart enough :)

Thank you very much!
 
> Before the bind-mount line. This will cause lxc to mount your /tmp
> before starting init. If systemd is clever, it'll detect it was already
> mounted and will leave it alone.
> 
> 
> If that trick doesn't work, then you've got two solutions:
>  - Patch systemd
>  - Bind-mount to some other path which doesn't get over-mounted, then
>have a systemd job mount --move it back to place during boot.
> 
> 
> -- 
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com
> 


pgp846Hd4cpUb.pgp
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] unprivileged container with systemd?]

[Christian Brauner]

I think I can help here. Systemd-based unprivileged containers will only work
properly with systemd compiled from git (master) or systemd 218 patched with:

From: Lennart Poettering 
Date: Thu, 8 Jan 2015 23:12:16 +0100
Subject: core: make EPERM errors when applying OOM adjustment for forked
 processes non-fatal

This should be useful for user namespaces.
---
 src/core/execute.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/core/execute.c b/src/core/execute.c
index 5e4135e..22b7862 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -1359,12 +1359,16 @@ static int exec_child(ExecCommand *command,
 }
 
 if (context->oom_score_adjust_set) {
-char t[16];
+char t[DECIMAL_STR_MAX(context->oom_score_adjust)];
 
-snprintf(t, sizeof(t), "%i", context->oom_score_adjust);
-char_array_0(t);
+/* When we can't make this change due to EPERM, then
+ * let's silently skip over it. User namespaces
+ * prohibit write access to this file, and we
+ * shouldn't trip up over that. */
 
-if (write_string_file("/proc/self/oom_score_adj", t) < 0) {
+sprintf(t, "%i", context->oom_score_adjust);
+err = write_string_file("/proc/self/oom_score_adj", t);
+if (err < 0 && err != -EPERM && err != -EACCES) {
 *error = EXIT_OOM_ADJUST;
 return -errno;
 }

and

From: Martin Pitt 
Date: Mon, 29 Dec 2014 14:18:28 +0100
Subject: Loopback setup / rtnl fixes

Various bug fixes in loopback device setup and netlink socket communication,
taken from upstream commits e95e909 ff. Fixes massive CPU usage due to tight
retry loops in user LXC containers.
---
 src/core/loopback-setup.c | 42 +++
 src/libsystemd/sd-rtnl/rtnl-message.c | 18 ---
 src/libsystemd/sd-rtnl/sd-rtnl.c  |  4 +++-
 3 files changed, 36 insertions(+), 28 deletions(-)

diff --git a/src/core/loopback-setup.c b/src/core/loopback-setup.c
index 98fc04d..ca10e20 100644
--- a/src/core/loopback-setup.c
+++ b/src/core/loopback-setup.c
@@ -56,30 +56,24 @@ static int start_loopback(sd_rtnl *rtnl) {
 return 0;
 }
 
-static int check_loopback(void) {
+static bool check_loopback(sd_rtnl *rtnl) {
+_cleanup_rtnl_message_unref_ sd_rtnl_message *req = NULL, *reply = 
NULL;
+unsigned flags;
 int r;
-_cleanup_close_ int fd = -1;
-union {
-struct sockaddr sa;
-struct sockaddr_in in;
-} sa = {
-.in.sin_family = AF_INET,
-.in.sin_addr.s_addr = INADDR_LOOPBACK,
-};
-
-/* If we failed to set up the loop back device, check whether
- * it might already be set up */
-
-fd = socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK|SOCK_CLOEXEC, 0);
-if (fd < 0)
-return -errno;
-
-if (bind(fd, &sa.sa, sizeof(sa.in)) >= 0)
-r = 1;
-else
-r = errno == EADDRNOTAVAIL ? 0 : -errno;
-
-return r;
+
+r = sd_rtnl_message_new_link(rtnl, &req, RTM_GETLINK, 
LOOPBACK_IFINDEX);
+if (r < 0)
+return false;
+
+r = sd_rtnl_call(rtnl, req, 0, &reply);
+if (r < 0)
+return false;
+
+r = sd_rtnl_message_link_get_flags(reply, &flags);
+if (r < 0)
+return false;
+
+return flags & IFF_UP;
 }
 
 int loopback_setup(void) {
@@ -92,7 +86,7 @@ int loopback_setup(void) {
 
 r = start_loopback(rtnl);
 if (r == -EPERM) {
-if (check_loopback() < 0)
+if (!check_loopback(rtnl))
 return log_warning_errno(EPERM, "Failed to configure 
loopback device: %m");
 } else if (r < 0)
 return log_warning_errno(r, "Failed to configure loopback 
device: %m");
diff --git a/src/libsystemd/sd-rtnl/rtnl-message.c 
b/src/libsystemd/sd-rtnl/rtnl-message.c
index 165e84d..e5a69bd 100644
--- a/src/libsystemd/sd-rtnl/rtnl-message.c
+++ b/src/libsystemd/sd-rtnl/rtnl-message.c
@@ -1294,8 +1294,10 @@ static int socket_recv_message(int fd, struct iovec 
*iov, uint32_t *_group, bool
 /* no data */
 if (errno == ENOBUFS)
 log_debug("rtnl: kernel receive buffer overrun");
+else if (errno == EAGAIN)
+log_debug("rtnl: no data in socket");
 
-return (errno == EAGAIN) ? 0 : -errno;
+return (errno == EAGAIN || errno == EINTR) ? 0 : -errno;
 } else if (r == 0)
 /* connection was closed by the kernel */
 return -ECONNRESET;
@@ -1307,8 +1309,10 @@ static int socket_recv_message(int fd, struct iovec 
*iov, uint32_t *_group, bool

Re: [lxc-users] unprivileged container with systemd?]

[Christian Brauner]

For the ones unfamiliar with patching software, here is are links to my
Google Drive with patched systemd-versions for Fedora 21 and Rawhide,
and Archlinux:

Fedora:

(1) systemd
https://drive.google.com/file/d/0B_UAut69TSAiTmI3SnN4TzRTaXM/view?usp=sharing

(2) systemd-libs
https://drive.google.com/file/d/0B_UAut69TSAiQkJKTmFjVDRyYVU/view?usp=sharing

Archlinux:

(1) systemd
https://drive.google.com/file/d/0B_UAut69TSAidi1wdzJKNmc3X1E/view?usp=sharing

(2) libsystemd
https://drive.google.com/file/d/0B_UAut69TSAiNWpvWVVxZ2dSSnc/view?usp=sharing

(3) systemd-sysvcompat
https://drive.google.com/file/d/0B_UAut69TSAiODFDZXF4MFVKMXM/view?usp=sharing

Have fun!
Christian

> I think I can help here. Systemd-based unprivileged containers will only work
> properly with systemd compiled from git (master) or systemd 218 patched with:
> 
> From: Lennart Poettering 
> Date: Thu, 8 Jan 2015 23:12:16 +0100
> Subject: core: make EPERM errors when applying OOM adjustment for forked
>  processes non-fatal
> 
> This should be useful for user namespaces.
> ---
>  src/core/execute.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/src/core/execute.c b/src/core/execute.c
> index 5e4135e..22b7862 100644
> --- a/src/core/execute.c
> +++ b/src/core/execute.c
> @@ -1359,12 +1359,16 @@ static int exec_child(ExecCommand *command,
>  }
>  
>  if (context->oom_score_adjust_set) {
> -char t[16];
> +char t[DECIMAL_STR_MAX(context->oom_score_adjust)];
>  
> -snprintf(t, sizeof(t), "%i", context->oom_score_adjust);
> -char_array_0(t);
> +/* When we can't make this change due to EPERM, then
> + * let's silently skip over it. User namespaces
> + * prohibit write access to this file, and we
> + * shouldn't trip up over that. */
>  
> -if (write_string_file("/proc/self/oom_score_adj", t) < 0) {
> +sprintf(t, "%i", context->oom_score_adjust);
> +err = write_string_file("/proc/self/oom_score_adj", t);
> +if (err < 0 && err != -EPERM && err != -EACCES) {
>  *error = EXIT_OOM_ADJUST;
>  return -errno;
>  }
> 
> and
> 
> From: Martin Pitt 
> Date: Mon, 29 Dec 2014 14:18:28 +0100
> Subject: Loopback setup / rtnl fixes
> 
> Various bug fixes in loopback device setup and netlink socket communication,
> taken from upstream commits e95e909 ff. Fixes massive CPU usage due to tight
> retry loops in user LXC containers.
> ---
>  src/core/loopback-setup.c | 42 
> +++
>  src/libsystemd/sd-rtnl/rtnl-message.c | 18 ---
>  src/libsystemd/sd-rtnl/sd-rtnl.c  |  4 +++-
>  3 files changed, 36 insertions(+), 28 deletions(-)
> 
> diff --git a/src/core/loopback-setup.c b/src/core/loopback-setup.c
> index 98fc04d..ca10e20 100644
> --- a/src/core/loopback-setup.c
> +++ b/src/core/loopback-setup.c
> @@ -56,30 +56,24 @@ static int start_loopback(sd_rtnl *rtnl) {
>  return 0;
>  }
>  
> -static int check_loopback(void) {
> +static bool check_loopback(sd_rtnl *rtnl) {
> +_cleanup_rtnl_message_unref_ sd_rtnl_message *req = NULL, *reply = 
> NULL;
> +unsigned flags;
>  int r;
> -_cleanup_close_ int fd = -1;
> -union {
> -struct sockaddr sa;
> -struct sockaddr_in in;
> -} sa = {
> -.in.sin_family = AF_INET,
> -.in.sin_addr.s_addr = INADDR_LOOPBACK,
> -};
> -
> -/* If we failed to set up the loop back device, check whether
> - * it might already be set up */
> -
> -fd = socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK|SOCK_CLOEXEC, 0);
> -if (fd < 0)
> -return -errno;
> -
> -if (bind(fd, &sa.sa, sizeof(sa.in)) >= 0)
> -r = 1;
> -else
> -r = errno == EADDRNOTAVAIL ? 0 : -errno;
> -
> -return r;
> +
> +r = sd_rtnl_message_new_link(rtnl, &req, RTM_GETLINK, 
> LOOPBACK_IFINDEX);
> +if (r < 0)
> +return false;
> +
> +r = sd_rtnl_call(rtnl, req, 0, &reply);
> +if (r < 0)
> +return false;
> +
> +r = sd_rtnl_message_link_get_flags(reply, &flags);
> +if (r < 0)
> +return false;
> +
> +return flags & IFF_UP;
>  }
>  
>  int loopback_setup(void) {
> @@ -92,7 +86,7 @@ int loopback_setup(void) {
>  
>  r = start_loopback(rtnl);
>  if (r == -EPERM) {
> -if (check_loopback() < 0)
> +if (!check_loopback(rtnl))
>  return log_warning_errno(EPERM, "Failed to configure 
> loopback device: %m");
>  } else if (r < 0)
>  return log_warning_errno(r, "Failed to configure loopback 
> device: %m");
> diff --git a/src/libsystem

[lxc-users] macvlan-based networking for unprivileged containers

[Christian Brauner]

Hello,

is it currently possible to use macvlan interfaces with unprivileged
containers?

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

[lxc-users] cgmanager: Could not get password database information for UID of current process

[Christian Brauner]

When I follow the journal output of systemd with
journalctl -f
I see an endless stream of warnings thrown by cgmanager. They are all
the same and state:

cgmanager[324]: Could not get password database information for UID
of current process: User "???" unknown or no memory to allocate
password entry

Everything on my system is working fine as far as I can see. I'm using
Archlinux with Kernel 3.19.3 compiled from source. Is this caused by
dbus and cgmanager communication? My shadow version is 4.2.1-3. My
cgroups are created manually with

sudo cgm create all $USER
sudo cgm chown all chb $(id -u) $(id -g)
cgm movepid all chb $$

Any ideas what this is caused by and how it can be stopped?

Best,
Christian


pgp_cX1plOVfZ.pgp
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] cgmanager: Could not get password database information for UID of current process

[Christian Brauner]

Hello,

When I follow the journal output of systemd with

journalctl -f

I see an endless stream of warnings thrown by cgmanager. They are all
the same and appear for every operation I do where cgmanager is involved:

cgmanager[324]: Could not get password database information for UID
of current process: User "???" unknown or no memory to allocate
password entry

(E.g. when I run Google Chrome in a Ubuntu Vivid container cgmanager will
consistently output said warning.)

Everything on my system is working fine as far as I can see. I'm using
Archlinux with Kernel 3.19.3 compiled from source. Is this caused by
dbus and cgmanager communication? My shadow version is 4.2.1-3. My
cgroups are created manually with

sudo cgm create all $USER
sudo cgm chown all chb $(id -u) $(id -g)
cgm movepid all chb $$

Any ideas what this is caused by and how it can be stopped?

Best,
Christian


pgpFXh3Xzl63K.pgp
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] Unprivileged containers still cause kernel panic on 4.0.3 and 4.0.4

[Christian Brauner]

Hello,

it seems that the two patches which were accidently removed from 4.0.2 which are
required to prevent a kernel panic when starting unprivileged lxc containers are
still not present in 4.0.3 and 4.0.4. I still get a total freeze when starting
an unprivileged container on a 4.0.4 kernel. Accidental oversight by the kernel
folks or will we have to wait until 4.1 comes out?

Best,
Christian


pgps2Ks2sg_sy.pgp
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] Unprivileged containers still cause kernel panic on 4.0.3 and 4.0.4

[Christian Brauner]

Just a heads up,

4.1-rc4 includes both required patches:
(1) 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=820f9f147dcce2602eefd9b575bbbd9ea14f0953
(2) 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cd4a40174b71acd021877341684d8bb1dc8ea4ae

Best,
Christian


pgpkb5GfHXjXX.pgp
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] lxcfs 0.9

[Christian Brauner]

Hello,

it seems on Github lxcfs 0.9 is out for quite a while now but there has been no
source package uploaded to linuxcontainers.org. Is this on purpose? If not it
would be great if you could put it up so I can update the corresponding arch
package.

Best,
Christian


pgpFjSX2dD8IB.pgp
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] lxcfs 0.9

[Christian Brauner]

No problem. Thanks for fixing it so fast!

Best,
Christian

On Thu, Jun 04, 2015 at 12:00:03PM +, 
lxc-users-requ...@lists.linuxcontainers.org wrote:
>1. Re: lxcfs 0.9 (Serge Hallyn)
>2. Re: lxcfs 0.9 (Stéphane Graber)

> Date: Wed, 3 Jun 2015 14:47:46 +
> From: Serge Hallyn 
> To: LXC users mailing-list 
> Subject: Re: [lxc-users] lxcfs 0.9
> 
> Quoting Christian Brauner (christianvanbrau...@gmail.com):
> > Hello,
> > 
> > it seems on Github lxcfs 0.9 is out for quite a while now but there has 
> > been no
> > source package uploaded to linuxcontainers.org. Is this on purpose? If not 
> > it
> > would be great if you could put it up so I can update the corresponding arch
> > package.
> > 
> > Best,
> > Christian
> 
> Sorry, not sure how I failed to do that.  I've uploaded it now.  (I'll need
> to whip up a description for the news.md page for 0.8 and 0.9 later today)
> 

> Date: Wed, 3 Jun 2015 10:49:38 -0400
> From: Stéphane Graber 
> To: LXC users mailing-list 
> Subject: Re: [lxc-users] lxcfs 0.9
> 
> On Wed, Jun 03, 2015 at 09:29:56AM +0200, Christian Brauner wrote:
> > Hello,
> > 
> > it seems on Github lxcfs 0.9 is out for quite a while now but there has 
> > been no
> > source package uploaded to linuxcontainers.org. Is this on purpose? If not 
> > it
> > would be great if you could put it up so I can update the corresponding arch
> > package.
> > 
> > Best,
> > Christian
> 
> Looks like Serge forgot to upload the tarball to the website, I'll fix that 
> now.
> 
> 
> -- 
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com


pgpznPVuGY79T.pgp
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] lxcfs v0.10: Upload tar.gz to linuxcontainers.org

[Christian Brauner]

Hi,

it seems that lxcfs v0.10 is out but there is no corresponding source package on
the download site from lxcfs on linuxcontainers.org. Would be good for distros
that get their source package from there. :)

Christian


signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Regression in ephemeral containers

[Christian Brauner]

Hm, both work without a problem when I try it. safe_mount() is a function that
has been added recently to protect containers against symlinks. Specifically, it
prevents two things:

1. do not allow mounts to paths containing symbolic links

2. do not allow bind mounts from relative paths containing symbolic
   links.

You can read more about it here
(https://github.com/lxc/lxc/commit/592fd47a6245508b79fe6ac819fe6d3b2c1289be).
Maybe your problem relates to this. Also, I find this line:

> '/usr/lib/x86_64-linux-gnu/lxc/home/ubuntu/test.txt'

in the debug output odd. Did you change your temporary rootfs when pivot_dir is
called to /usr/lib/x86_64-linux-gnu/lxc? Standardly, I would expect
/usr/lib/lxc/rootfs.

Christian

On Mon, Oct 12, 2015 at 10:34:16PM +1100, overlay fs wrote:
> Regression
> ---
> It is no longer possible to bind-mount a file into an ephemeral
> container, using the version of lxc in the lxc-daily ppa.  This used
> to work; the regression was introduced some time after September 15.
> 
> Details
> -
> If the following entry is added to the config file of an ubuntu-14.04
> container named 'trusty',
> 
>lxc.mount.entry = /home/oleg/test.txt home/ubuntu/test.txt none
> bind,create=file 0 0
> 
> then lxc-start works ok,
> 
>lxc-start -d -n trusty
> 
> but lxc-start-ephemeral fails to start,
> 
>lxc-start-ephemeral -d -o trusty -n debug
> 
> The error message in the logfile is,
> 
>lxc_utils - utils.c:safe_mount:1641 - Invalid argument - Failed to
> mount /home/oleg/test.txt onto
> /usr/lib/x86_64-linux-gnu/lxc/home/ubuntu/test.txt
>lxc_conf - conf.c:mount_entry:1731 - Invalid argument - failed to
> mount '/home/oleg/test.txt' on
> '/usr/lib/x86_64-linux-gnu/lxc/home/ubuntu/test.txt'
>lxc_conf - conf.c:lxc_setup:3762 - failed to setup the mount
> entries for 'debug'lxc_start - start.c:do_start:722 - failed to
> setup the container


signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] [BUG] lxc-destroy destroying wrong containers

[Christian Brauner]

On Tue, Nov 10, 2015 at 10:02:00PM +0900, Tomasz Chmielewski wrote:
> On 2015-11-10 20:29, Christian Brauner wrote:
> 
> >This may not have something to do with lxc-destroy but with how clones
> >work. Can
> >you only proceed up to step 2) you listed:
> >
> >> 2) clone it - but before the command returns, press ctrl+c (say,
> >you
> >> realized you used a wrong name and want to interrupt):
> >>
> >> # lxc-clone -B dir testvm012d testvm13d
> >> [ctrl+c]
> >
> >and immediately afterwards check whether the rootfs of the original
> >container
> >testvm012d is still present?
> 
> Step 4 shows the original container is still intact:
> 
> # du -⁠sh testvm012d testvm13d
> 462Mtestvm012d
> 11M testvm13d
> 
> 
> So it must be lxc-destroy.

Yes, it is lxc-destroy but lxc-destroy does it exactly what it is expected to
do. The cause is the incomplete clone: When you clone a container config of the
original container gets copied. After the clone (copying the storage etc.)
succeeds the config is updated. That means before the config is updated the
config of your clone still contains the rootfs path to the original container.
You can verify this by doing:

# lxc-clone -B dir testvm012d testvm13d
[ctrl+c]

and checking

YOUR-FAVOURITE editor testvm13d/config

it should still contain

lxc.rootfs = /path/to/testvm012d/rootfs

in contrast to when the copy of the rootfs of the original container succeeds.
Then it will contain:

lxc.rootfs = /path/to/testvm13d/rootfs

(lxc-devel might be a good place to determine whether this is a bug or not.)

Christian


signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] [BUG] lxc-destroy destroying wrong containers

[Christian Brauner]

On Tue, 10 Nov 2015 14:19:41 +0900, Tomasz Chmielewski :
> lxc-destroy may be destroying wrong containers!
> 
> To reproduce:
> 
> 1) have a container you want to clone - here, testvm012d:
> 
> # lxc-ls -f
> NAMESTATEIPV4
> IPV6  GROUPS  AUTOSTART
> ---
> testvm012d  STOPPED  -
> - -   NO
> 
> 
> 2) clone it - but before the command returns, press ctrl+c (say, you
> realized you used a wrong name and want to interrupt):
> 
> # lxc-clone -B dir testvm012d testvm13d
> [ctrl+c]
> 
> 
> 3) lxc-ls will now show two containers:
> 
> # lxc-ls -f
> NAMESTATEIPV4
> IPV6  GROUPS  AUTOSTART
> ---
> testvm012d  STOPPED  -
> - -   NO
> testvm13d   STOPPED  -
> - -   NO
> 
> 
> 4) we can see that the "interrupted" container was not fully copied - let's
> remove it then with lxc-destroy:
> 
> # du -sh testvm012d testvm13d
> 462Mtestvm012d
> 11M testvm13d
> 
> # lxc-destroy -n testvm13d
> 
> # echo $?
> 0
> 
> 
> 5) as expected, lxc-ls only lists the original container now:
> 
> # lxc-ls -f
> NAMESTATEIPV4
> IPV6  GROUPS  AUTOSTART
> ---
> testvm012d  STOPPED  -
> - -   NO
> 
> 
> 6) unfortunately rootfs for the original container is gone:
> 
> # du -sh testvm012d
> 4.0Ktestvm012d
> 
> # ls testvm012d/
> config
This may not have something to do with lxc-destroy but with how clones work. Can
you only proceed up to step 2) you listed:

> 2) clone it - but before the command returns, press ctrl+c (say, you
> realized you used a wrong name and want to interrupt):
> 
> # lxc-clone -B dir testvm012d testvm13d
> [ctrl+c]

and immediately afterwards check whether the rootfs of the original container
testvm012d is still present?

Christian


signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] [lxc-devel] Networking issue

[Christian Brauner]

Hi, can you please open a bug on https://github.com/lxc/lxc ?
Please specify your operating system version and how to reproduce.

Thanks. :)
Christian

On Wed, Nov 09, 2016 at 01:33:55AM -0500, Saint Michael wrote:
> It was working fine until a week ago.
> I have two sites, it happened on both, so the issue is not on my router or
> my switch, since they are different sites and we did not upgrade anything.
> Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-45-generic x86_64)
> LXC installed from apt-get install lxc1
> iptables off in both hosts and containers. I protect my network at the
> perimeter.
> 
> All my container networking is defined
> 
> lxc.network.type=macvlan
> lxc.network.macvlan.mode=bridge
> lxc.network.link=eth1
> lxc.network.name = eth0
> lxc.network.flags=up
> lxc.network.hwaddr = XX:XX:XX:XX:XX:XX
> lxc.network.ipv4 = 0.0.0.0/24
> 
> Now suppose I have a machine, not a container, in the same broadcast domain
> as the containers, same subnet.
> It cannot ping or ssh into a container, which is accessible from outside my
> network.
> However, from inside the container the packets come and go perfectly, when
> the connection is originated by the container.
> A container can ping that host I mentioned, but the host cannot ping back
> the container.
> It all started a few days ago.
> Also, from the host, this test works
> arping -I eth0 (container IP address)
> it shows that we share the same broadcast domain.
> 
> My guess is that the most recent kernel update in the LXC host, is blocking
> the communication to the containers, but it allows connections from the
> containers or connections from IP addresses not on the same broadcast
> domain.
> Any idea?

> ___
> lxc-devel mailing list
> lxc-de...@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel


On Mon, Nov 14, 2016 at 03:18:54AM -0500, Saint Michael wrote:
> In LXC networking type phys, the network interface correctly disappears
> from the host, but the container never "returns" the device when it gets
> stopped, and it never starts again, unless the host is rebooted, since the
> device is not there.
> I think the device should go back to the host so the container may start
> again.

> ___
> lxc-devel mailing list
> lxc-de...@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel


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

Re: [lxc-users] lxc 2.0.6 breaks lxc-start

[Christian Brauner]

Hm, works for me. I can just start containers fine where the
configuration file is located somewhere else. Can you please
append/copy the containers configuration file here and note any
special tweaks to your setup as well?

On Sat, Dec 31, 2016 at 8:46 PM, Serge E. Hallyn  wrote:
> That looks like
>
> commit 359467743d707d08fda029fa6e957a93bc8dc7ef
> Author: Christian Brauner 
> Date:   Fri Oct 14 15:27:24 2016 +0200
>
> tools: better error reporting for lxc-start
>
> which added a check for "!c->is_defined(c)"
>
> Christian?
>
> -serge
>
> Quoting Detlef Vollmann (d...@vollmann.ch):
>> Hello,
>>
>> I typically start my containers with something like:
>> sudo lxc-start -F -n xenial-dev -f /images/lxc/xenial-dev.conf
>>
>> With 2.0.6, I get the error 'Error: container xenial-dev is not defined'
>> Going back to 2.0.5 solves the problem.
>>
>> Using lxc-create also solves the problem, but I want to avoid this.
>>
>>   Detlef
>>
>> I'm not on the list, so please CC: me on any replies.
>> ___
>> lxc-users mailing list
>> lxc-users@lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] lxc 2.0.6 breaks lxc-start

[Christian Brauner]

Hi,

Thanks for the info. I'm a little confused.

On Thu, Jan 05, 2017 at 01:31:28PM +0100, Detlef Vollmann wrote:
> On 01/01/17 14:14, Christian Brauner wrote:
> > Hm, works for me. I can just start containers fine where the
> > configuration file is located somewhere else. Can you please
> > append/copy the containers configuration file here and note any
> > special tweaks to your setup as well?
> Here's my test case:
> $ sudo lxc-ls
> rlx3-test1 trusty-dev
> # note: no 'test' here

Yes, because the default lxc path should be "/var/lib/lxc" and according to the
config file that you attached the container "test" exists on a different path
"/images/lxc". So this is expected. If you'd pass:

sudo lxc-ls -P /images/lxc

the container "test" should show up.


> $ sudo lxc-start -F -n test -f /images/lxc/test.conf
> Error: container test is not defined

I'd argue that this is also fine because the container does not exist on the
"/var/lib/lxc" path so lxc-start is perfectly right to complain. The fact that
this worked before is actually the real bug.

> $ sudo lxc-create -n test -f /images/lxc/test.conf -t none
> $ sudo lxc-ls
> rlx3-test1 test   trusty-dev
> # no we have 'test'

This is also expected since you now have a dummy container "test" under
"/var/lib/lxc" that lxc-start finds and overloads with the configuration file
you passed.

> $ sudo lxc-start -F -n test -f /images/lxc/test.conf
> INIT: version 2.88 booting
> ...
> 
> I.e. without 'lxc-create', 'lxc-start' doesn't work anymore, though it
> used to work this way.

Yep. As I said the fact that it used to work without passing -P is the real bug
here.

So your solution should simply be to pass the path where the container actually
exists to lxc-start:


sudo lxc-start -F -n test -f /images/lxc/test.conf -P /images/lxc

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

Re: [lxc-users] lxc 2.0.6 breaks lxc-start

[Christian Brauner]

Hi Detlef,

Now we're getting somewhere. :)

On Wed, Jan 11, 2017 at 03:59:21PM +0100, Detlef Vollmann wrote:
> Hi Christian,
> 
> thank you for replying!
> 
> On 01/09/17 17:35, Christian Brauner wrote:
> > Thanks for the info. I'm a little confused.
> Sorry about that.  But maybe it's because we talk about
> different things.

Right, I think we talked past each other.

> 
> > On Thu, Jan 05, 2017 at 01:31:28PM +0100, Detlef Vollmann wrote:
> >> On 01/01/17 14:14, Christian Brauner wrote:
> >>> Hm, works for me. I can just start containers fine where the
> >>> configuration file is located somewhere else. Can you please
> >>> append/copy the containers configuration file here and note any
> >>> special tweaks to your setup as well?
> >> Here's my test case:
> >> $ sudo lxc-ls
> >> rlx3-test1 trusty-dev
> >> # note: no 'test' here
> > 
> > Yes, because the default lxc path should be "/var/lib/lxc" and according to 
> > the
> > config file that you attached the container "test" exists on a different 
> > path
> > "/images/lxc". So this is expected. If you'd pass:
> > 
> > sudo lxc-ls -P /images/lxc
> > 
> > the container "test" should show up.
> No, it doesn't.
> lxc-ls only shows containers that are either active, frozen or created.
> "test" never was created, so it still doesn't show up.

That's the crucial point.

> 
> >> $ sudo lxc-start -F -n test -f /images/lxc/test.conf
> >> Error: container test is not defined
> > 
> > I'd argue that this is also fine because the container does not exist on the
> > "/var/lib/lxc" path so lxc-start is perfectly right to complain. The fact 
> > that
> > this worked before is actually the real bug.
> I don't think so.  lxc-start doesn't complain because it doesn't
> exist in the default path, but because it doesn't (pre-)exist at all!
> 
> > So your solution should simply be to pass the path where the container 
> > actually
> > exists to lxc-start:
> > 
> > 
> > sudo lxc-start -F -n test -f /images/lxc/test.conf -P /images/lxc
> It still doesn't work ("Error: container test is not defined").
> 
> I try to lxc-start a container that was never lxc-create'd.
> From the man page "lxc":
>VOLATILE CONTAINER
>It is not mandatory to create a container object before  to
> start  it.
>The  container  can  be  directly  started with a configuration
> file as
>parameter.

Right, I didn't have this in the back of my mind. Let me look for a fix.

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

Re: [lxc-users] lxc 2.0.6 breaks lxc-start

[Christian Brauner]

Hi Detlef,

I sent a branch against lxc (https://github.com/lxc/lxc/pull/1381) which removes
the c->is_defined(c) check.

Thanks!
Christian

On Wed, Jan 11, 2017 at 04:10:53PM +0100, Christian Brauner wrote:
> Hi Detlef,
> 
> Now we're getting somewhere. :)
> 
> On Wed, Jan 11, 2017 at 03:59:21PM +0100, Detlef Vollmann wrote:
> > Hi Christian,
> > 
> > thank you for replying!
> > 
> > On 01/09/17 17:35, Christian Brauner wrote:
> > > Thanks for the info. I'm a little confused.
> > Sorry about that.  But maybe it's because we talk about
> > different things.
> 
> Right, I think we talked past each other.
> 
> > 
> > > On Thu, Jan 05, 2017 at 01:31:28PM +0100, Detlef Vollmann wrote:
> > >> On 01/01/17 14:14, Christian Brauner wrote:
> > >>> Hm, works for me. I can just start containers fine where the
> > >>> configuration file is located somewhere else. Can you please
> > >>> append/copy the containers configuration file here and note any
> > >>> special tweaks to your setup as well?
> > >> Here's my test case:
> > >> $ sudo lxc-ls
> > >> rlx3-test1 trusty-dev
> > >> # note: no 'test' here
> > > 
> > > Yes, because the default lxc path should be "/var/lib/lxc" and according 
> > > to the
> > > config file that you attached the container "test" exists on a different 
> > > path
> > > "/images/lxc". So this is expected. If you'd pass:
> > > 
> > > sudo lxc-ls -P /images/lxc
> > > 
> > > the container "test" should show up.
> > No, it doesn't.
> > lxc-ls only shows containers that are either active, frozen or created.
> > "test" never was created, so it still doesn't show up.
> 
> That's the crucial point.
> 
> > 
> > >> $ sudo lxc-start -F -n test -f /images/lxc/test.conf
> > >> Error: container test is not defined
> > > 
> > > I'd argue that this is also fine because the container does not exist on 
> > > the
> > > "/var/lib/lxc" path so lxc-start is perfectly right to complain. The fact 
> > > that
> > > this worked before is actually the real bug.
> > I don't think so.  lxc-start doesn't complain because it doesn't
> > exist in the default path, but because it doesn't (pre-)exist at all!
> > 
> > > So your solution should simply be to pass the path where the container 
> > > actually
> > > exists to lxc-start:
> > > 
> > > 
> > > sudo lxc-start -F -n test -f /images/lxc/test.conf -P /images/lxc
> > It still doesn't work ("Error: container test is not defined").
> > 
> > I try to lxc-start a container that was never lxc-create'd.
> > From the man page "lxc":
> >VOLATILE CONTAINER
> >It is not mandatory to create a container object before  to
> > start  it.
> >The  container  can  be  directly  started with a configuration
> > file as
> >parameter.
> 
> Right, I didn't have this in the back of my mind. Let me look for a fix.
> 
> Christian
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] [pepani...@gmail.com: Managing tarballs in lxd]

[Christian Brauner]

- Forwarded message from Javier López Sánchez  -

Date: Mon, 24 Apr 2017 14:04:34 +0200
From: Javier López Sánchez 
To: christian.brau...@ubuntu.com
Subject: Managing tarballs in lxd

Hello Christian, I don't know where to publish this. To help anybody who
need, this is how I make backups and restore my containers on lxd. (Sorry
my horrid English).

Backup

cd /var/lib/lxd/storage-pools/lxd/containers
lxc stop 
zfs mount lxd/containers/
tar --create --verbose --gzip  --file
/.tgz
zfs umount lxd/containers/
lxc start 

Restore

After crash, assuming the containers does not exist

cd 
tar --extract --verbose --file=//.tgz
zfs create lxd/containers/ -o
mountpoint=/var/lib/lxd/storage-pools/lxd/containers/
ln -s /var/lib/lxd/storage-pools/lxd/containers/
/var/lib/lxd/containers/
mv 
/var/lib/lxd/storage-pools>lxd/containers/
lxd import 
lxc start 

If version of LXD<2.13 before "lxd import":
mkdir /var/lib/lxd/storage-pools/lxd/snapshots
mkdir /var/lib/lxd/storage-pools/lxd/snapshots/

I hope it helps anyone who needs it.

Thanks and best regards

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

Re: [lxc-users] Adding a second disk to a container

[Christian Brauner]

On Wed, Jul 12, 2017 at 04:25:54PM -0400, Stéphane Graber wrote:
> On Wed, Jul 12, 2017 at 01:44:13PM -0600, Joshua Schaeffer wrote:
> > I'm wondering what the best/recommended approach is to adding a second disk 
> > to a container. I'm using LXD 2.15 on Ubuntu 16.04. As an example I have a 
> > container where I've limited the disk size to 20GB:
> > 
> > lxduser@blllxd01:~$ lxc config show bllcloudctl01 | grep -A 4 root
> >   root:
> > path: /
> > pool: int_lxd
> > size: 20GB
> > type: disk
> > 
> > This works great, but say I want the container to have another disk device 
> > that is mounted elsewhere like /mnt/disk1. I've tried adding that in my 
> > config but I alway get an error about needing the source. Since I'm using 
> > ZFS I don't have an actual block device to pass to the source. I then 
> > played around with storage volumes, which appears to work, but I always get 
> > an error when editing the volume:
> > 
> > lxduser@blllxd01:~$ lxc storage volume create int_lxd vol1
> > Storage volume cinder created
> > 
> > lxduser@blllxd01:~$ lxc storage volume set int_lxd vol1 size=240GB
> > error: ETag doesn't match: 
> > 834842d9406bd41f2f23c097e496434c3c263a022ef3fb1aaf214b13e4395771 vs 
> > b37ae1157f2a46dc1b24b2b561aefccc168ba822d5057330e94ca10ba47ccfb6
> 
> Sorry about that, looks like we're missing a test for "lxc storage
> volume set", I fixed the issue and added a test:
> 
> https://github.com/lxc/lxd/pull/3541
> 
> > If I create the storage volume with the size parameter is works, but 
> > doesn't set the right size:
> > 
> > lxduser@blllxd01:~$ lxc storage volume delete int_lxd vol1
> > Storage volume cinder deleted
> > 
> > lxduser@blllxd01:~$ lxc storage volume create int_lxd vol1 size=240GB
> > Storage volume cinder created
> > 
> > lxduser@blllxd01:~$ lxc storage volume show int_lxd vol1
> > config:
> >   *size: 10GB*
> > description: ""
> > name: vol1
> > type: custom
> > used_by: []
> 
> Hmm, so I'm not sure what's going on here. For container type volumes,

It was simple failure in the logic. If users passed a "size" property we parsed
and checked it but accidently set "size = 10GB" which obviously should've been
an else branch.

> we tie their size to the disk entry. But for custom volumes, we should
> very much be using the voluem size property for this since they can be
> shared with multiple containers.
> 
> So I would expect to both have the property applied at creation time
> (which it's not right now) and to allow the user to set the size
> afterwards so long as the backend permits it.

I agree. I'm looking into this right now (Also to make sure that I've not
already implemented this logic and just forgot.)

> 
> Christian, can you take care of this?

Do you need to ask? ;)

> 
> > I really just learned about storage volumes so I'm not even sure if I'm 
> > using them correctly or in the correct context here. Also, I get that ETag 
> > error whenever I edit the volume, even if I didn't make changes:
> > 
> > lxduser@blllxd01:~$ lxc storage volume delete int_lxd vol1
> > Storage volume cinder deleted
> > 
> > lxduser@blllxd01:~$ lxc storage volume create int_lxd vol1
> > Storage volume vol1 created
> > 
> > lxduser@blllxd01:~$ lxc storage volume edit int_lxd vol1
> > /[I immediately exit the editor without making any changes]/
> > Config parsing error: ETag doesn't match: 
> > 446844b3e6b6bc70d7a101b5b281e4cc8fb568cfcd66424f32b2027c8215032a vs 
> > 9e27a7a4de3badc96a0046c111094164619f7cfc6351534c7b7236769c85ace1
> > Press enter to open the editor again
> > 
> > I just want the container to look like it has two disks, one mounted on / 
> > and the other mounted under /mnt.
> > 
> > Thanks,
> > Joshua Schaeffer
> > ___
> > lxc-users mailing list
> > lxc-users@lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> 
> -- 
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com




signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Adding a second disk to a container

[Christian Brauner]

On Thu, Jul 13, 2017 at 12:27:52PM +0200, Christian Brauner wrote:
> On Wed, Jul 12, 2017 at 04:25:54PM -0400, Stéphane Graber wrote:
> > On Wed, Jul 12, 2017 at 01:44:13PM -0600, Joshua Schaeffer wrote:
> > > I'm wondering what the best/recommended approach is to adding a second 
> > > disk to a container. I'm using LXD 2.15 on Ubuntu 16.04. As an example I 
> > > have a container where I've limited the disk size to 20GB:
> > > 
> > > lxduser@blllxd01:~$ lxc config show bllcloudctl01 | grep -A 4 root
> > >   root:
> > > path: /
> > > pool: int_lxd
> > > size: 20GB
> > > type: disk
> > > 
> > > This works great, but say I want the container to have another disk 
> > > device that is mounted elsewhere like /mnt/disk1. I've tried adding that 
> > > in my config but I alway get an error about needing the source. Since I'm 
> > > using ZFS I don't have an actual block device to pass to the source. I 
> > > then played around with storage volumes, which appears to work, but I 
> > > always get an error when editing the volume:
> > > 
> > > lxduser@blllxd01:~$ lxc storage volume create int_lxd vol1
> > > Storage volume cinder created
> > > 
> > > lxduser@blllxd01:~$ lxc storage volume set int_lxd vol1 size=240GB
> > > error: ETag doesn't match: 
> > > 834842d9406bd41f2f23c097e496434c3c263a022ef3fb1aaf214b13e4395771 vs 
> > > b37ae1157f2a46dc1b24b2b561aefccc168ba822d5057330e94ca10ba47ccfb6
> > 
> > Sorry about that, looks like we're missing a test for "lxc storage
> > volume set", I fixed the issue and added a test:
> > 
> > https://github.com/lxc/lxd/pull/3541
> > 
> > > If I create the storage volume with the size parameter is works, but 
> > > doesn't set the right size:
> > > 
> > > lxduser@blllxd01:~$ lxc storage volume delete int_lxd vol1
> > > Storage volume cinder deleted
> > > 
> > > lxduser@blllxd01:~$ lxc storage volume create int_lxd vol1 size=240GB
> > > Storage volume cinder created
> > > 
> > > lxduser@blllxd01:~$ lxc storage volume show int_lxd vol1
> > > config:
> > >   *size: 10GB*
> > > description: ""
> > > name: vol1
> > > type: custom
> > > used_by: []
> > 
> > Hmm, so I'm not sure what's going on here. For container type volumes,
> 
> It was simple failure in the logic. If users passed a "size" property we 
> parsed
> and checked it but accidently set "size = 10GB" which obviously should've been
> an else branch.
> 
> > we tie their size to the disk entry. But for custom volumes, we should
> > very much be using the voluem size property for this since they can be
> > shared with multiple containers.
> > 
> > So I would expect to both have the property applied at creation time
> > (which it's not right now) and to allow the user to set the size
> > afterwards so long as the backend permits it.
> 
> I agree. I'm looking into this right now (Also to make sure that I've not
> already implemented this logic and just forgot.)

Ok, I just sent a branch implemented generic quota support:
https://github.com/lxc/lxd/pull/3545

> 
> > 
> > Christian, can you take care of this?
> 
> Do you need to ask? ;)
> 
> > 
> > > I really just learned about storage volumes so I'm not even sure if I'm 
> > > using them correctly or in the correct context here. Also, I get that 
> > > ETag error whenever I edit the volume, even if I didn't make changes:
> > > 
> > > lxduser@blllxd01:~$ lxc storage volume delete int_lxd vol1
> > > Storage volume cinder deleted
> > > 
> > > lxduser@blllxd01:~$ lxc storage volume create int_lxd vol1
> > > Storage volume vol1 created
> > > 
> > > lxduser@blllxd01:~$ lxc storage volume edit int_lxd vol1
> > > /[I immediately exit the editor without making any changes]/
> > > Config parsing error: ETag doesn't match: 
> > > 446844b3e6b6bc70d7a101b5b281e4cc8fb568cfcd66424f32b2027c8215032a vs 
> > > 9e27a7a4de3badc96a0046c111094164619f7cfc6351534c7b7236769c85ace1
> > > Press enter to open the editor again
> > > 
> > > I just want the container to look like it has two disks, one mounted on / 
> > > and the other mounted under /mnt.
> > > 
> > > Thanks,
> > > Joshua Schaeffer
> > > ___
> > > lxc-users mailing list
> > > lxc-users@lists.linuxcontainers.org
> > > http://lists.linuxcontainers.org/listinfo/lxc-users
> > 
> > -- 
> > Stéphane Graber
> > Ubuntu developer
> > http://www.ubuntu.com
> 
> 




signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] [lxc-devel] Suggestions regarding (ultimately) LXC 2.1.0 lxc-update-configy

[Christian Brauner]

On Wed, Oct 04, 2017 at 06:53:16PM -0500, Serge Hallyn wrote:
> agreed to both, lxc-update-config should delete it, and it should be
> (initially the only) member of a (new) group of keys to ignore, bc

I sent a branch [1] that does:
- removes lxc.kmsg and lxc.pivotdir from config files if deteced
- ingores lxc.kmsg and lxc.pivotdir in configuration files if detected

Let me **stress** that with 3.0 bot configuration items lxc.kmsg and
lxc.pivotdir will finally be killed. They will be removed and any config file
that contains them will not be parseable anymore. lxc.pivotdir has been
deprecated at least since 2014 and a warning in the logs has been printed that
this config key will be removed soon. "soon" for us meant three years later. :)

Christian

[1]: https://github.com/lxc/lxc/pull/1845

> it cannot possibly hurt.  Do you happen to have time to write one
> or both patches?
> 
> thanks,
> -serge
> 
> On Wed, Oct 04, 2017 at 03:35:08PM -0400, Adrian Pepper wrote:
> > Does mentioning lxc.pivotdir really need to be a fatal error?  Currently
> > it seems fatal to the degree that "lxc-ls -f" does not show the
> > container at all, not RUNNING and not STOPPED.
> > 
> > Or, at least, could the lxc-update-config command be modified to
> > effectively delete mentions of lxc.pivotdir?
> > (Comment out or delete it; I see lxc.rootfs.backend gets deleted by
> > lxc-update-config; it might be nice if that also was done as commenting
> > out, instead).
> > It seems that "lxc-update-config" currently just leaves lxc.pivotdir alone.
> > (In the following version).
> > 
> > -rwxr-xr-x 1 root root 3791 Sep 21 14:35 /usr/bin/lxc-update-config
> > (Ubuntu 16.04)
> > 
> > 
> > The messages indicating the need to update the config should be
> > improved to name the config file in question, and mention the
> > lxc-update-config command.
> > 
> > Perhaps...
> > 
> >   < The configuration file contains legacy configuration keys.
> >   < Please update your configuration file!
> >   ---
> >   > /var/lib/lxc/u1204-postfix-1/config contains legacy configuration keys.
> >   > "lxc-update-config" can be used to update most configuration files.
> > 
> > 
> > Oh, and "lxc-update-config" does not accept "--version".
> > 
> > 
> > Adrian Pepper
> > arpep...@uwaterloo.ca
> > 
> > 
> > Actual diagnostics associated with lxc.pivotdir...
> > 
> > lxc-start: u1204-postfix-1: confile.c: parse_line: 1982 Unknown 
> > configuration key "lxc.pivotdir"
> > lxc-start: u1204-postfix-1: parse.c: lxc_file_for_each_line: 58 Failed to 
> > parse config: lxc.pivotdir = lxc_putold
> > 
> > lxc-start: u1204-postfix-1: tools/lxc_start.c: main: 286 Failed to create 
> > lxc_container
> > 
> > 
> > ___
> > lxc-users mailing list
> > lxc-users@lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> ___
> lxc-devel mailing list
> lxc-de...@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] [lxc-devel] Container startup hook arguments

[Christian Brauner]

On Wed, Oct 04, 2017 at 09:35:25AM -0500, Serge Hallyn wrote:
> Quoting Kees Bos (cornelis@gmail.com):
> > I'm not using it, but do expect the extra args:
> > 
> > while [ {{ '${#@}' }} -gt 3 ] ; do
> >    ...
> >    shift
> > done
> > 
> > It might be that some users will need the last extra argument (stage:
> > pre-start|start|post-stop). This is currently not available in the
> > environment.
> > 
> > I can live without these extra arguments, but will have to update my
> > scripts.
> 
> Ok, but this will hurt then.  I certainly was going to keep the
> extra args, but they would be shifted now.  We can pass along an
> environment variable saying something like LXC_SIMPLE_ARGS=1 or
> something, but your unmodified script won't know to look for
> that so will do the wrong thing.  Any ideas?
> 
> This unfortunately basically means that you are in fact a "user",
> and that makes this seem like at best 3.0  material then, unless
> we can find a good solution.
> 
> Maybe a configuration key 'lxc.hooks.version=2' ?

I'm fine with simply keeping the arguments until 3.0 and then removing them. I
really don't want to add configuration keys that conceptually are internal keys
but are nonetheless exposed to users. Fwiw, this is also why I didn't implement
a version key for the 2.1. config file format update. This is just going to bite
us in the long run when we have to deprecate these internal keys. TL;DR, keep
the args for now and kill them in 3.0.

Christian

> 
> Thanks for replying!
> 
> -serge
> ___
> lxc-devel mailing list
> lxc-de...@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] [lxc-devel] Suggestions regarding (ultimately) LXC 2.1.0 lxc-update-config

[Christian Brauner]

On Wed, Oct 04, 2017 at 03:35:08PM -0400, Adrian Pepper wrote:
> Does mentioning lxc.pivotdir really need to be a fatal error?  Currently
> it seems fatal to the degree that "lxc-ls -f" does not show the
> container at all, not RUNNING and not STOPPED.

As I said in my previous mail, we've merged a branch of mine that makes this
non-fatal and ignores and lxc.pivotdir entries.
https://github.com/lxc/lxc/commit/63bab717a81bcd5280442c902df8ac664de71244

> 
> Or, at least, could the lxc-update-config command be modified to
> effectively delete mentions of lxc.pivotdir?

That's also part of said branch.
https://github.com/lxc/lxc/commit/727fd34960b2635015e5e9b5780e0d67cbb08992

So you should be fine with the next point release. :)

Christian

> (Comment out or delete it; I see lxc.rootfs.backend gets deleted by
> lxc-update-config; it might be nice if that also was done as commenting
> out, instead).
> It seems that "lxc-update-config" currently just leaves lxc.pivotdir alone.
> (In the following version).
> 
> -rwxr-xr-x 1 root root 3791 Sep 21 14:35 /usr/bin/lxc-update-config
> (Ubuntu 16.04)
> 
> 
> The messages indicating the need to update the config should be
> improved to name the config file in question, and mention the
> lxc-update-config command.
> 
> Perhaps...
> 
>   < The configuration file contains legacy configuration keys.
>   < Please update your configuration file!
>   ---
>   > /var/lib/lxc/u1204-postfix-1/config contains legacy configuration keys.
>   > "lxc-update-config" can be used to update most configuration files.
> 
> 
> Oh, and "lxc-update-config" does not accept "--version".
> 
> 
> Adrian Pepper
> arpep...@uwaterloo.ca
> 
> 
> Actual diagnostics associated with lxc.pivotdir...
> 
> lxc-start: u1204-postfix-1: confile.c: parse_line: 1982 Unknown configuration 
> key "lxc.pivotdir"
> lxc-start: u1204-postfix-1: parse.c: lxc_file_for_each_line: 58 Failed to 
> parse config: lxc.pivotdir = lxc_putold
> 
> lxc-start: u1204-postfix-1: tools/lxc_start.c: main: 286 Failed to create 
> lxc_container
> 
> 
> ___
> lxc-devel mailing list
> lxc-de...@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] [debian/stretch64] lxc-copy: Snapshot with OverlayFS backingstorage fails with Linux-4.9.y

[Christian Brauner]

On Wed, Oct 25, 2017 at 11:45:52AM +0200, Sedat Dilek wrote:
> [ Please CC me - I am not subscribed to lxc-users and debian-kernel MLs ]
> 
> Hi,
> 
> I am playing with LXC and OverlayFS.
> 
> The Debian-kernel shipped with stretch64 fails when using lxc-copy for
> a snapshot.
> Later I tried the latest Debian-kernel from stretch-backports
> APT-repository [0] and the issue does *not* appear.
> 
> Debian/stretch64 ships LXC v2.0.7.
> 
> root# lxc-copy --version
> 2.0.7
> 
> [ Instructions to reproduce ]
> 
> [ Create LXC-Container ]
> 
> root# lxc-create -n stretch64-ovl -B overlayfs -t download -- -d
> debian -r stretch -a amd64
> 
> [ GOOD: linux-image-4.12.0-0.bpo.2-amd64 (4.12.13-1~bpo9+1) ]
> 
> root# lxc-copy -n stretch64-ovl -N snapshot1 -B overlay -s
> --logfile=lxc-copy-log_kernel-bpo9.txt --logpriority=DEBUG
> 
> [ BAD: linux-image-4.9.0-4-amd64 (4.9.51-1) ]
> 
> root@iniza:~# lxc-copy -n stretch64-ovl -N snapshot2 -B overlay -s
> --logfile=lxc-copy-log_kernel-deb9.txt --logpriority=DEBUG
> 
> I found lxc-issue #1395 [1] where a similiar problem was reported
> 
> Can this be a kernel issue?

Well, if the only different in your tests is the kernel then could be. But there
also have been quite some changes to the liblxc codebase that should improve
general user experience wrt to the overlay storage driver. So you might want to
test e.g. liblxc 2.1. If your environment allows you to do that.

> 
> Miklos and Christian any idea?
> 
> Do you need further informations and/or have instructions on debugging this?
> 
> Thanks for any hints.
> 
> Regards,
> - Sedat -
> 
> P.S.: I have attached the LXC configs of stretch64-ovl & snaptshot1
> and the lxc-copy logfiles.
> 
> [0] https://backports.debian.org/Instructions/
> [1] https://github.com/lxc/lxc/issues/1395

>lxc-copy 20171025093206.756 WARN lxc_confile - 
> confile.c:config_pivotdir:1910 - lxc.pivotdir is ignored.  It will soon 
> become an error.
>lxc-copy 20171025093206.756 WARN lxc_confile - 
> confile.c:config_pivotdir:1910 - lxc.pivotdir is ignored.  It will soon 
> become an error.
>lxc-copy 20171025093206.756 INFO lxcoverlay - 
> bdev/lxcoverlay.c:ovl_mount:436 - Overlayfs: Mounted 
> /var/lib/lxc/stretch64-ovl/rootfs onto /var/lib/lxc/stretch64-ovl/rootfs with 
> options 
> upperdir=/var/lib/lxc/stretch64-ovl/delta0,lowerdir=/var/lib/lxc/stretch64-ovl/rootfs,workdir=/var/lib/lxc/stretch64-ovl/olwork.
>lxc-copy 20171025093206.757 INFO lxcoverlay - 
> bdev/lxcoverlay.c:ovl_mount:436 - Overlayfs: Mounted 
> /var/lib/lxc/stretch64-ovl/rootfs onto /var/lib/lxc/snapshot2/rootfs with 
> options 
> upperdir=/var/lib/lxc/snapshot2/delta0,lowerdir=/var/lib/lxc/stretch64-ovl/rootfs,workdir=/var/lib/lxc/snapshot2/olwork.
>lxc-copy 20171025093207.420 ERRORlxcoverlay - 
> bdev/lxcoverlay.c:ovl_rsync:717 - rsyncing /var/lib/lxc/stretch64-ovl/rootfs 
> to /var/lib/lxc/snapshot2/rootfs
>lxc-copy 20171025093207.421 ERRORlxcoverlay - 
> bdev/lxcoverlay.c:ovl_do_rsync:757 - copying overlayfs delta
>lxc-copy 20171025093207.421 ERRORbdev - bdev/bdev.c:bdev_copy:388 
> - failed getting pathnames for cloned storage: 
> overlayfs:/var/lib/lxc/stretch64-ovl/rootfs:/var/lib/lxc/stretch64-ovl/delta0
>lxc-copy 20171025093207.422 ERRORlxc_container - 
> lxccontainer.c:copy_storage:2867 - Error copying storage.
>lxc-copy 20171025093207.430 INFO lxc_container - 
> lxccontainer.c:container_destroy:2414 - Destroyed directory for snapshot2



>lxc-copy 20171025091007.914 WARN lxc_confile - 
> confile.c:config_pivotdir:1910 - lxc.pivotdir is ignored.  It will soon 
> become an error.
>lxc-copy 20171025091007.914 WARN lxc_confile - 
> confile.c:config_pivotdir:1910 - lxc.pivotdir is ignored.  It will soon 
> become an error.
>lxc-copy 20171025091007.914 INFO lxcoverlay - 
> bdev/lxcoverlay.c:ovl_mount:436 - Overlayfs: Mounted 
> /var/lib/lxc/stretch64-ovl/rootfs onto /var/lib/lxc/stretch64-ovl/rootfs with 
> options 
> upperdir=/var/lib/lxc/stretch64-ovl/delta0,lowerdir=/var/lib/lxc/stretch64-ovl/rootfs,workdir=/var/lib/lxc/stretch64-ovl/olwork.
>lxc-copy 20171025091007.914 INFO lxcoverlay - 
> bdev/lxcoverlay.c:ovl_mount:436 - Overlayfs: Mounted 
> /var/lib/lxc/stretch64-ovl/rootfs onto /var/lib/lxc/snapshot1/rootfs with 
> options 
> upperdir=/var/lib/lxc/snapshot1/delta0,lowerdir=/var/lib/lxc/stretch64-ovl/rootfs,workdir=/var/lib/lxc/snapshot1/olwork.
>lxc-copy 20171025091008.114 INFO lxc_container - 
> lxccontainer.c:copy_file:2641 - Error stat'ing 
> /var/lib/lxc/stretch64-ovl/lxc_rdepends
>lxc-copy 20171025091008.114 INFO lxc_container - 
> lxccontainer.c:copy_rdepends:2800 - Error copying reverse dependencies
>lxc-copy 20171025091008.136 INFO lxcoverlay - 
> bdev/lxcoverlay.c:ovl_mount:436 - Overlayfs: Mounted 
> /var/lib/lxc/stretch64-ovl/rootfs onto /usr/lib/x86_64-linux-gnu/lxc/ro

Re: [lxc-users] Debian and unprivileged LXC not working...

[Christian Brauner]

On Tue, Dec 12, 2017 at 11:00:01PM -0600, Serge Hallyn wrote:
> On Tue, Dec 05, 2017 at 05:20:32PM +0100, Dirk Geschke wrote:
> > Hi Serge,
> > 
> > > > I am a little bit clueless, I have several systems running with
> > > > Debian and unprivileged LXC. But newer systems won't start new
> > > > containers.
> > > > 
> > > > Actually I have a Debian stretch, installed the normal way but
> > > > with lxc-2.0.9 and cgmanager-0.41 installed from sources.
> > > > 
> > > > I can setup cgmanager, can do a cgm movepid and it is no problem
> > > > to download a template. But starting the container does not work,
> > > > it simply hungs at:
> > > > 
> > > >$ lxc-start -n lxc-test -l trace -o wheezy -F
> > > 
> > > I see no bad errors in the log.  When this hangs, can you
> > > from another terminal see whether 'lxc-ls -f' shows it
> > > running, and what 'lxc-attach -n lxc-test' does?
> > 
> > that's the funny part: Nothing. There is not one process from 
> > the subuid range running. It simply hangs before it tries to 
> > start the container at all. And I have no idea, why.
> > But with lxc-2.0.8 it works. 
> > 
> > I just installed and started debian wheezy, upgraded it to jessie
> > and finally to stretch. It works fine.
> > 
> > I now installed lxc-2.0.9 again, tried to start the container again
> > and nothing happens:
> > 
> >$ lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> > 
> > That's all. lxc-ls -f and lxc-attach-n lxc-test hangs, too.
> > 
> > I see also three processes of lxc-start:
> > 
> >$ ps waux |grep lxc-start
> >lxc-test 24478  0.0  0.1  51740  4232 pts/0S+   17:16   0:00
> >lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> >lxc-test 24487  0.0  0.0  51740   504 pts/0S+   17:16   0:00
> >lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> >lxc-test 24492  0.0  0.0  51740   508 pts/0S+   17:16   0:00
> >lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> 
> When you gdb-attach to these (which you have to do as root for two
> of them) you find that you're hung on:
> 
> (gdb) where
> #0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
> #1  0x7f2a94f68b95 in __GI___pthread_mutex_lock 
> (mutex=mutex@entry=0x7f2a95868a60 )
> at ../nptl/pthread_mutex_lock.c:80
> #2  0x7f2a95638c4d in lock_mutex (l=0x7f2a95868a60 ) at 
> cgroups/cgmanager.c:80
> #3  cgm_lock () at cgroups/cgmanager.c:98
> #4  0x7f2a94a722f5 in __libc_fork () at ../sysdeps/nptl/fork.c:96
> #5  0x7f2a95604ee7 in run_command (buf=buf@entry=0x7fff3b5a20e0 "",
> buf_size=buf_size@entry=4096,
> child_fn=child_fn@entry=0x7f2a95606a30 ,
> args=args@entry=0x7fff3b5a40e0) at utils.c:2262
> #6  0x7f2a9560b01e in lxc_map_ids (idmap=idmap@entry=0x55b48a62c1c0, 
> pid=pid@entry=15389)
> at conf.c:2652
> #7  0x7f2a9560f1e5 in userns_exec_1 (conf=conf@entry=0x55b48a625b90,
> fn=fn@entry=0x7f2a95639a20 , 
> data=data@entry=0x7fff3b5a5210,
> fn_name=fn_name@entry=0x7f2a9563fadc "chown_cgroup_wrapper") at 
> conf.c:3822
> #8  0x7f2a9563a1a9 in chown_cgroup (conf=0x55b48a625b90, 
> cgroup_path=)
> at cgroups/cgmanager.c:500
> #9  cgm_chown (hdata=0x55b48a62b1d0, conf=0x55b48a625b90) at 
> cgroups/cgmanager.c:1555
> #10 0x7f2a955fa397 in lxc_spawn (handler=0x55b48a624e50) at start.c:1363
> 
> and
> 
> #0  0x7f2a94f6f1f0 in __read_nocancel () at 
> ../sysdeps/unix/syscall-template.S:84
> #1  0x7f2a95607872 in run_userns_fn (data=0x7fff3b5a51b0) at conf.c:3570
> #2  0x7f2a94aa2aff in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
> 
> So it seems to be hanging on cgm_lock().
> 
> I'm a bit too tired to think it through clearly enough, but I'm thinking
> this might have to do with the introduction of run_command().  It introduces
> an extra fork() between the clone(CLONE_NEWUSER)'d thread and the task which
> actually does the work.  Perhaps that is messing with our lock state?

Right, so as I said, this could be related to pthread_atfork() handlers.
(I suspect that cgmanager is multi-threaded or calls to libnh or dbus
which is, Serge?)
Older liblxc version used system() instead of run_command(). For
system() POSIX leaves it unspecified whether pthread_atfork() handlers
are called but glibc's implementation of system() guarantees that they
are not. But there's no requirement. So this might be why we have been
fine - by chance - all of the time. The obvious solution is to switch
back to system() instead of run_command() but let me think about this
for a second.
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Debian and unprivileged LXC not working...

[Christian Brauner]

On Wed, Dec 13, 2017 at 12:54:04PM +0100, Christian Brauner wrote:
> On Tue, Dec 12, 2017 at 11:00:01PM -0600, Serge Hallyn wrote:
> > On Tue, Dec 05, 2017 at 05:20:32PM +0100, Dirk Geschke wrote:
> > > Hi Serge,
> > > 
> > > > > I am a little bit clueless, I have several systems running with
> > > > > Debian and unprivileged LXC. But newer systems won't start new
> > > > > containers.
> > > > > 
> > > > > Actually I have a Debian stretch, installed the normal way but
> > > > > with lxc-2.0.9 and cgmanager-0.41 installed from sources.
> > > > > 
> > > > > I can setup cgmanager, can do a cgm movepid and it is no problem
> > > > > to download a template. But starting the container does not work,
> > > > > it simply hungs at:
> > > > > 
> > > > >$ lxc-start -n lxc-test -l trace -o wheezy -F
> > > > 
> > > > I see no bad errors in the log.  When this hangs, can you
> > > > from another terminal see whether 'lxc-ls -f' shows it
> > > > running, and what 'lxc-attach -n lxc-test' does?
> > > 
> > > that's the funny part: Nothing. There is not one process from 
> > > the subuid range running. It simply hangs before it tries to 
> > > start the container at all. And I have no idea, why.
> > > But with lxc-2.0.8 it works. 
> > > 
> > > I just installed and started debian wheezy, upgraded it to jessie
> > > and finally to stretch. It works fine.
> > > 
> > > I now installed lxc-2.0.9 again, tried to start the container again
> > > and nothing happens:
> > > 
> > >$ lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> > > 
> > > That's all. lxc-ls -f and lxc-attach-n lxc-test hangs, too.
> > > 
> > > I see also three processes of lxc-start:
> > > 
> > >$ ps waux |grep lxc-start
> > >lxc-test 24478  0.0  0.1  51740  4232 pts/0S+   17:16   0:00
> > >lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> > >lxc-test 24487  0.0  0.0  51740   504 pts/0S+   17:16   0:00
> > >lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> > >lxc-test 24492  0.0  0.0  51740   508 pts/0S+   17:16   0:00
> > >lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> > 
> > When you gdb-attach to these (which you have to do as root for two
> > of them) you find that you're hung on:
> > 
> > (gdb) where
> > #0  __lll_lock_wait () at 
> > ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
> > #1  0x7f2a94f68b95 in __GI___pthread_mutex_lock 
> > (mutex=mutex@entry=0x7f2a95868a60 )
> > at ../nptl/pthread_mutex_lock.c:80
> > #2  0x7f2a95638c4d in lock_mutex (l=0x7f2a95868a60 ) at 
> > cgroups/cgmanager.c:80
> > #3  cgm_lock () at cgroups/cgmanager.c:98
> > #4  0x7f2a94a722f5 in __libc_fork () at ../sysdeps/nptl/fork.c:96
> > #5  0x7f2a95604ee7 in run_command (buf=buf@entry=0x7fff3b5a20e0 "",
> > buf_size=buf_size@entry=4096,
> > child_fn=child_fn@entry=0x7f2a95606a30 ,
> > args=args@entry=0x7fff3b5a40e0) at utils.c:2262
> > #6  0x7f2a9560b01e in lxc_map_ids (idmap=idmap@entry=0x55b48a62c1c0, 
> > pid=pid@entry=15389)
> > at conf.c:2652
> > #7  0x7f2a9560f1e5 in userns_exec_1 (conf=conf@entry=0x55b48a625b90,
> > fn=fn@entry=0x7f2a95639a20 , 
> > data=data@entry=0x7fff3b5a5210,
> > fn_name=fn_name@entry=0x7f2a9563fadc "chown_cgroup_wrapper") at 
> > conf.c:3822
> > #8  0x7f2a9563a1a9 in chown_cgroup (conf=0x55b48a625b90, 
> > cgroup_path=)
> > at cgroups/cgmanager.c:500
> > #9  cgm_chown (hdata=0x55b48a62b1d0, conf=0x55b48a625b90) at 
> > cgroups/cgmanager.c:1555
> > #10 0x7f2a955fa397 in lxc_spawn (handler=0x55b48a624e50) at start.c:1363
> > 
> > and
> > 
> > #0  0x7f2a94f6f1f0 in __read_nocancel () at 
> > ../sysdeps/unix/syscall-template.S:84
> > #1  0x7f2a95607872 in run_userns_fn (data=0x7fff3b5a51b0) at conf.c:3570
> > #2  0x7f2a94aa2aff in clone () at 
> > ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
> > 
> > So it seems to be hanging on cgm_lock().
> > 
> > I'm a bit too tired to think it through clearly enough, but I'm thinking
> > this might have to do with the introduction of run_command().  It introduces
> > an extra fork() between the clone(CLONE_NEWUSER)'d thread and the task whi

Re: [lxc-users] Debian and unprivileged LXC not working...

[Christian Brauner]

On Wed, Dec 13, 2017 at 01:35:01PM +0100, Christian Brauner wrote:
> On Wed, Dec 13, 2017 at 12:54:04PM +0100, Christian Brauner wrote:
> > On Tue, Dec 12, 2017 at 11:00:01PM -0600, Serge Hallyn wrote:
> > > On Tue, Dec 05, 2017 at 05:20:32PM +0100, Dirk Geschke wrote:
> > > > Hi Serge,
> > > > 
> > > > > > I am a little bit clueless, I have several systems running with
> > > > > > Debian and unprivileged LXC. But newer systems won't start new
> > > > > > containers.
> > > > > > 
> > > > > > Actually I have a Debian stretch, installed the normal way but
> > > > > > with lxc-2.0.9 and cgmanager-0.41 installed from sources.
> > > > > > 
> > > > > > I can setup cgmanager, can do a cgm movepid and it is no problem
> > > > > > to download a template. But starting the container does not work,
> > > > > > it simply hungs at:
> > > > > > 
> > > > > >$ lxc-start -n lxc-test -l trace -o wheezy -F
> > > > > 
> > > > > I see no bad errors in the log.  When this hangs, can you
> > > > > from another terminal see whether 'lxc-ls -f' shows it
> > > > > running, and what 'lxc-attach -n lxc-test' does?
> > > > 
> > > > that's the funny part: Nothing. There is not one process from 
> > > > the subuid range running. It simply hangs before it tries to 
> > > > start the container at all. And I have no idea, why.
> > > > But with lxc-2.0.8 it works. 
> > > > 
> > > > I just installed and started debian wheezy, upgraded it to jessie
> > > > and finally to stretch. It works fine.
> > > > 
> > > > I now installed lxc-2.0.9 again, tried to start the container again
> > > > and nothing happens:
> > > > 
> > > >$ lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> > > > 
> > > > That's all. lxc-ls -f and lxc-attach-n lxc-test hangs, too.
> > > > 
> > > > I see also three processes of lxc-start:
> > > > 
> > > >$ ps waux |grep lxc-start
> > > >lxc-test 24478  0.0  0.1  51740  4232 pts/0S+   17:16   0:00
> > > >lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> > > >lxc-test 24487  0.0  0.0  51740   504 pts/0S+   17:16   0:00
> > > >lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> > > >lxc-test 24492  0.0  0.0  51740   508 pts/0S+   17:16   0:00
> > > >lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> > > 
> > > When you gdb-attach to these (which you have to do as root for two
> > > of them) you find that you're hung on:
> > > 
> > > (gdb) where
> > > #0  __lll_lock_wait () at 
> > > ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
> > > #1  0x7f2a94f68b95 in __GI___pthread_mutex_lock 
> > > (mutex=mutex@entry=0x7f2a95868a60 )
> > > at ../nptl/pthread_mutex_lock.c:80
> > > #2  0x7f2a95638c4d in lock_mutex (l=0x7f2a95868a60 ) at 
> > > cgroups/cgmanager.c:80
> > > #3  cgm_lock () at cgroups/cgmanager.c:98
> > > #4  0x7f2a94a722f5 in __libc_fork () at ../sysdeps/nptl/fork.c:96
> > > #5  0x7f2a95604ee7 in run_command (buf=buf@entry=0x7fff3b5a20e0 "",
> > > buf_size=buf_size@entry=4096,
> > > child_fn=child_fn@entry=0x7f2a95606a30 ,
> > > args=args@entry=0x7fff3b5a40e0) at utils.c:2262
> > > #6  0x7f2a9560b01e in lxc_map_ids (idmap=idmap@entry=0x55b48a62c1c0, 
> > > pid=pid@entry=15389)
> > > at conf.c:2652
> > > #7  0x7f2a9560f1e5 in userns_exec_1 (conf=conf@entry=0x55b48a625b90,
> > > fn=fn@entry=0x7f2a95639a20 , 
> > > data=data@entry=0x7fff3b5a5210,
> > > fn_name=fn_name@entry=0x7f2a9563fadc "chown_cgroup_wrapper") at 
> > > conf.c:3822
> > > #8  0x7f2a9563a1a9 in chown_cgroup (conf=0x55b48a625b90, 
> > > cgroup_path=)
> > > at cgroups/cgmanager.c:500
> > > #9  cgm_chown (hdata=0x55b48a62b1d0, conf=0x55b48a625b90) at 
> > > cgroups/cgmanager.c:1555
> > > #10 0x7f2a955fa397 in lxc_spawn (handler=0x55b48a624e50) at 
> > > start.c:1363
> > > 
> > > and
> > > 
> > > #0  0x7f2a94f6f1f0 in __read_nocancel () at 
> > > ../sysdeps/unix/syscall-template.S:84
> > > #1  0x7f2a9560

Re: [lxc-users] Debian and unprivileged LXC not working...

[Christian Brauner]

On Wed, Dec 13, 2017 at 09:22:11AM -0600, Serge Hallyn wrote:
> Quoting Christian Brauner (christian.brau...@mailbox.org):
> > On Tue, Dec 12, 2017 at 11:00:01PM -0600, Serge Hallyn wrote:
> > > On Tue, Dec 05, 2017 at 05:20:32PM +0100, Dirk Geschke wrote:
> > > > Hi Serge,
> > > > 
> > > > > > I am a little bit clueless, I have several systems running with
> > > > > > Debian and unprivileged LXC. But newer systems won't start new
> > > > > > containers.
> > > > > > 
> > > > > > Actually I have a Debian stretch, installed the normal way but
> > > > > > with lxc-2.0.9 and cgmanager-0.41 installed from sources.
> > > > > > 
> > > > > > I can setup cgmanager, can do a cgm movepid and it is no problem
> > > > > > to download a template. But starting the container does not work,
> > > > > > it simply hungs at:
> > > > > > 
> > > > > >$ lxc-start -n lxc-test -l trace -o wheezy -F
> > > > > 
> > > > > I see no bad errors in the log.  When this hangs, can you
> > > > > from another terminal see whether 'lxc-ls -f' shows it
> > > > > running, and what 'lxc-attach -n lxc-test' does?
> > > > 
> > > > that's the funny part: Nothing. There is not one process from 
> > > > the subuid range running. It simply hangs before it tries to 
> > > > start the container at all. And I have no idea, why.
> > > > But with lxc-2.0.8 it works. 
> > > > 
> > > > I just installed and started debian wheezy, upgraded it to jessie
> > > > and finally to stretch. It works fine.
> > > > 
> > > > I now installed lxc-2.0.9 again, tried to start the container again
> > > > and nothing happens:
> > > > 
> > > >$ lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> > > > 
> > > > That's all. lxc-ls -f and lxc-attach-n lxc-test hangs, too.
> > > > 
> > > > I see also three processes of lxc-start:
> > > > 
> > > >$ ps waux |grep lxc-start
> > > >lxc-test 24478  0.0  0.1  51740  4232 pts/0S+   17:16   0:00
> > > >lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> > > >lxc-test 24487  0.0  0.0  51740   504 pts/0S+   17:16   0:00
> > > >lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> > > >lxc-test 24492  0.0  0.0  51740   508 pts/0S+   17:16   0:00
> > > >lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> > > 
> > > When you gdb-attach to these (which you have to do as root for two
> > > of them) you find that you're hung on:
> > > 
> > > (gdb) where
> > > #0  __lll_lock_wait () at 
> > > ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
> > > #1  0x7f2a94f68b95 in __GI___pthread_mutex_lock 
> > > (mutex=mutex@entry=0x7f2a95868a60 )
> > > at ../nptl/pthread_mutex_lock.c:80
> > > #2  0x7f2a95638c4d in lock_mutex (l=0x7f2a95868a60 ) at 
> > > cgroups/cgmanager.c:80
> > > #3  cgm_lock () at cgroups/cgmanager.c:98
> > > #4  0x7f2a94a722f5 in __libc_fork () at ../sysdeps/nptl/fork.c:96
> > > #5  0x7f2a95604ee7 in run_command (buf=buf@entry=0x7fff3b5a20e0 "",
> > > buf_size=buf_size@entry=4096,
> > > child_fn=child_fn@entry=0x7f2a95606a30 ,
> > > args=args@entry=0x7fff3b5a40e0) at utils.c:2262
> > > #6  0x7f2a9560b01e in lxc_map_ids (idmap=idmap@entry=0x55b48a62c1c0, 
> > > pid=pid@entry=15389)
> > > at conf.c:2652
> > > #7  0x7f2a9560f1e5 in userns_exec_1 (conf=conf@entry=0x55b48a625b90,
> > > fn=fn@entry=0x7f2a95639a20 , 
> > > data=data@entry=0x7fff3b5a5210,
> > > fn_name=fn_name@entry=0x7f2a9563fadc "chown_cgroup_wrapper") at 
> > > conf.c:3822
> > > #8  0x7f2a9563a1a9 in chown_cgroup (conf=0x55b48a625b90, 
> > > cgroup_path=)
> > > at cgroups/cgmanager.c:500
> > > #9  cgm_chown (hdata=0x55b48a62b1d0, conf=0x55b48a625b90) at 
> > > cgroups/cgmanager.c:1555
> > > #10 0x7f2a955fa397 in lxc_spawn (handler=0x55b48a624e50) at 
> > > start.c:1363
> > > 
> > > and
> > > 
> > > #0  0x7f2a94f6f1f0 in __read_nocancel () at 
> > > ../sysdeps/unix/syscall-template.S:84
> > > #1  0x7f2a95607872 in run_user

Re: [lxc-users] Debian and unprivileged LXC not working...

[Christian Brauner]

> You can see whether lxc-2.1.1 fixes it for you, or

It won't.

> you can run wigh cgfsng instead of cgmanager, as your
> problem is just with the cgm_lock.
> 
> > Can I help in any way?

I've appened a patch to this mail which I think solves your problem. If
you could apply it and test that would be amazing since I don't have
cgmanager here.

>
> If you were feeling bored and/or industrious, you could
> grab the lxc git tree and git bisect to the commit that
> breaks it :)  I'm 99% sure it'll point to the commit that
> introduces run_command(), but actually it's possible that
> I am actually wrong about that, so confirmation would be
> useful.

Yes, run_command() is the cause. It is caused by pthread_atfork()
handlers.

> 
> Or instead of a bisect, you could just revert ea3a694fe
> in the 2.0.9 tree and see if that fixes it.  Though it
> may not revert cleanly.
> 
> But, you've been enormously helpful in finding this.  While
> it currently only affects a configuration which isn't much
> used any more, if we're right about the cause then there is
> a more general underlying problem which can strike elsewhere
> too.  So thanks!

Essentially, run_command() is called in contexts where threads
explicitly hold a lock while fork()ing. Currently, this just affects the
legacy cgmanager cgroup driver.  Here's what's happening when we use
fork():

1. cgm_chown() calls cgm_dbus_connect()
2. cgm_dbus_connect() calls cgm_lock():
   Now the thread holds an explicit lock on the mutex
3. cgm_chown() calls chown_cgroup()
4. chown_cgroup() calls userns_exec_1()
5. userns_exec_1() forks with an explicit lock on the mutex being held
6. pthread_atfork() handlers get run including the prepare() handler:

#ifdef HAVE_PTHREAD_ATFORK __attribute__((constructor))
static void process_lock_setup_atfork(void)
{
pthread_atfork(cgm_lock, cgm_unlock, cgm_unlock);
}
#endif

   thus trying to acquire the mutex that is being explicitly held in the
   parent. If we were using recursive locks then the parent would now
   hold two locks but since I don't see us using them I guess we're
   simply getting undefined behavior.

There are multiple ways to solve this problem. They are all not very nice. One
solution is to use interposition wrapper for pthread_atfork() but that is
rather tricky since we need to have wrappers for the pthread_atfork() callbacks
and need to identify our caller so that we can make a decision whether we
should execute the callback or not. If this were a generic problem I'd say we
go for this solution but as this only affects the legacy cgmanager driver we
don't really care and I'd much rather enforce that any future code does not
take an explicit lock during a fork(). That sounds like a bad idea in the first
place. So simply switch from using fork() to clone() which does not run
pthread_atfork() handlers. If push comes to shove we might just go for doing
the clone() syscall directly via syscall(SYS_clone, ...).

Serge, please take a look at https://github.com/lxc/lxc/pull/2034 and
see whether that is acceptable to you. :)

Christian
>From 3b52c88ce5ba62013dd079e28003703028a9965f Mon Sep 17 00:00:00 2001
From: Christian Brauner 
Date: Thu, 14 Dec 2017 02:37:04 +0100
Subject: [PATCH] utils: use clone() in run_command()

run_command() is called in contexts where threads explicitly hold a lock while
fork()ing. Currently, this just affects the legacy cgmanager cgroup driver.
Here's what's happening when we use fork():

1. cgm_chown() calls cgm_dbus_connect()
2. cgm_dbus_connect() calls cgm_lock():
   Now the thread holds an explicit lock on the mutex
3. cgm_chown() calls chown_cgroup()
4. chown_cgroup() calls userns_exec_1()
5. userns_exec_1() forks with an explicit lock on the mutex being held
6. pthread_atfork() handlers get run including the prepare() handler:

#ifdef HAVE_PTHREAD_ATFORK __attribute__((constructor))
static void process_lock_setup_atfork(void)
{
pthread_atfork(cgm_lock, cgm_unlock, cgm_unlock);
}
#endif

   thus trying to acquire the mutex that is being explicitly held in the
   parent. If we were using recursive locks then the parent would now
   hold two locks but since I don't see us using them I guess we're
   simply getting undefined behavior.

There are multiple ways to solve this problem. They are all not very nice. One
solution is to use interposition wrapper for pthread_atfork() but that is
rather tricky since we need to have wrappers for the pthread_atfork() callbacks
and need to identify our caller so that we can make a decision whether we
should execute the callback or not. If this were a generic problem I'd say we
go for this solution but as this only affects the legacy cgmanager driver we
don't really 

Re: [lxc-users] Debian and unprivileged LXC not working...

[Christian Brauner]

On Tue, Dec 12, 2017 at 11:00:01PM -0600, Serge Hallyn wrote:
> On Tue, Dec 05, 2017 at 05:20:32PM +0100, Dirk Geschke wrote:
> > Hi Serge,
> > 
> > > > I am a little bit clueless, I have several systems running with
> > > > Debian and unprivileged LXC. But newer systems won't start new
> > > > containers.
> > > > 
> > > > Actually I have a Debian stretch, installed the normal way but
> > > > with lxc-2.0.9 and cgmanager-0.41 installed from sources.
> > > > 
> > > > I can setup cgmanager, can do a cgm movepid and it is no problem
> > > > to download a template. But starting the container does not work,
> > > > it simply hungs at:
> > > > 
> > > >$ lxc-start -n lxc-test -l trace -o wheezy -F
> > > 
> > > I see no bad errors in the log.  When this hangs, can you
> > > from another terminal see whether 'lxc-ls -f' shows it
> > > running, and what 'lxc-attach -n lxc-test' does?
> > 
> > that's the funny part: Nothing. There is not one process from 
> > the subuid range running. It simply hangs before it tries to 
> > start the container at all. And I have no idea, why.
> > But with lxc-2.0.8 it works. 
> > 
> > I just installed and started debian wheezy, upgraded it to jessie
> > and finally to stretch. It works fine.
> > 
> > I now installed lxc-2.0.9 again, tried to start the container again
> > and nothing happens:
> > 
> >$ lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> > 
> > That's all. lxc-ls -f and lxc-attach-n lxc-test hangs, too.
> > 
> > I see also three processes of lxc-start:
> > 
> >$ ps waux |grep lxc-start
> >lxc-test 24478  0.0  0.1  51740  4232 pts/0S+   17:16   0:00
> >lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> >lxc-test 24487  0.0  0.0  51740   504 pts/0S+   17:16   0:00
> >lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> >lxc-test 24492  0.0  0.0  51740   508 pts/0S+   17:16   0:00
> >lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F
> 
> When you gdb-attach to these (which you have to do as root for two
> of them) you find that you're hung on:
> 
> (gdb) where
> #0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
> #1  0x7f2a94f68b95 in __GI___pthread_mutex_lock 
> (mutex=mutex@entry=0x7f2a95868a60 )
> at ../nptl/pthread_mutex_lock.c:80
> #2  0x7f2a95638c4d in lock_mutex (l=0x7f2a95868a60 ) at 
> cgroups/cgmanager.c:80
> #3  cgm_lock () at cgroups/cgmanager.c:98
> #4  0x7f2a94a722f5 in __libc_fork () at ../sysdeps/nptl/fork.c:96
> #5  0x7f2a95604ee7 in run_command (buf=buf@entry=0x7fff3b5a20e0 "",
> buf_size=buf_size@entry=4096,
> child_fn=child_fn@entry=0x7f2a95606a30 ,
> args=args@entry=0x7fff3b5a40e0) at utils.c:2262
> #6  0x7f2a9560b01e in lxc_map_ids (idmap=idmap@entry=0x55b48a62c1c0, 
> pid=pid@entry=15389)
> at conf.c:2652
> #7  0x7f2a9560f1e5 in userns_exec_1 (conf=conf@entry=0x55b48a625b90,
> fn=fn@entry=0x7f2a95639a20 , 
> data=data@entry=0x7fff3b5a5210,
> fn_name=fn_name@entry=0x7f2a9563fadc "chown_cgroup_wrapper") at 
> conf.c:3822
> #8  0x7f2a9563a1a9 in chown_cgroup (conf=0x55b48a625b90, 
> cgroup_path=)
> at cgroups/cgmanager.c:500
> #9  cgm_chown (hdata=0x55b48a62b1d0, conf=0x55b48a625b90) at 
> cgroups/cgmanager.c:1555
> #10 0x7f2a955fa397 in lxc_spawn (handler=0x55b48a624e50) at start.c:1363
> 
> and
> 
> #0  0x7f2a94f6f1f0 in __read_nocancel () at 
> ../sysdeps/unix/syscall-template.S:84
> #1  0x7f2a95607872 in run_userns_fn (data=0x7fff3b5a51b0) at conf.c:3570
> #2  0x7f2a94aa2aff in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
> 
> So it seems to be hanging on cgm_lock().
> 
> I'm a bit too tired to think it through clearly enough, but I'm thinking
> this might have to do with the introduction of run_command().  It introduces
> an extra fork() between the clone(CLONE_NEWUSER)'d thread and the task which
> actually does the work.  Perhaps that is messing with our lock state?

I mean, one *could* attribute it to the pthread atfork handler... Let me
take a look at run_command().
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Using lxc.namespace.net in unprivileged containers

[Christian Brauner]

> Date: Fri, 2 Feb 2018 01:52:09 +0200
> From: Eytan Heidingsfeld 
> To: lxc-users@lists.linuxcontainers.org
> Subject: [lxc-users] Using lxc.namespace.net in unprivileged containers
> 
> Hi,
> I'm trying to use the new lxc.namespace.net config in an unprivileged
> container (using idmapping)
> The container fails to start, running the log at trace I see:
> 
> lxc_network - network.c:lxc_setup_network_in_child_namespaces:3031 -
> network has been setup
> lxc_network - network.c:lxc_network_send_name_and_ifindex_to_parent:3112 -
> Sent network device names and ifindeces to parent
> 
> But then right after that:
> 
> ERRORlxc_utils - utils.c:safe_mount:1659 - Operation not permitted -
> Failed to mount sysfs onto /usr/lib/x86_64-linux-gnu/lxc/sys

You need to also inherit the owning user namespace of the network
namespace in this scenario otherwise the kernel won't let you mount
sysfs. Another option is to specify a lxc.mount.entry to bind-mount
sysfs from the host.
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] lxc: issue cleanups

[Christian Brauner]

Hey everyone,

We are currently in the process of cleaning up the lxc issue list on
Github ( https://github.com/lxc/lxc/issues ). This may cause some issues
to be closed that you still consider relevant. Please do not take this
as a slight. We're mainly doing this because a bunch of those issues have
been around for such a long time that the codebase simply has changed so
substantially that figuring out what exactly caused this issue is simply
not practical or even doable anymore.
However, if you feel that an issue that has been closed should
definitely still be fixed or tracked feel free to reopen it. But please
ensure that you test it against one of the latest supported versions of LXC.

I'd also like to kindly request that anyone who still has issues open
against lxc to take a look whether they can be closed or not. This would
obviously help us a lot in keeping things clean and lean.

Thanks for your support and understanding everyone!
Christian


signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] LXC master: Legacy Config Items Have Been Removed

[Christian Brauner]

Hey everyone,

We've been making good progress on the way to 3.0 for all affected
projects under the LXC umbrella. One of the more invasive steps we have
undertaken yesterday is to remove the support for all legacy
configuration items from the LXC master branch. We have announced this
back when LXC 2.1 was
released: 
https://linuxcontainers.org/lxc/news/#lxc-21-release-announcement-5th-of-september-2017
Below, you will find a list of configuration items that have been
removed and their equivalent new configuration items. Note that LXC
ships an upgrade script

lxc-update-config -h|--help [-c|--config]

which can be used to update a legacy config to a new config. The script
will make a backup of the old config with the extension *.backup in the
same directory where the old config resides. In case of a failed update
the legacy config can easily be restored.

Christian


Legacy Key (removed from LXC master) | New Key   |
-|---|
lxc.aa_profile   | lxc.apparmor.profile  |
lxc.aa_allow_incomplete  | lxc.apparmor.allow_incomplete |
lxc.console  | lxc.console.path  |
lxc.devttydir| lxc.tty.dir   |
lxc.haltsignal   | lxc.signal.halt   |
lxc.id_map   | lxc.idmap |
lxc.init_cmd | lxc.init.cmd  |
lxc.init_gid | lxc.init.gid  |
lxc.init_uid | lxc.init.uid  |
lxc.limit| lxc.prlimit   |
lxc.logfile  | lxc.log.file  |
lxc.loglevel | lxc.log.level |
lxc.mount| lxc.mount.fstab   |
lxc.network  | lxc.net   |
lxc.network. | lxc.net.[i].  |
lxc.network.flags| lxc.net.[i].flags |
lxc.network.hwaddr   | lxc.net.[i].hwaddr|
lxc.network.ipv4 | lxc.net.[i].ipv4.address  |
lxc.network.ipv4.gateway | lxc.net.[i].ipv4.gateway  |
lxc.network.ipv6 | lxc.net.[i].ipv6.address  |
lxc.network.ipv6.gateway | lxc.net.[i].ipv6.gateway  |
lxc.network.link | lxc.net.[i].link  |
lxc.network.macvlan.mode | lxc.net.[i].macvlan.mode  |
lxc.network.mtu  | lxc.net.[i].mtu   |
lxc.network.name | lxc.net.[i].name  |
lxc.network.script.down  | lxc.net.[i].script.down   |
lxc.network.script.up| lxc.net.[i].script.up |
lxc.network.type | lxc.net.[i].type  |
lxc.network.veth.pair| lxc.net.[i].veth.pair |
lxc.network.vlan.id  | lxc.net.[i].vlan.id   |
lxc.pts  | lxc.pty.max   |
lxc.rebootsignal | lxc.signal.reboot |
lxc.rootfs   | lxc.rootfs.path   |
lxc.se_context   | lxc.selinux.context   |
lxc.seccomp  | lxc.seccomp.profile   |
lxc.stopsignal   | lxc.signal.stop   |
lxc.syslog   | lxc.log.syslog|
lxc.tty  | lxc.tty.max   |
lxc.utsname  | lxc.uts.name  |


signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] LXC master: Legacy Config Items Have Been Removed

[Christian Brauner]

> Date: Tue, 13 Feb 2018 00:32:36 +0300
> From: Andrey Repin 
> To: Sean McNamara , All
>  
> Subject: Re: [lxc-users] LXC master: Legacy Config Items Have Been Removed
> 
> Greetings, Sean McNamara!
> 
> > For LXD, is it true that the only potential impact is if you use
> > lxc.raw in a config or profile?

Yes, LXD will only be affected when you use lxc.raw entries. LXD itself
will generate the containers configuration on the fly and will also
perform checks at runtime which liblxc version is used.

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

Re: [lxc-users] Migrating a rootfs back-and-forth lxc 2.0 <=> 3.0

[Christian Brauner]

> Date: Thu, 15 Feb 2018 13:05:44 -0500 (EST)
> From: Adrian Pepper 
> To: lxc-users@lists.linuxcontainers.org
> Subject: [lxc-users] Migrating a rootfs back-and-forth lxc 2.0 <=> 3.0
> 
> Should one expect to encounter subtle (or perhaps not-so-subtle)
> problems if one takes the rootfs of a simple container created under
> one major version of lxc and uses it to replace the rootfs of a
> container previously created under another major version?
> (Replacing while the target is stopped, and then starting
> the container after the replacement).

No, that shouldn' cause any problems.

> 
> Assume that due diligence was done to keep the hostname in the
> filesystem was consistent with lxc.uts.name (or its equivalent
> in the relevant version), etc.
> 
> Or should one expect this to work seamlessly?  (The question would be
> whether there are hooks of some sort under the rootfs which might get
> automatically migrated in one direction (presumably "forwards" to a
> higher version), but not in the other direction, or possibly not in
> either direction at all).
> 
> Somewhat similarly, but conversely, I would assume that there is never
> any situation where having the same rootfs used simultaneously by more
> than one executing container would not be disastrous.  (in my case just
> a foreseeable possible accident, not something I have visions of exploiting).

That is a bad idea yes. For example, with system container you'd have
two init system thinking that they are in control of the whole rootfs
and fstree.

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

[lxc-users] LXC 3.0: Removal of cgmanager And cgfs cgroup Drivers

[Christian Brauner]

Hey everyone,

This is another update about the development of LXC 3.0. As of yesterday
the cgmanager and cgfs cgroup drivers have been removed from the
codebase. In the good long tradition of all LXC projects to try our
hardest to never regress our users and to clearly communicate invasive
changes I wanted to take the time to explain why these two cgroup
drivers have been removed in a little more detail.

 cgmanager
The cgmanager cgroup driver relies on the upstream cgmanager project
which as created and written by fellow LXC and LXD maintainer Serge
Hallyn. In a time where proper userspace cgroup management was still an
unsolved problem cgmanager was a stroke of genius and solved a lot of
issues. The most prominent ones where:
- using cgroups when nesting containers
- enabling cgroup management for unprivileged users running unprivileged
  containers, i.e. containers emplying user namespaces and idmappings.
To this day it isn't possible to do unprivileged cgroup management. The
upstream maintainers are opinionated in that respect and probably are
rightly so. To delegate cgroups to unprivileged users privilege is
required. To address this problem the cgmanager driver was bundled with
the cgmanager daemon.
The cgmanager daemon and it's driver counterpart in LXC were an
appropriate solution in a time where init systems did not do any proper
cgroup managment. With the rise of systemd this changed. Nowadays,
systemd is effectively its own cgroup manager. While this didn't
necessarily had to mean the end of cgamanger it seemed unlikely that users
would run two competing cgroup managers on the system. (To be honest, one
can still consider it controversial whether systemd in addition to using
a dedicated cgroup or cgroups to do process tracking should also be a
full cgroup manager. But it is at least an understandable choice.)
Additionally, a new cgroup driver was added to LXC that did not rely on
a cgroup manager daemon. It was written to be compatible with
unprivileged cgroup management and cgroup management when nesting
containers. (Unprivileged cgroup management is usually done by employing
our pam module which places users in writable cgroups on login.) While
unprivileged cgroup management is still not a solved problem, especially
with the rise of the unified cgroup hierarchy, cgmanager has outlived its
purpose. It has been marked deprecated for a long long time now. So
while it is still supported on the LXC 1.* stable branch it is now
officially dead. A big thanks to Serge for coming up with this project!

 cgfs
The cgfs driver, if I have my facts straight, stems from a time even
before cgmanager was a thing. Actually, it is so old that mounting
cgroups was not yet clearly standardized. For example, in these (dark)
times some distros would wount cgroups at /dev/cgroup while others would
mount them at /sys/fs/cgroup. In addition some distros would mount all
controllers into a single hierarchy located directly at /sys/fs/cgroup
other distros would mount some controllers into separate hierarchies and
others together. Over time the upstream cgroup maintainers became more
and more opinionated how and where cgroups should be mounted. At the
same time systemd decided to mount cgroups in a very specific layout.
This layout has been the default on nearly all distros that either use
systemd or have their init system mount cgroups.
The cgfs driver tried to accommodate **all** possible layouts, i.e. it
tried to find the mountpoint for each controller and mimic this layout
for the container. It obviously came with a lof of flexibility and the
code showed it. It was a massive C file that did a lot of complex
parsing. Nowadays, it is perfectly reasonable for a performant cgroup
driver to make simplifying assumptions about how cgroups are to be
mounted. This is especially true with the unified cgroup hierarchy.
Being able to rely on these standards is a good thing. It means code can
be simplified, logic can be simplified, and special cases become less
likely. In the face of these changes, carrying the cgfs driver into the
future would have meant accepting a significant but unecessary
performance penalty that outlived its own cause. That can't be a good
thing. It also would have meant keeping around massively complex
codepaths that would never really be hit or only hit in very rare
circumstances on exotic systems.

 More General Reasons
These are some arguments that apply to both cgroup drivers and to
coding in general:
- forgotten logic

  Reasoning about fallback/legacy codepaths is not a thing developers
  will have to do often. This makes it less likely for them to figure
  out bugs quickly. This is frustrating to users but also to developers
  since it increases maintenance costs significantly.
- code blindeness

  This is a general phenomenon that comes in two forms. Most developers
  will know what I'm talking about. It either means ones has stared at a
  codepath for too long to really see problems anym

Re: [lxc-users] LXC 3.0: Removal of cgmanager And cgfs cgroup Drivers

[Christian Brauner]

On Tue, Feb 20, 2018 at 13:04:00PM +0100, Harald Dunkel wrote:

> Does this mean that lxc 3.0 is systemd-only?

No!

This has no effect whatsoever on what init system you are running. This
is completely orthogonal and to some extent always has been. In fact,
we've become even more agnostic wrt to what init binary (be it a full
init system or a simple application) can be run. Additionally, the
current cgroup driver contains logic:
- to mount cgroups for an init system that doesn't mount cgroups by
  itself (e.g.  OpenRC) even when cgroup namespaces are supported.
  Something which wasn't possible before without specifying
  lxc.mount.entry entries or running hooks.
- to mount cgroups for container that drop CAP_SYS_ADMIN (privilged and
  unprivileged) in their user namespace

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

Re: [lxc-users] LXC 3.0: Removal of cgmanager And cgfs cgroup Drivers

[Christian Brauner]

On Tue, Feb 20, 2018 at 07:17:42PM +0100, Dirk Geschke wrote:
> Hi Christian,
> 
> > > Does this mean that lxc 3.0 is systemd-only?
> > 
> > No!
> > 
> > This has no effect whatsoever on what init system you are running. This
> > is completely orthogonal and to some extent always has been. In fact,
> > we've become even more agnostic wrt to what init binary (be it a full
> > init system or a simple application) can be run. Additionally, the
> > current cgroup driver contains logic:
> > - to mount cgroups for an init system that doesn't mount cgroups by
> >   itself (e.g.  OpenRC) even when cgroup namespaces are supported.
> >   Something which wasn't possible before without specifying
> >   lxc.mount.entry entries or running hooks.
> > - to mount cgroups for container that drop CAP_SYS_ADMIN (privilged and
> >   unprivileged) in their user namespace
> 
> that sounds great: Well done!
> 
> BTW: Do you know the kernel parameter for cgroup namespaces? The 
>  kernel config knows only about CONFIG_NAMESPACES, UTS_NS, IPC_NS,
>  USER_NS, PID_NS and NET_NS. I know, there are cgroup namespaces,
>  but what is the configuration parameter? I'm just wondering...

There's no separate flag for cgroup namespaces in the upstream kernel.
Cgroup namespaces are usually enabled by setting CONFIG_CGROUPS=y. From
the manpage (man cgroup_namespaces):
"Use of cgroup namespaces requires a kernel that is configured with the
 CONFIG_CGROUPS option."

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

[lxc-users] On The Way To LXC 3.0: Splitting Out Templates And Language Bindings

[Christian Brauner]

Hey everyone,

This is another update about the LXC 3.0 development. Instead of copying
and pasting what I wrote on my blog here I'm going to be lazy and please
ask you to read:

https://brauner.github.io/2018/02/27/lxc-removes-legacy-template-build-system.html

This should give you an idea what we are planning to do with the
language bindings and the template build system. And if that makes you
more likely to read it: there are asciicasts. :)

Thanks everyone!
Christian
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] On The Way To LXC 3.0: Moving The Cgroup Pam Module Into The LXC Tree (Including A Detour About Fully Unprivileged Containers)

[Christian Brauner]

Hey everyone,

Yet another blogpost about LXC 3.0 development. This time we'd like to
tell you what happens to the pam_cgfs.so pam module that we used to ship
with LXCFS. You can read the details here:

https://brauner.github.io/2018/02/28/lxc-includes-cgroup-pam-module.html

We're near the finish line so bear with us. We hope the blogposts are
sufficiently informative and useful for all of you but we'd rather be
informing you too much than to little. Also, **more asciicasts** that
can only be good thing, right.

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

Re: [lxc-users] On The Way To LXC 3.0: Splitting Out Templates And Language Bindings

[Christian Brauner]

On Thu, Mar 01, 2018 at 03:48:06AM +0300, Andrey Repin wrote:
> Greetings, Christian Brauner!
> 
> > And if that makes you
> > more likely to read it: there are asciicasts. :)
> 
> 410 Gone

Oha, let me fix this :) Thanks!

Christian

> 
> :(
> 
> 
> -- 
> With best regards,
> Andrey Repin
> Thursday, March 1, 2018 03:47:50
> 
> Sorry for my terrible english...
> 
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] how to crate a new Fedora LXC-template

[Christian Brauner]

On Thu, Mar 01, 2018 at 12:06:59AM -0500, Saint Michael wrote:
> I want to use Fedora 27 as a container. Supposed I install a physical
> machine with Fedora, how do I convert it to a container?

Stéphane added a new binary to LXD called lxd-p2c
( https://github.com/lxc/lxd/tree/master/lxd-p2c ) which lets you
convert any physical system into a container. It currently depends on
LXD though.

If you just care about building container images that can be consumed by
new versions of LXC than you should look at
https://github.com/lxc/distrobuilder . It is a very simple Go project to
build LXC and LXD container images. Fedora definitely is something that
we would like to add support for. If you or the wider community have
some interest you could work on adding Fedora support to distrobuilder.
I've opened an issue there just now: 
https://github.com/lxc/distrobuilder/issues/23

Christian

> Somebody should create a script that would "containerize" any OS.
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Attempt to define unprivileged LXC by libvirt

[Christian Brauner]

On Fri, Mar 23, 2018 at 11:49:08AM +0100, ales drtik wrote:
> Hi,
> i converted LXC conf to xml by:
> 
> lxcuser@blade1:~/.local/share/lxc/test_deb$  virsh -c lxc:/// 
> domxml-from-native lxc-tools /home/lxcuser/.local/share/lxc/test_deb/config
> 
> 
>   test_deb
>   cce77799-89fd-41fd-99c1-101e00844e23
>   65536
>   65536
>   1
>   
> exe
> /sbin/init
>   
>   
> 
> 
>   
>   
> 
> 
>   
>   
>   destroy
>   restart
>   destroy
>   
> /usr/lib/libvirt/libvirt_lxc
> 
>   
>   
> 
> 
>   
>   
>   
> 
>   
> 
> 
> Now attempt to define by virsh gives this err:
> 
> lxcuser@blade1:~/.local/share/lxc/test_deb$ virsh -c lxc:/// define 
> tmp/test_deb.xml
> error: Failed to define domain from /tmp/test_deb.xml
> error: unsupported configuration: You must map the root user of container
> 
> Debian stretch.
> Where am I wrong ?

Sorry, libvirt-lxc is a totally different project than ours. I have no
idea what the mapping between the two would look like. Serge, Stéphane,
ideas?

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

Re: [lxc-users] distrobuilder build-lxc, then how to start the container?

[Christian Brauner]

On Sat, Mar 31, 2018 at 02:50:00PM +0300, Mihamina RAKOTOMANDIMBY wrote:
> Hello,
> 
> Running LXC 3 on Archlinux, after having buit for LXC with "distrobuild
> build-lxc [...]": what is the next step to register the new container and
> start it?

So that's simply (this assumes LXC 3.0):

lxc-create  -t local -- --metadata meta.tar.xz --fstree 
rootfs.tar.xz

> Then how to setup its networking in order to attach it to a bridge? (I've
> previouly set up a bridge)

lxc.net.0.type  = veth
lxc.net.0.flags = up
lxc.net.0.link  = 
lxc.net.0.name  = eth0

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

[lxc-users] LXC 3.0.0: Packaging Changes To Be Aware Of

[Christian Brauner]

Hey everyone,

LX{C,FS,D} upstream here. :)

I'm sorry to ping you all at once in this mail and I seriously hope I only
added actual package maintainers for LXC based projects in their respective
distros to this mail. If not I'm genuinely sorry to have banged on your door
(or rather inbox) on a Saturday!

A few days ago we released LXC [1] and LXD [2] 3.0.0 which are going to be our
next LTS releases receiving support from upstream for 5 years until 2023.

LXC 3.0.0 not just introduces a lot of changes and improvements on all fronts
in general but will also likely require changes in packaging. These changes are
what I'd like to inform you about because we really don't want you all to run
into pointless confusion and problems.

The distros I think should be reached by this mail are:

Alpine
ArchLinux
Debian
Fedora
Gentoo
NixOS
openSUSE
OpenWrt

Please, if anyone of you know other packagers in other distros that are not
derivatives of the above please forward this mail. Don't leave fellow
maintainers hanging. :)

Here is a list of what we consider will most likely affect you as packagers:

1. **Important** the lxc-templates have been moved out of the main LXC tree
   into a separate repository
   https://github.com/lxc/lxc-templates

   This means that without this separate package LXC will now only come with
   the following templates:

   lxc-busybox
   lxc-download
   lxc-local
   lxc-oci

2. **Important** distrobuilder is the new way of creating machine/system
container images
   The templates have been replaced by a new project called "distrobuilder"
   [5]. It aims to be a very simple Go project focussed on letting you easily
   build full system container images by either using the official cloud image
   if one is provided by the distro or by using the respective distro's
   recommended tooling (e.g. debootstrap for Debian or pacman for ArchLinux).
   It aims to be declarative, using the same set of options for all
   distributions while having extensive validation code to ensure everything
   that's downloaded is properly validated.

   **Warning: Advertisement** please consider packaging distrobuilder.
   https://github.com/lxc/distrobuilder

   A more lengthy justification can be found at:
   
https://brauner.github.io/2018/02/27/lxc-removes-legacy-template-build-system.html

3. The python3 bindings have been moved out of the main LXC tree and are
   maintained in a separate Github repo under the LXC namespace.
   https://github.com/lxc/python3-lxc

   This means that the

   --with-python

   configure flag should be dropped.

   A more lengthy justification can be found at:
   
https://brauner.github.io/2018/02/27/lxc-removes-legacy-template-build-system.html

4. The lua bindings have been moved out of the main LXC tree and are
   maintained in a separate Github repo under the LXC namespace.
   https://github.com/lxc/lua-lxc

   This means that the

   --with-lua

   configure flag should be dropped.

   A more lengthy justification can be found at:
   
https://brauner.github.io/2018/02/27/lxc-removes-legacy-template-build-system.html

5. **Important** the pam_cgfs.so pam module has moved from the LXCFS tree into
   the LXC tree
   https://github.com/lxc/lxc/blob/master/src/lxc/pam/pam_cgfs.c

   This means that in order to compile the pam module with LXC you should pass:

   --enable-pam

   and

   --with-pamdir=PAM_PATH

   when compiling LXC.
   In case you don't know what the pam module is for it is used to allow
   unprivileged cgroup management for fully unprivileged containers. It
   useful for all container runtimes (e.g. openSUSE is shipping and
   using it). For a slightly deeper look at it I suggest you read [3].

6. Removeal of legacy cgroup drivers
   This includes the cgmanager driver. Which also implies that

   This means that the

   --with-cgmanager

   configure flag should be dropped. The cgmanager package can likely also be
   dropped unless you maintain a package for our 1.0 stable branch!

   A more lengthy justification can be found at:
   https://brauner.github.io/2018/02/20/lxc-removes-legacy-cgroup-drivers.html

7. All legacy configuration keys have been removed.
   With LXC 2.1.0 we started to print warning when legacy configuration keys
   were used in the container config and started yelling at people that we will
   remove legacy configuration keys in LXC 3.0.0. This is now reality.
   We ship an upgrade script since LXC 2.1:

   chb@conventiont|~
   > lxc-update-config
   /usr/bin/lxc-update-config -h|--help [-c|--config]
   config: the container configuration to update

   which will automatically replace legacy configuration keys with their new
   counterparts. If the upgrade fails it will have left a *.backup file in the
   same directory where the config file was and it can simply be restored.

   Please make sure your users know about this update script. Fwiw, [4]
   provides a list of all removed legacy configuration keys and their new
   counterparts.

Re: [lxc-users] Question regarding container affecting the system mounts

[Christian Brauner]

On Tue, Mar 27, 2018 at 11:00:01AM -0500, Ronak Desai wrote:
> Hi,
> 
> I came a cross a problem where if the containers are running then it
> affects the unmount process of the system's mount points. I am not
> using these mount points as shared partitions with container.
> 
> For example, I am using SD card and NAND as external storage device
> and mounting it to a mount point in the ramfs. Then I am launching
> containers and then when I try to unmount the NAND partition then my
> "unmount" call succeeds but I don't see the UBIFS hooks being called

Are you saying that all your containers are using the SD card as backing
storage device?

> and because of that my UBI detach process fails. When I stopped the
> container then I see that kernel is calling the unmount as I see my
> debug prints inside the UBIFS for unmounting that partition. It seems
> like the calls are buffered/queued because of container.
> 
> If I tried to mount my NAND partition once the container is up and try
> to unmount then it does unmount and detach without issue. It seems
> like there is an issue with namespace.
> 
> I am using 4.1.8 kernel . Please let me know if you need any
> additional detail from my end.
> 
> Thanks in advance !
> 
> -- 
> Ronak A Desai
> Sr. Software Engineer
> Airborne Information Solutions / RC Linux Platform Software
> MS 131-100, C Ave NE, Cedar Rapids, IA, 52498, USA
> ronak.de...@rockwellcollins.com
> https://www.rockwellcollins.com/
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] SIGRTMIN+3

[Christian Brauner]

On Tue, Mar 27, 2018 at 10:12:15AM -0400, Eric Wolf wrote:
> One of my containers is shutting down seemingly randomly. I'm trying
> to figure out why, but so far all I can find in syslog is systemd[1]:
> Received SIGRTMIN+3. which seems to be related to the LXC/LXD stop
> command, but I can't find anything that might be sending that command
> from my host, so I'm here looking for help finding the source. I'm not
> sure what to look for in my logs, either in the container or on the
> host.

What? That's odd. Can you run LXD in debug mode like

sudo lxd --debug --group lxd

and then paste the log of the affected container here. It should be
located in /var/log/lxd//lxc.log

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

Re: [lxc-users] Using devices in an unprivileged LXC container

[Christian Brauner]

On Sun, Mar 25, 2018 at 05:23:21PM +, Avadhut Bhangui wrote:
> Hello,
> I have an ubuntu system. i login to the device as root user. I have two LXC 
> containers created using the busbox template. One is privileged and other one 
> is unprivileged.
> I want to ensure that when a USB device is connected to my ubuntu box, i 
> should be able grant access to the unprivileged container. What options are 
> possible and how do we do this?

Are you using LXD or LXC?

For LXD it should be as simple as

lxc config device add   usb vendorid= 
productid=

vendor and product id can be gathered via lsusb. For example:

lxc config device add c1 sony usb vendorid=0fce productid=51da

would pass through a specific Sony phone.

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

Re: [lxc-users] debugging a failing clone() call

[Christian Brauner]

On Fri, Mar 23, 2018 at 06:13:15AM -0400, Andrew Cann wrote:
> Hello,
> 
> The folowing sycall is failing when called on a Travis-CI build machine.
> 
> clone(..,
> CLONE_FILES |
> CLONE_IO |
> CLONE_SIGHAND |
> CLONE_VM |
> CLONE_SYSVSEM |
> CLONE_NEWNET |
> CLONE_NEWUTS |
> CLONE_NEWUSER,
> ..
> );
> 
> This works when I run it on my machine, but inside the Docker container that
> Travis creates it fails with EPERM. Can anyone suggest why this might be
> happening? The clone(2) manpage lists possible reasons:
> 
> 
> EPERM   CLONE_NEWCGROUP, CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, 
> CLONE_NEWPID,
> or CLONE_NEWUTS was specified by an unprivileged process (process
> without CAP_SYS_ADMIN).
> 
> This shouldn't apply since I'm using CLONE_NEWUSER
> 
> 
> EPERM   CLONE_PID was specified by a process other than process 0. (This error
> occurs only on Linux 2.5.15 and earlier.)
> 
> Doesn't apply.
> 
> 
> EPERM   CLONE_NEWUSER was specified in flags, but either the effective user ID
> or the effective group ID of the caller does not have a mapping in the
> parent namespace (see user_namespaces(7)).
> 
> Again, this shouldn't apply. The process creating the namespace has a valid
> (not-nobody) uid and gid.
> 
> 
> EPERM   (since Linux 3.9) CLONE_NEWUSER was specified in flags and the caller
> is in a chroot environment (i.e., the caller's root directory does not
> match the root directory of the mount namespace in which it resides).
> 
> Possibly this one? The docker container shouldn't be aware that it's running 
> in
> a chroot though. Calling mount inside the container lists:
> 
> overlay on / type overlay (rw,relatime,...)
> 
> Which indicates that it's living inside its own mount namespace with its own
> root directory.
> 
> So I'm confused. Does anyone have any suggestions for why else this might be
> failing or thngs I could try to debug it? Is there a way to get more than just
> an eror code out of linux? Are there reasons for giving that error code that
> aren't listed in the man page?

Well, the Docker container might have dropped CAP_SYS_ADMIN at which
point you're not allowed to use any of the CLONE_* flags. Docker does
this as a security measure since they still default to running
privileged containers which are inherently unsafe.

Another possibility is that you're running a distro as host that does
not enable CLONE_NEWUSER by default. This can e.g. be the case with
CentOS based distros.

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

Re: [lxc-users] authentication in containers jacked-up!

[Christian Brauner]

On Thu, Mar 29, 2018 at 09:22:07AM -0400, Ray Jender wrote:
> So in Ubuntu 16.04.4 I created  4 LXD containers using LXC. From the host I
> created the first container then did $ lxc copy containter1 container2 , 1
> to 3 and 1 to 4.
> 
> It was a challenge for me to make them accessible from the outside world but
> I conquered that.
> 
>  
> 
> Now however I cannot su or sudo inside the containers?  For instance:
> 
>  
> 
> sudo find / -name testfile -print
> 
> sudo: no tty present and no askpass program specified
> 
>  
> 
> also.
> 
>  
> 
> When I do   $  lxc exec container1  /bin/bash  from the host:
> 
>  
> 
> I am put in:  ray@container1:/root$  // The "/root"  does not seem correct?
> 
>  
> 
> Also.
> 
>  
> 
> ray@container2:/etc$  visudo
> 
> visudo: /etc/sudoers: Permission denied
> 
>  
> 
> ray@ container2:/etc$  su visudo
> 
> su: must be run from a terminal
> 
>  
> 
> ray@ container 2:/etc$  sudo visudo
> 
> sudo: no tty present and no askpass program specified
> 
>  
> 
> Also when I try to putty into the container, I get the "login as:"  prompt,
> but when I enter the user name, I get:
> 
>  
> 
> puTTY Fatal Error
> 
> Disconnected: No supported authentication methods available (server sent:
> publickey)
> 
> (same error from WinSCP)
> 
>  
> 
> Any idea what I am missing?
> 
>  
> 
> Thanks, appreciate your help on this.

What containers (distro) are you creating?
What LXD version and what LXC version?

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

Re: [lxc-users] LXC 3.0.0: Packaging Changes To Be Aware Of

[Christian Brauner]

On Sat, Apr 07, 2018 at 10:11:58PM +0300, Mihamina RAKOTOMANDIMBY wrote:
> On 4/7/18 5:54 PM, Christian Brauner wrote:
> > 2. **Important** distrobuilder is the new way of creating machine/system
> >  container images
> > The templates have been replaced by a new project called "distrobuilder"
> > [5]. It aims to be a very simple Go project focussed on letting you 
> > easily
> > build full system container images by either using the official cloud 
> > image
> > if one is provided by the distro or by using the respective distro's
> > recommended tooling (e.g. debootstrap for Debian or pacman for 
> > ArchLinux).
> > It aims to be declarative, using the same set of options for all
> > distributions while having extensive validation code to ensure 
> > everything
> > that's downloaded is properly validated.
> > 
> > **Warning: Advertisement** please consider packaging distrobuilder.
> > https://github.com/lxc/distrobuilder
> > 
> > A more lengthy justification can be found at:
> > 
> > https://brauner.github.io/2018/02/27/lxc-removes-legacy-template-build-system.html
> 
> 
> Hello,
> 
> I'm looking for some tutorial of using the image built with distrobuilder.
> 
> After having build the image: how to start it with lxc-start?

lxc-create -n  -t local -- --metadata /path/to/meta.tar.xz 
--fstree /path/to/rootfs.tar.xz
lxc-start -n 

Also see:
https://asciinema.org/a/165783

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

[lxc-users] Patches required to compile LXC on ArchLinux with gcc-8

[Christian Brauner]

Hey everyone,

We've recently discovered that gcc-8 likes to complain (pointlessly
about non-bugs) a lot when compiling LXC on ArchLinux. This breaks the
build process. We have a set of patches that should fix this. They are
all already backported to at least stable-3.0:

ccd42a31440f584a82bd8aa1f6e1b34bcc87e5b5 
https://github.com/lxc/lxc/commit/ccd42a31440f584a82bd8aa1f6e1b34bcc87e5b5
d3bdf12cf00e93e3b1df354dd4cc46356baedf24 
https://github.com/lxc/lxc/commit/d3bdf12cf00e93e3b1df354dd4cc46356baedf24
def4def6fd9df15dbb1f3ea107b92ab0ce96d909 
https://github.com/lxc/lxc/commit/def4def6fd9df15dbb1f3ea107b92ab0ce96d909
095ead8051b58ec4a7aa89ad711daec15dff5f54 
https://github.com/lxc/lxc/commit/095ead8051b58ec4a7aa89ad711daec15dff5f54
91c272a571d1e0f1c91fa37102fffdd3540514ce 
https://github.com/lxc/lxc/commit/91c272a571d1e0f1c91fa37102fffdd3540514ce
9de31d5a1394fd0bed495fa7cde5e625a1d64b48 
https://github.com/lxc/lxc/commit/9de31d5a1394fd0bed495fa7cde5e625a1d64b48
2ec47d5149e73db97f7877d06d67cb11421097bb 
https://github.com/lxc/lxc/commit/2ec47d5149e73db97f7877d06d67cb11421097bb
50c6bb6b74d0414bc1b3bd5395b2bad6009a017d 
https://github.com/lxc/lxc/commit/50c6bb6b74d0414bc1b3bd5395b2bad6009a017d
d96a98469176ab6064583331cab9f002632a4586 
https://github.com/lxc/lxc/commit/d96a98469176ab6064583331cab9f002632a4586

For developers please note that we have officially deprecated strncpy()
from our codebase. It is replaced by a strlcpy() implementation that
will be included automatically on systems using libcs that don't provide
an implementation. Our official coding style now states:

>  Use strlcpy() instead of strncpy()
> 
> When copying strings always use strlcpy() instead of strncpy(). The
> advantage of strlcpy() is that it will always append a `\0` byte to the
> string.
> 
> Unless you have a valid reason to accept truncation you must check whether
> truncation has occurred, treat it as an error, and handle the error
> appropriately.

Thanks!
Christian


signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Unprivileged LXC - proc:mixed vs. proc:rw

[Christian Brauner]

On Wed, May 23, 2018 at 06:13:02PM +0200, Dr. Todor Dimitrov wrote:
> Hallo,
> 
> is there any security benefit of using proc:mixed inside an unprivileged 
> container? Or does proc:rw deliver the same level of isolation?

There's no security benefit for unprivileged containers. They can't
change /proc/sys and /proc/sysrq-trigger. If they can and the file isn't
namespaced it's a bug.

Christian

> 
> lxc.mount.auto = proc:mixed
> 
> vs.
> 
> lxc.mount.auto = proc:rw
> 
> Thanks in advance,
> Todor
> 



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

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

Re: [lxc-users] Fedora 27

[Christian Brauner]

On Mon, Jun 04, 2018 at 08:47:28PM -0400, Saint Michael wrote:
> I am struggling with adding LXC 3.0 to the latest Fedora Server 27.
> Also, in Fedora, the containers do no start automatically. I think I am
> missing some step in the system configuration. Any idea how to add LXC 3.0
> to Fedora and make lxc-autostart happen automatically?

Stéphane is this something you would know more about?

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

Re: [lxc-users] Can't start unprivileged containers on fedora 28

[Christian Brauner]

On Tue, Jun 05, 2018 at 02:25:52PM +0200, Mohamed LADGEM wrote:
> Hi,
> 
> Since few days, I'm struggling with lxc as unpriveleged user to start
> an alpine without success. I am running 2.1.1 from ganto/lxc repo.
> 
> I ran lxc-start -n test --logpriority=DEBUG --logfile=/tmp/log_lxc
> Could you help me to  get a better a view of what I am missing ?

Looks like your cgroups are not writable for your unprivileged users.
That's what the pam module (pre 3.0.0 ships this in LXCFS) is for.

Christian

> 
> Here is what I found, 
>   lxc-start test 20180605120725.666 INFO lxc_start_ui -
> tools/lxc_start.c:main:280 - using rcfile
> /home/kinkazma/.local/share/lxc/test/config
>   lxc-start test 20180605120725.666 INFO lxc_confile -
> confile.c:set_config_idmaps:1556 - Read uid map: type u nsid 0 hostid
> 10 range 65536
>   lxc-start test 20180605120725.666 INFO lxc_confile -
> confile.c:set_config_idmaps:1556 - Read uid map: type g nsid 0 hostid
> 10 range 65536
>   lxc-start test 20180605120725.667 INFO lxc_container -
> lxccontainer.c:do_lxcapi_start:883 - Attempting to set proc title to
> [lxc monitor] /home/kinkazma/.local/share/lxc test
>   lxc-start test 20180605120725.667 INFO lxc_lsm -
> lsm/lsm.c:lsm_init:48 - LSM security driver SELinux
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:435 - processing: .reject_force_umount  #
> comment this to allow umount -f;  not recommended.
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:610 - Adding native rule for
> reject_force_umount action 0(kill).
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:do_resolve_add_rule:276 - Setting Seccomp rule to reject
> force umounts.
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:614 - Adding compat rule for
> reject_force_umount action 0(kill).
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:do_resolve_add_rule:276 - Setting Seccomp rule to reject
> force umounts.
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:do_resolve_add_rule:276 - Setting Seccomp rule to reject
> force umounts.
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:435 - processing: .[all].
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:435 - processing: .kexec_load errno 1.
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:610 - Adding native rule for kexec_load
> action 327681(errno).
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:614 - Adding compat rule for kexec_load
> action 327681(errno).
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:435 - processing: .open_by_handle_at errno 1.
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:610 - Adding native rule for
> open_by_handle_at action 327681(errno).
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:614 - Adding compat rule for
> open_by_handle_at action 327681(errno).
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:435 - processing: .init_module errno 1.
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:610 - Adding native rule for init_module
> action 327681(errno).
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:614 - Adding compat rule for init_module
> action 327681(errno).
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:435 - processing: .finit_module errno 1.
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:610 - Adding native rule for finit_module
> action 327681(errno).
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:614 - Adding compat rule for finit_module
> action 327681(errno).
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:435 - processing: .delete_module errno 1.
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:610 - Adding native rule for delete_module
> action 327681(errno).
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:614 - Adding compat rule for delete_module
> action 327681(errno).
>   lxc-start test 20180605120725.668 INFO lxc_seccomp -
> seccomp.c:parse_config_v2:624 - Merging in the compat Seccomp ctx into
> the main one.
>   lxc-start test 20180605120725.668 WARN lxc_monitor -
> monitor.c:lxc_monitor_fifo_send:111 - Failed to open fifo to send
> message: No such file or directory.
>   lxc-star

Re: [lxc-users] Use image file for unprivileged containers

[Christian Brauner]

On Fri, Jun 15, 2018 at 10:28:34AM +0200, Dr. Todor Dimitrov wrote:
> Hallo,
> 
> is it possible to use an image file with “lxc.rootfs.path” for an
> unprivileged container? If possible, is it necessary to have the
> correct file ownerships within the image or are these automatically
> adjusted on start, e.g. on mount.

If by image you mean something you can mount on a loop device then yes
but it will have to be idshifted before the start.

Christian

> 
> Thanks in advance,
> Todor
> 



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

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

Re: [lxc-users] Use image file for unprivileged containers

[Christian Brauner]

On Fri, Jun 15, 2018 at 05:02:50PM +0200, Dr. Todor Dimitrov wrote:
> Hallo Christian,
> 
> do I have to manually perform the loop mount? I thought this was done by the 
> LXC runtime.

Yes, the mount is performed. If you have manually prepared an image you
can do:

lxc.rootfs.path = loop:/path/to/file

> 
> What is actually meant by “image file” inside the documentation:
> 
> “
> lxc.rootfs.path - specify the root file system for the container. It can be 
> an image file, a directory or a block device. If not specified, the container 
> shares its root file system with the host.
> "
> 
> Todor
> 
> > On 15. Jun 2018, at 16:39, Christian Brauner  wrote:
> > 
> > On Fri, Jun 15, 2018 at 10:28:34AM +0200, Dr. Todor Dimitrov wrote:
> >> Hallo,
> >> 
> >> is it possible to use an image file with “lxc.rootfs.path” for an
> >> unprivileged container? If possible, is it necessary to have the
> >> correct file ownerships within the image or are these automatically
> >> adjusted on start, e.g. on mount.
> > 
> > If by image you mean something you can mount on a loop device then yes
> > but it will have to be idshifted before the start.
> > 
> > Christian
> > 
> >> 
> >> Thanks in advance,
> >> Todor
> >> 
> > 
> > 
> > 
> >> ___
> >> lxc-users mailing list
> >> lxc-users@lists.linuxcontainers.org
> >> http://lists.linuxcontainers.org/listinfo/lxc-users
> > 
> > ___
> > lxc-users mailing list
> > lxc-users@lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> 



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

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

Re: [lxc-users] Use image file for unprivileged containers

[Christian Brauner]

On Fri, Jun 15, 2018 at 06:03:06PM +0200, Dr. Todor Dimitrov wrote:
> >> but it will have to be idshifted before the start.
> 
> So the id shifting will be also done automatically? Once or on each start?

No, the id shifting is *not* done by LXC. Only the *mount*.

> 
> What about the format of the image file? Is there any documentation or 
> samples on this? I assume a dd img with a single partition (e.g. ext4) should 
> be OK?

We don't really handle partitions, I think. You can setup a privileged
container with:

sudo lxc-create ttt -t download -B loop -- -d alpine -r edge -a amd64

and then take a look at the loop file that got created. This is the
format we support.

Christian

> 
> Thanks,
> Todor
> 
> > On 15. Jun 2018, at 17:50, Christian Brauner  wrote:
> > 
> > On Fri, Jun 15, 2018 at 05:02:50PM +0200, Dr. Todor Dimitrov wrote:
> >> Hallo Christian,
> >> 
> >> do I have to manually perform the loop mount? I thought this was done by 
> >> the LXC runtime.
> > 
> > Yes, the mount is performed. If you have manually prepared an image you
> > can do:
> > 
> > lxc.rootfs.path = loop:/path/to/file
> > 
> >> 
> >> What is actually meant by “image file” inside the documentation:
> >> 
> >> “
> >> lxc.rootfs.path - specify the root file system for the container. It can 
> >> be an image file, a directory or a block device. If not specified, the 
> >> container shares its root file system with the host.
> >> "
> >> 
> >> Todor
> >> 
> >>> On 15. Jun 2018, at 16:39, Christian Brauner  wrote:
> >>> 
> >>> On Fri, Jun 15, 2018 at 10:28:34AM +0200, Dr. Todor Dimitrov wrote:
> >>>> Hallo,
> >>>> 
> >>>> is it possible to use an image file with “lxc.rootfs.path” for an
> >>>> unprivileged container? If possible, is it necessary to have the
> >>>> correct file ownerships within the image or are these automatically
> >>>> adjusted on start, e.g. on mount.
> >>> 
> >>> If by image you mean something you can mount on a loop device then yes
> >>> but it will have to be idshifted before the start.
> >>> 
> >>> Christian
> >>> 
> >>>> 
> >>>> Thanks in advance,
> >>>> Todor
> >>>> 
> >>> 
> >>> 
> >>> 
> >>>> ___
> >>>> lxc-users mailing list
> >>>> lxc-users@lists.linuxcontainers.org
> >>>> http://lists.linuxcontainers.org/listinfo/lxc-users
> >>> 
> >>> ___
> >>> lxc-users mailing list
> >>> lxc-users@lists.linuxcontainers.org
> >>> http://lists.linuxcontainers.org/listinfo/lxc-users
> >> 
> > 
> > 
> > 
> >> ___
> >> lxc-users mailing list
> >> lxc-users@lists.linuxcontainers.org
> >> http://lists.linuxcontainers.org/listinfo/lxc-users
> > 
> > ___
> > lxc-users mailing list
> > lxc-users@lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> 



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

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

Re: [lxc-users] Mounting fuse in a container - most recent instructions don't seem to work

[Christian Brauner]

On Sat, Jun 23, 2018 at 11:19:17PM +1000, Tony Lewis wrote:
> I am trying to use FUSE in a container, namely bup.  I get the following
> error:
> 
> fusermount: mount failed: Operation not permitted
> 
> The most recent instructions for this seem to be at
> http://blog.forshee.me/2016/02/container-mounts-in-ubuntu-1604.html, and
> seem to include:
> 
> |echo Y | sudo tee /sys/module/fuse/parameters/userns_mounts|
> 
> But when I run this on the host I get:
> 
> tee: /sys/module/fuse/parameters/userns_mounts: Permission denied
> 
> What should I do to be able to get FUSE running in an unprivileged
> container?
> 
> More info:
> 
> Host is Debian Stretch, 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1
> (2018-05-07) x86_64 GNU/Linux

This is currently a Ubuntu specific patch. It will be available upstream
starting with kernel 4.18.

Christian

> 
> LXC and LXC are both at version 3.1, via snap
> 
> The /dev/fuse node exists in the guest:
> 
> crw-rw-rw- 1 nobody nogroup 10, 229 May 23 11:54 /dev/fuse
> 
> In the parameters directory on the host I have:
> 
> ls -la /sys/module/fuse/parameters/
> total 0
> drwxr-xr-x 2 root root    0 Jun 23 22:58 .
> drwxr-xr-x 6 root root    0 Jun 23 22:58 ..
> -rw-r--r-- 1 root root 4096 Jun 23 22:58 max_user_bgreq
> -rw-r--r-- 1 root root 4096 Jun 23 22:58 max_user_congthresh
> 
> 
> 
> 

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

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

Re: [lxc-users] Mounting fuse in a container - most recent instructions don't seem to work

[Christian Brauner]

On Tue, Jun 26, 2018 at 08:44:09AM +1000, Tony Lewis wrote:
> On 25/06/18 21:22, Christian Brauner wrote:
> > On Sat, Jun 23, 2018 at 11:19:17PM +1000, Tony Lewis wrote:
> > > Host is Debian Stretch, 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1
> > > (2018-05-07) x86_64 GNU/Linux
> > This is currently a Ubuntu specific patch. It will be available upstream
> > starting with kernel 4.18.
> > 
> > Christian
> Can you point me towards the specific patch please?  I'm keen enough to try
> rolling my own kernel to test this out

Oh, that's a bunch of infrastructure to backport, I think but here it
comes:
- https://lists.linuxfoundation.org/pipermail/containers/2018-May/039002.html
- https://lists.linuxfoundation.org/pipermail/containers/2018-May/039003.html
- https://lists.linuxfoundation.org/pipermail/containers/2018-May/039004.html
- https://lists.linuxfoundation.org/pipermail/containers/2018-May/039005.html
- https://lists.linuxfoundation.org/pipermail/containers/2018-May/039006.html
- https://lists.linuxfoundation.org/pipermail/containers/2018-May/039007.html
- 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e45b2546e23c2d10f8585063a15c745a7603fac9
- 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4ad769f3c346ec3d458e255548dec26ca5284cf6

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

Re: [lxc-users] Is this expected isolcpus behaviour with lxc

[Christian Brauner]

On Thu, Jun 28, 2018 at 11:07:38AM +0530, Emmanuel Livingstone wrote:
> For now to overcome this issue, we've added a patch to an internal mirror
> of lxc debian repo https://anonscm.debian.org/git/pkg-lxc/lxc.git
> If you guys think adding a config parameter to not mask out the isolcpus in
> cpuset:/lxc would be welcome, please let me know. I can work on a patch and
> submit the same.

Hm, the main problem with this is that there's no nice way of adding a
config item that would allow one to configure this. Otherwise I'd be
fine with it.

> 
> On Wed, Jun 6, 2018 at 9:34 AM Emmanuel Livingstone <
> livingstone@gmail.com> wrote:
> 
> > Hi,
> >
> > We use lxc along with qemu/kvm in our boxes to provide containers and VMs.
> > We rely on isolcpus to ensure that the kernel scheduler by default does not
> > schedule OS processes on the cores that we've reserved for customer's
> > virtual instances(containers/VMs).
> > As per these 2 PRs(https://github.com/lxc/lxc/pull/1282,
> > https://github.com/lxc/lxc/pull/1309), cpuset.cpus inside cpuset:/lxc is
> > configured to have only those cpus that are not present in isolcpus. This
> > effectively means setting lxc.cgroup.cpuset.cpus for a lxc container to any
> > cpu that is part of isolcpus setting causes the container not to start.
> > This is because cpuset cgroup allows cpuset.cpus to be set to a value that
> > is a subset of the parent's value. Quoting from
> > https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt
> >
> > For any cpuset, one can define child cpusets containing a subset
> >of the parents CPU and Memory Node resources.
> >
> > I've verified this behaviour
> >
> > root@fk-cloud-none-1080125:/home/iaas# cgcreate -g cpuset:/test
> > root@fk-cloud-none-1080125:/home/iaas# echo 0-1 >
> > /sys/fs/cgroup/cpuset/test/cpuset.cpus
> > root@fk-cloud-none-1080125:/home/iaas# cgcreate -g cpuset:/test/container
> > root@fk-cloud-none-1080125:/home/iaas# echo 0 >
> > /sys/fs/cgroup/cpuset/test/container/cpuset.cpus
> > root@fk-cloud-none-1080125:/home/iaas# echo 1 >
> > /sys/fs/cgroup/cpuset/test/container/cpuset.cpus
> > root@fk-cloud-none-1080125:/home/iaas# echo 2 >
> > /sys/fs/cgroup/cpuset/test/container/cpuset.cpus
> > bash: echo: write error: Permission denied
> >
> > In our case, we have 48 core boxes on which we reserve 4 cores for OS
> > processes and remaining 44 cores for customers virtual instances.
> > It was working fine for us until we upgraded from debian 8 to debian 9,
> > i.e., kernel 3.16 to 4.9. In kernel 3.16 even if isolcpus was enabled, the
> > file /sys/devices/system/cpu/isolated was missing and is available in 4.9
> > through this commit
> > https://github.com/torvalds/linux/commit/59f30abe94bff50636c8cad45207a01fdcb2ee49
> >
> > I had come across a recommended way of overcoming this issue in this
> > comment
> > 
> > by stgraber where he had recommended that all system processes should be
> > put inside a restricted cpuset cgroup and the remaining cores to be used
> > for scheduling by lxc/lxd using a script. Is there alternate way in systemd
> > to do this without writing an ad-hoc startup script.
> >
> > Also since we use both libvirt(qemu/kvm) and lxc(without libvirt), I was
> > wondering why the behaviour of isolcpus is different in both these cases.
> >

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

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

Re: [lxc-users] library start() API from process name having spaces

[Christian Brauner]

On Wed, Jul 04, 2018 at 03:23:19PM -0400, Chaetoo3 wrote:
> Hi!
> 
> I try to use the liblxc start() API from my process and it worked, but
> I notice it would not set the process name for the container process
> as it would do from the lxc-start command line.  Instead the container
> process stayed with the name of my caller.

You mean it wouldn't change from "my binary --with --args" to "[lxc monitor]?

> 
> I sniff around and make a local fix.  I'm sorry I do not know how to
> contribute this to lxc, but if anyone want to do that, here is the
> code.  Reason is: /proc/self/stat contains the process name in
> parentheses.  If the name contains space, when liblxc parse the file
> it would get off by one field, and get confused and fail in
> setproctitle().
> 
> I don't know if my fix is robust enough for real, but at least should
> point someone to the right place?  This looks for trailing ") "
> sequence (parent and space).  That is still subject to errors because
> the process name might include such, but maybe there is not a way to
> avoid a false positive sometimes.  You cannot paren match either,
> because a process may not have matching.  Well anyway, this at least
> account for spaces in process name, which is a little bit common
> situation I think.
> 
> I hope it would help someone.
> 
> 
> @@ -296,10 +296,23 @@ int setproctitle(char *title)
> return -1;
> }
>  
> -   /* Skip the first 25 fields, column 26-28 are start_code, end_code,
> +/* Find the end of the process name, which is bounded by parentheses.
> + * Some processes may include parens in their name, which in the 
> worst
> + * case can trigger a false positive no matter what we do here.  This
> + * tries to avoid that by looking for a ') ' sequence.
> + */

Interesting. Ccing Mr. Andersen in case he has any opinions or wants to
contribute a patch.

Christian

> +   tmp = buf;
> +
> +   while (tmp[0] && tmp[1] && tmp[0] != ')' && tmp[1] != ' ') {
> +   tmp = strchr(tmp + 1, ')');
> +   if (!tmp)
> +   return -1;
> +   }
> +
> +   /* Skip the next 23 fields, column 26-28 are start_code, end_code,
>  * and start_stack */
> -   tmp = strchr(buf, ' ');
> -   for (i = 0; i < 24; i++) {
> +   tmp = strchr(tmp+1, ' ');
> +   for (i = 0; i < 23; i++) {
> if (!tmp)
> return -1;
> tmp = strchr(tmp+1, ' ');
> 
> 
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] PAM-CGFS[xxx]: Failed to get list of controllers

[Christian Brauner]

On Mon, Jul 09, 2018 at 02:08:03AM +1200, Richard Hector wrote:
> Hi all,
> 
> I'm seeing this in auth.log on an lxc host (no lxd).
> 
> "PAM-CGFS[xxx]: Failed to get list of controllers"
> 
> This is on a host I didn't set up; I've inherited maintenance for it,
> and recently added logcheck.
> 
> On another host, which I did set up, I don't see that. I have noticed
> that the problem host has libpam-cgfs installed, whereas the other one
> doesn't.
> 
> Both hosts are running Debian stretch, and IIRC both were upgraded from
> jessie.
> 
> Any tips on what's causing this, and whether it's a problem?

So, first of all let's determine if you need the pam module at all. :)
- Do you run unprivileged containers as an unprivileged user on the
  affected host? If not, you can remove the pam module.
- What version is the package the pam module is installed from. It might
  just be that it can't really handle the empty unified cgroup hierarchy
  because it is too old.

Christian


signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] library start() API from process name having spaces

[Christian Brauner]

On Thu, Jul 05, 2018 at 01:06:29PM -0400, Chaetoo3 wrote:
> > You mean it wouldn't change from "my binary --with --args" to "[lxc 
> > monitor]?
> 
> Yes, exactly like that.
> 
> It seems to me that proc stat file is for machine parsing, but is not
> so convenient for machine parsing.  I do not know if there is an
> official technique. There are some ways, but they all seem kludgy.
> Maybe it would be "good enough" to look for a pattern like:
> 
> "[)] [RSDZTtWXxKWP] [0-9]"
> 
> Kludge too, but the chance of process name false matching is remote,
> and anyway it isn't fatal when it happens, it just names the process
> wrongly.

Can you file an issue on Github with the details and your suggestions to
track this, please?

Christian


signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] lxc-create using lxc.idmap?

[Christian Brauner]

On Mon, Jul 16, 2018 at 08:24:09AM +0200, Harald Dunkel wrote:
> Hi folks,
> 
> is there a way to tell lxc-create to support a custom(!) UID and
> GID map via lxc.idmap? Each container should get its own mapping.
> 
> Problem behind this is that some containers may affect each other
> by exceeding the maximum number of threads. (Is this as expected?
> This is lxc 2.0.9.)
> 
> Subuids/subgids are not an option. I would like to use something
> like
> 
> % su -
> # lxc-create -t debian \
>   -o "lxc.idmap = u 0 10 65536" \
>   -o "lxc.idmap = g 0 10 65536" ...
> 
> to set the mapping right from the start, without touching /etc/lxc/\
> default.conf.
> 
> Do you think this could be possible?

Well, lxc-create could do what lxc-start is doing and grow an -s option.
The code that would need to be copied is in lxc_start.c.
Just from the top of my head without checking whether there are more
changes outside of tools/lxc_create.c required.

Christian

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

Re: [lxc-users] lxc 2.0 => 3.0 and ubuntu.common.conf (and lxc-templates dpkg)

[Christian Brauner]

On Tue, Jul 17, 2018 at 04:11:43PM -0400, Adrian Pepper wrote:
> > From arpep...@uwaterloo.ca Mon Jul 16 15:40:10 2018
> > From: AR Pepper 
> > To: "lxc-users@lists.linuxcontainers.org"
> > 
> > CC: AR Pepper 
> > 
> > This message devolved from a different query which is implied here together
> > with its answer.  Perhaps this result will save some other people some time.
> > 
> > 
> > I just discovered a stupid user (lxc administrator) trick.
> > 
> > Suppose you have an lxc setup you are migrating from Ubuntu 16.04 to 18.04.
> > (Going from lxc 2.0(2.0.8) to 3.0(3.0.1)).
> > (Doing a fresh install of Ubuntu 18.04 and modifying to match).
> > 
> > If under Ubuntu 18.04 you install the "lxc" package, but not the
> > "lxc-templates" package, then, even after "lxc-update-config",
> > some of your lxc config files will fail because of...
> > (for example)
> > 
> > lxc.include = /usr/share/lxc/config/ubuntu.common.conf
> > 
> > 
> > As an even stupider user trick, things seem to superficially work properly
> > if you simply remove the "ubuntu." from the config file, leaving
> > 
> > lxc.include = /usr/share/lxc/config/common.conf
> > 
> > It turns out /usr/share/lxc/config/ubuntu.common.conf (and many others)
> > are provided under Ubuntu by the "lxc-templates" package.
> > 
> > Hmm.  Could lxc-update-config (be changed to) remark upon the need for
> > the lxc-templates package?  Or maybe just make a general observation
> > that the include file does not exist?  ("Something is wrong")
> 
> While waiting for the above message to actually appear, I thought of a
> perhaps better set of comments on the same thing.  As a follow-up to
> Christian Brauner's packaging change announcement.
> 
> I eventually wonder (below) if "lxc" could once again have "lxc-templates"
> as a dependency, even though "lxc-utils" does[should] not.  Since "lxc"
> is now branded as a transitional package => lxc-utils.

That's a packaging call that Stéphane needs to make.

> 
> 
> Adrian Pepper
> arpep...@uwaterloo.ca
> 
> > From lxc-users-boun...@lists.linuxcontainers.org Sat Apr  7 12:04:56 2018
> > From: Christian Brauner 
> > Subject: [lxc-users] LXC 3.0.0: Packaging Changes To Be Aware Of
> > 
> > 
> > Hey everyone,
> > 
> > LX{C,FS,D} upstream here. :)
> > 
> [...]
> > 
> > Here is a list of what we consider will most likely affect you as packagers:
> > 
> > 1. **Important** the lxc-templates have been moved out of the main LXC tree
> >into a separate repository
> >https://github.com/lxc/lxc-templates
> > 
> >This means that without this separate package LXC will now only come with
> >the following templates:
> > 
> >lxc-busybox
> >lxc-download
> >lxc-local
> >lxc-oci
> > 
> 
> The templates had been in a separate "lxc-templates" package also in
> Ubuntu 16.04.
> But "lxc-templates" had been a dependency of the "lxc" package and
> was therefore dragged in automatically.
> 
> But with the change indicated in the quoted announcement, it no longer
> gets so dragged in.
> 
> But an unmentioned associated effect of not dragging in lxc-templates
> is that most of the files
> /usr/share/lxc/config/*.conf
> are no longer put in place.
> 
> So "lxc-templates" must be installed not only to use the templates
> to generate new containers.  It must be installed if you are going
> bring forward containers from Ubuntu 16.04 (lxc 2.0), which had been
> generated using templates.
> 
> "lxc-update-config" works without complaint on containers whose config
> includes, for example
> 
>lxc.include = /usr/share/lxc/config/ubuntu.common.conf
> 
> But the containers still fail afterwards because the include is not
> satisfied.  (They fail, that is, until "lxc-templates" is installed).
> 
> (Assume here that a common way of producing an upgraded host system,
> e.g. Ubuntu 18.04 versus 16.04, is to produce a new minimal 18.04
> system and then apply all recorded "apt install" commands corresponding
> to actual desired packages (yes, modifications are sometimes needed,
> but...).  The old 16.04 system need not have explicitly done "apt
> install lxc-templates" and so that could be overlooked in 18.04).
> 
> Since "lxc" is now branded as a transitional package => lxc-utils,
> could "lxc" have lxc-templates as a dependency, even though lxc-utils
> will not?
> 
> 
> Adrian Pepper
> arpep...@uwaterloo.ca
> 
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users


signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] What is the state of the art for lxd and wifi ?

[Christian Brauner]

On Mon, Jul 23, 2018 at 05:12:09PM +0700, Fajar A. Nugraha wrote:
> On Mon, Jul 23, 2018 at 5:08 PM, Pierre Couderc  wrote:
> 
> > Where can I find a howto for lxd on a an ultramobile with wifi only ?
> >
> > I find some posts aged 2014 and more modern posts saying it is not
> > possible with wifi.
> >
> > I want to install many containers accessing internet, or being acessed
> > from internet.
> >
> >
> >
> >
> 
> Relevant to all VM-like in general (including lxd, kvm and virtualbox):
> - with the default bridged setup (on lxd this is lxdbr0), VMs/containers
> can access internet
> - to make it accessible FROM internet, you need (the easy way) to setup
> port forwarding/NAT (e.g. using iptables on the host)

You could also look whether our proxy device type will help you out with
that: https://github.com/lxc/lxd/blob/master/doc/containers.md#type-proxy

Christian

> - bridges (including macvlan) does not work on wifi
> 
> -- 
> Fajar

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



signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] New and current Linux container project maintainers

[Christian Brauner]

Hey everyone,

The Linux containers project is an umbrella project which is composed of
various sub-projects. The most well-known among them currently are:
- LXC
- LXCFS
- LXD

All of these projects need to be maintained. That includes fixing bugs,
implementing new features, properly handling security issues, releasing
new versions, backporting fixes to stable branches, providing long
term support, maintaining test-suites and general infrastructure, etc.

To competently cover all of these tasks we have maintainers. Usually,
Stéphane Graber, Serge Hallyn, and myself are the ones that have the
most visibility but we are not the only ones!
Over the last weeks we added two new maintainers. We are very happy to
welcome:

1. Free Ekanayaka (@freeekanayaka on Github) as a new maintainer of LXD.
   He has mostly been working tirelessly behind the scenes on the new
   LXD clustering feature. He is the sole author of the new dqlite
   project ( https://github.com/CanonicalLtd/dqlite ) a distributed
   SQLite database. In fact, he has written the same project twice: once
   in GO and now in C to significantly increase performance. We're very
   happy to have him on board.

2. Wolfgang Bumiller(@Blub\0 on Github) as a new maintainer of LXC and
   LXCFS.
   Wolfgang has been a LXC contributor for a long term touching various
   parts of the codebase. He has added multiple new features. Recently,
   he added support for AppArmor stacking to LXC and introduced a new
   way to add custom AppArmor rules per container by introducing the
   lxc.apparmor.raw config key.
   We are usually very stingy in granting write access to low-level
   projects such as LXC and LXCFS but Wolfgang has proven himself in
   both projects as well as fixing various kernel bugs. We're very happy
   that he is on board.

In case you were wondering who currently maintains what. For LXD we have
Serge Hallyn, Christian Brauner, Stéphane Graber, Free Ekanayaka, Tycho
Andersen, and Mike Mccracken. For LXC we have Serge Hallyn, Christian
Brauner, Stéphane Graber, Dwight Engen, and Wolfgang Bumiller. And for
LXCFS Serge Hallyn, Christian Brauner, Stéphane Graber, and Wolfgang
Bumiller.

A big thank you to everyone who spends time helping maintain these
projects. All of your are doing outstanding work and your help is
greatly appreciated.

The Linux containers team


signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] "lxc list" on Linux 4.18: cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied

[Christian Brauner]

On Wed, Aug 15, 2018 at 11:49:40AM +, Tomasz Chmielewski wrote:
> # lxc list
> cannot perform readlinkat() on the mount namespace file descriptor of the
> init process: Permission denied

Where is this error coming from? It's not from LX{C,D}
What does lxc info show?

> 
> # dmesg -c
> [ 1554.529049] audit: type=1400 audit(1534333565.580:49): apparmor="DENIED"
> operation="ptrace" profile="/snap/core/5145/usr/lib/snapd/snap-confine"
> pid=2636 comm="snap-confine" requested_mask="read" denied_mask="read"
> peer="unconfined"
> 
> 
> This is after upgrading the kernel to:
> 
> # uname -a
> Linux lxd05 4.18.0-041800-generic #201808122131 SMP Sun Aug 12 21:33:20 UTC
> 2018 x86_64 x86_64 x86_64 GNU/Linux
> 
> 
> # snap list
> Name  VersionRev   Tracking  Publisher  Notes
> core  16-2.34.3  5145  stablecanonical  core
> lxd   3.38011  stablecanonical  -
> 
> 
> # cat /etc/issue
> Ubuntu 18.04.1 LTS \n \l
> 
> 
> 
> Expected?
> 
> 
> 
> Tomasz Chmielewski
> https://lxadm.com
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Unprivileged LXC - proc:mixed vs. proc:rw

[Christian Brauner]

On Thu, Aug 16, 2018 at 09:07:16PM +0200, Dr. Todor Dimitrov wrote:
> A follow-up: I assume the same applies to sys:mixed vs. sys:rw, correct?

Yes. Newever LXC versions will always set sys:rw for unpriv containers.

Christian

> 
> Todor
> 
> > On 23. May 2018, at 19:09, Christian Brauner  wrote:
> > 
> > On Wed, May 23, 2018 at 06:13:02PM +0200, Dr. Todor Dimitrov wrote:
> >> Hallo,
> >> 
> >> is there any security benefit of using proc:mixed inside an unprivileged 
> >> container? Or does proc:rw deliver the same level of isolation?
> > 
> > There's no security benefit for unprivileged containers. They can't
> > change /proc/sys and /proc/sysrq-trigger. If they can and the file isn't
> > namespaced it's a bug.
> > 
> > Christian
> > 
> >> 
> >> lxc.mount.auto = proc:mixed
> >> 
> >> vs.
> >> 
> >> lxc.mount.auto = proc:rw
> >> 
> >> Thanks in advance,
> >> Todor
> >> 
> > 
> > 
> > 
> >> ___
> >> lxc-users mailing list
> >> lxc-users@lists.linuxcontainers.org
> >> http://lists.linuxcontainers.org/listinfo/lxc-users
> > 
> > ___
> > lxc-users mailing list
> > lxc-users@lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> 



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

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

Re: [lxc-users] Containers and checkpoint/restart micro-conference at LPC2018

[Christian Brauner]

On Sat, Sep 08, 2018 at 10:41:41AM +0300, Amir Goldstein wrote:
> On Sat, Sep 8, 2018 at 8:00 AM Stéphane Graber  wrote:
> >
> > On Mon, Aug 13, 2018 at 12:10:15PM -0400, Stéphane Graber wrote:
> > > Hello,
> > >
> > > This year's edition of the Linux Plumbers Conference will once again
> > > have a containers micro-conference but this time around we'll have twice
> > > the usual amount of time and will include the content that would
> > > traditionally go into the checkpoint/restore micro-conference.
> > >
> > > LPC2018 will be held in Vancouver, Canada from the 13th to the 15th of
> > > November, co-located with the Linux Kernel Summit.
> > >
> > >
> > > We're looking for discussion topics around kernel work related to
> > > containers and namespacing, resource control, access control,
> > > checkpoint/restore of kernel structures, filesystem/mount handling for
> > > containers and any related userspace work.
> > >
> > >
> > > The format of the event will mostly be discussions where someone
> > > introduces a given topic/problem and it then gets discussed for 20-30min
> > > before moving on to something else. There will also be limited room for
> > > short demos of recent work with shorter 15min slots.
> > >
> > >
> > > Details can be found here:
> > >
> > >   
> > > https://discuss.linuxcontainers.org/t/containers-micro-conference-at-linux-plumbers-2018/2417
> > >
> > >
> > > Looking forward to seeing you in Vancouver!
> >
> > Hello,
> >
> > We've added an extra week to the CFP, new deadline is Friday 14th of 
> > September.
> >
> > If you were thinking about sending something bug then forgot or just
> > missed the deadline, now is your chance to send it!
> >
> 
> [cc: overlayfs developers]
> 
> Hi Stéphane!

Hey Amir,

I'm one of the co-organizers of the microconf.

> 
> I am not planing to travel to LPC this year, so this is more of an FYI than
> a CFP, but maybe another overlayfs developer can pick up this glove??

Sure, that would be great.

> 
> For the past two years I have participated in the effort to fix overlayfs
> "non-standard" behavior:
> https://github.com/amir73il/overlayfs/wiki/Overlayfs-non-standard-behavior

Yes, this is an issue that we were aware of for a long time and it
something that has made overlayfs somewhat more difficult to use than it
should be.

> 
> Allegedly, this effort went underway to improve the experience of overlayfs
> users, who are mostly applications running inside containers. For backward
> compatibility reasons, container runtimes will need to opt-in for fixing some
> of the legacy behavior.
> 
> In reality, I have seen very little cross list interaction between 
> linux-unionfs
> and containers mailing lists. The only interaction I recall in the
> past two years
> ended up in a fix in overlayfs to require opt-in for fixing yet another 
> backward
> compatible bad behavior, although docker did follow up shortly after to fix
> bad practice in container runtime:
> https://github.com/moby/moby/issues/34672
> 
> So the questions I would like to relay to the micro-conf participants w.r.t 
> the
> new opt-in overlayfs behavior:
> 1. Did you know?

I personally did not know about the new opt-in behavior. More reason to
give a talk! :)

> 2. Do you care?

Yes, we do care. However - speaking as LXC upstream now - we have
recently focused on getting shiftfs to work rather than overlayfs.

We are more than happy to have a overlayfs talk at the microconf. If
someone were to talk about:
- What non-standard behavior has already been fixed?
- How has it been fixed?
- What non-standard behavior still needs to be fixed?
- Outstanding problems that either still need a solution or
  are solved but one would like feedback on the implementation. This way
  we can have a good discussion.

Thanks!
Christian


signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Overlayfs @ Containers and checkpoint/restart micro-conference at LPC2018

[Christian Brauner]

On Sun, Sep 09, 2018 at 09:31:02AM +0300, Amir Goldstein wrote:
> On Sun, Sep 9, 2018 at 4:31 AM Christian Brauner  wrote:
> >
> ...
> > > [cc: overlayfs developers]
> > >
> > > Hi Stéphane!
> >
> > Hey Amir,
> >
> > I'm one of the co-organizers of the microconf.
> >
> > >
> > > I am not planing to travel to LPC this year, so this is more of an FYI 
> > > than
> > > a CFP, but maybe another overlayfs developer can pick up this glove??
> >
> > Sure, that would be great.
> >
> > >
> > > For the past two years I have participated in the effort to fix overlayfs
> > > "non-standard" behavior:
> > > https://github.com/amir73il/overlayfs/wiki/Overlayfs-non-standard-behavior
> >
> > Yes, this is an issue that we were aware of for a long time and it
> > something that has made overlayfs somewhat more difficult to use than it
> > should be.
> >
> > >
> > > Allegedly, this effort went underway to improve the experience of 
> > > overlayfs
> > > users, who are mostly applications running inside containers. For backward
> > > compatibility reasons, container runtimes will need to opt-in for fixing 
> > > some
> > > of the legacy behavior.
> > >
> > > In reality, I have seen very little cross list interaction between 
> > > linux-unionfs
> > > and containers mailing lists. The only interaction I recall in the
> > > past two years
> > > ended up in a fix in overlayfs to require opt-in for fixing yet another 
> > > backward
> > > compatible bad behavior, although docker did follow up shortly after to 
> > > fix
> > > bad practice in container runtime:
> > > https://github.com/moby/moby/issues/34672
> > >
> > > So the questions I would like to relay to the micro-conf participants 
> > > w.r.t the
> > > new opt-in overlayfs behavior:
> > > 1. Did you know?
> >
> > I personally did not know about the new opt-in behavior. More reason to
> > give a talk! :)
> >
> > > 2. Do you care?
> >
> > Yes, we do care. However - speaking as LXC upstream now - we have
> > recently focused on getting shiftfs to work rather than overlayfs.
> >
> 
> IMO, as I expressed it in the past, the fact that shiftfs development is not
> collaborated with overlayfs developers is a pitty.
> Yes shiftfs has a different purpose than overlayfs, but they have common
> use cases and common problems as well.

My team hast just started to be more involved with shifts development a
few months back. Overlayfs is definitely an inspiration and we even once
thought about making shifts an extension of overlayfs.
Seth Forshee on my team is currently actively working on shifts and
getting a POC ready.
When he has a POC based on James' patchset there will be an RFC that
will go to fsdevel and all parties of interest.
There will also be an update on shifts development during the microconf.
So even more reason for developers from overlayfs to stop by.

> 
> > We are more than happy to have a overlayfs talk at the microconf. If
> > someone were to talk about:
> > - What non-standard behavior has already been fixed?
> > - How has it been fixed?
> 
> IMO, those questions are covered quite well by the wiki and overlayfs.txt
> documentation in kernel tree.

It's still worth bringing this in front of other developers in the form
of a talk.

> 
> > - What non-standard behavior still needs to be fixed?
> 
> There's the mmap MAP_SHARED case covered in the wiki
> and there may be other small stuff, but not sure if anyone cares
> about them, so the question should really be directed back to the audience...

The audience that cares enough to send patches for it will likely be at
the microconf so it's a good place to discuss it.

> 
> > - Outstanding problems that either still need a solution or
> >   are solved but one would like feedback on the implementation. This way
> >   we can have a good discussion.
> >
> 
> I think one of the chsallange that distros and container runtime will need to
> deal with is managing format versions of overlay "images".
> The reason the new features require user or distro to opt-in is because
> the new features create overlayfs images that are not fully compatible with 
> old
> kernels and existing container image tools (i.e. export/migrate image).

As I said we will be very thankful for any talk about such problems.

Thanks!
Christian

> 
> The new overlayfs-progs project by Zhangyi is going to help in that respect:
> https://github.com/hisilicon/overlayfs-progs
> As well as Zhangyi's work on overlayfs feature set support:
> https://marc.info/?l=linux-unionfs&m=153302911328159&w=2
> 
> Thanks,
> Amir.


signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Failed to reset devices.list (etc)

[Christian Brauner]

On Mon, Sep 10, 2018 at 01:30:42AM +1200, Richard Hector wrote:
> Hi all,
> 
> I have messages like this in the logs on several of my (lxc, not lxd)
> containers:
> 
> systemd[1]: phpsessionclean.service: Failed to reset devices.list:
> Operation not permitted
> 
> systemd[1]: run-user-1000.mount: Failed to reset devices.list: Operation
> not permitted
> 
> systemd[1]: apt-daily.service: Failed to reset devices.list: Operation
> not permitted
> 
> systemd[1]: Failed to reset devices.list on
> /system.slice/systemd-tmpfiles-clean.service: Operation not permitted
> 
> systemd[1]: Failed to reset devices.list on
> /system.slice/apt-daily.service: Operation not permitted
> 
> Host is debian stretch, guests are a mix of debian and ubuntu.
> 
> Searching the web finds various results of various ages; some claim to
> be fixed, others not.
> 
> Some claim it's an issue with unprivileged containers only, but AFAIK
> I'm using privileged containers only (how do I tell?)
> 
> What I can't find is:
> 
> What is devices.list, what specifically (in each case) wants to reset
> it, and why?
> 
> Can and should I stop it, and how?

No need to stop it. systemd will simply gracefully move one but report
an error. The devices.list regulates to what devices a privileged
container can have access to. The container not being able to mess with
it is very mucht wanted for security reasons. There's no way to stop it
from LXC's side. If you really care about this you could probably
disable all services that try to touch it. But it's really not needed.

Christian

> 
> There are some references to setting "PrivateNetwork=false" in the
> service file (for the phpsessionclean one, at least) - but that didn't
> seem to have any effect.
> 
> Any tips?
> 
> Thanks,
> Richard
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users


signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Failed to reset devices.list (etc)

[Christian Brauner]

On Mon, Sep 10, 2018 at 01:54:21AM +1200, Richard Hector wrote:
> On 10/09/18 01:40, Christian Brauner wrote:
> > On Mon, Sep 10, 2018 at 01:30:42AM +1200, Richard Hector wrote:
> >> Hi all,
> >>
> >> I have messages like this in the logs on several of my (lxc, not lxd)
> >> containers:
> >>
> >> systemd[1]: phpsessionclean.service: Failed to reset devices.list:
> >> Operation not permitted
> >>
> >> systemd[1]: run-user-1000.mount: Failed to reset devices.list: Operation
> >> not permitted
> >>
> >> systemd[1]: apt-daily.service: Failed to reset devices.list: Operation
> >> not permitted
> >>
> >> systemd[1]: Failed to reset devices.list on
> >> /system.slice/systemd-tmpfiles-clean.service: Operation not permitted
> >>
> >> systemd[1]: Failed to reset devices.list on
> >> /system.slice/apt-daily.service: Operation not permitted
> >>
> >> Host is debian stretch, guests are a mix of debian and ubuntu.
> >>
> >> Searching the web finds various results of various ages; some claim to
> >> be fixed, others not.
> >>
> >> Some claim it's an issue with unprivileged containers only, but AFAIK
> >> I'm using privileged containers only (how do I tell?)
> >>
> >> What I can't find is:
> >>
> >> What is devices.list, what specifically (in each case) wants to reset
> >> it, and why?
> >>
> >> Can and should I stop it, and how?
> > 
> > No need to stop it. systemd will simply gracefully move one but report
> > an error. The devices.list regulates to what devices a privileged
> > container can have access to. The container not being able to mess with
> > it is very mucht wanted for security reasons. There's no way to stop it
> > from LXC's side. If you really care about this you could probably
> > disable all services that try to touch it. But it's really not needed.
> 
> 
> Thanks Christian,
> 
> So my understanding is: The systemd service file tries to restrict what
> the service can access, for security, by altering the devices.list
> 
> The container won't let anything mess with devices.list, for security.
> 
> The two can't both happen at the same time.

Yes.

> 
> Is that about right?
> 
> Is it not possible to say "you can make it tighter, but not looser"?

Yes.

> 
> I guess I just add it to my logcheck ignores and carry on?

Yes.

:)
Christian

> 
> Thanks,
> 
> Richard
> 
> > Christian
> > 
> >>
> >> There are some references to setting "PrivateNetwork=false" in the
> >> service file (for the phpsessionclean one, at least) - but that didn't
> >> seem to have any effect.
> >>
> >> Any tips?
> >>
> >> Thanks,
> >> Richard
> >> ___
> >> lxc-users mailing list
> >> lxc-users@lists.linuxcontainers.org
> >> http://lists.linuxcontainers.org/listinfo/lxc-users
> >>
> >>
> >> ___
> >> lxc-users mailing list
> >> lxc-users@lists.linuxcontainers.org
> >> http://lists.linuxcontainers.org/listinfo/lxc-users
> 
> 




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



signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] How to recover from ERROR state

[Christian Brauner]

> Kees Bakker  hat am 11. September 2018 um 15:13 geschrieben:
> 
> 
> Hey,
> 
> Every now and then we have one or more containers in state ERROR.
> Is there a clever method to recover from that, other than
> rebooting the LXD server?
> 
> Killing the monitor and the forkstart does help. And also a kworker
> process (kworker/u16:0) is eating up one of the CPUs with 100% load.
> lxc info gives "error: Monitor is hung"

If I'm not mistaken this is usually caused by a hanging lxc-monitord
process which older LXC versions still use and which is removed in 
newer LXC versions.
Can you check whether you see a lxc-monitord process when such a hang
happens. If so, kill it. Afterwards things should work fine again.

> 
> I'm running Ubuntu 16.04 with BTRFS. The kernel is 4.15.0-33-generic


Cc stgraber since I don't have in mind what LXC version is used
and if it is one that has already gotten rid of lxc-monitord.

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