Resolved Error apache templates

[Erwan]

Hi all,

We have this error on one server:

New configuration files for the Apache web server were not created due to the errors in configuration templates: Syntax error on line 166 of /etc/httpd/conf/plesk.conf.d/vhosts/<domain.com>.conf: RewriteOptions: unknown option 'InheritBefore' . Detailed error descriptions were sent to you by email. Please resolve the issues and click here to generate broken configuration files once again or here to generate all configuration files.

In the email we have:

Unable to generate the web server configuration file on the host <server_domain> because of the following errors:
Template_Exception: Syntax error on line 192 of /etc/httpd/conf/plesk.conf.d/vhosts/<domainX.com>.conf:
RewriteOptions: unknown option 'InheritBefore'
file: /usr/local/psa/admin/plib/Template/Writer/Webserver/Abstract.php
line: 75
code: 0
Please resolve the errors in web server configuration templates and generate the file again.

But we check the file "/etc/httpd/conf/plesk.conf.d/vhosts/<domainX.com>.conf", we don't have any text: "InheritBefore".

How can we found the problem?

We have try to use:
# plesk repair web -y -v

Message:

- httpdmng failed: Execution failed.
Command: httpdmng
Arguments: Array
(
[0] => --reconfigure-domains
[1] =>
domain1.com, domain2.com...
)

Details: [2021-12-16 09:46:31.688] ERR [util_exec] proc_close()
failed ['/usr/local/psa/admin/bin/apache-config' '-t'] with
exit code [1]
[2021-12-16 09:46:38.893] ERR [panel] Apache config
(16396443710.82226600) generation failed: Template_Exception:
Syntax error on line 196 of
/etc/httpd/conf/plesk.conf.d/vhosts/<domain.com>.conf:
RewriteOptions: unknown option 'InheritBefore'

Not a good idea also, because the server certificate has been assigned to all clients (instead of their certificate). We had to regenerate them one by one ...

An idea how to correct the problem?
Thank you.

 

[IgorG]

The reported behaviour is a bug in WordPress Toolkit extension #EXTWPTOOLK-8572

This bug appears only on outdated RHEL-based OSes, like CentOS 6 with Apache version 2.2 or less. WordPress Toolkit has several options that add the directive InheritBefore in the web configuration. This directive is supported in Apache 2.3.10 and above.

Thus, I would strongly recommend migrating to a newer OS using our Plesk Migration and Transfer Guide.

You can use the following workaround:

1. Download attached apache.php file
   

   # wget https://plesk.zendesk.com/hc/article_attachments/4412664653586/apache.php

2. Rename /usr/local/psa/admin/plib/modules/wp-toolkit/resources/webconfigs/apache.php file:
   

   # mv /usr/local/psa/admin/plib/modules/wp-toolkit/resources/webconfigs/apache.php /usr/local/psa/admin/plib/modules/wp-toolkit/resources/webconfigs/apache.php_orig_58

3. Copy downloaded apache.php to /usr/local/psa/admin/plib/modules/wp-toolkit/resources/webconfigs/ directory:
   

   # cp apache.php /usr/local/psa/admin/plib/modules/wp-toolkit/resources/webconfigs/apache.php

4. Reconfigure affected domains:
   

   # plesk repair web example.com -y

   To reconfigure all domains on the server:
   

   # plesk repair web -y

 

[Erwan]

Hi Igor,

Thank you for the information.

Thus, I would strongly recommend migrating to a newer OS

Yes, it's planned but not right away.

But with this commande:

# wget https://plesk.zendesk.com/hc/article_attachments/4412664653586/apache.php

We have a 404 not found...

 

[IgorG]

We have a 404 not found...

Attached.

 

[Erwan]

Perfect. Thank you Igor.

 

[maybeso]

had the same problem - and yes older os that we need to update
The instructions given restored the server websites to working - but all email was still getting stuck in the mail queue
status=deferred (connect to 127.0.0.1[127.0.0.1]:10024: Connection refused)

looking for solutions - and everything pointed to restarting amavisd and amavis - neither of which were running but they are part of the plesk email security extension

so I uninstalled the plesk email security extension and email is working again

 

[IgorG]

but all email was still getting stuck in the mail queue
status=deferred (connect to 127.0.0.1[127.0.0.1]:10024: Connection refused)

looking for solutions - and everything pointed to restarting amavisd and amavis - neither of which were running but they are part of the plesk email security extension

so I uninstalled the plesk email security extension and email is working again

Please open a separate thread about this problem. It is not related to the initial issue. This thread is marked as Resolved.

 

[imhostingyou]

Whew. Thank you so much Igor. You saved my a** today. Cheers!

 

[rhall]

Thank you thank you thank you IgorG!

I am still running a Centos 6.10 box with Plesk Obsidian 18.0.31 - that I have been meaning to migrate to Ubuntu - and last Saturday afternoon this bug hit me - and I worked from 4pm till 6am fixing this manually just knowing when the config was regenerated that the template would re-introduce the InheritBefore directive breaking things. Of course this afternoon something triggered it again and killed about 10 domains and dozens of aliases. I did a quick check and found this today - so thank you! I was so close to installing an unsupported build of Apache 2.4 for Centos 6.10 to work around it, but was really wary of what that might have introduced and made things worse - hah!

I had also been really worried that I had gotten hit by a Log4JS attack and was investigating EVRYTHING I could think of, but couldn't find any signs of intrusion or changes so figure it was a bug. FWIW - I used this hand shell script: GitHub - rubo77/log4j_checker_beta: a fast check, if your server could be vulnerable to CVE-2021-44228 to do a cursory check for Log4JS - and it did actually flag some leftover binaries from a much older version of Plesk 12 for the web based SSH terminal:
/usr/local/psa/admin/htdocs/sshterm/commons-logging.jar contains log4j files
/usr/local/psa/admin/htdocs/sshterm/SSHTermApplet-signed.jar contains log4j files

I didn't bother to unzip that jars and manually inspect, but I did end up scanning them with this tool: GitHub - mergebase/log4j-detector: Scanner that detects vulnerable Log4J versions (CVE-2021-44228, CVE-2021-45046, etc) on your file-system within any application. It is able to even find instances that are hidden several layers deep. Works on Linux, Windows, and Mac, and everywhere else Java runs, too!

And it looks like they are old enough to not be affected by CVE-2021-44228 or CVE-2021-45046 - thank goodness!

In any case, hope that extra info helps, and thank you again for the patch to fix this! I can sleep and rest again!