On Wednesday, July 1, 2020 11:10 AM, Marek Marczykowski-Górecki <[email protected]> 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`. (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 :) ).
[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.)
> > [^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?
> [^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
--
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/AcLUEa3QM6VZy7VBWyY_EJyPFuV_C1RCEgJWPpzAWZ4zz-gQFJZXvosg99C8JaeCQfYso7NjPnfqyuYpEvX_HBl0anMFLm9QtX1FvD5kLhA%3D%40nerde.pw.
publickey - [email protected] - 0xD02DCEFF.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
