On Friday, July 3, 2020 5:28 AM, Marek Marczykowski-Górecki <[email protected]> wrote:
> On Thu, Jul 02, 2020 at 06:57:37PM +0000, WillyPillow wrote: > > > 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`. > > 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. Currently qvm-template does handle version and release separately. (Though I'll have to include the epoch later.) The reason I did this is because AFAIK, comparing RPM versions is not exactly trivial [^rpm], and storing them separately allows me to use `rpm.labelCompare` to do the job. [^rpm]: <https://blog.jasonantman.com/2014/07/how-yum-and-rpm-compare-versions/> > > (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. Awesome! I've also edited the titles of the PRs to make them (& the board) more clear. > > > > 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. Also, after an initial version of repo handling is finished, should I put `qvm-template` in `qubesadmin/tools` or somewhere else? 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/cnjISC_2lXbW89RLuNhjCPXOuNJXjujOSiF2K86ekhmihh2yYjTxIi43zSQZcyTvYtfCmLvWxdFmucul5lSVOKgkoYfuqtLtZfY-wtpHdD0%3D%40nerde.pw.
publickey - [email protected] - 0xD02DCEFF.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
