Resolved nginx protocol options redefined

[learning_curve]

It has been identified as a product issue. We are working on a solution. We have some suggestions for workarounds. One is to set the "preferred domain" in "Hosting Settings" of the affected domain(s) to "none". Could you please try that and report back here if it helps?

FWIW Pretty sure that this definitely IS a Plesk / their own Nginx admin / update / process related issue that's causing all these warnings (which we have too).
Also pretty sure, that it's not connected to Kolab and/or other Nginx usual mods made elsewhere...

In theory... There is a simple fix and that is to add the missing "http2" parameter to the "listen" (443 only) directives because currently... it is NOT present in all of the server_name fields (IPv4 and IPv6) in all of the /etc/nginx/plesk.conf.d/vhosts/***your-domain-name***.conf files and the /etc/nginx/plesk.conf.d/server.conf file too, plus any others missed of here, all of which, are system generated by Plesk, so can't just be overwritten, as the changes will be lost.

Here's a sanitised example that's extracted from a /etc/nginx/plesk.conf.d/vhosts/***your-domain-name***.conf file.
The omission error is on the 1st "listen" line:

#ATTENTION!
#
#DO NOT MODIFY THIS FILE BECAUSE IT WAS GENERATED AUTOMATICALLY,
#SO ALL YOUR CHANGES WILL BE LOST THE NEXT TIME THE FILE IS GENERATED.
server {
    listen **Your Server IP Address**:443 ssl;

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

    server_name www.**Your Domain.com**
    
    ~~~~
    
    server {
    listen **Your Server IP Address**:443 ssl http2;

    server_name **Your Domain.com**;
    server_name ipv4.**Your Domain.com**;

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

    client_max_body_size *********
    
    ~~~~
    
    Now repeat this ^ omission error for all IPv4 / IPv6 addresses in all the files
    mentioned above (plus any others missed off here!)

Hopefully, this has already been recognised as an internal bug and we'll see a point release that corrects this very shortly

 

[tkalfaoglu]

I read this:

https://support.plesk.com/hc/en-us/articles/15476324656151

but it doesn't help with ipv6 addresses..

When I do a:

# grep -i listen /etc/nginx/plesk.conf.d/vhosts/* |grep ssl|grep -v http2 |more

there are still tonns (84 lines of it on this server) of listen directives without http2.. interestingly BOTH for ipv4 and ipv6.

 

[Peter Debik]

Meanwhile we know that the [warn] messages are a result of an Nginx update. Nginx is now expecting a certain directive in a certain place. This will be taken care of in a future Plesk update. But it is a warning only and cannot cause the initial issue described in this thread that web server configuration files are not generated.

 

[tkalfaoglu]

Update: Eventually I am down to 35 lines of listen statements causing warnings.. They are all ipv6 addresses.

 

[Tim_Wakeling]

Meanwhile we know that the [warn] messages are a result of an Nginx update. Nginx is now expecting a certain directive in a certain place. This will be taken care of in a future Plesk update. But it is a warning only and cannot cause the initial issue described in this thread that web server configuration files are not generated.

Ah, when you wrote that I realised - at the end of all those warnings was one message that probably caused the error to appear along with all the warnings: a duplicate directive. The red box was around the lot and it was not obvious that the last error was the only one causing the red box. It looked like all the warnings were as well. Anyway, I fixed that and set all domains to "none" on www preference. Now all is clear.

 

[learning_curve]

Meanwhile we know that the [warn] messages are a result of an Nginx update. Nginx is now expecting a certain directive in a certain place. This will be taken care of in a future Plesk update. But it is a warning only and cannot cause the initial issue described in this thread that web server configuration files are not generated.

An Nginx update, yes. One than makes common sense really. The Plesk update to match, is what (....guessing...) you're referring too above and yes it's warnings only (even though it's lots of them), so, whilst it's a bit tedious, assuming that the Plesk corrective update will be here soon, it seems more more practical to wait and implement that (as part of a normal Plesk upgrade process) than to spend time invoking the Plesk workaround (see post #22) YMMV of course!

 

[trialotto]

Meanwhile we know that the [warn] messages are a result of an Nginx update. Nginx is now expecting a certain directive in a certain place. This will be taken care of in a future Plesk update. But it is a warning only and cannot cause the initial issue described in this thread that web server configuration files are not generated.

@Peter Debik

Could you be so kind as to get this

https://support.plesk.com/hc/en-us/articles/15476324656151

"support" article offline?

It is a completely overengineered "support" article that does not make any sense ....... (fuzzy) scripts, event handlers in order to change Nginx config templates??


In essence, Nginx config templates should be changed

1 - by Plesk : an appropriate change of default Nginx templates, (and/or)

2 - if and only if necessary, by Plesk admins : in the form of custom Nginx templates.



The changes in the default Nginx config templates, as provided with Plesk to generate Nginx config files, are really straightforward.

Could you be so kind as to ask a Plesk Team member to contact me in a private conversation?

After all, this minor Nginx related hickup should not take long to patch!!!!


Kind regards......

 

[trialotto]

Ah, when you wrote that I realised - at the end of all those warnings was one message that probably caused the error to appear along with all the warnings: a duplicate directive. The red box was around the lot and it was not obvious that the last error was the only one causing the red box. It looked like all the warnings were as well. Anyway, I fixed that and set all domains to "none" on www preference. Now all is clear.

@Tim_Wakeling

In essence, it is not about "duplicate directives", even though it can seem like that.

I did a quick inspection and it seems to be the case that specific types of default templates (used to generate Nginx config files for different "types of Hosting") are treating ssl directives differently : the "ssl" but also the "ssl http2" is added to the Nginx listen directive in almost a random way.

If you see something that seems to be a "duplicate", then it is probably (with 99% certainty) a different Nginx config generation for different "types of Hosting".

Any fix should come from a change in the Nginx default templates used to generate the Nginx config files.

In short, that is a task for Plesk Team ........ and it is an easy task.

Kind regards....

 

[Tim_Wakeling]

@Tim_Wakeling

In essence, it is not about "duplicate directives", even though it can seem like that.

I did a quick inspection and it seems to be the case that specific types of default templates (used to generate Nginx config files for different "types of Hosting") are treating ssl directives differently : the "ssl" but also the "ssl http2" is added to the Nginx listen directive in almost a random way.

If you see something that seems to be a "duplicate", then it is probably (with 99% certainty) a different Nginx config generation for different "types of Hosting".

Any fix should come from a change in the Nginx default templates used to generate the Nginx config files.

In short, that is a task for Plesk Team ........ and it is an easy task.

Kind regards....

Thanks @trialotto - I wasn't quite clear in how I explained it. As well as all those warnings, I *also* had an nginx error involving setting a directive twice on one domain. It was my mistake, and had nothing to do with all the warnings. But it sounds from what Peter was saying that the warnings themselves wouldn't have showed up in the red box at all if it hadn't been for the fact they also included one unrelated "error".

Or perhaps you did understand that and in fact I've not followed what you're saying correctly. No matter - I appreciate the responses to my thread and am glad it's now being dealt with by Plesk.

 

[trialotto]

Thanks @trialotto - I wasn't quite clear in how I explained it. As well as all those warnings, I *also* had an nginx error involving setting a directive twice on one domain. It was my mistake, and had nothing to do with all the warnings. But it sounds from what Peter was saying that the warnings themselves wouldn't have showed up in the red box at all if it hadn't been for the fact they also included one unrelated "error".

Or perhaps you did understand that and in fact I've not followed what you're saying correctly. No matter - I appreciate the responses to my thread and am glad it's now being dealt with by Plesk.

@Tim_Wakeling

To be honest, I am pretty sure that you only had ONE error.

It seems to be the case that you tried to reconfigure domains, but that failed with the nginx -t test.

On its turn, the nginx -t test failed, thanks to and only thanks to the Nginx default config files not being in line with requirements for Nginx 1.24.

I believe that that is the only thing, but I can be mistaken.

Kind regards....

 

[Peter Debik]

The original issue ID PPPM-14042 will be fixed in 18.0.54.

 

[Peter Debik]

Plesk Obsidian 18.0.54, published July 18th, 2023: Enabling HTTP/2 no longer results in the “protocol options redefined” warning. (PPPM-14042)

 

[learning_curve]

Plesk Obsidian 18.0.54, published July 18th, 2023: Enabling HTTP/2 no longer results in the “protocol options redefined” warning. (PPPM-14042)

A couple of days behind (holidays!) but, the above is correct - Well almost... All of the relevant system related files have indeed now been corrected, which is nice to see. However, all of the vhost domain conf files, (IPv4 and IPv6) were not updated by default, by this latest Plesk Obsidian update (well not in our case anyway...) and these, also contained the same previous nginx generated warnings from the previous Plesk config. We rectified this with a short session on here **My-Hosting-Domain**:8443/modules/configurations-troubleshooter/index.php/index/list and once complete, the the standard nginx -t test results, are now back to what was expected i.e. no more "protocol options redefined" warnings, so PPPM-14042 has been a successful fix for us.

 

[trialotto]

A couple of days behind (holidays!) but, the above is correct - Well almost... All of the relevant system related files have indeed now been corrected, which is nice to see. However, all of the vhost domain conf files, (IPv4 and IPv6) were not updated by default, by this latest Plesk Obsidian update (well not in our case anyway...) and these, also contained the same previous nginx generated warnings from the previous Plesk config. We rectified this with a short session on here **My-Hosting-Domain**:8443/modules/configurations-troubleshooter/index.php/index/list and once complete, the the standard nginx -t test results, are now back to what was expected i.e. no more "protocol options redefined" warnings, so PPPM-14042 has been a successful fix for us.

@learning_curve

the web configurations troubleshooter itself is not working properly, so that is an additional bug.


In essence, there are still some error notifications with respect to "protocol options redefined" for some domains in specific circumstances.

The aforementioned error notifications can still follow if Nginx config is correct and if the command nginx -t returns a "config is OK".

The bug is not fully solved by the latest update.


Nevertheless, there is an issue in (consistently) replicating the aformentioned "specific circumstances".

As far as I can conclude, the "specific circumstances" are related to Nginx - probably with what is stored by Nginx in memory.

As far as I can see, very specific subdomains are affected, such as the webmail.example.com subdomain.



In essence, the plesk repair (CLI) utility might help in case the web configurations troubleshooter (via Plesk GUI) does not work.

However, the nasty thing is that the plesk repair utility only seems (!) to work if all domains are repaired (read: repairing one domain does not help).

And the plesk repair utility does repair utility does create proper config, but still there is this error notification for the odd domain or subdomain.


It is a bit of a mystery to me - any idea, somebody?


Kind regards.....

 

[Peter Debik]

The "protocol options" issue is not automatically resolved by the update for existing webserver configurations. But if you reconfigure them, the new algorithms replace them with new syntax, and that resolves it for the existing configurations. So the issue itself has been resolved in the code, but that resolution is only applied after you reconfigure the configurations.

 

[learning_curve]

~~~
the web configurations troubleshooter itself is not working properly, so that is an additional bug.

FWIW Everything (including this ^) now works perfectly on all of our different servers / hosting setups / domains / subdomains / webail / configs etc etc

See the previous post by @Peter Debik

~~
The bug is not fully solved by the latest update.

See the previous post by @Peter Debik

~~
It is a bit of a mystery to me - any idea, somebody?

See the previous post by @Peter Debik

 

[TobiasP]

The "protocol options" issue is not automatically resolved by the update for existing webserver configurations. But if you reconfigure them, the new algorithms replace them with new syntax, and that resolves it for the existing configurations. So the issue itself has been resolved in the code, but that resolution is only applied after you reconfigure the configurations.

is there a way to repair the webmail config like there is the cmd for the vhost config:

plesk repair web domain.tld

?

 

[TobiasP]

thanks to @learning_curve for reminding me about the config troubleshooter, I used it to regenerate all the webmail configs.

 

[trialotto]

The "protocol options" issue is not automatically resolved by the update for existing webserver configurations. But if you reconfigure them, the new algorithms replace them with new syntax, and that resolves it for the existing configurations. So the issue itself has been resolved in the code, but that resolution is only applied after you reconfigure the configurations.

@Peter Debik

You are stating the obvious, but you are - apparently - not aware of the fact that "reconfiguration" is not a solid solution - it is a solution, not thé solution.

In essence, the "protocol options redefined" issue is associated with :

1 - a root cause of the problem : wrong Nginx templates - this issue has been solved,

2 - symptom 1 : nginx -t test gave error notifications - this issue has NOT been solved in ALL scenarios, only in MOST scenarios,

3 - symptom 2 : error notifications by email - this symptom is 100% related to symptom 1,

4 - symptom 3 : plesk repair utility not working properly - this symptom is very likely to be related to the Nginx templates AND another issue.


Let me give you some explanation, with an actual case.

I have run the plesk repair utility before and after the Nginx templates were adjusted for the "protocol options redefined" issue.

According to the theory, everything should be fine.

But it is not!


Running the command nginx -t returns

nginx: [warn] protocol options redefined for [ip]:443 in /etc/nginx/plesk.conf.d/webmails/example.com_webmail.conf:7
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful


Stated differently, after applying the micro update with the alleged fix for the "protocol options redefined" issue and running the plesk repair utility many times, there still is this output from nginx -t that indicates that the issue has not been solved for one specific subdomain.


Now, verifying the contents of the Nginx config file /etc/nginx/plesk.conf.d/webmails/example.com_webmail.conf returns

listen [ip]:443 ssl http2;

on the offending line 7.


Stated differently, the line 7 is correct and should not return an error notification when running nginx -t.


Running the plesk repair utility for the specific domain (or the entire server) does not make any difference.

Running the web configurations troubleshooter (via the Plesk GUI) does not make a difference either - it does not work properly in many ways.

Running a stop/start sequence of Nginx to force Nginx to flush memory and reload config, that does not work either.


So, yes, there is an issue that still is present and that has not been resolved by the micro updates of Plesk.

I am at a loss, since this kind of behavior is completely unexpected, totally not in line with Nginx behavior and it should not even occur, given the fact that the config is simply correct!


Kind regards.....

 

[TobiasP]

I can confirm after using the "Webserver Configurations Troubleshooter" and chose to "Rebuild"->"All" - nginx -t reports no more warning (or errors)