-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thu, Jul 02, 2020 at 06:57:37PM +0000, WillyPillow wrote:
> On Wednesday, July 1, 2020 11:10 AM, Marek Marczykowski-Górecki
> <marma...@invisiblethingslab.com> wrote:
>
> > On Tue, Jun 30, 2020 at 07:21:23PM +0000, WillyPillow wrote:
> >
>
> > > So to add the repo interaction functionality to the template manager, I've
> > > spent a while reading the docs of `python-dnf`. However, it occurred to
> > > me that
> > > as one should be able to use the manager from both dom0 and mgmtVMs, I
> > > have to
> > > deal with both `qubes-dom0-update` and `dnf`.
> > > As such, I'm thinking that perhaps invoking the CLI tools -- mostly `dnf
> > > {download,repoquery}`[^1] and the `qubes-dom0-update` equivalents [^2] --
> > > directly might be an easier way of approaching this?
> >
>
> > Somehow I don't like this idea. Mostly because I consider
> > `qubes-dom0-update` tool a big hack that is very fragile to extend. The
> > dom0<->VM interface there is very loosely defined as "options like for
> > dnf, with few exceptions", but it happens that depending on yum/dnf
> > version inside of the VM, this may not also work that well - especially
> > if the VM is Debian-based[^3], then you get only yum+yumdownloader which
> > does some things differently (and also have different output format).
> > This flexibility in options is nice for the user, because they can use
> > qubes-dom0-update almost as a drop-in replacement for dnf, with all the
> > features. But not that good for integrating into another script as you
> > don't have standardized interface and switching
> > template/version/something can mess things up.
> >
>
> > I recommend writing a simple set of qrexec services, which may
> > internally use `dnf repoquery`, but have defined interface. As for
> > handling dom0 and mgmt vm case - it isn't that different, in mgmt vm you
> > can simply call /etc/qubes-rpc/* script directly[^4], skipping qrexec
> > transport and keep the interface the same.
> >
>
> > In case of managing templates, I think those services can be much
> > simpler than full qubes-dom0-update. If I haven't missed anything, you
> > need two:
> >
>
> > 1. list available templates in a defined format (perhaps with some
> > limiting options, like which repository, or a patter for template name).
> >
>
> > 2. download a template
> >
>
> > Since you don't really care about dependencies for template rpm package,
> > you don't need to send rpmdb and similar data from dom0. You just need
> > repository configuration (or maybe just repository url?).
> > As for downloading - if the service would download directly to stdout,
> > instead of to file that is later send over another qrexec call, you can
> > get nice progress indicator directly in template manager (instead of
> > non-machine readable bar rendered by dnf). It should be quite easy - ask
> > dnf for the URL, then call `curl`.
>
> I see. I've opened a PR containing a PoC of this on `core-agent-linux`.
Besides comments I've left there, overall looks good.
I'm not sure if splitting epoch, version and release into separate
fields makes much sense - qvm-template would treat all three together as
a "version" anyway. But it shouldn't hurt either.
> (BTW,
> I've also opened PRs on the previously modified repos.) Additionally, the
> design doc [gist] has been updated to describe the protocol (and include a
> small progress tracker :) ).
I haven an idea, maybe we can try to use github projects feature to
track this?
I've created one here:
https://github.com/orgs/QubesOS/projects/1
And added all pull requests.
> [gist]: https://gist.github.com/WillyPillow/b8a643ddbd9235a97bc187e6e44b16e4
>
> > > Somewhat related question: is it reasonable to assume that mgmtVMs have
> > > network
> > > access? Or do we have to use a mechanism similar to `qubes-dom0-update`
> > > and allow downloading from another updateVM?
> >
>
> > While in practice some MgmtVMs will have network access, I don't think
> > we should assume that. For example, sys-gui which is kind of MgmtVM do
> > not need network access (and by default it doesn't have).
>
> Perhaps then we can have an option that lets the user decide whether qrexec or
> DNF from the mgmtVM itself should be used? (With the default being the
> former.)
Yes, that also could be an option.
> > > [^1]: Interestingly, the output of `dnf repoquery` seems to be
> > > machine-readable.
> > > [^2]: These actions may have to be added.
> >
>
> > [^3]: Debian mgmt vm would be an issue regardless, as dnf nor python-dnf
> > is not packaged there yet (work in progress).
>
> As long as the VM running the qrexec server is Fedora-based, I suppose this
> would not be a big problem?
Yes, currently this is a requirement. Once DNF will be in Debian, it
should "just work" there too.
> > [^4]: One thing to be careful about - if such service would execute
> > qrexec call back to the caller (like qubes-download-dom0-updates.sh
> > does), then this also would require a special case. But this "callback"
> > approach can be avoided.
>
> Thanks,
> WillyPillow
>
> > https://blog.nerde.pw/
> >
> > PGP fingerprint = 6CCF 3FC7 32AC 9D83 D154 217F 1C16 C70E E7C3 1C84
> >
> > Protonmail PGP = D02D CEFF ACE5 5A7B FF5D 871E 4004 1CB1 F52B 127E
- --
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/THMrX1ywFAl7+UXsACgkQ24/THMrX
1ywEhQf/SwgoXo3cJPPeAHH8waSYDqiW4Fv0JIU2KpfpZywcC4wdSP7eNnbWH3yz
3GdRMqAynSWl/+sD6rCFIy8Vj8iH6ElCNKEpDI1oSYQcQgia7lmrUsYwUms1s0IM
Tvozx8MJyHvEePEMnz1FoPM6h/ARapYh5WgfPoSXJ3zQ+xKr0fOjk3IcokVfpco9
69jUpdYMwYJA4iblsXMhBwI+GCG/MFBr3boi+QDGKZ+bappfaUuOpl+vEt9xgZqM
UWuvX3w9A0BffrG/sm1Qn1F2NjA0z970AtE8hZ/uQQ5vmC4WNtt7zSjFE0az/i9h
aThmAjL+DINVDpYJVuJPfQGCwx3zFA==
=tIJ0
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/20200702212826.GC102503%40mail-itl.
