Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/11/22 17:18, Colin Walters wrote:


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.

No, it's a database maintenance/repair operation. Converting between formats is merely a convenient side-effect.

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.

This doesn't seem to be documented as a dependency of this move...


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.

Rpm actually supports a keyring from the fs since 4.6 I think, it's just not integrated with --import and doesn't play that well along with the rest of the ecosystem because everything expects those gpg-pubkey "packages". We had bugs filed because somebody tried to use the fs-based thing but yum broke up.

The problem with fs based keyring is that packages can drop arbitrary unrelated keys in there, combined with the rpm model of imported == trusted. The trust aspect would have to be maintained in a place not directly accessible to packages.

That imported == trusted implication is of course a long-standing flaw in rpm but difficult to change because of all the assumptions that have been built around it. Everybody (me included) loves to hate the gpg-pubkey headers as we know them, but rpmdb as a keyring storage does make sense. I mean, rpmdb is data which rpm knows, and is free to store whatever it wishes there. Do understand that Fedora or anybody else moving it to /usr will not prevent rpm from adding more features that may need to modify it to store further data. So while it may seem "okay" now, it may as well not be that way in the future.

	- Panu -


	- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux