@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.......