Search results

@solucionesuno, root has the same uid 0 on all systems, therefore you won't have problems with DB restore on another server (as long as you have root access on it). However, please note that MySQL DB is not the only thing that would need to be "restored" if you're doing it on another server...

Please check https://talk.plesk.com/threads/pi-331-plesk-installer-error-with-de-de-locale.339620/#post-811596 Most likely you just need to properly set up locales on your Ubuntu box.

@BobClaas, please either use command line as suggested above (just run plesk installer in shell as root) or launch Plesk Installer web interface from Tools & Settings > Updates & Upgrades.

https://kb.plesk.com/en/130419

It depends on the license type. Plesk Installer will warn you if your license would not work after upgrade to Plesk Onyx.

You can install Courier-IMAP instead (available as Plesk component), and then after migration is finished you may switch it to Dovecot. This way UIDLs should be preserved.

Please make sure you have access to both ext.plesk.com and autoinstall.plesk.com from the servers.

Looks OK to me. Please check if DB is accessible locally by running the plesk db command. It should open MySQL prompt. Please also check that MariaDB daemon service is running. Which device is mounted to /var/lib and /var/run in your case? Is there anything unusual there?

Those are two separate events. There was an issue with update 8 that caused problems with Dovecot under certain update settings. It is already fixed (manual fix is to install the latest version of the 'plesk-dovecot-imap-driver' package, which should now happen automatically for all applicable...

This is not a bug. This just means that another application is using the system package manager. To prevent issues with concurrent usage of package manager Plesk Software Update checks whether another Plesk Installer or Software Update instance is already running.

Placing a mail handler in a given queue should be guided by the use case. Maybe you need before-local queue instead. Unfortunately, I am not aware of yours. As long as handler type is global for before-remote, it will indeed fire for any mail that goes through Postfix smtpd milters subsystem...

Please see this thread in the Plesk Extensions subforum: https://talk.plesk.com/threads/mail-handler-called-twice-why.339640/#post-810019

Sorry, it was a temporary error at download site. It should already be fixed now.

@Dree, check this out: [root@server ~] # cat /root/.plesk_banner # This script is indirectly called by Bash on login shell startup. # It outputs Plesk shell banner with login instructions. # If you don't need it, you may comment out the following line. /usr/lib64/plesk-9.0/ssh-banner || ...

Before switching, it is recommended to wait until all queued mail is delivered and stop the SMTP service to stop receiving emails. Other than that the process should be smooth. Please also note that by replacing sendmail (depending on the exact way you do it) you may inadvertently break some...

@Linulex, yes your script would work with Postfix as well. However I strongly advise against applying it as is since it's easy to affect security and behavior on package updates. A much better option would be to implement a custom mail handler as suggested by @UFHH01. Please also check out...

Thanks for your report, @Michael (UW Madison) ! We've reproduced and filed the issue under internal ID EXTRUBY-21. It will be fixed in one of the future updates.

@bonny3, please see this thread: https://talk.plesk.com/threads/exception-failed-to-solve-dependencies.340071/ Exception: Failed to solve dependencies: psa-mail-driver-common-17.0.17-cos6.build1700161110.19.x86_64 requires libopendkim.so.10()(64bit)

Yes, in before-local it's too late, since it is executed in the MDA (mail delivery agent) context. Handler needs to be executed in SMTP (or to lesser extent, sendmail) context for REPLY to have any effect. There's a SpamAssassin integration in Plesk. Doesn't it suit your needs?

_pre and _post scripts are for the case when user runs apt-get upgrade and apt-get dist-upgrade manually between them. The other script will automate the process completely, effectively running _pre, then dist-upgrade, then _post script. For dist-upgrading to Ubuntu 16.04 we usually recommend...