I need to place files in the /usr path, it is my understanding those files can be removed via swupd.
If I were to make my files and directories immutable, would that prevent swupd from removing/modifying them?
My specific example would be the xscreensaver’s various screensavers. By default, they are placed in /usr/libexec/xscreensaver/ and the configs in /usr/share/xscreensaver/config/ and these files are not included in CL’s xscreensaver bundle.
And yes, I am sure the CL developers would highly advise against doing this, if it would indeed accomplish the goal. I do not want to break swupd, just stop it from messing with some files I might need to put into /usr/.
In my understanding, swupd does not actively check what should not appear under /usr upon update.
But the update may replace any of your custom contents if any of them is included in a any of the bundle.
For example, I had some modifications to /use/share/defaults/etc/ directory. Some of them are completely new script I wrote, and they’re safe. But some others are installed by os-core but I modified them, so whenever there’s an update related to those files they would be replaced.
I was just testing this myself, and you are correct from my observations. So, this is good from the perspective that I am seemly free to supplement files that are not included in bundles in /usr without swupd subsequently “repairing” the files. However; this is also a caution to myself, that if I accidentally place a config file in /usr or /var, it could be utilized by an application, ruining the expected “stateless” nature of CL. Which then could lead to confusion concerning the application’s default/current settings, and importantly, swupd will not repair such a mistake.
Here’s your problem.
xscreensaver likely also allows you to put files in /usr/local/libexec/xscreensaver/. This location is meant for, and completely safe, from swupd.
So, put your screensaver mods in here and try it. If it works, great! If it doesn’t work then file a bug and we’ll see if we can patch xscreensaver to properly load mods from /usr/local as well.
Because that’s how this is supposed to work. And we’ll gladly fix applications that forgetting about that.
As for stateless, in my understanding it’s basically saying to separate configs from packages. This complies to Filesystem Hierarchy Standard.
There’re mainly three locations we should install custom packages, /usr/local, /opt, and ~/.local.
Except explicitly recommended by package developer, in your case you just need to decide whether to use /usr/local or /opt.
Normally if you build a package from source, the default install prefix is /usr/local, which has same/similar subdirectory structure as /usr.
As for /opt, I’ve only see several cases where the package is by default installed there. One is the driver for my printer, and another is a runtime requirement for Rstudio. Things installed there are located in their own sub-directory named after the package name. Say if you want to build something that won’t be touched by package management softwares even when there’s a new version, /opt is a good place. (This is why Rstudio have an external module installed there, it’s never modified so it guarantees Rstudio works).
Correspondingly the configurations should be located in /etc, /etc/opt for /usr/local and /opt.
The rationale is, binaries, libraries, manpages and other stuff under /usr are sharable between system. So theoretically you can clone them into another system and they should work.
On the other hand, (system-wide) configurations are host specific, and not sharable, so you should separate them from the sharable ones.
Well in practice it’s quite the opposite.
The stateless concept conforms to the FHS.
Default configurations ensures basic functionality without any host specific settings, and are located under /usr/share/sub-directory or /use/share/defaults/sub-directory. They are sharable.
Host specific configurations stay in /etc or /etc/opt. And per-user configurations are in home directory. None of them is sharable.
Normally even without stateless, many applications looks for configurations in the following order:
The stateless just added another layer, that if a configuration is required but not found, the application uses the default stateless configuration under /usr/share.
If you build something that’s also included in a bundle, then a configuration in /etc would effective for both your custom built package and the one shipped with swupd. And indeed, that has higher priority comparing to stateless default configurations. But it doesn’t break stateless because the configurations are still separated from executables and etc.
To avoid this, you may specify a different sysconfdir when building the package, for example, /etc/local.
If you build something not included in any bundle, configurations in /etc shall work as normal.
In either case, you custom built packages shall not read stateless configurations unless you explicitly required that when building them.
This is a well written explanation, maybe it should be “pinned”. I am attempting to adhere to the FHS and the intended design of Clear Linux, it is what appeals to me as a sys admin.
I also understand that our requirements are different than what I believe of Intel’s intent with CL. They have made the better mouse trap and we are committed to using it. In fact, it is vital for us.
I would like to thank you, for your significant efforts to assist others.
I would also like to thank the developers and support staff. They have responded in a timely manner to the major issues I had with enterprise authentication.
I replied to this suggestion in #1109.
This I largely disagree with - configurations are almost always a per-machine thing. Not only would it be very confusing if software would read ALL those locations and combine the configuration options somehow, it also would be difficult for SA (sysadmins) to figure out what configuration applies.
This is why most distros I’ve worked with pass --sysconfdir=/etc --localstatedir=/var even for software that gets installed in other prefixes. And you should pass these options to software that gets installed into --prefix=/usr/local as well.
Especially combined with stateless principles, this means /etc is largely empty, you will have all your machine configs in one location. You can then track them in git easily (a great way to keep historical info on local configs) as well because they’re all in the same location.
For the very same reason you should always put --localstatedir=/var. This will save you massive headaches later trying to find stuff.
I can understand the --localstatedir=/var because this is where files that are modified by applications should be located in, and the varying nature demands those files to be located in /var according to FHS.
But what do you mean by a largely empty /etc?
FHS is a reference implementation, and it would be very helpful if Clear Linux could publish a guide on its own implementation, under stateless principles.
I realize that may have sounded confusing.
Even if every piece of software uses /etc for it’s configuration changes, it should be empty by default(*), and not be littered with template configuration files that are unchanged.
In other words, /etc should only contain changes to defaults. And not entire files with 100’s of options, but only the options that are changed from default.
Sort of like this:
$ cat /etc/ssh/sshd_config
X11Forwarding yes
$
Just think of what happens if it isn’t mostly empty. Last time I upgraded my RPM-based distro, I had a dozen or two .rpmnew files created, which I had to manually go through and merge, because the template had been updated. In some cases, it might have been useful since I would have caught changed defaults that affected my installation. But in reality, that didn’t happen and it just made my /etc even more littered with junk than it already was.
I’ve updated man stateless with a little bit more detail on /usr/local and other special locations.