The Nextcloud Initialization Produces Redundant Configurations Ignoring Environment Variables

[neurolag]

When initializing a new Nextcloud installation, the maintenance:install part of the installation creates redundant settings which draw docker environment variables unfunctional.

Example of a brief docker-compose.yml setup:

version: "3.7"

services:
  nextcloud:
    image: nextcloud:fpm
    restart: unless-stopped
    cap_add:
      - SYS_ADMIN
    depends_on:
      - db
    environment:
      # Settings Required for Automated Installation
      NEXTCLOUD_ADMIN_USER: admin
      NEXTCLOUD_ADMIN_PASSWORD: nextcloud
      # Database Settings
      MYSQL_HOST: db
      MYSQL_DATABASE: NextCloud
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: nextcloud
      # Some Example Settings
      SMTP_HOST: example.org
      SMTP_PORT: 25
      SMTP_NAME: scott
      SMTP_PASSWORD: tiger
      MAIL_FROM_ADDRESS: john.doe
      MAIL_DOMAIN: example.org
      OVERWRITEPROTOCOL: https
      OVERWRITEHOST: cloud.example.org
      OVERWRITECLIURL: https://cloud.example.org
    volumes:
      - webroot:/var/www/html:z
  db:
    image: mariadb
    restart: unless-stopped
    environment:
      MARIADB_RANDOM_ROOT_PASSWORD: "yes"
      MARIADB_DATABASE: NextCloud
      MARIADB_USER: nextcloud
      MARIADB_PASSWORD: nextcloud
    volumes:
      - db:/var/lib/mysql
    command:
      - --innodb_read_only_compressed=OFF

volumes:
  webroot:
  cache:
  db:

Steps of reproduction:

1. Set up docker-compose environment:

   # Clean up pre-existing containers and volumes
   docker compose down --volumes
   # Set up environment
   docker compose up -d --build
   # Wait until the `nextcloud` service reports that it's ready to accept FPM connections
   docker compose logs --follow nextcloud
   

2. Examine config files:

   docker compose exec nextcloud bash -c 'tail -n+1 /var/www/html/config/*config.php'
   

Actual Result

Take note that all settings configured using environment variables (or implicitly configured) in these files:

• autoconfig.php: Database settings
• apcu.config.php: Local cache settings
• apps.config.php: App paths
• reverse-proxy.config.php: Reverse proxy settings (overwrite host, protocol, cli etc.)
• smtp.config.php: Mail settings
• redis.config.php: Redis settings

However, all settings configured implicitly or using environment variables are overridden by the config.php file which is created during the initialization.

Take note that all settings occurring in the previously named files also occur in the config.php file. This means that future changes made to the environment variables won't have any effect which, as far as I assume, isn't the expected or desired behavior.

Expected Result

Settings occurring in the files autoconfig.php, apcu.config.php, apps.config.php, reverse-proxy.config.php, smtp.config.php, redis.config.php etc. which contain implicitly configured or settings configured using environment variables should not re-occur in the config.php file in order to allow future changes to environment variables and remove confusion as to where the value of settings (such as mail settings, reverse-proxy settings and DB settings) actually come from.

Related to

• #2086
• #464
• #189
• #1312: How to allow GUI configuration? should this purposefully create overrides in config.php and/or show a warning?

[joshtrichards]

Hi @manuth -

I get how it can be confusing, but:

• those extra *.config.php files take priority over config.php at runtime [1]
• autoconfig.php is an entirely separate beast and only relevant at install time (one-off) [2]
• you can always see your full NC config by running occ config:list system since it is multi-config.php aware [3]

When initializing a new Nextcloud installation, the maintenance:install part of the installation creates redundant settings which draw docker environment variables unfunctional.

occ maintenance:install is upstream (it's provided by server). We don't have control over what it does here in the Docker image. The Nextcloud Server installer writes out the initial config.php at install time based on the live config at install time. It'll include the values of whatever is active at that point in time, which happens to be whatever was initially specified via the Docker environment. The sub-config.php files will still take precedence at runtime so most of the parameters, however, can be managed still via Docker later as needed (the exception is the db parameters that flow through autoconfig.php).

Take note that all settings occurring in the previously named files also occur in the config.php file. This means that future changes made to the environment variables won't have any effect which, as far as I assume, isn't the expected or desired behavior.

Only if the Docker variable is absent. If one is present it'll take priority. The db related variables are the only exception because they flow through autoconfig.php (so they're entirely an "one-off" / install time parameter).

You can easily test this by setting one of the non-db related values to something bogus in your Compose. You'll see the change flow through after recreating the container (to the running Nextcloud instance; not to it's main config.php but that's because config.php is only one of the active config files when multiple config files are in use).

Settings occurring in the files autoconfig.php, apcu.config.php, apps.config.php, reverse-proxy.config.php, smtp.config.php, redis.config.php etc. which contain implicitly configured or settings configured using environment variables should not re-occur in the config.php file in order to allow future changes to environment variables and remove confusion as to where the value of settings (such as mail settings, reverse-proxy settings and DB settings) actually come from.

I agree it can probably be better. But there are some big constraints:

• a clean/reliable migration path for existing installations (this is a biggie!)
  • not just via the entrypoint.sh but also assumptions various environments make about the how things currently function, what config files are there, etc. (e.g. assumptions made by locally created automation tools, etc.)
• upstream Server installer behavior (which there may be room for adjustment as well, but it'll have the same constraints in its own way across an even wider breadth of installations)

I'd love to see things unified, but someone would need to not only come up with a "Point B" but also come up with a clean path from "point A" to "point B" for all existing installations. And then still convince enough people that the change is worth the risk created (and effort required) by introducing the change.

Keep in mind not everyone may agree with me, including other members of the project. So I'll keep this open in case others want to contribute to the discussion.

Footnotes:

• [1] Take a look at how multiple config.php files are handled by NC:
  • https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#multiple-config-php-file
• [2] https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/automatic_configuration.html
• [3] There may also be room for improvement in the docs at various levels:
  • here for the Docker images
  • upstream at Server in terms of how multiple configurations are handled
  • etc.

[neurolag]

Thank you so much for the exmplanation! I had trouble with emails constantly containing links pointing to http://localhost despite the fact that I added OVERWRITECLIURL to my docker container. I was almost certain that the config.php has to be to blame. However, occ config:list system indeed does pick up the changes.

I'm terribly sorry for the false alarm

[joshtrichards]

I'll see about what can be done to make it clearer in the docs. Tracking in #2244.