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

مقدّمة نظام أسماء الّنطاقات، بالإنجليزية Domain Name System ويُختصَر ب DNS، هو أحد أكثر مجالات إعداد المواقع والخواديم صعوبةً على المتعلمين. فهْم آلية عمل نظام أسماء النطاقات سيُساعدك في تشخيص مشاكل إعدادات النفاذ إلى مواقعك؛ كما أنه يمنحك فرصة التعمق في فهم كيف تجري الأمور خلف الكواليس. سنتطرّق في هذا الدّليل إلى بعض المفاهيم الأساسية لنظام أسماء النّطاقات بحيثُ تُصبح جاهزا للعمل على إعدادات DNS لديك. يُفترَض - بعد قراءة هذا الدّليل - أن تكون لديك القدرة على إعداد اسم النطاق Domain name الذي تمتلكه على DigitalOcean أو ضبط خادومك الخاص لتشغيل DNS. فلنبدأ بتعريف بعض المفاهيم الأساسية حول كيف يعمل النظام، قبل الشروع في إعداد خواديمك الخاصة لحل نطاقك أو ضبط نطاقاتنا في لوحة التحكّم. مُصطلحات النطاق يجب أولا البدء بتعريف المصطلحات التي سنستخدمها؛ فبالرغم من أن بعض المواضيع تبدو مألوفة في أُطُر مُغايِرة، إلا أن الكثير من العبارات المُستخدمة في إطار الحديث عن أسماء النطاقات ونظام DNS لا تظهر بكثرة أثناء التطرق لمجالات أخرى من الحوسبة. فلنبدأ بالأبسط. نظام أسماء النطاقات نظام أسماء النطاقات المعروف اختصارًا ب"DNS" هو نظام التشبيك المُستخدَم لتحويل أسماء سهلة التذكّر إلى عناوين فريدة. اسم النّطاق اسم النّطاق هو الاسم سهل التذكر المستخدَم للرّبط بمورد على شبكة الإنترنت. على سبيل المثال، "google.com" اسمُ نطاق. سيقول بعض الأشخاص إن الجزء "google" هو اسم النطاق؛ ولكن يُمكننا على العموم الحديث على الصيغة المركّبة، أي "google.com" باعتبارها اسمَ النطاق. المَسار "google.com" مرتبِط بالخواديم المملوكة لشركة Google. نظام أسماء النطاقات يُتيح لنا إمكانية الوصول إلى خواديم Google عند كتابة "google.com" في شريط عناوين المتصفّح. عنوان IP عنوانIP هو ما نُسمّيه موقعا قابلا للعنونة على الشّبكة. كل عنوان IP يجب أن يكون فريدًا في شبكته. عند الحديث عن مواقع الوب فإن هذه الشبكة تشمل الإنترنت بأكملها. الإصدار الرّابع من عناوين IP - الأكثر استخدامًا والذي يُرمز له بIPv4 يُكتَب على شكل أربع مجموعات من الأعداد، تحوي كل مجموعة ثلاثة أرقام على الأكثر ويُفصَل بين المجموعات الأربع بنقطة. على سبيل المثال فإن "111.222.111.222" يمكن أن يكون عنوانَ IP صالحًا. نظام DNS يُترجِم اسمًا إلى هذا العنوان. بهذه الطّريقة لن تحتاج إلى حفظ مجموعة معقّدة من اﻷرقام لكل موقع توَدّ زيارته على الشبكة. النطاق ذو المستوى العلوي Top-Level Domain النطاق ذو المستوى العلوي (النطاق العلوي)، TLD اختصارًا، هو الجزء الأكثر شمولية من النطاق. النطاق العلوي هو القسم الموجود في أقصى يمين اسم النطاق (يُفصَل بين أجزاء اسم النطاق بنقطة). النطاقات العلوية المشهورة هي: "com"، و"net"، و"org"، و"gov"، و"edu"، و"io". توجد النطاقات العلوية في أعلى التسلسل الهرمي لأسماء النطاقات؛ حيث تَمنح منظمة Internet Corporation for Assigned Names and Numbers (ICANN) - المختصّة بتوزيع عناوين IP وأسماء النطاقات - لبعض الجهات صلاحية التحكم بإدارة نطاقات علوية. يُمكن لهذه الجهات بعد ذلك توزيع أسماء نطاقات تابعة للنطاق العلوي الذي تديرُه، عن طريق مسجّل نطاقات Domain registrar عادةً. المُضيف Host لدى مالك النطاق القدرة على تعريف عدة مُضيفات داخل نطاقه. يُشير المُضيف إلى حاسوب أو خدمة مستقلة يُمكن الوصول إليها عن طريق النطاق. على سبيل المثال، يُتيح معظم أصحاب النطاقات إمكانية الوصول إلى خواديم الوب الخاصة بهم عن طريق النطاق "الحاسِر" example.com إضافة إلى تعريف المُضيف "www" (مثال: www.example.com). يمكنك تعريف عدة مُضيفات أخرى داخل النطاق العام؛ فتَمنح الوصول إلى واجهة لبرمجة التطبيقات API عن طريق المُضيف "api" (api.example.com)، أو تعطِي إمكانية استخدام بروتوكول نقل الملفات FTP عن طريق تعريف مُضيف باسم "ftp" أو "files" (ftp.example.com أو files.example.com). لا يوجد تقييد على طول اسم المُضيف، التقييد الوحيد هو أن يكون فريدًا داخل النطاق. النطاق الفرعي SubDomain تحدثنا عن المُضيف في الفقرة السّابقة، في هذه الفقرة سنتطرّق لمفهوم ذي صلة به: النطاق الفرعي. يعمل نظام DNS حسب تسلسل هرمي تتبع فيه عدة نطاقات للنطاقات العلوية. على سبيل المثال فإن النطاقين "google.com" و"ubuntu.com" يندرجان تحت النطاق العلوي "com". عند الحديث عن نطاق فرعي فالمقصود هو أي نطاق يُشكِّل جزءًا من نطاق أكبر. في المثال الذي ذكرناه يمكننا القول بأن "ubuntu.com" هو نطاق فرعي من "com". إجمالاً فإن"ubuntu.com" يُسمّى نطاقا، وبشكل أكثر تحديدًا فإن جزئية "ubuntu" تسمّى نطاقا من المستوى الثاني Second Level Domain، وتُختصَرب SLD. إضافةً إلى ذلك، يمكن لكل نطاق التحكم في نطاقات تتبع له. هذه النطاقات هي ما يُطلق عليه نطاقات فرعية. على سبيل المثال يُمكنك إنشاء نطاق فرعي لقسم التاريخ في مدرستك www.history.school.edu. جزئية "history" هي النطاق الفرعي (على اعتبار أن school.edu هو النطاق التابع للمدرسة). الفرق بين المُضيف والنطاق الفرعي هو أن المُضيف يُعرّف حاسوبًا أو خدمة، في حين أن النطاق الفرعي يُمدِّد النطاق الأب؛ أي أنه طريقة لتقسيم النطاق نفسِه. يُمكن ملاحظة أن الجزء الموجود في أقصى يسارِ اسم النطاق، سواء تعلّق الأمر بمُضيف أو نطاق فرعي، هو الأكثر تحديدًا؛ هذه هي طريقة عمل نظام DNS: من الأكثر إلى الأقل تحديدًا، باتجاه القراءة من اليسار إلى اليمين. اسم النطاق المعرَّف بالكامل Fully Qualified Domain Name اسم نطاق معرَّف بالكامل، FQDN اختصارًا، هو ما يُطلق عليه اسم نطاق مُطلَق. في نظام DNS يُمكن إعطاء اسم نطاق بالنسبة إلى نطاق آخر، وهو ما قد يؤدي إلى بعض الالتباس. اسم النطاق المعرَّف بالكامل FQDN هو اسم مُطلق يحدّد النطاق انطلاقًا من أصل نظام أسماء النطاقات. يعني هذا أن FQDN يُحدد أسماء كل النطاقات التي يتفرّع منها النطاق بما فيها النطاق العلوي TLD. ينتهي اسمُ النطاق المعرَّف بالكامل بنقطة تُشير إلى النقطة الأعلى في التسلسل الهرمي لنظام DNS. النطاق ".mail.google.com" هو نطاق معرَّف بالكامل. النقطة الأخيرة غير ضرورية في بعض البرمجيات التي تتعامل مع FQDN؛ ولكنها مطلوبة للتوافق مع معايير ICANN. خادوم الأسماء Name server خادوم الأسماء هو حاسوب مخصَّص لترجمة أسماء النطاقات إلى عناوين IP. تقوم هذه الخواديم بالجزء الأكبر من العمل في نظام DNS. بما أن مجموع عمليات الترجمة من أسماء نطاقات إلى عناوين IP أكثر بكثير من أن يقوم به خادوم أسماء واحد فإن كل واحد من هذه الخواديم يُمكن أن يُعيد توجيه الطّلبات التي تصله إلى خواديم أخرى أو أن يُفوِّض إدارة مجموعة من النطاقات الفرعية التي هو مسؤول عنها. خواديم الأسماء يمكن أن تكون "ذات سلطة" Authoritative، بمعنى أنها تعطي إجابات عن نطاقات تقع ضمن مسؤوليتها. ما عدا ذلك فإنها تُشير إلى خواديم أخرى أو تُجيب بنسخ تخبِّئها من بيانات خواديم أسماء أخرى. ملف النطاق Zone file ملف النطاق هو ملف نصي بسيط يحوي الترجمات بين أسماء النطاقات وعناوين IP؛ هذه هي الوسيلة التي يعرِف عن طريقها نظام DNS أي عنوان IP يجب الاتصال به عند طلب اسم نطاق معيَّن. توجد ملفات النطاق لدى خواديم الأسماء، وتعرِّف عموما الموارد المتاحة في نطاق محدَّد أو المكان الذي يجب البحث فيه للحصول على هذه المعلومة. السّجلّات Records يُخزّن ملف النطاق المعلومات ضمن سجلات. في شكله الأبسط، السجل هو ترجمة وحيدة لمورِد (مضيف أو نطاق فرعي) واسْم. يُمكن أن يكون السّجل ترجمة لاسم نطاق إلى عنوان IP، أو تعريفًا لخواديم الأسماء المسؤولة عن نطاق، أو تعيينًا لخواديم بريد النطاق، ... إلخ. كيف يعمل نظام أسماء النّطاقات بعد الاطّلاع على بعض المُصطلحات المستخدمة في نظام DNS، سنتطرّق للسؤال: كيف يعمل فعلًا نظام DNS؟ يبدو النظام سهلًا للغاية عند إلقاء نظرة عامة عليه، ولكنه يصبح معقَّدًا جدًا عند الدّخول في التفاصيل. مع ذلك يبقى إجمالًا بنيةًً تحتيةً موثوقا بها، كان لها دور رئيس في تبني الإنترنت بالشكل الذي نعرفها به اليوم. خواديم الجذرRoot servers نظام DNS - كما ذكرنا سابِقًا - مُصمّم ليعمل حسب تسلسل هرمي. في أعلى هذا التسلسل يوجد ما يُعرف بخواديم الجذر. تُشغَّل هذه الخواديم من طرف عدّة منظمات، بتفويض من ICANN. يعمل في الوقت الحالي 13 خادومًا جذرًا.. من ناحية ثانية ونظرًا للعدد الهائل من طلبات ترجمات النطاقات في كل دقيقة، فإن كل واحد من هذه الخواديم معكوس mirrored (جميع العمليات والبيانات مكرّرة على خواديم أخرى).يشترك كل خادوم جذرفي نفس عنوان IP مع خواديمه المعكوسة. عند طلب أحد خواديم الجذر يُمرَّر الطّلب إلى مرآة Mirrorخادوم الجذر الأقرب من المُرِسل. ما العمل الذي تقوم به خواديم الجذر؟ تتعامل خواديم الجذر مع طلبات المعلومات عن نطاقات المستوى العلوي، فعند وصول طلب لا يُمكن لخادوم أسماء من مستوى أدنى التعامل معه؛ يُرسَل طلب إلى خادوم جذر للاستفسار عن النطاق. في الواقع لن يعرف الخادوم الجذر أين يُستضَاف النطاق محل الطّلب، ولكنه يستطيع إعادة توجيه مُرسِل الطّلب Requester إلى خواديم الأسماء التي تتعامل مع النطاق ذي المستوى العلوي المطلوب. في المحصّلة: عند إرسال طلب لعنوان "www.wikipedia.org" إلى خادوم جذر فإنه سيُجيب بعدم توفر نتائج في سجلاته تُوافق "www.wikipedia.org" وذلك بعد بحث في ملفات النطاق التي يحتفظ بها؛ ولكنه سيجد سجلًا للنطاق العلوي "org" ويُعطي لمُرسِل الطّلب عنوانَ خادوم الأسماء المسؤول عن عناوين "org". خواديم النّطاقات العليا TLD Servers بعدها يقوم مُرسِل الطّلب بتوجيه طلب جديد إلى عنوان خادوم الأسماء الذي زوّده به الخادوم الجذر. خادوم الأسماء هذا هو المسؤول عن النطاق العلوي الموجود في الطّلب. يقوم المرسِل بعدها ببعث طلب إلى خادوم الأسماء المسؤول عن النطاق العلوي "org" لسؤاله ما هو عنوان "www.wikipedia.org". يجيب خادوم الأسماء - بعد بحث عن "www.wikipedia.org" في ملفات النطاق الخاصة به - بعدم وجود هذا النطاق في ملفاته. غير أنه يعثر على السجل الذي يحوي اسم الخادوم المسؤول عن النطاق "wikipedia.org". لقد اقتربنا كثيرًا من الإجابة التي نبحث عنها. خواديم الأسماء على مستوى النّطاق Domain-Level name server حصل مُرسِل الطّلب الآن على عنوان IP الخاص بخادوم الأسماء المسؤول عن معرفة العنوان الفعلي للهدف. من جديد، يبعث مُرسِل الطلب إلى خادوم الأسماء لسؤاله إن كان يستطيع ترجمة "www.wikipedia.org" إلى عنوان IP. يبحث خادوم الأسماء على مستوى النطاق في ملفات النطاق لديه ويعثر على ملف نطاق يتعلق ب"wikipedia.org". داخل هذا الملف يوجد سجل عن مُضيف باسم "www". في هذا السّجل يوجد عنوان IP الذي يقع عليه المضيف. يبعث خادوم الأسماء بالإجابة النهائية إلى مُرسِل الطلب. ما هو خادوم الأسماء الحالّ Resolving name server؟ في السيناريو أعلاه تحدثنا عن "مُرسِل طلب". ما المقصود ب"مرسِل الطلب" في هذه الحالة؟ مرسِل الطّلب هو في الغالب ما نسميه "خادوم أسماء حالّ" Resolving name server. خادوم أسماء حالّ هو خادوم مُعَد لإرسال الطّلبات إلى خواديم أسماء أخرى؛ أي أنه في الأساس وسيط يلجأ إليه المستخدِم. هذا الوسيط يُخبِّئ نتائجَ طلبات سابقة لتحسين سرعة الإجابة، كما أنه يعرف عناوين خواديم الجذر مما يمكّنه من "حل" resolving الطّلبات التي ليست لديه معرفة بنتائجها. يوجد لدى المستخدم غالبًا عدة خواديم أسماء حالّة مضبوطة، آليًا أو يدويًا، في نظام التشغيل لديه. يوفّر مزوّدو خدمة الإنترنت Internet Service Profider, ISP عادة خواديم أسماء حالّة. بعض المنظمات الأخرى تقوم بنفس الشيء. Google على سبيل المثال تُقدّم خواديم DNS حالّة يُمكنك إرسال الطلبات إليها. أول ما يقوم به حاسوبك عند إدخال مسار في شريط العنواين على المتصفّح هو البحث في الموارد المحلّية لديه؛ فيتحقق من ملف المضيفات Hosts المحلّي وأماكن أخرى على جهازك. في حال عدم الحصول على إجابة يُرسل طلبًا إلى خادوم أسماء حالّ وينتظر عنوان IP المورِد الذي يبحث عنه. يقوم خادوم الأسماءالحالّ بعدها بالنظر في البيانات المخبَّأة لديه بحثًا عن إجابة وإن لم يجدها يتبع الخطوات التي ذكرناها أعلاه. عمل خواديم الأسماء الحالّة هو في الأساس اختصار آلية الطّلب للمستخدمين النهائيين. كل ما على هؤلاء معرفته هو طريقة سؤال خواديم الأسماء الحالّة عن عنوان مورِد والتأكد من أن خادوم الأسماء الحالّ سيبحث ويعود لهم بالإجابة. ملفّات النطاق تطرّقنا في آلية العمل المذكورة أعلاه إلى "ملفات النطاق" و"السجلّات". ملفات النطاق هي الوسيلة التي تستخدمها خواديم الأسماء لتخزين معلومات النطاقات التي تعرفها. كل نطاق يعرف خادومُ الأسماء معلوماتٍ عنه مخزَّن في ملف نطاق. أغلب الطلبات التي تأتي لخادوم أسماء تبحث عن نطاقات لا يملك ملفات نطاق تخزِّن معلومات عنها. إذا كان خادوم الأسماء مضبوطًا للتعامل مع الاستعلامات بطريقة تكرارية Recursive - مثل خادوم أسماء حالّ - فإنه سيعثُر على الإجابة ويُرسلها لصاحب الاستعلام. أما إن لم يكن كذلك فإنه سيُخبِر صاحب الاستعلام بالجهة التالية التي يجب عليه البحث لديها. تتناسب قدرة خادوم الأسماء على الإجابة على الطّلبات طردًا مع ملفات النطاق التي يُخزنها: ملفات نطاق أكثر تعني قدرة أكبر على الإجابة على الطّلبات بنطاقات تقع تحت مسؤولية الخادوم. يصف ملف النطاق "منطقة" من نظام DNS؛ أي مجموعة فرعية من كامل نظام الأسماء DNS، ويُستخدم عادةً لضبط نطاق واحد فقط حيث يمكن أن يحوي مجموعة من السجلّات تعرّف بمواقع موارد النطاق محل التعريف. يعرّف المُعطى Parameter $ORIGIN افتراضيًا المُستوى الأعلى لسلطة ملف النطاق. لنأخذ مثالًا لملف نطاق مُستخدَم لإعداد النطاق "example.com". في هذا المثال ORIGIN$ سيكون مضبوطًا على ".example.com". هذا الإعداد إما أن يكون في أعلى ملف النّطاق أو في ملف إعداد خادوم DNS الذي يُحيل إلى ملف النطاق. في كلتا الحالتين فالمُعطى يصف المنطقة التي ستكون لديه السلطة عليها. بشكل مشابِه، المُعطى TTL$ يضبط "عُمر" Time to live المعلومة التي يوفرها ملف النطاق. هذا المُعطى هو مؤقِّت يُمكن لخادوم أسماء يستعمل التخبئة Caching الاستعانة به للإجابة على طلبات سبق له الحصول على نتائجها دون إعادة البحث وذلك حتى انقضاء قيمة TTL. أنواع السجلّات يمكن أن توجد عدة أنواع من السجلّات في ملف النّطاق. في ما يلي سنستعرض بعض الأنواع الشّائعة (أو الإلزامية). سجلاّت بداية السّلطة Start of Authority سجل بداية السلطة، SOA اختصارًا، هو سجل إلزامي في كل ملفات النطاق. يجب أن يكون أولَ سجل فعلي في الملف (يُمكن لكل من ORIGIN$ و TTL$ أن يسبقه في الملف)، كما أنه الأكثر تعقيدًا. يأخذ سجل SOA الشكل التالي: domain.com. IN SOA ns1.domain.com. admin.domain.com. ( 12083 ; serial number 3h ; refresh interval 30m ; retry interval 3w ; expiry period 1h ; negative TTL ) فلنشرح دلالة كل جزء من السجل: .domain.com: هذا هو المستوى الأعلى في النطاق (جذر النطاق). يعني هذا الجزء أن الملف يتعلق بالنطاق .domain.com؛ قد تجد مكانه علامة @ التي هي مجرَّد ماسك مكان Placeholder يحل محل محتوى المُعطَى ORIGIN$ الذي تحدّثنا عنه سابقًا. IN SOA: تعني IN هنا إنترنت (ستتكرّر في عدة سجلّات)، أما SOA فيُشير لنوعية السجل (بداية سلطة). .ns1.domain.com: هنا نعرِّف خادوم الأسماء الرئيس الأولي للنطاق. خواديم الأسماء إما أن تكون رئيسة Master أو تابِعة Slave. إذا كان نظام DNS معدًّا ليعمل ديناميكا (تحديث السجلات يتم دون تدخل يدوي)- كما هي الحال هنا - فيجب أن يوجد خادوم "رئيس أولي" Primary master. في حال عدم ضبط DNS للعمل بشكل ديناميكي فهذا الخادوم هو أحد خواديم الأسماء الرئيسة. .admin.domain.com: عنوان البريد الإلكتروني للمسؤول عن النطاق. هنا أُبدِلت علامة "@" بنقطة في العنوان البريدي (admin@domain.com). إذا كان العنوان البريدي يحوي نقطة فيجب إبدالها ب"\" (your.name@domain.com تُصبح your\name.domain.com). 12083: هذا هو الرقم التسلسلي Serial number لملف النطاق. يجب زيادة هذا الرقم في كل مرّة يُعدَّل فيها على ملف النطاق حتى ينتشر ملف النطاق بشكل صحيح، حيثُ إن الخواديم التابعة تتحقق ما إذا كان الرقم التسلسلي الموجود في ملف النطاق لدى الخادوم الرئيس أكبرَ من الرّقم التسلسلي الموجود لديها. إن كان الأمر كذلك فإنها تطلب ملف النطاق الجديد وإلا تستمر في استخدام الملف الموجود لديها. 3h: فترة التجديد Refresh interval باالنسبة للنطاق (3 ساعات في المثال)، أي المدة الزمنية التي يقضيها الخادوم التابِع قبل إرسال استفسار إلى الخادوم الرّئيس عن تغييرات على ملف النطاق. 30m: فترة إعادة المحاولة Retry interval باالنسبة للنطاق (30 دقيقة في المثال هنا). في حال عدم قدرة الخادوم التابع على الاتصال بالخادوم الرئيس عند انقضاء فترة التجديد فإنه ينتظر مدةً مساوية لفترة إعادة المحاولة قبل إعادة محاولة الاتصال. 3w: مدة انتهاء الصلاحية Expiry period. إن لم يستطع الخادوم التابِع الاتصال بالخادوم الرئيس خلال هذه المدة (في المثال هنا 3 أسابيع) فإنه يتوقّف عن إرسال إجابات تتعلَّق بهذا النطاق. 1h: عمر المعلومة السّالب Negative TTL. مُماثل لمعطى TTL$ الذي تحدّثنا عنه مع فرق أنه يُلجأ إليه في حال عدم وجود المعلومة المبحوث عنها. بمعنى أخر: عند وصول طلب عن عنوان اسم غير موجود في الملف لدى الخادزم والإجابة أنه غير موجود فإن أي طلب عن الاسم مجدّدا سيُرد عليه بأنه غير موجود وذلك مدة ساعة (في المثال هنا) قبل البحث عنه مرة أخرى. ملحوظة: النص الموجود بعد النقطة-الفاصلة ";" على نفس السطر تعليق ولا يدخُل في إطار الإعدادات. سجلات A و AAAA يستعمل السّجلّان A و AAAA لتعيين مضيف إلى عنوان IP. يُستخدَم السجل "A" لتعيين مضيف إلى عنوان IP من الإصدار الرابع IPv4 بينما يُستخدَم السجل "AAAA" لتعيين مضيف إلى عنوان IP من الإصدار السّادس IPv6. تأتي الهيئة العامة لهذه السجلات على الشكل التالي: host IN A IPv4_address host IN AAAA IPv6_address رأينا أن السجل SOA يستدعي خادومًا رئيسًا أوليًا باسم "ns1.domain.com"؛ سيتوجّب علينا إذن تعيين عنوان IP ل"ns1.domain.com" نظرًا لأنه يقع ضمن النطاق الذي يُعرِّفه هذا الملف. يأخذ هذا السجل الشكل التالي: ns1 IN A 111.222.111.222 لاحِظ أنه لا يتوجَّب علينا هنا ذكر اسم النطاق كامِلًا، يكفينا ذكر اسم المُضيف فقط دون اسم النّطاق المعرَّف بالكامل (FQDN) وسيُكمل خادوم الأسماء الباقي عن طريق قيمة المُعطى ORIGIN$. مع ذلك يُمكننا استخدام FQDN إذا ارتأينا أن لذلك دلالة أكبر: ns1.domain.com. IN A 111.222.111.222 في الغالب هذا هو المكان الذي سنعرّف فيه خادوم الوب "www": www IN A 222.222.222.222 ستوجب علينا أيضًا ذكر العنوان الذي يُحيل إليه النطاق الأصلي، كما يلي: domain.com. IN A 222.222.222.222 كما يُمكن استخدم علامة "@" لتحل محل اسم النطاق الأصلي (domain.com): @ IN A 222.222.222.222 يوجد أيضًا خيار "*" لتعيين أي شيء يقع في النطاق - ولم يُذكَر تعريفه في الملف - إلى عنوان IP محدّد (خادوم الوب في مثالنا هنا): * IN A 222.222.222.222 كل ما ذُكِر في الفقرات السابقة يعمل بالنسبة للإصدار السادس من عناوين IP (IPv6) مع إبدال A بAAAA. سجلّات CNAME السجلّات من نوع CNAME تُعرِّف كُنية Alias للاسم المُتعارَف عليه Canonical name لخادومك (الأسماء المُعرَّفة في سجلات A أو AAAA). على سبيل المثال، يُمكّننا سجل A من تعريف مُضيف باسم "server1" ثم استخدام كُنية "www" للإحالة لهذا المُضيف: server1 IN A 111.111.111.111 www IN CNAME server1 من الجيّد الانتباه إلى أن استخدام الكُنيات يؤدي إلى التقليل من الأداء نظرًا لأنها تحتاج إلى استعلام إضافي إلى الخادوم. يُمكِن الحصول على نفس النتيجة - في الغالب - عن طريق إضافة سجلات من نوع A أو AAAA. الحالة التي يُنصَح فيها بسجل من نوع CNAME هي إتاحة كُنية لمورِد خارج النطاق الحالي. سجلّات MX تُستَخدم سجلّات MX (اختصار ل Mail eXchange، تبادُل البريد) لتعريف تعاملات البريد الإلكتروني داخل النّطاق. يُساعد هذا الأمر على وصول الرسائل إلى خادوم البريد بشكل صحيح. عكسَ الأنواع اﻷخرى، لا تُعيِّن السجلّات من نوع MX غالبًا مُضيفًا إلى شيء آخر (عنوان IP أو سجل). السّبب أن تعريفها ينطبق على كامل النّطاق. على هذا الأساس تأخذ غالبًا الشكل التالي: IN MX 10 mail.domain.com. لاحِظ ألّا وجودَ لاسم مضيف في بداية السّجل. لاحِظ أيضًا وجود رقم إضافي في السّجل. يُستخدم هذا الرّقم للمفاضلة بين خواديم البريد في حال وجود العديد منها. الأرقام الأدنى لديها أولوية أكبر. يجب أن يُشير سجل MX - في الحالة العامة - إلى مضيف مُعرَّف عن طريق سجل A أو AAAA، لا سجل CNAME. إذا كان لدينا خادوما بريد فإن تعريف السجلاّت سيكون على النحو التالي: IN MX 10 mail1.domain.com. IN MX 50 mail2.domain.com. mail1 IN A 111.111.111.111 mail2 IN A 222.222.222.222 في هذا المثال، المُضيف "mail1" هو المُفضَّل كخادوم لتبادل البريد الإلكتروني. الكتابة التالية مكافئة للكتابة السّابقة : IN MX 10 mail1 IN MX 50 mail2 mail1 IN A 111.111.111.111 mail2 IN A 222.222.222.222 سجلّات NS تُعرِّف السجلّات من نوع NS (اختصار لName Server، خادوم الأسماء) خواديم الأسماء المُستخدمة في النطاق. قد تطرح السؤال "إذا كان ملف النطاق موجودًا على خادوم الأسماء فلماذا يحتاج الخادوم لتعريف نفسه؟". أحد العناصر المهمة وراء نجاح نظام DNS هو المستويات المتعدّدة للتخبئة في هذا النظام. بالنسبة لتعريف خادوم الأسماء في ملف النطاق فأحد الأسباب هو أن هذا الملف قد يكون معروضًا من نسخة مخبَّأة موجودة على خادوم أسماء آخر. توجد أسباب أخرى لتعريف خادوم الأسماء في ملف النطاق الموجود عليه ولكن نكتفي بالسبب المذكور دون الدّخول في التفاصيل. مثل السجلّات من نوع MX، ينطبق تعريف سجلّات NS على كامل النّطاق، لذا لا تظهر أسماء مضيفات في هذا السجّل. الشكل العام لسجل NS هو كالتالي: IN NS ns1.domain.com. IN NS ns2.domain.com. ينبغي وجود خادومَيْ أسماء على الأقل معرَّفيْن في كل ملف نطاق حتى يعمل النظام بشكل صحيح في حال حصول مشكل مع أحد الخادوميْن. تعتبرأغلب برامج خواديم DNS ملف النطاق غيرَ صالح إذا كان يعرف خادوم أسماء واحدًا فقط. كالعادة، ضمِّن تعيين المضيفات عبر سجلّات A أو AAAA: IN NS ns1.domain.com. IN NS ns2.domain.com. ns1 IN A 111.222.111.111 ns2 IN A 123.211.111.233 توجد أنواع سجلّات أخرى عديدة يُمكنك استخدامُها، ولكن الأنواع التي تحدّثنا عنها أعلاه هي الأكثر شيوعًا من بين ما سيُصادفك. خاتمة من المفروض أن يكون لديك الآن إدراك جيّد لكيفية عمل نظام DNS. على الرّغم من أن الفكرة العامة للنظام سهلة الفهم نسبيا لمن ألِف طريقة عمله، إلا أنها تبقى أمرًا يواجه مديرو الأنظمة - من غير ذوي الخبرة - بعضَ الصّعوبة في تنفيذه. ترجمة -وبتصرّف- للمقال: An Introduction to DNS Terminology, Components, and Concepts

خدمة اسم النطاق (Domain Name Service) هي خدمة إنترنت تربط بين عناوين IP وأسماء النطاق الكاملة (fully qualified domain names‏ [FQDN])؛ وفي هذه الطريقة، تخفف خدمة DNS من حاجة تذكر عناوين IP. تسمى الحواسيب التي تشغّل خدمة DNS «خواديم الأسماء»، ويأتي أوبنتو مع BIND‏ (Brekley Internet Naming Daemon)، وهو أشهر خدمة لإعداد خادوم أسماء في لينُكس. التثبيتأدخِل الأمر الآتي في مِحَث الطرفية لتثبيت خادوم dns: sudo apt-get install bind9حزمة dnsutils مفيدةٌ جدًا في اختبار واستكشاف أخطاء DNS؛ قد تكون هذه الأدوات مثبتةً مسبقًا على نظامك؛ لكن للتأكد من وجودها أو تثبيتها، أدخِل الأمر الآتي: sudo apt-get install dnsutils الضبطهنالك العديد من الطرق لضبط BIND9؛ لكن بعض أشهر هذه الإعدادات هي خادوم تخزين أسماء (caching nameserver)، الرئيس الأولي (primary master)، والرئيس الثانوي (secondary master). عند ضبطه كخادوم تخزين أسماء، فسيجد BIND9 جوابًا عن استعلامات الأسماء وسيتذكر الجواب عندما يُطلَب النطاق مرةً أخرى.عندما يُضبَط كخادوم رئيس أولي، فسيقرأ BIND9 البيانات لنطاق (Zone) في ملف في المضيف ويستوثق لهذا النطاق.عندما يُضبَط كخادوم رئيس ثانوي؛ فسيحصل BIND9 على بيانات النطاق من خادوم أسماء آخر ويستوثق للنطاق.لمحةتُخزَّن ملفات ضبط DNS في المجلد ‎/etc/bind، ملف الضبط الرئيسي هو ‎/etc/bind/named.conf. يُحدِّد سطر include اسمَ الملف الذي يحتوي على خيارات DNS؛ سطر directory في ملف ‎/etc/bind/named.conf.options يخبر DNS أين سيبحث عن الملفات، جميع الملفات التي يستخدمها BIND ستتعلق بهذا المجلد. يصف ملف ‎/etc/bind/db.root خواديم الأسماء الرئيسية في العالم؛ تتغير هذه الخواديم مع مرور الوقت، لذلك يجب أن يُحدَّث ملف ‎/etc/bind/db.root بين الحين والآخر؛ وذلك يتم عادةً في تحديثات حزمة bind9؛ يُعرِّف القسم zone خادومًا رئيسيًا (master server)، وهو مخزن في ملف مذكور في خيار file. من الممكن ضبط نفس الخادوم ليكون خادوم تخزين أسماء، ورئيس أولي، ورئيس ثانوي؛ ويمكن أن يكون الخادوم «بداية السلطة» (Start of Authority‏ [SOA]) لنطاق واحد، بينما يوفر خدمة ثانوية لنطاق آخر؛ ومع كل هذا فهو يوفر خدمات التخزين للمضيفين على الشبكة المحلية LAN. خادوم تخزين الأسماءالضبط الافتراضي هو العمل كخادوم تخزين؛ كل ما هو مطلوب هو ببساطة إضافة عناوين IP لخواديم DNS التي وفرها لك مزود الخدمة ISP؛ ببساطة، أزل التعليقات عن الأسطر الآتية وعدلها في ملف ‎/etc/bind ‎/named.conf.options: forwarders { 1.2.3.4; 5.6.7.8; };ملاحظة: استبدل 1.2.3.4 و 5.6.7.8 بعناوين IP لخواديم الأسماء لديك. أعد الآن تشغيل خادوم DNS لتفعيل الضبط الجديد، وذلك بتنفيذ الأمر الآتي من مِحَث الطرفية: sudo service bind9 restartراجع القسم «dig» لمزيدٍ من المعلومات حول اختبار خادوم تخزين DNS. الرئيس الأوليسنضبط في هذا القسم BIND9 كخادوم رئيس أولي للنطاق example.com؛ استبدل example.com باسم نطاقك الكامل. ملف تمرير المنطقةلإضافة منطقة DNS إلى BIND9، مما يحول BIND9 إلى خادوم رئيس أولي، فإنَّ أول خطوة هي تعديل ملف ‎/etc/bind/named.conf.local: zone "example.com" { type master; file "/etc/bind/db.example.com"; };ملاحظة: إذا كان سيستقبل bind تحديثاتٍ تلقائيةً عبر DDNS، فعليك استخدام الملف ‎/var/lib/bind ‎/db.example.com‎ بدلًا من ‎/etc/bind/db.example.com سواءً في الملف السابق أو في أمر النسخ الآتي. استخدم الآن ملف نطاق موجود مسبقًا كقالب لإنشاء ملف ‎/etc/bind/db.example.com: sudo cp /etc/bind/db.local /etc/bind/db.example.comعدِّل ملف النطاق الجديد ‎/etc/bind/db.example.com مغيّرًا localhost إلى FQDN لخادومك، واترك النقطة الإضافية في النهاية؛ وغيّر 127.0.0.1 إلى عنوان IP لخادوم الأسماء و root.localhost إلى عنوان بريد صالح، لكن باستخدام "." بدلًا من رمز "@" واترك أيضًا النقطة الإضافية في النهاية؛ عدِّل التعليق لكي يبيّن النطاق الخاص بهذا الملف. أنشئ «سجلًا» (record) للنطاق الأساسي، example.com، وأيضًا أنشِئ سجلًا لخادوم الأسماء، الذي هو في هذا المثال ns.example.com: ; ; BIND data file for example.com ; $TTL 604800 @ IN SOA example.com. root.example.com. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL IN A 192.168.1.10 ; @ IN NS ns.example.com. @ IN A 192.168.1.10 @ IN AAAA ::1 ns IN A 192.168.1.10يجب أن تزيد الرقم التسلسلي (Serial Number) في كل مرة تعدِّل فيها على ملف النطاق؛ إذا عدَّلت عدة تغيرات قبل إعادة تشغيل BIND9، فَزِد الرقم التسلسلي مرةً واحدةً فقط. تستطيع الآن إضافة سجلات DNS في نهاية ملف المنطقة، راجع القسم «أنواع السجلات الشائعة» للتفاصيل. ملاحظة: يحب العديد من مدراء الأنظمة استخدام تاريخ آخر تعديل كرقم تسلسلي للمنطقة؛ مثل 2012010100 الذي هو yyyymmddss (حيث ss هو الرقم التسلسلي). بعد أن أجريت تعديلاتك في ملف النطاق؛ فيجب إعادة تشغيل BIND9 لكي تأخذ التعديلات مجراها. sudo service bind9 restartملف النطاق المعكوسبعد أن ضبطت النطاق لحل الأسماء إلى عناوين IP، فمن المطلوب أيضًا «نطاق معكوس» (Reverse zone)؛ يسمح النطاق المعكوس لخدمة DNS بحل العناوين إلى أسماء. عدِّل ملف ‎/etc/bind/named.conf.local، وأضف ما يلي: zone "1.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192"; };ملاحظة: استبدل 1.168.192 بأول ثلاث خانات تستخدمها شبكتك؛ وسَمِّ ملف النطاق ‎/etc/bind/db.192 تسميةً ملائمةً، حيث يجب أن يُطابِق أول خانة من خانات عنوان الشبكة. أنشِئ الآن ملف ‎/etc/bind/db.192: sudo cp /etc/bind/db.127 /etc/bind/db.192ثم غيِّر ملف ‎/etc/bind/db.192 معدِّلًا نفس الخيارات في ‎/etc/bind/db.example.com: ; ; BIND reverse data file for local 192.168.1.XXX net ; $TTL 604800 @ IN SOA ns.example.com. root.example.com. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS ns. 10 IN PTR ns.example.com.يجب أن يُزاد الرقم التسلسلي في النطاق المعكوس في كل مرة يُعدَّل فيها الملف. فلكل سجل A تضبطه في ‎/etc/bind/db.example.com لعنوان مختلف، يجب عليك أن تنشِئ سجل PTR في ‎/etc/bind/db.192. أعد تشغيل BIND9 بعد إنشاء ملف النطاق المعكوس. sudo service bind9 restartالرئيس الثانويبعد أن يُضبَط الرئيس الأولي فسنحتاج إلى رئيس ثانوي لكي نحافظ على بقاء النطاق في حال لم يكن الرئيس الأولي متوفرًا. في البداية، يجب أن يُسمَح بنقل النطاق في الخادوم الرئيس الأولي؛ أضف الخيار allow-transfer إلى قسم النطاق والنطاق المعكوس في ملف ‎/etc/bind/named.conf.local: zone "example.com" { type master; file "/etc/bind/db.example.com"; allow-transfer { 192.168.1.11; }; }; zone "1.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192"; allow-transfer { 192.168.1.11; }; };ملاحظة: استبدل 192.168.1.11 بعنوان IP لخادوم الأسماء الثانوي. أعد تشغيل خدمة BIND9 في الرئيس الأولي: sudo service bind9 restartالآن ثبِّت على الرئيس الثانوي الحزمة bind9 بنفس الطريقة التي ثبتتها على الأولي؛ ثم عدِّل ملف ‎/etc/bind/named.conf.local وأضف التعاريف الآتية لنطاقَيّ التمرير والعكس: zone "example.com" { type slave; file "db.example.com"; masters { 192.168.1.10; }; }; zone "1.168.192.in-addr.arpa" { type slave; file "db.192"; masters { 192.168.1.10; }; };ملاحظة: استبدل 192.168.1.10 بعنوان IP لخادوم الأسماء الأولي. أعد تشغيل خدمة BIND9 على الخادوم الثانوي: sudo service bind9 restartيجب أن تشاهد في سجل ‎/var/log/syslog شيئًا شبيهًا بما يلي (قُسِّمَت بعض الأسطر لكي تتسع في عرض الصفحة): client 192.168.1.10#39448: received notify for zone '1.168.192.in-addr.arpa' zone 1.168.192.in-addr.arpa/IN: Transfer started. transfer of '100.18.172.in-addr.arpa/IN' from 192.168.1.10#53: connected using 192.168.1.11#37531 zone 1.168.192.in-addr.arpa/IN: transferred serial 5 transfer of '100.18.172.in-addr.arpa/IN' from 192.168.1.10#53: Transfer completed: 1 messages, 6 records, 212 bytes, 0.002 secs (106000 bytes/sec) zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 5) client 192.168.1.10#20329: received notify for zone 'example.com' zone example.com/IN: Transfer started. transfer of 'example.com/IN' from 192.168.1.10#53: connected using 192.168.1.11#38577 zone example.com/IN: transferred serial 5 transfer of 'example.com/IN' from 192.168.1.10#53: Transfer completed: 1 messages, 8 records, 225 bytes, 0.002 secs (112500 bytes/sec)ملاحظة: تُنقَل المنطقة فقط إذا كان الرقم التسلسلي على الأولي أكبر منه على الثانوي؛ وإذا أردت أن يعلم الرئيس الأولي بتعديلات النطاقات في خواديم DNS الثانوية، فعليك إضافة الخيار ;{ also-notify { ipaddress في ملف ‎/etc/bind/named.conf.local كما هو موضح في المثال الآتي: zone "example.com" { type master; file "/etc/bind/db.example.com"; allow-transfer { 192.168.1.11; }; also-notify { 192.168.1.11; }; }; zone "1.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192"; allow-transfer { 192.168.1.11; }; also-notify { 192.168.1.11; }; };ملاحظة: المجلد الافتراضي للنطاقات غير الموثوق منها هو ‎/var/cache/bind؛ يُضبَط هذا المجلد أيضًا في AppArmor ليسمح للعفريت named بالكتابة إليه؛ المزيد من المعلومات حول AppArmor ستتوفر في الدرس القادم. استكشاف الأخطاء وإصلاحهايشرح هذا القسم الطرق التي تستخدم للمساعدة في تحديد المسبب عندما تحدث المشاكل مع DNS و BIND9. الاختبارملف resolv.confأول خطوة في اختبار BIND9 هي إضافة عنوان IP لخادوم الأسماء للذي يستبين أسماء المضيفين؛ يجب أن يُضبَّط خادوم الأسماء أيضًا لمضيف آخر للتأكد مرةً أخرى؛ تحقق إن كان الملف ‎/etc/resolv.conf يحتوي على الأسطر الآتية: nameserver 192.168.1.10 nameserver 192.168.1.11خواديم الأسماء التي تستمع على ‎127.*‎ مسؤولة عن إضافة عناوين IP الخاصة بهم إلى ملف resolv.conf (باستخدام resolveconf)؛ وهذا يتم عبر الملف ‎/etc/default/bind9 بتغيير السطر: RESOLVECONF=no إلى: RESOLVECONF=yes.‏‎ملاحظة: يجب إضافة عنوان IP لخادوم الأسماء الثانوي في حال لم يكن الخادوم الأولي متوفرًا. أداة البحث digإذا ثبتت حزمة dnsutils فيمكنك اختبار إعداداتك باستخدام أداة البحث في DNS المسماة dig: بعد تثبيت BIND9، فاستخدم dig مع بطاقة loopback (أي localhost) للتأكد أنها تستمع على المنفذ 53؛ أدخِل الأمر الآتي في مِحَث الطرفية: dig -x 127.0.0.1يجب أن تُشاهِد أسطرًا شبيهة بالآتي في ناتج الأمر: ;; Query time: 1 msec ;; SERVER: 192.168.1.10#53(192.168.1.10)إذا ضَبطَت BIND9 كخادوم تخزين الأسماء، فابحث (dig) عن نطاق خارجي للتحقق من زمن الطلبية: dig ubuntu.comلاحظ وقت الطلبية في نهاية ناتج الأمر السابق: ;; Query time: 49 msecبعد استخدام dig مرةً أخرى، يجب أن يتحسن الرقم السابق: ;; Query time: 1 msecأداة pingلشرح كيف تَستخدم التطبيقات DNS لكي يستبين اسم المضيف؛ فسنستخدم الأداة ping لإرسال طلب ICMP echo؛ وذلك بإدخال الأمر الآتي في الطرفية: ping example.comما سبق سيختبر إن استطاع خادوم الأسماء استبيان الاسم ns.example.com وتحويله إلى عنوان IP؛ يجب أن تشابه مخرجات الأمر السابق ما يلي: PING ns.example.com (192.168.1.10) 56(84) bytes of data. 64 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=0.800 ms 64 bytes from 192.168.1.10: icmp_seq=2 ttl=64 time=0.813 ms named-checkzoneطريقة رائعة لاختبار ملفات النطاقات لديك هي استخدام الأداة المثبتة مع حزمة bind9؛ تسمح هذه الأداة لك بالتأكد من أن الضبط صحيح قبل إعادة تشغيل BIND9 وجعل التغيرات حيةً. أدخِل الأمر الآتي في الطرفية لاختبار ملف النطاق في مثالنا: named-checkzone example.com /etc/bind/db.example.comإذا كان كل شيءٍ مضبوطًا ضبطًا سليمًا، فستشاهد مخرجاتٍ شبيهةٍ بما يلي: zone example.com/IN: loaded serial 6 OK وبشكل مشابه، أدخل ما يلي لاختبار ملف النطاق العكسي: named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.192يجب أن تكون المخرجات شبيهةً بما يلي: zone 1.168.192.in-addr.arpa/IN: loaded serial 3 OKملاحظة: سيكون الرقم التسلسلي لملف النطاق عندك مختلفًا عادةً. التسجيللدى BIND9 خيارات كثيرة لضبط التسجيل (logging)؛ هنالك خياران رئيسيان هما الخيار channel الذي يضبط أين سيذهب السجل، والخيار category الذي يحدد ما هي المعلومات التي ستُسجَّل. إذا لم يُحدَّد ضبطٌ للتسجيل، فالضبط الافتراضي هو: logging { category default { default_syslog; default_debug; }; category unmatched { null; }; };يشرح هذا القسم ضبط BIND9 لإرسال رسائل debug متعلقة بطلبيات DNS إلى ملفٍ منفصل. سنحتاج أولًا إلى ضبط «قناة» (channel) لتحديد الملف الذي ستُرسَل إليه الرسائل، عدل ملف ‎‎/etc/bind/‎named.conf.local، وأضف ما يلي: logging { channel query.log { file "/var/log/query.log"; severity debug 3; }; };اضبط الآن تصنيفًا لإرسال جميع طلبيات DNS إلى ملف query: logging { channel query.log { file "/var/log/query.log"; severity debug 3; }; category queries { query.log; }; };ملاحظة: لاحظ أن الخيار debug يمكن أن يُضبَط من المرحلة 1 إلى 3؛ وستستخدم المرحلة 1 إذا لم تُحدَّد مرحلة. ولما كان عفريت named يعمل كمستخدم bind، فيجب إنشاء الملف ‎/var/log/query.log وتغيير ملكيته: sudo touch /var/log/query.log sudo chown bind /var/log/query.logقبل أن يتمكن العفريت named من الكتابة إلى ملف السجل الجديد، فيجب أن يُحدَّث ضبط AppArmor؛ أولًا، عدِّل ملف ‎/etc/apparmor.d/usr.sbin.named وأضف: /var/log/query.log w,ثم أعد تحميل ملف ضبطه: cat /etc/apparmor.d/usr.sbin.named | sudo apparmor_parser -rأعد الآن تشغيل BIND9 لكي تأخذ التغييرات مفعولها: sudo service bind9 restartيجب أن ترى الملف ‎/var/log/query.log ممتلئًا بمعلومات الطلبيات؛ هذا مثال بسيط عن ضبط تسجيل BIND9؛ راجع القسم «المزيد من المعلومات» للمزيد من الخيارات المتقدمة. المراجع أنواع السجلات الشائعةيغطي هذا القسم بعض أنواع سجلات DNS الشائعة. سجل A: يربط هذا السجل عنوان IP إلى اسم مضيف. www IN A 192.168.1.12سجل CNAME: يُستخدَم لإنشاء اسم بديل لسجل موجود مسبقًا، لا يمكنك استخدام سجل CNAME للإشارة إلى سجل CNAME آخر. web IN CNAME wwwسجل MX: يُستخدَم لتعريف أين يجب أن يُرسَل البريد؛ يجب أن يشير إلى سجل A، وليس سجل CNAME. IN MX 1 mail.example.com. mail IN A 192.168.1.13سجل NS: يُستخدَم لتعريف أيّة خواديم تُخَدِّم نسخًا من المنطقة؛ يجب أن يشير إلى سجل A، وليس إلى CNAME؛ هذا مكان تعريف الخادومين الأولى والثانوي. IN NS ns.example.com. IN NS ns2.example.com. ns IN A 192.168.1.10 ns2 IN A 192.168.1.11 المزيد من المعلوماتدليل «DNS HOWTO» يشرح الخيارات المتقدمة لضبط BIND9.انظر إلى bind9.net للحصول على شرح معمّق لعمل DNS و BIND9.كتاب «DNS and BIND» هو كتابٌ شائع أصبح في إصداره الخامس؛ وهنالك أيضًا كتاب «DNS and BIND on IPv6».مكان رائع لطلب المساعدة في BIND9 والتعاون مع مجتمع خادوم أوبنتو هو قناة IRC على خادوم Freenode «#ubuntu-server»‎.أيضًا، راجع «BIND9 Server HOWTO» في ويكي أوبنتو.ترجمة -وبتصرف- للمقال: Ubuntu Server Guide: Domain Name Service DNS.

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

يعرض هذا الدّرس والذي يُعتبر الأول من سلسلة ذات ستة أجزاء كيفية إعداد بنية تحتية لتطبيق مكوَّن من خواديم عدة، انطلاقا من الصفر. سيحتوي الإعداد النهائي على آليات للنسخ الاحتياطي Backup، المراقبة Monitoring، نُظُم مركزية للسجلات Centralized logging مما يعزز من إمكانية تشخيص المشاكل واستعادة إعدادات التطبيق عند الحاجة. الهدف الأسمى هو إنشاء نظام إدارة قائم بذاته، والتعريف بأهم المفاهيم والاعتبارات العملية التي ينبغي التنبه لها عند إعداد خادوم موجَّه للإنتاج Production server. ملحوظة: توجد -عادة- أثناء تطوير وإعداد البرامج بيئة إنتاج وبيئة اختبار (أو أكثر). في بيئة الاختبار يستخدم قليلون التطبيق، ويكون المستخدمون في هذه الحالة غالبا مطورين يبحثون عن علل لترقيعها. في الجانب الآخر فإن التطبيق في بيئة الإنتاج يستخدمه المستهدَفون الحقيقيون بالمنتَج (التطبيق)؛ لذا يجب أن يعمل بكفاءة وسلاسة. قراءة الدّرس التالي وفهمه سيساعدك في المضي قدما مع هذا الدّرس: خمسة إعدادات شائعة لتطبيقات الوب.يقدم المقال خطوطا عريضة لإعداد تطبيق موجَّه للإنتاج، بينما يوضح هذا الدّرس كيفية التخطيط لتطبيق نموذجي وإعداده من البداية إلى النهاية. المأمول هو أن يساعدك الدرس في التخطيط لإعداد خادومك الخاص ثم تنفيذ الإعداد حتى ولو كنت تشغِّل حزمة تطبيقات مختلفة تماما. يحيل الدّرس في أحيان كثيرة، نظرا لأنه يغطي مواضيع مختلفة من إدارة النظم، إلى شروحات مفصلة ضمن مقالات أخرى تقدم معلومات إضافية. الهدفسنحصل بنهاية مجموعة المقالات هذه على خادوم إنتاج معدّ لتشغيل تطبيق PHP، ووردبريس على سبيل المثال، يمكن الوصول إليه عبر العنوان https://www.example.com/. سنعدّ أيضا خواديم إضافية لدعم خواديم التطبيق في بيئة الإنتاج. سيبدو الإعداد النهائي على النحو التالي (لا تظهر خواديم نظام إدارة النطاقات DNS الداخلية ولا النسخ الاحتياطية البعيدة في الصورة أدناه): نعُدُّ الخواديم الموجودة في مربع التطبيق ضرورية ليعمل التطبيق على النحو المرجو. تعمل العناصر المتبقية - النسخ الاحتياطية، المراقبة، والسجلات - بجانب خطة الاستعادة وخادوم النسخ الاحتياطي البعيد؛ على دعم خادوم الإنتاج. سنثبت كل عنصر على خادوم Ubuntu 14.04 منفصل ضمن نفس الحيز الجغرافي مع تفعيل التشبيك الخاص Private networking. نستخدم أسماء المستضيفات Hostnames لتمييز الخواديم المكوِّنة للتطبيق: lb1: موزع الحمل HAProxy، يمكن الوصول إليه عبر العنوان https://www.example.com/.app1: خادوم تطبيقات Apache و PHP.app2: خادوم تطبيقات Apache و PHP.db1: خادوم لقاعدة بيانات MySQL.من المهم التنبيه إلى أنه تم اختيار هذا النوع من الإعداد لتوضيح كيف يمكن لعناصر تطبيق أن تُنشأ على خواديم عدة؛ يجب أن يُخصَّص إعداد تطبيقك بناء على احتياجاتك. توجد نقطة إخفاق Point of failure وحيدة في هذا الإعداد، ويمكن التغلب عليها بتركيب موزع حمل إضافي (وخادوم DNS دوري) ومضاعفة قاعدة البيانات؛ وهو ما لن تطرق إليه في هذا الدرس. نميز العناصر الداعمة للتطبيق بأسماء المستضيفات التالية: النسخ الاحتياطية backups: خادوم النسخ الاحتياطي Bacula.المراقبة monitoring: خادوم Nagios.السجلات logging: سجلات مركزية باستخدام حزمة برمجيات مكونة من Kibana (ELK)، Logstash و Elasticsearch.توجد عناصر أخرى لا تظهر في الصورة، وهي: ns1: وهو خادومنا الرئيس لنظام أسماء النطاقات. نستخدم Bind لهذا الغرض.ns2: وهو الخادوم الثانوي لنظام أسماء النطاقات. نستخدم Bind.remotebackups: خادوم بعيد يوجد في منطقة جغرافية أخرى نحفظ عليه نسخ Bacula الاحتياطية احترازا من كارثة تحل بمركز البيانات الذي يوجد فيه التطبيق.يمكنك أيضا استخدام عنوان IP عائم Floating IP؛ وهو عبارة عن عنوان IP ثابت يُتاح للعموم الوصول إليه ويمكن توجيهه إلى أحد خواديمك الافتراضية أو بنيتك التحتية المكرَّرة Redundant ثم إطلاق موقعك أو خدمتك باستخدام عنوان IP عمومي وحيد. يمكن بعدها إعادة توجيه العنوان العائم إلى خادوم جديد من أجل بيئة إنتاج أكثر مرونة وأسرع تجاوبا. سنضع أيضا خطط استعادة لكلٍّ من العناصر المكونة للتطبيق. ستكون لدينا، عند بلوغ الهدف النهائي، عشرة خواديم. سننشئها كلَّها في نفس الوقت لتسهيل بعض الأمور مثل إعداد النطاقات؛ ولكن يمكنك إنشاؤها الواحد تلو الآخر حسب الحاجة. شبكة خاصة افتراضية Virtual Private Network (اختياري)إذا أردت تأمين اتصالات الشبكة بين خواديمك فيجب عليك إعداد شبكة خاصة افتراضية VPN. يصبح تأمين نقل البيانات عبر الشبكة بتعميتها Encryption أكثر أهمية إذا كانت البيانات تمر عبر الإنترنت. من منافع استخدام شبكة خاصة افتراضية التحقق من هوية المستضيفات بالاستيثاق منها؛ وهو ما يحمي من المصادر التي لا يُرخص لها الوصول للخدمات. إذا كنت تبحث عن أداة مفتوحة المصدر فيمكنك استخدام OpenVPN واتباع خطوات درس دليلك لكيفية إعداد خادوم OpenVPN على Ubuntu لإعداده. المتطلباتيتوجب أن يكون لدى كل خادوم أوبنتو 14.04 حساب مستخدم بصلاحيات إدارية غير المستخدم الجذر؛ يمكن إعداد مستخدم لهذا الغرض باتّباع الخطوات المشروحة في مقال الإعداد الابتدائي لخادوم أوبنتو 14.04. سننفّذ كل الأوامر باستخدام هذا الحساب. سنفترض أيضا أن لديك معرفة بالمفاهيم الأساسية للأمان في لينكس. إذا رغبت في درس تمهيدي حول الموضوع فيمكن الاطلاع على مقال 7 تدابير أمنيّة لحماية خواديمك. اسم نطاقنفترض في هذا المقال أن الوصول إلى التطبيق يكون عبر اسم نطاق، example.com مثلا. إنْ لم يكن لديك اسم نطاق فبالإمكان شراء واحد من أحد مسجلي أسماء النطاقات Domain name registrar. نحتاج اسم النّطاق ليس فقط لتسهيل الوصول إلى الموقع (مقارنة بعنوان IP المكون من أرقام فقط) بل أيضا للحصول على فوائد التحقق من الهوية والنطاق؛ وهو ما يتيح إمكانية الاستفادة من شهادات SSL التي تعمّي البيانات المنقولة بين التطبيق ومستخدميه. شهادة SSLيعمل بروتوكول TLS/SSL على تعميّة البيانات والتحقق من نطاقها أثناء الاتصال بين التطبيق ومستخدميه؛ لذا سنستخدم شهادة SSL لإضافة هذا الإعداد. في المثال نريد أن يصل المستخدمون إلى الموقع عبر العنوان www.example.com وهي القيمة التي سنحددها في الاسم الشّائع للشهادة Common Name (أو ما يُعرف اختصارًا بـ CN). سنثبت الشهادة على خادومHAProxy (المُسمّى lb1) وهو ما يعني أنه من الأفضل توليد مفاتيح الشهادة وطلب توقيع الشهادة Certificate Signing Request CSR على هذا الخادوم. إذا احتجت للتحقق من الهوية فستحتاج لشراء شهادة SSL. توجد الكثير من سلطات الشهادات Certificate Authorities التجارية التي يمكن شراء شهادة SSL منها. كما توجد إمكانية لاستخدام شهادة مجانية من StartSSL يتوفر أيضا حل بديل يتمثل في التوقيع الذاتي لشهادة SSL بتنفيذ الأمر التالي: sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ~/www.example.com.key -out ~/www.example.com.crtالخطوات المتبعة للوصول إلى الهدفعرضنا في الفقرات السابقة نظرة عامة على إعداد تطبيقنا الموجَّه للإنتاج، ننتقل الآن لإنشاء خطة عامة نسير وفقها لتحقيق هدفنا. العناصر الأهم هي تلك التي يتكون منها التطبيق؛ لذا يجب أن نشغلها مبكرا. لكن نظرا لأننا نخطط لاستخدام عنونة تعتمد على أسماء النطاقات للاتصالات ضمن الشبكة الخاصة فيجب أن نعد نظام أسماء النطاقات أولا. سنعدّ، بعد الانتهاء من ضبط إعداد النطاقات، الخواديم التي تكون التطبيق من أجل أن يكون جاهزا للتشغيل. يحتاج التطبيق إلى أن تكون قاعدة بيانات مهيَّأة سلفا، كما يتطلب موزع الحِمل أن يكون التطبيق جاهزا. انطلاقا من هذه الاعتبارات فإن إعداد العناصر سيكون حسب الترتيب التالي: خادوم قاعدة البيانات.خواديم التطبيق.موزع الحمل.سيمكننا - بعد إكمال الخطوات السالفة الذكر من أجل إعداد التطبيق - استنباطُ خطة للاستعادة اعتمادا على سيناريوهات عدة. ستكون خطة الاستعادة أساسية في التخطيط لآليات النسخ الاحتياطي. بعد خطة الاستعادة يأتي دور إعداد النسخ الاحتياطي ثم بعد استكماله يمكن ضبط نظام المراقبة من أجل التأكد من أن جميع الخواديم وكل الخدمات في وضعيةِ عمل مقبولة. ثم نأتي للخطوة الأخيرة وهي إنشاء نظام مركزي لتخزين السجلات مما يسمح بعرضها عند الحاجة، تشخيص المشاكل عند حدوثها وتحليلها لتحديد أنواع الاستخدام وطبيعته. خاتمةخطة العمل جاهزة الآن مما يعني أننا جاهزون للبدء في تنفيذ إعدادات التطبيق. ينبغي تذكر أن هذا الإعداد، رغم أنه يعمل على النحو المراد، يبقى مثالا يجب أن تستطيع التقاط معلومات مفيدة منه ثم استخدام ما تعلمته لتحسين إعداد تطبيقك الخاص. ترجمة -وبتصرّف- لمقال Building for Production: Web Applications — Overview لصاحبه Mitchell Anicas. حقوق الصورة البارزة: Designed by Freepik.

إنّ 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.

يُواجه كلّ شخص في وقتٍ ما مشاكل مع خادوم الوِيب Web Server، سيُساعدك تَعلّمك أين تبحث عندما تواجه مشكلة ما وأيّ العناصر هي التي من المحتمل تمّ تخريبها على إصلاح هذه المشاكل (troubleshoot) بسرعة وبإحباط أقل. سنناقش في هذا الدرس كيف نقوم باستكشاف هذه المشاكل بحيث تستطيع الإبقاء على موقعك يعمل بشكل طبيعي. ما هي أنواع المشاكل النموذجية التي من المحتمل أن تواجهها ؟قد تنشأ في بعض الأحيان بعض المشاكل غير النموذجية إلّا أنّ الغالبية العظمى من المشاكل التي ستصادفها أثناء محاولتك لجعل موقعك يعمل بشكل صحيح تقع ضمن مجموعة يُمكن التنبُّؤ بها كثيرًا. سنقوم بالمرور على هذا بشكلٍ مُفصّل في الأقسام اللاحقة ولكن حاليًّا هذه قائمة من الأشياء التي يجب تفحّصها: هل تمّ تنصيب خادوم الوِيب لديك؟هل خادوم الوِيب قيد التشغيل الآن؟هل الصياغة في ملفات ضبط خادوم الوِيب configuration files صحيحة؟هل المنافذ ports التي قمت بضبطها مفتوحة (لم يتم حجبها من الجدار الناري)؟هل تقودك إعدادات الـ DNS إلى المكان الصحيح؟هل يشير جذر المستند document root إلى موقع ملفاتك؟هل يقوم خادوم الوِيب بتخديم ملفات الفهرس index files الصحيحة؟هل أذونات permissions وملكية الملف ownership وبُنى المجلد صحيحة؟هل قُمتَ بمنع الوصول عن طريق ملفات الضبط؟إن كنتَ تملك قاعدة بيانات database في الخلفيّة backend فهل هي تعمل؟هل يستطيع موقعك الاتصال مع قاعدة البيانات بنجاح؟هذه هي بعض أشيع المشاكل التي يُصادفها مُدراء النُّظم عندما لا يعمل الموقع بشكلٍ صحيح، يُمكن عادةً تضييق المشكلة المحددة بإلقاء نظرة على ملفات السّجل Log Files للمكونات المختلفة وعن طريق الرجوع إلى صفحات الخطأ التي تظهر في متصفحك. سنقوم بالمرور في الأسفل على كل من هذه الحالات لكي تستطيع التحقق من أنّ الخدمات مضبوطة بشكلٍ صحيح. التحقق من السّجلات Logsقبل أن تقوم بتعقُّب مشكلة ما بشكلٍ عشوائي حاول أن تتحقق من سجلات خادوم الوِيب Logs لديك ومن أيّة عناصر مرتبطة بذلك، ستجد هذه السّجلات عادةً في المسار var/log/ في مجلّد فرعي مخصّص للخدمة التي تريدها. فعلى سبيل المثال إن كنتَ تملك خادوم Apache يعمل على توزيعة Ubuntu فستجد بشكل افتراضي أنّ السّجلات يتمّ الاحتفاظ بها في المسار var/log/apache2/، قُم بالتحقق من الملفات في هذا المجلد لكي ترى ما نوع رسائل الخطأ التي تمّ توليدها، إن كنت تملك قاعدة بيانات تعمل في الخلفيّة وتسبب لك المشاكل فهي على الأغلب تحتفظ بسجلاتها في المسار var/log/ أيضًا. من الأشياء التي يجب التحقق منها أيضًا أن تتأكد إذا ما كانت العمليّات نفسها تصدر رسائل خطأ عندما تقوم بتشغيل الخدمات، إن كنت تحاول زيارة صفحة وِيب وتلقّيت خطأ فإنّ صفحة الخطأ قد تحتوي على تلميحات عن الخطأ أيضًا (بالرغم من أنّها ليست دقيقة كالسطور في ملفات السّجلات). استخدم محرّك بحث Search Engine لتحاول إيجاد معلومات متعلقة بالموضوع والتي من الممكن أن تقودك في الاتجاه الصحيح، تساعدك الخطوات القادمة في استكشاف الأخطاء أكثر. هل تمّ تنصيب خادوم الوِيب لديك؟إنّ أول شيء تحتاج له لكي تُخدِّم مواقعك بشكل صحيح هو خادوم وِيب. ربّما قام مُعظم الأشخاص فعلًا بتنصيب خادوم قبل الوصول لهذه المرحلة، ولكن في بعض الحالات ربّما تكون أزلت الخادوم عن طريق الخطأ عند تنفيذك لعمليّات على الحزم Packages الأخرى. إذا كنت تعمل على نظام تشغيل Ubuntu أو Debian وترغب بتنصيب خادوم وِيب Apache تستطيع كتابة ما يلي: sudo apt-get update sudo apt-get install apache2تُدعى عمليّة Apache على هذه الأنظمة بـ apache2. إن كنت تعمل على نظام تشغيل Ubuntu أو Debian وترغب بتنصيب خادوم وِيب Nginx تستطيع بدلًا من ذلك كتابة: sudo apt-get update sudo apt-get install nginxتُدعى عمليّة Nginx على هذه الأنظمة بـ nginx. إن كنت تعمل على أنظمة تشغيل CentOS أو Fedora وترغب باستخدام خادوم وِيب Apache فقُم بكتابة التالي وبإمكانك إزالة الأمر "sudo" إن كُنت قد سجّلت الدخول كـ root: sudo yum install httpdتُدعى عمليّة Apache على هذه الأنظمة بـ httpd. إن كنت تعمل على أنظمة تشغيل CentOS أو Fedora وترغب باستخدام خادوم وِيب Nginx تستطيع كتابة الأمر التالي، ومرّة أخرى قم بإزالة الأمر "sudo" إن كُنت قد سجّلت الدخول كـ root: sudo rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm sudo yum install nginxتُدعى عمليّة Nginx على هذه الأنظمة بـ nginx. هل خادوم الوِيب قيد التشغيل الآن؟بعد أن قمت بالتأكد من أنّ خادومك مُنَصّب بالفعل، فهل هو قيد التشغيل؟ تُوجَد العديد من الطّرق لكي تكتشف إذا ما كانت الخدمة قيد التشغيل أم لا، واحدة من هذه الطرق والتي تعمل على منصّات متعدّدة cross-platform هي استخدام الأمر netstat. سيُخبِرك هذا الأمر عن جميع العمليّات التي تستخدم منافذ على الخادوم، بإمكاننا بعد ذلك كتابة الأمر grep لإيجاد اسم العملية التي نبحث عنها: sudo netstat -plunt | grep apache2 tcp6 0 0 :::80 :::* LISTEN 2000/apache2يجب عليك تغيير كلمة "apache2" إلى اسم عمليّة خادوم الوِيب الذي لديك، إن ظهر لك سطر كالموجود بالأعلى فهذا يعني أنّ العمليّة قيد التشغيل، أمّا إن لم تحصل على أيّة خَرج فهذا يعني إمّا أنّك قُمت بالاستعلام عن العمليّة الخطأ أو أنّ خادوم الوِيب لديك لا يعمل. يُمكنك في هذه الحالة بدء تشغيله باستخدام الطريقة المفضّلة لتوزيعتك، فعلى سبيل المثال على Ubuntu تستطيع بدء تشغيل خدمة Apache2 بكتابة: sudo service apache2 startوعلى توزيعة CentOS نكتب هذا الأمر: sudo /etc/init.d/httpd startإذا تمّ بدء تشغيل خادومك فعندها تستطيع التحقق باستخدام الأمر netstat مرّة أخرى لكي تتأكد من انّ كل شيء يعمل بشكل صحيح. هل الصّياغة Syntax في ملفات ضبط خادوم الوِيب صحيحة؟ إذا رفض خادوم الوِيب لديك أن يبدأ التشغيل فهذا يشير عادةً إلى أنّ ملفات الضبط تحتاج إلى بعض الانتباه، يتطلّب Apache و Nginx التزامًا صارمًا بتعليمات الصّياغة syntax لكي يتمّ قراءة الملفات بنجاح. تتواجد ملفات إعدادات الضبط لهذه الخدمات عادةً في المسار etc/ في مجلّد فرعي مُسمّى على اسم العمليّة نفسها. وبهذا نستطيع الوصول إلى المجلّد الرئيسي لإعدادات ضبط Apache على Ubuntu بكتابة: cd /etc/apache2ويمكننا الوصول بطريقة مشابهة إلى مجلّد إعدادات ضبط Apache على CentOS والمُسمّى على اسم تلك العمليّة: cd /etc/httpdتكون إعدادت الضبط مُوزّعة على عدّة ملفات، وعندما يفشل بدء الخدمة فإنها ستشير عادةً إلى ملف إعدادات الضبط وإلى السّطر الذي حدثت فيه المشكلة، قُم بالتحقق من هذا الملف بحثًا عن الأخطاء. يُزوّدك كل واحد من خواديم الوِيب هذه بالقدرة على التحقق من صياغة إعدادات الضبط في ملفاتك. إن كُنتَ تستخدم Apache فبإمكانك استخدام الأمر apache2ctl أو apachectl للتحقق من ملفات إعدادات الضبط بحثاً عن أخطاء الصياغة: apache2ctl configtest AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message Syntax OK لقد تلقيّنا كما ترى في الأعلى رسالة معلومات حول تفاصيل إعدادت الضبط لدينا ولم يكن هناك أيّة أخطاء، هذا جيّد. وإن كنتَ تملك خادوم وِيب Nginx تستطيع البدء باختبار مماثل بكتابة: sudo nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successfulتتحقق هذه العمليّة من صياغتك كما ترى، فإن أزلنا الفاصلة من المنقوطة من نهاية أحد الأسطر في ملف الإعدادات (وهو خطأ شائع بالنسبة لإعدادت ضبط Nginx) فسنحصل على رسالة مماثلة للآتي: sudo nginx -t nginx: [emerg] invalid number of arguments in "tcp_nopush" directive in /etc/nginx/nginx.conf:18 nginx: configuration file /etc/nginx/nginx.conf test failedيُوجد عدد خاطئ من المُعطيات arguments لأنّ Nginx يقوم بالبحث عن الفاصلة المنقوطة لإنهاء الجُمَل، فإن لم يجدها ينتقل للسطر التالي ويفسّر ذلك على أنها مُعطيات إضافية للسطر السابق. بإمكانك إجراء هذه الاختبارات لكي تجد أخطاء الصياغة في ملفاتك، قُم بإصلاح هذه المشاكل التي يُشير إليها إلى أن تستطيع ملفاتك تجاوز الاختبار بنجاح. هل المنافذ الذي قمت بضبطها مفتوحة؟تعمل خواديم الوِيب بشكلٍ عام على المنفذ 80 لاتصالات الوِيب الطبيعية normal web traffic وتستخدم المنفذ 443 للاتصالات المشفّرة باستخدام TLS/SSL، ولكي تصل بشكل صحيح إلى الموقع يجب أن تكون هذه المنافذ قابلة للوصول. تستطيع اختبار إذا ما كان الخادوم لديك يملك منفذًا مفتوحًا باستخدام الأداة netcat على حاسوبك المحلّي Local Machine. تحتاج فقط لاستخدام عنوان الـ IP لخادومك وتخبرها عن رقم المنفذ الذي تريد التحقق منه كما يلي: sudo nc -z 111.111.111.111 80سيقوم هذا الأمر بالتحقق من المنفذ 80 على الخادوم الذي يملك عنوان 111.111.111.111، إن كان مفتوحًا سيخبرك الأمر فورًا بالنتيجة، أمّا إن لم يكن مفتوحًا فسيحاول الأمر باستمرار لإنشاء اتصال مع الخادوم دون جدوى، بإمكانك إيقاف هذه العمليّة بضغط على CTRL-C في واجهة الأوامر. إن لم تكن منافذ الوِيب قابلة للوصول لديك فيجب أن تبحث في إعدادات الجدار الناري لديك، حيث قد تحتاج أن تفتح المنفذ 80 أو المنفذ 443. هل تقودك إعدادات الـ DNS إلى المكان الصحيح؟إن كان بإمكانك الوصول إلى موقعك باستخدام عنوان الـ IP ولا تستطيع ذلك عبر اسم المجال domain name فربّما يجب عليك إلقاء نظرة على إعدادت الـ DNS. لكي يتمكّن زوّار موقعك من الوصول إليه عبر استخدام اسم المجال فيجب أن يكون لديك سِجِل "A" أو "AAAA" يشير إلى عنوان الـ IP الخاص بخادومك في إعدادات الـ DNS، تستطيع الاستعلام عن سِجِل “A” لمجالك باستخدام هذا الأمر: host -t A example.com example.com has address 93.184.216.119يجب أن يتطابق السطر الذي يعود لك مع عنوان الـ IP لخادومك، إن كنتَ تريد التحقق من سِجِل "AAAA" (للاتصالات التي تستخدم IPv6) بإمكانك كتابة: host -t AAAA example.com example.com has IPv6 address 2606:2800:220:6d:26bf:1447:1097:aa7يجب أن تبقي في ذهنك أنّ أيّة تغييرات تقوم بها على سِجِل الـ DNS تأخذ وقتًا طويلًا ليتم تعميمها، ربّما تتلقى نتائج متضاربة بعد التغيير حيث أنّ طلبك يتمّ تلقيه من قبل خواديم مختلفة ليست جميعها مُحدّثة إلى آخر إصدار حتى الآن. إن كنتَ تستخدم موقع DigitalOcean فبإمكانك أن تتعلم أساسيات DNS وأسماء النطاقات. قم بالتأكد من أن ملفات إعدادات الضبط تقوم بالتعامل مع مجالك بشكل صحيح. يبدو المقطع الخاص بملف المضيف الوهمي virtual host file لديك في Apache كما يلي: <VirtualHost *:80> ServerName example.com ServerAlias www.example.com ServerAdmin admin@example.com DocumentRoot /var/www/html ٠٠٠يتم إعداد المضيف الوهمي virtual host لكي يستجيب مع أيّة طلبات على المنفذ 80 من أجل المجال example.com. تبدو القطعة المشابهة لهذا في Nginx كما يلي: server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.html index.htm; server_name example.com www.example.com; ٠٠٠يتم إعداد هذه الكتلة Block لكي تستجيب إلى النوع المماثل من الطلبات التي تحدثنا عنها في الأعلى. هل يشير جذر المستند Document Root إلى موقع ملفاتك؟من الاعتبارات الأخرى التي يجب أن نأخذ بها هي إذا ما كان خادوم الويب لديك يشير إلى الموقع الصحيح للملف. يتم إعداد كل خادوم وهمي في Apache أو كتلة خادوم Server Block في Nginx لكي تشير إلى مجلّد محدد، فإن كان مُعدًّا بشكل غير صحيح سيرمي الخادوم رسالة خطأ عندما تحاول الوصول إلى الصفحة. يتم إعداد جذر المستند Document Root في Apache باستخدام التوجيه DocumentRoot : <VirtualHost *:80> ServerName example.com ServerAlias www.example.com ServerAdmin admin@example.com DocumentRoot /var/www/html ...يُخبر هذا السطر Apache أنّه يجب عليه البحث عن الملفات لهذا المجال في المسار var/www/html/، فإن كنت تحتفظ بملفاتك في مكانٍ آخر يجب عليك تعديل هذا السطر لكي يشير إلى الموقع الصحيح. يقوم التوجيه root في Nginx بإعداد نفس الشيء: server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.html index.htm; server_name example.com www.example.com; ... يبحث Nginx في إعداد الضبط هذا عن الملفات لهذا المجال في المسار usr/share/nginx/html/ هل يقوم خادوم الوِيب بتخديم ملفات الفهرس Index files الصحيحة؟إذا كان جذر المستند لديك صحيحًا ولا يتم تخديم صفحات الفهرس Index Pages بشكلٍ صحيح عندما تذهب إلى موقعك أو إلى مكان المجلد على موقعك فربّما تم ضبط إعدادات الفهارس بشكل غير صحيح. عندما يقوم زائر ما بطلب مجلد يقوم خادومك نموذجيًا بإعطائه ملف فهرسة، عادةً ما يكون هذا ملف index.html أو ملف index.php وذلك اعتمادًا على على إعدادات الضبط لديك. ربّما تجد في Apache سطرًا في ملف المضيف الافتراضي الذي يقوم بضبط إعدادات ترتيب الفهرس التي سيتم استخدامها لمجلدات معيّنة بشكلٍ صريح كما يلي: <Directory /var/www/html> DirectoryIndex index.html index.php </Directory>هذا يعني أنّه عندما يتم تخديم مجلد فإنّ Apache سيقوم بالبحث أولًا عن ملف يدعى index.html، ويحاول تخديم ملف index.php كاحتياط في حال لم يتم إيجاد الملف الأول. بإمكانك تعيين الترتيب الذي سيتم استخدامه لتخديم ملفات الفهرس لكامل الخادوم عن طريق تعديل ملف mods-enabled/dir.conf والذي يقوم بتعيين الإعدادات الافتراضية للخادوم، إن كان الخادوم لديك لا يُخدّم ملف فهرس فقم بالتأكد أنّك تملك ملف فهرس في مجلّدك الذي يُوافق أحد الخيارات في ملفك. يُدعى التوجيه الذي يقوم بذلك في Nginx بـ “index” ويتمّ استخدامه كما يلي: server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.html index.htm; server_name example.com www.example.com; ...هل تمّ تعيين الأذونات والملكية بشكل صحيح؟حتى يتمكن خادوم الوِيب من تخديم الملفات الصحيحة يجب أن يكون قادرًا على قراءة الملفات وأن يمتلك صلاحية الوصول للمجلدات حيث يتم حفظ هذه الملفات، بالإمكان التحكم بهذا عبر أذونات وملكية الملفات والمجلدات. لكي تقرأ الملفات يجب أن تكون المجلدات التي تحتوي المحتوى قابلة للقراءة والتنفيذ من قبل عمليّة خادوم الوِيب، تختلف أسماء المستخدمين والمجموعات التي يتم استخدامها لتشغيل خادوم الوِيب من توزيعة لأخرى. على Ubuntu و Debian يعمل كلًّا من Apache و Nginx كالمستخدم www-data والذي هو عضو من المجموعة www-data. على CentOS و Fedora يعمل Apache تحت مستخدم يُدعى apache والذي ينتمي لمجموعة apache، يعمل Nginx تحت مستخدم يُدعى nginx والذي هو جزء من مجموعة nginx. تستطيع باستخدام هذه المعلومات النظر إلى المجلدات والملفات التي يتألف منها محتوى موقعك: ls -l /path/to/web/rootيجب أن تكون المجلدات قابلة للقراءة والتنفيذ من قبل المستخدم web أو مجموعته، أمّا الملفات فيجب أن تكون قابلة للقراءة لكي يتم قراءة محتواها، وبالإضافة لذلك إن أردنا تحميل، كتابة أو التعديل على المحتوى يجب أن تكون المجلدات والملفات قابلة للكتابة، ولكن احذر عند تعيينك للمجلدات لكي تكون قابلة للكتابة لأنّ هذا يُمكن أن يكون أحد المخاطر الأمنية. لتعديل ملكية ملف ما تستطيع فعل ما يلي: sudo chown user_owner:group_owner /path/to/file تستطيع فعل هذا أيضًا للمجلد، فبإمكانك تغيير ملكية المجلد وكل ما بداخله من ملفات عبر تمرير العَلَم –R: sudo chown -R user_owner:group_owner /path/to/file تستطيع التعلم أكثر عن أذونات لينِكس هنا. هل قُمتَ بمنع الوصول عن طريق ملفات الضبط؟من المحتمل أنّه تم تعيين إعدادات الضبط لديك لكي تمنع الوصول إلى الملفات التي تحاول تخديمها. يتم إعداد هذا الضبط في Apache في ملف المضيف الافتراضي لهذا الموقع أو عبر ملف htaccess. الموجود في المجلد نفسه. من الممكن من خلال هذه الملفات أن تقوم بمنع الوصول بعدّة طرق ، يُمكن منع الوصول للمجلدات في إصدار Apache 2.4 بهذه الطريقة: <Directory /usr/share> AllowOverride None Require all denied </Directory>يقوم هذا السطر بإخبار خادوم الوِيب بألّا يسمح لأي شخص بالوصول لمحتويات هذا المجلد، أمّا في إصدار Apache 2.2 والإصدارات الأقدم منه يمكننا كتابة ذلك كما يلي: <Directory /usr/share> AllowOverride None Require all denied </Directory>إن وجدت توجيهًا كهذا للمجلد المُحتوي للمحتوى الذي تحاول الوصول إليه فإنّ هذا هو ما يمنع نجاحك. تأخذ هذه القيود في Nginx شكل توجيهات deny وتتواجد في كتل خادومك أو في ملفات إعدادات الضبط الرئيسية: location /usr/share { deny all; }إن كنتَ تملك قاعدة بيانات database في الخلفية فهل هي تعمل؟إذا كان موقعك يعتمد على قاعدة بيانات في الخلفية مثل MySQL, PostreSQL, MongoDB, etc فستحتاج أن تتأكد من أنّها قيد التشغيل. بإمكانك فعل هذا بنفس الطريقة التي تأكدت منها بأنّ خادوم الوِيب يعمل، مرّة أخرى نستطيع البحث عن العمليات قيد التشغيل ومن ثم انتقاء اسم العملية التي نبحث عنها كما يلي: sudo netstat -plunt | grep mysql tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 3356/mysqldكما ترى فإن الخدمة قيد التشغيل على هذا الحاسوب، عندما تبحث عن خدمة قُم بالتأكد من أنّك تعرف الاسم الذي تعمل تحته هذه الخدمة. وكبديل لهذا ابحث عن المنفذ الذي تعمل الخدمة عليه إن كنتَ تعلم هذا، ابحث في توثيق documentation قاعدة بياناتك لكي تجد المنفذ الافتراضي الذي تعمل عليه أو تحقق من ملفات إعدادات الضبط. إن كنتَ تملك قاعدة بيانات في الخلفية، فهل يستطيع موقعك الاتصال بنجاح إليها؟الخطوة التالية التي يجب أن تأخذها إن كنت تحاول استكشاف الأخطاء مع وجود قاعدة بيانات في الخلفية هي أن ترى إن كان بإمكانك الاتصال بها بشكلٍ صحيح، يعني هذا عادةً التحقق من الملفات التي يقرؤها موقعك لكي يجد معلومات قاعدة البيانات. على سبيل المثال في موقع WordPress يتم تخزين إعدادات اتصال قاعدة البيانات في ملف يُدعى wp-config.php ، تحتاج للتحقق من أنّ DB_NAME ، DB_USER و DB_PASSWORD صحيحة لكي يتمكن موقعك من الاتصال بقاعدة البيانات. بإمكانك اختبار إذا ما كان الملف يملك المعلومات الصحيحة بمحاولة الاتصال إلى قاعدة البيانات يدويًّا باستخدام ما يلي: mysql -u DB_USER_value -pDB_PASSWORD_value DB_NAME_valueإن لم تتمكّن من الاتصال باستخدام القيم التي وجدتها في الملف فربّما تحتاج إلى إنشاء الحسابات وقواعد البيانات أو تعديل أذونات الوصول لقاعدة بياناتك. هل تمّ ضبط خادوم الوِيب لديك لكي يمرر محتوىً ديناميكيًا إلى معالج نصوص Script Processor؟إن كنت تستخدم قاعدة بيانات في الخلفية، فأنت بكل تأكيد تستخدم لغة برمجة مثل PHP لكي تعالج طلبات للمحتوى الديناميكي، تجلب المحتويات من قاعدة البيانات وتقديم النتائج. إن كانت هذه هي الحالة تحتاج للتأكد من أن خادوم الوِيب لديك مُعَد بشكل صحيح لكي يمرر الطلبات إلى معالج النصوص. يعني هذا بشكل عام في Apache التأكد من تنصيب وتمكين mod_php5، بإمكانك فعل هذا على Ubuntu أو Debian بكتابة: sudo apt-get update sudo apt-get install php5 libapache2-mod-php5 sudo a2enmod php5وفي أنظمة CentOS و Fedora يجب كتابة ما يلي: sudo yum install php php-mysql sudo service httpd restartولكنّ هذا معقّد أكثر قليلًا في Nginx، حيث أنّه لا يملك وحدة PHP ليتمّ تمكينها، لذلك نحتاج أن نتأكد من تنصيب وتمكين php-fpm في إعدادات الضبط. على خادوم Ubuntu أو Debian تأكد أنّه تم تنزيل العناصر بكتابة: sudo apt-get update sudo apt-get install php5-fpm php5-mysqlتستطيع فعل هذا على CentOS أو Fedora بكتابة: sudo yum install php-fpm php-mysql بما أنّ معالج PHP ليس جزءًا من Nginx تحتاج أن تذكر له صراحةً أن يمرر ملفات PHP، اتبع الخطوات الأربعة من هذا الدليل لتتعلم كيف تضبط إعدادات Nginx لكي يمرر ملفات PHP إلى php-fpm، يجب عليك أيضًا أن تلقي نظرة على المقطع من الخطوة الثالثة الذي يتعامل مع إعداد معالج PHP، يجب أن يكون هذا مماثلًا إلى حدٍّ كبير بغض النظر عن توزيعتك. إن فشل كل هذا تحقق من السّجلات مرّة أخرىيجب أن يكون التحقق من السّجلات خطوتك الأولى، ولكنّه من الجيد أن يكون أيضًا خطوتك الأخيرة قبل أن تطلب المزيد من المساعدة. إن بذلت قصارى جهدك في استكشاف الأخطاء بنفسك وتحتاج بعض المساعدة (من صديق، بفتح تذكرة مساعدة، إلخ...) ستحصل على مساعدة بشكل أسرع بتزويد ملفات السجل ورسائل الأخطاء، حيث سيجد مدراء النظم الخبيرون غالبًا فكرة جيّدة عمّا يحصل إن أعطيتهم هذه القطع من المعلومات التي يحتاجونها. الخاتمةآمل أن تكون نصائح استكشاف الأخطاء هذه قد ساعدتك في تعقب وإصلاح بعضًا من أشيع المشاكل التي يواجهها مدراء النظم عند محاولتهم في تشغيل مواقعهم. إن كنت تملك نصائح إضافية عن أشياء يجب التحقق منها وطرق لحل المشاكل قم بمشاركتهم مع المستخدمين الآخرين في التعليقات. ترجمة -وبتصرّف- للمقال How To Troubleshoot Common Site Issues on a Linux Server لصاحبه Justin Ellingwood.