On Tue, Jan 11, 2022, at 4:00 AM, Panu Matilainen wrote:
> The point was though, that the rpmdb is not at all the only data of this > kind and so having a dedicated home makes sense. You mentioned dnf/yum/PackageKit data; there's two kinds of that. One is e.g. /var/cache/dnf which does *not* move. It's just a cache. (Now there is this whole other very interesting thread around "why don't we include a cache of the rpm-md inside e.g. ostree or container images? And the reason why not is we don't want to have to respin all images every time a package not in the image changes) dnf does have its own outside-of-rpm state database in /var/lib/dnf which is closer to this. The situation with that is messier. AIUI this proposal so far is not calling for moving this. Where it lives and how it's versioned has strong implications for the people who want to support snapshot/rollback. But it's not relevant for rpm-ostree, which does not use this part of libdnf. We maintain our own little "state file" - for lots more detail on this, see https://github.com/coreos/rpm-ostree/issues/2326 (And it's important to note that rpm-ostree's origin file has almost nothing *unless* one explicitly engages client-side layering/overrides) > For one, /state (or whatever toplevel directory) allows for the fact > that there are write-operations to rpmdb that do not touch any external > files while maintaining read-only /usr. Such as rpmdb --rebuilddb, `rpmdb --rebuilddb` is basically about supporting switching from e.g. bdb to sqlite, right? On the rpm-ostree side at least, the default format comes from the base image; there's no reason to directly support `rpmdb --rebuilddb` as something any normal user or admin would need. > or rpm --import. OK yes, this (along with rpms that install into /opt as you mentioned) are I think the biggest examples of "rpmdb has stuff not about /usr". rpm --import actually encapsulates really well all the problems and benefits with everything we're trying to do. I have a big related blurb here https://github.com/rpm-software-management/libdnf/issues/43 But as I understand it, the creation of /etc/pki/rpm-gpg was at least partially motivated by the fact that in the traditional RPM model, the fact that GPG keys are stored in the rpmdb meant there was no way to update them "in band" of a default rpm operation. Today Fedora ships these GPG keys as an RPM which hence contain files, and when you type `yum upgrade` (or rpm-ostree upgrade) you get updates to those files, the same as other files. Now, as noted in the issue PackageKit (whose code was the precursor to libdnf, which has the code that rpm-ostree uses but AFAIK still not current dnf which has this logic in Python) auto-imports all of them. I am not completely sure how updating the rpmdb with new e.g. Fedora GPG key works. It might be part of system-upgrade or something? And then this all relates to a higher level goal we have with "image based updates", which is avoiding (or minimizing as much as possible) per-system hysteresis or "unmanaged state", particularly opaque (hard to see/diagnose/inspect) state. This set of trusted GPG keys stored in the rpmdb is both. The set of keys will just keep growing across in-place upgrades, depending on the initial Fedora version installed. And wh And this is security-relevant state, it's the set of trusted keys for RPM. Now, I am sure a number of sysadmins do understand that the rpmdb contains GPG keys. I'd bet a whole lot don't. I definitely think that it's confusing to have both /etc/pki/rpm-gpg *and* keys stored in the rpmdb. Of the two, I think the former - i.e. text files one can edit with standard tools - is much easier to understand and work with. It's also already in a place that is designed for users to edit in `/etc`. So by moving the rpmdb to /usr, it's basically saying that `rpm --import` should change. That said, this design could also clearly use some "systemd style" config model. ostree already supports /usr/share/ostree/trusted.gpg.d which is designed for keys shipped by the OS vendor. But, what's really tricky about this is we want to support in-place updates from previous versions (i.e. at least N-1), but hopefully not too old versions. Well, this is leading to a tangent so I'll cut off this sub-thread. The TL;DR for me is: I think everyone agrees that moving the rpmdb as it is today to /usr is not 100% a perfect fit. But it's a ~90% fit - almost all the raw data is just headers which are clearly immutable data generated elsewhere. And by making this change, we're basically saying we'll fix the remaining 10% of cases. Note for the people who are trying to do "client side snapshot/rollback" (i.e. the people whose names are attached to the Change), the rpmdb is still mutable by default. And I think their idea is is that by doing a "snapshot, then upgrade in place via traditional rpm/yum methods" approach, the blast radius is then contained to what happens on explicit rollback. And that's then very limited to e.g. "I wanted to add a 3rd party RPM and did `rpm --import` to trust their key and then rolled back and lost that change" which is clearly not a big deal. For rpm-ostree's "image based" updates model, to avoid hysteresis we always construct a *new* root (just hardlinked) so any manual outside-of-rpm-ostree's control changes to `/usr` will always be thrown away, and that's why it's read-only. So having `rpm --import` fail is intentional today. But, I hope we can get agreement about something like having `rpm --import` write to `/etc/pki/rpm-gpg` and dropping gpg keys from the rpmdb. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
