Bug Report: Violation of FHS by storing variable data under /usr/share?

[ralfbergs]

OS Version

Ubuntu 24.04.1 LTS

System Information

Linux server. 6.8.0-51-generic #52-Ubuntu SMP PREEMPT_DYNAMIC Thu Dec 5 13:09:44 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

What happened?

I understand that my choice of an OS is unsupported, but please note that installing HA Supervised under a supported OS would result in the very same problem (as it is "by design"), so I'm kindly asking you to make an exception and consider this report anyway.

This is a duplicate of an issue I filed in the wrong project previously.

Describe the issue you are experiencing

It somehow feels wrong that frequently-modified data is stored under /usr/share, more specifically under /usr/share/hassio/homeassistant, such as various SQLite databases, logfiles.

To me that seems a clear violation of the Filesystem Hierarchy Standard that says /usr/share is meant for "Architecture-independent (shared) data."

I believe most of the data should go under /var/lib/homeassistant/ or /var/log/homeassistant/.

Steps to reproduce the issue

1. Install HA Supervised.
2. Observe the folders used by HA within the file system hierarchy.

Machine Type

generic-x86-64

Installer output

not relevant

Relevant log output

not relevant

ADR

• I have read through the ADR and have confirmed that my system is compliant with the requirements
• I understand that if my system is found to not be compliant, my issue will be closed immediately without further investigation

Code of Conduct

• I have read and agree to the Home Assistant Code of Conduct

[agners]

To me that seems a clear violation of the Filesystem Hierarchy Standard that says /usr/share is meant for "Architecture-independent (shared) data."

In a way, the data stored by Supervisor is "Architecture-indepenet (shared) data". However, when reading further the FHS goes a bit more into details what is meant by share data:

Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally). It is recommended that a subdirectory be used in /usr/share for this purpose. Applications using a single file may use /usr/share/misc.

Typically these are graphics, icons, and other static data files etc. So I agree the non-static user data is misplaced there.

/var/lib could be one place. One could also argue that maybe /srv would be the right place. The data is rather a bunch of collected information.

FWIW, the Supervisor does use the file hierarchy somewhat liberally: The individual containers (Home Assistant Core, Add-ons etc.) do have bind mounts to /config, /share, /ssl etc, which does not really follow FHS. And I don't think this should be changed either. So one could also argue we could go completely off-script here and just use /homeassistant 🤔 🙈

But granted, for Supervised installation which is supposed to run on regular Debian operating system, which does follow the FHS, following FHS does seem sensible. I think I'd go for /srv/homeassistant.

Btw, as stated in the README, it is possible to change the default using DATA_SHARE=.... I guess your issue is about changing the default? If we do that, we certainly should make sure that existing installations are not affected (which should not be a problem since the chosen location is stored from what I understand).

[ralfbergs]

@agners Hi Stefan, many thanks for not rejecting my issue right away and for taking the time to phrase a comprehensive reply. I really appreciate it. :-)

If you look up one step in the FS hierarchy, then /usr/is meant as a "Secondary hierarchy for read-only user data" (there are systems where /usr/ is actually mounted read-only!). So I would argue logfiles and databases (or "backups") never belong anywhere under /usr/, even if logfiles are generally "Architecture-independent", and SQLite databases are indeed also ("by chance") "Architecture-independent". ;-)

TBH I don't have that much experience with software living under /srv/, so I can't really judge whether it fits there or not. The FHS speaks about "Site-specific data served by this system, such as data and scripts for web servers, data offered by FTP servers, and repositories for version control systems", so it may be a perfect location for web-server docroots, FTP mirrors, or source-code repos. Maybe if just the "codebase" lived there (i.e. files requested by HTTP clients), and all variable data went under /var/lib/ or /var/log/ it would be cleaner?

Indeed, my point is about providing "sane" defaults. I must admit that when I set this up about two (or three?) months ago, I was a complete newbie to HA, it was my first contact ever with it. I was simply too overwhelmed to even think about this point when I ran the install script. Now that I start observing minor issues to be investigated and fixed, I looked into logfiles and noticed the improper location of some files.

[agners]

Since the whole Supervisor data folder is a mixed bag of data, we can't really store it at the "perfect" location. And separating things in the Supervisor data folder would be a huge undertaking at this point, for questionable benefit in the end.

So neither /var/lib nor /var/log completely fit the bill for all Supervisor data.

But /srv does sound like a rather generic location. The usage examples listed seem to be a non-complete list of examples. And the data stored in the Supervisor data directory is definitly site-specific. So /srv does sound quite matching to me.

@ikifar2012 any thoughts on this?

[ikifar2012]

Since the whole Supervisor data folder is a mixed bag of data, we can't really store it at the "perfect" location. And separating things in the Supervisor data folder would be a huge undertaking at this point, for questionable benefit in the end.

So neither /var/lib nor /var/log completely fit the bill for all Supervisor data.

But /srv does sound like a rather generic location. The usage examples listed seem to be a non-complete list of examples. And the data stored in the Supervisor data directory is definitly site-specific. So /srv does sound quite matching to me.

@ikifar2012 any thoughts on this?

Totally agree that /srv/homeassistant sounds like a better location, since taking over the project I have always been very careful not to change much in fear of creating breaking changes... not sure how I feel about moving the data location for existing users but I do agree that moving to /srv makes sense in the long run.

Reference for the FHS standard if anyone is curious and wants to read:
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s17.html

[agners]

Totally agree that /srv/homeassistant sounds like a better location, since taking over the project I have always been very careful not to change much in fear of creating breaking changes... not sure how I feel about moving the data location for existing users but I do agree that moving to /srv makes sense in the long run.

Yeah I would definitely not move existing users location. Since the location is user configurable, and the default configuration is always stored in the local /etc/hassio.json configuration file, we can just consider existing installation as installations with the "custom" location /usr/share/hassio. Or in other words: Just leave it as is.

[calumapplepie]

Since the whole Supervisor data folder is a mixed bag of data, we can't really store it at the "perfect" location. And separating things in the Supervisor data folder would be a huge undertaking at this point, for questionable benefit in the end.

So neither /var/lib nor /var/log completely fit the bill for all Supervisor data.

But /srv does sound like a rather generic location. The usage examples listed seem to be a non-complete list of examples. And the data stored in the Supervisor data directory is definitly site-specific. So /srv does sound quite matching to me.

@ikifar2012 any thoughts on this?

Strictly speaking, full compliance with Debian's policy and the FHS would require sperateing the data folder to be "files which are changed" and "files which are wholly managed by dpkg and not changed by any other program". Anything managed by dpkg goes in /usr/share, and anything managed by some other program goes in /var. Even if a file is rarely or never modified (such as systemd-coredump's crash dump locations, texmf's font cache, doc-base's list of installed documentation), it still lives under /var/lib/. If a file isn't installed by dpkg and left unmodified until the next update, it shouldn't be under /usr/[1].

/srv/ is more for files that are served to users; I'm not sure, but I feel like I've heard of some web servers defaulting to just serving whatever is stored there. Data which is private and shouldnt be exposed probably doesn't belong there. That being said, Debian's development tools set up the chroots for building packages in a clean environment there, so it's possible it really is just a catch-all. The description, though, makes /var/lib sound like an equally choice under the FHS.

[1]: /usr/local is an exception