|
|
Subscribe / Log in / New account

Relocating Fedora's RPM database

Relocating Fedora's RPM database

Posted Jan 13, 2022 11:22 UTC (Thu) by nim-nim (subscriber, #34454)
In reply to: Relocating Fedora's RPM database by matthias
Parent article: Relocating Fedora's RPM database

Basically any system is a mix of :

1. installation files (recreated on install, identical over many systems)
2. caches (transient stuff that exists to optimise performance and can be lost)
3. valuable data (the things that can not be recreated on install and are worth saving)

It‘s a triptych not a diptych.

The third category is usually the smallest in size but the most valuable. It is hard to manage so the temptation to pretend it does not exist (or will be managed by someone else, usually the cloud nowadays) is permanent

Putting 3. in /usr can not work unless /usr is redefined as something that does not fit static installs.

3. is also often pre-seeded from static installation data and it is tempting to conclude that because pre-seeding makes it “almost” installation data is can be conflated with installation data but that does not work in real life (real life test: what happens when the filesystem is wiped out).

Also a lot of apps do not support layered preseeding, preseeded data has to be deployed in the “valuable data” space on install, not in the “static data” space.

A lot of systems do not make the effort to separate 1. 2. and 3. they are in the 90% almost working category.

But 90% almost working is known as never working from the user side.


to post comments

Relocating Fedora's RPM database

Posted Jan 13, 2022 11:36 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (3 responses)

(For all its faults the FHS is the child of sysadmins that could not handwave away data loss)

Relocating Fedora's RPM database

Posted Jan 13, 2022 16:33 UTC (Thu) by smoogen (subscriber, #97) [Link] (2 responses)

Agreed. I got off the mailing lists and out of the argument because that is the fundamental gulf in understanding. There is computing which has clouds of failover data so that downtime can be limited due to 'unlimited VC money' and there is computing which is done on a typical shoestring budget which will take a long time to recover from if a 'reset' happens. Assuming /var should be wipeable and resetable at anytime works well in the 'we can just spin up more instances and keep cold copies or some other <fill in trend today> term' It doesn't work in 'real' systems administration where they are dealing with budgets set 20 years ago.

Relocating Fedora's RPM database

Posted Jan 13, 2022 17:07 UTC (Thu) by dbnichol (subscriber, #39622) [Link]

With my sysadmin hat on, I usually like to put application data (e.g., a website or repositories) in /srv whereas system program data (e.g., the package manager database) lives in /var. Some programs make this easier than others, but then it's straightforward for me to know where the data I actually care about is should it need to be backed up or migrated.

Relocating Fedora's RPM database

Posted Jan 13, 2022 19:45 UTC (Thu) by walters (subscriber, #7396) [Link]

No one is assuming /var is wipable at any time.

See https://lwn.net/Articles/881260/

Relocating Fedora's RPM database

Posted Jan 13, 2022 11:51 UTC (Thu) by taladar (subscriber, #68407) [Link] (3 responses)

I would actually split your 3 in two categories, configuration and state. Configuration is small and could be identical for a sort of soft-factory-reset, state is almost always the largest amount of data in size on the system and it is what most definitely can't be recovered if deleted, not even if you let someone work 24/7 for the next week or two (where you could probably rewrite the configuration from scratch).

Configuration and State

Posted Jan 13, 2022 18:02 UTC (Thu) by rfunk (subscriber, #4054) [Link] (2 responses)

Configuration files go in /etc. State currently goes in /var.

Configuration and State

Posted Jan 14, 2022 16:48 UTC (Fri) by jccleaver (guest, #127418) [Link] (1 responses)

> Configuration files go in /etc. State currently goes in /var.

There's an argument that updated "permanent state" should go in /etc/, since package install/removal makes changes to things in /etc/ as well. Consider /etc/shells, which may be updated by the installation of a new shell package. Or any of the myriad other caches and records in there.

I'd support a move from /var/lib/rpm to /var/rpm, but I'd sooner suggest /etc/ than a new top-level directory for this. The prohibition on binaries in /etc/ is about executable programs, not binary caches or records -- especially not of things that correlate explicitly with package install/removal.

Configuration and State

Posted Jan 15, 2022 15:33 UTC (Sat) by luto (guest, #39314) [Link]

Having /etc/shells be modified by installation of a shell is IMO a mistake. One could construe shells(5) as a *cache* indicating what shells live in /usr/bin, in which case it should live in /var/cache. Or one could construe it as administrative policy, in which case package scripts have no business touching it, and /etc/shells should be an optional override of /usr/etc/shells.

Relocating Fedora's RPM database

Posted Jan 13, 2022 12:08 UTC (Thu) by matthias (subscriber, #94967) [Link] (1 responses)

> It‘s a triptych not a diptych.

Of course. I did not talk about your 1., as I was talking about /var and the installation files should be under /usr. And actually I would add a forth type: system configuration, i.e., the data usually found under /etc. Of course, configuration data is often valuable, but it is still different in the sense that it is also often system dependent. You cannot simply copy /etc to a different system and expect the things to just work.

> The third category is usually the smallest in size but the most valuable.

This depends on the use case. In many cases it is the largest in size by orders of magnitude. Our family photo collection alone is far bigger than 1.+2.

The valuable data is usually stored in /home, /var, or both, depending on whether it is managed by a user or by a system application (like a database engine). For the data in /home it is quite obvious that one wants to have a backup, but some of the data in /var is equally important. And having a backup of the system configuration under /etc is definitely not the worst thing either.

> A lot of systems do not make the effort to separate 1. 2. and 3. they are in the 90% almost working category.

Actually, the installation files (1.) are mostly separated under /usr. Whether this is a separate volume or just a folder does not really matter for most people. And for those who care this can be easily arranged as a separate volume. The mess is below /var and also below /home. In both places 2. and 3. are mixed up. Under /home there are, e.g., browser caches. Clearly not the most important thing to backup.

And I definitely agree that there should be some effort to separate these things. In this way, I really like much of the systemd development. All the systemd support for containers and stateless systems needs a clean filesystem layout. Fork a new instance by reusing /usr and providing a fresh (empty) /var. And they are also working hard on reducing the necessary configuration under /etc, thus that containers and similar lightweight systems can gather all necessary data from the environment (e.g. network configuration by dhcp) and /etc can be empty on system startup. Let's hope that they do not stop halfway and continue cleaning up. There is still some way to go.

Relocating Fedora's RPM database

Posted Jan 13, 2022 13:44 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

I agree 1. is mostly clean in /usr nowadays, it took decades of integrator work but it is mostly done.There is this awful temptation to declare “mission accomplished, everything else can be wiped out”. Some container people are definitely thinking this way.

The next frontier is sorting out 2. and 3.

Relocating Fedora's RPM database

Posted Jan 13, 2022 13:25 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

> A lot of systems do not make the effort to separate 1. 2. and 3. they are in the 90% almost working category.

And not that I had anything of importance there, I don't think, but I think I've just lost /var from my old system. And it had things like my personal wiki, I think the mail system stored a load of stuff there, etc etc. /var actually contains a lot of data (like other people said, databases), and its loss is NOT a minor matter.

I've now got into the habit of stashing most stuff in /home somewhere, but it would be nice if there was some way of separating stuff like user databases from other stuff like system databases (mail, printer spools, gentoo's installation stuff, whatever whatever).

Cheers,
Wol

Relocating Fedora's RPM database

Posted Jan 13, 2022 20:38 UTC (Thu) by JanC_ (guest, #34940) [Link]

There is also /srv where you can store things like wikis & databases if they aren’t user-specific or have to be used by multiple users.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds