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

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

نظام التحكم بالإصدارات Gitإن Git هو نظام تحكم بالإصدارات موزَّع (distributed) ومفتوح المصدر مطوَّر من لينوس تورفالدس لدعم تطوير نواة لينُكس؛ حيث يكون كل مجلد في Git عبارة عن مستودع مع تأريخ كامل وإمكانيات لتتبع الإصدارات، وليس متعمِدًا على الوصول على الشبكة أو على خادوم مركزي. التثبيتيمكن تثبيت نظام التحكم بالإصدارات git باستخدام الأمر الآتي: sudo apt-get install gitالضبطيجب لكل مستخدم git أن يعرِّف نفسه أولًا إلى git، وذلك بتنفيذ الأمرّين الآتيين: git config --global user.email "you@example.com" git config --global user.name "Your Name"الاستخدام الأساسيما سبق يكفي لاستخدام git في طريقة موزعة وآمنة، حيث يُفترَض أنَّ المستخدمين يستطيعون الوصول إلى الخادوم عبر SSH؛ حيث يمكن إنشاء مستودع جديد على الخادوم بالأمر: git init --bare /path/to/repositoryملاحظة: الأمر السابق يُنشِئ مستودعًا «فارغًا» (bare)، أي أنه ليس بالإمكان استخدامه للتعديل على الملفات مباشرةً. إذا أردت الحصول على نسخة من محتويات المستودع على الخادوم، فاحذف الخيار ‎--bare. يمكن لأي عميل يملك وصولًا عبر SSH إلى الخادوم أن ينسخ المستودع بالأمر: git clone username@hostname:/path/to/repositoryبعد نسخ الملفات إلى جهاز العميل، يمكنه تعديلها ثم إيداعها ومشاركتها بالأوامر: cd /path/to/repository # edit some files git commit -a # Commit all changes to the local version of the repository git push origin master # Push changes to the server's version of the repositoryتثبيت خادوم gitoliteعلى الرغم من أنّ ما سبق كافٍ لإنشاء ونسخ وتعديل المستودعات، لكن المستخدمين الذين يريدون تثبيت git على خادوم سيريدون عمومًا إنجاز المهام في git كنظام إدارة التحكم بالأكواد المصدرية تقليدي؛ وعند وجود عدِّة مستخدمين وامتيازات وصول لهم، فالحل الأمثل هو تثبيت gitolite كما يلي: sudo apt-get install gitoliteضبط Gitoliteضبط خادوم Gitolite مختلف قليلًا عن معظم الخواديم في الأنظمة الشبيهة بِيونكس؛ فبدلًا من ملفات الضبط التقليدية في ‎/etc/‎، فإن gitolite يُخزِّن الضبط في مستودع git؛ أول خطوة لضبط تثبيت جديد هي السماح بالوصول إلى مستودع الضبط. أولًا، علينا إنشاء مستخدم لأجل gitolite لكي نصل إليه عبره: sudo adduser --system --shell /bin/bash --group --disabled-password --home /home/git gitسنترك الآن gitolite لكي يعرف عن مفتاح SSH العمومي لمدير المستودع؛ هنا نفترض أن المستخدم الحالي هو مدير المستودع؛ إذا لم تضبط مفتاح SSH بعد، فراجع الدرس الخاص بخادوم OpenSSH لمزيدٍ من التفاصيل: cp ~/.ssh/id_rsa.pub /tmp/$(whoami).pubلنبدِّل إلى المستخدم git ونستورد مفتاح المدير إلى gitolite: sudo su - git gl-setup /tmp/*.pubسيسمح Gitolite لك بعمل تغيرات مبدئية لضبطه أثناء عملية الإعداد؛ يمكنك الآن نسخ وتعديل مستودع ضبط gitolite من المستخدم المدير (المستخدم الذي استوردت مفتاح SSH العمومي الخاص به)؛ عُد إلى ذاك المستخدم، ثم انسخ مستودع الضبط: exit git clone git@$IP_ADDRESS:gitolite-admin.git cd gitolite-adminالمجلد gitolite-admin فيه مجلدين فرعيين، المجلد «conf» و «keydir»؛ ملفات الضبط موجودة في مجلد conf، ويحتوي مجلد keydir على مفاتيح SSH العمومية للمستخدم. إدارة مستخدمي ومستودعات gitoliteإضافة مستخدمين جدد إلى gitolite هي عملية سهلة: احصل على مفتاح SSH العمومي لهم ثم أضفه إلى مجلد keydir بالاسم USERNAME.pub، لاحظ أن أسماء مستخدمي gitolite لا تطابق بالضرورة أسماء مستخدمي النظام، حيث تُستخدَم أسمائهم في ملف ضبط gitolite فقط، وذلك لإدارة التحكم بالوصول؛ وبشكل مشابه، يمكن حذف المستخدمين بحذف ملف المفتاح العمومي الخاص بهم؛ ولا تنسَ أن تودع التغييرات وتدفعها إلى خادوم git بعد كل تعديل: git commit -a git push origin masterتُدار المستودعات بتعديل الملف conf/gitolite.conf؛ الشكل العام له هو قيود مفصولة بفراغات تُحدِّد ببساطة قائمةً بالمستودعات ثم بعض قواعد الوصول؛ ما يلي هو المثال الافتراضي لهذا الملف: repo gitolite-admin RW+ = admin R = alice repo project1 RW+ = alice RW = bob R = deniseاستخدام خادومكلاستخدام الخادوم المُنشَأ حديثًا، يجب أن يستورد مدير gitolite مفاتيح المستخدمين العمومية إلى مستودع ضبط gitolite، ثم يمكنهم الوصول إلى أي مستودع لهم حق الوصول إليه عبر الأمر الآتي: git clone git@$SERVER_IP:$PROJECT_NAME.gitأو إضافة مشروع في الخادوم عن بعد: git remote add gitolite git@$SERVER_IP:$PROJECT_NAME.gitترجمة -وبتصرف- للمقال Ubuntu Server Guide: Git.

هنالك العديد من البرمجيات المفيدة جدًا المطورة من فريق خادوم أوبنتو وغيرهم التي تندمج اندماجًا جيدًا مع نسخة خادوم أوبنتو، لكن ربما لا تكون معروفةً جدًا؛ سيعرض هذا الدرس بعض التطبيقات المفيدة التي تسهِّل إدارة خادوم، أو عدِّة خواديم أوبنتو. 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.

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

إن OpenVPN هو حلّ لإنشاء شبكات وهمية خاصة (Virtual Private Networks اختصارًا VPN) موجودٌ في مستودعات أوبنتو؛ هو خدمة مرنة وعملية وآمنة، وينتمي إلى عائلة SSL/TLS VPN (التي تختلف عن IPSec VPN)؛ يشرح هذا الدرس تثبيت وضبط OpenVPN لإنشاء شبكة وهمية خاصة. OpenVPN إذا كنت تريد أكثر من مجرد مفاتيح مُشارَكة مسبقًا؛ فيجعل OpenVPN من السهل إعداد واستخدام بينة تحتية للمفتاح العمومي (Public Key Infrastructure اختصارًا PKI) لاستخدام شهادات SSL/TLS للاستيثاق ومبادلة المفاتيح بين خادوم VPN والعملاء؛ يمكن أن يُستخدَم OpenVPN في نمط موَجِّه أو جسر VPN‏ (routed or bridged VPN) ويمكن أن يُضبَط ليستخدم TCP أو UDP؛ ويمكن ضبط رقم المنفذ أيضًا، لكن رقم المنفذ 1194 هو الرقم الرسمي لهذه الخدمة؛ عملاء VPN موجودون تقريبًا في جميع توزيعات لينُكس، ونظام ماك OS X؛ وويندوز والموجهات (routers) التي تعتمد على OpenWRT. تثبيت الخادوم لتثبيت برمجية OpenVPN، أدخِل الأمر الآتي في الطرفية: sudo apt-get install openvpn إعداد البنية التحتية للمفتاح العمومي أول خطوة لضبط OpenVPN هي إنشاء بنية تحتية للمفتاح العمومي (PKI)؛ التي تحتوي على: شهادة منفصلة (تُسمى أيضًا مفتاح عمومي) وشهادة خاصة للخادوم ولكل عميل. شهادة سلطة شهادات (CA) رئيسية التي يمكن أن تُستخدَم لتوقيع شهادات كلٍّ من الخادوم والعملاء. يدعم OpenVPN الاستيثاق ثنائي الاتجاه بناءً على الشهادات، وهذا يعني أن على العميل الاستيثاق من شهادة الخادوم، وعلى الخادوم الاستيثاق من شهادة العميل قبل أن تُنشَأ ثقةٌ مشتركةٌ بينهما. على الخادوم والعميل الاستيثاق من بعضها أولًا عبر التحقق من أن الشهادة موقعة من سلطة الشهادات الرئيسية، ثم باختبار المعلومات في ترويسة الشهادة المستوثق منها؛ مثل اسم الشهادة الشائع أو نوع الشهادة (عميل أو خادوم). إعداد سلطة الشهادات لضبط سلطة شهادات خاصة بك وتوليد شهادات ومفاتيح لخادوم OpenVPN ولبعض العملاء، عليك أولًا نسخ المجلد easy-rsa إلى ‎/etc/openvpn؛ وهذا سيؤكد أن أي تغييرات إلى السكربتات لن تضيع عند تحديث الحزمة؛ أدخِل ما يلي في الطرفية: mkdir /etc/openvpn/easy-rsa/ cp -r /usr/share/easy-rsa/* /etc/openvpn/easy-rsa/ الآن عدِّل الملف ‎/etc/openvpn/easy-rsa/vars مغيّرًا ما يلي ليناسب بيئتك: export KEY_COUNTRY="US" export KEY_PROVINCE="NC" export KEY_CITY="Winston-Salem" export KEY_ORG="Example Company" export KEY_EMAIL="steve@example.com" export KEY_CN=MyVPN export KEY_NAME=MyVPN export KEY_OU=MyVPN أدخِل ما يلي لتوليد شهادة سلطة شهادات رئيسية ومفتاح: cd /etc/openvpn/easy-rsa/ source vars ./clean-all ./build-ca شهادات الخادوم عليك توليد شهادة ومفتاح خاص للخادوم: ./build-key-server myservername وكما في الخطوة السابقة، أغلبية المعاملات يمكن أن تبقى على قيمتها الافتراضية؛ هنالك سؤالان يجب أن تجيب عليهما بالقبول هما: "‎Sign the certificate? [y/n]" و "‎‏‎1 out of 1 certificate requests ‎certified, commit? [y/n]‎". يجب توليد معاملات Diffie Hellman لخادوم OpenVPN: ./build-dh جميع الشهادات والمفاتيح ستولد في المجلد الفرعيkeys‎‎‎/؛ ومن العادات الشائعة بين المدراء نسخها إلى ‎/etc/openvpn: cd keys/ cp myservername.crt myservername.key ca.crt dh2048.pem /etc/openvpn/ شهادات العميل سيحتاج عميل VPN إلى شهادة أيضًا لكي يُعرِّف نفسه إلى الخادوم؛ عليك عادةً إنشاء شهادة منفصلة لكل عميل؛ أدخِل ما يلي في الطرفية لإنشاء شهادة: cd /etc/openvpn/easy-rsa/ source vars ./build-key client1 انسخ الملفات الآتية إلى العميل باستخدام طريقة آمنة: /etc/openvpn/ca.crt /etc/openvpn/easy-rsa/keys/client1.crt /etc/openvpn/easy-rsa/keys/client1.key ولأن شهادات ومفاتيح العميل مطلوبة فقط على حاسوب العميل، فعليك حذفهم من الخادوم. ضبط بسيط للخادوم ستحصل عند تثبيت OpenVPN على أمثلة عن ملفات الضبط: ls -l /usr/share/doc/openvpn/examples/sample-config-files/ total 68 -rw-r--r-- 1 root root 3427 2011-07-04 15:09 client.conf -rw-r--r-- 1 root root 4141 2011-07-04 15:09 server.conf.gz ابدأ بنسخ وفك ضغط server.conf.gz إلى ‎/etc/openvpn/server.conf. sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz \ /etc/openvpn/ sudo gzip -d /etc/openvpn/server.conf.gz عدِّل ملف ‎/etc/openvpn/server.conf للتأكد من أن الأسطر الآتية تشير إلى الشهادات والمفاتيح التي أنشأتها في القسم السابق: ca ca.crt cert myservername.crt key myservername.key dh dh2048.pem عدِّل الملف ‎/etc/sysctl.conf وأزل التعليق عن السطر الآتي لتفعيل تمرير IP: #net.ipv4.ip_forward=1 ثم أعد تحميل sysctl: sudo sysctl -p /etc/sysctl.conf هذا هو الحد الأدنى الذي تحتاج لضبط خادوم OpenVPN؛ يمكنك استخدام جميع الإعدادات الافتراضية في ملف server.conf؛ الآن شغِّل الخادوم، وستجد رسائل التسجيل والخطأ موجودةً في ملف syslog: sudo service openvpn start * Starting virtual private network daemon(s)... * Autostarting VPN 'server' [ OK ] تأكد الآن من أن OpenVPN قد أنشَأ البطاقة tun0: sudo ifconfig tun0 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 [...] ضبط بسيط للعميل هنالك عدِّة نسخ من عملاء OpenVPN بواجهة أو بدون واجهة رسومية؛ يمكنك القراءة المزيد عن العملاء في قسمٍ آخر؛ لكننا الآن سنستخدم عميل OpenVPN في أوبنتو الذي هو نفس الملف التنفيذي للخادوم؛ لذلك عليك تثبيت الحزمة openvpn مرةً أخرى في جهاز العميل: sudo apt-get install openvpn سننسخ هذه المرة ملف مثال الضبط client.conf إلى ‎/etc/openvpn/‎: sudo cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf \ /etc/openvpn/ انسخ مفاتيح العميل والشهادة الصادرين من سلطة الشهادات التي أنشَأتها في قسمٍ سابق، وعدِّل ‎/etc/openvpn/client.conf للتأكد من أن الأسطر الآتية تُشير إلى تلك الملفات؛ يمكنك حذف المسار إذا كانت تلك الملفات موجودةً في ‎/etc/openvpn: ca ca.crt cert client1.crt key client1.key وعليك تحديد اسم أو عنوان خادوم OpenVPN واحد على الأقل؛ تأكد أن الكلمة المحجوزة client موجودةٌ في ملف الضبط، لأن هذا ما سيُفعِّل نمط العميل: client remote vpnserver.example.com 1194 شغِّل الآن عميل OpenVPN: sudo service openvpn start * Starting virtual private network daemon(s)... * Autostarting VPN 'client' [ OK ] وتأكد من إنشاء البطاقة الشبكية tun0: sudo ifconfig tun0 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.6 P-t-P:10.8.0.5 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 وتأكد إن كان بإمكانك عمل ping لخادوم OpenVPN: ping 10.8.0.1 PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data. 64 bytes from 10.8.0.1: icmp_req=1 ttl=64 time=0.920 ms ملاحظة: يستخدم خادوم OpenVPN أول عنوان IP قابل للاستخدام في شبكة العميل ويكون هذا العنوان هو الوحيد المستجيب للأداة ping؛ على سبيل المثال، لو ضُبِط قناع ‎/24 لشبكة العميل، فسيستخدم العنوان ‎.1؛ عنوان PTP (الند للند، أو peer to peer) الذي تراه في ناتج ifconfig أعلاه لا يجيب عادةً على طلبات ping. تأكد من جداول التوجيه عندك: sudo netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.8.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.8.0.1 10.8.0.5 255.255.255.255 UGH 0 0 0 tun0 192.168.42.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.42.1 0.0.0.0 UG 0 0 0 eth0 أول خطوة في استكشاف الأخطاء إذا لم يعمل ما سبق لك، فعليك أن تفعل ما يلي: تحقق من سجل syslog عندك، أي grep -i vpn /var/log/syslog. هل يستطيع العميل الاتصال إلى الخادوم؟ ربما يحجب الجدار الناري وصوله؟ تأكد من سجل syslog على الخادوم. يجب أن يستخدم الخادوم والعميل نفس البروتوكول والمنفذ، مثلًا UDP بمنفذ 1194؛ راجع خيارَيّ الضبط proto و port. يجب أن يستخدم الخادوم والعميل نفس إعدادات الضبط الخاصة بالضغط، راجع خيار الضبط comp-lzo. يجب أن يستخدم الخادوم والعميل نفس الضبط المتعلق بنمط التوجيه والجسور. ترجمة -وبتصرف- للمقال Ubuntu Server Guide: OpenVPN.

ينشئ 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 لاستخدام مجموعات التحكم هنا. ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Control Groups.

تعرفنا في الدرسين الماضيين عن مفهوم حاويات لينكس (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». ترجمة -وبتصرف- للمقال Ubuntu Server Guide: LXC.

تعرفنا في الدرس الماضي على مفهوم حاويات لينكس (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». ترجمة -وبتصرف- للمقال Ubuntu Server Guide: libvirt.

كانت أوبنتو أكثر نظام تشغيل مستخدم في العالم في أغلبية المنصات السحابية، فأصبح من الضروري توفير صور سحابية مستقرة وآمنة؛ وفي إصدارة 12.04، تحسن استعمال الصور السحابية خارج البنية التحتية للسحابة؛ وأصبح الآن بالإمكان استخدام هذه الصور لإنشاء آلات وهمية دون الحاجة إلى إجراء تثبيت كامل. إنشاء آلات وهمية باستخدام الأداة uvtool بدءًا من 14.04، أصبح هنالك أداة هي uvtool لتسهيل مهمة توليد الآلات الوهمية (VM) باستخدام الصور السحابية؛ توفر الأداة uvtool آليةً للمزامنة بين الصور السحابية محليًا واستخدامها لإنشاء آلات وهمية في غضون دقائق. حزم Uvtool الحزم الآتية واعتمادياتها مطلوبةٌ لاستخدام uvtool: uvtool uvtool-libvirt تثبيت uvtool مثله كمثل غيره من التطبيقات باستخدام apt-get: sudo apt-get install uvtool هذا سيتثبت الأوامر الرئيسية للأداة uvtool: uvt-simplestreams-libvirt uvt-kvm الحصول على صورة سحابة أوبنتو مع uvt-simplestreams-libvirt هذه إحدى التبسيطات التي جاءت بها الأداة uvtool؛ حيث أنها تعلم أين يمكن العثور على الصور السحابية، لذلك ستحتاج إلى أمرٍ واحد للحصول على صورة سحابية؛ على سبيل المثال، إذا أردت مزامنة كل الصور السحابية لمعمارية amd64، فسيكون الأمر كالآتي: uvt-simplestreams-libvirt sync arch=amd64 بعد الفترة الضرورية من الزمن لتنزيل كل الصور من الإنترنت، سيكون لديك مجموعة كاملة من الصور السحابية مخزنةٌ محليًا؛ نفِّذ الأمر الآتي لرؤية الصور التي نُزِّلَت: uvt-simplestreams-libvirt query release=oneiric arch=amd64 label=release (20130509) release=precise arch=amd64 label=release (20140227) release=quantal arch=amd64 label=release (20140302) release=saucy arch=amd64 label=release (20140226) release=trusty arch=amd64 label=beta1 (20140226.1) وفي حال أردت مزامنة صورة سحابية واحد محددة، فيمكنك استخدام المُرشِّحات release=‎ و arch=‎ لتعريف الصورة التي يجب مزامنتها: uvt-simplestreams-libvirt sync release=precise arch=amd64 إنشاء آلة وهمية باستخدام uvt-kvm لكي تكون قادرًا على الاتصال بالآلة الوهمية بعد أن تُنشِئها، فمن الضروري أن يكون لديك مفتاح SSH صالح متوفر لمستخدم أوبنتو؛ إذا لم يكن لبيئتك مفتاح، فيمكنك إنشاء واحد بسهولة باستخدام الأمر الآتي: $ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/ubuntu/.ssh/id_rsa. Your public key has been saved in /home/ubuntu/.ssh/id_rsa.pub. The key fingerprint is: 4d:ba:5d:57:c9:49:ef:b5:ab:71:14:56:6e:2b:ad:9b ubuntu@TrustyS The key's randomart image is: +--[ RSA 2048]----+ | ..| | o.=| | . **| | + o+=| | S . ...=.| | o . .+ .| | . . o o | | * | | E | +-----------------+ إنشاء آلة وهمية باستخدام uvtool هو أمر هيّن، ففي أبسط شكل، كل ما عليك فعله هو تنفيذ الأمر: uvt-kvm create firsttest وهذا ما سينُشِئ آلةً وهميةً باسم firsttest باستخدام الصورة السحابية لنسخة الدعم الطويل الحالية (LTS) المتوفرة محليًا، إذا أردت تحديد إصدارة لتُستخدم لإنشاء الآلة الوهمية؛ فستحتاج إلى استخدام مرشح release=‎: uvt-kvm create secondtest release=trusty يمكن استخدام الأمر uvt-kvm wait NAME للانتظار حتى اكتمال إنشاء الآلة الوهمية: uvt-kvm wait secondttest --insecure Warning: secure wait for boot-finished not yet implemented; use --insecure. الاتصال إلى آلة وهمية تعمل بعد إكمال إنشاء الآلة الوهمية، يمكنك الاتصال إليها عبر SSH: uvt-kvm ssh secondtest --insecure وبالمناسبة، الخيار ‎--insecure مطلوب، لذلك عليك استخدام هذه الطريقة للاتصال إلى الآلات الوهمية إذا كنت تثق بأمان البنية التحتية لشبكتك تمام الثقة. يمكنك أيضًا الاتصال إلى الآلة الوهمية باستخدام جلسة ssh اعتيادية باستعمال عنوان IP للآلة الوهمية؛ يمكن أن يُطلَب عنوان IP عبر الأمر الآتي: $ uvt-kvm ip secondtest 192.168.123.242 $ ssh -i ~/.ssh/id_rsa ubuntu@192.168.123.242 The authenticity of host '192.168.123.242 (192.168.123.242)' can't be established. ECDSA key fingerprint is 3a:12:08:37:79:24:2f:58:aa:62:d3:9d:c0:99:66:8a. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.123.242' (ECDSA) to the list of known hosts. Welcome to Ubuntu Trusty Tahr (development branch) (GNU/Linux 3.13.0-12-generic x86_64) * Documentation: https://help.ubuntu.com/ System information disabled due to load higher than 1.0 Get cloud support with Ubuntu Advantage Cloud Guest: http://www.ubuntu.com/business/services/cloud 0 packages can be updated. 0 updates are security updates. Last login: Fri Mar 21 13:25:56 2014 from 192.168.123.1 الحصول على قائمة بالآلات الوهمية التي تعمل يمكن الحصول على قائمة بالآلات الوهمية التي تعمل على نظامك باستخدام الأمر: uvt-kvm list secondtest تدمير الآلة الوهمية بعد أن تنتهي من الآلة الوهمية، يمكنك «تدميرها» والتخلص منها بالأمر: uvt-kvm destroy secondtest المزيد من خيارات uvt-kvm يمكن أن تُستخدَم الخيارات الآتية لتغيير بعض خصائص الذاكرة الوهمية التي تُنشِئها: الخيار ‎--memory: مقدار الذاكرة (RAM) بواحدة الميغابايت، القيمة الافتراضية هي 512. الخيار ‎--disk: مقدار قرص النظام بواحدة الغيغابايت، القيمة الافتراضية هي 8. الخيار ‎--cup: عدد أنوية المعالج، القيمة الافتراضية هي 1. بعض المعاملات الأخرى لها تأثير على ضبط cloud-init: الخيار ‎--password password: السماح بتسجيل الدخول إلى الآلة الوهمية باستخدام حساب ubuntu وكلمة المرور المزودة مع هذا الخيار. الخيار ‎--run-script-once script_file: تشغيل السكربت script_file بامتيازات الجذر في أول مرة تُقلِع فيها الآلة الوهمية، لكنه لن يُشغَّل بعد ذلك قط. الخيار ‎--packages package_list: تثبيت الحزم المذكورة في package_list والمفصول بينها بفواصل في أول مرة تُقلِع فيها الآلة الوهمية. يتوفر شرح كامل عن كل الخيارات المتوفرة في صفحة دليل man uvt-kvm. مصادر إذا كنت مهتمًا بتعلم المزيد أو كانت لديك أسئلة أو اقتراحات، فيمكنك مناقشة فريق خادوم أوبنتو على: قناة IRC باسم ‎#ubuntu-server على خادوم Freenode. القائمة البريدية: ubuntu-server at lists.ubuntu.com. ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Cloud images and uvtool.

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

الوصول إلى مشاركة سامبا من بين استخدامات Samba نجد الاندماج مع شبكة ويندوز موجودة مسبقًا، وبعد أن يصبح سامبا جزءًا من نطاق Active Directory، فيمكن لخدمة سامبا توفير خدمات مشاركة الملفات والطباعة إلى مستخدمي AD. أبسط طريقة للانضمام إلى نطاق AD هي استخدام Likewise-open؛ لإرشادات تفصيلية، انظر إلى «Likewise Open Installation and Administration Guide». بعد أن يصبح جزءًا في نطاق Active Directory؛ أدخِل الأمر الآتي في الطرفية: sudo apt-get install samba smbfs smbclient ثم عدِّل الملف ‎/etc/samba/smb.conf مُغيِّرًا: workgroup = EXAMPLE ... security = ads realm = EXAMPLE.COM ... idmap backend = lwopen idmap uid = 50-9999999999 idmap gid = 50-9999999999 أعد تشغيل سامبا لتأخذ التعديلات الجديدة تأثيرها: sudo restart smbd sudo restart nmbd يجب أن تكون الآن قادرًا على الوصول إلى أي من مشاركات سامبا من عميل Windows؛ لكن للتأكد من إعطاء مستخدمي أو مجموعات AD الملائمة الوصول إلى مجلد مشترك؛ راجع الدرس «تأمين خادوم سامبا لتخديم الملفات والطباعة» لمزيدٍ من التفاصيل. الوصول إلى مشاركة ويندوز بعد أن أصبح خادوم سامبا جزءًا من نطاق Active Directory فتستطيع الوصول إلى أيّة مشاركات من خادوم ويندوز: أدخِل الأمر الآتي في الطرفية لوصل مشاركة من ويندوز: mount.cifs //fs01.example.com/share mount_point من الممكن الوصول إلى مشاركات على حواسيب ليست جزءًا من نطاق AD، لكن يجب توفير اسم مستخدم وكلمة مرور للوصول إليها. لوصل مشاركة مجلد أثناء الإقلاع، أضف قيدًا في ملف ‎/etc/fstab؛ على سبيل المثال: //192.168.0.5/share /mnt/windows cifs auto,username=steve,password=secret,rw 0 0 طريقة أخرى لنسخ الملفات من خادوم ويندوز هي استخدام الأداة smbclient؛ فلعرض الملفات في مشاركة ويندوز: smbclient //fs01.example.com/share -k -c "ls" لنسخ ملف من مشاركة، اكتب الأمر: smbclient //fs01.example.com/share -k -c "get file.txt" الأمر السابق سينسخ الملف file.txt إلى مجلد العمل الحالي. ولنسخ ملف إلى المشاركة: smbclient //fs01.example.com/share -k -c "put /etc/hosts hosts" الأمر السابق سينسخ الملف ‎ /etc/hostsإلى ‎//fs01.example.com/share/hosts. الخيار ‎-c المُستخدَم في الأوامر السابقة يسمح لك بتنفيذ أمر smbclient مباشرةً؛ وهذا يفيد في كتابة السكربتات والعمليات البسيطة على الملفات؛ للدخول إلى مِحَث smb‎: \>‎؛ مثل محث FTP حيث تُنفَّذ أوامر لمعالجة الملفات العادية والمجلدات، فنفِّذ الأمر: smbclient //fs01.example.com/share -k ملاحظة: استبدل كل أماكن ورود fs01.example.com، و ‎//192.168.0.5/share، و username=steve,password=secret و file.txt بعنوان IP للخادوم، واسم المشاركة، واسم الملف، واسم المستخدم الحقيقي وكلمة مروره بالقيم الملائمة. مصادر لخياراتٍ إضافية للأمر smbclient، راجع صفحة الدليل man smbclient. صفحة دليل man mount.cifs هي أيضًا مرجع مفيد لمعلومات تفصيلية. ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Active Directory Integration with Samba.

على الرغم من أن سامبا لا يمكن أن يكون Active Directory Primary Domain Controller‏ (PDC)، لكن يمكن أن يُضبَط خادوم سامبا ليظهر كمتحكم من نمط Windows NT4؛ ميزة لهذا الضبط هي قابلية جعل تصاريح المستخدمين والحواسيب مركزية؛ يمكن أيضًا أن يَستخدم سامبا عدِّة أنواع من السند الخلفي (backends) لتخزين بيانات المستخدم. متحكم رئيسي بالنطاق يشرح هذا القسم طريقة ضبط سامبا ليعمل كمتحكم رئيسي بالنطاق (PDC) باستخدام السند الخلفي الافتراضي smbpasswd. 1. أولًا، ثبِّت سامبا و libpam-smbpass لمزامنة حسابات المستخدمين؛ وذلك بإدخال اﻷمر الآتي في الطرفية: sudo apt-get install samba libpam-smbpass 2. ثم اضبط سامبا بتعديل الملف ‎/etc/samba/smb.conf؛ حيث يجب أن يُضبَط نمط security إلى user؛ ويجب أن تتعلق workgroup بمنظمتك: workgroup = EXAMPLE ... security = user 3. في قسم «Domains» المحاط بتعليقات، أضف أو أزل التعليق عمَّا يلي (قُسِّم آخر سطر إلى قسمين ليظهر بشكلٍ مفهوم): domain logons = yes logon path = \\%N\%U\profile logon drive = H: logon home = \\%N\%U logon script = logon.cmd add machine script = sudo /usr/sbin/useradd -N -g machines -c Machine -d /var/lib/samba -s /bin/false %u ملاحظة: إذا أردت عدم استخدام «Roamin Profiles» فاترك الخيارين «logon home» و «logon path» مسبوقَين بتعليق. domain logons: يوفر خدمة netlogon مما يجعل سامبا يتصرف كمتحكم بالنطاق. logon path: يضع ملف profile الخاص بويندوز في مجلد المنزل للمستخدم؛ من الممكن ضبط مشاركة [profiles] ووضع كل ملفات profile في مجلد واحد. logon home: تحديد مكان مجلد المنزل. logon script: تحديد السكربت الذي يُشغَّل محليًا بعد أن يُسجِّل المستخدم دخوله؛ يجب أن يوضع السكربت في مشاركة [netlogon]. add machine script: السكربت الذي يُنشِئ تلقائيًا الحساب Machine Trust الضروري لكي تنضم محطة العمل (workstation) إلى النطاق. في هذا المثال، أُنشِئت المجموعة machines بالأداة addgroup؛ راجع درس إدارة المستخدمين قسم «إضافة وحذف المستخدمين» لمزيدٍ من التفاصيل. 4. أزل التعليق عن مشاركة [homes] للسماح بربط logon home: [homes] comment = Home Directories browseable = no read only = no create mask = 0700 directory mask = 0700 valid users = %S 5. بعد أن يُضبَط كمتحكم بالنطاق، يجب أن تُضبَط الآن المشاركة [netlogon]، أزل التعليق عما يلي لتفعيل تلك المشاركة: [netlogon] comment = Network Logon Service path = /srv/samba/netlogon guest ok = yes read only = yes share modes = no ملاحظة: مسار مشاركة netlogon الافتراضي هو ‎/home/samba/netlogon؛ لكن وفقًا لمعيار هيكلة نظام الملفات (FHS)، إن ‎/srv هو المسار الصحيح للبيانات الموفرة من الخادوم. 6. أنشِئ الآن مجلد netlogon وملف سكربت logon.cmd فارغًا (حاليًا): sudo mkdir -p /srv/samba/netlogon sudo touch /srv/samba/netlogon/logon.cmd يمكنك إدخال أوامر سكربت Windows Logon في ملف logon.cmd لتخصيص بيئة العميل. 7. أعد تشغيل سامبا لتفعيل المتحكم بالنطاق الجديد: sudo restart smbd sudo restart nmbd 8. في النهاية، هنالك بعض الأوامر الإضافية لضبط الحقوق الملائمة. لما كان حساب الجذر معطلًا افتراضيًا، ولكي تنضم محطة عمل إلى النطاق، فيجب أن تُربَط مجموعة في النظام إلى مجموعة Windows Domain Admins؛ أدخِل الأمر الآتي الذي يستخدم الأداة net: sudo net groupmap add ntgroup="Domain Admins" unixgroup=sysadmin rid=512 type=d ملاحظة: عدِّل sysadmin إلى المجموعة التي تفضلها؛ وأيضًا يجب أن يكون المستخدم الذي ينضم إلى النطاق عضوًا في المجموعة sysadmin ومجموعة النظام admin، التي تسمح باستخدام sudo. إذا لم يحصل المستخدم على تصاريح سامبا بعد؛ فيمكنك إضافتها باستخدام الأداة smbpasswd، لا تنسَ تعديل اسم sysadmin ليلائم نظامك: sudo smbpasswd -a sysadmin أيضًا، يجب أن تكون الحقوق المعطاة إلى مجموعة Domain Admins مُحدَّدةً للسماح لإضافة machine script (والوظائف الإدارية الأخرى) بأن تعمل؛ ويمكن فعل ذلك بالأمر: net rpc rights grant -U sysadmin "EXAMPLE\Domain Admins" \ SeMachineAccountPrivilege \ SePrintOperatorPrivilege SeAddUsersPrivilege \ SeDiskOperatorPrivilege SeRemoteShutdownPrivilege 9. يجب أن تكون الآن قادرًا على ضم عملاء ويندوز إلى النطاق بنفس الطريقة التي ينضمون فيها إلى نطاق NT4 يعمل على خادوم ويندوز. متحكم احتياطي بالنطاق بوجود متحكم رئيسي بالنطاق (PDC) في الشبكة، فمن الأفضل وجود متحكم احتياطي بالنطاق (BDC) أيضًا؛ مما يسمح باستيثاق العملاء في حال أصبح المتحكم الرئيسي غير متوفرٍ. عندما تضبط سامبا كمتحكم احتياطي، فستحتاج إلى آلية لمزامنة معلومات الحسابات مع المتحكم الرئيسي؛ هنالك عدِّة طرق لفعل ذلك تتضمن scp، أو rsync، أو باستخدام LDAP كسند passdb خلفي. استخدام LDAP هو أكثر الطرق مرونةً لمزامنة معلومات الحسابات، ﻷن كلا المتحكمَين بالنطاق يستخدمان نفس المعلومات في الوقت الحقيقي؛ لكن إعداد خادوم LDAP هو أمرٌ زائد التعقيد لشبكة تحتوي عددًا قليلًا من حسابات المستخدمين والحواسيب؛ راجع درس «استخدام سامبا مع LDAP» للتفاصيل. أولًا، ثبِّت samba و libpam-smbpass، وذلك بإدخال الأمر الآتي في الطرفية: sudo apt-get install samba libpam-smbpass عدِّل الآن ملف ‎/etc/samba/smb.conf وأزل التعليق عمّا يلي في قسم [global]: workgroup = EXAMPLE ... security = user في قسم Domains المحاط بتعليق، أضف أو أزل التعليق عن: domain logons = yes domain master = no تأكد أن المستخدم لديه الحقوق لقراءة الملفات في ‎/var/lib/samba؛ على سبيل المثال، للسماح لمجموعة admin بنقل الملفات عبر scp، فأدخِل الأمر: sudo chgrp -R admin /var/lib/samba ثم، زامن حسابات المستخدمين، باستخدام scp لنسخ مجلد ‎/var/lib/samba من PDC: sudo scp -r username@pdc:/var/lib/samba /var/lib ملاحظة: استبدل username باسم مستخدم صالح، و pdc باسم PDC أو عنوان IP له. ثم في النهاية، أعِد تشغيل سامبا: sudo restart smbd sudo restart nmbd يمكنك اختبار عمل متحكم النطاق الاحتياطي بإيقاف عفريت سامبا في PDC، ثم محاولة تسجيل الدخول من عميل ويندوز موجود في النطاق. شيء آخر لتبقيه في بالك أنَّه إذا ضُبِط الخيار logon home إلى مجلد في PDC، فإذا أصبح PDC غير متوفرٍ، فإن الوصول إلى قرص المنزل للمستخدم سيصبح متعذرًا؛ لهذا السبب من الأفضل ضبط logon home ليقبع في خادوم ملفات منفصل عن PDC و BDC. مصادر الفصل الرابع والخامس من «Samba HOWTO Collection» يشرحان طريقة ضبط خادوم سامبا ليكون متحكمًا رئيسيًا واحتياطيًا بالنطاق على التوالي وبالترتيب. ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Samba as a domain controller.

أنماط حماية سامبا هنالك مستويان أمنيان متوفران لبروتوكول الشبكة «نظام ملفات الإنترنت الشائع» (Common Internet Filesystem اختصارًا CIFS) هما user-level و share-level؛ نمط الحماية المستخدم في سامبا يسمح بمرونة زائدة، موفرًا أربع طرق لاستخدام الحماية من مستوى user-level وطريقة لاستخدام share-level: النمط security=user: يتطلب من العملاء توفير اسم مستخدم وكلمة مرور للاتصال إلى المشاركات؛ حسابات المستخدمين في سامبا منفصلة عن حسابات مستخدمي النظام، لكن الحزمة libpam-smbpass ستُزامن مستخدمي النظام وكلمات مرورهم مع قاعدة بيانات مستخدمي سامبا. النمط security=domain: هذا النمط يسمح لخادوم سامبا بأن يَظهر لعملاء ويندوز كالمتحكم الرئيسي بالنطاق (Primary Domain Controller اختصارًا PDC)، أو متحكم الاحتياطي بالنطاق (Backup Domain Controller اختصارًا BDC)، أو خادوم عضو في النطاق (Domain Member Server اختصارًا DMS)، وسنشرح ذلك في الدرس القادم. النمط security=ADS: السماح لخادوم سامبا بالانضمام إلى نطاق Active Directory كعضو أصيل (native member). النمط security=server: هذا النمط تُرِك قبل أن يتمكن سامبا من أن يصبح خادومًا عضوًا، وبسبب بعض المشاكل الأمنية، فلا يجب أن يُستخدَم؛ راجع قسم «Server Security» من دليل سامبا لمزيدٍ من التفاصيل. النمط security=share: يسمح لجميع العملاء بالاتصال إلى المشاركات دون توفير اسم مستخدم وكلمة مرور. يعتمد اختيارك لنمط الحماية بالبيئة التي تعمل فيها وما الذي تريد من خادوم سامبا أن يُنجزه. النمط Security = User سيعيد هذا القسم ضبط خادوم سامبا لمشاركة الملفات والطباعة من القسمين السابقين، كي يتطلب الاستيثاق. أولًا، ثبِّت الحزمة libpam-smbpass التي ستزامن مستخدمي النظام إلى قاعدة بيانات مستخدمي سامبا: sudo apt-get install libpam-smbpass ملاحظة: لو اخترت مهمة «Samba Server» أثناء التثبيت، فستكون الحزمة libpam-smbpass مثبَّتةً مسبقًا. عدِّل الملف ‎/etc/samba/smb.conf، وعدِّل ما يلي في قسم [share]: guest ok = no في النهاية، أعد تشغيل سامبا لكي تأخذ الإعدادات الجديدة مفعولها: sudo restart smbd sudo restart nmbd سيُطلَب منك الآن إدخال اسم مستخدم وكلمة مرور عند الاتصال إلى المجلدات المشاركة أو الطابعات. ملاحظة: إذا اخترت ربط قرص شبكي للمشاركة، فعليك تفعيل الحقل «Reconnect at Logon»؛ مما يجعله يطلب اسم المستخدم وكلمة المرور مرةً واحدةً فقط، على الأقل إلى أن تُغيَّر كلمة المرور. تأمين المشاركة هنالك عدِّة خيارات متوفرة لزيادة الحماية لمشاركات المجلدات المنفصلة؛ وباستخدام مثال «[share]»، فسيشرح هذا القسم بعض الخيارات الشائعة. المجموعات تُعرِّف المجموعات تشكيلةً من الحواسيب أو المستخدمين الذي يملكون وصولًا متكررًا إلى مورد شبكي معين؛ على سبيل المثال، إذا عُرِّفت المجموعة qa وكانت تحتوي على المستخدمين freda، و danika، و rob؛ ومجموعة ثانية هي support تحتوي على المستخدمين danika، و jeremy، و vincent؛ وضُبِط مورد شبكي معيّن للسماح بالوصول إلى المجموعة qa، والذي بدوره سيمنح المستخدمين freda، و danika، و rob وصولًا لكن ليس jeremy أو vincent؛ ولما كان المستخدم danika ينتمي إلى كلي المجموعتين qa و support؛ فسيتمكن من الوصول إلى الموارد التي يُسمَح لكلا المجموعتين بالوصول إليها، بينما كل المستخدمين الباقيين سيقيدون بالموارد التي تسمح بوصول مجموعتهم إليها. يبحث سامبا عن المجموعات في النظام المحلي المُعرَّفة في ‎/etc/group ليحدد أي مستخدم ينتمي إلى أي مجموعة؛ للمزيد من المعلومات حول إضافة أو إزالة المستخدمين من المجموعات، راجع القسم «إضافة وحذف المستخدمين» من درس إدارة المستخدمين. عند تعريف المجموعات في ملف ضبط سامبا،‏ ‎/etc/samba/smb.conf؛ فإن الصيغة المتعارف عليها هي بدء اسم المجموعة بالرمز «@»؛ على سبيل المثال، إذا أردت تعريف مجموعة مسماة sysadmin في قسم محدد من ملف ‎/‎etc/samba/smb.conf، فعليك إدخال اسم المجموعة ‎@sysadmin. أذونات الملف تُعرِّف أذونات الملف الحقوق المحددة التي يملكها حاسوب أو مستخدم على مجلد أو ملف أو مجموعة ملفات؛ يمكن تعريف هذه الأذونات بتعديل الملف ‎/etc/samba/smb.conf وتحديد الأذونات لمشاركة ملف معيّن. على سبيل المثال، لو عَرَّفتَ مشاركة سامبا اسمها share وأردت إعطاء أذونات «للقراءة فقط» لمجموعة المستخدم qa؛ لكنك تريد السماح بالكتابة لمجموعة اسمها sysadmin ومستخدم اسمه vincent، فعليك تعديل الملف ‎/etc/samba/smb.conf وإضافة القيود الآتية تحت قيد [share]: read list = @qa write list = @sysadmin, vincent طريقة أخرى لضبط الأذونات في سامبا هي التصريح عن أذونات «إدارية» لمورد معيّن مُشارَك؛ حيث يمكن للمستخدمين الذي يملكون أذونات إدارية قراءة أو كتابة أو تعديل أيّة معلومات موجودة في المورد الذي أُعطي ذاك المستخدم أذوناتٍ إدارية خاصة عليه. على سبيل المثال، إذا أردت إعطاء المستخدم melissa أذوناتٍ إدارية للمشاركة share، فعليك تعديل الملف ‎/etc/samba/smb.conf وإضافة الأسطر الآتية تحت القيد [share]: admin users = melissa بعد تعديل الملف ‎/etc/samba/smb.conf، أعد تشغيل سامبا كي تأخذ التعديلات مجراها: sudo restart smbd sudo restart nmbd ملاحظة: لكي تعمل «read list» و «write list»، لا يجب أن يكون نمط حماية المستخدم في سامبا مضبوطًا إلى security = share. ضُبِط الآن سامبا ليحدد أيّة مجموعات تملك الوصول إلى مجلد مُشارَك، يجب الآن تحديث أذونات نظام الملفات. نظام أذونات لينُكس التقليدي لا يترابط جيدًا مع قوائم التحكم بالوصول في ويندوز (NT (Windows NT Access Control Lists اختصارًا ACLs؛ لحسن الحظ، توجد POSIX ACLs في خواديم أوبنتو موفرةً تحكمًا أفضل؛ على سبيل المثال، للسماح باستخدام ACLs على ‎/srv بنظام ملفات EXT3، فعدِّل الملف ‎/etc/fstab وأضف الخيار acl كما يلي: UUID=66bcdd2e-8861-4fb0-b7e4-e61c569fe17d /srv ext3 noatime,relatime,acl 0 1 ثم أعد وصل القسم: sudo mount -v -o remount /srv ملاحظة: تفترض الأوامر السابقة أن ‎/srv على قسمٍ مختلف؛ إذا كان ‎/srv، أو أي مسار آخر تختار مشاركته، هو جزء من قسم الجذر /، فربما عليك إعادة إقلاع النظام. لمطابقة ضبط سامبا، فستُعطى المجموعة sysadmin أذونات القراءة والكتابة والتنفيذ إلى ‎/srv/samba ‎/share، وستُعطى المجموعة qa إذنَيّ القراءة والتنفيذ؛ وستُملَك الملفات من المستخدم melissa. أدخِل الأوامر الآتية في الطرفية: sudo chown -R melissa /srv/samba/share/ sudo chgrp -R sysadmin /srv/samba/share/ sudo setfacl -R -m g:qa:rx /srv/samba/share/ ملاحظة: الأمر setfacl السابق يعطي أذونات التنفيذ إلى جميع الملفات في المجلد ‎/‎srv/samba/share، ربما يكون أو لا يكون هذا ما تريده. الآن من عميل ويندوز، يجب أن تلاحظ تطبيق الأذونات الجديدة للملف؛ راجع صفحات دليل acl و setfacl لمزيد من المعلومات حول POSIX ACLs. ملف ضبط سامبا لبرمجية AppArmor يأتي أوبنتو مع وحدة الحماية AppArmor، الذي يوفر تحكمًا مقيّدًا للوصول؛ ملف الضبط الافتراضي الخاص ببرمجية AppArmor لخدمة سامبا يجب أن يلائم ضبطك، للمزيد من التفاصيل حول استخدام AppArmor راجع درس AppArmor. هنالك ملفات ضبط افتراضية لكلي ‎/usr/sbin/smbd و ‎/usr/sbin/nmbd (الملفات الثنائية لعفريت سامبا) كجزءٍ من حزمة apparmor-profiles؛ أدخِل الأمر الآتي من الطرفية لتثبيت الحزمة: sudo apt-get install apparmor-profiles apparmor-utils افتراضيًا، تكون ملفات الضبط لعفريتي smbd و nmbd في وضع «البناء» مما يسمح لخدمة سامبا بالعمل دون تعديل ملف الضبط، وستُسجَّل الأخطاء فقط؛ لجعل ملف ضبط smbd في وضع «الإجبار»، ولكي يعمل سامبا كما يجب، فيجب أن يُعدَّل ملف الضبط لتضمين المجلدات التي تمت مشاركتها. عدِّل ملف ‎/etc/apparmor.d/usr.sbin.smbd مضيفًا معلومات [share]: /srv/samba/share/ r, /srv/samba/share/** rwkix, ضع الملف في وضع «الإجبار» وأعد تحميله: sudo aa-enforce /usr/sbin/smbd cat /etc/apparmor.d/usr.sbin.smbd | sudo apparmor_parser -r يجب أن تكون قادرًا على قراءة وكتابة وتنفيذ الملفات في المجلد المُشارَك كالمعتاد، لكن smbd يملك الآن حق الوصول إلى الملفات والمجلدات المضبوطة فقط؛ تأكد من إضافة القيود لكل مجلد تضبط مشاركته في سامبا؛ وستسجل أيضًا أيّة أخطاء إلى ‎/var/log/syslog. مصادر الفصل الثامن عشر من «Samba HOWTO Collection» مخصصٌ للحماية. للمزيد من المعلومات حول Samba و ACLs، راجع الصفحة «Samba ACLs». راجع أيضًا صفحة ويكي أوبنتو «Samba». ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Securing File and Printer.

تتألف شبكات الحواسيب عادةً من خليط من أنظمة التشغيل، وعلى الرغم من أن شبكة مبنية كاملًا من حواسيب بأنظمة خادوم وسطح مكتب أوبنتو يمكن أن تكون ذات فائدة عظيمة؛ إلّا أن بعض بيئات الشبكة يجب أن تحتوي على أنظمة أوبنتو ومايكروسوفت® ويندوز® تعمل سويةً بتناغم؛ سيقدم هذا الدرس المبادئ الأساسية والأدوات المستخدم في ضبط خادوم أوبنتو لمشاركة موارد الشبكة مع حواسيب ويندوز. مقدمة يتطلب التواصل الشبكي الناجح بين خادوم أوبنتو وعملاء ويندوز توفير ودمج الخدمات الشائعة لبيئات ويندوز؛ تساعد مثل هذه الخدمات في مشاركة البيانات والمعلومات عن الحواسيب والمستخدمين الموجودين في الشبكة، ويمكن تصنيفها تحت ثلاثة تصنيفات للوظائف التي تؤديها: خدمات مشاركة الملفات والطابعات. استخدام بروتوكول «Server Message Block» (اختصارًا SMB) لتسهيل مشاركة الملفات والمجلدات والأقراص ومشاركة الطابعات عبر الشبكة. خدمات الدليل (Directory). مشاركة المعلومات الحيوية عن الحواسيب ومستخدمي الشبكة باستخدام تقنيات مثل LDAP و ®Microsoft Active Directory. الاستيثاق والوصول. التحقق من هوية حاسوب أو مستخدم للشبكة وتحديد المعلومات التي يُصرَّح للحاسوب أو المستخدم بالوصول إليها عبر تقنيات مثل أذونات الملفات، وسياسات المجموعات، وخدمة الاستيثاق Kerberos. لحسن الحظ، يمكن لخادوم أوبنتو توفير هذه الخدمات إلى عملاء ويندوز ومشاركة موارد الشبكة معهم؛ واحد من أهم البرمجيات التي يتضمنها نظام أوبنتو للتعامل الشبكي مع ويندوز هو مجموعة أدوات وتطبيقات خادوم SMB المُسمى سامبا. سيقدم هذا الدرس بعض حالات استخدام سامبا الشائعة، وطريقة تثبيت وضبط الحزم الضرورية؛ تفاصيلٌ إضافيةٌ يمكن العثور عليها في موقع سامبا. خادوم الملفات أحد أشهر الطرق للتواصل الشبكي بين أوبنتو وويندوز هو ضبط سامبا كخادوم ملفات؛ يشرح هذا القسم طريقة ضبط خادوم سامبا لمشاركة الملفات مع عملاء ويندوز. سيُضبَط الخادوم لمشاركة الملفات مع أي عميل على الشبكة دون طلب كلمة مرور منه؛ إذا كانت بيئتك تتطلب متحكمات بالوصول أكثر تقييدًا ، فراجع القسم «تأمين خادوم سامبا لتخديم الملفات والطباعة». التثبيت أول خطوة هي تثبيت حزمة samba؛ وذلك بإدخال الأمر الآتي من الطرفية: sudo apt-get install samba هذا كل ما عليك فعله! يجب أن تكون الآن جاهزًا لضبط سامبا لمشاركة الملفات. الضبط ملف ضبط سامبا الرئيسي موجودٌ في ‎/etc/samba/smb.conf؛ توجد كميةٌ كبيرةٌ من التعليقات في ملف الضبط لتوثيق مختلف تعليمات الضبط. ملاحظة: لا تُضمَّن جميع الخيارات المتوفرة في ملف الضبط الافتراضي؛ راجع صفحة الدليل للملف smb.conf أو مجموعة «Samba HOWTO». أولًا، عدِّل الأزواج المفتاح/القيمة في القسم [global] من ملف ‎/etc/samba/smb.conf: workgroup = EXAMPLE ... security = user المعامل security موجودٌ في أسفل قسم [global]، ويوجد قبله تعليق افتراضيًا؛ غيِّر أيضًا القيمة EXAMPLE إلى قيمة تلائم بيئتك. أنشِئ قسمًا جديدًا في نهاية الملف -أو أزل التعليق عن أحد الأمثلة- للمجلد الذي تريد أن تشاركه: [share] comment = Ubuntu File Server Share path = /srv/samba/share browsable = yes guest ok = yes read only = no create mask = 0755 comment: وصف قصير عن المشاركة، عدِّله ليناسب احتياجاتك. path: مسار المجلد الذي تريد مشاركته؛ يستخدم هذا المثال ‎/srv/samba/sharename لأنه وفقًا لمعيار هيكلة نظام الملفات (Filesystem Hierarchy Standard اختصارًا FHS)، فإن ‎/srv3 هو مكان تخزين البيانات التي ستُخدَّم؛ ويمكن (تقنيًا) أن تكون مشاركات سامبا في أي مكان في نظام الملفات لطالما كانت الأذونات صحيحةً، لكن الالتزام بالمعايير أمرٌ حسن. browsable: يفعِّل إمكانية تصفح عملاء ويندوز للمجلد باستخدام «مستكشف الملفات». guest ok: يسمح للعملاء بالاتصال إلى المشاركة دون توفير كلمة مرور. read only: تحديد إذا ما كانت المشاركة للقراءة فقط أم كان إذن الكتابة معطيًا؛ يُعطى إذن الكتابة فقط عندما تكون القيمة هي no (كما هو الحال في هذا المثال) إذا كانت القيمة yes، فإن الوصول للمشاركة سيكون للقراءة فقط. create mask: تحديد أذونات الملفات الجديدة عندما تُنشَأ. بعد أن ضُبِطَ سامبا، فيجب إنشاء المجلد وتغيير الأذونات؛ وذلك بإدخال الأمر الآتي من الطرفية: sudo mkdir -p /srv/samba/share sudo chown nobody.nogroup /srv/samba/share/ ملاحظة: الخيار ‎-p يخُبِر mkdir بأن يُنشِئ كامل شجرة المجلد إن لم تكن موجودةً. في النهاية، أعد تشغيل خدمات samba لتفعيل الضبط الجديد: sudo restart smbd sudo restart nmbd تحذير: يسمح الضبط السابق بالوصول لأي مستخدم في الشبكة المحلية، لضبط أكثر أمانًا راجع القسم «تأمين خادوم سامبا لتخديم الملفات والطباعة». تستطيع الآن من عميل ويندوز أن تكون قادرًا على تصفح خادوم أوبنتو للملفات ورؤية مشاركة المجلد؛ إذا لم تظهر المشاركة عند عميلك تلقائيًا، فحاول أن تصل إلى الخادوم عبر عنوان IP الخاص به؛ مثلًا، ‎ \\192.168.1.1 في نافذة مستكشف الملفات، حاول إنشاء مجلد من ويندوز للتحقق من أن كل شيء يعمل على ما يرام. لمشاركة مجلدات إضافية، فأنشِئ ببساطة أقسام [dir] في ‎/etc/samba/smb.conf وأعد تشغيل خدمة سامبا؛ عليك أن تتأكد أن المجلد الذي تريد مشاركته موجود فعلًا، والأذونات المُعطاة له صحيحة. ملاحظة: المشاركة المُسماة «[share]» والمسار ‎/srv/samba/share هما مجرد مثالين؛ عدِّل اسم ومسار المشاركة لملائمة بيئتك؛ فكرة جيدة هي تسمية اسم المشاركة باسم المجلد في نظام الملفات؛ مثال آخر سيكون مشاركةً باسم [qa] بمسار ‎/srv/samba/qa. مصادر كتاب «Using Samba» من O'Reilly هو مصدر جيد للمعلومات. صفحة ويكي أوبنتو «Samba» فيها بعض المعلومات. خادوم سامبا للطباعة استخدام شائع آخر لخادوم سامبا هو ضبطه لمشاركة الطابعات المثبتة إما محليًا أو عبر الشبكة على خادوم أوبنتو؛ وبآليةٍ شبيهةٍ بالآلية في قسم «خادوم ملفات سامبا»، سيضبط هذا القسم سامبا للسماح لأي عميل في الشبكة المحلية باستخدام الطابعات المثبتة دون طلب اسم مستخدم وكلمة مرور. لضبط أكثر أمانًا، راجع القسم الآتي «تأمين خادوم سامبا لتخديم الملفات والطباعة». التثبيت قبل تثبيت وضبط سامبا، من الأفضل أن يكون لديك تثبيت CUPS يعمل جيدًا، راجع القسم «خادوم الطباعة CUPS» في الدرس الخاص به لمزيدٍ من المعلومات. أدخِل ما يلي في الطرفية لتثبيت حزمة samba: sudo apt-get install samba الضبط بعد تثبيت سامبا، عدِّل الملف ‎/etc/samba/smb.conf مغيّرًا الخاصية workgroup إلى القيمة الملائمة لشبكتك، وعدِّل قيمة security إلى user: workgroup = EXAMPLE ... security = user عدِّل قيمة الخيار guest ok إلى yes في قسم [printers]: browsable = yes guest ok = yes أعد تشغيل سامبا بعد إتمام تعديل ملف smb.conf: sudo restart smbd sudo restart nmbd سيشارك ضبط سامبا الافتراضي كل الطابعات المثبتة، كل ما عليك فعله هو تثبيت الطابعة محليًا على عملاء ويندوز. مصادر راجع موقع CUPS لمزيد من المعلومات حول ضبط CUPS. ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Samba.

سنناقش في هذا الدرس كيفية تثبيت وضبط خادوم 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.

واحدة من أكبر المشاكل مع البريد الإلكتروني اليوم هي مشكلة البريد غير المرغوب فيه (Unsolicited Bulk Email أو اختصارًا UBE) المعروف أيضًا بالبريد العشوائي (SPAM)؛ قد تحتوي هذه الرسائل أيضًا على فيروسات أو أشكالٍ أخرى من البرمجيات الخبيثة؛ ووفقًا لبعض التقارير، تشغل هذه الرسائل حيزًا كبيرًا من البريد الإلكتروني المُرسَل عبر الإنترنت. سيشرح هذا القسم طريقة دمج Amavisd-new، و Spamassassin، و ClamAV مع عميل نقل البريد Postfix؛ يمكن أيضًا التحقق من البريد عبر تمريره خلال مرشحات خارجية؛ هذه المرشحات يمكنها في بعض الأحيان تحديد إذا ما كانت الرسالةُ عشوائيةً دون الحاجة إلى معالجتها ببرمجيات تستهلك الموارد؛ أشهر هذه المرشحات هي opendkim و python-policyd-spf. Amavisd-new هو برنامج مُغلِّف (wrapper) يستطيع استدعاء أي عدد من برامج ترشيح المحتوى لاستكشاف الرسائل العشوائية، وللتصدي للفيروسات ...إلخ. يستخدم Spamassassin آلياتٍ عدِّة لترشيح البريد اعتمادًا على محتوى الرسالة. ClamAV هو مضاد فيروسات مفتوح المصدر. يوفر opendkim ما يسمىMilter (أي Sendmail Mail Filter) إلى المعيار القياسي DKIM (أي DomainKeys Identified Mail). يُفعِّل python-policyd-spf تحقق SPF (اختصار للعبارة Sender Policy Framework) مع Postfix. هذه هي آلية جمع القطع السابقة: تُقبَل رسالة البريد الإلكتروني من Postfix. تُمرَّر الرسالة إلى أي مرشحات خارجية مثل opendkim و python-policyd-spf في هذه الحالة. ثم يُعالِج Amavisd-new الرسالة. ثم يُستخدَم ClamAV لفحص الرسالة؛ إذا حوت الرسالة على فيروس، فسيرفضها Postfix. ستُحلَّل الرسائل «النظيفة» من Spamassassin للتحقق إذا كانت الرسالة هي رسالة عشوائية؛ ثم يضيف Spamassassin أسطر X-Header ليسمح للبرمجية Amavisd-new بإكمال معالجة الرسالة. على سبيل المثال، إذا كان «رصيد العشوائية» لرسالة ما أكبر من خمسين بالمئة، فيمكن أن تُزال الرسالة تلقائيًا من الطابور (queue) حتى دون إعلام المتلقي؛ طريقة أخرى للتعامل مع هذه الرسائل هي إيصالهم لعميل مستخدم البريد (MUA) والسماح للمستخدم بأن يتعامل مع الرسالة بما يراه مناسبًا. التثبيت راجع درس Postfix لمعلوماتٍ تفصيلية عن تثبيت Postfix. أدخل الأمرين الآتيين في سطر الأوامر لتثبيت بقية البرمجيات: sudo apt-get install amavisd-new spamassassin clamav-daemon sudo apt-get install opendkim postfix-policyd-spf-python هنالك بعض الحزم الأخرى التي يمكن أن تُدمَج مع Spamassassin لاكتشاف أفضل للرسائل العشوائية: sudo apt-get install pyzor razor بالإضافة إلى برمجيات الترشيح الرئيسية، سنحتاج إلى أدوات الضغط لنعالج بعض مرفقات البريد: sudo apt-get install arj cabextract cpio lha nomarch pax rar unrar unzip zip ملاحظة: إذا لم يُعثَر على بعض الحزم السابقة، فتأكد من تفعيل مستودع multiverse في ملف ‎/etc/apt/sources.list. إذا أجريتَ تعديلاتٍ على ذاك الملف، فتأكد من تحديث فهرس الحزم بتنفيذ الأمر sudo apt-get update قبل محاولة التثبيت مرةً أخرى. الضبط علينا الآن ضبط كل شيء مع بعضه بعضًا لترشيح البريد. ClamAV السلوك الافتراضي لبرمجية ClamAV تناسب احتياجاتنا؛ للمزيد من خيارات الضبط الخاصة ببرمجية ClamAV، راجع ملفات الضبط في ‎/etc/clamav. أضف المستخدم clamav إلى المجموعة amavis لكي يملك Amavisd-new الوصول الملائم لتفحص الملفات: sudo adduser clamav amavis sudo adduser amavis clamav Spamassassin يعثر Spamassassin تلقائيًا على المكونات الإضافية ويستخدمها إن توفرت؛ هذا يعني أنه لا حاجة لضبط pyzor و razor. عدِّل ملف الضبط ‎/etc/default/spamassassin لتفعيل عفريت Spamassassin، عدِّل قيمة ENABLED=0 إلى: ENABLED=1 ثم ابدأ تشغيل العفريت: sudo service spamassassin start Amavisd-new أولًا، فعِّل استكشاف الرسائل العشوائية ومضاد الفيروسات في Amavisd-new بتعديل الملف ‎/etc/amavis‎/conf.d/15-content_filter_mode: use strict; # You can modify this file to re-enable SPAM checking through spamassassin # and to re-enable antivirus checking. # # Default antivirus checking mode # Uncomment the two lines below to enable it # @bypass_virus_checks_maps = ( \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re); # # Default SPAM checking mode # Uncomment the two lines below to enable it # @bypass_spam_checks_maps = ( \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re); 1; # insure a defined return قد تكون إعادة معالجة الرسائل العشوائية فكرةً سيئةً لأن العنوان المُعاد مزيفٌ غالبًا؛ ربما ترغب بتعديل الملف ‎/etc/amavis/conf.d/20-debian_defaults لتضبط ‎$final_spam_destiny إلى D_DISCARD بدلًا من D_BOUNCE، كما يلي: $final_spam_destiny = D_DISCARD; وربما ترغب بتعديل قيمة الخيارات الآتية لتعليم (flag) المزيد من الرسائل كرسائل عشوائية: $sa_tag_level_deflt = -999; # add spam info headers if at, or above that level $sa_tag2_level_deflt = 6.0; # add 'spam detected' headers at that level $sa_kill_level_deflt = 21.0; # triggers spam evasive actions $sa_dsn_cutoff_level = 4; # spam level beyond which a DSN is not sent إذا كان اسم المضيف للخادوم (hostname) مختلفًا عن سجل MX للنطاق، فربما تحتاج إلى أن تضبط الخيار ‎$myhostname يدويًا؛ وإذا كان الخادوم يستلم البريد لأكثر من نطاق، فيجب تخصيص الخيار ‎@local_domains_acl أيضًا، وذلك بتعديل الملف ‎/etc/amavis/conf.d/50-user: $myhostname = 'mail.example.com'; @local_domains_acl = ( "example.com", "example.org" ); إذا أردت تغطية أكثر من نطاق، فعليك استخدام ما يلي في ‎/etc/amavis/conf.d/50-user: @local_domains_acl = qw(.); يجب إعادة تشغيل Amavisd-new بعد الضبط: sudo service amavis restart DKIM Whitelist يمكن ضبط Amavisd-new ليضيف عناوين من نطاقات معينة مع مفاتيح نطاق (Domain Keys) صالحة إلى القائمة البيضاء (Whitelist)؛ هنالك بعض النطاقات المضبوطة مسبقًا في ‎/etc/amavis/conf.d/40-policy_banks: هذه بعض الأمثلة لضبط القائمة البيضاء لنطاق: التعليمة ‎'example.com' => 'WHITELIST',‎: ستضيف أي عنوان من النطاق "example.com" إلى القائمة البيضاء. التعليمة ‎'‎.example.com' => 'WHITELIST‎'‎,‎: ستضيف أي عنوان من أي نطاق فرعي للنطاق "example.com" ويملك توقيع صالح (valid signature) إلى القائمة البيضاء. التعليمة ‎'‎.example.com/@example.com' => 'WHITELIST',‎: إضافة أي عنوان من النطاقات الفرعية للنطاق "example.com" الذي يستخدم توقيع النطاق الأب "example.com". التعليمة ‎'‎./@example.com' => 'WHITELIST',‎: يضيف العناوين من توقيع صالح من "example.com" هذا يستخدم عادةً لمجوعات النقاش التي توقَّع رسائلها. يمكن أن يملك نطاقٌ واحد أكثر من ضبط للقائمة البيضاء؛ عليك إعادة تشغيل amavisd-new بعد تعديل الملف: sudo service amavis restart ملاحظة: في هذا السياق؛ عندما يُضاف النطاق إلى القائمة البيضاء، فإن الرسالة لن تحصل على أي فحص من الفيروسات أو الرسائل العشوائية؛ ربما يكون أو لا يكون هذا هو السلوك الذي ترغبه لهذا النطاق. Postfix أدخل ما يلي في مِحَث الطرفية لدمج Postfix: sudo postconf -e 'content_filter = smtp-amavis:[127.0.0.1]:10024' ثم عدِّل الملف ‎/etc/postfix/master.cf وأضف الأسطر الآتية إلى نهاية الملف: smtp-amavis unix - - - - 2 smtp -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes -o disable_dns_lookups=yes -o max_use=20 127.0.0.1:10025 inet n - - - - smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_delay_reject=no -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters أيضًا أضف السطرين الآتيين مباشرةً بعد خدمة النقل «pickup»: -o content_filter= -o receive_override_options=no_header_body_checks هذا سيمنع الرسائل المُولَّدة للتبليغ عن الرسائل العشوائية من تصنيفها كرسائل عشوائية؛ أعد الآن تشغيل Postfix: sudo service postfix restart يجب الآن أن يكون ترشيح المحتوى والعثور على الفيروسات مُفعَّلًا. الاختبار أولًا، اختبر أن Amavisd-new SMTP يستمع: telnet localhost 10024 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 [127.0.0.1] ESMTP amavisd-new service ready ^] وفي ترويسة (header) الرسائل التي تُمرَّر عبر مُرشِّح المحتوى، يجب أن تُشاهِد: X-Spam-Level: X-Virus-Scanned: Debian amavisd-new at example.com X-Spam-Status: No, hits=-2.3 tagged_above=-1000.0 required=5.0 tests=AWL, BAYES_00 X-Spam-Level: ملاحظة: قد تختلف النتائج المعروضة عمَّا سيظهر عندك، لكن من المهم وجود القيدين X-Virus-Scanned و X-Spam-Status. استكشاف الأخطاء أفضل طريقة لمعرفة سبب حدوث مشكلة ما هي مراجعة ملفات السجل. لتعليماتٍ عن التسجيل في Postfix راجع الدرس الخاص به. يستخدم Amavisd-new البرمجية Syslog لإرسال الرسائل إلى ‎/var/log/mail.log؛ يمكن زيادة مقدار التفاصيل بإضافة الخيار ‎$log_level إلى ملف ‎/etc/amavis/conf.d/50-user، وضبط القيمة من 1 إلى 5: $log_level = 2; ملاحظة: عند زيادة درجة الإسهاب لسجل Amavisd-new، فسيزداد ناتج سجل Spamassassin أيضًا. يمكن زيادة مستوى التسجيل لبرمجية ClamAV بتعديل الملف ‎/etc/clamav/clamd.conf وضبط الخيار الآتي: LogVerbose true افتراضيًا، سيُرسِل ClamAV رسائل السجل إلى ‎/var/log/clamav/clamav.log. ملاحظة: بعد تغيير إعدادات التسجيل للبرمجيات، تذكر أن تعيد تشغيل الخدمة لكي تأخذ الإعدادات الجديدة مفعولها؛ أيضًا تذكر أن تعيد القيمة الافتراضية بعد أن تحل المشكلة. مصادر للمزيد من المصادر حول ترشيح البريد، راجع الوصلات الآتية: توثيق Amavisd-new. توثيق ClamAV وويكي ClamAV. ويكي Spamassassin. صفحة Pyzor الرئيسية. صفحة Razor الرئيسية. DKIM.org Postfix Amavis New أيضًا، تستطيع أن تسأل أسئلتك في قناة ‎#ubuntu-sever على خادوم freenode. ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Mail Filtering.

Mailman هو برمجية مفتوحة المصدر لإدارة نقاشات البريد الإلكتروني وقوائم الأخبار الإلكترونية؛ وتعتمد العديد من قوائم البريد المفتوحة المصدر (بما فيها قوائم بريد أوبنتو) على Mailman كبرمجية قوائم البريد؛ حيث أنها قوية وسهلة التثبيت والإدارة. التثبيت يوفر Mailman واجهة ويب للمدراء والمستخدمين؛ مستخدمًا خادوم بريد خارجي لإرسال واستقبال الرسائل؛ حيث يعمل عملًا ممتازًا مع خواديم البريد الآتية: Postfix Exim Sendmail Qmail سنتعلم طريقة تثبيت وضبط Mailman مع خادوم ويب أباتشي ومع أحد خادومَي البريد Postfix أو Exim؛ إذا أردت استخدام Mailman مع خادوم بريد مختلف، فرجاءً عُد إلى قسم المصادر لمزيدٍ من المعلومات. ملاحظة: تحتاج إلى خادوم بريد وحيد فقط، و Postfix هو عميل نقل البريد الافتراضي في أوبنتو. Apache2 لتثبيت apache2، راجع درس إعداد خادوم أباتشي لمزيدٍ من التفاصيل. Postfix راجع درس Postfix لتعليمات عن تثبيت وضبط Postfix. Exim4 لتثبيت Exim4، راجع الدرس الذي شرحنا ذلك فيه. تُخزَّن ملفات الضبط في مجلد ‎ /etc/exim4بعد تثبيت exim4؛ وتكون ملفات ضبط exim4 مقسمة إلى عدة ملفات مختلفة افتراضيًا في أوبنتو؛ يمكنك تغيير هذا السلوك بتعديل قيمة المتغير الآتي في ملف ‎/etc/exim4 ‎/update-exim4.conf: dc_use_split_config='true' Mailman نفِّذ الأمر الآتي في الطرفية لتثبيت Mailman: sudo apt-get install mailman تنسخ هذه الحزمة ملفات التثبيت إلى مجلد ‎/var/lib/mailman، وتثبت سكربتات CGI في ‎/usr/lib/cgi-bin/mailman؛ وستُنشِئ مستخدم لينُكس المسمى list، وكذلك تُنشِئ المجموعة list؛ ستُملَك عملية mailman لهذا المستخدم. الضبط يفترض هذا القسم أنك ثبتت mailman و apache2 و postfix أو exim4 بنجاح؛ كل ما بقي عليك هو ضبطهم. Apache2 مثالٌ عن ملف ضبط أباتشي يأتي مع Mailman وهو موجود في ‎/etc/mailman/apache.conf، ولكي يستخدم أباتشي ملف الضبط هذا، فيجب أن يُنسَخ إلى ‎/etc/apache2/sites-available: sudo cp /etc/mailman/apache.conf /etc/apache2/sites-available/mailman.conf هذا سيُنشِئ مضيفًا وهميًا في أباتشي لموقع إدارة Mailman؛ فعِّل الآن الضبط الجديد وأعد تشغيل أباتشي: sudo a2ensite mailman.conf sudo service apache2 restart يستخدم Mailman أباتشي ليشغِّل سكربتات CGI؛ تكون سكربتات CGI مثبتةً في ‎/usr/lib/cgi-bin/mailman، هذا يعني أن وصلة mailman ستكون http://hostname/cgi-bin/mailman؛ يمكنك إجراء تعديلات إلى ملف ‎/etc/apache2/sites-available/mailman.conf لتعديل هذا السلوك. Postfix سنربط النطاق lists.example.com مع القائمة البريدية للدمج مع Postfix؛ رجاءً استبدل lists.example.com بالنطاق الذي تختاره. يمكنك استخدام الأمر postconf لإضافة الضبط الضروري إلى ملف ‎/etc/postfix/main.cf: sudo postconf -e 'relay_domains = lists.example.com' sudo postconf -e 'transport_maps = hash:/etc/postfix/transport' sudo postconf -e 'mailman_destination_recipient_limit = 1' انظر أيضًا في ‎/etc/postfix/master.cf للتحقق من أن لديك «الناقل» (transporter) الآتي: mailman unix - n n - - pipe flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py ${nexthop} ${user} هذا سيستدعي السكربت postfix-to-mailman.py عندما يُسلَّم بريدٌ ما إلى القائمة. اربط بين النطاق lists.example.com إلى ناقل Mailman باستخدام خريطة الربط (transport map)، وعدِّل الملف ‎/etc/postfix/transport: lists.example.com mailman: عليك الآن جعل Postfix يبني خريطة الربط بإدخال الأمر الآتي في الطرفية: sudo postmap -v /etc/postfix/transport ثم أعد تشغيل Postfix لتفعيل الضبط الجديد: sudo service postfix restart Exim4 تستطيع تشغيل خادوم Exim بإدخال الأمر الآتي في الطرفية بعد تثبيت Exim4: sudo service exim4 start ولجعل mailman يعمل مع Exim4، فيجب عليك أن تضبط Exim4؛ وكما ذُكِرَ سابقًا، يستخدم Exim4 افتراضيًا عدِّة ملفات ضبط للأنواع المختلفة؛ لمزيد من التفاصيل، ارجع إلى موقع ويب Exim. يجب عليك إضافة ملف ضبط جديد يحتوي على أنواع الضبط الآتية لتشغيل mailman: Main (الرئيسي). Transport (النقل). Router (الموجه). يُنشِئ Exim ملف ضبط رئيسي بترتيب كل ملفات الضبط الصغيرة هذه؛ ولذلك ترتيب هذه الملفات أمرٌ ضروريٌ جدًا. الرئيسي جميع ملفات الضبط التي تنتمي إلى النوع الرئيسي (Main) يجب أن تُخزَّن في مجلد ‎/etc/exim4/conf.d/main/‎‎، يمكنك إضافة المحتويات الآتية في ملف جديد مُسمى ‎04_exim4-config_mailman: # start # Home dir for your Mailman installation -- aka Mailman's prefix # directory. # On Ubuntu this should be "/var/lib/mailman" # This is normally the same as ~mailman MM_HOME=/var/lib/mailman # # User and group for Mailman, should match your --with-mail-gid # switch to Mailman's configure script. Value is normally "mailman" MM_UID=list MM_GID=list # # Domains that your lists are in - colon separated list # you may wish to add these into local_domains as well domainlist mm_domains=hostname.com # # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # # These values are derived from the ones above and should not need # editing unless you have munged your mailman installation # # The path of the Mailman mail wrapper script MM_WRAP=MM_HOME/mail/mailman # # The path of the list config file (used as a required file when # verifying list addresses) MM_LISTCHK=MM_HOME/lists/${lc::$local_part}/config.pck # end النقل جميع الملفات التي تنتمي إلى نوع النقل (transport) يجب أن تُخزَّن في مجلد ‎/etc/exim4/conf.d/transport/‎؛ تستطيع إضافة المحتويات الآتية إلى ملف جديد باسم ‎40_exim4-config_mailman: mailman_transport: driver = pipe command = MM_WRAP \ '${if def:local_part_suffix \ {${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \ {post}}' \ $local_part current_directory = MM_HOME home_directory = MM_HOME user = MM_UID group = MM_GID الموجه جميع الملفات التي تنتمي إلى نوع الموجه (router) يجب أن تُخزَّن في مجلد ‎/etc/exim4/conf.d/router/‎؛ تستطيع إضافة المحتويات الآتية إلى ملف جديد باسم 101‎_exim4-config_mailman: mailman_router: driver = accept require_files = MM_HOME/lists/$local_part/config.pck local_part_suffix_optional local_part_suffix = -bounces : -bounces+* : \ -confirm+* : -join : -leave : \ -owner : -request : -admin transport = mailman_transport تحذير: ترتيب ملفات الضبط «الرئيسي» و«النقل» غير مهم، لكن ترتيب ملفات ضبط التوجيه مهم؛ حيث يجب أن يظهر هذا الملف قبل ملف 200‎_exim4-config_primary؛ هذان الملفان يحتويان على نفس نوع المعلومات، وتكون الأولوية للذي يأتي أولًا. Mailman بعد تثبيت mailman، تستطيع تشغيله بالأمر الآتي: sudo service mailman start عليك الآن إنشاء قائمة بريدية افتراضية؛ وذلك بتنفيذ ما يلي: sudo /usr/sbin/newlist mailman Enter the email address of the person running the list: bhuvan at ubuntu.com Initial mailman password: To finish creating your mailing list, you must edit your /etc/aliases (or equivalent) file by adding the following lines, and possibly running the `newaliases' program: ## mailman mailing list mailman: "|/var/lib/mailman/mail/mailman post mailman" mailman-admin: "|/var/lib/mailman/mail/mailman admin mailman" mailman-bounces: "|/var/lib/mailman/mail/mailman bounces mailman" mailman-confirm: "|/var/lib/mailman/mail/mailman confirm mailman" mailman-join: "|/var/lib/mailman/mail/mailman join mailman" mailman-leave: "|/var/lib/mailman/mail/mailman leave mailman" mailman-owner: "|/var/lib/mailman/mail/mailman owner mailman" mailman-request: "|/var/lib/mailman/mail/mailman request mailman" mailman-subscribe: "|/var/lib/mailman/mail/mailman subscribe mailman" mailman-unsubscribe: "|/var/lib/mailman/mail/mailman unsubscribe mailman" Hit enter to notify mailman owner... # لقد ضبطنا إما Postfix أو Exim4 للتعرف على كل البريد من mailman؛ لذلك ليس ضروريًا إنشاء أيّة قيود جديدة في ‎/etc/aliases؛ إذا أجريت أيّة تعديلات إلى ملفات الضبط، فرجاءً تأكد أنك أعدت تشغيل هذه الخدمات قبل الإكمال إلى القسم الآتي. ملاحظة: لا يَستخدِم Exim4 الأسماء البديلة في الأعلى لتمرير البريد إلى Mailman، حيث أنه يستخدم طريقة «الاكتشاف»؛ لتجاهل الأسماء البديلة (aliases) عند إنشاء القائمة، فأضف السطر MTA=None إلى ملف ضبط Mailman، الذي هو ‏‎/etc/mailman/mm_cfg.py. الإدارة لنفرض أن لديك تثبيتًا افتراضيًا وأنَّك أبقيت على سكربتات CGI في المجلد ‎/usr/lib/cgi-bin/mailman/‎. يوفر Mailman أداة ويب للإدارة؛ وجِّه متصفحك إلى العنوان الآتي للوصول إليها: http://hostname/cgi-bin/mailman/admin ستظهر القائمة البريدية الافتراضية على الشاشة وهي mailman؛ إذا ضغطت على اسم القائمة البريدية، فستُسأل عن كلمة المرور للاستيثاق؛ إذا أدخلت كلمة مرور صحيحة، فستكون قادرًا على تغيير الإعدادات الإدارة للقائمة البريدية؛ يمكنك إنشاء قائمة بريدية جديدة باستخدام الأداة السطرية ‎/usr/sbin/newlist؛ أو بشكل بديل يمكنك إنشاؤها عبر واجهة الويب. المستخدمون يوفر Mailman واجهة ويب للمستخدمين، وجِّه متصفحك نحو العنوان الآتي للوصول لتلك الصفحة: http://hostname/cgi-bin/mailman/listinfo ستظهر القائمة البريدية الافتراضية mailman على الشاشة؛ وإذا ضغطت على اسم القائمة البريدية، فسيظهر نموذج للاشتراك فيها؛ يمكنك إدخال بريدك الإلكتروني واسمك (اختياري) وكلمة المرور للاشتراك؛ سيُرسَل بريد للدعوة إلى بريدك الإلكتروني، ويمكنك اتباع التعليمات في البريد للاشتراك. مصادر دليل تثبيت GNU Mainman. HOWTO – Using Exim 4 and Mailman 2.1 together. راجع أيضًا صفحة ويكي أوبنتو «Mailman».

Dovecot هو عميل تسليم البريد، مكتوبٌ مع اعتبار الحماية من الأولويات؛ ويدعم صيغتي صندوق البريد الرئيسيتين: mbox أو Maildir؛ يشرح هذا القسم كيفية ضبطه كخادوم imap أو pop3. التثبيت نفِّذ الأمر الآتي في الطرفية لتثبيت dovecot: sudo apt-get install dovecot-imapd dovecot-pop3d الضبط عدِّل الملف ‎ /etc/dovecot/dovecot.confلضبط dovecot، يمكنك اختيار البروتوكول الذي تريد استخدامه، حيث يمكن أن يكون pop3 أو pop3s (أي pop3 الآمن)، أو imap، أو imaps (أي imap الآمن)؛ شرح عن هذه البروتوكولات خارج عن نطاق هذا الدرس، للمزيد من المعلومات راجع مقالات ويكيبيديا عنهم: POP3 ،IMAP. بروتوكولَي IMAPS و POP3S أكثر أمانًا من بروتوكولَي IMAP و POP3 لأنهما يستخدمان تشفير SSL للاتصال؛ بعد أن تختار البروتوكول، فعليك تعديل السطر الآتي في الملف ‎/etc/dovecot/dovecot.conf: protocols = pop3 pop3s imap imaps ثم اختر صندوق البريد الذي تريد استخدامه، حيث يدعم Dovecot الصيغتين maildir و mbox؛ هاتان هما أشهر صيغتين مستعملتين للبريد؛ يملك كلاهما مزايا خاصةً به، ومشروحةً في موقع Dovecot. بعد أن تختار نوع صندوق البريد، عدِّل الملف ‎ /etc/dovecot/conf.d/10-mail.confوغيِّر السطر الآتي: mail_location = maildir:~/Maildir # (for maildir) أو mail_location = mbox:~/mail:INBOX=/var/spool/mail/%u # (for mbox) ملاحظة: يجب عليك ضبط عميل نقل البريد (MTA) لنقل البريد الوارد إلى هذا النوع من صندوق البريد إذا كان مختلفًا عمَّا ضبطته. بعد الانتهاء من ضبط dovecot، يجب عليك إعادة تشغيل عفريت dovecot لتجرِّب عمل الخادوم: sudo service dovecot restart إذا فعَّلت imap، أو pop3؛ فيجب عليك أيضًا تجربة تسجيل الدخول باستخدام الأوامر telnet localhost pop3 أو telnet localhost imap2؛ لترى إن شاهدت شيئًا شبيهًا بما يلي، فستعلم أن التثبيت والإعداد قد نجحا: user@localbox:~$ telnet localhost pop3 Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is '^]'. +OK Dovecot ready. ضبط Dovecot SSL لضبط Dovecot ليستخدم SSL، تستطيع أن تحرِّر الملف ‎/etc/dovecot/conf.d/10-ssl.conf وتُعدِّل الأسطر الآتية: ssl = yes ssl_cert = </etc/ssl/certs/dovecot.pem ssl_key = </etc/ssl/private/dovecot.pem يمكنك الحصول على شهادة SSL من سلطة إصدار الشهادات أو إنشاء شهادة SSL موقعة ذاتيًا؛ الخيار الأخير هو خيار جيد للبريد الإلكتروني، ﻷن عملاء SMTP نادرًا ما يشتكون حول الشهادات الموقعة ذاتيًا؛ رجاءً عُد إلى درس الشهادات لمزيدٍ من المعلومات حول إنشاء شهادة SSL موقعة ذاتيًا؛ يجب عليك الحصول على ملف مفتاح وملف الشهادة بعد إنشائك للشهادة؛ رجاءً انسخهما إلى المكان المُشار إليه في ملف الضبط ‎/etc/dovecot/conf.d‎/10-ssl.conf. ضبط الجدار الناري لخادوم البريد الإلكتروني عليك ضبط الجدار الناري للسماح للاتصالات على المنافذ الضرورية للوصول إلى خادوم البريد من حاسوبٍ آخر، وهي: IMAP‏ – 143 IMAPs‏ – 993 POP3‏ – 110 POP3s‏ – 995 مصادر راجع موقع Dovecot لمزيدٍ من المعلومات. أيضًا صفحة ويكي أوبنتو «Dovecot» فيها تفاصيلٌ إضافية. ترجمة -وبتصرف- للمقال Ubuntu Server Guide: DOvecot Server.

Exim4 هو عميل نقل رسائل آخر مطور في جامعة كامبردج لاستخدامه في أنظمة يونكس المتصلة إلى الإنترنت؛ يمكن تثبيت Exim بدلًا من sendmail، وذلك على الرغم من أن ضبط exim مختلف كثيرًا عن ضبط sendmail. التثبيتنفِّذ الأمر الآتي في الطرفية لتثبيت exim4: sudo apt-get install exim4الضبطنفِّذ الأمر الآتي لضبط Exim4: sudo dpkg-reconfigure exim4-configستظهر واجهة مستخدم تسمح لك بضبط العديد من المعاملات؛ فمثلًا تُقسَّم ملفات الضبط في Exim4 إلى عدِّة ملفات، إذا أردت أن تجعلهم في ملف واحد، فتستطيع ضبط ذلك من هذه الواجهة. جميع المعاملات التي ضبطتها في واجهة المستخدم مخزنةٌ في ملف ‎/etc/exim4/update-exim4.conf؛ وإذا أردت إعادة الضبط، فتستطيع تشغيل معالج الضبط أو تعديل هذا الملف يدويًا باستخدام محررك النصي المفضل؛ وبعد أن تنتهي من الضبط، يمكنك تنفيذ الأمر الآتي لتولد ملف ضبط رئيسي: sudo update-exim4.confيولَّد ويُخزَّن ملف الضبط الرئيسي في ‎/‎var/lib/exim4/config.autogenerated. تحذير: عليك عدم تعديل ملف الضبط الرئيسي بتاتًا؛ حيث يُحدَّث تلقائيًا في كل مرة تُنفِّذ فيها update-exim4.conf. نفِّذ الأمر الآتي لتشغيل عفريت Exim4: sudo service exim4 startاستيثاق SMTPيشرح هذا القسم كيفية ضبط Exim4 لاستخدام SMTP-AUTH مع TLS و SASL. أول خطوة هي إنشاء شهادة لاستخدامها مع TLS؛ وذلك بإدخال الأمر الآتي في الطرفية: sudo /usr/share/doc/exim4-base/examples/exim-gencertيجب أن يُضبَط Exim4 الآن لاستخدام TLS بتعديل الملف ‎/etc/exim4/conf.d/main/03_exim4-config_tlsoptions وإضافة ما يلي: MAIN_TLS_ENABLE = yesثم ستحتاج إلى ضبط Exim4 لاستخدام saslauthd للاستيثاق؛ عدِّل الملف ‎/etc/exim4/conf.d/auth ‎/30_exim4-config_examples وأزل التعليقات عن قسمَيّ plain_saslauthd_server و login_saslauthd_server: plain_saslauthd_server: driver = plaintext public_name = PLAIN server_condition = ${if saslauthd{{$auth2}{$auth3}}{1}{0}} server_set_id = $auth2 server_prompts = : .ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}} .endif # login_saslauthd_server: driver = plaintext public_name = LOGIN server_prompts = "Username:: : Password::" # don't send system passwords over unencrypted connections server_condition = ${if saslauthd{{$auth1}{$auth2}}{1}{0}} server_set_id = $auth1 .ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}} .endifلكي يتمكن عميل البريد الخارجي من الاتصال إلى خادوم exim الجديد، فمن الضروري إضافة مستخدمين جدد إلى exim بتنفيذ الأوامر الآتية: sudo /usr/share/doc/exim4/examples/exim-adduserيجب أن يحمي المستخدمون ملفات كلمة المرور الجديدة لخادوم exim بالأوامر الآتية: sudo chown root:Debian-exim /etc/exim4/passwd sudo chmod 640 /etc/exim4/passwdفي النهاية، حدِّث ضبط Exim4 وأعد تشغيل الخدمة: sudo update-exim4.conf sudo service exim4 restartضبط SASLيوفر هذا القسم معلومات حول ضبط خدمة saslauthd لتوفير الاستيثاق لخادوم Exim4. أول خطوة هي تثبيت حزمة sasl2-bin من الطرفية بإدخال الأمر الآتي: sudo apt-get install sasl2-binلضبط saslauthd، عدِّل ملف الضبط ‎/etc/default/saslauthd واضبط START=no إلى: START=yesثم يجب أن يكون المستخدم Debian-exim جزءًا من مجموعة sasl لكي يستخدم Exim4 الخدمةَ saslauthd: sudo adduser Debian-exim saslعليك الآن تشغيل خدمة saslauthd: sudo service saslauthd startضُبِط الآن Exim4 مع SMTP-AUTH ليستخدم TLS واستيثاق SASL. مصادرراجع موقع exim.org لمزيدٍ من المعلومات.يتوفر أيضًا كتاب «Exim4 Book».مصدر آخر هو صفحة ويكي أوبنتو «Exim4».ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Exim4.

تشترك العديد من الأنظمة في عملية الحصول على بريد إلكتروني من شخصٍ لآخر عبر الشبكة أو الإنترنت التي تعمل مع بعضها بعضًا؛ ويجب أن يُضبَط كل واحد من هذه الأنظمة ضبطًا صحيحًا لكي تتم العملية بنجاح؛ يستخدم المُرسِل «عميل مستخدم البريد» (Mail User Agent اختصارًا MUA) أو عميل بريد إلكتروني، لإرسال رسالة عبر واحد أو أكثر من «عملاء نقل البريد» (Mail Transfer Agents اختصارًا MTA)، سيسلم آخرهم البريد إلى «عميل إيصال البريد» (Mail Delivery Agent اختصارًا MDA) لإيصال البريد إلى صندوق بريد المستلم، الذي بدوره يحصل عليه عميل البريد الإلكتروني للمستلم عادةً باستخدام خادوم POP3 أو IMAP. Postfixإن Postfix هو عميل نقل البريد (MTA) الافتراضي في أوبنتو؛ الذي يُوصَف بأنه سريع وسهل الإدارة، وآمن ومتوافق مع عميل نقل البريد sendmail؛ يشرح هذا القسم طريقة تثبيت وضبط Postfix، ويشرح أيضًا كيفية إعداد خادوم SMTP باستخدام اتصال آمن (لإرسال رسائل البريد الإلكتروني بأمان). ملاحظة: لن نتطرّق إلى «Postfix Virtual Domains» للمزيد من المعلومات حول النطاقات الوهمية وغيرها من إعدادات الضبط المتقدمة، فراجع قسم «مصادر» في نهاية هذا القسم. التثبيتنفِّذ الأمر الآتي في الطرفية لتثبيت postfix: sudo apt-get install postfixستُسأل بعض الأسئلة أثناء عملية التثبيت، وسيُشرَح الضبط بتفاصيل أكبر في المرحلة القادمة. الضبط الأساسينفِّذ الأمر الآتي في الطرفية لضبط postfix: sudo dpkg-reconfigure postfixستظهر واجهة مستخدم، اختر منها القيم الآتية على كل شاشة: Internet Sitemail.example.comstevemail.example.com, localhost.localdomail, localhostNo‎127.0.0.1/8 8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/24‎0+allملاحظة: استبدل mail.example.com بالنطاق الذي سيقبل استلام البريد عليه، و 192.168.0.0/24 بالشبكة التي عندك ومجالها؛ و steve باسم ملائم للمستخدم. الآن هو وقتٌ ملائمٌ لتحديد صيغة صندوق البريد التي تنوي استخدامها؛ افتراضيًا Postfix يستخدم mbox لصيغة صندوق البريد؛ وبدلًا من تعديل ملف الضبط مباشرةً، يمكنك استخدام الأمر postconf لضبط كل معاملات postfix؛ ستُخزَّن معاملات الضبط في ملف ‎/etc/postfix/main.cf؛ وإذا أردت إعادة ضبط معامل معيَّن، يمكنك إما أن تنفذ الأمر أو تعدل الملف يدويًا؛ فلضبط صيغة صندوق البريد إلى Maildir: sudo postconf -e 'home_mailbox = Maildir/'ملاحظة: هذا سيضع البريد الجديد في مجلد ‎/home/username/Maildir، لذلك تريد ضبط عميل تسليم البريد (MDA) لاستخدام نفس المسار. استيثاق SMTPيسمح SMTP-AUTH للعميل بالتعريف عن نفسه باستخدام آلية استيثاق (SASL)، يجب استخدام أمن طبقة النقل (TLS) لتشفير عملية الاستيثاق؛ سيسمح خادوم SMTP للعميل بأن ينقل البريد بعد الاستيثاق. لضبط Postfix مع SMTP-AUTH باستخدام SASL‏ (Dovecot SASL): sudo postconf -e 'smtpd_sasl_type = dovecot' sudo postconf -e 'smtpd_sasl_path = private/auth-client' sudo postconf -e 'smtpd_sasl_local_domain =' sudo postconf -e 'smtpd_sasl_security_options = noanonymous' sudo postconf -e 'broken_sasl_auth_clients = yes' sudo postconf -e 'smtpd_sasl_auth_enable = yes' sudo postconf -e 'smtpd_recipient_restrictions = \ permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination'ملاحظة: الضبط smtpd_sasl_path هو مسار نسبي إلى مجلد طلبيات Postfix. ثم ولِّد أو احصل على شهادة TLS رقمية، راجع درس الشهادات للتفاصيل؛ هذا المثال يستخدم أيضًا سلطة شهادات (Certificate Authority أو CA)، للمزيد من المعلومات حول ذلك، انظر إلى قسم «سلطة الشهادات» في نفس الدرس. ملاحظة: عملاء مستخدمي البريد (MUA) التي تتصل إلى خادوم البريد عبر TLS يجب أن تتعرف على الشهادة المستخدمة في TLS؛ يمكن فعل ذلك إما باستخدام شهادة من سلطة شهادات تجارية، أو استخدام شهادة موقعة ذاتيًا، وعلى المستخدمين أن يُثبِّتوا أو يقبلوا الشهادة يدويًا، شهادات TLS من عميل نقل بريد إلى عميل نقل بريد آخر لا يُتحقَّق منها إلا بعد موافقة مسبقة من المنظمات المتأثرة؛ لا يوجد سبب لعدم استخدام شهادة موقعة ذاتيًا عند استعمال TLS من MTA إلى MTA، ما لم تتطلب السياسات المحلية ذلك؛ راجع قسم «إنشاء شهادة موقعة ذاتيا» لمزيدٍ من المعلومات في درس الشهادات. بعد أن تحصل على الشهادة، اضبط Postfix لتوفير تشفير TLS للبريد المُرسَل والمُستلَم: sudo postconf -e 'smtp_tls_security_level = may' sudo postconf -e 'smtpd_tls_security_level = may' sudo postconf -e 'smtp_tls_note_starttls_offer = yes' sudo postconf -e 'smtpd_tls_key_file = /etc/ssl/private/server.key' sudo postconf -e 'smtpd_tls_cert_file = /etc/ssl/certs/server.crt' sudo postconf -e 'smtpd_tls_loglevel = 1' sudo postconf -e 'smtpd_tls_received_header = yes' sudo postconf -e 'myhostname = mail.example.com'إذا كنت تستخدم سلطة الشهادات الخاصة بك لتوقيع الشهادة، فأدخِل: sudo postconf -e 'smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem'ملاحظة: بعد تنفيذ كل الأوامر السابقة، فيكون Postfix قد ضُبِطَ ليستخدم SMTP-AUTH وشهادة موقعة ذاتيًا أُنشِئت لاتصال TLS مشفر. # See /usr/share/postfix/main.cf.dist for a commented, more complete # version smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) biff = no # appending .domain is the MUA's job. append_dot_mydomain = no # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h myhostname = server1.example.com alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname mydestination = server1.example.com, localhost.example.com, localhost relayhost = mynetworks = 127.0.0.0/8 mailbox_command = procmail -a "$EXTENSION" mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all smtpd_sasl_local_domain = smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous broken_sasl_auth_clients = yes smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject _unauth_destination smtpd_tls_auth_only = no smtp_tls_security_level = may smtpd_tls_security_level = may smtp_tls_note_starttls_offer = yes smtpd_tls_key_file = /etc/ssl/private/smtpd.key smtpd_tls_cert_file = /etc/ssl/certs/smtpd.crt smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s tls_random_source = dev:/dev/urandomبعد إكمال الضبط الابتدائي لخدمة postfix؛ فنفذ الأمر الآتي لإعادة تشغيل العفريت: sudo service postfix restartيدعم Postfix استخدام SMTP-AUTH كما هو معرَّف في RFC2554؛ الذي هو مبني على SASL؛ لكنه يبقى ضروريًا إعداد استيثاق SASL قبل استخدام SMTP-AUTH. ضبط SASLيدعم Postfix نسختين من SASL هما Cyrus SASL و Dovecot SASL؛ لتفعيل Dovecot SASL، فيجب تثبيت حزمة dovecot-common، وذلك بإدخال الأمر الآتي من الطرفية: sudo apt-get install dovecot-commonيجب عليك تعديل ملف الضبط ‎/etc/dovecot/conf.d/10-master.conf؛ مغيِّرًا ما يلي: service auth { # auth_socket_path points to this userdb socket by default. It's typically # used by dovecot-lda, doveadm, possibly imap process, etc. Its default # permissions make it readable only by root, but you may need to relax these # permissions. Users that have access to this socket are able to get a list # of all usernames and get results of everyone's userdb lookups. unix_listener auth-userdb { #mode = 0600 #user = #group = } # Postfix smtp-auth unix_listener /var/spool/postfix/private/auth { mode = 0660 user = postfix group = postfix }ولكي نسمح لعملاء Outlook باستخدام SMTP-AUTH، فعدِّل السطر الآتي في قسم authentication mechanisms في ملف ‎/etc/dovecot/conf.d/10-auth.conf: auth_mechanisms = plainإلى ما يلي: auth_mechanisms = plain loginبعد أن ضَبَطَتَ Dovecot، فأعد تشغيله بالأمر: sudo service dovecot restartMail-Stack Deliveryخيار آخر لضبط Postfix لاستعمال SMTP-AUTH هو استخدام الحزمة mail-stack-delivery (كانت تُحزَّم مسبقًا باسم dovecot-postfix)؛ هذه الحزمة ستُثبِّت Dovecot وتضبط Postfix ليستخدمها لاستيثاق SASL وعميل تسليم البريد (MDA)؛ تضبط هذه الحزمة Dovecot أيضًا للخدمات IMAP و IMAPS و POP3 و POP3S. ملاحظة: ربما تريد أو لا تريد تشغيل IMAP، أو IMAPS، أو POP3، أو POP3S على خادوم البريد عندك؛ على سبيل المثال، إذا كنت تضبط خادومك ليكون بوابةً للبريد، أو مُرَشِّحًا للرسائل العشوائية (Spam) أو الفيروسات ...إلخ. فإذا كانت هذه هي الحالة عندك، فمن الأسهل استخدام الأوامر السابقة لضبط Postfix لاستخدام SMTP-AUTH. لتثبيت الحزمة، أدخِل ما يلي في الطرفية: sudo apt-get install mail-stack-deliveryيجب أن تحصل الآن على خادوم بريد يعمل تمامًا؛ لكن هنالك بعض الخيارات التي تريد ضبطها لمزيدٍ من التخصيص؛ على سبيل المثال، تستخدم الحزمة السابقة شهادة ومفتاح من حزمة ssl-cert، وفي بيئة إنتاجية يجب أن تستخدم شهادة ومفتاح مولَّد للمضيف. عدِّل الخيارات الآتية في ملف ‎/‎etc/postfix/main.cf بعد أن تخصص الشهادة والمفتاح للمضيف: smtpd_tls_cert_file = /etc/ssl/certs/ssl-mail.pem smtpd_tls_key_file = /etc/ssl/private/ssl-mail.keyثم أعد تشغيل Postfix: sudo service postfix restartالاختباراكتمل الآن ضبط SMTP-AUTH؛ حان الآن الوقت لاختبار الإعدادات. للتأكد إذا كان SMTP-AUTH و TLS يعملان عملًا صحيحًا، فنفِّذ الأمر الآتي: telnet mail.example.com 25بعد أن تُنشِئ اتصالًا لخادوم البريد postfix، اكتب ما يلي: ehlo mail.example.comإذا رأيت الأسطر الآتية بين غيرها، فإن كل شيء يعمل على ما يرام؛ اكتب quit للخروج. 250-STARTTLS 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250 8BITMIMEاستكشاف الأخطاء وإصلاحهاسنقدم في هذا القسم بعض الطرق الشائعة لتحديد السبب إذا حدثت مشكلة ما. الخروج من chrootستُثبَّت الحزمة postfix في أوبنتو افتراضيًا في بيئة «chroot» لأسبابٍ أمنية؛ يمكن أن يزيد هذا من تعقيد إصلاح المشاكل. لتعطيل عمل chroot، حدد السطر الآتي في ملف ‎/etc/postfix/master.cf: smtp inet n - - - - smtpdوعدِّله كما يلي: smtp inet n - n - - smtpdتحتاج إلى إعادة تشغيل Postfix لاستخدام الضبط الجديد، وذلك بإدخال الأمر الآتي في الطرفية: sudo service postfix restartSmtpsإذا احتجت إلى smtps، فعدِّل الملف ‎/etc/postfix/master.cf وأزل التعليق عن السطر الآتي: smtps inet n - - - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATINGملفات السجليُرسِل Postfix جميع رسائل السجل إلى ملف ‎/var/log/mail.log، لكن يمكن أن تضيع رسائل الخطأ والتحذير في السجل العادي، لذلك فإنها تُسجَّل أيضًا إلى ‎/var/log/mail.err و ‎/var/log/mail.warn على التوالي وبالترتيب. لمراقبة الرسائل الداخلة إلى السجل في الوقت الحقيقي، فاستخدم الأمر tail مع الخيار ‎-f كما يلي: tail -f /var/log/mail.errيمكن زيادة كمية التفاصيل التي ستُسجَّل؛ هذه بعض خيارات الضبط لزيادة مستوى التسجيل لبعض «المناطق» المذكورة أعلاه. لزيادة نشاط تسجيل TLS، فاضبط الخيار smtpd_tls_loglevel إلى قيمة من 1 إلى 4: sudo postconf -e 'smtpd_tls_loglevel = 4'إذا كانت لديك مشكلة في إرسال أو استقبل البريد من نطاق معين، فيمكنك إضافة ذاك النطاق إلى معامل debug_peer_list: sudo postconf -e 'debug_peer_list = problem.domain'يمكنك زيادة درجة الإسهاب لأي عملية تابعة لعفريت Postfix بتعديل الملف ‎/etc/postfix/master.cf وبإضافة الخيار ‎-v بعد القيد، على سبيل المثال، عدِّل القيد smtp كما يلي: smtp unix - - - - - smtp -vملاحظة: من الضروري ملاحظة أنه بعد إنشاء تعديل من تعديلات التسجيل المذكورة آنفًا، فيجب أن يعاد تحميل عملية Postfix لكي تُدرِك الضبط الجديد: sudo service postfix reloadلزيادة مقدار المعلومات المسجلة عند استكشاف مشاكل SASL، يمكنك ضبط الخيارات الآتية في ملف ‎/etc/dovecot/conf.d/10-logging.conf: auth_debug=yes auth_debug_passwords=yesملاحظة: مثل Postfix، إذا عدَّلت ضبط Dovecot فيجب إعادة تحميل العملية: sudo service dovecot reloadملاحظة: يمكن أن تزيد بعض الخيارات من مقدار المعلومات المُرسَلة إلى السجل زيادةً كبيرةً؛ تذكر أن تُعيد مستوى التسجيل إلى الحالة الطبيعية بعد أن تحلّ المشكلة؛ ثم أعد تحميل العفريت الملائم كي يأخذ الضبط الجديد مفعوله. مصادريمكن أن تكون مهمة إدارة خادوم Postfix مهمةً معقدةً جدًا؛ وستحتاج في مرحلةٍ ما إلى الاستعانة بمجتمع أوبنتو للحصول على المساعدة. مكان رائع للسؤال عن مساعدة في Postfix والاشتراك في مجتمع أوبنتو هو قناة ‎#ubuntu-server على خادوم freenode؛ يمكنك أيضًا نشر موضوع في أحد المنتديات.لمعلومات معمقّة عن Postfix، فينصح مطورو أوبنتو بكتاب «The Book of Postfix».موقع Postfix فيه توثيق رائع لمختلف خيارات الضبط المتوفرة.راجع أيضًا صفحة ويكي أوبنتو «Postfix» للمزيد من المعلومات.ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Postfix. حقوق الصورة البارزة: Designed by Freepik.

إن CVS هو خادوم تحكم بالإصدارات؛ تستطيع استخدامه لتسجيل تاريخ ملفات المصدر. التثبيتنفِّذ الأمر الآتي في الطرفية لتثبيت CVS: sudo apt-get install cvsبعد تثبيت cvs، يجب عليك تثبيت xinetd لتشغيل أو إيقاف خادوم cvs؛ وذلك بإدخال الأمر الآتي في الطرفية: sudo apt-get install xinetdالضبطبعد أن تثبت cvs، فإنه سيُهيّء مستودعًا تلقائيًا؛ يقبع المستودع افتراضيًّا في مجلد ‎/srv/cvs؛ ويمكنك تغيير هذا المسار بتنفيذ الأمر الآتي: cvs -d /your/new/cvs/repo initتستطيع ضبط xinetd لبدء خادوم CVS بعد أن يُضبَط المستودع الابتدائي؛ يمكنك نسخ الأسطر الآتية إلى ملف ‎/etc/xinetd.d/cvspserver: service cvspserver { port = 2401 socket_type = stream protocol = tcp user = root wait = no type = UNLISTED server = /usr/bin/cvs server_args = -f --allow-root /srv/cvs pserver disable = no }ملاحظة: تأكد أن تعدِّل المستودع إذا غيرت مجلد المستودع الافتراضي (‎/srv/cvs). بعد أن تضبط xinetd؛ يمكنك بدء خادوم CVS بإدخال الأمر الآتي: sudo service xinetd restartيمكنك التأكد من عمل خادوم CVS بإدخال الأمر الآتي: sudo netstat -tap | grep cvsيجب أن ترى مخرجاتٍ شبيهةً بالمخرجات الآتية بعد تنفيذ الأمر السابق: tcp 0 0 *:cvspserver *:* LISTENمن هنا يمكنك المتابعة في إضافة المستخدمين والمشاريع الجديدة وإدارة خادوم CVS. تحذير: يسمح CVS للمستخدم بإضافة مستخدمين بشكل مستقل عن نظام التشغيل؛ وربما أسهل طريقة هي استخدام مستخدمي لينُكس لخادوم CVS، على الرغم من أن لها مساوئ أمنية؛ راجع دليل CVS للتفاصيل. إضافة مشاريعيشرح هذا القسم كيفية إضافة مشاريع جديدة إلى مستودع CVS؛ أنشِئ مجلدًا وأضف المستندات والملفات المصدرية إليه؛ ثم نفِّذ الأمر الآتي لإضافة هذا المشروع إلى مستودع CVS: cd your/project cvs -d :pserver:username@hostname.com:/srv/cvs import -m "Importing my project to CVS repository" . new_project startتنويه: يمكن استخدام متغير البيئة CVSROOT لتخزين المجلد الجذر لخادوم CVS؛ يمكنك تجنب استخدام الخيار ‎-d في أمر cvs السابق بعد أن «تُصدِّر» (export) متغير البيئة CVSROOT. السلسلة النصية new_project هي وسم «vendor»، و start هي وسم «release»، لا يخدمان أي هدف في هذا السياق، لكن ولما كان خادوم CVS يتطلب وجودهما؛ فيجب أن تضعهما. تحذير: عندما تضيف مشروعًا جديدًا، فيجب أن يملك مستخدم CVS إذن الوصول إلى مستودع (CVS (/srv/cvs‎؛ تملك المجموعة src افتراضيًا إذن الكتابة إلى مستودع CVS؛ لذلك تستطيع إضافة المستخدم إلى هذه المجموعة، ثم سيستطيع إضافة وإدارة المشاريع في مستودع CVS.