[systemd-devel] I want to run systemd inside of a locked down base docker container

[Daniel J Walsh]

On 02/10/2016 11:16 AM, Lennart Poettering wrote:
> On Wed, 10.02.16 10:56, Daniel J Walsh (dwalsh at redhat.com) wrote:
>
>> On Fedora I see a few services starting up and failing when I run
>> systemd, I have been able  to disable these
>> by executing.
>>
>> RUN systemctl disable sysinit.target remote-fs.target
>> systemd-remount-fs;\
> sysinit.target and systemd-remount-fs.service are static units; they
> cannot be enabled via "systemctl enable" or disabled via "systemctl
> disable". That part should be a NOP and should not have any effect;
> you can drop it.
>
> remote-fs.target has no value either, unless there actually are NFS
> mounts listed in /etc/fstab. I am pretty sure there aren't any for in
> your container, are there? Hence, this really sounds like something
> you can drop too, without any change in behaviour.
I was seeing failed mounts inside the container until I removed these. 
I can
remove these lines to see if the failed mounts come back.  But there
should be nothing
in the container that does a mount, unless someone put bogus stuff in
the Fedora base container.

This is what the dockerfile looks like that I am building and testing
with systemd.
```
Cat Dockerfile

FROM 		fedora:23
MAINTAINER	Dan Walsh
ENV container docker
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd; systemctl disable dnf* dnf-makecache.timer
RUN systemctl disable sysinit.target remote-fs.target systemd-remount-fs;\
    systemctl mask systemd-firstboot initrd-udevadm-cleanup-db.service
systemd-udev-settle.service systemd-udev-trigger.service systemd-udevd.service systemd-udevd-control.socket systemd-udevd-kernel.socket; \
    rm -f /lib/systemd/system/multi-user.target.wants/systemd* /lib/systemd/system/multi-user.target.wants/getty*;\
    sed -i 's/^enable/disable/g' /lib/systemd/system-preset/* 

EXPOSE 80

CMD [ "/sbin/init" ]

```

>>     systemctl mask systemd-firstboot initrd-udevadm-cleanup-db.service
>> systemd-udev-settle.service systemd-udev-trigger.service
>> systemd-udevd.service systemd-udevd-control.socket
>> systemd-udevd-kernel.socket; \
> The systemd-firstboot service should have no effect unless you
> actually boot with an empty /etc (or more accuratily: unless you
> actually boot with an /etc that lacks /etc/machine-id) . Note that it
> carries a condition ConditionFirstBoot=yes which makes sure that it
> isn't even executed in normal cases. 
I see in the logs systemd complaining about no systemd-firstboot command.
> Masking all the udev stuff is pretty pointless too. These services are
> conditioned out in containers too anyway. There's really no need to
> mask them out. More specifically, they contain
> ConditionPathIsReadWrite=/sys, i.e. are skipped if /sys is read-only,
> which is the way how container managers should set up /sys (it's a big
> security hole to allow containers write access to /sys). My
> recommendation would be to make sure you container manager implements
> these recommendations:
I am just seeing mentions of udev inside of the container, What I don't
want is messages
inside of the journal or bootup that look like systemd is trying to run
firstboot, udev etc.
> https://wiki.freedesktop.org/www/Software/systemd/ContainerInterface/
>
> If your container manager follows these guidelines (of which the /sys
> being read-only thing is one), then there should be no special hacks
> necessary in systemd, as it should just work, and detect the slight
> semantica changes of containers correctly and avoid them cleanly.
>
>>     rm -f /lib/systemd/system/multi-user.target.wants/systemd*
>>     /lib/systemd/system/multi-user.target.wants/getty*;\
> What's the rationale for this? First of all, the getty stuff appears
> entirely unnecessary as getty at .service (which is the only thing
> generally linked from gettys.target these days) contains
> ConditionPathExists=/dev/tty0 which means it's already skipped when
> run on systems lacking a VC (such as containers).
Again, I am seeing getty@ failures inside of the container.
> And the other services you are removing here: what's the point? they
> aren't really optional, that's why they are linked from /usr/lib,
> rather than subject to systemctl enable/disable...
>
>>     sed -i 's/^enable/disable/g' /lib/systemd/system-preset/* 
> Why would this matter?
We don't want excess services running inside of a docker container.  I
only want systemd/journald and any services
that I enable in the container.   Not something pulled in because the
installer thinks this is a VM or a Host OS.
>
>> Could someone look at these and tell me if I went too far.  I would like to get these commands as the default for systemd in the base
>> RHEL/Fedora and Centos containers.
> I don't follow at all. 
>
> None of this is necessary. systemd works fine in containers as long as
> the container manager follows these guidelines:
>
> https://wiki.freedesktop.org/www/Software/systemd/ContainerInterface/
>
> nspawn implements all of this, and docker really should too...
>
> Lennart
>
If I remove these I end up seeing my systemd based container boot up
with these messages.

# docker run -ti $(/usr/bin/docker-systemd-setup) --name httpd2 httpd
systemd 222 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
Detected virtualization docker.
Detected architecture x86-64.

Welcome to Fedora 23 (Twenty Three)!

Set hostname to <ba64338e2b1a>.
Running in a container, ignoring fstab device entry for /dev/disk/by-uuid/2cd63037-e967-4e87-b29b-044190721e80.
sys-fs-fuse-connections.mount: Cannot add dependency job, ignoring: Unit sys-fs-fuse-connections.mount is masked.
dev-hugepages.mount: Cannot add dependency job, ignoring: Unit dev-hugepages.mount is masked.
systemd-remount-fs.service: Cannot add dependency job, ignoring: Unit systemd-remount-fs.service is masked.
systemd-logind.service: Cannot add dependency job, ignoring: Unit systemd-logind.service is masked.
getty.target: Cannot add dependency job, ignoring: Unit getty.target is masked.
[OK ] Reached target Encrypted Volumes.
[OK ] Created slice Root Slice.
[OK ] Listening on Journal Socket.
[OK ] Listening on Journal Socket (/dev/log).
[OK ] Reached target Remote File Systems.
[OK ] Reached target Paths.
[OK ] Created slice System Slice.
...

I want to get rid of these mount messages, getty messages systemd-logind messages...










-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20160210/85c6fff8/attachment-0001.html>