Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inventory and clarify how each auto-config value is handled [WIP] #2224

Open
joshtrichards opened this issue May 23, 2024 · 0 comments · May be fixed by #2228
Open

Inventory and clarify how each auto-config value is handled [WIP] #2224

joshtrichards opened this issue May 23, 2024 · 0 comments · May be fixed by #2228

Comments

@joshtrichards
Copy link
Member

joshtrichards commented May 23, 2024

We currently inject auto config variable a variety of ways.

Some:

  • are install time only
  • can be used all the time
  • only are used if other variables are specified with them
  • make there way into the main config.php if they're provided at install time
  • will never appear in the main config.php
  • are injected in more than one way depending on other factors
  • etc

These creates confusion in a variety of ways:

  • "Why aren't my configuration changes taking effect?"
  • "Which variables can only be specified at installation time?"
  • "Why are the variables apparently taking effect, but not appearing in my config.php"?
  • "Why does my long-time installed container's variable handling not match the docs?"
  • "How can I see my real running configuration if it's not visible in config.php"?
  • "Why doesn't this work in rootless environment?"
  • "Why does this variable only work when injected as a secret?"
  • "Why are my SMTP settings made via the web UI being overridden?"
  • "Why do my variable values sometimes show up in the main config.php and other times they don't?"
  • "Why are my Docker Compose and config.php values completely out-of-sync?"
  • etc

Here I'll attempt to inventory and analyze each variable so that we can then:

  • improve our documentation
  • determine where there are potential opportunities to enhance things (to make things easier to understand, more useful, etc.)
  • determine where there is potential technical debt (e.g. differences that inconsistent or no longer necessary)

Background:

  • Some of the variables are handled in particular ways out of necessity, such based on how the standard Nextcloud Server installer works.
  • Some of these are essentially for historical reasons, driven by a mixture of "just how it was implemented initially", backwards compatibility needs, and/or mere technical debt that hasn't been addressed.
  • Then we also have the NC_* support native to Server itself (see Document how to use NC_* environment variables with Nextcloud Server via the image #2226), but not documented upstream (but something we tend to suggest when people request new variables to adjust Server parameters get added here) nor documented for the image formally either officially

We likely can't fix all of them, but we can document them clearly. And, in the process, possibly also make some implementation adjustments where it make sense.

The variations (this basically needs to be translated into a big table or something):

  • Installation time only (first startup only) via image's entrypoint.sh
  • Installation time only (first startup only) via Server's autoconfig.php
  • Can be specified anytime and will override config.php
  • Will appear within config.php
  • Will appear only within occ config:list system
  • Require other variables to be present in order to be used
  • Requires root/can't be used in rootless environment
  • Can be specified as a Docker secret / from a file
  • Handled via container-specific extra config files (config/*.config.php)
  • Injected via { PHP's, Apache's } built-in environment variable substitution

Installation time only:

  • NEXTCLOUD_ADMIN_USER
    • requires NEXTCLOUD_ADMIN_PASSWORD
  • NEXTCLOUD_ADMIN_PASSWORD
    • requires NEXTCLOUD_ADMIN_USER
  • NEXTCLOUD_TRUSTED_DOMAINS
    • requires NEXTCLOUD_ADMIN_USER and NEXTCLOUD_ADMIN_PASSWORD
  • SQLITE_*
    • Installation time only (first startup only)
    • via image's entrypoint.sh (or) via Server's autoconfig.php
      • Injected via entrypoint.sh if used with NEXTCLOUD_ADMIN_* (provided to Server's installer)
      • Injected via Server's built-in autoconfig.php support if used without NEXTCLOUD_ADMIN_* (pulled in by Server's installer)
  • MYSQL_*
    • Installation time only (first startup only)
    • via image's entrypoint.sh (or) via Server's autoconfig.php
      • Injected via entrypoint.sh if used with NEXTCLOUD_ADMIN_* (provided to Server's installer)
      • Injected via Server's built-in autoconfig.php support if used without NEXTCLOUD_ADMIN_* (pulled in by Server's installer)
  • POSTGRES_*
    • Installation time only (first startup only)
    • via image's entrypoint.sh (or) via Server's autoconfig.php
      • Injected via entrypoint.sh if used with NEXTCLOUD_ADMIN_* (provided to Server's installer)
      • Injected via Server's built-in autoconfig.php support if used without NEXTCLOUD_ADMIN_* (pulled in by Server's installer)
  • NEXTCLOUD_DATA_DIR
    • Installation time only (first startup only)
    • via image's entrypoint.sh (or) via Server's autoconfig.php
      • Injected via entrypoint.sh if used with NEXTCLOUD_ADMIN_* (provided to Server's installer)
      • Injected via Server's built-in autoconfig.php support if used without NEXTCLOUD_ADMIN_* (pulled in by Server's installer)

Anytime

  • NEXTCLOUD_UPDATE
  • NEXTCLOUD_INIT_HTACCESS
  • REDIS_*
    • Requires root/can't be used in rootless environment
  • SMTP_* and MAIL_*
  • OBJECTSTORE_*
  • PHP_*
    • Injected via PHP's ini files (with built-in environment variable substitution)
  • APACHE_BODY_LIMIT
    • Injected via Apache's own config files (with built-in environment variable substitution)
  • APACHE_DISABLE_REWRITE_IP
    • via entrypoint.sh
  • TRUSTED_PROXIES and OVERWRITE*
    • will override config/config.php
    • handled via config/reverse.proxy.php
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant