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

إذا التقى شخصان في قرى الهيمالايا، حيِّا أحدهما الآخر قائلًا: "هل جسدك معافى؟" وأما في اليابان فقد ينحنيان أحيانًا، وفي عُمان يطبع كلّ منهما قبلة على أنف الآخر بعد التصافح، في كمبوديا وتايلاند، يضمّ كلّ منهما يديه وكأنّه يدعو. كل هذه الوسائل هي "بروتوكولات" للتواصل، أي سلسلة بسيطة من الرموز ذات المعنى والّتي تمهّد لتبادل حديث مُفيد. في عالم الويب، لدينا بروتوكول فعّال جدًّا على مستوى التّطبيقات يُمهّد الحواسيب حول العالم لتبادل الأحاديث النّافعة، واسمه Hypertext Transfer Protocol، أو HTTP اختصارًا؛ وهو بروتوكول يُصنّف ضمن طبقة التّطبيقات فوق TCP/IP، وهو أيضًا بروتوكول للتواصل. كثيرًا ما يغيب شرح HTTP في دروس التصميم والتطوير للويب، وهذا أمرٌ مُخزٍ: ففهمه يُعينك في تحسين تفاعل المستخدم وتحقيق أداء أفضل للموقع وإنشساء أدوات فعّالة لإدارة المعلومات على الويب. هذا المقال هو الجزء الأول من سلسلة تهدف إلى تعليم أساسيّات HTTP، وكيف يمكن استخدامه بفعّاليّة أكبر. سنطّلع في هذا الدّرس على محلّ HTTP من الإنترنت. ما معنى بروتوكول تواصل؟ قبل الدّخول في التفاصيل، لنتخيّل موقفًا بسيطًا يحدث فيه تواصل بين طرفين، ولكي يحدث هذا التواصل، فإن على الطّرفين (برنامجين كانا أم جهازين أم شخصين... إلخ.) أن يتّفقا على: الصياغة (تنسيق البيانات) الدلالات (معلومات التحكم والتعامل مع الأخطاء) التوقيت (تطابق السرعة والتتالي) عندما يلتقى اثنان، فإنّهما يتفاهمان من خلال بروتوكل تواصل: ففي اليابان مثلًا، يؤدي أحدهما حركة جسدية، كأن يحني ظهره. وهذه هي الصياغة المعتمدة في التواصل. وفي عادات اليابان، تدل حركة الانحناء هذه (وحركات أخرى مشابهة) على التّحيّة. وبحركة انحناء أحد الشخصين للآخر تنطلق سلسلة من الأحداث بينهما مرتبة بتوقيت معيّن. يتركّب بروتوكل التواصل عبر الشبكات من المكوّنات ذاتها. فأمّا الصّياغة فهي سلسلة من الحروف كالكلمات المفتاحيّة المُستخدمة في كتابة البروتوكول، وأمّا الدلالات فهي المعاني المُرتبطة بكلّ من هذه الكلمات، وأمّا التوقيت فهو ترتيب تبادل هذه الكلمات بين الطّرفين. ما محلّ HTTP من الإنترنت؟ يقوم HTTP نفسه فوق بروتوكولات أخرى. فعند الاتصال بموقع ويب مثل www.example.org، يستخدم وكيل المستخدم (user agent) مجموعة بروتوكولات TCP/IP، والتي صُمّمت في عام 1970 مؤلّفة من 4 طبقات: طبقة الوصلة (Link)، والتي تصف الوصول إلى الوسيط المادّي (كاستخدام بطاقة الشبكة مثلًا) طبقة الإنترنت، والتي تصف كيفيّة تغليف البيانات وتوجيهها (IP أو Internet Protocol) طبقة النقل (Transport)، والتي تصف كيفية نقل البيانات من نقطة الانطلاق إلى الوجهة (TCP وUDP) طبقة التطبيقات (Application)، والتي تصف معنى وصياغة الرسائل المنقولة (HTTP) فـ HTTP إذًا هو بروتوكول على مستوى التطبيقات يقوم على الطبقات السابقة، لا تنسَ هذه الفكرة. يُساعد فصل هذا النّموذج في طبقات على تطوير أجزاءه بصورة منفصلة دون الحاجة لإعادة تصميمها جميعًا. فمثلًا، يمكن تطوير TCP، باعتباره بروتوكولًا في طبقة النّقل، دون الحاجة لتعديل HTTP كونه برتوكولًا في طبقة التّطبيقات. لكن الواقع العمليّ يجعل التفاصيل أكثر تعقيدًا عند الحاجة للوصول إلى تواصل ذي أداء عالٍ. سنركّز في الأجزاء الأولى من هذه السّلسلة على فصل الطّبقات كما هو مُعرَّف في نموذج TCP/IP. صُمِّم HTTP بغرض تبادل المعلومات بين برنامجين من خلال رسائل تُسمّى رسائل HTTP، وتؤثّر طريقة تشكيل هذه الرسائل في العميل (client) والخادوم (server) والأطراف الوسيطة (كالخواديم الوكيلة proxies). لنتواصل مع خادوم! يُعتبر المنفذ رقم 80 المنفذ المبدئيّ للاتّصال بخواديم الويب، ويمكن التأكّد من ذلك بتجربة نُجريها من الطّرفيّة. افتح الطّرفية (أو سطر الأوامر) وجرّب الاتصال بـ www.opera.com على المنفذ 80 مُستخدمًا الأمر التالي: telnet www.opera.com 80 من المُفترض أن يكون الناتج: Trying 195.189.143.147... Connected to front.opera.com. Escape character is '^]'. Connection closed by foreign host. كما نرى فإن الطرفيّة تحاول الاتصال بالخادوم ذي عنوان IP‏ 195.189.143.147. إن لم نفعل شيئًا آخر سيغلق الخادوم الاتصال بنفسه. من الممكن بالطّبع استخدام منفذ آخر بل وحتّى بروتوكول تواصل آخر، ولكن هذه هي الإعدادات الشّائعة. لنتحدّث بلغة HTTP! لنحاول ثانية التواصل مع الخادوم. أدخل الرسالة التالية في الطرفية (أو سطر الأوامر): telnet www.opera.com 80 ما إن يُؤسّس الاتصال، اكتب رسالة HTTP التالية بسرعة (قبل أن يُغلق الخادوم الاتصال بنفسه)، ثم اضغط Enter مرّتين: GET / HTTP/1.1 Host: www.opera.com تُحدّد هذه الرسالة: GET: أي أننا نريد "الحصول على" تمثيل البيانات. /: أي أنّ المعلومات التي نريدها مخزنة في جذر الموقع. HTTP/1.1: أي أننا نتحدث ببروتوكول HTTP ذي الإصدارة 1.1. Host:: أي أننا نريد الوصول إلى الموقع المُحدّد. www.opera.com: اسم الموقع هو www.opera.com. على الخادوم الآن أن يُجيب طلبنا. من المفترض أن تمتلئ نافذة الطرفية بمحتوى مشابه لما يلي: HTTP/1.1 200 OK Date: Wed, 23 Nov 2011 19:41:37 GMT Server: Apache Content-Type: text/html; charset=utf-8 Set-Cookie: language=none; path=/; domain=www.opera.com; expires=Thu, 25-Aug-2011 19:41:38 GMT Set-Cookie: language=en; path=/; domain=.opera.com; expires=Sat, 20-Nov-2021 19:41:38 GMT Vary: Accept-Encoding Transfer-Encoding: chunked <!DOCTYPE html> <html lang="en"> ... يقول الخادوم هنا: "أنا أتحدث HTTP الإصدارة 1.1. نجحَ طلبك، لذا أجبت بالرمز 200." الكلمة OK ليست إلزامية والهدف منها شرح معنى الرمز للبشر - وهي تُشير في حالتنا إلى أن الأمور تسير على ما يرام وأن رسالتنا قُبلت. يلي ذلك سلسلة من "ترويسات HTTP" التي تُرسل لتصف الرسالة، وكيف يجب أن تُفهم. أخيرًا نجد محتويات الصفحة المُستضافة على جذر الموقع، والّتي تبدأ بـ <!DOCTYPE html>.

كان ختام المقالة السّابقة قولُنا أن بروتوكول HTTP يدير التّفاعل بين عميل وخادوم، وقد شرحنا فكرة ترويسات HTTP. سيكون لدينا الكثير مما يُقال عن هذه الترويسات في أجزاء تالية من هذه السّلسلة، فهذه الترويسات تؤثّر في التّفاعل بين الطّرفين وفي أداء الموقع. أمّا اليوم، فسنطّلع على جانب لا يقلّ أهمّيّة عن التّرويسات، وهو رموز إجابات HTTP. نزهة في الشوارع خرجت ذات صباح قاصدًا مقهى لأقرأ كتابًا، لكنّني وجدت المقهى مُغلقًا حينها، وقد كُتب على لوحة على الباب أنّ احتفالًا يُقام خلال هذا الأسبوع، ولذلك فإنّ المقهى سينتقل مؤقتًا ليُقدّم القهوة في شاحنة الطّعام (التي سمّوها "307") قرب النهر. ذهبت إلى ذلك المكان واستمتعت بشرب القهوة. قرّرت بعدئذٍ التجوّل في مكتبتي المفضّلة في المدينة، فوجدتها مُغلقةً كذلك، إلّا أنّني رأيت لوحة على الباب تقول أن المكتبة ستتوسع ولذلك انتقلت بشكل دائم إلى مبنى جديد في 301 شارع برنرز-لي. لم يُزعجني ذلك، فالمكان قريب. ذهبت إلى هناك فاستقبلني الموظّفون بالتّرحاب: "200 سلامة!". حسنًا، أنا أبالغ قليلًا، لكنّك فهمتني! في طريقي إلى البيت، وجدت متجرًا مهجورًا غطّى الغبار أبوابه في 410 شارع برنرز-لي، وقد أُلصقت ورقةٌ على الباب تقول أنّ صاحب المحلّ تقدّم بطلب إشهار الإفلاس واضطّر إلى إغلاق المتجر، إلى الأبد. وكأنّ العجائب لم تنتهِ اليوم، إذ رأيت في نهاية 500 شارع برنرز-لي مبنى من 4 طوابق وقد انهار بالكامل. ما الذي حدث هنا؟! لم يكن يومي سيئًا بالمجمل، لذا قرّرت أن أكمل يومي بكتابة مقال عن رموز HTTP الّتي تُرسلها الخواديم إلى العملاء الّذين يرسلون الطّلبات. صياغة جواب HTTP وسطر الحالةتطرّقنا في المقال السّابق إلى السّطر الأول من صيغة الطّلبات الّتي يُرسلها العميل (بما في ذلك أفعال HTTP). وسنركّز الآن على السّطر الأول من رسالة الجواب الّتي تصل من الخادوم، ومعاني الرّموز المختلفة الّتي تظهر في هذا السّطر. لاحظ التّشابه بين نوعي الرّسائل (الطّلبات والإجابات). فكما ينصّ توثيق الإصدارة 1.1 من HTTP: إما إن تكون رسالة HTTP طلبًا من العميل إلى الخادوم أو جوابًا من الخادوم للعمل. من حيث الصّياغة، لا يختلف نوعا الرّسائل إلى في السّطر الأوّل، والذي إمّا أن يكون سطر طلب (للطلبات) أو سطر حالة (للإجابات)، وفي خوارزميّة تحديد طول متن الرّسالة (القسم 3.3). يُدعى السّطر الأول في الجواب إذًا سطر الحالة. يبدأ السّطر بإصدارة بروتوكول HTTP ثمّ مسافة ثم رمز من ثلاثة أرقام، ثم مسافة ثمّ جملة تشرح الرّمز، كهذا المثال: HTTP/1.1 200 OKالجملة القصيرة الأخيرة غير إلزامية وعلى العملاء تجاهلها، ولا ينبغي أن يستخدمها برنامج بغرض تفسير الجواب. لنطّلع الآن على بعض أكثر رموز الحالة شيوعًا وما يعنيه كلّ رمز منها. رموز الحالة في HTTP200، كلّ شيء على ما يرام! في كلّ مرّة يريد شخصٌ ما زيارة الصّفحة الرئيسيّة لموقع Opera، يُرسل العميل طلبًا إلى http://www.opera.com/ برسالة مثل هذه: GET / HTTP/1.1 Host: www.opera.com Accept-Language: fr User-Agent: BrowseAndDream/1.0يُحلّل الخادوم الرّسالة الّتي وصلته من العميل ويُرسل جوابًا بناء على ما فهمه من الرابط والترويسات. وكما ذكرنا في المقالتين السّابقتين، يكون الهدف الأهمّ هو إدارة التّواصل بين الطّرفين بما يحقّق أقصى فائدة لكليهما. إن فهم الخادوم الرّسالة، فإنّه يرسل رسالة تبدأ بـ200 OK، أي أنّ كلّ شيء على ما يُرام. تحوي الرسالة بضع ترويسات إجابة ثمّ محتوى الصّفحة، والّذي قد يختلف بناءً على ترويسات الطّلب، فلا إجابة مُطلقة. فكما في كل تفاوض، يجري حوارٌ بين الطّرفين للوصول إلى أفضل تسوية. فيما يلي مثالٌ عن إجابة على الطّلب السّابق: HTTP/1.1 200 OK Date: Fri, 24 Aug 2012, 13:56:44 GMT307، انتقلتُ مؤقّتًا إلى مكان آخر يمكن للخادوم أن يجيب العميل برسالة تبيّن أنّ المحتو قد انتقل مؤقتًا إلى مكان آخر. ويفيد هذا عندما تريد إعادة توجيه العميل إلى صفحة مُعيّنة لفترة قصيرة. افترض مثلًا موقعًا يُعطي توقّعات الطقس لتاييبي، وقد شبّ إعصار هائل مؤخّرًا فيها. سيكون من المفيد إعلام المُستخدمين بوقوع هذا الإعصار حتى هدوئه. قد يكون الطّلب مثل هذا: GET /taiwan/weather/today HTTP/1.1 Host: meteo.example.orgقد يرغب الخادوم بإجابة العميل قائلًا: "سأنقلك إلى صفحة أخرى تُعطيك معلومات مفصّلة عن الأزمة الحاليّة في تاييبي". قد تبدو الإجابة مثل هذه: HTTP/1.1 307 Temporary Redirect Date: Fri, 24 Aug 2012, 13:56:44 GMT Location: http://meteo.example.org/taiwan/weather/crisisيتبع المتصفح عادةً الوجهة الجديدة المذكورة في سطر Location. يمكن أن يطلب الخادوم إعادة التّوجّه إلى نطاق آخر على الويب. وحالما تنتهي الأزمة، يمكن للخادوم إزالة إعادة التّوجيه. ينبغي ألّا يتذكّر العميل إعادة التّوجيه للأبد. فهذا مُهمّ في حالة الإشارات المرجعيّة وسجل التصفّح. من الممكن تصميم برنامج يُدير عمليّات إعادة التّوجيه هذه بطريقة مُفيدة. لا يرى المُستخدم إعادة التّوجيه في معظم المتصفّحات، ولكن من الممكن إرسال متن مع جواب إعادة التّوجيه يعرض على المستخدم رسالة تحوي رابطًا للمكان الجديد يُسمح للمُستخدم بنقره. 301، تغيّر العنوان بشكل دائم عند إدارة المعلومات على موقع ويب، قد نحتاج إلى إعلام العميل (ومستخدميه) أن الصّفحة المطلوبة قد انتقلت بشكل دائم. ففي الشّركات، يُعاد تنظيم الأقسام أحيانًا بعد الاتّحاد مع شركة أخرى أو عند تغيّر الأولويّات. لنفترض مثلًا أن وحدة الآلات الكهربائيّة في شركة تقنية قد ضُمَّت إلى قسم الإلكترونيّات. وعندها يمكن إعادة توجيه عميل يطلب: GET /section/electromech/about HTTP/1.1 Host: inc.example.comإلى: HTTP/1.1 301 Moved Permanently Date: Fri, 24 Aug 2012, 13:56:44 GMT Location: http://inc.example.com/section/electronic/aboutالفرق بين الرمز 307 الّذي شرحناه في الفقرة السّابقة، والرّمز 301، أنّ التّغيّر في العنوان دائم في حالة الرّمز الثّاني، وهي رسالة واضحة من الخادوم للعميل تطلب منه أن يُغيّر الإشارات المرجعيّة المحفوظة لديه إلى العناوين الجديدة. يمكن للمتصفّح تنفيذ ذلك من تلقاء نفسه أو بعد استشارة المستخدم. لإعادة توجيه الروابط القديمة فائدتان مُباشرتان. الأولى هي كسب ثقة المستخدمين بموقعك، بأن تُبدي اهتمامك بالمُحافظة على المعلومات الّتي تستضيفها. والثّانية هي استقرار الموارد، فالمواقع الّتي تُعرف بمحافظتها على الرّوابط تكون أكثر احتمالًا لأن تُشير إليها مواقع أخرى على المدى البعيد، ممّا يزيد ترتيب الموقع في مُحرّكات البحث. 410، وداعًا يا صديقي العزيز! تحتاج بعض المواقع أحيانًا إلى إبلاغ العميل باختفاء المعلومات الّتي كانت موجودة على رابط مُعيّن للأبد. وقد يكون لهذا مُبرّراته. نحن نعلم أن الروابط الجيّدة لا تتعطّل؛ ولكنّ الرّمز 410 Gone هو الوسيلة الوحيدة المناسبة لتعطيلها. لنكن أكثر دقّة: هذا الرّمز هة طريقة لإخبار المستخدمين أن المحتوى الّذي كان موجودًا من قبل على هذا الرابط قد حُذِفَ عمدًا. وهذا معناه أن الخادوم يطلب من العُملاء الّذي يقصدون هذا الرّابط ألّا يتذكّروه. ففي متصفّح يستخدم الإشارات المرجعيّة وسجّلات التّصفّح، يُعتبر هذا الرّمز إبلاغًا للمتصفّح بسلامة حذف هذا الرّابط. افترض شبكة اجتماعيّة يُطلب فيها الوصول إلى صفحة مُستخدم: GET /people/jeanpaulsartres HTTP/1.1 Host: socialnetwork.example.comقرّر المستخدم أن يُغادر شبكتك الاجتماعيّة ويُغلق حسابه، قد تُريد أن تُبلغ غيره من المستخدمين الّذين يطلبون صفحته من سجلّ المتصفّح أو إشاراته المرجعيّة: HTTP/1.1 410 Gone500، يا للمصيبة! قد يتعذّر على الخادوم إجابة الطّلب لسبب مجهول. لا يتدخّل HTTP على الإطلاق في تفاصيل عمل الموقع، مثل طريقة تخزين قواعد البيانات على الخادوم، أو كيف يجلب الخادوم البيانات ويُعالجها. ربّما توقّف الطّلب عند برنامج مُعيّن على الخادوم ولم يصل الجواب، وعندها يُبلغ الخادوم العميل ومستخدمه عن وقوع خطأ ما غير معروف بجواب مثل هذا: HTTP/1.1 500 Internal Server Errorاستخدام سطور الحالة في الإجابات الّتي تُرسلها الخواديمعند تصميم نظام لإدارة المحتوى، يكون من الضّروري فصل الطّبقات بصورة موارد وروابط إلى هذه الموارد، فهذا مُفيد عند إجابة طلبات العملاء بالمعلومات الصّحيحة، وتقديم المحتوى للبرامج أو للبشر هو شيء جوهريّ في صفة الخواديم. ولأنّ المعلومات تتغيّر وتتطوّر،فإنّ تصميم الخواديم بما يراعي هذه النّقطة يُعطيها مرونة أكبر. لا تهدف هذه السّلسلة إلى شرح تفاصيل تطبيق إجابات الخواديم من النّاحية البرمجيّة، ولكنّنا سنستعرض مثالين يُفيدان كنقطتي انطلاق، على الرّغم من أنّهما قد لا يُفيدان في حالة المواقع الضّخمة الّتي تضمّ آلاف الرّوابط. إعادة التّوجيه في Apacheفي حال أردت إعادة توجيه http://inc.example.com/section/electromech/about إلى http://inc.example.com/section/electronic/about، يمكن إضافة ملف .htaccess في جذر الموقع يحوي التّعليمات التّالية: RewriteEngine On RewriteBase / RewriteRule ^/section/electromech/about /section/electronic/about [L,R=301]مُلاحظة: هنالك طرق أخرى لتنفيذ هذا الغرض، كاستخدام httpd.conf أو قواعد البيانات أو من خلال النّصوص البرمجيّة... إلخ. واختيار الطّريقة المناسبة يعتمد على تصميم النّظام. إعادة التّوجيه في nginxخادوم Nginx هو الآخر شائع الاستخدام، وخصوصًا على شبكات توفير المحتوى (CDNs). يمكن إعادة كتابة المثال السّابق لاستخدامه مع nginx: server { listen 80; server_name inc.example.com; rewrite ^/section/electromech/about http://inc.example.com/section/electronic/about permanent; }تصنيف رموز HTTPتعرّفنا على بضع رموز HTTP فيما سبق، ولكنّها أكثر من ذلك، وبعض هذه الرّموز ذائع الصّيت مثل 404 Not Found، وبعضها مغمور لا يُرى كثيرًا. وفي كلا الحالتين يمكن الاستعانة بالرّقم الأوّل للرّمز لأخذ فكرة عن معناه، كون هذا الرقم يُشير إلى العائلة الّتي ينتمي إليها الرّمز: 1xx (بيان): وصل الطّلب، وتجري مُعالجته.2xx (نجاح): وصل الطّلب وفُهم وقُبل.3xx (إعادة توجيه): يُطلب إجراء تالٍ لإكمال الطّلب.4xx (خطأ من جهة العميل): صياغة الطّلب خاطئة أو يتعذّر تحقيقه.5xx (خطأ من جهة الخادوم): فشل الخادوم في تحقيق طلب يبدو سليمًا.الخلاصةإلى هنا نكون قد وصلنا إلى نهاية دراستنا لرموز حالة HTTP. أحثّك على الاطّلاع على كلّ رمز والتّعرّف على فائدته. لبعض هذه الرموز تأثيرات خاصّة على التّخزين المؤقّت وعلى متن رسالة HTTP؛ سنُلقي نظرةً على التّخزين المؤقت لاحقًا. تذكّرتُرسل الخواديم رموز حالة HTTP لتزويد العميل بمعلومات سريعة عن الجواب.تؤثّر رموز HTTP في التّخزين المؤقّت ومُعالجة الرّوابط من جهة العميل.تُصنّف رموز HTTP ضمن عدّة مجموعات.ترجمة (بشيء من التّصرّف) لمقال HTTP: Response Codes لصاحبه Karl Dubosy.

تعلمنا في الجزء السابق أن HTTP بروتوكول على مستوى التطبيقات. حان الوقت لنفهم كيفية استخدام هذا البروتوكول للتواصل بين العميل والخادوم. جلب الأشياء من الويب تذكر أن عميل HTTP (وهو المتصفح عادةً) هو الطرف الذي يبدأ بإرسال الطلب إلى الخادوم. يسمح بروتوكول HTTP للعميل بالتعبير عن نيّته من خلال بضعة مُكوّنات: الرابط (URI)، وأفعال HTTP، وترويساته. تسمية الأشياء تمثّل الروابط (URIs) حجر الأساس في الويب، لأنّها تحل مشكلة مهمّة على مستوى الإنترنت بكاملها، وهي مشكلة منح الأشياء مُعرّفًا تنفرد به على الشّبكة. افترض أنّك سألت شخصًا أن يجلب لك شيئًا ويُحضره إليك، يمكن عدّ الطرق الممكنة للطلب على الأصابع. فعادةً ما تُعرّف الكلمات الّتي تستخدمها الشيء الّذي تريده. بإمكانك أن تطلب من صديقك قائلًا: "اجلب لي الكتاب." قد يجيبك صديقك: "حاضر. ولكن أي كتاب؟". فتقول أنت: "الكتاب في الغرفة الأخرى." فيذهب صديقك إلى الغرفة ويسأل: "أي كتاب قلت؟" فتقول أنت وقد شعرت بالضّيق: "الأخضر!" ليقول صديقك: "تمهّل لحظة... هناك كتابان أخضران في الغرفة!" وعندها تنهض لتحضر الكتاب بنفسك. كان الأمر ليكون أكثر بساطة لو أننا وحدنا طريقة نُحدّد فيها الأشياء بطريقة مميّزة للوصول إليها لاحقًا. إحدى الوسائل الممكنة هي الاعتماد على الذاكرة. كيف نعطي الأوامر لشخص ما ليحضر إلينا الغرض المطلوب؟ لنُنشئ نظامًا لذلك: قص ورقات صغيرة أو استخدم ورق الملاحظات اللّصّاق. ضع هذه الأوراق على الأغراض في الغرفة المجاورة أو على الطّاولة (كالكتب مثلًا). اكتب مُعرّفًا مُميِّزًا على كل ورقة. كرّر العملية في غرفة مجاورة أو على طاولة مجاورة. تذكّر أن هذا النّظام لا يقتصر على أغراضك، بل يمتد ليسمح بنوعٍ من التّواصل بين الأغراض جميعها. طبّقت هذا النّظام على أغراضي، فكتبت على كل قطعة ورق واحدًا من المُعرّفات التالية: myRoom.org/table/book/001 myRoom.org/shelf/book/002 otherRoom.org/cup/001 otherRoom.org/flower/001 otherRoom.org/book/001 أعتقد أنك الآن فهمت ما أقصد. لدينا الآن نظام من اللصاقات الّتي تستخدم لتحديد كل شيء في المكان بدقة. في الويب، نحن نتعامل مع فضاء معلومات واللصاقات المُستخدمة ليست سوى الروابط (URIs). الوصول إلى الأشياء المُسمَّاة شرحنا كيف يُبنى طلب HTTP في المقال السابق من خلال الطرفية. استخدمنا بناءً بسيطًا مع فعل HTTP المُسمّى GET مع ترويسة واحدة: Host. GET / HTTP/1.1 Host: www.opera.com القائمة الكاملة لأفعال HTTP الحالية هي: OPTIONS، GET، HEAD، POST، PUT، DELETE، TRACE، CONNECT. لكل فعل دورٌ مختلف عن الأفعال الأخرى وسنشرح ذلك في المقالات التالية. أكثر الأفعال استخدامًا هو GET، ففي كلّ مرة نُدخل عنوان HTTP في شريط العناوين في المتصفح، فإنّنا نرسل طلب GET إلى خادوم. في عالم الويب يُرسل العميل معلومات أكثر (المزيد من ترويسات HTTP) إلى الخادوم للتفاهم على المطلوب. يستغل الخادوم هذه المعلومات ليُعدّل الجواب بما يناسب الترويسات. تتوفّر أداة عمليّة جدًا في Opera Dragonfly لإنشاء طلبات HTTP مُخصّصة وفحص إجابة الخادوم. يمكنك إيجادها في قسم Network في تبويب "Make Request". هنالك ثلاث مناطق في تبويب Make Request: الرابط (URL): مُعرّف المُحتوى (أو عنوان الويب) متن الطّلب (Request body): ما سيُرسله العميل إلى الخادوم (يُرسل الزّر "Send request" الطّلب إلى الخادوم عبر الشّبكة) الجواب (Response): جواب الخادوم بعد إرسال الطّلب تخصيص طلب HTTP انسخ http://www.opera.com/ إلى قسم URL. انسخ والصق طلب HTTP التّالي إلى قسم "Request body" في تبويب Network. أضفنا الترويسة Accept-Language إلى طلب HTTP السابق. اضغط الزر "Send request". GET / HTTP/1.1 Host: www.opera.com Accept-Language: en سيُجيب خادوم Opera بجواب HTTP مؤلّف من بضع ترويسات يليها محتوى المستند. قد تحتاج إلى تمرير النافذة، لأن الجواب قد يكون طويلًا. لاحظ أن المُستند باللغة الإنكليزيّة، ليس فقط من حيث اللغة الّتي كتب بها، بل أيضًا يُنصّ على ذلك صراحةً في خاصّة lang على ال عنصر html: <!DOCTYPE html> <html lang="en"> لنُجرّب الفرنسيّة: GET / HTTP/1.1 Host: www.opera.com Accept-Language: fr سُيجيب الخادم هذه المرة بالفرنسيّة، ويتبيّن ذلك في نص المستند وفي مصدره: <!DOCTYPE html> <html lang="fr"> لاحظ أنّنا استخدمنا الرابط نفسه بالضّبط (http://www.opera.com/) ولكنّنا تلقّينا إجابتين مُختلفتين لا لشيء إلا لأننا غيّرنا الترويسة Accept-Language. لاحظ أيضًا أنّ الخادوم أجاب بترويسات كثيرة تُعطينا معلوماتٍ عن حالة المحتوى ونوعه... إلخ. يسمح هذا للعميل بتعديل أسلوب معالجة المستند. يمكنك تجربة لغات مُختلفة مثل اليابانية (ja) والألمانية (de)... إلخ. ما الذي يحدث إن طلبنا لغة غير موجودة على الخادوم؟ جرّب مثلًا الصّينيّة (zh): GET / HTTP/1.1 Host: www.opera.com Accept-Language: zh ستتلقى النسخة الإنكليزية من الموقع. هل هذا مُحيّر؟ الحقيقة أنّ هذا الأمر يعتمد على تصميم الموقع ذاته. فقد يُصمم جواب HTTP بأسلوب آخر، كأن يُجيب الخادوم "لا، ما من نسخة صينية من الموقع لدينا"، أو "ليست لدينا نسخة صينية، ولكن لدينا اللغات التالية: ...). ولكن فريق تجربة المستخدمين في Opera قرر إرسال النسخة الإنكليزية من الموقع عند طلب لغة غير مُتوفّرة. المسألة مسألة اختيار، فلا قاعدة تُفرض على المواقع بهذا الشأن. ولهذا السّبب أقوم عادةً بتعليم مُصمّمي تجربة الاستخدام ومُطوّري الواجهات بعض أساسيّات HTTP، فهو بروتوكول يتوسّط التفاعل بين العميل والخادوم، وعليه فإنّ فهمه يُساعد في تصميم تفاعلات ذات معنى عند بناء المواقع، وذلك للبشر والآلات معًا (كالبرامج الّتي تستخدم الواجهات البرمجيّة (APIs) وما شابهها... إلخ). تذكّر URI: نظام لتعريف المعلومات على الشبكة. أفعال HTTP: يتضمّن البروتوكول حاليًا الأفعال التّالية: OPTIONS، GET، HEAD، POST، PUT، DELETE، TRACE، CONNECT. وقد تعرّفنا في هذه المقالة على أكثرها استخدامًا وهو GET. ترويسات HTTP:** الترويسات هي بيانات إضافية يُرسلها العميل لإعطاء معلومات أكثر عن البيانات المُتبادلة بين العميل والخادوم. تُفيد بعض هذه الترويسات الخادوم بحيث يختار الأسلوب الأفضل للإجابة. ترجمة (بشيء من التّصرّف) لمقال HTTP: Let’s GET It On! لصاحبه Karl Dubosy.

مقدمة: إطار التحليل الشبكي Bro هو إطار عمل مفتوح المصدر لتحليل الشبكات يركز على مراقبة أمانها، وهو نتاج خمس عشرة سنة من البحث واستخدمته جامعات كثيرة ومعامل بحثية ومراكز حواسيب خارقة وعدد من مجتمعات العلوم المفتوحة-Open Science. وقد بدأ تطويره بشكل أساسي في المعهد الدولي لعلوم الحاسوب في بيركلي والمركز الوطني لتطبيقات الحواسيب الخارقة في أوربانا-شامبين في إيلينوي. وتتلخص مزايا Bro فيما يلي: سياسات مراقبة خاصة بكل موقع، إذ تسمح لغة Bro النصية-scripting language بذلك استهداف الشبكات عالية الأداء. محللات للعديد من البروتوكولات، مما يسمح بالتحليل الدلالي عالي المستوى-High Level Semantic Analysis حتى على مستوى التطبيق. جمع إحصائيات شاملة على مستوى التطبيق للشبكة التي يراقبها. تسجّيل كل شيء يراقبه، ويوفّر أرشيفًا عالي المستوى لنشاط الشبكة. متطلبات Bro للعمل على الخادم يحتاج Bro إلى الاعتماديات-Dependencies التالية: Libpcap مكتبات Open SSL مكتبة BIND8 Libz Bash (نحتاجها من أجل BroControl) Python إصدار 2.6 أو أحدث (من أجل BroControl) كما يتطلب بناؤه من المصدر ما يلي: CMake 2.8 أو أحدث Make GCC 4.8 فأحدث، أو Clang 3.3 فأحدث SWIG GNU Bison Flex Libpcap headers OpenSSL headers zlib headers بدء العمل ثبّت الاعتماديات المطلوبة بتنفيذ الأمر التالي: # apt-get install cmake make gcc g++ flex bison libpcap-dev libssl-dev python-dev swig zlib1g-dev تثبيت قاعدة بيانات GeoIP من أجل موقع IP الجغرافي يعتمد Bro على GeoIP لتحديد الموقع الجغرافي للعنوان، فثبّت إصدارات IPv4، وIPv6 عبر هذه الأوامر: $ wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz $ wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCityv6-beta/GeoLiteCityv6.dat.gz فُكّ ضغط تلك الأرشيفات التي حملناها: $ gzip -d GeoLiteCity.dat.gz $ gzip -d GeoLiteCityv6.dat.gz انقل الملفات التي فككناها إلى مجلد GeoIP: # mvGeoLiteCity.dat /usr/share/GeoIP/GeoIPCity.dat # mv GeoLiteCityv6.dat /usr/share/GeoIP/GeoIPCityv6.dat بناء Bro من المصدر سنحصل على احدث إصدار من مستودعات git (اقرأ هذا المقال لتثبيتgit وإعداده إن لم يكن مثبتًا لديك)، عبر الأمر التالي: $ git clone --recursive git://git.bro.org/bro نذهب إلى هذا المجلد المنسوخ-cloned directory، ونبني bro بهذه الأوامر: $ cd bro $ ./configure $ make سيستغرق أمر make بعض الوقت للبناء، ويتوقف هذا الوقت على قوة الخادم نفسه. ويمكن تنفيذ شفرة configure النصية مع بعض المعاملات-arguments لتحديد أي الاعتماديات تريد بناءها، خاصة خيارات (–with-*) تثبيت Bro داخل مجلد bro سابق الذكر، نفذ الأمر التالي، حيث سيكون مجلد التثبيت هو usr/local/bro/ # make install تهيئة وإعداد Bro تقع ملفات تهيئة Bro وضبطه في مجلد etc، في مسار usr/local/bro/etc/، وستجد ثلاثة ملفات: node.cfg، يستخدم لتحديد أي عقدة-node أو مجموعة عُقّد سيراقبها (العقدة في الشبكات هي جهاز يتلقى/يشكّل/يحوّل المعلومات الواردة عبره). broctl.cfg، ملف تهيئة BroControl. networks.cgf، يحتوي قائمة بالشبكات في ترميز التوجيه غير الفئوي-CIDR Notation. ضبط إعدادات البريد افتح ملف broctl.cfg، حيث تستبدل $EDITOR في الأمر التالي بالمحرر النصي الذي تفضله: # $EDITOR /usr/local/bro/etc/broctl.cfg ابحث في الملف عن قسم Mail Options، وعدل سطر MailTo كما يلي: # Recipient address for emails sent out by Bro and BroControl MailTo = admin@example.com استبدل عنوان البريد بالعنوان الذي تريد، ثم احفظ الملف وأغلقه. لديك الكثير من الخيارات هنا، لكن الخيارات الافتراضية جيدة ولا تحتاج تعديلات. اختيار العُقَد التي ستُراقَب إن Bro مجهز افتراضيًا ليعمل في الوضع المستقل-Standalone، وهو ما نشرحه في هذا المقال، لذا لن تحتاج إلى تغيير الكثير، لكن سننظر على أي حال في ملف node.cfg: # $EDITOR /usr/local/bro/etc/node.cfg يجب أن ترى شيئًا كهذا في قسم [bro]: [bro] type=standalone host=localhost interface=eth0 تأكد أن تكون الواجهة-interface مطابقة لواجهة خادم أوبنتو 16.04، ثم احفظ الملف وأغلقه. ضبط شبكات العقدة-Node’s Networks آخر ملف سنعدّل فيه هو network.cfg، افتحه باستخدام المحرر النصي الذي تفضله: # $EDITOR /usr/local/bro/etc/networks.cfg يجب أن ترى المحتوى التالي: # List of local networks in CIDR notation, optionally followed by a # descriptive tag. # For example, "10.0.0.0/8" or "fe80::/64" are valid prefixes. 10.0.0.0/8 Private IP space 172.16.0.0/12 Private IP space 192.168.0.0/16 Private IP space احذف المدخلات الثلاثة (التي هي أمثلة فقط لكيفية استخدام الملف)، وأدخل مساحةIP العامة والخاصة للخادم الخاص بك، على هذه الهيئة: X.X.X.X/X مساحة IP العامة X.X.X.X/X مساحة IP الخاصة احفظ الملف وأغلقه. إدارة تثبيت Bro باستخدام BroControl تحتاج إلى استخدام BroControl من أجل إدارة Bro، وهو يأتي في صورة صَدفة تفاعلية-interactive shell وأداة سطر أوامر، افتح الصدفة بالآتي: # /usr/local/bro/bin/broctl ولتستخدمها كأداة سطر أوامر، أضف معاملًا-argument إلى الأمر السابق، مثال: # /usr/local/bro/bin/broctl status سيتحقق هذا الأمر من حالة Bro بإخراج نتيجة كهذه: Name Type Host Status Pid Started bro standalone localhost running 6807 20 Jul 12:30:50 خاتمة ما شرحناه في هذا المقال يلخص دليل تثبيت Bro، وقد استخدمنا طريقة التثبيت من المصدر لأنها أكفأ طريقة ممكنة للحصول على آخر إصدار متوفر، لكن اعلم أن أداة تحليل الشبكات هذه يمكن تحميلها أيضًا في صورة ملف ثنائي/تنفيذي إن لم ترغب ببنائها من الصفر. ترجمة -بتصرف- لمقال Network Analysis: How To Install Bro On Ubuntu 16.04 لصاحبه Giuseppe Molica حقوق الصورة البارزة محفوظة لـ Freepik

يحتوي لينكس على عددٍ هائلٍ من الأدوات التي تلبي كافَّة احتياجات المستخدم؛ إن كانت استخداماتك في مجال التطوير أو الحماية أو إدارة الأنظمة …إلخ. فنظام لينكس هو أفضل خيارٍ من بين أنظمة التشغيل. إنَّ الأمر «netstat» هو أحد الأوامر المستخدمة بكثرة في لينكس لإظهار معلومات تفصيليَّة عن الشبكة وكيفية اتصال حاسوبك مع الحواسيب أو الشبكات الأخرى؛ فمن مهامه عرض اتصالات وحالة الشبكة وجداول التوجيه وغيرها من البيانات والمعلومات الإحصائيَّة. ظهر الأمر «ss» باعتباره إصدارًا جديدًا للأمر «netstat» ولكن سرعان ما حلَّ مكانه وأصبح بديلًا له في لينكس نظرًا لما يوفِّره من مزايا مثل السرعة وعرض معلومات أوسع وأكثر تفصيلًا بالإضافة إلى سهولته وبساطته، ويمكنك التأكد من ذلك بتصفح صفحة الدليل لكلا الأمرين. يستطيع الأمر «ss» عرض معلومات عن الرزم (packet)، والبروتوكولات TCP و UDP و DCCP و RAW، بالإضافة إلى جميع مقابس الشبكة؛ يمكنه أيضًا الحصول على معلومات تفصيليَّة حول كيفيَّة اتصال حاسوبك مع الحواسيب الأخرى، وإظهار بيانات إحصائيَّة حول بروتوكولات الشبكة والمقابس المتَّصلة؛ إنَّ الحصول على هذا الكم من المعلومات يساعدنا بالتأكيد على حلِّ مختلف مشاكل وأعطال الشبكة، وبالتالي تعتبر هذه الأداة من أهمِّ الأدوات في حقيبة الإسعافات الأوليَّة لمديري الأنظمة. الاستخدامات الأساسيَّة يُستخدم الأمر «ss» كغيره من الأوامر التي تعمل على لينكس وذلك بكتابته في سطر الأوامر وإتباعه بخياراته، ويمكن أخذ لمحة أوليّة عن الأمر «ss» وخياراته بقراءة صفحة الدليل لهذا الأمر وذلك باستخدام الأمر «man ss»؛ قد تجد للوهلة الأولى، بعد الاطلاع على صفحة الدليل لكلا الأمرين، أنَّ الأمر «netstat» يحوي كثيرًا من الخيارات خلافًا للأمر «ss» وتظنُّ أنَّ الأول أفضل وأكثر كفاءة من الثاني، والحقيقة خلاف ذلك. إن نفذت الأمر «ss» دون أي خيارات فستحصل على معلومات عن الاتصالات لمقابس TCP كما موضح بالصورة. يمكن حفظ المعلومات التي حصلت عليها للتو في ملف خارجي لاطلاع عليها لاحقًا باستخدام الأمر: ss > ss_output قد لا يكون الأمر «ss» كافيًا بعض الأحيان، فإذا أردت الحصول على قائمة بالمقابس التي تستمع للاتصالات. استخدم الخيار ‎-l مع الأمر السابق. ss -l يمكن أيضًا استخدام خيارات أخرى مثل الخيار ‎-t لعرض اتصالات TCP، والخيار ‎-u لعرض اتصالات UDP، والخيار ‎-x لعرض مقابس يونكس. توضح الصورة التالية ناتج تنفيذ الأمر ss -x. استخدام الخيارات السابقة سيعطي قائمةً بالاتصالات الحالية وإذا أردنا معرفة الاتصالات المنصتة فنضيف الخيار ‎-a كما يلي: ss -t -a وسيُظهر هذا الأمر جميع مقابس TCP التي تنصت للاتصالات كما تبيِّن الصورة؛ لاحظ أنَّ الخيار الأخير هو خدمة SSH وهي تنصت للاتصالات. إن جرَّبت الأداة «netstat» للحصول على المعلومات السابقة فستظهر حقول أخرى مثل اسم العملية PID، واسم الأمر المسؤول عن هذه الاتصالات وهذا ما يصعِّب من قراءتها. بإمكانك الآن معرفة عناوين IP والمنافذ المستخدمة في إنشاء الاتصال بين حاسوبك والحواسيب والشبكات الأخرى والتي ستساعدك لتتمكن من تحليل المشاكل والأعطال وإصلاحها، ولكن مازال هنالك بعضًا من المعلومات تنقصك يجب عليك معرفتها. تصفية النتائج باستخدام حالات اتصال TCP تصفية نتائج الأمر «ss» واحد من أكثر الخيارات فائدة؛ تعتمد عملية التصفية على حالات TCP التي تصف مراحل حياة الاتصال، إذ يمر أي جهازان قبل إنشاء اتصال بينهما وحتى إنهائه بمراحل عدَّة، وذلك لحصر المعلومات التي نريد الحصول عليها في مجال ضيق ومحدود. من حالات الاتصال TCP التي يمكن استخدام عملية التصفية معها هي: الحالة شرح الحالة closed “غير مُنشأ” هي الحالة الافتراضيَّة التي يكون فيها الجهاز قبل بدء عملية تأسيس الاتصال، أي أنَّ الجهاز غير متصل مع أحد. listening “استماع” يكون الجهاز (غالبًا الخادم) في هذه الحالة بانتظار استلام رسالة تزامن (SYN اختصارًا للعبارة synchronize) من العميل. syn-sent “’طلب التزامن” يرسل في هذه الحالة أحد الجهازين (غالبًا العميل) رسالة تزامن (SYN) إلى الجهاز الذي يريد بدء وتأسيس اتصال معه، وينتظر منه بالمقابل الرد برسالة تزامن أخرى. sys-recv “تأكيد التزامن” أرسل كلا الجهازين في هذه الحالة رسالة تزامن وينتظران تقرير الاستلام لهذه الرسائل لإنهاء إعداد وتهيئة الاتصال بينهما. established “مُنشأ” وهي الحالة الثابتة والمستقرة للاتصال بين جهازين، ويمكن بدء تبادل البيانات بينهما متى دخل كلا الجهازين في هذه الحالة وذلك بعد أن يكون كلٌّ منها قد أرسل رسالة تزامنٍ واستلم تقرير التوصيل من الآخر. close-wait “بدء إنهاء الاتصال” استلم في هذه الحالة أحد الجهازين رسالةً لإنهاء الاتصال (FIN)، اختصارًا للعبارة (finish)، من الآخر وهو بانتظار تأكيد هذه الرسالة لإنهاء الاتصال معه. fin-wait-1 “انتظار إنهاء الاتصال-1” يكون الجهاز -الذي يريد قطع الاتصال- في هذه الحالة بانتظار تقرير استلام رسالة إنهاء الاتصال (FIN) أو قطع الاتصال التي أرسلها للجهاز المقابل. fin-wait-2 “انتظار إنهاء الاتصال-2” يدخل الجهاز في هذه الحالة بعد استلام تقريرٍ عن توصيل رسالة إنهاء الاتصال التي أرسلها للجهاز الآخر وهو بانتظار رسالة (FIN) لتأكيد إنهاء الاتصال منه. closing “تأكيد إنهاء الاتصال” يدخل بها الجهاز بعد استلام رسالة إنهاء الاتصال (FIN) وإرسال تقرير باستلامها إلى الجهاز الآخر الذي يريد قطع الاتصال. last-ack “تقرير الاستلام الأخير” أرسل أحد الجهازين تقريرًا باستلام رسالة (FIN) من الجهاز الآخر الذي يريد قطع الاتصال ثم أعاد إرسال الرسالة (FIN) له لتأكيد قطع الاتصال وهو الآن بانتظار آخر تقرير يؤكد استلام هذه الرسالة. time-wait “مهلة إنهاء الاتصال” هو الوقت الذي ينتظره الجهاز بعد إرسال تقريره الأخير (last-ack) للتأكد من أنَّ الجهاز المقابل قد استلمه، وبعد انتهاء المهلة تصبح حالة هذا الجهاز “غير متصل” (closed). هنالك أيضًا حالات متاحة يمكن استعمالها مع الأمر «ss» وهي: all: اختيار جميع الحالات السابقة. connected: جميع الحالات السابقة باستثناء حالتي الاتصال “غير مُنشأ” (closed) و “استماع” (listening). synchronized: جميع حالات الخيار السابق باستثناء حالة إرسال رسالة التزامن (sys-sent). bucket: تشمل الحالتان sys-recv و time-wait. big: عكس الخيار السابق. إن وجدت نفسك تائهًا في دوامة تلك الحالات، أعد قراءتها بهدوء. طريقة كتابة الأمر «ss» وتصفية النتائج سهلة، وهي للعنوان Ipv4: ss -4 state FILTER أما للعنوان IPv6 فهو: ss -6 state FILTER غير العبارة “FILTER” إلى واحدة من الحالات السابقة. ومثال على ذلك استخدام الأمر التالي لعرض المقابس في حالة الاستماع: ss -4 state listening والنتائج التي ستحصل عليها هي كما مبيَّنة في الصورة. عرض المقابس المتصلة بعناوين محدَّدة توفِّر الأداة «ss» وسيلة للحصول على معلومات عن الاتصالات التي تنشأ مع عناوين IP محدَّدة؛ إن أردت معرفة فيما إذا كان الجهاز ذو العنوان 192.168.1.139 على سبيل المثال متصلًا بخادمك، فنفذ الأمر التالي: ss dst 192.168.1.139 ستحصل على معلوماتٍ شبيهةٍ بتلك الموجودة في الصورة التالية: حان دورك الآن عرضنا في هذا المقال بعضًا من الخيارات الأساسيَّة للأمر «ss» التي يفترض الإلمام بها والتي ستساعدك في تحليل وإصلاح المشاكل التي قد يتعرض لها خادمك أو شبكتك أثناء عملهم؛ توجَّه مباشرة بعد الانتهاء من هذه المقالة نحو صفحة الدليل للأمر «ss» للتعرُّف على المزيد من المهام والخيارات. ترجمة -وبتصرف- للمقال an introduction to the ss command لصاحبه Jack Wallen.

نظام ملفات الشبكة (NFS)يسمح NFS للنظام بمشاركة المجلدات والملفات مع الآخرين عبر الشبكة؛ إذ يمكن للمستخدمين والبرامج الوصول إلى الملفات في الأنظمة البعيدة كأنها ملفاتٌ محلية باستخدام NFS. بعض الميزات الملحوظة التي يوفرها استخدام NFS: محطات العمل المحلية تستهلك مساحة قرص أقل ﻷنها تستخدم بيانات يمكن تخزينها على جهاز واحد وتبقى متاحةً للبقية عبر الشبكة.لا توجد حاجة ليُنشَأ للمستخدمين مجلدات منزل منفصلة في كل جهاز شبكي؛ حيث يمكن ضبط مجلدات المنزل على خادوم NFS وتتوفر للجميع عبر الشبكة.أجهزة التخزين مثل سواقات CD-ROM وأقراص USB يمكن استخدامها من الأجهزة الأخرى على الشبكة، وربما يقلل هذا من عدد مشغلات الوسائط القابلة للإزالة في الشبكة.التثبيتأدخل الأمر الآتي في الطرفية لتثبيت خادوم NFS: sudo apt-get install nfs-kernel-serverالضبطتستطيع ضبط المجلدات لكي «تُصدَّر» عبر إضافتها لملف ‎/etc/exports، على سبيل المثال: /ubuntu *(ro,sync,no_root_squash) /home *(rw,sync,no_root_squash)تستطيع استبدال * بإحدى صيغ أسماء المضيفين، تأكد من أن تعريف اسم المضيف محدد كي لا تستطيع الأنظمة غير المعنية أن تصل إلى NFS. نفِّذ الأمر الآتي في مِحَث الطرفية لتشغيل خادوم NFS: sudo service nfs-kernel-server startضبط عميل NFSاستخدم الأمر mount لوصل مجلد NFS مشترك من جهاز لآخر؛ وذلك بكتابة أمرٍ شبيه بالأمر الآتي في الطرفية: sudo mount example.hostname.com:/ubuntu /local/ubuntuتحذير: يجب أن تكون نقطة الوصل ‎/local/ubuntu موجودةً مسبقًا، ولا يجب أن يكون هنالك أيّة ملفات أو مجلدات فرعية في نقطة الوصل. طريقة أخرى لوصل مشاركة NFS من جهاز لآخر هي إضافة سطر إلى ملف ‎/etc/fstab؛ يجب أن يُحدِّد هذا السطر اسم مضيف خادوم NFS، والمجلد الذي صُدِّرَ من الخادوم، والمجلد في الجهاز المحلي الذي يجب وصل NFS إليه؛ الشكل العام للسطر الذي سيُضاف إلى ملف ‎/etc/fstab هو: example.hostname.com:/ubuntu /local/ubuntu nfs rsize=8192,wsize=8192,timeo=14,intrإذا حدثت معك مشكلة في وصل NFS، فتأكد أن الحزمة nfs-common مثبتة في نظام عميلك؛ وذلك بإدخال الأمر الآتي في الطرفية: sudo apt-get install nfs-commonمصادرLinux NFS faqصفحة ويكي أوبنتو «NFS Howto»«مبادر»‏ iSCSI‏إن iSCSI‏ (Internet Small Computer System Interface) هو بروتوكول يسمح بنقل أوامر SCSI عبر الشبكة؛ عادةً يُستخدَم iSCSI في SAN‏ (Storage Area Network) للسماح للخواديم بالوصول إلى مخزن كبير لمساحة القرص الصلب؛ يُشير بروتوكول iSCSI للعملاء «بالمبادرين» (initiators) ولخواديم iSCSI بالأهداف (targets). يمكن أن يُضبَط خادوم أوبنتو كمبادر أو هدف iSCSI، يوفر هذا الدرس الأوامر والضبط اللازم لإعداد مبادر iSCSI، على فرض أنك تملك هدف iSCSI في شبكتك وتملك الامتيازات المناسبة للاتصال إليه؛ التعليمات حول إعداد هدف تختلف اختلافًا كبيرًا بين مزودي العتاد، لذلك راجع توثيق الشركة لضبط هدف iSCSI الذي عندك. تثبيت مبادر iSCSIلضبط خادوم أوبنتو كمبادر iSCSI، فثبِّت الحزمة open-iscsi بإدخال الأمر الآتي: sudo apt-get install open-iscsiضبط مبادر iSCSIبعد أن تُثبَّت حزمة open-iscsi، عليك تعديل الملف ‎/etc/iscsi/iscsid.conf مغيرًا ما يلي: node.startup = automaticتستطيع التأكد إذا كان الهدف متوفرًا حاليًا باستخدام الأداة iscsiadm؛ وذلك بإدخال الأمر الآتي في الطرفية: sudo iscsiadm -m discovery -t st -p 192.168.0.10‎-m: يحدد النمط الذي سيُنفَّذ فيه iscsiadm.‎-t: يحدد نوع الاستكشاف.‎-p: يحدد عنوان IP للهدف.ملاحظة: عدِّل 192.168.0.10 إلى عنوان IP للهدف على شبكتك المحلية. إذا كان الهدف متوفرًا، فيجب أن تشاهد مخرجات شبيهة بما يلي: 192.168.0.10:3260,1 iqn.1992-05.com.emc:sl7b92030000520000-2ملاحظة: قد يختلف رقم iqn وعنوان IP في الأعلى بناءً على العتاد الذي تستخدمه. يجب أن تكون الآن قادرًا على الاتصال بهدف iSCSI، واعتمادًا على إعدادات الهدف، فربما تحتاج لإدخال بيانات المستخدم لتسجيل الدخول إلى عقدة iSCSI: sudo iscsiadm -m node --loginتأكد الآن أن القرص الجديد قد عُثِرَ عليه باستخدام dmesg: dmesg | grep sd [ 4.322384] sd 2:0:0:0: Attached scsi generic sg1 type 0 [ 4.322797] sd 2:0:0:0: [sda] 41943040 512-byte logical blocks:(21.4GB/20.0 GiB) [ 4.322843] sd 2:0:0:0: [sda] Write Protect is off [ 4.322846] sd 2:0:0:0: [sda] Mode Sense: 03 00 00 00 [ 4.322896] sd 2:0:0:0: [sda] Cache data unavailable [ 4.322899] sd 2:0:0:0: [sda] Assuming drive cache: write through [ 4.323230] sd 2:0:0:0: [sda] Cache data unavailable [ 4.323233] sd 2:0:0:0: [sda] Assuming drive cache: write through [ 4.325312] sda: sda1 sda2 < sda5 > [ 4.325729] sd 2:0:0:0: [sda] Cache data unavailable [ 4.325732] sd 2:0:0:0: [sda] Assuming drive cache: write through [ 4.325735] sd 2:0:0:0: [sda] Attached SCSI disk [2486.941805] sd 4:0:0:3: Attached scsi generic sg3 type 0 [2486.952093] sd 4:0:0:3: [sdb] 1126400000 512-byte logical blocks: (576 GB/537 ↪ GiB) [2486.954195] sd 4:0:0:3: [sdb] Write Protect is off [2486.954200] sd 4:0:0:3: [sdb] Mode Sense: 8f 00 00 08 [2486.954692] sd 4:0:0:3: [sdb] Write cache: disabled, read cache: enabled, ↪ doesn't support DPO or FUA [2486.960577] sdb: sdb1 [2486.964862] sd 4:0:0:3: [sdb] Attached SCSI diskفي الناتج أعلاه، يكون sdb هو قرص iSCSI الجديد؛ تذكر أن هذا مجرد مثال، قد يختلف الناتج عمّا تراه على الشاشة. أنشِئ الآن قسمًا، وهيّء نظام الملفات، وصِل قرص iSCSI الجديد؛ وذلك بإدخال ما يلي في الطرفية: sudo fdisk /dev/sdb n p enter wملاحظة: الأوامر الآتية من داخل الأداة fdisk؛ راجع man fdisk لتعليمات تفصيلية؛ أيضًا الأداة cfdisk في بعض الأحيان تكون «صديقة» للمستخدم أكثر. هيّء الآن نظام الملفات وصِله إلى ‎/srv على سبيل المثال: sudo mkfs.ext4 /dev/sdb1 sudo mount /dev/sdb1 /srvفي النهاية، أضف مدخلة إلى ‎/etc/fstab لوصل قرص iSCSI أثناء الإقلاع: /dev/sdb1 /srv ext4 defaults,auto,_netdev 0 0فكرة جيدة هي التأكد أن كل شيء يعمل على ما يرام قبل إعادة تشغيل الخادوم. مصادرموقع Open-iSCSI الإلكتروني.صفحة ويكي دبيان «Open-iSCSI».ترجمة -وبتصرف- للمقالين: Ubuntu Server Guide: Network File System NFS و Ubuntu Server Guide: ISCSI Initiator.