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

الأعضاء
  • المساهمات

    78
  • تاريخ الانضمام

  • تاريخ آخر زيارة

  • Days Won

    1

السُّمعة بالموقع

25 Excellent

10 متابعين

آخر الزُوّار

2,290 زيارة للملف الشّخصي
  1. نعود إليكم في الجزء الثاني من درس "كيف تختار سياسة فعّالة للجدار الناري لتأمين خواديمك" لنتحدث عن المزيد من الأمور والنصائح التي يجب أخذها بعين الاعتبار عند إعداد الجدار الناري الخاصّ بخادومك لأوّل مرّة. سياسات ICMP هناك آراءٌ مختلفة حول ما إذا كان يجب قبول حِزَم بيانات ICMP القادمة إلى خادومك أم لا. ICMP هو بروتوكول يستعمل لعدة أشياء، وغالبًا ما يتم إرساله مجددًا، كما رأينا سابقًا، لإعطاء معلومات عن حالة الطلبات التي تستخدم بروتوكولات أخرى. ربّما أبرز مهامه هو إرسال واستقبال نبضات الشبكة (network pings) لفحص قابلية الاتصال بالأجهزة المضيفة البعيدة. هناك عدة استخدامات غير شائغة أخرى لبروتوكول ICMP ولكنها ما تزال مفيدة. يتم تمييز حزم ICMP عبر "النوع (type)" وبعدها عبر "الشفرة (code)"، حيث يقوم النوع بتحديد معنى الرسالة العام، كمثال، Type 3 يعني أنّ الوجهة غير قابلة للوصول، بينما يتم استخدام "الشفرة" لإعطاء المزيد من المعلومات عن “النوع”. كمثال، "ICMP Type 3 Code 3" يعني أنّ المنفذ الذي تحاول الاتصال من خلاله بوجهتك غير متوفّر، بينما "ICMP Type 3 Code 0" تعني أنّ شبكة الوجهة التي تحاول الاتصال بها غير متوفّرة بالمرّة. الأنواع التي يمكن دوما حجبها هناك بعض الأنواع (Types) لبروتوكول ICMP تكون مهملة طوال الوقت، لذا يجب غالبًا حجبها. من بين هذه الأنواع: ICMP source quench (النوع 4 و code 0) Alternate host (النوع 6) الأنواع 1, 2, 7 و 15 محفوظة للاستخدام المستقبلي أو المتقدّم وليست مهمّة. الأنواع التي يمكن حجبها اعتمادا على إعدادات الشبكة تكون بعض أنواع ICMP مفيدة في إعدادات شبكةٍ معيّنة، ولكن يجب حجبها في بيئةٍ أخرى. كمثال، رسائل إعادة توجيه ICMP (النوع 5 أو type 5) يمكن أن تكون مفيدة في التقاط تصميم الشبكات السيء. يتم إرسال إعادة توجيه ICMP عندما يكون هناك طريقٌ أفضل متوفّر أمام العميل. لذا إذا استقبل الموجّه (router) حزمة بيانات يجب توجيهها إلى مضيفٍ آخر على نفس الشبكة، فإنّه يقوم بإرسال رسالة إعادة توجيه عبر بروتوكول ICMP لإخبار العميل بأن يقوم بإرسال الحِزَم إلى المضيف الآخر في المستقبل. سيفيدك هذا إذا كنت تثق بشبكتك المحلية وكنت تريد التقاط أماكن عدم الكفاءة (inefficiencies) في جداول التوجيه (routing tables) أثناء الإعداد الأوّلي (إصلاح التوجيه الخاصّ بك هو حلٌّ أفضل على المستوى البعيد). لكن على شبكة غير موثوقة، يمكن لمستخدم سيء أن يقوم بإرسال رسائل إعادة التوجيه عبر برتوكول ICMP للتلاعب بجداول التوجيه الموجودة على أجهزة المضيفين (hosts). من أنواع ICMP الأخرى المفيدة في بعض الشبكات والمؤذية في أخرى هي حِزَم ما يعرف بـICMP router advertisement (النوع 9 أو type 9) وrouter solicitation (النوع 10 أو type 10). يتم استخدام حزم الإعلان (advertisement) والحثّ (solicitation) كجزء من IRDP (ICMP Internet Router Discovery Protocol)، وهو نظام يسمح للمضيفين - بعد الإقلاع أو الانضمام لشبكة ما - بأن بكتشفوا تلقائيًا الموجّهات (routers) المتوفّرة. من الأفضل في معظم الحالات للمضيف أن يمتلك طرق (routes) ثابتة مُعدّة خصيصًا للبوابات التي سيستعملها. يجب أن يتم قبول هذه الحزم في نفس حالات حزم التوجيه من ICMP. في الواقع، بما أنّ المضيف لن يعرف الطرق الأكثر تفضيلًا لنقل التدفّق من بين جميع الطرق المكتشفة، فإنّ رسائل إعادة التوجيه غالبًا ما تكون مطلوبة مباشرةً بعد الاكتشاف. إذا كنت لا تشغل خدمة تقوم بإرسال حزم حثّ التوجيه (router solicitation) أو خدمة تقوم بتعديل الطرق بناءًا على حزم الإعلان (advertisement packets) مثل rdisc، فيمكنك حظر هذه الحزم بأمان. الأنواع التي من الآمن السماح لها ستجد أنواع ICMP الآمنة عادةً أدناه، لكن ربّما تريد تعطيلها إذا كنت تريد أن تكون في أمانٍ أكثر. Type 8 — Echo request: هذه هي طلبات النبضات (ping requests) الموجّهة إلى خادومك. من الآمن السماح لها بالعمل على خادومك عادةً (منع هذه الحزم لن يخفي خادومك، هناك عدة طرق أخرى أمام المستخدمين ليعرفوا ما إذا كان خادومك يعمل حاليًا أم لا)، ولكن يمكنك منعها أو تحديد عناوين مصدر هذه الحزم وتقليلها إذا كنت تريد ذلك. Type 13 — Timestamp request: يمكن استخدام هذه الحزم بواسطة العملاء لجمع معلومات مواجهة الأعطال. يمكن استخدامها أيضًا في بعض تقنيات التقاط بصمات نظام التشغيل، لذا يمكنك منعها إن أردت. يمكن السماح للأنواع التالية عمومًا دون الحاجة إلى قواعد (rules) خاصّة عبر إعداد جدارك الناري ليسمح بالردود على الطلبات التي قام بإرسالها (عبر استخدام وحدة conntrack للسماح بتدفّق ESATABLISHED وRELATED). Type 0 — Echo replies: وهي عبارة عن الردود على طلبات النبضات (pings requests). Type 3 — Destination Unreachable: حِزَم بيانات الوجهة الغير متوفّرة العادية هي عبارة عن ردود طلبات تمّ إنشاؤها بواسطة خادومك، وهي تعني أنّه لم يتم توصيل حِزَم البيانات بشكلٍ صحيح. Type 11 — Time exceeded: هذا عبارة عن خطأ يتم إرجاعه في حال موت الحِزَم المُنشأة بواسطة خادومك قبل وصولها وجهتها بسبب تعدّيها لقيمة TTL الخاصّة بها. Type 12 — Parameter problem: يعني هذا أنّ حزمةً صادرة من خادومك قد تعرضت للتلف في طريقها. Type 14 — Timestamp responses: هي عبارة عن الردود على عمليات الاستعلام عن المنطقة الزمنية التي يتم تنفيذها بواسطة خادومك. حجب تدفّق ICMP بأكمله ما يزال أمرًا مستحسنًا من قبل العديد من خبراء الحماية، ولكن العديد من الناس الآن ينصحون باستخدام سياسات ICMP ذكية بدلًا من منعه بالكامل. تحديد الاتصال وتحديد التردد في بعض الخدمات وأنماط التدفّقات (traffic patterns)، ربّما تود السماح بالوصول من قبل جهاز العميل طالما أنّه لا يسيء استخدام هذا الوصول. هناك طريقتان لتقييد استخدام الموارد: تقييد الاتصال (connection limiting) وتقييد التردد أو المعدل (rate limiting). تقييد الاتصال يمكن أن يتم تفعيل تقييد الاتصال عبر استخدام امتدادات مثل connlimit للتحقق من عدد الاتصالات النشطة التي قام جهاز العميل بفتحها. يمكن أن يتم استخدام هذا لتقييد عدد الاتصالات المسموحة في وقتٍ واحد. إذا كنت تخطط لاستخدام تقييد الاتصال، فيجب عليك اتخاذ بعض القرارات بخصوص هذا بغض النظر عن طريقة تطبيقك له. هذه القرارات هي: هل سيكون التقييد بناءًا على العنوان، الشبكة أم على أمورٍ عامّة أخرى؟ هل سيكون التقييد لخدمة معينة فقط أم على الخادوم بأكمله؟ يمكن تقييد الاتصالات بناءًا على أجهزة الاستضافة أو شبكة معيّنة عبر استخدام بادئة شبكة ما (network prefix). يمكنك أيضًا تعيين حدٍّ أقصى لعدد الاتصالات المسموح بها لخدمة معيّنة أو للخادوم بأكمله. لا تنسى أيضًا أنّه بمقدورك استخدام جميع هذه الطرق أو بعضٍ منها لتحصل على خليط معقّد من السياسات المستعملة للتحكم في الاتصالات التي تريدها. تقييد التردد يسمح لك تحديد التردد أو تحديد المعدل (rate limiting) بإنشاء قواعد (rules) تقوم بإدارة تردد أو معدل التدفّق الذي سيقبله خادومك. هناك عدد من الامتدادات المختلفة التي يمكن استخدامها لتقييد التردد مثل limit، hashlimit وrecent. اختيار الأنسبة من هذه الامتدادات يعتمد على الطريقة التي تريد تقييد التردد خلالها. سيتسبب الامتداد limit للقاعدة في السؤال بأن يتم مطابقتها إلى حين الوصول إلى الحد الأقصى، بعدها سيتم ترك أيّ حزم بيانات إضافية أخرى. إذا قمت باستخدام حد مثل “5/ثانية/، فإنّ القاعدة ستقوم بالسماح بمطابقة 5 حزم في الثانية الواحدة، بعدها، لن تسمح لأيّ حزم بأن تقوم بعملية المطابقة. هذا جيّد لتحديد الحدّ الأعلى العام لخدمة معيّنة من الحزم. لكنّ امتداد hashlimit يعتبر أكثر مرونةً، حيث يسمح لك بتحديد بعض القيم التي سيستخدمها iptables لتحقيق عملية المطابقة كذلك. مثلًا، يمكن لـhashlimit أن يتحقق من عنوان المصدر ومنفذه، عنوان الوجهة ومنفذها أو حتّى تشكيلة من هذه القيم الأربعة لمطابقة كل مُدخَلة (entry). يمكنه أيضًا أن يقوم بالتحديد بناءًا على عدد الحزم أو البايتات المتلقاة، وهو ما يوفّر تحديدًا أكثر مرونة على مستتوى العميل أو مستوى الخدمات. يقوم امتداد recent ديناميكيًا بإضافة عنوان IP العميل إلى قائمة بيضاء أو يتحقق من وجوده في قائمة سوداء عند مطابقة القاعدة. يسمح لك هذا باستخدام منطق أكثر تعقيدًا لإنشاء قواعد متعددة للحصول على نتيجة مبهرة. يمتلك أيضًا القدرة على تحديد العدد والوقت كالامتدادات الأخرى، ولكنه قادر أيضًا على إعادة تعيين مدى الوقت (timerange) في حال رؤية المزيد من تدفّق البيانات، حيث يجبر العميل على وقف التدفّق في حال وصوله إلى الحد الأقصى. اختيار واحدٍ من هؤلاء لتستعمله على خادومك يعتمد بشكلٍ كامل على السياسة التي تريد تطبيقها في خادومك. الإدارة كوحدة متكاملة مقابل الإدارة كسلسلة جميع سياسة iptables مرسّخة في توسيع السلاسل المبنية فيه أساسًا (built-in chains). في الجدران النارية البسيطة، يكون هذا على شكل تغيير السياسة الافتراضية للسلاسل وإضافة القواعد. في الجدران النارية الأكثر تعقيدًا، غالبًا ما يكون من الجيد توسيع إطار عمل الإدارة عبر إضافة المزيد من السلاسل. السلاسل المكوّنة من طرف المستخدمين (User-created chains) مقيّدة بطبيعتها إلى السلسلة التي تستدعيها. السلاسل المكوّنة من طرف المستخدمين لا تملك أيّ سياسة افتراضية، لذا إذا لم تنجح حزمة بيانات ما في المرور عبر سلسلة مكوّنة من طرف المستخدم، فإنّها ستعود إلى السلسلة وتتابع المطابقة. مع أخذ هذا في عين الاعتبار، تصبح السلاسل المكوّنة بواسطة المستخدم مفيدة جدًا في الأغراض التنظيمية، جعل شروط مطابقة القواعد أكثر وضوحًا ولتحسين قابلية القراءة عبر تقسيم شروط المطابقة. إذا كنت تكرر عمليّة معينة لعددٍ كبير من القواعد، فحينها قد يكون من المفيد إنشاء "jump rule" مع العملية أو المطابقة والشروط المطلوبة المشتركة في سلسلة جديدة، يمكنك إضافة مجموعة من القواعد دون المطابقة المشتركة ضمن تلك السلسلة. بغضّ النظر عن التنظيم البسيط، يمكن لهذا أن يفيدك بشكلٍ أكبر. مثلًا، الاستخدام الذكي للسلاسل لمجموعات متشابهة من القواعد يعني أنّ إضافة القواعد في الموقع الصحيح سيكون أسهل وأقل تعرّضًا للأخطاء. ويمكن أن يكون أسهل كذلك في عرض وفهم أجزاء السياسة التي تهتم بها عبر تحديد السلسلة. الاختيار ما بين تضمين جميع قواعدك في واحدةٍ من السلاسل الموجودة بالفعل في الجدار الناري أو عبر إنشاء وتعديل سلاسل جديدة يعتمد بشكلٍ رئيسي لمدى التعقيد والبساطة والأهداف التي تسعى إلى تحقيقها على خادومك. خاتمة الآن، يفترض أنك تمتلك معرفة جيدة حول بعض القرارات التي يجب عليك اتخاذها عند تصميم سياسات الجدار الناري لخواديمك. بشكلٍ عام، الوقت الذي ستستغرقه في إعداد الجدار الناري لأوّل مرّة سيسهل مهام الإدارة عليك لاحقًا. صحيحٌ أنّ العملية ستحتاج الكثير من الوقت والخبرة والتجارب للحصول على أفضل سياسة تلائم خواديمك، ولكن القيام بهذا سيوفّر لك تحكمًا أكبر في حمايتها. إذا كنت تريد معرفة المزيد عن الجدران النارية و iptables بالتحديد، فيمكنك التحقق من المقالات التالية: كيف يعمل جدار iptables الناري. إعداد جدار ناري باستخدام iptables على Ubuntu 14.04. إعداد جدار ناري باستخدام UFW على Ubuntu 14.04. ترجمة -وبتصرّف- لـلمقال: How To Choose an Effective Firewall Policy to Secure your Servers لصاحبه Justin Ellingwood.
  2. استخدام الجدار الناري (firewall) يعتمد كثيرًا على السياسة (policy) التي ستتبعها في تصفية تدفّقات البيانات (data traffics) بنفس درجة اعتماده على تعلّمك للأوامر الأساسية وطريقة الاستخدام. بعض الجدران النارية مثل ـiptables تمتلك القدرة على فرض سياسات معيّنة يتم تحديدها من قبل مدير النظام، ولكن كواحدٍ من هؤلاء، يجب أن تعرف أفضل السياسات المناسبة لتطبيقها على البيئة الخاصّة بك. بينما تركّز دروسٌ أخرى على الأوامر اللازمة للحصول على جدار ناري فعّال، في هذا الدرس، سنناقش بعض الأمور التي يجب عليك فعلها عندما تقوم بتشغيل جدار ناري. ستؤثّر هذه الخيارات على الطريقة التي يتصرّف بها جدارك الناري، وعلى المدى الذي يجب إحكام إقفال خادومك إليه، بالإضافة إلى طريقة استجابته لمختلف الشروط التي قد تطرأ من حينٍ إلى آخر. سنستخدم iptables في درس اليوم، إلّا أنّ معظم ما سنتكلّم عنه سينطبق على أيّ أداة بغضّ النظر عن نوعها. اختيار السياسة الافتراضية عند بناء جدارٍ ناريّ فإن السياسة الافتراضية هي واحدة من الأشياء الأساسية التي يجب عليك التفكير فيها. تحدد السياسة الافتراضية ما يجب أن يحصل لتدفّقات البيانات في حال عدم مطابقتها لأيّ قاعدة (rule). يمكن افتراضيًا للجدار الناري أن يقبل أيّ تدفّق لا يطابق القواعد المعيّنة أو أن يرفضه. القبول افتراضيا مقابل الرفض افتراضيا سياسة "Accept" (قبول) الإفتراضية تعني أنّه سيتم السماح لأيّ تدفّق غير مطابق للقواعد المعيّنة مسبقًا بالمرور إلى الخادوم. لا ينصح باستخدام هذه السياسة افتراضيًا لأنّ هذا يعني أنّك ستقوم بعمل قائمة سوداء لمنع ما تريد منعه من الوصول إلى خادومك. القوائم السوداء صعبة الإدارة لأنّه يجب عليك متابعة وحظر جميع أنواع التدفّقات التي لا تريدها في خادومك. يمكن أن يؤدي هذا إلى الكثير من وجع الرأس بالإضافة إلى مشاكل تقنية في حال حصول غلطة بسيطة في القائمة السوداء مثلًا، لذلك هو أمرٌ غير مستحسن. الحلّ البديل هو "drop" (ترك) التدفّق افتراضيًا. هذا يعني أنّه لن يتم السماح لأيّ تدفّق لا يطابق القواعد المعيّنة مسبقًا بالوصول إلى الخادوم (أو الخروج منه)، وهو أمرٌ مشابه للقوائم البيضاء وقوائم تحكّم الوصول (Access Control List) حيث يجب السماح بشكلٍ استثنائي وخاصّ بأن يتم تشغيل وتنفيذ كلّ خدمة متوفّرة على حدى، والذي قد يحتاج الكثير من الوقت والجهد في البداية، ولكنّ هذا يعني أنّ السياسة الافتراضية الخاصّة بك ستكون أكثر أمانًا وستعرف بالضبط نوع تدفّق البيانات الداخل إلى خادومك. عليك الاختيار بين التوجّه نحو الخيار الأكثر أمانًا أو السماح للخدمات بالتحرّك بشكلٍ أكثر حرّية خارج الصندوق. صحيحٌ أنّ خيار استخدام سياسة "Accept" (قبول) افتراضيًا مع الجدار الناري قد يكون أفضل ما تفكّر به للوهلة الأولى، ولكن - في غالب الأحيان - من الأفضل في الواقع أن تستخدم سياسة "منع" افتراضيًا للجدار الناري. سياسة "drop" افتراضيا مقابل قاعدة "drop" نهائية الخيار السابق باستخدام سياسة "drop" (ترك) افتراضيًا يقود إلى قرارٍ مهم آخر. في iptables والجدران النارية المشابهة الأخرى، يمكن أن يتم تعيين السياسة الافتراضية باستخدام خصائص داخلية للجدار الناري، أو تضمينها عبر إضافة قاعدة "drop" (ترك) شاملة في نهاية قائمة قواعد الجدار الناري. الفرق بين هذين الطريقتين هو فيما سيحصل في حال تمّ مسح (flush) قواعد الجدار الناري. إذا كانت السياسة الافتراضية الداخلية في الجدار الناري الخاصّ بك معيّنة على "drop" (ترك) التدفّق وحصل يومًا ما وأن تمّ مسح قواعد الجدار الناري أو حذف بعضٍ منها عن طريق الخطأ مثلًا، فإنّ جميع الخدمات التي تشغّلها على الخادوم ستصبح غير قابلة للوصول. هذه غالبًا فكرة جيّدة عند ضبط الخدمات غير الحساسة على خادومك لكي لا يتم السماح للبرامج والأدوات الخبيثة بالمرور إذا اختفت القواعد فجأة. لكنّ الجانب المظلم في هذا التوجّه هو أنّ خدماتك ستصبح فورًا غير متوفّرة لمستخدميك إلى حين أن تقوم بإعادة تعيين قواعد الوصول مجددًا. يمكن أحيانًا أن تقوم بقفل الباب على نفسك وأنت في خارج الخادوم، الأمر سيّئ خاصّة إذا لم تكن تقدر على الوصول "فيزيائيا" إلى الخادوم أو وسيلةً أخرى للاتصال به (خواديم DigitalOcean قابلة للوصول دومًا بغضّ النظر عن إعدادات الشبكة عبر استخدام زرّ "Console Access" الموجود في قسم "Access" من لوحة التحكّم الخاصّة بالخادوم). إذا كنت أنت من يريد إعادة تعيين القواعد ومسحها بشكلٍ مقصود، فيمكنك ببساطة تجنّب هذه المشكلة عبر تغيير السياسة الافتراضية إلى "Accept" (قبول) مباشرةً قبل إعادة تعيين ومسح القواعد. الخيار البديل لما سبق هو تعيين السياسة الافتراضية الخاصّة بك إلى "Accept" (قبول) مع تضمين قاعدة "drop" (ترك) في النهاية مع القواعد الأخرى. يمكنك إضافة قاعدة عادية في نهاية قائمة القواعد الخاصّة بك تقوم بمطابقة ومنع كلّ التدفّق الباقي الغير مُطابق. في هذه الحالة، إذا تمّ إعادة تعيين قواعد الجدار الناري الخاصّة بك، فإنّ خدماتك ستكون قابلة الوصول ولكن غير محمية. اعتمادًا على خياراتك للوصول المحلّي أو البديل، يمكن أن يكون هذا شرًّا ضروريًا لكي تضمن أنّك قادر على الوصول إلى خادومك مجددًا في حال مُسحت قواعد الجدار الناري. إذا قررت استخدام هذا الخيار، فيجب أن تضمن أنّ قاعدة "drop" (ترك) التدفّق الغير مطابق هي دومًا آخر قاعدة في قائمة قواعد الجدار الناري. ترك التدفق مقابل رفضه هناك بضع طرق مختلفة لمنع حزمة بيانات (packet) من المرور إلى الوجهة التي تريدها. الاختيار المختلف لواحدٍ من هذه الطرق سيؤثر على الطريقة التي يقوم المستخدمون من خلالها بمحاولة الاتصال بالخادوم وسرعة إدراكهم أنّه لن يتم خدمة طلبهم الذي أرسلوه مسبقًا. الطريقة الأولى التي يمكن من خلالها منع حِزَم البيانات هي عبر "drop" (ترك) التدفّق. يمكن أن يتم استخدام الـ "ترك (drop)" كسياسة افتراضية أو ضمن قواعد الجدار الناري. عندما يتم ترك حزمة بيانات، يقوم iptables ببساطة برميها بعيدًا، حيث لا يقوم بإرسال أيّ رد إلى العميل الذي يحاول الاتصال ولا يقوم حتّى بإرجاع ردّ أنّه قد استلم الطلب بنجاح أم لا. هذا يعني أنّ العملاء لن يعرفوا ما إذا كان الخادوم قد وصله طلبهم أساسًا أم لا. لمحاولات الاتصال عبر بروتوكول TCP، سيتم الحفاظ على الاتصال إلى حين انقضاء مهلته (timeout). بما أنّ بروتوكول UDP هو بروتوكول غير اعتمادي على الاتصال (connectionless)، فإنّ عدم توفّر الردّ للعملاء يصبح أكثر إيهامًا. في الواقع، غالبًا ما يكون عدم تلقّي ردّ في هذه الحالة دليلًا على أنّ حزمة البيانات قد قُبلت. إذا كان عميل UDP يهتم بالجهة التي يرسل الحِزَم إليها، فسيقوم بإرسالها مجددًا لكي يتحقق مما إذا تمّ قبولها أو فقدانها أو رفضها. قد يزيد هذا من الوقت الذي يجب على البرمجيات والشفرات الخبيثة استغراقه للحصول على معلوماتٍ صحيحة عن حالة المنافذ في خادومك، لكنّه قد يسبب أيضًا مشكلة للتدفّق العادي. الخيار البديل هنا هو ببساطة رفض حزم البيانات التي لا تريدها بشكلٍ استثنائي. ICMP أو بروتوكول رسائل التحكّم بالإنترنت (Internet Control Message Protocol) هو عبارة عن بروتوكول وصفي (meta-protocol) يستعمل عبر الإنترنت لإرسال الحالة ومعلومات مواجهة الأعطال ورسائل الخطأ بين المضيفين (hosts) ضمن قناة لا تعتمد على اتصالات البروتوكولات التقليدية مثل TCP وUDP. عندما تقوم بـ "رفض" شيءٍ ما، فإنّ التدفّق سيتم منعه وسيتم إعادة حزمة ICMP إلى المُرسِل لإعلامه أنّ البيانات التي أرسلها قد تمّ استلامها إلّا أنّه قد تمّ رفضها. يمكن لرسالة الحالة أن تشير إلى السبب أيضًا. توجد العديد من العواقب لهذا، بافتراض أنّ تدفّق ICMP قادر على الرجوع إلى العميل، فإنّه سيتم إخطاره مباشرةً أنّ التدفّق الخاص به محظور. للعملاء العاديين، سيعني هذا أنّه يجب عليهم الاتصال بمدير الخادوم للاستفسار عن السبب أو التحقق من خيارات اتصالاتهم للتأكّد من أنّهم يتصلون عبر المنفذ الصحيح. أمّا بالنسبة للمستخدمين السيئين والذين يحاولون اختراق الخادوم، فإنّ هذا يعني أنّه يمكنهم إكمال عمليات بحثهم عن المنافذ المفتوحة والمغلقة والمُرشّحة في وقتٍ أقصر. هناك الكثير من الأمور التي يجب أخذها بعين الاعتبار عندما تقرر قبول أو رفض تدفّق البيانات. من بينها معرفة أنّ غالب تدفّق البيانات الخبيث الذي يتم إرساله بواسطة المخترقين يتم إرساله في الواقع عبر سكربتات وبرامج مؤتمتة، وبما أنّها ليست حساسة للوقت، فإنّ ترك التدفّق العادي لن يكون مفضلًا حيث أنّه سيؤثر على المستخدمين العاديين للخادوم. يمكنك قراءة المزيد عن هذا من هنا. جدول المقارنة بين ترك الطلب ورفضه يظهر الجدول أدناه كيفية حماية خادوم بواسطة جدارٍ ناريّ، حيث سيقوم بالاستجابة إلى طلباتٍ مختلفة بناءًا على السياسة التي يتم تطبيقها على منافذ معيّنة. يحدد العمود الأول نوع حزمة البيانات التي يتم إرسالها بواسطة العميل، بينما في الثاني، نقوم بذكر أمر nmap الذي سنستخدمه لاختبار كلّ سيناريو. يحدد العمود الثالث سياسة المنفذ المتبّعة على المنفذ، بينما الرابع يحدد الرد الذي سيتم إرجاعه إلى من طرف الخادوم. والخامس، هو ما يمكن للعميل أن يفهمه بناءًا على الرد الذي تلقاه. ترجمة -وبتصرّف- لـلمقال: How To Choose an Effective Firewall Policy to Secure your Servers لصاحبه Justin Ellingwood.
  3. واحدة من أسهل الطرق لزيادة استجابة خادومك وجعله قويًا ضدّ أخطاء الذاكرة التي قد تطرأ على تطبيقاتك التي تشغّلها عليه هي عبر إضافة مساحة Swap. Swap هي مساحة من القرص الصلب يتم تعريفها على أنّها مكان يمكن لنظام التشغيل تخزين البيانات فيها مؤقتًا في حال عدم توفّر مكان لذلك على الذاكرة العشوائية (RAM). يعطيك هذا القدرة على زيادة كميّة المعلومات التي يمكن لخادومك الاحتفاظ بها في "ذاكرته" ريثما يعمل. سيتم استخدام المساحة من على القرص الصلب مؤقتًا عندما لا يكون هناك مساحة كافية في الذاكرة العشوائية لحفظ البيانات. المعلومات التي يتم كتابتها على القرص الصلب ستكون أبطء في الاستجابة من تلك الموجودة في الذاكرة العشوائية، ولكنّ نظام التشغيل سيفضّل الإبقاء على بيانات التطبيق العامِلة حاليًا في الذاكرة العشوائية مع استخدام قرص Swap للبيانات الأقدم. بشكلٍ عام، يعتبر امتلاك قرص Swap صمّام أمانٍ فاصل يتم استعماله تلقائيًا عند نضوب الذاكرة العشوائية من خادومك. في هذا الدرس، سنشرح كيفية إنشاء وتمكين ملفّ swap على توزيعة Ubuntu 14.04. ملاحظة: على الرغم من أنّ قرص Swap مستحسن للأنظمة التي تستخدم الأقراص الصلبة التقليدية، إلّا أنّ استخدام Swap مع أقراص SSD يمكن أن يسبب مشاكل وتهتّكًا للعتاد مع مرور الوقت. القيام بذلك قد يؤثر على بنية العتاد التحتية التي توفّر الخدمة لك ولجيرانك. إذا كنت تحتاج تحسين أداء خادومك، فإننا ننصحك بترقيته. سيوفّر لك هذا نتائج أفضل بما يتعلّق بالأداء وسيقلّص من احتمالية حصول مشاكل مع العتاد. التحقق من معلومات Swap على النظام قبل أن نبدأ، سنأخذ جولةً على نظام التشغيل الخاصّ بنا لنرى ما إذا كنّا نمتلك بالفعل قرص Swap أم لا. يمكننا امتلاك أكثر من قرص أو ملفّ Swap واحد، ولكن بشكلٍ عام، يجب أن يكون واحد منها كافيًا فقط. يمكننا رؤية ما إذا كان النظام يمتلك أيّ ملفّات Swap مُعدّة مسبقًا عبر كتابة: sudo swapon -s Filename Type Size Used Priority إذا رأيت فقط ترويسة الجدول، كما رأينا أعلاه، فهذا يعني أنّك لا تمتلك حاليًا أيّ قرص Swap على النظام. طريقة أخرى للتحقق من مساحة swap هي عبر استخدام الأداة free، والتي تقوم بإظهار استخدام الذاكرة الحالي لنا. يمكننا رؤية نسبة استخدام الذاكرة الحالية و swap محسوبةً بالميغابايت عبر كتابة: free -m total used free shared buffers cached Mem: 3953 154 3799 0 8 83 -/+ buffers/cache: 62 3890 Swap: 0 0 0 كما يمكنك أن ترى، مساحة Swap على نظامنا هي 0. وهذا مطابقٌ لما رأيناه في الأمر السابق. التحقق من المساحة المتوفرة على القرص الصلب الطريقة النموذجية لتخصيص المساحة لـ Swap هي عبر استخدام (partition) قسم من القرص الصلب له، ولكنّ التعديل على التقسيم الافتراضي للقرص الصلب ليس دومًا ممكنًا. يمكننا ببساطة إنشاء ملفّ swap عادي ليعمل على قسمٍ موجودٍ بالفعل. قبل أن نقوم بهذا، يجب أن نعرف حجم المساحة الحرّة المتوفّرة على القرص الصلب. يمكننا الحصول على هذه المعلومات عبر كتابة: df -h Filesystem Size Used Avail Use% Mounted on /dev/vda 59G 1.3G 55G 3% / none 4.0K 0 4.0K 0% /sys/fs/cgroup udev 2.0G 12K 2.0G 1% /dev tmpfs 396M 312K 396M 1% /run none 5.0M 0 5.0M 0% /run/lock none 2.0G 0 2.0G 0% /run/shm none 100M 0 100M 0% /run/user كما يمكنك أن ترى في السطر الأول، يمتلك القرص الصلب الخاصّ بنا حوالي 55 جيجابايت من المساحة المتوفّرة، لذا فإنّه يوجد لدينا مساحة كبيرة لاستغلالها. هذا طبعًا على خادوم افتراضي خاصّ جديد بحجمٍ متوسّط، قد يكون خادومك مختلفًا تبعًا لاستخداماتك. على الرغم من أنّه يوجد العديد من الآراء حول الحجم المناسب لملفّ swap، إلّا أنّه يعتمد في الواقع على رغبتك واحتياجات تطبيقاتك. بشكلٍ عام، من المنصوح أن تجعل حجم swap مساويًا أو مضاعفًا لحجم الذاكرة العشوائية (RAM) المتوفّرة على خادومك. بما أنّ خادومنا يحتوي 4 جيجابايت من الذاكرة العشوائية هنا، وبما أنّ ضعف هذا الرقم سيعطينا ملفّ swap كبير جدًا لن نحتاج بتاتًا لاستخدامه كلّه أو حتّى نصفه، فسنقوم فقط باستخدام 4 جيجابايت من المساحة لملفّ swap. إنشاء ملف Swap الآن وبعد أن عرفنا المساحة المتوفّرة على القرص الصلب الخاصّ بنا، يمكننا المضي قدمًا في إنشاء ملفّ swap على نظام الملفّات الخاصّ بنا. سنقوم بإنشاء ملفّ يدعى swapfile ضمن المسار الجذر (/). يجب أن يكون حجم الملفّ مساويًا لحجم المساحة التي نريد تخصيصها لـ Swap، وهناك طريقتان للقيام بالعملية: الطريقة التقليدية البطيئة يمكننا إنشاء ملفّ جديد بحجمٍ معيّن عبر استخدام الأمر dd. تقوم هذه الأداة متعددة الاستخدامات بكتابة البيانات من موقعٍ إلى آخر. يمكننا أن نستعمل هذه الأداة للقيام بكتابة أصفار إلى ملفّ من جهازٍ خاص في أنظمة لينكس موجود في المسار dev/zero/، يقوم هذا الجهاز فقط بطباعة عددٍ من الأصفار حسب ما يُطلبُ منه. نقوم بتحديد حجم الملفّ عبر استخدام bs لحجم الكتلة الواحدة (block size) وcount لعدد الكتل (blocks) التي نريد إنشاءها. يمكننا إسناد أيّ قيمة إلى كِلا المُعامِلين، ولكن ما يهم حقًا هو نتيجتهما معًا. كمثال، في حالتنا نريد إنشاء ملف بحجم 4 جيجابايت. يمكننا القيام بهذا عبر تحديد حجم الكتلة الواحدة بـ 1 جيجابايت وبتحديد عدد الكتل إلى 4: sudo dd if=/dev/zero of=/swapfile bs=1G count=4 4+0 records in 4+0 records out 4294967296 bytes (4.3 GB) copied, 18.6227 s, 231 MB/s تحقق من الأمر الذي تريد إدخاله قبل الضغط على زرّ Enter، لأنّ هذا الأمر يمكن أن يقوم بمسح بياناتك في حال قمت بتوجيه of (والذي يرمز إلى output file أو ملف الخرج) إلى المسار الخاطئ. يمكننا أن نرى أنّه قد تمّ إنشاء الملفّ بحجم 4 جيجابايت عبر كتابة: ls -lh /swapfile -rw-r--r-- 1 root root 4.0G Apr 28 17:15 /swapfile إذا قمت بتنفيذ الأمر السابق لإنشاء ملف swap بنجاح، فقد تكون قد لاحظت أنّه أخذ وقتًا ليكتمل، في خادومنا التجريبي، سترى أنّ النظام استغرق 18 ثانية ليقوم بإنشاء الملفّ، لأنّه يجب عليه كتابة 4 جيجابايت من الأصفار إلى ملفّ على القرص الصلب. إذا كنت تريد معرفة كيفيّة إنشاء الملفّ بشكلٍ أسرع، فقم بحذف الملفّ عبر الأمر أدناه وطبّق الخطوة التالية: sudo rm /swapfile الطريقة السريعة الطريقة الأسرع لإنشاء نفس الملفّ هي عبر استخدام برنامج fallocate. يقوم هذا الأمر بإنشاء ملفّ بحجمٍ معيّن، دون الحاجة إلى كتابة أصفار مثلًا أو محتوىً آخر إليه. يمكننا إنشاء ملفّ بحجم 4 جيجابايت عبر كتابة: sudo fallocate -l 4G /swapfile ستقوم الطرفية بالرجوع إليك في نفس اللحظة تقريبًا. يمكننا التحقق مما إذا كان حجم الملفّ صحيحًا أم لا عبر كتابة الأمر: ls -lh /swapfile -rw-r--r-- 1 root root 4.0G Apr 28 17:19 /swapfile وكما ترى، تمّ إنشاء ملفّ Swap الخاصّ بنا بالمساحة المطلوبة بشكلٍ صحيح. تفعيل ملف Swap الآن تمّ إنشاء الملفّ، ولكنّ النظام لا يعرف أنّه من المفترض به أن يستخدمه بعد. يجب أن نقوم بإخبار النظام بأن يقوم بتهيئة هذا الملفّ كقرص Swap ومن ثمّ تفعيله. ولكن قبل أن نقوم بهذا، علينا ضبط صلاحيات الملفّ بحيث لا يكون قابلًا للقراءة لأيّ أحد باستثناء المستخدم الجذر (root). السماح للمستخدمين الآخرين بقراءة أو كتابة محتويات هذا الملفّ قد يكون خطرًا أمنيًا كبيرًا. يمكننا قفل هذه الصلاحيات عبر كتابة: sudo chmod 600 /swapfile تحقق الآن من أنّ الملفّ يمتلك الصلاحيات الصحيحة عبر تطبيق: ls -lh /swapfile -rw------- 1 root root 4.0G Apr 28 17:19 /swapfile كما نرى، فقط المستخدم الجذر يمتلك صلاحيات الكتابة والقراءة حاليًا. الآن وبعد أن أصبح ملفّنا أكثر أمانًا، يمكننا أن نخبر نظامنا بأن يقوم بتهيئته كملفّ swap عبر تنفيذ: sudo mkswap /swapfile Setting up swapspace version 1, size = 4194300 KiB no label, UUID=e2f1e9cf-c0a9-4ed4-b8ab-714b8a7d6944 أصبح الملفّ الآن جاهزًا ليتم استخدامه كمساحة Swap. يمكننا تفعيله عبر الأمر: sudo swapon /swapfile يمكننا كذلك اختبار نجاح العملية أو فشلها عبر سؤال النظام الآن عمّا إذا كان يتعرّف على مساحة Swap أم لا عبر كتابة: sudo swapon -s Filename Type Size Used Priority /swapfile file 4194300 0 -1 لدينا ملفّ swap جديد هنا. يمكننا أيضًا استخدام أداة free للتأكّد مما وجدناه: free -m total used free shared buffers cached Mem: 3953 101 3851 0 5 30 -/+ buffers/cache: 66 3887 Swap: 4095 0 4095 تمّ الآن إعداد swap بنجاح، وسيقوم النظام باستخدامه عندما يحتاجه فقط. استخدام ملف Swap بشكل دائم لقد قمنا بتفعيل ملفّ Swap الآن، ولكن عندما نقوم بإعادة التشغيل، فإنّ الخادوم لن يقوم تلقائيًا بإعادة تفعيل الملفّ. يمكننا تغيير هذا عبر تعديل ملفّ fstab. قم بتعديل الملفّ بصلاحيات الجذر باستخدام محرر نصوصك المفضّل: sudo nano /etc/fstab في نهاية ملفّك، تحتاج إلى إضافة سطرٍ يخبر نظام التشغيل أن يقوم باستخدام الملفّ الذي أنشأته تلقائيًا: /swapfile none swap sw 0 0 احفظ الملفّ واخرج عندما تنتهي. اضبط إعدادات Swap الخاصة بك هناك بعض الخيارات المؤثّرة على أداء خادومك التي يمكنك ضبطها وتعديلها للحصول على أداءٍ أفضل عند التعامل مع swap. يقوم مُعامِل swappiness بإعداد معدّل تكرار النظام للقيام بعملية نقل البيانات من الذاكرة العشوائية إلى ملفّ swap، وهذه القيمة محصورة بين الـ0 والـ100 وتمثّل نسبةً مئوية. عندما تكون القيمة أقرب إلى الصفر، فإنّ النظام لن يقوم بنقل أيّ بيانات من الذاكرة العشوائية إلى swap إلّا في حال الضرورة القصوى. تذكّر أنّ التعامل مع swap "مكلف" حيث أنّه بطيء بشكلٍ ملحوظ مقارنةً بالذاكرة العشوائية مما يسبب بطئًا في الأداء. لذا فإنّ إخبار النظام بألّا يقوم بالاعتماد على swap كثيرًا سيقوم بتسريع أداء نظامك بشكلٍ عام. إذا كانت القيمة أقرب إلى المئة، فإنّ النظام سيقوم بنقل المزيد من البيانات إلى swap بهدف حفظ المزيد من الذاكرة العشوائية. اعتمادًا على ماهيّة التطبيقات التي تقوم بتشغيلها على خادومك واحتياجاتك الشخصية، قد يكون هذا الخيار أفضل لك في بعض الحالات. يمكننا أن نرى قيمة مُعامِل swappiness الحالية عبر تطبيق: cat /proc/sys/vm/swappiness 60 بالنسبة لجهاز سطح مكتب (استخدام عادي)، فإنّ قيمة 60 ليست سيئة. ولكن بالنسبة إلى خادوم، فإننا قد نود تقريب القيمة إلى الصفر. يمكننا تغيير قيمة swappiness إلى قيمة أخرى عبر استخدام الأمر sysctl. كمثال، لتغيير قيمة swappiness إلى 10، يمكننا تنفيذ: sudo sysctl vm.swappiness=10 vm.swappiness = 10 سيستمر هذا التغيير إلى حين عملية إعادة التشغيل المقبلة. يمكننا جعل هذا التغيير دائمًا حتّى بعد إعادة التشغيل عبر إضافة سطرٍ معيّن إلى نهاية ملفّ etc/sysctl.conf/: sudo nano /etc/sysctl.conf في نهاية الملفّ أضف: vm.swappiness=10 احفظ الملفّ واخرج عندما تنتهي. قيمة أخرى مرتبطة قد تودّ تغييرها هي vfs_cache_pressure. يقوم هذا المُعامِل بتحديد إلى أيّ مدى سيقوم النظام بالاحتفاظ بالخبيئة (cache) للبيانات الأكثر تكرارًا في مقابل البيانات الأخرى. تكون هذه البيانات عادةً متعلقة بنظام الملفّات نفسه، وغالبًا ما يتكرر طلبها، لذلك فإنّه من الممتاز لنظامك أن يقوم بالاحتفاظ بهذه البيانات في ذاكرته المؤقتة. يمكنك رؤية قيمة هذا المُعامِل الحالية عبر الأمر: cat /proc/sys/vm/vfs_cache_pressure 100 حاليًا، يقوم نظامنا بحذف البيانات والمعلومات من الخبيئة (cache) بسرعة سريعة جدًا. يمكننا جعل هذه العملية أكثر بطئًا عبر استخدام قيمة كـ50: sudo sysctl vm.vfs_cache_pressure=50 vm.vfs_cache_pressure = 50 مرةً أخرى.. هذه القيمة ليست دائمة حاليًا وسيتم فقدانها عند إعادة التشغيل، يمكننا تغيير هذا الوضع عبر إضافتها إلى ملفّات إعداداتنا كما فعلنا مسبقًا: sudo nano /etc/sysctl.conf في نهاية الملفّ، أضف القيمة التي تريدها: vm.vfs_cache_pressure = 50 احفظ الملفّ واخرج عندما تنتهي. الخاتمة اتبّاع الخطوات في هذا الدرس سيعطيك بعض الهواء لتتنفسه عندما يتعلّق الأمر باستخدام الذاكرة العشوائية في نظامك. مساحة Swap مفيدة بشكلٍ لا يصدّق في تفادي بعض المشاكل الشائعة. إذا كنت تصادف أخطاء (OOM (Out of memory أو عدم توفّر الذاكرة بشكلٍ شائع، أو إذا كنت ترى أنّ نظامك غير قادر على استخدام التطبيقات التي تحتاجها، فإنّ الحلّ الأفضل لك هو في ضبط إعدادات تطبيقاتك أو في ترقية موارد خادومك، كما أنّ تفعيل مساحة Swap على خادومك سيعطيه المزيد من المرونة ويوفّر لك المزيد من الوقت على خادومٍ بمواصفاتٍ عادية. ترجمة -وبتصرف- للمقال How To Add Swap on Ubuntu 14.04 لصاحبه Justin Ellingwood.
  4. الإعدادقبل أن تبدأ بالعملية، تحتاج امتلاك التالي: خادوم (خادوم افتراصي خاص - VPS) من DigitlOcean. إذا كنت لا تمتلك واحدًا، فيمكنك التسجيل وإعداد واحدٍ جديد في غضون دقائق. اسم نطاق (domain) مُسجّل بالفعل. حاليًا لا يمكنك تسجيل اسم نطاق عبر DigitalOcean، بل يجب عليك استخدام شركة أخرى.الخطوة الأولى - البحث عن المعلومات باستخدام WHOISأوّل شيء يجب عليك فعله لإعداد اسم المُضيف (hostname) الخاصّ بك هو تغيير خادوم أسماء النطاقات (domain name server) إلى خواديم أسماء النطاقات من DigitalOcean. يمكنك القيام بهذا عبر الموقع الذي قمتَ من خلاله بشراء النطاق الخاصّ بك. إذا كنت لا تتذكر من أين قمت بشرائه، فيمكنك البحث عنه عبر استخدام "WHOIS"، والذي هو عبارة عن بروتوكول يمكنه القيام بعرض معلومات موقعٍ ما، مثل عنوان الـIP وتفاصيل تسجيل النطاق. افتح سطر الأوامر واكتب: whois example.comسيقوم WHOIS بعرض جميع التفاصيل المرتبطة بالموقع، بما فيها بيانات الاتصال التقني التي تتضمن اسم الجهة التي قمت بتسجيل نطاقك عندها. الخطوة الثانية — غير خادوم أسماء النطاقات الخاص بكاذهب إلى لوحة التحكم الخاصّة بالجهة التي قمت بتسجيل النطاق عندها وابحث عن الحقول المُسماة "Domain Name Server". هذه الحقول بدت بالنسبة لي كالتالي: قم بتوجيه خادوم أسماء النطاقات الخاصّ بك إلى DigitalOcean واملأ الحقول الثّلاثة الخاصّة بخادوم أسماء النطاقات. عندما تنهي ذلك، احفظ تغييراتك واخرج. خواديم أسماء النطاقات الخاصّة بـDigitalOcean هي: ns1.digitalocean.comns2.digitalocean.comns3.digitalocean.comيمكنك أن تتحقق الآن أنّ خواديم أسماء النطاقات الجديدة قد تمّ تسجيلها عبر استخدام WHOIS مجددًا، يجب على الخرج (output) أن يتضمّن المعلومات المحدّثة: Domain Name: EXAMPLE.COM Registrar: ENOM, INC. Whois Server: whois.enom.com Referral URL: http://www.enom.com Name Server: NS1.DIGITALOCEAN.COM Name Server: NS2.DIGITALOCEAN.COM Name Server: NS3.DIGITALOCEAN.COM Status: okعلى الرغم من أنّ خواديم أسماء النطاقات مرئية عبر WHOIS، إلّا أنّ التغييرات قد تأخذ ساعة أو اثنتين ليتم تطبيقها. الخطوة الثالثة - اضبط نطاقكالآن، يجب علينا الانتقال إلى لوحة التحكّم في DigitalOcean. في قسم الشبكة أو "Networking"، انقر على "Add Domain"، وقم بإدخال اسم النطاق وعنوان IP الخادوم الذي تريد ربطه بالنطاق. ملاحظة: اسم النطاق لا يجب أن يحوي www في البداية. ستصل إلى صفحة يمكنك من خلالها إدخال جميع بيانات موقعك. لإنشاء اسم مُضيف جديد، تحتاج فقط إلى ملأ ما يُعرف بـ"A record". إذا كنت تستعمل عنوان IPv6، فيجب عليك أن تملأ حقل "AAAA record". A Records: استخدم هذا الحقل لإدخال عنوان IP الخادوم الذي تريد استضافة نطاقك عليه وعنوان اسم المُضيف نفسه، كاسمٍ مرتبط مُرافق لنطاقك الرئيسي، مثلًا: test.example.comلإتمام العملية، قم بإنشاء اسم مُضيف جديد عبر إدخال كلمة "test" في حقل "hostname". يجب أن تبدو شاشتك كالتالي: احفظ التغييرات عبر الضغط على "Add new A record". يمكنك أيضًا ربط عنوان الـIP الخاصّ بك باسم نطاق لا يحوي أيّ شيءٍ قبله (يجب أن تقوم بهذا افتراضيًا عندما تقوم بإضافة نطاق): http://example.comللحصول على هذا، أنشئ اسم مُضيف جديد مع إدخال الرمز "@" في حقل hostname. يجب أن تبدو شاشتك شيئًا كالتالي: يمكنك حفظ التغييرات عبر الضغط على مفتاح Enter. AAAA Records: استخدم هذا الحقل لإدخال عنوان IPv6 الخادوم الذي تريد استضافة نطاقك عليه وعنوان اسم المُضيف نفسه، كاسمٍ مرتبط مُرافق لنطاقك الرئيسي أو يمكنك أيضًا ربط عنوان الـIP الخاصّ بخادومك مع اسم النطاق دون أيّ شيءٍ قبله. لإتمام هذا، أنشئ اسم مُضيف جديد مع الرمز “@” في حقل hostname. يجب أن تبدو شاشتك كالتالي: احفظ التغييرات عبر الضغط على "CREATE". CNAME Records: تعمل "CNAME record" كاختصار لـ"A record"، عبر توجيه نطاقٍ فرعي إلى "A record". إذا تغيّر عنوان الـIP لـ"A record" فسيقوم "CNAME record" بالتوجيه إلى العنوان الجديد. لإضافة www إلى عنوان الويب الخاصّ بك، اضغط على "Add a new CNAME record" واملأ الحقلين الاثنين. يجب أن ترى شيئًا كالتالي: إذا كنت تحتاج أن تقوم بإعداد خادوم بريد على نطاقك، فيمكنك القيام بذلك عبر استخدام MX Records. MX Records: يجب أن يتم ملأ حقول MX Records باسم المُضيف وأولوية خادوم البريد الخاصّ بك، والتي هي عبارة عن قيمة تحدد الترتيب الذي يجب أن يتم استخدامه أثناء محاولة الوصول إلى خواديم البريد الإلكتروني. تنتهي جميع العناوين دومًا بـ"." عنوان MX Record صحيح سيبدو شيئًا كـ: mail1.example.com. أدناه تجد مثالًا على عناوين MX records مُعدّة لنطاقٍ يستخدم خواديم بريد جوجل (لاحظ النقطة في نهاية كل عنوان): إنهاء العمليةبمجرد أن تقوم بملأ جميع الحقول المطلوبة، ستأخذ معلوماتك وقتًا إلى أن يتم تحديثها. يجب أن يكون اسم النطاق الخاصّ بك جاهزًا في غضون بضع ساعات. بعد بعض الوقت، يمكنك أن تتأكد مما إذا كان اسم المُضيف الجديد قد تمّ تسجيله أم لا عبر استخدام: ping test.example.comيجب أن ترى شيئًا مثل: # ping test.example.com PING test.example.com (12.34.56.789) 56(84) bytes of data. 64 bytes from 12.34.56.789: icmp_req=1 ttl=63 time=1.47 ms 64 bytes from 12.34.56.789: icmp_req=2 ttl=63 time=0.674 msيجب أن تكون قادرًا على الوصول إلى الموقع كذلك عبر المتصفّح. ترجمة -وبتصرّف- للمقال How To Set Up a Host Name with DigitalOcean لصاحبته Etel Sverdlov.
  5. تحدثنا في السابق عن بضع خطوات يمكنك تطبيقها لزيادة أمان وحماية موقعك العامل بسكربت ووردبريس الشهير. صحيحٌ أنّ نواة ووردبريس آمنة للغاية، ولكن يجب عليك تثبيت عدّة إضافات وملحقات إضافية لزيادة مستوى أمان موقعك. سنتحدّث في هذا الدرس عن أهم إضافات الأمان والنسخ الاحتياطي التي يمكنك تثبيتها وتفعيلها على سكربت ووردبريس الشهير. لماذا قد أحتاج إضافة للحماية؟بشكلٍ عام، تقوم إضافات الحماية والأمان بتوفير طبقة إضافية من الحماية ضدّ هجمات 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.
  6. في الدرس السابق تحدثنا عن طرق تثبيت ووردبريس لأول مرة بأمان. في هذا الدرس، سنتحدّث عن كيفية تأمين موقع ووردبريس بعد تثبيته، سنتحدّث عن أساليب أفضل للحماية فوق مستوى نصائح "اختر كلمة مرور أكثر تعقيدًا" وسنحاول الغوص قليلًا في موضوع أمان ووردبريس. تقييد عمليات تسجيل الدخولواحدٌ من أول الأشياء التي يجب عليك فعلها لتأمين موقع ووردبريس الخاصّ بك هو تقييد عدد المرّات التي يمكن لشخصٍ ما أن يحاول تسجيل الدخول بها إلى الموقع. يحاول العديد من المخترقين القيام بهجمات التخمين أو ما يعرف بـ 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.phpreadme.htmllicense.txtwp-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.
  7. سنناقش في هذا الدرس أهمّية تحديث كلّ شيءٍ متعلّق بموقع ووردبريس الخاصّ بك إلى آخر الإصدارات المتوفّرة وأهميّة التحديثات بشكلٍ عام، وهو من أهمّ الأمور التي يمكنك القيام بها لزيادة حماية وأمان موقعك. لماذا نقوم بالتحديث؟السؤال الحقيقي يجب أن يكون "ولما لا"؟ يقوم مطوروا ووردبريس بإرسال التحديثات إلى المستخدمين لسببٍ معيّن في النهاية، حيث أنّ هذه التحديثات تحتوي على إصلاحاتٍ لثغراتٍ خطيرة يمكن أن يستغلها المهاجمون لمهاجمة موقعك، مما يجعل التحديث ضرورة لا مفرّ منها. تحديثات سكربت ووردبريس مهمّة بنفس أهمّية تحديثات أنظمة التشغيل والتطبيقات الأخرى، يتم دومًا اكتشاف ثغراتٍ جديدة في البرمجيات كلّ فترة، ويتم مع ذلك إرسال ترقيعاتٍ جديدة لترقيع هذه الثغرات كلّ فترة إلى أجهزة المستخدمين، مما يجعل التطبيق أكثر أمنًا" - Ken Westin الخبير الأمن في Tripwire, Inc. أنواع التحديثاتقبل أن نتابع، من المهمّ أن نفهم أنواع التحديثات المختلفة المتوفّرة في سكربت ووردبريس. يشير Tony Perez في تدوينة حديثة إلى أنّه هناك 3 أنواع مختلفة من التحديثات: تحديثات الأمان، الترقيعات والإصدارات الرئيسية. تحديثات الأمان هي بالضبط كما تبدو عليه من اسمها. يتم إصدارها بسرعة وتحتوي فقط على بضع إصلاحاتٍ لثغراتٍ موجودة تم اكتشافها مؤخرًا. تكون هذه التحديثات عادةً على شاكلة أرقام الإصدارات مثل 4.2.1. تحديثات الترقيعات أكبر قليلًا، لا تحتوي هي الأخرى على مميزاتٍ جديدة، ولكنّها تقوم بتحديث النظام وعادةً ما تتضمن تحديثاتٍ أمنية كذلك، كما أنّه يتم إصدارها بصفة دورية ومن الممكن توقّع وقت صدور الترقيع الجديد. وأمّا عن التحديثات الرئيسية من الانتقال من الإصدار 3.9 إلى الإصدار 4.0 فهذا تحديثٌ جوهري، يحتوي مميزاتٍ جديدة وإصلاحاتٍ للمشاكل الأمنية المعروفة بالإضافة لأمورٍ أخرى، كما أنّه يتم التدوين عنها في مدونة ووردبريس وفي العديد من المواقع الإخبارية الأخرى، حيث أنّها تحديثات كبيرة ويجب على الجميع معرفتها. قد تقوم هذه التحديثات أحيانًا بتحطيم شكل موقعك بسبب عدم توافقية مع القالب الذي تستخدمه مثلًا، ولكن مع وجود نسخة احتياطية من موقعك، فيجب ألّا تكون مشكلةً بالنسبة لك. الفشل بالتحديث يعني مشكلة أعظم كما ذكرنا سابقًا، عدم قيامك / فشلك بتحديث أيّ إضافات أو قوالب ووردبريس مثبّتة على موقعك قد يعرّضك لخطرٍ كبير، وما قد لا تفهمه هو "لماذا"؟ بمجرّد أن يتوفّر ترقيعٌ معيّن كتحديث، يتزايد الخطر على المستخدمين الذين لم يقوموا بالتحديث بصورةٍ كبيرة، لأنّ المخترقين سيكونون قادرين على قراءة الشفرة المصدرية للترقيع ومعرفة الثغرة الحقيقية وبالتالي يمكنهم استغلالها ضدّ مواقع ووردبريس التي لم تقم بالتحديث والترقيع. هناك فترة زمنية قصيرة ما بين توفّر الترقيع كتحديث لووردبريس وما بين قيام المُخترقين بالبدء باستغلال هذه الثغرة على مواقع ووردبريس التي لم تقم بالترقيع، وهذا هو الوقت الذي يجب على المستخدمين الانتباه إليه، حيث أنّ مجرّد الانتظار إهمالًا يتركك عرضةً لهجماتٍ أكثر - Ken Westin. يمكن قول نفس الأمر بخصوص القوالب والإضافات، صحيحٌ أنّها ليست جزءً من لبّ نواة ووردبريس، ولكنّها أيضًا قد تحتوي على ثغرات تمكّن المخترقين من استغلالها لاختراق موقعك، وأيضًا يتم اكتشاف هذه الثغرات كلّ فترة وتصدر تحديثات لترقيعها كلّ فترة، وعليك تثبيتها بمجرّد توفّرها. بعض السمات والقوالب تكون مبرمجة بصورة سيئة ويكون بها العديد من الثغرات ويجب عليك الانتباه إلى ذلك، كما يجب عليك تثبيت واستخدام القوالب والإضافات التي تستعملها فقط وحذف كلّ شيء لا تستعمله. إدارة تحديثات ووردبريسأفضل طريقة للتأكّد من أنّ كلّ شيء على موقعك محدّث هو جعل عملية التحقق من وجود تحديثات متوفّرة هي مهمّة روتينية أخرى على جدولك (لو لم تكن تقنيًا، فيجب عليك البحث عن استضافة تقوم تلقائيًا بتحديث جميع القوالب والإضافات والنواة الخاصّة بووردبريس)، يجب عليك التحقق من توفّر التحديثات بنفسك كلّ يوم لتجنّب أي مشاكل أمنية قد تحصل. منذ الإصدار 3.7 من ووردبريس فإنّ المنصة تسمح بالتحديث التلقائي بسهولة، بمجرّد تفعيل هذا الخيار، فإنّه هذا يعني أنّ نواة موقعك ستقوم بالتحديث تلقائيًا عند توفّر تحديثات جديدة بدون أيّ تدخّل منك. طبعًا لا يمكن فعل نفس الشيء بالنسبة للقوالب والإضافات، حيث يجب عليك القيام بتحديثها يدويًا. الخاتمةتحديثات ووردبريس مهمّة للغاية، بل ومهمّة جدًا، ومن واجبك الاهتمام بتحديث كلّ شيءٍ موجود على موقعك إلى الإصدارات الأخيرة المتوفّرة، وإلّا فإنك تترك بابك مفتوحًا للمخترقين ليخترقوك، إنّها مسألة وقت. ترجمة -وبتصرف- للمقال: The WordPress Developer’s Guide to Security: Updates لصاحبه: Brenda Barron.
  8. من المهم لمطورّي ووردبريس أن يكونوا على اطّلاعٍ على تقنيات الحماية والأمان عند تطوير مواقع تعمل بسكربت ووردبريس أو تصميم قوالب جاهزة له، سنبدأ سلسلة من 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.
  9. عند الاتصال بخادوم ويب أو تطبيق، يتم الردّ على كلّ طلب 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.
  10. ما هي 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.
  11. بعد أن قمنا مسبقًا بتثبيت وإعداد خادوم قاعدة بيانات 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.
  12. تأتي 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.
  13. 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.
  14. تصميم تجربة المستخدم ليس هو نفس الشيء عندما تقارنه بتصميم واجهات الاستخدام. تجربة المستخدمين تحصل وراء الشاشات وبين الفجوات. كمصممي ويب وواجهات استخدام محمولة فإنّ عملنا يتركّز في بناء واجهاتٍ أنيقة. واجهاتٍ تكون عناصر أساسية في تجربة المستخدم. واجهات تسمح للمستخدمين بأن يحصلوا على أجوبة لأسئلتهم أو إكمال مهام أساسية بالنسبة لهم. عملنا هو أن نساعدهم في تحقيق أهدافهم. لكن إيّاك أن تخطئ وتعتقد أنّ هذه التفاعلات هي كلّ شيءٍ عن تجربة المستخدم. تجربة المستخدمين الرائعة تحصل دومًا خلف الشاشات وفي الفجوات. الفجوات التي تقع بين القنوات، الأجهزة وشركات الأعمال. تحصل تلك التجربة دومًا عندما تقوم المنظّمات بالاهتمام بالتفاصيل الدقيقة لتفاعلاتها مع العملاء. بسبب أنّ تصميم تجربة المستخدم يتعلّق بأكثر من أمر فإنّه من الصعب وصفه عادةً. لذا عوضًا عن ذلك، دعني أعطيك بعض الأمثلة على تفاعلاتٍ تساعد على إنشاء تجربة أفضل للمستخدمين. تفادي إزعاج دعم الهواتفتطبيق 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.
  15. 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.