-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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`.
> 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).
> [^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).
[^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.
- --
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/THMrX1ywFAl77/rQACgkQ24/THMrX
1yzroQf/TRJy1e85XGN94zAOaZOWauQPGCwN/t9xiobMvNXZCBo82QipzlzfyplQ
HfYiDgSYQHosF3J0xf5R7bjnWsBnUkrejg3MHaX8xpBiaok3+IlCPrQ3nphBzbvb
pt1YwwTZQhpO7yAbnU5FWVGi/YoWUI23KzTdEB0kuiOi5BmpiD7uo1ib/aUhKNZC
Wmrc8CpiJRiKDdqXEN/40zlr7mBU70zYZldgQfa3u64eHmv2BShu5IrnuAo1pqb9
fBm4Nz0DiFSflTlQqm4WEROjufEtxV7/O0slanDTlWfwwnX+DMlmYRS7eUWvOsnw
i1yad1D2b7ZO+Nu+8JmnBFeSMXJtSA==
=lj7l
-----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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/20200701031044.GZ1197%40mail-itl.
