package/podman: new package (branch yem/podman)
v4 cover package/podman: new package (branch yem/podman)
Hello All!
This series introduce podman, an alternative to Docker. Podman is daemon-less, and does not need root either.
The series starts with preparatory commits in existing packages and the testing infra: then it introduces new packages on which podman will rely.
Eventually, it adds a few optional packages that extend podman's functionality.
Not required by podman, skopeo is made a target package as well, as it was of help debugging podman (and Docker in a separate series).
Last but not least, the ultmate patch in th eseries moves the /etc/resolv.conf symlink target to pont into /run rather than the current /tmp.
Changes v1 -> v2:
- add licensing info for netavark and podman (Julien)
Changes v2 -> v3:
- make rootless actually work (Raphael)
Changes v3 -> v4;
- bump podman to 5.4.1 (from 5.4.0)
- add support for nftables in lieu of iptables (Raphael)
- move iptables and nftables options from podman to netavark
- ditto for related kernel config fixups
- add json option to nftables
- add aardvark-dns (for inter-container DNS) and passt (alternative to slitrp4netns)
- extend podman's runtime test with network testing
- move /etc/resolv.conf symlink to point into /run
Regards,
Yann E. MORIN.
----------------------------------------------------------------
Yann E. MORIN (14):
support/testing: set date in emulated machine package/shadow: install to staging for subids package/conmon: depends on systemd when enabled package/slirp4netns: needs TUN support in the kernel package/skopeo: add target variant package/cgroupfs-mount: tweak the kernel config package/cgroupfs-v2-mount: new package package/nftables: add an option to force JSON support package/netavark: new package
package/podman: new package package/aardvark-dns: new package
package/passt: new package
package/podman: add option to use passt as network backend system/skeleton: move target of /etc/resolv.conf symlink
docs/manual/migrating.adoc | 14 ++ package/Config.in | 6 + package/aardvark-dns/Config.in | 9 + package/aardvark-dns/aardvark-dns.hash | 3 + package/aardvark-dns/aardvark-dns.mk | 15 ++ package/cgroupfs-mount/Config.in | 12 +- package/cgroupfs-mount/cgroupfs-mount.mk | 11 ++ package/cgroupfs-v2-mount/Config.in | 10 + package/cgroupfs-v2-mount/S30cgroupfs2 | 44 +++++ package/cgroupfs-v2-mount/cgroupfs-v2-mount.mk | 20 ++ package/conmon/conmon.mk | 4 + package/netavark/Config.in | 13 ++ package/netavark/netavark.hash | 3 + package/netavark/netavark.mk | 93 +++++++++ package/nftables/Config.in | 7 +- package/nftables/nftables.mk | 2 +- package/passt/Config.in | 19 ++ package/passt/passt.hash | 4 + package/passt/passt.mk | 41 ++++ package/podman/Config.in | 92 +++++++++ package/podman/podman.hash | 3 + package/podman/podman.mk | 122 ++++++++++++ package/podman/policy.json | 7 + package/podman/registries.conf | 1 + package/shadow/shadow.mk | 1 + package/skopeo/Config.in | 25 +++ package/skopeo/skopeo.mk | 10 + package/slirp4netns/slirp4netns.mk | 9 + support/testing/infra/emulator.py | 5 + support/testing/tests/package/test_podman.py | 253 +++++++++++++++++++++++++ support/testing/tests/package/test_skopeo.py | 41 ++++ system/skeleton/etc/resolv.conf | 2 +- 32 files changed, 887 insertions(+), 14 deletions(-) create mode 100644 package/aardvark-dns/Config.in create mode 100644 package/aardvark-dns/aardvark-dns.hash create mode 100644 package/aardvark-dns/aardvark-dns.mk create mode 100644 package/cgroupfs-v2-mount/Config.in create mode 100644 package/cgroupfs-v2-mount/S30cgroupfs2 create mode 100644 package/cgroupfs-v2-mount/cgroupfs-v2-mount.mk create mode 100644 package/netavark/Config.in create mode 100644 package/netavark/netavark.hash create mode 100644 package/netavark/netavark.mk create mode 100644 package/passt/Config.in create mode 100644 package/passt/passt.hash create mode 100644 package/passt/passt.mk create mode 100644 package/podman/Config.in create mode 100644 package/podman/podman.hash create mode 100644 package/podman/podman.mk create mode 100644 package/podman/policy.json create mode 100644 package/podman/registries.conf create mode 100644 package/skopeo/Config.in create mode 100644 support/testing/tests/package/test_podman.py create mode 100644 support/testing/tests/package/test_skopeo.py
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v4 1/14 support/testing: set date in emulated machine
When time comes to check certificates, the date and time in the emulated machine should be close enough to the actual values, so that certificate validity can be checked.
Some Qemu machines have an RTC (e.g. arm vexpress-a9 has a pl031), and the kernel needs a driver for those RTC. It is not guaranteed that the machine used for a test meets those two conditions; in such a case, the time in the machine starts way back in the past (1970-01-01T00:00:00Z on sysv, or the release date of systemd). This is the case with the default kernel, so such tests do not have the proper time.
Set the date to the date of the host system. This is going to be accurate to the second, which is, by far, enough for our purpose.
To avoid having to consider what combination of emulated machine and kernel configuration are being used, we always set the date, as this is a generic step that should be done by the infra (like login in as root is).
The Emulator() class doesn't inherit from unittest.TestCase, so we can't call any of the usual self.assertXXX() methods; instead, we just raise a standard exception, like is done a few lines above to detect the login prompt.
---
Changes v1 -> v2:
- catch failure to set the date
Changes v3 -> v4:
- extend the rationale in the commit log (Julien)
--- support/testing/infra/emulator.py | 5 +++++ 1 file changed, 5 insertions(+)
support/testing/infra/emulator.py +5 -0
@@ -5,6 +5,7 @@ import os import pexpect import pexpect.replwrap +import time import infra
@@ -152,6 +153,10 @@ class Emulator(object): self.connect_shell() + output, exit_code = self.run(f"date @{int(time.time())}") + if exit_code: + raise SystemError("Cannot set date in virtual machine") + def connect_shell(self): extra_init_cmd = " && ".join([ 'export PAGER=cat',
Signature · 6 lines
2.47.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH 01/14 v4] support/testing: set date in emulated machine
Hi Yann, All,
Quoted 18 lines · Yann E. MORIN
When time comes to check certificates, the date and time in the emulated machine should be close enough to the actual values, so that certificate validity can be checked.
Some Qemu machines have an RTC (e.g. arm vexpress-a9 has a pl031), and the kernel needs a driver for those RTC. It is not guaranteed that the machine used for a test meets those two conditions; in such a case, the time in the machine starts way back in the past (1970-01-01T00:00:00Z on sysv, or the release date of systemd). This is the case with the default kernel, so such tests do not have the proper time.
Set the date to the date of the host system. This is going to be accurate to the second, which is, by far, enough for our purpose.
To avoid having to consider what combination of emulated machine and kernel configuration are being used, we always set the date, as this is a generic step that should be done by the infra (like login in as root is).
Quoted 8 lines
The
Emulator()class doesn't inherit from unittest.TestCase, so we can't call any of the usualself.assertXXX()methods; instead, we just raise a standard exception, like is done a few lines above to detect the login prompt.Signed-off-by Yann E. MORIN <[email protected]>Cc Ricardo Martincoski <[email protected]>Cc Thomas Petazzoni <[email protected]>
I applied this series in branch next.
This series was starting to get big, and I think that it is in a good shape to be merged. It is also a good time to merge that in the branch next, early in the release cycle. It will give time to have all the runtime tests running on it and let people test it. We'll do follow up fixes, if needed.
Thanks for this great work!
Best regards,
Julien.
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH 01/14 v4] support/testing: set date in emulated machine
In reply to Yann E. MORINQuoted 18 lines · Yann E. MORIN
When time comes to check certificates, the date and time in the emulated machine should be close enough to the actual values, so that certificate validity can be checked.
Some Qemu machines have an RTC (e.g. arm vexpress-a9 has a pl031), and the kernel needs a driver for those RTC. It is not guaranteed that the machine used for a test meets those two conditions; in such a case, the time in the machine starts way back in the past (1970-01-01T00:00:00Z on sysv, or the release date of systemd). This is the case with the default kernel, so such tests do not have the proper time.
Set the date to the date of the host system. This is going to be accurate to the second, which is, by far, enough for our purpose.
To avoid having to consider what combination of emulated machine and kernel configuration are being used, we always set the date, as this is a generic step that should be done by the infra (like login in as root is).
Quoted 8 lines
The
Emulator()class doesn't inherit from unittest.TestCase, so we can't call any of the usualself.assertXXX()methods; instead, we just raise a standard exception, like is done a few lines above to detect the login prompt.Signed-off-by Yann E. MORIN <[email protected]>Cc Ricardo Martincoski <[email protected]>Cc Thomas Petazzoni <[email protected]>
Applied to 2025.02.x, thanks.
Regards,
Arnout
Quoted 24 lines
---
Changes v1 -> v2:
- catch failure to set the dateChanges v3 -> v4:
- extend the rationale in the commit log (Julien)--- support/testing/infra/emulator.py | 5 +++++ 1 file changed, 5 insertions(+)support/testing/infra/emulator.py +1
-0@@ -5,6 +5,7 @@ import os import pexpect import pexpect.replwrap +import time import infra
support/testing/infra/emulator.py class Emulator(object): · line 162
Quoted 10 lines
support/testing/infra/emulator.py +4
-0@@ -152,6 +153,10 @@ class Emulator(object): self.connect_shell() + output, exit_code = self.run(f"date @{int(time.time())}") + if exit_code: + raise SystemError("Cannot set date in virtual machine") + def connect_shell(self): extra_init_cmd = " && ".join([ 'export PAGER=cat',
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v4 2/14 package/shadow: install to staging for subids
In reply to Yann E. MORINWhen the subids feature is enabled, shadow will install a library and a header:
$ sort output/build/shadow-4.16.0/.files-list.txt
[...]
shadow,./lib/libsubid.la
shadow,./lib/libsubid.so
shadow,./lib/libsubid.so.5
shadow,./lib/libsubid.so.5.0.0
[...]
shadow,./usr/include/shadow/subid.h
[...]Install to staging in that case.
---
Changes v3 -> v4:
- add Raphael's reviewd-by tag, as per:
https://lore.kernel.org/buildroot/[email protected]/T/#m61860669691f25a893ddf851a32c3860edaf3ff7 --- package/shadow/shadow.mk | 1 + 1 file changed, 1 insertion(+)
package/shadow/shadow.mk +1 -0
@@ -46,6 +46,7 @@ SHADOW_CONF_OPTS += --disable-account-tools-setuid endif ifeq ($(BR2_PACKAGE_SHADOW_SUBORDINATE_IDS),y) +SHADOW_INSTALL_STAGING = YES SHADOW_CONF_OPTS += --enable-subordinate-ids define SHADOW_SUBORDINATE_IDS_PERMISSIONS /usr/bin/newuidmap f 4755 0 0 - - - - -
Signature · 6 lines
2.47.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v4 3/14 package/conmon: depends on systemd when enabled
In reply to Yann E. MORINWhen it detects it runs under systemd, conmon will want to log to the journal. However, it needs to be linked with libsystemd to do so and if not, will error out:
Feb 22 11:10:03 buildroot conmon[199]: conmon 3b462ce6f2cc64f75c42 <error>: Include journald in compilation path to log to systemd journal
This prevents starting any container.
Add a dependency to systemd when it is enabled.
--- package/conmon/conmon.mk | 4 ++++ 1 file changed, 4 insertions(+)
package/conmon/conmon.mk +4 -0
@@ -18,6 +18,10 @@ else CONMON_DISABLE_SECCOMP = 1 endif +ifeq ($(BR2_PACKAGE_SYSTEMD),y) +CONMON_DEPENDENCIES += systemd +endif + define CONMON_CONFIGURE_CMDS printf '#!/bin/bash\necho "$(CONMON_DISABLE_SECCOMP)"\n' > \ $(@D)/hack/seccomp-notify.sh
Signature · 6 lines
2.47.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v4 4/14 package/slirp4netns: needs TUN support in the kernel
In reply to Yann E. MORINslirp4netns needs a kernel with TUN support, so enable that and the few options it depends on.
---
Changes v3 -> v4:
- add Raphael's reviewd-by tag, as per:
https://lore.kernel.org/buildroot/[email protected]/T/#m3e676331134de815b1795b1a847431fe099032d9 --- package/slirp4netns/slirp4netns.mk | 9 +++++++++ 1 file changed, 9 insertions(+)
package/slirp4netns/slirp4netns.mk +9 -0
@@ -12,4 +12,13 @@ SLIRP4NETNS_DEPENDENCIES = libcap libglib2 libseccomp slirp SLIRP4NETNS_AUTORECONF = YES +define SLIRP4NETNS_LINUX_CONFIG_FIXUPS + $(call KCONFIG_ENABLE_OPT,CONFIG_NET) + $(call KCONFIG_ENABLE_OPT,CONFIG_NET_CORE) + $(call KCONFIG_ENABLE_OPT,CONFIG_NETDEVICES) + $(call KCONFIG_ENABLE_OPT,CONFIG_NET_CORE) + $(call KCONFIG_ENABLE_OPT,CONFIG_INET) + $(call KCONFIG_ENABLE_OPT,CONFIG_TUN) +endef + $(eval $(autotools-package))
Signature · 6 lines
2.47.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v4 5/14 package/skopeo: add target variant
In reply to Yann E. MORINSkopeo can be used to manipulate container images, and so can be usefull on target devices that are going to be used as a host to run containers.
So, add a target variant for skopeo.
... with a runtime test while at it.
--- package/Config.in | 1 + package/skopeo/Config.in | 25 ++++++++++++ package/skopeo/skopeo.mk | 10 +++++ support/testing/tests/package/test_skopeo.py | 41 ++++++++++++++++++++ 4 files changed, 77 insertions(+) create mode 100644 package/skopeo/Config.in create mode 100644 support/testing/tests/package/test_skopeo.py
package/Config.in +1 -0
@@ -2893,6 +2893,7 @@ menu "System tools" source "package/sdbusplus/Config.in" source "package/seatd/Config.in" source "package/shadow/Config.in" + source "package/skopeo/Config.in" source "package/smack/Config.in" source "package/start-stop-daemon/Config.in" source "package/supervisor/Config.in"
package/skopeo/Config.in new file +25 -0
@@ -0,0 +1,25 @@ +config BR2_PACKAGE_SKOPEO + bool "skopeo" + depends on BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS + depends on BR2_PACKAGE_HOST_GO_TARGET_CGO_LINKING_SUPPORTS + depends on BR2_USE_MMU # btrfs-progs, libgpgme, lvm2 + depends on BR2_PACKAGE_LIBGPG_ERROR_ARCH_SUPPORTS # libgpgme + depends on BR2_TOOLCHAIN_HAS_THREADS # btrfs-progs, lvm2 + depends on !BR2_STATIC_LIBS # lvm2 + select BR2_PACKAGE_HOST_GO + select BR2_PACKAGE_BTRFS_PROGS + select BR2_PACKAGE_LIBGPGME + select BR2_PACKAGE_LVM2 + help + skopeo is a command line utility that performs various + operations on container images and image repositories. + + https://github.com/containers/skopeo + +comment "skopeo needs a toolchain w/ threads, sahred libs" + depends on BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS + depends on BR2_PACKAGE_HOST_GO_TARGET_CGO_LINKING_SUPPORTS + depends on BR2_USE_MMU + depends on BR2_PACKAGE_LIBGPG_ERROR_ARCH_SUPPORTS + depends on !BR2_TOOLCHAIN_HAS_THREADS \ + || BR2_STATIC_LIBS
package/skopeo/skopeo.mk +10 -0
@@ -11,13 +11,23 @@ SKOPEO_LICENSE = Apache-2.0 SKOPEO_LICENSE_FILES = LICENSE SKOPEO_CPE_ID_VALID = YES +SKOPEO_DEPENDENCIES = \ + host-pkgconf \ + btrfs-progs \ + libgpgme \ + lvm2 + HOST_SKOPEO_DEPENDENCIES = \ host-btrfs-progs \ host-libgpgme \ host-lvm2 \ host-pkgconf +SKOPEO_GO_ENV = PKG_CONFIG_PATH=$(HOST_DIR)/lib/pkgconfig +SKOPEO_BUILD_TARGETS = cmd/skopeo + HOST_SKOPEO_GO_ENV = PKG_CONFIG_PATH=$(HOST_DIR)/lib/pkgconfig HOST_SKOPEO_BUILD_TARGETS = cmd/skopeo +$(eval $(golang-package)) $(eval $(host-golang-package))
support/testing/tests/package/test_skopeo.py new file +41 -0
41 lines not on this page · raw message
Signature · 6 lines
2.47.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v4 6/14 package/cgroupfs-mount: tweak the kernel config
In reply to Yann E. MORINWhen it was introduced in 2016 with commit 0e1547a87cfd (cgroupfs-mount:
new package), we did not yet have the infrastrucutre for package to set kernel config options, which only came 4 years later with commit 0aed4c2dae76 (linux: allow packages to set kernel config options).
So at that time, the requirements for cgroupfs-mount were documented in the help for the Kconfig symbol.
But now that we do have tha infrastructure in place, actually use it to set the required options, and drop the list from the Lconfig entry (that would be duplication, prone to bit-rot with time, and other packages do not document their requirements in LKconfig, they just use the infra to set the options).
--- package/cgroupfs-mount/Config.in | 12 +----------- package/cgroupfs-mount/cgroupfs-mount.mk | 11 +++++++++++ 2 files changed, 12 insertions(+), 11 deletions(-)
package/cgroupfs-mount/Config.in +1 -11
@@ -4,16 +4,6 @@ config BR2_PACKAGE_CGROUPFS_MOUNT help cgroupfs mount and umount scripts. - requires a Linux kernel >= 3.0 with the following options - enabled: - - - CONFIG_BLK_CGROUP - - CONFIG_CGROUPS - - CONFIG_CGROUP_CPUACCT - - CONFIG_CGROUP_DEVICE - - CONFIG_CGROUP_FREEZER - - CONFIG_CGROUP_WRITEBACK - - CONFIG_CGROUP_SCHED - - CONFIG_CGROUP_PIDS + Requires a Linux kernel >= 3.0 https://github.com/tianon/cgroupfs-mount
package/cgroupfs-mount/cgroupfs-mount.mk +11 -0
@@ -10,6 +10,17 @@ CGROUPFS_MOUNT_LICENSE = GPL-3.0+ CGROUPFS_MOUNT_LICENSE_FILES = debian/copyright CGROUPFS_MOUNT_CPE_ID_VALID = YES +define CGROUPFS_MOUNT_LINUX_CONFIG_FIXUPS + $(call KCONFIG_ENABLE_OPT,CONFIG_BLK_CGROUP) + $(call KCONFIG_ENABLE_OPT,CONFIG_CGROUPS) + $(call KCONFIG_ENABLE_OPT,CONFIG_CGROUP_CPUACCT) + $(call KCONFIG_ENABLE_OPT,CONFIG_CGROUP_DEVICE) + $(call KCONFIG_ENABLE_OPT,CONFIG_CGROUP_FREEZER) + $(call KCONFIG_ENABLE_OPT,CONFIG_CGROUP_WRITEBACK) + $(call KCONFIG_ENABLE_OPT,CONFIG_CGROUP_SCHED) + $(call KCONFIG_ENABLE_OPT,CONFIG_CGROUP_PIDS) +endef + define CGROUPFS_MOUNT_INSTALL_TARGET_CMDS $(INSTALL) -D -m 0755 $(@D)/cgroupfs-mount $(TARGET_DIR)/usr/bin/cgroupfs-mount $(INSTALL) -D -m 0755 $(@D)/cgroupfs-umount $(TARGET_DIR)/usr/bin/cgroupfs-umount
Signature · 6 lines
2.47.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v4 7/14 package/cgroupfs-v2-mount: new package
In reply to Yann E. MORINCurrently, the cgroupfs-mount package only mounts a cgroup v1 hierarchy, but v1 is considered legacy and obsolete, while v2 has ben around for a while now, and is required by some packages (e.g. podman whines about v1).
cgroupfs-mount has not had a release in almost 8 years now, and only the occasional commit since then and until more than 3 years ago. It's not going to evolve...
Add a new package with a simple-enough sysv startup script, that mounts the cgroup v2 hierarchy filesystem. For systemd, there's nothing to do, as systemd handles the mount by itself.
Since both cgroup v1 and v2 use the same mountpoint, we can't have both enabled at the same time, and thus we restrict the v2 to be hidden when v1 is enabled (quite a few packages select the v1; changing those would require that they be validated against v2 first...)
Note that, due to limitations in Kconfig, cgroupfs-v2-mount will appear indented below cgroupfs-mount, because it has a (negative) dependnecy on it. This spurious indentation is unfortunate and annoying, but benign; fixing that would require breaking the dependency with a random Kconfig symbole, which we dont have, and which we decided not to introduce jsut for this one use-case (well, there's host-gnupg and host-gnupg2 that have the exact same issue, but meh...)
---
Changes v2 -> v3;
- enable cgroups in the kernel
- really unmount on stop, rather than mounting again
--- package/Config.in | 1 + package/cgroupfs-v2-mount/Config.in | 10 +++++ package/cgroupfs-v2-mount/S30cgroupfs2 | 44 +++++++++++++++++++ .../cgroupfs-v2-mount/cgroupfs-v2-mount.mk | 20 +++++++++ 4 files changed, 75 insertions(+) create mode 100644 package/cgroupfs-v2-mount/Config.in create mode 100644 package/cgroupfs-v2-mount/S30cgroupfs2 create mode 100644 package/cgroupfs-v2-mount/cgroupfs-v2-mount.mk
package/Config.in +1 -0
@@ -2809,6 +2809,7 @@ menu "System tools" source "package/balena-engine/Config.in" source "package/bubblewrap/Config.in" source "package/cgroupfs-mount/Config.in" + source "package/cgroupfs-v2-mount/Config.in" source "package/circus/Config.in" source "package/conmon/Config.in" source "package/containerd/Config.in"
package/cgroupfs-v2-mount/Config.in new file +10 -0
@@ -0,0 +1,10 @@ +config BR2_PACKAGE_CGROUPFS_V2_MOUNT + bool "cgroupfs-v2-mount" + depends on !BR2_INIT_SYSTEMD + depends on !BR2_PACKAGE_CGROUPFS_MOUNT + help + Mount the cgroup v2 hierarchy filesystem. + +comment "cgroupfs-v2-mount is incompatible with cgroupfs-mount" + depends on !BR2_INIT_SYSTEMD + depends on BR2_PACKAGE_CGROUPFS_MOUNT
package/cgroupfs-v2-mount/S30cgroupfs2 new file +44 -0
44 lines not on this page · raw message
package/cgroupfs-v2-mount/cgroupfs-v2-mount.mk new file +20 -0
@@ -0,0 +1,20 @@ +################################################################################ +# +# cgroupfs-v2-mount +# +################################################################################ + +CGROUPFS_V2_MOUNT_VERSION = +CGROUPFS_V2_MOUNT_SITE = + +define CGROUPFS_V2_MOUNT_LINUX_CONFIG_FIXUPS + $(call KCONFIG_ENABLE_OPT,CONFIG_CGROUPS) +endef + +define CGROUPFS_V2_MOUNT_INSTALL_INIT_SYSV + $(INSTALL) -m 0755 -D \ + $(CGROUPFS_V2_MOUNT_PKGDIR)/S30cgroupfs2 \ + $(TARGET_DIR)/etc/init.d/S30cgroupfs2 +endef + +$(eval $(generic-package))
Signature · 6 lines
2.47.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v4 8/14 package/nftables: add an option to force JSON support
In reply to Yann E. MORINCurrently, nftables JSON suppot is implicit: if jansson is enabled, JSON support is enabled, otherwise it is not.
Some packages will require that nftables be built with JSON support; that's the case of netavarks, for example (to come in a later patch). So, in the current state, it would mean a package would have to select jansson, althogh it does not itself use it, so that nftables has JSON support. This does not feel right.
Instead, introduce an option to nftables, to explicitly enabled JSON support. Packages such as netavark would then just have to require JSON support in nftables.
--- package/nftables/Config.in | 7 ++++++- package/nftables/nftables.mk | 2 +- 2 files changed, 7 insertions(+), 2 deletions(-)
package/nftables/Config.in +6 -1
@@ -13,9 +13,14 @@ config BR2_PACKAGE_NFTABLES http://www.netfilter.org/projects/nftables/index.html -# Legacy: this used to be handled in nftables.mk if BR2_PACKAGE_NFTABLES +# Legacy: this used to be handled in nftables.mk source "package/nftables/nftables-python/Config.in" + +config BR2_PACKAGE_NFTABLES_JSON + bool "json support" + select BR2_PACKAGE_JANSSON + endif comment "nftables needs a toolchain w/ wchar, headers >= 3.12"
package/nftables/nftables.mk +1 -1
@@ -42,7 +42,7 @@ else NFTABLES_CONF_OPTS += --without-cli endif -ifeq ($(BR2_PACKAGE_JANSSON),y) +ifeq ($(BR2_PACKAGE_NFTABLES_JSON),y) NFTABLES_DEPENDENCIES += jansson NFTABLES_CONF_OPTS += --with-json else
Signature · 6 lines
2.47.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v4 9/14 package/netavark: new package
In reply to Yann E. MORIN---
Changes v1 -> v2:
- add licensing information (Julien)
changes v3 -> v4;
- carry the iptables options
- support nftables an alternative to iptables (Raphael)
--- package/Config.in | 1 + package/netavark/Config.in | 12 +++++ package/netavark/netavark.hash | 3 ++ package/netavark/netavark.mk | 92 ++++++++++++++++++++++++++++++++++ 4 files changed, 108 insertions(+) create mode 100644 package/netavark/Config.in create mode 100644 package/netavark/netavark.hash create mode 100644 package/netavark/netavark.mk
package/Config.in +1 -0
@@ -2560,6 +2560,7 @@ endif source "package/ndisc6/Config.in" source "package/net-tools/Config.in" source "package/netatalk/Config.in" + source "package/netavark/Config.in" source "package/netcalc/Config.in" source "package/netcat/Config.in" source "package/netcat-openbsd/Config.in"
package/netavark/Config.in new file +12 -0
@@ -0,0 +1,12 @@ +config BR2_PACKAGE_NETAVARK + bool "netavark" + depends on BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS + select BR2_PACKAGE_HOST_RUSTC + select BR2_PACKAGE_IPTABLES if !BR2_PACKAGE_NFTABLES # runtime + select BR2_PACKAGE_NFTABLES_JSON if BR2_PACKAGE_NFTABLES && !BR2_PACKAGE_IPTABLES + help + Netavark is a rust based network stack for containers. It + is being designed to work with Podman but is also applicable + for other OCI container management applications. + + https://github.com/containers/netavark
package/netavark/netavark.hash new file +3 -0
@@ -0,0 +1,3 @@ +# Locally computed +sha256 09471bd116fdebfd3f7a8100b37809e3a306d0f18e5feee8445ed1e01a22e0aa netavark-v1.14.0-git4-cargo2.tar.gz +sha256 c71d239df91726fc519c6eb72d318ec65820627232b2f796219e87dcf35d0ab4 LICENSE
package/netavark/netavark.mk new file +92 -0
92 lines not on this page · raw message
Signature · 6 lines
2.47.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v4 10/14 package/podman: new package
In reply to Yann E. MORINPodman is a container manager not unlike Docker, but is daemon-less.
Similarly to docker-engine, quite a few kernel config options are required; as they are very similar in goals and features, the options from docker-engine have been duplicated for podman. As that was not enough, a few additional options have been added after trial-and-error testing (they are not explicitly listed in the documentation).
The documentation [0] states that seccomp can be disabled (i.e. not enabled). However, without seccomp support, starting containers requires --security-opt=seccomp=unconfined to be specified; it does not look trivial to make that the default, though [1]. Furthermore, containers are about security, so disabling a security measure does not sound too good. So we make seccomp support mandatory.
Podman needs netavark as a the network backend (it missing is a hard error at runtime). It is supposd to also require aardvark-dns, an authoritative DNS resolver, but it missing does not look to adversely affect networking, so it is not used (as not even packaged in Buildroot yet).
Podman can run either as the root user, or it can run rootless, i.e. by a non-root user, which requires a bit of setup (see below, in the runtime test) and a few other dependencies: slirp4netns [2] (to provide network connectivity in userland), and support for subordinate UIDs and GIDs with the shadow library. Rootless mode is one of the main selling point for podman, so we decided that this would not be configurable in Buildroot.
Similar to Docker, podman can inject a minimalist init as PID1 in containers, and like Docker, this is optional; podman however by default uses catatonit as such an init [3]. As for Docker-engine, we offer a choice of which init package to use to provide podman-init.
Podman requires at least three config files; they can be either per-user or system-wide:
- containers.conf [4]: defines various settings for the container
runtimes;
- policy.json [5]: defines what signature to accept to validate
images; without one such file, podman just refuses to pull images;- registries.conf [6]: defines where to pull images from; without it, podman does not know how to pull un-qualified images (i.e. images where the registry is not specified in the path, and which Docker would fetch from the Docker Hub, e.g. "busybox:latest").
For those three files, we provide a very minimal default that (in the same order as above):
- uses the slirp4netns network backend for rootless operation (the default in podman is to use pasta [1], so we need to explicitly configure it to use slirp4netns);
- allows pulling images which signature can't be verified;
- pulls unqualified images from the Docker Hub, as is traditional.
Providing actual files is going to be use-case dependent, and interested parties will have to provide their own config files, e.g. in a rootfs overlay.
Finally, we add a runtime test for podman. Podman is a huge binary, and may call other huge binaries (netavark...); this can be quite slow in the emulated machine (even when running on a very fast host machine), so we use a huge timeout for all commands involving podman, even those that exit the containers, as that may need to tear down podman setup.
The default kernel used in runtime tests is missing a lot of features, so we need to build our own; we use the same version as the bundled kernel. We can't use cpio either, because we need a filesystem that can be used as a lower and upper of overlayfs, which is not possible with the filesystem the cpio is extracted into; ext2 fits the bill, so we use that. We need a bit of space to store images and stuff, so let's be generous and allocate 256M.
To test rootless operation, we need a non-root user that has some special setup [7]; it is easier to run the commands from the infra rather than carry a user-definition table and a rootfs overlay. We need that user to have the same prompts (main and continuation) so that the REPLWrapper still detects those; it has the unfortunate side effect that it is not immediately obvious whether a command was run as root or not, and one has to look back up in the run-log to see whether there was a transition to another user earlier.
Still for rootless containers, podman/netavark expect /etc/resolv.conf to be either a plain file, or a symlink that points either deeper in /etc or anywhere in /run; if resolv.conf resolves to any other location, DNS in rootless contaienrs does not work. This is reasonable, and is what already happens on a systemd-based system (and thus all major distributions nowadays. However, in Buildroot, we put the actual file in /tmp; this is historical, and dates back to the days where Buildroot did not have a guaranteed-writable /run. So, we work around this limitation in the test (for now).
The official busybox image on the Docker Hub supports a lot of architectures, of which armv7 which we use for this runtime test. Finding a small image that also supports armv7 on other registries was a bit of a challenge; we eventually found one busybox image on quay.io, but it is not an official busybox image; still, it fits the bill, so we use it.
There is no runtime test with systemd, as this requires quite some additional setup that does not look very trivial to do; when it detects it is running under systemd in rootless mode, podman expects that a full user session exists, or it whines about it every time it is started, reverting to non-systemd behaviour; getting a full user session does not look to be that trivial (PAM?), so this would not exercise the actual integration with systemd, so the test would not be meaningful, so it is not provided. This is left as an exercise to an interested party to extend the tests.
PS: Hat-tip to Raphael, who provided some pointers and hints on this change, especially for rootless mode. Thanks! 👍
[0] https://podman.io/docs/installation#get-source-code
[1] it looks like we can provide a custom seccomp profile, by specifying seccomp_profile="PATH" in containers.conf; that would still require seccomp support to use that file, though, so that does not change the outcome.
[2] it is possible to use another backend, but it is not packaged in
in Buildroot yet: https://passt.top/passt/about/#pasta-pack-a-subtle-tap-abstraction
[3] podman expects a 'catatonit' helper in /usr/libexec/podman, so even if tini would be usable instead, it would not feel right to use it to impersonate catatonit. So let's assume that only catatonit is supported.
[4] https://github.com/containers/common/blob/main/docs/containers.conf.5.md
[5] https://github.com/containers/image/blob/main/docs/containers-policy.json.5.md
[6] https://github.com/containers/image/blob/main/docs/containers-registries.conf.5.md
[7] https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md
---
Changes v1 -> v2:
- add licensing information (Julien)
Changes v2 -> v3:
- make it work with rootless
Changes v3 -> v4:
- bump to podman 5.4.1
- move iptables options away, into netavark
- make network work in rootless containers
- add choice for the init package
- move containers.conf into its primary canonical location (Raphael, Christian)
--- package/Config.in | 1 + package/podman/Config.in | 80 ++++++++ package/podman/containers.conf | 2 + package/podman/podman.hash | 3 + package/podman/podman.mk | 110 ++++++++++ package/podman/policy.json | 7 + package/podman/registries.conf | 1 + support/testing/tests/package/test_podman.py | 203 +++++++++++++++++++ 8 files changed, 407 insertions(+) create mode 100644 package/podman/Config.in create mode 100644 package/podman/containers.conf create mode 100644 package/podman/podman.hash create mode 100644 package/podman/podman.mk create mode 100644 package/podman/policy.json create mode 100644 package/podman/registries.conf create mode 100644 support/testing/tests/package/test_podman.py
package/Config.in +1 -0
@@ -2869,6 +2869,7 @@ menu "System tools" source "package/openvmtools/Config.in" source "package/pamtester/Config.in" source "package/petitboot/Config.in" + source "package/podman/Config.in" source "package/polkit/Config.in" source "package/powerpc-utils/Config.in" source "package/procps-ng/Config.in"
package/podman/Config.in new file +80 -0
80 lines not on this page · raw message
package/podman/containers.conf new file +2 -0
@@ -0,0 +1,2 @@ +[network] +default_rootless_network_cmd = "slirp4netns"
package/podman/podman.hash new file +3 -0
@@ -0,0 +1,3 @@ +# Locally computed +sha256 6c31845cbbc54a0b65c4afba224048c002b40e863c4ba7ca19355a8d333b3d19 podman-v5.4.1-git4-go2.tar.gz +sha256 62fb8a3a9621dc2388174caaabe9c2317b694bb9a1d46c98bcf5655b68f51be3 LICENSE
package/podman/podman.mk new file +110 -0
110 lines not on this page · raw message
package/podman/policy.json new file +7 -0
@@ -0,0 +1,7 @@ +{ + "default": [ + { + "type": "insecureAcceptAnything" + } + ] +}
package/podman/registries.conf new file +1 -0
@@ -0,0 +1 @@ +unqualified-search-registries = ["docker.io"]
support/testing/tests/package/test_podman.py new file +203 -0
203 lines not on this page · raw message
Signature · 6 lines
2.47.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v4 11/14 package/aardvark-dns: new package
In reply to Yann E. MORINaardvark-dns is needed by netavark to provide cross-container DNS resolving with Podman.
It is to be noted that netavark and aardvark-dns have to be udated in lock-step [0].
Update the podman runtime test to validate this is working.
--- package/Config.in | 1 + package/aardvark-dns/Config.in | 9 +++++ package/aardvark-dns/aardvark-dns.hash | 3 ++ package/aardvark-dns/aardvark-dns.mk | 15 ++++++++ package/netavark/Config.in | 1 + package/netavark/netavark.mk | 1 + package/podman/podman.mk | 1 + support/testing/tests/package/test_podman.py | 38 ++++++++++++++++++++ 8 files changed, 69 insertions(+) create mode 100644 package/aardvark-dns/Config.in create mode 100644 package/aardvark-dns/aardvark-dns.hash create mode 100644 package/aardvark-dns/aardvark-dns.mk
package/Config.in +1 -0
@@ -2411,6 +2411,7 @@ menu "Miscellaneous" endmenu menu "Networking applications" + source "package/aardvark-dns/Config.in" source "package/aircrack-ng/Config.in" source "package/alfred/Config.in" source "package/aoetools/Config.in"
package/aardvark-dns/Config.in new file +9 -0
@@ -0,0 +1,9 @@ +config BR2_PACKAGE_AARDVARK_DNS + bool "aardvark-dns" + depends on BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS + select BR2_PACKAGE_HOST_RUSTC + help + Authoritative dns server for A/AAAA container records. + Forwards other request to host's /etc/resolv.conf + + https://github.com/containers/aardvark-dns/
package/aardvark-dns/aardvark-dns.hash new file +3 -0
@@ -0,0 +1,3 @@ +# Locally computed +sha256 bbd4a0b0bdf6788c09266f1f944d5c5397b6db4f1da0735a1d42738a6e074249 aardvark-dns-v1.14.0-git4-cargo2.tar.gz +sha256 c71d239df91726fc519c6eb72d318ec65820627232b2f796219e87dcf35d0ab4 LICENSE
package/aardvark-dns/aardvark-dns.mk new file +15 -0
@@ -0,0 +1,15 @@ +################################################################################ +# +# aardvark-dns +# +################################################################################ + +# When updating the version here, also update netavark in lockstep +AARDVARK_DNS_VERSION = v1.14.0 +AARDVARK_DNS_SITE = https://github.com/containers/aardvark-dns +AARDVARK_DNS_SITE_METHOD = git + +AARDVARK_DNS_LICENSE = Apache-2.0 +AARDVARK_DNS_LICENSE_FILES = LICENSE + +$(eval $(cargo-package))
package/netavark/Config.in +1 -0
@@ -2,6 +2,7 @@ config BR2_PACKAGE_NETAVARK bool "netavark" depends on BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS select BR2_PACKAGE_HOST_RUSTC + select BR2_PACKAGE_AARDVARK_DNS # runtime select BR2_PACKAGE_IPTABLES if !BR2_PACKAGE_NFTABLES # runtime select BR2_PACKAGE_NFTABLES_JSON if BR2_PACKAGE_NFTABLES && !BR2_PACKAGE_IPTABLES help
package/netavark/netavark.mk +1 -0
@@ -4,6 +4,7 @@ # ################################################################################ +# When updating the version here, also update aardvark-dns in lockstep NETAVARK_VERSION = v1.14.0 NETAVARK_SITE = https://github.com/containers/netavark NETAVARK_SITE_METHOD = git
package/podman/podman.mk +1 -0
@@ -101,6 +101,7 @@ PODMAN_POST_INSTALL_TARGET_HOOKS += PODMAN_CONFIG define PODMAN_HELPERS $(Q)mkdir -p $(TARGET_DIR)/usr/libexec/podman + $(Q)ln -sf ../../bin/aardvark-dns $(TARGET_DIR)/usr/libexec/podman/aardvark-dns $(Q)ln -sf ../../bin/netavark $(TARGET_DIR)/usr/libexec/podman/netavark $(Q)ln -sf ../../bin/slirp4netns $(TARGET_DIR)/usr/libexec/podman/slirp4netns $(PODMAN_HELPER_INIT)
support/testing/tests/package/test_podman.py +38 -0
@@ -166,6 +166,44 @@ class PodmanBase(infra.basetest.BRTest): output, _ = self.emulator.run('echo ${br_container}') self.assertEqual(output[0], "", "Still in a container") + # Test networking between two containers + self.assertRunOk("podman network create buz") + self.assertRunOk( + "podman container run --rm -ti --name pod007 --network buz --detach busybox:1.37.0", + ) + self.assertRunOk( + "podman container run --rm -ti --name pod006 --network buz --detach busybox:1.37.0", + ) + # Ensure each pod can resolv itself and the other + # (not using itertools.matrix() just for those trivial combinations) + for pod1, pod2 in [ + ("pod006", "pod006"), + ("pod006", "pod007"), + ("pod007", "pod007"), + ("pod007", "pod006"), + ]: + output, exit_code = self.emulator.run( + f"podman container exec {pod1} nslookup {pod2}", + ) + self.assertEqual(exit_code, 0) + self.assertTrue(output[0].startswith("Server:")) + self.assertTrue(output[1].startswith("Address:")) + # Busybox' nslookup emits one "Non-authoritative answer" per + # supported address familly: IPv4 and IPv6. + self.assertEqual( + len([line for line in output[2:] if line == "Non-authoritative answer:"]), + 2, + ) + # But only IPv4 is available on this network + self.assertEqual( + len([line for line in output[2:] if line.startswith("Address:")]), + 1, + ) + self.assertRunOk("podman container kill --all") + output, _ = self.emulator.run("podman container ls --format '{{ json }}'") + pod_info = json.loads("".join(output)) + self.assertEqual(len(pod_info), 0, f"{len(pod_info)} container(s) still present, expecting 0") + # Remove the offical image self.assertRunOk('podman image rm busybox:1.37.0') output, _ = self.emulator.run("podman image ls --format '{{ json }}'")
Signature · 6 lines
2.47.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v4 12/14 package/passt: new package
In reply to Yann E. MORIN--- package/Config.in | 1 + package/passt/Config.in | 19 +++++++++++++++++++ package/passt/passt.hash | 4 ++++ package/passt/passt.mk | 41 ++++++++++++++++++++++++++++++++++++++++ 4 files changed, 65 insertions(+) create mode 100644 package/passt/Config.in create mode 100644 package/passt/passt.hash create mode 100644 package/passt/passt.mk
package/Config.in +1 -0
@@ -2606,6 +2606,7 @@ endif source "package/openvpn/Config.in" source "package/p910nd/Config.in" source "package/parprouted/Config.in" + source "package/passt/Config.in" source "package/phidgetwebservice/Config.in" source "package/phytool/Config.in" source "package/pimd/Config.in"
package/passt/Config.in new file +19 -0
@@ -0,0 +1,19 @@ +config BR2_PACKAGE_PASST + bool "passt" + help + passt: Plug A Simple Socket Transport + pasta: Pack A Subtle Tap Abstraction + + passt implements a translation layer between a Layer-2 + network interface and native Layer-4 sockets (TCP, UDP, + ICMP/ICMPv6 echo) on a host. It doesn't require any + capabilities or privileges, and it can be used as a simple + replacement for Slirp. + + pasta (same binary as passt, different command) offers + equivalent functionality, for network namespaces: traffic + is forwarded using a tap interface inside the namespace, + without the need to create further interfaces on the host, + hence not requiring any capabilities or privileges. + + https://passt.top/passt/about/
package/passt/passt.hash new file +4 -0
@@ -0,0 +1,4 @@ +# Locally computed +sha256 f76c12e0535b9f6af59ee747d8ed7a8f691bb1ac7429225484788f0bc6e23dac passt-2025_02_17.a1e48a0-git4.tar.gz +sha256 32dfe03d9985f5feb581da26a2fe6c84530cccb6b53ede0d8dab075cd048ac5b LICENSES/BSD-3-Clause.txt +sha256 aaf135472f81c5b4a0dca9367e5bb5e9750032b5bebe5442b36e4c0a47430df3 LICENSES/GPL-2.0-or-later.txt
package/passt/passt.mk new file +41 -0
41 lines not on this page · raw message
Signature · 6 lines
2.47.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v4 13/14 package/podman: add option to use passt as network backend
In reply to Yann E. MORINpasst/pasta is the officialy supported network backend, with slirp4netns only considered a legacy solution. However, some people have experienced corner cases when using passt/pasta (as it still is a yong stack), so we do not want to do a blanket replace of slirp4netns just yet. Still, we make passt/pasta the default option.
As a consequence, the existing runtime tests will now test passt/pasta, so we introduce two new tests for slirp4netns as a network backend.
--- package/podman/Config.in | 22 +++++++++++++++----- package/podman/containers.conf | 2 -- package/podman/podman.mk | 19 +++++++++++++---- support/testing/tests/package/test_podman.py | 19 +++++++++++++++++ 4 files changed, 51 insertions(+), 11 deletions(-) delete mode 100644 package/podman/containers.conf
package/podman/Config.in +17 -5
@@ -4,10 +4,10 @@ config BR2_PACKAGE_PODMAN depends on BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS # host-go depends on BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS # netavark depends on BR2_PACKAGE_LIBGPG_ERROR_ARCH_SUPPORTS # libgpgme - depends on BR2_PACKAGE_LIBSECCOMP_ARCH_SUPPORTS # libseccomp, slirp4netns - depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_17 # libseccomp, slirp4netns - depends on BR2_TOOLCHAIN_HAS_THREADS # conmon, slirp4netns - depends on BR2_USE_WCHAR # conmon, slirp4netns + depends on BR2_PACKAGE_LIBSECCOMP_ARCH_SUPPORTS # libseccomp + depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_17 # libseccomp + depends on BR2_TOOLCHAIN_HAS_THREADS # conmon + depends on BR2_USE_WCHAR # conmon select BR2_PACKAGE_HOST_GO select BR2_PACKAGE_CA_CERTIFICATES # runtime select BR2_PACKAGE_CGROUPFS_V2_MOUNT if !BR2_PACKAGE_CGROUPFS_MOUNT && !BR2_INIT_SYSTEMD # runtime
@@ -22,7 +22,6 @@ config BR2_PACKAGE_PODMAN select BR2_PACKAGE_RUNC if !BR2_PACKAGE_CRUN # runtime select BR2_PACKAGE_SHADOW select BR2_PACKAGE_SHADOW_SUBORDINATE_IDS - select BR2_PACKAGE_SLIRP4NETNS # runtime help The best free & open source container tools
@@ -67,6 +66,19 @@ config BR2_PACKAGE_PODMAN_INIT_NAME default "tini" if BR2_PACKAGE_PODMAN_INIT_TINI default "catatonit" if BR2_PACKAGE_PODMAN_INIT_CATATONIT +choice + bool "Network backend" + +config BR2_PACKAGE_PODMAN_NET_PASST + bool "passt/pasta" + select BR2_PACKAGE_PASST # runtime + +config BR2_PACKAGE_PODMAN_NET_SLIRP4NETNS + bool "slirp4netns" + select BR2_PACKAGE_SLIRP4NETNS # runtime + +endchoice + endif comment "podman needs a toolchain w/ headers >= 3.17, threads, wchar"
package/podman/containers.conf deleted +0 -2
@@ -1,2 +0,0 @@ -[network] -default_rootless_network_cmd = "slirp4netns"
package/podman/podman.mk +15 -4
@@ -62,6 +62,19 @@ define PODMAN_HELPER_INIT endef endif +ifeq ($(BR2_PACKAGE_PODMAN_NET_PASST),y) +define PODMAN_HELPER_PASST + $(Q)ln -sf ../../bin/pasta $(TARGET_DIR)/usr/libexec/podman/pasta +endef +else +define PODMAN_HELPER_SLIRP4NETNS + $(Q)ln -sf ../../bin/slirp4netns $(TARGET_DIR)/usr/libexec/podman/slirp4netns + $(Q)mkdir -p $(TARGET_DIR)/etc/containers/containers.conf.d + $(Q)printf '[network]\ndefault_rootless_network_cmd = "slirp4netns"\n' \ + >$(TARGET_DIR)/etc/containers/containers.conf.d/50-buildroot-net-backend.conf +endef +endif + define PODMAN_LINUX_CONFIG_FIXUPS $(call KCONFIG_ENABLE_OPT,CONFIG_CPUSETS) $(call KCONFIG_ENABLE_OPT,CONFIG_BPF_SYSCALL)
@@ -87,9 +100,6 @@ define PODMAN_LINUX_CONFIG_FIXUPS endef define PODMAN_CONFIG - $(Q)$(INSTALL) -D -m 0644 \ - $(PODMAN_PKGDIR)/containers.conf \ - $(TARGET_DIR)/usr/share/containers/containers.conf $(Q)$(INSTALL) -D -m 0644 \ $(PODMAN_PKGDIR)/policy.json \ $(TARGET_DIR)/etc/containers/policy.json
@@ -103,8 +113,9 @@ define PODMAN_HELPERS $(Q)mkdir -p $(TARGET_DIR)/usr/libexec/podman $(Q)ln -sf ../../bin/aardvark-dns $(TARGET_DIR)/usr/libexec/podman/aardvark-dns $(Q)ln -sf ../../bin/netavark $(TARGET_DIR)/usr/libexec/podman/netavark - $(Q)ln -sf ../../bin/slirp4netns $(TARGET_DIR)/usr/libexec/podman/slirp4netns $(PODMAN_HELPER_INIT) + $(PODMAN_HELPER_PASST) + $(PODMAN_HELPER_SLIRP4NETNS) endef PODMAN_POST_INSTALL_TARGET_HOOKS += PODMAN_HELPERS
support/testing/tests/package/test_podman.py +19 -0
@@ -239,3 +239,22 @@ class TestPodmanTini(PodmanBase): def test_run(self): self.do_test() + + +class TestPodmanSlirpIptables(PodmanBase): + config = PodmanBase.config + """ + BR2_PACKAGE_PODMAN_NET_SLIRP4NETNS=y + """ + + def test_run(self): + self.do_test() + + +class TestPodmanSlirpNftables(PodmanBase): + config = PodmanBase.config + """ + BR2_PACKAGE_NFTABLES=y + BR2_PACKAGE_PODMAN_NET_SLIRP4NETNS=y + """ + + def test_run(self): + self.do_test()
Signature · 6 lines
2.47.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v4 14/14 system/skeleton: move target of /etc/resolv.conf symlink
In reply to Yann E. MORINIn commit ba70f94e629e (subversion makes it so we do not need a separate tarball to store empty directories and symlinks for the target_skeleton.) /etc/resolv.conf was made a symlink to ../tmp/resolv.conf. There was no rationale behind this change, but back at the time (2006!), the only location that Buildroot guaranteed to be writable was /tmp, and we needed a writable location to create resolv.conf from a DHCP reply for example, so the change made sense.
Commits 2f67d9e2fe7b (preparation for BR2_PACKAGE_BUSYBOX_SKELETON), in 2007, then d9119c0bc55d (move default skeleton to fs/ and drop busybox skeleton), in 2010, and finally 6c3e3ad41977 (New top-level directory:
system), in 2012, propagated that /etc/resolv.conf without any change in the target of the symlink.
However, since commit d380dde1d287 (skeleton: make /run a proper directory/filesystem), in 2015, a tmpfs has been mounted on /run, so it is now guaranteed to be writable as well for SYS-V-based systems. That has also been the case for openrc since commit a840e485d174 (package/skeleton-init-openrc: new package), in 2019. This has also always been the case for systemd as well.
resolv.conf is not a temporary file [0]; it is really more of a runtime data; its location in /tmp is just a historical artefact of a long-wrong assertion.
Nowadays, distributions either have an actual file as /etc/resolv.conf (when /etc is writable), or it is a symlink to a location below /run.
Although resolv.conf is used by the C library resolver, a lot of applications now will directly use it; this is the case for some container management tools, such as podman (and its helpers, like netavark), that expect /etc/resolv.conf to either be a file or a symlink to somewhere in /run, and fail to provide DNS services if that is not the case.
So, we move the target of /etc/resolv.conf to ../run/resolv.conf.
As a consequence, we can drop the workaround in podman's runtime test.
To be noted: there are tow custom fstab files in Buildroot that do not explicitly mount a tmpfs on /run:
- one for a systemd runtime test, so /run would also be a tmpfs there
anyway, as systemd does mount one;
- one for the mender_x86_64_efi_defconfig; that's a not a problem:
/ is an ext4 that is mounted r/w (and /tmp is not a tmpfs either, so the symlink to /tmp would not not have worked if / was not r/w anyway).
This leaves people with their own fstab, to adapt. Cater to them by adding a little blurb in the documentation.
Note: the following 43 tests all built and ran successfully:
tests.init
tests.package.test_apache tests.package.test_docker_compose tests.package.test_dropbear tests.package.test_iputils tests.package.test_podman tests.package.test_skopeo tests.package.test_wget
(no other runtime test were attempted)
[0] temporary, as in relatively short-lived.
--- docs/manual/migrating.adoc | 14 ++++++++++++++ support/testing/tests/package/test_podman.py | 7 ------- system/skeleton/etc/resolv.conf | 2 +- 3 files changed, 15 insertions(+), 8 deletions(-)
docs/manual/migrating.adoc +14 -0
@@ -195,3 +195,17 @@ host-mender-artifact. See +board/mender/x86_64/post-image-efi.sh+ for an example of how to generate the bootstrap.mender file. See https://docs.mender.io/release-information/release-notes-changelog/mender-client#mender-3-5-0-1[the release notes], under features, for more information. + +[[migrating-resolv.conf]] +=== Migrating to 2025.05 + +In 2025.05, for SYS-V-like systems (busybox, sysvinit, openrc), the +`/etc/resolv.conf` symlink was changed to point to `/run/resolv.conf`, +rather than the legacy location in `/tmp`. Users of a custom `fstab` +will need to ensure that `/run` is writable before resolv.conf is +created (usually by a DHCP client), either with an entry for `/run`, +or with a startup script. + +Note that systems using systemd are not impacted: systemd always ensures +that `/run` is writable. Systems further using systemd-resolved already +had a `/etc/resolv.conf` that pointed into `/run` anyway.
support/testing/tests/package/test_podman.py +0 -7
@@ -71,13 +71,6 @@ class PodmanBase(infra.basetest.BRTest): self.assertRunOk("touch /etc/subuid /etc/subgid") self.assertRunOk("usermod --add-subuids 10000-75535 foo") self.assertRunOk("usermod --add-subgids 10000-75535 foo") - # If /etc/resolv.conf is a symlink, it has to point either into /etc - # (or deep in there), or into /run (or deep in there), as only those - # would eventually get used by podman/netavark for # rootless containers. - # This is considered a workaround to the current situation; resolv,conf - # should ultimately be in /run rather than /tmp. - self.assertRunOk("mv /tmp/resolv.conf /run/resolv.conf") - self.assertRunOk("ln -sf /run/resolv.conf /etc/resolv.conf") # First, test podman as root (the current user) self.do_podman()
system/skeleton/etc/resolv.conf +1 -1
@@ -1 +1 @@ -../tmp/resolv.conf +../run/resolv.conf
Signature · 6 lines
2.47.0 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot