Relocating Fedora's RPM database
Relocating Fedora's RPM database
Posted Jan 13, 2022 10:02 UTC (Thu) by nim-nim (subscriber, #34454)In reply to: Relocating Fedora's RPM database by lamawithonel
Parent article: Relocating Fedora's RPM database
/var as it exists today is in sore need of restructuring, but returning to the bad old days where everything static is in /usr and everything that does not fit the classification is stuffed in /home to avoid thinking about it is not a solution.
Posted Jan 13, 2022 10:31 UTC (Thu)
by matthias (subscriber, #94967)
[Link] (14 responses)
I am not sure whether they do. The idea seems to be to wipe /var (and /etc) as a factory reset. Having a real database in /var is no contradiction. Of course, the data would be lost if wiping /var, but this is actually what I would expect from a factory reset.
But I see your point that there is a clear difference between /var/cache and a database. The data in /var/cache is expected to be recoverable (e.g. by recomputation), while a database holds data that would be lost irrevocably. Thus having a better structure of /var would be nice. Or perhaps splitting /var, one part for user data (e.g. databases) and a second part for intermittent data (/var/cache, /var/spool, /var/log, etc.). The first part is the part that you might want to move to a different system just as you would want to transfer the files under /home, while you usually do not care about the second part if you migrate to a new system.
The rpm database fits into neither of these two categories. It cannot be easily regenerated and it is no user data that you might want to use on a different system.
Posted Jan 13, 2022 11:22 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (12 responses)
1. installation files (recreated on install, identical over many systems)
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.
Posted Jan 13, 2022 11:36 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (3 responses)
Posted Jan 13, 2022 16:33 UTC (Thu)
by smoogen (subscriber, #97)
[Link] (2 responses)
Posted Jan 13, 2022 17:07 UTC (Thu)
by dbnichol (subscriber, #39622)
[Link]
Posted Jan 13, 2022 19:45 UTC (Thu)
by walters (subscriber, #7396)
[Link]
Posted Jan 13, 2022 11:51 UTC (Thu)
by taladar (subscriber, #68407)
[Link] (3 responses)
Posted Jan 13, 2022 18:02 UTC (Thu)
by rfunk (subscriber, #4054)
[Link] (2 responses)
Posted Jan 14, 2022 16:48 UTC (Fri)
by jccleaver (guest, #127418)
[Link] (1 responses)
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.
Posted Jan 15, 2022 15:33 UTC (Sat)
by luto (guest, #39314)
[Link]
Posted Jan 13, 2022 12:08 UTC (Thu)
by matthias (subscriber, #94967)
[Link] (1 responses)
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.
Posted Jan 13, 2022 13:44 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link]
The next frontier is sorting out 2. and 3.
Posted Jan 13, 2022 13:25 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
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,
Posted Jan 13, 2022 20:38 UTC (Thu)
by JanC_ (guest, #34940)
[Link]
Posted Jan 21, 2022 16:10 UTC (Fri)
by Jonno (subscriber, #49613)
[Link]
Doesn't /srv already serve that use-case already? The FHS say it is for "site-specific data which is served by this system", which I sure read as including user data such as databases (or websites, or maildirs, etc).
For example, my mysql server uses /srv/myqsl as the datadir, and my imap server uses /srv/mail. (My smtp server uses /var/spool/postfix for in-flight messages, but emails destined for local users are delivered to /srv/mail/${USER}/.INBOX/).
Posted Jan 13, 2022 14:09 UTC (Thu)
by walters (subscriber, #7396)
[Link]
Or to restate this, around separating /usr and /var - "factory reset" is only one half of the coin. The other half is knowing that OS upgrades won't affect your user data. See for example https://github.com/coreos/rpm-ostree/pull/888 which I am still very proud of =)
Relocating Fedora's RPM database
Relocating Fedora's RPM database
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)
Relocating Fedora's RPM database
Relocating Fedora's RPM database
Relocating Fedora's RPM database
Relocating Fedora's RPM database
Relocating Fedora's RPM database
Configuration and State
Configuration and State
Configuration and State
Relocating Fedora's RPM database
Relocating Fedora's RPM database
Relocating Fedora's RPM database
Wol
Relocating Fedora's RPM database
Relocating Fedora's RPM database
> [...]
> Or perhaps splitting /var, one part for user data (e.g. databases) and a second part for intermittent data (/var/cache, /var/spool, /var/log, etc.).
Relocating Fedora's RPM database