1

The application I'm contributing to requires configuration files as a part of its operation. This is currently placed within the root directory of the application. If I followed the FHS, the config should be stored in /etc/Shinobi. The operating systems supported by the app are

  • Ubuntu 17.10.1 and 18.04

  • CentOS 7

  • MacOS 10.7(+)

Is it safe to assume that /etc/ Directory will always exist in an operating system and read the default configuration from /etc/Shinobi throwing appropriate warnings if the directory is missing?

rsn
  • 119
  • 3
  • Some ideas (I don't know what is normally done). I would think that at the very least it should be ${dir_that_bin_is_in}/../etc/… that will allow it to be placed in /usr/local. Another option is to specify it in ./configure. – ctrl-alt-delor Jul 18 '20 at 17:32
  • @ctrl-alt-delor but if you specify a relative path, you cannot move the software or use it on a system where it is installed elsewhere. It seems far safer to use /etc. What if the program is installed in /bin or /sbin or /usr/bin instead of /usr/local/bin? – terdon Jul 18 '20 at 17:36
  • 1
    On macOS, '/etc' is a symlink to '/private/etc'. '/usr/local/etc' is a potential choice, especially since '/usr/local/' is a standard and generally in the PATH. – JRFerguson Jul 18 '20 at 17:38
  • @terdon If the application is to be used "where it is installed elsewhere", putting the configuration files in /etc means every system the application is to be used on has to be configured. At least with a relative path, if the app is located in /path/to/app/binand the configuration is in/path/to/app/bin/../etc, sharing/path/to/appis sufficient to share the app on multiple systems in a way that doesn't need local configuration in/etc` on all systems the app is to be used on. This question makes me wonder what problem moving the configuration from its current location is solving. – Andrew Henle Jul 18 '20 at 17:44
  • @AndrewHenle yes, but since /etc is pretty standard, using that for configuration is probably the most portable solution. If you want to avoid that, just keep all the information in one directory which can be defined at install time. Then, the program will know to search in that directory. But expecting your config dir to be exactly N directories above you is bound to fail. – terdon Jul 18 '20 at 17:53
  • @JRFerguson for those of us less familiar with macosx is storing something in /private/etc (/etc) considdered bad practice? Why are you suggesting against using it? – Philip Couling Jul 19 '20 at 07:41
  • @Phillip Couling No, there's no bad practice in choosing '/private/etc'. – JRFerguson Jul 19 '20 at 11:46

1 Answers1

3

You are changing the fundamental nature of the application by doing this, making it no longer self-contained within a single filesystem tree. This might be not what your users want; nor how your application is used, distributed, and installed in practice. If your application installs self-contained from a single archive into a single filesystem sub-tree as a "portable application" install, you will break this. If your application doco recommends this as the best way to install it, you break things for a lot of your users.

You are introducing support problems and creating support expense (from stale config files, unexpectedly shared config files, surprising events at software upgrades, and others), with no better reason than to use parts of a Linux standard that many Linux-based operating systems intentionally do not use and that does not even apply to non-Linux operating systems like MacOS that your program targets.

Be warned.

Also be warned that /etc is not always the place that operating systems want used for this sort of thing. It is common on the BSDs, for example, for applications to be configured to use /usr/local/etc rather than /etc.

Similarly, FreeDesktop.org standards prefer that applications use the directories specified by the XDG_CONFIG_HOME and XDG_CONFIG_DIRS environment variables.

Ironically, you are actually moving away from your application's "portable application" model, not making things more portable.

And you aren't even doing the work to keep the doco in synch.

Further reading

JdeBP
  • 68,745
  • On the Linux end, the XDG spec really is the answer to this question. If that progam follows the guidelines this alleviates the need for non-FHS distros (NixOS for example) to patch it into behaving. – phg Jul 20 '20 at 07:40