المحتوى عن 'أوبنتو'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • نصائح وإرشادات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • مقالات عامة
  • التجارة الإلكترونية

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
  • HTML5
  • CSS
    • Sass
    • إطار عمل Bootstrap
  • SQL
  • سي شارب #C
    • منصة Xamarin
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة R
  • سير العمل
    • Git
  • صناعة الألعاب
    • Unity3D
  • مقالات عامّة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • مقالات عامّة

التصنيفات

  • خواديم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • استسراع النمو
  • المبيعات

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 101 نتائج

  1. PostgreSQL، هو نظام متطور مفتوح المصدر، كائنيّ الارتباط-Object Relational ﻹدارة قواعد البيانات، وهو نظام قابل للتوسع، بمعنى أنه يستطيع معالجة اﻷحمال المختلفة بدءًا من تطبيقات جهاز واحد إلى خدمات الويب التجارية التي تتعامل مع مستخدمين كثر في نفس الوقت. وهذا النظام Transactional أي يعامل النقل المتسلسل للبيانات -مثل تحديث قاعدة البيانات- كوحدة واحدة لضمان سلامتها، ويحقق خصائص ACID (Atomicity – Consistency – Isolation – Durability). وكذلك يدعم قسمًا كبيرًا من معايير SQL. فائدة: خصائص ACID هي أربعة خصائص يجب توافرها في تعاملات قواعد البيانات، وهي الذرية-Atomicity -أن تُنفَّذ العملية كوحدة واحدة-، والتناسق-Consistency، والعزل-Isolation، والثبات-Durability. ويوفر PostgreSQL العديد من المزايا مثل: الاستعلامات المعقدة-Complex Queries المفاتيح الأجنبية-Foreign Keys المشاهدات القابلة للتحديث-Updatable Views سلامة عمليات نقل البيانات-Transactional Integrity التحكم في التزامن متعدد الإصدارات-Multiversion Concurrency Control وذكرنا قبل قليل أنه قابل للتمدد والتوسع بواسطة مستخدميه عبر إضافة دوال-Functions جديدة، ومشغّلات-operators، وأنواع بيانات، وطرق فهرسة، ولغات إجرائية-Procedural Languages. ويقدّم PostgreSQL طرقًا عديدة لتكرار قاعدة بيانات، وسنتعلم في هذا الدليل كيفية إعداد تكرار من نوع (الرئيسي-Master/الثانوي-Slave)، وهي عملية مزامنة بين قاعدتي بيانات من خلال النسخ من قاعدة بيانات على خادم (الرئيسي) إلى قاعدة بيانات أخرى في خادم آخر (الثانوي)، وسننفذ هذه العملية على خادم يعمل بتوزيعة أوبنتو 16.04. المتطلبات أن يكون PostgreSQL 9.6 مثبتًا على خادم أوبنتو 16.04 إعداد UFW ثبّت جدار الحماية الناري غير المعقّد-Uncomplicated Firewall على خوادم أوبنتو، وهو أداة ﻹدارة جدار الحماية المعتمِد على iptables. استخدم الأمر التالي في الطرفية: # apt-get install -y ufw واﻵن، أضف PostgreSQL وخدمة SSH إلى جدار الحماية، عبر تنفيذ اﻷمر التالي: # ufw allow ssh # ufw allow postgresql فعّل جدار الحماية: # ufw enable إعداد خادم PostgreSQL الرئيسي سيمتلك الخادم الرئيسي صلاحيات القراءة والكتابة لقاعدة البيانات، وسيكون هو القادر على نقل البيانات إلى الخادم الثانوي. • افتح محررًا نصيًا وعدّل إعدادات PostgreSQL الرئيسية كما يلي: (ملاحظة: استبدل EDITOR$ بالمحرر النصي الذي تفضّله) # $EDITOR /etc/postgresql/9.6/main/postgresql.conf أزل التعليق (#) من سطر listen_addresses وأضف عنوان IP للخادم الرئيسي: listen_addresses = 'master_server_IP_address' واﻵن، أزل التعليق من سطر wal_level لتغيير قيمته: wal_level = hot_standby وأزل التعليق من السطر التالي كي تستخدم المزامنة المحلية-Local Syncing لمستوى المزامنة "Synchronization Level" synchronous_commit = local ثم أزل التعليق من السطرين التاليين، وعدلهما كما يلي، بما أننا نستخدم خادمين: max_wal_senders = 2 wal_keep_segments = 10 واﻵن احفظ الملف وأغلقه. عدّل ملف pg_hba.conf من أجل إعدادات التوثيق-Authentication، كما يلي: افتح الملف عبر هذا الأمر: # $EDITOR /etc/postgresql/9.6/main/pg_hba.conf الصق الإعدادات التالية: # Localhost host replication replica 127.0.0.1/32 md5 # PostgreSQL Master IP address host replication replica master_IP_address/32 md5 # PostgreSQL SLave IP address host replication replica slave_IP_address/32 md5 احفظ الملف وأغلقه، ثم أعد تشغيل PostgreSQL باستخدام systemctl # systemctl restart postgresql إنشاء مستخدم من أجل التكرار سننشئ مستخدم PostgreSQL من أجل عملية التكرار، فسجّل الدخول أولًا إلى حساب المستخدم المسمّىpostgres وافتح صدفة PostgreSQL، من خلال الأوامر التالية: # su - postgres $ psql أنشئ مستخدمًا جديدًا: postgres=# CREATE USER replica REPLICATION LOGIN ENCRYPTED PASSWORD 'usr_strong_pwd'; أغلق الصَّدَفة، وهكذا تنتهي إعدادات الخادم الرئيسي. إعداد الخادم الثانوي لن تكون للخادم الثانوي صلاحيات الكتابة في قاعدة البيانات، وستكون وظيفته الوحيدة هي استقبال البيانات من الخادم الرئيسي، أي ستكون له صلاحية القراءة فقط. • سنوقف أولًا خدمة PostgreSQL: # systemctl stop postgresql افتح ملف الإعدادات الرئيسية لـ PostgreSQL: # $EDITOR /etc/postgresql/9.6/main/postgresql.conf أزل التعليق من سطر listen_addresses وغيّر قيمته: listen_addresses = 'slave_IP_address' أزل التعليق من سطر wal_level وغيّره كما يلي: wal_level = hot_standby وأزل التعليق أيضًا من سطر synchronous_commit كما في الخادم الرئيسي للاستفادة من المزامنة المحلية-local syncing: synchronous_commit = local ثم أزل التعليق من السطرين التاليين وغيّر قيمهما كما يلي: max_wal_senders = 2 wal_keep_segments = 10 أزل التعليق من السطر التالي وغيّر قيمته كما يلي من أجل تفعيل hot_standby للخادم الثانوي: hot_standby = on احفظ الملف وأغلقه. نسخ البيانات من الخادم الرئيسي إلى الثانوي لكي نزامن بيانات الخادم الرئيسي مع الثانوي، فيجب أن يحل المجلد الأساسي “main” في الخادم الرئيسي محل المجلد الرئيسي في الخادم الثانوي، ونفعل هذا كما يلي: • سجل الدخول إلى مستخدم postgres: # su – postgres خذ نسخة احتياطية من مجلد البيانات الفعلي: $ cd/var/lib/postgresql/9.6/ $ mv main main_bak أنشئ مجلد أساسيًا جديدًا: $ mkdir main/ غيّر صلاحياته: $ chmod 700 main وهنا، انسخ المجلد الأساسي من الخادم الرئيسي إلى الخادم الثانوي باستخدام pg_basebackup: # pg_basebackup -h master_IP_address -U replica -D /var/lib/postgresql/9.6/main /-P –xlog وحين ينتهي النسخ، أنشئ ملف recovery.conf داخل المجلد الأساسي "main” وانسخ المحتوى التالي فيه: standby_mode = 'on' primary_conninfo = 'host=10.0.15.10 port=5432 user=replica password=usr_strong_pwd' trigger_file = '/tmp/postgresql.trigger.5432' واﻵن، احفظ الملف وأغلقه، ثم غير صلاحياته كما يلي: # chmod 600 recovery.conf شغّل خدمة PostgreSQL: # systemctl start postgresql وهنا تنتهي إعدادات الخادم الثانوي. الخلاصة لقد رأينا في هذا الدليل المبسّط كيفية ضبط تكرار Master/Slave في PostgreSQL عبر استخدام خادمين يعملان بأوبنتو. وهذه الطريقة في التكرار ما هي إﻻ إحدى طرق عديدة يوفرها نظام PostgreSQL لإدارة قواعد البيانات. ترجمة -بتصرف- لمقال PostgreSQL Replication on Ubuntu Tutorial لصاحبه Giuseppe Molica
  2. نحن نبني أغلب أعمالنا على خوادم مبنية على Apache أو NGNIX، وربما حان الوقت لتجربة خادم ويب جديد بدأ يحصد شعبية بسبب بساطته، وهو خادم Caddy. وقد أُطلق هذا الخادم لأول مرة في 2015 مكتوبًابالكامل بلغة Go، وتعتمد تهيئته على caddyfile، وهي ملفات يسهل كتابتها وإدارتها كما سنرى في هذا المثال، وما حمّسنا له حقيقة هو أنه يتكامل مع Let’s Encrypt بشكل افتراضي ودون أي تهيئة يدوية. مزايا Caddy Automatic HTTPS مفعّلة افتراضيًا من خلال Let’s Encrypt. HTTP/2 افتراضيًا. Static Files في مجلد العمل الحالي. كل أنواع الخوادم، والموجّهات-directives، ومزودو DNS، ومزايا أخرى، كل ذلك موجود في صورة إضافات. يمكن استخدامه كمكتبة في برامج أخرى بلغة Go. يمكن تهيئته ليشغّل أوامر خاصة بالنظام عند بدء التشغيل أو إيقافه. ملف تنفيذي واحد لا يحتاج إلى اعتماديات إلا فيما يتعلق بالنواة-kernel. كل هؤلاء إضافة إلى مزايا أخرى عديدة، أما الآن فسنلقي نظرة على كيفية تثبيته واستخدامه على خادم أوبنتو 16.04. تثبيت خادم ويب Caddy يوفّر Caddy شفرة نصية-script للتثبيت، تحمّل وتثبت الملف التنفيذي له -فهو لا يحتاج إلى اعتماديات كما ذكرنا-، نفذ الأمر التالي لتنفيذ الشفرة: $ curl https://getcaddy.com | bash وستسألك الشفرة أثناء التثبيت عن كلمة المرور من أجل الحصول على صلاحيات إدارية، فيكون الخرج هكذا: % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 5593 100 5593 0 0 3696 0 0:00:01 0:00:01 --:--:-- 3696 Downloading Caddy for linux/amd64... https://caddyserver.com/download/linux/amd64?plugins= Download verification OK Extracting... Putting caddy in /usr/local/bin (may require password) [sudo] password for gmolica: Caddy 0.10.6 Successfully installed ستتغير gmolica إلى اسم المستخدم الخاص بك طبعًا، وسيكون Caddy مثبتًا وجاهزًا بمجرد انتهاء الشفرة من عملها. جدير بالذكر أن عملية التثبيت لن تطبق إعدادات أو تهيئة على مستوى النظام-system wide، لذا سيكون عليك تنفيذ هذا الجزء، كما سنرى فيما يلي. تهيئة Caddy سيعتبر Caddy أن المجلد الجذر للموقع هو المجلد الذي نفّذته منه، فإن نفّذت Caddy من مجلد $HOME فسيستخدمه كمجلد جذر له، وهذا يعني بعبارة أخرى أن من السهل استخدام Caddy في العمل على المواقع محلّيًا. - لبدء Caddy: $ caddy ستظهر الطرفية الرسالة التالية: Activating privacy features... done. http://:2015 WARNING: File descriptor limit 1024 is too low for production servers. At least 8192 is recommended. Fix with "ulimit -n 8192". لاحظ أن Caddy يعمل على مضيف محلي-localhost، في منفذ 2015. قد يؤدي فتح صفحة http://your_server_IP:2015 -استبدل عنوان خادمك بـyour server IP-إلى صفحة خطأ 404، هذا بسبب أن المجلد الذي يستخدمه Caddy لا يحتوي على موقع، فيجب أن ننشئ تلك المجلدات المطلوبة أولًا: إنشاء المجلدات المطلوبة أولًا، ننشئ مجلدًا يحتوي ملف caddyfile الأساسي: # mkdir /etc/caddy نغير ملكيته إلى المستخدم الجذر ومجموعته إلى www-data: # chown -R root:www-data /etc/caddy أنشئ مجلدًا ثانيًا ليخزن فيه Caddy شهادات SSL والمفاتيح الخاصة: # mkdir /etc/ssl/caddy غير مالكه إلى www-data: # chown -R www-data /etc/ssl/caddy غيّر صلاحياته كما يلي: # chmod 0770 /etc/ssl/caddy والآن أنشئ المجلد الذي سيحتوي الموقع: # mkdir /var/www وغيّر مالكه إلى www-data: # chown www-data:www-data /var/www تحميل ملف Caddy Unit لن يثبّت Caddy نفسه افتراضيًا كخدمة systemd، لكنه يوفّر رسميًا ملف unit، حمّله بالأمر التالي: # curl -s https://raw.githubusercontent.com/mholt/caddy/master/dist/init/linux-systemd/caddy.service -o /etc/systemd/system/caddy.service بفتح الملف، سنلاحظ هذه السطور: ; Letsencrypt-issued certificates will be written to this directory. Environment=CADDYPATH=/etc/ssl/caddy ; Always set "-root" to something safe in case it gets forgotten in the Caddyfile. ExecStart=/usr/local/bin/caddy -log stdout -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp لاحظ مسارات المجلدات في تلك السطور، لهذا قد أنشأنا المجلدات قبل قليل. والآن أنشئ ملفًا فارغًا باسم caddyfile: # sudo touch /etc/caddy/Caddyfile نفّذ الأمر التالي كي يعمل Caddy عند الإقلاع: # systemctl daemon-reload # systemctl enable caddy تفقد حالته بهذا الأمر: # systemctl status caddy يجب أن يكون الخرج هكذا: ---------------------------------- â caddy.service - Caddy HTTP/2 web server Loaded: loaded (/etc/systemd/system/caddy.service; enabled; vendor preset: en Active: inactive (dead) Docs: https://caddyserver.com/docs السماح باتصالات HTTP وHTTPS سنسمح لاتصالات HTTP وHTTPS عبر UFW (Uncomplicated Firewall)، كي يتمكن Caddy من خدمة المستخدمين بشكل سليم، نفّذ هذه الأوامر في الطرفية للسماح بهذه الاتصالات: # ufw allow http # ufw allow https اختبار Caddy آخر خطوة هي اختبار Caddy للتأكد أن كل شيء تم بشكل سليم: تعديل Caddyfile لقد أنشأنا ملف caddyfile فارغ من قبل، الآن سنبدأ الكتابة فيه: - افتح الملف باستخدام المحرر النصي الذي تفضّله: # $EDITOR /etc/caddy/Caddyfile الصق هذا المحتوى في الملف: example.com { root /var/www gzip tls gmolica@example.com } ملاحظة: سطر tls يحتوي على عنوان بريد يستخدمه Caddy ليحصل على شهادات SSL من Let’s Encrypt. - احفظ الملف وأغلقه. - شغّل Caddy: # systemctl start caddy أنشئ صفحة ويب سننشئ صفحة ويب لاختبار Caddy: $ echo '<h1>Website using Caddy</h1>' | sudo tee /var/www/index.html استخدم نفس الجذر الذي ثبتنا فيه ملف caddyfile. خاتمة لقد رأينا الآن كيفية تثبيت واستخدام Caddy، ولاحظنا كيفية سهولة التثبيت وإنشاء ملف caddyfile لتخصيص سلوك الخادم. لاحظ أن سهولة الاستخدام يتبيّن فضلها في بيئات التشغيل المعقدة. ترجمة -بتصرف- لمقال Caddy Web Server On Ubuntu 16.04 لصاحبه Giuseppe Molica
  3. تزداد شعبية Go، وهي لغة برمجة حديثة تطوّرها شركة Google، تزداد كثيرا في التطبيقات والشركات؛ كما توفّر مجموعة متناسقة من المكتبات البرمجية. يشرح هذا الدرس خطوات تثبيت الإصدار 1.8 (الإصدار المستقر الأحدث حتى الآن) على توزيعة لينكس أوبونتو 16.04. سننفّذ في الخطوة الأخيرة من هذا الدرس تطبيق “أهلا بالعالم” صغيرا للتأكد من تثبيت مصرّف اللغة Compiler وعمله. المتطلّبات يفترض هذا الدرس توفّر نظام أوبونتو 16.04 معدًّا للعمل مع مستخدم إداري غير المستخدم الجذر بالطريقة التي يشرحها الإعداد الابتدائي لخادوم أوبونتو. الخطوة الأولى: تثبيت Go نبدأ بتثبيت Go على الخادوم. اتّصل - إن دعت الحاجة لذلك - بالخادوم عن طريق SSH: ssh sammy@your_server_ip اذهب إلى صفحة التنزيلات على الموقع الرسمي لـGo واعثُر على رابط الملف المضغوط لآخر إصدار مستقر، مع قيمة تجزئة SHA256 الخاصة به. تأكد من أنك في المجلّد الشخصي للمستخدم ثم نزّل الإصدار انطلاقا من الرابط الذي تحصّلت عليه في الفقرة الماضية: cd ~ curl -O https://storage.googleapis.com/golang/go1.8.3.linux-amd64.tar.gz استخدم الأمر sha256sum للتحقّق من الملف المضغوط: sha256sum go1.8.3.linux-amd64.tar.gz مثال على المُخرجات: 1862f4c3d3907e59b04a757cfda0ea7aa9ef39274af99a784f5be843c80c6772 go1.8.3.linux-amd64.tar.gz ستحصُل على قيمة تجزئة Hash مثل تلك الموجودة في المُخرجات السابقة. تأكد من أنها توافق قيمة التجزئة الخاصة بالملف التي تحصّلت عليها من صفحة التنزيلات. سنستخدم الآن الأمر tar لفك ضغط الملف. يطلُب الخيار x استخراج محتوى الملف المضغوط، يُظهر الخيار v مخرجات مفصَّلة ويحدّد الخيار f أننا سنمرّر للأمر tar اسم الملف المضغوط: tar xvf go1.6.linux-amd64.tar.gz ستحصُل الآن على مجلّد باسم go في المجلّد الشخصي للمستخدم. نفّذ الأمرين التاليين لتعديل ملكية المجلّد go ثم نقله إلى المسار usr/local/ : sudo chown -R root:root ./go sudo mv go /usr/local ملحوظة: المسار usr/local/go/ هو المسار المنصوح به رسميا لتثبيت Go إلا أن بعض الحالات قد تتطلّب تثبيته على مسار مختلف. الخطوة الثانية: ضبط مسارات Go سنضبُط في هذه الخطوة المسارات الخاصّة بـGo في بيئة النظام. نفتح الملف profile./~ لتحريره: sudo nano ~/.profile نضيف السطرين التاليّين في نهاية الملف لضبط قيمة المتغيّر GOPATH، الذي يحدّد المسار الذي يجب على المصرّف البحثُ فيه عن الملفات المكتوبة بـGo، ولإضافة هذا المسار إلى متغيّر النظام PATH: export GOPATH=$HOME/work export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin أضف الأسطر أدناه إلى الملف بدلا من الأسطر السابقة إن اخترت مسارا غير الذي اخترناه لتثبيت Go. يفترض المثال أن Go مثبَّت في المجلّد الشخصي للمستخدم: export GOROOT=$HOME/go export GOPATH=$HOME/work export PATH=$PATH:$GOROOT/bin:$GOPATH/bin نغلق الملف بعد التحرير ونعتمد التغيير بتنفيذ الأمر source: source ~/.profile الخطوة الثالثة: اختبار التثبيت نتأكّد بعد أن ثبّتنا Go وضبطنا مساراته من عمله. أنشئ مجلّدا جديدا لحفظ ملفات Go. مسار هذا الملف هو نفس المسار الذي حدّدناه في المتغيّر GOPATHضمن الخطوة السابقة: mkdir $HOME/work أنشئ مجلّدات مشاريع Go ضمن هذا المجلد كما في المثال التالي. يمكنك إبدال user في المسار أدناه باسم المستخدم الخاصّ بك على GitHub إن كنت تخطّط لاستخدام Git لإيداع شفرتك البرمجية على GitHub. إن لم تكن تخطّط لذلك فيمكن اختيار تسميات أخرى مثل my_project. mkdir -p work/src/github.com/user/hello ننشئ ملفّ Go بسيطا للتجربة، ونسميه hello: nano ~/work/src/github.com/user/hello/hello.go ألصق شفرة Go التالية ضمن محرّر النصوص. تستخدم هذه الشفرة حزمة main في Go، تستورد مكتبة fmt لدوالّ الإدخال والإخراج وتضبُط دالة جديدة لطباعة الجملة hello, world. package main import "fmt" func main() { fmt.Printf("hello, world\n") } يطبع البرنامج السابق عند تنفيذه بنجاح العبارة hello, world، وهو ما يدلّ على نجاح تصريف Compiling شفرة Go. احفظ الملف ثم أغلقه؛ ثم صرّفه باستدعاء الأمر go install: go install github.com/user/hello يمكننا الآن تشغيل البرنامج بتنفيذ الأمر hello: hello إن تمّ كل شيء على ما يُرام فستُطبَع العبارة hello, world. يمكنك معرفة أين يوجد الملف التنفيذي للبرنامج (ناتج التصريف) بتمرير اسمه إلى الأمر which: which hello مثال على المُخرجات: /home/user/work/bin/hello خاتمة يصبح لديك بعد تنزيل حزمة Go وتثبيتها وضبط مساراتها نظام جاهز لاستخدامه في التطوير بلغة Go. يمكنك الآن البدء بتعلم كتابة البرامج بهذه اللغة، راجع قسم البرمجة بلغة Go للمزيد. ترجمة - بتصرّف - للمقال How to Install Go 1.6 on Ubuntu 16.04 لصاحبه Brennen Bearnes.
  4. بروتوكول نقل الملفات FTP (اختصار للعبارة File Transfer Protocol) هو بروتوكول شبكي كان شائعًا جدًا فيما قد سلف لنقل الملفات بين الخادوم والعميل، لكن استبدلته الطرائق الأكثر أمانًا وسرعةً لنقل الملفات، فكثيرٌ من مستخدمي الإنترنت يتوقعون تنزيل الملفات مباشرةً من متصفح الويب عبر بروتوكول http (أو https)، أما مستخدمي سطر الأوامر فيستعملون بروتوكولات أكثر أمانًا مثل scp أو sFTP. لكن ما يزال بروتوكول FTP مستخدمًا في التطبيقات القديمة أو للحالات التي لها متطلبات خاصة، فلو كنتَ تستطيع اختيار ما هو البروتوكول الذي ستستخدمه، فأنصحك بالنظر في بقية الخيارات الحديثة؛ لكن إذا كنت تحتاج إلى استخدام FTP فخادوم vsftpd هو خيارٌ ممتازٌ إذ إنَّ أداءه ممتاز وآمن ومستقر، ويوفِّر قدرًا كبيرًا من الحماية ضد كثيرٍ من المشاكل الأمنية الموجودة في خودايم FTP الأخرى، إضافةً إلى أنه الخادوم الافتراضي لخدمة FTP للعديد من توزيعات لينكس. سنتعلم في هذا الدرس كيفية ضبط خادوم vsftpd للسماح للمستخدمين برفع ملفاتهم إلى مجلد المنزل الخاص بهم باستخدام بروتوكول FTP مع تأمين معلومات الدخول عبر تشفير SSL/TLS. المتطلبات المسبقة خادوم أوبنتو 16.04 مع وصول إلى مستخدم يملك امتيازات الجذر عبر الأمر sudo: إذ سنُطبِّق الأوامر المذكورة في هذا الدرس عبر مستخدمٍ ليس جذرًا لكنه يمتلك امتيازات الجذر عبر الأمر sudo. يمكنك إنشاء مستخدم له امتيازات الجذر باستخدام الأمر sudo باتباع درس «الإعداد الابتدائي لخادوم أوبنتو 14.04](https://academy.hsoub.com/devops/servers/الإعداد-الابتدائي-لخادوم-أوبنتو-1404-r4/)». يمكننا أن نبدأ بتطبيق هذا الدرس بعد أن يكون الخادوم جاهزًا. الخطوة الأولى: تثبيت vsftpd سنبدأ بتحديث فهرس الحزم في خادومنا ثم تثبيت خادوم vsftpd: sudo apt-get update sudo apt-get install vsftpd عند إكمال التثبيت، فسننسخ ملف الضبط الافتراضي لنأخذ نسخةً احتياطيةً منه، ولنعدِّل الضبط كما نشاء. sudo cp /etc/vsftpd.conf{,.orig} بعد أن أخذنا نسخةً احتياطيةً من ملف الضبط، فحان الوقت الآن لإعداد الجدار الناري. الخطوة الثانية: فتح المنافذ الضرورية في الجدار الناري سنتحقق أولًا من حالة الجدار الناري لنرى إن كان مفعلًا أم لا، فإذا كان مفعلًا فعلينا السماح باتصالات FTP عبره لكي لا نواجه مشاكل عندما نجرِّب الخادوم. sudo ufw status نجد من الناتج الآتي أنَّ خدمة SSH مسموحٌ لها فقط: Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) لاحظ أنَّ الناتج قد يكون مختلفًا عندك، فقد لا توجد أيّة قواعد لجدارك الناري أو لديك قواعد إضافية. ولمّا كان الجدار الناري لا يسمح إلا لاتصالات SSH فعلينا إضافة قواعد للسماح لاتصالات FTP، وسنحتاج إلى فتح المنفذين 20 و 21 لخدمة FTP، والمنفذ 990 لنستعمله لاحقًا عندما نضبط تشفير TLS، والمنافذ من 40000 إلى 50000 كمنافذ غير المباشرة (passive ports) التي نخطط لضبطها لاحقًا في ملف الضبط: sudo ufw allow 20/tcp sudo ufw allow 21/tcp sudo ufw allow 990/tcp sudo ufw allow 40000:50000/tcp sudo ufw status يجب أن تبدو قواعد الجدار الناري كما يلي: Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere 990/tcp ALLOW Anywhere 20/tcp ALLOW Anywhere 21/tcp ALLOW Anywhere 40000:50000/tcp ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) 20/tcp (v6) ALLOW Anywhere (v6) 21/tcp (v6) ALLOW Anywhere (v6) 990/tcp (v6) ALLOW Anywhere (v6) 40000:50000/tcp (v6) ALLOW Anywhere (v6) يمكننا الانتقال إلى الخطوة التالية بعد تثبيتنا لخادوم vsftpd وفتح المنافذ الضرورية. الخطوة الثالثة: تهيئة مجلد المنزل للمستخدم سنُنشِئ في هذا الدرس مستخدمًا جديدًا، لكن قد يكون لديك مستخدم موجود في نظامك ويحتاج إلى وصول FTP، وسنحرص على الحفاظ على وصول المستخدم إلى بياناته، لكن مع ذلك أنصحك بإنشاء مستخدم جديد إلى أن تضبط الخادوم وتجرّبه. سنُنشِئ بدايةً مستخدمًا جديدًا للتجربة: sudo adduser sammy أسنِد كلمة المرور إلى الحساب عند طلبها، ويمكنك تجاهل بقية الأسئلة بالضغط على زر Enter. تكون خدمة FTP أكثر أمانًا إذا كان المستخدمون محدودين بمجلدٍ معيّن، ويمكن لخادوم vsftpd فعل ذلك باستخدام chroot، فعند تفعيل chroot للمستخدمين المحليين، فلن يسمح لهم بالوصول إلى شيءٍ خارج مجلد المنزل الخاص بهم افتراضيًا، لكن خادوم vsftpd يحاول تأمين المجلد بعدم السماح بالكتابة عليه من قبل المستخدم (عبر سطر الأوامر)، ولا بأس بذلك للمستخدمين الجدد الذين يجب أن يتصلوا عبر FTP فقط، لكن إذا كان لدينا مستخدم موجود مسبقًا ويجب أن يستطيع الكتابة إلى مجلد المنزل الخاص به عبر سطر الأوامر فهذا لن يكون مناسبًا أبدًا. وبدلًا من إزالة إذن الكتابة من مجلد المنزل، فسنُنشِئ مجلد ftp لكي يكون chroot وسنُنشِئ داخله مجلد files يمكن الكتابة عليه ليحتوي على الملفات. لنُنشِئ مجلد ftp ونضبط ملكيته ونحذف إذن الكتابة منه بالأوامر الآتية: sudo mkdir /home/sammy/ftp sudo chown nobody:nogroup /home/sammy/ftp sudo chmod a-w /home/sammy/ftp لنتأكد من الأذونات: sudo ls -la /home/sammy/ftp الناتج: total 8 4 dr-xr-xr-x 2 nobody nogroup 4096 Aug 24 21:29 . 4 drwxr-xr-x 3 sammy sammy 4096 Aug 24 21:29 .. لنُنشِئ الآن المجلد الذي يحتوي على الملفات التي ستُرفَع ونضبط ملكيته إلى المستخدم: sudo mkdir /home/sammy/ftp/files sudo chown sammy:sammy /home/sammy/ftp/files لنتحقق أيضًا من أذونات المجلد files: sudo ls -la /home/sammy/ftp الناتج: total 12 dr-xr-xr-x 3 nobody nogroup 4096 Aug 26 14:01 . drwxr-xr-x 3 sammy sammy 4096 Aug 26 13:59 .. drwxr-xr-x 2 sammy sammy 4096 Aug 26 14:01 files وفي النهاية، لنضف ملفًا باسم test.txt لكي نستخدمه عند التجربة لاحقًا: echo "vsftpd test file" | sudo tee /home/sammy/ftp/files/test.txt بعد أن أصبح مجلد ftp آمنًا، وأعطينا المستخدم الأذونات اللازمة على مجلد files، فيمكننا الاهتمام الآن بموضوع الضبط. الخطوة الرابعة: ضبط وصول FTP خطتنا هي السماح للمستخدم الذي يملك وصولًا محليًا إلى سطر الأوامر بالاتصال عبر FTP، وهنالك خيارا ضبط رئيسيان مضبوطان في ملف vsftpd.conf. لنبدأ أولًا بفتح ملف الضبط للتأكد أنَّ التعليمات المذكورة فيه تُطابِق ما يلي: sudo nano /etc/vsftpd.conf محتوى الملف: . . . # Allow anonymous FTP? (Disabled by default). anonymous_enable=NO # # Uncomment this to allow local users to log in. local_enable=YES . . . علينا الآن تغيير بعض القيم في الملف، ولكي نسمح للمستخدم برفع الملفات فسنزيل رمز التعليق قبل التعليمة write_enable لكي يصبح السطر كما يلي: . . . write_enable=YES . . . سنُزيل رمز التعليق قبل التعليمة chroot_local_user لمنع المستخدم الذي يتصل عبر FTP من الوصول إلى أيّة ملفات خارج المجلد المضبوط: . . . chroot_local_user=YES . . . علينا إضافة التعليمة user_sub_token لكي نستطيع وضع اسم المستخدم في مسار local_root، وهذا لكي يعمل الضبط دون مشاكل لهذا المستخدم ولأي مستخدم آخر قد نضيفه مستقبلًا: user_sub_token=$USER local_root=/home/$USER/ftp سنُحدِّد مجال المنافذ المستخدم لاتصالات FTP غير المباشرة (passive FTP) لكي نحرص على توافر اتصالات كافية: pasv_min_port=40000 pasv_max_port=50000 تذكر أننا فتحنا هذه المنافذ سابقًا في الجدار الناري، أي لو استخدمتَ مجالًا مختلفًا عمّا سبق فاحرص على تحديث ضبط الجدار الناري بما يتوافق مع ذلك. ولأننا نخطط للسماح بوصول إلى FTP لمستخدمين معينين، فسنعدِّل في الضبط لكي نسمح بالوصول إلى قائمة معيّنة من المستخدمين: userlist_enable=YES userlist_file=/etc/vsftpd.userlist userlist_deny=NO التعليمة userlist_deny تُحدِّد ما الذي يجب فعله مع المستخدمين المذكورين في القائمة، فلو ضُبِطَت إلى YES فسيمنعون من الوصول إلى FTP، وإذا كانت NO فلن يسمح بالوصول إلى FTP إلا للمستخدمين المذكورين في القائمة. بعد أن تنتهي من إضافة الأسطر السابق فاحفظ الملف واخرج من المحرر النصي. علينا الآن إنشاء ملف القائمة وإضافة اسم المستخدم إليه، يمكننا استخدام الخيار ‎-a الخاص بالأمر tee لإسناد السطر إلى نهاية الملف: echo "sammy" | sudo tee -a /etc/vsftpd.userlist لنتأكد من محتوى الملف: cat /etc/vsftpd.userlist الناتج: sammy أعد تشغيل الخادوم لتطبيق التغييرات التي أجريناها في ملف الضبط: sudo systemctl restart vsftpd نحن جاهزون الآن للتجربة. الخطوة الخامسة: تجربة الوصول إلى FTP ضبطنا الخادوم للسماح للمستخدم sammy فقط بالوصول إلى FTP، لنتأكد من صحة ذلك. يجب ألّا يُسمَح للاتصال من المستخدمين المجهولين (anonymous users)، إذ عطلنا ذلك في الضبط، وسنجرِّب ذلك بمحاولة الاتصال بشكل مجهول، فإذا كان ضبطنا صحيحٌ فيجب ألّا يسمح لنا بالوصول إلى الخادوم: ftp -p 203.0.113.0 الناتج: Connected to 203.0.113.0. 220 (vsFTPd 3.0.3) Name (203.0.113.0:default): anonymous 530 Permission denied. ftp: Login failed. Ftp> أغلِق الاتصال: bye يجب ألّا يتمكن أيّ مستخدمٍ عدا sammy من الاتصال: وسنتحقق من ذلك عبر وضع اسم المستخدم الذي يملك امتيازات الجذر، ويجب ألّا يُسمَح له أيضًا قبل أن يُطلَب منه إدخال كلمة المرور: ftp -p 203.0.113.0 الناتج: Connected to 203.0.113.0. 220 (vsFTPd 3.0.3) Name (203.0.113.0:default): sudo_user 530 Permission denied. ftp: Login failed. Ftp> أغلِق الاتصال: bye يجب أن يتمكن المستخدم sammy من الاتصال، ومن قراءة وكتابة الملفات، لذا لنجرِّب ذلك: ftp -p 203.0.113.0 الناتج: Connected to 203.0.113.0. 220 (vsFTPd 3.0.3) Name (203.0.113.0:default): sammy 331 Please specify the password. Password: your_user's_password 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. Ftp> سندخل إلى المجلد files، ثم سنستعمل الأمر get لنقل ملف التجربة الذي أنشأناه سابقًا إلى جهازنا المحلي: cd files get test.txt الناتج: 227 Entering Passive Mode (203,0,113,0,169,12). 150 Opening BINARY mode data connection for test.txt (16 bytes). 226 Transfer complete. 16 bytes received in 0.0101 seconds (1588 bytes/s) ftp> سنحاول الآن إعادة رفع الملف باسمٍ جديد للتأكد من إمكانية الكتابة على المجلد: put test.txt upload.txt الناتج: 227 Entering Passive Mode (203,0,113,0,164,71). 150 Ok to send data. 226 Transfer complete. 16 bytes sent in 0.000894 seconds (17897 bytes/s) أغلِق الاتصال: bye بعد أن تأكدنا أنَّ الخادوم يعمل كما ضبطناه، فيمكننا إتباع إجراءات إضافية لتأمين الخادوم. الخطوة السادسة: جعل عمليات النقل آمنة لما كان بروتوكول FTP لا يشفِّر أيّة بيانات عند نقلها، بما في ذلك معلومات المستخدم، فعلينا تفعيل تشفير SSL/TLS لتأمين تلك البيانات، وأوّل خطوة هي إنشاء شهادات SSL لاستخدامها مع vsftpd. سنستخدم openssl لإنشاء شهادة جديدة، ونستخدم الخيار ‎-days لجعلها صالحةً لمدة سنة، وسنضيف –في الأمر نفسه– مفتاح ‎2048-bit RSA خاص، ثم بإسناد القيمة ذاتها إلى الخيارين ‎-keyout و ‎-out فستكون الشهادة والمفتاح الخاص في الملف نفسه. هذا هو الأمر الذي سنُطبِّقه: sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem سيُطلَب منّا توفير معلومات عن الشهادة التي سنُنشِئها، ضع المعلومات الخاصة بك عند الإجابة عن الأسئلة: Generating a 2048 bit RSA private key ............................................................................+++ ...........+++ writing new private key to '/etc/ssl/private/vsftpd.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:NY Locality Name (eg, city) []:New York City Organization Name (eg, company) [Internet Widgits Pty Ltd]:Hsoub Organizational Unit Name (eg, section) []: Common Name (e.g. server FQDN or YOUR name) []: Email Address []: بعد أن أنشأنا الشهادات، فعلينا الآن تعديل ضبط vsftpd مجددًا: sudo nano /etc/vsftpd.conf ستجد قرب نهاية الملف سطرين يبدآن بالسابقة rsa_‎، أضف قبلهما رمز التعليق ليصبحا كما يلي: # rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem # rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key أضف السطرين الآتيين بعدهما، اللذان يشيران إلى الشهادة والمفتاح الخاص اللذين أنشأناهما سابقًا: rsa_cert_file=/etc/ssl/private/vsftpd.pem rsa_private_key_file=/etc/ssl/private/vsftpd.pem علينا الآن جعل استخدام SSL إجباريًا، مما يمنع العملاء غير القادرين على التعامل مع تشفير TLS من الاتصال بخادومنا، وهذا ضروري للحرص على تشفير جميع المعلومات المنقولة لكن قد يجبر المستخدم على تغيير عميل الاتصال. عدِّل قيمة التعليمة ssl_enable إلى YES: ssl_enable=YES أضف بعد ذلك الأسطر الآتية لمنع الاتصالات المجهولة عبر SSL، ولإجبار استخدام SSL لتسجيل الدخول ولنقل البيانات: allow_anon_ssl=NO force_local_data_ssl=YES force_local_logins_ssl=YES علينا ضبط الخادوم استخدام TLS بدلًا من SSL عبر إضافة الأسطر الآتية: ssl_tlsv1=YES ssl_sslv2=NO ssl_sslv3=NO علينا بعد ذلك إضافة تعليمتين إضافيتين، الأولى تسمح بعدم استخدام SSL عند إعادة استخدام الجلسة (session reuse) لأنها لا تعمل مع أغلبية عملاء FTP، وسنطلب استخدام حزم عالية التشفير، وهذا يعني أنَّ طول المفتاح أكبر أو يساوي 128 بت: require_ssl_reuse=NO ssl_ciphers=HIGH بعد أن تنتهي من التعديلات السابقة، فاحفظ الملف وأغلق المحرر. علينا الآن إعادة تشغيل الخادوم لتأخذ التعديلات مجراها: sudo systemctl restart vsftpd لم نعد نتمكن الآن من استخدام عميل FTP غير الآمن الذي يعمل من سطر الأوامر، فلو جربناه فسنشاهد الناتج الآتي: ftp -p 203.0.113.0 Connected to 203.0.113.0. 220 (vsFTPd 3.0.3) Name (203.0.113.0:default): sammy 530 Non-anonymous sessions must use encryption. ftp: Login failed. 421 Service not available, remote server has closed connection ftp> سنتحقق من الاتصال في الخطوة القادمة باستخدام عميل يدعم تشفير TLS. الخطوة السابعة: تجربة الاتصال عبر TLS باستخدام FileZilla أغلبية عملاء FTP الحديثين يدعمون تشفير TLS، وسنشرح كيفية الاتصال عبر عميل FileZilla لأنه يعمل على جميع أنظمة التشغيل؛ راجع توثيق عميلك المفضل لتعرف كيف يمكن الاتصال عبر TLS فيه. عندما تفتح برنامج FileZilla فسنجد أيقونة Site Manager تحت قائمة File مباشرةً، أي أنَّها أوّل أيقونة في الشريط العلوي. اضغط عليها: ستُفتَح نافذة جديدة، اضغط فيها على زر «New Site» في الركن السفلي الأيسر: ستجد ظهور «New site» تحت أيقونة «My Sites»، يمكنك تسمية الموقع الآن أو إعادة تسميته لاحقًا بالضغط على زر «Rename». عليك أن تملأ حقل «Host» بعنوان IP أو اسم نطاق الموقع، وعليك أن تختار «Require explicit FTP over TLS» في قائمة «Encryption» أما لخيار «Logon Type» فاختر «Ask for password»، ثم أدخِل اسم المستخدم في حقل «User»: اضغط على زر «Connect» في أسفل النافذة، وستُسأل عن كلمة مرور المستخدم: اضغط على «OK» لتتصل، يجب أن يكون اتصالك مع الخادوم مشفرًا بتشفير TLS/SSL. بعد أن تقبل الشهادة، فانقر نقرًا مزدوجًا على مجلد files واسحب الملف upload.txt وأفلته في القسم اليساري من البرنامج لكي تبدأ بتنزيله: بعد ذلك، يمكنك أن تنقر بالزر الأيمن على الملف المحلي وتعيد تسميته إلى upload-tls.txt وتسحبه مجددًا إلى الخادوم لكي ترفعه عليه. لقد تمكنا من تنزيل الملفات ورفعها بأمان مع تفعيل تشفير SSL/TLS. الخطوة الثامنة: تعديل الوصول إلى سطر الأوامر (خطوة اختيارية) إن لم تتمكن من استخدام تشفير TLS بسبب محدوديات العميل، فيمكنك تأمين الخادوم قليلًا بمنع مستخدم FTP من تسجيل الدخول إلى سطر الأوامر، إحدى الطرائق البسيطة لفعل ذلك هي إنشاء صدفة (shell) خاصة. أكرِّر أنَّ الخطوة السابقة لا توفِّر أيّ تشفير، وإنما الغرض منها هو تقليل الوصول إلى حسابات المستخدمين المسموح لهم بالاتصال عبر FTP فقط. علينا أولًا إنشاء ملف باسم ftponly في مجلد ‎/bin: sudo nano /bin/ftponly سنضيف الآن رسالةً تخبر المستخدم أنَّه ليس قادرًا على تسجيل الدخول، أضف ما يلي يلي إلى الملف: #!/bin/sh echo "This account is limited to FTP access only." عدِّل الأذونات لجعل الملف قابلًا للتنفيذ: sudo chmod a+x /bin/ftponly افتح الملف الذي يضم قائمةً بالصدفات (shells) الصالحة للاستخدام في النظام: sudo nano /etc/shells وأضف في نهاية الملف: . . . /bin/ftponly عدِّل الصدفة الافتراضية للمستخدم عبر الآمر الآتي: sudo usermod sammy -s /bin/ftponly جرِّب الآن تسجيل الدخول بحساب المستخدم sammy: ssh sammy@203.0.113.0 ستجد رسالةً شبيهةً بالرسالة الآتية: This account is limited to FTP access only. Connection to 203.0.113.0 closed. هذا يؤكد أنَّ المستخدم غير قادر على تسجيل الدخول إلى الخادوم عبر الأمر ssh، ويُسمَح له بالوصول إلى FTP فقط. الخلاصة لقد شرحنا في هذا الدرس كيفية ضبط خادوم FTP للمستخدمين الذين يملكون حسابًا محليًا على النظام، أما إذا أردتَ استخدام مصدر خارجي للاستيثاق، فيمكنك إلقاء نظرة على دعم خادوم vsftpd للمستخدمين الوهميين (virtual users). هنالك خياراتٌ واسعة لدعم استخدام PAM مما يجعلك قادرًا على إدارة المستخدمين في نظام استيثاق مختلف مثل LDAP أو Kerberos. ترجمة –وبتصرّف– للمقال How To Set Up vsftpd for a User’s Directory on Ubuntu 16.04لصاحبته Melissa Anderson
  5. من المهم جدًا الحفاظ على دقة وقت النظام، سواءً فعلنا ذلك للحرص على دقة ترتيب السجلات (logs) أو أنَّ تحديثات قاعدة البيانات ستُطبَّق دون مشاكل؛ فإذا كان الوقت المضبوط على النظام غير صحيح، فقد يسبب ذلك أخطاءً أو تلفًا في البيانات أو مشاكل أخرى يصعب معرفة سببها بسهولة. ميزة مزامنة الوقت مضمّنةٌ ومفعّلةٌ في أوبنتو 16.04 افتراضيًا عبر خدمة timesyncd، وسنلقي في هذا الدرس نظرةً على الأوامر الأساسية المتعلقة بالوقت، ونتأكد أنَّ خدمة timesyncd مفعّلة، ونتعلم كيفية تثبيت خدمة بديلة لمزامنة الوقت والتاريخ. المتطلبات المسبقة يجب أن تملك قبل اتباع تعليمات هذا الدرس خادومًا يعمل بنظام أوبنتو 16.04 مع مستخدم ليس جذرًا لكنه يملك امتيازات الجذر عبر الأمر sudo؛ انظر إلى درس الإعداد الابتدائي لخادوم أوبنتو 14.04» لمزيدٍ من المعلومات. تعلّم الأوامر الأساسية للتعامل مع الوقت إنَّ أبسط الأوامر لمعرفة ما هو الوقت الحالي في نظامك هو date، يمكن لأي مستخدم كتابة هذا الأمر للحصول على الوقت والتاريخ الحاليين: date مثال على الناتج: Wed Apr 26 17:44:38 UTC 2017 من المرجح أنَّ المنطقة الزمنية المستعملة في خادومك هي UTC كما هو ظاهر في المثال أعلاه، كلمة UTC هي اختصار لعبارة Coordinated Universal Time (التوقيت العالمي الموحد) وهو الوقت عند مبدأ خطوط الطول، واستعمال توقيت UTC سيسهل عليك العمل إذا كانت خواديمك تمتد لأكثر من منطقة زمنية وحيدة. إذا أردت تغيير المنطقة الزمنية لأي سببٍ من الأسباب، فيمكنك استخدام الأمر timedatectl لفعل ذلك. اعرض أولًا قائمةً بالمناطق الزمنية المتاحة: timedatectl list-timezones ستُعرَض قائمة بجميع المناطق الزمنية، يمكنك الضغط على زر Space للتمرير إلى الأسفل وزر b للتمرير إلى الأعلى؛ وبعد أن تعثر على المنطقة الزمنية الصحيحة فدوِّنها عندك ثم اضغط على q للخروج من القائمة. يمكنك الآن ضبط القائمة الزمنية باستخدام الأمر timedatectl set-timezone، احرص على وضع منطقتك الزمنية بدلًا من تلك المذكورة في الأمر الآتي؛ لاحظ أنَّك ستحتاج إلى استخدام الأمر sudo مع الأمر timedatectl لإجراء هذا التعديل: sudo timedatectl set-timezone America/New_York يمكنك التحقق من التغييرات بتشغيل الأمر date مجددًا: date الناتج: Wed Apr 26 13:55:45 EDT 2017 يجب أن يشير الاختصار المذكور في الأمر السابق إلى المنطقة الزمنية التي اخترتها. تعلمنا كيف نتحقق من الوقت الحالي وكيف نضبط المناطق الزمنية، وسنتعلم الآن كيف نتأكد من مزامنة الوقت في نظامنا. التحكم بخدمة timesyncd بواسطة timedatectl كانت أغلبية عمليات مزامنة الوقت تتم عبر خدمة بروتوكول وقت الشبكة (Network Time Protocol daemon) ntpd، أي سيتصل الخادوم إلى مجموعة من خواديم NTP التي توفر الوقت بدقة كبيرة. لكن توزيعة أوبنتو تستعمل timesyncd بدلًا من ntpd لمزامنة الوقت، إذ تتصل خدمة timesyncd إلى خواديم الوقت نفسها وتعمل العمل نفسه تقريبًا، لكنها أخف وتندمج اندماجًا أفضل مع systemd وطريقة العمل الداخلية في توزيعة أوبنتو. يمكنك الحصول على حالة خدمة timesyncd بتشغيل الأمر timedatectl دون معاملات، ولن تحتاج إلى استخدام sudo في هذا الموضع: timedatectl الناتج: Local time: Wed 2017-04-26 17:20:07 UTC Universal time: Wed 2017-04-26 17:20:07 UTC RTC time: Wed 2017-04-26 17:20:07 Time zone: Etc/UTC (UTC, +0000) Network time on: yes NTP synchronized: yes RTC in local TZ: no سيطبع الأمر السابق الوقت المحلي والوقت العالمي (والذي يساوي الوقت المحلي في حال لم تغيّر المنطقة الزمنية)، وبعض معلومات عن حالة وقت الشبكة. السطر Network time on: yes يعني أنَّ خدمة timesyncd مفعّلة، والسطر NTP synchronized: yes يشير إلى نجاح مزامنة الوقت. إذا لم تكن خدمة timesyncd مفعلةً، فشغِّلها باستعمال الأمر timedatectl: sudo timedatectl set-ntp on شغِّل الأمر timedatectl مجددًا للتأكد من حالة وقت الشبكة؛ لاحظ أنَّ عملية التزامن تحتاج إلى بعض الوقت، لكن في النهاية يجب أن تكون قيمة السطرين Network time on:‎ و NTP synchronized:‎ تساوي yes. التحويل إلى خدمة ntpd على الرغم من أنَّ خدمة timesyncd مناسبة لغالبية الاحتياجات، لكن بعض التطبيقات حساسةٌ جدًا لأدنى اضطراب في الوقت ومن المستحسن استعمال ntpd في هذه الحالات، لأنه يستعمل تقنيات معقدة لإبقاء الوقت في النظام مزامنًا دومًا. علينا إيقاف خدمة timesyncd قبل تثبيت ntpd: sudo timedatectl set-ntp no للتأكد من إيقاف خدمة timesyncd: timedatectl ابحث عن السطر Network time on: no الذي يعني أنَّ خدمة timdsyncd متوقفة؛ يمكننا الآن تثبيت حزمة ntp باستعمال الأداة apt-get: sudo apt-get install ntp يجب أن يعمل خادوم ntpd تلقائيًا بعد التثبيت، يمكنك عرض حالة خدمة ntpd للتأكد أنَّ كل شيءٍ على ما يرام: sudo ntpq -p الناتج: remote refid st t when poll reach delay offset jitter ============================================================================== 0.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 1.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 2.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 3.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 ntp.ubuntu.com .POOL. 16 p - 64 0 0.000 0.000 0.000 -makaki.miuku.ne 210.23.25.77 2 u 45 64 3 248.007 -0.489 1.137 -69.10.161.7 144.111.222.81 3 u 43 64 3 90.551 4.316 0.550 +static-ip-85-25 130.149.17.21 2 u 42 64 3 80.044 -2.829 0.900 +zepto.mcl.gg 192.53.103.108 2 u 40 64 3 83.331 -0.385 0.391 ntpq هي أداة لطلب (query) معلومات حول خدمة ntpd، والخيار ‎-p يطلب معلومات حول خواديم NTP ‏(peers) التي اتصلت خدمة ntpd بها. قد يختلف الناتج عندك قليلًا، لكن يجب أن تتضمن القائمة على خواديم أوبنتو الافتراضية إضافةً إلى غيرها. أبقِ في ذهنك أنَّ خدمة ntpd تحتاج إلى بضع دقائق لتهيئة الاتصالات… الخلاصة رأينا في هذا الدرس طريقة عرض وقت النظام، وكيفية تغيير المناطق الزمنية، وطريقة التعامل مع خدمة timesyncd الموجودة افتراضيًا في أوبنتو، إضافةً إلى طريقة تثبيت ntpd. إذا كان نظامك ذو احتياجات خاصة لم نشرحها في هذا الدرس، فأنصحك بالرجوع إلى توثيق NTP الرسمي، وألقِ نظرةً على مشروع NTP Pool الذي هو مجموعةٌ من المتطوعين الذين يوفرون جزءًا كبيرًا من البنية التحتية التي يحتاج لها بروتوكول NTP في العالم. ترجمة –وبتصرّف– للمقال How To Set Up Time Synchronization on Ubuntu 16.04لصاحبه Brian Boucheron حقوق الصورة البارزة محفوظة لـ Freepik
  6. تعرّفنا في الجزأين السابقيْن من هذا الدليل على كيفية عرض معلومات عن مساحات التخزين وإنشاء مساحات تخزين جديدة وتحجيمها. سنكمل في هذا الجزأ - الأخير من الدليل - ما تعلمناه سابقا ونتعرّف على المهمة الأخيرة من بين المهمّات الأساسية في إدارة التخزين بآلية LVM. تنبيه: تأكّد من أنّ الأجهزة التّي تودّ تطبيق الأوامر المذكورة في هذا الدرس عليها لا تحتوي على بيانات مُهمّة. استخدام هذه الأجهزة مع LVM سيؤدّي إلى الكتابة فوق المحتويات الحاليّة. يُفضَّل أن تختبر الخطوات المعروضة أدناه في آلة افتراضية أو على خادوم خاصّ بأغراض التجربة والاختبار. إزالة أو تقليص مُكوّنات LVM بما أن تقليص مساحة التّخزين قد يؤدي إلى فقدان البيانات، فإجراءات تقليص المساحة المتوفّرة، سواءٌ بتقليص حجم أو حذف المكوّنات، أكثر تعقيدًا من بقية المهامّ. تخفيض حجم وحدة تخزين منطقيّة لتقليص وحدة تخزين منطقيّة، يجب عليك أولا أخذ نسخة احتياطية من بياناتك. فبما أن هذه العمليّة تقلّص مساحة التّخزين المُتوفّرة فإن أي خطأ يُمكن له أن يُؤدي إلى فقدان البيانات. إذا كنت جاهزا، تأكّد من حجم المساحة المُستخدمة حاليّا: df -h المُخرج: Filesystem Size Used Avail Use% Mounted on . . . /dev/mapper/LVMVolGroup-test 4.8G 521M 4.1G 12% /mnt/test في هذا المثال، يبدو بأنّنا نستخدم حاليّا حوالي 521M من المساحة. استعمل هذه المعلومة لتحديد الحجم الذي تريد تقليص وحدة التخزين إليه. تاليّا، أزل تركيب نظام الملفّات. فعلى عكس التوسيعات، يجب عليك تقليص مساحة نظام الملفّات أثناء إزالة التركيب: cd ~ sudo umount /dev/LVMVolGroup/test بعد إزالة التركيب، تأكّد من أن نظام الملفّات في حالة جيّدة. مرّر نوع نظام الملفّات عبر الخيار -t. سنستعمل الخيار -f للتّحقّق من أن كل شيء على ما يرام حتى ولو بدا كذلك: sudo fsck -t ext4 -f /dev/LVMVolGroup/test بعد التّحقّق من سلامة نظام الملفّات، يُمكنك تقليص مساحته باستخدام الأدوات الخاصّة، في حالة Ext4، فالأمر سيكون resize2fs. مرّر الحجم النّهائي لنظام الملفّات. تنبيه: أكثر خيار أمانا هو تمرير حجم نهائي أكبر بكثير من الحجم المُستخدم حاليا. أعط نفسك مساحة أمان لتجنّب فقدان البيانات وتأكّد من إنشاء نسخ احتياطيّة. sudo resize2fs -p /dev/LVMVolGroup/test 3G حالما تنتهي العمليّة، قلّص حجم وحدة التّخزين المنطقيّة عبر تمرير نفس الحجم (3G في هذه الحالة) إلى الأمر lvresize عبر الخيار -L. sudo lvresize -L 3G LVMVolGroup/test ستستقبل تنبيها حول فقدان البيانات، إن كنت جاهزا، فاكتب y للاستمرار. بعد تقليص حجم وحدة التّخزين المنطقيّة، تحقّق من سلامة نظام الملفّات مُجدّدا: sudo fsck -t ext4 -f /dev/LVMVolGroup/test إن سار كلّ شيء على ما يرام، فستستطيع إعادة وصل نظام الملفّات بالأمر المُعتاد: sudo mount /dev/LVMVolGroup/test /mnt/test ينبغي الآن على وحدة التّخزين المنطقيّة أن تُقلّص إلى الحجم المُحدّد. حذف وحدة تخزين منطقيّة إن لم تعد بحاجة إلى وحدة تخزين منطقيّة، يُمكنك حذفها باستعمال الأمر lvremove. أولا، أزل تركيب وحدة التخزين: cd ~ sudo umount /dev/LVMVolGroup/test بعدها، احذف وحدة التخزين بالأمر التّالي: sudo lvremove LVMVolGroup/test سيُطلب منك تأكيد العمليّة، إن كنت متأكّدا من رغبتك في حذف وحدة التّخزين، فاكتب y. حذف مجموعة تخزين لحذف مجموعة تخزين كاملة، بما في ذلك جميع وحدات التّخزين المنطقيّة المتواجدة بها، استعمل الأمر vgremove. قبل حذف مجموعة تخزين، عليك حذف وحدات التّخزين بداخلها بالعمليّة أعلاه. أو على الأقل، تأكّد من إزالة تركيب جميع وحدات التّخزين بداخل المجموعة: sudo umount /dev/LVMVolGroup/www sudo umount /dev/LVMVolGroup/projects sudo umount /dev/LVMVolGroup/db بعدها يُمكنك حذف مجموعة التّخزين عبر تمرير اسمها إلى الأمر vgremove: sudo vgremove LVMVolGroup سيُطلب منك تأكيد عمليّة حذف المجموعة. إذا كانت هناك أية وحدات تخزين منطقيّة مُتبقيّة، ستُسأل عن تأكيد حذفها واحدة واحدة قبل حذف المجموعة. حذف وحدة تخزين ماديّة إن أردت إزالة وحدة تخزين ماديّة من إدارة LVM، فسيعتمد الإجراء المطلوب على ما إذا كانت الوحدة مُستخدمة من طرف LVM أو لا. إن كانت وحدة التّخزين الماديّة مُستخدَمة، سيتوجّب عليك نقل المداءات الماديّة على الجهاز إلى مكان آخر. سيتطلّب ذلك وجود وحدات تخزين ماديّة أخرى لتحتضن المداءات الماديّة. إن كنت تستعمل أنواعا مُعقّدة من وحدات التّخزين المنطقيّة، فقد يتوجّب عليك الحصول على المزيد من وحدات التّخزين الماديّة حتى ولو كانت لديك مساحة تخزين كافيّة. إن كان لديك عدد كاف من وحدات التّخزين الماديّة في مجموعة التّخزين لاحتضان المداءات الماديّة، فانقلها إلى خارج وحدة التّخزين الماديّة التي ترغب في إزالتها عبر كتابة ما يلي: sudo pvmove /dev/sda يُمكن لهذه العمليّة أن تأخذ وقتا طويلا حسب حجم وحدات التّخزين وكميّة البيانات التي يتوجب نقلها. حالما تنتقل المداءات إلى وحدات تخزين أخرى، يُمكنك حذف وحدة التّخزين الماديّة من مجموعة التّخزين عبر الأمر التّالي: sudo vgreduce LVMVolGroup /dev/sda هذه العمليّة كفيلة بإزالة وحدات التّخزين التي أُخلِيت من مجموعة التّخزين. بعد انتهاء العمليّة، يُمكنك حذف علامة وحدة التّخزين الماديّة من جهاز التّخزين عبر الأمر: sudo pvremove /dev/sda ينبغي الآن أن تتمكّن من استعمال جهاز التّخزين المُزال لأغراض أخرى أو إزالته من النّظام بالكامل. ختاما إلى هذه النّقطة، يجب أن يكون لديك فهم لكيفيّة إدارة أجهزة التّخزين على أوبونتو 16.04 مع LVM. يجب أن تعرف كيفيّة الحصول على معلومات عن مكوّنات LVM، كيفيّة استخدام LVM لتركيب نظام تخزين خاص بك، وكيفيّة تعديل وحدات التّخزين لتلبيّة حاجاتك. يُمكنك اختبار هذه المبادئ في بيئة آمنة لفهم أعمق حول آليّة عمل LVM ومكوّناته. ترجمة – بتصرّف - للمقال How To Use LVM To Manage Storage Devices on Ubuntu 16.04 لكاتبه Justin Ellingwood.
  7. بعد أن تعرّفنا في الجزء السابق على كيفية عرض معلومات عن مختلف العناصر في LVM، سنتطرّق في هذا الجزء من الدليل إلى كيفية التحكم في هذه المكوّنات بإنشاء مكوّنات جديدة أو إعادة تحجيم (توسيع أو تقليص) مكوّنات موجودة. إنشاء أو توسيع مكوّنات LVM سنتحدّث في هذه الفقرات عن كيفيّة إنشاء وتوسيع وحدات التّخزين الماديّة والمنطقيّة وكذا مجموعات التّخزين. إنشاء وحدات تخزين ماديّة من أجهزة تخزين خام لاستعمال أجهزة التّخزين مع LVM، يجب عليها أولا أن تُعلّم على أنها وحدات تخزين ماديّة. ما يُحدّد إمكانيّة استخدام الجهاز داخل مجموعة تخزين. أولا، استعمل الأمر lvmdiskscan لإيجاد جميع أجهزة التّخزين التي يُمكن لـLVM رؤيتها واستخدامها: sudo lvmdiskscan المُخرج: /dev/ram0 [ 64.00 MiB] /dev/sda [ 200.00 GiB] /dev/ram1 [ 64.00 MiB] . . . /dev/ram15 [ 64.00 MiB] /dev/sdb [ 100.00 GiB] 2 disks 17 partitions 0 LVM physical volume whole disks 0 LVM physical volumes في المُخرج أعلاه، بتجاهل أجهزة /dev/ram*، يُمكننا رؤية الأجهزة التّي يُمكن تحويلها إلى وحدات تخزين ماديّة لـLVM. تنبيه: تأكّد من أنّ الأجهزة التّي ترغب باستعمالها مع LVM لا تحتوي على أيّة بيانات مُهمّة. استخدام هذه الأجهزة مع LVM سيؤدّي إلى الكتابة فوق المحتويات الحاليّة. إذا كنت تمتلك بيانات مهمّة على خادومك فأنشئ نسخا احتياطية قبل الاستمرار في تطبيق الدّرس. لجعل أجهزة التّخزين وحدات تخزين ماديّة خاصّة بـLVM، استعمل الأمر pvcreate. يُمكنك تمرير عدّة أجهزة في نفس الوقت: sudo pvcreate /dev/sda /dev/sdb هذا الأمر سيكتب ترويسة LVM على جميع الأجهزة الهدف لتخصيصها كوحدات تخزين LVM ماديّة. إنشاء مجموعة تخزين من وحدات التّخزين الماديّة لإنشاء مجموعة تخزين جديدة من وحدات التّخزين الماديّة، استعمل الأمر vgcreate. سيتوجّب عليك تمرير اسم للمجموعة متبوعا بوحدة تخزين ماديّة واحدة على الأقل: sudo vgcreate volume_group_name /dev/sda استبدل volume_group_name باسم من اختيارك لمجموعة التّخزين. سينشئ المثال أعلاه مجموعة تخزين انطلاقا من وحدة تخزين ماديّة واحدة فقط. يُمكنك تمرير أكثر من وحدة تخزين ماديّة عند إنشاء المجموعة إن أردت ذلك: sudo vgcreate volume_group_name /dev/sda /dev/sdb /dev/sdc عادة ستحتاج إلى مجموعة تخزين واحدة فقط لكل خادوم. بحيث يُمكنك إضافة أي مساحة تخزين إضافيّة لمنطقة مُوحّدة ثمّ تخصيص وحدات تخزين منطقيّة منها. الحاجة إلى استخدام أحجام مداءات مُختلفة من الأسباب التّي قد تدفعك إلى إنشاء أكثر من مجموعة تخزين واحدة. في العادة، لن يتوجّب عليك تحديد حجم المدى (الحجم المبدئي هو 4M ويُعدّ كافيّا لمُعظم الاستخدامات)، لكنّ إن أردت، يُمكنك تحديد حجم المداءات عند إنشاء مجموعة التّخزين باستعمال الخيار -s: sudo vgcreate -s 8M volume_group_name /dev/sda سينشئ هذا الأمر مجموعة تخزين مع حجم مداءات يُساوي 8M. إضافة وحدة تخزين ماديّة إلى مجموعة تخزين موجودة مُسبقا لتوسيع مجموعة تخزين عبر إضافة وحدات تخزين ماديّة، استخدم الأمر vgextend. يأخذ هذا الأمر مجموعة تخزين متبوعة بوحدات التّخزين الماديّة التّي ترغب بإضافتها إلى المجموعة. يُمكنك كذلك تمرير أكثر من جهاز في نفس الوقت إن أردت: sudo vgextend volume_group_name /dev/sdb ستُضاف وحدة التّخزين الماديّة إلى مجموعة التّخزين موسّعة بذلك مساحة التّخزين المُتوفّرة على المجموعة. إنشاء وحدة تخزين منطقيّة بحجم مُحدّد لإنشاء وحدة تخزين منطقيّة من مجموعة تخزين، استعمل الأمر lvcreate. حدّد حجم وحدة التّخزين المنطقيّة باستخدام الخيار -L، وحدّد اسما عبر الخيار -n، ومرّر مجموعة التّخزين الأم. على سبيل المثال، لإنشاء وحدة تخزين منطقيّة تُسمّى test من مجموعة تخزين تُسمّى LVMVolGroup، اكتب: sudo lvcreate -L 10G -n test LVMVolGroup على افتراض أنّ بمجموعة التّخزين مساحة تخزين فارغة توافق حجم وحدة التّخزين، فإنشاء وحدة التّخزين الجديدة سيتمّ بنجاح. إنشاء وحدة تخزين منطقيّة من كامل باقي المساحة الفارغة إن أردت إنشاء وحدة تخزين من باقي المساحة الفارغة على مجموعة تخزين، استعمل الأمر vgcreate مع الخيار -n لتحديد اسم لها ثمّ مرّر مجموعة التّخزين كما في السّابق. عوضا عن تمرير حجم مُعيّن، استعمل الخيار -l 100%FREE لتحديد بقيّة المساحة الفارغة في المجموعة: sudo lvcreate -l 100%FREE -n test2 LVMVolGroup إنشاء وحدات تخزين منطقيّة مع خيارات مُتقدّمة يُمكنك إنشاء وحدات تخزين منطقيّة مع خيارات مُتقدّمة كذلك. التّالي بعض من الخيارات التي يُمكن أن تأخذها بعين الاعتبار: --type: يقوم هذا الخيار بتحديد نوع وحدة التّخزين المنطقيّة ما يُحدّد كيفيّة تخصيص مساحة له. بعض من هذه الأنواع لن تكون مُتوفّرة إن لم يكن لديك الحدّ الأدنى من وحدات التّخزين الماديّة التي يتطلّبها النّوع. بعض من أكثر هذه الأنواع شيوعا هي كما يلي: linear: النّوع المبدئي. أجهزة التّخزين المُستخدمة ستُضاف بعضها على بعض واحدا تلو الآخر. striped: مُشابه لـRAID 0، تُقسّم البيانات إلى قطع صغيرة وتُنشر على شكل قوس على وحدات التّخزين الماديّة المُستعملة. ما يؤدّي إلى تحسينات في الأداء، لكن يُمكن أن يؤدي إلى زيادة في قابليّة إصابة البيانات. لتحديد هذا النّوع، يجب عليك تمرير الخيار -i ويتطلّب وحدتي تخزين ماديّتين على الأقل. raid1: إنشاء وحدة تخزين RAID 1 مُنعكسة Mirrored. مبدئيًّا، سيكون للانعكاس نُسختان، لكن يُمكنك تحديد عدد أكبر عبر الخيار -m المشروح أسفله. هذا الخيار يتطلّب وحدتي تخزين ماديّتين على الأقل. raid5: إنشاء وحدة تخزين RAID 5. يتطلّب ثلاثة وحدات تخزين ماديّة على الأقل. raid6: إنشاء وحدة تخزين RAID 6. يتطلّب أربعة وحدات تخزين ماديّة على الأقل. -m: يحدّد عدد نُسخ البيانات الإضافيّة. إن مرّرت القيمة 1 فهذا يعني بأنّ نُسخة واحدة إضافيّة من البيانات ستُصان، بحيث يكون لديك مجموعتان من نفس البيانات. -i: يُحدّد عدد الشّرائط Stripes. هذا الخيار مطلوب للنوع striped، ويُمكن أن يُؤثّر على بعض خيارات RAID الأخرى. -s: يُحدّد بأنّ أخذ لقطة يجب أن يتمّ على مُستوى وحدة التّخزين المنطقيّة الحاليّة عوضا عن إنشاء وحدة تخزين منطقيّة جديدة ومُستقلّة. سنلقي نظرة على بضعة أمثلة لهذه الخيارات لنرى حالات الاستخدام الشّائعة. لإنشاء وحدة تخزين شريطيّة Striped volume، يجب عليك تحديد شريطين على الأقل. هذه العمليّة تحتاج إلى وحدتي تخزين ماديّتين على الأقل مع مساحة تخزين متوافقة مع الحجم المُراد: sudo lvcreate --type striped -i 2 -L 10G -n striped_vol LVMVolGroup لإنشاء مساحة تخزين مُنعكسة Mirrored volume، استخدم النّوع raid1. إن أردت أكثر من مجموعتي بيانات، استعمل الخيار -m. المثال التّالي يستعمل -m 2 لإنشاء ثلاث مجموعات من البيانات (يعتبر LVM بأنّها مجموعة واحدة من البيانات مع انعكاسين). ستحتاج إلى ثلاثة وحدات تخزين ماديّة على الأقل لنجاح العمليّة: sudo lvcreate --type raid1 -m 2 -L 20G -n mirrored_vol LVMVolGroup لإنشاء لقطة لوحدة تخزين ما، يجب عليك تحديد وحدة التّخزين المنطقيّة الأصل التي ستأخذ منها اللقطة وليس كامل مجموعة التّخزين. لا تحجز اللقطات الكثير من المساحة في البدء، لكنّ حجمها يزداد كلّما أُجرِيَت تغييرات على وحدة التّخزين المنطقيّة الأصليّة. عند إنشاء لقطة ما، فالحجم المُخصّص يكون أقصى حدّ يُمكن للقطة أن تصل إليه (اللقطات التي تزيد عن هذا الحجم مُعطّلة وغير قابلة للاستخدام؛ لكن يُمكن توسيع اللقطات التي تقترب من هذا الحجم): sudo lvcreate -s -L 10G -n snap_test LVMVolGroup/test تنبيه: لإعادة وحدة تخزين إلى الحالة التي تتواجد بها اللقطة، استخدم الأمر lvconvert --merge: sudo lvconvert --merge LVMVolGroup/snap_test سيقوم هذا الأمر بإعادة اللقطة إلى الحالة التي كانت عليها عندما تمّ إنشاؤها. كما ترى، هناك العديد من الخيارات التي يُمكن لها أن تُغيّر طريقة عمل وحدة التخزين المنطقيّة بشكل كبير. زيادة حجم وحدة تخزين منطقيّة المرونة في التّعامل مع وحدات التّخزين المنطقيّة من أكثر المميّزات المتوفّرة في LVM. إذ يُمكنك بسهولة تعديل عدد أو حجم وحدات التّخزين المنطقيّة دون إيقاف النّظام. لزيادة حجم وحدة تخزين منطقيّة أنشئت مُسبقا، استعمل الأمر lvresize. مرّر قيمة إلى الخيار -L لتحديد حجم جديد. يُمكنك كذلك استخدام أحجام نسبيّة عبر الرّمز +. في هذه الحالة سيقوم LVM بإضافة الكميّة المُحدّدة إلى الحجم الكلي لوحدة التّخزين. لتعديل حجم نظام الملفّات المُستخدم على وحدة التّخزين بشكل آلي، استعمل الخيار --resizefs. لتحديد اسم صحيح لوحدة التّخزين التي ترغب بتوسيعها، سيتوجّب عليك تحديد مجموعة التّخزين، ثمّ رمز / متبوعا باسم وحدة التّخزين المنطقيّة: sudo lvresize -L +5G --resizefs LVMVolGroup/test في هذا المثال، سيتمّ زيادة 5G لكل من وحدة التّخزين test ونظام الملفّات المُستخدم. إن أردت توسيع نظام الملفّات يدويًّا، يُمكنك حذف الخيار --resizefs واستعمال أداة توسيع نظام الملفّات الخاصّة. مثلا، لو كان نظام الملفّات هو Ext4 فيُمكن أن تكتب: sudo lvresize -L +5G LVMVolGroup/test sudo resize2fs /dev/LVMVolGroup/test سيكون لهذه العمليّة نفس تأثير ما سبق. ترجمة – بتصرّف - للمقال How To Use LVM To Manage Storage Devices on Ubuntu 16.04 لكاتبه Justin Ellingwood.
  8. مُقدّمة LVM اختصار لعبارة Logical Volume Management، عبارة عن تقنيّة لإدارة أجهزة التّخزين تُمكّن المُستخدمين من توحيد وتجريد التّخطيط الماديّ لمكونات أجهزة التّخزين، لإدارتها بسهولة ومرونة. يُمكن استعمال النّسخة الحاليّة LVM2 بالاعتماد على إطار العمل الخاصّ بربط الأجهزة في نواة لينكس لجمع أجهزة التّخزين المُتوفّرة في مجموعات وتخصيص وحدات منطقيّة Logical units من المساحة المُركّبة حسب الطّلب. سنتعرّف في هذا الدليل على كيفية استخدام LVM لإدارة أجهزة التّخزين الخاصّة بك. سنرى كيفيّة عرض معلومات حول وحدات التّخزين وأهداف مُحتملة، كيفيّة إنشاء ومحو مُختلف أنواع وحدات التّخزين، وكيفيّة تعديل وحدات تخزينيّة متواجدة عبر إعادة تخصيص حجم لها وتحويلها. سنعتمد على Ubuntu 16.04 لأمثلة على تنفيذ هذه العمليّات. المُتطلّبات لمُتابعة الدّرس، يجب أن تكون قادرا على الوصول إلى خادوم Ubuntu 16.04. ستحتاج إلى مُستخدم ذي صلاحيّات sudo مع ضبط مُسبق لتمكينه من تنفيذ مهام إداريّة، غير المستخدم الجذر root. لأخذ فكرة حول مكوّنات LVM ومبادئه ولاختبار إعداد بسيط باستخدام LVM، اتّبع درس مدخل إلى LVM قبل الشّروع في هذا الدّرس. إن كنت جاهزا، ادخل إلى خادومك باستخدام حساب المُستخدم ذي صلاحيّات sudo. ملحوظة: يُفضَّل إن كانت هذه أول مرة تتعامل فيها مع LVM أو إن لم تكن متأكّدا من ما تريد فعله أن تختبر الخطوات المعروضة في هذا الدليل في آلة افتراضية أو على خادوم خاصّ بأغراض التجربة والاختبار. قد يؤدّي تنفيذ أوامر بطريقة غير صحيحة إلى ضياع البيانات. عرض معلومات حول وحدات التّخزين الماديّة، مجموعات التّخزين، ووحدات التّخزين المنطقيّة من المُهمّ أن تكون قادرا على الحصول على معلومات حول مُختلف مُكوّنات LVM في نظامك بسهولة. لحسن الحظّ، توفّر حزمة أدوات LVM كميّة وفيرة من الأدوات لعرض معلومات حول كلّ طبقة من طبقات كومة LVM. عرض معلومات حول جميع أجهزة التّخزين الكتليّة المتوافقة مع LVM لعرض جميع أجهزة التّخزين الكتليّة التي يُمكن لـLVM إدارتها، استخدم الأمر lvmdiskscan: sudo lvmdiskscan المُخرَج: /dev/ram0 [ 64.00 MiB] /dev/sda [ 200.00 GiB] /dev/ram1 [ 64.00 MiB] . . . /dev/ram15 [ 64.00 MiB] /dev/sdb [ 100.00 GiB] 2 disks 17 partitions 0 LVM physical volume whole disks 0 LVM physical volumes بتجاهل أجهزة /dev/ram* (التي تُعتبر جزءا من قرص الذاكرة العشوائيّة في لينكس)، يُمكننا مُلاحظة الأجهزة التي يُمكن استخدامها لتشكيل وحدات تخزين ماديّة لـLVM. ستكون هذه الخطوة في الغالب أول خطوة لتحديد أجهزة تخزين لاستعمالها مع LVM. عرض معلومات عن وحدات التّخزين الماديّة تُكتَب ترويسة Header على أجهزة التّخزين لتعليمها على أنها مكوّنات يُمكن لـLVM استخدامها. الأجهزة التي تحمل ترويسة تُسمّى بوحدات التّخزين الماديّة Physical Volumes. يُمكنك عرض جميع أجهزة التّخزين الماديّة على جهازك عبر استخدام الأمر lvmdiskscan مع خيار -l، ما سيُرجع وحدات التّخزين الماديّة فقط في نتيجة تنفيذ الأمر: sudo lvmdiskscan -l المُخرج: WARNING: only considering LVM devices /dev/sda [ 200.00 GiB] LVM physical volume /dev/sdb [ 100.00 GiB] LVM physical volume 2 LVM physical volume whole disks 0 LVM physical volumes الأمر pvscan مُشابه لما سبق، إذ يبحث عن جميع وحدات التّخزين الماديّة الخاصّة بـLVM. إلّا أنّ تنسيق المُخرج مُختلف نوعا ما، إذ يعرض معلومات إضافيّة: sudo pvscan المُخرج: PV /dev/sda VG LVMVolGroup lvm2 [200.00 GiB / 0 free] PV /dev/sdb VG LVMVolGroup lvm2 [100.00 GiB / 10.00 GiB free] Total: 2 [299.99 GiB] / in use: 2 [299.99 GiB] / in no VG: 0 [0 ] إن كنت ترغب بالحصول على المزيد من المعلومات، فاستعمال الأمرين pvs وpvdisplay خيار أفضل. يتميّز الأمر pvs بقابليّة تخصيصه وإمكانيّة استخدامه لعرض المعلومات في عدّة أشكال وتنسيقات مُختلفة. ولأنّ مُخرجات الأمر قابلة للتّخصيص، فاستخدامه شائع في السكريبتات أو عند الحاجة إلى أتمتة الأمور Automation. تُوفّر المُخرجات الأساسيّة للأمر خلاصة مُفيدة مُشابهة لما سبق: sudo pvs المُخرج: PV VG Fmt Attr PSize PFree /dev/sda LVMVolGroup lvm2 a-- 200.00g 0 /dev/sdb LVMVolGroup lvm2 a-- 100.00g 10.00g لمعلومات أكثر إسهابا وقابليّة للقراءة، فالأمر pvdisplay عادة ما يكون خيارا أفضل: sudo pvdisplay المُخرج: --- Physical volume --- PV Name /dev/sda VG Name LVMVolGroup PV Size 200.00 GiB / not usable 4.00 MiB Allocatable yes (but full) PE Size 4.00 MiB Total PE 51199 Free PE 0 Allocated PE 51199 PV UUID kRUOyU-0ib4-ujPh-kAJP-eeQv-ztRL-4EkaDQ --- Physical volume --- PV Name /dev/sdb VG Name LVMVolGroup PV Size 100.00 GiB / not usable 4.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 25599 Free PE 2560 Allocated PE 23039 PV UUID udcuRJ-jCDC-26nD-ro9u-QQNd-D6VL-GEIlD7 كما ترى، فالأمر pvdisplay أسهل أمر للحصول على معلومات مُفصّلة عن وحدات التّخزين الماديّة. لاستكشاف المدااءات المنطقيّة المُرتبطة بكلّ وحدة تخزين، مرّر الخيار -m إلى الأمر pvdisplay: sudo pvdisplay -m المُخرج: --- Physical volume --- PV Name /dev/sda VG Name LVMVolGroup PV Size 200.00 GiB / not usable 4.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 51199 Free PE 38395 Allocated PE 12804 PV UUID kRUOyU-0ib4-ujPh-kAJP-eeQv-ztRL-4EkaDQ --- Physical Segments --- Physical extent 0 to 0: Logical volume /dev/LVMVolGroup/db_rmeta_0 Logical extents 0 to 0 Physical extent 1 to 5120: Logical volume /dev/LVMVolGroup/db_rimage_0 Logical extents 0 to 5119 . . . يُمكن لهذا الأمر أن يكون مُفيدا لك عند الرّغبة في تحديد أي بيانات تتواجد في أي من الأقراص الماديّة لأغراض إداريّة. عرض معلومات عن مجموعات التّخزين Volume Groups يحتوي LVM على العديد من الأدوات التّي يُمكن بها عرض معلومات حول مجموعات التّخزين. يُستعملُ الأمر vgscan لفحص النّظام عن مجموعات التّخزين المتوفّرة. بالإضافة إلى إعادة بناء ملفّ التّخبئة Cache عند الحاجة. ويُعدّ أمرا جيّدا للاستخدام عند استيراد مجموعة تخزين إلى نظام جديد: sudo vgscan المُخرج: Reading all physical volumes. This may take a while... Found volume group "LVMVolGroup" using metadata type lvm2 المُخرج لا يُعطي الكثير من المعلومات، لكن يجب عليه أن يكون قادرا على إيجاد جميع مجموعات التّخزين على النّظام. لعرض المزيد من المعلومات، فالأمران vgs و vgdisplay مُتوفّران لذلك. تماما مثل مثيله المُخصّص لوحدات التّخزين الماديّة، فالأمر vgs مُتعدّد الاستعمالات ويُمكن له أن يعرض كميّة ضخمة من المعلومات في أشكال مُتعدّدة. ولأنّ إمكانيّة تخصيص مُخرجات الأمر عاليّة المرونة، فاستخدامه في برمجة السكريبتات والأتمتة أمر شائع. على سبيل المثال، من الأمور المُفيدة التي يُمكنك فعلها هي تخصيص المُخرج ليعرض فقط الأجهزة الماديّة ومسار وحدات التّخزين المنطقيّة: sudo vgs -o +devices,lv_path المُخرج: VG #PV #LV #SN Attr VSize VFree Devices Path LVMVolGroup 2 4 0 wz--n- 299.99g 10.00g /dev/sda(0) /dev/LVMVolGroup/projects LVMVolGroup 2 4 0 wz--n- 299.99g 10.00g /dev/sda(2560) /dev/LVMVolGroup/www LVMVolGroup 2 4 0 wz--n- 299.99g 10.00g /dev/sda(3840) /dev/LVMVolGroup/db LVMVolGroup 2 4 0 wz--n- 299.99g 10.00g /dev/sda(8960) /dev/LVMVolGroup/workspace LVMVolGroup 2 4 0 wz--n- 299.99g 10.00g /dev/sdb(0) /dev/LVMVolGroup/workspace لمُخرج أكثر إسهابا وقابليّة للقراءة، فالأمر vgdisplay عادة ما يكون خيارا أفضل. إضافة الخيار -v يُوفّر كذلك معلومات حول وحدات التّخزين الماديّة التّي تُشكّل مجموعة التّخزين، بالإضافة إلى وحدات التّخزين المنطقيّة التي تمّ إنشاءها باستخدام مجموعة التّخزين: sudo vgdisplay -v المُخرج: Using volume group(s) on command line. --- Volume group --- VG Name LVMVolGroup . . . --- Logical volume --- LV Path /dev/LVMVolGroup/projects . . . --- Logical volume --- LV Path /dev/LVMVolGroup/www . . . --- Logical volume --- LV Path /dev/LVMVolGroup/db . . . --- Logical volume --- LV Path /dev/LVMVolGroup/workspace . . . --- Physical volumes --- PV Name /dev/sda . . . PV Name /dev/sdb . . . الأمر vgdisplay مُفيد لقُدرته على الرّبط بين المعلومات حول مُختلف عناصر كومة LVM. عرض معلومات حول وحدات التّخزين المنطقيّة يمتلك LVM مجموعة من الأدوات لعرض معلومات عن وحدات التّخزين المنطقيّة كذلك. كما الحال مع مُكوّنات LVM الأخرى، يُمكن استعمال الأمر lvscan لفحص النّظام وعرض معلومات وجيزة حول وحدات التّخزين المنطقيّة التي يجدها: sudo lvscan المُخرج: ACTIVE '/dev/LVMVolGroup/projects' [10.00 GiB] inherit ACTIVE '/dev/LVMVolGroup/www' [5.00 GiB] inherit ACTIVE '/dev/LVMVolGroup/db' [20.00 GiB] inherit ACTIVE '/dev/LVMVolGroup/workspace' [254.99 GiB] inherit لمعلومات أكثر كمالا، يُمكنك استخدام الأمر lvs الذي يتمتّع بمرونة وقوّة بالإضافة إلى سهولة استخدامه في السكربتات: sudo lvs المُخرج: LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert db LVMVolGroup -wi-ao---- 20.00g projects LVMVolGroup -wi-ao---- 10.00g workspace LVMVolGroup -wi-ao---- 254.99g www LVMVolGroup -wi-ao---- 5.00g لإيجاد عدد شرائط Stripes وحدة التّخزين المنطقيّة ونوعها، استعمل الخيار --segments: sudo lvs --segments المُخرج: LV VG Attr #Str Type SSize db LVMVolGroup rwi-a-r--- 2 raid1 20.00g mirrored_vol LVMVolGroup rwi-a-r--- 3 raid1 10.00g test LVMVolGroup rwi-a-r--- 3 raid5 10.00g test2 LVMVolGroup -wi-a----- 2 striped 10.00g test3 LVMVolGroup rwi-a-r--- 2 raid1 10.00g يُمكن الحصول على أكثر مُخرج قابل للقراءة عبر الأمر lvdisplay. عند إضافة الخيار -m، فستعرض الأداة معلومات حول مكوّنات وحدة التّخزين المنطقيّة وكيفيّة توزيعها: sudo lvdisplay -m المُخرج: --- Logical volume --- LV Path /dev/LVMVolGroup/projects LV Name projects VG Name LVMVolGroup LV UUID IN4GZm-ePJU-zAAn-DRO3-1f2w-qSN8-ahisNK LV Write Access read/write LV Creation host, time lvmtest, 2016-09-09 21:00:03 +0000 LV Status available # open 1 LV Size 10.00 GiB Current LE 2560 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 252:0 --- Segments --- Logical extents 0 to 2559: Type linear Physical volume /dev/sda Physical extents 0 to 2559 . . . كما تُلاحظ من الجزء السّفلي للمُخرج أعلاه، فوحدة التّخزين المنطقيّة /dev/LVMVolGroup/projects متواجدة بالكامل على وحدة التّخزين الماديّة /dev/sda في هذا المثال. هذه المعلومة مُفيدة إن كنت ترغب بإزالة جهاز التّخزين المُعتمد عليه وتريد نقل البيانات إلى مكان مُحدّد. رأينا في هذا الجزء من الدليل كيفية عرض معلومات عن مختلف المكوّنات في LVM. سنكمل في الأجزاء التالية بقيّة المهام الإدارية. ترجمة – بتصرّف - للمقال How To Use LVM To Manage Storage Devices on Ubuntu 16.04 لكاتبه Justin Ellingwood.
  9. يتناول هذا المقال تثبيت بيئة تطوير Ruby on Rails على الإصدار 16.04 من أوبونتو. في أغلب الأحوال ستُنفَّذ الشفرة البرمجيّة التي تكتبها على خادوم لينكس، وأوبونتو هي إحدى توزيعات لينكس الأسهل استخداما وتوجد الكثير من الموارد عنها على الشبكة. تثبيت Ruby أول ما يجب علينا فعله هو تثبيت الاعتماديات Dependencies التي يحتاجها Ruby للعمل. نبدأ أولا بتحديث فهرس الحزم ثم تثبيت الاعتماديّات: sudo apt update sudo apt install git-core curl zlib1g-dev build-essential libssl-dev libreadline-dev libyaml-dev libsqlite3-dev sqlite3 libxml2-dev libxslt1-dev libcurl4-openssl-dev python-software-properties libffi-dev nodejs الخطوة الموالية هي تثبيت Ruby. توجد طرق عدّة للتثبيت، سنستخدم rbenv وهي أداة خفيفة وسريعة لإدارة إصدارات Ruby. نبدأ بتثبيت rbenv : cd git clone https://github.com/rbenv/rbenv.git ~/.rbenv echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc echo 'eval "$(rbenv init -)"' >> ~/.bashrc exec $SHELL الأداة rbenv جاهزة الآن. سنثبّت ruby-build وهي إضافة تعمل مع الأداة rbenv وتتيح تثبيت إصدارات عدّة من Ruby في مجلّدات مختلفة على نفس النظام. git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build echo 'export PATH="$HOME/.rbenv/plugins/ruby-build/bin:$PATH"' >> ~/.bashrc exec $SHELL ثم نثبّت الإصدار 2.4.0 من Ruby: TMPDIR=~/tmp/ rbenv install 2.4.0 rbenv global 2.4.0 يُثبّت الأمر الأول الإصدار المطلوب ضمن مجلّد العمل حيث نُفِّذ الأمر؛ في ما يضبط الأمر الثاني إصدار Ruby المبدئي، أي الإصدار الذي سيُستخدَم عند عدم تحديد إصدار. للتأكد من تثبيت Ruby والإصدار المثبّت ننفذ الأمر: ruby -v الذي يُظهر نتيجة تشبه التالي: ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux] الخطوة الأخيرة هي تثبيت Bundler الذي يوفّر بيئة تطوير متجانسة لـ Ruby عبر تتبّع الاعتماديات وتثبيت الإصدارات المطلوبة منها بالضبط: gem install bundler وتنفيذ الأمر لأخذ التثبيت الجديد في الحسبان: rbenv rehash تثبيت Rails يتضمّن إطار العمل Rails الكثير من الاعتماديات، لذا سنحتاج لبيئة تنفيذ JavaScript مثل NodeJS التي ستمكّننا من استخدام مكتبات تتيح إمكانيّة جمع وضغط ملفات جافاسكريبت من أجل الحصول على بيئة تطوير أسرع. نثبّت NodeJS من المستودع الرسمي على النحو التالي: curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash - sudo apt install -y nodejs ثم نثبّت Rails: gem install rails -v 5.0.1 ثم ننفذ الأمر التالي ليمكننا استخدام Rails: rbenv rehash Rails مثبّت الآن، يمكننا التأكّد من ذلك بتنفيذ الأمر التالي الذي يُظهر رقم الإصدار المثبت: rails -v إعداد قاعدة بيانات MySQL يأتي Rails مبدئيا بقاعدة بيانات sqlite3؛ إلا أن هذا النوع من قواعد البيانات لا يناسب تطبيقات كثيرة. يمكن في هذه الحالة إعداد Rails للعمل مع قاعدة بيانات MySQL (أو PostgreSQL). نثبّت خادوم وعميل MySQL من المستودعات الرسمية لأوبونتو: sudo apt install mysql-server mysql-client libmysqlclient-dev سيُطلَب منك خلال التثبيت إنشاءُ كلمة سر خاصة بالحساب الإداري root (انتبِه إلى أنّه حساب خاص بنظام MySQL لإدارة قواعد البيانات، وليس لنظام التشغيل أوبونتو). تتضمّن الحزمة libmysqlclient-dev الملفات الضرورية لتثبيت الاعتماديّات التي يحتاجها Rails للاتصال بقاعدة بيانات MySQL. ننفّذ بعد تثبيت MySQL الأمريْن التاليّيْن لتحضير قاعدة البيانات لبيئة الإنتاج (يمكنك تجاوز هذه الخطوة إن كنت تثبّت Rails على حاسوب شخصي): sudo mysql_install_db sudo mysql_secure_installation سيُطلب منك النّظام إدخال كلمة سرّ الحساب الجذر في MySQL؛ ثمّ يسألك ما إذا كنتَ تُريد تغييرها. أدخل حرف n (دلالةً على “no” أي “لا”) إن لم تكن ترغبُ في ذلك. بالنسبة لبقية الأسئلة يمكنك قبول القيم المبدئية بالنقر على زرّ Enter. أول تطبيق Rails حان الوقت الآن لتشغيل أول تطبيق Ruby on Rails. ننشئ تطبيقا باسم myapp يستخدم قاعدة البيانات MySQL: rails new myapp -d mysql انتظر اكتمال إنشاء التطبيق الذي قد يستغرق وقتا، ثم انتقل إلى مجلد التطبيق: cd myapp عدّل الملف config/database.yml بإضافة كلمة سر الحساب الإداري لقاعدة البيانات (أعددناها أثناء تثبيت MySQL، يمكنك تركها فارغة إن لم تكن أعددتَ كلمة سر لـ MySQL): default: &default adapter: mysql2 encoding: utf8 pool: 5 username: root password: socket: /var/run/mysqld/mysqld.sock اكتب كلمة السر أمام التعليمة password ضمن المقطع السابق الموجود أعلى الملف بعد التعليقات الأولى (تبدأ التعليقات بالعلامة #)؛ ثم نفّذ الأمر التالي لإنشاء قاعدة البيانات التي سيعمل عليها التطبيق: rake db:create النتيجة: Created database 'myapp_development' Created database 'myapp_test' إن واجهك خطأ Access denied for user 'root'@'localhost' (using password: NO) فهذا يعني أنك لم تكتب كلمة السر بطريقة صحيحة. نشغل خادوم التطوير: rails server يمكنك بعد تشغيل خادوم التطوير إدخال العنوان http://localhost:3000/ في المتصفح لمعاينة صفحة التطبيق المبدئي في Rails. إعداد Git هذه الخطوة اختيارية ولكنه تفيدك إن كنت تخطّط لاستعمال Git لإدارة إصدارات المشروع وربطه بحسابك على Github. أبدل YOUR NAME وYOUR@EMAIL.com في الأوامر أدناه على التوالي باسمك والبريد الذي استخدمته للتسجيل على Github. git config --global color.ui true git config --global user.name "YOUR NAME" git config --global user.email "YOUR@EMAIL.com" ssh-keygen -t rsa -b 4096 -C "YOUR@EMAIL.com" يُولّد الأمر الأخير في الأوامر أعلاه زوج مفاتيح SSH سنستخدمها في ما بعد للاتصال بحسابنا على Github. يضع الأمر ssh-keygen مبدئيا زوج المفاتيح على المسار ssh./~. نأخذ المفتاح العمومي الذي يوجد بملف المفتاح ذي الامتداد pub، ويُسمّى مبدئيا id_rsa.pub وننسخه ضمن مفاتيح SSH على حسابنا في Github الموجودة هنا. انقر على الزّر New SSH Key، أعط للمفتاح اسما تختاره ثم ألصق في الحقل الثاني محتوى الملف ssh/id_rsa.pub/~ الذي يمكن الحصول عليه بالأمر التالي، ثم انقر على زرّ Add SSH Key لاعتماد المفتاح: cat ~/.ssh/id_rsa.pub يمكنك التأكد من نجاح العملية بتنفيذ الأمر التالي: ssh -T git@github.com يجب أن تظهر لك رسالة تشبه التالي (يُذكَر فيها اسم حسابك على Github): Hi Zeine77! You've successfully authenticated, but GitHub does not provide shell access. ترجمة - بتصرّف - للمقال Setup Ruby On Rails on Ubuntu 16.04 Xenial Xerus.
  10. توجد بعض الإعدادات التي يجب إجراؤها في البداية كجزء من عملية التثبيت الأولية عند إنشاء خادوم جديد. تؤدي هذه الخطوات إلى تعزيز أمان وقابلية استخدام Usability خادومك ممّا يعطيك أساسًا صلبا للإجراءات اللاحقة. الخطوة الأولى - الولوج Login إلى الحساب الجذر Root يتوجّب عليك، للولوج إلى خادومك، معرفة عنوان IP العمومي Public IP Address إضافةً إلى كلمة سر حساب المستخدم الجذر. إن لم تكن قمتَ بالولوج إلى خادومك من قبل فبإمكانك الاطّلاع على الدرس أساسيات وخيارات الاتصال بخادوم عن بعد باستخدام SSH (البرنامج المسؤول عن الاتصال بالخادوم عن بعد)، الذي يُغطي هذه العملية بالتفصيل. ابدأ بالاتصال بخادومك عن طريق الأمر التّالي (أبدِل الكلمة البارزة بعنوان IP خادومك العمومي): ssh root@SERVER_IP_ADDRESS أكمِل عملية الولوج بقبول التحذيرات حول موثوقية المستضيف Host authenticity في حال ظهورها، وإعطاء معلومات التحقق (كلمة السّر أو المفتاح السري). سيُطلب منك تبديل كلمة سر حساب المستخدِم الجذر إن كانت هذه أول مرة تلِج إلى الخادوم باستخدام كلمة السر. حول المستخدم الجذر المستخدم الجذر هو المُدير في أنظمة لينوكس، ولديه امتيازات Privileges واسعة جدًًا. عمليًا، يُنصَح بعدم استخدام الحساب الجذر في الأمور الاعتيادية، فالصلاحيات الواسعة التي يتمتع بها تُتيح إحداث تغييرات - قد تكون مدمِّرة - في النظام . وليسَ نادرا أن يحدث ذلك بشكل غير مقصود. الخطوة الموالية ستكون إنشاء حساب مستخدم بديل بمجال تأثير محدود للقيام بالعمل اليومي. ستتعلّم أيضًا كيفية الحصول على امتيازات أكبر عندما تحتاج إليها. الخطوة الثانية - إنشاء مستخدم جديد بعد الولوج باستخدام الحساب الجذر تُصبِح على استعداد لإضافة الحساب الجديد الذي سنلِج باستخدامه من الآن فصاعدا. يُنشئ المثال التالي مستخدما باسم "demo"، أبدِلهُ باسم المستخدم الذي تراه مناسِبا: adduser demo ستُطرَح عليك بعض الأسئلة، بدءًا بكلمة سرالحساب. أدخِل كلمة سر قوية. يُمكنك تعبئة بقية المعلومات الإضافية حسب رغبتك. اضغط على زر Enter في لوحة المفاتيح لتجاوز أي حقل لا تودّ تعبئته. الخطوة الثالثة - امتيازات الجذر لدينا الآن حساب مستخدم جديد بامتيازات حساب عادي. سنحتاج في بعض الأحيان إلى القيام ببعض الأعمال الإدارية التي تتطلّب امتيازات الجذر. نستطيع إعداد "مستخدم أعلى" Super user لتجنب الخروج من الحساب العادي والولوج بالحساب الجذر أثناء القيام بالمهام الإدارية. المستخدم الأعلى هو مستخدم عادي ولكنه يستطيع الحصول على امتيازات المستخدم الجذر مؤقتا عن طريق كتابة sudo أمام الأوامر التي يطلب تنفيذها. يتوجّب علينا إضافة المستخدم الجديد إلى مجموعة المستخدمين Users group sudo حتى يتسنى له الحصول على الامتيازات الإدارية. يُسمَح - في الإعداد الافتراضي لأوبنتو 14.04 - للمستخدمين الأعضاء في مجموعة sudo باستخدام أمر sudo. نفّذ باستخدام الحساب الجذر، الأمر التالي لإضافة المستخدم الجديد إلى المجموعة sudo (أبدِل الكلمة البارزة بالاسم الذي اخترتَه للمستخدم الجديد): gpasswd -a demo sudo يُمكِن للمستخدِم الجديد الآن تنفيذ أوامر بامتيازات المستخدِم الأعلى. الخطوة الرابعة - إضافة الاستيثاق عن طريق المفتاح العمومي Public Key Authentication (يوصى بهذه الخطوة) الخطوة التالية في تأمين خادومك هي إعداد مفتاح عمومي Public Key للمستخدم الجديد. هذا الإعداد سيرفع من أمان خادومك بطلب مفتاح SSH سري للولوج. توليد زوج من المفاتيح سيتوجّب عليك توليد زوج مفاتيح (مفتاح عمومي وآخر سرّي). إن كان لديك مفتاح عمومي ترغب في استخدامه تجاوز إلى خطوة نسخ المفتاح العمومي. لتوليد زوج مفاتيح جديدة نفِّذ الأمر التالي على الطّرفيةTerminal محليًّا (على حاسوبك الشخصي): ssh-keygen ستظهر لك مُخرجات شبيهة بما يلي (localuser هنا هو اسم المستخدم الذي يُنفِّذ الأمر): Generating public/private rsa key pair. Enter file in which to save the key (/Users/localuser/.ssh/id_rsa): اضغط زر Enter على لوحة المفاتيح لقبول اسم ومسار حفظ الملف، أو أدخل مسارا لملف جديد. سيُطلب منك بعدها إدخال عبارة سر Passphrase لتأمين المفتاح. عبارة السّر اختيارية ويُمكنك تجاوزها وتركها خاوية. ملحوظة: عند ترك عبارة السر خاوية يُمكن استخدام المفتاح السري للاستيثاق دون الحاجة لإدخال عبارة سر، أما في حال إنشاء عبارة سر فستحتاج للإثنين (عبارة السر والمفتاح السري) للولوج. إنشاء عبارة سر يُعطي أمانا أكبر ولكن لكل من الطريقتين (المفتاح السري وحده أو مع عبارة سر) استخداماتُها، كما أنهما أكثر أمانا من الاستيثاق الأساسي عن طريق كلمة سر. حصلنا الآن على مفتاح سري (id_rsa)، وآخر عمومي (id_rsa.pub) يوجدان في المجلَّد ssh. الموجود في المجلّد الشخصي للمستخدم localuser. تذكَّر أنه لا يجوز على الإطلاق مُشاركة المفتاح السري مع أي شخص لا يحق له الاتصال بخواديمك. نسخ المفتاح العمومي بعد توليد المفتاح العمومي محليًّا ننقلهُ إلى الخادوم. استخدم الأمر التالي لإظهار مفتاحك العمومي (أبدِل مسار الملف في حال غيّرت مسار الحفظ أثناء توليد المفتاح) cat ~/.ssh/id_rsa.pub سيظهر مفتاحك العمومي الذي يُشبه شكلُه التالي: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBGTO0tsVejssuaYR5R3Y/i73SppJAhme1dH7W2c47d4gOqB4izP0+fRLfvbz/tnXFz4iOP/H6eCV05hqUhF+KYRxt9Y8tVMrpDZR2l75o6+xSbUOMu6xN+uVF0T9XzKcxmzTmnV7Na5up3QM3DoSRYX/EP3utr2+zAqpJIfKPLdA74w7g56oYWI9blpnpzxkEd3edVJOivUkpZ4JoenWManvIaSdMTJXMy3MtlQhva+j9CgguyVbUkdzK9KKEuah+pFZvaugtebsU+bllPTB0nlXGIJk98Ie9ZtxuY3nCKneB+KjKiXrAvXUPCI9mWkYS/1rggpFmu3HbXBnWSUdf localuser@machine.local حدّد المفتاح العمومي وانسخه إلى الحافِظة Clipboard. إضافة المفتاح العمومي إلى المستخدم الجديد على الخادوم يجب إضافة مفتاح SSH إلى ملف خاص يوجد بالمجلد الشخصي للمستخدِم على الخادوم حتى يتسنى له استعمالُه للاستيثاق. استعمل الأمر التالي - على الخادوم - للانتقال من المستخدِم الجذر إلى المستخدِم الذي أنشأناه في الخطوات الأولى من هذا الدّليل (أبدِل demo باسم المستخدِم الذي اخترتَه): su - demo ستُنقَل بعدَ الولوج إلى الخادوم إلى ملف المستخدم الشخصي. أنشئ مجلَّدا فرعيا جديدا في المجلّد الشخصي باسم ssh. (النقطة جزء من الاسم) مع تقييد الأذون Permissions عن طريق الأوامر التالية: mkdir .ssh chmod 700 .ssh سنُنشئ الآن ملفًا باسم authorized_keys مع فتحه عن طريق محرِّر نصوص. سنستخدِم محرِّر Nano للتعديل على الملف، كما في الأمر التالي: nano .ssh/authorized_keys ثم نأتي لإدراج المفتاح العمومي في الملف عن طريق لصقه في المحرِّر. اضغط على الزريْن CTRL و X معًا في لوحة المفاتيح للخروج من المحرِّر ثم زر Y لحفظ التغييرات وEnter لتأكيد اسم الملف. نُقيّد الأذون على الملف authorized_keys عن طريق الأمر: chmod 600 .ssh/authorized_keys للعودة إلى المستخدِم الجذر ننفِّذ الأمر التالي: exit بإمكانك الآن الولوج إلى حساب المستخدم الجديد عن طريق SSH باستخدام المفتاح السري. الخطوة الخامسة - إعداد SSH يُمكننا، بعد أن أنشأنا حسابَ مستخدم جديدًا، زيادة تأمين الخادوم عن طريق تغيير إعداد SSH . نبدأ بفتح ملف الإعدادات بواسطة محرِّر نصوص مع استعمال المستخدِم الجذر: nano /etc/ssh/sshd_config تغيير منفذ Port الاتصال عن طريق SSH (اختياري) أولى التغييرات ستكون تعديل المنفذ الذي يستخدمه SSH للاتصال بالخادوم. ابحث عن السّطر التالي: Port 22 عند تغيير هذا الرقم إلى آخر بين 1025 و 65536 فإن خدمة SSH ستستخدم المنفذ الجديد للاتصال بالخادوم بدلا من المنفذ الافتراضي (22). يُحاول بعض المستخدمين غير المسموح لهم بالولوج استعمال منفذ SSH الافتراضي الوصول إلى الخادوم. تغيير المنفذ يعني إضافة خطوات جديدة أمام هذا النوع من المستخدمين لأنه يضطرهم إلى تجربة منافذ عديدة لمعرفة أيها يُستخدم من طرف SSH. يجب عند تغيير منفذ SSH تذكر رقم المنفذ الجديد حتى يُمكن الاتصال عن بعد بالخادوم. سنُغيِّر منفذ SSH إلى 4444. يعني هذا أنه يتوجب إخبار الخادوم عند الاتصال برقم المنفذ المُستخدَم لكي لا يستخدم المنفذ الافتراضي، وهو ما سنشرحه لاحقا. Port 4444 تقييد ولوج المستخدم الجذر عبر SSH بعد تغيير منفذ SSH نبحث عن السّطر التالي: PermitRootLogin yes يُتيح هذا السطر إمكانية السماح للمستخدم الجذر أو منعه من الولوج عن طريق SSH. يُعتبَر هذا الإجراء أكثر أمانا حيثُ يمكن الولوج بالمستخدم العادي عن طريق SSH ثم استخدام صلاحيات المستخدم الجذر عن الحاجة. نُغيّر السطر بإبدال yes ب no لمنع المستخدم الجذر من الولوج عن بعد. PermitRootLogin no يُنصَح دائما، من أجل أمان أكبر، بتقييد ولوج المستخدم الجذر عبر SSH. بعد إنهاء التعديلات احفَظ الملف وأغلقه باستخدام الطريقة التي رأيناها سابقا (CTRL+X، ثم Y و ENTER بعد ذلك). الخطوة السادسة - إعادة تحميل SSH انتهينا الآن من تحرير الإعدادات. لأخذها في الاعتبار نُعيد تشغيل خدمة SSH عن طريق الأمر التالي: service ssh restart يجب أن نتأكد من أن الإعداد الجديد يعمل بشكل جيّد قبل الخروج، حتى لا نجد أنفسَنا في وضعية لا يُمكن فيها الولوج عن بعد إلى الخادوم. افتح نافذة جديدة لواجهة الأوامر على حاسوبك الشخصي. سنجري في النافذة الجديدة اتصالا مع الخادوم باستعمال حساب المستخدم العادي الذي أنشأناه بدلا من المستخدِم الجذر. يجب ذكر رقم منفذ الولوج إلى خادوم لا يستخدم المنفذ الافترضي للاتصال عن طريق SSH وذلك بإضافة العبارة "p 4444-" إلى أمر الاتصال حيثُ 4444 هو رقم المنفذ الجديد. للولوج إلى الخادوم عن طريق المنفَذ الذي أعددناه في الخطوة السابقة نستخدم الأمر التالي (أبدِل SERVER_IP_ADDRESS بعنوان خادومك و demo باسم المستخدِم): ssh -p 4444 demo@SERVER_IP_ADDRESS ملحوظة: لا تنسَ، إن كنت تستخدم برنامج PuTTY، تغيير إعداد المنفَذ في البرنامج حتى يتوافق مع الإعداد الحالي لخادومك. سيُطلب منك إدخال كلمة سر المستخدم الجديد ثم، بعد التحقق، ستلِج إلى المجلد الشخصي للمستخدم على الخادوم. تذكّر إضافة sudo أمام الأوامر التي ترغي في تنفيذها بصلاحيات المستخدِم الجذر: sudo command_to_run حيثُ command_to_run هو الأمر المُراد تنفيذه. إذا جرت الخطوات السّابقة كما وصفناها فإن كل شيء على ما يُرام ويُمكنك الخروج عن طريق الأمر exit ماذا بعد هذا الدرس؟ بالوصول إلى هذه النقطة فإن لدى خادومك أساسا قويا، ويُمكنك تثبيت أي برنامج ترغب فيه عليه. يُمكنك المُتابعة مع هذه السلسة بقراءة مقال خطوات إضافية موصى بها لخواديم أوبنتو 14.04 الجديدة الذي يشرح أمورا من قبيل تفعيل fail2ban للحد من فعاليّة هجمات القوة العمياء Brute force attacks، الإعدادات الأساسية للجدار الناري Firewall، بروتكول NTP وملفات الإبدال Swap. كما أنّ به روابطَ لشروح حول كيفية تثبيت وإعداد بعض تطبيقات الويب الشائعة. مقالات مثل إعداد حِزم LAMP أو LEMP جيّدة لمن يُريد استكشاف المزيد. ترجمة -وبتصرّف- للمقال: Initial Server Setup with Ubuntu 14.04 لصاحبه Justin Ellingwood.
  11. تمهيد كلما كانت صفحات الموقع أسرع تحميلًا كلما ازداد احتمال بقاء الزائر متصفحًا للموقع، وعندما تمتلئ صفحات مواقع الويب بالصور والمحتوى التفاعلي الظاهر عبر سكربتات تُحمَّل في الخلفية، فلن تكون عملية فتح «صفحة» ويب أمرًا هينًا، إذ تتضمن طلب ملفاتٍ عدِّة من خادوم الويب ملفًا ملفًا، وعملية تقليل تلك الطلبيات هي إحدى سُبُل تسريع موقعك. يمكن فعل ذلك بطرائق عدِّة، لكن إحدى أهم الخطوات التي يجب إجراؤها هي ضبط التخزين المؤقت في المتصفح (browser caching)؛ وهذا يعني إخبار المتصفح بإمكانية استخدام نسخ محلية من الملفات التي حُمِّلَت في إحدى المرات بدلًا من طلبها من الخادوم مرارًا وتكرارًا؛ ولفعل ذلك يجب إضافة ترويسات لرد HTTP ‏(HTTP response headers) تخبر المتصفح بما عليك فعله. هذا هو دور وحدة header (‏header module) في خادوم Nginx، التي يمكن استعمالها لإضافة الترويسات إلى رد HTTP، لكن دورها الأساسي يمكن في ضبط الترويسات المسؤولة عن التخزين المؤقت. سننظر في هذا الدرس إلى كيفية استخدام وحدة header لتطبيق الفكرة السابقة. المتطلبات المسبقة ستحتاج قبل إكمال قراءة هذا الدرس إلى ما يلي: خادوم أوبنتو 16.04 (أو 14.04) مضبوطٌ كما في درس «الإعداد الابتدائي لخادوم أوبنتو 14.04»، بما في ذلك إعداد حساب مستخدم عادي لكنه يملك امتيازات الجذر (root) عبر الأداة sudo. خدمة Nginx مثبّتة على خادومك باتباعك لهذا الدرس «تنصيب، إعداد واستخدام nginx كخادوم ويب». سنحتاج بالإضافة إلى وحدة header إلى وحدة map التابعة لخادوم Nginx؛ لمزيدٍ من المعلومات حول وحدة map، فاقرأ درس كيفية استخدام وحدة map على خادوم أوبنتو 16.04. الخطوة الأولى: إنشاء ملفات للتجربة سنُنشِئ في هذه الخطوة عدِّة ملفات في مجلد Nginx، إذ سنستخدم هذه الملفات لاحقًا للتحقق من سلوك خادوم Nginx الافتراضي لاختبار أنَّ التخزين المؤقت في المتصفح يعمل عملًا صحيحًا. لتقرير ما هو نوع الملفات المُخدَّمة عبر الشبكة، فلن يُحلِّل Nginx محتويات الملف لأن ذلك يستهلك وقتًا كثيرًا؛ وإنما سينظر إلى لاحقة (أو امتداد) الملف لتحديد ما هو نوع MIME التابع له، والذي سيُصرِّح عن الهدف أو الغاية من الملف. ونتيجةً لهذا السلوك، فلن يكون لمحتوى الملفات الاختبارية أيّة أهمية؛ إذ سنستطيع خداع خادوم Nginx بتسمية الملفات تسميةً صحيحةً، فقد يظن خادوم Nginx أنَّ ملفًا فارغًا يُمثِّل صورةً وآخر يُمثِّل سكربت JavaScript. لنُنشِئ ملفًا باسم test.html في مجلد Nginx الافتراضي عبر الأداة truncate (يمكنك استخدام أيّة أداة أو أمر آخر وليكن touch مثلًا). لاحقة الملف تُشير إلى أنَّه مستند HTML: sudo truncate -s 1k /var/www/html/test.html لنُنشِئ المزيد من الملفات الاختبارية بنفس الطريقة السابقة: صورة jpg وملف css وسكربت js: sudo truncate -s 1k /var/www/html/test.jpg sudo truncate -s 1k /var/www/html/test.css sudo truncate -s 1k /var/www/html/test.js الخطوة التالية هي التحقق من سلوك خادوم Nginx فيما يتعلق بإرسال ترويسات للتحكم بالتخزين المؤقت للمتصفح وذلك بتخديم الملفات التي أنشأناها أخيرًا مع الضبط الافتراضي له. الخطوة الثانية: التحقق من السلوك الافتراضي لخادوم Nginx يكون لجميع الملفات نفس سلوك التخزين المؤقت افتراضيًا. ولرؤية ذلك سنستخدم ملف HTML الذي أنشأناه في الخطوة الأولى، إلا أنَّك تستطيع إجراء هذا الاختبار على أيّ ملف من الملفات التي أنشأناها سابقًا. لنتحقق من أنَّ الملف test.html يُخدَّم ومعه المعلومات التي لها علاقة بالمدة الواجب تخزين المتصفح للملف فيها مؤقتًا. سيؤدي الأمر الآتي إلى طلب الملف من خادوم Nginx المحلي ويُظهِر ترويسات رد HTTP: curl -I http://localhost/test.html يجب أن ترى عدِّة ترويسات HTTP: HTTP/1.1 200 OK Server: nginx/1.10.0 (Ubuntu) Date: Sat, 10 Sep 2016 13:12:26 GMT Content-Type: text/html Content-Length: 1024 Last-Modified: Sat, 10 Sep 2016 13:11:33 GMT Connection: keep-alive ETag: "57d40685-400" Accept-Ranges: bytes يمكنك أن تلاحظ السطر قبل الأخير الذي يبدأ بالكلمة ETag الذي يتضمن مُعرِّفًا فريدًا للنسخة الحالية من الملف المطلوب. فإذا حاولت تنفيذ أمر curl السابق أكثر من مرة فستجد نفس قيمة ETag. أما عند استخدام متصفح ويب، فستُخزَّن قيمة ETag ثم تُرسَل إلى الخادوم عبر ترويسة If-None-Match عندما يريد المتصفح أن يطلب نفس الملف مرةً أخرى (عند تحديث الصفحة على سبيل المثال). يمكنك محاكاة ذلك في سطر الأوامر بالأمر الآتي. احرص على تغيير قيمة الترويسة If-None-Match في الأمر لتُطابِق قيمة ETag في ناتج الأمر السابق: curl -I -H 'If-None-Match: "57d40685-400"' http://localhost/test.html ستجد أنَّ الرد أصبح مختلفًا الآن: HTTP/1.1 304 Not Modified Server: nginx/1.10.0 (Ubuntu) Date: Sat, 10 Sep 2016 13:20:31 GMT Last-Modified: Sat, 10 Sep 2016 13:11:33 GMT Connection: keep-alive ETag: "57d40685-400" ردّ خادوم Nginx بحالة «‎304 Not Modified»، ولن يُرسِل الملف عبر الشبكة مجددًا، وإنما يخبر المتصفح أنَّه يستطيع إعادة استخدام الملف المُخزَّن محليًا والذي نزَّله سابقًا. ما سبق مفيدٌ لأنه يُقلِّل من التراسل الشبكي، لكنه ليس مثاليًا لتحقيق أداءٍ عالٍ نتيجةٍ للتخزين المؤقت. المشكلة مع ترويسة ETag أنَّ المتصفح سيرسل الطلبية إلى الخادوم دائمًا ويسأله إن كان بإمكانه استخدام الملف المُخزَّن مؤقتًا، وحتى لو ردّ الخادوم على المتصفح بالإيجاب بحالة 304 بدلًا من إعادة إرسال الملف مجددًا، إلا أنَّ إرسال الطلبية واستلام الرد سيستهلك وقتًا. سنستخدم في الخطوة التالية وحدة headers لإضافة معلومات للتحكم بالتخزين المؤقت. وهذا سيجعل المتصفح يُخزِّن الملفات محليًا دون أخذ إذن الخادوم أولًا. الخطوة الثالثة: ضبط ترويستَي Cache-Control و Expires إضافةً إلى ترويسة التحقق من تغيّر الملف (ETag)، هنالك ترويستان للتحكم بالتخزين المؤقت هما Cache-Control و Expires. ترويسة Cache-Control هي نسخةٌ أحدث، وفيها خياراتٌ أكثر مقارنةً بترويسة Expires وهي أفيد إن شئت التحكم بسلوك التخزين المؤقت تحكمًا دقيقًا. إذا ضُبِطَت تلك الترويسات، فهي تخبر المتصفح أنَّ الملف المطلوب يمكن أن يُخزَّن محليًا لفترةٍ زمنيةٍ معيّنة (تستطيع أن تجعل صلاحيته «للأبد»!) دون طلبه مرةً أخرى. أما إن لم تُضبَط تلك الترويسات، فسيطلب المتصفحُ الملفَ دومًا من الخادوم، متوقعًا أن يحصل على الحالة «‎200 OK» أو «‎304 Not Modified». يمكننا استخدام وحدة header لإرسال ترويسات HTTP آنفة الذكر. وحدة header هي وحدةٌ من أساس خادوم Nginx لذا لن تحتاج إلى تثبيت أيّ شيءٍ لاستخدامها. لإضافة وحدة header، افتح ملف ضبط Nginx في محرر nano أو أيّ محررٍ نصيٍ تشاء: sudo nano /etc/nginx/sites-available/default اعثر على القسم المُعَنوَنَ server، والذي يبدو كما يلي: . . . # Default server configuration # server { listen 80 default_server; listen [::]:80 default_server; . . . أضف القسمَين الآتيين: أولهما قبل قسم server لتعريف المدة الزمنية لتخزين مختلف أنواع الملفات مؤقتًا، وثانيهما داخل كتلة server الذي يضبط ترويسات التخزين المؤقت ضبطًا سليمًا: . . . # Default server configuration # # Expires map map $sent_http_content_type $expires { default off; text/html epoch; text/css max; application/javascript max; ~image/ max; } server { listen 80 default_server; listen [::]:80 default_server; expires $expires; . . . القسم الموجود قبل قسم server هو قسم map الذي يربط بين أنواع الملفات ومدة التخزين المؤقت لهذا النوع من الملفات. استعملنا عدِّة خيارات ضبط فيه: القيمة الافتراضية هي off، والتي لن تُضيف أيّة ترويسات للتحكم بالتخزين المؤقت، وهذا خيارٌ جيدٌ للمحتوى الذي لا يتطلب تخزينًا مؤقتًا. لنوع text/html سنضبط القيمة إلى epoch وهي قيمةٌ خاصةٌ التي تعني عدم التخزين المؤقت نهائيًا، مما يجبر المتصفح على السؤال إن كانت الصفحة مُحدَّثة. لنوع text/css و application/javascript -والتي هي ملفات الأنماط CSS وسكربتات JavaScript- سنضبط القيمة إلى max وهذا يعني أنَّ المتصفح سيُخزِّن هذه الملفات مؤقتًا أطول مدة يستطيعها، مما يُقلِّل عدد الطلبيات لوجود عدد كبير من هذه الملفات التي ترتبط بصفحة HTML. آخر خيار لنوع ‎~image/‎ وهو تعبيرٌ نمطيٌ (regular expression) الذي يُطابِق جميع الملفات ذات النوع الذي يحتوي على العبارة image/‎ فيه (مثل image/jpg و image/png). وكما في ملفات CSS و JS، تتواجد عادةً صورٌ كثير في مواقع الويب، ومن الجيد تخزينها محليًا، لذا ضبطنا القيمة إلى max أيضًا. التعليمة expires داخل قسم server (التي هي جزءٌ من وحدة headers) تضبط ترويسات التحكم بالتخزين المؤقت؛ حيث تستخدم القيمة المأخوذة من المتغير ‎$expires الذي يربط بين أنواع الملفات ومدة صلاحيتها. وبهذه الطريقة ستختلف الترويسات المُرسَلة اعتمادًا على نوع الملف. احفظ الملف واخرج من المُحرِّر النصي، وأعد تشغيل خادوم Nginx لتفعيل الضبط الجديد: sudo systemctl restart nginx سنتحقق في الخطوة التالية من أنَّ الضبط الجديد يعمل عملًا سليمًا. الخطوة الرابعة: اختبار التخزين المؤقت في المتصفح لنُنفِّذ نفس الأمر الذي طلبنا فيه ملف HTML في القسم السابق: curl -I http://localhost/test.html سيكون الرد مختلفًا هذه المرة، إذ يجب أن ترى ترويستين جديدتين: HTTP/1.1 200 OK Server: nginx/1.10.0 (Ubuntu) Date: Sat, 10 Sep 2016 13:48:53 GMT Content-Type: text/html Content-Length: 1024 Last-Modified: Sat, 10 Sep 2016 13:11:33 GMT Connection: keep-alive ETag: "57d40685-400" Expires: Thu, 01 Jan 1970 00:00:01 GMT Cache-Control: no-cache Accept-Ranges: bytes ترويسة Expires مرتبطة بتاريخٍ في الماضي وترويسة Cache-Control مضبوطةٌ إلى no-cache، مما يجعل المتصفح يسأل الخادوم إن توفرت نسخةٌ جديدةٌ من الملف (باستخدام ترويسة ETag كما سبق). ستجد ردًا مختلفًا عندما تُجرِّب على صورة: curl -I http://localhost/test.jpg ناتج الأمر السابق: HTTP/1.1 200 OK Server: nginx/1.10.0 (Ubuntu) Date: Sat, 10 Sep 2016 13:50:41 GMT Content-Type: image/jpeg Content-Length: 1024 Last-Modified: Sat, 10 Sep 2016 13:11:36 GMT Connection: keep-alive ETag: "57d40688-400" Expires: Thu, 31 Dec 2037 23:55:55 GMT Cache-Control: max-age=315360000 Accept-Ranges: bytes ارتبطت الترويسة Expires في هذه المرة بتاريخٍ في المستقبل البعيد، واحتوت ترويسة Cache-Control على max-age التي تخبر المتصفح كم ثانية يجب أن يُبقي على الملف. وهذا يُخبِر المتصفح أن يُخزِّن الصورة المُنزَّلة مؤقتًا لأطول مدة ممكنة، وبالتالي إذا ظهرت الصورة مرةً أخرى فستُستعمَل النسخة المحلية ولن تُرسَل الطلبية إلى الخادوم بتاتًا. يجب أن تكون النتيجة مشابهةً لملفَي test.js و test.css لأنهما ملفا JavaScript و CSS ويُضبَط لهما ترويسات التخزين المؤقت أيضًا، مَثَلُهُما كَمَثل الصور. إن ظهر عندك مثلما عرضنا في أمثلتنا، فاعلم أنَّ ترويسات التحكم بالتخزين المؤقت قد ضُبِطَت ضبطًا صحيحًا وسيستفيد موقعك من ناحية الأداء، وسيقل الحِمل على خادومك نتيجةً لتخزين المتصفح للملفات محليًا وعدم طلبها من الخادوم. عليك الآن أن تُخصِّص إعدادات التخزين المؤقت اعتمادًا على محتوى موقعك، لكن قد تجد أنَّ الضبط الذي وفرناه في هذا الدرس مناسبًا لتبدأ منه. الخلاصة يمكن أن تُستعمَل وحدة headers لإضافة أي نوع من الترويسات إلى رد HTTP، لكن من أفضل تطبيقات هذه الوحدة هو ضبط ترويسات التحكم بالتخزين المؤقت. إذ سيساعد ذلك في تحسين أداء مواقع الويب المُستضافة على خادومك، خصوصًا في الشبكات ذات زمن التأخير المرتفع (نسبيًا) مثل شبكات الهواتف المحمولة. يمكن أن يؤدي ذلك إلى تحسين ظهور موقعك في محركات البحث التي تأخذ عامل سرعة الموقع بالحسبان. حيث يُعتَبَر ضبط ترويسات التخزين المؤقت من أبزر نصائح أدوات اختبار سرعة الصفحات من Google (أقصد Google PageSpeed). لمزيدٍ من المعلومات التفصيلية عن وحدة headers، فارجع إلى توثيق Nginx الرسمي. ترجمة -وبتصرّف- للمقال How to Implement Browser Caching with Nginx’s header Module on Ubuntu 16.04 لصاحبه Mateusz Papiernik.
  12. سنتعلّم في هذا الدّرس كيفيّة استخدام HAProxy (والذي يرمز إلى الوسيط عالي التوفّر High Availability Proxy) كمُوازِن حمل عن طريق الطبقة السّابعة layer 7 load balancer من أجل تخديم تطبيقات متعدّدة من اسم مجال واحد Single Domain أو عنوان IP، بإمكان موازنة الحمل أن تزيد أداء، توفّر، ومرونة بيئتنا. تكون موازنة الحمل والوسيط العكسي للطبقة 7 ملائمة لموقعك إن أردت أن تملك اسم نطاق واحد يقوم بتخديم تطبيقات متعدّدة، حيث يمكن تحليل طلبات http لتقرّر أي تطبيق ينبغي عليه أن يستقبل حركة مرور البيانات. تمّت كتابة هذا الدّرس باستخدام ووردبريس وموقع ثابت Static website كأمثلة، ولكن يمكن استخدام مفاهيمه العامّة مع تطبيقات أخرى للحصول على تأثير مماثل. المتطلبات الأساسية قبل متابعة هذا الدّرس ينبغي عليك أن تملك تطبيقين على الأقل يعملان على خادومين منفصلين، سنستخدم موقعًا ثابتًا مستضافًا على Nginx و ووردبريس كتطبيقين لدينا، وبالإضافة للبيئة الحاليّة لديك سنقوم بإنشاء الخواديم التالية: haproxy-www: وهو خادوم HAProxy لأجل موازنة الحمل والوسيط العكسي wordpress-2: وهو خادوم الويب الثاني لووردبريس (تحتاجه فقط إن أردت موازنة حمل مكونات ووردبريس في بيئتك) web-2: خادوم ويب Nginx الثاني (تحتاجه فقط إن أردت موازنة حمل مكونات Nginx في بيئتك) إن لم يسبق لك التّعامل مع المفاهيم أو المصطلحات الأساسيّة لموازنة الحمل، مثل موازنة الحمل عن طريق الطبقة 7 أو الواجهات الخلفيّة backends أو قوائم تحكّم الوصول ACLs فهذا هو الدّرس الذي يشرح الأساسيّات: مقدّمة إلى HAProxy ومبادئ موازنة الحمل (Load Balancing). هدفنا بنهاية هذا الدّرس نريد أن نحصل على بيئة تبدو كما يلي: أي سيقوم المستخدمون لديك بالنفاذ لكلا تطبيقيك عبر http://example.com، وسيتم تمرير كل الطلبات التي تبدأ بـ http://example.com/wordpress إلى خواديم ووردبريس، ويتم تمرير جميع باقي الطلبات إلى خواديم Nginx الأساسيّة، لاحظ أنّه لا تحتاج بالضرورة لموازنة حمل تطبيقاتك حتى تظهر على مجال واحد، ولكن سنقوم بتغطية موازنة الحمل في هذا الدّرس. تثبيت HAProxy نقوم بإنشاء خادوم جديد مع الشّبكات الخاصّة، سنسمّيه في هذا الدّرس haproxy-www. نقوم بتثبيت HAProxy على الخادوم haproxy-www باستخدام apt-get: sudo apt-get update sudo apt-get install haproxy نحتاج لتمكين سكريبت التهيئة init script لـ HAProxy كي يبدأ ويتوقف HAProxy مع الخادوم لدينا: sudo vi /etc/default/haproxy نغيّر قيمة ENABLED إلى 1 لتمكين سكريبت التهيئة لـ HAProxy: ENABLED=1 نقوم بالحفظ والخروج، سيبدأ ويتوقف HAProxy الآن مع خادومنا، نستطيع أيضًا الآن استخدام الأمر service للتحكّم بـ HAProxy، فلنتحقّق من أنّه قيد التشغيل: user@haproxy-www:/etc/init.d$ sudo service haproxy status haproxy not running. نجد أنّه لا يعمل، لا مشكلة لأنّه يحتاج إلى إعداده قبل أن نتمكّن من استخدامه، فلنقم الآن بإعداد HAProxy لأجل بيئتنا. إعداد HAProxy يكون ملف إعدادات HAProxy مُقسّمًا إلى قسمين رئيسيين: العمومي Global: يقوم بتعيين المُعامِلات parameters على نطاق العمليّة الوسطاء Proxies: يتكون من المُعامِلات الافتراضيّة defaults، الاستماع listen، الواجهة الأماميّة frontend، والواجهة الخلفيّة backend. مرّة أخرى إن لم يسبق لك أن سمعت عن مفاهيم أو المصطلحات الأساسيّة لموازنة الحمل، فقم بالرجوع إلى هذا الدّرس: مقدّمة إلى HAProxy ومبادئ موازنة الحمل (Load Balancing). إعداد HAProxy: العمومي يجب أن يتم ضبط إعدادات HAProxy على الخادوم haproxy-www. في البداية لنقم بعمل نسخة من الملف haproxy.cfg الافتراضي: cd /etc/haproxy; sudo cp haproxy.cfg haproxy.cfg.orig نقوم الآن بفتح الملف haproxy.cfg باستخدام مُحرِّر نصوص: sudo vi /etc/haproxy/haproxy.cfg سنشاهد وجود قسمين معرّفين مسبقًا: global و defaults، سنلقي نظرة في البداية على بعض المعاملات القياسية default. تحت القسم defaults نبحث عن الأسطر التالية: mode http option httplog يقوم اختيار http كوضع بضبط HAProxy ليعمل كموازن حمل عن طريق الطبقة 7 (أو طبقة التطبيقات)، يعني هذا أنّ موازن الحمل سينظر إلى محتوى طلبات http ويقوم بتمريرها إلى الخادوم المناسب اعتمادًا على القواعد المعرّفة في الواجهة الأماميّة frontend، إن لم يكن هذا المفهوم مألوفًا لديك فمن فضلك اقرأ قسم أنواع موازنة الحمل في درس مقدّمة إلى HAProxy. لا تقم بإغلاق ملف الإعدادات الآن، لأنّنا سنضيف إعدادات الوسيط. إعداد HAProxy: الوسطاء إعداد الواجهة الأماميّة أول شيء نريد إضافته هو واجهة أماميّة frontend، ولأجل إعداد أساسي لوسيط عكسي وموازنة حمل عن طريق الطبقة 7 سنحتاج لتعريف قائمة تحكّم وصول ACL تُستخدَم لتوجيه حركة مرور بياناتنا إلى خواديم الواجهة الخلفيّة المناسبة، هنالك العديد من قوائم تحكّم الوصول التي يُمكن استخدامها في HAProxy، سنغطي فقط واحدة منها في هذا الدّرس (وهي path_beg)، ولأجل الحصول على قائمة كاملة من قوائم تحكّم الوصول في HAProxy قم بمراجعة التّوثيق الرسميّ: HAProxy ACLs. نضيف واجهتنا الأماميّة www في نهاية الملف، تأكّد من أن تضع عنوان IP الخاص بخادوم haproxy-www لديك بدلًا من haproxy_www_public_IP: frontend www bind haproxy_www_public_IP:80 option http-server-close acl url_wordpress path_beg /wordpress use_backend wordpress-backend if url_wordpress default_backend web-backend وهذا شرح لما يعنيه كل سطر من المقطع السابق المأخوذ من إعدادات الواجهة الأماميّة: frontend www: يُعيِّن واجهة أماميّة اسمها "www"، حيث سنستخدمها للتعامل مع حركة مرور بيانات www الواردة. bind haproxy_www_public_IP:80: ضع عنوان IP خادوم haproxy-www لديك بدلًا من haproxy_www_public_IP، يُخبر هذا السطر HAProxy أنّ هذه الواجهة الأماميّة ستتعامل مع حركة مرور بيانات الشبكة الواردة إلى عنوان IP هذا على هذا المنفذ. option http-server-close: يقوم بتمكين وضع إغلاق اتصال HTTP على الخادوم، ويحافظ على القدرة على دعم ترويسة HTTP keep-alive وتقنيّة HTTP pipelining على العميل (وهي تقنيّة لإرسال العديد من طلبات HTTP ضمن اتصال TCP وحيد بدون انتظار الموافقة لها)، يسمح هذا الخيار بأن يقوم HAProxy بمعالجة طلبات متعدّدة للعميل ضمن اتصال وحيد، والذي عادة ما يزيد من الأداء. acl url_wordpress path_beg /wordpress: يُعيِّن قائمة تحكّم وصول ACL تُدعى url_wordpress والتي تكون قيمتها صحيحة true إن كان مسار الطلب يبدأ بـ "wordpress/"، على سبيل المثال http://example.com/wordpress/hello-world. use_backend wordpress-backend if url_wordpress: يقوم بإعادة توجيه أي حركة مرور بيانات تتوافق مع قائمة تحكّم الوصول url_wordpress إلى wordpress-backend، والتي سنقوم بتعريفها قريبًا. default_backend web-backend: يُحدِّد أنّه أي حركة مرور بيانات لا تتوافق مع قاعدة use_backend سيتم تمريرها إلى web-backend، والتي سنقوم بتعريفها في الخطوة القادمة. إعداد الواجهة الخلفية Backend بعد أن تنتهي من إعداد الواجهة الأماميّة، قم الآن إضافة واجهتك الخلفيّة الأولى عن طريق إضافة الأسطر التالية، تأكّد من أن تضع عنوان IP المناسب بدلًا من web_1_private_IP: backend web-backend server web-1 web_1_private_IP:80 check وهذا شرح لما يعنيه كل سطر من المقطع السابق المأخوذ من إعدادات الواجهة الخلفيّة: backend web-backend: يُعيِّن واجهة خلفيّة تُدعى web-backend. server web-1 ... : يُعيِّن خادوم واجهة خلفيّة يُدعى web-1، مع عنوان IP الخاص (وهو الذي يجب أن تستبدله) والمنفذ الذي يستمع عليه، وهو 80 في هذه الحالة، يُخبِر الخيار check مُوازِن الحمل أن يُجري دوريًّا تحقّق من السّلامة على هذا الخادوم. بعدها أضف الواجهة الخلفيّة لتطبيق ووردبريس لديك: backend wordpress-backend reqrep ^([^\ :]*)\ /wordpress/(.*) \1\ /\2 server wordpress-1 wordpress_1_private_IP:80 check وهذا شرح لما يعنيه كل سطر من المقطع السابق المأخوذ من إعدادات الواجهة الخلفيّة: backend wordpress-backend: يُعيِّن واجهة خلفيّة تُدعى wordpress-backend. reqrep ... : يعيد كتابة الطلبات من wordpress/ إلى / عند تمرير حركة مرور البيانات إلى خواديم ووردبريس، وهو ليس ضروريًّا إن كان تطبيق ووردبريس مُثبّتًا على جذر root الخادوم ولكن نحتاج إليه لقابلية النفاذ عبر wordpress/ على خادوم HAProxy. server wordpress-1 ... : يُعيِّن خادوم واجهة خلفيّة يُدعى wordpress-1، مع عنوان IP الخاص (وهو الذي يجب أن تستبدله) والمنفذ الذي يستمع عليه، وهو 80 في هذه الحالة، يُخبِر الخيار check مُوازِن الحمل أن يُجري دوريًّا تحقّق من السّلامة على هذا الخادوم. إعدادات HAProxy: الإحصائيات Stats إن أردت تمكين إحصائيّات HAProxy، والتي قد تكون مفيدة في تحديد كيفيّة تعامل HAProxy مع حركة مرور البيانات الواردة، ستحتاج إلى إضافة الأسطر التالية إلى إعداداتك: listen stats :1936 stats enable stats scope www stats scope web-backend stats scope wordpress-backend stats uri / stats realm Haproxy\ Statistics stats auth user:password وهذا شرح لما تعنيه الأسطر غير البديهيّة من المقطع السابق المأخوذ من إعدادات listen stats: listen stats :1936: يقوم بإعداد صفحة إحصائيّات HAProxy لتكون قابلة للنفاذ على المنفذ 1936 (أي http://haproxy_www_public_IP:1936). stats scope ... : يجمع الإحصائيّات على الواجهة المُحدّدة سواء كانت أماميّة أو خلفيّة. / stats uri: يُعيِّن رابط صفحة الإحصائيّات إلى / . stats realm Haproxy\ Statistics: يقوم بتمكين الإحصائيّات وتعيين اسم الاستيثاق realm Authentication (وهو استيثاق ذو نافذة منبثقة)، يُستخدَم بالترابط مع الخيار stats auth. stats auth haproxy:password: يُعيِّن اعتمادات credentials الاستيثاق لصفحة الإحصائيّات، قم بوضع اسم المستخدم وكلمة السّر الخاصّة بك. الآن قم بالحفظ والإغلاق، عند تشغيل HAProxy تكون صفحة الإحصائيّات متوفّرة عبر الرابط http://haproxy_www_public_ip:1936/ حالما تبدأ خدمة HAProxy لديك، تكون HAProxy جاهزة الآن لتشغيلها ولكن فلنقم بتمكين التسجيل logging أولًا. تمكين تسجيل HAProxy إنّ تمكين التسجيل في HAProxy بسيط جدًّا، قم في البداية بتحرير الملف rsyslog.conf: sudo vi /etc/rsyslog.conf ثم ابحث عن السطرين التاليين وأزل التعليق عنهما لتمكين استقبال UDP syslog، يجب أن تبدو كما يلي عند الفراغ منها: $ModLoad imudp $UDPServerRun 514 $UDPServerAddress 127.0.0.1 الآن أعد تشغيل rsyslog لتمكين الإعدادات الجديدة: sudo service rsyslog restart تم تمكين تسجيل HAProxy الآن، سيتم إنشاء ملف السّجل في المسار var/log/haproxy.log/ بعد أن يتم تشغيل HAProxy. تحديث إعدادات ووردبريس الآن وقد تم تغيير رابط تطبيق ووردبريس فيجب علينا تحديث بعض الإعدادات في ووردبريس. قم بتعديل الملف wp-config.php على أي خادوم ووردبريس، هذا الملف موجود في مكان تثبيت ووردبريس (في هذا الدّرس تم تثبيته على المسار var/www/example.com/ ولكن قد يكون مختلفًا لديك): cd /var/www/example.com; sudo vi wp-config.php ابحث عن السطر الموجود في بداية الملف الذي يحتوي على ('define('DB_NAME', 'wordpress وقم بإضافة الأسطر التالية فوقه مع استبدال http://haproxy_www_public_IP: define('WP_SITEURL', 'http://haproxy_www_public_IP'); define('WP_HOME', 'http://haproxy_www_public_IP'); قم بحفظ وإغلاق الملف، تمّ الآن إعداد روابط ووردبريس لتشير إلى موازن الحمل بدلًا من خادوم ووردبريس الأصلي والتي تلعب دورها عند محاولتك النفاذ إلى لوحة تحكم ووردبريس. تشغيل HAProxy قم بتشغيل HAProxy على الخادوم haproxy-www ليتم تطبيق تغييرات الإعدادات: sudo service haproxy restart إتمام الوسيط العكسي Reverse Proxy أصبحت الآن تطبيقاتنا قابلة للوصول إليها عبر نفس المجال، example.com، عبر الوسيط العكسي للطبقة 7، ولكن لم يتم تطبيق موازنة الحمل عليها بعد، تبدو الآن البيئة لدينا كالمخطط التالي: وفقًا للواجهة الأماميّة التي عرفناها سابقًا، هذا وصف حول كيفيّة تمرير HAProxy لحركة مرور البيانات: http://example.com/wordpress: سيتم إرسال أي طلب يبدأ بـ wordpress/ إلى wordpress-backend (والذي يتكون من الخادوم wordpress-1). http://example.com/: سيتم إرسال أيّة طلبات أخرى إلى web-backend (والذي يتكون من الخادوم web-1). إن كان كل ما تريد فعله هو استضافة تطبيقات متعدّدة على مجال وحيد فقد أنجزت هذا بنجاح، أمّا إن أردت موازنة حمل تطبيقاتك أكمل قراءة الدّرس. كيفية إضافة موازنة الحمل موازنة حمل الخادوم web-1 لموازنة حمل خادوم ويب أساسي، كل ما تحتاج إليه هو إنشاء خادوم ويب جديد يمتلك إعدادات ومحتوى مطابق لخادوم الأصلي، سندعو هذا الخادوم الجديد: web-2. لديك خياران عند إنشاء الخادوم الجديد: إن كنت تملك خيار إنشاء خادوم جديد انطلاقًا من صورة web-1، فهذه هي الطريقة الأبسط لإنشاء web-2. إنشاؤه من الصفر، تثبيت نفس البرمجيّات، إعداده بشكل مماثل، ومن ثمّ نسخ محتوى جذر خادوم Nginx من web-1 إلى web-2 باستخدام rsync (اقرأ درس كيف تستخدِم Rsync لمزامنة مجلّدات بين الجهاز المحلّي والخادوم). ملاحظة: إن كل من الطريقتين السابقتين تقوم بإنشاء نسخة لمحتويات جذر الخادوم مرّة وحيدة، لذلك إن قمت بتحديث أي من الملفّات على أحد خواديمك، web-1 أو web-2، فتأكّد من مزامنة الملفّات مرّة أخرى. بعد أن يتم إعداد خادوم ويب المماثل لديك، قم بإضافته إلى web-backend ضمن إعدادات HAProxy. على الخادوم haproxy-www قم بتحرير الملف haproxy.cfg: sudo vi /etc/haproxy/haproxy.cfg ابحث عن القسم web-backend من الإعدادات: backend web-backend server web-1 web_1_private_IP:80 check وبعدها أضف الخادوم web-2 في السطر التالي: server web-2 web_2_private_IP:80 check قم بحفظ وإغلاق الملف، وأعد تحميل HAProxy لتطبيق التغييرات: sudo service haproxy reload يمتلك web-backend الآن خادومين يتعاملان مع حركة مرور البيانات غير المرتبطة بووردبريس، أي تمّ إعداد موازنة الحمل عليه بنجاح. موازنة حمل الخادوم wordpress-1 إنّ موازنة حمل تطبيق مثل ووردبريس أكثر تعقيدًا بقليل من موازنة حمل خادوم ثابت، لأنّه يجب عليك الاهتمام بأشياء مثل مزامنة الملفّات المُحمّلة ومستخدمي قواعد البيانات الإضافيّين. أكمل الخطوات الثلاث التالية لإنشاء خادوم ووردبريس الثاني wordpress-2: إنشاء خادوم تطبيق ويب الثاني. مزامنة ملفّات تطبيق الويب. إنشاء مستخدم قاعدة بيانات جديد. بعد أن تقوم بإنشاء الخادوم wordpress-2 مع إعداد قاعدة البيانات بشكل صحيح فكل ما تبقى عليك فعله هو إضافته إلى wordpress-backend ضمن إعدادات HAProxy. على الخادوم haproxy-www قم بتحرير الملف haproxy.cfg: sudo vi /etc/haproxy/haproxy.cfg ابحث عن القسم wordpress-backend من الإعدادات: backend wordpress-backend server wordpress-1 wordpress_1_private_IP:80 check وبعدها أضف الخادوم wordpress-2 في السطر التالي: server wordpress-2 wordpress_2_private_IP:80 check قم بحفظ وإغلاق الملف، وأعد تحميل HAProxy لتطبيق التغييرات: sudo service haproxy reload يمتلك web-backend الآن خادومين يتعاملان مع حركة مرور البيانات غير المرتبطة بووردبريس، أي تمّ إعداد موازنة الحمل عليه بنجاح. الخاتمة بعد أن أتممت الآن هذا الدّرس يجب أن تكون قادرًا على توسيع موازنة الحمل والوسيط العكسي لإضافة المزيد من التطبيقات والخواديم لبيئتك لجعلها تتوافق بشكل أفضل مع احتياجاتك، تذكّر أنّه لا توجد حدود لطرق إعداد بيئتك، وربّما تحتاج إلى البحث في توثيق HAProxy إن أردت متطلبات أكثر تعقيدًا. ترجمة -وبتصرّف- للمقال How To Use HAProxy As A Layer 7 Load Balancer For WordPress and Nginx On Ubuntu 14.04 لصاحبه Mitchell Anicas.
  13. طوّرت شركة Sun Microsystems نظام الملفّات الشبكي Network file system, NFS سنة 1980 من أجل السماح بتشارك الملفّات والمجلّدات بين الأنظمة الشبيهة بيونكس (لينكس ويونكس). يتيح نظام NFS للملفّات تركيب Mounting ملفّات عبر الشّبكة والتعامل معها كما لو كانت مركَّبة محليًّا على نفس النظام. فوائد نظام NFS يسمح نظام NFS بالوصول إلى الملفّات عن بعد. يستخدم بنية عميل-خادوم Client/Server معيارية لتشارك الملفّات بين جميع الأجهزة العاملة بالأنظمة الشبيهة بيونكس. ليس ضروريًّا عند استخدام NFS أن تكون الأجهزة تعمل على نفس نظام التّشغيل. يمكن ضبط حلول للتخزين المركزيّ بمساعدة نظام NFS. يعثُر المستخدمون على بياناتهم مهما كان تواجدها الفعلي. لا توجد حاجة للتحيين Refresh اليدوي للحصول على الملفّات الجديدة. تدعم الإصدارات الحديثة من NFS قوائم التحكّم في الوصول ACL. يمكن تأمينه عبر الجدران الناريّة Firewalls وKerberos (ميثاق للاستيثاق عبر الشبكة). تدخلّ الملفّات التاليّة في إعداد NFS: ملفّ etc/exports/: وهو ملفّ الإعداد الرئيس؛ تعرّف فيه - على الخادوم - جميع الملفّات والمجلّدات المشاركة. ملفّ etc/fstab/: يجب إدراج سطر لكلّ نظام ملفّات مُركَّب ضمن هذا الملفّ حتى يكون التركيب دائما (يبقى بعد إعادة التشغيل). ملفّ etc/sysconfig/nfs/: يعرّف المنافذ التي تنصت الخدمات للاتّصالات الواردة عبرها. إعداد NFS على خادوم أوبونتو سنعتمد في هذا الدرس على جهازين يعملان بإحدى توزيعات لينكس التاليّة: دبيان، أوبونتو أو ردهات. سنثبّت على أحد الجهازين خادوم NFS وعلى الثاني عميلا له كالتالي: خادوم NFS على العنوان 192.168.2.200. عميل NFS على العنوان 192.168.2.150. يمكنك استخدام VirtualBox لإعداد بيئة عمل بالمواصفات أعلاه. تثبيت الخادوم والعميل سنحتاج لتثبيت حزم NFS على الخادوم والعميل: # apt-get update # apt-get install nfs-kernel-server nfs-common ملحوظة: يمكن الاكتفاء بالحزمة nfs-common على العميل. تشير العلامة # إلى أن الأمر ينفَّذ بصلاحيّات الجذر. إعداد خادوم NFS الخطوة الأولى هي تحديد المجلّد الذي نريد مشاركته؛ سننشئ واحدا لهذا الغرض (يمكنك اختيّار مجلّد موجود مسبقا): # mkdir /nfsshare ثم نغيّر ملكيّته إلى nobody:nogroup: # chown nobody:nogroup /nfsshare غيّرنا ملكيّة الملفّ إلى المستخدم nobody الذي هو حساب لا يملك سوى الصلاحيّات الدنيا ويُستخدَم عادة لتنفيذ سكربتات غير مأمونة المصدر حتى لا تلحق أي ضرر بالنظام. هذه الخطوة ضروريّة وإلا فلن يكون بمقدورك إضافة ملفّات إلى المجلّد انطلاقا من العميل؛ إلا إذا أضفت خيار no_root_squash كما هو مشروح أدناه (لا يُنصَح بذلك). ليمكن تشاركُ المجلّد يجب أن نضيفه إلى ملفّ الإعداد etc/exports/؛ نفتح هذا الملفّ (بصلاحيّات الجذر) ثم نضيف إليه السّطر التالي: /nfsshare 192.168.2.150(rw,sync) يسمح السّطر أعلاه بتشارك المجلّد nfsshare مع العميل على العنوان 192.168.2.150 مع تحديد خيارات التشارك. يمكن أن تكون الخيارات على النحو التالي: ro: الوصول عبر وضع القراءة فقط؛ أي أن العميل يمكنه الوصول إلى الملفات المتشاركة فقط دون أن يكون قادرا على التعديل عليها أو إنشاء ملفات جديدة. rw: يمنح العميل القدرة على الوصول إلى الملفّات والتعديل عليها. sync: مزامنة التعديلات. يعني هذا أن أي تعديل سيُحفَظ فورا على نظام الملفّات؛ قد يؤثّر هذا الخيار على الأداء في حالة وجود الكثير من التغييرات المتزامنة على ملفّات كبيرة. no_subtree_check: يفحص نظام NFS مبدئيّا جميع المجلدات التي يتفرّع منها المجلّد المتشارَك من أجل التحقّق من الأذون وتفاصيل أخرى. يؤدّي تفعيل هذه الخاصيّة إلى تعطيل الفحص ممّا يحسّن من الأداء ولكنّه يؤدّي التقليل من الأمان. no_root_squash: تسمح هذه الخاصيّة للمستخدم الجذر على الجهاز العميل بالوصول إلى الملفّات المتشاركة على الخادوم بصلاحيّات الجذر على الخادوم. لا يُنصَح لأسباب أمنيّة باستخدام هذا الخيار إلا في حالات خاصّة. نطبّق الأمر exportfs بعد الانتهاء من تحرير الملفّ exports من أجل اعتماد التعديلات: # exportfs -r ثم نشغّل خدمة NFS كالتالي: # service nfs-kernel-server start إعداد عميل NFS على أوبونتو يمكننا الآن تركيب مجلّد التشارك على العميل. تأكد من أنه يمكن التواصل عبر الشبكة بين الجهاز الخادوم والعميل؛ مثلا باستخدام الأمر ping على العميل (حيثُ 192.168.2.200 هو عنوان الخادوم): $ ping 192.168.2.200 PING 192.168.2.200 (192.168.2.200) 56(84) bytes of data. 64 bytes from 192.168.2.200: icmp_seq=7 ttl=52 time=363 ms 64 bytes from 192.168.2.200: icmp_seq=8 ttl=52 time=322 ms نبدأ أولا بالبحث عن الملفّات المتشاركة عبر NFS على الخادوم: $ showmount -e 192.168.2.200 Export list for 192.168.2.200: /nfsshare 192.168.2.150 يظهر من نتيجة الأمر أعلاه أن المجلّد nfsshare/ متاح للتشارك مع العميل ذي العنوان 192.168.2.150. تركيب المجلد على العميل سننشئ على العميل مجلّدًا باسم mnt/nfs/nfsshare_mount/ ونستخدمه لتركيب المجلّد nfsshare/ على العميل (المجلّد nfsshare/ الموجود على الخادوم): # mkdir -p /mnt/nfs/nfsshare_mount # mount -t nfs 192.168.2.200:/nfsshare /mnt/nfs/nfsshare_mount يمكننا التأكد من تركيب المجلّد بتنفيذ الأمر mount والبحث عن نوع الملفّات nfs: $ mount | grep nfs 192.168.2.200:/nfsshare on /mnt/nfs/nfsshare_mount type nfs (rw,vers=4,addr=192.168.2.200,clientaddr=192.168.2.150) يمكن الآن إضافة ملفّات إلى مجلّد التشارك عبر نقطة التركيب: # touch /mnt/nfs/nfsshare_mount/testfile.txt يمكن التأكد من على الخادوم بسرد محتويات المجلّد nfsshare/. إن أردت جعل التركيب دائما (لا يزول مع إقلاع النظام) فيمكنك إضافة السطر التالي إلى ملفّ etc/fstab/: 192.168.2.200:/nfsshare /mnt/nfs/nfsshare_mount nfs defaults 0 0 نفّذ الأمر mount -a بعد تعديل ملفّ fstab لاعتماد التغييرات فورا. ملحوظة: تأكد من إدخال القيم الصحيحة في ملفّ etc/fstab/؛ وجود أخطاء في صياغة السّطر يمكن أن يؤدي إلى عدم إقلاع النظام. فصل المجلد من العميل استخدم الأمر umount إن أردت فصل المجلّد المركَّب، تُمرّضر نقطة التركيب للأمر على النحو التالي: # umount /mnt/nfs/nfsshare_mount نفّذ الأمر mount | grep nfs للتأكد من فصل المجلّد. أوامر أساسية للتعامل مع ملفات NFS في ما يلي أوامر يكثُر استخدامها أثناء التعامل مع المجلّدات المشارَكة عبر نظام NFS: showmount -e: يعرض جميع المجلّدات المتشاركة المتاحة على الجهاز. showmount -e <server-ip>: يسرد قائمة بالمجلّدات المشاركة المتاحة على الخادوم ذي العنوان server-ip. showmount -d <server-ip>: سرد المجلّدات المشاركة المتاحة على الخادوم والمجلدات المتفرعة منها. exportfs -v: يعرض قائمة بالمجلّدات المتشاركة الموجوة على الخادوم. exportfs -a: يطلب من الخادوم مشاركة الملفّات المحدّدة في الملفّ etc/exports/. exportfs -u: يعمل عكسَ عمل الأمر السابق، إذ يوقف مشاركة المجلدات المحدّدة في etc/exports/. exportfs -r: يحدّث قائمة المشاركات بعد التعديل على الملفّ etc/exports/. يمكن اعتماد هذا المقال الذي يقدّم أساسيات تشارك الملفّات عبر نظام NFS للانتقال إلى تفاصيل أكثر تقدّما بخصوص NFS والميزات التي يقدّمها. ترجمة -وبتصرّف- للمقال How to Setup NFS (Network File System) on RHEL/CentOS/Fedora and Debian/Ubuntu لصاحبه Tarunika Shrivastava.
  14. تم بشكل رسمي إطلاق الإصدار 16.04 LTS ذو الدعم طويل الأمد (الملقّب بـ Xerial Xerus) من توزيعة أوبونتو منذ عدّة أسابيع، ويتشوق الكثيرون إلى معرفة المزيد عن التغييرات التي طرأت والميزات الجديدة التي أضيفت، ويمكن القيام بذلك من خلال تثبيت نسخة نظيفة clean install أو تحديث نسخة قديمة من توزيعة لينوكس أوبونتو. سنتابع في المقال كيفية القيام بتحديث توزيعة أوبونتو من الإصدار 14.04 LTS إلى الإصدار الجديد وذلك خطوة بخطوة. تحذير: يجب أخذ الاحتياطات اللازمة وإنشاء نسخة احتياطية للبيانات كالمجلدات والمستندات والصور والكثير من الملفات الموجودة على النظام، ولا يجوز ترك الموضوع للحظ لأن في بعض الأحيان لا تجري عمليات التحديث كما هو متوقّع، وقد تصادف بعض الإشكالات التي قد تؤدي إلى تلف البيانات في حال فشلت عملية التحديث. تحديث توزيعة أوبونتو 14.04 إلى 16.04 على نسخة أوبونتو المكتبية Desktop Edition في البداية سنتحقق من أن النظام يملك آخر إصدار من البرمجيات المثبّتة، ونقوم بذلك من خلال فتح مدير تحديثات أوبونتو Ubuntu Update manager الموجود في لوحة القيادة Dashboard. رسم توضيحي 1 – البحث عن الإصدارات الجديدة لبرمجيات أوبونتو المثبّتة سيقوم مدير التحديثات بفحص النظام للتحقق فيما إذا كانت البرمجيات المثبتة تم تحديثها لآخر إصدار، وعند انتهائه يقوم بعرض قائمة بالبرمجيات التي سيتم تحديثها وتثبيت الإصدار الجديد منها. رسم توضيحي 2 - قائمة بالبرمجيات التي يتوفر إصدارات أحدث منها نقوم بالضغط على زر Install Now لتحميل وتثبيت التحديثات المعروضة. رسم توضيحي 3 - تحميل تحديثات برمجيات أوبونتو بعد انتهاء التحميل، سيتم البدء بتثبيت الإصدارات الجديدة: رسم توضيحي 4 - تثبيت تحديثات برمجيات أوبونتو بعد الانتهاء سيعُرض علينا إعادة التشغيل لإنهاء عملية تثبيت التحديثات، وسنقوم باختيار إعادة التشغيل Restart Now. رسم توضيحي 5 - إعادة التشغيل لإنهاء عملية تحديث البرمجيات أخيرًا، يمكن التحقق من أنه قد تم تثبيت جميع التحديثات على البرمجيات بفتح مدير التحديثات مجددًا ويُفترض أن تظهر الرسالة التالية التي تشير إلى عدم وجود تحديثات جديدة: رسم توضيحي 6 - جميع البرمجيات مثبتة بآخر إصداراتها سنباشر الآن بعملية تحديث التوزيعة، نقوم في البداية بفتح سطر الأوامر وتنفيذ الأمر التالي للبدء بعملية تحديث التوزيعة للإصدار الجديد 16.04 LTS: $ sudo update-manager -d تنبيه: انتبه إلى وجود مسافة ما بين update-manager و d- في الأمر السابق. بعد تنفيذ الأمر، سيطلب النظام إدخال كلمة مرور المستخدم، قم بإدخالها والضغط على مفتاح Enter وسيتم فتح مدير التحديث update-manager كما في الصورة: رسم توضيحي 7 - تحديث أوبونتو إلى الإصدار 16.04 أخيرًا، اضغط على زر Upgrade لتحديث نسخة التوزيعة. تحديث توزيعة أوبونتو 14.04 إلى 16.04 على نسخة أوبونتو الخاصة بالخوادم Server Edition سنقوم بتطبيق ذات الخطوات أيضًا، حيث سنبدأ بتحديث البرمجيات المثبتة من خلال تنفيذ الأمر: $ sudo apt-get update && sudo apt-get dist-upgrade وبعد الانتهاء قم بإعادة التشغيل لإنهاء تثبيت التحديثات: $ sudo init 6 بعد ذلك سنقوم بتثبيت حزمة update-manager-core باستخدام الأمر التالي إذا لم تكن مثبتة مسبقًا على الخادوم: $ sudo apt-get install update-manager-core بعد ذلك، سنقوم بفتح الملف etc/update-manager/release-upgrades/ باستخدام أي محرر نصوص نُفضّله (نستخدم vi في مثالنا)، وسنضيف عبارة Prompt=lts إلى نهايته كما في الصورة التالية: $ sudo vi /etc/update-manager/release-upgrades رسم توضيحي 8 - إعداد مدير تحديثات أوبونتو بعد ذلك، سنبدأ عملية التحديث بتنفيذ الأمر: $ sudo do-release-upgrade -d تنبيه: انتبه أيضًا إلى وجود مسافة ما بين do-release-upgrade و d- في الأمر السابق. رسم توضيحي 9 - عملية تحديث توزيعة أوبونتو 14.04 بعد أن يقوم مدير التحديثات بتحديد الحزم التي سيتم تحديثها وأفضل مصادر لها، سيطلب منك تأكيد العملية لذا سنقوم بالنقر على مفتاح y (الذي يشير إلى كلمة yes) ومن ثم نضغط على مفتاح Enter للبدء بعملية التحديث: رسم توضيحي 10 - تحديث أوبونتو للإصدار 16.04 سيُعرض أثناء عملية التحديث إعادة تشغيل بعض الخدمات، لذا نختار الموافقة yes حينها: رسم توضيحي 11 - إعداد الخدمات أثناء عملية تحديث توزيعة أوبونتو أخيرًا، سيُسأل فيما إذا كنا نرغب بإزالة الحزم القديمة التي تم تحديثها أو استبدالها، وسنقوم بالموافقة بالضغط على مفتاح y ومن ثم Enter. بعد انتهاء عملية التحديث نقوم بإعادة تشغيل الخادوم باستخدام الأمر: $ sudo init 6 ونكون قد انتهينا من تحديث توزيعة أوبونتو للإصدار 16.04 LTS. آمل أن تجدوا هذا الدليل مفيًدا ومساعدًا، وفي حال ظهور مشكلة أثناء العملية نظرًا لاختلاف خبرات المستخدمين أثناء عملية التحديث، فلا تترددوا بالسؤال في قسم التعليقات أدناه. ترجمة -وبتصرّف- للمقال How To Upgrade to Ubuntu 16.04 LTS from Ubuntu 14.04 LTS لصاحبه Aaron Kili.
  15. يعتبر Ansible حلًا مناسبًا لأتمتة الأعمال التقنية البسيطة، فإن وجدت نفسك تقوم بتثبيت ووردبريس بشكل متكرر ومُمل، فقد يوفّر عليك Ansible الكثير من الوقت، وباستخدام بعض الأسطر بلغة YAML (وهي لغة توصيف واضحة ومباشرة) سنقوم بأتمتة عملية تثبيت ووردبريس على خادوم يعمل بنظام تشغيل Ubuntu 14.04، وفق الخطوات بصورة أوتوماتيكية. سنستخدم خادومين: أحدهما الخادوم الباني ويتم تشغيل Ansible عليه، والآخر الذي سنقوم بتثبيت ووردبريس عليه باستخدام Ansible. المتطلبات الأولية قبل المتابعة في المقال، سنحتاج للأمور التالية: خادوم يعمل بنظام تشغيل Ubuntu 14.04. سنقوم بتثبيت Ansible على هذا الخادوم (ونشير إليه في المقال بـ الخادوم الباني). سنقوم بتسجيل الدخول إلى هذا الخادوم وجميع الأوامر والملفّات المذكورة في المقال على هذا الخادوم، خادوم آخر يعمل بنظام تشغيل Ubuntu 14.04. سنقوم بتثبيت ووردبريس عليه باستخدام Ansible (وسنشير إليه في المقال بـ خادوم ووردبريس)، حساب مستخدم عادي -على كِلا الخادومين- لا يملك صلاحيات مدير نظام، لكنّه يملك صلاحية تنفيذ الأمر sudo، إضافة مفتاح SSH الخاص بالمستخدم -الذي أنشأناه على الخادوم الباني- إلى المفاتيح المصادقة authorized_keys للمستخدم الذي أنشأناه على خادوم ووردبريس، وينبغي تنفيذ هذه العملية على الخادوم الباني ورفع المفاتيح إلى خادوم ووردبريس. تنفيذ أوامر sudo بدون تأكيد باستخدام كلمة مرور إنّ من الأسرع -ولكن أقل أمانًا- تنفيذ أوامر sudo على خادوم ووردبريس بدون الحاجة لإدخال كلمة مرور تأكيد في كل مرّة. لإعطاء المستخدم على خادوم ووردبريس هذه الإمكانية، سنقوم بتعديل ملف sudoers باستخدام الأمر visudo على سطر الأوامر: $ visudo ومن ثم سنضيف السطر التالي في نهاية الملف: sammy ALL=(ALL) NOPASSWD: ALL ملاحظة: لا تنس استبدال اسم المستخدم (sammy في هذه الحالة) باسم المستخدم الموجود لديك، وتأكد من وضع السطر في نهاية الملف حتى لا يتم تجاوزه بالصلاحيات الافتراضية الموجودة في الملف. نصيحة: قم دومًا باستخدام الأمر visudo عند تعديل ملف sudoers، لأن الأمر سيقوم بالتحقق من التعديلات قبل حفظ الملف ويحميك بالتالي من ارتكاب أخطاء في الملف قد تؤدي إلى منعك من الدخول. حالما تنتهي من تنفيذ العملية السابقة سيغدو بإمكانك تنفيذ الأمر التالي على خادوم ووردبريس بدون إدخال كلمة مرور لتأكيده: $ sudo echo "Hello" وفي بقية المقال، تستطيع تنفيذ الأمر ansible-playbook بدون المُعامل K- كي تتجنب الحاجة لإدخال كلمة المرور للتأكيد بشكل يدوي: $ ansible-playbook playbook.yml -i hosts -u sammy الخطوة الأولى: تثبيت Ansible سنقوم الآن بتثبيت Ansible على الخادوم الباني، ونبدأ بتسجيل الدخول عبر SSH إلى الخادوم وتنفيذ الأمر التالي: $ sudo apt-get install ansible -y وتستطيع التأكد من تثبيت Ansible بتنفيذ الأمر: $ ansible --version حيث ينبغي أن يكون الخرج مشابهًا (وليس بالضرورة مطابقًا) لما يلي: ansible 1.5.4 الخطوة الثانية: إعداد بنية الملفات الآن وبعد أن انتهينا من تثبيت Ansible، دعونا نقوم بإعداد بنية الملفات من أجل Ansible playbook. سنقوم بإنشاء مجلّد على النحو التالي: $ cd ~ $ mkdir wordpress-ansible && cd wordpress-ansible سنقوم الآن بإنشاء ملفّين: الأول يدعى playbook.yml (حيث سنقوم بكتابة الأوامر الخاصة بتثبيت ووردبريس فيه) والثاني يدعى hosts (وهذا يُخبر Ansible عن الخواديم التي سيتم تنفيذ الأوامر عليها): $ touch playbook.yml $ touch hosts إنّ من الأفضل فصل الأوامر بحسب الأدوار، ومن الممكن اعتبار الأدوار كأجزاء من الممكن إعادة استخدامها، وسنقوم في هذا المشروع بإنشاء 4 أدوار: server php mysql wordpress سنقوم بإنشاء مجلد الأدوار في الجذر الرئيسي للمجلد الذي أنشأناه سابقًا wordpress-ansible/~ بتنفيذ الأمر التالي: $ mkdir roles && cd roles والآن سنقوم بتجهيز الأدوار باستخدام أداة من أدوات Ansible تدعى ansible-galaxy، حيث سنقوم من أجل كل دور بتنفيذ الأمر ansible-galaxy init كالتالي: $ ansible-galaxy init server $ ansible-galaxy init php $ ansible-galaxy init mysql $ ansible-galaxy init wordpress ستلاحظ بأن هذا الأمر سيقوم بإنشاء هيكل ملفات متكامل لكل دور من الأدوار، وهذه الخطوة هي إحدى الأمور التي ينصح بها في توثيق Ansible. ما يهمّنا غالبًا هو التعامل مع محتوى ملف tasks/main.yml لكل دور. عند الوصول إلى هذه المرحلة سيكون لدينا الهيكل التالي: [.] |_ playbook.yml |_ hosts |_ [roles] |_ [server] |_ ... |_ [php] |_ ... |_ [mysql] |_ ... |_ [wordpress] |_ ... الخطوة الثالثة: إنشاء الـ Playbook سنقوم الآن بكتابة الأوامر التي ستقوم بتثبيت ووردبريس على خادوم ووردبريس. ملف المخزون hosts يُخبر هذا الملف Ansible بالخواديم التي نرغب بتثبيت ووردبريس عليها، ومن الممكن تنفيذ الأوامر للخواديم أو مجموعة الخواديم المعرّفة في ملف المخزون hosts. سنقوم بتحرير ملف hosts باستخدام محرر nano أو أي محرر آخر تفضّله وكتابة التالي: [wordpress] wordpress_server_ip ملاحظة: من الممكن وضع أي عدد نرغب به من العناوين الرقمية IPs تحت مجموعة [wordpress]. سيؤدي هذا إلى تنفيذ الأوامر على جميع الخواديم المذكورة على افتراض أننا نملك صلاحية استخدام هذه الخواديم. سيمكّننا هذا من تثبيت ووردبريس على أي عدد من الخواديم دفعة واحدة. ملف Playbook يمكن اعتبار هذا الملف كتعريف لتطبيق ووردبريس الذي سنقوم بتثبيته. سيحتوي الملف على جميع الأدوار التي قمنا بإنشائها بغرض تجهيز تطبيق مفيد (ووردبريس في حالتنا). سنقوم بداية بتحرير الملف باستخدام محرر nano أو أي محرر آخر ترغب به: $ nano ~/wordpress-ansible/playbook.yml ومن ثم سنضيف المحتويات التالية إلى الملف، والتي ستُخبر Ansible أية أدوار سيتم تنفيذها على أية خواديم (سيتم تنفيذ الأدوار المذكورة في حالتنا على مجموعة العناوين الرقمية المدرجة في مجموعة wordpress المسجّلة في ملف hosts الذي أنشأناه سابقًا): - hosts: wordpress roles: - server - php - mysql - wordpress والآن لنعد إلى الجذر الرئيسي: $ cd ~/wordpress-ansible/ سنتأكد الآن من أنه من الممكن إجراء اتصال ما بين الخادوم الباني وخادوم ووردبريس من خلال تنفيذ ملف playbook الذي لن يقوم بأي شيء سوى التحقق من الاتصال: $ ansible-playbook playbook.yml -i hosts -u sammy -K ستُطالب بإدخال كلمة المرور لتأكيد الأمر، ولا تنس أن تقوم باستبدال اسم المستخدم بالموجود لديك. سيظهر لنا خرج يشبه التالي عند تنفيذ الأمر: ansible-playbook playbook.yml -i hosts -u sammy -K PLAY [wordpress] ************************************************************** GATHERING FACTS *************************************************************** ok: [188.166.68.134] PLAY RECAP ******************************************************************** 188.166.68.134 : ok=1 changed=0 unreachable=0 failed=0 والذي سيؤكد لنا بأن الاتصال قد تم بنجاح، دون أن يتم تنفيذ أي تعديلات لأننا لم نقم بتحديد أي أوامر لتنفيذها حتى الآن. إن فشل تنفيذ الأمر فتأكّد من أن باستطاعتك تسجيل الدخول إلى خادوم ووردبريس من الخادوم الباني باستخدام مفتاح SSH الذي قمت بنسخه في البداية. الخطوة الثالثة: إنشاء الأدوار دور Server سنقوم بداية بتعريف الأوامر التي سيتم تنفيذها على الخادوم ولهذا الغرض سنقوم بتحرير أوامر دور server. ستقوم الأوامر التي سنصرّح عنها بتثبيت جميع البرمجيات التي سنحتاجها على السيرفر الهدف. نبدأ بتنفيذ الأمر التالي: $ nano roles/server/tasks/main.yml قم بإضافة المحتويات التالية وتأكد من وجود سطر واحد فقط يحتوي على --- (حيث يوجد هذا السطر سلفًا بشكل افتراضي): --- - name: Update apt cache apt: update_cache=yes cache_valid_time=3600 sudo: yes - name: Install required software apt: name={{ item }} state=present sudo: yes with_items: - apache2 - mysql-server - php5-mysql - php5 - libapache2-mod-php5 - php5-mcrypt - python-mysqldb سيقوم المحتوى السابق بما يلي: تحديث خبء apt-cache (تنفيذ الأمر apt-get update)، تثبيت Apache ،MySQL ،PHP وبرمجيات أخرى مرتبطة باستخدام apt-get install. وإن كنت مهتمًّا بمعرفة تفاصيل ما نقوم بتثبيته، فيمكنك الاطلاع على هذا المقال حول تثبيت LAMP على Ubuntu 14.04 بشكل يدوي. سنقوم الآن بتنفيذ ansible-playbook مرة أخرى على النحو التالي: $ ansible-playbook playbook.yml -i hosts -u sammy -K ويفترض هذه المرة أن يكون الخرج بما يشبه التالي: ansible-playbook playbook.yml -i hosts -u sammy -K PLAY [wordpress] ************************************************************** GATHERING FACTS *************************************************************** ok: [188.166.68.134] TASK: [server | Update apt cache] ********************************************* ok: [188.166.68.134] TASK: [server | Install required software] ************************************ changed: [188.166.68.134] => (item=apache2,mysql-server,php5-mysql,php5,libapache2-mod-php5,php5-mcrypt,python-mysqldb) PLAY RECAP ******************************************************************** 188.166.68.134 : ok=3 changed=1 unreachable=0 failed=0 وبعد التنفيذ، ينبغي أن تكون قادرًا على استعراض الصفحة الافتراضية لـ Apache عبر فتح العنوان http://wordpress_server_ip في المتصفح. ملاحظة: إن توقّف تنفيذ الأمر بشكل نهائي عند سطر [TASK: [server | Update apt cache فمن المحتمل أن يكون هناك نقص في الصلاحيات المطلوبة على الخادوم الهدف، لذا تأكّد من أن الوصول باستخدام sudo تم إعداده بشكل صحيح على خادوم ووردبريس. دور PHP سنقوم الآن بتجهيز الأوامر التي تستهدف PHP، ولهذا الغرض سنقوم بتحرير الملف الخاص بهذا الدور: $ nano roles/php/tasks/main.yml ومن ثم سنضيف المحتوى التالي (تأكّد من وجود سطر واحد فقط يحتوي على --- في بداية الملف): --- - name: Install php extensions apt: name={{ item }} state=present sudo: yes with_items: - php5-gd - libssh2-php سيقوم المحتوى السابق بتثبيت الملحقات extensions الضرورية لـ PHP وهي: php5-gd و libssh2-php. دور MySQL سنقوم الآن بإعداد قاعدة بيانات MySQL لموقع ووردبريس، وذلك في دور mysql. سنحتاج من أجل القيام بذلك إلى بعض المتغيّرات، والتي من الممكن تخزينها في ملف المتغيرات الافتراضية defaults/main.yml: $ nano roles/mysql/defaults/main.yml سنضيف في الملف اسم قاعدة البيانات، اسم المستخدم الخاص بالقاعدة، كلمة المرور الخاصة بالمستخدم وبنفس الترتيب، ولا تنس أن تستخدم كلمة مرور معقّدة لأغراض أمنية: --- wp_mysql_db: wordpress wp_mysql_user: wordpress wp_mysql_password: wp_db_password والآن نستخدم nano لتحرير ملف المهام: $ nano roles/mysql/tasks/main.yml ونضيف المحتوى التالي: --- - name: Create mysql database mysql_db: name={{ wp_mysql_db }} state=present - name: Create mysql user mysql_user: name={{ wp_mysql_user }} password={{ wp_mysql_password }} priv=*.*:ALL يقوم المحتوى السابق بـ: إنشاء قاعدة بيانات MySQL، إنشاء مستخدم MySQL، إعطاء المستخدم صلاحية الوصول إلى قاعدة البيانات. وكما ترى فسيتم استخدام قيم المتغيرات بشكل تلقائي من ملف defaults/main.yml عند تنفيذ الأوامر. ملاحظة: توفّر أدوات Ansible أداة ansible-vault والتي تسمح بتخزين كلمات المرور بصورة مشفّرة حتى لا تكون قابلة للقراءة في الملف، ولكن الحديث عن هذا خارج إطار حديثنا الآن. دور WordPress والآن نأتي للحظة التي كنا ننتظرها.. تثبيت ووردبريس. نبدأ بتحرير ملف المهام كالمعتاد: $ nano roles/wordpress/tasks/main.yml وسنقوم بنسخ المحتوى التالي إليه: --- - name: Download WordPress get_url: url=https://wordpress.org/latest.tar.gz dest=/tmp/wordpress.tar.gz validate_certs=no sudo: yes سيقوم المحتوى السابق بتحميل ووردبريس إلى مجلد tmp/ (ويمكن للحذرين أن ينتبهوا إلى أننا قمنا بتعطيل التحقق من الشهادة الأمنية، لأنه سيمنع عملية التحميل). بعد اكتمال التحميل سنقوم بفك ضغط الملف إلى var/www/، وهو المسار الذي يستخدمه Apache لتخزين محتوى الويب، وبالتالي سنضيف الجزء التالي لمحتوى الملف أيضًا: - name: Extract WordPress unarchive: src=/tmp/wordpress.tar.gz dest=/var/www/ copy=no sudo: yes وبعد أن يتم فك ضغط الملفات، سنقوم بتحديث مسار الجذر الافتراضي DocumentRoot في ملف إعدادات Apache كي يشير إلى موقع ووردبريس: - name: Update default Apache site sudo: yes lineinfile: dest=/etc/apache2/sites-enabled/000-default.conf regexp="(.)+DocumentRoot /var/www/html" line="DocumentRoot /var/www/wordpress" notify: - restart apache sudo: yes لاحظ أننا استخدمنا الكتلة notify، والتي نحتاجها عند الرغبة بإعادة تشغيل خدمات بعد أن يتم تنفيذ مهمّة بنجاح، ولا يتم تنفيذ معالجات notify إلا عندما يحصل تغيير على حالة المهمّة. سنقوم بإضافة المعالج الخاص بنا لإعادة تشغيل Apache باستخدام restart apache ويتم ذلك في الملف roles/wordpress/handlers/main.yml: $ nano roles/wordpress/handlers/main.yml نضيف المحتوى التالي: --- - name: restart apache service: name=apache2 state=restarted sudo: yes ويتم تنفيذ هذه المهمّة عندما تتغير حالة المهمّة التي تحتوي على الكتلة notify: restart apache، مما يؤدي إلى إعادة تشغيل الخدمة. إعداد ووردبريس بالعودة إلى roles/wordpress/tasks/main.yml، سنقوم الآن بتجهيز إعدادات موقع ووردبريس، فنقوم أولًا بنسخ ملف الإعدادات config الافتراضي: - name: Copy sample config file command: mv /var/www/wordpress/wp-config-sample.php /var/www/wordpress/wp-config.php creates=/var/www/wordpress/wp-config.php sudo: yes ومن ثم نقوم بتغيير بعض الثوابت في الملف لتتطابق مع معلومات الاتصال بقاعدة البيانات: - name: Update WordPress config file lineinfile: dest=/var/www/wordpress/wp-config.php regexp="{{ item.regexp }}" line="{{ item.line }}" with_items: - {'regexp': "define\\('DB_NAME', '(.)+'\\);", 'line': "define('DB_NAME', '{{wp_mysql_db}}');"} - {'regexp': "define\\('DB_USER', '(.)+'\\);", 'line': "define('DB_USER', '{{wp_mysql_user}}');"} - {'regexp': "define\\('DB_PASSWORD', '(.)+'\\);", 'line': "define('DB_PASSWORD', '{{wp_mysql_password}}');"} sudo: yes حيث ستقوم المهمّة بجلب معلومات الاتصال بالقاعدة من ملف المتغيّرات الافتراضية الذي قمنا بتحريره سابقًا. بعد الانتهاء من الخطوات السابقة بنجاح، سيكون قد أصبح لدينا ملفّين لدور wordpress، وفيما يلي النسخة الكاملة لمحتوى الملفّين.. ملف roles/wordpress/tasks/main.yml: --- - name: Download WordPress get_url: url=https://wordpress.org/latest.tar.gz dest=/tmp/wordpress.tar.gz validate_certs=no - name: Extract WordPress unarchive: src=/tmp/wordpress.tar.gz dest=/var/www/ copy=no sudo: yes - name: Update default Apache site sudo: yes lineinfile: dest=/etc/apache2/sites-enabled/000-default.conf regexp="(.)+DocumentRoot /var/www/html" line="DocumentRoot /var/www/wordpress" notify: - restart apache - name: Copy sample config file command: mv /var/www/wordpress/wp-config-sample.php /var/www/wordpress/wp-config.php creates=/var/www/wordpress/wp-config.php sudo: yes - name: Update WordPress config file lineinfile: dest=/var/www/wordpress/wp-config.php regexp="{{ item.regexp }}" line="{{ item.line }}" with_items: - {'regexp': "define\\('DB_NAME', '(.)+'\\);", 'line': "define('DB_NAME', '{{wp_mysql_db}}');"} - {'regexp': "define\\('DB_USER', '(.)+'\\);", 'line': "define('DB_USER', '{{wp_mysql_user}}');"} - {'regexp': "define\\('DB_PASSWORD', '(.)+'\\);", 'line': "define('DB_PASSWORD', '{{wp_mysql_password}}');"} sudo: yes ملف roles/wordpress/handlers/main.yml: --- - name: restart apache service: name=apache2 state=restarted sudo: yes ونكون قد انتهينا. لنقم الآن بتشغيل ansible-playbook لآخر مرة لإعداد موقع ووردبريس: $ ansible-playbook playbook.yml -i hosts -u sammy -K وبعد تنفيذ الأمر ينبغي أن نكون قادرين على تصفّح الموقع عبر طلب عنوانه http://your_server_ip في المتصفح ويمكن الآن متابعة إعداد موقع ووردبريس بشكل يدوي عند هذه المرحلة. الخلاصة تهانينا! ستتمكن الآن من تثبيت مواقع ووردبريس على أي عدد من الخواديم التي تعمل بنظام تشغيل Ubuntu باستخدام أمر واحد: $ ansible-playbook playbook.yml -i hosts -u sammy -K وكل ما تحتاج للقيام به هو إضافة العنوان الرقمي IP إلى قائمة الخواديم المستهدفة في ملف hosts والتأكّد من أن الصلاحيات قد تم إعدادها مسبقًا على الخادوم الهدف. تناولنا في المقال بصورة سريعة كيفية استخدام Ansible لتثبيت مواقع ووردبريس بشكل اوتوماتيكي، وقد تكون مهتمًّا ببعض التحسينات الإضافية الممكنة: تعلّم كيفية استضافة أدوارك الخاصة في الـ Ansible Galaxy. أتمتة عملية الإعداد النهائية لموقع ووردبريس حتى لا يكون هناك حاجة للقيام بأي إعداد يدوي للموقع المطلوب إطلاقًا. ترجمة -وبتصرّف- للمقال How To Automate Installing WordPress on Ubuntu 14.04 Using Ansible لصاحبه Christo Crampton.
  16. تعتمد سرعة عرض صفحة ويب على حجم جميع الملفات المرتبطة بالصفحة والتي يجب تحميلها من قبل المتصفح، وبالتالي فتخفيف حجم الملفات المطلوبة يمكن أن يسرّع من عرض صفحة الويب، ويوفّر الكثير من المال على الأشخاص الذين يدفعون مقابل عرض الحزمة bandwidth المستهلكة. يعدّ gzip من البرامج المشهورة المستخدمة في ضغط البيانات، وبالإمكان إعداد خادوم Nginx لاستخدام gzip لضغط الملفات التي يتم تخديمها من قبل الخادوم قبل إرسالها للمتصفحات والتي ستقوم بدورها بفك الضغط عن الملفّات (تدعم جميع المتصفحات المشهورة فك ضغط gzip ويفترض أن تدعم -معظم- المتصفحات عمومًا هذه العملية) دون أي خسارة في دقة البيانات بعد فك الضغط، مستفيدة بذلك من تخفيف حجم البيانات المتبادلة ما بين خادوم الويب والمتصفح. ونظرًا لاختلاف الطرق التي تعمل بها خوارزميات الضغط عمومًا، وآلية عمل خوارزمية gzip خصوصًا، فإنّ بعض الملفات يمكن ضغطها بنسبة أكبر من بعضها الآخر. فعلى سبيل المثال، يتم ضغط الملفات النصيّة text بصورة جيّدة جدًا حيث قد تكون نتيجة الضغط أصغر بحوالي مرّتين من الحجم الأصلي. ومن ناحية أخرى، فالصور من نوع JPEG و PNG تأتي مضغوطة سلفًا بطبيعة الخوارزمية المنتجة لها وبالتالي لن نحصل على الكثير من الفائدة بعد تطبيق ضغط gzip عليها، وعلى اعتبار أن ضغط الملفّات يستهلك الكثير من مصادر الخادوم، فمن الأفضل أن يتم ضغط الملفّات التي تملك نسبة ضغط عالية. سنناقش في المقال كيفية إعداد خادوم Nginx المثبت على نظام تشغيل Ubuntu 14.04 ليستخدم gzip في الضغط لتخفيف حجم المحتوى المرسل إلى متصفّحي الموقع. المتطلبات الأولية نحتاج الأمور التالية قبل المتابعة: نظام تشغيل Ubuntu 14.04، مستخدم عادي بدون صلاحيات مدير نظام، لكنّه يملك صلاحية تنفيذ أمر sudo، يمكن مراجعة الإعداد الابتدائي لخادوم أوبونتو 14.04 لمزيد من المعلومات، نسخة Nginx مثبّته على النظام، ويمكنك اتباع هذا المقال لتثبيت Nginx للقيام بذلك. الخطوة الأولى: إنشاء ملفات تجريبية سنقوم في هذه الخطوة بإنشاء عدّة ملفات تجريبية في الجذر الافتراضي للمواقع المدارة من Nginx لاختبار ضغط gzip. ولتحديد الملف الذي سيتم تخديمه عبر الشبكة، يكتفي Nginx بالاعتماد على لاحقة الملف لتحديد نمط MIME الخاص به، عوضًا عن القيام بقراءة ترويسته وذلك بغية تنفيذ العملية بأسرع وقت ممكن. ونتيجة لهذا التصرّف فإن محتوى الملف لا يعود مهمًّا ويصبح من الممكن خداع Nginx بجعله يعتقد أن ملفًا فارغًا عبارة عن صورة، وملفًا آخر عبارة عن مستند css. في إعداداتنا التالية، لن يقوم Nginx بضغط الملفّات الصغيرة جدًا، لذا سنقوم بإنشاء ملفّات تجريبية يبلغ حجمها 1 كيلوبايت تمامًا. سيسمح هذا السيناريو بالتحقق فيما إذا كان Nginx يقوم بضغط الملفات التي من المفترض به القيام بضغطها. لنقم بإنشاء ملف بحجم 1 كيلوبايت وتسميته test.html في الجذر الرئيسي الافتراضي للمواقع المدارة من Nginx وذلك باستخدام أمر truncate عبر سطر الأوامر، كما في المثال التالي: $ sudo truncate -s 1k /usr/share/nginx/html/test.html لنقم بإنشاء المزيد من الملفّات التجريبية بنفس الطريقة: ملف صورة jpg، ملف css، وملف js. $ sudo truncate -s 1k /usr/share/nginx/html/test.jpg $ sudo truncate -s 1k /usr/share/nginx/html/test.css $ sudo truncate -s 1k /usr/share/nginx/html/test.js الخطوة الثانية: التحقق من التصرّف الافتراضي لـ Nginx سنقوم الآن بالتحقق من كيفية تصرّف Nginx عند ضغط الملفات التي قمنا بإنشائها توًّا. لنتحقق مما إذا سيتم تخديم ملف test.html بعد الضغط، سنقوم في الأمر التالي بطلب الملف من خادوم Nginx، ونخبره بأنّه لا مشكلة لدينا في الحصول على محتوى مضغوط باستخدام gzip وذلك بتمرير ترويسة HTTP مناسبة (Accept-Encoding: gzip). $ curl -H "Accept-Encoding: gzip" -I http://localhost/test.html سنحصل في جواب الخادوم على ما يشبه النص التالي: HTTP/1.1 200 OK Server: nginx/1.4.6 (Ubuntu) Date: Tue, 19 Jan 2016 20:04:12 GMT Content-Type: text/html Last-Modified: Tue, 04 Mar 2014 11:46:45 GMT Connection: keep-alive Content-Encoding: gzip ويمكن في السطر الأخير ملاحظة وجود ترويسة (Content-Encoding: gzip) والتي تخبرنا بأن المحتوى الذي حصلنا عليه قد تم ضغطه باستخدام gzip، ولكن كيف حصل ذلك دون أن نقوم بتفعيل gzip أولًا في Nginx؟ إنّ السبب خلف هذا هو أن الضغط باستخدام gzip مفعّل بشكل تلقائي في نسخة Nginx على نظام Ubuntu 14.04 بإعداداته الافتراضية. على الرغم من ذلك، فإن Nginx لن يقوم إلا بضغط ملفات HTML فقط، بينما يتم تخديم باقي أنواع الملفّات بدون ضغط، ويمكن التحقق من ذلك بطلب صورة بنفس الطريقة السابقة: $ curl -H "Accept-Encoding: gzip" -I http://localhost/test.jpg وسنحصل على رد مختلف قليلًا عن السابق: HTTP/1.1 200 OK Server: nginx/1.4.6 (Ubuntu) Date: Tue, 19 Jan 2016 20:10:34 GMT Content-Type: image/jpeg Content-Length: 0 Last-Modified: Tue, 19 Jan 2016 20:06:22 GMT Connection: keep-alive ETag: "569e973e-0" Accept-Ranges: bytes حيث نلاحظ عدم وجود ترويسة (Content-Encoding: gzip) وهذا يعني أن الملف تم إرساله لنا بدون ضغط. يمكن تنفيذ الاختبار ذاته مجدّدًا مع ملف test.css ومرّة أخرى سنحصل على الملف بدون ضغط. HTTP/1.1 200 OK Server: nginx/1.4.6 (Ubuntu) Date: Tue, 19 Jan 2016 20:20:33 GMT Content-Type: text/css Content-Length: 0 Last-Modified: Tue, 19 Jan 2016 20:20:33 GMT Connection: keep-alive ETag: "569e9a91-0" Accept-Ranges: bytes الخطوة الثالثة: تغيير إعدادات ضغط gzip في خادوم Nginx سنقوم الآن بتغيّير إعدادات Nginx ليتم ضغط ملفّات من أنواع أخرى عدا عن HTML، والتي من الممكن الاستفادة من نسبة الضغط المطبّقة عليها. سنقوم بفتح ملف إعدادات Nginx باستخدام محرر nano أو أي محرر آخر تفضّل استخدامه: $ sudo nano /etc/nginx/nginx.conf ومن ثم سنبحث عن كتلة إعدادات gzip التي ستبدو كما يلي: . . . ## # `gzip` Settings # # gzip on; gzip_disable "msie6"; # gzip_vary on; # gzip_proxied any; # gzip_comp_level 6; # gzip_buffers 16 8k; # gzip_http_version 1.1; # gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; . . . نلاحظ في الإعدادات السابقة أن الضغط بواسطة gzip مفعّل بشكل افتراضي بواسطة توجيه gzip on، بينما معظم الإعدادات الإضافية تم تعطيلها بإشارة التعليقات # في بداية السطر. سنقوم بإجراء بعض التعديلات على هذه الإعدادات مثل: تفعيل الإعدادات الإضافية من خلال حذف إشارة التعليقات # في بداية الأسطر، إضافة توجيه gzip_min_length 256; الذي يخبر Nginx ألّا يقوم بضغط الملفات التي يصغر حجمها عن 256 بايت، فهذا الحجم الصغير جدًا لن يحقق الفائدة المرجوّة بعد الضغط، ▪ إضافة توجيه gzip_types مع المزيد من أنماط الملفّات كخطوط الويب، الأيقونات والصور من نوع SVG. بعد إجراء التعديلات المذكورة سيبدو مقطع الإعدادات الجديد على النحو التالي: . . . ## # `gzip` Settings # # gzip on; gzip_disable "msie6"; gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_buffers 16 8k; gzip_http_version 1.1; gzip_min_length 256; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/vnd.ms-fontobject application/x-font-ttf font/opentype image/svg+xml image/x-icon; . . . قم بحفظ الملف وإغلاقه وتطبيق التعديلات من خلال إعادة تشغيل خادوم Nginx باستخدام الأمر: $ sudo service nginx restart الخطوة الرابعة: التحقق من الإعدادات الجديدة سنقوم الآن بالتحقق من أنّ الإعدادات التي قمنا بتغييرها وإضافتها تعمل على النحو المطلوب، ويمكن القيام بذلك من خلال إعادة تنفيذ الاختبارات المذكورة في الخطوة الثانية عبر استخدام أمر curl على كلّ من الملفّات التجريبية والتحقق من وجود ترويسة Content-Encoding: gzip في الخرج: $ curl -H "Accept-Encoding: gzip" -I http://localhost/test.html $ curl -H "Accept-Encoding: gzip" -I http://localhost/test.jpg $ curl -H "Accept-Encoding: gzip" -I http://localhost/test.css $ curl -H "Accept-Encoding: gzip" -I http://localhost/test.js من المفترض الآن أن تكون جميع الملفّات مضغوطة وتظهر ترويسة Content-Encoding: gzip في الخرج، عدا ملف الصورة test.jpg، وتكون الإعدادات المطبّقة صحيحة والاختبار ناجحًا إن تحقق هذا. الخلاصة إن تغيّير إعدادات Nginx لاستخدام ضغط gzip عملية سهلة جدًا لكن الفوائد المحقّقة ستكون كبيرة، فستوفّر الكثير على الزوّار الذين يملكون اتصالات محدودة بعرض الحزمة، وبالإضافة إلى ذلك ستحصل على تقييم أفضل في محرّكات البحث مثل Google من خلال تحقيق سرعة عرض أعلى للصفحة، حيث أن عامل سرعة عرض الصفحة بدأ يأخذ حيّزًا مهمًا من عملية التقييم في المواقع الحديثة وخوارزمية الضغط gzip هي خطوة كبيرة باتجاه تحسين النتيجة. ترجمة -وبتصرّف- للمقال How To Add the gzip Module to Nginx on Ubuntu 14.04 لصاحبه Mateusz Papiernik.
  17. يُعتبَر خادوم ويب Apache الوسيلة الأكثر شعبيةً لتقديم المحتوى على شبكة الإنترنت، حيثُ يستعمله أكثر من نصف مواقع الويب على الشبكة لقدرته الفائقة ومرونته العالية. يُقسِّم خادوم Apache وظائفَه والعناصر التي تُكوِّنه إلى عدة وحدات يُمكِن تخصيصها وإعدادُها بشكل مستقل. تُسمَّى الوحدة الأساسية - التي تُمثِّل نطاقًا Domain أو موقع ويب - مُستضيفًا افتراضيًا Virtual host. تُتيح المُستضيفات الافتراضية إمكانية استضافة عدة نطاقات أو مواقع ويب على نفس العنوان باستخدام آليةٍ للمطابقة بين مُستضيف افتراضي وموقع ويب. تُناسِب هذه الطّريقة أي شخص يُريد استضافة عدة مواقع على نفس الخادوم الافتراضي الخاص Virtual private server, VPS. يُوجِّه كل واحد من النطاقات المضبوطة الزائرَ إلى مجلَّد مُحدَّد توجد به معلومات الموقع المطلوب دون أن يُشيرَ أبدًا إلى أن مواقع أخرى تُدار على نفس الخادوم. يُمكِن بطريقة المستضيفات الافتراضية ضبط عدد غير محدود من المواقع على نفس الخادوم ما دام يتحمّل عبئ الحِمل Load الذي تُمثِّله هذه المواقع. سنعرِض في هذا المقال طريقة إعداد مستضيفات افتراضية على خادوم ويب Apache يعمل على خادوم افتراضي خاص مع توزيعة أوبنتو 14.04. ستتعلَّم كيف تُقدِّم محتوى مختلِفا لزوّار متعدِّدين حسب النطاق الذي يطلبونه. المتطلباتقبل البدء في هذا الدّرس يجب إنشاء مستخدم آخر غير المستخدِم الجذر Root user كما هو موضَّح في الخطوات من 1 إلى 4 من الدرس الإعداد الابتدائي لخادوم أوبنتو. ستحتاج أيضًا إلى تثبيت خادوم ويب Apache لمتابعة الخطوات المذكروة في هذا الدّرس. إن لم تكُن ثبَّت البرنامج حتى الآن يُمكنك ذلك باستخدام أداة apt-get كما يلي: sudo apt-get update sudo apt-get install apache2بعد استكمال هذه الخطوات يُمكننا البدء. سنُنشئ خلال هذا الدرس مستضيفَيْن افتراضييْن، واحد للنطاق example.com والآخر لـ test.com. أثناء إعداد مستضيفاتك الافتراضية استخدِم النطاقات الخاصّة بك مكان المثاليْن المذكوريْن هنا. سنُريك خلال هذا الدّرس كيف تُحرِّر ملف المستضيفات على جهازك الشخصي Local hosts file لاختبار إعداداتك إن كنتَ تستخدم نطاقات وهمية. ستتمكَّن بهذه الطريقة من تجربة الإعدادات من جهازك الشخصي رغم أن المحتوى لن يكون مُتاحا لزوّار آخرين عبر النطاق الوهمي. الخطوة الأولى - أنشئ بنية المجلد Directory structureأول خطوة نقوم بها هي إنشاء بنية المجلَّد الذي سيحوي بيانات الموقِع الذي ننوي تقديمه إلى الزّوّار. يُعرَّف مبدأ المستند Document root بأنه المجلّد الأعلى مستوًى Top-level directory الذي سيبحث فيه خادوم وب Apache عن محتوى الموقع. بالنسبة لمثالنا سننشئ مبدأ مستند (مجلَّد) داخل المسار var/www/ لكلٍّ من المستضيفين الافتراضيّين الذين نعدهما. داخل كل من المجلَّدين نُنشئ مجلَّدًا باسم public_html، وهو المجلَّد الذي سيحوي ملفات الموقع وهو ما يمنح بعض المرونة في الاستضافة. لتطبيق ما ورد في الفقرة أعلاه نُنفِّذ الأوامر التالية: sudo mkdir -p /var/www/example.com/public_html sudo mkdir -p /var/www/test.com/public_htmlفي الأمرين السابقين يظهر كل من النطاقين الذين نريد تقديمهما من خادومنا الافتراضي الخاص باللون الأحمر. الخطوة الثانية - امنح الأذونات Permissionsأنشأنا في الخطوة الأولى بنية المجلَّدات، لكن هذه المجلَّدات مملوكة من المستخدِم الجذر، نظرا لاستخدام sudo أمام أمر إنشاء المجلّد. إن أردنا إعطاء المستخدِم العادي القدرة على تحرير الملفات الموجودة في مجلَّد الوب فبإمكاننا تغيير مُلكية هذه المجلّدات عن طريق الأمر: sudo chown -R $USER:$USER /var/www/example.com/public_html sudo chown -R $USER:$USER /var/www/test.com/public_htmlعند تنفيذ الأمر - بالضغط على زر Enter - فإن المتغيّر USER$ سيُبدَل بقيمته وهي اسم المستخدِم الحالي. ينتج عن الأمر تغيير ملكية المجلَّد public_html الذي يتضمّن محتوى الموقِع فيُصبِح المستخدم الحالي هو المالك بدلا من المستخدِم الجذر. سيتوجّب علينا أيضًا تغيير الأذونات قليلًا للتأكد من أنّ إذن القراءة متاح من مجلّد الويب العام (var/www/) وكل الملفات الموجودة داخله أو داخل المجلّدات المتفرّعة منه حتى يُقدَّم المحتوى بشكل صحيح: sudo chmod -R 755 /var/wwwلدى خادوم الويب الآن الأذونات التي يحتاجها لتقديم المحتوى، ولدى المستخدم أيضا القدرة على إنشاء وتحرير المجلَّدات التي يحتاجها. الخطوة الثالثة - أنشئ صفحات تجريبية Demo pages لكل مستضيف افتراضيفي هذه الخطوة سننشئ محتوى لتقديمه. الهدف من إنشاء المحتوى في هذه الخطوة توضيحي، لذا ستكون الصفحات بسيطة جدا: index.html لكل موقع. سنبدأ بـ example.com. نستطيع إنشاء وتحرير ملف index.html عن طريق محرِّر nano عبر الأمر التالي: nano /var/www/example.com/public_html/index.htmlأضف مستنَد HTML بسيطًا يُبرز اسم الموقع. يظهر الملف بالشكل التالي: <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title> Example.com أهلًا بك في موقع</title> </head> <body dir="rtl"> <h1>هنيئا لك! المُستضيف الافتراضي Example.com يعمل بشكل صحيح</h1> </body> </html>احفظ الملف (Ctrl+O ثم زر Enter) ثم أغلقه بعد الانتهاء من تحريره (Ctrl+x). ننسخ الملف ليكون أساس الموقع الثاني عبر الأمر : cp /var/www/example.com/public_html/index.html /var/www/test.com/public_html/index.htmlيُمكِن بعدها فتح الملف وتحرير المعلومات لتُناسب الموقع الثاني: nano /var/www/test.com/public_html/index.html<html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title> Test.com أهلًا بك في موقع</title> </head> <body dir="rtl"> <h1>هنيئا لك! المُستضيف الافتراضي Test.com يعمل بشكل صحيح</h1> </body> </html>احفظ الملف ثم أغلقه. لدينا الآن الصفحات الضرورية لاختبار إعداد المستضيف الافتراضي. الخطوة الرابعة - أنشئ ملفات مستضيفات افتراضية جديدةتُحدِّد ملفات المستضيفات الافتراضية إعدادات هذه المستضيفات كما أنها تُملي على خادوم ويب Apache الكيفية التي سيُجيب بها على طلبات النطاقات المختلفة. يأتي خادوم Apache بملف ابتدائي اسمه 000-default.conf لإعداد المستضيفات الافتراضية. يُمكننا استخدام هذا الملف للبدء، لذا سننسخ هذا الملف لإعداد المستضيفات الافتراضية الخاصة بنطاقاتنا. سنبدأ بإعداد أحد النطاقات ثم ننسخه إلى النطاق الثاني مع القيام بالتعديلات اللازمة. يجب - في الإعداد المبدئي لأوبنتو - أن ينتهي ملف المستضيف الافتراضي بالامتداد conf. أنشئ ملف المستضيف الافتراضي الأول. ابدأ بنسخ ملف النطاق الأول: sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/example.com.confافتَح الملف الجديد في المحرِّر بامتيازات المستخدِم الجذر : sudo nano /etc/apache2/sites-available/example.com.confسيبدو الملف بالشكل التّالي (حُذِفت التعليقات لجعل الملف أسهل للقراءة): <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>احفظ الملف ثم أغلقه بعد الانتهاء من تحريره. الخطوة الخامسة - فعل ملفات المستضيفات الافتراضية الجديدةبعد إنشاء ملفات إعداد المستضيفات الافتراضية نأتي لخطوة التفعيل؛ يوفِّر خادوم Apache بعض الأدوات لهذا الغرض. لتفعيل الموقعيْن نستخدم أداة a2ensite كما يلي: sudo a2ensite example.com.conf sudo a2ensite test.com.confثم نعيد تشغيل Apache لأخذ التغييرات بالاعتبار: sudo service apache2 restartأثناء إعادة تشغيل خادوم الوب قد تظهر رسالة كالتالية: * Restarting web server apache2 AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this messageلا يُمثِّل هذا التحذير أي خطر وليس له تأثير على موقعك. الخطوة السادسة - اضبط ملف المستضيفات المحلي (خطوة اختيارية)إن لم تتوفّر لديك أسماء نطاقات حقيقية لتجربة الخطوات المذكورة في هذا الدّرس يُمكنك اختيار نطاقات وهمية والتجربة بها على جهاز ك المحلي (الشخصي) عن طريق التعديل المؤقَّت على ملف المستضيفات المحلي. ستُوَجَّه كل طلبات النطاقات المضبوطة بهذه الطريقة إلى خادومك الافتراضي الخاص، تماما كما كان سيفعل نظام أسماء النِّطاقات Domain Name System, DNS لو استخدمتَ أسماء نطاقات مُسَجَّلة. ينبغي الانتباه أن هذه الطريقة ستعمل من جهازك الشخصي فقط وتقتصر على اختبار الإعدادات. تأكَّد من القيام بالخطوات التالية على جهازك المحلي وليس على خادومك الافتﻻاضي الخاص. ستحتاج لمعرفة كلمة سر اسم المستخدِم الجذر أو أن تكون ضمن مجموعة المديرين على نظام التشغيل. الأمر التالي يفتح ملف المستضيفات للتحرير على أنظمة Linux و Mac: sudo nano /etc/hostsبالنسبة لمستخدمي Windows توجد تعليمات التعديل على ملف المستضيفات هنا. ستحتاج لعنوان IP العمومي لخادومك الافتراضي الخاص والنطاق الذي تُريد استخدامه للوصول إلى الخادوم الافتراضي. يتكوَّن سطر ملف الإعداد من عنوان IP متبوعًا باسم النطاق. باعتبار أن 111.111.111.111 هو عنوان IP الخادوم نُضيف الأسطر التالية في أسفل ملف المستضيفات: 127.0.0.1 localhost 127.0.1.1 guest-desktop 111.111.111.111 example.com 111.111.111.111 test.comبهذه الطّريقة ستُوجَّه كل استعلامات الجهاز المحلي التي تطلُب النِّطاقين example.com أو test.com إلى الخادوم على العنوان 111.111.111.111، وهو ما يُساعدنا على اختبار إعدادات خادوم الوب إن لم نكن مالِكي النطاقيْن المذكوريْن. احفَظ الملف ثم أغلِقه. الخطوة السابعة - اختبر النتائجيُمكنك بعد الانتهاء من ضبط المُستضيفات الافتراضية اختبار الإعدادت بالذهاب إلى النطاقات المضبوطة عبر متصفِّح الوب: http://example.comيجب أن تكون النتيجة كما في الصّورة: الشيء بالنسبة للموقع الآخر: http://test.comستظهر الصّفحة التي أنشأتَها في الملف الثاني: يدل ظهور الصفحتين بشكل صحيح أن إعداد مستضيفيْن افتراضيّيْن على نفس الخادوم جرى بطريقة جيّدة. لا تنسَ حذف الأسطر الإضافية من ملف المستضيفات المحلي بعد التأكد من إعداد المستضيفات الافتراضية على الخادوم. أُضيفت هذه الأسطُر للاختبار فقط ومن الأحسن حذفها بعد انتهائه. ستحتاج إلى شراء وإعداد نطاقات إن احتجتَ دائما إلى خادومك عن طريق أسماء نطاقات. خاتمةستحصُل بعد متابعة هذا الدّرس على خادوم ويب واحد يتعامل مع نطاقيْن منفصلين. يُمكنك زيادة عدد النطاقات باتّباع الخطوات المذكورة أعلاه لإنشاء مستضيفات افتراضية جديدة. لا توجد تقييد على عدد النطاقات التي يُمكِن لـApache التعامل معها، أضِف ما تُريد من النطاقات ما دام الخادوم يستطيع تحمّلَها. ترجمة -وبتصرّف- للمقال How To Set Up Apache Virtual Hosts on Ubuntu 14.04 LTS لصاحبه Justin Ellingwood.
  18. تنفيذ جدار الحماية هو خطوة هامة في تأمين الخادوم الخاص بك. جزء كبير من عملية التنفيذ هو اتخاذ قرارات بشأن القواعد والسياسات التي تفرض قيودا على حركة مرور البيانات. يسمح لك الجدار الناري أن يكون لك دور في بنية إطار العمل الذي يتم فيه تطبيق القواعد الخاصة بك. في هذا الدليل سوف نبني جدار حماية ليكون أساسا للمزيد من القواعد المعقدة. وسيركز هذا الجدار الناري في المقام الأول على تقديم افتراضات معقولة ووضع إطار سهل التمدد. سيكون تطبيق هذا الدليل على أوبنتو 14.04. المتطلبات الأساسية قبل أن تبدأ يجب أن تكون لك فكرة قاعدية حول سياسات جدار الحماية التي ترغب في تنفيذها. يمكنك اتباع هذا الدليل للحصول على فكرة أفضل عن بعض الأشياء التي يجب أن تنظر فيها. سوف تحتاج إلى أن يكون لك حق الوصول إلى خادوم أوبنتو 14.04 بمستخدم عادٍ يكون له صلاحيات الجذر. تثبيت خدمة جدار الحماية الثابتة لكي نبدأ نحتاج إلى تثبيت الحزمة iptables-persistent إذا لم تكن قد فعلت ذلك من قبل. سيسمح هذا لنا بحفظ مجموعات القواعد ويجعل تنفيذها تلقائيا عند تشغيل النظام: sudo apt-get update sudo apt-get install iptables-persistent أثناء التثبيت سوف تُسأل عما إذا كنت تريد حفظ القواعد الحالية الخاصة بك، أجب بنعم. سوف نقوم بتحرير ملفات القواعد المولدة لاحقا. ملاحظة حول IPv6 قبل أن نبدأ يجب أن نتحدث بإيجاز عن عناوين IPv4 و IPv6. تعالج أوامر iptables فقط المرور عبر IPv4. وأما حركة المرور عبر IPv6 فيتم باستخدام أداة منفصلة تسمى ip6tables. يتم تخزين القواعد في جداول وسلاسل منفصلة. بالنسبة لـ iptables-persistent فتتم كتابة قواعد IPv4 في الملف etc/iptables/rules.v4/ وقواعد IPv6 في الملف etc/iptables/rules.v6/. يفترض هذا المقال أنك لا تستخدم البروتوكول IPv6 على الخادوم الخاص بك. إذا كان الأمر كذلك فالأكثر أمانا هو منع الوصول عبره تماما، وذلك ما سنقوم به في هذه الدليل. تنفيذ السياسات الأساسية لجدار الحماية (الطريق الأسرع) من أجل تنفيذ تلك السياسات على جدار الحماية في أسرع وقت ممكن سوف ندلك على ملف إعدادات يحتوي تلك السياسات، ثم ما عليك بعدُ إلا بالنسخ واللصق. بعد ذلك سوف نشرح الاستراتيجية العامة ونبين لك كيف يمكن تنفيذ هذه القواعد باستخدام أوامر iptables بدلا من تعديل الملف. لتنفيذ سياسات جدار الحماية وإطار العمل الخاص به سوف نقوم بتحرير الملفين etc/iptables/rules.v4/ و etc/iptables/rules.v6/. افتح أولا الملف rules.v4 في محرر النص المفضل لديك بصلاحيات الجذر: sudo nano /etc/iptables/rules.v4 سترى داخل هذا الملف مثل هذه الأسطر: # Generated by iptables-save v1.4.21 on Tue Jul 28 13:29:56 2015 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT # Completed on Tue Jul 28 13:29:56 2015 اُمحُ هذا المحتوى واستبدله بالمحتوى التالي: *filter # Allow all outgoing, but drop incoming and forwarding packets by default :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] # Custom per-protocol chains :UDP - [0:0] :TCP - [0:0] :ICMP - [0:0] # Acceptable UDP traffic # Acceptable TCP traffic -A TCP -p tcp --dport 22 -j ACCEPT # Acceptable ICMP traffic # Boilerplate acceptance policy -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A INPUT -i lo -j ACCEPT # Drop invalid packets -A INPUT -m conntrack --ctstate INVALID -j DROP # Pass traffic to protocol-specific chains ## Only allow new connections (established and related should already be handled) ## For TCP, additionally only allow new SYN packets since that is the only valid ## method for establishing a new TCP connection -A INPUT -p udp -m conntrack --ctstate NEW -j UDP -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP -A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP # Reject anything that's fallen through to this point ## Try to be protocol-specific w/ rejection message -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -j REJECT --reject-with icmp-proto-unreachable # Commit the changes COMMIT *raw :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT *security :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT احفظ ثم أغلق الملف. يمكنك اختبار الملف من أجل اكتشاف الأخطاء التي يمكن أن تكون في التركيب بالأمر التالي: sudo iptables-restore -t /etc/iptables/rules.v4 يجب عليك إصلاح أي خطأ يظهر لك قبل المتابعة. بعد ذلك افتح الملف etc/iptables/rules.v6/ من أجل تعديل قواعد IPv6: sudo nano /etc/iptables/rules.v6 يمكننا أن نمنع كل الحزم التي تستخدم البروتوكول IPv6 باستبدال محتوى الملف بالإعدادات التالية: *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] COMMIT *raw :PREROUTING DROP [0:0] :OUTPUT DROP [0:0] COMMIT *nat :PREROUTING DROP [0:0] :INPUT DROP [0:0] :OUTPUT DROP [0:0] :POSTROUTING DROP [0:0] COMMIT *security :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] COMMIT *mangle :PREROUTING DROP [0:0] :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] :POSTROUTING DROP [0:0] COMMIT احفظ ثم أغلق الملف. من أجل اختبار الملف ومعرفة إن كان فيه أخطاء نستعمل الأمر ip6tables-restore مع الخاصية t-: sudo ip6tables-restore -t /etc/iptables/rules.v6 إذا لم نجد أي خطأ في الملفين السابقين فلْنطبق تلك القواعد بتنفيذ الأمر: sudo service iptables-persistent reload سيقوم هذا الأمر بتنفيذ السياسات التي يتضمنها الملفان فورا. يمكنك التأكد من ذلك بسرد قواعد iptables الحالية بالأمرين: sudo iptables -S sudo ip6tables -S سوف يعاد تطبيق هذه القواعد في كل إقلاعٍ للنظام. تأكد أنه يمكنك الولوج عبر المنفذ 22 وأن كل المنافذ الأخرى محجوبة. شرح لاستراتيجيتنا العامة في الجدار الناري لقد أنشانا في جدار الحماية القاعدي الذي قمنا ببنائه مع القواعد السابقة أنشأنا إطارَ عمل قابلا للتمدد يمكّنك من إضافة قواعد جديدة أو حذفها بسهولة. أما حركة المرور التي تستخدم العنوان IPv4 فقد عالجناها في السلسلة INPUT داخل الجدول filter table ( تعالج هذه السلسلة كل الحزم التي تصل إلى خادومنا) فسمحنا بخروج الحزم من خادومنا ومنعنا إعادة توجيهها -إذ كان ذلك مناسبا فقط في حال كان الخادوم يعمل موجها router لخوادم أخرى- وقبِلنا الحزم على الجداول الأخرى بما أن نظرنا محصور في filter table في هذا الدليل. عموما تقوم القواعد التي طبقناها على الجدار الناري بمنع الحزم من الوصول إلى خادومنا افتراضيا ، سيكون علينا أن نضع استثناءات من أجل الحزم التي نريدها أن لا تدخل في سياسة الحجب. في السلسلة INPUT الرئيسة أضفنا بعض القواعد العامة لحركة المرور التي نثق بها. ما نريده الآن هو حجب كل الحزم التي نعتبرها غير صالحة ونسمح للحزم على واجهة الاسترجاع المحلية local loopback interface والبيانات المرتبطة باتصال مؤسس established connection. بعد ذلك نقوم بمسك البيانات حسب البروتوكول الذي تستخدمه ونمزجها بسلاسل البروتوكول المخصص protocol-specific. تهدف هذه السلاسل إلى التعامل مع القواعد المتعلقة بها والسماح لحركة المرور الصادرة والقادمة إلى الخدمات المعينة. في هذا المثال الخدمة الوحيدة التي قمنا بربطها في سلسلتنا ذات البروتوكول TCP هي SSH. إذا كنا نعرض خدمة أخرى كخادوم (HTTP(S يمكننا إضافة استثناءات لها أيضا. كل حركةٍ للمرور لا تتناسب مع القواعد العامة أو قواعد الخدمات في البروتوكول المحدد protocol-specific سوف تتم معالجتها بالقواعد الموجودة في آخر سلسلة INPUT. لقد جعلنا السياسة الافتراضية للجدار الناري هي الإسقاط DROP، وذلك سيحجب الحزم التي لا تتصف بمعايير السماح حسب قواعدنا. تمنع هذه القواعد في نهاية السلسلة INPUT الحزم وترسل رسالة إلى العميل تحاكي ما يرسله الخادوم في حالِ لم تكن الخدمة متوفرة على ذلك المنفذ. وأما العنوان IPv6 فإن حركة المرور سوف تُحجَب كلها لأن خادومنا لا يستخدمه، ولأنه من الآمن فعل ذلك لكي لا نتورط في حركة المرور بشكل عام. تحديث nameservers (اختياري) يمكن لحركة المرور المحجوبة على العنوان IPv6 أن تتداخل وطريقةُ تعامل الخادوم مع الأشياء في الأنترنت. مثلا يمكن لذلك أن يؤثر في استخدام الأمر APT. إذا ظهر لك خطأ مثل هذا في حال نفذت الأمر apt-get update: Err http://security.ubuntu.com trusty-security InRelease Err http://security.ubuntu.com trusty-security Release.gpg Could not resolve 'security.ubuntu.com' . . . فينبغي عليك أن تتبع هذه الطريقة لكي تجعل APT يعمل مرة أخرى. أولا اضبط nameservers الخاصة بخادومك إلى nameservers الخارجية، سنستخدم في حالتنا nameservers الخاصة بغوغل. افتح الملف etc/network/interfaces/ من أجل تعديله بالأمر: sudo nano /etc/network/interfaces ثم عدل السطر الذي أوله dns-nameservers على الطريقة التالية: . . . iface eth0 inet6 static address 2604:A880:0800:0010:0000:0000:00B2:0001 netmask 64 gateway 2604:A880:0800:0010:0000:0000:0000:0001 autoconf 0 dns-nameservers 8.8.8.8 8.8.4.4 حدّث إعدادات الشبكة بالأمر: sudo ifdown eth0 && sudo ifup eth0 الناتج المتوقع هو: RTNETLINK answers: No such process Waiting for DAD... Done بعد ذلك أنشئ قاعدة جديدة من أجل إرغام حركة المرور أن تستخدم العنوان IPv4 متى كان ذلك ممكنا. أنشئ هذا الملف الجديد: sudo nano /etc/apt/apt.conf.d/99force-ipv4 ثم أضف هذا السطر إليه: Acquire::ForceIPv4 "true"; احفظ ثم أغلق، ينبغي أن تكون الآن قادرا على استخدام ATP. تنفيذ الجدار الناري باستخدام أوامر IPTables لقد تبين لك كيف قمنا بتنفيذ الجدار الناري وسياساته وعرفت كيف تعمل، في المرحلة القادمة سنقوم بتطبيق تلك السياسات باستخدام أوامر iptables وسنحصل في الأخير على ما حصلنا عليه فيما سبق. ولكن سيكون إضافة تلك السياسات واحدة تلو الأخرى لأن iptables يطبق كل قاعدة في وقت تنفيذ الأمر ، لذلك فإن ترتيب القواعد مهم جدا (سوف ندع القواعد التي تحجب إلى النهاية). إعادة ضبط الجدار الناري سنبدأ بإعادة ضبط الجدار الناري لكي نستطيع بناء السياسات من سطر الأوامر . يمكنك إلغاء القواعد السابقة بالأمر: sudo service iptables-persistent flush تأكد أن الجدار الناري أعيد ضبطه بالأمر: sudo iptables -S سترى أن القواعد في الجدول filter table قد اختفت وأن السياسات الافتراضية قد أُعدت للوضع ACCEPT في كل السلاسل: -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT إنشاء سلاسل البروتوكول المخصص سنبدأ بإنشاء سلاسل البروتوكول المخصص protocol-specific. ستُستعمل هذه السلاسل للتحكم في القواعد التي تُنشِئ استثناءات في سياسات الحجب فتجعل خدماتنا ظاهرة في الشبكة. سوف ننشئ واحدة من أجل البروتوكول UDP ، واحدة للبروتوكول TCP وواحدة للبروتوكول ICMP: sudo iptables -N UDP sudo iptables -N TCP sudo iptables -N ICMP يمكننا الذهاب قدما فنضيف استثناء للخدمة SSH التي تستخدم البروتوكول TCP. سيكون ذلك بقبول حركة المرور على المنفذ 22 الخاص بالخدمة SSH: sudo iptables -A TCP -p tcp --dport 22 -j ACCEPT إذا كنت تريد إضافة استثناءات لخدمات أخرى تستخدم البروتوكول TCP فما عليك سوى تكرار الأمر السابق مع تغيير رقم المنفذ الذي تستخدمه الخدمة. إنشاء قواعد للأغراض العامة للحجب والقبول في السلسلة INPUT -حيث تفلتر كل الحزم القادمة- نحتاج إلى إضافة قواعد للأغراض العامة. تشكل تلك القواعد حجر الأساس للجدار الناري وتتبع المنطق السليم إذ تقبل حركة المرور الأقل خطورة (حركة المرور المحلية أو التي تأكدنا من موثوقية مصدرها) وتحجب تلك الموصوفة بأنها غير صالحة. أولا سننشئ استثناء لكي نقبل كل الحزم التي هي جزء من اتصال مؤسَّس established connection أو لها علاقة باتصال مؤسس: sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT تستخدم هذه القاعدة الملحق conntrack الذي يقدم سياقا يحتاج إليه iptables لمعالجة حزم الاتصالات الكبيرة بدل استخدامه للبيانات المنفصلة. TCP هو بروتوكول اتصال ، لذلك فإن كونه اتصالا مؤسَّسا لا غبار عليه. وأما UDP والبروتوكولات عديمة الاتصال فالاتصال المؤسس يشير إلى الحزم التي ترى جوابها (مصدر الحزمة هو نفسه الهدف المقصود والعكس بالعكس ). وأما الاتصالات ذات الصلة فتشير إلى اتصال جديد يُربط مع اتصال مؤسس. المثال الكلاسيكي هنا هو اتصال نقل البيانات ftp، حيث يربط هذا الاتصال الجديد بالاتصال المؤسس سابقا وهو FTP control connection. نريد أيضا أن نسمح لحركة المرور التي نشأت على واجهة الاسترجاع المحلية local loopback interface. هذه الحزم وُلّدت من قبل الخادوم ومتجهة إلى الخادوم نفسه. يتم استخدامها من قبل الخدمات على جهاز النظام للتواصل مع بعضها البعض: sudo iptables -A INPUT -i lo -j ACCEPT وأخيرا نريد حجب كل الحزم غير الصالحة. تكون الحزم غير صالحة للعديد من الأسباب. منها التي تكون وجهتها اتصالات أو عناوين أو منافذ غير موجودة، أو ببساطة لم يَحسُن تهيئتها. في كل الأحوال سوف نمنع أمثال هذه الحزم لأنه لا سبيل إلى معالجتها أو لأنها مغلفة لشيفرات خبيثة: sudo iptables -A INPUT -m conntrack --ctstate INVALID -j DROP إنشاء الانتقال السريع إلى سلاسل البروتوكول المخصص حتى الآن لقد أنشأنا بعض القواعد العامة في سلسلة INPUT وبعض القواعد للخدمات المقبولة في سلاسل البروتوكول المخصص. ومع ذلك فالبيانات القادمة إلى السلسلة INPUT ليس لديها وسيلة للوصول إلى تلك السلاسل. نحن بحاجة إلى توجيه حركة البيانات في سلسلة INPUT إلى سلاسل البروتوكول المخصص التي تناسبها. يمكننا البحث عن نوع البروتوكول لكي نعرف أي سلسلة تناسب هذه الحزمة. ويجب التأكد من أن الحزمة تمثل اتصالا جديدا (يفترض أنه تم بالفعل التعامل مع أي اتصال مؤسس أو له علاقة به). بالنسبة لحزم TCP سوف نقوم بإضافة شرط إضافي وهو أن تكون الحزمة SYN، والذي هو النوع الوحيد الصالح لبدء اتصال TCP: sudo iptables -A INPUT -p udp -m conntrack --ctstate NEW -j UDP sudo iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP sudo iptables -A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP رفض كل حركة المرور الأخرى إذا كانت الحزمة التي تم تمريرها الى سلسلة البروتوكول المخصص لم تعثر على أية قواعد فسيتم إعادة التحكم بها إلى السلسة INPUT. ما يصل إلى هذا النقطة ينبغي أن لا يسمح به جدار الحماية. سوف نحجب حركة المرور باستخدام الهدف REJECT الذي يرسل رسالة رد إلى العميل. و يتيح هذا لنا تحديد الرسائل الصادرة حتى نتمكن من محاكاة الرد كما لو كان العميل حاول إرسال الحزم إلى المنافذ المغلقة. يكون الرد حسب البروتوكول الذي يتم استخدامه من قبل العميل. محاولة الوصول إلى منفذ UDP المغلق يؤدي إلى رسالة ICMP مضمونها "لا يمكن الوصول إلى المنفذ” ، يمكننا محاكاة ذلك بتنفيذ الأمر: sudo iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable محاولة إنشاء اتصال TCP على منفذ مغلق سيؤدي إلى جواب TCP RST: sudo iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset وأما جميع الحزم الأخرى فيمكننا إرسال رسالة ICMP "تعذر الوصول إلى البروتوكول" للإشارة إلى أن الخادوم لا يرد على حزم من هذا النوع: sudo iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable ضبط السياسات الافتراضية آخر ثلاث قواعد أضفناها ينبغي أن تتعامل مع جميع ما تبقى من حركة البيانات في السلسلة INPUT. ومع ذلك ينبغي لنا أن ننشئ السياسات الافتراضية للإسقاطـ DROP كإجراء احترازي. وينبغي أيضا أن تُحدد هذه السياسة في سلسلة FORWARD إذا لم يتم استخدام هذا الخادوم جهازَ توجيه إلى أجهرة أخرى: sudo iptables -P INPUT DROP sudo iptables -P FORWARD DROP تحذير مع إعدادك لسياسات الجدار الناري إلى DROP يكون استعمالك للأمر sudo iptables -F لغرض مسح iptables مسقطا لاتصال SSH الحالي ، الأحسن من ذلك أن تقوم بمسحه بالأمر sudo iptables-persistent flush، لأن ذلك سيعيد ضبط الجدار النار إلى الحال الفتراضي. ولكى نجعل سياسة IPv6 هي إسقاط كل حركةٍ للمرور يمكننا تنفيذ الأوامر التالية: sudo ip6tables -P INPUT DROP sudo ip6tables -P FORWARD DROP sudo ip6tables -P OUTPUT DROP ينبغي لهذه الأوامر أن تكرر القواعد التي أعددناها سابقا بشكل موثوق. حفظ قواعد IPTables في هذه المرحلة يجب فحص قواعد جدار الحماية للتأكد من أنها تمنع حركة المرور التي تريد منعها وتسمح لما تريد السماح له. عندما تكون متأكدا من أن الجدار الناري والقواعد يعملان بشكل صحيح يمكنك حفظ تلك القواعد ليتم تطبيقها عند كل إقلاع للنظام. يمكنك حفظ قواعد كل من IPv4 و IPv6 بتنفيذ الأمر: sudo service iptables-persistent save سيقوم هذا الأمر بالكاتبة فوق الملفين etc/iptables/rules.v4/ و etc/iptables/rules.v6/ بالسياسات التي نفذتها من خلال سطر الأوامر. الخلاصة باتباعك هذا الدليل -سواء من خلال وضع قواعد جدار الحماية مباشرة في ملفات الإعدادات أو يدويا باستخدام سطر الأوامر - قمتَ بإنشاء منطلق جيد لإعدادات الجدار الناري. يبقى عليك أن تضيف قواعد خاصة بك لتسمح بالوصول إلى خدماتك الأخرى على الخادوم. يسمح لك إطار العمل الذي أسسناه في هذا الدليل بأن تعدل كيفما تشاء ، وأيضا يجعل السياسات الموجودة أكثر وضوحا. ترجمة -وبتصرّف- للمقال How To Implement a Basic Firewall Template with Iptables on Ubuntu 14.04 لصاحبه Justin Ellingwood.
  19. إدارة الحزم هي أحد الميزات الرئيسة التي تتحفنا بها توزيعات أنظمة لينكس. طريقة التحزيم وأدوات إدارة الحِزم تختلف من توزيعة إلى أخرى، رغم ذلك ظهرت مجموعتان وتم تصنيفهما الأكثر انتشارًا. بخصوص التوزيعات المبنية على ريدهات لينكس، فإنها تستخدم أدوات RPM مثل rpm و yum. أما المجموعة الأخرى والتي يتم استخدامها من قِبل دبيان ، أوبنتو ، والتوزيعات ذات العلاقة، فإنها تستخدم هيئة التحزيم بطريقة deb وأدوات مثل apt و dpkg. سيُعني المقال بمناقشة هذه المجموعة الأخيرة. ما الذي سيغطيه هذا المقال سيغطي هذا المقال أدوات إدارة الحِزم على مستوى المستخدم، والتي تستخدم غالبًا في أنظمة دبيان وأوبنتو، لن يتم تغطية الأدوات الضرورية لإنشاء الحِزم بسبب الآراء المتباينة حول السياسات بين مختلف التوزيعات والتعقيدات المتضمنة بأمثلة لها اعتبارها. سوف نناقش كل أداة متاحة بشكل منفرد في ملخص أدوات إدارة نظام الحِزم في دبيان، لكن أغلبية هذا المقال سيكون مرتبًا حسب الوظيفة وليس حسب الأداة؛ حيث أن هذا المقال يعتبر مرجعًا وظيفيًا. لتحقيق الاستفادة القصوى من هذا المقال يرجى وضع النقاط التالية في الاعتبار: إذا كنت مبتدئًا في أدوات إدارة الحِزم في دبيان يرجى قراءة ملخص أدوات إدارة الحِزم في دبيان أدناه، هذا القسم سيوفر لك ملخصًا شاملا عن ميّزات كل أداة، وكيف ترتبط ببعضها. استخدم كل قسم من هذا المقال كضرورة للوصول لما تريده. هذا المقال ليس إجرائيًا؛ لذا لك الحرية في الوصول إلى ما تراه مناسبًا لك. قم بنسخ ولصق أمثلة الأوامر المعطاة، مع استبدال القيم المذكورة بالقيم الخاصة بك. نظرة عامة حول أدوات إدارة الحزم الخاصة بدبيان نظام البيئة المتاح في دبيان / أوبنتو يستخدم أدوات إدارة حِزم مختلفة إلى حدِ ما لإدارة البرامج في النظام. أغلب هذه الأدوات غير مترابطة، وتعمل على نفس قاعدة البيانات للحزمة، بعض هذه الأدوات يحاول تقديم واجهات ذات مستوى عالٍ لأنظمة الحِزم، بينما تركّز أدوات أخرى على تزويد وظيفة في مستوى متدنّي. Apt-get يعتبر الأمر Apt-get الأكثر استخدامًا من مجموعة apt، هدفه الرئيسي هو عمل واجهة مع المستودعات البعيدة التي يتم الاحتفاظ بها من قِبل فريق الحِزم الخاص بالتوزيعة، بالإضافة إلى تنفيذ العمليات على الحِزم المتاحة. تعمل مجموعة apt بشكل عام عن طريق سحب المعلومات من المستودعات إلى الذاكرة المؤقتة التي يتم إدارتها من خلال النظام المحلي. الأمر apt-get يستخدم لتحديث الذاكرة المؤقتة المحلية، ويستخدم أيضًا للتعديل على حالة الحِزمة؛ نقصد تنصيب أو إزالة الحزمة من النظام. Apt-cache أحد الأوامر الأخرى المهمة في مجموعة apt هو الأمر apt-cache، والذي يستخدم الذاكرة المؤقتة المحلية ليستعلم عن المعلومات المتعلقة بالحِزم المتاحة في مستودعاته. على سبيل المثال، في أي وقت ترغب في البحث عن حزمة معينة أو أداة لتنفيذ وظيفة معينة، فإن الأمر apt-cache يُعتبر نقطة جيدة للبداية. يمكن أن تكون مفيدة أيضًا لمعرفة أيّ إصدار حزمة سيتم استخدامه من لأي إجراء. كما وتعتبر apt-cache مفيدة في حالة معلومات الاعتمادية، والاعتمادية العكسية. Aptitude يقوم الأمر aptitude بدمج الكثير من وظائف الأمرين المذكورين أعلاه، تتوفر فيه ميزة العمل كأداة سطر الأوامر حيث تدمج وظائف الأداتين المذكورتين أعلاه، وتستطيع أيضًا العمل باستخدام ncurses والتي تعتبر واجهة قائمة نصية. عند العمل من سطر الأوامر، العديد من الأوامر تقوم بتمثيل الإمكانيات الخاصة بـ apt-get و apt-cache بالضبط. لن نناقش aptitude باستفاضة في هذا المقال بسبب التداخل الواضح في وظائف الأوامر. إذا كنت تفضل هذه الأداة فإنك تستطيع دومًا استخدام aptitude بالمبادلة مع apt-get أو apt-cache. Dpkg بينما تركّز الأدوات السابقة على إدارة الحِزم المحفوظة في المستودعات، إلا أن الأمر dpkg يمكن استخدامه ليعمل على حزم deb. بشكل منفرد. هذا الأمر مسؤول بالضبط عن الأعمال التي تجري في كواليس الأوامر المذكورة أعلاه. Tasksel يعتبر برنامج tasksel نوعًا مختلفًا من أدوات إدارة البرامج. فبدلاً من إدارة الحزم أو حتى التطبيقات بشكل منفرد، فإن tasksel تركّز على تجميع البرامج المطلوبة لتنفيذ مهام محددة. يمكن اختيار المهام المنظمة باستخدام واجهة نصيَة، أو يمكن استهدافها مثلما تستهدف بعض الحِزم في أدواة الحزم المعتادة. تعتبر الأداة مفيدة جدًا للبداية والمضي قدمًا في العمل، بالرغم من أنها ليست الطريقة الأمثل. أدوات أخرى هناك العديد من الأدوات المتاحة لإدارة الحزم والتي تزودنا بالعديد من المهام والوظائف، أو تستحضر معلومات بطرق مختلفة. بعض هذه الأدوات مفيدة في مواقف معينة لكننا سنذكر بعض هذه الأدوات عند الضرورة. تحديث الذاكرة المؤقتة للحزم والنظام تزودنا أدوات إدارة الحزم بطرق ممتازة لدوام تحديث قائمة النظام الخاصة بالحزم المتاحة، كما وتزودنا بطرق بسيطة لتحدث الحزم المنصبة حاليا على خادومك. تحديث الذاكرة المؤقتة للحزم المحلية تعتبر المستودعات التي تعتمد عليها أدوات الحزم الخاصة بك في الحصول على معلومات الحزمة محدثة على الدوام، لكن معظم أدوات إدارة الحِزم تعمل بالذاكرة المؤقتة لهذه المعلومات. يحبذ دائمًا عمل تحديث للذاكرة المؤقتة الخاصة بالحِزم لكل جلسة قبل إجراء أي أوامر خاصة بالحزم، هذا سوف يضمن أنك تعمل على المعلومات المحدثة حول البرنامج المتاح. إضافة إلى أن بعض أوامر التنصيب سوف لن تتم إذا كنت تعمل على معلومات قديمة لبعض الحِزم. لتحديث الذاكرة المؤقتة، استخدم الأمر apt-get مع اللاحقة update: sudo apt-get update هذا سوف يجلب قائمة المعلومات المحدثة من المستودعات عن الحزم التي تتابعها. تحديث الحزم بدون إزالة مجموعة الحزم apt تسهل عملية تحديث كل البرامج المنصبة على الخادوم. الأمر apt يميّز بين عمليتي تحديثٍ مختلفتين، العملية الأولى (والتي سيتم تفصيلها في هذا القسم) يمكن استخدامها لتحديث أي جزء لا يتطلب إزالة أجزاء أخرى. تعتبر هذه الطريقة مهمة جدا عندما لا ترغب في إزالة أي حزمة مـُنصبّة تحت أي ظرف. لكن – في الحقيقة – بعض التحديثات تتضمن استبدال أجزاء النظام أو إزالة ملفات التعارض. سوف تتجاهل هذه الطريقة أي تحديثات تتطلب إزالة حِزم: sudo apt-get upgrade بعد تنفيذ هذا الإجراء، سيتم تطبيق أي تحديث لا يتضمن إزالة أجزاء. تحديث الحِزم والإزالة حسب الضرورة تقوم مجموعة apt بتسهيل عملية التحديث لكافة البرامج المنصبة على الخادوم. يقوم الأمر بالتمييز بين عمليتي تحديث مختلفتين، الأولى تقوم بتجاهل أي عملية تحديث تتطلب إزالة أي حزمة، وهذه العملية تم شرحها في القسم أعلاه. العملية الثانية، تقوم بتحديث كل الحِزم، حتى تلك التي تتطلب إزالة حزم معينة. هذا الأمر ضروري غالبًا كاعتمادية لتغيير الحِزم. عادة، يتم استبدال الحِزم التي تمت إزالتها ببديل وظيفي خلال عملية التحديث، مما يجعل عملية التحديث آمنة. على أي حال يجب الانتباه إلى الحزم التي يتوجب إزالتها. لإجراء هذه الوظيفة، نفّذ الأمر: sudo apt-get dist-upgrade سيقوم بتحديث كل الحزم على النظام، تعتبر هذه العملية تحديث كامل أكبر التحديث السّابق. تحميل وتنصيب الحزم تُعد مهمة تسهيل تحميل وتنصيب الحِزم على النظام كإحدى المهام الرئيسة في أدوات إدارة الحِزم. البحث عن الحزم بعد عملية تحميل وتنصيب الحِزم، أول خطوة هي البحث في مستودعات التوزيعة عن الحِزم التي تلزمك. أغلب أوامر apt تعمل بشكل رئيسي على الذاكرة المؤقتة لمعلومات الحِزم المحفوظة على الحاسوب المحلي. بالطبع فإن هذا الأمر يسمح بالمزيد من السرعة في التنفيذ، والتقليل من حركة البيانات عبر الشبكة. البحث عن الحِزم هي عملية تستهدف المعلومات في الذاكرة المؤقتة للحِزم. الأمر الفرعي apt-cache search هو الأداة المستخدمة في البحث عن الحِزم المتاحة. يرجى الانتباه إلى ضرورة التأكد من تحديث الذاكرة المؤقتة المحلية قبل عملية البحث من خلال الأمر sudo apt-get update: apt-cache search package حيث أن هذه العملية تستعلم عن المعلومات فقط، فإنها لا تتطلب صلاحيات sudo. أي بحث يتم إجراؤه سيبحث عن أسماء الحِزم بالإضافة إلى الوصف الكامل لها. على سبيل المثال، إذا كنت تبحث عن htop، ستكون النتائج كما يلي: apt-cache search htop aha - ANSI color to HTML converter htop - interactive processes viewer libauthen-oath-perl - Perl module for OATH One Time Passwords كما ترى، لدينا حزمة اسمها htop، لكننا نرى أيضا برنامجين آخرين، كلاهما أشار إلى htop في حقل الوصف الكامل للحزمة (الوصف الذي يلي المخرجات هو وصف مختصر). تنصيب الحزم من المستودعات لتنصيب حزمة من المستودعات، بالإضافة إلى كل الحزمة المعتمدة عليها، نستخدم الأمر apt-get مع الأمر الفرعي install. المدخلات مع هذا الأمر يجب أن تكون اسم أو أسماء الحزم كما هو ظاهر/مُستخدم في المستودع: sudo apt-get install package بإمكانك تنصيب عدة حِزم دفعة واحدة، مع الفصل بينها بمسافة: sudo apt-get install package1 package2 إذا طلبت حِزمة تتطلب اعتمادات أخرى، سيتم عرضها ويُطلب منك تأكيد العملية، ستكون شبيهة بما يلي: Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: apache2-data Suggested packages: apache2-doc apache2-suexec-pristine apache2-suexec-custom apache2-utils The following NEW packages will be installed: apache2 apache2-data 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 236 kB of archives. After this operation, 1,163 kB of additional disk space will be used. Do you want to continue [Y/n]? كما ترى، بالرغم من أننا طلبنا تنصيب apache2 فأن الحزمة apache2-data مطلوبة كاعتمادية. في هذه الحالة يمكنك الاستكمال بالضغط على زر الإدخال ENTER أو "y" أو تجاهل العملية بالضغط على حرف "n". تنصيب إصدار حِزمة معين من المستودعات إذا كنت تريد تنصيب إصدار محدد لحزمة ما، يمكنك إضافة الإصدار الذي ترغب به مع إشارة التساوي، كما يلي: sudo apt-get install package=version الإصدار في هذه الحالة يجب أن يتوافق مع الأرقام المتاحة في المستودع. هذا يعني استخدام نموذج الإصدارات الموجود في التوزيعة التي تستخدمها. تستطيع إيجاد الإصدارات المتاحة عبر تنفيذ الأمر apt-cache policy package إعادة ضبط الإعدادات العديد من الحِزم تتضمن إعدادات ما قبل التنصيب، والتي يتم تنفيذها بعد اكتمال عملية التنصيب. غالبا يكون لمدير النظام الحرية في اختيار الإعدادات. إذا كنت تريد تأجيل خطوات هذه الإعدادات الإضافية، يمكنك استخدام الأمر dpkg-reconfigure، الذي بدوره يبحث في الحزمة التي يتم تمريرها له، ويعيد تنفيذ أي أوامر للإعدادات اللاحقة المتضمنة في مواصفات الحزمة: sudo dpkg-reconfigure package هذا سيسمح لك بالوصول إلى الإعدادات الإضافية (وربما غيرها) التي تجاوزتها خلال التنصيب. إجراء محاكاة لعمليات الحزمة في بعض الأحيان، تحتاج لترى التأثيرات الجانبية لعملية ما بدون الاعتماد الفعلي لتنفيذ الأمر. لحسن الحظ فإن apt تسمح لك بإضافة s- لمحاكاة العملية. على سبيل المثال، تريد أن ترى ما يمكن أن يحصل عندما تختار تنصيب حزمة، يمكنك تنفيذ الأمر: apt-get install -s package هذا سيسمح لك برؤية كل الاعتمادات والتغييرات على نظامك، والتي سوف تحدث لو قمت بإزالة لاحقة s-. إحدى فوائد هذه الطريقة هو تمكينك من رؤية نتائج عملية ما، والتي تتطلب صلاحية root، بدون استخدام sudo. على سبيل المثال، لتقييم ما يمكن تنصيبه مع apache2، يمكنك تنفيذ الأمر: NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: apache2-data Suggested packages: apache2-doc apache2-suexec-pristine apache2-suexec-custom apache2-utils The following NEW packages will be installed: apache2 apache2-data 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Inst apache2-data (2.4.6-2ubuntu2.2 Ubuntu:13.10/saucy-updates [all]) Inst apache2 (2.4.6-2ubuntu2.2 Ubuntu:13.10/saucy-updates [amd64]) Conf apache2-data (2.4.6-2ubuntu2.2 Ubuntu:13.10/saucy-updates [all]) Conf apache2 (2.4.6-2ubuntu2.2 Ubuntu:13.10/saucy-updates [amd64]) سنحصل على كل المعلومات عن الحِزم والإصدارات دون الحاجة إلى إكمال العملية فعليًا. هذه الطريقة تعمل أيضا مع عمليات أخرى مثل تحديثات النظام: apt-get -s dist-upgrade عدم التنبيه لطلب التأكيد مع إجراءات الحزمة تقوم apt بتنبيه المستخدم بشكل افتراضي لتأكيد العديد من العمليات، هذا يتضمن عمليات التنصيب التي تتطلب اعتماديات إضافية وتحديث للحزم. لتجاوز هذه التحديثات، يمكنك إضافة y- عند تنفيذ هذه الأوامر: sudo apt-get install -y package سيقوم هذا الأمر بتنصيب الحزمة وأي اعتماديات دون طلب التأكيد من المستخدم، يستخدم أيضا في عملية التحديث أيضًا: sudo apt-get dist-upgrade –y إصلاح الاعتماديات غير المكتملة والحِزم في بعض الأحيان لا تكتمل بعض عمليات التنصيب بسبب الاعتماديات أو أي مشاكل أخرى. إحدى هذه الحالات الشائعة لحدوث مثل هذه المشاكل عند تنصيب حزمة من نوع deb. من خلال dpkg، والتي لا تقوم بتحليل الاعتماديات. يقوم الأمر apt-get بمحاولة تنظيم الوضع بتمرير الأمر f-. sudo apt-get install -f سيقوم بالبحث عن أي اعتماديات غير متوفرة ومحاولة تنصيبها لإصلاح شجرة الاعتماديات. إذا كان التنصيب غير مكتمل بسبب مشكلة في الاعتماديات، فيجب أن تكون هذه الخطوة الأولى لمحاولة الحل. تحميل حزمة من المستودعات في الكثير من الأحيان يكون من المفيد تحميل الحِزم من المستودعات دون تنصيبها فعليًا. يمكنك تنفيذ ذلك من خلال الأمر الفرعي download التابع للأمر apt-get. بما أن الحالة هي تحميل ملف فقط، فلا يتأثر النظام، وبالتالي لا حاجة لصلاحيات sudo: apt-get download package يقوم هذا الأمر بتحميل حزمة / حِزم معينة إلى المجلد الحالي. تحميل مصدر الحزمة من المستودعات يمكنك تحميل الملفات المصدرية للحِزم على الرغم من أن الأمر apt يتعامل بشكل رئيسي مع حِزم deb.، طالما أن قوائم المصدر الخاصة بـ apt تكون مجهّزة بتلك المعلومات. لتحميل مصدر الحزمة، يجب أن يكون هناك سطر deb-src مُوافق لذلك في ملف source.list لتلك الـ apt. بإمكانك الاطلاع على كيفية عمل ذلك في قسم إضافة مستودعات apt. بعد أن يتم إعداد المستودعات، يمكنك تحميل مصدر حزمة ما من خلال تنفيذ: sudo apt-get source package هذا الأمر سيقوم بتحميل ملفات الحزمة إلى المجلد الحالي. بالطبع فإن التحميل يشمل مجلد الحزمة، ملف الوصف dsc، وملف الحزمة مضغوطًا ومؤرشفًا. ls -F sublime-text-2.0.2/ sublime-text_2.0.2-1~webupd8~3.tar.gz sublime-text_2.0.2-1~webupd8~3.dsc إذا كنت تود استخدام حِزم التوزيعة كأساس لتعديلات مستقبلية، يمكنك استخدام الطريقة المذكورة. تنصيب حزمة deb. بعض المزودين يقدمون الملفات الخام deb. لبرامجهم، والتي يمكنك تنصيبها على نظامك، ولكن أغلب التوزيعات توصِي بتنصيب البرامج من مستودعاتهم التي تنال قدرًا كافيًا من اهتمامهم. لتنصيب ملفات deb.، نستخدم أداة dpkg والتي تستخدم بشكل رئيسي للعمل مع الحِزم المستقلة. لا تقوم الأداة بإجراءات التنصيب، بدلا من ذلك تبحث عن حِزم deb. في المجلد الحالي، أو المسار الذي يتم تزويده: sudo dpkg --install debfile.deb من المهم ملاحظة أن أداة dpkg لا تقوم بالتعامل مع الاعتماديات، مما يعني أن التنصيب سيبوء بالفشل في حال عدم وجود الحزم التي تعتمد عليها الحزمة الحالية. لحُسن الحظ تقوم الأداة بتحديد الاعتماديات المطلوبة، حيث أنه إذا كانت الاعتماديات متوفرة في المستودعات يمكنك توفيرها بسهولة فيما بعد من خلال تنفيذ الأمر sudo apt-get install -f سيقوم هذا الأمر بتنصيب الاعتماديات المطلوبة، من بينها تلك التي قامت الأداة dpkg بتحديدها. تنصيب "مهام" البرامج من خلال Tasksel من الممكن تنصيب مجموعة كبيرة من البرامج ذات العلاقة من خلال استخدام المهام "tasks". المهام – ببساطة – هي مجموعات من الحِزم التي تقوم بتجهيز بيئة معينة عندما يتم تنصيبها مع بعضها البعض. من الأمثلة على هذه المهام ما يلي: خادوم LAMP (خاص ببيئة تطوير مواقع الويب)، بيئة سطح المكتب، خادوم التطبيقات. قد تحتوي بعض الأنظمة على حزمة tasksel موجودة بشكل افتراضي. للحصول عليها يمكنك تنفيذ: sudo apt-get update sudo apt-get install tasksel كما ويمكنك اختيار حِزم مهام مختلفة بتنفيذ: sudo tasksel سيقوم هذه الأمر بعرض واجهة تسمح لك باختيار مجموعات حِزم مختلفة وتطبيق التغييرات. يمكنك استعراض قائمة المهام المتاحة وحالتها (من حيث التنصيب) بتنفيذ الأمر: tasksel --list-task أخيرًا، يمكنك تنصيب مهام من سطر الأوامر بتنفيذ: sudo tasksel install task_name سنواصل في الجزء القادم المزيد من أساسيات إدارة الحزم في أوبنتو ودبيان. ترجمة -وبتصرف- للمقال Ubuntu and Debian Package Management Essentials لصاحبه Justin Ellingwood.
  20. نواصل معكم في هذا المقال استعراض أساسيات إدارة الحزم في أوبنتو ودبيان. إذا لم تقرأ الجزء الأول فأنصحك بقراءته أوّلا قبل مواصلة قراءة هذا المقال. إزالة الحزم وحذف الملفات العمليات المعاكسة لعملية التنصيب والتحميل الحِزم متاحة أيضًا من مدير الحِزم. هذا القسم سيناقش كيفية إزالة تنصيب الحِزم وتنظيف الملفات التي قد تبقى كنتيجة لعمل الحزمة. إزالة حزمة لإزالة حزمة منصبة، يجب إضافة الأمر الفرعي remove إلى الأمر apt-get. سيقوم هذا الأمر بإزالة الملفات التي قامت الحزمة بتنصيبها على نظامك مع استثناء جدير بالاهتمام. الأمر يُبقي ملفات الإعدادات محفوظة في مكانِ ما في حال تم إعادة تنصيب الحزمة مرة أخرى فيما بعد. تعتبر هذه الطريقة مفيدة في حالة الحذف المفاجئ للحزمة؛ حيث لا تضيع جهودك هدرًا في إعادة ضبط الإعدادات وتخصيصها. لإكمال العملية يلزمك تزويد الأمر باسم الحزمة المراد إزالتها أو إلغاء تصيبها: sudo apt-get remove package ستتم إزالة الحزمة، باستثناء ملف الإعدادات. إزالة حزمة وكل ملفات الإعدادات ذات العلاقة إذا كنت ترغب في إزالة حزمة وكل الملفات المتعلقة بها من نظامك، متضمنة ملفات الإعدادات، يمكنك استخدام الأمر الفرعي purge من الأمر apt-get. بخلاف الأمر remove -الذي تم ذكره بالأعلى- فإن الأمر purge يزيل كل شيء. تعتبر هذه الطريقة مفيدة في حال عدم رغبتك الاحتفاظ بملفات الإعدادات، أو في حال ما كانت لديك بعض المشاكل وترغب في البدء من الصفر. تجدر الإشارة هنا إلى أن ملفات الإعدادات لا يمكن استرجاعها في حال تم حذفها: sudo apt-get purge package في هذه الحالة، عندما تقوم بإعادة تنصيب الحزمة مرة أخرى فسيتم استخدام الإعدادات الافتراضية. إزالة الاعتماديات التلقائية التي لم تعد لها حاجة تتم إزالة الحِزم من النظام باستخدام الأوامر apt-get remove أو apt-get purge، لكن بعض هذه الحزم كان قد تطلّب وقت التنصيب بعض الاعتماديات لاستكمال التنصيب، وبعد إزالة الحزمة تبقى هذه الاعتماديات. لإزالة أي حِزم تم تنصيبها كاعتماديات ولم تعد مطلوبة لأي حزمة أخرى، يمكنك تنفيذ الأمر autoremove كما يلي: sudo apt-get autoremove إذا كنت ترغب في إزالة كل ملفات الإعدادات المتعلقة من الاعتماديات التي تمت إزالتها، يجب إضافة purge-- إلى الأمر autoremove. سيقوم هذا الأمر بإزالة ملفات الإعدادات مثل وظيفة الأمر purge: sudo apt-get --purge autoremove تنظيف ملفات الحزم المهجورة Obsolete بعض الحِزم تُصبح قديمة ومهجورة مع مرور الوقت. بإمكان الأداة apt-get إزالة أيٍ من ملفات هذه الحِزم عن النظام المحلي، تلك الملفات المرتبطة بالحِزم والتي لم تعد متاحة من قِبل المستودعات باستخدام الأمر autoclean. يقوم هذا الأمر بتحرير المزيد من المساحة على الخادوم، ويسمح بتحديث الذاكرة المؤقتة على النظام المحلي وتجنّب الاحتفاظ ببيانات غير مستخدمة. sudo apt-get autoclean الحصول على معلومات حول الحزم كل حزمة تحتوي على كمية كبيرة من البيانات التي يمكن الوصول إليها من خلال أدوات إدارة الحِزم. في هذا القسم سنقوم بتسليط الضوء على بعض الطرق الشائعة للحصول على المعلومات حول الحزم المتاحة والمنصبة. عرض المعلومات حول حزمة لعرض المعلومات التفصيلية حول حزمة في التوزيعة التي تستخدمها، يمكنك استخدام الأمر الفرعي show من الأمر apt-cache. هذا الأمر يعتمد على اسم الحزمة في المستودع: apt-cache show package سيقوم الأمر بعرض معلومات حول الحِزم التي تظهر في نتاج البحث عن تلك الحزمة التي يتم الاستفسار عنها. كل حزمة مرشحة تتضمن معلومات حول اعتمادياتها، الإصدار، التركيبة أو المعمارية، التعارضات، الاسم الفعلي للحزمة، حجم الحزمة وحجم تنصيبها، الوصف التفصيلي، بالإضافة إلى معلومات أخرى. لعرض المزيد من المعلومات حول كل حزمة مرشحة، شاملة لقائمة كاملة للاعتماديات العكسية ( قائمة الحِزم التي تعتمد على الحزمة التي نستفسر عنها) استخدم الأمر showpkg بدلا من الأمر المذكور أعلاه، والذي سيتضمن الكثير من المعلومات حول علاقة هذه الحزمة بالحِزم الأخرى: apt-cache showpkg package عرض المعلومات حول حزمة deb. لعرض تفاصيل حول ملف deb. يمكنك استخدام المؤشر info-- مع الأمر dpkg، الهدف لهذا الأمر يجب أن يكون مسار ملف deb.: dpkg --info debfile.deb سيعرض لك هذا الأمر بعض البيانات الوصفية حول الحزمة التي تستفسر عنها، المعلومات تتضمن اسم الحزمة وإصدارها، المعمارية التي بُنيت لها، الحجم والاعتماديات المطلوبة، الوصف والتعارضات. عرض الاعتماديات والاعتماديات العكسية لعرض الاعتماديات (اعتماد حزمة على أخرى) بشكل دقيق، وكذلك الاعتماديات العكسية (الحِزم التي تعتمد على هذه الحزمة) يمكنك استخدام الأداة apt-cache. لعرض معلومات الاعتماديات بشكل جيد، يمكنك استخدام الأمر الفرعي depends: apt-cache depends package سيقوم الأمر بعرض معلومات حول كل حِزمة تم التعرف عليها كاعتمادية، بالإضافة إلى الاقتراحات، التوصيات أو التعارضات. إذا كنت ترغب في معرفة أي حِزم تعتمد على حزمة معينة، يمكنك إضافة اسم الحزمة إلى الأمر الفرعي rdepends: apt-cache rdepends package عرض إصدارات الحزمة المنصبة والمتاحة في الكثير من الأحيان تتوفر عدّة إصدارات من حزمة ما في المستودع، مع حزمة واحدة افتراضية. لعرض الإصدارات المتاحة لحزمة ما، يمكنك استخدام الأمر الفرعي policy من الأمر apt-cache: apt-cache policy package سيقوم الأمر بعرض أي إصدار تم تنصيبه (إذا كان الحزمة منصبة)، الحزمة المرشحة والتي سيتم تنصيبها بشكل افتراضي إذا لم تقم بتحديد إصدار في أمر التنصيب، بالإضافة إلى جدول إصدارات الحزم، منتهيًا بمؤشر يشير إلى أولوية كل إصدار. يمكنك استخدام تلك الطريقة لتحديد أي إصدار سيتم تنصيبه والبدائل المتاحة. ولأن هذه الطريقة ترصد المستودعات التي يتواجد فيها كل إصدار، فإنه يمكن استخدامها لتحديد إذا ما توافرت مستودعات أخرى أو الأرشيف الشخصي للحِزم (PPAs) تقوم بنسخ الحِزم من المستودع الافتراضي. عرض الحزم المنصبة باستخدام الأمر dpkg -l لعرض الحِزم التي تم تنصيبها على نظامك، لديك القليل من الخيارات، اعتمادًا على هيئة المخرجات، وكذلك حجم المعلومات المطلوبة. الطريقة الأولى تتضمن استخدام dpkg أو dpkg-query مع l-. المخرجات من الأمرين كليهما ستكون متطابقة، بلا شك ستعطي قائمة لكل حزمة منصبة (جزئيا أو كليّا) على النظام، وشكلها كما يلي: dpkg -l Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-===========================================-=======================================-============-===================================================================================================================== ii account-plugin-generic-oauth 0.10bzr13.03.26-0ubuntu1.1 amd64 GNOME Control Center account plugin for single signon - generic OAuth ii accountsservice 0.6.34-0ubuntu6 amd64 query and manipulate user account information ii acl 2.2.52-1 amd64 Access control list utilities ii acpi-support 0.142 amd64 scripts for handling many ACPI events ii acpid 1:2.0.18-1ubuntu2 amd64 Advanced Configuration and Power Interface event daemon . . . ستستمر المخرجات لكل حزمة في النظام على المخرجات يمكنك رؤية مدلولات الحروف الثلاثة الأولى في كل سطر. الحرف الأولى يشير إلى الحالة المرغوب فيها للحزمة، وتكون أحد ما يلي: u: غير معروف i: تم التنصيب r: تمت إزالتها. p: تمت إزالتها كليّا ( تنظيف بعد الإزالة) h: إصدار معلّق. الحرف الثاني يشير إلى الحالة الحقيقة للحزمة كما هو معروف لنظام التحزيم Packaging system، يمكن أن تكون إحدى الحالات التالية: n: لم يتم تنصيبها. i: تم تنصيبها. c: ملف الإعدادات موجود، لكن الحزمة تمت إزالتها. u: تم فك ضغط الحزمة لكن لم يُشرع في إعدادها بعد. f: الحزمة منصبة (جزئيًا) مما يعني حدوث فشل أثناء عملية التنصيب مما لم يسمح باكتمال عملية التنصيب. w: الحزمة تنتظر حدثًا من حزمة منفصلة. p: الحزمة تم تفعيلها من قِبل حزمة أخرى. الحرف الثالث، والذي يكون عبارة عن مسافة فارغة لأغلب الحِزم، له خيار واحد كما يلي: r: إشارة إلى ضرورة إعادة التنصيب، مما يفيد أن الحزمة غير مكتملة ولا يمكن الاستفادة من وظائفها. باقي الأعمدة تحتوي اسم الحزمة، الإصدار، المعمارية وكذلك الوصف. عرض حالة التنصيب للحِزم التي تم ترشيحها إذا قمت بإضافة معيار بحث بعد l- ، فإن dpkg سيعرض كل الحِزم التي تحوي معيار البحث، سواءً كانت منصّبة أم لا، على سبيل المثال، نستطيع البحث عن عمليات المكتبات YAML كما يلي: dpkg -l libyaml* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-===============-============-============-=================================== ii libyaml-0-2:amd 0.1.4-2ubunt amd64 Fast YAML 1.1 parser and emitter li ii libyaml-dev:amd 0.1.4-2ubunt amd64 Fast YAML 1.1 parser and emitter li un libyaml-perl <none> (no description available) un libyaml-syck-pe <none> (no description available) ii libyaml-tiny-pe 1.51-2 all Perl module for reading and writing كما ترى في العمود الأول، النتيجة الثالثة والرابعة غير منصبة. هذا الأمر يعرض كل حزمة يتوفر فيها معيار البحث، بالإضافة إلى الحالة الحالية والمرغوب فيها. عرض الحِزم المنصبة بالأمر dpkg --get-selections يمكنك استعراض الحِزم المنصبة على نظامك بطريقة أخرى، باستخدام مؤشر get-selections-- مع الأداة dpkg، حيث يزودنا هذا الأمر بقائمة لكل الحِزم التي تم تنصيبها، والتي تمت إزالتها دون التنظيف بعد الإزالة: dpkg --get-selections للتفريق بين تلك الحالتين، يمكنك استخدام awk للتصفية حسب الحالة. لاستعراض الحِزم المنصّبة فقط، اطبع: dpkg --get-selections | awk '$2 ~ /^install/` لعرض قائمة الحِزم التي تمت إزالتها لكن لم يتم إزالة ملفات الإعدادات، يمكنك استخدام الأمر: dpkg --get-selections | awk '$2 !~ /^install/' البحث ضمن الحزم المنصبة للبحث في الحِزم المنصبة عن حزمة معينة، يمكنك إضافة نص التصفية/الترشيح بعد خيار get-selections--. هذا الأمر يستخدم البدائل لمحاولة العثور على تطابق ما. مرة أخرى، يقوم هذا الأمر بعرض أي حزمة منصبة، أو ملفات الإعدادات الخاصة بها ما زالت على النظام: dpkg --get-selections libz* مرة أخرى، يمكنك التصفية باستخدام تعبيرات awk من القسم أعلاه. استعراض الملفات المنصبة من خلال حزمة لاستعراض الملفات الخاصة بحزمة ما، يمكنك استخدام مؤشر L- مع الأمر dpkg: dpkg -L package سيقوم هذا الأمر بطباعة المسار الكامل لكل ملف خاص بتلك الحزمة. بالطبع لن تتضمن القائمة ملفات الإعدادات التي يتم إنشاؤها من خلال عمليات الحزمة البحث عن ما تنصبه الحزمة لموقع ما لاستكشاف أي حزمة مسؤولة عن ملف معين في نظام الملفات، يمكنك إضافة الملف الكامل إلى الأمر dpkg مع مؤشر S-. سيقوم الأمر بطباعة اسم الحزمة التي قامت بتنصيب الملف: dpkg -S /path/to/file تجدر الإشارة إلى أن أي ملفات تم نقلها إلى مكان ما من خلال عملية ما بعد التنصيب، لا يمكن ربطها بحزمتها من خلال هذا الأمر. معرفة أي حزمة تقوم بتوفير ملف ما دون تنصيبها قد تحتاج في بعض الأحيان لمعرفة أي حزمة تزودك بملف ما أو أمر ما، حتى بدون أن تقوم بتنصيب الحزمة على نظامك. من السهل معرفة إذا ما كانت حزمة معينة تحتوي ملفًا ما باستخدام dpkg بإضافة الخيار S-. لعمل ذلك يلزم تنصيب الأداة apt-file. تمتلك هذه الأداة قاعدة بيانات لمعلوماتٍ حول الحزم، من ضمن هذه المعلومات مسار التنصيب لكل ملف خاص بالحزمة من قاعدة البيانات تلك. قم بتنصيب الأداة بتنفيذ: sudo apt-get update sudo apt-get install apt-file الآن، قم بتحديث قاعدة البيانات الخاصة بالأداة وقم بالبحث عن ملف بتنفيذ: sudo apt-file update sudo apt-file search /path/to/file سيعمل هذا الأمر فقط للمواقع التي تم تنصيبها مباشرة بواسطة حزمة ما. لن يتم إيجاد الملفات التي تم إنشاؤها بواسطة برامج ما بعد التثبيت. تحويل قوائم الحزم بين الأنظمة في كثير من الأحيان قد تحتاج لعمل نسخة احتياطية لقائمة الحِزم التي تم تنصيبها على نظامك، واستخدامها لتنصيب نفس القائمة من الحِزم على نظام آخر. بالطبع تعتبر هذه الطريقة مفيدة لأغراض النسخ الاحتياطي. هذا القسم يوضح آلية تصدير واستيراد قوائم الحِزم. تصدير قائمة الحزم إذا كنت ترغب في تكرار مجموعة الحزم التي تم تنصيبها على نظامك إلى نظام آخر، يتوجب عليك في البداية تصدير قائمة الحزم. يمكنك تصدير قائمة الحزم المنصّبة إلى ملف بتلك الصيغة المطلوبة لاحقًا لعمية الاستيراد عن طريق مخرجات الأمر dpkg --get-selections : dpkg --get-selections > ~/packagelist.txt يمكنك نسخ هذه القائمة إلى نظام أو حاسوب آخر واستيرادها. قد تحتاج أيضًا لأخذ نسخة احتياطية لقوائم المصادر وقائمة المفاتيح الموثوقة. يمكنك أخذ نسخة احتياطية من المصادر بإنشاء مجلد بالملفات الضرورية ونسخها: mkdir ~/sources cp -R /etc/apt/sources.list* ~/sources المفاتيح الموثوقة يمكن نسخها احتياطيًا بتنفيذ: apt-key exportall > ~/trusted_keys.txt الآن يمكنك تحويل الملف packagelist.txt ومجلد sources والملف trusted_keys.txt إلى حاسوب آخر بغرض استيرادها. استيراد قائمة الحزم إذا قمت بإنشاء قائمة الحزم باستخدام dpkg --get-selections كما تم شرحه أعلاه، بإمكانك استيراد الحِزم على حاسوب آخر باستخدام الأمر dpkg . في البداية يجب أن تقوم بإضافة مفاتيح الثقة، وتحضير قوائم المصادر التي تم نسخها من الحاسوب الأول. على افتراض أنك قمت بنسخ جميع الملفات المنقولة إلى مجلد home في الحاسوب الثاني، يمكنك تنفيذ: sudo apt-key add ~/trusted_keys.txt sudo cp -R ~sources/* /etc/apt/ ثم قم بإزالة الحالة عن الحزِم غير الضرورية من الحاسوب الجديد. مما يعني أنك تقوم بتطبيق التغييرات من جديد. يجب تطبيق هذا من خلال حساب root أو صلاحيات sudo: sudo dpkg --clear-selections سيقوم الأمر باختيار كل الحِزم التي لا ترغب بتنصيبها. يجب أيضا تحديث قائمة الحِزم المحلية لضمان أن عمليات التنصيب سيكون لديها سجل أو معلومات لكل البرامج التي نحتاج تنصيبها. عملية التنصيب والتحدث الفعلية سيتم معالجتها من خلال أداة dselect. يجب التأكد أن الأداة dselect قد تم تنصيبها. تمتلك هذه الأداة قاعدة بيانات خاصة بها، لذا يجب تحديثها قبل الاستكمال: sudo apt-get update sudo apt-get install dselect sudo dselect update الآن نستطيع تطبيق قائمة الحزم فوق القائمة الحالية؛ لمعرفة أي حزم يجب الاحتفاظ بها أو تحميلها: sudo dpkg --set-selections < packagelist.txt يقوم هذا الأمر بضبط حالات الحزم التي نريدها. لتطبيق التغييرات يجب تطبيق الأمر الفرعي dselect-upgrade من الأمر apt-get: sudo apt-get dselect-upgrade سيقوم هذا الأمر بتحميل وتنصيب الحزم الضرورية. وسيقوم بإزالة الحزم التي لم يتم اختيارها. وفي النهاية فإن قائمة الحزم يجب أن تتطابق مع تلك التي تم استيرادها من الحاسوب الأول، بغض النظر عن أن ملفات الإعدادات ما زالت تحتاج لأن يتم نسخها أو تعديلها. إضافة المستودعات والأرشيف الشخصي للحزم PPA تحتوي المجموعة الافتراضية من المستودعات التي يتم توفيرها في أغلب التّوزيعات على حِزم كافية لأغلب المستخدمين. بالرغم من ذلك فإنك تحتاج في الكثير من الأحيان إلى مصادر إضافية. سنقوم في هذا القسم بمناقشة آلية أعداد أدوات الحزم لتتعامل مع مصادر إضافية. إضافة أرشيف شخصي للحزم يعتبر الأرشيف الشخصي للحزم (PPAs) بديلا عن المستودعات التقليدية. الأرشيف الشخصي للحزم متاح فقط لأنظمة أوبنتو، حتى كتابة هذا المقال. عادة ما يتميز الأرشيف الشخصي للحزم بمجال أصغر من المستودعات، ويحتوي مجموعة مركزة من التطبيقات التي يتم الاحتفاظ بها مِن خلال مَن يمتلك الأرشيف الشخصي للحِزم. إضافة أرشيف الشخصي للحزم لنظامك، يسمح لك بإدارة الحِزم التي يحتويها مع أدوات إدارة الحِزم التي اعتدت عليها. هذه الطريقة ستزودنا بحزمة أو مجموعة من الحِزم المحدّثة والتي لا يتضمنها مستودع الحِزم الخاص بالتوزيعة. يجب الانتباه إلى ضرورة إضافة الأرشيف الشخصي للحزم الذي تثق به، حيث أنك تسمح لحافظة غير رسمية ببناء الحِزم لنظامك. لإضافة أرشيف الشخصي للحزم، يمكنك استخدام الأمر add-apt-repository. يجب أن تضيف الاسم ppa:، متبوعًا باسم مالك الأرشيف الشخصي للحزم على Launchpad، شرطة مائلة ثم اسم الأرشيف الشخصي للحزم: sudo add-apt-repository ppa:owner_name/ppa_name قد يتطلب الأمر الموافقة على قبول مفتاح صاحب الحِزم. بعد ذلك سيتم إضافة الأرشيف الشخصي للحزم لنظامك، مما يسمح لك بتنصيب الحزم بأوامر apt الاعتيادية. قبل البحث عن الحزم أو تنصيبها، قمت بالتأكد من تحديث ذاكرة التخزين المؤقت المحلية بالمعلومات حول الأرشيف الشخصي الجديد للحِزم: sudo apt-get update إضافة مستودعات لإضافة المزيد من المستودعات لأنظمة أوبنتو أو دبيان، يمكنك اتباع أحدِ مسارين. المسار الأول يتم بتعديل قوائم المصادر لديك مباشرة. بإمكانك تعديل ملف etc/apt/sources.list/ أو استبدال ملف قائمة جديد في مجلد /etc/apt/sources.list.d/. إذا قمت باستخدام الطريقة الثانية فيجب الانتباه إلى أن اسم الملف الذي قمت بإنشائه يجب أن ينتهي بـ list.: sudo nano /etc/apt/sources.list.d/new_repo.list يمكنك إضافة موقع المستودع الجديد في الملف الجديد باستخدام الشكل التالي: deb_or_deb-src url_of_repo release_code_name_or_suite component_names الأجزاء المختلفة لمواصفات المستودع موضحة كما يلي: deb أو deb-src: لتحديد نوع المستودع. تستخدم deb لتحديد المستودع العادي، بينما مستودعات المصادر تبدأ بـ deb-src. url: العنوان الرئيسي للمستودع. يجب أن يكون الموقع الذي يتواجد فيه المستودع. release code name or suite: عادة ما يكون الاسم الرسمي لإصدار التوزيعة، لكن قد يكون أي اسم مستخدم لتعريف مجموعة محددة من الحِزم التي تم إنشاؤها للإصدار الذي تستخدمه من التوزيعة. component names: علامات لاختيار الحِزم التي ترغب بتوفرها. وتعتبر ميزة يتم توفيرها من القائمين على التوزيعة؛ لتقديم توضيح حول المصداقية أو قيود الترخيص للبرامج التي تحتويها. باستطاعتك إضافة هذه الأسطر بداخل الملف. معظم المستودعات تحتوي معلومات حول الهيئة التي يجب استخدامها. الطّريقة الأخرى لإضافة المزيد من المستودعات يتم باستخدام الأمر add-apt-repository. توزيعات أوبنتو تحتوي هذا الأمر بشكل افتراضي، بينما يمكن تنصيبها إلى توزيعات دبيان من خلال حزمة software-properties-common: sudo apt-get update sudo apt-get install software-properties-common بعد ذلك يمكن إضافة الأسطر التي تريد إضافتها إلى الأمر add-apt-repository. بالطبع يجب أن تكون الإضافات بنفس الهيئة أو الشكل الذي تستخدمه في حالة الإضافات اليدوية: sudo add-apt-repository 'deb url release component' يجب التأكد من تحديث الذاكرة المؤقتة المحلية للحِزم بعد تطبيق أي تحديث للمستودع؛ كي يكون النظام على وعي بالحِزم المتاحة حديثًا: sudo apt-get update خاتمة هناك العديد من عمليات إدارة الحِزم التي يمكنك إجراؤها، لكننا حاولنا تغطية أغلب الخطوات الشائعة هنا. إذا كان لديك أي تفضيلات أو اهتمامات أخرى، يرجى استخدام قسم التعليقات أدناه لنعرفها. ترجمة -وبتصرف- للمقال Ubuntu and Debian Package Management Essentials لصاحبه Justin Ellingwood.
  21. هنالك العديد من البرمجيات المفيدة جدًا المطورة من فريق خادوم أوبنتو وغيرهم التي تندمج اندماجًا جيدًا مع نسخة خادوم أوبنتو، لكن ربما لا تكون معروفةً جدًا؛ سيعرض هذا الدرس بعض التطبيقات المفيدة التي تسهِّل إدارة خادوم، أو عدِّة خواديم أوبنتو. 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.
  22. تعدّ توزيعتا دبيان وأوبنتو من أكثر توزيعات لينكس تأثيرا، فمن بين حوالي 285 توزيعة نشطة، تُشتقّ 132 من دبيان بما فيها أوبنتو نفسها، إضافة إلى 67 أخرى مشتقة مباشرة من أوبنتو. على الرغم من ذلك تختلف تجربة استخدام الاثنتين في جميع الجوانب تقريبا؛ الأمر الذي يجعل الاختيار، الذي يجب أن يُبنى على التفضيلات في نواح أساسية مثل الدّعم، مستوى تحكّم المستخدِم، سهولة الاستخدام؛ أمرا غير يسير بتاتا. يميل الكثيرون عند وصف الاختلاف بين التوزيعتين إلى أن أوبنتو "توزيعة للمبتدئين"، بينما دبيان هي "خيار الخبراء". رغم أن هذا التوصيف صحيح جزئيا إلا أنه يميل في نفس الوقت إلى المبالغة. لم تتغيّر النظرة إلى دبيان كثيرا في السنوات العشر الأخيرة رغم أنها أصبحت تتيح تسهيلات أكثر للمستخدم الذي يرغب في ذلك. على نحو مشابه؛ يظهر أن استخدام أوبنتو سهل جدا إذا نظرنا للأمر من ناحية مبادئ التصميم إلا أن العادات قد تجعل المستخدِم يختلف في هذا التوصيف. تظهر الفروقات بين التوزيعتين جليةً رغم التشابه؛ بدءًا من التثبيت وسطح المكتب، إلى إدارة الحزم Packages والمجتمع Community، وهي أمور تجعل اختيار المناسب لخطّة عمل مؤسستك غير بديهي. الاختلافات في التثبيت يعتمد اختيار التوزيعة بدرجة مهمّة على نوعية العتاد Hardware لديك. تعمل دبيان حاليا على 13 معمارية عتاد تشمل معماريات 32bit و 64bit المعيارية من Intel، معمارية ARM و PowerPC. بينما تدعم أوبنتو رسميا معماريتي 32bit و 64bit، وتعمل على تطوير دعم معماريات ARM. يجب أيضا أخذ مثبّت Installer كل توزيعة في الحسبان. صُمِّم مثبِّت أوبنتو لكي لا يحتاج إلا إلى الحد الأدنى من المُدخلات من المستخدِم من أجل تسهيل التثبيت وجعله أسرع ما يمكن. يمكنك إن واجهت صعوبة تجربة وضع الخبير في المثبِّت والذي هو في الأساس إعادة تصميم لمثبّت دبيان. مثبِّت دبيان لديه، على الجانب الآخر، أولوياته الخاصة. مثلا، لا يختلف المثبّت الرسومي عن المثبّت على سطر الأوامر سوى في الواجهة. يمكن، على عكس الشائع عن دبيان، تثبيت التوزيعة بسهولة بقبول الخيارات المبدئية في كل مرحلة من مراحل التثبيت. أما إذا كنت تفضّل التخصيص فيمكنك الاختيار من بين الاختيارات المتاحة في كلّ خطوة، مما يزيد بدرجة ملحوظة مدّة التثبيت. يختار مثبِّت دبيان مخاطبة جميع مستويات المستخدمين بدلا من التوجّه إلى المبتدئين. لن تجد، على الأرجح، مثبّتا على نفس المستوى من المرونة. الفروق في إدارة النظام والحزم تنقسم المستودعات في دبيان إلى ثلاثة أساسية: المستودع المستقر Stable، المستودع الاختباري Testing والمستودع غير المستقر Unstable. يمثّل المستودع المستقرّ الإصدار المنصوح به من حزم البرمجيات لبيئات الإنتاج نظرًا لمرورها بالكثير من الاختبارات لتأكيد صلاحيتها، أما المستودع الاختباري فهو نسخة تخضع للاختبار وتتهيأ للمرور إلى المستوى الأعلى (المستودع المستقر)، في حين لا تزال النسخة في المستودع غير المستقر في مرحلة التطوير. أضيفت في السنوات الأخيرة مستودعات أخرى (رسمية وغير رسمية) مثل الحمل العكسي Backports، التجريبي Experimental، الأمان Security وغيرها. إلا أن تلك التي يجب على المستخدمين الانتباه إليها هي الثلاثة الأساسية. يختار مستخدمو دبيان بين الاستقرار منقطع النظير على حساب حداثة الحزم من جهة، والجدّة على حساب استقرار الحزم وتغييرات قد تكون كارثية وتشلّ النظام من جهة أخرى. يختلف تأثير خيار المستودعات أكثر على نوعية الحزم، هل هي حزم أساسية للنظام مثل النواة أو أخرى أقل أهمية مثل أدوات مساعِدة. يمكن مثلا اختيار مستودعات مستقرة للحزم الأساسية ومستودعات اختبارية لأدوات غير أساسية. تأخذ أوبنتو حزمها من مستودعات دبيان الاختبارية أو غير المستقرة وبدلا من تنظيمها حسب مستوى الاستقرار ترتّبها في أربع مستودعات أساسية: Main وتوجد به البرامج المدعومة من Canonical، مستودع Universe وتوجد به برامج حرّة يشرف عليها المجتمع، Restricted ويحوي برامج غير حرّة مُصنَّفة على أنها مهمّة و Multiverse الذي توجد به برامج غير حرة لا تدخل ضمن برامج المستودع السابق. تُضاف بضعة مستودعات أخرى، إلا أن هذه الأربعة هي الأساسية. يوجد فرق مهمّ آخر بين دبيان وأوبنتو وهو في طريقة التعامل مع البرامج غير الحرة؛ فدبيان لا تثبّت مبدئيا سوى الحزم الحرّة ونفس المبدأ يطبّقه المثبِّت الخاصّ بها والذي لا يثبّت الوِحدات غير الحرة في النواة. إنْ احتجت إلى برامج غير حرة فسيلزمك إضافة مقاطع Nonfree و Contrib لكلّ مستودع. لا تظهر التفرقة بين البرامج الحرّة وغير الحرّة بنفس الوضوح في أوبنتو. فرغم أن دبيان تتيح استخدام برامج غير حرّة إلا أنها لا تشجّع على ذلك وتجعلك تدرك أنّ استخدام هذه البرامج مخالف للمبادئ التي تشجّعها دبيان؛ في حين تشجّع أوبنتو على استخدام برامج غير حرّة من أجل توفير تجربة استخدام مشابهة لأنظمة التشغيل التجارية. من فروق إدارة النظام التي يجدر ذكرها هو أن أوبنتو تعطّل مبدئيا إمكانية الدخول المباشر إلى حساب المستخدِم الجذر، مشجّعةً استخدام sudo ما أمكن لتنفيذ المهامّ الإدارية. الفروق في بيئة سطح المكتب تختلف التوزيعتان في بيئة سطح المكتب المبدئيّة لكلّ منهما. تستخدم أوبنتو بيئة يونيتي Unity من تطوير شركة Canonical التي تقف خلف التوزيعة. إن نجحت Canonical في تسويق جوالاتها وأجهزتها اللوحية فسيمكنك في المستقبل الحصول على بيئة سطح المكتب نفسها على جميع أجهزتك (حاسوب، هاتف، حاسوب لوحيّ). تدعم كلّ من دبيان وأوبنتو أكثر من بيئة سطح مكتب. تقدّم أوبنتو أسطح مكتب في ما يشبه توزيعات مستقلة: على سبيل المثال Xubuntu لبيئة سطح المكتب Xfce و Kubuntu لبيئة سطح المكتب KDE. تشبه أسطُح المكتب المتوفّرة في دبيان تلك الموجودة في أوبنتو؛ إلا أن فِرَق التطوير التي تعدّها أقرب إلى توزيعة دبيان المعيارية. تختلف تواريخ إصدارات سطح المكتب لدبيان، فقد تتأخر بعضها قليلا بعد وقت الإصدار الرسمي لدبيان حتى تكون جاهزة (نفس الشيء يحدُث مع أوبنتو). تتوفّر أغلب حزم أوبنتو باستثناء Unity لدبيان؛ كما أن حزم دبيان تتوفّر غالبا لأوبنتو إذ أن الأخيرة تعتمد على حزم من مستودعات دبيان. تكون حزم أوبنتو عادةً أحدث من نظيراتها في دبيان التي تمر بدورة اختبار وتنقيح أطول مما يجعل حزم دبيان أكثر استقرارا. تحذير: لا تفترض أن الأصل المشترك بين الحزم يجعلها متوافقة بين التوزيعتين. يُقدَّر أن حوالي 20 بالمائة من حزم أوبنتو غير متوافقة مع دبيان للاختلافات في التسمية وأماكن الملفات. الفروق في مجتمع التوزيعة يمكن لمجتمعَيْ التوزيعتين أن يكونا معيارا ضمن معايير الاختيار. يشتهر مجتمع دبيان بمناقشته لكلّ قرار بالتفصيل. خصوصا في المسائل ذات الأهمية. تتحوّل النقاشات أحيانا عن مسارها وتصبح أقرب للشحناء. يصوّت جميع مطوّري الحزم الرسميين لاختيار قائد لمشروع دبيان، ومسؤولين آخرين. تسير الأمور على العموم حسب اقتراحات أعضاء المجتمع وإن كان للمسؤولسن المنتخبين سلطة لحدٍّ ما. يختلف مجتمع أوبنتو عن مجتمع دبيان في أن لديه مدونة سلوك Code of Conduct تحكُم التفاعلات في المجتمع. يقود Jono Bacon مجتمع أوبنتو لحدّ الساعة ويبذل مجهودا في حلّ النزاعات بين الأعضاء. يُضاف إلى ذلك مجلس إداري فني للمجتمع يُنتخب سنويا. رغم ذلك يبقى Mark Shuttleworth مؤسّس أوبنتو صاحب القرار الأخير. يملك المؤسس وممثلو Canonical السلطة في تقرير مستقبل التوزيعة وتنتُج عن قراراتهم أحيانا انتفاضات في أوساط المساهمين فيها. خاتمة توجد الكثير من المعايير لأخذها في الحسبان عند الاختيار بين دبيان وأوبنتو: مستخدم مبتدئ أم خبير؟ برنامج حرّ أم خاص؟ سهولة الاستخدام أم التحكم؟ برامج محدَّثة في مقابل برامج مستقرّة، مجتمع مفتوح أو مغلق؟ كلها أمور يجب أن تُراعى وتُدرَس قبل أن تأخذ قرارا قد يؤثّر على مستقبل مؤسستك. ربّما تجد من بين تلك المعايير ما لا يمثّل قيمة كبيرة لك، على عكس أخرى توليها أهمية شديدة. الأساسي أن تحدّد أولوياتك. ترجمة -وبتصرّف- لمقال How Ubuntu is different from Debian لصاحبه M.el Khamlichi.
  23. Redis عبارة عن نظام تخزين مؤقّت cache بنمط مفتاح-قيمة key-value مفتوح المصدر. إن كنت ترغب في استخدام Redis على بيئة الإنتاج الخاصة بك، فإن نسخ بياناتك على خادومين على الأقل يُعتبر من بين أفضل الممارسات (best practices)، تتيح الوفرة الاسترداد في حالة فشل البيئة، ما يُعتبر مهمّا عند نمو قاعدة مستخدمي تطبيقك. بنهاية هذا الدرس، سنضبط خادومي Redis كالتالي: خادوم Redis للمتبوع/السيد (master server) خادوم Redis للتّابع (slave server) سنشرح كذلك كيفيّة الانتقال إلى خادوم التّابع وضبطه كسيّدِِ مؤقّت. لك كامل الحريّة في ضبط أكثر من خادوم واحد خاص بالتابع. هذا الدرس يركز على ضبط عنقود تابع ومتبوع خاص بـredis، لتعلم المزيد عن Redis بشكل عام واستخدامه الأساسي كقاعدة بيانات، ألق نظرة على هذا الدرس. المتطلبات في حين سيعمل هذا على إصدارات أقدم وتوزيعات لينكس أخرى، لكن ننصح باستعمال نظام أوبنتو 14.04. سنعتمد على: نظام أوبنتو Ubuntu 14.04 LTS. خادومين، بأي حجم تريد، واحد متبوع وآخر أو أكثر للتّوابع. ادخل إلى خواديمك عبر SSH مع مستخدم غير جدري مع صلاحيّات sudo كما هو مبيّن في الإعداد الابتدائي لخادوم أوبنتو 14.04 . الخطوة الأولى: تثبيت Redis سنبدأ مع الخادوم الذي سيستضيف المتبوع/السّيّد، وأول خطوة هي تثبيت Redis. أولا نحتاج إلى إضافة مستودع Redis الخاص بـ Chris Lea (كما جرت عليه العادة، توخ الحذر عند إضافة مستودعات طرف ثالث، نستخدم هذا المستودع لأن صاحبه حسنُ السمعة): sudo add-apt-repository ppa:chris-lea/redis-server اضغط ENTER لقبول المستودع. شغل الأمر التالي لتحديث الحزم: sudo apt-get update ثبت خادوم Redis: sudo apt-get update تأكد أنّ Redis مُشغل وقيد التنفيذ: redis-benchmark -q -n 1000 -c 10 -P 5 الأمر أعلاه يخبر بأننا نريد تشغيل الأمر redis-benchmark في وضع صامت، مع 1000 طلبات إجماليّة، 10 اتصالات موازية، و 5 طلبات أنابيب. للمزيد من المعلومات عن هذا الأمر، شغّل الأمر redis-benchmark –help على الطرفيّة لتظهر لك معلومات وأمثلة حول الأمر. بعد انتهاء العمليّة، يجب أن ترى مُخرجات تبدو كالتالي: PING_INLINE: 166666.67 requests per second PING_BULK: 249999.98 requests per second SET: 249999.98 requests per second GET: 499999.97 requests per second INCR: 333333.34 requests per second LPUSH: 499999.97 requests per second LPOP: 499999.97 requests per second SADD: 499999.97 requests per second SPOP: 499999.97 requests per second LPUSH (needed to benchmark LRANGE): 499999.97 requests per second LRANGE_100 (first 100 elements): 111111.12 requests per second LRANGE_300 (first 300 elements): 27777.78 requests per second LRANGE_500 (first 450 elements): 8333.33 requests per second LRANGE_600 (first 600 elements): 6369.43 requests per second MSET (10 keys): 142857.14 requests per second الخطوة الثانية: ضبط Redis المتبوع الآن بما أن Redis قيد التنفيذ على العنقود المتكون من الخادومين، يجب علينا تعديل ملفات الإعدادات. كما سنرى، هناك اختلافات طفيفة بين ضبط الخادوم المتبوع والتابع. لنبدأ أولا مع المتبوع master. افتح الملف etc/redis/redis.conf/ باستخدام محرر النصوص المُفضّل لديك: sudo nano /etc/redis/redis.conf وعدّل الأسطر التّالية: ضع قيمة معقولة لمؤقّت الإبقاء على قيد الحياة KeepAlive للـTCP: tcp-keepalive 60 اجعل الخادوم متاحا للجميع على الويب بجعل هذا السّطر كتعليق (أو بحذفه): #bind 127.0.0.1 بحكم طبيعة Redis وسرعاتها العاليّة قد ينفذ مهاجم هجوم القوة الغاشمة Brute force على كلمة المرور. لذلك ننصح إزالة تعليق سطر requirepass وإضافة كلمة مرور معقّدة (أو من الأفضل أن تكون جملة مرور معقدة): requirepass your_redis_master_password على حسب سيناريو استخدامك، قد ترغب في تعديل السّطر التالي أو لا. لغرض هذا الدرس ، نفترض أن حذف أي مفتاح key deletion ممنوع. قم بإزالة التعليق عن هذا السّطر واضبطه كالتالي: maxmemory-policy noeviction أخيرا، سنقوم بالتعديلات التاليّة، وهي مطلوبة للنسخ الاحتياطي للبيانات. أزل التعليق/أو اضبط هذه الأسطر كالتالي: appendonly yes appendfilename redis-staging-ao.aof احفظ التغييرات. أعد تشغيل خدمة Redis لإعادة تحميل تعديلات الضبط التي قمنا بها. sudo service redis-server restart إذا أردت، يُمكنك إضافة بعض المحتوى إلى قاعدة بيانات المتبوع من خلال اتباع قسم أوامر Redis في هذا الدرس. حتى نتمكن من معرفة كيفية نسخه إلى الخادوم التابع. الآن وبعد أن جهزنا خادوم المتبوع أو السيّد، لننتقل إلى خادوم التابع. الخطوة الثالثة: إعداد Redis التابع نحتاج للقيام ببعض التعديلات التي ستسمح لخادوم التابع بالاتّصال مع المتبوع: افتح الملف etc/redis/redis.conf/ بمحررك المُفضل: sudo nano /etc/redis/redis.conf عدّل الأسطر التالية، بعض الإعدادات ستكون تماما مثل الإعدادات الخاصة بالمتبوع. اجعل الخادوم متاحا للجميع على الويب بتحويل هذا السطر إلى تعليق (عبر إضافة # إلى بدايته): #bind 127.0.0.1 يحتاج التابع كذلك إلى كلمة مرور لنستطيع إعطاء الأوامر له (مثل INFO). أزل التعليق عن هذا السطر وضع كلمة سر للخادوم: requirepass your_redis_slave_password أزل التعليق عن هذا السطر وضع عنوان IP الخاص بالمتبوع، متبوعا برقم المنفذ المضبوط على الخادوم. افتراضيّا يكون الرقم 6379 هو رقم المنفذ: SLAVEOF your_redis_master_ip 6379 تأكد من تغيير your_redis_master_ip إلى عنوان IP الخاص بالمتبوع. احفظ الآن هذه التغييرات، واخرج من الملف. ومن ثم، أعد تشغيل الخدمة كما فعلنا مع خادوم المتبوع: sudo service redis-server restart هذا الأمر سيعيد ضبط Redis وسيحمل الملفات التي عدّلناها. اتصل بـredis: redis-cli -h 127.0.0.1 -p 6379 استوثق بكلمة المرور الخاصة بالتابع: AUTH your_redis_slave_password لقد شغّلنا الآن عنقود Redis يعمل كتابع ومتبوع، مع ضبط كل من الخادومين بشكل صحيح. الخطوة الرابعة: تحقق من نسخ التابع-المتبوع سيسمح لنا اختبار هذا التّنصيب فهم كيفية تصرف خوادم Redis بشكل أفضل، عندما نرغب في بداية برمجة الحماية من الفشل. ما سنفعله الآن هو التحقق من أن الإعدادات تعمل بشكل صحيح، وأن المتبوع يتواصل مع التابع بشكل صحيح. أولا، نتصل بـredis عبر الطرفيّة، على خادوم المتبوع: اتّصل أولا بالنموذج المحليّ، مع استعمال المنفذ الافتراضي 6379. إذا كنت قد غيّرت المنفذ، فغير الأمر بما يناسب: redis-cli -h 127.0.0.1 -p 6379 الآن، استوثق مع Redis باستعمال كلمة المرور التي وضعتها عند ضبط المتبوع: AUTH your_redis_master_password يجب عليك أن تحصل على OK كمُخرج. الآن، كل ما عليك فعله هو تنفيذ الأمر: INFO سترى كلّ ما تحتاج معرفته عن خادوم المتبوع. ما يهمنا هو القسم Replication# والذي يجب أن تبدو كالمخرجات التاليّة: . . . # Replication role:master connected_slaves:1 slave0:ip=111.111.111.222,port=6379,state=online,offset=407,lag=1 master_repl_offset:407 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:406 . . . لاحظ سطر connected_slaves:1، الذي يخبرنا بأن نموذج التابع يتواصل مع الخادوم المتبوع. كما يُمكنك ملاحظة أنّنا حصلنا على عنوان IP الخاص بالتابع، وكذلك المنفذ، الحالة، ومعلومات أخرى. الآن لنلق نظرة على قسم Replication# في الخادوم الخاص بالتابع، العمليّة نفسها التي قمنا بها مع المتبوع، ادخل إلى Redis، طبق الأمر INFO، وانظر إلى المُخرجات: . . . # Replication role:slave master_host:111.111.111.111 master_port:6379 master_link_status:up master_last_io_seconds_ago:3 master_sync_in_progress:0 slave_repl_offset:1401 slave_priority:100 slave_read_only:1 connected_slaves:0 master_repl_offset:0 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0 . . . يُمكننا ملاحظة أن هذا الخادوم يقوم بدور التابع، وأنه يتواصل مع خادوم Redis المتبوع، ولا يملك أي توابع خاصة به. الخطوة الخامسة: التبديل إلى التابع بناء هذه الهندسة يعني أننا نريد التعامل مع الأخطاء والفشل بطريقة يُمكننا التأكد بها من سلامة البيانات وفي أقل وقت توقف ممكن لتطبيقنا. يُمكن لأي تابع أن يرتقي ليصبح متبوعا. أولا، لنختبر التبديل بشكل يدوي. على خادوم التابع، يجب أن نتصل مع نموذج Redis: redis-cli -h 127.0.0.1 -p 6379 الآن قم بالاستيثاق مع Redis باستخدام كلمة المرور التي استخدمتها عند ضبط التابع. AUTH your_redis_slave_password قم بإنهاء دور التابع: SLAVEOF NO ONE يجب الحصول على OK كمُخرج. الآن، نفذ الأمر: INFO قسم Replication# في الرد يجب أن يبدو كالمخرجات التاليّة: . . . # Replication role:master connected_slaves:0 master_repl_offset:1737 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0 . . . كما هو متوقع، فقد تحول التابع إلى متبوع، وهو الآن جاهز لقبول اتّصالات من خوادم أخرى (إذا كانت موجودة). يُمكننا استعماله كمخزن نسخ احتيّاطي مؤقّت أثناء إصلاح الأخطاء في المتبوع الأصلي. إذا كنت تمتلك عدة توابع مُعتمدة على المتبوع الرئيسي، فسيتوجب عليك توجيههم إلى المتبوع الجديد. يُمكن القيّام بذلك بسهولة، بالخطوات التاليّة التي يجب تطبيقها في حال كُشِف عن أيّ أخطاء. من التطبيق، أرسل جميع الطلبات لـredis إلى خادوم تابع. على هذا التابع، نفّذ الأمر SLAVEOF NO ONE. منذ النسخة 1.0.0 من Redis هذا الأمر يُخبر التابع بالتوقف عن نسخ البيانات، والبداية في التصرف كخادوم متبوع. على جميع التابعين المتبقّين (إذا كانوا موجودين)، تشغيل الأمر SLAVEOF hostname port سيوجههم للتوقف عن النسخ من المتبوع القديم، وتجاهل البيانات، والبداية في النسخ من المتبوع الجديد. تأكد من تغيير hostname و port بالمعلومات المناسبة من المتبوع الجديد. بعد حل المشكلة، قد يرجع المتبوع القديم كمتبوع رئيسي، إذا كانت الإعدادات الخاصّة بك تتطلّب ذلك. هناك العديد من الطرق الممكنة لتنفيذ الخطوات أعلاه. ومع ذلك، الأمر يعود لك لتنفيذ أي حل تراه ملائما لبيئتك، وتأكد من اختبارها قبل أن يحدث أي فشل حقيقي. الخطوة السادسة: إعادة الاتصال بالمتبوع الأصلي لنرجع الاتصال بالمتبوع الأصلي. على الخادوم التابع ادخل إلى Redis وشغل الأمر التالي: SLAVEOF your_redis_master_ip 6379 تأكد من تغيير your_redis_master_ip إلى عنوان IP الخاص بالمتبوع إذا قمت بتشغيل الأمر INFO مجددا، يجب أن تلاحظ أنّنا عدنا إلى الإعدادات الأصليّة. في الختام لقد قمنا بإعداد بيئة مكونة من خادومين بنجاح، واحد يتصرف كمتبوع Redis والآخر ينسخ البيانات كتابع. بهذه الطريقة، إذا كان خادوم المتبوع يعاني من أي أخطاء أو فقد بياناتنا علي، فقد تعلمنا كيفية تبديل تابع ليصبح متبوعا كاحتياط إلى حين إصلاح المشكلة. الخطوات التالية تتعلق ببرمجة إجراء الحماية من الخطأ التلقائي، أو ضمان اتصالات آمنة بين جميع خوادمك باستعمال حلول VPN مثل OpenVPN أو Tinc، اختبار الإجراءات والسكربتات للتحقق من صحة إعداداتك. إضافة إلى ذلك، يجب عليك اتخاذ احتياطات عند نشر مثل هذه لإعدادات على بيئات الإنتاج. يجب أن تدرس توثيق Redis ويجب أن تفهم جيدا أي من نماذج الأمان هي الملائمة لتطبيقك. نستعمل عادة Redis كمَخزن للجلسة، وما يحتويه من معلومات قد يكون ذا قيمة لمهاجم ما. الممارسة الشائعة هي أن تمتلك هذه الخواديم إمكانية وصول فقط عبر شبكة خاصة private network. هذه نقطة بداية بسيطة عن كيفية بناء مخزن بيانات خاص بك؛ وليس درسا شاملا عن ضبط Redis لاستخدام هندسة تابع-متبوع. إذا كان هناك أي شيء كنت ترغب في تغطيّته في هذا الدرس، اترك تعليقات أسفله، ولمزيد من المعلومات عن هذا الموضوع، فإن قسم أسئلة DevOps بالأكاديمية تعتبر أماكن جيّدة لتبدأ منها. ترجمة -وبتصرّف- للمقال How To Configure a Redis Cluster on Ubuntu 14.04 لصاحبه Florin Dobre.
  24. تمّ تطوير Redis في عام 2009، وهو مُخزّن بيانات بنمط المفتاح والقيمة (key value)، وهو مفتوح المصدر، ويُقدّم مرونة في الاستخدام، وكما في جميع نمط قواعد البيانات من نوع NoSQL الّتي اتبعها Redis، أمثال Cassandra, CouchDB, MongoDB، فإن Redis يَسمح للمُستخدِم بتخزين كميات ضخمة من البيانات بدون التقيد المفروض بقواعد البيانات العلائقيّة/الارتباطيّة (relational database)، بالإضافة إلى أنّه قد تمّ مُشابهته ومقارنته مع memcache، فيُمكن استخدامه بعناصره الأساسية كنظام تخبئة. إعداد بيئة ومتطلبات Redis قبل الشروع في تنصيب redis، يجب توفّر بعض المُتطلّبات والّتي من شأنها أنّ تجعل من عمليّة التنصيب أكثر سهولة. سيتمّ في البداية تحديث جميع حزم apt-get: sudo apt-get update سيتمّ بعد ذلك تحميل مُترجم (compiler) باستخدام الحزمة build-essential، والّتي من شأنها المساعدة في تنصيب Redis من المصدر: sudo apt-get install build-essential سيتمّ في الخطوة الأخيرة تحميل الأداة tcl الّتي يَعتمد عليها Redis: sudo apt-get install tcl8.5 تنصيب Redis بعد أنّ تمّ تنصيب المُتطلّبات الأساسيّة، فمن المُمكن الآن الشروع وتنصيب redis، ويُمكن تحديد الإصدار المطلوب أو تحميل الإصدار الأخير والذي سيحمل دائمًا الاسم redis-stable: wget http://download.redis.io/redis-stable.tar.gz يجب بعد ذلك فك ضغط الملفّ والانتقال إليه: tar xvzf redis-stable.tar.gz cd redis-stable يجب الآن المُتابعة مع الأمر make: make ولتنصيب Redis على كامل النّظام، فيُمكن إما نسخ ملفاته من المصدر: sudo cp src/redis-server /usr/local/bin/ sudo cp src/redis-cli /usr/local/bin/ أو تنفيذ الأمر التّالي: sudo make install بعد انتهاء عمليّة التنصيب، من المُستحسن تشغيل Redis كحارس (daemon) في خلفيّة النّظام، ولعمل ذلك يأتي Redis بملفّ برمجي (سكريبت) لهذه المُهمّة. يجب الانتقال إلى المسار utils للوصول إلى هذا الملفّ: cd utils ومن ثم تشغيل الملفّ الخاص بتوزيعات Ubuntu/Debian: sudo ./install_server.sh سيَعرض السكريبت بعض الأسئلة لإتمام عمليّة التهيئة، ولكن يُمكن الاعتماد على الإعداد الافتراضي والاكتفاء بالضغط على Enter، وبعد انتهاء عملية التهيئة سيكون خادم Redis يعمل في الخلفيّة (background). يُمكن تنفيذ الأمر التّالي للوصول إلى قاعدة البيانات Redis: redis-cli يُمكن اختبار Redis كالتّالي: $ redis-cli redis 127.0.0.1:6379> ping PONG redis 127.0.0.1:6379> set mykey somevalue OK redis 127.0.0.1:6379> get mykey "somevalue" أوامر Redis يتمّ إضافة بعض المُعطيات إلى سلسلة رموز (string)، والّتي تُعتبر من أبسط أنواع البيانات (datatype)، باستخدام الأمر التّالي: > SET users:SomeOne "job: SomeJob, email:example@example.com, age: some number " OK تمّ في الأمر السابق استخدام الأمر SET متبوعًا بالمُفتاح users:SomeOne، ومن ثمّ القيمة (value)، وهي سلسلة الرموز (string) نفسها. لا تُؤثر النقطتان (:) الموجودة في المُفتاح على الأمر السابق، ولكن من المُمكن الاستفادة منهما في وصف أوضح للمُفتاح المُراد تعيينه. يُمكن استعراض تفاصيل سلسلة الرموز السابقة باستخدام الأمر GET: GET users:SomeOne "job: SomeJob, email:example@example.com, age: some number " المجالات (Ranges) يتمّ تحديد مجال باستخدام مُعاملين والذين سيُمثلان العنصر الأوّل والعنصر الأخير، فالعنصر الأوّل سيُعتبر 0، وإن كان المُعامل الأخير -1، فإن جميع العناصر حتّى نهاية القائمة سيتمّ شملها، فعلى سبيل المثال، إن كانت قائمة تحتوي على ألوان قوس قزح مُرتبة بالترتيب ROYGBV، فيُمكن استعراضها كما في التّالي: > LRANGE ROYGBV 0 3 1) "red" 2) "orange" 3) "yellow" 4) "green" > LRANGE ROYGBV 0 -1 1) "red" 2) "orange" 3) "yellow" 4) "green" 5) "blue" 6) "violet" > LRANGE ROYGBV 3 -1 1) "green" 2) "blue" 3) "violet" انتهاء الصلاحية (Expiration) لا يُعتبر Redis ذو فائدة في تخزين المعلومات فقط، بل يُمكن استخدامه أيضًا في إنهاء صلاحيتها. يُعيّن الوقت اللازم على المُفتاح أنّ يتواجد خلاله إما بالثواني أو باستخدام طابع الوقت الخاصّ يونكس (Unix Time stamp)، ويتحكم الأمر EXPIRE بالمُدّة الّتي يتوجب على المُفتاح التواجد فيها، ويَعرض الأمر TTL الوقت المُتبقي حتّى انتهاء الصلاحيّة. > SET classified:information "Secret Stuff" OK > EXPIRE classified:information 45 (integer) 1 > TTL classified:information (integer) 31 وفي مُحاولة لاستعادة المعلومات بعد انقضاء مدّة الصلاحيّة، ستكون النتيجة هي nil: > GET classified:information (nil) التزايد أو العلاوة (Incrementing) يَملك Redis القدرة على زيادة سلاسل الرموز (strings) في قاعدة بياناته، مع الانتباه أنّه في حال وجود عمليّة جارية في زيادة قيمةٍ ما، فلا يستطيع أمر آخر التدخل والتعديل، هذا الأمر من شأنه أن يجعل من قاعدة البيانات ثابتة وغير شائبة. > SET population 6 OK > INCRBY population 10 (integer) 16 > INCR population (integer) 17 المداولات (Transactions) يملك Redis القدرة على إنجاز المُداولات (transactions)، والّتي يجب أنّ تخضع إلى: تنفيذ الأوامر بالترتيب، ولن يتمّ مقاطعتها خلال العمليّة من قبل طلبات أُخرى. على المُداولات أنّ تُعالج كلها دفعةً واحدة. تبدأ المُداولات بالأمر MULTI وبعد ذلك لتنفيذها يتمّ استخدام الأمر EXEC. سيتمّ الخروج من المُداولة، عند أي مُقاطعة للعمليّة، وسيواجه Redis خطًا سيوقفه من إعادة التشغيل حتّى تنفيذ الأمر edis-check-aof ليتمّ التراجع عن المُداولة الجزئية الّتي تمّت بالفعل قبل حدوث الخطأ وحذفها. سيَتمكّن الخادم بعد ذلك من إعادة التشغيل. > MULTI OK > SET population 6 QUEUED > INCRBY population 10 QUEUED > INCR population QUEUED > EXEC 1) OK 2) (integer) 16 3) (integer) 17 أنواع البيانات في Redis يَملك Redis خمسة أنواع من البيانات: Strings Sets Sorted Sets Lists Hashes سلاسل الرموز (Strings) تُعتبر سلاسل الرموز جوهر وأساس الأنواع في Redis الأوامر التّالية هي الأوامر الشائعة مع سلاسل الرموز: SET: يُعيّن قيمة إلى مُفتاح. GET: يجلب قيمة من مُفتاح. DEL: حذف مُفتاح وقيمته. INCR: زيادة قيمة مُفتاح. INCRBY: زيادة قيمة مُفتاح بقيم مُحدّدة. EXPIRE: الوقت اللازم على المُفتاح التواجد به، ويُعيّن بالثواني. تُستخدم سلاسل الرموز في تخزين الكائنات (objects): > SET newkey "the redis string begins" OK > GET newkey "the redis string begins" المجموعات (Sets) يُمكن الجمع بين سلاسل الرموز (strings)، ولذلك يُمكن استخدام مجموعات Redis، والّتي يُمكن القول عنها أنها مجموعة من سلاسل الرموز غير المُرتبة. بعض الأوامر الشائعة مع المجموعات: SADD: إضافة عنصر أو عناصر إلى مجموعة. SMEMBERS: جلب جميع العناصر المُعيّنة. SINTER: إيجاد تقاطع أكثر من مجموعة. SISMEMBER: التأكّد من وجود قيمة في مجموعة. SRANDMEMBER: جلب عنصر عشوائي. يُستفاد من المجموعات في Redis في العديد من الحالات، ولأن كل عنصر من مجموعة هو فريد، فإن إضافة عنصر إلى المجموعة لا يتطلّب عمليّة “افحص قبل الإضافة”، بدلًا من ذلك، فإن المجموعة ستتأكّد فيما إذا كان العنصر مكرّرًا أم لا، وذلك عند أي تنفيذ للأمر SADD: > SADD colors red (integer) 1 redis 127.0.0.1:6379> SADD colors orange (integer) 1 redis 127.0.0.1:6379> SADD colors yellow (integer) 1 redis 127.0.0.1:6379> SADD colors orange (integer) 0 redis 127.0.0.1:6379> SMEMBERS colors 1) "red" 2) "yellow" 3) "orange" يُستفاد من المجموعات بشكل خاصّ في فحص وضبط عناوين IPs في حال أنها فريدة لزوار صفحة ما، أو مثلًا في استخلاص عناصر بشكل عشوائي بالأمر SRANDMEMBER. المجموعات المرتبة (Sorted Sets) إن المجموعات المُرتبة هي اسمٌ على مُسمّى، فهي مجموعة من سلاسل الرموز (strings) مُرتبطة مع رقم مع ترتيب، وهو بشكلٍ افتراضيّ من الأصغر إلى الأكبر. يَعمل هذا النوع من البيانات بشكل مُلائم جدًا مع المجالات (ranges)، وبسبب التّرتيب الخاصّ به، فإن إضافة وحذف وتحديث القيم تتمّ بسرعة ملحوظة. بعض الأوامر الشائعة مع المجموعات المُرتّبة: ZADD: إضافة عناصر إلى مجموعة مُرتّبة. ZRANGE: عرض عناصر مجموعة مُرتّبة. ZREVRANGE: عرض عناصر مجموعة مُرتّبة بشكل عكسي. ZREM: إزالة عناصر من مجموعة مُرتّبة. يُمكن إنشاء مجموعة مُرتّبة كما في المثال التّالي، وهو لمساحة بعض البلدان، فعلى الرغم من تعيينها بشكل عشوائي، فإن استعراضها يَكون على التّرتيب: > ZADD countries 9 Tuvalu (integer) 1 > ZADD countries 62 Liechtenstein (integer) 1 > ZADD countries .7 Monaco (integer) 1 > ZADD countries .2 VaticanCity (integer) 1 > ZADD countries 107 Seychelles (integer) 1 redis 127.0.0.1:6379> ZRANGE countries 0 -1 1) "VaticanCity" 2) "Monaco" 3) "Tuvalu" 4) "Liechtenstein" 5) "Seychelles" القوائم (Lists) تُعتبر القوائم في Redis مجموعة من القيم المُرتّبة، وبالتّالي فهي عكس المجموعات (Sets)، والّتي هي غير مُرتّبة، فيُمكن إضافة عناصر إلى بداية ونهاية قائمة، حتّى بوجود ملايين العناصر داخل القائمة، وبسرعة كبيرة جدًا. الأوامر الأكثر شيوعًا مع القوائم: LPUSH: إضافة قيمة في بداية قائمة. RPUSH: إضافة قيمة في نهاية قائمة. LPOP: جلب وإزالة العنصر الأوّل في قائمة. LREM: إزالة العناصر من قائمة. LRANGE: جلب مجال من العناصر من قائمة. LTRIM: تعديل قائمة بترك عناصر مُحدّدة من مجال. أمثلة: > RPUSH lunch.provider alice (integer) 1 > RPUSH lunch.provider bob (integer) 2 > RPUSH lunch.provider carol (integer) 3 > RPUSH lunch.provider don (integer) 4 > RPUSH lunch.provider emily (integer) 5 عند الرغبة بالدفع (push) إلى واجهة صف الانتظار (queue)، فمن المُمكن استخدام الأمر LPUSH: LPUSH lunch.provider zoe (integer) 6 يُمكن استخدام الأمر LRANGE لاستعراض عناصر القائمة جميعًا: LRANGE lunch.provider 0 -1 1) "zoe" 2) "alice" 3) "bob" 4) "carol" 5) "don" 6) "emily" تُستخدم القوائم في مُعظم الأحيان لإنشاء خط زمني للأحداث، أو في الحفاظ على مجموعة مُحدودة من العناصر المبعثرات (Hashes) تُعتبر المبَعثرات في Redis من الأدوات المُفيدة في تمثيل الكائنات (objects) ذو العديد من الحقول (fields)، فهي مُعدّة لتخزين عدد هائل من الحقول في حجم صغير، وتستطيع البَعثرة تخزين أكثر من أربعة مليارات من أزواج قيم الحقول (field-value). بعض أوامر البعثرة الأكثر شيوعًا في Redis: HMSET: تعيين قيم بعثرة مُتعدّدة. HSET: تعيين حقل البعثرة بقيمة سلسلة رموز (string). HGET: جلب قيمة حقل البعثرة. HMGET: جلب جميع القيم من حقول البعثرة المعطاة. HGETALL: جلب جميع القيم لبعثرة ما. تُستخدم البَعثرة في وصف حساب المُستخدِم: > HMSET user:1 username someuser password 4bAc0s email someuser@example.com OK > HGETALL user:1 1) "username" 2) "jsmith" 3) "password" 4) "4bAc0s" 5) "email" 6) "jsmith@gmail.com" يتمّ استخدام الأمر HMGET للبحث عن معلومة مُحدّدة، وعرض القيم للحقول المطلوبة فقط. > HMGET user:1 username email 1) "someuser" someuser@example.com الختام انتشر Redis بسرعة كبيرة، واكتسب شهرةً واسعة بين المواقع أمثال: Github, Flickr, Disqus، وغيرها من المواقع، وذلك لتوافقه مع مُعظم لغات البرمجة، فهو بالفعل تقنية مُفيدة يُنصح بالاعتماد عليها وتجربتها. ترجمة -وبتصرّف- للمقال How To Install and Use Redis لصاحبته Etel Sverdlov.
  25. في كثير من الأحيان يحتاج مدراء أنظمة لينكس للإطلاع على ملفات السجلات (log files) للكشف عن الأخطاء والمشاكل، وهذا الأمر في الحقيقة يجب على أي مدير نظام القيام به. يستطيع نظام لينكس ومُختلف التطبيقات توليد مختلف أنواع الرسائل والتي يتم تسجيلها في ملفات السجلات المختلفة، ويستخدم نظام لينكس مجموعة من ملفات الإعدادات والمجلدات والبرامج والأوامر والعفاريت (daemons) لإنشاء وتخزين وحذف رسائل السجل. ولذلك فإن معرفة المكان الذي يحتفظ فيه النظام على ملفات السجلات وكيفية استخدام الأوامر المتعلقة به يمكن أن يساعدك على توفير وقتك الثمين أثناء استكشاف الأخطاء وإصلاحها. في هذا الدرس، سنلقي نظرة على مُختلف جوانب السّجلات وإدارتها على أنظمة لينكس ملاحظة: تم اختبار هذه الأوامر على أنظمة CentOS 6.4 و Ubuntu 12 و Debian 7. الموقع الافتراضي لملفات السجلات إن الموقع الافتراضي لملفات السجلات هو var/log/. يمكنك رؤية قائمة الملفات الموجودة في هذا المجلد عن طريق الأمر: ls -l /var/log هذه قائمة ملفات السجلات الموجودة في نظام CentOS الخاص بي: total 1472 -rw-------. 1 root root 4524 Nov 15 16:04 anaconda.ifcfg.log -rw-------. 1 root root 59041 Nov 15 16:04 anaconda.log -rw-------. 1 root root 42763 Nov 15 16:04 anaconda.program.log -rw-------. 1 root root 299910 Nov 15 16:04 anaconda.storage.log -rw-------. 1 root root 40669 Nov 15 16:04 anaconda.syslog -rw-------. 1 root root 57061 Nov 15 16:04 anaconda.xlog -rw-------. 1 root root 1829 Nov 15 16:04 anaconda.yum.log drwxr-x---. 2 root root 4096 Nov 15 16:11 audit -rw-r--r-- 1 root root 2252 Dec 9 10:27 boot.log -rw------- 1 root utmp 384 Dec 9 10:31 btmp -rw-------. 1 root utmp 1920 Nov 28 09:28 btmp-20131202 drwxr-xr-x 2 root root 4096 Nov 29 15:47 ConsoleKit -rw------- 1 root root 2288 Dec 9 11:01 cron -rw-------. 1 root root 8809 Dec 2 17:09 cron-20131202 -rw-r--r-- 1 root root 21510 Dec 9 10:27 dmesg -rw-r--r-- 1 root root 21351 Dec 6 16:37 dmesg.old -rw-r--r--. 1 root root 165665 Nov 15 16:04 dracut.log -rw-r--r--. 1 root root 146876 Dec 9 10:44 lastlog -rw------- 1 root root 950 Dec 9 10:27 maillog -rw-------. 1 root root 4609 Dec 2 17:00 maillog-20131202 -rw------- 1 root root 123174 Dec 9 10:27 messages -rw-------. 1 root root 458481 Dec 2 17:00 messages-20131202 -rw------- 1 root root 2644 Dec 9 10:44 secure -rw-------. 1 root root 15984 Dec 2 17:00 secure-20131202 -rw------- 1 root root 0 Dec 2 17:09 spooler -rw-------. 1 root root 0 Nov 15 16:02 spooler-20131202 -rw-------. 1 root root 0 Nov 15 16:02 tallylog -rw-rw-r--. 1 root utmp 89856 Dec 9 10:44 wtmp -rw------- 1 root root 3778 Dec 6 16:48 yum.log عرض محتويات ملف السجل هذه قائمة من ملفات السجلات الشائعة التي يمكن أن تجدها في مجلد /var/log/: wtmp utmp dmesg messages maillog أو mail.log spooler auth.log أو secure إن ملفات wtmp و utmp تتبع تسجيل دخول وخروج المستخدمين ولا يمكنك عرض محتويات هذه الملفات باستخدام الأمر cat أو ما شابه، فهنالك أوامر خاصة لفعل ذلك. سوف نتعلم في هذا الدرس بعضا من هذه الأوامر. لتعرف من الذي سجّل دخوله حاليا في خادوم لينكس يمكنك بسهولة استخدام الأمر who، وهذا الأمر يحصل على بياناته من ملف var/run/utmp/ (لأنظمة CentOS وDebian) أو من ملف run/utmp/ (لأنظمة أوبنتو). هذا مثال من نظام CentOS: who root tty1 2013-12-09 10:44 root pts/0 2013-12-09 10:29 (10.0.2.2) sysadmin pts/1 2013-12-09 10:31 (10.0.2.2) joeblog pts/2 2013-12-09 10:39 (10.0.2.2) في هذه الحالة بالذات، أنا المستخدم الوحيد للنظام ولقد شغّلت الخادوم من Oracle VirtualBox ومن ثم استطعت الوصول إليه كمستخدم جذر من الطرفية من جلسة SSH، أما بالنسبة للمستخدميْن الآخريْن (sysadmin وjoebolg) فهم أيضا فتحا جلسات لهما على النظام. الأمر last يخبرنا بتاريخ تسجيل الدخول للمستخدمين: last | grep sysadmin sysadmin pts/1 10.0.2.2 Mon Dec 9 10:31 still logged in sysadmin pts/0 10.0.2.2 Fri Nov 29 15:42 - crash (00:01) sysadmin pts/0 10.0.2.2 Thu Nov 28 17:06 - 17:13 (00:06) sysadmin pts/0 10.0.2.2 Thu Nov 28 16:17 - 17:05 (00:48) sysadmin pts/0 10.0.2.2 Thu Nov 28 09:29 - crash (06:04) sysadmin pts/0 10.0.2.2 Wed Nov 27 16:37 - down (00:29) sysadmin tty1 Wed Nov 27 14:05 - down (00:36) sysadmin tty1 Wed Nov 27 13:49 - 14:04 (00:15) في هذا المثال، أحاول إيجاد تاريخ تسجيل الدخول لمستخدم sysadmin، وكما ترى، فهنالك أمثلة لبضعة حالات توقّف فيها النظام. لتعرف متى كانت آخر مرة تم إعادة تشغيل (reboot) النظام، يمكننا كتابة الأمر التالي: last reboot وستكون النتيجة مشابهة لهذه: reboot system boot 2.6.32-358.el6.x Mon Dec 9 10:27 - 10:47 (00:19) reboot system boot 2.6.32-358.el6.x Fri Dec 6 16:37 - 10:47 (2+18:10) reboot system boot 2.6.32-358.el6.x Fri Dec 6 16:28 - 16:36 (00:08) reboot system boot 2.6.32-358.el6.x Fri Dec 6 11:06 - 16:36 (05:29) reboot system boot 2.6.32-358.el6.x Mon Dec 2 17:00 - 16:36 (3+23:36) reboot system boot 2.6.32-358.el6.x Fri Nov 29 16:01 - 16:36 (7+00:34) reboot system boot 2.6.32-358.el6.x Fri Nov 29 15:43 - 16:36 (7+00:53) ... ... wtmp begins Fri Nov 15 16:11:54 2013 وإذا أردت معرفة متى سجّل شخص معين دخوله آخر مرة إلى النظام، استخدم الأمر lastlog: lastlog في نظامي، ستكون النتيجة مشابهة لهذه: Username Port From Latest root tty1 Mon Dec 9 10:44:30 +1100 2013 bin **Never logged in** daemon **Never logged in** adm **Never logged in** lp **Never logged in** sync **Never logged in** shutdown **Never logged in** halt **Never logged in** mail **Never logged in** uucp **Never logged in** operator **Never logged in** games **Never logged in** gopher **Never logged in** ftp **Never logged in** nobody **Never logged in** vcsa **Never logged in** saslauth **Never logged in** postfix **Never logged in** sshd **Never logged in** sysadmin pts/1 10.0.2.2 Mon Dec 9 10:31:50 +1100 2013 dbus **Never logged in** joeblog pts/2 10.0.2.2 Mon Dec 9 10:39:24 +1100 2013 بالنسبة لبقية ملفات السجل النصية، يمكنك استخدام أوامر cat أو head أو tail لقراءة محتوياتها. في المثال بالأسفل، أحاول النظر إلى آخر 10 أسطر من ملف var/log/messages/ في نظام Debian: sudo tail /var/log/messages ستكون المخرجات كالآتي: Dec 16 01:21:08 debian kernel: [ 9.584074] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 Dec 16 01:21:08 debian kernel: [ 9.584074] Bluetooth: BNEP filters: protocol multicast Dec 16 01:21:08 debian kernel: [ 9.648220] Bridge firewalling registered Dec 16 01:21:08 debian kernel: [ 9.696728] Bluetooth: SCO (Voice Link) ver 0.6 Dec 16 01:21:08 debian kernel: [ 9.696728] Bluetooth: SCO socket layer initialized Dec 16 01:21:08 debian kernel: [ 9.832215] lp: driver loaded but no devices found Dec 16 01:21:08 debian kernel: [ 9.868897] ppdev: user-space parallel port driver Dec 16 01:21:11 debian kernel: [ 12.748833] [drm] Initialized drm 1.1.0 20060810 Dec 16 01:21:11 debian kernel: [ 12.754412] pci 0000:00:02.0: PCI INT A -> Link[LNKB] -> GSI 11 (level, low) -> IRQ 11 Dec 16 01:21:11 debian kernel: [ 12.754412] [drm] Initialized vboxvideo 1.0.0 20090303 for 0000:00:02.0 on minor 0 عفريت rsyslog في قلب آلية التّسجيل نجد عفريت rsyslog، وهذه الخدمة مسؤولة عن الاستماع إلى رسائل السجلات من مختلف أجزاء نظام لينكس ومن ثم توجيه الرسالة إلى ملف السجل الصحيح في مجلد var/log/ وكما يمكنها إعادة إرسال رسائل السجلات إلى خواديم لينكس آخرى. ملف إعدادات rsyslog يحصل عفريت rsyslog على إعداداته من ملف rsyslog.conf الموجود في مجلد etc/، ويعمل هذا الملف أساسا على اخبار عفريت rsyslog أين يحفظ رسائل السجلات، وهذه التعليمات تأتي من سلسلة أسطر متكونة من جزئين داخل الملف. يمكن إيجاد هذا الملف في rsyslog.d/50-default.conf في نظام أوبنتو. تتكون مجموعتا التعليمات من محدد (selector) وإجراء (action)، ويتم الفصل بين الجزئين بفراغ. يُحدد جزء "المحدد" مصدر وأهمية رسالة السجل وأما جزء "الإجراء" فيحتوي على ما يجب فعله مع تلك الرسالة. ينقسم جزء "المحدد" إلى جزئين مفصولين بنقطة .، ويسمى الجزء الأول بـ facility (جزء أصل الرسالة) وأما الثاني وهو الذي يأتي بعد النقطة فيسمى بـ priority (جزء درجة أهمية الرسالة) ومعا، أي جزئي facility/priority والإجراء يخبران rsyslog ماذا يفعل عندما يتم إنشاء رسالة تتطابق مع المعايير. هذا مقتطف من ملف rsyslog.conf على توزيعة CentOS: # rsyslog v5 configuration file ... ... # Include all config files in /etc/rsyslog.d/ IncludeConfig /etc/rsyslog.d/*.conf #### RULES #### # Log all kernel messages to the console. # Logging much else clutters up the screen. #kern.* /dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none /var/log/messages # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* -/var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg * # Save news errors of level crit and higher in a special file. uucp,news.crit /var/log/spooler # Save boot messages also to boot.log local7.* /var/log/boot.log ... ... لنفهم السطور السابقة، دعونا ننظر في أنواع المختلفة من المنشئات (facilities) التي يعترف بها نظام لينكس: auth أو authpriv: الرسائل التي تأتي من الأحداث المرتبطة بالأمن والتراخيص (authorization). kern: للرسائل القادمة من نواة لينكس. mail: للرسائل التي تم إنشاؤها من نظام الفرعي للبريد. cron: للرسائل المتعلقة بعفريت Cron. daemon: للرسائل القادمة من العفاريت. news: للرسائل القادم من النظام الفرعي لأخبار الشبكة. lpr: لرسائل السجل المتعلقة بالطباعة. user: لرسائل السجل القادمة من برامج المستخدم. من local0 إلى local7: محجوزة للاستخدام المحلي. وهذه قائمة من الأولويات بترتيب تصاعدي: debug: بيانات تنقيح البرامج. info: رسالة معلومات بسيطة - لا يلزم التدخل. notice: حالة قد تتطلب الاهتمام. warn: تحذير. err: خطأ. crit: حالة حرجة. alert: حالة تتطلب تدخلًا فوريًا. emerg: حالة طارئة مستعجلة. والآن دعونا ننظر إلى هذا السطر من الملف: cron.* /var/log/cron هذا السطر سيخبر عفريت rsyslog بحفظ جميع الرسائل من عفريت cron في ملف يدعى var/log/cron/، وأما رمز * بعد النقطة فيعني أن الرسائل من جميع الأولويات سيتم تسجيلها، وبالمثل فإذا تم وضع رمز * في المنشأ (facility) فذلك يعني لجميع المصادر. يمكن أن تكون المنشئات والأولويات مرتبطة بعدة طرق، ففي الشكل الافتراضي، عندما يكون هنالك أولوية واحد محددة بعد النقطة، فذلك يعني تحديد جميع الأحداث التي أولويتها أكبر أو تساوي تلك الأولوية، لذلك في الموجه التالي فإنه سيتم تسجيل جميع الرسائل القادمة من نظام الفرعي للبريد والتي تكون أولويتها من نوع تحذير فما فوق في ملف خاص داخل مجلد var/log/: mail.warn /var/log/mail.warn سيتم تسجيل جميع الرسائل التي تساوي أولويتها لـ "تحذير" فما فوق وتتُرك بقية الرسائل التي تكون أولويتها أقل من ذلك، أي أن الرسائل ذات أولوية err أو crit أو alert أو emerg لن يتم تسجيلها في الملف. إذا تم استخدام رمز المساواة = بعد النقطة فسيتم تسجيل فقط الأولوية المطابقة، أي أنه إذا أردت الحصول على رسائل info فقط القادمة من نظام الفرعي للرسائل، فإنك ستكتب شيء مشابه لهذا: mail.=info /var/log/mail.info مرة أخرى، إذا أردت الحصول على جميع الرسائل من نظام الفرعي للبريد ماعدا رسائل info، فإنك ستكتب شيئًا مشابهًا لهذا: mail.!info /var/log/mail.info أو هذا: mail.!=info /var/log/mail.info في الحالة الأولى، سيحتوي ملف mail.info على جميع الرسائل التي تملك أولوية أقل من info، وفي الحالة الثانية، سيحتوي هذا الملف على جميع الرسائل التي تملك أولوية أكبر من info. في حالة وجود أكثر من مَنشأ على نفس السطر فيجب الفصل بينها بواسطة فواصل، وفي حالة وجود مصادر متعددة (facility.priority) في نفس السطر فيجب الفصل بينها بواسطة الفاصلة المنقوطة. عندما يتم وضع علامة * لأحد الإجراءات فهذا يعني أن الإجراء لجميع المستخدمين. هذا السطر في ملف rsyslog.conf في نظام CentOS يخبرنا بهذا الشيء: # Everybody gets emergency messages *.emerg * حاول أن تعرف ماذا يقول ملف rsyslog.conf في نظام لينكس، فهذا مقتطف من خادوم نظام ديبيان الذي أعمل عليه: # /etc/rsyslog.conf Configuration file for rsyslog. # # For more information see # /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html ... ... auth,authpriv.* /var/log/auth.log *.*;auth,authpriv.none -/var/log/syslog #cron.* /var/log/cron.log daemon.* -/var/log/daemon.log kern.* -/var/log/kern.log lpr.* -/var/log/lpr.log mail.* -/var/log/mail.log user.* -/var/log/user.log # # Logging for the mail system. Split it up so that # it is easy to write scripts to parse these files. # mail.info -/var/log/mail.info mail.warn -/var/log/mail.warn mail.err /var/log/mail.err # # Logging for INN news system. # news.crit /var/log/news/news.crit news.err /var/log/news/news.err news.notice -/var/log/news/news.notice كما ترى، يحفظ ديبيان جميع الرسائل ذات مستوى أمني/تراخيص في var/log/auth.log/ في حين أن CentOS يحفظها في var/log/secure/. إن إعدادات rsyslog يمكن أن تأتي من ملفات خاصة أخرى، هذه الملفات الخاصة موجودة في العادة في مجلدات مختلفة داخل مجلد etc/rsyslog.d/ ويحتوي ملف rsyslog.conf على جميع هذه المجلدات باستخدام موجه IncludeConfig$. هكذا يبدو شكلها في نظام أوبنتو: # Default logging rules can be found in /etc/rsyslog.d/50-default.conf .... .... $IncludeConfig /etc/rsyslog.d/*.conf تبدو المحتويات الموجودة في مجلد etc/rsyslog.d/ كالتالي: -rw-r--r-- 1 root root 311 Mar 17 2012 20-ufw.conf -rw-r--r-- 1 root root 252 Apr 11 2012 21-cloudinit.conf -rw-r--r-- 1 root root 1655 Mar 30 2012 50-default.conf لا يجب أن تكون وجهة رسائل السجل بالضرورة هي ملف السجل، فيمكن أن تُرسل الرسالة إلى طرفية المستخدم، وفي هذه الحالة، سيحتوي حقل الإجراء على اسم المستخدم، وإذا كنت تحتاج إلى إرسال الرسالة إلى أكثر من مستخدم واحد، فيجب فصل أسماء المستخدمين بفواصل وإذا أردت إرسالها لجميع المستخدمين فيمكنك وضع الرمز * في حقل الإجراء. بما أن عفريت rsyslog جزء من نظام تشغيل الشبكة، فلا يُمكنه حفظ السّجلات محليا فحسب، وإنما يمكنه أن يُرسلها إلى خواديم لينكس أخرى في الشبكة أو أن يُصبح مستودعًا لبقية الأنظمة. فالعفريت يستمع لرسائل السجل من منفذ UDP 514. المثال التالي سيُغير وجهة الرسائل الحرجة للنواة إلى خادوم يدعى texas. kern.crit @texas إنشاء واختبار رسائل سجل الخاصة بك حان الآن وقت إنشاء ملفات سجل خاصة بنا، ولتجربة هذا سنحتاج إلى التالي: إضافة مواصفات ملف السجل في ملف etc/rsyslog.conf/ إعادة تشغيل عفريت rsyslog تجربة الإعدادات باستخدام أداة logger في المثال التالي، أضفت سطرين جديدين إلى ملف rsyslog.conf التابع لنظام لينكس CentOS الخاص بي، وكما ترى، كل واحد منها قادم من منشأ يدعى local4 ولديهم أولويات مختلفة. vi /etc/rsyslog.conf .... .... # New lines added for testing log message generation local4.crit /var/log/local4crit.log local4.=info /var/log/local4info.log بعد ذلك، سيتم إعادة تحميل ملف الإعدادات عند إعادة تشغيل الخدمة: /etc/init.d/rsyslog restart Shutting down system logger: [ OK ] Starting system logger: [ OK ] الآن، تم استدعاء تطبيق التسجيل لإنشاء رسالة سجل: logger -p local4.info " This is a info message from local 4" الآن، عند النظر إلى مجلد var/log/ سوف تجد ملفين جديدين: ... ... -rw------- 1 root root 0 Dec 9 11:21 local4crit.log -rw------- 1 root root 72 Dec 9 11:22 local4info.log إن حجم ملف local4info.log لا يساوي صفر، لذلك عندما يتم فتحه، سأرى الرسالة التي تم تسجيلها: cat /var/log/local4info.log Dec 9 11:22:32 TestLinux root: This is a info message from local 4 تدوير ملفات السجل كلما زادت المعلومات المكتوبة في ملفات السجل ازداد حجمها، ومن الواضح أن هذا الأمر سيقلل من الأداء وستكون إدارة هذه الملفات عملية متعبة. لينكس يستخدم مفهوم "التدوير" لملفات السجل بدلا من تنظيفها أو حذفها، عندما يتم تدوير سجل معين، سيتم إنشاء ملف جديد وتغيير اسم الملف القديم وضغطه بشكل إختياري. يمكن لملف السجل أن يملك عدة نسخ قديمة لا تزال موجودة، وهذه الملفات قد تعود لفترات قديمة من الزمن وستكون كسجل متراكم، وعند إنشاء عدد معين من هذه المتراكمات سيتسبب السجل المُدوّر بحذف ملف السجل الأقدم . يتم تشغيل التدوير عن طريق أداة logrotate. ملف إعدادات logrotate يعتمد logrotate مثل rsyslog على ملف الإعدادات واسم هذا الملف هو logrotate.conf وهو موجود في etc/. هذا ما أراه في ملف logrotate.conf على خادوم ديبيان الخاص بي: cat /etc/logrotate.conf # see "man logrotate" for details # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # create new (empty) log files after rotating old ones create # uncomment this if you want your log files compressed #compress # packages drop log rotation information into this directory include /etc/logrotate.d # no packages own wtmp, or btmp -- we'll rotate them here /var/log/wtmp { missingok monthly create 0664 root utmp rotate 1 } /var/log/btmp { missingok monthly create 0660 root utmp rotate 1 } # system-specific logs may be configured here الأسطر مفهومة وتشرح نفسها بنفسها، بشكل افتراضي، ملفات السجل يتم تدويرها بشكل أسبوعي مع الإبقاء على أربع سجلات في وقت واحد، عندما يشتغل البرنامج سيتم إنشاء ملف سجل جديد وسيتم ضغط الملف القديم اختياريا. الاستثناء الوحيد هو في ملفات wtmp و btmp، فملفات wtmp تتبع تسجيلات الدخول للنظام وأما btmp فهي تتبع تسجيلات الدخول النظام الخاطئة، كلا هذين الملفين يتم تدوريهما كل شهر ولن يتم إرجاع أي خطأ إذا كان أحد الملفات السابقة لـ wtmp أو btmp غير موجود. يتم الاحتفاظ بملفات إعدادات التّدوير المخصصة في مجلد etc/logrotate.d/، وهذه أيضا يتم تضمينها في ملف logrotate.conf مع التوجيه. يعرض لي نظام ديبيان محتويات هذا المجلد: ls -l /etc/logrotate.d total 44 -rw-r--r-- 1 root root 173 Apr 15 2011 apt -rw-r--r-- 1 root root 79 Aug 12 2011 aptitude -rw-r--r-- 1 root root 135 Feb 24 2010 consolekit -rw-r--r-- 1 root root 248 Nov 28 2011 cups -rw-r--r-- 1 root root 232 Sep 19 2012 dpkg -rw-r--r-- 1 root root 146 May 12 2011 exim4-base -rw-r--r-- 1 root root 126 May 12 2011 exim4-paniclog -rw-r--r-- 1 root root 157 Nov 16 2010 pm-utils -rw-r--r-- 1 root root 94 Aug 8 2010 ppp -rw-r--r-- 1 root root 515 Nov 30 2010 rsyslog -rw-r--r-- 1 root root 114 Nov 26 2008 unattended-upgrades محتويات ملف rsyslog تظهر لك كيف يتم تدوير بعض ملفات السجل: cat /etc/logrotate.d/rsyslog /var/log/syslog { rotate 7 daily missingok notifempty delaycompress compress postrotate invoke-rc.d rsyslog reload > /dev/null endscript } /var/log/mail.info /var/log/mail.warn /var/log/mail.err /var/log/mail.log /var/log/daemon.log /var/log/kern.log /var/log/auth.log /var/log/user.log /var/log/lpr.log /var/log/cron.log /var/log/debug /var/log/messages { rotate 4 weekly missingok notifempty compress delaycompress sharedscripts postrotate invoke-rc.d rsyslog reload > /dev/null endscript } كما ترى، إن ملف syslog ستتم إعادة تهيئته يوميا مع إبقاء ملفات السجل لمدة 7 أيام، أما بقية ملفات السجل فيتم تدويرها أسبوعيا. كما لا ننسى موجه postrotate فهو جدير بالذكر أيضا، فهذا الإجراء يحدد ماذا يحدث بعد الانتهاء من كامل عملية إعادة تدوير ملف السجل. تجربة التدوير يمكن أن يشتغل Logrotate يدويا لإعادة تدوير ملف أو أكثر، ولفعل ذلك، يمكننا ببساطة تحديد ملف الإعدادات الخاص بالأمر كمعامل لهذا الأمر. لنرى كيف يعمل، هذه قائمة جزئية من ملفات السجل موجود في مجلد var/log/ على الخادوم التجريبي CentOS الخاص بي: ls -l /var/log total 800 ... -rw------- 1 root root 359 Dec 17 18:25 maillog -rw-------. 1 root root 1830 Dec 16 16:35 maillog-20131216 -rw------- 1 root root 30554 Dec 17 18:25 messages -rw-------. 1 root root 180429 Dec 16 16:35 messages-20131216 -rw------- 1 root root 591 Dec 17 18:28 secure -rw-------. 1 root root 4187 Dec 16 16:41 secure-20131216 ... ... سوف تبدو المحتويات الجزئية لملف logrotate.conf كالتالي: cat /etc/logrotate.conf # see "man logrotate" for details # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # create new (empty) log files after rotating old ones create ... ... بعد ذلك قمنا بتشغيل أمر logrotate: logrotate -fv /etc/logrotate.conf سيتم نقل الرسائل عند إنشاء الملفات الجديدة والتعامل مع الأخطاء. وعندما يتنهي كل هذا، سنحاول التأكد من ملفات mail وsecure و messages الجديدة: ls -l /var/log/mail* -rw------- 1 root root 0 Dec 17 18:34 /var/log/maillog -rw-------. 1 root root 1830 Dec 16 16:35 /var/log/maillog-20131216 -rw------- 1 root root 359 Dec 17 18:25 /var/log/maillog-20131217 ls -l /var/log/messages* -rw------- 1 root root 148 Dec 17 18:34 /var/log/messages -rw-------. 1 root root 180429 Dec 16 16:35 /var/log/messages-20131216 -rw------- 1 root root 30554 Dec 17 18:25 /var/log/messages-20131217 ls -l /var/log/secure* -rw------- 1 root root 0 Dec 17 18:34 /var/log/secure -rw-------. 1 root root 4187 Dec 16 16:41 /var/log/secure-20131216 -rw------- 1 root root 591 Dec 17 18:28 /var/log/secure-20131217 كما ترى، تم إنشاء ملفات السجل الجديدة الثلاث، ملفات maillog و secure لاتزال فارغة، في حين أن ملف messages يملك بعض المعلومات. خاتمة نأمل أن يكون هذا الدرس قد أعطاك بعض الأفكار حول سجلات نظام لينكس، يمكنك أن تحاول وتجرب على خادومك التجريبي حتى تكون لديك فكرة أفضل، حالما تتعود على أماكن ملفات السجل وإعداداتها، استخدم معرفتك لدعم نظم الإنتاج الخاصة بك، وحينها، يمكنك إنشاء بعض الكُنيات aliases لتوفير بعض الوقت . ترجمة -وبتصرف- للمقال: How To View and Configure Linux Logs on Ubuntu and Centos لصاحبه Sadequl Hussain.