Description Philipp Hahn 2022-10-11 16:45:57 CEST

The Linux Filesytem Hierarchy Standard¹ (FHS) mandates, that
- `/usr` is for *read-only user data* only: it should only contain static data shipped via (Debian) packages
- `/usr/sbin` Non-essential system binaries
- `/var` is for *Variable files*

base/univention-group-membership-cache currently violates that:

- /usr/share/univention-group-membership-cache/univention-ldap-cache should be moved to /usr/sbin/ as it is the binary required to managed the setup, which can only be done by `root` locally. Finding that binary is hard as it is not part of the standard $PATH

- /usr/share/univention-group-membership-cache/shards.json is some kind of configuration file, which is maintained via `univention-ldap-cache`. As JSON is not a format do be modified by (human) users directly it is not appropriate for /etc/, but should be moved to `/var/lib/univention-group-membership-cache/shards.json`: it's not a cached file.

- /usr/share/univention-group-membership-cache/caches/ contains multiple caches; the belong to /var/cache/univention-group-membership-cache/ instead as they can be deleted and easily be re-created from LDAP easily.


Having the files in the wrong location not only complicates the usage of the binary, but also breaks other tools:

- /usr is often excluded from backups because that content can be easily re-created but just re-installing all Debian packages

- modifying files in /usr may trigger some intrusion detection systems, which assume, that the content is static

- as /usr is supposed to be read-only, /usr may be mounted read-only or be write-protected expect during updates. u-g-m will fail to update its file in that case.

- /var and /usr may on different file systems (for security and reliability) reasons; As /usr is more static its size may be limited; as that /var must be used for data, which may grow and often provides more space and is monitored for that situation.

¹: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard