plesk

PCI DSS requires servers to reject TLS 1.0 and TLS 1.1 and use only TLS 1.2 or higher. This guide shows how to enforce that in Plesk on Linux.

Prerequisites

• Root SSH access to the Plesk server
• Plesk 11.x, 12.x, or Onyx (17.x) on Linux

Steps

1. Edit the Plesk SSL configuration:

nano /etc/nginx/conf.d/ssl.conf

Set the allowed protocols:

ssl_protocols TLSv1.2 TLSv1.3;

2. For Apache (if used without Nginx):

nano /etc/httpd/conf.d/ssl.conf

SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

3. Disable weak cipher suites (Nginx):

ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';

4. Apply changes via Plesk:

plesk sbin httpdmng --reconfigure-all
service nginx restart
service httpd restart

Verify

openssl s_client -connect yourdomain.com:443 -tls1
# Should return: handshake failure
openssl s_client -connect yourdomain.com:443 -tls1_2
# Should return: SSL handshake has read ...

Also run the domain through a PCI scanner or https://www.ssllabs.com/ssltest/.

Notes

• TLS 1.0 and 1.1 disablement may break very old browsers (IE 8 on Windows XP).
• After a Plesk update, regenerate configs with plesk sbin httpdmng --reconfigure-all.

Enabling gzip (deflate) compression reduces page transfer sizes and improves load times. In Plesk you can enable it per-site via .htaccess or globally via the Apache configuration.

Prerequisites

• Access to Plesk File Manager or SSH
• Apache with mod_deflate enabled (default in Plesk)

Steps

Option A — Per-site via .htaccess

Open the site's .htaccess file in Plesk File Manager (Domains → example.com → File Manager) and add:

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
    AddOutputFilterByType DEFLATE application/x-font
    AddOutputFilterByType DEFLATE application/x-font-opentype
    AddOutputFilterByType DEFLATE application/x-font-otf
    AddOutputFilterByType DEFLATE application/x-font-truetype
    AddOutputFilterByType DEFLATE application/x-font-ttf
    AddOutputFilterByType DEFLATE application/x-javascript
    AddOutputFilterByType DEFLATE application/xhtml+xml
    AddOutputFilterByType DEFLATE application/xml
    AddOutputFilterByType DEFLATE font/opentype
    AddOutputFilterByType DEFLATE font/otf
    AddOutputFilterByType DEFLATE font/ttf
    AddOutputFilterByType DEFLATE image/svg+xml
    AddOutputFilterByType DEFLATE image/x-icon
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/javascript
    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/xml
</IfModule>

Option B — Nginx gzip (when Nginx is in front of Apache)

In Plesk go to Domains → example.com → Apache & Nginx Settings and add to the Additional nginx directives field:

gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;
gzip_min_length 1024;
gzip_vary on;

Click OK and Plesk will reload Nginx automatically.

Verify

curl -H "Accept-Encoding: gzip" -I https://example.com/ | grep -i content-encoding
# Expected: content-encoding: gzip

Notes

• Do not compress already-compressed formats such as JPEG, PNG, or ZIP.
• Changes to .htaccess take effect immediately without restarting Apache.

A 502 Bad Gateway from Nginx in Plesk usually means Nginx cannot reach the PHP-FPM socket for one or more vhosts. This guide covers diagnosing and fixing the issue.

Prerequisites

• Root SSH access
• Plesk 12.x or Onyx on CentOS/RHEL

Steps

1. Check the Nginx error log:

tail -50 /var/www/vhosts/system/example.com/logs/proxy_error_log

2. Repair the web server configuration:

plesk repair web

3. Restart PHP-FPM and Nginx:

service plesk-php73-fpm restart   # adjust PHP version as needed
service nginx restart

4. If the issue is Nginx-specific, disable Nginx temporarily to isolate:

/usr/local/psa/admin/bin/nginxmng --disable

Confirm sites load via Apache alone, then re-enable:

/usr/local/psa/admin/bin/nginxmng --enable

5. Reconfigure all web server settings to regenerate vhost configs:

plesk sbin httpdmng --reconfigure-all

Verify

curl -I https://example.com/
# Expected: HTTP/1.1 200 OK

Notes

• After a server migration the PHP-FPM socket paths may mismatch — plesk repair web regenerates them.
• Check /var/log/nginx/error.log for global Nginx errors in addition to per-domain proxy logs.

A 504 Gateway Timeout means Nginx gave up waiting for an upstream PHP-FPM response. This is typically caused by insufficient timeout values or a slow/stuck PHP process.

Prerequisites

• Root SSH access
• Plesk for Linux with Nginx + PHP-FPM

Steps

1. Confirm the error in the proxy log:

grep "upstream timed out" /var/www/vhosts/system/example.com/logs/proxy_error_log | tail -20

2. Increase the Nginx fastcgi timeout — add to the domain's Additional Nginx Directives in Plesk UI:

fastcgi_read_timeout 300;
fastcgi_send_timeout 300;
fastcgi_connect_timeout 300;

Or edit the Nginx vhost config directly:

nano /var/www/vhosts/system/example.com/conf/nginx.conf

3. Increase PHP-FPM request timeout. Edit the pool config:

nano /opt/plesk/php/7.4/etc/php-fpm.d/example.com.conf

request_terminate_timeout = 300

4. Also raise PHP max_execution_time in Plesk UI:
Domains → example.com → PHP Settings → max_execution_time = 300

5. Reload Nginx and PHP-FPM:

service nginx reload
service plesk-php74-fpm reload

Verify

curl -o /dev/null -w "%{http_code}" https://example.com/
# Expected: 200

Notes

• If many domains show the error simultaneously, the server may be overloaded — check top and iostat.
• Timeout values above 300 s indicate a PHP logic problem; profile the application rather than increasing timeouts further.

This guide covers upgrading MySQL 5.5 to 5.6/5.7, or MariaDB 5.5 to 10.x on a Plesk Linux server. Always take a full database backup before proceeding.

Prerequisites

• Root SSH access
• Plesk for Linux
• Sufficient disk space for a full backup

Steps

1. Back up all databases:

MYSQL_PWD=$(cat /etc/psa/.psa.shadow) mysqldump -u admin --all-databases --routines --triggers > /root/all-databases-backup.sql

2. Upgrade via Plesk installer (recommended):

plesk installer --select-release-current --install-component mysql57
# or for MariaDB 10.3:
plesk installer --select-release-current --install-component mariadb103

3. If doing a manual yum upgrade, stop MySQL first:

service mysqld stop
# or
service mariadb stop

4. Update the repo and install:

yum install -y MariaDB-server MariaDB-client
# or for MySQL:
yum install -y mysql-community-server

5. Start the service and run the upgrade script:

service mariadb start
MYSQL_PWD=$(cat /etc/psa/.psa.shadow) mysql_upgrade -u admin
service mariadb restart

6. Rebuild Plesk package dependencies:

plesk sbin packagemng -sdf

Verify

mysql --version
MYSQL_PWD=$(cat /etc/psa/.psa.shadow) mysql -u admin -e "SELECT VERSION();"

Notes

• Direct upgrade from MySQL 5.1 to 5.6/5.7 breaks table structures — upgrade to 5.5 first.
• Ubuntu 18.04 and Debian 9 ship MariaDB 10.1; upgrade via apt.
• Check the Plesk compatibility matrix before upgrading beyond the bundled version.

When importing a database larger than ~500 MB through phpMyAdmin, the upload can fail with a script timeout or a 504 Gateway Timeout. This guide shows how to work around the limit.

Prerequisites

• Root SSH access to the Plesk server
• The database dump file available on the server

Steps

Option A — Use Plesk's built-in database import (Plesk 12.5+):

1. In Plesk go to Home → Domains → example.com → Databases.
2. Click the database name, then click Import.
3. Upload the SQL file — Plesk handles it without PHP timeout constraints.

Option B — Import from the command line (most reliable for very large files):

MYSQL_PWD=$(cat /etc/psa/.psa.shadow) mysql -u admin database_name < /path/to/dump.sql

Option C — Increase PHP and Nginx timeouts for phpMyAdmin:

# Raise PHP limits in /etc/php.ini or Plesk PHP settings:
upload_max_filesize = 1024M
post_max_size = 1024M
max_execution_time = 3600
max_input_time = 3600

Then raise the Nginx timeout for the phpMyAdmin location:

fastcgi_read_timeout 3600;

service nginx reload

Verify

MYSQL_PWD=$(cat /etc/psa/.psa.shadow) mysql -u admin -e "USE database_name; SHOW TABLES;" | wc -l

Notes

• The command-line import method bypasses all web-layer timeouts and is the fastest approach for large dumps.
• Compress the dump with gzip and use zcat dump.sql.gz | mysql ... to save disk space.

Plesk manages Apache and Nginx configuration through a hierarchy of include files. Knowing the layout helps when troubleshooting or adding custom directives.

Prerequisites

• SSH access with read permission to /etc/httpd or /etc/apache2

Apache Configuration Hierarchy

/etc/httpd/httpd.conf                          # Main Apache config (RHEL/CentOS)
  └─ /etc/httpd/conf.d/zz010_psa_httpd.conf    # Plesk include entry point
       └─ /etc/httpd/conf/plesk.conf.d/
            ├─ server.conf                      # Global server settings
            ├─ ip_default/                      # Per-IP default vhosts
            ├─ horde.conf                       # Horde webmail
            ├─ roundcube.conf                   # Roundcube webmail
            └─ vhosts/
                 └─ example.com.conf            # Per-domain include

On Debian/Ubuntu the base config is /etc/apache2/apache2.conf and the Plesk entry point is in /etc/apache2/conf.d/.

Per-Domain Apache Files

/var/www/vhosts/system/example.com/conf/
    httpd.conf           # Main vhost directives (managed by Plesk)
    httpd.conf.d/        # Custom include dir — add custom .conf files here

Nginx Configuration Hierarchy

/etc/nginx/nginx.conf
  └─ /etc/nginx/conf.d/
       └─ zz010_psa_nginx.conf          # Plesk Nginx entry point

/var/www/vhosts/system/example.com/conf/
    nginx.conf                          # Per-domain Nginx config (managed by Plesk)
    nginx.conf.d/                       # Custom Nginx includes

Steps — Adding Custom Directives Safely

Do not edit Plesk-managed files directly — they are overwritten on reconfigure. Instead:

# Apache custom include
echo 'Header always set X-Frame-Options SAMEORIGIN' >   /var/www/vhosts/system/example.com/conf/httpd.conf.d/security.conf
service httpd reload

# Or use Plesk UI: Domains → example.com → Apache & Nginx Settings → Additional directives

Verify

apachectl -t          # Test Apache config syntax
nginx -t              # Test Nginx config syntax

Notes

• Run plesk sbin httpdmng --reconfigure-domain example.com to regenerate a domain's config without affecting others.
• PHP-FPM pool configs live in /opt/plesk/php/<version>/etc/php-fpm.d/.

When MariaDB or MySQL fails to start with a "Can't init tc log" error, the transaction coordinator log is corrupted or already in use. This guide shows how to recover the service.

Prerequisites

• Root SSH access
• Plesk for Linux (Onyx or later)

Steps

1. Confirm the error:

journalctl -xe | grep "Can't init tc log"
systemctl status mariadb.service

2. Check for a stale tc.log file and remove it:

ls -lh /var/lib/mysql/tc.log
rm -f /var/lib/mysql/tc.log

3. Check for and remove stale lock files:

rm -f /var/lib/mysql/mysql.sock
rm -f /var/lock/subsys/mysql

4. Verify data directory ownership:

ls -ld /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql/

5. Start the service:

systemctl start mariadb
# or
service mysqld start

Verify

systemctl status mariadb
MYSQL_PWD=$(cat /etc/psa/.psa.shadow) mysql -u admin -e "SHOW DATABASES;"

Notes

• This error commonly appears after an unclean shutdown or power loss.
• If the service still fails after removing stale files, check the full log: journalctl -u mariadb --since "1 hour ago".
• Plesk becomes inaccessible when its database is down — restore the service before attempting Plesk UI operations.

When Nginx logs connect() to unix:///...php-fpm.sock failed (11: Resource temporarily unavailable), PHP-FPM is rejecting connections because its backlog or process limits are exhausted. This guide covers tuning PHP-FPM to resolve the issue.

Prerequisites

• Root SSH access
• Plesk for Linux with PHP-FPM mode enabled

Steps

1. Confirm the error:

tail -100 /var/www/vhosts/system/example.com/logs/proxy_error_log | grep "temporarily unavailable"

2. Locate the PHP-FPM pool config for the domain:

ls /opt/plesk/php/*/etc/php-fpm.d/ | grep example.com

3. Increase process limits in the pool config:

nano /opt/plesk/php/7.4/etc/php-fpm.d/example.com.conf

pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500
listen.backlog = 65535

4. Raise the OS socket backlog limit:

echo 65535 > /proc/sys/net/core/somaxconn
# Make permanent:
echo "net.core.somaxconn = 65535" >> /etc/sysctl.conf
sysctl -p

5. Reload PHP-FPM:

service plesk-php74-fpm reload

Verify

grep "temporarily unavailable" /var/www/vhosts/system/example.com/logs/proxy_error_log | wc -l
# Should drop to zero after the fix

Notes

• Each PHP-FPM child consumes RAM; set pm.max_children relative to available memory.
• Use pm = ondemand on low-traffic sites to free idle workers.
• Tuning MaxClients in Apache does not help when PHP-FPM is the bottleneck.

The error "Resource temporarily unavailable" in the Nginx proxy log means PHP-FPM has run out of worker threads. Increasing the pool limits resolves the problem.

Prerequisites

• Root SSH access
• Nginx + PHP-FPM stack in Plesk or standalone

Steps

1. Edit the PHP-FPM pool configuration:

nano /etc/php-fpm.d/www.conf
# or for Plesk-managed PHP:
nano /opt/plesk/php/7.4/etc/php-fpm.d/example.com.conf

2. Apply tuned values:

pm = dynamic
pm.max_children = 1000
pm.max_requests = 1000
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 50

3. Reload PHP-FPM:

systemctl reload php-fpm
# or for Plesk:
service plesk-php74-fpm reload

Verify

tail -f /var/log/nginx/error.log | grep "temporarily unavailable"

Notes

• Setting pm.max_children = 1000 is aggressive — ensure the server has enough RAM (roughly 20–50 MB per worker).
• Use php-fpm -tt to validate the config syntax before reloading.
• Monitor active workers with systemctl status php-fpm or a status page set via pm.status_path.

The MongoDB PHP driver is not bundled with Plesk PHP packages and must be installed manually via PECL. Follow these steps for each PHP version that needs MongoDB support.

Prerequisites

• Root SSH access
• Plesk for Linux
• /tmp must be mounted with exec permission (not noexec)

Steps

1. Install build prerequisites (RHEL/CentOS):

yum groupinstall -y "Development Tools"
yum install -y openssl-devel

For Debian/Ubuntu:

apt-get install -y build-essential libssl-dev

2. Install the driver using the Plesk-managed PECL for the target PHP version:

/opt/plesk/php/7.4/bin/pecl install mongodb

3. Add the extension to the PHP ini:

echo "extension=mongodb.so" > /opt/plesk/php/7.4/etc/php.d/mongodb.ini

4. Restart PHP-FPM:

service plesk-php74-fpm restart

5. Repeat steps 2–4 for any additional PHP versions.

Verify

/opt/plesk/php/7.4/bin/php -m | grep mongodb
# Expected: mongodb

Notes

• If /tmp has noexec, set TMPDIR before running PECL: export TMPDIR=/var/tmp && pecl install mongodb.
• The PECL package name is mongodb (not mongo); the old mongo extension is deprecated.

CORS headers allow a browser to load resources from a different domain. This guide shows how to configure CORS headers in Plesk for an Apache or Nginx vhost.

Prerequisites

• Access to Plesk UI with Domain Administrator or Server Administrator role
• Plesk for Linux

Steps

Option A — Via Plesk UI (Apache + Nginx):

1. Log in to Plesk and go to Domains → example1.com → Apache & Nginx Settings.
2. Add the following to Additional directives for HTTP and to Additional directives for HTTPS:

Header set Access-Control-Allow-Origin "https://example.com"
Header set Access-Control-Allow-Methods "GET, POST, OPTIONS"
Header set Access-Control-Allow-Headers "Content-Type, Authorization"

3. Click OK.

Option B — Via .htaccess (Apache only):

<IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "https://example.com"
    Header set Access-Control-Allow-Methods "GET, POST, OPTIONS"
    Header set Access-Control-Allow-Headers "Content-Type, Authorization"
</IfModule>

Option C — Nginx additional directives (for wildcard CORS):

add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Methods "GET, POST, OPTIONS";
add_header Access-Control-Allow-Headers "DNT, X-CustomHeader, Keep-Alive, User-Agent, X-Requested-With, Content-Type, Authorization";

Verify

curl -I -H "Origin: https://example.com" https://example1.com/api/resource | grep -i "access-control"

Notes

• Wildcard (*) origins cannot be used with Access-Control-Allow-Credentials: true.
• For preflight requests, also handle the HTTP OPTIONS method.
• CORS is enforced by the browser — it does not restrict server-to-server requests.

Memcache and Memcached are not bundled with Plesk PHP packages and must be installed manually via PECL. This guide covers installation and removal for Plesk on Linux.

Prerequisites

• Root SSH access
• Plesk 12.5+ for Linux
• Build tools installed (gcc, make)

Steps — Install

1. Install the memcached daemon:

yum install -y memcached libmemcached-devel
systemctl enable --now memcached

2. Install the PHP extension via PECL for the target PHP version:

# For 'memcached' (recommended, libmemcached-based):
/opt/plesk/php/7.4/bin/pecl install memcached

# For legacy 'memcache' extension:
/opt/plesk/php/7.4/bin/pecl install memcache

3. Register the extension:

echo "extension=memcached.so" > /opt/plesk/php/7.4/etc/php.d/memcached.ini

4. Restart PHP-FPM:

service plesk-php74-fpm restart

Steps — Uninstall

rm -f /opt/plesk/php/7.4/etc/php.d/memcached.ini
service plesk-php74-fpm restart

Verify

/opt/plesk/php/7.4/bin/php -m | grep memcache

Notes

• Use memcached (with a d) for modern applications — the older memcache extension is unmaintained.
• Repeat the PECL install and ini steps for each additional PHP version that needs the extension.
• Default memcached listens on 127.0.0.1:11211 — do not expose it to the internet.

Collabora Online provides a self-hosted office suite that integrates with Nextcloud. This guide shows how to deploy it via Docker in Plesk and connect it to Nextcloud.

Prerequisites

• Root SSH access
• Docker extension installed and enabled in Plesk
• A working Nextcloud installation
• A dedicated subdomain (e.g., collabora.example.com) with a valid SSL certificate

Steps

1. Pull and run the Collabora Docker container:

docker run -t -d -p 127.0.0.1:9980:9980   -e 'domain=nextcloud\.example\.com'   -e 'username=admin'   -e 'password=strongpassword'   --restart always --cap-add MKNOD   collabora/code

2. In Plesk, create the subdomain collabora.example.com, disable PHP-FPM, and go to its Nginx settings. Add these Additional Nginx Directives:

# Static Collabora files
location ^~ /loleaflet {
    proxy_pass https://localhost:9980;
    proxy_set_header Host $http_host;
}

# WOPI discovery
location ^~ /hosting/discovery {
    proxy_pass https://localhost:9980;
    proxy_set_header Host $http_host;
}

# WebSocket tunnel
location ^~ /lool {
    proxy_pass https://localhost:9980;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $http_host;
    proxy_read_timeout 3600;
}

# Admin interface (optional, restrict access)
location ^~ /lool/adminws {
    proxy_pass https://localhost:9980;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $http_host;
}

3. Reload Nginx:

service nginx reload

4. In Nextcloud, install the Collabora Online app, then set the server URL to https://collabora.example.com.

Verify

curl https://collabora.example.com/hosting/discovery | head -5
# Should return XML capability document

Notes

• Escape dots in the domain environment variable with \..
• The --cap-add MKNOD flag is required for the container to function correctly.
• Monitor container logs with docker logs <container_id>.

When running a Node.js script via Plesk's Run Script button, npm may warn that no node binary is in the current PATH. This happens because the Plesk-managed Node.js binary is not in the system PATH used by npm lifecycle scripts.

Prerequisites

• Plesk Onyx for Linux or Windows
• Node.js extension installed

Steps

1. Add the --scripts-prepend-node-path flag to the npm start command in your package.json:

{
  "scripts": {
    "start": "node index.js"
  }
}

Run it as:

/opt/plesk/node/<version>/bin/npm start --scripts-prepend-node-path

2. Alternatively, set the NODE_PATH environment variable in the Plesk Node.js app configuration:
Go to Domains → example.com → Node.js, and add an environment variable:

PATH=/opt/plesk/node/12/bin:$PATH

3. Or symlink the Plesk Node.js binary to a system PATH location:

ln -s /opt/plesk/node/12/bin/node /usr/local/bin/node
ln -s /opt/plesk/node/12/bin/npm /usr/local/bin/npm

4. Restart the application from the Plesk UI or via SSH:

cd /var/www/vhosts/example.com/httpdocs
/opt/plesk/node/12/bin/npm start

Verify

curl -I https://example.com/
# App should respond with HTTP 200

Notes

• This affects both Linux and Windows Plesk installations.
• When upgrading Node.js through Plesk, update symlinks or PATH values accordingly.

This guide covers running the Collabora CODE Docker container in Plesk and configuring Nginx as a reverse proxy so Nextcloud can reach it.

Prerequisites

• Root SSH access and Docker installed
• A dedicated subdomain with SSL (e.g., collabora.nextcloud.tld)
• Nextcloud running on the same or a reachable server

Steps

1. Start the Collabora container:

docker run -t -d -p 127.0.0.1:9980:9980   -e "domain=your\.nextcloud\.tld"   -e "username=admin"   -e "password=admin"   --restart always --cap-add MKNOD   collabora/code

2. In Plesk create the subdomain, disable PHP-FPM for it, then add these Additional Nginx Directives:

# Static files
location ^~ /loleaflet {
    proxy_pass https://localhost:9980;
    proxy_set_header Host $http_host;
}

# WOPI discovery
location ^~ /hosting/discovery {
    proxy_pass https://localhost:9980;
    proxy_set_header Host $http_host;
}

# WebSocket tunnel
location ^~ /lool {
    proxy_pass https://localhost:9980;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $http_host;
    proxy_read_timeout 3600;
}

3. Reload Nginx:

service nginx reload

4. In Nextcloud admin panel, go to Settings → Collabora Online and set the URL to https://collabora.nextcloud.tld.

Verify

curl https://collabora.nextcloud.tld/hosting/discovery | grep -i "capabilities"

Notes

• Change the default admin password in the -e "password=..." argument before going to production.
• The subdomain must be accessible over HTTPS from the Nextcloud instance.

After a server migration or Plesk upgrade, scheduled cron tasks may stop running silently. This guide walks through diagnosing and restoring cron functionality in Plesk.

Prerequisites

• Root SSH access
• Plesk for Linux

Steps

1. Check whether the system cron daemon is running:

systemctl status crond
# or on Debian/Ubuntu:
systemctl status cron

2. List scheduled tasks as stored in Plesk:

plesk db "SELECT * FROM ScheduledTasks;"

3. Check the Plesk crontab for a domain user:

crontab -l -u example_user

4. Regenerate crontabs from Plesk database:

plesk repair web
# or force crontab rebuild:
/usr/local/psa/admin/sbin/psa_repair

5. Verify Plesk task scheduler service:

service psa status
plesk sbin pleskbackup --help    # confirms scheduler is reachable

6. Review the cron log for errors:

grep CRON /var/log/messages | tail -30
# or:
journalctl -u crond --since "24 hours ago"

Verify

Add a test cron task in Plesk UI (Tools & Settings → Scheduled Tasks) to run every minute and confirm it executes.

Notes

• After migrations, user UIDs may change, causing cron jobs to run as the wrong user — verify UID matches between source and destination.
• Domain-level scheduled tasks are stored per-user in /var/spool/cron/.

Plesk backups use tar and pigz for compression, which can saturate CPU and disk IO and cause 504 errors for live sites. This guide shows how to reduce backup impact.

Prerequisites

• Access to Plesk UI (Tools & Settings → Backup Manager)
• Root SSH access for advanced tuning

Steps

Option 1 — Run backups at low priority (recommended):

1. Go to Tools & Settings → Backup Manager → Settings.
2. Enable Run scheduled backup processes with low priority.
3. Click OK.

Option 2 — Disable compression to eliminate CPU spikes:

1. In the same Settings screen, enable Do not compress backup files.

Option 3 — Use ionice and nice to manually reduce backup process priority:

# Lower CPU priority of pigz and tar during backup
renice 19 -p $(pgrep pigz)
ionice -c 3 -p $(pgrep tar)

Option 4 — Schedule backups during off-peak hours:
In Backup Manager → Settings → Scheduled Backup, set the time to a low-traffic window.

Verify

iostat -x 2 5         # monitor disk IO during next backup run
top -d 2              # monitor CPU usage

Notes

• Disabling compression increases backup file size — ensure adequate storage.
• Consider backing up to a remote destination (FTP/S3) to move IO off the main disk.

When Apache MaxClients or MaxRequestWorkers limits are hit and connection counts spike abnormally, the server may be under a DoS or DDoS attack. This guide covers quick diagnosis and initial mitigation steps.

Prerequisites

• Root SSH access
• Plesk for Linux with Apache

Steps

1. Check current connection count and top source IPs (real-time attack):

ss -tan state established | grep ":80\|:443" | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

2. Find the most-requested URLs from Apache access log:

awk '{print $7}' /var/www/vhosts/example.com/logs/access_log | sort | uniq -c | sort -rn | head -20

3. Check which domains are receiving the most traffic:

grep -R "GET\|POST" /var/www/vhosts/*/logs/access_log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

4. Block an offending IP with iptables:

iptables -I INPUT -s <attacker_ip> -j DROP

5. Block a range (CIDR):

iptables -I INPUT -s 192.0.2.0/24 -j DROP

6. For post-attack analysis, parse historical logs:

grep "$(date --date='1 hour ago' '+%d/%b/%Y:%H')" /var/www/vhosts/example.com/logs/access_log |   awk '{print $1}' | sort | uniq -c | sort -rn | head -20

7. Increase Apache limits temporarily if the attack has passed:

plesk sbin httpdmng --reconfigure-all
service httpd graceful

Verify

ss -tan state established | grep ":80\|:443" | wc -l
# Connection count should drop after blocking offending IPs

Notes

• Consider enabling Fail2Ban or CSF Firewall for automated blocking.
• For sustained DDoS, contact the datacenter or upstream provider to implement upstream filtering.
• Enable mod_evasive in Apache for automatic rate-limiting.

Plesk stores DKIM private keys in a standard location on the filesystem. You may need to retrieve the key path when configuring external DNS or troubleshooting mail signing.

Steps

Default DKIM private key path:

/etc/domainkeys/<domain.com>/default

Replace <domain.com> with the actual domain name, for example:

/etc/domainkeys/example.com/default

View the public key (for DNS TXT record verification):

openssl rsa -in /etc/domainkeys/example.com/default -pubout

List all DKIM keys on the server:

ls /etc/domainkeys/

Verify

# Confirm the key is valid:
openssl rsa -check -in /etc/domainkeys/example.com/default
# Expected: RSA key ok

Notes

• The DKIM selector is default by default; the corresponding DNS record is default._domainkey.example.com.
• Key files are owned by root and should have permissions 600.
• To regenerate a DKIM key, go to Plesk → Domains → example.com → Mail Settings → DKIM and toggle DKIM off and back on.

DKIM, SPF, and DMARC are email authentication standards that reduce spam and phishing. Plesk supports all three natively. This guide covers enabling and verifying each one.

Prerequisites

• Plesk Administrator access
• Ability to add DNS TXT records for the domain

Steps — DKIM

1. Enable DKIM in Plesk:

1. Go to Domains → example.com → Mail Settings.
2. Check Use DKIM spam protection system to sign outgoing email messages.
3. Click OK.

2. Plesk adds the DNS TXT record automatically if using Plesk DNS. If using external DNS, retrieve the public key:

cat /etc/domainkeys/example.com/default.public

Add a TXT record: default._domainkey.example.com with value v=DKIM1; k=rsa; p=<public_key>.

Steps — SPF

1. Go to Domains → example.com → DNS Settings and add a TXT record:

v=spf1 a mx ip4:<server_ip> ~all

Use -all (hard fail) instead of ~all (soft fail) for stricter enforcement once verified.

Steps — DMARC

1. Add a TXT record for _dmarc.example.com:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-reports@example.com; sp=quarantine; adkim=s; aspf=s

Start with p=none (monitor only) before enforcing p=quarantine or p=reject.

Verify

# Check DNS records:
dig TXT default._domainkey.example.com
dig TXT example.com        # SPF
dig TXT _dmarc.example.com # DMARC

# Send a test email and check headers for DKIM=pass, SPF=pass, DMARC=pass

Notes

• DNS changes may take up to 48 hours to propagate.
• Plesk uses SRS (Sender Rewriting Scheme) so forwarded messages can pass SPF checks.
• Use https://mxtoolbox.com/dmarc.aspx to test your DMARC record.

When Imagick fails to load after an update, the PHP ini may still reference the old version. This guide shows how to reset the PECL config and reinstall the extension cleanly.

Prerequisites

• Root SSH access
• Plesk for Linux
• ImageMagick development libraries installed

Steps

1. Reset the PECL PHP ini path to ensure the correct ini is used:

/opt/plesk/php/7.3/bin/pecl config-set php_ini /opt/plesk/php/7.3/etc/php.ini

2. Verify Imagick is no longer loaded:

/opt/plesk/php/7.3/bin/php -m | grep imagick

3. Remove the old extension file:

rm -f /opt/plesk/php/7.3/lib/php/extensions/*/imagick.so
rm -f /opt/plesk/php/7.3/etc/php.d/imagick.ini

4. Install ImageMagick dev libraries if not present:

yum install -y ImageMagick-devel
# or on Debian/Ubuntu:
apt-get install -y libmagickwand-dev

5. Reinstall Imagick via PECL:

/opt/plesk/php/7.3/bin/pecl install imagick

6. Re-enable the extension:

echo "extension=imagick.so" > /opt/plesk/php/7.3/etc/php.d/imagick.ini
service plesk-php73-fpm restart

Verify

/opt/plesk/php/7.3/bin/php -m | grep imagick
# Expected: imagick

Notes

• Adjust the PHP version (7.3) in all paths to match the version you are targeting.
• If multiple PHP versions need Imagick, repeat steps 1–6 for each version.

This guide walks through upgrading MariaDB to a newer version (e.g., 10.5) on a Plesk Linux server, including backup, package replacement, and post-upgrade steps.

Prerequisites

• Root SSH access
• Sufficient disk space for a full database backup
• A scheduled maintenance window

Steps

1. Dump all databases:

MYSQL_PWD=$(cat /etc/psa/.psa.shadow) mysqldump -u admin --verbose   --all-databases --routines --triggers > /tmp/all-databases.sql

2. Stop MariaDB and back up the data directory:

service mariadb stop
cp -a /var/lib/mysql/ /var/lib/mysql_backup

3. Remove conflicting packages:

rpm -e --nodeps mariadb-bench

4. Update the MariaDB repository file:

nano /etc/yum.repos.d/MariaDB.repo

[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.5/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

5. Install the new MariaDB packages:

yum install -y MariaDB-client MariaDB-server MariaDB-compat MariaDB-shared

6. Start MariaDB and run the upgrade script:

systemctl restart mariadb
MYSQL_PWD=$(cat /etc/psa/.psa.shadow) mysql_upgrade -u admin
systemctl restart mariadb

7. Rebuild Plesk package dependencies:

plesk sbin packagemng -sdf
rpm -q --whatprovides mysql-server

Verify

mysql --version
MYSQL_PWD=$(cat /etc/psa/.psa.shadow) mysql -u admin -e "SELECT VERSION();"

Notes

• The data directory backup in step 2 allows rollback by stopping MariaDB and restoring from /var/lib/mysql_backup.
• Check the Plesk compatibility matrix at https://www.plesk.com/compatibility-matrix/ before upgrading beyond the recommended version.

A reference of frequently used Plesk command-line tools for server administration, web server management, and Git operations.

Web Server Management

# Reconfigure all vhosts (fixes "default Plesk page" issue):
/usr/local/psa/admin/sbin/websrvmng -a

# Reconfigure a single domain:
plesk sbin httpdmng --reconfigure-domain example.com

# Reconfigure all domains:
plesk sbin httpdmng --reconfigure-all

# Test Apache config:
apachectl -t

# Test Nginx config:
nginx -t

Nginx Management

# Enable Nginx:
/usr/local/psa/admin/bin/nginxmng --enable

# Disable Nginx:
/usr/local/psa/admin/bin/nginxmng --disable

# Reload Nginx:
service nginx reload

Plesk Database

# Run a query against the Plesk internal database:
plesk db "SELECT * FROM domains LIMIT 10;"

# Re-activate a disabled domain:
plesk db "UPDATE domains SET status = 0 WHERE name = 'example.com';"
plesk db "UPDATE domains SET webspace_status = 0 WHERE name = 'example.com';"

Git (on-server operations)

# Set Git identity:
git config --global user.email "user@example.com"
git config --global user.name "Username"

# Stage all changes in a Plesk-managed repo:
git --git-dir ./git/repo.git --work-tree ./httpdocs add --all

# Push using a specific SSH key:
git -c core.sshCommand="ssh -i ./.ssh/id_rsa_key"   --git-dir ./git/repo.git --work-tree ./httpdocs push

Package and License Management

# Rebuild Plesk package dependencies:
plesk sbin packagemng -sdf

# Refresh Plesk license:
plesk bin license --update

Notes

• Run plesk help to list all available Plesk CLI commands.
• Most plesk sbin commands require root; most plesk bin commands can run as the Plesk admin user.

When a domain remains disabled in Plesk even after being re-enabled through the UI — typically after a migration or manual database edit — you can restore it directly via the Plesk database.

Prerequisites

• Root SSH access
• Access to the Plesk psa database

Steps

1. Check the current domain status:

plesk db "SELECT name, status, webspace_status FROM domains WHERE name = 'example.com';"

A non-zero value in status or webspace_status means the domain is disabled.

2. Re-activate the domain:

plesk db "UPDATE domains SET status = 0 WHERE name = 'example.com';"
plesk db "UPDATE domains SET webspace_status = 0 WHERE name = 'example.com';"

3. Reconfigure the web server to apply the change:

plesk sbin httpdmng --reconfigure-domain example.com

4. If the domain is a subdomain of a disabled parent, re-activate the parent first:

plesk db "UPDATE domains SET status = 0 WHERE name = 'parentdomain.com';"
plesk db "UPDATE domains SET webspace_status = 0 WHERE name = 'parentdomain.com';"

Verify

plesk db "SELECT name, status, webspace_status FROM domains WHERE name = 'example.com';"
curl -I https://example.com/
# Expected: HTTP/1.1 200 OK

Notes

• This issue commonly occurs when the main domain's status is edited manually in the database while the subscription is in a partially disabled state.
• Always use plesk db rather than direct MySQL access to run Plesk database queries — it handles authentication automatically.