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

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

نشرح طريقة تثبيت وإعداد خادم PostgreSQL على نظام أوبنتو 18.04. مع إعداد كلمة مرور للمستخدم root؛ وإنشاء قاعدة بيانات جديدة ومستخدم جديد لديه الصلاحيات الكاملة عليها. قسم PostgreSQL في أكاديمية حسوب غني بالمقالات المفيدة للتعامل معها: https://academy.hsoub.com/devops/servers/databases/postgresql/ نوفر توثيقًا كاملًا لجميع تعليمات SQL على موسوعة حسوب: https://wiki.hsoub.com/SQL

نشرح طريقة تنصيب وإعداد خادم MySQL على نظام أوبنتو 18.04. مع إعداد كلمة مرور للمستخدم root؛ وإنشاء قاعدة بيانات جديدة ومستخدم جديد لديه الصلاحيات الكاملة عليها. نوفر توثيقًا كاملًا لجميع تعليمات SQL على موسوعة حسوب: https://wiki.hsoub.com/SQL

بعد برمجتك لموقعك باستخدام روبي وإطار ريلز، حان الوقت الآن لنشر التطبيق على خادم (server) ليستطيع زوارك الوصول إليه. سنعتمد في هذا الفيديو على أحد التطبيقات الذي طورناه في دورة تعلم تطوير تطبيقات الويب باستخدام روبي: https://academy.hsoub.com/learn/ruby-web-application-development/ مستودع التطبيق: https://github.com/HsoubAcademy/rails-twitter-web-app نوفر في موسوعة حسوب توثيقًا كاملًا للغة روبي وإطار العمل ريلز باللغة العربية: https://wiki.hsoub.com/Ruby https://wiki.hsoub.com/Rails

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

مقدمة إذا كنت تعمل(على الشبكة) مُستخدمًا بروتوكول النقل الآمن Secure Shell) SSH)، فإنّك تعلم مُسبقًا أنّ الجلسة session ستُغلق تلقائيًا بعد دقائقٍ قليلةٍ من عدم النشاط "الخمول"، وذلك لأسبابٍ أمنية.من الممكن في الحقيقة أن تكون قد نسيت إغلاقها، وبالتالي فقد يتمكن شخص آخر من السيطرة على نظامك. ولكن إذا كنت لا ترى في ذلك مشكلة، فبإمكانك تغيير هذا السلوك في ضبط GNU/Linux. يجب تنفيذ الأوامر التالية من عميل SSH. كيفيّة منع SSH من قطع الاتصال يجب تنفيذ الخطوات التالية في عميل SSH، وليس في الخادم البعيد. افتح محرّر النص خاصتك في البداية وعدّل ملف الـ config الحالي للمستخدم الخاص بك، والذي تجده في المسار التالي: ~/.ssh/config أضف الأسطر التالية: تأكّد من أن السطر الثاني سيبدأ بمسافة فارغة. يُخبر السطر الأول الـ SSH بتطبيق هذا الضبط على جميع المضيفات البعيدة remote hosts. كما يمكنك بالطبع تحديد واحد منها فقط، وذلك باستبدال رمز الـ "*" بالمضيف المطلوب. ستحتاج بعد الانتهاء من ذلك إلى تطبيق الإعدادات المذكورة أعلاه: sudo source ~/.ssh/config أضف أو عدّل السطر التالي في ملف etc / ssh / ssh_config/ لتطبيق هذه الإعدادات على المستوى العام globally: ServerAliveInterval 60 احفظ الملف واغلقه. وبهذه الطريقة، لن تُغلق جلسة SSH بعد الآن بسبب الخمول. الخلاصة تذكّر أن أمان نظامك، وخصوصًا في حالة الخادم server، ليس أمرًا ثانويًا، وذلك كلّه بيديك. إنّ تغيير سلوك برامج مثل SSH يجب أن يتم فقط في حال كنت تعرف بالضبط ما تريده، وبعد التأكّد من أنّ ذلك لن يضعك في مشكلةٍ ما. ترجمة وبتصرّف للمقال How to prevent SSH from disconnecting sessions لصاحبه Giuseppe Molica

لعلك تتساءل عن السبب الذي يجعلنا نستخدم Docker لتثبيت lamp أو lemp في حين أننا نستطيع تثبيتهما يدويًا؟ فتثبيتهما سهل ولا يحتاج إلى الكثير من التعقيد، لماذا نلجأ إلى Docker؟ دعني أجيب عن هذا السؤال، إنّ docker برنامج خفيف ويغنينا عن الحاجة إلى الآلات الوهمية مثل Virtualbox أو Xen أو غيرهما لنختبر أو نثبت أنظمة التشغيل. وفائدته معنا في هذا المقال أننا نستطيع استخدامه لسحب نسخ جاهزة من LAMP أو LEMP لتشغيلها في بضع دقائق، بدلًا من التثبيت اليدوي لأباتشي، ثم قاعدة بيانات مثل MariaDB أو mySQL، ثم PHP. وتحدث هذه الحالة التي تحتاج فيها إلى نسخة جاهزة وسريعة لاختبار شيء ما عليها إن كنت مطورًا أو مختبرًا أو شغوفًا بالبرمجة وتريد أن تختبر تطبيقًا يعمل في الويب، فتجد نفسك في حاجة إلى تثبيت كل تلك الخطوات التي ذكرتها في الفقرة السابقة، ولعلك جربت هذا من قبل ووجدتها عملية مرهقة وطويلة، وهنا تبرز ميزة Docker حيث يمكننا تثبيت وتشغيل برامج جاهزة ومعدة مسبقًا مباشرة دون الحاجة إلى خوض تفاصيلها التقنية كأننا نثبتها لأول مرة بأنفسنا. وهو ما سنشرحه في هذا المقال على LAMP أو LEMP. تثبيت LAMP/LEMP باستخدام Docker دعنا نبحث في docker عن نسخ جاهزة من LAMP أو LEMP: $ sudo docker search lamp وسيكون الخرج مشابهًا لهذا: NAME DESCRIPTION STARS OFFICIAL AUTOMATED reinblau/lamp Dockerfile for PHP-Projects with MySql client 17 [OK] dockie/lamp 6 [OK] nickistre/ubuntu-lamp LAMP server on Ubuntu 4 [OK] nickistre/ubuntu-lamp-wordpress LAMP on Ubuntu with wp-cli installed 4 [OK] nickistre/centos-lamp LAMP on centos setup 3 [OK] damienlagae/lamp Docker LAMP with supervisord 3 [OK] boolean93/lamp LAMP based on linode/lamp 2 [OK] drunomics/lamp 1 [OK] avatao/lamp LAMP base image 1 [OK] nickistre/ubuntu-lamp-xdebug LAMP on Ubuntu with xdebug installed 1 [OK] nickistre/centos-lamp-wordpress LAMP on CentOS setups with wp-cli installed 1 [OK] linuxconfig/lamp Automated build LAMP stack environment for... 1 [OK] greyltc/lamp a super secure, up-to-date and lightweight... 0 [OK] kazaoki/lamp ローカルフォルダをマウントす... 0 [OK] greyltc/lamp-gateone LAMP stack with gateone server & webdav 0 [OK] fauria/lamp Modern, developer friendly LAMP stack. Inc... 0 [OK] drunomics/lamp-memcached LAMP + Memcached base image. 0 [OK] rpawel/lamp Apache 2.4 + php5-fpm container 0 [OK] lioshi/lamp Docker image for LAMP + MySql under debian 0 [OK] nickistre/centos-lamp-xdebug LAMP on centos with xDebug 0 [OK] greyltc/lamp-aur LAMP stack (in Arch with php7) with AUR ac... 0 [OK] alledia/lamp General LAMP for our tests, based on phusi... 0 [OK] greatfox/lamp 0 [OK] cnrk/lamp LAMP stack Docker image. 0 [OK] grmanit/lamp Based on tutum/lamp with additional settin... 0 [OK] وكما ترى من النتيجة أعلاه، فهناك الكثير من نسخ LAMP المتوفرة لتوزيعات آرتش وCent OS وأوبنتو، وهي مرتبة وفق تقييم المستخدمين لها. وبالمثل يمكننا أن نبحث عن LEMP أيضًا: $ sudo docker search lemp ثم اختر نسخة lemp مناسبة لك، سأحمّل أنا مثلًا nickistre/ubuntu-lamp: $ docker pull nickistre/ubuntu-lamp ويكون الخرج مشابهًا لهذا: Using default tag: latest latest: Pulling from nickistre/ubuntu-lamp faecf96fd5ab: Pull complete 995977506e98: Pull complete efb63fb8dcb6: Pull complete a3ed95caeb02: Pull complete 61626f5cc06d: Pull complete d42e54d21590: Pull complete 4a32d1f581a1: Pull complete 52f44a8dd6d0: Pull complete ce6c1074ae9e: Pull complete 2fa559435609: Pull complete 93a433221384: Pull complete 521d09b9a2d1: Pull complete 6222edddc59d: Pull complete 8fa401b50efc: Pull complete 683063a5d5e0: Pull complete 1f87fa5088b3: Pull complete c5ee1c14048f: Pull complete Digest: sha256:e913d43c204b3cdb931156c1a680c712acfe8db531225ec7b9e4708fc7ebe93c Status: Downloaded newer image for nickistre/ubuntu-lamp:latest سيحمّل الأمر أعلاه نسخة LAMP لأوبنتو، يمكنك تحميل نسختك الخاصة لتوزيعتك كما أوضحنا قبل قليل. وإن لم ترغب في تحميل واستخدام النسخ التي يوفرها docker من الطرفية، فيمكنك تحميلها من Docker hub حيث تجد آلاف النسخ المستضافة هناك. اذهب إلى الرابط أعلاه وابحث عن نسخة LAMP التي تريدها وحمّلها. في حالتي أنا، فقد اخترت نسخة nickistre/ubuntu-lamp كما قلت قبل قليل: اضغط على النسخة التي تريد لمعرفة مزيد من البيانات عنها مثل كيفية تثبيتها واستخدامها: ستجد النسخ التي تحملها في مجلد var/lib/docker/، ولسرد تلك النسخ نفذ الأمر التالي: $ docker images مثال للخرج: REPOSITORY TAG IMAGE ID CREATED SIZE nickistre/ubuntu-lamp latest 5e750e4f49e4 2 days ago 633 MB reinblau/lamp latest 2813b461f843 9 days ago 697.9 MB hello-world latest 690ed74de00f 5 months ago 960 B والآن نشغّل النسخة بعد أن حمّلناها: $ docker run -it nickistre/ubuntu-lamp /bin/bash ستجد نفسك قد دخلت بشكل آلي إلى المجلد الجذر للحاوية على الويب كمستخدم جذر: root@184851ac9ebd:/# شغّل خدمة أباتشي: # service apache2 start ثم خدمة MySQL: # service mysql start تأكد ما إن كان خادم أباتشي يعمل أم لا، بفتح هذه الصفحة في متصفحك http://container_IP/. ولكي تجد عنوان IP، اكتب ifconfig أو ip addr في طرفية الحاوية، يجب أن ترى هنا صفحة اختبار خادم أباتشي. ويمكنك معرفة إصدارات أباتشي وMySQL وPHP بهذه الأوامر بالترتيب: # apache2 -v # mysql -v # php -v وهكذا نكون قد ثبتنا LAMP في أوبنتو واستخدمناه، ويمكنك الآن أن تختبر تطبيقك كما كنت تريد، دون أن تشغل بالك بتثبيت كل تلك الحزم يدويًا أو على حاسوبك، حتى لو كان في آلة وهمية. ترجمة -بتصرف- لمقال Deploy LAMP and/or LEMP stacks easily using Docker لصاحبه SK

مقدّمة من الممكن أن ننخدع بفكرة أنّ الخوادم لن تُهاجَم ما دام الخادوم جديدا، زواره قلائل أو أنّ المخترقين لن يستفيدوا شيئا من اختراقه. لكنّ العديد من الهجمات تكون مُؤتمتة وتُصمَّمُ خصيصا للبحث عن الأخطاء الشّائعة التي تُرتَكب عند ضبط الخادوم. تقوم هذه البرمجيات بفحص الشبكات لاكتشاف الخوادم فقط، ولا تكثرت بمحتواها. تمكين الاتصالات الخارجيّة من أكثر الحالات الشّائعة التي قد تُؤدي إلى وصول غير مُصرّح إلى قاعدة بيانات PostgreSQL. يُمكن أن يحدث هذا لأنّ الإعدادات تسمح للبرمجيات باستكشاف الخوادم الضعيفة بسهولة. في هذا الدّرس، سنلقي نظرة على كيفيّة تقليل خطر الوصول غير المُصرّح الذي يطرحه تفعيل الاتّصالات البعيدة (remote connections). ورغم أنّ هذه خطوة أولى بغاية الأهميّة، وبما أنّ الخوادم قد تتعرّض للاختراق بطرق أخرى، فإنّنا ننصح باتّخاذ إجراءات إضافيّة لحماية بياناتك، والتي يُمكنك أن تجدها في جزء "إجراءات إضافيّة لمزيد من الحماية” من هذا الدّرس. الوضعيّة لفهم الخطر الذي نحاول تخفيفه، تخيّل الخادوم على أنّه متجر صغير. إن كان المتجر يُنصت (listening) على أي منفذ (port)، فهذا يُكافئ قلب لافتة تُشير إلى أنّ المتجر "مفتوح”. أي أنّ الخادوم يكون مرئيّا على الشّبكة، ما يُمكّن البرمجيات المؤتمتة من إيجاده. يُمكننا أن نتخيّل بأنّ كلّ منفذ عبارة عن طريقة للدّخول إلى المتجر، مثل باب أو نافذة مثلا. يُمكن لهذه المداخل أن تكون مفتوحة، مُغلقة، مُقفلة أو مُعطّلة حسب حالة البرمجيّة التي تقوم بالإنصات، لكنّ الإنصات على واجهة عامّة يعني بأنّ البرمجيات الخبيثة تستطيع مُحاولة الدّخول. فمثلا، يُمكن أن تُحاول البرمجيّة استعمال كلمة مرور افتراضيّة على أمل أنّها لم تتغيّر. يُمكن لها كذلك استغلال ثغرات أمنيّة موجودة في البرنامج الذي يُنصِتُ على أمل أنّها لم تُصلَح بعد. يُمكن مُحاولة العديد من الأساليب، إن تمكّنت البرمجيّة الخبيثة من إيجاد نقطة ضعف وقامت باستغلالها، فهذا يعني بأنّ الوصول إلى الخادوم سيتمّ بنجاح وسيتمكّن الهجوم من تخليف خسائر كبيرة. إن قُمنا بتقييد عفريت (daemon) معيّن مثل postgresql ليُنصت محليّا فقط، فهذا مُشابه لمحو الباب الذي يوصل إلى الخارج. ولن يُمكن مُحاولة أي شيء آخر للوصول إلى Postgres. تحمي الجدران النّاريّة (Firewalls) وشبكات VPN بطريقة مُشابهة. في هذا الدّرس، سنُركّز على حذف الباب العمومي الذي يوصل إلى PostgreSQL. لحماية العفريت أو البيانات أثناء نقلها أو تخزينها، انظر فقرة "إجراءات إضافيّة لمزيد من الحماية” من هذا الدّرس. المُتطلّبات سنستعمل في هذا الدّرس خادومي Ubuntu، الأول لمُضيف قاعدة البيانات والآخر ليعمل كعميل يتّصل بالمُضيف عن بُعد. يجب على كلّ خادوم أن يُجهَّز بمُستخدم sudo وجدار ناري مُفعّل. يُمكنك الاستعانة بدرس الإعداد البدئي لخادوم Ubuntu. مُضيف قاعدة البيانات PostgreSQL (Ubuntu 16.04) إن لم تقم بتنصيب PostgreSQL بعد، يُمكنك القيام بذلك باستخدام الأوامر التّاليّة: sudo apt-get update sudo apt-get install postgresql postgresql-contrib آلة العميل (Ubuntu 16.04) لاختبار تمكين الاتصالات البعيدة، سنستعمل عميل PostgreSQL psql. لتنصيبها، استعمل الأوامر التّاليّة: sudo apt-get update sudo apt-get install postgresql-client عند استيفاء هذه المُتطلبات، ستكون جاهزا لاتّباع هذا الدّرس. فهم الإعداد الافتراضيّ عند تنصيب PostgreSQL من مستودع حزم Ubuntu، فالخيار الافتراضيّ هو الانصات على المُضيف المحليّ (localhost). يُمكن تغيير هذا الخيار الافتراضي عبر تعديل مقطع listen_addresses على ملفّ postgresql.conf، لكنّ هذا الإعداد الافتراضي يمنع الخادوم من الانصات آليّا على واجهة عموميّة (public interface). علاوة على ما سبق، فالملفّ pg_hba.conf لا يسمح سوى لاتّصالات من مقابس أسماء نطاقات Unix/Linux (Unix/Linux domain sockets)، وعنوان الاسترجاع (loopback address) الخاصّ بالخادوم المحلي، ما يعني بأنّ الاتّصالات من مُضيفات خارجيّة لن تُقبَل: # Put your actual configuration here # ---------------------------------- # # If you want to allow non-local connections, you need to add more # "host" records. In that case you will also need to make PostgreSQL # listen on a non-local interface via the listen_addresses # configuration parameter, or via the -i or -h command line switches. # DO NOT DISABLE! # If you change this first entry you will need to make sure that the # database superuser can access the database using some other method. # Noninteractive access to all databases is required during automatic # maintenance (custom daily cronjobs, replication, and similar tasks). # # Database administrative login by Unix domain socket local all postgres peer # TYPE DATABASE USER ADDRESS METHOD # "local" is for Unix domain socket connections only local all all peer # IPv4 local connections: host all all 127.0.0.1/32 md5 # IPv6 local connections: host all all ::1/128 md5 هذه الإعدادات الافتراضيّة تُحقّق هدف منع الانصات على واجهة عموميّة. إن تركناها على حالها وأبقينا الجدار النّاري مُفعّلا، فهذا كلّ ما في الأمر! يُمكننا الآن الانتقال إلى قسم "إجراءات إضافيّة لمزيد من الحماية” للتّعرف على كيفيّة حماية البيانات أثناء نقلها. إن أردت الاتصال من مُضيف بعيد، فسنتطرّق إلى كيفيّة تعديل الإعدادات الافتراضيّة إضافة إلى الخطوات التي يجب اتّخاذها فورا لحماية الخادوم في الفقرة التّاليّة. إعداد الاتّصالات البعيدة (Remote Connections) لإعداد بيئة إنتاج قويّة، وقبل بدء العمل مع بيانات حسّاسة، من المُفضّل تشفير مرور (traffic) PostgreSQL باستخدام SSL، إضافة إلى حماية باستخدام جدار ناري خارجي أو شبكة افتراضيّة خاصّة (VPN). قبل القيام بالأمور السابقة ذكرها، يُمكننا اتّخاذ طريق أقل تعقيدا عبر تفعيل جدار ناريّ على خادوم قاعدة البيانات الخاص بنا وتقييد الوصول لتقبل فقط المُضيفات التي تحتاج إلى الوصول إلى الخادوم. الخطوة الأولى – إضافة مُستخدم وقاعدة بيانات سنبدأ بإضافة مُستخدم وقاعدة بيانات لأغراض تجريبيّة. للقيام بذلك، سنستعمل عميل PostgreSQL psql للاتصال بصفة المُستخدم الإداري postgres. عبر تمرير الخيار -i للأمر sudo سيتمّ تشغيل صدفة تسجيل الدّخول (login shell) الخاصّة بالمُستخدم postgres، ما يضمن بأنّ الخيارات في ملفّ .profile أو في موارد أخرى مُتعلّقة بتسجيل الدّخول ستُحمَّل. يقوم الخيار -u بتحديد المُستخدم postgres: sudo -i -u postgres psql بعدها، سنقوم بإنشاء مُستخدم بكلمة مرور. تأكّد من استعمال كلمة مرور جيّدة عوضا عن المقطع mypassword في المثال أسفله: CREATE USER sammy WITH PASSWORD 'mypassword'; إن تمّ إنشاء المُستخدم بنجاح، فسنستقبل المُخرج التّالي: CREATE ROLE مُلاحظة: منذ الإصدار 8.1 من PostgreSQL، فالأدوار (ROLES) والمُستخدمون (USERS) يشتركون في المعنى.لكنّ هناك اتّفاقا يقول بأنّه إن كان لدور كلمة مرور فإنّنا نُسمّيه مُستخدما، ونُسمّي الدّور عديم كلمة المرور دورا، لذا أحيانا ستحصل على ROLE في المُخرج رغم أنّك تتوقّع أن ترى USER. تاليّاََ، سنُنشئ قاعدة بيانات وسنمنح كامل صلاحيّات الوصول لمُستخدمنا الجديد. تقول أفضل الممارسات بمنح المُستخدمين صلاحيّات الوصول التي يجتاجونها فقط، وعلى الموارد التي يجب أن يحصلوا عليها فقط، لذا فاعتمادا على حالة الاستخدام ( use case)، قد يُفضّل تقييد أحقيّة الوصول للمُستخدم. . CREATE DATABASE sammydb OWNER sammy; عند إنشاء قاعدة البيانات بنجاح، سنستقبل التّأكيد التّالي: CREATE DATABASE بعد إنشاء المُستخدم وقاعدة البيانات، سنقوم بالخروج من سطر أوامر PostgreSQL: \q بعد الضغط على مفتاح ENTER، سنرجع إلى سطر الأوامر وسنكون جاهزين للمُتابعة. الخطورة الثّانيّة – إعداد UFW في درس الإعداد البدئي لخادوم Ubuntu ، قمنا بتفعيل UFW وسمحنا لاتّصالات SSH فقط. قبل بدء الإعداد، لنتحقّق من حالة UFW: sudo ufw status مُلاحظة: إن كان المخرج يدُلّ على أنّ الجدار النّاري غير مُفعّل (inactive)، يُمكننا تفعيله بالأمر التّالي: sudo ufw enable بعد التّفعيل، فإنّ إعادة تنفيذ الأمر sudo ufw status سيستعرض القواعد الحاليّة. فعّل SSH إن كان ذلك مطلوبا: sudo ufw allow OpenSSH في حالة لم تُغيِّر من المُتطلّبات، فمُخرج الأمر sudo ufw status سيُشير إلى أنّ OpenSSH هي الخدمة الوحيدة المُفعّلة: Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) بعد التّحقّق من حالة الجدار النّاري، سنقوم بالسماح بالوصول إلى منفذ PostgreSQL وسنُقيّد الوصول لنسمح فقط للمُضيف أو المُضيفات المرغوبة. سيُضيف الأمر أسفله قاعدة للمنفذ الافتراضيّ لـPostgreSQL، أي المنفذ رقم 5432. إن غيّرت هذا المنفذ، فتأكّد من تعديل الأمر أسفله. تأكّد من استعمال عنوان IP الخاص بالخادوم الذي يحتاج إلى الوصول. أعد تنفيذ الأمر لإضافة كلّ عميل من العملاء الذين ترغب بإعطائهم أحقيّة الوصول إن كان ذلك لازما: sudo ufw allow from client_ip_address to any port 5432 استبدل client_ip_address بعنوان IP الخاصّ بالعميل. للتّحقّق من أنّ القاعدة قد طُبِّقت، يُمكنك تنفيذ الأمر ufw status مُجدّدا: sudo ufw status المُخرج: To Action From -- ------ ---- OpenSSH ALLOW Anywhere 5432 ALLOW client_ip_address OpenSSH (v6) ALLOW Anywhere (v6) مُلاحظة: إن لم تكن لديك دراية مُسبقة بأساسيّات UFW، يُمكنك تعلّم المزيد في درس أساسيات UFW: قواعد وأوامر شائعة للجدار الناري . بعد تجهيز قاعدة الجدار النّاريّ هذه، سنقوم الآن بإعداد PostgreSQL لتُنصت على عنوان IP العمومي. سنقوم بهذا عبر تعديل إعدادَيْن، خانة للمُضيف المُتصل في pg_hba.conf وإعداد listen_addresses في postgresql.conf. الخطوة الثّالثة – إعداد المُضيفات المسموح لها (Allowed Hosts) سنبدأ عبر إضافة خانة المُضيف في ملفّ pg_hba.conf. إن كنت تستعمل نسخة أخرى غيْرَ النُّسخةِ 9.5 من PostgreSQL فتأكّد من تعديل الأمر أسفله قبل تنفيذه: sudo nano /etc/postgresql/9.5/main/pg_hba.conf سنضع أسطر host تحت مقطع التّعليقات الذي يصف كيفيّة السّماح للاتصالات غير المحليّة. سنُضيف سطرا يحمل العنوان العمومي الخاص بخادوم قاعدة البيانات لاختبار ما إذا كان الجدار النّاري مُعدّا بشكل صحيح. استبدل المقطع client_ip_address بعنوان IP الخاص بآلة العميل الخاصّ بك: # If you want to allow non-local connections, you need to add more # "host" records. In that case you will also need to make PostgreSQL # listen on a non-local interface via the listen_addresses # configuration parameter, or via the -i or -h command line switches. host sammydb sammy client_ip_address/32 md5 قبل حفظ التغييرات، لننظر إلى كل قيمة من قيم السّطر الذي أضفناه في حالة كنت ترغب تعديل أي منها: المُضيف، المُعامل host يُحدّد بأنّ اتّصال TCP/IP سيُستَعمَل. قاعدة البيانات، العمود الثّاني، sammydb، يُحدّد أي قاعدة بيانات يُمكن للمُضيف أن يتّصل بها، يُمكنك تعيين أكثر من قاعدة بيانات واحدة عبر تفرقة أسمائها بالفاصلة ,. المُستخدم، sammy، يُحدّد المُستخدم المسموح له بالاتّصال. وكما مع عمود قاعدة البيانات، فتستطيع تحديد أكثر من مستخدم واحد باستعمال علامة الفاصلة. العنوان، يُحدّد عنوان آلة العميل ويُمكن أن يكون عبارة عن اسم مُضيف (hostname)، مجال عناوين IP (IP address range) أو كلمات مفتاحيّة خاصّة. في المثال أعلاه، قمنا بالسماح لعنوان IP الخاصّ بالعميل فقط. طريقة الاستيثاق (auth-method)، في الأخير، يُمكن تحديد طريقة استيثاق، يُشير md5 إلى كلمة مرور مزدوجة التّشفير بـMD5 ( double-MD5-hashed password ) لن تحتاج سوى كلمة المرور التي تم إنشاؤها للمُستخدم الذي سيقوم بالاتّصال. للمزيد من المعلومات وإعدادات إضافيّة راجع التوثيق الرّسمي لـPostgreSQL حول ملفّ pg_hba.conf. بعد الانتهاء من التّعديلات، احفظ وأغلق الملف. الخطوة الرّابعة – إعداد عنوان الإنصات (Listening Address) سنقوم الآن بضبط عنوان الإنصات في ملفّ postgresql.conf (تأكّد من تصحيح رقم النّسخة): sudo nano /etc/postgresql/9.5/main/postgresql.conf أضف عناوين الإنصات تحت سطر listen_addresses، تأكّد من استبدال server_ip_address بعنوان IP أو اسم مُضيف قاعدة البيانات الخاصّة بك وليس عنوان العميل الذي سيقوم بالاتصال: #listen_addresses = 'localhost' # what IP address(es) to listen on; listen_addresses = 'localhost,server_ip_address' احفظ وأغلق الملفّ عند الانتهاء من إجراء التّعديلات. الخطوة الخامسة – إعادة تشغيل PostgreSQL لن تُطبَّق التعديلات حتى نُعيد تشغيل عفريت (daemon) PostgreSQL، لذا سنقوم بهذا قبل أن نبدأ بالتجربة: sudo systemctl restart postgresql وبما أنّ systemctl لا يوفّر تغذيّة راجعة (feedback)، فسنتحقّق من نجاح إعادة تشغيل العفريت: sudo systemctl status postgresql إن احتوى المُخرج على Active: active وانتهى بمقطع مُشابه لما يلي، فهذا يعني بأنّ عفريتPostgreSQL مُفعّل. ... Jan 10 23:02:20 PostgreSQL systemd[1]: Started PostgreSQL RDBMS. بعد إعادة تشغيل العفريت، يُمكننا الآن التّجربة. الخطوة السّادسة – تجربة الاتّصال لنتحقّق من أنّنا نستطيع الاتّصال من جهاز العميل الخاص بنا. للقيام بهذا، سنستعمل الأمر psql مع الخيّار -U لتحديد المُستخدم، الخيار -h لتحديد عنوان IP الخاصّ بالعميل و -d لتحديد قاعدة البيانات، وذلك لأنّنا ضيّقنا الحماية لكي يتمكّن sammy فقط من الاتّصال بقاعدة بيانات واحدة فقط. psql -U sammy -h postgres_host_ip -d sammydb استبدل postgres_host_ip بعنوان IP الخاصّ بمُضيف PostgreSQL. إن تمّ إعداد كل شيء بشكل صحيح، فيجب أن تستقبل المحثَّ (prompt) التّالي: Password for user sammy: أدخل كلمة المرور التّي حدّدتها مسبقا عندما أضفت المُستخدم sammy في مرقاب (monitor) PostgreSQL. إن حصلت على المحثّ التّالي، فهذا يعني بأنّ الاتصال قد تمّ بنجاح: sammydb=> هذا يُؤكّد على أنّنا نستطيع تجاوز الجدار النّاري وأن نتّصل بقاعدة البيانات. سنقوم الآن بالخروج من المحثّ: \q بعد التّحقّق من أنّ الإعدادات قد ضُبِطت بنجاح، سنقوم بتنظيف مُخلّفات التّجربة. الخطوة السّابعة – حذف قاعدة البيانات والمُستخدم التّجريبيّين بعد اختبار الاتّصال، يُمكننا الآن العودة إلى المُضيف واستخدام الأمر التّالي لحذف قاعدة البيانات والمُستخدم. sudo -i -u postgres psql لحذف قاعدة البيانات: DROP DATABASE sammydb; عند نجاح العمليّة، ستستقبل المُخرج التّالي: DROP DATABASE لحذف المُستخدم: DROP USER sammy; المُخرج عند نجاح العمليّة: DROP ROLE سنقوم بإنهاء عمليّة التّنظيف بحذف خانة المُضيف الخاصّة بقاعدة البيانات sammydb من ملفّ pg_hba.conf لأنّنا لم نعد نحتاج إليها: sudo nano /etc/postgresql/9.5/main/pg_hba.conf استبدل 9.5 برقم النّسخة الخاصّة بك. السّطر الذي يجب عليك حذفه: host sammydb sammy client_ip_address/32 md5 ليُطبَّقَ التّعديل، سنقوم بحفظ وإغلاق الملفّ ومن ثمّ نُعيد تشغيل خادوم قاعدة البيانات: sudo systemctl restart postgresl للتحقّق من أنّ إعادة التّشغيل قد تمّت بنجاح، سنطّلع على الحالة: sudo systemctl status postgres إن كان المُخرج يحتوي على Active: active فهذا يعني بأنّ إعادة التّشغيل قد تمّت بنجاح. يُمكنك الآن ضبط التّطبيق أو الخدمة على العميل التي تحتاج إلى إمكانيّة الاتصال عن بعد. خاتمة اتّخذنا في هذا الدّرس الخطوات الأساسيّة لحماية PostgreSQL عبر إعداد الجدار النّاريّ الخاصّ بالخادوم ليسمح فقط للاتصالات من المُضيفات التي تحتاج إلى صلاحيّات الوصول وعبر ضبط PostgreSQL لتقبل الاتصالات من هذه المُضيفات فقط. هذا يُخفّف من خطر بعض من أنواع الهجمات. تعتبر هذه الإجراءات الخطوة الأولى فقط لحماية البيانات، وننصح بمراجعة واتّخاذ الإجراءات الأمنية الإضافيّة المذكورة أعلاه. ترجمة -بتصرّف- للمقال How To Secure PostgreSQL Against Automated Attacks لصاحبته Melissa Anderson.

سنلقي في هذا الدرس نظرةً إلى آلية التعامل مع الأخطاء و الإشارات أثناء تنفيذ السكربتات. يُقاس الفرق بين البرمجة الجيدة والتعيسة عادةً بمدة استقرار البرنامج ومرونته، أي قابلية تعامل البرنامج مع الحالات التي لا تسير فيها الأمور على ما يرام. حالة الخروج تتذكر من دروسنا السابقة أنَّ كل برنامج مكتوب بطريقة جيدة سيُعيد حالة خروج عندما ينتهي تنفيذه؛ فإذا انتهى تنفيذ البرنامج بنجاح، فستكون حالة الخروج مساويةً للصفر، وإن كانت حالة الخروج مساوية لقيمة مختلفة عن الصفر، فهذا يدلّ أنَّ البرنامج قد واجهة مشكلةً ما منعته من إتمام مهمته. من المهم جدًا التحقق من حالة خروج البرامج التي تستدعيها في سكربتاتك، ومن المهم أيضًا أن تُعيد سكربتاتك حالة خروج مفيدة عندما تنتهي. لقد مرّ عليّ مدير أنظمة يونكس قد كتب سكربتًا لنظام إنتاجي يحتوي على السطرين الآتيين: # Example of a really bad idea cd $some_directory rm * هذه طريقة سيئة جدًا لكتابة البرامج، لأنها تعمل بشكلٍ جيد لو لم يحدث أيّ خطأ. فالسطر الأول ينقل مجلد العمل الحالي إلى المسار الموجود في المتغير ‎$some_directory ثم يحذف جميع الملفات الموجودة في ذاك المجلد؛ وهذه هي الحالة الطبيعية لتنفيذ السكربت، لكن ماذا يحدث لو لم يكن المسار الموجود في المتغير ‎$some_directory موجودًا؟ سيفشل -في هذه الحالة- تنفيذ الأمر cd ثم سيُنفِّذ السكربتُ الأمرَ rm في مجلد العمل الحالي، وهنا ستقع الكارثة! بالمناسبة، واجه سكربت مدير الأنظمة البائس هذه المشكلة ودمَّر جزءًا كبيرًا مهمًا من النظام الإنتاجي؛ لا تدع ذلك يحدث لك! مشكلة السكربت السابق أنَّه لم يتحقق من حالة خروج الأمر cd قبل الاستمرار وتنفيذ الأمر rm. التحقق من حالة الخروج هنالك عدِّة طرائق تستطيع فيها الحصول على حالة الخروج والتصرف وفقًا لها. أول طريقة هي معاينة محتويات متغير البيئة ‎$?‎، الذي يحتوي على حالة خروج آخر أمر مُنفَّذ. يمكنك رؤية ذلك في المثال الآتي: $ true; echo $? 0 $ false; echo $? 1 تذكَّر أنَّ الأمرَين true و false لا يفعلان شيئًا سوى الانتهاء بحالة خروج تساوي 0 و 1 على التوالي وبالترتيب. وعبر استخدامهما سنرى كيف يُعيد المتغير ‎$?‎ حالة الخروج لآخر أمر مُنفَّذ. نستطيع كتابة السكربت بهذه الطريقة بعد التحقق من حالة الخروج: # Check the exit status cd $some_directory if [ "$?" = "0" ]; then rm * else echo "Cannot change directory!" 1>&2 exit 1 fi تفحصنا محتوى الأمر cd، وإن كان لا يساوي الصفر، فسيطبع رسالة خطأ في مجرى الخطأ القياسي (standard error stream) وسينتهي تنفيذه مع ضبط حالة الخروج إلى 1. صحيح أنَّ النسخة السابقة تقدِّم حلًا لمشكلتنا، إلا أنَّ هنالك طرائق أفضل ستقلل مقدار الكتابة التي نحتاج لها. سنستخدم في المثال الآتي العبارة الشرطية if مباشرةً، لأنَّها تحقق من حالة خروج الأمر الذي يليها ثم تتصرف وفقًا لذلك. يمكننا إعادة صياغة السكربت كالآتي: # A better way if cd $some_directory; then rm * else echo "Could not change directory! Aborting." 1>&2 exit 1 fi تحققنا هنا أنَّ تنفيذ الأمر cd قد نجح، وبعد ذلك سينُفّذ الأمر rm؛ أو ستظهر رسالة خطأ فيما عدا ذلك وينتهي البرنامج بحالة خروج تساوي 1، مما يشير إلى حدوث مشكلة أثناء التنفيذ. دالة خروج عند حدوث خطأ لمّا كنّا نتحقق من الأخطاء مرارًا وتكرارًا في برامجنا، فمن المعقول أن نكتب دالةً لإظهار الأخطاء، مما يوفِّر علينا بعض الكتابة ويُنمّي إحساس الكسل لدينا :-) . # An error exit function error_exit() { echo "$1" 1>&2 exit 1 } # Using error_exit if cd $some_directory; then rm * else error_exit "Cannot change directory! Aborting." fi معاملات التحكم: "و" AND وَ "أو" OR يمكننا تبسيط السكربت كثيرًا باستخدام معاملَي التحكم "AND" و "OR"، وسأقتبس الفقرة الآتية من صفحة دليل bash لشرح آلية عملهما: سنستعمل الأمرَين true و false مجددًا لكي نشاهد آلية التعامل مع AND و OR عمليًا: $ true || echo "echo executed" $ false || echo "echo executed" echo executed $ true && echo "echo executed" echo executed $ false && echo "echo executed" $ باستخدام هذه التقنية، يمكننا إعادة كتابة نسخة مختصرة أكثر من السكربت السابق: # Simplest of all cd $some_directory || error_exit "Cannot change directory! Aborting" rm * إن لم يكن إنهاء البرنامج مطلوبًا، فيمكننا كتابة السكربت بالصيغة الآتية: # Another way to do it if exiting is not desired cd $some_directory && rm * صحيحٌ أننا أخذنا جميع الاحتياطات الممكنة في مثال cd، إلا أنني أود أن أشير أنَّ الشيفرة يمكن أن تتعرض للمشاكل البرمجية الشائعة، خصوصًا إذا كُتِبَ اسم المتغير الذي يحتوي على مسار المجلد الذي نريد حذف محتوياته بشكلٍ خاطئ. ففي هذه الحالة ستضع الصَدَفة قيمةً فارغةً بدلًا من اسم المتغير وسينتج تنفيذ الأمر cd، لكنه سينتقل إلى مجلد المنزل للمستخدم الحالي، ثم سيحذف كل ما فيه! تحسين دالة الخروج عند حدوث خطأ هنالك عددٌ من التحسينات التي نستطيع إجراءها على الدالة error_exit، أود أن أضع اسم البرنامج في رسالة الخطأ كي أوضِّح من أين تأتي رسالة الخطأ؛ وذلك مهمٌ خصوصًا في السكربتات الكبيرة والمعقدة التي تُستدعى فيها سكربتات داخل سكربتات… لاحظ أيضًا تضمين متغير البيئة LINENO الذي سيساعد في تحديد السطر الذي حدثت فيه المشكلة. #!/bin/bash # A slicker error handling routine # I put a variable in my scripts named PROGNAME which # holds the name of the program being run. You can get this # value from the first item on the command line ($0). PROGNAME=$(basename $0) error_exit() { # ---------------------------------------------------------------- # Function for exit due to fatal program error # Accepts 1 argument: # string containing descriptive error message # ---------------------------------------------------------------- echo "${PROGNAME}: ${1:-"Unknown Error"}" 1>&2 exit 1 } # Example call of the error_exit function. Note the inclusion # of the LINENO environment variable. It contains the current # line number. echo "Example of error with line number and message" error_exit "$LINENO: An error has occurred." استخدام الحاضنات ({}) داخل الدالة error_exit هو مثالٌ عن "توسعة المعاملات" (parameter expansion)، يمكنك وضع حاضنات حول اسم المتغير (كما في {‎${PROGNAME) إذا أردت عزل المتغير عمّا حوله من نصوص. يُفضِّل البعض وضع الحاضنات حول كل متغير، وهذا الأمر منوطٌ بك. الشيء الآخر الذي أريد الإشارة إليه هو {"‎${1:- "Unknown Error الذي يعني أنَّه لو لم يكن المعامل 1 (أي ‎$1) مُعرَّفًا، فضع السلسلة النصية "Unknown Error" مكانه. يمكن إجراء الكثير من عمليات معالجة النصوص باستخدام توسعة المعاملات. الإشارات Signals لا تستطيع اعتبار أنَّ الأخطاء هي المُسبِّب الوحيد لإنهاء البرنامج على نحوٍ غير متوقع، فعليك أن تحتاط من الإشارات (signals) أيضًا. ليكن لديك المثال الآتي: #!/bin/bash echo "this script will endlessly loop until you stop it" while true; do : # Do nothing done بعد أن تُشغِّل هذا السكربت، فسيبدو وكأنَّه علّق، لكنه -مثل أغلبية البرامج التي تُعلِّق- قد دخل في حلقة تكرار ولم يخرج منها. فالسكربت في مثالنا ينتظر أن يُعيد الأمر true حالة خروج لا تساوي الصفر، وهذا لن يحدث أبدًا. وسيستمر تنفيذ السكربت إلى أن تُرسِل الصَدَفة bash إشارةً له لإيقافه. يمكنك إرسال إشارة بالضغط على Ctrl+c التي تُسمى SIGINT (مختصرة من SIGnal INTerrupt). إنهاء البرامج التي تستقبل إشارات بشكل سليم حسنًا، يمكن أن تأتي إشارة وتؤدي إلى إنهاء تنفيذ السكربت، لكن لماذا نهتم بذلك؟ لا يؤدي إنهاء السكربت عبر الإشارات في العديد من الحالات إلى مشاكل، لكنها تحتاج إلى معالجة في بعض الحالات. لننظر إلى مثالٍ آخر: #!/bin/bash # Program to print a text file with headers and footers TEMP_FILE=/tmp/printfile.txt pr $1 > $TEMP_FILE echo -n "Print file? [y/n]: " read if [ "$REPLY" = "y" ]; then lpr $TEMP_FILE fi يُعالِج السكربت السابق ملفًا نصيًا مُمَرَّرًا كوسيط في سطر الأوامر عبر الأمر pr الذي يُخزِّن الناتج في ملف مؤقت (temporary file)، ثم سيسأل المستخدم عمّا إذا كان يريد طباعة الملف، فلو وافق المستخدم عبر كتابة y فسيُمرَّر الملف المؤقت إلى الأمر lpr للطباعة (يمكنك وضع الأمر less بدلًا من lpr إذا لم تكن لديك طابعة موصولة بحاسوبك). عليّ أن أعترف لك أنَّ السكربت السابق فيه العديد من المشاكل التصميمية؛ وعلى الرغم من استخدامه لاسم الملف المُمرَّر عبر سطر الأوامر، لكنه لا يتحقق أنَّ القيمة فارغة، ولا يتحقق إن كان الملف موجودًا فعلًا. لكن الفكرة التي أريد التركيز عليها هي أنَّه عندما ينتهي تنفيذ السكربت، فسيُبقي خلفه ملفًا مؤقتًا. من المستحسن أن نحذف الملف المؤقت ‎$TEMP_FILE عند انتهاء تنفيذ السكربت، ويتم هذا بسهولة بإضافة السطر الآتي في نهاية السكربت: rm $TEMP_FILE قد تظن أننا حللنا المشكلة، لكن ماذا سيحدث لو ضغط المستخدم على Ctrl+c عندما تظهر الرسالة "Print file? [y/n]:‎" سينتهي تنفيذ السكربت عند الأمر read ولن يُنفَّذ الأمر rm أبدًا. سنحتاج إذًا إلى طريقة لمعالجة الإشارات مثل SIGINT عندما يضغط المستخدم على Ctrl+c. لحسن الحظ، توفِّر bash طريقةً لتنفيذ الأوامر فيما إذا استقبِلَت إشارةٌ ما. الأمر trap يسمح لك الأمر trap بتنفيذ أمر عندما يستقبل سكربتك إشارةً. يعمل هذا الأمر كالآتي: trap arg signals حيث signals هي قائمة بالإشارات التي تريد «اعتراضها» أو معالجتها، و arg هو الأمر التي سيُنفَّذ عندما تُستقبَل واحدة من الإشارات المُحدَّدة. يمكننا التعامل مع الإشارات في سكربت الطباعة السابق كما يلي: #!/bin/bash # Program to print a text file with headers and footers TEMP_FILE=/tmp/printfile.txt trap "rm $TEMP_FILE; exit" SIGHUP SIGINT SIGTERM pr $1 > $TEMP_FILE echo -n "Print file? [y/n]: " read if [ "$REPLY" = "y" ]; then lpr $TEMP_FILE fi rm $TEMP_FILE أضفنا الأمر trap الذي سيُنفِّذ الأمر rm $TEMP_FILE إذا استقبل السكربت إحدى الإشارات المذكورة، التي هي أكثر الإشارات التي ستواجهها، لكن هنالك المزيد منها التي تستطيع ذكرها أيضًا. انظر ناتج الأمر trap -l لرؤية القائمة الكاملة. يمكنك أيضًا ذكر الإشارات بأرقامها بدلًا من أسمائها. الإشارة 9 التي لا ترحم! هنالك إشارة لا تستطيع التعامل معها داخل السكربت: إشارة SIGKILL أو الإشارة رقم 9. ستُنهي النواة أيّ عملية تُرسَل لها هذه الإشارة مباشرةً دون العودة إلى البرنامج أو السماح له بإجراء أيّ عملية لمعالجة الإشارة. ولأنه هذه الإشارة تُنهي البرامج التي تُعلِّق أو لا تستجيب، فربما تظن أنَّها أسهل طريقة لإنهاء برنامج ما. وقد ترى الأمر الآتي عندما يأتي ذكر الإشارة SIGKILL: kill -9 وعلى الرغم من أنَّ هذه الإشارة تُتِمُّ عملها بسرعة وسهولة، لكن تذكَّر أنَّ البرنامج لن يستطيع معالجة هذه الإشارة، ولا بأس في ذلك في بعض الحالات؛ لكن قد يُسبِّب مشاكل في بعضها الآخر. حيث تُنشِئ بعض البرامج المعقدة (وحتى بعض البرامج غير المعقدة) ملفات اسمها lock files لمنع تشغيل عدِّة نسخ من نفس البرنامج في نفس الوقت. فعندما تُرسَل إشارة SIGKILL إلى برنامج يستخدم lock files، فلن يكون لديه فرصة لحذف ذاك الملف؛ وسيؤدي وجود ذاك الملف إلى منع تشغيل البرنامج إلى أن يُحذَف يدويًا. استعمل SIGKILL كملاذٍ أخيرٍ لك. دالة clean_up صحيحٌ أنَّ الأمر trap حلّ المشكلة، لكننا لاحظنا بعض المحدوديات؛ خصوصًا أنَّه لا يقبل إلا سلسلةً نصيةً وحيدةً تحتوي الأمر الذي سيُنفَّذ عندما تُستقبَل الإشارة. يمكنك الالتفاف على هذه المحدودية بوضع ; بين عدِّة أوامر، إلا أنَّ هذه الطريقة بشعة المظهر. فمن الأفضل إنشاء دالة ستُستدعى عندما ينتهي تنفيذ السكربت. أُسميّ هذه الدالة عادةً clean_up. #!/bin/bash # Program to print a text file with headers and footers TEMP_FILE=/tmp/printfile.txt clean_up() { # Perform program exit housekeeping rm $TEMP_FILE exit } trap clean_up SIGHUP SIGINT SIGTERM pr $1 > $TEMP_FILE echo -n "Print file? [y/n]: " read if [ "$REPLY" = "y" ]; then lpr $TEMP_FILE fi clean_up يمكن استعمال دالة clean_up في البُنى التي تهتم بمعالجة الأخطاء. فيجب على أيّة حال أن "تُنظِّف" ما خلّفه السكربت بعد انتهائه (لأي سببٍ كان). هذه هي النسخة النهائية من برنامجنا التي حسّنّا فيها معالجة الأخطاء والإشارات: #!/bin/bash # Program to print a text file with headers and footers # Usage: printfile file # Create a temporary file name that gives preference # to the user's local tmp directory and has a name # that is resistant to "temp race attacks" if [ -d "~/tmp" ]; then TEMP_DIR=~/tmp else TEMP_DIR=/tmp fi TEMP_FILE=$TEMP_DIR/printfile.$$.$RANDOM PROGNAME=$(basename $0) usage() { # Display usage message on standard error echo "Usage: $PROGNAME file" 1>&2 } clean_up() { # Perform program exit housekeeping # Optionally accepts an exit status rm -f $TEMP_FILE exit $1 } error_exit() { # Display error message and exit echo "${PROGNAME}: ${1:-"Unknown Error"}" 1>&2 clean_up 1 } trap clean_up SIGHUP SIGINT SIGTERM if [ $# != "1" ]; then usage error_exit "one file to print must be specified" fi if [ ! -f "$1" ]; then error_exit "file $1 cannot be read" fi pr $1 > $TEMP_FILE || error_exit "cannot format file" echo -n "Print file? [y/n]: " read if [ "$REPLY" = "y" ]; then lpr $TEMP_FILE || error_exit "cannot print file" fi clean_up الطريقة المثالية لإنشاء ملفات مؤقتة هنالك عدِّة إجراءات يمكننا اتخاذها لتأمين الملف المؤقت الذي استخدمه السكربت. من تقاليد نظام يونكس استخدام المجلد ‎/tmp لتخزين الملفات المؤقتة التي تستعملها البرامج. يمكن للجميع الكتابة إلى ذاك المجلد، وقد يُسبِّب ذلك لك بعض المخاوف الأمنية. تجنّب كتابة الملفات في مجلد ‎/tmp إن كان ذلك ممكنًا. التقنية المُستحسنة هي كتابة الملفات إلى مجلد محلي مثل ‎~/tmp (أي مجلد tmp الموجود في مجلد المنزل للمستخدم المُنفِّذ للسكربت)؛ وإن كان لا بُد، فعليك اتخاذ بعض الخطوات للتأكد أن أسماء الملفات المُخزَّنة في مجلد ‎‎/tmp غير متوقعة؛ حيث تسمح أسماء الملفات المتوقعة للمخترقين أن يُنشِئوا وصلات رمزية إلى ملفات أخرى التي يريدون منك أن تكتب فوقها. الاسم الجيد للملف المؤقت هو الاسم الذي يسمح لك بمعرفة مَن الذي كتب الملف، ولكنه ليس متوقعًا بشكلٍ كامل. استخدمنا السطر الآتي في السكربت أعلاه لإنشاء اسم الملف المؤقت ‎$TEMP_FILE: TEMP_FILE=$TEMP_DIR/printfile.$$.$RANDOM سيحتوي المتغير ‎$TEMP_DIR على ‎‎/tmp أو ‎~/tmp اعتمادًا على توفر المجلد ~/tmp، ومن الشائع تضمين اسم البرنامج في اسم الملف، وهذا هو سبب وضعنا للكلمة "printfile". ثم استخدمنا متغير الصَدَفة $$ لتضمين مُعرِّف العملية (PID) الخاص بالبرنامج. وهذا سيُحدِّد تمامًا ما هي العملية المسؤولة عن الملف. وبالطبع لا نستطيع أن نعتبر أنَّ رقم العملية كافٍ لجعل اسم الملف غير متوقع؛ لهذا أضفنا متغير الصَدَفة ‎$RANDOM لتضمين رقم عشوائي في اسم الملف. وبالآلية السابقة، أنشأنا اسمًا لملفٍ مؤقتٍ سهلُ التعرف وغير متوقع. خاتمة حسنًا، لقد أنهينا هذه السلسلة، أرجو أن تكون قد وجدتها مفيدةً ومسلية في آن واحد. وأنصحك بإكمال مسيرتك في سطر الأوامر وسكربتات الصَدَفة بقراءة كتاب سطر أوامر لينُكس لمترجمه عبد اللطيف ايمش. ترجمة -وبتصرّف- للمقالين Errors And Signals And Traps (Oh My!) - Part 1 و Errors And Signals And Traps (Oh, My!) - Part 2 لصاحبهما William Shotts.

تتوفر آلاف الأوامر لمستخدمي سطر أوامر لينُكس، لكن كيف تستطيع تذكرها جميعًا؟ الجواب هو أنَّك لا تحتاج إلى ذلك؛ فالقوة الحقيقية للحاسوب تظهر عندما يقوم بالعمل عوضًا عنك، وذلك باستخدام سكربتات الصدفة (Shell Scripts) لأتمتة المهام. ما هي سكربتات الصدفة؟ بأبسط تعريفٍ لها: سكربت الصّدفة هو ملف يحتوي على سلسلة من الأوامر التي تقرأها الصَدَفة (shell) وتنفِّذ الأوامر التي فيها كما لو أنها أُدخِلَت مباشرةً من سطر الأوامر. الصَدَفة هي برمجية فريدة من نوعها، وذلك لأنها توفر واجهة سطرية (أي من سطر الأوامر) للتعامل مع النظام مع كونها مُفسِّر (interpreter) للسكربتات. وكما سنرى لاحقًا، أيّ شيء يمكنك القيام به في سطر الأوامر يمكن فعله في سكربتات الصدفة، وأغلبية الأشياء التي تستطيع كتابتها في سكربتات الصدفة يمكن تنفيذها مباشرةً في سطر الأوامر. سنُركِّز في هذه السلسلة على الميزات التي تُستخدم عادةً عند كتابة السكربتات. كتابة أول سكربت لك يجب أن تفعل ثلاثة أشياء لكي تكتب سكربت شِل: كتابة السكربت السماح للصَدَفة (shell) بتنفيذه (أي إعطاؤه إذن التنفيذ x) وضعه في مكانٍ تستطيع الصَدَفة العثور عليه فيه سكربت الصّدفة ما هو إلا ملف يحتوي على نص عادي؛ فلا يلزمك إلا محرر نصي لكتابة سكربتات الصدفة. "المحرر النصي" هو برنامج -يشبه برامج التحرير المكتبي- يستطيع قراءة وكتابة ملفات ASCII النصية. هنالك الكثير من المحررات النصية المتوفرة على نظام لينُكس سواءً كانت سطريةً (أي تعمل من سطر الأوامر) أم رسوميةً؛ هذه قائمة تحتوي على أشهرها: vi أو vim: المحرر النصي السطري الشهير في نظام يونكس المعروف بصعوبة فهم بنية الأوامر فيه؛ لكنه -على الكفة الأخرى- محرر كفؤ وقوي جدًا وخفيف وسريع. سيؤتي تعلم vi أُكله لأنه متوفر على جميع الأنظمة الشبيهة بِيونكس (Unix-like). النسخة الموجودة من vi في أغلبية توزيعات لينُكس هي النسخة المُحسَّنة التي تدعى vim. Emacs: كبير المحررين في عالم النصوص الذي برمَجَه ريتشارد ستالمان. يحتوي محرر Emac (أو يستطيع أن يحتوي) على كل ميزة يمكن أن تتواجد في أي محرر نصي على الإطلاق! يجدر بالذكر أنَّ مستخدمي vi و Emacs يشتبكون مع بعضهم (على الإنترنت بالطبع!) محاولين إثبات أنَّ محررهم هو الأفضل. nano: هو برنامج سطري شبيه بالمحرر النصي المضمَّن مع عميل البريد الإلكتروني pine، وهو سهل الاستخدام لكن ميزاته قليلة. أنصح عادةً باستخدام nano لمَن يتعامل مع سطر الأوامر لأول مرة. gedit: هو محرر رسومي يأتي مع سطح مكتب غنوم (Gnome). kate: هو محرر رسومي ذو ميزات متقدمة تُسهِّل كتابة السكربتات ويأتي مع حزمة برمجيات كدي (KDE). افتح الآن محررك النصي المفضَّل واكتب فيه أول سكربت لك: !/bin/bash My first script echo "Hello World!" إذا كنتَ سريع البديهة، فمن المرجح أنَّك عرفت كيف تلصق النصوص في المحرر النصي الذي اخترته. إذا فتحت أيّ كتابٍ عن البرمجة من قبل، فستتعرف مباشرةً على برنامج "Hello World" التقليدي الذي يُجسِّده المثال السابق. احفظ الملف باسمٍ ذي معنى (ربما hello_world). أول سطر في الملف مهمٌ وله تأثيرٌ خاص، إذ يُسمى "shebang" وسيخبر الصَدَفة أيّ مُفسِّر عليها استدعاؤه لتفسير هذا السكربت، الذي هو في حالتنا ‎/bin/bash. تستعمل لغات السكربتات الأخرى مثل perl و awk و tcl و php و python هذه الآلية. السطر الثاني في الملف هو تعليق. أيّ شيء يأتي بعد علامة يُعتبر تعليقًا وستتجاهله الصَدَفة تمامًا. لكن عندما يزداد تعقيد برامجك فستصبح التعليقات مهمة جدًا، إذ يستعملها المبرمجون لشرح ما حولها لتسهيل فهم الآخرين له. آخر سطر في السكربت السابق هو الأمر echo الذي يطبع ما يليه على الشاشة. ضبط الأذونات علينا الآن إعطاء إذن التنفيذ لسكربت الصّدفة الذي كتبناه، وذلك بالأمر chmod كما يلي: $ chmod 755 hello_world الإذن "755" سيسمح لك بالقراءة والكتابة والتنفيذ، بينما سيتمكن بقية المستخدمين من قراءة وتنفيذ السكربت فقط. أما إذا أردت أن يكون السكربت خاصًا بك (أي أنَّك الوحيد الذي تستطيع قراءته وتنفيذه) فضع "700" بدلًا من "755". راجع درس مبادئ أذونات الملفات على لينكس للمزيد من المعلومات. وضع الملف في المكان الصحيح تستطيع عند هذه المرحلة تشغيل السكربت كما يلي: $ ./hello_world يجب أن تشاهد العبارة "Hello World!‎" على الشاشة، وإن لم ترها فانظر أين حفظت السكربت، وانتقل إلى ذاك المجلد (بالأمر cd) ثم جرب مرِّة أخرى. علينا الآن أن نتوقف قليلًا ونتحدث عن المسارات. عندما تكتب اسم أحد الأوامر فلن يبحث النظام (أو بالأحرى "الصَدَفة") عن ذاك البرنامج في جميع مجلدات حاسوبك لأن ذلك سيستغرق وقتًا طويلًا؛ ولكنك لاحظت أيضًا كيف أنَّك لا تحتاج إلى تحديد المسار الكامل للبرامج التي تريد تشغيلها وستظن أنَّ الصَدَفة تعرف أين تجدها. حسنًا، أنت محق: الصَدَفة تعرف أين تجد البرمجيات، لأنها -أي الصَدَفة- تحتوي على قائمة بالمجلدات التي تتواجد فيها الملفات التنفيذية (أي البرامج)، وستبحث داخل المجلدات في تلك القائمة عن البرامج، فإن لم تجد ما تبحث عنه في أحد تلك المجلدات فستظهر رسالة الخطأ الشهيرة command not found. يمكنك أن ترى تلك القائمة بكتابة الأمر الآتي: $ echo $PATH الذي سيطبع قائمة مفصولة بنقطتين رأسيتين للمجلدات التي سيتم البحث فيها عن البرامج إذا لم يُحدَّد مسارها الكامل. لاحظ كيف أننا حدَّدنا المسار (‎./‎) عند محاولتنا تشغيل السكربت سابقًا. يمكنك إضافة مجلدات إلى تلك القائمة باستخدام الأمر الآتي، حيث directory هو مسار المجلد الذي تريد إضافته: $ export PATH=$PATH:directory لكن من المستحسن أن تُعدِّل ملف ‎.bashrc‎ أو ‎.profile (اعتمادًا على توزيعتك) لتضمين الأمر السابق فيه، وبهذا سيُنفَّذ في كل مرّة تُسجِّل دخولك فيها. تسمح بعض توزيعات لينُكس بإنشاء مجلد خاص بكل مستخدم ليضع فيه برامجه الشخصية، ويدعى ذاك المجلد bin وهو مجلد فرعي موجود في مجلد المنزل (home) الخاص بك. إن لم يكن موجودًا، فتستطيع إنشاءه بالأمر: $ mkdir bin انقل السكربت إلى مجلد bin (ربما تستخدم الأمر mv) ثم اكتب: $ hello_world وسيعمل السكربت. لاحظ أنَّك قد تحتاج في بعض التوزيعات (مثل أوبنتو) إلى بدء جلسة (session) جديدة حتى تتعرَّف الصَدَفة على المجلد bin. ترجمة -وبتصرّف- للمقال Writing Your First Script And Getting It To Work لصاحبه William Shotts.

تستخدم المهام المجدولة باستخدام الأداة Cron لجدولة تنفيذ الأوامر في وقت محدد، حيث يمكن إعداد الأوامر أو السكربتات، التي يمكن أن يتم تنفيذها بشكل متكرر في وقت مجدد. يُعتبر Cron أحد أكثر الأدوات إفادة في أنظمة لينكس وشبيهات يونكس، حيث تعمل خدمة cron في الخلفية وتتحقق باستمرار من ملف etc/crontab/، ومجلّدات /.*etc/cron/، كما تتحقق من مجلد /var/spool/cron/. أمر crontab يستخدم أمر crontab لتثبيت، إلغاء تثبيت أو عرض الجداول (ملف إعدادات cron) المستخدم في قيادة خدمة cron في برمجية Vixie Cron. يمكن لكل مستخدم أن يكون لديه ملف crontab خاص به، وعلى الرغم من أنّها عبارة عن ملفّات في var/spool/cron/crontabs/ إلا أنها غير مخصصة ليتم التعديل عليها بشكل مباشر، حيث يجب استخدام الأمر crontab لتعديل أو إعداد أي مهام مجدولة في cron. أنواع ملفات إعدادات cron توجد أنواع مختلفة لملفات الإعدادات: Crontab الخاصة بأنظمة لينكس/يونكس عادةً ما تستخدم من قبل خدمات النظام والمهام المجدولة الحرجة التي تحتاج لصلاحيات مدير النظام root. ويستخدم الحقل السادس (انظر أدناه لمزيد من المعلومات عن الحقول) هو اسم المستخدم الذي سيتم تنفيذ الأمر وفق صلاحياته، وتعطي هذه المرونة إمكانية تنفيذ الأوامر وفق أي مستخدم. Crontab الخاصة بالمستخدم يمكن للمستخدم تثبيت مهامه المجدولة الخاصة باستخدام أمر crontab، ويستخدم الحقل السادس لتحديد الأمر المُراد تنفيذه، ويتم تنفيذ جميع الأوامر وفق المستخدم الذي قام بإنشاء المُهمّة. ملاحظة: يعرض المقال تطبيقات cron المكتوبة من قبل Paul Vixie والمستخدمة في معظم توزيعات لينكس وشبيهات يونكس كالإصدار الرابع الشهير لنظام BSD. إن الصيغة متوافقة مع العديد من تطبيقات خدمة crond. ولكن كيف أقوم بتثبيت وإنشاء مهامي المجدولة الخاصة؟ للقيام بذلك، نقوم بتنفيذ الأمر التالي في سطر الأوامر على أنظمة لينكس وشبيهات يونكس: $ crontab -e إن صيغة الملف الذي سيظهر على النحو التالي: 1 2 3 4 5 /path/to/command arg1 arg2 أو: 1 2 3 4 5 /root/ntp_sync.sh حيث أن: 1: الدقيقة (0-59) 2: الساعة (0-23) 3: اليوم في الشهر (0-31) 4: الشهر (0-12 حيث يمثل 12 شهر ديسمبر) 5: اليوم في الأسبوع (0-7 حيث يمثل الرقم 0 أو 7 يوم الأحد) path/to/command/: هو مسار السكربت أو اسم الأمر المراد جدولة تنفيذه. ويمكن تصوّر الصيغة على النحو الأسهل التالي: مثال على crontab بسيط: ## نفّذ سكربت backupscript كُل 5 دقائق ## */5 * * * * /root/backupscript.sh ## نفّذ سكربت backupscript يوميًا الساعة 1 صباحًا ## 0 1 * * * /root/backupscript.sh ## نفّذ سكربت backupscript شهريًا في اليوم الأول من الشهر في تمام الساعة 3:15 صباحًا ## 15 3 1 * * /root/backupscript.sh ملاحظة: يمكن إدراج تعليقات في ملف crontab بوضع إشارة # في بداية السطر. كيفية استخدام المعاملات operators لابد أنك لاحظت في الأمر الأول من الأوامر السابقة أننا كتبنا */5 بدلًا من 5 فقط. إنّ إشارة / هي إحدى المعاملات وسنرى الآن كيفية استخدام المعاملات في crontab. تسمح المعاملات بتحديد عدة قيم في الحقل الواحد، وهناك 4 معاملات: النجمة (*): يحدد هذا المعامل جميع القيم الممكنة في الحقل الذي استخدمت فيه. فعلى سبيل المثال، استخدام * في حقل الساعة يعني أنه سيتم تنفيذ الأمر في "كل" ساعة خلال اليوم، واستخدامها في حقل الأشهر يعني أنه سيتم تنفيذ الأمر في "كل" شهر من أشهر السنة. الفاصلة (,): يحدد هذا المعامل مجموعة من القيم، على سبيل المثال: "1,5,10,15,20,25"، فلو استخدمنا هذه السلسلة مثلًا في حقل الدقائق لعَنى ذلك أنه سيتم تنفيذ الأمر في الدقيقة الأولى، والخامسة، والعاشرة، والخامسة عشر، والعشرون، والخامسة والعشرون من الساعة. إشارة السالب (-): يحدد هذا المعامل مجالًا من القيم، على سبيل المثال: "5-15"، فلو استخدمنا هذه القيمة في حقل الأيام مثلًا لعَنى ذلك أنه سيتم تنفيذ الأمر في اليوم الخامس، السادس، السابع، .... الرابع عشر، الخامس عشر من كل شهر; وكما نلاحظ فهذا يشبه تمامًا كتابة "5,6,7,8,9,10,11,12,13,14,15" باستخدام معامل الفاصلة (,). الخط المائل الخلفي (/): يحدد هذا المعامل قيمة الخطوة، على سبيل المثال: "0-23/" يمكن استخدامها في حقل الساعة لتحديد أن الأمر سيتم تنفيذه في كُل ساعة، ويمكن استخدام هذا المعامل بعد معامل النجمة (*) فلو أردنا تنفيذ الأمر كل ساعتين فيمكن أن نكتب */2 في حقل الساعة. استخدام الكلمات الخاصة لتوفير الوقت عوضًا عن استخدام الحقول الخمسة الأولى من سطر crontab، يمكن استخدام إحدى الكلمات الخاصة الثمانية والتي لن توفّر الوقت فقط بل ستزيد من سهولة فهم المحتوى. reboot@: نفذ الأمر مرة واحدة عند كل إعادة تشغيل early@: نفذ الأمر مرة واحدة في بداية كل سنة، يماثل كتابة "0 0 1 1 *" annually@: مشابه لـ yearly@ تمامًا monthly@: نفذ الأمر مرة واحدة في بداية كل شهر، يماثل كتابة "0 0 1 * *" weekly@: نفذ الأمر مرة واحدة في بداية كل أسبوع، يماثل كتابة "0 0 * * 0" daily@: نفذ الأمر مرة واحدة في بداية كل يوم، يماثل كتابة "0 0 * * *" midnight@: مشابه لـ daily@ تمامًا hourly@: نفذ الأمر مرة واحدة في بداية كل ساعة، يماثل كتابة "0 * * * *" مثال: # نفذ أمر ntpdate كل ساعة @hourly /path/to/ntpdate المزيد من المعلومات عن ملف etc/crontab/ ومجلدات */etc/cron.d/ يُعدّ ملف etc/crontab/ خاصًا بالنظام، وعادة ما يستخدم من قبل مدير النظام root أو الخدمات لإعداد مهام مجدولة على مستوى النظام ككل، ويجب على المستخدمين استخدام أمر crontab لإعداد مهامهم المجدولة حسبما أوضحنا أعلاه. أمّا /var/spool/cron/ أو /var/cron/tabs/ فهي مجلّدات لملفّات crontab الخاصة بالمستخدم، ويجب إنشاء نسخة احتياطية عنها مع مجلد home الخاص بكل مستخدم. فهم ملف etc/crontab/ الافتراضي يحتوي الملف بشكل افتراضي على ما يلي: SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly يتم في البداية تحديد بيئة الصدفة SHELL، وفيما لو لم يتم تحديد البيئة سيقوم cron باستخدام الافتراضية sh. وفي حال لم يتم تحديد قيمة للمتغير PATH، فلن يكون هناك قيمة افتراضية ويتوجب حينها تحديد مسار الأمر أو السكربت المطلوب تنفيذه بشكل مباشر absolute. أما في حال لم يتم تحديد قيمة للمتغير HOME، فسيستخدم cron مسار مجلد home الخاص بالمستخدم الذي يقوم بالتنفيذ. بالإضافة إلى ما سبق، يقوم cron بقراءة الملفات في مجلد /etc/cron.d/، وعادة ما تقوم خدمات نظام مثل sa-update أو sysstat بوضع ملف مهامها المجدولة في هذا المجلّد. يمكن لمدير النظام root أو مستخدم بصلاحيات عالية superuser أن يستخدم هذه المجلّدات لإعداد المهام المجدولة، حيث بالإمكان إسقاط ملفات السكربتات في هذه المجلّدات مباشرة، ويقوم أمر run-parts بتنفيذ السكربتات أو البرامج الموجودة في مجلّد يتم تحديده في ملف etc/crontab/: ضع جميع السكربتات هنا واستدعيها في ملف etc/crontab/ /etc/cron.d/ نفذ جميع السكربتات مرة في اليوم /etc/cron.daily/ نفذ جميع السكربتات مرة في الساعة /etc/cron.hourly/ نفذ جميع السكربتات مرة في الشهر /etc/cron.monthly/ نفذ جميع السكربتات مرة في الأسبوع /etc/cron.weekly/ النسخ الاحتياطي للمهام المجدولة باستخدام cron يمكن استخدام الأمرين التاليين لأخذ نسخة عن المهام المجدولة للمستخدم الذي يقوم بتنفيذ الأمرين، حيث سيتم حفظ قائمة بالمهام المجدولة في الملف المحدد في المسار: # crontab -l > /path/to/file # crontab -u user -l /path/to/file يسمح الأمر الثاني بتحديد اسم المستخدم الذي سيتم عرض المهام المجدولة الخاصة به، ويتوجب أن يملك المستخدم الذي يقوم بتنفيذ الأمر صلاحية لاستعراض المهام المجدولة الخاصة بالمستخدم المذكور، فمثلًا يملك مدير النظام صلاحية تمكّنه من استعراض المهام المجدولة الخاصة بأي مستخدم، ولكن لا يمكن لأي مستخدم استعراض المهام المجدولة الخاصة بمدير النظام ما لم يكن يملك صلاحية بذلك. ترجمة -وبتصرّف- للمقال HOW TO ADD CRON JOBS IN LINUX AND UNIX لصاحبه Duy NguyenViet.

بعد أن تعلمنا التعامل مع المعاملات الموضعية (Positional parameters) في الدرس السابق، حان الوقت الآن لشرح آخر بُنية من بُنى التحكم: for. وكما في البنيتين while و until، تُستعمَل for لإنشاء حلقات تكرار. الشكل العام لحلقة for: for variable in words; do commands done الخلاصة هي أنَّ for تُسنِد كلمةً من قائمة الكلمات إلى متغيّرٍ معيّن، ثم تُنفِّذ الأوامر الموجودة داخل الحلقة، ثم تكرر ذلك إلى أن تُستعمَل جميع الكلمات الموجودة في القائمة. هذا مثالٌ عنها: #!/bin/bash for i in word1 word2 word3; do echo $i done أُسنِدَت -في بادئ الأمر- القيمة word1 إلى المتغير i، ثم نُفِّذ الأمر echo $i، ثم أُسنِدَت القيمة word2 إلى المتغير i، ثم نُفِّذ الأمر echo $i، وهكذا، إلى أن تُسنَد جميع الكلمات إلى المتغير i. الشيء المثير للاهتمام في for هو تنوع الطرائق التي تستطيع فيها بناء قائمة الكلمات، حيث يمكن استخدام جميع أنواع التوسعات (expansions). سنولِّد قائمة الكلمات في المثال الآتي باستخدام تعويض الأوامر (command substitution): #!/bin/bash count=0 for i in $(cat ~/.bash_profile); do count=$((count + 1)) echo "Word $count ($i) contains $(echo -n $i | wc -c) characters" done قمنا في المثال السابق بإحصاء عدد الكلمات في ملف ‎.bash_profile، ثم أظهرنا عدد الحروف في كل كلمة. حسنًا، ما علاقة ذلك بالمعاملات الموضعية؟ حسنًا، يمكن استخدام المعاملات الموضعية كقائمة بالكلمات التي ستمرّ عليها الحلقة for: #!/bin/bash for i in "$@"; do echo $i done المتغير "@" هو متغيرٌ خاصٌ بالصَدَفة ويحتوي على قائمة بوسائط سطر الأوامر. تُستعمَل هذه التقنية عادةً لمعالجة قائمة ملفات عبر سطر الأوامر. هذا مثالٌ آخر: #!/bin/bash for filename in "$@"; do result= if [ -f "$filename" ]; then result="$filename is a regular file" else if [ -d "$filename" ]; then result="$filename is a directory" fi fi if [ -w "$filename" ]; then result="$result and it is writable" else result="$result and it is not writable" fi echo "$result" done جرِّب السكربت السابق، ومرِّر إليه قائمةً بعدِّة ملفات، أو استعمل محرفًا بديلًا مثل * وانظر إلى مخرجاته. هذا سكربتٌ آخر يُقارِن الملفات الموجودة في مجلدين، ويظهِر قائمة بالملفات الموجودة في المجلد الأول وغير الموجودة في المجلد الثاني: #!/bin/bash # cmp_dir - program to compare two directories # Check for required arguments if [ $# -ne 2 ]; then echo "usage: $0 directory_1 directory_2" 1>&2 exit 1 fi # Make sure both arguments are directories if [ ! -d $1 ]; then echo "$1 is not a directory!" 1>&2 exit 1 fi if [ ! -d $2 ]; then echo "$2 is not a directory!" 1>&2 exit 1 fi # Process each file in directory_1, comparing it to directory_2 missing=0 for filename in $1/*; do fn=$(basename "$filename") if [ -f "$filename" ]; then if [ ! -f "$2/$fn" ]; then echo "$fn is missing from $2" missing=$((missing + 1)) fi fi done echo "$missing files missing" لنوظِّف ما سبق في مثالٌ عملي. لنحاول تحسين الدالة home_space في السكربت الذي نبنيه لكي تُخرِج المزيد من المعلومات. كانت النسخة القديمة من الدالة تبدو كما يلي: home_space() { # Only the superuser can get this information if [ "$(id -u)" = "0" ]; then echo "<h2>Home directory space by user</h2>" echo "<pre>" echo "Bytes Directory" du -s /home/* | sort -nr echo "</pre>" fi } # end of home_space هذه هي النسخة الحديثة منها: home_space() { echo "<h2>Home directory space by user</h2>" echo "<pre>" format="%8s%10s%10s %-s\n" printf "$format" "Dirs" "Files" "Blocks" "Directory" printf "$format" "----" "-----" "------" "---------" if [ $(id -u) = "0" ]; then dir_list="/home/*" else dir_list=$HOME fi for home_dir in $dir_list; do total_dirs=$(find $home_dir -type d | wc -l) total_files=$(find $home_dir -type f | wc -l) total_blocks=$(du -s $home_dir) printf "$format" $total_dirs $total_files $total_blocks done echo "</pre>" } # end of home_space تتضمن هذه النسخة المُحسَّنة أمرًا جديدًا هو printf، الذي يُستخدم لتنسيق المُخرجات بناءً على محتويات "عبارة التنسيق" (format string). تنحدر أصول الأمر printf من لغة البرمجة C وهو موجودٌ أيضًا في لغاتٍ برمجيةٍ أخرى مثل C++‎ و Perl و awk و java و PHP وبالطبع bash. هنالك أمرٌ آخر جديد هو الأمر find، الذي يُستخدم للبحث عن ملفات أو مجلدات تُطابِق معيارًا أو مقياسًا محدَّدًا (criteria). استخدمنا الأمر find في الدالة home_space لعرض قائمة بالمجلدات والملفات العادية الموجودة في مجلد المنزل، ثم أحصينا عدد الملفات والمجلدات باستخدام الأمر wc (تذكَّر أنَّه اختصار للعبارة "Word Count"). النقطة المثيرة للاهتمام في دالة home_space المُعدَّلة هي كيفية تعاملنا مع مشكلة عدم السماح بالوصول إلى مجلدات المنزل من المستخدمين العاديين، يمكنك ملاحظة أنَّنا اختبرنا إن كان المستخدم هو الجذر بوساطة id ثم -اعتمادًا على ناتج الاختبار- أسندنا سلاسل نصية مختلفة إلى المتغير dir_list، الذي سيُمثِّل قائمة الكلمات لحلقة for التي تليه. وبهذه الطريقة، إذا شغَّل مستخدمُ عاديٌ السكربت، فستُعرض معلومات عن مجلد المنزل الخاص به فقط. موضوعٌ آخر يمكننا توظيف حلقة for فيه هو الدالة system_info التي لم نكملها بعد. يمكننا كتابتها كالآتي: system_info() { # Find any release files in /etc if ls /etc/*release 1>/dev/null 2>&1; then echo "<h2>System release info</h2>" echo "<pre>" for i in /etc/*release; do # Since we can't be sure of the # length of the file, only # display the first line. head -n 1 $i done uname -orp echo "</pre>" fi } # end of system_info حدَّدنا في بادئ الأمر إن كانت هنالك ملفات release لكي نعالجها. تحتوي ملفات release على اسم التوزيعة وإصدارها. وهي موجودة في مجلد ‎/etc. ولكي نكتشف وجودها، سنستعمل الأمر ls لكننا لسنا مهتمين بمخرجات الأمر، وإنما بحالة الخروج، التي ستكون مساوية للصفر (true) إن وُجِدَت أيّة ملفات. الخطوة الآتية هي طباعة شيفرة HTML لهذا القسم من الصفحة؛ ولمّا كنا نعلم أنَّ هنالك عدِّة ملفات release لكي نعالجها، فسنستخدم حلقة for للمرور على كلٍ واحدٍ منها. ثم سنستعمل الأمر head في داخل الحلقة للحصول على السطر الأول من كل ملف. في النهاية، استعملنا الأمر uname مع الخيارات o و r و p للحصول على بعض المعلومات الإضافية حول النظام. ترجمة -وبتصرّف- للمقال Flow Control - Part 3 لصاحبه William Shotts.

سنتعلم في هذا الدرس من سلسلة مدخل إلى كتابة سكربتات الصدفة كيفية إضافة "ذكاء" إلى سكربتاتنا، فإلى الآن كان يحتوي مشروعنا على سلسلة من الأوامر التي يبدأ تنفيذها من بداية الملف ويستمر سطرًا بسطر إلى أن يصل إلى نهاية الملف. لكن إمكانيات أغلبية البرامج أكبر من ما سبق، حيث تستطيع "اتخاذ القرارات" وإجراء عمليات مختلفة بناءً على مجموعة من الشروط. توفِّر الصَدَفة عدِّة أوامر يمكننا استخدامها للتحكم في جريان تنفيذ البرنامج، وسنتعلم في هذا الدرس: if test exit الأمر if أول أمر سنلقي عليه نظرةً هو الأمر if، يبدو من أول وهلة أنَّ الأمر if بسيط جدًا، لأنه يتخذ قرارًا بناءً على "حالة الخروج" (exit status) لأحد الأوامر. الشكل العام لأمر if: if commands; then commands [elif commands; then commands...] [else commands] fi حيث commands هي مجموعة أوامر. قد تبدو الأمور مربكةً بعض الشيء في البداية، لكن قبل شرح الأمر if بالتفصيل، لنلقِ نظرة على آلية معرفة الصَدَفة لنجاح أو فشل تنفيذ أمر ما. حالة الخروج تُرسِل الأوامر (بما في ذلك السكربتات ودوال الصدفة التي نكتبها) قيمة إلى النظام عند انتهاء تنفيذها تُسمى "حالة الخروج" (exit status)؛ هذه القيمة (والتي هي عدد صحيح يتراوح ما بين 0 و 255) تُشير إلى نجاح أو فشل تنفيذ الأمر. من الأعراف البرمجية أن تكون القيمة 0 تعني نجاح التنفيذ وأي قيمة أخرى تعني فشله. توفِّر الصَدَفة معاملًا (parameter) خاصًا لتفحص حالة الخروج لآخر أمر مُنفَّذ: $ ls -d /usr/bin /usr/bin $ echo $? 0 $ ls -d /bin/usr ls: cannot access /bin/usr: No such file or directory $ echo $? 2 نفَّذنا -في المثال السابق- الأمر ls مرتين، حيث نُفِّذ تنفيذًا سليمًا في أول مرة، فلو عرضنا قيمة المعامل ‎$?‎ فسنرى أنها تساوي الصفر؛ ثم نفَّذنا الأمر ls مرةً أخرى لكنه عرض رسالة خطأ وعندما طبعنا قيمة المعامل ‎$?‎ مرةً أخرى فسنرى أنَّها تساوي 2، مما يشير إلى أنَّ آخر أمر قد نُفِّذ واجه مشكلةً. تستعمل بعض الأوامر حالات خروج مختلفة لتوفير معلومات حول الخطأ، لكن العديد من الأوامر تستعمل الرقم 1 فقط للإشارة إلى باقي أنواع الأخطاء. تحتوي صفحات الدليل man عادةً على قسم مُعنوَن "Exit Status" يشرح ما هي أرقام حالات الخروج المحتملة، لكن تذكَّر أنَّ 0 تُشير دائمًا إلى نجاح التنفيذ. توفِّر الصَدَفة أمرَين مُضمَّنين فيها بسيطين للغاية، كلُ ما يفعلانه هو الانتهاء بحالة خروج 0 أو 1. ينجح تنفيذ الأمر true دائمًا ويفشل تنفيذ الأمر false دائمًا: $ true $ echo $? 0 $ false $ echo $? 1 يمكننا استخدام هذه الأوامر لتجربة عبارة if الشرطية. ما تفعله عبارة if هو أنَّها تتحقق من نجاح أو فشل تنفيذ الأوامر التي تليها: $ if true; then echo "It's true."; fi It's true. $ if false; then echo "It's true."; fi $ يُنفَّذ الأمر echo "It's true."‎ عندما يُنفَّذ الأمر الذي يلي كلمة if بنجاح، ولن يُنفَّذ عندما يفشل تنفيذ الأمر الذي يلي كلمة if. الأمر test يُستخدَم الأمر test كثيرًا مع الأمر if لإنتاج القيمة true أو false. هذا الأمر غير اعتيادي لأنَّ له شكلان مختلفان: # الشكل الأول test expression # الشكل الثاني [ expression ] آلية عمل الأمر test بسيطةٌ جدًا، فلو كان التعبير (expression) الذي يليه صحيحًا، فسينتهي تنفيذ الأمر test بحالة خروج تساوي الصفر؛ فيما عدا ذلك سينتهي بحالة خروج تساوي 1. من أهم مميزات الأمر test تنوع التعابير التي تستطيع كتابتها فيه؛ هذا مثالٌ بسيط: if [ -f .bash_profile ]; then echo "You have a .bash_profile. Things are fine." else echo "Yikes! You have no .bash_profile!" fi استخدمنا في المثال السابق التعبير ‎ -f .bash_profile الذي يقول: "هل الملف ‎.bash_profile موجود؟" فإن كان موجودًا فسينتهي الأمر test بحالة خروج تساوي الصفر (أي true) وسيُنفِّذ الأمر if الأوامر التي تتبع الكلمة then؛ وإذا لم يكن الملف موجودًا فسينتهي الأمر test بحالة خروج تساوي الواحد (أي false) وسيُنفِّذ الأمر if الأوامر التي تلي الكلمة else. هذه قائمة مختصرة بالتعابير التي يمكن استعمالها في الأمر test. ولمّا كان الأمر test مُضمَّنًا في الصَدَفة (shell builtin)، فتستطيع استخدام help test لرؤية القائمة الكاملة. ‎-d dir: الناتج هو true إذا كان dir مجلدًا. ‎-e file: الناتج هو true إذا كان file موجودًا. ‎-f file: الناتج هو true إذا كان file ملفًا عاديًا موجودًا. ‎-L file: الناتج هو true إذا كان file وصلةً رمزيةً (symbolic link). ‎-r file: الناتج هو true إذا كنت تستطيع قراءة الملف file. ‎-w file: الناتج هو true إذا كنت تستطيع الكتابة على الملف file. ‎-x file: الناتج هو true إذا كنت تستطيع تنفيذ الملف file. file1 -nt file2: الناتج هو true إذا كان الملف file1 أحدث (وفقًا لوقت التعديل [modification time]) من الملف file2. file1 -ot file2: الناتج هو true إذا كان الملف file1 أقدم من file2. ‎-z string: الناتج هو true إذا كنت السلسلة النصية string فارغة. ‎-n string: الناتج هو true إذا لم تكن السلسلة النصية string فارغة. string1 = string2: الناتج هو true إذا كانت السلسلة النصية string1 مساويةً للسلسلة النصية string2. string1 != string2: الناتج هو true إذا لم تكن السلسلة النصية string1 مساويةً للسلسلة النصية string2. قبل أن نواصل أريد أن أشرح بقية المثال السابق لأنه يبرز عددًا من الأفكار المهمة. رأينا في بداية السكربت الأمر if متبوعًا بالأمر test متبوعًا بفاصلة منقوطة وفي النهاية الكلمة then. اخترت استعمال الشكل [ expression ] للأمر test لأنَّ أغلبية الناس يرون أنَّ قراءته أسهل. لاحظ أنَّ الفراغات مطلوبة بين قوس البداية ] وبداية التعبير، وكذلك الفراغ بين نهاية التعبير وقوس الإغلاق [. تعمل الفاصلة المنقوطة كفاصل بين الأوامر، مما يسمح بوضع أكثر من أمر في نفس السطر. مثلًا: $ clear; ls سيؤدي إلى مسح الشاشة ثم تنفيذ الأمر ls. استخدمتُ الفاصلة المنقوطة في عبارة if السابقة لأنني أريد وضع الكلمة then في نفس سطر الأمر if لأنني أرى أنَّها قراءتها أسهل بهذه الطريقة. سنشاهد صديقنا القديم echo في السطر الثاني، لكنك ستلاحظ وجود محاذاة (أي فراغات قبل الأمر)، وهذا لغرض تسهيل قابلية القراءة، ومن التقاليد البرمجية أن نحاذي جميع الأوامر داخل العبارة الشرطية if (أي جميع الأسطر التي ستُنفَّذ عند تحقيق شرط معيّن). تذكَّر أنَّ الصَدَفة لا تتطلَّب فعل ذلك، لكننا نفعله لجعل قراءة الشيفرة أسهل. بعبارة أخرى، يمكننا كتابة الشيفرات الآتية وسنحصل على نفس النتيجة: # Alternate form if [ -f .bash_profile ] then echo "You have a .bash_profile. Things are fine." else echo "Yikes! You have no .bash_profile!" fi # Another alternate form if [ -f .bash_profile ] then echo "You have a .bash_profile. Things are fine." else echo "Yikes! You have no .bash_profile!" fi الأمر exit لكي نكتب سكربتات صدفة جيدة، فعلينا ضبط حالة خروج عندما ينتهي تنفيذ السكربت، ونستعمل الأمر exit لفعل ذلك، الذي يؤدي إلى إيقاف تنفيذ السكربت فوريًا وضبط حالة الخروج إلى القيمة المُمرَّرة كوسيط إليه. على سبيل المثال، الأمر الآتي: exit 0 سيؤدي إلى إيقاف تنفيذ السكربت وضبط حالة الخروج إلى 0 (أي نجاح التنفيذ)، بينما: exit 1 سيؤدي إلى إيقاف تنفيذ السكربت وضبط حالة الخروج إلى 1 (أي فشل التنفيذ). التحقق من أن المستخدم المشغل للسكربت هو الجذر آخر مرة تركنا فيها السكربت كنا نحتاج إلى تشغيله بامتيازات الجذر، وذلك لأنَّ الدالة home_space تحتاج إلى معرفة المساحة التخزينية التي تستهلكها مجلدات المنزل للمستخدمين. لكن ماذا سيحدث لو حاول مستخدمٌ عادي تشغيل السكربت؟ سيؤدي ذلك إلى إظهار الكثير من رسائل الخطأ القبيحة. لكن ماذا لو وضعنا شيئًا في السكربت يمنع تنفيذه من المستخدم العادي؟ الأمر id يخبرنا من هو المستخدم الحالي، وعند تمرير الخيار ‎-u إليه فسيطبع قيمة عددية لمُعرِّف المستخدم (user ID) الحالي. $ id -u 501 $ su Password: # id -u 0 فلو نفَّذ المستخدم الجذر الأمر id -u فسيكون الناتج هو 0، ويمكننا أن نستثمر هذه المعلومة لكي تكون الأساس الذي سنبني عليه الاختبار الذي سنضعه في السكربت: if [ $(id -u) = "0" ]; then echo "superuser" fi تحققنا في المثال السابق أنَّ ناتج الأمر id -u مساوٍ للسلسلة النصية "0" ثم طبعنا العبارة "superuser". وعلى الرغم من أنَّ الأمر السابق يكتشف إن كان المستخدم هو المستخدم الجذر، إلا أنَّه لم يحل المشكلة بعد. إذ نريد أن يتوقف تنفيذ السكربت إن لم يكن المستخدم المُشغِّل له هو الجذر، لذلك نكتب الشيفرة الآتية: if [ $(id -u) != "0" ]; then echo "You must be the superuser to run this script" >&2 exit 1 fi نتحقق في الشيفرة السابقة أنَّ ناتج الأمر id -u لا يساوي "0"، ثم سيطبع السكربت رسالة خطأ مفهومة، ثم ينتهي تنفيذه بحالة خروج مساوية للواحد، لكي يخبر النظام أنَّه لم يتم التنفيذ بنجاح. لاحظ وجود ‎>&2 في نهاية الأمر echo، الذي هو شكلٌ من أشكال إعادة توجيه الدخل والخرج (I/O redirection)، وسترى هذا التعبير عادةً في نهاية الأوامر التي تطبع رسائل خطأ، لأننا لو لم نُعِد توجيه مجرى الخطأ هنا، فسترسَل رسالة الخطأ إلى مجرى الخرج القياسي (standard output stream)، لكننا نريد أن تظهر رسائل الخطأ بمعزل عن مخرجات السكربت، لأننا نعيد توجيه مجرى الخرج القياسي الناتج من تنفيذ السكربت إلى ملف. علينا أن نضع الأسطر السابقة في بداية السكربت لكي نتمكن من تحديد هوية المستخدم المُشغِّل قبل أن يقع الخطأ، لكننا نريد في الوقت نفسه أنَّ يمكن المستخدمون العاديون من تشغيل السكربت، لذلك سنعدِّل الدالة home_space لكي تتأكد من امتيازات المستخدم كالآتي: function home_space { # Only the superuser can get this information if [ "$(id -u)" = "0" ]; then echo "<h2>Home directory space by user</h2>" echo "<pre>" echo "Bytes Directory" du -s /home/* | sort -nr echo "</pre>" fi } # end of home_space بهذه الطريقة سيتمكن المستخدم العادي من تشغيل السكربت، وسيتم تجاوز الشيفرة التي قد تتسبب بخطأ بدلًا من تنفيذها وإظهار رسالة للمستخدم. ترجمة -وبتصرّف- للمقال Flow Control - Part 1 لصاحبه William Shotts.

بعد أن ازدادت السكربتات التي نكتبها تعقيدًا، فأحببت أن أشير إلى بعض الأخطاء الشائعة التي قد تصادفك أثناء مسيرتك. سنتعرض في هذا الدرس مثالًا ونعمل على تحليل الأخطاء التي قد نرتكبها، ولنسمِّ ذاك السكربت trouble.bash، تأكد من كتابة السكربت كما هو موجود حرفيًا. #!/bin/bash number=1 if [ $number = "1" ]; then echo "Number equals 1" else echo "Number does not equal 1" fi يجب أن يُخرِج السكربت السابق السطر "Number equals 1"، لأنَّ المتغير number يساوي 1، إن لم تحصل على المخرجات التي توقعتها، فتحقق من صحة كتابتك للسكربت، فربما ارتكبتَ خطأً… المتغيرات الفارغة عدِّل السطر الثالث من السكربت من: number=1 إلى: number= ثم شغِّل السكربت مرةً أخرى، وستحصل هذه المرة على المخرجات الآتية: $ ./trouble.bash /trouble.bash: [: =: unary operator expected. Number does not equal 1 كما لاحظت، عَرَضَت الصَدَفة bash رسالة خطأ عندما شغلنا السكربت، وربما ظننتَ أنَّ حذف القيمة "1" من السطر الثالث قد أدى إلى خطأٍ بنيوي (syntax error) لكن هذا ليس صحيحًا، ألقِ نظرةً إلى رسالة الخطأ مجددًا: ./trouble.bash: [: =: unary operator expected يمكننا ملاحظة أنَّ ‎./trouble.bash يُبلِّغ عن الخطأ، الذي يرتبط -بشكلٍ أو بآخر- مع ]؛ تذكَّر أنَّ ] هو اختصارٌ للأمر المُضمَّن في الصَدَفة test. ومن رسالة الخطأ السابقة استطعنا تحديد أنَّ الخطأ يحدث في السطر الخامس وليس الثالث. عليّ القول بادئ الأمر أنَّه لا توجد أيّة مشكلة في السطر الثالث، حيث number=‎ صحيحة بنيويًا؛ فقد ترغب في بعض الأحيان بحذف القيمة المُخزَّنة في متغيّر. يمكنك التحقق من سلامة هذه الصياغة بكتابتها وتجربتها في سطر الأوامر: $ number= $ أرأيت! لا توجد رسالة خطأ، لكن ما هو الشيء الخاطئ في السطر الخامس؟ لقد جربناه قبل تعديل السكربت ولم يكن يسبب أيّة مشاكل. لكي نفهم هذا الخطأ، علينا أن ننظر إلى الموضوع من وجهة نظر الصَدَفة. وَضَعَت الصَدَفة، في السطر الخامس، قيمة المتغير number عندما رأت ‎$number. ففي أول محاولة لتشغيل السكربت (أي عندما كان number=1)، بدَّلَت الصدفة المتغير ‎$number بالرقم 1 كما يلي: if [ 1 = "1" ]; then لكننا عندما أزلنا قيمة المتغير (number=‎)، فستحاول الصدفة تنفيذ ما يلي: if [ = "1" ]; then وهذا خطأ، ويُفسِّر أيضًا ما تبقى من رسالة الخطأ التي حصلنا عليها. المُعامِل = هو معامِل ثنائي، الذي يعني أنَّه يتوقع وجود عنصرين (كل عنصر على طرف). وما تحاول الصَدَفة إخبارنا به هو أنَّ هنالك عنصرٌ واحدٌ فقط، ولهذا يجب وضع معامل أحادي (مثل !) الذي يتطلب وجود عنصر وحيد فقط. علينا تعديل السطر الخامس إلى ما يلي لحل هذه المشكلة: if [ "$number" = "1" ]; then وسترى الصَدَفة ما يلي (إذا كانت قيمة number=‎): if [ "" = "1" ]; then وبهذا تجنبنا هذا الخطأ. تعلمنا من هذا الخطأ أمرًا مهمًا عند كتابة السكربتات: خذ بعين الاعتبار ماذا سيحدث لو كانت قيمة أحد المتغيرات فارغة. غياب إحدى علامات الاقتباس عدِّل السطر السادس وأزل علامة إغلاق الاقتباس من نهاية السطر: echo "Number equals 1 ثم شغِّل السكربت مرةً أخرى وستحصل على: $ ./trouble.bash ./trouble.bash: line 8: unexpected EOF while looking for matching " ./trouble.bash: line 10 syntax error: unexpected end of file هذه مشكلةٌ أخرى شائعةٌ تُسبِّب مشاكل في أماكن أخرى في السكربت. ماذا يحدث لو استمرت الصَدَفة بحثها عن علامة إغلاق الاقتباس لمعرفة نهاية سلسلةٍ نصيةٍ ما، لكنها وصلت إلى نهاية الملف ولم تجدها. يصعب كثيرًا اكتشاف هذا النوع من الأخطاء في السكربتات الطويلة؛ وهذا أحد الأسباب التي تدفعك لتجربة السكربتات بين الحين والآخر عندما تكتبها لوجود كمية قليلة من الشيفرات الجديدة التي عليك اختبارها. أرى أيضًا أنَّ استخدام المحررات النصيّة التي توفِّر تلوينًا للشيفرات يساعد كثيرًا في الكشف عن مثل هذه الأخطاء. عزل مكان المشكلة قد تكون عملية إيجاد الأخطاء والعِلل في برنامجك صعبة ومحبطة، هذه بعض التقنيات التي قد تستفيد منها: اعزل أجزاءً من الشيفرات بوضع علامة تعليق قبل الأسطر التي لا تريد أن تنفذها الصَدَفة. طبِّق هذا على كتلة من الشيفرات لكي ترى إن اختفت مشكلة معيّنة. وبهذه الآلية ستعرف ما هو الجزء الذي يسبب (أو لا يسبب) المشكلة. على سبيل المثال، لو عدنا إلى السكربت الذي فيه علامة اقتباس ناقصة، فيمكننا أن نعزل المشكلة كالآتي: #!/bin/bash number=1 if [ $number = "1" ]; then echo "Number equals 1 #else # echo "Number does not equal 1" fi سنعلم بعد وضع عبارة else في تعليق ثم تشغيل السكربت أنَّ المشكلة ليس في عبارة else حتى لو أشارت رسالة الخطأ إلى ذلك. استخدم الأمر echo للتحقق من القيم. فبعد أن تكتسب خبرة في تتبع العلل، ستكتشف أنَّ العلل ستتواجد في مكانٍ مختلف عن المكان الذي تتوقع وجودها فيه. إحدى المشاكل الشائعة هي افتراضك أنَّ التسلسل المنطقي لبرنامجك صحيحٌ تمامًا، وعندما ترى مشكلة في مرحلة ما في البرنامج فستفترض أنَّها موجودة هناك؛ وهذا خاطئ في معظم الحالات. يمكنك وضع أوامر echo في الشيفرة أثناء محاولة تنقيح (debugging) الأخطاء لكي تحصل على رسائل تؤكد لك أنَّ البرنامج يعمل كما تتوقع. هنالك نوعان من الرسائل التي عليك وضعها. الغرض من أول نوع هو الإعلان أنَّ التنفيذ قد وصل إلى مكان معيّن في البرنامج، ولقد رأينا ذلك سابقًا عند كتابتنا لشيفرات وهمية في الدوال التي أضفناها. وهذا مفيد لكي تعلم أنَّ مسار تنفيذ البرنامج مماثل تمامًا لما نتوقعه. النوع الثاني يعرض قيم المتغيرات المستخدمة في الحسابات أو الاختبارات. قد تجد في بعض الأحيان قسمًا من السكربت لا يُنفَّذ تنفيذًا سليمًا لأنك افترضت أنَّ شيئًا ما في ما سبقه من الشيفرات صحيحٌ؛ إلا أنَّ فيه مشكلةً تؤدي إلى فشل تنفيذ ما يليه من الشيفرات. مراقبة تشغيل السكربت من الممكن أنَّ تعرض لك bash ما الذي يحدث عندما تُشغِّل السكربت. وذلك بإضافة الخيار ‎-x في أول سطر من السكربت كما يلي: #!/bin/bash -x وعندما ستُشغِّل السكربت، فستعرض bash كل سطر ستحاول تنفيذه (بعد تعويض قيم المتغيرات…). تُسمى هذه التقنية بالتتبع (tracing)، وهذا مثالٌ عنها: $ ./trouble.bash + number=1 + '[' 1 = 1 ']' + echo 'Number equals 1' Number equals 1 تستطيع أيضًا أن تستعمل الأمر set داخل السكربت لتفعيل أو تعطيل التتبع. استخدم set -x لتشغيل التتبع و set +x لتعطيل التتبع، مثال: #!/bin/bash number=1 set -x if [ $number = "1" ]; then echo "Number equals 1" else echo "Number does not equal 1" fi set +x ترجمة -وبتصرّف- للمقال Stay Out Of Trouble لصاحبه William Shotts.

عندما يزداد طول البرامج وتعقيدها، فستزداد صعوبة تصميمها وبرمجتها وصيانتها؛ لذا من المفيد عادةً تقسيم المهام الكبيرة إلى سلسلة من المهام الأصغر. سنُقسِّم في هذا الدرس السكربت الذي كنا نعمل عليه إلى عدد من الدوال (functions) المنفصلة. لكي نتعرف على مفهوم الدوال، فلنحاول وصف طريقة القيام بمهمة يومية: الذهاب إلى السوق وشراء الطعام. تخيل أننا سنصف العملية إلى كائنات فضائية آتية من المريخ. سيبدو الوصف العام لعملية شراء الطعام كالآتي: غادر المنزل قد السيارة إلى السوق اركن السيارة ادخل السوق اشترِ طعامًا قد السيارة إلى المنزل اركن السيارة ادخل إلى المنزل سيُغطِّي الشرح السابق الآلية العامة للذهاب إلى السوق؛ لكن تلك الكائنات الفضائية ستحتاج مزيدًا من التفاصيل، فمثلًا يمكن وصف المهمة الفرعية "اركن السيارة" كالآتي: اعثر على مكان فارغ لركن السيارة قد السيارة إلى ذاك المكان أطفئ المحرك "ارفع" المكابح اليدوية اخرج من السيارة اقفل السيارة ويمكن بالطبع تقسيم خطوة "أطفئ المحرك" إلى عدد من الخطوات مثل: أطفئ دارة الإشعال أخرج مفتاح السيارة وهكذا إلى أن تُفصِّل كل خطوة من كامل عملية الذهاب إلى السوق. عملية تعريف الخطوط الأساسية ومن ثم كتابة التفاصيل لتلك الخطوات تسمى "نمط تصميم Top-Down". يسمح هذا النمط لنا بتقسيم المهام الكبيرة والضخمة إلى مهام أبسط وأصغر. سنستخدم نمط تصميم Top-Down ليساعدنا في التخطيط لبرنامجنا الذي سنكمل تطويره وإضافة الميزات إليه. يمكننا تلخيص "الوصف العام" للمهام التي يقوم بها السكربت الآن: بداية الصفحة بداية ترويسة الصفحة كتابة العنوان إغلاق الترويسة بداية جسم الصفحة كتابة العنوان كتابة بصمة الوقت (timestamp) إغلاق الجسم إغلاق الصفحة تمت برمجة كل الخطوات السابقة، لكننا نريد إضافة المزيد. لندرج بعض المهام الإضافية بعد المهمة السابعة: كتابة بصمة الوقت كتابة معلومات عن إصدار النظام كتابة الوقت الذي مضى منذ آخر تشغيل (uptime) كتابة مساحة القرص كتابة المساحة التخزينية لمجلدات المنزل (home) إغلاق الجسم إغلاق الصفحة سيكون من حسن حظنا وجود أوامر تستطيع تنفيذ المهام الإضافية، فسنستطيع استخدام "تعويض الأوامر" (command substitution) لوضعها في السكربت كالآتي: #!/bin/bash # sysinfo_page - A script to produce a system information HTML file ##### Constants TITLE="System Information for $HOSTNAME" RIGHT_NOW=$(date +"%x %r %Z") TIME_STAMP="Updated on $RIGHT_NOW by $USER" ##### Main cat <<- _EOF_ <html> <head> <title>$TITLE</title> </head> <body> <h1>$TITLE</h1> <p>$TIME_STAMP</p> $(system_info) $(show_uptime) $(drive_space) $(home_space) </body> </html> _EOF_ أما للمهام التي لا توجد أوامر تستطيع فعل ما نريد تحديدًا، فيمكننا إنشاؤها باستخدام دوال الصدفة (shell functions). وكما تعلمنا في أحد الدروس السابقة، يمكن اعتبار دوال الصدفة على أنها "برامج صغيرة ضمن البرامج" وتسمح لنا باتباع مبادئ نمط التصميم top-down. علينا تعديل السكربت كالآتي لإضافة دوال الصدفة: #!/bin/bash # sysinfo_page - A script to produce an system information HTML file ##### Constants TITLE="System Information for $HOSTNAME" RIGHT_NOW=$(date +"%x %r %Z") TIME_STAMP="Updated on $RIGHT_NOW by $USER" ##### Functions system_info() { } show_uptime() { } drive_space() { } home_space() { } ##### Main cat <<- _EOF_ <html> <head> <title>$TITLE</title> </head> <body> <h1>$TITLE</h1> <p>$TIME_STAMP</p> $(system_info) $(show_uptime) $(drive_space) $(home_space) </body> </html> _EOF_ هنالك نقطتان تجدر الإشارة إليهما: أولهما أنَّه يجب تعريف دوال الصدفة قبل محاولة استخدامها؛ وثانيهما هو أنَّ جسم الدالة (أي القسم الذي يقع بين قوس البداية "}" وقوس النهاية "{") يجب أن يحتوي على أمرٍ واحدٍ على الأقل. لن يعمل السكربت السابق وسيُظهِر رسالة خطأ وذلك لأنَّ جسم الدوال فارغ. أبسط طريقة لتصحيح هذه المشكلة هي وضع عبارة "return" في جسم كل دالة، وبعدها سيُنفَّذ السكربت بنجاح. إبقاء السكربتات قابلة للتشغيل من المفيد أثناء تطويرنا للتطبيق أن نُضيف جزءًا يسيرًا من الشيفرات ثم نُجرِّب السكربت ثم نضيف المزيد ثم نجرِّب السكربت وهكذا. وبهذه الطريقة سيسهل العثور على الأخطاء في الشيفرة ومن ثم تصحيحها. بعد إضافة الدوال إلى السكربت، أصبح بإمكانك الآن مراقبة التسلسل المنطقي لتنفيذ السكربت وذلك عبر آلية يُطلَق عليها اسم stubbing أي إضافة شيفرة وهمية. يمكنك تخيل هذه الآلية كما يلي: لنفترض أننا نريد إنشاء دالة اسمها "system_info" لكننا لم نفكر في تفاصيل الشيفرة بشكل كامل. فبدلًا من إيقاف عملية تطوير السكربت إلى أن ننتهي من الدالة system_info فيمكننا إضافة الأمر echo إليها كالآتي: system_info() { # Temporary function stub echo "function system_info" } سنتمكن باستخدام هذه الآلية من تنفيذ السكربت دون خطأ حتى لو لم نكمل برمجة الدالة system_info؛ ونستطيع لاحقًا وضع الشيفرة الحقيقية بدلًا من أمر echo السابق. سبب استخدامنا لأمر echo هو أننا نحتاج إلى مؤشر لكي نعرف أنَّ السكربت قد نفَّذ الدالة المعنية. لنُطبِّق هذه الآلية على جميع الدوال في السكربت: #!/bin/bash # sysinfo_page - A script to produce an system information HTML file ##### Constants TITLE="System Information for $HOSTNAME" RIGHT_NOW=$(date +"%x %r %Z") TIME_STAMP="Updated on $RIGHT_NOW by $USER" ##### Functions system_info() { # Temporary function stub echo "function system_info" } show_uptime() { # Temporary function stub echo "function show_uptime" } drive_space() { # Temporary function stub echo "function drive_space" } home_space() { # Temporary function stub echo "function home_space" } ##### Main cat <<- _EOF_ <html> <head> <title>$TITLE</title> </head> <body> <h1>$TITLE</h1> <p>$TIME_STAMP</p> $(system_info) $(show_uptime) $(drive_space) $(home_space) </body> </html> _EOF_ سنكمل الآن العمل على كل دالة على حدة لكي تُخرِج معلوماتٍ مفيدةً. show_uptime ستُظهِر الدالة show_uptime ناتج الأمر uptime، الذي يعرض عدِّة معلومات مثيرة للاهتمام حول النظام، بما في ذلك المدة الزمنية منذ آخر إعادة تشغيل، وعدد المستخدمين، والحِمل (load) الحالي على النظام. $ uptime 9:15pm up 2 days, 2:32, 2 users, load average: 0.00, 0.00, 0.00 لعرض ناتج الأمر uptime في صفحة HTML، فسنحتاج إلى برمجة دالة الصدفة كالآتي (وذلك بعد حذف الشيفرة الوهمية التي كانت فيها): show_uptime() { echo "<h2>System uptime</h2>" echo "<pre>" uptime echo "</pre>" } كما ترى، تُخرِج الدالة السابقة نصًا يحتوي على خليطٍ من وسوم HTML مع مخرجات الأمر uptime؛ وستصبح هذه المخرجات جزءًا من here script عندما تُجرى عملية "تعويض الأوامر" في الجزء الرئيسي من السكربت. drive_space تستخدم الدالة drive_space الأمر df لتوفير ملخص للمساحة التخزينية المستهلكة من أنظمة الملفات الموصولة (mounted file systems). $ df Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda2 509992 225772 279080 45% / /dev/hda1 23324 1796 21288 8% /boot /dev/hda3 15739176 1748176 13832360 12% /home /dev/hda5 3123888 3039584 52820 99% /usr ستبدو بنية دالة dive_space شبيهةً للغاية بدالة show_uptime: drive_space() { echo "<h2>Filesystem space</h2>" echo "<pre>" df echo "</pre>" } home_space ستُظهِر دالة home_space مقدار المساحة التخزينية التي يستهلكها كل مستخدم في مجلد المنزل الخاص به. سيُعرَض الناتج كقائمة مرتبة تنازليًا وفق مقدار المساحة التخزينية المستخدمة. home_space() { echo "<h2>Home directory space by user</h2>" echo "<pre>" echo "Bytes Directory" du -s /home/* | sort -nr echo "</pre>" } لاحظ أنَّه يجب تنفيذ السكربت عبر مستخدم يملك امتيازات إدارية لكي تعمل الدالة السابقة بشكلٍ صحيح، لأنَّ الأمر du يتطلب امتيازات الجذر (root) لكي يتفحص محتويات المجلد ‎/home. system_info لسنا جاهزين بعد لإكمال دالة system_info. لكننا سنُحسِّن من الشيفرة الوهمية التي فيها لكي تُنتِج وسوم HTML: system_info() { echo "<h2>System release info</h2>" echo "<p>Function not yet implemented</p>" } ترجمة -وبتصرّف- للمقالَين Shell Functions و Some Real Work لصاحبهما William Shotts.

رأينا في الدرس السابق كيف كتبنا سكربتًا يولِّد صفحة HTML، لكن هذا ليس كافيًا لنا، فلنقم ببعض التعديلات. #!/bin/bash # sysinfo_page - A script to produce an HTML file cat <<- _EOF_ <html> <head> <title> My System Information </title> </head> <body> <h1>My System Information</h1> </body> </html> _EOF_ هل لاحظت كيف أنَّ العبارة "My System Information" مكررة مرتين في السكربت السابق؟ لنُحسِّنها هكذا: #!/bin/bash # sysinfo_page - A script to produce an HTML file title="My System Information" cat <<- _EOF_ <html> <head> <title> $title </title> </head> <body> <h1>$title</h1> </body> </html> _EOF_ أضفنا سطرًا إلى بداية السكربت ووضعنا ‎$title بدلًا من العبارة "My System Information". المتغيرات ما فعلناه في الأعلى سيمهد لنا الطريق لشرح فكرة أساسية جدًا موجودة في جميع لغات البرمجة تقريبًا: المتغيرات (variables). المتغيرات هي أماكن في الذاكرة يمكن أن تُستعمَل لتخزين المعلومات، ويُشار إليها باسمٍ مُميِّزٍ لها. أنشأنا في السكربت السابق متغيرًا اسمه title ووضعنا العبارة "My System Information" في الذاكرة، ثم استخدمنا ‎$title لإخبار الصَدَفة أننا نريد إجراء "توسعة المعاملات" (parameter expansion) ونضع محتوى المتغير بدلًا من اسمه. عندما ترى الصَدَفة كلمةً تبدأ برمز $ فستحاول معرفة إذا كانت تُشير تلك الكلمة إلى متغير، ثم ستضع القيمة المُخزَّنة فيه -أي المتغير- مكان ورود تلك الكلمة. كيفية إنشاء متغير كل ما عليك فعله لإنشاء متغير هو وضع اسم المتغير في سطرٍ مستقل متبوعًا برمز المساواة (=) دون أيّة فراغات، ثم كتابة المعلومات التي تريد إسنادها بعد رمز المساواة. أسماء المتغيرات حسنًا، أنت من يُسمي المتغيرات، لكن هنالك بعض القواعد التي عليك مراعاتها: يجب أن تبدأ أسماء المتغيرات بحرف. يجب ألّا يحتوي اسم المتغير على فراغات. استخدم الشرطات السفلية (_) بدلًا منها. لا تستطيع استخدام علامات الترقيم. كيف أثر المتغير على السكربت الذي نكتبه سهَّلت إضافة المتغير title الأمر علينا من ناحيتين: الأولى هي تقليل مقدار الكتابة الذي نحتاجه، والثانية (وهي المهمة) هي أننا جعلنا صيانة السكربت أسهل. كلما ازدادت خبرتك في كتابة سكربتات الشِل (أو أي لغة برمجة أخرى)، فستتعلم أنَّك لا تنتهي من كتابة البرنامج في خطوة واحدة، فهنالك تعديلات وتحسينات من قبِل كاتب البرنامج أو من غيره؛ وهذا هو حجر الأساس لعملية تطوير البرمجيات مفتوحة المصدر. فلنقل مثلًا أنَّك تريد تغيير العبارة "My System Information" إلى "Linuxbox System Information"، فكنت تحتاج -في النسخة القديمة من السكربت- إلى تغيير تلك العبارة في مكانين منفصلين، أما في النسخة الجديدة التي فيها المتغير title فلا حاجة إلى تغيير تلك العبارة إلا في مكانٍ وحيد. قد تظن أنَّ هذا التغيير تافه أو ليس له فائدة حقيقية، لكن ذلك لأنَّ السكربت الذي نكتبه ما يزال بسيطًا وقصيرًا؛ لكن التنظيم أساسيٌ جدًا في السكربتات الكبيرة والمعقدة. متغيرات البيئة Environment Variables هنالك بعض المتغيرات المضبوطة في جلسة الصَدَفة من قِبل ملفات البدء التي رأيناها سابقًا. استعمل الأمر printenv لرؤية جميع المتغيرات الموجودة في البيئة عندك؛ يحتوي أحد تلك المتغيرات "اسم المضيف" (hostname) لنظامك؛ ونستطيع أن نُضيف ذاك المتغير إلى السكربت كالآتي: #!/bin/bash # sysinfo_page - A script to produce an HTML file title="System Information for" cat <<- _EOF_ <html> <head> <title> $title $HOSTNAME </title> </head> <body> <h1>$title $HOSTNAME</h1> </body> </html> _EOF_ أصبح السكربت الآن يضع اسم الحاسوب الذي نعمل عليه في صفحة HTML الناتجة. لاحظ أنَّ أسماء متغيرات البيئة (وفق التقاليد البرمجية) تُكتَب بأحرفٍ كبيرة. تعويض الأوامر سنحاول الآن تحسين السكربت بوضع ناتج من أحد الأوامر فيه. كانت آخر نسخة من السكربت قادرةً على إنشاء صفحة HTML تحتوي على أسطر نصية بسيطة تتضمن اسم المضيف لجهازنا المأخوذ من متغير البيئة المسمى HOSTNAME، سنُحدِّث السكربت الآن لإضافة بصمة وقت إلى الصفحة لكي تُشير إلى آخر تحديث لها، مع ذكر اسم المستخدم الذي قام بالتحديث. #!/bin/bash # sysinfo_page - A script to produce an HTML file title="System Information for" cat <<- _EOF_ <html> <head> <title> $title $HOSTNAME </title> </head> <body> <h1>$title $HOSTNAME</h1> <p>Updated on $(date +"%x %r %Z") by $USER</p> </body> </html> _EOF_ كما لاحظت، استعملنا متغير بيئة جديد هو USER لكي نحصل على اسم المستخدم؛ واستعملنا تعبيرًا غريب المظهر: $(date +"%x %r %Z") المحارف ‎$()‎ تقول "يجب وضع ناتج الأمر المُحاط بالأقواس هنا". وأردنا في السكربت السابق وضع ناتج الأمر date +"%x %r %Z"‎ الذي يطبع التاريخ والوقت الحاليين. لدى الأمر date ميزاتٌ وخياراتُ تنسيقٍ كثيرة، نستطيع إلقاء نظرة عليها كالآتي: $ date --help | less لاحظ أنَّ هنالك صيغة قديمة بديلة عن (‎$(command هي استخدام علامة الاقتباس الخلفية "`"، هذه الصيغة القديمة متوافقة مع صَدَفة Bourne Shell الأصلية (sh)؛ لكنني لا أنوي استخدام الشكل القديم لأنني أشرح استخدام bash الحديثة وليس sh. تدعم صَدَفة bash جميع السكربتات المكتوبة لـ sh، ولهذا تكون الصيغتان الآتيتان متكافئتين: $(command) `command` إسناد ناتج أحد الأوامر إلى متغير يمكننا أيضًا إسناد ناتج أحد الأوامر إلى متغير: right_now=$(date +"%x %r %Z") نستطيع أيضًا وضع متغير داخل متغير آخر كما يلي: right_now=$(date +"%x %r %Z") time_stamp="Updated on $right_now by $USER" الثوابت كما يوحي اسم "المتغيرات": قيمة المتغير قابلة للتبديل، وهذا يعني أنَّه من المحتمل أثناء تنفيذ السكربت أن تُعدَّل قيمة المتغير نتيجةً لعمليةٍ قمتَ بها. في المُقابل، هنالك قيم يجب ألّا تتغير بعد ضبطها، وتسمى "الثوابت" (constants). سبب ذكري لهذا الموضوع هو أنَّ مفهوم الثوابت شائعٌ في البرمجة، وتدعمها أغلبية لغات البرمجة، لكن لكي أكون صريحًا معك، لم أشاهد استعمالًا عمليًا لها. فلو كان من المفترض أن تبقى قيم المتغير ثابتةً فسيسمى المتغير بأحرفٍ كبيرة لتذكير المبرمج أنَّ قيمة المتغير ثابتة. تُعتبَر متغيرات البيئة ثوابتَ لأنها نادرًا ما تتغير؛ وتُعطى الثوابت أسماءً ذات أحرفٍ كبيرة عادةً. سأستعمل العرف الآتي في هذا السكربت: الأحرف الكبيرة للثوابت والأحرف الصغيرة للمتغيرات. يبدو السكربت الذي نعمل عليه كالآتي حاليًا: #!/bin/bash # sysinfo_page - A script to produce an HTML file title="System Information for $HOSTNAME" RIGHT_NOW=$(date +"%x %r %Z") TIME_STAMP="Updated on $RIGHT_NOW by $USER" cat <<- _EOF_ <html> <head> <title> $title </title> </head> <body> <h1>$title</h1> <p>$TIME_STAMP</p> </body> </html> _EOF_ ترجمة -وبتصرّف- للمقالَين Variables و Command Substitution And Constants لصاحبهما William Shotts.

سنشرع في بناء تطبيق مفيد بدءًا من هذا الدرس، سيُنتِج هذا التطبيق مستند HTML يحتوي على معلومات عن نظامك. قضيتُ وقتًا طويلًا في التفكير حول الطريقة التي عليّ اتباعها لشرح برمجة سكربتات الصدفة، ووجدت أنَّ الطريقة التي اعتمدتها مختلفة عن أغلبية الشروحات التي رأيتها، فالأغلبية تُفضِّل شرحًا هيكليًا لمختلف ميزات الصَدَفة bash، ويفترضون أنَّ لديك معرفة مسبقة مع إحدى لغات البرمجة؛ وعلى الرغم من أنني لا أعتبر أنَّ لديك خلفية برمجية، إلا أنني مدرك أنَّ نسبة كبيرة من الأشخاص العاملين في مجال التقنية يعرفون البنية الأساسية لصفحات HTML، لذلك سيُنتِج برنامجنا صفحة ويب. سنكتشف ميزات الصَدَفة bash أثناء بنائنا للسكربت، وسنتعرف على الأدوات اللازمة لحل المشكلات التي ستواجهنا. كتابة ملف HTML باستخدام سكربت كما تعلم، تكون بنية ملف HTML كالآتي: <html> <head> <title> The title of your page </title> </head> <body> Your page content goes here. </body> </html> بأخذ ذلك بعين الاعتبار، يمكننا أن نكتب سكربتًا يمكنه إخراج المحتوى السابق: #!/bin/bash # sysinfo_page - A script to produce an html file echo "<html>" echo "<head>" echo " <title>" echo " The title of your page" echo " </title>" echo "</head>" echo "" echo "<body>" echo " Your page content goes here." echo "</body>" echo "</html>" يمكن أن يُستخدم السكربت كالآتي (تذكَّر أنَّ الرمز < هو رمز إعادة توجيه المخرجات، وهنا سنعيد توجيه المخرجات إلى ملف باسم sysinfo_page.html): $ sysinfo_page > sysinfo_page.html قيل أنَّ أعظم المبرمجين قدرًا هم أكسلهم! حيث يكتبون برامج ليريحوا أنفسهم من بعض الأعمال؛ وبالمثِل: عندما يكتب المبرمجون الأذكياء برنامجًا، فإنهم يحاولون تقليل مقدار الكتابة التي يكتبونها. أول تحسين سنفعله للسكربت هو التخلص من الاستعمال المتكرر لأمر echo والاستعاضة عنه بأمرٍ واحد (سنحيط كامل مستند HTML بعلامات اقتباس): #!/bin/bash # sysinfo_page - A script to produce an HTML file echo "<html> <head> <title> The title of your page </title> </head> <body> Your page content goes here. </body> </html>" أصبح من الممكن احتواء الأسطر الجديدة في النص داخل علامتَي الاقتباس، وبهذا يمكن أن يمتد الوسيط (argument) المُمرَّر إلى الأمر echo على أكثر من سطر. بغض النظر أنَّ ما سبق تحسينٌ واضحٌ، إلا أنَّ فيه قصورًا لأنَّ شيفرات HTML تحتوي عادةً على علامات اقتباس، مما يجعلها تتعارض مع علامات الاقتباس المحيطة بالوسيط، لكن يمكننا "تهريب" (escape) علامة الاقتباس بوضع شرطة خلفية مائلة \ قبلها. لكننا نريد تجنب كتابة المزيد من الأحرف! إذًا علينا البحث عن طريقة أفضل لطباعة النص. لحسن الحظ توفر لنا الصَدَفة bash طريقةً لفعل ذلك اسمها here script. #!/bin/bash # sysinfo_page - A script to produce an HTML file cat << _EOF_ <html> <head> <title> The title of your page </title> </head> <body> Your page content goes here. </body> </html> _EOF_ here script (يُسمى أحيانًا here document) هو شكل من أشكال إعادة توجيه المخرجات، الذي يوفِّر طريقةً لتضمين محتوى سيُمرِّر إلى مجرى الدخل القياسي (standard input stream) لأحد الأوامر. مُرِّرَت -في المثال السابق- كتلةٌ نصيةٌ إلى مجرى الدخل القياسي للأمر cat. الشكل العام لإنشاء here script: command << token content to be used as command's standard input token يمكن اختيار أي سلسلة نصية لكي تكون العلامة الرمزية (token)، لكنني استخدمت __EOF__ ‏(EOF هو اختصارٌ شهير للعبارة End Of File أي نهاية الملف) لشيوعها، لكنك تستطيع استخدام أي سلسلة تشاء، لطالما أنَّها لا تتعارض مع كلمةٍ محجوزةٍ في bash. العلامة الرمزية التي تُنهي here script يجب أن تُطابِق تمامًا تلك التي بدأته، وإلا فستعامل محتويات السكربت المتبقية على أنَّها دخل قياسي للأمر المُحدَّد. هنالك خدعة إضافية يمكنك استخدامها مع here script تسمح لك بمحاذاة (indent) المحتوى المُمرَّر عبر here script لتحسين قابلية قراءة السكربت. يمكنك فعل ذلك بتعديل السكربت كالآتي: #!/bin/bash # sysinfo_page - A script to produce an HTML file cat <<- _EOF_ <html> <head> <title> The title of your page </title> </head> <body> Your page content goes here. </body> </html> _EOF_ تبديل علامة ‎>> إلى ‎<<-‎ سيؤدي إلى تجاهل مسافات الجدولة (tab) البادئة (لكن لن يتم تجاهل الفراغات) في here script؛ لن يحتوي ناتج الأمر cat على أيّة مسافات جدولة بادئة. حسنًا، لنُعدِّل محتويات ملف HTML لكي نبيّن ما الغرض من صفحة الويب: #!/bin/bash # sysinfo_page - A script to produce an HTML file cat <<- _EOF_ <html> <head> <title> My System Information </title> </head> <body> <h1>My System Information</h1> </body> </html> _EOF_ سنجعل السكربت في الدرس القادم يُظهِر معلومات حقيقة من نظامنا. ترجمة -وبتصرّف- للمقال Here Scripts لصاحبه William Shotts.

قبل أن تبدأ في كتابة سكربتات جديدة، عليّ أن أشير إلى أنَّك تملك بعض السكربتات الموجودة مسبقًا، وضِعَت هذه السكربتات في مجلد المنزل الخاص بك عندما أُنشِئ حسابك، وتُستعمل لضبط سلوك جلسات سطر الأوامر في حاسوبك؛ تستطيع تعديل هذه السكربتات لتغيير بعض الأمور. سنلقِي نظرةً على سكربتَين من هذه السكربتات في هذا الدرس لكي نتعلم بعض المفاهيم الجديدة والمهمة عن الصَدَفة. يُبقي النظام على مجموعة من المعلومات حول جلستك تدعى "البيئة" (environment)، تحتوي البيئة على أشياء مثل المجلدات التي سيتم البحث فيها عن البرمجيات (PATH)، واسم المستخدم، واسم الملف الذي سيُحفَظ فيه بريدك الإلكتروني، وغير ذلك. يمكنك رؤية قائمة كاملة لضبط البيئة بالأمر set. هنالك نوعان من الأوامر التي تحتويها البيئة، وتُعرَف بالاختصارات (aliases) ودوال الصّدفة (shell functions). ما هو منشأ البيئة؟ تبدأ صَدَفة bash عندما تُسجِّل دخولك إلى النظام، وتقرأ سلسلة من ملفات الضبط تُسمى "ملفات بدء التشغيل" أو "ملفات البدء" (startup files) التي تُعرِّف البيئة الافتراضية التي يتشارك فيها جميع المستخدمين؛ ثم ستقرأ ملفات بدء إضافية موجودة في مجلد المنزل الخاص بك التي تُعرِّف بيئتك الشخصية. يختلف الترتيب بحسب نوع جلسة سطر الأوامر التي بدأتها، إذ أنَّ هنالك نوعان: جلسة تحتاج إلى تسجيل دخول (login shell session) وجلسة لا تحتاج إلى تسجيل دخول (non-login shell session). الجلسة التي تحتاج إلى تسجيل دخول هي الجلسة التي تسألك عن اسم المستخدم وكلمة المرور، وذلك عندما تستعمل إحدى الطرفيات الوهمية (virtual console) على سبيل المثال. أما الجلسات التي لا تحتاج إلى تسجيل دخول فهي تحدث عادةً عندما تُشغِّل محاكي الطرفية داخل الواجهة الرسومية. تقرأ الصَدَفة التي تحتاج إلى تسجيل دخول ملف بدء أو أكثر كما هو موضَّح هنا: ‎/etc/profile: سكربت الضبط العام الذي يُطبَّق على جميع المستخدمين. ‎~/.bash_profile: ملف بدء خاص بالمستخدم، يمكن أن يُستعمل لضبط خياراتٍ أخرى غير موجودة في سكربت الضبط العام، أو لتجاوز بعضها وإعادة تعريفها. ‎~/.bash_login: إن لم يكن الملف ‎~/.bash_profile موجودًا فستحاول الصَدَفة bash قراءة هذا السكربت. ‎~/.profile: إن لم يكن الملف ‎~/.bash_profile أو ‎~/.bash_login موجودًا فستحاول الصَدَفة bash قراءة هذا الملف. هذا هو السلوك الافتراضي في التوزيعات المبنية على دبيان مثل أوبنتو. أما الصَدَفة التي لا تحتاج إلى تسجيل دخول، فتقرأ ملفات البدء الآتية: ‎/etc/bash.bashrc: سكربت ضبط عام يُطبَّق على جميع المستخدمين. ‎~/.bashrc: ملف بدء خاص بالمستخدم، يمكن أن يُستعمل لضبط خياراتٍ أخرى غير موجودة في سكربت الضبط العام، أو لتجاوز بعضها وإعادة تعريفها. إضافةً إلى قراءة ملفات الضبط السابقة، ترث الجلساتُ التي لا تحتاج إلى تسجيل دخول البيئةَ من العملية الأب (parent process) التي تكون عادةً جلسة تحتاج إلى تسجيل دخول. ألقِ نظرةً على نظامك لترى ما هي ملفات البدء التي عندك، لكن لاحظ أنَّ أغلبية الملفات السابقة تبدأ بنقطة (مما يعني أنها مخفية)، لذا عليك استخدام الخيار ‎-aمع الأمر ls. ls -a ملف ‎~/.bashrc هو أهم ملف بدء من وجه نظر المستخدم العادي لأنه يُقرَأ دائمًا. حيث تقرأه الجلسات التي لا تحتاج إلى تسجيل دخول افتراضيًا، وأغلبية ملفات البدء الخاصة بالجلسات التي تحتاج إلى تسجيل دخول تقرأ ملف ‎~/.bashrc أيضًا. إذا ألقيت نظرةً داخل ملف ‎.bash_profile‎ (الملف الآتي مأخوذ من توزيعة CentOS)، فسيبدو شبيهًا بالآتي: # .bash_profile # Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi # User specific environment and startup programs PATH=$PATH:$HOME/bin export PATH تذكَّر أنَّ الأسطر التي تبدأ برمز # هي تعليقات ولا تُفسَّرها الصَدَفة؛ حيث أُضيفت هذه الأسطر لشرح الشيفرة لمن يقرأها من البشر. ستجد في السطر الرابع أول الأشياء المثيرة للاهتمام: if [ -f ~/.bashrc ]; then . ~/.bashrc fi هذه هي عبارة if الشرطية، التي سنشرحها بالتفصيل في درسٍ لاحق، لكنني سأفسرها لك كالآتي: إذا كان الملف ‎~/.bashrc موجودًا، فنفِّذ محتويات ‎~/.bashrc. يمكننا أن نرى أنَّ الشيفرة القصيرة السابقة هي التي تجعل الجلسات التي تحتاج إلى تسجيل الدخول تقرأ محتويات الملف ‎.bashrc. الخطوة التالية في ملف البدء هي ضبط المتغير PATH وإضافة ‎~/bin إلى قائمة المجلدات التي سيتم البحث فيها عن الملفات التنفيذية للأوامر. وفي نهاية الملف: export PATH وظيفة الأمر export هي إخبار الصَدَفة أنَّ عليها جعل محتويات المتغير PATH متاحةً للعمليات التي تنحدر منها (الأبناء). الاختصارات aliases الاختصارات (aliases) هي طريقة سهلة لإنشاء أمر جديد يعمل اختصارًا لأمرٍ أطول. لها الشكل العام الآتي: alias name=value حيث name هو اسم الأمر الجديد و value هي السلسلة النصية التي ستُنفَّذ عند إدخال name في سطر الأوامر. لنُنشِئ اختصارا اسمه l (حرف L صغير) ولنجعله اختصارًا للأمر ls -l (أي عرض محتويات المجلد بالصيغة التفصيلية). تأكَّد أنَّ مجلد العمل الحالي هو المنزل، ثم افتح ملف ‎.bashrc باستخدام محررك النصي المُفضَّل وأضف السطر الآتي إلى نهاية الملف: alias l='ls -l' عند إضافتك للأمر alias إلى الملف، فستُنشِئ أمرًا جديدًا اسمه l الذي يكافئ ls -l. أغلِق جلسة الطرفية الحالية وابدأ واحدة جديدة لتجربة الاختصار التي أنشأناه، وذلك لإعادة قراءة محتويات الملف ‎.bashrc. يمكنك باستخدام هذه التقنية إنشاء أي عدد من الاختصارات المُخصصة لاستعمالك الشخصي، هذه إحداها: alias today='date +"%A, %B %-d, %Y"' سيُنشِئ السطر السابق اختصارا جديدا اسمه today الذي سيُظهِر تاريخ اليوم بتنسيقٍ جميل. بالمناسبة، الأمر alias هو أمر مُضمَّن في الصَدَفة (shell builtin)، أي أنَّك تستطيع إنشاء الأوامر البديلة مباشرةً من سطر الأوامر؛ لكن يجب أن تعلم بأنَّ تلك الأوامر ستزول عند إغلاقك لجلسة الطرفية الحالية. مثال: $ alias l='ls -l' دوال الصدفة ستستفيد من أمر alias عند إنشاء اختصارات لأوامر بسيطة، لكن ماذا لو أردت إنشاء شيءٍ أكثر تعقيدًا؟ عليك حينها أن تجرِّب شيئًا يسمى "دوال الصدفة" (shell functions)، التي يمكنك اعتبارها أنهَّا "سكربتات داخل سكربتات"، أو سكربتات فرعية صغيرة. لنجرب واحدةً منها! افتح ملف ‎.bashrc بمحررك وضع ما يلي بدلًا عن الاختصار today: today() { echo -n "Today's date is: " date +"%A, %B %-d, %Y" } صدِّق أو لا تصدِّق، () هو أمر مضمَّن بالصدفة أيضًا مثَلُهَ كَمَثَلِ الأمر alias، حيث يمكنك أيضًا إدخال دوال الصدفة مباشرةً من سطر الأوامر. $ today() { > echo -n "Today's date is: " > date +"%A, %B %-d, %Y" > } $ لكن تلك الدوال -مثلما هو عليه الحال مع الأمر alias- ستزول عند إغلاق جلسة الطرفية الحالية. ترجمة -وبتصرّف- للمقال Editing The Scripts You Already Have لصاحبه William Shotts.

سنتحدثُ في هذا الدّرس عن الطرق التي يُوفّرها لك كلّ من Bash، نظام لينكس والطرفيّة Terminal للتّحكم بالوظائف والعمليّات. ذكرنا في درس إدارة العمليات في لينكس باستخدام الطرفية كيفية استعمال الأوامر ps ،kill و nice للتحكم بالمهام على نظامك. سنُركّز في هذا المقال على إدارة عمليّات المُقدّمة وعمليّات الخلفيّة وسنشرح كيف ترفع من مُستواك في التّحكم بالوظائف والمهام لتحصل على مُرونة أكثر عند تنفيذك للأوامر. إدارة عمليات المقدمة مُعظمُ العمليّات التي تُشغّلها على لينكس ستُنفّذ في المُقدّمة. سيبدأ الأمر بالتّنفيذ ما يمنعك من تنفيذ أي أمر آخر طوال مدة تنفيذ العمليّة. يُمكن أن تسمح العمليّة بتَفاعلِ المُستخدم، أو يُمكن أن تُنفّذ إجراءًا معيّنا ثم تنتهي. وسيُعرض أي مُستخرج على شاشة الطرفية افتراضيّا، سنتطرّق إلى الطريقة المُبسّطة لإدارة عمليّات المُقدّمة أسفله. تشغيل عملية تُشَغّلُ العمليّات في المُقدّمة افتراضيا إلى أن تنتهي أو عند تغيّر الحالة، وأثناء تشغيل العمليّات لن تتمكن من التفاعل مع الصّدفة Shell. بعض أوامر المُقدّمة تنتهي بسرعة مُرجعة المُستخدم إلى واجهة الصدفة آنيّاً، وهذا الأمر هو مثال على ذلك: echo "Hello World" هذا الأمر سيطبع "مرحبا بالعالم" على شاشة الطرفيّة ثم يرجعك إلى شاشة الأوامر. بعض أوامر المُقدمة الأخرى تأخذ وقتا أطول للتنفيذ، مانعة الولوج إلى الصّدفة أثناء التشغيل. يُمكن أن يعود السبب إلى أن الأمر يُشغل عمليّة أعقد أو أنّ العمليّة مُبرمجة للتنفيذ إلى أن تتوقف بشكل واضح أو إلى أن تتلقى مُدخلات من المُستخدم. تُعتبر أداة top من الأوامر التي تنفذ لوقت غير محدود، فبعد تشغيلها ستستمر في التنفيذ وتحديث عناصر الشاشة إلى أن يقوم المُستخدم بإنهاء العملية: top يُمكنك الخروج بالضّغط على "q". بعض العمليّات لا تملك طريقة للخروج ولتوقفها سيجب عليك استخدام طريقة أخرى. إنهاء عملية لنفترض أننا قمنا بتشغيل حلقة تكرار بسيطة في سطر الأوامر، يُمكننا تشغيل حلقة تكرار تقوم بطباعة "Hello World" كل عشر ثوان. هذه الحلقة ستستمر في الطّباعة إلى أن تُوقَف إجباريّاً: while true; do echo "Hello World"; sleep 10; done حلقات التكرار كهذه لا تملك أي زر للإلغاء، سيتوجّب علينا أن نوقف العمليّة بارسال ما يسمّى بـ الإشارة signal. تستطيع النواة في لينكس إرسال إشارات إلى العمليّات لطلب إيقاف نهائيّ للعملية أو تغيير الحالة فقط، طرفيّات لينكس عادة ما تكون مضبوطة لإرسال إشارة "SIGNT" (الإشارة رقم 2) لعمليّة المُقدّمة الحاليّة عند ضغط تركيبة المفتاحين CTRL+C. تُخبر إشارة "SIGNT" البرنامج بأن المستخدم قد طلب إنهاء العمليّة مُستخدما لوحة المفاتيح. لإيقاف حلقة التكرار التي بدأناها اضغط على مفتاحي CTRL و"c": CTRL+C سيتم إغلاق حلقة التكرار و ستتمكن من التحكم بالصّدفة Shell مجددا. إشارة "SIGNT" المُرسلة عن طريق تركيبة CTRL+C واحدة من الإشارات المتعدّدة التي يمكن إرسالها إلى البرامج، مُعظم الإشارات لا تملك تركيبة مفاتيح مُرتبطة بها، وعليك إرسال هذه الإشارات باستخدام الأمر kill عوضا عن ذلك (سوف نغطي ذلك لاحقاً). تعليق العمليات ذكرنا أعلاه أن عمليّات المُقدّمة تمنعك من تنفيذ أي أمر آخر طوال مدة تنفيذ العمليّة. ماذا لو أدركنا أنّنا نحتاج إلى شاشة الطرفية بعد أن نُشغّل عملية في المُقدمة؟ إشارة "SIGTSTP" (الإشارة رقم 20) هي إشارة من الإشارات التي يمكن إرسالها إلى عمليّات المُقدّمة. عندما نضغط تركيبة مفاتيح CTRL+Z، تُسجل الطرفيّة أمر "تعليق"، الذي يرسل إشارة "SIGTSTP" إلى عملية المُقدمة. هذا الأمر سيوقف مؤقّتا تنفيذ الأمر ويعيد التحكم بالطرفيّة. كمثال على ذلك، لنستخدم أمر ping للاتّصال ب google.com كلّ 5 ثوان. سوف نُسبق الأمر بكلمة command، ما يُخولُ لنا تجاوز أي كُنيات للصدفة (shell aliases) يُمكن لها وضع عدّ أقصى على الأمر : command ping -i 5 google.com عوضا عن إنهاء العملية باستعمال CTRL+C، أدخل CTRL+Z بدلا من ذلك. CTRL+Z سيكون المُخرج هكذا: [1]+ Stopped ping -i 5 google.com لقد تم إيقاف الأمر ping مؤقّتاً، وبذلك تستطيع الوصول إلى جلسة الصّدفة shell لكتابة الأوامر مُجدّداً. يُمكننا استعمال أداة إدارة العمليّات ps لعرضها: ps T PID TTY STAT TIME COMMAND 26904 pts/3 Ss 0:00 /bin/bash 29633 pts/3 T 0:00 ping -i 5 google.com 29643 pts/3 R+ 0:00 ps t يُمكننا ملاحظة أن عمليّة ping لا تزال ضمن القائمة، لكن العمود STAT (الخاص بحالة العمليّة) يحمل القيمة "T". صفحة الدليل الخاصة بـ ps تخبرنا أن هذا الحرف يعني أن العملية قد أوقفت عن طريق إشارة "التحكم بالعمليات". سوف نتحدّث بعمق أكثر عن كيفية تغيير حالة العمليّة،لكن في الوقت الحالي يُمكننا استئناف تنفيذ العمليّة في المُقدمة بكتابة: fg عند استكمال التنفيذ، أنهِ العمليّة باستعمال CTRL+C: CTRL+C إدارة عمليات الخلفية البديل الرئيسي لتنفيذ عمليّة في المُقدمة هو تشغيلها في الخلفيّة، عمليّة الخلفية مرتبطة بالطرفيّة التي شغّلتها منها، لكنّها لا تمنعك من الوصول إلى الصّدفة (سطر الأوامر)، عوضا عن ذلك، تُنفّذ العمليّة في الخلفيّة، تاركة لمُستخدم حريّة التفاعل مع النظام أثناء تشغيل العمليّة. بسبب الطريقة التي تتعامل بها عمليّات المقدمة مع الطرفيّة، يمكن أن تُشغّل عمليّة واحدة فقط لكل نافذة من نوافذ الطرفية. ولأن عمليّات الخلفية ترجع التحكم بالصّدفة Shell مباشرة بدون انتظار انتهاء العمليّة، يُمكن تشغيل العديد من العمليّات في الخلفيّة في الآن ذاته. تشغيل العمليات يُمكنك تشغيل عمليّة في المُقدّمة بإلحاق محرف"&" عند نهاية الأمر. يُخبر هذا الصّدفة shell بألّا تنتظر إلى حين انتهاء العملية بل تشغيلها وإرجاع التحكم بالطرفيّة للمُستخدم فوراً. ستبقى المُخرجات تُعرض على شاشة الطرفية (إلا إذا قمت بـإعادة توجيهها) لكنّك ستتمكن من كتابة أوامر إضافية أثناء استمرار تنفيذ عمليّة الخلفيّة. على سبيل المثال، يُمكن أن نبدأ أمر ping نفسه من القسم السّابق في الخلفيّة: command ping -i 5 google.com & سترى مخرجا يبدو هكذا من نظام bash للتحكم بالعمليّات : [1] 4287 وسترى أيضا المُخرج العادي من طرف الأمر ping: PING google.com (74.125.226.71) 56(84) bytes of data. 64 bytes from lga15s44-in-f7.1e100.net (74.125.226.71): icmp_seq=1 ttl=55 time=12.3 ms 64 bytes from lga15s44-in-f7.1e100.net (74.125.226.71): icmp_seq=2 ttl=55 time=11.1 ms 64 bytes from lga15s44-in-f7.1e100.net (74.125.226.71): icmp_seq=3 ttl=55 time=9.98 ms رغم هذا ستتمكن من كتابة الأوامر في الوقت عينه. سوف يُمزج المُخرج من عمليّة الخلفيّة مع المدخلات والمخرجات الخاصة بعمليّة المُقدمة التي بدأتها، لكنّها لن تتداخل مع تنفيذ عمليّة المقدّمة. جدولة عمليات الخلفية لرؤية جميع العمليّات المُتوقفة أو عمليّات الخلفية، يمكنك استعمال الأمر jobs: jobs إذا كان الأمر ping مُشغّلا في الخلفية ستكون المخرجات على الشكل التالي: [1]+ Running command ping -i 5 google.com & يُبيّن هذا أنّنا نملك عمليّة واحدة في الخلفيّة. [1] تمثّل الـ "job spec" أو رقم الوظيفة. يُمكننا الإشارة إلى هذه العمليّة عند استعمال أوامر التحكم بالعمليّات مثل kill ،fg ،bg بإضافة سابقة "%" إلى رقم الوظيفة. في هذه الحالة سنشير إلى هذه الوظيفة بالإشارة 1%. إيقاف عمليات الخلفية يُمكننا إيقاف عمليّات الخلفيّة بعدّة طرق، أكثر طريقة نجاعة هي استخدام الأمر kill مع رقم الوظيفة. كمثال، يمكن أن نوقف أمرنا المُشغَّل في الخلفيّة بكتابة: kill %1 حسب طريقة ضبط الطرفيّة التي تستخدمها، إما مُباشرة أو بعض ضغط ENTER للمرة الثانية، ستشاهدُ حالة إيقاف الوظيفة على الطرفيّة: [1]+ Terminated command ping -i 5 google.com إذا تحققنا بالأمر jobs، سنلاحظ عدم وجود أي عمليّة. تغيير حالة العملية بعد أن تعرفنا على كيفية تشغيل عمليّة أو إيقافها في الخلفيّة، يُمكننا التحدث عن كيفية تغيير حالة العمليّة. شرحنا تغيير حالة واحدة قبل قليل عند التطرق لكيفيّة إيقاف مُهمّة أو تعليق عملها باستخدام CTRL+Z. يُمكننا نقل عمليّات المقدّمة إلى الخلفيّة أو العكس عندما تكون العمليّة في حالة توقّف. نقل عمليات المقدمة إلى الخلفية إذا نسيت أن تنهي الأمر بحرف العطف "&"، لا تزال قادرا على نقل هذه العمليّة إلى الخلفيّة. الخطوة الأولى هي إيقاف العمليّة باستخدام CTRL+Z: CTRL+Z عندما تتوقف العمليّة، يُمكننا استعمال الأمر bg لتشغيلها مجدّدا في الخلفيّة: bg ستشاهد حالة الوظيفة مع حرف العطف "&" ملحقا في الأخير: [1]+ ping -i 5 google.com & يعمل الأمر bg افتراضيّا مع آخر عمليّة تمت إيقافها، إذا أوقفت العديد من العمليّات بشكل متتالٍ بدون تشغيلها مجدّدا يُمكنك الإشارة إلى العمليّة برقم الوظيفة لإرسال العمليّة الصحيحة إلى الخلفيّة. لاحظ أنّه ليست كل العمليّات قابلة للإرسال إلى الخلفيّة. ستتوقف بعض العمليّات آليّاً إذا كشفت أنها نُفّذت مع إدخال ومخرج معياري متصلة مُباشرة مع طرفيّة نشطة. نقل عمليات الخلفية إلى المقدمة يُمكننا أيضاً نقل عمليّات الخلفيّة إلى المُقدّمة باستخدام الأمر fg: fg هذا الأمر يعمل مع آخر عمليّة منقولة إلى الخلفيّة، يُشار إليها بعلامة "+" في مخرجات jobs. الأمر يقوم فوراً بتعليق العمليّة ووضعها في المُقدّمة. لتحديد وظيفة أخرى استعمل رقم الوظيفة: fg %2 عندما تُنقل الوظيفة إلى المُقدّمة يُمكنك إمّا إنهاؤها مع CTRL+C، أو تركها لتكتمل أو تعليقها وإرسالها إلى الخلفيّة من جديد. التعامل مع إشارات SIGHUP سواء كانت العمليّة في المقدّمة أو في الخلفيّة، فستبقى مرتبطة بالطرفيّة التي بدأت العمليّة منها، عندما تغلق الطرفيّة فإنها ترسل إشارة SIGHUP لجميع العمليّات (في المُقدمة، في الخلفيّة، أو المتوقّفة) المرتبطة بها. ما يُشير إلى العمليّات بالإنهاء لأن الطرفيّة المُتحكِّمة ستصبح غير مُتوفرة قريباً، ماذا لو أردت إغلاق طرفيّة مع إبقاء تنفيذ عمليّات الخلفيّة؟ هناك العديد من الطرق للقيّام بذلك، أكثر الطرق مرونة هي باستعمال مُضاعف طرفيّة (terminal multiplexer) مثل tmux أو screen، أو استعمل أداة تمنح خاصية الفصل مثل dtach. على الرغم من هذا فهذه الطرق ليست دائما خيّارا ممكنا، ففي بعض الأوقات قد لا تكون هذه البرمجيات متوفرة أو أنّك قد سبق وبدأت العمليّة التي تريدها أن تستمر في التنفيذ بعد إغلاق الطرفيّة. استعمال nohup إذا كنت تعلم أنك عند تشغيل العمليّة سترغب في إغلاق الطرفيّة قبل انتهاء العمليّة، يُمكنك تنفيذها باستخدام أمر nohup، هذا الأمر يؤمّن العمليّة من التعرض إلى الإنهاء من طرف إشارة SIGHUP وستستمر في التنفيذ عندما تُغلق الطرفيّة. وستسجل كابن للنظام الأساسي: nohup ping -i 5 google.com & سترى سطرا يبدو كالتالي، مبيّنا أن مُخرجات الأمر ستُكتب في ملف يسمى nohup.out (في المجلّد الحالي إذا ما كان قابلا للكتابة عليه، في حالة لم يكن قابلا للكتابة عليه فسيُنشئه في مُجلّد المنزل): nohup: ignoring input and appending output to 'nohup.out' والغرض منه التأكد من أن المخرجات ليست مفقودة بعد إغلاق الطرفيّة. إذا أغلقت نافذة الطرفية وفتحت أخرى، ستبقى العمليّة في طور التنفيذ، ولن تتمكن من رؤيتها في مخرجات الأمر jobs لأن كل طرفيّة تحمل صفّ وظائف خاص بها، إغلاق الطرفيّة سبّب تدمير الوظيفة ping رغم أن العمليّة ping لا تزال تُنفّذ. لإيقاف عمليّة ping، يجب عليك البحث عن معرّف العمليّة (process ID) أو PID الخاص بها، يُمكنك القيّام بذلك بالاستعانة بالأمر pggrep (هناك أيضا الأمر pkill، لكنّنا بهذه الطريقة المقسّمة إلى خطوتين نكون متأكدين من أننّا سنوقف العمليّة التي نريدها فقط). استعمل pgrep مع a- للبحث عن العمليّة: pgrep -a ping المُخرجات: 7360 ping -i 5 google.com يُمكنك بعدها إيقاف العمليّة بإلحاق معرف العمليّة (الرقم في العمود الأول) بالأمر kill: kill 7360 قد ترغب في حذف ملف nohup.out إذا لم تكن تريده بعد الآن. استعمال disown يكون الأمر nohup مُفيدا فقط عندما تعلم أنّك ستحتاج إليه عند بدأ عمليّة ما. نظام إدارة الوظائف الخاص بـ bash يتيح لنا طرقا أخرى للحصول على نتائج مماثلة مع أمر diswon. عند الضبط الافتراضي للأمر disown، يقوم الأمر بحذف الوظيفة من طابور الوظائف الخاص بالطرفيّة. ما يعني أنك لن تستطيع إدارة العمليّة باستعمال التقنيّات التي تطرقنا إليها (مثل fg ،bg ،CTRL+Z ،CTRL+C). سيُحذف فوريّا من قائمة مخرجات الأمر jobs ولن يكون مرتبطا بالطرفيّة بعد ذلك. يُستعمل الأمر عن طريق تحديد العمليّة بالاستعانة برقم وظيفتها، على سبيل المثال، لتتبرر (disown) من الوظيفة رقم 2، يمكننا كتابة: disown %2 هذا الأمر سيترك الوظيفة في حالة مثل الأمر nohup، الاستثناء الوحيد هو أن جميع المُخرجات ستُفقد بعد إغلاق الطرفيّة في حالة لم يتم إعادة توجيهها إلى ملف ما. لن ترغب عادة في حذف العمليّة من قائمة التحكم بالوظائف إذا لم تكن تريد إغلاق نافذة الطرفيّة فورا.يمكنك إضافة h- للأمر لتقوم العمليّة بتجاهل إشارات SIGHUP، وتستمرَّ في العمل كوظيفة عاديّة: disown -h %1 في هذه الحالة، يُمكنك استعمال تقنيّات التحكم بالوظائف للاستمرار في التحكم بالوظيفة إلى حين إغلاق الطرفيّة، عند إغلاق الطرفيّة، ستكون عالقا -مرة أخرى- مع عمليّة دون أي مُخرجات إذا لم تعِد توجيهها إلى ملف عندما بدأتها. للعمل على ذلك، يمكنك محاولة إعادة توجيه مخرجات العمليّة بعد أن شغلتها. هذا الأمر خارج مجال هذا الدرس. يمكنك الإطلاع على الدرس مقدمة إلى إعادة توجيه الإدخال/الإخراج (I/O) في لينكس لمزيد من المعلومات. استعمال خيار الصدفة: huponexit هناك أيضا طريقة أخرى في Bash لتجنّب مشكلة إشارات SIGHUP للعمليّة الابن، يتحكم خيّار huponexit في ما إذا كان bash سيرسل إشارة SIGHUP للعمليّة الابن عند الخروج أو لا. ملاحظة: خيّار huponexit يؤثّر على طريقة تصرف إشارات SIGHUP فقط إذا كان إغلاق جلسة الصّدفة من داخل الصّدفة نفسه. يعتبر الأمر exit أو CTRL+D من الأمثلة على إغلاق الجلسة من داخل الصّدفة. عند إنهاء جلسة صدفة من برنامج الطرفيّة (بإغلاق النافذة، ...)، لن يكون للأمر huponexit أي تأثير، عوضا عن ترك اتخاذ قرار إرسال إشارة SIGHUP لـ bash سترسل الطرفيّة بنفسها الإشارة إلى bash، والتي ستبثّ (بشكل صحيح) الإشارة إلى العمليّة الابن. رغم المحاذير أعلاه، يعتبر خيار huponexit أسهل من الطرق. يُمكنك معرفة ما إذا كانت هذه الخاصية مُشغّلة أو لا بكتابة: shopt huponexit لتشغيل الخاصيّة: shopt -s huponexit الآن، إذا قمت بالخروج من الجلسة بالأمر exit، فإن العمليّات ستستمر في العمل: exit لدى هذا الأمر نفس المحاذير حول المُخرجات مع الخيّار السابق، لذلك تأكد أنّك قمت بتوجيه مُخرجات العمليّة قبل إغلاق الطرفيّة إذا كانت مُهمّة. خاتمة سيمنحك تعلّم التحكم بالوظائف وكيفيّة إدارة عمليّات المُقدمة وعمليّات الخلفيّة مرونة أكثر عند تشغيل البرامج من سطر الأوامر. عوضا عن فتح عدّة طرفيّات أو جلسات SSH، تستطيع أن تدبّر الأمر ببضع أوامر إيقاف وإرسال إلى الخلفيّة. ترجمة -وبتصرّف- للمقال How To Use Bash's Job Control to Manage Foreground and Background Processes لصاحبه Justin Ellingwood.

يعدّ أمر tar من بين الأدوات التي يشيع استخدامها في سطر أوامر لينكس، إلا أن جوانب مفيدة كثيرة في الأمر تبقى مجهولة. نعرض في هذا المقال بعض أشهر استخدامات الأمر tar إضافة إلى استخدامات رائعة أخرى يقل الانتباه إليها. أول ما تجب معرفته هو الغرض الأساسي من tar؛ إذ يعمل الأمر على جمع الكثير من الملفات في واحد. إذا نفذت أمر tar على مجلّد من 37 ملفّا فستحصُل على ملفّ واحد يضمّها جميعا وبالتي يسهُل مشاركتها مع الآخرين. كما أن الأمر يحافظ على بنية المجلّد ويمكن أن يحافظ على الأذونات ومعلومات الوقت والزمن كذلك. الخيارات في ما يلي قائمة بأهم الخيارات التي يمكن استخدامها مع tar. c: إنشاء ملف أرشيف. f: استخدام مُخرج الأمر لإنشاء ملف. تظهر مخرجات الأمر في الطرفية فقط إن لم يٍُستخدَم هذا الخيار. x: استخراج محتويات ملف أرشيف. j: استخدام خوارزمية bzip2 لضغط الملفات. z: استخدام خوارزمية gzip لضغط الملفات. p: الحفاظ على الأذونات عند استخراج الملفات. t: الحصول على قائمة بمحتويات ملف الأرشيف. v: عرض تقدّم عمل الأمر أثناء تنفيذه. d: عرض الفروق بين ملف الأرشيف ونظام الملفات. إنشاء ملف أرشيف إنشاء ملف أرشيف لمجلّد: tar cf directory.tar directory إنشاء ملفّ أرشيف انطلاقا من مجموعة ملفات: tar cf directory.tar file1 file2 file3 إنشاء ملف أرشيف مضغوط بخوارزمية bzip لملفات mp3 الموجودة في المجلّد الحالي: tar -cvf mp3collection.tar ./*.mp3 إنشاء ملف أرشيف من المجلد /home/academy/ مع الحفاظ على الأذونات: tar cvpf academy.tar /home/academy/ إنشاء أرشيف من المجلد etc/ مع استبعاد المجلد الفرعيّ apache2: tar cvf etc_without_apache.tar –exclude='/etc/apache2/' ضغط الملفات إنشاء ملف مضغوط بـbzip2 مع عرض تقدّم عمل الأمر في الطرفية: tar cjvf directory.tar.bz2 directory/ إنشاء ملف مضغوط بـgzip مع عرض تقدّم عمل الأمر في الطرفية: tar czvf directory.tar.gz directory/ عرض محتوى أرشيف عرض محتوى ملف الأرشيف directory: tar tvf directory.tar.bz2 ... bluewaters_1440x900.jpg cloudyday_1440x900.jpg fragile_1600x1200.jpg coolemoticon_1440x900.jpg cloudyday_1440x900.jpg ... الاستخراج من ملفات الأرشيف استخراج محتوى ملف أرشيف: tar xvf directory.tar.bz2 استخراج ملف passwd فقط من أرشيف etc: tar xvf etc.tar.bz2 passwd استخراج مجلد postfix فقط من أرشيف etc: tar xvf etc.tar.bz2 /etc/postfix/ استخراج ملفات php فقط من أرشيف htdocs: tar xvf htdocs.tar.bz2 –wildcards '*.php' الفروق الفرق بين ملف أرشيف ومجلّد (في حال عدم ذكر المجلد فالمقارنة تكون مع مجلد بنفس اسم الأرشيف في المجلد الحالي): tar df directory.tar.bz2 البحث عن ملف في الأرشيف: tar df directory.tar.bz2 directory/file1 ملحوظة: يجب في إصداراتٍ من tar تمرير خيار خوارزمية الضغط أثناء استخراج الملفات أو أثناء النظر في فروق ملفات أرشيف مضغوطة)؛ إلا أن الأمر اختياري في أغلب الإصدارات الأخيرة. مثلا: tar xjvf etc.tar.bz2 /etc/postfix/ بدلا من: tar xvf etc.tar.bz2 /etc/postfix/ ترجمة -وبتصرّف- لمقال A tar Primer لصاحبه Daniel Miessler.

يجد كثير من مستخدمي لينكس والأنظمة الشبيهة بيونكس عموما مشاكل في فهم أذونات Permissions الملفات والمجلّدات. يتعلق الأمر أحيانا بترتيب أوضاع بتات القراءة، الكتابة أو التنفيذ؛ بينما تكمن الصعوبة أحيانا أخرى بفهم رموز العدّ الثمانيّ Octal أو ربما كيفية حل لغز بت setuid والبت اللاّصق Sticky bit. يتوجّه هذا المقال إلى من لم يفهم قطّ هذه الأذونات بالدرجة الأولى وإلى من يجد خلطا من حين لآخر في تفاصيلها. راجع أيضا مقال مقدّمة إلى أذونات لينكس Linux Permissions. الأساسيات نبدأ أولا بالنظر إلى مخرجات أمر ls: ls -lah -rwxr-xr-- 1 daniel consultants 5K Mar 10 06:55 scanner.rb -rwxr-xr-x 1 sarah teachers 18M Jul 30 10:07 papers.tar.bz2 ثلاث مجموعات من ثلاثة أحرف: بما أن الأمر يتعلّق هنا بملفات فستظهر عارضة - في أول كل مُخرَج (سطر) . تلي العارضة مجموعة محارف (9 بالضبط، تدخُل العوارض - في الحساب) سنصطلح على تقسيمها إلى ثلاث مجموعات فرعية متساوية (3x3). المستخدِم-المجموعة-الآخرون: نسمي المجموعات الثلاث على الترتيب المستخدِم User, U، مجموعة المستخدم Group, G والآخرين Other, O. يعني هذا أن أول مجموعة محارف (rwx في السطريْن) تتعلق بالمستخدِم مالك الملفّ، الثانية (r-x في السطريْن) تتعلّق بمجموعة المستخدمين مالكة الملفّ والثالثة (--r في السطر الأول وr-x في السطر الثاني) تعني الآخرين أي بقية المستخدمين. صاحب (مالك) الملف: يظهر في نتيجة الأمر المستخدم مالك الملف ومجموعة المستخدمين مالكة الملف كذلك، لكنك لن ترى الآخرين. يعود السبب في ذلك إلى أن أذونات الآخرين (مجموعة المحارف الأخيرة ضمن المجموعات الثلاث أعلاه) تنطبق على كل من ليس مالكَ الملف وليس ضمن مجموعة المستخدمين صاحبة الملف. الأعداد الثلاثة يرتبك بعضهم عندما يرى الأذونات مذكورة بصيغة مجموعة من ثلاثة أعداد، لكنّ الأمر ليس بهذا التعقيد. تذكّر فقط أن هذه الأعداد هي أماكن تحوي الرقم الموافق للإذن حسب الترتيب (من اليسار إلى اليمين): r (القراءة)، w (الكتابة) وx (التنفيذ). لاحظ الصورة. بالنسبة لكلّ رمز، نضربه في 1 إذا كان مذكورا في الأذونات وفي 0 إن لم يكن (تظهر عارضة مكانه)، ثم نجمع نتيجة كل ثلاثي. الأذونات على المجلدات يجب الانتباه إلى أن الأذونات على المجلدات تختلف عنها على الملفات. توحي أسماء الأذونات على الملفات بعملها: قراءة الملف (r)، الكتابة فيه أو حذفه (w) وتنفيذه (x)؛ بينما الدلالة مختلفة قليلا في المجلدات: يعني إذن القراءة على مجلد أن بإمكانك عرض المجلّد. يدلّّ إذن الكتابة أن لديك القدرة على إنشاء محتوى في المجلد أو حذفه منه. يشير إذن التنفيذ إلى أنه بالإمكان الدخول إلى المجلّد، تنفيذ أمر cd عليه مثلا. البت اللاصق، معرف المستخدم ومعرف المجموعة تمثّل هذه الخيارات الثلاثة الجزئية الأكثر تعقيدا لدى الكثيرين في أذونات لينكس. معرف المستخدم صُمِّم خيار معرّف المستخدم setuid (اختصار لـ Set user ID upon execution "اضبط معرّف المستخدم أثناء التنفيذ") لحلّ مشكل أساسي: غياب الإذن الكافي لتنفيذ بعض البرامج. كان حلّ هذا المشكل بإضافة خيار إلى الملف يقول “نفّذ هذا البرنامج وفق أذونات المستخدم الذي يملكه بغضّ النظر عن المستخدم الذي ينفّذ الملف”. ينبغي الحذر من استخدام هذا الخيار - الذي أصبح متجاوزا - إذ قد يؤدي لأخطار أمنية. إن حدث ومررت بإذن على النحو التالي فأنت أمام خيار setuid: -rwsr-xr-- 1 daniel consultants 5K Mar 10 06:55 scanner.rb لاحظ حرف s في أذونات المستخدم مالك الملف مكان إذن التنفيذ x. يشير حرف s إلى أن إذن setuid مضبوط. يظهر حرف s في المثال أعلاه صغيرا Lowercase وهو ما يعني أن خيار التنفيذ متاح أيضا لمالك الملف. إن كان خيار setuid فقط مضبوطا (بمعنى أنه لا يُتاح لمالك الملف إذن تنفيذه) فسيظهر الحرف كبيرا Uppercase هكذا S. ملحوظة: ينطبق التنبيه أعلاه بخصوص هيئة الحرف (صغير أو كبير) على جميع خيارات الأذونات الخاصة. المبدأ العام هو: إذا كان الحرف الذي يشير للإذن الخاص صغيرا فهذا يعني أن الإذن لدى المالك أيضا، أما إذا كان كبيرا فهذا يعني أنه ليس لدى المالك هذا الإذن. معرف المجموعة setguid يشبه الخيّار السابق في عمله مع فرق أنه يُطبَّق على مجموعة المستخدمين المالكة للملف بدلا من المستخدم المالك: -rwxr-Sr-x 1 bjones principals 101K Aug 16 04:01 grades.xml الفرق هنا بالمقارنة مع المثال في الفقرة السابقة هو أن حرف S يوجد ضمن أذونات المجموعة بدلا من المستخدِم. لاحِظ أيضا أن الحرف S في هذا المثال كبير وهو ما يعني أنّه ليس لدى المجموعة المالكة (principals في هذه الحالة) إذن التنفيذ ولكن عند تنفيذ المستخدِم bjones (المالك) أو مستخدم آخر ليس ضمن مجموعة principals للملف فإنّ التنفيذ سيكون بصلاحيات المجموعة المالكة. البت اللاصق يُستخدم هذا البت من أجل منع مستخدمين من التعديل على أو حذف ملفات مستخدِم أو مجموعة مستخدمين. يمكن تطبيق البت اللّاصق على ملفات عادية ولكنّه يُطبَّق أكثر على المجلّدات. نفرض مثلا أنك وضعت مجلدا تحت تصرّف مجموعة من التلاميذ ثم منحت لكل طالب مجلدا خاصا به. يمكن باستخدام البتّ اللاصق التأكد من أنه لن يكون بإمكان طالب حذفُ محتوى مجلد خاصّ بطالب آخر. يبدو البت اللاّصق كما يلي (لاحظ حرف t): drwxr-xr-t 1 alice alice 4.4K 2007-01-01 09:21 Alice التعديل على الأذونات استخدم أمر chmod لتعديل أذونات ملفّ بذكر الأذونات الجديدة التي تريد تطبيقها. يغيّر الأمر التالي أذونات مجلد الويب لتصبح 755: chmod 755 web_directory يغيّر الأمر أدناه أذونات ملف لتصبح 644: chmod 644 grocery_list.txt تعيين معرف المستخدم، معرف المجموعة والبت اللاصق يمكن استخدام أمر chmod أيضا لتعيين الأذونات الخاصّة. لتعيين معرّف المستخدم (نضيف 4 أمام الأذونات الاعتيادية): chmod 4644 script.rb يمكن أيضا استخدام طريقة إضافة الأذونات الأخرى: chmod u+s script.rb لتعيين معرّف المجموعة (نضيف 2 أمام الأذونات الاعتيادية): chmod 2644 script.rb أو: chmod g+s script.rb لتعريف البت اللّاصق (نضيف 1 أمام الأذونات الاعتيادية): chmod 1644 myfiles أو: chmod o+t myfiles ترجمة -وبتصرّف- للمقال A Unix and Linux Permissions Primer لصاحبه Daniel Miessler.

لينكس هو نظام تشغيلٍ متعدد المستخدمين مبني على مفاهيم يونكس (Unix) لملكيّة الملفّّات والأذونات (permissions) بهدفِ توفير حمايةٍ أفضل. إذا كنتَ تخطط لتحسين مهاراتك بلينكس فيجب عليك أن تمتلك فهمًا جيدًا لكيفية عمل ملكية الملفّّات والأذونات في لينكس. هناك العديد من التعقيدات عند التعامل مع ملكية الملفّّات والأذونات، لكننا سنحاول جهدنا لاستخلاص المفاهيم الأساسية المهمّة لفهم كيفية عملها سنتطرّق إلى كيفية عرض وفهم ملكية الملفّّات والأذونات في لينكس. إذا كنتَ تبحث عن دليلٍ حول كيفية تعديل الأذونات، فاطّلع على هذا الدّرس: مبادئ أذونات الملفات (File permissions) على لينكس. المتطلبات تأكّد من أنّك تفهم المفاهيم التي تم تغطيتها بالدروس السابقة في هذه السلسلة: مقدّمة إلى طرفية لينكس. أساسيات التصفّح في لينكس وإدارة الملفّّات. حول المستخدمين كما ذكرنا في المقدّمة، لينكس هو نظام متعدد المستخدمين. يجب علينا أن نفهم أساسيات مستخدمي ومجموعات نظام لينكس قبل الحديث عن ملكية الملفّّات والأذونات، لأنهما الكيانان اللذان ينطبق عليهما ملكية الملفّّات والأذونات. فلنبدأ بالحديث عن أساسيات ماهيّة المستخدمين أولًا. في لينكس، هناك نوعان من المستخدمين: مستخدمو النظام (system users) والمستخدمون العاديون (regular users)، بشكلٍ عام، مستخدمو النظام يتم استخدامهم لتشغيل العمليات غير التفاعلية (non-interactive processes) والعمليات التي تعمل بالخلفية (background processes) على النظام، بينما يتم استخدام المستخدمين العاديين لتسجيل الدخول إلى النظام وتشغيل العمليات التفاعلية. عندما تقوم بالولوج لأول مرّة إلى أيّ نظام لينكس، قد تلاحظ أن النظام يبدأ مع عدّة مستخدمين للنظام حيث يقوم هؤلاء المستخدمون بتشغيل الخدمات التي يعتمد عليها نظام التشغيل، وهذا الأمر طبيعي تمامًا. من الطرق السهلة لعرض جميع المستخدمين المتوفّرين على النظام هي عرض محتويات ملفّّ etc/passwd/. كلّ سطر في هذا الملفّّ يحتوي معلوماتٍ حول مستخدمٍ واحد، بدءً باسم المستخدم الخاص به (الاسم قبل إشارة ":” الأولى). يمكنك طباعة محتويات ملفّّ passwd عن طريق الأمر التالي: cat /etc/passwd المستخدم الجذر بالإضافة إلى النوعين السابقين للمستخدمين، هناك "المستخدم الجذر" أو ما يعرف بـSuperuser أو root user، وهو يمتلك القدرة على الكتابة فوق أي تقييدات لأذونات ملكية الملفّّات أو تعديلها. بشكلٍ آخر، هذا يعني أن المستخدم الجذر يمتلك القدرة على الوصول إلى أيّ شيءٍ على خادومه الخاص. حيث يتم استخدام هذا المستخدم لتطبيق التغييرات المتعلقة بالنظام بأكمله، ويجب إبقاء هذا المستخدم آمنًا. من الممكن أيضًا أن يتم إعداد حسابات مستخدمين آخرين تمتلك صلاحيات "المستخدم الجذر". في الواقع، من أفضل التدربيات الممكن القيام بها هو إنشاء مستخدمٍ عادي يمتلك صلاحيات sudo لإدارة مهام النظام. حول المجموعات المجموعات هي تجميعات لـ0 مستخدمين أو أكثر. ينتمي المستخدم عادةً إلى المجموعة الافتراضية ويمكن أيضًا أن يكون عضوًا في أيٍّ من المجموعات الأخرى على الخادوم. من الطرق السهلة لعرض جميع المجموعات المتوفّرة على الخادوم والأعضاء بداخلها هي الاطّلاع على ملفّّ etc/group/. لن نغطّي أساسيات إدارة المجموعات في هذا المقال، ولكن يمكنك تطبيق هذا الأمر في حال كنتَ فضوليًا عن مجموعاتك: cat /etc/group الآن صرتَ تعرف ماهيةَ المستخدمين والمجموعات، فلنتحدّث عن ملكية الملفّّات والأذونات. عرض ملكية الملفات والأذونات في لينكس، كلّ الملفّّات تعتبر مملوكة من طرف مستخدمٍ واحد ومجموعةٍ واحدة، وكلّ ملفٍّّ يمتلك أذونات الوصول الخاصة به. فلنأخذ لمحة على كيفية عرض أذونات الملفّّات وملكيّتها. الطريقة الأكثر شيوعًا لعرض أذونات ملفٍّّ ما هي باستخدام الأمر ls مع خيار السرد الطويل (long listing option)، كمثال: ls -l myfile . إذا كنتَ تريد عرض أذونات جميع الملفّّات الموجودة في مسارك الحالي، فقم باستخدام الأمر بدون أيّ معامِلات مثل: ls -l تلميح: إذا كنتَ في مسار المنزل الخاص بك وكان فارغًا، ولم تقم بإنشاء أي ملفّّات لعرضها بعد، فيمكنك متابعة العملية عن طريق سرد محتويات المسار etc/ باستخدام هذا الأمر: ls -l /etc بالأسفل تجدُ مثالًا على لقطة شاشة لِمَا يُمكن للخرج أن يكون، مع تسميات كلِّ عمودٍ من الخرج: لاحظ أنّه يتم سرد وضع كلّ ملفّّ، المالك، المجموعة والاسم الخاصّين به. باستثناء عمود وضع الملفّّ (file's mode) فإنّه من السهل فهم جميع أجزاء الخرج. للمساعدة في شرح جميع هذه الحروف والرموز، فلنقم بتقسيم عمود الوضع (Mode column) إلى مكوناته الأساسية. فهم وضع الملفات للمساعدة في فهم ما تعنيه تلك الحروف والرموز، ألقِ نظرة على هذه الصورة التوضيحية التي تشرح ماهية "الوضع" أو الـ"mode” الخاص بأول ملفٍّّ من المثال أعلاه: نوع الملفات في لينكس، هناك نوعان أساسيان من الملفّّات: عادي وخاص. يتم تحديد نوع الملفّّ عن طريق أول حرفٍ من الوضع الخاص به. في هذا الدليل سنشير إلى هذا عن طريق استخدام مصطلح "حقل نوع الملفّّ". يُمكن أن يتم التعرف على الملفّّات العادية عن طريق شَرْطَة hyphen ( - ) في حقل نوع الملفّّ الخاص بها. الملفَّّات العادية هي مجرد ملفَّّات صرّفَة تحتوي على بيانات. يتم تسميتها بالملفّّات "العادية" لتمييزها عن الملفّّات الخاصة. الملفّاّت الخاصّة هي الملفّات التي تمتلك محرف غير شَرْطَي (non-hyphen character) مثل الحروف العادية في حقل نوع الملفّ الخاصة بها، ويتم معاملتها من جانب نظام التشغيل بطريقةٍ مختلفة عن الملفّاّت المحلّية. المحرف الذي يظهر في حقل نوع الملفّ يحدّد نوع الملفّ الخاص. مثل المجلّدات (folders)، وهي الملفّاّت الخاصة الأكثر شيوعًا من بين الملفّاّت الخاصّة. يتم التعرّف على المجلّدات عن طريق محرف d الذي يظهر في حقل نوع الملفّ الخاصّ بالمجلّد (مثل لقطة الشاشة السابقة). هناك أنواعٌ أخرى من الملفّاّت الخاصّة ولكنّها ليست أساسية لِمَا سنتعلّمه هنا. أصناف الأذونات نعلمُ من الرسم البياني السابق أنّ عمود الوضع يحدد نوع الملفّّ، متبوعًا بثلاثة أصناف (classes) من الأذونات: المستخدم (المالك)، المجموعة والآخرون. ترتيب هذه الأصناف ثابت على جميع توزيعات لينكس. فلنلقِ نظرة على الأصناف التي ينتمي إليها كلّ نوعٍ من المستخدمين: المستخدم (User): مالك الملفّ (owner) ينتمي إلى هذا الصنف. المجموعة (Group): أعضاء مجموعة الملفّ ينتمون إلى هذا الصنف. الآخرون (Other): أيُّ مستخدمين آخرين ليسوا جزءًا من صنفيّ المستخدم أو المجموعة فهم ينتمون إلى هذا الصنف. قراءة الأذونات الرمزية الشيء التالي الذي من الواجب الاهتمام به هو تشكيلة المحارف الثلاثة الخاصّة بوضع الملفّ، لأنها هي التي تقوم بتحديد الأذونات الخاصّة بالملفّ، بشكلٍ رمزي (symbolic) يمتلكها كل ملفّ. يتم تمثيل أذونات الكتابة، القراءة والتنفيذ في كلِّ تشكيلةٍ ثلاثية (triad) على النحو التالي: القراءة: يتم تمثيلها بحرف r بالموقع الأول. الكتابة: يتم تمثيلها بحرف w بالموقع الثاني. التنفيذ: يتم تمثيله بحرف x بالموقع الثالث. في بعض الحالات الخاصّة، يمكن أن يكون هناك حرفٌ آخر هنا. عندما يتم وضع شَرْطَة ( - ) في أي موقعٍ من هذه المواقع، فهذا يعني الإذن المعين ذاك ليس متوفرًا لهذا الصنف. كمثال: إذا كانت التشكيلة الثلاثية للمجموعة المالكة لملفٍّ معين هي: --r ، فهذا يعني أن الملفّ هو قابل للقراءة فقط لتلك المجموعة المتصلة بالملفّ. فهم قراءة، كتابة وتنفيذ الملفات الآن صرتَ قادرًا على قراءة الأذونات الخاصّة بكلّ ملفّّ، وعلى الأرجح فإنّك الآن تريد معرفة مالذي يسمح كلّ نوعٍ من أنواع الأذونات للمستخدمين أن يفعلوا. سوف سنشرح كلّ إذنٍ بشكلٍ منفصل، ولكن عليك أن تتذكر أنّه غالبًا ما يتمُ استخدام خليط من هذه الأذونات مع بعضها البعض للسماح بوصولٍ معين إلى هذه الملفّات والمسارات من قبل المستخدمين. إليك شرحًا بسيطًا إلى نوع الوصول الذي يمنحه كلٌّ نوعٍ من الأذونات للمستخدمين. 1- القراءة يسمحُ إذن القراءة لملفٍّ عادي أن يتم عرضه من قبل المستخدم لمشاهدة محتويات الملفّ. لمجلد أو مسار، يسمح إذن القراءة لمستخدمٍ أن يقوم بعرض أسماء الملفّات الموجودة بتلك المجلدات أو المسارات. 2- الكتابة يسمحُ إذن الكتابة لملفٍّ عادي أن يتم تعديله أو حذفه من قبل المستخدم. لمجلدٍ أو مسار، يسمح إذن الكتابة بأن يتم حذف المجلد أو المسار وتعديل محتوياته (إنشاء، حذف وإعادة تسمية الملفّات الموجودة بداخله) وتعديل محتويات الملفّات التي يمكن قراءتها من قبل المستخدم. 3- التنفيذ يسمح إذن الكتابة بأن يتم تنفيذ ملفٍّ من قبل المستخدم (يجب على المستخدم أن يمتلك إذن القراءة أيضًا). أذونات التنفيذ يجب أن يتم إعطاؤها للبرامج التنفيذية وسكربتات الشلّ (shell scripts) قبل أن يتمكّن المستخدم من تشغيلها. لمجلدٍ أو لمسار، يسمح إذن التنفيذ بالوصول إلى البيانات الوصفية (metadata) الخاصة بالملفّات الموجودة بداخله (مثل الأمر cd أو ls -l). أمثلة على أوضاع الملفّات والأذونات الآن وبعدما صرتَ قادرًا على قراءة وضع الملفّات وفهم معنى إذنِ كلِ واحدٍ منها، فسوف نتطرّق إلى بضعة أمثلة لأوضاعٍ شائعة للملفّات مع شرحٍ بسيط حولها: -rw-------: تمثّل ملفًّا قابلًا للوصول فقط من قبل مالكه. -rwxr-xr-x: تمثّل ملفًّا قابلًا للتنفيذ من قبل جميع المستخدمين على النظام. -rw-rw-rw-: تمثّل ملفًّا قابلًا للتعديل من قبل جميع المستخدمين على النظام. drwxr-xr-x: تمثّل مسارًا يمكن لجميع المستخدمين على النظام الوصول إليه وقراءته. drwxrwx---: تمثّل مسارًا قابلًا للتعديل (بالإضافة إلى محتوياته) من قبل مالكه والمجموعة التي ينتمي إليها. drwxr-x---: تمثّل مسارًا يمكن الوصول إليه من قبل مجموعته. كما تلاحظ، عادةً، مالك الملفّ يتمتّع بغالب الأذونات الخاصة بالملفّ مقارنةً مع الصنفين الآخرين. عادةً، سترى أنّ صنفيّ "المجموعة" و "الآخرون" يمتلكان أذونات فرعية فقط من أذونات مالك الملفّ (مساوية لها أو أقل). هذا أمرٌ منطقي لأن الملفّات يجب أن تكون قابلة للوصول فقط من طرف المستخدمين الذين يحتاجون الوصول إليه لسببٍ معيّن. شيءٌ آخر لملاحظته هو أنّه وعلى الرغم من أنّه هناك العديد من تشكيلات الأذونات الممكنة، فإنّ عددًا محدودًا منها فقط قد يكون استخدامها منطقيًا في حالاتٍ معيّنة. كمثال فإنّ أُذنيّ الكتابة والتنفيذ غالبًا ما يتم إلحاقهما بإذن القراءة، لأنّه سيكون من الصعب تعديل، ومن المستحيل تنفيذ ملفٍّ لا تستطيع قراءته. تعديل ملكية الملفات والأذونات للإبقاء على هذا الدليل بأبسط ما يمكن، لن نتطرف إلى كيفية تعديل ملكيّة الملفّات والأذونات هنا. الخاتمة يجب أن تكون الآن قد امتلكت معرفة جيّدة حول كيفية عمل ملكيّة الملفّات والأذونات في نظام لينكس. إذا كنتَ تحبّ تعلم المزيد عن أساسيات لينكس، فمن المستحسن بشدّة أن تقوم بقراءة الدّرس القادم من هذه السّلسلة والذي سيكون حول إعادة توجيه الإدخال/الإخراج في لينكس. ترجمة -وبتصرّف- للمقال: An Introduction to Linux Permissions.

جمعنا في هذا المقال 10 أدوات تساعد مستخدمي لينكس في مهامّ متنوعة مثل مراقبة الشبكة، فحص النظام وأوامر أخرى للرفع من الإنتاجية. الأداة w يُظهر أمر w المستخدمين مسجلي الدخول إلى النظام والعمليات التي ينفذونها: w أضف الخيار h- للحصول على المساعدة: w -h nmon وهي أداة تعرض معلومات عن أداء النظام، يمكن تثبيتها على أوبنتو بالأمر: sudo apt-get install nmon ثم بعد التثبيت ننفذ الأمر: nmon يمكن للأداة تحصيل معلومات عن استخدام الشبكة، المعالج والذاكرة. اضغط على حرف c لمعلومات عن استخدام المعالج: وحرف n لمعلومات عن الشبكة: تعطي الأداة بالضغط على حرف d معلومات عن استخدام القرص الصلب: ncdu وهي أداة تُستعمَل لتحليل استخدام مساحة القرص الصلب. للتثبيت على أوبنتو نفذ الأمر: sudo apt-get install ncdu وللاستخدام: ncdu / تأخذ الأداة معطى يمثّل المجلد الذي نريد معرفة مساحته على القرص الصلب. في المثال أعلاه حدّدنا المجلّد الجذر. قد يأخذ تحليل القرص بعض الوقت حسب حجمه، ثم تظهر النتيجة: استخدم الأسهم للانتقال بين قائمة المجلدات، وزر Enter لاختيار مجلد، n لترتيبها حسب الاسم و s لترتيبها حسب الحجم (تُرتّب المجلدات مبدئيا حسب الحجم). slurm تُستخدَم هذه الأداة لمراقبة تدفق البيانات عبر الشبكة حيث تظهرها في شكل منحنيات بيانية. sudo apt-get install slurm استخدم الخيار i- لمراقبة واجهة شبكة محددة: slurm -i eth1 اضغط زر l و c للانتقال بين طريقتي العرض، r لتحديث الشاشة و q للخروج. findmnt يُُستخدَم أمر findmnt للعثور على نظم الملفات المركّبة Mounted. كما يُستخدَم لتركيب أو نزع تركيب أجهزة طرفية عند الحاجة. findmnt نستخدم خيار l- للعرض على هيئة لائحة. findmnt -l عرض نظم الملفات المركّبة في ملف fstab: findmnt -s يمكن أيضا البحث عن نظم الملفات حسب النوع: findmnt -t ext4 dstat هي أداة مجمَّعة لمراقبة استخدام الذاكرة، عمليات النظام وأداء القرص الصلب. تُعدّ dstat بديلا جيدا لكل من ifstat ،iostat و dmstat. للتثبيت: sudo apt-get install dstat نفذ أمر dstat للحصول على معلومات مفصّلة عن استخدام المعالج، القرص الصلب والشبكة. يتيح الخيار c- تركيز المعلومات المعروضة على المعالج: dstat -c كما يمكن استخدام الخيار l- مع c- لمعرفة متوسّط استخدام المعالج لدقيقة، 3 دقائق أو 15 دقيقة. يوجد خيار D-الذي يمكن من متابعة أداء تجزئة قرص صلب بدلا من كامل القرص (d- لعرض أداء القرص فقط دون بقية الإحصاءات): dstat -dD sda7 saidar أداة أخرى تعمل في سطر الأوامر لمراقبة إحصاءات النظام مثل استخدام القرص الصلب، الشبكة، الذاكرة، مساحة الإبدال Swap وغيرها. للتثبيت: sudo apt-get install saidar ثم ننفذ أمر saidar للحصول على إحصاءات عن مختلف موارد النظام. يمكن استخدام الخيار c- لتلوين المخرجات. saider -c ss تأتي ss (اختصار لـSocket statistics) بديلا لأداة netstat لتجميع معلومات من فضاء النواة Kernel، تتميّز بالسرعة مقارنة مع netstat. لعرض جميع الاتصالات (نستخدم less لتسهيل تصفح المخرجات، اضغط على زر المسافة للانتقال للشاشة الموالية): ss |less يمكن استخدام الخيار A- لحصر النتائج حسب النوع: ss -A tcp كما توجد إمكانية عرض أسماء ومعرّفات العمليات pid: ss -ltp ccze تتيح هذه الأداة عرض السجلات Logs بهيئة أكثر جاذبية، للتثبيت نفذ الأمر: sudo apt-get install ccze مثال على الاستخدام: tailf /var/log/syslog | ccze تمكّن الأداة أيضا من حفظ السجلات بنفس طريقة العرض في ملف HTML: tailf /var/log/syslog | ccze -h > /path_to_file.html يعرض الأمر عند استخدام الخيار l- وحدات الأداة (أنواع السجلات التي تتعامل معها). ranwhen.py وهو سكربت python يعمل في الطرفية لعرض نشاطات النظام بيانيا، ينشئ السكربت منحنيات بيانية ملوّنة لعرض تفاصيل الأنشطة. للتثبيت على أوبنتو أضف المستودع التالي: sudo apt-add-repository ppa:fkrull/deadsnakes ثم حدّث النظام: sudo apt-get update وثبّت الإصدار 3.2 من python: sudo apt-get install python3.2 نزّل السكربت: wget -c https://github.com/p-e-w/ranwhen/archive/master.zip ثم فك ضغطه: unzip master.zip && cd ranwhen-master بإمكاننا الآن تنفيذ الأداة: python3.2 ranwhen.py ترجمة - وبتصرّف - لمقال Ten 10 Useful Utilities For Linux Users لصاحبه Rajneesh Upadhyay.

يحتاج لينكس، مثل غيره من أنظمة التشغيل متعدّدة المستخدمين Multi-user system إلى طريقة للتحكّم في وصول المستخدمين إلى مختلف الملفات. ليس من المحبّذ مثلا أن يعدّل مستخدم آخر على ملفات الإعداد التي أخذ ضبطها كثيرا من وقتك. يُطبَّق مبدأُ الفصلِ هذا على نظام تشغيل لينكس بآلية الأذونات Permissions. كيف تعمل الأذونات يُخزَّن كلّ ملف على النظام بأذوناته الخاصّة. كيف تُمثَّل؟ من الراجح أنك صادفتها أثناء عملك على نظام لينكس: drwxr-xr-x -r-w-rwrw- -rwxr--r-- تظهر الأذونات عند تنفيذ أوامر مثل ls -l. تخبر سلسلة المحارف Charcters بمعلومات الملف؛ يمكن تقسيم سلسلة المحارف الخاصّة بمعلومات الملف إلى أربعة أقسام: القسم الأول: هو المِحرف الأول الذي يدلّ على نوع الملفّ. القسم الثاني: يحوي المحارف من 2 إلى 4؛ وهي أذونات المستخدِم مالك الملف؛ أي ما يحقّ لهذا المستخدم فعله على الملف. القسم الثالث: المحارف من 5 إلى 7؛ وهي أذونات المجموعة مالكة الملف. القسم الرابع: المحارف من 8 إلى 10؛ وهي أذونات بقية المستخدمين (ليسوا مالك الملف ولا ينتمون للمجموعة مالكة الملف). يمكن للمحرف الأول أن يكون أحد المحارف التالية: - للملفات العادية. d: للمجلّدات. l: للوصلات الرمزية Symbolic link. s: لمقابس Socket يونكس. p: لأنابيب الاتّصال. c: للأجهزة الطرفيّة المحرفيّة Character device file. b: للأجهزة الطرفيّة الكتليّة Block device file. توضّح المحارف التسعة التالية لنوع الملف الأذونات في ثلاثة أقسام من ثلاثة محارف (القسم الثاني، الثالث والرابع المذكورة أعلاه): تعرض المحارف الثلاثة الأولى أذونات القراءة، الكتابة والتنفيذ بالنسبة لمالك الملف. تعرض المحارف الثلاثة الموالية نفس الأذونات ولكن بالنسبة للمجموعة مالكة الملف؛ والمحارف الثلاثة الأخيرة الأذونات بالنسبة لبقية المستخدمين. يعني المحرف الأول من كل قسم من إذن القراءة (r)، المحرف الثاني إذن الكتابة (w) والمحرف الثالث إذن التنفيذ (x). يدلّ ذكر المحرف (w، r وx) على وجود الإذن أما غياب الإذن فيُشار إليه بعارضة -. يعني وجود عارضة مكان إذن القراءة (أو الكتابة أو التنفيذ) أن المعني (المالك، المجموعة أو الآخرين) ليس لديه هذا الإذن. بالعودة إلى المثال: drwxr-xr-x يعني هذا السطر أننا أمام مجلّد (المحرف الأول d)، لدى مالك الملف (المحارف من 2 إلى 4) جميع الأذونات (rwx)، لدى المجموعة المالكة (المحارف من 5 إلى 7) إذنا القراءة والتنفيذ ولكن ليس لديها إذن الكتابة (r-x)، ونفس الشيء بالنسبة لبقية المستخدمين. تعديل الأذونات يُستخدَم أمر chmod لتعديل الأذونات. توجد طريقتان لذلك: الأولى باستخدام الأحرف المذكورة أعلاه (w، r وx)، والثانية باستخدام أرقام. سنشرح الطريقة الأخيرة هنا لأنها أسرع كثيرا. chmod 775 ~/my/file نلقي نظرة على القائمة التالية لفهم معنى الأرقام: 4 = r 2 = w 1 = w = إذن غير موجود نجمع الأرقام للحصول على الأذونات. بالنسبة لإذن rwx فيجب أن يكون 4+2+1=7؛ إذن r-x يجب أن يكون 4+0+1=5 وهكذا. بما أن لدينا ثلاثة أقسام من الأذونات (المستخدِم المالك، المجموعة المالكة وبقية المستخدمين) فسنحتاج إلى ثلاثة أرقام، رقم لكلّ قسم. أي أننا نجمع الأرقام المقابلة لأذونات كل قسم ونضعها جنبا إلى جنب في عدد من ثلاثة أرقام: الرّقم على اليسار لأذونات المستخدم المالك، الرقم في الوسط للمجموعة المالكة والرقم على اليمين لبقية المستخدمين. نعرف، بتنفيذ المبدأ أعلاه ، أن الأمر السابق يعدّل أذونات الملف /my/file/~ لتصبح كالتالي (طبقنا الأمر على ملف عادي، وبالتالي تظهر - في معلومات الملف تليها الأذونات): -rwxrwxr-x تعديل ملكية ملف يوجد أمران لتعديل ملكية الملف، الأول وهو chown يغيّر المستخدم المالك والثاني chgrp ويغيّر المجموعة المالكة. تغيير المستخدم المالك (المالك الجديد للملف /my/file/~ هو user): chown user ~/my/file تغيير المجموعة المالكة (المجموعة الجديدة هي group): chgrp group ~/my/file إن لم تكن مالكَ الملف أو تنفذ الأمرين أعلاه بصلاحيات المستخدم الأعلى root فلن ينجح تنفيذ الأمر. ترجمة -وبتصرّف- للمقال Linux File Permissions Explained لصاحبه Radek Pazdera.

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.