Recent content by OGR

I am using aptitude for this. It wasn't able to provide a solution that doesn't completely remove Plesk.

The upgrade from Debian 11 to Debian 12 fails after the successful reboot at step 17 when using this guide: https://support.plesk.com/hc/en-us/articles/12377714344983-How-to-perform-dist-upgrade-procedure-on-Linux-server-with-Plesk plesk installer update --skip-cleanup The command fails with...

We will begin transitioning from machines on Debian 8 to new ones on Ubuntu 20.04. That rules out using dist-upgrade. With a ten year support cycle for Ubuntu 20 I believe that the ability to do a dist-upgrade clearly fades in importance. There's a very high probability that our next OS change...

@retsifp We also still use Debian 8 and have been waiting for Plesk to finally support Debian 10 since last year. I think this time we'll wait a little longer for the Ubuntu 20.04 LTS support (announced for late Q3 2020) and migrate away from Debian. Ubuntu LTS gets security support into 2030...

In our firm we have suspended mutiple server migrations from old to new hardware because of missing Debian 10 support from Plesk. Corresponding tasks are on hold for more than half a year. Debian 10 was released last July. Why is this taking so long? Is it because of actual problems with changes...

Sorry for returning so late to the topic. I checked out with a cold and just managed to get back to the topic just now. I cleaned everything up on the server, rebooted it and at some point it just started working. The only problem is that now I just can't figure out what fixed it. This now...

First of all, thanks for alle the help, even if nothing fixed it. In short: I had no error message for the MU23 update. I applied KB128398 anyway, which yielded no errors. After that, the problem persists. The ProxyPassMatch directive is working, the SetHandler directive is not. I restarted...

Intermediate solution: Adding the following to the "additional directives for HTTP(S)" under the "Apache & nginx" settings works: <IfModule mod_proxy_fcgi.c> ProxyPassMatch ^/(.*\.php(/.*)?)$...

This is proven false by the fact that putting the wrong path at the end of the line yields "file not found" in the browser while putting the correct path works. And even if putting somehting at the end isn't supposed to make any difference: Don't tell me that, tell it to the Plesk developers...

That doesn't work. The Plesk licenses are from "Plesk partners", and I am for sure not jumping through the hoops of contacting my german server provider in the faint hope that they will contact your developers. I encourage you to create the ticket for us and provide the developers with a link to...

The "ProxyPassMatch" line is from an earlier version of Plesk before MU23. This is the config that works. The "SetHandler proxy" line is the one created by the MU23 template which doesn't work. So I don't have to "change" the "SetHandler proxy" lines, but I need to comment them out (or I would...

Now I could extract the previous configuration style from another server and revert the configuration on the server that has MU23 installed. And guess what: That fixes it! + <IfModule mod_proxy_fcgi.c> + ProxyPassMatch ^/(.*\.php(/.*)?)$...

The remarks about the error messages only showing up in the log if no domain is configured to use the corresponding FPM handler are correct. Once you assign a domain to the handler, then the corresponding log file log looks okay: [25-Feb-2016 06:40:58] NOTICE: fpm is running, pid 10732...

Update: After looking at MU23, I think that the contents of "php_over_fpm.php" are responsible for this. On another server I am lucky that MU22 is the last one that was installed. I switched that server to not autmoatically install updates in the Plesk update settings in the hope that Plesk will...

Same problem here. This is on Ubuntu 14.04 and the pages were working fine. Then after I added a domain alias I guess the services were triggered with a reload and suddenly I get those downloads for all PHP pages (the source code is served). I can only guess that it was the MU23 that was...