10:27 a.m.
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
Pavel
10:41 a.m.
On Fr, 27.04.18 17:27, Pavel Raiskup (praiskup(a)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
11:30 a.m.
On 04/27/2018 11:41 AM, Lennart Poettering wrote:
On Fr, 27.04.18 17:27, Pavel Raiskup (praiskup(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
11:47 a.m.
On Friday, April 27, 2018 5:41:19 PM CEST Lennart Poettering wrote:
On Fr, 27.04.18 17:27, Pavel Raiskup (praiskup(a)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-...
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
9:42 a.m.
On 27 April 2018 at 17:47, Pavel Raiskup <praiskup(a)redhat.com> wrote:
On Friday, April 27, 2018 5:41:19 PM CEST Lennart Poettering wrote:
> On Fr, 27.04.18 17:27, Pavel Raiskup (praiskup(a)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-...
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
9:56 a.m.
On 04/30/2018 10:42 AM, James Hogarth wrote:
On 27 April 2018 at 17:47, Pavel Raiskup <praiskup(a)redhat.com>
wrote:
> On Friday, April 27, 2018 5:41:19 PM CEST Lennart Poettering wrote:
>> On Fr, 27.04.18 17:27, Pavel Raiskup (praiskup(a)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-...
>
> 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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Perhaps it is time to update my blog on running systemd in a
unprivileged container.
10:21 a.m.
On 30 April 2018 at 15:56, Daniel Walsh <dwalsh(a)redhat.com> wrote:
On 04/30/2018 10:42 AM, James Hogarth wrote:
>
> On 27 April 2018 at 17:47, Pavel Raiskup <praiskup(a)redhat.com> wrote:
>>
>> On Friday, April 27, 2018 5:41:19 PM CEST Lennart Poettering wrote:
>>>
>>> On Fr, 27.04.18 17:27, Pavel Raiskup (praiskup(a)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-...
>>
>> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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.
10:31 a.m.
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
10:33 a.m.
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
2190
days inactive
2193
days old
8 comments
5 participants
participants (5)
-
Daniel Walsh -
James Hogarth -
Jan Pazdziora -
Lennart Poettering -
Pavel Raiskup