Search results

Explain. We're talking in the context of Plesk servers. By default Plesk servers require STARTTLS on 587. So in the context of Plesk servers, how is that relevant?

I'm not certain if that's exactly our issue, but we do have clients reporting issues with some mail apps on 465 that work fine with 587, so that probably is the issue. Another reason why, when 587 is enabled in Plesk, it should be the default in all guides.

@Kaspar@Plesk when the submission port (587) is enabled, that should become the default in all guides, not 465. We shouldn't have to use a panel.ini override to do that. In other words, keep it at 465 if submission port is not enabled, and force it to 587 when submission port is enabled.

Found the source of this issue and a solid workaround. Apparently Virtuozzo/OpenVZ symlinks /sbin/init to systemd within the container, but then on the node when vzctl launches things it passes init parameters in like: init -z, which results in systemd -z. For reasons unknown to me, the -z...

@Dave W would welcome a pull request with these changes over on GitHub if only to ensure it works in more scenarios! Technically we could modify the --d value to --description in alamconvert8_plesk via sed, though I'd also recommend submitting that to Virtuozzo devs. If you have a vz license...

I believe these might have been two different things. 1. @mow described that when you create an email account in Plesk, it creates a *mail* user that can login to Plesk. It has limited capabilities, just to set things like the autoresponder and manage the spam filter for that particular email...

@Dave W Just realized - did you remove /root/almaconvert8-plesk after updating Virtuozzo/OpenVZ? Our wrapper will likely need to copy an updated version of the software over and modify it, but it assumes you started this from an updated node.

@Dave W Wish we could help more with this, but almaconvert8 is entirely written by Virtuozzo devs. The -plesk modified version does only one thing: excludes Plesk from the list of exceptions that would cause it to not run at all from the start. Considering you appear to be running Virtuozzo...

OpenVZ 7.0.21 - I suspect almaconvert8 only works smoothly on 7.0.20 and newer. That would explain some odd issues like this!

We have used it to successfully convert a 'recommended' Plesk install on a fresh CentOS 7 test container repeatedly (it was for testing after all: convert, revert, convert, revert), as well as one live container with a less common combination of Plesk components. The latter was more complicated...

We've created a shell script to make this work. It's essentially a Plesk-specific wrapper for almaconvert8 - the utility provided by Virtuozzo/OpenVZ devs. You can find it here: GitHub - websavers/centos2alma_openvz: A CentOS 7 to AlmaLinux 8 conversion utility for OpenVZ / VIrtuozzo containers...

Noticed this occurring recently since we bumped up the SPF_FAIL score. What's odd to me is that the mail server still records the Received-SPF header as a pass, yet Spamassassin apparently ignores this for its scoring. This is odd because `ignore_received_spf_header` is 0 and...

@Peter Debik Will do, thanks :)

@Peter Debik curious if anyone at Plesk knows what the circumstances are that lead to needing this dbus timeout adjustment. As in, do you know what environment that is expected to apply to? I'd definitely be curious to learn if the KB article was created from a report on another OpenVZ...

Indeed - it certainly was the last time. It appears to be connected to cgroups sessions clashing with the default dbus timeout. Yet it only occurs on busier servers. I think it's going like this: 1. There must be many processes generating short-running cgroups sessions (perhaps php-fpm ondemand...

This issue was fixed with a Virtuozzo update, as indicated above. We were able to remove our workarounds for all CentOS 7 boxes. Now a very similar issue has occurred with AlmaLinux 9 where there are thousands of abandoned sessions to the point they reach the session limit of 8192. The very...

We've run into this issue as well. What I don't understand then is why Plesk allows setting the symbolic link as the document root to begin with if it's just going to cause failure during migrations. Seems to me that either: 1. Plesk should block using symbolic links as the document root, OR 2...

We've written a guide and PHP script to show how to export the data, then automatically update the exported data with the new domain and client IDs, then import the data into the new server. It can be found here: GitHub - websavers/Plesk-Migrate-Backup-Settings: Run this on old and new server to...

Hey @Peter Debik This was already requested here: Increase migration speed And marked Completed in 2016 at which point the admin said "Please let us know on Plesk Forum if still have problems with migration speed." Which is what we did here... Nonetheless it has been added here: Improve...

The Plesk migrator still behaves exactly this way, which means it's very slow to resync.