Search results

Does this happen when registry.xml grows too big? It was 65768 bytes here (just over 64KB), and after removing and retrieving it has just 950 bytes.

We proxy through nginx for a reason. Apache in general is slower than nginx, so attacking apache directly puts more load on the server. Best practice is that attack surface should be minimized. Services that don't need to listen on a public IP shouldn't. Apache might have different...

Do you have the Plesk firewall active? It is not enabled by default. And apache2 itself binds to any IP as visible with netstat, while in /etc/apache2/plesk.conf.d/ip_default or vhosts the domains are bound to the IPs, which is completely unnecessary for domains cached by nginx. If no domain is...

I usually use grep "SASL LOGIN authentication failed" /var/log/mail.info |cut -f 5 -d ":"|sort|uniq -dc and null-route the more obnoxious ones with route add -net 194.55.224.0/24 lo if there are several in the same net or route add -host 195.133.40.157 lo for single hosts.

And ssh from a shell on the target server works too?

Okay, I think I know what happened: Starting with the upgrade to 18.0.49, plesk explicitly pins the pgp key for the plesk repositories: add line 'deb [signed-by=/etc/apt/keyrings/plesk.gpg] http://autoinstall.plesk.com/pool/PSA_18.0.49_10759/ bullseye all' to temporary source list...

Does the request even reach apache or does the pagespeed module in nginx deliver this?

well, taking that literally, I'd remove support for unencrypted POP3/IMAP and keep POP3S/IMAPS. Sending passwords over unencrypted connections is a huge security risk anyway, so the insurance companies aren't exactly wrong about this, they just could have worded that better ...

And btw, plesk still doesn't show dist-upgrades. /admin/pum/updates-list says All packages are up-to-date Checked on Mar 30, 2023 10:47 AM but apt-get upgrade says The following packages have been kept back: linux-image-amd64

Well, it doesn't. It supports x86_64. There seems to be some confusion about arch vs. os_arch. This is not a debian key issue however, but a plesk pgp key issue, as all the repositories involved are plesk's. Maybe a leftover from the botched grafana key update? It seems plesk itself messed...

This is a problem with mxtoolbox. They expect mail to be on a subdomain even though there is nothing in the relevant RFCs that would support such an requirement.

Just curious, what are you expecting to access at https://mail.example.com/?

Putting the relevant name(s) like webmail.domainA.com into the client's /etc/hosts or %WINDIR%\System32\drivers\etc\hosts works too.

Could it be that you have an automatic backup configured on the target that started during the migration?

Same here. Plesk seems to have updated normally at 6:35 as usual, but a manual Recheck now resulted in "The System Updates tool is already installing updates in automatic mode. Please try later." which is at least misleading. apt-get update shows a message similar to OP's but with the 1298 on...

I thought it uses rsync?

Clients will refuse to connect to imaps or pop3s when the certificate does not match or doesn't even exist, and you shouldn't ever connect without SSL because your password WILL be stolen that way.

If you don't have domain.tld on the plesk server (and you can't use workarounds like using sshfs to mount .well-known on the webserver), you'd have to create webmail.domain.tld as a domain in plesk to get it to set up Let's Encrypt. But that has all kinds of other problems ... The easiest way is...

How?

Well they would try to access subpages under that default page which do not exist, and get a 403. I have no idea why HEAD on / throws a 405, though. No, the HTTP protocol version is independent from SSL.