installing mash-nextcloud as subdirectory, not subdomain, breaks urls

[brush]

if using the default config in vars.yml, with

nextcloud_hostname: mash.example.com nextcloud_path_prefix: /nextcloud

then the first admin account setup page will load, but without graphics, and clicking install will fail.

installing as subdomain works correctly.

[0xN0BADC0FF33]

Are you installing from mash.example.com/nextcloud or are you trying to run it from example.com/nextcloud?

[brush]

Are you installing from mash.example.com/nextcloud or are you trying to run it from example.com/nextcloud?

not entirely sure what you mean? obviously the domain i use is different... but the same as i used for miniflux, which works.

ie. this works:

miniflux_hostname: MYDOMAIN
miniflux_path_prefix: /miniflux

but this does not:

nextcloud_hostname: MYDOMAIN
nextcloud_path_prefix: /nextcloud

[moan0s]

I just spun up a test instance and could reproduce the problem. The problem stems from the fact that 'overwritewebroot' => '/nextcloud', in /mash/nextcloud/data/config/config.php is not yet set. This will only happen when you run just run-tags adjust-nextcloud-config.

Specifically this will run this task which will set these parameters

This bug should only affect the initial setup (so just use the form as-is). After that you should run just run-tags adjust-nextcloud-config and the paths will be set correctly. I'll think about a solution to streamline this in setup though

[spantaleev]

Don't the setup instructions mention the need for running adjust-nextcloud-config separately, after installing?

It's not ideal, as people might skip this step, but.. it's done this way, because it requires that Nextcloud be fully started (something usually done later by the systemd service manager role, as part of the start tag). If we are to make it part of the role, we'd need to have the role actually start Nextcloud at some point, run these things.. and potentially stop it later (to restore the state it was in before it started it).

Roles usually avoid starting services themselves and leave that to the systemd service manager role (and its start tag) due to historical reasons coming from matrix-docker-ansible-deploy. Sometimes you want to do install-all, but not start all the services yet, because you want to import an existing database. If services get started, most of them (e.g. Synapse) would initialize the database with some fresh data and you won't be able to import your existing database dump.

Some services likely feature a setup wizard and do not initialize the database even if you start them, but I believe most auto-initialize it and make such database-dump-importing difficult (you'd need to stop the service manually, clean up the database, and then import the dump -- annoying).

Because of this, I believe the "run this tag separately, at least the first time around" is a good compromise.

---

Still, in some environments you may wish to have a fully automated setup which doesn't involve multiple playbook runs. It'd be good to be able to accommodate those too and streamline it.

Perhaps some variable could be set in vars.yml (e.g. nextcloud_adjust_config_during_installation_enabled: true) which tells the role to start Nextcloud and run the adjust-nextcloud-config steps during installation (on tags: install-nextcloud, setup-nextcloud, install-all, setup-all).

We can then adjust the docs (docs/services/nextcloud.md) to:

• set it to true in the example configuration, along with a nice comment telling people what it does and why/when they may wish to comment it out (when restoring backups, ..)
• remove the instructions about the mandatory adjust-nextcloud-config step. Perhaps they should remain mentioned as optional (in case you commented out nextcloud_adjust_config_during_installation_enabled: true)

[PatMulligan]

I just spun up a test instance and could reproduce the problem. The problem stems from the fact that 'overwritewebroot' => '/nextcloud', in /mash/nextcloud/data/config/config.php is not yet set. This will only happen when you run just run-tags adjust-nextcloud-config.

Specifically this will run this task which will set these parameters

This bug should only affect the initial setup (so just use the form as-is). After that you should run just run-tags adjust-nextcloud-config and the paths will be set correctly. I'll think about a solution to streamline this in setup though

I tried running just run-tags adjust-nextcloud-config, however I receive the following error:

TASK [galaxy/nextcloud : Adjust Nextcloud configuration (set trusted_proxies)] ************************************************************
fatal: [domain.com]: FAILED! => changed=true 
  cmd:
  - docker
  - exec
  - --user=997:1002
  - mash-nextcloud-server
  - php
  - /var/www/html/occ
  - --no-warnings
  - config:system:set
  - trusted_proxies
  - '0'
  - --type=string
  - --value=172.23.0.0/16
  delta: '0:00:00.071456'
  end: '2024-02-29 16:27:32.122032'
  msg: non-zero return code
  rc: 1
  start: '2024-02-29 16:27:32.050576'
  stderr: |2-

      There are no commands defined in the "config:system" namespace.
  stderr_lines: <omitted>
  stdout: ''
  stdout_lines: <omitted>

PLAY RECAP ********************************************************************************************************************************
domain.com                   : ok=7    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

Appending 'overwritewebroot' => '/nextcloud', in /mash/nextcloud/data/config/config.php did the job, it still threw me to a 404 a couple times during the setup flow, but it did install and function. After that, I tried running the command just run-tags adjust-nextcloud-config again and it worked as well 🤷‍♂️

Edit: So after appending 'overwritewebroot' => '/nextcloud', to the config.php file, it sent me, erroneously, to mash.domain.com/index.php without the modified webroot. After running it a couple times it seems to get through.