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 _______________________________________________ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
