نشرح طريقة تثبيت وإعداد خادم Apache أباتشي على توزيعة أوبنتو، وسنستعمله لتخديم صفحات HTML الخاصة بنا.

لتثبيت خادم Nginx راجع فيديو تثبيت وضبط خادم Nginx في أكاديمية حسوب.

قسم خوادم الويب في أكاديمية حسوب غني بالمقالات المفيدة للتعامل معها.

الوسيط العكسي عبارة عن نوع من الخواديم الوسيطة Proxy servers تستقبل طلبات HTTP(S) وتوزّعها بصورة شفّافة على خادوم خلفيّ Backend server واحد أو أكثر. الوسيط العكسي مُفيد لأنّ مُعظم تطبيقات الويب في أيّامنا هذه تستعمل خواديم لم تكن قد صُمّمت لأخذ الطّلبات مُباشرة من المُستخدم وفي العادة لا تدعم إلّا ميزات HTTP بدائيّة.

يُمكنك استخدام وسيط عكسيّ لتجنّب وصول المستخدم إلى الخواديم الخلفيّة مُباشرة. يُمكن استخدامها كذلك لتوزيع الحمل Load balancing من الطّلبات على عدّة خواديم، ما يُحسّن الأداء ويُوفّر حماية من تعطّل التّطبيق. يُمكها كذلك أن تمنحك ميزات لا تمنحها خواديم التّطبيقات مثل التّخبئة Caching، ضغط الملفّات Compression، وحتى تشفير SSL.

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

مُلاحظة: أبدِل your_server_ip في عناوين URL التي تجدها في هذا الدّرس بعنوان IP الخاصّ بخادومك.

المُتطلّبات

لاتّباع هذا الدّرس، ستحتاج إلى:

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

• Apache 2 مُنصّب على خادومك باتّباع الخطوة الأولى من هذا الدّرس.

الخطوة الأولى – تفعيل وحدات Apache اللازمة

يمتلك Apache الكثير من الوحدات المبنيّة مُسبقا لكنّها لا تكون مُفعّلة عند التّنصيب. لذا سيتوجّب علينا تفعيل الوحدات التي سنستخدمها في هذا الدّرس.

الوحدات التّي نحتاج إليها هي mod_proxy وبضعة إضافات خاصّة بها للحصول على بضعة ميزات أخرى لدعم بروتوكولات شبكيّة مُتعدّدة. سنستعمل ما يلي بالتّحديد:

• mod_proxy، الوحدة الرّئيسيّة لإعادة توجيه الطّلبات، وتُمكّننا من تحويل Apache إلى بوابّة لخواديم التّطبيقات المُعتمدة.
• وحدة mod_proxy_http لتمكيننا من توسيط اتّصالات HTTP.
• وحدتا mod_proxy_balancer وmod_lbmethod_byrequests لإضافة ميّزات مُوازنة الحمل على عدّة خواديم.

لتفعيل الوحدات الأربع، نفّذ الأوامر التّاليّة:

sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod proxy_balancer
sudo a2enmod lbmethod_byrequests

لتطبيق التّغييرات، أعد تشغيل Apache:

sudo systemctl restart apache2

يُمكن الآن استخدام Apache ليعمل وسيطًا عكسيًّا لطلبات HTTP. في الخطوة – الاختياريّة - التّاليّة، سننشئ خادومين خلفيّين بسيطين. ما سيُخوّلنا التّحقّق من أنّ الإعدادات تعمل جيّدا، لكن إن كانت لديك تطبيقات تعمل في الواجهة الخلفيّة، يُمكنك تخطي الخطوة التّاليّة والانتقال مُباشرة إلى الخطوة الثّالثة.

الخطوة الثّانيّة – إعداد خواديم خلفيّة Backend Servers للاختبار

إنشاء خواديم خلفيّة بسيطة طريقة سهلة لاختبار ما إذا كانت إعدادات Apache الخاصّة بك تعمل جيّدًا أو لا. في هذه الفقرة، سنعدّ خادومين يجيبان على طلبات HTTP بمقطع نصّي صغير. أحد الخادومين سيُجيب بالمقطع Hello world! والآخر بالمقطع Howdy world!.

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

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

أولا، حدّث قائمة الحزم:

sudo apt-get update

بعدها، نصّب أداة pip لإدارة حزم لغة بايثون:

sudo apt-get -y install python3-pip

استخدام pip لتنصيب أداة Flask:

sudo pip3 install flask

بعد تنصيب المُكوّنات المطلوبة، ابدأ بإنشاء ملفّ جديد ليحتوي على شفرة الخادوم الأول في المُجلّد الشخصي للمستخدم الحاليّ:

nano ~/backend1.py

انسخ ما يلي إلى الملفّ ثمّ احفظه وأغلقه:

from flask import Flask
app = Flask(__name__)

@app.route('/')
def home():
    return 'Hello world!'

السّطران الأول والثّاني عبارة عن تهيئة لإطار العمل Flask. لدينا دالّة واحدة باسم home() تُرجع النّص Hello world!. السّطر @app.route('/') المتواجد فوق الدّالة home() يُخبر Flask بالإجابة على أي طلب يصل إلى العنوان الجذر / بما تُرجعه الدّالّة.
الخادوم الثّاني مُشابه للأول، الاختلاف الوحيد أنّ الجواب مُختلف قليلا. لذا انسخ الملفّ الأول:

cp ~/backend1.py ~/backend2.py

عدّل الملفّ الجديد:

nano ~/backend2.py

عدّل ما تُرجعه الدّالة من Hello world! إلى Howdy world! ثمّ احفظ وأغلق الملفّ.

from flask import Flask
app = Flask(__name__)

@app.route('/')
def home():
    return 'Howdy world!'

استخدم الأمر التّالي لتشغيل الخادوم الأول على المنفذ رقم 8080. سيقوم هذا الأمر بتحويل المخرجات إلى /dev/null كذلك لتفادي مُقاطعة المُخرج للطّرفيّة.

FLASK_APP=~/backend1.py flask run --port=8080 >/dev/null 2>&1 &

في السّطر أعلاه، عرّفنا مُتغيّر البيئة FLASK_APP ثمّ نفّذنا الأمر flask لتشغيل الخادوم في نفس السّطر. مُتغيّرات البيئة طريقة سهلة لتمرير المعلومات إلى العمليّات المبدوءة على الطّرفيّة.

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

استعمل الأمر التّالي لتشغيل الخادوم الثّاني على المنفذ 8081 بطريقة مُشابهة لما سبق. لاحظ بأنّ قيمة مُتغيّر البيئة FLASK_APP مُختلفة في هذه الحالة:

FLASK_APP=~/backend2.py flask run --port=8081 >/dev/null 2>&1 &

يُمكنك اختبار عمل الخادومين باستخدام أداة curl.

اختبار الخادوم الأول:

curl http://127.0.0.1:8080/

يجب على المُخرج أن يساوي Hello world!. الخادوم الثّاني:

curl http://127.0.0.1:8081/

يجب على المُخرج أن يكون Howdy world!.

مُلاحظة: لإغلاق كلا الخادومين بعد أن تنتهي من استخدامهما، عند إنهائك لهذا الدّرس مثلا، فيُمكنك تنفيذ الأمر killall flask.

في الخطوة التّاليّة، سنعدّل ملفّ إعدادات Apache لتمكيننا من استخدامه وسيطًا عكسيًّا.

الخطوة الثّالثة – تعديل الإعدادات المبدئيّة لجعل Apache يعمل وسيطًا عكسيًّا

سنعدّ في هذه الفقرة مُضيفًا افتراضيًّا Virtual host على Apache للعمل وسيطًا عكسيًّا لخادوم خلفي واحد أو عدّة خواديم موزونة الحمل.

مُلاحظة: سنُطبّق الإعدادات في هذا الدّرس على مُستوى المُضيف الافتراضي. يوجد في الإعداد المبدئي لـApache مُضيف افتراضي واحد مُفعّل. لكنّك تستطيع استعمال جميع أجزاء هذه الإعدادات على أي مُضيف افتراضي آخر.

إن كان خادوم Apache الخاص بك يجيب على طلبات HTTP و HTTPS، فسيتوجّب عليك وضع إعدادات الوسيط العكسي في كلا المُضيفَين الافتراضيّيْن لـHTTP وHTTPS.

افتح ملفّ إعدادات Apache المبدئي باستخدام nano أو أي مُحرّر مُفضّل لديك:

sudo nano /etc/apache2/sites-available/000-default.conf

ستجد داخل هذا الملفّ الجزء <VirtualHost *:80> بدءا من السّطر الأول. يشرح المثال الأول أسفله كيفيّة ضبط هذا الجزء لإعداد وسيط عكسي لخادوم واحد، وفي المثال الثّاني سنضبط وسيطا عكسيّا يوازن الحمل على أكثر من خادوم.

المثال الأول – إعداد وسيط عكسي لخادوم خلفيّ واحد

أبدل جميع المُحتويات داخل الوسم VirtualHost بما يلي ليصير ملفّ الإعدادات الخاصّ بك كما يلي:

<VirtualHost *:80>
    ProxyPreserveHost On

    ProxyPass / http://127.0.0.1:8080/
    ProxyPassReverse / http://127.0.0.1:8080/
</VirtualHost>

إن تابعت الأمثلة في الخطوة الثّانيّة أعلاه، فاستخدم العنوان 127.0.0.1:8080 كما هو مكتوب أعلاه. إن كان لديك تطبيق ويب خاصّ بك، فاستعمل عنوان التّطبيق عوضا عمّا فعلنا.

لدينا ثلاثة تعليمات في هذا الإعداد:

• ProxyPreserveHost مسؤولة عن جعل Apache يُمرّر الترويسة Header المسمَّاة Host الأصليّة إلى الخادوم الخلفيّ. هذا الأمر مُفيد لأنّه يُخبر الخادوم بالعنوان المُستخدَم للوصول إلى التّطبيق.
• ProxyPass عبارة عن تعليمة الإعداد الرّئيسيّة للوسيط. في هذه الحالة، نحدّد كلّ شيء تحت عنوان URL الجذر / ليُربط مع الخادوم الخلفيّ المرتبط بالعنوان المُعطى. على سبيل المثال، إن استقبل Apache طلبا للموجّه /example، فسيقوم بالاتّصال بالعنوان http://your_backend_server/example وإرجاع الإجابة إلى العميل.
• ينبغي على ProxyPassReverse أن يحمل نفس الإعداد الذي يحمله ProxyPass. ويُخبر Apache بتعديل ترويسة الجواب من طرف الخادوم الخلفيّ. بهذه الطّريقة سنتأكّد من إعادة توجيه العميل إلى عنوان الوسيط وليس الخادوم الخلفيّ في حالة وُجدت ترويسة إعادة توجيه في جواب الخادوم لتجنّب أخطاء إعادة التّوجيه.

لتطبيق هذه التّغييرات، أعد تشغيل Apache:

sudo systemctl restart apache2

إن حاولت الآن الوصول إلى http://your_server_ip في مُتصفّح ويب، ستجد جواب الخادوم الخلفيّ عوضا عن رسالة ترحيب Apache المألوفة. إن تابعت الخطوة الثّانيّة، فهذا يعني بأنّ النّتيجة ستكون Hello world!.

المثال الثّاني – موازنة الحمل على عدّة خواديم خلفيّة

إن كان لديك أكثر من خادوم خلفيّ واحد، فاستخدام ميزة مُوازنة الحمل في mod_proxy طريقة جيّدة لتوزيع الطّلبات على الخواديم.

استبدل جميع مُحتويات الجزء VirtualHost بما يلي ليبدو ملفّ الإعدادات كما يلي:

<VirtualHost *:80>
<Proxy balancer://mycluster>
    BalancerMember http://127.0.0.1:8080
    BalancerMember http://127.0.0.1:8081
</Proxy>

    ProxyPreserveHost On

    ProxyPass / balancer://mycluster/
    ProxyPassReverse / balancer://mycluster/
</VirtualHost>

الإعدادات هنا مُشابهة لما سبق، لكن عوضا عن تخصيص خادوم واحد مُباشرة، استعملنا وسم Proxy إضافيّا لتعيين خواديم مُتعدّدة.سمّينا الوسم بـbalancer://mycluster (يُمكنك تغيير الاسم إن شئت) ليحتوي على أكثر من تعليمة BalancerMember، والذي يُحدّد عناوين الخواديم الخلفيّة. هكذا تستعمل التّعليمتان ProxyPass وProxyPassReverse مجموعة موازنة الحمل المُسمّاة mycluster عوضا عن خادم مُحدّد.

إن تابعت الخطوة الثّانيّة من هذا الدّرس، فاستعمل العنوانين 127.0.0.1:8080 و127.0.0.1:8081 للتّعليمة BalancerMember كما هو مُبيّن في الإعدادات أعلاه. أمّا إن كانت لديك خواديم خاصّة بك فاستعمل عناوينها.

لتطبيق هذه التّغييرات، أعد تشغيل Apache:

sudo systemctl restart apache2

إن حاولت الآن الوصول إلى http://your_server_ip في مُتصفّح ويب، ستجد جواب الخواديم الخلفيّة عوضا عن رسالة ترحيب Apache المألوفة. إن تابعت الخطوة الثّانيّة، فعند إعادة تحميل الصّفحة عدّة مرّات، ستُلاحظ بأنّ النّتيجة ستكون إمّا Hello world! أو Howdy world!، ما يعني بأنّ الوسيط العكسي يعمل على مُوازنة الحمل بين الخادومين.

خاتمة

لديك الآن معرفة بكيفيّة إعداد خادوم Apache ليعمل وسيطًا عكسيًّا لخادوم تطبيق أو أكثر. يُمكن استعمال mod_proxy لضبط وسيط عكسي لخواديم تطبيقات مكتوبة بلغات مثل Python مع Django أو Ruby مع Ruby on Rails.
يُمكن كذلك استخدامها لموازنة الحمل على عدّة خواديم للتّطبيقات التي تستقبل العديد من الزّوار، بالإضافة إلى إمكانيّة استخدامه لتوفير حماية SSL للخواديم الخلفيّة التي لا تدعم SSL.

رغم أنّ mod_proxy وmod_proxy_http أكثر تركيب يتمّ استخدامه، إلّا أنّ هناك العديد من الوحدات الأخرى التّي تدعم بروتوكولات اتّصال أخرى. إليك بعضا من الوحدات الشّهيرة التي لم نستخدمها في هذا الدّرس:

• mod_proxy_ftp لبروتوكول FTP.
• mod_proxy_connect لإعداد أنفاق SSL.
• mod_proxy_ajp لبروتوكول AJP (Apache JServ Protocol) لخواديم خلفيّة مبنيّة على Tomcat.
• mod_proxy_ftp لمقابس الويب Web sockets.

يُمكنك قراءة التّوثيق الرّسمي للاستزادة حول mod_proxy.

ترجمة – بتصرّف - للمقال How To Use Apache as a Reverse Proxy with mod_proxy on Ubuntu 16.04 لكاتبه Mateusz Papiernik.

تعرفنا في درس سابق على كيفية تفعيل وحدة mod_rewrite وضبطها لإعادة كتابة عناوين URL في خادوم Apache.ا سنعتمد في هذا الشرح على ما تعلمناه سابقًا ونتوسّع - مع مثاليْن عمليّيْن - في شرحٍ بعض من أكثر التّعليمات استخداما في ضبط mod_rewrite.

المثال الأول – تبسيط نصوص الاستعلام Query strings باستخدام RewriteRule

تستعمل تطبيقات الوِب في العادة نصوص الاستعلام التي يُمكن إضافتها إلى عنوان URL باستخدام علامة استفهام (?) بعد العنوان. تُمرَّر المُعاملات المُختلفة باستخدام علامة &. يُمكن استخدام نصوص الاستعلام لتمرير معلومات إضافيّة بين صفحات تطبيق الوِب.

على سبيل المثال، يُمكن لصفحة نتائج بحث مكتوبة بلغة PHP أن تستعمل عنوانا مثل http://example.com/results.php?item=shirt&season=summer. في هذا المثال، هناك مُعاملان إضافيّان، المُعامل item مع القيمة shirt، والمُعامل season ذو القيمة summer. سيستعمل التّطبيق هذه المعلومات لتقديم أكثر نتيجة مناسبة للمُستخدم.

تُكتب قواعد إعادة الكتابة في Apache عادة لتبسيط روابط طويلة مثل التي أعلاه إلى عناوين URL بسيطة سهلة القراءة والفهم. في هذا المثال، نريد تبسيط ما سبق ليكون على شكل http://example.com/shirt/summer. كما تُلاحظ، فالقيمتان shirt و summer لا تزالان مُتواجدتيْن داخل العنوان، لكن دون نصّ استعلام واسم ملفّ PHP.

إليك قاعدة لتحقيق مُرادنا:

RewriteRule ^shirt/summer$ results.php?item=shirt&season=summer [QSA]

المقطع shirt/summer واضح وقد أخبرنا Apache بتوجيه أي طلبات مطابقة إلى العنوان results.php?item=shirt&season=summer.
تُستخدم الخيارات [QSA] عادة في قواعد إعادة الكتابة. وتُخبر Apache بإضافة أي نصّ استعلام إضافي إلى عنوان URL المُقدَّم، لذا لو كتب زائر http://example.com/shirt/summer?page=2 فسيجيب الخادوم بـ results.php?item=shirt&season=summer&page=2. إن لم تُضف هذه الخيارات فسيُتجاهل نصّ الاستعلام الإضافي.

رغم أنّ هذه الطّريقة تُحقّق هدفنا، إلّا أنّنا كتبنا القيمتين بصراحة داخل الملفّ. لذا فالقاعدة لن تعمل لأي قيم أخرى مثل pants وwinter.

لجعل القاعدة عامّة أكثر، يُمكننا استخدام التّعابير النّمطيّة لمُطابقة أجزاء من العنوان الأصلي واستعمالها في مقطع بدل نمطي. بحيث تكون القاعدة المُعدّلة كما يلي:

RewriteRule ^([A-Za-z0-9]+)/(summer|winter|fall|spring) results.php?item=$1&season=$2 [QSA]

التّعبير النمطي الأول داخل القوسين يُطابق أي مقطع نصّ مكوّن من أحرف وأرقام مثل shirt و pants ويحفظ المقطع المُطابق في المُتغيّر $1. التّعبير النمطي الذي يتبعه يُطابق حرفيًّا كلّا من summer، winter، fall و spring، ويحفظ أي مُطابق في المُتغيّر $2.

تُستعمل المقاطع المُطابقة بعدها في عنوان URL النّاتج لتمريرها إلى كل من المُعاملين item وseason عوضا عن كتابة القيمتين على نحو صريح كما فعلنا سابقا.

القاعدة أعلاه ستستبدل على سبيل المثال العنوان http://example.com/pants/summer إلى http://example.com/results.php?item=pants&season=summer. هذا المثال قابل للتماشي مع التّطويرات المُستقبليّة كذلك، بحيث يُمكن إعادة كتابة العناوين لعدّة قيم باستخدام قاعدة واحدة فقط.

المثال الثّاني – إضافة شروط منطقيّة باستخدام RewriteConds

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

RewriteCond TestString Condition [Flags]

• RewriteCond: تعليمة الشرط.
• TestString النّص الذي سيُجرى عليه الاختبار.
• Condition نمط أو شرط للاختبار به.
• Flags عبارة عن مُعاملات إضافيّة يُمكن لها تعديل الشّرط وقواعد التّحويل.

إذا أرجع شرط في RewriteCond القيمة المنطقيّة true (أي أنّ الشرط قد تحقّق)، فستُنفَّذ قاعدة RewriteRule التي تلي الشرط مُباشرة. إن لم يتحقّق الشّرط فتُتجاهل القاعدة. يُمكن استخدام أكثر من شرط. يجب مبدئيًّا على جميع الشّروط أن تتحقّق لتطبيق القاعدة التي تليها.

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

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /

في المثال أعلاه:

• %{REQUEST_FILENAME} يُمثّل النصّ المُختبَر. في هذه الحالة، القيمة ستكون عبارة عن اسم الملفّ الذي طلبه المُستخدم وهو مُتغيّر نظام خاص يتوفّر في كل طلب.
• f- شرط متوفّر مُسبقا في وحدة mod_rewrite للتّحقّق من أنّ الاسم الذي طلبه المُستخدم مُتواجد على القرص وبأنّه ملفّ فعلا. أمّا ! فهي علامة نفي. بجمعهما، فـf-! تتحقّق من أنّ الاسم الذي طلبه الاستعلام غير مُتواجد أو أنّه ليس ملفّا.
• d-! يعمل بطريقة مُشابهة ولكن بالنسبة للمجلّدات، إذ يُساوي القيمة true فقط إن كان الاسم المطلوب غير موجود أو أنّه ليس مجلّدا.

ستُنفَّذ قاعدة RewriteRule الموجودة في السطر الأخير فقط إن تلقى الخادوم طلبا لملفّ أو مُجلّد غير موجود. القاعدة بسيطة وكلّ ما تفعله هو إعادة توجيه الطّلب إلى موجّه الجذر / في الموقع (والذي يكون عادة صفحة رئيسيّة).

خاتمة

mod_rewrite وحدة مُفيدة جدّا في Apache يُمكن استخدامها لتوفير عناوين URL سهلة القراءة. في هذا الدّرس، تعلّمتَ كيفيّة استخدام تعليمة RewriteRule لإعادة توجيه المُستخدمين حتى ولو كانت تتضمّن نصوص استعلام. تعلّمت كذلك كيفيّة إعادة التّوجيه حسب شروط باستعمال التّعليمة RewriteCond.
للتّعرف أكثر على mod_rewrite، ألق نظرة على هذه الصّفحة والتّوثيق الرّسمي لـmod_rewrite من Apache.

ترجمة – بتصرّف - للمقال How To Rewrite URLs with mod_rewrite for Apache on Ubuntu 16.04 لكاتبه Mateusz Papiernik.

مُقدّمة

سنتعرّف في هذا الدّرس على كيفيّة إعادة كتابة عناوين URL باستخدام وحدة mod_rewrite الخاصّة بـApache 2. تمنحنا هذه الوحدة حريّة إعادة كتابة روابط URL لتكون أكثر نظافة وتنسيقا عبر ترجمة مسارات قابلة للقراءة إلى استعلامات مُوجّهة لتطبيق الوِب أو إعادة توجيه المُستخدم حسب شروط إضافيّة.

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

المُتطلّبات

لاتّباع هذا الدّرس، ستحتاج إلى:

• خادوم أوبونتو 16.04 مضبوط باتّباع الخطوات الواردة في درس الإعداد الابتدائي لخادوم أوبونتو، وذلك يشمل مُستخدما ذا صلاحيّات sudo مع ضبط مُسبق لتمكينه من تنفيذ مهام إداريّة، غير المستخدم الجذر root، بالإضافة إلى جدار ناري.

• Apache 2 مُنصّب على خادومك باتّباع الخطوة الأولى من درس تثبيت حزم LAMP على أوبونتو.

الخطوة 1 – تفعيل mod_rewrite

أولا، نحتاج إلى تفعيل mod_rewrite. مبدئيًّا، الوحدة متوفّرة لكنّها غير مُفعّلة عند تنصيب Apache 2.

sudo a2enmod rewrite

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

sudo systemctl restart apache2

وحدة mod_rewrite مُفعّلة الآن. سنضبُط في الخطوة التّاليّة ملفّ .htaccess لاستخدامه لتحديد قواعد إعادة الكتابة لإعادات التّوجيه Redirects.

الخطوة 2 – ضبط htaccess.

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

مُلاحظة: يُمكن لأي قواعد تضعها داخل ملفّ .htaccess أن توضع كذلك داخل ملفّات إعدادات الخادوم، في الحقيقة، ينصح التوثيق الرّسمي لـApache ينصح باستعمال ملفات إعدادات الخادوم عوضا عن ملفّ .htaccess لقدرة Apache على مُعالجتها بسرعة أعلى.

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

سنحتاج إلى ضبط وتأمين بعض الإعدادات قبل أن نبدأ.

يمنع Apache مبدئيًّا استخدام ملفّ .htaccess لقواعد إعادة كتابة روابط URL، لذا سيتوجّب عليك أولا تفعيل إمكانيّة استخدام الملفّ. افتح ملفّ إعدادات Apache المبدئية باستخدام nano أو مُحرّرك المفضّل.

sudo nano /etc/apache2/sites-available/000-default.conf

ستجد داخل هذا الملفّ الجزء <VirtualHost *:80> في أول سطر. داخل هذا الجزء، أضف الجزء التّالي مباشرة بعد السطر الذي يبدأ بـDocumentRoot:

    <Directory /var/www/html>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Require all granted
    </Directory>

ليُصبح ملفّ الإعدادات كما يلي (حذفنا - للاختصار - التعليقات، وهي الأسطر التي تبدأ بـ# من المُقتَطع أدناه). تأكّد من أنّ الإزاحة صحيحة:

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        <Directory /var/www/html>
            Options Indexes FollowSymLinks MultiViews
            AllowOverride All
            Require all granted
        </Directory>


        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

احفظ وأغلق الملفّ.

ملحوظة: يفترض هذا الدليل وجودَ موقع واحد على خادومك، في هذه الحالة يكفي التعديل على ملف المضيف الافتراضي Virtual host المبدئي (000-default.conf) بالطريقة أعلاه لتفعيل إمكانيّة إعادة التوجيه. إن كان لديك أكثر من موقع فستحتاج لإجراء التعديل أعلاه على ملفّ المضيف الافتراضي الخاصّ بالموقع الذي تريد. توجد ملفات المضيفات الافتراضية على المسار /etc/apache2/sites-available/.

لتطبيق التّغييرات، أعد تشغيل خادوم Apache:

sudo systemctl restart apache2

الآن، أنشئ ملفّ .htaccess داخل مجلّد الوب الجذر:

sudo nano /var/www/html/.htaccess

أضف السّطر التّالي إلى أعلى الملفّ لتفعيل مُحرّك إعادة الكتابة Rewrite engine:

RewriteEngine on

احفظ وأغلق الملفّ.

يُمكنك الآن استعمال الملفّ .htaccess للتّحكم بقواعد المُوجّهات في تطبيق الوِب الخاصّ بك.

الخطوة 3 – ضبط إعادات كتابة روابط URL

سنعدّ في هذه الفقرة إعادة كتابة بسيطة لرابط URL، بحيث نستطيع تحويل عناوين URL جميلة إلى مسارات يُمكن للشفرة فهمها. سنسمح بالخصوص للمُستخدمين بالوصول إلى العنوان http://your_server_ip/about.

لنبدأ بإنشاء ملفّ باسم about.php داخل مُجلّد الوب:

sudo nano /var/www/html/about.php

انسخ شفرة HTML التّاليّة إلى الملفّ واحفظه ثمّ أغلقه:

<html>
    <head>
        <title>About Us</title>
    </head>
    <body>
        <h1>About Us</h1>
    </body>
</html>

ملحوظة: تأكّد من أن خادوم الوِب لديه صلاحيات الوصول إلى الملف الذي أنشأته للتو. مثلا، بإعطاء الأذون 755على مجلد الوِب:

sudo chmod -R 755 /var/www

يُمكنك الوصول إلى هذه الصّفحة على العنوان http://your_server_ip/about.html، لكن لو حاولت الوصول إلى العنوان http://your_server_ip/about، فستُلاحظ خطأ 404 Not Found، إن أردت تمكين مُستخدميك من استعمال هذا العنوان عوضا عن العنوان السّابق (أي دون الجزء .html) فقواعد إعادة الكتابة كفيلة بتوفير هذه الوظيفة.

تتّبع جميع قواعد الكتابة التّنسيق التّالي:

RewriteRule pattern substitution [flags]

بحيثُ:

• RewriteRule يُحدّد التّعليمة.
• pattern تعبير نمطي Regular Expression يُحدّد عنوان URL المرغوب به، هذا هو ما سيكتبه المُستخدم في شريط عنوان URL.
• substitution: البدل، وهو مسار عنوان URL الأصلي، (مسار الملفّ الذي يقوم Apache بتقديمه).
• flags عبارة عن مُعاملات اختياريّة لتعديل آليّة عمل القاعدة.
  افتح ملفّ .htaccess:

sudo nano /var/www/html/.htaccess

بعد السّطر الأول، أضف السّطر الثّاني ممّا يلي:

RewriteEngine on
RewriteRule ^about$ about.html [NC]

في هذه الحالة، المقطع ^about$ هو التّعبير النّمطي، about.html يُعبّر عن البدل، و [NC] هي المُعاملات. استخدمنا في هذا المثال عدّة محارف تحمل معان خاصّة:

• ^ يُشير إلى بداية العنوان بعد المقطع your_server_ip/.
• $ يُشير إلى نهاية عنوان URL.
• about المقطع الذي يجب على التّعبير النّمطي مُطابقته.
• about.html اسم الملفّ الأصلي الذي يصل إليه المُستخدم
• [NC] خيار لجعل القاعدة تتجاهل حالة الأحرف Case insensitive.

ينبغي الآن أن تستطيع الوصول إلى العنوان http://your_server_ip/about في مُتصّفح الويب الخاصّ بك. في الحقيقة، بالقاعدة التي كتبناها أعلاه، فالعناوين التّاليّة ستؤدّي جميعها إلى الملفّ about.html:

• http://your_server_ip/about، بسبب تعريفنا للقاعدة.
• http://your_server_ip/About، لأنّ القاعدة تتجاهل حالة الأحرف.
• http://your_server_ip/about.html، لأنّ اسم الملفّ الأصلي سيعمل دائما.

العناوين التّاليّة لن تعمل:

• http://your_server_ip/about/، لأنّ القاعدة تنصّ بوضوح بأنّه لا يجوز على أي شيء أن يكون بعد about باستخدام المحرف $.
• http://your_server_ip/contact، لأنّ العنوان لن يُطابق المقطع about.

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

ترجمة – بتصرّف - للمقال How To Rewrite URLs with mod_rewrite for Apache on Ubuntu 16.04 لكاتبه Mateusz Papiernik.

مقدمة

يُستخدم ميثاق (بروتوكول) الوِب TLS (اختصار لـ Transport Layer Security، أمان طبقة النقل) وسلفه SSL (اختصار لـ Secure Sockets Layer، طبقة المقابس الآمنة) لتغليف البيانات العاديّة ضمن إطار محميّ وآمن. يمكن للخواديم باستخدام هذه التقنية أن تؤمّن تبادل البيانات بينها وبين العملاء حتى ولو اعتُرِضت طريقُ الرسائل بين الخادوم والعميل. يساعد نظام الشهادات الأمنية Certificates المستخدِمين والزوار في التحقّق من أمان المواقع التي يتّصلون بها.

سنقدّم في هذا الدليل الخطوات اللازمة لإعداد شهادة أمنيّة موقَّعة ذاتيًّا Self-signed certificate لاستخدامها مع خادوم الوِب Apache على أوبونتو 16.04.

ملحوظة: تعمّي الشهادات الموقَّعة ذاتيًّا الاتصالات بين الخادوم والعملاء؛ لكن لن يمكنَ للعملاء استخدامُها للتحقّق من التحقّق من هويّة خادومك تلقائيًّا، إذ أنه لم تُوقّعها سلطة معترف بها. تتضمَّن المتصفّحات مثل فيرفكس وكروم قائمة بالسلطات المعترف بها والمخوَّلة إصدار شهادات TLS.
يُناسب استخدام الشهادات الموقَّعة ذاتيًّا بيئات الاختبار، على الحاسوب الشخصي أو عندما لا يكون لديك نطاق Domain؛ مثلا في واجهات الوِب غير المتاحة للعموم. إن كان لديك نطاق فالأفضل أن تستخدم شهادة أمنية من سطلة معترف بها. يمكنك الحصول على شهادة مجانيّة من Let’s encrypt وإعدادها.

المتطلبات

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

ستحتاج أيضا لتثبيت خادوم الوِب Apache. إن رغبت في تثبيت كامل حزم LAMP (أي لينكس Linux، أباتش Apache، وMySQL وPHP) فالدرس كيف تثبت حزم MySQL ،Apache ،Linux :LAMP و PHP موجود لهذا الغرض؛ أما إن كنت ترغب في تثبيت Apache لوحده فيمكنك الاعتماد على الدرس المُشار إليه مع ترك الخطوات الخاصّة بكلّ من MySQL وPHP.

تأكّد من توفّرك على المتطلّبات ثم نفّذ الخطوات المشروحة أدناه.

الخطوة اﻷولى: إنشاء شهادة SSL

يعمل بروتكول TLS (وسلفه SSL) باستخدام مفتاحيْن للتعميّة واحد عمومي Public وآخر خاصّ (أو سرّي) Private. يُخزَّن المفتاح السّري على الخادوم ولا يجوز أن يطّلع عليه أي عميل فهو خاصّ بالخادوم الذي يستخدمه لتعميّة المحتوى المُرسَل إلى العملاء. يُمكن لأيّ عميل الاطّلاع على شهادة TLS. تحوي هذه الشهادة المفتاح العموميّ الذي يُستخدَم لفكّ التعميّة عن المحتوى القادم من الخادوم.

ملحوظة: رغم أن استخدام البروتكول SSL يقلّ يومًا بعد يوم إلا أن المصطلح “شهادة SSL” لا يزال يُستَخدَم كثيرًا، ويُقصَد به - في الغالب - TLS، الذي هو نسخة محسَّنة من SSL.

تتيح مكتبة OpenSSL (مكتبة برمجيّة توفّر أدوات للتعامل مع شهادات SSL/TLS) إنشاء مفتاح تعميّة موقَّع ذاتيًّا بالأمر التالي:

    sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt

ستُطرَح عليك مجموعة من الأسئلة، ولكن قبل النظر في تلك الأسئلة سنشرح الخيارات المذكورة في الأمر السابق:

• openssl: هذا هو الأمر الأساسي لإنشاء الشهادات، المفاتيح وبقية الملفات وإدارتها في OpenSSL.
• req: يحدّد هذا الأمر الفرعي المعيار X.509 لاستخدامه في البنية التحتيّة التي نريد استخدامها لإدارة المفاتيح العموميّة. يعتمد الميثاقان SSL وTLS المعيار X.509 لإدارة المفاتيح العمومية. نستخدم هذا الأمر الفرعي لطلب إنشاء شهادة تتوافق مع هذا المعيار.
• x.509: يغيّر هذا الخيار طريقة عمل الأمر الفرعي السابق ليخبره أننا في طور إنشاء شهادة موّقَّعة ذاتيًّا بدلا من إرسال طلب لتوقيع شهادة الذي هو السلوك المبدئي للأمر الفرعي.
• nodes: يطلُب هذا الخيار من openssl تجاوز خيار تأمين الشهادة بعبارة سرّ Passphrase. نريد أن يكون Apache قادرا على قراءة الشهادة بدون تدخّل من المستخدم عند بدْء تشغيل الخادوم. يمنع وجود عبارة سرّ Apache من قراءة ملفّ الشهادة وسنحتاج عند وجودها لإدخالها في كلّ مرة نعيد فيها تشغيل الخادوم.
• days 365: يحدّد هذا الخيار مدّة صلاحيّة الشهادة. اخترنا سنة.
• newkey rsa:2048: يخبر هذا الخيار الأمر openssl أننا نريد توليد شهادة ومفتاح جديد في نفس الوقت. بما أننا لم نولّد المفتاح المطلوب لتوقيع الشهادة في خطوة منفصلة فإننا نحتاج لإنشائه مع الشهادة. يحدّد الجزء rsa:2048 نوعيّة المفتاح بـ RSA وطوله بـ 2048 بت.
• keyout: يحدّد المسار الذي نريد حفظ المفتاح الخاصّ فيه.
• out: يحدّد المسار الذي نريد حفظ الشهادة فيه.

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

تتعلّق الأسئلة بمعلومات عامة من قبيل الدولة والمدينة والمؤسّسة والمنظَّمة المُصدِرة للشهادة إضافة إلى معلومات عن الخادوم.

يتعلّق أهمّ الأسئلة المطروحة - السطر Common Name - بالخادوم. يجب أن تجيب باسم النطاق الذي يعمل عليه الخادوم أو - وهو الأكثر شيوعا - عنوان IP العمومي للخادوم.

يبدو المحثّ Prompt على النحو التالي:

Country Name (2 letter code) [AU]:حرفان يمثّلان الدولة
State or Province Name (full name) [Some-State]:اسم المنطقة (المحافظة أو الولاية)
Locality Name (eg, city) []:اسم المدينة
Organization Name (eg, company) [Internet Widgits Pty Ltd]:اسم المنظَّمة أو الشركة
Organizational Unit Name (eg, section) []:اسم الفرع
Common Name (e.g. server FQDN or YOUR name) []:عنوان الخادوم
Email Address []:بريد المسؤول

سيوضع الملفان المنشآن في مجلّدات فرعيّة من المجلّد etc/ ssl/ حسب ماهو محدَّد في الأمر.
سنحتاج أيضًا - ما دمنا نتحدَّث عن OpenSSL - إلى إنشاء مجموعة Diffie-Hellman قويّة لتُستخدَم عندما يُناقش الخادوم طريقة نقل البيانات مع العملاء (خطوة من خطوات عدّة ضمن تقنيّة SSL/TLS لتأمين نقل البيانات). ينشئ اﻷمر التالي المطلوب:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

يمكن أن يستغرق الأمر بضعة دقائق، نحصُل بعدها على مجموعة Diffie-Hellman مناسبة (على المسار etc/ssl/certs/dhparam.pem/) لاستعمالها في إعداداتنا.

الخطوة الثانية: إعداد Apache لاستخدام SSL

أنشأنا في الخطوة السابقة ملفّيْ الشهادة والمفتاح الخاصّ. نحتاج الآن لضبط Apache للاستفادة من هذيْن الملفّيْن.
سنعدّل بضعة إعدادات:

1. سننشئ مقطعا جديدًا في إعدادات Apache لتحديد خيارات إعداد مبدئيّة آمنة لـ SSL.
2. سنعدّل المضيف الافتراضي Virtual host الخاص بـ SSL للإشارة إلى شهادة SSL التي أنشأناها في الخطوة السابقة.
3. سنعدّل المضيف الافتراضي غير المُعمَّى ليعيد توجيه جميع الطلبات إلى المضيف الافتراضي المُعمَّى (الخاص بـ SSL). يُنصَح بهذا الإجراء لجعل جميع الاتصالات القادمة إلى الموقع آمنة (تمرّ عبر شهادة SSL).

يجدر بالإعدادات التي سنحصُل عليها بعد تنفيذ النقاط المُشار إليها أعلاه أن تكون آمنة.

تحديد خيارات إعداد مبدئيّة آمنة في Apache

سننشئ أولا ملفّ إعداد جديدًا في Apache نعرّف فيه بعض إعدادات SSL. سنضبُط Apache للعمل بخوارزميّات تعميّة فعّالة ونفعّل بعض الميزات المتقدّمة لمساعدتنا في إبقاء خادومنا آمنا. سيُمكن لأيّ مضيف افتراضي يفعّل SSL.

أنشئ ملفّ إعداد جديد ضمن المجلَّد etc/apache2/conf-available/ (مجلَّد إعدادات Apache). سنسمّي هذا الملف بـssl-params.conf حتى يكون واضحًا أنه يتعلّق بمعطيات Parameters إعداد SSL.

sudo nano /etc/apache2/conf-available/ssl-params.conf

سنعتمد لضبط إعدادات Apache بطريقة آمنة على توصيّات Remy van Elst من موقع Cipherli.st. جُهِّز هذا الموقع لتوفير إعدادات تعميّة جاهزة للاستعمال في أكثر البرمجيّات شيوعًا على الخواديم.

ملحوظة
توفّر الإعدادات المُقترَحة مبدئيًّا في الموقع أعلاه درجة أمان عاليّة. يمكن أن تأتي هذه الدرجة من الأمان على حساب التوافق مع البرامج العميلة (المتصفّحات أو أنظمة التشغيل القديمة). إن أردت دعم إصدارات قديمة من هذه البرامج فإن الموقع يوفّر إعدادات بديلة للإعدادات المبدئيّة، يمكنك الحصول عليها بالنقر على الرابط “Yes, give me a ciphersuite that works with legacy / old software” وستلاحظ أن الإعدادات تبدّلت.
يعتمد الخيار بين النسخة المبدئية من الإعدادات والنسخة البديلة على نوعيّة العملاء التي تريد دعمها. توفّر النسختان أمانًا جيّدًا.

سننسخ - لأغراض هذا الدرس - الإعدادات المقترحة، مع إجراء تعديليْن عليها.

سنعدّل التعليمة SSLOpenSSLConfCmd DHParameters لتشير إلى ملف Diffie-Hellman الذي أنشأناه في الخطوة الأولى. سنعدّل أيضًا تعليمات الترويسة لتغيير عمل الخاصيّة Strict-Transport-Security وذلك بحذف التعليمة preload. توفّر هذه الخاصيّة أمانًا عاليَّا جدًّا إلا أنها يمكن إن فُعِّلت بدون وعي أو بطريقة غير صحيحة - خصوصًا عند استخدام الميزة preload - أن تؤدّي إلى اختلالات كبيرة في عمل الخادوم. تأكّد عندما تفعِّل هذه الميزة أنك تدرك جيّدًا ما تفعله.

# from https://cipherli.st/
# and https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.html

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
# تعطيل التعليمة preload في الخاصيّة Strict-Transport-Security
# يمكنك إن أردت تفعيل هذه الخاصية وذلك بنزع علامة التعليق # من بداية السطر
#Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
# نفس التعليمة السابقة ولكن دون preload
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
# Requires Apache >= 2.4
SSLCompression off 
SSLSessionTickets Off
SSLUseStapling on 
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
# أضفنا هنا المسار إلى ملفّ Diffie-Hellman
SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem"

احفظ الملفّ ثم أغلقه عندما تكون جاهزا لذلك.

تعديل ملف مضيف SSL الافتراضي المبدئي

ننتقل الآن إلى الملف المبدئي Default لمضيف SSL الافتراضي الموجود على المسار etc/apache2/sites-available/default-ssl.conf/. إن كنت تستخدم مضيفا اقتراضيًّا آخر فأبدله بالمضيف الافتراضي المبدئي في الأمر أدناه.

نأخذ أولًا نسخة احتياطية من الملف:

sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/default-ssl.conf.bak

ثم نفتح ملف المضيف الافتراضي لتحريره:

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

        </VirtualHost>
</IfModule>

سنعدّل قليلا على الملف بإعداد تعليمات بريد مدير الخادوم، عنوان، اسم الخادوم… إلخ. كما سنعدّل تعليمة SSL لتشير إلى مسار ملفّيْ الشهادة والمفاتيح. نختُم بنزع التعليق عن خيار يوفّر الدعم للمتصفّحات القديمة لتفعيله.

يبدو الملف بعد التعديلات كالتالي:

<IfModule mod_ssl.c>
        <VirtualHost _default_:443>
                # بريد مدير الخادوم
                ServerAdmin your_email@example.com
                # نطاق الخادوم أو عنوان IP الخاص به
                ServerName server_domain_or_IP

                DocumentRoot /var/www/html

                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined

                SSLEngine on

                SSLCertificateFile      /etc/ssl/certs/apache-selfsigned.crt
                SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.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

        </VirtualHost>
</IfModule>

احفظ الملف ثم أغلقه.

إعادة توجيه طلبات HTTP (غير المُعمَّاة) إلى HTTPS

يجيب الخادوم بإعداداته الحاليّة على الطلبات الآمنة (HTTPS) وغير الآمنة (HTTP) على حدّ السواء. يُنصَح في أغلب الحالات من أجل أمان أعلى أن تُوجَّه طلبات HTTP تلقائيَّا إلى HTTPS.

نفتح ملف المضيف الافتراضي - أو المضيف الذي تريده - لتحريره:

sudo nano /etc/apache2/sites-available/000-default.conf

كلّ ما نحتاجه هو إضافة تعليمة إعادة إعادة التوجيه Redirect داخل إعداد الوسم VirtualHost والإشارة إلى النسخة الآمنة من الموقع (https):

<VirtualHost *:80>
        . . .

        Redirect "/" "https://your_domain_or_IP/"

        . . .
</VirtualHost>

احفظ الملف ثم أغلقه.

الخطوة الثالثة: تعديل الجدار الناري

إن كان جدار ufw الناري مفعّلًا، وهو ما توصي به الدروس المُشار إليها في المتطلّبات، فقد تحتاج لتعديل إعداداتِه من أجل السماح للبيانات المُؤَمَّنة (عبر SSL).

يُسجّل Apache أثناء تثبيته مجموعات من المعلومات المختصرة Profiles لدى جدار ufw الناري. يمكننا عرض المجموعات المتوفّرة بالأمر التالي:

sudo ufw app list

تظهر مُخرجات الأمر :

Available applications:
  Apache
  Apache Full
  Apache Secure
  OpenSSH

يمكنك عرض الإعداد الحالي بالأمر

sudo ufw status

إن كان إعدادك الحالي يسمح لطلبات HTTP فقط فستبدو إعداداتك كالتالي”

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Apache                     ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Apache (v6)                ALLOW       Anywhere (v6)

يمكننا تفعيل المجموعة Apache Full للسماح لطلبات HTTPS وHTTP معًا، ثم حذف المجموعة Apache لأننا لم نعد بحاجة إليها، فهي متَضَمَّنة في المجموعة Apache Full :

sudo ufw allow 'Apache Full'
sudo ufw delete allow 'Apache'

ملحوظة: يمكنك استخدام الأمر sudo ufw app info PROFILE حيث PROFILE اسم مجموعة المعلومات لمعرفة المنافذ Ports والبروتوكولات التي تسمح المجموعة للطلبات بالمرور عبرها.

يجب أن تبدو حالة الجدار الناري الآن على النحو التالي:

sudo ufw status

المخرجات:

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Apache Full                ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Apache Full (v6)           ALLOW       Anywhere (v6)

الخطوة الرابعة: اعتماد التغييرات في Apache

نحن جاهزون الآن، بعد أن عدّلنا الإعدادات، لتفعيل وحدات Modules الترويسات Headers وSSL في Apache، وتفعيل المضيف الافتراضي الجاهز لاستخدام SSL ثم إعادة تشغيل Apache.

يفعّل الأمران التاليّان على التوالي mod_ssl (وحدة SSL في Apache) وmod_headers (وحدة الترويسات) اللتين تحتاجهما إعداداتنا للعمل:

sudo a2enmod ssl
sudo a2enmod headers

ثم نفعّل المضيف الافتراضي (ضع اسم المضيف مكان default-ssl إن كنت تستخدم مضيفًا غير المضيف المبدئي):

sudo a2ensite default-ssl

نحتاج أيضًا لتفعيل ملفّ الإعداد ssl-params الذي أنشأناه سابقا:

sudo a2enconf ssl-params

يجدر بالوحدات المطلوبة أن تكون الآن مفعَّلة وجاهزة للعمل، بقي لنا فقط اعتماد التغييرات. لكن قبل ذلك سنتأكّد من أنه لا توجد أخطاء صياغة في الملفات التي أعددناها وذلك بتنفيذ الأمر التالي:

sudo apache2ctl configtest

إن جرى كلّ شيء على ما يُرام فستظهر رسالة تشبه ما يلي:

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

السطر الأول ليس سوى رسالة تفيد بأنّ التعليمة ServerName غير مضبوطة لتعمل على كامل الخادوم (مثلا مضبوطة في المضيفات الافتراضية فقط). يمكنك التخلّص من هذه الرسالة - إن أردت - بضبط قيمة التعليمة ServerName على نطاق الخادوم أو عنوان IP الخاصّ به في ملف الإعدادات العام etc/apache2/apache2.conf/. هذا الإعداد اختياري، فالرسالة لا تتسبّب في أي خلل.

تظهر في السطر الثاني نتيجة التحقّق من الصياغة Syntax OK وتفيد بأنه لا توجد مشكلة من هذه الناحيّة. يمكننا إذن إعادة تشغيل خادوم الوِب لاعتماد التعديلات:

sudo systemctl restart apache2

الخطوة الخامسة: اختبار التعمية

افتح متصفّح الوِب وأدخل العنوان //:https متبوعًا باسم نطاق الخادوم أو عنوان IP الخاصّ به:

https://server_domain_or_IP

بما أنّ الشهادة الأمنيّة التي أنشأناه لا تصدُر من سلطة شهادات يثق بها المتصفّح فستظهر صفحة مخيفة عند زيارة الموقع تحمل الرسالة التالية.

هذا السلوك متوقَّع وطبيعي. نهتمّ في هذا الدرس بجانب التعميّة من الشهادات الأمنيّة دون جانب التحقّق من هويّة المضيف (الموقع) الذي توفّره سلطات الشهادات (وهو جانب مهمّ أيضًا لأمان التصفّح).

انقر على زرّ ADVANCED ثم انقر على الرابط الذي ينقلك إلى موقعك (يوجد عادة أسفل الصفحة).

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

إن أعددتَ إعادة توجيه طلبات HTTP إلى HTTPS فيمكنك التحقق من نجاح الأمر بالذهاب إلى العنوان http://server_domain_or_IP (بدون حرف s في http). إن ظهرت نفس الأيقونة السابقة في شريط العناوين فهذا يعني نجاح الإعداد.

الخطوة السادسة: جعل إعادة التوجيه دائما

إن كنت متأكّدًا من رغبتك في السماح للطلبات الآمنة فقط (القادمة عبر HTTPS)، وتحقّقت في الخطوة السابقة من عمل توجيه طلبات HTTP إلى HTTPS فيجب عليك جعل إعادة التوجيه دائمة.

افتح ملف إعداد المضيف الافتراضي الذي نريد:

sudo nano /etc/apache2/sites-available/000-default.conf

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

<VirtualHost *:80>
        . . .

        Redirect permanent "/" "https://your_domain_or_IP/"

        . . .
</VirtualHost>

احفظ الملف ثم أغلقه.

ملحوظة: إعادة التوجيه التي أعددناها في الخطوة الثانية باستخدام التعليمة Redirect فقط هي من النوع 302. تصبح إعادة التوجيه هذه من النوع 301 (الفرق بين إعادة التوجيه 301و302) عند إضافة الكلمة المفتاحية permanent (دائم) إلى التعليمة.

نتحقّق من خلو الإعدادات من أخطاء في الصياغة:

sudo apache2ctl configtest

ثم عندما يكون كلّ شيء على ما يرام نعيد تشغيل خادوم الوِب:

sudo systemctl restart apache2

ترجمة - بتصرّف للمقال How To Create a Self-Signed SSL Certificate for Apache in Ubuntu 16.04 لصاحبه Justin Ellingwood.

أباتشي هو خادوم يعتمد على الوحدات، هذا يعني أن الوظيفة الأساسية فقط هي مضمَّنة في أساس الخادوم؛ الميزات الإضافية متوفرة عبر وحدات يمكن تحميلها إلى أباتشي؛ تُضمَّن افتراضيًّا مجموعة أساسية من الوحدات في الخادوم أثناء البناء، إذا بُنِي الخادوم ليستخدم الوحدات المُحمَّلة ديناميكيًا، فيمكن بناء تلك الوحدات بناءً منفصلًا ويمكن أن تضاف في أي وقت باستخدام التعليمة 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».

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

عند إعداد خادوم ويب توجد غالبًا أقسام من الموقع نرغب بتقييد الوصول إليها، تُوفِّر تطبيقات الويب عادةً طرق التصريح 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/.htpasswd

sammy:$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 apache

Status 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 apache

Status 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.

ما هو 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 خطوة جيّدة في هذا المجال.

يُعتبَر خادوم ويب 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.