[pkg-go] Bug#1020691: debos should depend on systemd-resolved

[Arnaud Rebillout]

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