عند إنشاءك خادم أوبونتو 18.04 للمرة الأولى، يجب عليك اتخاذ بعض الخطوات كجزء من الإعدادات الأولية. سيزيد ذلك من أمان وسهولة استخدام الخادم، ويمنحك أساسًا قويًا لإجراءات لاحقة.

ملاحظة: يشرح المقال أدناه الخطوات التي نوصي بها لإكمال تهيئة خادم أوبنتو 18.04 يدويا. اتباع هذه الاعدادات اليدوية سيساعدك في تعلم بعض المهارات الأساسية لإدارة الخادم وكتمرين لفهم الإجراءات التي تحدث في الخادم بصورة عامة. إن كنت تريد تهيئة الخادم وبدء استخدامة بسرعة، يمكنك استخدام نصنا البرمجي لتهيئة الخادم الأولي والذي ينفذ خطوات التهيئة تلقائيا.

خطوة 1 - تسجيل الدخول كمستخدم مسؤول (root)

تحتاج لمعرفة عنوان بروتوكول الإنترنت العام (public IP) للخادم الخاص بك لتسجيل الدخول. تحتاج أيضا إلى كلمة المرور، أو المفتاح السري لمستخدم مسؤول (ما يسمى ب root users) إن كنت قد ثبتت مفتاح SSH للمصادقة. إن لم تكن قد سجلت الدخول إلى الخادم الخاص بك، فيمكنك اتباع المقال حول كيفية الاتصال ب Droplet باستخدام SSH.

قم بتسجيل الدخول إلى الخادم كمستخدم مسؤول root إن كنت غير متصلا حتى الآن باستخدام الأمر التالي. استبدل النص المظلل بعنوان بروتوكول الإنترنت العام للخادم الخاص بك.

$ ssh root@your_server_ip

في حال ظهور تحذير عن موثوقية المضيف قم بقبوله. إن كنت تقوم بالدخول باستخدام إثبات الهوية؛ قم بتقديم كلمة المرور. أما إن كنت تستخدم مفتاح SSH المحمي بعبارة مرور (passphrase)، سيُطلب منك إدخال عبارة المرور في بداية كل جلسة. قد يُطلب منك أيضا تغيير كلمة المرور للمستخدم المسؤول root في أول مرة تقوم بالتسجيل بها.

عن المستخدم root

المستخدم المسؤول root في بيئة لينكس هو المتحكم والذي يمتلك صلاحيات عديدة. ونظرا لهذه الصلاحيات فلا ينصح باستخدامه دائمًا وذلك لتجنب القيام بتغييرات عن طريق الخطأ.

الخطوة التالية هي إعداد مستخدم بديل بصلاحيات أقل للعمل اليومي. كما سنشرح كيفية إضافة صلاحيات في أي وقت تحتاج إليها.

خطوة 2 - إنشاء مستخدم جديد

بعد تسجيل دخولك كمستخدم مسؤول root، فأنت جاهز لإضافة حساب مستخدم جديد لاستخدامه من الآن فصاعدا.

الأمر التالي يقوم بإنشاء مستخدم بالاسم sammy، يمكنك تسمية المستخدم بأي اسم تريده.

 # adduser sammy

ستُعرض عليك بعض الاسئلة بدأَ بكلمة مرور للحساب الجديد.

يجب أن تقوم بإدخال كلمة مرور قوية. ومن ثم تعبئة باقي المعلومات والتي تعتبر اختيارية ويمكنك تجاوزها بالضغط على زر ENTER.

خطوة 3 - منح صلاحيات إدارية

يمتلك الحساب الذي قمنا بإنشائه صلاحيات اعتيادية. لكن قد نحتاج في بعض الأحيان إلى صلاحيات إدارية.

لتجنب الخروج من هذا المستخدم والدخول إلى المستخدم المسؤول root بكثرة؛ يمكننا إعداد ما يسمى بصلاحيات المستخدم الأعلى أو صلاحيات مسؤول root لحساب المستخدم العادي، مما يتيح للمستخدم العادي تنفيذ الأوامر التي تحتاج إلى صلاحيات إدارية عن طريق استخدام الكلمة "sudo" قبل كل أمر.

لإضافة هذه الصلاحيات للمستخدم الجديد، نحتاج لإضافة هذا المستخدم إلى مجموعة sudo. يمكن للمستخدمين ضمن مجموعة sudo في اوبنتو 18.14 استخدام الأمر sudo.

نفِّذ الأمر التالي لإضافة المستخدم الجديد إلى مجموعة sudo، يجب أن تكون متصلا بالخادم باستخدام حساب مسؤول root (استخدم اسم المستخدم الذي أنشأته مسبقا).

# usermod -aG sudo sammy

الآن يمكنك الدخول باستخدام الحساب الجديد وتنفيذ الأوامر ذات الصلاحيات العليا عن طريق كتابة "sudo" قبل هذه الأوامر.

خطوة 4 - إعداد جدار حماية رئيسي

يمكن لخادم أوبونتو 18.04 استخدام جدار الحماية Uncomplicated Firewall) UFW) -جدار الحماية في نظام لينكس- للتأكد من عدم الاتصال سوى بخدمات معينة. يمكن إعداد جدار حماية رئيسي بسهولة باستخدام تطبيق UFW.

ملاحظة: إن كان الخادم الخاص بك يعمل على DigitalOcean؛ فيمكنك استخدام DigitalOcean Cloud Firewalls بدلا من تطبيق UFW وذلك يعد اختياريا. يستحسن استخدام جدار حماية واحد فقط لتجنب أي تعارضات والتي قد تكون صعبة التصحيح.

يمكن لمختلف التطبيقات تسجيل ملفات التعريف الخاصة بها مع UFW أثناء تثبيتها. تسمح هذه الملفات لتطبيق UFW بإدارة هذه التطبيقات وفقا لاسم التطبيق. لدى خدمة OpenSSH (Open Secure Shell) -أداة الاتصال الأولى لتسجيل الدخول عن بُعد باستخدام بروتوكول SSH- التي تتيح لنا الاتصال بالخادم ملف تعريف مسجل لدى UFW.

لرؤية ذلك نستخدم الأمر:

 # ufw app list

المخرجات:

Available applications:

  OpenSSH

يجب التأكد من أن جدار الحماية يسمح لاتصالات SSH حتى نتمكن من تسجيل الدخول مرة أخرى. يمكن القيام بذلك باستخدام الأمر:

 # ufw allow OpenSSH

ثم يمكننا تفعيل جدار الحماية:

 # ufw enable

قم بإدخال الحرف "y" وقم بالضغط على "ENTER" للمتابعة، للتأكد من أن اتصالات SSH ما زالت تعمل نفذ الأمر:

  # ufw status

المخرجات

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

في حال قمت بإعداد خدمات إضافية، قم بتعديل إعدادات جدار الحماية للسماح باتصالات هذه الخدمات؛ كون جدار الحماية يقوم بمنع الاتصالات عدا اتصالات SSH. يمكنك اتباع هذا المقال لتعلم بعض عمليات UFW الشهيرة.

خطوة 5 - السماح بالوصول الخارجي للمستخدم الجديد

بما أنه أصبح لدينا مستخدم جديد للاستخدام اليومي، سنحتاج للتأكد من أنه يمكننا الدخول إلى هذا المستخدم عبر SSH.

ملاحظة: للتأكد من ذلك، يمكنك الدخول إلى المستخدم الجديد باستخدام كلمة المرور واستخدام sudo. يستحسن البقاء متصلا باسم المستخدم المسؤول root. بهذه الطريقة يمكنك تصحيح أي مشاكل وإضافة أي تعديلات تحتاجها. إن تستخدم واجهتك أي مشكلة في الاتصال بالمستخدم المسؤول root باستخدام SSH وكنت تستخدم DigitalOcean Droplet فيمكنك الدخول إلى Droplet باستخدام شاشة أوامر DigitalOcean.

عملية إعداد وصول SSH لمستخدم الجديد تعتمد على ما إن كان حساب المستخدم المسؤول root يستخدم كلمة مرور أو مفتاح SSH للمصادقة.

في حال كان المستخدم root يستخدم المصادقة بكلمة المرور

إن كنت مسجلا دخولك إلى حساب المستخدم المسؤول root باستخدام كلمة مرور، فإن عملية المصادقة باستخدام كلمة المرور مفعلة ل SSH. مما يمكنك من إضافة SSH لحساب المستخدم الجديد عن طريق تنفيذ الأمر التالي مستخدما اسم المستخدم الذي انشأته سابقا:

 $ ssh sammy@your_server_ip

بعد إدخال كلمة المرور الخاصة بالمستخدم الجديد؛ ستكون مسجلًا إلى النظام بالحساب الجديد ويمكنك تنفيذ الأوامر الإدارية من خلاله عن طريق إضافةsudoقبل الأمر:

 $ sudo command_to_run

سيطلب منك النظام إدخال كلمة المرور الخاصة بالمستخدم الحالي لأول مرة من كل جلسة ومن ثم في بعض الأوقات فقط.

لتعزيز أمان الخادم الخاص بك، يستحسن أن تقوم بإعداد مفاتيح SSH بدلا من استخدام كلمة المرور للمصادقة. يمكنك اتباع هذا المقال عن كيفية إعداد مفاتيح SSH على أوبنتو 18.04 لتتعرف على طريقة إعداد المصادقة المعتمده على المفاتيح السرية.

في حال كان المستخدم المسؤول root يستخدم المصادقة بمفتاح SSH

في حال كنت مسجلا الى حساب المسؤول root باستخدام مفاتيح SSH، فإن المصادقة باستخدام كلمة المرور ل SSH معطلة. للدخول إلى حساب المستخدم الجديد بنجاح، تحتاج لإضافة نسخة من المفتاح العام المحلي إلى الملف "‎~/.ssh/authorized_keys".

يمكنك أيضا نسخ الملف "‎~/.ssh/authorized_keys" - والذي يحتوي على المفتاح العام الخاص بك- من حساب المسؤول root إلى الحساب الجديد باستخدام الجلسة الحالية.

لنسخ الملف بطريقة سهلة وبالملكية والصلاحيات الصحيحة؛ نستخدم الأمر "rsync". سيقوم هذا الأمر بنسخ مجلد "‎.ssh" للمستخدم المسؤول root ،يحافظ على الصلاحيات ويقوم بتعديل ملكية الملفات في مرة واحدة. تأكد من وضع اسم المستخدم الجديد الذي أنشأته مسبقا.

ملاحظة يتعامل الأمر "rsync" مع المجلدات التي تنتهي بشرطة مائلة "/" بطريقة مختلفة عن المجلدات التي لا تنتهي بشرطة مائلة. تأكد من أن أسماء المجلدات (‎~/.ssh) لا تنتهي بشرطة مائلة عند استخدام هذا الأمر"‎~/.ssh/‎".

في حال أضفت شرطة مائلة في نهاية اسم المجلد عن طريق الخطأ في هذا الأمر، فسيقوم بنسخ محتويات المجلد من حساب المستخدم المسؤول root إلى المجلد الرئيسي لمستخدم "sudo" بدلا من نسخ الهيكل كاملا للمجلد "‎~/.ssh". وهكذا تكون الملفات في المكان الخاطئ ولن يتمكن SSH من العثور عليها واستخدامها.

 # rsync --archive --chown=sammy:sammy ~/.ssh /home/sammy

الآن يمكنك استخدام SSH مع المستخدم الجديد عن طريق الأمر التالي في شاشة الأوامر:

 $ ssh sammy@your_server_ip

يجب أن تقوم بالدخول إلى المستخدم الجديد بدون استخدام كلمة مرور. تذكر، لتنفيذ أمر باستخدام صلاحيات إدارية استخدم "sudo" قبل الأمر:

 $ sudo command_to_run

ماذا بعد؟

الآن أصبح لديك إعدادات قوية للخادم الخاص بك. يمكنك تثبيت اي برنامج تحتاجه. اطلع على قسم لينكس في الأكاديمية لقراءة دليل آخر أو تعلم تثبيت برامج أخرى.

ترجمة -وبتصرف- للمقال Initial Server Setup with Ubuntu 18.04 لصاحبه الكاتب Justin Ellingwood.

حاوية لينكس (Linux container) هي تجميع لمجموعة من عمليات تكون منفصلة عن باقي النظام عبر استعمال الخصائص الأمنية لنواة لينكس مثل مجالات الأسماء (Namespaces) ومجموعات المراقبة (Control groups). وهي بنية مُشابهة للأجهزة الوهميّة (Virtual Machines)، إلا أنها أكثر خفّة، بحيث أنك لن تحتاج إلى تشغيل نواة إضافية أو محاكاة العتاد، ما يعني أنه بالإمكان إنشاء حاويات متعددة على نفس الخادوم. ويُمكنك باستعمال حاويات لينكس تشغيل وحدات متعددة لأنظمة تشغيل بأكملها، كلّها محجوزة بنفس الخادوم. أو تحزيم تطبيقاتك الخاصة والملفات التابعة لها في حاوية خاصة دون التأثير على باقي مكونات النظام.

على سبيل المثال تخيّل أنك تملك خادوما وتريد تجهيز عدد من الخدمات، بما فيها المواقع اﻹلكترونية لعملائك. في النظام التقليدي، كل موقع إلكتروني سيكون عبارة عن مضيف وهمي (virtual host) من نفس خادوم Nginx أو Apache، لكن مع حاويات لينكس، كل موقع إلكتروني يتم إعداده في حاويته الخاصة مع خادوم ويب خاصّ به. ﻹنشاء وتسيير هذه الحاويات يمكن استعمال LXD الذي يوفر خدمة مراقبة الأجهزة الافتراضية hypervisor لتسيير دورة حياة الحاويات بأكملها. سنقوم في هذا الدرس بتنصيب موقعين إلكترونيين مبنيين على Nginx في نفس الخادوم. كل منهما محجوز في حاويته الخاصة، ثم سنقوم بتنصيب HAProxy ليعمل على شكل وسيط عكسي (reverse proxy) على حاوية ثالثة، ثم سنقوم بتوجيه الزوار إلى حاوية HAProxy لجعل كلا الموقعين قابلين للولوج من خلال شبكة الإنترنت.

المتطلّبات

لإتمام المطلوب نحتاج إلى ما يلي:

• خادوم Ubuntu 16.04 معد بإتباع الخطوات المتواجدة في هذا الدّرس ومستخدم إداري بامتيازات sudo غير المستخدم الجذر وجدار ناري.

• اسما نطاق مؤهلان بالكامل (FQDNs)، مع كل سجل DNS A موجه نحو عنوان IP الخاصّ بالخادوم، لتحقيق ذلك يمكن إتباع هذا الدرس.

اختياريا، قم بإضافة 20 GB من تخزين الكتل (Block storage) عن طريق إتباع هذا الدرس الذي يُمكن استعماله لتخزين جميع البيانات المتعلقة بالحاويات.

الخطوة الأولى - إضافة المستخدم إلى مجموعة LXD

نسجل الدخول إلى الخادوم عن طريق حساب المستخدم غير الجذر الذي سيُستعمل لتأدية جميع مهام تسيير الحاوية، وليُنجِز ذلك يجب إضافة هذا الحساب إلى مجموعة lxd عن طريق الأمر التّالي:

sudo usermod --append --groups lxd sammy

أبدل sammy باسم المستخدم الخاصّ بك. نقوم بتسجيل الخروج من الخادوم ثم تسجيل الدخول إليه لتحديث جلسة SHH بعضوية المجموعة الجديدة، بعد ذلك، يمكن البدء بإعداد LXD.

الخطوة الثانية - إعداد LXD

يحتاج LXD إلى إعدادات معينة ليعمل بالشكل المطلوب قبل استعماله، نوع التخزين على مستوى الواجهة الخلفية هو أهم إعداد يجب علينا تحديده، لتخزين الحاويات، التخزين المقترح لـLXD هو استعمال ملف من نوع ZFS مُخزّن إما داخل ملف مخصص مسبقا أو عن طريق استعمال تخزين الكتل. لدعم ملفات ZFS في LXD، سنقوم بتنصيب حزمة zfsutils-linux:

sudo apt-get update
sudo apt-get install zfsutils-linux

بعد ذلك سنكون مستعدين لتهيئة LXD، أثناء التهيئة سيُطلَبُ منك تخصيص تفاصيل تخزين ZFS على مستوى النظام الخلفي. هناك طريقتان لذلك اعتمادا على إذا ما كنا سنستعمل ملفا معدا مسبقا أو تخزين الكتل، بعد تحديد آلية التخزين سنقوم بإعداد اختيارات تواصل الحاويات الخاصة بنا. لكن قبل ذلك، سنتعرّف على خياري تهيئة التّخزين.

الخيار الأول - استعمال ملف مخصص مسبقا

اتبع الخطوات التالية لإعداد LXD لاستعمال ملف مخصص مسبقا لتخزين الحاويات. أولا نفّذ اﻷمر التالي لبدأ عملية تهيئة LXD:

sudo lxd init

سيُطلب منا اﻹدلاء بمجموعة من المعلومات كما يظهر في النتائج التالية، سنقوم باختيار الاختيارات الافتراضية بما في ذلك حجم الملف المقترح والمسمى جهاز الحلقة (loop device).

المُخرجات:

Name of the storage backend to use (dir or zfs) [default=zfs]: zfs
Create a new ZFS pool (yes/no) [default=yes]? yes
Name of the new ZFS pool [default=lxd]: lxd
Would you like to use an existing block device (yes/no) [default=no]? no
Size in GB of the new loop device (1GB minimum) [default=15]: 15
Would you like LXD to be available over the network (yes/no) [default=no]? no
Do you want to configure the LXD bridge (yes/no) [default=yes]? yes
Warning: Stopping lxd.service, but it can still be activated by:
  lxd.socket
LXD has been successfully configured.

يتم حساب الحجم المقترح تلقائيا بناء على المساحة المتاحة في الخادوم. بعد إعداد الجهاز، سنقوم بضبط إعدادات التشبيك، لكن قبل ذلك، لنتعرّف على الخيار الثاني.

الخيار الثاني - استعمال تخزين الكتل

إذا كنت تريد استعمال تخزين الكتل، ستحتاج إلى البحث عن الجهاز الذي يُشير نحو حجم تخزين الكتل (block storage volume) الذي تمّ إنشاؤه لتخصيصه في إعدادات LXD، سنذهب إلى تبويبة Volumes في لوحة التحكم الخاصّة بـDigitalOcean. ثم نقوم بتحديد مكان للمساحة ثم النقر على النافذة المنبثقة More، ثم انقر على Config instructions.

نقوم بتحديد مكان الجهاز عن طريق النّظر إلى مُخرج أمر تشكيل الحجم، ابحث بشكل خاص عن المسار المخصّص في أمر sudo mkfs.ext4 -F.

تمثل الوثيقة التالية مثالا على هذا الحجم:

الذي يهمنا هو الجزء المسطر بالأحمر.

في هذه الحالة اسم الحجم هو:

/dev/disk/by-id/scsi-0D0_Volume_volume-fra1-01

يمكن لهذا الاسم أن يختلف في حالتك. بعد تعريف الحجم سنعود إلى الطرفية وسننفّذ الأمر التالي لبدء عملية تهيئة LXD:

sudo lxd init

سوف تُطرَح علينا مجموعة من اﻷسئلة، أجب عليها بالأجوبة المُوضّحة أسفله:

Name of the storage backend to use (dir or zfs) [default=zfs]: zfs
Create a new ZFS pool (yes/no) [default=yes]? yes
Name of the new ZFS pool [default=lxd]: lxd

إذا طُلب منك استخدام جهاز كتل جاهز آنفا فاختَر نعم (yes)، مع اﻹدلاء بمساره.

Would you like to use an existing block device (yes/no) [default=no]? yes
Path to the existing block device: /dev/disk/by-id/scsi-0DO_Volume_volume-fra1-01

ثم اختر القيم الافتراضية لباقي اﻷسئلة.

Would you like LXD to be available over the network (yes/no) [default=no]? no
Do you want to configure the LXD bridge (yes/no) [default=yes]? yes
Warning: Stopping lxd.service, but it can still be activated by:
  lxd.socket
LXD has been successfully configured.

بعد انتهاء العملية، سنقوم بإعداد الشبكة.

إعداد التشبيك (Networking)

ستُظهِر لنا عمليّة التّهيئة مجموعة من شاشات التّعليمات كما هو موضّح في الصورة أسفله، ستمكّننا هذه التّعليمات من إعداد جسر التشبيك للحاويات حتى تتمكن من الحصول على عناوين IP خاصّة بها، وتتمكن من التواصل بينها والاتصال بشبكة الأنترنت.

قم باستعمال جميع القيم الافتراضية باستثناء تشبيك IPv6، قم باختيار الخيار No في هذه الحالة. إذ لن نستعمله في هذا الدرس.

بعد الانتهاء من إعداد التّشبيك، ستكون جاهزا لإنشاء الحاويات.

الخطوة الثّالثة - إنشاء الحاويات

قمنا بإعداد LXD بنجاح، إذ قمنا بتخصيص موقع للتخزين على مستوى الواجهة الخلفية وقمنا بإعداد التشبيك الافتراضي ﻷي حاويات منشأة حديثا.

ما يعني بأنّنا جاهزون ﻹنشاء وتسيير بعض الحاويات، وذلك باستعمال الأمر lxc. أول أمر سنُجرّبه هو الأمر lxc list، والذي يُعطينا لائحة الحاويات المُنصّبة المتوفرة:

lxc list

المُخرجات:

Generating a client certificate. This may take a minute...
If this is your first time using LXD, you should also run: sudo lxd init
To start your first container, try: lxc launch ubuntu:16.04

+------+-------+------+------+------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+-------+------+------+------+-----------+

ولأنها المرة اﻷولى التي يتواصل فيها أمر lxc مع مراقب الأجهزة الافتراضية (Hypervisor) الخاص بـLXD،فإن المخرج يخبرنا بأن اﻷمر قام بإنشاء شهادة عميل تلقائيا وذلك للتواصل اﻵمن مع LXD. بعد ذلك، يخبرنا بمعلومات حول كيفيّة إطلاق الحاويات، ثمّ يعرِض لائحة فارغة من الحاويات ﻷننا لم ننشئ أيا منها بعد. لنَقُم بإنشاء ثلاثة حاويات، واحدة لكل خادوم ويب والثالثة للوسيط العكسي، دور هذا اﻷخير هو توجيه الاتصالات الواردة من اﻷنترنت نحو الخادوم المناسب داخل الحاوية.

نقوم باستعمال أمر lxc launch لإنشاء وتشغيل حاوية (ubuntu:x) Ubuntu 16.04 باسم web1. الحرف x في ubuntu:x هو اختصار لكلمة Xenial الاسم الرمزي لـUbuntu 16.04، أمّا ubuntu: فهو مُعرّف المجلد المضبوط مسبقا الخاص بصور LXD.

ملاحظة: يمكنك الوصول إلى اللائحة الكاملة لصور Ubuntu المتاحة عن طريق الأمر lxc image list ubuntu:، ولتوزيعات أخرى استعمل اﻷمر lxc image list images:.

نفّذ الأوامر التالية لإنشاء الحاويات:

lxc launch ubuntu:x web1
lxc launch ubuntu:x web2
lxc launch ubuntu:x haproxy

وبما أنها المرة اﻷولى التي ننشئُ فيها الحاويات، فسيقوم اﻷمر اﻷول بتنزيل صور الحاويات من اﻷنترنت وسيخزنها محليا، ستُنشَئُ الحاويّتان المتبقيّتان بشكل أسرع.

لاحظ بيانات المخرج جرّاء إنشاء الحاوية web1:

Creating web1
Retrieving image: 100%
Starting web1

بعد أن قمنا بإنشاء ثلاثة حاويات فارغة سنقوم باستعمال الأمر lxc list ﻹظهار المعلومات حولها:

lxc list

يُظهِر المخرج جدولا باسم الحاوية وحالتها الحالية، عنوان IP الخاص بها، نوعها وما إذا تم أخد أية لقطات (snapshots) لها:

+---------+---------+-----------------------+------+------------+-----------+
|  NAME   |  STATE  |         IPV4          | IPV6 |    TYPE    | SNAPSHOTS |
+---------+---------+-----------------------+------+------------+-----------+
| haproxy | RUNNING | 10.10.10.10 (eth0)    |      | PERSISTENT | 0         |
+---------+---------+-----------------------+------+------------+-----------+
| web1    | RUNNING | 10.10.10.100 (eth0)   |      | PERSISTENT | 0         |
+---------+---------+-----------------------+------+------------+-----------+
| web2    | RUNNING | 10.10.10.200 (eth0)   |      | PERSISTENT | 0         |
+---------+---------+-----------------------+------+------------+-----------+

سَجِّل أسماء الحاويات وعناوين IPv4 الخاصة بها لأننا سنحتاجها لإعداد الخدمات.

الخطوة الرابعة - إعداد حاويات Nginx

لنقم بالاتصال مع الحاوية web1 وإعداد الخادوم اﻷول، وللقيام بذلك نستعمل الأمر lxc exec الذي يأخذ اسم الحاوية والأوامر التي تريد تنفيذها.

استعمل اﻷمر التالي للاتصال بالحاوية:

lxc exec web1 -- sudo --login --user ubuntu

يَدُلّ المقطع -- على أنّ العوامل التي ستُمرَّرُ للأمر lxc ستنتهي وسيتم تمرير باقي السطر على شكل أوامر للتنفيذ داخل الحاوية، اﻷمر الذي سيُمرَّرُ في هذه الحالة هو sudo --login --user ubuntu والذي يوفر صدفة ولوج (login shell) للحساب ubuntu المعد مسبقا داخل الحاويّة. ملاحظة: إذا كنت تريد الاتصال بالحاوية بصلاحيات حساب الجذر، فقم باستعمال اﻷمر lxc exec web1 -- /bin/bash عوضا عمّا سبق. فور الدخول إلى الحاويّة، سيظهر لنا محثّ الصدفة على الشكل التالي:

ubuntu@web1:~$

المُستخدم ubuntu هذا معد مسبقا بصلاحيات sudo داخل الحاوية ويستطيع إصدار أوامر sudo دون الحاجة إلى اﻹدلاء بكلمة المرور. هذه الصدفة محدودة داخل حدود الحاوية. أي أنّ أيّ أمر نُشغله داخل هذه الصدفة يبقى داخل الحاوية ولا يخرج إلى الخادوم المُضيف. لِنحدّث لائحة حزم Ubuntu داخل الحاوية ولنُنصِّب Nginx:

sudo apt-get update
sudo apt-get install nginx

لنعدل صفحة الويب الافتراضية لهذا الموقع ولنُضِف نصّا يوضح أن هذا الموقع مستضاف على الحاوية web1. افتح الملف /var/www/html/index.nginx-debian.html:

sudo nano /var/www/html/index.nginx-debian.html

قم بالتعديلات التالية للملف:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx on LXD container web1!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx on LXD container web1!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
...

قمنا بتعديل الملف في مكانين العنوان <title> والوسم <h1> وذلك بإضافة المقطع on LXD container web1.

أغلق المحرر بعد الحفظ. واﻵن، سجّل الخروج من الحاوية لنَعودَ إلى الخادوم المُضيف:

logout

سنُكرر نفس اﻷمر بالنسبة لحاويّة web2، نسجل الدخول نُنصّب Nginx ثمّ نعدّل الملفّ /var/www/html/index.nginx-debian.html لذِكرِ web2، ثم نخرج من الحاويّة web2. لنستعمل curl للتأكد من أن الخواديم داخل الحاويات تعمل بشكل جيد. نحتاج إلى عناوين IP الخاصّة بالحاويات، والتي حصلنا عليها سابقا.

curl http://10.10.10.100/

يجب على المُخرج أن يكون كما يلي:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx on LXD container web1!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx on LXD container web1!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
...

تفقّد الحاوية الثانية كذلك باستعمال الأمر curl وعنوان IP الخاصّ بها للتّأكد من أنّها قد ضُبطت بالشكل الصحيح، يمكن المرور إلى ضبط HAProxy بعد ذلك.

الخطوة الخامسة - إعداد حاوية HAProxy

سنقوم بإعداد حاوية HAProxy لتعمل كوسيط أمام هاتين الحاويتين. ولمزيد من المعلومات حول طريقة عمل HAProxy يمكنك الرجوع إلى هذا الدرس.

سنقوم بتوجيه حركة المرور نحو كل حاوية بناءا على اسم النطاق الذي نستعمله، سوف نستعمل اسم النطاق example.com في مثال الإعدادات الموالي، وهو نطاق خاص للتوثيقات التعليمية مثل هذا الدرس، سنقوم بإنشاء أول موقع إلكتروني متاح على اسمي النطاق example.com و www.example.com. الموقع اﻹلكتروني الثاني سيكون على اسم النّطاق www2.example.com. أبدِل أسماء النطاقات الخاصة بك مكان هذه اﻷسماء.

سجل الدخول إلى حاوية haproxy:

lxc exec haproxy -- sudo --login --user ubuntu

حدّث لائحة الحزم ونصِّب HAProxy:

sudo apt-get update
sudo apt-get install haproxy

بعد انتهاء التنصيب سننتقل إلى إعداد HAProxy. ملف إعدادات HAProxy مُتواجد في المسار ‎/etc/haproxy/haproxy.cfg. افتح هذا الملف بواسطة محرر النصوص المُفضّل لديك:

sudo nano /etc/haproxy/haproxy.cfg

أولا سنقوم ببعض التعديلات في قسم defaults. سنقوم بإضافة خيار forwardfor لكي نحتفظ بعنوان IP المصدري لعميل الويب، وسنضيف الخيار http-server-close، والذي سيقوم بتمكين إعادة استخدام الجلسة (session reuse) وتخفيض زمن الوصول (Latency).

global
...
defaults
    log global
    mode    http
    option  httplog
    option  dontlognull
    option   forwardfor
    option   http-server-close
    timeout connect 5000
    timeout client  50000
    timeout server  50000
...

سنقوم بعد ذلك بإعداد الواجهة اﻷمامية للإشارة نحو حاويتي الواجهة الخلفية الخاصة بنا. أضف قسم frontend تحت اسم www_frontend كما يلي:

frontend www_frontend
    bind *:80     # Bind to port 80 (www) on the container

    # It matches if the HTTP Host: field mentions any of the hostnames (after the '-i').
    acl host_web1 hdr(host) -i example.com www.example.com
    acl host_web2 hdr(host) -i web2.example.com

    # Redirect the connection to the proper server cluster, depending on the match.
    use_backend web1_cluster if host_web1
    use_backend web2_cluster if host_web2

توافق أوامر acl أسماء مُضيفات خواديم الويب ثم تقوم بإعادة توجيه الطلب إلى قسم backend المناسب. ثم نعرف قسمي backend جديدين واحد لكل خادوم ويب، ثم نقوم بتسميتهما web1_cluster وweb2_cluster تباعا.

أضف الشفرة التالية للملف لتعريف الواجهات الخلفية:

backend web1_cluster
    balance leastconn
    # We set the X-Client-IP HTTP header. This is useful if we want the web server to know the real client IP.
    http-request set-header X-Client-IP %[src]
    # This backend, named here "web1", directs to container "web1.lxd" (hostname).
    server web1 web1.lxd:80 check

backend web2_cluster
    balance leastconn
    http-request set-header X-Client-IP %[src]
    server web2 web2.lxd:80 check

يحدّد خيار balance استراتيجية موازنة الحمل (load-balancing). في هذه الحالة، نُفضّل اقل عدد من الاتصالات. خيار http-request يضبط ترويسة HTTP (HTTP header) مع عنوان IP الخاصّ بعميل الويب الحقيقي، إذا لم نحدد هذه الترويسة فإن خادوم الويب سيسجل عنوان HAProxy IP على انه العنوان المصدري لجميع الاتصالات مما سيصعب تحليل أماكن و أصول حركة المرور. يُخصّص خيار server اسما كيفيا (arbitrary name) للخادوم web1 متبوعا باسم المُضيف ومنفذ الخادوم. يُزوّد LXD الحاويات بخادوم DNS، وذلك لكي يُشير web1.lxd إلى عنوان IP التّابع للحاوية web1. الحاويات اﻷخرى لها أسماء مُضيفات خاصة بها مثل web2.lxd وhaproxy.lxd.

يدفع المُعامل check HAProxy إلى أداء فحوصات السلامة (Health checks) على الخادوم للتأكد من توفره.

لاختبار صحة اﻹعدادات، نفّذ اﻷمر التالي:

/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -c

ينبغي على المخرج أن يكون كما يلي:

Configuration file is valid

لِنُعد تحميل Haproxy لكي يقرأ اﻹعدادات الجديدة:

sudo systemctl reload haproxy

والآن سجل الخروج من الحاوية للعودة إلى المُضيف:

logout

قمنا بتجهيز Haproxy ليتصرف على شكل وسيط عكسي يوجّه أي اتصال يتلقاه عبر المنفذ رقم 80 نحو الخادوم الملائِم داخل كلا الحاويتين. لنتحقق من أن haproxy يستطيع فعلا تحويل الطلبات نحو الحاوية الصحيحة. ولذلك نستعمل اﻷمر التّالي:

curl --verbose --header 'Host: web2.example.com' http://10.10.10.10

يُرسل الأمر أعلاه طلبا لـHAProxy ويضبط ترويسة HTTP باسم host والتي سيستعملها HAProxy لتوجيه الاتصال نحو الخادوم الملائم.

يجب على المخرج أن يكون كالتالي:

...
> GET / HTTP/1.1
> Host: web2.example.com
> User-Agent: curl/7.47.0
> Accept: */*
> 
...
< 
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx on LXD container web2!</title>
<style>
...

تمكن Hproxy من فهم الطلب وتوجيهه نحو الحاوية web2 بنجاح. ومنه فإن الخادوم قدم لنا الصّفحة الرّئيسيّة الافتراضيّة التي قمنا بتعديلها سابقا وأظهر النص on LXD container web2.

لنقم الآن بتوجيه الطلبات الخارجية إلى HAProxy حتى يتمكن بقية العالم من الولوج إلى مواقعنا الإلكترونية.

الخطوة السادسة - توجيه الاتصالات الواردة نحو حاوية HAProxy

القطعة اﻷخيرة من اﻷحجية هي توصيل الوسيط العكسي مع شبكة اﻷنترنت. نحتاج إلي ضبط الخادوم لتوجيه أي اتصال وارد إليه من اﻷنترنت عبر المنفذ 80 نحو حاوية HAProxy.

نُصِّبَ HAProxy في حاوية خاصّة به، وبالتالي، فإنه غير قابل للولوج من اﻷنترنت افتراضيا ولحل هذه المشكلة، سنقوم بإنشاء قاعدة iptables لتوجيه الاتصالات. يحتاج اﻷمر iptables إلى عنواني IP، عنوان الخادوم العمومي (your_server_ip) وعنوان IP الخاصّ بالحاويّة haproxy (أي your_haproxy_ip أسفله)، والذي نحصل عليه من خلال اﻷمر lxc list.

نفّذ هذا اﻷمر ﻹنشاء القاعدة:

sudo iptables -t nat -I PREROUTING -i eth0 -p TCP -d your_server_ip/32 --dport 80 -j DNAT --to-destination your_haproxy_ip:80

وهذا شرح لتفاصيل هذا اﻷمر:

• المقطع -t nat يعني بأننا نستعمل الجدول nat.
• المقطع -I PREROUTING يعني أننا نضيف القاعدة إلى سلسلة التوجيه المسبَق (PREROUTING).
• المقطع -i eth0 يعني أن الواجهة eth0 هي التي ستُستَعمَل، وهي الواجهة العمومية الافتراضية على الخواديم.
• المقطع -p TCP يعني أننا نستعمل بروتوكول TCP.
• المقطع -d your_server_ip/32 يحدد عنوان IP الهدف للقاعدة.
• المقطع --dport 80 يُحدّد رقم المنفذ الهدف.
• المقطع -j DNAT يعني أننا نريد أن نؤدي قفزة نحو الهدف NAT (DNAT).
• المقطع --to-destination your_haproxy_ip:80 يدلّ على أننا نريد من الطلب الذهاب إلى عنوان IP الخاصّ بالحاوية من طريق HAProxy.

للمزيد من المعلومات حول IPTables، تفقّد الدّرس ما هو الجدار الناري وكيف يعمل؟ والدّرس أساسيات IPTables - قواعد وأوامر شائعة للجدار الناري .

أخيرا لحفظ أمر iptables لكي يُعاد تطبيقُه بعد إعادة التشغيل نقوم بتنصيب حزمة iptables-persistent:

sudo apt-get install iptables-persistent

أثناء تنصيب الحزم سيطلب منك حفظ قواعد iptables الحاليّة. وافق واحفظ جميع قواعد iptables الحاليّة.

إذا قمت بإعداد اسمي نطاق FQDN، فسيمكنك أن تتصل بكل من الموقعين باستعمال متصفحك. لذا جرب ذلك.

للتحقق من أن الخادومين يمكن الولوج لهما عن طريق اﻷنترنت، ادخل إلى كل منهما باستعمال حاسوبك المحلي عن طريق أمر curl بالشكل التالي:

curl --verbose --header 'Host: example.com' 'http://your_server_ip'
curl --verbose --header 'Host: web2.example.com' 'http://your_server_ip'

هذه اﻷوامر تقوم باتصالات HTTP مع عنوان IP العمومي الخاصّ بالخادوم وتضيف حقل ترويسة HTTP مع خيار --header والذي سيستعمله HAProxy لتنفيذ الطلب كما فعلنا في الخطوة الخامسة.

هذا هو المخرج بالنسبة لأمر curl الأول:

*   Trying your_server_ip...
* Connected to your_server_ip (your_server_ip) port 80 (#0)
> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx/1.10.0 (Ubuntu)
...
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx on LXD container web1!</title>
<style>
    body {
...

وهذا هو مٌخرج الأمر الثّاني:

*   Trying your_server_ip...
* Connected to your_server_ip (your_server_ip) port 80 (#0)
> GET / HTTP/1.1
> Host: web2.example.com
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx/1.10.0 (Ubuntu)
...
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx on LXD container web2!</title>
<style>
    body {
...

تم إظهار الموقع الصحيح في كلتا الحالتين.

خاتمة

قمت الآن بضبط موقعي ويب كل منهما داخل حاويته الخاصة مع HAProxy كموجه للمرور، يمكنك تكرار نفس العملية ﻹعداد مواقع ويب أخرى كل داخل حاويته الخاصة، يمكن كذلك إضافة MySQL في حاوية جديدة وتنصيب نظام إدارة محتوى مثل Wordpress لتسيير كل موقع ويب على حدة.

يمكنك كذلك استعمال هذه العملية لدعم نُسخِِ أقدم من برمجية معينة، على سبيل المثال، إن كان نظام إدارة محتوى يتطلب برمجية قديمة مثل PHP5 فبإمكانك تنصيب Ubuntu 14.04 على حاوية (lxc launch ubuntu:t) عوضا عن محاولة تخفيض إصدارات مدير الحزم المتوفرة على Ubuntu 16.04.

يوفر LXD القدرة على أخذ لقطات للحالة الكاملة للحاويات، ما يجعل إنشاء النسخ الاحتياطية وإرجاع الحاويات إلى الوراء في وقت لاحق أمرا سهلا. إضافة إلى ما سبق فتنصيب LXD على خادومين مختلفين يمكّن من الربط بينهما وتهجير الحاويات بين الخواديم عبر الإنترنت.

ترجمة -بتصرّف- للمقال How to Host Multiple Web Sites with Nginx and HAProxy Using LXD on Ubuntu 16.04 لصاحبه Simos Xenitellis.

ProxySQL هو عبارة عن خادم وكيل (proxy server) مفتوح المصدر لخادم قاعدة البيانات MySQL، أي أنه يعمل كوسيط بين خادم قاعدة البيانات MySQL والتطبيقات التي تتعامل مع قاعدة البيانات هذه. حيث يقوم الخادم الوكيل بتحسين الأداء، وذلك عن طريق توزيع النقل بين خوادم قاعدة البيانات مشتركة. كما يحسّن من عملية توفّر قاعدة البيانات، وذلك من خلال الانتقال الآلي إلى خادم أخر متاح عند فشل أحد خوادم قاعدة البيانات.

سيتم في هذه المقالة شرح طريقة تنصيب الخادم الوكيل ProxySQL كموازن تحميل (load balancer، توزيع الحمل) لعدة خوادم بيانات MySQL مع تمكين الانتقال الآلي إلى الخوادم المتاحة عند فشل أحدها. حيث سيتم استخدام مجموعة التناسخ المتماثل Group Replication ذات العُقد الرئيسية المتعددة multi-primary مكونة من ثلاث خوادم MySQL، غير أنه يمكن تطبيق الشرح الوارد في هذه المقالة على أي عدد من الخوادم.

المتطلبات

قبل البدء يجب أن يتوفر ما يلي:

• خادم أوبنتو 16.04 يتضمن على حساب مستخدم عادي (غير جزر) بصلاحيات sudo وجدار حماية.
• ثلاث خوادم بيانات MySQL مهيّأة للعمل كمجموعة تناسخ متماثل، والتي يمكن إعدادها اعتمادًا على هذه المقالة، الفقرة multi-primary.

الخطوة الأولى- تنصيب ProxySQL

قام مطورو ProxySQL بتوفير حزم أوبنتو رسمية لكل إصدارات ProxySQL، وذلك على صفحتهم في موقع GitHub، لذا سنقوم بتحميل أخر إصدار ProxySQL من هذه الصفحة، حيث تتضمن هذه الصفحة على لائحة بجميع إصدارات ProxySQL، وكل إصدار تَمّت تسميته وفق الصيغة proxysql_version-distribution.deb، إذ version هي عبارة عن رقم إصدار حزمة ProxySQL مثل 1.4.4، و distribution هي عبارة عن توزيعة لينكس المخصصة لها هذه الحزمة مثل ubuntu16_amd64.

سنقوم الآن بتحميل أخر إصدار من حزمة ProxySQL (1.4.4 هو آخر إصدار لحظة كتابة هذه المقالة) إلى المسار ‎/tmp، وذلك بتنفيذ الأوامر التالية في موجه أوامر لينكس:

$ cd /tmp
$  curl -OL https://github.com/sysown/proxysql/releases/download/v1.4.4/
proxysql_1.4.4-ubuntu16_amd64.deb

ثم نقوم بعد انتهاء عملية التحميل، بتنصيب هذه الحزمة باستخدام أداة إدارة حزم ‎.deb البرمجية dpkg، وذلك بتنفيذ الأوامر التالية في موجه أوامر لينكس:

$ sudo dpkg -i proxysql_*

حيث استُخدمت الراية ‎-i للدلالة على رغبتنا بتنصيب الحزمة من ملف محدد. ثم نقوم بعد انتهاء عملية التنصيب بحذف ملف الحزمة المُحمّل لعدم الحاجة إليه بعد الآن، وذلك بتنفيذ الأمر التالي:

$ rm proxysql_*

نحتاج الآن لتطبيق عميل لقاعدة البيانات MySQL ليتصل مع نسخة ProxySQL المُنصّبة، ذلك لأن ProxySQL يستخدم واجهة تخاطب متوافقة مع MySQL من أجل مهام الإدارة. لذا سنستخدم موجه أوامر MySQL، والذي هو جزء من الحزمة mysql-client المتوفرة على مخازن حزم أوبنتو. لكن قبل البدء بتنصيب هذه الحزمة يجب أن نحدّث مستودع الحزم لضمان تحميل وتنصيب آخر إصدار من هذه الحزمة، وذلك بتنفيذ الأمر التالي:

$ sudo apt-get update

ثم نقوم بتنصيب الحزمة mysql-client، وذلك بتنفيذ الأمر التالي:

$ sudo apt-get install mysql-client

أصبح لدينا الآن جميع متطلبات تشغيل ProxySQL، غير أن هذه الخدمة لا تُشَّغل آليًا بعد التنصيب، لذا يتوجب علينا تشغيلها يدويًا وذلك بتنفيذ الأمر التالي:

$ sudo systemctl start proxysql

سيعمل ProxySQL الآن بإعداداته الافتراضية، والتي يمكن عرضها بتنفيذ الأمر التالي:

$ systemctl status proxysql

فنحصل على الخرج التالي في نافذة موجه الأوامر:

● proxysql.service - LSB: High Performance Advanced Proxy for MySQL
   Loaded: loaded (/etc/init.d/proxysql; bad; vendor preset: enabled)
   Active: active (running) since Thu 2017-12-21 19:19:20 UTC; 5s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 12350 ExecStart=/etc/init.d/proxysql start (code=exited، status=0/SUCCESS)
    Tasks: 23
   Memory: 30.9M
      CPU: 86ms
   CGroup: /system.slice/proxysql.service
           ├─12355 proxysql -c /etc/proxysql.cnf -D /var/lib/proxysql
           └─12356 proxysql -c /etc/proxysql.cnf -D /var/lib/proxysql

حيث تدلّ العبارة active (running) على أن ProxySQL مُنصَّب وفي حالة عمل.

في الخطوة التالية سنقوم بزيادة الأمان، وذلك بإعداد كلمة السر المستخدمة للدخول إلى الواجهة التخاطبية لإدارة ProxySQL.

الخطوة الثانية- إعداد كلمة سر مدير ProxySQL

يستخدم ProxySQL في أول مرة يتم تشغيله فيها بعد التنصيب ملف الإعدادات القادم مع الحزمة، وذلك من أجل التهيئة الابتدائية لجميع إعداداته بالقيم الافتراضية، إذ يقوم ProxySQL بعد عملية التهيئة هذه بحفظ هذه الإعدادات في قاعدة البيانات، والتي يمكن إدارتها وتعديلها عن طريق موجه أوامر MySQL. لذا يجب عند إعداد كلمة سر مدير ProxySQL الاتصال بقاعدة البيانات الخاصة بالإعدادات لتعديل الإعدادات الموافقة.

لإعداد كلمة السر سنقوم في البداية بالدخول إلى الواجهة التخاطبية لإدارة ProxySQL، وذلك بتنفيذ الأمر التالي:

$ mysql -u admin -p -h 127.0.0.1 -P 6032 --prompt='ProxySQLAdmin> '

• ‎-u: يُستخدم هذا العلَم لتحديد اسم المستخدم الذي يريد القيام بالمهام الإدارية مثل تغيير الإعدادات، وبما أنه لم يتم بعد إضافة أي مستخدم، لذا تم استخدام اسم المستخدم الافتراضي admin.
• ‎-h: يُستخدم هذا العلَم لتحديد المضيف المُراد الاتصال به، وبما أننا نريد الاتصال بالواجهة التخاطبية لإدارة ProxySQL المحلي لذا استخدمنا المضيف المحلي 127.0.0.1.
• ‎-P: يُستخدم هذا العلَم لتحديد منفذ الاتصال بالواجهة التخاطبية لإدارة ProxySQL، حيث تَستخدم هذه الواجهة التخاطبية المنفذ 6032.
• ‎--prompt: وهو علَم اختياري لتغيير الموجِّه الافتراضي mysql>‎، حيث قمنا هنا بتغييره إلى ProxySQLAdmin>‎ لتوضيح أننا اتصلنا بالواجهة التخاطبية لإدارة ProxySQL، وذلك لتجنب الالتباس لاحقًا عند الاتصال أيضًا بخوادم قاعدة البيانات MySQL.

عند تنفيذ الأمر السابق سيطلب منا موجه الأوامر إدخال كلمة سر الدخول إلى الواجهة التخاطبية لإدارة ProxySQL، وبما أننا لم نقم بإعدادها بعد، لذا سنُدخل كلمة السر الافتراضية admin.

عند نجاح عملية الدخول إلى الواجهة التخاطبية لإدارة ProxySQL، يتغيّر موجه أوامر النظام إلى الموجه ProxySQLAdmin>‎ الخاص بالواجهة التخاطبية لإدارة ProxySQL كما يلي:

ProxySQL administration console prompt

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.5.30 (ProxySQL Admin Module)

Copyright (c) 2000، 2017، Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

ProxySQLAdmin>

ثم نقوم بتغيير كلمة السر مدير ProxySQL، وذلك بتنفيذ الأمر التالي في موجه أوامر الواجهة التخاطبية لإدارة ProxySQL:

ProxySQLAdmin> UPDATE global_variables SET variable_value='admin:password' 
WHERE variable_name='admin-admin_credentials';

Output
Query OK، 1 row affected (0.00 sec)

حيث تمّ استخدام الأمر UPDATE من أجل تغيير كلمة السر password للحساب الإداري admin الموجودة في المتغير admin-admin_credentials ضمن قاعدة البيانات global_variables.

طبعًا يجب استبدال password في الأمر السابق بكلمة سر قوية قبل تنفيذه.

لا تدخل عملية تغيير كلمة السر حيِّز التنفيذ مباشرة، وذلك نتيجة بنية نظام الإعدادات الخاص بالخادم ProxySQL، والذي يتكون من ثلاث طبقات منفصلة هي:

• طبقة الذاكرة MEMORY: وهي عبارة عن قواعد بيانات الإعدادات المُحمّلة في الذاكرة والتي يتم التفاعل معها والتعديل عليها مباشرة من خلال موجه أوامر الواجهة التخاطبية لإدارة ProxySQL.
• طبقة وقت التشغيل RUNTIME: يَستعمل ProxySQL هذه الطبقة لتفعيل الإعدادات المعدَّلة ودخولها حيز التنفيذ مباشرة.
•  طبقة القرص DISK: وهي عبارة عن قاعدة بيانات محفوظة على القرص الصلب والتي يتم فيها حفظ الإعدادات، حيث تُحمَّل هذه الإعدادات في طبقة الذاكرة عند إقلاع النظام، وبالتالي تضيع أي تعديلات تم إجرائها على هذه الإعدادات في طبقة وقت التشغيل، وذلك أثناء إعادة تشغيل النظام إن لم يتم حفظها في طبقة القرص.

أي أن التعديلات التي قمنا بإجرائها على كلمة السر مازالت في طبقة الذاكرة، ولتدخل حيز التنفيذ يجب نقلها إلى طبقة وقت التشغيل، وذلك بتنفيذ الأمر التالي موجه أوامر الواجهة التخاطبية لإدارة ProxySQL:

ProxySQLAdmin> LOAD ADMIN VARIABLES TO RUNTIME;

ثم يجب القيام بحفظها في طبقة القرص كي نحافظ عليها بشكل دائم، وذلك بتنفيذ الأمر التالي موجه أوامر الواجهة التخاطبية لإدارة ProxySQL:

ProxySQLAdmin> SAVE ADMIN VARIABLES TO DISK;

حيث استُخدم الأمر ADMIN من أجل التعامل مع المتغيرات المتعلقة فقط بموجه أوامر الواجهة التخاطبية لإدارة ProxySQL.

هذا ويستخدم ProxySQL أوامر مشابهة للتي يستخدمها خادم MySQL، في التعامل مع الأقسام الأخرى من الإعدادات، والتي سيتم استخدامها لاحقًا في هذه المقالة.

الآن وبعد أن تم تنصيب ProxySQL وإعداد كلمة سر مدير النظام، سنقوم بإعداد ثلاث عُقد MySQL ليتمكن ProxySQL من مراقبتها.

الخطوة الثالثة- إعداد المراقبة في MySQL

يجب أن يكون ProxySQL قادرًا على الاتصال بعُقد MySQL ليتمكن من تقدير حالتها، ولتنفيذ ذلك يجب أن يكون قادرًا على الاتصال بكل خادم عن طريق مستخدم مخصص. لذا سنقوم بإعداد المستخدم الضروري في عُقد MySQL وتنصيب وظائف SQL إضافية، والتي تسمح لخادم ProxySQL بالاستعلام عن حالة مجموعة التناسخ المتماثل.

وبما أن مجموعة التناسخ المتماثل قد تم إعدادها مسبقًا، لذا يجب أن تُطبَّق الخطوات التالية على عضو وحيد من المجموعة.

نفتح نافذة موجه أوامر نظام لينكس ثانية، ثم نسجل الدخول إلى الخادم الذي يحوي أحد عُقد MySQL، وذلك بتنفيذ الأمر التالي:

$ ssh sammy@your_mysql_server_ip_1

ثم نحمل ملف SQL الذي يحتوي على بعض الوظائف الضرورية لدعم عمل مجموعة التناسخ المتماثل الخاصة بالخادم الوكيل ProxySQL، وذلك بتنفيذ الأمر التالي في موجه الأوامر:

$ curl -OL https://gist.github.com/lefred
/77ddbde301c72535381ae7af9f968322/raw
/5e40b03333a3c148b78aa348fd2cd5b5dbb36e4d/addition_to_sys.sql

ملاحظة: إن هذه الملف مُوفَّر من قبل مطوري ProxySQL غير أنه موجود ضمن مخزن GitHub شخصي، مما يعني أنه قد يُحذف أو يصبح قديمًا. لكنه قد يُضاف في المستقبل لمخزن ProxySQL الرسمي على شكل ملف له إصدار. ولمزيد من المعلومات حول هذا الملف يمكن قراءة المقال التالي: native ProxySQL support for MySQL group replication.

يمكن رؤية محتويات هذا الملف بتنفيذ الأمر التالي:

$ less addition_to_sys.sql

ثم نقوم بتنفيذ الأمر التالي على الملف، حيث سيطلب منا موجه أوامر MySQL إدخال كلمة السر المستخدم الجذر root:

$ mysql -u root -p < addition_to_sys.sql

في حال نجاح عملية تنفيذ الأمر السابق، فإنه لن يظهر أي خرج في نافذة موجه الأوامر. وتصبح جميع عُقد MySQL قادرة على تأمين الوظائف الضرورية لتمكين قدرة ProxySQL على معرفة حالة مجموعة التناسخ المتماثل.

والآن نحتاج لإنشاء مستخدم مخصص ليستخدمه ProxySQL في مراقبة سلامة نسخ البيانات. لكن علينا في البداية الدخول إلى موجه أوامر MySQL والذي سيطلب منا مرة أخرى إدخال كلمة سر المستخدم الجزر root:

$ mysql -u root -p

نقوم الآن بإنشاء المستخدم المخصص والذي سنسميه monitor، وذلك بتنفيذ الأمر التالي في موجه أوامر MySQL بعد استبدال كلمة السر monitorpassword بأخرى قوية:

(member1)mysql> CREATE USER 'monitor'@'%' IDENTIFIED BY 'monitorpassword';

ثم نقوم بمنح هذا المستخدم صلاحية الاستعلام عن حالة خوادم MySQL، وذلك بتنفيذ الأمر:

(member1)mysql> GRANT SELECT on sys.* to 'monitor'@'%';

وأخيرًا نُطبِّق التعديلات لتصبح سارية المفعول، وذلك بتنفيذ الأمر التالي:

(member1)mysql> FLUSH PRIVILEGES;

وبما أننا نعمل ضمن مجموعة التناسخ المتماثل، فإن إضافة مستخدم مخصص لمراقبة حالة أحد عُقد المجموعة، سيُطبَّق على جميع العُقد الأخرى في المجموعة.

سيتم في الخطوة التالية تزويد ProxySQL بمعلومات المستخدم المخصص للمراقبة، ليتمكن ProxySQL من الدخول إلى عُقد MySQL.

الخطوة الرابعة- إعداد المراقبة في ProxySQL

سنقوم بإعداد ProxySQL ليستخدم مستخدم جديد أثناء مراقبة عُقد MySQL، وذلك عن طريق تحديث قيمة المتغيّر الموافق. وذلك بشكل مشابه لطريقة إعداد كلمة سر مدير ProxySQL في الخطوة الثانية.

ننتقل إلى موجه أوامر الواجهة التخاطبية لإدارة ProxySQL، ثم نحدّث قيمة المتغير mysql-monitor_username بقيم حساب المستخدم المخصص لمراقبة عُقد MySQL، وذلك بتنفيذ الأمر:

ProxySQLAdmin> UPDATE global_variables SET variable_value='monitor' 
WHERE variable_name='mysql-moniter_username';

ولكي يأخذ هذا التحديث حيّز التنفيذ، يجب تطبيقه على طبقة وقت التشغيل ثم حفظه في طبقة القرص، وذلك بتنفيذ الأوامر التالية في موجه أوامر الواجهة التخاطبية لإدارة ProxySQL:

ProxySQLAdmin> LOAD MYSQL VARIABLES TO RUNTIME;
ProxySQLAdmin> SAVE MYSQL VARIABLES TO DISK;

حيث استخدمنا الأمر MYSQL بدل ADMIN عند تحديث قيمة المتغير، لأننا نتعامل هنا مع متغيرات إعداد MySQL.

وهكذا تم إعداد ProxySQL بحساب المستخدم المراقب، وسيتم في الخطوة التالية إضافة عُقد MySQL إلى ProxySQL.

الخطوة الخامسة- إضافة عُقد MySQL إلى ProxySQL

لجعل ProxySQL مدركاً لعُقد MySQL، يجب إخباره بطريقة توزُّع هذه العُقد في المجموعات المضيفة، والتي هي عبارة عن مجموعة محددة من العُقد. وتعرَّف كل مجموعة مضيفة برقم موجب مثل 1 أو 2. حيث تُستخدم المجموعات المضيفة من أجل توجيه استعلامات SQL المختلفة إلى مجموعات مختلفة من المضيفات عند قيام ProxySQL بتوجيه الاستعلامات.

يتم في إعدادات التناسخ الثابتة تعيين المجموعات المضيفة بشكل اعتباطي، غير أن مجموعة التناسخ المتماثل الخاصة بالخادم ProxySQL تقوم آليًا بتقسيم جميع العُقد الموجودة فيها إلى أربع مجموعات مضيفة وذلك حسب حالتها كما يلي:

• مجموعة عُقد الكتابة: وهي عبارة عن مجموعة عُقد MySQL التي تقبل الاستعلامات الخاصة بتغيير البيانات. حيث يراعي ProxySQL المحافظة على العدد الأعظمي المعرَّف من العقد الرئيسية في هذه المجموعة.
• مجموعة عُقد الكتابة الاحتياطية: وهي كذلك الأمر مجموعة عُقد MySQL التي تقبل الاستعلامات الخاصة بتغيير البيانات، غير أنه لا يتم تعيينها كعقد كتابة إلا في حال فشل أحد عُقد مجموعة الكتابة. حيث يضع ProxySQL في هذه المجموعة العُقد الرئيسة المتبقية عند تجاوز عدد العُقد الرئيسية العدد الأعظمي المطلوب في مجموعة الكتابة.
• مجموعة عُقد القراءة: وهي مجموعة العُقد التي لا تقبل الاستعلامات الخاصة بتغيير البيانات، ويتم استخدمها فقط لقراءة البيانات. ولا يضع ProxySQL إلا العُقد الثانوية في هذه المجموعة.
• مجموعة العُقد المفصولة: وتتضمن هذه المجموعة على العُقد الرديئة من حيث الاتصال ونقل البيانات.

إن المعرِّف الرقمي لكل مجموعة مضيفة لا يتم تحديده آليًا، لذا يجب إخبار ProxySQL بالمعرِّف الرقمي الذي سيتم استخدامه لكل مجموعة. سنستخدم في حالتنا هنا المعرِّف 1 لمجموعة العُقد المفصولة، و المعرِّف 2 لمجموعة عُقد الكتابة، والمعرِّف 3 لمجموعة عُقد القراءة، والمعرِّف 4 لمجموعة عُقد الكتابة الاحتياطية. ولتطبيق هذه المعرّفات، سنقوم بإنشاء صف بهذه المتغيرات (المجموعات المضيفة) وقيمها الموافقة (المعرّفات الرقمية) في جدول الإعدادات mysql_group_replication_hostgroups، وذلك بتنفيذ الأمر التالي في موجه أوامر الواجهة التخاطبية لإدارة ProxySQL:

ProxySQLAdmin> LOAD INSERT INTO mysql_group_replication_hostgroups (writer_hostgroup، backup_writer_hostgroup، reader_hostgroup، offline_hostgroup، active، max_writers، writer_is_also_reader، max_transactions_behind) VALUES (2، 4، 3، 1، 1، 3، 1، 100);

تم في الأمر السابق إعداد متغيرات إضافية ضمن صف هي:

• active: وهو المتغيّر الخاص بتمكين ProxySQL من مراقبة المجموعات المضيفة، حيث تم إسناده بالقيمة 1 (تمكين).
• max_writers: وهو المتغير الخاص بتحديد العدد الأعظمي من عُقد الكتابة، حيث تم إسناده بالقيمة 3 كون مجموعة التناسخ المتماثل الخاصة بنا من النوع multi-primary، أي قمنا بتعيين جميع العُقد الثلاثة كعُقد كتابة.
• writer_is_also_reader: يُستخدم لتفعيل القراءة في عُقد الكتابة. حيث تم إسناده بالقيمة 1 وذلك لإعلام ProxySQL باستخدام جميع عُقد القراءة كعُقد كتابة أيضًا.
• max_transactions_behind: يُستخدم لتحديد العدد الأعظمي من محاولات الاتصال قبل تصنيف العُقدة كعُقدة مفصولة.

ملاحظة: بما أننا نستخدم في مثالنا هنا مجموعة التناسخ المتماثل ذات العُقد الرئيسية المتعددة والتي تستطيع جميع عُقدها الكتابة إلى قاعدة البيانات، لذا سوف نوازن تحميل جميع استعلامات SQL عبر مجموعة عُقد الكتابة. أما في الأنواع الأخرى من مجموعات التناسخ المتماثل، يقوم التقسيم بين عُقد الكتابة (الرئيسية) وعُقد القراءة (الثانوية)، بتوجيه استعلامات القراءة إلى مجوعات مضيفة مختلفة عن المجموعات المضيفة الخاصة باستعلامات الكتابة، غير أن ProxySQL لا يقوم بمعملية التوجيه هذه آليًا، لذا يجب في هذه الحالة إعداد توجيه الاستعلامات باستخدام القواعد.

بما أن ProxySQL يعلم الآن طريقة توَّزع عُقد MySQL ضمن المجموعات المضيفة، لذا أصبح بمقدورنا الآن إضافة خوادم MySQL الموافقة لهذه العُقد إلى قائمة الخوادم المرتبطة بالخادم الوكيل ProxySQL. وذلك من خلال إدخال INSERT عنوان IP واسم المجموعة المضيفة الأولية لكل خادم إلى الجدول mysql_servers، والمتضمّن على لائحة بخوادم MySQL التي يستطيع ProxySQL التفاعل معها. وذلك بتنفيذ الأوامر التالية في موجه أوامر الواجهة التخاطبية لإدارة ProxySQL بعد استبدال عناوين IP الخوادم بالقيمة الحقيقية:

ProxySQLAdmin> INSERT INTO mysql_servers(hostgroup_id، hostname، port) VALUES (2، '203.0.113.1'، 3306);
ProxySQLAdmin> INSERT INTO mysql_servers(hostgroup_id، hostname، port) VALUES (2، '203.0.113.2'، 3306);
ProxySQLAdmin> INSERT INTO mysql_servers(hostgroup_id، hostname، port) VALUES (2، '203.0.113.3'، 3306);

حيث أُسنِدت القيمة 2 للمعامل hostgroup_id لجعل جميع هذه الخوادم عُقد كتابة، كما تمّ تعيين المنفذ 3306 لجميع خوادم MySQL. ولكي يأخذ هذا التحديث حيّز التنفيذ، يجب تطبيقه على طبقة وقت التشغيل ثم حفظه في طبقة القرص، وذلك بتنفيذ الأوامر التالية في موجه أوامر الواجهة التخاطبية لإدارة ProxySQL:

ProxySQLAdmin> LOAD MYSQL VARIABLES TO RUNTIME;
ProxySQLAdmin> SAVE MYSQL VARIABLES TO DISK;

سيقوم ProxySQL الآن بتوزيع عُقد MySQL الخاصة بنا ضمن المجموعات المضيفة كما هو محدد. وللتأكد من ذلك سنقوم بالاستعلام SELECT عن الجدول runtim330e_mysql_servers والذي يعرض الحالة الآنية لقائمة خوادم MySQL المرتبطة بالخادم ProxySQL، وذلك بتنفيذ الأمر التالي:

ProxySQLAdmin> LOAD MYSQL VARIABLES TO RUNTIME;

Output
+--------------+-------------+--------+
| hostgroup_id | hostname    | status |
+--------------+-------------+--------+
| 2            | 203.0.113.1 | ONLINE |
| 2            | 203.0.113.2 | ONLINE |
| 2            | 203.0.113.3 | ONLINE |
| 3            | 203.0.113.1 | ONLINE |
| 3            | 203.0.113.2 | ONLINE |
| 3            | 203.0.113.3 | ONLINE |
+--------------+-------------+--------+
6 rows in set (0.01 sec)

نلاحظ من الجدول أنه تم عرض جميع الخوادم في كل من المجموعة المضيفة ذات المعرِّف 2 والمجموعة المضيفة ذات المعرِّف 3، وهذا يدلّ على أن جميع الخوادم هي عُقد كتابة وقراءة في نفس الوقت. كما نلاحظ أن جميع الخوادم بحالة ONLINE أي أنها جميعها بحالة عمل.

لكن قبل أن نتمكن من استعمالها، يجب علينا إعداد متطلبات ولوج المستخدم إلى قاعدة البيانات MySQL في كل عُقدة.

الخطوة السادسة- إنشاء مستخدمي قاعدة البيانات MySQL

يلعب ProxySQL دور موازن تحميل، حيث يقوم المستخدمون بالاتصال بالخادم ProxySQL والذي يقوم بدوره بتمرير هذا الاتصال إلى عُقدة MySQL المختارة. هذا ويتصل ProxySQL بكل عُقدة عن طريق متطلبات الولوج التي استخدمها المستخدم للدخول إلى ProxySQL.

لنتمكن من الولوج إلى قواعد البيانات الكائنة في عُقد مجموعة التناسخ، نحتاج لإنشاء حساب مستخدم بنفس متطلبات الولوج الخاصة بالخادم ProxySQL ومنح هذا المستخدم الصلاحيات الضرورية. كما هو الحال في الخطوة الثالثة، يجب أن تُطبّق الخطوات التالية على عضو وحيد من مجموعة التناسخ المتماثل، حيث يمكننا اختيار أي عضو نريد.

ننتقل إلى موجه أوامر MySQL، ثم نُنشئ مستخدم جديد اسمه playgrounduser وكلمة سره playgrounduser، وذلك بتنفيذ الأمر التالي:

(member1)mysql> CREATE USER 'playgrounduser'@'%' IDENTIFIED BY 'playgroundpassword';

ثم نمنح هذا المستخدم صلاحيات الولوج الكاملة إلى قاعدة البيانات playground، وذلك بتنفيذ الأمر التالي في موجه أوامر MySQL:

(member1)mysql> GRANT ALL PRIVILEGES on playground.* to 'playgrounduser'@'%';

ثم نُطبِّق التعديلات، وننهي موجه أوامر MySQL كما يلي:

(member1)mysql> FLUSH PRIVILEGES;
(member1)mysql> EXIT;

للتأكّد من أنه تم إنشاء المستخدم بشكل صحيح، سنقوم باختبار قدرته على الولوج إلى قاعدة البيانات الكائنة في عُقدة MySQL بواسطة متطلبات الولوج التي تم إعدادها، وذلك بإعادة فتح موجه أوامر لينكس والدخول إلى موجه أوامر MySQL بحساب المستخدم الذي تم إنشائه، حيث سيطلب موجه الأوامر إدخال كلمة السر الخاصة بهذا المستخدم:

$ mysql -u playgrounduser -p

وبعد نجاح الدخول إلى موجه أوامر MySQL بحساب المستخدم playgrounduser، ننفذ استعلام تجريبي على قاعدة البيانات playground، وذلك كما يلي:

(member1)mysql> SHOW TABLES FROM playground;

Output
+----------------------+
| Tables_in_playground |
+----------------------+
| equipment            |
+----------------------+
1 row in set (0.00 sec)

فنلاحظ ظهور لائحة الجداول الموجودة في قاعدة البيانات، حيث تحوي على الجدول equipment الذي تم إنشائه سابقًا، مما يدل على أنه تم إنشاء المستخدم بشكل صحيح على عُقد MySQL.

نستطيع الآن إنهاء موجه أوامر MySQL بتنفيذ الأمر EXIT، لكننا سنُبقي عليه متصلًا بالخادم لاستخدامه لاحقًا في تنفيذ اختبارات الخطوة الأخيرة.

نحتاج الآن لإنشاء مستخدم موافق في خادم ProxySQL.

الخطوة السابعة- إنشاء مستخدم ProxySQL

إن آخر خطوة في الإعدادات هو سماح الاتصال بالخادم ProxySQL باستخدام حساب المستخدم playgrounduser، ومرور هذا الاتصال عبره إلى عُقد MySQL.

لتحقيق ذلك نحتاج لإعداد المتغيرات الموجودة في الجدول mysql_users والتي تحتفظ بمعلومات حساب المستخدم. وذلك بإدخال اسم المستخدم (في حالتنا playgrounduser) وكلمة مروره ومعرِّف المجموعة المضيفة الافتراضية (في حالتنا المعرّف 2 الموافق لمجموعة الكتابة) في قاعدة بيانات الإعدادات، من خلال موجه أوامر الواجهة التخاطبية لإدارة ProxySQL:

ProxySQLAdmin> INSERT INTO mysql_users(username، password، default_hostgroup) VALUES ('playgrounduser'، 'playgroundpassword'، 2);

ولكي يأخذ هذا التحديث حيّز التنفيذ، يجب تطبيقه على طبقة وقت التشغيل ثم حفظه في طبقة القرص، وذلك بتنفيذ الأوامر التالية في موجه أوامر الواجهة التخاطبية لإدارة ProxySQL:

ProxySQLAdmin> LOAD MYSQL VARIABLES TO RUNTIME;
ProxySQLAdmin> SAVE MYSQL VARIABLES TO DISK;

للتأكد من أننا قادرين على الاتصال بقاعدة بيانات عُقد MySQL باستخدام حساب المستخدم الذي تم إنشاؤه، سنقوم بفتح نافذة موجه أوامر لينكس أخرى ثم نتصل بخادم ProxySQL باستخدام قناة الاتصال SSH، مع إبقاء موجه أوامر الواجهة التخاطبية لإدارة ProxySQL لأننا سنحتاجه لاحقًا.

$ ssh sammy@your_proxysql_server_ip_1

يتنصّت ProxySQL على المنفذ 6033 للاتصالات القادمة من العملاء، لذا سنحاول الاتصال بقاعدة البيانات الحقيقية (ليس بالواجهة الإدارية) باستخدام اسم المستخدم playgrounduser وكلمة مرورهplaygroundpassword (التي سيطلبها موجه الأوامر) والمنفذ 6033:

$ mysql -u playgrounduser -p -h 127.0.0.1 -P 6033 --prompt='ProxySQLClient> '

حيث تم استبدال الموجه الافتراضي بالموجه ProxySQLClient>‎ وذلك من أجل تمييزه عن موجه الواجهة التخاطبية لإدارة ProxySQL، كونه سنستخدم كلاهما في الإعدادات النهائية.

وعند نجاح عملية الاتصال سيظهر موجه الأوامر ProxySQLClient>‎ للدلالة على أن الخادم ProxySQL قد قبل حساب المستخدم playgrounduser:

ProxySQL client prompt
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 31
Server version: 5.5.30 (ProxySQL)

Copyright (c) 2000، 2017، Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective owners.

Type 'help;' or '\h' for help.Type '\c' to clear the current input statement.

ProxySQLClient>

سنقوم بتنفيذ تعبير برمجي بسيط للتأكد من أن الخادم ProxySQL سيتصل بأحد عُقد MySQL، حيث يقوم هذا التعبير البرمجي بالاستعلام في قاعدة البيانات عن اسم المضيف الذي يعمل عليه الخادم، وتكون نتيجة تنفيذ هذا التعبير عبارة عن خرج وحيد يتضمن على اسم مضيف الخادم:

ProxySQLClient> SELECT @@hostname;
Output
+------------+
| @@hostname |
+------------+
| member1    |
+------------+
1 row in set (0.00 sec)

سيتم بناء على إعداداتنا توجيه الاستعلام من قبل الخادم ProxySQL إلى واحد من عُقد MySQL الثلاث المُسندة للمجموعة المضيفة الخاصة بالكتابة. وتكون نتيجة الاستعلام member1 والذي هو أحد مضيفات عُقد MySQL.

وهكذا تم الانتهاء من الإعدادات التي تسمح بعمل ProxySQL كموازن تحميل للاتصالات بين عُقد MySQL.

سنقوم في الخطوة الثامنة والأخيرة بالتحقق من قدرة ProxySQL على تنفيذ التعابير البرمجية الخاصة بالقراءة والكتابة في قاعدة البيانات حتى في حال فشل أحد العُقد.

الخطوة الثامنة- التحقق من إعدادات ProxySQL

لقد تحققنا سابقًا من أن الاتصال يعمل بشكل سليم بين ProxySQL وعُقد MySQL، لذا ستكون الاختبارات الأخيرة للتأكُّد من أن أذونات قاعدة البيانات تسمح بتنفيذ التعابير البرمجية الخاصة بالقراءة والكتابة القادمة من الخادم ProxySQL، والتأكُّد من أن هذه التعابير قابلة للتنفيذ حتى في حال فشل بعض عُقد المجموعة.

سنقوم بتنفيذ تعبير القراءة SELECT في موجه أوامر عميل ProxySQL للتحقق من قدرتنا على قراءة البيانات من قاعدة البيانات playground، وذلك كما يلي:

ProxySQLClient> SELECT * FROM playground.equipment;
Output
+----+--------+-------+--------+
| id | type   | quant | color  |
+----+--------+-------+--------+
|  3 | slide  |     2 | blue   |
| 10 | swing  |    10 | yellow |
| 17 | seesaw |     3 | green  |
+----+--------+-------+--------+
3 rows in set (0.00 sec)

نلاحظ أن خرج تنفيذ التعبير السابق عبارة عن جدول equipment يحوي على ثلاث مكونات، والذي تم إنشاؤه سابقاً في قاعدة البيانات playground، وهذا يدل على نجاح عملية القراءة من قاعدة بيانات MySQL عن طريق الخادم ProxySQL.

والآن سنحاول الكتابة في قاعدة البيانات، وذلك بتنفيذ تعبير الكتابة INSERT لكتابة بيانات جديدة في الجدول equipment الموجود ضمن قاعدة البيانات playground، وذلك كما يلي:

ProxySQLClient> INSERT INTO playground.equipment (type، quant، color) VALUES ("drill"، 5، "red");

وللتحقق من أنه تم كتابة البيانات السابقة في قاعدة البيانات playground، نعيد تنفيذ تعبير القراءة SELECT السابق كما يلي:

ProxySQLClient> SELECT * FROM playground.equipment;

Output
+----+--------+-------+--------+
| id | type   | quant | color  |
+----+--------+-------+--------+
|  3 | slide  |     2 | blue   |
| 10 | swing  |    10 | yellow |
| 17 | seesaw |     3 | green  |
| 24 | drill  |     5 | red    |
+----+--------+-------+--------+
4 rows in set (0.00 sec)

نلاحظ من الخرج ظهور مكون جديد في الجدول equipment الموجود في قاعدة البيانات، وهذا يدل على نجاح عملية الكتابة في قاعدة بيانات MySQL عن طريق الخادم ProxySQL.

وهكذا تأكّدنا من قدرة الخادم ProxySQL على استخدام قاعدة البيانات بشكل كامل، لكن ماذا يحصل في حال فشل أحد خوادم MySQL.

سنقوم الآن بمحاكاة فشل أحد خوادم MySQL، وذلك بإيقاف عملية mysql من موجه أوامر أحد خوادم MySQL كما يلي:

$ systemctl stop mysql

بعد توقف أحد خوادم MySQL، سنحاول ثانيةً الاستعلام عن البيانات الموجودة في الجدول equipment من موجه أوامر عميل ProxySQL كما يلي:

ProxySQLClient> SELECT * FROM playground.equipment;

فنلاحظ أن الخرج لم يتغير، وهذا يدل على أن ProxySQL لاحظ فشل أحد عُقد MySQL، وقام بالانتقال إلى عُقدة أخرى سليمة لتنفيذ عملية الاستعلام عن البيانات الموجودة في قاعدة بيانات MySQL.

هذا ويمكننا التحقق من ذلك عن طريق الاستعلام عن الجدول runtime_mysql_servers من موجه أوامر الواجهة التخاطبية لإدارة ProxySQL، كما ورد في الخطوة الخامسة:

ProxySQLAdmin> SELECT hostgroup_id، hostname، status FROM runtime_mysql_servers;

Output
+--------------+-------------+---------+
| hostgroup_id | hostname    | status  |
+--------------+-------------+---------+
| 1            | 203.0.113.1 | SHUNNED |
| 2            | 203.0.113.2 | ONLINE  |
| 2            | 203.0.113.3 | ONLINE  |
| 3            | 203.0.113.2 | ONLINE  |
| 3            | 203.0.113.3 | ONLINE  |
+--------------+-------------+---------+
6 rows in set (0.01 sec)

نلاحظ من الخرج أن عُقدة MySQL التي قمنا بإيقافها قد أصبحت SHUNNED، وهذا يعني أنها غير قابلة للوصول مؤقتًا، لذا سيتم توزيع كل النقل بين العُقدتين المتبقيتين بحالة عمل.

سيقوم ProxySQL بمراقبة حالة العُقدة المتوقفة عن العمل بشكل مستمر، ويعيدها للحالة online في حال عادت للعمل، أو يعتبرها مفصولة offline في حال تجاوزت زمن الانتظار المحدد في الخطوة الخامسة (في المتغير max_transactions_behind).

سنقوم الآن باختبار مراقبة ProxySQL لحالة عُقد MySQL، وذلك بإعادة تشغيل خادم MySQL المتوقّف، وبالتالي إعادة العُقدة المتوقّفة إلى العمل ثانيةً:

$ systemctl start mysql

ثم ننتظر قليلًا ونعيد الاستعلام عن الجدول runtime_mysql_servers من موجه أوامر الواجهة التخاطبية لإدارة ProxySQL:

ProxySQLAdmin> SELECT hostgroup_id، hostname، status FROM runtime_mysql_servers;

Output
+--------------+-------------+--------+
| hostgroup_id | hostname    | status |
+--------------+-------------+--------+
| 2            | 203.0.113.1 | ONLINE |
| 2            | 203.0.113.2 | ONLINE |
| 2            | 203.0.113.3 | ONLINE |
| 3            | 203.0.113.1 | ONLINE |
| 3            | 203.0.113.2 | ONLINE |
| 3            | 203.0.113.3 | ONLINE |
+--------------+-------------+--------+
6 rows in set (0.01 sec)

نلاحظ من الخرج أن ProxySQL لاحظ فورًا عودة العُقدة للعمل، وقام بإعادة حالتها إلى ONLINE. يمكنك إعادة هذا الاختبار على عُقدة أخرى (أو اثنين منها)، والتحقق من أن وجود عُقدة واحدة على الأقل بحالة عمل، كافي لاستخدام قاعدة البيانات بحرية في عمليتي القراءة والكتابة.

ملخص

تم في هذه المقالة شرح طريقة إعداد الخادم الوكيل ProxySQL لموازنة تحميل استعلامات SQL عبر العديد من عُقد MySQL القادرة على الكتابة ضمن بنية مجموعة التناسخ المتماثل ذات العُقد الرئيسية المتعددة. حيث يساعد هذا النوع من الإعدادات على تحسين أداء قواعد البيانات الكثيرة الاستخدام، عن طريق توزيع الحمل عبر العديد من الخوادم، كما توفر قابلية الانتقال الآلي إلى الخوادم المتاحة عند فشل أحدها.

لم يتم في هذه المقالة تغطية إلاّ البنية القائمة على عُقدة واحدة كمثال. إلا أن إمكانيات ProxySQL الجبارة في الحفاظ على الاستعلامات والتوجيه وتحليل الأداء تعمل كذلك الأمر على الكثير من البنى الأخرى. يمكنك الاضطلاع على المزيد حول ميزات ProxySQL وطريقة استخدامه في حل العديد من مشاكل إدارة قواعد البيانات في مدونة ProxySQL الرسمية.

ترجمة المقال بتصرف للمقال How to Use ProxySQL as a Load Balancer for MySQL on Ubuntu 16.04 لصاحبته Mateusz Papiernik

إنَّ osquery عبارة عن أداة أمنية مفتوحة المصدر دورها تحويل نظام تشغيل بأكمله إلى قاعدة بيانات ضخمة، مع جداول يُمكنك استعلامها باستعمال جمل مُشابهة لجمل SQL. يُمكنك بهذه الاستعلامات مراقبة صلاحيّة الملفات، الاطلاع على حالة وإعدادات الجدار الناري، القيام بتدقيقات أمنية على الخادوم الهدف وغير ذلك.

التطبيق عابر للمنصّات مع دعم للنسخ الجديدة من macOS، Windows 10، CentOS وUbuntu. تُوصف رسميا بأنّها "إطار عمل يحتوي على مجموعة من الأدوات المبنية على SQL لمراقبة نظام التّشغيل والحصول على الإحصائيات" وقد كانت بداية الإطار من شركة Facebook.

يُمكنك باستخدام osquery تنفيذ أوامر مثل select * from logged_in_users ;‎ على الخادوم الخاصّ بك لتحصل على نتيجة مُشابهة لما يلي:

+-----------+----------+-------+------------------+------------+------+
| type      | user     | tty   | host             | time       | pid  |
+-----------+----------+-------+------------------+------------+------+
| login     | LOGIN    | ttyS0 |                  | 1483580429 | 1546 |
| login     | LOGIN    | tty1  |                  | 1483580429 | 1549 |
| user      | root     | pts/0 | 24.27.68.82      | 1483580584 | 1752 |
| user      | sammy    | pts/1 | 11.11.11.11      | 1483580770 | 4057 |
| boot_time | reboot   | ~     | 4.4.0-57-generic | 1483580419 | 0    |
| runlevel  | runlevel | ~     | 4.4.0-57-generic | 1483580426 | 53   |
+-----------+----------+-------+------------------+------------+------+

إن سرَّك ما سبق، فسيُعجبك استعمال osquery كأداة أمنية لمُراقبة النظام واستكشاف الوصول غير المُصرّح له على خادومك الخاصّ.

يُوفّر تنصيب osquery ما يلي من المكونات:

• osqueryi: صدفة osquery التفاعليّة، للقيام باستعلامات ظرفيّة.
• osqueryd: عفريت (daemon) لتوقيت وتشغيل الاستعلامات في الخلفيّة.
• osqueryctl: سكربت مُساعد لاختبار نشرِِ (deployment) أو إعدادِِ لـosquery. يُمكن أن يُستعمَل كذلك عوضا عن مُدير خدمات نظام التّشغيل لتشغيل/إيقاف/إعادة تشغيل osqueryd.

أداتا osqueryi و osqueryd مُستقلّتان عن بعضهما. إذ لا يحتاجان إلى التواصل بينهما. ولا يتواصلان، ويُمكنك استعمال الواحدة دون الأخرى. معظم المعامِلات والخيارات المطلوبة لتشغيل كل واحدة هي نفسها بين الأداتين، ويُمكنك تشغيل osqueryi باستعمال ملفّ إعدادات osqueryd لتتمكّن من تشخيص البيئة دون الحاجة إلى انتقال دائم بين أسطر الأوامر.

سنقوم في هذا الدّرس بما يلي:

• تثبيت osquery

• ضبط الأجزاء التي يحتاج إليها osquery في نظام التّشغيل (مثل Rsyslog)، وذلك لكي يعمل osquery بشكل صحيح.

• ضبط ملفّ إعدادات يُمكن أن يُستعمل من طرف كل من osqueryi و osqueryd.

• العمل مع حِزمات (packs) osquery، وهي عبارة عن مجموعات من الاستعلامات المسبوقَةِ التّعريف يُمكنك إضافتها إلى المُؤقّت (schedule).
• تنفيذ استعلامات ظرفيّة باستعمال osqueryi للبحث عن مشاكل أمنيّة.
• تشغيل العفريت لكي يقوم بتنفيذ الاستعلامات آليّا.

السّجلات المُولَّدة من طرف العفريت osqueryd مُراد بها أن تُنقَل إلى نقاط نهاية (endpoints) خارجيّة تحتاج إلى خبرات إضافيّة لضبطها واستعمالها بشكل صحيح. لن يُغطيّ هذا الدّرس هذا الإعداد، لكنّك ستتعلّم كيفيّة ضبط وتشغيل العفريت وحفظ النتائج محليّا.

المُتطلّبات

لمُتابعة هذا الدّرس، ستحتاج إلى ما يلي:

• خادوم Ubuntu 16.04 معد بإتباع الخطوات المتواجدة في هذا الدّرس ومستخدم إداري بامتيازات sudo غير المستخدم الجذر وجدار ناري.

يجب عليك كذلك أن تمتلك فهما بسيطا لأساسيّات SQL ومعرفة أوليّة حول تأمين نظام لينكس .

الخطوة الأولى: تثبيت osquery على الخادوم

يُمكنك تنصيب osquery عبر تجميعه من الشيفرة المصدرية، أو عبر استعمال مدير الحزم. وبما أنّ المستودع الرسمي لـUbuntu لا يحتوي على حزمة تنصيب، فسيتوجب عليك إضافة المستودع الرسمي لـosquery إلى النظام.

أضف أولًا المفتاح العمومي للمُستودع:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1484120AC4E9F8A1A577AEEE97A80C63C9D8B80B

ثمّ أضف المُستودع:

sudo add-apt-repository "deb [arch=amd64] https://osquery-packages.s3.amazonaws.com/xenial xenial main"

حدّث قاعدة بيانات الحزم:

sudo apt-get update

وأخيرا، نصّب osquery:

sudo apt-get install osquery

افتراضيّا، لا يُمكن اعتبار osquery مُفيدا للغاية، إذ لا يُعتبر تطبيقا يُمكنك تنصيبه والاستفادة من كامل مزاياه مُباشرة. سواء رغبت باستعمال الصدفة التفاعليّة (interactive shell) أو العفريت، سيتوجّب عليك تمرير بعض المُعاملات والخيارات، إما عبر سطر الأوامر أو عبر ملفّ إعدادات. لعرض المُعاملات والخيارات المتوفّرة للعفريت، اكتب ما يلي:

osqueryd --help

سيحتوي المُخرج على عشرات المعاملات لسطر الأوامر وخيارات الضّبط. ما يلي جزء من المُخرج عند تجربة الأمر في الخادوم التجريبي الذي استعمِل من أجل هذا المقال:

osquery 2.1.2, your OS as a high-performance relational database
Usage: osqueryd [OPTION]... 

osquery command line flags:

    --flagfile PATH                           Line-delimited file of additional flags
    --config_check                            Check the format of an osquery config and exit
    --config_dump                             Dump the contents of the configuration
    --config_path VALUE                       Path to JSON config file
    --config_plugin VALUE                     Config plugin name
    --config_tls_endpoint VALUE               TLS/HTTPS endpoint for config retrieval
    --config_tls_max_attempts VALUE           Number of attempts to retry a TLS config/enroll request
    --config_tls_refresh VALUE                Optional interval in seconds to re-read configuration
    --daemonize                               Run as daemon (osqueryd only)

...

...

osquery configuration options (set by config or CLI flags):

    --audit_allow_config                      Allow the audit publisher to change auditing configuration
    --audit_allow_sockets                     Allow the audit publisher to install socket-related rules
    --audit_persist                           Attempt to retain control of audit
    --aws_access_key_id VALUE                 AWS access key ID
    --aws_firehose_period VALUE               Seconds between flushing logs to Firehose (default 10)
    --aws_firehose_stream VALUE               Name of Firehose stream for logging
    --aws_kinesis_period VALUE                Seconds between flushing logs to Kinesis (default 10)
    --aws_kinesis_random_partition_key        Enable random kinesis partition keys
    --aws_kinesis_stream VALUE                Name of Kinesis stream for logging
    --aws_profile_name VALUE                  AWS profile for authentication and region configuration
    --aws_region VALUE                        AWS region

للاطلاع على المعاملات الإضافيّة المُتوفرة للصدفة التفاعلية فقط، نفّذ ما يلي:

osqueryi --help

تشغيل osqueryi أسهل طريقة لعرض واستعلام جداول osquery المتوفرة افتراضيّا. على سبيل المثال، شغّل الصّدفة باستعمال الأمر التّالي:

osqueryi --verbose

سيضعك هذا في صدفة تفاعليّة، وستُلاحظ مُخرجا مُشابها لما يلي:

I0105 01:52:54.987584  4761 init.cpp:364] osquery initialized [version=2.1.2]
I0105 01:52:54.987808  4761 extensions.cpp:351] Could not autoload extensions: Failed reading: /etc/osquery/extensions.load
I0105 01:52:54.987944  4761 extensions.cpp:364] Could not autoload modules: Failed reading: /etc/osquery/modules.load
I0105 01:52:54.988209  4761 init.cpp:606] Error reading config: config file does not exist: /etc/osquery/osquery.conf
I0105 01:52:54.988334  4761 events.cpp:886] Error registering subscriber: socket_events: Subscriber disabled via configuration
I0105 01:52:54.993973  4763 interface.cpp:307] Extension manager service starting: /home/sammy/.osquery/shell.em
Using a virtual database. Need help, type '.help'
osquery>

من رسائل المعلومات والأخطاء أعلاه، من الواضح بأنّ بعضا من أجزاء osquery لا تعمل كما يجب . بعض الاستعلامات مثل select * from yara ;‎ لن تُرجع أي شيء، ما يعني بأنّ الجدول لا يحتوي على أية بيانات.

بعض الاستعلامات الأخرى مثل select time, severity, message from syslog ;‎ تُرجع رسالة كما يلي، ما يُوضّح بأنّنا بحاجة إلى بعض من العمل الإضافي:

W1202 15:44:48.600539  1720 virtual_table.cpp:492] Table syslog is event-based but events are disabled
W1202 15:44:48.600587  1720 virtual_table.cpp:499] Please see the table documentation: https://osquery.io/docs/#syslog

سنقوم بتعديل إعدادات الخادوم الخاصّ بنا لحل هذه المُشكلة.

اخرج من سطر أوامر osquery عبر كتابة ما يلي:

.exit

سنقوم في الفقرة التّالية بتعديل الأجزاء من نظام التّشغيل التي يحتاج إليها osquery للعمل بشكل صحيح.

الخطوة الثّانيّة: السّماح لـosquery بالوصول إلى سجلّ النّظام

سنقوم في هذه الخطوة بتعديل تطبيق syslog الخاص بنظام التشغيل لتمكين osquery من الحصول على واستعلام سجّل النّظام. وفي Ubuntu 16.04، هذا يعني تعديل ملفّ إعدادات Rsyslog. والتعديل الوحيد الذي سيتوجب عليك القيام به هو إضافة بضعة أسطر من الشيفرة إلى ملفّ الإعدادات. كبداية، افتح الملفّ ‎/etc/rsyslog.conf:

sudo nano /etc/rsyslog.conf

نحتاج إلى إضافة بضعة أسطر من الإعدادات التي ستُحدِّدُ لـRsyslog الأنبوب (pipe) الذي تجِبُ الكتابة إليه، وأيّا من مُعطيات (parameters) syslog يجب كتابتها للأنبوب. افتراضيّا، الأنبوب هو ‎/var/osquery/syslog_pipe. سيقوم osquery بعد ذلك بملء جدول syslog الخاصّ به من المعلومات المكتوبة لهذا الأنبوب.

ألحِق ما يلي من الأسطر إلى نهاية الملفّ:

template(
  name="OsqueryCsvFormat"
  type="string"
  string="%timestamp:::date-rfc3339,csv%,%hostname:::csv%,%syslogseverity:::csv%,%syslogfacility-text:::csv%,%syslogtag:::csv%,%msg:::csv%\n"
)
*.* action(type="ompipe" Pipe="/var/osquery/syslog_pipe" template="OsqueryCsvFormat")

احفظ وأغلق الملفّ. لتطبيق التغييرات، أعد تشغيل عفريت syslog:

sudo systemctl restart rsyslog

لنُنشئ الآن ملفّ إعدادات يضبط بعض الخيارات الافتراضية ويُوقِّتُ بعض الاستعلامات.

الخطوة الثّالثة: إنشاء ملفّ إعدادات osquery

إنشاء ملفّ إعدادات يُسهِّلُ من عمليّة تشغيل osqueryi.فعوضا عن تمرير عدد كبير من خيارات سطر الأوامر، يُمكن لـosqueryi قراءة هذه الخيارات من ملفّ إعدادات مُتواجد في المسار ‎/etc/osquery/osquery.conf. وبالطّبع، فملفّ الإعدادات سيكون مُتاحا للعفريت كذلك.

يحتوي ملفّ الإعدادات على الاستعلامات التي تحتاج إلى تنفيذها حسب توقيت مُعيّن. لكنّ مُعظم الاستعلامات التي يُمكنك تشغيلها متوفّرة على شكل حزمات (packs). ملفّات الحزمات مُتوفرة في المُجلّد ‎/usr/share/osquery/packs.

لا يأتي osquery مُجهّزا بملفّ إعدادات مُسبق، لكنّ هناك نموذج ملفّ إعدادات يُمكنك نسخه إلى /etc/osquery وتعديله. لكنّ ملفّ الإعدادات هذا لا يحتوي على جميع الخيارات التي تحتاج إليها لتشغيله على توزيعة لينكس مثل Ubuntu، لذا سنقوم بإنشاء ملفّنا الخاصّ.

هناك ثلاثة أقسام لملفّ الإعدادات:

• قائمة بخيارات العفريت وإعدادات المزايا. يُمكن لهذه الإعدادات أن تُقرأ كذلك من طرف osqueryi.
• قائمة استعلامات موقوتة لتُشغَّل متى ما وَجَبَ ذلك.
• قائمة حزمات لتُستعمل للتعامل مع استعلامات موقوتة أكثر تحديدا.

ما يلي قائمة من الخيارات التي سنستعملها في ملفّ الإعدادات الخاصّ بنا، ما يعنيه كلّ خيار، والقيم التي سنعيِّنها لهذه الخيارات. تكفي هذه القائمة من الخيارات لتشغيل كل من osqueryi وosqueryd على Ubuntu 16.04 وتوزيعات لينكس الأخرى.

• config_plugin: من أين نُريد osquery أن يقرأ الإعدادات الخاصّة به. بما أنّ الإعدادات تُقرأ من ملفّ على القرص افتراضيّا، فستكون القيمة filesystem.
• logger_plugin: يُحدّد هذا الخيار مكان كتابة نتائج الاستعلامات الموقوتة. سنستعمل القيمة filesystem مُجدّدا.
• logger_path: هذا هو المسار الذي يُؤدّي إلى مُجلّد السّجلات الذي ستجد به ملفّات تحتوي على المعلومات، التنبيهات والأخطاء ونتائج الاستعلامات الموقوتة. القيمة الافتراضيّة هي ‎/var/log/osquery.
• disable_logging: سنقوم بتفعيل التّسجيل عبر تحديد القيمة false لهذا الخيار.
• log_result_events: عبر تحديد القيمة true لهذا الخيار، سيُعبّر كل سطر من سجلات النّتائج عن تغيير في الحالة.
• schedule_splay_percent: في حالة تواجد عدد كبير من الاستعلامات الموقوتة في نفس المدة الزمنية، سيقوم هذا الخيار بتمديدها للحد من التأثيرات على أداء الخادوم. القيمة الافتراضيّة هي 10، وهي نسبة مئويّة.
• pidfile: المكان الذي سيُكتب فيه مُعرِّف العمليّة (process id) الخاصّ بعفريت osquery. القيمة الافتراضيّة هي ‎/var/osquery/osquery.pidfile.
• events_expiry: المُدة الزمنية بالثواني التي سيتم فيها الاحتفاظ بنتائج المُشترك في مخزن osquery. القيمة الافتراضية هي 3600.
• database_path: مسار قاعدة بيانات osquery. سنستعمل القيمة الافتراضية ‎/var/osquery/osquery.db.
• verbose: مع تفعيل التّسجيل، يُستعمل هذا الخيار لتفعيل أو تعطيل رسائل معلومات مُفصّلة. سنعيّن للخيار القيمة false.
• worker_threads: عدد السلاسل المُستعملة للتعامل مع الاستعلامات. سنترك القيمة الافتراضية 2.
• enable_monitor: تفعيل أو تعطيل مراقِب المُؤقّت. سنقوم بتفعيله، أي القيمة true.
• disable_events: يُستعمل هذا الخيار لضبط نظام osquery الخاصّ بالنّشر والاشتراك. نحتاج إلى تفعيله، أي القيمة false.
• disable_audit: يُستعمل لتعطيل استقبال الأحداث (events) من النظام الفرعي المسؤول عن التّدقيق في نظام التّشغيل. نحتاج إلى تفعيله، لذا فالقيمة التي سنستعملها هي false.
• audit_allow_config: السّماح لناشر التّدقيق بتغيير إعدادات التّدقيق. القيمة الافتراضية هي true.
• audit_allow_sockets: يقوم هذا الخيار بالسماح لناشر التّدقيق بتنصيب قواعد مُتعلّقة بالمقابس (socket). القيمة هي true.
• host_identifier: يُستعمَلُ لتعريف المُضيف الذي يُشغّل osquery. عند جمع نتائج من عدّة خوادم، فمن المُفيد التّمكن من التّعرف على الخادوم الذي جاء منه التّسجيل. القيمة تكون إمّا hostname أو uuid. القيمة الافتراضية التي سنعتمد عليها هي hostname.
• enable_syslog: يجب أن تكون قيمة هذا الخيار true ليتمكّن osquery من الحصول على معلومات syslog.
• schedule_default_interval: عند عدم توفير مُدّة لاستعلام موقوت، استعمِل هذه القيمة. سنُعيّن لهذا الخيار القيمَة 3600 ثانيّة.

سبق لك وأن تعرّفت على كيفيّة عرض جميع مُعاملات سطر الأوامر وخيارات الضّبط المتوفّرة لكل من osqueryi و osqueryd، لكنّ الخيارات أعلاه كافيّة لتشغيل osquery على هذا الخادوم. أنشئ وافتح ملفّ الإعدادات باستخدام الأمر التّالي:

sudo nano /etc/osquery/osquery.conf

يعتمد ملفّ الإعدادات على صيغة JSON. انسخ ما يلي إلى الملفّ:

{
  "options": {
    "config_plugin": "filesystem",
    "logger_plugin": "filesystem",
    "logger_path": "/var/log/osquery",
    "disable_logging": "false",
    "log_result_events": "true",
    "schedule_splay_percent": "10",
    "pidfile": "/var/osquery/osquery.pidfile",
    "events_expiry": "3600",
    "database_path": "/var/osquery/osquery.db",
    "verbose": "false",
    "worker_threads": "2",
    "enable_monitor": "true",
    "disable_events": "false",
    "disable_audit": "false",
    "audit_allow_config": "true",
    "host_identifier": "hostname",
    "enable_syslog": "true",
    "audit_allow_sockets": "true",
    "schedule_default_interval": "3600" 
  },

القسم التّالي من ملفّ الإعدادات هو قسم التوقيت. يُعرَّف كل استعلام عبر مفتاح أو اسم يجب أن يكون فريدا في الملفّ، متبوعا بالاستعلام المُراد تنفيذه والمدّة الزمنية بالثواني. سنقوم بتوقيت استعلام لينظر إلى جدول crontab كلّ 300 ثانيّة. أضف ما يلي إلى ملفّ الإعدادات:

  "schedule": {
    "crontab": {
      "query": "SELECT * FROM crontab;",
      "interval": 300
    }
  },

يُمكنك إضافة أي عدد من الاستعلامات تُريد، أبقِ فقط على الصّيغة الصحيحة لكي لا تحدث أخطاء في التدقيق. على سبيل المثال، لإضافة بضعة استعلامات أخرى، أضف ما يلي من الأسطر:

  "schedule": {
    "crontab": {
      "query": "SELECT * FROM crontab;",
      "interval": 300
    },
    "system_profile": {
      "query": "SELECT * FROM osquery_schedule;"
    }, 
    "system_info": {
      "query": "SELECT hostname, cpu_brand, physical_memory FROM system_info;",
      "interval": 3600
    }
  },

بعد الاستعلامات الموقوتة، يُمكنك إضافة استعلامات خاصّة تُدعى المُزخرفات (decorators)، وهي استعلامات تُضيف بيانات إلى بداية الاستعلامات الموقوتة الأخرى. الاستعلامات المُزخرفة التّالية ستقوم بإضافة المعرّف UUID الخاصّ بالمُضيف الذي يُشغّل osquery واسم المُستخدم في بداية كلّ استعلام موقوت.

أضف ما يلي إلى نهاية الملفّ:

  "decorators": {
    "load": [
      "SELECT uuid AS host_uuid FROM system_info;",
      "SELECT user AS username FROM logged_in_users ORDER BY time DESC LIMIT 1;"
    ]
  },

يُمكننا أخيرا توجيه osquery إلى قائمة من الحزمات التي تحتوي على استعلامات مُحدّدة. يوفّر osquery مجموعة افتراضيّة من الحزمات تجدها في المُجلّد ‎/usr/share/osquery/packs. أحد هذه الحزمات مُخصّصة لنظام macOS وبقيّتها لأنظمة لينكس. يُمكنك استعمال الحزمات من مساراتها الافتراضية، ويُمكنك كذلك نسخها إلى المُجلّد ‎/etc/osquery.

أضف الأسطر التّالية إلى الملفّ لإنهاء الإعداد:

  "packs": {
     "osquery-monitoring": "/usr/share/osquery/packs/osquery-monitoring.conf",
     "incident-response": "/usr/share/osquery/packs/incident-response.conf",
     "it-compliance": "/usr/share/osquery/packs/it-compliance.conf",
     "vuln-management": "/usr/share/osquery/packs/vuln-management.conf"
  }
}

لاحظ معقوفة الإغلاق }في الأخير، هذه المعقوفة تُوافق معقوفة الفتح في السطر الأول من بداية الملفّ.

يجب على ملفّ الإعدادات الكامل أن يبدو كما يلي:

{
  "options": {
    "config_plugin": "filesystem",
    "logger_plugin": "filesystem",
    "logger_path": "/var/log/osquery",
    "disable_logging": "false",
    "log_result_events": "true",
    "schedule_splay_percent": "10",
    "pidfile": "/var/osquery/osquery.pidfile",
    "events_expiry": "3600",
    "database_path": "/var/osquery/osquery.db",
    "verbose": "false",
    "worker_threads": "2",
    "enable_monitor": "true",
    "disable_events": "false",
    "disable_audit": "false",
    "audit_allow_config": "true",
    "host_identifier": "hostname",
    "enable_syslog": "true",
    "audit_allow_sockets": "true",
    "schedule_default_interval": "3600" 
  },
  "schedule": {
    "crontab": {
      "query": "SELECT * FROM crontab;",
      "interval": 300
    },
    "system_profile": {
      "query": "SELECT * FROM osquery_schedule;"
    }, 
    "system_info": {
      "query": "SELECT hostname, cpu_brand, physical_memory FROM system_info;",
      "interval": 3600
    }
  },
  "decorators": {
    "load": [
      "SELECT uuid AS host_uuid FROM system_info;",
      "SELECT user AS username FROM logged_in_users ORDER BY time DESC LIMIT 1;"
    ]
  },
  "packs": {
     "osquery-monitoring": "/usr/share/osquery/packs/osquery-monitoring.conf",
     "incident-response": "/usr/share/osquery/packs/incident-response.conf",
     "it-compliance": "/usr/share/osquery/packs/it-compliance.conf",
     "vuln-management": "/usr/share/osquery/packs/vuln-management.conf"
  }
}

احفظ وأغلق الملفّ ثمّ تحقّق من الإعدادات باستعمال الأمر التّالي:

sudo osqueryctl config-check

يجب على المُخرج أن يبدو كما يلي:

I0104 11:11:46.022858 24501 rocksdb.cpp:187] Opening RocksDB handle: /var/osquery/osquery.db

إن حدث خطأ ما، فسيحتوي المُخرج على موقع الخطأ لكي تتمكّن من إصلاحه.

بعد إعداد ملفّ إعدادات سليم، يُمكنك الآن الانتقال إلى إعداد حزمة osquery المطلوبة لمُراقبة صلاحيّة الملفّات.

الخطوة الرّابعة: إعداد حزمة osquery المطلوبة لمُراقبة صلاحيّة الملفّات

مُراقبة صلاحيّة وسلامة الملفات على خادومك من الأجزاء المهمّة في مُراقبة أمن النّظام. ويُوفّر لنا osquery حلّا جاهزا في هذه المسألة. الحزمات التي أضفناها في ملفّ الإعدادات في القسم السّابق عبارة عن حزمات جاهزة. سنقوم في هذا الجزء من الدرس بإضافة حزمة واحدة إضافيّة إلى القائمة، والتي ستحتوي على الاستعلام والتّعليمات التي سيتم استعمالها لمُراقبة صلاحية الملفّات. سنقوم بتسمية الملفّ fim.conf. أنشئ الملفّ وافتحه باستعمال مُحرّر النّصوص الخاصّ بك:

sudo nano /usr/share/osquery/packs/fim.conf

سنقوم بإنشاء حزمة لمراقبة أحداث الملفّات في المُجلّدات /home، /etc و‎/tmp كلّ 300 ثانيّة. الضبط الكامل للحزمة متواجد أسفله، انسخه إلى الملفّ:

{
  "queries": {
    "file_events": {
      "query": "select * from file_events;",
      "removed": false,
      "interval": 300
    }
  },
  "file_paths": {
    "homes": [
      "/root/.ssh/%%",
      "/home/%/.ssh/%%"
    ],
      "etc": [
      "/etc/%%"
    ],
      "home": [
      "/home/%%"
    ],
      "tmp": [
      "/tmp/%%"
    ]
  }
}

احفظ وأغلق الملفّ.

لجعل الملفّ الجديد وقواعده مُتوفّرة لـosquery، أضفه إلى قائمة الحزمات في نهاية الملفّ ‎/etc/osquery/osquery.conf، افتح الملفّ للتّعديل:

sudo nano /etc/osquery/osquery.conf

بعدها عدّل قسم الحزمات لتشمل الملفّ الجديد (الصّف الأول ممّا يلي):

...

"packs": {
     "fim": "/usr/share/osquery/packs/fim.conf",
     "osquery-monitoring": "/usr/share/osquery/packs/osquery-monitoring.conf",
     "incident-response": "/usr/share/osquery/packs/incident-response.conf",
     "it-compliance": "/usr/share/osquery/packs/it-compliance.conf",
     "vuln-management": "/usr/share/osquery/packs/vuln-management.conf"
  }

احفظ وأغلق الملفّ. ولتتأكد من أنّنا لم نرتكب أي خطأ في تعديل الملفّ، تحقّق مُجدّدا:

sudo osqueryctl config-check

لنبدأ الآن استعمال osqueryi لاستعلام النّظام.

الخطوة الخامسة: استعمال osqueryi لتنفيذ تدقيقات أمنية ظرفيّة

هناك العديد من الحالات التي يُفيد فيها osquery. سنقوم في هذا القسم بالقيام بمجموعة من التدقيقات الأمنية على النّظام باستعمال الصدفة التّفاعليّة osqueryi. وتذكّر بأنّنا لم نقم بتشغيل عفريت osquery بعد. وهذا من ميّزات osquery الجميلة، إذ تستطيع تنفيذ استعلامات باستعمال osqueryi حتى ولو لم يكن العفريت مُفعّلا، مع استعمال ملفّ الإعدادات الذي أعددناه لضبط البيئة أيضا.

لتشغيل osqueryi مع ملفّ الإعدادات، نفّذ ما يلي:

sudo osqueryi --config_path /etc/osquery/osquery.conf --verbose

مُلاحظة: تمرير خيار ‎--verbose إلى أمر تشغيل كلّ من osqueryi وosqueryd من أفضل الممارسات لأنّه يُظهر أية أخطاء أو تنبيهات يُمكن لها أن تُساعدك على استكشاف وحل مشاكل osquery. ويُمكن تشغيل osqueryi دون صلاحيات المُدير، لكنّك ستحتاج إلى تنفيذ الأمر بصلاحيات الجذر إن كنت ترغب في استعمال ملفّ الإعدادات الخاصّ بالعفريت.

لنبدأ بتنفيذ تدقيقات أمنية بسيطة أولا ثمّ ننتقل إلى مُستويات أعلى خطوة بخطوة. على سبيل المثال، لنطّلع على من قد سجّل دخوله إلى النّظام في الوقت الحالي غيركَ أنت؟ يُمكن ذلك عبر الاستعلام التّالي:

select * from logged_in_users ;

يجب على المُخرج أن يبدو كالتّالي:

+-----------+----------+-------+------------------+------------+------+
| type      | user     | tty   | host             | time       | pid  |
+-----------+----------+-------+------------------+------------+------+
| boot_time | reboot   | ~     | 4.4.0-57-generic | 1483580419 | 0    |
| runlevel  | runlevel | ~     | 4.4.0-57-generic | 1483580426 | 53   |
| login     | LOGIN    | ttyS0 |                  | 1483580429 | 1546 |
| login     | LOGIN    | tty1  |                  | 1483580429 | 1549 |
| user      | root     | pts/0 | 11.11.11.11      | 1483580584 | 1752 |
| user      | sammy    | pts/1 | 11.11.11.11      | 1483580770 | 4057 |
+-----------+----------+-------+------------------+------------+------+

في المُخرج أعلاه حسابا مُستخدمين حقيقين قد سجّلا دخولهما إلى الجهاز، وكلاهما من نفس عنوان IP. يجب على عنوان IP هذا أن يكون معروفا. إن لم يكن كذلك، فسيتوجب عليك البحث عن مصدر تسجيل الدخول المثير للشبهات.

يُخبرنا الاستعلام السّابق من قد سجّل دخوله في الوقت الحاليّ، لكن ماذا عن تسجيلات الدخول السّابقة؟ يُمكنك معرفة ذلك عبر استعلام الجدول last كما يلي:

select * from last ;

لا يُشير المُخرج إلى أي شيء غير اعتيادي، ما يعني بأنّه لم يُسجّل أي أحد غيرنا دخوله إلى الجهاز مُؤخّرا:

+----------+-------+------+------+------------+------------------+
| username | tty   | pid  | type | time       | host             |
+----------+-------+------+------+------------+------------------+
| reboot   | ~     | 0    | 2    | 1483580419 | 4.4.0-57-generic |
| runlevel | ~     | 53   | 1    | 1483580426 | 4.4.0-57-generic |
|          | ttyS0 | 1546 | 5    | 1483580429 |                  |
| LOGIN    | ttyS0 | 1546 | 6    | 1483580429 |                  |
|          | tty1  | 1549 | 5    | 1483580429 |                  |
| LOGIN    | tty1  | 1549 | 6    | 1483580429 |                  |
| root     | pts/0 | 1752 | 7    | 1483580584 | 11.11.11.11      |
| sammy    | pts/1 | 4057 | 7    | 1483580770 | 11.11.11.11      |
+----------+-------+------+------+------------+------------------+

هل تم ضبط وتفعيل الجدار النّاري؟ هل لا يزال الجدار النّاري قيد التّشغيل؟ إن كنت في شك من أمرك، فنفّذ الاستعلام التّالي:

select * from iptables ;

إن لم تحصل على أي مُخرج، فهذا يعني بأنّ جدار IPTables النّاري لم يُضبَط. إن كان الخادوم مُتصلا بالأنترنت فهذا ليس جيّدا، لذا من المُفضّل أن تُعدّ الجدار النّاري الخاصّ بك.

يُمكنك تعديل الاستعلام السّابق وتنفيذه لترشيح أعمدة مُحدّدة كما يلي:

select chain, policy, src_ip, dst_ip from iptables ;

يجب على الاستعلام أن يمنحك مُخرجا مُشابها لما يلي. ابحث عن أي مصدر مُثير للشبهات وعناوين IP الوجهة (destination IP addresses) التي لم تقم بضبطها:

+---------+--------+---------+-----------+
| chain   | policy | src_ip  | dst_ip    |
+---------+--------+---------+-----------+
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| INPUT   | ACCEPT | 0.0.0.0 | 127.0.0.0 |
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| FORWARD | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| FORWARD | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| OUTPUT  | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| OUTPUT  | ACCEPT | 0.0.0.0 | 0.0.0.0   |
+---------+--------+---------+-----------+

ما نوع العمليّات الموقوتة في crontab؟ هل قُمت بتوقيتها بنفسك؟ سيُساعدك الاستعلام التّالي على اكتشاف البرمجيات الخبيثة التي تمّ توقيتها لتعمل في فترات زمنية مُعيّنة:

select command, path from crontab ;

يجب على المُخرج أن يكون على الشّكل التّالي. إن بدت أية أوامر مُثيرة للشبهات، فهذا يعني بأنّها تحتاج إلى تحقيق إضافي:

+----------------------------------------------------------------------------------------------------------------------------------------+--------------------------------+
| command                                                                                                                                | path                           |
+----------------------------------------------------------------------------------------------------------------------------------------+--------------------------------+
| root cd / && run-parts --report /etc/cron.hourly                                                                                       | /etc/crontab                   |
| root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )                                                       | /etc/crontab                   |
| root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )                                                      | /etc/crontab                   |
| root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )                                                     | /etc/crontab                   |
| root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi | /etc/cron.d/mdadm              |
| root test -x /etc/cron.daily/popularity-contest && /etc/cron.daily/popularity-contest --crond                                          | /etc/cron.d/popularity-contest |
+----------------------------------------------------------------------------------------------------------------------------------------+--------------------------------+

هل هناك من ملفّات على النّظام مع خاصيّة setuid مُفعّلة؟ هناك بضعة من هذه الأنواع من الملفّات على أي خادوم يعمل بـUbuntu 16.04، لكن أي من هذه هي؟ وهل هناك من ملفات لا يجب عليها أن تتواجد في النظام؟ يُمكن لإجابات هذه الأسئلة أن تُساعدك على اكتشاف ثنائيّات بأبواب خلفيّة (backdoored binaries). نفّذ الاستعلام التّالي بين الفينة والأخرى وقارن النتائج مع نتائج أقدم لتتمكن من اكتشاف أية إضافات أو تغييرات غير مرغوب فيها:

select * from suid_bin ;

مقطع من المُخرج يبدو كما يلي:

+-------------------------------+----------+-----------+-------------+
| path                          | username | groupname | permissions |
+-------------------------------+----------+-----------+-------------+
| /bin/ping6                    | root     | root      | S           |
| /bin/su                       | root     | root      | S           |
| /bin/mount                    | root     | root      | S           |
| /bin/umount                   | root     | root      | S           |
| /bin/fusermount               | root     | root      | S           |
| /bin/ntfs-3g                  | root     | root      | S           |
| /bin/ping                     | root     | root      | S           |
| /sbin/mount.ntfs-3g           | root     | root      | S           |
| /sbin/mount.ntfs              | root     | root      | S           |
| /sbin/unix_chkpwd             | root     | shadow    | G           |
| /sbin/pam_extrausers_chkpwd   | root     | shadow    | G           |
| /usr/bin/chage                | root     | shadow    | G           |
| /usr/bin/locate               | root     | mlocate   | G           |
| /usr/bin/chfn                 | root     | root      | S           |
| /usr/bin/chsh                 | root     | root      | S           |
| /usr/bin/newuidmap            | root     | root      | S           |
| /usr/bin/write                | root     | tty       | G           |
| /usr/bin/mlocate              | root     | mlocate   | G           |
| /usr/bin/at                   | daemon   | daemon    | SG          |
| /usr/bin/sg                   | root     | root      | S           |

لعرض قائمة بوحدات النواة المُحمَّلة (loaded kernel modules)، نفّذ الاستعلام التّالي:

select name, used_by, status from kernel_modules where status="Live" ;

هذا استعلام آخر يجب تنفيذه بين الحين والآخر لمُقارنة مُخرجه مع نتائج أقدم للتحقق ممّا إذا كان هناك تغيير ما أو لا.

عرض قائمة بجميع المنافذ المُنصتة (listening ports) من أحد الطرق الأخرى التي يُمكنك بها إيجاد أبواب خلفيّة على الخادوم. للقيام بذلك، نفّذ الأمر التّالي:

select * from listening_ports ;

يجب على المُخرج أن يكون كالتّالي على خادوم جديد مع SSH وحدها تعمل على المنفذ 22:

+-------+------+----------+--------+---------+
| pid   | port | protocol | family | address |
+-------+------+----------+--------+---------+
| 1686  | 22   | 6        | 2      | 0.0.0.0 |
| 1686  | 22   | 6        | 10     | ::      |
| 25356 | 0    | 0        | 0      |         |
+-------+------+----------+--------+---------+

إن كان المُخرج يحتوي على منافذ تعلم بأنّ الخادوم يُنصت منها، فلا داعي للقلق، أمّا إن كانت هناك منافذ أخرى مفتوحة، فسيتوجّب عليك التّحقيق في ماهيّة هذه المنافذ.

لعرض نشاطات الملفّات على الخادوم، نفّذ الاستعلام التّالي:

select target_path, action, uid from file_events ;

يعرض المُخرج جميع نشاطات الملفات الحديثة على الخادوم، إضافة إلى مُعرّف المُستخدم المسؤول عن النّشاط:

+---------------------------+---------+------+
| target_path               | action  | uid  |
+---------------------------+---------+------+
| /home/sammy/..bashrc.swp  | CREATED | 1000 |
| /home/sammy/..bashrc.swp  | UPDATED | 1000 |
| /home/sammy/..bashrc.swp  | UPDATED | 1000 |
| /home/sammy/.bashrc       | UPDATED | 1000 |
| /home/sammy/..bashrc.swp  | DELETED | 1000 |
| /home/sammy/..bashrc.swp  | CREATED | 1000 |
| /home/sammy/..bashrc.swp  | UPDATED | 1000 |
| /home/sammy/..bashrc.swp  | UPDATED | 1000 |
| /home/sammy/.bashrc       | UPDATED | 1000 |
| /home/sammy/.bashrc       | UPDATED | 1000 |
| /home/sammy/.bashrc       | UPDATED | 1000 |
| /home/sammy/..bashrc.swp  | DELETED |      |
| /etc/test_file.txt        | DELETED |      |
| /home/sammy/.bash_history | UPDATED | 1000 |
| /home/sammy/.bash_history | UPDATED | 1000 |
| /etc/secret_file.md       | CREATED | 0    |
| /etc/secret_file.md       | UPDATED | 0    |
| /etc/secret_file.md       | UPDATED | 0    |
+---------------------------+---------+------+

هناك العديد من الاستعلامات مُشابهة لما سبق يُمكنك بها أن تحصل على فكرة حول مشاكل أمنية مُحتملة.

إن لم تكن مُتأكدا من مُخطّط (schema) جدول ما، يُمكنك استعمال الأمر التّالي لمعرفة مُخطّط الجدول:

.schema name-of-table

مع إبدال name-of-table باسم الجدول. ويُمكنك كذلك عرض قائمة بالجداول المُتوفرة بالأمر:

.tables

هناك العديد من الأمثلة الأخرى في الحزمات التي تأتي مع osquery، وقد صُمِّم العديد منها ليعمل بشكل دوري من طرف osqueryd. سنتعرّف في القسم التّالي على كيفيّة تشغيل العفريت لتنفيذ هذه الاستعلامات.

##الخطوة السّادسة: تشغيل osqueryd يسمح العفريت osqueryd بتنفيذ الاستعلامات في فترات زمنيّة مُحدّدة. ما يشمل كلّا من الاستعلامات التي ضبطناها في الخطوة الرّابعة، الاستعلامات المتواجدة في الحزمات التي أعددناها في تلك الخطوة، وحزمة FIM التي أعددناها في الخطوة الخامسة كذلك. إن لم تطّلع على الحزمات بعد، فهذا وقت مُناسب لإلقاء نظرة على مُحتويات ‎/usr/share/osquery/packs. تُكتَب النتائج المُولَّدة من طرف osqueryd إلى ملفّ باسم osqueryd.results.log في مُجلّد ‎/var/log/osquery. هذا الملفّ غير موجود افتراضيّا. ولا يتم إنشاؤه إلا بعد تشغيل العفريت وبدء توليد النّتائج من طرفه.

يُمكنك تشغيل osqueryd إما بأداة systemctl أو osqueryctl. كلاهما يؤدي نفس المُهمّة، لذا لا يهم أيّ واحد منهما تستعمل. سيتحقّق osqueryd من تواجد ملفّ إعدادات عند تشغيله، وسيُنبّهك إن لم يجد واحدا. سيبقى مُشتغلا دون ملفّ إعدادات، إلا أن ذلك لن يكون ذا فائدة تُذكر.

وبما أنّه قد سبق وأن أعددنا ملفّ إعدادات، فكل ما تحتاج إليه هو تشغيل العفريت:

sudo systemctl start osqueryd

أو يُمكن كتابة ما يلي:

sudo osqueryctl start

بعد بضعة دقائق من تشغيل العفريت، من المُفترض أن يزداد حجم الملفّ ‎/var/log/osquery/osqueryd.results.log. يُمكنك أن ترى ذلك بنفسك عبر تنفيذ الأمر التّالي مرارا وتكرارا:

ls -lh /var/log/osquery/osqueryd.results.log

ازدياد حجم الملفّ يدل على أن نتائج الاستعلامات الموقوتة تُكتَب على القرص. لا يمتلك osquery للأسف نظام تنبيهات مثل OSSEC، ما يعني بأنّك لن تستطيع رؤية نتائج الاستعلامات الموقوتة إلا عبر عرض ملفّ النتائج. ويُمكنك القيام بذلك عبر الأمر tail الذي سيقوم بعرض آخر 10 أسطر من الملفّ على الشّاشة بشكل مُستمر:

sudo tail -f /var/log/osquery/osqueryd.results.log

اضغط على CTRL+C لإيقاف العرض المُستمرّ للسّجل.

قد ترغب على المدى البعيد بنقل نتائج الاستعلامات إلى منصّة تحليل خارجيّة يُمكنك العمل معها. بعض الخيارات مفتوحة المصدر تشمل كلّا من Doorman، Zentral و ElasticSearch.

ختاما

يعد osquery أداة قويّة مُفيدة لتشغيل استعلامات ظرفية وموقوتة باستعمال جمل SQL المألوفة. osqueryi هو المكون الذي يُمكّنك من تشغيل استعلامات سريعة، أما osqueryd فهو للاستعلامات الموقوتة. لتحليل نتائج الاستعلامات الموقوتة، سيتوجب عليك نقلها إلى منصّة خارجية لتحليل السّجلات. يُمكنك الحصول على المزيد من المعلومات حول osquery على osquery.io.

ترجمة -بتصرّف- للمقال How To Monitor Your System Security with osquery on Ubuntu 16.04 لصاحبه finid.

دعنا نفترض أنَّك تكتب سلسلة من البرامج التعليمية لـ Blender وأنك تستخدم PrintScreen لأخذ لقطات الشاشة. يمنحك هذا دليلًا مليئًا بالصور الضخمة غير المُحسَّنة للتحميل إلى صفحة ويب وعرضها. آخر شيء تريد القيام به هو تغيير حجمها يدويًا. انت محظوظ! باستخدام خيار تغيير الحجم ‎-resize يمكنك بسرعة وسهولة تغيير حجم هذه الصور إلى حجم يمكن التحكم فيه.

ضع كل الصور التي تريد توسيع نطاقها في مجلد وانتقل إلى موقع الدليل عبر سطر الأوامر. ثم أدخل الأمر التالي:

mogrify -resize 960x528 *.png

يقوم هذا الأمر بتغيير حجم جميع ملفات png. في الدليل إلى حجم 960 بكسل في 528 بكسل. ربَّما الارتفاع ليس بنفس أهمية العرض. يمكنك ببساطة كتابة الأمر السابق على النحو التالي:

mogrify -resize 960 *.png

سيؤدي هذا إلى تغيير حجم جميع صورك إلى 960 بكسل، وسيتمُّ تغيير الارتفاع وفقًا لذلك، محافظًا على نسبة العرض إلى الارتفاع. ربما لديك الطول والعرض الذي تريده، لكنك ترغب في الحفاظ على نسبة العرض إلى الارتفاع. يمكنك إدخال الأمر على النحو التالي:

mogrify -resize 960x528! *.png

سيؤدِّي ذلك إلى توسيع نطاق صورك إلى 960 × 528 بكسل متى كان ذلك ممكناً، لكنَّه سيحافظ على نسبة العرض إلى الارتفاع لتلك الصور التي لن يتم تكبيرها إلى هذه الأبعاد بالضبط.

ترجمة -وبتصرّف- للمقال ImageMagick Tutorial: How To Batch Resize Images on the Command Line لصاحبه Jared

نشرح في هذا الفيديو مفهوم المالك والأذونات على الملفات في نظام لينكس، وكيفية قراء الأذونات وتفاصيلها والأوامر اللازمة لإدارتها.

• لعرض المستخدمين في النظام: cat /etc/passwd
• لعرض المجموعات في النظام: cat /etc/group
• لعرض الملفات مع كامل تفاصيلها: ls -l
• لتغيير ملكية أحد المجلدات أو الملفات: chown -R USER:GROUP $FILE
• لتغيير أدونات أحد المجلدات أو الملفات: chmod -R +rwx $FILES

يمكنك الاطلاع على الصورة الآتية للاستزادة.

قسم لينكس في أكاديمية حسوب غني بالمقالات المفيدة عن التعامل مع النظام.

دعنا نفترض أنك تكتب سلسلة من البرامج التعليمية على Blender وأنك تستخدم مفتاح PrintScreen لالتقاط لقطات الشاشة. إنَّ مفتاح PrintScreen رائع، لكنه يمسك بكل شيء. ربَّما لا تريد أن يظهر تطبيقك في كل صورة. وربما لا تريد تحرير عشرات الصور يدويًا. أنت محظوظ! لدى برنامج ImageMagick وسيلة سهلة لاستخدام وظيفة الاقتصاص للصور التي يمكنك تنفيذها بسرعة وسهولة من سطر الأوامر.

إذا لم تكن قد قمت بالفعل بتثبيت البرنامج، فاحصل على ImageMagick بالطريقة السهلة:

sudo apt-get install imagemagick

ضع كل الصور التي تريد اقتصاصها في مجلد وانتقل إليه عبر سطر الأوامر. في المثال الذي أستخدمه هنا، أرغب في قطع البيكسلات السفلية البالغ عددها 25 بكسل من سلسلة صور png. نفِّذْ الأمر التالي للقيام بذلك:

mogrify -format png -gravity south -chop 0x25 *.png

الرايات التي استعملناها مع الأمر هي:

• ‎:-format png ينص الخيار بإخراج الملف بصيغة png.
• ‎:-gravity south ينصُّ الخيار ببدء الاقتصاص من أسفل الصورة.
• ‎:-chop 0x25 ينصُّ الخيار بقصَّ 25 بكسلًا من الارتفاع.
• ‎*.png: ينصُّ الخيار بتطبيق جميع ما سبق على أي ملف ذو اللاحقة png.

أدناه ملفي الأصلي:

والصورة المشذبة حديثا:

ترجمة -وبتصرّف- للمقال ImageMagick Tutorial: How To Batch Crop Images on the Command Line لصاحبه Jared

تُعرّف Node.js بأنّها منصّة JavaScript للبرمجة عامّة الأغراض تسمح للمستخدمين ببناء تطبيقات شبكيّة بسرعة. تجعل Node.js عمليّة التّطوير أكثر اتّساقًا وتكاملًا وذلك بتسخير ميّزات JavaScript في كلٍّ من الواجهة الأماميّة (front end) والواجهة الخلفيّة (backend).

سنعرض لك في هذا الدّليل كيفيّة البدء بمنصة Node.js على نظام خادم أبونتو 18.04.

المتطلبات

يفترض هذا الدّليل أنك تستخدم أبونتو 18.04. قبل أن تبدأ، يجب أن يتوفّر لديك على نظامك حساب مستخدم غير جذر (non-root) ذا امتيازات sudo. يمكنك تعلُّم كيفيّة القيام بهذا من خلال اتّباع خطوات دليل إعداد الخادم الابتدائي لنظام أبونتو 18.04.

تثبيت إصدار التوزيعة المستقرة (Distro-Stable) في أبونتو

يتضمّن أبونتو 18.04 في مستودعاته الافتراضيّة إصدارًا من Node.js يُمكن استخدامه للحصول على تجربة مُتّسقة على عدّة أنظمة. حتى كتابة هذا الدّليل، فإن الإصدار المتوفّر في المستودعات هو 8.10.0. هذا الإصدار ليس الأحدث، لكنّه مُستقّرٌ وكافٍ لإجراء تجارب سريعةٍ مع اللغة.

للحصول على هذا الإصدار، يمكنك استخدام مدير الحزمة apt. قم بتحديث فهرس الحزمة المحليّة لديك بكتابة الأمر التالي:

sudo apt update

قم بتثبيت Node.js من المستودعات:

sudo apt install nodejs

إذا لبّت الحزمة الموجودة في المستودعات حاجتك، فهذا كل ما تحتاج القيام به لإعداد Node.js. في معظم الحالات، قد ترغب في تثبيت مدير الحزم الخاصّ بالمنصة (Node.js package manager أو npm). يمكنك القيام بذلك بكتابة التّالي:

sudo apt install npm

سيسمح ما سبق لك بتثبيت وحدات وحزم لاستخدامها مع Node.js.

نظرًا لوجود تعارضٍ مع حزمة أخرى، يُدعى الملفّ التّنفيذيّ المُحمّل من مستودعات أبونتو nodejs بدلًا من node. تذكّر هذا الأمر جيدًا عند تشغيلك للبرمجيّة.

للتّحقق من إصدار Node.js المُثبّت لديك بعد هذه الخطوات الأوليّة، قم بكتابة الأمر التّالي:

nodejs -v

بعد أن تتأكد من إصدار Node.js المُثبّت لديك من مستودعات أبونتو، تستطيع حينها أن تقرر إذا ما كنت تريد العمل مع إصدارات مُغايرة، أرشفة حزم مختلفة أو مدير إصدار آخر. سنناقش هذه العناصر فيما يلي كما سنعرض سُبلًا أكثر مرونةً وحداثةً للتّثبيت.

التّثبيت باستخدام أرشيف الحزم الشّخصي PPA

للحصول على إصداراتٍ أحدث من Node.js، يمكنك إضافة أرشيف الحزم الشّخصي المُدار من قبل NodeSource. يحتوي هذا الأرشيف على إصدارات أحدث مما هو موجود في مستودعات أبونتو الرّسميّة. كما سيسمح لك بالاختيار من باقة إصدارات أوسع تتراوح بين Node.js v8.x (المدعومة حتى نهاية العام الجاري)، الإصدار ذي الدّعم الطّويل الأمد الحالي Node.js v10.x، والإصدار الحالي Node.js v12.x.

قم أوّلًا بتثبيت PPA لتستطيع الوصول إلى محتوياته. من الدّليل الرّئيسيّ لديك، استخدم curl لجلب البرنامج النّصي لتّثبيت الإصدار المُفضّل لديك، لا تنسَ استبدال ‎10.x بالسّلسلة الخاصة بالإصدار الذي تريده إن لم يكن هو المطلوب:

cd ~
curl -sL https://deb.nodesource.com/setup_10.x -o nodesource_setup.sh

يمكنك فحص محتويات هذا البرنامج النّصّي من خلال فتحه باستخدامnano أو باستخدام محرّرك النّصّي المُفضّل:

nano nodesource_setup.sh

قم بتنفيذ البرنامج النّصّي ضمن امتيازات sudo:

sudo bash nodesource_setup.sh

سيُضاف أرشيف الحزم الشخصي هذا إلى إعداداتك وستُحدّث خابية الحزم المحليّة لديك تلقائيًّا. بعد تنفيذ نص التثبيت من Nodesource، يمكنك تثبيت حزمة Node.js بنفس الطريقة المذكورة أعلاه:

sudo apt install nodejs

للتّحقق من إصدار Node.js المُثبّت لديك بعد هذه الخطوات الأوليّة، قم بكتابة الأمر التّالي:

nodejs -v

وسترى خرجًا مشابهًا للتّالي:

v10.14.0

nvmتتضمّن حزمة nodejs الملف الثنائي nodejs بالإضافة إلى npm. لذلك، فلست بحاجةٍ لتثبيت npm على حدة.

يستخدم npm ملف إعدادات في دليلك الرّئيسيّ لتعقّب التّحديثات. سيُنشَئ هذا الملف عند المرّة الأولى التي تقوم بها بتشغيل npm. قم بتنفيذ هذا الأمر للتّحقق أنّ npm مُثبّتة بالفعل وإنشاء ملف الإعدادت هذا:

npm -v

وسترى خرجًا مشابهًا للتّالي:

6.4.1

لكي يتسنّى لبعض حزم npm أن تعمل (تتطلّب تلك الحزم على سبيل المثال ترجمة الشّيفرة البرمجيّة من المصدر)، أنت بحاجةٍ لتثبيت حزمة build-essential:

sudo apt install build-essential

أصبح لديك الآن الأدوات الضّروريّة للعمل مع حزم npm التي تتطلّب ترجمة الشيفرة البرمجيّة من المصدر.

التثبيت باستخدام NVM

كبديلٍ عن تثبيت Node.js باستخدام apt، يمكنك استخدام أداة nvm، هذه الأداة هي مدير إصدارات المنصة (Node.js Version Manager). عوضًا عن العمل على مستوى نظام التشغيل، تعمل nvm على مستوى مجلد مستقلٍّ داخل مجلدك الرّئيسيّ. هذا يعني أنّ بإمكانك تثبيت عدّة إصدارات قائمة بحدّ ذاتها من Node.js ضمن المجلد الرّئيسيّ دون التّأثير على النّظام بأكمله.

يسمح لك ضبط بيئتك باستخدام nvm بالوصول إلى أحدث إصدارات Node.js وفي الوقت ذاته الإبقاء على الإصدارات السابقة وإدارتها بفعاليّة. إنّها وسيلة مختلفةٌ كليًّا عن apt كما أنّ إصدارات Node.js التي تديرها باستخدام nvm مميّزة عن تلك التي تديرها باستخدام apt.

يمكنك استخدام curl لتنزيل البرنامج النّصي الخاص بتثبيت nvm من صفحة المشروع على GitHub. لاحظ أنّ رقم الإصدار قد يختلف عمّا هو موجود في هذا الدّليل:

curl -sL https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh -o install_nvm.sh

تفحّص البرنامج النّصي للتّثبيت باستخدامnano:

nano install_nvm.sh

قم بتنفيذ البرنامج النّصي باستخدام bash:

bash install_nvm.sh

سيثبِّت الأمر السّابق البرمجيّة في مجلد فرعيّ من المجلد الرئيسي ضمن الملف ‎~/.nvm كما سيضيف الأسطر اللازمة إلى الملف ‎~/.profile لاستخدام الملف المذكور.

لتستطيع النّفاذ إلى قدرات nvm الوظيفيّة، ستحتاج إما لتسجيل الخروج ومن ثمّ تسجيل الدّخول مرة أخرى أو إعادة تحميل الملف ~/.profile باستخدام الأمر source وذلك حتى تدرك الجلسة الحاليّة التّغييرات التي أحدثتها.

source ~/.profile

الآن بعد أن قمت بتثبيت nvm، يمكنك تثبيت إصدارات معزولةٍ من Node.js. للحصول على معلومات حول إصدارات Node.js المتوفّرة، نفذ الأمر التّالي:

nvm ls-remote

سيظهر لك خرجٌ مشابهٌ لما يلي:

...
        v10.15.3   (Latest LTS: Dubnium)
        v11.0.0
        v11.1.0
        v11.2.0
        v11.3.0
        v11.4.0
        v11.5.0
        v11.6.0
        v11.7.0
        v11.8.0
        v11.9.0
        v11.10.0
        v11.10.1
        v11.11.0
        v11.12.0
        v11.13.0
        v11.14.0
        v11.15.0
        v12.0.0
        v12.1.0
        v12.2.0

كما ترى، الإصدار ذو الدّعم الطّويل الأمد الحالي عند كتابة هذا الدّليل هو v10.15.3، يمكنك تثبيته من خلال الأمر التّالي:

nvm install 10.15.3

عادة ما تُبدّل nvm لاستخدام الإصدار الأحدث. يمكنك أن تحدّد الإصدار الذي قمت بتحميله توًّا لتستخدمه nvm من خلال الأمر:

nvm use 10.15.3

عندما تُثبّت Node.js باستخدام nvm، فإنّ الملف التنفيذي يحمل الاسم node. يمكنك معرفة الإصدار الذي تستخدمه الصّدفة (Shell) لديك من خلال الأمر التّالي:

node -v

وسيكون الخرج:

v10.15.3

إذا كان لديك أكثر من إصدار Node.js، يمكنك معاينتها بكتابة الأمر:

nvm ls

إذا رغبت بتحديد أحد هذه الإصدارات كافتراضيّ، نفذ الأمر التالي:

nvm alias default 10.15.3

سيتم اختيار هذا الإصدار تلقائيًّا عند الشّروع في جلسةٍ جديدة. يمكنك أيضًا الإشارة إلى الإصدار باسم بديل (Alias) كما يلي:

nvm use default

يقوم كل إصدار من Node.js بتعقب حزمه ويتوفر لديه npm خاصّ لإدارة هذه الحزم.

يمكنك استخدام npm لتثبيت حزم إلى دليل مشروع Node.js وهو ‎./node_modules. استخدم الصّياغة التّالية لتثبيت الوحدة express:

npm install express

إذا أردت تثبيت الوحدة على نحوٍ عموميٍّ (Global) لجعلها متاحةً للمشاريع الأخرى باستخدام الإصدار نفسه من Node.js، يمكنك إضافة الراية ‎-g:

npm install -g express

سيقوم الأمر السّابق بتثبيت الحزمة في:

~/.nvm/versions/node/node_version/lib/node_modules/express

سيسمح لك تثبيت الوحدة على نحوٍ عموميٍّ بتنفيذ أوامر من سطر الأوامر، لكن سيكون عليك ربط الحزمة في النّطاق الخاص بك لطلبها من داخل برنامج ما:

npm link express

يمكنك الاطلاع على المزيد من الخيارات التي يوفرها nvm بكتابة الأمر التالي:

nvm help

حذف منصة Node.js

يمكنك حذف Node.js باستخدام apt أو apt تبعًا للإصدار الذي تريد حذفه. لحذف إصدار التّوزيعة المستقرّة، عليك أن تستخدم الأداة apt على مستوى النّظام.

لحذف إصدار التّوزيعة المستقرّة، استخدم الأمر الآتي:

sudo apt remove nodejs

سيحذف هذا الأمرُ الحزمةَ ويحتفظ بملفات الإعدادات. قد تكون هذه الملفات ذات فائدة لك إذا ما رغبت بتثبيت الحزمة مرة أخرى بعد مرور الوقت. إن لم ترد الاحتفاظ بملف الإعدادات لاستخدامه لاحقًا، قم بتنفيذ الأمر التالي:

sudo apt purge nodejs

سيقوم هذا الأمر بإلغاء تثبيت الحزمة وحذف ملفات الإعدادات المرافقة لها.

كخطوة أخيرة، يمكنك حذف جميع الحزم غير المستخدمة والتي تم تثبيتها تلقائيًّا مع الحزم التي قمت بحذفها توًّا باستخدام الأمر التالي:

sudo apt autoremove

لإلغاء تثبيت إصدار قمت بتفعليه باستخدام nvm ، تحقق أولًّا فيما إذا كان الإصدار المعنيّ هو الإصدار النشط حاليًّا:

nvm current

إذا لم يكن الإصدار المستهدف هو الإصدار النّشط حاليًّا، نفذ الأمر التّالي:

nvm uninstall node_version

سيقوم هذا الأمر بإلغاء تثبيت الإصدار المختار من Node.js.

أمّا إذا كان الإصدار الذي ترغب بحذفه هو الإصدار النشط، عليك أولًا إلغاء تفعيل nvm لتمكين التّغييرات التي ستقوم بإجرائها:

nvm deactivate

يمكنك الآن إلغاء تثبيت الإصدار الحالي باستخدام أمر uninstall المستخدم أعلاه والذي سيقوم بحذف جميع الملفات المرافقة للإصدار المعني من Node.js ما عدا الملفات المخبّأة والتي يمكن استخدامها لاحقًا لإعادة التّثبيت.

الخاتمة

هناك بالفعل العديد من الطّرق للبدء باستخدام Node.js على خادم أبونتو 18.04. عادةً ما تملي الظروف أيًّا من الطرق المذكورة أعلاه هي الأفضل. وفي حين أنّ استخدام الإصدار الموجود في مستودع أبونتو هو الخيار الأسهل، يُقدّم استخدام nvm خيارات ومرونةً أكثر.

ترجمة -وبتصرف- للمقال How To Install Node.js on Ubuntu 18.04 لصاحبيه Brennen Bearnes و Kathleen Juell

نحتاج إلى كلٍّ من جافا (Java) وآلة جافا الوهميّة (Java Virtual Machine) لتشغيل العديد من البرمجيّات مثل Tomcat، و Jetty، و Glassfish، و Cassandra، و Jenkins.

سنتعلم في هذا الدّليل كيفية تثبيت إصدارات مختلفة من (Java Runtime Environment (JRE و (Java Developer Kit (JDK باستخدام apt. سنثبِّت OpenJDK بالإضافة إلى الحزم الرّسميّة من موقع Oracle، سنختار بعدئذٍ الإصدار الذي تريد استخدامه لمشروعك. ستستطيع عند الانتهاء من استخدام JDK لتطوير البرمجيّات أو استخدام Java Runtime لتنفيذ البرمجيّات.

المتطلبات

ستحتاج لمتابعة هذا الدّليل إلى:

• خادم أبنتو 18.04 سبق إعداده باتّباع خطوات دليل إعداد الخادم الابتدائي، وهذا يتضمّن سحاب مستخدم غير جذر (non-root) ذا امتيازات sudo وجدارًا ناريًّا.

تثبيت JRE/JDK الافتراضيّة

الخيار الأسهل عند تثبيت جافا هو استخدام الإصدارات المُضمّنة مع أبنتو. يتضمّن أوبنتو 18.04 افتراضيًّا Open JDK والتي هي تنويعة مفتوحة المصدر من JRE و JDK.

لتثبيت الإصدار 11 من OpenJDK، قُم أوّلًا بتحديث فهرس الحزمة:

    sudo apt update

تحقّق بعد ذلك إذا ما كانت جافا مُثبّتةً بالفعل:

    java -version

إذا لم تكن جافا مُثبّتةً، سترى الخرج التّالي:

Output
Command 'java' not found, but can be installed with:

apt install default-jre
apt install openjdk-11-jre-headless
apt install openjdk-8-jre-headless
apt install openjdk-9-jre-headless

نفّذ الأمر التّالي لتثبيت OpenJDK:

sudo apt install default-jre

سيُثبّت هذا الأمر بيئة التشغيل الآني لجافا (JRE اختصار للعبارة Java Runtime Environment) التي ستسمح لك بتشغيل جميع برمجيّات جافا تقريبًا.

تحقّق من التّثبيت باستخدام:

java -version

سترى الخرج التّالي:

Output
openjdk version "11.0.3" 2019-04-16
OpenJDK Runtime Environment (build 11.0.3+7-Ubuntu-1ubuntu218.04.1)
OpenJDK 64-Bit Server VM (build 11.0.3+7-Ubuntu-1ubuntu218.04.1, mixed mode, sharing)

قد تحتاج إلى أدوات جافا التطويرية (JDK اختصار للعبارة Java Development Kit) إلى جانب JRE إذا أردت ترجمة وتشغيل بعض البرمجيّات المعتمدة على جافا. لتثبيت JDK، قم بتنفيذ الأمر التّالي:

sudo apt install default-jdk

سيثبت هذا الأمر JRE أيضًا.

تحقّق من تثبيت JDK من خلال تفحّص إصدار مصرِّف جافا javac:

javac -version

سترى الخرج التّالي:

javac 11.0.3

سنعمل الآن على تحديد الإصدار الذي نريد تثبيته من OpenJDK.

تثبيت إصدارات محددة من OpenJDK

بالإضافة إلى تثبيت حزمة OpenJDK الافتراضية، يمكنك أيضًا تثبيت إصدارات مختلفة من OpenJDK. ستتعلّم في هذا الدّليل تثبيت الإصدارين الحاليّ والسّابق من الإصدارات ذات الدّعم الطّويل الأمد.

OpenJDK 8

جافا 8 هي إحدى الإصدارات ذات الدّعم الطّويل الأمد من Oracle. على الرّغم من انتهاء صيانتها العامّة منذ كانون الثّاني من هذا العام إلّا أن التّحديثات العامّة للإصدارات الشّخصيّة وإصدارات التّطوير مستمرّة حتى كانون الأوّل 2020. لتثبيت OpenJDK 8، قم بتنفيذ الأمر التّالي:

    sudo apt install openjdk-8-jdk

تحقّق من التّثبيت من خلال الأمر:

    java -version

سيظهر لك الخرج التّالي:

Output
openjdk version "1.8.0_162"
OpenJDK Runtime Environment (build 1.8.0_162-8u162-b12-1-b12)
OpenJDK 64-Bit Server VM (build 25.162-b12, mixed mode)

من المُمكن تثبيت JRE فقط من خلال تنفيذ الأمر sudo apt install openjdk-8-jre.

OpenJDK 11

جافا 11 هي الإصدار الحاليّ ذي الدّعم الدّعم الطّويل الأمد ومن المُتوقّع أن يستمرّ دعمها حتّى العام 2022 .

لتثبيت OpenJDK 11، قم بتنفيذ الأمر التّالي:

    sudo apt install openjdk-11-jdk

لتثبيت JRE فقط، استخدم الأمر التّالي:

    sudo apt install openjdk-11-jre

سنقوم الآن بتثبيت حزم JDK و JRE الرّسميّة من Oracle.

تثبيت Oracle JDK

إذا أردت تثبيت Oracle JDK، الإصدار الرّسمي الذي توزعه Oracle، ستحتاج لإضافة مستودع حزمة جديد للإصدار الذي ترغب باستخدامه.

لتثبيت جافا 8، قم أولًا بإضافة مستودع حزمته:

    sudo add-apt-repository ppa:webupd8team/java

عند إضافة المستودع، سترى رسالةً كهذه:

Output
Oracle Java (JDK) Installer (automatically downloads and installs Oracle JDK8). There are no actuJava
 files in this PPA.

Important -> Why Oracle Java 7 And 6 Installers No Longer Work: http://www.webupd8.org/2017/06/why-oracl
e-java-7-and-6-installers-no.html

Update: Oracle Java 9 has reached end of life: http://www.oracle.com/technetwork/java/javase/downloads/j
dk9-downloads-3848520.html

The PPA supports Ubuntu 18.04, 17.10, 16.04, 14.04 and 12.04.

More info (and Ubuntu installation instructions):
- for Oracle Java 8: http://www.webupd8.org/2012/09/install-oracle-java-8-in-ubuntu-via-ppa.html

Debian installation instructions:
- Oracle Java 8: http://www.webupd8.org/2014/03/how-to-install-oracle-java-8-in-debian.html

For Oracle Java 10, see a different PPA: https://www.linuxuprising.com/2018/04/install-oracle-java-10-in-ubuntu-or.html

More info: https://launchpad.net/~webupd8team/+archive/ubuntu/java
Press [ENTER] to continue or Ctrl-c to cancel adding it.

اضغط ENTER للاستمرار ثمّ قُم بتحديث قائمة الحزم:

    sudo apt update

حالما تُحدَّث القائمة، قُم بتثبيت جافا 8:

    sudo apt install oracle-java8-installer

سيُنزّل نظامك JDK من Oracle ويطلب منك قبول اتفاقيّة التّرخيص. قُم بالموافقة على الاتفاقيّة وسيبدأ تثبيت JDK.

سننظر الآن إلى إمكانيّة اختيار إصدار جافا الذي ترغب باستخدامه.

إدارة جافا

قد يتوفّر لديك عدّة إصدارات جافا مُثبّتةٍ على خادمٍ واحد. يمكنك إعداد أيٍّ من هذه الإصدارات ليكون الافتراضي لديك أو استخدام سطر الأوامر من خلال الأمرupdate-alternatives:

    sudo update-alternatives --config java

إذا ثبَّت جميع إصدارات جافا في هذا الدّليل، سيبدو الخرج لديك كالتّالي:

Output
There are 3 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                            Priority   Status
------------------------------------------------------------
* 0            /usr/lib/jvm/java-11-openjdk-amd64/bin/java      1101      auto mode
  1            /usr/lib/jvm/java-11-openjdk-amd64/bin/java      1101      manual mode
  2            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1081      manual mode
  3            /usr/lib/jvm/java-8-oracle/jre/bin/java          1081      manual mode

اختر الرّقم الموافق لإصدار جافا الذي ترغب في استخدامه افتراضيّا، أو اضغط ENTER لترك الإعدادت على ما هي عليه.

يمكنك القيام بهذا لأوامر جافا أخرى، مثل المترجم (javac):

    sudo update-alternatives --config javac

نذكر على سبيل المثال لا الحصر من بعض الأوامر الأخرى التي يمكنك تنفيذ ما سبق عليها: keytool، Javadoc و jarsigner.

تعيين متغير البيئة JAVA_HOME

تستخدم العديد من البرامج المكتوبة باستخدام لغة جافا مُتغيّر البيئة JAVA_HOME لتحديد مسار تثبيت جافا.

لتعيين مُتغيّر البيئة هذا، حدّد أولًا أين ثُبتّت جافا. استخدم الأمر update-alternatives كما يلي:

    sudo update-alternatives --config java

سيعرض لك هذا الأمر جميع تثبيات جافا لديك مع مسار كلٍّ منها:

There are 3 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                            Priority   Status
------------------------------------------------------------
* 0            /usr/lib/jvm/java-11-openjdk-amd64/bin/java      1101      auto mode
  1            /usr/lib/jvm/java-11-openjdk-amd64/bin/java      1101      manual mode
  2            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1081      manual mode
  3            /usr/lib/jvm/java-8-oracle/jre/bin/java          1081      manual mode

Press <enter> to keep the current choice[*], or type selection number:

في حالتنا هذه، فإنّ مسارات التّثبيت هي كالتّالي:

1. OpenJDK 11 على المسار ‎/usr/lib/jvm/java-11-openjdk-amd64/bin/java.

2. OpenJDK 8 على المسار ‎/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java.

3. Oracle Java 8 على المسار ‎/usr/lib/jvm/java-8-oracle/jre/bin/java.

قُم بنسخ مسار الإصدار المفضّل لديك ثم افتح الملف ‎/etc/environment باستخدام nano أو محرّر النّصوص الذي تفضّله:

    sudo nano /etc/environment

أَضِف السطر التّالي في نهاية هذا الملف وتأكّد من استبدال المسار الملّون بالمسار الذي قمت أنت بنسخه:

JAVA_HOME="/usr/lib/jvm/java-11-openjdk-amd64/bin/"

سيضبط تعديل هذا الملف مسار JAVA_HOME لجميع المستخدمين على نظامك.

احفظ تعديلاتك على الملف وأغلق المُحرّر.

أعِد تحميل هذا الملف لتطبيق التعديلات على جلستك الحاليّة:

    source /etc/environment

تحقّق من تعيين مُتغيّر البيئة:

    echo $JAVA_HOME

سترى المسار الذي قمت بتعيينه منذ قليل:

Output
/usr/lib/jvm/java-11-openjdk-amd64/bin/

سيحتاج المستخدمون الآخرون إلى تنفيذ الأمر source /etc/environment أو تسجيل الخروج وإعادة تسجيل الدخول ليصبح هذا الضّبط نافذ المفعول.

خاتمة

قمتَ في هذا الدّليل بتثبيت عدة إصدارات من جافا وتعلّمت كيفيّة إدارة هذه الإصدارات. يمكنك الآن تثبيت برمجيات تعمل على Java مثل Tomcat، أو Jetty، أو  Glassfish، أو Cassandra، أو Jenkins.

ترجمة -وبتصرف- للمقال How To Install Java with apt on Ubuntu 18.04 لصاحبه Koen Vlaswinkel

نشرح في هذا الفيديو إدارة الملفات والمجلدات على نظام لينكس.

الأوامر المشروحة في هذا الفيديو:

• pwd لطباعة المجلد الحالي
• cd للتنقل بين المجلدات
• ls لعرض الملفات والمجلدات
• touch لإنشاء ملفات جديدة
• mkdir لإنشاء مجلدات جديدة
• mv لنقل الملفات والمجلدات
• cp لنسخ الملفات والمجلدات
• rm لحذف الملفات والمجلدات
• ln لإنشاء وصلات رمزية وصلبة

قسم لينكس في أكاديمية حسوب غني بالمقالات المفيدة التي تشرح مختلف جوانب استعمال هذا النظام.

فلنفترض أنّ لديك مقطع فيديو طويلًا تريد قطع جزء من وسطه دون أن تكلّف نفسك عناء استيراد المقطع إلى محرّر فيديو، وقطع أجزاء منه، ثم تصديره من جديد. هذه الطريقة مملّة، وعلاوةص على ذلك تغيّر ترميز (Transcoding) الفيديو لغير حاجة. توجد طريقة سهلة لقصّ مقاطع الفيديو من سطر الأوامر باستخدام برنامج avconv عن طريق تنفيذ الأمر التالي في سطر الأوامر:

avconv -i [input file] -ss [start time] -t [duration] -codec copy [output file]

سنعطي مثالًا على كيفيّة تنفيذ الأمر أعلاه. فلنفترض أنّ لدينا مقطع فيديو يبدأ بـ 42 ثانية لا نرغب فيها.

نحتاج لتعيين المعامل ‎-ss إلى القيمة 00:00:42. يقبل هذا المعطى رمزًا زمنيًّا بصيغة "ثوان:دقائق:ساعات". يخبر المعامل البرنامج أنّنا نريد الإبقاء على محتوى الفيديو الموجود بعد 42 ثانية.

ماذا لو كانت لدينا 12 ثانيّة أخرى غير مرغوب بها في آخر الفيديو؟. في هذه الحالة يمكننا استخدام المعامل ‎-t لتحديد المدّة التي نريد الاحتفاظ بها من الفيديو. يوجد إشكال بسيط هنا، فقيمة المعامل ‎-t هي مدّة زمنيّة وليست نقطة زمنيّة محدّدة، وهذه المدّة هي الطول الإجمالي للمقطع الناتج. يعني هذا أنّ ما كان يوجد عند النقطة الزمنيّة 00:00:42 سيصبح عند 00:00:00 في الملفّ الناتج عن القصّ. وبالتالي إنْ أردنا قصّ 12 ثانيّة من آخر الفيديو فسنحتاج لعمليّة حسابيّة بسيطة. توجد طريقة سهلة تتمثّل في طرح قيمة المعامل ‎-ss من النقطة الزمنيّة التي تريد التوقّف عندها، واستخدام هذه القيمة في المعامل ‎-t. إذا كنّا نريد التوقّف عند النقطة 00:04:08 فإنّ قيمة ‎-t ستكون 00:03:26.

نحصُل في النهاية على الأمر التالي:

avconv -i input.mkv -ss 00:00:42 -t 00:03:26 -codec copy output.mkv

لدينا الآن مقطع فيديو بطول 3 دقائق و26 ثانيّة.

هذه هي طريقة قصّ الفيديو باستخدام avconv نظريّا. عمليًّا، قد تحتاج لتغيير بسيط. لسبب مّا لا يُنسَخ الصوت إلى الفيديو الناتج بطريقة جيّدة، لذا قد تحتاج لإعادة ترميز الصوت. إنْ واجهت هذه المشكلة فيمكنك التغلّب عليها بسهولة باستخدام الأمر التالي:

avconv -i input.mkv -ss 00:00:42 -t 00:03:26 -c:v copy -c:a flac output.mkv

يطلُب الأمرُ من البرنامج بنسخ ترميز الفيديو من المصدر، وفي نفس الأثناء إعادة ترميز الصوت إلى flac، الذي هو ترميز يضغط الصوت بدون فقد للمعلومات.

ترجمة – بتصرّف – للمقال How to Trim Videos with the Command Line Using AVConv.

يشرح هذا المقال كيفيّة إنشاء صور متحرّكة بصيغة GIF انطلاقًا من مجموعة صور بصيغة PNG عبر سطر الأوامر على لينكس (توزيعة أوبونتو).

أدناه مثال على تجميع صور لإنشاء صورة متحرّكة تُستخدم لشدّ الانتباه.

نبدأ أوّلًا بتثبيت الأداة ImageMagick التي سنستعملها خلال هذا الدرس:

sudo apt install imagemagick

الخطوة التاليّة لتثبيت الأداة هي الانتقال إلى المجلّد الذي يحوي مجموعة الصوّر التي نريد استخدامها لإنشاء الصورة المتحرّكة. بالنسبة لهذا المثال فمسار المجلّد هوDesktop/shebang :

cd Desktop/shebang

من السهل جدًّا استخدام ImageMagick وفهمُ آليّة عمله. يوفّر ImageMagick برنامجًا يُسمّى convert، هو الذي سنستخدمه لتحويل الصور. يمكن عبر الأمر التالي إظهار صفحة التوثيق الخاصّة بالبرنامج، والتي تشرح آليّة عمله:

man convert

تُظهر صفحة التوثيق السطر التالي، والذي يوضح طريقة استخدام البرنامج:

convert [input-option] input-file [output-option] output-file

نمرّر للبرنامج convert خيّارًا للإدخال، وملفًّا مُدخلًا، ونحدّد خيّارات عمليّة التحويل وأخيرًا اسم الملفّ الناتج عن عمليّة التحويل.

نفّذ الأمر التالي في سطر الأوامر:

convert -delay 2 -loop 0 *.png -scale 480x270 shebang.gif

فلنمرّ على الأمر أعلاه خطوة خطوة.

الخيّار الأوّل هو ‎-delay. يعيّن هذا الخيّار مدّة التوقّف بين إطارات الصورة المتحرّكة، بالأجزاء المئويّة من الثانيّة. أعطيناه هنا القيمة 2 (أي جزئيْن مئويّين من ثانيّة). نحدّد بعد ذلك عدد مرات تكرار التحريك عبر الخيّار ‎-loop. نريد ألّا يتوقّف التحريك، لذا نعطي القيمة 0 للخيّار. إنْ أردنا تحريك الصورة لمرّة واحدة فقط، فستكون القيمة 1، وإنْ أردنا تحريكها مرتين فالقيمة المناسبة هي 2. نريد أن يكون مُدخَل البرنامج مجموعةً من الصوّر، لذا نستخدم حرف البدل * لإخبار برنامج convert أنّنا نريد استخدام جميع الصوّر الموجودة في مجلّد العمل التي تنتهي بـpng. لدينا صوّرPNG مُصدَّرة من برنامج Blender، وتبلغ أبعادها ‎1920 x 1080، وهو قيّاس كبير جدًّا ولا يناسب صوّر GIF المتحرّكة، فنحدّد أبعاد الملفّ الناتج عن التحويل عبر الخيّار ‎-scale لتكون الأبعاد ‎.480×270 أخيرًا، ندخل اسم الملفّ الناتج وصيغته (shebang.gif).

ترجمة – بتصرّف – للمقال How To Create Animated GIFs from a PNG Sequence with ImageMagick and the Command Line.

نشرح في هذا الفيديو جدولة المهام باستخدام cron على أنظمة لينكس، مع ذكر عدّة أمثلة عملية عليه، وطريقة تعديل ملف crontab.

قسم DevOps في أكاديمية حسوب غني بالمقالات المفيدة للتعامل مع الخوادم.

يؤمن تطبيق المفكرة Jupyter Notebook موجه أوامر تفاعلي شبيه بتطبيقات الويب، والذي يمكن استخدامه مع العديد من لغات البرمجة مثل Python و Julia و R و Haskell و Ruby، وذلك في التطبيقات الخاصة بالبيانات والإحصاء والذكاء الصناعي.
سيتم في هذه المقالة شرح طريقة تهيئة وإعداد تطبيق المفكرة Jupyter Notebook للعمل مع أكواد لغة البرمجة Python 3 محليًا أو من الخادم Ubuntu 16.04 server. إن تطبيق المفكرة Jupyter Notebook هو عبارة عن برنامج مفكرة يقوم بتوليد المستندات المتضمنة على الأكواد البرمجية والشروحات والصور والمخططات البيانية والمعادلات الرياضية، لاستخدامها في عرض وتطوير ومشاركة الأبحاث العلمية.

المتطلبات

قبل البدء يجب توفر بيئة برمجية مهيّأة محليًا (على الحاسب الشخصي) أو على الخادم Ubuntu 16.04 مع امتلاك صلاحية مدير النظام (المستخدم الجذر root) أو استخدام الأمر sudo عند تنفيذ الأوامر في موجه أوامر لينكس.

الخطوة الأولى- تنصيب تطبيق المفكرة Jupyter Notebook

سيتم استخدام أداة إدارة الحزم pip لتنصيب تطبيق المفكرة Jupyter Notebook في بيئة Python البرمجية المُنشأة مسبقًا. لكن يجب في البداية الانتقال إلى المجلدenvironments الخاص ببيئة Python البرمجية my_env المُنشأة مسبقًا وتفعيلها، وذلك بتنفيذ الأوامر التالية في موجه أوامر النظام:

sammy@ubuntu:~$  cd ~/environments 
sammy@ubuntu:~/environments$  . my_env/bin/activate
(my_env) sammy@ubuntu:~/environments$

ثم علينا التأكد من أن الأداة pip محدّثة لآخر إصدار وذلك بتنفيذ الأمر التالي:

(my_env) sammy@ubuntu:~/environments$ pip install --upgrade pip

ثم نقوم عن طريق الأداة pip بتنصيب تطبيق المفكرة Jupyter Notebook في البيئة البرمجية my_env، وذلك بتنفيذ الأمر التالي:

(my_env) sammy@ubuntu:~/environments$ pip install jupyter

وهكذا تم تنصيب تطبيق المفكرة Jupyter Notebook في البيئة البرمجية.
الخطوة التالية وهي اختيارية للذين يريدون الاتصال عبر قناة الاتصال SSH بواجهة الويب التفاعلية لتطبيق المفكرة Jupyter Notebook المنصَّب على الخادم.

الخطوة الثانية (اختيارية)- الاتصال بتطبيق المفكرة Jupyter Notebook المنصَّب على الخادم عبر قناة الاتصال SSH

سيتم في هذه الخطوة شرح طريقة الاتصال بواجهة الويب التفاعلية لتطبيق المفكرة Jupyter Notebook المنصَّب مسبقًا على الخادم، وذلك عبر قناة الاتصال SSH. حيث تؤمن قناة الاتصال SSH اتصالاً آمنًا بتطبيق المفكرة Jupyter Notebook كونه يستخدم منفذ محدد في الخادم (مثل المنفذ :8888 أو :8889 الخ).
سيتم في الفقرتين التاليتين شرح طريقة إنشاء قناة الاتصال SSH. الأولى من نظام التشغيل ماكنتوش أو لينكس، والثانية من نظام التشغيل ويندوز.

طريقة إنشاء قناة الاتصال SSH من نظام التشغيل ماكنتوش أو لينكس

سيتم في هذه الفقرة شرح طريقة إنشاء قناة اتصال SSH من نظام التشغيل ماكنتوش أو لينكس، باستخدام الأمر ssh مع مجموعة من المعاملات التي تؤمن نجاح عملية الاتصال.
يمكن إنشاء قناة اتصال SSH جديدة بتنفيذ الأمر التالي في نافذة جديدة لموجه أوامر النظام:

$ ssh -L 8888:localhost:8888 your_server_username@your_server_ip

حيث يستخدم الأمر ssh من أجل فتح اتصال SSH، في حين يستخدم العلم -L لتحديد المنفذ المعطى في المضيف المحلي (العميل) الذي سيتم توجيهه إلى المنفذ والمضيف البعيد (الخادم) المعطى، أي أن أي شيء سيعمل على المنفذ الثاني (مثلا 8888) على الخادم، سيظهر على المنفذ الأول (مثلا 8888) على العميل (الحاسب الشخصي). ويفضل تغيير رقم المنفذ 8888 إلى أي رقم آخر اختياري لتجنب وجود عملية أخرى تعمل على نفس المنفذ.
إن المُعامل your_server_username هو اسم المستخدم (مثلا sammy) الذي تم إنشاؤه مسبقًا على الخادم، والمُعامل your_server_ip هو عنوان IP للخادم (مثلا 203.0.113.0). أي يصبح الأمر السابق بعد إدخال اسم المستخدم وعنوان IP للخادم كما يلي:

$ ssh -L 8888:localhost:8888 sammy@203.0.113.0

وفي حال نجاح عملية الاتصال بالخادم وعدم حدوث أي خطأ، ينتقل موجه أوامر النظام إلى البيئة البرمجية المهيّأة مسبقًا على الخادم كما يلي:

(my_env) sammy@ubuntu:~/environments$

ثم نقوم بتشغيل تطبيق المفكرة Jupyter Notebook المنصَّب مسبقًا في بيئتنا البرمجية كما يلي:

(my_env) sammy@ubuntu:~/environments$ jupyter notebook

والآن أصبح بالإمكان التفاعل مع تطبيق المفكرة Jupyter Notebook من خلال واجهة الويب التفاعلية الخاصة به، وذلك بإدخال العنوان الالكتروني http://localhost:8888 في المتصفح، كما يجب إدخال السلسلة الرمزية token الخاصة بالتصديق عند طلبها من قبل المتصفح، أو كتابتها بعد العنوان في المتصفح.

طريقة إنشاء قناة الاتصال SSH من نظام التشغيل ويندوز عن طريق Putty

تستخدم الأداة Putty لإنشاء قناة اتصال SSH في نظام التشغيل ويندوز، لذا يجب في البداية تنصيبها، وعند فتحها تظهر واجهة الأداة كما هو موضح بالشكل التالي:

حيث يتم إدخال العنوان الإلكتروني URL للخادم أو عنوان IP ضمن حقل اسم المضيف Host Name، ثم الضغط على الخيار SSH في أسفل النافذة اليسارية من واجهة الأداة، فتظهر قائمة منسدلة من الخيارات، نختار منها الخيار Tunnels فتظهر في النافذة اليمينية مجموعة من خيارات التحكم بقناة الاتصال SSH كما هو موضح بالشكل التالي:

ثم نقوم بإدخال رقم منفذ الحاسب الشخصي المراد استخدامه لتطبيق المفكرة Jupyter Notebook (مثلًا 8888)، ضمن حقل منفذ المصدر Source port، ويفضل أن يكون رقم هذا المنفذ أكبر من 8888 لضمان عدم وجود أي تطبيق أخر يعمل على هذا المنفذ. ثم ندخل العنوان localhost:8888 في حقل الهدف Distination حيث :8888 هو رقم المنفذ الذي يعمل عليه تطبيق المفكرة Jupyter Notebook في الخادم، ثم نضغط على زر الإضافة Add، فيظهر المنفذ في قائمة المنافذ الموجَّهة Forwarded ports. وأخيرًا نضغط على زر الفتح Open من أجل الاتصال بالخادم عن طريق قناة الاتصال SSH، ثم ندخل العنوان localhost:8888 (طبعًا يجب أن يكون رقم المنفذ موافقًا لرقم المنفذ الذي تم اختياره) في متصفح الويب من أجل الاتصال بتطبيق المفكرة Jupyter Notebook العامل على الخادم، كما يجب إدخال السلسلة الرمزية token الخاصة بالتصديق عند طلبها من قبل المتصفح، أو كتابتها بعد العنوان في المتصفح.

الخطوة الثالثة- تشغيل تطبيق المفكرة Jupyter Notebook

بعد الانتهاء من تنصيب تطبيق المفكرة Jupyter Notebook، يصبح بالإمكان تشغيله من موجه أوامر النظام بتنفيذ الأمر التالي:

(my_env) sammy@ubuntu:~/environments$ jupyter notebook

فيُطبع في نافذة موجه الأوامر سجل معلومات تشغيل تطبيق المفكرة Jupyter Notebook كما يلي:

[I NotebookApp] Serving notebooks from local directory: /home/sammy
[I NotebookApp] 0 active kernels 
[I NotebookApp] The Jupyter Notebook is running at: http://localhost:8888/
[I NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
...

حيث تتضمن هذه المعلومات على رقم المنفذ الذي يعمل عليه التطبيق، وعند تشغيل التطبيق لأول مرة سيكون رقم المنفذ 8888.
يقوم المتصفح الافتراضي تلقائياً بفتح واجهة الويب التفاعلية الخاصة بتطبيق المفكرة Jupyter Notebook عند تشغيله على الحاسب الشخصي (ليس على الخادم)، وفي حال لم يتم ذلك أو تم إغلاق المتصفح، يمكن إعادة فتحه من جديد بإدخال عنوانه http://localhost:8888/ الظاهر في سجل معلومات التطبيق في المتصفح.
يتم إنهاء تطبيق المفكرة Jupyter Notebook بالضغط على المفاتيح CTRL و C ثم ضغط المفتاح y (نعم) عند السؤال عن تأكيد عملية الإنهاء، ثم ضغط المفتاح ENTER، فتُطبع رسالة تأكيد عملية إنهاء التطبيق التالية في نافذة موجه الأوامر:

[C 12:32:23.792 NotebookApp] Shutdown confirmed
[I 12:32:23.794 NotebookApp] Shutting down kernels

الخطوة الرابعة- استخدام تطبيق المفكرة Jupyter Notebook

سيتم في هذه الفقرة شرح أساسيات استخدام تطبيق المفكرة Jupyter Notebook، لكن يجب في البداية تشغيله إن لم يكن في حالة العمل، وذلك بتنفيذ الأمر التالي:

(my_env) sammy@ubuntu:~/environments$ jupyter notebook

نستطيع الآن الإتصال به والتفاعل معه من خلال واجهة الويب التفاعلية. يمتاز تطبيق المفكرة Jupyter Notebook بالقوة حيث يحتوي على الكثير من الميزات، لكن سيقتصر الشرح على بعض الميزات الأساسية التي تسمح بمباشرة العمل على هذا التطبيق.
يعرض تطبيق المفكرة Jupyter Notebook جميع الملفات والمجلدات الواقعة ضمن المسار الذي تم تشغيله منه، لذا يجب تشغيله دائمًا من مسار المشروع البرمجي الذي يتم العمل عليه.
يتم إنشاء ملف مفكرة Jupyter Notebook جديد بالضغط على خيار جديد New الموجود في الزاوية اليمينية العُلوية من واجهة الويب التفاعلية، فتظهر قائمة منسدلة نختار منها Python 3 كما هو موضح بالشكل التالي:

فيُفتح الملف الجديد المُنشأ ضمن واجهة الويب التفاعلية. نستطيع الآن كتابة وتنفيذ كود Python ضمن خليّة الكود البرمجي. كما يمكن تغيير هذه الخلية لتقبل لغة التوصيف Markdown، وذلك بالضغط على خيار الخلية Cell ثم خيار نوع الخلية Cell Type ثم خيار التوصيف Markdown من الشريط العلوي، فيصبح بالإمكان الآن استخدام هذه الخلية لكتابة الملاحظات وحتى تضمين المعادلات الرياضية المكتوبة بلغة LaTeX بعد وضعها بين الرمزين ($$)، فمثلا يمكن كتابة كود التوصيف التالي ضمن الخلية بعد تحويلها لخلية توصيف:

# Simple Equation

Let us now implement the following equation:
$$ y = x^2$$

where $x = 2$

يتم تحويل هذا الكود إلى نص بضغط المفاتيح CTRL و ENTER فنحصل على النتيجة التالية:

وهكذا نلاحظ أنه يمكن استخدام خلايا التوصيف من أجل توثيق الكود البرمجي. سنقوم الآن بإنشاء معادلة رياضية بسيطة ونطبع نتيجة تنفيذها، وذلك بالضغط على الخلية العلوية ثم الضغط على المفاتيح ALT و CTRL من أجل إنشاء خلية جديدة تحتها ثم ندخل فيها الكود التالي:

x = 2
y = x**2

print(y)

ثم نقوم بتنفيذ الكود بضغط المفاتيح CTRL و ENTER فنحصل على النتيجة التالية:

أصبح بمقدورك الآن وبعد أن تعلمت أساسيات تطبيق المفكرة Jupyter Notebook ، أن تقوم باستيراد النماذج البرمجية، وأن تستخدم هذه المفكرة كما تريد مع أي بيئة برمجية أخرى.

ملخص

أصبحت قادرا الآن على كتابة أكواد Python والملاحظات القابلة للتطوير والمشاركة، بعد أن تعلمت كيفية تنصيب وتشغيل والعمل على تطبيق المفكرة Jupyter Notebook. يمكن الحصول على مزيد من المعلومات والمساعدة حول كيفية استخدام هذه المفكرة، بالدخول إلى User Interface Tour عن طريق الخيار Help الموجود في الشريط العلوي من واجهة الويب التفاعلية.

ترجمة المقال How To Set Up Jupyter Notebook for Python 3 لصاحبته Lisa Tagliaferri

مقدمة

Node.js هي منصة لجافا سكريبت للبرمجة متعددة الأغراض والتي تسمح للمستخدمين ببناء تطبيقات الشبكة بسرعة. من خلال استخدام جافا سكريبت على كل من الواجهة الأمامية والخلفية، سيكون التطوير أكثر اتساقا وسيُصمم داخل النظام نفسه.
في هذا الدليل، ستتعلم كيفية تثبيت Node.js على خادم Debian 8. يحتوي Debian 8 على إصدار لـ Node.js في مجلداته الافتراضية، ولكن ذلك الإصدار قديم في الأغلب، سنقوم باستكشاف طريقتين لتثبيت أحدث إصدارات Node.js على نظامك.

المتطلبات الأساسية

لمتابعة هذا الدرس، ستحتاج إلى خادم Debian 8 مع مستخدم غير كامل الصلاحيات non-root user ويملك امتيازات sudo.

كيفية التثبيت باستخدام PPA

أسرع وأسهل وسيلة للحصول على أحدث إصدار من Node.js على خادمك هي بإضافة PPA (personal package archive) الخاص بـ NodeSource. سوف يشتمل على عدد أكبر من تحديثات Node.js مقارنة بمستودعات Debian الرسمية. كما أنه يتيح لك الاختيار بين Node.js v4.x (النسخة القديمة المدعومة على المدى الطويل, مدعومة حتى أبريل 2017)، v6.x (نسخة أحدث من LTS، والتي ستُدعم حتى أبريل 2018)، و Node.js v7.x (النسخة الحالية قيد التطوير).
أولا، قم بتثبيت PPA للحصول على محتوياته. تأكد من أنك في المجلد الرئيسي home directory، استخدم curl لاستخراج النص البرمجي لتثبيت الإصدار المفضل لديك، مع استبدال 6.x برقم الإصدار الصحيح:

cd ~
curl -sL https://deb.nodesource.com/setup_6.x -o nodesource_setup.sh

يمكنك فحص محتويات هذا النص البرمجي بواسطة nano (أو محرر النصوص المفضل لديك):

nano nodesource_setup.sh

وقم بتشغيل البرنامج النصي عقِب الأمر sudo:

sudo bash nodesource_setup.sh

سيتم إضافة PPA إلى إعداداتك وسوف يتم تحديث حزمتك المحلية المُخزنة تلقائيًا. بعد تشغيل برنامج التنصيب من nodesource، يمكنك تثبيت حزمة Node.js بنفس الطريقة التي اتبعتها أعلاه:

sudo apt-get install nodejs

الحزمة nodejs تحتوي رُقامة nodejs (nodejs binary ) إضافة إلى npm، لذلك لا تحتاج إلى تثبيت npm بشكل منفصل. ولكن لكي تعمل بعض حُزم npm (مثل تلك التي تتطلب ترجمة التعليمات البرمجية من المصدر)، فستحتاج إلى تثبيت الحزمة build-essential:

sudo apt-get install build-essential

كيفية التثبيت بواسطة nvm

بدل تثبيت Node.js بواسطة apt، يمكنك استعمال أداة خاصة تسمّى nvm (Node.js version manager). فباستخدام nvm، يمكنك تثبيت عدة إصدارات متكاملة من Node.js ما سيسمح لك بضبط بيئة العمل بشكل أسهل. كما ستعطيك إمكانية الوصول إلى أحدث إصدارات Node.js، ولكن ستسمح لك أيضا باستهداف الإصدارات السابقة التي قد يعتمد عليها تطبيقك.
بدايةً سوف نحتاج إلى الحصول على حزم البرمجيات من مستودعات Debian والتي ستسمح لنا ببناء الحُزم المصدرية source packages. التعليمة nvm ستستخدم تلك الأدوات لبناء المكونات الضرورية:

sudo apt-get update
sudo apt-get install build-essential libssl-dev

حالما يتم تثبيت الحُزم الضرورية، يمكنك حذف سكريبت التثبيتnvm من صفحة المشروع علىGitHub , رقم الإصدار قد يكون مختلفًا، ولكن بشكل عام، يمكنك تحميله بـ curl:

curl -sL https://raw.githubusercontent.com/creationix/nvm/v0.32.0/install.sh -o install_nvm.sh

طالع سكريبت التثبيت بواسطة nano:

nano install_nvm.sh

قم بتشغيل النص البرمجي بواسطة bash:

bash install_nvm.sh

النص البرمجي سيقوم بتثبيت البرنامج في مجلد في ~/.nvm. كما سيقوم بإضافة الأسطر اللازمة للملف ~/.profile لجعل التعليمة nvm متاحًا.
لكسب إمكانية الوصول إلى التعليمةnvm وكذلك وظائفها، ستحتاج إلى تسجيل الخروج ثم تسجيل الدخول مرة أخرى، أو يمكنك إضافة المصدر ~/.profile حتى يتم اعتبار التغييرات في الجلسةsession الحالية:

source ~/.profile

الآن وبعد تثبيت nvm، يمكنك تثبيت أحد إصدارات Node.js بشكل منفصل.
لمعرفة إصدارات Node.js المتوفرة للتثبيت، قم بكتابة:

nvm ls-remote

Output

...
         v6.8.0
         v6.8.1
         v6.9.0   (LTS: Boron)
         v6.9.1   (LTS: Boron)
         v6.9.2   (Latest LTS: Boron)
         v7.0.0
         v7.1.0
         v7.2.0

كما ترون، فأحدث إصدار في وقت كتابة هذه السطور هو v7.2.0، ولكن v6.9.2 هو آخر الإصدارات المدعومة على المدى الطويل. يمكنك تثبيته بكتابة:

nvm install 6.9.2

سوف ترى المخرجات التالية:

Computing checksum with sha256sum
Checksums matched!
Now using node v6.9.2 (npm v3.10.9)
Creating default alias: default -> 6.9.2 (-> v6.9.2)

عادة، سيتحولnvm إلى استخدام الإصدار المثبت حديثًا. لكن يمكنك أن تخبرnvm صراحة باستخدام النسخة التي حمّلناها للتو عن طريق كتابة:

nvm use 6.9.2

يمكنك مشاهدة النسخة المستخدمة حاليا عن طريق كتابة في واجهة الأوامر:

node -v

Output

v6.9.2

إن كان لديك عدة إصدارات من Node.js، يمكنك معرفة أيّ منها تم تثبيته بكتابة:

nvm ls

إذا كنت ترغب في جعل أحد هذه الإصدارات نسختك الافتراضية، يمكنك كتابة:

nvm alias default 6.9.2

هذا الإصدار سيتم اختياره تلقائيًا عند فتح جلسة عمل جديدة على المِطراف terminal. يمكنك أيضًا الإحالة إليه باستخدام الاسم default هكذا:

nvm use default

كل نسخة من Node.js ستُتابع حُزمها الخاصة بها، وسيكونnpm متاحًا لإدارتها.
يمكنك وضع حُزم تثبيت npm في المجلد ./node_modules الخاص بمشروعNode.js باستخدام الصيغة الطبيعية normal format. على سبيل المثال، بالنسبة للوحدة express:

npm install express

إذا كنت ترغب بتثبيته بشكل كلّي (جعْله متاحا للمشاريع الأخرى التي تستخدم نفس إصدار Node.js)، يمكنك إضافة العلم –g كما يلي:

npm install -g express

هذا سيثبّت الحزمة في:

~/.nvm/node_version/lib/node_modules/package_name

التثبيت الكلي سيتيح لك تشغيل التعليمات من سطر الأوامر، ولكن سيكون عليك ربط الحزمة من مجالك المحلي local sphere للوصول إليه من داخل برنامج ما:

npm link express

يمكنك معرفة المزيد حول الخيارات المتاحة لك مع nvm بكتابة:

nvm help

خلاصة

كما رأيت، هناك عدة طرق لتثبيت وتشغيل Node.js على خادم Debian 8. ظروفك ستملي عليك أيّ الطرق المذكورة أعلاه ستكون أفضل لك. وفي حين أن النسخة المحزومة packaged في مستودع Ubuntu هي الأسهل، إلّا أن طريقةnvm أكثر مرونة بالتأكيد.
ترجمة -وبتصرّف- للمقال How To Install Node.js on Debian 8 لصاحبه Brian Hogan

كتبت مؤخّرا برنامج Bash قصير لنسخ ملفّات MP3 من مفتاح USB من مُضيف شبكة (network host) إلى مُضيف شبكة آخر. تُنسَخ الملفّات إلى مجلّد خاصّ على خادوم أقوم بتشغيله لمؤسّسة تطوعيّة، ما يسمح بتشغيل وتنزيل الملفّات.

يقوم برنامجي ببضعة أمور أخرى، مثل تعديل أسماء الملفّات قبل نسخها لتكون مرتّبة تلقائيّا حسب التّاريخ على صفحة الويب. كما تحذف جميع الملفّات على مفتاح USB بعد التّأكد من اكتمال النّقل بنجاح. يأتي هذا البُريْمِج ببضعة خيارات، مثل -h لعرض المُساعدة، و -t لنمط الاختبار (test mode) وبضعة خيارات أخرى.

رغم أنّ برنامجي الصغير هذا جميل، إلّا أنّه يحتاج إلى تشغيله بالمُستخدم الجذر (root) للقيام بالعمليّات الأساسيّة. للأسف، لا تمتلك هذه المؤسّسة أشخاصا مهتمين بإدارة أنظمة الحواسيب، ما يدفعني للبحث عن أشخاص بقدرات تقنيّة متواضعة لتدريبهم على كيفيّة تسجيل الدّخول إلى الحاسوب الذي يعمل على نقل الملفّات وتشغيل هذا البرنامج. صحيح بأنّني أستطيع تشغيل البرنامج بنفسي، إلّا أنّ بضعة أسباب (كالمرض والسّفر) قد تحول دون ذلك. وحتى لو كنتُ متاحا، فبصفتي مدير نُظم كسول، أحب أن يقوم الآخرون بعملي من أجلي. لذا أكتب برامج لأتمتة (automate) هذه المهام وأستعمل Sudo لتمكين بضعة مُستخدمين من تشغيل البرامج.يتطلّب تنفيذ العديد من أوامر Linux صلاحيّات المُستخدم الجذر. هذا يحمي النظام من التخريب الخبيث أو غير المقصود.

استعمال أداة Sudo

يُمكنّ برنامج sudo مدراء النّظم ذوي صلاحيّات الجذر من تفويض المسؤوليّة لبضعة مهام أو جميعها لمستخدمين آخرين لنفس الحاسوب. كما يسمح لي بتنفيذ هذا التفويض دون توفير كلمة مرور المُستخدم الجذر، ما يوفّر مستوى عاليّا من الحماية على المُضيف.

لنفترض على سبيل المثال بأنّني أعطيت للمُستخدم ruser أحقيّة الوصول إلى برنامج Bash خاص بي باسم myprog، والذي يحتاج إلى صلاحيّات المستخدم الجذر لتنفيذ بعض من وظائفه. يقوم المستخدم ruser بتسجيل الدّخول أولا باستعمال كلمة المرور الخاصّة به، وبعدها ينفّذ الأمر التّالي لتشغيل myprog.

sudo myprog

يقوم برنامج sudo بالاطّلاع على الملفّ /etc/sudoers ويتحقّق من أنّ لـruser إذنا يُمكّنه من تشغيل myprog. إن كان الأمر كذلك، يطلب sudo من المُستخدم كلمة مروره -وليس كلمة مرور المُستخدم الجذر-، بعد إدخال كلمة المرور، يتمّ تنفيذ البرنامج. يقوم sudo كذلك بتسجيل معلومات الوصول إلى myprog مع التاريخ والوقت الذي تمّ فيه تشغيل البرنامج إضافة إلى سطر الأمر والمُستخدم الذي قام بتنفيذه. تُسجّل هذه البيانات في ملفّ /var/log/security. أجد بأنّ سجلّ الأوامر التي تم تنفيذها مفيد عند التّدريب. إذ يسمح لي هذا بالتعرّف على من قام بماذا وما إن أدخل الأمر بشكل صحيح. قمت باستخدام هذه الميّزة لتفويض الصلاحيّات لي ولمُستخدم آخر للتمكّن من تشغيل برنامج واحد؛ لكن لـsudo إمكانيّات أكبر من ذلك. إذ يسمح لمدير النظام بتفويض السُّلطَة لإدارة وظائف الشّبكة أو خدمات مُعيّنة لشخص واحد أو مجموعة من المُستخدمين الموثوقين. يُمكّن هذا من تفويض أحقيّة تشغيل هذه الوظائف ويحمي كلمة مرور المُستخدم الجذر في نفس الوقت.

ضبط ملفّ sudoers

بصفتي مدير نُظم، يُمكنني استعمال ملفّ /etc/sudoers للسماح للمستخدمين أو مجموعات من المُستخدمين بالوصول إلى أمر مُعيّن، مجموعة محدّدة من الأوامر أو جميع الأوامر. هذه المرونة هي سرّ كل من قوّة وبساطة استعمال sudo للتفويض.

بدا لي ملفّ sudoers معقّدا في البداية، لذا نسختُ وحلّلت ملفّ sudoers بالكامل من المُضيف الذي أستخدمه. على أمل أن تفهم الأساسيّات بعد قراءة هذا التّحليل. وجدت كذلك بأنّ ملفّات الإعدادات الافتراضيّة في التوزيعات المبنيّة على Red Hat تحتوي على الكثير من التّعليقات والأمثلة التي تُسهّل المأموريّة.

لا تستعمِل محرّر النصوص الاعتياديّ عند تعديل ملفّ sudoers. استعمل الأمر visudo لتطبيق التّغييرات حالما تحفظ الملفّ وتخرجُ من المُحرّر. يُمكن استعمال محرّرات أخرى عوضا عن Vi بنفس الشكل الذي نستعمل فيه visudo. لنبدأ بتحليل هذا الملفّ من البداية مع بضعة أنواع من الأسماء المُستعارة (aliases).

الأسماء المُستعارة الخاصّة بالمُضيفات Host aliases

يُستعمل جزء الأسماء المُستعارة الخاصّة بالمُضيفات لإنشاء مجموعات من المُضيفات التي يُمكن عليها استعمال الأوامر أو الأسماء المستعارة للأوامر لمنح أحقيّة الوصول. الفكرة أن يُصان (maintain) هذا الملفّ الوحيد من أجل جميع المُضيفات في المؤسّسة ويُنسخ إلى مُجلّد /etc الخاص بكل مُضيف. وبالتالي يُمكن ضبط بعض المُضيفات (مثل الخوادم) لتُشكّل مجموعة لمنح بعض المُستخدمين أحقيّة الوصول إلى أوامر مُخصّصة، مثل إمكانيّة تشغيل أو إيقاف خدمات مثل HTTPD، DNS والتشبيك (networking) أو وصل (mount) أنظمة الملفّات وما إلى ذلك.

يُمكن استعمال عناوين IP عوضا عن أسماء المُضيفات في الأسماء المُستعارة الخاصّة بالمُضيفات.

## Sudoers allows particular users to run various commands as
## the root user, without needing the root password.
##
## Examples are provided at the bottom of the file for collections
## of related commands, which can then be delegated out to particular
## users or groups.
##
## This file must be edited with the 'visudo' command.

## Host Aliases
## Groups of machines. You may prefer to use hostnames (perhaps using
## wildcards for entire domains) or IP addresses instead.
# Host_Alias     FILESERVERS = fs1, fs2
# Host_Alias     MAILSERVERS = smtp, smtp2

## User Aliases
## These aren't often necessary, as you can use regular groups
## (ie, from files, LDAP, NIS, etc) in this file - just use %groupname
## rather than USERALIAS
# User_Alias ADMINS = jsmith, mikem
User_Alias AUDIO = dboth, ruser

## Command Aliases
## These are groups of related commands...

## Networking
# Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, /sbin/dhclient, /usr/bin/net, /sbin/iptables, /usr/bin/rfcomm, /usr/bin/wvdial, /sbin/iwconfig, /sbin/mii-tool

## Installation and management of software
# Cmnd_Alias SOFTWARE = /bin/rpm, /usr/bin/up2date, /usr/bin/yum

## Services
# Cmnd_Alias SERVICES = /sbin/service, /sbin/chkconfig

## Updating the locate database
# Cmnd_Alias LOCATE = /usr/bin/updatedb

## Storage
# Cmnd_Alias STORAGE = /sbin/fdisk, /sbin/sfdisk, /sbin/parted, /sbin/partprobe, /bin/mount, /bin/umount

## Delegating permissions
# Cmnd_Alias DELEGATING = /usr/sbin/visudo, /bin/chown, /bin/chmod, /bin/chgrp

## Processes
# Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/kill, /usr/bin/killall

## Drivers
# Cmnd_Alias DRIVERS = /sbin/modprobe

# Defaults specification

#
# Refuse to run if unable to disable echo on the tty.
#
Defaults   !visiblepw

Defaults    env_reset
Defaults    env_keep =  "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS"
Defaults    env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults    env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults    env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults    env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"


Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin

## Next comes the main part: which users can run what software on
## which machines (the sudoers file can be shared between multiple
## systems).
## Syntax:
##
##      user    MACHINE=COMMANDS
##
## The COMMANDS section may have other options added to it.
##
## Allow root to run any commands anywhere
root    ALL=(ALL)       ALL

## Allows members of the 'sys' group to run networking, software,
## service management apps and more.
# %sys ALL = NETWORKING, SOFTWARE, SERVICES, STORAGE, DELEGATING, PROCESSES, LOCATE, DRIVERS

## Allows people in group wheel to run all commands
%wheel  ALL=(ALL)       ALL

## Same thing without a password
# %wheel        ALL=(ALL)       NOPASSWD: ALL

## Allows members of the users group to mount and unmount the
## cdrom as root
# %users  ALL=/sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom

## Allows members of the users group to shutdown this system
# %users  localhost=/sbin/shutdown -h now

## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d

################################################################################
# Added by David Both, 11/04/2017 to provide limited access to myprog          #
################################################################################
#
AUDIO   guest1=/usr/local/bin/myprog

الأسماء المستعارة الخاصّة بالمُستخدمين User aliases

تُعطي الأسماء المستعارة الخاصّة بالمُستخدمين إمكانيّة ترتيب المُستخدمين إلى مجموعات ذات أسماء مُستعارة للمُستخدم الجذر، بهذه الطّريقة ستتمكّن مجموعة كاملة من المستخدمين من الوصول إلى صلاحيات مدير محدّدة. هذا هو الجزء الذي أضَفْتُ فيه السّطر User_Alias AUDIO = dboth, ruser، والذي يقوم بتعيين مُستخدمَيْنِ للاسم المُستعار AUDIO. يُمكن الاعتماد على المجموعات المنشأة مُسبقا في ملفّ /etc/groups عوضا عن الأسماء المستعارة. إن كانت أحد المجموعات في هذا الملفّ تفي بالغرض، مثل مجموعة audio فيُمكنك استخدام اسم المجموعة مسبوقا بعلامة % كما يلي: %audio عند تعيين الأوامر التي ستُوفَّرُ للمجموعات في ملفّ sudoers.

الأسماء المستعارة للأوامر Command aliases

في جزء الأسماء المستعارة للأوامر، نقوم بتوفير قائمة للأوامر ذات الصّلة، مثل أوامر التّشبيك أو الأوامر التي تقوم بتنصيب التّحديثات أو حزم RPM جديدة. تُمكّن هذه الأسماء المستعارة مدير النّظام من منح تصريح للوصول إلى مجموعة من الأوامر. تم مُسبقا إعداد عدد من هذه الأسماء المستعارة في هذا الجزء، ما يجعل تفويض أحقية الوصول لنوع محدد من الأوامر أمرا سهلا.

القيم الافتراضيّة للبيئة Environment defaults

يقوم الجزء التّالي بتعيين عدد من متغيّرات البيئة (environment variables). أكثر سطر مثير للاهتمام في هذا الجزء هو السّطر !visiblepw، والذي يمنع تشغيل sudo إن كانت بيئة المُستخدم تسمح بعرض كلمة المرور. هذا إجراء وقائي لا يجب تعديله.

قسم الأوامر Command section

قسم الأوامر هو الجزء الرّئيسي في ملفّ sudoers. يمكن القيام بأي شيء ترغب به دون الحاجة إلى الأسماء المستعارة عبر إضافة خانات هنا. لكنّ الأسماء المستعارة تجعل الأمر في غاية السّهولة. يقوم هذا القسم باستخدام الأسماء المُستعارة التي تم تعريفها أعلاه لإخبار sudo من لديه الحقّ للقيام بماذا وعلى أي مُضيف. الأمثلة تشرح نفسها ما دمت تفهم القواعد (Syntax) في هذا القسم. لننظر إلى القواعد في قسم الأوامر:

ruser           ALL=(ALL) ALL 

المثال أعلاه يقول بأنّ للمُستخدم ruser صلاحيات تُمكّنه من تنفيذ أي برنامج على أي مُضيف بصفة أي مُستخدم.

هذه خانة عامّة للمُستخدم ruser. المقطع ALL الأول يدلّ على أنّ هذه القاعدة تُطبَّق على جميع المُضيفات. ALL الثّانيّة تسمح لـruser بتنفيذ الأوامر بصفة أي مُستخدم آخر. افتراضيّا، تُنفَّذُ الأوامر بصفة المُستخدم الجذر، لكنّ لـruser القدرة على انتحال صفة أي مُستخدم آخر عند استعمال الأمر sudo. المقطع ALL الأخير يعني بأنّ ruser يستطيع تنفيذ جميع الأوامر دون أية قيود. ما يمنح لـruser جميع صلاحيّات المُدير. لاحظ الخانة التي تمنح للمُستخدم root جميع صلاحيات الوصول لجميع الأوامر على جميع المُضيفات:

root    ALL=(ALL) ALL 

لتجربة هذا، قمت بتعليق (comment) السّطر أعلاه وحاولتُ تنفيذ الأمر chown بصفة المُستخدم الجذر دون sudo. تمّ تنفيذ الأمر. بعدها حاولت استخدام الأمر sudo chown، والذي فشل مع الرّسالة root غير موجود على ملفّ sudoers. سيتم الإبلاغ عن هذه الحادثة. ما يعني بأنّ المُستخدم الجذر قادر على تنفيذ أي أمر بصفته المُستخدم الجذر، لكن أي أمر سيفشل عند استعمال الأمر sudo. سيمنع هذا المُستخدمَ الجذر من تنفيذ أية أوامر بصفته مُستخدما آخر عبر الأمر sudo. لكنّ root يستطيع التحايل على هذا القيد بالعديد من الطّرق.

الشّيفرة أسفله هي ما أضفته للتحكم بأحقية الوصول إلى برنامج myprog. يقول السّطر بأنّ المستخدمين الذين ينتمون إلى المجموعة AUDIO التي تم تعريفها أعلى الملفّ لديهم أحقيّة الوصول إلى برنامج واحد فقط (myprog) على مُضيف واحد (guest1).

AUDIO   guest1=/usr/local/bin/myprog

سيُمكّن السّطر أعلاه المستخدمين المنتمين إلى مجموعة AUDIO من الوصول إلى البرنامج myprog على المُضيف guest1.

لاحظ بأنّ السّطر أعلاه لا يُحدّد سوى المُضيف الذي يُمكن عليه تنفيذ البرنامج. ولا يُحدّد بأنّ للمُستخدم حريّة تنفيذ الأمر بصفة أي مُستخدم آخر.

تجاوز كلمات المرور

يُمكنك استخدام الكلمة المفتاحيّة NOPASSWORD لتمكين المُستخدمين المنتمين إلى المجموعة AUDIO من تشغيل برنامج myprog دون الحاجة إلى إدخال كلمة المرور الخاصّة بهم كما يلي:

AUDIO   guest1=NOPASSWORD : /usr/local/bin/myprog

لم أُفعِّل هذا الخيار لبرنامجي، إذ يجب على مُستخدمي sudo التوقف والتفكير في ما يقومون به، وهذا يُساعد قليلا على ذلك. والسّطر أعلاه مُجرّد مثال توضيحيّ.

المجموعة wheel

معيار wheel المُحدّد في جزء الأوامر داخل ملفّ sudoers (كما هو موضّح أسفله) يقوم بالسماح لجميع المُستخدمين المُنتمين إلى المجموعة wheel بتنفيذ جميع الأوامر على أي مُضيف. تُعرَّف مجموعة wheel على الملفّ /etc/group، ومن الواجب إضافة المُستخدمين هناك. علامة % التي تسبق اسم المجموعة تعني بأنّ على sudo البحث عن هذه المجموعة في ملفّ /etc/group.

%wheel          ALL = (ALL) ALL 

يسمح السّطر أعلاه لجميع المُستخدمين الذين ينتمون إلى المجموعة wheel المعرّفة في ملفّ /etc/group بتشغيل جميع الأوامر على أي مُضيف.

هذه طريقة جيّدة لتفويض كامل صلاحيّات المُستخدم الجذر لعدّة مُستخدمين دون توفير كلمة المرور الخاصّة بالمُستخدم الجذر. مجرّد إضافة مُستخدم إلى مجموعة wheel يُعطيهم كامل إمكانيّات المُستخدم الجذر. يسمح هذا كذلك بمُراقبة نشاطات المُستخدمين عبر مُدخلات التّسجيلات التي يقوم sudo بإنشائها. تُضيف بعض التوزيعات (مثل توزيعة Ubuntu) مُعرّفات المُستخدمين (user ID) إلى المجموعة wheel في ملفّ /etc/group، ما يسمح لهم باستخدام sudo لتنفيذ جميع الأوامر التي تتطلّب صلاحيّات المُستخدم الجذر.

ختاما

استعملت sudo هنا لغرض محدود (تمكين مستخدم أو مُستخدمَيْن من الوصول إلى أمر واحد). تمكّنت من تحقيق هذا الغرض عبر كتابة سطرَيْن فقط (دون احتساب التّعليقات). تفويض صلاحيات تنفيذ مهام مُحدّدة لمُستخدمين لا يمتلكون إمكانيّة الوصول إلى المستخدم الجذر عمليّة بسيطة يُمكن لها اقتصاد كم جيّد من الوقت لمُدير النظم. بالإضافة إلى ميّزة تسجيل نشاطات المُستخدمين التي تُساعد على إيجاد المشاكل.

يُوفّر ملفّ sudoers كمًّا هائلًا من الإمكانيّات والخيارات. ألقِ نظرة على ملفّات man الخاصّة بـsudo وsudoers لمزيد من التّفاصيل.

ترجمة -بتصرّف- للمقال Using sudo to delegate permissions in Linux لصاحبه David Both.

تعلمنا في الدرس السابق كيفية إعداد LXD وإعداد الشبكة بالإضافة إلى إنشاء حاوية Nginx والآن لنقم بإعداد Nginx داخل الحاوية:

الخطوة 4 : تكوين حاوية Nginx

لِنتصلْ بالحاوية webserver ولنقم بإعداد خادوم الويب. اتصل بالحاوية بالأمر lxc exec الذي يأخذ اسم الحاوية وأوامر التنفيذ كمدخلات:

lxc exec webserver -- sudo --login --user ubuntu 

يشير المحرف “–” الأول إلى أن مدخلات الأمر lxc يجب أن تتوقف عندها وسيتم تمرير بقية السطر كأمر يتم تنفيذه داخل الحاوية. الأمر هو sudo --login –user Ubuntu وهو الذي سوف يوفر صدفة تسجيل الدخول للحساب ubuntu السابق الإعداد داخل الحاوية.
ملاحظة: إذا كنت بحاجة إلى الاتصال بالحاوية باعتبارك جذرًا استخدم الأمر

lxc exec webserver -- /bin/bash 

بدلًا من ذلك. بعدما تدخل إلى الحاوية ستبدو الصدفة الآن كما يلي.

ubuntu@webserver:~$

المستخدم ubuntu في الحاوية لديه صلاحيات sudo مُعَدَّة مسبقًا ويمكنه تنفيذ أوامر بصلاحيات الجذر دون المطالبة بإدخال كلمة السر. تقتصر هذه الصدفة على حدود الحاوية. أيُّ شيء تقوم بتشغيله في هذه الصدفة سيبقى في الحاوية ولا يمكن الذهاب به إلى الخادوم المضيف. لنقم بإعداد Nginx في هذه الحاوية. حدّث قائمة حزم ubuntu داخل الحاوية وثبت Nginx:

sudo apt-get update
sudo apt-get install nginx

ثم قم بتحرير صفحة الويب الافتراضية لهذا الموقع وأضف بعض الجمل التي تجعل من الواضح أن هذا الموقع يتم استضافته في الحاوية webserver .
افتح الملف :

sudo nano /var/www/html/index.nginx-debian.html

أدخل التغيير التالي على الملف:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx on LXD container webserver!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx on LXD container webserver!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

لقد قمنا بتحرير الملف في مكانين، وعلى وجه التحديد أضفنا العبارة ” on LXD container webserver”. احفظ الملف وأغلق المحرر. الآن سجل الخروج من الحاوية وعُد إلى الخادوم المضيف:

Logout

استخدم الأمر curl لاختبار أن خادوم الويب في الحاوية يعمل. ستحتاج إلى عناوين IP لحاويات الويب التي يمكنك أن تجدها بتنفيذ الأمر lxd list.

curl http://10.10.10.100/

يجب أن تكون المخرجات:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx on LXD container webserver!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx on LXD container webserver!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

خادوم الويب يعمل، ولكن لا يمكننا الوصول إليه إلا من خلال الـ IP الخاص. لِنوجِّهْ الطلبات الخارجية إلى هذه الحاوية حتى يتمكن العالم من الدخول إلى موقعنا على الويب.

الخطوة 5 : إعادة توجيه الاتصالات الواردة إلى حاوية Nginx

الجزء الأخير من اللغز هو ربط حاوية خادوم الويب بالإنترنت. Nginx مثبت في حاوية، وبشكل افتراضي لا يمكن الوصول إليه من الإنترنت. نحتاج إلى إعداد الخادوم المضيف لإعادة توجيه أيّ اتصالات قد يتلقاها من الإنترنت على المنفذ 80 إلى الحاوية webserver . للقيام بذلك سننشئ قاعدة iptables لإعادة توجيه الاتصالات. يتطلب الأمر iptables اثنين من عناوين IP: عنوان IP العام للخادوم (your_server_ip) وعنوان IP الخاص بحاوية nginx (your_webserver_container_ip) ، والذي يمكنك الحصول عليه باستخدام الأمر lxc list . نفذ هذا الأمر لإنشاء القاعدة:

PORT=80 PUBLIC_IP=your_server_ip CONTAINER_IP=your_container_ip \
sudo -E bash -c 'iptables -t nat -I PREROUTING -i eth0 -p TCP -d $PUBLIC_IP --dport $PORT -j DNAT --to-destination $CONTAINER_IP:$PORT -m comment --comment "forward to the Nginx container"'

وإليك شرح هذا الأمر:

• -t nat يعني أننا نستخدم جدول nat لترجمة العنوان.
• -I PREROUTING يعني أننا نقوم بإضافة القاعدة إلى سلسلة PREROUTING.
• -i eth0 يعني الواجهة eth0، وهي الواجهة العامة الافتراضية في Droplets.
• -p TCP يعني أننا نستخدم البروتوكول TCP.
• -d $PUBLIC_IP يحدد عنوان IP الوجهة .
• --dport $PORT : يحدد منفذ الوجهة (مثل 80 ).
• -j DNAT تعني أننا نريد إجراء قفزة إلى الوجهة NAT (DNAT).
• --to-destination $CONTAINER_IP:$PORT تعني أننا نريد الذهاب إلى عنوان IP الخاص بالحاوية المذكورة ومنفذ الوجهة.

ملاحظة: يمكنك إعادة استخدام هذا الأمر لإعداد قواعد إعادة التوجيه ببساطة عن طريق تعيين متغيرات PORT و PUBLIC_IP و CONTAINER_IP في بداية السطر.
فقط قم بتغيير القيم الملونة بالأحمر.

يمكنك الاطلاع على قواعد IPTables عن طريق تشغيل هذا الأمر:

sudo iptables -t nat -L PREROUTING 

سترى مخرجًا مماثلًا لهذا:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       tcp  --  anywhere             your_server_ip       tcp dpt:http /* forward to this container */ to:your_container_ip:80
...

اختبر الآن إمكانية الوصول إلى خادوم الويب، وذلك بالدخول إليه من جهاز الكمبيوتر المحلي باستخدام الأمر curl مثل هذا:

curl --verbose  'http://your_server_ip' 

سترى رأس صفحة الويب التي أنشأتها في الحاوية متبوعًا بمحتوياتها:

* Trying your_server_ip...
* Connected to your_server_ip (your_server_ip) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx/1.10.0 (Ubuntu)
...
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx on LXD container webserver!</title>
<style>
    body {
...

هذا يؤكد أن الطلبات ستذهب إلى الحاوية.

وأخيرًا .. لحفظ قاعدة جدار الحماية ثبت الحزمة iptables-persistent الحماية لكي يتم إعادة تطبيقها بعد إعادة التشغيل

sudo apt-get install iptables-persistent

عند تثبيت الحزمة ستتم مطالبتك بحفظ قواعد جدار الحماية الحالية. اقبل واحفظ جميع القواعد الحالية. عند إعادة تشغيل جهازك ستكون قاعدة جدار الحماية موجودة. بالإضافة إلى ذلك سيتم إعادة تشغيل خدمة Nginx في الحاوية الخاصة بك تلقائيا. الآن بعد أن قمنا بإعداد كل شيء لننظر في كيفية إزالته.

الخطوة 6 : إيقاف وإزالة الحاوية

ربما تقرر إزالة الحاوية واستبدالها. لنعرف كيف نقوم بذلك:
لإيقاف الحاوية استخدم lxc stop :

  lxc stop webserver

استخدم الأمر lxc list للتحقق من الحالة، ستكون المخرجات:

+-----------+---------+------+------+------------+-----------+
|   NAME    |  STATE  | IPV4 | IPV6 |    TYPE    | SNAPSHOTS |
+-----------+---------+------+------+------------+-----------+
| webserver | STOPPED |      |      | PERSISTENT | 0         |
+-----------+---------+------+------+------------+-----------+

لإزالة الحاوية استخدم lxc delete :

lxc delete webserver

نفذ الأمر lxc list مرة أخرى ليظهر لك أنه لا يوجد حاوية قيد التشغيل:

+------+-------+------+------+------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+-------+------+------+------+-----------+

استخدم الأمر lxc help للاطلاع على خيارات إضافية.

لإزالة قاعدة الجدار الناري التي توجه حركة المرور إلى الحاوية حدد أولا القاعدة في قائمة القواعد بهذا الأمر والذي يربط رقم سطر مع كل قاعدة:

sudo iptables -t nat -L PREROUTING --line-numbers

سترى القاعدة، مسبوقة برقم سطر، كما يلي:

Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    DNAT       tcp  --  anywhere             your_server_ip      tcp dpt:http /* forward to the Nginx container */ to:your_container_ip

استخدم رقم السطر هذا لإزالة القاعدة:

sudo iptables -t nat -D PREROUTING 1

تأكد من إلغاء القاعدة من خلال مشاهدة القواعد مرة أخرى بالأمر:

`sudo iptables -t nat -L PREROUTING --line-numbers`

سترى أنه تمت إزالة القاعدة:

Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination 

احفظ التغييرات الآن حتى لا يتم العمل بالقاعدة بعد إعادة تشغيل الخادوم:

sudo netfilter-persistent save

يمكنك الآن إنشاء حاوية أخرى مع الإعدادات الخاصة بك وإضافة قاعدة جدار حماية جديدة لإعادة توجيه حركة المرور إليها.

خلاصة

لقد قمت بإعداد موقع ويب باستخدام Nginx في حاوية LXD. يمكنك من هنا إعداد المزيد من مواقع الويب حيث يقتصر كل واحد منها على حاويته الخاصة به، ويمكنك ايضا استخدام بروكسي عكسي لتوجيه حركة المرور إلى الحاوية المناسبة. سيعلمك كيف تفعل ذلك هذا المقال: كيف تستضيف مجموعة مواقع بشكل آمن باستخدام Nginx و Php-fpm على أوبنتو 14.04

يتيح لك LXD أيضا التقاط لقطات من الحالة الكاملة للحاويات، مما يجعل من السهل إنشاء نسخ احتياطية من أجل الرجوع إليها لاحقا. وإذا قمت بتثبيت LXD على خادومين مختلفين فمن الممكن توصيل الحاويات بعضها ببعض وترحيلها بين الخوادم عبر الإنترنت.

لمعرفة المزيد عن LXD اقرأ هذه التدوينات عن LXD التي كتبها مطورو LXD
يمكنك أيضا تجربة LXD على الانترنت واتباع البرنامج التعليمي على شبكة الإنترنت للحصول على مزيد من الممارسة.

ترجمة -وبتصرّف- للمقال How to Set Up and Use LXD on Ubuntu 16.04 لصاحبه Simos Xenitellis

حاوية لينكس هي مجموعة من العمليات المعزولة عن بقية النظام من خلال استخدام ميزات أمان نواة لينكس، مثل مساحات الأسماء ومجموعات التحكم. إنها بناء مماثل للآلة الافتراضية، و لكنه أكثر خفة منها، فإن لم يكن لديك النفقات الكافية لتشغيل أنوية إضافية أو آلات افتراضية فلا تقلق من ذلك، لأنه يمكنك بسهولة إنشاء حاويات متعددة على نفس الخادوم. على سبيل المثال، تخيل أن لديك خادوم يقوم بتشغيل مواقع ويب متعددة لعملائك. في حال التثبيت التقليدي سيكون كل موقع على شبكة الانترنت مضيفًا افتراضيًا من نفس حالة خادوم apache أو Nginx. ولكن مع حاويات لينكس يمكن لكل موقع على شبكة الإنترنت أن يثبت في حاوية خاصة به مع خادوم الويب الخاص بها. باستخدام حاويات لينكس يمكنك تجميع التطبيق الخاص بك واعتمادياته في حاوية دون التأثير على بقية النظام. يتيح لك LXD إنشاء هذه الحاويات وإدارتها. يوفر LXD خدمة مراقب الأجهزة الافتراضية لإدارة دورة الحياة الكاملة للحاويات. في هذا الدرس سوف نقوم بإعداد LXD واستخدامه لتشغيل Nginx في حاوية. وستقوم بعد ذلك بتوجيه حركة المرور إلى الحاوية من أجل جعل موقع الويب ممكن الوصول إليه من الإنترنت.

المتطلبات الأساسية

لإكمال هذا الدرس ستحتاج إلى ما يلي:

1. خادوم أوبونتو 16.04 مُعَد مسبقا ، يمكنك الرجوع إلى هذه المقال لتعرف كيف تفعل ذلك: الإعداد الابتدائي لخادوم أوبنتو 14.04
2. مستخدم غير جذر يملك صلاحيات الجذر وجدار الحماية.
3. اختياريًا أضف 20 جيغا أو أكثر من مساحة التخزين ، يمكنك استخدام ذلك لتخزين كافة البيانات المتعلقة بالحاويات.

الخطوة 1 : إعداد LXD

تم تثبيت LXD بالفعل على أوبونتو، ولكن يجب أن يتم إعداده بشكل مناسب قبل أن تتمكن من استخدامه على الخادوم. يجب عليك إعداد حساب المستخدم لإدارة الحاويات، ثم إعداد نوع قاعدة التخزين لتخزين الحاويات وإعداد الشبكة. قم بتسجيل الدخول إلى الخادوم باستخدام حساب المستخدم غير الجذر. ثم أضف المستخدم إلى مجموعة LXD بحيث يمكنك استخدامه لأداء جميع مهام إدارة الحاويات:

sudo usermod --append --groups lxd Sammy

قم بتسجيل الخروج من الخادوم وتسجيل الدخول مرة أخرى لكي يتم تحديث جلسة SSH الجديدة الخاصة بك مع عضوية المجموعة الجديدة. بعد تسجيل الدخول يمكنك البدء في تهيئة LXD. الآن قم بإعداد قاعدة التخزين. قاعدة التخزين الموصى بها ل LXD هو نظام ملفات ZFS، المخزنة إما في ملف مخصص مسبقًا أو باستخدام كتلة التخزين . لاستفادة من دعم ZFS في LXD حدّث قائمة الحزم الخاصة بك ثم ثبت الحزمة zfsutils-linux :

sudo apt-get update
sudo apt-get install zfsutils-linux

يمكنك الآن إعداد LXD. ابدأ بعملية تهيئة LXD مع الأمر LXD init :

sudo lxd init

ستتم مطالبتك بتعيين تفاصيل قاعدة التخزين. بعد الانتهاء من هذا الإعداد يتوجب عليك إعداد الشبكة من أجل الحاويات.

أولاً سوف يُقترح عليك أن تختار بشأن قاعدة التخزين، وستُخَير بين أمرين: dir أو zfs . الخيار dir يخبر LXD بتخزين الحاويات في مجلدات تابعة لنظام ملفات الخادوم. وأما الخيار zfs فيستخدم نظام الملفات zfs ونظام إدارة القرص الصلب LVM. اختر zfs. باستخدام zfs نحصل على كلٍّ من كفاءة التخزين وتحسين الاستجابة. على سبيل المثال إذا أنشأنا عشرة حاويات من نفس صورة الحاوية الأولية، فإنها جميعا تستخدم من القرص مساحةَ حاوية واحدة فقط. وبعد ذلك سيتم فقط تخزين التغييرات على صورة الحاوية الأولى في قاعدة التخزين.

Name of the storage backend to use (dir or zfs) [default=zfs]: zfs

بعد اختيار zfs سيُطلَب منك إنشاء تجمع (pool) zfs جديد واسم لهذا التجمع. اختر نعم لإنشاء التجمع، وسمه ب lxd :

Create a new ZFS pool (yes/no) [default=yes]? yes
Name of the new ZFS pool [default=lxd]: lxd

ثم ستُسأل إذا كنت ترغب في استخدام عتاد التخزين الموجود:

Would you like to use an existing block device (yes/no) [default=no]

إذا أجبت بنعم فعليك أن تخبر LXD أين يجد هذا العتاد. إذا أجبت بلا فسوف يقوم LXD باستخدام ملف مخصص مسبقًا. مع هذا الخيار سوف تستخدم المساحة الفارغة على الخادوم نفسه. هناك حالتان يتبعان ذلك اعتمادًا على ما إذا كنت تريد استخدام ملف مخصص مسبقًا أو عتاد التخزين. اتبع الخطوة المناسبة لحالتك. بعد تحديد آلية التخزين ستعمل على تهيئة خيارات الشبكة من أجل حاوياتك.

الخيار 1 : استخدام التخصيص المسبق

يمكنك استخدام ملف مخصص مسبقًا إذا لم تتمكن من الوصول إلى عتاد التخزين من أجل تخزين الحاويات. اتبع هذه الخطوات لإعداد LXD لكي يستخدم ملف مخصص مسبقًا لتخزين الحاويات.
أولًا، عندما يطلب منك استخدام عتاد التخزين الموجود أجب بلا :

Would you like to use an existing block device (yes/no) [default=no]? no

بعد ذلك، سيطلب منك تحديد حجم loop device ، الذي يستدعيه الملف المخصص مسبقًا من LXD. استخدام الحجم الافتراضي المقترح للملف المخصص مسبقًا :

Size in GB of the new loop device (1GB minimum) [default=15]: 15

وكقاعدة عامة 15 جيغا هو أصغر حجم يجب عليك إنشاؤه. فأنت تريد تخصيص مساحة كافية لكي يكون لديك 10 غيغابايت على الأقل من المساحة المتبقية بعد إنشاء الحاويات الخاصة بك.
بعد تهيئة الجهاز سيطلب منك إعداد الشبكة. انتقل إلى الخطوة 2 لمتابعة الإعداد.

الخيار 2 : استخدام عتاد التخزين

إذا كنت تريد استخدام عتاد التخزين قاعدةً للتخزين فستحتاج إلى العثور على العتاد الذي يتوافق مع حجم كتلة التخزين التي قمت بإنشائها في تهيئة LXD. انتقل إلى تبويب المجلدات في لوحة التحكم الخاصة ب DigitalOcean، ثم حدد موقع وحدة التخزين الخاصة بك، انقر فوق المزيد من القائمة المنبثقة، ثم انقر فوق تعليمات الإعداد. حدد موقع العتاد بتطبيق أمر تهيئة وحدة التخزين. بعبارة أدق ابحث عن المسار المحدد بتنفيذ الأمر sudo mkfs.ext4 -F . لا تقم بتشغيل أيٍّ من الأوامر الظاهرة في تلك الصفحة، نحن لا نريد سوى العثور على اسم الجهاز الصحيح لإعطاءه لـ LXD.
يوضح الشكل التالي مثالا عن اسم الجهاز الخاص بوحدة التخزين. تحتاج فقط إلى الجزء المسطر عليه بالأحمر:

يمكنك أيضا تحديد اسم الجهاز بالأمر التالي:

ls -l /dev/disk/by-id/
total 0
lrwxrwxrwx 1 root root  9 Sep  16 20:30 scsi-0DO_Volume_volume-fra1-01 -> ../../sda 

في هذه الحالة اسم الجهاز لوحدة التخزين هو

/dev/disk/by-id/scsi-0D0_Volume_volume-fra1-01

وقد يختلف الأمر لديك. بعد تحديد اسم عتاد وحدة التخزين تابع مع تثبيت LXD . عندما تُسأل هل تود أن تستخدم عتاد التخزين الموجود، اختر نعم وقدّم المسار الذي وجدته سابقا:

Would you like to use an existing block device (yes/no) [default=no]? yes
Path to the existing block device: /dev/disk/by-id/scsi-0DO_Volume_volume-fra1-01

بعد تحديد القرص الصلب سيطلب منك إعداد خيارات الشبكة.

الخطوة 2 : إعدادات الشبكة

بعد تهيئة وحدة التخزين ستتم مطالبتك بتهيئة الشبكة وإعدادها. أولاً سيسألك LXD عما إذا كنت تريد جعله متاحًا عبر الشبكة. اختيار “نعم” سوف يمكّنك من إدارة LXD من جهاز الكمبيوتر المحلي الخاص بك، دون الحاجة إلى جلسة SSH للوصول إلى هذا الخادوم. اقبل القيمة الافتراضية “لا” :

Output of the "lxd init" command — LXD over the network
Would you like LXD to be available over the network (yes/no) [default=no]? no

ثم سيطلب منك إنشاء جسر الشبكة من أجل حاويات LXD. وهذا يتيح لك الميزات التالية:

• كل حاوية تحصل تلقائيًا على عنوان IP خاص.
• يمكن للحاويات التواصل مع بعضها البعض عبر الشبكة الخاصة.
• يمكن لكل حاوية انشاء اتصال بالإنترنت.
• تبقى الحاويات التي تقوم بإنشائها غير قابلة للوصول إليها من الإنترنت.

لا يمكنك إجراء اتصال من الإنترنت والوصول إلى حاوية إلا إذا قمت بتمكينه صراحة. سوف تتعلم كيفية السماح بالوصول إلى حاوية معينة في الخطوة التالية.

عندما يطلب منك تكوين جسر LXD، اختر نعم :

Output of the "lxd init" command — Networking for the containers
Do you want to configure the LXD bridge (yes/no) [default=yes]? Yes

سيتم عرض الرسالة التالية:

• أكّد أنك تريد إعداد جسر الشبكة.
• سيطلب منك تسمية الجسر. اقبل القيمة الافتراضية.
• سيطلب منك إجراء تهيئة الشبكة لكلٍّ من IPv4 و IPv6. في هذا الدرس سنعمل فقط مع IPv4.
• عندما يطلب منك إعداد شبكة فرعية IPv4 اختر نعم . سوف يتم إعلامك بأنه تم إنشاء شبكة فرعية عشوائية بالنسبة لك. اختر موافق للمتابعة.
• عند المطالبة بعنوان IPv4 صحيح قم بقبول القيمة الافتراضية.
• عندما يطلب منك قناع CIDR صحيح، اقبل القيمة الافتراضية.
• عند المطالبة بعنوان DHCP الأول اقبل القيمة الافتراضية. افعل الشيء نفسه مع عنوان DHCP الأخير وذلك حسب الحد الأقصى لعدد عملاء DHCP.
• اختر نعم عندما يطلب إلى NAT حركة مرور IPv4.
• عندما يطلب منك إعداد شبكة فرعية لـ IPv6 اختر “لا” . ستشاهد المخرجات التالية بعد اكتمال إعداد الشبكات:

Warning: Stopping lxd.service, but it can still be activated by:
  lxd.socket
LXD has been successfully configured.

أنت مستعد الآن لإعداد حاوياتك.

الخطوة 3 : إنشاء حاوية Nginx

لقد نجحت في تهيئة LXD وأصبحت الآن جاهزا لإنشاء الحاوية الأولى وإدارتها. يمكنك إدارة الحاويات مع الأمر lxc.
استخدم lxc list لعرض الحاويات المثبتة المتاحة:

lxc list 

سترى الإخراج التالي:

Generating a client certificate. This may take a minute...
If this is your first time using LXD, you should also run: sudo lxd init
To start your first container, try: lxc launch ubuntu:16.04

+------+-------+------+------+------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+-------+------+------+------+-----------+

وبما أن هذه هي المرة الأولى التي يتواصل فيها الأمر lxc مع مراقب الأجهزة الافتراضية لـ LXD تتيح لك مخرجاته معرفة أنه قام تلقائيًا بإنشاء شهادة للعميل من أجل الاتصال الآمن مع LXD، وبعض المعلومات حول كيفية تشغيل حاوية، وقائمة فارغة من الحاويات، وهو أمر متوقع لأننا لم ننشئ أي واحدة حتى الآن. دعنا ننشئ حاوية تقوم بتشغيل Nginx. للقيام بذلك سوف نستخدم الأمر lxc launch لإنشاء وبدء حاوية أوبونتو 16.04 اسمها webserver. لإنشاء الحاوية webserver ننفذ الأمر:

lxc launch ubuntu:x webserver

x في ubuntu:x هو اختصار للحرف الأول من Xenial ، الاسم الرمزي لأوبونتو 16.04. ubuntu: هو معرف للمستودع الذي تم تكوينه مسبقا لصور LXD . يمكنك أيضا استخدام ubuntu:16.04 لاسم الصورة.

ملاحظة : يمكنك العثور على القائمة الكاملة لجميع صور ubuntu المتاحة عن طريق تشغيل الأمر:

lxc image list Ubuntu:

وفي التوزيعات الأخرى عن طريق تشغيل الأمر:

lxc image list images:

نظرًا لأن هذه هي المرة الأولى التي تقوم فيها بإنشاء حاوية ينزّل هذا الأمرُ صورةَ الحاوية من الإنترنت ويخزنها محليًا بحيث إذا أنشأت حاوية جديدة فسيتم إنشاؤها بسرعة أكبر. سترى هذه المخرجات عند إنشاء الحاوية الجديدة:

Generating a client certificate. This may take a minute...
If this is your first time using LXD, you should also run: sudo lxd init
To start your first container, try: lxc launch ubuntu:16.04

Creating webserver
Retrieving image: 100%
Starting webserver 

الآن ..بعد تشغيل الحاوية استخدم الأمر lxc list لعرض معلومات حولها:

lxc list 

تظهر المخرجات جدولًا يحمل اسم كل حاوية وحالتها الحالية وعنوان IP خاص بها ونوعها وما إذا كانت هناك لقطات مأخوذة.

Output
+-----------+---------+-----------------------+------+------------+-----------+
|  NAME     |  STATE  |         IPV4          | IPV6 |    TYPE    | SNAPSHOTS |
+-----------+---------+-----------------------+------+------------+-----------+
| webserver | RUNNING | 10.10.10.100 (eth0)   |      | PERSISTENT | 0         |
+-----------+---------+-----------------------+------+------------+-----------+ 

ملاحظة: إذا قمت بتمكين IPv6 في LXD فقد يكون مخرج أمر lxc list كبيرًا جدًا عن أن تسعه الشاشة.
يمكنك أن تستخدم بدلا عن ذلك الأمر lxc list –columns ns4tS الذي يظهر فقط الاسم والحالة و IPv4 والنوع وما إذا كانت هناك لقطات متاحة.
لاحظ عنوان IPv4 للحاوية. ستحتاج إلى تهيئة الجدار الناري للسماح بالزيارات الواردة من العالم الخارجي.

سنتابع في الدرس القادم كيفية تكوين وتوجيه وإزالة حاوية Nginx.

ترجمة -وبتصرّف- للمقال How to Set Up and Use LXD on Ubuntu 16.04 لصاحبه Simos Xenitellis

Alerta هو تطبيق ويب يُستخدم لتعزيز وإزالة التنبيهات المتكررة من مختلف أنظمة المراقبة ومشاهدة ذلك كله على شاشة واحدة. يمكن أن تدمج Alerta مع العديد من أدوات المراقبة المعروفة مثل Nagios, Zabbix, Sensu, InfluxData Kapacitor وغيرها الكثير. في هذا الدرس سوف نقوم بتثبيت Alerta وإعداده لعرض الإشعارات من Nagios، نظام المراقبة المفتوح المصدر الأكثر شعبية.

المتطلبات الأساسية

لمتابعة هذا الدرس، سوف تحتاج إلى:

• خادومين CentOS 7 تم إعدادهما باتباع هذا الدليل الضبط المبدئي لخادوم CentOS 7 ، مع مستخدم sudo غير جذر وجدار الحماية.
• على الخادوم CentOS الأول، حيث ستشغل Nagios، قم بتثبيت المكونات التالية:
  • Apache و MySQL و PHP, ، باتباع هذا الدليل: كيف تثبت حزم MySQL ،Apache ،Linux :LAMP و PHP
  • Nagios 4، مع متطلباته باتباع هذا الدليل: كيف تستخدم Nagios 4 لمراقبة خواديم Ubuntu 14.04
• على الخادوم CentOS الثاني حيث سنقوم بتثبيت Alerta في هذه المقالة ، قم بتثبيت Nginx و MongoDB و Alerta.

الخطوة 1 – تثبيت وحدة وسيط الأحداث Nagios-to-Alerta

يمكنك توسيع وظائف Nagios مع وحدات وسائط الأحداث الخاصة بــ (Nagios (Nagios Event Broker (NEB).
NEB هي آلية دمج أحداث (Event) الخاصة بـ Nagios، ووحدات NEB هي المكتبات المشتركة التي تمكنك من دمج خدمات أخرى مع Nagios. في هذه الخطوة سنقوم بتثبيت بوابة Nagios-to-Alerta ، وهي وحدة NEB التي سوف ترسل إشعارات إلى Alerta.

سجل الدخول إلى خادوم Nagios بمستخدم غير جذر:

ssh sammy@your_nagios_server_ip

بوابة Nagios-to-Alerta لا تحتوي على حزم جاهزة مسبقًا في نظام التشغيل، لذلك سيكون عليك بناؤها من المصدر. للقيام بذلك ستحتاج إلى تثبيت بعض أدوات التطوير والملفات. ستحتاج أيضًا إلى تثبيت Git حتى تتمكن من جلب شفرة المصدر من GitHub.

sudo yum install -y git curl gcc make libcurl-devel

استخدم Git الآن لاستنساخ الملفات المصدرية من مستودع GitHub للمشروع:

git clone https://github.com/alerta/nagios-alerta.git 

ثم اذهب إلى مجلد nagios-alerts الجديد:

cd nagios-alerta

ثم جمّع وحدة nagios-alerta باستخدام الأمر make :

make nagios4 

سترى المخرجات التالية:

cd ./src && make nagios4
make[1]: Entering directory `/root/nagios-alerta/src'
gcc -fPIC -g -O2 -DHAVE_CONFIG_H -I../include -I../include/nagios4 -lcurl -o alerta-neb.o alerta-neb.c -shared  -lcurl
make[1]: Leaving directory `/root/nagios-alerta/src'

إذا كنت ترى شيئا مختلفا فتأكد من تثبيت كافة المتطلبات الأساسية.
الآن.. قم بالبدء في عملية التثبيت:

sudo make install

سترى هذه المخرجات، وهي تشير إلى أن الوحدة تم تثبيتها في /usr/lib/nagios :

cd ./src && make nagios4
make[1]: Entering directory `/root/nagios-alerta/src'
gcc -fPIC -g -O2 -DHAVE_CONFIG_H -I../include -I../include/nagios4 -lcurl -o alerta-neb.o alerta-neb.c -shared  -lcurl
make[1]: Leaving directory `/root/nagios-alerta/src'

بعد تثبيت الوحدة يمكننا إعداد Nagios لاستخدام هذه الوحدة.

الخطوة 2 – إعداد الوحدة Nagios-to-Alerta

لنقم بإعداد Nagios لإرسال رسائل الإشعار إلى Alerta.
أولًا، مكّن وحدة الوسيط Alerta المثبتة حديثًا في ملف الإعدادات الرئيسي لــ Nagios. افتح ملف إعدادات Nagios في المحرر:

sudo vi /usr/local/nagios/etc/nagios.cfg

ثم ابحث عن الجزء الذي يحتوي على توجيهات broker_module :

..
# EVENT BROKER MODULE(S)
# This directive is used to specify an event broker module that should
# by loaded by Nagios at startup.  Use multiple directives if you want
# to load more than one module.  Arguments that should be passed to
# the module at startup are separated from the module path by a space.
#
[...]
#broker_module=/somewhere/module1.o
#broker_module=/somewhere/module2.o arg1 arg2=3 debug=0
...

لإعداد الوحدة Alerta تحتاج إلى اثنين من المدخلات الإلزامية:

• URL: العنوان الذي يتم استخدامه للتواصل مع Alerta API.
• key: مفتاح API ، لقد قمت بإنشائه في الخطوة 4 من البرنامج التعليمي السابق. ستحتاج إليه في المصادقة مع Alerta وإرسال الأحداث.

أضف هذا السطر إلى الملف لإعداد دمج Alerta:

...
broker_module=/usr/lib/nagios/alerta-neb.o http://your_alerta_server_ip/api key=ALERTA_API_KEY
...

هناك بعض المخلات الاختيارية الإضافية التي يمكنك تعيينها أيضا:

• env: يحدد هذا اسم البيئة. اسم البيئة الافتراضي هو Production.
• hard_only : تجاوز النتائج في الحالة الصعبة فقط. يمكنك العثور على مزيد من المعلومات حول أنواع حالات Nagios في وثائق Nagios . عين هذا إلى 1 لتمكين هذا الوضع.
• debug: تمكين وضع معالجة وتصحيح الأخطاء. عيّن هذا إلى 1 لتمكين هذا الوضع.

لتحديد كل هذه الخيارات استخدم هذا السطر بدلًا من السابق:

...
broker_module=/usr/lib/nagios/alerta-neb.o http://your_alerta_server_ip/api key=ALERTA_API_KEY env=Production hard_only=1 debug=1
...

احفظ الملف وأغلق المحرر. من أجل تعيين التنبيهات حسب البيئة واسم الخدمة ستحتاج إلى إعداد أسماء البيئة والخدمات باستخدام: Nagios Custom Object Variables
للقيام بذلك استخدم المتغيرات _Environment و _Service في الإعداد الخاص بك. دعنا نهيئ ذلك الآن. افتح ملف إعدادات كائنات Nagios الافتراضي، ستجده في الدليل /usr/local/nagios/etc/objects/ :

sudo vi /usr/local/nagios/etc/objects/localhost.cfg

سوف نجعل جميع التنبيهات في هذا المضيف من نوع تنبيهات “Production”، وسنسمي الخدمة الافتراضية بـ “Nagios” . ابحث عن تعريف المضيف التالي:

...
define host{
        use                     linux-server            ; Name of host template to use
                                                        ; This host definition will inherit all variables that are defined
                                                        ; in (or inherited by) the linux-server host template definition.
        host_name               localhost
        alias                   localhost
        address                 127.0.0.1
        }

...

أضف القيم _Environment و _Service إلى الإعدادات:

...
        host_name               localhost
        alias                   localhost
        address                 127.0.0.1
        _Environment            Production
        _Service                Nagios
        }
...

الآن ضع علامة ” System ” على جميع الأحداث المرتبطة بانعدام المساحة أو قلتها في مساحة التخزين المخصصة للنظام. حدد موقع هذا الجزء من الملف الذي يحدد كيفية التحقق من المساحة الفارغة:

...
define service{
        use                             local-service         ; Name of service template to use
        host_name                       localhost
        service_description             Root Partition
        check_command                   check_local_disk!20%!10%!/
        }
...

قم بتعديله لربطه بخدمة System:

...
define service{
        use                             local-service         ; Name of service template to use
        host_name                       localhost
        service_description             Root Partition
        check_command                   check_local_disk!20%!10%!/
        _Service                        System
        }
...

احفظ الملف ثم أغلق المحرر. أعد تشغيل Nagios لتطبيق هذه الإعدادات الجديدة:

sudo systemctl restart nagios.service 

تأكد من تشغيل الخدمة عن طريق التحقق من حالتها:

systemctl status nagios.service 

سترى المخرج التالي:

...
Jul 01 08:44:31 nagios nagios[8914]: [alerta] Initialising Nagios-Alerta Gateway module, v3.4.1
Jul 01 08:44:31 nagios nagios[8914]: [alerta] debug is off
Jul 01 08:44:31 nagios nagios[8914]: [alerta] states=Hard/Soft
Jul 01 08:44:31 nagios nagios[8914]: [alerta] Forward service checks, host checks and downtime to http://your_alerta_server_ip/api
Jul 01 08:44:31 nagios nagios[8914]: Event broker module '/usr/lib/nagios/alerta-neb.o' initialized successfully.
Jul 01 08:44:31 nagios nagios[8914]: Successfully launched command file worker with pid 8920

الآن Nagios سوف يرسل إشعارًا في أقرب وقت عن أيّ نظام أو خدمة وقع فيه مشكل. لنقم بإنشاء حدث اختبار.

الخطوة 3 - توليد إشعار اختبار للتحقق من دمج Nagios-Alerta

لنقم بتوليد إشعار لاختبار أن كل شيء متصل. افتراضيًا Nagios يحتفظ بمقدار مساحة القرص الحرة على الخادوم الخاص بك. سننشئ ملفًا مؤقتًا كبيرًا بما يكفي لتشغيل تنبيه استخدام نظام الملفات في Nagios.

أولًا، حدد مقدار المساحة الحرة لديك على خادوم Nagios. يمكنك استخدام الأمر df لمعرفة ذلك:

df –h

ستشاهد الناتج مثل ما يلي:

  Filesystem      Size  Used Avail Use% Mounted on
    /dev/vda1        20G  3.1G   16G   17% /

انظر إلى مقدار المساحة الحرة المتاحة. في هذه الحالة المساحة الحرة هي 16GB. قد تختلف المساحة الحرة لديك. استخدم الأمر fallocate لإنشاء ملف يستهلك أكثر من 80٪ من مساحة القرص المتوفرة والتي يجب أن تكون كافية لتحريك التنبيه:

fallocate -l 14G /tmp/temp.img

في غضون بضع دقائق سوف يقوم Nagios بتشغيل تنبيه حول مقدار المساحة الحرة على القرص وسوف يرسل إشعارًا إلى Alerta. سترى هذا الإشعار الجديد في لوحة التحكم الخاصة بــ Alerta:

الآن بعد أن عرفت أن التنبيهات تعمل، احذف الملف المؤقت الذي قمت بإنشائه حتى تتمكن من استعادة مساحة القرص:

rm -f /tmp/temp.img

بعد دقيقة واحدة سوف يقوم Nagios بإرسال رسالة الاسترداد. سوف يختفي الإشعار من لوحة التحكم الرئيسية لــ Alerta، ولكن يمكنك عرض جميع الأحداث المغلقة عن طريق اختيار Closed.

يمكنك النقر على صف الحدث لعرض مزيد من التفاصيل.

الخلاصة

في هذا المقال قمت بإعداد Nagios لإرسال إشعارات إلى خادوم آخر يقوم بتشغيل Alerta.
Alerta يعطيك مكانًا مناسبًا لتتبع التنبيهات من العديد من الأنظمة. على سبيل المثال، إذا كانت بعض أجزاء البنية الأساسية تستخدم Nagios وأخرى تستخدم Zabbix فيمكنك دمج الإشعارات من كلا النظامين في لوحة واحدة.

ترجمة -وبتصرّف- للمقال How To Monitor Nagios Alerts with Alerta on CentOS 7 لصاحبه Vadym Kalsin

تعرف على كيفية استخدام الروابط التي تجعل أعمالك أسهل من خلال توفير إمكانية الوصول إلى الملفات من مواقع متعددة من شجرة المجلدات في نظام ملفات لينكس. في مقالاتٍ لي كَتبتُ عن جوانب مختلفة من أنظمة ملفات لينوكس ، بما في ذلك مقدمة عن نظام الملفات EXT4 لينكس و إدارة الأجهزة في لينكس و مقدمة عن نظام ملفات لينكس و دليل مستخدم لينكس لإدارة وحدة التخزين المنطقية ، وقد أشرت فيها إلى ميزة مثيرة للاهتمام من أنظمة الملفات في لينكس، يمكن أن تجعل هذه الميزة بعض المهام أسهل من خلال توفير إمكانية الوصول إلى الملفات من مواقع متعددة من شجرة المجلدات في نظام الملفات. هناك نوعان من روابط الملفات في لينكس: صلب و لين . والفرق بين هذين النوعين كبير، ولكن كلا النوعان يستخدمان لحل مشاكل مماثلة. كلاهما يوفر مداخل ( أو مراجع) إلى ملف واحد، لكنها تفعل ذلك بشكل مختلف تمامًا . الروابط مفيدة جدًا وإضافة مرنة إلى أنظمة ملفات لينكس فكل شيء فيه هو ملف.
لقد وجدت -على سبيل المثال- أن بعض البرامج تتطلب نسخة معينة من المكتبات . عندما تقوم بترقية النظام تحل مكتبة جديدة محل أخرى، سوف يتعطل البرنامج الذي تمت برمجته لاعتماد المكتبة القديمة. عادة يكون التغيير الوحيد في اسم المكتبة هو رقم الإصدار، ببساطة أضفت رابطًا يشير إلى المكتبة الجديدة ولكن باسم المكتبة القديمة. شغلت البرنامج مرة أخرى وقد عمل بشكل جيد. في الواقع ترتبط جميع التطبيقات تقريبًا بالمكتبات باستخدام اسم عام مع رقم إصدار رئيسي فقط ، وهذا الارتباط يشير إلى ملف المكتبة الفعلي الذي يحتوي أيضًا على رقم الإصدار الثانوي. وفي حالات أخرى يتم نقل الملفات المطلوبة من مجلد إلى آخر لتتوافق مع مواصفات لينكس، وتبقى في المجلدات القديمة روابط تشير إلى الملفات التي تم نقلها ، حتى إذا كان البرنامج لا يزال مرتبطًا بالمجلد القديم وملفاته لم يقع في مشكلة فقدان الملفات ، إذا عرضت الملفات في المجلد /lib64 فستجد العديد من الأمثلة على كلا الأمرين.

lrwxrwxrwx.  1 root root       36 Dec  8  2016 cracklib_dict.hwm -> ../../usr/share/cracklib/pw_dict.hwm 
lrwxrwxrwx.  1 root root       36 Dec  8  2016 cracklib_dict.pwd -> ../../usr/share/cracklib/pw_dict.pwd 
lrwxrwxrwx.  1 root root       36 Dec  8  2016 cracklib_dict.pwi -> ../../usr/share/cracklib/pw_dict.pwi
lrwxrwxrwx.  1 root root       27 Jun  9  2016 libaccountsservice.so.0 -> libaccountsservice.so.0.0.0 
-rwxr-xr-x.  1 root root   288456 Jun  9  2016 libaccountsservice.so.0.0.0 
lrwxrwxrwx   1 root root       15 May 17 11:47 libacl.so.1 -> libacl.so.1.1.0 
-rwxr-xr-x   1 root root    36472 May 17 11:47 libacl.so.1.1.0 
lrwxrwxrwx.  1 root root       15 Feb  4  2016 libaio.so.1 -> libaio.so.1.0.1 
-rwxr-xr-x.  1 root root     6224 Feb  4  2016 libaio.so.1.0.0 
-rwxr-xr-x.  1 root root     6224 Feb  4  2016 libaio.so.1.0.1 
lrwxrwxrwx.  1 root root       30 Jan 16 16:39 libakonadi-calendar.so.4 -> libakonadi-calendar.so.4.14.26 
-rwxr-xr-x.  1 root root   816160 Jan 16 16:39 libakonadi-calendar.so.4.14.26 
lrwxrwxrwx.  1 root root       29 Jan 16 16:39 libakonadi-contact.so.4 -> libakonadi-contact.so.4.14.26

بعض الروابط في الدليل / lib64. تظهر القائمة الطويلة من الدليل /lib64 أعلاه أن الحرف الأول في الملف هو الحرف “l”، وهو ما يعني أن كلاً منها رابط لين ( رمزي).

الروابط الصلبة Hard links

في مقدمة لنظام الملفات EXT4 لينكس ، ناقشت حقيقة أن كل ملف يحتوي على inode واحد يحتوي على معلومات حول هذا الملف، بما في ذلك موقع البيانات الذي ينتمي إلى هذا الملف. الشكل 2 في تلك المقالة يظهر مدخل دليل واحد يشير إلى inode ، يجب أن يكون لكل ملفٍ مدخلُ دليل واحدٌ على الأقل يشير إلى inode الذي يصف الملف. مدخل الدليل عبارة عن رابط صلب Hard links ، وبالتالي يكون لكل ملف رابط صلب واحد على الأقل.
في الشكل 1 أدناه، تشير مداخل الأدلة المتعددة إلى inode واحد. هذه كلها روابط صلبة. لقد اختصرت مواقع ثلاثة من مداخل الأدلة باستخدام التلدة ( ~ ) وهي تشير إلى المجلد الرئيسي، بحيث ( ~ ) يعادل /home/user . لاحظ أن مدخل الدليل الرابع مختلف تماما، (/home/shared ) والذي قد يكون موقعا لتبادل الملفات بين مستخدمي الكمبيوتر.

شكل 1

تقتصر الروابط الصلبة على الملفات الموجودة في نظام ملفات واحد، “نظام الملفات” يستخدم هنا بمعنى التقسيم من القرص الصلب أو الحجم المنطقي( logical volume) الذي وُصِل إلى نقطة توصيل معينة ( specified mount point)، في هذه الحالة /home . وذلك لأن أرقام inode فريدة من نوعها فقط داخل نظام ملفات الواحد، وفي حال اختلف نظام ملفات -على سبيل المثال- /var أو /opt سيكون inode له نفس رقم inode لملفنا. كل الروابط الصلبة تشير إلى inode واحدٍ يحتوي على البيانات الوصفية للملف، لذلك فإن كل هذه البيانات تعتبر جزءا من الملف، مثل الملكية والأذونات وعدد الروابط الصلبة إلى تلك inode ، هذه البيانات لا تختلف باختلاف الروابط الصلبة. السمة الوحيدة التي يمكن أن تكون مختلفة هي اسم الملف فلذلك لا يضمن في inode ، الروابط الصلبة إلى file/inode واحد موجود في نفس الدليل يجب أن يكون لها أسماء مختلفة، نظرا لأنه لا يمكن أن يكون هناك أسماء ملفات مكررة داخل دليل واحد.
يتم عرض الروابط الصلبة لملف بالأمر ls -l ، إذا كنت ترغب في عرض أرقام ال inode الفعلية، فإن الأمر ls -li يفعل ذلك.

الروابط الرمزية (اللينة)

الفرق بين الرابط الصلب والرابط اللين ( والمعروف أيضا باسم الرابط الرمزي أو الرابط التشعبي)، هو أن الروابط الصلبة تشير مباشرة إلى inode ، وأما الروابط اللينة فتشير إلى مدخل الدليل، أي واحدة من الروابط الصلبة. ولأن الروابط اللينة تشير إلى رابط صلب للملف وليس inode فإنها لا تعتمد على رقم inode ، ويمكن أن تعمل عبر أنظمة ملفات مختلفة.
الجانب السلبي لهذا هو أنه إذا حذف الرابط الصلب الذي يشير إليه الرابط اللين أو غُيِّر اسمه فإن الرابط الرمزي سوف يتعطل، لحسن الحظ الأمر ls يوضح الروابط المعطلة بالنص الأبيض بخلفية حمراء في قائمة طويلة.

مشروع مختبر: تجربة الروابط

أعتقد أن أسهل طريقة لفهم استخدام والاختلاف بين الروابط الصلبة واللينة هي مع مشروع المختبر. يجب أن يتم هذا المشروع في دليل فارغ بمستخدم غير جذر . لقد أنشأت الدليل ~/temp لهذا الغرض، ويجب عليك فعل ذلك أيضا. هذا يهيئ مكانا آمنا للقيام بالمشروع ويوفر دليلا جديدا فارغا للعمل فيه بحيث تكون فيه فقط الملفات المرتبطة بهذا المشروع.

الإعداد الأولي

أولا، أنشئ الدليل المؤقت الذي سوف تؤدي فيه المهام اللازمة لهذا المشروع. تأكد من أن مجلد العمل الحالي (PWD) هو المجلد الرئيسي الخاص بك، ثم أدخل الأمر التالي.

mkdir temp 

ادخل إلى الدليل ~/temp بالأمر

cd temp 

للبدء نحتاج إلى إنشاء ملف يمكننا الربط إليه. الأمر التالي يفعل ذلك ويوفر بعض المحتويات أيضا.

du -h > main.file.txt 

استخدم الأمر ls -l للتحقق من إنشاء الملف بشكل صحيح . يجب أن يكون الإخراج مشابه لنتائجي. لاحظ أن حجم الملف هو 7 بايت فقط، لكن قد يختلف حجم الملف عن بايت أو اثنين.

[dboth@david temp]$ ls -l 
total 4 
-rw-rw-r-- 1 dboth dboth 7 Jun 13 07:34 main.file.txt

لاحظ الرقم “1” الذي يتبع وضع الملف في القائمة . يمثل هذا العدد عدد الروابط الصلبة الموجودة للملف. في الوقت الحالي، يجب أن تكون 1 لأننا لم ننشئ أي روابط صلبة إضافية لملف الاختبار.

تجربة الروابط الصلبة

تنشئ الروابطُ الصلبة مدخلَ دليل جديد يشير إلى نفس inode ، لذلك عند إضافة روابط صلبة إلى ملف، سترى زيادة عدد الروابط. تأكد من أنك لا تزال في المجلد ~/temp ثم أنشئ رابطا صلبا إلى الملف main.file.txt ، وقم بعرض القائمة الطويلة بالأمر ls -l :

[dboth@david temp]$ ln main.file.txt link1.file.txt 
[dboth@david temp]$ ls -l 
total 8 
-rw-rw-r-- 2 dboth dboth 7 Jun 13 07:34 link1.file.txt 
-rw-rw-r-- 2 dboth dboth 7 Jun 13 07:34 main.file.txt

لاحظ أن كلا الملفين يحتوي على رابطين، وهما بنفس الحجم والتاريخ. فهو ملف واحد مع inode واحد ورابطين صلبين اثنين. أنشئ رابطا صلبا ثانيا إلى هذا الملف واعرض محتويات المجلد . يمكنك إنشاء رابط إلى أي من الروابط الموجودة link1.file.txt أو main.file.txt

[dboth@david temp]$ ln link1.file.txt link2.file.txt ; ls -l
total 16 
-rw-rw-r-- 3 dboth dboth 7 Jun 13 07:34 link1.file.txt 
-rw-rw-r-- 3 dboth dboth 7 Jun 13 07:34 link2.file.txt 
-rw-rw-r-- 3 dboth dboth 7 Jun 13 07:34 main.file.txt

لاحظ أن كل رابط صلب جديد في هذا الدليل يجب أن يكون لها اسم مختلف لأنه لا يمكن أن يكون للملفين نفس الاسم داخل نفس الدليل. حاول إنشاء رابط آخر باسم ملف موجود حاليا.

[dboth@david temp]$ ln main.file.txt link2.file.txt 
ln: failed to create hard link 'link2.file.txt': File exists

من الواضح أن هذا لن ينجح، لأن link2.file.txt موجود بالفعل.
حتى الآن، أنشأنا فقط الروابط الصلبة في نفس الدليل. لذلك، أنشئ رابطا في الدليل الرئيسي الخاص بك، حيث يوجد مجلد المشروع الذي نعمل عليه.

[dboth@david temp]$ ln main.file.txt ../main.file.txt ; ls -l ../main*
-rw-rw-r--    4 dboth dboth     7 Jun 13 07:34 main.file.txt

يظهر الأمر ls في القائمة المذكورة أعلاه أن الملف main.file.txt موجود في الدليل الرئيسي بنفس اسم الملف في الدليل المؤقت . وبطبيعة الحال، هذه ليست ملفات مختلفة. فهي الملف نفسه مع عدة روابط (مداخل الأدلة) إلى نفس Inode . للمساعدة في توضيح النقطة التالية أضف ملفا لا رابطا.

[dboth@david temp]$ touch unlinked.file ; ls -l
total 12
-rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 link1.file.txt
-rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 link2.file.txt
-rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 main.file.txt
-rw-rw-r-- 1 dboth dboth 0 Jun 14 08:18 unlinked.file

انظر في عدد الروابط الصلبة للملف الأول والملف الجديد باستخدام الخيار -i إلى الأمر ls

[dboth@david temp]$ ls -li
total 12
657024 -rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 link1.file.txt
657024 -rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 link2.file.txt
657024 -rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 main.file.txt
657863 -rw-rw-r-- 1 dboth dboth 0 Jun 14 08:18 unlinked.file

لاحظ الرقم 657024 على يسار وضع الملف في المثال أعلاه. هذا هو رقم Inode، وتشير جميع الروابط الثلاثة إلى Inode نفسه . يمكنك استخدام الخيار -i لعرض رقم Inode للروابط التي أنشأناها في الدليل الرئيسي أيضا، والتي سوف تظهر أيضا نفس القيمة. رقم Inode للملف الذي يحتوي على رابط واحد يختلف عن الروابط الأخرى. لاحظ أن أرقام Inode ستكون مختلفة على النظام الخاص بك.
لنقم بتغيير حجم رابط من الروابط الصلبة.

[dboth@david temp]$ df -h > link2.file.txt ; ls -li
total 12
657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 link1.file.txt
657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 link2.file.txt
657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 main.file.txt
657863 -rw-rw-r-- 1 dboth dboth    0 Jun 14 08:18 unlinked.file

حجم الملف سيتغير في جميع الروابط الصلبة وذلك لأن هناك ملفا واحدا يرتبط بمداخل متعددة.
أنا أعلم أن التجربة المقبلة سوف تعمل على جهاز الكمبيوتر الخاص بي لأن المجلد /tmp على تقسيم ( partition ) منفصل ، إن كان لك ذلك تأكد أن لديك إمكانية الوصول إلى التقسيم. إذا لم تقم بذلك، يمكنك إدراج إصبع ذاكرة USB وتركيبه. إذا كان أحد هذه الخيارات يناسبك، يمكنك إجراء هذه التجربة.
حاول إنشاء رابط إلى أحد الملفات في الدليل ~/temp في /tmp أو في أي مكان حيث نظام الملفات مختلف.

[dboth@david temp]$ ln link2.file.txt /tmp/link3.file.txt
ln: failed to create hard link '/tmp/link3.file.txt' => 'link2.file.txt': 
Invalid cross-device link

لماذا يحدث هذا الخطأ؟ السبب هو أن كل نظام ملفات منفصل لديه مجموعة خاصة من أرقام Inode ، ببساطة الإشارة إلى ملف من رقم Inode معين عبر كامل أدلة لينكس يمكن أن يؤدي إلى الارتباك، لأن نفس رقم Inode يمكن أن يوجد في كل نظام الملفات المختلفة.
ربما تريد تحديد مواقع كل الروابط الصلبة التي تنتمي إلى Inode واحد . يمكنك العثور على رقم Inode باستخدام الأمر ls –li ثم يمكنك استخدام الأمر find لتحديد كافة الروابط المتعلقة برقم Inode هذا.

[dboth@david temp]$ find . -inum 657024 
./main.file.txt
./link1.file.txt
./link2.file.txt  

لاحظ أن الأمر find لم يجد كل الروابط الأربعة إلى هذا Inode لأننا بدأنا في الدليل الحالي من ~/temp . لا يجد الأمر find سوى الملفات في الدليل الحالي. للعثور على جميع الروابط، يمكننا استخدام الأمر التالي الذي يحدد الدليل الرئيسي الخاص بك كمكان للبدء بالبحث.

[dboth@david temp]$ find ~ -samefile main.file.txt 
/home/dboth/temp/main.file.txt
/home/dboth/temp/link1.file.txt
/home/dboth/temp/link2.file.txt
/home/dboth/main.file.txt

قد تشاهد رسائل خطأ إذا لم يكن لديك أذونات كمستخدم غير جذر. يستخدم هذا الأمر أيضا الخيار -samefile بدلا من تحديد رقم Inode . هذا يعمل كما لو استخدمت رقم Inode ويمكن أن يكون هذا أسهل إذا كنت تعرف اسم واحد من الروابط الصلبة.

تجربة الروابط اللينة (الرمزية)

كما رأيت للتو، إنشاء روابط صلبة غير ممكن خارج حدود نظام الملفات. الروابط اللينة هي وسيلة لحل هذه المشكلة، رغم أنها يمكن أن تحقق نفس الغاية، فهي مختلفة جدا، ومعرفة هذه الاختلافات هو المهم.
لنبدأ من خلال إنشاء رابط رمزي في مجلد الاختبار ~/temp لبدء الاستكشاف

[dboth@david temp]$ ln -s link2.file.txt link3.file.txt ; ls -li
total 12
657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 link1.file.txt
657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 link2.file.txt
658270 lrwxrwxrwx 1 dboth dboth   14 Jun 14 15:21 link3.file.txt -> 
link2.file.txt
657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 main.file.txt
657863 -rw-rw-r-- 1 dboth dboth    0 Jun 14 08:18 unlinked.file

الروابط الصلبة -وهي تلك التي تحتوي على رقم Inode 657024 - لم تتغير، وعدد الروابط الصلبة المعروضة لم يتغير أيضا . الروابط الجديدة التي تم إنشاؤها لديها رقم Inode مختلف حيث رقمها658270 .
الرابط اللين المسمى link3.file.txt يشير إلى link2.file.txt ، استخدم الأمر cat لعرض محتويات link3.file.txt .
معلومات الملف للرابط الرمزي يبدأ بالحرف ” l ” الذي يشير إلى أن هذا الملف هو في الواقع رابط رمزي.
حجم الرابط الرمزي link3.file.txt في المثال أعلاه هو 14 بايت فقط. هذا هو حجم النص link3.file.txt -> link2.file.txt” “، وهو المحتوى الفعلي للرابط الرمزي.
الرابط الرمزي link3.file.txt لا يشير إلى Inode ، بل يشير إلى مدخل دليل آخر (رابط صلب أو رمزي) ، هذا يجعل من المفيد إنشاء روابط تمتد خارج حدود نظام الملفات . لذلك، دعونا ننشئ هذا الرابط.

[dboth@david temp]$ ln -s /home/dboth/temp/link2.file.txt 
/tmp/link3.file.txt ; ls -l /tmp/link*
lrwxrwxrwx 1 dboth dboth 31 Jun 14 21:53 /tmp/link3.file.txt -> 
/home/dboth/temp/link2.file.txt

حذف الروابط

هناك بعض الأشياء الأخرى التي يجب عليك مراعاتها عندما تحتاج إلى حذف الروابط أو الملفات التي تشير إليها.
أولا، دعونا نحذف الرابط main.file.txt ، تذكر أن كل مدخل دليل يشير إلى Inode هو مجرد رابط صلب.

[dboth@david temp]$ rm main.file.txt ; ls -li
total 8
657024 -rw-rw-r-- 3 dboth dboth 1157 Jun 14 14:14 link1.file.txt
657024 -rw-rw-r-- 3 dboth dboth 1157 Jun 14 14:14 link2.file.txt
658270 lrwxrwxrwx 1 dboth dboth   14 Jun 14 15:21 link3.file.txt -> 
link2.file.txt
657863 -rw-rw-r-- 1 dboth dboth    0 Jun 14 08:18 unlinked.file

لقد كان الرابط main.file.txt هو الرابط الأول الذي تم إنشاؤه عند إنشاء الملف. حذفه الآن لا يزال يترك الملف الأصلي وبياناته على القرص الصلب مع جميع الروابط الصلبة المتبقية. لحذف الملف وبياناته، سيكون عليك حذف كافة الروابط الصلبة المتبقية.
الآن احذف الرابط الصلب link2.file.txt

 [dboth@david temp]$ rm link2.file.txt ; ls -li 
total 8 
657024 -rw-rw-r-- 3 dboth dboth 1157 Jun 14 14:14 link1.file.txt 
658270 lrwxrwxrwx 1 dboth dboth   14 Jun 14 15:21 link3.file.txt -> 
link2.file.txt 
657024 -rw-rw-r-- 3 dboth dboth 1157 Jun 14 14:14 main.file.txt 
657863 -rw-rw-r-- 1 dboth dboth    0 Jun 14 08:18 unlinked.file

لاحظ ما يحدث للرابط اللين (الرمزي). حذف الرابط الصلب الذي يشير إليه الرابط اللين يتركه معطلا. لإصلاحه يمكنك إنشاء رابط صلب آخر في نفس الدليل بنفس اسم القديم، طالما لم يتم حذف كافة الروابط الصلبة.
يمكنك أيضا إعادة إنشاء الرابط بنفس الاسم ولكن بالإشارة إلى واحد من الروابط الصلبة المتبقية. وبطبيعة الحال، إذا لم يعد هناك حاجة إلى رابط لين يمكن حذفها مع الأمر rm
يمكن أيضا استخدام الأمر unlink لحذف الملفات والروابط. إنه بسيط جدا وليس لديه خيارات كالأمر rm ، ومع ذلك فإنه يعكس بشكل أكثر دقة العملية الأساسية للحذف، من حيث أنه يزيل الارتباط - مدخل الدليل - عن الملف الذي يتم حذفه.

الخلاصة

لقد عملت مع كلا النوعين من الروابط لفترة طويلة قبل أن أبدأ في فهم قدراتها وخصوصياتها. استغرق الأمر كتابة مشروع مختبر لفئة لينكس، لقد علمت أخيرا كيف تعمل الروابط. هذه المقالة هي تبسيط ما تعلمت في تلك الفئة، وآمل أن يسرع ذلك التعلم لديك.

ترجمة -وبتصرّف- للمقال A user’s guide to links in the Linux filesystem لصاحبه David Both

حقوق الصورة البارزة محفوظة لـ Freepik