Systemd Change Allows For Stateless Systems With Tmpfs

[RahulSundaram]

/usr is for user related things
/etc is for system wide settings
$HOME/.config/ is for user specific configs

from the FHS "/usr : Secondary hierarchy for read-only user data; contains the majority of (multi-)user utilities and applications."

EDIT: user things that are system wide and the package manager for some reason can't just leave be can go into a subdirectory or idk "$THATCONFIGDIRNAME-user" or something

Home cannot be used for setting overrides when it is not user specific. A common pattern for a lot of programs these days is to drop vendor configuration in /usr/lib and user defined custom overrides in /etc/. That way there is clean separation for *system* wide defaults.

[gens]

You can't use $HOME/.config/ for administrator-specific settings for system daemons since those daemons could not read from the user's home dir.
And /etc/ IS being used for system-wide settings, its just using /usr/lib as a backup-config location.

Also im reposting this link...

http://0pointer.de/blog/projects/stateless.html

If distros want to ship a 'golden master' image or a cryptographically verifiable image then it can't include /etc/, /tmp, or /var/ since those directories would be machine-specific and would change the hash.

... /etc/ for system-wide settings, nothing else
well.. /lib/ for kernel/modules settings

you can repost that blog all you want
if you read it and it is clear and makes sense, then you can make a good point
but there is no good point in using /usr/lib/ for system-wide settings, it's just plain stupid
i hope you can agree with that

the FHS is there for a reason, and it's mostly very good


EDIT: i think i know where the confusion is coming from
when i say "user related" i mean that they are for use by the user
so /usr/lib/ is for libraries that are for programs that a user uses, like the ones in /bin

while you are thinking of "user specific"
user specific programs and libraries have their own place, and it's not in /usr/lib/ or /usr/bin/

[Ericg]

so...
instead of just copying or better yet untaring some defaults, they should be hardcoded into some executable ?
if this is like that, that i doubt it is, then that's just plain stupid

From the blog...

Given that there are probably many cases like this we are working with a number of folks to introduce a new directory called /usr/share/etc (name is not settled yet) to major distributions, that always contain the full, original, vendor-supplied configuration of all packages. This is very useful here, so that there's an obvious place to copy the original configuration from, but it is also useful completely independently as this provides administrators with an easy place to diff their own configuration in /etc against to see what local changes are in place.

[duby229]

From the blog...

From your blog quote, that is exactly what etc-update is used for in gentoo builds. I'm pretty sure most distros have that covered.

[Karl Napf]

... /etc/ for system-wide settings, nothing else
well.. /lib/ for kernel/modules settings

you can repost that blog all you want
if you read it and it is clear and makes sense, then you can make a good point
but there is no good point in using /usr/lib/ for system-wide settings, it's just plain stupid
i hope you can agree with that

Having the pristine state as defined by the distribution outside of /etc is really nice: That way you can get diffs to a (hopefully) known good state, you can find your own changes and reset back to the distribution provided state.

Having that in /usr also makes perfect sense to me: usr is short for Unix System Resources. Configuration definitely falls into that category. It is also the only persistent place to put things in the proposal made by Lennart, so it is the only option. Whether that needs to be in /usr/lib is of course debatable, but I frankly do not care too much:-)

The FHS does not support stateless systems at all. So why should systemd bother to follow its suggestions (and that is all the FHS is anyway) when implementing this new feature? A distribution following the filesystem layout suggested by systemd is pretty far from FHS anyway. /bin, /sbin, etc. are all gone, /run is not really in FHS either. Maybe FHS needs to be adapted... or maybe that is not necessary anymore now that systemd actually gets things unified across distros. That is something the FHS never managed!

[Ericg]

... /etc/ for system-wide settings, nothing else
well.. /lib/ for kernel/modules settings

you can repost that blog all you want
if you read it and it is clear and makes sense, then you can make a good point
but there is no good point in using /usr/lib/ for system-wide settings, it's just plain stupid
i hope you can agree with that

the FHS is there for a reason, and it's mostly very good


EDIT: i think i know where the confusion is coming from
when i say "user related" i mean that they are for use by the user
so /usr/lib/ is for libraries that are for programs that a user uses, like the ones in /bin

while you are thinking of "user specific"
user specific programs and libraries have their own place, and it's not in /usr/lib/ or /usr/bin/

/etc/ is being used for system wide settings though. systemd's config-lookup priority goes: /etc/ --> /usr/lib/systemd/system/. It only goes to /usr/lib/ if it gets an empty or incomplete configuration for the .service file its checking for.

And yes, the FHS is there for a reason and it IS mostly good, but it hasn't been updated in over 10 years (2004). The way we use systems has changed considerably, and with the emphasis growing in terms of thin clients, verifiable system images, and the likes... It could probably use an update. For example the official FHS doesn't specifically acknowledge the /bin, /sbin, /lib ---> /usr/ move that several distros have done. The linuxfoundation's FHS page does have a "FHS 3.0; Under Development" listing so maybe we will see an update soon that takes into account several of the changes that have happened in the Linux landscape.

[Ericg]

From your blog quote, that is exactly what etc-update is used for in gentoo builds. I'm pretty sure most distros have that covered.

Not a Gentoo user so I can't make any comment on that. But, just as an example of the two distros that I do use: AFAIK, neither Arch nor Fedora have any way to return to 'pristine /etc'.

[duby229]

Not a Gentoo user so I can't make any comment on that. But, just as an example of the two distros that I do use: AFAIK, neither Arch nor Fedora have any way to return to 'pristine /etc'.

Well, etc-update is a bit more powerful than the blog quote you made. It is possible for users to delete "pristine" settings. I'd bet most users do. For the fact that "pristine" settings aren't meant for deployed systems. As soon as etc is configured properly "pristine" settings don't matter anymore.

[duby229]

EDIT: Forgot to say etc-update isn't system wide, it's per package. Or rather per configuration file.

[Chousuke]

from the FHS "/usr : Secondary hierarchy for read-only user data; contains the majority of (multi-)user utilities and applications."

Nothing in that definition actually forbids putting *read-only* default configuration in /usr; in fact, that's pretty much exactly where it belongs. It's read-only data that you don't ever need to modify.

The /usr -- /etc split systemd utilizes (along with the somewhat-clumsy but extremely useful drop-in "extension" mechanism) is in my opinion the least broken way to handle software configuration. Distributors or sysadmins put their *default* configuration under /usr somewhere and I don't need to care because any host-specific configuration under /etc will override it. Taken to its completion, a "stateless system" will make it almost trivial to eg. write an OS image that automatically downloads its own configuration from the network at first boot... You can just dump the config in /etc and on the next boot it will take precedence over the defaults, without having to bake in puppet or cloud-init or whatever crazy rsync-perl-bash'n'sed hacks you like to use for host initialization.

If the pedants say that it goes against the FHS, then screw the FHS. I want *better*.