[lxc-users] Autostart Unpriviledged Containers
Hi. I'm using Debian Stretch. And I would like to use unpriviledged containers. It seems by default, there is one cgroup owned by root. In order to start an unpriviledged container I need to create a new cgroup, chown it to the unpriviledged user and then move the current tty process into that cgroup. Then start the container from there. If this is the case, how will it be possible to autostart containers on boot? Or am I going about this all wrong? ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Autostart Unpriviledged Containers
Le 06/10/2015 06:03, Paul Jones a écrit : Hi. I'm using Debian Stretch. And I would like to use unpriviledged containers. It seems by default, there is one cgroup owned by root. In order to start an unpriviledged container I need to create a new cgroup, chown it to the unpriviledged user and then move the current tty process into that cgroup. Then start the container from there. If this is the case, how will it be possible to autostart containers on boot? Or am I going about this all wrong? Hi Paul, to start an unprivileged container on boot, you run some steps similar to what you describe but in a script that you call through a systemd service. Here are the step i do: - set clone_children to 1 - create a dedicated cgroup and give it to my user - start the container Xavier ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Autostart Unpriviledged Containers
I have tried this but for some reason I am having trouble. I have pastebins for my systemd unit file and the bash script it calls. http://pastebin.com/FLtLWaih http://pastebin.com/b9qM2a9J It appears as though it succesfully creates the cgroup "me", i see it, and i own it and have seemingly correct permission to it. But as my normal user I cannot move the current tty to that cgroup. I cannot even do it as root! On Tue, Oct 6, 2015 at 1:14 AM, Xavier Gendre wrote: > Le 06/10/2015 06:03, Paul Jones a écrit : > >> Hi. >> >> I'm using Debian Stretch. And I would like to use unpriviledged >> containers. >> >> It seems by default, there is one cgroup owned by root. In order to >> start an unpriviledged container I need to create a new cgroup, chown it >> to the unpriviledged user and then move the current tty process into >> that cgroup. Then start the container from there. >> >> If this is the case, how will it be possible to autostart containers on >> boot? >> >> Or am I going about this all wrong? >> > > Hi Paul, > > to start an unprivileged container on boot, you run some steps similar to > what you describe but in a script that you call through a systemd service. > > Here are the step i do: > - set clone_children to 1 > - create a dedicated cgroup and give it to my user > - start the container > > Xavier > ___ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users -- Time To Get an EKG, G! ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Autostart Unpriviledged Containers
On Fri, Oct 9, 2015 at 7:19 AM, Paul Jones wrote: > I have tried this but for some reason I am having trouble. > > I have pastebins for my systemd unit file and the bash script it calls. > http://pastebin.com/FLtLWaih > http://pastebin.com/b9qM2a9J > > It appears as though it succesfully creates the cgroup "me", i see it, and i > own it and have seemingly correct permission to it. But as my normal user I > cannot move the current tty to that cgroup. I cannot even do it as root! Try this: (1) on top of /etc/sudoers: Defaultsuse_pty Short version: with this, sudo will create new pty owned by the user. Needed if you intend to run "screen" (or other stuff which needs user-owned tty). Not needed if you only need to run "lxc-attach" or "lxc-console". (2) at the bottom of /etc/pam.d/sudo sessionoptional pam_loginuid.so sessionoptional pam_systemd.so Short version: make pam_systemd create and use new cgroup owned by the user when you run "sudo". With this, you can use "sudo" for "lxc-autostart". (3) on your script ("paul" is your username, right?) /usr/bin/sudo -u paul -i -- /usr/bin/lxc-autostart -- Fajar ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Autostart Unpriviledged Containers
I would also like to note that when I run the script I created through the bash interpreter from tty it works just fine. Exactly as intended. I can then switch back to my user and move the tty to my new cgroup. The only time it doesn't work is when I attempt to call it from the systemd unit. It says i own the cgroup, but it is almost like I do not. Very weird. I can use sudo, but it isn't my preferred method. Also it has the same issue if I try to run it via the systemd unit. On Fri, Oct 9, 2015 at 2:18 AM, Fajar A. Nugraha wrote: > On Fri, Oct 9, 2015 at 7:19 AM, Paul Jones wrote: > > I have tried this but for some reason I am having trouble. > > > > I have pastebins for my systemd unit file and the bash script it calls. > > http://pastebin.com/FLtLWaih > > http://pastebin.com/b9qM2a9J > > > > It appears as though it succesfully creates the cgroup "me", i see it, > and i > > own it and have seemingly correct permission to it. But as my normal > user I > > cannot move the current tty to that cgroup. I cannot even do it as root! > > > Try this: > > (1) on top of /etc/sudoers: > Defaultsuse_pty > > Short version: with this, sudo will create new pty owned by the user. > Needed if you intend to run "screen" (or other stuff which needs > user-owned tty). Not needed if you only need to run "lxc-attach" or > "lxc-console". > > (2) at the bottom of /etc/pam.d/sudo > sessionoptional pam_loginuid.so > sessionoptional pam_systemd.so > > Short version: make pam_systemd create and use new cgroup owned by the > user when you run "sudo". With this, you can use "sudo" for > "lxc-autostart". > > (3) on your script ("paul" is your username, right?) > /usr/bin/sudo -u paul -i -- /usr/bin/lxc-autostart > > -- > Fajar > ___ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users > -- Time To Get an EKG, G! ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Autostart Unpriviledged Containers
This one was a pain in the a$$ Apparently newer systemd is picky, saying "Cannot create session: Already running in a session" if it already runs in a session (e.g. root's session). Latest systemd have "machinectl shell" (https://github.com/systemd/systemd/pull/1022) which should eliminate the need to abuse sudo. However it's not in ubuntu/debian yet, so a workaround is needed. Here's what I did on Ubuntu Wily: (1) on top of /etc/sudoers: Defaultsuse_pty (2) at the bottom of /etc/pam.d/sudo sessionoptional pam_loginuid.so sessionoptional pam_systemd.so (3) Make SURE libpam-systemd is installed (e,g "dpkg -l") (4) Test # bash -c 'cgm movepidabs all / $$ && sudo -u user -i cat /proc/self/cgroup' Note the single quote, and "cgm movepidabs" command. That's the workaround. It should print something like 10:hugetlb:/user.slice/user-1000.slice/session-47.scope ... 1:name=systemd:/user.slice/user-1000.slice/session-47.scope The main thing is "user.slice/user-UID.slice". If you don't see your "normal", non-0 uid there, recheck steps 1-3. See /var/log/auth.log for possible problems. (5) create /etc/systemd/system/lxc-autostart-user.service, Note that you do NOT want RemainAfterExit=yes [Unit] Description=Autostart "user" containers [Service] Type=oneshot ExecStart=/opt/lxc/autostart-user RemainAfterExit=yes [Install] WantedBy=multi-user.target (6) Create /opt/lxc/autostart-user, then make it executable (e.g. chmod 700) #!/bin/bash export PATH=/usr/sbin:/usr/bin:/sbin:/bin cgm movepidabs all / $$ sudo -u user -i -- bash -c "lxc-autostart;lxc-ls -f" (7) Enable and test with systemd # systemctl daemon-reload # systemctl enable lxc-autostart-user # systemctl start lxc-autostart-user # systemctl status lxc-autostart-user If all works well, you should see something like this: root@wily:~# systemctl status lxc-autostart-user ● lxc-autostart-user.service - Autostart "user" containers Loaded: loaded (/etc/systemd/system/lxc-autostart-user.service; enabled; vendor preset: enabled) Active: inactive (dead) since Sat 2015-10-10 13:02:55 WIB; 1s ago Process: 21146 ExecStart=/opt/lxc/autostart-user (code=exited, status=0/SUCCESS) Main PID: 21146 (code=exited, status=0/SUCCESS) Oct 10 13:02:54 wily systemd[1]: Starting Autostart "user" containers... Oct 10 13:02:55 wily autostart-user[21146]: NAMESTATEIPV4 IPV6 GROUPS AUTOSTART Oct 10 13:02:55 wily autostart-user[21146]: -- Oct 10 13:02:55 wily autostart-user[21146]: trusty RUNNING - - - YES Oct 10 13:02:55 wily systemd[1]: Started Autostart "user" containers. -- Fajar On Sat, Oct 10, 2015 at 4:20 AM, Paul Jones wrote: > I would also like to note that when I run the script I created through the > bash interpreter from tty it works just fine. Exactly as intended. I can > then switch back to my user and move the tty to my new cgroup. > > The only time it doesn't work is when I attempt to call it from the systemd > unit. > > It says i own the cgroup, but it is almost like I do not. Very weird. > > I can use sudo, but it isn't my preferred method. Also it has the same issue > if I try to run it via the systemd unit. > > On Fri, Oct 9, 2015 at 2:18 AM, Fajar A. Nugraha wrote: >> >> On Fri, Oct 9, 2015 at 7:19 AM, Paul Jones wrote: >> > I have tried this but for some reason I am having trouble. >> > >> > I have pastebins for my systemd unit file and the bash script it calls. >> > http://pastebin.com/FLtLWaih >> > http://pastebin.com/b9qM2a9J >> > >> > It appears as though it succesfully creates the cgroup "me", i see it, >> > and i >> > own it and have seemingly correct permission to it. But as my normal >> > user I >> > cannot move the current tty to that cgroup. I cannot even do it as root! >> >> >> Try this: >> >> (1) on top of /etc/sudoers: >> Defaultsuse_pty >> >> Short version: with this, sudo will create new pty owned by the user. >> Needed if you intend to run "screen" (or other stuff which needs >> user-owned tty). Not needed if you only need to run "lxc-attach" or >> "lxc-console". >> >> (2) at the bottom of /etc/pam.d/sudo >> sessionoptional pam_loginuid.so >> sessionoptional pam_systemd.so >> >> Short version: make pam_systemd create and use new cgroup owned by the >> user when you run "sudo". With this, you can use "sudo" for >> "lxc-autostart". >> >> (3) on your script ("paul" is your username, right?) >> /usr/bin/sudo -u paul -i -- /usr/bin/lxc-autostart >> >> -- >> Fajar >> ___ >> lxc-users mailing list >> lxc-users@lists.linuxcontainers.org >> http://lists.linuxcontainers.org/listinfo/lxc-users > > > > > -- > Time To Get an EKG, G! > > ___ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users ___ lxc-users mailing list lxc-users@lists
Re: [lxc-users] Autostart Unpriviledged Containers
Thanks for you answers Fajar. The technology is still in it's infancy, so I'm not surprised with the need to abuse sudo in this manner, and am willing to work around it. But i'm not sure I completely follow what you are saying. I get the error that you are mentioning from systemd, where it is already running in a session. But i can also start the service after boot manually and not get that error, and it will create the cgroup, but as usual, i cannot as normal user move a process to that cgroup, it get an invalid request error. And I can follow your steps 1-3 already. My questions are on step 4. My output looks nothing like yours and I do not understand why you're moving the current tty into the / cgroup which is where it already resides? My output looks like this: root@ZitZ:/home/paul# bash -c 'cgm movepidabs all / $$ && sudo -u paul -i cat /proc/self/cgroup' 9:perf_event:/ 8:memory:/ 7:cpuset:/ 6:devices:/ 5:blkio:/ 4:cpu,cpuacct:/ 3:freezer:/ 2:net_cls,net_prio:/ 1:name=systemd:/ On Sat, Oct 10, 2015 at 2:14 AM, Fajar A. Nugraha wrote: > This one was a pain in the a$$ > > Apparently newer systemd is picky, saying "Cannot create session: > Already running in a session" if it already runs in a session (e.g. > root's session). Latest systemd have "machinectl shell" > (https://github.com/systemd/systemd/pull/1022) which should eliminate > the need to abuse sudo. However it's not in ubuntu/debian yet, so a > workaround is needed. > > Here's what I did on Ubuntu Wily: > > (1) on top of /etc/sudoers: > Defaultsuse_pty > > (2) at the bottom of /etc/pam.d/sudo > sessionoptional pam_loginuid.so > sessionoptional pam_systemd.so > > (3) Make SURE libpam-systemd is installed (e,g "dpkg -l") > > (4) Test > # bash -c 'cgm movepidabs all / $$ && sudo -u user -i cat > /proc/self/cgroup' > > Note the single quote, and "cgm movepidabs" command. That's the > workaround. It should print something like > > 10:hugetlb:/user.slice/user-1000.slice/session-47.scope > ... > 1:name=systemd:/user.slice/user-1000.slice/session-47.scope > > The main thing is "user.slice/user-UID.slice". If you don't see your > "normal", non-0 uid there, recheck steps 1-3. See /var/log/auth.log > for possible problems. > > (5) create /etc/systemd/system/lxc-autostart-user.service, Note that > you do NOT want RemainAfterExit=yes > > [Unit] > Description=Autostart "user" containers > > [Service] > Type=oneshot > ExecStart=/opt/lxc/autostart-user > RemainAfterExit=yes > > [Install] > WantedBy=multi-user.target > > (6) Create /opt/lxc/autostart-user, then make it executable (e.g. chmod > 700) > #!/bin/bash > export PATH=/usr/sbin:/usr/bin:/sbin:/bin > cgm movepidabs all / $$ > sudo -u user -i -- bash -c "lxc-autostart;lxc-ls -f" > > (7) Enable and test with systemd > # systemctl daemon-reload > # systemctl enable lxc-autostart-user > # systemctl start lxc-autostart-user > # systemctl status lxc-autostart-user > > If all works well, you should see something like this: > root@wily:~# systemctl status lxc-autostart-user > ● lxc-autostart-user.service - Autostart "user" containers >Loaded: loaded (/etc/systemd/system/lxc-autostart-user.service; > enabled; vendor preset: enabled) >Active: inactive (dead) since Sat 2015-10-10 13:02:55 WIB; 1s ago > Process: 21146 ExecStart=/opt/lxc/autostart-user (code=exited, > status=0/SUCCESS) > Main PID: 21146 (code=exited, status=0/SUCCESS) > > Oct 10 13:02:54 wily systemd[1]: Starting Autostart "user" containers... > Oct 10 13:02:55 wily autostart-user[21146]: NAMESTATEIPV4 > IPV6 GROUPS AUTOSTART > Oct 10 13:02:55 wily autostart-user[21146]: > -- > Oct 10 13:02:55 wily autostart-user[21146]: trusty RUNNING - - > - YES > Oct 10 13:02:55 wily systemd[1]: Started Autostart "user" containers. > > -- > Fajar > > On Sat, Oct 10, 2015 at 4:20 AM, Paul Jones > wrote: > > I would also like to note that when I run the script I created through > the > > bash interpreter from tty it works just fine. Exactly as intended. I can > > then switch back to my user and move the tty to my new cgroup. > > > > The only time it doesn't work is when I attempt to call it from the > systemd > > unit. > > > > It says i own the cgroup, but it is almost like I do not. Very weird. > > > > I can use sudo, but it isn't my preferred method. Also it has the same > issue > > if I try to run it via the systemd unit. > > > > On Fri, Oct 9, 2015 at 2:18 AM, Fajar A. Nugraha wrote: > >> > >> On Fri, Oct 9, 2015 at 7:19 AM, Paul Jones > wrote: > >> > I have tried this but for some reason I am having trouble. > >> > > >> > I have pastebins for my systemd unit file and the bash script it > calls. > >> > http://pastebin.com/FLtLWaih > >> > http://pastebin.com/b9qM2a9J > >> > > >> > It appears as though it succesfully creates the cgroup "me", i see it, > >> > and i > >> > own it and have seemingly correct permission to it. But as my normal > >> > user
Re: [lxc-users] Autostart Unpriviledged Containers
On Sat, Oct 10, 2015 at 9:52 PM, Paul Jones wrote: > Thanks for you answers Fajar. The technology is still in it's infancy, so > I'm not surprised with the need to abuse sudo in this manner, and am willing > to work around it. If everything you tested fail, the sure-fire workaround would be just to setup passwordless key-based ssh authentication for your user, so you can do something like ssh user@localhost lxc-autostart > > But i'm not sure I completely follow what you are saying. I get the error > that you are mentioning from systemd, where it is already running in a > session. But i can also start the service after boot manually and not get > that error, and it will create the cgroup, but as usual, i cannot as normal > user move a process to that cgroup, it get an invalid request error. > You don't move your process as a normal user. You get root to create a cgroup for you (including the correct permission), and use that (possibly creating a cgroup under that). The easiest way would be to abuse pam_systemd, which creates /user.slice/user-X.slice/session-N.scope , where X is uid and N is session identifier. > And I can follow your steps 1-3 already. > > My questions are on step 4. My output looks nothing like yours and I do not > understand why you're moving the current tty into the / cgroup which is > where it already resides? > Does it already reside there? I haven't tested what cgroup systemd services are put in by default, but my guess is it's NOT "/". And when you login as root, you should be on /user.slice/user-0.slice/session-N.scope cgroup, and pam_systemd will refuse to create a new cgroup for the normal user if you're already in a user session (including root's session) > My output looks like this: > > root@ZitZ:/home/paul# bash -c 'cgm movepidabs all / $$ && sudo -u paul -i > cat /proc/self/cgroup' > 9:perf_event:/ > 8:memory:/ > 7:cpuset:/ > 6:devices:/ > 5:blkio:/ > 4:cpu,cpuacct:/ > 3:freezer:/ > 2:net_cls,net_prio:/ > 1:name=systemd:/ Then pam_systemd doesn't work. What's in /var/log/auth.log when you execute the above command? Did you forget to add entry for pam_loginuid before pam_systemd? What does "cat /proc/self/cgroup" say when you login as user "paul", either with ssh or from console? Again, the goal is NOT to create a new cgroup that a normal user can "move" into. Rather, it's to create the SAME cgroup setting that you get when you LOGIN from ssh/console, where you're already assigned to a cgroup that you can control, and where a normal user can start an unprivileged container. -- Fajar ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Autostart Unpriviledged Containers
The error i see in auth.log is that i'm already in a session and it cannot start a session for user paul. I do believe i setup /etc/pam.d/sudo properly. paul ~ 12:40:07 $ cat /proc/self/cgroup 9:perf_event:/ 8:memory:/ 7:cpuset:/ 6:devices:/user.slice 5:blkio:/ 4:cpu,cpuacct:/ 3:freezer:/ 2:net_cls,net_prio:/ 1:name=systemd:/user.slice/user-1000.slice/session-6.scope Why isn't it as simple as moving into this cgroup or changing its settings? On Sat, Oct 10, 2015 at 12:19 PM, Fajar A. Nugraha wrote: > On Sat, Oct 10, 2015 at 9:52 PM, Paul Jones > wrote: > > Thanks for you answers Fajar. The technology is still in it's infancy, so > > I'm not surprised with the need to abuse sudo in this manner, and am > willing > > to work around it. > > If everything you tested fail, the sure-fire workaround would be just > to setup passwordless key-based ssh authentication for your user, so > you can do something like > > ssh user@localhost lxc-autostart > > > > > But i'm not sure I completely follow what you are saying. I get the error > > that you are mentioning from systemd, where it is already running in a > > session. But i can also start the service after boot manually and not get > > that error, and it will create the cgroup, but as usual, i cannot as > normal > > user move a process to that cgroup, it get an invalid request error. > > > > You don't move your process as a normal user. You get root to create a > cgroup for you (including the correct permission), and use that > (possibly creating a cgroup under that). The easiest way would be to > abuse pam_systemd, which creates > /user.slice/user-X.slice/session-N.scope , where X is uid and N is > session identifier. > > > > And I can follow your steps 1-3 already. > > > > My questions are on step 4. My output looks nothing like yours and I do > not > > understand why you're moving the current tty into the / cgroup which is > > where it already resides? > > > > Does it already reside there? > > I haven't tested what cgroup systemd services are put in by default, > but my guess is it's NOT "/". > > And when you login as root, you should be on > /user.slice/user-0.slice/session-N.scope cgroup, and pam_systemd will > refuse to create a new cgroup for the normal user if you're already in > a user session (including root's session) > > > > My output looks like this: > > > > root@ZitZ:/home/paul# bash -c 'cgm movepidabs all / $$ && sudo -u paul > -i > > cat /proc/self/cgroup' > > 9:perf_event:/ > > 8:memory:/ > > 7:cpuset:/ > > 6:devices:/ > > 5:blkio:/ > > 4:cpu,cpuacct:/ > > 3:freezer:/ > > 2:net_cls,net_prio:/ > > 1:name=systemd:/ > > Then pam_systemd doesn't work. > What's in /var/log/auth.log when you execute the above command? > Did you forget to add entry for pam_loginuid before pam_systemd? > What does "cat /proc/self/cgroup" say when you login as user "paul", > either with ssh or from console? > > Again, the goal is NOT to create a new cgroup that a normal user can > "move" into. > Rather, it's to create the SAME cgroup setting that you get when you > LOGIN from ssh/console, where you're already assigned to a cgroup that > you can control, and where a normal user can start an unprivileged > container. > > -- > Fajar > ___ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users > -- Time To Get an EKG, G! ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Autostart Unpriviledged Containers
On Sat, Oct 10, 2015 at 11:48 PM, Paul Jones wrote: > The error i see in auth.log is that i'm already in a session and it cannot > start a session for user paul. That should not be the case IF you're on "/" cgroup. To make sure, can you try: - login as root, run sudo, while on another terminal do tail -f /var/log/auth.log - as root, cgm movepidabs, THEN run sude, while still looking at the logs The output SHOULD be different, with the second one being able to create cgroups > I do believe i setup /etc/pam.d/sudo properly. > > paul ~ 12:40:07 $ cat /proc/self/cgroup > 9:perf_event:/ > 8:memory:/ > 7:cpuset:/ > 6:devices:/user.slice > 5:blkio:/ > 4:cpu,cpuacct:/ > 3:freezer:/ > 2:net_cls,net_prio:/ > 1:name=systemd:/user.slice/user-1000.slice/session-6.scope > Ah, debian vs ubuntu :) See http://changelogs.ubuntu.com/changelogs/pool/main/s/systemd/systemd_225-1ubuntu7/changelog, search "1346734" > Why isn't it as simple as moving into this cgroup or changing its settings? In theory, it should be as simple as that. So IF when you login using ssh you only get a separate systemd cgroup (while all others are still on "/" cgroup) AND you can succesfully run unprivileged containers from that ssh session, THEN you only need to create a similar situation. I'm not sure why you said "as my normal user I cannot move the current tty to that cgroup". It should work. Here's what I tested (from shell, not from systemd script): as root: cgm movepidabs all / $$ <== You MUST do this first, since at least systemd cgroup is NOT on "/". And from my tests you can only create a new cgroup under your current one. cgm create all test cgm chown all test 1000 1000 <== MUST use uid and gid here, NOT user/group name ls -la /sys/fs/cgroup/systemd/test/ <== The directory, and at least the "tasks" file, should now be owned by your user as user: cgm movepidabs all /test $$ cat /proc/self/cgroup You should now see everything under "/test" cgroup, and you SHOULD be able to start unprivileged container from there. The way I see it, you have several options: (1) continue your previous attempt to create cgroups manually, but do it like I did above. OR (2) use passwordless ssh method (assuming you CAN, as a normal user, run lxc-autostart from a normal ssh session). OR (3) port ubuntu's changes (at least systemd, and probably even cgmanager, lxcfs, and lxc-1.1.4 if you want to run systemd containers) to debian, and go sudo and pam_systemd way. OR (4) switch to ubuntu Of the above, (2) should be easiest if you want to stick with debian. If it were me though, I'd go with (4), using ubuntu trusty for HOST (and call my script from an upstart job, or even rc.local) which is already capable of starting systemd-based containers (when combined with ppa:ubuntu-lxc/lxc-stable), and only switch to next LTS next April if I want a systemd-based host. -- Fajar ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users