Recent content by ChristophRo

Nope, we run our own physical servers and virtual infrastructures Does the problem also happen when using the "OS" PHP version with Plesk? That would eliminate a possible influence of the php compiling process that Plesk uses for it's own shipped versions.

if not for PHP 7.4, I would have suspected that maybe the JiT compiler has some say in this...

already did that, checked syslog on multiple servers (with several thousand websites on it) and so far zero/zilch segfaults on what PHP versions does this happen for you? (we do use deb.sury.org for some, as to have older versions and also longer maintained ones, than from Plesk)

Our Debian 10, 11 and 12 servers do not show any problems with PHP and they are all on 18.0.61#1 Maybe an extension you have loaded and we don't? (we use the default set of plesk)

We've upgraded several servers to 18.0.61 Update #1 (Debian 10, 11 and 12) and so far the internal monitoring tool of Plesk still works on all of them. (we did not enable http3 anywhere)

1) your "proxy_pass http://0.0.0.0:5000" line needs a semicolon in the end 2) you are not allowed to use a "server_name xxx;" in a location {} block

You also need to disable the "Proxy mode" in the "Apache & nginx Settings" and I recommend to disable PHP for this subdomain as well.

Just askin, because we've already installed it on two servers... Something we need to be worried about or look after specifically?

Try using "127.0.0.1" instead of "localhost" had way to much trouble with MariaDB > 10.6 on Debian/Ubuntu lately when using "localhost" (something to do with socket based connections and the "%" wildcard for access restrictions in mariadb no longer covers "localhost")

I do not think that the Plesk Migrator extension does migrate DKIM keys... So all your domains on the new server will have a different key for the email signature than before. For domains with local DNS you can most likely just uncheck and then enable the DKIM checkbox again, in order to fix the...

To answer my own question, in the end it is quite simple. Adjusting the ext-plesk-sitejet-website_template_id value in the dom_param table of the psa database for the new site

For that you may need to convert .htaccess (rewrite) rules to nginx and add it to the nginx config in Plesk.

I assume this function to move/migrate a website is not yet published in the Sitejet extension? As least I don't see anything like that release notes.

most likely a postqueue -f would have helped to deliver them immediately once messages are stuck in the queue for a certain time, new delivery attempts for them only happen once every 1, 2, 4 hours or so. So it's normal that it may have taken quite some time to get these 150 mails out.

Already updated all our servers on the 3rd of April (as it finally fixed a Backup Telemetry extension problem for us) and so far no problems with it.