Setting Application Defaults in Linux /etc/default

Question

Am I being a curmudgeon, or should /etc/default be reserved to settings for the operating system?

I'm seeing systems show up with /etc/default/{company}-environment. The file is typically Tomcat data, but not always. I've also seen setup data for Mqueue.

One objection I've heard that makes sense on a technical level is that it does not allow applications to migrate to Containers. Beyond that, am I just carping?

I posted this question over in ServerFault, but it isn't getting any answers. What does the group assembled here think? I've looked in the local Confluence docs and it's been this way for like ten years. The technical curmudgeon in me just objects because /etc should not have anything but operating system components. I'd be interested in others' thoughts.

Answer 1

Your question seems pretty unclear, and maybe this is why nobody answered you yet.

However, you may consider the below statements coming only from my personal thoughts.

About the /etc/default folder and files.

• The beauty of linux is that you may do pretty much anything you wish -> even adding some weird files in your /etc/ folder :)
• AFAIK, the /etc/default folder is more related to some "defaults" configurations files (and env variables) that may be used by any apps requiring it. You may consider those files like "templates" usable by any apps,services, OS directives as "last resort" when they don't have any other custom confs available.
• Most files in /etc/default (in an ubuntu setup), currently have the permissions root:root -rw-r--r--, meaning that everybody is able to read them (so there shall not be any serious "secrets" in those files), but only "root" has the right to modify them (proof that those templates are safe to use).
• On my (ubuntu setup), the /etc/default shows some 'openvpn' and 'google chrome` related files. -> So it is NOT ONLY reserved to OS tasks.
• For example, the /etc/default/useradd file defines some "Default values for useradd(8)", which may be (of course) overriden using some parameters from the useradd commandline (or some other conf files), but it is also smart enough to look for some default missing ones by looking into the related /etc/default file when necessary.

So basically, if you want to create a tool/app/software in linux, feel free to add a default template (configuration files and/or variables) in /etc/default/anyname, and then loading such variables into your shell script (if it is not specified by an input parameters) using the source directive (below just a dummy example):

#!/bin/bash
source /etc/default/anyname #"anyname" file having a DEF_VAR="radigris" in it.
any_var=""
if [ -z "$1" ]; then
    echo "param is unset, lets use the one from the template"
    any_var="${DEF_VAR}"
else
    echo "lets use the given parameter value"
    any_var="$1"
fi
echo "the final parameter value is: $any_var"

You also mentioned compatibility with containers

About containers compatibility, assuming you are talking about docker containers: I also do not see any problems or issues with it...

Lets assume you want to make an /etc/default/anyname available inside a docker container you may probably use this:

• docker run -v /etc/default/anyname:/CONTAINER/PATH:ro -it anycontainer
• or this docker run -v /etc/default/anyname:/etc/default/anyname:ro -it anycontainer(interesting: the 'ro' directive specifiable to keep the immutability aspect of the anyname file inside the container.

Answer 2

At least on Linux distributions, the purpose of /etc/default is to store configuration files used by the general boot process, and in particular init scripts (in /etc/init.d). This allows system administrators (not general users) to change some settings used for system services without having to modify the init scripts themselves.

This is a perfectly valid use of /etc, at least in the context of Linux distributions applying the Filesystem Hierarchy Standard; the latter defines the purpose of /etc as follows:

The /etc hierarchy contains configuration files. A “configuration file” is a local file used to control the operation of a program; it must be static and cannot be an executable binary.

“A program” covers any application installed in the system, not just “operating system components” (whatever that means in the context of a distribution). Note however that regular users aren’t supposed to have to modify configuration files in /etc.

/etc/default is becoming less relevant as init scripts disappear in favour of systemd units in most distributions, but /etc still remains relevant for systemd: for example that’s where unit overrides go.

As far as containers are concerned, containers can also have /etc inside them, and configuration files from the host can be made available in a container by mounting them. In my experience though it’s not all that common to rely on these mechanisms to configure container-based workloads; if external configuration is required, it’s usually provided by some centralised mechanism made available through an external API of some kind.