[lxc-users] Autostart Unpriviledged Containers
Fajar A. Nugraha
list at fajar.net
Sat Oct 10 17:24:04 UTC 2015
On Sat, Oct 10, 2015 at 11:48 PM, Paul Jones <spacefreak18 at gmail.com> 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
- 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
Ah, debian vs ubuntu :)
> 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):
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
cgm movepidabs all /test $$
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.
More information about the lxc-users