Add a systemd service 'collect-firewalld-logs.service' that copies
firewalld log file into bundles/ on container shutdown. This won't
provide much value for developers who run `make shell`, but it'll be
useful on CI to include firewalld logs in the exported artifacts.
The CI is already configured to pick every *.log file from bundles/, so
no further change is needed on that side.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
The github action running bake expected FIREWALLD to be set, but
DOCKER_FIREWALLD was set instead, so firewalld wasn't installed
in the dev image.
The dind-systemd script expected DOCKER_FIREWALLD to be set if it
needed to run firewalld, and it was. But it had no effect.
In CI, bake builds the image then make runs it - and the use the
same env. So, align on FIREWALLD (as it's not a docker feature).
Signed-off-by: Rob Murray <rob.murray@docker.com>
The pkg/archive/archive_linux_test.go tests create a test archive
content in a temporary directory. This also includes device nodes (using
mknod).
Running these tests in Docker-in-Docker (dind) with systemd was failing
with "operation not permitted" because the rootfs is remounted with
`nodev`.
This change aligns `hack/dind-systemd` with `hack/dind` by
conditionally mounting a `tmpfs` on `/tmp` (with dev enabled),
to make the mknod work.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Commit 4e567e16 added firewalld to the test matrix for various CI jobs
(namely unit, integration and integration-cli).
Commit 2807c0c2 reverted that commit as it was putting too much load on
GHA cache, and thus it was returning 429 more frequently, so builds had
a greater chance of spending time building everything from scratch. This
was slowing down our CI even more than what it was before.
This new commit re-adds firewalld to the test matrix of unit,
integration and integration-cli jobs. Unlike 4e567e16, not all
combinations of OS, storage and 'mode' will be tested. Instead,
firewalld jobs will run only on ubuntu-22.04, and with the containerd
snapshotter.
Also, the revert commit mistakenly reverted a fix that was originally
intended for commit 8883db20, but was actually 'fixed up' in the wrong
commit. Let's re-revert that too.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Temporarily remove firewallds jobs. These are actually not running
firewalld due to a typo in GHA definitions. Moreover, these new jobs
are putting too much load on the CI, causing GHA cache backend to return
429 for many jobs. This slows down build jobs (as they can't use
existing cache), and at least one buildkit test is now failing.
This reverts commit 4e567e1622.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
On bookworm, AppArmor failed to start inside the container, which can be
seen at startup of the dev-container:
Created symlink /etc/systemd/system/systemd-firstboot.service → /dev/null.
Created symlink /etc/systemd/system/systemd-udevd.service → /dev/null.
Created symlink /etc/systemd/system/multi-user.target.wants/docker-entrypoint.service → /etc/systemd/system/docker-entrypoint.service.
hack/dind-systemd: starting /lib/systemd/systemd --show-status=false --unit=docker-entrypoint.target
systemd 252.17-1~deb12u1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
Detected virtualization docker.
Detected architecture x86-64.
modprobe@configfs.service: Deactivated successfully.
modprobe@dm_mod.service: Deactivated successfully.
modprobe@drm.service: Deactivated successfully.
modprobe@efi_pstore.service: Deactivated successfully.
modprobe@fuse.service: Deactivated successfully.
modprobe@loop.service: Deactivated successfully.
apparmor.service: Starting requested but asserts failed.
proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 49 (systemd-binfmt)
+ source /etc/docker-entrypoint-cmd
++ hack/make.sh dynbinary test-integration
When checking "aa-status", an error was printed that the filesystem was
not mounted:
aa-status
apparmor filesystem is not mounted.
apparmor module is loaded.
Checking if "local-fs.target" was loaded, that seemed to be the case;
systemctl status local-fs.target
● local-fs.target - Local File Systems
Loaded: loaded (/lib/systemd/system/local-fs.target; static)
Active: active since Mon 2023-11-27 10:48:38 UTC; 18s ago
Docs: man:systemd.special(7)
However, **on the host**, "/sys/kernel/security" has a mount, which was not
present inside the container:
mount | grep securityfs
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
Interestingly, on `debian:bullseye`, this was not the case either; no
`securityfs` mount was present inside the container, and apparmor actually
failed to start, but succeeded silently:
mount | grep securityfs
systemctl start apparmor
systemctl status apparmor
● apparmor.service - Load AppArmor profiles
Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled)
Active: active (exited) since Mon 2023-11-27 11:59:09 UTC; 44s ago
Docs: man:apparmor(7)
https://gitlab.com/apparmor/apparmor/wikis/home/
Process: 43 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, status=0/SUCCESS)
Main PID: 43 (code=exited, status=0/SUCCESS)
CPU: 10ms
Nov 27 11:59:09 9519f89cade1 apparmor.systemd[43]: Not starting AppArmor in container
Same, using the `/etc/init.d/apparmor` script:
/etc/init.d/apparmor start
Starting apparmor (via systemctl): apparmor.service.
echo $?
0
And apparmor was not actually active:
aa-status
apparmor module is loaded.
apparmor filesystem is not mounted.
aa-enabled
Maybe - policy interface not available.
After further investigating, I found that the non-systemd dind script
had a mount for AppArmor, which was added in 31638ab2ad
The systemd variant was missing this mount, which may have gone unnoticed
because `debian:bullseye` was silently ignoring this when starting the
apparmor service.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
