1

When building a new software that will store a directory of configuration files in /etc, should the directory be named software_name.d or just software_name?

I can't seem to find good style guides regarding this subject. Debian is the primary distribution I have in mind but more general style guides or guidelines are welcome.

'Official' guidance is preferred to personal opinions.

  • This question is a useful one because it has good answers: one explaining the standard practice and another highlighting that the standard practice has not (yet) been codified by the closest official standard. – Anthony Geoghegan May 17 at 10:03
5

The typical use of a .d directory is to hold multiple config files (typically sharing a common file extension, such as *.conf) which are then merged or composed to produce a single logical configuration. This mechanism is typically equivalent to one where the multiple config files were concatenated to form a single config file.

Applications typically evolved to use .d directories in order to play nicer with Linux software packages (deb/rpm) and package managers. A .d directory is nicer towards the use of packages by distributions, since then packages can simply "drop" a standalone file into a directory (which is a natural operation, as packages manage/contain files), rather than having to edit a shared configuration file to add a stanza to plug in that particular package. (In earlier days of Linux distributions, you'll see packages doing exactly that, editing existing configuration files, through post-install and pre-uninstall scripts.)

The use of a configuration directory named /etc/software_name is more common when the application uses multiple configuration files for different purposes (and perhaps even using different file formats, such as JSON, ini files, etc.) In that case, you might want to use a directory to group all the configuration files for that same application, but if you're not expecting other packages (or system administrators) to want to extend the configuration by "dropping" new files into a directory, then you won't use a .d directory.

Some systems end up using both actually. For example, yum (the Red Hat package manager) has its own configuration file, but it also has a .d directory for its own repos (/etc/yum.repos.d.) I believe apt is also similar, so you could look at that one if you're on Debian. You can see that setup makes sense, since you might want to manage adding/removing repositories by "dropping" new files into a .d directory (either from packages you push, or through a configuration management system) without having to modify the existing one (which might be getting updates from the O.S. distribution itself.)

  • 1
    filbranden makes a good point. For example, consider the nginx config folders installed by RPM on an Enterprise Linux system. /etc/nginx/ holds several configs, and also contains sub-folders (conf.d for example) with distinct purposes. – 0xSheepdog May 15 at 13:39
4

There is a lot of discussion over this topic. Nothing really definitive is apparent.

For "official" guidance on what is 'correct' I say the definitive source would be the Filesystem Hierarchy Standard at The Linux Foundation. Unfortunately I didn't find anything definitive with some basic searches. You may have luck with more diligent searching.

Failing the FHS, I would look to the community you are writing software for, try to find a general consensus on what they prefer, and decide if that meets your requirements. I think you are asking for guidance where none actually exists, because "recommended" is a pretty vague term in this case. "Recommended by whom? And for whom?"

  • 3
    It’s also worth looking at existing practice — there’s a common pattern to the contents of .d directories, as summarised by Russ Allbery: Generally when you see that *.d convention, it means "this is a directory holding a bunch of configuration fragments which will be merged together into configuration for some service." – Stephen Kitt May 14 at 21:12
  • @StephenKitt Absolutely agree. I avoided too much personal input because OP wasn't interested in opinions. I know what I prefer, and I have examples of how it is done well, and not so well... But if there is no official info from the FHS nor the Distro style-guide, it's hard to suggest much EXCEPT opinions and personal preferences. – 0xSheepdog May 14 at 21:50
  • 2
    Yes, it’s one of the many patterns which appeared and evolved without ever being codified (AFAICT)... – Stephen Kitt May 14 at 21:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.