Excluding IP address from Nginx Listen directive

Hello,

We have recently switched from using Apache to using Nginx in our Virtualmin Professional setup. Virtualmin's Apache-related settings allow for lots of customization to generated virtual host blocks (), but Virtualmin's Nginx support does not seem to allow for as much customization.

For example, Virtualmin allows you to customize the IP address used to define VirtualHost blocks, i.e. for all addresses, or for a specific address.

But when creating virtual servers on Nginx, Virtualmin always inserts the system's IP address when writing out the associated Listen directive in the Nginx virtual host configuration. How can I change this behavior so that no IP address is added? The Listen directive doesn't require one to be set specifically.

Also how can I customize other portions of the default template Virtualmin uses to write out Nginx configuration files? I know I can add additional directives by way of the Nginx plugin configuration screen, but I want to customize the existing template that Virtualmin writes out for each new virtual server.

Thanks for any assistance provided!

Status: 
Closed (fixed)
Virtualmin version: 
6.14
Webmin version: 
1.962

Comments

You should be able to do this by having Virtualmin use a different IP address for the domain at creation time. There's an option for this on the virtual server creation page.

I'm actually not sure if your suggestion will work only because we have our Websites hosted on a cluster of servers. Virtualmin is installed on the main server in the cluster and manages everything, and then we use a combination of Git repositories and custom PHP scripts to push file changes (like Website files and Nginx virtual host configuration files) to the other servers in the cluster (that are running Webmin rather than Virtualmin).

Each server in the cluster has a different public IP address. We had the same setup when we used Apache, which is why I liked that when Virtualmin created new virtual host blocks in Apache configuration files, it used rather than a specific IP address in place of the asterisk, because then the files could be farmed out to the other servers in the cluster and bind to that server's IP address automatically. In other words, if Virtualmin had used that may have worked for the main server in the cluster but we would have had to manually edit the files on each of the other servers to change their IP addresses accordingly and make sure we made these same changes every time updates were deployed to the virtual host configuration files.

Does Virtualmin allow for something similar with the Listen directive of Nginx? Right now Virtualmin has Listen 1.2.3.4:443 which again is IP address dependent. Nginx lets you use a Listen directive that will bind to any IP address by just using the format "Listen 80" or "Listen 443". This is why it would be handy to customize the base template Virtualmin uses when writing Nginx virtual host blocks.

I don't think this is possible, because each Nginx server block has to contain a listen directive indicating which IP the domain is associated with.

If you manually edit a few of those listen lines and change them to just listen 80 , does Nginx still work as expected?

Yes. :) The other day I used the sed command to do a mass edit of all of my virtual hosts (as each Nginx virtual host is stored in its own configuration file) and replaced all my Listen directives so that for HTTP they now read "Listen 80", and for HTTPS they now read "Listen 443 ssl http2". One reason I did this was to enable HTTP/2 support in Nginx.

Anyways, I restarted Nginx and everything works just fine like it did before when the IP address was part of the Listen directive. I just don't want to have to do this editing manually for each new virtual server that I create, and I am also worried that if Virtualmin makes a change to an existing virtual server's config file then my edits might get overwritten unless I put them in a Virtualmin template or configuration variable somewhere.

Good to hear. In the next release of the Nginx plugin, we'll add a config option to support this style of listen directive.

Thank you! I appreciate how the Virtualmin team works quickly to incorporate feedback into updated versions of its software. Would you be able to also include an option to add HTTP/2 support to the SSL version of the Listen directive if SSL is configured for a virtual server? That would look like t his:

Listen 443 ssl http2;

HTTP/2 of course is the newest version of the HTTP protocol and offers many improvements and enhancements over HTTP/1.1. Nginx supports it out of the box (at least it does when installed natively via YUM on CentOS 7) but you have to add the "http2" keyword to the end of the Listen directive for each virtual server in which you wish to have HTTP/2 support enabled.

Hello again,

Just one more thing I wanted to add to this thread: rather than giving specific customization options inside Virtualmin, would it be possible to allow users to simply customize the Nginx virtual host configuration template as we can with Apache sites at the moment? That way I can customize things like the "Index" line, which I want to start with index.php even though Virtualmin uses index.html. I know that Virtualmin's Nginx support already gives the option to include additional directives in virtual host configuration files (outside of the default directives), but I want to be able to edit the default directives just like you can in server templates with Apache sites.

That last request is a bit more complex, because the current configs are dynamically generated and not as easily turned into a simple template.

We can add the http2 option though.

Ah, that makes sense. What would you recommend then for those who want custom configuration variables for Nginx virtual hosts? Should I just continue my current practice of editing configuration lines after the Nginx virtual host file has been generated? I am still excited about support for HTTP/2 and omitting the IP address from Listen directives as doing this manually is a very tedious process LOL. I look forward to the next Virtualmin release :)

By the way I also filed a related bug a few days ago having to do with Website redirects and an issue that arises when using them with Nginx and its virtual host config.

We actually already run pre and post scripts as part of our current clustered infrastructure so I could just add that to our existing scripts I suppose. I still believe however that adding the ability to remove the IP address by way of the Listen directive from within Virtualmin for new/existing virtual servers (i.e. as a toggle, like Apache) would be nice. The more customization Virtualmin offers out of the box, the less we have to write as part of a custom script that could potentially become incompatible with a future Virtualmin change (or vice versa).

The next release of the Nginx plugin will add an option to not include the IP address in listen directives.

Perfect, thank you. Are there also plans to add the option to enable HTTP/2 support by adding "http2" to the end of the Listen directive (for SSL sites only)? Then the Listen directive without the IP address would look like "Listen 443 ssl http2" (with HTTP/2 support enabled)

Yes, there will also be an option for that.

Hello! I see that Virtualmin 6.15 is now available, along with new versions of Webmin and Usermin as well. Has the Nginx plugin also been updated to address, for example, the items mentioned in this issue? Thanks!

Ilia's picture
Submitted by Ilia on Fri, 03/12/2021 - 12:00

Like mentioned on the previous thread, it will be needed to fix these bugs first.

I will try wrapping it up tomorrow.

Ilia's picture
Submitted by Ilia on Sat, 03/13/2021 - 07:59

Updated version of Virtualmin Nginx 2.19 and Virtualmin Nginx SSL 1.15 been released, and will appear in the repos shortly.

Thank you for releasing this update. I don't yet see it in the Virtualmin repository for CentOS 7 though; YUM says there are no updates available and I am still on Nginx module version 2.18. What should I do to install this update? Thanks!

Ilia's picture
Submitted by Ilia on Wed, 03/17/2021 - 11:20

Assigned: Unassigned »

Jamie, do you think there is anything else that is blocking new Nginx/Nginx SSL release that I recently tagged?

No I think we're good for a release, if it hasn't happened already

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.