يتناول هذا المقال كيفية تثبيت الإصدار 1.3 من برنامج Graylog (يُشار إليه أحيانا بـ Graylog2) وإعداده لتجميع سجلات نظام التشغيل Syslog في موضِع مركزي. Graylog هو أداة فعّالة لإدارة السجلات وتحليلها تُستخدم في حالات كثيرة من مراقبة Monitoring الدخول عبر SSH والأنشطة غير المعتادة إلى تنقيح Debugging التطبيقات. تعتمد الأداة على Elasticsearch، جافا وقاعدة بيانات MongoDB.

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

مكونات Graylog

توجد أربعة عناصر أساسية في Graylog:

• عُقد خادوم Graylog: تشتغل عاملا لاستقبال الرسائل ومعالجتها، كما أنها تتواصل مع بقية العناصر (غير عقد الخادوم). يعتمد أداء هذه العقد على قدرات معالج Processor الخادوم المضيف.
• عُقد Elasticsearch: تخزّن الرسائل والسجلات. يعتمد أداءها على الذاكرة الحية RAM وقدرة الأقراص على الإدخال/الإخراج.
• قاعدة بيانات MongoDB: تخزّن البيانات الوصفية Metadata؛ لا تُستحث كثيرا.
• واجهة المستخدم (صفحات ويب).

إعداد Graylog القاعدي

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

المتطلبات

ستحتاج من أجل تنفيذ الخطوات المشروحة في هذا الدرس إلى حساب إداري على خادوم أوبنتو 14.04 ذي ذاكرة عشوائية لا تقلّ عن 2GB. طريقة إعداد الحساب مشروحة في درس الإعداد الابتدائي لخادوم أوبنتو 14.04. إن كانت ذاكرة الوصول العشوائي لديك أقل من 2GB فلن تستطيع تشغيل جميع مكونات Graylog.

نبدأ بتثبيت MongoDB.

تثبيت MongoDB

تثبيت MongoDB سهل وسريع. نفّذ الأمر التالي لاستيراد مفتاح GPG الخاص بـ MongoDB إلى apt:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10

ثم أنشئ قائمة مصادر MongoDB بتنفيذ الأمر:

echo "deb http://repo.mongodb.org/apt/ubuntu trusty/mongodb-org/3.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.0.list

حدّث أرشيف الحزم:

sudo apt-get update

ثم نثبّت الإصدار المستقر Stable من MongoDB بتنفيذ الأمر:

sudo apt-get install mongodb-org

يجب أن تكون قاعدة بيانات MongoDB الآن جاهزة وتعمل على الخادوم. يمكنك التأكد من ذلك بتنفيذ الأمر:

sudo service mongod status

لتشغيل قاعدة البيانات (إن لم تشتغل لسبب ما):

sudo service mongod start

تثبيت Java

يحتاج Elasticsearch لجافا حتى يعمل، لذا سنثبته. ينصح Elasticsearch بتثبيت Oracle Java 8، وهو ما سنفعله (على الرغم من ذلك، إلا أن Elasticsearch ينبغي أن يعمل دون مشاكل مع OpenJDK).

أضف مستودع PPA الخاص بـ ـOracle Java إلى apt:

sudo add-apt-repository ppa:webupd8team/java

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

sudo apt-get update

نفذ أمر تثبيت Oracle Java 8 التالي (واقبل شروط الرخصة في النافذة المنبثقة):

sudo apt-get install oracle-java8-installer

بعد اكتمال تثبيت جافا يأتي دور Elasticsearch.

تثبيت Elasticsearch

نحتاج لإصدار من Elasticsearch سابق للإصدار 2.0 ليعمل معه Graylog، لذا سنثبّت الإصدار 1.7 من Elasticsearch.

نستورد مفتاح GPG العمومي الخاص بـ ـElasticsearch إلى apt كما يلي:

wget -qO - https://packages.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -

قد تحتاج لإدخال كلمة السر الخاصة بالمستخدم الجذر.

ثم أنشئ قائمة مورد لـ Elasticsearch:

echo "deb http://packages.elastic.co/elasticsearch/1.7/debian stable main" | sudo tee -a /etc/apt/sources.list.d/elasticsearch-1.7.x.list

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

sudo apt-get update

ثم نثبت Elasticsearch:

sudo apt-get -y install elasticsearch

الخطوة الموالية هي إعداد Elasticsearch؛ افتح ملف التعديل:

sudo vi /etc/elasticsearch/elasticsearch.yml

ابحث عن فقرة cluster.name ثم انزع عنها علامة التعليق # وأبدل القيمة المبدئية بـ graylog-development (الاسم الذي اخترناه للعنقود Cluster. لا يمكن أن يكون لعنقودين في نفس الشبكة نفس الاسم):

cluster.name: graylog-development

يستعمل Elasticsearch المنفذ Port رقم 9200. سنمنع المتصلين من خارج الشبكة المحلية من الوصول إليه. اعثر على السطر الذي يحدّد المضيف على الشبكة network.host، أزل علامة التعليق وضع مكانها localhost (المضيف المحلي) كالتالي:

network.host: localhost

احفظ ملف elasticsearch.yml ثم أغلقه. أعد تشغيل Elasticsearch:

sudo service elasticsearch restart

نفذ الأمر التالي لتشغيل Elasticsearch مع بدء تشغيل النظام:

sudo update-rc.d elasticsearch defaults 95 10

انتظر بضع لحظات ثم نفذ الأمر التالي للتأكد من أن Elasticsearch يعمل كما يرام:

curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'

تظهر نتيجة الأمر كالتالي:

{
"cluster_name" : "graylog-development",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 1,
"active_shards" : 1,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0
}

تثبيت خادوم Graylog

يمكننا الآن بعد تجهيز المتطلبات تثبيتُ برنامج Graylog. نبدأ بتثبيت خادوم Graylog.

ننزل حزمة مستودع Graylog في المجلد الشخصي للمستخدم:

cd ~
wget https://packages.graylog2.org/repo/packages/graylog-1.3-repository-ubuntu14.04_latest.deb

ونثبتها:

sudo dpkg -i graylog-1.3-repository-ubuntu14.04_latest.deb

تضيف هذه الحزمة عند تثبيتها مستودع Graylog إلى قائمة المستودعات لدى النظام.

قبل تثبيت حزمة خادوم Graylog نتأكد من أن apt-transport-https التي تمكّن من تنزيل حزم apt باتصال آمن مثبتة:

sudo apt-get update
sudo apt-get install apt-transport-https
sudo apt-get install graylog-server

سنستخدم حزمة pwgen لتوليد مفاتيح سرية لذا سنثبتها:

sudo apt-get install pwgen

سنحتاج لضبط كلمة سر مدير خادوم Graylog ومفتاحه الخاص. يُضبط المفتاح الخاص في ملف server.conf بتحديد قيمة معطى password_secret. يمكن توليد مفتاح عشوائي وإدراجه في إعداد Graylog عبر الأمرين التاليين:

SECRET=$(pwgen -s 96 1)
sudo -E sed -i -e 's/password_secret =.*/password_secret = '$SECRET'/' /etc/graylog/server/server.conf

تُعيَّن كلمة سر المدير بإنشاء مجموع تحقق Checksum لكلمة السر المرغوبة ثم تحديد قيمة المعطى root_password_sha2 في ملف إعداد Graylog بمجموع التحقق المُنشأ.

أنشئ مجموع التحقق الخاص بكلمة السر بتنفيذ الأمر أدناه مع إبدال password بكلمة السر التي ترغب فيها. يدرج أمر sed في السطر الثاني مجموع التحقق في ملف إعداد Graylog (يمكنك تنفيذ أمر shasum ثم إدراج النتيجة يدويا في الملف server.conf):

PASSWORD=$(echo -n password | shasum -a 256 | awk '{print $1}')
sudo -E sed -i -e 's/root_password_sha2 =.*/root_password_sha2 = '$PASSWORD'/' /etc/graylog/server/server.conf

نفتح ملف server.conf لتحريره:

sudo vi /etc/graylog/server/server.conf

ستجد أن قيمتي المعطيين password_secret وroot_password_sha2 عبارة عن سلسلة محارف Strings عشوائية هي ناتج الأوامر أعلاه.

نعيد تعيين قيمة المعطى rest_transport_uri التي هي وسيلة اتصال واجهة ويب Graylog بخادومه. بما أننا نثبت جميع العناصر على نفس الخادوم فسنحدّد القيمة 127.0.0.1 أو localhost. اعثُر على المعطى rest_transport_uri وعدّل قيمته لتصبح على النحو التالي (مع إزالة علامة التعليق أمام السطر #):

rest_transport_uri = http://127.0.0.1:12900/

نغيّر قيمة معطى elasticsearch_shards إلى 1 نظرا لأن لدينا عامل Elasticsearch وحيدا وهو الخادوم:

elasticsearch_shards = 1

ثم نغير قيمة المعطى elasticsearch_cluster_name إلى graylog-development (نفس الاسم الذي حددناه أعلاه لمعطى cluster.name):

elasticsearch_cluster_name = graylog-development

نزيل علامة التعليق من أمام السطرين التاليين لاستخدام اتصال من نوع unicast بدلا من multicast:

elasticsearch_discovery_zen_ping_multicast_enabled = false
elasticsearch_discovery_zen_ping_unicast_hosts = 127.0.0.1:9300

احفظ الملف ثم أغلقه. خادوم Graylog الآن مضبوط وجاهز للعمل. نشغّل خادوم Graylog بتنفيذ الأمر التالي:

sudo java -jar /usr/share/graylog-server/graylog.jar server

تظهر في مخرجات الأمر العبارتان التاليتان دلالة على نجاح تشغيل خادوم Graylog:

Started REST API at <http://127.0.0.1:12900/>
Graylog server up and running

الخطوة الموالية هي تثبيت واجهة ويب Graylog.

تثبيت واجهة ويب Graylog

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

sudo apt-get install graylog-web

الخطوة التالية هي إعداد المفتاح السري لواجهة الويب الذي يمثله معطى application.secret في ملف الإعداد web.conf. نطبق نفس الطريقة السابقة لتوليد مفتاح سري وإدراجه:

SECRET=$(pwgen -s 96 1)
sudo -E sed -i -e 's/application\.secret=""/application\.secret="'$SECRET'"/' /etc/graylog/web/web.conf

افتح ملف إعداد واجهة الويب لتحريره:

sudo vi /etc/graylog/web/web.conf

نحتاج لتحديث ملف الإعداد لتحديد قيمة المعطى graylog2-server.uris التي هي قائمة من مسارات URI خاصة بخواديم Graylog. بما أن لدينا عقدة خادوم واحدة فيجب أن تطابق قيمة graylog2-server.uris قيمةَ المعطى rest_listen_uri في إعداد الخادوم (أي http://127.0.0.1:12900/):

graylog2-server.uris="http://127.0.0.1:12900/"

احفظ الملف ثم أغلقه. يجب نسخ ملف الإعداد إلى المسار /usr/share/graylog-web/conf/web.conf كالتالي:

sudo cp /etc/graylog/web/web.conf /usr/share/graylog-web/conf/web.conf

ننفذ الأمر التالي لتشغيل واجهة ويب Graylog:

sudo /usr/share/graylog-web/bin/graylog-web-interface

نستطيع الآن استخدام واجهة الويب، وهو ما سنفعله في الفقرات التالية.

إعداد Graylog لاستقبال رسائل النظام Syslog

أدخل عنوان الويب التالي إلى شريط العناوين في متصفحك المفضل:

http://graylog_public_IP:9000/

يمثّل graylog_public_IP عنوان IP العمومي لخادومك.

ستظهر لديك واجهة تطلب اسم المستخدم وكلمة السر. أدخل admin وكلمة السر التي اخترتها أثناء إعداد خادوم Graylog.

ثم بعد الدخول الواجهة التالية:

يوجد في أعلى الواجهة عدد يمثل إشعارا تظهر بعد النقر عليه رسالة تقول إن لديك عقدة نشطة لا تصلها أية مُدخَلات Inputs. فلنضف مدخلا لاستقبال رسائل سجل النظام عبر UDP.

إنشاء مدخل لسجلات النظام عبر ميثاق UDP

انقر على القائمة المنسدلة System (النظام) الموجودة في شريط القوائم العلوي واختر Inputs (مُدخلات) لإضافة مُدخَل يستقبل رسائل سجل النظام. اختر Syslog UDP من القائمة المنسدلة في الصفحة الجديدة ثم انقر على زر Launch new input (ابدأ المُدخَل الجديد).

ستظهر نافذة منبثقة جديدة. أدخل البيانات التالية (أبدِل graylog_private_IP بعنوان IP الداخلي لخادومك):

Title: syslog
Port: 8514
Bind address: graylog_private_IP

ثم انقر على زرّ Launch أسفل النافذة.

ستجد أن مُدخلا جديدا باسم syslog يظهر في فقرة Local inputs؛ تظهر أولا لصيقة starting (في طور التشغيل) ثم بعد قليل تتحول إلى اللون الأخضر وعبارة running (يعمل)، قد تحتاج لإعادة تحميل الصفحة لتحديث الحالة.

جهزنا خادوم Graylog لاستقبال رسائل من سجل النظام، بقي لنا ضبط الخادوم لإرسال سجلات النظام إلى Graylog.

إعداد الخواديم لإرسال سجلات النظام إلى Graylog

ينبغي تطبيق الخطوات التالية على الخواديم التي نريد مراقبتها.

نبدأ بإنشاء ملف إعداد rsyslog في المجلد etc/rsyslog/، سنسميه 90-graylog.conf:

sudo vi /etc/rsyslog.d/90-graylog.conf

نضيف الأسطر التالية إلى الملف كي يبعث برسائل سجلات النظام إلى خادوم Graylog (أبدل graylog_private_IP بعنوان IP المحلي لخادوم Graylog):

$template GRAYLOGRFC5424,"<%pri%>%protocol-version% %timestamp:::date-rfc3339% %HOSTNAME% %app-name% %procid% %msg%\n"
*.* @graylog_private_IP:8514;GRAYLOGRFC5424

احفظ الملف ثم أغلقه. سيُحمَّل هذا الملف مع تحميل إعداد rsyslog، تجب إعادة تحميل rsyslog من أجل اعتماده:

sudo service rsyslog restart

نعود، بعد إكمال إعداد rsyslog على جميع الخواديم التي نريد مراقبة سجلاتها إلى واجهة Graylog.

عرض مصادر Graylog

بالعودة إلى واجهة الويب، انقر قائمة Sources في الشريط العلوي. ستظهر أسفل الصفحة لائحة بجميع الخواديم التي أعددت عليها rsyslog لإرسال السجلات إلى Graylog، مع عدد الرسائل الواردة منها في المدة المحددة ضمن القائمة المنسدلة (ساعة مبدئيا).

البحث في بيانات Graylog

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

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

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

خاتمة

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

ترجمة -وبتصرف- لمقال How To Install Graylog 1.x on Ubuntu 14.04 لصاحبه Mitchell Anicas.

يُستخدَم Hexo، وهو إطار عمل للتدوين الثابت (Static) مبنيّ على Node.js، لنشر تدوينات مكتوبة في مستندات Markdown. تُعالَج التدوينات ثم تُحوَّل إلى HTML/CSS انطلاقا من قوالب معدَّة لهذا الغرض (تماما كما تفعل بقية مُولّدات المحتوى الثابت مثل Jekyll و Ghost). يعمل Hexo على هيئة وِحدات (Modules) يمكن ثبيتها وإعدادها حسب الحاجة.

سنعدّ في هذا المقال Hexo اعتمادا على خادوم ويب Nginx ومنصة GitHub.

المتطلبات

في ما يلي قائمة بما ستحتاجه لإنجاز هذا الدرس:

• خادوم أوبنتو 14.04 مع حساب ذي صلاحيات إدارية غير المستخدم الجذر. يمكنك إعداد حساب بالمواصفات المطلوبة باتباع خطوات درس الإعداد الابتدائي لخادوم أوبنتو.
• تثبيت Git على خادوم أوبنتو وإعداده. يشرح درس تنصيب وإعداد Git و gitolite للتحكم في الإصدارات على أوبنتو الكيفية.
• تثبيت Node.js على خادوم أوبنتو.
• تثبيت Nginx على خادوم أوبنتو.
• حساب على GitHub الذي هو مستودع Git.

تأكد من أن المتطلبات مثبتة ومضبوطة ثم انتقل إلى خطوات تثبيت Hexo وإعداده.

الخطوة الأولى: تثبيت Hexo وبدء تشغيله

تتضمن هذه الفقرة كل ما عليك فعله لتثبيت Hexo وجعله يعمل على خادومك.

ابدأ أولا بتحديث الحزم:

sudo apt-get update && sudo apt-get upgrade

يتكوّن Hexo من الكثير من العناصر والحزم البرمجية. سنجلب اثنتين من الحزم الأكثر أهمية في Hexo باستخدام مدير الاعتمادات npm.

العنصر الأول والأهم هو hexo-cli، يوفر أوامر Hexo الأساسية :

npm install hexo-cli -g

ثم نأتي للعنصر الثاني hexo-server وهو خادوم مضمَّن يمكن استخدامه للعرض المسبق للتدوينات واختبارها قبل النشر:

npm install hexo-server -g

تتوفر الكثير من الحزم الأخرى لـHexo، إلا أن الحزمتين أعلاه هما الأساس الذي لا يُستغنى عنه لإطلاق مدونة باستخدام Hexo. يمكن أن تستعرض الحزم الأخرى المكونة لإطار عمل Hexo بخاصية البحث في npm.

نحتاج الآن لقاعدة ملفات لبناء مدونتنا عليها. يُوفِّر Hexo أمر init لهذا الغرض، كل ما عليك فعله هو تمرير المسار أو المجلد الذي تريد استخدامه لملفات إعداد المدونة إلى الأمر:

hexo init ~/hexo_blog

يستغرق اﻷمر بضع ثوان حسب سرعة الاتصال لديك:

INFO  Copying data to ~/hexo_blog
INFO  You are almost done! Don't forget to run 'npm install' before you start blogging with Hexo!

. . .

ننتقل إلى المجلد المستخدَم في الأمر السابق:

cd ~/hexo_blog

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

npm install

يمكنك تجاهل التحذيرات الاختيارية (WARN notsup). نحصُل بعد انتهاء تنفيذ الأمر على ملفات الإعداد الأساسية.

الخطوة الثانية: ضبط ملف الإعداد الأساسي في Hexo

نسرُد محتويات مجلد المشروع:

ls -l

تظهر مخرجات على النحو التالي:

-rw-rw-r--   1 zeine77 zeine77  1483 Feb 17 15:48 _config.yml
drwxrwxr-x 201 zeine77 zeine77 36864 Feb 17 15:53 node_modules
-rw-rw-r--   1 zeine77 zeine77   442 Feb 17 15:48 package.json
drwxrwxr-x   2 zeine77 zeine77  4096 Feb 17 15:45 scaffolds
drwxrwxr-x   3 zeine77 zeine77  4096 Feb 17 15:45 source
drwxrwxr-x   3 zeine77 zeine77  4096 Feb 17 15:45 themes

يعدّ الملف config.yml_ أهم هذه الملفات إذ تخزَّن به إعدادات نواة Hexo. إن احتجت مستقبلا لإجراء تعديلات على المدونة فعلى الأرجح سيكون ذلك من خلال هذا الملف.

نفتح الملف لإجراء تخصيصات على البرنامج:

nano _config.yml

توجد في أعلى الملف فقرة معنونة بـSite (الموقع):

# Site
title: Hexo
subtitle:
description:
author: John Doe
language:
timezone:

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

الخياران المواليان يمثلان اللغة والمنطقة الزمنية. تأخذ اللغة قيمة عبارة عن حرفين يرمزان للغة وفق معيار ISO-639-1. يُضبط الوقت مبدئيا على المنطقة الزمنية للخادوم ويستخدم صيغة قاعدة بيانات tz. إن قررت التعديل على إحدى المعطيين فتأكد أن القيمة وفق الصيغة المطلوبة.

في ما يلي مثال على ملف الإعداد:

#Site
title: مدونة أكاديمية حسوب
subtitle: مدونة تقنية تستخدم Hexo
description: مثال على استخدام Hexo لإنشاء مدونة
author: أكاديمية حسوب
language: ar 
timezone: Africa/Nouakchott

تضبط الفقرة الموالية إعدادات الروابط. يمكن استخدام عنوان IP قيمةً لمعطى url إن لم يكن لديك نطاق خاص.

# URL
## If your site is put in a subdirectory, set url as 'http://yoursite.com/child' and root as '/child/'
url: http://127.0.0.1
root: /
permalink: :year/:month/:day/:title/
permalink_defaults:

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

# Writing
new_post_name: :title.md # File name of new posts
default_layout: draft
titlecase: false # Transform title into titlecase

احفظ الملف ثم أغلقه. سنعود إليه لاحقا عندما نبدأ بالنشر.

الخطوة الثالثة: كتابة تدوينة جديدة ونشرها

تبدأ عملية نشر تدوينة (أو مسودة كما أسميناها في الإعداد أعلاه) بتنفيذ الأمر التالي، حيث أول-تدوينة هو اسم التدوينة التي تريد إنشاءها:

hexo new أول-تدوينة

تظهر الرسالة التالي في سطر الأوامر:

INFO  Created: ~/hexo_blog/source/_drafts/أول-تدوينة.md

نفتح الملف لتحرير أول تدويناتنا:

nano ~/hexo_blog/source/_drafts/أول-تدوينة.md

يجب أن تحوي كل تدوينة على جبهة أمامية Front-matter، وهي كتلة تعليمات قصيرة مكتوبة بـJSON أو YAML لضبط إعدادات مثل عنوان التدوينة، تاريخ النشر، الوسوم Tags ومعلومات من هذا القبيل. تُعلَّم نهاية الجبهة الأمامية بعلامة --- أو ;;;. تمكن كتابة منشور المدونة بعد الجبهة الأمامية باستخدام صيغة Markdown.

أبدل المحتوى المبدئي لملف "md.أول-تدوينة" بالمحتوى التالي:

title: أول تدوينة في مدونة أكاديمية حسوب
tags:
- حسوب
- مدونة
categories:
- إعلانات
comments: true
date: 2016-02-18 09:30:00
---

## هنا تكتب تعليمات ماركداون

**هذه هي تدوينتنا الأولى!**

نص التدوينة الأولى

احفظ الملف ثم أغلقه.

سيبقى ملف ماركداون الذي أنشأناه للتو في مجلد hexo_blog/source/_drafts/~ إلى أن ننشره. كل الملفات الموجودة في هذا الملف غير مرئية لزوار المدونة.

ننشر التدوينة لتتاح للزوار

hexo publish first-post

تظهر الرسالة التالية:

INFO  Published: ~/hexo_blog/source/_posts/أول-تدوينة.md

سيصبح بالإمكان رؤية المنشور فور نشر المدونة.

الخطوة الرابعة: تشغيل خادوم الاختبار

أكملنا في الخطوات السابقة إعداد الخادوم، ونشرنا أول تدوينة. سنشغّل خادوم الاختبار لرؤية النتيجة:

hexo server

يمكن الآن رؤية المدونة بزيارة http://your_server_ip:4000 حيث your_server_ip عنوان IP الموقع. سيظهر لديك منشور Hello World المعرَّف مسبقا، إضافة للمنشور الذي كتبناه للتو.

اضغط على الزرين CTRL+C لإيقاف خادوم الاختبار.

يُستخدم خادوم الاختبار لعرض التغييرات والإضافات إلى المدونة، ثم يأتي وقت نشر المدونة على الشبكة بعد أن تنتهي من التعديلات.

الخطو الخامسة: إعداد Git لنشر المدونة

توجد وسائل عدة لنشر ما أعدنناه على Hexo. المقاربة المختارة في هذا الدرس هي استخدام Git لتخزين الملفات الثابتة، الخطافات Hooks لتوجيهها وNginx لتقديمها. تتيح حزم في Hexo الدعم لـ Heroku ،Rsync ،OpenShift وغيرها.

سنحتاج لمستودع Git نخزّن فيه ملفات HTML التي يولّدها Hexo. سنستخدم مستودعا عموميا على GitHub لتسهيل الأمور.

أنشئ مستودعا جديدا على GitHub باسم hexo_static أو أي اسم آخر تراه مناسبا، مع التأكد من أن المستودع عمومي (خيار Public). حدّد مربع Initialize this repository with a README لإضافة ملف README تلقائيا إلى المستودع.

افتح ملف الإعداد الرئيسي لـHexo من أجل تحريره:

nano _config.yml

توجد في أسفل الملف فقرة معنونة بـDeployment:

# Deployment
## Docs: https://hexo.io/docs/deployment.html
deploy:
type:

حدّد خيارات النشر كما في المثال أدناه. يحيل رابط URL إلى المستودع الذي أنشأته للتو؛ لذا تأكد من وضع اسم حسابك في GitHub مكان your_github_username. أبدل كذلك اسم المستودع إن كنت اخترت اسما مغايرا.

deploy:
    type: git
    repo: https://github.com/your_github_username/hexo_static.git
    branch: master

احفظ الملف ثم أغلقه.

بما أننا اخترنا النشر عن طريق Git فسنحتاج لحزمة Hexo التي ترسل الملفات الثابتة التي يولدها إلى مستودع Git.

استخدم npm لتثبيتها:

npm install hexo-deployer-git --save

يمكنك الآن تجربة إرسال الملفات إلى مستودع hexo_static وإضافة أول إيداع بواسطة Hexo:

hexo generate && hexo deploy

أدخل معلومات الاستيثاق في GitHub عندما تطلب منك لبدء نقل الملفات.

تبدو نتيجة تنفيذ الأمرين السابقين بعد نجاحه على النحو التالي:

To https://github.com/username/hexo_static.git.
* [new branch]      master -> master
Branch master set up to track remote branch master from https://github.com/username/hexo_static.git.
INFO  Deploy done: git

الخطوة السادسة: إعداد Nginx

يتميّز خادوم ويب Nginx في تقديم الملفات الثابتة للزوار، وهو ما يجعله اختيارا مناسبا لمدونتنا. نبدأ بإعداد Nginx لتقديم المدونة للزوار.

ننشئ أولا مجلدات النظام التي سنطلب من Nginx استخدامها:

sudo mkdir -p /var/www/hexo

ثم نعطي للحساب الذي نستخدمه على أوبنتو ملكيةَ المجلد:

sudo chown -R $USER:$USER /var/www/hexo

نعدّل أذون المجلد على النحو التالي:

sudo chmod -R 755 /var/www/hexo

نفتح ملف الإعداد المبدئي لـNginx لتحريره:

sudo nano /etc/nginx/sites-available/default

نعدّل كلتة server في ملف الإعداد بحيث يصبح جذر المستند Document root يشير إلى المجلد الذي أنشأناه للتو:

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;

    root /var/www/hexo;
    index index.html index.htm;

احفظ الملف ثم أغلقه. يمكنك عند الحصول على اسم نطاق للمدونة تحرير هذا الملف وتحديد قيمة server_name بحيث تصبح اسمَ نطاقك.

نعيد تشغيل Nginx لاعتماد التعديلات:

sudo service nginx restart

الخطوة السابعة: إنشاء خطافات Hooks في Git

سنربط في هذه الخطوة مستودع hexo_static بمستودع Git آخر لنرسل عبره ملفات HTML إلى مجلد خادوم الويب.

نبدأ بإنشاء مستودع Git فارغ الهدف منه توجيه محتوى المستودع hexo_static إلى مجلد خادوم الويب:

git init --bare ~/hexo_bare

أنشئ ملف خطاف جديدا داخل مجلد خطافات Git:

nano ~/hexo_bare/hooks/post-receive

أضف السطرين التاليين إلى الملف. نحدّد في الملف شجرة عمل Git التي تحوي الشفرة المصدرية ومجلد Git الذي يحوي الإعدادات، السجل وأمورا أخرى:

#!/bin/bash

git --work-tree=/var/www/hexo --git-dir=/home/$USER/hexo_bare checkout -f

احفظ الملف ثم أغلقه.

اجعل الملف post-receive قابلا للتنفيذ:

chmod +x ~/hexo_bare/hooks/post-receive

سنحتاج الآن لنسخ مستودع النشر hexo_static الذي أنشأناه في الخطوة الخامسة إلى الخادوم. تأكد من إبدال username في الأمر أدناه باسم حسابك في GitHub.

git clone https://github.com/username/hexo_static.git ~/hexo_static

انتقل إلى المجلد hexo_static:

cd ~/hexo_static

نضيف مستودع hexo_bare السابق على أنه مستودع بعيد باسم live:

git remote add live ~/hexo_bare

الخطوة الثامنة: إنشاء سكربت النشر

يمكن باستخدام سكربت Shell قصير بدء كامل عملية النشر السابقة بدلا من أدائها يدويا. يعني هذا أننا لن نحتاج إلى تنفيذ أوامر Hexo الواحدة تلو الأخرى أو تشغيل خطّاف Git بأوامر متعدّدة.

نعود إلى مجلد مدونة Hexo وننشء فيه ملفا للسكربت:

cd ~/hexo_blog 
nano hexo_git_deploy.sh

ألصق الشفرة التالية في الملف:

#!/bin/bash

hexo clean
hexo generate 
hexo deploy

( cd ~/hexo_static ; git pull ; git push live master )

احفظ الملف ثم أغلقه.

ينفذ السكربت أوامر Hexo التالية:

• أمر clean الذي يحذف الملفات المولَّدة سابقا من مجلد public.
• أمر generate الذي يولّد ملفات HTML انطلاقا من ملفات ماركداون ويضعها في مجلد public.
• أمر deploy الذي يُرسِل الملفات الموجودة في المجلد public إلى مستودع Git الذي عرّفناه سابقا في ملف الإعداد config.yml_.

يشغّل السطر الأخير (cd ~/hexo_static ; git pull ; git push live master) خطاف Git ويحدّث مجلد المدونة على خادوم الويب بوضع ملفات HTML فيه.

نجعل سكربت النشر قابلا للتنفيذ:

chmod +x hexo_git_deploy.sh

الخطوة التاسعة: تنفيذ سكربت النشر

نفذ سكربت النشر السابق لاختبار كامل العملية:

./hexo_git_deploy.sh

ستُطلب منك معلومات الاستيثاق أثناء إيداع الملفات في مستودع GitHub. انتظر اكتمال العملية ثم ألق نظرة على الملفات في المجلد var/www/hexo/:

ls /var/www/hexo

النتيجة:

2016  archives  categories  css  fancybox  index.html  js  tags

تُظهر نتيجة الأمر أعلاه أن الملفات التي أنشأها Hexo نُقلت إلى مجلد خادوم الويب، يعني هذا أن بإمكانك تصفح المدونة بالذهاب إلى عنوان الخادوم http://your_server_ip/.

يكفي تنفيذ السكربت hexo_git_deploy.sh مستقبلا لنشر التعديلات أو الإضافات على المدونة. تذكر أن تختبر التغييرات على خادوم Hexo الاختباري قبل نشرها.

الخطوة العاشرة: اكتشاف نظام ملفات Hexo (اختيارية)

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

يبدو مخطَّط الملفات والمجلدات على النحو التالي:

├── _config.yml
├── node_modules
├── package.json
├── scaffolds
├── source
|   └── _posts
└── themes

مجلد node_modules

يخزّن Hexo في هذا المجلّد الوحدات التي تنزّلها بـ npm لاستخدامها في المدونة. بنهاية هذا الدرس لن توجد في هذا المجلد سوى الحزم التي نزلناها في الخطوة الأولى أو الحزم التي تأتي مضمَّنة في Hexo. على العموم لن تحتاج للتعديل على هذا المجلد.

مجلد package.json

يحوي ملف JSON هذا الإعدادات والإصدارات التي يستخدمها Hexo. الجأ لهذا الملف إن احتجت لتحديث الحزم يدويا، إرجاعها إلى إصدار أقدم Downgrade أو حذفها. لن تحتاج لتعديل هذا الملف على الأرجح إلا إذا حدث تعارض بين حزم Hexo وهو أمر غير شائع.

مجلد scaffolds

يستخدم Hexo القوالب الموجودة في هذا المجلد ليصيغ التدوينات وفقا لها. تأتي ثلاثة قوالب مبدئيا في الملف وهي draft (مسودة)، post (منشور) و page (صفحة). إن أردت استخدام قالب جديد فيجب وضعه هنا قبل الاستخدام.

مجلد source

توجد التدوينات المنشورة في مجلد فرعي من مجلد source، نفس الشيء ينطبق على المسودات. يوجد أغلب محتوى المدونة المكتوب بماركداون في هذا المجلد أو مجلد متفرع عنه.

مجلد themes

توضع قوالب المظهر Themes في هذا المجلد. تحوي أغلب القوالب على ملف config.yml_ خاص بها للاحتفاظ بإعدادات مخصّصة مثل تلك التي يعرّفها ملف الإعداد العام. استخدمنا خلال هذا الدليل القالب المبدئي في Hexo.

خاتمة

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

ترجمة -وبتصرف- لمقال How to Create a Blog with Hexo On Ubuntu 14.04 لصاحبه C.J. Scarlett.

هنالك العديد من البرمجيات المفيدة جدًا المطورة من فريق خادوم أوبنتو وغيرهم التي تندمج اندماجًا جيدًا مع نسخة خادوم أوبنتو، لكن ربما لا تكون معروفةً جدًا؛ سيعرض هذا الدرس بعض التطبيقات المفيدة التي تسهِّل إدارة خادوم، أو عدِّة خواديم أوبنتو.

pam_motd

عندما تسجل دخولك إلى خادوم أوبنتو، ربما تلاحظ "رسالة اليوم" (Message Of The Day اختصارًا MOTD)؛ تأتي هذه المعلومات وتُعرَض من حزمتين:

1. الحزمة landscape-common: توفر المكتبات الأساسية لبرمجية landscape-client، التي يمكن أن تُستخدَم لإدارة الأنظمة باستخدام تطبيق الويب Landscape؛ تتضمن هذه الحزمة الأداة ‎/usr/bin/landscape-sysinfo التي تُستخدَم لجمع المعلومات التي تُعرَض في MOTD، مثل المعالج، والذاكرة، والمساحة التخزينية للقرص الصلب ...إلخ. على سبيل المثال:

	  System load:  0.0               Processes:           76
	  Usage of /:   30.2% of 3.11GB   Users logged in:     1
	  Memory usage: 20%               IP address for eth0: 10.153.107.115
	  Swap usage:   0%

	  Graph this data and manage this system at https://landscape.canonical.com/

ملاحظة: يمكنك تشغيل الأمر landscape-sysinfo في أي وقت يدويًا.

2. حزمة update-notifier-common: التي توفر معلومات عن التحديثات المتوفرة للحزم، والتحققات من أنظمة الملفات (fsck)، ومتى يجب إعادة الإقلاع (مثلًا، بعد تحديث النواة).

تنفِّذ pam_motd السكربتات في ‎/etc/update-motd.d في ترتيبٍ مبنيّ على الرقم الذي يسبق اسم السكربت؛ يُكتَب ناتج السكربتات إلى ‎/‎var/run/motd، بترتيبٍ رقمي، ثم تُجمَّع مع ‎/etc/motd.tail.

يمكنك إضافة البيانات الديناميكية إلى رسالة اليوم؛ فمثلًا، لإضافة معلومات الطقس المحلي:

• أولًا، ثبِّت حزمة weather-util:

sudo apt-get install weather-util

• تستخدم أداة الطقس بيانات METAR من National Oceanic and Atmospheric Administration and Forecast من National Weather Service؛ وللعثور على المعلومات المحلية، فستحتاج إلى رمز ICAO من أربعة محارف؛ الذي يمكن تحديده بتصفح موقع http://www.weather.gov/tg/siteloc.shtml.

وعلى الرغم من أن National Weather Service هي وكالة حكومية تابعة للولايات المتحدة، لكن هنالك محطات طقس متوفرة في جميع أنحاء العالم، لكن ربما لا تتوفر معلومات الطقس لجميع المناطق خارج الولايات المتحدة.

• أنشِئ الملف ‎/usr/local/bin/local-weather، الذي هو سكربت شِل بسيط للحصول على الطقس لمنطقتك المحلية:

#!/bin/sh
#
#
# Prints the local weather information for the MOTD.
#
#

# Replace KINT with your local weather station.
# Local stations can be found here: http://www.weather.gov/tg/siteloc.shtml

echo
weather -i KINT
echo

• اجعل السكربت قابلًا للتنفيذ:

sudo chmod 755 /usr/local/bin/local-weather

• ثم أنشِئ وصلةً رمزيةً إلى ‎/etc/update-motd.d/98-local-weather:

sudo ln -s /usr/local/bin/local-weather /etc/update-motd.d/98-local-weather

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

يجب أن يُرحَّب بك الآن ببعض المعلومات المفيدة؛ لكن بعض المعلومات حول الطقس المحلي قد لا تكون مفيدةً جدًا! لكن هذا المثال يشرح مرونة pam_motd.

etckeeper

يسمح etckeeper بتخزين محتويات ‎/etc/‎ بسهولة في مستودع نظام تحكم بالإصدارات (VCS)؛ حيث يندمج مع apt لكي يودع التغيرات الحاصلة على ‎/etc تلقائيًّا عندما تُثبَّت أو تُحدَّث الحزم. وضع ‎/etc ضمن مستودع للتحكم بالإصدارات هو أفضل ممارسة يُنصَح بها في مجال العمل، وهدف etckeeper هو جعل هذه المهمة أسهل ما يمكن.

أدخِل الأمر الآتي في الطرفية لتثبيت etckeeper:

sudo apt-get install etckeeper

ملف الضبط الافتراضي ‎/etc/etckeeper/etckeeper.conf هو بسيط جدًا؛ الخيار الرئيسي يكون لضبط أي متحكم بالإصدارات ليُستخدَم؛ افتراضيًا، يكون etckeeper مضبوط لاستخدام Bazaar للتحكم بالإصدارات؛ ويُهيَّأ المستودع تلقائيًّا (ويُودَع فيه لأول مرة) أثناء عملية تثبيت الحزمة؛ من الممكن التراجع عن هذه الخطوة بإدخال الأمر:

sudo etckeeper uninit

سيودع etckeeper التغيرات غير المودعة التي حصلت على ‎/etc يوميًا افتراضيًا؛ يمكن تعطيل هذا باستخدام خيار الضبط AVOID_DAILY_AUTOCOMMITS؛ وستودع أيضًا التغيرات تلقائيًا قبل وبعد تثبيت الحزم؛ للمزيد من القدرة على التحكم بالتغيرات، من المستحسن أن تودع التغيرات يدويًا مع رسالة الإيداع كما يلي:

sudo etckeeper commit "..Reason for configuration change.."

يمكنك باستخدام أوامر VCS مشاهدة سجل المعلومات حول الملفات في ‎/etc:

sudo bzr log /etc/passwd

لشرح طريقة الاندماج مع نظام إدارة الحزم، جرِّب تثبيت الحزمة postfix:

sudo apt-get install postfix

بعد انتهاء التثبيت، ستودَع كل ملفات ضبط postfix إلى المستودع:

Committing to: /etc/
added aliases.db
modified group
modified group-
modified gshadow
modified gshadow-
modified passwd
modified passwd-
added postfix
added resolvconf
added rsyslog.d
modified shadow
modified shadow-
added init.d/postfix
added network/if-down.d/postfix
added network/if-up.d/postfix
added postfix/dynamicmaps.cf
added postfix/main.cf
added postfix/master.cf
added postfix/post-install
added postfix/postfix-files
added postfix/postfix-script
added postfix/sasl
added ppp/ip-down.d
added ppp/ip-down.d/postfix
added ppp/ip-up.d/postfix
added rc0.d/K20postfix
added rc1.d/K20postfix
added rc2.d/S20postfix
added rc3.d/S20postfix
added rc4.d/S20postfix
added rc5.d/S20postfix
added rc6.d/K20postfix
added resolvconf/update-libc.d
added resolvconf/update-libc.d/postfix
added rsyslog.d/postfix.conf
added ufw/applications.d/postfix
Committed revision 2.

وكمثال عن طريقة تتبع etckeeper للتغيرات اليدوية، أضف مضيفًا جديدًا إلى ملف ‎/etc/hosts؛ ثم استخدام bzr لمشاهدة أي ملفات قد عُدِّلَت:

sudo bzr status /etc/
modified:
  hosts

يمكنك إيداع التغيرات الآن:

sudo etckeeper commit "new host"

للمزيد من المعلومات حول bzr، راجع درس نظرة سريعة على Bazaar، نظام التحكم في الإصدارات على أوبنتو.

Byobu

أحد أكثر البرامج فائدةً لأي مدير أنظمة هو screen، حيث يسمح بتنفيذ عدِّة صدفات (shells) في طرفية واحدة؛ ولجعل بعض ميزات screen المتقدمة أكثر قربًا من المستخدم، ولتوفير بعض المعلومات المفيدة عن النظام؛ أنشِئت الحزمة byobu.

عند تنفيذ byobu، سيُظهِر الضغط على زر F9 قائمةَ الضبط التي تسمح لك بما يلي:

• عرض قائمة المساعدة.
• تغيير لون خلفية Byobu.
• تغيير لون أمامية Byobu.
• تبديل ظهور شريط الإشعارات.
• تغيير ربط المفاتيح.
• تغيير سلسلة الخروج.
• إنشاء نوافذ جديدة.
• إدارة النوافذ الافتراضية.
• «لا يبدأ Byobu عند تسجيل الدخول (تفعيل ذاك الخيار)".

ربط المفاتيح يحدد بعض الأمور مثل سلسلة الخروج (escape sequence)، وإنشاء نافذة جديدة، وتغيير النافذة ...إلخ. هنالك مجموعتا ربط للمفاتيح يمكن الاختيار بينها، واحدة باسم f-keys، والأخرى screen-escape-keys؛ إذا أردت استخدام الربط الافتراضي، فاختر none.

يوفر byobu قائمةً تُظهِر إصدارة أوبنتو، ومعلومات المعالج، ومعلومات الذاكرة، والوقت والتاريخ؛ مما يجعلها تبدو كقائمة سطح مكتب.

تفعيل خيار "لا يبدأ Byobu عند تسجيل الدخول" سيجعل byobu يبدأ عند فتح أي طرفية؛ التغيرات التي تحصل على byobu تكون خاصة بالمستخدم، ولن تؤثر على بقية مستخدمي النظام.

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

• h: تحريك المؤشر إلى اليسار محرفًا واحدًا.
• j: تحريك المؤشر إلى الأسفل سطرًا واحدًا.
• k: تحريك المؤشر إلى الأعلى سطرًا واحدًا.
• l: تحريك المؤشر إلى اليمين محرفًا واحدًا.
• : تحريك المؤشر إلى بداية السطر الحالي.
• $: تحريك المؤشر إلى نهاية السطر الحالي.
• G: تحريك المؤشر إلى سطر محدد (افتراضيًا إلى النهاية).
• ?: البحث إلى الخلف.
• n: الانتقال إلى المطابقة التالية إما إلى الأمام أو إلى الخلف.

مصادر

• راجع صفحة الدليل man update-motd للمزيد من الخيارات المتوفرة لحزمة update-motd.
• راجع موقع etckeeper لمزيدٍ من التفاصيل حول استخدامه.
• راجع أيضًا صفحة ويكي أوبنتو "etckeeper".
• لآخر الأخبار عن bzr، انظر إلى موقع bzr الرسمي.
• لمزيد من المعلومات حول screen، راجع موقعه الرسمي.
• وأيضًا صفحة ويكي أوبنتو "Screen".
• راجع صفحة مشروع Byobu لمزيدٍ من المعلومات.

ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Other Useful Applications.

ينشئ DRBD (الذي هو اختصار لـ Distributed Replicated Block Device والذي يُمكن ترجمته إلى «جهاز كتلي موزع ومُستنسَخ») نسخة انعكاسية من الأجهزة الكتلية بين عدِّة مضيفين؛ الاستنساخ غير مرئي لبقية التطبيقات على الأنظمة المضيفة. أي أقراص صلبة، أو أقسام، أو أجهزة RAID، أو حجوم منطقية ...إلخ. يمكن أن تُنسَخ انعكاسيًا (mirrored).

للبدء باستخدام DRBD، عليك أولًا تثبيت الحزم الضرورية؛ وذلك بإدخال الأمر الآتي من الطرفية:

sudo apt-get install drbd8-utils

ملاحظة: إذا كنت تستخدم نواةً وهمية (virtual kernel) كجزءٍ من الآلة الوهمية، فستحتاج إلى تصريف (compile) وحدة debd؛ ربما من الأسهل تثبيت حزمة linux-server داخل الآلة الوهمية.

يشرح هذا القسم كيفية ضبط debd لاستنساخ القسم ‎/srv بنظام ملفات ext3 بين مضيفَين؛ لا يهم حجم القسم، لكن يجب أن يكون كلا القسمَين بنفس الحجم.

الضبط

اسم المضيفين في هذا المثال هو debd01 و drbd02؛ وسنحتاج إلى الحصول على خدمة استبيان أسماء إما عبر DNS أو ملف ‎/etc/hosts؛ راجع درس DNS للتفاصيل.

• لضبط drbd، عدِّل ملف ‎/etc/drbd.conf على المضيف الأول:

global { usage-count no; }
common { syncer { rate 100M; } }
resource r0 {
        protocol C;
        startup {
                wfc-timeout  15;
                degr-wfc-timeout 60;
        }
        net {
                cram-hmac-alg sha1;
                shared-secret "secret";
        }
        on drbd01 {
                device /dev/drbd0;
                disk /dev/sdb1;
                address 192.168.0.1:7788;
                meta-disk internal;
        }
        on drbd02 {
                device /dev/drbd0;
                disk /dev/sdb1;
                address 192.168.0.2:7788;
                meta-disk internal;
        }
} 

ملاحظة: هنالك خيارات أخرى كثيرة في ‎/etc/drbd.conf، لكن القيم الافتراضية كافيةٌ لهذا المثال.

• انسخ الآن الملف ‎/etc/drbd.conf إلى المضيف الثاني:

scp /etc/drbd.conf drbd02:~

• الآن، انسخ الملف إلى ‎ /‎etcفي drbd02:

sudo mv drbd.conf /etc/

• باستخدام أداة drbdadm لتهيئة تخزين البيانات الوصفية؛ نفِّذ على كل خادوم ما يلي:

sudo drbdadm create-md r0

• وعلى كلا المضيفين، شغِّل عفريت drbd:

sudo service drbd start

• في drbd01، أو أي مضيف تريد أن يكون هو المضيف الرئيسي، أدخِل ما يلي:

sudo drbdadm -- --overwrite-data-of-peer primary all

• ستبدأ البيانات بالمزامنة مع المضيف الثاني بعد تنفيذ الأمر السابق؛ نفِّذ الأمر الآتي على drbd02 لمشاهدة العملية:

watch -n1 cat /proc/drbd

اضغط Ctrl+c لإيقاف الأمر السابق.

• في النهاية، أضف نظام ملفات إلى ‎/dev/drbd0 وصِله:

sudo mkfs.ext3 /dev/drbd0
sudo mount /dev/drbd0 /srv

الاختبار

لتختبر إذا كانت الملفات تُزامَن فعليًا بين المضيفين، فانسخ بعض الملفات في drbd01، إلى ‎/srv:

sudo cp -r /etc/default /srv

ثم افصل ‎/srv:

sudo umount /srv

الآن نزِّل مرتبة الخادوم الرئيسي إلى دور ثانوي:

sudo drbdadm secondary r0

ورقّ الخادوم الثانوي إلى رئيسي:

sudo drbdadm primary r0

ثم صِل القسم:

sudo mount /dev/drbd0 /srv

وباستخدام ls، يجب أن تشاهد ‎/srv/default منسوخةً من الخادوم الرئيسي (سابقًا) الذي هو drbd01.

مصادر

• للمزيد من المعلومات حول DRBD، راجع الصفحة الرئيسية الخاصة به.
• تحتوي صفحة دليل man drbd.conf على شرح لخيارات لم نغطها في هذا الفصل.
• راجع أيضًا صفحة الدليل man drbdadm.
• صفحة ويكي أوبنتو «DRBD» فيها المزيد من المعلومات.

ترجمة -وبتصرف- للمقال Ubuntu Server Guide: DRBD.

مجموعات التحكم هي آلية في النواة لتجميع وتتبع ووضع حد لاستهلاك الموارد للمهام؛ الواجهة الإدارية التي توفرها النواة تكون عبر نظام ملفات وهمي؛ لكن طوِّرت أدوات إدارية لمجموعات التحكم ذات مستوى أعلى، بما فيها libcgroup و lmctfy. بالإضافة لذلك، هنالك دليل في freedesktop.org حول كيف يمكن أن تتعاون التطبيقات بأفضل طريقة باستخدام واجهة نظام الملفات لمجموعات التحكم (cgroup filesystem interface).

في أوبنتو 14.04؛ أصبح مدير مجموعات التحكم (cgmanager) متوفرًا كأداة أخرى لإدارة واجهة cgroup؛ حيث هدفه هو الاستجابة لطلبات dbus من أي مستخدم، مما يمكِّنه من إدارة مجموعات التحكم التي أُسنِدَت إليه فقط.

لمحة

إن مجموعات التحكم (cgroups) هي الميزة التي تستعمل لتجميع المهام؛ حيث يكون تتبع الموارد ووضع حدود لها مُدارًا من أنظمة فرعية؛ إذ أنَّ الهيكلية (hierarchy) هي مجموعة من الأنظمة الفرعية الموصولة مع بعضها بعضًا؛ على سبيل المثال، إذا كانت الأنظمة الفرعية للذاكرة والأجهزة (devices) موصولة مع بعضها في ‎/sys/fs/cgroups/set1، فيمكن لأي مهمة في ‎/child1 أن تكون عرضةً للحدود الموافقة للنظامين الفرعيين السابقين.

حيث تُشكِّل كل مجموعة من الأنظمة الفرعية الموصولة «هيكليةً» (مع استثناءات)؛ مجموعات التحكم التي تكون أولاد ‎/child1 تكون عرضةً للحدود المفروضة على ‎/child1، ويكون استهلاك الموارد محسوبًا على ‎/child1.

الأنظمة الفرعية الموجودة تتضمن:

• cpusets: تبسيط إسناد مجموعة من المعالجات وعُقَد الذاكرة إلى مجموعات التحكم؛ فالمهام في مجموعة تحكّم فيها النظام الفرعي cpusets يمكن أن تستخدم المعالجات المُسنَدة إلى تلك المجموعة فقط.
• blkio: تحديد كتل الدخل/الخرج لكل مجموعة تحكم.
• cpuacct: توفير حساب الاستهلاك للمعالج لكل مجموعة تحكم.
• devices: التحكم في قدرة المهام على إنشاء أو استخدام عقد الأجهزة إما باستعمال قائمة بيضاء (whitelist) أو سوداء (blacklist).
• freezer: توفير طريقة «لتجميد» (freeze) و «تذويب» (thaw) مجموعات التحكم؛ لا يمكن جدولة (scheduled) مجموعات التحكم وهي مجمدة.
• hugetlb: تبسيط وضع حد لاستهلاك hugetlb لكل مجموعة تحكم.
• memory: السماح للذاكرة، وذاكرة النواة، وذاكرة التبديل (swap) بأن تُتَبَّع وتقيّد.
• net_cls: توفير واجهة لوضع علامات على الرزم الشبكية بناءً على مجموعة التحكم المُرسِلة؛ يمكن استعمال هذه العلامات لاحقًا باستخدام tc‏ (traffic controller) لإسناد أولويات للرزم الشبكية.
• net_prio: السماح بضبط أولوية بيانات التراسل الشبكي بناءً على مجموعة التحكم.
• cup: تمكين ضبط جدولة الخصائص على أساس مجموعة التحكم.
• pref_event: تفعيل نمط لكل معالج لمراقبة الخيوط (threads) لمجموعات تحكم معينة.

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

نظام الملفات

تُنشَأ هيكلية بوصل نسخة من نظام ملفات مجموعة التحكم لكل نظام فرعي مُراد استخدامه كخيار للوصل؛ على سبيل المثال:

mount -t cgroup -o devices,memory,freezer cgroup /cgroup1

وهذا ما سيُنشِئ هيكلية فوريًا مع الأجهزة ومجموعات التحكم للذاكرة موصولةً مع بعضها؛ ويمكن إنشاء مجموعة تحكم فرعية (child cgroup) باستخدام mkdir:

mkdir /cgroup1/child1

يمكن نقل المهام إلى مجموعة التحكم الفرعية الجديدة بكتابة أرقام معرفات عملياتهم في ملف tasks أو cgroup.procs:

sleep 100
echo $! > /cgroup1/child1/cgroup.procs

يمكن الإدارة أيضًا عبر ملفات في مجلدات cgroup؛ على سبيل المثال، لتجميد جميع المهام في child1:

echo FROZEN > /cgroup1/child1/freezer.state

يمكن العثور على كمية كبيرة من المعلومات عن مجموعات التحكم وأنظمتها الفرعية في مجلد التوثيق cgroups في شجرة مصدر النواة.

التفويض

يمكن لملفات ومجلدات مجموعات التحكم أن تُملَك من مستخدمين غير المستخدم الجذر، مما يمكِّن تفويض (delegation) إدارة مجموعات التحكم؛ عمومًا، تُجبِر النواة القيود المفروضة على الهيكلية على الأولاد؛ على سبيل المثال، إن كانت مجموعة الأجهزة ‎/child1 لا تملك وصولًا للقرص الصلب، فلا تستطيع مجموعة التحكم ‎/child1/child2 إعطاء نفسها هذه الامتيازات.

في أوبنتو 14.04، يوضع المستخدمون افتراضيًا في مجموعة من مجموعات التحكم التي يملكونها، مما يسمح لهم باحتواء المهام التي يشغلونها باستخدام مجموعات تحكم فرعية بأمان؛ تُستخدَم هذه الميزة عمليًا ويمكن الاعتماد عليها فمثلًا يمكن استخدامها لإنشاء حاوية LXC دون امتيازات.

المدير

مدير مجموعات التحكم (cgmanager) يوفر خدمة D-Bus للسماح للبرامج والمستخدمين بإدارة مجموعات التحكم دون الحاجة إلى معرفة أو وصول مباشر إلى نظام ملفات مجموعات التحكم. وللطلبات من المهام في نفس مجال الأسماء (namespace) للمدير، فيمكن للمدير إجراء التحققات الأمنية اللازمة للتأكد من شرعية تلك الطلبات؛ وللطلبات الأخرى، كتلك القادمة من مهمة في حاوية، فيجب القيام بطلبات D-Bus مُحَسَّنة؛ حيث يجب أن تُمرَّر معرفات process، و user، و group على شكل SCM_CREDENTIALS، لذلك يمكن للنواة ربط المعرفات إلى قيم المضيف العامة.

ولتبسيط استخدام استدعاءات D-Bus من جميع المستخدمين، فيبدأ «وسيط مدير مجموعات التحكم» (cgproxy) تلقائيًا في الحاويات؛ حيث يقبل طلبات D-Bus قياسية من المهام في نفس مجال أسمائه، ثم يحوله إلى طلبات SCM D-Bus محسنة التي تُمرَّر بعد ذلك إلى cgmanager.

مثال بسيط عن إنشاء مجموعة تحكم -التي ستُشغِّل تصريفًا (compile) يستهلك كثيرًا من طاقة المعالجة- سيكون كالآتي:

cgm create cpuset build1
cgm movepid cpuset build1 $$
cgm setvalue cpuset build1 cpuset.cpus 1
make

مصادر

• مشروع cgmanager مُستضاف في linuxcontainers.org.
• يمكن العثور على صفحة توثيق النواة هنا.
• ويمكن العثور على دليل freedesktop.org لاستخدام مجموعات التحكم هنا.

تعرفنا في الدرسين الماضيين عن مفهوم حاويات لينكس (LXC) ومبدأ عملها ثم شرعنا في كيفية البدء في استعمالها. سنعرج في هذا الدرس إلى كيفية استغلال مختلف نقاط ومراحل دورة حياة حاويات لينكس (LXC) لإدراج بعض من الإضافات (hooks) التي تقوم بإجراء مهمة ما.

إضافات إدارة دورة التشغيل

بدءًا من أوبنتو 12.10، أصبح من الممكن تعريف إضافات (hooks) تُنفَّذ عند نقاط محددة من دورة تشغيل الحاوية:

• الإضافات التي تحدث قبل التشغيل تُنفَّذ من مجال أسماء المضيف قبل أن تُنشَأ طرفيات أو نقاط وصل الحاويات؛ إذا أُجري أي وصل في هذه الفترة، فيجب أن يُنظَّف في إضافة تحدث بعد إيقاف التشغيل.
• الإضافات التي تحدث قبل الوصل تُنفَّذ في مجال أسماء الحاوية، لكن قبل أن يوصل جذر نظام الملفات؛ سينظف أي وصل لنظام الملفات في هذه الفترة تلقائيًا عند إيقاف تشغيل الحاوية.
• إضافات الوصل هي إضافات تنفذ بعد وصل أنظمة ملفات الحاوية، لكن قبل أن تُنفِّذ الحاوية pivot_root لتغيير جذر نظام ملفاتها.
• الإضافات التي تحدث بعد إيقاف التشغيل ستنفَّذ بعد إيقاف تشغيل الحاوية.

إذا أعادت أيّة إضافة خطأً، فسيلغى تشغيل الحاوية، لكن أي إضافة تحدث بعد إيقاف التشغيل ستنفَّذ، ستُسجَّل أيّة مخرجات تولد من السكربت بأولوية التنقيح (debug).

رجاءً راجع صفحة دليل lxc.container.conf لصيغة ملف الضبط التي سيحدد الإضافات؛ يمكن أن تأتي بعض أمثلة الإضافات في الحزمة lxc لتخدم كمثال حول طريقة كتابة إحدى تلك الإضافات.

سطر الأوامر

لدى الحاويات عدد مضبوط من «أسطر الأوامر» (consoles)؛ أحدها موجودٌ دائمًا في ‎/dev/console؛ الذي يظهر في الطرفية عندما تُشغِّل lxc-start ما لم تحدد الخيار ‎-d؛ يمكن إعادة توجيه ناتج خرج ‎/dev/console إلى ملف باستخدام ‎-c console-file في الأمر lxc-start؛ يمكن تحديد عدد إضافي من أسطر الأوامر باستخدام المتغير lxc.tty المضبوط عادةً إلى 4؛ يمكن أن تظهر أسطر الأوامر تلك في ‎/dev/ttyN (حيث N أكبر أو تساوي 1، وأصغر أو تساوي 4)؛ ولتسجيل الدخول إلى console 3 من المضيف، فنفِّذ الأمر:

sudo lxc-console -n container -t 3

إذا لم تحدد الخيار ‎-t N، فسيتم اختيار سطر أوامر غير مُستخدَم؛ للخروج منه، استخدام عبارة الخروج Ctrl-a q؛ لاحظ أن عبارة الخروج لا تعمل في سطر الأوامر الناتج عن lxc-start دون الخيار ‎-d.

استكشاف الأخطاء

التسجيل

إذا حدث شيء ما خاطئ عند تشغيل حاوية، فإن أول خطوة هي الحصول على سجل كامل من LXC:

sudo lxc-start -n C1 -l trace -o debug.out

هذا سيؤدي إلى جعل lxc يسجل في أعلى درجة إسهاب، التي هي trace، وسيكون ملف التخزين هو ملف باسم «debug.out»، إذا كان الملف debug.out موجودًا مسبقًا، فستُضاف معلومات السجل الجديد إليه.

مراقبة حالة الحاوية

هنالك أمران متوفران لمراقبة تغيرات حالة الحاوية: lxc-monitor الذي يراقب حاويةً أو أكثر ﻷي تغيرات في الحالة، حيث يأخذ اسم الحاوية مع الخيار ‎-n كالعادة؛ لكن في هذا الحالة، يمكن أن يكون اسم الحاوية تعبيرًا نمطيًا من نمط POSIX للسماح بمراقبة مجموعة من الحاويات؛ يستمر lxc-monitor بالعمل ويعرض تغيرات حالات الحاويات؛ أما lxc-wait فينتظر تغيِّرًا محددًا في الحالة ثم ينتهي تنفيذه؛ على سبيل المثال:

sudo lxc-monitor -n cont[0-5]*

هذا سيعرض جميع تغيرات الحالة لأي حاوية تطابق التعبير النمطي؛ بينما:

sudo lxc-wait -n cont1 -s 'STOPPED|FROZEN'

سينتظر إلى أن تتغير حالة الحاوية cont1 إلى STOPPED أو FROZEN ثم ينتهي.

الوصل

من الممكن في أوبنتو 14.04 الوصل (attach) إلى مجال أسماء حاوية، أبسط طريقة هي تنفيذ:

sudo lxc-attach -n C1

الذي سيبدأ صدفة موصولة لمجال الحاوية C1، أو داخل الحاوية؛ آلية عمل الوصل هي معقدة جدًا، مما يسمح بوصل مجموعة فرعية من مجالات أسماء (namespaces) الحاوية ونمط الحماية (security context)، راجع صفحة الدليل لمزيدٍ من المعلومات.

درجة إسهاب init في الحاوية

إذا أكمل LXC بدء تشغيل الحاوية، لكن فشل إكمال تنفيذ init فيها (على سبيل المثال، لم يُعرَض محث الدخول)، فمن المفيد طلب درجة إسهاب أكبر من عملية init، فلحاوية upstart:

sudo lxc-start -n C1 /sbin/init loglevel=debug

يمكنك أيضًا بدء تشغيل برامج مختلفة عن init، على سبيل المثال:

sudo lxc-start -n C1 /bin/bash
sudo lxc-start -n C1 /bin/sleep 100
sudo lxc-start -n C1 /bin/cat /proc/1/status

واجهة LXC البرمجية API

يمكن الوصول إلى غالبية وظائف LXC عبر واجهة برمجية (API) مُصدَّرة من liblxc التي تكون ارتباطاتها متوفرة لعدة لغات برمجية بما فيها بايثون، و lua، وروبي، و go.

ما يلي هو مثال عن استخدام ربط بايثون (المتوفرة في حزمة python3-lxc)، التي تُنشِئ وتبدأ حاوية، ثم تنتظر إلى أن يوقف تشغيلها:

# sudo python3
Python 3.2.3 (default, Aug 28 2012, 08:26:03)
[GCC 4.7.1 20120814 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lxc
__main__:1: Warning: The python-lxc API isn't yet stable and may change at any p
oint in the future.
>>> c=lxc.Container("C1")
>>> c.create("ubuntu")
True
>>> c.start()
True
>>> c.wait("STOPPED")
True

الحماية

يربط مجال الأسماء المعرفات (ids) إلى الموارد؛ لكنه لا يوفر للحاوية أي معرِّف يمكنه أن يشير إلى المورد، لذلك يمكن أن يُحمى المورد؛ وهذا هو أساس بعض الحماية الموفرة لمستخدمي الحاوية؛ على سبيل المثال، مجال أسماء IPC معزول تمامًا؛ لكن مجالات أسماء أخرى فيها بعض «التسربات» (leaks) التي تسمح للامتيازات بأن تُستخرَج بشكل غير ملائم من الحاوية إلى حاوية أخرى، أو إلى المضيف.

افتراضيًا، تُشغَّل حاويات LXC بسياسة AppArmor التي تقيّد بعض الأفعال، تفاصيل دمج AppArmor مع LXC موجودة في قسم «AppArmor» في الدرس السابق، الحاويات دون امتيازات تربط الجذر في الحاوية إلى مستخدم دون امتيازات في المضيف، وهذا يمنع الوصول إلى ملفات ‎/proc و ‎/sys التي تمثل موارد المضيف، وغيرها من الملفات المملوكة من الجذر في المضيف.

الثغرات في استدعاءات النظام

ميزة أساسية من مزايا الحاويات أنها تشارك النواة مع المضيف؛ وهذا يعني أنه إذا حوت النواة على أيّة ثغرات في استدعاءات النظام (system calls)، فيمكن أن تستغلها الحاوية؛ وبعد أن تتحكم حاوية بالنواة، فيمكنها أن تسيطر سيطرةً كاملةً على أي مورد معروف للمضيف!

بدءًا من أوبنتو 12.10، يمكن أن تقيَّد الحاوية من مرشِّح seccomp، إن Seccomp هو ميزة جديدة في النواة التي تُرشِّح استدعاءات النظام التي يمكن أن تُستخدَم من المهمة وأولادها؛ بينما يتوقع الوصول إلى إدارة سهلة ومحسنة للسياسة في المستقبل القريب، لكن تحتوي السياسة الحالية على قائمة بيضاء بسيطة لأرقام استدعاءات النظام؛ يبدأ ملف السياسة برقم الإصدار (الذي يجب أن يكون 1) في أول سطر ونوع السياسة (الذي يجب أن يكون whitelist) في ثاني سطر؛ وتُلحَق بقائمة أرقام، كل رقم في سطر.

سنحتاج عادةً لتشغيل حاوية بتوزيعة كاملة إلى عدد كبير من استدعاءات النظام؛ لكن لحاويات البرامج، يمكن أن نقلل عدد استدعاءات النظام المتوفرة إلى رقم قليل؛ وحتى للحاويات التي تشغل توزيعات كاملة يمكن الحصول على فوائد أمنية إذا حذفت -على سبيل المثال- استدعاءات النظام المتوافقة مع 32 بت في حاوية 64 بت؛ راجع صفحة دليل lxc.container.conf للمزيد من التفاصيل حول كيفية ضبط الحاوية لتستخدم seccomp؛ لن تُحمَّل افتراضيًا سياسة seccomp.

مصادر

• كتاب «Secure Containers Cookbook» يشرح كيفية استخدام أنماط الحماية لجعل الحاويات أكثر أمانًا.
• مشروع LXC مُستضاف في linuxcontainers.org.
• مشاكل LXC الأمنية مذكورة ومناقشة في صفحة وكي «LXC Security».

تعرفنا في الدرس الماضي على مفهوم حاويات لينكس (LXC)، مبدأ عملها وكيفية تثبيتها، سنشرع في هذا الدرس إلى كيفية بدء تشغيلها واستعمالها.

لا يملك LXC عفريتًا (daemon) يعمل طوال الوقت، لكنه يملك مهام upstart:

• المهمة ‎/etc/init/lxc-net.conf: هي مهمة اختيارية تعمل فقط إذا حَدَّد الملف ‎/etc/default/lxc الخاصية USE_LXC_BRIDGE (قيمتها هي true افتراضيًا)؛ حيث تهيِّء جسر NAT لكي تستخدمه الحاويات.
• المهمة ‎/etc/init/lxc.conf: تعمل إذا كانت الخاصية LXC_AUTO (قيمتها true افتراضيًا) مضبوطة إلى true في ‎/etc/default/lxc؛ حيث تبحث عن القيود في المجلد ‎/etc/lxc/auto‎/‎ حيث توجد وصلات رمزية إلى ملفات الضبط للحاويات التي يجب أن تُشغَّل في وقت الإقلاع.
• المهمة ‎/etc/init/lxc-instance.conf: تُستخدَم من ‎/etc/init/lxc.conf للبدء التلقائي لتشغيل حاوية.

التخزين

يدعم LXC عدّة أنماط من التخزين لجذر نظام ملفات الحاوية؛ افتراضيًا يكون مجلدًا بسيطًا، لأنه لا يتطلب أي ضبط مسبق للمضيف طالما أن نظام الملفات فيه مساحة تخزينية كافية؛ وهو لا يتطلب أيضًا امتيازات الجذر لإنشاء المخزن، لذلك سيكون ملائمًا للاستخدام دون امتيازات؛ جذر نظام الملفات للاستخدام مع امتيازات موجود افتراضيًا في ‎/var/lib/lxc/C1/rootfs، بينما جذر نظام الملفات للحاويات التي تعمل دون امتيازات يكون في ‎~/.local/share/lxc/C1/rootfs، إذا حُدِّد lxcpath خاص في lxc.system.com، فإن جذر نظام ملفات الحاوية سيكون موجودًا في ‎$lxcpath/C1/rootfs.

نسخة snapshot باسم C2 لحاوية C1 التي تُخزَّن في مجلد ستصبح حاوية overlayfs، بجذر نظام ملفات هو overlayfs:/var/lib/lxc/C1/rootfs:/var/lib/lxc/C2/delta0، أنواع التخزين الأخرى تتضمن loop، و btrfs، و LVM، و zfs.

حاوية تعتمد على تخزين btrfs تبدو عمومًا مثل حاوية تعتمد على التخزين في مجلد، ويكون جذر نظام الملفات في نفس المكان؛ لكن جذر نظام الملفات يحتوي على حجم فرعي (subvolume)، لذلك تكون نسخة snapshot مُنشَأة باستخدام نسخة snapshot لحجم فرعي.

جذر نظام الملفات لحاوية تستخدم LVM يمكن أن يكون أي حجم منطقي منفصل؛ اسم مجموعة الحجوم الافتراضي يمكن أن يُحدَّد في ملف lxc.conf؛ ويُضبَط نوع وحجم نظام الملفات لكل حاوية باستخدام lxc-create.

جذر نظام الملفات لحاوية تستخدم zfs هو نظام ملفات zfs منفصل، وموصول في المكان التقليدي ‎/var/lib ‎/lxc/C1/rootfs، يمكن تحديد zfsroot باستخدام lxc-create، ويمكن تحديد قيمة افتراضية في ملف lxc.system.conf.

المزيد من المعلومات حول إنشاء الحاويات بمختلف طرائق التخزين يمكن أن توجد في صفحة دليل lxc-create.

القوالب

يتطلب إنشاء حاوية عادةً إنشاء جذر نظام ملفات للحاوية؛ يفوض الأمر lxc-create هذا العمل إلى القوالب (templates)، التي تكون عادةً خاصة بالتوزيعة؛ قوالب lxc التي تأتي مع lxc يمكن أن توجد في مجلد ‎/usr/share/lxc/templates، بما فيها القوالب لإنشاء أوبنتو، ودبيان، وفيدورا، وأوراكل، وسنتوس، وجنتو بالإضافة لغيرها.

إنشاء صور للتوزيعات في أغلب الحالات يتطلب القدرة على إنشاء عقد أجهزة، ويتطلب ذلك أدوات التي ليست متوفرة في بقية التوزيعات، وعادةً يستغرق هذا الأمر وقتًا طويلًا؛ فلذلك يأتي lxc بقالب download، الذي ينزل صور مبنية مسبقًا للحاويات من خادوم lxc مركزي؛ أهم حالة استخدام هي السماح بإنشاء بسيط لحاويات دون امتيازات بواسطة مستخدمين غير الجذر، الذين لن يستطيعوا ببساطة تشغيل الأمر debootstrap.

عند تشغيل lxc-create، فجميع الخيارات التي تأتي بعد «--» تُمرَّر إلى القالب؛ ففي الأمر الآتي، تمرر الخيارات ‎--name و ‎--template و ‎--bdev إلى lxc-create، بينما يمرر الخيار ‎--release إلى القالب:

lxc-create --template ubuntu --name c1 --bdev loop -- --release trusty

يمكنك الحصول على مساعدة حول الخيارات المدعومة في حاوية معينة بتمرير الخيار ‎--help واسم القالب إلى الأمر lxc-create؛ فعلى سبيل المثال، للحصول على مساعدة حول تنزيل قالب:

lxc-create --template download --help

البدء التلقائي

يدعم LXC تعليم الحاويات لكي تُشغَّل عند إقلاع النظام؛ ففي الإصدارات قبل أوبنتو 14.04، كان يتم ذلك باستخدام وصلات رمزية في المجلد ‎/etc/lxc/auto؛ وبدءًا من أوبنتو 14.04، يتم ذلك عبر ملفات ضبط الحاوية؛ القيد:

lxc.start.auto = 1
lxc.start.delay = 5

يعني أن على الحاوية البدء عند إقلاع النظام ويجب الانتظار 5 ثواني قبل بدء تشغيل الحاوية التالية؛ يدعم LXC أيضًا ترتيب وتجميع الحاويات، وأيضًا إعادة الإقلاع وإيقاف التشغيل عبر مجموعات autostart؛ راجع صفحات دليل lxc-autostart و lxc-container.conf للمزيد من المعلومات.

AppArmor

يأتي LXC مع ملف ضبط AppArmor مهمته هي حماية المضيف من الإساءة العرضية للامتيازات داخل الحاوية؛ على سبيل المثال، لن تكون الحاوية قادرةً على الكتابة إلى ‎/proc/sysrq-trigger أو أغلبية ملفات ‎/sys.

الملف usr.bin.lxc-start يدخل حيز التنفيذ عند تشغيل lxc-start؛ يمنع ملف الضبط lxc-start من وصل أنظمة ملفات جديدة خارج نظام ملفات الجذر الخاص بالحاوية؛ قبل تنفيذ init للحاوية، فإن LXC يطلب تبديلًا لملف ضبط الحاوية؛ افتراضيًا، هذا الضبط هو السياسة lxc-container-default المعرَّفة في ملف الضبط ‎/etc/apparmor.d/lxc/lxc-default. يمنع هذا الضبط الحاوية من الوصول إلى مسارات خطرة، ومن وصل أغلبية أنظمة الملفات.

لا يمكن تقييد البرامج في الحاوية أكثر من ذلك؛ فعلى سبيل المثال، خادوم MySQL الذي يعمل ضمن نطاق الحاوية (مما يحمي المضيف) لا يمكن أن يدخل في نطاق ملف ضبط MySQL (لحماية الحاوية).

لا يدخل lxc-execute ضمن سلطة AppArmor، لكن الحاوية التي يُنشِئها (spawn) ستكون مقيدةً.

تعديل سياسات الحاوية

إذا وجدت أن lxc-start لا يعمل بسبب تقييد في الوصول من سياسة AppArmor، فيمكنك تعطيل ملف ضبط lxc-start بتنفيذ:

sudo apparmor_parser -R /etc/apparmor.d/usr.bin.lxc-start
sudo ln -s /etc/apparmor.d/usr.bin.lxc-start /etc/apparmor.d/disabled/

هذا سيجعل lxc-start يعمل دون قيود، لكن ستبقى الحدود موجودةً للحاوية نفسها، وإذا أردت إزالة التقييد عن الحاوية، فعليك بالإضافة إلى تعطيل ملف الضبط usr.bin.lxc-start أن تضيف السطر:

lxc.aa_profile = unconfined

إلى ملف ضبط الحاوية. يأتي LXC مع سياسات بديلة للحاويات، فإذا أردت إنشاء حاويات داخل حاويات (تشعب)، فعليك استخدام ملف الضبط lxc-container-default-with-nasting بإضافة السطر الآتي إلى ملف ضبط الحاوية:

lxc.aa_profile = lxc-container-default-with-nesting

إذا أردت استخدام libvirt داخل الحاويات، فستحتاج إلى تعديل تلك السياسة (المعرفة في ‎‎/etc/apparmor.d/lxc/lxc-default-with-nasting) وإزالة التعليق عن السطر الآتي:

mount fstype=cgroup -> /sys/fs/cgroup/**,

ثم أعد تحميل السياسة.

لاحظ أن سياسة التشعب للحاويات ذات الامتيازات هي أقل أمانًا من السياسة الافتراضية، حيث تسمح للحاويات بإعادة وصل ‎/sys و ‎/proc في أمكان غير قياسية، مما يتجاوز سياسة AppArmor؛ لا تملك الحاويات دون امتيازات هذا التأثير الجانبي، ﻷن جذر الحاوية لا يمكنه الكتابة إلى ملفات proc و sys المملوكة من الجذر.

إذا أردت تشغيل الحاوية بملف ضبط مخصص، فبإمكانك إنشاء ملف ضبط في ‎/etc/apparmor.d/lxc، ويجب أن يبدأ اسمه بالكلمة lxc-‎ لكي يُسمَح لبرنامج lxc-start بالانتقال إليه؛ ملف lxc-default يتضمن إعادة استعمال الملف المجرد ‎/etc/apparmor.d/abstraction/lxc/container-base؛ طريقة سهلة لإنشاء ملف ضبط جديد هي فعل المثل، ثم إضافة الأذونات الإضافية في نهاية السياسة.

حَمِّل الضبط الجديد بعد إنشاءه كما يلي:

sudo apparmor_parser -r /etc/apparmor.d/lxc-containers

سيُحمَّل هذا الضبط تلقائيًا بعد إعادة الإقلاع، ﻷنه يُقرَأ من الملف ‎/etc/apparmor.d/lxc-containers؛ وفي النهاية ولجعل الحاوية CN تستخدم ملف الضبط الجديد lxc-CN-profile، فأضف السطر الآتي إلى ملف الضبط:

lxc.aa_profile = lxc-CN-profile

مجموعات التحكم

إن مجموعات التحكم (cgroups) هي ميزة من ميزات النواة توفر تجميع للمهام تجميعًا هيكليًا، وإسناد وتحديد الموارد لكل مجموعة تحكم؛ تُستخدَم في الحاويات للحد من الوصول إلى الأجهزة الكتلية أو المحرفية (block or character devices) وتجمِّد عمل الحاويات؛ يمكن استعمالها أيضًا لتحديد استخدام الذاكرة وإيقاف الدخل أو الخرج، وضمانة استخدام أصغري للمعالج، والسماح للحاوية بالوصول إلى معالجات محددة.

افتراضيًا، سيُسند للحاوية CN ذات امتيازات مجموعةُ تحكمٍ باسم ‎/lxc/CN؛ وفي حال حدوث تضارب بالاسم (الذي قد يحدث عند استخدام lxcpaths مخصصة)، فستُضاف لاحقة «‎-n» حيث n هو رقم صحيح يبدأ من الصفر، ويُسنَد إلى اسم مجموعة التحكم.

افتراضيًا، سيُسند للحاوية CN دون امتيازات مجموعة تحكم باسم CN في مجموعة التحكم الخاصة بالمهمة التي بدأت الحاوية، على سبيل المثال ‎/usr/1000.user/1.session/CN سيُمنَح جذر الحاوية ملكية المجموعة للمجلد (لكن ليس جميع الملفات)، وهذا ما سيسمح بإنشاء مجموعات تحكم فرعية.

وفي أوبنتو 14.04، يستخدم LXC مدير مجموعات التحكم cgmanager لإدارة مجموعات التحكم؛ يستقبل مدير مجموعات التحكم طلبات D-Bus عبر مقبس يونكس ‎/sys/fs/cgroup/cgmanager/sock؛ يجب أن يُضاف السطر الآتي لاستخدام آمن للحاويات المتشعبة:

lxc.mount.auto = cgroup

إلى ملف ضبط الحاوية، مما يصل المجلد ‎/sys/fs/cgroup/cgmanager وصلًا ترابطيًا (bind-mounted) إلى الحاوية؛ ويجب على الحاوية في المقابل تشغيل وسيط إدارة مجموعات التحكم (ويتم ذلك افتراضيًا إذا كانت الحزمة cgmanager مثبتةً على الحاوية) الذي سينقل المجلد ‎/sys/fs/cgroup/cgmanager إلى ‎/sys/fs/cgroup‎/cgmanager.lower ثم سيبدأ الاستماع إلى الطلبات للوسيط على مقبسه ‎/sys/fs/cgroup ‎/cgmanager‎/sock؛ سيتأكد مدير مجموعات التحكم في المضيف أن الحاويات المتشعبة لن تستطيع «الهروب» من مجموعات التحكم المُسندَة إليها أو إنشاء طلبات غير مصرح لها بها.

الاستنساخ

للتزويد السريع بالحاويات، ربما تريد تخصيص حاوية تبعًا لحاجاتك ثم تُنشِئ عدَّة نسِخٍ منها؛ ويمكن فعل ذلك بالبرنامج lxc-clone.

الاستنساخ إما أن يكون عبر snapshots أو بنسخ حاوية أخرى؛ فالنسخ هو إنشاء حاوية جديدة منسوخة من الأصلية، وتأخذ مساحة تخزينية مثل الحاوية الأصلية؛ أما snapshot فإنها تستخدم قدرة آلية التخزين على إنشاء snapshots لإنشاء حاوية النسخ-عند-الكتابة (copy-on-write) تُشير إلى الحاوية الأولى؛ يمكن إنشاء snapshots للحاويات المخزنة في btrfs، و LVM، و zfs، وتلك التي تكون مخزنة في مجلدات؛ حيث كل آلية تخزين لها خصوصياتها؛ فمثلًا، حاويات LVM التي ليست thinpool-provisioned لا تدعم إنشاء snapshots من snapshots؛ ولا يمكن حذف حاويات zfs مع snapshots قبل أن تُطلَق (release) جميع snapshots؛ ويجب أن يُخطط جيدًا لحاويات LVM فقد لا يدعم نظام الملفات أن يزيد حجمه. لا يعاني btrfs من تلك السلبيات، لكنه يعاني من أداء fsync منخفض يسبب جعل dpkg و apt-get أبطئ.

تُنشَأ snapshots من الحاويات المخزنة في مجلدات عبر نظام الملفات؛ فمثلًا يكون لحاوية ذات امتيازات C1 جذر نظام ملفات في ‎/var/lib/lxc/C1/rootfs، وستبدأ نسخة snapshot للحاوية C1 باسم C2 بجذر نظام الملفات للحاوية C1 موصولًا للقراءة فقط في ‎/var/lib/lxc/C2/delta0؛ كل ما يهم في هذه الحالة أنه لا يفترض أن تعمل أو تحذف الحاوية C1 أثناء عمل C2؛ من المستحسن اعتبار الحاوية C1 هي حاوية أساسية واستخدام نسخة snapshot لها فقط.

لنفترض أن لدينا حاوية باسم C1، فيمكن إنشاء نسخة منها باستخدام الأمر:

sudo lxc-clone -o C1 -n C2

يمكن إنشاء snapshot باستخدام:

sudo lxc-clone -s -o C1 -n C2

راجع صفحة دليل lxc-clone لمزيد من المعلومات.

Snapshots

LXC يدعم snapshots لتسهيل دعم نسخ snapshot لتطوير تكراري للحاوية؛ فعندما تعمل على حاوية C1 -وقبل إنشاء تغيير خطير وصعب العكس- يمكنك إنشاء snapshot:

sudo lxc-snapshot -n C1

التي هي نسخة snapshot باسم «snap0» في مجلد ‎/var/lib/lxcsnaps أو ‎$HOME/.local ‎/share/lxcsnaps، النسخة الثانية ستُسمى «snap1» وهكذا؛ يمكن عرض النسخ الموجودة حاليًا باستخدام الأمر lxc-snapshot -L -n C1، ويمكن أن تُستعاد نسخة snapshot وتمحى حاوية C1 الحالية باستخدام الأمر lxc-snapshot -r snap1 -n C1، وبعد تنفيذ أمر الاستعادة، فستبقى النسخة snap1 موجودةً.

تُدعَم snapshots لحاويات btrfs، و lvm، وzfs، و overlayfs؛ إذا استدعي الأمر lxc-snapshot على حاوية تُخزَّن في مجلد، فسيسجل خطأ وستُنشَأ نسخة copy-clone؛ وسبب ذلك أنه لو أنشأ المستخدم نسخة overlayfs snapshot لحاوية تخزن في مجلد، فسينعكس جزء من تغيرات الحاوية الأصلية على نسخة snapshot؛ إذا كنت تريد إنشاء snapshots لحاوية C1 مخزنة في مجلد، فيمكن إنشاء نسخة overlayfs للحاوية C1، ويجب ألّا تلمس C1 بعد ذلك قط، لكن يمكن أن نعدِّل overlayfs وننسخها نسخ snapshots كما نريد، أي:

lxc-clone -s -o C1 -n C2
lxc-start -n C2 -d # make some changes
lxc-stop -n C2
lxc-snapshot -n C2
lxc-start -n C2 # etc

الحاويات العابرة

«الحاويات العابرة» (Ephemeral containers) هي حاويات تستخدم لمرة واحدة فقط؛ فليكن لدينا حاوية موجودة مسبقًا باسم C1، فيمكنك إنشاء حاوية عابرة باستخدام:

lxc-start-ephemeral -o C1

ستبدأ الحاوية كنسخة snapshot للحاوية C1، وستطبع التعليمات للدخول إلى الحاوية على الطرفية، وستدمر الحاوية العابرة بعد إيقاف التشغيل، راجع صفحة الدليل lxc-start-ephemeral لمزيد من الخيارات.

ترجمة -وبتصرف- للمقال Ubuntu Server Guide: LXC.

الحاويات (containers) هي تقنية أنظمة وهمية خفيفة؛ حيث تجنح لأن تكون شبيهةً بطريقة chroot محسّنة بدلًا من كونها تقنية أنظمة وهمية كاملة مثل Qemu أو VMware؛ لأن كلاهما لا يحاكي العتاد ولأن الحاويات تشارك نفس نظام التشغيل للمضيف؛ لذلك من الأفضل مقارنة الحاويات إلى «نطاقات سولارس» (Solaris zones) أو «سجون BSD» ‏(BSD jails). إن Linux-vserver و OpenVZ هما نسختان من الحاويات لنظام لينُكس مطورتان بشكل منفصل عن بعضهما؛ في الواقع، ظهرت الحاويات نتيجةً للعمل على تطوير وظائف vserver و OpenVZ.

هنالك نسختان في «مجال المستخدم» (user-space) للحاويات تستخدمان نفس مزايا النواة؛ تسمح Libvirt باستخدام الحاويات عبر محرك LXC بالاتصال إلى «lxc:///‎»، قد يكون هذا أمرًا ملائمًا لأنها تملك نفس طريقة الاستخدام الموجودة في المحركات الأخرى. النسخة الأخرى المُسماة ببساطة «LXC» هي غير متوافقة مع libvirt؛ لكنها أكثر مرونةً بأدوات أكثر في مجال المستخدم؛ من الممكن التبديل بين النسختين آنفتَيّ الذكر، لكن هنالك بعض الخصوصيات التي قد تسبب ارتباكًا.

سنشرح في هذا الدرس حزمة lxc شرحًا رئيسيًا، حيث أن استخدام libvirt-lxc ليس مستحسنًا ﻷنه يفتقر إلى حماية AppArmor لحاويات libvirt-lxc؛ وستكون أسماء الحاويات الموجودة في هذا الفصل هي CN، أو C1، أو C2.

التثبيت

يمكن تثبيت حزمة lxc باستخدام الأمر:

sudo apt-get install lxc

سنحتاج إلى تنزيل الاعتماديات المطلوبة والمستحسنة، وضبط جسر الشبكة لكي يستخدمه الحاويات؛ إذا أردت استخدام حاويات دون امتيازات، فربما تحتاج إلى أن تتأكد أن للمستخدمِين امتيازات subuids و subgids، وتريد أن تسمح للمستخدمين بوصل الحاويات إلى جسر؛ راجع القسم «الاستخدام الأساسي دون امتيازات».

الاستخدام الأساسي

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

الاستخدام الأساسي بامتيازات

لإنشاء حاوية ذات امتيازات، كل ما عليك فعله هو تنفيذ الأمر:

sudo lxc-create --template download --name u1

أو بشكل مختصر:

sudo lxc-create -t download -n u1

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

sudo lxc-create -t download -n u1 -- --dist ubuntu --release trusty --arch amd64

أو

sudo lxc-create -t download -n u1 -- -d ubuntu -r trusty -a amd64

يمكنك الآن استخدام lxc-ls لعرض قائمة بالحاويات، و lxc-info للحصول على معلومات مفصلة عن حاوية، و lxc-start لبدء و lxc-stop لإيقاف الحاوية؛ بينما يسمح لك الأمران lxc-attach و lxc-console بالدخول إلى حاوية إذا لم يكن الاتصال إليها عبر SSH متاحًا؛ والأمر lxc-destory يحذف الحاوية، بما في ذلك جذر نظام الملفات؛ راجع صفحات الدليل للأوامر السابقة للمزيد من المعلومات؛ أمثلة:

sudo lxc-ls --fancy
sudo lxc-start --name u1 --daemon
sudo lxc-info --name u1
sudo lxc-stop --name u1
sudo lxc-destroy --name u1

مجالات أسماء المستخدم

تسمح الحاويات دون امتيازات للمستخدمين بإنشاء وإدارة الحاويات دون الحصول على امتيازات الجذر؛ أساس هذه الميزة هو ما يسمى «مجالات أسماء المستخدم» (user namespaces)، إن مجالات أسماء المستخدم هيكليةٌ، حيث تكون المهام ذات امتيازات في مجال الأسماء الأب قادرة على ربط معرِّفاتها إلى مجالات أسماء الأبناء؛ افتراضيًا، كل مهمة على المضيف تعمل في مجال أسماء مبدئي (initial user namespace)، حيث المجال الكامل لمعرفاتها مربوطٌ مع المجال الكامل؛ يمكن مشاهدة ذلك بالنظر إلى ‎/proc/self/uid_map و ‎/proc/self ‎/gid_map؛ اللذان سيظهران القيمة «‎‎0 0 4294967295‎» عندما يُقرأ من مجال الأسماء المبدئي؛ وفي أوبنتو 14.04، المستخدمون الجدد الذين يُنشؤون يكون لهم افتراضيًا مجال من معرفات المستخدم؛ هذه القائمة من المعرفات المُسنَدة يمكن أن تُشاهد في الملفين ‎/etc/subuid و ‎/etc/subgid؛ انظر إلى صفحات الدليل الموافقة لهم للمزيد من المعلومات؛ ويبدأ subuid و subgid عرفيًا من المعرف 100000 لتجنب التضارب مع مستخدمي النظام.

إذا أُنشِئ المستخدم في إصدارة قديمة، فيمكنك منحه مجالًا من المعرفات باستخدام usermod، كما يلي:

sudo usermod -v 100000-200000 -w 100000-200000 user1

برنامجا newuidmap و newgidmap هما برنامجا setuid-root في حزمة uidmap، اللذان يُستخدمان داخليًا بواسطة lxc لربط subuids و subgids من المضيف إلى حاوية دون امتيازات؛ ويتأكدان من أن المستخدم يربط المعرفات المصرَّح بها فقط من ضبط المضيف.

الاستخدام الأساسي دون امتيازات

لإنشاء حاويات دون امتيازات، فإن هنالك خطوات أولية ضرورية؛ حيث تحتاج إلى إنشاء ملف ضبط حاوية افتراضي، مُحدِّدًا ربط المعرفات الذي تريده وضبط الشبكة، بالإضافة إلى ضبط المضيف للسماح لمستخدم دون امتيازات بالارتباط إلى شبكة المضيف؛ يفترض المثال الآتي أنك ربطت معرفات المستخدم والمجموعة ذات المجال 100000 – 165536.

mkdir -p ~/.config/lxc
echo "lxc.id_map = u 0 100000 65536" > ~/.config/lxc/default.conf
echo "lxc.id_map = g 0 100000 65536" >> ~/.config/lxc/default.conf
echo "lxc.network.type = veth" >> ~/.config/lxc/default.conf
echo "lxc.network.link = lxcbr0" >> ~/.config/lxc/default.conf
echo "$USER veth lxcbr0 2" | sudo tee -a /etc/lxc/lxc-usernet

بعد ذلك، يمكنك إنشاء حاويات دون امتيازات بنفس طريقة إنشاء حاويات بامتيازات، لكن ببساطة دون sudo:

lxc-create -t download -n u1 -- -d ubuntu -r trusty -a amd64
lxc-start -n u1 -d
lxc-attach -n u1
lxc-stop -n u1
lxc-destroy -n u1

التشعب

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

lxc.mount.auto = cgroup
lxc.aa_profile = lxc-container-default-with-nesting

سيسبب السطر الأول بدمج مقبس مدير مجموعات التحكم في الحاوية، لذلك سيكون lxc داخل الحاوية قادرًا على إدارة مجموعات التحكم للحاويات المتشعبة الخاصة به؛ أما السطر الثاني فيسبب تشغيل الحاوية بوضع أكثر سماحيةً بالنسبة إلى AppArmor، مما يسمح للحاوية بإجراء عمليات الوصل اللازمة لبدء تشغيل الحاويات؛ لاحظ أن سياسة AppArmor التي ستُطبَّق أقل أمنًا من السياسة العادية أو سياسة حاوية دون امتيازات؛ راجع القسم «AppArmor» في هذا الدرس القادم لمزيدٍ من المعلومات.

الضبط العام

تُستخدَم ملفات الضبط الآتية من LXC؛ للاستخدام ذو الامتيازات، فإنها ستتواجد في مجلد ‎/etc/lxc، بينما للاستخدام دون امتيازات فستكون موجودةً في ‎~/.config/lxc.

• lxc.conf: يُحدِّد اختياريًا القيم البديلة لمختلف خيارات ضبط lxc، بما فيها lxcpath، والضبط الافتراضي، ومجموعات التحكم التي ستُستخدَم، ونمط إنشاء مجموعة تحكم، وإعدادات الواجهات الخلفية لتخزين lvm و zfs.
• default.conf: يحدد الضبط الذي يجب أن يحتويه كل ملف ضبط للحاويات المُنشأة حديثًا؛ يحتوي هذا الملف عادةً على الأقل على قسم للشبكة؛ ويحتوي على قسم لربط المعرفات للمستخدمين دون امتيازات.
• lxc-usernet.conf: يحدد كيف يوصل المستخدمون دون امتيازات حاوياتهم إلى شبكة مملوكة من المضيف.

الملفان lxc.conf و default.conf موجودان في ‎/etc/lxc و ‎$HOME/.config/lxc؛ بينما الملف lxc-usernet.conf هو ملف لعموم المضيف.

افتراضيًا، تقبع الحاويات في مجلد ‎/var/lib/lxc بالنسبة للمستخدم الجذر، و ‎$HOME/.local/share/lxc عدا ذلك؛ يمكن تحديد المسار لجميع أوامر lxc باستخدام المعامل «‎-P|--lxcpath».

ضبط الشبكة

افتراضيًا، يُنشِئ LXC مجال أسماء شبكي خاص لكل حاوية، الذي يتضمن مجموعة الاتصال الشبكي من الطبقة الثانية (layer 2)، تتصل الحاويات عادةً إلى العالم الخارجي إما بالحصول على بطاقة شبكية فيزيائية، أو عبر نفق veth يُمرَّر إلى الحاوية؛ ينُشِئ LXC جسر NAT، الذي هو lxcbr0 عند إقلاع المضيف؛ والحاويات المُنشَأة باستخدام ملف الضبط الافتراضي سيكون لها بطاقة شبكية veth تكون نهايتها موصولةٌ إلى الجسر lxcbr0، يمكن للبطاقة الشبكية أن تتواجد في مجال أسماء واحد في وقتٍ واحد، لذلك البطاقة الشبكية الفيزيائية المُمررة إلى الحاوية ستكون غير قابلة للاستخدام في المضيف.

من الممكن إنشاء حاويات دون مجال أسماء شبكي خاص، ففي هذه الحالة، ستحصل الحاوية على وصول إلى شبكة المضيف مثل أي تطبيق آخر، لاحظ أنه هذا خطير خصوصًا إذا كانت الحاوية تُشغِّل توزيعة تستخدم upstart، مثل أوبنتو، لأن البرامج التي «تتحدث» إلى init، مثل shutdown، سيتحدثون عبر مقبس مجال يونكس مجرد (abstract Unix domain socket) إلى upstart للمضيف، مما سيوقف تشغيل المضيف!

لمنح الحاويات في lxcbr0 عنوان IP ثابت بناءً على اسم المضيف، فيمكنك كتابة هذه المدخلات إلى ‎/etc/lxc/dnsmasq.conf:

dhcp-host=lxcmail,10.0.3.100
dhcp-host=ttrss,10.0.3.101

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

 iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 587 -j DNAT \
 	--to-destination 10.0.3.100:587

طريقة أخرى هي إنشاء جسر إلى إلى البطاقة الشبكية للمضيف (راجع درس ضبط الشبكة لمزيدٍ من المعلومات)؛ ثم حدد جسر المضيف في ملف ضبط الحاوية بدلًا من lxcbr0، فمثلًا:

lxc.network.type = veth
lxc.network.link = br0

في النهاية، يمكنك سؤال LXC ليستخدم macvlan كبطاقة شبكية للحاوية؛ لاحظ أن لهذه الطريقة حدود واعتمادًا على الضبط قد لا تتمكن الحاوية من «التحدث» إلى المضيف نفسه، وبالتالي الخياران السابقان أفضل ويُستخدمان أكثر.

هنالك عدِّة طرق لتحديد عنوان IP للحاوية، فأولًا، يمكنك استخدام lxc-ls --fancy الذي سيطبع عناوين IP لجميع الحاويات التي تعمل؛ أو lxc-info -i -H -n C1 الذي سيطبع عنوان IP للحاوية C1؛ إذا كان dnsmasq مثبتًا على المضيف، فيمكنك إضافة قيد إلى ‎/etc/dnsmasq.conf كما يلي:

server=/lxc/10.0.3.1

بعد أن يستبين dnsmasq عنوان C1.lxc محليًا، فيمكنك تنفيذ:

ping C1
ssh C1

للمزيد من المعلومات، راجع صفحة دليل lxc.conf ومثال ضبط الشبكة في ‎/usr/share/doc/lxc ‎/examples/‎.

ترجمة -وبتصرف- للمقال Ubuntu Server Guide: LXC.

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

تقنية الأنظمة الوهمية الافتراضية المدعومة في أوبنتو هي KVM، تتطلب KVM ملحقات لدعم الأنظمة الوهمية في عتاد Intel و AMD؛ وتقنية Xen مدعومة أيضًا في أوبنتو؛ حيث يمكن أن تستفيد Xen من تلك الملحقات عند توفرها، لكن يمكن تشغيلها على عتاد دون إضافات الأنظمة الوهمية؛ خيار شائع أخر هو Qemu للعتاد بدون ملحقات الأنظمة الوهمية (virtualization extensions).

libvirt

تُستخدَم المكتبة libvirt للتعامل مع مختلف تقنيات الأنظمة الوهمية؛ وقبل البدء مع libvirt، من الأفضل التحقق أنّ عتادك يدعم الملحقات الضرورية لعمل KVM، وذلك بإدخال الأمر الآتي في الطرفية:

kvm-ok

ستظهر رسالة تعلِمك إن كان معالجك يدعم أو لا يدعم الملحقات العتادية للأنظمة الوهمية.

ملاحظة: يكون من الضروري في أغلب الحواسيب التي تدعم معالجاتها الأنظمة الوهمية أن يفعَّل خيارٌ في BIOS لتمكينها.

التواصل الشبكي الوهمي

هنالك عدِّة طرق للسماح لنظام وهمي بالوصول إلى الشبكة الخارجية؛ خيار ضبط التواصل الشبكي الوهمي الافتراضي هو «usermode»، الذي يستخدم بروتوكول SLIRP ويمرِّر التراسل الشبكي عبر NAT عبر بطاقة المضيف إلى الشبكة الخارجية.

لتمكين وصول المضيفين الخارجيين إلى الخدمات مباشرةً على الأنظمة الوهمية، فيجب استخدام ضبط «bridge»؛ هذا يسمح للبطاقات الشبكية الوهمية بالاتصال إلى الشبكة الخارجية عبر البطاقة العتادية، مما يجعلها تبدو كأنها حواسيب عادية لبقية الشبكة.

التثبيت

أدخِل ما يلي في الطرفية لتثبيت الحزم اللازمة:

sudo apt-get install kvm libvirt-bin

يجب إضافة المستخدم الذي سيدير الآلات الوهمية إلى مجموعة libvirtd بعد تثبيت libvirt-bin؛ وبهذا تعطي المستخدم وصولًا إلى خيارات الشبكة المتقدمة؛ وذلك بإدخال الأمر الآتي:

sudo adduser $USER libvirtd

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

أنت الآن جاهز لتثبيت نظام تشغيل «ضيف» (Guest)؛ طريقة تثبيت نظام التشغيل على الآلات الوهمية هي نفس طريقة تثبيته مباشرةً على العتاد؛ أي أنك إما أن تحتاج إلى أتمتة التثبيت، أو إلى لوحة مفاتيح وشاشة موصولين إلى الآلة الفيزيائية.

في حالة الآلات الوهمية، تكون الواجهة الرسومية (GUI) مماثلة لاستخدام لوحة مفاتيح وفأرة فيزيائية؛ فبدلًا من تثبيت واجهة رسومية، يمكن استخدام التطبيق virt-viewer للاتصال إلى الآلة الوهمية باستخدام VNC، راجع القسم «عارض الآلات الوهمية» لمزيدٍ من التفاصيل.

هنالك عدِّة طرق لأتمتة تثبيت أوبنتو، إذ يمكن ذلك باستخدام preseed أو kickstart على سبيل المثال. راجع دليل تثبيت أوبنتو للتفاصيل.

طريقة أخرى لتثبيت أوبنتو على آلة افتراضية هي استخدام ubuntu-vm-builder، يسمح ubuntu-vm-builder بإعداد متقدم للأقسام، وتنفيذ سكربتات بعد التثبيت ...إلخ. للتفاصيل، راجع القسم «الصور السحابية وأداة uvtools».

يمكن ضبط Libvirt مع Xen، راجع صفحة مجتمع أوبنتو المُشار إليها في المصادر.

virt-install

virt-install هو جزء من حزمة virtinst، أدخِل الأمر الآتي لتثبيتها:

sudo apt-get install virtinst

هنالك عدِّة خيارات متوفرة عند استخدام virt-install:

sudo virt-install -n web_devel -r 256 \
--disk path=/var/lib/libvirt/images/web_devel.img,bus=virtio,size=4 -c \
ubuntu-14.04-server-i386.iso --network network=default,model=virtio \
--graphics vnc,listen=0.0.0.0 --noautoconsole -v

• الخيار ‎-n web_devel: اسم الآلة الوهمية، سيكون web_devel في هذا المثال.
• الخيار ‎-r 256: تحديد مقدار الذاكرة التي ستستخدمها الآلة الوهمية مقدرًا بالميغابايت.
• الخيار ‎--disk path=/var/lib/libvirt/images/web_devel.img,size=4: الإشارة إلى مسار القرص الوهمي الذي يمكن أن يكون ملفًا أو قسمًا أو حجمًا وهميًا؛ في هذا المثال هنالك ملف باسم web_devel.img في مجلد ‎/var/lib/libvirt/images/‎ بحجم 4 غيغابايت، وسيستخدم virtio كناقل للقرص (disk bus).
• الخيار ‎:-c ubuntu-14.04-server-i386.iso الملف الذي سيُستخدَم كقرص CD-ROM وهمي، يمكن أن يكون الملف إما ملف ISO أو مسار إلى جهاز قرص CD-ROM في المضيف.
• الخيار ‎--network: يوفر معلومات حول البطاقة الشبكية للآلة الوهمية؛ يُستخدَم هنا default، وضُبِط موديل البطاقة إلى virtio.
• الخيار ‎--graphics vnc,listen=0.0.0.0: تصدير طرفية الضيف باستخدام VNC على جميع البطاقات الشبكية للمضيف؛ إذ عمومًا لا يكون للخادوم واجهة رسومية، لذلك فيمكن لحاسوب آخر على الشبكة المحلية ذي واجهةٍ رسومية أن يتصل عبر VNC لإكمال التثبيت.
• الخيار ‎--noautoconsole: يؤدي إلى عدم الاتصال تلقائيًا إلى طرفية الآلة الوهمية.
• الخيار ‎-v: إنشاء ضيف وهمي كامل.

بعد تشغيل virt-install يمكنك الاتصال إلى طرفية الآلة الوهمية إما محليًا باستخدام GUI أو باستخدام الأداة virt-viewer.

virt-clone

يمكن استخدام virt-clone لنسخ آلة وهمية إلى آلة أخرى؛ على سبيل المثال:

sudo virt-clone -o web_devel -n database_devel -f /path/to/database_devel.img \
--connect=qemu:///system

• ‎-o: الآلة الوهمية الأصلية.
• ‎-n: اسم الآلة الوهمية الجديدة.
• ‎-f: المسار إلى الملف، أو القسم، أو الحجم المنطقي الذي سيُستخدَم من الآلة الوهمية الجديدة.
• ‎--connect: تحديد «المشرف» (hypervisor) الذي سيُتصَّل به.

يمكن أيضًا استخدام الخيار ‎-d أو ‎--debug لاستكشاف الأخطاء مع virt-clone.

ملاحظة: استبدل web_devel و database_devel بأسماء ملائمة للآلات الوهمية.

إدارة الآلة الوهمية

virsh

هنالك عدِّة أدوات متوفرة لإدارة الآلات الوهمية و libvirt؛ يمكن أن تُستخدَم الأداة virsh من سطر الأوامر؛ هذه بعض الأمثلة:

• لعرض قائمة بالآلات الوهمية التي تعمل:

virsh -c qemu:///system list

• لبدء تشغيل آلة وهمية:

virsh -c qemu:///system start web_devel

• وبشكلٍ مشابه، لتشغيل آلة وهمية عند الإقلاع:

virsh -c qemu:///system autostart web_devel

• أعد إقلاع آلة وهمية باستخدام الأمر:

virsh -c qemu:///system reboot web_devel

• يمكن حفظ «حالة» (state) الآلة الوهمية إلى ملف لتُستعاد لاحقًا؛ ما يلي سوف يحفظ حالة الآلة الوهمية إلى ملف مسمى وفقًا لتاريخ اليوم:

virsh -c qemu:///system save web_devel web_devel-022708.state

ستتوقف الآلة الوهمية عن العمل بعد حفظ حالتها.

• يمكن استعادة الآلة الوهمية باستخدام:

virsh -c qemu:///system restore web_devel-022708.state

• نفِّذ الأمر لإيقاف تشغيل آلة وهمية:

virsh -c qemu:///system shutdown web_devel

• يمكن وصل جهاز CD-ROM إلى آلة وهمية بالأمر:

virsh -c qemu:///system attach-disk web_devel /dev/cdrom /media/cdrom

ملاحظة: استبدل في الأمثلة السابقة web_devel مع اسم الآلة الوهمية الملائم، و web_devel-022708.state باسم ملف أكثر وصفًا.

مدير الآلات الوهمية

تحتوي حزمة virt-manager على أداة رسومية لإدارة الآلات الوهمية المحلية والبعيدة؛ أدخِل الأمر الآتي لتثبيتها:

sudo apt-get install virt-manager

لما كانت الأداة virt-manager تتطلب واجهة رسومية (GUI) فمن المستحسن أن تُثبَّت على محطة عمل أو جهاز للاختبارات بدلًا من خادوم إنتاجي؛ أدخِل الأمر الآتي للاتصال بخدمة libvirt محلية:

virt-manager -c qemu:///system

تستطيع الاتصال بخدمة libvirt في مضيف آخر بإدخال ما يلي في الطرفية:

virt-manager -c qemu+ssh://virtnode1.mydomain.com/system

ملاحظة: يفترض المثال السابق أن إمكانية الاتصال عبر SSH بين نظام الإدارة و virtnode1.mydomain.com قد ضُبِطَت مسبقًا، وتستخدم مفاتيح SSH للاستيثاق؛ هنالك حاجة لمفاتيح SSH لأن المكتبة libvirt تُرسِل محث كلمة المرور إلى عملية أخرى. للتفاصيل عن ضبط SSH، راجع درس خادوم OpenSSH.

عارض الآلات الوهمية

يسمح التطبيق virt-viewer لك بالاتصال إلى طرفية الآلة الوهمية لكن virt-viewer يتطلب واجهة رسومية (GUI) للتعامل مع الآلة الوهمية، أدخِل الأمر الآتي من الطرفية لتثبيت virt-viewer:

sudo apt-get install virt-viewer

بعد تثبيت وتشغيل آلة وهمية، يمكنك الاتصال إلى طرفيتها بالأمر:

virt-viewer -c qemu:///system web_devel

وكما في virt-manager، يمكن اتصال virt-viewer إلى مضيف بعيد باستخدام SSH مع استيثاق باستخدام مفتاح:

virt-viewer -c qemu+ssh://virtnode1.mydomain.com/system web_devel

تأكد من استبدال web_devel باسم الآلة الوهمية الملائم.

إذا ضبطت استخدام بطاقة شبكية جسرية (bridged network interface)، فيمكنك ضبط وصول SSH إلى الآلة الوهمية؛ راجع درس خادوم OpenSSH لمزيدٍ من المعلومات.

مصادر

• راجع صفحة KVM الرئيسية للمزيد من التفاصيل.
• للمزيد من المعلومات حول libvirt، انظر إلى صفحة libvirt الرئيسية.
• موقع «Virtual Machine Manager» فيه المزيد من المعلومات حول تطوير virt-manager.
• ادخل إلى قناة ‎#ubuntu-virt على خادوم freenode لمناقشة تقنيات الأنظمة الوهمية في أوبنتو.
• مصدر آخر جيد هو صفحة ويكي أوبنتو «KVM».
• للمزيد من المعلومات حول Xen، بما فيها استخدام Xen مع libvirt؛ رجاءً راجع صفحة ويكي أوبنتو «Xen».

إن Bacula هو برنامج للنسخ الاحتياطي يسمح لك بالنسخ والاستعادة والتحقق من البيانات عبر الشبكة؛ هنالك عملاء Bacula للينُكس وويندوز وماك OS X؛ مما يجعله حلًّا متعدد المنصات للنسخ الاحتياطي.

لمحة

يتألف Bacula من عدِّة مكونات وخدمات تُستخدَم لإدارة أيّة ملفات لتُنسَخ وأماكن النسخ:

• Bacula Director: خدمة تتحكم بجميع عمليات النسخ الاحتياطي والاستعادة والتحقق والأرشفة.
• Bacula Console: برنامج يسمح بالتواصل مع Director؛ هنالك ثلاثة إصدارات من Console:
  • نسخة نصية تعتمد على سطر الأوامر.
  • واجهة رسومية متناغمة مع غنوم وتَستخدم GTK+‎.
  • واجهة رسومية تعتمد على wxWidgets.
• Bacula File: ويُعرَف أيضًا بعميل Bacula؛ يُثبَّت هذا التطبيق على الأجهزة التي ستُنسَخ احتياطيًا، وهو مسؤول عن البيانات التي تُطلَب من Director.
• Bacula Storage: التطبيق الذي يجري عملية تخزين واستعادة البيانات من وإلى الوسائط التخزينية.
• Bacula Catalog: مسؤول عن صيانة فهارس الملفات وقواعد بيانات الحجوم لجميع الملفات التي نُسِخَت احتياطيًا، مما يُمكِّن تحديد المكان والاستعادة السريعة للملفات المؤرشفة؛ يدعم Catalog ثلاثة محركات قواعد بيانات مختلفة هي MySQL و PostgreSQL و SQLite.
• Bacula Monitor: يسمح بمراقبة عمل Director، وعفاريت الملفات والتخزين؛ يتوفر Monitor حاليًا كتطبيق GTK+‎ فقط.

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

التثبيت

ملاحظة: إذا كنت تستخدم MySQL أو PostgreSQL كقاعدة بيانات، فيجب أن تملك أولًا تلك الخدمات؛ إذ لن يثبتها Bacula.

هنالك عدِّة حزم تحتوي على مختلف مكونات Bacula، أدخِل الأمر الآتي لتثبيت Bacula:

sudo apt-get install bacula

يَستخدم التثبيت الافتراضي لحزمة bacula قاعدة بيانات MySQL لتطبيق Catalog؛ إذا أردت استخدام SQLite أو PostgreSQL لتطبيق Catalog، فثبِّت الحزمة bacula-director-sqlite3 أو bacula-director-pgsql على التوالي وبالترتيب.

ستُسأل أثناء التثبيت عن توفير تصاريح لمدير قاعدة البيانات ومالك قاعدة بيانات bacula؛ سيحتاج مدير قاعدة البيانات إلى امتلاك الأذونات الملائمة لإنشاء قاعدة بيانات؛ راجع درس قواعد البيانات لمزيدٍ من المعلومات.

الضبط

ملفات ضبط Bacula منسقة بناءً على «موارد» تشتمل على «تعليمات» محاطة بقوسين معقوفين «{}»؛ ولكل مكون من مكونات Bacula ملف منفصل في مجلد ‎/etc/bacula.

يجب أن تُصرِّح مختلف مكونات Bacula عن نفسها لبعضها بعضًا؛ وهذا يتم باستخدام التعليمة password؛ على سبيل المثال، كلمة مرور مورد Storage في ملف ‎/etc/bacula/bacula-dir.conf يجب أن تُطابِق كلمة مرور Director في ‎/etc/bacula/bacula-sd.conf.

افتراضيًا، تكون هنالك مهمة نسخ احتياطي اسمها Client1 لأرشفة Bacula Catalog؛ إذا كنت تخطط لاستخدام الخادوم للنسخ الاحتياطي لأكثر من عميل، فعليك تعديل اسم هذه المهمة إلى شيء أكثر وصفًا؛ لتغيير الاسم، عدِّل الملف ‎/eth]lc/bacula/bacula-dir.conf:

#
# Define the main nightly save backup job
#   By default, this job will back up to disk in 
Job {
  Name = "BackupServer"
  JobDefs = "DefaultJob"
  Write Bootstrap = "/var/lib/bacula/Client1.bsr"
}

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

يمكن استخدام Console لإنشاء طلبية لبرمجية Director عن المهام؛ لكن لكي تستخدم Console بمستخدم غير جذر، فيجب أن تضيف المستخدم لمجموعة bacula؛ وذلك بإدخال الأمر الآتي في الطرفية:

sudo adduser $username bacula

ملاحظة: استبدل ‎$username باسم المستخدم الفعلي؛ وإذا أضفت المستخدم الحالي إلى المجموعة، فعليك تسجيل الخروج ثم إعادة تسجيل الدخول مرةً أخرى لتأخذ الأذونات الجديدة مفعولها.

نسخة احتياطية محلية

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

• أولًا، يجب ضبط جهاز Storage؛ وذلك بتعديل الملف ‎/etc/bacula/bacula-sd.conf وإضافة:

Device {
  Name = "Tape Drive"
  Device Type = tape
  Media Type = DDS-4
  Archive Device = /dev/st0
  Hardware end of medium = No;
  AutomaticMount = yes;               # when device opened, read it
  AlwaysOpen = Yes;
  RemovableMedia = yes;
  RandomAccess = no;
  Alert Command = "sh -c 'tapeinfo -f %c | grep TapeAlert'"
}

هذا المثال يستخدم شريطًا ممغنطًا من نوع DDS-4؛ عدِّل قيمة Media Type و Archive Device لتُطابِق عتادك.

يمكنك أيضًا إزالة التعليق عن أحد الأمثلة في الملف.

• بعد تعديل ‎/etc/bacula/bacula-ds.conf، فيجب إعادة تشغيل عفريت Storage:

sudo service bacula-sd restart

• أضف الآن مورد Storage إلى ملف ‎/etc/bacula/bacula-dir.conf لاستخدام الجهاز الجديد:

# Definition of "Tape Drive" storage device
Storage {
  Name = TapeDrive
  # Do not use "localhost" here    
  Address = backupserver               # N.B. Use a fully qualified name here
  SDPort = 9103
  Password = "Cv70F6pf1t6pBopT4vQOnigDrR0v3LT3Cgkiyjc"
  Device = "Tape Drive"
  Media Type = tape
}

يجب أن تكون قيمة التعليمة Address هي الاسم الكامل للنطاق (FQDN) للخادوم؛ عدِّل backupserver إلى اسم المضيف الحقيقي.

تأكد أيضًا أن التعليمة Password تُطابِق قيمة السلسلة النصية password في ‎/etc/bacula ‎/bacula-sd.conf.

• أنشِئ FileSet جديد، الذي سيُحدِّد المجلدات التي ستُأخذ نسخة احتياطية لها، وذلك بإضافة:

# LocalhostBacup FileSet.
FileSet {
  Name = "LocalhostFiles"
  Include {
    Options {
      signature = MD5
      compression=GZIP
    }
    File = /etc
    File = /home
  }
}

سيُنسخ المجلدان ‎/etc و ‎/home احتياطيًا، تعليمات Options تضبط FileSet لإنشاء بصمة MD5 لكل ملف يُنسَخ احتياطيًا؛ ولضغط الملفات باستخدام gzip.

• الآن، أنشِئ Schedule (للجدولة) لمهمة النسخ:

# LocalhostBackup Schedule -- Daily.
Schedule {
  Name = "LocalhostDaily"
  Run = Full daily at 00:01
}

ستعمل مهمة النسخ الاحتياطي كل يوم في تمام الساعة 00:01 أو 12:01‎ ‎AM؛ تتوفر العديد من خيارات الجدولة الإضافية.

• في النهاية، أنشِئ Job:

# Localhost backup.
Job {
  Name = "LocalhostBackup"
  JobDefs = "DefaultJob"
  Enabled = yes
  Level = Full
  FileSet = "LocalhostFiles"
  Schedule = "LocalhostDaily"
  Storage = TapeDrive
  Write Bootstrap = "/var/lib/bacula/LocalhostBackup.bsr"
}  

مما سينسخ نسخةً كاملةً كل يوم إلى الشريط الممغنط.

• كل شريط ممغنط مستخدم يجب أن تكون له لافتة (Label)، إذا لم يكن للشريط الحالي لافتةٌ، فسيرسل Bacula بريدًا إلكترونيًا لجعلك تعلم بذلك؛ لضبط لافتة لشريط باستخدام Console، فعليك إدخال الأمر الآتي:

bconsole

• وفي برنامج Bacula Console، أدخِل:

label

• ثم ستُسأل عن مورد Storage:

Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
The defined Storage resources are:
     1: File
     2: TapeDrive
Select Storage resource (1-2):2

• أدخِل اسم الحجم الجديد:

Enter new Volume name: Sunday
Defined Pools:
     1: Default
     2: Scratch

استبدل Sunday باسمٍ ملائم.

• الآن اختر Pool:

Select the Pool (1-2): 1
Connecting to Storage daemon TapeDrive at backupserver:9103 ...
Sending label command for Volume "Sunday" Slot 0 ...

تهانينا! لقد ضبطت Bacula لنسخ جهازك المحلي احتياطيًا إلى شريط ممغنط.

مصادر

• لمزيد من المعلومات حول خيارات ضبط Bacula، راجع «Bacula User's Manual».
• تحتوي صفحة Bacula الرئيسية على آخر أخبار تطوير Bacula.
• أيضًا، راجع صفحة ويكي أوبنتو «Bacula».

ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Bacula.

هنالك عدِّة طرق لنسخ تثبيت أوبنتو احتياطيًا؛ أهم ما هنالك بالنسبة إلى النسخ الاحتياطية هو تطوير «خطة نسخ احتياطي» تحتوي على ماذا سيُنسَخ احتياطيًّا، وأين سيُنسَخ، وكيف سيُسترجَع.

ستشرح الأقسام الآتية طرقًا مختلفة لإنجاز هذه المهام.

سكربتات شل

إحدى أبسط الطرق لنسخ نظام احتياطيًّا هي استخدام «سكربت شِل» (shell script)؛ على سبيل المثال، يمكن أن يُستخدَم سكربت لضبط أيّة مجلدات يجب أن تُنسَخ احتياطيًّا، وتُمرَّر هذه المجلدات كوسائط إلى الأداة tar، التي ستُنشِئ ملف أرشيف؛ ويمكن أن يُنقَل ذاك الملف أو ينُسَخ إلى مكانٍ آخر؛ ويمكن أن يُنشَأ أيضًا الأرشيف في نظام بعيد عبر NFS.

الأداة tar تُنشِئ ملف أرشيف واحد من عدِّة ملفات أو مجلدات؛ يمكن أيضًا للأداة tar تمرير الملفات عبر أدوات ضغط، وهذا سيؤدي بدوره إلى تقليل حجم ملف الأرشيف.

سكربت شِل بسيط

السكربت الآتي يستخدم tar لإنشاء ملف أرشيف في نظام ملفات NFS موصول عن بعد؛ يُحدَّد اسم الأرشيف باستخدام أدوات إضافية تعمل من سطر الأوامر:

#!/bin/bash
####################################
#
# Backup to NFS mount script.
#
####################################

# What to backup. 
backup_files="/home /var/spool/mail /etc /root /boot /opt"

# Where to backup to.
dest="/mnt/backup"

# Create archive filename.
day=$(date +%A)
hostname=$(hostname -s)
archive_file="$hostname-$day.tgz"

# Print start status message.
echo "Backing up $backup_files to $dest/$archive_file"
date
echo

# Backup the files using tar.
tar czf $dest/$archive_file $backup_files

# Print end status message.
echo
echo "Backup finished"
date

# Long listing of files in $dest to check file sizes.
ls -lh $dest

• ‎$backup_files: متغير يحتوي على قائمة بأيّة مجلدات تود أن تنسخها احتياطيًّا؛ يجب تعديل هذه القائمة لتناسب احتياجاتك.
• ‎$day: متغير يحتوي على اسم اليوم من الأسبوع (مثل Monday، أو Tuesday، أو Wednesday ...إلخ.)؛ وسيُستخدَم لإنشاء ملف أرشيف لكل يوم من الأسبوع، مما يعطي تاريخًا للنسخ الاحتياطي هو سبعة أيام؛ هنالك طرقٌ أخرى للقيام بذلك بما فيها استخدام الأداة date.
• ‎$hostname: متغير يحتوي على الاسم القصير للمضيف؛ استخدام اسم المضيف في اسم ملف الأرشيف يُمكِّنك من وضع ملفات الأرشيف اليومية من عدِّة خواديم في نفس المجلد.
• ‎$archive_file: الاسم الكامل لملف الأرشيف.
• ‎$dest: الوجهة التي سيُخزَّن فيها ملف الأرشيف؛ يجب أن يكون المجلد موجودًا وفي هذه الحالة موصولًا قبل تنفيذ أمر النسخ الاحتياطي؛ راجع درس «نظام ملفات الشبكة (NFS)» لمزيدٍ من التفاصيل حول استخدام NFS.
• status messages: الرسائل الاختيارية التي ستُطبَع إلى الطرفية باستخدام الأمر echo.
• tar czf $dest/$archive_file $backup_files: أمر tar المُستخدَم لإنشاء ملف الأرشيف.
  • الخيار c: إنشاء أرشيف.
  • الخيار z: تمرير الملف الناتج عبر الأداة gzip لضغط الأرشيف.
  • الخيار f: الإخراج إلى ملف أرشيف؛ عدا ذلك، سيُرسِل الأمر tar مخرجاته إلى مجرى الخرج القياسي.
• ls -lh $dest: عبارة اختيارية تطبع قائمة تفصيلية (‎-l) بتنسيق سهل القراءة للبشر (‎-h) لمحتويات مجلد الهدف، هذا الأمر مفيدٌ للتحقق السريع من الحجم التخزيني لملف الأرشيف؛ هذا التحقق ليس بديلًا عن اختبار ملف الأرشيف نفسه!

هذا مثالٌ بسيطٌ عن سكربت شِل للنسخ الاحتياطي؛ لكن هنالك العديد من الخيارات التي يمكن تضمينها في مثل هكذا سكربت، راجع قسم «مصادر» في هذا الدرس للحصول على روابط تُوفِّر معلومات تفصيلية عن كتابة سكربتات شِل.

تنفيذ السكربت

• التنفيذ من الطرفية: أبسط طريقة لتنفيذ سكربت النسخ الاحتياطي السابق هي نسخ ولصق محتوياته في ملف باسم backup.sh على سبيل المثال، ثم تنفيذ ما يلي من الطرفية:

sudo bash backup.sh

هذه طريقة رائعة لاختبار أن كل شيء يعمل على ما يرام في السكربت.

• التنفيذ عبر المهام المجدولة (cron): يمكن استخدام الأداة cron ﻷتمتة تنفيذ السكربت، يسمح عفريت cron بتنفيذ السكربتات أو الأوامر في أوقات وتواريخ محددة مسبقًا.

يُضبَط cron عبر قيود في ملف crontab؛ تنقسم ملفات crontab إلى حقول:

# m h dom mon dow command

• الحقل m: الدقيقة التي سيُنفَّذ عندها الأمر؛ تتراوح القيمة بين 0 و 59.
• الحقل h: الساعة التي سيُنفَّذ عندها الأمر؛ تتراوح القيمة بين 0 و 23.
• الحقل dom: يوم الشهر الذي سينُفَّذ عنده السكربت.
• الحقل mon: الشهر الذي سيُنفَّذ عنده السكربت، بين 1 و 12.
• الحقل dow: يوم الأسبوع الذي سيُنفَّذ عنده الأمر، تتراوح قيمته بين 0 و 7؛ حيث يمكن تحديد يوم الأحد باستخدام 0 أو 7، حيث يجوز استخدام كلا القيمتين.
• الحقل command: الأمر الذي سيُنفَّذ.

يجب استخدام الأمر crontab -e لإضافة أو تعديل المدخلات في ملف crontab؛ أيضًا يجب عرض محتويات الملف crontab باستخدام الأمر crontab -l.

أدخِل الأمر الآتي في الطرفية لتنفيذ سكربت backup.sh السابق باستخدام cron:

sudo crontab -e

ملاحظة: استخدام sudo مع الأمر crontab -e سيُعدِّل جدول المهام للمستخدم الجذر؛ هذا ضروريٌ إذا كنت تنسخ مجلدات احتياطيًا لا يملك وصولًا إليها عدا المستخدم الجذر.

أضف القيد الآتي إلى ملف crontab:

# m h dom mon dow command
0 0 * * * bash /usr/local/bin/backup.sh

يجب أن يُنفَّذ سكربت backup.sh كل يوم في تمام الساعة 12:00 AM.

ملاحظة: يجب نسخ سكربت backup.sh إلى مجلد ‎/usr/local/bin لكي يعمل القيد السابق عملًا صحيحًا؛ يمكن أن يقبع السكربت في أي مكان في نظام الملفات، وكل ما عليك فعله هو تعديل المسار المذكور في القيد أعلاه بما يلائم مكان وجوده.

الاستعادة من أرشيف

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

• يمكنك تنفيذ الأمر الآتي لعرض قائمة بمحتويات الأرشيف:

tar -tzvf /mnt/backup/host-Monday.tgz

• لاستعادة ملف من الأرشيف إلى مجلد مختلف، أدخِل الأمر:

tar -xzvf /mnt/backup/host-Monday.tgz -C /tmp etc/hosts

يوجه الخيار ‎-C الأمر tar ليستخرج الملفات إلى مجلد محدد؛ حيث سيستخرج الأمر السابق الملف ‎/etc/hosts إلى ‎/tmp/etc/hosts؛ يعيد tar إنشاء هيكلة المجلدات التي تحتوي الملفات.

لاحظ أيضًا أن الشرطة المائلة / في أول المسار قد أزيلت من المسار المُستخرَج إليه.

• لاستعادة كل الملفات من الأرشيف، أدخِل الأمرين:

cd /
sudo tar -xzvf /mnt/backup/host-Monday.tgz

ملاحظة: سيكتب الأمر السابق فوق الملفات في نظام الملفات.

مصادر

• للمزيد من المعلومات حول كتابة سكربتات الشِل، راجع «Advanced Bash-Scription Guide».
• كتاب «Teach Yourself Shell Programming in 24 Hours» متوفر على الإنترنت، وهو مصدر ممتاز يشرح كتابة سكربتات الشِل.
• صفحة الويكي «CronHowto» تحتوي على تفاصيل عن خيارات cron المتقدمة.
• راجع دليل GNU tar للمزيد من خيارات tar.
• صفحة ويكيبيديا «Bachup Rotation Scheme» تحتوي على معلومات عن أنماط أخرى للنسخ الاحتياطي.
• يستخدم سكربت الشِل الأداةَ tar لإنشاء الأرشيف، لكن هنالك أدواتٌ سطريةٌ أخرى يمكن استعمالها، على سبيل المثال:
  • cpio: يُستخدَم لنسخ الملفات إلى ومن الأرشيفات.
  • dd: جزء من حزمة coreutils، الذي هو أداة منخفضة المستوى تستطيع نسخ البيانات من صيغة لأخرى.
  • rsnapshot: أداة لأخذ snapshot لنظام الملفات تُستخدَم لإنشاء نسخ من كامل نظام الملفات.
  • rsync: أداة مرنة تُستخدَم لإنشاء نسخ تراكمية من الملفات.
• وبالطبع، كتاب «سطر أوامر لينُكس» يحتوي على شرحٍ تفصيلي لأغلبية المواضيع التي ناقشناها هاهنا.

دورة الأرشيف

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

دورة أرشيفات NFS

سنعدِّل في هذا القسم السكربت السابق لتطبيق مخطط الجد-الأب-الابن (شهريًا-أسبوعيًا-يوميًا):

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

هذا هو السكربت:

#!/bin/bash
####################################
#
# Backup to NFS mount script with
# grandfather-father-son rotation.
#
####################################

# What to backup. 
backup_files="/home /var/spool/mail /etc /root /boot /opt"

# Where to backup to.
dest="/mnt/backup"

# Setup variables for the archive filename.
day=$(date +%A)
hostname=$(hostname -s)

# Find which week of the month 1-4 it is.
day_num=$(date +%d)
if (( $day_num <= 7 )); then
        week_file="$hostname-week1.tgz"
elif (( $day_num > 7 && $day_num <= 14 )); then
        week_file="$hostname-week2.tgz"
elif (( $day_num > 14 && $day_num <= 21 )); then
        week_file="$hostname-week3.tgz"
elif (( $day_num > 21 && $day_num < 32 )); then
        week_file="$hostname-week4.tgz"
fi

# Find if the Month is odd or even.
month_num=$(date +%m)
month=$(expr $month_num % 2)
if [ $month -eq 0 ]; then
        month_file="$hostname-month2.tgz"
else
        month_file="$hostname-month1.tgz"
fi

# Create archive filename.
if [ $day_num == 1 ]; then
	archive_file=$month_file
elif [ $day != "Saturday" ]; then
        archive_file="$hostname-$day.tgz"
else 
	archive_file=$week_file
fi

# Print start status message.
echo "Backing up $backup_files to $dest/$archive_file"
date
echo

# Backup the files using tar.
tar czf $dest/$archive_file $backup_files

# Print end status message.
echo
echo "Backup finished"
date

# Long listing of files in $dest to check file sizes.
ls -lh $dest/

يمكن تنفيذ هذا السكربت بنفس آلية التنفيذ في القسم السابق «تنفيذ السكربت».

عادة جيدة هي أخذ وسائط تخزين النسخ الاحتياطية خارج مكان العمل تحسبًا لوقوع كارثة؛ في مثال سكربت الشِل؛ وسيط التخزين هو خادوم آخر يوفر مشاركة NFS؛ في مثل هذه الحالة، لن يكون خيارًا عمليًا نقل خادوم NFS إلى موقع آخر؛ لكن بناءً على سرعة الاتصال يمكنك نسخ ملف الأرشيف عبر خط WAN إلى خادوم في مكان آخر.

خيار آخر هو نسخ ملف الأرشيف على قرص صلب خارجي يمكن أن يؤخذ بعد ذلك خارج الموقع؛ ولما كانت أسعار الأقراص الصلبة الخارجية تستمر بالانخفاض، فربما يكون ملائمًا استخدام قرصين صلبين لكل مستوى من مستويات الأرشفة؛ هذا سيسمح بوجود قرص صلب خارجي موصول إلى خادوم النسخ الاحتياطي، وآخر في مكانٍ بعيد.

محركات الأشرطة الممغنطة

يمكن استخدام شريط ممغنط (tape) بدلًا من مشاركة NFS، يُسهِّل استخدام الأشرطة الممغنطة دورات الأرشيفات؛ ويجعل أخذ وسائط التخزين خارج الموقع أمرًا هينًا.

القسم الخاص باسم الملف في السكربت لن يكون ضروريًا عند استخدام الأشرطة، لأن البيانات تُرسَل مباشرةً إلى الشريط؛ هنالك حاجة لبعض الأوامر للتعديل على الأشرطة، يتم ذلك باستخدام الأداة mt، التي تُستخدَم للتحكم بالأشرطة الممغنطة وهي جزء من حزمة cpio.

هذا هو سكربت الشِل المعدَّل لاستخدام شريط ممغنط:

#!/bin/bash
####################################
#
# Backup to tape drive script.
#
####################################

# What to backup. 
backup_files="/home /var/spool/mail /etc /root /boot /opt"

# Where to backup to.
dest="/dev/st0"

# Print start status message.
echo "Backing up $backup_files to $dest"
date
echo

# Make sure the tape is rewound.
mt -f $dest rewind

# Backup the files using tar.
tar czf $dest $backup_files

# Rewind and eject the tape.
mt -f $dest rewoffl

# Print end status message.
echo
echo "Backup finished"
date

ملاحظة: اسم الجهاز الافتراضي لشريط SCSI ممغنط هو ‎/dev/st0؛ استخدم مسار الجهاز الملائم لنظامك في السكربت السابق.

الاستعادة من شريط ممغنط هي نفس عملية الاستعادة من ملف؛ ببساطة أعد لَفّ الشرط واستخدم مسار الجهاز بدلًا من مسار ملف؛ على سبيل المثال، لاستعادة ملف ‎/etc/hosts إلى ‎/tmp/etc/hosts:

mt -f /dev/st0 rewind
tar -xzf /dev/st0 -C /tmp etc/hosts

ترجمة -وبتصرف- للمقالين Ubuntu Server Guide; Shell Scripts و Ubuntu Server Guide: Archive Rotation.

سنناقش في هذا الدرس كيفية تثبيت وضبط خادوم IRC‏ (ircd-irc2) وسنناقش أيضًا كيفية تثبيت وضبط خادوم المراسلة الفورية Jabber.

خادوم IRC

يحتوي مستودع أوبنتو على العديد من خواديم IRC، يشرح هذا القسم كيفية تثبيت وضبط خادوم IRC الأصلي ircd-irc2.

التثبيت

أدخِل الأمر الآتي في الطرفية لتثبيت خادوم ircd-irc2:

sudo apt-get install ircd-irc2

يُخزَّن ملف الضبط في مجلد ‎/etc/ircd، والتوثيق متوفرٌ في مجلد ‎/usr/share/doc/ircd-irc2.

الضبط

يمكن أن تُضبَط إعدادات IRC بملف الضبط ‎/etc/ircd/ircd.conf؛ يمكنك ضبط اسم مضيف IRC بتعديل السطر الآتي:

M:irc.localhost::Debian ircd default configuration::000A

رجاءً تأكد أنك تضيف أسماء DNS البديلة لاسم مضيف IRC؛ على سبيل المثال، إذا ضبطت irc.liveciper.com كاسم مضيف IRC؛ فتأكد أن irc.liveciper.com يُحَّل في خادوم أسماء المضيفين عندك؛ لا يتوجب أن يكون اسم مضيف IRC هو نفسه اسم مضيف الخادوم.

يمكن ضبط معلومات مدير IRC بتعديل السطر الآتي:

A:Organization, IRC dept.:Daemon <ircd@example.irc.org>:Client Server::IRCnet:

عليك إضافة أسطر خاصة لضبط قائمة بالمنافذ التي يستمع إليها IRC؛ ولضبط «الأوراق الاعتمادية للمشغل»، ولتضبط الاستيثاق من العميل ...إلخ. رجاءً ارجع إلى المثال عن ملف الضبط الموجود في ‎/usr/share/doc/ircd-irc2/ircd.conf.example.gz.

لافتة IRC هي الرسالة التي تظهر في عميل IRC عندما يتصل إلى الخادوم، ويمكن أن تُضبَط في الملف ‎/etc/ircd/ircd.motd.

بعد إجراء التعديلات الضرورية لملف الضبط، تستطيع إعادة تشغيل خادوم IRC بتنفيذ الأمر الآتي:

sudo service ircd-irc2 restart

مصادر

• ربما تكون مهتمًا بإلقاء نظرة إلى خواديم IRC الأخرى المتوفرة في مستودعات أوبنتو، التي تتضمن ircd-ircu، و ircd-hybrid.
• ارجع إلى IRCD FAQ للمزيد من التفاصيل حول خادوم IRC.

خادوم المراسلة الفورية Jabber

إن Jabber هو بروتوكول مراسلة فورية مبني على XMPP (معيار مفتوح للمراسلة الفورية) ويُستخدَم بواسطة عدِّة برمجيات مشهورة. يشرح هذا القسم طريقة إعداد خادوم Jabberd 2 على شبكة LAN محلية؛ يمكن أن يُعدَّل هذا الضبط لتوفير خدمات تبادل الرسائل فوريًا عبر الإنترنت.

التثبيت

لتثبيت jabberd2، أدخِل الأمر الآتي في الطرفية:

sudo apt-get install jabberd2

الضبط

هنالك ملفَيّ ضبط XML يُستخدَمان لضبط Jabberd2 لاستيثاق Berkeley DB من المستخدم؛ هذا شكل بسيط جدًا من أشكال الاستيثاق؛ لكن يمكن ضبط Jabberd2 لكي يَستخدم LDAP، أو MySQL، أو PostgreSQL ...إلخ. للاستيثاق من المستخدم.

أولًا، عدِّل الملف ‎/etc/jabberd2/sm.xml مغيّرًا:

<id>jabber.example.com</id>

ملاحظة: استبدل jabber.example.com باسم المضيف أو بمعرِّف ID آخر لخادومك.

الآن في قسم <storage>، عدِّل قيمة <driver> إلى:

<driver>db</driver>

ثم في ملف ‎/etc/jabberd2/c2s.xml، عدِّل في قسم <local>:

<id>jabber.example.com</id>

وعدِّل أيضًا <module> في قسم <authreg> إلى:

<module>db</module>

في النهاية، أعد تشغيل خدمة jabberd2 لتفعيل الضبط الجديد:

sudo service jabberd2 restart

يمكنك الآن الاتصال إلى الخادوم باستخدام عميل Jabber مثل بيدجن (Pidgin) على سبيل المثال.

ملاحظة: ميزة استخدام Berkeley DB لمعلومات المستخدم هو أنها لا تحتاج إلى صيانة إضافية بعد ضبطها؛ إذا أردت المزيد من التحكم في حسابات المستخدمين، فمن المستحسن استخدام آلية استيثاق أخرى.

مصادر

• يحتوي موقع Jabberd2 على المزيد من التفاصيل حول ضبط Jabberd2.
• للمزيد من خيارات الاستيثاق، راجع «Jabberd2 Install Guide».
• أيضًا، هنالك بعض المعلومات في صفحة ويكي أوبنتو «Setting Up Jabber Server».

ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Chat Applications.

حقوق الصورة البارزة: Designed by Freepik.

CUPS هي الآلية الرئيسية للطباعة وخدمات الطباعة في أوبنتو وهي «النظام الشائع للطباعة في يونكس» (Common UNIX Printing System اختصارًا CUPS)، نظام الطباعة هذا هو طبقة محمولة متوفرة مجانًا التي أصبحت المعيار القياسي الجديد للطباعة في غالبية توزيعات لينُكس.

يدير CUPS مهام الطباعة والطلبيات ويوفر خدمات طباعة عبر الشبكة باستخدام «بروتوكول الطباعة عبر الإنترنت» (Internet Printing Protocol اختصارًا IPP)، بينما يوفر CUPS دعمًا لمجالٍ واسعٍ جدًا من الطابعات، بدءًا من طابعات مصفوفة النقط (dot-matrix) إلى الطابعات الليزرية وما بينهما؛ ويدعم CUPS أيضًا «PostScript Printer ‎Description»‏‎‏ (PPD) والاكتشاف التلقائي لطابعات الشبكة، ويوفر واجهة ويب بسيطة كأداة للضبط والإدارة.

التثبيت

أدخل الأمر الآتي في الطرفية لتثبيت CUPS:

sudo apt-get install cups

سيعمل خادوم CUPS تلقائيًا بعد نجاح التثبيت.

ولاستكشاف الأخطاء، يمكنك الوصول إلى أخطاء خادوم CUPS عبر ملف سجل في ‎/var/log/cups ‎/error_log؛ إذا لم يُظهِر سجل الأخطاء معلوماتٍ كافيةً لحل المشاكل التي تواجهك، فيمكن زيادة درجة «الإسهاب» لسجل CUPS بتغيير التعليمة LogLevel في ملف الضبط إلى "debug" أو حتى إلى "debug2"، مما يؤدي إلى تسجيل كل شيء؛ تأكد من إعادة القيمة الافتراضية "info" بعد حل مشكلتك لتفادي زيادة حجم السجل زيادةً كبيرةً جدًا.

الضبط

يُضبَط سلوك خادوم CUPS عبر تعليمات موجودة في ملف ‎/etc/cups/cupsd.conf؛ يتبِّع ملف ضبط CUPS نفس الصيغة العامة لملف الضبط الرئيسي لخادوم أباتشي؛ سنذكر هنا بعض الأمثلة عن الإعدادات التي يمكن تغييرها.

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

انسخ الملف ‎/etc/cups/cupsd.conf واحمهِ من الكتابة بالأوامر الآتية:

sudo cp /etc/cups/cupsd.conf /etc/cups/cupsd.conf.original
sudo chmod a-w /etc/cups/cupsd.conf.original

• التعليمة ServerAdmin: لضبط عنوان البريد الإلكتروني لمدير خادوم CUPS، عليك أن تُحرِّر ملف الضبط ‎/etc/cups/cupsd.conf، ثم أضف أو عدِّل سطر ServerAdmin بما يلائمك؛ فمثلًا إن كنت أنت مدير خادوم CUPS، وكان بريدك الإلكتروني هو user@example.com، فعليك تعديل سطر ServerAdmin ليبدو كما يلي:

ServerAdmin user@example.com

• التعليمة Listen: يستمع خادوم CUPS في أوبنتو افتراضيًا على بطاقة loopback فقط على عنوان IP 127.0.0.1؛ ولكي تجعل خادوم CUPS يستمع على عنوان IP لبطاقة شبكية، فعليك تحديد إما اسم مضيف، أو عنوان IP، أو اختيارًا، عنوان IP ومنفذ؛ وذلك بإضافة التعليمة Listen؛ على سبيل المثال، لو كان خادوم CUPS يقبع على شبكة محلية بعنوان IP هو 192.168.10.250 وتريد أن تجعله متاحًا لبقية الأنظمة على هذه الشبكة الفرعية؛ فعليك تعديل ‎/etc/cups/cupsd.conf؛ وإضافة التعليمة Listen، كما يلي:

Listen 127.0.0.1:631 # existing loopback Listen
Listen /var/run/cups/cups.sock # existing socket Listen
Listen 192.168.10.250:631 # Listen on the LAN interface, Port 631 (IPP)

قد تحذف أو تضع تعليقًا قبل الإشارة إلى عنوان loopback‏ (127.0.0.1) إذا لم ترغب في أن يستمع cupsd إلى هذه البطاقة لكنك تريده أن يستمع فقط إلى بطاقة إيثرنت للشبكة المحلية LAN؛ لتفعيل الاستماع لكل منافذ الشبكة بما فيها loopback لمضيف معيّن، فتستطيع إنشاء قيد Listen لاسم المضيف (socrates) كما يلي:

Listen socrates:631 # Listen on all interfaces for the hostname 'socrates'

أو بحذف التعليمة Listen واستخدام Port عوضًا عنها:

Port 631 # Listen on port 631 on all interfaces

للمزيد من الأمثلة عن تعليمات الضبط لخادوم CUPS، راجع صفحة الدليل الخاصة بملف الضبط بإدخال الأمر الآتي:

man cupsd.conf

ملاحظة: في كل مرة تُعدِّل فيها على ملف الضبط ‎/etc/cups/cupsd.conf؛ فستحتاج إلى إعادة تشغيل خادوم CUPS بكتابة الأمر التالي في الطرفية:

sudo service cups restart

واجهة الويب

ملاحظة: يمكن أن يُضبَط ويُراقَب CUPS باستخدام واجهة ويب، التي تتوفر افتراضيًا على http://localhost:631/admin؛ يمكن استخدام واجهة الويب لإجراء كل مهام إدارة الطابعة.

لكي تنفذ المهام الإدارية عبر واجهة الويب، فعليك إما تفعيل حساب الجذر على خادومك، أو الاستيثاق كمستخدم في المجموعة lpadmin؛ ولأسبابٍ أمنية، لن يستوثق CUPS من مستخدم لا يملك كلمة مرور.

لإضافة مستخدم إلى المجموعة lpadmin، فعليك تنفيذ الأمر الآتي في الطرفية:

sudo usermod -aG lpadmin username

يتوفر توثيق في لسان Documentation/Help في واجهة الويب.

مصادر

• موقع CUPS الإلكتروني.

ترجمة -وبتصرف- للمقال Ubuntu Server Guide: CUPS - Print Server.

نظام ملفات الشبكة (NFS)

يسمح NFS للنظام بمشاركة المجلدات والملفات مع الآخرين عبر الشبكة؛ إذ يمكن للمستخدمين والبرامج الوصول إلى الملفات في الأنظمة البعيدة كأنها ملفاتٌ محلية باستخدام NFS.

بعض الميزات الملحوظة التي يوفرها استخدام NFS:

• محطات العمل المحلية تستهلك مساحة قرص أقل ﻷنها تستخدم بيانات يمكن تخزينها على جهاز واحد وتبقى متاحةً للبقية عبر الشبكة.
• لا توجد حاجة ليُنشَأ للمستخدمين مجلدات منزل منفصلة في كل جهاز شبكي؛ حيث يمكن ضبط مجلدات المنزل على خادوم NFS وتتوفر للجميع عبر الشبكة.
• أجهزة التخزين مثل سواقات CD-ROM وأقراص USB يمكن استخدامها من الأجهزة الأخرى على الشبكة، وربما يقلل هذا من عدد مشغلات الوسائط القابلة للإزالة في الشبكة.

التثبيت

أدخل الأمر الآتي في الطرفية لتثبيت خادوم NFS:

sudo apt-get install nfs-kernel-server

الضبط

تستطيع ضبط المجلدات لكي «تُصدَّر» عبر إضافتها لملف ‎/etc/exports، على سبيل المثال:

/ubuntu *(ro,sync,no_root_squash)
/home *(rw,sync,no_root_squash)

تستطيع استبدال * بإحدى صيغ أسماء المضيفين، تأكد من أن تعريف اسم المضيف محدد كي لا تستطيع الأنظمة غير المعنية أن تصل إلى NFS.

نفِّذ الأمر الآتي في مِحَث الطرفية لتشغيل خادوم NFS:

sudo service nfs-kernel-server start

ضبط عميل NFS

استخدم الأمر mount لوصل مجلد NFS مشترك من جهاز لآخر؛ وذلك بكتابة أمرٍ شبيه بالأمر الآتي في الطرفية:

sudo mount example.hostname.com:/ubuntu /local/ubuntu

تحذير: يجب أن تكون نقطة الوصل ‎/local/ubuntu موجودةً مسبقًا، ولا يجب أن يكون هنالك أيّة ملفات أو مجلدات فرعية في نقطة الوصل.

طريقة أخرى لوصل مشاركة NFS من جهاز لآخر هي إضافة سطر إلى ملف ‎/etc/fstab؛ يجب أن يُحدِّد هذا السطر اسم مضيف خادوم NFS، والمجلد الذي صُدِّرَ من الخادوم، والمجلد في الجهاز المحلي الذي يجب وصل NFS إليه؛ الشكل العام للسطر الذي سيُضاف إلى ملف ‎/etc/fstab هو:

example.hostname.com:/ubuntu /local/ubuntu nfs rsize=8192,wsize=8192,timeo=14,intr

إذا حدثت معك مشكلة في وصل NFS، فتأكد أن الحزمة nfs-common مثبتة في نظام عميلك؛ وذلك بإدخال الأمر الآتي في الطرفية:

sudo apt-get install nfs-common

مصادر

• Linux NFS faq
• صفحة ويكي أوبنتو «NFS Howto»

«مبادر»‏ iSCSI‏

إن iSCSI‏ (Internet Small Computer System Interface) هو بروتوكول يسمح بنقل أوامر SCSI عبر الشبكة؛ عادةً يُستخدَم iSCSI في SAN‏ (Storage Area Network) للسماح للخواديم بالوصول إلى مخزن كبير لمساحة القرص الصلب؛ يُشير بروتوكول iSCSI للعملاء «بالمبادرين» (initiators) ولخواديم iSCSI بالأهداف (targets).

يمكن أن يُضبَط خادوم أوبنتو كمبادر أو هدف iSCSI، يوفر هذا الدرس الأوامر والضبط اللازم لإعداد مبادر iSCSI، على فرض أنك تملك هدف iSCSI في شبكتك وتملك الامتيازات المناسبة للاتصال إليه؛ التعليمات حول إعداد هدف تختلف اختلافًا كبيرًا بين مزودي العتاد، لذلك راجع توثيق الشركة لضبط هدف iSCSI الذي عندك.

تثبيت مبادر iSCSI

لضبط خادوم أوبنتو كمبادر iSCSI، فثبِّت الحزمة open-iscsi بإدخال الأمر الآتي:

sudo apt-get install open-iscsi

ضبط مبادر iSCSI

بعد أن تُثبَّت حزمة open-iscsi، عليك تعديل الملف ‎/etc/iscsi/iscsid.conf مغيرًا ما يلي:

node.startup = automatic

تستطيع التأكد إذا كان الهدف متوفرًا حاليًا باستخدام الأداة iscsiadm؛ وذلك بإدخال الأمر الآتي في الطرفية:

sudo iscsiadm -m discovery -t st -p 192.168.0.10

• ‎-m: يحدد النمط الذي سيُنفَّذ فيه iscsiadm.
• ‎-t: يحدد نوع الاستكشاف.
• ‎-p: يحدد عنوان IP للهدف.

ملاحظة: عدِّل 192.168.0.10 إلى عنوان IP للهدف على شبكتك المحلية.

إذا كان الهدف متوفرًا، فيجب أن تشاهد مخرجات شبيهة بما يلي:

192.168.0.10:3260,1 iqn.1992-05.com.emc:sl7b92030000520000-2

ملاحظة: قد يختلف رقم iqn وعنوان IP في الأعلى بناءً على العتاد الذي تستخدمه.

يجب أن تكون الآن قادرًا على الاتصال بهدف iSCSI، واعتمادًا على إعدادات الهدف، فربما تحتاج لإدخال بيانات المستخدم لتسجيل الدخول إلى عقدة iSCSI:

sudo iscsiadm -m node --login

تأكد الآن أن القرص الجديد قد عُثِرَ عليه باستخدام dmesg:

dmesg | grep sd

[   4.322384] sd 2:0:0:0: Attached scsi generic sg1 type 0
[   4.322797] sd 2:0:0:0: [sda] 41943040 512-byte logical blocks:(21.4GB/20.0 GiB)
[   4.322843] sd 2:0:0:0: [sda] Write Protect is off
[   4.322846] sd 2:0:0:0: [sda] Mode Sense: 03 00 00 00
[   4.322896] sd 2:0:0:0: [sda] Cache data unavailable
[   4.322899] sd 2:0:0:0: [sda] Assuming drive cache: write through
[   4.323230] sd 2:0:0:0: [sda] Cache data unavailable
[   4.323233] sd 2:0:0:0: [sda] Assuming drive cache: write through
[   4.325312] sda: sda1   sda2 < sda5 >
[   4.325729] sd 2:0:0:0: [sda] Cache data unavailable
[   4.325732] sd 2:0:0:0: [sda] Assuming drive cache: write through
[   4.325735] sd 2:0:0:0: [sda] Attached SCSI disk
[2486.941805] sd 4:0:0:3: Attached scsi generic sg3 type 0
[2486.952093] sd 4:0:0:3: [sdb] 1126400000 512-byte logical blocks: (576 GB/537 ↪ GiB)
[2486.954195] sd 4:0:0:3: [sdb] Write Protect is off
[2486.954200] sd 4:0:0:3: [sdb] Mode Sense: 8f 00 00 08
[2486.954692] sd 4:0:0:3: [sdb] Write cache: disabled, read cache: enabled, ↪ doesn't support DPO or FUA
[2486.960577] sdb: sdb1
[2486.964862] sd 4:0:0:3: [sdb] Attached SCSI disk

في الناتج أعلاه، يكون sdb هو قرص iSCSI الجديد؛ تذكر أن هذا مجرد مثال، قد يختلف الناتج عمّا تراه على الشاشة.

أنشِئ الآن قسمًا، وهيّء نظام الملفات، وصِل قرص iSCSI الجديد؛ وذلك بإدخال ما يلي في الطرفية:

sudo fdisk /dev/sdb
n
p
enter
w

ملاحظة: الأوامر الآتية من داخل الأداة fdisk؛ راجع man fdisk لتعليمات تفصيلية؛ أيضًا الأداة cfdisk في بعض الأحيان تكون «صديقة» للمستخدم أكثر.

هيّء الآن نظام الملفات وصِله إلى ‎/srv على سبيل المثال:

sudo mkfs.ext4 /dev/sdb1
sudo mount /dev/sdb1 /srv

في النهاية، أضف مدخلة إلى ‎/etc/fstab لوصل قرص iSCSI أثناء الإقلاع:

/dev/sdb1 /srv ext4 defaults,auto,_netdev 0 0

فكرة جيدة هي التأكد أن كل شيء يعمل على ما يرام قبل إعادة تشغيل الخادوم.

مصادر

• موقع Open-iSCSI الإلكتروني.
• صفحة ويكي دبيان «Open-iSCSI».

ترجمة -وبتصرف- للمقالين: Ubuntu Server Guide: Network File System NFS و Ubuntu Server Guide: ISCSI Initiator.

إذا كان لديك أكثر من حاسوب في نفس الشبكة، فعند حدٍّ معيَّن ستحتاج إلى مشاركة الملفات بين تلك الحواسيب.

خادوم FTP

بروتوكول نقل الملفات (File Transfer Protocol اختصارًا FTP) هو بروتوكول TCP لتنزيل الملفات بين الحواسيب؛ في الماضي، كان يُستخدم أيضًا لرفع الملفات، لكن هذه الطريقة لا توفر إمكانية التشفير، وستُنقَل معلومات المستخدم مع البيانات في صيغة سهلة التفسير؛ إذا كنت تبحث هنا عن طريقة آمنة لرفع أو تنزيل الملفات، فألقِ نظرةً على خادوم OpenSSH.

يعمل FTP وفق نمط «عميل/خادوم»؛ حيث تُسمى مكونة FTP في الخادوم «عفريت FTP»، الذي يستمع بشكل متواصل لطلبات FTP من العملاء البعيدين؛ وعند وصول طلب، فإنه يجري عملية الدخول ويُهيِّء الاتصال، وستُنفَّذ الأوامر المُرسَلة من عميل FTP أثناء مدة عمل الجلسة.

يمكن الوصول إلى خادوم FTP بإحدى الطريقتين:

• مستخدم مجهول.
• مستخدم موثوق.

في نمط المستخدم المجهول (Anonymous)؛ يمكن للعملاء البعيدين الوصول إلى خادوم FTP بحساب المستخدم الافتراضي المُسمى «anonymous» أو «ftp» ويرسلون عنوان بريد إلكتروني ككلمة مرور؛ أما في نمط المستخدم الموثوق، فيجب على المستخدم امتلاك حساب وكلمة مرور؛ الخيار الثاني غير آمن أبدًا ولا يجب أن يستخدم إلا في الحالات الخاصة؛ إذا كنت تبحث عن طريقة آمنة لنقل الملفات، فانظر إلى SFTP في OpenSSH-Server. وصول المستخدم إلى مجلدات وملفات خادوم FTP يتعلق بالأذونات المعطية للحساب أثناء تسجيل الدخول؛ وكقاعدة عامة، سيخفي عفريت FTP المجلد الجذر لخادوم FTP وسيحول المستخدم إلى مجلد منزل FTP؛ وهذا سيخفي بقية نظام الملفات من الجلسات البعيدة.

تثبيت خادوم FTP‏ ‎«vsftpd»‎

إن vsftpd هو عفريت FTP متوفر في أوبنتو، ومن السهل تثبيته وإعداده وصيانته؛ لتثبيت vsftpd، عليك تنفيذ الأمر الآتي في الطرفية:

sudo apt-get install vsftpd

ضبط الوصول المجهول لخادوم FTP

افتراضيًا، لم يُضبَط vsftpd للسماح للمستخدمين المجهولين بالتنزيل؛ إذا كنت تريد السماح لهم بالتنزيل، فعدِّل الملف ‎/etc/vsftpd.conf مغيّرًا:

anonymous_enable=Yes

سيُنشَأ مستخدم باسم ftp مع مجلد المنزل ‎/srv/ftp أثناء التثبيت؛ هذا هو مجلد FTP الافتراضي.

إذا أردت تغيير هذا المسار إلى ‎/srv/files/ftp على سبيل المثال، فببساطة أنشِئ مجلدًا في مكانٍ آخر، وغيّر مجلد المنزل للمستخدم ftp:

sudo mkdir /srv/files/ftp
sudo usermod -d /srv/files/ftp

أعد تشغيل الخدمة vsftpd بعد عمل التغيرات السابقة:

sudo restart vsftpd

في النهاية، انسخ أيّة ملفات ومجلدات تريد للمستخدمين المجهولين تنزيلها عبر ftp إلى ‎/srv/files/ftp أو إلى ‎/srv/ftp إذا أبقيت على الإعدادات الافتراضية.

ضبط FTP للاستيثاق من المستخدمين

افتراضيًا، يكون vsftpd مضبوطًا على الاستيثاق من مستخدمي النظام والسماح لهم بتنزيل الملفات؛ إذا أردت السماح للمستخدمين برفع الملفات، فعدِّل الملف ‎/etc/vsftpd.conf:

write_enable=YES

ثم أعد تشغيل vsftpd:

sudo restart vsftpd

الآن عندما يتصل مستخدمو النظام عبر FTP، فسيبدؤون في مجلد المنزل الخاص بهم، حيث يستطيعون تنزيل أو رفع الملفات أو إنشاء المجلدات ...إلخ.

وبشكلٍ مشابه، لا يُسمَح افتراضيًا للمستخدمين المجهولين برفع الملفات إلى خادوم FTP؛ لتغيير ذلك الإعداد عليك أن تُزيل التعليق عن السطر الآتي وتُعيد تشغيل خدمة vsftpd:

anon_upload_enable=YES

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

يحتوي ملف الضبط على العديد من خيارات الضبط؛ توجد معلومات حول كل خيار في ملف الضبط؛ ويمكنك مراجعة صفحة الدليل man 5 vsftpd.conf للمزيد من التفاصيل حول كل إعداد.

تأمين FTP

هنالك خيارات في ‎/etc/vsftpd.conf للمساعدة في جعل vsftpd أكثر أمانًا؛ فمثلًا يمكن أن يقيّد وصول المستخدمين إلى مجلدات المنزل الخاصة بهم بإزالة التعليق عن السطر:

chroot_local_users=YES

يمكنك أن تقيّد قائمة محددة من المستخدمين إلى مجلدات المنزل الخاصة بهم فقط:

chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list

بعد إزالة التعليق عن الخيارات السابقة؛ أنشِئ ملف ‎/etc/vsftpd.chroot_list الذي يحتوي على قائمة بالمستخدمين المسموح لهم واحدًا في كل سطر؛ ثم أعد تشغيل vsftpd:

sudo restart vsftpd

يحتوي الملف ‎/etc/ftpusers أيضًا على قائمة بالمستخدمين غير المسموح لهم بالوصول إلى FTP؛ القائمة الافتراضية تتضمن root، و daemon، و nobody ...إلخ. لتعطيل الوصول إلى FTP لمستخدمين آخرين، فأضفهم ببساطة إلى القائمة.

يمكن أن يُشفَّر FTP باستخدام FTPS، الذي يختلف عن SFTP؛ FTPS هو FTP عبر طبقة المقابس الآمنة (SSL)؛ إن SFTP هو مثل جلسة FTP عبر اتصال SSH مشفر؛ اختلاف رئيسي هو أن مستخدمي SFTP يجب أن يملكوا حساب «shell» على النظام، بدلًا من صدفة nologin؛ قد لا يكون توفير صدفة لكل المستخدمين أمرًا ملائمًا في بعض البيئات مثل خادوم ويب مشترك؛ لكن من الممكن تقييد مثل هذه الحسابات إلى SFTP فقط وتعطيل التعامل مع الصدفة، راجع درس OpenSSH لمزيدٍ من المعلومات.

لضبط FTPS، عدِّل الملف ‎/etc/vsftpd.conf وأضف في النهاية:

ssl_enable=Yes

أيضًا، لاحظ الخيارات المتعلقة بالشهادة والمفتاح:

rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key

ضُبِطَت هذه الخيارات افتراضيًا إلى الشهادة والمفتاح الموفر من الحزمة ssl-sert؛ لكن يجب استبدالهما في البيئات الإنتاجية بالشهادة والمفتاح المُولَّد لمضيف محدد؛ للمزيد من المعلومات حول الشهادات، راجع الدرس الخاص بها في هذه السلسلة.

أعد الآن تشغيل vsftpd، وسيُجبر المستخدمون غير المجهولين على استخدام FTPS:

sudo restart vsftpd

للسماح للمستخدم بصدفة ‎/usr/sbin/nologin بالوصول إلى FTP، لكن عدم امتلاك وصول للصدفة، فعدِّل ملف ‎/etc/shells مضيفًا الصدفة nologin:

# /etc/shells: valid login shells
/bin/csh
/bin/sh
/usr/bin/es
/usr/bin/ksh
/bin/ksh
/usr/bin/rc
/usr/bin/tcsh
/bin/tcsh
/usr/bin/esh
/bin/dash
/bin/bash
/bin/rbash
/usr/bin/screen
/usr/sbin/nologin

هذا ضروريٌ لأن vsftpd يستخدم PAM افتراضيًا للاستيثاق؛ والملف ‎/etc/pam.d/vsftpd يحتوي على:

auth required pam_shells.so

الصدفات التي تسمح الوحدة PAM لها بالوصول هي الصدفات المذكورة في ملف ‎/etc/shells.

يمكن ضبط أغلبية عملاء FTP الشهيرين ليتصلوا عبر FTPS. الأداة lftp التي تعمل من سطر الأوامر لها إمكانية استخدام FTPS أيضًا.

مصادر

• راجع موقع vsftpd الرسمي لمزيدٍ من المعلومات.
• لتفاصيل الخيارات في ‎/etc/vsftpd.conf راجع صفحة دليل vsftpd.conf.

ترجمة -وبتصرف- للمقال Ubuntu Server Guide: FTP Server.

تثبيت LAMP (الذي هو Linux + Apache + MySQL + PHP/Perl/Python) هو إعداد شائع لخواديم أوبنتو؛ هنالك تشكيلة واسعة جدًا من البرمجيات مفتوحة المصدر المكتوبة لتجميعة برامج LAMP؛ أشهر تلك البرمجيات هي تطبيقات الويكي، وأنظمة إدارة المحتوى، وبرمجيات الإدارة مثل phpMyAdmin.

ميزة من مزايا LAMP هي المرونة غير العادية لاستخدام قواعد بيانات أو خواديم ويب أو لغات برمجية مختلفة! بدائل شائعة لقواعد MySQL تتضمن PostgreSQL و SQLite؛ وتُستخدَم Python أو Perl أو Ruby بدلًا من PHP؛ ويَستبدل Nginx أو Cherokee أو Lighttpd الخادوم أباتشي.

أسرع طريقة للبدء في تثبيت LAMP هي استخدام tasksel؛ الأداة tasksel هي أداة خاصة بدبيان/أوبنتو التي تُثبِّت حزمًا مترابطة للقيام «بمهمة» في نظامك؛ أدخِل الأمر الأتي في الطرفية لتثبيت خادوم LAMP:

sudo tasksel install lamp-server

بعد إتمام عملية التثبيت، ستكون قادرًا على تثبيت أغلبية تطبيقات LAMP بهذه الطريقة:

• تنزيل أرشيف يحتوي على الملفات المصدرية للتطبيق.
• استخراج الملفات من الأرشيف إلى مجلد يمكن لخادوم الويب الوصول إليه.
• اعتمادًا على المكان الذي استخرجت الملفات إليه، فاضبط خادوم الويب ليُخدِّم الصفحات من هناك.
• اضبط التطبيق للاتصال بقاعدة البيانات.
• شغِّل سكربتًا، أو افتح صفحةً من التطبيق لتثبيت قاعدة البيانات التي يحتاج لها هذا التطبيق.
• بعد أن أجريت الخطوات السابقة أو خطواتٍ شبيهةٍ بها، فأنت جاهزٌ الآن للبدء باستعماله.

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

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

Moin Moin

إن MoinMoin هو محرك ويكي مكتوب بلغة بايثون ومبني على محرك الويكي PikiPiki ومرخص برخصة GUN GPL.

التثبيت

نفِّذ الأمر الآتي لتثبيت MoinMoin:

sudo apt-get install python-moinmoin

يجب أن تكون قد ثبتت خادوم أباتشي؛ رجاءً راجع درس تثبيت أباتشي لمزيدٍ من المعلومات حول تثبيت أباتشي.

الضبط

لضبط أول تطبيق ويكي خاص بك، فعليك تنفيذ سلسلة الأوامر الآتية؛ على فرض أنك تُنشِئ «ويكي» باسم mywiki:

cd /usr/share/moin
sudo mkdir mywiki
sudo cp -R data mywiki
sudo cp -R underlay mywiki
sudo cp server/moin.cgi mywiki
sudo chown -R www-data.www-data mywiki
sudo chmod -R ug+rwX mywiki
sudo chmod -R o-rwx mywiki

يجب الآن أن تضبط MoinMoin لكي يرى الويكي الجديد mywiki؛ لضبط MoinMoin، افتح الملف ‎/etc/moin/mywiki.py وعدِّل السطر الآتي:

data_dir = '/org/mywiki/data'

إلى:

data_dir = '/usr/share/moin/mywiki/data'

أيضًا، تحت الخيار data_dir، أضف الخيار data_underlay_dir:

data_underlay_dir='/usr/share/moin/mywiki/underlay'

ملاحظة: إذا لم يكن الملف ‎/etc/moin/mywiki.py موجودًا، فعليك نسخ ‎/usr/share/moin/‎config/wikifarm/mywiki.py إلى ‎/etc/moin/mywiki.py ثم تنفيذ التغيير المذكور آنفًا.

ملاحظة: إذا سميت الويكي باسم my_wiki_name، فيجب إضافة السطر:

‎("my_wiki_name",r".*") 

إلى ملف ‎/etc/moin/farmconfig.py بعد السطر:

‎("mywiki", r".*")

بعد أن تضبط MoinMoin ليعثر على أول تطبيق ويكي mywiki عليك ضبط أباتشي وجعله جاهزًا لتطبيق الويكي.

يجب أن تُضيف الأسطر الآتية في ملف ‎/etc/apache2/sites-available/default ضمن الوسم ‎<VirtualHost *>‎:

### moin
  ScriptAlias /mywiki "/usr/share/moin/mywiki/moin.cgi"
  alias /moin_static193 "/usr/share/moin/htdocs"
  <Directory /usr/share/moin/htdocs>
    Order allow,deny
    allow from all
  </Directory>
### end moin

بعد أن تضبط خادوم أباتشي وتجعله جاهزًا لتطبيق الويكي، يجب عليك أن تعيد تشغيله، وذلك بإدخال الأمر الآتي لإعادة تشغيل خادوم أباتشي:

sudo service apache2 restart

التجربة

للتأكد من عمل تطبيق الويكي، وجِّه متصفحك للوصلة الآتية:

http://localhost/mywiki

للمزيد من المعلومات، راجع موقع MoinMoin الرسمي.

مصادر

• للمزيد من المعلومات انظر إلى ويكي «moinmoin».
• أيضًا، صفحة ويكي أوبنتو «MoinMoin».

MediaWiki

إن MediaWiki هي برمجية Wiki مبنية على الويب مكتوبة بلغة PHP؛ يمكنها أن تستخدم نظام إدارة قواعد بيانات MySQL أو PostgreSQL.

التثبيت

قبل تثبيت MediaWiki، يجب عليك تثبيت أباتشي ولغة برمجة PHP5 ونظام إدارة قواعد بيانات؛ وأشهرها MySQL أو PostgreSQL، اختر واحدًا بناءً على احتياجاتك، رجاءً ارجع إلى الأقسام التي تشرح تثبيتها في هذه السلسلة للمزيد من المعلومات.

نفِّذ الأمر الآتي في الطرفية لتثبيت MediaWiki:

sudo apt-get install mediawiki php5-gd

لوظائف MediaWiki إضافية، انظر إلى الحزمة mediawiki-extensions.

الضبط

ملف ضبط أباتشي mediawiki.conf مثبَّتٌ في ‎‎/etc/apache2/conf-available/‎، يجب عليك إزالة التعليق من السطر الآتي للوصول إلى تطبيق MediaWiki:

# Alias /mediawiki /var/lib/mediawiki

بعد أن تُزيل التعليق من السطر السابق، ففعِّل الضبط ثم أعد تشغيل خادوم أباتشي ثم ادخل إلى MediaWiki عبر الرابط الآتي http://localhost/mediawiki/config/index.php:

sudo a2enconf mediawiki.conf
sudo service apache2 restart

بعد إكمال الضبط، يجب عليك أن تنقل الملف LocalSettings.php إلى المجلد ‎/etc/mediawiki:

sudo mv /var/lib/mediawiki/config/LocalSettings.php /etc/mediawiki/

ربما تريد أيضًا تعديل ‎/etc/mediawiki/LocalSettings.php لكي تضبط حد الذاكرة الأقصى (معطَّل افتراضيًا):

ini_set( 'memory_limit', '64M' );

الإضافات

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

يمكنك تنزيل إضافات MediaWiki كأرشيف أو عبر سحبها (checkout) من مستودع Subversion؛ عليك أن تنسخها إلى مجلد ‎/var/lig/mediawiki/extensions؛ يجب عليك أيضًا إضافة السطر الآتي في نهاية الملف ‎/etc/mediawiki/LocalSettings.php:

require_once "$IP/extensions/ExtentionName/ExtentionName.php";

مصادر

• للمزيد من المعلومات، رجاءً راجع موقع MediaWiki.
• يحتوي كتاب «MediaWiki Administrators’ Tutorial Guide» على معلوماتٍ قيمة لمدراء MediaWiki الجدد.
• صفحة ويكي أوبنتو «MediaWiki» هي مصدرٌ جيدٌ أيضًا.

phpMyAdmin

إن phpMyAdmin هو تطبيق LAMP مكتوب خصيصًا لإدارة خواديم MySQL، وهو مبرمج بلغة PHP، ويمكن الوصول إليه عبر متصفح الويب، حيث يوفِّر phpMyAdmin واجهة رسومية لمهام إدارة قواعد البيانات.

التثبيت

قبل تثبيت phpMyAdmin فستحتاج إلى وصول إلى قاعدة بيانات MySQL سواءً على نفس المضيف الذي سيُثبَّت عليه phpMyAdmin أو على مضيف آخر متوفر عبر الشبكة؛ للمزيد من المعلومات حول MySQL فانظر إلى القسم الخاص بها في هذا الكتاب؛ أدخِل الأمر الآتي لتثبيت phpMyAdmin:

sudo apt-get install phpmyadmin

ستظهر لك نافذة لاختيار أي خادوم ويب سيُضبَط ليستخدمه phpMyAdmin؛ سنستخدم لبقية هذا القسم خادوم أباتشي كخادوم ويب.

في المتصفح، اذهب إلى http://server/phpmyadmin مستبدلًا server باسم مضيف الخادوم الحقيقي؛ وعند صفحة تسجيل الدخول، اكتب root في حقل اسم المستخدم، أو أي مستخدم MySQL إذا كنت قد أعددت واحدًا؛ ثم أدخل كلمة مرور ذاك المستخدم.

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

الضبط

ملفات الضبط الخاصة ببرمجية phpMyAdmin موجودةٌ في مجلد ‎/etc/phpmyadmin؛ ملف الضبط الرئيسي هو ‎/etc/phpmyadmin/config.inc.php يحتوي هذا الملف خيارات الضبط التي تُطبَّق عمومًا على phpMyAdmin.

لاستخدام phpMyAdmin لإدارة قواعد بيانات MySQL على خادوم آخر، عدِّل قيمة ما يلي في ملف ‎/etc/phpmyadmin/config.inc.php:

$cfg['Servers'][$i]['host'] = 'db_server';

ملاحظة: استبدل db_server باسم مضيف الخادوم البعيد أو عنوان IP الخاص به؛ أيضًا تأكد أن مضيف phpMyAdmin لديه الأذونات الكافية للوصول إلى قاعدة البيانات البعيدة.

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

الملفان config.header.inc.php و config.footer.inc.php يستخدمان لإضافة ترويسة وتذييل HTML إلى phpMyAdmin.

ملف ضبط آخر مهم هو ‎/etc/phpmyadmin/apache.conf، توجد وصلة رمزية لهذا الملف في ‎/etc/apache2/conf.d/phpmyadmin.conf ويُستخدَم لضبط أباتشي لتخديم صفحات phpMyAdmin؛ يحتوي هذا الملف على تعليمات لتحميل PHP، وأذونات المجلد ...إلخ.

مصادر

• يأتي توثيق phpMyAdmin مثبتًا مع الحزمة ويمكن الوصول إليه من وصلة «phpMyAdmin Documentation» تحت شعار phpMyAdmin؛ يمكن الوصول إلى التوثيق الرسمي أيضًا في موقع phpMyAdmin.
• كتاب «Mastering phpMyAdmin» هو مصدر جيد للمعلومات.
• مصدر ثالث هو صفحة ويكي أوبنتو «phpMyAdmin».

ووردبريس

إن ووردبريس (Wordpress) هي أداة تدوين، ومنصة نشر، ونظام إدارة محتوى مكتوبة بلغة PHP ومرخصة برخصة GNU GPLv2.

التثبيت

نفِّذ الأمر الآتي في سطر الأوامر لتثبيت ووردبريس:

sudo apt-get install wordpress

يجب عليك أيضًا تثبيت خادوم أباتشي وخادوم MySQL؛ راجع الأقسام التي تُعنى بتثبيتهما وإعدادهما في هذه السلسلة.

الضبط

لضبط أول تطبيق ووردبريس، فعليك ضبط موقع أباتشي؛ افتح الملف ‎/etc/apache2/sites-available/wordpress.conf وضع فيه الأسطر الآتية:

Alias /blog /usr/share/wordpress

<Directory /usr/share/wordpress>
  Options FollowSymLinks
  AllowOverride Limit Options FileInfo
  DirectoryIndex index.php
  Order allow,deny
  Allow from all
</Directory>

<Directory /usr/share/wordpress/wp-content>
  Options FollowSymLinks
  Order allow,deny
  Allow from all
</Directory>

ثم فعِّل الموقع الجديد:

sudo a2ensite wordpress

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

sudo service apache2 restart

لتبسيط تشغيل عدِّة نسخ من ووردبريس، فسمِّ ملف الضبط بناءً على اسم المضيف؛ وهذا يعني أنك تستطيع أن تملك عدّة مضيفين وهميين بمطابقة اسم المضيف في ملف الضبط مع ملف اسم المضيف الوهمي في أباتشي؛ فعلى سبيل المثال، تكون أسماء الملفات هي ‎/etc/wordpress/config-10.211.55.50.php، أو ‎/etc/wordpress/config-hostalias1.php ...إلخ. هذه التعليمات تفترض أنك تستطيع الوصول إلى أباتشي عبر المضيف المحلي (ربما باستخدام نفق SSH)؛ إذا لم يكن ذلك هو الأمر، فاستبدل ‎/etc/wordpress/config-localhost.php بالاسم ‎/etc/wordpress/config/NAME_OF_VIRTUAL ‎_HOST.php.

بعد أن يُكتَب ملف الضبط، فعليك اختيار نمط ﻷسماء مستخدمي MySQL وكلمات مرورهم لكل نسخة ووردبريس؛ لكن سنعرض في هذا الدرس مثالًا واحدًا هو localhost فقط.

علينا الآن ضبط ووردبريس لاستخدام قاعدة بيانات MySQL؛ افتح الملف ‎/etc/wordpress/config-localhost.php واكتب الأسطر الآتية:

<?php
  define('DB_NAME', 'wordpress');
  define('DB_USER', 'wordpress');
  define('DB_PASSWORD', 'yourpasswordhere');
  define('DB_HOST', 'localhost');
  define('WP_CONTENT_DIR', '/usr/share/wordpress/wp-content');
?>

ثم أنشِئ قاعدة البيانات، وذلك بفتح ملف مؤقت باسم wordpree.sql فيه أوامر MySQL الآتية:

CREATE DATABASE wordpress;
GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER
  ON wordpress.*
  TO wordpress@localhost
  IDENTIFIED BY 'yourpasswordhere';
FLUSH PRIVILEGES;

نفِّذ أوامر MySQL السابقة بالأمر:

cat wordpress.sql | sudo mysql --defaults-extra-file=/etc/mysql/debian.cnf

يجب أن تكون نسخة ووردبريس عندك قابلة للضبط بزيارة الوصلة http://localhost/blog/wp-admin/install.php، ثم اكتب اسم الموقع واسم المستخدم وكلمة المرور وبريدك الإلكتروني ثم اضغط على «تثبيت ووردبريس».

لاحظ كلمة المرور المُولَّدة إن لم تختر واحدةً، ثم سجِّل دخولك إلى لوحة تحكم ووبرديس.

مصادر

• توثيق Wordpress.org Codex.
• صفحة ويكي أوبنتو «WordPress».

ترجمة -وبتصرف- للمقال Ubuntu Server Guide: LAMP Applications.

إن أباتشي تومكات (Apache Tomcat) هو «حاوية ويب» (web container) يسمح لك بتخديم Java Servlets و JSP ‏(Java Server Pages).

في أوبنتو دعمٌ لإصدارَيّ تومكات 6 و 7، حيث تومكات 6 هي النسخة القديمة؛ و تومكات 7 هي النسخة الحالية التي تضاف إليها الميزات الجديدة. يُعتَبَر أن كلا الإصدارين مستقر، لكننا سنركز على نسخة تومكات 7، لكن أغلبية تفاصيل الضبط المشروحة هنا صالحة لكلي النسختين.

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

التثبيت لعموم النظام

عليك إدخال الأمر الآتي في الطرفية لتثبيت خادوم تومكات:

sudo apt-get install tomcat7

الأمر السابق سيُثبِّت خادوم تومكات مع تطبيق الويب الافتراضي ROOT؛ الذي يُظهِر صفحةً بسيطةً تحتوي على "It works".

الضبط

ملفات ضبط تومكات موجودة في ‎/etc/tomcat7، بعض تعديلات الضبط الشائعة ستُشرَح هنا فقط؛ رجاءً راجع توثيق Tomcat 7.01 للمزيد.

تغيير المنافذ الافتراضية

يعمل تومكات 7.0 افتراضيًا بواصل HTTP‏ (HTTP connector) على المنفذ 8080 وواصل AJP على المنفذ 8009؛ ربما تريد تغيير هذين المنفذين الافتراضيين لتفادي التضاربات مع خواديم أخرى على النظام، يمكن فعل ذلك بتعديل الأسطر الآتية في ‎/etc/tomcat7/server.xml:

<Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />
...
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

تبديل JVM المستخدمة

يعمل تومكات افتراضيًا عملًا ممتازًا مع OpenJDK، ثم سيُجرِّب JVM الخاصة بشركة Sun؛ ثم سيجرب JVMs الأخرى؛ إذا كان لديك عدّة JVMs مثبتةً، فيمكنك ضبط أيٌّ منها سيستخدم عبر JAVA_HOME في ‎/etc/default ‎/tomcat7:

JAVA_HOME=/usr/lib/jvm/java-6-sun

تعريف المستخدمين وأدوارهم

يمكن أن تُعرَّف أسماء المستخدمين وكلمات مرورهم وأدوارهم (المجموعات) في حاوية Servlet؛ يتم ذلك في ملف ‎/etc/tomcat7/tomcat-users.xml:

<role rolename="admin"/>
<user username="tomcat" password="s3cret" roles="admin"/>

استخدام تطبيقات الويب القياسية التابعة لتومكات

يأتي تومكات مع تطبيقات ويب تستطيع تثبيتها لأغراض التوثيق أو الإدارة أو لأغراض تجريبية.

توثيق تومكات

تحتوي الحزمة tomcat7-docs على توثيق تومكات محزمًّا كتطبيق ويب تستطيع الدخول إليه افتراضيًا عبر http://server:8080/docs، وتستطيع تثبيت تلك الحزمة بالأمر الآتي:

sudo apt-get install tomcat7-docs

تطبيقات الويب لإدارة تومكات

تحتوي الحزمة tomcat7-admin على تطبيقَيّ ويب تستطيع استخدامهما لإدارة خادوم تومكات عبر واجهة ويب، يمكنك تثبيتهما عبر إدخال الأمر الآتي في الطرفية:

sudo apt-get install tomcat7-admin

أولهما هو تطبيق الويب «manager»؛ الذي يمكن الوصول إليه افتراضيًا عبر http://server:8080/manager/html؛ ويُستخدَم للحصول على حالة الخادوم وإعادة تشغيل تطبيقات الويب.

ملاحظة: الوصول إلى تطبيق manager محميٌ افتراضيًا: عليك أن تُعرِّف مستخدمًا بدور «manager-gui» في ‎/etc/tomcat7/tomcat-users.xml قبل الوصول إليه.

التطبيق الآخر هو «host-manager» الذي يمكن الوصول إليه افتراضيًّا عبر http://server:8080/host-manager/html، ويمكن أن يُستخدَم لإنشاء مضيفين وهميين ديناميكيًّا.

ملاحظة: الوصول إلى تطبيق host-manager محميٌ افتراضيًا أيضًا: عليك أن تُعرِّف مستخدمًا بدور «admin-gui» في ‎/etc/tomcat7/tomcat-users.xml قبل الوصول إليه.

لأسباب تتعلق بالحماية، لا يمكن للمستخدم tomcat7 أن يكتب إلى مجلد ‎/etc/tomcat7 افتراضيًا؛ بعض الميزات في تطبيقات الويب هذه (نشر التطبيقات، أو إنشاء مضيف وهمي) تحتاج إلى إذن الكتابة إلى ذاك المجلد؛ إذا أردت استخدام هذه الميزات، فعليك تنفيذ الأوامر الآتية لإعطاء المستخدمين في مجموعة tomcat7 الامتيازات اللازمة:

sudo chgrp -R tomcat7 /etc/tomcat7
sudo chmod -R g+w /etc/tomcat7

تطبيقات ويب تومكات للتجربة

تحتوي حزمة tomcat7-example على تطبيقَيّ ويب يُستخدمان لاختبار أو شرح ميزات Servlets و JSP؛ تستطيع الوصول إليهما افتراضيًا عبر http://server:8080/examples؛ يمكنك تثبيتهما بالأمر:

sudo apt-get install tomcat7-examples

استخدام نسخ خاصة

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

ملاحظة: من الممكن تشغيل نسخة لعموم النظام، ونسخ خاصة على التوازي (أي معًا)؛ شريطة ألّا يستخدموا نفس منافذ TCP.

تثبيت دعم النسخ الخاصة

يمكنك تثبيت كل ما يلزم لدعم النسخ الخاصة بتنفيذ الأمر الآتي في الطرفية:

sudo apt-get install tomcat7-user

إنشاء نسخة خاصة

يمكنك إنشاء مجلد لنسخة خاصة بإدخال الأمر الآتي في الطرفية:

tomcat7-instance-create my-instance

سيُنشِئ الأمر السابق مجلد my-instance جديد مع كل المجلدات الفرعية والسكربتات اللازمة؛ يمكنك على سبيل المثال تثبيت المكتبات الشائعة في المجلد الفرعي lib/‎ ووضع تطبيق الويب في مجلد webapps/‎؛ لا توجد أيّة تطبيقات ويب افتراضيًا.

ضبط نسختك الخاصة

ستجد ملفات ضبط تومكات التقليدية في النسخة الخاصة في المجلد الفرعي conf/‎؛ يجب عليك، على سبيل المثال، تعديل ملف conf/server.xml لتغيير المنفذ الافتراضي المُستخدَم من نسخة تومكات الخاصة لتفادي التضارب مع النسخ الأخرى التي قد تكون تعمل على النظام.

بدء أو إيقاف النسخة الخاصة

يمكنك بدء نسختك الخاصة بإدخال الأمر الآتي في الطرفية (بفرض أن نسختك موجودةٌ في مجلد my-instance):

my-instance/bin/startup.sh

ملاحظة: عليك التحقق من المجلد الفرعي logs/ لأي خطأ؛ إذا حصلت على خطأ:

 java.net.BindException: Address already in use<null>:8080 

فاعلم أن المنفذ مُستخدَم من قبل وعليك تغييره.

يمكنك إيقاف نسختك الخاصة بتنفيذ الأمر الآتي في سطر الأوامر:

my-instance/bin/shutdown.sh

مصادر

• راجع موقع Apache Tomcat لمزيدٍ من المعلومات.
• كتاب «Tomcat: The Definitive Guide» هو مصدر جيد لبناء تطبيقات الويب مع تومكات.
• راجع قائمة «Tomcat Books» لمزيدٍ من الكتب.

ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Apache Tomcat.

إن Squid هو خادوم تخزين وسيط للويب (web proxy cache server) الذي يوفر خدمات الوساطة والتخزين لبروتوكول نقل النص الفائق (HTTP)، وبروتوكول نقل الملفات (FTP)، وغيرهما من بروتوكولات الشبكة الشهيرة؛ يمكن أن يدعم Squid التخزين والوساطة لطلبات طبقة المقابس الآمنة (SSL) وتخزين طلبيات DNS؛ ويدعم Squid أيضًا بروتوكولات تخزين مخبأ مختلفة، مثل بروتوكول تخزين الإنترنت (Internet Cache Protocol اختصارًا ICP)، وبروتوكول تخزين النص الفائق (Hyper Text Caching Protocol اختصارًا HTCP)، وبروتوكول تخزين مصفوفة التوجيه (Cache Array Routing Protocol اختصارًا CARP)، وبروتوكول تنسيق تخزين الويب (Web Cache Coordination Protocol اختصارًا WCCP).

إن الخادوم الوسيط Squid هو حل ممتاز لاحتياجاتٍ كثيرةً للوساطة أو التخزين المؤقت، والتوسع من مكتب فرعي إلى شبكة الشركة الكبيرة وذلك بتوفير آليات مراقبة وتحكم في الوصول للمعاملات المهمة باستخدام بروتوكول إدارة الشبكة المبسط (Simple Network Management Protocol اختصارًا SNMP).

عند اختيار حاسوب ليعمل كخادوم Squid، فتأكد أنه مضبوط مع كمية كبيرة من الذاكرة الفيزيائية، حيث يستخدم Squid التخزين في الذاكرة لزيادة الأداء.

التثبيت

أدخِل الأمر الآتي في الطرفية لتثبيت خادوم Squid:

sudo apt-get install squid3

الضبط

يُضبَط Squid بتعديل التعليمات الموجودة ضمن ملف الضبط ‎/etc/squid3/squid.conf؛ الأمثلة الآتية تعرض بعض التعليمات التي يمكن تعديلها لتغيير سلوك خادوم Squid؛ للمزيد من التفاصيل المعمَّقة حول Squid، فانظر إلى قسم المصادر.

تنويه: قبل تعديل ملف الضبط، تأكد أنك ستُنشِئ نسخةً من الملف الأصلي وتحميها من الكتابة كي تحصل على الإعدادات الافتراضية كمرجعٍ لك، أو أن تعيد استخدامها وقت الحاجة.

انسخ الملف ‎/etc/squid/squid.conf واحمهِ من الكتابة بإدخال الأوامر الآتية في الطرفية:

sudo cp /etc/squid3/squid.conf /etc/squid3/squid.conf.original
sudo chmod a-w /etc/squid3/squid.conf.original

لضبط خادوم Squid لكي يستمع إلى منفذ TCP ذو الرقم 8888 بدلًا من منفذ TCP الافتراضي 3128، فعدِّل التعليمة http_port كما يلي:

http_port 8888

عدِّل التعليمة visible_hostname لكي تعطي خادوم Squid اسم مضيف خاص به؛ هذا الاسم لا يفترض أن يكون نفس اسم المضيف للحاسوب؛ ضُبِطَ في هذا المثال إلى weezie:

visible_hostname weezie

باستخدام التحكم في الوصول الخاص بخادوم Squid، ربما تضبط استخدام خدمات الإنترنت التي يكون فيها Squid وسيطًا لتتوفر للمستخدمين الذي يملكون عناوين IP معيّنة؛ ففي هذا المثال، سنسمح بالوصول لمستخدمي الشبكة الفرعية 192.168.42.0/24 فقط:

أضف ما يلي إلى نهاية قسم ACL من ملف ضبط ‎/etc/squid3/squid.conf:

acl fortytwo_network src 192.168.42.0/24

ثم أضف ما يلي إلى بداية قسم http_access في ملف ‎/etc/squid3/squid.conf:

http_access allow fortytwo_network

باستخدام ميزات التحكم بالوصول الممتازة التي يوفرها Squid؛ فربما تضبط استخدام خدمات الإنترنت التي يكون فيها Squid وسيطًا كي تتوفر فقط أثناء ساعات العمل العادية؛ على سبيل المثال، سنحاكي وصول الموظفين خلال ساعات العمل من 9:00AM إلى 5:00PM ومن الاثنين إلى الجمعة، الذين يستخدمون الشبكة الفرعية 10.1.42.0/42:

أضف ما يلي إلى نهاية قسم ACL في ملف ‎/etc/squid3/squid.conf:

acl biz_network src 10.1.42.0/24
acl biz_hours time M T W T F 9:00-17:00

ثم أضف ما يلي إلى أعلى قسم http_access في ملف ‎/etc/squid3/squid.conf:

http_access allow biz_network biz_hours

ملاحظة: بعد عمل تغيرات إلى ملف الضبط ‎/etc/squid3/squid.conf، فاحفظ الملف ثم أعد تشغيل خادوم Squid لكي تأخذ التغيرات مجراها بإدخال الأمر الآتي في الطرفية:

sudo service squid3 restart

مصادر

• موقع Squid.
• صفحة ويكي أوبنتو «Squid».

ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Squid - Proxy Server.