Add a environment variable toggle to decide if existing configuration files should be kept or overwritten

[pawlakm]

I write this improvement request after having read the answer to my bug report #1327

After having read the code of /web/rootfs/etc/cont-init.d/10-config it appears that the config.js file will be overwritten in any case by the default file generated from environment options then the content of custom-config.js is appended to the previous result

This approach is used for many config files, but not all. And for some of them this approach implies having to write the whole content of the default file into the custom one to avoid losing some options (for instance a custom_interface_config.js should have the content of interface_config.js + modifications)

I don't understand the rationale behind this approach of overwriting at each docker-compose start/up. Usualy conf files are exposed to allow users to tune them so overwriting existing files / appending custom ones in this way is quite disturbing, and overly complicated for the end used. This is especially true as some options are not configurable at first init using environment variables yet.

A better approach would be IMHO to:

• have an environment variable OVERWRITE_CONFIG_FILES to overwrite / keep existing configurations as follows:
  • if the toggle is set to "false" (default value), use existing configuration files or create them if missing
  • if the toggle is set to "true", overwrite config files or create them if missing

The effort to achieve this should be minimal. For instance I just tried to do it for /web/rootfs/etc/cont-init.d/10-config. So instead of having:

# copy config files
tpl /defaults/nginx.conf > /config/nginx/nginx.conf

tpl /defaults/meet.conf > /config/nginx/meet.conf
if [[ -f /config/nginx/custom-meet.conf ]]; then
    cat /config/nginx/custom-meet.conf >> /config/nginx/meet.conf
fi

tpl /defaults/ssl.conf > /config/nginx/ssl.conf

tpl /defaults/default > /config/nginx/site-confs/default

tpl /defaults/system-config.js > /config/config.js
tpl /defaults/settings-config.js >> /config/config.js
if [[ -f /config/custom-config.js ]]; then
    cat /config/custom-config.js >> /config/config.js
fi

cp /defaults/interface_config.js /config/interface_config.js
if [[ -f /config/custom-interface_config.js ]]; then
    cat /config/custom-interface_config.js >> /config/interface_config.js
fi

We would have the following code:

# copy config files
if [[ ! -f /config/nginx/nginx.conf ]] || [ "$OVERWRITE_CONFIG_FILES" = "true" ] ; then
    tpl /defaults/nginx.conf > /config/nginx/nginx.conf
fi

if [[ ! -f /config/nginx/meet.conf ]] || [ "$OVERWRITE_CONFIG_FILES" = "true" ] ; then
    tpl /defaults/meet.conf > /config/nginx/meet.conf
fi

if [[ ! -f /config/nginx/ssl.conf ]] || [ "$OVERWRITE_CONFIG_FILES" = "true" ] ; then
    tpl /defaults/ssl.conf > /config/nginx/ssl.conf
fi

if [[ ! -f /config/nginx/site-confs/default ]] || [ "$OVERWRITE_CONFIG_FILES" = "true" ] ; then
    tpl /defaults/default > /config/nginx/site-confs/default
fi

if [[ ! -f /config/config.js ]] || [ "$OVERWRITE_CONFIG_FILES" = "true" ] ; then
    tpl /defaults/system-config.js > /config/config.js
    tpl /defaults/settings-config.js >> /config/config.js
fi

if [[ ! -f /config/interface_config.js ]] || [ "$OVERWRITE_CONFIG_FILES" = "true" ] ; then
    cp /defaults/interface_config.js /config/interface_config.js
fi

A future "candy" could be to detect inconsistencies between environment variables and existing config files and have warnings in a specific log file, but meantime for each of the above cases, a else case could be added which would log a message stating that existing configuration file will be used and as such it is not sure that it matches environment variables.

Another "candy" could be to search and replace environment variables in existing configuration files.

What's your opinion ?

[DanielMcAssey]

I disagree with this, containers should be able to be created and destroyed with minimal fuss, if you are starting a container then editing files within it then either environment options are missing or something else in your flow is wrong.

Containers should be ephermal and never maintain persistence outside its intended configuration (either by mounting config files or environment variables).

Additionally using environment variables over mounting a config file allows easier upgrade to configurations with minimal fuss.

[saghul]

I disagree with this, containers should be able to be created and destroyed with minimal fuss, if you are starting a container then editing files within it then either environment options are missing or something else in your flow is wrong.

100% this. If we need to freely customize some file we can always go the -custom route.

[pawlakm]

I mainly agree with both of you, however as the strategy is to rely exclusively on environment variables, I don't understand why configuration files are shared as volumes at all as they should not be edited by users. It is confusing.

if you are starting a container then editing files within it then either environment options are missing

• all options in interface_config.js seem to not be configurable through environment variables for now (but can be set the custom_ way)

[saghul]

I don't understand why configuration files are shared as volumes at all as they should not be edited by users. It is confusing.

Good point. The custom files need to go somewhere, and they also come in handy for debugging the generated file but yes, we could put them elsewhere now.

• all options in interface_config.js seem to not be configurable through environment variables for now (but can be set the custom_ way)

That file is deprecated and we are in the process of moving all options to config.js, that why the only way to customize it is through the -custom file.