The DietPi installation does not follow the *nix Filesystem Hierarchy Standard

[TerryE]

This is a general configuration / architectural issue that started out as a comment in #1294, but this has a wider scope so it really merits its own issue.

Expected behaviour:

Linux adopts a convention Filesystem Hierarchy Standard (FHS) for what is type of files are located in /etc, /usr/local/lib,/var/lib. DietPi should follow FHS, as this convention have been developed for sound reasons and following it makes for better system configuration and facilitates experienced sysadmins using the package. For example /etc is normally used solely for piecewise static configuration data and is by default o:r accessible, with all files in the /etc tree owned by and only writeable by root. Where data (such as identification data) is not publicly readable but access is required by service account, then this is mode 640 and the files are service account's group so the application can read it (see for example /etc/at.deny).

Packages such as etckeeper can be used to to manage the system configuraton, if the installation follows these conventions.

Actual behaviour:

DietPi stores non-configuration data in /etc such as /etc/dietpi/logs which breaks the conventions and makes it impractical to use etckeeper. These log snapshots are really dietpi application data and therefore would be better located in /var/lib/dietpi/logs, and so on.

Likewise /usr/local/libs should be reserved for shared binary libraries used by /usr/local/bin programs.

The share hierarchies of /usr are a better fit except that all files in these hierarchies are again root-owned so this can't be written to by an unprivileged service account. The node_modules hierarchy doesn't fit this read-only pattern so doesn't belong here. Where applications need applications directories that they can write to, then these are kept in a /var/lib subdirectory owned by the service account, e.g. /var/lib/mysql which is normally mode 700 or 755 with a 700 subdirectory for private data. So here we should follow the mysql pattern were services run in a service account and in the case of node red, for example, use /var/lib/npm and /var/lib/node-red.

Before exploring / expanding this issue further I am interested in @Fourdee Dan's comments.

[k-plan]

Before exploring / expanding this issue further I am interested in @Fourdee Dan's comments.

Until @Fourdee give any comment:

Lock conversation on this issue.

Locking the conversation means:

• Other users can’t add new comments to this issue.
• You and other collaborators with access to this repository can still leave comments that others can see.
• You can always unlock this issue again in the future.

[Fourdee]

@TerryE

Many thanks for the info 👍

I'll browse through FHS and make a decision on if we are adopt it. I'll post here once I have a answer :)

[Fourdee]

Notes:

• /etc/dietpi/logs, due to /var/log default as RAMlog for performance, and, SD write reduction. We use this for storing logs which would avoid the 1hour automatic clear (to free up memory).
• /etc I agree with "/etc to static configuration files and may not contain binaries". Solution would be to install everything to /mnt/dietpi_userdata as standard, or binaries only in /usr/bin

I think the simple solution here (in regards to DietPi logs and non apt/dpkg installations eg: amiberry) is to install/configure everything in /mnt/dietpi_userdata. This way, we can customize the installation to our needs and optimizations, without breaking FHS. It would also benefit uses with /mnt/dietpi_userdata setup for USB drives with higher IO than rootFS.
We use /mnt/dietpi_userdata for some items (eg: mysql/nextcloud/owncloud data), but not all, i'll need to review them.

@TerryE
Yep, i agree 👍
Leave it with me, i'll go through the DietPi specific items 1st, then we can review any outstanding queries.

[Fourdee]

Reference: https://github.com/Fourdee/DietPi/issues/1294#issuecomment-352176566

@TerryE
Unlocked, apologies.

[Fourdee]

Moved from https://github.com/Fourdee/DietPi/issues/1309#issue-282622893

---

MichaIng wrote:

@Fourdee
Sorry for opening up new unlocked issue 😅, just wanted to add the /opt folder into discussion for DietPi files. At least I learned about this to be used for non repo package software (compared to /etc) and according to the debian.org article it is also meant to include binaries: https://wiki.debian.org/FilesystemHierarchyStandard

If consider /usr/bin, maybe consider /usr/local/(bin), which looks most intended for stuff like that and is clean on default installations. It also already works great for ownCloud/Nextcloud occ/ncc commands 😛. Then we don't need our binaries as alias anymore and they will also work inside scripts. But no benefit from ramdisk.

But my main idea was just to copy our optimized software configs out of ramdisk, as they really don't need to be there (so real performance benefit) but consume RAM, that we have to consider while writing configs into their own files. Okay it's just about a couple of MB still, but my further ideas are to clean up dietpi-software more by moving configurations into their own files 😉.

[Fourdee]

Ok going with:

• /var/tmp/dietpi/logs for DietPi logs outside of /var/log, that we dont want clearing every 1 hour with dietpi-ramlog
• /var/lib/dietpi/dietpi-ramlog_store for storing RAMlog /var/log files during reboots

Commit done, i'll tweak if needed.

@TerryE @MichaIng Any objections, suggestions?

Then remains checking everything else we use /etc/dietpi and discussing.

[TerryE]

Yup make them owned by dietpi:dietpi and mode 660, then any account in the dietpi group can manage the files.

[Fourdee]

Ok,completed for v160 /etc/dietpi is no more!:

• /var/tmp/dietpi/logs for DietPi logs outside of /var/log, that we dont want clearing every 1 hour with dietpi-ramlog
• Replaced /etc/dietpi throughout DietPi scripts with /var/lib/dietpi
• dietpi-software installations of non-systemd services which used /etc/dietpi. Have been moved to /var/lib/dietpi/dietpi-software/services
• dietpi-software installations of custom scripts (eg: Pi-SPC) which used /etc/dietpi. Have been moved to /var/lib/dietpi/dietpi-software/installed

---

Will leave open, to allow me to run some final testing.

[Fourdee]

Completed.

I'll do final in-depth testing on v160 prior to release.