Issue Plesk 18.0.81 Update #7 breaks AJP connectors for some applications

[Fede Marsell]

Server operating system version

AlmaLinux release 8.10

Plesk version and microupdate number

18.0.81 Update #7

Hello,

After updating to Plesk Obsidian 18.0.81 Update #7, some applications using AJP connectors stopped working, with Apache logging the following error:

proxy_lock: refused proxy backend ajp://localhost:XXXX

After investigating the issue, we identified the newly installed Apache module mod_proxy_lock (plesk-mod_proxy_lock) as the cause.

Disabling the module by renaming /etc/httpd/conf.d/proxy_lock.conf and restarting Apache immediately restores normal operation of all affected applications.

This module does not appear to be part of standard Apache, but rather a Plesk-specific customization.

We would like to clarify the following:

1. What exactly does mod_proxy_lock do, and what is its intended purpose?
2. Why does it block connections to local AJP backends configured through standard Apache ProxyPass directives?
3. Is this behavior intentional or a regression introduced in Update #7?
4. Is there a way to allow legitimate AJP connections without disabling the module?
5. What are the security or operational implications of leaving this module disabled?

Our environment runs AlmaLinux 8.X with Apache 2.4 and multiple applications using AJP connectors.

We would appreciate clarification, as this update has disrupted previously working applications, and we need to determine whether disabling mod_proxy_lock is a safe workaround or whether an official fix is planned.

Best regards,

Fede

 

[Oscare09]

Hi,

Thanks for flagging this. We'd suggest digging deeper into mod_proxy_lock, especially how it behaves with Apache AJP connectors after Plesk Obsidian 18.0.81 Update #7. Check the module's config and how it actually runs, so you can pin down what's causing it.

 

[Fede Marsell]

Hi,

After further investigation, we have identified the cause of the issue.

Plesk 18.0.81 Update #7 introduces the Apache module mod_proxy_lock, which appears to restrict proxy connections to a specific Unix socket.

The module causes previously working AJP connections to fail with the following error:

proxy_lock: refused proxy backend ajp://localhost:XXXX

Disabling mod_proxy_lock immediately restores normal operation, confirming that the module is responsible.

We understand that this module may have been introduced as a security measure. However, legitimate AJP connections should remain supported, particularly when configured to connect to a specific IP address and port using standard Apache ProxyPass directives (e.g., ajp://127.0.0.1:XXXX). Administrators should be able to explicitly define and authorize these trusted AJP destinations without having to disable the security module entirely.

We believe this limitation should be addressed, particularly as it introduces a breaking change to existing Apache configurations.

Regards,

Fede

 

[mizar]

Hello,

Sorry, but I cannot provide details about the security now, so anwering only on couple of questions:

> 1. What exactly does mod_proxy_lock do, and what is its intended purpose?

It restricts connections for paricular domain only to specified unix/tcp sockets.

> Is this behavior intentional or a regression introduced in Update #7?

This behaivor is intentional.

> Is there a way to allow legitimate AJP connections without disabling the module?

Configure:
<IfModule mod_proxy_lock.c>
ProxyLockSocket "ajp://127.0.0.1:XXXX"
</IfModule>

Disabling the module will effectively remove the checks.

 

[Fede Marsell]

Hello,

Sorry, but I cannot provide details about the security now, so anwering only on couple of questions:

> 1. What exactly does mod_proxy_lock do, and what is its intended purpose?

It restricts connections for paricular domain only to specified unix/tcp sockets.

> Is this behavior intentional or a regression introduced in Update #7?

This behaivor is intentional.

> Is there a way to allow legitimate AJP connections without disabling the module?

Configure:
<IfModule mod_proxy_lock.c>
ProxyLockSocket "ajp://127.0.0.1:XXXX"
</IfModule>

Disabling the module will effectively remove the checks.

Thank you @mizar for the clarification.

One question: Plesk already generates a ProxyLockSocket directive for the domain's PHP-FPM Unix socket.

Can we add a second ProxyLockSocket directive for an AJP backend within the same virtual host, using custom Apache directives?

Will both destinations be allowed, or will the second directive override the first one?

We need to ensure that authorizing an AJP backend does not interfere with the existing PHP-FPM configuration.

Regards,

Fede

 

[tessa67]

Hi @Fede Marsell,

I looked around for you, but I couldn't find any documentation or release note entry for mod_proxy_lock, so I can't tell you for sure whether a second ProxyLockSocket line is added to the first one or replaces it. Nobody has published that yet as far as I can see. The good news is that you can find out in a few minutes, without risking the PHP side.

1. First, check what Plesk generated for the domain (replace DOMAIN with your domain name):

grep -rn "ProxyLockSocket" /var/www/vhosts/system/DOMAIN/conf/

Note down the exact line for the PHP-FPM socket.

2. Under Domains > your domain > Apache & nginx Settings > Additional Apache directives, add mizar's block for the AJP backend (HTTP and HTTPS fields, if the app is used on both):

<IfModule mod_proxy_lock.c>
ProxyLockSocket "ajp://127.0.0.1:XXXX"
</IfModule>

I'd use exactly the same host and port as in your ProxyPass line. Your error message says "localhost", so if 127.0.0.1 doesn't work for you, try "ajp://localhost:XXXX" instead.

3. After saving, repeat the grep from step 1 and check that Apache is happy:

grep -rn "ProxyLockSocket" /var/www/vhosts/system/DOMAIN/conf/
httpd -t

4. Now open one PHP page and one page that uses the AJP backend, then look at the log:

grep "proxy_lock" /var/www/vhosts/system/DOMAIN/logs/error_log | tail

How to read the result:
- Both pages work and there is no new "refused" line: both destinations are allowed, you're done.
- AJP works but PHP breaks: the second line replaced the first one. In that case please post the output of step 3, and we can look at the next option together.
- AJP still fails: please post the exact line from the error log, so we can see which address it complains about.

If something goes wrong, just remove the block again in Plesk and save, and you're back to the state before. Renaming proxy_lock.conf, as you did, remains the temporary fallback. mizar mentioned that this removes the checks completely, so I would only keep it that way until this is sorted out.

Since this changes the behavior of existing setups, it's also worth reporting to Plesk support, so the multi-socket case gets documented.

Hope this helps!

Regards
Tessa

 

[Bitpalast]

@mizar
Would it perhaps be advisable to automatically reload or restart the Apache service after installing an update?

At least on AlmaLinux, I have installed several updates, but none of them appears to have triggered a reload of the updated Apache configuration.

Especially when an update includes security-related changes, I believe it would be beneficial to ensure that these changes take effect immediately.

It might therefore be worth considering either an automatic Apache configuration reload whenever an update modifies the relevant configuration files or, alternatively, including a clear note in the release notes advising administrators to reload or restart Apache manually after installing the update.

This would help ensure that important security improvements are actually applied and that administrators are aware of any additional steps required.

Thank you very much for considering this suggestion and for your continued efforts to improve the software!

 

[tessa67]

Hi @Bitpalast,

I think that's a really good suggestion. A security fix only helps once it's actually active, and right now an admin has no easy way to know whether that's already the case after an update. Even a short line in the release notes would take away a lot of that uncertainty.

I'd support an automatic Apache reload too, with one condition: Plesk would have to make sure that Apache doesn't end up offline if the new configuration has a problem. I've run into exactly that myself more than once, where a reload or restart with a broken config left the web server down. So ideally the configuration is checked first, and the reload only happens if that check passes. If it fails, the old config should stay active and the admin should get a clear message.

That said, I'm only speaking from my own experience here. @mizar will know much better what Plesk already does after an update and what would be possible.

Thanks for bringing it up!

Regards
Tessa

 

[Bitpalast]

I would also like to add that I am extremely pleased with the way configuration file updates are handled here. In particular, I very much appreciate that the existing configuration files are not removed all at once, nor are their symbolic links deleted, as is unfortunately the case with plesk repair web.

This has been a significant issue with plesk repair web for quite some time, especially on servers hosting a large number of domains. For example, on a server with around 1,000 domains, the web server configuration files can effectively be missing for 20 to 30 minutes while the repair process is running.

The approach taken here is a considerable improvement. The configuration files remain in place throughout the update process, ensuring that there is essentially no point at which they are missing.

I genuinely appreciate this thoughtful implementation. It is a much more elegant and reliable solution, particularly for administrators managing large hosting environments. Thank you for getting this right!

 

[mizar]

> Can we add a second ProxyLockSocket directive for an AJP backend within the same virtual host, using custom Apache directives?

Yes, you can, and it will override previous one (that's how apache directives works). Also the directive can be defined in the directory scope, which allow different sockets for different locations.