أحمد صحبي

Lighttpd هو خادوم ويب خفيف مفتوح المصدر، وهو الأمثل للبيئات عالية السرعة مع الحفاظ على استخدام أقل للموارد. وهو بديل ممتاز لخوادم الويب شائعة الاستخدام Nginx و Apache. في هذا المقال سيتم تثبيت وإعداد Lighttpd على خادوم يعمل بنظام FreeBSD 11.0. يمكنك أيضا إضافة MySQL و PHP إلى خادوم الويب Lighttpd الجديد الخاص بك حتى تتمكن من تشغيل خدمات الويب فضلا عن محتويات ثابتة. المتطلبات الأساسية لإكمال هذا البرنامج التعليمي ستحتاج إلى: خادوم بنظام تشغيل FreeBSD 11.0. حساب مستخدم تم إعداده لتشغيل الأوامر مع sudo . إن حساب freebsd الافتراضي الذي يأتي مع Digital Ocean FreeBSD Droplet كاف لهذا البرنامج التعليمي. لمعرفة المزيد حول إعداد FreeBSD اقرأ سلسلة المقالات حول FreeBSD. الخطوة 1 - تثبيت Lighttpd هناك عدة خيارات لتثبيت Lighttpd، ولكن في هذا الدرس سوف نستخدم حزم التثبيت. هذه الطريقة أسرع من التثبيت من المصدر أو عبر المنافذ (Ports)، والبرمجيات المثبتة مع هذه الطريقة أسهل تحديثًا. لتثبيت Lighttpd مع الحزمة الخاصة به، أولًا حدّث معلومات المستودع للتأكد من أن لديك أحدث قائمة من الحزم المتاحة: sudo pkg update بعد ذلك حمّل وثبت الحزمة lighttpd: sudo pkg install lighttpd أكّد التثبيت عن طريق كتابة y . سيتم تثبيت Lighttpd. باستخدام هذا الإعداد الافتراضي سيظهر لك هذا الخطأ عند بدء تشغيل الخادوم: (network.c.260) warning: please use server.use-ipv6 only for hostnames, not without server.bind / empty address; your config will break if the kernel default for IPV6_V6ONLY changes وذلك لأن إعدادات Lighttpd الافتراضية لم يتم تهيئتها لدعم IPv6. لتجنب المفاجآت في وقت لاحق حرر ملف إعدادات Lighttpd ثم عطل دعم IPv6، لأنك لن تحتاج إليها لإكمال هذا الدرس. يمكنك تمكينه في المستقبل إذا قررت استخدامه: sudo ee /usr/local/etc/lighttpd/lighttpd.conf ابحث عن هذا الجزء: ... ## ## Use IPv6? ## server.use-ipv6 = "enable" ... وغير enable إلى disable ... ... server.use-ipv6 = "disable" ... بعد ذلك حدد موقع هذا السطر في نهاية ملف الإعداد: ... ... $SERVER["socket"] == "0.0.0.0:80" { } ألغه بإضافة الرمز # في أوله، لأنه لا لزوم له إذ كنا لا نستخدم IPv6: #$SERVER["socket"] == "0.0.0.0:80" { } ثم احفظ الملف وأغلق المحرر. بعد هذا سوف نقوم بإعداد MySQL الخطوة 2 - تركيب وإعداد MySQL MySQL هو نظام إدارة قواعد بيانات من شأنها أن تسمح بإنشاء قواعد بيانات لتطبيقات PHP التي تخطط لاستضافتها على خادوم الويب الخاص بك Lighttpd. سوف تقوم بتثبيت MySQL عبر الحزم، تماما كما فعلت مع Lighttpd. ثم عليك إعداد كلمة مرور للمستخدم الجذر MySQL وتعطيل بعض خيارات الاختبار الأخرى. وهذا يضمن أنه سيكون لديك إعداد آمن لــ MySQL. بما أنك قمت بتحديث معلومات مستودع pkg في الخطوة 1، يمكنك الآن تحميل وتثبيت حزمة خادوم MySQL بسرعة: sudo pkg install mysql57-server أكد التثبيت عن طريق الضغط على: y. بعد اكتمال التثبيت، مكّن MySQL لكي يبدأ عند تشغيل النظام: sudo sysrc mysql_enable=yes ثم شغل خدمة mysql-server : sudo service mysql-server start بعد بدء تشغيل الخدمة أمّن تثبيت MySQL باستخدام السكريبت mysql_secure_installation . سيؤدي هذا إلى إزالة بعض الإعدادات الافتراضية الخطرة وإغلاق الوصول إلى نظام قاعدة البيانات قليلا. شغل السكريبت بالأمر: sudo mysql_secure_installation سترى الرسالة التالية: Securing the MySQL server deployment. Connecting to MySQL server using password in '/root/.mysql_secret' بعد ذلك سيتم سؤالك عما إذا كنت تريد إعداد إضافة للتحقق من صحة كلمات المرور: VALIDATE PASSWORD PLUGIN can be used to test passwords and improve security. It checks the strength of password and allows the users to set only those passwords which are secure enough. Would you like to setup VALIDATE PASSWORD plugin? تحذير: تمكين هذه الميزة لهو شيء من الحكمة. إذا تم التمكين فسيتم رفض كلمات المرور التي لا تتطابق مع المعايير المحددة من قبل MySQL مع إظهار رسالة خطأ. وهذا سوف يسبب مشاكل إذا كنت تستخدم كلمة مرور ضعيفة أو كان لك برنامج يقوم تلقائيا بإعداد بيانات اعتماد مستخدم MySQL. لذلك يعد من الآمن أن تترك التحقق معطلًا، ولكن يجب عليك دائمًا استخدام كلمات مرور قوية وفريدة من نوعها لبيانات اعتماد قاعدة البيانات. أجب بنعم أو أيّ شيء آخر للمتابعة دون تمكين. إذا اخترت تمكين هذه الميزة فسيطلب منك تحديد مستوى التحقق من صحة كلمة المرور. ضع في اعتبارك أنه إذا قمت بإدخال 2 –وهو أقوى مستوى- فسوف تتلقى أخطاء عند محاولة تعيين أي كلمة المرور لا تحتوي على أرقام وحروف كبيرة وصغيرة ورموزا خاصة أو أي كلمة المرور هي موجودة في قواميس كلمات السر الشائعة. There are three levels of password validation policy: LOW Length >= 8 MEDIUM Length >= 8, numeric, mixed case, and special characters STRONG Length >= 8, numeric, mixed case, special characters and dictionary file Please enter 0 = LOW, 1 = MEDIUM and 2 = STRONG: بعد ذلك سيتم سؤالك عما إذا كنت ترغب في تغيير كلمة المرور للمستخدم الجذر: Change the password for root ? ((Press y|Y for Yes, any other key for No): اضغط على Y لتغيير كلمة المرور هذه. إذا مكنت التحقق من صحة كلمة المرور فستظهر لك قوة كلمة المرور للجذر الحالية، وستسأل إذا كنت تريد تغيير كلمة المرور هذه. New password: Re-enter new password: Estimated strength of the password: 100 Do you wish to continue with the password provided?(Press y|Y for Yes, any other key for No): اضغط Y للمتابعة مع كلمة المرور الجديدة. بالنسبة لبقية الأسئلة اضغط على Y ثم على مفتاح الإدخال في كل مرة. سيؤدي ذلك إلى إزالة بعض المستخدمين المجهولين وقاعدة بيانات الاختبار وتعطيل تسجيلات الجذر عن بعد وتحميل هذه القواعد الجديدة بحيث تجعل MySQL يعمل بالتغييرات التي أجريناها فورا. ثم قم بإعادة تشغيل خدمة mysql-server للتأكد من أن المثيل (Instance) الخاص بك نفَّذ على الفور التغييرات الأمنية: sudo service mysql-server restart بعد تثبيت وتشغيل MySQL يمكننا تثبيت وإعداد PHP. الخطوة 3 - تثبيت وإعداد PHP PHP هو المكون الذي يتكفل بعرض المحتوى الديناميكي. فإنه يمكنه أن يشغل السكريبتات، والاتصال بقواعد بيانات MySQL للحصول على المعلومات، وتسليم المحتوى إلى خادوم الويب لمعالجته ثم عرضه. مرة أخرى استخدم نظام الحزم لتثبيت PHP مع إضافة PHP المسماة mysqli لكي تضيف دعما MySQL: sudo pkg install php71 php71-mysqli Lighttpd لا يحتوي على معالجة للــ PHP مثل بعض خوادم الويب الأخرى، لذلك سوف نستخدم PHP-FPM الذي سيعمل في ” إدارة عمليات FastCGI “. سنقوم بإعداد Lighttpd لاستخدام هذه الوحدة لمعالجة طلبات PHP. قبل أن نفعل ذلك نحن بحاجة إلى إعداد PHP-FPM نفسها. ابدأ بتعديل ملف إعدادات PHP-FPM: sudo ee /usr/local/etc/php-fpm.d/www.conf سنقوم بإعداد PHP-FPM لاستخدام مقبس (socket) يونكس بدلا من منفذ شبكة للاتصال. هذا أكثر أمنا لخدمات التواصل داخل خادوم واحد. ابحث عن هذا السطر في ملف التهيئة: /usr/local/etc/php-fpm.d/www.conf listen = 127.0.0.1:9000 غيّر هذا السطر لكي يستخدم مقبس php-fpm : listen = /var/run/php-fpm.sock الآن عيّن المالك والمجموعة والأذونات للمقبس الذي سيتم إنشاؤه. ابحث عن هذا الجزء من ملف الإعداد: ... ;listen.owner = www ;listen.group = www ;listen.mode = 0660 ... قم بإلغاء علامة التعليق من أول السطر (;) بحيث يبدو كالتالي: ... listen.owner = www listen.group = www listen.mode = 0660 ... احفظ الملف وأغلقه بعد الانتهاء. بعد ذلك قم بإنشاء ملف php.ini ، هذا الملف سيقوم بإعداد السلوك العام لـ PHP. هناك نوعان من نماذج الملفات: php.ini-production و php.ini-development . سيكون php.ini-production أقرب إلى ما تريده لخادومك، لذا انسخه إلى المسار : /usr/local/etc/ وهو الموضع الذي تتوقع PHP العثور عليه في إعداداتها: sudo cp /usr/local/etc/php.ini-production /usr/local/etc/php.ini افتح الملف php.ini الجديد باستخدام محرر النصوص: sudo ee /usr/local/etc/php.ini داخل ملف الإعداد حدّد موقع الجزء الخاص بسلوك cgi.fix_pathinfo . ستراه مَلغِيّا ومعينا إلى القيمة 1 افتراضيا: ... ;cgi.fix_pathinfo=1 ... قم بإزالة الفاصلة المنقوطة لتمكين السطر وتعيين القيمة إلى 0. هذا سيمنع PHP من محاولة تنفيذ أجزاء من المسار إذا لم يتم العثور على الملف الذي تم تمريره إلى العملية. هذا يمكن أن يستخدم من قبل المهاجم لتنفيذ الشيفرات الخبيثة. ... cgi.fix_pathinfo=0 ... احفظ الملف وأغلق المحرر. ثم مكّن خدمة php-fpm لتبدأ مع بدء تشغيل النظام: sudo sysrc php_fpm_enable=yes ثم شغّل الخدمة: sudo service php-fpm start بعد ذلك لنقم بإعداد Lighttpd لمعالجة تطبيقات PHP. الخطوة 4 - إعداد Lighttpd لخدمة تطبيقات PHP في هذه الخطوة سوف نقوم بإعداد Lighttpd لاستخدام FastCGI و PHP-FPM. هذا سيمكّن الــ PHP على Lighttpd ويقدم دعما من PHP سريعا وفعّالا. أولاً مكّن وحدة FastCGI. افتح ملف إعداد وحدات Lighttpd: sudo ee /usr/local/etc/lighttpd/modules.conf حدد موقع القسم التالي: ... ## ## FastCGI (mod_fastcgi) ## #include "conf.d/fastcgi.conf" ... أزل الإلغاء عن طريق إزالة الرمز # . إذا لم تجد هذا السطر، فأضفه إلى نهاية الملف، سيصبح هكذا: ... ## ## FastCGI (mod_fastcgi) ## include "conf.d/fastcgi.conf" ... احفظ الملف وأغلق المحرر. بعد ذلك قم بتحرير ملف إعداد FastCGI: sudo ee /usr/local/etc/lighttpd/conf.d/fastcgi.conf يحتوي هذا الملف على عدة أمثلة ملغاة. أضف أسطر الإعداد التالية إلى نهاية الملف الذي سيقوم بإعداد Lighttpd لمعالجة ملفات PHP مع FastCGI و PHP-FPM: .. fastcgi.server += ( ".php" => (( "socket" => "/var/run/php-fpm.sock", "broken-scriptfilename" => "enable" )) )... بعد ذلك مكّن Lighttpd لكي يشتغل مع بداية تشغيل النظام. بهذه الطريقة سوف تبدأ Lighttpd تلقائيا كلما تم إعادة تشغيل خادوم الويب: sudo sysrc lighttpd_enable=yes ثم شغّل خدمة lighttpd : sudo service lighttpd start الآن بعد أن صار PHP على استعداد للاشتغال، دعونا نتأكد من أن كل شيء يعمل. الخطوة 5 - اختبار إعداد الخادوم لاختبار Lighttpd المعدّ حديثا أنشئ أولا المجلد /usr/local/www/data، هذا المجلد هو الذي سيبحث فيه Lighttpd عن صفحات الويب. sudo ee /usr/local/www/data/info.php ثم أنشئ info.php في المجلد /usr/local/www/data/ . سيختبر هذا الملف أن PHP يعمل ويتيح لك مراجعة المعلومات حول إعداد خادوم الويب في متصفح الويب: sudo ee /usr/local/www/data/info.php أضف هذا الكود إلى الملف: <?php phpinfo(); ?> احفظ الملف وأغلق المحرر. قم بزيارة الرابط http://your_server_ip/info.php من متصفحك سوف ترى مظهر الصفحة مثل هذا: تعرض هذه الصفحة معلومات حول نظام التشغيل وخادوم الويب وكيفية معالجة خادوم الويب لملفات PHP. كما تتحقق من أن خادوم الويب الخاص بك يمكنه أن يعالج ملفات PHP بشكل صحيح. إذا لم تشاهد هذه الصفحة ، وبدلا من ذلك شاهدت ” Error 503 Service Not Available ” فتأكد من أن خدمة php-fpm اشتغلت بشكل صحيح في الخطوة السابقة. بعد التحقق من أن الأمور تعمل قم بإزالة الصفحة info.php إذ أنها تعرض معلومات حول الخادوم الخاص بك يجب أن تبقى خاصة: sudo rm /usr/local/www/data/info.php تم الآن إعداد خادوم الويب بالكامل وهو على استعداد للعمل. ما عليك الآن سوى أن تضع ملفاتك في /usr/local/www/data لكي تتم معالجتها. الخلاصة الآن بعد أن صار خادوم الويب Lighttpd في الخدمة يمكنك استضافة صفحات الويب والمستندات والملفات الأخرى عليه. لجعل خادوم الويب أكثر أمانا من خلال إضافة إعدادات SSL وغيرها من ميزات الأمان ولمزيد من المعلومات حول Lighttpd قم بزيارة منتديات Lighttpd . ترجمة -وبتصرّف- للمقال How to Install Lighttpd with MySQL and PHP on FreeBSD 11.0 لصاحبه Brian Hogan

تعلمنا في الدرس السابق كيفية إعداد LXD وإعداد الشبكة بالإضافة إلى إنشاء حاوية Nginx والآن لنقم بإعداد Nginx داخل الحاوية: الخطوة 4 : تكوين حاوية Nginx لِنتصلْ بالحاوية webserver ولنقم بإعداد خادوم الويب. اتصل بالحاوية بالأمر lxc exec الذي يأخذ اسم الحاوية وأوامر التنفيذ كمدخلات: lxc exec webserver -- sudo --login --user ubuntu يشير المحرف “–” الأول إلى أن مدخلات الأمر lxc يجب أن تتوقف عندها وسيتم تمرير بقية السطر كأمر يتم تنفيذه داخل الحاوية. الأمر هو sudo --login –user Ubuntu وهو الذي سوف يوفر صدفة تسجيل الدخول للحساب ubuntu السابق الإعداد داخل الحاوية. ملاحظة: إذا كنت بحاجة إلى الاتصال بالحاوية باعتبارك جذرًا استخدم الأمر lxc exec webserver -- /bin/bash بدلًا من ذلك. بعدما تدخل إلى الحاوية ستبدو الصدفة الآن كما يلي. ubuntu@webserver:~$ المستخدم ubuntu في الحاوية لديه صلاحيات sudo مُعَدَّة مسبقًا ويمكنه تنفيذ أوامر بصلاحيات الجذر دون المطالبة بإدخال كلمة السر. تقتصر هذه الصدفة على حدود الحاوية. أيُّ شيء تقوم بتشغيله في هذه الصدفة سيبقى في الحاوية ولا يمكن الذهاب به إلى الخادوم المضيف. لنقم بإعداد Nginx في هذه الحاوية. حدّث قائمة حزم ubuntu داخل الحاوية وثبت Nginx: sudo apt-get update sudo apt-get install nginx ثم قم بتحرير صفحة الويب الافتراضية لهذا الموقع وأضف بعض الجمل التي تجعل من الواضح أن هذا الموقع يتم استضافته في الحاوية webserver . افتح الملف : sudo nano /var/www/html/index.nginx-debian.html أدخل التغيير التالي على الملف: <!DOCTYPE html> <html> <head> <title>Welcome to nginx on LXD container webserver!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx on LXD container webserver!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> لقد قمنا بتحرير الملف في مكانين، وعلى وجه التحديد أضفنا العبارة ” on LXD container webserver”. احفظ الملف وأغلق المحرر. الآن سجل الخروج من الحاوية وعُد إلى الخادوم المضيف: Logout استخدم الأمر curl لاختبار أن خادوم الويب في الحاوية يعمل. ستحتاج إلى عناوين IP لحاويات الويب التي يمكنك أن تجدها بتنفيذ الأمر lxd list. curl http://10.10.10.100/ يجب أن تكون المخرجات: <!DOCTYPE html> <html> <head> <title>Welcome to nginx on LXD container webserver!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx on LXD container webserver!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> خادوم الويب يعمل، ولكن لا يمكننا الوصول إليه إلا من خلال الـ IP الخاص. لِنوجِّهْ الطلبات الخارجية إلى هذه الحاوية حتى يتمكن العالم من الدخول إلى موقعنا على الويب. الخطوة 5 : إعادة توجيه الاتصالات الواردة إلى حاوية Nginx الجزء الأخير من اللغز هو ربط حاوية خادوم الويب بالإنترنت. Nginx مثبت في حاوية، وبشكل افتراضي لا يمكن الوصول إليه من الإنترنت. نحتاج إلى إعداد الخادوم المضيف لإعادة توجيه أيّ اتصالات قد يتلقاها من الإنترنت على المنفذ 80 إلى الحاوية webserver . للقيام بذلك سننشئ قاعدة iptables لإعادة توجيه الاتصالات. يتطلب الأمر iptables اثنين من عناوين IP: عنوان IP العام للخادوم (your_server_ip) وعنوان IP الخاص بحاوية nginx (your_webserver_container_ip) ، والذي يمكنك الحصول عليه باستخدام الأمر lxc list . نفذ هذا الأمر لإنشاء القاعدة: PORT=80 PUBLIC_IP=your_server_ip CONTAINER_IP=your_container_ip \ sudo -E bash -c 'iptables -t nat -I PREROUTING -i eth0 -p TCP -d $PUBLIC_IP --dport $PORT -j DNAT --to-destination $CONTAINER_IP:$PORT -m comment --comment "forward to the Nginx container"' وإليك شرح هذا الأمر: -t nat يعني أننا نستخدم جدول nat لترجمة العنوان. -I PREROUTING يعني أننا نقوم بإضافة القاعدة إلى سلسلة PREROUTING. -i eth0 يعني الواجهة eth0، وهي الواجهة العامة الافتراضية في Droplets. -p TCP يعني أننا نستخدم البروتوكول TCP. -d $PUBLIC_IP يحدد عنوان IP الوجهة . --dport $PORT : يحدد منفذ الوجهة (مثل 80 ). -j DNAT تعني أننا نريد إجراء قفزة إلى الوجهة NAT (DNAT). --to-destination $CONTAINER_IP:$PORT تعني أننا نريد الذهاب إلى عنوان IP الخاص بالحاوية المذكورة ومنفذ الوجهة. ملاحظة: يمكنك إعادة استخدام هذا الأمر لإعداد قواعد إعادة التوجيه ببساطة عن طريق تعيين متغيرات PORT و PUBLIC_IP و CONTAINER_IP في بداية السطر. فقط قم بتغيير القيم الملونة بالأحمر. يمكنك الاطلاع على قواعد IPTables عن طريق تشغيل هذا الأمر: sudo iptables -t nat -L PREROUTING سترى مخرجًا مماثلًا لهذا: Chain PREROUTING (policy ACCEPT) target prot opt source destination DNAT tcp -- anywhere your_server_ip tcp dpt:http /* forward to this container */ to:your_container_ip:80 ... اختبر الآن إمكانية الوصول إلى خادوم الويب، وذلك بالدخول إليه من جهاز الكمبيوتر المحلي باستخدام الأمر curl مثل هذا: curl --verbose 'http://your_server_ip' سترى رأس صفحة الويب التي أنشأتها في الحاوية متبوعًا بمحتوياتها: * Trying your_server_ip... * Connected to your_server_ip (your_server_ip) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.47.0 > Accept: */* > < HTTP/1.1 200 OK < Server: nginx/1.10.0 (Ubuntu) ... <!DOCTYPE html> <html> <head> <title>Welcome to nginx on LXD container webserver!</title> <style> body { ... هذا يؤكد أن الطلبات ستذهب إلى الحاوية. وأخيرًا .. لحفظ قاعدة جدار الحماية ثبت الحزمة iptables-persistent الحماية لكي يتم إعادة تطبيقها بعد إعادة التشغيل sudo apt-get install iptables-persistent عند تثبيت الحزمة ستتم مطالبتك بحفظ قواعد جدار الحماية الحالية. اقبل واحفظ جميع القواعد الحالية. عند إعادة تشغيل جهازك ستكون قاعدة جدار الحماية موجودة. بالإضافة إلى ذلك سيتم إعادة تشغيل خدمة Nginx في الحاوية الخاصة بك تلقائيا. الآن بعد أن قمنا بإعداد كل شيء لننظر في كيفية إزالته. الخطوة 6 : إيقاف وإزالة الحاوية ربما تقرر إزالة الحاوية واستبدالها. لنعرف كيف نقوم بذلك: لإيقاف الحاوية استخدم lxc stop : lxc stop webserver استخدم الأمر lxc list للتحقق من الحالة، ستكون المخرجات: +-----------+---------+------+------+------------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +-----------+---------+------+------+------------+-----------+ | webserver | STOPPED | | | PERSISTENT | 0 | +-----------+---------+------+------+------------+-----------+ لإزالة الحاوية استخدم lxc delete : lxc delete webserver نفذ الأمر lxc list مرة أخرى ليظهر لك أنه لا يوجد حاوية قيد التشغيل: +------+-------+------+------+------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +------+-------+------+------+------+-----------+ استخدم الأمر lxc help للاطلاع على خيارات إضافية. لإزالة قاعدة الجدار الناري التي توجه حركة المرور إلى الحاوية حدد أولا القاعدة في قائمة القواعد بهذا الأمر والذي يربط رقم سطر مع كل قاعدة: sudo iptables -t nat -L PREROUTING --line-numbers سترى القاعدة، مسبوقة برقم سطر، كما يلي: Chain PREROUTING (policy ACCEPT) num target prot opt source destination 1 DNAT tcp -- anywhere your_server_ip tcp dpt:http /* forward to the Nginx container */ to:your_container_ip استخدم رقم السطر هذا لإزالة القاعدة: sudo iptables -t nat -D PREROUTING 1 تأكد من إلغاء القاعدة من خلال مشاهدة القواعد مرة أخرى بالأمر: `sudo iptables -t nat -L PREROUTING --line-numbers` سترى أنه تمت إزالة القاعدة: Chain PREROUTING (policy ACCEPT) num target prot opt source destination احفظ التغييرات الآن حتى لا يتم العمل بالقاعدة بعد إعادة تشغيل الخادوم: sudo netfilter-persistent save يمكنك الآن إنشاء حاوية أخرى مع الإعدادات الخاصة بك وإضافة قاعدة جدار حماية جديدة لإعادة توجيه حركة المرور إليها. خلاصة لقد قمت بإعداد موقع ويب باستخدام Nginx في حاوية LXD. يمكنك من هنا إعداد المزيد من مواقع الويب حيث يقتصر كل واحد منها على حاويته الخاصة به، ويمكنك ايضا استخدام بروكسي عكسي لتوجيه حركة المرور إلى الحاوية المناسبة. سيعلمك كيف تفعل ذلك هذا المقال: كيف تستضيف مجموعة مواقع بشكل آمن باستخدام Nginx و Php-fpm على أوبنتو 14.04 يتيح لك LXD أيضا التقاط لقطات من الحالة الكاملة للحاويات، مما يجعل من السهل إنشاء نسخ احتياطية من أجل الرجوع إليها لاحقا. وإذا قمت بتثبيت LXD على خادومين مختلفين فمن الممكن توصيل الحاويات بعضها ببعض وترحيلها بين الخوادم عبر الإنترنت. لمعرفة المزيد عن LXD اقرأ هذه التدوينات عن LXD التي كتبها مطورو LXD يمكنك أيضا تجربة LXD على الانترنت واتباع البرنامج التعليمي على شبكة الإنترنت للحصول على مزيد من الممارسة. ترجمة -وبتصرّف- للمقال How to Set Up and Use LXD on Ubuntu 16.04 لصاحبه Simos Xenitellis

حاوية لينكس هي مجموعة من العمليات المعزولة عن بقية النظام من خلال استخدام ميزات أمان نواة لينكس، مثل مساحات الأسماء ومجموعات التحكم. إنها بناء مماثل للآلة الافتراضية، و لكنه أكثر خفة منها، فإن لم يكن لديك النفقات الكافية لتشغيل أنوية إضافية أو آلات افتراضية فلا تقلق من ذلك، لأنه يمكنك بسهولة إنشاء حاويات متعددة على نفس الخادوم. على سبيل المثال، تخيل أن لديك خادوم يقوم بتشغيل مواقع ويب متعددة لعملائك. في حال التثبيت التقليدي سيكون كل موقع على شبكة الانترنت مضيفًا افتراضيًا من نفس حالة خادوم apache أو Nginx. ولكن مع حاويات لينكس يمكن لكل موقع على شبكة الإنترنت أن يثبت في حاوية خاصة به مع خادوم الويب الخاص بها. باستخدام حاويات لينكس يمكنك تجميع التطبيق الخاص بك واعتمادياته في حاوية دون التأثير على بقية النظام. يتيح لك LXD إنشاء هذه الحاويات وإدارتها. يوفر LXD خدمة مراقب الأجهزة الافتراضية لإدارة دورة الحياة الكاملة للحاويات. في هذا الدرس سوف نقوم بإعداد LXD واستخدامه لتشغيل Nginx في حاوية. وستقوم بعد ذلك بتوجيه حركة المرور إلى الحاوية من أجل جعل موقع الويب ممكن الوصول إليه من الإنترنت. المتطلبات الأساسية لإكمال هذا الدرس ستحتاج إلى ما يلي: خادوم أوبونتو 16.04 مُعَد مسبقا ، يمكنك الرجوع إلى هذه المقال لتعرف كيف تفعل ذلك: الإعداد الابتدائي لخادوم أوبنتو 14.04 مستخدم غير جذر يملك صلاحيات الجذر وجدار الحماية. اختياريًا أضف 20 جيغا أو أكثر من مساحة التخزين ، يمكنك استخدام ذلك لتخزين كافة البيانات المتعلقة بالحاويات. الخطوة 1 : إعداد LXD تم تثبيت LXD بالفعل على أوبونتو، ولكن يجب أن يتم إعداده بشكل مناسب قبل أن تتمكن من استخدامه على الخادوم. يجب عليك إعداد حساب المستخدم لإدارة الحاويات، ثم إعداد نوع قاعدة التخزين لتخزين الحاويات وإعداد الشبكة. قم بتسجيل الدخول إلى الخادوم باستخدام حساب المستخدم غير الجذر. ثم أضف المستخدم إلى مجموعة LXD بحيث يمكنك استخدامه لأداء جميع مهام إدارة الحاويات: sudo usermod --append --groups lxd Sammy قم بتسجيل الخروج من الخادوم وتسجيل الدخول مرة أخرى لكي يتم تحديث جلسة SSH الجديدة الخاصة بك مع عضوية المجموعة الجديدة. بعد تسجيل الدخول يمكنك البدء في تهيئة LXD. الآن قم بإعداد قاعدة التخزين. قاعدة التخزين الموصى بها ل LXD هو نظام ملفات ZFS، المخزنة إما في ملف مخصص مسبقًا أو باستخدام كتلة التخزين . لاستفادة من دعم ZFS في LXD حدّث قائمة الحزم الخاصة بك ثم ثبت الحزمة zfsutils-linux : sudo apt-get update sudo apt-get install zfsutils-linux يمكنك الآن إعداد LXD. ابدأ بعملية تهيئة LXD مع الأمر LXD init : sudo lxd init ستتم مطالبتك بتعيين تفاصيل قاعدة التخزين. بعد الانتهاء من هذا الإعداد يتوجب عليك إعداد الشبكة من أجل الحاويات. أولاً سوف يُقترح عليك أن تختار بشأن قاعدة التخزين، وستُخَير بين أمرين: dir أو zfs . الخيار dir يخبر LXD بتخزين الحاويات في مجلدات تابعة لنظام ملفات الخادوم. وأما الخيار zfs فيستخدم نظام الملفات zfs ونظام إدارة القرص الصلب LVM. اختر zfs. باستخدام zfs نحصل على كلٍّ من كفاءة التخزين وتحسين الاستجابة. على سبيل المثال إذا أنشأنا عشرة حاويات من نفس صورة الحاوية الأولية، فإنها جميعا تستخدم من القرص مساحةَ حاوية واحدة فقط. وبعد ذلك سيتم فقط تخزين التغييرات على صورة الحاوية الأولى في قاعدة التخزين. Name of the storage backend to use (dir or zfs) [default=zfs]: zfs بعد اختيار zfs سيُطلَب منك إنشاء تجمع (pool) zfs جديد واسم لهذا التجمع. اختر نعم لإنشاء التجمع، وسمه ب lxd : Create a new ZFS pool (yes/no) [default=yes]? yes Name of the new ZFS pool [default=lxd]: lxd ثم ستُسأل إذا كنت ترغب في استخدام عتاد التخزين الموجود: Would you like to use an existing block device (yes/no) [default=no] إذا أجبت بنعم فعليك أن تخبر LXD أين يجد هذا العتاد. إذا أجبت بلا فسوف يقوم LXD باستخدام ملف مخصص مسبقًا. مع هذا الخيار سوف تستخدم المساحة الفارغة على الخادوم نفسه. هناك حالتان يتبعان ذلك اعتمادًا على ما إذا كنت تريد استخدام ملف مخصص مسبقًا أو عتاد التخزين. اتبع الخطوة المناسبة لحالتك. بعد تحديد آلية التخزين ستعمل على تهيئة خيارات الشبكة من أجل حاوياتك. الخيار 1 : استخدام التخصيص المسبق يمكنك استخدام ملف مخصص مسبقًا إذا لم تتمكن من الوصول إلى عتاد التخزين من أجل تخزين الحاويات. اتبع هذه الخطوات لإعداد LXD لكي يستخدم ملف مخصص مسبقًا لتخزين الحاويات. أولًا، عندما يطلب منك استخدام عتاد التخزين الموجود أجب بلا : Would you like to use an existing block device (yes/no) [default=no]? no بعد ذلك، سيطلب منك تحديد حجم loop device ، الذي يستدعيه الملف المخصص مسبقًا من LXD. استخدام الحجم الافتراضي المقترح للملف المخصص مسبقًا : Size in GB of the new loop device (1GB minimum) [default=15]: 15 وكقاعدة عامة 15 جيغا هو أصغر حجم يجب عليك إنشاؤه. فأنت تريد تخصيص مساحة كافية لكي يكون لديك 10 غيغابايت على الأقل من المساحة المتبقية بعد إنشاء الحاويات الخاصة بك. بعد تهيئة الجهاز سيطلب منك إعداد الشبكة. انتقل إلى الخطوة 2 لمتابعة الإعداد. الخيار 2 : استخدام عتاد التخزين إذا كنت تريد استخدام عتاد التخزين قاعدةً للتخزين فستحتاج إلى العثور على العتاد الذي يتوافق مع حجم كتلة التخزين التي قمت بإنشائها في تهيئة LXD. انتقل إلى تبويب المجلدات في لوحة التحكم الخاصة ب DigitalOcean، ثم حدد موقع وحدة التخزين الخاصة بك، انقر فوق المزيد من القائمة المنبثقة، ثم انقر فوق تعليمات الإعداد. حدد موقع العتاد بتطبيق أمر تهيئة وحدة التخزين. بعبارة أدق ابحث عن المسار المحدد بتنفيذ الأمر sudo mkfs.ext4 -F . لا تقم بتشغيل أيٍّ من الأوامر الظاهرة في تلك الصفحة، نحن لا نريد سوى العثور على اسم الجهاز الصحيح لإعطاءه لـ LXD. يوضح الشكل التالي مثالا عن اسم الجهاز الخاص بوحدة التخزين. تحتاج فقط إلى الجزء المسطر عليه بالأحمر: يمكنك أيضا تحديد اسم الجهاز بالأمر التالي: ls -l /dev/disk/by-id/ total 0 lrwxrwxrwx 1 root root 9 Sep 16 20:30 scsi-0DO_Volume_volume-fra1-01 -> ../../sda في هذه الحالة اسم الجهاز لوحدة التخزين هو /dev/disk/by-id/scsi-0D0_Volume_volume-fra1-01 وقد يختلف الأمر لديك. بعد تحديد اسم عتاد وحدة التخزين تابع مع تثبيت LXD . عندما تُسأل هل تود أن تستخدم عتاد التخزين الموجود، اختر نعم وقدّم المسار الذي وجدته سابقا: Would you like to use an existing block device (yes/no) [default=no]? yes Path to the existing block device: /dev/disk/by-id/scsi-0DO_Volume_volume-fra1-01 بعد تحديد القرص الصلب سيطلب منك إعداد خيارات الشبكة. الخطوة 2 : إعدادات الشبكة بعد تهيئة وحدة التخزين ستتم مطالبتك بتهيئة الشبكة وإعدادها. أولاً سيسألك LXD عما إذا كنت تريد جعله متاحًا عبر الشبكة. اختيار “نعم” سوف يمكّنك من إدارة LXD من جهاز الكمبيوتر المحلي الخاص بك، دون الحاجة إلى جلسة SSH للوصول إلى هذا الخادوم. اقبل القيمة الافتراضية “لا” : Output of the "lxd init" command — LXD over the network Would you like LXD to be available over the network (yes/no) [default=no]? no ثم سيطلب منك إنشاء جسر الشبكة من أجل حاويات LXD. وهذا يتيح لك الميزات التالية: كل حاوية تحصل تلقائيًا على عنوان IP خاص. يمكن للحاويات التواصل مع بعضها البعض عبر الشبكة الخاصة. يمكن لكل حاوية انشاء اتصال بالإنترنت. تبقى الحاويات التي تقوم بإنشائها غير قابلة للوصول إليها من الإنترنت. لا يمكنك إجراء اتصال من الإنترنت والوصول إلى حاوية إلا إذا قمت بتمكينه صراحة. سوف تتعلم كيفية السماح بالوصول إلى حاوية معينة في الخطوة التالية. عندما يطلب منك تكوين جسر LXD، اختر نعم : Output of the "lxd init" command — Networking for the containers Do you want to configure the LXD bridge (yes/no) [default=yes]? Yes سيتم عرض الرسالة التالية: أكّد أنك تريد إعداد جسر الشبكة. سيطلب منك تسمية الجسر. اقبل القيمة الافتراضية. سيطلب منك إجراء تهيئة الشبكة لكلٍّ من IPv4 و IPv6. في هذا الدرس سنعمل فقط مع IPv4. عندما يطلب منك إعداد شبكة فرعية IPv4 اختر نعم . سوف يتم إعلامك بأنه تم إنشاء شبكة فرعية عشوائية بالنسبة لك. اختر موافق للمتابعة. عند المطالبة بعنوان IPv4 صحيح قم بقبول القيمة الافتراضية. عندما يطلب منك قناع CIDR صحيح، اقبل القيمة الافتراضية. عند المطالبة بعنوان DHCP الأول اقبل القيمة الافتراضية. افعل الشيء نفسه مع عنوان DHCP الأخير وذلك حسب الحد الأقصى لعدد عملاء DHCP. اختر نعم عندما يطلب إلى NAT حركة مرور IPv4. عندما يطلب منك إعداد شبكة فرعية لـ IPv6 اختر “لا” . ستشاهد المخرجات التالية بعد اكتمال إعداد الشبكات: Warning: Stopping lxd.service, but it can still be activated by: lxd.socket LXD has been successfully configured. أنت مستعد الآن لإعداد حاوياتك. الخطوة 3 : إنشاء حاوية Nginx لقد نجحت في تهيئة LXD وأصبحت الآن جاهزا لإنشاء الحاوية الأولى وإدارتها. يمكنك إدارة الحاويات مع الأمر lxc. استخدم lxc list لعرض الحاويات المثبتة المتاحة: lxc list سترى الإخراج التالي: Generating a client certificate. This may take a minute... If this is your first time using LXD, you should also run: sudo lxd init To start your first container, try: lxc launch ubuntu:16.04 +------+-------+------+------+------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +------+-------+------+------+------+-----------+ وبما أن هذه هي المرة الأولى التي يتواصل فيها الأمر lxc مع مراقب الأجهزة الافتراضية لـ LXD تتيح لك مخرجاته معرفة أنه قام تلقائيًا بإنشاء شهادة للعميل من أجل الاتصال الآمن مع LXD، وبعض المعلومات حول كيفية تشغيل حاوية، وقائمة فارغة من الحاويات، وهو أمر متوقع لأننا لم ننشئ أي واحدة حتى الآن. دعنا ننشئ حاوية تقوم بتشغيل Nginx. للقيام بذلك سوف نستخدم الأمر lxc launch لإنشاء وبدء حاوية أوبونتو 16.04 اسمها webserver. لإنشاء الحاوية webserver ننفذ الأمر: lxc launch ubuntu:x webserver x في ubuntu:x هو اختصار للحرف الأول من Xenial ، الاسم الرمزي لأوبونتو 16.04. ubuntu: هو معرف للمستودع الذي تم تكوينه مسبقا لصور LXD . يمكنك أيضا استخدام ubuntu:16.04 لاسم الصورة. ملاحظة : يمكنك العثور على القائمة الكاملة لجميع صور ubuntu المتاحة عن طريق تشغيل الأمر: lxc image list Ubuntu: وفي التوزيعات الأخرى عن طريق تشغيل الأمر: lxc image list images: نظرًا لأن هذه هي المرة الأولى التي تقوم فيها بإنشاء حاوية ينزّل هذا الأمرُ صورةَ الحاوية من الإنترنت ويخزنها محليًا بحيث إذا أنشأت حاوية جديدة فسيتم إنشاؤها بسرعة أكبر. سترى هذه المخرجات عند إنشاء الحاوية الجديدة: Generating a client certificate. This may take a minute... If this is your first time using LXD, you should also run: sudo lxd init To start your first container, try: lxc launch ubuntu:16.04 Creating webserver Retrieving image: 100% Starting webserver الآن ..بعد تشغيل الحاوية استخدم الأمر lxc list لعرض معلومات حولها: lxc list تظهر المخرجات جدولًا يحمل اسم كل حاوية وحالتها الحالية وعنوان IP خاص بها ونوعها وما إذا كانت هناك لقطات مأخوذة. Output +-----------+---------+-----------------------+------+------------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +-----------+---------+-----------------------+------+------------+-----------+ | webserver | RUNNING | 10.10.10.100 (eth0) | | PERSISTENT | 0 | +-----------+---------+-----------------------+------+------------+-----------+ ملاحظة: إذا قمت بتمكين IPv6 في LXD فقد يكون مخرج أمر lxc list كبيرًا جدًا عن أن تسعه الشاشة. يمكنك أن تستخدم بدلا عن ذلك الأمر lxc list –columns ns4tS الذي يظهر فقط الاسم والحالة و IPv4 والنوع وما إذا كانت هناك لقطات متاحة. لاحظ عنوان IPv4 للحاوية. ستحتاج إلى تهيئة الجدار الناري للسماح بالزيارات الواردة من العالم الخارجي. سنتابع في الدرس القادم كيفية تكوين وتوجيه وإزالة حاوية Nginx. ترجمة -وبتصرّف- للمقال How to Set Up and Use LXD on Ubuntu 16.04 لصاحبه Simos Xenitellis

Alerta هو تطبيق ويب يُستخدم لتعزيز وإزالة التنبيهات المتكررة من مختلف أنظمة المراقبة ومشاهدة ذلك كله على شاشة واحدة. يمكن أن تدمج Alerta مع العديد من أدوات المراقبة المعروفة مثل Nagios, Zabbix, Sensu, InfluxData Kapacitor وغيرها الكثير. في هذا الدرس سوف نقوم بتثبيت Alerta وإعداده لعرض الإشعارات من Nagios، نظام المراقبة المفتوح المصدر الأكثر شعبية. المتطلبات الأساسية لمتابعة هذا الدرس، سوف تحتاج إلى: خادومين CentOS 7 تم إعدادهما باتباع هذا الدليل الضبط المبدئي لخادوم CentOS 7 ، مع مستخدم sudo غير جذر وجدار الحماية. على الخادوم CentOS الأول، حيث ستشغل Nagios، قم بتثبيت المكونات التالية: Apache و MySQL و PHP, ، باتباع هذا الدليل: كيف تثبت حزم MySQL ،Apache ،Linux :LAMP و PHP Nagios 4، مع متطلباته باتباع هذا الدليل: كيف تستخدم Nagios 4 لمراقبة خواديم Ubuntu 14.04 على الخادوم CentOS الثاني حيث سنقوم بتثبيت Alerta في هذه المقالة ، قم بتثبيت Nginx و MongoDB و Alerta. الخطوة 1 – تثبيت وحدة وسيط الأحداث Nagios-to-Alerta يمكنك توسيع وظائف Nagios مع وحدات وسائط الأحداث الخاصة بــ (Nagios (Nagios Event Broker (NEB). NEB هي آلية دمج أحداث (Event) الخاصة بـ Nagios، ووحدات NEB هي المكتبات المشتركة التي تمكنك من دمج خدمات أخرى مع Nagios. في هذه الخطوة سنقوم بتثبيت بوابة Nagios-to-Alerta ، وهي وحدة NEB التي سوف ترسل إشعارات إلى Alerta. سجل الدخول إلى خادوم Nagios بمستخدم غير جذر: ssh sammy@your_nagios_server_ip بوابة Nagios-to-Alerta لا تحتوي على حزم جاهزة مسبقًا في نظام التشغيل، لذلك سيكون عليك بناؤها من المصدر. للقيام بذلك ستحتاج إلى تثبيت بعض أدوات التطوير والملفات. ستحتاج أيضًا إلى تثبيت Git حتى تتمكن من جلب شفرة المصدر من GitHub. sudo yum install -y git curl gcc make libcurl-devel استخدم Git الآن لاستنساخ الملفات المصدرية من مستودع GitHub للمشروع: git clone https://github.com/alerta/nagios-alerta.git ثم اذهب إلى مجلد nagios-alerts الجديد: cd nagios-alerta ثم جمّع وحدة nagios-alerta باستخدام الأمر make : make nagios4 سترى المخرجات التالية: cd ./src && make nagios4 make[1]: Entering directory `/root/nagios-alerta/src' gcc -fPIC -g -O2 -DHAVE_CONFIG_H -I../include -I../include/nagios4 -lcurl -o alerta-neb.o alerta-neb.c -shared -lcurl make[1]: Leaving directory `/root/nagios-alerta/src' إذا كنت ترى شيئا مختلفا فتأكد من تثبيت كافة المتطلبات الأساسية. الآن.. قم بالبدء في عملية التثبيت: sudo make install سترى هذه المخرجات، وهي تشير إلى أن الوحدة تم تثبيتها في /usr/lib/nagios : cd ./src && make nagios4 make[1]: Entering directory `/root/nagios-alerta/src' gcc -fPIC -g -O2 -DHAVE_CONFIG_H -I../include -I../include/nagios4 -lcurl -o alerta-neb.o alerta-neb.c -shared -lcurl make[1]: Leaving directory `/root/nagios-alerta/src' بعد تثبيت الوحدة يمكننا إعداد Nagios لاستخدام هذه الوحدة. الخطوة 2 – إعداد الوحدة Nagios-to-Alerta لنقم بإعداد Nagios لإرسال رسائل الإشعار إلى Alerta. أولًا، مكّن وحدة الوسيط Alerta المثبتة حديثًا في ملف الإعدادات الرئيسي لــ Nagios. افتح ملف إعدادات Nagios في المحرر: sudo vi /usr/local/nagios/etc/nagios.cfg ثم ابحث عن الجزء الذي يحتوي على توجيهات broker_module : .. # EVENT BROKER MODULE(S) # This directive is used to specify an event broker module that should # by loaded by Nagios at startup. Use multiple directives if you want # to load more than one module. Arguments that should be passed to # the module at startup are separated from the module path by a space. # [...] #broker_module=/somewhere/module1.o #broker_module=/somewhere/module2.o arg1 arg2=3 debug=0 ... لإعداد الوحدة Alerta تحتاج إلى اثنين من المدخلات الإلزامية: URL: العنوان الذي يتم استخدامه للتواصل مع Alerta API. key: مفتاح API ، لقد قمت بإنشائه في الخطوة 4 من البرنامج التعليمي السابق. ستحتاج إليه في المصادقة مع Alerta وإرسال الأحداث. أضف هذا السطر إلى الملف لإعداد دمج Alerta: ... broker_module=/usr/lib/nagios/alerta-neb.o http://your_alerta_server_ip/api key=ALERTA_API_KEY ... هناك بعض المخلات الاختيارية الإضافية التي يمكنك تعيينها أيضا: env: يحدد هذا اسم البيئة. اسم البيئة الافتراضي هو Production. hard_only : تجاوز النتائج في الحالة الصعبة فقط. يمكنك العثور على مزيد من المعلومات حول أنواع حالات Nagios في وثائق Nagios . عين هذا إلى 1 لتمكين هذا الوضع. debug: تمكين وضع معالجة وتصحيح الأخطاء. عيّن هذا إلى 1 لتمكين هذا الوضع. لتحديد كل هذه الخيارات استخدم هذا السطر بدلًا من السابق: ... broker_module=/usr/lib/nagios/alerta-neb.o http://your_alerta_server_ip/api key=ALERTA_API_KEY env=Production hard_only=1 debug=1 ... احفظ الملف وأغلق المحرر. من أجل تعيين التنبيهات حسب البيئة واسم الخدمة ستحتاج إلى إعداد أسماء البيئة والخدمات باستخدام: Nagios Custom Object Variables للقيام بذلك استخدم المتغيرات _Environment و _Service في الإعداد الخاص بك. دعنا نهيئ ذلك الآن. افتح ملف إعدادات كائنات Nagios الافتراضي، ستجده في الدليل /usr/local/nagios/etc/objects/ : sudo vi /usr/local/nagios/etc/objects/localhost.cfg سوف نجعل جميع التنبيهات في هذا المضيف من نوع تنبيهات “Production”، وسنسمي الخدمة الافتراضية بـ “Nagios” . ابحث عن تعريف المضيف التالي: ... define host{ use linux-server ; Name of host template to use ; This host definition will inherit all variables that are defined ; in (or inherited by) the linux-server host template definition. host_name localhost alias localhost address 127.0.0.1 } ... أضف القيم _Environment و _Service إلى الإعدادات: ... host_name localhost alias localhost address 127.0.0.1 _Environment Production _Service Nagios } ... الآن ضع علامة ” System ” على جميع الأحداث المرتبطة بانعدام المساحة أو قلتها في مساحة التخزين المخصصة للنظام. حدد موقع هذا الجزء من الملف الذي يحدد كيفية التحقق من المساحة الفارغة: ... define service{ use local-service ; Name of service template to use host_name localhost service_description Root Partition check_command check_local_disk!20%!10%!/ } ... قم بتعديله لربطه بخدمة System: ... define service{ use local-service ; Name of service template to use host_name localhost service_description Root Partition check_command check_local_disk!20%!10%!/ _Service System } ... احفظ الملف ثم أغلق المحرر. أعد تشغيل Nagios لتطبيق هذه الإعدادات الجديدة: sudo systemctl restart nagios.service تأكد من تشغيل الخدمة عن طريق التحقق من حالتها: systemctl status nagios.service سترى المخرج التالي: ... Jul 01 08:44:31 nagios nagios[8914]: [alerta] Initialising Nagios-Alerta Gateway module, v3.4.1 Jul 01 08:44:31 nagios nagios[8914]: [alerta] debug is off Jul 01 08:44:31 nagios nagios[8914]: [alerta] states=Hard/Soft Jul 01 08:44:31 nagios nagios[8914]: [alerta] Forward service checks, host checks and downtime to http://your_alerta_server_ip/api Jul 01 08:44:31 nagios nagios[8914]: Event broker module '/usr/lib/nagios/alerta-neb.o' initialized successfully. Jul 01 08:44:31 nagios nagios[8914]: Successfully launched command file worker with pid 8920 الآن Nagios سوف يرسل إشعارًا في أقرب وقت عن أيّ نظام أو خدمة وقع فيه مشكل. لنقم بإنشاء حدث اختبار. الخطوة 3 - توليد إشعار اختبار للتحقق من دمج Nagios-Alerta لنقم بتوليد إشعار لاختبار أن كل شيء متصل. افتراضيًا Nagios يحتفظ بمقدار مساحة القرص الحرة على الخادوم الخاص بك. سننشئ ملفًا مؤقتًا كبيرًا بما يكفي لتشغيل تنبيه استخدام نظام الملفات في Nagios. أولًا، حدد مقدار المساحة الحرة لديك على خادوم Nagios. يمكنك استخدام الأمر df لمعرفة ذلك: df –h ستشاهد الناتج مثل ما يلي: Filesystem Size Used Avail Use% Mounted on /dev/vda1 20G 3.1G 16G 17% / انظر إلى مقدار المساحة الحرة المتاحة. في هذه الحالة المساحة الحرة هي 16GB. قد تختلف المساحة الحرة لديك. استخدم الأمر fallocate لإنشاء ملف يستهلك أكثر من 80٪ من مساحة القرص المتوفرة والتي يجب أن تكون كافية لتحريك التنبيه: fallocate -l 14G /tmp/temp.img في غضون بضع دقائق سوف يقوم Nagios بتشغيل تنبيه حول مقدار المساحة الحرة على القرص وسوف يرسل إشعارًا إلى Alerta. سترى هذا الإشعار الجديد في لوحة التحكم الخاصة بــ Alerta: الآن بعد أن عرفت أن التنبيهات تعمل، احذف الملف المؤقت الذي قمت بإنشائه حتى تتمكن من استعادة مساحة القرص: rm -f /tmp/temp.img بعد دقيقة واحدة سوف يقوم Nagios بإرسال رسالة الاسترداد. سوف يختفي الإشعار من لوحة التحكم الرئيسية لــ Alerta، ولكن يمكنك عرض جميع الأحداث المغلقة عن طريق اختيار Closed. يمكنك النقر على صف الحدث لعرض مزيد من التفاصيل. الخلاصة في هذا المقال قمت بإعداد Nagios لإرسال إشعارات إلى خادوم آخر يقوم بتشغيل Alerta. Alerta يعطيك مكانًا مناسبًا لتتبع التنبيهات من العديد من الأنظمة. على سبيل المثال، إذا كانت بعض أجزاء البنية الأساسية تستخدم Nagios وأخرى تستخدم Zabbix فيمكنك دمج الإشعارات من كلا النظامين في لوحة واحدة. ترجمة -وبتصرّف- للمقال How To Monitor Nagios Alerts with Alerta on CentOS 7 لصاحبه Vadym Kalsin

تعرف على كيفية استخدام الروابط التي تجعل أعمالك أسهل من خلال توفير إمكانية الوصول إلى الملفات من مواقع متعددة من شجرة المجلدات في نظام ملفات لينكس. في مقالاتٍ لي كَتبتُ عن جوانب مختلفة من أنظمة ملفات لينوكس ، بما في ذلك مقدمة عن نظام الملفات EXT4 لينكس و إدارة الأجهزة في لينكس و مقدمة عن نظام ملفات لينكس و دليل مستخدم لينكس لإدارة وحدة التخزين المنطقية ، وقد أشرت فيها إلى ميزة مثيرة للاهتمام من أنظمة الملفات في لينكس، يمكن أن تجعل هذه الميزة بعض المهام أسهل من خلال توفير إمكانية الوصول إلى الملفات من مواقع متعددة من شجرة المجلدات في نظام الملفات. هناك نوعان من روابط الملفات في لينكس: صلب و لين . والفرق بين هذين النوعين كبير، ولكن كلا النوعان يستخدمان لحل مشاكل مماثلة. كلاهما يوفر مداخل ( أو مراجع) إلى ملف واحد، لكنها تفعل ذلك بشكل مختلف تمامًا . الروابط مفيدة جدًا وإضافة مرنة إلى أنظمة ملفات لينكس فكل شيء فيه هو ملف. لقد وجدت -على سبيل المثال- أن بعض البرامج تتطلب نسخة معينة من المكتبات . عندما تقوم بترقية النظام تحل مكتبة جديدة محل أخرى، سوف يتعطل البرنامج الذي تمت برمجته لاعتماد المكتبة القديمة. عادة يكون التغيير الوحيد في اسم المكتبة هو رقم الإصدار، ببساطة أضفت رابطًا يشير إلى المكتبة الجديدة ولكن باسم المكتبة القديمة. شغلت البرنامج مرة أخرى وقد عمل بشكل جيد. في الواقع ترتبط جميع التطبيقات تقريبًا بالمكتبات باستخدام اسم عام مع رقم إصدار رئيسي فقط ، وهذا الارتباط يشير إلى ملف المكتبة الفعلي الذي يحتوي أيضًا على رقم الإصدار الثانوي. وفي حالات أخرى يتم نقل الملفات المطلوبة من مجلد إلى آخر لتتوافق مع مواصفات لينكس، وتبقى في المجلدات القديمة روابط تشير إلى الملفات التي تم نقلها ، حتى إذا كان البرنامج لا يزال مرتبطًا بالمجلد القديم وملفاته لم يقع في مشكلة فقدان الملفات ، إذا عرضت الملفات في المجلد /lib64 فستجد العديد من الأمثلة على كلا الأمرين. lrwxrwxrwx. 1 root root 36 Dec 8 2016 cracklib_dict.hwm -> ../../usr/share/cracklib/pw_dict.hwm lrwxrwxrwx. 1 root root 36 Dec 8 2016 cracklib_dict.pwd -> ../../usr/share/cracklib/pw_dict.pwd lrwxrwxrwx. 1 root root 36 Dec 8 2016 cracklib_dict.pwi -> ../../usr/share/cracklib/pw_dict.pwi lrwxrwxrwx. 1 root root 27 Jun 9 2016 libaccountsservice.so.0 -> libaccountsservice.so.0.0.0 -rwxr-xr-x. 1 root root 288456 Jun 9 2016 libaccountsservice.so.0.0.0 lrwxrwxrwx 1 root root 15 May 17 11:47 libacl.so.1 -> libacl.so.1.1.0 -rwxr-xr-x 1 root root 36472 May 17 11:47 libacl.so.1.1.0 lrwxrwxrwx. 1 root root 15 Feb 4 2016 libaio.so.1 -> libaio.so.1.0.1 -rwxr-xr-x. 1 root root 6224 Feb 4 2016 libaio.so.1.0.0 -rwxr-xr-x. 1 root root 6224 Feb 4 2016 libaio.so.1.0.1 lrwxrwxrwx. 1 root root 30 Jan 16 16:39 libakonadi-calendar.so.4 -> libakonadi-calendar.so.4.14.26 -rwxr-xr-x. 1 root root 816160 Jan 16 16:39 libakonadi-calendar.so.4.14.26 lrwxrwxrwx. 1 root root 29 Jan 16 16:39 libakonadi-contact.so.4 -> libakonadi-contact.so.4.14.26 بعض الروابط في الدليل / lib64. تظهر القائمة الطويلة من الدليل /lib64 أعلاه أن الحرف الأول في الملف هو الحرف “l”، وهو ما يعني أن كلاً منها رابط لين ( رمزي). الروابط الصلبة Hard links في مقدمة لنظام الملفات EXT4 لينكس ، ناقشت حقيقة أن كل ملف يحتوي على inode واحد يحتوي على معلومات حول هذا الملف، بما في ذلك موقع البيانات الذي ينتمي إلى هذا الملف. الشكل 2 في تلك المقالة يظهر مدخل دليل واحد يشير إلى inode ، يجب أن يكون لكل ملفٍ مدخلُ دليل واحدٌ على الأقل يشير إلى inode الذي يصف الملف. مدخل الدليل عبارة عن رابط صلب Hard links ، وبالتالي يكون لكل ملف رابط صلب واحد على الأقل. في الشكل 1 أدناه، تشير مداخل الأدلة المتعددة إلى inode واحد. هذه كلها روابط صلبة. لقد اختصرت مواقع ثلاثة من مداخل الأدلة باستخدام التلدة ( ~ ) وهي تشير إلى المجلد الرئيسي، بحيث ( ~ ) يعادل /home/user . لاحظ أن مدخل الدليل الرابع مختلف تماما، (/home/shared ) والذي قد يكون موقعا لتبادل الملفات بين مستخدمي الكمبيوتر. شكل 1 تقتصر الروابط الصلبة على الملفات الموجودة في نظام ملفات واحد، “نظام الملفات” يستخدم هنا بمعنى التقسيم من القرص الصلب أو الحجم المنطقي( logical volume) الذي وُصِل إلى نقطة توصيل معينة ( specified mount point)، في هذه الحالة /home . وذلك لأن أرقام inode فريدة من نوعها فقط داخل نظام ملفات الواحد، وفي حال اختلف نظام ملفات -على سبيل المثال- /var أو /opt سيكون inode له نفس رقم inode لملفنا. كل الروابط الصلبة تشير إلى inode واحدٍ يحتوي على البيانات الوصفية للملف، لذلك فإن كل هذه البيانات تعتبر جزءا من الملف، مثل الملكية والأذونات وعدد الروابط الصلبة إلى تلك inode ، هذه البيانات لا تختلف باختلاف الروابط الصلبة. السمة الوحيدة التي يمكن أن تكون مختلفة هي اسم الملف فلذلك لا يضمن في inode ، الروابط الصلبة إلى file/inode واحد موجود في نفس الدليل يجب أن يكون لها أسماء مختلفة، نظرا لأنه لا يمكن أن يكون هناك أسماء ملفات مكررة داخل دليل واحد. يتم عرض الروابط الصلبة لملف بالأمر ls -l ، إذا كنت ترغب في عرض أرقام ال inode الفعلية، فإن الأمر ls -li يفعل ذلك. الروابط الرمزية (اللينة) الفرق بين الرابط الصلب والرابط اللين ( والمعروف أيضا باسم الرابط الرمزي أو الرابط التشعبي)، هو أن الروابط الصلبة تشير مباشرة إلى inode ، وأما الروابط اللينة فتشير إلى مدخل الدليل، أي واحدة من الروابط الصلبة. ولأن الروابط اللينة تشير إلى رابط صلب للملف وليس inode فإنها لا تعتمد على رقم inode ، ويمكن أن تعمل عبر أنظمة ملفات مختلفة. الجانب السلبي لهذا هو أنه إذا حذف الرابط الصلب الذي يشير إليه الرابط اللين أو غُيِّر اسمه فإن الرابط الرمزي سوف يتعطل، لحسن الحظ الأمر ls يوضح الروابط المعطلة بالنص الأبيض بخلفية حمراء في قائمة طويلة. مشروع مختبر: تجربة الروابط أعتقد أن أسهل طريقة لفهم استخدام والاختلاف بين الروابط الصلبة واللينة هي مع مشروع المختبر. يجب أن يتم هذا المشروع في دليل فارغ بمستخدم غير جذر . لقد أنشأت الدليل ~/temp لهذا الغرض، ويجب عليك فعل ذلك أيضا. هذا يهيئ مكانا آمنا للقيام بالمشروع ويوفر دليلا جديدا فارغا للعمل فيه بحيث تكون فيه فقط الملفات المرتبطة بهذا المشروع. الإعداد الأولي أولا، أنشئ الدليل المؤقت الذي سوف تؤدي فيه المهام اللازمة لهذا المشروع. تأكد من أن مجلد العمل الحالي (PWD) هو المجلد الرئيسي الخاص بك، ثم أدخل الأمر التالي. mkdir temp ادخل إلى الدليل ~/temp بالأمر cd temp للبدء نحتاج إلى إنشاء ملف يمكننا الربط إليه. الأمر التالي يفعل ذلك ويوفر بعض المحتويات أيضا. du -h > main.file.txt استخدم الأمر ls -l للتحقق من إنشاء الملف بشكل صحيح . يجب أن يكون الإخراج مشابه لنتائجي. لاحظ أن حجم الملف هو 7 بايت فقط، لكن قد يختلف حجم الملف عن بايت أو اثنين. [dboth@david temp]$ ls -l total 4 -rw-rw-r-- 1 dboth dboth 7 Jun 13 07:34 main.file.txt لاحظ الرقم “1” الذي يتبع وضع الملف في القائمة . يمثل هذا العدد عدد الروابط الصلبة الموجودة للملف. في الوقت الحالي، يجب أن تكون 1 لأننا لم ننشئ أي روابط صلبة إضافية لملف الاختبار. تجربة الروابط الصلبة تنشئ الروابطُ الصلبة مدخلَ دليل جديد يشير إلى نفس inode ، لذلك عند إضافة روابط صلبة إلى ملف، سترى زيادة عدد الروابط. تأكد من أنك لا تزال في المجلد ~/temp ثم أنشئ رابطا صلبا إلى الملف main.file.txt ، وقم بعرض القائمة الطويلة بالأمر ls -l : [dboth@david temp]$ ln main.file.txt link1.file.txt [dboth@david temp]$ ls -l total 8 -rw-rw-r-- 2 dboth dboth 7 Jun 13 07:34 link1.file.txt -rw-rw-r-- 2 dboth dboth 7 Jun 13 07:34 main.file.txt لاحظ أن كلا الملفين يحتوي على رابطين، وهما بنفس الحجم والتاريخ. فهو ملف واحد مع inode واحد ورابطين صلبين اثنين. أنشئ رابطا صلبا ثانيا إلى هذا الملف واعرض محتويات المجلد . يمكنك إنشاء رابط إلى أي من الروابط الموجودة link1.file.txt أو main.file.txt [dboth@david temp]$ ln link1.file.txt link2.file.txt ; ls -l total 16 -rw-rw-r-- 3 dboth dboth 7 Jun 13 07:34 link1.file.txt -rw-rw-r-- 3 dboth dboth 7 Jun 13 07:34 link2.file.txt -rw-rw-r-- 3 dboth dboth 7 Jun 13 07:34 main.file.txt لاحظ أن كل رابط صلب جديد في هذا الدليل يجب أن يكون لها اسم مختلف لأنه لا يمكن أن يكون للملفين نفس الاسم داخل نفس الدليل. حاول إنشاء رابط آخر باسم ملف موجود حاليا. [dboth@david temp]$ ln main.file.txt link2.file.txt ln: failed to create hard link 'link2.file.txt': File exists من الواضح أن هذا لن ينجح، لأن link2.file.txt موجود بالفعل. حتى الآن، أنشأنا فقط الروابط الصلبة في نفس الدليل. لذلك، أنشئ رابطا في الدليل الرئيسي الخاص بك، حيث يوجد مجلد المشروع الذي نعمل عليه. [dboth@david temp]$ ln main.file.txt ../main.file.txt ; ls -l ../main* -rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 main.file.txt يظهر الأمر ls في القائمة المذكورة أعلاه أن الملف main.file.txt موجود في الدليل الرئيسي بنفس اسم الملف في الدليل المؤقت . وبطبيعة الحال، هذه ليست ملفات مختلفة. فهي الملف نفسه مع عدة روابط (مداخل الأدلة) إلى نفس Inode . للمساعدة في توضيح النقطة التالية أضف ملفا لا رابطا. [dboth@david temp]$ touch unlinked.file ; ls -l total 12 -rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 link1.file.txt -rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 link2.file.txt -rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 main.file.txt -rw-rw-r-- 1 dboth dboth 0 Jun 14 08:18 unlinked.file انظر في عدد الروابط الصلبة للملف الأول والملف الجديد باستخدام الخيار -i إلى الأمر ls [dboth@david temp]$ ls -li total 12 657024 -rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 link1.file.txt 657024 -rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 link2.file.txt 657024 -rw-rw-r-- 4 dboth dboth 7 Jun 13 07:34 main.file.txt 657863 -rw-rw-r-- 1 dboth dboth 0 Jun 14 08:18 unlinked.file لاحظ الرقم 657024 على يسار وضع الملف في المثال أعلاه. هذا هو رقم Inode، وتشير جميع الروابط الثلاثة إلى Inode نفسه . يمكنك استخدام الخيار -i لعرض رقم Inode للروابط التي أنشأناها في الدليل الرئيسي أيضا، والتي سوف تظهر أيضا نفس القيمة. رقم Inode للملف الذي يحتوي على رابط واحد يختلف عن الروابط الأخرى. لاحظ أن أرقام Inode ستكون مختلفة على النظام الخاص بك. لنقم بتغيير حجم رابط من الروابط الصلبة. [dboth@david temp]$ df -h > link2.file.txt ; ls -li total 12 657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 link1.file.txt 657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 link2.file.txt 657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 main.file.txt 657863 -rw-rw-r-- 1 dboth dboth 0 Jun 14 08:18 unlinked.file حجم الملف سيتغير في جميع الروابط الصلبة وذلك لأن هناك ملفا واحدا يرتبط بمداخل متعددة. أنا أعلم أن التجربة المقبلة سوف تعمل على جهاز الكمبيوتر الخاص بي لأن المجلد /tmp على تقسيم ( partition ) منفصل ، إن كان لك ذلك تأكد أن لديك إمكانية الوصول إلى التقسيم. إذا لم تقم بذلك، يمكنك إدراج إصبع ذاكرة USB وتركيبه. إذا كان أحد هذه الخيارات يناسبك، يمكنك إجراء هذه التجربة. حاول إنشاء رابط إلى أحد الملفات في الدليل ~/temp في /tmp أو في أي مكان حيث نظام الملفات مختلف. [dboth@david temp]$ ln link2.file.txt /tmp/link3.file.txt ln: failed to create hard link '/tmp/link3.file.txt' => 'link2.file.txt': Invalid cross-device link لماذا يحدث هذا الخطأ؟ السبب هو أن كل نظام ملفات منفصل لديه مجموعة خاصة من أرقام Inode ، ببساطة الإشارة إلى ملف من رقم Inode معين عبر كامل أدلة لينكس يمكن أن يؤدي إلى الارتباك، لأن نفس رقم Inode يمكن أن يوجد في كل نظام الملفات المختلفة. ربما تريد تحديد مواقع كل الروابط الصلبة التي تنتمي إلى Inode واحد . يمكنك العثور على رقم Inode باستخدام الأمر ls –li ثم يمكنك استخدام الأمر find لتحديد كافة الروابط المتعلقة برقم Inode هذا. [dboth@david temp]$ find . -inum 657024 ./main.file.txt ./link1.file.txt ./link2.file.txt لاحظ أن الأمر find لم يجد كل الروابط الأربعة إلى هذا Inode لأننا بدأنا في الدليل الحالي من ~/temp . لا يجد الأمر find سوى الملفات في الدليل الحالي. للعثور على جميع الروابط، يمكننا استخدام الأمر التالي الذي يحدد الدليل الرئيسي الخاص بك كمكان للبدء بالبحث. [dboth@david temp]$ find ~ -samefile main.file.txt /home/dboth/temp/main.file.txt /home/dboth/temp/link1.file.txt /home/dboth/temp/link2.file.txt /home/dboth/main.file.txt قد تشاهد رسائل خطأ إذا لم يكن لديك أذونات كمستخدم غير جذر. يستخدم هذا الأمر أيضا الخيار -samefile بدلا من تحديد رقم Inode . هذا يعمل كما لو استخدمت رقم Inode ويمكن أن يكون هذا أسهل إذا كنت تعرف اسم واحد من الروابط الصلبة. تجربة الروابط اللينة (الرمزية) كما رأيت للتو، إنشاء روابط صلبة غير ممكن خارج حدود نظام الملفات. الروابط اللينة هي وسيلة لحل هذه المشكلة، رغم أنها يمكن أن تحقق نفس الغاية، فهي مختلفة جدا، ومعرفة هذه الاختلافات هو المهم. لنبدأ من خلال إنشاء رابط رمزي في مجلد الاختبار ~/temp لبدء الاستكشاف [dboth@david temp]$ ln -s link2.file.txt link3.file.txt ; ls -li total 12 657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 link1.file.txt 657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 link2.file.txt 658270 lrwxrwxrwx 1 dboth dboth 14 Jun 14 15:21 link3.file.txt -> link2.file.txt 657024 -rw-rw-r-- 4 dboth dboth 1157 Jun 14 14:14 main.file.txt 657863 -rw-rw-r-- 1 dboth dboth 0 Jun 14 08:18 unlinked.file الروابط الصلبة -وهي تلك التي تحتوي على رقم Inode 657024 - لم تتغير، وعدد الروابط الصلبة المعروضة لم يتغير أيضا . الروابط الجديدة التي تم إنشاؤها لديها رقم Inode مختلف حيث رقمها658270 . الرابط اللين المسمى link3.file.txt يشير إلى link2.file.txt ، استخدم الأمر cat لعرض محتويات link3.file.txt . معلومات الملف للرابط الرمزي يبدأ بالحرف ” l ” الذي يشير إلى أن هذا الملف هو في الواقع رابط رمزي. حجم الرابط الرمزي link3.file.txt في المثال أعلاه هو 14 بايت فقط. هذا هو حجم النص link3.file.txt -> link2.file.txt” “، وهو المحتوى الفعلي للرابط الرمزي. الرابط الرمزي link3.file.txt لا يشير إلى Inode ، بل يشير إلى مدخل دليل آخر (رابط صلب أو رمزي) ، هذا يجعل من المفيد إنشاء روابط تمتد خارج حدود نظام الملفات . لذلك، دعونا ننشئ هذا الرابط. [dboth@david temp]$ ln -s /home/dboth/temp/link2.file.txt /tmp/link3.file.txt ; ls -l /tmp/link* lrwxrwxrwx 1 dboth dboth 31 Jun 14 21:53 /tmp/link3.file.txt -> /home/dboth/temp/link2.file.txt حذف الروابط هناك بعض الأشياء الأخرى التي يجب عليك مراعاتها عندما تحتاج إلى حذف الروابط أو الملفات التي تشير إليها. أولا، دعونا نحذف الرابط main.file.txt ، تذكر أن كل مدخل دليل يشير إلى Inode هو مجرد رابط صلب. [dboth@david temp]$ rm main.file.txt ; ls -li total 8 657024 -rw-rw-r-- 3 dboth dboth 1157 Jun 14 14:14 link1.file.txt 657024 -rw-rw-r-- 3 dboth dboth 1157 Jun 14 14:14 link2.file.txt 658270 lrwxrwxrwx 1 dboth dboth 14 Jun 14 15:21 link3.file.txt -> link2.file.txt 657863 -rw-rw-r-- 1 dboth dboth 0 Jun 14 08:18 unlinked.file لقد كان الرابط main.file.txt هو الرابط الأول الذي تم إنشاؤه عند إنشاء الملف. حذفه الآن لا يزال يترك الملف الأصلي وبياناته على القرص الصلب مع جميع الروابط الصلبة المتبقية. لحذف الملف وبياناته، سيكون عليك حذف كافة الروابط الصلبة المتبقية. الآن احذف الرابط الصلب link2.file.txt [dboth@david temp]$ rm link2.file.txt ; ls -li total 8 657024 -rw-rw-r-- 3 dboth dboth 1157 Jun 14 14:14 link1.file.txt 658270 lrwxrwxrwx 1 dboth dboth 14 Jun 14 15:21 link3.file.txt -> link2.file.txt 657024 -rw-rw-r-- 3 dboth dboth 1157 Jun 14 14:14 main.file.txt 657863 -rw-rw-r-- 1 dboth dboth 0 Jun 14 08:18 unlinked.file لاحظ ما يحدث للرابط اللين (الرمزي). حذف الرابط الصلب الذي يشير إليه الرابط اللين يتركه معطلا. لإصلاحه يمكنك إنشاء رابط صلب آخر في نفس الدليل بنفس اسم القديم، طالما لم يتم حذف كافة الروابط الصلبة. يمكنك أيضا إعادة إنشاء الرابط بنفس الاسم ولكن بالإشارة إلى واحد من الروابط الصلبة المتبقية. وبطبيعة الحال، إذا لم يعد هناك حاجة إلى رابط لين يمكن حذفها مع الأمر rm يمكن أيضا استخدام الأمر unlink لحذف الملفات والروابط. إنه بسيط جدا وليس لديه خيارات كالأمر rm ، ومع ذلك فإنه يعكس بشكل أكثر دقة العملية الأساسية للحذف، من حيث أنه يزيل الارتباط - مدخل الدليل - عن الملف الذي يتم حذفه. الخلاصة لقد عملت مع كلا النوعين من الروابط لفترة طويلة قبل أن أبدأ في فهم قدراتها وخصوصياتها. استغرق الأمر كتابة مشروع مختبر لفئة لينكس، لقد علمت أخيرا كيف تعمل الروابط. هذه المقالة هي تبسيط ما تعلمت في تلك الفئة، وآمل أن يسرع ذلك التعلم لديك. ترجمة -وبتصرّف- للمقال A user’s guide to links in the Linux filesystem لصاحبه David Both حقوق الصورة البارزة محفوظة لـ Freepik

تظهر لنا الإحصاءات أن أكثر من 80٪ من تطبيقات الويب ومواقع الويب مدعومة بخوادم الويب مفتوحة المصدر. في هذه المقالة، سألقي نظرة على خوادم الويب المفتوحة المصدر الأكثر شعبية، وأراجع تاريخها وتقنياتها وميزاتها وغير ذلك. وسوف أقدم أيضًا بعض النصائح حتى تتمكن من النشر بسهولة على واحد من خوادم الويب هذه بنفسك. وفقًا لويكيبيديا ، فإن خادوم الويب هو "نظام حاسوبي يعمل على معالجة الطلبات عبر بروتوكول HTTP، وهو بروتوكول الشبكة الأساسي المستخدم لتوزيع المعلومات على الشبكة العالمية، ويمكن أن يشير المصطلح إلى النظام بأكمله، أو تحديدًا إلى البرنامج الذي يشرف على الطلبات" ، في هذه المقالة سنتعامل مع البرامج التي تعالج طلبات الويب من المستخدمين النهائيين. Apache HTTP تم إطلاق خادوم Apache HTTP - والذي غالبا ما يشار إليه باسم httpd أو Apache- في عام 1995، واحتُفل بعيد ميلاده العشرين في فبراير 2015. يشغل Apache 52٪ من جميع المواقع على مستوى العالم، وهو خادوم الويب الأكثر شعبية في العالم. يغلب أن يكون Apache مشغلا على لينكس ، ولكن يمكنك أيضا تشغيله على OS X و ويندوز. ليس غريبا أن Apacheمرخص بموجب رخصة Apache الإصدار 2. وهو يستخدم معمارية الوحدات، والتي يمكن بها إضافة وحدات جديدة لتمديد عمل الخادوم وزيادة ميزات أخرى . على سبيل المثال سيؤدي تحميل الوحدة mod_proxy إلى السماح للبروكسي على الخادوم الخاص بك، وسيعمل mod_proxy_balancer على تمكين موازنة التحميل لجميع البروتوكولات المدعومة. اعتبارا من الإصدار 2.4 صار Apache يدعم HTTP/2 من خلال الوحدة الجديدةmod_http2. وبما أن خادوم Apache HTTP هو خادوم الويب الأكثر شعبية منذ عام 1996، فإنه "يستفيد من الوثائق الكبيرة والدعم المتكامل من مشاريع البرامج الأخرى ." يمكنك العثور على مزيد من المعلومات حول Apache في صفحة مشروع. NGINX بدأ Igor Sysoev تطوير NGINX مرة أخرى في عام 2002. وقد طوّر NGINX جوابًا على ما يسمى مشكلة C10K ، وهو اختصار لــ "كيف يمكنك تصميم خادوم الويب الذي يمكنه التعامل مع عشرة آلاف اتصال متزامن ؟ " . NGINX يحل هذا المشكل وهو الثاني على قائمة خوادم الويب المفتوحة المصدر حسب الاستخدام، فهو يشغل ما يزيد عن 30٪ من المواقع. يعتمد NGINX على معمارية الأحداث الموجهة (event-driven) غير المتزامنة ، وذلك ما يساعده في تحقيق هدفه ، ألا وهو التعامل مع أكبر عدد ممكن من الاتصالات ، وبسبب ذلك أصبح خادوم الويب الأكثر شعبية جدًا بين مديري الأنظمة بسبب استخدامه لموارد خفيفة وقدرته على التوسع بسهولة. يتم إصدار NGINX تحت رخصة BSD-like ، ولا يقتصر استخدامه على خدمة الويب فحسب، بل أيضًا كخادوم وكيل proxy أو موازن التحميل load-balancer ، يمكنك العثور على مزيد من المعلومات حول NGINX في موقع المجتمع. Apache Tomcat Apache Tomcat هو حاوية جافا (اسمها الكامل Java servlet) مفتوح المصدر. وهو برنامج جافا بقدرات ملقمات الويب، على الرغم من أن servlet يمكن أن تستجيب لأي أنواع من الطلبات، فإنها استخدامها شائع فقط في تنفيذ التطبيقات المستضافة على خوادم الويب. servlet هي نظير تقنيات الويب الديناميكية الأخرى مثل PHP و ASP.NET، تم التبرع بالشيفرة المصدرية لــ Apache Tomcat من قبل شركة Sun Microsystems إلى مؤسسة Apache للبرمجيات في عام 1999، وأصبحت مشروع Apache الأعلى قيمة في عام 2005. وهي حاليًا تحتل 1٪ فقط من جميع المواقع. يستخدم Apache Tomcat -والذي يصدر تحت رخصة Apache الإصدار 2- عادة لتشغيل تطبيقات الجافا . ومع ذلك، فإنه يمكن تمديده بـ Coyote لأداء دور خادوم الويب العادي لكي يخدم الملفات المحلية كوثائق HTTP ، يمكنك الإطلاع على مزيد من المعلومات على موقع المشروع. غالبًا ما يتم ذكر Apache Tomcat مع خوادم تطبيقات الجافا المفتوحة المصدر الأخرى. مثل JBoss و Wildfly و Glassfish Node.js Node.js هي بيئة جافا سكريبت من جانب الخادوم ، وهي تعمل لتشغيل تطبيقات الشبكة، لا تحتل Node.js إلا مكانة منخفضة في السوق ، فنسبة تشغيلها لا تتجاوز 0.2٪ من المواقع . طور هذه البيئة في الأصل Ryan Dahl في عام 2009 ، وتسيرها الآن مؤسسة Node.js وبمساعدة مؤسسة لينكس. الفرق بين Node.js وغيرها من خوادم الويب الشعبية الأخرى هو أنها بيئة تشغيل عابرة للمنصات لتشغيل تطبيقات الشبكة، تطبّق Node.js معمارية الأحداث الموجهة event-driven القادرة على الإدخال والإخراج غير المتزامن. هذه الخيارات في التصميم هي الأمثل إنتاجية وقابلية للتوسع في تطبيقات الويب مما يسمح بتشغيل الاتصالات وألعاب المتصفح في الوقت الحقيقي، يظهر الفرق أيضًا في أن Node.js هو في الحقيقة جزء من مراحل تطوير الويب (HTML, CSS, and JavaScript)، على عكس Apache أو NGINX التي هي جزء من العديد من البرامج المختلفة. يتم إصدار Node.js تحت مزيج من التراخيص . يمكن الحصول على مزيد من المعلومات على الموقع الإلكتروني للمشروع . Lighttpd أطلق Lighttpd في أول إصدار له في مارس 2003. وهو حاليًا يشغل 0.1٪ من المواقع ويتم توزيعه تحت رخصة BSD. يميز Lighttpd أنه يعمل بموارد أقل مقارنة بالخوادم الأخرى (من حيث الذاكرة ، والمعالج) وهذا يجعله أسرع أداء واستجابة ، وهو يستخدم معمارية الأحداث الموجهة event-driven architecture ، ويعتبر الخيار الأمثل في حال كثرة الاتصالات المتزامنة وموارد أقل من العتاد، يدعم Lighttpd الكثير من التقنيات مثل : FastCGI, SCGI, Auth, Output-compression, URL-rewriting. كثيرًا ما يستعمل Lighttpd مع إطار العمل Ruby on Rails وإطار العمل Catalyst. لمزيد من المعلومات حوله قم بزيارة الصفحة الرئيسية للمشروع . نصائح إذا كنت ترغب أن تجرب واحدا من خوادم الويب الأكثر شعبية فأنا أوصي بشدة بتحميل التجميعية LAMP (Linux, Apache, MySQL, PHP) أو التجميعية LEMP (Linux, NGINX, MySQL, PHP) ، هناك الكثير من هذه التجميعيات المتاحة التي توفير نكهات مختلفة ، وعادة ما يتم توفيرها كمثبتات بنقرة واحدة، أو متوفرة كحزمة في مدير برامجك على لينوكس. بعد الانتهاء بنجاح من عملية التثبيت يمكنك بدء تشغيل خادوم الويب الخاص بك، ومحاولة إخراج المثال المشهور مرحبا بالعالم . انها طريقة رائعة للبدء في اكتشاف مداخل ومخارج خادوم الويب الخاص بك، وكيف تعمل خوادم الويب في الحياة التقنية الحقيقية. ترجمة -وبتصرّف- للمقال Top 5 open source web servers لصاحبه Robin Muilwijk حقوق الصورة البارزة محفوظة لـ Freepik

تنفيذ جدار الحماية هو خطوة هامة في تأمين الخادوم الخاص بك. جزء كبير من عملية التنفيذ هو اتخاذ قرارات بشأن القواعد والسياسات التي تفرض قيودا على حركة مرور البيانات. يسمح لك الجدار الناري أن يكون لك دور في بنية إطار العمل الذي يتم فيه تطبيق القواعد الخاصة بك. في هذا الدليل سوف نبني جدار حماية ليكون أساسا للمزيد من القواعد المعقدة. وسيركز هذا الجدار الناري في المقام الأول على تقديم افتراضات معقولة ووضع إطار سهل التمدد. سيكون تطبيق هذا الدليل على أوبنتو 14.04. المتطلبات الأساسية قبل أن تبدأ يجب أن تكون لك فكرة قاعدية حول سياسات جدار الحماية التي ترغب في تنفيذها. يمكنك اتباع هذا الدليل للحصول على فكرة أفضل عن بعض الأشياء التي يجب أن تنظر فيها. سوف تحتاج إلى أن يكون لك حق الوصول إلى خادوم أوبنتو 14.04 بمستخدم عادٍ يكون له صلاحيات الجذر. تثبيت خدمة جدار الحماية الثابتة لكي نبدأ نحتاج إلى تثبيت الحزمة iptables-persistent إذا لم تكن قد فعلت ذلك من قبل. سيسمح هذا لنا بحفظ مجموعات القواعد ويجعل تنفيذها تلقائيا عند تشغيل النظام: sudo apt-get update sudo apt-get install iptables-persistent أثناء التثبيت سوف تُسأل عما إذا كنت تريد حفظ القواعد الحالية الخاصة بك، أجب بنعم. سوف نقوم بتحرير ملفات القواعد المولدة لاحقا. ملاحظة حول IPv6 قبل أن نبدأ يجب أن نتحدث بإيجاز عن عناوين IPv4 و IPv6. تعالج أوامر iptables فقط المرور عبر IPv4. وأما حركة المرور عبر IPv6 فيتم باستخدام أداة منفصلة تسمى ip6tables. يتم تخزين القواعد في جداول وسلاسل منفصلة. بالنسبة لـ iptables-persistent فتتم كتابة قواعد IPv4 في الملف etc/iptables/rules.v4/ وقواعد IPv6 في الملف etc/iptables/rules.v6/. يفترض هذا المقال أنك لا تستخدم البروتوكول IPv6 على الخادوم الخاص بك. إذا كان الأمر كذلك فالأكثر أمانا هو منع الوصول عبره تماما، وذلك ما سنقوم به في هذه الدليل. تنفيذ السياسات الأساسية لجدار الحماية (الطريق الأسرع) من أجل تنفيذ تلك السياسات على جدار الحماية في أسرع وقت ممكن سوف ندلك على ملف إعدادات يحتوي تلك السياسات، ثم ما عليك بعدُ إلا بالنسخ واللصق. بعد ذلك سوف نشرح الاستراتيجية العامة ونبين لك كيف يمكن تنفيذ هذه القواعد باستخدام أوامر iptables بدلا من تعديل الملف. لتنفيذ سياسات جدار الحماية وإطار العمل الخاص به سوف نقوم بتحرير الملفين etc/iptables/rules.v4/ و etc/iptables/rules.v6/. افتح أولا الملف rules.v4 في محرر النص المفضل لديك بصلاحيات الجذر: sudo nano /etc/iptables/rules.v4 سترى داخل هذا الملف مثل هذه الأسطر: # Generated by iptables-save v1.4.21 on Tue Jul 28 13:29:56 2015 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT # Completed on Tue Jul 28 13:29:56 2015 اُمحُ هذا المحتوى واستبدله بالمحتوى التالي: *filter # Allow all outgoing, but drop incoming and forwarding packets by default :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] # Custom per-protocol chains :UDP - [0:0] :TCP - [0:0] :ICMP - [0:0] # Acceptable UDP traffic # Acceptable TCP traffic -A TCP -p tcp --dport 22 -j ACCEPT # Acceptable ICMP traffic # Boilerplate acceptance policy -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A INPUT -i lo -j ACCEPT # Drop invalid packets -A INPUT -m conntrack --ctstate INVALID -j DROP # Pass traffic to protocol-specific chains ## Only allow new connections (established and related should already be handled) ## For TCP, additionally only allow new SYN packets since that is the only valid ## method for establishing a new TCP connection -A INPUT -p udp -m conntrack --ctstate NEW -j UDP -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP -A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP # Reject anything that's fallen through to this point ## Try to be protocol-specific w/ rejection message -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -j REJECT --reject-with icmp-proto-unreachable # Commit the changes COMMIT *raw :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT *security :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT احفظ ثم أغلق الملف. يمكنك اختبار الملف من أجل اكتشاف الأخطاء التي يمكن أن تكون في التركيب بالأمر التالي: sudo iptables-restore -t /etc/iptables/rules.v4 يجب عليك إصلاح أي خطأ يظهر لك قبل المتابعة. بعد ذلك افتح الملف etc/iptables/rules.v6/ من أجل تعديل قواعد IPv6: sudo nano /etc/iptables/rules.v6 يمكننا أن نمنع كل الحزم التي تستخدم البروتوكول IPv6 باستبدال محتوى الملف بالإعدادات التالية: *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] COMMIT *raw :PREROUTING DROP [0:0] :OUTPUT DROP [0:0] COMMIT *nat :PREROUTING DROP [0:0] :INPUT DROP [0:0] :OUTPUT DROP [0:0] :POSTROUTING DROP [0:0] COMMIT *security :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] COMMIT *mangle :PREROUTING DROP [0:0] :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] :POSTROUTING DROP [0:0] COMMIT احفظ ثم أغلق الملف. من أجل اختبار الملف ومعرفة إن كان فيه أخطاء نستعمل الأمر ip6tables-restore مع الخاصية t-: sudo ip6tables-restore -t /etc/iptables/rules.v6 إذا لم نجد أي خطأ في الملفين السابقين فلْنطبق تلك القواعد بتنفيذ الأمر: sudo service iptables-persistent reload سيقوم هذا الأمر بتنفيذ السياسات التي يتضمنها الملفان فورا. يمكنك التأكد من ذلك بسرد قواعد iptables الحالية بالأمرين: sudo iptables -S sudo ip6tables -S سوف يعاد تطبيق هذه القواعد في كل إقلاعٍ للنظام. تأكد أنه يمكنك الولوج عبر المنفذ 22 وأن كل المنافذ الأخرى محجوبة. شرح لاستراتيجيتنا العامة في الجدار الناري لقد أنشانا في جدار الحماية القاعدي الذي قمنا ببنائه مع القواعد السابقة أنشأنا إطارَ عمل قابلا للتمدد يمكّنك من إضافة قواعد جديدة أو حذفها بسهولة. أما حركة المرور التي تستخدم العنوان IPv4 فقد عالجناها في السلسلة INPUT داخل الجدول filter table ( تعالج هذه السلسلة كل الحزم التي تصل إلى خادومنا) فسمحنا بخروج الحزم من خادومنا ومنعنا إعادة توجيهها -إذ كان ذلك مناسبا فقط في حال كان الخادوم يعمل موجها router لخوادم أخرى- وقبِلنا الحزم على الجداول الأخرى بما أن نظرنا محصور في filter table في هذا الدليل. عموما تقوم القواعد التي طبقناها على الجدار الناري بمنع الحزم من الوصول إلى خادومنا افتراضيا ، سيكون علينا أن نضع استثناءات من أجل الحزم التي نريدها أن لا تدخل في سياسة الحجب. في السلسلة INPUT الرئيسة أضفنا بعض القواعد العامة لحركة المرور التي نثق بها. ما نريده الآن هو حجب كل الحزم التي نعتبرها غير صالحة ونسمح للحزم على واجهة الاسترجاع المحلية local loopback interface والبيانات المرتبطة باتصال مؤسس established connection. بعد ذلك نقوم بمسك البيانات حسب البروتوكول الذي تستخدمه ونمزجها بسلاسل البروتوكول المخصص protocol-specific. تهدف هذه السلاسل إلى التعامل مع القواعد المتعلقة بها والسماح لحركة المرور الصادرة والقادمة إلى الخدمات المعينة. في هذا المثال الخدمة الوحيدة التي قمنا بربطها في سلسلتنا ذات البروتوكول TCP هي SSH. إذا كنا نعرض خدمة أخرى كخادوم (HTTP(S يمكننا إضافة استثناءات لها أيضا. كل حركةٍ للمرور لا تتناسب مع القواعد العامة أو قواعد الخدمات في البروتوكول المحدد protocol-specific سوف تتم معالجتها بالقواعد الموجودة في آخر سلسلة INPUT. لقد جعلنا السياسة الافتراضية للجدار الناري هي الإسقاط DROP، وذلك سيحجب الحزم التي لا تتصف بمعايير السماح حسب قواعدنا. تمنع هذه القواعد في نهاية السلسلة INPUT الحزم وترسل رسالة إلى العميل تحاكي ما يرسله الخادوم في حالِ لم تكن الخدمة متوفرة على ذلك المنفذ. وأما العنوان IPv6 فإن حركة المرور سوف تُحجَب كلها لأن خادومنا لا يستخدمه، ولأنه من الآمن فعل ذلك لكي لا نتورط في حركة المرور بشكل عام. تحديث nameservers (اختياري) يمكن لحركة المرور المحجوبة على العنوان IPv6 أن تتداخل وطريقةُ تعامل الخادوم مع الأشياء في الأنترنت. مثلا يمكن لذلك أن يؤثر في استخدام الأمر APT. إذا ظهر لك خطأ مثل هذا في حال نفذت الأمر apt-get update: Err http://security.ubuntu.com trusty-security InRelease Err http://security.ubuntu.com trusty-security Release.gpg Could not resolve 'security.ubuntu.com' . . . فينبغي عليك أن تتبع هذه الطريقة لكي تجعل APT يعمل مرة أخرى. أولا اضبط nameservers الخاصة بخادومك إلى nameservers الخارجية، سنستخدم في حالتنا nameservers الخاصة بغوغل. افتح الملف etc/network/interfaces/ من أجل تعديله بالأمر: sudo nano /etc/network/interfaces ثم عدل السطر الذي أوله dns-nameservers على الطريقة التالية: . . . iface eth0 inet6 static address 2604:A880:0800:0010:0000:0000:00B2:0001 netmask 64 gateway 2604:A880:0800:0010:0000:0000:0000:0001 autoconf 0 dns-nameservers 8.8.8.8 8.8.4.4 حدّث إعدادات الشبكة بالأمر: sudo ifdown eth0 && sudo ifup eth0 الناتج المتوقع هو: RTNETLINK answers: No such process Waiting for DAD... Done بعد ذلك أنشئ قاعدة جديدة من أجل إرغام حركة المرور أن تستخدم العنوان IPv4 متى كان ذلك ممكنا. أنشئ هذا الملف الجديد: sudo nano /etc/apt/apt.conf.d/99force-ipv4 ثم أضف هذا السطر إليه: Acquire::ForceIPv4 "true"; احفظ ثم أغلق، ينبغي أن تكون الآن قادرا على استخدام ATP. تنفيذ الجدار الناري باستخدام أوامر IPTables لقد تبين لك كيف قمنا بتنفيذ الجدار الناري وسياساته وعرفت كيف تعمل، في المرحلة القادمة سنقوم بتطبيق تلك السياسات باستخدام أوامر iptables وسنحصل في الأخير على ما حصلنا عليه فيما سبق. ولكن سيكون إضافة تلك السياسات واحدة تلو الأخرى لأن iptables يطبق كل قاعدة في وقت تنفيذ الأمر ، لذلك فإن ترتيب القواعد مهم جدا (سوف ندع القواعد التي تحجب إلى النهاية). إعادة ضبط الجدار الناري سنبدأ بإعادة ضبط الجدار الناري لكي نستطيع بناء السياسات من سطر الأوامر . يمكنك إلغاء القواعد السابقة بالأمر: sudo service iptables-persistent flush تأكد أن الجدار الناري أعيد ضبطه بالأمر: sudo iptables -S سترى أن القواعد في الجدول filter table قد اختفت وأن السياسات الافتراضية قد أُعدت للوضع ACCEPT في كل السلاسل: -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT إنشاء سلاسل البروتوكول المخصص سنبدأ بإنشاء سلاسل البروتوكول المخصص protocol-specific. ستُستعمل هذه السلاسل للتحكم في القواعد التي تُنشِئ استثناءات في سياسات الحجب فتجعل خدماتنا ظاهرة في الشبكة. سوف ننشئ واحدة من أجل البروتوكول UDP ، واحدة للبروتوكول TCP وواحدة للبروتوكول ICMP: sudo iptables -N UDP sudo iptables -N TCP sudo iptables -N ICMP يمكننا الذهاب قدما فنضيف استثناء للخدمة SSH التي تستخدم البروتوكول TCP. سيكون ذلك بقبول حركة المرور على المنفذ 22 الخاص بالخدمة SSH: sudo iptables -A TCP -p tcp --dport 22 -j ACCEPT إذا كنت تريد إضافة استثناءات لخدمات أخرى تستخدم البروتوكول TCP فما عليك سوى تكرار الأمر السابق مع تغيير رقم المنفذ الذي تستخدمه الخدمة. إنشاء قواعد للأغراض العامة للحجب والقبول في السلسلة INPUT -حيث تفلتر كل الحزم القادمة- نحتاج إلى إضافة قواعد للأغراض العامة. تشكل تلك القواعد حجر الأساس للجدار الناري وتتبع المنطق السليم إذ تقبل حركة المرور الأقل خطورة (حركة المرور المحلية أو التي تأكدنا من موثوقية مصدرها) وتحجب تلك الموصوفة بأنها غير صالحة. أولا سننشئ استثناء لكي نقبل كل الحزم التي هي جزء من اتصال مؤسَّس established connection أو لها علاقة باتصال مؤسس: sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT تستخدم هذه القاعدة الملحق conntrack الذي يقدم سياقا يحتاج إليه iptables لمعالجة حزم الاتصالات الكبيرة بدل استخدامه للبيانات المنفصلة. TCP هو بروتوكول اتصال ، لذلك فإن كونه اتصالا مؤسَّسا لا غبار عليه. وأما UDP والبروتوكولات عديمة الاتصال فالاتصال المؤسس يشير إلى الحزم التي ترى جوابها (مصدر الحزمة هو نفسه الهدف المقصود والعكس بالعكس ). وأما الاتصالات ذات الصلة فتشير إلى اتصال جديد يُربط مع اتصال مؤسس. المثال الكلاسيكي هنا هو اتصال نقل البيانات ftp، حيث يربط هذا الاتصال الجديد بالاتصال المؤسس سابقا وهو FTP control connection. نريد أيضا أن نسمح لحركة المرور التي نشأت على واجهة الاسترجاع المحلية local loopback interface. هذه الحزم وُلّدت من قبل الخادوم ومتجهة إلى الخادوم نفسه. يتم استخدامها من قبل الخدمات على جهاز النظام للتواصل مع بعضها البعض: sudo iptables -A INPUT -i lo -j ACCEPT وأخيرا نريد حجب كل الحزم غير الصالحة. تكون الحزم غير صالحة للعديد من الأسباب. منها التي تكون وجهتها اتصالات أو عناوين أو منافذ غير موجودة، أو ببساطة لم يَحسُن تهيئتها. في كل الأحوال سوف نمنع أمثال هذه الحزم لأنه لا سبيل إلى معالجتها أو لأنها مغلفة لشيفرات خبيثة: sudo iptables -A INPUT -m conntrack --ctstate INVALID -j DROP إنشاء الانتقال السريع إلى سلاسل البروتوكول المخصص حتى الآن لقد أنشأنا بعض القواعد العامة في سلسلة INPUT وبعض القواعد للخدمات المقبولة في سلاسل البروتوكول المخصص. ومع ذلك فالبيانات القادمة إلى السلسلة INPUT ليس لديها وسيلة للوصول إلى تلك السلاسل. نحن بحاجة إلى توجيه حركة البيانات في سلسلة INPUT إلى سلاسل البروتوكول المخصص التي تناسبها. يمكننا البحث عن نوع البروتوكول لكي نعرف أي سلسلة تناسب هذه الحزمة. ويجب التأكد من أن الحزمة تمثل اتصالا جديدا (يفترض أنه تم بالفعل التعامل مع أي اتصال مؤسس أو له علاقة به). بالنسبة لحزم TCP سوف نقوم بإضافة شرط إضافي وهو أن تكون الحزمة SYN، والذي هو النوع الوحيد الصالح لبدء اتصال TCP: sudo iptables -A INPUT -p udp -m conntrack --ctstate NEW -j UDP sudo iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP sudo iptables -A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP رفض كل حركة المرور الأخرى إذا كانت الحزمة التي تم تمريرها الى سلسلة البروتوكول المخصص لم تعثر على أية قواعد فسيتم إعادة التحكم بها إلى السلسة INPUT. ما يصل إلى هذا النقطة ينبغي أن لا يسمح به جدار الحماية. سوف نحجب حركة المرور باستخدام الهدف REJECT الذي يرسل رسالة رد إلى العميل. و يتيح هذا لنا تحديد الرسائل الصادرة حتى نتمكن من محاكاة الرد كما لو كان العميل حاول إرسال الحزم إلى المنافذ المغلقة. يكون الرد حسب البروتوكول الذي يتم استخدامه من قبل العميل. محاولة الوصول إلى منفذ UDP المغلق يؤدي إلى رسالة ICMP مضمونها "لا يمكن الوصول إلى المنفذ” ، يمكننا محاكاة ذلك بتنفيذ الأمر: sudo iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable محاولة إنشاء اتصال TCP على منفذ مغلق سيؤدي إلى جواب TCP RST: sudo iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset وأما جميع الحزم الأخرى فيمكننا إرسال رسالة ICMP "تعذر الوصول إلى البروتوكول" للإشارة إلى أن الخادوم لا يرد على حزم من هذا النوع: sudo iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable ضبط السياسات الافتراضية آخر ثلاث قواعد أضفناها ينبغي أن تتعامل مع جميع ما تبقى من حركة البيانات في السلسلة INPUT. ومع ذلك ينبغي لنا أن ننشئ السياسات الافتراضية للإسقاطـ DROP كإجراء احترازي. وينبغي أيضا أن تُحدد هذه السياسة في سلسلة FORWARD إذا لم يتم استخدام هذا الخادوم جهازَ توجيه إلى أجهرة أخرى: sudo iptables -P INPUT DROP sudo iptables -P FORWARD DROP تحذير مع إعدادك لسياسات الجدار الناري إلى DROP يكون استعمالك للأمر sudo iptables -F لغرض مسح iptables مسقطا لاتصال SSH الحالي ، الأحسن من ذلك أن تقوم بمسحه بالأمر sudo iptables-persistent flush، لأن ذلك سيعيد ضبط الجدار النار إلى الحال الفتراضي. ولكى نجعل سياسة IPv6 هي إسقاط كل حركةٍ للمرور يمكننا تنفيذ الأوامر التالية: sudo ip6tables -P INPUT DROP sudo ip6tables -P FORWARD DROP sudo ip6tables -P OUTPUT DROP ينبغي لهذه الأوامر أن تكرر القواعد التي أعددناها سابقا بشكل موثوق. حفظ قواعد IPTables في هذه المرحلة يجب فحص قواعد جدار الحماية للتأكد من أنها تمنع حركة المرور التي تريد منعها وتسمح لما تريد السماح له. عندما تكون متأكدا من أن الجدار الناري والقواعد يعملان بشكل صحيح يمكنك حفظ تلك القواعد ليتم تطبيقها عند كل إقلاع للنظام. يمكنك حفظ قواعد كل من IPv4 و IPv6 بتنفيذ الأمر: sudo service iptables-persistent save سيقوم هذا الأمر بالكاتبة فوق الملفين etc/iptables/rules.v4/ و etc/iptables/rules.v6/ بالسياسات التي نفذتها من خلال سطر الأوامر. الخلاصة باتباعك هذا الدليل -سواء من خلال وضع قواعد جدار الحماية مباشرة في ملفات الإعدادات أو يدويا باستخدام سطر الأوامر - قمتَ بإنشاء منطلق جيد لإعدادات الجدار الناري. يبقى عليك أن تضيف قواعد خاصة بك لتسمح بالوصول إلى خدماتك الأخرى على الخادوم. يسمح لك إطار العمل الذي أسسناه في هذا الدليل بأن تعدل كيفما تشاء ، وأيضا يجعل السياسات الموجودة أكثر وضوحا. ترجمة -وبتصرّف- للمقال How To Implement a Basic Firewall Template with Iptables on Ubuntu 14.04 لصاحبه Justin Ellingwood.

HHVM هي آلة افتراضية مفتوحة المصدر لتنفيذ الشيفرة المكتوبة بلغتي PHP وHACK. تُطور HHVM وتدعمها فيس بوك، الأمر الذي لفت الانتباه إليها كثيرا في الآونة الأخيرة. تختلف HHVM عن باقي محركات PHP لأنها تتبع منهج "الترجمة فقط في الوقت المناسب" JIT. HHVM تترجم الشيفرة PHP إلى شيفرة ثنائية وسيطة intermediate byte code ثم بعد ذلك إلى شيفرة بلغة الآلة x64 machine instructions قبيل وقت التنفيذ، هذا الأمر يسمح بكثير من التحسين وسرعة في الأداء مقارنة بالطرق التي تتبعها محركات PHP الأخرى. HHVM قوية وسريعة ، ولكنها -مقارنة بمحركات PHP الأخرى- تتطلب موارد أكثر من ذاكرة الوصول العشوائي RAM والمعالج CPU، مثلها مثل الآلات الافتراضية الأخرى (JVM مثلا). في هذه المقالة سوف نبين لك كيف تثبت HHVM وتدمجه مع Nginx. المتطلبات الأساسيةقد تم اختبار هذا الدرس على أوبنتو 14.04 . طريقة التثبيت الموصوفة في هذه المقالة والإعدادات المشروحة فيها ستكون هي نفسها في كل أنظمة التشغيل إلا بعض الأوامر ومسارات ملفات الإعداد. من أجل إتمام هذا الدرس وتطبيقه لا بد لك من الأمور التالية: نظام أوبنتو 14.04 مع ذاكرة وصول عشوائي RAM لا تقل عن 1 جيجا.مستخدم عادي له صلاحيات sudo.خادوم Nginx مثبت على النظام.كل الأوامر في هذا الدرس ينبغي أن تنفذ بصلاحيات المستخدم العادي، وفي حال كانت صلاحيات الجذر مطلوبة فسيُسبق الأمر بالكلمة sudo . في حال استخدمت أوبنتو 14.04 فإن له مستودعا رسميا يدعم HHVM، ومن أجل إضافة هذا المستودع يجب عليك استيراد المفتاح العام GnuPG بالأمر التالي: sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0x5a16e7281be7a449بعد هذا يمكنك تثبيت مستودع HHVM بكل أمان بالأمر التالي: sudo add-apt-repository "deb http://dl.hhvm.com/ubuntu $(lsb_release -sc) main"بعد إضافة المستودع يجب عليك تحديث قاعدة بيانات الحزم حتى تنضاف إليها حزم المستودع الجديد وذلك يكون بالأمر التالي: sudo apt-get updateوأخيرا يمكنك تثبيت HHVM بالأمر التالي: sudo apt-get install hhvmالأمر السابق يقوم بتثبيت HHVM وتشغيلها في الوقت نفسه ، ولكي نجعل التشغيل تلقائيا مع تشغيل النظام فلابد لنا من تنفيذ الأمر: sudo update-rc.d hhvm defaultsالإعداداتيأتي مع HHVM سكريبت يجعل دمجها مع خادوم Nginx أسهل. ونحن نفترض أنك ثبتّ خادوم Nginx بالطريقة الافتراضية، وعليه يمكنك تنفيذ السكريبت من غير أي مدخلات بالأمر التالي: sudo /usr/share/hhvm/install_fastcgi.shعند تنفيذ هذا السكريبت يقوم بإضافة ملف الإعدادات etc/nginx/hhvm.conf/ إلى الملف الافتراضي لإعدادات Nginx server block ألا وهو الملف etc/nginx/sites-enabled/default/، هذا السكربت يعمل فقط مع الإعدادت الإفتراضية لخادوم Nginx بدون أي تغييرات في FastCGI. إذا كنت قد غير في إعدادات Nginx server block وإعدادات FastCGI كما هو الشأن في PHP-FPM فيجب عليك استبدال الإعدادات الجديدة بالقديمة يدويا وذلك بالتعديل على الملف etc/nginx/sites-enabled/default/: location ~ \.(hh|php)$ { fastcgi_keep_conn on; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }تعني الأسطر السابقة أنه على Nginx أن يعالج أي ملف مطلوب ينتهي باللاحقة php. أو hh. الخاصة بلغة hack، ويجب عليك بعدئذ إعادة تشغيل الخادوم Nginx من أجل تفعيل التغييرات: sudo service nginx restartوأيضا يفترض هذا السكريبت أنك لم تغير إعدادات HHVM التي تجعل الخدمة قابلة للوصول إليها عبر العنوان 127.0.0.1:9000، هذه الإعدادات تأتي افتراضيا في الملف etc/hhvm/server.ini/ الذي محتواه: ; php options pid = /var/run/hhvm/pid ; hhvm specific hhvm.server.port = 9000 hhvm.server.type = fastcgi hhvm.server.default_document = index.php hhvm.log.use_log_file = true hhvm.log.file = /var/log/hhvm/error.log hhvm.repo.central.path = /var/run/hhvm/hhvm.hhbcولعلك لاحظت في هذه الإعدادات لـ HHVM المتغير hhvm.server.port الذي يحدد أن هذه HHVM سوف تستمع على منفذ البروتوكول TCP 9000، وعلى الهوست المحلي localhost ما لم يتم تغيير ذلك. يفترض ب HHVM أن تعمل في بيئات ذات عبء ثقيل ، لذلك فإن التغيير الأول الذي ينبغي عليك فعله هو تغيير طريقة الاستماع من المنفذ TCP إلى المقبس socket ، هذا سيستهلك موارد أقل من الذاكرة العشوائية والمعالج في حال التواصل بين الخادوم Nginx والآلة الافتراضية HHVM. لكي تغير تلك الإعدادات افتح الملف etc/hhvm/server.ini/ بأي محرر نصوص مفضل لديك مثل vim : sudo vim /etc/hhvm/server.ini ثم احذف السطر الذي يبدأ بـ hhvm.server.port، وضع في مكانه السطر التالي: hhvm.server.file_socket=/var/run/hhvm/hhvm.sockاحفظ الإعدادات ثم أعد تشغيل HHVM بالأمر: sudo service hhvm restartبعد ذلك يجب عليك أن تجعل الخادوم Nginx يأخذ بعين الاعتبار التغييرات السابقة وذلك بتعديل الملف etc/nginx/hhvm.conf/: sudo vim /etc/nginx/hhvm.confفي هذا الملف تأكد أن الموجه fastcgi_pass يشير إلى مقبس HHVM وأنه يظهر بالشكل التالي: fastcgi_pass unix:/var/run/hhvm/hhvm.sock;ثم بعد ذلك يجب عليك أن تعيد تشغيل الخادوم Nginx حتى يتم تفعيل تلك التغييرات ، من أجل ذلك نفذ الأمر: sudo service nginx restartيمكن للسكريبت usr/share/hhvm/install_fastcgi.sh/ أن يوفر عليك بعض الوقت، ولكن هناك أشياء لابد عليك من فعلها بنفسك لا سيما فيما يخص Nginx server blocks ، مثال على ذلك أن الإعدادات الافتراضية لـ Nginx server blocks إذا طلب منه صفحة index فإنه يفتح فقط الملفين index.html و index.htm عندما يكون سرد المجلدات ممنوعا، هذا أحد الأشياء التي يجب عليك تغييرها لكي يضاف index.php إلى الملفات التي يفتحها الخادوم عند طلب index. لفعل ذلك افتح ملفات إعدادات server block بمحررك المفضل: sudo vim /etc/nginx/sites-enabled/defaultثم اذهب إلى الجزء المخصص للخادوم ثم أضف index.php حيث يوجد ملفات index ، سيظهر ذلك الجزء بالشكل التالي: index index.html index.htm index.php;مرة اخرى أعد تشغيل خادوم Nginx ليتم تفعيل هذه الإعدادات: sudo service nginx restartاختبار وتعديل HHVMأول اختبار يمكنه أداؤه هو بواجهة أوامر PHP (cli) /usr/bin/php التي تشير إلى etc/alternatives/php/، والتي هي أيضا تشير إلى الملف التنفيذي usr/bin/hhvm/ الخاص بـ HHVM، نفذ الأمر: /usr/bin/php --versionعندما تنفذ هذا الأمر فإنه ينبغي أن ترى رقم إصدار HHVM ومعلومات أخرى كهذا: HipHop VM 3.8.1 (rel) Compiler: tags/HHVM-3.8.1-0-g3006bc45691762b5409fc3a510a43093968e9660 Repo schema: 253b3802ce1bcd19e378634342fc9c245ac76c33إذا كنت قد ثبتّ PHP من قبل فربما ظهر لك معلومات النسخة القديمة من PHP، من أجل تغيير ذلك وجعله يشير إلى HHVM نفذ هذا الأمر: sudo /usr/bin/update-alternatives --install /usr/bin/php php /usr/bin/hhvm 60بعد ذلك يمكنك استعمال الدالة ()phpinfo من أجل إظهار إعدادات وخواص الـ HHVM، لفعل ذلك أنشئ ملفا اسمه info.php في المجلد الافتراضي لخادوم الويب Nginx والذي هو usr/share/nginx/html/ باستخدام محررك المفضل: sudo vim /usr/share/nginx/html/info.phpثم أضف فيه الأسطر التالية: <?php phpinfo(); ?>إنه من المنصوح به لدى الخبراء أن تجعل كل ملفات الويب التي يشغلها الخادوم Nginx مملوكة للمستخدم الخاص به www-data. قم بعمل ذلك بالأمر التالي: sudo chown www-data: /usr/share/nginx/html/info.phpالآن جرب الدخول إلى هذا الملف الذي أنشأته عبر هذا الرابط: http://your_server_ip/info.php. يجب عليك استبدال your_server_ip بـ IP خادومك، والنتيجة ستكون في متصفحك هكذا: إذا لم يظهر لك مثل هذه الصورة فتأكد أنك اتبعت الخطوات السابقة بطريقة صحيحة ، ثم تفقد ملف أخطاء الخادوم Nginx الذي مساره var/log/nginx/error.log/ وملف HHVM الذي مساره var/log/hhvm/error.log/. ارجع الآن إلى متصفحك وأعد النظر تر أن هذه البيانات التي أظهرتها الدالة ()phpinfo هي نفسها التي تظهر مع محركات PHP الأخرى غير أن كل المتغيرات كانت مسبوقة بـ hhvm. عند استكشاف المتغيرات ستلحظ أن الحد الأقصى للذاكرة المسموحة هو 17179869184 بايت أي ما يقارب 17 غيغابايت، وهذا بالتأكيد سوف يقتل النظام إذا كان لا يملك سوى القليل من ذاكرة الوصول العشوائي ويجعلها لا تستجيب، لذلك يجب عليك أن تخفض ذلك الحد إلى قيمة هي أقل من سعة الذاكرة العشوائية لكي نضمن أن أي خدمة أخرى لن تتأثر بنقص في موارد النظام. كمثال عام، إذا كان نظامك يملك ذاكرة بسعة 2 جيغا فإنه ينبغي عليك تخفيض الحد الأقصى لـ HHVM إلى ما يقارب 1.2 جيغا. لفعل ذلك عدّل الملف etc/hhvm/php.ini/ بمحررك المفضل: sudo vim /etc/hhvm/php.iniثم أضف المتغير الجديد بعد القسم ; php options memory_limit = 1200Mبالطريقة نفسها يمكنك تغيير أي شيء تريده في إعدادات PHP ، فقط تأكد دائما أن تعيد تشغيل HHVM بعد انتهائك من التغييرات بالأمر: sudo service hhvm restartبعد كل ذلك يمكنك إجراء اختبار أكثر تعقيدا مع تطبيق ويب مشهور. من المهم أن تعرف أن HHVM ليس متوافقا مائة بالمائة مع PHP المعتاد ولا مع جميع أطر PHP الأكثر الشعبية. وقد أظهرت اختباراتنا خلال وقت كتابة هذا المقال أن العديد من تطبيقات PHP على شبكة الإنترنت مثل ووردبريس تعمل بشكل جيد. ومع ذلك فإن أطر العمل المدعومة محدودة العدد. عندما تقوم بالاختبار مع تطبيق ويب حقيقي فإنه لا شيء يخص HHVM يجب فعله، التثبيت والإعدادات هي نفسها كما هو الشأن في LEMP القياسية، وذلك لأن HHVM تأتي مجمعة بوحدات PHP القياسية ، وذلك يجعلها أكثر توافقية مع تطبيقات وأطر PHP. مع ذلك وفي بعض الحالات النادرة قد تحتاج لتثبيت وحدة إضافية لـ HHVM. على سبيل المثال إذا كنت تستخدم PostgreSQL بمثابة خادوم قاعدة البيانات فسوف تحتاج إلى وحدة pgsql. في مثل هذه الحالات راجع الوثائق الرسمية لـ HHVM. الخلاصةكما رأيت في هذا المقال فإن HHVM سهلٌ تثبيتها سهل إعدادها سهل دمجها مع خادوم الويب Nginx. فإن كان لديك ما يكفي من الموارد فينبغي أن تجربها ثم ترى كيف يعمل منهج JIT الذي تتبعه HHVM من حيث الأداء والاستقرار. لابد من سبب وجيه لموقع مثل فايس بوك بوظائفه المعقدة وحركة بيانات لا مثيل لها أن تثق به. وأما المواقع الصغيرة التي لها حركة بيانات أقل فأولى لها أن تختار حلولا أقل استهلاكا للذاكرة مثل PHP-FPM، فإنه بالتأكيد أفضل خيار. مقال مترجم من How To Install HHVM with Nginx on Ubuntu 14.04 للكاتب Anatoliy Dimitrov.