لوحة المتصدرين

يزداد نمو المواقع يومًا بعد يوم، ومنه إلى ازديار في نسبة مرور البيانات (traffic)، الأمر الّذي من شأنه أن يزيد من الضغط على قواعد البيانات، وباعتبار أنّ قواعد البيانات هي عنق الزجاجة لأداء أي موقع، فعليه يجب أنّ يتمّ إعدادها بشكل مُناسب لِتتولّى الضغط العالي بشكل يُلائم مُتطلّبات العمل.يُمكن اعتبار تقنيّة memcached أحد الطّرق العمليّة في رفع معدّل تخبئة الكائنات في ذاكرة النظام، فهي نظام يعمل على تخزين البيانات وبشكلٍ مؤقّت في الذّاكرة على أن يتمّ استدعائها من الذّاكرة بدلًا من قاعدة البيانات، بحيث تكون هذه البيانات جاهزةً إلى الطلب التّالي ومن الذّاكرة، الأمر الّذي يزيد من سرعة الاستجابة وبشكلٍ ملحوظ. سيتناول هذا الشرح كيفيّة تنصيب وإعداد الذّاكرة المُخبّئة على الخادوم Ubuntu 14.04، ومناقشة ما يلزم من تفاصيل. مُتطلّبات العملقبل بدء العمل، يجب توفّر مُستخدِم ذو صلاحيات وصول عالية، لتطبيق مُحتويات هذه الدليل. تنصيب Memcached وباقي المُقَوِّمات المطلوبةيُمكن تنصيب كافة المُقَوِّمات (components) اللازمة لبدأ العمل من مستودعات أبونتو حيثُ أنّه يوفّرها جميعها. سيتمّ أولًا تحديث الحزم المحلّيّة، ومن ثمّ تنصيب باقي البرامج سيتمّ تنصيب memcached، بالإضافة إلى قواعد البيانات MySQL، ولغة PHP لتتولّى عمليّة الوساطة مع قواعد البيانات، وكما سيتمّ الحاجة إلى تنصيب تَوْسِعَة/إضافة (extension) للغة PHP لِتتولّى عمليّة الربط مع الذّاكرة المُخبّئة (memcached): sudo apt-get update sudo apt-get install mysql-server php5-mysql php5 php5-memcached memcachedيجب الانتباه هنا إلى توفّر توسعتان من الذّاكرة المخبّئة الخاصّة بلغة PHP، تحمل الأولى الاسم php5-memcache، وتحميل الثّانية الاسم php5-memcached، -حرف “d” الإضافي في الثّانية-سيتمّ الاعتماد على الإضافة الثّانية في هذا الشرح بسبب استقرارها، وتقديمها إلى مساحة أكبر من الخيارات والمزايا. إنّ لم تكن قواعد البيانات منصّبة من قبل، فإن المُنصب سيَطلب اختيار وتأكيد كلمة مرور حساب المُدير. ويكون بهذا قد تمّ تنصيب ما سيتمّ الحاجة له خلال الشرح. اختبار تنصيب الذّاكرة المُخبّئةقد يبدو الأمر صعب التصديق، ولكن بهذا الإعداد البسيط فإن الذّاكرة المُخبئة أصبحت جاهزة للعمل، ويُمكن اختبارها بطرقٍ عدّة. تُعتبر الطريقة الأولى سهلة إلى حدٍّ ما، حيث من المُمكن فقط سؤال PHP إن كانت تعلم حول تَوْسِعَة memcached، وفيما إذا كانت مُفعّلة أو لا، وذلك عبر إنشاء صفحة PHP info المعروفة. سيتمّ إنشاء ملف بالاسم info.php في المسار الجذر لخادوم الوب، والّذي سيكون /var/www/html على اعتبار أنّ خادوم الوب هو Apache: sudo nano /var/www/html/info.phpسيتمّ كتابة السطور التّالية في هذا الملفّ، والّتي من شأنها استدعاء دالّة (PHP function)، والّتي من شأنها أنّ تجمع وتطبع معلومات حول الخادوم بصفحة ويب مُنسقة بشكل مقروء ومُبسّط. <?php phpinfo(); ?>يُمكن الآن زيارة خادوم الوب متبوعًا بـ /info.php، وبعد التدرّج في الصفحة إلى القسم الخاص بـ “memcached”، سيكون هناك معلومات مُشابهة إلى التّالي: http://server_domain_name_or_IP/info.php تشير المعلومات السابقة إلى أنّ تَوْسِعَة memcached مُفعّلة، وقد تمّ ربطها مع خادوم الوب. يُمكن أيضًا اختبار فيما إذا كانت خدمة memcached تعمل عن طريقة ترشيح العمليات الحاليّة باستخدام الأداة grep: ps aux | grep memcachedيعرض الأمر السابق معلومات على الشكل التّالي: memcache 6584 0.0 0.0 327448 3004 ? Sl 14:07 0:00 /usr/bin/memcached -m 64 -p 11211 -u memcache -l 127.0.0.1 demouser 6636 0.0 0.0 11744 904 pts/0 S+ 14:29 0:00 grep --color=auto memcachedوكما هو الأمر دائمًا مع خدمات أنظمة لينكس فيمكن إيقاف، تشغيل، أو إعادة تشغيل أي خدمة، فالإعادة تشغيل خدمة memcached يُمكن تنفيذ الأمر التّالي: sudo service memcached restartاختبار الذّاكرة المُخبّئةبعد أن تمّ التأكّد من عمل الذّاكرة المُخبّئة، وأن تَوْسِعَة PHP مُتصلة بها ومُفعّلة، فمن المُمكن تجربة استخدامها في تخبئة/تخزين بعض البيانات. سيتمّ كتابة شيفرة/سكريبت PHP آخر لذلك، وسيكون أكثر تعقيدًا من سابقه: sudo nano /var/www/html/cache_test.phpسيتمّ تغليف الشيفرة بوسم PHP: <?php ?>سيتمّ إنشاء حالة/نموذج (instance) من كائن Memcached، وتخزينه في مُتغيّر، ومن ثُمّ سيتمّ تعريف المَوضع الّذي يُمكّن هذا الكائن من الاتصال بخدمة memcache، والّتي تعمل على المنقذ 11211 بالإعداد الافتراضيّ. <?php $mem = new Memcached(); $mem->addServer("127.0.0.1", 11211); ?>سيتمّ في الخطوة التّالية إخبار حالة Memcached، المُنشئة في الخطوة السابقة، بالاستعلام (query) عن مفتاح (key) من *التخبئة (cache)، يُمكن أنّ يكون اسم المُفتاح اعتباطيًا باعتبار أنّه لم ينشئ بعد، وليكن “test”، وستُخزّن نتيجة هذا الطلب في المتغيّر $result: <?php $mem = new Memcached(); $mem->addServer("127.0.0.1", 11211); $result = $mem->get("test"); ?>سيتمّ في الخطوة التّالية اختبار فيما إذا تمّ الحصول على أي عائد: فلو وجدت memcached مفتاحًا بالاسم “test”، سيتمّ طباعته مع قيمته.أما لو لم تجد مفتاحًا مُطابقًا، سيتمّ طباعة رسالة تُشير إلى ذلك.يجب بعد ذلك تعيين قيمة للمفتاح، ليكون حاضرًا عند السؤال عن البيانات/القيمة في المرّة القادمة، ستجد memcached البيانات/القيمة المُعيّنة له. <?php $mem = new Memcached(); $mem->addServer("127.0.0.1", 11211); $result = $mem->get("blah"); if ($result) { echo $result; } else { echo "No matching key found. I will add that now"; $mem->set("blah", "I am data! I am held in memcached") or die("Couldn't save anything to memcached..."); } ?>أصبحت الشيفرة/السكريبت جاهزةً في هذه المرحلة، وبزيارة الصّفحة باستخدام المُتصفّح، سيتمّ رؤية التّالي: http://server_domain_name_or_IP/cache_test.phpستظهر النتيجة على الشكل التّالي في الزيارة الأولى، والّتي تُشير إلى عدم وجود مُفتاح مُطابق، على أنّ تتم إضافته إلى حين الطلب اللّاحق: وستكون النتيجة على الشكل التّالي في الزيارة التّالية: يُوضّح المثال السابق، كيف استطاعت خدمة memcached على تخبئة المعلومات المُعيّنة كما هو مُبرمجٌ لها أن تفعل. اختبار تخبئة قيم قواعد البيانات بشكل مؤقّت (Caching Database Values)أصبح الآن من المُمكن تخزين البيانات في الذّاكرة المُخبئة، ومن المُمكن توضيح المزيد من الأمثلة الواقعيّة، وذلك بالتّطرّق إلى تخبئة النتائج المُستعلمة من قواعد البيانات بشكل مؤقّت في الذّاكرة. إنشاء عيّنة بيانات في MySQLسيتمّ إعداد قواعد البيانات بشكلٍ مُلائم أولًا، وذلك قبل أنّ يتمّ إنشاء هذه العيّنة سيتمّ الاتصال بقواعد البيانات كمُستخدِم مُدير مع إدخال كلمة المرور المُعيّنة خلال تنصيب MySQL، ليتمّ استحضار موجّه الأوامر الخاصّ بـ MySQL: mysql -u root -pسيتمّ إنشاء قاعدة بيانات ليتمّ الاختبار عليها، وبعد ذلك البدء في استخدامها: CREATE DATABASE mem_test; USE mem_test;سيتمّ إنشاء مُستخدِم بالاسم “test”، وبكلمة مرور “testing”، وبصلاحيات وصول إلى القاعدة الّتي تمّ إنشاؤها: GRANT ALL ON mem_test.* TO test@localhost IDENTIFIED BY 'testing123';سيتمّ بعد ذلك إنشاء جدول يحتوي على سجل وحيد، سيحمل الجدول الاسم “sample_data”، مُحتويًا على عمودان، نصيّ وعددي. CREATE TABLE sample_data (id int, name varchar(30)); INSERT INTO sample_data VALUES (1, "some_data");تمّ بذلك إنشاء بنية قاعدة البيانات اللازمة، وأصبح بالإمكان الخروج من موجّه الأوامر الخاصّ بـ MySQL: exitكتابة شيفرة PHP لتخبئة بيانات MySQLأصبح من المُمكن كتابة شيفرة تُحاكي بيئة عمل تطبيق حقيقي في البيئة الحيّة، وذلك بعد أنّ أصبحت قواعد البيانات مجهّزة بشكل مُناسب. ستقوم الشيفرة بالبحث عن البيانات في الذّاكرة المُخبّئة والعودة بالبيانات المُتوفّرة، ولكن عند عدم إيجاد أي بيانات، سيتمّ الاستعلام من قواعد البيانات نفسها، ومن ثمّ تخزين النتائج في الذّاكرة المخبّئة من أجل الاستعلامات المُستقبليّة. سيتمّ كتابة الشيفرة في المسار الجذر الخاصّ بخادوم الوب، وسيحمل الملفّ الّذي يحتوي هذه الشيفرة الاسم database_test.php: sudo nano /var/www/html/database_test.phpستبدأ سُطور الشيفرة بشكل مُشابه إلى الشيفرة السابقة، وذلك بإنشاء حالة وإخبارها بمكان خدمة memcached على الخادوم، كما تمّ الأمر في المثال السابق: <?php $mem = new Memcached(); $mem->addServer("127.0.0.1", 11211); ?>ستكون الخطوة التّالية هي تحديد كيف لـ PHP الاتصال بقواعد بيانات MySQL، وذلك بتمرير بيانات الاعتماد/الدخول الخاصّة بالمُستخدِم المُنشئ سابقًا، ومن ثُمّ تحديد أيًا من قواعد البيانات يجب استخدامها: <?php $mem = new Memcached(); $mem->addServer("127.0.0.1", 11211); mysql_connect("localhost", "test", "testing123") or die(mysql_error()); mysql_select_db("mem_test") or die(mysql_error()); ?>سيتوجّب في الخطوة التّالية بناء الاستعلام، الّذي وظيفته جلب البيانات الموجودة في جدول قاعدة البيانات، وتخزينه في المُتغيّر $query. سيتمّ بعد ذلك إنشاء مُتغيّر $querykey ليخزّن المفتاح الذي ستستخدمه memcached لاسترجاع المعلومات سيتمّ بناء هذا المُفتاح بالجمع بين الكلمة “KEY”، وبعثرة (hashing) من نوع md5، ويضمن ذلك أن كلَّ مُفتاح هو مُفتاح فريد عن الآخر، فعندما يتمّ استخدام هذا الأسلوب مع مجموعة كبيرة من البيانات، وليس كما هو حال هذا المثال المُبسّط، سيضمن ذلك أن أي استعلام مُماثل سيُنتج نفس المُفتاح للطلبات المُستقبليّة. <?php $mem = new Memcached(); $mem->addServer("127.0.0.1", 11211); mysql_connect("localhost", "test", "testing123") or die(mysql_error()); mysql_select_db("mem_test") or die(mysql_error()); $query = "SELECT ID FROM sample_data WHERE name = 'some_data'"; $querykey = "KEY" . md5($query); ?>سيتمّ في الخطوة التّالية إنشاء المُتغيّر querykey، ليتمّ تعيينه إلى المُتغيّر $result في حال توفّره. <?php $mem = new Memcached(); $mem->addServer("127.0.0.1", 11211); mysql_connect("localhost", "test", "testing123") or die(mysql_error()); mysql_select_db("mem_test") or die(mysql_error()); $query = "SELECT name FROM sample_data WHERE id = 1"; $querykey = "KEY" . md5($query); $result = $mem->get($querykey); ?>سيتمّ عمل اختبار منطقي (جملة شرطيّة)، والّذي من شأنه أن يُحدّد ماذا سيحدث عند وجود نتائج (جواب الشرط true) في الذّاكرة المُخبّئة، وفي حال ذلك سيتمّ طباعة البيانات المسحوبة، وإخبار المُستخدم أنه قد تمّ استدعاء البيانات من الذّاكرة المُخبّئة بشكل مُباشر: <?php $mem = new Memcached(); $mem->addServer("127.0.0.1", 11211); mysql_connect("localhost", "test", "testing123") or die(mysql_error()); mysql_select_db("mem_test") or die(mysql_error()); $query = "SELECT name FROM sample_data WHERE id = 1"; $querykey = "KEY" . md5($query); $result = $mem->get($querykey); if ($result) { print "<p>Data was: " . $result[0] . "</p>"; print "<p>Caching success</p><p>Retrieved data from memcached!</p>"; } ?>سيتمّ في الخطوة التّالية كتابة الحالة البديلة، وستكون عند عدم وجود نتائج (جواب الشرط false)، ولذلك يجب استخدام الاستعلام الذي تمّت صياغته سابقًا لسؤال MySQL عن البيانات، ومن ثمّ تخزينها داخل المُتغيّر $result، والذي سيكون على شكل مصفوفة (array). أصبح من المُمكن بعد ذلك إضافة النتائج إلى الذّاكرة المُخبّئة، بعد توفّر نتيجة الاستعلام، لتكون هذه البيانات مُخبّئة للطلب التّالي، ولذلك سيتمّ تمرير ثلاثة مُعاملات لتعيين الذّاكرة المُخبّئة: المفتاح الّذي سيتمّ استخدامه كإشارة مرجعيّة للبيانات، وهو نفس المُفتاح المُنشئ بالمُتغيّر $querykey.البيانات نفسها، وهي مخزّنة في المُتغيّر $result بعد إجراء استعلام MySQL.مُدّة التخبئة بالثانية.سيتمّ تخزين التخبئة لمُدّة ثوانٍ قليلة، في البيئة الحقيقية، سيكون من المُفيد تخبئة المُحتوى لمدّة أطول، ربما دقائق عدّة، خاصّة إذا كان المُحتوى لا يتغيّر بشكل كبير، ولكن لأغراض التجربة، سيتمّ الالتزام بهذه الثواني بدلًا من إعادة تشغيل خدمة memcached لتكملة الاختبار. بعد ذلك، سيتمّ طباعة رسالة بنتائج الاستعلام، مع إخبار المُستخدِم بطريقة الحصول على البيانات: <?php $mem = new Memcached(); $mem->addServer("127.0.0.1", 11211); mysql_connect("localhost", "test", "testing123") or die(mysql_error()); mysql_select_db("mem_test") or die(mysql_error()); $query = "SELECT name FROM sample_data WHERE id = 1"; $querykey = "KEY" . md5($query); $result = $mem->get($querykey); if ($result) { print "<p>Data was: " . $result[0] . "</p>"; print "<p>Caching success</p><p>Retrieved data from memcached!</p>"; } else { $result = mysql_fetch_array(mysql_query($query)) or die(mysql_error()); $mem->set($querykey, $result, 10); print "<p>Data was: " . $result[0] . "</p>"; print "<p>Data not found in memcached.</p><p>Data retrieved from MySQL and stored in memcached for next time.</p>"; } ?>اكتملت الشيفرة بهذا الشكل، وبالمُختصر ما سيحدث هو مُحاولة الحصول على البيانات من الذّاكرة المُخبّئة، واستعراضها عند توفرها، وفي حال الفشل في الحصول على البيانات من الذّاكرة المُخبّئة، سيتمّ التوجّه مُباشرةً لاستعلام قواعد البيانات، ومن ثُمّ تخزين النتائج للطلب التّالي ولفترة ثواني معدودة. اختبار الشيفرةتمّ الانتهاء من كتابة الشيفرة، وأصبح بالإمكان اختبارها، وذلك عبر التوجّه إلى المُتصفّح واستعراض ملفّ الشيفرة: http://server_domain_name_or_IP/database_test.phpيجب أنّ تكون المُخرجات في الزيارة الأولى على الشكل التّالي: ما أن يتمّ تحديث الصفحة، وقبل انقضاء الثواني العشر، حتّى تَعرض الصفحة رسالة مُختلفة كما في التّالي: ما إنّ تنقضي الثواني العشر، ستنتهي صلاحيّة المُحتوى المُخبّئ، وسيُحذف من الذّاكرة المُخبّئة (memcached)، وستُعرض الرسالة الأولى الّتي تُشير إلى أنّ البيانات قد تمّ استدعاؤها من قاعدة البيانات بدلًا من الذّاكرة المُخبّئة. كلمات أخيرةيُفترض الآن وبعد الانتهاء من هذا الشرح الحصول على فهم كامل لكيفيّة إعداد الذّاكرة المُخبّئة، وكيف من المُمكن الحفاظ على أداء خادوم الوب، بتجنيبه من إجراء استعلامات مٌتكرّرة على قواعد البيانات للحصول على نفس المُحتوى. يجب الانتباه إلى أنّ الشيفرة المُستخدمة في هذا الدليل هي فقط لأغراض الشرح، ولتُعطي فكرة واضحة عن آلية العمل وكيفيّة بناء منظومة كاملة وصحيحة تعتمد على الذّاكرة المُخبئة، واستعلام قواعد البيانات في حال فشلها. ترجمة – وبتصرّف – للمقال How To Install and Use Memcache on Ubuntu 14.04 لصاحبه Justin Ellingwood.

نحتاج في أحيانٍ كثيرة إلى إدخال تعديلات محدّدة على بعض الملفات، فمديرو نظم التشغيل يحتاجون أحيانًا إلى تعديل مجموعة فقط من عناوين الـ IP التي تنتمي إلى فئة ما، أو مجموعة من أسماء النطاقات domains (أو النطاقات الفرعية)، بل ربما احتاج أحدنا إلى تصحيح بعض الأخطاء الكتابية المتكرّرة في ملفٍ طويل، كحذف الأسطر الفارغة مثلًا، أو المسافات الفارغة في بدايات الأسطر، تغطّي التعابير النمطيّة Regular Expressions التعامل مع هذا النوع من المشاكل. التعابير النمطيّة هي أسلوب يُستخدم لوصف النصوص والتعرّف عليها من خلال مطابقتها (أو عدم مطابقتها) مع رموز محدّدة، وتنتشر تطبيقاتها في عدد متزايد من برامج معالجة النصوص، ومحرّرات اللغات البرمجيّة وغيرها. نتناول في هذا الدرس شرح أساسيات التعامل مع هذه التعابير دون تخصيص الحديث عن برنامج ما، حيث سنستخدم الأداة egrep في أمثلتنا (والتي تستخدم للبحث ضمن الملفات النصيّة أو دخل المستخدم عن طريق التعابير النمطيّة وطباعة الخرج المطابق لها على شاشة الطرفية). التعابير النمطيّة تدعم التعابير النمطيّة نوعين من المحارف: الأول هو الأحرف الأبجديّة المعروفة، والآخر هو الرموز الخاصة Metacharacters، وهي ما تعطي التعابير النمطية فاعليتها الحقيقية. لنأخذ الملف التالي country.txt كمثال، وهو - كما نرى - مؤلف من سبعة أسطر وثلاثة أعمدة، العمود الأول يحمل اسم البلد، والثاني عدد سكانه، والأخير القارّة التي يقع فيها: $ cat country.txt India,1014003817,Asia Italy,57634327,Europe Yemen,1184300,Asia Argentina,36955182,Latin America Brazil,172860370,Latin America Cameroon,15421937,Africa Japan,126549976,Asia محارف الإرساء الخاصة لنبدأ في شرح المحارف الخاصة مع العلامتين ^ و $، واللتان تشيران إلى أول السطر وآخره على التتالي، وتسمى بمحارف الإرساء anchor metacharacters. فلو رغبنا مثلًا بمعرفة الأسطر التي تبدأ بحرف "I"، فإننا سنستخدم التعبير: $ egrep '^I' country.txt India,1014003817,Asia Italy,57634327,Europe وبالمثل، لتحديد الأسطر التي تنتهي بحرف "e"، نكتب: $ egrep 'e$' country.txt Italy,57634327,Europe العلامة التالية هي النقطة (.)، والتي تشير إلى محرف واحد (حرف، رقم، أو علامة)، فللبحث عن أسماء المدن المؤّلفة من خمسة محارف نطبع الأمر: $ egrep '^.....,' country.txt India,1014003817,Asia Italy,57634327,Europe Yemen,1184300,Asia Japan,126549976,Asia الآن لنجرّب البحث عن الأسطر التي تبدأ بحرف "I" أو "J" ومؤلفة من خمسة محارف: $ egrep '^[IJ]....,' country.txt India,1014003817,Asia Italy,57634327,Europe Japan,126549976 تسمّى الأقواس المستطيلة [] هنا بصفّ المحرف character class، وهي تبحث عن تطابق واحد فقط من المحارف التي تضمها مع النصّ. وإذا وضعنا بداخلها العلامة ^ فإنها تصبح صفّ استبعاد، أي تطابق كل النصّ المذكور عدا ما يلحقها، فلو أردنا البحث عن أسماء البلدان المؤلفة من خمسة محارف والتي لا يبدأ اسمها بحرف "J" ولا "I" فإننا نكتب: $ egrep '^[^IJ]....,' country.txt Yemen,1184300,Asia مجموعات المحارف الخاصة وتنويعاتها لمطابقة جميع الأسطر التي تضم كلمة Asia أو Africa نكتب: $ egrep 'Asia|Africa' country.txt India,1014003817,Asia Yemen,1184300,Asia Cameroon,15421937,Africa Japan,126549976,Asia كما يمكن إجراء ذات البحث باستخدام تعبير نمطي يستخرج حرفي A و a كعوامل مشتركة في الكلمتين: $ egrep 'A(si|fric)a' country.txt India,1014003817,Asia Yemen,1184300,Asia Cameroon,15421937,Africa Japan,126549976,Asia تحديد الكميّة بدلًا من كتابة العبارة: $ egrep '^[IJ]....,' country.txt يمكننا اختصارها بالشكل: $ egrep '^[IJ].{4},' country.txt يسمى القوسين المزهّرين هنا {} بمحدّدي الكمية، وتضم رقم يعبّر عن عدد المرات التي يجب أن يتكرر فيها المحرف قبل مطابقته، كما تُستخدم للتعبير عن مدى (مجال) من المرات: $ egrep '^[IJ].{4,6},' country.txt India,1014003817,Asia Italy,57634327,Europe Japan,126549976,Asia يبحث التعبير النمطي السابق عن أسماء البلدان التي تبدأ بالحرف "I" أو "J" وتتراوح عدد محارفها من 4 إلى 6. هناك أيضًا بعض الاختصارات التي يمكن استخدامها مع تحديد الكمية مثلًا المجال {0,1} والذي يعني "يوجد مرة واحدة على الأقل أو لا يوجد تمامًا"، يُكافئ بالرمز ؟، حيث يمكننا كتابة: $ egrep '^ab{0,1}c$' filename أو: $ egrep '^ab?c$' filename أيضًا المجال {0,} يُكافئ بالرمز *، والتي تعني عدد لا نهائي من المرات، حيث التعبير: $ egrep '^ab{0,}c$' filename يساوي بالنتيجة: $ egrep '^ab*c$' filename وكذلك المجال {1,} والذي يحدّد الكمية "مرّة واحدة على الأقل"، يُكافئ بالرمز +، ويكون التعبيرين التاليين متكافئين: $ egrep '^ab{1,}c$' filename $ egrep '^ab+c$' filename لنأخذ الآن بعض الأمثلة الأكثر تعقيدًا ولندمج ما تعلمناه من تعابير، لكن عوضًا عن البحث ضمن ملف نصيّ txt سنعالج دخل قياسي من قبل المستخدم. لنبحث مثلًا عن كل الاحتمالات الممكنة في تهجئة الجملة التالية: the grey colour suit was his favourite $ egrep 'the gr[ea]y colou?r suit was his favou?rite' the grey color suit was his favourite the grey color suit was his favourite the gray colour suit was his favorite the gray colour suit was his favorite لو نظرنا إلى التعبير المستخدم في هذا المثال، فإننا سنرى: الكلمة "grey" يمكن أن تلفظ grey أو gray. الكلمة "colour" تكتب بطريقتين: colour أو color، وهذا يعني بأن حرف (u) اختياري، لذلك استخدمنا العلامة ؟ والتي تعني "يوجد مرة واحدة على الأقل أو لا يوجد تمامًا. + كذلك الأمر مع الكلمة "favourite" حيث كتابة حرف (u) اختيارية لذا استخدمنا ذات العلامة ؟ لنجرّب الآن مطابقة عنوان الرمز البريدي zip code في الولايات المتحدة: $ egrep '^[0-9]{5}(-[0-9]{4})?$' 83456 83456 83456- 834562 92456-1234 92456-1234 10344-2342-345 مثال آخر يطابق جميع الأوقات الممكنة في الأربع والعشرين ساعة: $ egrep '^([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9]' 23:44:02 23:44:02 33:45:11 15:45:33 15:45:33 في المثال السابق قلنا أنه إذا كانت الخانة الأولى من الساعة إما 0 أو 1، عندها يسمح للخانة الثانية بأن تأخذ قيمة من المجال من 0 إلى 9، ولكن إذا كانت الخانة الأولى تحمل الرقم 2 حينها يسمح للخانة الثانية أن تأخذ القيم 0، 1، 2، أو 3. حدود الكلمة لكتابة تعبير نمطي يطابق الكلمات التي تنتهي بـ "color"، سنرى أنه يطابق الأمثلة: unicolor ،watercolor ،multicolor، لكنه لن يطابق colorless أو colorful: تطابق العلامة "<\" ورود كلمة color آخر الكلمة مثل unicolor، watercolor، أو multicolor، $ egrep 'color\>' أما لمطابقة كلمة color في أوّل الكلمة، مثل colorless أو colorful، فإننا نكتب: $ egrep '\<color' ولمطابقة كلمة color كما هي: $ egrep '\<color\>' الإحالات المرجعية لنفترض أننا نريد مطابقة جميع الكلمات المكرّرة مثل "the the" أو "before before"، هنا نستخدم ما يسمى بالإحالات المرجعية backreferences والتي تستعمل لتذكّر الأنماط، مثال: $ egrep "\<the\> \1" أو في الحالة العامّة: $ egrep "\<(.*)\> \1" يطابق التعبير السابق جميع الكلمات عندما تتشابه الثانية مع الأولى، كما يمكن استخدام زوج إضافي من الأقواس مع المرجع 2\ لمطابقة الكلمات فقط إذ تكررت أربع مرات، وهكذا.. ترجمة -وبتصرّف- للمقال: An Introduction To Regular Expressions للكاتب: Shantanu Kulkarni.

يُعتبر خادوما الويب Apache و Nginx الأكثر شهرةً من بين الخواديم المفتوحة المصدر في عالم الشبكة العنكبوتيّة، على اعتبار أنّهما مسؤولان عن خدمة وتأمين نصف تدفّق البيانات على الإنترنت، وعلى مَقدرة على تولّي مُختلف حجوم الأحمال، والعمل مع برمجيات أخرى في سبيل توفير حزمة من خدمات الويب الشاملة والكاملة لتلبية مُختلف الاحتياجات. بينما يَتشارك الخادومان Apache و Ngnix العديد من الميّزات والخاصيّات، فلا يُمكن اعتبارهما مُتشابهان، أو التفكير بأن أحدهما هو بديل عن الآخر، فكل منهما يتفّوق عن الآخر بشيءٍ ما، وعلى مُدير النظام فهم وإدراك لماذا يجب اختيار أحدهما دون الآخر، فهذا الدليل يَهدف إلى مُناقشة كيف أنّ كُل خادوم يَتميّز ويَبرز في شيء ويُخفق في آخر. مقدّمة عامّةسيتمّ أخذ نظرة سريعة عن تاريخ وبداية المشروعين وخواصّهم العامّة قبل التعمّق في الاختلاف بينهما. تاريخ خادوم الويب Apacheأَنْشَأَ “روبت ماك كول” (Robert McCool) “خادم الـ HTTP أباتشي” (Apache HTTP Server) في عام 1995، وتمّ مُتابعة تطويره تحت مظلّة “مُنشأةُ برمجيات أباتشي” (Apache Software Foundation) مُنذ العام 1999، وكان هذا الخادم هو المشروع الأساسي للمُنشأة والأكثر شهرةً عن باقي البرمجيات، فأصبح ببساطة يُشار إليه بالاسم “Apache”. يُعتبر خادم الويب أباتشي الخادم الأكثر استخدامًا على الإنترنت منذ العام 1996، وبسبب هذه الشهرة، استفاد أباتشي من توثيق ودعم باقي مشاريع البرمجيات الأُخرى. يَختار مُدراء الأنظمة الخادم أباتشي غالبًا بسبب مرونته، وقُدرته على التحمّل، وتوفّر دعمه العالي والمُنتشر، كما يُحسب له قابليته على التوسّع عبر نظام الوحدات (modules) الديناميكيّة، واستطاعته على مُعالجة عدد كبير من اللغات المُفسّرة (interpreted languages) من دون الحاجة إلى برمجيّة مٌستقلّة وسيطة. تاريخ خادوم الويب Nginxبَدأ “ايجور سيسيوﭫ” في عام 2002 العمل Nginx للإجابة وحلّ المُشكلة المعروفة بالاسم C10K، والّتي كانت تُشكّل تحدّيًا كبيرًا لخوادم الويب لتُصبح قادرة على تولّي عشرة آلاف اتصال مُتزامن (concurrent) وذلك في تلبية حاجة الويب الحديث، وأُنتجت الإصدارة الأوليّة والمُتاحة للعُموم في عام 2004 مُقدمةً حلًا لهذه المُشكلة، وذلك بالاعتماد على معماريّة مدفوعة بالحالة (event-driven) ولا مُتزامنة. انتشر Nginx كالنار في الهشيم مُنذ إصداره، بمُقتضى خفته واستخدامه الخفيف للمَوارد، وقدرته على التوسّع وتحمّل الضغط العالي وبأقل عتاد مُمكن، وتفوّق Nginx بتأمين المُحتوى الثّابت (static content) بسرعة، وبتصميمه لتمرير الطلبات الديناميكيّة (المُتغيّرة) إلى برمجيات أُخرى قادرة على مُعالجة هذا النوع من المُحتوى. يختار مُدراء الأنظمة الخادم Nginx غالبًا بسبب استهلاكه الأمثل للمَوارد، واستجابته العالية مع الضغط المتزايد. معماريّة مُعالجة الاتصال (Connection Handling Architecture)يَكمن الاختلاف الواضح بين أباتشي و Nginx في طريقة كلٍ منهما في مُعالجة الاتصالات وتدفّق البيانات (traffic)، وربّما هذا السبب وراء الاختلاف في طريقة كل من الخادمين في الاستجابة إلى حالة تدفّق البيانات المُختلفة. وحدات أباتشي (Apache Modules)يقدّم أباتشي تشكيلةً من وحدات المُعالجة المُتعدّدة (multi-processing)، والّتي يُطلق عليها بـ MPMs، والغرض منها تحديد آليّة مُعالجة طلبات العميل، ويَسمح ذلك مُدراء الأنظمة عامّةً بالتبديل بين معماريّة مُعالجة الاتصال بسهولة، والوحدات هي: mpm_prefork: تَستنسخ وتُوالد هذه الوحدة الخاصّة بالمُعالجة عمليّات (processes) باستخدام سلسلة وحيدة (single thread)، على أنّ تكون كل عمليّة لمُعالجة طلب، ويستطيع كل ابن مُعالجة اتصال واحد في نفس الوقت، وطالما أنّ عدد الطلبات أقل من عدد العمليّات، فستكون هذه الوحدة سريعةً جدًا، ولكن يَنخفض الأداء بسرعة بعد تخطّي الطلبات عدد العمليّات، ولذلك لا يُعتبر هذا النمط بالخيار الجيّد للعديد من السيناريوهات، فكل عمليّة لها تأثير بليغ على استهلاك الذاكرة (RAM)، ولهذا السبب تُصعّب هذه الوحدة من عمليّة التوسّع بطريقة مُلائمة، ومع هذا تبقى هذه الوحدة خيارًا جيّدًا إن تمّ استخدامها مقترنةً مع مُقوّمات (components) أُخرى لم تُبنى بالأساس آخذةً بعين الاعتبار السلاسل (threads)، فلغة PHP ليست سلسلة آمنة (thread-safe)، ولذلك يُنصح بهذه الوحدة باعتبارها الطريقة الوحيدة الآمنة للعمل مع mod_php والّتي هي وحدة من وحدات أباتشي لمُعالجة هذا النوع من الملفّات. mpm_worker: تستنسخ وتُوالد هذه الوحدة عمليّات (processes) كل منها ذات قُدرة على إدارة سلاسل مُتعدّدة (multiple threads)، تستطيع كل واحدة من هذه السلاسل مُعالجة اتصال وحيد، تُعتبر هذه السلاسل أكثر كفاءة من العمليّات، بسبب أنّ هذه الوحدة تتوسّع (scales)، وتتحمّل المزيد من الضغط أفضل من الوحدة prefork MPM، وباعتبار أنّه يوجد سلاسل أكثر من العمليّات، فهذا يعني أيضًا أنّ الاتصالات الجديدة تستطيع مُباشرةً استهلاك واستخدام سلسلةبدلًا من اضطرارها إلى الانتظار لتوفّر عمليّة مُتاحة. mpm_event: تَعمل هذه الوحدة بشكل مُشابه إلى الوحدة worker، ولكنها مُحسّنة لتتولّى اتصالات keep-alive، فعند استخدام الوحدة worker فإن الاتصال سيَحتفظ بالسلسلة (thread) بصرف النظر فيما إذا كان الطلب نشطًا فيما صُنع من أجله ما دام الاتصال محفوظًا نشطًا، فالوحدة mpm_event تتولّى الاتصالات keep-alive بالاحتفاظ جانبًا بسلاسل مكرّسة لمُعالجتها، وبتمرير الطلبات النشطة إلى سلاسل أُخرى، وهذا من شأنه أنّ يُبعد الوحدة من الغوص بطلبات keep-alive، الأمر الّذي يُجيز بتنفيذ الطلبات (execution) بشكل أسرع، وهذا الأسلوب أصبح يعمل بشكل مُستقر مع الإصدار Apache 2.4. أصبح الأمر أكثر وضوحًا، حيث تقدّم خوادم أباتشي بنية معماريّة مرنة للاختيار بين مُختلف الاتصالات وخوارزمية مُعيّنة في مُعالجة الطلبات، وبُنيت هذه الخيارات في الدرجة الأولى من تطوّر الخادم والحاجة المُتزايدة للاتصالات المُتزامنة لتواكب طبيعة الإنترنت بعد تغيرها وتطوّرها. آليّة مُعالجة الاتصال في خادوم Nginxقَدِم Nginx إلى عالم خوادم الويب بعد قدوم أباتشي، مَبنيًّا ومُعدًّا لمشاكل الاتصالات المُتزامنة (concurrency) الّتي تواجه المواقع عند التوسّع، مُحمّلًا بهذه المعرفة، صُمّمَ Nginx من جذوره ليستخدم خوارزميّة في مُعالجة اتصالات مدفوعة بالحالة (event-driven)، غير مُستوقفة (non-blocking)، ولا مُتزامِنة. يستنسخ ويُوالد Nginx من العمليّات العاملة (worker processes)، ويستطيع كلٍ مِنها مُعالجة آلاف الاتصالات، وتُنجذ العمليّات العاملة ذلك عن طريق تطبيق/تنفيذ آلية حلقيّة سريعة، والّتي تفحص بشكل مُستمر حالات العمليّات (processes events)، وإن فصل المُهمّة الفعليّة عن الاتصالات يسمح لكلعامل بالاهتمام بنفسه باتصال فقط عند بدء حالة جديدة. يتموضع كل اتصال مُعالج من قبل العامل ضمن حلقة الحالة (event loop) في مكان تواجد بقية الاتصالات، وتُعالج الأحداث بشكل لا مُتزامن ضمن الحلقة، ليتمّ إنجاز المُهمّة بطريقة غير مُستوقفة (non-blocking)، وعندما يُغلق الاتصال سيتمّ نزعه من الحلقة. يَسمح هذا الأسلوب من مُعالجة الاتصال Nginx بتحمّل الضغط العالي بشكل لا يُصدّق وبأقل المَوارد المُتاحة، وباعتبار أنّ الخادم ذو سلسلة وحيدة (single-threaded) ولا تتوالد العمليّات لتُعالج كل اتصال جديد، فإن استهلاك المُعالج (CPU)، والذّاكرة يبقى ثابتًا نسبيّا، حتّى في أوقات الذروة. كيف يُعالج أباتشي و Nginx المُحتوى الثّابت والمحتوى الديناميكي (المُتغيّر)إن أبرز ما يتمّ النظر إليه عند المُقارنة بين الخادمين هي طريقة كلٍ منهما في التعامل مع طلبات المُحتوى الثّابت (static)، والمُحتوى المُتغيّر (dynamic). كيف يتعامل أباتشي مع المُحتوى الثّابت والمُتغيّرتستطيع خوادم أباتشي التعامل مع المُحتوى الثّابت باستخدام الطريقة التقليديّة المُعتمدة على الملفّات، ويعود أداء هذه الإجراءات (operations) في الدرجة الأولى على دور ووظيفة أساليب الوحدات (MPM) المشروحة سابقًا. يستطيع أباتشي أيضًا مُعالجة المُحتوى الديناميكي (المُتغيّر) بدمج مُعالج اللغة المُراد مُعالجتها داخل كل من نماذجه العاملة (worker instances)، وهذا يَسمح له بتنفيذ المُحتوى الديناميكي داخل خادم الويب نفسه بدون الحاجة إلى الاعتماد على مُقوّمات خارجيّة، ومن المُمكن تفعيل هذه المُعالجات الديناميكيّة (المُتغيّرة) من خلال استخدام وحدات قابلة للتحميل بشكل ديناميكي. إن قدرة أباتشي على مُعالجة المُحتوى الديناميكي بشكل داخلي تعني أنّ الإعداد يُصبح أسهل لمُعالجة هذا النوع من المُحتوى، فليس من الضروري تنسيق عمليّة الربط مع برمجيات إضافيّة، وتستطيع الوحدات وبسهولة أنّ تقوم بالتبديل عندما تتغيّر مُتطلّبات المُحتوى. كيف يتعامل Nginx مع المُحتوى الثّابت والمُتغيّرلا يَملك Nginx بطبيعته أي قدرة على مُعالجة المُحتوى الديناميكي، ولمُعالجة شيفرة PHP وطلبات المُحتوى الديناميكي، فإن على Nginx تمرير الطلبات إلى مُعالج خارجي من أجل التنفيذ (execution) والانتظار ريثما يتم الانتهاء من مُعالجة هذا المُحتوى ليتمّ إعادة إعادته، ومن ثم عرض النتائج على العميل. يَنبغي على مُدراء الأنظمة الانتباه إلى أنّ الأسلوب الّذي ينتهجه Nginx يستوجب إعدادًا بينه وبين المُعالج وباستخدام واحدًا من البرتوكولات الّتي يفهمها Nginx أمثال: HTTP, FastCGI, SCGI,uWSGI, memcache، وهذا من شأنه أنّ يُعقّد الأمور بعض الشيء، خصوصًا عند مُحاولة توقّع عدد الاتصالات اللازم السماح بها، حيثُ أنّه سيتمّ استخدام اتصالًا إضافيًا لكل مُعالج يتمّ استدعاؤه. من ناحية أخرى، إن هذا الأسلوب يقدّم بعضًا من الأفضليّة، عندما نعلم أنّ مُفسّر المُحتوى الديناميكي غير مُدمج في عمليّة العامل، وتكلفة هذه الطريقة ستُدفع للمُحتوى الديناميكي فقط، وعلى أنّ يُقدّم المُحتوى الثّابت بطريقة مُباشرة، ولا يتمّ الاتصال بالمُفسر إلا عند الحاجة، والجدير بالذكر أنّ أباتشي يستطيع العمل بهذا الأسلوب، ولكن بعمله ذلك سيتخلّى عندها عن بعض ميزاته. الاختلاف بين الإعداد الموزّع (Distributed) والإعداد المركزي (Centralized)يَعتبر مُدراء الأنظمة الاختلاف الأكبر والبارز بين هذين الخادمين هو فيما إذا كان الإعداد والتخصيص على مُستوى المسار مسموحًا أو لا ضمن مسارات (directories)المُحتوى. فلسفة Apache في الإعداديُضمّن أباتشي خيارًا للسماح بالإعداد لكل مسار عن طريق تَفحُّص (inspecting) وتفسير (interpreting) التعليمات أو التوجيهات الموجودة في الملفات المخفيّة داخل مسارات المُحتوى نفسها، وهذه الملفّات معروفة بملفات .htaccess. باعتبار أنّ هذه الملفّات تَقطن داخل مسارات المُحتوى نفسها، فعند مُعالجة طلبٍ ما، فإن أباتشي يَفحص كل جزء من مسار الملفّ المطلوب باحثًا عن ملفّ .htaccess ليُطبّق التوجيهات الّتي بداخله، وهذا من شأنه أنّ يسمح للإعداد اللامركزي لخادم الويب، والذي غالبًا ما يُستخدم لإنجاز: إعادة كتابة عنوان الموقع (URL rewrites)تقييد الوصول (access restrictions)التفويض والمُصادقة (authorization and authentication)سياسات التخبئة (caching policies)بالطبع يُمكن للأمثلة السابقة إعدادها عن طريق ملفّ إعدادات أباتشي الرئيسي، ولكن استخدام ملفات.htaccess يَملك بعض الميزات: أوّلًا، باعتبار أنّها تُفسّر في كل مرّة توجد بها مع المسار المطلوب، فهي تُنفّذ مُباشرةً بدون إعادة تحميل الخادم.ثانيًا، تجعل من المُمكن السماح للمُستخدِمين غير المصرّح لهم بالتحكم بجانب معيّن من المُحتوى الخاصّة بهم بدون إعطائهم تحكم كامل لملفّ الإعدادات.يُقدّم هذا النمط من الإعداد طريقة سهلة ونموذجيّة، وخاصّة لبعض برمجيات الويب، مثل أنظمة إدارة المُحتوى (CMS)، لغرض إعداد بيئتها بدون مَنح إذن وصول إلى ملفّ إعدادات مركزيّ، وكما هو معروف يُستخدم هذا الأسلوب مع مزودات الاستضافة المُشتركة (shared hosting providers) لصون والحفاظ على الإعدادات الرئيسية مع إمكانيّة منح العُملاء أفضليّة التحكّم بمسارات مُعيّنة. فلسفة Nginx في الإعدادلا يُفسّر Nginx ملفّات .htaccess، ولا يُقدّم أي آليّة للتعامل مع كل مسار من دون استخدام ملفّ إعدادات رئيسي، قد يبدو هذا الأسلوب أقل مرونةً من أسلوب أباتشي، ولكن من ناحية أُخرى فلهذا الأسلوب أفضليته. إن عدم الاعتماد على نظام ملفّات .htaccess الخاصّ بالإعداد على مستوى المسارات يُقدّم سرعةً في الأداءً، فخادم أباتشي عليه القيام بتفحّص المسار الجذر لكل طلب يصله، وعند وجود ملفّ أو أكثر خلال عمليّة البحث، يتم قراءة محتوياته وتفسيرها، ولكن Nginx لا يفعل ذلك، فهو يخدم الطلبات بسرعة أكبر بالاعتماد على مكان وحيد للبحث عنه. أفضليّة أُخرى مُتعلّقة بالحماية، فإن توزيع ملفّات الإعدادات على مستوى المسارات يوزّع مسؤوليّة الحماية على كل المُستخدِمين، الّذين قد يكونوا في معظم الأحوال غير موثوقون لتولّي هذه المُهمّة بالشكل الأمثل، فعندما يقوم مُدير النظام بتولّي مُهمة التحكم بالخادم ككل، يمنع ذلك من حدوث أخطاء، والتي قد تحدث في حال منح صلاحيات وصول لأطراف أُخرى. يجدر الذكر أنّه من المُمكن تعطيل تفسير ملفّات .htaccess’ فيأباتشي`، في حال أنها تُشكل نوعًا من القلق لمُدير النّظام. الاختلاف بين تفسير الملفّات وتفسير URIلا يقتصر الاختلاف بين الخادومين على ما سبق فقط، فيظهر الاختلاف الآخر في كيفيّة تفسير كلٍ منهما للطلبات (requests) وربطها مع المَوارد المُتواجدة على النّظام. كيف يُفسر Apache الطلباتيقدّم أباتشي القدرة على تفسير الطلب إما كمَورد فيزيائي (حقيقي) على نظام الملفّات (filesystem) أو عنوان URI الّذي قد يحتاج أسلوب أكثر تجرّد، ويستخدم أباتشي بشكلٍ عام للأسلوب الأول كتل (blocks) وهي إما <Directory> أو <Files>، بينما يستخدم كتل <Location>للمَوارد الأكثر تجرّدًا. صُمّم أباتشي من الأساس كخادم ويب، لذلك في مُعظم الأحيان فإن السلوك الافتراضيّ هو تفسير الطلبات كمَوارد نظام ملفّات (filesystem)، حيثُ يبدأ بتتبّع جذر المُستند وإلحاقه بجزئية الطلب متبوعًا باسم المُضيف (host) ورقم المنفذ في مُحاولة لإيجاد الملفّ المطلوب، بمعنى آخر وببساطة، تتمثّل هرميّة نظام الملفّات على الويب كشجرة مُستند. يُقدّم أباتشي عددًا من البدائل عندما لا يتوافق الطلب مع نظام الملفّات المقصود، فمثلًا من المُمكن استخدام الموجّه Alias لربط عنوان البديل، مع العلم أنّ استخدام الكتل <Location> هو طريقة للتعامل مع URI نفسها بدلًا من نظام الملفّات، كما يُمكن استخدام التعابير النمطيّة (regular expression)، والّتي من المُمكن استخدامها لتطبيق الإعداد بسهولة أكبر في كامل نظام الملفّات. يُعوّل أباتشي على نظام الملفّات بشكل كبير، يظهر ذلك جليًا في اعتماده على ملفّات .htaccessلإعداد كل مسار، حتّى أنّ التوثيق الرسميّ الخاصّ به يحذر من استخدام كتل مُعتمدة على URI في تقييد الوصول عندما يكون الطلب يَعتمد بشكل أو بآخر على نظام الملفّات. كيف يُفسّر Nginx الطلباتأُنشِأ Nginx ليكون خادمًا للويب وخادمًا وكيلًا/وسيطًا (proxy server)، ونظرًا إلى المعماريّة المطلوبة للعمل بهذه الأدوار، فإنه يعمل بشكل رئيسي مع URIs، والتحويل إلى نظام الملفّات عند الضرورة. يُمكن رؤية ذلك في بعض جوانب بناء وتفسير ملفّات إعدادات Nginx، فلا يوفّر Nginx آليّة لتحديد إعدادًا لمسار نظام الملفّات، بل يَستعيض عنها بتحليل URI نفسه. يُمكن توضيح ذلك بالمثال، كتل الإعداد الأوليّ لـ Nginx هي: server و location، الكتلة serverتُفسّر المُضيف الجاري طلبه، بينما الكتل مسؤولة عن مُطابقة أجزاء من URI التي تأتي بعد المُضيف والمنفذ، في هذه المرحلة يتمّ تفسير الطلب كـ URI، وليس كعنوان على نظام الملفّات. يتوجّب في نهاية المطاف على جميع الطلبات أنّ تُربط مع عنوان على نظام الملفّات وذلك للملفّات الثّابتة، فأولًا، سيَختار Nginx كتل server و location الّتي سوف تتولّى الطلب، ومن ثم ضم جزر المُستند مع الـ URI. إن تحليل ومُعالجة الطلب قبل كل شيء على شكل URIs بدلًا من عناوين نظام الملفّات يَسمح لـ Nginxالعمل بسهولة وعلى حدٍّ سواء كخادم وسيط (بروكسي)، وكخادم بريد، وخادم ويب، فقد تمّ إعداده ليُلائم كيف له أنّ يستجيب لأنماط الطلبات المُختلفة، ولا يفحص Nginx نظام الملفّات حتّى يكون جاهزًا ليَخدم الطلب، وهذا يُفسّر لماذا هو لا يُطبّق نمط ملفّات .htaccess. الوحداتيتوسع كلا الخادومان عن طريق نظام الوحدات، ولكن طريقة عملهما تختلف عن الآخر بشكل كبير. كيف يستخدم أباتشي نظام الوحدات (Modules)؟يَسمح نظام وحدات أباتشي بطريقة آليّة وديناميكيّة بتركيب ونزع الوحدات ليتناسب مع مُتطلّبات مُدير النظام خلال عمليّة تشغيل الخادم، وتتواجد نواة أباتشي دائمًا بكل جاهزية، بينما يُمكن تشغيل أو تعطيل الوحدات، أو حتّى حذفها أو إضافة ما يلزم إلى الخادم. يستخدم أباتشي الوحدات في العديد من المهام، ونظرًا للباع الطويل لمنصة أباتشي، فيتوفّر عدد هائل من مكتبات الوحدات، والّتي من المُمكن استخدامها في تعديل بعض الوظائف الداخليّة في بنية خادم أباتشي، فمثلًا الوحدة mod_php تقوم بدمج مُفسّر PHP داخل كل عامل (worker). لا تنحصر الوحدات لمُعالجة المُحتوى الديناميكي (المُتغيّر) فقط، فيُمكن استخدامها في العديد من الوظائف، فيُمكن استخدامها في: rewriting URLs: إعادة كتابة العناوينauthenticating: المُصادقةlogging: التّتبّعcaching: التخبئةcompression: الضغطproxying: الوساطةencrypting: التشفيركيف يتعامل Nginx مع نظام الوحدات (Modules)يُطبّق ويتعامل Nginx مع نظام الوحدات، ولكن يختلف الأمر عما هو في نظام أباتشي، فلا تُحمّل الوحدات بشكل ديناميكي في نظام Nginx، لذلك يجب على هذه الوحدات أنّ تُختار وتُترجم (compiled) إلى النواة. قد يبدو الأمر صعبًا للعديد من المُستخدمين وخاصّة لهؤلاء الذين لا يُحبذون صيانة برمجياتهم المُترجمة (compiled) بدون الاستعانة بنظام حزم تقليدي، وعلى الرغم من أنّ حزم الموزّع تتضمّن الوحدات الأكثر استخدامًا، ولكن عند الحاجة إلى وحدة غير شائعة، سيتوجب على مُدير النظام بناء الخادم من المصدر بنفسه. تَبقى وحدات Nginx مع ذلك ذات فائدة، وتسمح لمُدير النّظام بتحديد ماذا يجب على الخادم أنّ يحتوي من وظائف، أيضًا بعض المُدراء ينظر إلى الأمر من منظور الحماية، حيثُ أنّ المُكوّنات الاعتباطيّة لا يُمكن أن تُدرج داخل الخادم. تُقدّم وحدات Nginx مقدرات مُماثلة للوحدات الّتي المُقدّمة من أباتشي، على سبيل المثال، توفّر وحدات Nginx: proxying support: الوساطةcompression: الضغطlogging: التّتبّعrewriting: إعادة كتابة العنوانauthentication: المُصادقةencryption: التشفيرالدعم والتوافُقيّة والتوثيقيجب دائمًا التأكد من آليّة بناء الخادم ومُتطلباتها، وما الّذي على مُدير النّظام عمله لبناء خادم يعمل بأبسط الإمكانيات، وما هو حجم الدعم والمُساعدة المتوفّر لهذه البرمجية. الدعم في أباتشييُعرف الخادم أباتشي بباعه الطويل في هذا المجال، ولذلك فإن الدعم الخاصّ به متواجد وبقوّة، حيثُ يتوفّر توثيق مُمتاز لمكتباته الخاصّة به ومكتبات الطرف الثالث (الخارجيّة)، وعلى كافّة المُستويات، سواء كان لنواة الخادم أو للجزئيات المُرتبطة ببرمجيات أُخرى. يتوفّر بجانب التوثيق، العديد من الأدوات ومشاريع الويب لتسريع بدء العمل مع بيئة الخادم، وهي موجودة ضمن المشاريع نفسها أو مُتوفّرة ضمن برمجيات الحزم المعروفة. يَملك أباتشي بشكلٍ عام دعمًا قويًا من قِبل مشاريع الطرف الثالث، وذلك بسبب حصته السوقيّة، وقِدَمه، كما يَملك مُعظم مُدراء الأنظمة بشكل أو بآخر معرفة جيّدة بخادم أباتشي، ليس فقط بسبب انتشاره، ولكن أيضًا بسبب أنّ معظمهم بشكل أو بآخر يستخدم الاستضافة المُشتركة (shared-hosting)، والّتي تعتمد على خادم أباتشي بشكل حصري، لمقدرته الإدارية الموزّعة باستخدام ملفّ .htaccess. الدعم في Nginxيكسب Nginx المزيد من الدعم مع ازدياد المُستخدِمين بسبب أدائه العالي، ولكن يبقى عليه التطوير من نفسه في بعض الجزئيات. قد كان من الصعب إيجاد توثيق مفهوم وواضح بالغة الإنكليزية للخادم Nginx في البداية، نظرًا إلى أنّ تطويره وتوثيقه تمّ بالغة الروسية، ومع ازدياد الاهتمام بالمشروع، أصبح هناك وفرة من المصادر على الموقع الرسميّ وغيره من الدعم الخارجي. أصبح الدعم متوفّرًا أكثر من ذي قبل فيما يخص تطبيقات الطرف الثالث، وبدأت بعض الحزم بتقدم خيارات الإعداد التلقائي سواءً لـ أباتشي أو Nginx، وعند عدم توفّر الدعم، فإن إعداد Nginx مع البرمجيات البديلة عادةً ما يكون واضحًا ومُيسرًا طالما أنّ برمجية الطرف الثالث تملك توثيقًا جيّدًا لمُتطلّباتها. استخدام Apache و Nginx معًاتمّ عرض فوائد وقصور كلا الخادومين، ويجب على مُدير النّظام في هذه المرحلة أنّ يُحدّد أيًا منهما يُناسب احتياجاته، ولكن يجد العديد من المُستخدِمين أنّه من المُمكن تقوية خادوم الويب عند استخدام كلٍ من أباتشي و Nginx جنبًا إلى جنب. إن إتمام هذه الشراكة يتمّ عن طريق تَمَوْضُع Nginx أمام أباتشي كوكيل/وسيط عكسي (reverse proxy)، وهذه يسمح لـ Nginx بمُعالجة جميع الطلبات من العُملاء، الأمر الّذي يَسمح بالاستفادة من سرعة Nginx وقدرته على تولّي عدد كبير من الاتصال في وقتٍ واحد. إن خدمة الملفّات الثّابتة بسرعة كبيرة ومباشرةً إلى العُملاء، هو الأمر الّذي يتفوّق به Nginx، ولكن وللمُحتوى الديناميكي، ملفات PHP مثلًا، سيُوكل Nginx الطلبات إلى أباتشي لمُعالجتها والعودة بصفحة بالنتيجة النهائيّة، ليستطيع Nginx عندها تمرير المُحتوى إلى العميل. يعمل هذا الإعداد بشكل جيّد للعديد من مُدراء الأنظمة، وذلك بسبب أنّه يسمح لـ Nginx ليعمل كآلة فرز وتصنيف، بمعنى أنّه سيتولّى مُعالجة جميع الطلبات طالما أنّه يستطيع ذلك، وتمرير ما لا يستطيع التعامل معه، وبتخفيض الطلبات المطلوب من خادم أباتشي تولّيها، سيُخفف بعضًا من الاستيقاف (blocking) الّذي قد يحدث عندما يستهلك أباتشي المزيد من المُعالج. يَسمح هذا الإعداد أيضًا لمُدراء الأنظمة بالتوسّع عن طريق إضافة خادم خلفي (backend) على حسب الحاجة والضرورة، ومن المُمكن إعداد Nginx لتمرير الطلبات إلى تجمّع (pool) من الخوادم بسهولة، الأمر الّذي يزيد من الأداء والفعاليّة. الختاميُقدّم كلًا من أباتشي و Nginx مُرونة في الاستخدام، وقوّةً في الأداء، والتفضيل بينهما هو لأمرٌ يَعتمد على تقدير مُتطلبات ووظائف الخادم، وعلى مُدير النّظام أنّ لا يسأل: هو أفضل خادم ويب؟، بل السؤال الّذي يجب سؤاله هو، ما هو أفضل خادم ويب لمشروعي الّذي يتطلّب كذا وكذا؟ يوجد بالفعل اختلافات بين المشروعين، هذه الاختلافات من شأنها أن تأثر على الأداء، والقدرات، والوقت المُستغرق في إتمام أي منهما للعمل بالجاهزيّة الكاملة، ولكي يتمّ اختيار الأفضل يُنصح بعمل تسوية أو مقايضة بين المحاسن والمساوئ، ففي نهاية المطاف لا يوجد خادم يُلبي كافة الاحتياجات، ويَكمن الحلّ في ترتيب الأولويات. ترجمة –وبتصرّف– للمقال Apache vs Nginx: Practical Considerations لصاحبه Justin Ellingwood.

هل تريد الوصول إلى شبكة الإنترنت بشكلٍ آمن ومحمي من هاتفك الذكي أو حاسوبك المحمول عندما تقوم بالاتصال بشبكاتٍ غير موثوقة مثل الشبكات اللاسلكية العمومية لفندق أو مقهى؟ تسمح لك الشبكة الافتراضية الخاصّة (Virtual Private Network - VPN) بتصفّح الإنترنت بالشبكات غير الموثوقة بشكلٍ آمن ومجهول كما لو كنتَ على شبكةٍ آمنة وموثوقة. يتم تمرير تدفّق البيانات (traffic) من خادومك إلى وجهته ومن ثمّ يعود إليك حاملًا البيانات. يسمح لك هذا الإعداد عندما يتم ربطه مع [اتصال HTTPS] (https://en.wikipedia.org/wiki/HTTP_Secure) أن تقوم بتأمين عمليات تسجيل الدخول وعمليات الدفع وغيرها من العمليات التي تقوم بها عند تصفّحك للإنترنت. يمكنك تخطّي الحجب الذي يفرضه مزوّد الخدمة على مواقع معيّنة مثلًا وتخطّي تقييدات المنطقة الجغرافية لمواقع معيّنة، كما يمكنك تحصين موقعك وتدفّق HTTP الصادر من جهازك من الشبكات غير المحمية. OpenVPN هو عبارة عن شبكة افتراضية خاصّة لطبقة حِزَم البيانات الآمنة مفتوحة المصدر (SSL) ويقبل تشكيلةً واسعة من الإعدادات والتخصيصات. في هذا الدرس، سنقوم بإعداد خادوم OpenVPN على خادومنا ومن ثمّ نقوم بإعداده ليقبل الوصول إليه من نظام ويندوز، Mac OS X، iOS و Android. سنبقي خطوات التثبيت والإعداد أسهل ما يمكن في هذا الدرس. المتطلّباتالمتطلّبات الوحيدة اللازمة هي امتلاك خادوم يعمل بتوزيعة Ubuntu 14.04. يجب أن تمتلك الوصول إلى حساب المستخدم الجذر لإكمال هذا الدرس. إضافي: بعد إكمال هذا الدرس، سيكون من الجيد إنشاء حساب مستخدمٍ عادي بصلاحيات sudo لعمل صيانةٍ عامّة على خادومك في حال احتجتها مستقبلًا.الخطوة الأولى: تثبيت وإعداد بيئة خادوم OpenVPNإعداد OpenVPNقبل أن نقوم بتثبيت أيّ حزم، يجب أن نقوم بتحديث قوائم مستودعات توزيعة أوبونتو أولًا: apt-get updateومن ثمّ، يمكننا تثبيت OpenVPN و Easy-RSA: apt-get install openvpn easy-rsaيجب أن يتم استخراج ملفّ عيّنة إعدادات OpenVPN إلى المسار /etc/openvpn لكي نتمكّن من إضافته إلى عملية التثبيت الخاصّة بنا. يمكن القيام بهذا عبر الأمر: gunzip -c /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz > /etc/openvpn/server.confبمجرّد أن يتم استخراجه، افتح ملفّ server.conf في محرر نصوص. في هذا الدرس سنستخدم Vim ولكن يمكنك استخدم أيّ محرر نصوص تريده: vim /etc/openvpn/server.confهناك العديد من التغييرات التي يجب علينا تطبيقها على هذا الملفّ. سترى قسمًا يبدو هكذا: # Diffie hellman parameters. # Generate your own with: # openssl dhparam -out dh1024.pem 1024 # Substitute 2048 for 1024 if you are using # 2048 bit keys. dh dh1024.pemقم بتغيير dh1024.pem إلى: dh2048.pemسيقوم هذا بمضاعفة طول مفتاح RSA المُستخدم عندما يتم إنشاء مفاتيح الخادوم والعميل. ما نزال في ملفّ server.conf، والآن ابحث عن هذا القسم: # If enabled, this directive will configure # all clients to redirect their default # network gateway through the VPN, causing # all IP traffic such as web browsing and # and DNS lookups to go through the VPN # (The OpenVPN server machine may need to NAT # or bridge the TUN/TAP interface to the internet # in order for this to work properly). ;push "redirect-gateway def1 bypass-dhcp"قم بإلغاء تعليق السطر التالي (أزل إشارة # أو ; من قبله): ;push "redirect-gateway def1 bypass-dhcp" لكي يتمكّن خادوم OpenVPN الخاصّ بنا من تمرير التدفّق المطلوب من المستخدمين والعملاء إلى وجهته المطلوبة. يجب أن يبدو السطر هكذا بعد التعديل: push "redirect-gateway def1 bypass-dhcp"الآن ابحث عن هذا القسم: # Certain Windows-specific network settings # can be pushed to clients, such as DNS # or WINS server addresses. CAVEAT: # http://openvpn.net/faq.html#dhcpcaveats # The addresses below refer to the public # DNS servers provided by opendns.com. ;push "dhcp-option DNS 208.67.222.222" ;push "dhcp-option DNS 208.67.220.220"قم بإلغاء تعليق السطرين push "dhcp-option DNS 208.67.222.222" و push "dhcp-option DNS 208.67.220.220" . يجب أن يبدوا على هذا الشكل: push "dhcp-option DNS 208.67.222.222" push "dhcp-option DNS 208.67.220.220"يقوم هذا بإخبار الخادوم بأن يقوم بدفع OpenVPN ليتصل بالعملاء (clients) ليعطيهم عنوان الـDNS المخصص. يقوم هذا الأمر بحماية المستخدم من خروج طلبات DNS خارج اتصال الـVPN. وعلى كلّ حال، من المهم أن تقوم بتحديد عناوين الـDNS المطلوبة التي تريد استخدامها على كلّ جهازٍ من أجهزة العملاء. رغم أنّ OpenVPN يستخدم خدمة OpenDNS افتراضيًا إلّا أنّه يمكنك استخدامه أيّ خدمات DNS تريدها. القسم الأخير الذي يجب تغييره في ملفّ server.conf هو: # You can uncomment this out on # non-Windows systems. ;user nobody ;group nogroupقم بإلغاء تعليق كلٍّ من السطرين user nobody و group nobody. يجب أن يبدوا هكذا: user nobody group nogroupافتراضيًا، يقوم OpenVPN بالعمل باستخدام المستخدم الجذر (root) حيث يمتلك هذا الأخير وصولًا كاملًا إلى النظام. سنقوم عوضًا عن هذا بجعل OpenVPN يستخدم المستخدم nobody والمجموعة nobody. هذا المستخدم لا يمتلك صلاحيات ولا أيّ إمكانياتٍ للولوج، ويتم استخدامه عادةً لتشغيل التطبيقات غير الموثوقة مثل خواديم واجهات الويب. يمكنك الآن حفظ تغييراتك والخروج من VIM. توجيه حِزَم البياناتهذا الأمر هو عبارة عن خاصية sysctl تقوم بإخبار نواة الخادوم أن تقوم بتوجيه التدفّق من أجهزة العملاء إلى الإنترنت. إن لم يتم هذا الأمر، فإنّ التدفّق سيتوقف في الخادوم. يمكنك تفعيل توجيه حِزَم البيانات أثناء وقت التشغيل باستخدام الأمر التالي: echo 1 > /proc/sys/net/ipv4/ip_forwardنحتاج أن نقوم بجعل هذا الأمر دائمًا بحيث يبقى الخادوم يقوم بتوجيه التدفّق حتى بعد إعادة تشغيل الخادوم: vim /etc/sysctl.confفي بداية ملفّ sysctl ستجد: # Uncomment the next line to enable packet forwarding for IPv4 #net.ipv4.ip_forward=1قم بإلغاء تعليق net.ipv4.ip_forward. يجب أن يبدو ذاك السطر هكذا: # Uncomment the next line to enable packet forwarding for IPv4 net.ipv4.ip_forward=1احفظ تغييراتك واخرج. الجدار الناري غير المعقّد (ufw)ufw هو واجهة أمامية (front-end) لـiptables. إعداد ufw ليس صعبًا. وهو مُضمّن بشكلٍ افتراضي في Ubuntu 14.04، لذا يجب علين فقط إنشاء بضع قواعد (rules) وتعديل بعض الإعدادات ليعمل، ومن ثمّ سنقوم بتشغيله. للمزيد من المعلومات حول ufw يمكنك مراجعة كيفية إعداد جدارٍ ناري باستخدام UFW على خادوم أوبونتو ودبيان السحابي. أولًا قم بضبط ufw بحيث يسمح باتصال SSH. أدخل اﻷمر التالي: ufw allow sshسنستخدم OpenVPN عبر UDP في هذا الدرس، لذا يجب أن يسمح UFW بتدفّق UDP عبر المنفذ 1194: ufw allow 1194/udpيجب ضبط سياسة التوجيه في UFW كذلك. يمكنك القيام هذا عبر تعديل ملفّ إعدادات UFW الرئيسي: vim /etc/default/ufwابحث عن DEFAULTFORWARDPOLICY="DROP". يجب تغيير محتوى هذا السطر من DROP إلى ACCEPT. يجب أن يبدو السطر هكذا عندما تنتهي منه: DEFAULT_FORWARD_POLICY="ACCEPT"ثمّ سنقوم بإضافة بعض قواعد UFW الإضافية لترجمة عناوين الشبكة وتذكّر عناوين الـIP الخاصّة بالعملاء الحاليين: vim /etc/ufw/before.rulesقم بجعل بداية ملفّ before.rules الخاصّ بك تبدو هكذا كما بالمثال أدناه. القسم بعد START OPENVPN RULES وقبل END OPENVPN RULES هو ما يجب إضافته: # # rules.before # # Rules that should be run before the ufw command line added rules. Custom # rules should be added to one of these chains: # ufw-before-input # ufw-before-output # ufw-before-forward # # START OPENVPN RULES # NAT table rules *nat :POSTROUTING ACCEPT [0:0] # Allow traffic from OpenVPN client to eth0 -A POSTROUTING -s 10.8.0.0/8 -o eth0 -j MASQUERADE COMMIT # END OPENVPN RULES # Don't delete these required lines, otherwise there will be errors *filterبعدما تمّ تطبيق هذه التغييرات على UFW، يمكننا الآن تفعيله. أدخل اﻷمر التالي في سطر الأوامر: ufw enableوسيتم طباعة الخرج التالي: Command may disrupt existing ssh connections. Proceed with operation (y|n)?للتحقق من حالة قواعد الجدار الناري طبّق: ufw statusوالخرج يجب أن يكون: Status: active To Action From -- ------ ---- 22 ALLOW Anywhere 1194/udp ALLOW Anywhere 22 (v6) ALLOW Anywhere (v6) 1194/udp (v6) ALLOW Anywhere (v6)الخطوة الثانية: إنشاء استيثاق الشهادات و شهادة موقّعة من الخادوم ومفتاح لهايستخدم OpenVPN الشهادات ليقوم بتشفير التدفّق. إعداد وبناء استيثاق الشهاداتالآن هو وقت إعداد استيثاق الشهادات الخاصّ بنا (Certificate Authority - CA) وإنشاء شهادة ومفتاح لخادوم الـOpenVPN. يدعم OpenVPN الاستيثاق ثنائي الاتجاه (bidirectional authentication) باستخدام الشهادات، مما يعني أنّه يجب على العميل أن يقوم باستيثاق شهادة الخادوم ويجب على الخادوم أن يقوم باستيثاق شهادة العميل قبل أن يتم إنشاء الاتصال المشترك بينهما. سنستخدم سكربتات Easy RSA التي نسخناها مبكّرًا للقيام بهذا. أولًا، انسخ سكربتات Easy RSA إلى مكانها: cp -r /usr/share/easy-rsa/ /etc/openvpnثمّ قم بعمل مجلّد لتخزين المفاتيح: mkdir /etc/openvpn/easy-rsa/keysتمتلك Easy-RSA ملفّ متغيّرات يمكننا تعديله لإنشاء شهاداتٍ خاصّة بشخصنا، شركاتنا أو أيّ شيءٍ آخر نريده. يتم نسخ هذه المعلومات إلى الشهادات والمفاتيح، وستساعد هذه المعلومات على التعرّف على المفاتيح لاحقًا: vim /etc/openvpn/easy-rsa/varsالمتغيّرات بين علامتيّ تنصيص (") يجب أن تقوم بتغييرها بناءً على إعداداتك: export KEY_COUNTRY="US" export KEY_PROVINCE="TX" export KEY_CITY="Dallas" export KEY_ORG="My Company Name" export KEY_EMAIL="sammy@example.com" export KEY_OU="MYOrganizationalUnit"في نفس الملفّ vars، قم أيضًا بتعديل السطر الظاهر أدناه، سنستخدم server كاسم المفتاح. إذا أردت استخدام اسمٍ آخر، فسيجب عليك أيضًا تحديث ملفّات إعدادات OpenVPN التي تقوم بالإشارة إلى server.key و server.crt: export KEY_NAME="server"نحتاج إلى إنشاء مُعامِلات Diffie-Hellman; قد يأخذ هذا الأمر بضع دقائق: openssl dhparam -out /etc/openvpn/dh2048.pem 2048الآن فلنغيّر المسارات بحيث نعمل في المسارات الذي نقلنا سكربتات Easy-RSA إليه من قبل في الخطوة الثانية: cd /etc/openvpn/easy-rsaقم بتحليل ملفّ (PKI (Public Key Infrastructure. انتبه إلى النقطة (.) و المسافة (space) قبل الأمر vars/. حيثُ أنّ هذا الأمر قد يغيّر المسار الحالي كلّيًا (المصدر): . ./varsخرج الأمر أعلاه ظاهرٌ أدناه. بما أننا لم نقم بإنشاء أيّ شيء في مجلّد keys بعد، فإنّ رسالة التحذير ليست شيئًا لنقلق حوله الآن: NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keysالآن سنقوم بتنظيف مسار عملنا الحالي من أيّ ملفّات عيّنة مفاتيح أو مفاتيح قديمة لكي تبقى المفاتيح الجديدة بالمسار فقط: ./clean-allسيبني هذا الأمر الأخير استيثاق الشهادات (CA) عبر استدعاء طرفيّة OpenSSL التفاعلية. سيسألك الخرج أن تقوم بتأكيد اسم المتغيرات الفريدة التي أدخلناها من قبل في ملفّ متغيّرات Easy-RSA (اسم البلد، المنظمة.. إلخ): ./build-caاضغط مفتاح Enter ببساطة لتتنقل عبر كلّ طرفية. إذا كان هناك شيءٌ يجب تغييره، فيمكنك القيام بذلك عبر سطر الأوامر. إنشاء شهادة ومفتاح للخادومما زلنا نعمل من المسار /etc/openvpn/easy-rsa ، الآن قم بإدخال الأمر التالي لبناء مفتاح الخادوم. حيث سترى أنّ server هو قيمة المتغيّر export KEY_NAME الذي أعددناه في ملفّ vars الخاصّ بـEasy-RSA من قبل بالخطوة الثانية: ./build-key-server serverيظهر خرج مشابه كالذي يظهر عندما طبّقنا ./build-ca ، ويمكنك مجددًا الضغط على مفتاح Enter لتأكيد كلّ سطرٍ من الأسماء الفريدة. على كلّ حال، هذه المرّة هناك إدخالان إضافيان: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:يجب أن يتم تركهما كلاهما فارغين، لذا فقط اضغط Enter للمتابعة. هناك سؤالان إضافيان في النهاية، وهما يتطلبان إجابة ( y ) إيجابية فقط: Sign the certificate? [y/n] 1 out of 1 certificate requests certified, commit? [y/n]يجب أن يكتمل السؤال الأخير أعلاه بالتالي: Write out database with 1 new entries Data Base Updatedنقل شهادات الخادوم والمفاتيحيتوقّع OpenVPN أن يرى استيثاق شهادات الخادوم، الشهادات والمفاتيح في /etc/openvpn . فلننسخها إلى الموقع الصحيح: cp /etc/openvpn/easy-rsa/keys/{server.crt,server.key,ca.crt} /etc/openvpnيمكنك التحقق من نجاح العملية عبر: ls /etc/openvpnيجب أن ترى ملفّات الشهادات والمفاتيح الخاصّة بالخادوم. في هذه النقطة، أصبح خادوم OpenVPN جاهزًا للانطلاق. شغّله وتحقق من حالته باستخدام: service openvpn start service openvpn statusيجب أن يقوم أمر التحقق من الحالة بإرجاع الخرج التالي لك: VPN 'server' is runningتهانينا! أصبح خادوم OpenVPN الخاصّ بك عاملًا! إذا كانت رسالة الحالة تقول لك أنّ خادوم الـOpenVPN لا يعمل، فتحقق من ملفّ /var/log/syslog وابحث عن أخطاء مثل: Options error: --key fails with 'server.key': No such file or directoryوالتي تقوم أنّ ملفّ server.key لم يتم نسخه إلى المسار etc/openvpn/ بشكلٍ صحيح، مما يتوجب عليك إعادة نسخه مجددًا. الخطوة الثالثة: إنشاء الشهادات والمفاتيح الخاصّة بالعملاءلقد قمنا بتثبيت وإعداد خادوم OpenVPN، أنشأنا استيثاق الشهادات وشهادة ومفتاح الخادوم. في هذه الخطوة الآن، سنستخدم استيثاق شهادات الخادوم لنقوم بإنشاء الشهادات والمفاتيح الخاصّة بجهاز كلّ عميلٍ سيتصل بالخادوم على حدى. سيتم تثبيت هذه الملفّات لاحقًا إلى أجهزة العملاء كالهواتف الذكية والأجهزة المحمولة. بناء المفاتيح والشهاداتمن المناسب أن يمتلك كلّ عميلٍ يتصل بالخادوم شهادته ومفتاحه الخاصّين به. هذا الأمر مفضّل على إنشاء شهادة واحدة ومفتاح واحد وتوزيعهما على جميع أجهزة العملاء لأغراض تتعلق بالأمان. ملاحظة: افتراضيًا، لا يسمح OpenVPN بالاتصالات المتزامنة بنفس الوقت إلى الخادوم من أكثر من جهازٍ عميل باستخدام نفس الشهادة والمفتاح (انظر duplicate-cn في etc/openvpn/server.conf/). لإنشاء شهادات استيثاق منفصلة لكلّ جهاز عميل تنوي السماح له بالاتصال بخادوم الـOpenVPN، يجب عليك إكمال هذه الخطوة لكلّ جهاز، ولكن يمكنك تغيير الاسم client1 أدناه إلى شيءٍ مختلف مثل client2 أو iphone2. بفضل استخدام شهادةٍ منفصلة لكلّ جهاز عميل، يمكن لاحقًا منعهم بشكلٍ منفصل من الوصول إلى الخادوم إذا ما تمّ الاحتياج لذلك. سنستخدم client1 في الأمثلة الموجودة في هذا الدرس كاسم الجهاز العميل. كما فعلنا مع مفتاح الخادوم، فسنقوم الآن ببناء واحد لمثال client1. يجب أن تكون ما زلت تعمل في /etc/openvpn/easy-rsa: ./build-key client1مجددًا، سيتم سؤالك عمّا إذا كنتَ تريد تغيير أو تأكيد متغيّرات الأسماء الفريدة والحقول الإضافية التي تركناها فارغة من قبل. اضغط Enter لاختيار الخيارات الافتراضية: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:وكما في السابق، سيسألك مرتين عن تأكيد بعض الخيارات، اكتب y: Sign the certificate? [y/n] 1 out of 1 certificate requests certified, commit? [y/n]إذا نجحت عملية بناء المفتاح فسيظهر التالي: Write out database with 1 new entries Data Base Updatedيجب على ملفّ عيّنة إعدادات العميل أن يتم نسخه إلى مجلّد Easy-RSA أيضًا. سنستخدمه كقالب يمكن تحميله إلى أجهزة العملاء ليتم تعديله. أثناء عملية النسخ، سنقوم بتغيير اسم ملفّ العيّنة من client.conf إلى client.ovpn لأنّ امتداد ملفّ .ovpn هو ما تتوقع أجهزة العملاء أن تراه باسم الملفّ وليس .conf: cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/easy-rsa/keys/client.ovpnيمكنك تكرار هذا القسم مجددًا لكلّ عميلٍ تريد السماح له بالوصول، ولا تنسى استبدال client1 باسم الجهاز الجديد. نقل الشهادات والمفاتيح إلى أجهزة العميلخلاصة ما طبقّناه أعلاه هو أننا أنشأنا شهادات ومفاتيح العملاء، وأننا قمنا بتخزينها على خادوم OpenVPN في المسار /etc/openvpn/easy-rsa/keys . نحتاج القيام بنقل شهادة العميل، المفتاح وقالب الملفّ الشخصي لكلّ عميلٍ نريد السماح له بالوصول إلى مجلّد محلّي على جهاز الحاسوب الخاصّ بنا أو أيّ جهاز عميل آخر. في هذا المثال، يتطلّب جهاز العميل client1 الشهادات والمفاتيح الخاصّة به والموجودة في المسارات: * /etc/openvpn/easy-rsa/keys/client1.crt * /etc/openvpn/easy-rsa/keys/client1.keyتكون ملفّات ca.crt و client.ovpn هي نفسها لجميع أجهزة العملاء مهما اختلفت. قمّ بتحميل هذه الملفّات أيضًا; لاحظ أنّ ملف ca.crt هو في مسارٍ مختلف عن الملفّات الأخرى: etc/openvpn/easy-rsa/keys/client.ovpn/etc/openvpn/ca.crt/بينما ستعتمد التطبيقات المُستخدمة لإكمال هذه المهمّة على اختيارك ونوع نظام التشغيل الخاصّ بك، فإنّك بحاجة إلى تطبيق يستخدم STFP (بروتوكول نقل الملفّات عبر SSH) أو SCP (النسخ الآمن) للوصول إلى الملفّات الموجودة في خلفية الخادوم. سينقل هذا ملفّات الاستيثاق الخاصّة بخادومك عبر اتصالٍ مشفّر. إليك مثالًا لأمر SCP باستخدام مثالنا من client1. إنّه يقوم بوضع الملفّ client1.key إلى المجلّد Downloads الموجود على حاسوبنا المحلّي: scp root@your-server-ip:/etc/openvpn/easy-rsa/keys/client1.key Downloads/إليك بضع أدوات ودروس يمكنك استخدامها لنقل الملفّات بشكلٍ آمن من الخادوم إلى الحاسوب المحلّي: WinSCPكيفية استخدام SFTP لنقل الملفّات بشكلٍ آمن من خادومٍ بعيد.كيفية استخدام FileZilla لنقل وإدارة الملفّات بشكلٍ آمن.في نهاية هذا القسم، تأكّد أنّ هذه الملفّات الأربعة أصبحت موجودة على جهاز المحلّي مهما كان نوعه: client1.crtclient1.keyclient.ovpnca.crtالخطوة الرابعة: إنشاء ملفٍّ شخصيٍ موحّد لجهاز العميلهناك العديد من الطرق المُستخدمة لإدارة ملفّات العملاء ولكن أسهلها يستخدم ملفّا شخصيًا موحّدًا. يتم إنشاء هذا الملفّ عبر تعديل قالب ملفّ client.ovpn ليتضمّن استيثاق شهادات الخادوم، شهادة العميل والمفتاح الخاصّ به. بمجرّد إضافته، فسيجب حينها فقط استيراد ملفّ client.ovpn إلى تطبيقات OpenVPN على أجهزة العميل. سنقوم بإنشاء ملفٍّ شخصيٍ وحيد لجهازنا المدعو client1 على الحاسوب المحلّي الذي قمنا بتحميل جميع الملفّات إليه. يمكن لهذا الحاسوب المحلّي بنفسه أن يكون جهازًا عميلًا أو مجرّد منطقة عمل مؤقّتة لدمج ملفّات الاستيثاق. يجب أن يتم نسخ قالب ملفّ client.ovpn وإعادة تسميته. كيفية قيامك بهذا الأمر ستعتمد على نظام التشغيل الخاصّة بجهازك المحلّي. ملاحظة: لا يجب على اسم ملفّ client.ovpn الخاصّ بك المنسوخ الجديد أن يكون مطابقًا لاسم جهاز العميل. تطبيق العميل لـOpenVPN سيستخدم اسم الملفّ كمُعرّف لاتصال VPN نفسه، حيث يجب عليك نسخ ملفّ client.ovpn إلى أيّ اسمٍ جديد تريد استخدامه على نظام التشغيل الخاصّ بك. كمثال: work.ovpn سيتم التعرّف عليه كـwork و school.ovpn سيتم التعرّف عليه كـschool. في هذا الدرس، سنقوم بتسمية اتصال VPN كـ HsoubAcademy ولذلك فسيكون اسم الملفّ هو HsoubAcademy.ovpn من الآن فصاعدًا. بمجرّد تسمية الملفّ الجديد المنسوخ، يجب علينا حينها فتح ملفّ HsoubAcademy.ovpn في محرر نصوص. أول نقطة سيقع عليها انتباهك هي مكان عنوان الـIP الخاصّ بخادومك. بالقرب من بداية الملفّ، قم بتغيير my-server-1 إلى عنوان IP الخاصّ بخادومك: # The hostname/IP and port of the server. # You can have multiple remote entries # to load balance between the servers. remote my-server-1 1194الآن، ابحث عن القسم الظاهر أدناه وقم بإلغاء تعليق user nobody و group nobody، كما فعلنا مع ملفّ server.conf في الخطوة الأولى. ملاحظة: هذا لا ينطبق على ويندوز لذا يمكنك تجاوزه. يجب أن يبدو هكذا عندما تنتهي: # Downgrade privileges after initialization (non-Windows only) user nobody group nogroupالقسم الظاهر أدناه يحتاج أن نقوم فيه بتعليق السطور الثلاثة الأخيرة لكي نتمكّن من تضمين الشهادة والمفتاح مباشرةً في ملفّ HsoubAcademy.ovpn، يجب أن يبدو هكذا: # SSL/TLS parms. # . . . #ca ca.crt #cert client.crt #key client.keyلدمج الملفّات المنفصلة إلى ملفٍّ شخصي واحدٍ موحّد، يجب أن يتم وضع محتويات الملفّات ca.crt, client1.crt, و client1.key مباشرةً في ملفّ .ovpn باستخدام هيكلة XML. يجب بالنهاية أن يبدو شكلها كالتالي: <ca> (أدخل محتويات ca.crt هنا) </ca> <cert> (أدخل محتويات client1.crt هنا) </cert> <key> (أدخل محتويات client1.key هنا) </key>عندما تنتهي، يجب أن تبدو نهاية الملفّ كالتالي: <ca> -----BEGIN CERTIFICATE----- . . . -----END CERTIFICATE----- </ca> <cert> Certificate: . . . -----END CERTIFICATE----- . . . -----END CERTIFICATE----- </cert> <key> -----BEGIN PRIVATE KEY----- . . . -----END PRIVATE KEY----- </key>يمتلك ملفّ client1.crt معلوماتٍ إضافية في داخله; لا بأس بتضمين الملفّ بأكمله. احفظ التغييرات واخرج. أصبح لدينا الآن ملفّ واحد موحّد لضبط جهازنا المحلّي client1. الخطوة الخامسة: تثبيت ملفّ العميلالآن سنناقش تثبيت ملفّ VPN على Windows, OS X, iOS, و Android. لا يعتمد أيٌّ من إرشادات هذه الأنظمة على الآخر لذا يمكنك التجاوز إلى الذي يطابق نظامك التشغيلي الحالي فقط. تذكّر أنّ الاتصال سيتم تسميته بحساب اسم ملفّ .ovpn الذي استخدمته. في مثالنا قمنا بتسمية الملفّ كـ HsoubAcademy.ovpn ولذلك سيكون اسم الاتصال هو HsoubAcademy. Windowsالتثبيتيمكن العثور على تطبيق عميل OpenVPN لنظام ويندوز من صفحة التحميلات الخاصّة بـOpenVPN. اختر المُثبّت المناسب لإصدارك من ويندوز. ملاحظة: يتطلّب OpenVPN الصلاحيات الإدارية ليتم تثبيته. بعد تثبيته، انسخ الملفّ HsoubAcademy.ovpn إلى: C:\Program Files\OpenVPN\configعندما تقوم بتشغيل OpenVPN، فسيقوم تلقائيًا برؤية الملفّ وجعله متاحًا. يجب أن يتم تشغيل OpenVPN بصلاحيات المسؤول في كلّ مرّة يتم تشغيله، حتى ولو كان يتم تشغيله على حسابات المستخدمين. لفعل هذا دون الحاجة إلى الضغط على زرّ الفأرة الأيمن واختيار التشغيل كمسؤول في كلّ مرّة تقوم باستعمال الـVPN، يمكنك ضبط هذا الأمر ولكنك ستحتاج إلى القيام به من حساب بصلاحياتٍ إدارية. هذا يعني أيضًا أنّه سيجب على المستخدمين إدخال كلمة مرور المستخدم المدير لاستخدام OpenVPN. على الناحية الأخرى، لن يتمكن المستخدمون من استخدام OpenVPN بشكلٍ صحيح دون أن يتم تشغيله على جهاز العميل بصلاحياتٍ إدارية، لذا فإنّ الصلاحيات الإدارة مطلوبة. لجعل تطبيق OpenVPN يتم تشغيله دومًا كمدير، اضغط بزرّ الفأرة الأيمن على أيقونة الاختصار الخاصّة به واذهب إلى خصائص. في نهاية لسان التوافقية، اضغط على الزرّ لتغيير الإعدادات لجميع المستخدمين. في النافذة الجديدة، اختر تشغيل هذا البرنامج كمدير. الاتصالفي كلّ مرّة تقوم بتشغيل واجهة OpenVPN الرسومية، سيسألك ويندوز عمّا إذا كنتَ تريد السماح للبرنامج بتطبيق التغييرات على نظامك. اضغط على موافق. تشغيل تطبيق عميل OpenVPN سيقوم فقط بوضع الأيقونة في تنبيهات النظام ويمكن الاتصال أو قطع الاتصال بخادوم OpenVPN عند الحاجة; وهو لا يقوم حقيقةً بالاتصال بـ VPN. بمجرّد بدء OpenVPN، قم بإنشاء اتصال عبر الذهاب إلى تنبيهات النظام والضغط بزرّ الفأرة الأيمن على أيقونة OpenVPN. هذا سيفتح لك قائمةً فرعية. اختر HsoubAcademy من أعلى القائمة (والذي هو عبارة عن HsoubAcademy.ovpn) واختر اتصال. سيتم فتح نافذة حالة جديدة تعرض لك الخرج أثناء تأسيس الاتصال، وسيتم طباعة رسالة بمجرّد اكتمال العملية. يمكنك إلغاء الاتصال من VPN بنفس الطريقة: اذهب إلى تنبيهات النظام وانقر بزرّ الفأرة الأيمن على أيقونة OpenVPN واختر قطع الاتصال. OS XالتثبيتTunnelblick هو تطبيق عميل OpenVPN مجاني ومفتوح المصدر لنظام MAC OS X. يمكنك تحميله من صفحة تحميلات Tunnelblick. انقر نقرتين على ملفّ .dmg المحمّل وتابع إرشادات التثبيت. إلى نهاية عملية التثبيت، سيسألك Tunnelblick عمّا إذا كنتَ تمتلك أيّ ملفّات إعدادات. الأسهل حاليًا هو اختيار لا وترك Tunnelblick ليتابع التثبيت. ابحث نافذة Finder وانقر على ملفّ HsoubAcademy.ovpn وسيتم تشغيل Tunnelblick باستخدام ذلك الملفّ، الصلاحيات الإدارية مطلوبة. الاتصالشغّل Tunnelblick عبر النقر مرّتين على مجلّد أيقونة التطبيقات. بمجرّد تشغيل Tunnelblick، سيكون هناك أيقونة Tunnelblick على شريط القائمة في أعلى يمين الشاشة للتحكّم بالاتصالات. اضغط على الأيقونة ومن ثمّ عنصر قائمة اتصال لبدء اتصالٍ جديد واختر HsoubAcademy. iOSالتثبيتمن متجر تطبيقات iTunes، ابحث وثبّت تطبيق OpenVPN Connect، والذي هو تطبيق عميل OpenVPN الرسمي لـiOS. لنقل ملفّ .ovpn الخاصّ بك إلى هاتفك، قم بتوصيله مباشرةً إلى حاسوب. إكمال النقل مع iTunes سيكون خارجيًا هنا. افتح iTunes من على الحاسوب واضغط على iPhone > apps. انتقل إلى الأسفل إلى قسم مشاركة الملفّات وانقر على تطبيق OpenVPN. النافذة الموجودة على اليمين، OpenVPN Documents هي لمشاركة الملفّات. اسحب ملفّ .ovpn وأفلته إلى النافذة أدناه. الآن شغّل تطبيق OpenVPN على iPhone. سيكون هناك إشعار أنّه هناك ملفّ جديد ليتم استيراده. انقر على إشارة الزائد الخضراء ليتمّ ذلك: الاتصالأصبح OpenVPN الآن جاهزًا للاستخدام مع الملفّ الجديد. ابدأ الاتصال عبر النقر على زرّ Connect وجعله On. ويمكنك قطع الاتصال عبر جعله Off. ملاحظة: لا يمكن استخدام محوّل VPN الموجود تحت الإعدادات للاتصال بـVPN. إذا حاولت، فسيصلك إشعار باستخدام تطبيق OpenVPN فقط. Androidالتثبيتافتح متجر Google Play. ابحث عن تطبيق Android OpenVPN Connect وثبّته، إنّه تطبيق OpenVPN الرسمي لأندرويد. يمكن نقل ملفّ .ovpn إلى الهاتف عبر إيصال جهاز الأندرويد الخاصّ بك إلى الحاسوب عبر USB ونقل الملفّ. بشكلٍ مغاير، إذا كنتَ تمتلك قارئ بطاقات SD، فيمكنك إزالة بطاقة SD من الجهاز، نسخ الملفّ إليها ومن ثمّ إدراجها مجددًا إلى جهاز الأندرويد. ابدأ تطبيق OpenVPN وانقر على القائمة للاستيراد: ثمّ تنقّل إلى موقع الملفّ المحفوظ (لقطة الشاشة تستخدم /sdcard/Download/) واختر الملفّ. وسيقوم التطبيق بإخبارك أنّ الملفّ تمّ استيراده: الاتصالللاتصال، قم ببساطة بالضغط على زرّ الاتصال الموجود أمامك. سيتم سؤالك عمّا إذا كنتَ تثق بالتطبيق، اضغط على موافق وتابع. لإلغاء الاتصال، انقر على زرّ قطع الاتصال بالتطبيق. الخطوة السادسة: اختبار اتصالك بـ VPNبمجرّد تثبيت كلّ شيء، يمكن لفحصٍ سريع أن يؤكّد لك أنّك تستعمل VPN الآن أو لا. أولًا قبل استخدام أيّ VPN، اذهب إلى موقع DNSLeakTest. سيعطيك الموقع عنوان الـIP الخاصّ بك عبر مزوّد الإنترنت لديك وستظهر أنت كما تبدو لبقية العالم. للتحقق من إعدادات DNS الخاصّ بك عبر نفس الموقع، انقر على Extended Test وسيخبرك عن خواديم DNS التي تستعملها. الآن، قم بالاتصال بخادوم OpenVPN الموجود على خادومك وحدّث الصفحة. وشاهد عنوان الـIP الجديد المختلف كليًا عن السابق. هذا سيكون هو عنوان الـIP الظاهر للعالم عند تصفّحك لمواقعهم. مجددًا، انقر على Extended Test وسيخبرك عن خواديم DNS التي تستعملها وسيؤكد لك أنّك تستخدم الآن خواديم الـDNS المُعدّة من قبل OpenVPN. تهانينا! يمكنك الآن التنقّل بأمان في الإنترنت وحماية خصوصيتك، موقعك وبياناتك من المراقبة والمُخترقين. ترجمة -وبتصرّف- للمقال: How To Set Up an OpenVPN Server on Ubuntu 14.04.

تمّ تطوير Redis في عام 2009، وهو مُخزّن بيانات بنمط المفتاح والقيمة (key value)، وهو مفتوح المصدر، ويُقدّم مرونة في الاستخدام، وكما في جميع نمط قواعد البيانات من نوع NoSQL الّتي اتبعها Redis، أمثال Cassandra, CouchDB, MongoDB، فإن Redis يَسمح للمُستخدِم بتخزين كميات ضخمة من البيانات بدون التقيد المفروض بقواعد البيانات العلائقيّة/الارتباطيّة (relational database)، بالإضافة إلى أنّه قد تمّ مُشابهته ومقارنته مع memcache، فيُمكن استخدامه بعناصره الأساسية كنظام تخبئة. إعداد بيئة ومتطلبات Redis قبل الشروع في تنصيب redis، يجب توفّر بعض المُتطلّبات والّتي من شأنها أنّ تجعل من عمليّة التنصيب أكثر سهولة. سيتمّ في البداية تحديث جميع حزم apt-get: sudo apt-get update سيتمّ بعد ذلك تحميل مُترجم (compiler) باستخدام الحزمة build-essential، والّتي من شأنها المساعدة في تنصيب Redis من المصدر: sudo apt-get install build-essential سيتمّ في الخطوة الأخيرة تحميل الأداة tcl الّتي يَعتمد عليها Redis: sudo apt-get install tcl8.5 تنصيب Redis بعد أنّ تمّ تنصيب المُتطلّبات الأساسيّة، فمن المُمكن الآن الشروع وتنصيب redis، ويُمكن تحديد الإصدار المطلوب أو تحميل الإصدار الأخير والذي سيحمل دائمًا الاسم redis-stable: wget http://download.redis.io/redis-stable.tar.gz يجب بعد ذلك فك ضغط الملفّ والانتقال إليه: tar xvzf redis-stable.tar.gz cd redis-stable يجب الآن المُتابعة مع الأمر make: make ولتنصيب Redis على كامل النّظام، فيُمكن إما نسخ ملفاته من المصدر: sudo cp src/redis-server /usr/local/bin/ sudo cp src/redis-cli /usr/local/bin/ أو تنفيذ الأمر التّالي: sudo make install بعد انتهاء عمليّة التنصيب، من المُستحسن تشغيل Redis كحارس (daemon) في خلفيّة النّظام، ولعمل ذلك يأتي Redis بملفّ برمجي (سكريبت) لهذه المُهمّة. يجب الانتقال إلى المسار utils للوصول إلى هذا الملفّ: cd utils ومن ثم تشغيل الملفّ الخاص بتوزيعات Ubuntu/Debian: sudo ./install_server.sh سيَعرض السكريبت بعض الأسئلة لإتمام عمليّة التهيئة، ولكن يُمكن الاعتماد على الإعداد الافتراضي والاكتفاء بالضغط على Enter، وبعد انتهاء عملية التهيئة سيكون خادم Redis يعمل في الخلفيّة (background). يُمكن تنفيذ الأمر التّالي للوصول إلى قاعدة البيانات Redis: redis-cli يُمكن اختبار Redis كالتّالي: $ redis-cli redis 127.0.0.1:6379> ping PONG redis 127.0.0.1:6379> set mykey somevalue OK redis 127.0.0.1:6379> get mykey "somevalue" أوامر Redis يتمّ إضافة بعض المُعطيات إلى سلسلة رموز (string)، والّتي تُعتبر من أبسط أنواع البيانات (datatype)، باستخدام الأمر التّالي: > SET users:SomeOne "job: SomeJob, email:example@example.com, age: some number " OK تمّ في الأمر السابق استخدام الأمر SET متبوعًا بالمُفتاح users:SomeOne، ومن ثمّ القيمة (value)، وهي سلسلة الرموز (string) نفسها. لا تُؤثر النقطتان (:) الموجودة في المُفتاح على الأمر السابق، ولكن من المُمكن الاستفادة منهما في وصف أوضح للمُفتاح المُراد تعيينه. يُمكن استعراض تفاصيل سلسلة الرموز السابقة باستخدام الأمر GET: GET users:SomeOne "job: SomeJob, email:example@example.com, age: some number " المجالات (Ranges) يتمّ تحديد مجال باستخدام مُعاملين والذين سيُمثلان العنصر الأوّل والعنصر الأخير، فالعنصر الأوّل سيُعتبر 0، وإن كان المُعامل الأخير -1، فإن جميع العناصر حتّى نهاية القائمة سيتمّ شملها، فعلى سبيل المثال، إن كانت قائمة تحتوي على ألوان قوس قزح مُرتبة بالترتيب ROYGBV، فيُمكن استعراضها كما في التّالي: > LRANGE ROYGBV 0 3 1) "red" 2) "orange" 3) "yellow" 4) "green" > LRANGE ROYGBV 0 -1 1) "red" 2) "orange" 3) "yellow" 4) "green" 5) "blue" 6) "violet" > LRANGE ROYGBV 3 -1 1) "green" 2) "blue" 3) "violet" انتهاء الصلاحية (Expiration) لا يُعتبر Redis ذو فائدة في تخزين المعلومات فقط، بل يُمكن استخدامه أيضًا في إنهاء صلاحيتها. يُعيّن الوقت اللازم على المُفتاح أنّ يتواجد خلاله إما بالثواني أو باستخدام طابع الوقت الخاصّ يونكس (Unix Time stamp)، ويتحكم الأمر EXPIRE بالمُدّة الّتي يتوجب على المُفتاح التواجد فيها، ويَعرض الأمر TTL الوقت المُتبقي حتّى انتهاء الصلاحيّة. > SET classified:information "Secret Stuff" OK > EXPIRE classified:information 45 (integer) 1 > TTL classified:information (integer) 31 وفي مُحاولة لاستعادة المعلومات بعد انقضاء مدّة الصلاحيّة، ستكون النتيجة هي nil: > GET classified:information (nil) التزايد أو العلاوة (Incrementing) يَملك Redis القدرة على زيادة سلاسل الرموز (strings) في قاعدة بياناته، مع الانتباه أنّه في حال وجود عمليّة جارية في زيادة قيمةٍ ما، فلا يستطيع أمر آخر التدخل والتعديل، هذا الأمر من شأنه أن يجعل من قاعدة البيانات ثابتة وغير شائبة. > SET population 6 OK > INCRBY population 10 (integer) 16 > INCR population (integer) 17 المداولات (Transactions) يملك Redis القدرة على إنجاز المُداولات (transactions)، والّتي يجب أنّ تخضع إلى: تنفيذ الأوامر بالترتيب، ولن يتمّ مقاطعتها خلال العمليّة من قبل طلبات أُخرى. على المُداولات أنّ تُعالج كلها دفعةً واحدة. تبدأ المُداولات بالأمر MULTI وبعد ذلك لتنفيذها يتمّ استخدام الأمر EXEC. سيتمّ الخروج من المُداولة، عند أي مُقاطعة للعمليّة، وسيواجه Redis خطًا سيوقفه من إعادة التشغيل حتّى تنفيذ الأمر edis-check-aof ليتمّ التراجع عن المُداولة الجزئية الّتي تمّت بالفعل قبل حدوث الخطأ وحذفها. سيَتمكّن الخادم بعد ذلك من إعادة التشغيل. > MULTI OK > SET population 6 QUEUED > INCRBY population 10 QUEUED > INCR population QUEUED > EXEC 1) OK 2) (integer) 16 3) (integer) 17 أنواع البيانات في Redis يَملك Redis خمسة أنواع من البيانات: Strings Sets Sorted Sets Lists Hashes سلاسل الرموز (Strings) تُعتبر سلاسل الرموز جوهر وأساس الأنواع في Redis الأوامر التّالية هي الأوامر الشائعة مع سلاسل الرموز: SET: يُعيّن قيمة إلى مُفتاح. GET: يجلب قيمة من مُفتاح. DEL: حذف مُفتاح وقيمته. INCR: زيادة قيمة مُفتاح. INCRBY: زيادة قيمة مُفتاح بقيم مُحدّدة. EXPIRE: الوقت اللازم على المُفتاح التواجد به، ويُعيّن بالثواني. تُستخدم سلاسل الرموز في تخزين الكائنات (objects): > SET newkey "the redis string begins" OK > GET newkey "the redis string begins" المجموعات (Sets) يُمكن الجمع بين سلاسل الرموز (strings)، ولذلك يُمكن استخدام مجموعات Redis، والّتي يُمكن القول عنها أنها مجموعة من سلاسل الرموز غير المُرتبة. بعض الأوامر الشائعة مع المجموعات: SADD: إضافة عنصر أو عناصر إلى مجموعة. SMEMBERS: جلب جميع العناصر المُعيّنة. SINTER: إيجاد تقاطع أكثر من مجموعة. SISMEMBER: التأكّد من وجود قيمة في مجموعة. SRANDMEMBER: جلب عنصر عشوائي. يُستفاد من المجموعات في Redis في العديد من الحالات، ولأن كل عنصر من مجموعة هو فريد، فإن إضافة عنصر إلى المجموعة لا يتطلّب عمليّة “افحص قبل الإضافة”، بدلًا من ذلك، فإن المجموعة ستتأكّد فيما إذا كان العنصر مكرّرًا أم لا، وذلك عند أي تنفيذ للأمر SADD: > SADD colors red (integer) 1 redis 127.0.0.1:6379> SADD colors orange (integer) 1 redis 127.0.0.1:6379> SADD colors yellow (integer) 1 redis 127.0.0.1:6379> SADD colors orange (integer) 0 redis 127.0.0.1:6379> SMEMBERS colors 1) "red" 2) "yellow" 3) "orange" يُستفاد من المجموعات بشكل خاصّ في فحص وضبط عناوين IPs في حال أنها فريدة لزوار صفحة ما، أو مثلًا في استخلاص عناصر بشكل عشوائي بالأمر SRANDMEMBER. المجموعات المرتبة (Sorted Sets) إن المجموعات المُرتبة هي اسمٌ على مُسمّى، فهي مجموعة من سلاسل الرموز (strings) مُرتبطة مع رقم مع ترتيب، وهو بشكلٍ افتراضيّ من الأصغر إلى الأكبر. يَعمل هذا النوع من البيانات بشكل مُلائم جدًا مع المجالات (ranges)، وبسبب التّرتيب الخاصّ به، فإن إضافة وحذف وتحديث القيم تتمّ بسرعة ملحوظة. بعض الأوامر الشائعة مع المجموعات المُرتّبة: ZADD: إضافة عناصر إلى مجموعة مُرتّبة. ZRANGE: عرض عناصر مجموعة مُرتّبة. ZREVRANGE: عرض عناصر مجموعة مُرتّبة بشكل عكسي. ZREM: إزالة عناصر من مجموعة مُرتّبة. يُمكن إنشاء مجموعة مُرتّبة كما في المثال التّالي، وهو لمساحة بعض البلدان، فعلى الرغم من تعيينها بشكل عشوائي، فإن استعراضها يَكون على التّرتيب: > ZADD countries 9 Tuvalu (integer) 1 > ZADD countries 62 Liechtenstein (integer) 1 > ZADD countries .7 Monaco (integer) 1 > ZADD countries .2 VaticanCity (integer) 1 > ZADD countries 107 Seychelles (integer) 1 redis 127.0.0.1:6379> ZRANGE countries 0 -1 1) "VaticanCity" 2) "Monaco" 3) "Tuvalu" 4) "Liechtenstein" 5) "Seychelles" القوائم (Lists) تُعتبر القوائم في Redis مجموعة من القيم المُرتّبة، وبالتّالي فهي عكس المجموعات (Sets)، والّتي هي غير مُرتّبة، فيُمكن إضافة عناصر إلى بداية ونهاية قائمة، حتّى بوجود ملايين العناصر داخل القائمة، وبسرعة كبيرة جدًا. الأوامر الأكثر شيوعًا مع القوائم: LPUSH: إضافة قيمة في بداية قائمة. RPUSH: إضافة قيمة في نهاية قائمة. LPOP: جلب وإزالة العنصر الأوّل في قائمة. LREM: إزالة العناصر من قائمة. LRANGE: جلب مجال من العناصر من قائمة. LTRIM: تعديل قائمة بترك عناصر مُحدّدة من مجال. أمثلة: > RPUSH lunch.provider alice (integer) 1 > RPUSH lunch.provider bob (integer) 2 > RPUSH lunch.provider carol (integer) 3 > RPUSH lunch.provider don (integer) 4 > RPUSH lunch.provider emily (integer) 5 عند الرغبة بالدفع (push) إلى واجهة صف الانتظار (queue)، فمن المُمكن استخدام الأمر LPUSH: LPUSH lunch.provider zoe (integer) 6 يُمكن استخدام الأمر LRANGE لاستعراض عناصر القائمة جميعًا: LRANGE lunch.provider 0 -1 1) "zoe" 2) "alice" 3) "bob" 4) "carol" 5) "don" 6) "emily" تُستخدم القوائم في مُعظم الأحيان لإنشاء خط زمني للأحداث، أو في الحفاظ على مجموعة مُحدودة من العناصر المبعثرات (Hashes) تُعتبر المبَعثرات في Redis من الأدوات المُفيدة في تمثيل الكائنات (objects) ذو العديد من الحقول (fields)، فهي مُعدّة لتخزين عدد هائل من الحقول في حجم صغير، وتستطيع البَعثرة تخزين أكثر من أربعة مليارات من أزواج قيم الحقول (field-value). بعض أوامر البعثرة الأكثر شيوعًا في Redis: HMSET: تعيين قيم بعثرة مُتعدّدة. HSET: تعيين حقل البعثرة بقيمة سلسلة رموز (string). HGET: جلب قيمة حقل البعثرة. HMGET: جلب جميع القيم من حقول البعثرة المعطاة. HGETALL: جلب جميع القيم لبعثرة ما. تُستخدم البَعثرة في وصف حساب المُستخدِم: > HMSET user:1 username someuser password 4bAc0s email someuser@example.com OK > HGETALL user:1 1) "username" 2) "jsmith" 3) "password" 4) "4bAc0s" 5) "email" 6) "jsmith@gmail.com" يتمّ استخدام الأمر HMGET للبحث عن معلومة مُحدّدة، وعرض القيم للحقول المطلوبة فقط. > HMGET user:1 username email 1) "someuser" someuser@example.com الختام انتشر Redis بسرعة كبيرة، واكتسب شهرةً واسعة بين المواقع أمثال: Github, Flickr, Disqus، وغيرها من المواقع، وذلك لتوافقه مع مُعظم لغات البرمجة، فهو بالفعل تقنية مُفيدة يُنصح بالاعتماد عليها وتجربتها. ترجمة -وبتصرّف- للمقال How To Install and Use Redis لصاحبته Etel Sverdlov.