محمد هاني صباغ

عند الاتصال بخادوم ويب أو تطبيق، يتم الردّ على كلّ طلب HTTP يتمّ استقباله من طرف الخادوم برمز حالة HTTP أو “HTTP status codes”. رموز حالة HTTP هي عبارة عن رموز مكوّنة من 3 أرقام يتم تصنيفها إلى 5 أصناف مختلفة. يمكن أن يتمّ التعرّف على صنف رمز الحالة بسرعة عبر الرقم الأوّل منه: 1xx: معلومة 2xx: نجاح 3xx: إعادة توجيه 4xx: خطأ من طرف جهاز العميل 5xx: خطأ من طرف الخادوميركّز هذا الدرس على استكشاف أبرز رموز أخطاء HTTP التي قد تصادفك مثل 4xx و5xx وإصلاحها. من منظور مدير النظام، هناك العديد من الحالات التي قد تجعل خادوم الويب يجيب طلبًا معيّنًا برمز خطأ معيّن، سنقوم بتغطية أكثر الأسباب الشائعة التي تؤدي إلى ذلك بالإضافة إلى حلولها. لمحة عامة عن أخطاء العميل والخادومأخطاء العميل، أو رموز حالة HTTP من 400 إلى 499، هي نتيجة لطلبات HTTP تمّ إرسالها بواسطة جهاز مستخدم (مثل متصفح ويب أو أيّ عميل HTTP آخر), صحيح أنّ هذا النوع من الأخطاء مرتبط بالعميل، إلّا أنّه سيكون من المفيد معرفة رمز الخطأ الذي يصادف المستخدم للتحقق مما إذا كان يمكن إصلاح المشكلة من إعدادات الخادوم. يتم إرجاع أخطاء الخادوم أو بالأحرى رموز حالة HTTP من 500 إلى 599 بواسطة خادوم الويب عندما يكتشف حصول مشكلة، وإلّا فإنّه لن يكون قادرًا على معالجة الطلب. نصائح عامة عن اكتشاف الأخطاء وإصلاحهاعند استخدام متصفّح ويب لاختبار خادوم ويب، قم بتحديث المتصفّح بعد تطبيق التغييرات على الخادوم.تحقق من سجلات الخادوم للمزيد من التفاصيل عن كيفية قيام الخادوم بمعالجة الطلبات. كمثال، تُنتِج خواديم الويب مثل Apache وNginx ملفّين اثنين يدعيان access.log وerror.log يمكن أن يتم فحصهما للحصول على المعلومات منهما.تذكّر أنّ تعريفات رموز حالة HTTP هي جزء من معيار مُضمَّن من قبل التطبيق الذي يخدم الطلبات. هذا يعني أنّ رمز الحالة الذي يتم إرجاعه إليك يعتمد على كيفية معالجة برنامج الخادوم لخطأ معيّن. سيفيدك هذا الدرس عمومًا لتوجيهك في المسار الصحيح بخصوص ذلك.الآن وبعد أن امتلكت فهمًا جيدًا لرموز حالة HTTP، سنلقي نظرةً على الأخطاء الشائعة التي قد تصافدك. 400 Bad Requestرمز الحالة 400، أو خطأ Bad Request، يعني أنّ طلب الـHTTP الذي تمّ إرساله إلى الخادوم كان يحوي دوالًا ومُعامِلات غير صحيحة. إليك بعض الأمثلة التي قد يطرأ فيها خطأ Bad Request والذي رقمه 400: كعكة المستخدم (Cookie) المرتبطة بالموقع تالفة، مسح خبيئة المتصفّح والكعكات قد يحلّ هذه المشكلة. طلب تالف بسبب متصفّح ويب سيء وقديم مثلًا. طلب تالف بسبب خطأٍ بشري مثل عند تشكيل طلبات HTTP بشكلٍ يدوي (مثل استعمال curl بطريقة غير صحيحة).401 Unauthorizedرمز الحالة 401، أو خطأ Unauthorized أو عدم التصريح يعني أنّ المستخدم يحاول الوصول إلى صفحة أو مادّة غير مخوّل له بالوصول إليها أو لم يتم السماح له بذلك بشكلٍ صحيح. يعني هذا أنّه يجب على المستخدم توفير بيانات الدخول ليتمكّن من رؤية البيانات والموارد المحمية. كمثال، إذا حاول مستخدم الوصول إلى صفحة محمية باستيثاق HTTP، كما في درسنا كيفية إعداد استيثاق http مع nginx على 14.04 ubuntu، ففي هذه الحالة، سيتلقّى المستخدم رمز الحالة "401" إلى أن يقوم بتوفير اسم مستخدم وكلمة مرور (تلك الموجودة في ملفّ htpasswd.) لخادوم الويب. 403 Forbiddenرمز الحالة 403، أو خطأ Forbidden أو "محظور"، يعني أنّ المستخدم قام بطلبٍ خاطئ إلّا أنّ الخادوم يرفض تنفيذه على كلّ حال بسبب عدم توفّر الصلاحيات الكافية للوصول إلى الصفحة المطلوبة. إذا كنت تواجه خطأ 403 بشكلٍ غير متوقّع، فهناك بضع أسباب يمكن أن نشرحها هنا. صلاحيات الملفاتتطرأ أخطاء 403 عادةً عندما يكون المستخدم الذي يشغّل عملية خادوم الويب لا يمتلك الصلاحيات الكافية لقراءة الملفّ الذي تمّ طلبه. لإعطاء مثال عن الكشف عن هذا الخطأ وإصلاحه، افترض حصول الوضع التالي: يحاول المستخدم الوصول إلى ملفّ الفهرس الخاصّ بالخادوم من http://example.com/index.htmlعملية تشغيل خادوم الويب مملوكة للمستخدم www-dataيوجد ملفّ الفهرس على الخادوم بالمسار usr/share/nginx/html/index.html/إذا كان المستخدم يحصل على خطأ 403، فتأكّد أنّ المستخدم www-data يمتلك الصلاحيات الكافية لقراءة ذلك الملفّ. يعني هذا عادةً أنّه يجب ضبط صلاحيات "الآخرين" أو الـ"Others" إلى السماح بالقراءة ليتم حلّ المشكلة، هناك عدّة طرق لتنفيذ هذا، ولكنّ هذا الأمر سيعمل في هذه الحالة: sudo chmod o=r /usr/share/nginx/html/index.html htaccess.سببٌ آخر قد يكون وراء خطأ 403 وغالبًا ما يحصل عن غير قصد، هو الاستخدام الخاطئ لملفّ htaccess.، يمكن أن يتمّ استخدام ملفّ htaccess. لمنع الوصول إلى صفحاتٍ أو موارد معيّنة من قبل عناوين IP محددة أو نطاقات، استخدام هذا الملفّ بشكلٍ غير صحيح قد يكون المشكلة مثلًا. إذا كان المستخدم يحصل على خطأ 403 بشكلٍ غير متوقع، فتأكّد من أنّ ملفّ الـhtaccess. الخاصّ بك ليس المسؤول عن ذلك. ملف الفهرس غير موجودإذا كان المستخدم يحاول الوصول إلى مجلّد لا يمتلك بداخله ملفّ فهرس افتراضيًا، ولم يكن خيار السماح بسرد محتويات المجلّدات مفعّلًا، فإنّ خادوم الويب سيُرجع خطأ حظر 403. كمثال، إذا كان المستخدم يحاول الوصول إلى http://example.com/emptydir ولم يكن هناك ملفّ فهرس في المجلّد emptydir على الخادوم، فإنّه سيتم إرجاع رمز حالة 403. إذا كنت تريد تفعيل خيار سرد محتويات المجلّدات في حال عدم وجود ملفّ فهرس بداخلها، فيمكنك القيام بذلك من إعدادات خادوم الويب الخاصّ بك. 404 Not Foundرمز الحالة 404، أو خطأ Not Found، يعني أنّ المستخدم كان قادرًا على التواصل مع الخادوم إلّا أنّه لم يتمكن من إيجاد الملفّ المطلوب أو الصفحة المنشودة. يمكن أن تطرأ أخطاء 404 في الكثير من الحالات. إذا كان المستخدم يتلقّى خطأ 404 بشكلٍ غير متوقّع، فإليك بعض الأسئلة التي يجب أن تسألها للمساعدة في تفحّص المشكلة وإصلاحها: هل الرابط الذي وجّهَ المستخدم إلى خادمك يحتوي على خطأ بالكتابة؟ هل قام المستخدم بكتابة العنوان الخاطئ؟ هل الملفّ موجود في المسار الحالي للخادوم؟ وهل تمّ نقله أو نقل الصفحة المطلوبة إلى مكانٍ آخر أو حذفها من الخادوم؟ هل تمّ ضبط إعدادات الخادوم إلى مسار الجذر الرئيسي المطلوب؟ هل المستخدم الذي يملك العملية المُشغّلة لخادوم الويب يمتلك الصلاحيات اللازمة للوصول إلى المسار الذي يحوي الملفّ بداخله؟ (تلميح: تتطلب المجلّدات صلاحيات القراءة والتنفيذ لتستطيع الوصول إليها). هل يتمّ الوصول إلى الملفّ أو الصفحة عبر وصلة رمزية (symbolic link)؟ إذا كان الأمر كذلك، فتحقق من أن خادوم الويب مضبوط ليتبع الوصلات الرمزية.500 Internal Server Errorرمز الحالة 500، أو 500 Internal Server Error يعني أنّ الخادوم غير قادر على معالجة الطلب لسببٍ مجهول. أحيانًا سيظهر هذا الرمز عندما تكون أخطاء 5xx أكثر عرضةً لتكون هي سبب المشكلة. عادةً ما يكون أبرز سببٍ مسبب لهذا الخطأ هو وجود مشكلة في إعدادات الخادوم (مثل ملفّ htaccess. تالف) أو حزم ناقصة (مثل محاولة تنفيذ سكربت PHP دون وجود حزمة PHP مثبّتة بشكلٍ صحيح على الخادوم). 502 Bad Gatewayرمز الحالة 502، أو 502 Bad Gateway، يعني أنّ الخادوم هو عبارة عن خادوم بوّابة أو وسيط (proxy)، وأنّه لا يتلقّى ردًا صحيحًا من خواديم الواجهة الخلفية (backend servers) التي يجب أن تقوم بمعالجة الطلب. إذا كان الخادوم المطلوب هو عبارة عن خادوم وسيط عكسي (reverse proxy server)، مثل موازِن للحِمل، فإليك بعض الأمور التي يمكنك التحقق منها: أنّ خواديم الواجهة الخلفية (حيث يتم توجيه طلبات HTTP) تعمل بشكلٍ صحيح. أنّ الخادوم العكسي مضبوط بشكلٍ صحيح، مع تحديد الخواديم الصحيحة للواجهة الخلفية. أنّ اتصال الشبكة بين خواديم الواجهة الخلفية وبين خادوم الوسيط العكسي يعمل بشكلٍ جيّد. إذا كان بإمكان الخواديم أن تتواصل عن طريق منافذ أخرى، فتأكّد أنّ الجدار الناري يسمح بمرور التدفّق (Traffic) بينها. إذا كان تطبيق الويب الخاصّ بك مضبوطًا للاستماع إلى socket، فتأكّد أنّ الـsocket موجودة في المسار الحالي وأنّها تمتلك الصلاحيات الكافية.503 Service Unavailableرمز الحالة 503، أو خطأ Service Unavailable، يعني أنّ الخادوم قد تحمّل فوق طاقته أو أنّه تحت الصيانة، يوحي هذا الخطأ أنّ الخدمة يجب أن تعود إلى العمل في وقتٍ ما من الزمن. إذا لم يكن الخادوم تحت الصيانة، يمكن لهذا أن يشير إلى أنّ الخادوم لا يملك الموارد الكافية من المعالج والذاكرة العشوائية لمعالجة جميع الطلبات الواردة، أو أنّ خادوم الويب يحتاج إلى أنّ يتم إعداده ليسمح بالمزيد من المستخدمين والعمليات. 504 Gateway Timeoutرمز الحالة 504، أو خطأ Gateway Timeout، يعني أنّ الخادوم هو عبارة عن خادوم بوّابة أو خادوم وسيط (proxy)، وأنّه لا يتلقّى ردًا من خواديم الواجهة الخلفية في فترة الوقت المسموح بها. يمكن لهذا الخطأ عادةً أن يحصل في الحالات التالية: اتصال الشبكة بين الخواديم ضعيف. خواديم الواجهة الخلفية التي تقوم بتنفيذ الطلب بطيئة جدًا، بسبب الأداء الضعيف. فترة المهلة لخادوم البوابة أو الوسيط قصيرة جدًا.الخاتمةيجب أن تكون قد صرتَ الآن مُدركًا لأبرز رموز أخطاء HTTP وأبرز الحلول المتوفّرة لهذه الأخطاء، يجب أن تمتلك أساسياتٍ جيّدة لاكتشاف الأخطاء وإصلاحها على خواديم الويب الخاصّة بك أو تطبيقاتك. ترجمة -وبتصرف- للمقال How To Troubleshoot Common HTTP Error Codes لصاحبه Mitchell Anicas.

ما هي MySQL؟MySQL هي عبارة عن أداة إدارة قواعد بيانات شهيرة تستخدم لغة استعلامات SQL للوصول إلى البيانات والتعامل معها، يمكن استخدامها بسهولة لإدارة البيانات ضمن المواقع أو تطبيقات الويب. عمليات النسخ الاحتياطي مهمة جدًا لأي نوع من البيانات، وهذا مرتبط بشدّة عندما نتحدث عن قواعد البيانات. يمكن نسخ قواعد بيانات MySQL احتياطيا بواسطة عدة طرق سنشرحها في هذا الدرس. سنستخدم خادوم Ubuntu 12.04 مع MySQL 5.5 في شرحنا هذا. تأتي معظم توزيعات لينكس بإصداراتٍ حديثة من MySQL ويجب ألّا تواجه صعوبةً في تطبيق نفس المهام بطريقةٍ مشابهة على تلك التوزيعات. نسخ قاعدة بيانات MySQL باستخدام mysqldumpواحدة من أكثر الطرق شيوعا لعمل النسخ الاحتياطي لقاعدة بيانات MySQL هي استخدام أمرٍ يدعى "mysqldump". النسخ الاحتياطيالشكل الأساسي للأمر هو: mysqldump -u username -p database_to_backup > backup_name.sqlالاستعادةلاستعادة نسخة قاعدة بيانات MySQL مصنوعة بـmysqldump، يمكنك ببساطة إعادة توجيه الملفّ إلى MySQL مرةً أخرى. نحتاج إنشاء قاعدة بيانات فارغة لاستضافة البيانات التي سنقوم باستيرادها مجددًا. أوّلًا، قم بالولوج إلى MySQL عبر كتابة: mysql -u username -pأنشئ قاعدة بيانات جديدة الآن - والتي ستحوي جميع البيانات الموجودة في نسخة قاعدة البيانات التي قمت بنسخها مسبقًا - ومن ثمَّ، قم بالخروج: CREATE DATABASE database_name; exitالآن، يمكننا إعادة توجيه ملفّ النسخة إلى قاعدة البيانات الجديدة التي قمنا بإنشائها مسبقًا عبر استخدام الأمر: mysql -u username -p database_name < backup_name.sqlيجب أن يتم استعادة بياناتك الآن إلى قاعدة البيانات الجديدة التي أنشئتها. نسخ جدول MySQL احتياطيا إلى ملف نصييمكنك تصدير البيانات من جدول ما مباشرة إلى ملف نصي عبر استخدام جملة SELECT مع MySQL. الشكل الأساسي للعملية هو: SELECT * INTO OUTFILE 'table_backup_file' FROM name_of_table;ستقوم هذه العملية بحفظ بيانات الجدول إلى الملف النصي المطلوب. وسيفشل في حال كان هناك اسم ملف آخر موجود بنفس المسار الذي قررت حفظ الملف إليه. ملاحظة: يقوم هذا الخيار بحفظ بيانات الجدول فقط. إذا كانت بنية جدولك معقّدة ويجب حفظها كما هي، فالأفضل أن تستخدم طريقةً أخرى. نسخ معلومات MySQL احتياطيا باستخدام automysqlbackupهناك برنامج أداة يدعى "automysqlbackup" متوفّر في مستودعات توزيعة أوبونتو الرسمية. يمكن أن يتم جدولة هذه الأداة يدويا للقيام بعمليات النسخ الاحتياطي بأوقات محددة. لتثبيت هذا البرنامج، طبق الأمر التالي في الطرفية: sudo apt-get install automysqlbackupوقم بتشغيله عبر الأمر: sudo automysqlbackupستجد ملف الإعدادات الرئيسي لـautomysqlbackup في المسار "etc/default/automysqlbackup/". افتحه بصلاحيات الجذر: sudo nano /etc/default/automysqlbackupيمكنك أن ترى أن هذا الملف يقوم افتراضيا بتعيين العديد من المتغيرات باستخدام ملف MySQL الموجود في المسار "etc/mysql/debian.cnf/". وهو يقوم بقراءة اسم المستخدم وكلمة المرور وقواعد البيانات التي يجب نسخها احتياطيًا من هذا الملفّ. المسار الافتراضي للنُسَخ الاحتياطية هو “/var/lib/automysqlbackup”. ابحث عن هذا المسار لترى بنية النُسَخ الاحتياطية: ls /var/lib/automysqlbackup daily monthly weeklyإذا نظرنا إلى مجلد "daily"، فإنّه يمكننا أن نرى مجلدا فرعيًا داخله لكل قاعدة بيانات، حيث يكون بداخلها أيضًا ملفات النُسَخ الاحتياطية لقاعدة البيانات مضغوطة بصيغة gzip. استخدم الأمر التالي لترى محتويات ذاك المسار: .: database_name information_schema performance_schema ./database_name: database_name_2013-08-27_23h30m.Tuesday.sql.gz ./information_schema: information_schema_2013-08-27_23h30m.Tuesday.sql.gz ./performance_schema: performance_schema_2013-08-27_23h30m.Tuesday.sql.gzتقوم Ubuntu بتثبيت سكربت cron مع هذا البرنامج لتشغيله كل يوم. سيقوم تلقائيًا بتنظيم الملفات إلى مسارها الصحيح. كيفية النسخ الاحتياطي عند استخدام النسخ المتماثلمن الممكن استخدام النسخ المتماثل (Replication) في MySQL لعمل نسخة احتياطية عن البيانات مع الطرق المذكورة أعلاه كذلك. النسخ المتماثل هو عملية تمرير البيانات من خادومٍ إلى آخر (من رئيسي إلى فرعي) أو تمرير التغييرات من خادومٍ رئيسي إلى خادومٍ رئيسيٍ آخر. صحيح أن النسخ المتماثل يسمح بتمرير البيانات وحفظها، إلا أنه يعاني عندما تحاول حفظ البيانات من نقطة معينة من الزمان. هذا بسبب أن عملية النسخ المتماثل تحصل بشكل مستمر لتنسخ التغييرات الجديدة التي يتم إجراؤها على النظام. لتفادي هذه المشكلة يمكننا: تعطيل النسخ المتماثل مؤقتًا. جعل آلة النسخ الاحتياطي قابلة للقراءة فقط مؤقتًا.تعطيل النسخ المتماثل مؤقتايمكنك تعطيل النسخ المتماثل للخادوم الفرعي مؤقتًا عبر تنفيذ: mysqladmin -u user_name -p stop-slaveخيار آخر يمكنك استخدامه ولا يقوم بتعطيل عملية النسخ المتماثل بالكامل، بل يضعها بوضع الإيقاف المؤقت، هو تطبيق: mysql -u user_name -p -e 'STOP SLAVE SQL_THREAD;بعد إيقاف عملية النسخ المتماثل مؤقتًا، يمكنك القيام بعملية النسخ الاحتياطي باستخدام أحد الطرق المذكورة مسبقًا. يسمح لك هذا بإبقاء قاعدة البيانات الرئيسية نشطة بينما يتم نسخ قاعدة البيانات الفرعية. عندما يكتمل هذا، قم بإعادة تفعيل النسخ المتماثل عبر: mysqladmin -u user_name -p start-slaveجعل آلة النسخ الاحتياطي قابلة للقراءة فقط مؤقتايمكنك أيضًا أن تحافظ على البيانات على الخادوم عبر جعلها قابلة للقراءة فقط. يمكنك تنفيذ هذه الخطوات سواء كان على الخادوم الرئيسي (Master) أو الفرعي (Slave). أولا، قم بالولوج إلى MySQL بالصلاحيات اللازمة للقيام بذلك: mysql -u root -pالآن، يمكننا كتابة جميع التغييرات المحفوظة إلى القرص وجعل النظام قابلًا للقراءة فقط (read-only) عبر كتابة: FLUSH TABLES WITH READ LOCK; SET GLOBAL read_only = ON;الآن، قم بعمل النسخ الاحتياطي باستخدام mysqludump. بمجرّد اكتمال عملية النسخ الاحتياطي، قم بإعادة النظام إلى وضعه الأصلي عبر كتابة: SET GLOBAL read_only = OFF; UNLOCK TABLES; ملاحظة عن الطرق التي لم تعد مستحسنةmysqlhotcopyتتضمن MySQL سكربتا مكتوبا بلغة Perl لنسخ قواعد البيانات احتياطيا بسرعة ويدعى "mysqlhotcopy". يمكن أن يتم استخدام هذه الأداة للقيام بنسخ قاعدة البيانات بسرعة على الآلة المحلّية، ولكنها تمتلك بعض التقييدات التي تجعلنا نتجنبها. السبب الأهم الذي جعلنا لا نستخدمها هو أنها فقط تعمل مع البيانات التي تم تخزينها باستخدام محركات التخزين "MyISAM" و"Stroage" فقط. معظم المستخدمين لا يقومون بتغيير المحرك الافتراضي للتخزين، وبدءً من الإصدار 5.5 من MySQL فإن المحرك الافتراضي هو "InnoDB". لهذا لا يمكن استخدام هذه الأداة لأنها لا تتوافق مع المحرك. مشكلة أخرى مع هذا السكربت هو أنه يمكن تشغيله فقط على الآلة التي يتم تخزين قاعدة البيانات عليها. يمنعك هذا من القيام بعمليات النسخ الاحتياطي باستخدام آلة بعيدة (remote machine)، والذي يمكنه أن يكون مشكلة حقيقية في بعض الأحيان. نسخ ملفات الجداولطريقة أخرى تقتَرح بعض الأحيان هي القيام بنسخ الجداول التي تقوم MySQL بوضع البيانات فيها ببساطة ونقلها إلى مكان آخر. تعاني هذه الطريقة من نفس مشكلة "mysqlhotcopy". قد يكون منطقيًا استخدام هذه الطريقة مع المحرّكات التي تقوم بتخزين بياناتها على شكل ملفات، إلا أن InnoDB (وهو المحرك الافتراضي الجديد لـMySQL) لا يمكن نسخ قواعد البيانات الخاصة به بهذه الطريقة. الخاتمةهناك العديد من الطرق لإجراء عمليات النسخ الاحتياطي لقواعد بيانات MySQL، جميعها يمتلك نقاط قوة وضعف، ولكن بعضها أسهل للمستخدم وأفضل للتطبيق من غيرها. ستعتمد طريقة عملية النسخ الاحتياطي التي ستستخدمها بشكل رئيسي على احتياجاتك ومواردك، بالإضافة إلى بيئة العمل الخاصة بك. مهما كانت الطريقة التي تعتمد عليها، كن متأكدا من التحقق من النُسَخ الاحتياطية الخاصّة بك وحاول استرجاعها للتأكد من الأمر، لتكون متأكدا من أنها لا تحوي أي مشاكل. ترجمة -وبتصرف- للمقال How to Backup MySQL Databases on an Ubuntu VPS لصاحبه Justin Ellingwood.

بعد أن قمنا مسبقًا بتثبيت وإعداد خادوم قاعدة بيانات MySQL التجريبي الخاصّ بنا، يمكننا الآن البدء باستخدام mysqlslap. يمكن تشغيل mysqlslap عبر طرفية الصدفة العادية، لذا لن يكون هناك حاجة إلى الدخول إلى MySQL لتشغيله من هناك. وعلى الرغم من ذلك، فإننا سنقوم في درسنا هذا بفتح اتصالٍ جديد إلى خادومنا بالإضافة إلى بدء جلسة MySQL جديدة من هناك بواسطة المستخدم sysadmin الذي أنشأناه من قبل، لكي نتمكّن من التحقق من بعض الأمور وتحديث أخرى في MySQL بشكلٍ أسهل. لذا وفي المجمل، فإننا سنمتلك طرفيةً واحدة مفتوحة مع مستخدمٍ بصلاحيات إدارية (sudo)، وطرفية واحدة لـMySQL. قبل أن ندخل في الأوامر الرئيسية المُستخدمة للاختبار، قد تودّ أن تلقي نظرةً على هذه القائمة لأكثر الخيارات المفيدة لـmysqlslap. يمكن أن يساعدك هذا على تصميم أوامر mysqlslap الخاصّ بك لاحقًا. الخياروظيفتهuser--اسم مستخدم MySQL الذي يجب الاتصال به على خادوم قاعدة البياناتpassword--كلمة المرور الخاصّة باسم المستخدم. من الأفضل تركها فارغة في سطر الأوامرhost--اسم خادوم قاعدة بيانات MySQLport--رقم المنفذ الذي يجب من خلاله الاتصال بـMySQL إذا كان الافتراضي غير مستخدمconcurrency--عدد اتصالات العملاء الافتراضية التي سيتم محاكاتها من طرف mysqlslapiterations--عدد المرّات التي سيتم تشغيل الاختبار فيهاcreate-schema--قاعدة البيانات التي سيتم تشغيل الاختبار عليهاquery--عملية الاستعلام التي يجب تنفيذها. يمكن لهذا أن يكون متغيّر استعلام SQL أو مسارًا لملفّ سكربت SQLcreate--الاستعلام الذي يجب إنشاؤه كجدول، مجددًا، يمكن لهذا أن يكون متغيّر استعلام SQL أو مسارًا لملفّ SQLdelimiter--الحائل الذي يجب استخدامه للفصل بين جُمَل SQL متعددةengine--محرّك قاعدة البيانات الذي يجب استخدامه، مثل InnoDBauto-generate-sql-- يسمح هذا الخيار لـMySQL بتنفيذ اختبار الحِمل باستخدام أمر SQL المُنشَئ تلقائيًا من طرف mysqlslapحالة استخدام: اختبار الأداء مع بيانات واستعلامات SQL منشئة تلقائياسنبدأ عبر استخدام ميّزة mysqlslap في الإنشاء التلقائي لجمل SQL. عندما نقوم باستخدامها، فإنّ mysqlslap سيقوم بإنشاء قاعدة بيانات مؤقّتة منفصلة تدعى "mysqlslap". ستحوي قاعدة البيانات هذه جدولًا بسيطًا يحوي هو الآخر عددًا صحيحًا واحدًا وعمودًا واحدًا من نوع varchar بداخله بيانات تجريبية. يمكن أن تكون هذه طريقةً سهلة وسريعة للتحقق من أداء خادوم قاعدة البيانات الكلّي. سنبدأ عبر اختبار اتصال عميلٍ واحدٍ فقط يتم تكراره مرّةً واحدة كذلك باستخدام جملة SQL مُنشئة تلقائيًا: sudo mysqlslap --user=sysadmin --password --host=localhost --auto-generate-sql --verboseيجب أن يبدو الخرج كالتالي: Benchmark Average number of seconds to run all queries: 0.009 seconds Minimum number of seconds to run all queries: 0.009 seconds Maximum number of seconds to run all queries: 0.009 seconds Number of clients running queries: 1 Average number of queries per client: 0يقوم mysqlslap بإعطاء بعض الإحصائيات عن اختبار الأداء كما رأينا من الخرج السابق، حيث أنّه يقوم بإرجاع متوسّط، أقل وأعلى عدد من الثواني التي يحتاجها ليقوم بتنفيذ عملية الاستعلام. يمكننا أيضًا أن نرى أنّ عدد اتصالات العملاء المُستخدمة لاختبار الحِمل هذا كان واحدًا فقط. الآن، جرّب محاكاة 50 اتصال، وقم باختيار تشغيل عملية الاستعلام المُنشَئة تلقائيًا 10 مرّات: sudo mysqlslap --user=sysadmin --password --host=localhost --concurrency=50 --iterations=10 --auto-generate-sql --verboseيعني هذا الأمر أنّه سيتم محاكاة 50 اتصالًا، يقوم كلّ منها بتنفيذ نفس عملية الاستعلام بنفس الوقت، وسيتم إعادة هذه الاختبار 10 مرّات. يظهر لنا الخرج فرقًا واضحًا في الوقت مع ازدياد الحِمل: Benchmark Average number of seconds to run all queries: 0.197 seconds Minimum number of seconds to run all queries: 0.168 seconds Maximum number of seconds to run all queries: 0.399 seconds Number of clients running queries: 50 Average number of queries per client: 0لاحظ كيف أنّ حقل "Number of clients running queries" أصبح الآن يظهر الرقم 50، وأنّ عدد عمليات الاستعلام بواسطة العميل الواحد هو صفر. تقوم SQL المُشَئة تلقائيًا بإنشاء جدولٍ بسيط يحوي حقلين اثنين، إلّا أنّه وفي معظم البيئات الإنتاجية فستكون بنية الجدول أكبر بكثير من هذا. يمكننا أن نفرض على mysqlslap أن يقوم بمحاكاة هذا عبر إضافة بعض الحقول الإضافية إلى جدول الاختبار. لفعل ذلك، يمكننا استخدام المُعامِلين الجديدين number-char-cols-- وnumber-int-cols--. تقوم هذه المُعامِلات بتحديد عدد الأعمدة من نوع varchar وint لإضافتها إلى جدول الاختبار. سنختبر استعلام SQL مُنشَئ تلقائيًا عن جدولٍ بـ5 أعمدة رقمية و20 عمود نصّي في المثال التالي. سنحاكي أيضًا 50 اتصالًا من أجهزة العملاء في الوقت ذاته وسنقوم بتكرار الاختبار 100 مرّة: sudo mysqlslap --user=sysadmin --password --host=localhost --concurrency=50 --iterations=100 --number-int-cols=5 --number-char-cols=20 --auto-generate-sql --verbosسيستغرق هذا الأمر وقتًا أطول. يمكننا أن نتحوّل إلى الطرفية الأخرى الني قمنا بتشغيل جلسة MySQL الخاصّة بنا عليها لنرى ما يجري بينما يتم تنفيذ الاختبار. لاحظ أنّه في حال انتظرت وقتًا طويلًا، سيكتمل الاختبار ولن تتمكن من رؤية قاعدة البيانات الاختبارية. من طرفية MySQL، طبّق: show databases;لاحظ وجود قاعدة mysqlslap: +--------------------+ | Database | +--------------------+ | information_schema | | employees | | mysql | | mysqlslap | | performance_schema | +--------------------+ 5 rows in set (0.01 sec)يمكنك أن تتحقق من الجدول في قاعدة البيانات الاختبارية إن أردت; إنّه يدعى t1. تحقق من نافذة الطرفية الأخرى الآن. عندما ينتهي الاختبار، ستلاحظ أنّ الأداء قد انخفض بدرجةٍ أكبر من السابق بسبب الحِمل الزائد: Benchmark Average number of seconds to run all queries: 0.695 seconds Minimum number of seconds to run all queries: 0.627 seconds Maximum number of seconds to run all queries: 1.442 seconds Number of clients running queries: 50 Average number of queries per client: 0ارجع إلى نافذة طرفية MySQL. يمكننا أن نرى أنّ mysqlslap قد حذف قاعدة البيانات المؤقّتة الخاصّة به، طبّق: show databases;الخرج: +--------------------+ | Database | +--------------------+ | information_schema | | employees | | mysql | | performance_schema | +--------------------+ 4 rows in set (0.00 sec)حالة استخدام: اختبار الأداء مع استعلامات مخصصةاستعلامات SQL المُنشَئة تلقائيًا جيّدة إذا كنت تريد تقييم موارد الخادوم الفيزيائية. هيَ مفيدة عندما تريد معرفة درجة الحِمل التي يمكن للنظام أن يتحمّلها. عندما تريد التحقق من تطبيقٍ يعتمد على قاعدة بيانات، فإنّك ستودّ اختبار استعلاماتٍ حقيقية على بياناتٍ حقيقية. يمكن لهذه الاستعلامات أن تأتي من خادوم الويب الخاصّ بك أو من خادوم التطبيق الذي تشغّله. الآن، سنفترض أنّك تعرف الاستعلامات المحددة التي تريد اختبارها. في القسم التالي، سنريك طريقةً لمعرفة عمليات الاستعلام التي يتم تنفيذها على خادومك. يمكنك جعل mysqlslap ينفّذ عملية استعلام معيّنة عبر الخيار query--. لا يمكن لجُمل الـSQL أن تحتوي على فواصل الأسطر (أكثر من سطر) ضمنها، ويجب فصلها بواسطة فاصلة منقوطة (;). يجب أيضًا إغلاق الاستعلامات بعلامتيّ تنصيص. في الشفرة التالية، سنقوم بتشغيل عملية استعلام بسيطة عن الجدول deptemp. يحوي جدول "deptemp" أكثر من ثلاثمئة ألف سجل بداخله. لاحظ كيف قمنا بتحديد قاعدة البيانات employees مع الخيار create-schema--: sudo mysqlslap --user=sysadmin --password --host=localhost --concurrency=50 --iterations=10 --create-schema=employees --query="SELECT * FROM dept_emp;" --verboseسيستغرق هذا بعض الوقت ليكتمل. بعدها، يجب أن تتلقّى تقريرًا عن اختبار الأداء كالتالي بعد دقيقة أو اثنتين: Benchmark Average number of seconds to run all queries: 18.486 seconds Minimum number of seconds to run all queries: 15.590 seconds Maximum number of seconds to run all queries: 28.381 seconds Number of clients running queries: 50 Average number of queries per client: 1(ملاحظة: إذا استغرقت العملية حوالي 10 دقائق أو لم ترجع أيّ خرج، فيجب عليك المحاولة مجددًا مع عددٍ أقل للخيار concurrency-- و/أو iterations--, أو محاولة تطبيقها على خادوم أقوى). بعدها، سنستخدم أكثر من جملة SQL مع الخيار query--. في المثال التالي، نقوم بإنهاء كلّ جملة بفاصلة منقوطة. سيعرف mysqlslap أننا نستخدم عددًا من أوامر SQL المنفصلة بسبب استخدامنا للخيارdelimiter--: sudo mysqlslap --user=sysadmin --password --host=localhost --concurrency=20 --iterations=10 --create-schema=employees --query="SELECT * FROM employees;SELECT * FROM titles;SELECT * FROM dept_emp;SELECT * FROM dept_manager;SELECT * FROM departments;" --delimiter=";" --verboseيستخدم هذا الاختبار نفس عدد الاتصالات ونفس عدد مرّات التكرار، إلّا أنّ الأداء كان أبطئ بشكلٍ ملحوظ بسبب استخدام أكثر من جملة SELECT واحدة (متوسّط 23.8 ثانية مقابل 18.486 ثانية). Benchmark Average number of seconds to run all queries: 23.800 seconds Minimum number of seconds to run all queries: 22.751 seconds Maximum number of seconds to run all queries: 26.788 seconds Number of clients running queries: 20 Average number of queries per client: 5يمكن لجُمل SQL التي يتم استخدامها في بيئة إنتاجية أن تكون معقّدة. إضافة جملة SQL معقّدة إلى سكربت هو أسهل من وضعها للاختبارات، لذا، يمكننا أن نطلب من mysqlslap أن يقوم بقراءة الاستعلامات من ملفّ سكربت. للقيام بهذا، فلنقم بإنشاء ملفّ سكربت من أوامر SQL. يمكننا استخدام الشفرة البرمجية أدناه لإنشاء الملفّ: sudo echo "SELECT * FROM employees;SELECT * FROM titles;SELECT * FROM dept_emp;SELECT * FROM dept_manager;SELECT * FROM departments;" > ~/select_query.sql sudo cp ~/select_query.sql /mysqlslap_tutorial/يحوي ملفّ select_query.sql جميع عبارات SELECT الآن. بما أنّ السكربت يحوي أكثر من عملية استعلام واحدة، فيمكننا استخدام مفهومٍ جديد في الاختبار. يمكن لـmysqlslap أن يقوم بتوزيع عمليات الاستعلام. يمكننا القيام بهذا عبر تحديد عدد الاستعلامات التي يجب على كلّ جهازٍ عميل متّصل أن ينفذّها. يسمح mysqlslap بفعل هذا عبر استخدام الخيار number-of-queries--. لذا، إذا كان لدينا 50 اتصال و1000 عمليّة استعلام يجب تنفيذها، فإنّ كلّ جهاز عميل متّصل سينفّذ حوالي 20 عملية استعلام تقريبًا. أخيرًا، يمكننا أيضًا استخدام الخيار debug-info--، والذي سيظهر لنا حسبة تقريبية للموارد المستعملة. في الشفرة البرمجية التالية، نطلب من mysqlslap أن يستخدم ملفّ السكربت الذي أنشأناه للتوّ. إننا نقوم أيضًا بتحديد المُعامِل number-of-queries. سيتم تكرار العمليّة مرّتين كما أننا نريد معلومات التنقيح (debug) ضمن الخرج: sudo mysqlslap --user=sysadmin --password --host=localhost --concurrency=20 --number-of-queries=1000 --create-schema=employees --query="/mysqlslap_tutorial/select_query.sql" --delimiter=";" --verbose --iterations=2 --debug-infoبعد أن يكتمل هذا الأمر، يجب أن نرى بعض النتائج المثيرة للاهتمام: Benchmark Average number of seconds to run all queries: 217.151 seconds Minimum number of seconds to run all queries: 213.368 seconds Maximum number of seconds to run all queries: 220.934 seconds Number of clients running queries: 20 Average number of queries per client: 50 User time 58.16, System time 18.31 Maximum resident set size 909008, Integral resident set size 0 Non-physical pagefaults 2353672, Physical pagefaults 0, Swaps 0 Blocks in 0 out 0, Messages in 0 out 0, Signals 0 Voluntary context switches 102785, Involuntary context switches 43هنا يكون متوسّط عدد الثواني اللازم لتنفيذ جميع عمليات الاستعلام في MySQL هو 217 ثانية، حوالي 4 دقائق. صحيحٌ أنّ هذا الرقم له علاقة بحجم الذاكرة العشوائية ونوع المعالج المُستخدم مع آلتنا الوهمية، إلّا أنّه كان كبيرًا أيضًا بسبب عدد الاستعلامات الكبير الذي كان كلّ جهاز عميل متصل يكرره مرّتين. يمكننا أن نرى وجود عددٍ كبير من أخطاء الصفحات غير العتادية (البرمجية). تحصل أخطاء الصفحات (page faults) عندما لا يمكن العثور على البيانات في الذاكرة ويتوجّب على النظام أن يبحث عنها على قرص الـSwap. يظهر الخرج أيضًا بعض المعلومات المتعلّقة بالمعالج المركزي. في حالتنا، فإننا نرى عدد كبيرًا من تبديلات السياق كذلك. حالة استخدام: سيناريو اختبار أداء عملي مع التقاط مباشر للاستعلاماتإلى الآن في أمثلتنا، كنّا نقوم بتطبيق عمليات الاستعلام مع قاعدة بيانات "employees" الخاصّة بنا، وهو ما قد لا يكون شيئًا يريدك مُدراء قواعد البيانات أن تفعله، وهناك سببٌ وجيهٌ لذلك. لا تريد أن تقوم بإضافة حِمل إضافي إلى قاعدة بياناتك الإنتاجية ولا تريد أن تقوم بتفيذ استعلامات اختبارية يمكنها أن تقوم بحذف، تحديث أو إدراج البيانات إلى جداول قاعدة البيانات الإنتاجية الخاصّة بك. سنريك كيفيّة عمل نسخة احتياطية من قاعدة بيانات إنتاجية وكيفيّة نسخها إلى بيئة تجريبية، في هذا المثال وعلى نفس الخادوم، ولكنّك طبعًا قد تودّ نسخها إلى خادومٍ منفصل بنفس قدرات العتاد. والأكثر أهميّة من ذلك، سنريك كيف تقوم بتسجيل الاستعلامات بشكلٍ حيّ أو مباشر (live) من قاعدة بيانات إنتاجية بالإضافة إلى كيفيّة إضافة الاستعلامات إلى سكربتٍ اختباري. في المجمل، ستحصل على الاستعلامات من بيئة عمل إنتاجية، ولكنّك ستقوم بتنفيذ الاختبارات على قاعدة البيانات التجريبية. الخطوات العامّة هي كالتالي، ويمكنك استخدامها لأيّ اختبار mysqlslap: انسخ قاعدة البيانات الإنتاجية إلى بيئة اختبارية.قم بإعداد MySQL لتسجيل والتقاط جميع طلبات الاتصال والاستعلام على قاعدة البيانات الإنتاجية.قم بمحاكاة حالة الاستخدام التي تحاول اختبارها. كمثال، إذا كنتَ تدير موقع تسوّق، يجب أن تشتري شيئًا لتقوم بتفعيل جميع عمليات الاستعلام الأساسية ضمن تطبيقك.قم بتعطيل تسجيل الاستعلامات.انظر إلى سجل الاستعلامات وقم بعمل قائمة بالاستعلامات التي تريد اختبارها.أنشئ ملفًّا اختباريًا لكلّ عملية استعلام تريد اختبارها.نفّذ الاختبارات.استخدم الخرج لتحسين أداء قاعدة البيانات الخاصّة بك.للبدء، قم بإنشاء نسخة احتياطية من قاعدة البيانات "employees". سنقوم بإنشاء مسارٍ منفصل لهذه النسخة الاحتياطية: sudo mkdir /mysqlslap_tutorial/mysqlbackup cd /mysqlslap_tutorial/mysqlbackupأنشئ النسخة الاحتياطية وانقلها إلى المسار الجديد: sudo mysqldump --user sysadmin --password --host localhost employees > ~/employees_backup.sql sudo cp ~/employees_backup.sql /mysqlslap_tutorial/mysqlbackup/اذهب إلى خادوم MySQL التجريبي الخاصّ بك، وأنشئ قاعدة البيانات "employees_backup": CREATE DATABASE employees_backup;في هذه النقطة، إذا كنتَ تستخدم خادومًا منفصلًا للاختبار، فيجب أن تنقل ملفّ employeesbackup.sql إليه، ومن جلسة الطرفيّة الرئيسية، استورد بيانات النسخة الاحتياطية إلى قاعدة البيانات employeesbackup: sudo mysql -u sysadmin -p employees_backup < /mysqlslap_tutorial/mysqlbackup/employees_backup.sqlعلى خادوم قاعدة بيانات MySQL الإنتاجية الخاصّ بك، فعّل سجل استعلامات MySQL العام وقم بتوفير اسم ملفٍّ خاصٍّ به. يقوم سجل الاستعلامات العام بالتقاط الاتصالات، الاتصالات المنقطعة وسجل الاستعلامات لقاعدة بيانات MySQL: SET GLOBAL general_log=1, general_log_file='capture_queries.log';الآن، شغّل الاستعلامات التي تريد اختبارها على خادوم MySQL الإنتاجي. في هذا المثال، سنقوم بتنفيذ عملية استعلام من سطر الأوامر. وعلى كلّ حال، قد تودّ إنشاء الاستعلامات من تطبيقك عوضًا عن تنفيذها بشكلٍ مباشر. إذا كنتَ تمتلك صفحة موقع تريد اختبار أدائها، فيجب عليك تنفيذ تلك العملية أو الوصول إلى تلك الصفحة الآن. كمثال، إذا كنتَ تدير موقع تسوّق إلكتروني، قد تودّ إكمال عملية الدفع الآن، والذي من شأنه أن يقوم بطلب جميع الاستعلامات المطلوبة على خادوم قاعدة البيانات. هذه هي عملية الاستعلام التي سنقوم بطلبها على خادوم MySQL الإنتاجي الخاصّ بنا. أولًا، قم باستخدام قاعدة البيانات الصحيحة: USE employees;والآن عملية الاستعلام: SELECT e.first_name, e.last_name, d.dept_name, t.title, t.from_date, t.to_date FROM employees e INNER JOIN dept_emp de ON e.emp_no=de.emp_no INNER JOIN departments d ON de.dept_no=d.dept_no INNER JOIN titles t ON e.emp_no=t.emp_no ORDER BY e.first_name, e.last_name, d.dept_name, t.from_date;الخرج المتوقّع: 489903 rows in set (4.33 sec)سنقوم بتعطيل التسجيل العام عندما تكتمل عملية الاستعلام: SET GLOBAL general_log=0;لاحظ أنّه في حال تركت التسجيل العام مفعّلًا، سيستمر إضافة الاستعلامات إلى السجل، والذي من شأنه جعل الاختبارات أصعب. لذا تأكّد أنّك قمت بتعطيل التسجيل مباشرةً بعد الإنتهاء من اختبارك. فلنتحقق من أنّ ملفّ السجل تمَّ إنشاؤه ضمن المسار var/lib/mysql/: sudo ls -l /var/lib/mysql/capt* -rw-rw----. 1 mysql mysql 861 Sep 24 15:09 /var/lib/mysql/capture_queries.logفلننسخ هذا الملفّ إلى مسار MySQL الاختباري الخاصّ بنا. إذا كنتَ تستخدم خادومًا منفصلًا للاختبار، فقم بنسخه إلى ذلك الخادوم: sudo cp /var/lib/mysql/capture_queries.log /mysqlslap_tutorial/يجب أن يكون هناك بعض البيانات داخل ملفّ السجل هذا. في مثالنا، يجب أن تكون الاستعلامات التي نريدها بالقرب من نهاية الملفّ. تحقق من آخر جزء من الملفّ عبر الأمر: sudo tail /mysqlslap_tutorial/capture_queries.logالخرج المتوقّع: 6294 Query show databases 6294 Query show tables 6294 Field List departments 6294 Field List dept_emp 6294 Field List dept_manager 6294 Field List employees 6294 Field List salaries 6294 Field List titles 140930 15:34:52 6294 Query SELECT e.first_name, e.last_name, d.dept_name, t.title, t.from_date, t.to_date FROM employees e INNER JOIN dept_emp de ON e.emp_no=de.emp_no INNER JOIN departments d ON de.dept_no=d.dept_no INNER JOIN titles t ON e.emp_no=t.emp_no ORDER BY e.first_name, e.last_name, d.dept_name, t.from_date 140930 15:35:06 6294 Query SET GLOBAL general_log=0يظهر هذا السجل أوامر SQL والتوقيت الزمني الخاصّ بها. جملة SQL SELECT الموجودة بالقرب من نهاية الملفّ هي الجزء الذي نحن مهتمّون به. يجب أن يكون بالضبط هو الأمر الذي نقوم بتنفيذه على خادوم قاعدة البيانات الإنتاجية، حيث أننا قمنا من هناك بالتقاطه. في مثالنا هذا، كنّا نعرف عملية الاستعلام بالفعل، ولكن، في بيئة عمل إنتاجية، يمكن أن تكون هذه الطريقة نافعة جدًا لمعرفة الاستعلامات التي ربّما لا تعرف بالضرورة أنّه يتم تشغيلها على خادومك. لاحظ أنّه في حال قمت بطلب استعلامات مختلفة أثناء عملية التسجيل (logging)، فإنّ هذا الملفّ سيبدو مختلفًا تمامًا. في سيناريو حقيقي، يمكن أن يتمّ ملئ هذا الملفّ بالمئات من المُدخَلات القادمة من مختلف الاتصالات. هدفك هو العثور على الاستعلام أو الاستعلامات التي تسبب هذا الحِمل. يمكنك أن تبدأ عبر إنشاء قائمة بكلّ سطر يتضمّن الكلمة "Query". بعدها، ستمتلك قائمةً دقيقة بالاستعلامات التي تمّ تنفيذها على قاعدة البيانات الخاصّة بك أثناء الاختبار. قم بنسخ كلّ استعلام تريد اختباره إلى ملفٍّ ينتهي بالامتداد sql. كمثال: sudo vi /mysqlslap_tutorial/capture_queries.sqlيجب أن تكون المحتويات هي استعلامات MySQL التي تريد اختبارها، دون استخدام أيّ سطور إضافية (استخدم سطر واحد فقط) ودون فاصلة منقوطة بالنهاية: SELECT e.first_name, e.last_name, d.dept_name, t.title, t.from_date, t.to_date FROM employees e INNER JOIN dept_emp de ON e.emp_no=de.emp_no INNER JOIN departments d ON de.dept_no=d.dept_no INNER JOIN titles t ON e.emp_no=t.emp_no ORDER BY e.first_name, e.last_name, d.dept_name, t.from_dateبعدها، تأكّد أنّ نتائج الاستعلامات لم يتم تخزينها في ذاكرة الخبيئة (cache). ارجع إلى جلسة MySQL الخاصّة بالخادوم الاختباري وطبّق الأمر التالي: RESET QUERY CACHE;الآن، صار الوقت المناسب لتشغيل أداة mysqlslap مع ملفّ السكربت. تأكّد أنّك تستخدم اسم ملفّ السكربت الصحيح مع المُعامِل query--. سنستخدم فقط 10 اتصالات افتراضية وسنكرر العمليّة مرّتين فقط. قم بتشغيل الأمر التالي من خادومك الاختباري: sudo mysqlslap --user=sysadmin --password --host=localhost --concurrency=10 --iterations=2 --create-schema=employees_backup --query="/mysqlslap_tutorial/capture_queries.sql" --verboseيجب أن يبدو خرج اختبار الأداء شيئًا كالتالي: Benchmark Average number of seconds to run all queries: 68.692 seconds Minimum number of seconds to run all queries: 59.301 seconds Maximum number of seconds to run all queries: 78.084 seconds Number of clients running queries: 10 Average number of queries per client: 1إذًا، كيف يمكننا الآن تحسين هذا الأداء؟ ستحتاج معرفةً جيّدة باستعلامات MySQL لتقييم ما تفعله عمليات الاستعلام. بالنظر مجددًا إلى الاستعلامات، يمكننا أن نرى أنّه تقوم بالعديد من عمليات الدمج على امتداد أكثر من جدول، تقوم الاستعلامات بإظهار تواريخ عمل الموظّف وأثناء القيام بذلك، تقوم بدمج أكثر من جدول عبر الحقل empno، كما أنّها تقوم باستخدام الحقل deptno للدمج، ولكن بما أنّه هناك أقسام سجلات قليلة فقط، فسنقوم بتجاهل هذا. بما أنّه هناك العديد من مُدخَلات empno في قاعدة البيانات، فمن المنطقي افتراضي أنّ إنشاء الفهارس في حقل empno يمكن أن يحسّن من أداء عمليات الاستعلام. مع القليل من التمرّن، بمجرّد أن تجد الاستعلامات التي تسبب ضغطًا على خادوم البيانات (وهو القسم الذي سيساعدك mysqlslap فيه!)، ستكون قادرًا على تقييم عمليات الاستعلام المتوفّرة بناءً على معرفتك بـMySQL وقاعدة بياناتك. بعدها، يمكنك محاولة تحسين قاعدة بياناتك أو الاستعلامات التي يتم تنفيذها عليها. في حالتنا، فلنضف الفهارس التي ذكرناه بالأعلى، سنقوم بإنشاء 3 فهارس فارغة لـempno. سيتم إنشاء فهرس واحد في حقل empno في جدول employees، وسيتم إنشاء فهرس آخر في حقل empno بالجدول deptemp، وسيتم إنشاء الأخير في حقل emp_no في جدول titles. فلنذهب إلى جلسة MySQL الاختبارية الخاصّة بنا ونطبّق الأوامر التالية: USE employees_backup; CREATE INDEX employees_empno ON employees(emp_no); CREATE INDEX dept_emp_empno ON dept_emp(emp_no); CREATE INDEX titles_empno ON titles(emp_no);بالعودة إلى نافذة الطرفية الرئيسية على خادومنا الاختباري، إذا قمنا بتشغيل mysqlslap بنفس المُعاملات، فسنرى اختلافًا في نتائج اختبار الأداء: sudo mysqlslap --user=sysadmin --password --host=localhost --concurrency=10 --iterations=2 --create-schema=employees_backup --query="/mysqlslap_tutorial/capture_queries.sql" --verbose Benchmark Average number of seconds to run all queries: 55.869 seconds Minimum number of seconds to run all queries: 55.706 seconds Maximum number of seconds to run all queries: 56.033 seconds Number of clients running queries: 10 Average number of queries per client: 1يمكن أن نرى وجود تحسّن فوري في متوسّط، أدنى وأقصى وقت لتنفيذ عمليات الاستعلام. عوضًا عن متوسّط 68 ثانية، يتم تنفيذ الاستعلامات الآن بغضون 55 ثانية. هذا تحسّن بحوالي 13 ثانية لنفس الاستعلامات التي تمّ تنفيذها. بما أنّ هذا التغيير في قاعدة البيانات أعادة نتيجةً جيّدة في البيئة الاختبارية، فإنّه يمكنك الآن أخذه بعين الاعتبار لتنفيذه على خادوم قاعدة البيانات الإنتاجية الخاصّة بك، ولكن لا تنسى أنّ تغييرات قاعدة البيانات لها دومًا إيجابيات وسلبيات عليك المفاضلة بينها. يمكنك إعادة عملية اختبار الأوامر والتحسينات مع جميع الاستعلامات التي جمعتها من ملفّ السجل الخاصّ بك. استكشاف الأخطاء وإصلاحها: mysqlslap لا يظهر الخرجإذا قمت بتنفيذ أمر اختبار ولم يرجع لك خرجًا، فهذا مؤشّرٌ جيّد إلى أنّ موارد خادومك قد تكون امتلأت بالفعل. قد تتضمّن أعراض هذه المشكلة نقصًا في خرج Benchmark، أو رسالة خطأ مثل: mysqlslap: Error when storing result: 2013 Lost connection to MySQL server during queryربّما قد تودّ إعادة الاختبار مجددًا مع عددٍ أقل للمُعامِل concurrency-- أو iterations--، أو يمكنك محاولة ترقية بيئة خادومك الاختباري لإصلاح المشكلة. يمكن أن يكون هذا طريقةً جيّدة لمعرفة حدود سعة خادوم قاعدة البيانات الخاصّ بك. الخاتمةmysqlslap هو أداة بسيطة وخفيفة يمكنها أن تندمج بسهولة مع محرّك قاعدة بيانات MySQL. وهي متوفّر لجميع إصدارات MySQL بدءًا من الإصدار 5.1.4. في هذا الدرس، رأينا كيفيّة استخدام mysqlslap مع خياراته المتعددة وجرّبنا الأمر مع قاعدة بيانات اختبارية كعيّنة. يمكنك تحميل قواعد بيانات عينية أخرى للاختبار من موقع MySQL والتمرّن عليها أيضًا. كما ذكرنا من قبل: رجاءًا لا تقم بتنفيذ الاختبارات على خادوم قاعدة بيانات إنتاجية. آخر حالة استخدام في درسنا هذا تعلّقت بعملية استعلام واحدة فقط. صحيحٌ أننا قمنا بتحسين أداء عملية الاستعلام تلك عبر إضافة فهارس إضافية إلى جميع الجداول الثلاث، إلّا أنّ العملية قد لا تكون بتلك البساطة في الحياة الحقيقية. إضافة المزيد من الفهارس قد يبطئ - في بعض الأحيان - أداء النظام وغالبًا مع يحتاج مُدراء قواعد البيانات إلى قياس إيجابيات إضافتها على حساب التغيير في الأداء الذي سيحصل. سيناريوهات الاختبار في الحياة الحقيقية أكثر تعقيدًا، ولكن هذا قد يعطيك الأدوات اللازمة للبدء في اختبار وتحسين أداء قاعدة البيانات الخاصّة بك. ترجمة -وبتصرف- للمقال: How To Measure MySQL Query Performance with mysqlslap لصاحبه: Sadequl Hussain.

تأتي MySQL مع أداة تشخيص (diagnostic) تدعى mysqlslap، تمّ توفير هذه الأداة منذ الإصدار 5.1.4 من MySQL، وهي عبارة عن أداة قياس للأداء (benchmarking) يمكنها أن تساعد مدراء قواعد البيانات والمطورّين على أن يختبروا أداء خواديم قواعد البيانات الخاصّة بهم بسهولة. يمكن لـmysqlslap أن تحاكي عددًا كبيرًا من أجهزة العملاء التي تتصل بخادوم قاعدة البيانات بنفس الوقت. مُعامِلات اختبار الحمل (load testing parameters) قابلة للضبط بشكلٍ كلّي ويمكن استخدام نتائج الاختبارات المختلفة بهدف تحسين تصميم قواعد البيانات أو استهلاك موارد العتاد. في هذا الدرس، سنشرح كيفيّة تثبيت وإعداد mysqlslap بهدف إجراء اختبار الحِمْل (load test) على قاعدة بيانات MySQL باستخدام بعض عمليات الاستعلام الأساسية ولنرى كيف يمكن لاختبارات الأداء أن تساعدنا على تحسين هذه الاستعلامات لاحقًا. بعد القليل من التوضيحات المبدئية، سنقوم بعمل سيناريو تجريبي مشابه للتجربة الحقيقية حيث سنقوم بإنشاء نسخة من قاعدة بيانات موجودة حاليًا لنقوم بالاختبارات عليها، وسنجمع الاستعلامات من ملفّات السجل ونبدأ بالاختبار بواسطة سكربت. ما هو حجم الخادوم الذي يجب أن أستخدمه؟إذا كنتَ مهتمًا باختبار أداء خادوم قاعدة بياناتٍ معيّن، فيجب عليك أن تقوم بتشغيل اختبارات الأداء على خادوم بنفس المواصفات وبنسخة مطابقة تمامًا لقاعدة البيانات التي قمت بتثبيتها على خادومك الرئيسي. إذا كنتَ تريد المضيّ قدمًا بهذا الدرس بهدف التعلّم وتنفيذ كلّ أمر موجودٍ فيه، فإننا ننصحك بخادوم يمتلك 2 جيجابت من الذاكرة العشوائية (RAM) على الأقل. وبما أنّ الأوامر الموجودة في هذا الدرس تهدف إلى إرهاق الخادوم بالطلبات الكثيرة بهدف قياس أدائه، فإنّك قد تلاحظ أنّ الخواديم الأصغر حجمًا قد ينقطع الاتصال بها بسبب ذلك الحِمل. تمّ إنتاج الخرج الناتج في هذا الدرس بواسطة عدّة طرق بهدف تحسين الاستفادة من الأمثلة الموجودة هنا. الخطوة الأولى: تثبيت خادوم MySQL على نظام اختباريسنبدأ عبر تثبيت نسخة جديدة من خادوم MySQL المطوّر بواسطة المجتمع أو MySQL Community Server على نظام تشغيل اختباري. يجب ألّا تقوم بتشغيل أيّ أوامر أو استعلامات تجدها في هذا الدرس على خادوم قاعدة بيانات ضمن بيئة إنتاجية بتاتًا. تهدف هذه الاختبارات إلى الضغط على الخادوم التجريبي وقد تسبب تعليقا أو تعطلا لخادوم يعمل ضمن بيئة عمل إنتاجية. تمّ تنفيذ هذا الدرس ضمن بيئة العمل التالية: CentOS 7.أوامر تمّ تنفيذها بواسطة مستخدم جذر.2 جيجابت من الذاكرة العشوائية (RAM); لا تنسى أنّ الاختبارات التي سيتم ذكرها هنا تمّ إنتاجها بهدف التعليم ولا تعني بأيّ شكل من الأشكال أنّها نتيجة اختبارات رسمية صادرة عنّا.أولًا، سنقوم بإنشاء مسار ليحوي جميع الملفّات المتعلّقة بهذا الدرس. سيساعدنا هذا على إبقاء المكان نظيفًا. قم بالذهاب إلى هذا المسار: sudo mkdir /mysqlslap_tutorial cd /mysqlslap_tutorialبعدها، سنقوم بتحميل مستودع yum الخاصّ بنسخة المجتمع من خادوم MySQL. المستودع الذي سنحمّله هو مخصص بشكل اساسي لـRed Hat Enterprise Linux 7 إلّا أنّه يعمل بالطبع مع CentOS 7 كذلك: sudo wget http://dev.mysql.com/get/mysql-community-release-el7-5.noarch.rpmالآن يمكننا تنفيذ rpm -Uvh لتثبيت هذا المستودع: sudo rpm -Uvh mysql-community-release-el7-5.noarch.rpmتحقق أنّه قد تمّ تثبيت المستودعات عبر تفحّص محتويات المجلّد etc/yum.repos.d/: sudo ls -l /etc/yum.repos.dيجب أن يبدو الخرج كالتالي: -rw-r--r--. 1 root root 1612 Jul 4 21:00 CentOS-Base.repo -rw-r--r--. 1 root root 640 Jul 4 21:00 CentOS-Debuginfo.repo -rw-r--r--. 1 root root 1331 Jul 4 21:00 CentOS-Sources.repo -rw-r--r--. 1 root root 156 Jul 4 21:00 CentOS-Vault.repo -rw-r--r--. 1 root root 1209 Jan 29 2014 mysql-community.repo -rw-r--r--. 1 root root 1060 Jan 29 2014 mysql-community-source.repoوفي حالتنا، فإنّ MySQL 5.6 Community Server هو ما نريده: mysql-connectors-community/x86_64 MySQL Connectors Community 10 mysql-tools-community/x86_64 MySQL Tools Community 6 mysql56-community/x86_64 MySQL 5.6 Community Server 64والآن قم بتثبيت خادوم MySQL: sudo yum install mysql-community-serverبمجرّد اكتمال العمليّة، قم بالتحقق من أنّه تمّ تثبيت المكوّنات فعلًا: sudo yum list installed | grep mysqlيجب أن تبدو القائمة كالتالي: mysql-community-client.x86_64 5.6.20-4.el7 @mysql56-community mysql-community-common.x86_64 5.6.20-4.el7 @mysql56-community mysql-community-libs.x86_64 5.6.20-4.el7 @mysql56-community mysql-community-release.noarch el7-5 installed mysql-community-server.x86_64 5.6.20-4.el7 @mysql56-communityبعدها، يجب أن نتأكّد أن عفريت MySQL أو MySQL Daemon يعمل بالفعل وأنّه سيبدأ تلقائيًا عند تشغيل الخادوم. يمكنك القيام بذلك عبر الأمر التالي: sudo systemctl status mysqld.serviceيجب أن ترى خرجًا كهذا: mysqld.service - MySQL Community Server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; disabled) Active: inactive (dead)ابدأ الخدمة عبر: sudo systemctl start mysqld.serviceولجعلها تبدأ عند بدء تشغيل الخادوم: sudo systemctl enable mysqld.serviceوأخيرًا يجب علينا تأمين خادوم MySQL: sudo mysql_secure_installationسيظهر لك هذا مجموعة من الأسئلة. سنريك بالأسفل جميع الأسئلة مع أجوبتها التي يجب أن تختارها. في البداية لن يكون هناك كلمة مرور للمستخدم root الخاصّ بـMySQL، لذا، قم فقط بالضغط على زرّ Enter. أثناء الأسئلة، يجب أن تقوم بكتابة كلمة مرور جديدة وآمنة للمستخدم الجذر. يجب أن تقوم بكتابة y لإزالة حساب المستخدم المجهول من خادوم قاعدة البيانات، ولتعطيل السماح بالولوج البعيد للمستخدم الجذر وإعادة تحميل جدول الصلاحيات وغيرها: ... Enter current password for root (enter for none): OK, successfully used password, moving on... ... Set root password? [Y/n] y New password: Re-enter new password: Password updated successfully! Reloading privilege tables.. ... Success! ... Remove anonymous users? [Y/n] y ... Success! ... Disallow root login remotely? [Y/n] y ... Success! Remove test database and access to it? [Y/n] y - Dropping test database... ... Success! ... Reload privilege tables now? [Y/n] y ... Success! Cleaning up...يمكننا الآن أن نتّصل بقاعدة البيانات لنتأكّد من أنّ كلّ شيءٍ يعمل بشكلٍ صحيح: sudo mysql -h localhost -u root -pقم بإدخال كلمة مرور MySQL التي كتبتها للتوّ الآن. يجب أن ترى الخرج التالي: Enter password: Welcome to the MySQL monitor.... mysql>في طرفيّة <mysql قم بإدخال الأمر الذي سيظهر لك جميع قواعد البيانات: show databases;يجب أن ترى خرجًا كالتالي: +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | +--------------------+ 3 rows in set (0.00 sec)وأخيرًا، دعنا ننشئ مستخدمًا يدعى "sysadmin"، سيتم استخدام هذا الحساب للولوج إلى MySQL بدلًا من المستخدم الجذر. كن متأكّدًا من استبدال mypassword بكلمة المرور التي تريدها لهذا المستخدم. سنقوم أيضًا بمنح جميع الصلاحيات اللازمة لهذا المستخدم. في طرفيّة MySQL، قم بإدخال التالي: create user sysadmin identified by 'mypassword';الخرج: Query OK, 0 rows affected (0.00 sec)قم بإعطاء جميع الصلاحيات للمستخدم: grant all on *.* to sysadmin;الخرج: Query OK, 0 rows affected (0.01 sec)والآن فلنعد إلى طرفيّة نظام التشغيل العادية: quit;الخرج: Byeالخطوة الثانية: تثبيت قاعدة بيانات تجريبيةالآن، سنحتاج إلى تثبيت قاعدة بيانات تجريبية بهدف الاختبار. اسم قاعدة البيانات هذه هو "employees" وهي وهي متوفّرة بشكلٍ مجاني من على موقع MySQL، كما أنّه يمكن تحميل قاعدة البيانات من Launchpad. اخترنا قاعدة "employees" لأنّها تحتوي على مجموعة كبيرة من البيانات. رغم ذلك، فإنّ بنية قاعدة البيانات بسيطة بدرجة كافية، إنّها تحتوي على 6 جداول فقط، ولكن وفي داخلها، فهي تحتوي على سجلات 3 مليون موظّف (يمتلك جدول الرواتب لوحده حوالي 3 ملايين صفّ)، وسيساعدنا هذا على محاكاة حِمل بيئة عمل إنتاجية بشكل أفضل. أوّلًا، دعنا نتأكّد أننا في المسار mysqlslap_tutorial/ الخاصّ بنا: cd /mysqlslap_tutorialقم بتحميل آخر إصدار من قاعدة البيانات التجريبية: sudo wget https://launchpad.net/test-db/employees-db-1/1.0.6/+download/employees_db-full-1.0.6.tar.bz2قم بتثبيت bzip2 لنتمكّن من استخراج الملفّ: sudo yum install bzip2والآن قم بفكّ الضغط عن أرشيف قاعدة البيانات، قد يأخذ هذا وقتًا: sudo bzip2 -dfv employees_db-full-1.0.6.tar.bz2 sudo tar -xf employees_db-full-1.0.6.tarسيتم فكّ ضغط المحتويات إلى مسار منفصل جديد يدعى "employees_db"، نحتاج أن نقوم بالذهاب إلى هذا المجلّد لنقوم بتشغيل الأمر الذي يقوم بتثبيت قاعدة البيانات هذه. تتضمّن المحتويات ملفّ README، سجل للتغييرات، حِزَم بيانات وملفّات استعلامات SQL مختلفة تشكّل جميعها بنية قاعدة البيانات: cd employees_db ls -lوهذا هو ما يجب أن تراه: -rw-r--r--. 1 501 games 752 Mar 30 2009 Changelog -rw-r--r--. 1 501 games 6460 Oct 9 2008 employees_partitioned2.sql -rw-r--r--. 1 501 games 7624 Feb 6 2009 employees_partitioned3.sql -rw-r--r--. 1 501 games 5660 Feb 6 2009 employees_partitioned.sql -rw-r--r--. 1 501 games 3861 Nov 28 2008 employees.sql -rw-r--r--. 1 501 games 241 Jul 30 2008 load_departments.dump -rw-r--r--. 1 501 games 13828291 Mar 30 2009 load_dept_emp.dump -rw-r--r--. 1 501 games 1043 Jul 30 2008 load_dept_manager.dump -rw-r--r--. 1 501 games 17422825 Jul 30 2008 load_employees.dump -rw-r--r--. 1 501 games 115848997 Jul 30 2008 load_salaries.dump -rw-r--r--. 1 501 games 21265449 Jul 30 2008 load_titles.dump -rw-r--r--. 1 501 games 3889 Mar 30 2009 objects.sql -rw-r--r--. 1 501 games 2211 Jul 30 2008 README -rw-r--r--. 1 501 games 4455 Mar 30 2009 test_employees_md5.sql -rw-r--r--. 1 501 games 4450 Mar 30 2009 test_employees_sha.sqlقم بتشغيل هذا الأمر للاتصال بـMySQL وتشغيل سكربت employees.sql، والذي سيقوم بإنشاء قاعدة البيانات وتحميل البيانات إليها: sudo mysql -h localhost -u sysadmin -p -t < employees.sqlالآن، يجب عليك إدخال كلمة المرور التي اخترتها للمستخدم "sysadmin" من قبل. يجب أن يكون خرج العملية شيئًا كهذا، قد تأخذ وقتًا (حوال الدقيقة) ليكتمل: +-----------------------------+ | INFO | +-----------------------------+ | CREATING DATABASE STRUCTURE | +-----------------------------+ +------------------------+ | INFO | +------------------------+ | storage engine: InnoDB | +------------------------+ +---------------------+ | INFO | +---------------------+ | LOADING departments | +---------------------+ +-------------------+ | INFO | +-------------------+ | LOADING employees | +-------------------+ +------------------+ | INFO | +------------------+ | LOADING dept_emp | +------------------+ +----------------------+ | INFO | +----------------------+ | LOADING dept_manager | +----------------------+ +----------------+ | INFO | +----------------+ | LOADING titles | +----------------+ +------------------+ | INFO | +------------------+ | LOADING salaries | +------------------+الآن، يمكنك الولوج إلى MySQL وتشغيل بعض الاستعلامات البدائية للتحقق من أنّ البيانات قد تمّ استيرادها بنجاح: sudo mysql -h localhost -u sysadmin -pقم بإدخال كلمة المرور الخاصّة بالمستخدم sysadmin. تحقق من قائمة قواعد البيانات لرؤية قاعدة البيانات employees الجديدة: show databases;الخرج: +--------------------+ | Database | +--------------------+ | information_schema | | employees | | mysql | | performance_schema | +--------------------+ 4 rows in set (0.01 sec)استخدم قاعدة البيانات "employees" عبر الأمر: use employees;وللتحقق من الجداول الموجودة: show tables;الخرج: +---------------------+ | Tables_in_employees | +---------------------+ | departments | | dept_emp | | dept_manager | | employees | | salaries | | titles | +---------------------+ 6 rows in set (0.01 sec)إذا كنت تريد ذلك، فيمكنك التحقق من تفاصيل كلّ جدول من هذه الجداول. سنتحقق الآن من تفاصيل جدول titles فقط: describe titles;الخرج: +-----------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-----------+-------------+------+-----+---------+-------+ | emp_no | int(11) | NO | PRI | NULL | | | title | varchar(50) | NO | PRI | NULL | | | from_date | date | NO | PRI | NULL | | | to_date | date | YES | | NULL | | +-----------+-------------+------+-----+---------+-------+ 4 rows in set (0.01 sec)وللتحقق من رقم المُدخَلات: mysql> select count(*) from titles;+----------+ | count(*) | +----------+ | 443308 | +----------+ 1 row in set (0.14 sec)يمكنك التحقق من أيّ بيانات أخرى تريدها. بعد أن تنتهي، ارجع إلى طرفيّة نظام التشغيل الرئيسية عبر كتابة: quit;انتهى درسنا حول تثبيت mysqlslap وإعداده، اقرأ الدرس الآخر لمتابعة طريقة استخدامه للقيام بالاختبارات المطلوبة. ترجمة -وبتصرف- للمقال: How To Measure MySQL Query Performance with mysqlslap لصاحبه: Sadequl Hussain.

TLS، أو حماية طبقة النقل (Transport Layer Security)، وسلفها SSL أو طبقة الحِزَم الآمنة (Secure Sockets Layer) هما عبارة عن بروتوكولات آمنة يتم إنشاؤها بهدف توجيه تدفّق البيانات العادية (traffic) ضمن طريق مشفّر وآمن أثناء تنقّلها، وقد قمنا سابقا بشرح كيفية إعداد SSL على خادوم Apache، سنقوم في هذا الدرس بشرح كيفية إعداده مع خادوم nginx. باستخدام هذه التكنولوجيا، يمكن للخواديم أن تقوم بإرسال تدفّق البيانات بشكل آمن بينها وبين الزائر دون الحاجة إلى القلق بخصوص وجود إمكانية لاعتراض تدفّق البيانات بينها وقراءتها بواسطة شخص ما من الخارج. يساعد نظام الشهادات المستخدمين على التحقق من هوية المواقع التي يزورونها أيضًا. في هذا الدرس، سنشرح كيفيّة إنشاء شهادة SSL موقّعة ذاتيًا لخادوم Nginx على Ubuntu 14.04، لن تسمح الشهادة الموقّعة ذاتيًا لمستخدميك من أن يتحققوا من هوية موقعك بما أنّها ليست موقّعة بواسطة واحدة من الجهات التي يثق بها متصفّحك، ولكنّها ستسمح لك بتشفير الاتصالات مع زوّارك. المتطلباتقبل أن تبدأ، يجب أن تهتم ببعض الإعدادات بالطبع. سنستخدم مستخدمًا غير مستخدم الجذر مع صلاحيات sudo في هذا الدرس. يمكنك إعداد واحد عبر اتباع الخطوات المذكورة في درسنا حول إعداد خادوم أوبونتو 14.04 الابتدائي. ستحتاج أيضًا إلى تثبيت خادوم Nginx. إذا كنت تريد إعداد خادوم LEMP كامل (Linux, Nginx, MySQL, PHP) فإنّه يمكنك مراجعة درسنا حول تثبيت LEMP على أوبونتو 14.04. إذا كنت تريد خادوم Nginx فقط، فيمكنك تثبيته بواسطة: sudo apt-get update sudo apt-get install nginxالخطوة الأولى: إنشاء شهادة SSLفلنبدأ عبر إنشاء مسار فرعي ضمن مجلّد إعدادات خادوم Nginx لنضع ملفّات الشهادة التي سنقوم بإنشائها فيه: sudo mkdir /etc/nginx/sslوالآن وبعد أن قمنا بإنشاء ذلك المسار، يمكننا أن نقوم بإنشاء تلك الملفّات بأمر واحد وهو: sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.crtسيتم سؤالك عدّة أسئلة. قبل أن نتعرّف عليها، فلنتعرّف على ما يعنيه الأمر السابق: openssl: هذا هو الأمر الأساسي الذي يتم توفيره بواسطة OpenSSL لإنشاء وإدارة الشهادات، المفاتيح وطلبات التوقيع.. إلخ.req: يحدد هذا الأمر الفرعي أننا نريد استخدام إدارة طلبات توقيع الشهادة X.509. X.509 هو عبارة عن معيار بنية تحتية للمفتاح العمومي يحتاجه كلٌّ من SSL وTLS لإدار الشهادات. نريد أن نقوم بإنشاء شهادة X.509 جديدة، ولذلك فإننا سنستخدم هذا الأمر الفرعي.x509-: يقوم هذا أيضًا بتعديل الأمر السابق عبر إخبار الأداة أننا نريد إنشاء شهادة موقّعة ذاتيًا عوضًا عن إنشاء طلب توقيع شهادة، والذي كان ليحدث بالحالة العادية.nodes-: يخبر هذا الخيار OpenSSL بأننا لا نريد تأمين ملفّ المفتاح الخاصّ بنا بجملة مرور، لأنّ استخدام هذا الخيار سيعترض طريق خادوم nginx عندما يتم تشغيله تلقائيًا حيث أنّه يجب علينا إدخال جملة المرور في كلّ مرّة يبدأ فيها الخادوم وفي كلّ مرّة يتم فيها إعادة تشغيله.days 365-: يحدد هذا أنّ الشهادة التي سنقوم بإنشائها صالحة لمدّة 365 يومًا.newkey rsa:2048-: سينشئ هذا الخيار طلب الشهادة ومفتاحًا خاصًّا جديدًا في الوقت ذاته. هذا ضروري جدًا بما أننا لم نقم بإنشاء مفتاح خاصّ مسبقًا. يقوم rsa:2048 بإخبار OpenSSL بأن يقوم بتوليد مفتاح RSA بطول 2048 بت.keyout-: يسمّي هذا المُعامِل الملفّ الناتج لملفّ المفتاح الخاصّ الذي يتم إنشاؤه.out-: يسمّي هذا الخيار ملفّ الشهادة الناتج الذي نقوم بإنشائه.كما وضّحنا أعلاه، ستقوم هذه الخيارات بإنشاء ملفّ مفتاح وشهادة. سيتم سؤالنا بضع أسئلة عن خادومنا بهدف تضمين المعلومات بشكل صحيح في تلك الشهادة. قم بكتابة الأجوبة بشكل صحيح، أهمّ واحد منها هو جواب ذاك السؤال الذي يسألك عن: "Common Name (e.g. server FQDN or YOUR 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]:Bouncy Castles, Inc. Organizational Unit Name (eg, section) []:Ministry of Water Slides Common Name (e.g. server FQDN or YOUR name) []:your_domain.com Email Address []:admin@your_domain.comسيتم إنشاء الشهادة والمفتاح في مسار etc/nginx/ssl/. الخطوة الثانية: إعداد Nginx ليستخدم SSLالآن وبعد أن أصبح ملفّا الشهادة والمفتاح متوفّرين في مسار إعدادات Nginx، نحتاج الآن فقط إلى تعديل إعدادات خادوم Nginx الخاصّة بنا ليستفيد من التغييرات الجديدة. يمكنك تعلّم المزيد عن إعدادات خادوم Nginx من خلال قراءة تصنيف nginx على أكاديمية حسوب. يستطيع الإصدار 0.7.14 والأعلى منه من Nginx (تأتي أوبونتو 14.04 بالإصدار 1.4.6) أن يقوم بتفعيل SSL في نفس كتلة الخادوم (Server Block) كتدفّق HTTP عادي. يسمح لنا هذا بإعداد الوصول إلى نفس الموقع بطريقةٍ مختصرة بشكل أكبر. قد تبدو إعدادات الخادوم الخاصّة بك كالتالي: server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.html index.htm; server_name your_domain.com; location / { try_files $uri $uri/ =404; } }الشيء الوحيد الذي يجب علينا فعله لنجعل SSL تعمل على نفس الخادوم مع السماح باتصالات HTTP العادية هو إضافة السطور التالية: server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; listen 443 ssl; root /usr/share/nginx/html; index index.html index.htm; server_name your_domain.com; ssl_certificate /etc/nginx/ssl/nginx.crt; ssl_certificate_key /etc/nginx/ssl/nginx.key; location / { try_files $uri $uri/ =404; } }عندما تنتهي، احفظ الملفّ وأغلقه. الآن ستحتاج إلى إعادة تشغيل خادوم Nginx فقط لكي تأخذ التغييرات مجراها: sudo service nginx restartسيقوم هذا بإعادة تحميل إعدادات موقعك، وسيصبح قادرًا على الاستجابة إلى كل من طلبات HTTP وHTTPS. الخطوة الرابعة: اختبر إعداداتكيجب الآن أن تعمل وظيفة SSL بشكلٍ جيّد معك، ولكن يجب علينا اختبارها لنتأكّد من ذلك. أولًا، دعنا نتحقق أنّه ما يزال بإمكاننا الوصول إلى الموقع عبر بروتوكول HTTP العادي. في متصفّحك، قم بزيارة اسم نطاق الخادوم الخاصّ بك أو عنوان الـIP: http://اسم_النطاق_أو_عنوان_الآي_بييجب أن ترى الموقع العادي. في حالتي، سأرى رسالة Nginx الافتراضية فقط: إذا وصلت إلى هذه الصفحة، فهذا يعني أنّ خادومك ما يزال يخدم طلبات HTTP بشكل صحيح. الآن يمكننا التحقق مما إذا كان خادومنا قادرًا على استخدام SSL للتواصل أم لا. قم بذلك عبر كتابة بروتوكول https عوضًا عن http: https://اسم_النطاق_أو_عنوان_الآي_بيسترى رسالة تنبيه أن متصفّحك لم يتمكّن من التحقق من هوية خادومك لأنّه لم يتم توقيع الشهادة الخاصّة به من قبل جهة من الجهات التي يثق بها ذلك المتصفّح. هذه رسالة متوقّعة بمّا أنّ شهادتنا هي شهادة موقّعة ذاتيًا (self-signed). صحيح أّنّه لن يكون من الممكن استخدام شهادتنا للتحقق من هوية خادومنا، إلّا أنّ الخادوم سيزال قادرا على التواصل المشفّر. بمّا أنّ هذه الرسالة هي رسالة متوقّعة، فيمكنك الضغط على زرّ "المتابعة على كلّ حال" أو "Proceed anyway" أو أيّ خيار مشابه تجده أمامك للمتابعة. يجب أن ترى صفحة موقعك مجددًا: قد يظهر لك متصفّحك اسم بروتوكول "https" مشطوبًا في شريط العنوان أو محطّمًا أو بجانبه إشارة قفل مشطوبة. إذا ضغطت على أيقونة القفل، ستجد بعض المعلومات عن الاتصال: كما يمكنك أن ترى، المشكلة هي أنّ المتصفّح غير قادر على التحقق من هوية الخادوم بسبب أنّ شهادته ليست موقّعة من جهة إصدارات شهادات موثوقة بالنسبة إلى المتصفّح لا أكثر. يُظهر لك القسم الذي بالمنتصف أنّ الاتصال مشفّر، وهذا يعني أننا حققنا هدفنا على كلّ حال. الخاتمةلقد قمتَ الآن بإعداد خادوم Nginx الخاصّ بك ليعالج كلًّا من طلبات HTTP وSSL. سيساعدك هذا على التواصل مع زوّارك بشكل أأمن بالإضافة إلى جعل الجهات الخارجية غير قادرة على قراءة تدفّق البيانات الخاصّ بك. إذا كنتَ تخطط لإطلاق موقعٍ للعموم وتحتاج SSL، فإنّه يجب عليك شراء شهادة SSL من جهة شهادات موثوقة لموقعك لتجنّب ظهور رسالة التحذير الصفراء لزوّاك موقعك. ترجمة -وبتصرف- للمقال: How To Create an SSL Certificate on Nginx for Ubuntu 14.04 لصاحبه: Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.

تصميم تجربة المستخدم ليس هو نفس الشيء عندما تقارنه بتصميم واجهات الاستخدام. تجربة المستخدمين تحصل وراء الشاشات وبين الفجوات. كمصممي ويب وواجهات استخدام محمولة فإنّ عملنا يتركّز في بناء واجهاتٍ أنيقة. واجهاتٍ تكون عناصر أساسية في تجربة المستخدم. واجهات تسمح للمستخدمين بأن يحصلوا على أجوبة لأسئلتهم أو إكمال مهام أساسية بالنسبة لهم. عملنا هو أن نساعدهم في تحقيق أهدافهم. لكن إيّاك أن تخطئ وتعتقد أنّ هذه التفاعلات هي كلّ شيءٍ عن تجربة المستخدم. تجربة المستخدمين الرائعة تحصل دومًا خلف الشاشات وفي الفجوات. الفجوات التي تقع بين القنوات، الأجهزة وشركات الأعمال. تحصل تلك التجربة دومًا عندما تقوم المنظّمات بالاهتمام بالتفاصيل الدقيقة لتفاعلاتها مع العملاء. بسبب أنّ تصميم تجربة المستخدم يتعلّق بأكثر من أمر فإنّه من الصعب وصفه عادةً. لذا عوضًا عن ذلك، دعني أعطيك بعض الأمثلة على تفاعلاتٍ تساعد على إنشاء تجربة أفضل للمستخدمين. تفادي إزعاج دعم الهواتفتطبيق Barclays للهواتف الذكية مثال جيّد على تصميم جيّد لتجربة المستخدم. يمتلك التطبيق بذات نفسه واجهة جميلة. ولكنّ هذا ليس هو السبب وراء تجربة المستخدم الجيّدة الخاصّة به. يمتلك Barclays تطبيقًا ممتازًا للهاتف المحمول، ولكن السحر الحقيقي يحصل عندما تحاول الاتصال بهم. إذا أردت الاتصال بـBaraclays فإنّه يمكنك القيام بذلك عبر التطبيق. يسمح لك هذا بتخطّي الحاجة إلى الاستيثاق عبر الهاتف لأنّك قمتَ بهذا بالفعل عندما قمتَ بتسجيل الدخول إلى التطبيق. هذا مثال رائع على تجربة مستخدم مميّزة. أنا متأكّد من أنّ جلب نظام الهاتف والتطبيق ليتحدثا مع بعضهما البعض مباشرةً دون تدخل المستخدم لم يكن أمرًا سهلًا. ولكن بلا شكّ، فإنّه سيساعد المستخدمين على تجنّب الكثير من الإزعاج يوميًا. جعل عمليات الإرجاع أقل صعوبةإذا قمتَ من قبل بإرجاع منتج اشتريته عبر الشبكة فحينها أنت تعرف أنّ الأمر ليس سهلًا دومًا. يجب عليك كتابة طلب إرجاع، الذهاب إلى مكتب البريد والانتظار لأيّام قبل أن يعود المبلغ إلى حسابك الشخصي. وفوق كلّ هذا فهناك ذلك الأمر الذي تقلق حوله دومًا من أنّهم لن يعيدوا لك أموالك. على العكس مما سبق فقد كان لي تجربة حديثة في القيام بعملية إرجاع منتج. بعد أن أخبرت الشركة بأنني أريد إرجاع منتج خاصّ بهم، أخبروني بأنّ المال سيعود مباشرةً إلى حسابي، دون أيّ حاجة لانتظار عودة الطرد إليهم ومن ثمّ التحقق منه مجددًا. عند إرجاع منتج ما فهناك دومًا خوف من ألّا يعيدوا إليك نقودك. هذه فرصة سانحة لتحسين تجربة المستخدم. بعدها سألوني متى أريد أن يتم أخذ الطرد منّي. لم أحتج إلى توضيب الطرد وإغلاقه مجددًا أو تعبئة استمارة إرجاع ولصقها عليه والذهاب إلى البريد أو ما شابه. قام أحدهم فجأة بطرق باب منزلي حاملًا صندوقًا لكي يأخذ المنتج الذي أريد إرجاعه منّي. وضعت المنتج في ذلك الصندوق وأخذه لاحقًا. الآن، هذه تجربة مستخدم مميّزة. مساعدة الزبائن على أن يشعروا بالأمانعملت مرة مع زبون قام ببيع وجبات جاهزة مثلّجة لكبار السنّ. إنّه أمرٌ مثير للقلق بالنسبة لهم عندما يشترون المنتجات عبر الشبكة، ولا يحبّون فكرة أن يقوم شخص غريب بأن يطرق الباب عليهم. للتعامل مع هذه المشكلة، تمّ جعل اسم السائق وهويته واضحين لهم عندما يقومون بطلب عملية توصيل عبر الشبكة. بهذه الطريقة، سيتمكنون من تمييز الشخص الذي سيطرق الباب عليهم لاحقًا ليوصل الطلب إليهم. من الممكن لتجربة مستخدم جيّدة أن تقوم بزيادة أرباحك وأن تميّزك عن منافسيك. ولكنّهم لم يتوقّفوا هناك، بل يقومون بعمل فحص بواسطة الشرطة على جميع السائقين لكي يتمكّن الزبون من التأكّد من أنّ الأمر آمن. كان هذا مكلفًا واستغرق الكثير من الجهد، ولكنّه في المقابل زيادةً ملحوظةً في المبيعات. كان شيئًا لم يتمكّن منافسوهم (مثل Tescos) من تقديمه. الحفاظ على وقت المستخدمبالحديث عن عمليات التوصيل. هل قمت من قبل بالحصول على أيّ طرد عبر شركة DPD؟ أكره عمليات التوصيل، غالبًا ما لا يكون لديك أيّ فكرة عن متى سيصل الطرد الخاصّ بك وهل يجب عليك أن تقوم بمهامك وفقًا لهذا في الصباح أم في المساء. فهذا يعني أنّه يجب عليك أن تكون موجودًا ومستعدًا لرجل تسليم الطرود. لاشيء أبشع من اكتشاف وجود بطاقة تخبرك بالذهاب للمركز البريدي لاحقًا لتسلّم الطرد لأنّك اخترت اللحظة الخاطئة للذهاب إلى الحديقة. تسمح لك DPD بمعرفة موعد وصول الطرد الخاصّ بك بالضبط. تتعامل شركة DPD مع هذا. في يوم التوصيل سيقومون بمراسلتك قبل ساعةٍ من الموعد المتوقّع لوصول الطرد الخاصّ بك. كما وسيقومون أيضًا بالسماح لك بتعقّب طردك في الوقت الحقيقي ومعرفة مكانه عبر الخريطة. هذا يعني أنّه يمكنك معرفة مكان السائق وأن تقرر ما إذا كنت تمتلك 10 دقائق للذهاب إلى المتجر أم لا. بسبب تجربة المستخدم هذا، فإنني أتحمّس بشدّة عندما أكتشف أنني سأستلم طردًا عبر DPD! توفير الإلهاموأخيرًا أريد أن أذكر Etsy. يدرك المدراء في Etsy أنّه هناك الكثير من الأمور التي يمكن الاستفادة منها من قنوات التواصل الإجتماعي غير كونها مجرّد قناة تسويق. يعرفون أنّ العديد من زبائنهم يبحثون عن هديةٍ جيّدة ويحتارون في ماذا يشترون. لهذا قاموا ببناء تطبيق يقوم بالاتصال بحسابات المستخدمين على موقع Facebook. تقوم Etsy بدمج تجربة فيسبوك مع موقعهم عبر عرض اقتراحات الهدايا على المستخدمين عبر تحليل اهتمامات أصدقاء المستخدمين، يقوم التطبيق بتقديم الاقتراحات للمستخدمين عن ماهيّة الهدايا التي يجب عليهم شراؤها. استخدموا التكنولوجيا لتوفير مصدرٍ للإلهام لتجربة الشراء. أليس هذا هو نفسه خدمة العملاء؟ربّما تعتقد أنّ التفكير بهذه الطريقة هو أقرب إلى ما يشبه تصميم خدمة العملاء أكثر منه إلى تصميم تجربة المستخدم. ربّما تكون محقًا. تجربة المستخدمين ليست محدودة بقناةٍ واحدة، جهاز أو قطعة من مشروعك. الحقيقة هي أننا قمنا بتجزئة توصيفات أعمالنا بحيث تتداخل مع بعضها البعض غالبًا. أؤمن أنّ تصميم تجربة المستخدم مهمّ لأكثر من مجال. مجالات تتضمن كلا من تصميم واجهة الاستخدام وخدمة العملاء. مهما كان الاسم الذي تدعوها به، هناك درسٌ مهمّ لتعلّمه، وهو أنّ تجربة المستخدمين ليست محدودة بقناةٍ واحدة، جهاز أو قطعة من مشروعك. ترجمة -وبتصرّف- للمقال User experience design is not what you think لصاحبه Paul Boag. حقوق الصورة البارزة: Designed by Freepik.

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.

يحبّ المصممون استخدام المساحات البيضاء، ويريد أصحاب المواقع ملأها. قد تبدو المساحات البيضاء واحدة من أكثر الجوانب المثيرة للجدل في التصميم. لماذا هي مهمّة جدًا إذًا وكيف يمكننا أن نضمن استخدامها بأفضل طريقة ممكنة؟ المساحات البيضاء هي حجر البناء الأساسي للتصميم الجيّد. إنّها واحدة من أوائل الأمور التي يفكّر بها أيّ مصمم. ولكن بالنسبة إلى العديد من أصحاب المواقع، فإنّها بكلّ بساطة مجرّد إهدارٍ لمساحةٍ كان يمكن استخدامها بشكلٍ أفضل لإيصال الرسائل، الخدمات والمنتجات التي يريدونها. أرغب في هذا المقال في أنّ أشرح سبب أهميّة المساحات البيضاء وكيفيّة إبقاءها ضمن التصميم دون الإضرار بمهام العمل. وعلى كلّ حال وقبل أن أبدأ في ذلك، يجب علينا أن نوضّح ما نعنيه بـ"المساحات البيضاء". مالذي يعنيه المصممون بالمساحات البيضاء؟عندما يتحدّث المصممون عن المساحات البيضاء، فهم يعنون المساحة السلبية بذلك. بعبارةٍ أخرى فهم يقصدون المسافة بين العناصر على الشاشة. وهي ليست دائمًا "بيضاء". فقد تكون هذه المساحة ملوّنة أو خليطًا من الألوان، ولكن وفي كلتا الحالتين فهي مساحة ضمن تصميم لا تحتوي على أيّ عناصر. يمكنك بالأسفل أن ترى بعض الأمثلة على المساحات البيضاء في عدّة مواقع. الآن وبعد أن قمنا بتعريف مصطلح "المساحات البيضاء" بوضوح، فإنّ السؤال التالي سيكون: “لماذا هي مهمّة؟". لماذا المساحات البيضاء مهمّةالمساحات البيضاء هي عنصر أساسي لأيّ تصميم لسببٍ وجيه. إذا تمّ استخدامها بشكلٍ جيّد فيمكنها أن تحوّل من شكل التصميم وتوفّر له العديد من المزايا والمحاسن. بعض هذه المحاسن يكون جماليًا بحتًا بينما تمتلك غيرها أثرًا مباشرًا على فعالية موقعك. أشارك معكم أدناه 4 إيجابيات لهذا النوع الأخير: تحسين الوضوحأفضل ميّزة للمساحات البيضاء هي أنّها تزيد من الوضوح. تحتاج فقط إلى مقارنة الأمثلة الظاهرة أدناه والمستنقاة من http://alistapart.com/article/whitespace حول المساحات البيضاء لتلاحظ كيفّ أنّ استخدامها بشكلٍ جيّد يمكنه أن يحسّن بشكلٍ هائل من درجة وضوح موقعك: فهمٌ أعلىصدّق أو لا تصدّق، يمكن للمساحات البيضاء بين الفقرات وحول أقسام النصوص أن تساعد الناس على أن يفهموا ما يقرؤون بشكلٍ أفضل. وفقًا لدراسة في 2004، يمكن لهذا النوع من المساحات البيضاء أن يحسّن نسبة الفهم بنسبة 20% تقريبًا. تركيزٌ أفضليمكن للمساحات البيضاء أيضًا أن تكون طريقةً رائعة لجذب اهتمام المستخدمين إلى عنصر معيّن على الشاشة. بالنسبة إلى غير المصممين، فإنّ أسهل طريقة لجعل شيءٍ ما يجذب اهتمامًا أكبر هي عبر جعله أكبر. ولكن غالبًا ما يكون إحاطة العنصر بالمساحات البيضاء فعّالًا بنفس الدرجة. إيصال النبرة الصحيحةوأخيرًا، فإنّ استخدام المساحات البيضاء يمكن أن يكون طريقةً ممتازة لإيصال أناقة ونضارة وانفتاح التصميم. طبعًا، هذه ليست الأمور التي تريد إيصالها دومًا عبر تصميمك، ولكنّ عندما تكون هي ما تريده، فليس هناك شيءٌ أفضل من استخدام العديد من المساحات البيضاء في التصميم. أصبحت محاسن المساحات البيضاء واضحةً الآن. ولكن أحيانًا يحصل وأن يتم طرد المساحات البيضاء خارجًا من التصميم. ولمنع هذا فإنّه يجب علينا أن نفهم لما قد يحصل هذا وكيف نتغلّب عليه. أعداء المساحات البيضاء الثلاثأعتقد أنّه هناك ثلاث أعداء رئيسيين يمنعون من استخدام المساحات البيضاء ضمن التصميم. إذا كنتَ تفهم ما هي هذه الأشياء وكيف تتعامل معها، فحينها ستوفّر فرصة أكبر لتصميمك ليستخدم المساحات البيضاء التي يحتاجها. فلنبدأ بالحديث عن الطيّ (the fold). الطيّ The foldيتم طرد المساحات البيضاء خارج التصميم عادةً بسبب أنّ شخصًا ما ضمن المؤسسة يعتقد أنّ المستخدمين لا يقومون باستخدام شريط التمرير (scrollbar). النتيجة هي أنّهم يصرّون على وضع أكبر كمّية ممكنة من المحتوى في أعلى مكان ممكن على الصفحة مما يمنع من استخدام أيّ مساحات بيضاء ضمن التصميم. وعلى كلّ حال، فقد تم إثبات خطأ فكرة أنّ المستخدمين لا يقومون باستخدام شريط التمرير مبكّرًا في عام 1997، بل وأظهرت دراسات حديثة أنّ المستخدمين يقومون باستخدام شريط التمرير بكثرة للانتقال إلى نهاية الصفحات. بالإضافة إلى ذلك، فإنّه من المهم أن تتذكّر أننا لا نعرف النقطة التي سيقوم المستخدمون بالبدء فيها باستخدام شريط التمرير. يعتمد هذا على نوع نظام التشغيل، المتصفّح، دقّة الشاشة والعديد من العوامل الأخرى. في النهاية فإنّ القلق على فكرة "طيّ" الصفحات هي فكرة خاطئة. بعد قول هذا، فإنّه ما يزال من الجيّد أن تضمن أنّ الرسائل التي تحثّ المستخدمين على اتّخاذ إجراء بالإضافة إلى المحتوى موضوعةٌ في أعلى الصفحة. ولكن، هذا لا يعني أنّه يجب عليك تجاهل المحتوى الآخر ضمن الصفحة. أضف إلى ذلك أنّ وضع الكثير من المحتوى في رأس الصفحة وبدايتها سيقلل من أهمّية المحتوى الرئيسي لأنّه سيتم تجاهله في مقابل محتوىً مجاورٍ أقل كما وضّحنا في نقطة "زيادة الانتباه" في الأعلى. محاولة قول الكثيرسببٌ شائع آخر يتم من أجله عدم استخدام المساحات البيضاء ضمن التصميم هو وجود الرغبة في إيصال الكثير من المعلومات في وقتٍ واحد. يمتلك معظم أصحاب المواقع الكثير من الأشياء التي يريدون قولها ولكنّ المستخدمين لسوء الحظ لا يعيرون سوى القليل من الاهتمام. لذلك فإنّه من المهم بالنسبة لك أن تقوم بـ"صرف" هذا الاهتمام بشكلٍ حكيم. صفحتا جوجل وياهو الرئيسيتان هما مثالٌ جيّد على هذه المشكلة. تعرض كلا الشركتان خدماتٍ مشابهة. ولكنّهما تتخذان مسارًا مختلفًا لطريقة هيكلة صفحتيهما الرئيسيتين. كما يمكنك أن ترى من لقطات الشاشة التالية، تحاول ياهو جلب المستخدم لينظر إلى كلّ شيءٍ في وقتٍ واحد. بينما تعرف جوجل أنّ المستخدم لديه تركيز محدود معك ولذلك فإنّهم يركّزون على منتجهم الرئيسي أولًا – البحث. عبر النظر إلى كلتا الصفحتين فإنّك تدرك مباشرةً أيّ واحدة منهما هي الأكثر فعالية. لكي تستفيد من هذه الفكرة أقترح عليك(أو على أولئك الذين يعملون ضمن مؤسستك والذين يريدون دفع المزيد من المحتوى) أن تقوم بتحديد 15 نقطة لاهتمام المستخدم. كلّ عنصرٍ تقوم بإضافته إلى الصفحة يكلّف نقطةً واحدة. إذا كان عنصرٌ ما على الشاشة أكثر أهمّية بالنسبة لك من واحدٍ آخر فإنّك بحاجة إلى إعطائه المزيد من النقاط لتجعله بارزًا. بعددٍ قليل من النقط المتوفّرة فإنّه يصبح من الواضح بشكلٍ سريع أنّك لا تستطيع قول كلّ شيءٍ تريده على الصفحة الرئيسية، ولذا فإنّه لا يوجد حاجة لإخراج المساحات البيضاء من التصميم. السياساتبالطبع وحتّى في أحسن الأحوال في العالم فإنّ صاحب الموقع قد يضطر إلى إضافة الكثير من المحتوى إلى صفحةٍ ما بسبب سياساتٍ داخلية. عندما يصرّ أحدٌ ما أعلى منك ضمن المؤسسة أن يظهر محتوى مشروعه أو مشروعها بأكمله على الصفحة الرئيسية فإنّه هناك القليل مما يمكنك فعله. هذا هو المكان الذي يعرض فيه كتاب "Laws of Simplicity" بعض النصائح الرائعة. إذا كنت لا تستطيع إزالة قطعة معيّنة من المحتوى من الصفحة، فحينها حاول تقليصها أو إخفاءها. خذ على سبيل المثال الطريق الذي استخدمناه على صفحة موقع Wiltshire Farm Foods الرئيسية. لأسباب عدّة فقد تقرر أن تحتوي الصفحة الرئيسية على الطعام وأخبار الصحّة بغضّ النظر عنّ أنّ هذه المعلومات ستشوّش على الزائر أن يقوم باتخاذ الإجراء المطلوب منه (شراء وجبة) ولم يكن شيئًا تهتم به الشريحة الكبرى من المستخدمين. كان حلّنا هو توفير هذا المحتوى ولكن إخفاؤه إلّا في حال قرر المستخدم عرضه. قطعة صغيرة من شفرة جافاسكربت كانت كافية لتوسيع ذلك القسم عند طلب المستخدم. هذا أخفى ذلك المحتوى عن أولئك المستخدمين الغير مهتمين به وسمح للتصميم بأن يحتوي على المزيد من المساحات البيضاء. الخاتمةهناك جدالٌ بسيط حول ما إذا كانت المساحات البيضاء عبارةً عن أداة قيّمة في التصميم يمكن أن تجعل أيّ موقع يبدو أكثر فعالية. ما أراه هو أنّه لا حاجة لأن تكون هذه النقطة هي نقطة خلاف بين المصممين وأصحاب المواقع. أؤمن بأنّ أيّ تصميم سيكون قادرًا على استخدام المساحات البيضاء بشكلٍ يلائم العمل المطلوب منه تنفيذه. ولكن مالذي تعتقدونه أيها الأصحاب؟ مالمشاكل التي واجهتموها مع المساحات البيضاء؟ لماذا تعتقدون أنّ المساحات البيضاء ضمن التصميم مهمّة جدًا؟ أو لماذا لا تعتقدون ذلك؟ شاركونا آرائكم في التعليقات أدناه. تمّت ترجمة المقال: Why whitespace matters وبتصرّف لصاحبه Paul Boag. حقوق الصورة البارزة: Designed by Freepik.

في هذا الدرس، سنشرح طريقة تثبيت Icinga على Ubuntu 14.04. نظام المراقبة Icinga هو نظام مفتوح المصدر لمراقبة الخواديم والخدمات. سنغطّي بعض الإعدادات الأساسية التي ستجعلك قادرًا على مراقبة خدمات الشبكة وموارد الجهاز المستضيف عبر واجهة الويب. سنستخدم أيضًا مشغّل ملحق Nagios البعيد (NRPE - Nagios Remote Plugin Executor)، والذي سيتم تثبيته كعميل (agent) على أنظمة بعيدة (remote systems) لمراقبة مواردها المحلّية (استخدام الأقراص، عدد المستخدمين المسجّلين للدخول.. إلخ). Icinga هو عبارة عن تطبيق مراقبة أنظمة شهير ومفتوح المصدر يعمل على مراقبة الأجهزة المستضيفة والخدمات، ويقوم أيضًا بتنبيهك دوريًا عن حالتها. Icinga هو عبارة عن اشتقاق (Fork) من Nagios، لذا فهما متوافقان مع بعضهما البعض ويتشاركان بالعديد من الأمور، وقد اكتسب Icinga شعبيةً بسبب عملية تطويره الأكثر سرعةً مقارنةً بـNagios. المتطلباتلإكمال هذا الدرس، ستحتاج إلى إمكانية استخدام صلاحيات الجذر على خادوم Ubuntu 14.04. يمكن العثور على إرشادات إعداد هذه الصلاحيات من هنا. أيضًا، إذا كنتَ تريد إعداد ميّزة التنبيه عبر البريد الإلكتروني، فستحتاج إلى القيام بإعداد Postfix بطريقةٍ صحيحة. يمكن العثور على إرشادات القيام بذلك من هنا. يتم تثبيت Postfix مع حزم Icinga، ولكن يمكن إعداده لاحقًا بعد أن يتم تثبيت Icinga. تثبيت Icingaسينقوم بتثبيت Icinga باستخدام الحزم. أيضًا، سنقوم باستخدام MySQL كقاعدة بيانات. قم بتطبيق الأمر التالي لإضافة مستودع Icinga إلى مدير الحزم الخاصّ بك: sudo add-apt-repository ppa:formorer/icingaثمّ قم بتحديث قاعدة الحزم الخاصّة بك: sudo apt updateوالآن قم بتثبيت Icinga وMySQL عبر الأمر: sudo apt install icinga icinga-doc icinga-idoutils mysql-server libdbd-mysql mysql-clientسيتم سؤالك عن أكثر من شيء أثناء عملية التثبيت. إليك قائمة بالأمور التي سيتم سؤالك عنها وكيف يجب أن تجاوب عليها: إعداد MySQL: قم بإدخال كلمة مستخدم جذر جديدة لـMySQL.إعداد Postfix: اختر "Internet Site".إعداد Postfix: قم بإدخال نطاقك المؤهّل الذي تستعمله (example.com مثلًا).إعداد icinga-cgi: قم بإدخال كلمة مرور للمستخدم "icingaadmin" (ستحتاجها لتسجيل الدخول إلى لوحة التحكّم لاحقًا).إعداد icinga-common: اختر "No" لتفعيل الأوامر الخارجية.إعداد icinga-idoutils: اختر "Yes" لإعداد قاعدة بيانات لـicinga-idoutils باستخدام dbconfig-common.إعداد icinga-idoutils: اختر "mysql" كنوع قاعدة البيانات.إعداد icinga-idoutils: أدخل كلمة مرور المستخدم الجذر (root) الخاصّ بقاعدة البيانات (التي قمتَ بإدخالها أولًا).إعداد icinga-idoutils: قم بإدخال كلمة مرور جديدة لمستخدم قاعدة البيانات الخاصّة بـicinga-idoutils.هكذا يكون تثبيت Icinga مكتملًا، ولكننا مانزال بحاجة إلى إعداد بضع أمور قبل أن نتمكّن من تشغيله. لاحظ أنّ خادوم Apache وPostfix قد تمّ تثبيتهما تلقائيًا أثناء تثبيت Icinga كاعتماديات. قم بإضافة المستخدم الرئيسي لخادوم Apache والذي يدعى www-data إلى مجموعة nagios: sudo usermod -a -G nagios www-dataقم بتفعيل عفريت ido2db لكي يبدأ عند الإقلاع، والذي يقوم بتخزين أحداث وإعدادات Icinga في قاعدة البيانات. لتعديل إعدادات Icinga الافتراضية: sudo vi /etc/default/icingaقم بتغيير قيمة IDO2DB إلى yes لتبدو بالشكل التالي: IDO2DB=yesاحفظ الملفّ واخرج، وقم بإعادة تشغيل خدمة ID02DB: sudo service ido2db startقم بتفغيل وحدة idomod عبر نسخ ملفّ عيّنة idoutils.cfg إلى مجلّد إعدادات Icinga الحالي: sudo cp /usr/share/doc/icinga-idoutils/examples/idoutils.cfg-sample /etc/icinga/modules/idoutils.cfgوالآن أصبح Icinga مضبوطًا وجاهزًا للبدء: sudo service icinga restartوالآن فلنجرّب واجهة Icinga الرسومية. الوصول إلى واجهة Icinga الرسوميةاذهب إلى http://yourhost/icinga ، وقم بتسجيل الدخول باستخدام مستخدم icingaadmin وكلمة المرور الخاصّة به اللذان قمت بإعدادهما مسبقًا. يجب أن ترى أنّه Icinga يقوم حاليًا بمراقبة مستضيفٍ واحدٍ فقط هو localhost (خادومك الحالي) و7 خدمات كالتالي: يعرض الصفّ الأوّل أنّ المستضيف الوحيد الذي يتم مراقبته حاليًا فعّال، ويظهر الصفّ السفلي أنّه هناك 7 خدمات يتم مراقبتها حاليًا وتعمل بشكلٍ جيّد. إذا كانت حالة localhost هي "Down"، فحينها ربّما تحتاج إلى تغيير صلاحيات الأمر ping الخاصّ بك. شغّل الأمر التالي للسماح للمستخدم nagios باستخدام الأمر ping: sudo chmod u+s `which ping`طرق المراقبة بواسطة Icingaهناك طريقتان رئيسيتان لمراقبة المستضيفين والخدمات بواسطة Icinga: مراقبة "الخدمات العموميّة المتوفّرة".المراقبة عبر عميل مثبّت على جهاز مستضيف (host) بعيد لجمع وإرسال البيانات إلى Icinga. عند استخدام الطريقة الأولى، تشير الخدمات العمومية العامّة إلى الخدمات التي يمكن الوصول إليها عبر الشبكة المحلّية أو الإنترنت. الأمثلة الأكثر شيوعًا لذلك هي HTTP, البريد، SSH وICMP Ping. هذه الطريقة مفيدة لمراقبة الأنظمة التي لا يمكنك (أو لا تريد) تثبيت عميل (agent) عليها، وأيضًا لمراقبة واجهات الشبكة المقابلة للمستخدم. لتضمين الطريقة الثانية، سنقوم بتثبيت NRPE كعميل خاصّ بنا على المستضيفين البعيدين (remote hosts) لمراقبة مواردهم المحلّية. سيسمح هذا لـIcinga بمراقبة أشياء مثل استخدام القرص، العمليات التي تعمل حاليًا وأمورٍ أخرى بالنظام لا يمكن للطريقة الأولى مراقبتها. الطريقة 1: مراقبة الخدمات العمومية المتوفرةبسبب أنّ الطريقة الأولى تقوم ببساطة بمراقبة الخدمات المُشغّلة حاليًا، فإنّ إعداد هذه الطريقة سيكون بأكمله على خادوم Icinga. يمكن مراقبة العديد من الأشياء باستخدام هذه الطريقة، لذا سنوضّح كيفية مراقبة واجهة عمومية (public interface) لخادوم ويب. أنشئ ملفًّا باسم المستضيف الخاصّ بك، باستخدام هذا الأمر (استبدل yourhost باسم المستضيف عندك): sudo vi /etc/icinga/objects/yourhost.cfgالآن قم بإضافة السطور التالية، حيث ستستبدل host_name باسم المستضيف الخاصّ بك (في كلا المكانين)، alias بوصف للمستضيف و address بعنوان الـIP العمومي الخاصّ بالمستضيف: define host { use generic-host host_name web-1 alias A Web Server address 107.170.xxx.xxx } define service { use generic-service host_name web-1 service_description HTTP check_command check_http }احفظ الملفّ واخرج، وقم بإعادة تحميل إعدادات خدمة Icinga لكيّ تأخذ التغييرات مجراها: sudo service icinga reloadالطريقة 2: المراقبة باستعمال عميل (Agent)كما ذكرنا سابقًا، سنستخدم NRPE كعميلنا الافتراضي لجلب البيانات من مستضيفٍ بعيد إلى Icinga. هذا يعني أنّه يجب تثبيت NRPE على جميع الأجهزة والخواديم المستضيفة التي سيتم مراقبتها باستخدام هذه الطريقة، وسيجب أيضًا إعداد خادوم Icinga ليستقبل البيانات من كلّ الأجهزة المستضيفة (hosts). فلنقم بتثبيت NRPE. تثبيت NRPE على مستضيف بعيدقم بتطبيق الأمر التالي على الخادوم الذي تريد أن يتم مراقبته لتحديث قاعدة بيانات الحزم: sudo apt updateوالآن قم بتثبيت NRPE وملحقات Nagios: sudo apt install nagios-plugins nagios-nrpe-serverابحث عن اسم نظام ملفّات الجذر الخاصّ بك (لأنّه واحدٌ من الأشياء التي نريد مراقبتها): df -h /سنستخدم اسم نظام الملفّات في إعدادات NRPE لمراقبة استخدام القرص الصلب (سيكون غالبًا /dev/vda/). الآن قم بفتح ملفّ nrpe.cfg للتعديل: sudo vi /etc/nagios/nrpe.cfgملفّ إعدادات NRPE طويلٌ جدًا ومليء بالتعليقات. هناك القليل من السطور التي يجب عليك تعديلها فقط: server_address: قم بتغييره إلى عنوان الـIP الخاصّ لهذا المستضيف.allowed_hosts: قم بتعيين هذا إلى عنوان الـIP الخاصّ لخادوم Icinga الخاصّ بك.[command[check_hda1: غيّر dev/hda1/ إلى اسم نظام الملفّات الجذر الخاصّ بك الذي حصلت عليه من الخطوة السابقة.يجب أن تبدو السطور الثلاثة كشيءٍ مشابه للتالي بعد التعديل: server_address=client_private_IP allowed_hosts=nagios_server_private_IP command[check_hda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/vdaلاحظ أنّه هناك العديد من الأوامر الأخرى المعرّفة في هذا الملفّ التي سيتم تشغيلها في حال ما إذا تمّ ضبط Icinga ليستعملها. لاحظ كذلك أنّ NRPE سيعمل على المنفذ 5666 لأنّ الخيار server_port مضبوط على القيمة 5666. إذا كنتَ تمتلك أيّ جدارٍ ناري يمنع ذلك المنفذ، فيجب عليك فتحه لخادوم Icinga. احفظ الملفّ واخرج، وقم بإعادة تشغيل NRPE ليتم تطبيق التغييرات: sudo service nagios-nrpe-server restartبمجرّد ما أن تنتهي من تثبيت وإعداد NRPE على أجهزة المستضيفين التي تريد مراقبتها، سيجب عليك إضافة هؤلاء المستضيفين (hosts) إلى إعدادات خادوم Icinga الخاصّ بك قبل أن يبدأ بمراقبتهم. إضافة مستضيف بعيد إلى إعدادات خادوم Icingaعلى خادوم Icinga الخاصّ بك، قم بإنشاء ملفّ إعداداتٍ جديد لكلّ واحدٍ من الأجهزة المستضيفة البعيدة التي تريد مراقبتها في etc/icinga/objects/ واستبدل yourhost باسم المستضيف الذي تريده: sudo vi /etc/icinga/objects/yourhost.cfgقم بإضافة تعريف المستضيف التالي إلى الملفّ، واستبدل قيمة host_name باسم المستضيف البعيد الخاصّ بك (استعملتُ wordpress-1 في مثالي)، قيمة alias بوصف للمستضيف وقيمة address بعنوان الـIP الخاصّ للمستضيف البعيد: define host { use generic-host host_name wordpress-1 alias My first wordpress server address 10.128.xxx.xxx }ثمّ قم بإضافة أيّ واحدٍ من أقسام الخدمات التي تريد مراقبتها. لاحظ أنّ قيمة check_command تحدد مالذي سيتم مراقبته. إليك بعض الأمثلة على ما يمكنك إضافته إلى ملفّ الإعدادات الخاصّ بالمستضيف البعيد الخاصّ بك: Ping: define service { use generic-service host_name wordpress-1 service_description PING check_command check_ping!100.0,20%!500.0,60% }SSH (عند تعيين notifications_enabled إلى 0 فإنّه يتم تعطيل التنبيهات للخدمة) define service { use generic-service host_name wordpress-1 service_description SSH check_command check_ssh notifications_enabled 0 }الحمل(Load): define service { use generic-service host_name wordpress-1 service_description Current Load check_command check_load!5.0!4.0!3.0!10.0!6.0!4.0 }المستخدمون الحاليون: define service { use generic-service host_name wordpress-1 service_description Current Users check_command check_users!20!50 }مساحة القرص: define service { use generic-service host_name wordpress-1 service_description Disk Space check_command check_all_disks!20%!10% }إذا كنت تتسائل عن معنى use generic-service، فهي عبارة عن خيار يقوم ببساطة بجلب قِيَم قالب خدمة يدعى "generic-service" المعرّف افتراضيًا. الآن احفظ الملفّ واخرج. وقم بإعادة تحميل إعدادات Icinga: sudo service icinga reloadمثال على واجهة المستخدمبعد ضبط إعدادات المراقبة على بعض أجهزة المستضيفين بواحدٍ من الطرق المتوفّرة، اذهب إلى واجهة الويب الخاصّة بـIcinga على http://youricingaserver.com/icinga وأدخل اسم المستخدم وكلمة المرور اللذين أدخلتهما أثناء التثبيت. واضغط على رابط "Service Link". يجب أن ترى قائمة بجميع الخدمات التي قمتَ بتجهيزها ليتم مراقبتها حاليًا. كمثال، إليك مستضيفين اثنين يتم مراقبتهما باستخدام ملفّات الإعدادات التي وصفناها بالأعلى. يتم مراقبة خدمة web-1HTTP عبر منفذ HTTP العادي الخاصّ بها، وهي حاليًا تخبرنا أنّ كلّ شيءٍ يعمل بشكلٍ جيّد، وwordpress-1 يخبرنا أيضًا أنّ جميع خدماته التي نراقبها تعمل بشكلٍ جيّد حاليًا. يمتلك Icinga الكثير من المزايا، يمكنك تصفّح واجهة الويب لاستكشاف المزيد عن المستضيفين والخدمات التي تراقبها. الخاتمةالآن وبعد أن صرتَ قادرًا على مراقبة الخواديم التي تريدها والخدمات التي تحددها، ربّما تريد إمضاء المزيد من الوقت في استكشاف الخدمات المهمّة بالنسبة لك والتي تريد مراقبتها. ربّما تودّ أيضًا إعداد التنبيهات عبر البريد الإلكتروني في حال امتلاء القرصّ الصلب الخاصّ بك مثلًا أو تعطّل موقعك الرئيسي، لكي تتمكن من حلّ المشاكل فورًا أو قبل حصولها حتّى. ترجمة -وبتصرف- للمقال: How To Use Icinga To Monitor Your Servers and Services On Ubuntu 14.04 لصاحبه: Mitchell Anicas. حقوق الصورة البارزة: Designed by Freepik.

سنشرح اليوم فكرة التوفّر أو تكرار البيانات (redundancy). البيانات المُكررة ليست نسخةً احتياطية، بل هي بيانات يمكن أن تساعدك على تجاوز عمليات فشل الأقراص (disks fail) في حال ما إذا تعذّر عليك الوصول إلى بيانات الأقراص الصلبة عبر الطريقة الأساسية التي تستعملها. تعتمد طريقة تشغيل النسخ المتماثل (replication) على نظامك على كيفية استعمالك لبياناتك، الأخطاء التي تريد تجنّبها وكيفيّة تفاعل زوّارك مع خادومك. الوفرة العالية عبر RAIDربّما يكون أشهر أنواع النسخ المتماثل (replication) هو تقنية RAID. ترمز RAID إلى "مصفوفة تكرار الأقراص المستقلة - Redundant Array of Independent Disks". يعني هذا أنّه وفي غالب الأحيان، تعمل الأقراص كمرايا (mirrors) لبعضها البعض. التطبيق الأكثر شيوعًا لتقنية RAID هو مصفوفة RAID 1. يقوم هذا النوع من المصفوفات بتمرير (mirror) قرصٍ صلب ما على قرصٍ صلبٍ آخر. يعني أنّه وفي حال فشل القرص الصلب الأوّل، فسيبقى القرص الصلب الثاني موجودًا للخدمة وكتابة البيانات. يسرّع هذا النوع من المصفوفات عملية القراءة من الأقراص بسبب توفّر البيانات في أكثر من مكان وبالتالي يستطيع النظام قراءتها من أيّ موقعٍ يريد من الموقعين المتوفّرين. هذا المثال أيضًا هو مثالٌ جيّد لتوضيح السبب الذي من أجله تكون تقنية مثل RAID، أو عملية تكرار البيانات (redundancy) عمومًا مختلفة عن عملية النسخ الاحتياطي (backup). إذا قمتَ بحذف ملفّ ما فقد تمّ حذفه بالفعل ولن تتمكن من استرجاعه. يتم تطبيق التغييرات على جميع الأقراص مباشرةً بالوقت نفسه لضمان المزامنة بينها. يتم تطبيق تقنية RAID في المستوى المنخفض (low-level)، هذا يعني أنّك لن تستطيع التحكّم بتقنية RAID وخصائصها أو تضمينها على خادومك الافتراضي الخاصّ على شركة DigitalOcean مثلا، إن كان خادومك على مزود آخر، فراجع دليل المساعدة الخاص بالمزود. تكرار البيانات على مستوى الكتل Block-Levelمن الطرق الأخرى للقيام بعملية تكرار البيانات (Redundancy) هي عبر تمرير هيكلة الكُتَل (Blocks) بالكامل. DRBD أو "جهاز الكُتَل المكررة الموزّع - Distributed Replicated Block Device"، هو عبارة عن طريقة يمكن تطبيقها للقيام بعملية تكرار البيانات على امتداد أجهزة الكُتَل (Block Devices). قد يبدو هذا مشابهًا لمصفوفة RAID التي تستعمل المرايا، وفي بعض الأحيان، هي كذلك بالفعل. لكنّ الفرق هو في المكان الذي تتم فيه عملية النسخ المتماثل. في RAID، تتم عمليّة تكرار البيانات على مستوى أقل من مستوى تطبيقات النظام. تدير بطاقة RAID أو برمجيّة RAID الأقراص الصلبة الفيزيائية بنفسها وتقوم في النهاية بتقديم قرصٍ واحد ليتم قراءة البيانات منه. DRBD على الجانب الآخر، مُعدّة بطريقة مختلفة تماًمًا. في DRBD، يتم تمرير محتويات كلّ خادوم بالكامل إلى خادومٍ آخر. يتم تمرير واجهة التطبيقات كذلك. هذا يعني أنّه يمكن التعامل مع فشل التطبيقات بسهولة بسبب وجود آلة أخرى منفصلة تمامًا عن الخادوم الرئيسي تحوي على نفس محتويات الخادوم الرئيسي. إذا فشل خادومك الأوّل مثلًا بسبب مشاكل بالطاقة، فسيتم تشغيل خادومك الثاني ليقوم بنفس المهام. النسخ المتماثل في SQLإذا كانت بياناتك المهمّة مخزّنة في قاعدة بيانات SQL (مثل MySQL ،MariaDB ،PostgreSQL، ..)، فيمكنك الاستفادة من بعض مزايا النسخ التكراري أو النسخ المتماثل المضمّنة بالفعل. يمكن لهذه المزايا أن توفّر لك نظام استرجاع في حال تعطّل نظامك الرئيسي. النسخ المتماثل بـ Master-Slaveالنوع الأساسي للنسخ التكراري أو المتماثل (replication) الخاصّ بـSQL هو إعداد Master-Slave. في هذا السيناريو، تمتلك خادوم قاعدة بيانات رئيسي، والذي يتم الإشارة إليه باسم السيّد أو "Master". هذا الخادوم هو المسؤول عن تنفيذ جميع مهام الكتابة والتحديثات. يتم نسخ البيانات من هذا الخادوم بشكلٍ مستمر إلى الخادوم الفرعي أو "slave". يمكن أيضًا القراءة من هذا الخادوم، ولكن لا يمكن الكتابة عليه. يسمح لك هذا التثبيت بتوزيع البيانات على امتداد أجهزة متعددة، والذي يمكنه تحسين أداء تطبيقك بشكل ملحوظ. في حين أنّ تحسين الأداء هذا يعتبر ميّزة مهمّة، واحدٌ من الأسباب الرئيسية التي قد تودّ من أجلها إعداد نسخٍ تكراري باستخدام Master-Slave هو لمعالجة الأعطاب ومشاكل الفشل. إذا أصبح خادومك الرئيسي غير متوفّر، فيمكنك القراءة من خادومك الفرعي. أيضًا من الممكن أن تقوم بتحويل الخادوم الفرعي إلى خادوم رئيسي في حال ما إذا كان خادومك الرئيسي معطّلًا لفترة معيّنة من الوقت. نسخ Master-Slave المتماثل في الواقع هو مكان من الأماكن التي يمكننا أن نلاحظ فيها تكامل عمليتيّ النسخ الاحتياطي والنسخ المتماثل. في إعداد master-slave، يمكنك نسخ البيانات بشكلٍ متماثل من الخادوم السيّد أو الرئيسي إلى الخادوم الفرعي. يمكنك بعدها تعطيل النسخ المتماثل بشكلٍ مؤقّت لمعرفة حالة المعلومات وصيانتها على الخادوم الفرعي. من هنا، يمكنك عمل نسخة احتياطية من قاعدة البيانات باستخدام أيّ أداة نسخ احتياطي تريدها. يمكنك قراءة المزيد عن: إعداد النسخ المتماثل بـMaster-Slave لـMySQL أو إعداد النسخ المتماثل بـMaster-Slave لـPostgreSQL. النسخ المتماثل بـMaster-Masterالنوع الثاني من النسخ المتماثل يدعى "Master-Master" أو من خادومٍ رئيسي إلى خادومٍ رئيسي آخر. يسمح هذا الإعداد لكلا الخادومين بامتلاك الميّزات "الرئيسية". يعني هذا أنّه يمكن لكلا الخادومين أن يقبلا الكتابة والتحديثات ونقل التغييرات إلى الخادوم الآخر. يرث هذا الإعداد مزايا إعداد master-slave، ولكنّه يستفيد أيضًا من التحسّن بأداء الكتابة على الأقراص إذا كانت طريقة الكتابة موزّعة بشكلٍ جيّدة عبر آلية موازنة حملٍ جيّدة. هذا يعني أيضًا أنّه في حال تعطّل خادومٍ ما، سيبقى الآخر عامِلًا وقادرًا على استقبال الطلبات وخدمة الزوّار. صحيحٌ أنّ عملية الإعداد ستكون أكثر تعقيدًا هنا، ولكنّ عملية الاسترجاع في هذه الحالة هي أقل تعقيدًا من حالة الاسترجاع من الفشل في إعداد master-slave، لأنّه لا حاجة إلى نقل قاعدة البيانات من الخادوم الفرعي إلى الخادوم الرئيسي. يمكن أيضًا دمج هذا الإعداد مع آلية نسخٍ احتياطي إذا قمت بتعطيل واحدٍ من الخواديم الرئيسية. يجب أن تقوم بإعداد قاعدة بيانات ثابتة للنسخ الاحتياطي لتعمل بشكلٍ صحيح، لذا يجب عليك أن تتأكّد من أنّه لا يتم كتابة أو تعديل أيّ بيانات إلى حين انتهاء عملية النسخ الاحتياطي. يمكنك قراءة المزيد عن: النسح المتماثل كـmaster-master. التوزيع كبديل للنسخ لتكرار البياناتتعرض الأنظمة الموزّعة العديد من المزايا مقارنةً بتضبيطات تكرار البيانات التقليدية. شرحنا مراحل RAID الممررة عبر المرايا أعلاه (RAID 1). هناك مرحلة أخرى شائعة الاستخدام في RAID وهي RAID 5. تقوم هذه المرحلة بتوزيع البيانات على امتداد عددٍ من الأجهزة وتقوم أيضًا بكتابة بياناتٍ مساوية على امتداد كلّ جهاز. يعني هذا أنّه يمكن إعادة بناء أيّ نوع من الإجراءات (Transactions) عبر جمع المعلومات الموزّعة بشكلٍ متساوٍ من الأجهزة الأخرى في حال تعطّل جهازٍ ما. يوفّر هذا طريقةً مختلفة لتوزيع البيانات عبر مختلف الأقراص، ويمكنه معالجة فشل واحدٍ من الأقراص كذلك. لا يجب أن تتم الأنظمة الموزّعة على صعيد العتاد (hardware) فقط. هناك أيضًا عدّة قواعد بيانات وحلول برمجية أخرى مصممة للتعامل مع البيانات الموزّعة كميّزة أساسية لها. من الأمثلة على هذا هو Riak، Riak هو عبارة عن قاعدة بيانات موزّعة. عُقَد Riak متطابقة جميعًا. لا يوجد أيّ علاقة master-slave بين الأجزاء المختلفة. تتم عملية النسخ المتماثل على الكائنات المخزّنة في قاعدة البيانات تلقائيًا، لذا فهناك عملية نسخ متماثل تلقيدية في هذا الجانب. على كلّ حال، لا تقوم كلّ عقدة بتخزين قاعدة البيانات بأكملها داخلها، بل يتم توزيع البيانات على جميع العقد بطريقة مشابهة. يتم وضع الكائنات التي تمّ نسخها بشكلٍ متماثل على عقدٍ مختلفة للسماح بالتوفّر العالي في حال حصول أعطاب على مستوى العتاد. مثالٌ آخر قائم على هذا المبدأ المُضمّن في قاعدة بيانات هو Cassandra. وهو مبني على نفس المبادئ الموجود في Riak، ولكنّها مضمّنة بطريقة مختلفة. خاتمةكما يمكنك أن ترى، هناك العديد من الخيارات المتوفّرة للنسخ المتماثل أو النسخ التكراري، كلّ واحدٍ منه يمتلك إيجابياتٍ وسلبيات. يعتمد الأمر بشكلٍ أساسي على المشاكل التي تحاول تجنّبها وماهيّة أجزاء النظام التي لا تريد أن تكون خارج الخدمة بتاتًا. خليطٌ من هذه التقنيات سيكون دومًا خيارًا أأمن وأكثر شمولية. يجب أيضًا أن تكون قادرًا على أن ترى الآن أن إعداد النسخ المتماثل ليس بديلًا عن النسخ الاحتياطي. للتطبيقات التي يكون فيها توافق البيانات والوصول أمرًا أساسيًا، سيكون النسخ الاحتياطي والنسخ المتماثل تقنيتين لا تقدرّان بثمن. تضمينٌ صحيح لهاتين التقنيتين سيضمن لك أنّ منتجك سيكون دومًا متوفرًا للمستخدمين وأنّ البيانات لن تضيع منك. ترجمة -وبتصرف- للمقال: How To Choose a Redundancy Plan To Ensure High Availability لصاحبه: Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.

سنناقش في هذا الدرس أهمّية تحديث كلّ شيءٍ متعلّق بموقع ووردبريس الخاصّ بك إلى آخر الإصدارات المتوفّرة وأهميّة التحديثات بشكلٍ عام، وهو من أهمّ الأمور التي يمكنك القيام بها لزيادة حماية وأمان موقعك. لماذا نقوم بالتحديث؟ السؤال الحقيقي يجب أن يكون "ولما لا"؟ يقوم مطوروا ووردبريس بإرسال التحديثات إلى المستخدمين لسببٍ معيّن في النهاية، حيث أنّ هذه التحديثات تحتوي على إصلاحاتٍ لثغراتٍ خطيرة يمكن أن يستغلها المهاجمون لمهاجمة موقعك، مما يجعل التحديث ضرورة لا مفرّ منها. أنواع التحديثات قبل أن نتابع، من المهمّ أن نفهم أنواع التحديثات المختلفة المتوفّرة في سكربت ووردبريس. يشير Tony Perez في تدوينة حديثة إلى أنّه هناك 3 أنواع مختلفة من التحديثات: تحديثات الأمان، الترقيعات والإصدارات الرئيسية. تحديثات الأمان هي بالضبط كما تبدو عليه من اسمها. يتم إصدارها بسرعة وتحتوي فقط على بضع إصلاحاتٍ لثغراتٍ موجودة تم اكتشافها مؤخرًا. تكون هذه التحديثات عادةً على شاكلة أرقام الإصدارات مثل 4.2.1. تحديثات الترقيعات أكبر قليلًا، لا تحتوي هي الأخرى على مميزاتٍ جديدة، ولكنّها تقوم بتحديث النظام وعادةً ما تتضمن تحديثاتٍ أمنية كذلك، كما أنّه يتم إصدارها بصفة دورية ومن الممكن توقّع وقت صدور الترقيع الجديد. وأمّا عن التحديثات الرئيسية من الانتقال من الإصدار 3.9 إلى الإصدار 4.0 فهذا تحديثٌ جوهري، يحتوي مميزاتٍ جديدة وإصلاحاتٍ للمشاكل الأمنية المعروفة بالإضافة لأمورٍ أخرى، كما أنّه يتم التدوين عنها في مدونة ووردبريس وفي العديد من المواقع الإخبارية الأخرى، حيث أنّها تحديثات كبيرة ويجب على الجميع معرفتها. قد تقوم هذه التحديثات أحيانًا بتحطيم شكل موقعك بسبب عدم توافقية مع القالب الذي تستخدمه مثلًا، ولكن مع وجود نسخة احتياطية من موقعك، فيجب ألّا تكون مشكلةً بالنسبة لك. الفشل بالتحديث يعني مشكلة أعظم كما ذكرنا سابقًا، عدم قيامك / فشلك بتحديث أيّ إضافات أو قوالب ووردبريس مثبّتة على موقعك قد يعرّضك لخطرٍ كبير، وما قد لا تفهمه هو "لماذا"؟ يمكن قول نفس الأمر بخصوص القوالب والإضافات، صحيحٌ أنّها ليست جزءً من لبّ نواة ووردبريس، ولكنّها أيضًا قد تحتوي على ثغرات تمكّن المخترقين من استغلالها لاختراق موقعك، وأيضًا يتم اكتشاف هذه الثغرات كلّ فترة وتصدر تحديثات لترقيعها كلّ فترة، وعليك تثبيتها بمجرّد توفّرها. بعض السمات والقوالب تكون مبرمجة بصورة سيئة ويكون بها العديد من الثغرات ويجب عليك الانتباه إلى ذلك، كما يجب عليك تثبيت واستخدام القوالب والإضافات التي تستعملها فقط وحذف كلّ شيء لا تستعمله. إدارة تحديثات ووردبريس أفضل طريقة للتأكّد من أنّ كلّ شيء على موقعك محدّث هو جعل عملية التحقق من وجود تحديثات متوفّرة هي مهمّة روتينية أخرى على جدولك (لو لم تكن تقنيًا، فيجب عليك البحث عن استضافة تقوم تلقائيًا بتحديث جميع القوالب والإضافات والنواة الخاصّة بووردبريس)، يجب عليك التحقق من توفّر التحديثات بنفسك كلّ يوم لتجنّب أي مشاكل أمنية قد تحصل. منذ الإصدار 3.7 من ووردبريس فإنّ المنصة تسمح بالتحديث التلقائي بسهولة، بمجرّد تفعيل هذا الخيار، فإنّه هذا يعني أنّ نواة موقعك ستقوم بالتحديث تلقائيًا عند توفّر تحديثات جديدة بدون أيّ تدخّل منك. طبعًا لا يمكن فعل نفس الشيء بالنسبة للقوالب والإضافات، حيث يجب عليك القيام بتحديثها يدويًا. الخاتمة تحديثات ووردبريس مهمّة للغاية، بل ومهمّة جدًا، ومن واجبك الاهتمام بتحديث كلّ شيءٍ موجود على موقعك إلى الإصدارات الأخيرة المتوفّرة، وإلّا فإنك تترك بابك مفتوحًا للمخترقين ليخترقوك، إنّها مسألة وقت. ترجمة -وبتصرف- للمقال: The WordPress Developer’s Guide to Security: Updates لصاحبه: Brenda Barron.

يفترض هذا الدرس أنّك قد قمتَ بالفعل بإنشاء خادوم افتراضي خاصّ (VPS) وإضافة العديد من حسابات المستخدمين إليه. يتم تطبيق نظام الحصص (Quotas) في غالب الأحيان على مستخدمي FTP أو SFTP، ولكن من الممكن أيضًا تطبيقه على أيّ مستخدم على النظام. لاحظ أنّه من غير الممكن استخدام ميّزة المستخدم الوهمي (virtual user) عبر VSFTP، لأنّ المستخدمين لا يجب أن يكونوا موجودين على النظام أصلًا. يتم استخدام الحصص لتقييد المساحة التي يمكن لمستخدم أو مجموعة أن يستخدمها على الخادوم. هناك عادةً طريقتان لإدارة الحصص: الأولى عبر إنشاء نظام ملفّاتٍ فارغ خاصّ بمستخدمٍ معيّن ومن ثمَّ ضمّه (mount) إلى النظام. ميّزة هذه الطريقة هي أنّك لا تحتاج تثبيت أيّ حزمة إضافية خارجية. والطريقة الثانية هي عبر استخدام أداة لإدارة الحصص وتنظيمها. ميّزة هذه الطريقة هي إمكانية تغيير الحصص بسهولة بدون الحاجة إلى القيام بأيّ تغييراتٍ معقّدة على نظام الملفّات. تثبيت Quotaسنبدأ العملية عبر تثبيت برنامج quota: apt-get install quotaيجب أن يتم تعديل خيارات الضمّ (mount) الخاصّة بنظام الملفّات قبل أن نتمكّن من استخدام الحصص. يجب أن نفتح ملفّ fstab ونقوم بتعديله عبر الأمر التالي: sudo nano /etc/fstabيتم تفعيل الحصص عبر إضافة usrquota و/أو grpquota إلى خيارات الضمّ للقرص الصلب الرئيسي. عند استخدام usrquota، فإنّه سيتم تفعيل الحصص على مستخدمين معيّنين فقط، بينما يسمح خيار grpquota بتفعيل نظام الحصص لمجموعات معيّنة. يمكن إضافة الخيارين بشكلٍ منفصل بناء على النتيجة التي تريد الوصول إليها. يجب أن يتم تعديل ملفّ fstab كالتالي لتفعيل نظام الحصص على حسابات المستخدمين (إذا كنتَ تريد تفعيل نظام الحصص على المجموعات، فقم بإضافة grpquota): LABEL=DOROOT / ext4 errors=remount-ro,usrquota 0 1احفظ الملفّ وقم بتفعيل خيارات الضمّ الجديدة عبر إعادة ضمّ نظام الملفّات بالأمر: mount -o remount /سيقوم الأمر التالي بإنشاء ملفّ حصص جديد في مسار الجذر الخاصّ بنظام الملفّات. سيكون هذا الملفّ عبارةً عن ملف فهرس يتم استخدامه بواسطة نظام الحصص لإدارة حجم حصّة كلّ مستخدم من مساحة القرص. يحتوي الملفّ أيضًا على تقييدات المستخدمين والإعدادات المضبوطة. quotacheck -cum /يتألّف الأمر من المُعامِلات الثلاثة التالية: يقوم المُعامِل c بالإشارة إلى ضرورة إنشاء ملفٍّ جديد، وسيقوم بالكتابة فوقه في حال كان موجودًا مسبقًا.يشير المُعامِل u إلى أنّه يجب إنشاء ملفّ فهرس جديد للمستخدمين. لإنشاء ملفّ فهرس للمجموعات كذلك، قم بإضافة المُعامِل g في الأمر السابق.وأخيرًا يحدد المُعامِل m أنّه ليس هناك حاجة إلى القيام بعمليّة ضمّ بوضع القراءة فقط لنظام الملفّات بأكمله لإنشاء ملفّات الفهارس.بسبب استخدام المُعامِل m، فإنّه من الممكن أن يحصل عدم تطابق صغير بين الحجم الذي قمتَ بتحديده لحصّة مساحة المستخدم وبين الحجم الذي سيتم استخدامه بالفعل من قبل برنامج quota. تأكّد من أنّه لا يوجد مستخدم يقوم حاليًا برفع الملفّات إلى الخادوم عند تطبيق الأمر السابق لتقليل حجم الفرق. يقوم الأمر التالي بتفعيل نظام الحصص على نظام الملفّات المطلوب: quotaon /يمكن استخدام أمرٍ مشابه لتعطيل نظام الحصص بأكمله: quotaoffإعداد الحصص المختلفة لحسابات المستخدمينيمكن إعداد الحصص باستخدام الأمر edquota متبوعًا باسم المستخدم أو اسم المجموعة. سيقوم الأمر بفتح محرر الملفّات الافتراضي، في درسنا هذا، سنفترض أنّ المستخدم ftpuser يجب أن يتم تخصيص مساحة 10ميغابت له. الأمر الذي سنستخدمه هو هذا: edquota ftpuserوالذي سيقوم بفتح الملفّ للتعديل: Disk quotas for user ftpuser (uid 1001): Filesystem blocks soft hard inodes soft hard /dev/disk/by-label/DOROOT 8 10000 10240 2 0 0يعرض محرر النصوص 7 أعمدة مختلفة: يحدد اسم نظام الملفّات الذي تمّ تفعيل نظام الحصص عليه.يحدد حجم الكُتَل (Blocks) المُستخدمة حاليًا من قبل المستخدم.يحدد حدّ soft block للمستخدم على نظام الملفّات.يحدد حدّ hard block للمستخدم على نظام الملفّات.يحدد عدد عُقَد inodes المُستخدمة حاليًا بواسطة المستخدم.يحدد حدّ soft inode للمستخدم على نظام الملفّات.يحدد حدّ hard inode للمستخدم على نظام الملفّات.تشير الكُتَل (Blocks) إلى حجم المساحة التي يجب استخدامها، بينما تشير الـinodes إلى عدد الملفّات/المجلّدات التي يمكن استخدامها. عادةً ما يتم استخدام حجم الكتلة في برنامج quota. حدّ hard block هو المساحة القصوى من القرص الصلب التي يمكن لمستخدم أو مجموعة استخدامها. بمجرّد الوصول إلى هذا الحدّ، فلن يتم استخدام أيّ مساحة إضافية من على القرص الصلب. يُعرِِّف حدّ soft block أيضًا أقصى مساحة يمكن للمستخدم أو المجموعة استخدامها، إلّا أنّه وعلى عكس hard block، فإنّه يمكن للمستخدم أن يقوم بتخطّي الحدّ الأقصى المسموح لفترة معيّنة من الزمن فقط، تعرف هذه الفترة باسم فترة المهلة (grace period). سنتعرّف على المزيد من المعلومات عنها لاحقًا في هذا الدرس. في المثال أعلاه، استخدمنا الحدّ الناعم (soft limit) بمساحة 9,785Mb والحدّ الصلب (hard limit) بمساحة 10Mb. يمكنك القيام ببدء عملية نقل ملفّات عبر برتوكول FTP/SFTP، حيث يكون الملفّات المرفوعة بحجم 12Mb مثلًا(طالما يكون حجمها أكبر من الحدّ الصلب hard limit). سيتم إرجاع رسالة خطأ إليك من طرف برنامج عميل FTP/SFTP تخبرك بأنّ عملية الرفع قد فشلت. بالطبع فإنّ تخصيص مساحة 10Mb للمستخدم ليس أمرًا منطقيًا، وسنخصص الآن حدًّا ناعمًا بمساحة 976Mb وحدًّا صلبًا بمساحة 1Gb: Disk quotas for user ftpuser (uid 1001): Filesystem blocks soft hard inodes soft hard /dev/disk/by-label/DOROOT 8 1000000 1048576 2 0 0للتحقق من حصّة مستخدم معيّن، يمكن أن يتم تنفيذ الأمر التالي متبوعًا باسم المستخدم أو اسم المجموعة: quota ftpuserوسيكون الخرج على شكل: Disk quotas for user ftpuser (uid 1001): Filesystem blocks soft hard inodes soft hard /dev/disk/by-label/DOROOT 8 1000000 1048576 2 0 0إنشاء التقاريرمن الممكن إنشاء التقارير من مختلف أنظمة الحصص عبر الأمر: repquota -aوالذي سيقوم بطباعة الخرج التالي لك: *** Report for user quotas on device /dev/disk/by-label/DOROOT Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ------------------------------------------------------------------------------------ root -- 1118708 0 0 37093 0 0 daemon -- 68 0 0 4 0 0 man -- 9568 0 0 139 0 0 www-data -- 2908 0 0 15 0 0 nobody -- 0 0 0 1 0 0 libuuid -- 24 0 0 2 0 0 Debian-exim -- 44 0 0 10 0 0 mysql -- 30116 0 0 141 0 0 ftpuser -- 8 1000000 1048576 2 0 0فرعي: تحديد فترة مهلةلإعطاء المستخدمين الحاليين بعض الوقت لتقليل مساحة ملفّاتهم على الخادوم، يمكن إعداد فترة مهلة (grace period). تسمح هذه الفترة للمستخدمين بأن يتعدّوا الحدّ الناعم (soft limit) المحدد لهم بينما يبقون تحت سقف الحدّ الصلب (hard limit). يمكن إعداد فترة المهلة عن طريق الأمر التالي (لاحظ أنّ هذه الفترة سيتم تطبيقها على جميع المستخدمين، لا يوجد إمكانية لتطبيقها على مستخدمين معيّنين مثلًا) ويمكنك التعبير عن الفترة التي تريدها بالثواني أو الدقائق أو الساعات أو الشهور.. إلخ: edquota -tسيعطيك الأمر أعلاه الخرج التالي وسيقوم بإخبارك بالوقت الذي يمكنك أن تستخدمه. في هذا الدرس، تمّ استخدام فترة 7 أيام لفترة المهلة: Grace period before enforcing soft limits for users: Time units may be: days, hours, minutes, or seconds Filesystem Block grace period Inode grace period /dev/disk/by-label/DOROOT 7days 7daysخاتمةسيتم تحديث وتطبيق الحصص تلقائيًا عندما يقوم مستخدمٌ ما بإنشاء / حذف / نقل ملفّ أو مجلّد. تذكّر أنّ برنامج quota يعمل عبر النظر إلى مجلّدات المستخدمين أو المجموعات المحددة. يمكن لمستخدمي SSH التخلّص من نظام الحصص عبر تغيير مالك الملفّات الخاصّة بهم. ترجمة -وبتصرف- للمقال: How To Enable User and Group Quotas لصاحبه: Jan Stevens.

تستغل هجمات حقن SQL البرمجة السيئة للشفرة الخاصّة بالبرمجيات. إنّها هجمات حيث يقوم المهاجمون بإرسال شفرة عبر واحدٍ من مربّعات الإدخال الموجودة على موقعك (أيّ مربّع)، عوضًا عن أن يرسل بياناتٍ عادية كنتَ تنوي استقبالها عبر مربّعات الإدخال تلك. تقوم تلك الشفرة المُدخلة بتنفيذ عمليات الاستعلام على قاعدة البيانات الخاصّة بموقعك بطريقةٍ لم تكن تتوقعها، أو تقوم بتحطيم تطبيق الويب الخاصّ بك وتقوم بتخريب خادومك السحابي. م السهل جدًا عمل هجمات حقن SQL ضدّ المواقع الغير مؤمّنة. وحراسة موقعك ضدّ هذه الهجمات قد يكون من أهمّ ما تقوم به منذ اليوم الأوّل. الخطوة الأولى: تعلم تمييز الشفرة المحتوية على ثغرات تأخذ هجمات SQL دومًا شكل سلسلة نصّية يتم إرسالها من طرف مستخدمٍ تتكون من قسمين. القسم الأول هو عبارة عن تخمين لكيفية تعطيل أمرٍ تحاول شفرتك المصدرية أن تقوم بتنفيذه بأمان; القسم الثاني هو الشفرة الخبيثة التي يريد المهاجم تنفيذها على خادومك. إليك مثالًا على سلسلة نصّية مصممة لاستغلال ثغرة ممكنة في الشفرة المصدرية لديك: x' AND user.email IS NULL; -- يبدو هذا كشيء قمتَ بكتابته بنفسك، وتلك هي النقطة. يأمل المستخدم المُخترِق أن تقوم بأخذ هذا السطر، وتقوم بتنفيذه بعملية استعلام SQL تبدو كالتالي: SELECT email, passwd FROM user WHERE email = 'x' AND user.email IS NULL; --'; لا يبدو أنّ هذا يقوم بالكثير حقًا، ولكن اعتمادًا على الطريقة التي سيستجيب بها تطبيقك إلى ما سبق، يمكن أن يوفّر هذا بعض المعلومات المهمّة للمُخترِق مثل اسم جدول قاعدة البيانات الذي تستعمله. بعد هذا، هناك المزيد من الهجمات التي يمكن للمهاجم أن يستخدمها لجلب المزيد من المعلومات، مثل أسماء المستخدمين وكلمات المرور. الفكرة الرئيسية التي يجب عليك فهمها هي أنّ الشفرة الخبيثة تحاول البحث عن ثغرة بعملية استعلام SQL التي يقوم بها تطبيقك لمحاولة استغلالها لجلب المعلومات أو إدراجها وتعديلها. لا تتطلب جميع هجمات حقن SQL إشارة الاقتباس المغلقة ('). إذا كانت شفرتك المصدرية تنفّذ عملية استعلامٍ متعلّقة برقم، فإنّك لن تقوم بالطبع بوضع تلك البيانات داخل إشارة اقتباس. وهذا يتركك عرضةً لهذا النوع من الهجمات: 2097 OR 1=1 يأمل المهاجم أن يقوم تطبيقك بعملية استعلام مشابهة للتالي: SELECT somedata FROM yourtable WHERE userid = 2097 OR 1=1; غالبًا ما تكون شفرتك البرمجية مصممة لتقوم بعملية الاستعلام السابقة لتعيد البيانات فقط في حال تطابق الـ userid مع المستخدم الصحيح. ولكنّ حقنة الـSQL تجعل عملية الاستعلام تقوم دومًا بإرجاع البيانات. النقطة ليست في سلوكٍ معيّن لأيّ حقنة SQL. الشيء الأكثر أهمّية من هذا كلّه هو القاعدة العامّة لجميع حقن SQL: محاولة لتخمين كيفية حذف جزء معيّن من عملية استعلام، وإضافة جزءٍ آخر إليها لم تكن تتوقعه. هذا هو توقيع جميع هجمات حقن SQL. وهذه هي طريقة محاربتها. الخطوة الثانية: اعثر على مدخلاتك أفضل طريقة لتعقّب جميع نقط إدخال حقن SQL الممكنة في شفرتك البرمجية ليس عبر النظر إلى حقول إدخال HTML. بالطبع يمكنك العثور على العديد من الثغرات الممكنة هناك، ولكن هناك طرقٌ أخرى يمكن من خلالها للمستخدم أن يقوم بإدخال البيانات، مثل عنوان الويب (URL)، أو عبر واحدةٍ من واجهات AJAX الخاصّة بك. أفضل مكان للبحث فيه عن الثغرات هو الشيء الذي يريد المخترقون اختراقه بنفسه; جملة استعلام SQL بنفسها. على الأغلب، فإنّك تقوم بتنفيذ جميع عمليات الاستعلام عن طريق الأمر الأساسي نفسه، وربّما أمران آخران أو أكثر قليلًا. فقط ابحث عن هذه الأوامر في شفرتك البرمجية وستجد جميع الثغرات الممكنة بشكلٍ سريع. كمثال، إذا كانت شفرتك البرمجية مكتوبة بـPerl، فإنّ جميع عمليات استعلام SQL الخاصّة بك ستبدو هكذا: $result = mysql_query($sql) في تلك الحالة، يمكنك العثور بسرعة على جميع الثغرات الممكنة بواسطة سطر الأوامر، عبر استخدام أمر شبيه بالتالي: $ grep -R mysql_query * الخطوة الثالثة: نظف مدخلاتك هناك العديد من التقنيات التي يستخدمها الناس لمنع هجمات حقن SQL، ولكن خطّ دفاعك الأمامي يجب أن يكون تنظيف جميع مُدخلات المستخدم من أيّ شفرة خبيثة مشبوهة. يجب ألّا تعتقد بتاتًا أنّ المستخدم سيقوم بإدخال البيانات بالطريقة التي تريدها. في الواقع، يجب عليك أن تفترض العكس - أنّهم سيقومون بإدخال الشفرات الخبيثة في كلّ مكانٍ ممكن في موقعك. تنظيف المُدخلات يعني أنّه يجب اختبار جميع مُدخلات المستخدم للتأكّد من أنّها تحتوي فقط مُدخلات آمنة، مُدخلات لا يمكن استخدامها بتاتًا في شنّ هجوم. المُدخلات التي سيتم إدخالها من طرف المستخدم إلى خادوم SQL الخاصّ بك ستكون على شكلَين: كرقم، مثل 2097. كسلسلة (string)، مثل اسم المستخدم، كلمة المرور أو البريد الإلكتروني. تتوقّع شفرتك البرمجية دومًا مُدخَلًا واحدًا من هذين الشكلين. في الأمثلة التي ذكرناها ببداية هذا المقال، كان المثال الأوّل عبارة عن سلسلة نصّية، وكان المثال الثاني عبارةً عن رقم. هناك أيضًا طريقتان لتنظيف البيانات: طريقة جيدة وطريقة سيئة. الطريقة السيئة هي التحقق من وجود حقن SQL الممكنة. السبب في كونها سيئة هو لأنّ عدد حقن SQL الممكن كبير جدًا، و"إبداع" المهاجمين واسع كذلك. الطريقة الجيّدة هي تنظيف البيانات للتعرّف على ما يبدو شكل الإدخال الصحيح عليه، وتجاهل كلّ شيء لا يتوافق مع شكل ذلك الإدخال الصحيح. البيانات الرقمية هي الأسهل للتنظيف، لذا سنقوم بتغطية هذا أوّلًا. يمكن للرقم أن يحتوي على إشارة سالبة على يساره، أو أن يكون متبوعا بأرقام أخرى، وربّما يحتوي على فاصلة عشرية. هذا كلّ ما يمكن للبيانات الرقمية أن تبدو عليه، في Perl، ستبدو الشفرة التي تتحقق من البيانات الرقمية كالتالي: if($numericaluserinput !~ /^-?[0-9.]+$/) { # البيانات المُدخلة ليست رقمًا } من الصعب تخيّل أيّ حقنة خبيثة يمكنها أن تتخطى ما سبق. تنظيف المُدخلات النصّية أكثر صعوبة، لأنّه هناك العديد من الطرق لمحاولة إدخالها. يمكن للمهاجم أن يستخدم إشارات الاقتباس وغيرها بطرق "إبداعية" للقيام بالهجمات. في الواقع، محاولة إنشاء قائمة سوداء للحروف المُدخلة هو أمرٌ سيّء، لأنّه من السهل نسيان شيء مهم مثلًا. هناك طريقة أفضل، كما قمنا مع البيانات الرقمية، وهي تقييد مُدخلات المستخدم إلى قائمة بيضاء من الحروف فقط. كمثال، عناوين البريد الإلكتروني لا يجب أن تحتوي على شيء سوى الأرقام والحروف العادية وبعض الإشارات مثل @ و _ وعدا ذلك، يجب منع كلّ الحروف الأخرى. في لغة Perl، ستبدو الشفرة كالتالي: if($useremail ~= /^[0-9a-zA-Z\-_+.\@]$/) { # the user's email address is unacceptable } يمكن العثور على قوائم بيضاء للأنواع الأخرى من المُدخلات كذلك مثل اسم المستخدم وكلمة المرور.. إلخ. قد تكون القوائم البيضاء مصدر إزعاج لبعض المستخدمين. فربّما يكون هناك رموز معيّنة في بعض مربّعات الإدخال تكون غير مقبولة من طرفها مثلًا، ولكنّك بالطبع حرّ لتقوم بتعديل القوائم البيضاء حسب حاجتك، ولكن لا تنسى أن تقوم ببحث عن الرموز والمحارف التي تريد تمكينها للتأكّد من أنّه لا يمكن استخدامها في حقن SQL، فعندما تختار بين حماية الموقع وراحة المستخدم، حماية الموقع تأتي أوّلًا. تنظيف المُدخلات بواسطة القوائم البيضاء جيّد لأنّه سهل. إذا كنتَ مُدركًا بشكل صحيح للرموز والمحارف التي تقوم بتمكينها، فحينها سيكون هذا الحلّ كافيًا للتخليص من هجمات حقن SQL. الخطوة الرابعة: قبول المدخلات الخطيرة لا تنخدع بالعنوان! سنتحدّث فقط عن أهمّية عدم قبول المُدخلات الخطيرة. صحيحٌ أنّ القوائم البيضاء شديدة التقييد جيّدة من أجل الحماية في حال ما إذا كان تطبيقك يستطيع أن يتوافق مع تلك التقييدات على المستخدمين. ولكن في بعض الحالات، قد يكون من المهمّ لنموذجك الربحي الخاصّ بالتطبيق ألّا تقوم بفرض أيّ تقييدات على مُدخلات المستخدمين. في هذه الحالة، غالبًا ما تكون لغة البرمجة التي تستعملها في تطبيقك تحوي على مكتباتٍ تساعدك في تنظيف مُدخلات المستخدمين من الشفرات الخبيثة. كمثال، مكتبة Perl DBI تحوي طُرقًا متعددة لمنع مُدخلات المستخدمين من التعامل مع استعلام SQL بخارج المنطقة المخصصة لها: my $sql = "INSERT INTO user (username, email) VALUES (?, ?)"; my $handle = $dbh->prepare( $sql ); $handle->execute( $untrustedusername, $untrustedemail); في المثال السابق، تمّ استخدام إشارة ؟ كعناصر نائبة (placeholders). تقوم مكتبة Perl DBI باستبدال هذه الإشارات بالمتغيّرات الغير موثوقة والتي تمّ إدخالها من طرف المستخدم. ولكن أثناء القيام بهذا، تقوم مكتبة DBI بتقييد هذه المتغيرات وتجعلها تتعامل فقط مع الحقول المخصصة لها بجدول قاعدة البيانات. هناك مكتبات مشابهة باللغات البرمجية الأخرى، إمّا لتقييد مُدخلات المستخدم، أو لتجاهل البيانات في حال حاولت التعامل مع خارج الحقل المخصص لها. ميّزة هذه التقنية هي أنّك قادرٌ على إعطاء ثقتك بالأشخاص المطورين لتلك المكتبات، حيث أنّهم سيقومون بتطويرها، والحفاظ عليها بعيدة عن الثغرات الأمنية والمشاكل الخطيرة. ولكن عيب هذه التقنية هي أنّها أقل قابلية للقراءة البشرية، وهكذا ربّما تنسى استخدام المكتبة الصحيحة لحماية بعض من عمليات استعلام SQL الخاصّة بك. الخطوة الخامسة: خفف ضرر الهجمات الناجحة اعتمادًا على ماهيّة نموذج الأعمال الذي تقوم به بموقعك، فربّما تودّ القيام بإنشاء خطٍّ أخير للدفاع، شيء مستقل تمامًا عن مطوري تطبيقك. فبعد كلّ شيء، ربّما يستخدم واحدٌ منهم القوائم البيضاء الخاطئة في مكان ما، أو فشل باستخدام المكتبة الصحيحة لتنظيف المُدخلات. ثغرة واحدة فقط من هذا النوع قد تسبب في تحويل موقعك بأكمله إلى موقع قابل للاختراق عبر هجمات SQL. أولًا، يجب عليك أن تفترض أنّ المهاجمين نجحوا باختراق دفاعاتك ضدّ حقن SQL، وأنّهم حصلوا على الصلاحيات الكاملة لإدارة خادومك. إنهم يملكون الآلة الآن بالكامل، على الرغم من أنّك من يهتم بصيانتها وتطويرها. لتجنّب ذلك السقوط المروع، يجب على الخادوم نفسه أن يكون مضبوطًا داخل بيئة معزولة عن الشبكة، حيث يكون مستخدم الجذر على النظام غير قادر على الرؤية أو الوصول إلى أيّ أجزاء أخرى موجودة على خادومك. هذا النوع من الدفاع يدعى DMZ، وهو رائع للغاية، وهو كذلك خارج نطاق هذا الدرس. مهما كانت الطريقة التي تستخدمها لتأمين خادومك ضدّ مستخدم مهاجم نجح بالدخول بالفعل، فإنّه يجب عليك أن تقوم بإعداد نظام تنبيهات يقوم بإخطار مدراء النظام في حال حصول نشاط معيّن على الخادوم. هذه التنبيهات ستخبرك ما إذا تمّ اختراق التطبيق، وأنّه عليك عمل مراجعة سريع للشفرة البرمجية وللخادوم نفسه. دون هذه التنبيهات، سيكون المهاجم قادرًا على قضاء وقتٍ ممتع في محاولة اختراق الـDMZ الخاصّ بك دون أن تشعر، وربّما لا تشعر بتاتًا بما يفعله إلى حين أن يسرق جميع البطاقات الائتمانية التي ظننت أنّها كانت معزولة تمامًا عن الخادوم، في بيئةً كنت تظن أنّها منفصلة عن خادومك الرئيسي. الخطوة السادسة: وظف محترف حماية إذا كنتَ تقوم بإدارة تطبيق ويب دون الاستعانة بخبير حماية، فحينها أنت تسبح بالمياه الخطيرة. وإذا كنت ولسبب ما غير قادر على توظيف خبير حماية وأمان، فإنّه يجب عليك الاستعانة بالقوائم البيضاء لتنظيف مُدخلات المستخدمين إلى حين. من السهل تضمين واستخدام القوائم البيضاء. لا بأس من تقييد تجرية المستخدمين قليلًا في سبيل حماية خادومك والبيانات الثمينة الموجودة عليه. وبمجرّد أن تقوم بتوظيف شخص يفهم في مجال الحماية والأمان، فستكون بعدها قادرًا بشكل أفضل على حماية موقعك من هجمات حقن SQL و XSS وغيرها من الهجمات الخطيرة التي قد تصيب موقعك. ترجمة -وبتصرف- للمقال: How To Secure a Cloud Server Against SQL Injection.

تحدثنا في السابق عن بضع خطوات يمكنك تطبيقها لزيادة أمان وحماية موقعك العامل بسكربت ووردبريس الشهير. صحيحٌ أنّ نواة ووردبريس آمنة للغاية، ولكن يجب عليك تثبيت عدّة إضافات وملحقات إضافية لزيادة مستوى أمان موقعك. سنتحدّث في هذا الدرس عن أهم إضافات الأمان والنسخ الاحتياطي التي يمكنك تثبيتها وتفعيلها على سكربت ووردبريس الشهير. لماذا قد أحتاج إضافة للحماية؟ بشكلٍ عام، تقوم إضافات الحماية والأمان بتوفير طبقة إضافية من الحماية ضدّ هجمات Bruteforce والهجمات الأخرى والبرمجيات الخبيثة التي قد تصيب موقعك، يمكنها أيضًا أن توفّر لك عدّة أدوات يمكنك استخدامها لتقليل المخاطر الأمنية المحيطة بك، كما توفّر بعض الأدوات للمراجعات اليدوية الدورية أيضًا. هناك إضافات أخرى للنسخ الاحتياطي تمكّنك من استرجاع موقعك بسرعة في حال ما إذا تمّ اختراقه. لهذا، سنتطرّق الآن إلى أهم الإضافات للحماية والأمان والنسخ الاحتياطي التي يمكنك استخدامها. iThemes Security تعتبر هذه الإضافة شهيرةً جدًا عندما يتعلّق الأمر بمجال أمان ووردبريس. كانت هذه الإضافة تدعى بالسابق "WP Security" ولكن تمّ تغيير اسمها. توفّر لك هذه الإضافة عدّة طرق لحماية موقعك. في الواقع، تقوم إضافة iThemes Security بالعديد من الأمور التي ذكرناها بالدروس السابقة تلقائيًا، مثل تغيير اسم المستخدم الرئيسي ورابط صفحة تسجيل الدخول، إزالة وسم generator والمزيد. كما تعرض عدّة أدوات للحماية مثل فحوصاتٍ دورية لملفّات موقعك للبحث عن الثغرات الأمنية والملفّات الخبيثة إن وجدت، مما يحسّن من أمان موقعك، كما أنّها تقوم بحظر المستخدمين الذين يفشلون بتسجيل الدخول لأكثر من مرّة عن طريق الـIP، وتحظر ربوتات الاختراق الشهيرة، وتفرض على المستخدمين اختيار كلمات مرورٍ قويّة.. والمزيد. توفّر إضافة iThemes Security ميزات التنبيه، حيث يمكنها أن تقوم بتنبيهك عندما يتم إجراء تغييراتٍ ما دون صلاحيات. يمكنها أن تلتقط الروبوتات التي تحاول اختراقك ويمكنها أن ترسل رسالة بريدٍ إلكتروني في حال التقطت أيًّا منها. توفّر الإضافة ميّزة النسخ الاحتياطي كذلك، حيث أنّها قادرة على أخذ نسخة احتياطية من جميع ملفّات موقعك وتدويناتك التي نشرتها، ويمكنها استعادتها في أيّ وقتٍ تريده. هناك إصدارٌ مدفوع من الإضافة كذلك ويوفّر ميّزاتٍ أكثر. All in One WP Security & Firewall خيارٌ آخر متوفّر أمامك هو إضافة All in One WP Security & Firewall، تتميز هذه الإضافة بسهولة تثبيتها وإعدادها مما يجعلها خيارًا جيَدًا للمدونين الجدد. تتضمن أيضًا نظام تقييم للحماية يحدد لك مدى أمان موقعك بوضعه الحالي. يمكنك من هناك تفعيل أو تعطيل مميزاتٍ معيّنة للأمان والحماية في موقعك حسبما تريده. تسمح لك هذه الإضافة المجانية كذلك بإعداد العديد من إجراءات الحماية بمجرّد بضع ضغطات، مثل تغيير اسم المستخدم "admin"، التعرّف على المستخدمين الذين يمتلكون أكثر من حساب وتفعيل أداة تقوية كلمات المرور. كما تحتوي الإضافة على ميزة تمنع هجمات Bruteforce على موقعك عبر حظر محاولات تسجيل الدخول الفاشلة لأكثر من مرّة. يمكنك أيضًا فرض تسجيل الخروج على حسابٍ معيّن، تتبع سجل النشاط الخاصّ به والمزيد. تتضمن الإضافة أيضًا مزايا حماية قواعد البيانات والملفّات، بالإضافة إلى إمكانية إنشاء ملفّ htaccess. عبرها وعمل النسخ الاحتياطية لملفّ wp-config.php. هناك ميزة أخرى مهمّة بهذه الإضافة وهي ميّزة الجدار الناري، حيث تسمح لك بتعديل ملفّ htaccess. لتمنع المخترقين حتّى من الوصول إلى الشفرة الخاصّة بموقعك. كما أنّها تحتوي على فاحص ملفّات، الحماية من نسخ النصوص، حماية ضد هجمات السخام (Spam)، تحديثات تلقائية والمزيد. Sucuri Security Sucuri Security هي إضافة أخرى شائعة لحماية ووردبريس. تسمح لك ميزة SiteCheck المُضمّنة بالتحقق من حالة موقعك الحالية وفحصه لإيجاد الثغرات الموجودة به بالإضافة للبحث عن البرمجيات الخبيثة إن وجدت. تمكّنك الميزة كذلك من البحث عن جميع أنواع الثغرات، مثل ثغرات حقن قواعد البيانات، محاولات التصيّد الاحتيالي، إعادة التوجيه المشبوهة.. إلخ، كما يمكنها أن تلتقط أكواد جافاسكربت وPHP الخبيثة إن وجدت. تستخدم الإضافة أكثر من واجهة تطبيق برمجية واحدة (API) لفحص موقعك، أيّ أنّها تستخدم أكثر من قاعدة بيانات للشفرات الضارّة والخبيثة الموجودة على الإنترنت للتأكد من أنّ موقعك لا يحتوي على أحدها، مما يوفّر فحصًا شاملًا لموقعك، تتضمن هذه المصادر الخارجية أسماءً عريقة مثل Norton, McAfee.. إلخ. هناك بعض المزايا الموجودة بالإضافة والتي توفّر الحماية لمسار رفع ملفّات الوسائط الخاصّ بموقعك، حيث تقيّد الوصول إلى مجلّديّ wp-content وwp-includes، تتحقق من إصدارات PHP ووردبريس وتعطّل محرر الإضافات والقوالب من لوحة التحكم. Wordfence Security تحدّثنا من قبل عن إضافة Wordfence Security، وقلنا أنّها من أهم إضافات الحماية لسكربت ووردبريس. بمجرّد تثبيتها على موقعك فإنّها ستقوم بعملية فحصٍ شامل للشفرة المصدرية للتأكّد من أنّها مطابقة للشفرة المصدرية الخامّة المنشورة من موقع ووردبريس الرئيسي، إذا اكتمل الفحص بنجاح، فإنّ الإضافة تقوم بعدها تلقائيا بتفعيل خيارات الحماية لزيادة أمان موقعك. هناك إصدار مدفوع ومجاني من الإضافة، كلاهما يعتمدان على منصّة "Wordfence Cloud"، مما يعني أنّ عملية الفحص وتفعيل الجدار الناري بالواقع تجريان على خواديم الشركة المطوّرة للاستضافة وليس على خادومك مما يقلل من الحمل الموجود عليه. توفّر هذه الإضافة دعمًا لأكثر من موقع ووردبريس في آنٍ واحد، تسجيل الدخول عبر الهاتف المحمول، دعم للإضافات الشهيرة مثل WooCommerce، الاستيثاق الثنائي، فرض كلمات المرور القوية، فحص الملفّات والمزيد. تتضمن الإضافة أيضًا جدارًا ناريًا لحماية موقعك من الروبوتات، البرمجيات الخبيثة وهجمات Bruteforce. بمجرّد تثبيتها فإنك ستكون قادرًا على حظر المهاجمين واتصالات الشبكات المشبوهة، وكلّه في الوقت الحقيقي (Real time). BruteProtect تمّ شراؤها مؤخرًا من قبل شركة Automattic (الشركة المطوّرة لووردبريس)، إضافة BruteProtect هي أحد الحلول الأمنية التي يمكنك استخدامها لصدّ هجمات Bruteforce بالتحديد. توفّر الإضافة أدواتٍ لمراقبة الهجمات الحالية على موقعك في حال حصولها بالوقت الحقيقي بالإضافة إلى التحديث التلقائي لنواة ووردبريس في موقعك. الإضافة ليست مجهّزة لحمايتك ضد الهجمات الأخرى، بل فقط ضدّ هجمات Bruteforce فلا تعتمد عليها لوحدها. Acunetix WP Security Acunetix WP Security هي إضافةٌ أخرى مجانية لفحص موقعك بسهولةٍ ويسر. تمكّنك من إعداد صلاحيات الملفّات، تأمين قاعدة البيانات، إخفاء إصدار ووردبريس الحالي الذي تستخدمه عن أعين المخترقين، تغيير اسم المستخدم admin والمزيد. تتوافق الإضافة مع مواقع ووردبريس المتعددة (multisite) وعمليات النسخ الاحتياطي، كما تتضمّن أداةً تعمل بالوقت الحقيقي لعرض من يتصفّح موقعك حاليًا وماذا يتصفّحون. Bulletproof Security آخر إضافة ووردبريس سنتحدث عنها هي إضافة Bulletproof Security. توفّر هذه الإضافة العديد من المزايا التي توفّرها الإضافات الأخرى مثل ملفّات htaccess. ، حفظ نسخة احتياطية من قاعدة البيانات، سمات مختلفة لواجهة الإضافة والمزيد. يتضمّن الإصدار المدفوع منها المزيد من المميزات مثل التثبيت بنقرة واحدة، الاستعادة التلقائية، جدار ناري يتعامل مع عناوين الـIP للمستخدمين، مسجّل للأخطاء، حامٍ من هجمات Bruteforce، حظر عناوين IP معيّنة والمزيد. أهمّية إضافات النسخ الاحتياطي بجانب إضافة قويّة للحماية والأمان، فإنّه يجب عليك استخدام إضافةٍ أخرى لعمليات النسخ الاحتياطي، معظم هذه الإضافات السابق ذكرها يتضمّن الميّزتين بالواقع مما يسهّل عليك الأمر، ولكن لا تنسى بتاتًا استخدام النسخ الاحتياطي. القيام دوريًا بعمل نُسخ احتياطية من موقعك هو أمرٌ مهم لخطّة أمان كاملة، وإلّا فكيف تتوقع أن تقوم باسترجاع موقعك في حال تمّ اختراقه مثلًا؟ هناك العديد من الإضافات الجيّدة للنسخ الاحتياطي مثل VaultPress ،WordPress Backup to Dropbox و BackupBuddy. تتنوّع هذه الإضافات ما بين المدفوعة والمجانية، ولكنّها مفيدة لضمان عدم فقدان أيّ شيء مهم يتعلّق بموقعك. الخاتمة صحيحٌ أنّه يمكنك القيام بالعديد من الأمور يدويًا لتحسين حماية ووردبريس، ولكن استخدام الإضافات قد يوفّر عليك الكثير من الوقت ويوفّر لك الكثير من المميزات، خاصةً لو كنتَ تمتلك أكثر من موقع ووردبريس واحد. الإضافات السابق ذكرها يجب أن تؤدّي المهمّة المطلوبة بالنسبة لك ويمكنك تجريبها جميعًا لتصل إلى أفضلٍ واحدةٍ منها بالنسبة لك. في الدرس الأخير من هذه السلسلة سنتحدث عن أهمية تحديث ووردبريس وإضافاته لزيادة أمان موقعك. ترجمة -وبتصرف- للمقال The WordPress Developer’s Guide to Security: Security & Backup Plugins لصاحبته Brenda Barron.

في الدرس السابق تحدثنا عن طرق تثبيت ووردبريس لأول مرة بأمان. في هذا الدرس، سنتحدّث عن كيفية تأمين موقع ووردبريس بعد تثبيته، سنتحدّث عن أساليب أفضل للحماية فوق مستوى نصائح "اختر كلمة مرور أكثر تعقيدًا" وسنحاول الغوص قليلًا في موضوع أمان ووردبريس. تقييد عمليات تسجيل الدخول واحدٌ من أول الأشياء التي يجب عليك فعلها لتأمين موقع ووردبريس الخاصّ بك هو تقييد عدد المرّات التي يمكن لشخصٍ ما أن يحاول تسجيل الدخول بها إلى الموقع. يحاول العديد من المخترقين القيام بهجمات التخمين أو ما يعرف بـ Bruteforce لمحاولة كسر اسم المستخدم / كلمة المرور الخاصّيَن بك، وحتّى لو لم تنجح هذه الهجمات في اختراق موقعك، فإنّه ستقوم باستهلاك جزء كبير من موارد خادومك وستقوم بوضع حملٍ عليه. عبر تقييد عمليات تسجيل الدخول، يمكنك منع المخترقين من محاولة القيام بهجمات Bruteforce. بمجرّد أن يقوم بمحاولة تخمين كلمة المرور مرتين أو ثلاث، فسيتم حظر عنوان الـIP الخاصّ به. يمكنك القيام بهذا الأمر بسهولة عبر تثبيت إصافة Limit Login Attempts، صحيحٌ أنّه لم يتم تحديثها منذ سنتين ولكنّها تمتلك مميزاتٍ رائعة، ولكن ربّما تودّ تجاهلها حاليًا بسبب انقطاع دعمها عن التحديثات الأمنية. عوضًا عن هذا، فإننا ننصح بإضافة Login Lockdown، تسمح لك هذه الإضافة أيضًا بتقييد عدد مرّات تسجيل الدخول الفاشلة قبل أن يتم حظر عنوان الـIP الخاصّ بالمستخدم الذي يحاول الدخول، كما يمكنك اختيار المدّة التي تريد حظر عنوان الـIP خلالها، ستصبح هجمات Bruteforce أصعب بكثير بعد تثبيت هذه الإضافة وضبطها، لأنّه سيجب على المخترقين استخدام وسيط (Proxy) بعد كلّ 3 محاولات فاشلة لتسجيل الدخول، وسيجب عليهم تغيير ذلك الوسيط آلاف المرّات ليتمكّنوا من تحقيق الهجوم، وهو الأمر الذي لا يتوفّر لديهم غالبًا. حظر المستخدمين الذين يحاولون تسجيل الدخول باسم Admin من المهم ألّا تستخدم اسم "admin" كاسم مدير الموقع على موقعك، ومن المهم أيضًا أن تقوم بحظر كلّ من يحاول الدخول إلى ذلك المستخدم (طالما أنتَ لستَ المدير، والحساب غير موجود، فلماذا تحاول الدخول؟ إذن فأنتَ مُخترِق)، يمكنك القيام بهذا عن طريق إضافة Wordfence. تسمح لك هذه الإضافة بإعداد ميزة الحظر التلقائي هذه، بالطبع، هناك العديد من المميزات الأخرى في هذه الإضافة التي يمكنك استخدامها من أجل الحماية، مثل الاستيثاق الثنائي (two-factor authentication)، حظر الهجمات الشائعة والمزيد. ضبط صلاحيات الملفّات الصحيحة شيءٌ آخر يمكنك فعله هو ضبط صلاحياتٍ مناسبة للملفّات على موقعك. وفقًا لـ WordPress.org، فإنّ استخدام صلاحيات 777 للملفّات / المجلّدات هو أمرٌ خطير للغاية ويسمح للجميع أن يقوموا بتعديل ملفّات موقعك وإضافة أكواد خبيثة أو حتّى حذف الموقع بالكامل. يجب عليك أن تقوم بوضع صلاحيات 600 لملفّ wp-config.php، بينما يجب عليك أن تقوم بتعيين ملفّاتك الأخرى إلى وضع صلاحيات 640 أو 644، كما يجب أن تكون المجلّدات الموجودة على موقعك بالصلاحيات 750 أو 755. يمكنك تعلّم المزيد عن الصلاحيات عبر دليل ووردبريس الرسمي لتغيير الصلاحيات. إنشاء ملف htaccess. إذا كنتَ تريد تركيبة روابط دائمة (permalinks) جميلة لموقعك فإنّك ستحتاج ملفّ htaccess. عبر إضافة واحدٍ إلى موقعك فإنّك ستقوم بتحسين مستوى الحماية قليلًا، صحيحٌ أنّه ليس حلًا كاملًا ولا يمكنه فعل شيء جوهري لوحده ولكنّه إضافة جيّدة. هناك شرح شامل منشور على الويب حول إنشاء ملفّ htaccess. ، لن نقوم بشرح تلك العملية بالكامل هنا لأنّ العملية مشروحة بذاك الدليل بشكلٍ شامل. بمجرّد أن تقوم باتّباع ذاك الشرح فإنّه سيصبح بإمكانك منع الوصول إلى ملفّات معيّنة على موقع ووردبريس الخاصّ بك. إذا لم يكن الناس قادرين على الوصول إلى تلك الملفّات التي تريدها فلن يكونوا قادرين على العبث بها. لزيادة صعوبة اختراق موقع ووردبريس الخاصّ بك ستحتاج إلى إضافة بضع سطور من الأكواد لحظر الوصول إلى ملفّات معينة مثل: wp-config.php readme.html license.txt wp-includes directory يمكنك أيضًا منع الوصول إلى امتدادات معيّنة للملفّات، مثل ملفّات النسخ الاحتياطي، الإعدادات، السجلات المحفوظة على الخادوم.. إلخ. بشكلٍ عام، يجب حظر الوصول إلى أيّ شيء يتعلّق بالتصميم والتطوير والتوثيق الخاصّ بخلفيّة الموقع (back-end). إذا كنتَ تريد حظر الوصول إلى مجلّد إضافة أو قالب معيّن أو مسارٍ آخر على موقعك، فيمكنك حظر المجلّد بأكمله إن أردت. هذه حركة جيّدة للقيام بها في كلّ مجلّد لا يمتلك بداخله ملفّ index. حيث أنّ المجلّدات التي لا تحتوي على ملفّات index ستقوم بعرض كلّ الملفّات الموجودة بداخل ذاك المجلّد، مما يعطي معلوماتٍ هامّة يمكن استغلالها من طرف المخترقين، لذا يجب عليك إخفاؤها. إخفاء صفحة تسجيل الدخول هذا تعديلٌ آخر يمكن القيام به عن طريق htaccess. ولكن مختلف قليلًا عن التعديلات الأخرى ولذلك سنذكره هنا. يمكنك حظر وصول أيّ شخص إلى صفحة تسجيل الدخول الخاصّة بموقعك ومنح حقّ الوصول فقط إلى عنوان الـIP الخاصّ بك، وطبعًا، يجب أن يكون هناك مستخدمٌ واحد فقط للموقع بأكمله، وبالتالي فتلك ليست طريقة عملية حقًا لاستخدامها. إذا كنتَ تريد إبقاء خيارٍ مفتوح لإضافة كتّابٍ ومستخدمين آخرين إلى موقعك لاحقًا، فيمكنك استخدام إضافة Secure Hidden Login. تسمح لك هذه الإضافة بإخفاء حقول الإدخال من صفحة تسجيل الدخول الخاصّة بموقعك، ويتم إظهار حقول الإدخال لاسم المستخدم وكلمة المرور فقط عند الضغط على اختصاراتٍ معيّنة على لوحة المفاتيح، فإن حاول أحدهم فتح صفحة تسجيل الدخول، فلن يتمكّن من ذلك دون أن يعرف ما هي اختصارات لوحة المفاتيح التي تقوم بعرض صفحة تسجيل الدخول. إزالة وسم Generator يقوم المخترقون بكلّ شيءٍ قد يمكّنهم من اختراق موقعك، واحدٌ من هذه الأشياء هو سكربتٌ شهير يستخدمه المخترقون لالتقاط المواقع التي تعمل بإصدارات معيّنة من ووردبريس عبر بصمات الأقدام (Footprints)، بصمات الأقدام هي عبارة عن سطور متعددة من الأكواد يمكن استخدامها للتعرّف على هوية موقع ويب ما، لسوء الحظّ فإن ووردبريس يستخدم هذه البصمات مما يجعل مواقع ووردبريس الموجودة على الشبكة قابلة للاكتشاف بسهولة. قد تبدو بصمة القدم الخاصّة بموقع ووردبريس كشيءٍ مثل: <meta name="generator" content="WordPress 3.8.4" /> يمكنك إزالة هذا الوسم إن أردت من الشفرة المصدرية الخاصّة بموقعك، ولكن ما يزال عليك إضافة الشفرة التالية إلى ملفّ functions.php الخاصّ بقالبك: remove_action('wp_head', 'wp_generator'); بعد هذا، لن يقوم موقع ووردبريس الخاصّ بك بتعريف نفسه على أنّه موقعٌ يعمل بسكربت ووردبريس، مما يصعّب المهمّة على المُخترقِين. تفعيل الاستيثاق الثنائي Two-Step Authentication شيءٌ آخر يمكنك فعله لتأمين موقعك هو تفعيل الاستيثاق الثنائي أو ما يدعى بـ Two-Step Authentication. عندما تقوم بطلب خطوتين للاستيثاق من مستخدمي موقعك عوضًا عن خطوة واحدة فإنّك تصعّب الأمر جدًا على المُخترقِين. هناك عدّة إضافات موجودة لتفعيل الاستيثاق الثنائي على ووردبريس ومن بينها: Clef: بمجرّد تثبيت هذه الإضافة، فإنّ كل ما سيجب عليك فعله هو فتح تطبيق Clef على هاتفك المحمول وتركيز كاميرا الهاتف على شاشة الحاسوب الخاصّة بك، بعدها سيتم فتح القفل الموجود على موقعك وتتمكن من الدخول. Duo Two-Factor Authentication: بعد أن تقوم بإدخال كلمة المرور الخاصّة بك في مربّع الإدخال التقليدي، سيجب عليك إكمال خطوةٍ أخرى لإتمام عملية تسجيل الدخول، مثل تأكيد تسجيل الدخول من على هاتفك الذكي عبر رسالة SMS وغيرها من الطرق. الخاتمة إدارة الحماية على موقع ووردبريس الخاصّ وإعداد عمليات تسجيل الدخول ليتم تقييدها قدر المستطاع هو أمرٌ قد يستغرق منك بعض الوقت، ولكن بمجرّد أن تكتمل هذه الأمور، فإنّ موقعك سيكون أكثر أمانًا لمستخدميه. ترجمة -وبتصرف- للمقال The WordPress Developer’s Guide to Security: Management & Logins لصاحبته Brenda Barron.

الحماية هي مشكلة كبيرة في غاية الأهمّية عند الحديث عن الخواديم على الشبكة. صحيح أنه يمكن إعداد الجدران النارية، سياسات fail2ban، الخدمات الآمنة وتطبيق بعض التقييدات على تطبيقات الويب، إلّا أنّه من الصعب أن تتأكّد مما إذا قمتَ حقًا بمنع حصول كلّ الهجمات على خادومك أو صدّها. يعمل نظام اكتشاف الاختراق على جهاز المستضيف (HIDS - host-based intrusion detection system) عبر جمع التفاصيل عن نظام ملفّات حاسوبك وإعداداته. ثمّ يقوم بتخزين هذه المعلومات لديه ليستخدمها في مطابقة حالة النظام الحالية مع البيانات التي قام بجمعها بالسابق. إذا حصل أيّ تغيير بين حالة النظام الحالية وبين حالة النظام المخزّنة لدى HIDS، فتلك قد تكون إشارة إلى أنّه قد تمّ اختراق خادومك. من أنظمة اكتشاف الاختراق الشهيرة على نظام لينكس هو تطبيق Tripwire. وهو برنامج يمكنه تعقّب العديد من نقط بيانات نظام الملفّات بهدف اكتشاف ما إذا حصلت تغييرات غير متوقّعة عليها. في هذا الدرس، سنشرح كيفية تثبيت وإعداد tripwire على Ubuntu 12.04. بسبب طبيعة نظام اكتشاف الاختراقات، فمن المستحسن أن تقوم بتثبيت هذا النظام مباشرةً بعد إعداد خادومك، لكي يتمكّن النظام من الحصول على نسخةٍ نظيفة وآمنة بالأساس من خادومك. تثبيت Tripwireلحسن الحظّ، يتوفّر tripwire في المستودعات الافتراضية لتوزيعة Ubuntu، يمكن تثبيته عبر الأمر التالي: sudo apt-get update sudo apt-get install tripwireأثناء عملية التثبيت، سيتم ضبط إعدادات العديد من الحزم الأخرى التي يعتمد عليها التطبيق في عمله. أوّلًا، سيقوم بإعداد تطبيق البريد الذي يحتاجه كاعتمادية. إذا كنت تريد إعداد التنبيهات عبر البريد الإلكتروني، فاختر "internet site". بعدها سيسألك عمّا إذا كنت تريد اختيار جمل المرور passphrases أثناء التثبيت، اختر Yes لكلا السؤالين. ثمّ سيسألك عمّا إذا كنت تريد إعادة بناء ملفّ الإعدادات، اختر yes. وأخيرًا، سيسألك سؤالًا مشابهًا عن ملفّ السياسة المتّبعة policy، اختر yes. بعدها، سيطلب منك اختيار وتأكيد جُمَل مرور للموقع. يستخدم Tripwire مفتاحين اثنين لتأمين ملفّات إعداداته: مفتاح الموقع site key: يُستخدم هذا المفتاح لتأمين ملفّات الإعدادات. نحتاج إلى أن نضمن أنّ هذه الملفّات لن يتم تغييرها، وإلّا فلن نتمكّن من الوثوق بنظام اكتشاف الاختراقات بأكمله حينها. بما أنّ نفس ملفّات الغعدادات يمكن أن يتم استخدامها من قبل أكثر من خادوم، فإنّه بالإمكان استخدام هذا المفتاح على أكثر من خادوم.المفتاح المحلّي local key: يتم استخدام هذا المفتاح على كلّ آلة لتشغيل الملفّات الثنائية (binaries). وهو أمرٌ ضروري لضمان أنّ الملفّات الثنائية لن يتم تشغيلها دون موافقتنا.ستقوم أوّلًا باختيار وتأكيد جُملة مرور لمفتاح الموقع، ثمّ للمفتاح المحلّي. تأكّد من إدخال جمل قوّية. تحليل قاعدة البياناتبعد التثبيت، يجب أن تقوم بتحليل وإعداد تثبيتك. كما في معظم برامج الحماية، يأتي tripwire مع إعدادت افتراضية عامّة مُقيّدة يمكن تعديلها لتناسب احتياجاتك. أوّلًا، إذا لم تختر yes عندما سألك عن إنشاء ملفّ السياسة المتّبعة policy أثناء التثبيت، فإنّه يجب عليك فعل ذلك الآن عبر الأمر: sudo twadmin --create-polfile /etc/tripwire/twpol.txtسيتم سؤالك بعدها عن جملة المرور التي اخترتها سابقًا. يقوم هذا بإنشاء ملفّ سياسة مشفّر من الملفّ الموجود في المسار etc/tripwire/، هذا الملفّ المشفّر هو ما يقرأه tripwire حقا عند تنفيذ فحوصاته. يمكننا الآن تحليل قاعدة البيانات التي سيستخدمها tripwire للتحقق من نظامنا لاحقًا. تستخدم قاعدة البيانات هذه الملف الذي قمنا بإنشاءه للتو كما أنّها تقوم بالتحقق من النقاط المحددة بداخله. بسبب أنّ هذا الملف ليس مجهّزا لنظامنا بعد، فسنحصل على الكثير من رسائل التحذير، الأخطاء وغيرها. سنستخدم هذه الرسائل كدليل لنقوم بضبط ملفّ إعدادتنا حاليًا. للقيام بتحليل قاعدة البيانات، طبّق: sudo tripwire --initيقوم هذا الأمر بإنشاء ملفّ قاعدة البيانات وطباعة الأشياء التي يجب علينا ضبطها في ملفّ إعداداتنا. ولأننا نريد حفظ النتائج لنقوم بتحديد ما سنقوم بتعديله بالإعدادات، فيمكننا التقاط أيّ جزءٍ يقوم بذكر اسم ملف معيّن نريده من الخرج، ووضعه في مجلّد إعدادات tripwire. يمكننا تشغيل عمليّة التحقق ووضع الملفّات التي تمّ سردها داخل ملف يدعى test_results عن طريق الأمر: sudo sh -c 'tripwire --check | grep Filename > test_results'إذا فتحنا هذا الملف، فيجب أن نرى شيئا مثل: less /etc/tripwire/test_results Filename: /etc/rc.boot Filename: /root/mail Filename: /root/Mail Filename: /root/.xsession-errors . . . إعداد ملف السياسة المتبعة لمطابقة حالة نظامكالآن وبعد أن صار لدينا قائمة بكل الملفّات التي تشكّل إعدادات tripwire، يمكننا تعديل ملفّ السياسة policy file للتخلص من تلك الرسائل المزعجة التي تظهر لنا. افتح ملف السياسة الصرف بمحرر النصوص الخاص بك وبصلاحيات الجذر: sudo nano /etc/tripwire/twpol.txtابحث عن عن جميع الملفّات الموجودة في ملف test_results. قم بتعليق كل السطور التي تجدها منها (ضع إشارة # قبلها فقط). في قسم "Boot Scripts"، يجب أن تقوم بتعليق السطر etc/rc.boot/ لأنّه ليس موجودًا على نظام Ubuntu: ( rulename = "Boot Scripts", severity = $(SIG_HI) ) { /etc/init.d -> $(SEC_BIN) ; #/etc/rc.boot -> $(SEC_BIN) ; /etc/rcS.d -> $(SEC_BIN) ; } كان هناك العديد من الملفّات الموجودة بمسار root/ والتي كان يجب علي تعليقها على نظامي، قم بتعليق أي ملف غير متوفر على نظامك حاليًا: ( rulename = "Root config files", severity = 100 ) { /root -> $(SEC_CRIT) ; # Catch all additions to /root #/root/mail -> $(SEC_CONFIG) ; #/root/Mail -> $(SEC_CONFIG) ; #/root/.xsession-errors -> $(SEC_CONFIG) ; #/root/.xauth -> $(SEC_CONFIG) ; #/root/.tcshrc -> $(SEC_CONFIG) ; #/root/.sawfish -> $(SEC_CONFIG) ; #/root/.pinerc -> $(SEC_CONFIG) ; #/root/.mc -> $(SEC_CONFIG) ; #/root/.gnome_private -> $(SEC_CONFIG) ; #/root/.gnome-desktop -> $(SEC_CONFIG) ; #/root/.gnome -> $(SEC_CONFIG) ; #/root/.esd_auth -> $(SEC_CONFIG) ; #/root/.elm -> $(SEC_CONFIG) ; #/root/.cshrc -> $(SEC_CONFIG) ; /root/.bashrc -> $(SEC_CONFIG) ; #/root/.bash_profile -> $(SEC_CONFIG) ; #/root/.bash_logout -> $(SEC_CONFIG) ; /root/.bash_history -> $(SEC_CONFIG) ; #/root/.amandahosts -> $(SEC_CONFIG) ; #/root/.addressbook.lu -> $(SEC_CONFIG) ; #/root/.addressbook -> $(SEC_CONFIG) ; #/root/.Xresources -> $(SEC_CONFIG) ; #/root/.Xauthority -> $(SEC_CONFIG) -i ; # Changes Inode number on login #/root/.ICEauthority -> $(SEC_CONFIG) ; }آخر جزءٍ من عملية التحقق الخاصّة بي كان يتذمّر من الملفّات الوصفية بنظام الملفّات proc/. تتغير هذه الملفّات طوال الوقت، لذا فإنّها تقوم بإرجاع نتيجة موجبة طوال الوقت لنظام اكتشاف الاختراقات بعد أن تتغير. في قسم "Devices & Kernel information"، يمكنك أن ترى أن نظام الملفّات proc/ مُعلّم ليتم التحقق منه: ( rulename = "Devices & Kernel information", severity = $(SIG_HI), ) { /dev -> $(Device) ; /proc -> $(Device) ; }ولكن هذا يقوم بالتحقق من كل الملفّات الموجودة ضمنه، ونحن لا نريد هذا. وعوضا عن ذلك، فسنقوم بحذف هذا الخيار، وإضافة الملفّات الفرعية الموجودة داخل نظام proc/ والتي نريد التحقق منها فقط: { /dev -> $(Device) ; #/proc -> $(Device) ; /proc/devices -> $(Device) ; /proc/net -> $(Device) ; /proc/tty -> $(Device) ; /proc/sys -> $(Device) ; /proc/cpuinfo -> $(Device) ; /proc/modules -> $(Device) ; /proc/mounts -> $(Device) ; /proc/dma -> $(Device) ; /proc/filesystems -> $(Device) ; /proc/interrupts -> $(Device) ; /proc/ioports -> $(Device) ; /proc/scsi -> $(Device) ; /proc/kcore -> $(Device) ; /proc/self -> $(Device) ; /proc/kmsg -> $(Device) ; /proc/stat -> $(Device) ; /proc/loadavg -> $(Device) ; /proc/uptime -> $(Device) ; /proc/locks -> $(Device) ; /proc/meminfo -> $(Device) ; /proc/misc -> $(Device) ; }وبما أننا في هذا القسم من الملف، فنريدُ أيضًا عمل شيءٍ مع نظام الملفّات dev/pts/. لن يتحقق Tripwire من نظام الملفّات ذاك افتراضيًا لأنّه مضبوط لأن يتحقق من dev/ فقط، بينما يعتبر dev/pts/ نظام ملفات منفصل، ولذلك لن يتم اعتباره في عملية التحقق. لجعل Tripwire يتحقق من هذا النظام كذلك، يمكنك إضافته كالشكل التالي: { /dev -> $(Device) ; /dev/pts -> $(Device) ; #/proc -> $(Device) ; /proc/devices -> $(Device) ; /proc/net -> $(Device) ; /proc/tty -> $(Device) ; . . .الشيء الأخير الذي سنقوم بوضع إشارة تعليق قبله هما السطران var/run/ و var/lock/ لكي لا يقوم نظامنا باعتبار التغييرات التي تجري على نظام الملفّات من طرف الخدمات: ( rulename = "System boot changes", severity = $(SIG_HI) ) { #/var/lock -> $(SEC_CONFIG) ; #/var/run -> $(SEC_CONFIG) ; # daemon PIDs /var/log -> $(SEC_CONFIG) ; }احفظ الملف وأغلقه عندما تنتهي. الآن وبعد أن قمنا بضبط ملفّنا، نحتاج إلى استخدامه عبر إعادة إنشاء ملف السياسة المشفّر الذي يستخدمه tripwire في الواقع: sudo twadmin -m P /etc/tripwire/twpol.txtبعد أن يتم إنشاؤه، يجب أن نقوم بإعادة تحليل قاعدة البيانات لتطبيق السياسة الجديدة: sudo tripwire --init Please enter your local passphrase: Parsing policy file: /etc/tripwire/tw.pol Generating the database... *** Processing Unix File System *** Wrote database file: /var/lib/tripwire/tripit.twd The database was successfully generated.يجب أن تختفي الآن جميع رسائل التحذيرات والأخطاء المزعجة التي رأيتها في البداية، إذا كان لا يزال هناك رسائل تحذير مثلا، فيجب أن تتابع تحرير ملف etc/tripwire/twpol.txt/ إلى أن تختفي. اختبار الإعداداتإذا لم تشتكي عمليّة تحليل قاعدة البيانات من أي مشاكل أو أخطاء، فهذا يعني أن إعداداتك تطابق نظام الحالي في هذه النقطة. ولكننا سنقوم بعمل اختبار لرؤية ما يبدو عليه تقرير tripwire إذا لم يكن هناك حقًا أيّ أخطاء. الأمر الرئيسي للاختبار هو: sudo tripwire --checkيجب أن ترى تقريرًا يتم طباعته على شاشتك ليخبرك أنّه لا يوجد أيّ أخطاء أو تغييرات مُكتشفة على نظامك. بمجرّد اكتمال هذه العملية، يمكنك أن تكون مطمئنا إلى أن إعداداتك تم ضبطها بالشكل الصحيح. يجب علينا تنظيف ملفّاتنا قليلًا لحذف المعلومات الحسّاسة من نظامنا. يمكننا حذف ملف test_results الذي قمنا بإنشائه: sudo rm /etc/tripwire/test_resultsشيء آخر يمكننا القيام به هو إزالة ملف الإعدادات الصرف الغير مشفّر. يمكننا الآن القيام بهذا بشكل آمن لأنّه يمكن إعادة إنشائه إن أردنا مجددا من الملف المشفّر باستخدام جملة المرور الخاصّة بنا لاحقا. كل ما علينا فعله لإعادة إنشاء ملف الإعدادات الصرف هو تمرير الملف المشفّر إلى twadmin، بنفس الطريقة التي قمنا بإنشاء الإصدار المشفّر بداية. يجب علينا فقط تطبيق: sudo sh -c 'twadmin --print-polfile > /etc/tripwire/twpol.txt'اختر هذا الآن عبر نقل الإصدار النصّي إلى موقع النسخ الاحتياطي ثم حاول إعادة إنشائه: sudo mv /etc/tripwire/twpol.txt /etc/tripwire/twpol.txt.bak sudo sh -c 'twadmin --print-polfile > /etc/tripwire/twpol.txt'إذا عمل بشكل صحيح، فيمكنك حينها حذف الملفّات الصرفة بشكل آمن الآن: sudo rm /etc/tripwire/twpol.txt sudo rm /etc/tripwire/twpol.txt.bakإعداد التنبيهات عبر البريد الإلكترونيسنقوم بإعداد tripwire ليتم تشغيله كل يوم وليتم أتمتة التنبيهات عبر البريد الإلكتروني فيه. خلال العملية، يمكننا أن نختبر كيفيّة تحديث قاعدة البيانات عندما نقوم بعمل تغييرا على نظامنا. سنستخدم الأمر mail لإرسال التنبيهات إلى عنوان بريدنا الإلكتروني. هذا الأمر غير مثبّت حاليا على نظامنا، لذلك يجب علينا تحميله من المستودعات الرسمية. لتثبيته: sudo apt-get install mailutilsالآن وبعد أن تم تثبيت الأمر، فلنقم باختبار قدرة نظامنا على إرسال تقرير tripwire عبر البريد الإلكتروني. سيحتوي هذا التقرير على رسائل التحذير والتغييرات الحاصلة مؤخّرًا على الخادوم، وبما أننا قمنا للتو بتثبيت برنامج جديد دون إخبار tripwire: sudo tripwire --check | mail -s "Tripwire report for `uname -n`" your_email@domain.comيجب أن تتلقى تقريرا بعد فترة قصيرة في بريدك الإلكتروني عن البرنامج الجديد "mail" الذي تمّ تثبيته على النظام. هذا أمر جيّد، إنّه يعني أن tripwire يقوم بمهمّته بمراقبة نظام ملفّاتنا وأنّ نظام التنبيهات عبر البريد الإلكتروني يعمل كذلك. يجب علينا الآن تشغيل اختبار تحقق لتحديث قاعدة البيانات بعد أن قمنا بتثبيت برنامج جديد. يمكننا فعل ذلك عبر: sudo tripwire --check --interactiveسيقوم هذا الأمر بتشغيل الاختبارات كالمعتاد، ولكن في النهاية، عوضًا عن أن يقوم بطباعة التقرير على الشاشة، سيتم نسخه إلى ملف نصّي وفتحه بواسطة محرر النصوص الافتراضي. يحتوي هذا التقرير على الكثير من التفاصيل عن الملفّات التي تمّ تغييرها. في الواقع، على جهازي، كان الملفّ المُنشَئ يتكوّن من أكثر من 2275 سطر. هذه الكمّية من المعلومات مفيدة جدًا في حال حصول مشكلة حقيقية تتعلق بالحماية. الجزء الأهم هو ببداية الملف. بعد القليل من المعلومات التقديمية، يجب أن ترى بضع سطور تحتوي صناديق اختيار لكل من الملفّات المُعدّلة أو المُضافة: Rule Name: Other binaries (/usr/sbin) Severity Level: 66 ------------------------------------------------------------------------------- Remove the "x" from the adjacent box to prevent updating the database with the new values for this object. Added: [x] "/usr/sbin/maidag" Modified: [x] "/usr/sbin" . . .تشير صناديق الاختيار هذه إلى أنّك تريد تحديث قاعدة البيانات للسماح بهذه التغييرات. يجب أن تبحث عن كل صندوق يحوي إشارة "x" بداخله وأن تتحقق من أن هذه التغييرات قد قمت بها أنت فعلا وأنّه لا بأس بها. إذا لم تكن تريد لتغيير معيّن أن يبقى، يمكنك إزالة إشارة "x" من الصندوق ولن يتم تحديث ذلك الملفّ في قاعدة البيانات. سيسبب هذا أن يقوم tripwire باعتبار الملفّ كملف تمّ تعديله دون أن يكون متوقعًا ذلك. في هذه النقطة، سيسألك النظام عن جملة المرور التي اخترتها في البداية لكي يتمكّن tripwire من تحديث ملفّات قاعدة البيانات الخاصّة به. إذا قبلنا جميع التغييرات، وإذا قمنا بتشغيل هذا الأمر بعدها، فيجب أن يكون التقرير أقصر بكثير الآن وألّا يسرد أيّ تغييرات. أتمتة Tripwire مع Cronالآن وبعد أن تحققنا من أن جميع وظائف النظام تعمل بشكل يدوي، يمكننا إعداد مهمّة cron لتقوم بتنفيذ اختبار تحقق بواسطة tripwire في كل صباح. يمكنك الإطلاع على كيفية عمل cron من هنا. يمكننا استخدام crontab الخاص بالمستخدم الجذر، لأنّ التعديلات على الـcronjob الخاصّة بالنظام قد يتم محوها في حال توفّر تحديث لحزمة cron. للتحقق ما إذا كان المستخدم الجذر يمتلك بالفعل crontab: sudo crontab -lإذا كان crontab موجودًا، فيجب عليك نقله عبر أنبوب (pipe) إلى ملف وأن تقوم بإرجاعه: sudo sh -c 'crontab -l > crontab.bad'بعدها، يمكننا تعديل الـcrontab عبر: sudo crontab -eإذا كانت هذه مرّتك الأولى في تشغيل crontab، فسيسألك عن اسم محرر النصوص الذي تود استخدامه. إذا كنت لا تفضّل واحدًا على آخر، فيمكنك استخدام المحرر nano. بعدها، سيتم نقلك إلى ملف حيث يمكنك أتمتة tripwire من داخله. بما أننا سنقوم بتشغيل tripwire كل يوم، فسنحتاج فقط إلى أن نقرر الوقت الذي نريد تشغيله فيه. بشكلٍ عام، يتم تشغيل الخدمات في أوقات بعيدة عن أوقات الذروة لألّا تكون مزعجة أثناء التنفيذ للخادوم في ساعات الذروة والضغط على الخادوم. الصيغة التي نحتاج استخدامها هي min hour * * * command والأمر الذي نريد استخدامه هو نفسه الذي استخدمناه في تقريرنا عبر البريد الإلكتروني سابقًا. لا نحتاج إلى استخدام sudo هذه المرّة بما أنّه سيتم تشغيل الأمر باسم المستخدم الجذر. لتشغيل tripwire بالساعة 3:30 صباحًا كلّ يوم، يمكننا وضع السطر التالي بملفّنا: 30 3 * * * /usr/sbin/tripwire --check | mail -s "Tripwire report for `uname -n`" your_email@domain.comيمكنك تعديله حسب احتياجك. خاتمةيجب أن تمتلك الآن نظام اكتشاف اختراق مؤتمن يُرسِل لك التقارير يوميًا في حال حصول تغييرات على نظام الملفّات الخاصّ بك. يجب أن تقوم بمعاينة التقارير المُرسلة بصفة دورية وتقوم باتّخاذ إجراء حيالها إن احتجت ذلك، إمّا بتحديث قاعدة tripwire بأنّ التغييرات لا بأس بها وأنّها من طرفك، وإمّا بالتحقيق بأي نشاط مشبوه. ترجمة -وبتصرف- للمقال How To Use Tripwire to Detect Server Intrusions on an Ubuntu VPS لصاحبه Justin Ellingwoo.

SSH هو الطريقة الأساسية للاتصال بخواديم لينكس والأنظمة الشبيهة بيونكس عبر سطر الأوامر. يوفّر لك هذا اتصالًا آمنًا يمكنك استخدامها لتطبيق الأوامر، التفاعل مع النظام أو حتّى توجيه التدفّق (traffic) عبره. معظم المستخدمين يدركون أساسيات البدء وكيفية الاتصال بخادومٍ بعيد عبر أمرٍ شبيه بـ: ssh username@remote_serverلكن، هناك المزيد من الخيارات المفيدة التي يمكنك استخدامها مع عفريت SSH Daemon) SSH) لتحسين الأمان، إدارة اتصالات المستخدمين.. إلخ. سنشرح بعض هذه الخيارات التي تعطيك تحكّمًا أكبر باتصال SSH الخاصّ بك. سنقوم بتوضيح هذه الأمور على خادوم Ubuntu 12.04، ولكن الأمور نفسها تنطبق على أيّ توزيعة لينكس حديثة. تصفح ملف إعداد SSHDالمصدر الرئيسي لإعدادات عفريت SSH هو بالملف etc/ssh/sshd_config/. لاحظ أنّ هذا الملف مختلفٌ عن ملف ssh_config، والذي يقوم بضبط إعدادات SSH لأجهزة العملاء فقط (clients). افتح الملف بصلاحياتٍ إدارية عبر: sudo nano /etc/ssh/sshd_configسترى ملفًّا مفتوحًا مع بعض خيارات، ولحسن الحظ، فسترى بعض التعليقات كذلك (اعتمادًا على توزيعة لينكس الخاصّة بك). صحيحٌ أنّ معظم توزيعات لينكس تستخدم إعدادات افتراضية جيّدة، ولكن هناك مساحة موجودة كذلك لعمل بعض التخصيص والتحسين. فلنستعرض بعض الخيارات التي تمّ ضبطها بالفعل بملفّنا على Ubuntu 12.04: المنافذ والبروتوكولاتPort 22: يقوم هذا السطر بتحديد المنفذ الذي سيعمل عليه عفريت SSH. افتراضيًا، تعمل معظم الخواديم وأجهزة العملاء على المنفذ 22، ولكن تغيير هذا المنفذ إلى منفذٍ آخر قد يساعد من تقليل محاولات تسجيل الدخول الفاشلة عبر SSH بواسطة المُخترقين.Protocol 2: تمّ تطوير SSH عبر بروتوكولين مختلفين اثنين. باستثناء ما إذا كنتَ تحتاج إلى دعم أجهزة العملاء التي تعمل فقط على البروتوكول 1، فمن المستحسن أن تترك هذا السطر على ما هو عليه.المفاتيح والعزلHostKey /etc/ssh/sshhost…: تقوم هذه السطور بتحديد مفاتيح المستضيف الخاصّة بالخادوم. يتم استخدام هذه المفاتيح للتعرّف على الخادوم للاتصال بأجهزة العملاء. إذا كان جهاز عميلٍ ما قد اتصل من قبل بالخادوم في الماضي، فيمكنه استخدام هذا المفتاح للتحقق من الاتصال الجديد.UsePrivilegeSeparation yes: يسمح هذا الخيار لـSSH بإنشاء عملياتٍ فرعية تمتلك الصلاحيات اللازمة فقط لآداء مهامّها. هذه الميّزة هي ميّزة أمان يتم استخدامها لعزل العمليات الفرعية في حصول اختراقٍ أمني.KeyRegenerationInterval و ServerKeyBits: تقوم هذه الخيارات بالتأثير على مفتاح الخادوم الذي يتم إنشاؤه للبروتوكول 1. لا يجب عليك أن تولي اهتمامًا لهذا طالما أنّك لا تزال تستخدم البروتوكول 2.التسجيل والتقييداتSyslogFacility و LogLevel: تحدد هذه الخيارات كيف سيتم تسجيل النشاط. الخيار الأول هو لتسجيل الرسائل، والخيار الثاني يحدد "درجة التسجيل" أو التفاصيل التي يجب أن يتم تسجيلها بملفّات السجل.LoginGraceTime 120: يحدد هذا الخيار عدد الثواني التي يجب على الخادوم أن ينتظرها قبل أن يقوم بقطع الاتصال عن جهازٍ عميل في حال لم يكن هناك عملية تسجيل دخول ناجحة.PermitRootLogin yes: يسمح هذا الخيار أو يمنع من استخدام SSH لتسجيل الدخول إلى المستخدم الجذر عبر اتصالٍ بعيد. بما أنّ المستخدم الجذر هو مستخدمٌ يعرف المهاجمون أنّه حتمًا موجود على الخادوم، وبما أنّه يمتلك كامل الصلاحيات كذلك، فهو هدفٌ معرّض بشدة للهجمات. لذا فإنّ تغيير هذا الخيار إلى "no" سيكون جيّدا بعد أن تضبط مستخدمًا عاديًا بصلاحيات الإدارة.StrictModes yes: هذا السطر يمنع استخدام أيّ ملفّات إعداد تابعة لـSSH في حال كانت غير مضبوطة على الصلاحيات الصحيحة. مثلًا، إذا كانت ملفّات الإعداد قابلة للكتابة من قبل الجميع، فإنّ هذا الأمر يعتبر خطرًا، ويجب عدم استخدام تلك الملفّات إلى حين إصلاح المشكلة.IgnoreRhosts و RhostsRSAAuthentication: تحدد هذه السطور نمط استيثاق rhost الذي سيتم استخدامه. هذه السطور مصممة للبروتوكول 1 ولا تنطبق على البروتوكول 2.HostbasedAuthentication no: هذا هو إصدار البروتوكول 2 من الخيارين السابقين. يسمح لك هذا الخيار بشكلٍ أساسي بقبول عمليات الاستيثاق بناءً على المستضيف الخاصّ بأجهزة العملاء. عادةً يكون هذا الخيار مقبولًا فقط بالبيئات المعزولة، لأنّه يمكن أن يتم عبره محاكاة معلومات المصدر. يمكنك تحديد معلومات المستضيف التي يجب السماح لها بالملف etc/ssh/shosts.equiv/ أو الملف etc/hosts.equiv/، ولن نتحدّث عن هذا الأمر حاليًا.PermitEmptyPasswords no: يقوم هذا الخيار بمنع الوصول عبر SSH إلى حسابات المستخدمين التي لا تمتلك كلمة مرور (وهي كثيرة!)، وهذا أمرٌ خطير ولا يجب عليك تغيير حالته بتاتًا.ChallengeResponseAuthentication: يقوم هذا السطر بتفعيل أو تعطيل الاستياق عبر "التحدّي" حيث يمكن ضبطه باستخدام PAM، وهو خارج نطاق درسنا هذا حاليًا.العرضX11Forwarding yes: يسمح لك هذا بإعادة توجيه واجهة X11 الرسومية الخاصّة بالتطبيقات على الخادوم إلى أجهزة العملاء. هذا يعني أنّه يمكنك تشغيل برنامجٍ رسومي على الخادوم والتفاعل معه من على جهاز العميل. يجب على جهاز العميل أن يمتلك نظام النوافذ X مثبّتًا. يمكنك تثبيت وضبط هذه الأمور على OS X، كما أنّ جميع توزيعات لينكس ستحتوي على هذه الأشياء كذلك.X11DisplayOffset 10: هذا الخيار هو عبارة عن "إزاحة" لرقم عرض sshd لتوجيه X11. تسمح هذه الإزاحة لنوافذ X11 المفتوحة عبر بروتوكول SSH بأن تتفادى التشابك مع خادوم العرض X المحلّي.PrintMotd no: يقوم هذا السطر بجعل عفريت SSH لا يقوم بقراءة وعرض رسالة اليوم. أحيانًا يتم قراءة هذه الرسالة بواسطة الصدفة نفسها، لذا ربما تحتاج إلى تعديل إعدادات الصدفة الخاصّة بك كذلك.PrintLastLog yes: يقوم هذا الخيار بإخبار عفريت SSH بأن يطبع معلوماتٍ عامّة عن آخر عملية تسجيل دخول قمتَ بها.الاتصال والبيئةTCPKeepAlive yes: يحدد هذا السطر ما إذا كان يجب إرسال رسائل الإبقاء على قيد الحياة لبروتوكول TCP إلى جهاز العميل. يمكن لهذا الأمر أن يساعد الخادوم على اكتشاف المشاكل وأن يُعلمه متى سيتم إغلاق الاتصال. إذا كان هذا الخيار معطلًا، فإنّه لن يتم إغلاق الاتصالات عندما يكون هناك عدد قليل من المشاكل مع الشبكة، وهو ما يمكن أن يكون أمرًا جيّدًا، ولكنّه أيضًا يعني أنّ المستخدمين سيكونون قادرين على إلغاء الاتصال ومتابعة حجز مساحة من موارد الخادوم.AcceptEnv LANG LC_*: يسمح لك هذا الخيار بقبول متغيّرات بيئة معيّنة من جهاز العميل. في هذه السطر بالتحديد، سينقوم بقبول متغيرات اللغة، والذي يمكنه أن يساعد جلسة الصدفة على طباعة الرسائل بشكلٍ مخصص لجهاز العميل.Subsystem sftp /usr/lib/openssh/sftp-server: يقوم هذا الخيار بإعداد أنظمة فرعية خارجية يمكن استخدامها مع SSH. وبمثالنا هذا، فإنّه يتم تحديد خادوم STFP والمسار المؤدّي إلى تشغيله.UsePAM yes: يقوم هذا الخيار بتحديد ما إذا كان يجب توفير PAM (وحدات الاستيثاق القابلة للإضافة) للمستخدمين الذين تمّ التحقق منهم بالفعل.ما سبق هو أهمّ الخيارات الافتراضية المفعّلة على خادومنا العامل بـUbuntu 12.04. الآن، سنتحدّث عن بعض الخيارات الأخرى التي يمكن أن تكون مساعدةً لك لتضبطها أو تعدّلها. خيارات SSHD أخرىهناك المزيد من الخيارات التي يمكننا ضبطها لعفريت SSH الخاصّ بنا. بعض هذه الخيارات قد يكون مفيدًا لك وبعضها الآخر قد لا يكون مفيدًا إلّا في حالات معيّنة. لن نتحدّث عن جميع الخيارات هنا بل فقط المهم منها. ترشيح المستخدمين والمجموعاتتسمح لك بعض الخيارات بالتحكّم بشكلٍ دقيق بالمستخدمين الذين تريد السماح لهم فقط بالولوج عبر SSH. تعتبر هذه الخيارات خياراتٍ حصرية; كمثال، يسمح الخيار AllowUsers لمستخدمين معيّنين فقط بتسجيل الدخول بينما يمنع كلّ المستخدمين الآخرين. AllowGroups: يسمح لك هذا الخيار بتحديد أسماء المجموعات الموجودة على الخادوم. سيمتلك المستخدمون الأعضاء في واحدةٍ أو أكثر من هذه المجموعات حقّ الوصول إلى الخادوم فقط.AllowUsers: هذا الخيار شبيه بما سبق، ولكنّه يحدد المستخدمين المخوّلين فقط بالولوج. لن يتمكّن أيّ مستخدم غير مدرج على هذه القائمة من تسجيل الدخول عبر SSH. يمكنك اعتبار هذا الخيار كقائمةٍ بيضاء لأسماء المستخدمين المخوّلين للولوج.DenyGroups: يقوم هذا الخيار بعمل قائمة سوداء للمجموعات الغير مخوّلة بتسجيل الدخول، أيّ مستخدم عضو في واحدٍ من هذه المجموعات لن يمتلك حقّ الوصول إلى الخادوم عبر SSH.DenyUsers: وكالسابق، يقوم هذا الخيار بإنشاء قائمة سوداء للمستخدمين الممنوعين من تسجيل الدخول عبر SSH.بالإضافة إلى ما سبق، هناك بعض الخيارات التي تمكّنك من فرض المزيد من التقييدات. يمكن أن يتم استخدامها بالتوازي مع الخيارات السابقة. Match: يسمح هذا الخيار بالمزيد من التحكّم على المستخدمين القادرين على الاستيثاق تحت شروطٍ معيّنة. يحدد هذا الخيار كذلك مجموعةً مختلفة من الخيارات يمكن استخدامها عندما تتم عملية اتصال مستخدم معيّن أو مستخدمٍ ضمن مجموعة معيّنة. سنناقش هذا بالتفصيل لاحقًا.RevokedKeys: يسمح لك هذا الخيار بتحديد المفاتيح العمومية المُلغاة. سيقوم هذا بمنع المفاتيح المحددة من أن يتم استخدامها لتسجيل الدخول إلى النظام.خيارات منوعةهناك بعض الخيارات التي يمكنك استخدامها كذلك لإعداد التدفّق (traffic) عبر عفريت SSH، ومن بينها: AddressFamily: يحدد هذا الخيار نوع العناوين التي سيتم قبول الاتصالات منها. افتراضيًا، فإنّ الخيار مضبوط ليقبل جميع العناوين، ولكن يمكنك تغييره إلى "inet" لتجعله يقبل عناوين IPv4 فقط، أو "inet6" لعناوين IPv6.ListenAddress: يسمح لك هذا الخيار بأن تخبر عفريت SSH بأن يعمل على منفذٍ وعنوانٍ محددين. افتراضيًا، يعمل العفريت على جميع العناوين الموجودة على الآلة.الخيارات الأخرى المتوفّرة تشمل تلك التي يتم استخدامها لإعداد الاستيثاق عبر الشهادات، خيارات تقييد الاتصال مثل ClientAliveCountMax و ClientAliveInterval، بالإضافة إلى خيارات مثل ChrootDirectory، والذي يمكن استخدامها لقفل تسجيل دخول مستخدمٍ معيّن إلى مسارٍ محدد مضبوط مسبقًا. تقييد تسجيل دخول المستخدمينذكرنا أعلاه بعض الأدوات التي يمكنك استخدامها لتقييد دخول المستخدمين والمجموعات، فلنشرح بعضًا منها هنا بالقليل من التفصيل. الصيغة الأساسية لاستخدام هذه الأدوات هي كالتالي: AllowUsers demouser fakeuser madeupuserكما يمكنك أن ترى، يمكننا تحديد أكثر من مستخدم مفصولين بمسافة ليتم تطبيق الأمر عليهم. يمكننا أيضًا استخدام إشارات النفي لتطبيق قواعد معيّنة. مثلًا، إذا أردنا السماح للجميع بالولوج فيما عدا المستخدم "hanny"، فيمكننا تطبيق شيءٍ كـ: AllowUsers * !hannyيمكننا أن نعبّر عن المثال السابق مع الخيار DenyUsers كالشكل التالي: DenyUsers hannyيمكننا أيضًا استخدام محراف؟ لمطابقة حرفٍ واحد بالضبط. مثلًا: AllowUsers ?imالخيار السابق سيقوم بالسماح لجميع المستخدمين الذين يتكوّن اسمهم من 3 حروف، وينتهي اسمهم بـim، مثل "jim" ،"tim" ،"vim". يمكننا أن نكون أكثر تحديدًا كذلك، يمكننا استخدام الشكل user@hostname بهدف تقييد تسجيل الدخول إلى موقعٍ معيّن فقط من قبل أجهزة العملاء، كمثال، يمكنك كتابة: AllowUsers demouser@host1.com fakeuserسيقوم هذا الخيار بالسماح للمستخدم fakeuser بتسجيل الدخول من أيّ مكان، بينما لن يسمح للمستخدم demouser بأن يقوم بتسجيل الدخول إلّا من مستضيف يدعى host1.com. يمكننا كذلك تقييد عمليات تسجيل الدخول بناءً على اسم المستضيف من خارج ملفّ sshd_config عبر أغلفة TCP Wrappers. يمكن القيام بهذا عبر الملفّين etc/hosts.allow/ و etc/hosts.deny/. كمثال، يمكننا تقييد الوصول عبر SSH بناءً على اسم مستضيفٍ معيّن عبر إضافة السطر التالي إلى ملفّ hosts.allow: sshd: .example.comوبافتراض أننا نمتلك السطر التالي كذلك في ملفّ hosts.deny: sshd: allفإنّه سيتم السماح بعمليات تسجيل الدخول عبر SSH فقط من الاتصالات القادمة من example.com أو من واحدٍ من نطاقاته الفرعية. استخدام خيارات Match لإضافة الاستثناءاتيمكننا التحكّم بخياراتنا بشكلٍ أكبر عبر استخدام خيارات "match". تعمل خيارات Match عبر تحديد نمطٍ معيّن ليكون الفيصل فيما إذا كان خيارٌ ما سيتم تطبيقه أم لا. نبدأ عبر كتابة الخيار Match ومن ثم نقوم بتحديد مجموعة من قيم المفاتيح التي نريد تطبيقها، المفاتيح الموجودة هي "User", "Group", "Host", و "Address". يمكننا الفصل فيما بين كلّ مُدخَلة بمسافة وفصل كلّ نمط (user1, user2) بفاصلة. يمكننا كذلك تطبيق إشارات الاستبعاد (!) مثلًا إن أردنا: Match User !demouser,!fakeuser Group sshusers Host *.example.comيقوم السطر السابق بالمطابقة فقط في حال كان المستخدم ليس demouser أو fakeuser، وكان المستخدم عضوًا في مجموعة sshusers، وكان المستخدم يتصل من مستضيف بعنوان example.com ، إذا تحققت كلّ الشروط السابقة فحينها فقط يتم إرجاع المطابقة بنجاح. يمكن للمعيار “Address” أن يستخدم مجموعة رموز CIDR netmask. الخيار الذي يتبع السطر Match سوف يتم تطبيقه فورًا في حال ما إذا تمّت المطابقة بنجاح. مدى هذه المطابقات الشرطية هو إلى نهاية ملفّ الإعدادات أو إلى بداية المطابقة الشرطية التالية. بسبب هذا، من المنصوح أن تقوم بوضع إعداداتك ومتغيّراتك الافتراضية في بداية الملفّ وأن تضع الاستثناءات في نهايته. بسبب هذه الجمل الشرطية، الخيار الذي يكون تحت جملة match غالبًا ما يتم إزاحته إلى اليمين قليلًا ليشير إلى أنّه تابعٌ لجملة match الشرطية. كمثال، يمكن للشرط أعلاه أن يبدو عند التطبيق كالتالي: Match User !demouser,!fakeuser Group sshusers Host *.example.com AuthorizedKeysFile /sshusers/keys/%u PasswordAuthentication yes X11Forwarding X11DisplayOffset 15تمتلك الوصول إلى مجموعة صغيرة من الخيارات فقط عندما تتعامل مع تقييدات الخيار match. للحصول على قائمةً كاملة، يمكنك مراجعة صفحة man الخاصّة بـsshd_config: man sshd_configابحث عن قسم "Match" لترى قائمة كاملة بالمتغيّرات المتوفّرة. الخاتمةكما ترى، يمكنك ضبط العديد من المتغيّرات الخاصّة بـSSH من طرف الخادوم والتي ستؤثّر على الطريقة التي يقوم المستخدمون من خلالها بتسجيل الدخول. تأكّد من اختبار تغييراتك بحذر قبل أن تقوم بتطبيقها بشكلٍ كامل على كامل الخادوم لتجنّب أيّ إعدادات خاطئة ومشاكل قد تحصل. تعلّم أساسيات إعداد ملفّ etc/ssh/sshd_conf/ هو خطوة ممتازة نحو فهم كيفية التحكّم بحذر بالوصول إلى خادومك، إنّها مهارةٌ ضرورية لأيّ مدير نظام لينكس. ترجمة -وبتصرف- للمقال How To Tune your SSH Daemon Configuration on a Linux VPS لصاحبه Justin Ellingwood.

من المهم لمطورّي ووردبريس أن يكونوا على اطّلاعٍ على تقنيات الحماية والأمان عند تطوير مواقع تعمل بسكربت ووردبريس أو تصميم قوالب جاهزة له، سنبدأ سلسلة من 4 دروس حول هذا الموضوع وسيكون درسنا اليوم عن "التثبيت". هناك عدّة أمور مهمّة لتأخذها بعين الاعتبار لضمان أمانٍ أعلى لموقعك ومن بينها: اختيار الاستضافة المناسبة يبدأ موقع ووردبريس المؤمّن بشكلٍ مثالي من اختيار استضافة مناسبة لموقعك، فمن دون استضافة آمنة وجيّدة السمعة عالميًا، فإنّ جهودك في مجال تأمين موقعك العامِل بووردبريس قد تذهب أدراج الرياح. على الجانب التقني، بِما أنّ ووردبريس يستخدم PHP وMySQL، فإنّ أيّ استضافة تعمل بنظام لينكس ستكون مناسبة، ولكن من المنصوح أن تبتعد عن استضافة GoDaddy و Yahoo! ومثيلاتها حيث أنّ هذه الاستضافات مصممة لتكون بسيطة للغاية مما يجعلها مُقيّدة في بعض الأحيان، وهو ما يعني أنّه غير مجهّزة لأيّ شيء أكثر من موقع ووردبريس عادي بسيط. إذا كنتَ تريد القيام بتعديل بعض الإعدادات على الخادوم لتحسين إعدادات الأمان، فإنّ القيام بهذا قد يكون صعبًا على تلك الاستضافات المقيّدة. ينصح معظم خبراء الحماية باستخدام استضافاتٍ توفّر خواديمًا افتراضية خاصّة (VPS). وهو ما يستخدمه Tony Perez المدير التنفيذي لـSucuri: يستخدم Tony العديد من الأدوات على خادومه للحماية والأمان، هذه الأدوات تريه من يقوم بتسجيل الدخول إلى خادومه، من يقوم بالتعديل على المواضيع.. وهكذا، كما أنّ هذه الأدوات تقوم بعرض WHOIS، الـDNS ونشاط البرمجيات الخبيثة إن كانت موجودة، كلّ واحدٍ من هذه الأدوات مصمم ليراقب جزءًا معيّنا من جزئيات الحماية على الخادوم، بالإضافة إلى أمورٍ قد لا تخطر على بال المستخدمين العاديين. ينصح Tony باستخدام إضافة Sucuri Scanner لفحص مواقع الووردبريس للتأكّد من حمايتها، كما ينوّه إلى أنّه هناك العديد من الإضافات الأخرى التي يمكنك البحث عنها من على مخزن إضافات ووردبريس. مشكلة سكربتات التثبيت بنقرة واحدة توفّر العديد من شركات الاستضافة الآن القيام بعملية تثبيت ووردبريس "بنقرة واحدة"، وهو ما يسمح للمستخدمين العاديين أن يمتلكوا موقع ووردبريس بسرعة أكثر من السابق، ولكن بالطبّع، السرعة لها تكلفة. يمكنك في الواقع تغيير هذه البيانات بسهولة إن أردت -وهو ما سنتحدّث عنه لاحقًا- ولكن المشكلة هنا هي في الافتراضات التي يظنّها الناس عن عمليات التثبيت بنقرة واحدة بسبب شركات الاستضافة، فهم يظنون أنّها آمنة ومحميّة، لسوء الحظّ، فهي ليست كذلك، مما يجعل طريق التثبيت اليدوي أفضل بكثيرٍ للحماية. كيفية تثبيت ووردبريس إذا كنتَ لا تستخدم عملية التثبيت بنقرة واحدة، فإنّ القيام بتثبيت ووردبريس بالطريقة اليدوية على خادومك يجب أن يستغرق حوالي 10 دقائق. ستحتاج إلى فهم أساسيات عمل بروتوكول نقل الملفّات FTP وقواعد البيانات. هناك عدّة دروس على الويب حول هذا الموضوع من البداية إلى النهاية، ولكننا لن نذكر تفاصيلها الآن في هذا المقال. بمجرّد أن تقوم برفع كلّ ملفّاتك إلى موقعك وبمجرّد أن تقوم بإعداد قاعدة البيانات، سيتم توجيهك إلى إعداد اسم المستخدم وكلمة المرور الخاصّيَن بووردبريس، من المستحسن أن تقوم باختيار اسم مستخدمٍ معقّد ومن الصعب أن يتم تخمينه من قبل المخترقين لحمايةٍ أعلى. نفس الشيء بالنسبة لكلمة المرور الخاصّة بك، اجعلها معقّدة قدر الإمكان وأضف إليها الأرقام والرموز والأحرف الكبيرة، لا تتركها بسيطة فتصبح عُرضةً لهجمات التخمين بسهولة، كلّما كانت كلمة المرور أكثر تعقيدًا وطولًا، كلّما صعب تخمينها وكسرها. تغيير اسم المستخدم "Admin" تحدّثنا بالفعل عن أهميّة تجنّب اسم المستخدم "admin" ولماذا يجب عليك أن تختارَ اسمًا معقدًا، ولكن لنفرض أنّك قمتَ بالفعل بتثبيت موقع ووردبريس جديد منذ فترة واستخدمت اسم المستخدم "admin" فيه، فستحتاج تغييره يدويًا من phpMyAdmin. افتراضيًا، لا يسمح لك ووردبريس بتغيير اسم المستخدم، ولكن يمكنك إنشاء مستخدمٍ جديد إن أردت وإعطاؤه صلاحياتٍ إدارية كاملة وحذف المستخدم "admin" وإسناد الصفحات والمقالات التي أنشئتها بالمستخدم القديم إلى المستخدم الجديد، ولكن إذا كنتَ تمتلك الكثير من الصفحات والمقالات فربّما تريد القيام بالأمر يدويًا. للقيام بذلك، قم بالدخول إلى لوحة cPanel الخاصّة بك (على افتراض أنّك تمتلك واحدة!) ثمّ ابحث عن phpMyAdmin وقم بفتحها، بعد هذا، ابحث عن قاعدة البيانات الخاصّة بموقعك وابحث عن جدول wp_users ضمنها. ابحث عن المستخدم "admin" واصغط على زر "Edit" أو تحرير بجانبه لتعديل اسم المستخدم، قم بتبديل الاسم واحفظه. بعد هذا، سيتم تلقائيًا تغيير اسم المستخدم في جميع أنحاء موقعك إلى الاسم الجديد ولن تحتاج إلى حذف شيء. الخاتمة في معظم الأحيان، يعتقد الناس أنّ أمان ووردبريس هو مسألة يمكن حلّها عبر إضافة ووردبريس، صحيحٌ أنّ هذا جزءٌ مهم من المعادلة ولكنّه ليس كلّ شيء، حيث أنّك تحتاج تأمين كلّ شيء منذ البداية. في الدرس القادم سنتطرق إلى كيفية تأمين ووردبريس بعد تثبيته عبر تأمين تسجيل الدخول إلى المنصة. ترجمة -وبتصرف- للمقال The WordPress Developer’s Guide to Security: Installation لصاحبته Brenda Barron.

سنقوم في هذا الدرس بإعداد خادوم بريد باستخدام Postfix، Dovecot، MySQL و SpamAssasin على توزيعة Ubuntu. بعد اتّباع هذا الدرس، ستكون قادرًا على إضافة نطاقات افتراضية (virtual domains)، المستخدمين والاختصارات إلى خادوم بريدك الإلكتروني، وليس هذا فقط، بل سيكون خادومك محميًا من هجمات السبام (Spam). المتطلّباتقبل البدء بإعداد خادوم البريد الخاصّ بك، من المهم أن يمتلك خادومك الافتراضي الخاص الأمور التالية: توجيه النطاق الرئيسي إلى عنوان الآي بي الخاصّ بخادومك.تثبيت وإعداد MySQL على الخادوم.مستخدم بصلاحيات الجذر (root privileges).إعداد وضبط اسم النطاق المؤهّل الكامل (FQDN). (إعداد FQDN).إضافي: شهادة SSL (إعداد شهادة SSL مجانية موقّعة).إضافي: تسجيل الدخول إلى المستخدم الجذر.سيكون من المفيد تثبيت الحزم باستخدام المستخدم الجذر حيث أنّك ستمتلك جميع الصلاحيات: sudo -iقم بكتابة كلمة المرور الخاصّة بالمستخدم. بمجرد نجاح العملية، سترى أنّ رمز $ قد تغيّر إلى #. الخطوة الأولى: تثبيت الحزمapt-get install postfix postfix-mysql dovecot-core dovecot-imapd dovecot-lmtpd dovecot-mysqlعندما يتم سؤالك عن إعدادات Postfix، اختر "Internet Site": سيقوم Postfix بسؤالك عن اسم بريد النظام الإلكتروني - يمكنك استخدام FQDN أو نطاقك الرئيسي إن أردت: الخطوة الثانية: إنشاء قاعدة بيانات MySQL، نطاقات افتراضية، المستخدمين والاختصاراتبعد أن انتهى التثبيت، سنقوم الآن بإنشاء قاعدة بيانات MySQL لإعداد 3 جداول مختلفة: واحدٌ للنطاقات، واحدٌ للمستخدمين والأخير سيكون للاختصارات (aliases). سنقوم بتسمية قاعدة البيانات بـ"servermail"، ولكن يمكنك استخدام أيّ اسمٍ تريده. لإنشاء قاعدة البيانات servermail: mysqladmin -p create servermailلتسجيل الدخول كالمستخدم الجذر في MySQL: mysql -u root -pقم بإدخال كلمة مرور MySQL الخاصّة بالمستخدم الجذر; إذا نجحت العملية فسترى: mysql >يجب علينا أولًا إنشاء مستخدمٍ جديد، حيث يكون مخصصًا لعملية الاستيثاق (authentication) الخاصّة بالبريد الإلكتروني، وسنقوم بإعطائه صلاحية SELECT: mysql > GRANT SELECT ON servermail.* TO 'usermail'@'127.0.0.1' IDENTIFIED BY 'mailpassword';نحتاج بعدها إلى إعادة تحميل صلاحيات MySQL لضمان تطبيقها بشكلٍ صحيح: mysql > FLUSH PRIVILEGES;وأخيرًا، يجب علينا استخدام قاعدة البيانات الجديدة لإنشاء الجداول وحفظ بياناتنا: mysql> USE servermail;سنقوم بإنشاء جدول خاصّ بالنطاقات التي نعرفها على أنّها نطاقات موثوقة: CREATE TABLE `virtual_domains` ( `id` INT NOT NULL AUTO_INCREMENT, `name` VARCHAR(50) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;سنقوم الآن بإنشاء جدول لحفظ المستخدمين فيه. ستقوم هنا بإضافة عناوين البريد الإلكتروني وكلمات المرور. من المهم جدًا أن تقوم بربط كلّ مستخدمٍ متوفّر بنطاقٍ ما: CREATE TABLE `virtual_users` ( `id` INT NOT NULL AUTO_INCREMENT, `domain_id` INT NOT NULL, `password` VARCHAR(106) NOT NULL, `email` VARCHAR(120) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `email` (`email`), FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8;وأخيرًا، سنقوم بإنشاء جدول اختصاراتٍ افتراضي لتحديد جميع عناوين البريد الإلكتروني التي تريد توجيهها إلى عناوين بريدية أخرى: CREATE TABLE `virtual_aliases` ( `id` INT NOT NULL AUTO_INCREMENT, `domain_id` INT NOT NULL, `source` varchar(100) NOT NULL, `destination` varchar(100) NOT NULL, PRIMARY KEY (`id`), FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8;لقد قمنا بإنشاء الجداول الثلاثة بنجاح. الآن سنقوم بإدخال البيانات. النطاقات الافتراضيةسنقوم هنا بإدخال النطاقات الخاصّة بك إلى جدول virtual_domains. يمكنك إضافة جميع النطاقات التي ترغب بها، ولكننا سنقوم في هذا الدليل بإضافة النطاق الرئيسي فقط (example.com) و اسم نطاقك المؤهّل الكامل (FQDN) والذي هو على شاكلة (hostname.example.com). INSERT INTO `servermail`.`virtual_domains` (`id` ,`name`) VALUES ('1', 'example.com'), ('2', 'hostname.example.com');عناوين البريد الإلكتروني الافتراصيةوالآن، سنقوم بإدخال عناوين البريد الإلكتروني وكلمات المرور المرتبطة بها إلى كلّ نطاقٍ على حدا. تأكّد من أنّك غيّرت جميع البيانات والمعلومات الموجودة بالشفرة أدناه لتناسب احتياجاتك قبل تطبيقها: INSERT INTO `servermail`.`virtual_users` (`id`, `domain_id`, `password` , `email`) VALUES ('1', '1', ENCRYPT('firstpassword', CONCAT('$6$', SUBSTRING(SHA(RAND()), -16))), 'email1@example.com'), ('2', '1', ENCRYPT('secondpassword', CONCAT('$6$', SUBSTRING(SHA(RAND()), -16))), 'email2@example.com');الاختصارات الوهمية:سنُدخِل عنوان البريد الإلكتروني (المصدر) الذي سنقوم بتوجيهه إلى عنوان البريد الإلكتروني الآخر (الوجهة): INSERT INTO `servermail`.`virtual_aliases` (`id`, `domain_id`, `source`, `destination`) VALUES ('1', '1', 'alias@example.com', 'email1@example.com');للخروج من MySQL: mysql > exitالخطوة الثالثة: إعداد Postfixسنقوم بإعداد Postfix ليستلم معالجة اتصالات SMTP وإرسال الرسائل إلى كلّ مستخدمٍ موجود في قاعدة بيانات MySQL. أولًا، يجب علينا إنشاء نسخة من الملفّ الافتراضي، في حال أردنا استرجاع الإعدادات الافتراضي إذا حصلت مشكلةٌ ما: cp /etc/postfix/main.cf /etc/postfix/main.cf.origافتح ملف main.cf لتعديله: nano /etc/postfix/main.cfأولًا سنحتاج إلى القيام بوضع إشارة تعليق (#) على مُعامِلات TLS وإضافة مُعامِلات جديدة من هذا الدرس، سنقوم باستخدام شهادات SSL المجانية والمسارات التي تم اقتراحها في هذا الدليل (رابط)، ولكن يمكنك تعديل الأمور بناءً على احتياجاتك الشخصية: # TLS parameters #smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem #smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key #smtpd_use_tls=yes #smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache #smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtpd_tls_cert_file=/etc/ssl/certs/dovecot.pem smtpd_tls_key_file=/etc/ssl/private/dovecot.pem smtpd_use_tls=yes smtpd_tls_auth_only = yesثم سنقوم بإضافة المُعامِلات التالية إلى أسفل إعدادات TLS التي قمنا بتغييرها بالخطوة السابقة: smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth smtpd_sasl_auth_enable = yes smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destinationنحتاج الآن إلى القيام بوضع إشارة تعليق (#) قبل سطر mydestination واستبداله بـlocalhost. سيسمح هذا التغيير لخادومك الافتراضي الخاصّ باستخدام النطاق الافتراضي الموجود داخل جدول قاعدة MySQL. #mydestination = example.com, hostname.example.com, localhost.example.com, localhost mydestination = localhostتأكّد أنّ مُعامِل myhostname مضبوط على الـFQDN الخاصّ بك: myhostname = hostname.example.comقم بإضافة السطر التالي ليتم إرسال الرسائل إلى جميع النطاقات الافتراضية الموجودة داخل جدول MySQL: virtual_transport = lmtp:unix:private/dovecot-lmtpوأخيرًا، نحتاج إلى إضافة هذه المُعامِلات الثلاثة لنخبر Postfix أن يقوم بإعداد النطاقات الافتراضية، المستخدمين والاختصارات: virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cfملاحظة: قارن هذه التغييرات مع هذا الملف لتتأكد من عدم وجود أخطاء: https://www.dropbox.com/s/x9fpm9v1dr86gkw/etc-postfix-main.cf.txtسنقوم بإنشاء الملفّات الثلاثة الأخيرة التي قمنا بإدراجها في ملف main.cf لنخبر Postfix كيف يتصل بـMySQL. أولًا، نحتاج إلى إنشاء ملف mysql-virtual-mailbox-domains.cf . إنّه ضروري لتغيير قِيَم الإعدادات بناءً على احتياجاتك الخاصّة: nano /etc/postfix/mysql-virtual-mailbox-domains.cf user = usermail password = mailpassword hosts = 127.0.0.1 dbname = servermail query = SELECT 1 FROM virtual_domains WHERE name='%s'ثم نحتاج إلى إعادة تشغيل Postfix: service postfix restartيجب علينا أن نضمن قيام Postfix بإيجاد النطاق الخاصّ بك، لذا نحتاج اختباره باستخدام الأمر التالي، إذا نجح الأمر فسيتم طباعة رقم 1: postmap -q example.com mysql:/etc/postfix/mysql-virtual-mailbox-domains.cfوالآن، يجب علينا إنشاء ملف mysql-virtual-mailbox-maps.cf: nano /etc/postfix/mysql-virtual-mailbox-maps.cf user = usermail password = mailpassword hosts = 127.0.0.1 dbname = servermail query = SELECT 1 FROM virtual_users WHERE email='%s'ثم يجب علينا إعادة تشغيل Postfix مجددًا: service postfix restartفي هذه النقطة، سنتأكّد من أنّ Postfix سيجد عنوان البريد الإلكتروني الأول الخاصّ بك باستخدام الأمر التالي، يجب أن يتم إرجاع الرقم 1 في حال نجحت العملية: postmap -q email1@example.com mysql:/etc/postfix/mysql-virtual-mailbox-maps.cfوأخيرًا، سنقوم بإنشاء آخر ملفّ لإعداد الاتصال بين Postfix و MySQL: nano /etc/postfix/mysql-virtual-alias-maps.cf user = usermail password = mailpassword hosts = 127.0.0.1 dbname = servermail query = SELECT destination FROM virtual_aliases WHERE source='%s'قم بإعادة تشغيل Postfix: service postfix restartيجب أن نضمن أيضًا أنّ Postfix سيعثر على الاختصارات الخاصّة بك. قم بإدخال الأمر التالي ويجب أن يتم طباعة البريد الإلكتروني الذي يتم توجيهه إلى الاختصار: postmap -q alias@example.com mysql:/etc/postfix/mysql-virtual-alias-maps.cfإذا أردت تفعيل المنفذ 587 للاتصال بشكلٍ آمن باستخدام برامج البريد الإلكتروني (email clients)، فمن الضروري أن تقوم بتعديل ملفّ /etc/postfix/master.cf: nano /etc/postfix/master.cfنحتاج إلى إلغاء تعليق السطور التالية وإضافة سطور أخرى: submission inet n - - - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,rejectفي بعض الحالات، نحتاج إلى إعادة تشغيل Postfix لكي يتم فتح المنفذ 587: service postfix restartملاحظة: يمكنك استخدام هذه الأداة لفحص منافذ نطاقك والتأكّد من أنّ المنفذين 25 و 587 مفتوحان (http://mxtoolbox.com/SuperTool.aspx) الخطوة الرابعة: إعداد Dovecotسنقوم بنسخ الـ7 ملفّات التي سنقوم بتعديلها هنا، لكي نكون قادرين على استرجاعها في حال ما إذا حصلت مشكلة. أدخل الأوامر التالية الواحد تلو الآخر: cp /etc/dovecot/dovecot.conf /etc/dovecot/dovecot.conf.orig cp /etc/dovecot/conf.d/10-mail.conf /etc/dovecot/conf.d/10-mail.conf.orig cp /etc/dovecot/conf.d/10-auth.conf /etc/dovecot/conf.d/10-auth.conf.orig cp /etc/dovecot/dovecot-sql.conf.ext /etc/dovecot/dovecot-sql.conf.ext.orig cp /etc/dovecot/conf.d/10-master.conf /etc/dovecot/conf.d/10-master.conf.orig cp /etc/dovecot/conf.d/10-ssl.conf /etc/dovecot/conf.d/10-ssl.conf.origثمّ لتعديل ملفّ الإعدادات من Dovecot: nano /etc/dovecot/dovecot.confوتأكّد أنّ هذا الخيار ليس مُعلّقًا (لا يوجد إشارة # قبله): chown -R vmail:vmail /var/mailثمّ سنحتاج إلى تعديل ملفّ /etc/dovecot/conf.d/10-auth.conf: nano /etc/dovecot/conf.d/10-auth.confقم بإلغاء تعليق سطر استيثاق النصّ الصرف (plain text authentication) وأضف هذا السطر: disable_plaintext_auth = yesقم بتعديل مُعامِل auth_mechanisms: auth_mechanisms = plain loginوقم بتعليق هذا السطر: auth_mechanisms = plain loginالآن، قم بتفعيل استيثاق MySQL عبر إلغاء تعليق هذا السطر: !include auth-sql.conf.extملاحظة: قارن تغييراتك بهذا الملفّ: https://www.dropbox.com/s/4h472nqrj700pqk/etc.dovecot.conf.d.10-auth.conf.txtنحتاج إنشاء ملفّ /etc/dovecot/dovecot-sql.conf.ext والذي سيحتوي على معلومات الاستيثاق الخاصّة بك: nano /etc/dovecot/conf.d/auth-sql.conf.extقم بإدخال الشفرة التالية في الملفّ: passdb { driver = sql args = /etc/dovecot/dovecot-sql.conf.ext } userdb { driver = static args = uid=vmail gid=vmail home=/var/mail/vhosts/%d/%n }نحتاج تعديل ملفّ /etc/dovecot/dovecot-sql.conf.ext وإضافة معلومات MySQL الخاصّة بنا: nano /etc/dovecot/dovecot-sql.conf.extقم بإلغاء تعليق مُعامِل driver وقم بتعيين mysql فيه: driver = mysqlقم بإلغاء تعليق مُعامِل connect وأضف البيانات الخاصّة بإعدادات MySQL لديك: connect = host=127.0.0.1 dbname=servermail user=usermail password=mailpasswordقم بإلغاء تعليق سطر defaultpassscheme وغيّره إلى SHA-512: default_pass_scheme = SHA512-CRYPTقم بإلغاء تعليق سطر password_query وأضف هذه المعلومات: password_query = SELECT email as user, password FROM virtual_users WHERE email='%u';ملاحظة: قارن تغييراتك مع هذا الملفّ: https://www.dropbox.com/s/48a5r0mtgdz25cz/etc.dovecot.dovecot-sql.conf.ext.txtالآن، قم بتغيير المالك ومجموعة مجلّد dovecot إلى المستخدم vmail: chown -R vmail:dovecot /etc/dovecot chmod -R o-rwx /etc/dovecotافتح وعدّل ملفّ /etc/dovecot/conf.d/10-master.conf (وكن حذرًا، لأنّه هناك أكثر من مُعامِل يجب تغييره): nano /etc/dovecot/conf.d/10-master.conf ##Uncomment inet_listener_imap and modify to port 0 service imap-login { inet_listener imap { port = 0 } #Create LMTP socket and this configurations service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { mode = 0600 user = postfix group = postfix } #inet_listener lmtp { # Avoid making LMTP visible for the entire internet #address = #port = #} }قم بتعديل مُعامِل unixlistener إلى serviceauth كالتالي: service auth { unix_listener /var/spool/postfix/private/auth { mode = 0666 user = postfix group = postfix } unix_listener auth-userdb { mode = 0600 user = vmail #group = } #unix_listener /var/spool/postfix/private/auth { # mode = 0666 #} user = dovecot }عدّل service auth-worker كالتالي: service auth-worker { # Auth worker process is run as root by default, so that it can access # /etc/shadow. If this isn't necessary, the user should be changed to # $default_internal_user. user = vmail }ملاحظة: قارن تغييراتك بهذا الملفّ: https://www.dropbox.com/s/g0vnt233obh6v2h/etc.dovecot.conf.d.10-master.conf.txtوأخيرًا، سنقوم بتعديل ملفّ إعدادات SSL من Dovecot (تخطّى هذه الخطوة في حال كنتَ تريد استخدام الإعدادات الافتراضية): nano /etc/dovecot/conf.d/10-ssl.confغيّر مُعامَل SSL إلى required: ssl = requiredعدّل المسار لـsslcert و sslkey: ssl_cert = </etc/ssl/certs/dovecot.pem ssl_key = </etc/ssl/private/dovecot.pemوقم بإعادة تشغيل Dovecot: service dovecot restartيجب أن تتأكّد أنّ المنفذ 993 يعمل ومفتوح: telnet example.com 993تهانينا!، لقد قمتَ بنجاح بإعداد خادوم بريدك الأول ويمكنك اختبار الإعدادات التالية باستخدام أحد برامج إدارة البريد الإلكتروني: - Username: email1@example.com - Password: email1's password - IMAP: example.com - SMTP: example.comملاحظة: استخدام المنفذ 993 لـIMAP المؤمّن و 587 أو 25 لـSMTP. الخطوة الخامسة: إعداد SpamAssassinنحتاج أولًا إلى تثبيت SpamAssassin: apt-get install spamassassin spamcثمّ يجب علينا إنشاء مستخدمٍ خاص بـSpamAssassin: adduser spamd --disabled-loginلإعداد SpamAssassin بنجاح، من الضروري أن تفتح وتعدّل ملفّ الإعدادات: nano /etc/default/spamassassinيجب علينا تغيير مُعامِل ENABLED لتفعيل SpamAssasin: ENABLED=1كما ونحتاج إلى تغيير مُعامِلات مجلّد المنزل والخيارات: SPAMD_HOME="/home/spamd/" OPTIONS="--create-prefs --max-children 5 --username spamd --helper-home-dir ${SPAMD_HOME} -s ${SPAMD_HOME}spamd.log"ثمّ نحتاج إلى تعديل مُعامِل PID_FILE بالشكل التالي: PIDFILE="${SPAMD_HOME}spamd.pid"وأخيرًا، نحتاج إلى تحديد أنّ قواعد SpamAssasins يجب أن يتم تحديثها تلقائيًا: CRON=1ملاحظة: قارن تغييراتك بهذا الملفّ: PIDFILE="${SPAMD_HOME}spamd.pid"نحتاج الآن إلى فتح /etc/spamassassin/local.cf لإعداد القواعد التي ستحدّ من هجمات السبام (Spam): nano /etc/spamassassin/local.cfسيقوم SpamAssasin بتسجيل كلّ بريدٍ إلكتروني ويفحص ما إذا كان هذا البريد الإلكتروني يمتلك 5 نقط أو أعلى في اختبار فحص السبام، وإن كان كذلك فسيقوم تلقائيًا باعتباره سبام. يمكنك استخدام المُعامِلات التالية لإعداد القواعد المُضادة للسبام: rewrite_header Subject ***** SPAM _SCORE_ ***** report_safe 0 required_score 5.0 use_bayes 1 use_bayes_rules 1 bayes_auto_learn 1 skip_rbl_checks 0 use_razor2 0 use_dcc 0 use_pyzor 0نحتاج إلى تغيير ملفّ /etc/postfix/master.cf لنخبره أنّه سوف يتم التحقق من كلّ بريدٍ إلكترونيٍ وارد بواسطة SpamAssasin: nano /etc/postfix/master.cfثمّ نحتاج إلى العثور على السطر التالي وإضافة مرشّح spamassasin: smtp inet n - - - - smtpd -o content_filter=spamassassinوأخيرًا نحتاج إلى إضافة المُعامِلات التالية: spamassassin unix - n n - - pipe user=spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}يجب الآن إعادة تشغيل كلٍّ من Postfix و SpamAssasin لكي تأخذ التغييرات مكانها: service spamassassin start service postfix restart*تهانينا! لقد قمتَ بنجاح بإعداد خادوم بريدٍ إلكتروني باستخدام Postfix و Dovecot مع استيثاق MySQL وحماية ضدّ هجمات السبام باستخدام SpamAssasin ! حظًا موفقًا يا صاح! ترجمة -وبتصرّف- للمقال: How To Configure a Mail Server Using Postfix, Dovecot, MySQL, and SpamAssasin.

هل تريد الوصول إلى شبكة الإنترنت بشكلٍ آمن ومحمي من هاتفك الذكي أو حاسوبك المحمول عندما تقوم بالاتصال بشبكاتٍ غير موثوقة مثل الشبكات اللاسلكية العمومية لفندق أو مقهى؟ تسمح لك الشبكة الافتراضية الخاصّة (Virtual Private Network - VPN) بتصفّح الإنترنت بالشبكات غير الموثوقة بشكلٍ آمن ومجهول كما لو كنتَ على شبكةٍ آمنة وموثوقة. يتم تمرير تدفّق البيانات (traffic) من خادومك إلى وجهته ومن ثمّ يعود إليك حاملًا البيانات. يسمح لك هذا الإعداد عندما يتم ربطه مع [اتصال HTTPS] (https://en.wikipedia.org/wiki/HTTP_Secure) أن تقوم بتأمين عمليات تسجيل الدخول وعمليات الدفع وغيرها من العمليات التي تقوم بها عند تصفّحك للإنترنت. يمكنك تخطّي الحجب الذي يفرضه مزوّد الخدمة على مواقع معيّنة مثلًا وتخطّي تقييدات المنطقة الجغرافية لمواقع معيّنة، كما يمكنك تحصين موقعك وتدفّق HTTP الصادر من جهازك من الشبكات غير المحمية. OpenVPN هو عبارة عن شبكة افتراضية خاصّة لطبقة حِزَم البيانات الآمنة مفتوحة المصدر (SSL) ويقبل تشكيلةً واسعة من الإعدادات والتخصيصات. في هذا الدرس، سنقوم بإعداد خادوم OpenVPN على خادومنا ومن ثمّ نقوم بإعداده ليقبل الوصول إليه من نظام ويندوز، Mac OS X، iOS و Android. سنبقي خطوات التثبيت والإعداد أسهل ما يمكن في هذا الدرس. المتطلّباتالمتطلّبات الوحيدة اللازمة هي امتلاك خادوم يعمل بتوزيعة Ubuntu 14.04. يجب أن تمتلك الوصول إلى حساب المستخدم الجذر لإكمال هذا الدرس. إضافي: بعد إكمال هذا الدرس، سيكون من الجيد إنشاء حساب مستخدمٍ عادي بصلاحيات sudo لعمل صيانةٍ عامّة على خادومك في حال احتجتها مستقبلًا.الخطوة الأولى: تثبيت وإعداد بيئة خادوم OpenVPNإعداد OpenVPNقبل أن نقوم بتثبيت أيّ حزم، يجب أن نقوم بتحديث قوائم مستودعات توزيعة أوبونتو أولًا: apt-get updateومن ثمّ، يمكننا تثبيت OpenVPN و Easy-RSA: apt-get install openvpn easy-rsaيجب أن يتم استخراج ملفّ عيّنة إعدادات OpenVPN إلى المسار /etc/openvpn لكي نتمكّن من إضافته إلى عملية التثبيت الخاصّة بنا. يمكن القيام بهذا عبر الأمر: gunzip -c /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz > /etc/openvpn/server.confبمجرّد أن يتم استخراجه، افتح ملفّ server.conf في محرر نصوص. في هذا الدرس سنستخدم Vim ولكن يمكنك استخدم أيّ محرر نصوص تريده: vim /etc/openvpn/server.confهناك العديد من التغييرات التي يجب علينا تطبيقها على هذا الملفّ. سترى قسمًا يبدو هكذا: # Diffie hellman parameters. # Generate your own with: # openssl dhparam -out dh1024.pem 1024 # Substitute 2048 for 1024 if you are using # 2048 bit keys. dh dh1024.pemقم بتغيير dh1024.pem إلى: dh2048.pemسيقوم هذا بمضاعفة طول مفتاح RSA المُستخدم عندما يتم إنشاء مفاتيح الخادوم والعميل. ما نزال في ملفّ server.conf، والآن ابحث عن هذا القسم: # If enabled, this directive will configure # all clients to redirect their default # network gateway through the VPN, causing # all IP traffic such as web browsing and # and DNS lookups to go through the VPN # (The OpenVPN server machine may need to NAT # or bridge the TUN/TAP interface to the internet # in order for this to work properly). ;push "redirect-gateway def1 bypass-dhcp"قم بإلغاء تعليق السطر التالي (أزل إشارة # أو ; من قبله): ;push "redirect-gateway def1 bypass-dhcp" لكي يتمكّن خادوم OpenVPN الخاصّ بنا من تمرير التدفّق المطلوب من المستخدمين والعملاء إلى وجهته المطلوبة. يجب أن يبدو السطر هكذا بعد التعديل: push "redirect-gateway def1 bypass-dhcp"الآن ابحث عن هذا القسم: # Certain Windows-specific network settings # can be pushed to clients, such as DNS # or WINS server addresses. CAVEAT: # http://openvpn.net/faq.html#dhcpcaveats # The addresses below refer to the public # DNS servers provided by opendns.com. ;push "dhcp-option DNS 208.67.222.222" ;push "dhcp-option DNS 208.67.220.220"قم بإلغاء تعليق السطرين push "dhcp-option DNS 208.67.222.222" و push "dhcp-option DNS 208.67.220.220" . يجب أن يبدوا على هذا الشكل: push "dhcp-option DNS 208.67.222.222" push "dhcp-option DNS 208.67.220.220"يقوم هذا بإخبار الخادوم بأن يقوم بدفع OpenVPN ليتصل بالعملاء (clients) ليعطيهم عنوان الـDNS المخصص. يقوم هذا الأمر بحماية المستخدم من خروج طلبات DNS خارج اتصال الـVPN. وعلى كلّ حال، من المهم أن تقوم بتحديد عناوين الـDNS المطلوبة التي تريد استخدامها على كلّ جهازٍ من أجهزة العملاء. رغم أنّ OpenVPN يستخدم خدمة OpenDNS افتراضيًا إلّا أنّه يمكنك استخدامه أيّ خدمات DNS تريدها. القسم الأخير الذي يجب تغييره في ملفّ server.conf هو: # You can uncomment this out on # non-Windows systems. ;user nobody ;group nogroupقم بإلغاء تعليق كلٍّ من السطرين user nobody و group nobody. يجب أن يبدوا هكذا: user nobody group nogroupافتراضيًا، يقوم OpenVPN بالعمل باستخدام المستخدم الجذر (root) حيث يمتلك هذا الأخير وصولًا كاملًا إلى النظام. سنقوم عوضًا عن هذا بجعل OpenVPN يستخدم المستخدم nobody والمجموعة nobody. هذا المستخدم لا يمتلك صلاحيات ولا أيّ إمكانياتٍ للولوج، ويتم استخدامه عادةً لتشغيل التطبيقات غير الموثوقة مثل خواديم واجهات الويب. يمكنك الآن حفظ تغييراتك والخروج من VIM. توجيه حِزَم البياناتهذا الأمر هو عبارة عن خاصية sysctl تقوم بإخبار نواة الخادوم أن تقوم بتوجيه التدفّق من أجهزة العملاء إلى الإنترنت. إن لم يتم هذا الأمر، فإنّ التدفّق سيتوقف في الخادوم. يمكنك تفعيل توجيه حِزَم البيانات أثناء وقت التشغيل باستخدام الأمر التالي: echo 1 > /proc/sys/net/ipv4/ip_forwardنحتاج أن نقوم بجعل هذا الأمر دائمًا بحيث يبقى الخادوم يقوم بتوجيه التدفّق حتى بعد إعادة تشغيل الخادوم: vim /etc/sysctl.confفي بداية ملفّ sysctl ستجد: # Uncomment the next line to enable packet forwarding for IPv4 #net.ipv4.ip_forward=1قم بإلغاء تعليق net.ipv4.ip_forward. يجب أن يبدو ذاك السطر هكذا: # Uncomment the next line to enable packet forwarding for IPv4 net.ipv4.ip_forward=1احفظ تغييراتك واخرج. الجدار الناري غير المعقّد (ufw)ufw هو واجهة أمامية (front-end) لـiptables. إعداد ufw ليس صعبًا. وهو مُضمّن بشكلٍ افتراضي في Ubuntu 14.04، لذا يجب علين فقط إنشاء بضع قواعد (rules) وتعديل بعض الإعدادات ليعمل، ومن ثمّ سنقوم بتشغيله. للمزيد من المعلومات حول ufw يمكنك مراجعة كيفية إعداد جدارٍ ناري باستخدام UFW على خادوم أوبونتو ودبيان السحابي. أولًا قم بضبط ufw بحيث يسمح باتصال SSH. أدخل اﻷمر التالي: ufw allow sshسنستخدم OpenVPN عبر UDP في هذا الدرس، لذا يجب أن يسمح UFW بتدفّق UDP عبر المنفذ 1194: ufw allow 1194/udpيجب ضبط سياسة التوجيه في UFW كذلك. يمكنك القيام هذا عبر تعديل ملفّ إعدادات UFW الرئيسي: vim /etc/default/ufwابحث عن DEFAULTFORWARDPOLICY="DROP". يجب تغيير محتوى هذا السطر من DROP إلى ACCEPT. يجب أن يبدو السطر هكذا عندما تنتهي منه: DEFAULT_FORWARD_POLICY="ACCEPT"ثمّ سنقوم بإضافة بعض قواعد UFW الإضافية لترجمة عناوين الشبكة وتذكّر عناوين الـIP الخاصّة بالعملاء الحاليين: vim /etc/ufw/before.rulesقم بجعل بداية ملفّ before.rules الخاصّ بك تبدو هكذا كما بالمثال أدناه. القسم بعد START OPENVPN RULES وقبل END OPENVPN RULES هو ما يجب إضافته: # # rules.before # # Rules that should be run before the ufw command line added rules. Custom # rules should be added to one of these chains: # ufw-before-input # ufw-before-output # ufw-before-forward # # START OPENVPN RULES # NAT table rules *nat :POSTROUTING ACCEPT [0:0] # Allow traffic from OpenVPN client to eth0 -A POSTROUTING -s 10.8.0.0/8 -o eth0 -j MASQUERADE COMMIT # END OPENVPN RULES # Don't delete these required lines, otherwise there will be errors *filterبعدما تمّ تطبيق هذه التغييرات على UFW، يمكننا الآن تفعيله. أدخل اﻷمر التالي في سطر الأوامر: ufw enableوسيتم طباعة الخرج التالي: Command may disrupt existing ssh connections. Proceed with operation (y|n)?للتحقق من حالة قواعد الجدار الناري طبّق: ufw statusوالخرج يجب أن يكون: Status: active To Action From -- ------ ---- 22 ALLOW Anywhere 1194/udp ALLOW Anywhere 22 (v6) ALLOW Anywhere (v6) 1194/udp (v6) ALLOW Anywhere (v6)الخطوة الثانية: إنشاء استيثاق الشهادات و شهادة موقّعة من الخادوم ومفتاح لهايستخدم OpenVPN الشهادات ليقوم بتشفير التدفّق. إعداد وبناء استيثاق الشهاداتالآن هو وقت إعداد استيثاق الشهادات الخاصّ بنا (Certificate Authority - CA) وإنشاء شهادة ومفتاح لخادوم الـOpenVPN. يدعم OpenVPN الاستيثاق ثنائي الاتجاه (bidirectional authentication) باستخدام الشهادات، مما يعني أنّه يجب على العميل أن يقوم باستيثاق شهادة الخادوم ويجب على الخادوم أن يقوم باستيثاق شهادة العميل قبل أن يتم إنشاء الاتصال المشترك بينهما. سنستخدم سكربتات Easy RSA التي نسخناها مبكّرًا للقيام بهذا. أولًا، انسخ سكربتات Easy RSA إلى مكانها: cp -r /usr/share/easy-rsa/ /etc/openvpnثمّ قم بعمل مجلّد لتخزين المفاتيح: mkdir /etc/openvpn/easy-rsa/keysتمتلك Easy-RSA ملفّ متغيّرات يمكننا تعديله لإنشاء شهاداتٍ خاصّة بشخصنا، شركاتنا أو أيّ شيءٍ آخر نريده. يتم نسخ هذه المعلومات إلى الشهادات والمفاتيح، وستساعد هذه المعلومات على التعرّف على المفاتيح لاحقًا: vim /etc/openvpn/easy-rsa/varsالمتغيّرات بين علامتيّ تنصيص (") يجب أن تقوم بتغييرها بناءً على إعداداتك: export KEY_COUNTRY="US" export KEY_PROVINCE="TX" export KEY_CITY="Dallas" export KEY_ORG="My Company Name" export KEY_EMAIL="sammy@example.com" export KEY_OU="MYOrganizationalUnit"في نفس الملفّ vars، قم أيضًا بتعديل السطر الظاهر أدناه، سنستخدم server كاسم المفتاح. إذا أردت استخدام اسمٍ آخر، فسيجب عليك أيضًا تحديث ملفّات إعدادات OpenVPN التي تقوم بالإشارة إلى server.key و server.crt: export KEY_NAME="server"نحتاج إلى إنشاء مُعامِلات Diffie-Hellman; قد يأخذ هذا الأمر بضع دقائق: openssl dhparam -out /etc/openvpn/dh2048.pem 2048الآن فلنغيّر المسارات بحيث نعمل في المسارات الذي نقلنا سكربتات Easy-RSA إليه من قبل في الخطوة الثانية: cd /etc/openvpn/easy-rsaقم بتحليل ملفّ (PKI (Public Key Infrastructure. انتبه إلى النقطة (.) و المسافة (space) قبل الأمر vars/. حيثُ أنّ هذا الأمر قد يغيّر المسار الحالي كلّيًا (المصدر): . ./varsخرج الأمر أعلاه ظاهرٌ أدناه. بما أننا لم نقم بإنشاء أيّ شيء في مجلّد keys بعد، فإنّ رسالة التحذير ليست شيئًا لنقلق حوله الآن: NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keysالآن سنقوم بتنظيف مسار عملنا الحالي من أيّ ملفّات عيّنة مفاتيح أو مفاتيح قديمة لكي تبقى المفاتيح الجديدة بالمسار فقط: ./clean-allسيبني هذا الأمر الأخير استيثاق الشهادات (CA) عبر استدعاء طرفيّة OpenSSL التفاعلية. سيسألك الخرج أن تقوم بتأكيد اسم المتغيرات الفريدة التي أدخلناها من قبل في ملفّ متغيّرات Easy-RSA (اسم البلد، المنظمة.. إلخ): ./build-caاضغط مفتاح Enter ببساطة لتتنقل عبر كلّ طرفية. إذا كان هناك شيءٌ يجب تغييره، فيمكنك القيام بذلك عبر سطر الأوامر. إنشاء شهادة ومفتاح للخادومما زلنا نعمل من المسار /etc/openvpn/easy-rsa ، الآن قم بإدخال الأمر التالي لبناء مفتاح الخادوم. حيث سترى أنّ server هو قيمة المتغيّر export KEY_NAME الذي أعددناه في ملفّ vars الخاصّ بـEasy-RSA من قبل بالخطوة الثانية: ./build-key-server serverيظهر خرج مشابه كالذي يظهر عندما طبّقنا ./build-ca ، ويمكنك مجددًا الضغط على مفتاح Enter لتأكيد كلّ سطرٍ من الأسماء الفريدة. على كلّ حال، هذه المرّة هناك إدخالان إضافيان: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:يجب أن يتم تركهما كلاهما فارغين، لذا فقط اضغط Enter للمتابعة. هناك سؤالان إضافيان في النهاية، وهما يتطلبان إجابة ( y ) إيجابية فقط: Sign the certificate? [y/n] 1 out of 1 certificate requests certified, commit? [y/n]يجب أن يكتمل السؤال الأخير أعلاه بالتالي: Write out database with 1 new entries Data Base Updatedنقل شهادات الخادوم والمفاتيحيتوقّع OpenVPN أن يرى استيثاق شهادات الخادوم، الشهادات والمفاتيح في /etc/openvpn . فلننسخها إلى الموقع الصحيح: cp /etc/openvpn/easy-rsa/keys/{server.crt,server.key,ca.crt} /etc/openvpnيمكنك التحقق من نجاح العملية عبر: ls /etc/openvpnيجب أن ترى ملفّات الشهادات والمفاتيح الخاصّة بالخادوم. في هذه النقطة، أصبح خادوم OpenVPN جاهزًا للانطلاق. شغّله وتحقق من حالته باستخدام: service openvpn start service openvpn statusيجب أن يقوم أمر التحقق من الحالة بإرجاع الخرج التالي لك: VPN 'server' is runningتهانينا! أصبح خادوم OpenVPN الخاصّ بك عاملًا! إذا كانت رسالة الحالة تقول لك أنّ خادوم الـOpenVPN لا يعمل، فتحقق من ملفّ /var/log/syslog وابحث عن أخطاء مثل: Options error: --key fails with 'server.key': No such file or directoryوالتي تقوم أنّ ملفّ server.key لم يتم نسخه إلى المسار etc/openvpn/ بشكلٍ صحيح، مما يتوجب عليك إعادة نسخه مجددًا. الخطوة الثالثة: إنشاء الشهادات والمفاتيح الخاصّة بالعملاءلقد قمنا بتثبيت وإعداد خادوم OpenVPN، أنشأنا استيثاق الشهادات وشهادة ومفتاح الخادوم. في هذه الخطوة الآن، سنستخدم استيثاق شهادات الخادوم لنقوم بإنشاء الشهادات والمفاتيح الخاصّة بجهاز كلّ عميلٍ سيتصل بالخادوم على حدى. سيتم تثبيت هذه الملفّات لاحقًا إلى أجهزة العملاء كالهواتف الذكية والأجهزة المحمولة. بناء المفاتيح والشهاداتمن المناسب أن يمتلك كلّ عميلٍ يتصل بالخادوم شهادته ومفتاحه الخاصّين به. هذا الأمر مفضّل على إنشاء شهادة واحدة ومفتاح واحد وتوزيعهما على جميع أجهزة العملاء لأغراض تتعلق بالأمان. ملاحظة: افتراضيًا، لا يسمح OpenVPN بالاتصالات المتزامنة بنفس الوقت إلى الخادوم من أكثر من جهازٍ عميل باستخدام نفس الشهادة والمفتاح (انظر duplicate-cn في etc/openvpn/server.conf/). لإنشاء شهادات استيثاق منفصلة لكلّ جهاز عميل تنوي السماح له بالاتصال بخادوم الـOpenVPN، يجب عليك إكمال هذه الخطوة لكلّ جهاز، ولكن يمكنك تغيير الاسم client1 أدناه إلى شيءٍ مختلف مثل client2 أو iphone2. بفضل استخدام شهادةٍ منفصلة لكلّ جهاز عميل، يمكن لاحقًا منعهم بشكلٍ منفصل من الوصول إلى الخادوم إذا ما تمّ الاحتياج لذلك. سنستخدم client1 في الأمثلة الموجودة في هذا الدرس كاسم الجهاز العميل. كما فعلنا مع مفتاح الخادوم، فسنقوم الآن ببناء واحد لمثال client1. يجب أن تكون ما زلت تعمل في /etc/openvpn/easy-rsa: ./build-key client1مجددًا، سيتم سؤالك عمّا إذا كنتَ تريد تغيير أو تأكيد متغيّرات الأسماء الفريدة والحقول الإضافية التي تركناها فارغة من قبل. اضغط Enter لاختيار الخيارات الافتراضية: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:وكما في السابق، سيسألك مرتين عن تأكيد بعض الخيارات، اكتب y: Sign the certificate? [y/n] 1 out of 1 certificate requests certified, commit? [y/n]إذا نجحت عملية بناء المفتاح فسيظهر التالي: Write out database with 1 new entries Data Base Updatedيجب على ملفّ عيّنة إعدادات العميل أن يتم نسخه إلى مجلّد Easy-RSA أيضًا. سنستخدمه كقالب يمكن تحميله إلى أجهزة العملاء ليتم تعديله. أثناء عملية النسخ، سنقوم بتغيير اسم ملفّ العيّنة من client.conf إلى client.ovpn لأنّ امتداد ملفّ .ovpn هو ما تتوقع أجهزة العملاء أن تراه باسم الملفّ وليس .conf: cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/easy-rsa/keys/client.ovpnيمكنك تكرار هذا القسم مجددًا لكلّ عميلٍ تريد السماح له بالوصول، ولا تنسى استبدال client1 باسم الجهاز الجديد. نقل الشهادات والمفاتيح إلى أجهزة العميلخلاصة ما طبقّناه أعلاه هو أننا أنشأنا شهادات ومفاتيح العملاء، وأننا قمنا بتخزينها على خادوم OpenVPN في المسار /etc/openvpn/easy-rsa/keys . نحتاج القيام بنقل شهادة العميل، المفتاح وقالب الملفّ الشخصي لكلّ عميلٍ نريد السماح له بالوصول إلى مجلّد محلّي على جهاز الحاسوب الخاصّ بنا أو أيّ جهاز عميل آخر. في هذا المثال، يتطلّب جهاز العميل client1 الشهادات والمفاتيح الخاصّة به والموجودة في المسارات: * /etc/openvpn/easy-rsa/keys/client1.crt * /etc/openvpn/easy-rsa/keys/client1.keyتكون ملفّات ca.crt و client.ovpn هي نفسها لجميع أجهزة العملاء مهما اختلفت. قمّ بتحميل هذه الملفّات أيضًا; لاحظ أنّ ملف ca.crt هو في مسارٍ مختلف عن الملفّات الأخرى: etc/openvpn/easy-rsa/keys/client.ovpn/etc/openvpn/ca.crt/بينما ستعتمد التطبيقات المُستخدمة لإكمال هذه المهمّة على اختيارك ونوع نظام التشغيل الخاصّ بك، فإنّك بحاجة إلى تطبيق يستخدم STFP (بروتوكول نقل الملفّات عبر SSH) أو SCP (النسخ الآمن) للوصول إلى الملفّات الموجودة في خلفية الخادوم. سينقل هذا ملفّات الاستيثاق الخاصّة بخادومك عبر اتصالٍ مشفّر. إليك مثالًا لأمر SCP باستخدام مثالنا من client1. إنّه يقوم بوضع الملفّ client1.key إلى المجلّد Downloads الموجود على حاسوبنا المحلّي: scp root@your-server-ip:/etc/openvpn/easy-rsa/keys/client1.key Downloads/إليك بضع أدوات ودروس يمكنك استخدامها لنقل الملفّات بشكلٍ آمن من الخادوم إلى الحاسوب المحلّي: WinSCPكيفية استخدام SFTP لنقل الملفّات بشكلٍ آمن من خادومٍ بعيد.كيفية استخدام FileZilla لنقل وإدارة الملفّات بشكلٍ آمن.في نهاية هذا القسم، تأكّد أنّ هذه الملفّات الأربعة أصبحت موجودة على جهاز المحلّي مهما كان نوعه: client1.crtclient1.keyclient.ovpnca.crtالخطوة الرابعة: إنشاء ملفٍّ شخصيٍ موحّد لجهاز العميلهناك العديد من الطرق المُستخدمة لإدارة ملفّات العملاء ولكن أسهلها يستخدم ملفّا شخصيًا موحّدًا. يتم إنشاء هذا الملفّ عبر تعديل قالب ملفّ client.ovpn ليتضمّن استيثاق شهادات الخادوم، شهادة العميل والمفتاح الخاصّ به. بمجرّد إضافته، فسيجب حينها فقط استيراد ملفّ client.ovpn إلى تطبيقات OpenVPN على أجهزة العميل. سنقوم بإنشاء ملفٍّ شخصيٍ وحيد لجهازنا المدعو client1 على الحاسوب المحلّي الذي قمنا بتحميل جميع الملفّات إليه. يمكن لهذا الحاسوب المحلّي بنفسه أن يكون جهازًا عميلًا أو مجرّد منطقة عمل مؤقّتة لدمج ملفّات الاستيثاق. يجب أن يتم نسخ قالب ملفّ client.ovpn وإعادة تسميته. كيفية قيامك بهذا الأمر ستعتمد على نظام التشغيل الخاصّة بجهازك المحلّي. ملاحظة: لا يجب على اسم ملفّ client.ovpn الخاصّ بك المنسوخ الجديد أن يكون مطابقًا لاسم جهاز العميل. تطبيق العميل لـOpenVPN سيستخدم اسم الملفّ كمُعرّف لاتصال VPN نفسه، حيث يجب عليك نسخ ملفّ client.ovpn إلى أيّ اسمٍ جديد تريد استخدامه على نظام التشغيل الخاصّ بك. كمثال: work.ovpn سيتم التعرّف عليه كـwork و school.ovpn سيتم التعرّف عليه كـschool. في هذا الدرس، سنقوم بتسمية اتصال VPN كـ HsoubAcademy ولذلك فسيكون اسم الملفّ هو HsoubAcademy.ovpn من الآن فصاعدًا. بمجرّد تسمية الملفّ الجديد المنسوخ، يجب علينا حينها فتح ملفّ HsoubAcademy.ovpn في محرر نصوص. أول نقطة سيقع عليها انتباهك هي مكان عنوان الـIP الخاصّ بخادومك. بالقرب من بداية الملفّ، قم بتغيير my-server-1 إلى عنوان IP الخاصّ بخادومك: # The hostname/IP and port of the server. # You can have multiple remote entries # to load balance between the servers. remote my-server-1 1194الآن، ابحث عن القسم الظاهر أدناه وقم بإلغاء تعليق user nobody و group nobody، كما فعلنا مع ملفّ server.conf في الخطوة الأولى. ملاحظة: هذا لا ينطبق على ويندوز لذا يمكنك تجاوزه. يجب أن يبدو هكذا عندما تنتهي: # Downgrade privileges after initialization (non-Windows only) user nobody group nogroupالقسم الظاهر أدناه يحتاج أن نقوم فيه بتعليق السطور الثلاثة الأخيرة لكي نتمكّن من تضمين الشهادة والمفتاح مباشرةً في ملفّ HsoubAcademy.ovpn، يجب أن يبدو هكذا: # SSL/TLS parms. # . . . #ca ca.crt #cert client.crt #key client.keyلدمج الملفّات المنفصلة إلى ملفٍّ شخصي واحدٍ موحّد، يجب أن يتم وضع محتويات الملفّات ca.crt, client1.crt, و client1.key مباشرةً في ملفّ .ovpn باستخدام هيكلة XML. يجب بالنهاية أن يبدو شكلها كالتالي: <ca> (أدخل محتويات ca.crt هنا) </ca> <cert> (أدخل محتويات client1.crt هنا) </cert> <key> (أدخل محتويات client1.key هنا) </key>عندما تنتهي، يجب أن تبدو نهاية الملفّ كالتالي: <ca> -----BEGIN CERTIFICATE----- . . . -----END CERTIFICATE----- </ca> <cert> Certificate: . . . -----END CERTIFICATE----- . . . -----END CERTIFICATE----- </cert> <key> -----BEGIN PRIVATE KEY----- . . . -----END PRIVATE KEY----- </key>يمتلك ملفّ client1.crt معلوماتٍ إضافية في داخله; لا بأس بتضمين الملفّ بأكمله. احفظ التغييرات واخرج. أصبح لدينا الآن ملفّ واحد موحّد لضبط جهازنا المحلّي client1. الخطوة الخامسة: تثبيت ملفّ العميلالآن سنناقش تثبيت ملفّ VPN على Windows, OS X, iOS, و Android. لا يعتمد أيٌّ من إرشادات هذه الأنظمة على الآخر لذا يمكنك التجاوز إلى الذي يطابق نظامك التشغيلي الحالي فقط. تذكّر أنّ الاتصال سيتم تسميته بحساب اسم ملفّ .ovpn الذي استخدمته. في مثالنا قمنا بتسمية الملفّ كـ HsoubAcademy.ovpn ولذلك سيكون اسم الاتصال هو HsoubAcademy. Windowsالتثبيتيمكن العثور على تطبيق عميل OpenVPN لنظام ويندوز من صفحة التحميلات الخاصّة بـOpenVPN. اختر المُثبّت المناسب لإصدارك من ويندوز. ملاحظة: يتطلّب OpenVPN الصلاحيات الإدارية ليتم تثبيته. بعد تثبيته، انسخ الملفّ HsoubAcademy.ovpn إلى: C:\Program Files\OpenVPN\configعندما تقوم بتشغيل OpenVPN، فسيقوم تلقائيًا برؤية الملفّ وجعله متاحًا. يجب أن يتم تشغيل OpenVPN بصلاحيات المسؤول في كلّ مرّة يتم تشغيله، حتى ولو كان يتم تشغيله على حسابات المستخدمين. لفعل هذا دون الحاجة إلى الضغط على زرّ الفأرة الأيمن واختيار التشغيل كمسؤول في كلّ مرّة تقوم باستعمال الـVPN، يمكنك ضبط هذا الأمر ولكنك ستحتاج إلى القيام به من حساب بصلاحياتٍ إدارية. هذا يعني أيضًا أنّه سيجب على المستخدمين إدخال كلمة مرور المستخدم المدير لاستخدام OpenVPN. على الناحية الأخرى، لن يتمكن المستخدمون من استخدام OpenVPN بشكلٍ صحيح دون أن يتم تشغيله على جهاز العميل بصلاحياتٍ إدارية، لذا فإنّ الصلاحيات الإدارة مطلوبة. لجعل تطبيق OpenVPN يتم تشغيله دومًا كمدير، اضغط بزرّ الفأرة الأيمن على أيقونة الاختصار الخاصّة به واذهب إلى خصائص. في نهاية لسان التوافقية، اضغط على الزرّ لتغيير الإعدادات لجميع المستخدمين. في النافذة الجديدة، اختر تشغيل هذا البرنامج كمدير. الاتصالفي كلّ مرّة تقوم بتشغيل واجهة OpenVPN الرسومية، سيسألك ويندوز عمّا إذا كنتَ تريد السماح للبرنامج بتطبيق التغييرات على نظامك. اضغط على موافق. تشغيل تطبيق عميل OpenVPN سيقوم فقط بوضع الأيقونة في تنبيهات النظام ويمكن الاتصال أو قطع الاتصال بخادوم OpenVPN عند الحاجة; وهو لا يقوم حقيقةً بالاتصال بـ VPN. بمجرّد بدء OpenVPN، قم بإنشاء اتصال عبر الذهاب إلى تنبيهات النظام والضغط بزرّ الفأرة الأيمن على أيقونة OpenVPN. هذا سيفتح لك قائمةً فرعية. اختر HsoubAcademy من أعلى القائمة (والذي هو عبارة عن HsoubAcademy.ovpn) واختر اتصال. سيتم فتح نافذة حالة جديدة تعرض لك الخرج أثناء تأسيس الاتصال، وسيتم طباعة رسالة بمجرّد اكتمال العملية. يمكنك إلغاء الاتصال من VPN بنفس الطريقة: اذهب إلى تنبيهات النظام وانقر بزرّ الفأرة الأيمن على أيقونة OpenVPN واختر قطع الاتصال. OS XالتثبيتTunnelblick هو تطبيق عميل OpenVPN مجاني ومفتوح المصدر لنظام MAC OS X. يمكنك تحميله من صفحة تحميلات Tunnelblick. انقر نقرتين على ملفّ .dmg المحمّل وتابع إرشادات التثبيت. إلى نهاية عملية التثبيت، سيسألك Tunnelblick عمّا إذا كنتَ تمتلك أيّ ملفّات إعدادات. الأسهل حاليًا هو اختيار لا وترك Tunnelblick ليتابع التثبيت. ابحث نافذة Finder وانقر على ملفّ HsoubAcademy.ovpn وسيتم تشغيل Tunnelblick باستخدام ذلك الملفّ، الصلاحيات الإدارية مطلوبة. الاتصالشغّل Tunnelblick عبر النقر مرّتين على مجلّد أيقونة التطبيقات. بمجرّد تشغيل Tunnelblick، سيكون هناك أيقونة Tunnelblick على شريط القائمة في أعلى يمين الشاشة للتحكّم بالاتصالات. اضغط على الأيقونة ومن ثمّ عنصر قائمة اتصال لبدء اتصالٍ جديد واختر HsoubAcademy. iOSالتثبيتمن متجر تطبيقات iTunes، ابحث وثبّت تطبيق OpenVPN Connect، والذي هو تطبيق عميل OpenVPN الرسمي لـiOS. لنقل ملفّ .ovpn الخاصّ بك إلى هاتفك، قم بتوصيله مباشرةً إلى حاسوب. إكمال النقل مع iTunes سيكون خارجيًا هنا. افتح iTunes من على الحاسوب واضغط على iPhone > apps. انتقل إلى الأسفل إلى قسم مشاركة الملفّات وانقر على تطبيق OpenVPN. النافذة الموجودة على اليمين، OpenVPN Documents هي لمشاركة الملفّات. اسحب ملفّ .ovpn وأفلته إلى النافذة أدناه. الآن شغّل تطبيق OpenVPN على iPhone. سيكون هناك إشعار أنّه هناك ملفّ جديد ليتم استيراده. انقر على إشارة الزائد الخضراء ليتمّ ذلك: الاتصالأصبح OpenVPN الآن جاهزًا للاستخدام مع الملفّ الجديد. ابدأ الاتصال عبر النقر على زرّ Connect وجعله On. ويمكنك قطع الاتصال عبر جعله Off. ملاحظة: لا يمكن استخدام محوّل VPN الموجود تحت الإعدادات للاتصال بـVPN. إذا حاولت، فسيصلك إشعار باستخدام تطبيق OpenVPN فقط. Androidالتثبيتافتح متجر Google Play. ابحث عن تطبيق Android OpenVPN Connect وثبّته، إنّه تطبيق OpenVPN الرسمي لأندرويد. يمكن نقل ملفّ .ovpn إلى الهاتف عبر إيصال جهاز الأندرويد الخاصّ بك إلى الحاسوب عبر USB ونقل الملفّ. بشكلٍ مغاير، إذا كنتَ تمتلك قارئ بطاقات SD، فيمكنك إزالة بطاقة SD من الجهاز، نسخ الملفّ إليها ومن ثمّ إدراجها مجددًا إلى جهاز الأندرويد. ابدأ تطبيق OpenVPN وانقر على القائمة للاستيراد: ثمّ تنقّل إلى موقع الملفّ المحفوظ (لقطة الشاشة تستخدم /sdcard/Download/) واختر الملفّ. وسيقوم التطبيق بإخبارك أنّ الملفّ تمّ استيراده: الاتصالللاتصال، قم ببساطة بالضغط على زرّ الاتصال الموجود أمامك. سيتم سؤالك عمّا إذا كنتَ تثق بالتطبيق، اضغط على موافق وتابع. لإلغاء الاتصال، انقر على زرّ قطع الاتصال بالتطبيق. الخطوة السادسة: اختبار اتصالك بـ VPNبمجرّد تثبيت كلّ شيء، يمكن لفحصٍ سريع أن يؤكّد لك أنّك تستعمل VPN الآن أو لا. أولًا قبل استخدام أيّ VPN، اذهب إلى موقع DNSLeakTest. سيعطيك الموقع عنوان الـIP الخاصّ بك عبر مزوّد الإنترنت لديك وستظهر أنت كما تبدو لبقية العالم. للتحقق من إعدادات DNS الخاصّ بك عبر نفس الموقع، انقر على Extended Test وسيخبرك عن خواديم DNS التي تستعملها. الآن، قم بالاتصال بخادوم OpenVPN الموجود على خادومك وحدّث الصفحة. وشاهد عنوان الـIP الجديد المختلف كليًا عن السابق. هذا سيكون هو عنوان الـIP الظاهر للعالم عند تصفّحك لمواقعهم. مجددًا، انقر على Extended Test وسيخبرك عن خواديم DNS التي تستعملها وسيؤكد لك أنّك تستخدم الآن خواديم الـDNS المُعدّة من قبل OpenVPN. تهانينا! يمكنك الآن التنقّل بأمان في الإنترنت وحماية خصوصيتك، موقعك وبياناتك من المراقبة والمُخترقين. ترجمة -وبتصرّف- للمقال: How To Set Up an OpenVPN Server on Ubuntu 14.04.

HAProxy (والذي يرمز إلى الوسيط عالي التوفّر High Availability Proxy) هو عبارة عن تطبيق موزانة حملٍ مفتوح المصدر لبروتوكول TCP/HTTP يُمكن أن يتم تشغيله على أنظمة لينكس، Solaris وFreeBSD. يتم استخدامه بشكلٍ شائع لتحسين أداء ومرونة بيئة خادوم الويب عبر توزيع الحمل على خواديم أخرى متعددة (كمثال: خادوم للويب، خادوم للتطبيق، خادوم لقاعدة البيانات..). يتم استخدام HAProxy في العديد من البيئات عالية التوفّر مثل: GitHub، Imgur, Instagram و Twitter. في هذا الدرس، سنتعرّف على ماهيّة HAProxy بشكلٍ عام، مصطلحات موازنة الحمل الأساسية وأمثلةٍ لكيفية استخدامه لتحسين أداء ومرونة بيئة خادوم الويب الخاصّ بك. مصطلحات HAProxyهناك العديد من المصطلحات والمفاهيم التي من المهمّ فهمها عند الحديث عن موازنة الحمل واستخدام الوسيط (Proxying)، سنتحدّث عن أهمّ هذه المصطلحات في الأقسام الفرعيّة التالية. قبل أن نبدأ بالحديث عن الأنواع الأساسية لموازنة الحمل، سنتحدّث عن قوائم تحكّم الوصول (ACLs – Access Control Lists)، الواجهات الخلفيّة (backends) والواجهات الأماميّة (frontends). قائمة تحكّم الوصول (ACL)في ارتباطٍ وثيق مع مبدأ موازنة الحمل، يتم استخدام قوائم تحكّم الوصول (Access Control List) لاختبار بعض الشروط وتنفيذ بعض الأوامر (كمثال: اختيار خادومٍ معيّن، حظر طلبٍ ما..) بناءً على نتيجة الاختبار. يسمح استخدام قوائم تحكّم الوصول بعمليةِ إعادة توجيهٍ مرنة لتدفّق الشبكة (network traffic) بناءً على عدّة عوامل مثل مطابقة النمط (pattern matching) وعدد الاتصالات المُرسلة إلى الواجهة الخلفيّة. مثال على ACL: acl url_blog path_beg /blogتكون قائمة تحكّم الوصول السابقة متطابقة في حال كان المسار الذي يطلبه المستخدم مبدوءًا بـ blog/. هذا يعني أنّ مسارًا مثل http://yourdomain.com/blog/blog-entry-1 مثلًا كان ليكون متطابقًا مع القائمة في حال تطبيقها. لدليلٍ تفصيلي حول كيفية استخدام ACL، راجع دليل إعداد HAProxy. الواجهة الخلفيّة Backendالواجهة الخلفيّة هي عبارة عن مجموعة خواديم تتلقى الطلبات (requests) الموجّهة إليها. يتمّ تعريف الواجهات الخلفيّة في قسم backend في ملفّ إعدادات HAProxy. في شكلها الأكثر بساطةً يمكننا تعريف الواجهة الخلفيّة عبر: خوارزميات موازنة الحمل التي يجب استخدامها.قائمة من الخواديم والمنافذ (Ports).يمكن لواجهةٍ خلفيّة أن تحتوي خادومًا واحدًا أو أكثر فيها. بشكلٍ عام، إضافة المزيد من الخواديم إلى واجهتك الخلفيّة سيزيد من سعة التحمّل القصوى الخاصّة بموقعك عبر توزيع الحمل على أكثر من خادومٍ واحد. يتم توفير عمليّة زيادة المرونة أيضًا باستخدام هذه الطريقة، ففي حال تعطّل أحد خواديمك، سيبقى هناك غيره ليقوم بخدمة الزوّار. إليك مثالًا على إعدادات واجهتين خلفيّتين، web-backend وblog-backend مع خادومين اثنين لكلّ واحدٍ منهما، يعملان على المنفذ 80: backend web-backend balance roundrobin server web1 web1.yourdomain.com:80 check server web2 web2.yourdomain.com:80 check backend blog-backend balance roundrobin mode http server blog1 blog1.yourdomain.com:80 check server blog1 blog1.yourdomain.com:80 checkيقوم السطر balance roundrobin بتحديد خوارزميّة موازنة الحمل التي سيتم استعمالها، والتي سنتحدث عنها في قسمٍ لاحق.يحدد سطر mode http أنّه سيتم استخدام الطبقة 7 كوسيط، سنشرح هذا الأمر أيضًا في قسمٍ لاحق.يقوم الخيار check في نهاية السطور المبدوءة بـserver بإخبار النظام بوجوب التحقق من حالة خواديم الواجهة الخلفيّة هذه في كلّ مرّة.الواجهة الأماميّة Frontendتقوم بالواجهة الأماميّة بتعريف كيفية إعادة توجيه الطلبات إلى الواجهات الخلفيّة backends. يتم تعريف الواجهات الأماميّة في قسم frontend في ملفّ إعدادات HAProxy. تتكون تعريفاتها من المكونات التالية: مجموعة من عناوين الـIP والمنافذ (مثل: 10.1.1.7:80، *:443، إلخ..).قوائم تحكّم الوصول ACLs.قواعد use_backend، والتي تعرّف أيًّا من الواجهات الخلفيّة يجب استخدامها اعتمادًا على ما إذا كانت قوائم تحكّم الوصول متطابقة معها في كلّ مرّة أم لا، و/أو قاعدة default_backend والتي تقوم بمعالجة الحالات الأخرى.يمكن إعداد واجهةٍ أمامية تبعًا لأنواعٍ مختلفة من تدفّقات الشبكة، وهو ما سنشرحه في القسم التالي. أنواع موازنة الحملالآن وبعد أن فهمنا المكوّنات الأساسية التي يتم استخدامها في عملية موازنة الحمل، فلنتطرّق إلى الأنواع الأساسية لموازنة الحمل. موازنة الحمل المعدومة No Load Balancingيمكن لبيئة تطبيق ويبٍ بسيطة لا تستعمل أيًّا من طرق موازنة الحمل أن تبدو بالشكل التالي: في هذا المثال، يتّصل المستخدم مباشرةً إلى خادوم الويب الخاصّ بك في yourdomain.com حيث لا يوجد أيّ نوع من موازنة الحمل. إذا تعطّل خادوم الويب الوحيد، فإنّ المستخدم لن يكون قادرًا على الوصول إلى تطبيقك. أيضًا، في حال ما إذا كان العديد من المستخدمين يحاولون الوصول إلى خادومك بنفس الوقت ولم يكن الخادوم قادرًا على معالجة كل هذه الطلبات بنفس الوقت، فقد يواجه الزوّار بطئًا في عملية تحميل الموقع وقد لا يحمّل إطلاقّا. موازنة الحمل عن طريق الطبقة 4 (Layer 4 Load Balancing)أبسط طريقة لموازنة الحمل في تدفّق الشبكة على خادومين اثنين هو استخدام موازنة الحمل عن طريق الطبقة رقم 4 (وهي طبقة شفافة transport layer). موازنة الحمل باستخدام هذه الطريقة ستسبب في توجيه تدفّق الزوار بناءً على مدى عنوان الـIP والمنفذ (كمثال، إذا جاء طلبٌ للمسار http://yourdomain.com/anything، فإنّه سيتم توجيه التدفّق إلى خادوم الواجهة الخلفيّة الذي يعالج الطلبات لـyourdomain.com بالمنفذ 80). إليكَ رسمًا توضيحيًا لموازنة الحمل باستخدام الطبقة 4: يقوم المستخدم بالوصول إلى مُوازِن الحمل (load balancer) والذي يقوم بدوره بتوجيه طلبات المستخدم إلى مجموعة web-backend لخواديم الواجهة الخلفيّة. عندما يتم اختيار خادوم واجهةٍ خلفيّة معيّن فإنّه يستجيب مباشرةً إلى طلبات المستخدم. بشكلٍ عام، يجب على جميع الخواديم في مجموعة web-backend أن تحتوي على نفس المحتوى والبيانات، وإلّا فإنّ المستخدم قد يتصفّح محتوىً مختلفًا بالمرّة. لاحظ أيضًا أن كُلًا من الخادومين يتصلان إلى نفس خادوم قاعدة البيانات. موازنة الحمل عن طريق الطبقة 7 - Layer 7 Load Balancingطريقةٌ أخرى أكثر تعقيدًا لتوزيع تدفّق الحمل القادم إلى الشبكة هي عبر استخدام الطبقة 7 (وهي طبقة تطبيق application layer) لموازنة الحمل. يسمح استخدام الطبقة 7 لمُوازِن الحمل بتوجيه الطلبات إلى خواديم الواجهة الخلفيّة المختلفة بناءً على المحتوى الذي يطلبه المستخدم. يسمح لك هذا النوع من موازنة الحمل بتشغيل أكثر من خادوم تطبيق ويب تحت نفس النطاق والمنفذ. إليك رسمًا توضيحيًا لمثالٍ بسيط لموازنة الحمل باستخدام الطبقة 7: في هذا المثال، إذا قام مستخدم بطلب yourdomain.com/blog فإنّه سيتم توجيهه إلى الواجهة الخلفيّة لـblog، والتي تتكون من مجموعة خواديم تشغّل تطبيق الويب الخاصّ بالمدوّنة. يتم توجيه الطلبات الأخرى إلى web-backend، والتي يمكن أن تكون عاملةً على تشغيل تطبيق ويب مختلف. كلٌّا الواجهتين الخلفيّتين تستعملان نفس خادوم قاعدة البيانات في هذا المثال. يمكن لجزءٍ من مثالٍ على ملفّ إعدادات الواجهة الأماميّة أن يبدو هكذا: frontend http bind *:80 mode http acl url_blog path_beg /blog use_backend blog-backend if url_blog default_backend web-backendيقوم هذا المثال بإعداد واجهةٍ أمامية تدعى http، والتي ستقوم بمعالجة جميع الطلبات المتدفّقة إلى المنفذ 80.يقوم سطر acl url_blog_path_beg /blog بمطابقة ما إذا كان ما يطلبه الزائر يبدأ بـ blog/.يقوم سطر use_backend blog-backend if url_blog بجعل الخادوم يستخدم قوائم تحكّم الوصول ACL كوسيط لتوجيه التدفّق إلى blog-backend.يحدّد default_backend web-backend أنّه سيتم توجيه كل التدفّقات الأخرى إلى web-backend.خوارزميات موازنة الحملتقوم خوارزميّة موازنة الحمل المستخدمة بتحديد أيٍّ من خواديم الواجهة الخلفيّة سيتم اختيارها عند بدء عملية موازنة الحمل. يوفّر HAProxy عدّة خيارات لهذه الخوارزميّات. بالإضافة إلى خوارزميّة موازنة الحمل فإنّه بالإمكان إسناد مُعامِل الـweight لتحديد الخواديم التي نريد استخدامها بشكلٍ أكبر من الأخرى. بسبب أنّ HAProxy يوفّر العديد من خوارزميّات موازنة الحمل، فإننا سنتحدّث عن القليل منها فقط هنا. يمكنك مراجعة دليل إعداد HAProxy لقائمةً كاملة بالخوارزميات. 1-roundrobinتقوم خوارزميّة round robin باختيار الخواديم بالتناوب، وهي الخوارزميّة الافتراضية المستعملة. 2-leastconnتقوم هذه الخوارزميّة باختيار الخادوم الأقل استخدامًا حاليًا والذي يتصل به أقل عدد من الزوّار ليعالج الطلبات القادمة، هذه الخوارزميّة مستحسنة للجلسات (sessions) الطويلة. يتم أيضًا اختيار الخواديم الموجودة في نفس الواجهة الخلفيّة بالتناوب على طريقة round-robin. 3-Sourceتقوم هذه الخوارزميّة باختيار الخادوم الذي يجب استعماله بناءً على عنوان الـIP الخاصّ بالمستخدم. يتم استخدام هذه الطريقة للتأكّد مما إذا كان المستخدم سيتصل بنفس الخادوم. الجلسات الملتصقة Sticky Sessionsتتطلب بعض التطبيقات أن يقوم المستخدم بمتابعة الاتصال إلى نفس خادوم الواجهة الخلفيّة. يتم تحقيق هذه العمليّة عن طريق ما يعرف بالجلسات الملتصقة أو Sticky Sessions، عبر استخدام مُعامِل appsession في ملف إعدادات الواجهة الخلفيّة التي تحتاجه. اختبار الحالة Health Checkيقوم HAProxy باستخدام اختبارات الحالة للتحقق مما إذا كان خادومٌ ما في الواجهة الخلفيّة متوفّرًا لمعالجة الطلبات أم لا. بفضل هذه العمليّة، فإنّ المستخدم لا يعود بحاجة إلى إزالة الخادوم يدويًا من الواجهة الخلفيّة في حال أصبح غير متوفّر. سيقوم اختبار الحالة الافتراضي بمحاولة إنشاء اتصال TCP مع الخادوم ليرى إن كان يعمل أم لا، حيث سيقوم بمحاولة الاتصال بعنوان الـIP المحدّد والمنفذ الخاصّ به. إذا فشل أحد الخواديم في اختبار الحالة وكان غير قادرٍ على معالجة الطلبات، فإنّه يتم تعطيله تلقائيًا من الواجهة الخلفيّة، حيث لن يتم توجيه تدفّق الشبكة إليه مرةً أخرى إلى أن يصبح متوفّرًا مجددًا وبحالة جيّدة. إذا تعطّلت جميع خواديم الواجهة الخلفيّة، فإنّ الخدمة لن تعود متوفّرة إلى حين عودة أحد الخواديم إلى العمل من جديد. لأنواعٍ معيّنة من خواديم الواجهات الخلفيّة، مثل خواديم قاعدة البيانات في بعض الحالات الخاصّة، فإنّ اختبار الحالة الافتراضي ليس كافيًا لتحديد حالة الخادوم الجيّدة أو عكس ذلك. حلولٌ أخرىإذا كنتَ تشعر أنّ HAProxy معقّد جدًا مقارنةً باحتياجاتك، فإنّ الحلول التالية قد تناسبك: خواديم لينكس الافتراضية (LVS) – مُوَازِن حملٍ يستخدم الطبقة رقم 4 لموازنة الحمل، بسيط وسريع ومتوفّر في معظم توزيعات لينكس.Nginx – خادوم ويب سريع ومرن يُمكن أيضًا استخدامه كوسيط أو لغرض موازنة الحمل (راجع مقالتنا السابقة عن استخدام Nginx لموزانة الحمل). يتم استخدام Nginx عادةً بالتوازي مع HAProxy نظرًا لقدرته على إنشاء ذاكرة الخبيئة (caching) وإمكانيات الضغط العالية.الخاتمةالآن صرتَ تمتلك معرفةً أساسية حول موازنة الحمل وصرتَ تعرف بضع طرقٍ يستخدمها HAProxy لتلبية احتياجات موازنة الحمل الخاصّة بك، صار لديك قاعدةٌ صلبة لتستند عليها في البدء بتحسين أداء ومرونة بيئة خادوم الويب الخاصّ بك. ترجمة -وبتصرّف- للمقال: An Introduction to HAProxy and Load Balancing Concepts.

قدرات إعادة التوجيه (redirection) في لينكس توفّر لك العديد من الأدوات القوية التي يُمكن استخدامها لجعل جميع أنواع المهام أسهل للتنفيذ. سواءٌ كنتَ تكتبُ برمجياتٍ معقّدة أو كنتَ تقوم بإدارة الملفّات عبر سطر الأوامر، فإنّ معرفة كيفية التلاعب بتدفّقات (streams) الإدخال/الإخراج (input/output) على بيئتك الشخصية سيزيدُ من إنتاجيّتك بشكلٍ ملحوظ. التدفقات يتم توزيع الإدخال والإخراج في بيئة لينكس عبر ثلاث تدفّقات (streams) أساسية: إدخال معياري (stdin). إخراج معياري (stdout). خطأ معياري (stderr). هذه التدفّقات أيضًا مرقّمة وفق التالي: (stdin (0. (stdout (1. (stderr (2. أثناء التفاعلات المعيارية (standard interactions) بين المستخدم والطرفيّة (terminal)، فإنّه يتم نقل الإدخال المعياري عبر لوحة مفاتيح المستخدم. يتم عرض الإدخال المعياري و الخطأ المعياري على طرفية المستخدم كنصّ. بشكلٍ عام، جميع هذه التدفّقات الثلاثة يتم الإشارة إليها بـ"التدفّقات المعيارية". الإدخال المعياري تدفّق الإدخال المعياري عادةً ما يحمل البيانات من المستخدم إلى البرنامج. البرامج التي تتوقع إدخالًا معيّنًا من المستخدم تستقبل الإدخال عادةً من جهازٍ ما، مثل لوحة المفاتيح، الإدخال المعياري ينتهي عند وصوله نهاية الملف (EOF – End Of File). كما يتم وصفه بواسطة اسمه، فإنّ نهاية الملف أو "EOF" تُعلِم الحاسوب أنه لا يوجد هناك المزيد من البيانات ليتم قراءتُها. لرؤية الإدخال المعياري بصورةٍ حيّةَ، شغّل برنامج cat. كلمة Cat ترمز لـ"concatenate” أو "سَلسَلة الأشياء"، والتي تعني ربط الأشياء مع بعضها البعض على شكل سلسلة. يتم استخدام Cat بشكلٍ شائع لدمج محتويات ملفّّين. عندما يتم تشغيله لوحده فإنّ cat يقوم بفتح طرفيّته الخاصّة. cat بعد فتح cat، قم بإدخال مجموعة من الأرقام كالتالي: 1 2 3 ثم اضغط Ctrl+D. عندما تقوم بكتابة رقم والضغط على زرّ Enter، فإنّك تقوم بإرسال إدخال معياري (standard input) إلى برنامج cat الذي يعمل حاليًا، والذي هو بدوره يتوقّع وصول الإدخال إليه. يقوم برنامج cat بإرسال الإدخال الذي تُدخله إليه مرةً أخرى إلى الطرفية حيث يتم عرضه كإخراج معياري (standard output). إشارة EOF (أو نهاية مدّة حياة العملية الحالية – End of File) يُمكن أن يتم إرسالها إلى البرنامج بواسطة المستخدم عبر الضغط على مفاتحيّ Ctrl+D. بعد أن يتسلّم برنامج cat إشارة EOF فإنّ البرنامج يتوقف. الإخراج المعياري يقوم الإخراج المعياري (standard output) بكتابة البيانات التي يتم إنشاءها بواسطة البرامج. عندما لا يتم إعادة توجيه تدفّق الإخراج المعياري، فإنّه سيتم إخراج النصّ إلى الطرفية. جرّب المثال التالي: echo Sent to the terminal through standard output الخطأ المعياري يقوم الخطأ المعياري (standard error) بكتابة الأخطاء التي يتم إنشاؤها بواسطة البرامج التي فشلت في أن يتم تنفيذها في مرحلةٍ ما. تمامًا مثل الإدخال المعياري فإنّ الوجهة الافتراضية لهذا التدفّق هي شاشة الطرفيّة. عندما يتم إرسال تدفّقِ خَطَأٍ معياريٍ لبرنامجٍ إلى برنامجٍ آخر، فإنّ البيانات المُرسلة (المتكوّنة من أخطاء البرنامج) يتم إرسالها بشكلٍ موازي إلى الطرفية كذلك. فلنرى مثالًا بسيطًا عن الخطأ المعياري باستخدام ls. يقوم الأمر ls بسرد محتويات المجلّدات أو المسارات. عندما يتم تنفيذه بدون أيّ معطيات، فإنَّ أمر ls يقوم بسرد محتويات المسار الحالي. إذا تمّ تشغيله مع مسارٍ معيّن كمُعطَى، فإنّه سيقوم بسرد محتويات المسار المطلوب. ls % بما أنّ % ليس مسارًا موجودًا، فإنّه سيتم إرسال النصّ التالي كخطأٍ معياري: ls: cannot access %: No such file or directory إعادة توجيه التدفق يمتلك نظام لينكس أوامرًا مُضمّنة لإعادة توجيه كلّ تدفّق. تقوم هذه الأوامر بطباعة إخراجٍ معياري إلى ملفٍّ ما. إذا تم استهداف ملفٍّ غير موجود، فإنّه سيتم إنشاء ملفٍّ جديد باسم ذاك الملفّ ليتم الكتابة عليه. الأوامر التي يأتي معها قوسٌ واحد (إشارة >) تقوم بالكتابة فوق ملفّ الوجهة الموجود. بالأسفل تجد بعض الإشارات الشائع استخدامها مع الأوامر عند التعامل معها بالطرفية لإعادة توجيه التدفّقات: 1. الكتابة فوق الملفات > إخراج معياري. < إدخال معياري. 2> خطأ معياري. 2. الإضافة إلى الملفات الأوامر التي يتم استخدامها مع قوسين اثنين لا تقوم بالكتابة فوق الملفّّات، بل تقوم بالكتابة إلى نهاية الملفّّات: >> إخراج معياري. << إدخال معياري. 2>> خطأ معياري. فلنأخذ المثال التالي: $ cat > write_to_me.txt a b c > ctrl-d يتم استخدام cat هنا لتتم عملية الكتابة إلى أحد الملفّّات، والذي يتم إنشاؤه تلقائيًا بسبب عدم وجوده ولأن الأمر الأول يحتاجه. لطباعة محتويات الملفّ write_to_me.txt باستخدام cat: $ cat write_to_me.txt يجب أن ترى أنّ الملفّ يحتوي على التالي: a b c الآن قم بإعادة توجيه cat إلى write_to_me.txt مجددًا وقم بإدخال الأرقام التالية: $ cat > write_to_me.txt 1 2 3 > ctrl-d عندما تستعمل cat لعرض محتويات write_to_me.txt، يجب أن ترى التالي: 1 2 3 أخيرًا، قم بعمل إعادة توجيه أخرى لـ cat ولكن هذه المرّة باستخدام قوسين عوضًا عن قوسٍ واحد: cat >> write_to_me.txt a b c ctrl-d وافتح ملفّ write_to_me.txt مجددًا، وسترى التالي: 1 2 3 a b c يحتوي الملفّّ الآن على النصّ من المرّة الأخيرة لاستخدام الأمر cat والتي قبلها، لأنّ الثانية لم تقم بالكتابة فوق الأولى. الأنابيب يتم استخدام الأنابيب (Pipes) لإعادة توجيه تدفّقٍ من برنامجٍ إلى آخر. عندما يتم إرسال الإخراج المعياري الخاص بأحد البرامج إلى برنامجٍ آخر عبر أنبوب (pipe) فإنّ بيانات البرنامج الأول والتي تمّ تلقّيها من طرف البرنامج الثاني سوف لن تظهر في الطرفية. فقط البيانات المُرشّحة عبر البرنامج الثاني سوف يتم عرضها. الأنبوب في نظام لينكس يتم تمثيله بإشارة شريطٍ عمودي: *|* وكمثالٍ على أمرٍ يستخدم أنبوبًا: ls | less هذا الأمر يقوم بأخذ ناتج الأمر ls (والذي يقوم بعرض محتويات المسار الحالي الذي أنت فيه) ويقوم بتمريره عبر أنبوبٍ إلى برنامج less. يقوم less بعرض البيانات المُرسلة إليه سطرًا سطرًا بدلًا من عرضها كاملة. بشكلٍ عام، يقوم ls بعرض محتويات المسار المطلوب عبر عرض الخرج بأكمله دفعةً واحدة. عندما تقوم بتشغيل ls عبر less فإنّ كلّ مُدخَلة يتم عرضها في سطرٍ واحد فقط خاصٍ بها ولا يتم عرض الخرج كله دفعةً واحدة، بل واحدة واحدة. على الرغم من أنّ وظيفة الأنابيب قد تبدو مشابهةً لإشارات الأقوس < و << (إعادة توجيه الإخراج المعياري)، فإنّ الفرق هو أنّ الأنابيب تقوم بتوجيه الخرج من أمرٍ إلى آخر، بينما تقوم إشارات الأقواس مثل < و << بتوجيه الخرج حصرًا إلى الملفّات فقط. المرشحات المرشّحات (filters) هي عبارة عن أوامر تعدّل على أنابيب إعادة التوجيه والإخراج. لاحظ أيضًا أنّه يمكن استخدام أوامر المرشّحات وأوامر لينكس العادية دون الحاجة لاستخدام الأنابيب. find: يقوم برنامج find بعرض الملفّات التي يتطابق اسمها مع المعطيات المُمررة له. grep: يقوم برنامج grep بعرض النصّ الذي يتطابق مع النصّ المُمرر إليه. tee: مهمّة برنامج tee هي إعادة توجيه الإدخال المعياري إلى كلٍ من الإخراج المعياري وملفٍّ واحد أو أكثر. tr: يقوم برنامج tr بالبحث عن سلسلة (string) واستبدالها بواحدة أخرى. wc: عدّاد للمحارف، السطور والكلمات. أمثلة قد تعرّفت الآن على إعادة التوجيه، استخدام الأنابيب والمرشّحات الأساسية، فلنلقي نظرةً على بعض أنماط إعادة التوجيه الأساسية والأمثلة. الأمر > الملف يقوم هذا النمط بإعادة توجيه ناتج أمرٍ معين إلى ملفّ، مثال: ls ~ > root_dir_contents.txt سيقوم الأمر السابق بتمرير محتويات مجلد الجذر (root directory) وكتابتها إلى ملفٍّ يدعى root_dir_contents.txt. سيقوم أيضًا بالكتابة فوق أيّ بيانات موجودة في ذاك الملفّ كوننا نستخدم قوسًا واحدًا فقط (>). الأمر > dev/null/ dev/null/ هو ملفٌّ خاص يتم استعماله لحذف أيّ بياناتٍ يتم توجيهها له. يتم استخدامه للتخلص من الخرج الذي لا نحتاجه والذي يُمكن أن يتعارض أحيانًا مع وظيفة أمرٍ آخر أو سكربت (script). يتم إهمال أي خرجٍ يتم إرساله إلى dev/null/. في المستقبل، ربّما تقوم باستخدام إعادة توجيه الخرج الناتج عن الأوامر والأخطاء إلى dev/null/ عند كتابة سكربتات الشلّ (shell scripts). ls > /dev/null سيقوم الأمر السابق بإهمال تدفّق الإخراج المعياري (standard output stream) العائد من الأمر ls عبر تمريره إلى الملفّ dev/null/ الذي سيتخلص منه. الأمر 2> الملف يقوم هذا النمط بتوجيه تدفّق الخطأ المعياري لأمرٍ ما إلى ملفّ، حيث يقوم بالكتابة فوق محتوياته الموجودة. كمثال: mkdir '' 2> mkdir_log.txt هذا الأمر سيوجّه رسالة الخطأ الصادرة عن "اسم المسار الخاطئ" ويكتبها إلى ملفّ mkdir_log.txt. لاحظ أنّه سوف يتم إرسال رسالة الخطأ أيضًا إلى الطرفية ليتمّ عرضها كنص. الأمر >> الملف يقوم هذا النمط بتوجيه ناتج أمرٍ ما إلى ملفّ دون الكتابة فوق محتويات الملفّ الحالية. مثال: echo Written to a new file > data.txt echo Appended to an existing file's contents >> data.txt هذان الأمران سيقومان أولًا بالكتابة فوق محتويات data.txt، ومن ثمّ سيتم الكتابة أسفل المحتويات الحالية لملفّ data.txt بواسطة الأمر الثاني، محتويات الملفّ يجب أن تبدو هكذا: Written to a new file Appended to an existing file's contents الأمر 2>> الملف يقوم النمط السابق بتوجيه تدفّق خطأٍ معياري لأمرٍ ما إلى ملفّ دون الكتابة فوق محتوياته الحالية. هذا النمط مفيد لإنشاء ملفّّات السجل (log files) لبرنامجٍ أو خدمة، حيث أنّه لن يتم محو محتويات الملفّ السابقة في كلِّ مرةٍ يتم الكتابة فيها إلى الملفّ. find '' 2> stderr_log.txt wc '' 2>> stderr_log.txt يوجّه الأمر أعلاه رسالة الخطأ الصادرة عن معطىٍ خاطئ للأمر find إلى ملفٍّ يُدعى stderr_log.txt. ومن ثمّ يقوم بتوجيه رسالة الخطأ الصادرة عن استخدامٍ خاطئ للأمر wc إلى نفس الملفّ. الأمر | الأمر يقوم بتوجيه خَرْجِ الأمر الأول إلى دَخْلِ الأمر الثاني. find /var lib | grep deb هذا الأمر يبحث عبر مجلّد var/ ومجلّداته الفرعية عن الملفّات والامتدادات المُطابقة للسلسلة "deb"، ويُرجِع مسارات تلك الملفّات مع تمييز الجزء المطابق من أسماء تلك بالملفّات بالسلسلة المبحوث عنها. الأمر | tee الملف هذا النمط (والذي يتضمّن أمر tee) يقوم بتوجيه ناتج أمرٍ معيّن إلى ملفّ والكتابة فوق محتوياته ومن ثمّ يقوم بعرض الناتج المُوجّه بالطرفية. حيثُ ينشئ ملفًّّا جديدًا في حال كان الملفّ غير موجود. في سياق هذا النمط، يتم استخدام الأمر tee عادةً لعرض ناتج أمرٍ معين بينما يتمّ أيضًا حفظه إلى ملفّ. كمثال: wc /etc/magic | tee magic_count.txt هذا الأمر يقوم باستخدام الأنابيب لنقل عدد المحارف، السطور والكلمات في ملفّ etc/magic/ (الذي يتم استخدامه بواسطة صدفة لينكس لتحديد نوع الملفّّات) إلى الأمر tee، والذي بدوره يقوم بفصل ناتج الأمر wc إلى اتّجاهين، ويقوم بإرساله إلى شاشة الطرفية وملفّ magic_counts.txt. بالحديث عن الأمر tee، فتخيّل الحرف T، نهاية هذا الحرف هي البيانات الكاملة، وقمّة هذا الحرف هو البيانات عندما يتم فصلها إلى اتّجاهين (الإخراج المعياري لملفٍّ ما وشاشة الطرفية). أمر | أمر | أمر >> ملف يقوم هذا النمط بتوجيه ناتج الأمر الأوّل وترشيحه عبر الأمرين الثانيين. ومن ثمَّ يقوم بطباعة الناتج إلى ملفّ. مثال: ls ~ | grep *tar | tr e E >> ls_log.txt الخاتمة تعلّم كيفية استخدام قدرات إعادة التوجيه في لينكس عند التعامل مع الأوامر قد يكون شاقًا قليلًا، ولكنك في طريقك بالفعل لاحتراف هذه المهارات بعد إكمالك لهذا الدليل. الآن وبعد أن شاهدت أساسيات كيفية عمل إعادة التوجيه والأنابيب، فستكون قادرًا على بدء رحلتك إلى عالم برمجة سكربتات الشلّ، والذي يستخدم بشكلٍ شائع غالب البرامج والأنماط المُغطّاة في هذا الدليل. إذا كنتَ تحبّ الغوص أكثر في الأوامر التي قدّمناها في هذا الدليل، فيُمكنك ذلك باستخدام الأمر man command | less. كمثال: man tee | less هذا الأمر سيُريك قائمةً كاملة بالأوامر المتوفّرة لبرنامج tee. يمكنك استخدام هذا النمط لعرض المعلومات وخيارات الاستخدام لأيّ أمرٍ أو برنامج في نظام لينكس. ترجمة -وبتصرّف- للمقال: An Introduction to Linux I/O Redirection لصاحبه David Collazo.

إعداد جدارٍ ناريّ قوي هو خطوةٌ أساسية يجب فعلها بهدف تأمين أيّ نظام تشغيلٍ حديث. تأتي معظم توزيعات لينكس بأدواتٍ مختلفة يمكننا استخدامها لضبط جداراتنا الناريّة. في هذا الدرس، سنتحدّث عن جدار iptables الناريّ. Iptables هو عبارة عن جدارٍ ناريّ عادي موجود في معظم توزيعات لينكس افتراضيًا (برنامجٌ آخر يدعى nftables سيبدأ قريبًا باستبداله). هو في الواقع عبارة عن واجهةٍ أمامية لخطّافات netfilter على مستوى النواة (kernel-level netfilter hooks) يمكنه التعامل مع مكدّس شبكة لينكس (Linux network stack). يعمل iptables عن طريق مطابقة كلّ حزمة (packet) تمرّ عبر الشبكة بمجموعة من القواعد (rules) التي تجعله يقرر ما يجب فعله. ملاحظة: يغطّي هذا الدرس أساسيات الحماية لـIPv4. في نظام لينكس، هناك فرق بين طرق الحماية لـIPv4 و IPv6. كمثال فإنّ iptables يقوم فقط بالتحكّم في قواعد جدار الحماية لعناوين IPv4 إلّا أنّه يمتلك برنامجًا خارجيًا يدعى ip6tables يمكن استخدامه للتحكّم في قواعد جدار الحماية لعناوين IPv6. إذا كان خادومك الافتراضي الخاصّ مُعدًّا ليستخدم IPv6، فرجاءً تذكّر حماية كلّ من واجهتيّ الشبكة IPv4 و IPv6 باستخدام الأدوات المناسبة. للمزيد من المعلومات عن أدوات IPv6، راجع هذا الدرس: كيفية ضبط بعض الأدوات لاستخدام IPv6 على نظام لينكس. أوامر iptables الأساسية الآن وبعد أن صار لديك المفاهيم الأساسية حول iptables، فإنّه يجب علينا تغطية الأوامر الأساسية التي سيتم استعمالها لتشكيل مجموعات قواعد iptables أكبر بالإضافة إلى إدارة واجهة iptables بشكلٍ عام. أولًا، يجب عليك أن تنتبه إلى أنّ أوامر iptables يجب أن يتم تشغيلها بصلاحيات الجذر (root privileges). هذا يعني أنّه يجب عليك الولوج إلى النظام باسم المستخدم root، استخدم su أو sudo -i للولوج إلى صدفة المستخدم الجذر، أو يمكنك ببساطة وضع sudo قبل جميع الأوامر التي ستطبّقها. سنستخدم sudo في هذا الدرس بما أنّها طريقة شائعة الاستخدام على نظام Ubuntu. نقطة جيدة للبداية بها هي كيفية سرد قواعد iptables المُستخدمة حاليًا. يمكنك فعل هذا باستخدام الخيار -L : $ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination كما يمكنك أن ترى، لدينا ثلاث سلاسل (chains) هنا. يمكننا أيضًا أن نرى السياسة المتّبعة في كلّ سلسلة (كل سلسلة افتراضيًا تمتلك سياسة ACCEPT للاتصالات المارّة منها). يمكننا أيضًا رؤية بعض ترويسات العواميد في ناتج الأمر السابق، إلّا أنّنا فعليًا لا نرى أيّ قواعد مطبّقة. هذا بسبب أنّ Ubuntu لا تأتي مع مجموعةٍ افتراضية من قواعد iptables. يمكننا رؤية الخرج بصيغةٍ تعكس الأوامر الضرورية لتفعيل كلّ قاعدة وسياستها عبر استخدام الخيار -S : $ sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT لإعادة إنتاج الإعدادات وتطبيقها من جديد، سيجب علينا فقط كتابة الأمر sudo iptables متبوعًا بكلّ واحدٍ من السطور الظاهرة في الخرج. (اعتمادًا على الإعدادات، قد يكون الأمر أكثر تعقيدًا في حال كنّا متّصلين عن بعد إلى الخادوم حيث أننا لا نريد إضافة قواعد iptables معيّنة تمنع جميع الاتصالات الواردة إليها مثلًا دون استثناء اتّصالنا الحالي لكي لا ينقطع فجأة ولكي يبقى متّصلًا). إذا كان لديك قواعد بالفعل لديك في iptables وكنتَ ترغب بإتلافها والبدء من جديد، فيمكنك فعل ذلك عبر تطبيق: $ sudo iptables -F مرةً أخرى، سياسة قبول الاتصالات أو رفضها مهمّة هنا، لأنّه وبينما يتم حذف جميع القواعد الأخرى من السلاسل الخاصّة بك، فإنّ السياسة الافتراضية لن تتغيّر باستخدام هذا الأمر. هذا يعني أنّه في حال كنت متّصلًا عن بعد بخادومك، فإنّه يجب عليك التأكّد من أنّ السياسة الافتراضية لسلسلتيّ INPUT و OUTPUT هي ACCEPT بالتزامن مع قيامك بإتلاف قواعدك السابقة. يمكنك فعل ذلك عبر تطبيق الأوامر التاليّة: $ sudo iptables -P INPUT ACCEPT $ sudo iptables -P OUTPUT ACCEPT $ sudo iptables -F يمكنك تغيير سياسة الحظر أو الترك (drop) مجددًا إلى DROP بعد أن تقوم بإعداد القواعد التي تسمح ببقاء اتّصالك الحالي. سنفصّل كيفيّة ذلك بعد قليل. إنشاء قاعدتك الأولى سنبدأ ببناء سياسة جدار الحماية الخاصّ بن حول قبول أو رفض الاتصالات. كما قلنا أعلاه، فإنّنا سنعمل مع سلسلة INPUT بما أنّها المصدر الرئيسي لتدفّق الزوار القادم إلى خادومنا. سنبدأ مع القاعدة التي تحدّثنا عنها مسبقًا من قبل بالأعلى: القاعدة التي تسمح لنا بشكل خاص بمتابعة اتّصال SSH الحالي. القاعدة الكاملة التي نحتاج إليها هي هذه: $ sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT قد يبدو هذا معقّدا للغاية لك في الوهلة الأولى، إلّا أنّ معظم مكوّنات الأمر السابق ستكون ذات معنى بالنسبة لك عندما تفهمها: -A INPUT: يقوم الخيار -A بإضافة قاعدةٍ ما إلى نهاية السلسلة المطلوبة. هذا هو الجزء الذي يقوم بإخبار iptables بأنّنا نريد إضافة قاعدةٍ جديدة إلى سلسلة معيّنة، والسلسلة التي نريدها في مثالنا حاليًا هي سلسلة INPUT. -m conntrack: يمتلك iptables عدّة وظائف داخليّة، ولكنّه أيضًا يمتلك مجموعةً من الامتدادات والوحدات التي تقوم بتوفير مزايا إضافيّة. إنّنا نقوم في هذا الجزء من الأمر بإخبار iptables بأنّنا نريد الحصول على إذن بالوصول إلى الوظيفة التي يتم توفيرها عبر الوحدة المسماة "conntrack”. تعطينا هذه الوحدة وصولًا إلى الأوامر التي يمكن أن يتم استخدامها بناءً على علاقة حزمة البيانات الداخلة بالاتّصال السابق. --ctstate: هذا واحدٌ من الأوامر التي أصبحت متوفّرة بعد أن تم استدعاء وحدة "conntrack”. يسمح لنا هذا الأمر بمطابقة حزم البيانات بناءً على ماهيّة ارتباطها بحزم البيانات التي رأيناها من قبل. إننا نقوم بتمرير قيمة ESTABLISHED للسماح بمرور حزم البيانات الداخلة التي هي جزء من اتّصالٍ عاملٍ حاليًا فقط. ونقوم بتمرير قيمة RELATED للسماح بمرور حزم البيانات المرتبطة باتّصالٍ مُنشَئٍ بالفعل. هذا الجزء من القاعدة هو الجزء الذي يتطابق مع جلسة SSH الحالية الخاصّة بنا. -j ACCEPT: يقوم هذا الخيار بتحديد هدف مطابقة حزم البيانات. هنا، نقوم بإخبار iptables أنّ حزم البيانات التي تطابق القاعدة السابقة يجب أن يتم السماح لها بالمرور. قمنا بوضع هذه القاعدة في البداية لأننا أردنا أن نتأكّد أنّ اتصالنا الحالي مطابق، مقبول وخارج إطار السلسلة قبل تنفيذ أيّ قواعد DROP. يمكننا الآن رؤية حالة التغييرات التي قمنا بها عن طريق: $ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination الآن وبعد أن صرتَ تعرف الصياغة العامّة لقواعد iptables، فلنتابع عبر استعراض المزيد من الحالات التي سنحتاج فيها إلى قبول الاتّصالات. قبول الاتّصالات المهمّة الأخرى أخبرنا iptables أن يبقي أيّ اتصالاتٍ مفتوحة على وضعها الحالي بالإضافة إلى السماح بالاتصالات الجديدة المرتبطة بتلك الاتصالات. على كلّ حال، نحتاج إلى إنشاء بعض القواعد الضرورية لتحديد متى نريد قبول اتّصالاتٍ جديدة لا تطابق هذه المعايير التي طبّقناها. نريد إبقاء منفذين اثنين مفتوحين بالتحديد. نريد إبقاء منفذ اتّصال SSH الخاصّ بنا مفتوحًا (سنفترض في هذا الدرس أنّ المنفذ الافتراضي له هو المنفذ 22. إذا كنتَ غيّرت هذا المنفذ على خادومك من إعدادات SSH فقم بتعديل قيمته هنا). سنقوم أيضًا بافتراض أنّ هذا الحاسوب يقوم أيضًا بتشغيل خادوم ويب يعمل على المنفذ 80. إذا لم يكن هذا هو نفس الوضع بالنسبة لك فلن تحتاج تطبيق القاعدة التالية. السطران اللذان سنستعملهما لتطبيق هذه القواعد هما: sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT كما يمكنك أن ترى، هذه القواعد مشابهة جدًا لقاعدتنا الأولى التي كتبناها، ولكنها ربما تكون أكثر بساطةً. الخيارات الجديدة هي: -p tcp: يقوم هذا الخيار بمطابقة حزم البيانات في حال كان البروتوكول المستخدم هو TCP. هذا البروتوكول هو بروتوكولٌ مستخدم بواسطة معظم التطبيقات لأنّه يسمح بتواصلٌ مرن وقوي بين المستخدم والتطبيق. --dport: يكون هذا الخيار متوفّرًا للاستخدام فقط في حال كان الخيار -p tcp موجودًا في الأمر. إنّه يقوم أيضًا بتحديد رقم المنفذ الذي يجب مطابقة حزم البيانات عبره. تقوم القاعدة الأولى بمطابقة حزم البيانات المارّة عبر بروتوكول TCP بالمنفذ 22، بينما تقوم الثانية بمطابقتها عبر المنفذ 80. هناك قاعدة ACCEPT أخرى يجب علينا التأكّد من أنّ خادومنا يقبلها بشكل صحيح. غالبًا، تتواصل الخدمات (services) مع بعضها البعض على الحاسوب عبر إرسال حزم بياناتٍ فيما بينها، وهي تقوم بذلك عبر الاستفادة من واجهة شبكةٍ زائفة تدعى loopback device ، والتي تقوم بتوجيه التدفّق إلى نفسها عوضًا عن الأجهزة الأخرى. لذا إذا كانت واحدة من الخدمات تريد التواصل مع خدمةٍ أخرى تستمع إلى المنفذ 4555، فإنّه بمقدورها إرسال حزمة بيانات إلى المنفذ 4555 على الشبكة الزائفة loopback device. نريد أن يتم السماح بهذا النوع من السلوك بين الخدمات لأنّه ضروري للعديد من برامج نظام التشغيل. القاعدة التي نحتاج تطبيقها هي هذه: $ sudo iptables -I INPUT 1 -i lo -j ACCEPT يبدو هذا الأمر مختلفًا قليلًا عن الأوامر السابقة. فلنشرح ما يفعله: -I INPUT 1: يقوم الخيار -I بإخبار iptables بإدراج قاعدةٍ جديدة. هذا الخيار مختلف عن الخيار -A والذي يقوم بإضافة القاعدة الجديدة إلى نهاية قواعد iptables. يحتاج الخيار -I إلى اسم السلسلة والمكان الذي تريد إدراج القاعدة الجديدة فيه. في حالتنا، فإننا نقوم بإضافة هذه القاعدة كأول قاعدة في سلسلة INPUT. هذا سيدفع بقية القواعد إلى الأسفل بدرجةٍ واحدة تلقائيًا. نحتاج لهذه القاعدة أن تكون بالأعلى لأنّها أساسية ولا يجب أن يتم التأثير عليها عبر قواعد فرعيّة أخرى. -i lo: يقوم هذا المكوّن من القاعدة بمطابقة ما إذا كانت الواجهة التي تستخدمها حزمة البيانات هي واجهة "lo”. واجهة "lo” هي عبارة عن اسمٍ آخر لـloopback device. هذا يعني أنّ أيّ حزمةِ بياناتٍ تستعمل تلك الواجهة الشبكيّة للتواصل (حزم البيانات الناتجة في خادومنا، إلى خادومنا) يجب أن يتم قبولها من طرف iptables. لرؤية قواعدنا الحاليّة، يجب أن نستخدم الخيار -a . هذا بسبب أنّ الخيار -L لا يتضمّن بعض المعلومات، مثل اسم الواجهة المرتبطة بالقواعد، والذي يعتبر جزءًا مهمًّا في القاعدة التي قمنا بإضافتها: $ sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT تضمين قاعدة حظر (Drop) نمتلك الآن 4 قواعد منفصلة تقبل الاتصالات بناءً على معايير معيّنة. وبالرغم من ذلك، فإنّا خادومنا حاليًا لا يحظر وصول أيّ شيء إليه. إذا دخلت حزمة بياناتٍ إلى سلسلة INPUT ولم تكن مطابقة لأيٍّ من القواعد الأربعة التي أدخلناها، فإنّه سيتم تحويلها إلى السياسة الافتراضية للتعامل مع حزم البيانات، والتي هي حاليًا "قبول حزم البيانات جميعها"، ونحتاج لتغيير هذا الأمر. هناك طريقتان يمكننا فعل ذلك بهما، مع بعض الاختلافات الجوهرية. الطريقة الأولى التي يمكننا من خلالها القيام بهذا هي عن طريق تعديل السياسة الافتراضية لسلسلة INPUT. يمكننا القيام بذلك عبر كتابة: $ sudo iptables -P INPUT DROP ستقوم القاعدة السابقة بالتقاط أيّ حزم بياناتٍ تفشل بالمرور عبر سلسلة INPUT الخاصّة بنا ويمنع وصولها إلى الخادوم. هذا ما ندعوه بسياسة المنع الافتراضيّة (default drop policy)، من مساوئ هذه الطريقة هي أنّ قاعدة الـDROP هذه يتم إلغاؤها في حال تم مسح قواعد iptables (حيث أنّها قاعدة هي الأخرى وبالتالي سيتم مسحها معها). قد تكون هذه الطريقة أكثر أمنًا، ولكنك قد تواجه عواقب وخيمة في حال لم يكن لديك طريقةٌ أخرى للوصول إلى خادومك. في DigitalOcean، يمكنك الولوج عبر لوحة التحكّم إلى خادومك والوصول إلى طرفيّة ويب تمكّنك من التحكّم به إذا حصل هذا. طرفيّة الويب هذه تعرّف نفسها على أنّها اتصال وهمي محلّي ولذلك فإنّ قواعد iptables لا تؤثّر عليها. قد تودّ لخادومك أن يقوم بحظر جميع الاتصالات في حال مسح جميع القواعد. قد يمنع هذا من ترك خادومك مفتوحًا للجميع. وهذا يعني أيضًا أنّه بمقدورك بسهولة إضافة القواعد إلى نهاية أيّ سلسلة تريدها بينما تحظر حزم البيانات التي لا تريدها بسهولة. إذا قمتَ بتغيير السياسة الافتراضيّة لسلسلة INPUT، فإنّه يمكنك إرجاعها عبر تطبيق: $ sudo iptables -P INPUT ACCEPT الآن، يمكنك إضافة قاعدة إلى نهاية السلسلة والتي ستقوم بحظر أيّ حزم بياناتٍ متبقية: $ sudo iptables -A INPUT -j DROP النتائج تحت شروطٍ تشغيلية عادية ستكون بالضبط هي نفس سياسة الحظر الافتراضيّة. تعمل هذه القاعدة عبر مطابقة كلّ حزمة بياناتٍ متبقية تصل إليها. يمنع هذا حزمةَ البيانات من الوصول إلى الخادوم في حال فشلت بتجاوز القواعد السابقة التي قمنا بإنشائها. بشكلٍ عام، يتم استخدام هذه القاعدة لجعل السياسة الافتراضيّة في التعامل مع الاتصالات تقبل التدفّق الواصل إليها. بهذه الطريقة، في حال كان هناك أيّ مشاكل وتم مسح جميع القواعد، فإنّك ستبقى قادرًا على الوصول إلى الآلة عبر الشبكة. بالطبع، هذا يعني أيضًا أنّ أيّ قاعدةٍ إضافية تودّ إضافتها إلى نهاية السلسلة يجب أن تكون قبل قاعدة الحظر أو الـdrop. يمكنك فعل هذا عبر حذف قاعدة الحظر مؤقتًا عبر: $ sudo iptables -D INPUT -j DROP $ sudo iptables -A INPUT new_rule_here $ sudo iptables -A INPUT -j DROP أو، يمكنك إدراج القواعد التي تحتاجها في نهاية السلسلة (ولكن قبل قاعدة الـdrop) عبر تحديد رقم السطر. لإدراج قاعدةٍ في السطر رقم 4، يمكنك كتابة: $ sudo iptables -I INPUT 4 new_rule_here إذا كنتَ تواجه مشاكل في معرفة إلى أيّ سطرٍ تنتمي أيّ قاعدة، فيمكنك إخبار iptables بأن يقوم بسرد السطور المتوفّرة عبر: $ sudo iptables -L –line-numbers Chain INPUT (policy DROP) num target prot opt source destination 1 ACCEPT all -- anywhere anywhere 2 ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED 3 ACCEPT tcp -- anywhere anywhere tcp dpt:ssh 4 ACCEPT tcp -- anywhere anywhere tcp dpt:http Chain FORWARD (policy ACCEPT) num target prot opt source destination Chain OUTPUT (policy ACCEPT) num target prot opt source destination يمكن لهذا أن يكون مفيدًا للتأكّد من أنّك تضيف القاعدة إلى مكانها الصحيح. حفظ إعدادات iptables الخاصّة بك افتراضيًا، تكون القواعد التي تضيفها إلى iptables غير دائمة. هذا يعني أنّك عندما تقوم بإعادة تشغيل خادومك، فإنّ جميع قواعد iptables ستختفي. هذه المشكلة في الواقع هي ميّزة لبعض المستخدمين لأنّها تعطيهم فرصةً للعودة إلى التحكّم بالخادوم في حال قاموا بحبس أنفسهم خارجها عن طريق الخطأ في تطبيق القواعد. وعلى كلّ حال، معظم المستخدمين سيودّون أن يكون هناك طريقة تلقائية لحفظ القواعد التي أنشؤوها وتحميلها تلقائيًا عند إقلاع الخادوم. هناك عدّة طرق لفعل هذا، لكنّ أسهلها هو باستخدام حزمة iptables-presistent، يمكنك تحميل هذه الحزمة من مستودعات Ubuntu الافتراضيّة: $ sudo apt-get update $ sudo apt-get install iptables-persistent أثناء التثبيت، سيتم سؤالك عمّا إذا كنتَ تحبّ حفظ قواعد iptables الحاليّة ليتم تحميلها تلقائيًا. إذا كنتَ مسرورًا مع إعداداتك الحاليّة (واختبرت قدرتك على الوصول إلى اتصالات SSH جديدة مستقلة) فإنّه يمكنك الموافقة على ذلك. سيتم سؤالك أيضًا عمّا إذا كنتَ تريد حفظ قواعد IPv6 التي قمتَ بإعدادها، يتم إعداد هذه القواعد عبر أداة منفصلة تدعى ip6tables والتي تتحكم بحزم بيانات IPv6 بنفس الطريقة. بمجرّد اكتمال التثبيت، ستتوفر خدمة جديدة لديك تدعى iptables-presistent وهي مُعدّة ليتم تشغيلها عند الإقلاع. ستقوم هذه الخدمة بتحميل قواعد iptables الحاليّة وتطبيقها من جديد في كلّ مرّة يتم إعادة تشغيل النظام فيها. الخاتمة يجب أن تكون الآن قد امتلكت نقطة بداية جيّدة للبدء في تطوير جدارٍ ناري يلبي احتياجاتك. هناك العديد من أدوات الجدران الناريّة الأخرى التي يمكنك استخدامها والتي قد تكون أسهل، ولكن iptables أداةٌ جيّدة لتعلّمها، ذلك لأنّها توفّر بنية netfilter تحتية جيّدة للاستعمال ولأنّها متوفّرة افتراضيًا في العديد من أنظمة التشغيل. ترجمة -وبتصرّف- للمقال: How To Set Up a Firewall Using IPTables on Ubuntu 14.04.

بعد إنشاء الإعدادات الدُنيا لخادومك الافتراضي الجديد واستخدامها، هناك بعض الخطوات الإضافيّة المستحسنة التي من المهمّ أن تطبّقها. في هذا الدرس، سنتابع إعداد خواديمنا عبر تنفيذ إجراءاتٍ إضافيّة مستحسنة عليها. الأهداف والمتطلبات قبل أن تبدأ بهذا الدرس، يجب أن تقرأ درس إعداد خادوم Ubuntu 14.04 من الصفر. قراءة ذلك الدرس أولًا هو أمرٌ مهمّ بهدف إعداد حسابات المستخدمين، إعداد وضبط الصلاحيّات المرتبطة بـsudo وقفل اتصالات SSH للحصول على المزيد من الحماية. بمجرّد أن تقرأ وتطبّق الدرس المذكور أعلاه، ستكون قادرًا على المتابعة مع هذه المقالة. في هذا الدرس، سنركّز على إعداد بعض المكوّنات الإضافية المستحسنة لخادومنا. سيتضمن هذا إعداد جدارٍ ناري، مزامنة بروتوكول وقت الشبكة وإعداد ملفّات الـSwap. إعداد جدار ناري بسيط تقوم جدران الحماية بتوفير درجة حمايةٍ بسيطة لخادومك. هذه التطبيقات مسؤولة عن منع وصول التدفّقات (traffics) إلى كلّ المنافذ الموجودة في خادومك باستثناء تلك المنافذ/الخدمات التي قمتَ بالسماح لها بالوصول. تأتي توزيعة Ubuntu مع اداة تدعى UFW يُمكن استخدامها لإعداد سياسات (policies) الجدار الناري الخاصّ بك. استراتيجيّتنا البسيطة ستكون قفلَ كلّ شيءٍ لا نرى أنّه من الصواب تركه مفتوحًا. قبل أن نقوم بتفعيل أو إعادة تحميل جدارنا الناريّ، سنقوم بإنشاء القواعد (rules) التي تعرّف تلك الاستثناءات التي نريدها من سياسة التعامل مع حزم البيانات الواردة. أولًا، سنحتاج إلى إنشاء استثناء لاتّصالات SSH لنتمكّن من الوصول إلى الصلاحيات الإدارية لخادومنا عن بعد. يعمل عفريت SSH (يدعى SSH daemon) على المنفذ 22 افتراضيًا. يمكن لـufw أن يقوم بتطبيق القواعد التي تريدها على SSH طالما أنّك لم تقم بتغيير ذاك المنفذ. لذا إذا لم تكن قد عدّلت المنفذ الافتراضي لـSSH، فيمكنك السماح باستثنائه عبر: sudo ufw allow ssh إذا قمتَ بتعديل المنفذ الافتراضي الذي يعمل عليه عفريت SSH، فسيجب عليك السماح له بالوصول إلى الخادوم عبر تحديد رقم المنفذ الجديد مع بروتوكول TCP: sudo ufw allow 4444/tcp هذا هو أبسط إعدادٍ متوفّر للجدار الناري. سيسمح فقط بالوصول إلى منفذ SSH الخاصّ بخادومك وسيقوم بحجب كلّ الخدمات الأخرى ومنعها من الوصول إلى الخادوم. إذا كنتَ تريد السماح بوصول المزيد من الخدمات، فسيجب عليك فتح الجدار الناري لكلٍّ منفذٍ تريده بالتحديد. إذا كنتَ تخطط لتشغيل خادوم ويب لبروتوكول HTTP، فستحتاج إلى السماح بالوصول للمنفذ 80: sudo ufw allow 80/tcp إذا كنتَ تريد تشغيل خادوم ويب مع تفعيل SSL/TLS، فيجب عليك السماح بمرور التدفّق عبر المنفذ 443 أيضًا: sudo ufw allow 443/tcp إذا كنتَ تحتاج إلى تفعيل بريد SMTP، فيجب أن يكون المنفذ 25 مفتوحًا أيضًا: sudo ufw allow 25/tcp بعد أن تنتهي من إضافة هذه الاستثناءات، يجب أن تقوم بمعاينة التغييرات التي قمتَ بها عن طريق: sudo ufw show added إذا كان كلّ شيءٍ يبدو جيّدًا، فيمكنك الآن تفعيل الجدار الناري عبر كتابة: sudo ufw enable سيتم سؤالك لتأكيد اختياراتك، لذا قد تكتب "y" إذا رغبتَ بالمتابعة. سيقوم هذا الأمر بتطبيق الاستثناءات التي قمتَ بإضافتها وحجب جميع أنواع التدفّقات الأخرى إلى خادومك، كما سيقوم بإعداد الجدار الناري الخاصّ بك ليبدأ تلقائيًا عند الإقلاع. تذكّر أنّه يجب عليك فتح أيّ منافذ إضافية لأيّ خدمات إضافية تحتاج الوصول عبر تلك المنافذ. للمزيد من المعلومات التفصيليّة، راجع مقالتنا حول إعداد جدار ufw الناري. إعداد المناطق الزمنية ومزامنة بروتوكول وقت الشبكة الخطوة التالية هي ضبط إعدادات التوطين (localization) لخادومك وإعداد مزامنة بروتوكول وقت الشبكة (NTP - Network Time Protocol). ستضمن الخطوة الأولى أنّ خادومك يعمل باستخدام المنطقة الزمنية الصحيحة، وستقوم الخطوة الثانية بإعداد نظامك لمزامنة ساعة النظام الخاصّة به تلقائيًا مع الساعة العالمية عبر الاتصال بخواديم NTP العالمية، وهذا لضمان عدم وجود فرق بين التوقيتين (توقيت الخادوم وتوقيت الوقت الحقيقي في المنطقة التي تعيش بها) ولجعل الوقت المضبوط على خادومك هو نفسه الوقت المضبوط على الخواديم الأخرى. إعداد المناطق الزمنية ستكون خطوتنا الأولى هي إعداد المنطقة الزمنيّة الخاصّة بخادومنا. هذا الأمر سهل للغاية ويمكن فعله عبر إعادة إعداد حزمة tzdata: sudo dpkg-reconfigure tzdata سيتم عرض قائمة لك تحتوي مناطق العالم المتوفّرة، اختر المنطقة التي تعيش بها: بعد اختيار منطقة معيّنة، ستكون قادرًا على اختيار منطقة زمنيّة معيّنة لضبطها في خادومك الشخصي عبر اختيار العاصمة أو المدينة التي تعيش بها: بعد هذا، سيتم تحديث نظامك ليستخدم المنطقة الزمنيّة الجديدة، وسيتم طباعة النتائج إلى الشاشة: Current default time zone: 'America/New_York' Local time is now: Mon Nov 3 17:00:11 EST 2014. Universal Time is now: Mon Nov 3 22:00:11 UTC 2014. إعداد مزامنة NTP الآن وبعد أن قمتَ بإعداد المنطقة الزمنيّة، يجب عليك إعداد NTP. ستسمح عمليّة مزامنة NTP لحاسوبك بالبقاء متزامنًا مع خواديم الويب الأخرى حيث سيتم توحيد الوقت الذي يستعمله خادومك مع الخواديم الأخرى حول العالم، وهو ما سيوفّر المزيد من الدقّة للعمليات التي تحتاج وقتًا دقيقًا لتتم بنجاح. لمزامنة NTP، سنستخدم خدمة تدعى ntp، والتي يمكننا تثبيتها من مستودعات Ubuntu الافتراضية: sudo apt-get update sudo apt-get install ntp هذا هو كلّ ما تحتاج فعله لإعداد مزامنة NTP على Ubuntu. سيبدأ عفريت ntp تلقائيًا بعد التثبيت وعند كلّ إقلاع وسيبقى طوال الوقت عاملًا على مزامنة وقت النظام مع خواديم NTP العالميّة لضمان التوافقية. اضغط هنا إذا أردت تعلّم المزيد عن خواديم NTP. إنشاء ملف Swap يسمح إنشاء ملفّ "Swap" على خادوم لينكس للنظام بنقل المعلومات والبرامج الأقل استعمالًا حاليًا من الذاكرة العشوائية RAM إلى موقعٍ معيّن على القرص الصلب. الوصول إلى البيانات الموجودة على القرص الصلب هو أبطئ بكثير من عملية الوصول إليها لو كانت على الذاكرة العشوائية RAM، ولكنّ توفير قرص Swap قد يكون الأمر الفاصل بين بقاء تطبيقاتك العاملة حاليًا على قيد الحياة وبين تحطّمها (crash). هذا الأمر مفيد للغاية خاصةً في حال كنتَ تنوي استضاف قواعد بيانات على خادومك. تختلف النصيحة عن الحجم الأفضل لقرص الـSwap اعتمادًا على ما تريد القيام به. ولكن بشكلٍ عام، فإنّ جعل حجمه بضعف حجم الذاكرة العشوائية RAM سيكون فكرةً جيّدة. قم باقتطاع المساحة التي تريد تخصيصها لقرص الـSwap من نظام الملفّات الكلّي باستخدام أداة fallocate. كمثال، إذا احتجنا إلى عمل قرص Swap حجمه 4 جيجابايت، فيمكننا إنشاء ملفّ Swap بالمسار /swapfile عن طريق كتابة: sudo fallocate -l 4G /swapfile بعد إنشاء الملفّ، سنحتاج إلى تقييد الوصول إليه لكي لا يتمكن المستخدمون الآخرون أو العمليّات الأخرى من رؤية البيانات المكتوبة عليه: sudo chmod 600 /swapfile نمتلكُ الآن ملفّ Swap مضبوطًا على الصلاحيّات الصحيحة. لإخبار نظامنا بتهيئة الملفّ وإعداده ليكون قرص Swap، فلنطبّق: sudo mkswap /swapfile يمكننا الآن أن نخبر نظامنا أن يستخدم الملفّ الجديد عن طريق تطبيق: sudo swapon /swapfile وسيبدأ النظام باستخدامه لجلستنا الحاليّة، هناك مشكلة وهي أنّ النظام لن يستخدمه سوى لجلستنا الحاليّة وليس طوال الوقت، ولذلك علينا تعديل ملفٍ في النظام لجعل خادومنا يقوم بالمهمّة تلقائيًا عند الإقلاع. يمكنك فعل ذلك عبر كتابة: sudo sh -c 'echo "/swapfile none swap sw 0 0" >> /etc/fstab' مع هذه الإضافة، يجب أن يكون نظامك قادرًا على استخدام ملفّ Swap تلقائيًا عند كل إقلاع. أين الطريق من هنا؟ بدأتَ الآن بداية جيّدة في إعداد خادومك العامل بنظام لينكس. من هنا، هناك العديد من الأماكن التي يمكنك التوجّه إليها الآن. أولًا، قد تودّ أخذَ لقطةٍ احتياطية (snapshot) من خادومك بإعداداته الحاليّة. خذّ لقطةٍ احتياطية من إعداداتك الحاليّة إذا كنتَ مرتاحًا مع إعداداتك الحاليّة وكنتَ تودُّ استخدامها كقاعدةٍ أساسية في خواديمك المستقبليّة، فيمكنك أخذ لقطةٍ احتياطيّة لخادومك عبر لوحة تحكّم DigitalOcean. للقيام بهذا، قم بإطفاء خادومك من سطر الأوامر عبر كتابة: sudo poweroff الآن، في لوحة تحكّم DigitalOcean، يمكنك أخذ لقطةٍ احتياطية عبر زيارة لسان "Snapshots" الموجود في صفحة خادومك: بعد أخذ اللقطة الاحتياطية التي تريدها، ستكون قادرًا على استعمال تلك الصورة كقاعدةٍ لعمليات تثبيت وإعداد خواديمك المستقبلية عبر اختيار تلك اللقطة الاحتياطية من لسان "My Snapshots" كنظام تشغيل أثناء عمليّة الإنشاء: مصادر إضافيّة وخطواتٌ أخرى من هنا، يعتمد مسارك بشكلٍ كامل على ما تودّ فعله بخادومك. قائمة الدروس أدناه مرهقة للتطبيق، ولكنّها تمثّل جزءًا مهمًا من الإعدادات التي يجب تنفيذها من قبل المستخدمين بالخطوة التاليّة: كيف تُثبّت حزم LEMP كـ: Linux, PHP, Nginx و MySQL على أوبونتو 14.04 كيف تُثبّت حزم LAMP كـ: Linux, PHP, Apache و MySQL على أوبونتو 14.04 تثبيت سكربت إدارة المحتوى ووردبريس على خادوم Apache تثبيت سكربت إدارة المحتوى ووردبريس على خادوم Nginx تثبيت سكربت إدارة المحتوى دروبال على خادوم Apache تثبيت Node.js تثبيت Ruby on Rails مع RVM تثبيت Laravel, إطار عمل PHP تثبيت Puppet لإدارة البنى التحتية الخاتمة بعد هذا الدرس، يجب أن تكون صرتَ تعرف كيفيّة إعداد بنيةٍ تحتية جيّدة لخواديمك الجديدة. لحسن الحظّ، لديك قائمة جيّدة بالأفكار التي يمكنك تطبيقها كخطوةٍ تالية. يمكنك تصفّح المقالات الموجودة بقسم DevOps بموقع أكاديمية حسوب لرؤية المزيد من الدروس التي يمكنك تطبيقها. ترجمة -وبتصرّف- للمقال: Additional Recommended Steps for New Ubuntu 14.04 Servers.