Closed artonge closed 3 years ago
One solution could be to allow access to the php-fpm process through port 9000 which would allow to reverse proxy nextcloud from another server.
@jdrouhard Would that work for your use case?
Another solution would be to white-list the plugin's self-signed certificates on the reverse proxy side.
Another solution would be to allow access through port 80. But I am not a fan of this, as it would add some complexity to make it conditional.
One solution could be to allow access to the php-fpm process through port 9000 which would allow to reverse proxy nextcloud from another server.
I think this would work, but it'd require moving most of the actual HTTP server config to my reverse proxy and I'd no longer get the updates to that as part of the plugin (much more manual work on my part to ensure the HTTP config is sync'd).
Another solution would be to white-list the plugin's self-signed certificates on the reverse proxy side.
I'm not a huge fan of this. I'd rather not have my reverse proxy decrypt traffic and then re-encrypt for the nextcloud instance to just decrypt it again. Afterall, the reverse proxy <-> nextcloud instance is entirely internal so I don't need that connection to be encrypted.
Another solution would be to allow access through port 80. But I am not a fan of this, as it would add some complexity to make it conditional.
I think this is the option I like the best :smile: It's most similar to how the plugin was set up before this most recent version and worked flawlessly for a very long time. I think it wouldn't be too hard to make this conditional.
Include the "common" HTTP server settings in its own file (all the nextcloud-specific stuff), and then just have two templates: one that uses the self signed SSL certs and listens on 443 (with a redirect on 80), and the other can just listen on 80 without SSL. It might take a bit of refactoring since the main nginx.conf script includes some SSL-related configuration, but that can just be moved to the nextcloud-ssl template file. The init script that currently syncs the template config with the "real" config can just gain a simple conditional that decides which template to use based on the config option. You can use another config option (or the same one, for that matter) to determine whether the letsencrypt certbot cron job runs to renew certs, since that part isn't necessary for a non-SSL plugin setup.
I haven't thought about this too much yet but it doesn't seem like it'd be that bad once it's refactored appropriately.
I think this would work, but it'd require moving most of the actual HTTP server config to my reverse proxy and I'd no longer get the updates to that as part of the plugin (much more manual work on my part to ensure the HTTP config is sync'd).
True that.
I haven't thought about this too much yet but it doesn't seem like it'd be that bad once it's refactored appropriately.
Let me sleep on that, I'll try to have something early next week.
From https://github.com/freenas/iocage-plugin-nextcloud/issues/45, a valid use case was raised by @jdrouhard to allow unencrypted access to the plugin.