status of meta-eid ?

status of meta-eid ?

[ydirson]

Hello,

The meta-eid project really looks promising (eg. with sbuild support), but the repo has not shown any activity for a couple of years.  Could someone summarize the status of this project ?

Best regards,
-- 
Yann

Re: status of meta-eid ?

[Baurzhan Ismagulov]

On Sun, Oct 24, 2021 at 07:46:36PM +0200, ydirson@free.fr wrote:
> The meta-eid project really looks promising (eg. with sbuild support), but
> the repo has not shown any activity for a couple of years. Could someone
> summarize the status of this project ?

Your impression is right, we haven't invested major efforts in it lately.

sbuild preview is available in [1]. If you are interested, we could share the
current state.

1. https://groups.google.com/g/isar-users/c/vNcgAkbdECI/m/vlyrDEqRAgAJ

With kind regards,
Baurzhan.

Re: status of meta-eid ?

[ydirson]

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

(sorry for somewhat breaking the thread, I'm apparently not receiving answers --
nothing new here from google servers unfortunately)

Re: status of meta-eid ?

[Henning Schild]

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.

regards,
Henning

> (sorry for somewhat breaking the thread, I'm apparently not receiving
> answers -- nothing new here from google servers unfortunately)
> 

Re: status of meta-eid ?

[ydirson]

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)

- 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.

- 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)

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.


[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

Re: status of meta-eid ?

[Henning Schild]

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
>