Currently, the Virtualmin NGINX module spits all virtualhosts into /etc/nginx/nginx.conf.
That's VERY bad practice and is a maintenance nightmare.
There's a built-in mechanism in place for virtual hosts.
/etc/nginx/sites-available: this is where virtual host config files are stored
/etc/nginx/sites-enabled: this is where symbolic links (or file shortcuts) to the virtual host config files are placed
Here's an example /etc/nginx/sites-available/example.com.conf
server_name example.com www.example.com;
... all that per-server stuff you are currently spitting into the main config file...
To enable the config, just:
ln -s /etc/nginx/sites-available/example.com.conf /etc/nginx/sites-enabled/example.com.conf
Then restart NGINX.
See how much nicer that is, compared to spitting everything into the main daemon config file?
Please fix this, seriously. ;-)
One more thing when it comes to NGINX and SSL: http://www.virtualmin.com/documentation/web/nginx says that "Only one virtual server can have SSL enabled per IP address, even if a wildcard or UCC certificate would potentially allow multiple SSL sites to share the same IP."
This is incorrect. If you set up multiple servers on the same port but with different certificates, then NGINX uses SNI (Server Name Identification) to determine which certificate to send and will send the proper one. All modern browsers support SNI. If the browser doesn't understand SNI, then it might use a random one, or none at all, I haven't tested (only WinXP users running Internet Explorer would be affected).
However, disregard that and listen to me when it comes to the proper setup:
... listen on port 80 and 443 (SSL).
With this setup, it works as follows: If it cannot determine the hostname via SNI, it will give the client "/my/awesome/default.cert". If it received a hostname via SNI, it gives the client "/home/example/ssl.cert"
AND, as an added bonus: If a virtual server is bound to a completely unique IP/port combo, then it serves THAT certificate regardless of SNI status.
Here's more information: http://wiki.nginx.org/NginxHttpSslModule#Using_Wildcard_certificates_wit...
So, did you catch all that? It means:
- Make the Virtualmin-NGINX module write each virtual host to individual config files under /etc/nginx/available-sites and symlink them to /etc/nginx/enabled-sites
- Make the Virtualmin-NGINX module write a default certificate to the /etc/nginx/nginx.conf file and allow the user to choose which certificate should be the default written to this file
- Remove the warnings about sharing SSL certificate because they're silly (in the module)
- Fix the NGINX documentation at http://www.virtualmin.com/documentation/web/nginx since it's wrong about SSL, even in the current state of the module (SSL on same IP:Port is fine even today).
These are relatively small changes but would fix Virtualmin's NGINX support and make it a lot better, pretty much a first class citizen comparable to Apache. So, whadd'ya say? Is it worth spending half an hour fixing these things in the Virtualmin-NGINX module and uploading a new version of the package? I'd say so. I'd definitely say so. ;-)
It won't even break existing setups, if you just make an install/upgrade script that runs by default on installing the newer Virtualmin-NGINX module, which scans /etc/nginx/nginx.conf for the current, messy way that you are defining virtualhosts, and exports them to proper "site" config files as described above. So, add another half hour for that and call it a job well done!