Recent content by D3nnis3n

Doing so causes the updating problems if you have any other repositories configured that use default accepted algorithms, so they should not do that as it breaks their clients servers ... We only updated to .70 yesterday, and it did indeed restore the Imunify sources. There is no signs of...

So we figured this one out as well. The workaround is bad. It configures: APT::Key::Assert-Pubkey-Algo ">=dsa1024,rsa4096,rsa3072"; However, this line will replace the defaults, e.g. if this is configured, what is accepted by default will no longer be accepted when it is not in that...

Just in case someone else has the same problem in the future: Create the folder "resolved.conf.d" in /etc/systemd/ and add a 99-custom.conf with the following content: [Resolve] DNS=127.0.0.1 That will permanently change the DNS to the local resolver.

_Manual_ updating never failed, the issue is the warnings are seen as error which leads to the Plesk configured automatic updates _not_ working and sending an update failed e-mail every day. It is readded on every execution of Plesk Installer.

Well, we don't - but the source files are still included in apt. The workaround noted by Plesk also doesn't help - the Imunify repositories are still considered to be in failure and as such we still get an e-mail every day noting to us that updating failed.

So a security software is not able to actually provide secure keys, despite warnings about that having been given for ages and the "in due course" is so far months since they have been made first aware? Noone should use that security software. I don't even know why these repositories are...

Imunify still shows the error.

Hello, we are also getting this issue with the Plesk Grafana extension, additional to Imunify and PHP 7.4. If you have automatic updates enabled in Plesk, you will get sent a mail noting that the updates failed every day, as these warnings are considered an error for that purpose.

I figured it out, if someone else ever has the same issue: The process I was advised to do for some reason reset the IP assignment, but only for IPv6, the IPv4 was still there. As my personal network uses IPv6 as preferred, it never reached the website, but instead the base page for Plesk, which...

I also checked /etc/apache2 and /etc/nginx webmail configs for their certificate line - the certificate listed there is the one that in the database is connected to the correct domain and would be the correct certificate. Yet, all tried web browsers claim to see a different certificate.

@Martin Dias Any idea on that? The website is still using the general server certificate (which is a different domain and as such doesnt allow access due to HSTS) for its webmail, despite I have set mail and web certificate to it's own and have regenerated it via Let's Encrypt. Webmail is no...

Hello, it seems I can make changes which take effect, but there is an issue with the certificate after the subscription change. Despite no configuration has been changed - and it later having been updated to use the same certificate as before (or rather re-saved, the same was still noted in the...

Hello @Martin Dias, thank you, that seems to have worked, though the command closed with an error: SUCCESS: Owner of subscription '<redacted>' was changed. [2025-04-10 18:42:15.011] 51288:67f7f4e64535a ERR [util_exec] proc_close() failed ['/opt/psa/admin/bin/dnsmng' '--update'...

That was indeed the case, after removing the three entries and the respective session files in /opt/psa/PMM/sessions/ the backup error display has vanished. Thank you!

Sorry, I forgot that one. Looking at it, it shows all used IP's, which I would have to anonymize. If it's necessary, I'll do that, but given you said "leave that, for the moment" let's see if it works without. Yes, those datacenter nameservers are specified in /etc/netplan settings (and...