I experienced strange glitch Web Server and was not able to restore it using the dietpi backup. Fortunately I was able to salvage MYSQL database and the user data. To which I been able to reinstall next cloud to a Nginx Web Server. I’m glad to report everything works as expected. I need a little help navigating configuration files. Dietpi seems to use templates found in /etc/nginx. Normally one would be able to navigate to different configuration files for different web services navigating to /etc/nginx/sites-enabled. The configuration file within that web directory only points to etc/nginx/sites-available/default. Nothing seems to indicate next cloud is installed in /etc/nginx/* yet clearly next cloud is operational.
Certbot doesn’t support nginx as the warning suggests and several tickets on Git hub indicate. I need to access Nginx configuration files for next cloud so I can manually install the certificates from my old server.
Nothing seems to indicate next cloud is installed in /etc/nginx/*
Its not required, the default site allows for everything under /var/www to be accessable on the webserver. eg: /var/www/nextcloud, /var/www/wordpress etc
I’m sorry to complicate things it’s just the only way I’ll be able to use SSL and set up rewrite for ‘.well-known’ for webDav
From my understanding, in a standard configuration the sites-enabled folder is used for virtual host definitions, while conf.d is used for global server configuration. If you’re supporting multiple web sites – i.e., virtual hosts – then each one gets its own file, so you can enable and disable them very easily by moving files in and out of sites-enabled or creating and removing symlinks.
Dietpi configuration is different.
sites-available ( contains symlinks ‘default’ from sites-enabled)
sites-enabled (containing ‘default’ physical file)
sites-dietpi (unused)
conf.d (unused)
…
nginx.conf which resides in ‘/etc/nginx’
default’ which resides in sites-enabled
I can see how that can be useful from a ease-of-use point of view. Nextcloud has a lot of optimizations and security that are recommended by their Administration Manual. Hence a separate site specific configuration is needed (virtual host). Is there anyway I can actually exclude nextcloud from the global config while maintaining the global default config which ensures dietpi compatibility?
The main reason we use a single global config for all sites is:
For most users, this global site config is ideal, allowing the user to simply “drag and drop” a website into /var/www, without the need to setup individual site configs.
We have to support 3 webservers (Apache2, Nginx, Lighttpd). A default site for each, is preferred from our end, in terms of simplifying maintenance and support.
If you are looking to control sites with multiple site configs, this is fine, however, installing any software again in dietpi-software, will rewrite (and enable) the global site config.
Another option would be to set required options in the global site config /etc/nginx/sites-available/default, and limit it to the nextcloud directory, eg:
</var/www/nextcloud>
Do this
</>
It may even be possible that multiple site configs, will override settings in the global site config anyway?
In terms of NextCloud security, the only thing we are unable to setup for the user, is SSL (we recommend certbot with lighttpd/apache2). Aside from that, all other security requirements are for-filled.
I will look into this piecemeal for you Zone. I think Dietpi as a principal should be configured to be compatible for standard Web server practices while maintaining global site config, allowing the user to simply “drag and drop” a website into /var/www, without the need to setup individual site configs if desired.
Two issues
Certbot Does not work with all Web servers. A more flexible solution is required. Fortunately I found an alternative to Certbot which should be compatible with all Web servers and is lighter on system resources which follows standard practices of let’s encrypt. With just a little tweak on the Dietpi side of the equation. Soon I will create a guide and recommendation to integrate with Dietpi. Hopefully this will solve one of the issues.
Second what is substantially harder requires a bit of research and most likely a change to how Dietpi sets up all Web servers. We will see how this works out but no promises. Each Web server would essentially have to allow site config’s to override global settings.
