On 30 April 2018 at 15:56, Daniel Walsh <dwalsh@xxxxxxxxxx> wrote: > On 04/30/2018 10:42 AM, James Hogarth wrote: >> >> On 27 April 2018 at 17:47, Pavel Raiskup <praiskup@xxxxxxxxxx> wrote: >>> >>> On Friday, April 27, 2018 5:41:19 PM CEST Lennart Poettering wrote: >>>> >>>> On Fr, 27.04.18 17:27, Pavel Raiskup (praiskup@xxxxxxxxxx) wrote: >>>> >>>>> Hi all, >>>>> >>>>> just wanted to let you know about trivial experiment [1] with systemd >>>>> in >>>>> container. Non-privileged systemd can now pretty fine run in docker >>>>> container (tested on Fedora 27 box). >>>> >>>> Hmm, IIRC there were at least two isues still, did they get resolved? >>>> Specifically: >>>> >>>> 1. docker fakes a /dev/console that doesn't behave like a console >>>> usually works, i.e. if a hangup is seen on it then it will destroy >>>> the pty behind it, instead of keeping it around... >>> >>> There't toy work-around to have at least something: >>> >>> https://github.com/praiskup/systemd-container/blob/master/fedora-rawhide-x86_64/systemd >>> >>> Pavel >>> >>>> 2. docker sends SIGTERM to the container's PID 1 when it wants it to >>>> go down even though SIGTERM to PID 1 on SysV systems generally >>>> means "please reexecute", and not "please shut down". >>>> >>>> What's the current state on that? >>>> >> Did a bunch of related activities at my work recently ... >> >> If you are using Red Hat docker (eg from the RHEL/CentOS extras repo) >> then this will get a systemd container running for you: >> >> Dockerfile: >> FROM centos:7 >> ENV container docker >> STOPSIGNAL SIGRTMIN+3 >> ENTRYPOINT ["/sbin/init"] >> RUN yum -y update && yum clean all >> >> Run statement: >> docker run -dt --name mycontainer mysystemdimage >> >> If you are using upstream docker then you need to do the following: >> mkdir /etc/docker >> echo '{"seccomp-profile": "/etc/docker/seccomp.json"}' > >> /etc/docker/daemon.json >> wget -O /etc/docker/seccomp.json >> https://src.fedoraproject.org/rpms/docker/raw/master/f/seccomp.json >> >> Same dockerfile >> >> Run statement: >> docker run -dt --tmpfs /tmp:exec --tmpfs /run -v >> /sys/fs/cgroup:/sys/fs/cgroup:ro --name mycontainer mysystemdimage >> >> _______________________ >> >> The real problem here is docker engines you don't control as the >> seccomp filter is a potential blocker and potentially the run mount >> options >> _______________________________________________ >> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > > Perhaps it is time to update my blog on running systemd in a unprivileged > container. > Not a bad idea ... Oh and for reference the above blurb was mostly based on work we did in the atomic/cloud/something working group around a year ago https://pagure.io/atomic-wg/issue/233 https://fedoraproject.org/wiki/Container:Guidelines#systemd_Containers The exec was added to /tmp since (at least upstream) docker mounts --tmpfs as noexec and that upsets some applications (especially some java bits) and if it wasn't clear by "Red Hat docker" that includes the docker engine shipped in Fedora, not just in EL7. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
