Issue All Domains Apache2/Error 500

[Monty]

FYI: Canonical has released new apache2 packages some minutes ago which fix the regression:
Change log : apache2 package : Ubuntu

Bugreport: Bug #1945311 “Fix for CVE-2021-40438 breaks existing configs” : Bugs : apache2 package : Ubuntu

 

[trialotto]

FYI: Canonical has released new apache2 packages some minutes ago which fix the regression:
Change log : apache2 package : Ubuntu

Bugreport: Bug #1945311 “Fix for CVE-2021-40438 breaks existing configs” : Bugs : apache2 package : Ubuntu

@Monty

Thanks for the very valuable tip.

And now it becomes interesting

The bug fix update to be released by Plesk Team ..... or the patch with the PPA package mentioned often in this thread (or uninstalling that PPA) ....... or the workaround presented in the first KB article (or the undoing of that) ........ or the "solution" presented in the second KB article (or the undoing of that).

I really wish that there is some uniform approach here....... it is a severe issue if all sites go dark at once.

By the way, did you test the Canonical patched packages already? And if yes, is it without any issue (also when previous work-arounds have been applied)?

I hope that you can give some additional good news.

Kind regards ..........

 

[mow]

The bug fix update to be released by Plesk Team ..... or the patch with the PPA package mentioned often in this thread (or uninstalling that PPA) ....... or the workaround presented in the first KB article (or the undoing of that) ........ or the "solution" presented in the second KB article (or the undoing of that).

The first KB workaround was reverting to an older version of apache. This would need to be undone so you get current and fixed versions of apache again.

The second was a new template that replaces the unix:/// urls with unix:/ urls, which all relevant versions of apache accept, therefore it does not need to be removed.

The new patched version of apache has just a minor change of allowing unix:/// urls again.

 

[Monty]

@trialotto Nope, I haven't tested it myself as I don't run Ubuntu.

Regarding the "best" solution:

• If you downgraded your apache2 package, I suggest you do a test on one box by doing "apt-mark unhold apache2" followed by "apt update && apt upgrade". If this works then it should safe to update all your other boxes. You may want to wait 1-2 days before doing this, just to make sure.
• If you applied the Hotfix from Plesk (new PhysicalHosting.php file) then you can keep that file. It will be overwritten by the next Plesk update anyway.

 

[trialotto]

The first KB workaround was reverting to an older version of apache. This would need to be undone so you get current and fixed versions of apache again.

The second was a new template that replaces the unix:/// urls with unix:/ urls, which all relevant versions of apache accept, therefore it does not need to be removed.

The new patched version of apache has just a minor change of allowing unix:/// urls again.

@mow

It is good that you write it down like that - forum members can see the differences in the various approaches and decide what to do.

I have tested all approaches mentioned and chose to apply the work-around of reverting to an old Apache version, based upon the idea that it should only be a temporary fix : a Plesk or Canonical update was to be expected within a short period ....... and implementing that update is always the best solution.

However, it should be duly noted that the "new template" approach has some pittfalls, since you have to rebuild webserver config files - that is not always the best solution, for instance when customization (on the Apache or even the Nginx level) is required.

I did not test the new Canonical patch yet, but that should do the trick.

I am not so sure whether the "template" patch allows for an easy and worry free update to the lateste Apache releases by Canonical.

Did you test that?

Kind regards....

 

[trialotto]

@trialotto Nope, I haven't tested it myself as I don't run Ubuntu.

Regarding the "best" solution:

• If you downgraded your apache2 package, I suggest you do a test on one box by doing "apt-mark unhold apache2" followed by "apt update && apt upgrade". If this works then it should safe to update all your other boxes. You may want to wait 1-2 days before doing this, just to make sure.
• If you applied the Hotfix from Plesk (new PhysicalHosting.php file) then you can keep that file. It will be overwritten by the next Plesk update anyway.

@Monty

I am not sure whether the Plesk update is required, if the Canonical patches are present.

It is a big mess, with various work-arounds required to keep websites running ......... followed by various patches (bug fix solutions) that might not be compatible with applied work-arounds.

That is why I am posting here and there : it is good to exchange some information .........

Kind regards.....

 

[Monty]

@mow
However, it should be duly noted that the "new template" approach has some pittfalls, since you have to rebuild webserver config files - that is not always the best solution, for instance when customization (on the Apache or even the Nginx level) is required.

@trialotto Just a small comment: Rebuilding your webserver configuration should _never_ break your customizations if the customizations were done correctly. In theory you should be able to rebuild your configuration any day without breaking anything.

 

[Monty]

@Monty

I am not sure whether the Plesk update is required, if the Canonical patches are present.

It is a big mess, with various work-arounds required to keep websites running ......... followed by various patches (bug fix solutions) that might not be compatible with applied work-arounds.

That is why I am posting here and there : it is good to exchange some information .........

Kind regards.....

Well, it started as a raging wildfire so the workarounds/solutions were published in order of their complexity: The easiest solution (downgrade Apache) was published first. In the meantime the Plesk team has worked on a Hotfix that can be applied without modifying the OS configuration (new template file).

And now, Canonical has finally published their "official" fix for the problem that will make the previous 2 workarounds obsolete.

So not really a "big mess" in my opinion, it's rather like watching different engineers finding solutions in real-time. IMHO this whole story showed us how quick and flexible the whole community (Plesk, users, Canonical) is.

 

[mow]

@trialotto Just a small comment: Rebuilding your webserver configuration should _never_ break your customizations if the customizations were done correctly. In theory you should be able to rebuild your configuration any day without breaking anything.

It can break things if you changed the configuration directly, but then, when you did that, you should know what you are doing anyway and wouldn't have any problem changing the unix:/// to unix:/ where needed.

 

[Linnl71]

Yes, had this automatic update on our server lastnight, killed 80 websites instantly...

Ran these commands to update to Apache 2.4.49 (Which has fixed the problem for me) - for anyone who isn't tech savvy.

sudo add-apt-repository ppa:ondrej/apache2
sudo apt install apache2

I've done this - which solved the issue. I'm a typical non-tech person and applied the easiest solution, which I think this is.

I hope Plesk will update the KB once they're done with the fix, and to guide what actions to take based on the various "work-arounds" that have been applied.

 

[Neotop]

this worked for us, several hundred websites knocked over instantly with this update

The pages are loaded but both web hosting options in Plesk have errors

 

[trialotto]

@mow and @Monty,

@trialotto Just a small comment: Rebuilding your webserver configuration should _never_ break your customizations if the customizations were done correctly. In theory you should be able to rebuild your configuration any day without breaking anything.

It can break things if you changed the configuration directly, but then, when you did that, you should know what you are doing anyway and wouldn't have any problem changing the unix:/// to unix:/ where needed.

These quotes are right ........ but you are also aware of the fact that Plesk allows for custom templates.

In the Plesk structure, these custom templates are used first ..... and then the default templates are used - that is a very rough outline of what happens.

The customization thing here is an "onion" : peeling layers of config, the config is being read in a specific order.

This is also (potentially) causing issues when changing config : the customization in the custom directory has to be in line with the remainder of default config that is applied in absence of custom config ....... and custom config is hence able to break config, even when not altering the default config templates.

Moreover, rebuilding (web) config templates does not touch the custom templates .... meaning that a config rebuild is often not a great solution, if custom config is in place.

Nevertheless, it does not really matter for the current situation at hand.

I am a bit surprised though .......... it should have been possible to work-around the Apache issues with a safe custom config that only has to be removed when the to be expected patch from Canonical would have arrived.

If I am not mistaken, Plesk used one work-around in which the default config was altered........ so hence the surprise.

As for me, it is all fine ........ in this worst-case-scenario-of-sites-going-white-screen, all means are allowed to solve the issues.

Kind regards.......

 

[trialotto]

Well, it started as a raging wildfire so the workarounds/solutions were published in order of their complexity: The easiest solution (downgrade Apache) was published first. In the meantime the Plesk team has worked on a Hotfix that can be applied without modifying the OS configuration (new template file).

And now, Canonical has finally published their "official" fix for the problem that will make the previous 2 workarounds obsolete.

So not really a "big mess" in my opinion, it's rather like watching different engineers finding solutions in real-time. IMHO this whole story showed us how quick and flexible the whole community (Plesk, users, Canonical) is.

@Monty,

The thing here is that multiple parties tried to solve one issue, with all solutions being viewed from the specific perspective that each party had.

It is not messy that a lot of parties suddenly find solutions, that is true.

It is messy that one has to pick and choose between a number of work-arounds (not solutions) first, then some partial solutions (like the Apache update by Canonical) and then has to wait for the formal update release by Plesk ......... even though there is no time to spare, when sites go down.

Personally, I have found 3 "work-arounds" within 1.5 hours after the update was executed and I decided not to implement them, since there simply was an update from Canonical (or Plesk) to arrive sooner or later - more important, the "broken" Apache update was security related, so it was imperative to wait for the bug fix by Canonical, at least that was my opinion.

Nevertheless, we will just wait and see what happens........ it is nice to see that so many people are pro-active on this topic.

Kind regards.........

 

[mow]

If I am not mistaken, Plesk used one work-around in which the default config was altered........ so hence the surprise.

It uses a workaround which works with all involved apache versions and does not need to be removed.

The apache update is the full solution, btw. plesk does not deliver apache. They do deliver php, though. So if php breaks in an apache update you would have a point complaining to plesk, but not if an apache update delivered by your distribution (ubuntu) breaks everything.

 

[Andrea Bampi]

I was affected by this issue too and solved by switching to FastCGI instead of FPM...
I just have a quick question (I'm NOT a Plesk guru, I'm just a developer forced to manage some servers, too) - WHY did this update apply automatically on my server, considering I've disabled ALL updates, at least AFAIK?? Was it possibile to avoid this update in any way?
...btw the new fix (3.6) was automatically applied too ... any advice about how to completely disable all system updates from a Plesk-based server??

 

[mow]

I just have a quick question (I'm NOT a Plesk guru, I'm just a developer forced to manage some servers, too) - WHY did this update apply automatically on my server, considering I've disabled ALL updates, at least AFAIK?? Was it possibile to avoid this update in any way?
...btw the new fix (3.6) was automatically applied too ... any advice about how to completely disable all system updates from a Plesk-based server??

ubuntu has its own update mechanism which installs security updates automatically at night by default. The apache update fixes several CVEs, so it was obviously qualified as security update.

 

[Andrea Bampi]

ubuntu has its own update mechanism which installs security updates automatically at night by default. The apache update fixes several CVEs, so it was obviously qualified as security update.

Thanks... this confirms my "fears". Now I'm puzzled about completely disabling all security updates too - I know it's clearly not recommended, but it's unacceptable to lose an entire server overnight like that

 

[kama]

Hi, I ran the command

# apt-mark hold apache2
export version="2.4.41-4ubuntu3"; apt-get install apache2=$version apache2-utils=$version apache2-data=$version apache2-bin=$version

solving the error on Ubuntu 20.04.3 LTS

Now in the updates I have the following package

apache2-doc 2.4.41-4ubuntu3.5 (now)

Apache HTTP Server (on-site documentation)

Aggiorna a 2.4.41-4ubuntu3.6 (Ubuntu for focal-updates by Ubuntu)

question is: it safe to install this update or should I wait?

Thanks.

 

[Monty]

@kama Yes, it should be safe. The 2.4.41-4 release contains the bugfix for the UDS URIs, see: 2.4.41-4ubuntu3.6 : apache2 package : Ubuntu

 

[Akrolis]

Hi, I'm runnging Plesk Obsidian 18.0.38 Update 2 on Debian 9.13 and the following updates are available:
apache2 2.4.25-3+deb9u11
apache2-bin 2.4.25-3+deb9u11
apache2-data 2.4.25-3+deb9u11
apache2-utils 2.4.25-3+deb9u11

Is it safe to update or should I wait?