Search results

But you accessed the nginx port (80 or 443), not the port apache runs on, so the deny/allow settings don't even apply to your connection.

Since a while, apache binds to localhost by default. This is not automatically updated, but a new install will do that, and a restore won't change back to the old setting.

Yes, but there also is a limit to the amount of enshittification we will tolerate.

okay, that's even more bugs then. The additional restart was enough to fix our Taubenkot.

I'd guess that's what saved you: another restart after all the changes were really done. Relevant part of autoinstaller3.log: Setting up plesk-dovecot (2.4.1-4-v.debian.11+p18.0.73.3+t251009.1752) ... Installing new version of config file /etc/dovecot/conf.d/10-plesk-security.conf ...

I have no other idea how the error message could reference file contents that don't exist anymore, though. The file timestamp 03:18:20 exactly matches the error message.

It seems that during the upgrade, Plesk restarts dovecot before updating all the config files, which is bound to fail. Rookie mistake. Makes one wonder whether there are any experienced developers left at Plesk.

YOU GET PAID FOR DOING THAT. Today I got woken up by a phone call, while sick at home, that email doesn't work. Logged in and found: Nov 03 03:18:20 sourcetronic.com systemd[1]: Starting Dovecot IMAP/POP3 email server... Nov 03 03:18:20 sourcetronic.com dovecot[1780787]: doveconf: Fatal: Error...

And maybe change the time, or that poor server will be DDoSed by all the plesk installations ...

That's just a Notice. Error would start with E:, as above. Do you have immunify360 installed?

Since I changed the IP to 85.10.234.30, I didn't get any further errors.

The server is at hetzner's datacenter in Falkenstein, Germany. The working drweb server 85.10.234.30 is in hetzner's datacenter in Nuremberg. I don't think increasing the log level will be of much help since 103 is a connection issue where the connection already fails at the TCP level - some of...

Unfortunately it didn't for me - but now I got return code 103 which, according to /opt/drweb/update.pl, is EXIT_STATUS_CONNECT_ERROR => 103, Worse is that I keep getting this error even now running /etc/cron.daily/drweb-update manually. Update: I checked all the round-robin IPs of...

You're looking in the wrong place. cron has two ways to start things: The per-user crontab and the system-wide /etc/crontab, which in turn runs the scripts in /etc/cron.hourly, daily, weekly and monthly. At the start of the line for cron.daily, I changed 25 6 to 40 5 for 5:40. Please do not use...

Try tcpdump port 443 and net 173.0 while PayPal is supposed to connect. If that doesn't output anything, you know that the packets don't even reach your server, and you should ask Strato.

Randomizing the update time should sort it out too. Mass changing to another server will only perform what essentially looks like a DDoS on that other server. If Plesk wants to keep using a fixed update time, Plesk should take care of proxy-caching the files on their own servers.

Why? A certificate is simply invalid outside its specified validity interval. If you renew a certificate, the old one isn't explicitly revoked, it simply runs out. This might be true if you only see the certificate as a way to, together with PFS, encrypt communication so that not just anyone...

That's not what I heard. What I understand how it went like (see also OCSP stapling - Wikipedia): Early SSL-supporting browsers only checked the certificate chain. Checking the certificate status requires extra data. If the browser connects somewhere to check the validity, in this case the CA's...

Isn't OCSP Stapling explicitly designed to prevent the CA gathering user information, which it would get if each browser would have to connect some revocation database on their own instead of the webserver doing it for them and deliver the recent revocation status stapled to the certificate, so...

But you don't have the package php7.4-cli installed? That's the one plesk wants to run in that script because it thinks it is there as there obviously is an /etc/php/7.4 in your system, otherwise it wouldn't try to run that part.