Search results

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.

They wrote they have the backups on the server. Are they in /var/lib/psa/dumps/ on CentOS 7 too?

JFTR: Not necessarily. We had an email abuse incident when one of our users didn't have their mail client set to SSL only (shame on outlook for not having that as default). Some WLAN AP must have stolen the unencrypted login data.

However, nginx is rather fast doing that. Also keep in mind that a bot might retry if it doesn't get a 4xx error. This would really be a lot easier if plesk had a way to easily integrate varnish. We moved our main site to another server without plesk just so we could add varnish to our site and...

What does the log say?

Are you sure this will help? IMHO limiting the database server memory will only ensure that it definitely fails, which is not really helpful.

Keep in mind that proxying does not change the request. Which means, what 192.168.1.2 sees is still GET https://test.com/test.

How did you set that up? location blocks with proxy_pass?

Maybe for variables that can be set from the mariadb cli. Everything that would require a restart of the db server would have a risk of prolonged downtime for a rather small benefit.

The read access time on a hash table grows sublinear with size, but still grows. Write access - to insert new values - is significantly worse. Especially when you have many workers, which you do when every site connects to the same redis. And you usually want persistence for the session cache...

Do I see that right that you have just one redis? You should have a separate redis for each dataset. Especially if the cache is persistent, as redis will block while the cache is saved to disk.

After a plesk user is created by the mail setup, it shows up in "Users" on the left side. You would delete the plesk user there.

Could you try to send a mail to a domain that is on the relaying server? In that case, it would have to check DKIM, and it'd be very interesting how that turns out.

An extra Received: is normal. Are you sure that's everything that's changed? Any encoding issues, CR/LF conversions? Are you sure it doesn't replace the signature? Do the postfix logs say anything about DKIM? By the way, your plesk is ancient and it seems you don't have reverse DNS properly...

plesk does not change the way your linux distribution configures ip addresses, so you'd really need to look up your distribution's networking documentation.

What IP does google report, then? Does it belong to your vserver provider? Does your provider force smtp connections through a proxy?