البحث في الموقع

خادوم الويب هو برمجية مسؤولة عن قبول طلبات HTTP من العملاء المعروفين بمتصفحات الويب، وتخديمهم بردود HTTP مع محتويات البيانات الاختيارية؛ التي تكون عادةً صفحات ويب كمستندات HTML والكائنات الأخرى مثل الصور والفيديو ...إلخ. خادوم أباتشي (HTTPD)أباتشي (Apache) هو أشهر خادوم ويب مستخدم في أنظمة لينُكس؛ تُستعمَل خواديم الويب لتخديم الصفحات المطلوبة من العملاء؛ يَطلب ويَعرض العملاءُ صفحاتَ الويب عادةً باستخدام متصفح ويب مثل فايرفكس أو كروميوم أو أوبرا أو موزيلا. يُدخِل المستخدم URL (اختصار للعبارة Uniform Resource Locator) للإشارة إلى خادوم ويب باسم النطاق الكامل (FQDN) والمسار إلى الهدف المطلوب؛ على سبيل المثال، لعرض الصفحة الرئيسية لموقع أوبنتو، فسيدخل المستخدم اسم النطاق الكامل فقط: www.ubuntu.com لعرض الصفحة الفرعية للمجتمع، فإن المستخدم سيُدخِل اسم النطاق الكامل متبوعًا بمسار: www.ubuntu.com/community أشهر بروتوكول مُستخدَم لنقل صفحات الويب هو بروتوكول نقل النص الفائق (Hyper Text Transfer Protocol، اختصارًا HTTP)، بروتوكولات أخرى مدعومة مثل بروتوكول نقل النص الفائق فوق طبقة مقابس آمنة (Hyper Text Transfer Protocol over Secure Sockets Layer، اختصارًا HTTPS)، وبروتوكول نقل الملفات (File Transfer Protocol، اختصارًا FTP) الذي هو بروتوكول لرفع (upload) أو تنزيل (download) الملفات. يُستخدَم خادوم ويب أباتشي عادةً مع محرك قواعد بيانات MySQL، ولغة معالجة النصوص الفائقة (PHP)، وغيرها من «لغات السكربتات» (scripting languages) مثل بايثون و بيرل؛ يُسمَّى هذا الضبط بالمصطلح LAMP‏ (Linux, Apache, MySQL and Perl/Python/PHP) ويُشكِّل منصةً قوية ومرنةً لتطوير ونشر تطبيقات الويب. التثبيتخادوم أباتشي متوفر في أوبنتو؛ أدخل الأمر الآتي لتثبيته: sudo apt-get install apache2الضبطيُضبَط أباتشي بوضع تعليمات (directives) في ملفات ضبط نصية بسيطة؛ هذه التعليمات موزعة بين الملفات والمجلدات الآتية: ملف apache2.conf: ملف ضبط أباتشي الرئيسي؛ يحتوي على الإعدادات العامة لأباتشي.الملف httpd.conf: تاريخيًا كان ملف ضبط أباتشي الرئيسي؛ وسُمِّي هذا الملف باسم عفريت httpd؛ الآن الملفُ فارغٌ افتراضيًا، حيث نُقِلَت معظم خيارات الضبط إلى المجلدات تالية الذكر؛ يمكن أن يُستخدَم هذا الملف لإعدادات الضبط التي يجريها المستخدم وتؤثر على ضبط أباتشي العام.المجلد conf-available: يحتوي على ملفات الضبط المتوفرة لأباتشي؛ جميع الملفات التي كانت في مجلد ‎/etc/apache2/conf.d انتقلت إلى ‎/etc/apache2/conf-available.المجلد conf-enabled: يحتوي على الوصلات الرمزية للملفات في مجلد ‎/etc/apache2/conf-available؛ فعندما تُضاف وصلة رمزية لملف ضبط، فإنه سيُفعَّل عندما يُعاد تشغيل خدمة أباتشي.الملف envvars: الملف حيث تُضبَط قيم متغيرات البيئة (environment variables) لأباتشي.مجلد mods-available: يحتوي هذا المجلد على ملفات خاصة لتحميل الوحدات (modules) وضبطها، لا تملك جميع الوحدات ملفات ضبط خاصة بها.مجلد mods-enabled: يحتوي على الوصلات الرمزية إلى الملفات في ‎/etc/apache2/mods-available؛ فعندما تُضاف وصلة رمزية لملف ضبط خاص بوحدة، فإن هذه الوحدة ستُفعَّل في المرة القادمة التي سيُعاد تشغيل أباتشي فيها.ملف ports.conf: يحتوي على التعليمات التي تُحدِّد منافذ TCP التي يستمع إليها أباتشي.مجلد sites-available: يحتوي هذا المجلد على ملفات الضبط «للمضيفين الوهميين» (Virtual Hosts) في أباتشي؛ يسمح المضيفون الوهميون بضبط أباتشي لتشغيل عدة مواقع تملك ضبطًا منفصلًا.مجلد sites-enabled: مثل mods-enabled، يحتوي مجلد sites-enabled على وصلاتٍ رمزية لمحتويات مجلد ‎/etc/apache2/sites-available؛ وبشكل مشابه، فإن ملفات الضبط التي تُوصَل وصلًا رمزيًا لهذا المجلد ستُفعَّل في المرة القادمة التي سيُعاد تشغيل خادوم أباتشي فيها.الملف magic: يُستخدَم لتحديد نوع MIME بناءً على أول عدِّة بايتات من الملف.بالإضافة لذلك، يمكن أن تُضاف ملفات ضبط أخرى باستخدام التعليمة Include؛ ويمكن أن تُستخدم المحارف الخاصة (wildcards) لتضمين العديد من ملفات الضبط؛ أي تعليمة يمكن أن توضع في أيّ من ملفات الضبط تلك. لا تؤخذ التعديلات على ملفات الضبط الرئيسية بعين الاعتبار من أباتشي إلا إذا بدء أو أعيد تشغيله. يقرأ الخادوم أيضًا ملفًا يحتوي على أنواع المستندات (mime types)؛ يُحدَّد اسم الملف بالتعليمة TypesConfig ويكون عمومًا هو الملف ‎/etc/apache2/mods-available/mime.conf؛ الذي ربما يحتوي على إضافات أو تعديلات على ‎/etc/mime.types. الإعدادات الأساسيةيشرح هذا القسم معاملات ضبط خادوم أباتشي الأساسية؛ ارجع إلى توثيق أباتشي للمزيد من التفاصيل. يأتي أباتشي مع ضبط افتراضي «صديق» للمضيفين الوهميين؛ هذا يعني أنه مضبوط مع مضيف وهمي وحيد افتراضيًا (باستخدام التعليمة VirtualHost) الذي يمكن أن يعدَّل أو يُستخدَم كما هو لو أردت الحصول على موقع وحيد فقط؛ أو تستطيع استخدامه كقالب للمضيفين الوهميين الإضافيين إذا كنت تريد الحصول على عدِّة مواقع؛ إذا تُرِكَ كما هو، فسيُخدِّم المضيف الوهمي الافتراضي موقعك الافتراضي؛ أو الموقع الذي سيراه مستخدمو الموقع لو أن عنوان URL الذي أدخلوه لا يُطابِق التعليمة ServerName لأيٍّ من مواقعك المخصصة؛ لتعديل المضيف الوهمي الافتراضي فيجب تعديل الملف ‎/etc/apache2‎/sites-available/default. ملاحظة: التعليمات المضبوطة لمضيفٍ وهمي لا تطبَّق إلا عليه فقط؛ إذا ضُبِطَت تعليمة لعموم الخادوم ولم يعاد تعريفها في ضبط المضيف الوهمي، فسيُستخدَم الضبط الافتراضي؛ على سبيل المثال، تستطيع ضبط عنوان بريد webmaster ولا تُعيد تعريفه لكل مضيف وهمي. إذا أردت ضبط مضيفٍ وهميٍ جديد أو موقع؛ فانسخ هذا الملف إلى نفس المجلد باسمٍ من اختيارك؛ على سبيل المثال: sudo cp /etc/apache2/sites-available/000-default.conf \ /etc/apache2/sites-available/mynewsite.confعدِّل ملف ضبط الموقع الجديد باستخدام بعض التعليمات المشروحة في الأسفل. التعليمة ServerAdmin تحدد البريد الإلكتروني لمدير الخادوم؛ القيمة الافتراضية هي webmaster@localhost؛ يجب أن تُعدَّل القيمة إلى البريد الإلكتروني الخاص بك (إذا كنت مديرًا للنظام)؛ إذا حدثت مشكلة مع موقع الويب، فسيُظهِر أباتشي رسالة خطأ تحتوي على هذا البريد الإلكتروني للتبليغ عن المشكلة؛ اعثر على هذه التعليمة في ملف ضبط الموقع الخاص بك في ‎/etc/apache2/sites-available.التعليمة listen تحدد المنفذ وبشكل اختياري عنوان IP الذي يجب على أباتشي الاستماع إليه؛ إذا لم يُحدَّد عنوان IP، فسيستمع أباتشي على جميع عناوين IP المُسندَة للخادوم الذي يعمل عليه أباتشي؛ القيمة الافتراضية للتعليمة listen هي 80؛ عدِّل هذه القيمة إلى 127.0.0.1:80 لجعل أباتشي يستمع فقط إلى بطاقة loopback لذلك لن يكون متوفرًا إلى الإنترنت، عدِّل القيمة إلى 81 (على سبيل المثال) لتغيير المنفذ الذي يستمع إليه أباتشي؛ أو اتركه كما هو للعمل العادي؛ هذه التعليمة توجد وتُعدَّل في ملفها الخاص ‎/etc/apache2/ports.conf.التعليمة ServerName هي اختيارية وتحدد ما هو اسم النطاق الكامل (FQDN) لموقعك الذي سيستجيب أباتشي له؛ المضيف الوهمي الافتراضي لا يملك خاصية ServerName مُحدَّدة، لذلك سيستجيب لجميع الطلبات التي لا تطابقها التعليمة ServerName في أي مضيف وهمي آخر؛ إذا حصل وامتلكتَ النطاق ذو الاسم ubunturocks.com وأردت أن تستضيف الموقع على خادومك، فإن قيمة ServerName في ملف ضبط المضيف الوهمي الخاص بك ستكون ubunturocks.com، أضف هذه التعليمة إلى ملف ضبط المضيف الوهمي الجديد الذي أنشَأناه سابقًا (‎/etc/apache2/sites-available/mynewsite.conf).ربما تريد من موقعك أن يستجيب إلى www.ubunturocks.com، ولما كان العديد من المستخدمين يعتبرون أنّ السابقة www هي سابقة ملائمة لمواقع الويب؛ فعليك استخدام التعليمة ServerAlias لهذا الغرض؛ ربما تستخدم المحارف الخاصة (wildcards) للتعليمة ServerAlias. فمثلًا، سيسبب الضبط الآتي استجابة موقعك لأي طلب نطاق ينتهي بالعبارة «‎.ubunturocks.com»: ServerAlias *.ubunturocks.comتُحدِّد التعليمة DocumentRoot أين يجب أن يبحث أباتشي عن الملفات لإنشاء الموقع؛ القيمة الافتراضية هي ‎/var/www كما هو محدد في ‎/etc/apache2/sites-available/000-default.conf؛ يمكنك تستطيع تعديل هذه القيمة في ملف ضبط مضيفك الوهمي؛ لكن تذكر أن تُنشِئ المجلد إذا كان ذلك ضروريًا. فعِّل المضيف الوهمي الجديد باستخدام الأداة a2ensite وأعد تشغيل أباتشي: sudo a2ensite mynewsite sudo service apache2 restartملاحظة: تأكد أنك ستستبدل mynewsite باسم أكثر وصفًا للمضيف الوهمي؛ إحدى الطرق لتسمية الملف هي استخدام قيمة ServerName للمضيف الوهمي. وبشكلٍ مشابه، استخدم الأداة a2dissite لتعطيل المواقع؛ يمكن أن يكون هذا مفيدًا عند استكشاف أخطاء الضبط عند وجود أكثر من مضيف وهمي: sudo a2dissite mynewsite sudo service apache2 restartالإعدادات الافتراضيةسيشرح هذا القسم إعدادات الضبط الافتراضية لخادوم أباتشي؛ مثلًا، إذا أضفت مضيفًا وهميًا فالإعدادات التي ستضبطها للمضيف الوهمي ستكون لها الأولوية لذاك المضيف الوهمي؛ وستُستخدَم القيمة الافتراضية للتعليمات غير المُعرَّفة ضمن إعدادات المضيف الوهمي. التعليمة DirectoryIndex هي الصفحة الافتراضية المُخدَّمة من الخادوم عندما يَطلب المستخدم فهرس الدليل بإدخال شرطة أمامية (‎/‎) في نهاية اسم الدليل.على سبيل المثال، عندما يطلب المستخدم الصفحة ‎http://www.example.com/directory/‎‎‎ فأنه إما سيحصل على صفحة DirectoryIndex إن وجدت، أو على قائمة بمحتويات المجلد مولدَّةً من الخادوم إذا لم تكن موجودةً وكان قد حُدِّد الخيار Indexes، أو صفحة «Permission Denied» إن لم يتحقق أيٌّ منهما. سيحاول الخادوم إيجاد أحد الملفات المذكورة في التعليمة DirectoryIndex وستُعيد أول ملف ستجده؛ إذا لم تجد أي ملف من تلك الملفات وكان الخيار «Options Indexes» مضبوطًا لهذا المجلد، فسيولِّد الخادوم قائمةً بصيغة HTML للمجلدات الفرعية والملفات في هذا الدليل؛ القيمة الافتراضية الموجودة في ملف ‎/etc/apache2/mods-available/dir.conf هي "index.html index.cgi index.pl index.php index.xhtml index.htm" وبالتالي إذا عَثَر أباتشي على ملف في المجلد المطلوب يطابق أحد تلك الأسماء، فسيُظهِر أول مطابقة. التعليمة ErrorDocument تسمح لك بتحديد ملف لكي يستعمله أباتشي عند حدوث خطأ معين؛ على سبيل المثال، إذا طلب المستخدم ملفًا غير موجودٍ، فسيحدث خطأ 404؛ وافتراضيًا، سيُعيد أباتشي الرمز HTTP 404؛ راجع ‎/etc/apache2/conf.d/localized-error-pages لمعلومات تفصيليّة عن استخدام ErrorDocument بما فيها أماكن ملفات الأمثلة.يكتب الخادوم سجل النقل افتراضيًا إلى الملف ‎/var/log/apache2/access.log، تستطيع تغيير هذا لكل موقع بناءً على ملفات ضبط مضيفك الوهمي باستخدام التعليمة CustomLog؛ أو أن تقبل باستخدام القيمة الافتراضية المحددة في ‎/etc/apache2/conf.d/other-vhosts-access-log. ربما تحدد أيضًا الملف الذي تريد تسجيل الأخطاء إليه باستخدام التعليمة ErrorLog، التي تكون قيمتها الافتراضية هي ‎/var/log/apache2/error.log؛ لكن اترك هذا السجل منفصلًا عن سجل النقل للمساعدة في استكشاف الأخطاء الحاصلة مع خادوم أباتشي؛ ربما تحدد أيضًا التعليمة LogLevel (القيمة الافتراضية هي "warn") و LogFormat (راجع ‎/etc/apache2/apache2.conf للقيمة الافتراضية). تُحدَّد بعض الخيارات على أساس المجلد بدلًا من الخادوم؛ التعليمة Options هي إحداها، يكون قسم Directory محاطًا بوسوم شبيهة بلغة XML، كما يلي: <Directory /var/www/mynewsite> ... </Directory>التعليمة Options ضمن قسم Directory تقبل قيمة واحدة أو أكثر من القيم الآتية مفصولةً بفراغات:ExecCGI: السماح بتنفيذ سكربتات CGI، لن تُنفَّذ سكربتات CGI ما لم يُحدَّد هذا الخيار.تنويه: لا يجب أن تُنفَّذ أغلبية الملفات كسكربتات CGI، لأن ذلك سيكون خطرًا جدًا! سكربتات CGI يجب أن تُبقى في مجلد منفصل وخارج المجلد الجذر لموقعك، ويجب أن يكون الخيار ExecCGI مضبوطًا لهذا المجلد فقط؛ هذا هو الضبط الافتراضي، والمكان الافتراضي لسكربتات CGI هو ‎/usr/lib/cgi-bin. Includes: السماح بتضمينات من جهة الخادوم؛ حيث تسمح تضمينات الخادوم لملف HTML بتضمين الملفات الأخرى، راجع «Apache SSI Documentation» لمزيدٍ من المعلومات.IncludesNOEXEC: السماح بتضمينات من جهة الخادوم، لكن تعطيل الأمرَين ‎#exec و ‎#Include في سكربتات CGI.Indexes: عرض قائمة مُنسَّقة بمحتويات المجلد، إذا لم يُعثر على ملف DirectoryIndex (مثل index.html) في المجلد المطلوب.تحذير: لأغراض تتعلق بالحماية، لا يجب أن يُضبَط هذا الخيار عادةً؛ وخصوصًا في مجلد جذر الموقع! فعِّل هذا الخيار بحذر لكل مجلد على حدة إن كنت متأكدًا أنك تريد أن يتمكن المستخدمون من رؤية كامل محتويات المجلد. Multiview: دعم «content-negotiated multiviews»؛ هذا الخيار مُعطَّل افتراضيًا لأسباب أمنية، راجع توثيق أباتشي حول هذا الخيار.SysLinksIfOwnerMatch: اتباع الوصلات الرمزية فقط إذا كان الملف أو المجلد الهدف له نفس مالك الوصلة.إعدادات httpdيشرح هذا القسم بعض إعدادات ضبط عفريت httpd الأساسية. التعليمة LockFile: تضبط التعليمة LockFile المسار إلى ملف القفل الذي سيستخدم عندما يُبنى الخادوم مع أحد الخيارين USE_FCNTL_SERIALIZED_ACCEPT أو USE_FLOCK_SERIALAIZED_‎ ACCEPT؛ يجب أن يكون الملف مخزنًا على قرصٍ محلي، ويجب أن يترك لقيمته الافتراضية ما لم يكن مجلد السجلات موجودًا على مشاركة NFS، إذا كانت هذه هي الحالة، فيجب أن تبدَّل القيمة إلى مسار في القرص المحلي، وإلى مجلد قابل للقراءة من المستخدم الجذر (root) فقط.التعليمة PidFile: التعليمة PidFile تضبط الملف الذي يُسجِّل فيه الخادوم رقم عمليته (process ID أو pid اختصارًا)؛ يجب أن يكون هذا الملف قابلًا للقراءة فقط من الجذر، وفي أغلب الحالات، يجب أن تترك هذه التعليمة بقيمتها الافتراضية.التعليمة User: تَضبُط التعليمة User معرِّف userid المستعمل من الخادوم للإجابة عن الطلبيات؛ هذا الخيار يُعرِّف حدود وصول الخادوم، لن يتمكن زوار الموقع من الوصول إلى أي ملف لا يمكن لهذا المستخدم الوصول إليه، القيمة الافتراضية لهذه التعليمة هي "www-data".تحذير: ما لم تكن متأكدًا تمامًا مما تفعل، فلا تضبط التعليمة User إلى root، سيسبب استخدام الجذر كمستخدم هنا في إنشاء ثغرات كبيرة في خادوم الويب.التعليمة Group: التعليمة Group شبيهة بالتعليمة User، التعليمة Group تحدد المجموعة التي سيجيب عبرها الخادوم عن الطلبيات؛ المجموعة الافتراضية هي "www-data" أيضًا.مشاركة إذن الكتابةلكي يتمكن أكثر من مستخدم من الكتابة إلى نفس المجلد، فمن الضروري أن نعطي إذن الكتابة للمجموعة التي يشتركون بها؛ المثال الآتي يُشارِك إذن الكتابة للمجلد ‎/var/www للمجموعة «webmasters»: sudo chgrp -R webmasters /var/www sudo find /var/www -type d -exec chmod g=rwxs "{}" \; sudo find /var/www -type f -exec chmod g=rws "{}" \;ملاحظة: لو أردت أن يُمنَح الوصول لأكثر من مجموعة واحدة للمجلد، ففعِّل قوائم التحكم بالوصول (ACLs). مصادرتوثيق أباتشي، الذي يشرح بعمق معلومات حول تعليمات ضبط أباتشي، وأيضًا راجع الحزمة apache2-doc لتوثيق أباتشي الرسمي.راجع توثيق Mod SSL للمزيد من المعلومات المتعلقة بالوحدة SSL.كتاب O'Reilly المسمى «Apache Cookbook» هو مصدر رائع للقيام بضبط خاص لأباتشي.لأسئلة حول أباتشي على أوبنتو، فاسأل في قناة IRC المسماة ‎#ubuntu-server على خادوم freenode.net.لما كان أباتشي يُدمَج عادةً مع PHP و MySQL، فصفحة ويكي أوبنتو «Apache MySQL PHP» هي مصدر جيد للمعلومات.ترجمة -وبتصرف- للمقال Ubuntu Server Guide: HTTPD - Apache2 Web Server.

يُواجه كلّ شخص في وقتٍ ما مشاكل مع خادوم الوِيب 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.