Bug#1020691: debos should depend on systemd-resolved
On Tue, 2022-10-25 at 07:47 +0700, Arnaud Rebillout wrote: > On 24/10/2022 21:55, Christopher Obbard wrote: > > I'm more leaning on just adding it as a direct Dependency to the > > Debos > > package and seeing if anyone moans... > Works for me. Seems installing systemd-resolved breaks the autopkgtest test runner, at least in a local qemu instance :-). For now I will leave it as a Recommends.
Bug#1020691: debos should depend on systemd-resolved
On 24/10/2022 21:55, Christopher Obbard wrote: I'm more leaning on just adding it as a direct Dependency to the Debos package and seeing if anyone moans... Works for me.
Bug#1020691: debos should depend on systemd-resolved
On Mon, 2022-10-24 at 20:00 +0700, Arnaud Rebillout wrote: > > On 24/10/2022 17:34, Christopher Obbard wrote: > > > I have proposed[1] to check if systemd-resolved is available at > > runtime, to at least let users know *why* name resolution doesn't > > work > > inside their fakemachine over letting the user debugging it > > themselves. > > > [1]: https://github.com/go-debos/fakemachine/pull/115 > That's nice! I thought of it as well, and I was wondering if systemd- > resolved (and possibly other services) should be listed under > Requires= instead of Wants= (talking about > https://github.com/go-debos/fakemachine/blob/main/machine.go#L288). > But then, I noticed commit 4c60b85a8302f0fa544adae73f0649726034711c, > and why using Wants= is the intention. So your approach works better. That's been merged into Fakemachine now. > > Perhaps we should add systemd-resolved to Suggests in > > debos/fakemachine? Adding it as a Depends/Recommends would break > > users > > who have some other package on their machine handling name > > resolution. > > > > @Arnaud, how does that sound? > Well, I'm not sure for the packaging part. If fakemachine needs > systemd-resolved to be functional, then it should be a Depends. > That's what Depends is for. > At a quick glance, there's no reverse dependencies of fakemachine / > debos. So the only users that would be surprised by the change are > the ones who installed it explicitly, so we can assume those are > technical users and they'll find their way? But then, what if there > are some installations on servers (think builders), and the upgrade > breaks the name resolution? Not a nice surprise. > OTOH, an error message saying that "/lib/systemd/systemd-resolved is > missing", plus a Suggests: systemd-resolved, both together gives a > strong hint regarding what should be done. It sounds sensible as > well. > Sorry, that's not really a clear answer :) > Best, I'm more leaning on just adding it as a direct Dependency to the Debos package and seeing if anyone moans...
Bug#1020691: debos should depend on systemd-resolved
On 24/10/2022 17:34, Christopher Obbard wrote: I have proposed[1] to check if systemd-resolved is available at runtime, to at least let users know *why* name resolution doesn't work inside their fakemachine over letting the user debugging it themselves. [1]:https://github.com/go-debos/fakemachine/pull/115 That's nice! I thought of it as well, and I was wondering if systemd-resolved (and possibly other services) should be listed under Requires= instead of Wants= (talking about https://github.com/go-debos/fakemachine/blob/main/machine.go#L288). But then, I noticed commit 4c60b85a8302f0fa544adae73f0649726034711c, and why using Wants= is the intention. So your approach works better. Perhaps we should add systemd-resolved to Suggests in debos/fakemachine? Adding it as a Depends/Recommends would break users who have some other package on their machine handling name resolution. @Arnaud, how does that sound? Well, I'm not sure for the packaging part. If fakemachine needs systemd-resolved to be functional, then it should be a Depends. That's what Depends is for. At a quick glance, there's no reverse dependencies of fakemachine / debos. So the only users that would be surprised by the change are the ones who installed it explicitly, so we can assume those are technical users and they'll find their way? But then, what if there are some installations on servers (think builders), and the upgrade breaks the name resolution? Not a nice surprise. OTOH, an error message saying that "/lib/systemd/systemd-resolved is missing", plus a Suggests: systemd-resolved, both together gives a strong hint regarding what should be done. It sounds sensible as well. Sorry, that's not really a clear answer :) Best, -- Arnaud Rebillout / Offensive Security / Kali Linux Developer
Bug#1020691: debos should depend on systemd-resolved
On Thu, 2022-10-06 at 10:11 +0700, Arnaud Rebillout wrote: > > On 05/10/2022 22:06, Michael Biebl wrote: > > I think if you want to assemble a root/usr fs where you don't want > > do > > "disturb" the host system, I'd use a debootstrapped chroot but not > > the > > host fs. > > I think the original reason for fakemachine to exist was to build OS > images from within containers. At first it doesn't sound like a great > idea, because usually there's not enough capabilities in the > container > for that (ie. no access to the loop device). But systems like Jenkins > or > GitLab CI drop you in a container, you have no choice. So fakemachine > came as a solution / workaround to spawn a VM from within a container > (according that you have access to /dev/kvm), and then from within > the > VM you can build an OS image. > > Hence this weird approach of "faking a machine", ie. creating a VM by > reusing bits from the host filesystem. To say it again: if you're > already within an environment that has been setup for the job (chroot > or > container), no need to debootstrap a chroot again, let's just make > sure > this environment has everything needed, and re-use it for the VM. > That's > the approach of fakemachine, as I understand it. > > And so, for this use-case when fakemachine is used from within a > chroot/container, I must say that the systemd-resolved split is not > really problematic: all it takes is to add systemd-resolved to the > list > of packages to install in the chroot/container. > > The issue is for people installing fakemachine on their own machine. > So > far it worked great (I've been using it a lot to build OS images). > Now > it doesn't anymore. So either I install systemd-resolved, either I > start > a chroot and run fakemachine from there. It doesn't work "out of the > box" anymore, if you want. > > > > Say you want to install apache2 in your fakemachine managed VM, > > this > > would also start it on the host system, or not? > > Yes, but this comparison is not really relevant here. systemd- > resolved > is needed for the VM to have a functional network, so it's really a > prerequisite for a functional VM, regardless of what users want to do > with it. Hence the question of whether it should become a Depends for > the fakemachine package. > > While apache2 will never be a Depend of fakemachine in any case, and > if > users have a need for a particular need for that, it's in their hand > to > decide how to do it. > > Maybe fakemachine is more or less a VM counterpart of "systemd-nspawn > -D > / -xb" (systemd-nspawn(1), example 6)? > > I hope that I clarified a few points here. Would be nice to hear more > from fakemachine maintainers. > > Best regards, > I have proposed[1] to check if systemd-resolved is available at runtime, to at least let users know *why* name resolution doesn't work inside their fakemachine over letting the user debugging it themselves. Perhaps we should add systemd-resolved to Suggests in debos/fakemachine? Adding it as a Depends/Recommends would break users who have some other package on their machine handling name resolution. @Arnaud, how does that sound? [1]: https://github.com/go-debos/fakemachine/pull/115
Bug#1020691: debos should depend on systemd-resolved
On 05/10/2022 22:06, Michael Biebl wrote: I think if you want to assemble a root/usr fs where you don't want do "disturb" the host system, I'd use a debootstrapped chroot but not the host fs. I think the original reason for fakemachine to exist was to build OS images from within containers. At first it doesn't sound like a great idea, because usually there's not enough capabilities in the container for that (ie. no access to the loop device). But systems like Jenkins or GitLab CI drop you in a container, you have no choice. So fakemachine came as a solution / workaround to spawn a VM from within a container (according that you have access to /dev/kvm), and then from within the VM you can build an OS image. Hence this weird approach of "faking a machine", ie. creating a VM by reusing bits from the host filesystem. To say it again: if you're already within an environment that has been setup for the job (chroot or container), no need to debootstrap a chroot again, let's just make sure this environment has everything needed, and re-use it for the VM. That's the approach of fakemachine, as I understand it. And so, for this use-case when fakemachine is used from within a chroot/container, I must say that the systemd-resolved split is not really problematic: all it takes is to add systemd-resolved to the list of packages to install in the chroot/container. The issue is for people installing fakemachine on their own machine. So far it worked great (I've been using it a lot to build OS images). Now it doesn't anymore. So either I install systemd-resolved, either I start a chroot and run fakemachine from there. It doesn't work "out of the box" anymore, if you want. Say you want to install apache2 in your fakemachine managed VM, this would also start it on the host system, or not? Yes, but this comparison is not really relevant here. systemd-resolved is needed for the VM to have a functional network, so it's really a prerequisite for a functional VM, regardless of what users want to do with it. Hence the question of whether it should become a Depends for the fakemachine package. While apache2 will never be a Depend of fakemachine in any case, and if users have a need for a particular need for that, it's in their hand to decide how to do it. Maybe fakemachine is more or less a VM counterpart of "systemd-nspawn -D / -xb" (systemd-nspawn(1), example 6)? I hope that I clarified a few points here. Would be nice to hear more from fakemachine maintainers. Best regards, -- Arnaud Rebillout / Offensive Security / Kali Linux Developer
Bug#1020691: debos should depend on systemd-resolved
Hi, > > So far, the package fakemachine Depends on systemd, and that was enough. > > Now with the split, and since we need systemd-resolved, we should make > > fakemachine Depend on systemd-resolved as well. However, and if I > > understand properly, installing systemd-resolved also *enables* it. A > > user installing the package is saying: I want name resolution to be done > > by systemd-resolved. Therefore it's not really suitable to put it in a > > Depend or a Recommend. fakemachine only needs the code from > > systemd-resolved (lib and binary, I suppose), but it definitely doesn't > > want to enable it: this decision belongs to the user. > > > > Does that make sense so far? Many times I have got the same feeling/need about packages like apache2, tomcat, etc. I would like to install and maintain them up-to-date using their Debian package distribution, but having a facility to not activate their (default) root/system- land and provide a facility for a user-land activation. In general it is possible in fact, I have achieved such for at least the two apache2 and tomcat ones. I mean for such packages providing a way to activate them-self in the root/system-land as well as a (general?) facility for a user- land service. I know that having a general approach to solve this is somehow infeasible. But despite this could it be really interesting (at least for my pov) to think about it and therefore a good candidate for a grow-your-idea-for- Debian-Project ticket? Best, Patrice
Bug#1020691: debos should depend on systemd-resolved
On Wed, 5 Oct 2022 at 17:06, Michael Biebl wrote: > > Am 05.10.22 um 16:08 schrieb Arnaud Rebillout: > > On 05/10/2022 16:58, Christopher Obbard wrote: > >> Hi Arnaud, > >> > >> Thanks for shedding the extra light. This is not a nice bug ! > >> > >> I think we should ask the systemd maintainer if they'd accept a patch > >> to make the enabling of systemd-resolved service a manual operation, or > >> at least to split the binary into a separate package, something like > >> systemd-standalone-resolved ? > > > > > > Dear systemd maintainers, > > > > the packages fakemachine & debos (which uses fakemachine) are facing an > > issue now that systemd-resolved was split in a separate package. > > > > For the background: fakemachine is a program that spawns a QEMU VM that > > "mimics" the host. It does so mainly by mounting /usr from the host into > > the VM, plus a few other bits from here and there. For the network to > > work in the VM, it relies on systemd-networkd and systemd-resolved. > > These programs need to be present on the host, so that they are > > available in the VM. > > > > For more details, you can just run "fakemachine" in a shell, then "ps > > fax | grep qemu" in another shell: you will see how fakemachine uses qemu. > > > > So far, the package fakemachine Depends on systemd, and that was enough. > > Now with the split, and since we need systemd-resolved, we should make > > fakemachine Depend on systemd-resolved as well. However, and if I > > understand properly, installing systemd-resolved also *enables* it. A > > user installing the package is saying: I want name resolution to be done > > by systemd-resolved. Therefore it's not really suitable to put it in a > > Depend or a Recommend. fakemachine only needs the code from > > systemd-resolved (lib and binary, I suppose), but it definitely doesn't > > want to enable it: this decision belongs to the user. > > > > Does that make sense so far? > > Not really, tbh. I think if you want to assemble a root/usr fs where you > don't want do "disturb" the host system, I'd use a debootstrapped chroot > but not the host fs. > Say you want to install apache2 in your fakemachine managed VM, this > would also start it on the host system, or not? > I don't know why fakemachine does it this way and it's possible I'm > missing something, but this approache feels "weird" to me, for the lack > of a better word. Indeed, and the approach should be the opposite - if you want the binary but not to run it, then for that special case you should script it to disable it. Enablement is done via postinst. The semantics that we _want_ are that installing the package means "use this as my resolver", i.e., the default is very much intentionally that installing it also enables it, so that for the supported case there's no manual step to do, it "just works" out of the box. This is the approach that upstream recommends. Kind regards, Luca Boccassi
Bug#1020691: debos should depend on systemd-resolved
Am 05.10.22 um 16:08 schrieb Arnaud Rebillout: On 05/10/2022 16:58, Christopher Obbard wrote: Hi Arnaud, Thanks for shedding the extra light. This is not a nice bug ! I think we should ask the systemd maintainer if they'd accept a patch to make the enabling of systemd-resolved service a manual operation, or at least to split the binary into a separate package, something like systemd-standalone-resolved ? Dear systemd maintainers, the packages fakemachine & debos (which uses fakemachine) are facing an issue now that systemd-resolved was split in a separate package. For the background: fakemachine is a program that spawns a QEMU VM that "mimics" the host. It does so mainly by mounting /usr from the host into the VM, plus a few other bits from here and there. For the network to work in the VM, it relies on systemd-networkd and systemd-resolved. These programs need to be present on the host, so that they are available in the VM. For more details, you can just run "fakemachine" in a shell, then "ps fax | grep qemu" in another shell: you will see how fakemachine uses qemu. So far, the package fakemachine Depends on systemd, and that was enough. Now with the split, and since we need systemd-resolved, we should make fakemachine Depend on systemd-resolved as well. However, and if I understand properly, installing systemd-resolved also *enables* it. A user installing the package is saying: I want name resolution to be done by systemd-resolved. Therefore it's not really suitable to put it in a Depend or a Recommend. fakemachine only needs the code from systemd-resolved (lib and binary, I suppose), but it definitely doesn't want to enable it: this decision belongs to the user. Does that make sense so far? Not really, tbh. I think if you want to assemble a root/usr fs where you don't want do "disturb" the host system, I'd use a debootstrapped chroot but not the host fs. Say you want to install apache2 in your fakemachine managed VM, this would also start it on the host system, or not? I don't know why fakemachine does it this way and it's possible I'm missing something, but this approache feels "weird" to me, for the lack of a better word. Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1020691: debos should depend on systemd-resolved
On 05/10/2022 16:58, Christopher Obbard wrote: Hi Arnaud, Thanks for shedding the extra light. This is not a nice bug ! I think we should ask the systemd maintainer if they'd accept a patch to make the enabling of systemd-resolved service a manual operation, or at least to split the binary into a separate package, something like systemd-standalone-resolved ? Dear systemd maintainers, the packages fakemachine & debos (which uses fakemachine) are facing an issue now that systemd-resolved was split in a separate package. For the background: fakemachine is a program that spawns a QEMU VM that "mimics" the host. It does so mainly by mounting /usr from the host into the VM, plus a few other bits from here and there. For the network to work in the VM, it relies on systemd-networkd and systemd-resolved. These programs need to be present on the host, so that they are available in the VM. For more details, you can just run "fakemachine" in a shell, then "ps fax | grep qemu" in another shell: you will see how fakemachine uses qemu. So far, the package fakemachine Depends on systemd, and that was enough. Now with the split, and since we need systemd-resolved, we should make fakemachine Depend on systemd-resolved as well. However, and if I understand properly, installing systemd-resolved also *enables* it. A user installing the package is saying: I want name resolution to be done by systemd-resolved. Therefore it's not really suitable to put it in a Depend or a Recommend. fakemachine only needs the code from systemd-resolved (lib and binary, I suppose), but it definitely doesn't want to enable it: this decision belongs to the user. Does that make sense so far? I don't know how to solve best this situation. Maybe the the lib and binaries could go back into the systemd package, leaving only the "enablement" part in systemd-resolved? Thanks! -- Arnaud Rebillout / Offensive Security / Kali Linux Developer
Bug#1020691: debos should depend on systemd-resolved
merge 1020288 1020691 On Wed, 2022-10-05 at 14:36 +0700, Arnaud Rebillout wrote: > > > On Sun, 25 Sep 2022 12:28:19 +0100 Christopher Obbard > > wrote: > > > Because of this, on a machine which does not have > > > systemd-resolved installed, debos no longer works as > > > intended. > > > > > > Please add systemd-resolved as a runtime dependency to debos. > > > > It will fix debos but might break user's setup, or at least > surprise > > user, because systemd-resolved will take over name resolution > > on the machine where it's installed. > > > > Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020288 > > This comment also applies to fakemachine bug: > https://bugs.debian.org/1020690 > Hi Arnaud, Thanks for shedding the extra light. This is not a nice bug ! I think we should ask the systemd maintainer if they'd accept a patch to make the enabling of systemd-resolved service a manual operation, or at least to split the binary into a separate package, something like systemd-standalone-resolved ?
Bug#1020691: debos should depend on systemd-resolved
> On Sun, 25 Sep 2022 12:28:19 +0100 Christopher Obbard > wrote: > > Because of this, on a machine which does not have > > systemd-resolved installed, debos no longer works as > > intended. > > > > Please add systemd-resolved as a runtime dependency to debos. > > It will fix debos but might break user's setup, or at least surprise > user, because systemd-resolved will take over name resolution > on the machine where it's installed. > > Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020288 This comment also applies to fakemachine bug: https://bugs.debian.org/1020690 -- Arnaud Rebillout / Offensive Security / Kali Linux Developer
Bug#1020691: debos should depend on systemd-resolved
Hello Christopher! On Sun, 25 Sep 2022 12:28:19 +0100 Christopher Obbard wrote: > Because of this, on a machine which does not have systemd-resolved installed, > debos no longer works as intended. > > Please add systemd-resolved as a runtime dependency to debos. It will fix debos but might break user's setup, or at least surprise user, because systemd-resolved will take over name resolution on the machine where it's installed. Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020288 Best, Arnaud
Bug#1020691: debos should depend on systemd-resolved
Package: debos Version: 1.0.0+git20210707.c66a48d-2+b2 Severity: important Dear Maintainer, The latest systemd packages do not include systemd-resolved; it was split out into a seperate package. Because of this, on a machine which does not have systemd-resolved installed, debos no longer works as intended. Please add systemd-resolved as a runtime dependency to debos. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debos depends on: ii busybox1:1.35.0-2 ii debootstrap1.0.127 ii libc6 2.35-1 ii libglib2.0-0 2.74.0-1 ii libostree-1-1 2022.5-3 ii qemu-system-x861:7.1+dfsg-2 ii qemu-user-static 1:7.1+dfsg-2 ii systemd-container 251.4-3 Versions of packages debos recommends: ii bmap-tools 3.6-1 ii bzip2 1.0.8-5+b1 ii e2fsprogs 1.46.6~rc1-1 ii linux-image-amd64 5.19.6-1 ii mount 2.38.1-1 ii ovmf 2022.08-1 ii parted 3.5-2 ii udev 251.4-3 ii xz-utils 5.2.5-2.1 ii zip3.0-12 debos suggests no packages. -- no debconf information
