Search results

Can't tell for sure. The server, the backup was taken from, went offline yesterday night, so I guess it would be either the latest .60 or .59

ok I fixed the issue but this needs to be implemeted in the restore routine: disabling and re-enabling the Localhost Mode fixes the configs: plesk bin apache --listen-on-localhost false && plesk bin apache --listen-on-localhost true

alright, one step further: https://support.plesk.com/hc/en-us/articles/17793065826839-Enhancing-Security-with-Apache-Localhost-Mode-in-Plesk-18-0-56-PPP-43250 with Apache Localhost Mode introduced in Plesk 18.0.56 apache is set to listen to localhost only. thats fine and good but this must then...

on another x86 Plesk Server running 18.0.59, apache is listening on 0.0.0.0:7080 / 0.0.0.0:7081 instead of localhost / 127.0.0.1 (which of course would also fix the issue, however the configuration on the new server is different and I need to know how to fix this).

more structured as I cannot edit my first message anymore: Info: Ubuntu 22.04 on ARM fresh install with restored backup on a new machine (new IP) Facts: all Websites and their Webmail-Subdomains throw 502`s by nginx disabling nginx-proxying fixes the Websites but not webmail (as it is always...

- Ubuntu 22.04 on ARM - Fresh install with restored backup on a new machine (new IP) - all Websites and their Webmail-Subdomains throw 502`s by nginx - disabling nginx-proxying fixes the Websites but not webmail (as it is always using apache) - proxy_error_log shows connect() failed (111...

same here

also check cat /proc/user_beancounters | grep numproc for the numproc limit on your machine. DefaultTasksMax must be equal or smaller than numproc limit and you have to be aware that setting DefaultTasksMax == numproc limit basically means: One process can use all of the available ressources...

@ciB check systemctl show --property DefaultTasksMax which is set to 60 on my end. I increased this value to 300 through /etc/systemd/system.conf on another system which seems to work fine now.

same here (18.0.34 / Debian 9.13). changing chroot flag in master.cf and removing compatibility_level = 2 in main.cf fixed the issues. thanks @hschramm and @Andri. @plesk Team: How is it that there is not a huge "Fix 18.0.34" sticky-thread on top of the forum? Apart from srewing up the mails...

This is my temporary workaround: 1) create the desired webmail address as a subdomain (i.e. mail.xyz.com) 2) go to webserver settings of the just created subdomain and use the settings below for http and https UseCanonicalName Off DocumentRoot "/usr/share/psa-horde" Alias /horde/...

any idea what needs to be changed?

This solved the issue for me: http://kb.odin.com/en/121094

well but I did not upgrade from 6 to 7 and do have the exact same issue..

exact same issue on two servers here! "/opt/psa/admin/bin/httpdmng --reconfigure-domain AAAAA.de" throws a "Segmentation fault" also "/usr/local/psa/bootstrapper/pp12.0.18-bootstrapper/bootstrapper.sh repair" throws the exact same...

another reboot did the trick. seems to be fine now. still wondering how this could have happened.. thank you!

I can login with root / root-pw now (using FF, Safari does not work). /etc/my.cnf does not exist. When I tried to change the "admin" pw being logged in as root, I got no errors along with a "changed successful" message. /usr/local/psa/bin/admin --show-password does show the new pw now (the...

getting closer: #2 /opt/psa/admin/plib/auth.php(93): require_once('/opt/psa/admin/...') #3 {main} 2014-01-22T13:33:57+01:00 ERR (3) [panel]: Unable to connect to database: saved admin password is incorrect.: 0: auth.php:142 [22-Jan-2014 13:33:57 Europe/Berlin] PleskFatalException: Unable to...

which one? EDIT: last reported error two days ago in /var/log/sw-cp-server/error.log 2014/01/20 09:57:54 [error] 2702#0: *1688 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 194.38.105.19, server: , request: "GET /dbs/index.php HTTP/1.1"...

nope, this also doesn't work EDIT: I also tried changing the sql pw directly, changing the pw in /etc/psa/.psa.shadow and then re-run export PSA_PASSWORD='new_password' /usr/local/psa/admin/sbin/ch_admin_passwd unset PSA_PASSWORD result is the same. SQL access works after that through mysql...