Re: status of meta-eid ?

[Henning Schild <henning.schild@siemens.com>]

Am Mon, 25 Oct 2021 13:15:42 +0200 (CEST)
schrieb ydirson@free.fr:

> Hi Henning,
> 
> > Am Sun, 24 Oct 2021 21:18:53 +0200 (CEST)
> > schrieb ydirson@free.fr:
> >   
> > > Hi Baurzhan,
> > >   
> > > > sbuild preview is available in [1].  
> > > 
> > > Nice!
> > >   
> > > > If you are interested, we could share the current state.  
> > > 
> > > I still have quite a lot in dig in right now, so don't divert
> > > efforts
> > > :)
> > > 
> > > My main focus for now is a bit far from this - I still need to get
> > > familiar with the current state of things, with in mind the idea
> > > of possibly using ISAR as a next-gen build system[1] for
> > > QubesOS[0] (a bit of a personal research project to see if it can
> > > help to improve the dev workflow there)
> > > 
> > > [0] https://qubes-os.org/
> > > [1]
> > > https://forum.qubes-os.org/t/ideas-for-next-generation-qubes-builder/6402
> > >  
> > 
> > Cater as a build system for an OSS project like qubes-os would be
> > cool.
> > I looked into 1 and it seems qubes-os is currently based on fedora.
> >
> > Making isar work for that would be possible but not an easy task. It
> > is
> > already hard to keep all the different flavours/versions of debian
> > maintained and working. Plus we are building on top of
> > qemu-debootstrap
> > for native builds of non-host architectures. A very powerful thing
> > that
> > might be missing some bits in other distros.
> > 
> > In fact Isar is not a lot of code, and most of it is very much
> > debian specific. The easiest way to go might be switching base
> > distros, which
> > might bring you "back in time" and on a slower release cycle your
> > might
> > be used to. And if you carry a lot of your own spec-files, those
> > will need translation into "debian/" folders.
> > 
> > Also note that Isars main feature is building complete bootable
> > images,
> > or OTA-update rootfss. For more than just a rootfs, partitioning and
> > bootloader stuff come into play. It also builds debian package repos
> > for later offline rebuild or for shipping package-based updates with
> > apt.
> > If your main concern is building packages, and maybe package repos
> > ...
> > it might be too big of a gun (but will work). On the other hand full
> > bootable image is what you might still need for automated continous
> > testing in qemu or on real devices.  
> 
> 
> QubesOS encompasses quite a number of things, the most prominent ones
> from my PoV being:
> 
> - the virtualization layer and dom0, which happen to be fedora-based
> today, but will likely not stay that way in the long run, see eg.
> [0].  This one will for a start essentially benefit from better
> package-building capabilities (eg. don't rebuild all dependent
> packages every time)

I guess that once can be moved to isar, and you might see some benefits
... depending on your current situation. For xen you might need to mess
with wic plugins. (the things that do partitioning and bootloader
install/configuration) But here you can change the ones in place or
heave custom ones in a layer. Last time i did use xen (very long time
ago) it involved several changes to the bootloader config to describe
the dom0 loading.

> - the VM templates, which include as standard Fedora, Debian, and
> Whonix. They are indeed OS images, and it will not be a large amount
> of work to produce those for Debian with ISAR, as all VM tools
> already come with Debian packaging.

Indeed, a VM is in fact the standard isar demo case and kind of the
lowest hanging fruit. If all tools are in debian it will boil down to
"IMAGE_PREINSTALL +=". Or if you have customizations it might be
packages that do stuff in "postinst" (like /etc/issue /etc/motd) and
pull in packages via DEBIAN_DEPENDS. These packages would then end up
in IMAGE_INSTALL.
 
> - the assembled OS itself, which is out of my scope for now (as I
> understand it, it is mostly a customized installer for the dom0 OS)

We have several layers where we do image-in-image. i.e. Isar built
containers in isar-built rootfs. Or isar-based VM in isar based host
image.

> This last point excluded, the first 2 ones both need to build some
> custom packages and modified versions of upstream ones, so ISAR
> features still seem to address a big part of the needs.
> 
> My plan (as outline in [1]) is to have a closer look at rootfs and
> package building, to get a measure of the amount of work to adapt for
> a rpm distro. I guess most of it can live in a separate meta-isar-rpm
> layer, and a meta-isar-qubes can be build on top of that.

Sure, get back here if you have any questions or are looking for a
"pattern" to solve a particiular problem.
Many things that can be done are not too obvious, or hidden in layers
that are not OSS.


Good public example layers are i.e. xenomai-image and jailhouse-images
and isar-cip-core.

Henning

> 
> [0] https://forum.qubes-os.org/t/alpine-linux-in-dom0/7077/4
> [1]
> https://forum.qubes-os.org/t/ideas-for-next-generation-qubes-builder/6402/2
>