تثبيت حزمة LEMP على Ubuntu 24.04: Nginx وMariaDB وPHP-FPM

LEMP اختصار لـ Linux وNginx (يُنطق "إنجن إكس") وMariaDB أو MySQL وPHP. هذه الحزمة تشغّل معظم تطبيقات PHP: ووردبريس وLaravel ولوحات الفوترة والبرمجيات الخاصة. في هذا الدليل نبني الحزمة على خادم VPS جديد بنظام Ubuntu 24.04 باستخدام الحزم الرسمية للتوزيعة، ثم نشرح الأخطاء التي يواجهها الجميع تقريبًا في اليوم الأول.
تحتاج إلى خادم VPS بصلاحيات root أو sudo، ونطاق يشير سجل A الخاص به إلى عنوان IP الخادم، وحوالي 20 دقيقة. نفترض أن النظام مثبت حديثًا. استبدل example.com بنطاقك داخل ملفات الإعداد.
ماذا يوفر Ubuntu 24.04
حزم التوزيعة تجعل الصيانة بسيطة: أمر apt upgrade واحد يحدّث الحزمة كاملة، وتصل التصحيحات الأمنية عبر Ubuntu نفسه. الإصدارات الافتراضية في Ubuntu 24.04 هي:
| المكوّن | الحزمة | الإصدار في 24.04 |
|---|---|---|
| Nginx | nginx | 1.24 |
| MariaDB | mariadb-server | 10.11 (LTS) |
| PHP | php-fpm | 8.3 |
إذا احتاج تطبيقك إصدار PHP مختلفًا فهناك مستودعات خارجية، لكن كل مستودع مصدر إضافي عليك أن تثق به وتتابعه. ابدأ بالإصدارات الافتراضية ما لم يكن لديك سبب واضح لغير ذلك.
الخطوة 1: تحديث النظام
sudo apt update && sudo apt upgrade -y
إذا ثبّت التحديث نواة جديدة فأعد تشغيل الخادم قبل المتابعة. اكتشاف المشكلات أسهل على نظام نظيف ومحدّث.
الخطوة 2: تثبيت Nginx وفتح الجدار الناري
sudo apt install -y nginx
sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status
اسمح بـ OpenSSH قبل تفعيل UFW. إذا فعّلت الجدار الناري أولًا فقد تغلق الباب على نفسك ولا تستطيع الدخول إلى خادمك. ملف التعريف Nginx Full يفتح المنفذين 80 و443.
افتح عنوان IP الخادم في المتصفح. ظهور صفحة "Welcome to nginx!" يعني أن Nginx يعمل. إذا لم تظهر فراجع systemctl status nginx وتأكد من السماح بالمنفذ 80.
الخطوة 3: تثبيت MariaDB وتأمينه
sudo apt install -y mariadb-server
sudo mariadb-secure-installation
في Ubuntu يسجّل حساب root في MariaDB الدخول عبر Unix socket، أي أن مستخدم root في النظام (أو sudo) وحده يستطيع الدخول كمدير لقاعدة البيانات دون كلمة مرور. هذا إعداد افتراضي آمن فاحتفظ به: أجب بـ n على سؤال التحويل إلى unix_socket (فهو مفعّل أصلًا) وعلى تغيير كلمة مرور root. وأجب بـ Y على حذف المستخدمين المجهولين، ومنع دخول root عن بُعد، وحذف قاعدة الاختبار، وإعادة تحميل الصلاحيات.
لا تجعل تطبيقك يتصل أبدًا بحساب root. أنشئ قاعدة بيانات ومستخدمًا مخصصين:
sudo mariadb
CREATE DATABASE appdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'use-a-long-random-password';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;
ترميز utf8mb4 يخزّن نطاق Unicode كاملًا، بما فيه النصوص العربية والرموز التعبيرية. أما ترميز utf8 القديم في MariaDB فهو جزء من 3 بايت وقد يقطع بعض الحروف. وكلمة 'localhost' تعني أن المستخدم لا يتصل إلا من الخادم نفسه. يستمع MariaDB في Ubuntu افتراضيًا على 127.0.0.1، فلا يكون المنفذ 3306 مكشوفًا للإنترنت. أبقِه كذلك ما لم يحتج خادم آخر إلى الوصول.
الخطوة 4: تثبيت PHP-FPM
sudo apt install -y php-fpm php-mysql php-cli php-curl php-mbstring php-xml php-zip php-gd php-intl
php -v
systemctl status php8.3-fpm
لا تثبّت الحزمة العامة php ولا libapache2-mod-php. في Ubuntu قد تجلب حزمة php معها Apache، فينافس Nginx على المنفذ 80.
يشغّل PHP-FPM لغة PHP كمجموعة مستقلة من العمليات العاملة (workers). لا ينفّذ Nginx كود PHP بنفسه، بل يمرّر طلبات PHP إلى FPM عبر Unix socket، وهو افتراضيًا /run/php/php8.3-fpm.sock. هذا الفصل هو سبب قدرة LEMP على خدمة عدد كبير من الزوار بذاكرة معتدلة: يقدّم Nginx الصور وملفات CSS وJavaScript مباشرة، ولا تستهلك عملية PHP إلا طلبات PHP فقط.
الخطوة 5: إنشاء الموقع وكتلة الخادم (server block)
sudo mkdir -p /var/www/example.com/public
sudo chown -R $USER:www-data /var/www/example.com
sudo nano /etc/nginx/sites-available/example.com
الصق هذا الإعداد وعدّل النطاق والمسارات:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
root /var/www/example.com/public;
index index.php index.html;
client_max_body_size 64M;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}
location ~ /\.(?!well-known) {
deny all;
}
}
وظيفة كل جزء:
try_files يقدّم الملف إن كان موجودًا، وإلا يرسل الطلب إلى
index.php. يحتاج ووردبريس وLaravel هذا للروابط النظيفة.snippets/fastcgi-php.conf يأتي مع Nginx في Ubuntu، ويحدد مسار السكربت لـ PHP ويعيد خطأ 404 لملفات PHP غير الموجودة.
fastcgi_pass يجب أن يطابق مسار socket الخاص بـ FPM تمامًا. رقم إصدار خاطئ هنا هو السبب الأكثر شيوعًا لخطأ 502.
الكتلة الأخيرة تمنع الوصول إلى الملفات المخفية مثل
.envو.git، مع السماح بمجلد.well-knownاللازم للتحقق من شهادات SSL.
فعّل الموقع، واحذف الموقع الافتراضي، ثم اختبر الإعداد وأعد التحميل:
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo rm /etc/nginx/sites-enabled/default
sudo nginx -t
sudo systemctl reload nginx
شغّل nginx -t دائمًا قبل إعادة التحميل. إعادة التحميل بإعداد معطوب تُرفض، لكن الاختبار يخبرك أي سطر فيه الخطأ. كما أن reload يُبقي الاتصالات القائمة مفتوحة بخلاف restart.
الخطوة 6: اختبار PHP
echo '<?php phpinfo();' | sudo tee /var/www/example.com/public/info.php
# after checking it in the browser:
sudo rm /var/www/example.com/public/info.php
افتح http://example.com/info.php. يجب أن تظهر صفحة معلومات PHP وفيها "Server API: FPM/FastCGI". احذف الملف فورًا بعد ذلك، لأنه يكشف مسارات وإصدارات وإعدادات تفيد أي مهاجم.
حل الأخطاء الشائعة
خطأ 502 Bad Gateway
لم يتمكن Nginx من الوصول إلى PHP-FPM. اقرأ سجل الأخطاء أولًا، فهو يذكر السبب غالبًا:
sudo tail -n 20 /var/log/nginx/error.log
# connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)
systemctl status php8.3-fpm
ls -l /run/php/
إما أن FPM لا يعمل، أو أن مسار socket في fastcgi_pass لا يطابق الملف الموجود في /run/php/. يحدث هذا كثيرًا بعد نسخ إعداد مكتوب لإصدار PHP أقدم.
رسالة "File not found." أو "Primary script unknown"
استلم FPM الطلب لكنه لم يجد السكربت. إما أن مسار root خاطئ، أو الملف غير موجود، أو أن المستخدم www-data لا يملك صلاحية قراءته. الأمر namei -l /var/www/example.com/public/index.php يعرض صلاحيات كل مجلد في المسار.
المتصفح يحمّل ملف PHP بدل تشغيله
لم يطابق الطلب كتلة PHP، فقدّم Nginx الملف كبيانات عادية. تأكد أن موقعك مفعّل وأنه لا توجد كتلة خادم أخرى تجيب على النطاق نفسه: sudo nginx -T | grep server_name.
خطأ 413 Request Entity Too Large
يرفض Nginx افتراضيًا الطلبات التي يزيد حجمها على 1 ميجابايت. الإعداد client_max_body_size في كتلة الخادم يرفع هذا الحد. ولدى PHP حدوده الخاصة: upload_max_filesize وpost_max_size في الملف /etc/php/8.3/fpm/php.ini. اضبط القيم الثلاث على الرقم نفسه، وأعد تشغيل php8.3-fpm بعد تعديل php.ini.
اضبط عدد عمليات PHP-FPM حسب الذاكرة
المجموعة الافتراضية تسمح بخمس عمليات PHP فقط. مع زيارات حقيقية ستظهر رسالة "server reached pm.max_children setting (5), consider raising it" في /var/log/php8.3-fpm.log وينتظر الزوار. وإذا رفعت الرقم أكثر من اللازم تستنفد العمليات الذاكرة ويبدأ النظام بقتل العمليات، وغالبًا يكون MariaDB أولها.
قاعدة تقريبية: max_children = الذاكرة المتاحة لـ PHP ÷ متوسط حجم العملية الواحدة. قِس متوسط حجم العملية تحت حمل عادي:
ps -o rss= -C php-fpm8.3 | awk '{s+=$1; n++} END {print s/n/1024 " MB"}'
مثال: على خادم بذاكرة 2 جيجابايت قد يحجز النظام وMariaDB حوالي 800 ميجابايت، فيبقى حوالي 1.2 جيجابايت. إذا كانت العملية 60 ميجابايت فهذا يعني 20 عملية؛ اترك هامشًا وابدأ بـ 15. ثم راقب الذاكرة بالأمر free -h في أوقات الذروة وعدّل.
; /etc/php/8.3/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 15
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500
sudo systemctl restart php8.3-fpm
sudo grep max_children /var/log/php8.3-fpm.log
الإعداد pm.max_requests يعيد تشغيل كل عملية بعد 500 طلب، وهذا يحدّ من تسرب الذاكرة البطيء في الإضافات. وإضافة OPcache مفعّلة افتراضيًا في Ubuntu وتخزّن كود PHP المترجم مؤقتًا؛ اتركها مفعّلة.
الخطوات التالية
HTTPS: شهادات Let's Encrypt مجانية، وأداة Certbot تعدّل إعداد Nginx نيابة عنك:
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com
النسخ الاحتياطي: صدّر قاعدة البيانات بالأمر
mariadb-dumpبشكل مجدول، وانسخ الملفات إلى خارج الخادم.التحديثات: فعّل
unattended-upgradesللتصحيحات الأمنية، وراجع الترقيات الكبيرة بنفسك.
شغّلها على IM HOST
تحتاج حزمة LEMP إلى صلاحيات root كاملة وموارد يمكن توقعها. تبدأ خطط Linux VPS من IM HOST من 5 دولارات شهريًا مع صلاحيات root كاملة على KVM، وعنوان IPv4 مخصص مع IPv6 /64، وحماية من هجمات DDoS. وإذا أردت معالجًا وذاكرة مخصصين مع نسخ احتياطي تلقائي كل 3 أيام فاطّلع على Cloud VPS. لديك موقع قائم؟ خدمة النقل المجانية تنقل الملفات وقواعد البيانات والبريد دون توقف. لا توجد رسوم إعداد، ومهندسو الدعم متاحون على مدار الساعة طوال أيام الأسبوع، وكل خطة تشمل ضمان استرداد المبلغ خلال 30 يومًا.
المزيد من مدونتنا
اكتشف المزيد من الأدلة العملية ورؤى الخدمات من فريق IM Host.
عرض كل المقالات