WordPress Multisite με nginx και PHP-FPM σε RHEL 9 και 10

p

Το WordPress Multisite τρέχει πολλά sites από μία εγκατάσταση WordPress: ένας κώδικας, ένα σύνολο plugins και themes για ενημέρωση, μία βάση δεδομένων, και ένας network admin που τα ελέγχει όλα. Το πρόβλημα είναι ότι σχεδόν κάθε οδηγός online είναι γραμμένος για Debian ή Ubuntu, με διαδρομές και πακέτα που δεν υπάρχουν στο Red Hat Enterprise Linux. Αυτός ο οδηγός χτίζει ολόκληρο το stack σε RHEL 9 και 10, και δουλεύει το ίδιο σε Oracle Linux, AlmaLinux και Rocky Linux.

Σε όλο τον οδηγό, αντικαταστήστε το example.com με το domain σας και τρέξτε τις εντολές ως root.

h2: Subdirectory ή subdomain;

Τα δίκτυα subdirectory δίνουν σε κάθε site μια διαδρομή: example.com/shop/, example.com/blog/. Ένα όνομα DNS και ένα συνηθισμένο πιστοποιητικό αρκούν. Το nginx χρειάζεται λίγους κανόνες rewrite ώστε κάθε site να φτάνει τα κοινά αρχεία wp-admin, wp-includes και wp-content.
Τα δίκτυα subdomain δίνουν σε κάθε site ένα hostname: shop.example.com. Χρειάζεστε wildcard εγγραφή DNS (*.example.com) και wildcard πιστοποιητικό, αλλά το nginx δεν χρειάζεται ειδικά rewrites.

Το WordPress προσφέρει την επιλογή subdirectory μόνο σε φρέσκια εγκατάσταση, γιατί σε υπάρχον site οι διαδρομές μπορεί να συγκρουστούν με τα permalinks των άρθρων. Αποφασίστε πριν ξεκινήσετε.

h2: Βήμα 1: Εγκαταστήστε τα πακέτα

h3: RHEL 10

Το RHEL 10 δεν έχει module streams. Τα πακέτα nginx, PHP και MariaDB στο AppStream εγκαθίστανται απευθείας:

dnf install nginx php-fpm php-cli php-mysqlnd php-gd php-intl php-mbstring php-xml php-opcache php-pecl-zip mariadb-server

h3: RHEL 9 με module streams του AppStream

Το RHEL 9 έρχεται με προεπιλεγμένα PHP και nginx, συν νεότερες εκδόσεις ως module streams. Δείτε τη λίστα, και μετά ενεργοποιήστε το νεότερο stream που δείχνει η λίστα (τα ονόματα stream παρακάτω είναι παραδείγματα):

dnf module list php nginx
dnf module reset php nginx
dnf module enable php:8.2 nginx:1.24
dnf install nginx php-fpm php-cli php-mysqlnd php-gd php-intl php-mbstring php-xml php-opcache php-pecl-zip mariadb-server

h3: RHEL 9 με το αποθετήριο Remi

Αν χρειάζεστε έναν κλάδο PHP που το AppStream δεν προσφέρει, το αποθετήριο Remi τον παρέχει ως module streams. Το Remi εξαρτάται από το EPEL, που στο RHEL χρειάζεται το αποθετήριο CodeReady Builder (σε AlmaLinux και Rocky Linux χρησιμοποιήστε dnf config-manager --set-enabled crb αντί για τη γραμμή subscription-manager):

subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms
dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
dnf install https://rpms.remirepo.net/enterprise/remi-release-9.rpm
dnf module reset php
dnf module enable php:remi-8.3
dnf install nginx php-fpm php-cli php-mysqlnd php-gd php-intl php-mbstring php-xml php-opcache php-pecl-zip mariadb-server

Τα module streams του Remi αντικαθιστούν τα βασικά πακέτα PHP, οπότε κάθε διαδρομή σε αυτόν τον οδηγό μένει ίδια. Για RHEL 10, χρησιμοποιήστε τον οδηγό ρύθμισης του Remi στο rpms.remirepo.net, που δίνει τις αντίστοιχες εντολές για εκείνη την έκδοση.

Θα θέλετε επίσης τα εργαλεία διαχείρισης SELinux για το Βήμα 5:

dnf install policycoreutils-python-utils

h2: Βήμα 2: Ρυθμίστε το PHP-FPM pool

Το πακέτο php-fpm του RHEL τρέχει το προεπιλεγμένο pool του ως χρήστης apache, γιατί είναι στημένο για httpd. Με nginx το τρέχουμε ως nginx. Επεξεργαστείτε το /etc/php-fpm.d/www.conf και ορίστε αυτές τις γραμμές (υπάρχουν ήδη, αλλάξτε τις τιμές):

user = nginx
group = nginx
listen = /run/php-fpm/www.sock
listen.acl_users = nginx

pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

php_value[upload_max_filesize] = 64M
php_value[post_max_size] = 64M
php_value[memory_limit] = 256M

Διαστασιολογήστε το pm.max_children με βάση τη RAM σας: μετρήστε τη μνήμη που χρησιμοποιεί ένας μέσος PHP worker υπό πραγματική κίνηση, και βεβαιωθείτε ότι ο μέγιστος αριθμός workers επί αυτή την τιμή χωρά στη μνήμη με περιθώριο για τη βάση δεδομένων και την page cache.

h3: Δώστε στο nginx τους καταλόγους session και log της PHP

Το πακέτο δημιουργεί τα /var/lib/php/session, /var/lib/php/opcache και /var/lib/php/wsdlcache με ομάδα apache, και το /var/log/php-fpm με ιδιοκτήτη apache. Ένα pool που τρέχει ως nginx δεν μπορεί να γράψει εκεί, και τα logins αποτυγχάνουν με μπερδεμένους τρόπους. Οι ενημερώσεις πακέτων επαναφέρουν αυτές τις ιδιοκτησίες, οπότε ορίστε τις με systemd-tmpfiles και επανεφαρμόστε τις κάθε φορά που ξεκινά το PHP-FPM. Δημιουργήστε το /etc/tmpfiles.d/php-fpm-nginx.conf:

z /var/lib/php/session   0770 root  nginx -
z /var/lib/php/opcache   0770 root  nginx -
z /var/lib/php/wsdlcache 0770 root  nginx -
z /var/log/php-fpm       0770 nginx root  -

Μετά δημιουργήστε το /etc/systemd/system/php-fpm.service.d/10-nginx-perms.conf:

[Service]
ExecStartPre=/usr/bin/systemd-tmpfiles --create /etc/tmpfiles.d/php-fpm-nginx.conf

systemctl daemon-reload
systemctl enable --now php-fpm
ls -ld /var/lib/php/session /var/log/php-fpm
ls -l /run/php-fpm/www.sock

h2: Βήμα 3: Δημιουργήστε τη βάση δεδομένων

systemctl enable --now mariadb
mariadb-secure-installation
mariadb

CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wordpress'@'localhost' IDENTIFIED BY 'use-a-long-random-password';
GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Με τη βάση δεδομένων στον ίδιο server και το DB_HOST ορισμένο σε localhost, η PHP συνδέεται μέσω του τοπικού socket και το SELinux δεν χρειάζεται αλλαγή. Αν η βάση δεδομένων τρέχει σε άλλον server, δείτε το Βήμα 5.

h2: Βήμα 4: Εγκαταστήστε το WordPress

cd /var/www
curl -O https://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz
mv wordpress example.com
cd example.com
cp wp-config-sample.php wp-config.php
mkdir -p wp-content/uploads wp-content/upgrade
chown -R nginx:nginx /var/www/example.com
find /var/www/example.com -type d -exec chmod 750 {} +
find /var/www/example.com -type f -exec chmod 640 {} +

Επεξεργαστείτε το wp-config.php: ορίστε DB_NAME, DB_USER, DB_PASSWORD και DB_HOST, και αντικαταστήστε τα placeholder keys και salts με φρέσκα από την υπηρεσία secret key του WordPress. Πάνω από τη γραμμή που λέει «That's all, stop editing!», προσθέστε:

define( 'FORCE_SSL_ADMIN', true );
define( 'WP_ALLOW_MULTISITE', true );

Προσθέστε μόνο το WP_ALLOW_MULTISITE προς το παρόν. Οι σταθερές του δικτύου έρχονται αργότερα, από το ίδιο το WordPress.

Εγκαταστήστε και το WP-CLI. Είναι ο ασφαλέστερος τρόπος να ενημερώνετε μια θωρακισμένη εγκατάσταση και κάνει εύκολους τους ελέγχους στο τέλος:

curl -o /usr/local/bin/wp https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod 755 /usr/local/bin/wp
wp --info

h2: Βήμα 5: Ετικέτες και booleans του SELinux

Κρατήστε το SELinux σε enforcing. Το /var/www έχει ήδη την ετικέτα httpd_sys_content_t, που το nginx και το PHP-FPM μπορούν να διαβάσουν αλλά όχι να γράψουν. Αυτό θέλετε για τον κώδικα του WordPress. Μόνο οι κατάλογοι στους οποίους το WordPress πρέπει να γράφει παίρνουν την ετικέτα ανάγνωσης και εγγραφής:

semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/example.com/wp-content/uploads(/.*)?"
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/example.com/wp-content/upgrade(/.*)?"
restorecon -Rv /var/www/example.com
ls -Zd /var/www/example.com/wp-content/uploads

Το Multisite κρατά τα media κάθε site κάτω από το wp-content/uploads/sites/<id>/, οπότε ο ένας κανόνας καλύπτει ολόκληρο το δίκτυο. Αν χρησιμοποιείτε plugin caching που γράφει στο wp-content/cache, δώστε σε εκείνον τον κατάλογο την ίδια ετικέτα.

Μετά ενεργοποιήστε μόνο τα booleans που χρειάζεστε:

# WordPress fetches updates, talks to APIs and runs wp-cron over HTTP
setsebool -P httpd_can_network_connect on

# only if the database is on another server
setsebool -P httpd_can_network_connect_db on

# only if WordPress sends mail through the local MTA or an SMTP server
setsebool -P httpd_can_sendmail on

Επειδή ο ίδιος ο κώδικας είναι μόνο για ανάγνωση από την PHP, η εγκατάσταση plugins ή η ενημέρωση του WordPress από το dashboard θα απορρίπτεται. Κάντε το με WP-CLI αντ' αυτού, ως ο ιδιοκτήτης του site, κάτι που σας δίνει και καθαρό ιστορικό του τι άλλαξε:

sudo -u nginx wp --path=/var/www/example.com core update
sudo -u nginx wp --path=/var/www/example.com plugin update --all --network

Αν προτιμάτε ενημερώσεις από το dashboard, δώστε και στα wp-content/plugins και wp-content/themes την ετικέτα httpd_sys_rw_content_t, αποδεχόμενοι ότι η PHP μπορεί τότε να γράφει κώδικα.

h2: Βήμα 6: Ανοίξτε το firewall

firewall-cmd --permanent --add-service=http --add-service=https
firewall-cmd --reload
firewall-cmd --list-services

h2: Βήμα 7: Πάρτε ένα πιστοποιητικό TLS

Στο RHEL, η ρύθμιση των sites του nginx ζει στο /etc/nginx/conf.d/: κάθε αρχείο *.conf εκεί φορτώνεται. Δεν υπάρχει sites-available ή sites-enabled. Ξεκινήστε με ένα απλό server block HTTP ώστε να μπορεί να εκδοθεί το πιστοποιητικό, στο /etc/nginx/conf.d/example.com.conf:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/example.com;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

nginx -t
systemctl enable --now nginx

h3: Δίκτυο subdirectory: ένα κανονικό πιστοποιητικό

Το certbot βρίσκεται στο EPEL. Στο RHEL, ενεργοποιήστε το CodeReady Builder και εγκαταστήστε το πακέτο EPEL release για τη δική σας κύρια έκδοση (σε AlmaLinux και Rocky Linux ενεργοποιήστε το crb με dnf config-manager αντ' αυτού. Σε Oracle Linux εγκαταστήστε oracle-epel-release-el9 ή oracle-epel-release-el10):

# RHEL 9
subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms
dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm

# RHEL 10
subscription-manager repos --enable codeready-builder-for-rhel-10-$(arch)-rpms
dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm

dnf install certbot
certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com --deploy-hook "systemctl reload nginx"
systemctl enable --now certbot-renew.timer

h3: Δίκτυο subdomain: ένα wildcard πιστοποιητικό

Τα wildcard πιστοποιητικά επικυρώνονται μόνο μέσω DNS. Χρησιμοποιήστε το plugin DNS του certbot για τον πάροχο DNS σας ώστε οι ανανεώσεις να τρέχουν χωρίς επίβλεψη (για παράδειγμα python3-certbot-dns-rfc2136 για έναν server που δέχεται δυναμικές ενημερώσεις), ή εγκαταστήστε ένα wildcard πιστοποιητικό από τη δική σας αρχή πιστοποίησης. Τα πιστοποιητικά που διαχειρίζεστε μόνοι σας ανήκουν στο /etc/pki/tls/certs/ και τα κλειδιά στο /etc/pki/tls/private/, όπου το SELinux επιτρέπει ήδη στο nginx να τα διαβάζει.

certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini -d example.com -d "*.example.com" --deploy-hook "systemctl reload nginx"

Για δίκτυο subdomain, αλλάξτε επίσης το server_name στο παραπάνω HTTP block σε example.com *.example.com.

h2: Βήμα 8: Η ρύθμιση του nginx

Μόλις υπάρξει το πιστοποιητικό, αντικαταστήστε το /etc/nginx/conf.d/example.com.conf με την πλήρη ρύθμιση για τον τύπο δικτύου σας. Τα regex locations ελέγχονται με τη σειρά που εμφανίζονται, οπότε κρατήστε τους κανόνες deny πάνω από το block της PHP.

h3: Δίκτυο subdirectory

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/example.com;
    }

    location / {
        return 301 https://example.com$request_uri;
    }
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com;

    root  /var/www/example.com;
    index index.php;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         PROFILE=SYSTEM;
    ssl_prefer_server_ciphers on;
    ssl_session_cache   shared:SSL:10m;

    client_max_body_size 64m;

    access_log /var/log/nginx/example.com.access.log main;
    error_log  /var/log/nginx/example.com.error.log;

    # Multisite subdirectory rules: map /site/wp-admin, /site/wp-includes,
    # /site/wp-content and /site/*.php to the shared WordPress files.
    if (!-e $request_filename) {
        rewrite /wp-admin$ $scheme://$host$uri/ permanent;
        rewrite ^(/[^/]+)?(/wp-.*) $2 last;
        rewrite ^(/[^/]+)?(/.*\.php) $2 last;
    }

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    # never serve hidden files or run PHP from uploads
    location ~ /\.(?!well-known) {
        deny all;
    }
    location ~* ^/wp-content/uploads/.*\.php$ {
        deny all;
    }

    location ~* \.(?:css|js|gif|ico|jpe?g|png|svg|webp|avif|woff2?)$ {
        expires 30d;
        access_log off;
        try_files $uri =404;
    }

    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_index index.php;
        fastcgi_pass unix:/run/php-fpm/www.sock;
        fastcgi_read_timeout 300;
    }
}

h3: Δίκτυο subdomain

Η ίδια δομή χωρίς το block των rewrites, με wildcard server_name και το wildcard πιστοποιητικό. Ο τυπικός κανόνας try_files είναι ό,τι χρειάζεται το WordPress, γιατί κάθε site ξεχωρίζει από το hostname του:

server {
    listen 80;
    listen [::]:80;
    server_name example.com *.example.com;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/example.com;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com *.example.com;

    root  /var/www/example.com;
    index index.php;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         PROFILE=SYSTEM;
    ssl_prefer_server_ciphers on;
    ssl_session_cache   shared:SSL:10m;

    client_max_body_size 64m;

    access_log /var/log/nginx/example.com.access.log main;
    error_log  /var/log/nginx/example.com.error.log;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ /\.(?!well-known) {
        deny all;
    }
    location ~* ^/wp-content/uploads/.*\.php$ {
        deny all;
    }

    location ~* \.(?:css|js|gif|ico|jpe?g|png|svg|webp|avif|woff2?)$ {
        expires 30d;
        access_log off;
        try_files $uri =404;
    }

    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_index index.php;
        fastcgi_pass unix:/run/php-fpm/www.sock;
        fastcgi_read_timeout 300;
    }
}

Λίγες σημειώσεις για αυτά τα αρχεία:

Το ssl_ciphers PROFILE=SYSTEM παραδίδει την επιλογή ciphers στη συστημική πολιτική κρυπτογραφίας του RHEL, οπότε ο server ακολουθεί το update-crypto-policies αντί για μια χειροποίητη λίστα ciphers.
Σε nginx 1.25.1 και νεότερο, το listen ... http2 λειτουργεί ακόμα αλλά τυπώνει προειδοποίηση κατάργησης. Μπορείτε να γράψετε listen 443 ssl; συν http2 on; αντ' αυτού. Οι παλιότερες εκδόσεις nginx στο RHEL 9 χρειάζονται τη μορφή που δείχνουμε.
Το try_files $uri =404 στο block της PHP εμποδίζει το nginx να περνά στο PHP-FPM αιτήματα για αρχεία PHP που δεν υπάρχουν.
Το log format main ορίζεται στο αρχικό /etc/nginx/nginx.conf. Το προεπιλεγμένο server block σε εκείνο το αρχείο συνεχίζει να απαντά σε αιτήματα για άγνωστα hostnames. Το δικό σας αναλαμβάνει το example.com.

nginx -t && systemctl reload nginx

h2: Βήμα 9: Εγκαταστήστε το WordPress και ενεργοποιήστε το δίκτυο

Ανοίξτε το https://example.com/ και ολοκληρώστε τον κανονικό installer του WordPress, ή κάντε το από το shell:

sudo -u nginx wp --path=/var/www/example.com core install --url=https://example.com --title="Example Network" --admin_user=netadmin --admin_email=admin@example.com --prompt=admin_password

Συνδεθείτε, απενεργοποιήστε τυχόν plugins, και μετά πηγαίνετε στο Tools, Network Setup. Επειδή το WP_ALLOW_MULTISITE είναι ορισμένο, το WordPress προσφέρει την επιλογή subdomains ή subdirectories (σε φρέσκια εγκατάσταση). Επιλέξτε, πατήστε Install, και το WordPress δείχνει ένα block σταθερών για προσθήκη στο wp-config.php, πάνω από τη γραμμή «stop editing». Για δίκτυο subdirectory μοιάζει έτσι:

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Για δίκτυο subdomain, το SUBDOMAIN_INSTALL είναι true. Αντιγράψτε το block που σας δίνει το WordPress και όχι αυτό το παράδειγμα. Το WordPress δείχνει επίσης κανόνες .htaccess. Αυτοί είναι για Apache και δεν κάνουν τίποτα στο nginx, γιατί η ρύθμιση nginx του Βήματος 8 κάνει ήδη αυτή τη δουλειά. Συνδεθείτε ξανά και εμφανίζεται το μενού My Sites, Network Admin.

Η ίδια μετατροπή γίνεται με WP-CLI σε ένα βήμα: sudo -u nginx wp --path=/var/www/example.com core multisite-convert, προσθέτοντας --subdomains για δίκτυο subdomain. Γράφει τις σταθερές στο wp-config.php για εσάς. Αφαιρέστε τη γραμμή WP_ALLOW_MULTISITE μετά αν θέλετε, δεν χρειάζεται πια.

h2: Βήμα 10: Επαληθεύστε

Δημιουργήστε ένα δοκιμαστικό site και ελέγξτε ότι κάθε κομμάτι της διαδρομής δουλεύει:

cd /var/www/example.com

# subdirectory network
sudo -u nginx wp site create --slug=test --title="Test site" --email=admin@example.com
# subdomain network: the same command creates test.example.com

sudo -u nginx wp site list

# home page of the new site: expect 200
curl -sI https://example.com/test/ | head -1

# shared assets through the site path: expect 200
curl -sI https://example.com/test/wp-includes/js/jquery/jquery.min.js | head -1

# admin without a trailing slash redirects: expect 301 to /test/wp-admin/
curl -sI https://example.com/test/wp-admin | grep -iE "^HTTP|^location"

# login page: expect 200
curl -sI https://example.com/test/wp-login.php | head -1

# PHP in uploads is refused: expect 403
curl -sI https://example.com/wp-content/uploads/x.php | head -1

# HTTP goes to HTTPS: expect 301
curl -sI http://example.com/ | head -1

Για δίκτυο subdomain χρησιμοποιήστε το https://test.example.com/ στους ίδιους ελέγχους. Μετά ανεβάστε μια εικόνα στη βιβλιοθήκη media του δοκιμαστικού site και επιβεβαιώστε ότι καταλήγει στο wp-content/uploads/sites/2/. Αν κάτι αποτύχει, εδώ κοιτάτε:

tail -50 /var/log/nginx/example.com.error.log
tail -50 /var/log/php-fpm/www-error.log
ausearch -m AVC -ts recent -i
journalctl -u php-fpm -u nginx --since "15 min ago"

Ένα «Permission denied» στο log της PHP μαζί με μια εγγραφή AVC δείχνει σε ετικέτα ή boolean του SELinux που λείπει (Βήμα 5). Ένα 502 από το nginx σημαίνει ότι δεν μπόρεσε να φτάσει το socket του PHP-FPM: ελέγξτε ότι το php-fpm τρέχει και ότι το listen.acl_users περιλαμβάνει το nginx. Το να σας στέλνει πίσω στη σελίδα login μετά από σωστό κωδικό συνήθως σημαίνει ότι ο κατάλογος session δεν είναι εγγράψιμος από τον χρήστη του pool (Βήμα 2).

h2: Διατηρώντας το υγιές

Ενημερώνετε με dnf upgrade για το stack και με WP-CLI για το WordPress, και ελέγχετε το site μετά με τα παραπάνω curl tests.
Κρατάτε backup τη βάση δεδομένων και το wp-content/uploads μαζί, από ξεχωριστό backup server που τραβά τα δεδομένα, ώστε ο web server να μην κρατά διαπιστευτήρια για τα backups.
Προσθέστε page cache (nginx FastCGI cache ή plugin caching) μόλις το δίκτυο αποκτήσει πραγματική κίνηση, και ορίστε request_slowlog_timeout στο pool για να βλέπετε ποια αιτήματα είναι αργά.

p

Οι μηχανικοί της EuroVPS χτίζουν και λειτουργούν stacks WordPress Multisite σαν αυτό σε nginx και PHP-FPM για πελάτες στους managed servers μας.

Ρύθμιση WordPress Multisite με nginx και PHP-FPM σε RHEL 9 και 10

p