Recent content by D3nnis3n

Hello, I actually have this issue ever since we changed over to SSLit!, the domains using normal .acme folder verification do correctly renew automatically, all domains that use wildcard certificates and do DNS check do not. I always get this mail: Could not secure domains of xxx (login xxx)...

I set the 8.1 handler anyway, not knowing where the variable above comes from, Roundcube is now successfully using PHP 8.1, but I still can't remove PHP 8,0 without removing roundcube, sigh.

I found this article, but the files don't look like they do there: https://support.plesk.com/hc/en-us/articles/213367729-How-to-change-PHP-version-for-webmail-in-Plesk-for-Linux I instead have this: FcgidInitialEnv PP_CUSTOM_PHP_CGI_INDEX "<?php echo $roundcubePhpHandler; ?>" and the...

Plesk is refusing to allow me to remove PHP 8.0 without uninstalling Roundcube. But Roundcube is delivered with Plesk in Version 1.6, which does support PHP 8.1 which is available by OS vendor. Any way I can get around this?

Multiple times tried to restore a plesk backup of one domain today, always got a success note in Plesk and via e-mail but nothing at the domain was actually changed, neither files, database or configuration, despite everything selected. It's just as if it wouldn't do anything but touch all files...

No problem, much better to know there is an issue than wondering what is going on, thank you so much. By the way: Does anyone know for chance how I can correctly remove / rotate php-fpm_error.log? I have deleted the log about six times now, but after a few hours it's just back again with all...

No, unfortunately the automatic logrotate did not work.

That latency being at least 15+ minutes, while executing stats doing it correctly immediately seems odd to me. In any case, it feels like something here is no longer working correctly since early march. None of what I saw today has been an issue before.

Interesting. So I can reproduce the following on my instance: logrotate command does visibly only empty the file, nothing else. Only when I execute /usr/local/psa/admin/sbin/statistics –calculate-one –domain-name=<mydomain> the rotation actually happens. So If i execute logrotate three times...

So, I have no idea what I'm actually doing, but executing /usr/local/psa/admin/sbin/statistics –calculate-one –domain-name=<mydomain> does correctly rotate the logs? You can now see the previously vanished big logs that were rotated into packaged files (100 MB and 75 MB). How is that even...

I just tried the "logrotate -f /usr/local/psa/etc/logrotate.d/<domain name>" way you had mentioned in your post, the error_log was removed, but not rotated. It's just been emptied. Weird. Maybe that was a problem due to it having become so big, but I see that my access_log also has not been put...

Here is a screen, actually only the access_log was rotated when doing the fix mentioned by Peter. The error_log doesn't rotate on manual either.

I can confirm this is the case, I just noticed this today as well while working on a MediaWiki Update, the error_log wasn't rotated since early march and has gotten to a sizeable 6 GB. The same was true for access_logs, which is at 1.2 GB. And php-fpm_error.log as well. Manual logrotate worked...

Yeh, their algorithm is horribly broken: https://talk.plesk.com/threads/password-security-secure-does-not-recognize-a-secure-password-as-secure-but-as-medium.358283/

Oof, that algorithm seems broken beyond repair.