Recent content by mow

"Pricing is based on users and query volume," so if your key leaks I guess that key's query volume and therefore the price goes through the roof ...

In /etc/systemd/system.conf, the default is given as #DefaultLimitNOFILE=1024:524288. Increasing the limit there followed by a systemctl daemon-reload works, but the overrides don't do anything, in either direction. Must be expected somewhere else.

With the systemd approach, you have to redo it for a new version of php. With the limits.conf approach, you have to redo it for each new domain user.

No, this is not enough, because it is not nginx which is hitting the limit but the php process, which runs as the domain user. Sou you have to raise the limits for all those domain users.

Plesk doesn't restrict pop/imap. But Thunderbird does not support the same account twice in the same profile. (Most clients don't.) Solution for Thunderbird: Add a second profile for archival purposes with pop3.

cloudflare's challenge will also block legitimate users who don't have the most recent browser version installed or who block third-party scripts. Also, randomly API requests are blocked. And that's not counting the cases where cloudflare itself fails massively.

This is configured in the systemd unit file.

Are those all from different networks or just a few rogue providers? E.g. when I run grep "SASL LOGIN authentication failed" /var/log/mail.info |cut -f 5 -d ":"|sort|uniq -c, I get ... 8580 unknown[158.94.210.39] 177 unknown[158.94.210.86] ... for which I block the whole net...

@King555 Because POST parsing is where the vulnerabilities usually are.

... while explicitly stating that you are invoicing the undisputed part of the current price, but still uphold claim to the rest. If the client already does continue to pay the old price, just send a payment reminder instead.

Add to .htaccess: <Limit POST> Order Deny,Allow Deny from all Allow from <your IP addresses> </Limit>

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.