Hi, * Michael Biebl [Fri Aug 19, 2022 at 09:11:47AM +0200]: > Am 19.08.22 um 08:58 schrieb Michael Prokop:
> > I just tested a few things, JFYI: > > > > * When systemd-resolved is installed and gets removed, the > > file/symlink /etc/resolv.conf gets removed as well. Is that really > > expected? (This is something e.g. the resolvconf doesn't do, you > > still end up with a /etc/resolv.conf being in-place then) > The question would be, which file should be restored. > One could make a copy of the resolv.conf file when systemd-resolved is > installed and restore that file upon removal. > But how would you know if the resolv.conf is still valid (after say a year)? > Isn't it cleaner to simply do nothing here and fail hard? Yeah, good question. :) That's a problem resolvconf doesn't seem to have AFAICT (as you're usually configuring specific nameservers there, and resolvconf can continue to restore/keep them in case of uninstalling resolvconf). But given that "it's usually a DNS problem" this situation is something which we should probably keep in mind. > > * Installation of the systemd-resolved package inside docker/podman > > fails hard for me (running on a Debian/bullseye host): > > > > | Unpacking systemd-resolved (251.4-1) ... > > | dpkg: error processing archive > > /var/cache/apt/archives/systemd-resolved_251.4-1_amd64.deb (--unpack): > > | unable to make backup link of './etc/resolv.conf' before installing new > > version: Invalid cross-device link > > | Selecting previously unselected package libnss-resolve:amd64. > > | Preparing to unpack .../libnss-resolve_251.4-1_amd64.deb ... > > | Unpacking libnss-resolve:amd64 (251.4-1) ... > > | Errors were encountered while processing: > > | /var/cache/apt/archives/systemd-resolved_251.4-1_amd64.deb > > | E: Sub-process /usr/bin/dpkg returned an error code (1) > > > > (Didn't investigate further on this yet, seems to be related to the > > way dpkg handles symlinks (as set up by dh_link in the systemd > > packaging) and containers with overlay doesn't like that, though > > installing systemd inside docker/podman containers used to work fine > > so far for me) > > Is /run bind-mounted into the container somehow? AFAIK no: | root@5880f837612b:/# mount | fuse-overlayfs on / type fuse.fuse-overlayfs (rw,nodev,noatime,user_id=0,group_id=0,default_permissions,allow_other) | proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) | tmpfs on /dev type tmpfs (rw,nosuid,size=65536k,mode=755,uid=1000,gid=1000) | sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime) | devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=100004,mode=620,ptmxmode=666) | mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime) | tmpfs on /etc/resolv.conf type tmpfs (rw,nosuid,nodev,relatime,size=1615024k,nr_inodes=403756,mode=700,uid=1000,gid=1000) | tmpfs on /etc/hosts type tmpfs (rw,nosuid,nodev,relatime,size=1615024k,nr_inodes=403756,mode=700,uid=1000,gid=1000) | shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=64000k,uid=1000,gid=1000) | tmpfs on /etc/hostname type tmpfs (rw,nosuid,nodev,relatime,size=1615024k,nr_inodes=403756,mode=700,uid=1000,gid=1000) | tmpfs on /run/.containerenv type tmpfs (rw,nosuid,nodev,relatime,size=1615024k,nr_inodes=403756,mode=700,uid=1000,gid=1000) | cgroup2 on /sys/fs/cgroup type cgroup2 (ro,nosuid,nodev,noexec,relatime) | udev on /dev/null type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755) | udev on /dev/zero type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755) | udev on /dev/full type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755) | udev on /dev/tty type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755) | udev on /dev/random type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755) | udev on /dev/urandom type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755) | tmpfs on /proc/acpi type tmpfs (ro,relatime,size=0k,uid=1000,gid=1000) | udev on /proc/kcore type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755) | udev on /proc/keys type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755) | udev on /proc/timer_list type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755) | udev on /proc/sched_debug type devtmpfs (rw,nosuid,relatime,size=8048900k,nr_inodes=2012225,mode=755) | tmpfs on /sys/firmware type tmpfs (ro,relatime,size=0k,uid=1000,gid=1000) | tmpfs on /sys/dev/block type tmpfs (ro,relatime,size=0k,uid=1000,gid=1000) | proc on /proc/asound type proc (ro,relatime) | proc on /proc/bus type proc (ro,relatime) | proc on /proc/fs type proc (ro,relatime) | proc on /proc/irq type proc (ro,relatime) | proc on /proc/sys type proc (ro,relatime) | proc on /proc/sysrq-trigger type proc (ro,relatime) But podman and docker both by default use the resolv.conf bind mount, e.g. when inspecting the podman container one can see: | ResolvConfPath": "/run/user/1000/containers/overlay-containers/5880f837612b91c1d3a53d5886993cdaae36c78e70633121f628cc89759b7067/userdata/resolv.conf", (see also `tmpfs on /etc/resolv.conf type tmpfs` in mount output above). podman here™ uses the overlay (fuse) driver, but also running a docker container with overlay2 instead doesn't change this problem, inspecting the container also shows: | "ResolvConfPath": "/var/lib/docker/containers/5f67361c24dfd4807b360263f546acbddfe70777e34c811987feec239f7a6cfb/resolv.conf", ... and its mount output is similar (though not identical due to different internal behaviors): | root@5f67361c24df:/# mount | overlay on / type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/l/MSJTD4IGM2UVJIF2PRZU3X2UG4:/var/lib/docker/overlay2/l/BDJL4S6XH3QHLIEI74CGOEPXWH,upperdir=/var/lib/docker/overlay2/f2a3281e02c6e9fb0e5478bc3b948a1aa04f7c34bb6ccf94be4ca4641e768dff/diff,workdir=/var/lib/docker/overlay2/f2a3281e02c6e9fb0e5478bc3b948a1aa04f7c34bb6ccf94be4ca4641e768dff/work) | proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) | tmpfs on /dev type tmpfs (rw,nosuid,size=65536k,mode=755) | devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666) | sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime) | cgroup on /sys/fs/cgroup type cgroup2 (ro,nosuid,nodev,noexec,relatime) | mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime) | shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k) | /dev/mapper/crypt_lunge-docker on /etc/resolv.conf type ext4 (rw,relatime) | /dev/mapper/crypt_lunge-docker on /etc/hostname type ext4 (rw,relatime) | /dev/mapper/crypt_lunge-docker on /etc/hosts type ext4 (rw,relatime) | devpts on /dev/console type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666) | proc on /proc/bus type proc (ro,nosuid,nodev,noexec,relatime) | proc on /proc/fs type proc (ro,nosuid,nodev,noexec,relatime) | proc on /proc/irq type proc (ro,nosuid,nodev,noexec,relatime) | proc on /proc/sys type proc (ro,nosuid,nodev,noexec,relatime) | proc on /proc/sysrq-trigger type proc (ro,nosuid,nodev,noexec,relatime) | tmpfs on /proc/asound type tmpfs (ro,relatime) | tmpfs on /proc/acpi type tmpfs (ro,relatime) | tmpfs on /proc/kcore type tmpfs (rw,nosuid,size=65536k,mode=755) | tmpfs on /proc/keys type tmpfs (rw,nosuid,size=65536k,mode=755) | tmpfs on /proc/timer_list type tmpfs (rw,nosuid,size=65536k,mode=755) | tmpfs on /proc/sched_debug type tmpfs (rw,nosuid,size=65536k,mode=755) | tmpfs on /sys/firmware type tmpfs (ro,relatime) HTH && regards -mika-
signature.asc
Description: PGP signature
