Re: systemd in non-privileged container
On Mon, Apr 30, 2018 at 10:56:10AM -0400, Daniel Walsh wrote: > > Perhaps it is time to update my blog on running systemd in a unprivileged > container. Let's get the base images fixed so that at least that ENV container ... is there by default, to minimize the number of steps that are needed. -- Jan Pazdziora | adelton at #aos*, #brno Sr. Principal Software Engineer, OpenShift Security Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: systemd in non-privileged container
On Fri, Apr 27, 2018 at 05:27:19PM +0200, Pavel Raiskup 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). > > Could we support this under fedora-kickstarts, or as a layered image? > > [1] https://github.com/praiskup/systemd-container The pull request https://github.com/fedora-cloud/docker-brew-fedora/pull/45 to add the container environment variable to Fedora based images was merged many month ago but it does not seem to have affected the images that get built. Does anyone have any idea what is the based container image build process these days and in which repository we need to do the same change to have the environment variable set by default? -- Jan Pazdziora Senior Principal Software Engineer, OpenShift Security Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: systemd in non-privileged container
On 30 April 2018 at 15:56, Daniel Walsh wrote:
> On 04/30/2018 10:42 AM, James Hogarth wrote:
>>
>> On 27 April 2018 at 17:47, Pavel Raiskup wrote:
>>>
>>> On Friday, April 27, 2018 5:41:19 PM CEST Lennart Poettering wrote:
On Fr, 27.04.18 17:27, Pavel Raiskup (prais...@redhat.com) 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@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: systemd in non-privileged container
On 04/30/2018 10:42 AM, James Hogarth wrote:
On 27 April 2018 at 17:47, Pavel Raiskup wrote:
On Friday, April 27, 2018 5:41:19 PM CEST Lennart Poettering wrote:
On Fr, 27.04.18 17:27, Pavel Raiskup (prais...@redhat.com) 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Perhaps it is time to update my blog on running systemd in a
unprivileged container.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: systemd in non-privileged container
On 27 April 2018 at 17:47, Pavel Raiskup wrote:
> On Friday, April 27, 2018 5:41:19 PM CEST Lennart Poettering wrote:
>> On Fr, 27.04.18 17:27, Pavel Raiskup (prais...@redhat.com) 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: systemd in non-privileged container
On Friday, April 27, 2018 5:41:19 PM CEST Lennart Poettering wrote: > On Fr, 27.04.18 17:27, Pavel Raiskup (prais...@redhat.com) 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? > > Lennart > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: systemd in non-privileged container
On 04/27/2018 11:41 AM, Lennart Poettering wrote: On Fr, 27.04.18 17:27, Pavel Raiskup (prais...@redhat.com) 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... First off this is not a Docker issue, it is a runc and OCI Runtime issue. I am not sure if this is fixed or not at this point. 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". The container runtimes can specify a stop signal, so as long as you specify the correct stop signal when creating your systemd based image, everything should work properly. NOTE you need to have oci-systemd-hook installed, and the container runtime needs to be able support OCI Runtime hooks. podman, CRI-O and ProjectAtomic/Docker all support them. Upstream Docker does NOT. What's the current state on that? Lennart ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: systemd in non-privileged container
On Fr, 27.04.18 17:27, Pavel Raiskup (prais...@redhat.com) 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... 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? Lennart ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
