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

سوف نعرفّك في هذا المقال على إعدادات رفع الوسائط في ووردبريس التي تسمح لك بتعديل أبعاد ملفات الوسائط وتنظيمها عند إضافتها لموقعك الإلكتروني، كما سنشرح أيضًا عمل كل خيار وآلية استخدامه لتحقيق أقصى استفادة من ووردبريس. بعد ذلك سوف نشرح الخيارات المتوفرة في صفحة إعدادات القراءة في ووردبريس، حيث تسمح لك هذه الخيارات بتخصيص أي صفحة تُعرض للزوار على أنها الصفحة الرئيسية للموقع، إضافةً إلى خيارات أخرى تُساعدك على عرض محتواك بأفضل طريقة. كيفية ضبط إعدادات وسائط ووردبريس يُعَد ووردبريس منصةً عالية المرونة، حيث تستطيع تخصيصها لتناسب احتياجاتك، ولكن سهولة التنقل ومرونة العمل تعني المزيد من القوائم والخيارات التي عليك التعامل معها، حيث تبدو إعدادات رفع وسائط ووردبريس مثلًا، مُربكةً للوهلة الأولى، خصوصًا عندما تكون منصات إدارة المحتوى جديدةً بالنسبة لك، لكن لا داعي للقلق فإن عمل هذه الخيارات والوصول لها ليس أمرًا صعبًا. مقدمة عن إعدادات رفع وسائط ووردبريس تتحكم الخيارات الموجودة في صفحة إعدادات الوسائط في ووردبريس، بجوانب مختلفة مرتبطة بالصور وملفات الوسائط التي تُستخدم ضمن صفحات ومقالات موقعك الإلكتروني، وتستطيع الوصول لهذه الإعدادات من خلال القائمة الجانبية في لوحة تحكم ووردبريس والضغط على "وسائط" في قسم "إعدادات". توجد مجموعة صغيرة من الخيارات في هذه النافذة، ولكنها تمتلك تأثيرًا كبيرًا على طريقة عرض الوسائط في موقعك، كما أنها تؤثر على حجم مساحة التخزين التي تشغلها والتي تُعَد مهمةً للعديد من أصحاب المواقع. من المهم أن تعلم أنّ ووردبريس يُنشئ تلقائيُا ثلاث نسخ من كل صورة ترفعها، وذلك بأحجام مختلفة هي حجم صورة مصغرة ومتوسط وكبير، لتصبح عملية تغيير حجم الصورة أسهل، كما أنّ هذه الأحجام المتنوعة تُستخدم في أماكن مختلفة ضمن قوالب ووردبريس، حيث يُستخدم حجم الصورة المصغرة للصور بالعادة مثلًا في الصفحة الرئيسية للمدونة، وذلك لعرض الصورة البارزة لكل مقال. من ناحية أخرى سوف تستخدم الصور ذات الحجم الكبير في الشريط المُنزلق أو القسم الأول من الصفحة. تتحكم إعدادات هذه الصفحة بالأبعاد الفعلية للأحجام المذكورة سابقًا للصور، ويوجد خيار لتحديد عدد الصور المحفوظة ضمن نظام ملفات ووردبريس، وهذا يُسهل البحث عن الصور أو يجعله أصعب تبعًا لخيارك. ضبط إعدادات وسائط ووردبريس لقد أصبحت قادرًا الآن على شرح عمل الخيارات الموجودة في هذه الصفحة بعد المقدمة السابقة، لكننا سنعرج على الخيارات حسب ترتيب ورودها مع ذكر توصيات لكيفية ضبط كل خيار، لكن تذكَّر ضرورة حفظ التغييرات عند كل عملية تعديل على الإعدادات ضمن هذه الصفحة. إعدادات حجم الصورة يتضمن القسم الأول من هذه الصفحة إعدادات أحجام الصور الثلاث التي يُولدها ووردبريس تلقائيًا عند رفع أي صورة (مُصغرة أو متوسط أو كبير)، حيث تستطيع تغيير قياسات كل حجم على حدى، فإذا وجدت أن حجم الصورة المصغرة مناسب ولكن يجب تغيير حجم الصورة المتوسط والكبير مثلًا، فهذا ممكن دون أي تأثير على حجم الصورة المصغرة. تستطيع إيقاف ووردبريس عن توليد هذه النسخ لكل صورة ترفعها بوضع القيمة "0" للأبعاد، وهذا مفيد للحفاظ على مساحة التخزين ضمن الخادم أو لمن لا يحتاج لهذه الميزة إطلاقًا، حيث يوّلد ووردبريس هذه النسخ افتراضيًا عن كل صورة ترفعها سواءً استخدمتها أم لا، ولذلك فلا حاجة لملء مساحة التخزين في استضافتك إن لم تكن تنوي الاستفادة من هذه الخاصية، كما أنّ الإبقاء على عدد كبير من الصور وملفات الوسائط يؤثر سلبًا على أداء الموقع. يوجد خيار إضافي لحجم الصورة المُصغرة وهو "إقطع الصورة المصغرة لتتلاءم مع الأبعاد (العرض والطول) بالضبط". تكون الصورة المُصغرة عادةً ذات أبعاد متساوية، ولكن عند تفعيل هذا الخيار تستطيع ضبطها للحصول على شكل مستطيل. يرتبط استخدام هذا الخيار بتصميم الموقع، لذلك لا توجد توصية محددة لاستخدامه، ومع ذلك فعليك الانتباه إلى أنّ بعض قوالب ووردبريس تقتطع الصور المُصغرة لمربعات بغض النظر عن الحجم الذي اخترته هنا، لذا فعليك التجريب للتأكد من أي خيار هو الأفضل لك؛ أما بخصوص سؤال "ما هي الأبعاد المثالية؟"، فلا توجد قاعدة سريعة وعامة، وفي معظم الحالات تُناسب الأحجام الافتراضية موقعك ولكن الحجم الأكبر يوفر جودة صورة أفضل، خصوصًا عند تكبير المستخدم للصفحة لتفحص التفاصيل، ولكنها أيضًا تتطلب المزيد من مساحة التخزين. لذلك عليك الموازنة بين إيجابيات استخدام الحجم الأكبر وسلبياته لاختيار الأفضل لموقعك. خيارات رفع الملفات يتضمن القسم الأخير من صفحة إعدادات وسائط ووردبريس خيارًا وحيدًا فقط هو "تنظيم الملفات المرفوعة في مجلدات، وذلك بالإعتماد على التاريخ"، ولكنه خيار مهم يُسهل إيجاد الملفات المرفوعة على موقعك، وذلك اعتمادًا على تاريخ الرفع. سوف يُنشئ ووردبريس عند تفعيل هذا الخيار مجلدات بالاعتماد على العام والشهر الذي رُفعت فيه الملفات. يُسهل هذا النظام عملية البحث عن ملف محُدد، ولكن عند إلغاء تفعيل هذا الخيار فسوف تُضاف جميع الملفات المرفوعة إلى مجلد uploads ضمن مسار تثبيت ووردبريس، وذلك دون أي تنظيم أو تصنيف، لذلك يُنصح بتفعيل هذا الخيار سواءً كنت تمتلك عددًا صغيرً أو كبيرًا من الصور. كيفية ضبط إعدادات القراءة في ووردبريس توجد العديد من إعدادات القراءة في لوحة تحكم ووردبريس التي تستطيع ضبطها، بحيث يحدد البعض منها طريقة ظهور الموقع للزوار ومحركات البحث. مقدمة لصفحة إعدادات القراءة في ووردبريس تُحدد الخيارات في صفحة إعدادات القراءة في ووردبريس تجربة المستخدم عند زيارته لموقعك أو تفاعله مع محتواه. تتحكم هذه الخيارات ببضع وظائف رئيسية في ووردبريس، مثل اختيار أي صفحة من الموقع لتكون الصفحة الرئيسية له، كما أنها تتحكم بعدد المنشورات التي تُعرض في صفحة المدونة، حيث تسمح لك بتعديل عدد المنشورات المُضّمنة في خلاصة الموقع RSS. تتضمن هذه الصفحة أيضًا خيارًا للسماح أو عدم السماح لمحركات البحث بفهرسة الموقع، وستجد جميع الخيارات السابقة في تبويب "قراءة" ضمن قسم "الإعدادات" في لوحة تحكم ووردبريس. كيفية ضبط إعدادات القراءة في ووردبريس لقد أصبح الوقت مناسبًا لتفحص الصفحة عن كثب بعد أن تعلمت كيف تصل لها، حيث ستتعلم في هذا القسم وظيفة كل خيار ضمن هذه الصفحة والاستخدام الأفضل له لتحسين أداء موقع ووردبريس الخاص بك، وبطبيعة الحال تذكر أنّ عليك حفظ التغييرات قبل مغادرة هذه الصفحة وإلا فلن تُحفظ تعديلاتك. إعدادات الصفحة الرئيسية يُعيّن القسم الأول من صفحة إعدادات القراءة المحتوى المعروض على الصفحة الرئيسية للموقع حيث يوجد خياران فقط هما: آخر مقالاتك صفحة ثابتة سوف تكون الصفحة الرئيسية عبارةً عن قائمة مرتبة مكونة من منشوراتك الأخيرة عند اختيارك الخيار الأول "آخر المقالات"، حيث تظهر هذه الصفحة للمستخدمين عند زيارتهم رابط موقعك الرئيسي. www.yourwebsite.com أو تستطيع اختيار "صفحة ثابتة"، بعد ذلك عليك اختيار أي صفحة من الموقع لتكون هي الصفحة الرئيسية. عند اختيارك لهذا الخيار فستستطيع تعيين صفحة لمنشورات المدونة كي تتمكن من إضافتها لقائمة موقعك. يظهر من الصورة السابقة اختيارين لصفحة اسمها "الرئيسية" لتكون الصفحة الرئيسية للموقع، حيث لم نختر صفحة المقالات كما يتضّح، والسبب في ذلك أن الموقع هو عبارة عن موقع إخباري، حيث صُممت الصفحة الرئيسية فيه لتعرض المنشورات بتصميم جذاب، لذلك فأنت لست بحاجة لصفحة المقالات، بل عليك إضافة الصفحات التي تريد استخدامها لتكون صفحةً رئيسية وأخرى لتكون صفحة المقالات، وذلك قبل ضبط هذه الإعدادات والسبب يعود إلى أنّ هذه الصفحات لن تظهر في القوائم المنسدلة السابقة ما لم تكن مُضافةً مسبقًا. تعتمد الإعدادات الأمثل للخيارات السابقة على الهدف من موقعك، فمثلًا إن كانت مدونتك هي غايتك الرئيسية، فإن عرض آخر المقالات يُعَد خيارًا مناسبًا لك، لكن إذا كانت المدونة جزءًا صغيرًا من موقع تجاري أكبر، فعندها عليك اختيار "صفحة ثابتة" للصفحة الرئيسية لتتمكن من التعريف بالشركة ومنتجاتها وخدماتها أولًا. إعدادات المدونة يُعين القسم التالي من صفحة إعدادات القراءة في ووردبريس عدد المنشورات التي يعرضها نظام إدارة المحتوى قبل أن يُضطر المستخدم للانتقال لصفحة جديدة. الخيار الافتراضي هو 10 وهو خيار جيد، ولكنك تستطيع استخدام عدد أقل إن كنت تريد عرض محتوى أكبر ضمن مقتطف المقال، أو في حال كان زمن تحميل الصفحة مرتفعًا، وهو في الحقيقة أمر هام جدًا لأخذخ بالحسبان عند ضبط هذا الخيار، فكلما زاد عدد المنشورات التي تريد عرضها ضمن الصفحة، زاد زمن تحميل الصفحة. ولذلك لا ننصح بتجاوز القيمة الافتراضية "10". يرتبط هذا الخيار أيضًا بتجربة المستخدم، فعدد كبير من المنشورات ضمن الصفحة الواحدة يعني أن على المستخدم قضاء وقت أطول للوصول لنهاية الصفحة، بينما عدد قليل جدًا من المنشورات يعني أن على المستخدم التنقل كثيرًا بين الصفحات ليصل للمطلوب. تُساعدك التجربة على الوصول للخيار الأمثل بالنسبة لموقعك، بحيث توازن بين تجربة المستخدم وأداء الصفحة من حيث زمن تحميلها. إعدادات خلاصة الموقع يتحكم الخيار التالي بعدد المنشورات المُضمنة في خلاصة الموقع والذي يستطيع المستخدمون الاشتراك به للوصول لقائمة مرتبة تحتوي على المقالات المنشورة من موقعك، فعندما تُضيف محتوى جديدًا لموقعك، فستُحدّث التغذية تلقائيًا لتُبقي القُراء على اطلاع بكل جديد. إعدادات الظهور لمحركات البحث يُعَد الخيار الأخير ضمن صفحة إعدادات القراءة في ووردبريس، عبارة عن مربع اختيار بسيط لـ "منع محركات البحث من أرشفة هذا الموقع"، ويمتلك وظيفتين أولاهما هي إضافة سطر شيفرة برمجية لكل صفحة على موقعك، لتُخبر محركات البحث بأن لا تُفهرس صفحات الموقع؛ أما الثانية فهي تعديل ملف الروبوت الذي يُستخدم مثل مرجعِ من قِبل محركات البحث، وفي هذه الحالة سوف يطلب من محركات البحث أن لا تزحف أو تُفهرس أي صفحة من الموقع. عليك الانتباه إلى أنه حتى مع تفعيل هذا الخيار فإن القرار يعود لمحركات البحث لتأخذ به أو تتجاهله، مما يعني أن احتمالية فهرسة موقعك من قِبل محركات البحث موجودة بغض النظر عن رأيك بالموضوع. يُنصح بعدم تفعيل هذا الخيار، نظرًا لرغبة معظم المواقع في أن تُفهرس من قِبل محركات البحث لكي تظهر في صفحات البحث المرتبطة بمحتواها، كما أنّ هذا الخيار يُطبق على كامل الموقع، وبالتالي فإذا أردت عدم فهرسة بضع صفحات فهناك طرق أفضل لتحقيق ذلك. توجد عدة استثناءات لاستخدام هذا الخيار، حيث يمكن مثلًا أن يكون موقعًا خاصًا بمجموعة من الأصدقاء أو أفراد العائلة ويُستخدم فيما بينهم فقط، أو ربما لموظفي شركتك وليس للعموم. عندها يُمكن لهذا الخيار أن يُساعدك على إبقاء موقعك بعيدًا عن محركات البحث ولكنه لا يضمن ذلك. يُستخدم هذا الخيار أيضًا من قبل المطورين عند بناء الموقع لأنه يخضع للكثير من التعديلات والأفضل ألا يُفهرس في هذه الفترة. الخلاصة إن العدد الكبير من الخيارات والإعدادات التي يوفرها ووردبريس يجعل البعض يرتبك ولا يعرف من أين يبدأ سواءً كان مستخدمًا جديدًا لووردبريس أو كان مسكشفًا للوحة التحكم للمرة الأولى، لكن حالما تتعرف على هذه الخيارات فستتمكن من اختيار المناسب لك والتحكم بموقعك بسهولة، وتتضمن صفحة إعدادات وسائط ووردبريس عدة خيارات لتحديد قياسات الأحجام المختلفة للصورة وخيار لتنظيم ملفات الوسائط ضمن مجلدات تعتمد على العام والشهر، لذلك فمن المهم التعرف عليها وكيفية استخدامها للتحكم بمكتبة وسائط موقعك بأفضل صورة. توجد العديد من الخيارات الموجودة ضمن لوحة تحكم ووردبريس سواءً كنت مستخدمًا جديدًا لووردبريس أو مهتمًا بتعلم الميزات التي تُقدمها هذه المنصة، ولذلك توجد العديد من الوظائف والميزات المخفية ضمن صفحات الإعدادات العديدة، وهنا تكمن أهمية تخصيص الوقت لاستكشاف هذه المنصة بعمق أكبر، وقد تحدثنا في هذا المقال عن أهمية صفحة إعدادات القراءة في ووردبريس، وكيفية تخصيص الصفحة الرئيسية وخلاصة الموقع وغيرها، حيث تسمح لك هذه الخيارات بعرض المحتوى الذي تريد بالطريقة التي تُناسبك ضمن موقعك. ترجمة -وبتصرّف- للمقالين: How to Configure Your WordPress Media Settings والمقال How to Configure Your WordPress Reading Settings لصاحبهما Will Morris. اقرأ أيضًا كيفية استخدام مكتبة الوسائط في ووردبريس تعرف على مكتبة الوسائط وأقسامها وكيفية عرض الوسائط في موقع ووردبريس إضافة نص مكتوب لمقاطع الفيديو على صفحات والمقالات وإدارتها على ووردبريس أهمية صفحة إعدادات القراءة في ووردبريس وكيفية ضبطها

توجد العديد من الإعدادات التي عليك معرفة عملها وضبطها في ووردبريس، وهذا ناتج عن المرونة الكبيرة التي يتمتع بها، حيث تختصر الخيارات الموجودة ضمن صفحة "عام" من إعدادات ووردبريس من الوصف، فهي مليئة بالخيارات غير المرتبطة ببعضها، ومع ذلك فهي في الحقيقة أبسط مما تبدو. سوف نطلعك في هذا المقال على الخيارات المتوفرة في صفحة "عام" من إعدادات ووردبريس وكيفية ضبطها للحصول على ما يُناسبك. مقدمة عن الخيارات الموجودة في صفحة عام تختلف إعدادات صفحة "عام" عن مثيلاتها في ووردبريس التي تُركز عادةً على صنف معين، حيث تتضمن صفحة "عام" مجموعةً واسعةً من الخيارات الأساسية لموقعك، مثل صيغة التاريخ والمنطقة الزمنية وعنوان الموقع واللغة، لتبدو هذه الصفحة مثل مستودع يجمع الإعدادات التي لا تملك مكانًا آخر يمكن أن تُضاف له، وبالرغم من ذلك فهي تُعَد مهمة جدًا لعمل موقعك وأمنه وكذا تجربة المستخدم. تستطيع الوصول لهذه الصفحة من لوحة تحكم ووردبريس بالضغط على "عام"، وذلك ضمن قسم "إعدادات". كيفية ضبط إعدادات صفحة عام General في ووردبريس يوجد 12 خيارًا ضمن صفحة "عام" التابعة لإعدادات ووردبريس، والتي يُمكن تصنيفها لخمسة أنواع، بحيث سنوضح كيفية ضبطها في الأقسام التالية. هوية الموقع إن حقل "اسم الموقع" هو نفسه اسم موقعك أو مدونتك، حيث يُعرض عادةً ضمن الترويسة ولسان المتصفح ليظهر للجميع في كل الصفحات. يلعب "اسم الموقع" دورًا مهمًا جدًا في التسويق لعلامتك التجارية وتحسين محركات البحث (سيو)، لذلك فإن وُجد خطأ في عرضه، فتستطيع إصلاحه من خلال صفحة "عام". يستخدم الغالبية شعار موقعهم من أجل ملء "وصف الموقع"، رغم أن الأفضل هو استخدامه لوصف موقعك ومحتواه، إذ تعرِض معظم القوالب "وصف الموقع" بجانب اسم الموقع أو أسفله. املأ وصف موقعك بحكمة لأنه سوف يساعدك في تحسين محركات البحث (سيو)، ولذلك فمن المهم تضمين كلمات مفتاحية يبحث عنها زوارك، مع الإبقاء على الوصف جذابًا ومقروءًا، وكما يظهر من الصورة السابقة فإن وصف موقع Ahrefs يحمل معلومات، كما يتضمن عدة كلمات مفتاحية يبحث عنها الزوار مثل "SEO pro" و"rank higher" و"get more traffic". عنوان ووردبريس URL وعنوان الموقع URL عنوان ووردبريس هو الرابط الكامل للمسار الذي يحتوي على ملفات تثبيت ووردبريس، وفي غالب الحالات فإن عنوان ووردبريس هو عنوان الموقع، ولكن إن نصّبت ووردبريس ضمن مسار خاص به، فعليك التصريح به هنا؛ أما عنوان الموقع فهو كما يُشير إليه الاسم، فهو رابط موقعك الإلكتروني وهو نفسه عنوان ووردبريس، إلا في حال تثبيت ووردبريس ضمن مسار مختلف. تُملأ هذه الحقول في معظم عمليات التثبيت تلقائيًا، بحيث يكون عليك تغييرها فقط عند تعديل بنية ملفات موقعك أو لحل بعض المشاكل. عنوان البريد الإلكتروني للإدارة يُرسل ووردبريس الإشعارات لهذا العنوان والتي تكون في العادة مرتبطةً بأمور إدارية، مثل تسجيل مستخدم جديد أو تعليقات جديدة أو تحديث إضافات. تستطيع استخدام البريد الإلكتروني الذي تريده لأنه لن يُعرض للعلن أبدًا، ولكن من المهم تغيير محتوى هذا الحقل عند تغيير عنوان البريد الإلكتروني الذي تريد استقبال الإشعارات عليه، وسيُذكرك ووردبريس دوريًا بالتحقق من هذا العنوان. تسجيل المستخدم سوف تجد تحت "العضوية" مربع "السماح بالتسجيل"، حيث سيُصبح زوار الموقع من خلال الضغط عليه قادرين على التسجيل به، وهذا مفيد إن أردت من المستخدم الولوج للموقع ليتمكن من كتابة تعليق أو الدخول لأجزاء معينة من الموقع. سوف تجد أسفل هذا الخيار "الرتبة الافتراضية للأعضاء الجدد" وهي عبارة عن قائمة منسدلة تتضمن الرُتب الافتراضية لووردبريس، وهو مهم جدًا عند تفعيل التسجيل ضمن الموقع لتحديد الرُتبة للمسجلين الجُدد، وبالتالي الصلاحيات التي يمتلكونها. توجد خمس خيارات افتراضية تتمثل في الآتي: المدير: يمتلك وصولًا كاملًا لجميع وظائف وأجزاء الموقع. المحرر: يستطيع نشر وإدارة المقالات لجميع المستخدمين ضمن الموقع. الكاتب: يستطيع نشر وإدارة المقالات التابعة له فقط. المساهم: يستطيع كتابة وإدارة مقالاته فقط ولكن لا يستطيع نشرها. المشترك: يستطيع إدارة حسابه الشخصي فقط. من الممكن أن تجد رُتبًا أخرى إلى جانب الرُتب الافتراضية للوردبريس، وذلك بناءً على ما لديك من إضافات، فعلى سبيل المثال عند تثبيت إضافة ووكومرس، فإنها تُضيف رتبتي "الزبون" و"مدير المتجر". يجب اعتماد رتبة "مشترك" لتكون رتبةً افتراضيةً لجميع المُسجلين، إلا إن كانت لديك عوامل أمان تسمح لك بالتحكم بمن يُسجل ضمن الموقع، وتُعَد رتبة "الزبون" خيارًا آمنًا للمتاجر الإلكترونية. إعدادات اللغة والتاريخ والوقت يتضمن آخر قسم من صفحة "عام" كلًا من إعدادات الوقت والتاريخ واللغة، حيث تُستخدم اللغة التي تختارها من القائمة المنسدلة في "لغة الموقع" ضمن لوحة تحكم ووردبريس فقط، فهي لا تعمل على ترجمة محتوى الموقع أو القالب أو الإضافات، ولهذا يجب اختيار اللغة بناءً على اللغة التي يستخدمها غالبية رواد الموقع. تُفيد إعدادات الوقت في تنفيذ الأمور المُجدولة مثل نشر مقال في تاريخ ووقت محددين، حيث يعتمد وقت وتاريخ النشر على إعدادات الوقت هذه، إذ تُعدل ساعة الموقع بالاعتماد على المنطقة الزمنية، وهذا يؤثر على التوقيع الزمني للتعليقات والمنشورات، ولضبطه فما عليك سوى عليك اختيار مدينة ضمن منطقتك الزمنية من القائمة المنسدلة، وإذا لم تستطع العثور على مدينتك، فتستطيع هنا استخدام التوقيت العالمي المنسق UTC، مثل UTC +3 لمنطقة الخليج العربي عدا الإمارات وعُمان، كما تستطيع التحكم بصيغة الوقت والتاريخ باستخدام صيغ مُعرفة أو باستخدام صيغة خاصة بك. اطلع على التوثيق الرسمي للوردبريس إن أردت استخدام الصيغة المخصصة لمعلومات أكثر عن الموضوع، حيث يتحكم هذا الخيار فقط بصيغة التاريخ عند عرضه ضمن الموقع، ولكنه لا يُغير العرض ضمن لوحة تحكم المدير. نفس الأمر ينطبق على صيغة الوقت والتي تتحكم بطريقة عرض الوقت ضمن الموقع ولكن ليس ضمن لوحة تحكم ووردبريس، حيث يتحكم الخيار الأخير ضمن الصفحة في تحديد أي يوم من الأسبوع سيظهر أولًا في التقويم ضمن موقعك، والخيار الافتراضي هو يوم الاثنين، ومع ذلك تستطيع اختيار أي يوم تريد. الخلاصة يُمكن أن تكون الخيارات العديدة التي يوفرها ووردبريس متعبةً في بعض الأحيان للمستخدمين الجدد أو المتمرسين على حد سواء، وذلك لأن هناك عدة صفحات للإعدادات فقط للتثبيت العادي -أي قبل تثبيت أي إضافات جديدة-، ولكن حالما تطلع على ما تنظر إليه فستُصبح هذه الخيارات سهلة الإدارة والتحكم. لقد تحدثنا في هذا المقال عن الخيارات المتوفر في صفحة "عام" من إعدادات ووردبريس بالتفصيل، وذلك بدءًا من عنوان الموقع وانتهاءً بصيغة التاريخ وأول يوم من الأسبوع، لذلك تستطيع الآن تخصيص هذه الإعدادات بما يتناسب مع زوار موقعك ومتطلباتك. ترجمة -وبتصرّف- للمقال How to Configure Your WordPress General Settings لصاحبه Will Morris. اقرأ أيضًا كيفية إضافة مستخدمين جدد لموقع ووردبريس التعرف على لوحة التحكم بشاشة الصفحات في ووردبريس كيفية إنشاء وإدارة صفحات ووردبريس شرح مفصل لصفحات الإدارة وكيفية التحكم الكامل بموقع ووردبريس كيفية تخصيص صفحة ملفك الشخصي على ووردبريس

تُعَد سياسة الخصوصية واحدةً من أكثر أقسام موقع ووردبريس التي لا تحظى بالتقدير، وبالرغم من ذلك يجب أن يضغط كل زائر على خيار الموافقة على سياسة الخصوصية للموقع. من المهم امتلاك سياسة خصوصية مُحكمة في موقعك، فهي توفر حمايةً قانونيةً له (محليًا ودوليًا)، كما تُساهم في رفع ترتيب الموقع وتحسين محركات البحث. يجب أن تكون سياسة الخصوصية واضحةً ومُحّدثةً ومكتوبةً بأفضل صيغة ممكنة، وهناك أدوات ومصادر يُمكن أن تساعدك على كتابتها، وبعض النصائح لما يجب أن تتضمنه سياسة الخصوصية لموقع ووردبريس. ما هي سياسة الخصوصية؟ تُخبر سياسة الخصوصية المستخدمين كيف يُعالج موقعك بياناتهم، لذلك عليك التصريح عن المعلومات التي يجمعها موقعك عن الزوار سواءً كانت عنوان بريد إلكتروني أو الاسم أو الكنية أو الموقع الجغرافي أو غيرها، ثم عليك إخبارهم بما تنوي فعله بهذه المعلومات حتى لو كان الأمر بسيطًا وغير مؤذٍ، مثل إرسال تخفيض عبر البريد الإلكتروني بمناسبة ذكرى ولادته. تُعَد اللائحة العامة لحماية البيانات في الاتحاد الأوروبي GDPR تشريعًا من قِبل الاتحاد الأوروبي، يطلب من الزوار الاشتراك قبل أن تُجمع أي بيانات، ويُشترط امتلاك سياسة خصوصية ضمن موقعك في حال استخدمت Google Analytics أو زر الإعجاب الخاص بفيسبوك أو استخدمت إعلانات أو أي أمر مُشابه. ستكون أنت وزوار موقعك مقيدين بسياسة الخصوصية الموجودة على موقعك سواءً قرؤوها أم لا، وعدم وجود سياسة خصوصية ضمن أي موقع تُعرضه للكثير من المشاكل القانونية، وأولها غرامات بآلاف الدولارات، فقد صدر في مطلع عام 2020 تشريع باسم CCPA أكثر صرامةً من GDPR بما يخص المتطلبات والعقوبات، لذلك فلتأمين نفسك قانونيًا؛ فيجب أن يكون أول بند في قائمة أولوياتك. يجب عليك الاستعانة بمحام لمساعدتك على صياغة مسودة سياسة الخصوصية لموقعك، ولكن هذا ليس خيارًا عمليًا لمعظم أصحاب المواقع، ولهذا انتشرت العديد من الخدمات التي يُمكنها مُساعدتك على صياغة سياسة خصوصية، ولكن المشكلة تكمن في أنه لا يُمكنك الوثوق بأي خدمة تجدها ضمن محرك البحث جوجل، وهنا يأتي دور هذا المقال ليُقدّم لك فكرةً عما يجب أن تتضمنه سياسة الخصوصية، حيث ستستطيع بعد قراءة هذا المقال وما يحويه من معلومات؛ استخدام أي خدمة لتوليد سياسة خصوصية لموقعك. كيفية إنشاء سياسة خصوصية باستخدام ووردبريس لحسن الحظ فإن مطوري ووردبريس توقعوا أن عدم امتلاك سياسة خصوصية للموقع سوف يكون له تداعيات سلبية، لذلك فإن الإصدارات الجديدة من ووردبريس تتضمن تبويب "الخصوصية" ضمن قسم "الإعدادات" في لوحة تحكم ووردبريس، وسشرح في ما يلي خطوات إنشاء سياسة خصوصية لموقعك باستخدام لوحة تحكم ووردبريس. سوف تظهر لك رسالة (1) في أعلى الصفحة حال دخول "الخصوصية" في قسم "الإعدادات"، وهذا لأن قسم سياسة الخصوصية (2) فارغ. إنّ ظهور هذه الرسالة لا يعني أنك لا تمتلك سياسة خصوصية، ولكنه يُشير إلى أنك لا تملك سياسة خصوصية مُولدةً باستخدام هذه الخاصية، وسيُساعدك ووردبريس على إنشاء سياسة الخصوصية إن كنت لا تملك واحدة، وكل ما عليك فعله هو الضغط على "إنشاء" (3). يتضمن الشريط الذي في أعلى المنشور (4) مُلخصًا لما يتضمنه المنشور نفسه، حيث تستطيع الضغط عليه لقراءته بالتفصيل، أو تستطيع التنقل باستخدام الشريط المنزلق لمراجعة النص المُوّلد مسبقًا، وكذا التأكد من أنه مناسب لموقعك. تتشابه سياسات الخصوصية في ووردبريس لأن معظم المواقع تستخدم البيانات بنفس الطريقة، فإن كنت تريد سياسة خصوصية سريعةً وسهلة، فعليك مراجعة الفقرات وإزالة عبارة النص المقترح (5)، والضغط على "نشر" (6)، وستحصل على سياسة خصوصية ضمن صفحة جديدة برابط مثل الرابط الدائم المُستخدم عند النشر في الخطوة السابقة، بعد ذلك يجب عليك مراجعة المعلومات مرةً ثانيةً بعد إنشاء ووردبريس لسياسة الخصوصية لموقعك، وذلك لتتأكد أن جميع العبارات ضمنها تُشير لموقعك. ماذا يجب أن تتضمن سياسة الخصوصية؟ قد تكون النقاط الذي سوف نذكرها لاحقًا، كافيةً أو غير كافية لموقعك للحصول على سياسة خصوصية مُتقنة ومُحكمة، لذلك عُدَّها نقاطًا أساسيةً يجب أن تتضمنها أي سياسة خصوصية، هذه النقاط هي ما يلي: كيف تجمع المعلومات؟ ماذا تفعل بالمعلومات التي تجمعها؟ ماذا يستخدم موقعك لتتبع الزوار من ملفات ارتباط أو بيكسل أو غيرها؟ وما هدفها؟ ما هي شبكات الإعلان التي تستخدمها وطرقهم في جمع البيانات وعرض الإعلان؟ كيف يُمكن للمستخدمين الموافقة أو عدم الموافقة على جمعك لبياناتهم وتخزينها؟ كيف يستطيع مستخدمو موقعك طلب حذف بياناتهم و/أو تسليمها لهم؟ هذه هي النقاط الأساسية التي تتضمنها أي سياسة خصوصية، والتي من المُفترض أن يُلقي الزائر عليها نظرةً ليقرر استخدام خدمتك، ولكن هناك عدد قليل فقط من الأشخاص هم من يقرؤون هذه السياسات، لذلك فمهمتها الأساسية هي حمايتك من الناحية القانونية في حال قرر أحدهم مقاضاتك بسبب استخدامك لبياناته، بالرغم من موافقته على ما ذُكر في سياسة خصوصيتك. تتضمن سياسة الخصوصية بقسم كبير منها ذكر ملفات الارتباط التي تُحفظ على حاسوبك، وهي تتضمن إعدادات خاصة لمواقع خاصة، حيث تُستخدم ملفات الارتباط لتتبع المستخدم ضمن الموقع، حيث تسمح لك ملفات الارتباط مثلًا، بالبقاء مُسجلًا ضمن الموقع حتى بعد مغادرته (بالرغم من وجود محدودية لهذه الجزئية)، ويجب أن يُبلغ الموقع زواره عن استخدامه لملفات الارتباط، مع توفير خيار يسمح له بتعطيلها تنفيذًا لما جاء في قانون ملفات الارتباط للاتحاد الأوروبي وتشريعات الخصوصية الإلكترونية. ما تفعله ببيانات المستخدمين من المهم أن تذكر كيف تستخدم البيانات، إذ لها نفس أهمية ذكر جمعك لها، وذلك لأن للبيانات سوقًا ضخمًا بمليارات الدولارات التي تتدفق سنويًا في هذا السوق، إلى جانب العديد من المواقع التي تبيع بيانات مستخدميها؛ أما البعض الآخر فيستخدم هذه البيانات لتخصيص المحتوى والإعلانات لزواره. كيفية إنشاء سياسة خصوصية مُخصصة إذا كان النشاط التجاري متضمنًا على استخدام بيانات حساسة، فالأفضل هو إنشاء سياسة خصوصية مُفصلة لمتطلبات موقعك، وربما من الأفضل الاستعانة بمحامي، ففي نهاية المطاف سياسة الخصوصية هي عبارة عن وثيقة قانونية مُلزم بها أنت ونشاطك التجاري. وإن كنت لا ماتزال راغبًا في تصميم سياسة خصوصية بدون وجود محامي، فهناك خدمات عدة انتشرت خلال السنوات الماضية، بحيث تُولد لك سياسة خصوصية معيارية قابلةً للتخصيص لموقعك الإلكتروني، وسوف نتحدث عن بعض هذه الخدمات. Termageddon تُعَد Termageddon خدمةً مميزةً تُولّد تلقائيًا سياسات خصوصية مُحدًثة، حيث يُحدث Termageddon سياسة الخصوصية المُضمنة لديك كلما صدر قانون جديد يؤثر على بيانات الخصوصية، فعندما دخلت قرارات CCPA مثلًا حيز التنفيذ؛ فقد حدّث Termageddon سياسات الخصوصية لديه انطلاقًا من تشريعات GDPR. تُعَد عملية ضبط هذه الخدمة سهلة، بحيث تتطلب الإجابة على بعض الأسئلة حول تجارتك أو موقعك الإلكتروني، بعد ذلك عليك لصق شيفرة التضمين ضمن الصفحة التي تريد عرض سياسة الخصوصية فيها، طبعًا ستستطيع تجاوز أي تحديث أو تغيير، كما تستطيع تعديل السياسة يدويًا، وفي حال كنت تتعامل مع كمية كبيرة من البيانات عليك دفع 10$ شهريًا. لا يقتصر استخدام Termageddon على مواقع ووردبريس فقط، بل يمكنك استخدامه لضبط سياسة الخصوصية لمتجر شوبيفاي أو تطبيقات فيسبوك أو غيرها، وبالتالي فإن كنت تستخدم إضافات خارجية لموقعك، فإن Termageddon تُعَد خيارك الأفضل. TermsFeed يسمح لك TermsFeed بتوليد سياسة خصوصية خلال دقائق، بحيث تستطيع بسهولة تخصيصها باستخدام معلومات موقعك، حيث عليك الإجابة على مجموعة من الأسئلة في كل مرة تستخدم فيها هذه الخدمة لإنشاء سياسة خصوصية لموقعك، فهي تُساعدك من خلال هذه الأسئلة على استخدام العبارات القانونية التي تحتاجها، وستستلم سياسة الخصوصية عبر بريدك الإلكتروني عند انتهائك من الإجابة على الأسئلة لتتمكن من استخدامها على الموقع ونشرها ليقرأها الزوار. تُوفر هذه الخدمة خيار تحديث سياسة الخصوصية خاصتك تلقائيًا عند تغيّر القوانين. تستطيع تحميل عدة قوالب جاهزة لشروط الخدمة مع تعديلها حسب حاجتك، إلى جانب كتابة المعلومات التي تريدها ضمنها. إن خدمة TermsFeed ليست مخصصةً فقط لمواقع ووردبريس، بل يُمكن استخدام سياسة الخصوصية التي تُولدها هذه الخدمة على تطبيقات iOS ومنصات SaaS وتطبيقات سطح المكتب التي تحتاج أذون لتعمل محليًا على جهازك. FireBase لقد صُمِّم FireBase إلى حد كبير لتطبيقات الهاتف، ولكنه يُعد أداةً جيدةً لتوليد سياسة الخصوصية، وخاصةً إن كنت تريد الحصول عليها بسهولة وسرعة، مع تخصيصها لك إلى حد ما. يُعَد من السهل استخدام هذه الخدمة للحصول على سياسة خصوصية بسيطة لكن مفيدة، حيث تُظهر السياسات المُولدة باستخدام هذه الأداة كيف تستخدم ملفات الارتباط والخدمات المتنوعة، وتُعد أفضل سياسة للخصوصية هي تلك الناتجة عن هذه الأداة، لأنها مكتوبة بلغة أبسط يستطيع المستخدم فهمها، إذ لا تغطي سياسة الخصوصية هنا بعض التشريعات المعقدة كما تفعل الخدمات السابقة، ولكن إن أردت مولد سياسة خصوصية سريع وسهل وبلغة واضحة فهي الخيار الأفضل. كيفية إضافة سياسة الخصوصية الجديدة في ووردبريس إذا استخدمت أيًا من الخدمات السابقة وليس الخدمة المقدمة من ووردبريس، فعليك نقل سياسة الخصوصية لموقعك، وإلا فلا فائدة منها. لكن لا داعي للقلق فالعملية بسيطة جدًا، والخطوة الأولى تتطلب منك إضافة صفحة جديدة بالضغط على قسم "صفحات" (1)، ثم خيار "أضف جديد" (2)، بعدها أدخل عنوان صفحة ووردبريس الجديدة وليكن "الخصوصية" أو "سياسة الخصوصية" (3). عليك الآن نقل محتوى سياسة الخصوصية لهذه الصفحة أو لصق شيفرة تضمين السياسة المُقدمة من الخدمة التي استخدمتها. لنفترض أنك قد أنشأت سياسة خصوصية لووردبريس باستخدام أحد المولدات، ثم لصقتها ضمن المحرر التقليدي لووردبريس. اضغط الآن على "نشر" لتبقى خطوة واحدة عليك تنفيذها، وهي جعل هذه السياسة ظاهرةً لجميع المستخدمين، من خلال وضع رابط لها في صفحة "من نحن"، ولكن أفضل مكان لها هو القائمة الرئيسية لووردبريس أو القائمة الموجودة في التذييل. تستطيع إضافة عنصر جديد للقائمة من خلال قسم "مظهر" (1)، ثم تبويب "قوائم" (2)، والآن عليك اختيار القائمة المناسبة لك لتعديلها، اختر صفحة "سياسة الخصوصية" (3) التي أنشأتها وأضفها لتكون عنصرًا رئيسيًا للقائمة، أو ثانويًا لأحد عناصر القائمة (4)، ثم اضغط على "حفظ القائمة" (5). يجب عليك الضغط على "حفظ القائمة"، فهذه من أكثر الخطوات التي يسهو عنها مستخدمو ووردبريس، وللأسف فإن القائمة لا تُحفظ تلقائيًا عند تعديلها. يجب أن تجد الآن صفحة سياسة الخصوصية في القائمة تعمل دون أي مشاكل. الخلاصة لست بحاجة لكتابة وثيقة قانونية جديدة كل مرة تُحدّث فيها سياسة الخصوصية، وبفضل مطوري ووردبريس ومنصات أخرى مثل Termageddon، فستستطيع امتلاك أي عدد من هذه الوثائق القانونية خلال لحظات. يُظهر وجود سياسة خصوصية واضحة للجميع جديّتك بحماية بيانات مستخدميك، بحيث تُوضح ضمنها كيفية استخدامك للبيانات وتحمي نفسك من الناحية القانونية والأخلاقية. ترجمة -وبتصرّف- للمقال How to Configure your WordPress Privacy Settings لصاحبه B.J. Keeton. اقرأ أيضًا ضبط شاشة الإعدادات العامة بلوحة تحكم ووردبريس إجراء الترقية الآمنة لووردبريس عبر أداة الأتمتة Automate 30 إضافة ووردبريس أساسية يجب عليك تثبيتها إذا لم تكن ثبتها بالفعل الدليل الكامل إلى أمن مواقع ووردبريس هل ووردبريس آمن؟

ترتبط منصة ووردبريس بالكتابة ارتباطًا عميقًا، وقد هذا كان هو الهدف من إنشائها، فهي تُسهل عليك عملية نشر المقالات، إضافةً إلى أنواع مختلفة من المحتوى، كما تحث القُرّاء على النقاش فيما بينهم. يُعَد هذا جزءًا فقط من ما تقدمه منصة ووردبريس وهي بالتأكيد منصة صديقة للكُتاب والناشرين. توجد بعض الإعدادات التي تتعلق بالكتابة في ووردبريس، حيث تسمح لك بتعديل أجزاء مرتبطة بتجربة إنشاء المحتوى، حيث سيغطي هذا المقال هذا القسم من إعدادات ووردبريس ووظيفة كل منها. مقدمة لصفحة إعدادات الكتابة في ووردبريس يوفر ووردبريس عددًا كبيرًا من الخيارات من بينها الخيارات المرتبطة بالكتابة، لذلك فمن المهم قبل أن نبدأ بالحديث عنها، أن نوضح بأن هذه الإعدادات غير مرتبطة بمحرر ووردبريس التقليدي أو الافتراضي، بل هي تُركز على تخصيص الصيغة الافتراضية للمحتوى وتأمين ميزة "النشر عبر البريد الإلكتروني" وإشعار خدمات الطرف الثالث بالتحديثات. لمعرفة المزيد عن إعدادات الكتابة في ووردبريس، اذهب إلى لوحة تحكم ووردبريس وتوجه لتبويب "كتابة" في قسم "الإعدادات". لا توجد العديد من الخيارات كما هو ظاهر في الصورة السابقة، ولكن بعض الخيارات الموجودة قد تكون معقدةً، لذا فمن المهم جدًا أن تأخذ وقتك وتتأكد من أن كل شيء مضبوط كما تريد. كيفية ضبط إعدادات صفحة الكتابة في ووردبريس ألقي نظرةً على جميع الخيارات المتوفرة، وتذكر أنه عليك حفظ الإعدادات عند الانتهاء من ضبطها كي لا تُضطر لضبطها مرةً أخرى. التصنيف والبنية الافتراضيين للمقالة يتضمن ووردبريس نظام تصنيف متينًا يسمح لك بتعيين تصنيفات ووسوم لكل مقال تنشره، حيث تستطيع إضافة ما تريد من التصنيفات والوسوم لتُسهل عليك عملية تنظيم المقالات ضمن الموقع وإيجادها من قِبل الزوار المهتمين بقرائتها، إذ يُتيح لك ووردبريس في صفحة إعدادات الكتابة اختيار التصنيف الافتراضي للمقالات الجديدة، كما تستطيع الاختيار البنية الافتراضية للمقال. يعتمد عدد من خيارات بنية المقال على القالب الذي تستخدمه، فهي عبارة عن قوالب تتحكم بطريقة عرض محتوى المنشور للزوار، ويستخدم ووردبريس تلقائيًا البنية القياسية للمقالات الجديدة. يدعم ووردبريس العديد من بُنى المقالات، مثل الصور والاقتباسات والصوت وغيرها، حيث يُساعد استخدام البنية المناسبة على جعل المحتوى أكثر جاذبيةً للقارئ، فمثلًا إذا كنت تريد إدارة مدونة موسيقية ومشاركة ملفات صوتية مع الزوار، فعندها سيكون عليك تغيير البنية الافتراضية لمقالات موقعك. ترتبط هذه الميزة بشكل الموقع وتصميمه أكثر من بنيته الوظيفية، ولذلك فليس من الضروري استخدامها إن كنت لا ترغب في ذلك. تُقدم بعض القوالب بنية مقال واحدة فقط، وإن كانت هذه هي الحالة لديك، فلن تظهر القائمة المنسدلة للبنية الافتراضية للمقالة ضمن صفحة إعدادات الكتابة لموقعك، وهذا أمر غير شائع. تستطيع إضافة تصنيفات جديدة لموقعك من خلال التوجه إلى تبويب "تصنيفات" في قسم "مقالات" إن كنت لا تجد التصنيف الافتراضي مناسبًا لك. سوف تتمكن من اختيار التصنيف الجديدة مثل تصنيف افتراضي حالما تحفظه في صفحة التصنيفات، ولكن عليك العودة لصفحة إعدادات الكتابة من خلال تبويب "كتابة" ضمن قسم "الإعدادات"، ثم اختيار هذا التصنيف من القائمة المنسدلة. تذكر أنك تستطيع تصنيف موقعك كيف ما تشاء دون أن تقلق حول خيارك هنا لأنك قادر على تغييره في أي وقت ودون أي مشاكل. النشر بواسطة البريد الإلكتروني في واحدة من ميزات ووردبريس المُهملة، نجد إمكانية نشر مقالات من خلال البريد الإلكتروني، حيث تسمح لك منصة ووردبريس بضبط إعدادات بريد إلكتروني مُعين يَنشر تلقائيًا محتوى الرسالة التي يتلقاها يتكون بمثابة مقال على موقعك. تُعَد هذه الميزة مفيدةً جدًا عندما لا تستطيع الوصول للوحة التحكم مؤقتًا رغم حاجتك لتنشر مقالًا عاجلًا، كما أنها مفيدة إذا كنت تستخدم هاتفك المحمول ولا تستطيع استخدام محرر ووردبريس بسهولة مع قدرتك على كتابة بريد إلكتروني. الجانب السلبي لهذه الميزة هو عدم قدرتك على استخدام خيارات تنسيق متقدمة للمقال وبالتالي سوف يظهر أي محتوى تنشره عبر البريد الإلكتروني مثل مقال بنص بسيط عادي دون أي تنسيق. يُعَدّ تنسيق المقالات أمرًا هامًا جدًا لأنه يُسهل على الزوار عملية القراءة ويحفزهم على التفاعل مع المقال، إضافةً إلى صلته بتحسين محركات البحث SEO. بعد إطلاعك على إيجابيات وسلبيات النشر عبر البريد الإلكتروني، يمكن القول أنه يوصى باستخدام هذه الميزة عند الحاجة فقط؛ أما لاستخدامها فستحتاج لعنوان بريد إلكتروني مع تفعيل POP3 عليه، ويجب أن يكون هذا العنوان مخصصًا فقط لهذه الغاية لأن أي رسالة تصله سوف تُنشر تلقائيًا على موقعك. يطلب منك ووردبريس إدخال عنوان البريد الإلكتروني واسم الخادم ورقم المنفذ وكلمة المرور، وإن كنت غير متأكد من اسم الخادم لبريدك الإلكتروني، فغالبًا سوف تجد الإجابة ضمن قاعدة معلومات المزود التابع له. تستطيع اختيار التصنيف الافتراضي للمقالات التي تُنشر باستخدام البريد الإلكتروني، وهذا الخيار غير مرتبط بالخيار السابق الذي يتحكم بتصنيفات المقالات التي تُنشر باستخدام لوحة التحكم. خدمات التحديث هناك ميزة أخرى من ووردبريس لا تلقى رواجًا بين المستخدمين، وهي إشعار خدمات طرف ثالث عند نشر محتوى جديد على موقعك، والاستخدام الرائج لهذه الميزة هو إعلام محركات البحث والقنوات الإخبارية بآخر المقالات على موقعك، كي لا تُضطر لانتظارهم لفهرسة محتوى موقعك الجديد يدويًا. يجب عليك إضافة قائمة بالخدمات والقنوات الإخبارية التي تريد تنبيهها عند نشر أي شيء جديد على موقعك، وذلك كي تعمل هذه الخاصية. تستطيع رفع ظهور موقعك من خلال تضمين بضع قنوات إخبارية هنا، مع إبقاء الزوار على اطلاع بآخر التحديثات، وفي بديل عن ذلك، يُمكنك وضع Ping-O-Matic الذي يعمل على تنبيه مجموعة من الخدمات مع بعضها بنفس الوقت، لكن يجب الانتباه أنه عند استخدام هذه الميزة، فمن غير المُحبذ تنبيه محركات البحث كثيرًا لأنك بلك ستعمل على الرفع من احتمال معاقبة موقعك عند إشعارهم مرارًا خلال فترات زمنية قصيرة، وهو أمر مُحتمل الحدوث لموقع ينشر مقالات يوميًا أو حتى أسبوعيًا. توجد طرق أفضل للتأكد من أنّ محركات البحث تزحف لموقعك دوريًا، مثل استخدام طرفية البحث التابعة لمحرك البحث وطلب مراجعة موقعك في أي وقت. الخلاصة تُعَد صفحة إعدادات الكتابة في ووردبريس واحدةً من أصغر الصفحات التي تتضمن خيارات، ولكنها بالرغم من ذلك تُعَد مهمة جدًا، بحيث يجب عليك ضبطها لكل موقع من مواقعك بما يتناسب مع محتواه وطلب جمهوره. تتضمن هذه الخيارات بعض الميزات المفيدة، مثل اختيار قالب البنية الافتراضية للمقال، أو التصنيف الافتراضي للمقال؛ أما بقية الخيارات فهي تُعَد أقل استخدامًا، ومع ذلك فيجب الإطلاع عليها، إذ أنك لا تعلم متى ستحتاجها، مثل ميزة النشر باستخدام البريد الإلكتروني أو خدمات التحديث. ترجمة -وبتصرّف- للمقال How to Configure Your WordPress Writing Settings لصاحبه Will Morris. اقرأ أيضًا كيفية ضبط إعدادات الوسائط والقراءة في ووردبريس كيفية ضبط صفحة عام في إعدادات ووردبريس ضبط شاشة الإعدادات العامة بلوحة تحكم ووردبريس أهمية صفحة إعدادات القراءة في ووردبريس وكيفية ضبطها كيفية ضبط إعدادات المناقشة في ووردبريس

ووردبريس هو عبارة عن منصة تدوين بالأساس، وما زال يُستخدم في الغالب لهذا الغرض، لذلك فإن التعليقات هي مكوّن أساسي لمعظم التدوينات التقليدية وطريقة سهلة للحصول على تفاعل من القُرّاء. يمتلك ووردبريس مجموعةً مفيدةً من إعدادات المناقشة التي تستطيع ضبطها لتُلبي احتياجاتك وتحقيق أكبر قدر ممكن من الفائدة من هذه الميزة، حيث تستطيع التحكم كُليًا بآلية تفاعل القُرّاء مع قسم التعليقات في ووردبريس عبر تعديل إعدادات المناقشة، وسنشرح في هذا المقال الخيارات المُتاحة وعملها لضبط التعليقات في موقعك على ووردبريس. مقدمة لإعدادات المناقشة في ووردبريس تستطيع الوصول لإعدادات المناقشة في ووردبريس بسهولة، فما عليك سوى الدخول إلى لوحة تحكم ووردبريس ثم التوجه لتبويب "مناقشة" ضمن قسم "الإعدادات". سنشرح ضمن الفقرات القادمة عمل كل خيار على حدة، وهذا يتضمن ضبط آلية عمل التعليقات والإشعارات والصورة الرمزية ومراجعة التعليقات المنشورة ضمن موقعك الإلكتروني. كيفية ضبط إعدادات المناقشة في ووردبريس سوف تطّلع الآن على عمل كل خيار، وعليك أن لا تنسى حفظ الإعدادات قبل مغادرة الصفحة عند عمل أي تعديل على إعدادات المناقشة في ووردبريس. إعدادات التعليقات الأساسية يتضمن ووردبريس افتراضيًا قسمًا خاصًا بالتعليقات ضمن كل منشور على موقعك الإلكتروني، كما أنك تستطيع تفعيل التعليقات على صفحات محددة لتوفير فرصة للزوار لمشاركتك أفكارهم. تستطيع أيضًا تعطيل قسم التعليقات لمنشورات وصفحات مُحددة من خلال تحرير الصفحة، باستخدام المحرر الافتراضي لووردبريس والضغط على قسم "مُناقشة" في الشريط الجانبي، ثم إلغاء خيار "السماح بالتعليقات". ولتعطيل التعليقات على جميع المنشورات فعليك التوجه لصفحة إعدادات المناقشة في ووردبرس من خلال لوحة التحكم لووردبريس، والضغط على تبويب "مناقشة" في قسم "الإعدادات". يتضمن القسم الأول من هذه الصفحة ثلاث خيارات ضمن قسم "الإعدادات الافتراضية للمقالة". يرتبط الخيار الأول والثاني بالتنبيهات، بحيث عند ذكر رابط موقع آخر ضمن التعليقات أو المنشورات، فسيُرسل ووردبريس "تنبيهًا" أو إشعارًا له، وفي حال كان هذا الموقع مبنيًا على منصة ووردبريس، فسيظهر التنبيه مثل تعليق ينتظر المراجعة. يؤدّي تعطيل خيار "محاولة تنبيه المدوَّنات المشار إليها في المقالة" لإيقاف إرسال الإشعارات والتنبيهات من موقعك الإلكتروني، أما تعطيل خيار "السماح بإشعارات الربط من المدونات الأخرى (التنبيهات "PingBacks" والتعقيبات "TrackBacks") في المقالات الجديدة"، فسيحجب الإشعارات القادمة من مواقع أخرى لموقعك لأي محتوى يُنشر مُستقبلًا. بطبيعة الحال توجد إيجابيات وسلبيات لهذه الخيارات، ةلذلك فمن المهم معرفة عملها قبل تفعيلها أو تعطيلها. يسمح لك الخيار الأخير ضمن هذا القسم بتعطيل التعليقات ضمن ووردبريس، حيث يُفضل مديرو بعض المواقع تعطيل التعليقات بدلًا من مُراجعتها يوميًا لكل منشور، لكن هذا يعني خسارة فرصة التفاعل مع المستخدِم، وبالتالي من المهم موازنة الإيجابيات والسلبيات لهذا الخيار قبل اتخاذ قرار تفعيله أو تعطيله. إعدادات التعليقات المتقدمة ألق نظرةً على مجموعة الخيارات التالية والتي تمنحك تحكمًا أكبر بإعدادات المناقشة. تستطيع هنا اختيار ما إذا كان المُستخدم بحاجة لتوفير اسمه وبريده الإلكتروني ليتمكن من كتابة تعليق، حيث يُساعد هذا على تقليل التعليقات المُزعجة وعمليات التصّيُد، كونها تفرض على المستخدم التعريف عن نفسه. كما يُساعدك هذا الخيار أيضًا على بناء قوائم البريد الإلكتروني أو التواصل مع الأفراد الذين يبحثون عن خدمة عملاء. يُمكنك أن تطلب من المُستخدمين التسجيل ضمن الموقع والدخول إليه ليتمكنوا من كتابة تعليق، وهو أمر مفيد جدًا في المواقع التي تتضمن عضويةً أو مجتمعات حصريةً. يوجد خيار آخر يسمح لك بإيقاف قسم التعليقات ضمن أي منشور مضت على نشره مدة مُحددة من الأيام، بحيث يسمح هذا للقُرّاء بالتفاعل معك ومع المحتوى، إضافةً إلى تخفيض عبء مراجعة كمية ضخمة من التعليقات، وبهذا تستطيع التركيز في كل مرة على عدد مُحدد من المنشورات لترد على القُرّاء بدلًا من مراقبة الموقع كاملًا. توجد إعدادات أخرى تستطيع ضبطها هنا وهي: ملفات تعريف الارتباط: اختر تفعيل ملفات ارتباط الكاتب والتي تحفظ معلومات المستخدم ضمن المتصفح كي يتمكن من كتابة تعليقات بسهولة أكبر في المستقبل. التعليقات التشعبية: اختر إذا ما كنت تريد السماح للمستخدمين بالرد على تعليقات بعضهم البعض، وبالتالي إنشاء عمق جديد للتعليقات. عدد التعليقات في كل صفحة: اختر آلية تنظيم التعليقات، فهل تريد عرض جميع التعليقات في صفحة واحدة أم عدد مُحدد في كل صفحة؟ تستطيع اختيار الترتيب الذي تظهر به التعليقات، حيث يعرض ووردبريس افتراضيًا التعليقات الأقدم في أعلى القسم وهو النموذج المألوف من قِبل معظم المستخدمين. إعدادات إشعارات المناقشة تستطيع هنا اختيار طريقة إعلامك من قِبل ووردبريس بظهور تعليقات جديدة على موقعك من قِبل المستخدمين، والخيار الافتراضي هو إرسال بريد إلكتروني لك عند كتابة تعليق من قِبل أحد المستخدمين على موقعك. تُوضع التعليقات الجديدة في رتل المراجعة لتتمكن من مراجعتها والموافقة عليها يدويًا قبل أن تظهر على الموقع، حيث تستطيع الوصول لهذه القائمة أو الرتل بالضغط على قسم "تعليقات" في لوحة تحكم ووردبريس. إن استخدام طريقة الإشعار السابقة جيدة طالما أنك تُدير مدونةً حديثة العهد ولا تملك العديد من التعليقات، ولكن سوف تشعر بالإزعاج عند وصول مئات الإشعارات لبريدك في حال كان لديك العديد من القُرّاء يوميًا لمدونتك، إذ سيُصبح من الصعب عليك قراءة بريدك الإلكتروني أو العثور على بريد هام ضمنه، ولذلك يُعطل العديد من مديري المواقع هذا الخيار ويعملون على مراجعة التعليقات دوريًا دون الحاجة لوصول إشعار بها. إعدادات مراجعة التعليق تُعَد عملية مراجعة التعليقات أمرًا مهمًا جدًا لأي موقع إلكتروني، حيث ستتلقى العديد من التعليقات المزعجة إن سمحت للجميع بنشر التعليقات دون أي مراجعة، أضف إلى ما سبق تعليقات تتضمن خطاب كراهية أو عبارات غير لائقة بين المستخدمين. يوفر ووردبريس رتلًا لمراجعة التعليقات والموافقة عليها قبل أن تظهر على الموقع، كما أنك تستطيع حذف التعليق أو تعيينه على أنه مزعج، إذ يوجد خياران ضمن قسم "قبل ظهور التعليق" يسمحان لك باختيار الطريقة الأنسب لك للتعامل مع التعليقات الجديدة قبل ظهورها. يسمح لك الخيار الأول بالموافقة على كل تعليق يدويًا قبل ظهوره على الموقع، أو السماح تلقائيًا بظهور التعليق إن كان لصاحب التعليق تعليق سابق يظهر على الموقع. وتستطيع تفعيل أحد الخيارين أو عدم اختيارهما لتعطيل عملية المراجعة وهو فعل لا نوصي به لأن ذلك يجعل موقعك غير احترافي وغير موثوق، خصوصًا إن كان قسم التعليقات مليئًا بالتعليقات المزعجة أو التي تتضمن تعليقات مسيئةً وغير لائقة. تستطيع تخفيض عبء العمل من خلال السماح لأصحاب التعليقات السابقة بنشر تعليقاتهم دون مراجعة، لكن ذلك سيفتح المجال لظهور مناقشات أو خلافات ضمن التعليقات بين المستخدمين، ولتجنب ذلك تستطيع ضبط ما هو مسموح باستخدامه ضمن قسم التعليقات باستخدام الخيارات التابعة لـ "إدارة التعليقات". تستطيع هنا إحالة التعليقات للمراجعة إذا تضمنت عددًا معينًا من الروابط، وهو الأمر الذي يُساعدك على تقليل التعليقات المزعجة، كما تستطيع وضع قائمة بالمصطلحات وحتى عناوين IP التي تُفعل إحالة التعليق للمراجعة، حيث سيساعدك هذا على استبعاد العديد من التعليقات المشبوهة تلقائيًا دون أي تدخل مُباشر منك، كما تستطيع أيضًا وضع قائمة بالمصطلحات والعبارات التي تريد حجبها تمامًا من التعليقات. سوف تُنقل التعليقات للمهملات مباشرةً عند احتوائها على أي من المصطلحات الموجودة ضمن القائمة السابقة لتوفر عليك الكثير من الوقت عند مراجعة التعليقات. إعدادات الصورة الرمزية يتعلق القسم الأخير من صفحة إعدادات مناقشة ووردبريس بالصورة الرمزية، حيث يُفعل ووردبريس الصورة الرمزية تلقائيًا لجميع المستخدمين الذي يشاركون أفكارهم ضمن موقعك، وفي حال كان لديهم حساب Gravatar، فسيستخدم ووردبريس الصورة المُستخدمة ضمن الحساب لعرضها على أساس صورة شخصية لهم على موقعك. وهنا تستطيع طبعًا تعطيل الصورة الرمزية، كما تستطيع تعطيل الصور التي من الممكن ألا تُناسب جمهورك. يوجد خيار لضبط الصورة الرمزية الافتراضية للمستخدمين الذين لا يمتلكون حساب Gravatar أو لم يرفعوا صورةً شخصيةً لحسابهم، حيث يُمكنك المفاضلة بين مجموعة خيارات يوفرها ووردبريس والتي يكون أحدها "فارغًا" أي بدون صورة. تُضيف الصورة الرمزية لمسةً جميلةً لقسم التعليقات، فتفعيلها يُشعر القُرّاء بالراحة عند مشاركة أفكارهم، لكنها غير ضرورية من ناحية عمل التعليقات، ولذلك فإنّ قرار تفعيلها من عدمه يعود لك. الخلاصة يُعَد قسم التعليقات في ووردبريس قسمًا أساسيًا لأي مدونة أو موقع يريد السماح لزواره بمشاركة أفكارهم، لكن من المُرجح أن تشوب الفوضى هذا القسم في حال عدم وجود مراجعة للتعليقات التي تُنشر. لحسن الحظ فأنت قادر على ضبط إعدادات المناقشة في ووردبريس، فبالإضافة لقدرتك على تفعيل أو تعطيل التعليقات على الصفحات والمنشورات؛ فأنت قادر على اختيار التعليقات التي تُعرض ومن يستطيع نشرها، وما هي شروط إحالة التعليقات للمراجعة أو الحذف، إضافةً إلى عرض الصورة الرمزية إلى جانب التعليقات. ترجمة -وبتصرّف- للمقال How to Configure Your WordPress Discussion Settings لصاحبه Will Morris. اقرأ أيضًا كيفية ضبط صفحة عام في إعدادات ووردبريس كيفية ضبط إعدادات الوسائط والقراءة في ووردبريس التعامل مع التعليقات في ووردبريس كيفية إنشاء وإدارة صفحات ووردبريس استطلاع صفحة إعدادات الكتابة للتحكم بعملية إضافة المحتوى في ووردبريس

إن بروتوكول ضبط المضيف ديناميكيًّا (Dynamic Host Configuration Protocol) هو خدمة شبكة تُفعِّل إسناد إعدادات الشبكة إلى الحواسيب المضيفة من خادوم بدلًا من إعداد كل مضيف شبكي يدويًا؛ حيث لا تملك الحواسيب المُعدَّة كعملاءٍ لخدمة DHCP أيّة تحكم بالإعدادات التي تحصل عليها من خادوم DHCP. إن أشهر الإعدادات الموفَّرة من خادوم DHCP إلى عملاء DHCP تتضمن: عنوان IP وقناع الشبكة.عنوان IP للبوابة الافتراضية التي يجب استخدامها.عناوين IP لخواديم DNS التي يجب استعمالها.لكن يمكن أيضًا أن يوفِّر خادوم DHCP خاصيات الضبط الآتية: اسم المضيف.اسم النطاق.خادوم الوقت.خادوم الطباعة.من مزايا استخدام DHCP هو أن أي تغييرٍ في إعدادات الشبكة -على سبيل المثال تغيير عنوان خادوم DNS- سيتم في خادوم DHCP فقط، وسيُعاد ضبط جميع مضيفي الشبكة في المرة القادمة التي سيَطلُبُ فيها عملاء DHCP معلومات الإعدادات من خادوم DHCP؛ ويُسهِّل استعمال خادوم DHCP إضافة حواسيب جديدة إلى الشبكة، فلا حاجة للتحقق من توفر عنوان IP؛ وسيقل أيضًا التضارب في حجز عناوين IP. يمكن أن يُوفِّر خادوم DHCP إعدادات الضبط باستخدام الطرق الآتية: التوزيع اليدوي (Manual allocation) عبر عنوان MACتتضمن هذه الطريقة استخدام DHCP للتعرف على عنوان مميز لعتاد كل كرت شبكة متصل إلى الشبكة، ثم سيوفِّر إعدادات ضبطٍ ثابتةً في كل مرة يتصل فيها عميل DHCP إلى خادوم DHCP باستخدام بطاقة الشبكة المعيّنة مسبقًا؛ وهذا يضمن أن يُسنَد عنوان معيّن إلى بطاقةٍ شبكيّةٍ معيّنة وذلك وفقًا لعنوان MAC. التوزيع الديناميكي (Dynamic allocation)سيُسنِد خادوم DHCP -في هذه الطريقة- عنوان IP من مجموعة من العناوين (تسمى pool، أو في بعض الأحيان range أو scope) لمدة من الزمن (يسمى ذلك بالمصطلح lease) التي تُضبَط في الخادوم، أو حتى يخبر العميل الخادوم أنه لم يعد بحاجةٍ للعنوان بعد الآن؛ وسيحصل العملاء في هذه الطريقة على خصائص الضبط ديناميكيًّا وفق المبدأ «الذي يأتي أولًا، يُخدَّم أولًا»؛ وعندما لا يكون عميل DHCP متواجدًا على الشبكة لفترة محددة، فسينتهي وقت الضبط المخصص له، وسيعود العنوان المسند إليه إلى مجموعة العناوين لاستخدامه من عملاء DHCP الآخرين؛ أي أنَّه في هذه الطريقة، يمكن «تأجير» أو استخدام العنوان لفترة من الزمن؛ وبعد هذه المدة، يجب أن يطلب العميل من الخادوم أن يعيد تأجيره إياه. التوزيع التلقائي (Automatic allocation)سيُسنِد خادوم DHCP -في هذه الطريقة- عنوان IP إسنادًا دائمًا إلى جهاز معين، ويتم اختيار هذه العنوان من مجموعة العناوين المتوفرة؛ يُضبَط عادةً DHCP لكي يُسنِد عنوانًا مؤقتًا إلى الخادوم، لكن يمكن أن يسمح خادوم DHCP بزمن تأجير «لا نهائي». يمكن اعتبار آخر طريقتين «تلقائيتَين»، ﻷنه في كل حالة يُسنِد خادوم DHCP العنوان دون تدخل إضافي مباشر، الفرق الوحيد بينهما هو مدة تأجير عنوان IP؛ بكلماتٍ أخرى، هل ستنتهي صلاحية عنوان العميل بعد فترة من الزمن أم لا. يأتي أوبنتو مع خادوم وعميل DHCP، الخادوم هو dhcpd‏ (dynamic host configuration protocol daemon)، والعميل الذي يأتي مع أوبنتو هو dhclient، ويجب أن يثبَّت على جميع الحواسيب التي تريدها أن تُعَدّ تلقائيًا، كلا البرنامجين سهلُ التثبيت، وسيبدآن تلقائيًا عند إقلاع النظام. التثبيتاكتب الأمر الآتي في مِحَث الطرفية لتثبيت dhcpd: sudo apt-get install isc-dhcp-serverربما تحتاج إلى تغيير الضبط الافتراضي بتعديل ملف ‎/etc/dhcp/dhcpd.conf ليلائم احتياجاتك والضبط الخاص الذي تريده. ربما تحتاج أيضًا إلى تعديل ‎/etc/default/isc-dhcp-server لتحديد البطاقات الشبكية التي يجب أن «يستمع» (listen) إليها عفريت dhcpd. ملاحظة: رسالة عفريت dhcpd تُرسَل إلى syslog، انظر هناك لرسائل التشخيص. الضبطربما سيربكك ظهور رسالة خطأ عند انتهاء التثبيت، لكن الخطوات الآتية ستساعدك في ضبط الخدمة: في الحالات الأكثر شيوعًا، كل ما تريد أن تفعله هو إسناد عناوين IP إسنادًا عشوائيًا، يمكن أن يُفعَل ذلك بالإعدادات الآتية: # minimal sample /etc/dhcp/dhcpd.conf default-lease-time 600; max-lease-time 7200; subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.150 192.168.1.200; option routers 192.168.1.254; option domain-name-servers 192.168.1.1, 192.168.1.2; option domain-name "mydomain.example"; }نتيجة الإعدادات السابقة هي ضبط خادوم DHCP لإعطاء العملاء عناوين IP تتراوح من 192.168.1.150 إلى 192.168.1.200، وسيُأجَّر عنوان IP لمدة 600 ثانية إذا لم يطلب العميل وقتًا محددًا؛ عدا ذلك، فسيكون وقت الإيجار الأقصى للعنوان هو 7200 ثانية؛ و«سينصح» الخادومُ العميلَ أن يستخدم 192.168.1.254 كبوابة افتراضية، و 192.168.1.1 و 192.168.1.2 كخادومَيّ DNS. عليك إعادة تشغيل خدمة dhcpd بعد تعديل ملف الضبط: sudo service isc-dhcp-server restartمصادرتوجد بعض المعلومات المفيدة في صفحة ويكي أوبنتو «dhcp3-server».للمزيد من خيارات ملف ‎/etc/dhcp/dhcpd.conf، راجع صفحة الدليل man dhcpd.conf.مقالة في ISC:‏ «dhcp-server».ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Dynamic Host Configuration Protocol - DHCP. حقوق الصورة البارزة: Designed by Freepik.

تطرقنا في الدرس السابق البدء مع محرر نصوص LibreOffice Writer إلى كيفية تثبيت حزمة أدوات المكتب LibreOffice واختيار اللغة العربية للواجهة، كما ألقينا نظرة على شريط أدوات محرر النصوص LibreOffice Writer. في هذا الدرس سنرى كيفية إعداد صفحة العمل في محرر النصوص. الاتجاه الطولي والعرضي للصفحة يُمكننا كتابة المُستندات في محرر النصوص LibreOffice Writer باتجاه طولي وآخر عرضي، الوضع الافتراضي للصفحة فور بدء البرنامج هو الاتجاه بالطول، وهو النمط الأكثر استخدامًا في أوراق البحث، الخطابات الرسميّة، الكتب، الحلقات الأكاديميّة وغيرها، بينما يُستخدم الاتجاه العرضي للصفحة بكتابة الإعلانات والمنشورات بشكلٍ أساسي. لتحديد اتجاه صفحات المُستند بالكامل نتّجه إلى القائمة: Format > Page ثم من علامة التبويب الصفحة Page انظر إلى الخانة الاتجاه Orientation. بشكلٍ افتراضي ستجد الخيار بالطول Portrait مُفعّلًا. اضغط على بالعرض Landscape لقلب جميع صفحات المُستند إلى الاتجاه العرضي. أما إذا كنتَ ترغب بقلب اتجاه صفحةٍ واحدة إلى العرض ضمن مُستندٍ طولي، ولنقل أنه لديك مُستند من أربع صفحات طوليّة الاتجاه، إلا أنّه يلزمك قلب الصفحة الثانية فقط إلى الاتجاه العرضي، لفعل ذلك اتّبع الأسلوب التالي: ضع مؤشّر الكتابة في نهاية الصفحة الأولى (آخر كلمة من السطر الأخير)، ثم من قائمة: Insert < Manual break ومن مربع الحوار الظاهر وتحت بند النوع Type اختر فاصل صفحات Page break، من القائمة المُنسدلة النمط Style اختر بالعرض Landscape. الآن ستجد بأنّ الصفحة الثانية باتت عرضيّة الاتجاه، لكن التأثير طُبّق أيضًا على الصفحات الثالثة والرابعة وهو ما لا نريده، لذا اتّجه مُجددًا إلى نهاية الصفحة الثانية وضع مؤشّر الفأرة هناك، ثم من قائمة: Insert > Manual break اختر فاصل صفحات Page break ومن قائمة النمط Style اختر النمط الافتراضي Default style. هكذا ستعود الصفحتان الثالثة والرابعة إلى الاتجاه الطولي، بينما تبقى الصفحة الثانية عرضيّة وهو ما نريده تمامًا. حجم الصفحة وهوامشها يأتي محرر النصوص Writer من ليبر أوفيس بإعداد افتراضي لحجم صفحة الكتابة يُسمى خطاب أو Letter وهو النمط الأكثر شيوعًا في الولايات المُتحدّة الأمريكيّة، إلا أنّ هذا قد يُسبّب لك مشاكل عند طباعة مُستنداتك في المكتبات العامّة أو حتى في المنزل، فغالبًا ما نستخدم ورق من مقاس A4 (الأوروبي) للطباعة في منطقتنا العربيّة، ومع اختلاف حجم الصفحة بين القالبين لن تحصل على نتيجة طباعة مثالية. لتغيير الإعداد الافتراضي للبرنامج نحتاج إلى العودة مُجددًا إلى صندوق تنسيق الصفحة Page من القائمة تنسيق Format، ومن علامة التبويب الصفحة Page اضبط القائمة المُنسدلة التنسيق Format إلى الخيار A4 ثم اضغط على تطبيق Apply. من ذات النافذة يُمكننا ضبط الهوامش الأربعة للصفحة بهدف الحصول على المزيد من المساحة البيضاء القابلة للكتابة أو العكس، لكن يجب الانتباه إلى أن عملية الطباعة تفرض قيودًا ماديّة على أصغر هوامش يُمكننا استخدامها، وفي حال تجاوز هذه القيود فسنحصل على رسالة خطأ قبيل إتمام عملية الطباعة تُفيد بضيق الهوامش وتُخيّرنا بين الطباعة على أيّة حال (ما يؤدّي إلى ضياع جزء من النصّ) أو تعديل الهوامش. في العموم يُمكن اعتبار هوامش "0.25 فأكثر؛ آمنة لمُعظم الطابعات. ملاحظة؛ يُمكننا تغيير واحدة قياس أبعاد الصفحة والهوامش من البوصة إلى أي واحدة أخرى من قائمة: Options > Tools ثم من القائمة الجانبية نختار LibreOffice Writer، بعد ذلك من قسم إعدادات General ومن أمام القائمة المُنسدلة Measurement Unit يُمكنك اختيار السنتيمتر centimeter أو ما شابه. تخطيط الصفحة ضمن صندوق حوار تنسيق الصفحة Page format السابق لدينا خيار آخر مُهم يتعلّق بأسلوب تخطيط الصفحات لا سيّما عندما يكون المُستند مُعدًّا لغرض الطباعة، فمن القائمة المُنسدلة تخطيط الصفحة Page layout سنجد لدينا أربعة خيارات: يمين ويسار Right and left، يُستخدم هذا الخيار عادةً مع الحلقات الأكاديميّة، الأبحاث، المُلخّصات إلخ عندما يُطبع على وجهي الورقة، بحيث تجمع أوراق المُستند بواسطة سلك معدني يسمح بطوي المادة. منعكس Mirrored، يُستخدم هذا التخطيط مع الكتب، عندما يُطبع على وجهي الورقة بينما تُجمع أوراق المُستند بالغراء أو الخياطة، بحيث نحصل على صفحتين مُتقابلتين دومًا في هذه الحالة يُمكننا تخصيص هوامش أوسع من الناحية الداخلية لأجل عملية التحرير المطبعي. يمين فقط Only right أو يسار فقط Only left يُستخدم مع المُستندات التي تُطبع فيها المواد على وجه واحد من وجهي الورقة، ويُحدد الخيار المناسب تبعًا للغة المُستند المُستخدمة إن كانت تُكتب من اليمين إلى اليسار (كالعربية)، أو من اليسار إلى اليمين (كالإنكليزيّة). الترويسة والتذييل رغم أن هوامش الصفحات هي اضطرار طباعي بالمقام الأوّل، إلا أنها تُعطي جمالية للصفحة علاوةً على إمكانية الاستفادة من هذه المساحات لإنشاء الترويسات والتذييل. الترويسة هي أي نصّ أو صورة يوضع ضمن الهامش العلوي للصفحة، بحيث يتكرّر في مجمل صفحات المُستند، ويقابله التذييل ضمن الهامش السفلي. يُمكن أن يُوضع ضمن الترويسة أو التذييل رقم الصفحة، اسم الكتاب أو الكاتب، شعار الموقع إلخ. لإدراج ترويسة للمُستند اتّبع ما يلي؛ من القائمة: Insert > Header > Default style سينتقل مؤشّر الإدخال مُباشرةً إلى رأس الصفحة الحاليّة. لنُدرج مثلًا رقم الصفحة كترويسة للصفحات، اكتب في منطقة الترويسة "الصفحة" ثم أضف مسافة فارغة، الآن من قائمة: Insert > Fields > Page number أدخل مسافة فارغة جديدة ثم اكتب "من"، وتوجّه مُجددًا إلى: Insert > Fields > Page count هكذا سنكون حصلنا على ترقيم شامل لجميع صفحات المُستند لدينا. بنفس الطريقة يُمكننا إدراج تذييل ما، أي من القائمة: Insert > Footer > Default style لنضع في التذييل مسار الملف كمثال، من القائمة: Insert > Fields > More fields الآن من النوع Type اختر اسم الملف File name ومن التنسيق Format اختر المسار/اسم الملف Path/File name. وهكذا سيظهر مسار الملف الذي نعمل عليه حاليًا في أسفل كل صفحة. الحدود والأعمدة من المزايا التحريريّة ضمن محرر ليبر أوفيس إمكانيّة إضافة حدود لنصوص الصفحات من ذات صندوق الحوار السابق تنسيق الصفحة Page format عبر علامة التبويب الحدود Borders. أسفل الخيار Line Arrangement يُمكنك انتقاء نمط الحدود المناسب؛ بلا حدود، وضع الحدود الأربعة، وضع الحدّين العلوي والسفلي، وضع الحدّين الجانبيين، وضع الحدّ الأيسر فقط. بالإضافة إلى إمكانية اختيار نمط الحدّ، لونه، حجمه، هوامشه عن النصّ، وأخيرًا إضافة ظلّ للحدّ عبر الخاصيّة Shadow Style. تُتيح لنا علامة التبويب التالية الأعمدة Columns تقسيم النصّ ضمن المُستند إلى عدّة أعمدة، يكثر استخدام هذا النمط في الجرائد والمجلات والدوريات الأخرى لا سيما عند استخدام حجم ورق أكبر من A4، من هذا اللسان يُمكنك اختيار عدد الأعمدة بالإضافة إلى عرض كل عمود وتباعده عن باقي الأعمدة. العلامة المائية واحدة من أكثر الميزات التحريريّة استخدامًا في المكتبات؛ وضع علامة مائية كخلفيّة لكل صفحة من المستند تُشير إلى المكتبة التي تحمل حقوق الطبع والبيع، أو تُبرز اسم الكاتب ورقم هاتفه إلخ. بكلّ الأحوال لفعل ذلك هناك أكثر من طريقة إحداها عن طريق مربع حوار تنسيق الصفحة Page format من علامة التبويب مساحة Area. لهذا الغرض يتوجّب علينا في البداية تحضير صورة مناسبة لاستخدامها كعلامة مائيّة، يُمكننا الاستعانة بأي برنامج تصميمي مثل Gimp، في حالتي هذه استخدمت تطبيق Draw الذي يأتي مع حزمة ليبر أوفيس. بكلّ الأحوال لا نحتاج إلى الكثير؛ فقط إنشاء مستند رسومي جديد مُطابق لقياس الصفحة (وهو في مثالنا هنا A4) ثم كتابة النصّ المطلوب بلون رمادي فاتح، يُمكننا تدويره قليلًا ووضعه بوسط الصفحة، ثم حفظ المُستند إلى لاحقة png. الآن من مربح الحوار السابق سنختار من القائمة المُنسدلة: Fill > Bitmap ومن الزر Import Graphic نختار الصورة السابقة ثم نضغط تطبيق، ليتم لصقها كخلفية لجميع الصفحات.

قد تكون محترفا تتقن استخدام خصائص شاشات إدارة ووردبريس (WordPress admin screens) ومتمرسا في العمل على هذه المنصة، إلا أن ذلك لن يمنع تواجد بعض الخاصيات التي لم تتعرف عليها بعد، والتي قد تحسن سيرورة العمل لديك بشكل كبير للغاية. تتميز شاشات إدارة ووردبريس بالتطور المستمر، فمع كل إصدار جديد يتمتع المدير (admin) بتحسينات، تعديلات وإضافات أكثر تقدما والتي يستهدف بعضها تطوير تجربة المستخدم (User Experience (UX والبعض الآخر تسهيل الولوج إلى الخصائص المتوافرة سابقا فضلا عن إضافة خصائص أخرى جديدة. مع مرور الوقت، يطور معظم مستخدمي ووردبريس أنماطهم الخاصة لكيفية تعاملهم مع شاشات الإدارة، قد تبقى هذه الأنماط على حالها رغم إضافة بعض الخصائص الجديدة، أما بالنسبة للمستخدمين الجدد فمن المحتمل أن لا تتاح لهم الفرصة للاطلاع على كل خصائص إدارة ووردبريس بشكل كامل ما يسبب تضييع فرصة التعرف على بعض الإمكانيات التي من شأنها أن تجعل الأمر أكثر بساطة. سأعمل في المقال التالي على التطرق لكل قسم من إدارة ووردبريس (WordPress admin) وإعطاء أمثلة لبعض الخصائص وأدوات التحكم التي قد تكون أغفَلتها والتي من شأنها أن تحسن سيرورة عملك. إن كنت تعرف مسبقا ما سأتطرق له فذلك أمر رائع، أما إن كان لديك أي اقتراحات أخرى فتفضل بالإشارة إليها في التعليقات. لوحة التحكم (The Dashboard) عدا بضع الخصائص التي يمكنك الولوج إليها باستخدام شاشة لوحة التحكم لا يوجد الكثير من ما قد تكون أغفلت، تجدر الإشارة إلى إمكانية الولوج إلى هذه الخصائص أيضا من خلال العديد من شاشات الإدارة الأخرى. ودجات لوحة التحكم (Dashboard Widgets) يوجد تبويب Screen Options في أعلى شاشة لوحة التحكم، يمكنك استخدامه لتفعيل وإلغاء تفعيل الودجات (widgets) كل واحدة على حدة. نظرا لأهمية تبويب Screen Options الكبرى سأعمل على التطرق له مرة أخرى في هذا الموضوع خلال الحديث عن أجزاء أخرى من لوحة التحكم. Help (الدعم) يمكنك أيضا الولوج إلى تبويب Help من خلال لوحة التحكم ما يوفر عليك عناء البحث في التوثيق (Codex): Updates (التحديثات) يمكنك من خلال إحدى شاشات لوحة التحكم الخاصة بموقعك القيام بتحديث كل شيء، بما في ذلك إصدار ووردبريس، القوالب والملحقات، لولوج هذه الخاصية: Updates < Dashboard Listing Screens (شاشات القوائم) تعمل شاشات القوائم على عرض قوائم منشوراتك، صفحاتك، محتويات الميديا فضلا عن أنواع المنشورات المخصصة، تتواجد في هذه الشاشات بضع أسرار أعتقد أنها على وجه الخصوص مفيدة للغاية. تغيير محتوى القوائم يمكنك أن تستخدم تبويب Screen Options لتغيير عدد المنشورات الذي يتم عرضه على إحدى شاشات القوائم، تكون هذه الخاصية أكثر فاعلية على شاشة تتضمن نتائج بحث ما، توفر هذه الامكانية عليك عناء تصفح العديد من الشاشات بغرض الوصول إلى مبتغاك فضلا عن المساعدة في القيام ببعض الإجراءات دفعة واحدة (bulk actions) ما سأتطرق له بعد قليل. يمكنك أيضا تغيير ما إن كان سيتم عرض التصنيفات (categories)، الوسوم (tags) فضلا عن التصنيفات المخصصة (custom taxonomies) في القوائم إلى جانب التعليقات. في ما يلي شاشة القوائم الافتراضية الخاصة بالمنشورات على موقع يتوفر على بضع تصنيفات مخصصة مضافة: وهنا نفس الشاشة بعد تغيير عدد المنشورات (Posts) والتصنيفات المخصصة المعروضة من خلال تبويب Screen Options : إجراءات الجملة (Bulk Actions) يمكنك القيام بإجراءات الجملة في العديد من شاشات القوائم ما يعني سهولة التعديل على عدة منشورات دفعة واحدة. للقيام بذلك، عليك بتحديد المنشورات التي تود التعديل عليها، تحديد Edit من قائمة Bulk Actions في الأعلى ثم الضغط على Apply: من هنا تستطيع تغيير حالة النشر (published status)، الأصناف (categories) وكاتب المنشور، يمكن أيضا استخدام قائمة Bulk Actions المنسدلة لحذف عدد كبير من المنشورات دفعة واحدة. شاشات التعديل على المنشورات تتواجد في شاشات التعديل على المنشورات (بما في ذلك المنشورات المخصصة إن قمت بإعدادها) بعض أدوات التحكم التي من المرجح أنك لم تستخدمها من قبل. الجدولة المتقدمة (Advance Scheduling) عوض ضرورة نشر منشوراتك في الحال، تستطيع أن تُجَدْوِلَهَا بشكل مسبق. تظهر أهمية هذه الخاصية بشكل كبير في حال ما إن كنت ستبتعد عن موقعك لفترة من الزمن لكنك ترغب في استمرار عرض محتوى جديد على موقعك، أو إن أردت نشر محتوى بشكل آلي في تاريخ معين. للقيام بذلك ما عليك إلا أن تضغط رابط Edit على يمين تاريخ النشر (publish date) وتقوم بتغييره. ملاحظة: لن تظهر المنشورات المجدولة للعرض في المستقبل إلا حين وصول تاريخ عرضها، أما تلك المجدولة في الماضي فستظهر في الحين لكن بتاريخ أقدم. المنشورات المثبتة (Sticky Posts) تتجلى أهمية خاصية Sticky Posts في تثبيت المنشورات أعلى صفحتك الرئيسية أو قائمة منشوراتك حتى وإن تم نشر أخرى جديدة، لتثبيت منشور ما، عليك بالضغط على Edit بجانب Visibility ثم وضع علامة في خانة: Stick this post to the front page. المنشورات الخاصة (Private Posts) إن قمت بنشر منشور ما وجعله خاصا (private)، سيتمكن فقط مدراء ومحررو الموقع الذين سجلوا دخولهم من مشاهدته عند تصفحهم واجهة موقعك (front end). يمكن لهذه الخاصية أن تكون نافعة للغاية إن أردت أن تتيح لهم إمكانية الولوج السريع لمنشور ما بغرض مراجعته أو صياغة خاتمة التوقيع قبل النشر. لجعل منشور ما خاصا اضغط على خاصية Private ، عند الضغط على Publish سيتم نشره لكن الولوج إليه لن يكون ممكنا لغير مديري الموقع والمحررين. تغيير كاتب المنشور تعتبر إمكانية تغيير كاتب منشور ما خاصية مهمة جدا في المدونات التي تتوفر على العديد من الكتاب، ما يعني أن أحد الكتاب يقوم بصياغة ونشر الموضوع وينسبه لكاتب آخر، تظهر أهمية القيام بذلك إن كان فقط أحد الكتاب قادرا على الولوج إلى الموقع في وقت ما أو إن كان شخص واحد يقوم بمعظم الكتابة لكنك تريد أن تظهر المواضيع موزعة بين عدد كبير من الكتاب. ضع علامة في خانة Author في تبويب Screen Options، ثم حدد الكاتب من القائمة المنسدلة أسفل المنشور، تتوفر هذه الخاصية فقط للمدراء والمحررين. شاشات التعديل على الصفحات توجد في شاشات التعديل على الصفحات بضع خصائص مفيدة والتي يمكن أن تكون أغفلتها كمستخدم حديث العهد بووردبريس. قوالب الصفحات يمكنك استخدام أي واحد من قوالب الصفحات المتوافرة في قالب ووردبريس الذي تستخدمه من خلال تحديدها من القائمة المنسدلة التي تتضمن قوالب الصفحات، حري بك أن تطلع على هذه الخاصية عند تفعيلك لقالب جديد لتكتشف ما يمكن أن يحتويه. ترتيب الصفحات (Page Parents) تستطيع أن تجعل صفحاتك مرتبة بشكل هرمي من خلال شاشة التعديل على الصفحات عن طريق جعل صفحة ما أعلى من أخرى في الترتيب أي كسابق أو أب لها (parent)، حدد الصفحة الأب من القائمة المنسدلة. مكتبة الميديا (The Media Library) تمت إضافة العديد من الخصائص الرائعة لشاشات مكتبة الميديا في الإصدار 4.0 من ووردبريس ما يجعل مشاهدة نوع محدد من هذا المحتوى بغرض التركيز عليه أمرا في غاية السهولة كما يمكن مشاهدة كل الصور ببساطة أكبر. عرض ملفات ذات صيغة محددة تتوفر إمكانية تحديد صيغة الملفات التي تريد مشاهدتها من خلال قائمة الصيغ المنسدلة أسفل قائمة الميديا، تتضمن الخيارات: الصور، الملفات الصوتية وملفات الفيديو. في ما يلي المظهر الافتراضي لمكتبة الميديا: وفي ما يلي عند عرض الصور فقط: العرض الشبكي يمكنك أن ترى صورك على شكل شبكة، الأمر الذي يتعود عليه مستخدمو برامج إدارة الصور، حدد أيقونة الشبكة أعلى قائمة الميديا: التحديد دفعة واحدة (Bulk Select) كما هو الأمر بالنسبة للمنشورات، يمكنك استخدام Bulk Select بالنسبة للميديا، ما يسمح لك بتحديد أي عدد من الصور تريد ثم حذفها، لا تتوافر إمكانية التعديل عليها دفعة واحدة بعد، لكن إن أردت أن تخفف من كم المحتوى في مكتبة الميديا بكل سهولة فستجد ضالتك في هذه الخاصية الجيدة لحذف العديد من الملفات دفعة واحدة. التعديل على الصور إن كنت متعودا على تعديل صورك باستخدام Photoshop قبل رفعها على ووردبريس فمن المحتمل أن تساعدك هذه الخاصية في تحسين سيرورة عملك، من المؤكد أنها ليست بشمولية فوتوشوب لكنها توفر لك كلا من حف الجوانب (cropping)، التدوير (rotating) وتغيير حجم الصور. يمكنك الولوج إلى هذه الشاشة لكل صورة سواء عند رفعها أو من خلال مكتبة الميديا: شاشات المظهر (Appearance) عرفت الشاشات في قسم Appearance من الإدارة العديد من التحسينات المهمة في الإصدارات الأخيرة، تستهدف العديد منها تسهيل الولوج ما يعني إمكانية التفاعل دونما الحاجة لاستعمال فأرة الحاسوب. مخصص القوالب عند تنصيب قالب جديد، لا تنس إلقاء نظرة عليه في مخصص القوالب (Theme Customizer)، بناء على ما تمت برمجته في القالب، قد يكون بإمكانك تغيير بعض العناصر مثل الألوان، التصميم (layout)، المحتوى وغير ذلك كثير. تعتبر هذه الخاصية ذات منفعة كبيرة خصوصا بالنسبة للمستخدمين الذين لا قبل لهم بالبرمجة من أجل التعديل على القالب بغرض جعله أكثر خصوصية وعلى المقاس. ملاحظة: منذ الإصدار 4.0 من ووردبريس تم إدماج الودجات في مخصص القوالب، إلا أن عرضها يتم بشكل منفصل عند الضغط عليها وذلك لتجنب الفوضى في مخصص القوالب. الودجات (Widgets) يمكنك الآن أن تقوم بالتعديل على الودجات دون الحاجة إلى القيام بسحبها ووضعها في أماكن الودجات، حدد الودجت التي تريد إضافته واختر المكان التي تريد أن تضعه فيه من خلال القائمة المنسدلة: توفر هذه الخاصية سهولة في الولوج نظرا لعدم الحاجة للتغيير بين الفأرة ولوحة المفاتيح. القوائم (Menus) قد تحاول في بعض الأحيان إضافة بعض المحتوى لقوائم التصفح إلا أنك لا تراه في القائمة على اليسار، في هذه الحالة اضغط على تبويب Screen Options وتأكد من تحديد كل أنواع المنشورات التي تحتاجها. يمكنك أيضا استخدام هذه الخاصية لإخفاء أنواع المنشورات ما يعتبر أمرا نافعا في حال إدارتك موقعا بعدة كتاب ورغبتك في عدم تواجد أنواع محددة من المحتوى في القائمة. عرفت شاشة القوائم أيضا تحديثات في ما يتعلق بسهولة الولوج ما يعني عدم الحاجة لسحب عناصر القائمة صعودا ونزولا على قائمة تصفح طويلة، لا تساهم هذه الخاصية في تحسين الولوج فحسب بل في الرفع من جودة تجربة المستخدم. اضغط على السهم الرمادي في يمين أحد عناصر القائمة، حدد من بين الخيارات الظاهرة ما تراه مناسبا. تعتبر إمكانية إضافة الروابط المخصصة كعناصر في قائمة التصفح من بين وظائف القوائم التي من المحتمل أن تكون أغفلتها، للقيام بذلك عليك باستخدام علبة الروابط على اليسار. تتجلى أهمية هذه الخاصية في إمكانية إضافة الروابط المؤدية إلى مواقع خارجية أو من أجل أرشفة الصفحات الغير المتضَمنة في عناصر قائمة التصفح: بمجرد إضافة رابط ما، يمكنك التعديل عليه كما هو الشأن بالنسبة لأي عنصر آخر من القائمة، من خلال إعطائه عنوانا وصفات مخصصة: شاشات الملحقات تتوفر شاشات عرض الملحقات على بعض الخيارات التي تساعدك في إيجاد الملحقات التي تريد العمل عليها بسرعة أكبر. أولا، يمكنك أن تشاهد الملحقات حسب الحالة، لذى إن كنت تبحث عن الملحقات المفعلة، غير المفعلة أو تلك التي تحتاج إلى تحديثات عليك فقط بتحديد الخيار من القائمة المتواجدة أعلى قائمة الملحقات. في الصورة أسفله تتواجد فقط الملحقات المفعلة. لديك أيضا إمكانية القيام ببعض الإجراءات دفعة واحدة، إن قمت باختيار مشاهدة الملحقات التي تتطلب التحديث، يمكنك القيام بتحديدها كلها ثم اختيار Update في القائمة المنسدلة Bulk Actions من أجل التحديث دفعة واحدة بشكل أسرع. شاشات المستخدمين في حين لا توجد الكثير من الخصائص المتخفية في هذه الشاشات، تعتبر إمكانية تغيير دور مستخدميك دفعة واحدة من خلال شاشة قوائم المستخدمين من بين الأمور التي من المحتمل أن تكون أغفلتها. يمكنك هنا تحديد كل المستخدمين الذين تود تغيير أدوارهم ثم اختيار دورهم الجديد، تكون هذه الخاصية نافعة جدا إن تطلبت بعض إجراءات الحماية منع بعض المستخدمين من الولوج لفترة معينة. تتوفر شاشات قوائم المستخدمين أيضا على قائمة منسدلة: Bulk Actions والتي تسمح لك بحذف العديد من المستخدمين إن أردت ذلك. شاشات الإعدادات نتطرق في الختام لبضع الخصائص المفيدة وغير المعروفة في شاشات الإعدادات: تستطيع تغيير التصنيف الافتراضي للمنشورات الجديدة إلى أحد تصنيفاتك عوض Uncategorized (غير مصنفة). يمكن لهذه الخاصية أن تكون مفيدة جدا كونها توفر عليك عناء تواجد العديد من المنشورات في تصنيف لا تستخدمه. هنالك بعض الإعدادات التي يمكنك العمل بها خارج شاشات الإعدادات (Settings screens)، في مخصص القوالب (Theme Customizer). تتضمن هذه الإعدادات عنوان الموقع ووصفه والصفحة الرئيسية، قد تتواجد أمور غير ذلك تبعا للقالب الذي تستخدمه: خلاصة تطرقنا فيما سبق إلى بعض خصائص إدارة ووردبريس والتي بدا لي أنها مفيدة أو تم اقتراحها علي من طرف بعض الأشخاص الآخرين والتي لا تتصف بسهولة إيجادها. رغم أني لن أتفاجئ إن كنت تعلم مسبقا عن بعض هذه الخاصيات إلا أنه من الوارد أن لا تكون قد صادفتها كلها أو قد يكون لديك بعض النصائح التي لم نشر إليها في هذا المقال. هل لديك أي نصائح أو طرق لاستعمال شاشات إدارة ووردبريس؟ تفضل رجاء بمشاركتنا إياها في التعليقات أسفله. ترجمة -وبتصرف- للمقال: The Power User’s Ultimate Guide to the WordPress Admin Area للكاتبة: RACHEL MCCOLLIN.

تطرّقنا في الدّرس السّابق إلى ضبط بسيط جدًا لـ VPN، يمكن للعميل الوصول إلى الخدمات على خادوم VPN عبر نفق مشفَّر؛ إذا أردت الوصول إلى المزيد من الخواديم أو أي شيء آخر على الشبكات الأخرى، فأعطِ العملاء بعض تعليمات التوجيه؛ على سبيل المثال، لو كان بالإمكان تلخيص شبكة شركتك بالنطاق 192.168.0.0/16؛ فيمكنك إعطاء هذا التوجيه إلى العملاء، لكن عليك أيضًا تغيير التوجيه لطريقة العودة، أي أن خادومك عليه أن يعرف طريقة العودة إلى شبكة عميل VPN. أو ربما تريد أن تعطي البوابة الافتراضية إلى جميع عملائك وترسل جميع البيانات الشبكية إلى بوابة VPN أولًا، ومن هناك إلى الجدار الناري للشركة ثم إلى الإنترنت؛ يوضح لك هذا القسم بعض الخيارات المتاحة أمامك. ضبط VPN موجه على الخادوم سيسمح إعطاء التوجيهات للعميل له بالوصول إلى شبكات فرعية أخرى خلف الخادوم؛ تذكر أن هذه الشبكات الفرعية يجب أن تعرف أن عليها إعادة توجيه الرزم التابعة لنطاق عناوين عميل OpenVPN ‏(10.8.0.0/24) إلى خادوم OpenVPN. push "route 10.0.0.0 255.0.0.0" ستضبط التعليمة السابقة جميع العملاء كي يعيدوا توجيه بوابة الشبكة الافتراضية عبر VPN، مما يؤدي إلى مرور جميع بيانات الشبكة كتصفح الويب أو طلبات DNS عبر VPN (خادوم OpenVPN أو الجدار الناري المركزي عندك الذي يحتاج إلى تمرير بطاقة TUN/TAP إلى الإنترنت لكي يعمل ذلك عملًا صحيحًا). اضبط نمط الخادوم ووفر شبكة VPN فرعية لكي يسحب OpenVPN عناوين العملاء منها؛ سيأخذ الخادوم العنوان 10.8.0.1 لنفسه، والبقية ستتوفر للعملاء؛ وكل عميل سيقدر على الوصول إلى الخادوم عبر 10.8.0.1. ضع تعليقًا قبل هذا السطر إذا كنت تستخدم جسر إيثرنت (ethernet bridging): server 10.8.0.0 255.255.255.0 حافظ على سجل لارتباطات عناوين IP للعملاء في هذا الملف؛ إذا توقف OpenVPN عن العمل أو أعيد تشغيله، فإن العملاء الذي سيعيدون إنشاء الاتصال سيُسنَد لهم نفس عنوان IP المُسنَد لهم سابقًا. ifconfig-pool-persist ipp.txt أضف خواديم DNS إلى العميل: push "dhcp-option DNS 10.0.0.2" push "dhcp-option DNS 10.1.0.2" اسمح بالتواصل من العميل إلى العميل: client-to-client تفعيل الضغط على خط VPN: comp-lzo تؤدي التعليمة keepalive بإرسال شبيهة برسائل ping مرارًا وتكرارًا عبر الخط الذي يصل بين الجانبين، لذلك سيعلم كل جانب متى ينقطع الاتصال عن الجانب الآخر؛ السطر الآتي سيرسل ping كل 1 ثانية، بافتراض أن الند البعيد سيكون متوقفًا إذا لم يَرِد رد على الرسالة خلال مدة 3 ثواني: keepalive 1 3 فكرةٌ جيدةٌ هي تقليص امتيازات عفريت OpenVPN بعد التهيئة: user nobody group nogroup يتضمن OpenVPN 2.0 خاصية تسمح لخادوم OpenVPN بالحصول الآمن على اسم مستخدم وكلمة مرور من العميل المتصل، ويستخدم هذه المعلومات كأساس للاستيثاق بالعميل؛ لاستخدام طريقة الاستيثاق هذه، أولًا أضف تعليمة auth-user-pass إلى ضبط العميل؛ التي ستوجه عميل OpenVPN لطلب اسم مستخدم وكلمة مرور، وتمريرها إلى الخادوم عبر قناة TLS آمنة. # client config! auth-user-pass هذا سيخبر خادوم OpenVPN أن يتحقق من اسم المستخدم وكلمة المرور المُدخَلة من العملاء باستخدام واحدة PAM لتسجيل الدخول؛ وهذا يفيد في حالة كان عندك آلية مركزية للاستيثاق مثل Kerberos. plugin /usr/lib/openvpn/openvpn-auth-pam.so login ضبط متقدم لخدمة VPN جسرية على الخادوم يمكن إعداد OpenVPN لكي يعمل بنمط VPN جسري (bridged VPN) أو موجَّه (routed VPN)؛ أحيانًا يُشار لذلك بخدمة VPN تعمل بالطبقة الثانية أو الثالثة من OSI؛ في VPN جسري، جميع الإطارات (frames) الشبكية تكون من الطبقة الثانية (layer-2)، أي جميع إطارات إيثرنت تُرسَل إلى شركاء VPN‏ (VPN partners)؛ بينما تُرسَل الرزم الشبكية من الطبقة الثالثة فقط إلى شركاء VPN‏ (VPN Partners)؛ في النمط الجسري، ستُرسَل جميع البيانات الشبكية بما التي تكون شبيهة بشبكة LAN مثل طلبات DHCP، و طلبات ARP ...إلخ إلى شركاء VPN، لكن في النمط الموجه، سيتم تجاهل تلك الرزم. تحضير ضبط بطاقة شبكية لإنشاء جسر على الخادوم تأكد من أن لديك الحزمة bridge-utils: sudo apt-get install bridge-utils قبل أن تضبط OpenVPN في النمط الجسري، عليك تغيير ضبط بطاقات الشبكة؛ لنفترض أن لدى خادومك بطاقة اسمها eth0 موصولة إلى الإنترنت، وبطاقة باسم eth1 موصولة إلى شبكة LAN التي تريد إنشاء جسر لها؛ سيبدو ملف ‎/etc/network/interfaces كما يلي: auto eth0 iface eth0 inet static address 1.2.3.4 netmask 255.255.255.248 default 1.2.3.1 auto eth1 iface eth1 inet static address 10.0.0.4 netmask 255.255.255.0 هذا ضبط بسيط للبطاقة ويجب أن يُعدَّل لكي يغيَّر إلى النمط الجسري حيث تتحول البطاقة eth1 إلى بطاقة br0 الجديدة؛ بالإضافة إلى أننا ضبطنا br0 لتكون البطاقة الجسرية للبطاقة eth1؛ علينا التأكد أن البطاقة eth1 دومًا في نمط تمرير الحزم: auto eth0 iface eth0 inet static address 1.2.3.4 netmask 255.255.255.248 default 1.2.3.1 auto eth1 iface eth1 inet manual up ip link set $IFACE up promisc on auto br0 iface br0 inet static address 10.0.0.4 netmask 255.255.255.0 bridge_ports eth1 يجب أن تشغِّل الآن تلك البطاقة؛ تحضَّر لأن هذا قد لا يعمل كما هو متوقع، وستفقد التحكم عن بعد؛ تأكد أنك تستطيع حل المشاكل بالوصول إلى الجهاز محليًا. sudo ifdown eth1 && sudo ifup -a إعداد ضبط الخادوم للجسر عدِّل الملف ‎/etc/openvpn/server.conf، مغيّرًا ما يلي من الخيارات إلى: ;dev tun dev tap up "/etc/openvpn/up.sh br0 eth1" ;server 10.8.0.0 255.255.255.0 server-bridge 10.0.0.4 255.255.255.0 10.0.0.128 10.0.0.254 ثم أنشِئ سكربتًا مساعدًا لإضافة البطاقة tap إلى الجسر، وللتأكد من أن eth1 في وضع تمرير الحزم؛ أنشِئ الملف ‎/etc/openvpn/up.sh: #!/bin/sh BR=$1 ETHDEV=$2 TAPDEV=$3 /sbin/ip link set "$TAPDEV" up /sbin/ip link set "$ETHDEV" promisc on /sbin/brctl addif $BR $TAPDEV ثم اجعل السكربت تنفيذًا: sudo chmod 755 /etc/openvpn/up.sh بعد ضبط الخادوم، عليك إعادة تشغيل خدمة openvpn بإدخال الأمر: sudo service openvpn restart ضبط العميل أولًا، ثبِّت openvpn على العميل: sudo apt-get install openvpn ثم بعد أن يكون الخادوم مضبوطًا، وشهادات العميل منسوخةً إلى ‎/etc/openvpn؛ فأنشِئ ملف ضبط للعميل بنسخ المثال، وذلك بإدخال الأمر الآتي في طرفية جهاز العميل: sudo cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf \ /etc/openvpn عدِّل الملف ‎/etc/openvpn/client.conf مغيّرًا الخيارات الآتية: dev tap ;dev tun ca ca.crt cert client1.crt key client1.key في النهاية، أعد تشغيل openvpn: sudo service openvpn restart يجب الآن أن تستطيع الوصول إلى شبكة LAN البعيدة عبر VPN. نسخ عميل OpenVPN الواجهة الرسومية لإدارة الشبكة في لينكس تأتي أغلبية توزيعات لينُكس بما فيها توزيعة أوبنتو للأجهزة المكتبية على برمجية «مدير الشبكة»، الذي هو واجهة رسومية جميلة لإدارة خيارات الشبكة؛ يمكنك أيضًا إدارة اتصالات VPN منها؛ تأكد أن لديك الحزمة network-manager-openvpn مثبتةً، ستلاحظ هنا أن تثبيتها سيثبِّت حزمًا أخرى مطلوبة: sudo apt-get install network-manager-openvpn لإعلام برمجية «مدير الشبكة» بتثبيت الحزم الجديدة، عليك إعادة تشغيله: restart network-manager network-manager start/running, process 3078 في واجهة مدير الشبكة، اختر لسان VPN واضغط على زر "إضافة"، ثم اختر OpenVPN كنوع خدمة VPN ثم اضغط على «إنشاء»، في النافذة التالية أضف اسم خادوم OpenVPN «كبوابة»، واختر «النوع» إلى «شهادات (TLS)» ثم وجِّه «شهادة المستخدم» إلى شهادتك، و «شهادة CA» إلى سلطة الشهادات التي تعتمدها، و «المفتاح الخاص» إلى ملف مفتاحك الخاص، استخدم الزر «خيارات متقدمة» لتفعيل الضغط أو غيره من الخيارات الخاصة التي ضبطتها على الخادوم؛ جرِّب الآن إنشاء اتصال عبر VPN. برمجية Tunnelblick للاتصال بخدمة OpenVPN مع واجهة رسومية لأنظمة ماك OS X إن Tunnelblick هو نسخة ممتازة حرة مفتوحة المصدر لواجهة رسومية لعميل OpenVPN لنظام ماك؛ نزِّل آخر نسخة من المثبِّت من الموقع الرسمي وثبتِّها؛ ثم ضع ملف الضبط client.ovpn مع الشهادات والمفاتيح سويةً في ‎ ‎/Users/username/Library/Application Support/Tunnelblick/Configurations/‎ ثم شغِّل Tunnelblick من مجلد «التطبيقات» لديك. # sample client.ovpn for Tunnelblick client remote blue.example.com port 1194 proto udp dev tun dev-type tun ns-cert-type server reneg-sec 86400 auth-user-pass auth-nocache auth-retry interact comp-lzo yes verb 3 ca ca.crt cert client.crt key client.key واجهة رسومية لعميل OpenVPN لويندوز نزِّل وثبِّت آخر نسخة من عميل OpenVPN لويندوز؛ يمكنك تثبيت واجهة رسومية اختيارية باسم OpenVPN Windows GUI؛ ثم عليك تشغيل خدمة OpenVPN، وذلك بالذهاب إلى «ابدأ - جهاز الكومبيوتر - إدارة - الخدمات» و «التطبيقات - الخدمات»، ثم اعثر على خدمة OpenVPN وشغِّلها، ثم اضبط نمط التشغيل إلى «تلقائي»؛ وعندما تشغِّل OpenVPN MI GUI لأول مرة، فعليك تشغيله كمدير؛ وذلك بالنقر عليه بالزر الأيمن وانتقاء الخيار المناسب. سيتوجب عليك كتابة ملف ضبط OpenVPN إلى ملف نصي ووضعه في C:\Program Files\OpenVPN\config\client.ovpn مع شهادة CA؛ وعليك وضع شهادة المستخدم في مجلد المنزل للمستخدم كما في المثال الآتي: # C:\Program Files\OpenVPN\config\client.ovpn client remote server.example.com port 1194 proto udp dev tun dev-type tun ns-cert-type server reneg-sec 86400 auth-user-pass auth-retry interact comp-lzo yes verb 3 ca ca.crt cert "C:\\Users\\username\\My Documents\\openvpn\\client.crt" key "C:\\Users\\username\\My Documents\\openvpn\\client.key" management 127.0.0.1 1194 management-hold management-query-passwords auth-retry interact ; Set the name of the Windows TAP network interface device here dev-node MyTAP وإذا لم ترد الاستيثاق من المستخدم أو كنت تريد تشغيل الخدمة دون تفاعله، فأضف تعليقًا قبل الخيارات الآتية: auth-user-pass auth-retry interact management 127.0.0.1 1194 management-hold management-query-passwords استخدام OpenVPN مع OpenWRT يوصف OpenWRT أنه توزيعة لينُكس للأجهزة المدمجة مثل موجهات WLAN؛ هنالك بعض الأنواع من تلك الموجهات التي أُعدَّت لتشغيل OpenWRT؛ بالاعتماد على الذاكرة المتوفرة في الموجه لديك، ربما تتمكن من تشغيل برمجيات مثل OpenVPN ويمكنك بناء موجه لمكتب فرعي مع إمكانية الاتصال عبر VPN إلى المكتب الرئيسي. سجِّل دخولك إلى OpenWRT وثبِّت OpenVPN: opkg update opkg install openvpn تفقَّد الملف ‎/etc/config/openvpn وضع ضبط العميل هناك؛ وانسخ الشهادة والمفاتيح إلى ‎/etc/openvpn: config openvpn client1 option enable 1 option client 1 # option dev tap option dev tun option proto udp option ca /etc/openvpn/ca.crt option cert /etc/openvpn/client.crt option key /etc/openvpn/client.key option comp_lzo 1 أعد تشغيل OpenVPN: service openvpn restart عليك أن ترى إذا كان عليك تعديل إعدادات الجدار الناري والتوجيه في موجهك. مصادر راجع موقع OpenVPN لمزيد من المعلومات. راجع كتاب «OpenVPN hardening security guide». أيضًا، الكتاب المنشور من Pakt باسم «OpenVPN: Building And Integration Virtual Private Networks» هو مرجع جيد. ترجمة -وبتصرف- للمقال Ubuntu Server Guide: OpenVPN.

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

إنّ CloudFlare هي عبارة عن شركة تزوّدنا بشبكة تسليم محتوى (content delivery network (CDN وخدمات DNS مُوزَّعة من خلال العمل كوسيط عكسي reverse proxy لمواقع الإنترنت، من الممكن استخدام خدمات CloudFlare المجانيّة والمدفوعة لتحسين الأمان، السرعة، والتوفّر availability للموقع بطرق عديدة، سنشرح في هذا الدّرس كيفيّة استخدام خدمة tier المجانيّة لـ CloudFlare لحماية خادوم الويب ضدّ هجمات DDoS الجارية المعتمدة على HTTP عن طريق تمكين الوضع "أنا تحت الهجوم" "I'm Under Attack Mode"، يُخفِّف وضع الأمان هذا من هجمات DDoS من خلال تقديم صفحة وسيطة للتحقق من شرعيّة الاتصال قبل تمريره إلى خادوم الويب لدينا. المتطلبات الأساسيةيفترض هذا الدّرس أنّك تمتلك ما يلي: خادوم ويب.نطاق Domain مُسجَّل يُشير إلى خادوم الويب لدينا.نفاذ إلى لوحة التحكّم لمسجّل النطاق الذي أصدر النطاق.يجب قبل المتابعة أيضًا التسجيل Sign up من أجل حساب CloudFlare، فلنلاحظ أنّ هذا الدرس يتطلّب استخدام أسماء خواديم CloudFlare. إعداد النطاق لاستخدام CloudFlareيجب قبل أن نستخدم أي من ميّزات CloudFlare أن نقوم بإعداد النّطاق لدينا ليستخدم DNS التّابع لـ CloudFlare. إن لم نفعل هذا مُسبقًا نقوم بتسجيل الدخول إلى CloudFlare. إضافة موقع ومسح Scan تسجيلات DNS Recordsبعد تسجيل الدخول سيتم أخذنا إلى صفحة البدء Get Started with CloudFlare، وهنا يجب إضافة موقعنا إلى CloudFlare: نُدخِل اسم النّطاق الذي نريد استخدام CloudFlare معه ونضغط على زر بدء المسح Begin Scan، ينبغي أن يتم نقلنا إلى صفحة تشبه ما يلي: سيستغرق هذا حوالي دقيقة، وعندما يكتمل نضغط زر المتابعة Continue. تُظهِر الصفحة التالية نتائج مسح تسجيلات DNS، نتحقّق من أنّ تسجيلات DNS الحاليّة موجودة لأنّها التسجيلات التي ستستخدمها CloudFlare لتحليل resolve الطلبات إلى نطاقنا، استخدمنا في مثالنا cockroach.nyc كنطاق: نلاحظ أنّه من أجل تسجيلات A وCNAME التي تشير إلى خادوم الويب لدينا، يجب أن يملك عمود الحالة Status غيمة برتقاليّة مع سهم يمر من خلالها، والذي يشير إلى أنّ حركة مرور البيانات traffic ستتدفق من خلال وسيط CloudFlare العكسي قبل أن تصل إلى خادومنا أو خواديمنا. نختار بعدها خطّة CloudFlare plan، سنستخدم في هذا الدّرس خيار الخطّة المجانية Free plan، إن كنت ترغب بالدفع لأجل خطة أخرى توفّر لك ميزات CloudFlare إضافيّة تستطيع فعل ذلك: تغيير أسماء الخواديم Nameservers لديناتعرض الصفحة التالية جدولًا لأسماء الخواديم الحالية لنطاقنا والأسماء التي ينبغي تغييرها لها، يجب تغيير اثنين منهما إلى أسماء خواديم CloudFlare، أمّا بقية المُدخلات يجب إزالتها، وهذا مثال عمّا يجب أن تكون عليه الصفحة لديك إن كنت تستخدم أسماء خواديم DigitalOcean : لتغيير أسماء خواديم نطاقنا نسجّل الدخول إلى لوحة تحكّم مُسجّل النطاق domain registrar ونقوم بالتغييرات التي عرضها لنا CloudFlare، على سبيل المثال إن كُنّا قد اشترينا نطاقنا عبر مُسجِّل مثل GoDaddy أو NameCheap سنحتاج لتسجيل الدخول إلى لوحة تحكّم الملائمة لهذا المُسجِّل ونقوم بالتغييرات هناك. تتفاوت العمليّة بحسب مُسجِّل النطاق الخاص بنا، وإن لم تعرف كيفيّة القيام بها فهي مشابهة للعمليّة الموصوفة في كيف نشير إلى أسماء خواديم DigitalOcean من مُسجِّلات النطاق الشائعة عدا أنّك ستستخدم أسماء خواديم CloudFlare بدلًا من تلك الخاصة بـ DigitalOcean. يستخدم النطاق في حالة هذا المثال أسماء خواديم DigitalOcean ونحتاج إلى تحديثه لكي يستخدم DNS الخاص بـ CloudFlare، تمّ تسجيل هذا النّطاق باستخدام NameCheap لذلك هذا هو المكان الذي يجب أن نذهب إليه لتحديث أسماء الخواديم. نضغط على زر المتابعة Continue بعد الانتهاء من تغيير أسماء الخواديم لدينا، قد يستغرق حتى 24 ساعة ليتم تبديل أسماء الخواديم ولكن عادة ما يتم ذلك في غضون عدّة دقائق. انتظار أسماء الخواديم حتى يتم تحديثهاولأنّ تحديث أسماء الخواديم يستغرق وقت غير معروف فمن المحتمل أن نرى هذه الصفحة بعد ذلك: تعني الحالة قيد الانتظار Pending أنّ CloudFlare تنتظر تحديث أسماء الخواديم إلى الأسماء المطلوبة (على سبيل المثال olga.ns.cloudflare.com وrob.ns.cloudflare.com)، إن قمت بفعل ذلك فكل ما عليك الآن هو الانتظار والتحقّق لاحقًا من أجل الحالة نشيط Active، إن ضغطنا على الزر Recheck Nameservers أو انتقلنا إلى لوحة تحكّم CloudFlare فستقوم بالتحقّق من أنّ أسماء الخواديم قد تمّ تحديثها. حالة CloudFlare نشيطة Activeحالما يتم تحديث أسماء الخواديم سيستخدم النطاق DNS الخاص بـ CloudFlare وسنرى أنّه أصبح يمتلك الحالة نشيط Active، مثل ما يلي: يعني هذا أنّ CloudFlare يعمل كوسيط عكسي لموقعنا، وأنّنا نملك النفاذ للميّزات المتاحة في الخطة التي سجلّناها، إن كُنّا نستخدم الخطة المجانيّة Free كما فعلنا في هذا الدّرس فسنملك النفاذ لبعض الميّزات التي تُحسِّن أمان موقعنا وسرعته وتوفّره، لن نُغطّي هنا جميع الميّزات لأنّنا نركّز على التخفيف من هجمات DDoS، ولكنّها تتضمّن CDN، SSL، التخزين المؤقت للمحتوى الثابت static content caching، الجّدار الناري Firewall (قبل أن تصل حركة مرور البيانات إلى خادومنا)، وأدوات تحليل حركة مرور البيانات traffic analytics tools. نلاحظ أيضًا أنّ ملخّص الإعدادات Settings Summary الموجودة تحت نطاقنا يُظهِر مستوى الأمان الحالي لموقعنا (متوسّط medium افتراضيًّا) وبعض المعلومات الأخرى. للحصول على أقصى استفادة من CloudFlare قد ترغب قبل المتابعة باتّباع هذا الدّليل: الخطوات الأولى المُوصى بها لجميع مستخدمي CloudFlare، وهذا ضروري للتأكّد من أنّ CloudFlare ستسمح بالاتصالات الشرعيّة من الخدمات التي نرغب بالسّماح بها، وأنّ سجلّات خادوم الويب لدينا ستظهر عناوين IP الأصليّة للزوار (بدلًا من عناوين IP الوسيط العكسي لـ CloudFlare). بعد أن ننتهي من إعداد كل هذا سنلقي نظرة على إعدادات الوضع "أنا تحت الهجوم" "I'm Under Attack Mode" في جدار CloudFlare النّاري. الوضع "أنا تحت الهجوم" I'm Under Attack Modeيتم تعيين أمان جدار CloudFlare النّاري افتراضيًّا إلى متوسّط Medium، يوفّر هذا بعض الحماية ضدّ الزوّار المُصنّفين كتهديد معتدل عن طريق إظهار صفحة تحدّي challenge page قبل السّماح لهم بالمتابعة إلى موقعنا، ومع ذلك إن كان موقعنا هدفًا لهجمات DDoS فلن يكون هذا كافيًا لإبقاء موقعنا يعمل، وفي هذه الحالة ربّما يكون الوضع I'm Under Attack Mode مناسبًا لنا. إن قمنا بتمكين هذا الوضع سيتم عرض صفحة وسيطة لأي زائر لموقعنا تقوم بتنفيذ بعض التحقّقات من المتصفّح وتُؤخِّر الزائر لمدة 5 ثوان قبل تمريره إلى خادومنا، سيبدو هذا مشابهًا لما يلي: إن مرّت التحقّقات بنجاح سيتم السّماح للزائر بالوصول لموقعنا، ويكون عادةً مزيج المنع والتأخير للزوّار من الاتصال إلى موقعنا كافيًا لإبقائه قيد التشغيل حتى خلال هجمات DDoS. ملاحظة: يجب أن تكون JavaScript و Cookies مُمكَّنة لدى زوّار الموقع لكي يتجاوزوا الصفحة الوسيطة، وإن لم يكن هذا مقبولًا يجب النظر في استخدام إعدادات أمان الجّدار الناري العالية "High" بدلًا من ذلك. فلنبقِ في ذهننا أنّه يجب تمكين الوضع I'm Under Attack Mode فقط عندما يكون الموقع ضحيّة لهجمات DDoS، فيما عدا ذلك يجب إطفاؤه كي لا يُؤخِّر المستخدمين الطبيعيّين من النفاذ للموقع بدون سبب. كيفية تمكين الوضع I'm Under Attack Modeأبسط طريقة لتمكين هذا الوضع هي الذهاب إلى صفحة نظرة عامّة Overview في CloudFlare (وهي الصفحة الافتراضيّة) واختياره من قائمة إجراءات سريعة Quick Actions: ستتحوّل إعدادات الأمان فورًا إلى حالة I'm Under Attack، وسيتم الآن عرض صفحة CloudFlare الوسيطة لأي زائر كما تحدّثنا سابقًا. كيفية تعطيل الوضع I'm Under Attack Modeبما أنّه يجب استخدام هذا الوضع فقط في حالات الطوارئ وهجمات DDoS فينبغي علينا تعطيله عندما لا نكون تحت الهجوم، ولفعل هذا نذهب إلى صفحة نظرة عامّة Overview في CloudFlare ونضغط على الزر تعطيل Disable: نختار بعدها مستوى الأمان الذي نرغب بالتحويل إليه، الوضع الافتراضي والمُفضَّل هو متوسّط Medium: يجب أن يعود موقعنا إلى حالة نشيط Active وأن يتم تعطيل صفحة حماية DDoS. الخاتمةالآن وقد أصبح موقعنا يستخدم CloudFlare أصبحنا نملك أداة أخرى لحمايته بسهولة من هجمات DDoS المُعتمدة على HTTP، هنالك أيضًا مجموعة من الأدوات الأخرى التي توفّرها CloudFlare والتي قد نرغب بإعدادها، مثل شهادات SSL المجانيّة، ولهذا من المُفضَّل أن تقوم باستكشاف الخيارات وترى ما هو مفيد لك. حظًّا طيّبًا ! ترجمة -وبتصرّف- لـ How To Mitigate DDoS Attacks Against Your Website with CloudFlare لصاحبه Mitchell Anicas.

بالرّغم من أنّ الاتصال إلى الخادوم عبر SSH آمن جدًّا، فإنّ SSH daemon (وهو عمليّة تعمل في خلفيّة النّظام بشكل دائم) بحدّ ذاتها هي خدمة يجب تعريضها إلى الإنترنت لتعمل بشكل صحيح، ويأتي هذا مع بعض المخاطر الكامنة ويخلق ناقلات للهجوم لأي مهاجمين مُحتَملين. إنّ أي خدمة مُعرّضة إلى الشّبكة هي هدف مُحتمل بهذه الطريقة، فإذا ألقينا انتباهنا إلى سجلّات التطبيق لهذه الخدمات سنجد محاولات مُنظّمة ومتكرّرة لتسجيل الدخول والتي تُمثّل هجمات بالقوّة القاسية Brute force attacks عن طريق مستخدمين أو روبوتات bots على حدٍّ سواء. يُمكن الحد من هذه المشكلة عن طريق خدمة تُدعى fail2ban والتي تقوم بإنشاء قواعد تستطيع تبديل إعدادات جدار حماية iptables بناءً على عدد معرّف مُسبقًا من محاولات تسجيل الدخول غير النّاجحة، يسمح هذا لخادومنا بالاستجابة لمحاولات النّفاذ غير الشّرعية من دون أي تدخّل منّا. سنغطّي في هذا الدّرس كيفيّة تثبيت واستخدام fail2ban على خادوم Ubuntu. تثبيت Fail2Ban على Ubuntuإنّ عمليّة التثبيت لهذه الأداة بسيطة لأنّ فريق تحزيم Ubuntu يُحافِظ على الحِزمة Package في المستودعات الافتراضيّة default repositories. نحتاج في البداية لتحديث دليل الحِزَم المحلّي local package index لدينا، وبعدها نستطيع استخدام apt لتنزيل وتثبيت الحِزمة: sudo apt-get update sudo apt-get install fail2banإنّ عملية التثبيت بديهيّة كما نرى، نستطيع الآن البدء بإعداد الأداة لاستخدامنا الشّخصي. إعداد Fail2Ban مع إعدادات الخدمة الخاصة بناتحتفظ خدمة fail2ban بملفّات إعداداتها في الدّليل etc/fail2ban/، يوجد ملف مع إعدادات افتراضيّة يُدعى jail.conf. ولأنّه يُمكن أن يتم تعديل هذا الملف عن طريق ترقية الحِزَم لذلك لا ينبغي علينا تحرير هذا الملف في مكانه، بل من الأفضل أن نقوم بنسخه حتى نستطيع القيام بتغييراتنا بأمان. نحتاج لنسخه إلى ملف يُدعى jail.local حتى يستطيع fail2ban إيجاده: sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.localحالما يتم نسخ الملف بإمكاننا فتحه للتحرير لنرى كيف يعمل كل شيء: sudo nano /etc/fail2ban/jail.localيوجد في هذا الملف القليل من الإعدادات التي قد نرغب بضبطها، يتم تطبيق هذه الإعدادات الموجودة تحت قسم [DEFAULT] على جميع الخدمات المُمَكَّنة enabled من أجل fail2ban الذي لا يتم تجاوزه في القسم الخاص بالخدمة: ignoreip = 127.0.0.1/8نستطيع ضبط مصدر العناوين التي يتجاهلها fail2ban عن طريق إضافة قيمة إلى المُعامِل parameter ignoreip. يتم ضبطه افتراضيًّا بأن لا يقوم بمنع أي نقل للبيانات traffic قادم من الجهاز المحلّي، نستطيع إضافة المزيد من العناوين التي نريد تجاهلها عن طريق إلحاقها بنهاية هذا المُعامِل مع الفصل بينها بفراغ Space. bantime = 600يقوم المُعامِل bantime بتعيين المُدّة الزمنيّة التي سيتم خلالها حظر العميل عندما يفشل بالاستيثاق authenticate بشكلٍ صحيح، يتم قياس هذا المُعامِل بالثّواني، وقيمته الافتراضيّة هي 600 ثانية أي 10 دقائق. findtime = 600 maxretry = 3ومن المُعامِلات التي نرغب أن نلقي لها انتباهًا نجد المُعامِلَين findtime و maxretry، وهما يعملان معًا لتأسيس الشّروط التي نستطيع بناءً عليها اعتبار عميل ما مستخدمًا غير قانونيٍ يجب علينا حظره. يقوم المُتغيّر maxretry بتعيين عدد المحاولات التي يجب خلالها أن يقوم العميل بالاستيثاق خلال فترة زمنيّة مُعرّفة بـ findtime وذلك قبل أن يتمّ حظره، تقوم الإعدادات الافتراضيّة لخدمة fail2ban بحظر العميل الذي يقوم بثلاث محاولات غير ناجحة لتسجيل الدخول خلال فترة 10 دقائق. destemail = root@localhost sendername = Fail2Ban mta = sendmailومن بعض الإعدادات الأخرى التي قد نرغب بتعديلها نجد الإعدادات destemail، sendername، و mta إن أردنا ضبط تنبيهات alerts البريد الإلكتروني، يقوم المُعامِل destemail بتعيين عنوان البريد الإلكتروني الذي سيستقبل رسائل الحظر، يقوم المُعامِل sendername بتعيين قيمة الحقل From في البريد الإلكتروني، يُحدّد المُعامِل mta خدمة البريد الإلكتروني التي سيتم استخدامها لإرسال البريد. action = $(action_)sيضبط هذا المُعامل الإجراءات التي يتّخذها fail2ban عندما يريد إقامة حظر، إنّ القيمة _action مُعرَّفة في الملف قبل هذا المُعامِل بقليل، الإجراء الافتراضي هو ببساطة أن يتم ضبط الجّدار النّاري firewall لكي يرفض نقل البيانات من المُضيف Host المُهاجِم حتى تنتهي مُدّة الحظر. إن أردنا ضبط تنبيهات البريد الإلكتروني نستطيع تغيير القيمة من _action إلى action_mw، وإن كُنّا نرغب أن يقوم البريد الإلكتروني بتضمين سطور السّجلات المُتعلّقة بذلك نستطيع تغييرها إلى action_mwl، يجب أن نتأكّد من أنّه يتم ضبط إعدادات البريد المُناسبة إن اخترنا استخدام تنبيهات البريد. 1. إعدادات Jail الفرديةلقد وصلنا أخيرًا إلى الجزء من ملف الإعدادات الذي يتعامل مع الخدمات الفرديّة، والتي يتم تحديدها في القسم headers مثل [SSH]. نستطيع تمكين كل واحد من هذه الأقسام عن طريق تعديل أو إضافة السّطر enabled وتعيينه إلى true: enabled = trueنجد بشكل افتراضي أنّ خدمة SSH مُمكّنة وباقي الخدمات مُعطّلة. تعمل هذه الأقسام عن طريق استخدام القيم الافتراضيّة التي عرّفناها مُسبقًا، وإن أردنا تجاوز override أي قيم نستطيع فعل ذلك في قسم الخدمات، أمّا إن أردنا استخدام القيم الافتراضيّة فلا داعي لإضافة أي شيء. ومن الإعدادات الأخرى التي يُمكن تعيينها هنا هي filter والذي يستخدم ليحدّد إذا ما كان السطر في ملف السّجل يشير إلى استيثاق فاشل، وlogpath الذي يُخبِر fail2ban أين توجد السّجلات لتلك الخدمة بالتحديد. إنّ قيمة filter هي في الواقع إشارة reference إلى ملف يتوضّع في الدّليل etc/fail2ban/filter.d/ مع إزالة لاحقته conf.، يحتوي هذا الملف على التّعابير النمطيّة regular expressions التي تُحدّد إذا ما كان السّطر في ملف السّجل سيّئًا، لن نقوم بالتّحدث بالتفصيل عن هذا الملف في هذا الدّرس، لأنّه مُعقّد إلى حدٍ ما، والإعدادات المُعرّفة مُسبقًا تتوافق مع السطور المُلائمة لها بشكل جيّد. بإمكاننا على أيّة حال أن نرى أنواع المُرشّحات filters المتوفرة من خلال النّظر إلى هذا الدّليل: ls /etc/fail2ban/filter.dعندما نجد ملفًّا مرتبطًا بالخدمة التي نستخدمها ينبغي أن نفتحه باستخدام مُحرّر نصوص. مُعظم هذه الملفّات تحتوي على تعليقات للشرح بشكل جيّد ويجب أن نكون قادرين على الأقل أن نعرف ما هو نوع الشّروط التي تم تصميم الـ script من أجل الحماية ضدّها، تملك أغلب هذه المُرشّحات أقسام (مُعطّلة) مناسبة في ملف jail.local والتي نستطيع تمكينها عند الرغبة بذلك. فلنفترض على سبيل المثال أنّنا نقوم بتخديم موقع باستخدام nginx وأدركنا أنّ قسم منه محمي بكلمة مرور يتعرّض لمحاولات تسجيل دخول، نستطيع إخبار fail2ban أن يستخدم الملف nginx-http-auth.conf لكي يفحص هذا الشّرط من خلال الملف var/log/nginx/error.log/. هذا الشّرط مُعَد مُسبقًا في الواقع ضمن قسم يُدعى [nginx-http-auth] في الملف etc/fail2ban/jail.local/، نحتاج فقط إلى قلب المُعامِل enabled إلى true لحماية الخدمة الخاصّة بنا: [nginx-http-auth] enabled = true filter = nginx-http-auth port = http,https logpath = /var/log/nginx/error.logإن قمنا بتفعيلها نحتاج إلى إعادة تشغيل خدمة fail2ban للتأكّد من أنّ قواعدنا مبنيّة بشكل صحيح. وضع كل ذلك معاالآن وقد فهمنا الفكرة الأساسيّة من وراء fail2ban، فلنقم بتشغيل إعداد أساسي. سنقوم بإعداد سياسة حظر تلقائي من أجل SSH وNginx تمامًا كما وصفنا سابقًا، نريد من fail2ban أن يقوم بإرسال بريد إلكتروني لنا عندما يتم حظر عنوان IP. فلنقم في البداية بتثبيت جميع البرمجيّات المتعلقّة بذلك. إن كُنّا لا نملك nginx يجب علينا تثبيته، لأنّنا سنقوم بمراقبة سجلّاته، سنحتاج أيضًا sendmail لكي يرسل التّنبيهات إلينا، سنقوم بتثبيت iptables-persistent لكي يسمح للخادوم بإعداد قواعد الجّدار النّاري تلقائيًّا عند الإقلاع boot، نستطيع الحصول على كل هذا من مستودعات Ubuntu الافتراضيّة: sudo apt-get update sudo apt-get install nginx sendmail iptables-persistent 1. إنشاء جدار ناري أساسيينبغي علينا بعد الانتهاء من كل هذا إنشاء جدار ناري افتراضي، تستطيع تعلّم كيفيّة إعداد iptables للجدار الناري على Ubuntu من هنا، سنقوم في هذا الدّرس فقط بإنشاء جدار ناري أساسي. سنخبر الجّدار النّاري بالسّماح للاتصالات التي تمّ تأسيسها، نقل البيانات traffic الذي يتم توليده من قبل الخادوم نفسه، مقدار نقل البيانات من أجل SSH لدينا، ومنافذ ports خادوم الوِب، وسنقوم باستبعاد أي نقل بيانات آخر، نستطيع إعداد هذا الجّدار النّاري الأساسي عن طريق كتابة: sudo iptables -A INPUT -i lo -j ACCEPT sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT sudo iptables -A INPUT -j DROPستقوم هذه الأوامر بتنفيذ السّياسة السّابقة، وبإمكاننا رؤية قواعد الجّدار النّاري الحاليّة عن طريق كتابة: sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -j DROP -A fail2ban-ssh -j RETURN حصلنا هنا على سياستنا الافتراضيّة لكل واحدة من السلاسل لدينا، ومن ثمّ القواعد الخمس التي أنشأناها للتو، إنّ الأسطر التي تحتوي على: -N fail2ban-ssh و -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-sshو -A fail2ban-ssh -j RETURN هي عبارة عن البُنية الافتراضيّة المُعدّة من قبل fail2ban حيث أنّه يقوم مُسبقًا بتنفيذ سياسات حظر SSH بشكل افتراضي. 2. ضبط إعدادات Fail2banنحتاج الآن لضبط إعدادات fail2ban باختيار الإعدادات التي نرغب بها، فلنقم بفتح الملف jail.local: sudo nano /etc/fail2ban/jail.localنستطيع هنا تعيين زمن للحظر أشد طولًا، فلنقم بتغيير الإعداد bantime الموجود تحت الترويسة الافتراضيّة بحيث تقوم خدمتنا بحظر العملاء لمدة نصف ساعة: bantime = 1800نحتاج أيضًا لضبط معلومات تنبيهات البريد الإلكتروني، نقوم في البداية بإيجاد المُعامِل destemail ونضع بداخله عنوان البريد الإلكتروني الذي نرغب باستخدامه لجمع هذه الرسائل: destemail = admin@example.comنستطيع تعيين sendername إلى قيمة أخرى إن أردنا ذلك، على الرغم من أنّه من المفيد أن يكون لها قيمة يُمكن تصفيتها بسهولة باستخدام خدمة البريد الإلكتروني الخاصّة بنا، وإلّا امتلأ صندوق الوارد بالتنبيهات إن كانت هناك الكثير من محاولات الاختراق من أماكن متعدّدة. بالانتقال للأسفل نحتاج لضبط المُعامِل action إلى أحد الإجراءات التي ترسل لنا بريد إلكتروني، الخيارات محصورة بين action_mw والذي يُنشِئ الحظر ومن ثمّ يرسل لنا بريدًا إلكترونيًّا يحتوي على تقرير whois حول المُضيف المخالف، أو action_mwl والذي يقوم بما سبق ولكن يرسل لنا أيضًا سطور السجل المتعلّقة بذلك. سوف نختار action_mwl لأنّ سطور السّجلات ستساعدنا على استكشاف الأخطاء وجمع المزيد من المعلومات إن كانت توجد مشاكل: action = %(action_mwl)sوبالانتقال إلى قسم SSH لدينا، إن أردنا ضبط عدد المحاولات غير الناجحة التي ينبغي أن نسمح بها قبل إنشاء حظر نستطيع تعديل الإدخال maxretry، وإن كُنّا نستخدم منفذ غير 22 سنحتاج لضبط المُعامِل port بشكلٍ مُناسِب، وكما قلنا سابقًا فإنّ هذه الخدمة مُمكّنة مُسبقًا لذلك لا حاجة لتعديل ذلك. فلنبحث بعد ذلك عن القسم nginx-http-auth ونُغيّر المُعامِل enabled ليصبح true: [nginx-http-auth] enabled = true . . .هذا هو كل ما ينبغي علينا فعله في هذا القسم ما لم يكن يعمل خادوم الوِب لدينا على منافذ غير معياريّة أو قمنا بنقل المسار الافتراضي لسجلّات الأخطاء. 3. إعادة تشغيل خدمة Fail2banبعد الانتهاء مما سبق نقوم بحفظ وإغلاق الملف. نقوم الآن ببدء تشغيل أو إعادة تشغيل خدمة fail2ban، من الأفضل أحيانًا إيقاف تشغيل الخدمة بشكلٍ تام ومن ثم تشغيلها مرة أخرى: sudo service fail2ban stopنستطيع الآن إعادة تشغيلها بكتابة ما يلي: sudo service fail2ban startقد تستغرق بضع لحظات لكي يتم ملء جميع قواعد الجّدار النّاري لدينا، على أيّة حال نستطيع بعد ذلك التأكّد من القواعد الجديدة بكتابة: sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N fail2ban-nginx-http-auth -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-http-auth -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -j DROP -A fail2ban-nginx-http-auth -j RETURN -A fail2ban-ssh -j RETURNإن الأسطر التي قامت بإنشائها سياسات fail2ban لدينا هي: -N fail2ban-nginx-http-auth -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-http-auth -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A fail2ban-nginx-http-auth -j RETURN -A fail2ban-ssh -j RETURN تقوم هذه الأسطر الآن بتوجيه نقل البيانات إلى سلاسل جديدة وفارغة تقريبًا ومن ثمّ تسمح لنقل البيانات بالتدفق والعودة إلى سلسلة الدّخل INPUT. على أيّة حال هذه السلاسل الجديدة هي حيث يتم إضافة قواعد الحظر الجّديدة. 4. اختبار سياسات الحظرنستطيع اختبار القواعد من خادوم آخر -خادوم لا نحتاج له للدخول إلى خادوم fail2ban- عن طريق جعل هذا الخادوم الثاني ينحظر. بعد الدخول إلى الخادوم الثاني نقوم بمحاولة الدخول عن طريق SSH إلى خادوم fail2ban، نستطيع على سبيل المثال محاولة الاتصال باستخدام اسم غير موجود: ssh blah@fail2ban_server_IPفلنقم بإدخال أحرف عشوائيّة في النّافذة التي تطلب منّا كلمة مرور، ومن ثمّ نعيد هذه الخطوة عدّة مرات، سيقوم خادوم fail2ban في نقطة ما بإيقاف الاستجابة مع رسالة تم رفض الإذن Permission denied، وهذا يشير إلى أنه تم حظر الخادوم الثاني من قبل خادوم fail2ban. نستطيع على خادوم fail2ban مشاهدة القواعد الجديدة عن طريق التّحقق مرة أخرى من iptables لدينا: sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N fail2ban-nginx-http-auth -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-http-auth -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -j DROP -A fail2ban-nginx-http-auth -j RETURN -A fail2ban-ssh -s 11.111.111.11/32 -j REJECT --reject-with icmp-port-unreachable -A fail2ban-ssh -j RETURNوكما نرى في السّطر: -A fail2ban-ssh -s 11.111.111.11/32 -j REJECT --reject-with icmp-port-unreachableنملك الآن قاعدة جديدة في إعداداتنا ترفض نقل البيانات القادمة من عنوان IP خادومنا الثاني عبر منفذ SSH، ينبغي أيضًا أن نكون قد حصلنا على بريد إلكتروني حول هذا الحظر في الحساب الذي قمنا بإعداده. خاتمةينبغي أن نكون قادرين الآن على إعداد بعض سياسات الحظر الأساسيّة لخدماتنا، من السّهل جدًّا إعداد Fail2ban وهو طريقة رائعة لحماية أي نوع من الخدمات تستخدم الاستيثاق. إن أردت تعلّم المزيد حول كيفيّة عمل fail2ban بإمكانك تفحّص هذا الدّرس التعليمي حول كيفيّة عمل قواعد وملفّات fail2ban. ترجمة -وبتصرّف- للمقال How To Protect SSH with Fail2Ban on Ubuntu 14.04 لصاحبه Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.

يُعد إنجن إكس NginX خادوم ويب Web Server ذو أداء عالي وهو مسؤول عن معالجة العبء الواقع على بعض أكبر المواقع الإلكترونية Web Sites على الإنترنت Internet. وهو جيد خصوصًا في معالجة الكثير من الاتصالات المتزامنة concurrent ويتفوق في تخديم المحتوى الثابت static content. مع أنّ الكثير من المستخدمين يدركون قدرات Nginx، إلا أنه عادةً ما يحتار المستخدمين الجدد ببعض المصطلحات التي يجدونها في ملف إعدادات configuration خادوم Nginx. سنركّز في هذا الدليل على شرح البنية الأساسية لملف إعدادات Nginx بالإضافة لاستعراض بعض المبادئ guidelines في كيفية تصميم ملف الإعدادات. فهم سياقات الإعدادات في Nginxسيُغطي هذا الدليل البنية الأساسية الموجودة في ملف الإعدادات الرئيسي Nginx. قد يختلف مكان هذا الملف وفقًا للطريقة التي اتبعتها عند تثبيت البرمجية Software على الخادوم. إلا أنَّك سوف تجده في العديد من التوزيعات distributions على المسار التالي: /etc/nginx/nginx.confإنّ لم يكن موجودًا فقد تجده على المسار: /usr/local/nginx/conf/nginx.confأو المسار: /usr/local/etc/nginx/nginx.confإنّ أحد أول الأمور التي ينبغي عليك ملاحظتها عندما تنظر إلى ملف الإعدادات الرئيسي هي أنَّه منظَّم في بنيةٍ من ثلاثة أقسام تعرّف بداية ونهاية كلٍ منها بالقوسين } و {. تسمى الأقسام المعرّفة باستخدام القوسين سياقات contexts وفقًا للغة Nginx، وذلك لأنها تحوي على إعداداتٍ مُفَصَّلة وموزعة بين تلك الأقسام وفقًا للمجال الذي يُعنى به كل قسم. يقدم هذا التقسيم بشكل أساسي بنيةً منظّمة وفق بعض الشروط المنطقية التي تقرّر فيما إن كان ينبغي تطبيق الإعدادات التي يحويها القسم أو لا. وباعتبار أنه يمكن للسياقات أن تتداخل فيما بينها فإنNginx يقدم مستوًا من وراثة التعليمات directive inheritance. كقاعدةٍ عامة، إن كانت التعليمة صالحةً في عدّة مجالات scopes متدخلة فإنّ التصريح عنها في سياق أعلى boarder context سيُمرّر لأي سياقٍ أدنى (سياق ابن child context) كقيم افتراضية. يمكن للسياقات الأدنى أن يعيد تعريف override تلك القيم لاحقًا. جدير بالذكر أنّ عملية إعادة التعريف إلى أي مصفوفة-نوع array-type سينتج عنها استبدال القيم السابقة وليس إضافة append القيم الجديدة لها. يمكن أن تستخدم التعليمات Directives ضمن السياقات المصمّمة لها فقط، إذ أنّ Nginx سيُصدر خطأ عند قراءته لملف إعدادات يحوي على تعليمات مصرّح عنها في السياق الخاطئ. يحوي توثيق Nginx على معلومات حول كلّ تعليمة والسياقات التي تكون صالحة ضمنها لذلك يُعد مرجع رائع إن لم تكن متأكدًا من معلوماتك. سنناقش فيما يلي أكثر السياقات شيوعًا والتي قد تصادفها عند استخدامك Nginx. السياقات الأساسيةأول مجموعة سياقات سنشرحها هي السياقات الأساسية core contexts التي يستخدمها Nginx لإنشاء شجرة هرمية hierarchical tree وتوزيع الإعدادات - بحسب مهمّتها - في كتل Blocks منفصلة. تشكّل تلك السياقات البنية الأساسية لإعدادات Nginx. السياق الأساسيإن أكثر سياق عام هو السياق الأساسي Main Context، والذي يدعى أيضًا بالسياق العام Global Context. إذ أنه السياق الوحيد غير المحتوى ضمن كتل السياق القياسية والتي تبدو كما يلي: # السياق الأساسي يوجد هنا، السياقات الأخرى تكون خارجا . . . context { . . . }يمكن القول عن أيّة تعليمة موجودة خارج كل تلك الكتل بأنها تقع في السياق الأساسي. ضع في الحسبان أنه إن كانت إعدادات Nginx مضبوطةً على شكل وحدات modular فستحوي بعض الملفات على تعليماتٍ instructions تبدو وكأنها تقع خارج أقواس السياق إلا أنها ستُضمّن داخله عندما يتم دمج الإعدادات معًا. يمثّل السياق الأساسي أوسع بيئة حاضنة لإعدادات Nginx، وهي مستخدمة لضبط التفاصيل التي تؤثر على كامل التطبيق application في مستوى أساسي. وفي الوقت الذي تؤثر فيه التعليمات الموجودة في هذا القسم على السياقات الأدنى فإن العديد من تلك التعليمات لا توّرث، إذ أنه من غير الممكن إعادة تعريفها في مستوياتٍ أدنى. إن بعض التفاصيل الشائعة والتي تُهيّئ في السياق الرئيسي هي المستخدم user والمجموعة group التي ستُشغّل العمليات العاملة worker processes باسمهما، بالإضافة لعدد العمليات العاملة والملف الذي سيحتفظ بمعرّف العملية الرئيسية PID. يمكن أيضًا أن يُضبط ملف الأخطاء الافتراضي لكامل التطبيق ضمن هذا المستوى (كما يمكن أن يُعاد تعريف الملف ضمن سياقات مخصّصة أكثر). سياق الأحداثإنَّ سياق الأحداث Events Context يقع ضمن السياق الأساسي. وهو يستخدم لضبط الخيارات العامة التي تؤثّر على كيفية معالجة Nginx للاتصالات في مستوى عام. يمكن أن يُعرّف سياق أحداث واحد فقط ضمن إعدادات Nginx. سوف يبدو هذا السياق ضمن ملف الإعدادات كما يلي، خارج أقواس أي سياقٍ آخر: # السياق الأساسي events { # سياق الأحداث . . . }يستخدم Nginx وحدة معالجة اتصال مقادة بالأحداث event-based connection processing model لذلك فإن التعليمات المعرّفة داخل هذا السياق تحدّد كيف ينبغي على العمليات العاملة worker processes معالجة الاتصالات connections. تُستخدم التعليمات الموجودة هنا بشكل أساسي إما في اختيار الطريقة المستخدمة في معالجة الاتصال أو لتغيير كيفية تحقيق implement تلك الطرق methods. عادةً ما تُختار طريقة معالجة الاتصال تلقائيًا بالاعتماد على أكثر الخيارات - التي توفّرها منصّة العمل platform - فاعليةً. بالنسبة لأنظمة لينكس Linux، فعادةً ما تكون طريقة epoll هي الخيار الأفضل. هنالك عناصر أخرى يمكن ضبطها، كعدد الاتصالات التي يمكن لكل عملية عاملة أن تعالجها، وفيما إن كان على العملية أن تأخذ اتصالًا تلو الآخر أو أن تأخذ كل الاتصالات المنتظرة بعد أن يتم إعلامها بوجودها. وأيضًا فيما إن كان على العمليات العاملة أن تتناوب في الرد على الأحداث. سياق HTTPعند إعداد Nginx كخادوم ويب أو خادوم وكيل معكوس reverse proxy، فسيحتفظ سياق HTTP بغالبية الإعدادات. سيحتوي السياق على كل التعليمات والسياقات الأخرى الضرورية لتعريف كيفية معالجة البرنامج لاتصالات HTTP أو HTTPS. يُعد سياق HTTP أخًا لسياق الأحداث - أي أنهما يقعان في نفس المستوى - إذ أن كلاهما يُعد ابنًا للسياق الرئيسي، لذلك ينبغي أن يُدرجا جنبًا إلى جنب بدلًا من أن يتداخلا: # السياق الأساسي events { # سياق الأحداث . . . } http { # سياق HTPP . . . }فيما تختص السياقات الدنيا lower contexts في كيفية معالجات الطلبات، فإن التعليمات في هذا المستوى تتحكم بالقيم الافتراضية لكل الخواديم الافتراضية المعرّفة داخله. هنالك عدد كبير من التعليمات القابلة للضبط configurable ضمن هذا السياق والسياقات المحتواة ضمنه، يعتمد ذلك على طريقة التوريث inheritance التي ترغب أن يتم العمل وفقها. فيما يلي مجموعة من التعليمات التي يمكن أن تصادفها خلال ضبط إعدادات Nginx: تعليمات تتحكم بالمواقع الافتراضية لسجلات الوصول والأخطاء مثل (access_log و error_log).تعليمات تضبط عمليات القراءة والكتابة I/O غير المتزامنة asynchronous من وإلى الملفات مثل (aio و sendfile و directio)،تعليمات تضبط حالات الخادوم عندما تحدث الأخطاء مثل (error_page).تعليمات تضبط عملية الضغط compression مثل (gzip و gzip_disable).عمليات تحسّن fine-tune إعدادات اتصال TCP الحي TCP keep alive مثل (keepalive_disable و keepalive_requests و keepalive_timeout).القواعد rules التي يتبعها Nginx عندما يحاول تحسين optimize الحزم packets واستدعاءات النظام system calls مثل (sendfile و tcp_nodelay و tcp_nopush).تعليمات تضبط جذر المستندات document root وفهرس الملفات index files على مستوى التطبيق application-level مثل (root و index).تعليمات تهيّئ العديد من جداول المقابلة hash tables المستخدمة لتخزين أتماط مختلفة من البيانات مثل (*_hash_bucket_size و *_hash_max_size المستخدمتين مع server_names بالإضافة لـ types و variables).سياق الخادوميُعرّف سياق الخادوم Server Context ضمن سياق HTTP، ويُعد ذلك أوّل مثال لنا عن السياقات المتداخلة. كما أنّه أوّل سياق مرّ معنا يمكن تعريفه عدّة مرات. قد يبدو التنسيق العام لسياق الخادوم مشابهًا لما يأتي، تذكّر أنّ هذا السياق سيقع ضمن سياق HTTP: # السياق الأساسي http: { # سياق HTTP server { # سياق خادوم أول } server { # سياق خادوم ثاني } }يعود سبب السماح بوجود أكثر من تعريف لسياق الخادوم إلى أن كل غرض instance يعرّف خادومًا افتراضيًا لمعالجة طلبات المستخدم client. بإمكانك تعريف كتل الخادوم server blocks بقدر حاجتك، إذ أنّه بإمكان كل منها أن يعالج مجموعة فرعية محدّدة من الاتصالات. وبسبب امكانية وترجيح وجود عدة كتل خواديم، فإن هذا أوّل نوع من السياقات يحتّم على Nginx استخدام خوارزمية algorithm انتقاء لاتخاذ القرارات. إنّ كلّ طلب مستخدم سيُعالَج وفقًا للإعدادات المعرّفة في سياق خادوم وحيد، لذلك فإن على Nginx أن يقرّر أي سياق خادوم هو الأنسب وفقًا لتفاصيل الطلب. إنّ التعليمات التي تقرّر فيما إذا كانت كتلة الخادوم ستُستخدم أم لا هي: تعليمة التنصت listen: تُصمَّم كتلة الخادوم للرد على الطلبات الواردة من مصدر معرّف بثنائية عنوان الإنترنت IP / المنفذ Port. فإن ورد طلب request من مستخدم يطابق ذلك المصدر فمن المحتمل أن يتم اختيار تلك الكتلة لمعالجة الاتصال.تعليمة اسم الخادم server_name: هذه التعليمة هي المكوّن الآخر المستخدم في اختيار كتلة الخادوم التي ستقوم بالمعالجة. إن كان هنالك العديد من كتل الخادوم مزوّدةً بتعليمات تنصت مضبوطة بنفس القيم ويمكنها أن تعالج الطلب، فسيحلّل إنجن إكس ترويسة المُضيف Host header الخاصة بالطلب ويطابقها مع التعليمة.يمكن للتعليمات الموجودة ضمن هذا السياق أن تعيد تعريف العديد من التعليمات المعرّفة في سياق HTTP بما فيها تعليمات التسجيل logging، وجذر المستندات، والضغط، وإلى ما هنالك. وبالإضافة إلى التعليمات المأخوذة من سياق HTTP، فبإمكاننا أيضًا إعداد ملفات لمحاولة الرد على الطلبات عبر تعليمة (try_files)، وإصدار أمر لإعادة التوجيه وإعادة الكتابة (return و rewrite)، وضبط المتحولات عبر تعليمة (set). سياق الموقعالسياق التالي الذي ستتعرف عليه هو سياق الموقع location context وهو سياقٌ ستتعامل معه بشكل متكرّر. تتشارك سياقات الموقع العديد من الصفات مع سياقات الخادوم. فمثلًا، يمكن تعريف أكثر من سياق موقع، ويُستخدم كل منها لمعالجة نوع محدّد من طلبات المستخدم، ويتم اختيار كل موقع بناءًا على مطابقة تعريف الموقع مع طلب المستخدم باستخدام خوارزمية انتقاء. في الوقت الذي تُعرّف فيه التعليمات - التي تحدّد فيما إن كان سيتم اختيار كتلة خادوم - ضمن السياق الخادوم ذاته، فإن المكوّن component الذي يقرّر مدى قدرة الموقع على معالجة الطلب يقع ضمن تعريف الموقع نفسه. تبدو الصيغة العامة كما يلي: location match_modifier location_match { . . . }تقع كتل الموقع ضمن سياقات الخواديم، وعلى عكس كتل الخادوم، يمكن لكتل الموقع أن تتداخل فيما بينها. قد يفيد ذلك في إنشاء سياق موقع أعم ليلتقط مجموعة فرعية محدّدة من الطلبات المتناقلة traffic، لتكمل السياقات الإضافية الداخلية معالجتها بإسهاب أكبر وفقًا لمعايير أدق. # السياق الأساسي server { # سياق الخادوم location /match/criteria { # سياق موقع أول } location /other/criteria { # سياق موقع ثاني location nested_match { # موقع أول } location other_nested { # موقع ثاني } } }بينما يتم اختيار سياقات الخواديم وفقًا لثنائية عنوان IP / المنفذ المطلوبة ولاسم المضيف الموجود ضمن ترويسة المضيف، فإن كتل الموقع تقسّم معالجة الطلب ضمن كتلة الخادوم بالنظر إلى معرّف الموارد الموّحد URI الخاص بالطلب. إن معرّف URI الخاص بالطلب هو جزءٌ من الطلب يأتي بعد اسم النطاق domain name وثنائية عنوان IP / المنفذ. لذلك فإن طلب المستخدم http://www.example.com/blog على المنفذ 80، يستخدم العنوان http www.example.com والمنفذ 80 لتحديد كتلة الخادوم التي سيتم اختيارها. بعد اختيار الخادوم، سيُطابق الجزء /blog (المُمثّل لمعرّف URI الخاص بالطلب) مع المواقع المعرّفة لتحديد السياق الإضافي الذي ينبغي استخدامه ليرد على الطلب. إنّ العديد من التعليمات التي يمكن أن تراها في سياق الموقع متوفّرةٌ أيضًا في مستويات الآباء (المستويات الأعلى) parent levels. فيما يلي مجموعة جديدة من التعليمات المستخدمة ضمن هذا المستوى تسمح لك بالوصول إلى المواقع الواقعة خارج جذر المستندات (تعليمة alias)، وتحديد الموقع كموقع يمكن الوصول له من الداخل فقط (تعليمة internal)، وكوكيل لخواديم أو مواقع أخرى (باستخدام برتوكولات http، fastcgi، scgi، uwsgi) سياقات أخرىمع أنّ الأمثلة السابقة تمثّل السياقات الأساسية التي ستصادفها في Nginx، إلا أنه يوجد سياقات أخرى أيضًا. هنالك عدّة أسباب دعتنا لفصل السياقات التالية، فإما أنها تعتمد على الكثير من الوحدات الاختيارية، أو أنها تستخدم ضمن ظروف خاصة فقط، أو أنها تستخدم لوظائف لن يستخدمها معظم الأشخاص. لكننا لن نناقش كل السياقات المتوفّرة، ولن نخوض بشرح السياقات الآتية بالتفصيل: split_clients أُعد هذا السياق لتقسيم المستخدمين اللذين يستقبلهم الخادوم إلى فئات categories عبر عنونتهم بمتحولات تعتمد على النسبة المئوية. يمكن أن يُستخدم ذلك لاحقًا للقيام باختبار A/B عبر توفير محتويات content مختلفة لمُضيفين hosts مختلفين.perl / perl_set يُهيّئ هذين السياقين معالجات بيرل Perl للموقع الذي تتواجد ضمنه. تستخدم هذه السياقات للمعالجة باستخدام بيرل فقط.map يُستخدم هذا السياق لضبط قيمة متحول بالاعتماد على قيمة متحول آخر. إذ أنه يوفّر جدول مقابلة mapping لقيم المتحوّل الأول حتى يحدّد القيمة التي ينبغي ضبط المتحول الثاني بها.geo يُستخدم هذا السياق - مثل السياق السابق - في تحديد جدول مقابلة. إلا أنّ هذا الجدول يستخدم خصيصًا لتصنيف عناوين IP. يضبط هذا السياق قيمة متحول وفقًا لعنوان IP المتّصل.types يُستخدم هذا السياق أيضًا لجداول المقابلة. إذ أنه يُستخدم لمقابلة أنماط وسائط الإنترنت MIME بامتدادات (لواحق) extensions الملفات التي ينبغي ربطهم بها. يوفّر Nginx ذلك عادةً عبر ملف يُضمّن محتواه داخل ملف الإعدادات nginx.conf.charset_map يمثّل هذا السياق مثالًا آخر عن سياقات المقابلة، إذ أنه يُستخدم لإنشاء جدول مقابلة للتحويل conversion table من مجموعة محارف إلى مجموعة أُخرى. تضمّن كلا المجموعتين في ترويسة هذا السياق، ويضمّن جدول المقابلة في بنيته body.إنّ السياق التالي ليس شائعًا بقدر السياقات التي شرحناها حتى الآن، إلا أنّ التعرّف عليه يبقى مفيدًا. سياق مجموعة الخواديم العليايُستخدم سياق مجموعة الخواديم العليا upstream context لتعريف وإعداد الخواديم العليا upstream. يعرّف هذا السياق بشكل أساسي حوضًا pool معرّفًا باسم يحتوي على مجموعة الخواديم التي يستطيع Nginx أن يعمل كوكيل proxy عنها للطلبات. ستستخدم هذا السياق على الأرجح عندما تُعد وكلاءًا من مختلف الأنواع. يجب وضع سياق مجموعة الخواديم العليا ضمن سياق HTTP، وخارج كلِّ سياقات الخواديم. تبدو الصيغة العامة له كما يلي: # السياق الأساسي http { # سياق HTTP upstream upstream_name { # سياق مجموعة الخواديم العليا server proxy_server1; server proxy_server2; . . . } server { # سياق خادوم } }يمكن فيما بعد أن تتم الإشارة إلى سياق مجموعة الخواديم العليا باسمه ضمن الخادوم أو كتل الموقع لتمرير طلبات ذات نوع محدّد لحوض الخواديم الذي تمّ تعريفه. ستستخدم عندها مجموعة الخواديم خوارزميةً لتحديد الخادوم الذي ينبغي أن يسلم الطلب له، تستخدم خوارزمية راوند روبن round-robin بشكل افتراضي. يسمح هذا السياق لـNginx أن يعمل على موازنة الحمل load balancing عندما يعمل كوكيل للطلبات. سياق البريدبالرغم من أن Nginx يُستخدم عادةً كخادوم ويب أو خادوم وكيل معكوس، إلا أنه يعمل كخادوم وكيل للبريد mail proxy server بأداءٍ عالي جدًا. يسمّى السياق المستخدم لهذا النوع من التعليمات بالبريد mail. يعرّف سياق البريد The mail context ضمن السياق العام، أو السياق الأساسي (خارج سياق HTTP). الوظيفة الأساسية لسياق البريد هي توفير مجال لإعداد وكيل للبريد على الخادوم. يمكن لـNginx أن يعيد توجيه redirect طلبات المصادقة authentication لخادوم مصادقة خارجي authentication server. ويمكنه بعد ذلك أن يوفّر الوصول إلى خواديم البريد العاملة ببرتوكولات POP3 و IMAP لجلب بيانات البريد الفعلية. يمكن لسياق البريد أن يُعد أيضًا للاتصال بخادوم الترحيل العامل ببرتوكول SMTP (SMTP Relayhost) إن دعت الحاجة. عمومًا، قد يبدو شكل سياق البريد مشابهًا لما يلي: # السياق الأساسي events { # سياق الأحداث } mail { # سياق البريد }السياق الشرطييمكن أن يُنشئ السياق الشرطي if لتوفير معالجة شرطية للتعليمات المعرّفة بداخله. وكما هو حال عبارات الشرط if في لغات البرمجة التقليدية، فإن تعليمة if في Nginx ستنفذ التعليمات المتحواة ضمنها إن كان الشرط محقّقًا وأعاد القيمة الصحيحة True. يُقدَّم السياق if في Nginx من قِبل وحدة إعادة الكتابة rewrite module وهي الغاية الأساسية من استخدام هذا السياق. باعتبار أنّ Nginx سيختبر حالات الطلب باستخدام العديد من التعليمات الأخرى المعمولة لهذا الغرض، فلا ينبغي استخدام تعليمة if في أغلب حالات التنفيذ الشرطي. تُعد هذه الملاحظة هامةً لدرجة أنّ مجتمع Nginx أنشأ صفحةً وسمّاها if الشريرة. إنّ المشكلة الأساسية هي أنّ ترتيب المعالجة لدى Nginx قد يؤدي في كثير من الأحيان إلى نتائج غير متوقعة تظهر وكأنها تقلب معنى كتلة if رأسًا على عقب. تُعد تعليمتي إعادة التوجيه return وإعادة الكتابة rewrite التعليمتين الوحيدتين اللتين يعتبر استخدامهما آمنًا داخل هذه السياقات، إذ أنها أُنشئت لأجلهما. ضع في الحسبان أيضًا أنّه عند استخدام سياق if فإنّه يقدّم تعليمة try_files داخل نفس السياق بلا فائدة. غالبًا ما يتم استخدام if لتحديد فيما إنّ كان هنالك حاجة لتعليمة return أو تعلمية rewrite. وستقع غالبًا داخل كتل الموقع، لذلك فستبدو الصيغة العامة مشابهةً لما يلي: # السياق الأساسي http { # سياق HTTP server { # سياق خادوم location location_match { # سياق موقع if (test_condition) { # سياق شرطي if } } } }سياق تحديد الاستثناءاتيُستخدم سياق تحديد الاستثناءات Limit_except Context لتحديد استخدام طرق HTTP Methods محدّدة داخل سياق الموقع. فمثلًا، إن كان ينبغي لمجموعة محدّدة فقط من المستخدمين أن يصلوا إلى محتوى طريقة POST Method، أما البقيّة فينبغي أن يتمكّنوا من قراءة المحتوى، فيمكنك استخدام كتلة limit_except لتعريف تلك المتطلّبات. سيبدو المثال السابق مشابهًا لما يلي: . . . # سياق موقع أو خادوم location /restricted-write { # سياق موقع limit_except GET HEAD { # سياق تحديد الاستثناءات allow 192.168.1.1/24; deny all; } }ستطبق التعليمات الموجودة داخل السياق - والتي يقصد منها تقييد الوصول - عند مصادفة أيٍ من طرق HTTP باستثناء تلك المدرجة ضمن ترويسة السياق. إنّ نتيجة المثال السابق هي أنّه بإمكان أي مستخدم استخدام أفعال GET و HEAD، إلا أنّه يسمح فقط للمستخدمين المتصلين من الشبكة الفرعية subnet ذات العنوان 192.168.1.1/24 باستخدام طرق أخرى. قواعد عامة حول السياقات ينبغي اتباعهاالآن وبعد أن أصبح لديك فكرة عن السياقات الشائعة التي يمكن أن تصادفها أثناء استعراضك لإعدادات إنجن إكس، فبإمكاننا شرح بعض القواعد المُثلى التي يمكن اتباعها عند التعامل مع سياقات Nginx. تطبيق التعليمات في أعلى سياق متوفرإنّ العديد من التعليمات تكون صالحةً داخل أكثر من سياق واحد. فمثلًا، هنالك بضعة تعليمات يمكن وضعها داخل كل من سياقات HTTP والخادوم والموقع. يمنحنا ذلك مرونةً عند ضبط تك التعليمات. ولكن كقاعدة عامة، عادةً ما يكون من الأفضل تعريف التعليمات في أعلى سياق تقبل التعريف ضمنه، وإعادة تعريفها ضمن السياقات الأدنى عند الحاجة. يمكن ذلك بسبب وحدة الوراثة inheritance model التي تحقّقها إنجن إكس. هنالك العديد من الأسباب لاستخدام هذه الاستراتيجية. أولًا، إنّ التعريف ضمن أعلى مستوى يجنّبك تكرار نفس التعريف ضمن السياقات الأخوة. فمثلًا، في المثال التالي يعرّف كل موقع نفس جذر المستندات. http { server { location / { root /var/www/html; . . . } location /another { root /var/www/html; . . . } } }يمكنك نقل الجذر خارج كتلة الخادوم، أو حتى لكتلة HTTP كما يلي: http { root /var/www/html; server { location / { . . . } location /another { . . . } } }أغلب الأحيان، سيكون مستوى الخادوم ملائمًا أكثر، إلا أنّ التصريح declaring في مستوىً أعلى له محاسنه. إنّ ذلك لا يسمح بضبط التعليمة في أماكن أقل فحسب، وإنما سيسمح لك بتمرير القيمة الافتراضية لكل الأبناء، ما يمنع ظهور الحالات التي تصادف فيها خطأً لأنك نسيت تعليمةً ضمن مستوىً أدنى. يمكن أن يكون ذلك مشكلةً كبيرةً في الإعدادات الطويلة. إن التصريح في مستوىً عالي يوفّر لك قيمةً افتراضيةً صحيحة. استخدام عدة سياقات أشقاء عوضا عن المنطق الشرطي If في المعالجةعندما تريد معالجة الطلبات كل بشكل مختلف، اعتمادًا على بعض المعلومات التي يمكنك ايجادها ضمن طلب المستخدم، فعادةً ما يلجئ المستخدمون إلى سياق if ليحاولوا معالجتها شرطيًا. هنالك بعض المشاكل المترافقة مع ذلك كنا قد ذكرناها سابقًا بإيجاز. أول مشكلة هي أنّ تعليمة if عادةً ما تعيد نتائج لا تتوافق مع توقعات مدير النظام administrator. مع أنّ المعالجة ستُؤدي دائمًا إلى نفس النتائج عند توفير نفس المُدخلات، إلا أنّ الطريقة التي يتبعها Nginx في تفسير البيئة يمكن أن تختلف كثيرًا عما هو متوقع ما ام تخضع لاختبارات مكثّفة. السبب الثاني هو أنّ هنالك تعليمات معدّة لهذا الغرض بالتحديد، وهي مستخدمةٌ للعديد من تلك الأغراض. يستخدم Nginx خوارزمية انتقاء - ذات توثيق جيد - لاختيار كتل الخادوم وكتل الموقع. لذلك، يفضّل نقل الإعدادات المختلفة إلى الكتل المخصّصة لها إن كان ذلك ممكنًا، ما يسمح لتلك الخوارزمية بمعالجة منطق عملية الاختيار. فمثلًا، عوضًا عن الاعتماد على إعادة الكتابة rewrites للحصول على طلب المستخدم بالشكل format الذي ترغب بالعمل به، فعليك أن تجرّب إعداد كتلتين للطلب، أحدهما تمثّل الطريقة المرغوب بها، والأخرى تلتقط الطلبات العشوائية وتعيد توجيهها - وقد تعيد كتابتها - للكتلة الصحيحة. عادةً ما تكون النتائج أسهل للقراءة كما أنها تمتلك محاسن كونها ذات أداء عالي. لا تخضع الطلبات الصحيحة لأي معالجة إضافية وفي العديد من الحالات يمكن تجاوز الطلبات غير الصحيحة عبر تعليمة إعادة التوجيه عوضًا عن تعليمة إعادة الكتابة والتي ينبغي أنّ يكون عبء تنفيذها أقل. الخلاصةإلى هنا، ينبغي أن تكون قد حصلت على فهم جيّد لأكثر سياقات Nginx شيوعًا وللتعليمات التي تُنشئ الكتل التي تعرّف تلك السياقات. تحقّق دائمًا من توثيق Nginx للحصول على معلومات حول أي السياقات هو الأنسب لوضع تعليمة ما بداخله ولتقييم الموقع الأكثر فاعلية. إنّ الحرص أثناء إنشاء الإعدادات لن يسهل من عملية الصيانة فحسب، بل أنه سيرفع الأداء أيضًا في أغلب الآحيان. ترجمة -بتصرف- للمقال Understanding the Nginx Configuration File Structure and Configuration Contexts لكاتبه Justin Ellingwood.

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

تناول الجزء الأوّل من هذا الدّليل الخوارزميّة الّتي يتبعها خادوم ويب Nginx لاختيّار كتلة Server للإجابة على طلب العميل. سنتحدَّث في هذا المقال عن كتل Location وكيف يقرّر Nginx الكتلة الّتي ستُجيب على الطّلب. تحليل كُتَل Locationتوجد لدى Nginx آليّة لتقرير كتلة Location (الموقع) الّتي ستتولّى التّعامل مع الطّلب. تُشبه هذه الخوارزميّة في عملها خوارزميّة اختيّار كتلة Server المشروحة في الجزء الأوّل من هذا الدّليل. 1- صيّاغة Syntax كتلة Locationنبدأ، قبل شرح خوارزميّة اختيّار كتلة Location الّتي ستتولّى الإجابة على الطّلب، بشرح الصّيّاغة الّتي يستخدمها Nginx في تعريفات كتل الموقع. تُستخدَم كُتل Location الّتي تقبع ضمن كتلة Server (أو ضمن كتلة Location أخرى)، لتقرير كيف يُتعامل مع المعرّفات الكليّة للموارد Universal Resource Identifier, URI (الجزء الّذي يأتي بعد اسم النّطاق أو عنوان IP/المنفذ). تأخذ كتلة Location عمومًا الهيئة التّاليّة: location optional_modifier location_match { . . . }تُحدّد تعليمة location_match مالّذي سيُقارن به معرّف المورد الموجود في الطّلب. يُحيل optional_modifier إلى مُغيِّر اختيّاري يؤثّر على الطّريقة الّتي يبحث بها Nginx عن تطابق في كتلة Location. نميّز الحالات التّاليّة، حسب قيمة optional_modifier: لا يوجد متغيّر: إن لم تُذكَر قيمة للمغيِّر الاختيّاريّ فإنّ الموقع سيُحلّل حسب التّطابق المُبدَأ Prefix match. يعني هذا أنّ الموقع سيُقارَن ببداية معرّف المورِد (URI) في الطّلب، بحثًا عن تطابقات.=: إذا استُخدمت علامة التّساوي فإنّ الكُتلة لن تُأخذ في الحسبان إلّا إذا كانت مطابقة تمامًا لمعرّف المورِد في الطّلب.~: في هذه الحالة يُستخدَم تعبير نمطيّ Regular expression يتأثّر بحالة الأحرف (كبيرة Upper case أو صغيرة Lower case).*~: تختلف عن الحالة السّابقة في أنّ التّعبير النّمطيّ لا يتأثر بحالة الأحرف.~^: تُشير هذه القيمة إلى أنّه إن اختيرت هذه الكتلة في بوصفها أفضل تطابق دون الاعتماد على التّعابير النّمطيّة فإنّ هذه الأخيرة (أي التّعابير النّمطيّة) لن تُأخَذ بالحسبان.2- أمثلة توضّح صيّاغة كتلة Locationكتلة Location التّاليّة مثال على التّطابق المُبدَأ. ستُختار هذه الكتلة للإجابة على الطّلبات الّتي تتضمّن معرّفات الموارِد مثل site/page1/index.html/، site/ أو site/index.html/ (كلّها تبدأ ب site/): location /site { . . . }لتوضيح التّطابق التّام نأخذ الكتلة التّاليّة الّتي ستُستخدَم للإجابة على الطّالبات ذات معرّف المورد page1/. لن تُختار هذه كتلة Location هذه للإجابة على طلب بمعرّف مورد page1/index.html/. انتبه إلى أنّه في حال اختيّار هذه الكتلة وكان الطّلب يُنفَّذ باستخدام صفحة فهرس (Index page) فإنّه ستُجرى إعادة توجيه داخليّة Internal redirect إلى كتلة موقع أخرى تكون هيّ المُداول Handler الفعليّ للطّلب: location = /page1 { . . . }في الإعداد أدناه تعبيرٌ نمطيّ يتأثّر بحالة الأحرف. يُمكن أن تُستخدَم كتلة الموقع في هذا المثال للتّعامل مع الطّلبات على tortoise.jpg/ ولكنّها لا يُمكن أن تلبّي الطّلبات على FLOWER.PNG/. location ~ \.(jpe?g|png|gif|ico)$ { . . . }المثال التّالي لا يختلف عن المثال السّابق سوى في المغيّر الاختيّاريّ (~*) حيثُ إنّ التّعبير النّمطي هنا لا يتأثّر بحالة الأحرف؛ لذا يُمكن استخدام الكتلة للإجابة على كلّ من tortoise.jpg/ و FLOWER.PNG/. location ~* \.(jpe?g|png|gif|ico)$ { . . . }المثال الأخير للحالة الّتي تمنع فيها كتلة Location البحث عن تطابق عبر التّعابير النّمطيّة. تُحدّد الكتلة التّالية على أنّها أفضل تطابق لا يعتمد على التّعابير النّمطيّة للطّلبات على costumes/ninja.html/. location ^~ /costumes { . . . }رأينا أنّ المغيّرات تُحدّد كيف يجب أن تُفسَّر كتلة Location؛ إلّا أنّها لا تخبرنا عن ماهيّة الخوارزميّة الّتي يستخدمها Nginx لتقرير كتلة الموقع الّتي سيُرسِل إليها الطّلب، وهو ما سنتعرّض لها في الفقرات التّاليّة. 3- كيف يختار Nginx كتلة Location الّتي ستتعامل مع الطّلبات؟يستخدم Nginx آليّةً لاختيّار كتلة الموقِع الّتي ستُجيب على الطّلبات مُشابهةً لكيفيّة اختيّاره لكتلة الخادوم.فهم الإجراءات الّتي يتبعها Nginx لاختيّار الكتلة المناسبة أساسيّ جدًّا لتكون قادرًا على إعداد Nginx بوثوق ودقّة. يُقارن Nginx بين معرّف المورد في الطّلب وكتلة Location، مع احتساب المغيّرات الّتي ذكرناه في الفقرة السّابقة، من أجل تحديد أنسب كتلة موقع للإجابة على الطّلب؛ وفقًا للخوارزميّة التّاليّة: يبدأ Nginx بالتحقّق من كلّ المواقع الّتي لا تستعمل تعابير نمطيّة؛ فيُقارن كلّ كتلة موقع بمعرّف مورد الطّلب كاملًا. يبحث Nginx أوّلًا عن تطابق كامل. إن وُجدت كتلة Location تستخدم المغيِّر = وتُطابق تمامًا معرّف المورد في الطّلب؛ فإنّ كتلة الخادوم هذه سيقع عليها الاختيّار فورًا. إن لم يعثُر على تطابق كامل (باستخدام المغيّر =)، ينتقل Nginx إلى تقويم السّابقات (Prefixes) غير المُطابقة تمامًا؛ فيبحث عن أطول تطابق في الموقع مع معرّف المورد ثمّ يقوّمه بالطّريقة التّاليّة: إذا كانت كتلة الموقع الّتي يوجد بها أطول تطابق تستخدِم المغيّر ~^ فسيُنهي Nginx فورًا بحثَه ويختار هذه الكتلة للإجابة على الطّلب. إن لم تكُن الكتلة الّتي يوجد بها أطول تطابق تستخدِم المغيّر ~^ فسيحتفظ بها Nginx دون أن يُنهي البحث، بحيث يُمكن له اختيّارها عند الحاجة. ينتقل Nginx، بعد تحديد الكتلة ذات التّطابق الأطول والاحتفاظ بها، إلى تقويم كتل المواقع الّتي تستخدِم التّعابير النّمطيّة، سواء كانت تتأثّر بحالة الأحرف أم لا. يُقوِّم Nginx التّعابير النمطيّة بالتّسلسل، ويختار فورًا أوّل كتلة موقع يُوافق تعبيرها النّمطيّ معرّفَ مورد الطّلب. إن لم يعثُر خادوم الويب على موقع ذي تعبير نمطيّ يُوافق معرّف المورد المطلوب فإنّه يختار الكتلة المُحتفَظ بها سابقًا للإجابة على الطّلب. من المهمّ هنا أن نفهم أنّ Nginx، مبدئيًّا، يُفضّل كتل الموقع الّتي تُطابق الطّلب عبر تعابير نمطيّة؛ إلّا أنّه يبدأ بالبحث عن تطابق في كتل المواقع الّتي لا تستعمل تعابير نمطيّة، وهو ما يسمح لمسؤول خادوم الويب بتجاوز ميل Nginx إلى تفضيل التّعابير النّمطيّة عبر تحديد المغيِّرات = و~^. من المهمّ أيضًا الانتباه إلى أنّ الاختيّار في كتل المواقع الّتي تستخدِم التّطابق المُبدَأ يكون حسب التّطابق الأطول والأكثر تحديدًا غالبًا. في حين أنّ تقويم التّعابير النمطيّة (وبالتّالي الاختيّار) يتوقّف فور الحصور على تطابق وهو ما يعني أنّ ترتيب كتل المواقع الّتي تستخدم التّعابير النّمطيّة له تأثير كبير على الاختيّار. 4- متى يتجاوز تقويم كتلة الموقع إلى مواقع أخرى؟عند اختيّار كتلة Location للإجابة على طلب فإنّ التّعامل معه، ابتداءً من هذه النّقطة، يحدُث بالكامل ضمن إطار الكتلة المُختارة. فقط هذه الكتلة والتّعليمات المتفرّعة عنها هي من يُحدّد كيف يُتعامل مع الطّلب، دون تدخّل من كتل Location من نفس المستوى في البنية الشّجريّة. تسمح هذه القاعدة العامّة بتصميم كتل Location يُمكن التّنبّؤ بعملها. على الرّغم من ذلك، يجب الانتباه إلى وجود حالات تتسبّب تعليمات داخل الكتلة المُختارة في البحث من جديد عن موقع. يُمكن لهذا الاستثناء من القاعدة العامّة “كتلة موقع واحدة فقط” أن يُحدِث تأثيرات على كيفيّة الإجابة على الطّلب، بحيث يُخالف التّوقّعات الّتي كانت عندك أثناء تصميم كتل المواقع. في ما يلي بعض التّعليمات الّتي قد تؤدّي إلى إعادة توجيه من داخل الكتلة المختارة: indextry_filesrewriteserror_pageنعرض باختصار لكلّ واحدة من هذه التّعليمات. تتسبّب تعليمة index دائمًا في إعادة توجيه إن استُخدِمت للتّعامل مع الطّلب. يُستخدَم التّطابق التّام غالبًا لتسريع اختيّار كتلة الموقع عبر إنهاء الخوارزميّة فور حدوث هذا التّطابق. مع ذلك، إن استخدمت التّطابق التّامّ في حال الطّلب على مجلَّد فإنّه توجد إمكانيّة كبيرة لإعادة توجيه الطّلب إلى موقع آخر للإجابة الفعليّة عليه. تُطابق أوّل كتلة في المثال التّالي معرّف المورد exact/، إلّا أنّ تعليمة index الّتي ترثها هذه الكتلة تتسبّب في إعادة توجيه إلى الكتلة الثّانيّة: index index.html; location = /exact { . . . } location / { . . . }إذا احتجت أن يبقى تنفيذ الطّلب داخل الكتلة الأولى، في المثال أعلاه؛ فسيتطلّب ذلك منك استخدام وسيلة أخرى لتلبيّة الطّلب على المجلّد. يُمكنك مثلًا استخدامُ فهرس غير صالح لهذه الكتلة ثمّ تفعيل تعليمة autoindex: location = /exact { index nothing_will_match; autoindex on; } location / { . . . }هذه إحدى الوسائل لمنع index من تبديل السّيّاق، ولكنّها وسيلة غير ناجعة في أغلب الإعدادات. يُستخدَم التّطابق التّامّ في المجلّدات كثيرًا في بعض الأمور مثل إعادة كتابة الطّلب Request rewriting (الّذي ينتُج عنه البحث من جديد عن الموقع). قد تتسبّب تعليمة try_files هي الأخرى في إعادة تقويم عمليّة اختيّار الموقع. تطلُب هذه التّعليمة من Nginx التحقّق من وجود مجموعة مسمّاة من الملفّات أو المجلّدات؛ قد يكون المُعطى الأخير لتعليمة try_files معرّفَ مورد يُعيد Nginx التّوجيه إليه. فلنأخذ الإعداد التّالي مثالًا للشّرح: root /var/www/main; location / { try_files $uri $uri.html $uri/ /fallback/index.html; } location /fallback { root /var/www/another; }سيختار Nginx الكتلة الأولى، في المثال أعلاه، في حال الطّلب على blahblah/. تبحث الكتلة عن ملفّ blahblah في المجلّد var/www/main/، وإن لم تعثُر عليه تبحث عن ملفّ blahblah.html؛ فإن لم تجد هذا الأخير تبحث عن مجلَّد blahblah/ ضمن var/www/main/. إذا فشلت كلّ هذه المحاولات يُعيد Nginx توجيه الطّلب إلى fallback/index.html/ وهو ما يتسبّب في استدعاء كتلة موقع الأخرى، الثّانيّة في المثال. في المحصّلة فإنّ الملفّ var/www/another/fallback/index.html/ سيكون الإجابة على الطّلب. تعليمة rewrite أيضًا قد تتسبّب في تجاوز كتلة الموقع المختارة عبر الخوارزميّة المشروحة أعلاه. يبحث Nginx عند استخدام المعطى الأخير مع تعليمة rewrite أو في حالة عدم ذكر أيّ معطى على الإطلاق، يبحث عن تطابق جديد اعتمادًا على نتيجة rewrite. نُعيد استخدام المثال الأخير مع إضافة تعليمة rewrite للكتلة الأولى؛ يُمكن أن نلاحظ أنّ الطّلب يُمرَّر في بعض الحالات ماباشرةً إلى كتلة Location الثّانيّة دون تنفيذ تعليمة try_files: root /var/www/main; location / { rewrite ^/rewriteme/(.*)$ /$1 last; try_files $uri $uri.html $uri/ /fallback/index.html; } location /fallback { root /var/www/another; }تُجيب كتلة الموقع الأولى ابتداءً في المثال أعلاه على الطّلب rewriteme/hello/؛ ثمّ يأتي الطّلب لتعليمة rewrite الّتي تُعيد كتابته ليُصبح hello/ فيبدأ Nginx البحث من جديد عن موقع للإجابة على الطّلب ويعثُر من جديد على تطابق مع الكتلة الأولى ثمّ تُنفَّذ عليه تعليمة try_files وفقًا للآليّة المشروحة في مثال استخدام تعليمة try_files. أمّا إذا كان الطّلب على rewriteme/fallback/hello/ فستُطابق كتلة الموقع الأولى الطّلب ثمّ تنفَّذ عليه تعليمة rewrite الّتي تعيد كتابته فيصبح fallback/hello/ ممّا ينتُج عنه مطابقة مع كتلة الموقع الثّانيّة وبالتّالي تُجيب الطّلب. تحدُث حالة مُشابهة مع تعليمة return عند إرسال رمز الحالة Status code رقم 301 أو 302. الفرق في هذه الحالة هي أنّ النتيجة عبارة عن طلب جديد كلّيًّا على هيئة إعادة توجيه خارجيّة External redirect مرئيّة. نفس الشيء يُمكن أن يحدُث مع تعليمة rewrite عند استخدام عَلَميْ redirect و permanent. إلّا أنّ هذه الحالات يجب ألا تكون غير متوقّعة، فإعادة التّوجيه الخارجيّة المرئيّة ينتُج عنها دومًا طلب جديد. ملحوظة 1: الفرق بين إعادة التّوجيه الدّاخليّة والخارجيّة هو أنّ الأولى لا تُنهي طلب العميل الحاليّ بل تُحيله إلى مسار آخر ضمن خادوم الويب؛ أمّا الخارجيّة فتُنهي طلب العميل مع إخباره بمعرّف المورد الجديد الّذي يجب عليه إرسال طلب آخر للحصول عليه. ملحوظة 2: رموز الحالة هي أعداد يستخدمها بروتوكول HTTP ليُشعِر بالحالة الّتي انتهى عليها تنفيذ الطّلب. تُقسَّم إجابات HTTP إلى خمس مجموعات: إجابات بمعلومات، إجابات بنجاح الطّلب، إعادات توجيه، أخطاء من جانب العميل و أخطاء من جانب الخادوم. يُمكن أن تؤدّي تعليمة error_page إلى إعادة توجيه داخليّة مشابهة لتلك الّتي تُنشئها تعليمة try_files. تُستخدَم تعليمة error_page لتحديد ما يجب أن يحدُث عند تلقّي رموز حالات معيَّنة. على الأرجح لن تُنفَّذ تعليمة error_page إذا كانت تعليمة try_filesمضبوطة، فهذه الأخيرة تتعامل مع كامل دورة حياة الطّلب. فلنأخذ المثال التّاليّ: root /var/www/main; location / { error_page 404 /another/whoops.html; } location /another { root /var/www; }تستجيب الكتلة الأولى الّتي تقدّم ملفّات من المجلَّد var/www/main/ لجميع الطّلبات، ما عدا تلك الّتي تبدأ بanother/. إن لم يُعثَر على الملفّ المطلوب ضمن المجلَّد المذكور (رمز الحالة 404) فسيُعاد توجيه الطّلب إلى الملفّ another/whoops.html/ ممّا ينتُج عنه البحث عن كتلة موقع تتعامل مع الطّلب الجديد. يرسو البحث على كتلة الموقع الثّانيّة الّتي تُجيب بالملفّ var/www/another/whoops.html/. يُساعد فهمُ الظّروف الّتي تؤثّر على Nginx وتجعله يبحث عن كتلة موقع جديدة تلبّي الطّلب على توقّع سلوك Nginx عند إنشاء طلبات. خاتمةيُسهّل فهمُ الإجراءات الّتي يتبعها Nginx في الاستجابة لطلبات العملاء كثيرًا من عمل مسؤول الموقع، فيمكنك معرفة كتلة الخادوم الّتي سيختارها Nginx للإجابة حسب كلّ طلب على حدة. كما ستكون لديك القدرة على معرفة كتلة الموقع الّتي سيختارها خادوم الويب اعتمادًا على معرّف المورد المذكور في الطّلب. على العموم تُمكنّك معرفة الطّريقة الّتي يختار Nginx وفقها الكتل المختلفة من تتبّع السّيّاقات الّتي يطبّقها Nginx من أجل الإجابة على كلّ طلب. ترجمة بتصرّف لمقال Understanding Nginx Server and Location Block Selection Algorithms.

يمكِن لـِ Nginx، أحد أكثر خواديم الويب انتشارًا؛ التّعاملُ بنجاح مع عملاء عدّة يتّصلون بالتّزامن، كما يُمكنه العمل بوصفه خادوم ويب، خادوم بريد أو وسيطًا عكسيًّا Reverse proxy. سنتطرّق في هذا الدّليل إلى بعض كواليس الآليّة الّتي تحدّد كيف يتعامل Nginx مع طلبات العملاء Client requests. يُساعد فهمُ هذه الآليّة في معرفة كيف تعمل إعدادات الكتلة (Block configurations) في خادوم ويب Nginx وخصوصًا كتلتَيْ Server (الخادوم) وLocation (الموقع). كما أنّه يجعل من تعامل Nginx مع طلبات العملاء أكثر قابليّةً للتّوقّع والتخمين. إعدادات كتلة Nginxيقسّم Nginx إعداداتِ تقديم المحتوى إلى كُتل تنتظِم في بنية شجريّة Hierarchical. يبدأ Nginx عندما يتلقّى طلبًا إجراءاتِ تقرير كُتَل الإعداد الّتي يجب استخدامُها للتّعامل مع الطّلب. سنتحدّث في هذا الدّليل عن آليّة التّقرير هذه. يتحدّث الجزء الأوّل من هذا الدّليل عن كتلة Server، أمّا الثّاني فيتناول كتلة Location. تعرّف كتلة Server، وهي مجموعة فرعيّة من إعدادات Nginx، خادومًا افتراضيًّا يتعامل مع طلباتٍ من نوع محدَّد. يعرّف مدراء الخواديم عادةً كتلَ خادوم عدّة ثمّ يضبطونها للتّعامل مع الطّلبات حسب اسم النّطاق Domain name، أو المنفذ Port، أو عنوان IP الذي يأتي عبره الطّلب. تقبع كتلة Location ضمن كتلة من نوع Server (كتلة خادوم)، وتُستخدَم لتعريف الكيفيّة الّتي سيتعامل بها خادوم ويب Nginx مع الطّلبات على موارد الخادوم والمعرّفات الكليّة لهذه الموارد Universal Resource Identifier, URI. يُمكن أن تُقسَّم مساحة المعرّفات الكليّة للموارد URIs بالطّريقة الّتي يراها المدير عن طريق استخدام كتل Location، فنموذج الكتل مرن للغاية. كيف يقرّر Nginx كتلة Server الّتي ستتعامل مع الطّلب؟يحتاج Nginx، ما دام يسمح بتعريف كُتَل Server عدّة تعمل على أنّها خواديم ويب افتراضيّة متفرّقة، يحتاج لوسيلة يعرف بها كتلة Server الّتي ستتولّى تلبيّة الطّلب. يُعرّف خادوم ويب Nginx نظامَ فحص يُستخدَم للعثور على كتلة Server الأكثر مُطابقةً للطّلب. يهتم Nginx أثناء عمليّة الفحص بتعليمتَيْن Directives على مستوى كتلة الخادوم، وهما listen وserver_name. 1- تحليل تعليمة listen بحثًا عن تطابقات ممكنةينظُر Nginx أوّلًا إلى عنوان IP الطّلب ومنفَذه؛ ثمّ يبحث عن تطابق بين هاتين المعلومتيْن مع محتوى تعليمة listen في كلّ كتلة خادوم. يُنشئ Nginx إثر هذه الخطوة قائمةً بكُتل الخواديم الّتي يُمكن أن تلبّي الطّلب. تعرّف تعليمة listen عنوان IP والمنفَذ الّذيْن ستُجيب كتلة الخادوم الطّلبات الآتيّة منهما. إذا لم تتضمّن كتلة الخادوم تعليمة listen فإنّ المعطيات 0.0.0.0:80 تُمنح للتّعليمة بشكل افتراضيّ (أو 0.0.0.0:8080 إذا كان مستخدم عاديّ غير المستخدم الجذر هو من يشغّل خادوم ويب Nginx). تسمح هذه المعطيات لكتلة الخادوم بالإجابة عن طلبات عبر المنفذ 80 على كلّ الواجهات Interfaces؛ إلّا أنّ المعطيات الافتراضيّة لا تمثّل ثقلًا كبيرًا في عمليّة اختيّار الخادوم. يُمكن ضبطُ تعليمة listen: بذكر عنوان IP ومنفَذ.بذكر عنوان IP فقط؛ في هذه الحالة يُستخدم المنفذ الافتراضيّ 80.بذكر منفَذ فقط؛ في هذه الحالة تستجيب لأي طلب يأتي عبر هذا المنفذ على كلّ الواجهات.بتحديد مسار إلى مقبس يونكس Unix socket.سيقتصر تأثير الخيّار الأخير - غالبًا - على الطّلبات الّتي تمرّر بين مجموعة خواديم. يقرّر Nginx كتلة الخادوم الّتي سيُرسل إليها الطّلب اعتمادًا على خصوصيّة تعليمة listen وذلك وفقًا للقواعد التّاليّة: تُكمَّل الأجزاء غير المكتملة من تعليمة listen بالقيّم الافتراضيّة. الأمثلة التّاليّة توضّح كيف تُكمّل تعليمة listen: كتلة خادوم لا توجد بها تعليمة listen ستستعمل القيمة 0.0.0.0:80.كتلة خادوم مضبوطة على العنوان 111.111.111.111 ولا تعرّف منفذًا تستعمل القيمة 111.111.111.111:80.كتلة خادوم مضبوطة على المنفذ 8888 دون عنوان IP، تستخدم القيمة 0.0.0.0:8888.يكوّن Nginx قائمة بكتل الخواديم الّتي تُطابق الطّلب، وبالتحديد عنوان IP والمنفذ. يعني هذا أنّ أيّة كتلة تستخدم عنوان 0.0.0.0 (مطابقة كلّ الواجهات) لن تُختار إن وُجدت كتلة تستخدم عناوين IP تُطابق الطّلب. في جميع الحالات يجب أن تُطابقَ الكتلة المنفذ بالضّبط. إذا وُجدت كتلة واحدة تُطابق الطّلب، ولم توجد أخرى بنفس المستوى من المُطابقة، فستُستخدَم للإجابة على الطّلب؛ أمّا إذا وُجدت عدّة كتل مع نفس المستوى من المطابقة فإنّ Nginx يبدأ بالنّظر في قيمة تعليمة server_name بالنّسبة لكلّ كتلة خادوم. يجب الانتباه إلى أنّ Nginx لن ينظُر في قيمة تعليمة server_name إلّا إذا احتاج للتّفريق بين كتل خواديم لديها تعليمة listen بنفس المستوى من المطابقة للطّلب. على سبيل المثال؛ إذا كان example.com مُستضافًا على المنفذ 80 من 192.168.1.10 فـإنّ كتلة الخادوم الأولى فقط في المثال أدناه، هيّ من سيستجيب للطّلبات الموّجّهة إلى example.com، على الرّغم من أنّ تعليمة server_name في الكتلة الثّانيّة تحوي القيمة example.com. server { listen 192.168.1.10; . . . } server { listen 80; server_name example.com; . . . }أمّا إذا وُجِدت أكثر من كتلة خادوم تُطابق بنفس المستوى من التّحديد الطّلب؛ فإنّ الخطوة التّاليّة هي فحص محتوى تعليمة server_name. 2- تحليل تعليمة server_name للاختيّار بين التّطابقاتالخطوة المواليّة، في حال وجود كتل خواديم عدّة بنفس المستوى من التّحديد توافق الطّلب، هي تحليل تعليمة server_name. يتحقّق Nginx من ترويسة Header في الطّلب تُسمّى Host (المستضيف). تحوي ترويسة Host اسم النّطاق أو عنوان IP الّذي يُريد العميل الوصول إليه. يُحاول Nginx إيجاد كتلة الخادوم الأكثر مطابقةً لترويسة Host من بين كتل الخواديم المتبقيّة بعد تحليل تعليمة listen. يتبع Nginx الوصفة التّاليّة لإيجاد الكتلة المناسبة: يبحث خادوم الويب عن كتلة خادوم تكون قيمة تعليمة server_name مطابقةً تمامًا لترويسة Host الموجودة في الطّلب. إذا عثر على تعليمة server_name يتحقّق فيها الشّرط فإنّ الكتلة المرتبطة بها هي الّتي تُستخدَم. إذا كانت هناك عدّة تعليمات مطابقة فإنّ أوّل كتلة خادوم هيّ الّتي ستُختار. إن لم يعثُر على مطابقة تامّة يبحث Nginx عن كتلة خادوم تبدأ قيمة تعليمة server_name فيها بحرف بَدَل Wildcard (يُشار إليه بعلامة * في بداية الاسم) بحيث توافق التّعليمة ترويسة المستضيف في الطّلب. إذا عثر على تعليمة server_name يتحقّق فيها الشّرط فإنّ الكتلة المرتبطة بها هي الّتي تُستخدَم. أمّا إذا كانت هناك عدّة تعليمات فإنّ التّعليمة ذات التّطابق الأطول (عدد الأحرف) هيّ الّتي ستُختار. إن لم يُعثُر على مُطابقة باستخدام حرف بدل في بداية قيمة التّعليمة فإنّ Nginx يبحث عن تعليمة server_name تنتهي بحرف بدل (يُشار إليه بعلامة * في نهاية الاسم) بحيث توافق التّعليمة ترويسة المستضيف في الطّلب. إذا عثر على تعليمة server_name يتحقّق فيها الشّرط فإنّ الكتلة المرتبطة بها هي الّتي تُستخدَم. أمّا إذا كانت هناك عدّة تعليمات فإنّ التّعليمة ذات التّطابق الأطول (عدد الأحرف) هيّ الّتي ستُختار. إن لم يعثُر Nginx على مُطابقة باستخدام حرف بدل في نهاية قيمة التّعليمة فإنّه يبحث عن كتلة خادوم تعرّف تعليمة server_name عن طريق تعبير نمطيّ Regular expression (يُشار إليه بعلامة ~ قبل الاسم). يستخدِم Nginx أوّل كتلة خادوم يُوافق تعبير تعليمة server_name النّمطيّ فيها ترويسة المستضيف. إن لم يوجد تطابُق باستخدام التّعبير النّمطيّ يختار Nginx كتلة الخادوم الافتراضّية لعنوان IP والمنفَذ المستخدَم. يوجد لكلّ ثنائيّ عنوان IP/منفذ كتلة خادوم مبدئيّة Default تُستخدَم إن لم تؤدِّ الآليّة الموصوفة أعلاه للعثور على كتلة خادوم. كتلة الثّنائيّ عنوان IP/منفذ المبدئيّة هيّ الكتلة الأولى في الإعداد أو تلك الّتي تحوي خيّار default_server ضمن تعليمة listen (يغلِب مفعول خيّار default_server، إذا كان موجودًا، مفعول الكتلة الأولى). لا يُمكن أن يوجد خيّار default_server في أكثر من مرّة بالنّسبة لكلّ عنوان IP/منفذ. نشرح في الفقرة التّاليّة كلّ نقطة من آليّة العمل أعلاه. 3- أمثلةإذا وجدت تعليمة server_name تُطابق تمامًا ترويسة المستضيف فسيقع على الكتلة المرتبطة بها الاختيّار للإجابة على الطّلب. إذا كانت ترويسة Host الموجودة في الطّلب تحوي host1.example.com فإنّ الخادوم الثّاني في المثال أدناه هو الّذي سيقع عليه الاختيّار: server { listen 80; server_name *.example.com; . . . } server { listen 80; server_name host1.example.com; . . . }إن لم يوجد تطابق كامل يبحثُ Nginx عن تعليمة server_name تبدأ بحرف بَدَل ويتحقّق من توافقها مع المستضيف في الطّلب. يختار خادوم الويب أطول قيمة في server_name من بين تلك الّتي تُطابق الطّلب. في المثال التّالي يختار Nginx كتلة الخادوم الثّانيّة إذا كان العميل يطلُب المستضيف www.example.org: server { listen 80; server_name www.example.*; . . . } server { listen 80; server_name *.example.org; . . . } server { listen 80; server_name *.org; . . . }ملحوظة: كلّ من الكتلة الثّانيّة والثّالثة توافق المستضيف في الطّلب (www.example.org)؛ إلّا أنّ قيمة server_name في الكتلة الثّانيّة أطول. تُقرأ قيمة الكتلة الثّانيّة في المثال أعلاه “جميع المستضيفات الّتي تنتهي بexample.org. أمّا الكتلة الثّالثّة فتقرأ قيمة server_name “جميع المستضيفات الّتي تنتهي بorg.. يُمكن ملاحظة أنّ قيمة server_name في كتلة الخادوم الثّانيّة أكثر تحديدًا. إذا لم يجد Nginx كتلة الخادوم المناسبة في قيّم server_name الّتي تبدأ بحرف بدل، فإنّه يبحث في كتل الخادوم الّتي تنتهي قيّم server_name فيها بحرف بدل. مثل ما يحدُث في الحالة السّابقة، يختار خادوم الويب أطول قيمة في server_name من بين تلك الّتي تُطابق الطّلب. إذا كان المستضيف المحدّد في الطّلب هو www.example.com فإنّ Nginx سيختار، في المثال التّالي، كتلة الخادوم الثّالثة. server { listen 80; server_name host1.example.com; . . . } server { listen 80; server_name example.com; . . . } server { listen 80; server_name www.example.*; . . . }ملحوظة: تُقرأ قيمة server_name في كتلة الخادوم الثّالثة في المثال أعلاه “جميع المستضيفات الّتي تبدأ ب.www.example. مجدّدًا، إذا لم يعثُر Nginx على تطابق باستخدام أحرف البدل في نهاية قيمة التّعليمة فإنّه سينتقل إلى محاولة مطابقة قيمة Host في ترويسة الطّلب بقيّم server_name المعرّفة بتعابير نمطيّة ويختار أوّل كتلة خادوم تُطابق فيها قيمة server_name قيمة Host. إذا كانت قيمة Host هي www.example.com فإنّ Nginx سيختار، في المثال التّالي، كتلة الخادوم الثّالقة للإجابة على الطّلب: server { listen 80; server_name example.com; . . . } server { listen 80; server_name ~^(www|host1).*\.example\.com$; . . . } server { listen 80; server_name ~^(subdomain|set|www|host1).*\.example\.com$; . . . }ملحوظة: يُقرأ التّعبير النّمطيّ أعلاه “يبدأ اسم المستضيف بإحدى الكلمات التّاليّة set، www، host1 أو subdomain؛ قد يتبعها حرف أو عدد غير محدّد من الحروف، ثمّ نقطة ثم كلمة example ثمّ نقطة ثمّ com.“. للمزيد حول التّعابير النّمطيّة راجع درس مقدمة في التعابير النمطية Regular Expressions. إذا لم يتمكّن Nginx من العثور على أي تعليمة server_name مُطابقة لقيمة Host عبر الإجراءات السّابقة فإنّه يختار الخادوم المبدئي الموافق للثّنائي عنوان IP/المنفَذ الّذي أتى عليه الطّلب.