كيف تقوم بالفحص عن المشاكل الشائعة للمواقع على خادوم لينكس

يُواجه كلّ شخص في وقتٍ ما مشاكل مع خادوم الوِيب Web Server، سيُساعدك تَعلّمك أين تبحث عندما تواجه مشكلة ما وأيّ العناصر هي التي من المحتمل تمّ تخريبها على إصلاح هذه المشاكل (troubleshoot) بسرعة وبإحباط أقل.

سنناقش في هذا الدرس كيف نقوم باستكشاف هذه المشاكل بحيث تستطيع الإبقاء على موقعك يعمل بشكل طبيعي.

ما هي أنواع المشاكل النموذجية التي من المحتمل أن تواجهها ؟

قد تنشأ في بعض الأحيان بعض المشاكل غير النموذجية إلّا أنّ الغالبية العظمى من المشاكل التي ستصادفها أثناء محاولتك لجعل موقعك يعمل بشكل صحيح تقع ضمن مجموعة يُمكن التنبُّؤ بها كثيرًا. سنقوم بالمرور على هذا بشكلٍ مُفصّل في الأقسام اللاحقة ولكن حاليًّا هذه قائمة من الأشياء التي يجب تفحّصها:

• هل تمّ تنصيب خادوم الوِيب لديك؟
• هل خادوم الوِيب قيد التشغيل الآن؟
• هل الصياغة في ملفات ضبط  خادوم الوِيب configuration files صحيحة؟
• هل المنافذ ports التي قمت بضبطها مفتوحة (لم يتم حجبها من الجدار الناري)؟
• هل تقودك إعدادات الـ DNS إلى المكان الصحيح؟
• هل يشير جذر المستند document root إلى موقع ملفاتك؟
• هل يقوم خادوم الوِيب بتخديم ملفات الفهرس index files الصحيحة؟
• هل أذونات permissions وملكية الملف ownership وبُنى المجلد صحيحة؟
• هل قُمتَ بمنع الوصول عن طريق ملفات الضبط؟
• إن كنتَ تملك قاعدة بيانات database في الخلفيّة backend فهل هي تعمل؟
• هل يستطيع موقعك الاتصال مع قاعدة البيانات بنجاح؟

هذه هي بعض أشيع المشاكل التي يُصادفها مُدراء النُّظم عندما لا يعمل الموقع بشكلٍ صحيح، يُمكن عادةً تضييق المشكلة المحددة بإلقاء نظرة على ملفات السّجل Log Files للمكونات المختلفة وعن طريق الرجوع إلى صفحات الخطأ التي تظهر في متصفحك. سنقوم بالمرور في الأسفل على كل من هذه الحالات لكي تستطيع التحقق من أنّ الخدمات مضبوطة بشكلٍ صحيح.

التحقق من السّجلات Logs

قبل أن تقوم بتعقُّب مشكلة ما بشكلٍ عشوائي حاول أن تتحقق من سجلات خادوم الوِيب Logs لديك ومن أيّة عناصر مرتبطة بذلك، ستجد هذه السّجلات عادةً في المسار var/log/ في مجلّد فرعي مخصّص للخدمة التي تريدها.

فعلى سبيل المثال إن كنتَ تملك خادوم Apache يعمل على توزيعة Ubuntu فستجد بشكل افتراضي أنّ السّجلات يتمّ الاحتفاظ بها في المسار var/log/apache2/، قُم بالتحقق من الملفات في هذا المجلد لكي ترى ما نوع رسائل الخطأ التي تمّ توليدها، إن كنت تملك قاعدة بيانات تعمل في الخلفيّة وتسبب لك المشاكل فهي على الأغلب تحتفظ بسجلاتها في المسار var/log/ أيضًا.

من الأشياء التي يجب التحقق منها أيضًا أن تتأكد إذا ما كانت العمليّات نفسها تصدر رسائل خطأ عندما تقوم بتشغيل الخدمات، إن كنت تحاول زيارة صفحة وِيب وتلقّيت خطأ فإنّ صفحة الخطأ قد تحتوي على تلميحات عن الخطأ أيضًا (بالرغم من أنّها ليست دقيقة كالسطور في ملفات السّجلات).

استخدم محرّك بحث Search Engine لتحاول إيجاد معلومات متعلقة بالموضوع والتي من الممكن أن تقودك في الاتجاه الصحيح، تساعدك الخطوات القادمة في استكشاف الأخطاء أكثر.

هل تمّ تنصيب خادوم الوِيب لديك؟

إنّ أول شيء تحتاج له لكي تُخدِّم مواقعك بشكل صحيح هو خادوم وِيب. ربّما قام مُعظم الأشخاص فعلًا بتنصيب خادوم قبل الوصول لهذه المرحلة، ولكن في بعض الحالات ربّما تكون أزلت الخادوم عن طريق الخطأ عند تنفيذك لعمليّات على الحزم Packages الأخرى.

إذا كنت تعمل على نظام تشغيل Ubuntu أو Debian وترغب بتنصيب خادوم وِيب Apache تستطيع كتابة ما يلي:

sudo apt-get update
sudo apt-get install apache2

تُدعى عمليّة Apache على هذه الأنظمة بـ apache2.

إن كنت تعمل على نظام تشغيل Ubuntu أو Debian وترغب بتنصيب خادوم وِيب Nginx تستطيع بدلًا من ذلك كتابة:

sudo apt-get update
sudo apt-get install nginx

تُدعى عمليّة Nginx على هذه الأنظمة بـ nginx.

إن كنت تعمل على أنظمة تشغيل CentOS أو Fedora وترغب باستخدام خادوم وِيب Apache فقُم بكتابة التالي وبإمكانك إزالة الأمر "sudo" إن كُنت قد سجّلت الدخول كـ root:

sudo yum install httpd

تُدعى عمليّة Apache على هذه الأنظمة بـ httpd.

إن كنت تعمل على أنظمة تشغيل CentOS أو Fedora وترغب باستخدام خادوم وِيب Nginx تستطيع كتابة الأمر التالي، ومرّة أخرى قم بإزالة الأمر "sudo" إن كُنت قد سجّلت الدخول كـ root:

sudo rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
sudo yum install nginx

تُدعى عمليّة Nginx على هذه الأنظمة بـ nginx.

هل خادوم الوِيب قيد التشغيل الآن؟

بعد أن قمت بالتأكد من أنّ خادومك مُنَصّب بالفعل، فهل هو قيد التشغيل؟

تُوجَد العديد من الطّرق لكي تكتشف إذا ما كانت الخدمة قيد التشغيل أم لا، واحدة من هذه الطرق والتي تعمل على منصّات متعدّدة cross-platform هي استخدام الأمر netstat.

سيُخبِرك هذا الأمر عن جميع العمليّات التي تستخدم منافذ على الخادوم، بإمكاننا بعد ذلك كتابة الأمر grep لإيجاد اسم العملية التي نبحث عنها:

sudo netstat -plunt | grep apache2

tcp6       0      0 :::80           :::*            LISTEN      2000/apache2

يجب عليك تغيير كلمة "apache2" إلى اسم عمليّة خادوم الوِيب الذي لديك، إن ظهر لك سطر كالموجود بالأعلى فهذا يعني أنّ العمليّة قيد التشغيل، أمّا إن لم تحصل على أيّة خَرج فهذا يعني إمّا أنّك قُمت بالاستعلام عن العمليّة الخطأ أو أنّ خادوم الوِيب لديك لا يعمل.

يُمكنك في هذه الحالة بدء تشغيله باستخدام الطريقة المفضّلة لتوزيعتك، فعلى سبيل المثال على Ubuntu تستطيع بدء تشغيل خدمة Apache2 بكتابة:

sudo service apache2 start

وعلى توزيعة CentOS نكتب هذا الأمر:

sudo /etc/init.d/httpd start

إذا تمّ بدء تشغيل خادومك فعندها تستطيع التحقق باستخدام الأمر netstat مرّة أخرى لكي تتأكد من انّ كل شيء يعمل بشكل صحيح.

هل الصّياغة Syntax في ملفات ضبط خادوم الوِيب صحيحة؟ إذا رفض خادوم الوِيب لديك أن يبدأ التشغيل فهذا يشير عادةً إلى أنّ ملفات الضبط تحتاج إلى بعض الانتباه، يتطلّب Apache و Nginx التزامًا صارمًا بتعليمات الصّياغة syntax لكي يتمّ قراءة الملفات بنجاح.

تتواجد ملفات إعدادات الضبط لهذه الخدمات عادةً في المسار etc/  في مجلّد فرعي مُسمّى على اسم العمليّة نفسها.

وبهذا نستطيع الوصول إلى المجلّد الرئيسي لإعدادات ضبط Apache على Ubuntu بكتابة:

cd /etc/apache2

ويمكننا الوصول بطريقة مشابهة إلى مجلّد إعدادات ضبط Apache على CentOS والمُسمّى على اسم تلك العمليّة:

cd /etc/httpd

تكون إعدادت الضبط مُوزّعة على عدّة ملفات، وعندما يفشل بدء الخدمة فإنها ستشير عادةً إلى ملف إعدادات الضبط وإلى السّطر الذي حدثت فيه المشكلة، قُم بالتحقق من هذا الملف بحثًا عن الأخطاء. يُزوّدك كل واحد من خواديم الوِيب هذه بالقدرة على التحقق من صياغة إعدادات الضبط في ملفاتك. إن كُنتَ تستخدم Apache فبإمكانك استخدام الأمر apache2ctl أو apachectl للتحقق من ملفات إعدادات الضبط بحثاً عن أخطاء الصياغة:

apache2ctl configtest
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK

لقد تلقيّنا كما ترى في الأعلى رسالة معلومات حول تفاصيل إعدادت الضبط لدينا ولم يكن هناك أيّة أخطاء، هذا جيّد.

وإن كنتَ تملك خادوم وِيب Nginx تستطيع البدء باختبار مماثل بكتابة:

sudo nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

تتحقق هذه العمليّة من صياغتك كما ترى، فإن أزلنا الفاصلة من المنقوطة من نهاية أحد الأسطر في ملف الإعدادات (وهو خطأ شائع بالنسبة لإعدادت ضبط Nginx) فسنحصل على رسالة مماثلة للآتي:

sudo nginx -t 

nginx: [emerg] invalid number of arguments in "tcp_nopush" directive in /etc/nginx/nginx.conf:18
nginx: configuration file /etc/nginx/nginx.conf test failed

يُوجد عدد خاطئ من المُعطيات arguments لأنّ Nginx يقوم بالبحث عن الفاصلة المنقوطة لإنهاء الجُمَل، فإن لم يجدها ينتقل للسطر التالي ويفسّر ذلك على أنها مُعطيات إضافية للسطر السابق.

بإمكانك إجراء هذه الاختبارات لكي تجد أخطاء الصياغة في ملفاتك، قُم بإصلاح هذه المشاكل التي يُشير إليها إلى أن تستطيع ملفاتك تجاوز الاختبار بنجاح.

هل المنافذ الذي قمت بضبطها مفتوحة؟

تعمل خواديم الوِيب بشكلٍ عام على المنفذ 80 لاتصالات الوِيب الطبيعية normal web traffic وتستخدم المنفذ 443 للاتصالات المشفّرة باستخدام TLS/SSL، ولكي تصل بشكل صحيح إلى الموقع يجب أن تكون هذه المنافذ قابلة للوصول. تستطيع اختبار إذا ما كان الخادوم لديك يملك منفذًا مفتوحًا باستخدام الأداة netcat على حاسوبك المحلّي Local Machine.

تحتاج فقط لاستخدام عنوان الـ IP لخادومك وتخبرها عن رقم المنفذ الذي تريد التحقق منه كما يلي:

sudo nc -z 111.111.111.111 80

سيقوم هذا الأمر بالتحقق من المنفذ 80 على الخادوم الذي يملك عنوان 111.111.111.111، إن كان مفتوحًا سيخبرك الأمر فورًا بالنتيجة، أمّا إن لم يكن مفتوحًا فسيحاول الأمر باستمرار لإنشاء اتصال مع الخادوم دون جدوى، بإمكانك إيقاف هذه العمليّة بضغط على CTRL-C في واجهة الأوامر.

إن لم تكن منافذ الوِيب قابلة للوصول لديك فيجب أن تبحث في إعدادات الجدار الناري لديك، حيث قد تحتاج أن تفتح المنفذ 80 أو المنفذ 443.

هل تقودك إعدادات الـ DNS إلى المكان الصحيح؟

إن كان بإمكانك الوصول إلى موقعك باستخدام عنوان الـ IP ولا تستطيع ذلك عبر اسم المجال domain name فربّما يجب عليك إلقاء نظرة على إعدادت الـ DNS.

لكي يتمكّن زوّار موقعك من الوصول إليه عبر استخدام اسم المجال فيجب أن يكون لديك سِجِل "A"  أو "AAAA"  يشير إلى عنوان الـ IP الخاص بخادومك في إعدادات الـ DNS، تستطيع الاستعلام عن سِجِل “A” لمجالك باستخدام هذا الأمر:

host -t A example.com
example.com has address 93.184.216.119

يجب أن يتطابق السطر الذي يعود لك مع عنوان الـ IP لخادومك، إن كنتَ تريد التحقق من سِجِل "AAAA" (للاتصالات التي تستخدم IPv6) بإمكانك كتابة:

host -t AAAA example.com
example.com has IPv6 address 2606:2800:220:6d:26bf:1447:1097:aa7

يجب أن تبقي في ذهنك أنّ أيّة تغييرات تقوم بها على سِجِل الـ DNS تأخذ وقتًا طويلًا ليتم تعميمها، ربّما تتلقى نتائج متضاربة بعد التغيير حيث أنّ طلبك يتمّ تلقيه من قبل خواديم مختلفة ليست جميعها مُحدّثة إلى آخر إصدار حتى الآن. إن كنتَ تستخدم موقع DigitalOcean فبإمكانك أن تتعلم أساسيات DNS وأسماء النطاقات.

قم بالتأكد من أن ملفات إعدادات الضبط تقوم بالتعامل مع مجالك بشكل صحيح. يبدو المقطع الخاص بملف المضيف الوهمي virtual host file لديك في Apache كما يلي:

<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
ServerAdmin admin@example.com
DocumentRoot /var/www/html
٠٠٠

يتم إعداد المضيف الوهمي virtual host لكي يستجيب مع أيّة طلبات على المنفذ 80 من أجل المجال example.com.

تبدو القطعة المشابهة لهذا في Nginx كما يلي:

server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /usr/share/nginx/html;
index index.html index.htm;
server_name example.com www.example.com;
٠٠٠

يتم إعداد هذه الكتلة Block لكي تستجيب إلى النوع المماثل من الطلبات التي تحدثنا عنها في الأعلى.

هل يشير جذر المستند Document Root إلى موقع ملفاتك؟

من الاعتبارات الأخرى التي يجب أن نأخذ بها هي إذا ما كان خادوم الويب لديك يشير إلى الموقع الصحيح للملف. يتم إعداد كل خادوم وهمي في Apache أو كتلة خادوم Server Block في Nginx لكي تشير إلى مجلّد محدد، فإن كان مُعدًّا بشكل غير صحيح سيرمي الخادوم رسالة خطأ عندما تحاول الوصول إلى الصفحة.

يتم إعداد جذر المستند Document Root في Apache باستخدام التوجيه DocumentRoot :

<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
ServerAdmin admin@example.com
DocumentRoot /var/www/html
...

يُخبر هذا السطر Apache أنّه يجب عليه البحث عن الملفات لهذا المجال في المسار var/www/html/، فإن كنت تحتفظ بملفاتك في مكانٍ آخر يجب عليك تعديل هذا السطر لكي يشير إلى الموقع الصحيح.

يقوم التوجيه root في Nginx بإعداد نفس الشيء:

server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /usr/share/nginx/html;
index index.html index.htm;
server_name example.com www.example.com;
... 

يبحث Nginx في إعداد الضبط هذا عن الملفات لهذا المجال في المسار usr/share/nginx/html/

هل يقوم خادوم الوِيب بتخديم ملفات الفهرس Index files الصحيحة؟

إذا كان جذر المستند لديك صحيحًا ولا يتم تخديم صفحات الفهرس Index Pages بشكلٍ صحيح عندما تذهب إلى موقعك أو إلى مكان المجلد على موقعك فربّما تم ضبط إعدادات الفهارس بشكل غير صحيح.

عندما يقوم زائر ما بطلب مجلد يقوم خادومك نموذجيًا بإعطائه ملف فهرسة، عادةً ما يكون هذا ملف index.html أو ملف index.php وذلك اعتمادًا على على إعدادات الضبط لديك.

ربّما تجد في Apache سطرًا في ملف المضيف الافتراضي الذي يقوم بضبط إعدادات ترتيب الفهرس التي سيتم استخدامها لمجلدات معيّنة بشكلٍ صريح كما يلي:

<Directory /var/www/html>
DirectoryIndex index.html index.php
</Directory>

هذا يعني أنّه عندما يتم تخديم مجلد فإنّ Apache سيقوم بالبحث أولًا عن ملف يدعى index.html، ويحاول تخديم ملف index.php كاحتياط في حال لم يتم إيجاد الملف الأول. بإمكانك تعيين الترتيب الذي سيتم استخدامه لتخديم ملفات الفهرس لكامل الخادوم عن طريق تعديل ملف mods-enabled/dir.conf والذي يقوم بتعيين الإعدادات الافتراضية للخادوم، إن كان الخادوم لديك لا يُخدّم ملف فهرس فقم بالتأكد أنّك تملك ملف فهرس في مجلّدك الذي يُوافق أحد الخيارات في ملفك.

يُدعى التوجيه الذي يقوم بذلك في Nginx بـ “index” ويتمّ استخدامه كما يلي:

server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /usr/share/nginx/html;
index index.html index.htm;
server_name example.com www.example.com;
...

هل تمّ تعيين الأذونات والملكية بشكل صحيح؟

حتى يتمكن خادوم الوِيب من تخديم الملفات الصحيحة يجب أن يكون قادرًا على قراءة الملفات وأن يمتلك صلاحية الوصول للمجلدات حيث يتم حفظ هذه الملفات، بالإمكان التحكم بهذا عبر أذونات وملكية الملفات والمجلدات. لكي تقرأ الملفات يجب أن تكون المجلدات التي تحتوي المحتوى قابلة للقراءة والتنفيذ من قبل عمليّة خادوم الوِيب، تختلف أسماء المستخدمين والمجموعات التي يتم استخدامها لتشغيل خادوم الوِيب من توزيعة لأخرى.

على Ubuntu و Debian يعمل كلًّا من Apache و Nginx كالمستخدم www-data والذي هو عضو من المجموعة www-data.

على CentOS و Fedora يعمل Apache تحت مستخدم يُدعى apache والذي ينتمي لمجموعة apache، يعمل Nginx تحت مستخدم يُدعى nginx والذي هو جزء من مجموعة nginx.

تستطيع باستخدام هذه المعلومات النظر إلى المجلدات والملفات التي يتألف منها محتوى موقعك:

ls -l /path/to/web/root

يجب أن تكون المجلدات قابلة للقراءة والتنفيذ من قبل المستخدم web أو مجموعته، أمّا الملفات فيجب أن تكون قابلة للقراءة لكي يتم قراءة محتواها، وبالإضافة لذلك إن أردنا تحميل، كتابة أو التعديل على المحتوى يجب أن تكون المجلدات والملفات قابلة للكتابة، ولكن احذر عند تعيينك للمجلدات لكي تكون قابلة للكتابة لأنّ هذا يُمكن أن يكون أحد المخاطر الأمنية.

لتعديل ملكية ملف ما تستطيع فعل ما يلي:

sudo chown user_owner:group_owner /path/to/file

تستطيع فعل هذا أيضًا للمجلد، فبإمكانك تغيير ملكية المجلد وكل ما بداخله من ملفات عبر تمرير العَلَم –R:

sudo chown -R user_owner:group_owner /path/to/file

تستطيع التعلم أكثر عن أذونات لينِكس هنا.

هل قُمتَ بمنع الوصول عن طريق ملفات الضبط؟

من المحتمل أنّه تم تعيين إعدادات الضبط لديك لكي تمنع الوصول إلى الملفات التي تحاول تخديمها. يتم إعداد هذا الضبط في Apache في ملف المضيف الافتراضي لهذا الموقع أو عبر ملف htaccess. الموجود في المجلد نفسه.

من الممكن من خلال هذه الملفات أن تقوم بمنع الوصول بعدّة طرق ، يُمكن منع الوصول للمجلدات في إصدار Apache 2.4 بهذه الطريقة:

<Directory /usr/share>
AllowOverride None
Require all denied
</Directory>

يقوم هذا السطر بإخبار خادوم الوِيب بألّا يسمح لأي شخص بالوصول لمحتويات هذا المجلد، أمّا في إصدار Apache 2.2 والإصدارات الأقدم منه يمكننا كتابة ذلك كما يلي:

<Directory /usr/share>
AllowOverride None
Require all denied
</Directory>

إن وجدت توجيهًا كهذا للمجلد المُحتوي للمحتوى الذي تحاول الوصول إليه فإنّ هذا هو ما يمنع نجاحك. تأخذ هذه القيود في Nginx شكل توجيهات deny وتتواجد في كتل خادومك أو في ملفات إعدادات الضبط الرئيسية:

location /usr/share {
deny all;
}

إن كنتَ تملك قاعدة بيانات database في الخلفية فهل هي تعمل؟

إذا كان موقعك يعتمد على قاعدة بيانات في الخلفية مثل MySQL, PostreSQL, MongoDB, etc فستحتاج أن تتأكد من أنّها قيد التشغيل.

بإمكانك فعل هذا بنفس الطريقة التي تأكدت منها بأنّ خادوم الوِيب يعمل، مرّة أخرى نستطيع البحث عن العمليات قيد التشغيل ومن ثم انتقاء اسم العملية التي نبحث عنها كما يلي:

sudo netstat -plunt | grep mysql

tcp        0      0 127.0.0.1:3306        0.0.0.0:*         LISTEN      3356/mysqld

كما ترى فإن الخدمة قيد التشغيل على هذا الحاسوب، عندما تبحث عن خدمة قُم بالتأكد من أنّك تعرف الاسم الذي تعمل تحته هذه الخدمة. وكبديل لهذا ابحث عن المنفذ الذي تعمل الخدمة عليه إن كنتَ تعلم هذا، ابحث في توثيق documentation قاعدة بياناتك لكي تجد المنفذ الافتراضي الذي تعمل عليه أو تحقق من ملفات إعدادات الضبط.

إن كنتَ تملك قاعدة بيانات في الخلفية، فهل يستطيع موقعك الاتصال بنجاح إليها؟

الخطوة التالية التي يجب أن تأخذها إن كنت تحاول استكشاف الأخطاء مع وجود قاعدة بيانات في الخلفية هي أن ترى إن كان بإمكانك الاتصال بها بشكلٍ صحيح، يعني هذا عادةً التحقق من الملفات التي يقرؤها موقعك لكي يجد معلومات قاعدة البيانات.

على سبيل المثال في موقع WordPress يتم تخزين إعدادات اتصال قاعدة البيانات في ملف يُدعى wp-config.php ، تحتاج للتحقق من أنّ DB_NAME ، DB_USER و DB_PASSWORD صحيحة لكي يتمكن موقعك من الاتصال بقاعدة البيانات. 

بإمكانك اختبار إذا ما كان الملف يملك المعلومات الصحيحة بمحاولة الاتصال إلى قاعدة البيانات يدويًّا باستخدام ما يلي:

mysql -u DB_USER_value -pDB_PASSWORD_value DB_NAME_value

إن لم تتمكّن من الاتصال باستخدام القيم التي وجدتها في الملف فربّما تحتاج إلى إنشاء الحسابات وقواعد البيانات أو تعديل أذونات الوصول لقاعدة بياناتك.

هل تمّ ضبط خادوم الوِيب لديك لكي يمرر محتوىً ديناميكيًا إلى معالج نصوص Script Processor؟

إن كنت تستخدم قاعدة بيانات في الخلفية، فأنت بكل تأكيد تستخدم لغة برمجة مثل PHP لكي تعالج طلبات للمحتوى الديناميكي، تجلب المحتويات من قاعدة البيانات وتقديم النتائج. إن كانت هذه هي الحالة تحتاج للتأكد من أن خادوم الوِيب لديك مُعَد بشكل صحيح لكي يمرر الطلبات إلى معالج النصوص.

يعني هذا بشكل عام في Apache التأكد من تنصيب وتمكين mod_php5، بإمكانك فعل هذا على Ubuntu أو Debian بكتابة:

sudo apt-get update
sudo apt-get install php5 libapache2-mod-php5
sudo a2enmod php5

وفي أنظمة CentOS و Fedora يجب كتابة ما يلي:

sudo yum install php php-mysql
sudo service httpd restart

ولكنّ هذا معقّد أكثر قليلًا في Nginx، حيث أنّه لا يملك وحدة PHP ليتمّ تمكينها، لذلك نحتاج أن نتأكد من تنصيب وتمكين php-fpm في إعدادات الضبط.

على خادوم Ubuntu أو Debian تأكد أنّه تم تنزيل العناصر بكتابة:

sudo apt-get update
sudo apt-get install php5-fpm php5-mysql

تستطيع فعل هذا على CentOS أو Fedora بكتابة:

sudo yum install php-fpm php-mysql

بما أنّ معالج PHP ليس جزءًا من Nginx تحتاج أن تذكر له صراحةً أن يمرر ملفات PHP، اتبع الخطوات الأربعة من هذا الدليل لتتعلم كيف تضبط إعدادات Nginx لكي يمرر ملفات PHP إلى php-fpm، يجب عليك أيضًا أن تلقي نظرة على المقطع من الخطوة الثالثة الذي يتعامل مع إعداد معالج PHP، يجب أن يكون هذا مماثلًا إلى حدٍّ كبير بغض النظر عن توزيعتك.

إن فشل كل هذا تحقق من السّجلات مرّة أخرى

يجب أن يكون التحقق من السّجلات خطوتك الأولى، ولكنّه من الجيد أن يكون أيضًا خطوتك الأخيرة قبل أن تطلب المزيد من المساعدة.

إن بذلت قصارى جهدك في استكشاف الأخطاء بنفسك وتحتاج بعض المساعدة (من صديق، بفتح تذكرة مساعدة، إلخ...) ستحصل على مساعدة بشكل أسرع بتزويد ملفات السجل ورسائل الأخطاء، حيث سيجد مدراء النظم الخبيرون غالبًا فكرة جيّدة عمّا يحصل إن أعطيتهم هذه القطع من المعلومات التي يحتاجونها.

الخاتمة

آمل أن تكون نصائح استكشاف الأخطاء هذه قد ساعدتك في تعقب وإصلاح بعضًا من أشيع المشاكل التي يواجهها مدراء النظم عند محاولتهم في تشغيل مواقعهم. إن كنت تملك نصائح إضافية عن أشياء يجب التحقق منها وطرق لحل المشاكل قم بمشاركتهم مع المستخدمين الآخرين في التعليقات.

ترجمة -وبتصرّف- للمقال  How To Troubleshoot Common Site Issues on a Linux Server  لصاحبه Justin Ellingwood.