• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Question NGINX Unit on server under plesk

deepnpisgah

New Pleskian
Server operating system version
Ubuntu 22.04
Plesk version and microupdate number
18.0.59.2
I would am running FastAPI ASGI applications on my virtual host managed by Plesk. Phusion Passenger is available but only supports WSGI. NGINX Unit can run WSGI and ASGI python applications. I already have several Flask apps running in Phusion Passenger via Apache, but if I switch to NGINX Unit I can run both WSGI and ASGI from one application server (and other Frameworks too). But there's no way via Plesk to configure NGINX as reverse proxy for NGINX Unit because it needs to insert configuration into either Location{} or Server { Location{} } and that's not allowed where the Includes are available via Plesk - since the http{} configuration is already closed by then (Server and Location live inside http{} as in http{ Server { Location{} } }).

Based on how nginx configuration gets generated by plesk I have dropped a file names zz020_myasgiconfig.conf into /etc/nginx/conf.d and so as part of configuration generation it gets included just after zz010_psa_nginx.conf and I can add my own server{} directive.


server {
listen <myip> ssl http2;

ssl_certificate /opt/psa/var/certificates/xyz12345;
ssl_certificate_key /opt/psa/var/certificates/xyz12345;

server_name api.myhost.com;


location /api/myapp/ {
rewrite ^/api/myapp/(.*) /$1 break;
proxy_pass http://127.0.0.1:<app port in UNIT>;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}

It works and it is 'configuration regneration proof' - but I have a few questions before calling it a total solution.

1) Will the /etc/nginx/conf.d directory get changed (or my zz020... file deleted) on a Plesk upgrade or update?

2) The only part of my conf that needs to adapt over time is the ssl_certificate and ssl_certificate_key which will change when a new certificate is generated, is there some hook or include within the Plesk infrastructure I can use to get that updated as an include? Otherwise I would need to periodically update my conf file to reflect the current certificates.

thanks!
 
1) Will the /etc/nginx/conf.d directory get changed (or my zz020... file deleted) on a Plesk upgrade or update?
Existing files managed by Plesk may be changed, but additional custom files that you create will not be touched.
2) The only part of my conf that needs to adapt over time is the ssl_certificate and ssl_certificate_key which will change when a new certificate is generated, is there some hook or include within the Plesk infrastructure I can use to get that updated as an include? Otherwise I would need to periodically update my conf file to reflect the current certificates.
There is no such hook, but why can you not let Plesk manage the certificate for you?
 
Plesk manages the certificates perfectly - it gets renewed and then the new certs are dropped in /opt/psa/var/certificates, but they are all uniquely named and I suppose Plesk figures out the current one within the PHP scripting that generates the config or just gets the name they are saved as during the automated certificate renewal and updates its own include files. I get an email from Let's Encrypt when certs need renewal and that seems to be the same time Plesk renews them too - I will just need to pay attention for that so I can update my conf file.
 
Huh? Certificates should be just updated in-place without changing their names.
 
2) The only part of my conf that needs to adapt over time is the ssl_certificate and ssl_certificate_key which will change when a new certificate is generated, is there some hook or include within the Plesk infrastructure I can use to get that updated as an include? Otherwise I would need to periodically update my conf file to reflect the current certificates.

@deepnpisgah

For this purpose, it is better to add a paid for SSL certificate, for many reasons.

This paid for SSL certificate has to be ordered elsewhere and has to be "uploaded" manually in Plesk - after that, you can assign it to the domain in question.

Why should this be preferred over Let's Encrypt certificates?

First of all, Plesk can encounter and/or Let's Encrypt has some (often unexpected) issues when securing subdomains - your app is hosted on a subdomain.

Second, Plesk uses the LE certificate of the main domain to secure subdomains - you are essentially using the equivalent of a wildcard ssl certificate.

Third, Plesk and wildcard ssl certificates are to be setup with care - when using wildcard LE ssl certificates, Plesk can cause some issues every now and then.

Fourth, a recommended way to setup wildcard ssl certificates is to use DNS to enable verification - it is good to have DNS nameservers hosted elsewhere.

Fifth and final, a paid for wildcard SSL certificate allows you to

- secure a domain and all of its subdomains : ideal for securing production and testing/development environments,
- prevent any issues that might or often can occur with Plesk based LE wildcard ssl certificates,
- keep a ssl certificate for a duration of 1 to 2 years, if desired
- use external DNS nameservers for verification purposes : ideal and preferable, for many reasons

and the manual process of renewing the paid for wildcard SSL certificates is a price to pay, but it is often worth it.

In summary, as long as a LE ssl certificate can suffice, do not change anything ........ but prepare for that moment that LE related issues occur.

Have a good look and/or test the implementation of paid for wildcard ssl certificates in the meantime!


I hope the above helps a bit ......


Kind regards....


PS There is no need to add the suffix zz020 to the nginx conf file name (read: zz020_myasgiconfig.conf) - Nginx does not really care and/or is able to read a lot of config files and decide which config line is most appropriate and which config line should be applied, irregardless of the config file in which the config line is located. Personally, I would recommend to remove the suffix or change the suffix in such a way that it is clear to you that it is custom config.
 
Back
Top