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