Search results

Or you use update-alternatives to change what /etc/alternatives/php points to.

I'd let the VPS provider check the SSD.

Looks like a problem with IPv6.

That's not the mail tab Peter meant. Isn't there a "Manage in Customer Panel" link in the dashboard?

Logging in would produce even more log entries, so I'm not sure that would improve things.

Node.js Toolkit shows up under Extensions, no idea when it was (auto)installed. github doesn't.

I don't use Cloud Backup Pro. All of those backups use ftp(s) and have been set up some time ago, some even before the upgrade to Obsidian. These warnings showed up for two of the four webspaces on the server after Plesk auto-updated to 18.0.57 on Dec 20 for all scheduled backups running since...

Waaait. If you're in a chrooted environment, shouldn't /var/www/vhost/<domain> be the chroot jail and thus removed from the file path?

Do you retrieve all those feeds sequentially or in parallel? How do you do that anyway, do you use a WP plugin or is it something you programmed yourself? What I notice is that grafana uses a lot of CPU. Like, really a lot. Phusion Passenger Core too, what do you use that for?

So an ugly workaround would be to take a list of FQDNs Plesk uses, resolve IPs for those, and add them to /etc/hosts and the whitelist.

Before it was DMARC pass DKIM fail, though. @Alex Presland If you send from Outlook using an address on that server, are those headers wrapped too? (DKIM probably wouldn't fail in that case as the server generates the signature after mangling)

This is probably a vserver, so would this even work?

Did you configure Outlook first, or import first? Outlook misbehaves if the Sent folder doesn't already exist, so I make sure to open a new account with webmail, which will create the special folders, before configuring Outlook.

The problem with fpm is that the pools know nothing about each other and therefore you will get problems with oversubscribing when more than one pool gets considerable load.

The problem is that the default kernel might be too old for your CPU, so going back to an even older debian won't help. This would rather be a case for trying a kernel backported from debian 13.

That's probably because it wasn't installed from the focal repository but from the above mentioned autoinstall.plesk.com.

Might be the i9-13900 with its different core types not being fully supported by the debian 12 kernel yet.

What load is: The number of tasks that are currently waiting. Optimal load distribution is to have one task per (virtual) core waiting so no core will be waiting for something to do. If you have more tasks than that waiting, things are starting to lag. Now if you have tasks that are dead...

For access it wouldn't need id_rsa*, though. Only authorized_keys, if at all.

Have you tried just setting that CAA record? It's best practice anyway.