No documentation on NEXTCLOUD_CONFIG_DIR

[jluttine]

The documentation doesn't mention that the environment variable NEXTCLOUD_CONFIG_DIR can be used to change the path to config.php. This was implemented in https://github.com/nextcloud/server/commit/cc8b50898768805f4e3b2e91bc9346db831a08bc. For more information, see https://github.com/nextcloud/server/issues/300.

[mathiasconradt]

Referencing @rullzer 's comment here: https://github.com/nextcloud/server/issues/7802#issuecomment-357163671

Well it is not really documented because this is not recommended or supported really ;)

[trenshaw]

Is this the answer / solution to multi-tenancy in Nextcloud? ownCloud announced multi-tenancy in 2016. See: https://owncloud.com/blog-multi-tenancy-owncloud/

Has anyone looked at ownCloud's approach to multi-tenancy?

[rullzer]

The question to ask here is what problem are you trying to solve.

Because doing multitennancy like this means that you have to upgrade all the instances like this in lock step. You are sacrificing a lot of flexibility for the sake of a few MB. And the MBs taken up by nextcloud are probably insignificant to the amount of data stored.

[trenshaw]

It's all about saving time not space.

When bringing on a new client, the client would create a CNAME in their domain e.g. cloud.example.org to point to nc.provider.com

As a provider we would pass any cloud.* server requests from our reverse proxy to our pool of backend web servers.

The backend web servers all reference the same NFS symlinked vhost conf for cloud.example.org which sets the NEXTCLOUD_CONFIG_DIR for that client e.g. /path/to/nextcloud/config/clientA through 'fastcgi_param'.

The config path being a sub-directory within the document root of a single NFS installation of Nextcloud mounted in all of the backend web servers

The config.php in /path/to/nextcloud/config/clientA would define the data dir e.g. /path/to/nextcloud/data/clientA and database to use e.g. nc_clientA which is repeated for clientB, clientC etc.

This puts all clients on the same version of Nextcloud but more importantly means future upgrades need only be performed once not 3 or more times for each client.

The only exception to this would be applying database changes as part of an upgrade. This step would need to be repeated for each client but could be easily automated e.g. a bash script to loop loop through /path/to/nextcloud/config/ and set NEXTCLOUD_CONFIG_DIR to each sub-directory before calling occ upgrade with a --database-only or similar argument to only apply the database changes.

I don't know if occ upgrade accepts this or a similar argument? If not, then perhaps this needs to be a feature request?

[rullzer]

@trenshaw well in theory.

But now consider the following

• 1000 clients
• You start the upgrade
• 1000 clients have to be put into maintenance mode
• You start the loop upgrading the servers
• Installation 580 has a bug and the upgrade fails (for whatever reason, a bug can always happen)

What do you do?

Or even if it all runs trough. The final insllation is in maintenance mode until the first 999 are all properly upgraded

I do see the appeal in having it separated like this. But I would suggest to when a new client signs up call a script that just extracts the current tarball you have to ..../CLIENTID or something. This could also all be automated. And would also be almost instant.

[joshtrichards]

The multi-tenancy discussion may still be interesting to a few folks, but it should probably be taken elsewhere (out of documentation) IMO. There are other spots like nextcloud/server#7802 and even nextcloud/server#300 or perhaps a new issue thereabouts.

This issue here in documentation could have probably been closed by this: https://github.com/nextcloud/server/issues/7802#issuecomment-357163671

😆

[joshtrichards]

I think four years is enough time to make the judgement to close this stale Issue out (in docs) as a "won't fix" (for now) since this feature exists but isn't encouraged. And documenting it means supporting it and that doesn't sound desirable. :)

Maybe someday a chapter/manual for "Large Deployments" or something could include it. Might also be some spots on the GmbH customer portal for it (with better engineering context), but that's out of scope for here.

[DataGhost]

@joshtrichards sorry for the ping but I'm not entirely sure comments to closed issues are seen otherwise.

I'm having trouble following this rationale. It's been in the codebase for almost eight years now and it's a very simple protection against dumb configuration errors. It's hooked in pretty early and right next to (and does the same as) the testing code, which I assume has been tested and is working. If this were to break anything in production that would mean a code path was taken which in itself should be unsupported. So I don't really see how much "support" this feature could require. But even documenting it and explicitly saying "we won't support this (because )" is much better for security-minded people than nothing.

I just wanted to move my config outside the webroot in order to eliminate the chance of it and the credentials contained in it ever being publicly readable through the web server when the perfect storm of misconfiguration happens. I've seen another ticket https://github.com/nextcloud/server/issues/16472 that was just closed without any comment or change and a thread https://help.nextcloud.com/t/config-php-outside-web-root-why-not/82683 where the issue was just waved away with "there is .htaccess" and "you'll have bigger problems" citing e.g. access to the data directory which, in my case, is also outside the webroot, after which it just died off.

These were the first few results I found googling for "nextcloud config outside webroot" and lacking anything in the documentation I was very close to opening a ticket or even PR, but diving into the code I stumbled upon this NEXTCLOUD_CONFIG_DIR which seems to do exactly what I need, besides needing a small tweak in the cronjob and virtualhost configs, nothing difficult. The corresponding issue https://github.com/nextcloud/server/issues/300 also linked in here is exactly clear and precisely describes this use-case. I don't think the way to stumble upon this feature should be actually reading the source code. This google search should have pointed me to a documentation page.

I personally think that config files (or anything containing credentials) have no business being inside the webroot, they're not required to be there, they can live anywhere. They're just a possible attack vector in case things go wrong and I'd say it's good practice to have them outside the webroot as a default, also in documentation, so that over time everyone will become aware of this practice. It should be encouraged. Right now there are no official resources on this absolutely trivial piece of security that, again, has been part of the codebase for almost eight years now. So I'd vote to reopen this issue and actually document what this does with some very basic instructions (the env var and maybe open_basedir are the only things required usually) and at the very very least include a reference in the installation docs "if you're concerned about security, look here".

[joshtrichards]

Right now there are no official resources on this absolutely trivial piece of security that, again, has been part of the codebase for almost eight years now. So I'd vote to reopen this issue and actually document what this does with some very basic instructions (the env var and maybe open_basedir are the only things required usually) and at the very very least include a reference in the installation docs "if you're concerned about security, look here".

You're welcome to submit a PR. As far as I'm concerned it shouldn't have been merged into the code base without corresponding documentation / if we weren't comfortable documenting it. :-)

However:

• documenting this in any way means someone is taking responsibility for understanding the feature fully and documenting how it can/should be used
• it's been 8 years and while apparently it's important enough for a couple of people to comment on, it's not been important enough for anyone to step up and do the prior item :)
• ideally someone already using this feature actively would take a first pass at documenting it and/or collaborating with/reviewing any proposed PR [appears it is actively used by the Snap so maybe @kyrofa et al are willing to help give any proposed doc addition for this a review from a real-world context perspective]

Re: security context - Security topics are not lightweight topics to be added to the manually offhandedly IMO - merely mentioning this in the context of security means a lot of folks will just do it blindly. That's fine if the general consensus seems to be in that direction, but I don't get that sense at the moment (obviously that could change once it's documented and more widely known to even be an option).

A start might be a neutral addition basically cleaning up the language in the original PR + its comments (nextcloud/server#660). If someone wants to come back in an try to layer in some security context in a follow-on PR, great. But my understanding is this isn't purely a security feature anyhow (though I can see how it could be used in that way in some scenarios).

So maybe we start with adding some basic docs here?

https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html

Then later on it may start to make sense to include something here too:

https://docs.nextcloud.com/server/latest/admin_manual/installation/harden_server.html

Keep in mind these are purely my opinions. Others are obviously welcome to weigh in.