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

هذا الدليل مناسب أيضًا لإعداد خادم WordPress المحلي الخاص بك. إن اختبار العديد من الأشياء (نظام إدارة المحتوى، والسمات وما إلى ذلك) على الإنترنت يسبب متاعبًا كبيرة وله العديد من العيوب، لذا نلجأ عادةً إلى ضبط وتشغيل خادم محلي على حاسوبنا لإجراء مثل عمليات الاختبار تلك. إن أردت التجريب على خادم حقيقي، تحتاج إلى شراء نطاق (domain)، والدفع مقابل الاستضافة، واستخدام سرعة تحميل بطيئة لمزودي الإنترنت لتحميل الملفات عبر بروتوكول نقل الملفات ftp، وكلما أردت تغيير بعضَ إعدادات Apache أو PHP، يتعيَّنُ عليك الاتصال بمزوِّد الاستضافة والانتظار لبعض الوقت حتى يردّوا. يمكنني سرد مساوئ أخرى، لكنني أعتقد أن الصورة قد اتضحت. هناك العديد من الخوادم التي تمثِّل عدّة حزم في حزمة واحدة، والتي سيتمُّ تثبيتها جميعًا مثل WAMP أو XAMPP، لكني لا أحبُّها. هذه البرامج -برأيي- بمثابة قمامة غير منضبطة على الكمبيوتر وغير محدَّثة في كثيرٍ من الأحيان. لكنَّها حلٌّ سريع وجيد للأشخاص الذين لا يريدون أن يتعلموا عملَ كلِّ شيء ويحتاجون طريقةً سريعة لتثبيت خادم ويب محلي، لاختبار مشاريعهم. هذا الدليل أكثر تعقيدًا من مجرّد كونه حلٌّ يعتمد علىWAMP أو XAMPP ولكن الميزة الأكبر أنَّ لديك كامل التحكم، لأنّك تضبط بنفسك كل شيء (الخادم، قاعدة البيانات ضمن أية حزمة). ويمكنك أن تكون دائمًا مطلعًا على التحديثات وتستمتع بأحدث الإصلاحات والتحسينات في حزم Apache و PHP و MySQL. بمجرّد إتقان هذا الدّليل، فستوافق على إمكانيّة تثبيت خادم محليّ باستخدام الحزم الأصلية في بضعِ دقائق، مثل WAMP أو XAMPP. تحديث الحزم الجديدة بسيطٌ للغاية أيضًا. قُمْ بتثبيت الحزمة الجديدة على الحزمة الحالية وانتهى الأمر. من ينبغي أن يقرأ هذا المقال لإعداد خادم الويب المحلي؟ يعدُّ هذا البرنامج التعليمي رائعًا لمطوّري الويب ومصمِّمي الويب الذين يحتاجون إلى اختبار التطبيقات المستندة للويب في الوقت الفعلي أو السمات الخاصة بـ WordPress أو Joomla أو Drupal دون الحاجة إلى اتصال بالإنترنت أو استضافة المواقع. سيغطي، أيضًا، ويُعْلِمْكَ بأهمِّ العثرات والأخطاء غير المتوقعة التي تحدث في بعض الأحيان والتي لا تغطيها البرامج التعليمية الأخرى. لذلك يجب أن يكون لدى المستخدمين الذين سيتبعون هذا البرنامج التعليمي خطوة بخطوة خادمُ ويب مضيف محلي، يعمل من دون أخطاء غير متوقعة في النهاية. قرَّرتُ أن أكتب هذا البرنامج التعليمي لأنني تابعت العديد من البرامج التعليمية على الويب، إلا أنني لم أتمكن من جعل خوادمي المحلية التي أنشئها تعمل من المحاولة الأولى، لذلك قضيت عدة ساعات في البحث عن الأخطاء غير المتوقعة وإصلاحها، والتي غطيتها كلها في هذا الدليل التعليمي . اقتباسات استخدم غالبًا علامات الاقتباس لكتابة التعليمات والأوامر وأسماء تسجيل الدخول وكلمات المرور والمسارات وأسماء المجلدات التي تحتاج إلى تعديل بما يناسبك. لذلك كلِّما رأيت علامات الاقتباس في هذا الدليل، استخدم دائمًا ما بين علامات الاقتباس فقط. سيتمّ وضع علامة كنصٍّ غامق أيضًا. في بعض الأحيان توجد علامات اقتباس بين علامات الاقتباس، تكون هذه علامات الاقتباس (بين علامات الاقتباس) مهمة في ملفات الضبط. المتطلبات تم إنشاء هذا الدليل التعليمي على (ويندوز7 32 بت نهائي) 32bit Windows 7 Ultimate في برنامج VMware Player، لكنني أستخدمه في تثبيت حقيقي لـ (ويندوز7 64 بت نهائي) 64bit Windows 7 Ultimate دون أي مشكلة. على أي حال، يمكن تطبيق هذا الدليل على إصدارات ويندوز اللاحقة مع اختلاف في الإصدارات. لذلك، في هذه الحالة يجب أن تعمل على أي نظام تشغيل Microsoft. حتى إذا كانت الحزم 32 بت، فإنها تعمل على أنظمة تشغيل 64 بت دون أية مشاكل تتعلق بعدم التوافق. هناك حزم 64 بت غير رسمية لـ Apache و PHP، ولكن التثبيت أكثر تعقيدًا ولا يتم تحديثها غالبًا. يحتوي الدعم الرسمي لأنظمة التشغيل 64 بت على MySQL، لكنه لن يعمل بشكل صحيح مع نسخة 32 بت من Apache و PHP. التنزيلات Apache 2.2.15 win32 x86 no ssl msi PHP 5.3.2 VC6 x86 Thread Safe Installer phpMyAdmin 3.3.2 zip WordPress (اختياري) إذا وجدت أي إصدارات جديدة من هذه الحزم، فيمكنك استخدامها أيضًا، وستكون الخطوات هي نفسها. خطوات ما قبل التثبيت الخطوة الأولى: إنشاء المجلدات اللازمة أنشئ مجلدًا للتثبيت وآخر لتخزين صفحات الويب الخاصة بالاختبار. أنصحك باتباع نفس الهيكل؛ وإلا فيتعيّن عليك تغيير جميع المسارات إلى إعداداتك الخاصة أثناء خطوات البرنامج التعليمي. يسمى المجلد الأول الذي أقوم بإنشائه بـ "dev" (من الكلمة "تطوير") في جذر "C:\‎". يسمَّى المجلد الثاني الذي أقوم بإنشائه "progs" في "C:\dev\‎" والثالث يسمى "www" في "C:\dev\‎" ، لذا بعد ذلك يجب أن يكون لديك ثلاثة مجلدات جديدة. C:\dev\‎ C:\dev\progs\‎ لتثبيت Apache و PHP و Mysql C:\dev\www\‎ - هذا المجلد بمثابة مجلد لبروتوكول FTP عند الاستضافة، وسيتم استخراج جميع صفحات الويب الخاصة بك فيه الخطوة الثانية: إيقاف التحكم في حساب المستخدم يمكن لمستخدمي نظام التشغيل Windows XP تخطي هذه الخطوة! إنه لمستخدمي فيستا و ويندوز 7 و ويندوز 10 وهي تعطيل UAC! ستقوم بذلك بالنقر فوق Start> ‏Control Panel> ‏User Accounts (ابدأ> لوحة التحكم> حسابات المستخدمين) ثم انقر فوق "تغيير إعدادات التحكم في حساب المستخدم" (Change User Account Control settings). في النافذة التالية (تذكر الموضع الافتراضي لشريط التمرير)، اسحب شريط التمرير لأسفل حتى "لا تبلغني أبدًا متى: ..."، انقر فوق "موافق" وأغلق النوافذ. بالنسبة لمستخدمي نظام التشغيل Vista - ما عليك سوى إيقاف التحكم في حساب المستخدم. لا تقم بإعادة تشغيل جهاز الكمبيوتر الآن! يجب إعادة شريط التمرير إلى الإعدادات الافتراضية بعد التثبيت الناجح لـ Apache و PHP و MySQL، وذلك لأسباب أمنية. الخطوة الثالثة: تعديل ملف المضيفين hosts في ويندوز في بعض الحالات، لم أستطعْ التثبيت حتى قمت بهذه الخطوة. لم أختبر هذا على نظام التشغيل Windows XP، لذلك يمكن لمستخدمي XP أيضًا تخطي هذه الخطوة، لأنه في رأيي ليست هناك من حاجة إليها. غالبًا ما يتمُّ وضع ملف المضيفين في المسار "C:\Windows\System32\drivers\etc\‎" وهو ملف مخفي وللقراءة فقط. لمشاهدة الملفات المخفية، انتقل إلى ابدأ> لوحة التحكم> خيارات المجلد، انقر فوق اللسان "عرض"، وحدد "إظهار الملفات والمجلدات ومحركات الأقراص المخفية"، ثم انقر فوق موافق. في أنظمة x64، لن يكون الملف مرئيًا في برنامج طرف ثالث كمديري ملفات 32bit، مثل Total Commander حتى وإن غيَّرت الإعدادات لمشاهدة الملفات والمجلدات المخفيّة، لأن برامج 32bit لا يمكنها رؤية ملفات ومجلدات 64 بت. لذا انتقل إلى هذا المجلد من خلال مستكشف Windows الأصليّ للملفات للوصول إلى ملف المضيفين بشكل صحيح. افتح الملف في المفكرة، وابحث عن السطر: ‎# 127.0.0.1 localhost، وحذف الرمز #، واحفظ الملف، والآن يمكنك إعادة تشغيل الكمبيوتر لتطبيق الإعدادات. الآن انتهينا من خطوات التثبيت المسبق. تثبيت الخادم Apache وضبطه قم بتشغيل تثبيت Apache عبر فتح الملف الذي نزَّلته، وانقر فوق التالي، وتحقق من أنك تقبل الشروط، ثم انقر فوق التالي، ثم التالي مرة أخرى. في الشاشة التالية، قم بملء إعدادات الخادم، كما في الصورة أدناه، وانقر فوق التالي مرة أخرى. في الصفحة التالية، حدد النوع Custom Setup (الإعداد المخصّص) وانقر فوق (التالي). اترك جميع الميزات كما هي، قم بتغيير مسار التثبيت فقط إلى: "C:\dev\progs\Apache\‎" وانقر فوق "التالي". الآن انقر فوق تثبيت. سترى أيقونة جديدة على شريط مهام windows مع مثلث أخضر صغير يشير إلى تثبيت Apache وتشغيله. لاختباره بشكل صحيح افتح المتصفح Internet Explorer أو Firefox أو أي متصفح تستخدمه واكتب "localhost" في شريط العناوين. إذا سارت الأمور على ما يرام، يجب أن ترى "إنه يعمل!" "It Works!". نحرِّرُ ملف ضبط Apache! ننتقل إلى المجلد "C:\dev\progs\Apache\conf\‎" ونفتح الملف "httpd.conf" في المفكرة. أوصي باستخدام محرر نصوص متقدم مثل Adobe Dreamweaver أو PSPad مجاني، من أجل تحرير أفضل وأكثر راحة. حيث يمكنك رؤية أرقام الأسطر والتنقل عبر الملف النصي بسهولة. انتقل إلى السطر 117 أو ابحث عن "‎#LoadModule rewrite_module modules/mod_rewrite.so" واحذف "#" في بداية السطر - وبمعنى آخر، أزلْ التعليق (جيد لعناوين URL جميلة). انتقل إلى السطر 178 أو ابحث عن "DocumentRoot "C:/dev/progs/Apache/htdocs"‎" واستبدل به "DocumentRoot "C:/dev/www"‎ " انتقل إلى السطر 205 أو ابحث عن "<Directory "C:/dev/progs/Apache/htdocs">" واستبدل به "<Directory "C:/dev/www">" انتقل إلى السطر 208 أو ابحث عن " Options Indexes FollowSymLinks" واستبدل به "Options Includes Indexes FollowSymLinks MultiViews". انتقل إلى السطر 225 أو ابحث عن "AllowOverride None" واستبدل به " AllowOverride All". انتقل إلى السطر 240 أو ابحث عن "DirectoryIndex index.html" واستبدل به " DirectoryIndex index.html index.htm index.php". انتقل إلى السطر 382 أو ابحث عن "AddType application / x-gzip .gz .tgz" لا تستبدل أي شيء، فقط أضف سطرًا جديدًا أسفل هذا السطر بالقيمة التالية: "AddType application / x-httpd-php .php". احفظ الملف، واخرج من برنامج المحرر وأعدْ تشغيل Apache. يمكنك القيام بذلك من خلال النقر على أيقونة Apache في شريط المهام ثم نقل المؤشر على Apache 2.2 والنقر فوق "إعادة التشغيل". إذا قمت بتوجيه متصفحك مرة أخرى إلى مضيف محلي "localhost"، فلن ترَ "إنه يعمل!" ولكن سترى شيئًا مثل "Index Of". لا تقلق، إنه بسبب تغيير المجلد من حيث يقوم Apache بترجمة صفحات الويب. تهانينا، اكتمل تثبيت اباتشي وإعداده! تثبيت وضبط الـ PHP قم بتشغيل حزمة تثبيت PHP التي نُزِّلتها ثم انقرْ فوق "التالي"، واقبلْ الشروط وانقر فوق "التالي" مرة أخرى. انقرْ فوق استعراض، في الشاشة التالية، وانتقل إلى برنامج التثبيت لتثبيت PHP إلى "C:\dev\progs\PHP\‎" وانقر فوق "التالي". حدِّد Apache 2.2.x Module وانقرْ فوق التالي مرة أخرى. يجب أن تخبر برنامج التثبيت بمكان ملف ضبط Apache (الذي قمنا بتحريره حينَ إعداد apache). إذا سارت الأمور بشكل جيد، فسترى الأسطر الجديدة التالية في نهاية ملف ضبط الأباتشي httpd.conf: #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL PHPIniDir "C:/dev/progs/PHP/" LoadModule php5_module "C:/dev/progs/PHP/php5apache2_2.dll" #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL لنضبط ملف تكوين PHP المسمّى php.ini الموجود في المجلد "C:\dev\progs\PHP\‎" وافتحه في Notepad أو PSPad أو Dreamweaver وغيِّر الأسطر على النحو التالي (يجب على PHP تعمل أيضًا مع php.ini الأصلي، ولكن يوصى باستخدام هذه التغييرات لاستخدام أكثر راحة): انتقل إلى السطر 458 أو ابحث عن "memory_limit = 128M" وقم بتغييره إلى "memory_limit = 512M" (حدد مقدار الذاكرة التي يمكن لـ PHP استخدامها). انتقل إلى السطر 531 أو ابحث عن "display_errors = Off" وقم بتغييره إلى "display_errors = On" (إذا كانت هناك بعض الأخطاء، فسيتم عرضها في متصفح الويب، إذا فعِّلتْ هذه الإعدادات). انتقل إلى السطر 542 أو ابحث عن "display_startup_errors = Off" وقم بتغييره إلى "display_startup_errors = On". انتقل إلى السطر 728 أو ابحث عن **"post_max_size = 8M"** وقم بتغييره إلى **" post_max_size = 100M"**. انتقل إلى السطر 879 أو ابحث عن "upload_max_filesize = 2M" وقم بتغييره إلى "upload_max_filesize = 2000M". انتقل إلى السطر 959 أو ابحث عن "‎;date.timezone =‎" واستبدل به "date.timezone = "XXX/XXX"‎". حيث يعني XXX/XXX موقعك الفعليّ، بالنسبة لي سوريا/حلب، للعثور على وضعك هنا. بالنسبة للأشخاص الذين يعيشون في سوريا - حلب، يجب أن يبدو التنسيق مثل هذا "date.timezone = "Asia/Aleppo"‎". هذا هو كل ما يجب فعله. احفظْ الملفَّ، ثم أخرج من المحرِّرْ، وأعد تشغيل Apache. لنختبر ما إذا كان PHP يعمل. لذا انتقل إلى المجلد "C:\dev\www\‎" وأنشئ ملفًا نصيًّا جديدًا يسمَّى "index.php" واكتب بداخله النص التالي: "<?php phpinfo()‎; ?>" احفظ الملف واخرجْ. افتح متصفح الويب وانتقل إلى المضيف المحلي "localhost". إذا تمَّ تثبيت PHP بنجاح، فسترى هذه الصورة: تثبيت وضبط MySQL هذا هو الجزء الأسهل، لضبط كلِّ شيء في معالج التثبيت. قمْ بتشغيل ملف التثبيت MySQL. انقر فوق التالي، واختر مخصص، ثمَّ انقر فوق التالي، وقم بتغيير مجلد التثبيت إلى "C:\dev\progs\MySQL\‎" ثمَّ انقر فوق "التالي" مرةً أخرى، ثمَّ قُمْ بالتثبيت. بعد اكتمال التثبيت، سترى نافذةً أخرى، لذلك انقر مرة أخرى، التالي، التالي، تحقق من وضع إشارة على "Configure the MySQL server now" وألغِ تحديد "Register the MySQL server now"، ثم انقرْ فوق "إنهاء". في الشاشة التالية، انقر فوق "التالي"، ثم حدد الضبط التفصيلي "Detailed Configuration" ثمَّ انقر فوق "التالي"، وحدد "Developer Machine" وانقر فوق "التالي"، "Multifunctional Database" وانقر فوق "التالي"، واترك النافذة الأخرى كما هي وانقر فوق "التالي"، وحدد الخيار "Decision Support (DSS)/OLAP" وانقر فوق" التالي". تحقق الآن من "Enable TCP/IP Networking"، واتركْ رقم المنفذ 3306، وحدد "Add firewall exception for this port"، وحدد "Enable Strict Mode"، ثم انقر فوق التالي. حدد "Best Choice For Multilingualism" وانقر فوق "التالي". حدِّدْ "Install As Windows Service"، وحدد اسم الخدمة "MySQL5"، حدد "Launch the MySQL Server automatically" وتحقَّقْ من وضع علامة على "Include Bin Directory in Windows PATH" ثم انقر فوق "التالي". حدد "Modify Security Settings" وباعتبارها "New root password"، استخدم "root" بدون علامات الاقتباس، وأكِّدْ كلمة المرور، واترك باقي الخيارات كما هي ثم انقر فوق "التالي". الخطوة الأخيرة هي تطبيق جميع الإعدادات التي قمنا بها، لذلك انقر على "تنفيذ" وانتظر حتى ترى هذا: إذا كنت لا ترى هذه الصورة، فهناك شيء خاطئ. ويجب أن يكون أشياء كثيرة. سأحاول المساعدة في التعليقات. ولكن أتوقع أنه لن يكون هناك أية مشاكل. تثبيت phpMyAdmin وضبطه phpMyAdmin هو مدير قاعدة بيانات MySQL على شبكة الإنترنت. بالنسبة لي شخصيا، إنه الحلُّ الأفضل والأسهل لإدارة وإنشاء قواعد البيانات حتى لو كان يعمل على المضيف المحلي localhost. هناك حلٌّ من مطوِّري MySQL يُسمِّى MySQL GUI Tools، يعمل على أنظمة تشغيل Windows، لكنَّه لا يوفِّرُ الاستطلاع الأسهل وهو فوضوي بعض الشيء بالنسبة لي. يعرفُ العديد من المستخدمين الذين يستخدمون خدمات استضافة الويب لصفحات الويب، phpMyAdmin جيّدًا. أثبت غالبًا WordPress و Drupal و Joomla و vBulletin معًا لاختبار السمات وما إلى ذلك، وأستخدم قاعدة بيانات واحدة لكل نظام إدارة محتوى CMS، ولهذا السبب أستخدم phpMyAdmin، والذي يسمح لي بإنشاء قواعد بيانات بطريقة سهلة دون معرفة العمل على سطر أوامر MySQL. سنبدأ بإنشاء مجلد يسمى "pma" في "C:\dev\www\‎". افتح الآن ملف zip باستخدام phpMyAdmin واستخلص كل محتوى المجلد "phpMyAdmin-3.3.2-all-languages" إلى مجلد "pma". افتح الآن متصفح الويب المفضَّل لديك وأشرْ إلى المسار "localhost/pma". إذا كنت محظوظًا، يجب أن تشاهد شاشة تسجيل دخول phpMyAdmin. يمكنك تسجيل الدخول إلى phpMyAdmin عن طريق إدخال "root" لاسم المستخدم وكلمة المرور على السواء. على نظامي التشغيل Vista و Windows 7، وربما على أنظمة تشغيل XP أيضًا، ستظهر لك في بعض الأحيان بعض الأخطاء تشير بأنَّ PHP غير مثبَّت أو مُجهَّز بشكلٍ صحيح. هذا أحد الأخطاء غير المتوقعة التي كنت أبحث عنها في كثير من الأحيان لعدة ساعات، قبل أن أحلّها! قد يكون الحل بسيطًا - أولاً ، انتقل إلى المجلد "C:\dev\progs\PHP\‎" وابحث عن ملف يسمى "php5ts.dll" وانسخه إلى المجلدين التاليين: "C:\Windows\‎" و "C:\Windows\System32\‎" وأعدْ تشغيل Apache. ربَّما سيرفض Apache البدء وسيظهر أخطاء، إذا كان الأمر كذلك، تجاهل الخطأ وابدأ من جديد. يجب أن تعمل الآن! يجب أن تشاهد صفحة تسجيل دخول phpMyAdmin عن طريق توجيه المتصفح إلى "localhost/pma". إذا لم يساعد الحل الأول، فستكون المشكلة متعلقة بأذونات الكتابة لمجلد Windows وجلسة PHP، التي تقوم بحفظ المسار إلى مجلدات Temp. ليس لدى PHP إذن الكتابة إلى مجلدات Temp المطلوبة. هذه المشكلة فردية حقًا، وإذا قام شخص ما بالإبلاغ عنها في التعليقات، فسوف أساعده بشكل منفرد. قُمْ بتسجيل الدخول إلى phpMyAdmin وستحصل على واجهة إدارة قاعدة بيانات phpMyAdmin. في اللوحة اليسرى، سترى قواعد البيانات الفعلية، والتي تُعَدُّ مهمة لتشغيل MySQL بشكل صحيح، لذلك لا تحذفها. على الجانب الأيمن سترى بعض المعلومات حول خادم الويب الخاص بك، يمكنك تغيير السمة أو اللغة أو إنشاء قاعدة بيانات جديدة. في الجزء السفلي سترى بعض الأخطاء، والتي سنصلحها. للاستخدام الأساسي ليس ضروريًا، لكن لا يمكنني تحمّل أي شيء يُظْهِرُ أخطاءً :-) أولاً، يجب علينا إنشاء بعض الجداول لإلغاء تأمين الإمكانات الكاملة لـ phpMyAdmin، لذلك في اللوحة اليسرى، انقر فوق قاعدة البيانات المسماة اختبار "test"، ثم انقرْ فوق استيراد "import". انقر فوق الزر Browse وانتقل من خلال phpMyAdmin إلى المجلد "C:\dev\www\pma\scripts\‎" واختر ملفًا يسمَّى "create_tables.sql" وفي phpMyAdmin في الركن السفلي الأيمن انقر على "Go". سيقوم بإنشاء قاعدة بيانات جديدة تسمى phpmyadmin مع 9 جداول. سيتمُّ استخدامه لميزات phpMyAdmin المتقدِّمَة، مثل إنشاء ملفات PDF وما إلى ذلك. يمكنك إغلاق المتصفح و التطلّع إلى الجزء الأخير - تحرير ملف ضبط phpMyAdmin :-). انتقل إلى المجلد "C:\dev\www\pma\‎" وافتح الملف "config.sample.inc.php" في Notepad أو Dreamweaver أو PSPad. نحتاج إلى تعديل السطر 18 الذي يحدد عبارة المرور السرية لـ blowfish. الأمر متروك لك تمامًا فيما تقوم بإدخاله بين علامات الاقتباس حتى تتمكن من البحث عن مثال كهذا: "‎$cfg['blowfish_secret'] = '1M41Oie6q9E3w#7U0M^3f3Tyzr5r93 ';‎" انتقل إلى السطر 36 واستبدل "‎$cfg['Servers'][$i]['extension'] = 'mysql';‎" بـ "‎$cfg['Servers'][$i]['extension'] = 'mysqli';‎" نحتاج الآن إلى حذف "//" في بداية الأسطر التالية: (also change default pma user to root) $cfg['Servers'][$i]['controlpass'] = 'root';<strong> (also change default pmapass password to root)</strong> $cfg['Servers'][$i]['pmadb'] = 'phpmyadmin'; $cfg['Servers'][$i]['bookmarktable'] = 'pma_bookmark'; $cfg['Servers'][$i]['relation'] = 'pma_relation'; $cfg['Servers'][$i]['table_info'] = 'pma_table_info'; $cfg['Servers'][$i]['table_coords'] = 'pma_table_coords'; $cfg['Servers'][$i]['pdf_pages'] = 'pma_pdf_pages'; $cfg['Servers'][$i]['column_info'] = 'pma_column_info'; $cfg['Servers'][$i]['history'] = 'pma_history'; $cfg['Servers'][$i]['tracking'] = 'pma_tracking'; $cfg['Servers'][$i]['designer_coords'] = 'pma_designer_coords'; احفظ الملف في نفس المجلد كـ "config.inc.php" ثم اخرج من المُحرِّر. يجب أن يعمل phpMyAdmin الآن دون أية أخطاء، وقد انتهينا من التثبيت الكامل لخادم الويب المضيف المحلي. يمكنك الآن استعادة إعدادات UAC كما كنا تحدثنا عنها في البداية. اختياري - تثبيت أحد أنظمة إدارة المحتوى (ووردبريس) يجب أولًا إنشاء قاعدة بيانات جديدة لبرنامج WordPress، لذلك قمْ بتسجيل الدخول إلى phpMyAdmin وتحت النص إنشاء قاعدة بيانات جديدة "Create New Database"، اكتب اسم "WordPress" وانقر فوق "إنشاء". انتقل الآن إلى المجلد "C:\dev\www\‎" وقم بإنشاء مجلد جديد يسمى "wp". إذا قُمْتَ بتنزيل ملف التثبيت WordPress 2.9.2، فافتح الملف المضغوط واستخرج كل محتويات مجلد WordPress إلى "C:\dev\www\wp\‎" افتح المتصفح وانتقل إلى "localhost/wp"، إذا كان كل شيء جيدًا ، يجب أن تشاهد أولاً صفحة تثبيت WordPress، لذلك انقر على "إنشاء ملف ضبط" (Create a Configuration File) ثم على " هيا نذهب!" (Lets go!‎) في الصفحة التالية. في الصفحة التالية، قم بملء اسم قاعدة البيانات، وهو "WordPress" واسم المستخدم وكلمة المرور "root" لكليهما. هذه هي كلمة المرور الخاصة بـ WordPress لكتابة الجداول في قاعدة البيانات وليس للوصول إلى لوحة إدارة نظام إدارة المحتوى CMS. يمكن أن تظل جميع القيم الأخرى كما هي، انقر فوق "إرسال" (submit) ثم "تشغيل التثبيت" (Run the Install). املأ عنوان المدونة، كما يحلو لك. وفي حقل البريد الإلكتروني، أدخل أي عنوان بريد إلكتروني حقيقي. لن يعمل إرسال رسائل البريد الإلكتروني لأن Apache الخاص بنا غير مكوّن لإرسال رسائل البريد الإلكتروني، ولكن من يهتم؟ نحن لسنا في حاجة إليها على مضيف محلي! ;-) ثم تابع التثبيت. في الشاشة التالية، سترى معلومات تسجيل الدخول وكلمة المرور الخاصة بك، اكتبها في مكان ما، وانقر على "تسجيل الدخول" "Log In" للوصول إلى واجهة مسؤول WordPress. هنا يمكنك تغيير كلمة المرور إلى شيء أسهل يمكن تذكره. انتهيت. إذا وجهت متصفحك الآن إلى "localhost/wp" فسترى شيئًا كهذا: تعرَّفتَ على أساسيات تثبيت أي نظام إدارة محتوى. تثبيتات دروبال أو جملة متشابهة جدا. الخلاصة قلت لك إنه ليس معقدًا ;-) إذا كنت مثلي، فأنت تحب القهوة الجيدة في المقهى المفضل لديك (والذي للأسف ليس متصلًا بالإنترنت). وإذا كنت ترغب في العمل بصحبة أشخاص وليس وحدك في المنزل أو في مكتب، فمن المحتمل أنَّكَ ستقدِّر هذا الدليل التعليمي. غالبًا ما يستخدم معظمكم حلولًا مثل WAMP أو XAMPP، والبعض الآخر يستخدم الحل الخاص بي بطريقة أكثر تقدّمًا، والتي توفرها تكوينات Apache، لكنني أعرف الكثير من مصممي الويب ومطوري الويب الذين لا يعرفون هذه الحلول وهذا الدليل التعليمي موجه لهم بالضبط. إذا كنت تواجه أي مشكلة، فأعلمني وسأبذل قصارى جهدي لمساعدتك. ترجمة -وبتصرّف- للمقال Step by Step Guide to Setting Up Your Local Web Server لصاحبها "فريق تحرير الموقع"

كان ختام المقالة السّابقة قولُنا أن بروتوكول HTTP يدير التّفاعل بين عميل وخادوم، وقد شرحنا فكرة ترويسات HTTP. سيكون لدينا الكثير مما يُقال عن هذه الترويسات في أجزاء تالية من هذه السّلسلة، فهذه الترويسات تؤثّر في التّفاعل بين الطّرفين وفي أداء الموقع. أمّا اليوم، فسنطّلع على جانب لا يقلّ أهمّيّة عن التّرويسات، وهو رموز إجابات HTTP. نزهة في الشوارع خرجت ذات صباح قاصدًا مقهى لأقرأ كتابًا، لكنّني وجدت المقهى مُغلقًا حينها، وقد كُتب على لوحة على الباب أنّ احتفالًا يُقام خلال هذا الأسبوع، ولذلك فإنّ المقهى سينتقل مؤقتًا ليُقدّم القهوة في شاحنة الطّعام (التي سمّوها "307") قرب النهر. ذهبت إلى ذلك المكان واستمتعت بشرب القهوة. قرّرت بعدئذٍ التجوّل في مكتبتي المفضّلة في المدينة، فوجدتها مُغلقةً كذلك، إلّا أنّني رأيت لوحة على الباب تقول أن المكتبة ستتوسع ولذلك انتقلت بشكل دائم إلى مبنى جديد في 301 شارع برنرز-لي. لم يُزعجني ذلك، فالمكان قريب. ذهبت إلى هناك فاستقبلني الموظّفون بالتّرحاب: "200 سلامة!". حسنًا، أنا أبالغ قليلًا، لكنّك فهمتني! في طريقي إلى البيت، وجدت متجرًا مهجورًا غطّى الغبار أبوابه في 410 شارع برنرز-لي، وقد أُلصقت ورقةٌ على الباب تقول أنّ صاحب المحلّ تقدّم بطلب إشهار الإفلاس واضطّر إلى إغلاق المتجر، إلى الأبد. وكأنّ العجائب لم تنتهِ اليوم، إذ رأيت في نهاية 500 شارع برنرز-لي مبنى من 4 طوابق وقد انهار بالكامل. ما الذي حدث هنا؟! لم يكن يومي سيئًا بالمجمل، لذا قرّرت أن أكمل يومي بكتابة مقال عن رموز HTTP الّتي تُرسلها الخواديم إلى العملاء الّذين يرسلون الطّلبات. صياغة جواب HTTP وسطر الحالةتطرّقنا في المقال السّابق إلى السّطر الأول من صيغة الطّلبات الّتي يُرسلها العميل (بما في ذلك أفعال HTTP). وسنركّز الآن على السّطر الأول من رسالة الجواب الّتي تصل من الخادوم، ومعاني الرّموز المختلفة الّتي تظهر في هذا السّطر. لاحظ التّشابه بين نوعي الرّسائل (الطّلبات والإجابات). فكما ينصّ توثيق الإصدارة 1.1 من HTTP: إما إن تكون رسالة HTTP طلبًا من العميل إلى الخادوم أو جوابًا من الخادوم للعمل. من حيث الصّياغة، لا يختلف نوعا الرّسائل إلى في السّطر الأوّل، والذي إمّا أن يكون سطر طلب (للطلبات) أو سطر حالة (للإجابات)، وفي خوارزميّة تحديد طول متن الرّسالة (القسم 3.3). يُدعى السّطر الأول في الجواب إذًا سطر الحالة. يبدأ السّطر بإصدارة بروتوكول HTTP ثمّ مسافة ثم رمز من ثلاثة أرقام، ثم مسافة ثمّ جملة تشرح الرّمز، كهذا المثال: HTTP/1.1 200 OKالجملة القصيرة الأخيرة غير إلزامية وعلى العملاء تجاهلها، ولا ينبغي أن يستخدمها برنامج بغرض تفسير الجواب. لنطّلع الآن على بعض أكثر رموز الحالة شيوعًا وما يعنيه كلّ رمز منها. رموز الحالة في HTTP200، كلّ شيء على ما يرام! في كلّ مرّة يريد شخصٌ ما زيارة الصّفحة الرئيسيّة لموقع Opera، يُرسل العميل طلبًا إلى http://www.opera.com/ برسالة مثل هذه: GET / HTTP/1.1 Host: www.opera.com Accept-Language: fr User-Agent: BrowseAndDream/1.0يُحلّل الخادوم الرّسالة الّتي وصلته من العميل ويُرسل جوابًا بناء على ما فهمه من الرابط والترويسات. وكما ذكرنا في المقالتين السّابقتين، يكون الهدف الأهمّ هو إدارة التّواصل بين الطّرفين بما يحقّق أقصى فائدة لكليهما. إن فهم الخادوم الرّسالة، فإنّه يرسل رسالة تبدأ بـ200 OK، أي أنّ كلّ شيء على ما يُرام. تحوي الرسالة بضع ترويسات إجابة ثمّ محتوى الصّفحة، والّذي قد يختلف بناءً على ترويسات الطّلب، فلا إجابة مُطلقة. فكما في كل تفاوض، يجري حوارٌ بين الطّرفين للوصول إلى أفضل تسوية. فيما يلي مثالٌ عن إجابة على الطّلب السّابق: HTTP/1.1 200 OK Date: Fri, 24 Aug 2012, 13:56:44 GMT307، انتقلتُ مؤقّتًا إلى مكان آخر يمكن للخادوم أن يجيب العميل برسالة تبيّن أنّ المحتو قد انتقل مؤقتًا إلى مكان آخر. ويفيد هذا عندما تريد إعادة توجيه العميل إلى صفحة مُعيّنة لفترة قصيرة. افترض مثلًا موقعًا يُعطي توقّعات الطقس لتاييبي، وقد شبّ إعصار هائل مؤخّرًا فيها. سيكون من المفيد إعلام المُستخدمين بوقوع هذا الإعصار حتى هدوئه. قد يكون الطّلب مثل هذا: GET /taiwan/weather/today HTTP/1.1 Host: meteo.example.orgقد يرغب الخادوم بإجابة العميل قائلًا: "سأنقلك إلى صفحة أخرى تُعطيك معلومات مفصّلة عن الأزمة الحاليّة في تاييبي". قد تبدو الإجابة مثل هذه: HTTP/1.1 307 Temporary Redirect Date: Fri, 24 Aug 2012, 13:56:44 GMT Location: http://meteo.example.org/taiwan/weather/crisisيتبع المتصفح عادةً الوجهة الجديدة المذكورة في سطر Location. يمكن أن يطلب الخادوم إعادة التّوجّه إلى نطاق آخر على الويب. وحالما تنتهي الأزمة، يمكن للخادوم إزالة إعادة التّوجيه. ينبغي ألّا يتذكّر العميل إعادة التّوجيه للأبد. فهذا مُهمّ في حالة الإشارات المرجعيّة وسجل التصفّح. من الممكن تصميم برنامج يُدير عمليّات إعادة التّوجيه هذه بطريقة مُفيدة. لا يرى المُستخدم إعادة التّوجيه في معظم المتصفّحات، ولكن من الممكن إرسال متن مع جواب إعادة التّوجيه يعرض على المستخدم رسالة تحوي رابطًا للمكان الجديد يُسمح للمُستخدم بنقره. 301، تغيّر العنوان بشكل دائم عند إدارة المعلومات على موقع ويب، قد نحتاج إلى إعلام العميل (ومستخدميه) أن الصّفحة المطلوبة قد انتقلت بشكل دائم. ففي الشّركات، يُعاد تنظيم الأقسام أحيانًا بعد الاتّحاد مع شركة أخرى أو عند تغيّر الأولويّات. لنفترض مثلًا أن وحدة الآلات الكهربائيّة في شركة تقنية قد ضُمَّت إلى قسم الإلكترونيّات. وعندها يمكن إعادة توجيه عميل يطلب: GET /section/electromech/about HTTP/1.1 Host: inc.example.comإلى: HTTP/1.1 301 Moved Permanently Date: Fri, 24 Aug 2012, 13:56:44 GMT Location: http://inc.example.com/section/electronic/aboutالفرق بين الرمز 307 الّذي شرحناه في الفقرة السّابقة، والرّمز 301، أنّ التّغيّر في العنوان دائم في حالة الرّمز الثّاني، وهي رسالة واضحة من الخادوم للعميل تطلب منه أن يُغيّر الإشارات المرجعيّة المحفوظة لديه إلى العناوين الجديدة. يمكن للمتصفّح تنفيذ ذلك من تلقاء نفسه أو بعد استشارة المستخدم. لإعادة توجيه الروابط القديمة فائدتان مُباشرتان. الأولى هي كسب ثقة المستخدمين بموقعك، بأن تُبدي اهتمامك بالمُحافظة على المعلومات الّتي تستضيفها. والثّانية هي استقرار الموارد، فالمواقع الّتي تُعرف بمحافظتها على الرّوابط تكون أكثر احتمالًا لأن تُشير إليها مواقع أخرى على المدى البعيد، ممّا يزيد ترتيب الموقع في مُحرّكات البحث. 410، وداعًا يا صديقي العزيز! تحتاج بعض المواقع أحيانًا إلى إبلاغ العميل باختفاء المعلومات الّتي كانت موجودة على رابط مُعيّن للأبد. وقد يكون لهذا مُبرّراته. نحن نعلم أن الروابط الجيّدة لا تتعطّل؛ ولكنّ الرّمز 410 Gone هو الوسيلة الوحيدة المناسبة لتعطيلها. لنكن أكثر دقّة: هذا الرّمز هة طريقة لإخبار المستخدمين أن المحتوى الّذي كان موجودًا من قبل على هذا الرابط قد حُذِفَ عمدًا. وهذا معناه أن الخادوم يطلب من العُملاء الّذي يقصدون هذا الرّابط ألّا يتذكّروه. ففي متصفّح يستخدم الإشارات المرجعيّة وسجّلات التّصفّح، يُعتبر هذا الرّمز إبلاغًا للمتصفّح بسلامة حذف هذا الرّابط. افترض شبكة اجتماعيّة يُطلب فيها الوصول إلى صفحة مُستخدم: GET /people/jeanpaulsartres HTTP/1.1 Host: socialnetwork.example.comقرّر المستخدم أن يُغادر شبكتك الاجتماعيّة ويُغلق حسابه، قد تُريد أن تُبلغ غيره من المستخدمين الّذين يطلبون صفحته من سجلّ المتصفّح أو إشاراته المرجعيّة: HTTP/1.1 410 Gone500، يا للمصيبة! قد يتعذّر على الخادوم إجابة الطّلب لسبب مجهول. لا يتدخّل HTTP على الإطلاق في تفاصيل عمل الموقع، مثل طريقة تخزين قواعد البيانات على الخادوم، أو كيف يجلب الخادوم البيانات ويُعالجها. ربّما توقّف الطّلب عند برنامج مُعيّن على الخادوم ولم يصل الجواب، وعندها يُبلغ الخادوم العميل ومستخدمه عن وقوع خطأ ما غير معروف بجواب مثل هذا: HTTP/1.1 500 Internal Server Errorاستخدام سطور الحالة في الإجابات الّتي تُرسلها الخواديمعند تصميم نظام لإدارة المحتوى، يكون من الضّروري فصل الطّبقات بصورة موارد وروابط إلى هذه الموارد، فهذا مُفيد عند إجابة طلبات العملاء بالمعلومات الصّحيحة، وتقديم المحتوى للبرامج أو للبشر هو شيء جوهريّ في صفة الخواديم. ولأنّ المعلومات تتغيّر وتتطوّر،فإنّ تصميم الخواديم بما يراعي هذه النّقطة يُعطيها مرونة أكبر. لا تهدف هذه السّلسلة إلى شرح تفاصيل تطبيق إجابات الخواديم من النّاحية البرمجيّة، ولكنّنا سنستعرض مثالين يُفيدان كنقطتي انطلاق، على الرّغم من أنّهما قد لا يُفيدان في حالة المواقع الضّخمة الّتي تضمّ آلاف الرّوابط. إعادة التّوجيه في Apacheفي حال أردت إعادة توجيه http://inc.example.com/section/electromech/about إلى http://inc.example.com/section/electronic/about، يمكن إضافة ملف .htaccess في جذر الموقع يحوي التّعليمات التّالية: RewriteEngine On RewriteBase / RewriteRule ^/section/electromech/about /section/electronic/about [L,R=301]مُلاحظة: هنالك طرق أخرى لتنفيذ هذا الغرض، كاستخدام httpd.conf أو قواعد البيانات أو من خلال النّصوص البرمجيّة... إلخ. واختيار الطّريقة المناسبة يعتمد على تصميم النّظام. إعادة التّوجيه في nginxخادوم Nginx هو الآخر شائع الاستخدام، وخصوصًا على شبكات توفير المحتوى (CDNs). يمكن إعادة كتابة المثال السّابق لاستخدامه مع nginx: server { listen 80; server_name inc.example.com; rewrite ^/section/electromech/about http://inc.example.com/section/electronic/about permanent; }تصنيف رموز HTTPتعرّفنا على بضع رموز HTTP فيما سبق، ولكنّها أكثر من ذلك، وبعض هذه الرّموز ذائع الصّيت مثل 404 Not Found، وبعضها مغمور لا يُرى كثيرًا. وفي كلا الحالتين يمكن الاستعانة بالرّقم الأوّل للرّمز لأخذ فكرة عن معناه، كون هذا الرقم يُشير إلى العائلة الّتي ينتمي إليها الرّمز: 1xx (بيان): وصل الطّلب، وتجري مُعالجته.2xx (نجاح): وصل الطّلب وفُهم وقُبل.3xx (إعادة توجيه): يُطلب إجراء تالٍ لإكمال الطّلب.4xx (خطأ من جهة العميل): صياغة الطّلب خاطئة أو يتعذّر تحقيقه.5xx (خطأ من جهة الخادوم): فشل الخادوم في تحقيق طلب يبدو سليمًا.الخلاصةإلى هنا نكون قد وصلنا إلى نهاية دراستنا لرموز حالة HTTP. أحثّك على الاطّلاع على كلّ رمز والتّعرّف على فائدته. لبعض هذه الرموز تأثيرات خاصّة على التّخزين المؤقّت وعلى متن رسالة HTTP؛ سنُلقي نظرةً على التّخزين المؤقت لاحقًا. تذكّرتُرسل الخواديم رموز حالة HTTP لتزويد العميل بمعلومات سريعة عن الجواب.تؤثّر رموز HTTP في التّخزين المؤقّت ومُعالجة الرّوابط من جهة العميل.تُصنّف رموز HTTP ضمن عدّة مجموعات.ترجمة (بشيء من التّصرّف) لمقال HTTP: Response Codes لصاحبه Karl Dubosy.

يُخفّض الضّغط من أوقات الاستجابة من خلال تقليص حجم استجابة HTTP. يُعدُّ Gzip طريقةَ الضّغط الأكثر شيوعًا وفعاليّةً في الوقت الحاضر و عادةً ما يُقلّص حجم الاستجابة بما يقارب 70%. في عام 2009، كانت 90% من حركة البيانات على الإنترنت تعبر من خلال متصفّحات تدعم Gzip. أمّا اليوم: يمكنك القيام بذلك على خادم مبنيٍّ على Apache من خلال الملف ‎.htaccess: # BEGIN GZIP <ifmodule mod_deflate.c> AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript </ifmodule> # END GZIP يُمثّل ما سبق قائمةً بأنواع MIME التي سيُطبّق عليها الضّغط حينئذٍ. يمكنك التعديل على هذه القائمة كما ترى مناسبًا لتشمل جميع أصولك النّصيّة التي ستخدّمها: يُقدّم مشروع HTML5 Boilerplate إعدادات الخواديم لجميع الخواديم الشائعة. هذه هي نسخة المشروع لملف htaccess. <IfModule mod_filter.c> AddOutputFilterByType DEFLATE "application/atom+xml" \ "application/javascript" \ "application/json" \ "application/ld+json" \ "application/manifest+json" \ "application/rdf+xml" \ "application/rss+xml" \ "application/schema+json" \ "application/vnd.geo+json" \ "application/vnd.ms-fontobject" \ "application/x-font-ttf" \ "application/x-javascript" \ "application/x-web-app-manifest+json" \ "application/xhtml+xml" \ "application/xml" \ "font/eot" \ "font/opentype" \ "image/bmp" \ "image/svg+xml" \ "image/vnd.microsoft.icon" \ "image/x-icon" \ "text/cache-manifest" \ "text/css" \ "text/html" \ "text/javascript" \ "text/plain" \ "text/vcard" \ "text/vnd.rim.location.xloc" \ "text/vtt" \ "text/x-component" \ "text/x-cross-domain-policy" \ "text/xml" </IfModule> ترجمة -وبتصرف- للمقال Active Gzip Compression لصاحبه Chris Coyier

نتابع عملنا في هذه السلسلة بتنصيب ماجنتو على نظام التشغيل Ubuntu 16.04.1 LTS. لقد اخترت طريقة سهلة وعمليّة لتنصيب ماجنتو واستثماره. يعتمد ماجنتو في عمله على وجود خادوم الويب Apache بالإضافة إلى لغة PHP وقواعد بيانات MySQL. سنستخدم الإصدار الأخير من ماجنتو وهو 2.1. يحتاج هذا الإصدار إلى الإصدارات التالية من البرمجيّات السابقة: Apache 2.2 أو Apache 2.4. MySQL 5.6 PHP 5.6.x حيث من الممكن أن يكون x أي رقم. لا يُعتبر تجهيز البرمجيات السابقة بالشكل الملائم أمرا يسيرا في الواقع. لذلك فقد آثرت استخدام توزيعة اسمها XAMPP، وهي توزيعة مشهورة تسمح بتنصيب البرمجيّات السابقة (وأكثر) دفعةً واحدةً. تأتي توزيعة XAMPP من مجموعة تُدعى Apache Friends. المثير في الأمر أنّ هذه المجموعة تتعاون مع شركة اسمها Bitnami وهي شركة متخصّصة بالحوسبة السحابيّة، حيث توفّر هذه الشركة العديد من التطبيقات المهمّة التي تعمل بشكل سلس على توزيعة XAMPP. من بين هذه التطبيقات هو تطبيق ماجنتو Magento. يمكننا بإجراءات بسيطة للغاية تجهيز ماجنتو وتشغليه على XAMPP. سنبدأ بتحميل وتنصيب توزيعة XAMPP وما تحويه من برمجيّات ضروريّة لعمل ماجنتو، ثمّ سنعمل على تحميل وتنصيب تطبيق ماجنتو. يفترض هذا الدرس أنّه لديك خبرة أساسيّة بطريقة التعامل مع أنظمة تشغيل Linux بشكل عام، مثل استخدام الطرفية Terminal والوصول عن طريقها إلى المجلّدات المختلفة، وتنفيذ الأوامر. تحميل وتنصيب توزيعة XAMPP انتقل إلى الحاسوب الذي يشغّلUbuntu . ثم استخدم المتصفّح للانتقال إلى موقع التحميل الخاص بتوزيعة XAMPP. استخدم شريط التمرير لتصل إلى القسم الخاص بلينوكس كما في الشكل التالي: حمّل النسخة التي تتضمّن PHP 5.6.23 (في الوسط) مع معمارية 64 بت. عند الانتهاء من تحميل الملف، انتقل إلى الطرفية Terminal ومنها إلى المكان الذي حمّلت إليه الملف السابق. بالنسبة إليّ كان الملف يحمل الاسم التالي وهو موجود ضمن المجلّد Documents: xampp-linux-x64-5.6.23-0-installer.run نفّذ الأمرين التاليين: sudo chmod 755 xampp-linux-x64-5.6.23-0-installer.run sudo ./xampp-linux-x64-5.6.23-0-installer.run كما يظهر في الشكل التالي: لاحظ أنّ الطرفية تطلب إدخال كلمة المرور الخاصة بالمستخدم الحالي بعد تنفيذ الأمر الأوّل مباشرةً، وذلك بسبب استخدام الأمر sudo. بعد تنفيذ الأمر الثاني سيبدأ برنامج الإعداد الخاص بالتوزيعة XAMPP بالعمل، حيث سيُظهر رسالة ترحيبيّة كما في الشكل التالي: انقر الزر Next للمتابعة لتصل إلى النافذة الخاصة بالمكوّنات الأساسيّة التي سيتم تنصيبها كما يلي: تأكّد من صناديق الاختيار، ثم انقر الزر Next. ستخبرك النافذة التالية عن المكان الذي سيتم فيه حفظ الملفات وهو /opt/lampp انقر زر Next لتحصل على نافذة دعائيّة للخدمات التي من الممكن أن تحصل عليها مع Bitnami. تابع نقر Next حتى تبدأ عملية التنصيب. ستأخذ عملية التنصيب قليلًا من الوقت، وبعد أن تنتهي، ستحصل على نافذة شبيهة بما يلي: احرص على اختيار تشغيل XAMPP من تحديد صندوق الاختيار إن لم يكن كذلك، ثم انقر الزر Finish ليعمل تطبيق الإدارة الخاص بـ XAMPP كما يظهر من الشكل التالي: انقر لسان التبويب Manage Servers من الأعلى لتحصل على شكل شبيه بما يلي: نلاحظ من الشكل السابق أنّ كل من الخادومين MySQL Database و Apache Web Server هما حاليًا في طور التشغيل Running. إن لم يكونا كذلك، فيمكنك تحديد كل منهما على حدة ونقر زر Start الذي يظهر في الجهة اليمنى من الشكل السابق. للتأكّد من نجاح عمليّة التنصيب السابقة، افتح متصفّح الانترنت لديك، ثم اكتب ضمن شريط العنوان ما يلي: http://ubuntu ثم اضغط الزر Enter، يجب أن تحصل على شكل شبيه بالشكل التالي: نكون عند هذه النقطة قد انتهينا من تنصيب XAMPP وبتنا مستعدّين لتنصيب ماجنتو. تحميل وتنصيب ماجنتو انتقل بمتصفّح الويب إلى العنوان التالي https://bitnami.com/stack/xampp لعرض التطبيقات التي توفرها Bitnami لتوزيعة XAMPP. ثم استخدام شريط التمرير حتى تصل إلى ماجنتو Magento كما في الشكل التالي: انقر زر Download الخاص بنظام التشغيل لينكس مع معمارية 64 بت كما في الشكل السابق لتبدأ عملية التحميل. بعد الانتهاء من التحميل، انتقل باستخدام الطرفية Terminal إلى المجلّد الذي يحوي الملف المُحمَّل. بالنسبة إليّ كان الملف يحمل الاسم التالي وهو موجود ضمن المجلّد Documents: bitnami-magento-2.1.0-2-module-linux-x64-installer.run نفّذ الأمرين التاليين ضمن الطرفية: sudo chmod 755 bitnami-magento-2.1.0-2-module-linux-x64-installer.run sudo ./bitnami-magento-2.1.0-2-module-linux-x64-installer.run كما في الشكل التالي: لاحظ من الشكل السابق أنّ الطرفية قد طلبت كلمة المرور للمستخدم الحالي، كما هو الحال عند تنصيب XAMPP وذلك لأنّني أعدت تشغيل الطرفية من جديد. بمجرّد تنفيذ الأمر الثاني سيبدأ عمل برنامج التنصيب الخاص بماجنتو، حيث ستظهر لك رسالة ترحيبيّة من برنامج الإعداد كما يلي: انقر Next ليعرض لك برنامج الإعداد نافذة تفيد بالمكوّنات المراد تنصيبها. يوجد مكوّن واحد هو ماجنتو Magento يجب أن يكون في حالة اختيار. انقر Next لتصل إلى النافذة التي تحدّد المسار الذي سيتم فيه نسخ الملفات. يجب أن يكون هذا المسار هو /opt/lampp انقر زر Next مرّة أخرى لتصل إلى النافذة التالية: ستطلب هذه النافذة بعض المعلومات الشخصيّة مثل الاسم المرغوب لتسجيل الدخول على ماجنتو (Login) والاسم الحقيقي والبريد الإلكتروني. كما ستطلب منك تعيين كلمة المرور الخاصة بتطبيق ماجنتو. بعد أن تنتهي من كتابة البيانات المطلوبة انقر Next لتصل إلى النافذة التالية: تطلب منك النافذة السابقة تحديد عنوان المضيف لإنشاء الروابط الداخلية. وهنا ينبغي أن تكتب العنوان الخاص بموقعك. في حالتنا هذه، استخدمت العنوان المحلّي 127.0.1.1 فحسب. يمكن بالتأكيد تغيير هذا العنوان فيما بعد. انقر الآن الزر Next لتصل إلى النافذة الخاصة بإعدادات خادوم البريد الصادر SMTP الذي سيستخدمه ماجنتو لإرسال رسائل البريد الإلكتروني. انظر الشكل التالي: لاحظ أنّني قد اخترت مزوّد خدمة GMail للبريد الصادر SMTP. أدخل البريد الإلكتروني الذي ترغب استخدامه مع هذه الخدمة، ثم زوّد برنامج الإعداد بكلمة المرور لهذا الحساب. انقر Next لتصل إلى نافذة تعرض عليك نشر deploy نسخة ماجنتو هذه إلى الخدمة السحابية الخاصة بشركة Bitnami كما في الشكل التالي: أزل الاختيار من الصندوق ثم انقر زر Next. سيعرض برنامج الإعداد رسالة تفيد بأنّه جاهز لبدء عمليّة التنصيب. انقر Next للبدء. سيستغرق الأمر بعض الوقت، وبعد الانتهاء سيعرض برنامج الإعداد رسالة تفيد بانتهاء عمليّة التنصيب ويعرض عليك تشغيل ماجنتو فورًا. كما في الشكل التالي: انقر على زر Finish لتختفي هذه النافذة وتظهر نافذة متصفّح الويب وقد انتقلت لتعرض الصفحة الرئيسيّة لمتجر ماجنتو: نكون بذلك قد انتهينا من تنصيب ماجنتو وبات جاهزًا للعمل. الخلاصة تعلّمنا في هذا الدرس كيفيّة تنصيب تطبيق ماجنتو بشكل عمليّ وسهل. حيث مررنا بخطوتين رئيسيتين. الأولى هي تنصيب توزيعة XAMPP التي تتضمن خادوم الويب Apache وخادوم قاعدة البيانات MySQL. أمّا الخطوة الثانية فكانت تنصيب ماجنتو من خلال برنامج إعداد مخصّص من Bitnami لكي ينصّب ماجنتو بوجود التوزيعة XAMPP. سنتابع عملنا في الدرس القادم في إلقاء نظرة على المنتجات في ماجنتو.

يُعتبر خادوما الويب Apache و Nginx الأكثر شهرةً من بين الخواديم المفتوحة المصدر في عالم الشبكة العنكبوتيّة، على اعتبار أنّهما مسؤولان عن خدمة وتأمين نصف تدفّق البيانات على الإنترنت، وعلى مَقدرة على تولّي مُختلف حجوم الأحمال، والعمل مع برمجيات أخرى في سبيل توفير حزمة من خدمات الويب الشاملة والكاملة لتلبية مُختلف الاحتياجات. بينما يَتشارك الخادومان Apache و Ngnix العديد من الميّزات والخاصيّات، فلا يُمكن اعتبارهما مُتشابهان، أو التفكير بأن أحدهما هو بديل عن الآخر، فكل منهما يتفّوق عن الآخر بشيءٍ ما، وعلى مُدير النظام فهم وإدراك لماذا يجب اختيار أحدهما دون الآخر، فهذا الدليل يَهدف إلى مُناقشة كيف أنّ كُل خادوم يَتميّز ويَبرز في شيء ويُخفق في آخر. مقدّمة عامّةسيتمّ أخذ نظرة سريعة عن تاريخ وبداية المشروعين وخواصّهم العامّة قبل التعمّق في الاختلاف بينهما. تاريخ خادوم الويب Apacheأَنْشَأَ “روبت ماك كول” (Robert McCool) “خادم الـ HTTP أباتشي” (Apache HTTP Server) في عام 1995، وتمّ مُتابعة تطويره تحت مظلّة “مُنشأةُ برمجيات أباتشي” (Apache Software Foundation) مُنذ العام 1999، وكان هذا الخادم هو المشروع الأساسي للمُنشأة والأكثر شهرةً عن باقي البرمجيات، فأصبح ببساطة يُشار إليه بالاسم “Apache”. يُعتبر خادم الويب أباتشي الخادم الأكثر استخدامًا على الإنترنت منذ العام 1996، وبسبب هذه الشهرة، استفاد أباتشي من توثيق ودعم باقي مشاريع البرمجيات الأُخرى. يَختار مُدراء الأنظمة الخادم أباتشي غالبًا بسبب مرونته، وقُدرته على التحمّل، وتوفّر دعمه العالي والمُنتشر، كما يُحسب له قابليته على التوسّع عبر نظام الوحدات (modules) الديناميكيّة، واستطاعته على مُعالجة عدد كبير من اللغات المُفسّرة (interpreted languages) من دون الحاجة إلى برمجيّة مٌستقلّة وسيطة. تاريخ خادوم الويب Nginxبَدأ “ايجور سيسيوﭫ” في عام 2002 العمل Nginx للإجابة وحلّ المُشكلة المعروفة بالاسم C10K، والّتي كانت تُشكّل تحدّيًا كبيرًا لخوادم الويب لتُصبح قادرة على تولّي عشرة آلاف اتصال مُتزامن (concurrent) وذلك في تلبية حاجة الويب الحديث، وأُنتجت الإصدارة الأوليّة والمُتاحة للعُموم في عام 2004 مُقدمةً حلًا لهذه المُشكلة، وذلك بالاعتماد على معماريّة مدفوعة بالحالة (event-driven) ولا مُتزامنة. انتشر Nginx كالنار في الهشيم مُنذ إصداره، بمُقتضى خفته واستخدامه الخفيف للمَوارد، وقدرته على التوسّع وتحمّل الضغط العالي وبأقل عتاد مُمكن، وتفوّق Nginx بتأمين المُحتوى الثّابت (static content) بسرعة، وبتصميمه لتمرير الطلبات الديناميكيّة (المُتغيّرة) إلى برمجيات أُخرى قادرة على مُعالجة هذا النوع من المُحتوى. يختار مُدراء الأنظمة الخادم Nginx غالبًا بسبب استهلاكه الأمثل للمَوارد، واستجابته العالية مع الضغط المتزايد. معماريّة مُعالجة الاتصال (Connection Handling Architecture)يَكمن الاختلاف الواضح بين أباتشي و Nginx في طريقة كلٍ منهما في مُعالجة الاتصالات وتدفّق البيانات (traffic)، وربّما هذا السبب وراء الاختلاف في طريقة كل من الخادمين في الاستجابة إلى حالة تدفّق البيانات المُختلفة. وحدات أباتشي (Apache Modules)يقدّم أباتشي تشكيلةً من وحدات المُعالجة المُتعدّدة (multi-processing)، والّتي يُطلق عليها بـ MPMs، والغرض منها تحديد آليّة مُعالجة طلبات العميل، ويَسمح ذلك مُدراء الأنظمة عامّةً بالتبديل بين معماريّة مُعالجة الاتصال بسهولة، والوحدات هي: mpm_prefork: تَستنسخ وتُوالد هذه الوحدة الخاصّة بالمُعالجة عمليّات (processes) باستخدام سلسلة وحيدة (single thread)، على أنّ تكون كل عمليّة لمُعالجة طلب، ويستطيع كل ابن مُعالجة اتصال واحد في نفس الوقت، وطالما أنّ عدد الطلبات أقل من عدد العمليّات، فستكون هذه الوحدة سريعةً جدًا، ولكن يَنخفض الأداء بسرعة بعد تخطّي الطلبات عدد العمليّات، ولذلك لا يُعتبر هذا النمط بالخيار الجيّد للعديد من السيناريوهات، فكل عمليّة لها تأثير بليغ على استهلاك الذاكرة (RAM)، ولهذا السبب تُصعّب هذه الوحدة من عمليّة التوسّع بطريقة مُلائمة، ومع هذا تبقى هذه الوحدة خيارًا جيّدًا إن تمّ استخدامها مقترنةً مع مُقوّمات (components) أُخرى لم تُبنى بالأساس آخذةً بعين الاعتبار السلاسل (threads)، فلغة PHP ليست سلسلة آمنة (thread-safe)، ولذلك يُنصح بهذه الوحدة باعتبارها الطريقة الوحيدة الآمنة للعمل مع mod_php والّتي هي وحدة من وحدات أباتشي لمُعالجة هذا النوع من الملفّات. mpm_worker: تستنسخ وتُوالد هذه الوحدة عمليّات (processes) كل منها ذات قُدرة على إدارة سلاسل مُتعدّدة (multiple threads)، تستطيع كل واحدة من هذه السلاسل مُعالجة اتصال وحيد، تُعتبر هذه السلاسل أكثر كفاءة من العمليّات، بسبب أنّ هذه الوحدة تتوسّع (scales)، وتتحمّل المزيد من الضغط أفضل من الوحدة prefork MPM، وباعتبار أنّه يوجد سلاسل أكثر من العمليّات، فهذا يعني أيضًا أنّ الاتصالات الجديدة تستطيع مُباشرةً استهلاك واستخدام سلسلةبدلًا من اضطرارها إلى الانتظار لتوفّر عمليّة مُتاحة. mpm_event: تَعمل هذه الوحدة بشكل مُشابه إلى الوحدة worker، ولكنها مُحسّنة لتتولّى اتصالات keep-alive، فعند استخدام الوحدة worker فإن الاتصال سيَحتفظ بالسلسلة (thread) بصرف النظر فيما إذا كان الطلب نشطًا فيما صُنع من أجله ما دام الاتصال محفوظًا نشطًا، فالوحدة mpm_event تتولّى الاتصالات keep-alive بالاحتفاظ جانبًا بسلاسل مكرّسة لمُعالجتها، وبتمرير الطلبات النشطة إلى سلاسل أُخرى، وهذا من شأنه أنّ يُبعد الوحدة من الغوص بطلبات keep-alive، الأمر الّذي يُجيز بتنفيذ الطلبات (execution) بشكل أسرع، وهذا الأسلوب أصبح يعمل بشكل مُستقر مع الإصدار Apache 2.4. أصبح الأمر أكثر وضوحًا، حيث تقدّم خوادم أباتشي بنية معماريّة مرنة للاختيار بين مُختلف الاتصالات وخوارزمية مُعيّنة في مُعالجة الطلبات، وبُنيت هذه الخيارات في الدرجة الأولى من تطوّر الخادم والحاجة المُتزايدة للاتصالات المُتزامنة لتواكب طبيعة الإنترنت بعد تغيرها وتطوّرها. آليّة مُعالجة الاتصال في خادوم Nginxقَدِم Nginx إلى عالم خوادم الويب بعد قدوم أباتشي، مَبنيًّا ومُعدًّا لمشاكل الاتصالات المُتزامنة (concurrency) الّتي تواجه المواقع عند التوسّع، مُحمّلًا بهذه المعرفة، صُمّمَ Nginx من جذوره ليستخدم خوارزميّة في مُعالجة اتصالات مدفوعة بالحالة (event-driven)، غير مُستوقفة (non-blocking)، ولا مُتزامِنة. يستنسخ ويُوالد Nginx من العمليّات العاملة (worker processes)، ويستطيع كلٍ مِنها مُعالجة آلاف الاتصالات، وتُنجذ العمليّات العاملة ذلك عن طريق تطبيق/تنفيذ آلية حلقيّة سريعة، والّتي تفحص بشكل مُستمر حالات العمليّات (processes events)، وإن فصل المُهمّة الفعليّة عن الاتصالات يسمح لكلعامل بالاهتمام بنفسه باتصال فقط عند بدء حالة جديدة. يتموضع كل اتصال مُعالج من قبل العامل ضمن حلقة الحالة (event loop) في مكان تواجد بقية الاتصالات، وتُعالج الأحداث بشكل لا مُتزامن ضمن الحلقة، ليتمّ إنجاز المُهمّة بطريقة غير مُستوقفة (non-blocking)، وعندما يُغلق الاتصال سيتمّ نزعه من الحلقة. يَسمح هذا الأسلوب من مُعالجة الاتصال Nginx بتحمّل الضغط العالي بشكل لا يُصدّق وبأقل المَوارد المُتاحة، وباعتبار أنّ الخادم ذو سلسلة وحيدة (single-threaded) ولا تتوالد العمليّات لتُعالج كل اتصال جديد، فإن استهلاك المُعالج (CPU)، والذّاكرة يبقى ثابتًا نسبيّا، حتّى في أوقات الذروة. كيف يُعالج أباتشي و Nginx المُحتوى الثّابت والمحتوى الديناميكي (المُتغيّر)إن أبرز ما يتمّ النظر إليه عند المُقارنة بين الخادمين هي طريقة كلٍ منهما في التعامل مع طلبات المُحتوى الثّابت (static)، والمُحتوى المُتغيّر (dynamic). كيف يتعامل أباتشي مع المُحتوى الثّابت والمُتغيّرتستطيع خوادم أباتشي التعامل مع المُحتوى الثّابت باستخدام الطريقة التقليديّة المُعتمدة على الملفّات، ويعود أداء هذه الإجراءات (operations) في الدرجة الأولى على دور ووظيفة أساليب الوحدات (MPM) المشروحة سابقًا. يستطيع أباتشي أيضًا مُعالجة المُحتوى الديناميكي (المُتغيّر) بدمج مُعالج اللغة المُراد مُعالجتها داخل كل من نماذجه العاملة (worker instances)، وهذا يَسمح له بتنفيذ المُحتوى الديناميكي داخل خادم الويب نفسه بدون الحاجة إلى الاعتماد على مُقوّمات خارجيّة، ومن المُمكن تفعيل هذه المُعالجات الديناميكيّة (المُتغيّرة) من خلال استخدام وحدات قابلة للتحميل بشكل ديناميكي. إن قدرة أباتشي على مُعالجة المُحتوى الديناميكي بشكل داخلي تعني أنّ الإعداد يُصبح أسهل لمُعالجة هذا النوع من المُحتوى، فليس من الضروري تنسيق عمليّة الربط مع برمجيات إضافيّة، وتستطيع الوحدات وبسهولة أنّ تقوم بالتبديل عندما تتغيّر مُتطلّبات المُحتوى. كيف يتعامل Nginx مع المُحتوى الثّابت والمُتغيّرلا يَملك Nginx بطبيعته أي قدرة على مُعالجة المُحتوى الديناميكي، ولمُعالجة شيفرة PHP وطلبات المُحتوى الديناميكي، فإن على Nginx تمرير الطلبات إلى مُعالج خارجي من أجل التنفيذ (execution) والانتظار ريثما يتم الانتهاء من مُعالجة هذا المُحتوى ليتمّ إعادة إعادته، ومن ثم عرض النتائج على العميل. يَنبغي على مُدراء الأنظمة الانتباه إلى أنّ الأسلوب الّذي ينتهجه Nginx يستوجب إعدادًا بينه وبين المُعالج وباستخدام واحدًا من البرتوكولات الّتي يفهمها Nginx أمثال: HTTP, FastCGI, SCGI,uWSGI, memcache، وهذا من شأنه أنّ يُعقّد الأمور بعض الشيء، خصوصًا عند مُحاولة توقّع عدد الاتصالات اللازم السماح بها، حيثُ أنّه سيتمّ استخدام اتصالًا إضافيًا لكل مُعالج يتمّ استدعاؤه. من ناحية أخرى، إن هذا الأسلوب يقدّم بعضًا من الأفضليّة، عندما نعلم أنّ مُفسّر المُحتوى الديناميكي غير مُدمج في عمليّة العامل، وتكلفة هذه الطريقة ستُدفع للمُحتوى الديناميكي فقط، وعلى أنّ يُقدّم المُحتوى الثّابت بطريقة مُباشرة، ولا يتمّ الاتصال بالمُفسر إلا عند الحاجة، والجدير بالذكر أنّ أباتشي يستطيع العمل بهذا الأسلوب، ولكن بعمله ذلك سيتخلّى عندها عن بعض ميزاته. الاختلاف بين الإعداد الموزّع (Distributed) والإعداد المركزي (Centralized)يَعتبر مُدراء الأنظمة الاختلاف الأكبر والبارز بين هذين الخادمين هو فيما إذا كان الإعداد والتخصيص على مُستوى المسار مسموحًا أو لا ضمن مسارات (directories)المُحتوى. فلسفة Apache في الإعداديُضمّن أباتشي خيارًا للسماح بالإعداد لكل مسار عن طريق تَفحُّص (inspecting) وتفسير (interpreting) التعليمات أو التوجيهات الموجودة في الملفات المخفيّة داخل مسارات المُحتوى نفسها، وهذه الملفّات معروفة بملفات .htaccess. باعتبار أنّ هذه الملفّات تَقطن داخل مسارات المُحتوى نفسها، فعند مُعالجة طلبٍ ما، فإن أباتشي يَفحص كل جزء من مسار الملفّ المطلوب باحثًا عن ملفّ .htaccess ليُطبّق التوجيهات الّتي بداخله، وهذا من شأنه أنّ يسمح للإعداد اللامركزي لخادم الويب، والذي غالبًا ما يُستخدم لإنجاز: إعادة كتابة عنوان الموقع (URL rewrites)تقييد الوصول (access restrictions)التفويض والمُصادقة (authorization and authentication)سياسات التخبئة (caching policies)بالطبع يُمكن للأمثلة السابقة إعدادها عن طريق ملفّ إعدادات أباتشي الرئيسي، ولكن استخدام ملفات.htaccess يَملك بعض الميزات: أوّلًا، باعتبار أنّها تُفسّر في كل مرّة توجد بها مع المسار المطلوب، فهي تُنفّذ مُباشرةً بدون إعادة تحميل الخادم.ثانيًا، تجعل من المُمكن السماح للمُستخدِمين غير المصرّح لهم بالتحكم بجانب معيّن من المُحتوى الخاصّة بهم بدون إعطائهم تحكم كامل لملفّ الإعدادات.يُقدّم هذا النمط من الإعداد طريقة سهلة ونموذجيّة، وخاصّة لبعض برمجيات الويب، مثل أنظمة إدارة المُحتوى (CMS)، لغرض إعداد بيئتها بدون مَنح إذن وصول إلى ملفّ إعدادات مركزيّ، وكما هو معروف يُستخدم هذا الأسلوب مع مزودات الاستضافة المُشتركة (shared hosting providers) لصون والحفاظ على الإعدادات الرئيسية مع إمكانيّة منح العُملاء أفضليّة التحكّم بمسارات مُعيّنة. فلسفة Nginx في الإعدادلا يُفسّر Nginx ملفّات .htaccess، ولا يُقدّم أي آليّة للتعامل مع كل مسار من دون استخدام ملفّ إعدادات رئيسي، قد يبدو هذا الأسلوب أقل مرونةً من أسلوب أباتشي، ولكن من ناحية أُخرى فلهذا الأسلوب أفضليته. إن عدم الاعتماد على نظام ملفّات .htaccess الخاصّ بالإعداد على مستوى المسارات يُقدّم سرعةً في الأداءً، فخادم أباتشي عليه القيام بتفحّص المسار الجذر لكل طلب يصله، وعند وجود ملفّ أو أكثر خلال عمليّة البحث، يتم قراءة محتوياته وتفسيرها، ولكن Nginx لا يفعل ذلك، فهو يخدم الطلبات بسرعة أكبر بالاعتماد على مكان وحيد للبحث عنه. أفضليّة أُخرى مُتعلّقة بالحماية، فإن توزيع ملفّات الإعدادات على مستوى المسارات يوزّع مسؤوليّة الحماية على كل المُستخدِمين، الّذين قد يكونوا في معظم الأحوال غير موثوقون لتولّي هذه المُهمّة بالشكل الأمثل، فعندما يقوم مُدير النظام بتولّي مُهمة التحكم بالخادم ككل، يمنع ذلك من حدوث أخطاء، والتي قد تحدث في حال منح صلاحيات وصول لأطراف أُخرى. يجدر الذكر أنّه من المُمكن تعطيل تفسير ملفّات .htaccess’ فيأباتشي`، في حال أنها تُشكل نوعًا من القلق لمُدير النّظام. الاختلاف بين تفسير الملفّات وتفسير URIلا يقتصر الاختلاف بين الخادومين على ما سبق فقط، فيظهر الاختلاف الآخر في كيفيّة تفسير كلٍ منهما للطلبات (requests) وربطها مع المَوارد المُتواجدة على النّظام. كيف يُفسر Apache الطلباتيقدّم أباتشي القدرة على تفسير الطلب إما كمَورد فيزيائي (حقيقي) على نظام الملفّات (filesystem) أو عنوان URI الّذي قد يحتاج أسلوب أكثر تجرّد، ويستخدم أباتشي بشكلٍ عام للأسلوب الأول كتل (blocks) وهي إما <Directory> أو <Files>، بينما يستخدم كتل <Location>للمَوارد الأكثر تجرّدًا. صُمّم أباتشي من الأساس كخادم ويب، لذلك في مُعظم الأحيان فإن السلوك الافتراضيّ هو تفسير الطلبات كمَوارد نظام ملفّات (filesystem)، حيثُ يبدأ بتتبّع جذر المُستند وإلحاقه بجزئية الطلب متبوعًا باسم المُضيف (host) ورقم المنفذ في مُحاولة لإيجاد الملفّ المطلوب، بمعنى آخر وببساطة، تتمثّل هرميّة نظام الملفّات على الويب كشجرة مُستند. يُقدّم أباتشي عددًا من البدائل عندما لا يتوافق الطلب مع نظام الملفّات المقصود، فمثلًا من المُمكن استخدام الموجّه Alias لربط عنوان البديل، مع العلم أنّ استخدام الكتل <Location> هو طريقة للتعامل مع URI نفسها بدلًا من نظام الملفّات، كما يُمكن استخدام التعابير النمطيّة (regular expression)، والّتي من المُمكن استخدامها لتطبيق الإعداد بسهولة أكبر في كامل نظام الملفّات. يُعوّل أباتشي على نظام الملفّات بشكل كبير، يظهر ذلك جليًا في اعتماده على ملفّات .htaccessلإعداد كل مسار، حتّى أنّ التوثيق الرسميّ الخاصّ به يحذر من استخدام كتل مُعتمدة على URI في تقييد الوصول عندما يكون الطلب يَعتمد بشكل أو بآخر على نظام الملفّات. كيف يُفسّر Nginx الطلباتأُنشِأ Nginx ليكون خادمًا للويب وخادمًا وكيلًا/وسيطًا (proxy server)، ونظرًا إلى المعماريّة المطلوبة للعمل بهذه الأدوار، فإنه يعمل بشكل رئيسي مع URIs، والتحويل إلى نظام الملفّات عند الضرورة. يُمكن رؤية ذلك في بعض جوانب بناء وتفسير ملفّات إعدادات Nginx، فلا يوفّر Nginx آليّة لتحديد إعدادًا لمسار نظام الملفّات، بل يَستعيض عنها بتحليل URI نفسه. يُمكن توضيح ذلك بالمثال، كتل الإعداد الأوليّ لـ Nginx هي: server و location، الكتلة serverتُفسّر المُضيف الجاري طلبه، بينما الكتل مسؤولة عن مُطابقة أجزاء من URI التي تأتي بعد المُضيف والمنفذ، في هذه المرحلة يتمّ تفسير الطلب كـ URI، وليس كعنوان على نظام الملفّات. يتوجّب في نهاية المطاف على جميع الطلبات أنّ تُربط مع عنوان على نظام الملفّات وذلك للملفّات الثّابتة، فأولًا، سيَختار Nginx كتل server و location الّتي سوف تتولّى الطلب، ومن ثم ضم جزر المُستند مع الـ URI. إن تحليل ومُعالجة الطلب قبل كل شيء على شكل URIs بدلًا من عناوين نظام الملفّات يَسمح لـ Nginxالعمل بسهولة وعلى حدٍّ سواء كخادم وسيط (بروكسي)، وكخادم بريد، وخادم ويب، فقد تمّ إعداده ليُلائم كيف له أنّ يستجيب لأنماط الطلبات المُختلفة، ولا يفحص Nginx نظام الملفّات حتّى يكون جاهزًا ليَخدم الطلب، وهذا يُفسّر لماذا هو لا يُطبّق نمط ملفّات .htaccess. الوحداتيتوسع كلا الخادومان عن طريق نظام الوحدات، ولكن طريقة عملهما تختلف عن الآخر بشكل كبير. كيف يستخدم أباتشي نظام الوحدات (Modules)؟يَسمح نظام وحدات أباتشي بطريقة آليّة وديناميكيّة بتركيب ونزع الوحدات ليتناسب مع مُتطلّبات مُدير النظام خلال عمليّة تشغيل الخادم، وتتواجد نواة أباتشي دائمًا بكل جاهزية، بينما يُمكن تشغيل أو تعطيل الوحدات، أو حتّى حذفها أو إضافة ما يلزم إلى الخادم. يستخدم أباتشي الوحدات في العديد من المهام، ونظرًا للباع الطويل لمنصة أباتشي، فيتوفّر عدد هائل من مكتبات الوحدات، والّتي من المُمكن استخدامها في تعديل بعض الوظائف الداخليّة في بنية خادم أباتشي، فمثلًا الوحدة mod_php تقوم بدمج مُفسّر PHP داخل كل عامل (worker). لا تنحصر الوحدات لمُعالجة المُحتوى الديناميكي (المُتغيّر) فقط، فيُمكن استخدامها في العديد من الوظائف، فيُمكن استخدامها في: rewriting URLs: إعادة كتابة العناوينauthenticating: المُصادقةlogging: التّتبّعcaching: التخبئةcompression: الضغطproxying: الوساطةencrypting: التشفيركيف يتعامل Nginx مع نظام الوحدات (Modules)يُطبّق ويتعامل Nginx مع نظام الوحدات، ولكن يختلف الأمر عما هو في نظام أباتشي، فلا تُحمّل الوحدات بشكل ديناميكي في نظام Nginx، لذلك يجب على هذه الوحدات أنّ تُختار وتُترجم (compiled) إلى النواة. قد يبدو الأمر صعبًا للعديد من المُستخدمين وخاصّة لهؤلاء الذين لا يُحبذون صيانة برمجياتهم المُترجمة (compiled) بدون الاستعانة بنظام حزم تقليدي، وعلى الرغم من أنّ حزم الموزّع تتضمّن الوحدات الأكثر استخدامًا، ولكن عند الحاجة إلى وحدة غير شائعة، سيتوجب على مُدير النظام بناء الخادم من المصدر بنفسه. تَبقى وحدات Nginx مع ذلك ذات فائدة، وتسمح لمُدير النّظام بتحديد ماذا يجب على الخادم أنّ يحتوي من وظائف، أيضًا بعض المُدراء ينظر إلى الأمر من منظور الحماية، حيثُ أنّ المُكوّنات الاعتباطيّة لا يُمكن أن تُدرج داخل الخادم. تُقدّم وحدات Nginx مقدرات مُماثلة للوحدات الّتي المُقدّمة من أباتشي، على سبيل المثال، توفّر وحدات Nginx: proxying support: الوساطةcompression: الضغطlogging: التّتبّعrewriting: إعادة كتابة العنوانauthentication: المُصادقةencryption: التشفيرالدعم والتوافُقيّة والتوثيقيجب دائمًا التأكد من آليّة بناء الخادم ومُتطلباتها، وما الّذي على مُدير النّظام عمله لبناء خادم يعمل بأبسط الإمكانيات، وما هو حجم الدعم والمُساعدة المتوفّر لهذه البرمجية. الدعم في أباتشييُعرف الخادم أباتشي بباعه الطويل في هذا المجال، ولذلك فإن الدعم الخاصّ به متواجد وبقوّة، حيثُ يتوفّر توثيق مُمتاز لمكتباته الخاصّة به ومكتبات الطرف الثالث (الخارجيّة)، وعلى كافّة المُستويات، سواء كان لنواة الخادم أو للجزئيات المُرتبطة ببرمجيات أُخرى. يتوفّر بجانب التوثيق، العديد من الأدوات ومشاريع الويب لتسريع بدء العمل مع بيئة الخادم، وهي موجودة ضمن المشاريع نفسها أو مُتوفّرة ضمن برمجيات الحزم المعروفة. يَملك أباتشي بشكلٍ عام دعمًا قويًا من قِبل مشاريع الطرف الثالث، وذلك بسبب حصته السوقيّة، وقِدَمه، كما يَملك مُعظم مُدراء الأنظمة بشكل أو بآخر معرفة جيّدة بخادم أباتشي، ليس فقط بسبب انتشاره، ولكن أيضًا بسبب أنّ معظمهم بشكل أو بآخر يستخدم الاستضافة المُشتركة (shared-hosting)، والّتي تعتمد على خادم أباتشي بشكل حصري، لمقدرته الإدارية الموزّعة باستخدام ملفّ .htaccess. الدعم في Nginxيكسب Nginx المزيد من الدعم مع ازدياد المُستخدِمين بسبب أدائه العالي، ولكن يبقى عليه التطوير من نفسه في بعض الجزئيات. قد كان من الصعب إيجاد توثيق مفهوم وواضح بالغة الإنكليزية للخادم Nginx في البداية، نظرًا إلى أنّ تطويره وتوثيقه تمّ بالغة الروسية، ومع ازدياد الاهتمام بالمشروع، أصبح هناك وفرة من المصادر على الموقع الرسميّ وغيره من الدعم الخارجي. أصبح الدعم متوفّرًا أكثر من ذي قبل فيما يخص تطبيقات الطرف الثالث، وبدأت بعض الحزم بتقدم خيارات الإعداد التلقائي سواءً لـ أباتشي أو Nginx، وعند عدم توفّر الدعم، فإن إعداد Nginx مع البرمجيات البديلة عادةً ما يكون واضحًا ومُيسرًا طالما أنّ برمجية الطرف الثالث تملك توثيقًا جيّدًا لمُتطلّباتها. استخدام Apache و Nginx معًاتمّ عرض فوائد وقصور كلا الخادومين، ويجب على مُدير النّظام في هذه المرحلة أنّ يُحدّد أيًا منهما يُناسب احتياجاته، ولكن يجد العديد من المُستخدِمين أنّه من المُمكن تقوية خادوم الويب عند استخدام كلٍ من أباتشي و Nginx جنبًا إلى جنب. إن إتمام هذه الشراكة يتمّ عن طريق تَمَوْضُع Nginx أمام أباتشي كوكيل/وسيط عكسي (reverse proxy)، وهذه يسمح لـ Nginx بمُعالجة جميع الطلبات من العُملاء، الأمر الّذي يَسمح بالاستفادة من سرعة Nginx وقدرته على تولّي عدد كبير من الاتصال في وقتٍ واحد. إن خدمة الملفّات الثّابتة بسرعة كبيرة ومباشرةً إلى العُملاء، هو الأمر الّذي يتفوّق به Nginx، ولكن وللمُحتوى الديناميكي، ملفات PHP مثلًا، سيُوكل Nginx الطلبات إلى أباتشي لمُعالجتها والعودة بصفحة بالنتيجة النهائيّة، ليستطيع Nginx عندها تمرير المُحتوى إلى العميل. يعمل هذا الإعداد بشكل جيّد للعديد من مُدراء الأنظمة، وذلك بسبب أنّه يسمح لـ Nginx ليعمل كآلة فرز وتصنيف، بمعنى أنّه سيتولّى مُعالجة جميع الطلبات طالما أنّه يستطيع ذلك، وتمرير ما لا يستطيع التعامل معه، وبتخفيض الطلبات المطلوب من خادم أباتشي تولّيها، سيُخفف بعضًا من الاستيقاف (blocking) الّذي قد يحدث عندما يستهلك أباتشي المزيد من المُعالج. يَسمح هذا الإعداد أيضًا لمُدراء الأنظمة بالتوسّع عن طريق إضافة خادم خلفي (backend) على حسب الحاجة والضرورة، ومن المُمكن إعداد Nginx لتمرير الطلبات إلى تجمّع (pool) من الخوادم بسهولة، الأمر الّذي يزيد من الأداء والفعاليّة. الختاميُقدّم كلًا من أباتشي و Nginx مُرونة في الاستخدام، وقوّةً في الأداء، والتفضيل بينهما هو لأمرٌ يَعتمد على تقدير مُتطلبات ووظائف الخادم، وعلى مُدير النّظام أنّ لا يسأل: هو أفضل خادم ويب؟، بل السؤال الّذي يجب سؤاله هو، ما هو أفضل خادم ويب لمشروعي الّذي يتطلّب كذا وكذا؟ يوجد بالفعل اختلافات بين المشروعين، هذه الاختلافات من شأنها أن تأثر على الأداء، والقدرات، والوقت المُستغرق في إتمام أي منهما للعمل بالجاهزيّة الكاملة، ولكي يتمّ اختيار الأفضل يُنصح بعمل تسوية أو مقايضة بين المحاسن والمساوئ، ففي نهاية المطاف لا يوجد خادم يُلبي كافة الاحتياجات، ويَكمن الحلّ في ترتيب الأولويات. ترجمة –وبتصرّف– للمقال Apache vs Nginx: Practical Considerations لصاحبه Justin Ellingwood.

يُعتبَر خادوم ويب Apache الوسيلة الأكثر شعبيةً لتقديم المحتوى على شبكة الإنترنت، حيثُ يستعمله أكثر من نصف مواقع الويب على الشبكة لقدرته الفائقة ومرونته العالية. يُقسِّم خادوم Apache وظائفَه والعناصر التي تُكوِّنه إلى عدة وحدات يُمكِن تخصيصها وإعدادُها بشكل مستقل. تُسمَّى الوحدة الأساسية - التي تُمثِّل نطاقًا Domain أو موقع ويب - مُستضيفًا افتراضيًا Virtual host. تُتيح المُستضيفات الافتراضية إمكانية استضافة عدة نطاقات أو مواقع ويب على نفس العنوان باستخدام آليةٍ للمطابقة بين مُستضيف افتراضي وموقع ويب. تُناسِب هذه الطّريقة أي شخص يُريد استضافة عدة مواقع على نفس الخادوم الافتراضي الخاص Virtual private server, VPS. يُوجِّه كل واحد من النطاقات المضبوطة الزائرَ إلى مجلَّد مُحدَّد توجد به معلومات الموقع المطلوب دون أن يُشيرَ أبدًا إلى أن مواقع أخرى تُدار على نفس الخادوم. يُمكِن بطريقة المستضيفات الافتراضية ضبط عدد غير محدود من المواقع على نفس الخادوم ما دام يتحمّل عبئ الحِمل Load الذي تُمثِّله هذه المواقع. سنعرِض في هذا المقال طريقة إعداد مستضيفات افتراضية على خادوم ويب Apache يعمل على خادوم افتراضي خاص مع توزيعة أوبنتو 14.04. ستتعلَّم كيف تُقدِّم محتوى مختلِفا لزوّار متعدِّدين حسب النطاق الذي يطلبونه. المتطلباتقبل البدء في هذا الدّرس يجب إنشاء مستخدم آخر غير المستخدِم الجذر Root user كما هو موضَّح في الخطوات من 1 إلى 4 من الدرس الإعداد الابتدائي لخادوم أوبنتو. ستحتاج أيضًا إلى تثبيت خادوم ويب Apache لمتابعة الخطوات المذكروة في هذا الدّرس. إن لم تكُن ثبَّت البرنامج حتى الآن يُمكنك ذلك باستخدام أداة apt-get كما يلي: sudo apt-get update sudo apt-get install apache2بعد استكمال هذه الخطوات يُمكننا البدء. سنُنشئ خلال هذا الدرس مستضيفَيْن افتراضييْن، واحد للنطاق example.com والآخر لـ test.com. أثناء إعداد مستضيفاتك الافتراضية استخدِم النطاقات الخاصّة بك مكان المثاليْن المذكوريْن هنا. سنُريك خلال هذا الدّرس كيف تُحرِّر ملف المستضيفات على جهازك الشخصي Local hosts file لاختبار إعداداتك إن كنتَ تستخدم نطاقات وهمية. ستتمكَّن بهذه الطريقة من تجربة الإعدادات من جهازك الشخصي رغم أن المحتوى لن يكون مُتاحا لزوّار آخرين عبر النطاق الوهمي. الخطوة الأولى - أنشئ بنية المجلد Directory structureأول خطوة نقوم بها هي إنشاء بنية المجلَّد الذي سيحوي بيانات الموقِع الذي ننوي تقديمه إلى الزّوّار. يُعرَّف مبدأ المستند Document root بأنه المجلّد الأعلى مستوًى Top-level directory الذي سيبحث فيه خادوم وب Apache عن محتوى الموقع. بالنسبة لمثالنا سننشئ مبدأ مستند (مجلَّد) داخل المسار var/www/ لكلٍّ من المستضيفين الافتراضيّين الذين نعدهما. داخل كل من المجلَّدين نُنشئ مجلَّدًا باسم public_html، وهو المجلَّد الذي سيحوي ملفات الموقع وهو ما يمنح بعض المرونة في الاستضافة. لتطبيق ما ورد في الفقرة أعلاه نُنفِّذ الأوامر التالية: sudo mkdir -p /var/www/example.com/public_html sudo mkdir -p /var/www/test.com/public_htmlفي الأمرين السابقين يظهر كل من النطاقين الذين نريد تقديمهما من خادومنا الافتراضي الخاص باللون الأحمر. الخطوة الثانية - امنح الأذونات Permissionsأنشأنا في الخطوة الأولى بنية المجلَّدات، لكن هذه المجلَّدات مملوكة من المستخدِم الجذر، نظرا لاستخدام sudo أمام أمر إنشاء المجلّد. إن أردنا إعطاء المستخدِم العادي القدرة على تحرير الملفات الموجودة في مجلَّد الوب فبإمكاننا تغيير مُلكية هذه المجلّدات عن طريق الأمر: sudo chown -R $USER:$USER /var/www/example.com/public_html sudo chown -R $USER:$USER /var/www/test.com/public_htmlعند تنفيذ الأمر - بالضغط على زر Enter - فإن المتغيّر USER$ سيُبدَل بقيمته وهي اسم المستخدِم الحالي. ينتج عن الأمر تغيير ملكية المجلَّد public_html الذي يتضمّن محتوى الموقِع فيُصبِح المستخدم الحالي هو المالك بدلا من المستخدِم الجذر. سيتوجّب علينا أيضًا تغيير الأذونات قليلًا للتأكد من أنّ إذن القراءة متاح من مجلّد الويب العام (var/www/) وكل الملفات الموجودة داخله أو داخل المجلّدات المتفرّعة منه حتى يُقدَّم المحتوى بشكل صحيح: sudo chmod -R 755 /var/wwwلدى خادوم الويب الآن الأذونات التي يحتاجها لتقديم المحتوى، ولدى المستخدم أيضا القدرة على إنشاء وتحرير المجلَّدات التي يحتاجها. الخطوة الثالثة - أنشئ صفحات تجريبية Demo pages لكل مستضيف افتراضيفي هذه الخطوة سننشئ محتوى لتقديمه. الهدف من إنشاء المحتوى في هذه الخطوة توضيحي، لذا ستكون الصفحات بسيطة جدا: index.html لكل موقع. سنبدأ بـ example.com. نستطيع إنشاء وتحرير ملف index.html عن طريق محرِّر nano عبر الأمر التالي: nano /var/www/example.com/public_html/index.htmlأضف مستنَد HTML بسيطًا يُبرز اسم الموقع. يظهر الملف بالشكل التالي: <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title> Example.com أهلًا بك في موقع</title> </head> <body dir="rtl"> <h1>هنيئا لك! المُستضيف الافتراضي Example.com يعمل بشكل صحيح</h1> </body> </html>احفظ الملف (Ctrl+O ثم زر Enter) ثم أغلقه بعد الانتهاء من تحريره (Ctrl+x). ننسخ الملف ليكون أساس الموقع الثاني عبر الأمر : cp /var/www/example.com/public_html/index.html /var/www/test.com/public_html/index.htmlيُمكِن بعدها فتح الملف وتحرير المعلومات لتُناسب الموقع الثاني: nano /var/www/test.com/public_html/index.html<html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title> Test.com أهلًا بك في موقع</title> </head> <body dir="rtl"> <h1>هنيئا لك! المُستضيف الافتراضي Test.com يعمل بشكل صحيح</h1> </body> </html>احفظ الملف ثم أغلقه. لدينا الآن الصفحات الضرورية لاختبار إعداد المستضيف الافتراضي. الخطوة الرابعة - أنشئ ملفات مستضيفات افتراضية جديدةتُحدِّد ملفات المستضيفات الافتراضية إعدادات هذه المستضيفات كما أنها تُملي على خادوم ويب Apache الكيفية التي سيُجيب بها على طلبات النطاقات المختلفة. يأتي خادوم Apache بملف ابتدائي اسمه 000-default.conf لإعداد المستضيفات الافتراضية. يُمكننا استخدام هذا الملف للبدء، لذا سننسخ هذا الملف لإعداد المستضيفات الافتراضية الخاصة بنطاقاتنا. سنبدأ بإعداد أحد النطاقات ثم ننسخه إلى النطاق الثاني مع القيام بالتعديلات اللازمة. يجب - في الإعداد المبدئي لأوبنتو - أن ينتهي ملف المستضيف الافتراضي بالامتداد conf. أنشئ ملف المستضيف الافتراضي الأول. ابدأ بنسخ ملف النطاق الأول: sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/example.com.confافتَح الملف الجديد في المحرِّر بامتيازات المستخدِم الجذر : sudo nano /etc/apache2/sites-available/example.com.confسيبدو الملف بالشكل التّالي (حُذِفت التعليقات لجعل الملف أسهل للقراءة): <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>احفظ الملف ثم أغلقه بعد الانتهاء من تحريره. الخطوة الخامسة - فعل ملفات المستضيفات الافتراضية الجديدةبعد إنشاء ملفات إعداد المستضيفات الافتراضية نأتي لخطوة التفعيل؛ يوفِّر خادوم Apache بعض الأدوات لهذا الغرض. لتفعيل الموقعيْن نستخدم أداة a2ensite كما يلي: sudo a2ensite example.com.conf sudo a2ensite test.com.confثم نعيد تشغيل Apache لأخذ التغييرات بالاعتبار: sudo service apache2 restartأثناء إعادة تشغيل خادوم الوب قد تظهر رسالة كالتالية: * Restarting web server apache2 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لا يُمثِّل هذا التحذير أي خطر وليس له تأثير على موقعك. الخطوة السادسة - اضبط ملف المستضيفات المحلي (خطوة اختيارية)إن لم تتوفّر لديك أسماء نطاقات حقيقية لتجربة الخطوات المذكورة في هذا الدّرس يُمكنك اختيار نطاقات وهمية والتجربة بها على جهاز ك المحلي (الشخصي) عن طريق التعديل المؤقَّت على ملف المستضيفات المحلي. ستُوَجَّه كل طلبات النطاقات المضبوطة بهذه الطريقة إلى خادومك الافتراضي الخاص، تماما كما كان سيفعل نظام أسماء النِّطاقات Domain Name System, DNS لو استخدمتَ أسماء نطاقات مُسَجَّلة. ينبغي الانتباه أن هذه الطريقة ستعمل من جهازك الشخصي فقط وتقتصر على اختبار الإعدادات. تأكَّد من القيام بالخطوات التالية على جهازك المحلي وليس على خادومك الافتﻻاضي الخاص. ستحتاج لمعرفة كلمة سر اسم المستخدِم الجذر أو أن تكون ضمن مجموعة المديرين على نظام التشغيل. الأمر التالي يفتح ملف المستضيفات للتحرير على أنظمة Linux و Mac: sudo nano /etc/hostsبالنسبة لمستخدمي Windows توجد تعليمات التعديل على ملف المستضيفات هنا. ستحتاج لعنوان IP العمومي لخادومك الافتراضي الخاص والنطاق الذي تُريد استخدامه للوصول إلى الخادوم الافتراضي. يتكوَّن سطر ملف الإعداد من عنوان IP متبوعًا باسم النطاق. باعتبار أن 111.111.111.111 هو عنوان IP الخادوم نُضيف الأسطر التالية في أسفل ملف المستضيفات: 127.0.0.1 localhost 127.0.1.1 guest-desktop 111.111.111.111 example.com 111.111.111.111 test.comبهذه الطّريقة ستُوجَّه كل استعلامات الجهاز المحلي التي تطلُب النِّطاقين example.com أو test.com إلى الخادوم على العنوان 111.111.111.111، وهو ما يُساعدنا على اختبار إعدادات خادوم الوب إن لم نكن مالِكي النطاقيْن المذكوريْن. احفَظ الملف ثم أغلِقه. الخطوة السابعة - اختبر النتائجيُمكنك بعد الانتهاء من ضبط المُستضيفات الافتراضية اختبار الإعدادت بالذهاب إلى النطاقات المضبوطة عبر متصفِّح الوب: http://example.comيجب أن تكون النتيجة كما في الصّورة: الشيء بالنسبة للموقع الآخر: http://test.comستظهر الصّفحة التي أنشأتَها في الملف الثاني: يدل ظهور الصفحتين بشكل صحيح أن إعداد مستضيفيْن افتراضيّيْن على نفس الخادوم جرى بطريقة جيّدة. لا تنسَ حذف الأسطر الإضافية من ملف المستضيفات المحلي بعد التأكد من إعداد المستضيفات الافتراضية على الخادوم. أُضيفت هذه الأسطُر للاختبار فقط ومن الأحسن حذفها بعد انتهائه. ستحتاج إلى شراء وإعداد نطاقات إن احتجتَ دائما إلى خادومك عن طريق أسماء نطاقات. خاتمةستحصُل بعد متابعة هذا الدّرس على خادوم ويب واحد يتعامل مع نطاقيْن منفصلين. يُمكنك زيادة عدد النطاقات باتّباع الخطوات المذكورة أعلاه لإنشاء مستضيفات افتراضية جديدة. لا توجد تقييد على عدد النطاقات التي يُمكِن لـApache التعامل معها، أضِف ما تُريد من النطاقات ما دام الخادوم يستطيع تحمّلَها. ترجمة -وبتصرّف- للمقال How To Set Up Apache Virtual Hosts on Ubuntu 14.04 LTS لصاحبه Justin Ellingwood.

ما هو OPcache؟ يحتاج كلّ طلب Request في PHP إلى أن يُحلَّل Parsed، يُترجَم Compiled ثمّ يُنفَّذ Executed؛ لكن في حالات عديدة تؤدّي الطّلبات دائمًا إلى نفس النّتائج، وهو ما يعني أن الخادوم يكرّر في كلّ مرة الخطوات الثّلاث المذكورة دون حاجة لذلك. هنا يأتي دور أدوات التّخزين المؤقَّت للشّيفرة العمليّة Opcode (اختصار ل Operation code، وهو ناتج التّحليل ثمّ التّرجمة أي الصّيغة الّتي يُنفَّذ بها الطّلب)، ومن بينها OPcache. يتلخَّص عمل OPcache في الاحتفاظ بالشيفرة العمليّة في ذاكرة الوصول العشوائي RAM وتنفيذها - عند إعادة الطّلب - من الذّاكرة مباشرةً دون الحاجة للمرور بخطوتَيْ التّحليل والتّرجمة؛ وهو ما يعني اختصار الخطوات والتّقليل من حِمل العمل، غير الضّروريّ، على الخادوم. نفترض في هذا الدّرس وجود حزم LAMP مثبَّتة ومضبوطة على خادومك. تفعيل OPcache تأتي أداة OPcache مضمَّنةً في الإصدار 5.5 من PHP. الأمر التّالي يُظهر إصدار PHP المستخدَم: php -v عندي مثلًا: PHP 5.5.9-1ubuntu4.9 (cli) (built: Apr 17 2015 11:44:57) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies لاحظ السّطر الأخير: with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies يخبرنا هذا السّطر أن OPache مُثبَّت؛ وأنّ الإصدار المستخدَم هو 7.0.3. إذا اتّبعت خطوات كيف تُثبِّت وتؤمِّن phpMyAdmin على Ubuntu 14.04 فستجد أنّ OPcache مُفعَّل. للتّأكّد ننشئ ملفّ info.php (راجِع الدّرس السّابق) ثمّ ندخل إلى العنوان http://domain_or_ip/info.php حيث domain_or_ip نطاق أو عنوان IP الخادوم. في صفحة معلومات الخادوم نبحث عن بعض التّفاصيل. يُمكن ملاحظة أنّ ملفّ إعداد خادوم الويب المستخدَم هو etc/php5/apache2/php.ini/ وأنّ خادوم الويب يبحث عن ملفّات إعداد إضافيّة في المجلَّد etc/php5/apache2/conf.d/؛ تظهر ملفّات الإعداد الموجودة في هذا المجلّد ضمن خانة Additional .ini files parsed، ومن بينها الملفّ etc/php5/apache2/conf.d/05-opcache.ini/. يتحكّم هذا الملفّ في إعداد OPcache كما سنرى. إذا نزلنا أسفل الصّفحة فسنجد فقرات خاصّة ب OPcache: ما يهمّنا الآن من هذه الفقرة هو السّطر الأوّل: Opcode Caching Up and Running أي أنّ التّخزين المؤقَّت مُفعَّل ويعمل. إعداد OPcache توجد خيّارات عديدة لضبط آليّة عمل OPcache. سنتعرّض في هذه الفقرة لأهمّها. يقدّم توثيق PHP قائمة بجميع الخيّارات الموجودة. 1- حجم ذاكرة التّخزين المؤقّت تُحدّد تعليمة opcache.memory_consumption حجم الذّاكرة المخصَّصة لاستخدام OPcache، حيثُ تُخزّن الشيفرة العمليّة لسكربتات PHP. تُضاف هذه التّعليمة إلى ملفّ إعداد OPcache الموجد على المسار etc/php5/apache2/conf.d/05-opcache.ini/. نفتح الملفّ للتّحرير: sudo nano /etc/php5/apache2/conf.d/05-opcache.ini محتوى الملفّ: ; configuration for php ZendOpcache module ; priority=05 zend_extension=opcache.so ملحوظة: لتعطيل OPcache أضف علامة ; أما سطر zend_extension=opcache.so؛ ثمّ أعد تشغيل خادوم ويب Apache. ستلاحظ أنّ صفحة المعلومات لم تعد تظهر البيانات المتعلّقة ب Zend OPcache. نُضيف تعليمة opcache.memory_consumption ونحدّد قيمتها، علمًا أنّ القيمة الافتراضيّة هي 64MB. مثلًا، التّعليمة التّاليّة تحدّد حجم ذاكرة التّخزين المؤقّت ب128 ميغا بايت: opcache.memory_consumption=128 ينصح التّوثيق الرّسمي لOPcache بإعطاء قيمة 128 لهذه التّعليمة، إلّا أنّ الأمر يعتمد على قدرات خادومك ونوعيّة وعدد التّطبيقات والخدمات العاملة عليه. 2- الحدّ الأقصى لعدد الملفّات المُخزّنة تُتيح تعليمة opcache.max_accelerated_file تحديد عدد أقصى للملفّات المحتفظ بها في ذاكرة التّخزين المؤقَّت. القيمة المنصوح بها هي 4000: opcache.max_accelerated_files=4000 3- المدّة اللّازمة للتّحقّق من وجود تغيير على برنامج مُخزَّن في الذّاكرة تُحدّد تعليمة opcache.revalidate_freq مدّة زمنيّة (بالثّانيّة) يُتحقّق بعد انقضائها من وجود تغييرات على الملفّ المخزّن في ذاكرة الوصول العشوائيّ؛ إذا كان الاختبار إيجابيًّا، أي حدث تغيير، فإنّ الملفّ يُعاد تحليله وترجمته قبل أن يُخزّن من جديد. يُنصَح بقيمة 60 لهذه التّعليمة: opcache.revalidate_freq=60 ملحوظة: إضافة علامة ; في بداية سطر يعني تجاهلَه. في هذه الحالة، إذا كان السّطر يحوي تعليمة فلن تؤخَذ في الحسبان. يظهر الملفّ الآن بالمحتوى التّالي: ; configuration for php ZendOpcache module ; priority=05 zend_extension=opcache.so opcache.memory_consumption=128 opcache.max_accelerated_files=4000 opcache.revalidate_freq=60 لم يتبقّ إلا إعادة تشغيل خادوم الويب لتفعيل الخيّارات: sudo service apache2 restart ملحوظة: يمكن التّأكّد من عبر صفحة info.php حيث تظهر قيمة الخيّارات أعلاه في خانات بنفس أسماء الخيّارات. خاتمة يُساعد استخدام أداة OPcache في تحسين أداء الخادوم بشكل ملحوظ والاستفادة القصوى من موارد الجهاز. حاول - بحذر - تجربة إعدادات مختلفة وتفحّص تأثيراتها على الأداء حتى تجد الإعداد الأكثر مناسبةً لبيئة عملك. إذا أردت مواصلة التّحسين فدرس كيفيّة تثبيت وإعداد الذّاكرة المُخبّئة (Memcache) على Ubuntu خطوة جيّدة في هذا المجال.

ما الذي يجعل مشروعك مفتوح المصدر؟ أن تكون الشّيفرة متوفرةً مجانًا على الإنترنت؟ أو أن تستطيع استعماله، أو تعديله وإرساله إلى صديقك؟ إذا ابتغينا الدقة، فإن الرخصة هي التي تعطيك الامتيازات لفعل كل ما سبق ذكره. فعندما "تفتح" مصدر مشروعك، فعليك أن تُضمِّن ملف رخصة يُحدِّد ما هي الشروط التي سيُسمَح للآخرين باستعمال مشروعك وفقًا لها. لحسن الحظ، هنالك خياراتٌ عديدةٌ يمكنك الاختيار بينها، فلا حاجة إلى أن تكون محاميًا لفعل ذلك؛ لكن لسوء الحظ هنالك الكثير من الرخص، مما يجعلك تحتار أيهم ستختار. تنبيه: هذه هي طريقة ترخيص مشاريعي الخاصة، لكنني لست محاميًا وهذه المقالة لا تُمثِّل نصيحة قانونية. ما هي الرخص؟ عدد الرخص التي يمكن اعتبارها "حرة" (free) أو مفتوحة المصدر (open-source) بالمئات! إذا كنت تريد قوائم طويلة، فراجع القوائم الموجودة على موقع مشروع GNU و opensoucre.org أو على ويكيبيديا، وحتى تلك القوائم الطويلة ليست شاملة لجميع الرخص. وعلى الرغم من التعداد الكبير للرخص، لكن الفروقات بينها ليست محورية؛ والسبب وراء وجود عدد كبير منها هو أنَّ كاتبيها صعيبو المراس في اختيار الكلمات وبعض التفاصيل، لكن يمكن اعتبار شروط الكثير منها متماثلة. ادخل إلى موقع tl;drLegal لمراجعة سريعة لشروط مختلف الرخص. الرخص المتساهلة و Copyleft أكبر أمر يُفرِّق بين الرخص هو Copyleft، وهو مصطلحٌ أوجده مشروع غنو (GNU) لمنع الأشخاص الذين سيعيدون توزيع البرمجيات في المستقبل من تقييد الحريات التي أعطيتَها للمشروع عند إطلاقه، وهذا يعني أنَّه على أيّ شخصٍ يريد أن يُعيد توزيع نسخةٍ مُعدَّلةٍ من الشيفرة التي كتبتَها أن ينشر تعديلاته أيضًا. تُطبِّق بعض الرخص ذاك المبدأ (مثل GPL، و LGPL، وMPL) بينما لا تُطبقه الأخرى (مثل MIT، و Apache، و BSD). قد تكون رخص "copyleft" مفيدةً جدًا لمنع إساءة استعمال مشروعك، وقد تكون في بعض الأحيان معيقةً لاستعماله من الشركات التي قد لا تقدر على استعمال شيفرات مرخصة بتلك الرخصة في برمجياتها التجارية. مجال مشروعك أحد أهم الأشياء التي يجب أخذها بعين الاعتبار عند اختيار رخصة لمشروعك هو "المجال"؛ هل هو مكتبة برمجية، أم أداة للمطورين، أم تطبيق كامل للمستخدم النهائي؟ إذا كان سيُستعمَل مع مكتباتٍ أخرى، فعليك أن تكون حذرًا في اختيارك للرخصة بسبب مشاكل في التوافقية بين الرخص (سنشرح ذلك بعد قليل). أختارُ للتطبيقات الكاملة أو المنتجات، مثل تطبيقات الأندرويد أو تطبيقات سطح المكتب أو الأدوات التي تعمل من سطر الأوامر، رخصًا من نمط copyleft مثل GPLv3 التي تطمئنني أنَّ المشروع سيبقى مفتوح المصدر دومًا. وعندما تُطلِقُ مكتبة أو إطار عمل ليستعمله المطورون في مشاريعهم، فإن اختيارك سيصبح أكثر صعوبةً. فعدم السماح لهم بتوزيع برمجياتهم التي تعتمد على مكتبتك دون التضمين الكود المصدري قد يمنع الشركات من استعمالها في مشاريعهم، مما يمنع انتشارها انتشارًا واسعًا. شخصيًا، أستعمل رخصًا متساهلة في هذه الحالة، مثل MIT أو BSD؛ وبينما تترك تلك الرخص احتمال أن تشتق الشركات مصدر المشروع الخاص بك، وتطوره ولا تعطيك التعديلات عليه، لكن ذلك غير عملي أو منطقي لكثيرٍ من الشركات؛ لأن الاختلاف من مصدر الشيفرة الأصلي سيجعلهم يتحملون عبء تكاليف الصيانة التي تتجاوز عادةً قيمة التّعديل الذي أجروه على شيفرة مشروعك. رخصة LGPL ليست خيارًا سيئًا أيضًا، إذ تسمح للآخرين باستعمال نسخة مُصرَّفة (compiled) من المكتبة مع شيفراتهم المملوكة (proprietary أو الاحتكارية)، وفي نفس الوقت ستحافظ على حقوق مصدر المكتبة. المشاكل في التوافقية تحتوي بعض الرخص بنودًا تتعارض مع غيرها من الرخص؛ مما يجعلها غير متوافقة، مما يعني أنك لا تستطيع أن تدمج بين حزمتين برمجيتين أو مكتبتين مرخصتين برخصتين فيهما بنود متعارضة. انظر إلى الحزم البرمجية التي تستعملها في مشروعك، وحاول أن تختار رخصةً لا تتعارض مع بنود تلك الحزم. هنالك مصادرٌ عدِّة تستطيع الحصول على معلومات توافقية الرخص منها، بما في ذلك ويكيبيديا. تؤثر عادةً المشاكل في التوافقية على الرخص المعقَّدة والمحدَّدة مثل GPLv3؛ فكلما ازداد طول الرخصة وتخصيصها للبنود، كما ازدادت احتمالية حدوث مشاكل في التوافقية. تحقق من مجتمعك اعتمادًا على التقنيات التي يستعملها مشروعك، قد تجد أنَّ إحدى الرخص أفضل وأنسب من الأخرى، آخذًا بعين الاعتبار سهولة دمج مشروعك وتبنيه، وخصيصًا لو كان مكتبةً. فاستعمال أكثر رخصة شائعة في مجالك ستُسهِّل الأمر على مستعمليها، لأنهم سيكونون معتادين على شروط تلك الرخصة، وسيتم تقليل احتمالية وجود تعارض في الرخص في المشاريع. على سبيل المثال، مجتمعَا JavaScript و Ruby يُحبذون الرخص الأكثر سماحيةً مثل MIT، بينما تُنشَر المشاريع المكتوبة بلغة C/C++‎ برخصة GPL. عليك أن تبحث قليلًا في المجتمع التطويري المحيط بك عندما تنشر مكتبة برمجية وفق رخصةٍ معينة، فذاك المجتمع قد يساعدك بقرارك. لكن لا تُكرِه نفسك على رخصة معينة لأن الآخرين يستعملونها، فقد لا تكون خيارًا صائبًا لمشروعك. الخلاصة هي أنه اختيارك سيكون سديدًا إن كانت تتوافق الرخصة التي اخترها مع أغلبية المكتبات في مجتمعك. بدون رخصة إحصائيات الاستخدام التي نُشِرَت من Ben Balter على مدونة Github في مطلع عام 2015 تُظهِر أنَّ حوالي 80% من المستودعات على الموقع لا تُضمِّن رخصة؛ وهذا يعني أنَّ لا يُسمَح لأي شخص قانونيًا أن يستعمل الشيفرة الخاصة بهم حتى لو كانت متوفرة على الإنترنت لأنه لا يمكن اعتبارها "مفتوحة المصدر". هذا أمرٌ كارثي! إن لم يكن هذا ما تطمح له، فخذ وقتك للتفكير برخصة مناسبة، وإلا فلن "يلمس" أي مبرمج خبير الشيفرة الخاصة بك، ويعرض سمعته للخطر بدعوى قضائية. الخلاصة هذه هي الطريقة التي أتبعها لاختيار رخصة لمشروعي. لا يوجد خيار صائب أو خيار خاطئ في اختيارك للرخصة إن كنت تعي ما تفعل. اختر واحدةً تناسب احتياجاتك، وتأكد أن تختار رخصةً واحدةً على الأقل. ما هي الرخصة التي استعملتها لآخر مشروعٍ لك؟ أخبرنا في التعليقات. ترجمة -وبتصرّف- للمقال How to pick an open source licence for your code لصاحبه Radek Pazdera.

تَعِد PHP 7، التي صدرت في 3 ديسمبر 2015، بتحسينات كبيرة في سرعتها على النُسخ السابقة من اللغة، مع مميزات جديدة مثل تلميح النوع العددي (scalar type hinting). سنشرح كيفية ترقية خادوم Apache أو Nginx يستخدم PHP 5.x (أي إصدار) إلى PHP 7. تحذير: كما هو الحال مع معظم النسخ الرئيسية لإصدارات اللغة، من الأفضل الانتظار لبعض الوقت قبل الانتقال إلى PHP 7 في بيئة الإنتاج. في غضون ذلك، يكون الوقت مناسب لاختبار توافقية تطبيقاتك مع الإصدار الجديد، إجراء مقاييس الأداء والتّعرف على الميزات الجديدة للغة. إذا كُنت تُشغل أي خدمات أو تطبيقات بمستخدمين نُشطاء، فالآمن اختبار PHP 7 في بيئة إدراج staging environment قبل تثبيتها في بيئة الإنتاج. ملحوظة: بيئة الإدراج (staging environment) هي بيئة تطوير تقع بين بيئة الاختبار وبيئة الإنتاج، تُستخدم في تجميع، اختبار واستعراض الإصدارات الجديدة من البرمجيات قبل نقلها إلى بيئة الإنتاج. المتطلبات الأساسية يُفتَرض أنك تستخدم PHP 5.x على أوبنتو 14.04، باستخدام إما mod_php بالتزامن مع Apache، أو PHP-FPM بالتزامن مع Nginx. ويُفتَرض أن لديك مُستخدم عادي غير المستخدم الجذر بصلاحيات sudo للمهام الإدارية. إضافة PPA لحزم PHP 7.0 أرشيف الحزم الشخصي، أو PPA، هو مُستودع Apt مُستضاف على Launchpad. وهذه الأرشيفات الشخصية تسمح لمطوري الطرف الثالث ببناء وتوزيع الحزم لأوبنتو خارج قنوات تطوير الحزم الرسمية. وهي مصادر مفيدة غالبًا من البرمجيات التجريبية، البنّى المُعدلة والمنقولات الخلفية backports لإصدارات النظام القديمة. ملحوظة: الحزم المنقولة خلفًا (package backports) هي حزم لبرمجيات حديثة أعيدت ترجمتها لتوزيعة قديمة (نُقلت إلى الخلف)، وعادة ما يكون النقل إلى التوزيعة المستقرة. يقوم Ondřej Surý على صيانة حزم PHP لدبيان، ويوفر أرشيف شخصي للنسخة PHP 7.0 على أوبنتو. قبل القيام بأي شيء، سجل دخولك إلى النظام، وأضف أرشيف Ondřej الشخصي إلى قائمة مصادر Apt بالنظام: $ sudo add-apt-repository ppa:ondrej/php-7.0 ستلاحظ وصف الأرشيف الشخصي، متبوعًا بمحث للاستمرار. اضغط Enter للمواصلة. ملحوظة: إذا كانت محليات نظامك مضبوطة لأي شيء غير UTF-8، فقد تفشل عملية إضافة الأرشيف الشخصي لوجود مشكلة برمجية في التعامل مع الحروف في اسم المؤلف. وكالتفاف حول المشكلة يمكنك تثبيت الحزمة language-pack-en-base لتتأكد من توليد المحليات المطلوبة، وتتجاوز إعدادات محليات النظام عند إضافة الأرشيف الشخصي: $ sudo apt-get install -y language-pack-en-base $ sudo LC_ALL=en_US.UTF-8 add-apt-repository ppa:ondrej/php-7.0 بمجرد انتهاء تثبيت الأرشيف الشخصي، حدّث ذاكرة الحزم المُخبأة لكي يتم تضمين محتويات الأرشيف: $ sudo apt-get update الآن أصبح لدينا وصول لحزم PHP 7.0، ويمكننا استبدال نسخة PHP الحالية. ترقية mod_php مع Apache هذا القسم يوضح عملية ترقية نظام يستخدم Apache كخادوم و mod_php لتنفيذ شفرة PHP. إذا كُنت تستخدم Nginx و PHP-FPM انتقل للقسم التالي. تثبت الحزم الجديدة سوف يُرقي كل حزم PHP الهامة، باستثناء php5-mysql، التي سيتم حذفها. $ sudo apt-get install php7.0 ملحوظة: إذا قُمت بتعديلات هامة على أي ملف من ملفات الضبط في/etc/php5/، فهذه الملفات ستظل في مكانها، ويمكن الرجوع إليها. ملفات ضبط PHP 7.0 تجدها الآن في etc/php/7.0/. إذا كُنت تستخدم MySQL، تأكد من إعادة تثبيت جسر PHP MySQL المُحدّثة: $ sudo apt-get install php7.0-mysql ترقية PHP-FPM مع Nginx هذا القسم يوضح عملية ترقية نظام يستخدم Nginx كخادوم و PHP-FPM لتنفيذ شفرة PHP. تثبيت حزم PHP-FPM الجديدة واعتمادياتها: $ sudo apt-get install php7.0-fpm سيطلب منك الاستمرار، اضغط Enter لإكمال التثبيت. إذا كُنت تستخدم MySQL، تأكد من إعادة تثبيت جسر PHP MySQL المُحدّثة: $ sudo apt-get install php7.0-mysql ملحوظة: إذا قُمت بتعديلات هامة على أي ملف من ملفات الضبط في/etc/php5/، فهذه الملفات ستظل في مكانها، ويمكن الرجوع إليها. ملفات ضبط PHP 7.0 تجدها الآن في etc/php/7.0/. ترقية مواقع Nginx لتستخدم مسار المقبس الجديد يتواصل Nginx مع PHP-FPM باستخدام مقبس نطاق يونكس. ترسم المقابس خريطة لمسار على نظام الملفات، تستخدم PHP 7 مسار افتراضيًا جديدًا : PHP 5: /var/run/php5-fpm.sock PHP 7: /var/run.php7.0-fpm.sock افتح ملف ضبط الموقع الافتراضي بالمحرر nano (أو أي مُحرر من اختيارك): sudo nano /etc/nginx/sites-enabled/default قد يختلف ضبطك قليلا. ابحث عن كتلة تبدأ بـ }$location ~ \.php وسطر يبدو مثل ;fastcgi_pass unix:/var/run/php5-fpm.sock غيّر هذا ليستخدم unix:/var/run/php/php7.0-fpm.sock. مثال لملف etc/nginx/sites-enabled/default/ server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /var/www/html; index index.php index.html index.htm; server_name server_domain_name_or_IP; location / { try_files $uri $uri/ =404; } error_page 404 /404.html; error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } location ~ \.php$ { try_files $uri =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php/php7.0-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } } اخرج واحفظ الملف. يمكنك القيام بهذا في nano بالضغط على Ctrl-x للخروج، y للتأكيد و Enter للتأكيد على اسم الملف الذي سيتم الكتابة فوقه. ينبغي تكرار هذه الخطوة لأي مواقع مُعرّفة في المُجلّد etc/nginx/sites-enabled/ والتي تحتاج أن تدعم PHP. الآن يمكننا إعادة تشغيل nginx: $ sudo service nginx restart اختبار PHP بعد ضبط الخادوم وتثبيت الحزم الجديدة، يمكننا التحقق من أن PHP تعمل. ابدأ بالتحقق من نسخة PHP المُثبتة بالأمر: $ php -v المخرجات PHP 7.0.0-5+deb.sury.org~trusty+1 (cli) ( NTS ) Copyright (c) 1997-2015 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2015 Zend Technologies with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies يمكننا كذلك إنشاء ملف اختبار في مُجلد جذر وثائق الخادوم (document root). مسار هذا المُجلد يعتمد على خادومك وضبطك، قد يكون واحدًا من: var/www/html/ /var/www/ usr/share/nginx/html/ افتح ملفًا جديدًا باستخدام nano يسمى info.php في جذر الوثائق. يكون على Apache، افتراضيًا بالمسار الأول: $ sudo nano /var/www/html/info.php على Nginx، قد تستخدم: $ sudo nano /usr/share/nginx/html/info.php وألصق الشيفرة التالية بالملف: <?php phpinfo(); ?> أغلق المُحرر، واحفظ info.php. الآن، حمل العنوان التالي في متصفحك: http://server_domain_name_or_IP/info.php استبدل server_domain_name_or_IP باسم نطاق أو عنوان ip الخادوم. ينبغي أن ترى رقم نُسخة PHP ومعلومات ضبط PHP 7. بمجرد أن تُراجع هذه المعلومات، فمن الأفضل (لزيادة أمان خادومك) حذف الملف info.php: $ sudo rm /var/www/html/info.php خاتمة الآن لديك PHP 7، مُثبت ويعمل. قد ترغب في إلقاء نظرة على دليل الهجرة الرسمي إلى PHP 7. ترجمة -وبتصرّف- للمقال How To Upgrade to PHP 7 on Ubuntu 14.04 لصاحبه Brennen Bearnes.

حزم LAMP هيّ مجموعة من البرامج مفتوحة المصدر تُثَبَّت عادةً معًا لتمكين خادوم من استضافة مواقع ويب ديناميكيّة وتطبيقات ويب. تُشير الأحرف LAMP على التّوالي إلى نِظام تشغيل Linux، خادوم ويب Apache، قاعدة بيانات MySQL، ولغة PHP لمُعالجة المُحتوى الدّيناميكي. سنُثبِّت في هذا الدّليل حزم LAMP على خادوم Ubuntu 14.04، حيث يُمثِّل أوبنتو اللّبنة الأولى من الحزمة (نظام التّشغيل). المتطلبات يجب، من أجل مُتابعة خطوات هذا الدّرس، أن يكون لديك حساب عادي (غير الحساب الجذر Root user) بصلاحيّات sudo. يُمكنّك معرفة كيف تضبُط حسابًا بهذه المواصفات في الخطوات من 1 إلى 4 من درس الإعداد الابتدائي لخادوم أوبنتو 14.04. الخطوة الأولى: ثبت Apache خادوم ويب Apache هوّ في الوقت الحالي خادوم الويب الأكثر شعبيّة، الأمر الّذي يجعل منه خيّارًا افتراضيًّا جيّدًا لاستضافة مواقع الويب. يُمكن تثبيت خادوم ويب Apache بسهولة عن طريق مدير حزم Package manager أوبنتو، apt. نبدأ بتحديث فهرس الحزم ثمّ نُثبّت حزمة apache2 لنحصُل على خادوم ويب Apache: sudo apt-get update sudo apt-get install apache2 سيُطلب منك إدخال كلمة السّر من حين لآخر، نظرًا لاستخدام صلاحيّات الجذر (Root) عن طريق sudo. ننتقل إلى مُتصفِّح الويب بعد انتهاء تنفيذ الأمر السّابق للتّأكد من تثبيت Apache. نُدخِل عنوان IP الخادوم العمومي أو اسم نطاق الموقع Domain name في شريط عنوان المُتصفّح: http://your_server_IP_address ملحوظة: إذا كنتَ تُجرِّب هذه الخطوات على جهازك الشّخصي (أو جهاز محلّي) فعنوان خادوم الويب هو 127.0.0.1 (أو localhost). ستظهر الصّفحة الافتراضيّة لخادوم ويب Apache، حيثُ توجد بعض معلومات الإعداد. شكل الصّفحة يبدو كالتّالي: إن عُرضت الصّفحة أعلاه فتثبيتُ خادوم ويب Apache جرى كما يُرام. كيف تجد عنوان IP العمومي لخادومك ملحوظة: هذه الفقرة غير مُوَّجَّهة لمن يختبر التّثبيت على حاسوبه الشّخصي. توجد عدّة طُرُق لمعرفة عنوان IP العمومي لخادوم على شبكة الإنترنت. عنوان IP العمومي للخادوم هو في العادة نفس العنوان الّي تتّصل به عن طريق SSH. نفِّذ الأمر التّالي في سطر الأوامر: ip addr show eth0 | grep inet | awk '{ print $2; }' | sed 's/\/.*$//' ينتُج عن هذا الأمر سطر أو اثنان (واحد عنوان كما يُكتَب في الإصدار الرّابع IPv4 من بروتوكول IP، والآخر كما يُكتَب في الإصدار السّادس IPv6). في حال كانت النّتيجة سطرين فكلاهما صحيح ولكن من الممكن ألّا يستطيعَ حاسوبك الشّخصي التّعامل إلا مع واحد منهما؛ جرّب العنوانيْن حتى تحصُل على العنوان المُناسب. توجد طريقة بديلة وهي استخدام خدمة عامّة للحصول على عنوان IP. للحصول على العنوان نتّصل بالخدمة ونطلُب منها إخبارنَا عن العنوان الّذي نتّصِل منه: curl http://icanhazip.com ملحوظة: إن استخدمتَ الأمر السّابق من جهازك الشّخصي فستحصُل على عنوان IP الّذي تظهر به للخارج؛ هذا لا يعني بالضّرورة أنّ هذا هو عنوان IP العمومي لجهازك. مهما اختلفت الطّريقة فالمهم هو الحصول على عنوان خادومك ثمّ إدخاله في شريط العناوين في المتصفّح للتّأكّد من تثبيت خادوم ويب Apache. الخطوة الثانية: ثبت MySQL يأتي الآن دورُ MySQL، بعد تثبيت MySQL. Apache هو نظام لإدارة قواعد البيانات DataBase Management System, DBMS؛ وهو برنامج مسؤول عن إدارة وتوفير الاتّصال بقاعدة البيانات الّتي تُخزَّن بها معلومات الموقع. سنستخدم - كما في الخطوة السّابقة - مُديرَ حزم Apt، ولكن هذه المرّة سنُضيف بعض الحزم المُساعدة من أجل تمكين الاتّصال بين مختلف عناصِر البيئة الّتي نحن في طور إعدادها. sudo apt-get install mysql-server php5-mysql ملحوظة: لم ننُفِّذ أمر sudo apt-get update قبل أمر التّثبيت هذه المرّة. يعود السّبب في ذلك إلى أنّنا نفّذنا هذا الإجراء للتّو وهو ما يعني أنّ فهرس الحزم لدينا مُحدَّث up-to-date. أثناء تثبيت MySQL سيطلُب منك الخادوم اختيّار كلمة سرّ للمُستخدِم root على MySQL. الحساب root هو حساب إداريّ يملك صلاحيّات واسعة على نظام قواعد البيانات؛ وهو يُشبه إلى حدٍّ مّا الحساب الجذر في خادوم أوبنتو نفسه (لكن انتبِه إلى أنّه حساب خاص بنظام MySQL لإدارة قواعد البيانات). نحتاج بعد انتهاء التّثبيت إلى تنفيذ أوامر إضافيّة من أجل تأمين MySQL. نطلُب أوّلا من MySQL إنشاءَ بُنية المجلّدات الخاصّة بقاعدة البيانات حيثُ سيُخزّن المعلومات. الأمر التّالي يُؤدّي هذه المهمّة: sudo mysql_install_db ثمّ نُنفّذ سكربت التّثبيت الآمن الّذي يحذِف بعض القيّم الافتراضيّة غير الآمنة ويمنع الوصول المُباشر لنظام إدارة قواعد البيانات: sudo mysql_secure_installation سيُطلب منك النّظام إدخال كلمة سرّ الحساب الجذر في MySQL؛ ثمّ يسألك ما إذا كنتَ تُريد تغييرها. أدخل حرف n (دلالةً على "no" أي "لا") إن لم تكن ترغبُ في ذلك. بقيّة الأسئلة تتعلّق بإزالة بعض الحسابات وقواعد البيانات المُعَدَّة للتّجربة، تعطيل الدّخول عن بُعد للحساب الجذر، ثم تحميل الإعدادات الجديدة ليبدأ MySQL العمل بها مُباشرةً؛ فقط اضغط Enter للإجابة على هذه الأسئلة. تحصُل بعدانتهاء هذه الخطوة على نظام قواعد بيانات مضبوط وجاهز للعمل. الخطوة الثالثة: ثبت PHP يتولّى PHP التّعاملَ مع البيانات لإظهار المُحتوى الدّيناميكي؛ حيث يُنفِّذ السكربتات، يتّصِل بقاعدة بيانات MySQL ويُمرّر المُحتوى - بعد معالجته - إلى خادوم الويب، الّذي يعرضه. نستعين بمُدير الحزم apt مُجدّدًا لتثبيت PHP وبعض البرامج المُساعِدة الأخرى: sudo apt-get install php5 libapache2-mod-php5 php5-mcrypt ينبغي أن يكون الأمر السّابق كفيلًا بتثبيت PHP دون أيّة مشاكل. سنختبر نجاح التّثبيت بعد قليل. يقضي الإعداد الافتراضي لخادوم ويب Apache بالبحث أوّلا عن ملفّ باسم index.html عند وصول طلب لعرض مُجلّد. سنُغيّر هذا الإعداد بحيثُ يبحث خادوم الويب أوّلًا عن ملفّ PHP باسم index.php. نفتح ملفّ dir.conf في المُحرّر بصلاحيّات المُستخدِم الجذر: sudo nano /etc/apache2/mods-enabled/dir.conf يُشبه مُحتوى الملفّ الشّكلَ التّالي: <IfModule mod_dir.c> DirectoryIndex index.html index.cgi index.pl index.php index.xhtml index.htm </IfModule> ما نُريده هو تقديم ملف index.php المُعلَّم بالأحمر أعلاه إلى الوضعيّة الأولى، مباشرةً بعد تعليمة DirectoryIndex هكذا: <IfModule mod_dir.c> DirectoryIndex index.php index.html index.cgi index.pl index.xhtml index.htm </IfModule> احفَظ الملفّ بعد الانتهاء من تحريره عن طريق الضغط على الزّرّيْن CTRL+O ثم زرّ Enter في لوحة المفاتيح وأغلِقه بالضّغط على الزّرّيْن CTRL+X. نعيد تشغيل Apache للعمَل بالإعدادات الجديدة: sudo service apache2 restart ثبت وحدات PHP Modules ،PHP توجد بعض الوِحدات Modules الاختيّاريّة الّتي نستطيع تثبيتَها من أجل تحسين وظائف PHP. ننفِّذ الأمر التّالي لعرض مكتبات Libraries ووِحدات PHP المُتاحة: apt-cache search php5- جميع ما يظهَر في النّتائج هيّ وحدات اختيّاريّة يُمكن تثبيتها إن أردت. تتضمّن كل نتيجة اسم الوحدة ووصفًا مُختَصرًا لها: php5-cgi - server-side, HTML-embedded scripting language (CGI binary) php5-cli - command-line interpreter for the php5 scripting language php5-common - Common files for packages built from the php5 source php5-curl - CURL module for php5 php5-dbg - Debug symbols for PHP5 php5-dev - Files for PHP5 module development php5-gd - GD module for php5 . . . إن أردت معلوماتٍ أكثرَ عن إحدى الوِحدَات يمكنك البحث على الشّبكة أو استخدام أمر الوصف المُطَوَّل للحزمة عبر تنفيذ الأمر (حيثُ package_name اسم الحزمة): apt-cache show package_name بالنّسبة لوحدة php5-cli على سبيل المثال: apt-cache show php5-cli ستجد أن هناك مخرجاتٍ عديدةً من بينها حقلٌ باسم Description-en يُقدّم شرحًا لوظيفة الوِحدة (بالإنجليزيّة غالبًا، إلّا إذا كان التّوثيق Documentation يتوفّر بلغة النّظام لديك). . . . SHA256: 91cfdbda65df65c9a4a5bd3478d6e7d3e92c53efcddf3436bbe9bbe27eca409d Description-en: command-line interpreter for the php5 scripting language This package provides the /usr/bin/php5 command interpreter, useful for testing PHP scripts from a shell or performing general shell scripting tasks. . The following extensions are built in: bcmath bz2 calendar Core ctype date dba dom ereg exif fileinfo filter ftp gettext hash iconv libxml mbstring mhash openssl pcntl pcre Phar posix Reflection session shmop SimpleXML soap sockets SPL standard sysvmsg sysvsem sysvshm tokenizer wddx xml xmlreader xmlwriter zip zlib. . PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. Description-md5: f8450d3b28653dcf1a4615f3b1d4e347 Homepage: http://www.php.net/ . . . إذا أردتَ تثبيت وِحدة من وِحدات PHP، بعد الحصول على المعلومات الكافيّة عن وظيفتها، فيُمكنك استخدامُ أمر apt-get install. بالعودة إلى مثال php5-cli فإنّ التّثبيت يكون كما يلي: sudo apt-get install php5-cli ُيرجى ملاحظة أنّه بالإمكان تثبيت أكثر من حزمة في نفس الوقت عبر الفصل بينها بمسافة، هكذا: sudo apt-get install package1 package2 ينبغي أن تكون حزم LAMP، بالوصول إلى هذه النّقطة من الدّليل، مُثّبَّتةً ومضبوطةً. ننتقل إلى اختبار PHP. الخطوة الرابعة: اختبر تعامل خادوم الويب مع ملفات PHP سننشئ سكربت PHP مُيَسّرًا من أجل اختبار إعدادات PHP وخادوم الويب. الهدف هوّ أن يعثُر خادوم الويب على السكربت، الّذي سنُسمّيه info.php، ثمّ يعرض محتواه بشكل صحيح. يجب أن يُحفَظ الملفّ في مجلّد خاصّ، يُسمّى جذر الويب Web root (في هذا المُجلَّد مباشرةً أو في أحد المجلّدات المتفرّعة عنه)، لكي يعثُر عليه خادوم ويب Apache . يوجد جذر الويب في أوبنتو 14.04 على المسار /var/www/html/. نُنشئ ملفَّ اختبار الإعداد داخل هذا المسار عبر الأمر: sudo nano /var/www/html/info.php سيُفتح المحرّر وبداخله ملفّ فارغ، نُضيف إليه الشيفرة البرمجيّة التّاليّة: <?php phpinfo(); ?> هذا كل ما في الأمر. احفظ الملفّ ثم أغلقه. لاختبار إعداد خادوم الويب نفتح متصفّحَ ويب ثمّ نُدخل عنوان الصّفحة في شريط العنوان. يتكوّن عنوان الصّفحة من عنوان IP العمومي لخادوم الويب (أو اسم النّطاق) متبوعًا بمسار تواجد الصّفحة بالنّسبة لجذر الويب. صفحة الاختبار الّتي أعددناها موجودة في جذر الويب وهو ما يعني أنّ عنوان الوصول إليها هوّ التّالي (حيث your_server_IP_address هو عنوان IP أو اسم نطاق الموقع): http://your_server_IP_address/info.php يجب أن تظهر في المتصفّح صفحة الويب التّاليّة: تُقدّم هذه الصّفحة معلوماتٍ عن الخادوم كما يراه PHP. بعض هذه المعلومات مهمّ لمعرفة إعدادات خادوم الويب ومُعالج PHP، كما أنّها تُساعِدك أثناء تنقيح Debugging السكربتات. إذا ظهرت الصّفحة فهذا يعني أنّ PHP يعمل كما نُريد. يُنصَح بحذف هذه الصّفحة بعد الانتهاء من الاختبار، حيث إنّها قد تُعطي معلوماتٍ عن خادومك لأشخاص لا يجدر بهم الحصول على هذه المعلومات، الأمر التّالي يؤدّي هذه المهمّة: sudo rm /var/www/html/info.php يُمكن دائمًا إنشاء صفحة الاختبار من أجل الوصول إلى المعلومات الّتي توفّرها، متى أردت ذلك. خاتمة باستكمال خطوات هذا الدّليل تكون قد وضعتَ الأساس لتثبيت، استعمال وإعداد العديد من أنواع مواقع وتطبيقات الويب. ترجمة -وبتصرف- للمقال How To Install Linux, Apache, MySQL, PHP (LAMP) stack on Ubuntu 14.04 لصاحبه Justin Ellingwood.

إن أباتشي تومكات (Apache Tomcat) هو «حاوية ويب» (web container) يسمح لك بتخديم Java Servlets و JSP ‏(Java Server Pages). في أوبنتو دعمٌ لإصدارَيّ تومكات 6 و 7، حيث تومكات 6 هي النسخة القديمة؛ و تومكات 7 هي النسخة الحالية التي تضاف إليها الميزات الجديدة. يُعتَبَر أن كلا الإصدارين مستقر، لكننا سنركز على نسخة تومكات 7، لكن أغلبية تفاصيل الضبط المشروحة هنا صالحة لكلي النسختين. تَدعم حزم تومكات في أوبنتو طريقتين مختلفتين لتشغيل تومكات؛ يمكنك تثبيته بالطريقة الكلاسيكية لعموم النظام، مما يجعل تومكات يبدأ في وقت الإقلاع وسيعمل كمستخدم tomcat7 (أو tomcat6) بدون امتيازات؛ لكنك تستطيع إنشاء نسخ خاصة منه وتشغيلها بامتيازات المستخدم، الذي يمكنك بدؤه أو إيقافه بنفسك؛ الطريقة الثانية هي مفيدة خصوصًا في الخادوم التطويري حيث يحتاج عدّة مستخدمين إلى اختبار البرمجيات في نسخ تومكات الخاصة بهم. التثبيت لعموم النظامعليك إدخال الأمر الآتي في الطرفية لتثبيت خادوم تومكات: sudo apt-get install tomcat7الأمر السابق سيُثبِّت خادوم تومكات مع تطبيق الويب الافتراضي ROOT؛ الذي يُظهِر صفحةً بسيطةً تحتوي على "It works". الضبطملفات ضبط تومكات موجودة في ‎/etc/tomcat7، بعض تعديلات الضبط الشائعة ستُشرَح هنا فقط؛ رجاءً راجع توثيق Tomcat 7.01 للمزيد. تغيير المنافذ الافتراضيةيعمل تومكات 7.0 افتراضيًا بواصل HTTP‏ (HTTP connector) على المنفذ 8080 وواصل AJP على المنفذ 8009؛ ربما تريد تغيير هذين المنفذين الافتراضيين لتفادي التضاربات مع خواديم أخرى على النظام، يمكن فعل ذلك بتعديل الأسطر الآتية في ‎/etc/tomcat7/server.xml: <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> ... <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />تبديل JVM المستخدمةيعمل تومكات افتراضيًا عملًا ممتازًا مع OpenJDK، ثم سيُجرِّب JVM الخاصة بشركة Sun؛ ثم سيجرب JVMs الأخرى؛ إذا كان لديك عدّة JVMs مثبتةً، فيمكنك ضبط أيٌّ منها سيستخدم عبر JAVA_HOME في ‎/etc/default ‎/tomcat7: JAVA_HOME=/usr/lib/jvm/java-6-sunتعريف المستخدمين وأدوارهميمكن أن تُعرَّف أسماء المستخدمين وكلمات مرورهم وأدوارهم (المجموعات) في حاوية Servlet؛ يتم ذلك في ملف ‎/etc/tomcat7/tomcat-users.xml: <role rolename="admin"/> <user username="tomcat" password="s3cret" roles="admin"/>استخدام تطبيقات الويب القياسية التابعة لتومكاتيأتي تومكات مع تطبيقات ويب تستطيع تثبيتها لأغراض التوثيق أو الإدارة أو لأغراض تجريبية. توثيق تومكاتتحتوي الحزمة tomcat7-docs على توثيق تومكات محزمًّا كتطبيق ويب تستطيع الدخول إليه افتراضيًا عبر http://server:8080/docs، وتستطيع تثبيت تلك الحزمة بالأمر الآتي: sudo apt-get install tomcat7-docsتطبيقات الويب لإدارة تومكاتتحتوي الحزمة tomcat7-admin على تطبيقَيّ ويب تستطيع استخدامهما لإدارة خادوم تومكات عبر واجهة ويب، يمكنك تثبيتهما عبر إدخال الأمر الآتي في الطرفية: sudo apt-get install tomcat7-adminأولهما هو تطبيق الويب «manager»؛ الذي يمكن الوصول إليه افتراضيًا عبر http://server:8080/manager/html؛ ويُستخدَم للحصول على حالة الخادوم وإعادة تشغيل تطبيقات الويب. ملاحظة: الوصول إلى تطبيق manager محميٌ افتراضيًا: عليك أن تُعرِّف مستخدمًا بدور «manager-gui» في ‎/etc/tomcat7/tomcat-users.xml قبل الوصول إليه. التطبيق الآخر هو «host-manager» الذي يمكن الوصول إليه افتراضيًّا عبر http://server:8080/host-manager/html، ويمكن أن يُستخدَم لإنشاء مضيفين وهميين ديناميكيًّا. ملاحظة: الوصول إلى تطبيق host-manager محميٌ افتراضيًا أيضًا: عليك أن تُعرِّف مستخدمًا بدور «admin-gui» في ‎/etc/tomcat7/tomcat-users.xml قبل الوصول إليه. لأسباب تتعلق بالحماية، لا يمكن للمستخدم tomcat7 أن يكتب إلى مجلد ‎/etc/tomcat7 افتراضيًا؛ بعض الميزات في تطبيقات الويب هذه (نشر التطبيقات، أو إنشاء مضيف وهمي) تحتاج إلى إذن الكتابة إلى ذاك المجلد؛ إذا أردت استخدام هذه الميزات، فعليك تنفيذ الأوامر الآتية لإعطاء المستخدمين في مجموعة tomcat7 الامتيازات اللازمة: sudo chgrp -R tomcat7 /etc/tomcat7 sudo chmod -R g+w /etc/tomcat7تطبيقات ويب تومكات للتجربةتحتوي حزمة tomcat7-example على تطبيقَيّ ويب يُستخدمان لاختبار أو شرح ميزات Servlets و JSP؛ تستطيع الوصول إليهما افتراضيًا عبر http://server:8080/examples؛ يمكنك تثبيتهما بالأمر: sudo apt-get install tomcat7-examplesاستخدام نسخ خاصةيُستخدم تومكات استخدامًا واسعًا في التطوير وحالات الاختبار حيث لا يكون استخدام نسخة واحدة لعموم النظام كافيًا لعدة مستخدمين على نظام واحد؛ تأتي حزم تومكات في أوبنتو مع الأدوات اللازمة لإنشاء نسخ موجهة للمستخدمين، مما يسمح لكل مستخدم في النظام بتشغيل (دون امتيازات الجذر) نسخة خاصة منفصلة بينما ما تزال تستخدم تلك النسخة المكتبات المثبتة على النظام. ملاحظة: من الممكن تشغيل نسخة لعموم النظام، ونسخ خاصة على التوازي (أي معًا)؛ شريطة ألّا يستخدموا نفس منافذ TCP. تثبيت دعم النسخ الخاصةيمكنك تثبيت كل ما يلزم لدعم النسخ الخاصة بتنفيذ الأمر الآتي في الطرفية: sudo apt-get install tomcat7-userإنشاء نسخة خاصةيمكنك إنشاء مجلد لنسخة خاصة بإدخال الأمر الآتي في الطرفية: tomcat7-instance-create my-instanceسيُنشِئ الأمر السابق مجلد my-instance جديد مع كل المجلدات الفرعية والسكربتات اللازمة؛ يمكنك على سبيل المثال تثبيت المكتبات الشائعة في المجلد الفرعي lib/‎ ووضع تطبيق الويب في مجلد webapps/‎؛ لا توجد أيّة تطبيقات ويب افتراضيًا. ضبط نسختك الخاصةستجد ملفات ضبط تومكات التقليدية في النسخة الخاصة في المجلد الفرعي conf/‎؛ يجب عليك، على سبيل المثال، تعديل ملف conf/server.xml لتغيير المنفذ الافتراضي المُستخدَم من نسخة تومكات الخاصة لتفادي التضارب مع النسخ الأخرى التي قد تكون تعمل على النظام. بدء أو إيقاف النسخة الخاصةيمكنك بدء نسختك الخاصة بإدخال الأمر الآتي في الطرفية (بفرض أن نسختك موجودةٌ في مجلد my-instance): my-instance/bin/startup.shملاحظة: عليك التحقق من المجلد الفرعي logs/ لأي خطأ؛ إذا حصلت على خطأ: java.net.BindException: Address already in use<null>:8080 فاعلم أن المنفذ مُستخدَم من قبل وعليك تغييره. يمكنك إيقاف نسختك الخاصة بتنفيذ الأمر الآتي في سطر الأوامر: my-instance/bin/shutdown.shمصادرراجع موقع Apache Tomcat لمزيدٍ من المعلومات.كتاب «Tomcat: The Definitive Guide» هو مصدر جيد لبناء تطبيقات الويب مع تومكات.راجع قائمة «Tomcat Books» لمزيدٍ من الكتب.ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Apache Tomcat.

أباتشي هو خادوم يعتمد على الوحدات، هذا يعني أن الوظيفة الأساسية فقط هي مضمَّنة في أساس الخادوم؛ الميزات الإضافية متوفرة عبر وحدات يمكن تحميلها إلى أباتشي؛ تُضمَّن افتراضيًّا مجموعة أساسية من الوحدات في الخادوم أثناء البناء، إذا بُنِي الخادوم ليستخدم الوحدات المُحمَّلة ديناميكيًا، فيمكن بناء تلك الوحدات بناءً منفصلًا ويمكن أن تضاف في أي وقت باستخدام التعليمة LoadModule؛ عدا ذلك، فيجب إعادة بناء أباتشي في كل مرة تُضاف أو تُحذف فيها الوحدات. يبني أوبنتو أباتشي ليسمح بالتحميل الديناميكي للوحدات؛ يمكن أن تُضاف تعليمات الضبط شرطيًّا في حال تطلب وجود وحدة معينة بوضعها في قسم <IfModule>. تستطيع تثبيت وحدات أباتشي إضافية واستخدامها في خادوم الويب؛ على سبيل المثال، نفِّذ الأمر الآتي من الطرفية لتثبيت وحدة الاستيثاق الخاصة بقواعد بيانات MySQL: sudo apt-get install libapache2-mod-auth-mysqlانظر إلى مجلد ‎/etc/apache2/mods-available للمزيد من الوحدات. استخدم الأداة a2enmod لتفعيل وحدة: sudo a2enmod auth_mysql sudo service apache2 restartوبشكلٍ مشابه، الأداة a2dismod ستعطل وحدة: sudo a2dismod auth_mysql sudo service apache2 restartضبط HTTPSتُضيف الوحدة mod_ssl ميزةً مهمةً لخادوم أباتشي، ألا وهي القدرة على تشفير الاتصالات؛ وهذا يعني أنه عندما يتواصل متصفح الويب باستخدام SSL، فستُستخدَم السابقة https‎://‎ في بداية URL في شريط العنوان في المتصفح. تتوفر الوحدة mod_ssl في الحزمة apache2-common؛ نفِّذ الأمر الآتي من الطرفية لتفعيل وحدة mod_ssl: sudo a2enmod sslهنالك ملف ضبط HTTPS افتراضي في ‎/etc/apache2/sites-available/default-ssl.conf؛ ولكي يستطيع أباتشي توفير HTTPS، فيجب توفير شهادة ومفتاح أيضًا؛ ضبط HTTPS الافتراضي سيستخدم شهادة ومفتاح مولد من الحزمة ssl-cert؛ هذه الشهادات مناسبة للاختبار، لكن يجب استبدال الشهادة والمفتاح المولد تلقائيًا بشهادة خاصة بالموقع أو الخادوم، للمزيد من المعلومات حول توليد مفتاح والحصول على شهادة، راجع درس الشهادات. أدخِل الأمر الآتي لضبط أباتشي ليتعامل مع HTTPS: sudo a2ensite default-sslملاحظة: المجلدان ‎/etc/ssl/certs و ‎/etc/ssl/private هما المساران الافتراضيان للشهادة والمفتاح؛ إذا ثبتت الشهادة والمفتاح في مجلد آخر، فتأكد من تغيير قيمة SSLCertificateFile و SSLCertificateKeyFile بما يلائمك. بعد أن ضبطنا أباتشي ليستخدم HTTPS، فعلينا إعادة تشغيل الخدمة لتفعيل الإعدادات الجديدة: sudo service apache2 restartملاحظة: اعتمادًا على من أين حصلت على الشهادة، ربما تحتاج إلى إدخال عبارة مرور عند تشغيل أباتشي. تستطيع الوصول إلى صفحات الخادوم الآمنة بكتابة https://hostname/url/‎ في شريط العنوان في المتصفح. لغة السكربتات PHP5إن PHP هي لغة برمجة عامة ملائمة لتطوير الويب؛ يمكن تضمين سكربت PHP في HTML؛ وهذا القسم سيشرح كيفية تثبيت وضبط PHP5 على خادوم أوبنتو مع أباتشي و MySQL. يفترض هذا القسم أنك ثبتت وضبطت خادوم الويب أباتشي وقواعد بيانات MySQL؛ تستطيع الرجوع إلى الأقسام التي تشرح ضط أباتشي و MySQL في هذه السلسلة لمزيدٍ من المعلومات. التثبيتلغة PHP5 متوفرة في أوبنتو، وعلى عكس بايثون وبيرل المثبتتين في النظام افتراضيًّا، يجب تثبيت PHP يدويًّا. أدخِل الأمر الآتي في الطرفية لتثبيت PHP5: sudo apt-get install php5 libapache2-mod-php5تستطيع تشغيل سكربتات PHP5 من سطر الأوامر؛ يجب عليك تثبيت الحزمة php5-cli لتنفيذ سكربتات PHP5 من سطر الأوامر؛ وذلك بإدخال الأمر الآتي في الطرفية: sudo apt-get install php5-cliتستطيع أيضًا تشغيل سكربتات PHP5 دون تثبيت وحدة PHP5 التابعة لأباتشي؛ للقيام بذلك، عليك تثبيت الحزمة php5-cgi؛ وذلك بإدخال الأمر الآتي في الطرفية: sudo apt-get install php5-cgiلاستخدام MySQL مع PHP5، فعليك تثبيت الحزمة php5-mysql، وبذلك بتنفيذ الأمر الآتي: sudo apt-get install php5-mysqlوبشكل مشابه، لاستخدام PostgreSQL مع PHP5، فعليك تثبيت الحزمة php5-pgsql: sudo apt-get install php5-pgsqlالضبطبعد أن تُثبِّت PHP5، تستطيع تشغيل سكربتات PHP5 من متصفح الويب، وإذا ثبتت الحزمة php5-cli فتستطيع تشغيل سكربتات php5 من سطر الأوامر. خادوم أباتشي مضبوطٌ افتراضيًا لتشغيل سكربتات PHP5؛ بكلمات أخرى، وحدة PHP5 مفعَّلة افتراضيًا في خادوم أباتشي بعد تثبيت الوحدة مباشرةً؛ رجاءً تأكد إذا كانت الملفات etc/apache2/mods/‎enabled/php5.conf/ و ‎/etc/apache2/mods-enabled/php5.load موجودةً، إن لم تكن موجودةً، فتستطيع تفعيل الوحدة باستخدام الأمر a2enmod. بعد أن تثبت الحزمة المتعلقة بلغة PHP5 وتُفعِّل وحدة أباتشي، فعليك أن تعيد تشغيل خادوم أباتشي لتستطيع تنفيذ سكربتات PHP5؛ وذلك بالأمر الآتي: sudo service apache2 restartالاختبارللتأكد من التثبيت الصحيح للغة PHP؛ فنفِّذ سكربت phpinfo الآتي: <?php phpinfo(); ?>عليك حفظ محتويات الملف السابق باسم phpinfo.php ووضعه تحت مجلد DocumentRoot في خادوم ويب أباتشي؛ وعندما توجه متصفحك نحو http://hostname/phpinfo.php فسوف يعرض لك إعدادات ضبط PHP5 المختلفة. مصادرلتفاصيل أكثر، راجع توثيق موقع php.net.هنالك مجموعة كبيرة من الكتب عن PHP، كتابان جيدان من O'Reilly هما «Learning PHP5»، و «PHP CookBook».Ruby on Railsإن Ruby on Rails هو إطار عمل مفتوح المصدر للويب لتطوير تطبيقات ويب يعتمد على قواعد البيانات؛ حيث يُفضِّل هذا الإطار المبدأ «convention over configuration». التثبيتقبل تثبيت Ruby on Rails، يجب أن يكون لديك خادومي أباتشي و MySQL؛ رجاءً عُد للأقسام التي تشرح تثبيت أباتشي و MySQL في هذه السلسلة للمزيد من المعلومات. بعد أن تُثبَّت حزم أباتشي و MySQL؛ فيجب أن تكون جاهزًا لتثبيت حزمة Ruby on Rails؛ وذلك بإدخال الأمر الآتي في الطرفية: sudo apt-get install railsالضبطعدِّل ملف الضبط ‎/etc/apache2/sites-available/000-default.conf لإعداد النطاقات. أول شيء يجب تغييره هو التعليمة DocumentRoot: DocumentRoot /path/to/rails/application/publicثم عدِّل التعليمة ‎<Directory "/path/to/rails/application/public">‎: <Directory "/path/to/rails/application/public"> Options Indexes FollowSymLinks MultiViews ExecCGI AllowOverride All Order allow,deny allow from all AddHandler cgi-script .cgi </Directory>يجب أن تُفعِّل الوحدة mod_rewrite لأباتشي، وذلك بإدخال الأمر الآتي في الطرفية: sudo a2enmod rewriteفي النهاية، يجب أن تُعدِّل ملكية ‎/path/to/rails/application/public و ‎‎/path/to/‎ rails/application/tmp للمستخدم الذي يُشغِّل عملية أباتشي: sudo chown -R www-data:www-data /path/to/rails/application/public sudo chown -R www-data:www-data /path/to/rails/application/tmpهذا كل ما في الأمر! يجب أن يكون خادومك جاهزًا الآن لتخديم تطبيقات Ruby on Rails. مصادرراجع موقع Ruby on Rails لمزيدٍ من المعلومات.Agile Development with Rails هو مصدر رائع قد تستفيد منه.صفحة ويكي أوبنتو «Ruby on Rails».ترجمة -وبتصرف- للمقالين: Ubuntu Server Guide: PHP5 - Scripting Language و Ubuntu Server Guide: Ruby on Rails.

خادوم الويب هو برمجية مسؤولة عن قبول طلبات 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.

سنتعلّم في هذا الدّرس كيفيّة الحصول على شهادة SSL من سلطة شهادات تجاريّة (Commercial Certificate Authority (CA وكيفيّة تثبيتها، تسمح شهادات SSL لخواديم الويب بتشفير حركة مرور بياناتها traffic وتُوفِّر آليّة للتحقّق من هويّات الخواديم من أجل الزوّار، إنّ الميزة الأساسيّة لشراء شهادة SSL من سلطة شهادات تجاريّة (CA) موثوقة عن الشهادات المُوقَّعة ذاتيًّا self-signed أنّه لن يتم عرض تحذير مُخيف للزوّار حول عدم القدرة على التحقّق من هويّة موقعنا. يغطّي هذا الدرس كيفيّة الحصول على شهادة SSL من سلطات الشهادات الموثوقة التالية: GoDaddyRapidSSL via Namecheapبإمكانك أيضًا استخدام أي سلطة شهادات CA من اختيارك. سنشرح بعد أن حصلنا على شهادة SSL كيفيّة تثبيتها على خواديم ويب Nginx و Apache HTTP. سنشاهد في هذا الدّرس كيفيّة الحصول على شهادة SSL مُفردة النطاق أو wildcard من GoDaddy وRapidSSL، ولكنّ الحصول على الأنواع الأخرى من الشهادات مماثل تمامًا. توليد CSR ومفتاح خاص Private Keyبعد أن تقوم بتجهيز المتطلبات الأساسيّة وتختار نوع الشهادة التي نريد الحصول عليها، تحتاج لتوليد طلب توقيع الشهادة (certificate signing request (CSR ومفتاح خاص private key. إن كنت تخطّط لاستخدام Apache HTTP أو Nginx كخادوم ويب لديك فاستخدم openssl لتوليد CSR ومفتاحك الخاص على خادومك الويب، سنبقي في هذا الدّرس كافّة الملفات المرتبطة بهذا في الدليل الرئيسي home directory ولكن لا تتردد في تخزينها في أي موقع آمن على خادومك: cd ~نقوم بتنفيذ هذا الأمر لتوليد مفتاح خاص يُدعى example.com.key و CSR يُدعى example.com.csr (ضع اسم نطاقك بدلًا من example.com): openssl req -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csrعند هذه النقطة سيتم حثنا على إدخال عدّة أسطر من المعلومات تُضمَّن في طلب شهادتنا، إنّ الجزء الأهم منها هو حقل الاسم الشائع Common Name والذي يجب أن يُطابق الاسم الذي نرغب باستخدام الشهادة معه، على سبيل المثال example.com ،www.example.com، أو (بالنسبة لطلب شهادة wildcard) *.example.com، إن كنت تُخطّط للحصول على شهادة OV أو EV فتأكّد من أن تتوافق كافّة الحقول الأخرى بدقة مع بيانات منظمتك أو عملك. على سبيل المثال: Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:New York Locality Name (eg, city) []:New York Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []: Common Name (e.g. server FQDN or YOUR name) []:example.com Email Address []:sammy@example.comسيقوم هذا بتوليد ملفات key. و csr.، حيث يكون الملف key. هو مفتاحنا الخاص ويجب أن نبقيه في مكان آمن، والملف csr. هو الذي يجب أن نرسله إلى سلطة الشهادات لطلب شهادة SSL. نحتاج إلى نسخ ولصق CSR الخاصّة بنا عند تقديم طلب الشهادة إلى سلطة الشهادات، نستخدم هذا الأمر لطباعة محتويات ملف CSR لدينا (ضع اسم ملفّك بدلًا من التالي): cat example.com.csrنحن الآن مستعدون لشراء شهادة من سلطة الشهادات، سنعرض هنا مثالين، GoDaddy و RapidSSL عبر Namecheap، ولكن لك الحرية بالحصول على الشهادة من أي بائع آخر. مثال سلطة الشهادات الأول: RapidSSL via Namecheapتوفّر Namecheap طريقة لشراء شهادات SSL من مجموعة متنوعة من سلطات الشهادات، سنشرح عمليّة الحصول على شهادة نطاق مُفرَد من RapidSSL، ولكن إن أردت نوعًا مختلفًا من الشهادات فبإمكانك فعل ذلك. ملاحظة: إن طلبنا شهادة نطاق مُفرَد من RapidSSL من أجل النطاق الفرعي www لنطاقنا (على سبيل المثال www.example.com) فسيقومون بإصدار الشهادة لنا مع SAN لنطاقنا الأساسي، فإن كان طلب شهادتنا على سبيل المثال من أجل www.example.com فستعمل الشهادة الصادرة من أجل www.example.com و example.com. اختيار وشراء الشهادةنذهب إلى صفحة Namecheap لشهادات SSL . نستطيع هنا البدء في اختيار مستوى التحقّق، نوع الشهادة ("Domains Secured") أو ("CA Brand"). سنضغط في مثالنا على زر مقارنة المنتجات Compare Products في مربّع التحقّق من النطاق "Domain Validation"، بعدها نستطيع إيجاد "RapidSSL" والضغط على زر إضافة إلى السلّة Add to Cart. عند هذه النقطة يجب علينا التسجيل في Namecheap أو تسجيل الدخول إليه، وإنهاء عمليّة الدفع. طلب الشهادةنذهب بعد أن دفعنا من أجل الشهادة التي اخترناها إلى الرابط Manage SSL Certificates الموجود تحت القسم "Hi Username". سنشاهد هنا قائمة بكامل شهادات SSL التي اشتريناها عبر Namecheap، نضغط على رابط التفعيل الآن Activate Now من أجل الشهادة التي نريد استخدامها. نختار الآن برمجيّة خادوم الويب لدينا والتي تُحدِّد تنسيق الشهادة التي سيسلمها Namecheap لنا، الخيارات التي نختارها بشكل شائع هي "Apache + MOD SSL"، "nginx"، أو "Tomcat". نلصق CSR الخاصة بنا في المربّع ونضغط بعدها زر التالي Next. يجب أن نكون الآن في خطوة اختيار المُصادِق "Select Approver" من العمليّة، والتي سترسل بريد إلكتروني لطلب التحقّق إلى عنوان في تسجيل WHOIS لنطاقنا أو إلى عنوان من نوع مدير administrator للنطاق الذي نريد أن نحصل على شهادة له، نختار العنوان الذي نريد أن نرسل إليه البريد الإلكتروني للتحقّق. نقوم بتزويد معلومات التواصل الإداريّة "Administrative Contact Information" ونضغط على زر تقديم الطلب Submit order. التحقق من النطاقسيتم عند هذه النقطة إرسال بريد إلكتروني إلى عنوان المُصادِق "approver"، نفتح البريد الإلكتروني ونصادق على طلب الشهادة. تنزيل الشهاداتبعد المُصادَقة على الشهادة سيتم إرسالها عبر البريد الإلكتروني إلى القسم التقني Technical Contact، ستكون الشهادة الصادرة لنطاقنا وشهادة سلطة الشهادات الوسيطة CA's intermediate certificate في أسفل رسالة البريد الإلكتروني. ننسخها ونحفظها إلى خادومنا في نفس المكان الذي وضعنا فيه CSR ومفتاحنا الخاص. نقوم بتسمية الشهادة باسم النطاق مُضافًا إليه اللاحقة crt.، مثل example.com.crt، وتسمية الشهادة الوسيطة intermediate.crt. تكون الشهادة الآن جاهزة للتثبيت على خادوم الويب لدينا. مثال سلطة الشهادات الثاني: GoDaddyإنّ GoDaddy هي سلطة شهادات شائعة تملك كافّة أنواع الشهادات الأساسية، سنشرح عمليّة الحصول على شهادة نطاق مُفرَد، ولكن إن أردت نوعًا مختلفًا من الشهادات فبإمكانك فعل ذلك. اختيار وشراء الشهادةنذهب إلى صفحة GoDaddy لشهادات SSL. ننزل للأسفل ونضغط على زر البدء Get Started. نختار نوع شهادة SSL الذي نريده من القائمة المنسدلة: نطاق مُفرَد single domainنطاقات متعدّدة (multidomain (UCCwildcard نختار بعدها نوع الخطّة plan: نطاق domainمُنظَّمة organizationتحقّق مُوسَّع extended validationثم نختار المدى term (مُدّة الصلاحية). نضغط بعدها على زر إضافة إلى السلّة Add to Cart. نُراجع طلبنا الحالي ثم نضغط على المتابعة إلى الدفع Proceed to Checkout. ومن ثمّ نكمل التسجيل وعمليّة الدفع. طلب الشهادةبعد إكمال طلبنا نضغط على زر SSL Certificates* (أو نضغط على My Account > Manage SSL Certificates الموجودة في الزاوية العلوية اليمنى). نقوم بإيجاد شهادة SSL التي اشتريناها للتو ونضغط على زر الإعداد Set Up، إن لم تستخدم GoDaddy من قبل من أجل شهادات SSL فسيتم حثك على إعداد مُنتَج "SSL Certificates" وربط طلب شهادتك الأخيرة مع المُنتَج (نضغط على زر Set Up الأخضر وننتظر عدّة دقائق قبل تحديث متصفّحنا). بعد أن تتم إضافة مُنتَج "SSL Certificates" إلى حسابنا في GoDaddy ينبغي أن نرى شهادتنا الجديدة "New Certificate" وزر التنفيذ "Launch"، نضغط على الزر Launch الموجود بجانب شهادتنا الجديدة. نقوم بتقديم CSR الخاص بنا عن طريق لصقه في المربع، تُستخدَم خوارزميّة SHA-2 افتراضيًّا. نضع علامة في خانة التأشير I agree ونضغط على زر طلب الشهادة Request Certificate. التحقق من النطاقيجب الآن أن نُثبِت أنّنا نمتلك تحكّمًا بنطاقنا ونزوّد GoDaddy ببعض المستندات، تقوم GoDaddy بإرسال رسالة بريد إلكتروني للتحقّق من ملكيّة النطاق إلى العنوان الموجود في تسجيل WHOIS لنطاقنا، نتبع الخطوات الموجودة في رسائل البريد الإلكتروني التي تصلنا ونُصرِّح بإصدار الشهادة. تنزيل الشهادةبعد أن نُثبِت لـ GoDaddy أنّنا نمتلك النطاق، نتحقّق من بريدنا الإلكتروني (الذي قمنا من خلاله بالتسجيل في GoDaddy) بحثًا عن رسالة تقول أنّه تم إصدار شهادة SSL الخاصة بنا، نفتحها ونتبع رابط تنزيل الشهادة (أو نضغط على زر Launch بجانب شهادة SSL التي نريدها في لوحة تحكّم GoDaddy). نضغط الآن على زر التنزيل Download. نختار برمجيّة الخادوم التي نستخدمها من القائمة المنسدلة لنوع الخادوم Server type، إن كنّا نستخدم Apache HTTP أو Nginx نختار "Apache" ثم نضغط على زر تنزيل الملف المضغوط Download Zip File. نستخرج الملف المضغوط، الذي ينبغي أن يحتوي على ملفين crt.، أحدهما شهادة SSL الخاصّة بنا (التي ينبغي أن تملك اسمًا عشوائيًّأ) وحزمة bundle شهادة GoDaddy الوسيطة (gd_bundle-g2-1.crt)، نقوم بنسخهما إلى خادوم الويب لدينا، ونعيد تسمية الشهادة إلى اسم نطاقنا مع إضافة اللاحقة crt.، على سبيل المثال example.com.crt، ونعيد تسمية حزمة الشهادة الوسيطة إلى intermediate.crt. تكون الشهادة الآن جاهزة للتثبيت على خادوم الويب لدينا. تثبيت الشهادة على خادوم الويب لديناينبغي بعد الحصول على شهادتنا من سلطة الشهادات التي نختارها أن نقوم بتثبيتها على خادوم الويب لدينا، يتضمّن هذا إضافة بعض الأسطر المتعلّقة بـ SSL لملفّات إعدادات خادومنا. سنغطي في هذا القسم الإعدادات الأساسيّة لخادوم Nginx و Apache HTTP على Ubuntu. سنفترض الأمور التالية: يتوضّع المفتاح الخاص وشهادة SSL والشهادات الوسيطة لسلطة الشهادات-إن كان ذلك قابلًا للتطبيق- في الدليل الرئيسي على المسار home/sammy/يُدعى المفتاح الخاص باسم example.com.keyتُدعى شهادة SSL باسم example.com.crtتُوجد الشهادة أو الشهادات الوسيطة لسلطة الشهادات في ملف يُدعى intermediate.crtإن كنت تملك جدار ناري مُمكَّنًا لديك فتأكّد من أنّه يسمح بالمنفذ 443 (منفذ HTTPS)ملاحظة: يجب في البيئة الحقيقيّة تخزين هذه الملفّات في مكان يستطيع فقط المستخدم الذي يُشغِّل عملية خادوم الويب الرئيسيّة (عادة root) الوصول إليه، ينبغي الاحتفاظ بالمفتاح الخاص في مكان آمن. خادوم Nginxإن كنت ترغب باستخدام شهادتك مع خادوم Nginx على Ubuntu فاتبع هذا القسم. ينبغي في Nginx إن كانت سلطة الشهادات قد أعطتنا شهادة وسيطة أن نقوم بإنشاء ملف شهادة مُفرَد محمي بالسلاسل chained يحتوي على شهادتنا والشهادات الوسيطة لسلطة الشهادات. نذهب إلى الدليل الذي يحوي مفتاحنا الخاص، الشهادة، وشهادة سلطة البيانات الوسيطة (أي الملف intermediate.crt)، سنفترض أنّها في الدليل الرئيسي على سبيل المثال: cd ~بافتراض أنّ ملف الشهادة يُدعى example.com.crt نستخدم هذا الأمر لإنشاء ملف مُدمَج يُدعى example.com.chained.crt (نضع اسم نطاقنا بدلًا من example.com): cat example.com.crt intermediate.crt > example.com.chained.crtنذهب الآن إلى دليل إعدادات كتلة block خادوم Nginx، وبافتراض أنّه موجود في المسار etc/nginx/sites-enable/ نستخدم هذا الأمر للانتقال إليه: cd /etc/nginx/sites-enabledبافتراض أنّنا نريد إضافة SSL إلى ملف كتلة الخادوم الافتراضي default نفتح الملف من أجل تحريره: sudo vi defaultنبحث عن الأمر التوجيهي listen ونقوم بتعديله بحيث يبدو كما يلي: listen 443 ssl;نبحث بعدها عن الأمر التوجيهي server_name ونتأكد من أنّ قيمته مُطابِقة لاسم شهادتنا، نُضيف أيضًا الأوامر التوجيهيّة ssl_certificate و ssl_certificate_key لتحديد المسارات لشهادتنا وتحديد ملفّات المفاتيح الخاصّة (نضع الأسماء الموجودة لدينا بدلًا من example.com): server_name example.com; ssl_certificate /home/sammy/example.com.chained.crt; ssl_certificate_key /home/sammy/example.com.key;ولنسمح فقط بالشيفرات ciphers وميفاقات SSL protocols الأكثر أمانًا نُضيف الأسطر التالية إلى الملف: ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers AES256+EECDH:AES256+EDH:!aNULL;إن أردنا إعادة توجيه المرور عبر HTTP إلى HTTPS نستطيع إضافة هذه الكتلة الإضافيّة للخادوم في أعلى الملف (نضع معلوماتنا بدلًا من example.com): server { listen 80; server_name example.com; rewrite ^/(.*) https://example.com/$1 permanent; }نقوم بعدها بالحفظ والخروج. نعيد تشغيل خادوم Nginx الآن لتحميل الإعدادات الجديدة وتمكين TLS/SSL عبر HTTPS: sudo service nginx restartنختبر ذلك بالوصول إلى موقعنا عبر HTTPS، على سبيل المثال https://example.com. خادوم Apacheإن كنت ترغب باستخدام شهادتك مع خادوم Apache على Ubuntu فاتبع هذا القسم. نقوم بعمل نسخة احتياطيّة لملف إعداداتنا عن طريق نسخه، وبافتراض أنّ خادومنا يعمل على ملف إعدادات المُضيف الوهمي virtual الافتراضي، etc/apache2/sites-available/000-default.conf/، نستخدم هذه الأوامر لعمل النسخة: cd /etc/apache2/sites-available cp 000-default.conf 000-default.conf.origنفتح بعدها الملف لتحريره: sudo vi 000-default.confنبحث عن المُدخَل <VirtualHost *:80> ونقوم بتعديله بحيث يستمع خادوم الويب لدينا على المنفذ 443: <VirtualHost *:443>نقوم بعدها بإضافة الأمر التوجيهي ServerName إن لم يكن موجودًا مُسبقًا (نضع اسم نطاقنا هنا): ServerName example.comنضيف بعد ذلك الأسطر التالية لتحديد شهادتنا ومسارات المفاتيح (نضع مسارنا الفعلي هنا): SSLEngine on SSLCertificateFile /home/sammy/example.com.crt SSLCertificateKeyFile /home/sammy/example.com.keyإن كُنّا نستخدم Apache 2.4.8 أو أكثر نُحدِّد حزمة الشهادة الوسيطة لسلطة الشهادات بإضافة هذا السطر (نضع المسار الفعلي لدينا): SSLCACertificateFile /home/sammy/intermediate.crtإن كُنّا نستخدم إصدار أقدم من Apache نُحدِّد حزمة الشهادة الوسيطة لسلطة الشهادات بإضافة هذا السطر (نضع المسار الفعلي لدينا): SSLCertificateChainFile /home/sammy/intermediate.crtعند هذه النقطة أصبح خادومنا مُعدًّا ليستمع إلى HTTPS فقط (المنفذ 443)، لذا لن يتم تخديم طلبات HTTP (المنفذ 80)، لإعادة توجيه طلبات HTTP إلى HTTPS نضيف ما يلي إلى أعلى الملف (نكتب اسم نطاقنا بدلًا من example.com): <VirtualHost *:80> ServerName example.com Redirect permanent / https://example.com/ </VirtualHost>نقوم بالحفظ والخروج. نقوم بتمكين وحدة Apache SSL بتنفيذ هذا الأمر: sudo a2enmod sslنعيد تشغيل خادوم Apache الآن لتحميل الإعدادات الجديدة وتمكين TLS/SSL عبر HTTPS: sudo service apache2 restartنختبر ذلك بالوصول إلى موقعنا عبر HTTPS، على سبيل المثال https://example.com، نريد أيضًا اختبار الاتصال عبر HTTP، مثل http://example.com لنضمن أنّ إعادة التوجيه تعمل بشكل صحيح. الخاتمةنمتلك الآن فكرة جيّدة عن كيفيّة إضافة شهادة SSL موثوقة لتأمين خادوم الويب لدينا، احرص على أن تتسوّق من سلطة شهادات تجعلك مسرورًا معها. ترجمة -وبتصرّف- لـ How To Install an SSL Certificate from a Commercial Certificate Authority لصاحبه Mitchell Anicas.

هذا الدّرس هو الجزء الثّاني من سلسلة من 6 دروس حول "نظرة عامة على إنشاء تطبيقات موجهة لبيئة الإنتاج". إذا لم تقرأ الدّرس الأول فألق نظرة عليه قبل أن تواصل القراءة. سنعدّ في هذا الجزء من السّلسلة تطبيق PHP الذي اخترناه مثالا (ووردبريس) إضافة إلى خادوم أسماء نطاقات DNS خاص. سيستعمل مستخدمو التطبيق اسمَ النطاق للوصول إليه؛ عبر العنوان https://www.example.com على سبيل المثال. يحيل العنوان إلى موزع الحِمل الذي سيعمل وسيطا عكسيا Reverse proxy لخواديم التطبيق التي تتصل بدورها بخادوم قاعدة البيانات. يمكِّننا استخدامُ نظام أسماء نطاقات خاصة Private DNS من الإشارة إلى عناوين الخواديم ضمن الشبكة الداخلية بأسماء المستضيفات الخاصة بها مما يسهل من عملية إعداد الخواديم. سنعد العناصر للتوّ التي أشرنا إليها على ستة خواديم، طبقا للترتيب التالي: نظام أسماء نطاقات خاصة (المستضيفان ns1 وns2).خادوم قاعدة البيانات (db1).خواديم التطبيق (app1 وapp2).موزع حمل (lb1). فلنبدأ بإعداد النطاقات. خواديم النطاقات الداخليةيساعد استخدام أسماء نطاقات بدلا من عناوين IP في التعرف على الخواديم التي نعمل عليها، كما أنه ضروري حال إدارة الكثير من الخواديم؛ إذ يمكّن من إحلال خادوم مكان آخر بمجرد تحديث سجلات النطاق (ضمن ملف وحيد) بدلا من من تحديث عناوين IP ضمن الكثير من ملفات الإعداد. سنعدّ نظام نطاقات للإحالة إلى عناوين الشبكة الداخلية التي توجد بها الخواديم بدلا من عناوين IP. سنشير إلى كل عنوان في الشبكة الداخلية بمستضيف ضمن النطاق الفرعي nyc3.example.com. سيكون عنوان خادوم قاعدة البيانات ضمن الشبكة الداخلية - على سبيل المثال - db1.nyc3.example.com؛ وهو ما ستترجمه خواديم النطاقات إلى عنوان IP داخلي (خاص). تنبغي الإشارة إلى أن اختيار اسم النطاق الفرعي nyc3.example.com اعتباطي. في العادة يُستخدم اسم الموقع الجغرافي للنطاق الفرعي؛ في مثالنا، تشير nyc3 إلى أن الخواديم تتواجد في مركز البيانات NYC3، وexample.com إلى اسم النطاق الخاص بالتطبيق. ستحصل على خادومي BIND هما ns1 وns2. أضف عناوين IP الخاصة بجميع الخواديم التي تخطط لإعدادها إن كنت تعرفها سلفًا، وإلا أضف سجلات النطاق بالتزامن مع إنشاء الخواديم. ننتقل لإعداد خادوم قاعدة البيانات. إعداد خادوم قاعدة البياناتنريد - طبقا للخطة - توزيع الحمل بين خواديم التطبيقات؛ أي تلك التي تشغِّل PHP وApache، لذا سنفْصِل قاعدة البيانات عن خواديم التطبيق لجعلها على خادوم خاص بها. من المهم جدا فصل قاعدة البيانات عن التطبيق في حال أردنا إمكانية التوسع أفقيا Horizontally Scaling (إضافة خواديم جديدة لتعمل مع تلك الموجودة) في تطبيقات PHP. تغطي هذه الفقرة كل الخطوات الضرورية لإعداد خادوم قاعدة البيانات، لكن يمكنك معرفة المزيد عن إعداد قاعدة بيانات MySQL بعيدة بقراءة مقال كيفية إعداد قاعدة بيانات بعيدة لتحسين أداء موقع يستخدِم MySQL. تثبيت MySQLنفذ الأمرين التاليين على خادوم قاعدة البيانات (db1) لتثبيت خادوم MySQL: sudo apt-get update sudo apt-get -y install mysql-serverأدخل كلمة السر التي تريد استخدامها للحساب الإداري في MySQL عندما يُطلب منك ذلك. نفذ: sudo mysql_install_db sudo mysql_secure_installationستحتاج لإدخال كلمة سر المستخدِم الإداري التي اخترتها عند تثبيت خادوم MySQL؛ بعدها سيسألك إن كنت تريد تغيير كلمة السر هذه، اضغط زر N إذا كنت لا تريد تغييرها. بالنسبة لبقية الأسئلة اضغط زر Enter لتأكيد الاختيارات الافتراضية. إعداد MySQL لاستخدام واجهة الشبكة الداخليةافتح ملف إعداد MySQL عبر الأمر التالي: sudo nano /etc/mysql/my.cnfابحث عن bind-address وحدد قيمة المتغير بعنوان IP قاعدة البيانات ضمن الشبكة الداخلية: bind-address = db1.nyc3.example.comاحفظ الملف ثم أغلقه. أعد تشغيل MySQL: sudo service mysql restartضبط قاعدة البيانات ومستخدميهانحتاج الآن لإنشاء قاعدة بيانات والمستخدمين الذين ستتصل خواديم التطبيقات عن طريقهم إلى قاعدة البيانات. استخدم الأمر التالي للدخول إلى سطر أوامر MySQL: mysql -u root -pأدخل كلمة السر عندما تُطلب. أنشئ قاعدة بيانات بتنفيذ الأمر التالي في سطر أوامر MySQL: CREATE DATABASE app;يرفق خادوم MySQL كل مستخدم بالخواديم التي يمكنه منها الاتصال بقاعدة بيانات. يوجد في مثالنا خادوما تطبيق يتصلان بقاعدة البيانات؛ لذا سننشئ مستخدما لكل واحد منهما. أنشئ مستخدما في قاعدة البيانات باسم appuser يمكنه الاتصال من العناوين الداخلية لخواديم التطبيقات (أي app1 وapp2). يجب استخدام نفس كلمة السر للمستخدمَيْن (اختر كلمة سر واكتبها مكان password في الأمرين أدناه): CREATE USER 'appuser'@'app1.nyc3.example.com' IDENTIFIED BY 'password'; CREATE USER 'appuser'@'app2.nyc3.example.com' IDENTIFIED BY 'password';سنضبط في ما بعد امتيازات المستخدم appuser، نكتفي الآن بإعطائه تحكما كاملا على قاعدة البيانات app: GRANT ALL PRIVILEGES ON app.* TO 'appuser'@'app1.nyc3.example.com'; GRANT ALL PRIVILEGES ON app.* TO 'appuser'@'app2.nyc3.example.com'; FLUSH PRIVILEGES;تضمن الامتيازات الممتدة أن سكربت تثبيت التطبيق سيتمكن من تثبيته على قاعدة البيانات. إن كان لديك أكثر من خادومي تطبيقات، فيجب أن تنشئ حسابات المستخدمين الآن بنفس الكيفية. للخروج من سطر أوامر MySQL: exitاكتمل الآن إعداد خادوم قاعدة البيانات. ننتقل لإعداد خواديم التطبيقات. إعداد خواديم التطبيقاتتتصل خواديم التطبيق بخادوم قاعدة البيانات. اخترنا ووردبريس للتمثيل في هذا الدليل، وهو تطبيق PHP يعمل على خادوم ويب مثل Apache أو Nginx. سنضبط خادومين متطابقين لتوزيع الحِمل بينهما. تغطّي هذه الفقرة الخطوات الضرورية لإعداد خواديم التطبيق، لكن الموضوع مشروح بتفاصيل أكثر في مقال كيفية إعداد قاعدة بيانات بعيدة لتحسين أداء موقع يستخدِم MySQL انطلاقا من فقرة إعداد خادوم الويب. تثبيت Apache وPHPنفذ الأوامر التالية على كل واحد من الخادومين app1وapp2 لتثبيت Apache وPHP: sudo apt-get update sudo apt-get -y install apache2 php5-mysql php5 libapache2-mod-php5 php5-mcryptإعداد Apacheسنستخدم HAProxy على خادوم موزع الحمل للتعامل مع الاتصال عبر SSL، مما يعني أننا لا نريد أن يتصل المستخدمون بخادوميْ التطبيقات مباشرة. سنربط Apache بعنوان الشبكة الداخلية الخاص بكل واحد من الخادومين. نفّذ الأمر التالي على كل من الخادومين، app1 وapp2: sudo nano /etc/apache2/ports.confابحث عن السطر الذي توجد فيه العبارة Listen 80 وأضف عنوان خادوم التطبيق الخاص إليها، على النحو التالي (أبدل private_IP بعنوان IP الخاص بك): Listen private_IP:80احفظ الملف ثم أغلقه. يجعل هذا الإعداد خادوم Apache يُنصت لعناوين الشبكة الداخلية فقط؛ ممايعني أنه لا يمكن الوصول إليه عبر عنوان IP العمومي أو اسم المستضيف. أعد تشغيل Apache لأخذ التغيير في الحسبان: sudo service apache2 restartلا يمكن - وفق الإعداد الحالي - الوصول مباشرة إلى خادوم Apache؛ إذ تقتصر الاتصالات التي يقبلها على تلك القادمة من الشبكة الداخلية. سنعدّ - بعد قليل - موزع الحمل لإرسال الطلبات إلى الخواديم. تنزيل التطبيق وإعدادهاخترنا في هذه السّلسلة ووردبريس مثالا للتطبيق. إن كنت تستخدم تطبيق PHP مغايرا فيجب عليك تنزيله وعمل الإعدادات اللازمة (معلومات الاتصال بقاعدة البيانات على سبيل المثال)؛ ثم انتقل إلى الفقرة الموالية. نزل أرشيف ووردبريس على خادوم التطبيق الأول، app1: cd ~ wget http://wordpress.org/latest.tar.gzفك ضغط الأرشيف واستخرج ملفات ووردبريس: tar xvf latest.tar.gzانتقل إلى مجلّد ووردبريس المُستخرَج: cd wordpressيحتاج ووردبريس إلى مجلّد لوضع الملفات التي يحملها فيه؛ فلننشئ هذا المجلّد (wp-content/uploads): ode>mkdir wp-content/uploadsسنستخدم ملف إعداد ووردبريس النموذجي قالبا للإعداد: cp wp-config-sample.php wp-config.phpافتح الملف الإعداد من أجل تحريره: nano wp-config.phpاضبط اتصال ووردبريس بقاعدة البيانات بتحرير المعلومات الميَّزة في الأسطر التالية: /** The name of the database for WordPress */ define('DB_NAME', 'app'); /** MySQL database username */ define('DB_USER', 'appuser'); /** MySQL database password */ define('DB_PASSWORD', 'password'); /** MySQL hostname */ define('DB_HOST', 'db1.nyc3.example..com');نضيف الأسطر التالية إلى ملف إعداد ووردبريس لإخباره بأنه خلف وسيط عكسي يستخدم SSL (موزع الحمل يستخدم TLS/SSL للتعميّة): define('FORCE_SSL_ADMIN', true); if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') $_SERVER['HTTPS']='on';احفظ الملف ثم أغلقه. تبقّى الآن نقلُ ملفات ووردبريس إلى مجلد يمكن لخادوم الويب الوصول إليه من أجل خدمة الزوار. نقل ملفات التطبيق إلى جذر المستند Document Rootنحتاج الآن، بعد إعداد التطبيق، لنقل ملفات ووردبريس إلى جذر المستند في Apache حيث يمكن لخادوم الويب الوصول إليها وتقديمها لزوار الموقع. جذر المستند الافتراضي في Apache هو المسار var/www/html/ وهو ما سنستخدمه في مثالنا. احذف أولا ملف index.html الافتراضي: sudo rm /var/www/html/index.htmlاستخدم أداة rsync لنسخ ملفات ووردبريس إلى المجلد var/www/html/ اجعل www-data (الحساب الذي يشتغل به خادوم ويب Apache) مالكَ هذا المجلّد: sudo rsync -avP ~/wordpress/ /var/www/html sudo chgrp -R www-data /var/www/html/*أصبح خادوم التطبيق الأول app1 جاهزا؛ سنعد الآن خادوم التطبيق الآخر. تكرار ملفات التطبيق على الخواديم الأخرىيتوجب إعداد آلية لتكرار الملفات الموجودة في جذر المستند لخادوم الويب على مختلف الخواديم المكوِّنة للتطبيق؛ من أجل إبقاء ملفات التطبيق متجانسة عبر الخواديم. في حالة ووردبريس فإن استخدام واجهة الويب لتحميل الملفات وتثبيت الإضافات سيجعلها موجودة فقط على الخادوم الذي عالج الطلب. إن لم تكرَّر الملفات على جميع الخواديم فسيرى بعض زوار الموقع صفحات بصور ناقصة وإضافات مكسورة. إن كنت تستخدم تطبيقا آخر غير ووردبريس لا يحفظ بياناته (الملفات المحمَّلة والإضافات المنزّلة مثلا) على خادوم التطبيق فيمكنك الاكتفاء بنقل الملفات إلى الخادوم يدويا مرة واحدة. في هذه الحالة استخدم أداة rsync لنقل ملفات التطبيق من الخادوم app1 إلى الخادوم app2. يمكن استخدام GlusterFS لإنشاء تجزئة قرص مكرَّرة من الملفات الضرورية. الطريقة مشروحة في فقرة مزامنة الملفات في تطبيقات الويب ضمن مقال كيف تستخدم HAProxy لتوزيع الحمل بين خواديم تطبيق ووردبريس. اتبع الخطوات (تجاوز فقرة إعداد ملفات المستضيف لأن خادوم النطاقات لدينا يتولى المهمة) ثم اضبُط تكرار الملفات بين app1 وapp2. بعد الانتهاء من إعداد تكرار الملفات بين الخواديم نكون على استعداد لتجهيز موزِّع الحمل. إعداد موزع الحملاخترنا HAProxy موزعا للحمل؛ وسيعمل وسيطا عكسيا لخواديم التطبيق. سيصل المستخدمون إلى التطبيق عبر عنوان شبيه بhttps://www.example.com بعد المرور بموزع الحمل. تشرح هذه الفقرة الخطوات الضرورية لإعداد خادوم موزِّع للحمل/ نسخ شهادة SSLنفذ الخطوات التالية على خادوم موزع الحمل، lb1. ضع شهادة SSL (أحد متطلبات الجزء الأول من السّلسلة) ومفتاح الشهادة، إضافة لأي شهادات من سلطة وسيطة ضمن ملف pem. واحد (نفترض أن شهادات SSL موجودة في المجلّد root/certs/): cd /root/certs cat www.example.com.crt CAintermediate.ca-bundle www.example.com.key > www.example.com.pemثم انسخ ملف pem إلى المجلّد etc/ssl/private/: sudo cp www.example.com.pem /etc/ssl/private/سيستخدم HAProxy هذا الملف لإنهاء SSL. تثبيت HAProxyنفذ الأوامر التالية على خادوم موزع الحمل، lb1: sudo add-apt-repository ppa:vbernat/haproxy-1.5 sudo apt-get update sudo apt-get -y install haproxyإعداد HAProxyنحتاج لضبط إعداداتٍ عامة في HAProxy إضافة لإنهاء SSL والنهايات الخلفية Backend والأمامية Frontend المناسبة لجعله يعمل مع خواديم التطبيق. افتح ملف إعداد HAProxy لتحريره: sudo nano /etc/haproxy/haproxy.cfgخيارات عامة في إعداد HAProxyأول ما يجب فعله هو تحديد قيمة معقولة للحد الأعلى لعدد الاتصالات maxconn. يحدد هذا المتغير عدد الاتصالات الأكبر التي يسمح بها HAProxy في نفس الوقت؛ وهو ما قد يؤثر على جودة الخدمة ويحول دون انهيار خادوم الويب عند محاولته الإجابة على الكثير من الطلبات. يجب أن تبحث وتجرب قيما عدة لإيجاد تلك المناسبة لبيئة عملك. أضف السطر التالي إلى ملف إعداد HAProxy (اخترنا القيمة 2048): maxconn 2048أضف السطر التالي لضبط الحجم الأكبر للذاكرة المؤقتة لتخزين مفاتيح التعمية: tune.ssl.default-dh-param 2048أضف السطرين التاليين ضمن مقطع defaults مباشرة بعد السطر الذي توجد به mode http: option forwardfor option http-server-closeتفعل الأسطر التالية إذا أضيفت ضمن مقطع defaults صفحة إحصاءات HAProxy (أبدل user وpassword بقيم آمنة): stats enable stats uri /stats stats realm Haproxy\ Statistics stats auth user:passwordيمكن بعد التفعيل عرض إحصاءات HAProxy بالذهاب إلى الصفحة التالية https://www.example.com/stats. لم ننته بعد من ملف إعدادات HAProxy، سنضبط في ما يلي إعدادات الوسيط. إعداد الوسيط في HAProxyنبدأ بإضافة نهاية أمامية للتعامل مع اتصالات HTTP الواردة. نضيف في نهاية ملف الإعداد نهاية أمامية باسم www-http عبر الأسطر التالية: frontend www-http bind www.example.com:80 reqadd X-Forwarded-Proto:\ http default_backend app-backendالهدف من هذا الإعداد هو قبول اتصالات HTTP من أجل توجيهها عبر اتصال HTTPS. ثم نضيف نهاية أمامية للتعامل مع اتصالات HTTPS، تأكد من تحديد ملف pem المناسب. frontend www-https bind www.example.com:443 ssl crt /etc/ssl/private/www.example.com.pem reqadd X-Forwarded-Proto:\ https default_backend app-backendنستكمل الإعداد بضبط النهاية الخلفية: backend app-backend redirect scheme https if !{ ssl_fc } server app1 app1.nyc3.example.com:80 check server app2 app2.nyc3.example.com:80 checkتحدد النهاية الخلفية خواديم التطبيقات التي يوزَّع بينها الحمل. يطلب السطر: redirect scheme https if !{ ssl_fc } توجيه اتصالات HTTP إلى HTTPS. احفظ ملف haproxy.cfg ثم أغلقه. HAProxy جاهز الآن لبدء العمل؛ لكن سنفعل أولا السجلات Logs. تفعيل سجلات HAProxyافتح ملف rsyslog للتحرير: sudo nano /etc/rsyslog.confابحث عن الأسطر التالية وانزع علامة التعليق من أجل تفعيل بروتوكول UDP عند استقبال سجلات النظام Syslog. تبدو الأسطر كما يلي بعد نزع علامة التعليق: $ModLoad imudp $UDPServerRun 514 $UDPServerAddress 127.0.0.1أعد تشغيل خدمة rsyslog لتفعيل الإعداد الجديد: sudo service rsyslog restartسجل HAProxy مفعَّل الآن وسيُنشأ ملف var/log/haproxy.log/ فور بدء عمل HAProxy. إعادة تشغيل HAProxyأعد تشغيل HAProxy لأخذ التعديلات في الحسبان. sudo service haproxy restartاكتمل الآن إعداد موزع الحِمل، ننتقل لتثبيت التطبيق (ووردبريس). تثبيت ووردبريسسيتوجب علينا - قبل البدء في استخدام ووردبريس - تشغيل سكربت التثبيت الذي يهيئ قاعدة البيانات ليستخدمها ووردبريس. أدخل إلى العنوان التالي في المتصفح: https://www.example.com/wp-admin/install.phpستظهر شاشة تثبيت ووردبريس. املأء الحقول بما يناسب ثم انقر على زر التثبيت. بعد انتهاء تثبيت ووردبريس يصبح التطبيق جاهزا للعمل. خاتمةاكتمل الآن إعداد الخواديم المكوِّنة للتطبيق، وهذا الأخير جاهز للاستخدام. يمكنك الدخول بحساب المدير كما يمكن لزوار موقعك الوصول إليه عبر HTTPS عند استخدام اسم النطاق المناسب. تأكد قبل الانتقال إلى الجزء الموالي من الدليل أن التطبيق يعمل بطريقة صحيحة. ترجمة -وبتصرّف- لمقال Building for Production: Web Applications — Deploying لصاحبه Mitchell Anicas. حقوق الصورة البارزة: Designed by Freepik.

عند إعداد خادوم ويب توجد غالبًا أقسام من الموقع نرغب بتقييد الوصول إليها، تُوفِّر تطبيقات الويب عادةً طرق التصريح authorization والاستيثاق authentication الخاصّة بها، ولكن يُمكِن استخدام خادوم الويب بذاته لتقييد الوصول إن كانت هذه الطّرق غير كافية أو غير متوفّرة. سنشرح في هذا الدّرس كيف نحمي الممتلكات assets باستخدام كلمة سر على خادوم ويب Apache يعمل على Ubuntu. المتطلبات الأساسيةنحتاج للوصول إلى بيئة خادوم Ubuntu لكي نبدأ، نحتاج أيضًا لمستخدم غير جذري non-root مع صلاحيّات sudo من أجل تنفيذ مهام إداريّة administrative، لكي تتعلّم كيفيّة إعداد مستخدم بامتيازات sudo اتبع دليلنا للإعداد الأولي لخادوم Ubuntu 14.04. تثبيت حزمة أدوات Apache المساعدةسنستخدم أداة مُساعِدة utility تُدعى htpasswd من أجل إنشاء الملف الذي يقوم بتخزين كلمات السّر التي نحتاجها للوصول إلى المحتوى المُقيَّد لدينا، تُوجَد هذه الأداة في الحِزمة apache2-utils داخل المستودعات repositories في Ubuntu. نُحدِّث الذاكرة المؤقتة cache للحِزَم المحليّة ونُثبِّت الحِزمَة بكتابة هذا الأمر، سننتهز الفرصة أيضًا لتثبيت خادوم Apache2 في حال لم يكن مُثبّتًا لديك: sudo apt-get update sudo apt-get install apache2 apache2-utilsإنشاء ملف كلمات السرنستطيع الآن الوصول للأمر htpasswd واستخدامه لإنشاء ملف كلمات السّر والذي يستعمله خادوم Apache لاستيثاق authenticate المستخدمين، سنقوم بإنشاء ملف مخفي لهذا الغرض يُدعى htpasswd. بداخل دليل الإعدادات etc/apache2/. عند استخدام هذه الأداة لأوّل مرّة نحتاج لإضافة الخيار c- لإنشاء الملف المُحدَّد، نقوم بتحديد اسم مستخدم (في هذا المثال sammy) في نهاية الأمر لإنشاء مُدخَل جديد بداخل الملف: sudo htpasswd -c /etc/apache2/.htpasswd sammyسيتم سؤالنا عن تزويد كلمة سر وتأكيدها للمستخدم. نترك الوسيط c- لأي مستخدمين آخرين نرغب في إضافتهم: sudo htpasswd /etc/apache2/.htpasswd another_userإن قمنا بمشاهدة محتويات الملف نستطيع رؤية اسم المستخدم وكلمة السّر المُشفّرة لكل تسجيل record: cat /etc/apache2/.htpasswdsammy:$apr1$lzxsIfXG$tmCvCfb49vpPFwKGVsuYz. another_user:$apr1$p1E9MeAf$kiAhneUwr.MhAE2kKGYHK.إعداد استيثاق كلمة السر لخادوم Apacheالآن وبعد أن أصبحنا نمتلك ملف لأسماء المستخدمين وكلمات السّر في صيغة يستطيع خادوم Apache قراءتها، نحتاج لإعداد Apache لكي يتفحّص هذا الملف قبل تخديم محتوانا المحمي، بإمكاننا فعل هذا بطريقتين مختلفتين. الخيار الأول هو تحرير edit إعدادات Apache وإضافة حماية كلمة السّر إلى ملف المضيف الافتراضي virtual host file. يُعطينا هذا الخيار أداء أفضل بشكل عام لأنّه يتجنّب تكلفة قراءة ملفات إعدادات مُوزَّعة، إن كنت تملك هذا الخيار فإنّنا ننصح بهذا الأسلوب. إن لم تكن لدينا القدرة على تعديل ملف المضيف الافتراضي (أو كنّنا نستخدم مُسبقًا ملفات htaccess. لأغراض أخرى) نستطيع تقييد النفاذ باستخدام ملف htaccess.، يستخدم Apache ملفّات htaccess. من أجل السّماح لتعيين بعض عناصر الإعدادات داخل ملف في دليل المحتوى. العيب في هذا هو أنّه يجب على Apache إعادة قراءة هذه الملفّات عند كل طلب يتضمّن هذا الدّليل ممّا قد يؤثر على الأداء. اختر الخيار الذي يُناسِب احتياجاتك أدناه. إعداد التحكم بالنفاذ Access Control داخل تعريف المضيف الافتراضينبدأ بفتح ملف المضيف الافتراضي الذي نرغب بإضافة تقييد له، سنستخدم في مثالنا الملف 000-default.conf الذي يحمل المضيف الظاهري الافتراضي والمُثبَّت عبر حزمة apache في Ubuntu: sudo nano /etc/apache2/sites-enabled/000-default.confينبغي أن يبدو المحتوى داخل الملف مُشابِهًا لما يلي بعد إزالة التّعليقات: etc/apache2/sites-enabled/000-default.conf/ <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>يتم الاستيثاق على أساس كل دليل، سنحتاج لإعداد الاستيثاق إلى استهداف الدّليل الذي نرغب بتقييد الوصول إليه بواسطة كتلة <Directory ___>، في مثالنا سنقيّد الوصول إلى كامل جذر المستند document root ولكن نستطيع تعديل القائمة لاستهداف دليل مُحدَّد داخل مساحة الويب: etc/apache2/sites-enabled/000-default.conf/ <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined <Directory "/var/www/html"> </Directory> </VirtualHost>نُحدِّد داخل كتلة الدّليل أنّنا نرغب بإعداد استيثاق أساسي Basic، نختار من أجل AuthName اسم حقل يتم عرضه عند السؤال عن الاعتمادات credentials، نستخدم الأمر التوجيهي AuthUserFile ليشير إلى Apache عن ملف كلمات السّر الذي أنشأناه، سنحتاج أخيرًا إلى valid-user للوصول إلى هذا المورد، وهذا يعني أنّه سيتم السماح بالدخول لكل من يثبت صحّة هويته بكلمة سر: etc/apache2/sites-enabled/000-default.conf/ <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined <Directory "/var/www/html"> AuthType Basic AuthName "Restricted Content" AuthUserFile /etc/apache2/.htpasswd Require valid-user </Directory> </VirtualHost>عند الانتهاء نحفظ ونغلق الملف، نعيد تشغيل Apache لتنفيذ سياسة policy كلمات السّر: sudo service apache2 restartيجب الآن أن يكون الملف الذي حدّدناه محميًّا بكلمة سر. إعداد التحكم بالنفاذ Access Control باستخدام ملفات htaccess.إن كُنّا نرغب بإعداد حماية كلمة السّر باستخدام ملفّات htaccess. بدلًا من الطريقة السّابقة فينبغي أن نبدأ بتحرير ملف إعدادات Apache الرئيسي للسماح بملفّات htaccess.: sudo nano /etc/apache2/apache2.confنبحث عن الكتلة <Directory> من أجل الدّليل var/www/ الذي يحتوي جذر المستند، نقوم بتشغيل معالجة htaccess. بتغيير الأمر التّوجيهي AllowOverride داخل تلك الكتلة من “None” إلى “All”: etc/apache2/apache2.conf/ . . . <Directory /var/www/> Options Indexes FollowSymLinks AllowOverride All Require all granted </Directory> . . .عند الانتهاء نحفظ ونغلق الملف. نحتاج بعد ذلك لإضافة ملف htaccess. إلى الدّليل الذي نرغب بتقييد الوصول إليه، في هذا المثال سنقيّد الوصول إلى كامل جذر المستند (كامل الموقع) والذي يتواجد في المسار var/www/html/، ولكن يُمكننا وضع هذا الملف في أي دليل نرغب بتقييد الوصول إليه: sudo nano /var/www/html/.htaccessنُحدِّد بداخل هذا الملف أنّنا نرغب بإعداد استيثاق أساسي Basic، نختار من أجل AuthName اسم حقل يتم عرضه عند السؤال عن الاعتمادات credentials، نستخدم الأمر التوجيهي AuthUserFile ليشير إلى Apache عن ملف كلمات السّر الذي أنشأناه، سنحتاج أخيرًا إلى valid-user للوصول إلى هذا المورد، وهذا يعني أنّه سيتم السماح بالدخول لكل من يثبت صحّة هويته بكلمة سر: var/www/html/.htaccess/ AuthType Basic AuthName "Restricted Content" AuthUserFile /etc/apache2/.htpasswd Require valid-userنحفظ ونغلق الملف، نعيد تشغيل خادوم الويب لنحمي بكلمة سر كل المحتوى الموجود في الدّليل بواسطة الملف htaccess.: sudo service apache2 restartتأكيد استيثاق كلمة السرللتأكّد من أنّ المحتوى محمي لدينا نُجرِّب النفاذ إلى المحتوى المُقيَّد من متصفّح إنترنت، يجب أن يتم عرض مُحث prompt لاسم المستخدم وكلمة السّر يُشبه ما يلي: إن أدخلنا الاعتمادات الصحيحة سيتم السماح لنا بالنفاذ إلى المحتوى، وإن أدخلنا الاعتمادات الخاطئة أو ضغطنا على إلغاء Cancel سنشاهد صفحة الخطأ "Authorization Required": الخاتمة يجب أن يكون لدينا الآن كل ما نحتاجه لإعداد استيثاق أساسي لموقعنا، فلنضع في اعتبارنا أنّ حماية كلمة السّر يجب أن تكون جنبًا إلى جنب مع تشفير SSL كي لا يتم إرسال اعتماداتنا إلى الخادوم في شكل نص مُجرَّد plain text، يمكنك الإطلاع أيضا على كيفيّة إنشاء شهادة SSL موقّعة ذاتيًّا لاستخدامها مع Apache. ترجمة -وبتصرّف- لـ How To Set Up Password Authentication with Apache on Ubuntu 14.04 لصاحبه Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.

من المهم عند العمل على خادوم ويب تنفيذ تدابير أمنيّة لحماية موقعنا ومستخدمينا، إنّ حماية مواقع الإنترنت والتّطبيقات لدينا باستخدام سياسات الجّدار النّاري firewall policies وتقييد الوصول إلى بعض المناطق باستخدام استيثاق كلمة السّر password authentication هو نقطة بدء رائعة لتأمين النظام لدينا، ومع ذلك من المُرجَّح أن يجذب أي طلب لكلمة السّر مُتاح للعوام محاولات القوة القاسية brute force من قبل المستخدمين والروبوتات bots الخبيثين. يتمكّن إعداد fail2ban من المساعدة في الحد من هذه المشكلة، فعندما يفشل المستخدمون بالاستيثاق إلى خدمة ما بشكلٍ متكرّر (أو الانخراط في أي نشاط مشبوه آخر) تستطيع fail2ban أن تصدر حظرًا مؤقّتًا على عنوان IP المُهاجِم عن طريق التّعديل بشكل ديناميكي على سياسة الجّدار النّاري التي تعمل حاليًّا. تعمل كل "jail" تابعة لـ fail2ban عن طريق تفحّص السّجلّات المكتوبة من قبل خدمة ما بحثًا عن أنماط patterns تُشير إلى محاولات فاشلة بالاستيثاق. من السّهل إعداد fail2ban لكي تراقب سجلّات Apache باستخدام مُرشِّحات filters الإعداد المُضمَّنة. سنشرح في هذا الدّرس كيفيّة تثبيت fail2ban وإعدادها لمراقبة سجلّات Apache بحثًا عن محاولات التّسلّل، سنستخدم خادوم Ubuntu من أجل هذا. المتطلبات الأساسيةينبغي قبل أن نبدأ أن نمتلك خادوم Ubuntu مع إعداد حساب غير جذري non-root، ويجب أن يكون هذا الحساب مُعدًّا بامتيازات sudo من أجل إصدار أوامر إداريّة administrative commands. لكي تتعلّم كيفيّة إعداد مستخدم بامتيازات sudo اتبع دليلنا للإعداد الأولي لخادوم Ubuntu 14.04. تثبيت Apache وإعداد استيثاق كلمة السرإن كنتَ مهتمًّا بحماية خادوم Apache باستخدام fail2ban فمن الغالب أنك تملك مسبقًا خادومًا مُعدًّا وقيد التشغيل، وإن لم تكن كذلك تستطيع تثبيت Apache من خلال مستودعات Ubuntu الافتراضيّة باستخدام apt. فلنقم بتحديث دليل الحِزَم المحلّي وتثبيت Apache بكتابة ما يلي: sudo apt-get update sudo apt-get install apache2إنّ خدمة fail2ban مفيدة من أجل حماية نقاط تسجيل الدخول، ومن أجل أن يكون هذا مفيدًا لتثبيت Apache يجب تنفيذ استيثاق كلمة السّر على الأقل لمجموعة فرعيّة من المحتوى على الخادوم، تستطيع اتباع هذا الدّليل لإعداد حماية كلمة السّر من أجل خادوم Apache لديك. تثبيت Fail2Banبعد أن أصبح خادوم Apache لدينا قيد التّشغيل وتمّ تمكين استيثاق كلمة السّر عليه نستطيع المضي قدمًا وتثبيت fail2ban (نقوم هنا بإدراج إعادة جلب للمستودع مرّة أخرى في حال قمتَ بالفعل بتثبيت Apache في الخطوات السّابقة): sudo apt-get update sudo apt-get install fail2banسيقوم هذا بتثبيت برمجيّة fail2ban، والتي هي مُعدَّة افتراضيًّا لكي تحظر فقط محاولات تسجيل دخول SSH الفاشلة، نحتاج إلى تمكين بعض القواعد التي تقوم بإعدادها لكي تتفحّص سجلّات Apache لدينا بحثًا عن أنماط تشير إلى نشاط خبيث. ضبط الإعدادات العامة داخل Fail2Banنحتاج لكي نبدأ إلى ضبط ملف الإعدادات الذي تستخدمه fail2ban لتحديد سجلّات التطبيقات التي يجب أن تراقبها والإجراءات التي يجب أن يتمّ اتخاذها عند إيجاد مُدخلات مُخالِفة، ومن الموارد الرئيسيّة التي يتم تزويدنا بها لهذا الأمر نجد الملف etc/fail2ban/jail.conf/. ولإجراء التعديلات نحتاج إلى نسخ هذا الملف إلى etc/fail2ban/jail.local/، وهذا يمنع الكتابة فوق التغييرات التي أجريناها إن قام تحديث الحِزمة package بتزويدنا بملف جديد افتراضي: sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.localنقوم بفتح الملف الجديد المنسوخ حتى نستطيع إعداد مراقبة سجلّات Apache لدينا: sudo nano /etc/fail2ban/jail.local تغيير الإعدادات الافتراضيةينبغي أن نبدأ بتقييم المجموعة الافتراضيّة داخل الملف لنرى إن كانت تُلائِم احتياجاتنا، نستطيع إيجاد هذه المجموعة تحت قسم [DEFAULT] داخل الملف. تقوم هذه العناصر بتعيين السّياسة policy العامّة وبإمكاننا تجاوز أي منها في jails مُحدّدة. ومن أوائل العناصر التي يجب أن ننظر إليها هي قائمة العُمَلاء Clients التي لا تخضع لسياسات fail2ban، ويتم تعيينها باستخدام الأمر التّوجيهي ignoreip، من الجّيد أحيانًا إضافة عنوان IP الخاص بنا أو بشبكتنا إلى قائمة الاستثناءات لتجنّب حظر أنفسنا، على الرّغم من أنّ هذا أقل من أن يكون مشكلة مع تسجيلات الدّخول إلى خادوم الويب إن كان بإمكاننا المحافظة على النفاذ للـ Shell، حيث أنّنا دائمًا نستطيع إلغاء الحظر يدويًّا. نستطيع إضافة عناوين IP أو شبكات إضافيّة بفصلها بمسافة Space إلى القائمة الحاليّة: etc/fail2ban/jail.local/ [DEFAULT] . . . ignoreip = 127.0.0.1/8 your_home_IPومن العناصر الأخرى التي قد نرغب بضبطها نجد bantime والذي يتحكّم بعدد الثّواني التي سيتم خلالها حظر العضو المُخالِف، من المثالي تعيينه إلى مدّة طويلة كافية لتكون مُدمِّرة لجهود المستخدم الخبيث، وفي نفس الوقت قصيرة بما فيه الكفاية لتسمح للمستخدمين الشرعيّين لتصحيح أخطائهم، يتم تعيين هذه القيمة افتراضيًّا إلى 600 ثانية (10 دقائق)، قم بزيادتها أو إنقاصها على النحو الذي تراه مناسبًا: etc/fail2ban/jail.local/ [DEFAULT] . . . bantime = 3600يُحدّد العنصران التّاليان نطاق أسطر السّجلّات المستخدمة لتحديد العميل المُخالِف، يُحدِّد findtime المدّة الزمنية مُقدّرةً بالثواني ويُشير الأمر التّوجيهي maxretry إلى عدد المحاولات التي يتم التسامح معها خلال تلك المدّة، فإن قام العميل بعدد محاولات أكثر من maxretry خلال المدّة الزمنيّة المُحدّدة بواسطة findtime فسيتمّ حظره: etc/fail2ban/jail.local/ [DEFAULT] . . . findtime = 3600 # These lines combine to ban clients that fail maxretry = 6 # to authenticate 6 times within a half hour.إعداد تنبيهات البريد الإلكتروني (اختياري)نستطيع تمكين تنبيهات البريد الإلكتروني إن كُنّا نرغب باستقبال بريد كلّما حدث حظر، ويتوجب علينا أولًا لفعل هذا أن نقوم بإعداد MTA على خادومنا بحيث يستطيع إرسال بريد إلكتروني، لتتعلّم كيفيّة استخدام Postfix من أجل هذه المهمّة اتبع هذا الدّليل. ويتوجّب علينا بعد الانتهاء من إعداد MTA أن نقوم بضبط بعض الإعدادات الإضافيّة داخل القسم [DEFAULT] من الملف etc/fail2ban/jail.local/. نبدأ بإعداد الأمر التّوجيهي mta، فإن قمنا بإعداد Postfix -كما هو واضح في الدّرس التعليمي المذكور بالأعلى- نُغيّر هذه القيمة إلى “mail”: etc/fail2ban/jail.local/ [DEFAULT] . . . mta = mailيجب أن نختار عنوان البريد الإلكتروني الذي سيتم إرسال التنبيهات إليه ونكتبه داخل الأمر التّوجيهي destemail، بإمكاننا استخدام الأمر التّوجيهي sendername لتعديل حقل المُرسِل Sender في تنبيهات البريد الإلكتروني: etc/fail2ban/jail.local/ [DEFAULT] . . . destemail = youraccount@email.com sendername = Fail2BanAlertsإنّ الإجراء action -بحسب تعبير fail2ban- هو العمليّة التي تتلو فشل العميل بالاستيثاق مرات كثيرة، الإجراء الافتراضي (يُدعى _action) هو ببساطة حظر عنوان الـ IP من المنفذ port قيد الطلب، ويوجد على أيّة حال إجراءان آخران مُعدّان مُسبقًا يُمكن استخدامهما إن كنّا نملك إعداد بريد إلكتروني. نستطيع استخدام الإجراء action_mw لحظر العميل وإرسال تنبيه بريد إلكتروني إلى الحساب المضبوط لدينا مع تقرير “whois” حول عنوان المُخالِف، بإمكاننا أيضًا استخدام الإجراء action_mwl والذي يقوم بنفس العمل ولكن يقوم بتضمين سطور سجلّات المُخالِف والتي قامت بإطلاق عمليّة الحظر: etc/fail2ban/jail.local/ [DEFAULT] . . . action = %(action_mwl)sإعداد Fail2Ban لمراقبة سجلات Apacheبعد أن قمنا بضبط بعض إعدادات fail2ban العامّة في مكانها الصحيح نستطيع التركيز على تمكين بعض jails المرتبطة بـ Apache والتي ستراقب سجلّات خادوم الويب لدينا بحثًا عن أنماط سلوك مُعيّن. تتميّز كل jails داخل ملف الإعدادات بترويسة header تحتوي اسم الـ jail بين قوسين مربّعين (كل قسم يشير إلى إعدادات jail مُحدّدة ما عدا القسم [DEFAULT])، وافتراضيًّا نجد ssh] jail] هي الوحيدة المُمكّنة. لتمكين مراقبة السّجلّات بحثًا عن محاولات تسجيل دخول Apache سنقوم بتمكين [jail [apache، نُعدّل الأمر التّوجيهي enabled داخل هذا القسم بحيث يصبح true: etc/fail2ban/jail.local/ [apache] enabled = true port = http,https filter = apache-auth logpath = /var/log/apache*/*error.log maxretry = 6 . . .إن كان خادوم Apache يقوم بالكتابة إلى موقع السّجلّات الافتراضي (var/log/apache/error.log/) تكون jail مُعدّة مُسبقًا للبحث في المكان المناسب، وإن كُنّا نقوم بوضع السّجلّات في مكان آخر نُعدِّل مسار السّجل logpath حسب الحاجة، لا تتردد في ضبط الأمر التّوجيهي maxretry أو إضافة قيمة findtime لهذه الـ jail إن كنت ترغب في وضع قيود أخرى لهذه الـ jail تحديدًا: etc/fail2ban/jail.local/ [apache] enabled = true port = http,https filter = apache-auth logpath = /var/log/apache/custom_log_location.log maxretry = 3 findtime = 600 . . .تهتم jail السابقة بأمر حظر فشل الاستيثاق الأساسي، توجد أيضًا بعض jails التي تستحق تمكينها (إنّ jail التي تُدعى [apache-multiport] هي jail تراثيّة legacy لا نحتاج إليها). تُستَخدم jail التي تُدعى [apache-noscript] لحظر العُملاء الذين يبحثون عن تنفيذ واستغلال scripts على الموقع، إن لم نكن نستخدم PHP أو أيّة لغة برمجة أخرى بالتزامن مع خادوم الويب لدينا فبإمكاننا تمكين هذه الـ jail لحظر هؤلاء العملاء الذين يطلبون هذا النوع من الموارد: etc/fail2ban/jail.local/ [apache-noscript] enabled = true . . .تُستخدَم jail التي تُدعى [apache-overflows] لحظر العملاء الذين يحاولون طلب روابط URLs طويلة غير معتادة ومثيرة للشك، والتي تكون عادةً إشارة لمحاولات استغلال Apache عن طريق محاولة تحريض حدوث buffer overflow. بإمكاننا تمكين هذه الـ jail إن أردنا منع هذا النوع من الهجمات: etc/fail2ban/jail.local/ [apache-overflows] enabled = true . . .نستطيع القيام بفحوصات إضافيّة للتحقّق عن طريق نسخ ولصق المدخلة entry التي تُدعى [apache-overflows] وتعديلها قليلًا، فعلى سبيل المثال بإمكاننا نسخ ولصق هذا القسم وتعديل اسم الـ jail والمُرشِّح filter إلى apache-badbots لإيقاف بعض نماذج طلبات الروبوتات bots الخبيثة المعروفة: etc/fail2ban/jail.local/ [apache-overflows] enabled = true port = http,https filter = apache-overflows logpath = /var/log/apache*/*error.log maxretry = 2 [apache-badbots] enabled = true port = http,https filter = apache-badbots logpath = /var/log/apache*/*error.log maxretry = 2إن لم نكن نستخدم Apache لتزويدنا بالنفاذ إلى محتوى الويب داخل دليل المستخدمين الرئيسي فبإمكاننا نسخ ولصق ما سبق مرةً أخرى وتغيير أسماء الـ jail والمُرشِّح إلى apache-nohome: etc/fail2ban/jail.local/ [apache-overflows] enabled = true port = http,https filter = apache-overflows logpath = /var/log/apache*/*error.log maxretry = 2 [apache-badbots] enabled = true port = http,https filter = apache-badbots logpath = /var/log/apache*/*error.log maxretry = 2 [apache-nohome] enabled = true port = http,https filter = apache-nohome logpath = /var/log/apache*/*error.log maxretry = 2وأخيرًا إن كُنّا نستخدم Apache مع PHP فقد نرغب بتمكين jail التي تُدعى [php-url-fopen] والتي تقوم بحجب محاولات استخدام سلوك PHP مُحدَّد لأغراض خبيثة، من المحتمل أن يتوجّب علينا تغيير الأمر التّوجيهي logpath لكي يشير إلى مسار السّجلّات الصحيح (المسار الافتراضي على Ubuntu هو var/log/apache2/access.log/)، نستطيع استخدام نموذج مشابه للنموذج الذي يوافق سجل الأخطاء في jails الأخرى: etc/fail2ban/jail.local/ [php-url-fopen] enabled = true port = http,https filter = php-url-fopen logpath = /var/www/apache*/*access.logعندما ننتهي من التّعديلات التي نحتاجها نقوم بحفظ وإغلاق الملف. تنفيذ Apache Jails لدينالكي يتم تنفيذ تغييراتنا على الإعدادات نحتاج إلى إعادة تشغيل خدمة fail2ban، نستطيع فعل ذلك بكتابة ما يلي: sudo service fail2ban restartينبغي أن يتم إعادة تشغيل الخدمة وتنفيذ سياسات الحظر المختلفة التي قمنا بإعدادها. الحصول على معلومات حول Jails التي تم تمكينهانستطيع رؤية جميع jails التي تمّ تمكينها لدينا باستخدام الأمر fail2ban-client: sudo fail2ban-client statusينبغي أن نشاهد قائمة بكامل jails التي قمنا بتمكينها: Status |- Number of jail: 7 `- Jail list: php-url-fopen, apache-overflows, apache-noscript, ssh, apache-badbots, apache-nohome, apacheنستطيع أن نرى قيام fail2ban بتعديل قواعد الجّدار النّاري لدينا لإنشاء إطار عمل لمنع العملاء، وحتى بدون قواعد الجّدار النّاري السابقة سيكون لدينا الآن إطار عمل مُمكّن يسمح لـ fail2ban بحظر العملاء انتقائيًّا عن طريق إضافتهم إلى سلاسل chains مبنيّة لهذا الغرض: sudo iptables -S-P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N fail2ban-apache -N fail2ban-apache-badbots -N fail2ban-apache-nohome -N fail2ban-apache-noscript -N fail2ban-apache-overflows -N fail2ban-php-url-fopen -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-nohome -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-badbots -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-php-url-fopen -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-overflows -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-noscript -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A fail2ban-apache -j RETURN -A fail2ban-apache-badbots -j RETURN -A fail2ban-apache-nohome -j RETURN -A fail2ban-apache-noscript -j RETURN -A fail2ban-apache-overflows -j RETURN -A fail2ban-php-url-fopen -j RETURN -A fail2ban-ssh -j RETURNوإن أردنا رؤية تفاصيل حظر مُطبَّق من قبل أي jail فمن الأسهل ربّما استخدام الأمر fail2ban-client مرة أخرى: sudo fail2ban-client status apacheStatus for the jail: apache |- filter | |- File list: /var/log/apache2/error.log | |- Currently failed: 0 | `- Total failed: 0 `- action |- Currently banned: 0 | `- IP list: `- Total banned: 0اختبار سياسات Fail2Banمن الهام اختبار سياسات fail2ban لكي نتأكّد من أنها تقوم بحظر نقل البيانات كما هو متوقّع، على سبيل المثال نستطيع إعطاء بيانات خاطئة في مُحث prompt استيثاق Apache عدّة مرات، وبعد أن نتجاوز الحدّ ينبغي أن يتم حظرنا وألا نكون قادرين على الوصول للموقع، وإن قمنا بإعداد تنبيهات البريد الإلكتروني فيجب أن نرى رسائل حول الحظر في البريد الإلكتروني الذي قمنا باختياره لاستقبال التّنبيهات. عندما ننظر إلى الحالة باستخدام الأمر fail2ban-client سنشاهد أنّ عنوان IP الخاص بنا يتم حظره من الموقع: sudo fail2ban-client status apacheStatus for the jail: apache |- filter | |- File list: /var/log/apache2/error.log | |- Currently failed: 0 | `- Total failed: 12 `- action |- Currently banned: 1 | `- IP list: 111.111.111.111 `- Total banned: 1وعندما نكون مقتنعين بأنّ قواعدنا تعمل بشكل صحيح نستطيع فك الحظر يدويًّا عن عنوان IP الخاص بنا عن طريق الأمر fail2ban-client بكتابة ما يلي: sudo fail2ban-client set apache unbanip 111.111.111.111ينبغي أن نكون الآن قادرين على محاولة الاستيثاق مرة أخرى. الخاتمةإنّ إعداد fail2ban لحماية خادوم Apache لدينا هو عمليّة سهلة إلى حدٍّ ما في أبسط الحالات، توفّر fail2ban على أيّة حال قدرًا كبيرًا من المرونة لبناء سياسات تُلائِم احتياجاتنا الأمنيّة، وبإلقاء نظرة على المتغيّرات والأنماط داخل الملف etc/fail2ban/jail.local/ والملفات التي يعتمد عليها داخل الدّليل etc/fail2ban/filter.d/ والدّليل etc/fail2ban/action.d/ نجد العديد من الأجزاء التي يمكننا تطويعها tweak وتغييرها لكي تلبّي احتياجاتنا، إنّ تعلّم أساسيّات كيفيّة حماية خادومنا باستخدام fail2ban يزوّدنا بقدرٍ كبير من الأمان وبأقل جهد. إن كنت ترغب في تعلّم المزيد حول fail2ban قم بزيارة الروابط التالية: كيف تعمل Fail2Ban لحماية الخدمات على خادوم لينِكسكيفيّة حماية SSH باستخدام Fail2Ban على Ubuntu 14.04كيفيّة حماية خادوم Nginx باستخدام Fail2Banعلى Ubuntu 14.04ترجمة -وبتصرّف- للمقال How To Protect an Apache Server with Fail2Ban on Ubuntu 14.04 لصاحبه Justin Ellingwood.

TLS، أو حماية طبقة النقل (Transport Layer Security)، وسلفها SSL أو طبقة الحِزَم الآمنة (Secure Sockets Layer) هما عبارة عن بروتوكولات آمنة يتم إنشاؤها بهدف توجيه تدفّق البيانات العادية (traffic) ضمن طريق مشفّر وآمن أثناء تنقّلها. تسمح هذه البروتوكولات للتدفّق بأن يتمّ إرساله بشكل آمن بين جهات بعيدة عن بعضها البعض دون وجود إمكانية لاعتراض تدفّق البيانات بينها وقراءتها بواسطة شخص ما في المنتصف. لها أيضًا دور فعّال في التحقق من هوّية النطاقات والخواديم الموجودة على الإنترنت عبر استخدامها كأداة للتحقق من هوية تلك الخواديم والنطاقات عبر جهة معيّنة تقوم بإصدار تلك الشهادات. في هذا الدرس، سنشرح كيفيّة إنشاء شهادة SSL موقّعة ذاتيًا لخادوم Apache على Ubuntu 14.04، والذي سيسمح لك بأن تقوم بتشفير التدفّق القادم إلى خادومك. صحيح أنّ هذا لن يوفّر لك ميّزة الاستفادة من استيثاق جهة ما من جهات الطرف الثالث (third-parties) لهويّة خادومك، إلّا أنّه يحقق هدف أولئك الذين يريدون نقل المعلومات بأمان وببساطة. المتطلباتقبل أن تبدأ، يجب أن تهتم ببعض الإعدادات بالطبع. سنستخدم مستخدمًا غير مستخدم الجذر مع صلاحيات sudo في هذا الدرس. يمكنك إعداد واحد عبر اتباع الخطوات المذكورة في درسنا حول إعداد خادوم أوبونتو 14.04 الابتدائي. ستحتاج أيضًا إلى تثبيت خادوم Apache. إذا لم تقم بالفعل بتثبيته وتشغيله فقم بتطبيق الأوامر التالية: sudo apt-get update sudo apt-get install apache2الخطوة الأولى: تفعيل وحدة SSLيأتي دعم SSL افتراضيًا بالواقع مع حزمة Apache على أوبونتو 14.04. نحتاج فقط أن نقوم بتفعيله بكلّ بساطة لكي نستفيد من مميزات SSL على خادومنا. لتفعيله، قم بالأمر التالي: sudo a2enmod sslبعد أن تقوم بتفعيل SSL، سيجب عليك إعادة تشغيل خادوم الويب ليتم تطبيق التغييرات: sudo service apache2 restartبعد هذا، سيكون خادومنا قادرًا على استخدام SSL في حال قمنا بضبطه ليقوم بذلك. الخطوة الثانية: إنشاء شهادة SSL موقعة ذاتيافلنبدأ عبر إنشاء مسار فرعي ضمن مجلّد إعدادات خادوم Apache لنضع ملفّات الشهادة التي سنقوم بإنشائها فيه: sudo mkdir /etc/apache2/sslوالآن وبعد أن قمنا بإنشاء ذلك المسار، يمكننا أن نقوم بإنشاء تلك الملفّات بأمر واحد وهو: sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crtفلنتعرّف على ما يعنيه الأمر السابق: openssl: هذا هو الأمر الأساسي الذي يتم توفيره بواسطة OpenSSL لإنشاء وإدارة الشهادات، المفاتيح وطلبات التوقيع.. إلخ.req: يقوم هذا بتحديد أمرٍ فرعي لإدارة طلب توقيع شهادة X.509 (CSR). X.509 هو معيار بنية تحتية للمفاتيح العمومية تستخدمه SSL لإدارة الشهادات والمفاتيح. بما أننا نريد إنشاء شهادة X.509 جديدة، فإنّ هذا هو ما نريده.x509-: يقوم هذا الخيار بتحديد أننا نريد إنشاء ملفّ شهادة موقّعة ذاتيًا عوضًا عن إنشاء طلب شهادة.nodes-: يخبر هذا الخيار OpenSSL بأننا لا نريد تأمين ملفّ المفتاح الخاصّ بنا بجملة مرور، لأنّ استخدام هذا الخيار سيعترض طريق خادوم أباتشي عندما يتم تشغيله تلقائيًا حيث أنّه يجب علينا إدخال جملة المرور في كلّ مرّة يبدأ فيها الخادوم وفي كلّ مرّة يتم فيها إعادة تشغيله.days 365-: يحدد هذا أنّ الشهادة التي سنقوم بإنشائها صالحة لمدّة 365 يومًا.newkey rsa:2048-: سينشئ هذا الخيار طلب الشهادة ومفتاحًا خاصًّا جديدًا في الوقت ذاته. هذا ضروري جدًا بما أننا لم نقم بإنشاء مفتاحٍ خاصّ مسبقًا. يقوم rsa:2048 بإخبار OpenSSL بأن يقوم بتوليد مفتاح RSA بطول 2048 بت.keyout-: يسمّي هذا المُعامِل الملفّ الناتج لملفّ المفتاح الخاصّ الذي يتم إنشاؤه.out-: يسمّي هذا الخيار ملفّ الشهادة الناتج الذي نقوم بإنشائه.عندما تقوم بضغط زرّ Enter فسيتم سؤالك بضع أسئلة. أهمّ واحدٍ منها هو ذاك السؤال الذي يسألك عن الـ"Common Name". يجب أن تقوم بإدخال اسم نطاقك الذي تريد استخدامه مع الشهادة هنا، أو عنوان الـIP العام إذا كنتَ لا تمتلك نطاقًا بعد. أجوبة الأسئلة ستبدو شيئًا كهذا: Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:New York Locality Name (eg, city) []:New York City Organization Name (eg, company) [Internet Widgits Pty Ltd]:Your Company Organizational Unit Name (eg, section) []:Department of Kittens Common Name (e.g. server FQDN or YOUR name) []:your_domain.com Email Address []:your_email@domain.comسيتم إنشاء الشهادة والمفتاح في مسار etc/apache2/ssl/. الخطوة الثالثة: إعداد Apache ليستخدم SSLالآن وبعد أن أصبح ملفّا الشهادة والمفتاح متوفّرين، يمكننا الآن ضبط خادوم أباتشي ليستخدم هذه الملفّات ضمن ملفّ مستضيف وهمي (virtual host file). يمكنك تعلّم المزيد عن كيفيّة إعداد واحد من موقعنا. عوضًا عن وضع إعداداتنا كلّها في ملفّ 000-default.conf في مجلّد sites-available الفرعي، فسنقوم بوضع هذه الإعدادات في ملفّ default-ssl.conf والذي يحوي إعدادات SSL الافتراضية. افتح الملفّ بصلاحيات الجذر عبر: sudo nano /etc/apache2/sites-available/default-ssl.confيجب أن يبدو الملفّ كالتالي (بعد إزالة التعليقات): <IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> BrowserMatch "MSIE [2-6]" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown </VirtualHost> </IfModule>قد يبدو هذا معقّدًا قليلًا، ولكن لحسن الحظّ فإننا لا نحتاج إلى تعديل معظم الخيارات هنا. نريد فقط إعداد الأمور العادية التي نريدها ضبطها للمستضيف الوهمي (مدير الخادوم، اسم الخادوم، اختصار الخادوم، المسار الجذر.. إلخ) بالإضافة إلى تغيير المكان الذي يبحث فيه أباتشي عن شهادة الـSSL والمفتاح. في النهاية، سيبدو الملفّ كالتالي: <IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin admin@example.com ServerName your_domain.com ServerAlias www.your_domain.com DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/apache2/ssl/apache.crt SSLCertificateKeyFile /etc/apache2/ssl/apache.key <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> BrowserMatch "MSIE [2-6]" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown </VirtualHost> </IfModule>احفظ الملفّ واخرج عندما تنتهي. الخطوة الرابعة: تفعيل شهادة SSL للمستضيف الوهميالآن وبعد أن قمنا بضبط المستضيف الوهمي الذي أعددناه ليستخدم SSL افتراضيًا، يجب عليك أن نقوم بتفعيله. يمكننا القيام بذلك ببساطة عبر تنفيذ: sudo a2ensite default-ssl.confومن ثمّ، سيجب عليك إعادة تشغيل خادوم أباتشي لتحميل ملفّ إعدادات المستضيف الجديد: sudo service apache2 restartيجب أن يتمَّ الآن تفعيل المستضيف الوهمي الجديد الخاصّ بك، والذي سيخدم المحتوى المشفّر باستخدام شهادة SSL التي قمتَ بإنشائها. الخطوة الخامسة: اختبر إعداداتكالآن وبعد أن قمتَ بإعداد كلّ شيء، يمكنك اختبار إعداداتك عبر زيارة اسم النطاق الخاصّ بك أو عنوان الـIP بعد كتابة //:https قبله، كالتالي: https://اسم_النطاق_أو_عنوان_الآي_بيسترى رسالة تنبيه أنّ متصفّحك لم يتمكّن من التحقق من هوية خادومك لأنّه لم يتم توقيع الشهادة الخاصّة به من قبل جهة من الجهات التي يثق بها ذلك المتصفّح. هذه رسالة متوقّعة بمّا أنّ شهادتنا هي شهادة موقّعة ذاتيًا (self-signed). صحيحٌ أّنّه لن يكون من الممكن استخدام شهادتنا للتحقق من هوية خادومنا، إلّا أنّ الخادوم سيزال قادرًا على التواصل المشفّر. بمّا أنّ هذه الرسالة هي رسالة متوقّعة، فيمكنك الضغط على زرّ "المتابعة على كلّ حال" أو "Proceed anyway" أو أيّ خيار مشابه تجده أمامك للمتابعة. سيتم أخذك بعدها إلى قيمة خيار DocumentRoot التي قمتَ بإعدادها مسبقًا في ملفّ إعدادات SSL الخاصّ بالمستضيف الوهمي. الآن هكذا، أصبح تدفّق البيانات الخاصّ بك مشفّرًا. يمكنك التحقق من ذلك عبر الضغط على أيقونة القفل الموجودة في شريط العنوان: يمكنك أن ترى ذلك القسم الأخضر في المنتصف الذي يخبرك أنّ الاتصال مشفّر. الخاتمةيجب أن تمتلك SSL مفعّلةً الآن على خادومك. ستساعدك على تأمين الاتصال بين موقعك وبين الزوّار، ولكنّ المتصفّحات ستقوم بتحذير كلّ مستخدم يزور موقعك بخصوص شهادة خادومك وأنّه غير قادر على التحقق منها. إذا كنتَ تخطط لإطلاق موقع للعموم وتحتاج SSL، فإنّه يجب عليك شراء شهادة SSL من جهة شهادات موثوقة لموقعك. يمكنك قراءة المزيد من الدروس حول كيفية إعداد خادوم أباتشي أو تأمين خادومك. ترجمة -وبتصرف- للمقال: How To Create a SSL Certificate on Apache for Ubuntu 14.04 لصاحبه: Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.

في بعض الأحيان يرغب المؤلفون والمبرمجون في إعادة نشر أو إنتاج عمل يستفيد من مواد أو منتجات أخرى ولكنهم لايعرفون إذا كان هذا الشيء مشروعاً. هناك العديد من الرخص التي تسمح لك باستخدام ونشر وتعديل المنتج بشكل حر، بل وتسمح لك أيضاً بالاستفادة المادية منه. سنشرح اليوم جميع الرخص الحرة واستخداماتها والشروط الخاصة بكل رخصة. أولا تراخيص الملفات الرقميةتراخيص تصلح للصور بأنواعها والكتب والنصوص والتصميمات والوثائق والفيديو والصوت وملفات المالتيميديا بكل أنواعها وغيرها.. تراخيص المشاع الإبداعي Creative Commonsتسمح لك هذه الرخصة بتوزيع وتعديل وإعادة نشر المواد أو إنتاج أعمال مشتقة منه بشكل حر، ولكنها تحتفظ للمؤلف بحقه الأدبي فقط (أي في حالة توزيعه كما هو لا يمكنك أن تنسب العمل لنفسك أو لشخص آخر)، تحتوي هذه الرخصة على 6 أنواع و3 فقط منها يصلح للاستخدام التجاري وهي: نسب المصنف (CC-BY) تشترط: ذكر اسم المؤلف ونسب العمل إليه – لا قيود أخرى.نسب المصنف – الترخيص بالمثل (CC-BY-SA) تشترط: ذكر اسم المؤلف ونسب العمل إليه – أي أعمال مشتقة يجب أن تكون تحت المشاع الإبداعي أيضا بنفس الترخيص – لا قيود أخرىنسب المصنف – بلااشتقاق (CC-BY-ND) تشترط: ذكر اسم المؤلف ولكن لا يسمح لك بإنتاج أعمال مشتقة منه (يمكنه توزيعه أو بيعه كما هو بدون تغيير).الملكية العامة Public domainالملكية العامة تعني أن سقوط الحقوق الفكرية وتصبح هذه المواد حرة بشكل كامل ويحق لك استخدامها بلا قيود. تصبح المواد ملكية عامة في حالتين: مواد انتهت حقوق الملكية لها نظراً لسقوطها بالتقادم حسب القانون المنظم لكل دولة، ولكن بشكل عام أغلب المواد تكون في الملكية العامة إذا مر على نشرها 70 عام ومر على وفاة مؤلفها 50 عام، مثال: الكتب التراثية القديمة أو اللوحات والأعمال الفنية التي مضى عليها 100 عام واكثر وغيرها.مواد قام مؤلفها بالتنازل عنها للملكية العامة وصرح بذلك، ومن أحد الأمثلة على ذلك: الصور والمنشورات الصادرة عن الحكومة الأمريكية ووكالة ناسا، وغيرها.هناك أيضا العديد من المؤلفين لا يستخدمون التراخيص السابقة وإنما قد تتخذ أشكال مشابهة لها، مثل أن يصرحوا بالاستخدام التجاري فقط أو يسمحوا بالتعديل والاستخدام التجاري معا، أهم شرط يجب ان تبحث عنه دائما هو إمكانية الاستغلال التجاري أم لا، فإذا لم يسمح لك بذلك بشكل صريح فلا يمكنك القيام ببيعه كمنتج لك. ثانيا تراخيص البرمجيات بشتى أنواعهاوتعرف عند الكثيرين بـ”رخص البرمجيات الحرة”: 1. ترخيص Apacheتسمح لك باستخدام البرمجة بشكل حر من: تعديل – إضافة – إعادة نشر- منح ترخيص جديد لها، ولكن تشترط: أن يتم ذكر اسم المؤلف داخل الملفات النصية للبرمجة documentation، ولا يسمح الترخيص لك باستغلال العلامة التجارية للمنشأ. وله عدة إصدارات ولكن جميعها يسمح لك بالاستغلال التجاري. 2. ترخيص GPL وهو اختصار GNU General Public Licenseيعتبر أشهر أنواع التراخيص البرمجية وأكثرها انتشاراً، وهو مشابهة لترخيص اباتشي السابق ولكن يختلف عنه في أنه يطبق فقط علي البرمجيات ذات المصدر المفتوح ويجب أن تستخدم معها المصادر المفتوحة فقط ويشترط أن تقوم بالإشارة إلى التغييرات التي قمت بها علي الكود الأصلي، ولا يسمح لك بأن تقوم بإصدار تراخيص جديدة بل يجب أن يظل بنفس الترخيص حتى مع الأعمال المشتقة، وهذا الترخيص له 3 إصدارات ولكن جميعها يسمح لك بالاستخدام التجاري. 3. ترخيص LGPL وهو اختصار لـ GNU Lesser General Public Licenseهو ترخيص مشابه للـ GPL تماما ولكن الاختلاف البسيط هو أنه يسمح لك بأن تستخدم مكتبات وأدوات خارجية قد تكون مغلقة المصدر (وليس كلها مفتوحة المصدر كما تشترط GPL) وبالتالي لا تجبرك على أن تبقي مصدر البرنامج مفتوحاً. 4. ترخيص MITوهو ترخيص تم إنشاؤه بواسطة معهد ماساتشوستس للتقنية ويعتبر مشابه للرخص السابقة من حيث التعديل والتوزيع، وتتيح لك هذه الرخصة استخدام المصدر في البرامج التجارية والإبقاء على شفرتك الخاصة مغلقة المصدر ولكل يجب أن ترفق نسخة من الملفات التي استخدمتها ضمن برنامجك وهذه الملفات ستظل تحت رخصة MIT. 5. ترخيص MPL وهو اختصار لـ Mozilla Public Licenseوهو ترخيص من إنشاء شركة موزيلا وهو مشابه لترخيص GPL ولكن يشترط فقط أن جميع الأعمال المشتقة يجب أن تبقى مفتوحة المصدر حتى ولو كانت تجارية ولكنها لاتعطي المستخدم أي حق في استخدام الشفرة دون إذن المالك. 6. ترخيص BSDويشترط فقط أن تقوم بالإشارة إلى أنك استخدمت الكود المصدري تحت هذا الترخيص ولا يلزمك بأن يكون المصدر مفتوحا أو مغلقا بل يكون حسب رغبتك. وهناك أيضا بعض التراخيص الأخرى ولكننا قمنا باستعراض اشهرها وأكثرها استخداما، وعلى أي حال يبقى عليك في النهاية أن تطلع جيدا على ترخيص أي مواد أو برامج قد تقوم باستخدامها وإعادة بيعها حتى تضمن أنك تقدم محتوى سليما وصحيحا ولا يحتوي على أي أخطاء أو انتهاكات قد تسبب لك أي مشاكل لاحقا.

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

لِمَاذا قد تودُّ تشغيل Nginx و Apache معًافي الواقع يعتبر كلٌّ من nginx و apache عبارة عن خواديم ويب فعّالة للعمل. حاليًّا يحتل Apache المرتبة الأولى في مجال إدارة الخواديم منذ إطلاقه للعموم في 2006، nginx يصعد بقوة في شتّى أرجاء العالم وهو الآن يحتل المرتبة الثانية في خواديم الويب التي تدير المواقع النشطة. الأسباب وراء شعبية كلّ خادوم واضحة: قوة apache وسرعة nginx المعروفتان لدى الجميع. وعلى كلّ حال، فإن كلًّا من الخادومين يمتلكان نقاط ضعف – apache يستهلك الذاكرة بشراهة، بينما nginx -الذي يؤدي عملًا ممتازًا مع الملفات الثابتة(static files)- يحتاج مساعدة php-fpm أو وحدات مشابهة للتعامل مع المحتوى الديناميكي. على كلّ حال، يمكن لأي شخص أن يدمج الخادومين للحصول على فعالية ممتازة، مع استخدام nginx كخادوم ويب للملفات الثابتة بالواجهة (front-end) و apache ليعالج العمليات بالخلفية (back-end). التثبيتلتطبيق الخطوات الموجودة في هذا الدّرس ستحتاج إلى امتلاك صلاحيات المستخدم الجذر root على خادومك الافتراضي الخاص. لإنشاء مستخدم يمتلك صلاحيات الجذر، تابع الخطوتيّن الثالثة والرابعة من دليل تثبيت خادوم أوبونتو الشامل. تثبيت nginxلكي نبدأ العمل، سنحتاج إلى تثبيت وإعداد nginx الذي سيخدم واجهة موقعنا. يمكن تثبيته باستخدام apt-get عبر الأمر التالي: sudo apt-get install nginx بمجرد أن يتم التثبيت، يمكنك أن تبدأ بإعداد المضيف الوهمي (virtual host) لكي يتم تشغيله بواجهة الموقع. هناك بضع تغييرات إضافية علينا عملها في الإعدادات. إعداد nginxافتح إعدادات nginx عن طريق الأمر: sudo nano /etc/nginx/sites-available/exampleالإعدادات التالية ستسمح لك باستخدام nginx كخادوم لواجهة الموقع. هذه الإعدادات مشابهة للإعدادات الافتراضية، تفاصيلها تجدها تحتها. server { listen 80; root /var/www/; index index.php index.html index.htm; server_name example.com; location / { try_files $uri $uri/ /index.php; } location ~ \.php$ { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header Host $host; proxy_pass http://127.0.0.1:8080; } location ~ /\.ht { deny all; } }هذه هي التغييرات التي تم عملها على الإعدادات: مسار الجذر تم تغييره إلى مسار الويب الحالي. ملف index.php تم إضافته إلى سطر الفهرس. دالة try_files ستحاول القيام بتخديم الزوار مهما كانت الصفحات التي يطلبونها. إذا كان nginx غير قادرٍ على فعل ذلك، حينها يتم إرسال الملف إلى الوسيط (proxy). دالة proxy_pass تسمح لـ nginx أن يتعرف على مسار الخادوم الوسيط. "location ~ /\.ht {" تمنع الموقع من الوصول إلى جميع ملفات .htaccess إذا كان مسار الجذر الخاص بـ Apache يتعارض مع ذاك الخاص بـnginx. هذه الإعدادات تقوم بإعداد نظامٍ صغير حيث يتم توجيه جميع الملفات التي نهايتها .php إلى خادوم apache ليعالجها بالخلفية والذي سيعمل على المنفذ 8080. لتفعيل المضيف الوهمي: sudo ln -s /etc/nginx/sites-available/example /etc/nginx/sites-enabled/exampleبالإضافة إلى ذلك، علينا حذف إعداد nginx الافتراضي: sudo rm /etc/nginx/sites-enabled/defaultالخطوة التالية ستكون تثبيت وإعداد apache. تثبيت Apacheبعد أنّ انتهينا من nginx، حان الوقت لتثبيت واجهة موقعنا الخلفية، apache: sudo apt-get install apache2بما أنه لم يتم تشغيل nginx بعد، فإنّ Apache سيعمل المنفذ 80. إعداد Apacheسنحتاج إلى إعداد apache لجعله يدير الواجهة الخلفية لموقعنا، والذي كما قلنا سابقًا، سيعمل على المنفذ 8080. افتح ملف منافذ apache للبدأ في إعداده ليستخدم المنفذ الصحيح عبر الأمر: sudo nano /etc/apache2/ports.confابحث وغيّر السطور التّالية لجعل apache يعمل على المنفذ 8080 والقابل للوصول من المضيف المحلي (localhost) فقط: NameVirtualHost 127.0.0.1:8080 Listen 127.0.0.1:8080احفظ الملف واخرج. بعد ذلك قمّ بإنشاء ملف مضيف وهمي عبر نسخ تخطيط الملف من ملف apache الافتراضي عبر الأمر: sudo cp /etc/apache2/sites-available/default /etc/apache2/sites-available/example sudo nano /etc/apache2/sites-available/exampleالمشكلة الرئيسية التي يجب حلّها هنا هي أنه يجب أن يتم إعادة ضبط المضيف الوهمي مُجدّدًا لكي يعمل على المنفذ 8080 (عوضًا عن المنفذ الافتراضي الذي هو 80 والذي يعمل عليه nginx). يجب أن يبدو السطر المطلوب هكذا: <VirtualHost 127.0.0.1:8080>تأكّد من أن مسار الجذر صحيح. احفظ الملف واخرج منه وقم بتفعيل المضيف الوهمي: sudo a2ensite exampleقبل البدء باختبار الأشياء، نحتاج إلى دعم apache بملحق php. ثبّته عبر الأمر: sudo apt-get install php5قم بإعادة تشغيل كلٍ من الخادومين للتأكد من عمل التغييرات: sudo service apache2 restart sudo service nginx restartإنهاء العمليّةلقد قمنا بإعداد خادومنا الشخصي الوهمي الخاص (VPS) ليتم تشغيل nginx في واجهة موقعنا وapache ليعالج الطلبات المتعلقة بـ php في الخلفية. الذهاب إلى نطاقنا الرئيسي (domain) الآن سيأخذنا إلى الصفحة الافتراضية لموقعنا. يمكننا التحقق مما إذا كان يتم توجيه المعلومات إلى apache عبر تشغيل سكربت PHP شائع الاستخدام. اذهب وأنشء ملف php.info عبر: sudo nano /var/www/info.phpوالصق الشفرة التالية داخله: <? phpinfo( ); ?>احفظ الملف واخرج. زيارة domain/info.php الخاص بك يجب أن يعرض لك شاشة معلومات php، وسيكون بمقدورك رؤية أنه قد تم معالجة الطلب بواسطة apache أخيرًا، يمكنك رؤية أيٍّ من المنافذ مفتوح وأيّ التطبيقات التي تعمل على كلّ واحدٍ منها عبر كتابة هذا الأمر: sudo netstat -pluntترجمة -وبتصرّف- للمقال How To Configure Nginx as a Reverse Proxy for Apache لصاحبته Etel Sverdlov