[Feature]: respect the XDG directory layout for configuration and data directories

[ryantking]

Summary

Cosmos-SDK based nodes use the concept of the home directory, which defaults to a .<daemon> directory in the home folder of whichever user owns the node software. The config and data directories are then children of that home directory. This goes against the XDG base directory specification, which puts config and data directories in $XDG_CONFIG_HOME a $XDG_DATA_HOME respectively.

This specific feature proposal would be to allow a user to specify different config and data directories instead of being hardcoded to sub directories of the daemon home so they can adhere to those standards while the software would maintain backwards compatibility.

I would be happy to implement this feature myself should I receive indication that such a pull request could be merged.

Problem Definition

Why do we need this feature? What problems may be addressed by introducing this feature?

Blockchain nodes should follow the same standards that virtually all other software daemons designed for UNIX-like systems follow.

What benefits does the SDK stand to gain by including this feature?

This would greatly increase the discoverability of the software to administrators who are familiar with Linux server administration, but not the quirks of blockchain node software specifically. Most Linux users know that they can find configuration files in /etc/my_daemon and data in /var/lib/my_daemon, where the latter is also the home directory for the daemon user.

Are there any disadvantages of including this feature?

If done in a non-backwards compatible way then users would have to update their node software configuration. This proposal takes compatibility into consideration for that reason.

Proposed Feature

I propose that the daemon have two additional flags:

--config-home    The directory to load configuration files from (default: <daemon_home>/config)
--data-home    The directory to store node data in (default: <daemon_home>/data)

This would allow users who wish to operate their daemons more in line with the well-established Linux directory conventions to opt into such a layout without disturbing any existing setups.

Cosmovisor would also have to be updated with an environment variable that allows the user to specify where it should discover upgrade binaries and manifests instead of a path based on the daemon home directory. Like the daemon itself, the default behavior would be backwards compatible.

[tac0turtle]

This looks like a good feature to add, we would welcome a pr if you are willing to submit one

[alexanderbez]

I wasn't familiar with the XDG pattern, but I have noticed many linux libraries (e.g. systemctl) adopt a similar approach. Asking out of curiosity, is XDG the standard in linux tools or is it merely a community proposal that most adopt?

[ryantking]

@alexanderbez Short answer: its the de facto standard.

Long answer: It depends on what you mean by "the standard." I am not aware of any documentation in the Linux kernel or POSIX spec that enforces following the XDG base directory standard. The XDG standard is managed by the freedesktop organization, which is arguably the most significant Linux development team after the kernel team itself and GNU. Most notably they maintain both major Linux display servers (X.Org and Wayland) and dbus. Even if you are running a headless Linux server, you for sure have some freedesktop.org software running on it. So for that reason its about as close to an official Linux standard as one can get in the fragmented Linux world. Plus virtually all Linux software follows it.

Here's an example from the man pages of my window manager:

CONFIGURATION
       sway searches for a config file in the following locations, in this or‐
       der:

       1.   ˜/.sway/config
       2.   $XDG_CONFIG_HOME/sway/config (suggested location)
       3.   /etc/sway/config

       If unset, $XDG_CONFIG_HOME defaults to ˜/.config.

I think a similar setup would work in the cosmos SDK.

1. If $HOME/.my_daemon exists, use it. Current behavior
2. If XDG_CONFIG_HOME is set, look for config in XDG_CONFIG_HOME/my_daemon and put data in XDG_DATA_HOME/my_daemon if its found.
3. Expect config in /etc/my_daemon and put data in /var/lib/my-daemon

I guess you wouldn't technically even need flags then as the old behavior would stay default and all users would have to do to get the new behavior is:

mv /home/admin/.my_daemon/config /etc/my_daemon
mv /home/admin/.my_daemon/data /var/lib/my_daemon
mv /home/admin/.my_daemon/cosmovisor /var/lib/my_daemon/cosmovisor
rmdir /home/admin/.my_daemon

[alexanderbez]

Very detailed response, thanks @ryantking. Adopting XDG makes sense to me. I think we can implement this in a backwards compatible way, considering the current layout as legacy/sunsetted.

[ryantking]

@alexanderbez is this something that cosmos proper is going to prioritize? My offer still stands to take a crack at implementing it myself since this issue is very near and dear to me, but might not be immediate.

[alexanderbez]

I would love it if you would give it a go.

As for it being something that cosmos at large will use or prioritize, that's difficult to answer as the operators in the ecosystem are large and diverse. However, I would argue many operators are like minded like you and would prefer a feature like this.