Fwd: Void Linux on QubesOS - packaged.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek, what do you think?

(CCing qubes-devel with author's permission.)

- -------- Forwarded Message --------
Subject: Void Linux on QubesOS - packaged.
Date: Thu, 31 May 2018 13:55:23 +0200
From: Lucy Liu <snow.d...@gmail.com>
To: a...@qubes-os.org

Dear Mr. Wong

Recently I made an effort and ported the software for a QubesOS VM to
another distribution,
provided as packages within an unofficial repository.
It's available as source for their build system including the instructions
and as well as a downloadable template vm ready to use.

The Distribution I'm speaking about is Void Linux.
You may read more about the port here:
https://forum.voidlinux.eu/t/void-linux-on-qubesos-4-packaged/5714

I've seen you have listed the community supported template VMs on your
website.
Maybe this could be another candidate?

However that beeing said, I'm not part of the Void Linux team. These
packages are unofficial and would potentially not meet their very strict
criterias.
Some not so pretty workarounds were required due to the very minimalistic
init system. I'm also honestly a bit concerned about the future of QubesOS
when it comes to init system restrictions that *eventually* may happen. So
I just wanted to say I'm glad that so far it works also without systemd.

Your sincerely,
Lucy von Känel

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlsP+jQACgkQ203TvDlQ
MDCjoQ//Yym5cT4iAPAZfuhFt+P0gLDQxryPOMNYYknY/Iy1AHIJWm9P687Xgppw
9t1+AvxW2KSk6dA2f0Ekm14ALLCGEj0IB7SwwEo8g1dt0Mk+WXBfTteBMTP4CMUz
xCyTR3FJR/4lud2jMD8xjfZJH0SGgs//RsiQ28u2nJ3CTuqiZi4afrtaAaaEyyy0
x4M9DUD3JsVll7BdgbTp+PGQ7jsgo8xbLgGm09vAp1DuJch4T0lNkHpH8XTMvw+0
FgGA8eY+0dMatV6qF87gbVvalVVr9TR1LIg2mW6CEXHSgtyPkFSXJS4KqTfWte9B
PNjtvwD0joLDZkuB3wtR/ZCPWG/YC7Whs3vFKT3lklmBQP6V3UzbWjWuE9Ee50m3
baRAhAOb04vU8+GbuIN+Se0uDThseNRhciTEYNIBCbTvLSL7Mhm/91+NlyBeylF0
/m1I8QXC5kGqA4GxsRPG6Tu6ikAhkbLhf+3rJ/6Lgo+N+Xc7NXtE+ApIhvjLmOqS
8cc1DKM5QScAQ6DfRvUbcfkTOxzqC1dDmq4iphNpXMnL4wn6b9pDN7+3rbsMarZo
d+jNpX8baty6AaQDUFwOYdVC8m1xbR8B+i0hrRVj/Y3bghaNOhv9ApYHWXZPpDSR
rGUyK7UIckwMWZFmXYRGvtJhI4sjMIUX6ZqNdgR9dydBC/9qWAU=
=QqBs
-----END PGP SIGNATURE-----

[Frédéric Pierret (fepitre)]

Hello,

From my side, I think that it worth to look at how to proceed in the Qubes way to build a template. A step would be to create a "builder-void" and to implement inside each component the mechanism of building the package. Like I did to create a builder-gentoo (not currently available sorry because not yet finished), inspiration can be taken from builder-archlinux (https://github.com/QubesOS/qubes-builder-archlinux) because there is no so much particular cases to handle like in builder-rpm or builder-debian.

Globally, the first step for creating a builder is to have a way of creating a minimal chroot of Void Linux where packages will be built inside. Then, inside the components needed for a template, a specific target must be done when the distro is Void Linux. For example, have a look at Makefile.builder inside vmm-xen (https://github.com/QubesOS/qubes-vmm-xen/blob/xen-4.8/Makefile.builder).

Don't hesitate to ask for any help.
Frédéric

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Jun 02, 2018 at 01:23:20AM -0700, Frédéric Pierret (fepitre) wrote:
> Le jeudi 31 mai 2018 15:36:05 UTC+2, Andrew David Wong a écrit :
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > Marek, what do you think?
> >
> > (CCing qubes-devel with author's permission.)
> >
> > - -------- Forwarded Message --------
> > Subject: Void Linux on QubesOS - packaged.
> > Date: Thu, 31 May 2018 13:55:23 +0200
> > From: Lucy Liu <snow.d...@gmail.com>
> > To: a...@qubes-os.org
> >
> > Dear Mr. Wong
> >
> > Recently I made an effort and ported the software for a QubesOS VM to
> > another distribution,
> > provided as packages within an unofficial repository.
> > It's available as source for their build system including the instructions
> > and as well as a downloadable template vm ready to use.
> >
> > The Distribution I'm speaking about is Void Linux.
> > You may read more about the port here:
> > https://forum.voidlinux.eu/t/void-linux-on-qubesos-4-packaged/5714
> >
> > I've seen you have listed the community supported template VMs on your
> > website.
> > Maybe this could be another candidate?

Yes, definitely!
Personally I'd see it as a good fit for minimalistic single-purpose VMs
like split-gpg backend holding gpg keys. Or a base for DispVM converting
PDFs. But there are for sure more use cases for that.

> > However that beeing said, I'm not part of the Void Linux team. These
> > packages are unofficial and would potentially not meet their very strict
> > criterias.
> > Some not so pretty workarounds were required due to the very minimalistic
> > init system. I'm also honestly a bit concerned about the future of QubesOS
> > when it comes to init system restrictions that *eventually* may happen. So
> > I just wanted to say I'm glad that so far it works also without systemd.

Generally we try to not depend on systemd too much, but the fact that
all currently existing templates have it make it convenient to use some
of its shortcuts. I try to maintain Sys-V init scripts, but they are
not tested for a long time, so expect some things being out of sync.
We do use .socket and .timer units. It's easy to have non-systemd
equivalent (using socat/xinetd and cron, respectively), but when systemd is
present, using those units reduces resource usage.

If there will be a template without systemd, it will be much easier to
keep non-systemd scripts up to date.

> Hello,
>
> From my side, I think that it worth to look at how to proceed in the Qubes way to build a template. A step would be to create a "builder-void" and to implement inside each component the mechanism of building the package. Like I did to create a builder-gentoo (not currently available sorry because not yet finished), inspiration can be taken from builder-archlinux (https://github.com/QubesOS/qubes-builder-archlinux) because there is no so much particular cases to handle like in builder-rpm or builder-debian.
>
> Globally, the first step for creating a builder is to have a way of creating a minimal chroot of Void Linux where packages will be built inside. Then, inside the components needed for a template, a specific target must be done when the distro is Void Linux. For example, have a look at Makefile.builder inside vmm-xen (https://github.com/QubesOS/qubes-vmm-xen/blob/xen-4.8/Makefile.builder).

Actually, vmm-xen might be optional, if Void linux have needed stuff
packaged. Especially libxenvchan library. There are some Qubes-specific
patches, but very few of them are even touching code used outside of
dom0 and most important patches are already in upstream version.

Anyway, Frédéric is right about next steps and how to proceed.

Re https://github.com/Nexolight/void-tainted-pkgs/tree/qubes/QubesOS

| Runit doesn't play very well with the style the Qubes services are meant to be used. It required some hacky workarounds.

Can you elaborate? Is it about service dependencies? I'd like to make it
easier not harder to package qubes package for various distributions.


| Make sure your partition setup looks like this:
|
| /dev/xvda1 1M BIOS boot
| /dev/xvda2 EFI System
| /dev/xvda3 Linux filesystem
|
| especially /dev/xvda3 is hardcoded by the devs in the initramfs!

Technically, if you use gpt and make it "Root filesystem", it can be a
different partition. But if it isn't the last one, you won't be able to
dynamically resize root fs, so better stick to this layout.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlsV1hMACgkQ24/THMrX
1ywFegf+PqWXWwUKKBsNy7j8xFaiKIBk63+D5EK/IKSzW8xMY5fzTw/iOQMqBhu0
btEOFJJmUrY+msbv3Y+06zxeTD7IBQHS9vOVOoTot5ZvCuAtyIruMoc68nS/y129
p8C0l7iljJiDA77BDGGRLfRhDhqbJ+B8tBQ/N74lfxR4iH+/H5FwiMd4nAhj/+tz
xXXIN2H6MFxivTeXnmpiopk7BCVLsqB3oGV5bvkM9D2yhhjI4SB3ywnk6QCxZnDt
o0oLcMTELHCtW4aW7DXN3F2lQ8hxz1qZFisll6zcqIlnhzA4Sv5K/fjbkIXLIp2+
FQ+DzDJsyIQfN/yEQ/3KJOPcEI7qfw==
=wdjB
-----END PGP SIGNATURE-----

[nexolight]

> Re https://github.com/Nexolight/void-tainted-pkgs/tree/qubes/QubesOS
>
> | Runit doesn't play very well with the style the Qubes services are meant to be used. It required some hacky workarounds.
>
> Can you elaborate? Is it about service dependencies? I'd like to make it
> easier not harder to package qubes package for various distributions.

Yep that is the main problem.
At the beginning I tried to make runit services for everything. But that ended up not working very well. In particular Runit does not allow "oneshots". This can be sort of bypassed in void as it has

"/ets/runit/core-services/99-00-whatever"

This is however executed before any of the regular services start. These are not really services.

Then there's /etc/sv/someservice/run

That's the place for a service. Runit uses supervision. It doesn't really allow forking. Nor does it allow dependencies. There's a fork-wrapper that can help with forking processes. There's also a "check" command that will start another service first and wait up to 7 seconds or timeout of the other one. But there's no real way to do "before XY" and/or "after XY".

I also had to put some things into /etc/rc.local as it did not really work as a runit service.

After all I managed to get it work but it's a mess. And I'm not sure if I got the order right. I could post it for a short review.

> Actually, vmm-xen might be optional, if Void linux have needed stuff packaged. Especially libxenvchan library. There are some Qubes-specific patches, but very few of them are even touching code used outside of dom0 and most important patches are already in upstream version.

I'm not sure anymore why exactly I packaged it but I know it had a reason or there was at least a problem with the xen package in the repository. I guess it was somehow related to libxenvchan.

> If there will be a template without systemd, it will be much easier to
> keep non-systemd scripts up to date.

Runit doesn't use this kind of init scripts. It's much more lightweight. I'm not sure why these scripts would benefit from that.

> From my side, I think that it worth to look at how to proceed in the Qubes way to build a template. A step would be to create a "builder-void" and to implement inside each component the mechanism of building the package. Like I did to create a builder-gentoo (not currently available sorry because not yet finished), inspiration can be taken from builder-archlinux (https://github.com/QubesOS/qubes-builder-archlinux) because there is no so much particular cases to handle like in builder-rpm or builder-debian.

> Globally, the first step for creating a builder is to have a way of creating a minimal chroot of Void Linux where packages will be built inside. Then, inside the components needed for a template, a specific target must be done when the distro is Void Linux. For example, have a look at Makefile.builder inside vmm xen (https://github.com/QubesOS/qubes-vmm-xen/blob/xen-4.8/Makefile.builder).

I already answered to this but I guess it ended up not here. I'm not very familiar with mailing lists and google groups.

The builder at first looked to complicated to start with it, so I went with the manual installation and made the packages for this method.

If I'm able to chroot into the install directory of the void template during the build process with the builder, download, use and remove xbps-src there, then it will be very straightforward. It's their build environment that allows to build the packages in any repository from source and then install them locally from the build folder. For this it downloads the required build dependencies into a chroot directory and builds the packages there. Xbps-src can be removed after that by a simple rm -rf command. If I'm not able to use it then it might take me too long.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Jun 05, 2018 at 10:22:21AM -0700, nexolight wrote:
> > Re https://github.com/Nexolight/void-tainted-pkgs/tree/qubes/QubesOS
> >
> > | Runit doesn't play very well with the style the Qubes services are meant to be used. It required some hacky workarounds.
> >
> > Can you elaborate? Is it about service dependencies? I'd like to make it
> > easier not harder to package qubes package for various distributions.
>
>
> Yep that is the main problem.
> At the beginning I tried to make runit services for everything. But that ended up not working very well. In particular Runit does not allow "oneshots". This can be sort of bypassed in void as it has
>
> "/ets/runit/core-services/99-00-whatever"
>
> This is however executed before any of the regular services start. These are not really services.

How for example iptables rules are loaded normally? Or kernel modules?
Those are examples of "oneshots" that could be found on any system.
Maybe something similar could be used?

> Then there's /etc/sv/someservice/run
>
> That's the place for a service. Runit uses supervision. It doesn't really allow forking. Nor does it allow dependencies. There's a fork-wrapper that can help with forking processes. There's also a "check" command that will start another service first and wait up to 7 seconds or timeout of the other one. But there's no real way to do "before XY" and/or "after XY".

Hmm, that's weird. How one starts a service that require a network up,
for example? Or an application that require database server running
already? Is is just about sorting with appropriate number-prefixed name?
That also should be good enough...

> I also had to put some things into /etc/rc.local as it did not really work as a runit service.
>
> After all I managed to get it work but it's a mess. And I'm not sure if I got the order right. I could post it for a short review.
>

> > If there will be a template without systemd, it will be much easier to
> > keep non-systemd scripts up to date.
>
> Runit doesn't use this kind of init scripts. It's much more lightweight. I'm not sure why these scripts would benefit from that.

Ah, ok.

> > From my side, I think that it worth to look at how to proceed in the Qubes way to build a template. A step would be to create a "builder-void" and to implement inside each component the mechanism of building the package. Like I did to create a builder-gentoo (not currently available sorry because not yet finished), inspiration can be taken from builder-archlinux (https://github.com/QubesOS/qubes-builder-archlinux) because there is no so much particular cases to handle like in builder-rpm or builder-debian.
> > Globally, the first step for creating a builder is to have a way of creating a minimal chroot of Void Linux where packages will be built inside. Then, inside the components needed for a template, a specific target must be done when the distro is Void Linux. For example, have a look at Makefile.builder inside vmm xen (https://github.com/QubesOS/qubes-vmm-xen/blob/xen-4.8/Makefile.builder).
>
> I already answered to this but I guess it ended up not here. I'm not very familiar with mailing lists and google groups.
>
> The builder at first looked to complicated to start with it, so I went with the manual installation and made the packages for this method.
>
> If I'm able to chroot into the install directory of the void template during the build process with the builder, download, use and remove xbps-src there, then it will be very straightforward. It's their build environment that allows to build the packages in any repository from source and then install them locally from the build folder. For this it downloads the required build dependencies into a chroot directory and builds the packages there. Xbps-src can be removed after that by a simple rm -rf command. If I'm not able to use it then it might take me too long.

That's also an option, rather hacky, but should work. IMO that's a good
start.
BTW Whonix have it the same way - initially everything was built in the
template build stage using the same chroot as final template.

The proper way do something similar to what you propose, as you can see
in qubes-builder-archlinux/Makefile.archlinux, there is
dist-prepare-chroot to prepare this chroot (Archlinux downloads
bootstrap tarball for that), then (among other things) there is
disp-package that basically execute "chroot $CHROOT_DIR
command-to-build-package".
But we can get there later.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlsm+WYACgkQ24/THMrX
1yzPvgf5AZtG2LOg6+NtAC+bDXHwagJ1c1ZCQgQPY25Rh0yONhwOSkPYNjVDzqu9
zKXDWAgAchRE0dquJjyAxm4VQ3CP+eclSqP3OZLFaaCsr6VhUfJTNdRDaWHVTCnf
AKGNirWe84IWgj15ZKWTYZlzOYt1tCu1iBl7UpNfQTKO7xRY5BVg0R2Z3k3F7cLP
ipLrk5UensckXd26sV4IAjwGiw9AQoOakILJ5H9i+seaNlsedQ9faMK7/lEyK81z
Ddl7trhEK/MxHQx5ZI0gWLAXvHoOON+NzUa3Xxk429KNydu9oUJB+VZDyCA2f6on
ANN1vr36G1j56ob7wAWS7nakn2pLqA==
=y1O7
-----END PGP SIGNATURE-----