عبدالهادي الديوري

الأعضاء
  • المساهمات

    359
  • تاريخ الانضمام

  • تاريخ آخر زيارة

  • Days Won

    19

السُّمعة بالموقع

164 Excellent
  1. بايثون و Django زوج يعدّ بديلا كاملا للغة PHP، حاول تعلّم Django، إن وجدت أنّ تعلّمه صعب، فابدأ بإطار العمل Flask كبداية، فهو أبسط وأقرب إلى البرمجة بلغة بايثون دون إطار عمل. إن أردت تعلّم Flask، فابدأ بهذه الدروس التي كتبتُها، ابدأ من أول درس وأكمل صعودا، السلسة الثّانيّة (ذات الـ24 درسا) بطيئة نوعا ما، لأنّها تشرح الكثير من التّفاصيل التي قد لا تكون مُهمّة في البداية، إلّا أنّها ستكون مُهمّة عند تطوير تطبيق مُعقّد، وتهدف إلى أن تكون بديلا للتوثيقات الأجنبيّة، أي أنّك لا تحتاج إلى حفظ كل شيء في آن واحد، بل هي أقرب إلى المرجع الذي تبحث فيه عمّا تُريده في وقت الحاجة، لذا أنصحك بالصّبر. دروس Flask تشرح الكثير من التّفاصيل الدّقيقة التي ستُفيدك حتى عند انتقالك إلى Django أو لغة برمجة أخرى تتخصّص في تطوير الويب. الخلاصة أنّك لن تخسَر شيئا، سواء تعلّمت Flask أو Django فكلاهما يُغطّي ما تحتاج إليه. انظر الفرق بين Flask و Django.
  2. لغة بايثون لغة شاملة مطلوبة في مجالات عديدة عالميّا، مثل تطوير الويب (من الواجهة الخلفيّة، أي ما يتعلّق بالخوادم وقواعد البيانات)، تحليل البيانات وإدارة الخوادم وحتى تعلّم الآلة إلى غير ذلك من المجالات الجديدة نوعًا ما. ولأنّ هذه المجالات جديدة نسبيا في العالم العربي -عدا تطوير الويب- فمن الطبيعي أن لا تجد ما تُريده. وأتّفق مع مُحمّد في إجابته. لا تهُمّ لغة البرمجة التي تبدأ بها، المُهمّ أن تتعلّم أساسيّات البرمجة وتفهم كيفَ تنشئ تطبيقات بسيطة كخُطوة أولى. بعدها لن تحتاج إلى إجابة لسُؤالِك هذا، لأنّك ستفهم لمَ وكيفَ تستغلّ معرفتك آنذاك. لذا ما دُمتَ بدأت بلغة بايثون، فأنصحك أن تُكمِل فيها إلى أن تتعلّم أساسيّاتها على الأقل، فإن أردت الانتقال إلى لغة أخرى فسيسهُل عليك ذلك. وإن وجدت مشاريع تُريد العمل عليها بلغة بايثون فيما تنفَع فيه (تطوير تطبيقات الويب مثلًا) فافعَل ذلك. وفّقك الله.
  3. مقدّمة من الممكن أن ننخدع بفكرة أنّ الخوادم لن تُهاجَم ما دام الخادوم جديدا، زواره قلائل أو أنّ المخترقين لن يستفيدوا شيئا من اختراقه. لكنّ العديد من الهجمات تكون مُؤتمتة وتُصمَّمُ خصيصا للبحث عن الأخطاء الشّائعة التي تُرتَكب عند ضبط الخادوم. تقوم هذه البرمجيات بفحص الشبكات لاكتشاف الخوادم فقط، ولا تكثرت بمحتواها. تمكين الاتصالات الخارجيّة من أكثر الحالات الشّائعة التي قد تُؤدي إلى وصول غير مُصرّح إلى قاعدة بيانات PostgreSQL. يُمكن أن يحدث هذا لأنّ الإعدادات تسمح للبرمجيات باستكشاف الخوادم الضعيفة بسهولة. في هذا الدّرس، سنلقي نظرة على كيفيّة تقليل خطر الوصول غير المُصرّح الذي يطرحه تفعيل الاتّصالات البعيدة (remote connections). ورغم أنّ هذه خطوة أولى بغاية الأهميّة، وبما أنّ الخوادم قد تتعرّض للاختراق بطرق أخرى، فإنّنا ننصح باتّخاذ إجراءات إضافيّة لحماية بياناتك، والتي يُمكنك أن تجدها في جزء "إجراءات إضافيّة لمزيد من الحماية” من هذا الدّرس. الوضعيّة لفهم الخطر الذي نحاول تخفيفه، تخيّل الخادوم على أنّه متجر صغير. إن كان المتجر يُنصت (listening) على أي منفذ (port)، فهذا يُكافئ قلب لافتة تُشير إلى أنّ المتجر "مفتوح”. أي أنّ الخادوم يكون مرئيّا على الشّبكة، ما يُمكّن البرمجيات المؤتمتة من إيجاده. يُمكننا أن نتخيّل بأنّ كلّ منفذ عبارة عن طريقة للدّخول إلى المتجر، مثل باب أو نافذة مثلا. يُمكن لهذه المداخل أن تكون مفتوحة، مُغلقة، مُقفلة أو مُعطّلة حسب حالة البرمجيّة التي تقوم بالإنصات، لكنّ الإنصات على واجهة عامّة يعني بأنّ البرمجيات الخبيثة تستطيع مُحاولة الدّخول. فمثلا، يُمكن أن تُحاول البرمجيّة استعمال كلمة مرور افتراضيّة على أمل أنّها لم تتغيّر. يُمكن لها كذلك استغلال ثغرات أمنيّة موجودة في البرنامج الذي يُنصِتُ على أمل أنّها لم تُصلَح بعد. يُمكن مُحاولة العديد من الأساليب، إن تمكّنت البرمجيّة الخبيثة من إيجاد نقطة ضعف وقامت باستغلالها، فهذا يعني بأنّ الوصول إلى الخادوم سيتمّ بنجاح وسيتمكّن الهجوم من تخليف خسائر كبيرة. إن قُمنا بتقييد عفريت (daemon) معيّن مثل postgresql ليُنصت محليّا فقط، فهذا مُشابه لمحو الباب الذي يوصل إلى الخارج. ولن يُمكن مُحاولة أي شيء آخر للوصول إلى Postgres. تحمي الجدران النّاريّة (Firewalls) وشبكات VPN بطريقة مُشابهة. في هذا الدّرس، سنُركّز على حذف الباب العمومي الذي يوصل إلى PostgreSQL. لحماية العفريت أو البيانات أثناء نقلها أو تخزينها، انظر فقرة "إجراءات إضافيّة لمزيد من الحماية” من هذا الدّرس. المُتطلّبات سنستعمل في هذا الدّرس خادومي Ubuntu، الأول لمُضيف قاعدة البيانات والآخر ليعمل كعميل يتّصل بالمُضيف عن بُعد. يجب على كلّ خادوم أن يُجهَّز بمُستخدم sudo وجدار ناري مُفعّل. يُمكنك الاستعانة بدرس الإعداد البدئي لخادوم Ubuntu. مُضيف قاعدة البيانات PostgreSQL (Ubuntu 16.04) إن لم تقم بتنصيب PostgreSQL بعد، يُمكنك القيام بذلك باستخدام الأوامر التّاليّة: sudo apt-get update sudo apt-get install postgresql postgresql-contrib آلة العميل (Ubuntu 16.04) لاختبار تمكين الاتصالات البعيدة، سنستعمل عميل PostgreSQL psql. لتنصيبها، استعمل الأوامر التّاليّة: sudo apt-get update sudo apt-get install postgresql-client عند استيفاء هذه المُتطلبات، ستكون جاهزا لاتّباع هذا الدّرس. فهم الإعداد الافتراضيّ عند تنصيب PostgreSQL من مستودع حزم Ubuntu، فالخيار الافتراضيّ هو الانصات على المُضيف المحليّ (localhost). يُمكن تغيير هذا الخيار الافتراضي عبر تعديل مقطع listen_addresses على ملفّ postgresql.conf، لكنّ هذا الإعداد الافتراضي يمنع الخادوم من الانصات آليّا على واجهة عموميّة (public interface). علاوة على ما سبق، فالملفّ pg_hba.conf لا يسمح سوى لاتّصالات من مقابس أسماء نطاقات Unix/Linux (Unix/Linux domain sockets)، وعنوان الاسترجاع (loopback address) الخاصّ بالخادوم المحلي، ما يعني بأنّ الاتّصالات من مُضيفات خارجيّة لن تُقبَل: # Put your actual configuration here # ---------------------------------- # # If you want to allow non-local connections, you need to add more # "host" records. In that case you will also need to make PostgreSQL # listen on a non-local interface via the listen_addresses # configuration parameter, or via the -i or -h command line switches. # DO NOT DISABLE! # If you change this first entry you will need to make sure that the # database superuser can access the database using some other method. # Noninteractive access to all databases is required during automatic # maintenance (custom daily cronjobs, replication, and similar tasks). # # Database administrative login by Unix domain socket local all postgres peer # TYPE DATABASE USER ADDRESS METHOD # "local" is for Unix domain socket connections only local all all peer # IPv4 local connections: host all all 127.0.0.1/32 md5 # IPv6 local connections: host all all ::1/128 md5 هذه الإعدادات الافتراضيّة تُحقّق هدف منع الانصات على واجهة عموميّة. إن تركناها على حالها وأبقينا الجدار النّاري مُفعّلا، فهذا كلّ ما في الأمر! يُمكننا الآن الانتقال إلى قسم "إجراءات إضافيّة لمزيد من الحماية” للتّعرف على كيفيّة حماية البيانات أثناء نقلها. إن أردت الاتصال من مُضيف بعيد، فسنتطرّق إلى كيفيّة تعديل الإعدادات الافتراضيّة إضافة إلى الخطوات التي يجب اتّخاذها فورا لحماية الخادوم في الفقرة التّاليّة. إعداد الاتّصالات البعيدة (Remote Connections) لإعداد بيئة إنتاج قويّة، وقبل بدء العمل مع بيانات حسّاسة، من المُفضّل تشفير مرور (traffic) PostgreSQL باستخدام SSL، إضافة إلى حماية باستخدام جدار ناري خارجي أو شبكة افتراضيّة خاصّة (VPN). قبل القيام بالأمور السابقة ذكرها، يُمكننا اتّخاذ طريق أقل تعقيدا عبر تفعيل جدار ناريّ على خادوم قاعدة البيانات الخاص بنا وتقييد الوصول لتقبل فقط المُضيفات التي تحتاج إلى الوصول إلى الخادوم. الخطوة الأولى – إضافة مُستخدم وقاعدة بيانات سنبدأ بإضافة مُستخدم وقاعدة بيانات لأغراض تجريبيّة. للقيام بذلك، سنستعمل عميل PostgreSQL psql للاتصال بصفة المُستخدم الإداري postgres. عبر تمرير الخيار -i للأمر sudo سيتمّ تشغيل صدفة تسجيل الدّخول (login shell) الخاصّة بالمُستخدم postgres، ما يضمن بأنّ الخيارات في ملفّ .profile أو في موارد أخرى مُتعلّقة بتسجيل الدّخول ستُحمَّل. يقوم الخيار -u بتحديد المُستخدم postgres: sudo -i -u postgres psql بعدها، سنقوم بإنشاء مُستخدم بكلمة مرور. تأكّد من استعمال كلمة مرور جيّدة عوضا عن المقطع mypassword في المثال أسفله: CREATE USER sammy WITH PASSWORD 'mypassword'; إن تمّ إنشاء المُستخدم بنجاح، فسنستقبل المُخرج التّالي: CREATE ROLE مُلاحظة: منذ الإصدار 8.1 من PostgreSQL، فالأدوار (ROLES) والمُستخدمون (USERS) يشتركون في المعنى.لكنّ هناك اتّفاقا يقول بأنّه إن كان لدور كلمة مرور فإنّنا نُسمّيه مُستخدما، ونُسمّي الدّور عديم كلمة المرور دورا، لذا أحيانا ستحصل على ROLE في المُخرج رغم أنّك تتوقّع أن ترى USER. تاليّاََ، سنُنشئ قاعدة بيانات وسنمنح كامل صلاحيّات الوصول لمُستخدمنا الجديد. تقول أفضل الممارسات بمنح المُستخدمين صلاحيّات الوصول التي يجتاجونها فقط، وعلى الموارد التي يجب أن يحصلوا عليها فقط، لذا فاعتمادا على حالة الاستخدام ( use case)، قد يُفضّل تقييد أحقيّة الوصول للمُستخدم. . CREATE DATABASE sammydb OWNER sammy; عند إنشاء قاعدة البيانات بنجاح، سنستقبل التّأكيد التّالي: CREATE DATABASE بعد إنشاء المُستخدم وقاعدة البيانات، سنقوم بالخروج من سطر أوامر PostgreSQL: \q بعد الضغط على مفتاح ENTER، سنرجع إلى سطر الأوامر وسنكون جاهزين للمُتابعة. الخطورة الثّانيّة – إعداد UFW في درس الإعداد البدئي لخادوم Ubuntu ، قمنا بتفعيل UFW وسمحنا لاتّصالات SSH فقط. قبل بدء الإعداد، لنتحقّق من حالة UFW: sudo ufw status مُلاحظة: إن كان المخرج يدُلّ على أنّ الجدار النّاري غير مُفعّل (inactive)، يُمكننا تفعيله بالأمر التّالي: sudo ufw enable بعد التّفعيل، فإنّ إعادة تنفيذ الأمر sudo ufw status سيستعرض القواعد الحاليّة. فعّل SSH إن كان ذلك مطلوبا: sudo ufw allow OpenSSH في حالة لم تُغيِّر من المُتطلّبات، فمُخرج الأمر sudo ufw status سيُشير إلى أنّ OpenSSH هي الخدمة الوحيدة المُفعّلة: Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) بعد التّحقّق من حالة الجدار النّاري، سنقوم بالسماح بالوصول إلى منفذ PostgreSQL وسنُقيّد الوصول لنسمح فقط للمُضيف أو المُضيفات المرغوبة. سيُضيف الأمر أسفله قاعدة للمنفذ الافتراضيّ لـPostgreSQL، أي المنفذ رقم 5432. إن غيّرت هذا المنفذ، فتأكّد من تعديل الأمر أسفله. تأكّد من استعمال عنوان IP الخاص بالخادوم الذي يحتاج إلى الوصول. أعد تنفيذ الأمر لإضافة كلّ عميل من العملاء الذين ترغب بإعطائهم أحقيّة الوصول إن كان ذلك لازما: sudo ufw allow from client_ip_address to any port 5432 استبدل client_ip_address بعنوان IP الخاصّ بالعميل. للتّحقّق من أنّ القاعدة قد طُبِّقت، يُمكنك تنفيذ الأمر ufw status مُجدّدا: sudo ufw status المُخرج: To Action From -- ------ ---- OpenSSH ALLOW Anywhere 5432 ALLOW client_ip_address OpenSSH (v6) ALLOW Anywhere (v6) مُلاحظة: إن لم تكن لديك دراية مُسبقة بأساسيّات UFW، يُمكنك تعلّم المزيد في درس أساسيات UFW: قواعد وأوامر شائعة للجدار الناري . بعد تجهيز قاعدة الجدار النّاريّ هذه، سنقوم الآن بإعداد PostgreSQL لتُنصت على عنوان IP العمومي. سنقوم بهذا عبر تعديل إعدادَيْن، خانة للمُضيف المُتصل في pg_hba.conf وإعداد listen_addresses في postgresql.conf. الخطوة الثّالثة – إعداد المُضيفات المسموح لها (Allowed Hosts) سنبدأ عبر إضافة خانة المُضيف في ملفّ pg_hba.conf. إن كنت تستعمل نسخة أخرى غيْرَ النُّسخةِ 9.5 من PostgreSQL فتأكّد من تعديل الأمر أسفله قبل تنفيذه: sudo nano /etc/postgresql/9.5/main/pg_hba.conf سنضع أسطر host تحت مقطع التّعليقات الذي يصف كيفيّة السّماح للاتصالات غير المحليّة. سنُضيف سطرا يحمل العنوان العمومي الخاص بخادوم قاعدة البيانات لاختبار ما إذا كان الجدار النّاري مُعدّا بشكل صحيح. استبدل المقطع client_ip_address بعنوان IP الخاص بآلة العميل الخاصّ بك: # If you want to allow non-local connections, you need to add more # "host" records. In that case you will also need to make PostgreSQL # listen on a non-local interface via the listen_addresses # configuration parameter, or via the -i or -h command line switches. host sammydb sammy client_ip_address/32 md5 قبل حفظ التغييرات، لننظر إلى كل قيمة من قيم السّطر الذي أضفناه في حالة كنت ترغب تعديل أي منها: المُضيف، المُعامل host يُحدّد بأنّ اتّصال TCP/IP سيُستَعمَل. قاعدة البيانات، العمود الثّاني، sammydb، يُحدّد أي قاعدة بيانات يُمكن للمُضيف أن يتّصل بها، يُمكنك تعيين أكثر من قاعدة بيانات واحدة عبر تفرقة أسمائها بالفاصلة ,. المُستخدم، sammy، يُحدّد المُستخدم المسموح له بالاتّصال. وكما مع عمود قاعدة البيانات، فتستطيع تحديد أكثر من مستخدم واحد باستعمال علامة الفاصلة. العنوان، يُحدّد عنوان آلة العميل ويُمكن أن يكون عبارة عن اسم مُضيف (hostname)، مجال عناوين IP (IP address range) أو كلمات مفتاحيّة خاصّة. في المثال أعلاه، قمنا بالسماح لعنوان IP الخاصّ بالعميل فقط. طريقة الاستيثاق (auth-method)، في الأخير، يُمكن تحديد طريقة استيثاق، يُشير md5 إلى كلمة مرور مزدوجة التّشفير بـMD5 ( double-MD5-hashed password ) لن تحتاج سوى كلمة المرور التي تم إنشاؤها للمُستخدم الذي سيقوم بالاتّصال. للمزيد من المعلومات وإعدادات إضافيّة راجع التوثيق الرّسمي لـPostgreSQL حول ملفّ pg_hba.conf. بعد الانتهاء من التّعديلات، احفظ وأغلق الملف. الخطوة الرّابعة – إعداد عنوان الإنصات (Listening Address) سنقوم الآن بضبط عنوان الإنصات في ملفّ postgresql.conf (تأكّد من تصحيح رقم النّسخة): sudo nano /etc/postgresql/9.5/main/postgresql.conf أضف عناوين الإنصات تحت سطر listen_addresses، تأكّد من استبدال server_ip_address بعنوان IP أو اسم مُضيف قاعدة البيانات الخاصّة بك وليس عنوان العميل الذي سيقوم بالاتصال: #listen_addresses = 'localhost' # what IP address(es) to listen on; listen_addresses = 'localhost,server_ip_address' احفظ وأغلق الملفّ عند الانتهاء من إجراء التّعديلات. الخطوة الخامسة – إعادة تشغيل PostgreSQL لن تُطبَّق التعديلات حتى نُعيد تشغيل عفريت (daemon) PostgreSQL، لذا سنقوم بهذا قبل أن نبدأ بالتجربة: sudo systemctl restart postgresql وبما أنّ systemctl لا يوفّر تغذيّة راجعة (feedback)، فسنتحقّق من نجاح إعادة تشغيل العفريت: sudo systemctl status postgresql إن احتوى المُخرج على Active: active وانتهى بمقطع مُشابه لما يلي، فهذا يعني بأنّ عفريتPostgreSQL مُفعّل. ... Jan 10 23:02:20 PostgreSQL systemd[1]: Started PostgreSQL RDBMS. بعد إعادة تشغيل العفريت، يُمكننا الآن التّجربة. الخطوة السّادسة – تجربة الاتّصال لنتحقّق من أنّنا نستطيع الاتّصال من جهاز العميل الخاص بنا. للقيام بهذا، سنستعمل الأمر psql مع الخيّار -U لتحديد المُستخدم، الخيار -h لتحديد عنوان IP الخاصّ بالعميل و -d لتحديد قاعدة البيانات، وذلك لأنّنا ضيّقنا الحماية لكي يتمكّن sammy فقط من الاتّصال بقاعدة بيانات واحدة فقط. psql -U sammy -h postgres_host_ip -d sammydb استبدل postgres_host_ip بعنوان IP الخاصّ بمُضيف PostgreSQL. إن تمّ إعداد كل شيء بشكل صحيح، فيجب أن تستقبل المحثَّ (prompt) التّالي: Password for user sammy: أدخل كلمة المرور التّي حدّدتها مسبقا عندما أضفت المُستخدم sammy في مرقاب (monitor) PostgreSQL. إن حصلت على المحثّ التّالي، فهذا يعني بأنّ الاتصال قد تمّ بنجاح: sammydb=> هذا يُؤكّد على أنّنا نستطيع تجاوز الجدار النّاري وأن نتّصل بقاعدة البيانات. سنقوم الآن بالخروج من المحثّ: \q بعد التّحقّق من أنّ الإعدادات قد ضُبِطت بنجاح، سنقوم بتنظيف مُخلّفات التّجربة. الخطوة السّابعة – حذف قاعدة البيانات والمُستخدم التّجريبيّين بعد اختبار الاتّصال، يُمكننا الآن العودة إلى المُضيف واستخدام الأمر التّالي لحذف قاعدة البيانات والمُستخدم. sudo -i -u postgres psql لحذف قاعدة البيانات: DROP DATABASE sammydb; عند نجاح العمليّة، ستستقبل المُخرج التّالي: DROP DATABASE لحذف المُستخدم: DROP USER sammy; المُخرج عند نجاح العمليّة: DROP ROLE سنقوم بإنهاء عمليّة التّنظيف بحذف خانة المُضيف الخاصّة بقاعدة البيانات sammydb من ملفّ pg_hba.conf لأنّنا لم نعد نحتاج إليها: sudo nano /etc/postgresql/9.5/main/pg_hba.conf استبدل 9.5 برقم النّسخة الخاصّة بك. السّطر الذي يجب عليك حذفه: host sammydb sammy client_ip_address/32 md5 ليُطبَّقَ التّعديل، سنقوم بحفظ وإغلاق الملفّ ومن ثمّ نُعيد تشغيل خادوم قاعدة البيانات: sudo systemctl restart postgresl للتحقّق من أنّ إعادة التّشغيل قد تمّت بنجاح، سنطّلع على الحالة: sudo systemctl status postgres إن كان المُخرج يحتوي على Active: active فهذا يعني بأنّ إعادة التّشغيل قد تمّت بنجاح. يُمكنك الآن ضبط التّطبيق أو الخدمة على العميل التي تحتاج إلى إمكانيّة الاتصال عن بعد. خاتمة اتّخذنا في هذا الدّرس الخطوات الأساسيّة لحماية PostgreSQL عبر إعداد الجدار النّاريّ الخاصّ بالخادوم ليسمح فقط للاتصالات من المُضيفات التي تحتاج إلى صلاحيّات الوصول وعبر ضبط PostgreSQL لتقبل الاتصالات من هذه المُضيفات فقط. هذا يُخفّف من خطر بعض من أنواع الهجمات. تعتبر هذه الإجراءات الخطوة الأولى فقط لحماية البيانات، وننصح بمراجعة واتّخاذ الإجراءات الأمنية الإضافيّة المذكورة أعلاه. ترجمة -بتصرّف- للمقال How To Secure PostgreSQL Against Automated Attacks لصاحبته Melissa Anderson.
  4. كتبت مؤخّرا برنامج Bash قصير لنسخ ملفّات MP3 من مفتاح USB من مُضيف شبكة (network host) إلى مُضيف شبكة آخر. تُنسَخ الملفّات إلى مجلّد خاصّ على خادوم أقوم بتشغيله لمؤسّسة تطوعيّة، ما يسمح بتشغيل وتنزيل الملفّات. يقوم برنامجي ببضعة أمور أخرى، مثل تعديل أسماء الملفّات قبل نسخها لتكون مرتّبة تلقائيّا حسب التّاريخ على صفحة الويب. كما تحذف جميع الملفّات على مفتاح USB بعد التّأكد من اكتمال النّقل بنجاح. يأتي هذا البُريْمِج ببضعة خيارات، مثل -h لعرض المُساعدة، و -t لنمط الاختبار (test mode) وبضعة خيارات أخرى. رغم أنّ برنامجي الصغير هذا جميل، إلّا أنّه يحتاج إلى تشغيله بالمُستخدم الجذر (root) للقيام بالعمليّات الأساسيّة. للأسف، لا تمتلك هذه المؤسّسة أشخاصا مهتمين بإدارة أنظمة الحواسيب، ما يدفعني للبحث عن أشخاص بقدرات تقنيّة متواضعة لتدريبهم على كيفيّة تسجيل الدّخول إلى الحاسوب الذي يعمل على نقل الملفّات وتشغيل هذا البرنامج. صحيح بأنّني أستطيع تشغيل البرنامج بنفسي، إلّا أنّ بضعة أسباب (كالمرض والسّفر) قد تحول دون ذلك. وحتى لو كنتُ متاحا، فبصفتي مدير نُظم كسول، أحب أن يقوم الآخرون بعملي من أجلي. لذا أكتب برامج لأتمتة (automate) هذه المهام وأستعمل Sudo لتمكين بضعة مُستخدمين من تشغيل البرامج.يتطلّب تنفيذ العديد من أوامر Linux صلاحيّات المُستخدم الجذر. هذا يحمي النظام من التخريب الخبيث أو غير المقصود. استعمال أداة Sudo يُمكنّ برنامج sudo مدراء النّظم ذوي صلاحيّات الجذر من تفويض المسؤوليّة لبضعة مهام أو جميعها لمستخدمين آخرين لنفس الحاسوب. كما يسمح لي بتنفيذ هذا التفويض دون توفير كلمة مرور المُستخدم الجذر، ما يوفّر مستوى عاليّا من الحماية على المُضيف. لنفترض على سبيل المثال بأنّني أعطيت للمُستخدم ruser أحقيّة الوصول إلى برنامج Bash خاص بي باسم myprog، والذي يحتاج إلى صلاحيّات المستخدم الجذر لتنفيذ بعض من وظائفه. يقوم المستخدم ruser بتسجيل الدّخول أولا باستعمال كلمة المرور الخاصّة به، وبعدها ينفّذ الأمر التّالي لتشغيل myprog. sudo myprog يقوم برنامج sudo بالاطّلاع على الملفّ /etc/sudoers ويتحقّق من أنّ لـruser إذنا يُمكّنه من تشغيل myprog. إن كان الأمر كذلك، يطلب sudo من المُستخدم كلمة مروره -وليس كلمة مرور المُستخدم الجذر-، بعد إدخال كلمة المرور، يتمّ تنفيذ البرنامج. يقوم sudo كذلك بتسجيل معلومات الوصول إلى myprog مع التاريخ والوقت الذي تمّ فيه تشغيل البرنامج إضافة إلى سطر الأمر والمُستخدم الذي قام بتنفيذه. تُسجّل هذه البيانات في ملفّ /var/log/security. أجد بأنّ سجلّ الأوامر التي تم تنفيذها مفيد عند التّدريب. إذ يسمح لي هذا بالتعرّف على من قام بماذا وما إن أدخل الأمر بشكل صحيح. قمت باستخدام هذه الميّزة لتفويض الصلاحيّات لي ولمُستخدم آخر للتمكّن من تشغيل برنامج واحد؛ لكن لـsudo إمكانيّات أكبر من ذلك. إذ يسمح لمدير النظام بتفويض السُّلطَة لإدارة وظائف الشّبكة أو خدمات مُعيّنة لشخص واحد أو مجموعة من المُستخدمين الموثوقين. يُمكّن هذا من تفويض أحقيّة تشغيل هذه الوظائف ويحمي كلمة مرور المُستخدم الجذر في نفس الوقت. ضبط ملفّ sudoers بصفتي مدير نُظم، يُمكنني استعمال ملفّ /etc/sudoers للسماح للمستخدمين أو مجموعات من المُستخدمين بالوصول إلى أمر مُعيّن، مجموعة محدّدة من الأوامر أو جميع الأوامر. هذه المرونة هي سرّ كل من قوّة وبساطة استعمال sudo للتفويض. بدا لي ملفّ sudoers معقّدا في البداية، لذا نسختُ وحلّلت ملفّ sudoers بالكامل من المُضيف الذي أستخدمه. على أمل أن تفهم الأساسيّات بعد قراءة هذا التّحليل. وجدت كذلك بأنّ ملفّات الإعدادات الافتراضيّة في التوزيعات المبنيّة على Red Hat تحتوي على الكثير من التّعليقات والأمثلة التي تُسهّل المأموريّة. لا تستعمِل محرّر النصوص الاعتياديّ عند تعديل ملفّ sudoers. استعمل الأمر visudo لتطبيق التّغييرات حالما تحفظ الملفّ وتخرجُ من المُحرّر. يُمكن استعمال محرّرات أخرى عوضا عن Vi بنفس الشكل الذي نستعمل فيه visudo. لنبدأ بتحليل هذا الملفّ من البداية مع بضعة أنواع من الأسماء المُستعارة (aliases). الأسماء المُستعارة الخاصّة بالمُضيفات Host aliases يُستعمل جزء الأسماء المُستعارة الخاصّة بالمُضيفات لإنشاء مجموعات من المُضيفات التي يُمكن عليها استعمال الأوامر أو الأسماء المستعارة للأوامر لمنح أحقيّة الوصول. الفكرة أن يُصان (maintain) هذا الملفّ الوحيد من أجل جميع المُضيفات في المؤسّسة ويُنسخ إلى مُجلّد /etc الخاص بكل مُضيف. وبالتالي يُمكن ضبط بعض المُضيفات (مثل الخوادم) لتُشكّل مجموعة لمنح بعض المُستخدمين أحقيّة الوصول إلى أوامر مُخصّصة، مثل إمكانيّة تشغيل أو إيقاف خدمات مثل HTTPD، DNS والتشبيك (networking) أو وصل (mount) أنظمة الملفّات وما إلى ذلك. يُمكن استعمال عناوين IP عوضا عن أسماء المُضيفات في الأسماء المُستعارة الخاصّة بالمُضيفات. ## Sudoers allows particular users to run various commands as ## the root user, without needing the root password. ## ## Examples are provided at the bottom of the file for collections ## of related commands, which can then be delegated out to particular ## users or groups. ## ## This file must be edited with the 'visudo' command. ## Host Aliases ## Groups of machines. You may prefer to use hostnames (perhaps using ## wildcards for entire domains) or IP addresses instead. # Host_Alias FILESERVERS = fs1, fs2 # Host_Alias MAILSERVERS = smtp, smtp2 ## User Aliases ## These aren't often necessary, as you can use regular groups ## (ie, from files, LDAP, NIS, etc) in this file - just use %groupname ## rather than USERALIAS # User_Alias ADMINS = jsmith, mikem User_Alias AUDIO = dboth, ruser ## Command Aliases ## These are groups of related commands... ## Networking # Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, /sbin/dhclient, /usr/bin/net, /sbin/iptables, /usr/bin/rfcomm, /usr/bin/wvdial, /sbin/iwconfig, /sbin/mii-tool ## Installation and management of software # Cmnd_Alias SOFTWARE = /bin/rpm, /usr/bin/up2date, /usr/bin/yum ## Services # Cmnd_Alias SERVICES = /sbin/service, /sbin/chkconfig ## Updating the locate database # Cmnd_Alias LOCATE = /usr/bin/updatedb ## Storage # Cmnd_Alias STORAGE = /sbin/fdisk, /sbin/sfdisk, /sbin/parted, /sbin/partprobe, /bin/mount, /bin/umount ## Delegating permissions # Cmnd_Alias DELEGATING = /usr/sbin/visudo, /bin/chown, /bin/chmod, /bin/chgrp ## Processes # Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/kill, /usr/bin/killall ## Drivers # Cmnd_Alias DRIVERS = /sbin/modprobe # Defaults specification # # Refuse to run if unable to disable echo on the tty. # Defaults !visiblepw Defaults env_reset Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS" Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE" Defaults env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES" Defaults env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE" Defaults env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY" Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin ## Next comes the main part: which users can run what software on ## which machines (the sudoers file can be shared between multiple ## systems). ## Syntax: ## ## user MACHINE=COMMANDS ## ## The COMMANDS section may have other options added to it. ## ## Allow root to run any commands anywhere root ALL=(ALL) ALL ## Allows members of the 'sys' group to run networking, software, ## service management apps and more. # %sys ALL = NETWORKING, SOFTWARE, SERVICES, STORAGE, DELEGATING, PROCESSES, LOCATE, DRIVERS ## Allows people in group wheel to run all commands %wheel ALL=(ALL) ALL ## Same thing without a password # %wheel ALL=(ALL) NOPASSWD: ALL ## Allows members of the users group to mount and unmount the ## cdrom as root # %users ALL=/sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom ## Allows members of the users group to shutdown this system # %users localhost=/sbin/shutdown -h now ## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment) #includedir /etc/sudoers.d ################################################################################ # Added by David Both, 11/04/2017 to provide limited access to myprog # ################################################################################ # AUDIO guest1=/usr/local/bin/myprog الأسماء المستعارة الخاصّة بالمُستخدمين User aliases تُعطي الأسماء المستعارة الخاصّة بالمُستخدمين إمكانيّة ترتيب المُستخدمين إلى مجموعات ذات أسماء مُستعارة للمُستخدم الجذر، بهذه الطّريقة ستتمكّن مجموعة كاملة من المستخدمين من الوصول إلى صلاحيات مدير محدّدة. هذا هو الجزء الذي أضَفْتُ فيه السّطر User_Alias AUDIO = dboth, ruser، والذي يقوم بتعيين مُستخدمَيْنِ للاسم المُستعار AUDIO. يُمكن الاعتماد على المجموعات المنشأة مُسبقا في ملفّ /etc/groups عوضا عن الأسماء المستعارة. إن كانت أحد المجموعات في هذا الملفّ تفي بالغرض، مثل مجموعة audio فيُمكنك استخدام اسم المجموعة مسبوقا بعلامة % كما يلي: %audio عند تعيين الأوامر التي ستُوفَّرُ للمجموعات في ملفّ sudoers. الأسماء المستعارة للأوامر Command aliases في جزء الأسماء المستعارة للأوامر، نقوم بتوفير قائمة للأوامر ذات الصّلة، مثل أوامر التّشبيك أو الأوامر التي تقوم بتنصيب التّحديثات أو حزم RPM جديدة. تُمكّن هذه الأسماء المستعارة مدير النّظام من منح تصريح للوصول إلى مجموعة من الأوامر. تم مُسبقا إعداد عدد من هذه الأسماء المستعارة في هذا الجزء، ما يجعل تفويض أحقية الوصول لنوع محدد من الأوامر أمرا سهلا. القيم الافتراضيّة للبيئة Environment defaults يقوم الجزء التّالي بتعيين عدد من متغيّرات البيئة (environment variables). أكثر سطر مثير للاهتمام في هذا الجزء هو السّطر !visiblepw، والذي يمنع تشغيل sudo إن كانت بيئة المُستخدم تسمح بعرض كلمة المرور. هذا إجراء وقائي لا يجب تعديله. قسم الأوامر Command section قسم الأوامر هو الجزء الرّئيسي في ملفّ sudoers. يمكن القيام بأي شيء ترغب به دون الحاجة إلى الأسماء المستعارة عبر إضافة خانات هنا. لكنّ الأسماء المستعارة تجعل الأمر في غاية السّهولة. يقوم هذا القسم باستخدام الأسماء المُستعارة التي تم تعريفها أعلاه لإخبار sudo من لديه الحقّ للقيام بماذا وعلى أي مُضيف. الأمثلة تشرح نفسها ما دمت تفهم القواعد (Syntax) في هذا القسم. لننظر إلى القواعد في قسم الأوامر: ruser ALL=(ALL) ALL المثال أعلاه يقول بأنّ للمُستخدم ruser صلاحيات تُمكّنه من تنفيذ أي برنامج على أي مُضيف بصفة أي مُستخدم. هذه خانة عامّة للمُستخدم ruser. المقطع ALL الأول يدلّ على أنّ هذه القاعدة تُطبَّق على جميع المُضيفات. ALL الثّانيّة تسمح لـruser بتنفيذ الأوامر بصفة أي مُستخدم آخر. افتراضيّا، تُنفَّذُ الأوامر بصفة المُستخدم الجذر، لكنّ لـruser القدرة على انتحال صفة أي مُستخدم آخر عند استعمال الأمر sudo. المقطع ALL الأخير يعني بأنّ ruser يستطيع تنفيذ جميع الأوامر دون أية قيود. ما يمنح لـruser جميع صلاحيّات المُدير. لاحظ الخانة التي تمنح للمُستخدم root جميع صلاحيات الوصول لجميع الأوامر على جميع المُضيفات: root ALL=(ALL) ALL لتجربة هذا، قمت بتعليق (comment) السّطر أعلاه وحاولتُ تنفيذ الأمر chown بصفة المُستخدم الجذر دون sudo. تمّ تنفيذ الأمر. بعدها حاولت استخدام الأمر sudo chown، والذي فشل مع الرّسالة root غير موجود على ملفّ sudoers. سيتم الإبلاغ عن هذه الحادثة. ما يعني بأنّ المُستخدم الجذر قادر على تنفيذ أي أمر بصفته المُستخدم الجذر، لكن أي أمر سيفشل عند استعمال الأمر sudo. سيمنع هذا المُستخدمَ الجذر من تنفيذ أية أوامر بصفته مُستخدما آخر عبر الأمر sudo. لكنّ root يستطيع التحايل على هذا القيد بالعديد من الطّرق. الشّيفرة أسفله هي ما أضفته للتحكم بأحقية الوصول إلى برنامج myprog. يقول السّطر بأنّ المستخدمين الذين ينتمون إلى المجموعة AUDIO التي تم تعريفها أعلى الملفّ لديهم أحقيّة الوصول إلى برنامج واحد فقط (myprog) على مُضيف واحد (guest1). AUDIO guest1=/usr/local/bin/myprog سيُمكّن السّطر أعلاه المستخدمين المنتمين إلى مجموعة AUDIO من الوصول إلى البرنامج myprog على المُضيف guest1. لاحظ بأنّ السّطر أعلاه لا يُحدّد سوى المُضيف الذي يُمكن عليه تنفيذ البرنامج. ولا يُحدّد بأنّ للمُستخدم حريّة تنفيذ الأمر بصفة أي مُستخدم آخر. تجاوز كلمات المرور يُمكنك استخدام الكلمة المفتاحيّة NOPASSWORD لتمكين المُستخدمين المنتمين إلى المجموعة AUDIO من تشغيل برنامج myprog دون الحاجة إلى إدخال كلمة المرور الخاصّة بهم كما يلي: AUDIO guest1=NOPASSWORD : /usr/local/bin/myprog لم أُفعِّل هذا الخيار لبرنامجي، إذ يجب على مُستخدمي sudo التوقف والتفكير في ما يقومون به، وهذا يُساعد قليلا على ذلك. والسّطر أعلاه مُجرّد مثال توضيحيّ. المجموعة wheel معيار wheel المُحدّد في جزء الأوامر داخل ملفّ sudoers (كما هو موضّح أسفله) يقوم بالسماح لجميع المُستخدمين المُنتمين إلى المجموعة wheel بتنفيذ جميع الأوامر على أي مُضيف. تُعرَّف مجموعة wheel على الملفّ /etc/group، ومن الواجب إضافة المُستخدمين هناك. علامة % التي تسبق اسم المجموعة تعني بأنّ على sudo البحث عن هذه المجموعة في ملفّ /etc/group. %wheel ALL = (ALL) ALL يسمح السّطر أعلاه لجميع المُستخدمين الذين ينتمون إلى المجموعة wheel المعرّفة في ملفّ /etc/group بتشغيل جميع الأوامر على أي مُضيف. هذه طريقة جيّدة لتفويض كامل صلاحيّات المُستخدم الجذر لعدّة مُستخدمين دون توفير كلمة المرور الخاصّة بالمُستخدم الجذر. مجرّد إضافة مُستخدم إلى مجموعة wheel يُعطيهم كامل إمكانيّات المُستخدم الجذر. يسمح هذا كذلك بمُراقبة نشاطات المُستخدمين عبر مُدخلات التّسجيلات التي يقوم sudo بإنشائها. تُضيف بعض التوزيعات (مثل توزيعة Ubuntu) مُعرّفات المُستخدمين (user ID) إلى المجموعة wheel في ملفّ /etc/group، ما يسمح لهم باستخدام sudo لتنفيذ جميع الأوامر التي تتطلّب صلاحيّات المُستخدم الجذر. ختاما استعملت sudo هنا لغرض محدود (تمكين مستخدم أو مُستخدمَيْن من الوصول إلى أمر واحد). تمكّنت من تحقيق هذا الغرض عبر كتابة سطرَيْن فقط (دون احتساب التّعليقات). تفويض صلاحيات تنفيذ مهام مُحدّدة لمُستخدمين لا يمتلكون إمكانيّة الوصول إلى المستخدم الجذر عمليّة بسيطة يُمكن لها اقتصاد كم جيّد من الوقت لمُدير النظم. بالإضافة إلى ميّزة تسجيل نشاطات المُستخدمين التي تُساعد على إيجاد المشاكل. يُوفّر ملفّ sudoers كمًّا هائلًا من الإمكانيّات والخيارات. ألقِ نظرة على ملفّات man الخاصّة بـsudo وsudoers لمزيد من التّفاصيل. ترجمة -بتصرّف- للمقال Using sudo to delegate permissions in Linux لصاحبه David Both.
  5. يُستعمل Varnish Cache بكثرة لتخبئة محتوى مواقع الويب لتسريع أداء المواقع وتخفيض الحمولة على الخادوم الأصل (origin-server). لطالما شجعنا على استعمال التّخبئة لتسريع أداء تطبيقات الويب وتسهيل قابلية التوسع (Scalability) وضمان الاستقراريّة إضافة إلى الفوائد الأخرى التي تأتي مع هذه الإجراءات من تحسين لتجربة المُستخدم إلى التوفير في الموارد. لكن رغم ذلك فلا نزال بحاجة إلى التأكيد على أهميّة التّخبئة. وفي بعض الأحيان، قد يعني الأمر شرح كيفيّة استعمال Varnish Cache وما يُميّزه عن بقيّة التقنيات الأخرى. الأمور الغريبة التي تُميّز Varnish Cache Varnish Cache عبارة عن خادوم HTTP بنظام HTTP خلفي له قدرة على تقديم الملفّات. يعتمد على هندسة سلسليّة (threaded architecture)، دون حلقة أحداث (event loop). ولأن شيفرة الكتابة قادرة على استعمال استدعاءات النظام الحاصرة (blocking system calls)، فذلك يجعله أسهل استعمالا من Apache أو NGINX، التي يتطلّب استعمالها التعامل مع حلقة أحداث. يقوم Varnish Cache بالتسجيل (logging) على الذاكرة عوضا عن القرص الصلب، تم تصميمه بهذه الطّريقة لأن تسجيل 10000 من عمليات HTTP كل ثانية على القرص الصلب أمر يتطلب الكثير من الموارد. يقوم Varnish بتسجيل جميع التّفاصيل (حوالي 200 سطر لكل طلب) على الذاكرة مُباشرة. إن لم يتم طلب التفاصيل المُسجّلة فستتم الكتابة فوقها (overwrite). يعتبر Varnish التطبيق الوحيد الذي يتخذ هذا المسلك. المرونة: استعمال VCL الميّزة الكبرى لـ Varnish Cashe هي لغة الضّبط الخاصّة به. تمّ إنشاء لغةVCL (Varnish Configuration Language) منذ أكثر من 11 عاما لتدعم النسخة الأولى من Varnish Cache. على عكس Apache أو بقيّة البرمجيّات، فـVarnish Cache لا يعتمد على إعداد تقليدي.بل يعتمد عوضا عن ذلك على مجموعة من السّياسات التي تُكتب بهذه اللغة. تتم ترجمة هذه السيّاسات إلى شيفرة ثنائية، تُحمّل هذه الشيفرة ويتمّ تشغيلها بعد ذلك. يقول مهندس Varnish Cache Poul-Henning Kamp بأنVCL أُنشأت لتكون مجموعة أدوات يمكن استعمالها حسب الحاجة، وليس قطعة موحدة يُمكن إضافتها إلى بيئة العمل. في يومنا الحالي، هناك أكثر من 100 وحدة (modules) لـ VCL يمكن استعمالها ببساطة. في الحقيقة، ففي ملتقيات Varnish Summits هناك دائما ورشة عمل لتعليم الأشخاص كيفيّة كتابة وحدات خاصّة. تعتبر لغة VCL من أكبر الأسباب التي تجعل النّاس تستعمل وتتعلّق بـVarnish Cache. إذ تفتح المرونة التي توفرها اللغة الأبواب للقيام بأي شيء قد يرغب أحدهم بفعله، ما يمحو القيود التي عادة ما تأتي مع البرمجيّات التقليديّة. إذا، ما هي أهم الأدوات التي توفّرها VCL وكيف يُمكننا الاستفادة منها؟ التنطيف Purging لا يدعم Varnish تنظيف المحتوى عند إعداده لأول مرّة، إذ لا يُمكنك تنزيله وتنصيبه ثمّ استعمال نظام تنظيف دون أية خطوات إضافيّة. عوضا عن تمكين إعدادات افتراضيّة، يتوجب على مستخدمي Varnish Cache العمل على تفعيل الميزات المرغوبة كل على حدة، لكن إعداد نظام تنظيف أمر بسيط، ويمكنك الحصول على النتيجة التي ترغبها. sub vcl_recv { if (req.method == "PURGE") { return (purge); } } إن لم ترغب بتمكين الأشخاص على الأنترنت من تنظيف المحتوى على نظام تخبئتك، فسيتوجب عليك ضبط حدّ الوصول ACL كما يلي: acl purge { "localhost"; "192.168.55.0"/24; } sub vcl_recv { if (req.method == "PURGE") { if (!client.ip ~ purge) { return(synth(405,"Not allowed.")); } return (purge); } } إضافة ميزة لـVarnish Cache: خنق الرّبط السّاخن (Hot linking) يسمح إطار العمل الخاص بـVarnish للمستخدمين بإضافة أية ميزة يحتاجون إليها. أول ميّزة أضيفت هي استعمال VCL للحد من الرّبط السّاخن. الرّبط السّاخن هو عمليّة سرقة موارد أحدهم على الويب وكتابة مقال يستخدم صورا مرفوعة على خادوم الضّحية ليدفع تكاليف استخدام الموارد. يسمح Varnish للخوادم بإيقاف هذه العملية عند استعمال الرّبط السّاخن للموارد الخاصة بالخادم دون إذن. على سبيل المثال، يمكن لـVarnish وضع سقف لعدد مرّات حدوث هذا الأمر كل ثانيّة عبر استخدام وحدة من وحدات Varnish (VMOD) باسم vsthrottle لإضافة الخنق (throttling). يمكن القيام بالأمر عبر استيراد وتحميل الوحدة. شيفرة VCL أسفله تُوضّح كيفيّة الحدّ من الرّبط السّاخن. في هذا المثال، نقوم بتطبيق ثلاثة قواعد. القاعدة الأولى تتحقّق من أن عنوان URL المطلوب يبدأ بـ/assets/. القاعدتان الثانيّة والثّالثة تحميان مجلّد الملفات السّاكنة من الرّبط السّاخن. يتمّ هذا عبر التحقق ممّا إذا كان المُحيل referrer طرفا غير مُتوقّع، وما إن طلبت أسماء نطاق أخرى ملفّاتك لأكثر من 10 مرّات خلال 60 ثانيّة. ما سبق عبارة عن دالّة الخنق، يُستعمل رابط URL كمفتاح للخنق.الحدّ المسموح به هو 10 مرّات كلّ 60 ثانيّة. يُمكن تقديم الملفات السّاكنة غير المُشار إليها، وعندما يحصل ذلك، فسيتم إرسال خطأ 403 مع منع الربط السّاخن. يُمكن كذلك توسيع الخنق لاستعمال memcache، وذلك ليحصل المستخدم على المُحاسبة الرّئيسيّة (central accounting) في العنقود (cluster). import vsthrottle; (..) if (req.url ~ "^/assets/" && (req.http.referer !~ "^http://www.example.com/") && vsthrottle.is_denied(req.url, 10, 60s) { return(error(403,"Hotlinking prohibited"); } التّعامل مع ملفات تعريف الارتباط (cookies) لن يقوم Varnish بتخبئة المحتوى الذي يُطلَبُ باستعمال ملفّات تعريف الارتباط. ولن يستجيب إلى طلب محتوى مخبّأ إن كان الطّلب متعلّقا بملف تعريف ارتباط. عوضا عن هذا، يُمكن استعمال وحدة VMOD لحذف ملفّ تعريف الارتباط. المحترفون يستعملون تعبيرا نمطيّا (regular expression) لترشيح ملفات تعريف الارتباط. ولأنّنا لسنا محترفين، فـVarnish يوفّر وحدة باسم cookie تبدو كما يلي: import cookie; sub vcl_recv { cookie.parse ("cookie1: value1; cookie2: value2"); cookie.filter_except("cookie1"); // get_string() will now yield // "cookie1: cookie2: value2;"; } لا يقوم Varnish بإنشاء ترويسة (header) ملف تعريف ارتباط. وإن رأى بأن النظام الخلفي قد أرسل شيفرة إنشاء ملفّ تعريف ارتباط، فلن يقوم بتخبئته. الحل أن تحذف ترويسة Set-Cookie أو إصلاح الخادوم الخلفي. ترويسات Set-Cookie تقوم بتعطيل ملفّات تعريف الارتباط. الحلّ: احذف ترويسة Set-Cookie أو أصلح النّظام الخلفيّ. نمط الإمهال Grace Mode يُمكن نمط الإمهال Varnish من تقديم محتوى قديم إن لم يكن المحتوى الجديد جاهزا أو مُتوفّرا. يساهم هذا في تحسين الأداء عبر إعادة تحميل المحتوى من النظام الخلفيّ بشكل غير متزامن (asynchronous). في الوقت الذي تم فيه تقديم Varnish 1.0 كحل لنظام تخبئة لموقع الجريدة النرويجيّة Verdens Gang، كانت هناك مشاكل كبرى بسبب التكتّلات السلسليّة (threading pileups). كانت الصفحة الرّئيسيّة للموقع تُقدّم 3000 مرّة كلّ ثانيّة، لكن نظام إدارة المُحتوى (CMS) كان بطيئا، إذ كان يأخذ 3 ثوان لإعادة توليد الصّفحة الرّئيسيّة. في بعض المواقع، إن اتّبعت طلبات التّعليقات (RFC)، فسيقوم وسيط (proxy) التّخبئة بإلغاء الصّفحة الرّئيسيّة أو سيحدث انقضاء وقت (time out). عندها سيأتي مُستخدم آخر وسيتوجب جلب نسخة جديدة من الصّفحة الرّئيسيّة. يقوم Varnish بهذا عبر عمليّة التئام التّخبئة (coalescing). إذ يتم وضع المستخدمين الجدد عند وصولهم على قائمة انتظار. (أنظمة التّخبئة الأخرى تُرسل المُستخدمين إلى النظام الخلفيّ ما يقتل الخادم). إن تّمت إضافة 3000 مُستخدم إلى قائمة الانتظار كلّ ثانيّة، فبعد ثلاثة ثوان، سيكون الطابور عبارة عن 9000 مستخدم ينتظرون النظام الخلفي لجلب المحتوى. في البداية، كان Varnish يأخذ المحتوى المطلوب، ويقوم بالتواصل مع السّلاسل (Thread) الـ9000 التي تمّ إنشاؤها، ويُحاول دفع كل شيء دفعة واحدة. سمّي هذا الحدث بالقطيع الصّاخب (thundering herd). وكانت النّتيجة موت الخادوم فورا. لحلّ هذه المُشكلة، قرّر Varnish استعمال الصفحة الرّئيسيّة القديمة عوضا عن انتظار الخادوم لإعادة توليد المحتوى. لن يهتم أحد إن كان المحتوى قديما بـ20 ثانيّة، إلا في حالة كانت البيانات التي تقدّمها متعلّقة بمعلومات ماليّة وترغب عرضها في الوقت الفعلي. تغيّرت التّفاصيل المتعلّقة بـGrace خلال السنوات الماضيّة. في Varnish 4.0 (إن تمّ تفعيله) فستبدو كما يلي: sub vcl_backend_response { set beresp.grace = 2m; } يتم ربط Grace مع كائن الإجابة الخلفيّة (backend response object). إن تم تحديد القيمة في دقيقتين (2m) فسيُبقي Grace على الكائن لدقيقتين بعد انقضاء الـTPL. إن تم طلب الكائن خلال هذا الوقت، فسيتم تفضيل تقديم ما هو مُخبّأ عوضا عن إرسال طلب جديد إلى النظام الخلفيّ. سيتم استعمال الكائن وإعادة تحميله بعدها بشكل غير متزامن. تفاصيل Grace لا يتطلب فهم Varnish Cache النظر إلى الشّيفرة المصدريّة، عوضا عن ذلك، يتم توفير VCL افتراضيّ يُمكن الاعتماد عليه لإضافة أية تفاصيل أخرى حسب الحاجة. فبِميّزة مثل Grace يُمكن للمُستخدمين قراءة شيفرة VCL والنظر إلى التفاصيل: Insert code sub vcl_hit { if (obj.ttl >= 0s) { // A pure unadulterated hit, deliver it return (deliver); } if (obj.ttl + obj.grace > 0s) { // Object is in grace, deliver it // Automatically triggers a background fetch return (deliver); } // fetch & deliver once we get the result return (fetch); } إن كان الكائن VCL يحمل قيمة أكبر من 0 ثوان، هذا يعني بأنّ الـTTL موجب، سيتمّ الرجوع والتّقديم. إن كانتا كل من قيمتي TTL وGrace أكبر من 0 ثوان، فهذا يعني بأنّها ضمن Grace وسيقوم Varnish بتقديمها. إن كانتا كل من قيمتي TTL وGrace أصغر من 0 ثوان، فسيتّم طلب الصّفحة من النّظام الخلفيّ. تعديل كيفيّة عمل Grace يُمكن للمؤسّسات التي تكون بحاجة إلى تقديم معلومات ماليّة وتأبى عرض معلومات قديمة للمُستخدم أن تُغيّر من كيفيّة عمل Grace. في المثال التّالي، لم يتغيّر الجزء الأول، في الجزء الثّاني نقوم بالتقديم في حالة لم يكن الخادوم الخلفيّ على ما يرام وكانت كلا من قيمتي TTL و Grace أكبر من 0 ثانيّة. sub vcl_hit { if (obj.ttl >= 0s) { // A pure unadulterated hit, deliver it return (deliver); } if (!std.healthy(req.backend_hint) && (obj.ttl + obj.grace > 0s)) { return (deliver); } // fetch & deliver once we get the result return (fetch); } *بضعة معلومات إضافيّة: beresp: كائن الطّلب الخلفّي backend request object. req: كائن الطّلب request object. يُستعمل في vcl_recv. bereq: كائن الطّلب الخلفي backend request object. يُستعمل في vcl_backed_fetch. beresp: كائن الإجابة الخلفيّة. يُستعمل في vcl_backend_response. resp: كائن الإجابة response object. يُستعمل في vcl_deliver. obj: الكائن الأصلي في الذّاكرة. يُستعمل في vcl_hit. للمزيد من التّفاصيل استعمل man(7) vcl. آلة الحالة (state machine) يمرّ كل طلب عبر عدّة حالات. يُمكن تشغيل شيفرة مخصّصة في كل حالة لتعديل كائنات الطّلب. بعد تنفيذ الشّيفرة المخصّصة، يقوم Varnish باتّخاذ قرار ما إذا كان نجاحا (Hit) أو إخفاقا (Miss) بعدها يتم تشغيل إمّا VCL hit أو VCL Miss. في حالة النّجاح سيقوم Varnish بتقديم المحتوى. والإخفاقات تُعيد الطّلب من النظام الخلفي. 90% من التّغييرات التي يُحدثها المُستخدمون تحدث هنا. كيفيّة التّضبيط (Tuning) على Linux يتم تحديد الانضباطيات (Tunables) على Linux بشكل محافظ، ونجد SOMAXCONN و TCP_MAX_SYN_Backlog أكثرها مشقّة. عند الانصات (listen) إلى المقابس (socket)، يأخذ Varnish بضعة ثوان للانصات للنّداء. إن كانت السّلاسل مشغولة، فستبدأ النّواة (kernel) بالتّكتّل (queue). لا يُسمَحُ لهذا التّكتّل بأن ينمو إلى ما وراء قيمة SOMAXCONN. سيطلب Varnish 1024 اتّصالا على تكتّل عمق الانصات (listen depth queue)، لكنّ النواة تقوم بإبطال ذلك لتحصل على 928 فقط. ولأنّ Varnish يعمل بصلاحيات الجذر (root)، فمن الممكن تقرير عمق انصات خاصّ، لكنّ Linux أدرى بما هو أفضل. قد يرغب المُستخدمون بالرّفع من هذا الحدّ إن أرادوا تخفيض خطر رفض الاتّصالات عند انقضاء عمق الانصات. سيتوجّب على المستخدم اتخاذ قرار ما إذا كان عدم التّقديم وتقديم صفحة خطأ أفضل أو لا. يقوم TCP_MAX_SYN_Backlog بتعريف عدد الاتّصالات البارزة التي يُمكن لها أن تكون بداخل إقامة الاتّصال (handshake) الثّلاثي الأطراف قبل أن تقرّر النواة بأنّها تحت الهجوم. القيمة الافتراضيّة هي 128. لكن في حالة دخل جمع كبير من النّاس إلى موقعك دفعة واحدة فقد تحصل على أكثر من 128 اتّصال TCP كلّ ثانيّة. لا تقم بتعديل tcp_tw_recycle. تأكّد بأنّك تعرف ما تفعله قبل لمس الإعدادات وابحث على الويب قبل ذلك. إذ أنّ الكثير من العفاريت (demons) تعتمد على هذه القيّم. مساحات العمل (Work spaces) في Linux في Varnish، الذاكرة المحليّة متواجدة في كلّ سلسلة. ولأنّ التّراجع (rollback) يستنزف الموارد، فإنّنا لا نتراجع كلّما احتجنا إلى قليل من المساحة في الذّاكرة. عوضا عن ذلك، نقوم بتعيين مُسبق للذّاكرة على كلّ سلسلة إن كان للمستخدم العديد من سياسات VCL التي قد تستنزف مساحة العمل بأكملها. لا يقوم Varnish بتتبّع الاتّصال، وحدة التّعاقد (contract module) بطيئة للغاية. يتمّ افتراضيّا تشغيل خمسة سلاسل. يُمكن إنشاء سلاسل جديدة بسرعة نسبيّا، لكن إن كنت تخطّط لفتح ألف اتّصال كلّ ثانيّة أي ألف سلسلة، ففي هذه الحالة لديك مُعطى (parameter) لتخصيص سلاسل مُسبقا. خلاصة: احذر عند التّعامل مع مساحات العمل. لا تقم بتتبّع الاتّصالات (connection tracking). ارفع معدّل السّلاسل إلى طلب واحد في الثانيّة لكل سلسلة. الموازنة بين ما هو غريب وما هو رائع في Varnish Cache المرونة القويّة والمميّزات التّي يتمتّع بهاVarnish Cache لا تأتي في حزمة جاهزة (ما قد يجده البعض غريبا)، لذا فقد لا يكون الحلّ الأنسب للجميع. لكنّ المرونة التي يتمتّع بها قد تُغيّر من مجريات الأمور عند الرغبة في تخصيص والتّحكم بأداء المواقع وقابليّة توسيعها. ترجمة -بتصرّف- للمقال Getting started with web app accelerator Varnish Cache لصاحبه Per Buer.
  6. الوسيط العكسي عبارة عن نوع من الخواديم الوسيطة Proxy servers تستقبل طلبات HTTP(S) وتوزّعها بصورة شفّافة على خادوم خلفيّ Backend server واحد أو أكثر. الوسيط العكسي مُفيد لأنّ مُعظم تطبيقات الويب في أيّامنا هذه تستعمل خواديم لم تكن قد صُمّمت لأخذ الطّلبات مُباشرة من المُستخدم وفي العادة لا تدعم إلّا ميزات HTTP بدائيّة. يُمكنك استخدام وسيط عكسيّ لتجنّب وصول المستخدم إلى الخواديم الخلفيّة مُباشرة. يُمكن استخدامها كذلك لتوزيع الحمل Load balancing من الطّلبات على عدّة خواديم، ما يُحسّن الأداء ويُوفّر حماية من تعطّل التّطبيق. يُمكها كذلك أن تمنحك ميزات لا تمنحها خواديم التّطبيقات مثل التّخبئة Caching، ضغط الملفّات Compression، وحتى تشفير SSL. سنضبُط في هذا الدّرس Apache ليعمل على وسيطًا عكسيًّا بسيطًا باستخدام وحدة mod_proxy لإعادة توجيه الطّلبات القادمة إلى خادوم خلفيّ أو أكثر من خادوم يعمل على نفس الشّبكة. سنستعمل في هذا الدّرس واجهة خلفيّة بسيطة مكتوبة بإطار العمل Flask، لكنّك تستطيع استعمال أي خادوم خلفيّ تُريده وأي لغة برمجيّة مُناسبة لك. مُلاحظة: أبدِل your_server_ip في عناوين URL التي تجدها في هذا الدّرس بعنوان IP الخاصّ بخادومك. المُتطلّبات لاتّباع هذا الدّرس، ستحتاج إلى: خادوم أوبونتو 16.04 مضبوط باتّباع الخطوات في هذا الدّرس، وذلك يشمل مُستخدما ذا صلاحيّات sudo مع ضبط مُسبق لتمكينه من تنفيذ مهام إداريّة، غير المستخدم الجذر root، بالإضافة إلى جدار ناري. Apache 2 مُنصّب على خادومك باتّباع الخطوة الأولى من هذا الدّرس. الخطوة الأولى – تفعيل وحدات Apache اللازمة يمتلك Apache الكثير من الوحدات المبنيّة مُسبقا لكنّها لا تكون مُفعّلة عند التّنصيب. لذا سيتوجّب علينا تفعيل الوحدات التي سنستخدمها في هذا الدّرس. الوحدات التّي نحتاج إليها هي mod_proxy وبضعة إضافات خاصّة بها للحصول على بضعة ميزات أخرى لدعم بروتوكولات شبكيّة مُتعدّدة. سنستعمل ما يلي بالتّحديد: mod_proxy، الوحدة الرّئيسيّة لإعادة توجيه الطّلبات، وتُمكّننا من تحويل Apache إلى بوابّة لخواديم التّطبيقات المُعتمدة. وحدة mod_proxy_http لتمكيننا من توسيط اتّصالات HTTP. وحدتا mod_proxy_balancer وmod_lbmethod_byrequests لإضافة ميّزات مُوازنة الحمل على عدّة خواديم. لتفعيل الوحدات الأربع، نفّذ الأوامر التّاليّة: sudo a2enmod proxy sudo a2enmod proxy_http sudo a2enmod proxy_balancer sudo a2enmod lbmethod_byrequests لتطبيق التّغييرات، أعد تشغيل Apache: sudo systemctl restart apache2 يُمكن الآن استخدام Apache ليعمل وسيطًا عكسيًّا لطلبات HTTP. في الخطوة – الاختياريّة - التّاليّة، سننشئ خادومين خلفيّين بسيطين. ما سيُخوّلنا التّحقّق من أنّ الإعدادات تعمل جيّدا، لكن إن كانت لديك تطبيقات تعمل في الواجهة الخلفيّة، يُمكنك تخطي الخطوة التّاليّة والانتقال مُباشرة إلى الخطوة الثّالثة. الخطوة الثّانيّة – إعداد خواديم خلفيّة Backend Servers للاختبار إنشاء خواديم خلفيّة بسيطة طريقة سهلة لاختبار ما إذا كانت إعدادات Apache الخاصّة بك تعمل جيّدًا أو لا. في هذه الفقرة، سنعدّ خادومين يجيبان على طلبات HTTP بمقطع نصّي صغير. أحد الخادومين سيُجيب بالمقطع Hello world! والآخر بالمقطع Howdy world!. مُلاحظة: في الحالات غير الاختباريّة، عادة ما يجب على الخواديم أن تُجيب بنفس الإجابة. لكن بالنّسبة لهذا الاختبار، فامتلاك إجابتين مُختلفتين يُمكّننا من التّأكّد من أنّ خاصيّة مُوازنة الحمل تستخدم كلا الخادومين. Flask إطار عمل مُصغّر مبني بلغة بايثون لبناء تطبيقات الويب. استعملنا Flask لإنشاء خادوميْ الاختبار لأنّ تطبيقا بسيطا باستخدامه لا يتطلّب سوى بضعة أسطر برمجيّة. ليس من الضّروري أن تكون لديك معرفة بلغة بايثون لإعداد الخادومين، لكن إن أردت تعلّمها، فيُمكنك الاطّلاع على هذه الدّروس. أولا، حدّث قائمة الحزم: sudo apt-get update بعدها، نصّب أداة pip لإدارة حزم لغة بايثون: sudo apt-get -y install python3-pip استخدام pip لتنصيب أداة Flask: sudo pip3 install flask بعد تنصيب المُكوّنات المطلوبة، ابدأ بإنشاء ملفّ جديد ليحتوي على شفرة الخادوم الأول في المُجلّد الشخصي للمستخدم الحاليّ: nano ~/backend1.py انسخ ما يلي إلى الملفّ ثمّ احفظه وأغلقه: from flask import Flask app = Flask(__name__) @app.route('/') def home(): return 'Hello world!' السّطران الأول والثّاني عبارة عن تهيئة لإطار العمل Flask. لدينا دالّة واحدة باسم home() تُرجع النّص Hello world!. السّطر @app.route('/') المتواجد فوق الدّالة home() يُخبر Flask بالإجابة على أي طلب يصل إلى العنوان الجذر / بما تُرجعه الدّالّة. الخادوم الثّاني مُشابه للأول، الاختلاف الوحيد أنّ الجواب مُختلف قليلا. لذا انسخ الملفّ الأول: cp ~/backend1.py ~/backend2.py عدّل الملفّ الجديد: nano ~/backend2.py عدّل ما تُرجعه الدّالة من Hello world! إلى Howdy world! ثمّ احفظ وأغلق الملفّ. from flask import Flask app = Flask(__name__) @app.route('/') def home(): return 'Howdy world!' استخدم الأمر التّالي لتشغيل الخادوم الأول على المنفذ رقم 8080. سيقوم هذا الأمر بتحويل المخرجات إلى /dev/null كذلك لتفادي مُقاطعة المُخرج للطّرفيّة. FLASK_APP=~/backend1.py flask run --port=8080 >/dev/null 2>&1 & في السّطر أعلاه، عرّفنا مُتغيّر البيئة FLASK_APP ثمّ نفّذنا الأمر flask لتشغيل الخادوم في نفس السّطر. مُتغيّرات البيئة طريقة سهلة لتمرير المعلومات إلى العمليّات المبدوءة على الطّرفيّة. في هذه الحالة، باستعمال مُتغيّرات البيئة فإنّنا نتأكّد من أنّ الإعداد يُطبّق على الأمر الذي سيكون قيد التّشغيل فقط ولن يكون مُتوفّرا بعد ذلك، وهذا مُناسب لنا لأنّنا سنمرّر اسم ملفّ آخر بنفس الطّريقة لإخبار flask بتشغيل الخادوم الثّاني. استعمل الأمر التّالي لتشغيل الخادوم الثّاني على المنفذ 8081 بطريقة مُشابهة لما سبق. لاحظ بأنّ قيمة مُتغيّر البيئة FLASK_APP مُختلفة في هذه الحالة: FLASK_APP=~/backend2.py flask run --port=8081 >/dev/null 2>&1 & يُمكنك اختبار عمل الخادومين باستخدام أداة curl. اختبار الخادوم الأول: curl http://127.0.0.1:8080/ يجب على المُخرج أن يساوي Hello world!. الخادوم الثّاني: curl http://127.0.0.1:8081/ يجب على المُخرج أن يكون Howdy world!. مُلاحظة: لإغلاق كلا الخادومين بعد أن تنتهي من استخدامهما، عند إنهائك لهذا الدّرس مثلا، فيُمكنك تنفيذ الأمر killall flask. في الخطوة التّاليّة، سنعدّل ملفّ إعدادات Apache لتمكيننا من استخدامه وسيطًا عكسيًّا. الخطوة الثّالثة – تعديل الإعدادات المبدئيّة لجعل Apache يعمل وسيطًا عكسيًّا سنعدّ في هذه الفقرة مُضيفًا افتراضيًّا Virtual host على Apache للعمل وسيطًا عكسيًّا لخادوم خلفي واحد أو عدّة خواديم موزونة الحمل. مُلاحظة: سنُطبّق الإعدادات في هذا الدّرس على مُستوى المُضيف الافتراضي. يوجد في الإعداد المبدئي لـApache مُضيف افتراضي واحد مُفعّل. لكنّك تستطيع استعمال جميع أجزاء هذه الإعدادات على أي مُضيف افتراضي آخر. إن كان خادوم Apache الخاص بك يجيب على طلبات HTTP و HTTPS، فسيتوجّب عليك وضع إعدادات الوسيط العكسي في كلا المُضيفَين الافتراضيّيْن لـHTTP وHTTPS. افتح ملفّ إعدادات Apache المبدئي باستخدام nano أو أي مُحرّر مُفضّل لديك: sudo nano /etc/apache2/sites-available/000-default.conf ستجد داخل هذا الملفّ الجزء <VirtualHost *:80> بدءا من السّطر الأول. يشرح المثال الأول أسفله كيفيّة ضبط هذا الجزء لإعداد وسيط عكسي لخادوم واحد، وفي المثال الثّاني سنضبط وسيطا عكسيّا يوازن الحمل على أكثر من خادوم. المثال الأول – إعداد وسيط عكسي لخادوم خلفيّ واحد أبدل جميع المُحتويات داخل الوسم VirtualHost بما يلي ليصير ملفّ الإعدادات الخاصّ بك كما يلي: <VirtualHost *:80> ProxyPreserveHost On ProxyPass / http://127.0.0.1:8080/ ProxyPassReverse / http://127.0.0.1:8080/ </VirtualHost> إن تابعت الأمثلة في الخطوة الثّانيّة أعلاه، فاستخدم العنوان 127.0.0.1:8080 كما هو مكتوب أعلاه. إن كان لديك تطبيق ويب خاصّ بك، فاستعمل عنوان التّطبيق عوضا عمّا فعلنا. لدينا ثلاثة تعليمات في هذا الإعداد: ProxyPreserveHost مسؤولة عن جعل Apache يُمرّر الترويسة Header المسمَّاة Host الأصليّة إلى الخادوم الخلفيّ. هذا الأمر مُفيد لأنّه يُخبر الخادوم بالعنوان المُستخدَم للوصول إلى التّطبيق. ProxyPass عبارة عن تعليمة الإعداد الرّئيسيّة للوسيط. في هذه الحالة، نحدّد كلّ شيء تحت عنوان URL الجذر / ليُربط مع الخادوم الخلفيّ المرتبط بالعنوان المُعطى. على سبيل المثال، إن استقبل Apache طلبا للموجّه /example، فسيقوم بالاتّصال بالعنوان http://your_backend_server/example وإرجاع الإجابة إلى العميل. ينبغي على ProxyPassReverse أن يحمل نفس الإعداد الذي يحمله ProxyPass. ويُخبر Apache بتعديل ترويسة الجواب من طرف الخادوم الخلفيّ. بهذه الطّريقة سنتأكّد من إعادة توجيه العميل إلى عنوان الوسيط وليس الخادوم الخلفيّ في حالة وُجدت ترويسة إعادة توجيه في جواب الخادوم لتجنّب أخطاء إعادة التّوجيه. لتطبيق هذه التّغييرات، أعد تشغيل Apache: sudo systemctl restart apache2 إن حاولت الآن الوصول إلى http://your_server_ip في مُتصفّح ويب، ستجد جواب الخادوم الخلفيّ عوضا عن رسالة ترحيب Apache المألوفة. إن تابعت الخطوة الثّانيّة، فهذا يعني بأنّ النّتيجة ستكون Hello world!. المثال الثّاني – موازنة الحمل على عدّة خواديم خلفيّة إن كان لديك أكثر من خادوم خلفيّ واحد، فاستخدام ميزة مُوازنة الحمل في mod_proxy طريقة جيّدة لتوزيع الطّلبات على الخواديم. استبدل جميع مُحتويات الجزء VirtualHost بما يلي ليبدو ملفّ الإعدادات كما يلي: <VirtualHost *:80> <Proxy balancer://mycluster> BalancerMember http://127.0.0.1:8080 BalancerMember http://127.0.0.1:8081 </Proxy> ProxyPreserveHost On ProxyPass / balancer://mycluster/ ProxyPassReverse / balancer://mycluster/ </VirtualHost> الإعدادات هنا مُشابهة لما سبق، لكن عوضا عن تخصيص خادوم واحد مُباشرة، استعملنا وسم Proxy إضافيّا لتعيين خواديم مُتعدّدة.سمّينا الوسم بـbalancer://mycluster (يُمكنك تغيير الاسم إن شئت) ليحتوي على أكثر من تعليمة BalancerMember، والذي يُحدّد عناوين الخواديم الخلفيّة. هكذا تستعمل التّعليمتان ProxyPass وProxyPassReverse مجموعة موازنة الحمل المُسمّاة mycluster عوضا عن خادم مُحدّد. إن تابعت الخطوة الثّانيّة من هذا الدّرس، فاستعمل العنوانين 127.0.0.1:8080 و127.0.0.1:8081 للتّعليمة BalancerMember كما هو مُبيّن في الإعدادات أعلاه. أمّا إن كانت لديك خواديم خاصّة بك فاستعمل عناوينها. لتطبيق هذه التّغييرات، أعد تشغيل Apache: sudo systemctl restart apache2 إن حاولت الآن الوصول إلى http://your_server_ip في مُتصفّح ويب، ستجد جواب الخواديم الخلفيّة عوضا عن رسالة ترحيب Apache المألوفة. إن تابعت الخطوة الثّانيّة، فعند إعادة تحميل الصّفحة عدّة مرّات، ستُلاحظ بأنّ النّتيجة ستكون إمّا Hello world! أو Howdy world!، ما يعني بأنّ الوسيط العكسي يعمل على مُوازنة الحمل بين الخادومين. خاتمة لديك الآن معرفة بكيفيّة إعداد خادوم Apache ليعمل وسيطًا عكسيًّا لخادوم تطبيق أو أكثر. يُمكن استعمال mod_proxy لضبط وسيط عكسي لخواديم تطبيقات مكتوبة بلغات مثل Python مع Django أو Ruby مع Ruby on Rails. يُمكن كذلك استخدامها لموازنة الحمل على عدّة خواديم للتّطبيقات التي تستقبل العديد من الزّوار، بالإضافة إلى إمكانيّة استخدامه لتوفير حماية SSL للخواديم الخلفيّة التي لا تدعم SSL. رغم أنّ mod_proxy وmod_proxy_http أكثر تركيب يتمّ استخدامه، إلّا أنّ هناك العديد من الوحدات الأخرى التّي تدعم بروتوكولات اتّصال أخرى. إليك بعضا من الوحدات الشّهيرة التي لم نستخدمها في هذا الدّرس: mod_proxy_ftp لبروتوكول FTP. mod_proxy_connect لإعداد أنفاق SSL. mod_proxy_ajp لبروتوكول AJP (Apache JServ Protocol) لخواديم خلفيّة مبنيّة على Tomcat. mod_proxy_ftp لمقابس الويب Web sockets. يُمكنك قراءة التّوثيق الرّسمي للاستزادة حول mod_proxy. ترجمة – بتصرّف - للمقال How To Use Apache as a Reverse Proxy with mod_proxy on Ubuntu 16.04 لكاتبه Mateusz Papiernik.
  7. تعرفنا في درس سابق على كيفية تفعيل وحدة mod_rewrite وضبطها لإعادة كتابة عناوين URL في خادوم Apache.ا سنعتمد في هذا الشرح على ما تعلمناه سابقًا ونتوسّع - مع مثاليْن عمليّيْن - في شرحٍ بعض من أكثر التّعليمات استخداما في ضبط mod_rewrite. المثال الأول – تبسيط نصوص الاستعلام Query strings باستخدام RewriteRule تستعمل تطبيقات الوِب في العادة نصوص الاستعلام التي يُمكن إضافتها إلى عنوان URL باستخدام علامة استفهام (?) بعد العنوان. تُمرَّر المُعاملات المُختلفة باستخدام علامة &. يُمكن استخدام نصوص الاستعلام لتمرير معلومات إضافيّة بين صفحات تطبيق الوِب. على سبيل المثال، يُمكن لصفحة نتائج بحث مكتوبة بلغة PHP أن تستعمل عنوانا مثل http://example.com/results.php?item=shirt&season=summer. في هذا المثال، هناك مُعاملان إضافيّان، المُعامل item مع القيمة shirt، والمُعامل season ذو القيمة summer. سيستعمل التّطبيق هذه المعلومات لتقديم أكثر نتيجة مناسبة للمُستخدم. تُكتب قواعد إعادة الكتابة في Apache عادة لتبسيط روابط طويلة مثل التي أعلاه إلى عناوين URL بسيطة سهلة القراءة والفهم. في هذا المثال، نريد تبسيط ما سبق ليكون على شكل http://example.com/shirt/summer. كما تُلاحظ، فالقيمتان shirt و summer لا تزالان مُتواجدتيْن داخل العنوان، لكن دون نصّ استعلام واسم ملفّ PHP. إليك قاعدة لتحقيق مُرادنا: RewriteRule ^shirt/summer$ results.php?item=shirt&season=summer [QSA] المقطع shirt/summer واضح وقد أخبرنا Apache بتوجيه أي طلبات مطابقة إلى العنوان results.php?item=shirt&season=summer. تُستخدم الخيارات [QSA] عادة في قواعد إعادة الكتابة. وتُخبر Apache بإضافة أي نصّ استعلام إضافي إلى عنوان URL المُقدَّم، لذا لو كتب زائر http://example.com/shirt/summer?page=2 فسيجيب الخادوم بـ results.php?item=shirt&season=summer&page=2. إن لم تُضف هذه الخيارات فسيُتجاهل نصّ الاستعلام الإضافي. رغم أنّ هذه الطّريقة تُحقّق هدفنا، إلّا أنّنا كتبنا القيمتين بصراحة داخل الملفّ. لذا فالقاعدة لن تعمل لأي قيم أخرى مثل pants وwinter. لجعل القاعدة عامّة أكثر، يُمكننا استخدام التّعابير النّمطيّة لمُطابقة أجزاء من العنوان الأصلي واستعمالها في مقطع بدل نمطي. بحيث تكون القاعدة المُعدّلة كما يلي: RewriteRule ^([A-Za-z0-9]+)/(summer|winter|fall|spring) results.php?item=$1&season=$2 [QSA] التّعبير النمطي الأول داخل القوسين يُطابق أي مقطع نصّ مكوّن من أحرف وأرقام مثل shirt و pants ويحفظ المقطع المُطابق في المُتغيّر $1. التّعبير النمطي الذي يتبعه يُطابق حرفيًّا كلّا من summer، winter، fall و spring، ويحفظ أي مُطابق في المُتغيّر $2. تُستعمل المقاطع المُطابقة بعدها في عنوان URL النّاتج لتمريرها إلى كل من المُعاملين item وseason عوضا عن كتابة القيمتين على نحو صريح كما فعلنا سابقا. القاعدة أعلاه ستستبدل على سبيل المثال العنوان http://example.com/pants/summer إلى http://example.com/results.php?item=pants&season=summer. هذا المثال قابل للتماشي مع التّطويرات المُستقبليّة كذلك، بحيث يُمكن إعادة كتابة العناوين لعدّة قيم باستخدام قاعدة واحدة فقط. المثال الثّاني – إضافة شروط منطقيّة باستخدام RewriteConds قواعد إعادة الكتابة ليست محصورة في قواعد تُترجم واحدة تلو الأخرى دون أية قيود. تُمكّننا تعليمة RewriteCond من إضافة شروط لقواعد إعادة الكتابة للتحكم في وقت ترجمة القواعد. تتّبع RewriteCond التّنسيق التّالي: RewriteCond TestString Condition [Flags] RewriteCond: تعليمة الشرط. TestString النّص الذي سيُجرى عليه الاختبار. Condition نمط أو شرط للاختبار به. Flags عبارة عن مُعاملات إضافيّة يُمكن لها تعديل الشّرط وقواعد التّحويل. إذا أرجع شرط في RewriteCond القيمة المنطقيّة true (أي أنّ الشرط قد تحقّق)، فستُنفَّذ قاعدة RewriteRule التي تلي الشرط مُباشرة. إن لم يتحقّق الشّرط فتُتجاهل القاعدة. يُمكن استخدام أكثر من شرط. يجب مبدئيًّا على جميع الشّروط أن تتحقّق لتطبيق القاعدة التي تليها. على سبيل المثال، لنفترض بأنّك تريد إعادة توجيه جميع الطّلبات المُوجّهة إلى ملفّات أو مُجلّدات غير موجودة إلى الصّفحة الرّئيسيّة عوضا عن عرض صفحة الخطأ 404. يُمكن تحقيق هذا الهدف بالشّروط التّاليّة: RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . / في المثال أعلاه: %{REQUEST_FILENAME} يُمثّل النصّ المُختبَر. في هذه الحالة، القيمة ستكون عبارة عن اسم الملفّ الذي طلبه المُستخدم وهو مُتغيّر نظام خاص يتوفّر في كل طلب. f- شرط متوفّر مُسبقا في وحدة mod_rewrite للتّحقّق من أنّ الاسم الذي طلبه المُستخدم مُتواجد على القرص وبأنّه ملفّ فعلا. أمّا ! فهي علامة نفي. بجمعهما، فـf-! تتحقّق من أنّ الاسم الذي طلبه الاستعلام غير مُتواجد أو أنّه ليس ملفّا. d-! يعمل بطريقة مُشابهة ولكن بالنسبة للمجلّدات، إذ يُساوي القيمة true فقط إن كان الاسم المطلوب غير موجود أو أنّه ليس مجلّدا. ستُنفَّذ قاعدة RewriteRule الموجودة في السطر الأخير فقط إن تلقى الخادوم طلبا لملفّ أو مُجلّد غير موجود. القاعدة بسيطة وكلّ ما تفعله هو إعادة توجيه الطّلب إلى موجّه الجذر / في الموقع (والذي يكون عادة صفحة رئيسيّة). خاتمة mod_rewrite وحدة مُفيدة جدّا في Apache يُمكن استخدامها لتوفير عناوين URL سهلة القراءة. في هذا الدّرس، تعلّمتَ كيفيّة استخدام تعليمة RewriteRule لإعادة توجيه المُستخدمين حتى ولو كانت تتضمّن نصوص استعلام. تعلّمت كذلك كيفيّة إعادة التّوجيه حسب شروط باستعمال التّعليمة RewriteCond. للتّعرف أكثر على mod_rewrite، ألق نظرة على هذه الصّفحة والتّوثيق الرّسمي لـmod_rewrite من Apache. ترجمة – بتصرّف - للمقال How To Rewrite URLs with mod_rewrite for Apache on Ubuntu 16.04 لكاتبه Mateusz Papiernik.
  8. مُقدّمة سنتعرّف في هذا الدّرس على كيفيّة إعادة كتابة عناوين URL باستخدام وحدة mod_rewrite الخاصّة بـApache 2. تمنحنا هذه الوحدة حريّة إعادة كتابة روابط URL لتكون أكثر نظافة وتنسيقا عبر ترجمة مسارات قابلة للقراءة إلى استعلامات مُوجّهة لتطبيق الوِب أو إعادة توجيه المُستخدم حسب شروط إضافيّة. هذا الدّرس مُقسّم إلى جزأين. بحيث نجهّز في الجزء الأول موقعا إلكترونيا بسيطا مع مثال بسيط لإعادة كتابة عنوان URL. يُغطّي الجزء الثّاني مثالين مُعمّقين لأكثر قواعد إعادة الكتابة شيوعا. المُتطلّبات لاتّباع هذا الدّرس، ستحتاج إلى: خادوم أوبونتو 16.04 مضبوط باتّباع الخطوات الواردة في درس الإعداد الابتدائي لخادوم أوبونتو، وذلك يشمل مُستخدما ذا صلاحيّات sudo مع ضبط مُسبق لتمكينه من تنفيذ مهام إداريّة، غير المستخدم الجذر root، بالإضافة إلى جدار ناري. Apache 2 مُنصّب على خادومك باتّباع الخطوة الأولى من درس تثبيت حزم LAMP على أوبونتو. الخطوة 1 – تفعيل mod_rewrite أولا، نحتاج إلى تفعيل mod_rewrite. مبدئيًّا، الوحدة متوفّرة لكنّها غير مُفعّلة عند تنصيب Apache 2. sudo a2enmod rewrite سيقوم هذا الأمر بتفعيل الوحدة أو إخبارك بأنّ الوحدة قد سبق تفعيلها. لتطبيق التّغييرات، أعد تشغيل Apache: sudo systemctl restart apache2 وحدة mod_rewrite مُفعّلة الآن. سنضبُط في الخطوة التّاليّة ملفّ .htaccess لاستخدامه لتحديد قواعد إعادة الكتابة لإعادات التّوجيه Redirects. الخطوة 2 – ضبط htaccess. يسمح لنا ملفّ .htaccessبتعديل قواعد إعادة الكتابة دون الحاجة إلى الوصول إلى ملفّات إعدادات الخادوم. لهذا السّبب، فملفّ .htaccess مُهمّ جدّا لحماية تطبيق الوِب الخاصّ بك. النّقطة في أول الاسم تُشير إلى أنّ الملفّ مخفي. مُلاحظة: يُمكن لأي قواعد تضعها داخل ملفّ .htaccess أن توضع كذلك داخل ملفّات إعدادات الخادوم، في الحقيقة، ينصح التوثيق الرّسمي لـApache ينصح باستعمال ملفات إعدادات الخادوم عوضا عن ملفّ .htaccess لقدرة Apache على مُعالجتها بسرعة أعلى. مع ذلك، في مثالنا البسيط، الفرق في الأداء لن يكون ملحوظا. بالإضافة إلى أنّ وضع القواعد داخل ملفّ .htaccess مُريح أكثر، خاصّة إن كان لديك الكثير من المواقع الإلكترونيّة في خادوم واحد. إذ لا تتطلّب التّغييرات إعادة تشغيل الخادوم ولا تحتاج إلى صلاحيّات المُستخدم الجذر Root لتعديل الملفّ، ما يُسهّل إجراء التّغييرات بحساب مُستخدم عاديّ. بعض البرمجيّات مفتوحة المصدر مثل جوملا ، ووردبريس ولارافل تعتمد على ملفّ .htaccess لإجراء التّعديلات وإضافة قواعد إضافيّة حسب الطّلب. سنحتاج إلى ضبط وتأمين بعض الإعدادات قبل أن نبدأ. يمنع Apache مبدئيًّا استخدام ملفّ .htaccess لقواعد إعادة كتابة روابط URL، لذا سيتوجّب عليك أولا تفعيل إمكانيّة استخدام الملفّ. افتح ملفّ إعدادات Apache المبدئية باستخدام nano أو مُحرّرك المفضّل. sudo nano /etc/apache2/sites-available/000-default.conf ستجد داخل هذا الملفّ الجزء <VirtualHost *:80> في أول سطر. داخل هذا الجزء، أضف الجزء التّالي مباشرة بعد السطر الذي يبدأ بـDocumentRoot: <Directory /var/www/html> Options Indexes FollowSymLinks MultiViews AllowOverride All Require all granted </Directory> ليُصبح ملفّ الإعدادات كما يلي (حذفنا - للاختصار - التعليقات، وهي الأسطر التي تبدأ بـ# من المُقتَطع أدناه). تأكّد من أنّ الإزاحة صحيحة: <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html <Directory /var/www/html> Options Indexes FollowSymLinks MultiViews AllowOverride All Require all granted </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost> احفظ وأغلق الملفّ. ملحوظة: يفترض هذا الدليل وجودَ موقع واحد على خادومك، في هذه الحالة يكفي التعديل على ملف المضيف الافتراضي Virtual host المبدئي (000-default.conf) بالطريقة أعلاه لتفعيل إمكانيّة إعادة التوجيه. إن كان لديك أكثر من موقع فستحتاج لإجراء التعديل أعلاه على ملفّ المضيف الافتراضي الخاصّ بالموقع الذي تريد. توجد ملفات المضيفات الافتراضية على المسار /etc/apache2/sites-available/. لتطبيق التّغييرات، أعد تشغيل خادوم Apache: sudo systemctl restart apache2 الآن، أنشئ ملفّ .htaccess داخل مجلّد الوب الجذر: sudo nano /var/www/html/.htaccess أضف السّطر التّالي إلى أعلى الملفّ لتفعيل مُحرّك إعادة الكتابة Rewrite engine: RewriteEngine on احفظ وأغلق الملفّ. يُمكنك الآن استعمال الملفّ .htaccess للتّحكم بقواعد المُوجّهات في تطبيق الوِب الخاصّ بك. الخطوة 3 – ضبط إعادات كتابة روابط URL سنعدّ في هذه الفقرة إعادة كتابة بسيطة لرابط URL، بحيث نستطيع تحويل عناوين URL جميلة إلى مسارات يُمكن للشفرة فهمها. سنسمح بالخصوص للمُستخدمين بالوصول إلى العنوان http://your_server_ip/about. لنبدأ بإنشاء ملفّ باسم about.php داخل مُجلّد الوب: sudo nano /var/www/html/about.php انسخ شفرة HTML التّاليّة إلى الملفّ واحفظه ثمّ أغلقه: <html> <head> <title>About Us</title> </head> <body> <h1>About Us</h1> </body> </html> ملحوظة: تأكّد من أن خادوم الوِب لديه صلاحيات الوصول إلى الملف الذي أنشأته للتو. مثلا، بإعطاء الأذون 755على مجلد الوِب: sudo chmod -R 755 /var/www يُمكنك الوصول إلى هذه الصّفحة على العنوان http://your_server_ip/about.html، لكن لو حاولت الوصول إلى العنوان http://your_server_ip/about، فستُلاحظ خطأ 404 Not Found، إن أردت تمكين مُستخدميك من استعمال هذا العنوان عوضا عن العنوان السّابق (أي دون الجزء .html) فقواعد إعادة الكتابة كفيلة بتوفير هذه الوظيفة. تتّبع جميع قواعد الكتابة التّنسيق التّالي: RewriteRule pattern substitution [flags] بحيثُ: RewriteRule يُحدّد التّعليمة. pattern تعبير نمطي Regular Expression يُحدّد عنوان URL المرغوب به، هذا هو ما سيكتبه المُستخدم في شريط عنوان URL. substitution: البدل، وهو مسار عنوان URL الأصلي، (مسار الملفّ الذي يقوم Apache بتقديمه). flags عبارة عن مُعاملات اختياريّة لتعديل آليّة عمل القاعدة. افتح ملفّ .htaccess: sudo nano /var/www/html/.htaccess بعد السّطر الأول، أضف السّطر الثّاني ممّا يلي: RewriteEngine on RewriteRule ^about$ about.html [NC] في هذه الحالة، المقطع ^about$ هو التّعبير النّمطي، about.html يُعبّر عن البدل، و [NC] هي المُعاملات. استخدمنا في هذا المثال عدّة محارف تحمل معان خاصّة: ^ يُشير إلى بداية العنوان بعد المقطع your_server_ip/. $ يُشير إلى نهاية عنوان URL. about المقطع الذي يجب على التّعبير النّمطي مُطابقته. about.html اسم الملفّ الأصلي الذي يصل إليه المُستخدم [NC] خيار لجعل القاعدة تتجاهل حالة الأحرف Case insensitive. ينبغي الآن أن تستطيع الوصول إلى العنوان http://your_server_ip/about في مُتصّفح الويب الخاصّ بك. في الحقيقة، بالقاعدة التي كتبناها أعلاه، فالعناوين التّاليّة ستؤدّي جميعها إلى الملفّ about.html: http://your_server_ip/about، بسبب تعريفنا للقاعدة. http://your_server_ip/About، لأنّ القاعدة تتجاهل حالة الأحرف. http://your_server_ip/about.html، لأنّ اسم الملفّ الأصلي سيعمل دائما. العناوين التّاليّة لن تعمل: http://your_server_ip/about/، لأنّ القاعدة تنصّ بوضوح بأنّه لا يجوز على أي شيء أن يكون بعد about باستخدام المحرف $. http://your_server_ip/contact، لأنّ العنوان لن يُطابق المقطع about. تمتلك الآن ملفّ .htaccess مع قاعدة بسيطة، يُمكنك الآن تعديله وتوسيعه حسب حاجاتك. سنتعرّف في الجزء الثاني من هذا الدرس على أمثلة إضافية لإعادة كتابة الروابط والتعليمات الأكثر استخداما مع mod_rewrite. ترجمة – بتصرّف - للمقال How To Rewrite URLs with mod_rewrite for Apache on Ubuntu 16.04 لكاتبه Mateusz Papiernik.
  9. تعرّفنا في الجزأين السابقيْن من هذا الدليل على كيفية عرض معلومات عن مساحات التخزين وإنشاء مساحات تخزين جديدة وتحجيمها. سنكمل في هذا الجزأ - الأخير من الدليل - ما تعلمناه سابقا ونتعرّف على المهمة الأخيرة من بين المهمّات الأساسية في إدارة التخزين بآلية LVM. تنبيه: تأكّد من أنّ الأجهزة التّي تودّ تطبيق الأوامر المذكورة في هذا الدرس عليها لا تحتوي على بيانات مُهمّة. استخدام هذه الأجهزة مع LVM سيؤدّي إلى الكتابة فوق المحتويات الحاليّة. يُفضَّل أن تختبر الخطوات المعروضة أدناه في آلة افتراضية أو على خادوم خاصّ بأغراض التجربة والاختبار. إزالة أو تقليص مُكوّنات LVM بما أن تقليص مساحة التّخزين قد يؤدي إلى فقدان البيانات، فإجراءات تقليص المساحة المتوفّرة، سواءٌ بتقليص حجم أو حذف المكوّنات، أكثر تعقيدًا من بقية المهامّ. تخفيض حجم وحدة تخزين منطقيّة لتقليص وحدة تخزين منطقيّة، يجب عليك أولا أخذ نسخة احتياطية من بياناتك. فبما أن هذه العمليّة تقلّص مساحة التّخزين المُتوفّرة فإن أي خطأ يُمكن له أن يُؤدي إلى فقدان البيانات. إذا كنت جاهزا، تأكّد من حجم المساحة المُستخدمة حاليّا: df -h المُخرج: Filesystem Size Used Avail Use% Mounted on . . . /dev/mapper/LVMVolGroup-test 4.8G 521M 4.1G 12% /mnt/test في هذا المثال، يبدو بأنّنا نستخدم حاليّا حوالي 521M من المساحة. استعمل هذه المعلومة لتحديد الحجم الذي تريد تقليص وحدة التخزين إليه. تاليّا، أزل تركيب نظام الملفّات. فعلى عكس التوسيعات، يجب عليك تقليص مساحة نظام الملفّات أثناء إزالة التركيب: cd ~ sudo umount /dev/LVMVolGroup/test بعد إزالة التركيب، تأكّد من أن نظام الملفّات في حالة جيّدة. مرّر نوع نظام الملفّات عبر الخيار -t. سنستعمل الخيار -f للتّحقّق من أن كل شيء على ما يرام حتى ولو بدا كذلك: sudo fsck -t ext4 -f /dev/LVMVolGroup/test بعد التّحقّق من سلامة نظام الملفّات، يُمكنك تقليص مساحته باستخدام الأدوات الخاصّة، في حالة Ext4، فالأمر سيكون resize2fs. مرّر الحجم النّهائي لنظام الملفّات. تنبيه: أكثر خيار أمانا هو تمرير حجم نهائي أكبر بكثير من الحجم المُستخدم حاليا. أعط نفسك مساحة أمان لتجنّب فقدان البيانات وتأكّد من إنشاء نسخ احتياطيّة. sudo resize2fs -p /dev/LVMVolGroup/test 3G حالما تنتهي العمليّة، قلّص حجم وحدة التّخزين المنطقيّة عبر تمرير نفس الحجم (3G في هذه الحالة) إلى الأمر lvresize عبر الخيار -L. sudo lvresize -L 3G LVMVolGroup/test ستستقبل تنبيها حول فقدان البيانات، إن كنت جاهزا، فاكتب y للاستمرار. بعد تقليص حجم وحدة التّخزين المنطقيّة، تحقّق من سلامة نظام الملفّات مُجدّدا: sudo fsck -t ext4 -f /dev/LVMVolGroup/test إن سار كلّ شيء على ما يرام، فستستطيع إعادة وصل نظام الملفّات بالأمر المُعتاد: sudo mount /dev/LVMVolGroup/test /mnt/test ينبغي الآن على وحدة التّخزين المنطقيّة أن تُقلّص إلى الحجم المُحدّد. حذف وحدة تخزين منطقيّة إن لم تعد بحاجة إلى وحدة تخزين منطقيّة، يُمكنك حذفها باستعمال الأمر lvremove. أولا، أزل تركيب وحدة التخزين: cd ~ sudo umount /dev/LVMVolGroup/test بعدها، احذف وحدة التخزين بالأمر التّالي: sudo lvremove LVMVolGroup/test سيُطلب منك تأكيد العمليّة، إن كنت متأكّدا من رغبتك في حذف وحدة التّخزين، فاكتب y. حذف مجموعة تخزين لحذف مجموعة تخزين كاملة، بما في ذلك جميع وحدات التّخزين المنطقيّة المتواجدة بها، استعمل الأمر vgremove. قبل حذف مجموعة تخزين، عليك حذف وحدات التّخزين بداخلها بالعمليّة أعلاه. أو على الأقل، تأكّد من إزالة تركيب جميع وحدات التّخزين بداخل المجموعة: sudo umount /dev/LVMVolGroup/www sudo umount /dev/LVMVolGroup/projects sudo umount /dev/LVMVolGroup/db بعدها يُمكنك حذف مجموعة التّخزين عبر تمرير اسمها إلى الأمر vgremove: sudo vgremove LVMVolGroup سيُطلب منك تأكيد عمليّة حذف المجموعة. إذا كانت هناك أية وحدات تخزين منطقيّة مُتبقيّة، ستُسأل عن تأكيد حذفها واحدة واحدة قبل حذف المجموعة. حذف وحدة تخزين ماديّة إن أردت إزالة وحدة تخزين ماديّة من إدارة LVM، فسيعتمد الإجراء المطلوب على ما إذا كانت الوحدة مُستخدمة من طرف LVM أو لا. إن كانت وحدة التّخزين الماديّة مُستخدَمة، سيتوجّب عليك نقل المداءات الماديّة على الجهاز إلى مكان آخر. سيتطلّب ذلك وجود وحدات تخزين ماديّة أخرى لتحتضن المداءات الماديّة. إن كنت تستعمل أنواعا مُعقّدة من وحدات التّخزين المنطقيّة، فقد يتوجّب عليك الحصول على المزيد من وحدات التّخزين الماديّة حتى ولو كانت لديك مساحة تخزين كافيّة. إن كان لديك عدد كاف من وحدات التّخزين الماديّة في مجموعة التّخزين لاحتضان المداءات الماديّة، فانقلها إلى خارج وحدة التّخزين الماديّة التي ترغب في إزالتها عبر كتابة ما يلي: sudo pvmove /dev/sda يُمكن لهذه العمليّة أن تأخذ وقتا طويلا حسب حجم وحدات التّخزين وكميّة البيانات التي يتوجب نقلها. حالما تنتقل المداءات إلى وحدات تخزين أخرى، يُمكنك حذف وحدة التّخزين الماديّة من مجموعة التّخزين عبر الأمر التّالي: sudo vgreduce LVMVolGroup /dev/sda هذه العمليّة كفيلة بإزالة وحدات التّخزين التي أُخلِيت من مجموعة التّخزين. بعد انتهاء العمليّة، يُمكنك حذف علامة وحدة التّخزين الماديّة من جهاز التّخزين عبر الأمر: sudo pvremove /dev/sda ينبغي الآن أن تتمكّن من استعمال جهاز التّخزين المُزال لأغراض أخرى أو إزالته من النّظام بالكامل. ختاما إلى هذه النّقطة، يجب أن يكون لديك فهم لكيفيّة إدارة أجهزة التّخزين على أوبونتو 16.04 مع LVM. يجب أن تعرف كيفيّة الحصول على معلومات عن مكوّنات LVM، كيفيّة استخدام LVM لتركيب نظام تخزين خاص بك، وكيفيّة تعديل وحدات التّخزين لتلبيّة حاجاتك. يُمكنك اختبار هذه المبادئ في بيئة آمنة لفهم أعمق حول آليّة عمل LVM ومكوّناته. ترجمة – بتصرّف - للمقال How To Use LVM To Manage Storage Devices on Ubuntu 16.04 لكاتبه Justin Ellingwood.
  10. بعد أن تعرّفنا في الجزء السابق على كيفية عرض معلومات عن مختلف العناصر في LVM، سنتطرّق في هذا الجزء من الدليل إلى كيفية التحكم في هذه المكوّنات بإنشاء مكوّنات جديدة أو إعادة تحجيم (توسيع أو تقليص) مكوّنات موجودة. إنشاء أو توسيع مكوّنات LVM سنتحدّث في هذه الفقرات عن كيفيّة إنشاء وتوسيع وحدات التّخزين الماديّة والمنطقيّة وكذا مجموعات التّخزين. إنشاء وحدات تخزين ماديّة من أجهزة تخزين خام لاستعمال أجهزة التّخزين مع LVM، يجب عليها أولا أن تُعلّم على أنها وحدات تخزين ماديّة. ما يُحدّد إمكانيّة استخدام الجهاز داخل مجموعة تخزين. أولا، استعمل الأمر lvmdiskscan لإيجاد جميع أجهزة التّخزين التي يُمكن لـLVM رؤيتها واستخدامها: sudo lvmdiskscan المُخرج: /dev/ram0 [ 64.00 MiB] /dev/sda [ 200.00 GiB] /dev/ram1 [ 64.00 MiB] . . . /dev/ram15 [ 64.00 MiB] /dev/sdb [ 100.00 GiB] 2 disks 17 partitions 0 LVM physical volume whole disks 0 LVM physical volumes في المُخرج أعلاه، بتجاهل أجهزة /dev/ram*، يُمكننا رؤية الأجهزة التّي يُمكن تحويلها إلى وحدات تخزين ماديّة لـLVM. تنبيه: تأكّد من أنّ الأجهزة التّي ترغب باستعمالها مع LVM لا تحتوي على أيّة بيانات مُهمّة. استخدام هذه الأجهزة مع LVM سيؤدّي إلى الكتابة فوق المحتويات الحاليّة. إذا كنت تمتلك بيانات مهمّة على خادومك فأنشئ نسخا احتياطية قبل الاستمرار في تطبيق الدّرس. لجعل أجهزة التّخزين وحدات تخزين ماديّة خاصّة بـLVM، استعمل الأمر pvcreate. يُمكنك تمرير عدّة أجهزة في نفس الوقت: sudo pvcreate /dev/sda /dev/sdb هذا الأمر سيكتب ترويسة LVM على جميع الأجهزة الهدف لتخصيصها كوحدات تخزين LVM ماديّة. إنشاء مجموعة تخزين من وحدات التّخزين الماديّة لإنشاء مجموعة تخزين جديدة من وحدات التّخزين الماديّة، استعمل الأمر vgcreate. سيتوجّب عليك تمرير اسم للمجموعة متبوعا بوحدة تخزين ماديّة واحدة على الأقل: sudo vgcreate volume_group_name /dev/sda استبدل volume_group_name باسم من اختيارك لمجموعة التّخزين. سينشئ المثال أعلاه مجموعة تخزين انطلاقا من وحدة تخزين ماديّة واحدة فقط. يُمكنك تمرير أكثر من وحدة تخزين ماديّة عند إنشاء المجموعة إن أردت ذلك: sudo vgcreate volume_group_name /dev/sda /dev/sdb /dev/sdc عادة ستحتاج إلى مجموعة تخزين واحدة فقط لكل خادوم. بحيث يُمكنك إضافة أي مساحة تخزين إضافيّة لمنطقة مُوحّدة ثمّ تخصيص وحدات تخزين منطقيّة منها. الحاجة إلى استخدام أحجام مداءات مُختلفة من الأسباب التّي قد تدفعك إلى إنشاء أكثر من مجموعة تخزين واحدة. في العادة، لن يتوجّب عليك تحديد حجم المدى (الحجم المبدئي هو 4M ويُعدّ كافيّا لمُعظم الاستخدامات)، لكنّ إن أردت، يُمكنك تحديد حجم المداءات عند إنشاء مجموعة التّخزين باستعمال الخيار -s: sudo vgcreate -s 8M volume_group_name /dev/sda سينشئ هذا الأمر مجموعة تخزين مع حجم مداءات يُساوي 8M. إضافة وحدة تخزين ماديّة إلى مجموعة تخزين موجودة مُسبقا لتوسيع مجموعة تخزين عبر إضافة وحدات تخزين ماديّة، استخدم الأمر vgextend. يأخذ هذا الأمر مجموعة تخزين متبوعة بوحدات التّخزين الماديّة التّي ترغب بإضافتها إلى المجموعة. يُمكنك كذلك تمرير أكثر من جهاز في نفس الوقت إن أردت: sudo vgextend volume_group_name /dev/sdb ستُضاف وحدة التّخزين الماديّة إلى مجموعة التّخزين موسّعة بذلك مساحة التّخزين المُتوفّرة على المجموعة. إنشاء وحدة تخزين منطقيّة بحجم مُحدّد لإنشاء وحدة تخزين منطقيّة من مجموعة تخزين، استعمل الأمر lvcreate. حدّد حجم وحدة التّخزين المنطقيّة باستخدام الخيار -L، وحدّد اسما عبر الخيار -n، ومرّر مجموعة التّخزين الأم. على سبيل المثال، لإنشاء وحدة تخزين منطقيّة تُسمّى test من مجموعة تخزين تُسمّى LVMVolGroup، اكتب: sudo lvcreate -L 10G -n test LVMVolGroup على افتراض أنّ بمجموعة التّخزين مساحة تخزين فارغة توافق حجم وحدة التّخزين، فإنشاء وحدة التّخزين الجديدة سيتمّ بنجاح. إنشاء وحدة تخزين منطقيّة من كامل باقي المساحة الفارغة إن أردت إنشاء وحدة تخزين من باقي المساحة الفارغة على مجموعة تخزين، استعمل الأمر vgcreate مع الخيار -n لتحديد اسم لها ثمّ مرّر مجموعة التّخزين كما في السّابق. عوضا عن تمرير حجم مُعيّن، استعمل الخيار -l 100%FREE لتحديد بقيّة المساحة الفارغة في المجموعة: sudo lvcreate -l 100%FREE -n test2 LVMVolGroup إنشاء وحدات تخزين منطقيّة مع خيارات مُتقدّمة يُمكنك إنشاء وحدات تخزين منطقيّة مع خيارات مُتقدّمة كذلك. التّالي بعض من الخيارات التي يُمكن أن تأخذها بعين الاعتبار: --type: يقوم هذا الخيار بتحديد نوع وحدة التّخزين المنطقيّة ما يُحدّد كيفيّة تخصيص مساحة له. بعض من هذه الأنواع لن تكون مُتوفّرة إن لم يكن لديك الحدّ الأدنى من وحدات التّخزين الماديّة التي يتطلّبها النّوع. بعض من أكثر هذه الأنواع شيوعا هي كما يلي: linear: النّوع المبدئي. أجهزة التّخزين المُستخدمة ستُضاف بعضها على بعض واحدا تلو الآخر. striped: مُشابه لـRAID 0، تُقسّم البيانات إلى قطع صغيرة وتُنشر على شكل قوس على وحدات التّخزين الماديّة المُستعملة. ما يؤدّي إلى تحسينات في الأداء، لكن يُمكن أن يؤدي إلى زيادة في قابليّة إصابة البيانات. لتحديد هذا النّوع، يجب عليك تمرير الخيار -i ويتطلّب وحدتي تخزين ماديّتين على الأقل. raid1: إنشاء وحدة تخزين RAID 1 مُنعكسة Mirrored. مبدئيًّا، سيكون للانعكاس نُسختان، لكن يُمكنك تحديد عدد أكبر عبر الخيار -m المشروح أسفله. هذا الخيار يتطلّب وحدتي تخزين ماديّتين على الأقل. raid5: إنشاء وحدة تخزين RAID 5. يتطلّب ثلاثة وحدات تخزين ماديّة على الأقل. raid6: إنشاء وحدة تخزين RAID 6. يتطلّب أربعة وحدات تخزين ماديّة على الأقل. -m: يحدّد عدد نُسخ البيانات الإضافيّة. إن مرّرت القيمة 1 فهذا يعني بأنّ نُسخة واحدة إضافيّة من البيانات ستُصان، بحيث يكون لديك مجموعتان من نفس البيانات. -i: يُحدّد عدد الشّرائط Stripes. هذا الخيار مطلوب للنوع striped، ويُمكن أن يُؤثّر على بعض خيارات RAID الأخرى. -s: يُحدّد بأنّ أخذ لقطة يجب أن يتمّ على مُستوى وحدة التّخزين المنطقيّة الحاليّة عوضا عن إنشاء وحدة تخزين منطقيّة جديدة ومُستقلّة. سنلقي نظرة على بضعة أمثلة لهذه الخيارات لنرى حالات الاستخدام الشّائعة. لإنشاء وحدة تخزين شريطيّة Striped volume، يجب عليك تحديد شريطين على الأقل. هذه العمليّة تحتاج إلى وحدتي تخزين ماديّتين على الأقل مع مساحة تخزين متوافقة مع الحجم المُراد: sudo lvcreate --type striped -i 2 -L 10G -n striped_vol LVMVolGroup لإنشاء مساحة تخزين مُنعكسة Mirrored volume، استخدم النّوع raid1. إن أردت أكثر من مجموعتي بيانات، استعمل الخيار -m. المثال التّالي يستعمل -m 2 لإنشاء ثلاث مجموعات من البيانات (يعتبر LVM بأنّها مجموعة واحدة من البيانات مع انعكاسين). ستحتاج إلى ثلاثة وحدات تخزين ماديّة على الأقل لنجاح العمليّة: sudo lvcreate --type raid1 -m 2 -L 20G -n mirrored_vol LVMVolGroup لإنشاء لقطة لوحدة تخزين ما، يجب عليك تحديد وحدة التّخزين المنطقيّة الأصل التي ستأخذ منها اللقطة وليس كامل مجموعة التّخزين. لا تحجز اللقطات الكثير من المساحة في البدء، لكنّ حجمها يزداد كلّما أُجرِيَت تغييرات على وحدة التّخزين المنطقيّة الأصليّة. عند إنشاء لقطة ما، فالحجم المُخصّص يكون أقصى حدّ يُمكن للقطة أن تصل إليه (اللقطات التي تزيد عن هذا الحجم مُعطّلة وغير قابلة للاستخدام؛ لكن يُمكن توسيع اللقطات التي تقترب من هذا الحجم): sudo lvcreate -s -L 10G -n snap_test LVMVolGroup/test تنبيه: لإعادة وحدة تخزين إلى الحالة التي تتواجد بها اللقطة، استخدم الأمر lvconvert --merge: sudo lvconvert --merge LVMVolGroup/snap_test سيقوم هذا الأمر بإعادة اللقطة إلى الحالة التي كانت عليها عندما تمّ إنشاؤها. كما ترى، هناك العديد من الخيارات التي يُمكن لها أن تُغيّر طريقة عمل وحدة التخزين المنطقيّة بشكل كبير. زيادة حجم وحدة تخزين منطقيّة المرونة في التّعامل مع وحدات التّخزين المنطقيّة من أكثر المميّزات المتوفّرة في LVM. إذ يُمكنك بسهولة تعديل عدد أو حجم وحدات التّخزين المنطقيّة دون إيقاف النّظام. لزيادة حجم وحدة تخزين منطقيّة أنشئت مُسبقا، استعمل الأمر lvresize. مرّر قيمة إلى الخيار -L لتحديد حجم جديد. يُمكنك كذلك استخدام أحجام نسبيّة عبر الرّمز +. في هذه الحالة سيقوم LVM بإضافة الكميّة المُحدّدة إلى الحجم الكلي لوحدة التّخزين. لتعديل حجم نظام الملفّات المُستخدم على وحدة التّخزين بشكل آلي، استعمل الخيار --resizefs. لتحديد اسم صحيح لوحدة التّخزين التي ترغب بتوسيعها، سيتوجّب عليك تحديد مجموعة التّخزين، ثمّ رمز / متبوعا باسم وحدة التّخزين المنطقيّة: sudo lvresize -L +5G --resizefs LVMVolGroup/test في هذا المثال، سيتمّ زيادة 5G لكل من وحدة التّخزين test ونظام الملفّات المُستخدم. إن أردت توسيع نظام الملفّات يدويًّا، يُمكنك حذف الخيار --resizefs واستعمال أداة توسيع نظام الملفّات الخاصّة. مثلا، لو كان نظام الملفّات هو Ext4 فيُمكن أن تكتب: sudo lvresize -L +5G LVMVolGroup/test sudo resize2fs /dev/LVMVolGroup/test سيكون لهذه العمليّة نفس تأثير ما سبق. ترجمة – بتصرّف - للمقال How To Use LVM To Manage Storage Devices on Ubuntu 16.04 لكاتبه Justin Ellingwood.
  11. مُقدّمة LVM اختصار لعبارة Logical Volume Management، عبارة عن تقنيّة لإدارة أجهزة التّخزين تُمكّن المُستخدمين من توحيد وتجريد التّخطيط الماديّ لمكونات أجهزة التّخزين، لإدارتها بسهولة ومرونة. يُمكن استعمال النّسخة الحاليّة LVM2 بالاعتماد على إطار العمل الخاصّ بربط الأجهزة في نواة لينكس لجمع أجهزة التّخزين المُتوفّرة في مجموعات وتخصيص وحدات منطقيّة Logical units من المساحة المُركّبة حسب الطّلب. سنتعرّف في هذا الدليل على كيفية استخدام LVM لإدارة أجهزة التّخزين الخاصّة بك. سنرى كيفيّة عرض معلومات حول وحدات التّخزين وأهداف مُحتملة، كيفيّة إنشاء ومحو مُختلف أنواع وحدات التّخزين، وكيفيّة تعديل وحدات تخزينيّة متواجدة عبر إعادة تخصيص حجم لها وتحويلها. سنعتمد على Ubuntu 16.04 لأمثلة على تنفيذ هذه العمليّات. المُتطلّبات لمُتابعة الدّرس، يجب أن تكون قادرا على الوصول إلى خادوم Ubuntu 16.04. ستحتاج إلى مُستخدم ذي صلاحيّات sudo مع ضبط مُسبق لتمكينه من تنفيذ مهام إداريّة، غير المستخدم الجذر root. لأخذ فكرة حول مكوّنات LVM ومبادئه ولاختبار إعداد بسيط باستخدام LVM، اتّبع درس مدخل إلى LVM قبل الشّروع في هذا الدّرس. إن كنت جاهزا، ادخل إلى خادومك باستخدام حساب المُستخدم ذي صلاحيّات sudo. ملحوظة: يُفضَّل إن كانت هذه أول مرة تتعامل فيها مع LVM أو إن لم تكن متأكّدا من ما تريد فعله أن تختبر الخطوات المعروضة في هذا الدليل في آلة افتراضية أو على خادوم خاصّ بأغراض التجربة والاختبار. قد يؤدّي تنفيذ أوامر بطريقة غير صحيحة إلى ضياع البيانات. عرض معلومات حول وحدات التّخزين الماديّة، مجموعات التّخزين، ووحدات التّخزين المنطقيّة من المُهمّ أن تكون قادرا على الحصول على معلومات حول مُختلف مُكوّنات LVM في نظامك بسهولة. لحسن الحظّ، توفّر حزمة أدوات LVM كميّة وفيرة من الأدوات لعرض معلومات حول كلّ طبقة من طبقات كومة LVM. عرض معلومات حول جميع أجهزة التّخزين الكتليّة المتوافقة مع LVM لعرض جميع أجهزة التّخزين الكتليّة التي يُمكن لـLVM إدارتها، استخدم الأمر lvmdiskscan: sudo lvmdiskscan المُخرَج: /dev/ram0 [ 64.00 MiB] /dev/sda [ 200.00 GiB] /dev/ram1 [ 64.00 MiB] . . . /dev/ram15 [ 64.00 MiB] /dev/sdb [ 100.00 GiB] 2 disks 17 partitions 0 LVM physical volume whole disks 0 LVM physical volumes بتجاهل أجهزة /dev/ram* (التي تُعتبر جزءا من قرص الذاكرة العشوائيّة في لينكس)، يُمكننا مُلاحظة الأجهزة التي يُمكن استخدامها لتشكيل وحدات تخزين ماديّة لـLVM. ستكون هذه الخطوة في الغالب أول خطوة لتحديد أجهزة تخزين لاستعمالها مع LVM. عرض معلومات عن وحدات التّخزين الماديّة تُكتَب ترويسة Header على أجهزة التّخزين لتعليمها على أنها مكوّنات يُمكن لـLVM استخدامها. الأجهزة التي تحمل ترويسة تُسمّى بوحدات التّخزين الماديّة Physical Volumes. يُمكنك عرض جميع أجهزة التّخزين الماديّة على جهازك عبر استخدام الأمر lvmdiskscan مع خيار -l، ما سيُرجع وحدات التّخزين الماديّة فقط في نتيجة تنفيذ الأمر: sudo lvmdiskscan -l المُخرج: WARNING: only considering LVM devices /dev/sda [ 200.00 GiB] LVM physical volume /dev/sdb [ 100.00 GiB] LVM physical volume 2 LVM physical volume whole disks 0 LVM physical volumes الأمر pvscan مُشابه لما سبق، إذ يبحث عن جميع وحدات التّخزين الماديّة الخاصّة بـLVM. إلّا أنّ تنسيق المُخرج مُختلف نوعا ما، إذ يعرض معلومات إضافيّة: sudo pvscan المُخرج: PV /dev/sda VG LVMVolGroup lvm2 [200.00 GiB / 0 free] PV /dev/sdb VG LVMVolGroup lvm2 [100.00 GiB / 10.00 GiB free] Total: 2 [299.99 GiB] / in use: 2 [299.99 GiB] / in no VG: 0 [0 ] إن كنت ترغب بالحصول على المزيد من المعلومات، فاستعمال الأمرين pvs وpvdisplay خيار أفضل. يتميّز الأمر pvs بقابليّة تخصيصه وإمكانيّة استخدامه لعرض المعلومات في عدّة أشكال وتنسيقات مُختلفة. ولأنّ مُخرجات الأمر قابلة للتّخصيص، فاستخدامه شائع في السكريبتات أو عند الحاجة إلى أتمتة الأمور Automation. تُوفّر المُخرجات الأساسيّة للأمر خلاصة مُفيدة مُشابهة لما سبق: sudo pvs المُخرج: PV VG Fmt Attr PSize PFree /dev/sda LVMVolGroup lvm2 a-- 200.00g 0 /dev/sdb LVMVolGroup lvm2 a-- 100.00g 10.00g لمعلومات أكثر إسهابا وقابليّة للقراءة، فالأمر pvdisplay عادة ما يكون خيارا أفضل: sudo pvdisplay المُخرج: --- Physical volume --- PV Name /dev/sda VG Name LVMVolGroup PV Size 200.00 GiB / not usable 4.00 MiB Allocatable yes (but full) PE Size 4.00 MiB Total PE 51199 Free PE 0 Allocated PE 51199 PV UUID kRUOyU-0ib4-ujPh-kAJP-eeQv-ztRL-4EkaDQ --- Physical volume --- PV Name /dev/sdb VG Name LVMVolGroup PV Size 100.00 GiB / not usable 4.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 25599 Free PE 2560 Allocated PE 23039 PV UUID udcuRJ-jCDC-26nD-ro9u-QQNd-D6VL-GEIlD7 كما ترى، فالأمر pvdisplay أسهل أمر للحصول على معلومات مُفصّلة عن وحدات التّخزين الماديّة. لاستكشاف المدااءات المنطقيّة المُرتبطة بكلّ وحدة تخزين، مرّر الخيار -m إلى الأمر pvdisplay: sudo pvdisplay -m المُخرج: --- Physical volume --- PV Name /dev/sda VG Name LVMVolGroup PV Size 200.00 GiB / not usable 4.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 51199 Free PE 38395 Allocated PE 12804 PV UUID kRUOyU-0ib4-ujPh-kAJP-eeQv-ztRL-4EkaDQ --- Physical Segments --- Physical extent 0 to 0: Logical volume /dev/LVMVolGroup/db_rmeta_0 Logical extents 0 to 0 Physical extent 1 to 5120: Logical volume /dev/LVMVolGroup/db_rimage_0 Logical extents 0 to 5119 . . . يُمكن لهذا الأمر أن يكون مُفيدا لك عند الرّغبة في تحديد أي بيانات تتواجد في أي من الأقراص الماديّة لأغراض إداريّة. عرض معلومات عن مجموعات التّخزين Volume Groups يحتوي LVM على العديد من الأدوات التّي يُمكن بها عرض معلومات حول مجموعات التّخزين. يُستعملُ الأمر vgscan لفحص النّظام عن مجموعات التّخزين المتوفّرة. بالإضافة إلى إعادة بناء ملفّ التّخبئة Cache عند الحاجة. ويُعدّ أمرا جيّدا للاستخدام عند استيراد مجموعة تخزين إلى نظام جديد: sudo vgscan المُخرج: Reading all physical volumes. This may take a while... Found volume group "LVMVolGroup" using metadata type lvm2 المُخرج لا يُعطي الكثير من المعلومات، لكن يجب عليه أن يكون قادرا على إيجاد جميع مجموعات التّخزين على النّظام. لعرض المزيد من المعلومات، فالأمران vgs و vgdisplay مُتوفّران لذلك. تماما مثل مثيله المُخصّص لوحدات التّخزين الماديّة، فالأمر vgs مُتعدّد الاستعمالات ويُمكن له أن يعرض كميّة ضخمة من المعلومات في أشكال مُتعدّدة. ولأنّ إمكانيّة تخصيص مُخرجات الأمر عاليّة المرونة، فاستخدامه في برمجة السكريبتات والأتمتة أمر شائع. على سبيل المثال، من الأمور المُفيدة التي يُمكنك فعلها هي تخصيص المُخرج ليعرض فقط الأجهزة الماديّة ومسار وحدات التّخزين المنطقيّة: sudo vgs -o +devices,lv_path المُخرج: VG #PV #LV #SN Attr VSize VFree Devices Path LVMVolGroup 2 4 0 wz--n- 299.99g 10.00g /dev/sda(0) /dev/LVMVolGroup/projects LVMVolGroup 2 4 0 wz--n- 299.99g 10.00g /dev/sda(2560) /dev/LVMVolGroup/www LVMVolGroup 2 4 0 wz--n- 299.99g 10.00g /dev/sda(3840) /dev/LVMVolGroup/db LVMVolGroup 2 4 0 wz--n- 299.99g 10.00g /dev/sda(8960) /dev/LVMVolGroup/workspace LVMVolGroup 2 4 0 wz--n- 299.99g 10.00g /dev/sdb(0) /dev/LVMVolGroup/workspace لمُخرج أكثر إسهابا وقابليّة للقراءة، فالأمر vgdisplay عادة ما يكون خيارا أفضل. إضافة الخيار -v يُوفّر كذلك معلومات حول وحدات التّخزين الماديّة التّي تُشكّل مجموعة التّخزين، بالإضافة إلى وحدات التّخزين المنطقيّة التي تمّ إنشاءها باستخدام مجموعة التّخزين: sudo vgdisplay -v المُخرج: Using volume group(s) on command line. --- Volume group --- VG Name LVMVolGroup . . . --- Logical volume --- LV Path /dev/LVMVolGroup/projects . . . --- Logical volume --- LV Path /dev/LVMVolGroup/www . . . --- Logical volume --- LV Path /dev/LVMVolGroup/db . . . --- Logical volume --- LV Path /dev/LVMVolGroup/workspace . . . --- Physical volumes --- PV Name /dev/sda . . . PV Name /dev/sdb . . . الأمر vgdisplay مُفيد لقُدرته على الرّبط بين المعلومات حول مُختلف عناصر كومة LVM. عرض معلومات حول وحدات التّخزين المنطقيّة يمتلك LVM مجموعة من الأدوات لعرض معلومات عن وحدات التّخزين المنطقيّة كذلك. كما الحال مع مُكوّنات LVM الأخرى، يُمكن استعمال الأمر lvscan لفحص النّظام وعرض معلومات وجيزة حول وحدات التّخزين المنطقيّة التي يجدها: sudo lvscan المُخرج: ACTIVE '/dev/LVMVolGroup/projects' [10.00 GiB] inherit ACTIVE '/dev/LVMVolGroup/www' [5.00 GiB] inherit ACTIVE '/dev/LVMVolGroup/db' [20.00 GiB] inherit ACTIVE '/dev/LVMVolGroup/workspace' [254.99 GiB] inherit لمعلومات أكثر كمالا، يُمكنك استخدام الأمر lvs الذي يتمتّع بمرونة وقوّة بالإضافة إلى سهولة استخدامه في السكربتات: sudo lvs المُخرج: LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert db LVMVolGroup -wi-ao---- 20.00g projects LVMVolGroup -wi-ao---- 10.00g workspace LVMVolGroup -wi-ao---- 254.99g www LVMVolGroup -wi-ao---- 5.00g لإيجاد عدد شرائط Stripes وحدة التّخزين المنطقيّة ونوعها، استعمل الخيار --segments: sudo lvs --segments المُخرج: LV VG Attr #Str Type SSize db LVMVolGroup rwi-a-r--- 2 raid1 20.00g mirrored_vol LVMVolGroup rwi-a-r--- 3 raid1 10.00g test LVMVolGroup rwi-a-r--- 3 raid5 10.00g test2 LVMVolGroup -wi-a----- 2 striped 10.00g test3 LVMVolGroup rwi-a-r--- 2 raid1 10.00g يُمكن الحصول على أكثر مُخرج قابل للقراءة عبر الأمر lvdisplay. عند إضافة الخيار -m، فستعرض الأداة معلومات حول مكوّنات وحدة التّخزين المنطقيّة وكيفيّة توزيعها: sudo lvdisplay -m المُخرج: --- Logical volume --- LV Path /dev/LVMVolGroup/projects LV Name projects VG Name LVMVolGroup LV UUID IN4GZm-ePJU-zAAn-DRO3-1f2w-qSN8-ahisNK LV Write Access read/write LV Creation host, time lvmtest, 2016-09-09 21:00:03 +0000 LV Status available # open 1 LV Size 10.00 GiB Current LE 2560 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 252:0 --- Segments --- Logical extents 0 to 2559: Type linear Physical volume /dev/sda Physical extents 0 to 2559 . . . كما تُلاحظ من الجزء السّفلي للمُخرج أعلاه، فوحدة التّخزين المنطقيّة /dev/LVMVolGroup/projects متواجدة بالكامل على وحدة التّخزين الماديّة /dev/sda في هذا المثال. هذه المعلومة مُفيدة إن كنت ترغب بإزالة جهاز التّخزين المُعتمد عليه وتريد نقل البيانات إلى مكان مُحدّد. رأينا في هذا الجزء من الدليل كيفية عرض معلومات عن مختلف المكوّنات في LVM. سنكمل في الأجزاء التالية بقيّة المهام الإدارية. ترجمة – بتصرّف - للمقال How To Use LVM To Manage Storage Devices on Ubuntu 16.04 لكاتبه Justin Ellingwood.
  12. مُقدّمة بعد إنشاء جدولي المقالات والمُستخدمين في قاعدة البيانات في الدّرس السّابق، حان الوقت للتّعامل مع البيانات وإدارتها باستعمال لغة بايثون عوضا عن لغة SQL؛ في هذا الدّرس سنتعرّف على كيفيّة الوصول إلى مُفسّر بايثون في مجلّد مشروعنا وكذلك كيفيّة إضافة البيانات وجلبها من قاعدة البيانات. الوصول إلى مُفسّر بايثون داخل مُجلّد المشروع سنقوم في هذا الدّرس بالتّعامل مع قاعدة البيانات باستعمال Flask-SQLAlchemy مُباشرة من مُفسّر بايثون، إن كنت على نظام Windows فهو في الغالب متواجد في قائمة ابدأ، أمّا إن كنت على لينكس أو OSX فادخل إلى الطّرفيّة Terminal واكتب python تأكّد فقط من أنّك في مُجلّد kalima قبل أن تقوم بالوصول إلى مُفسّر بايثون، وتأكّد كذلك بأنّك قد فعّلت البيئة الوهميّة. إن لم تستطع الوصول إلى مُفسّر بايثون في مُجلّد kalima فيُمكنك تنفيذ الأمر chdir من وحدة os لتغيير المُجلّد الحالي إلى مسار مُجلّد kalima: >>> import os >>> os.chdir('path/to/kalima') مع تغيير path/to/kalima إلى مسار مُجلّد kalima في حاسوبك. مُلاحظة: الشّيفرة التّي سأقوم بتنفيذها ستُسبق بعلامة >>> أمّا المُخرج/النّتيجة فلن يُسبق بشيء. مثال: >>> site = 'Hsoub Academy' >>> site 'Hsoub Academy' بما أنّنا في مُفسّر بايثون نستطيع الوصول إلى قيمة المُتغيّر دون طباعتها، فقط اكتب اسم المُتغيّر ثم اضغط مفتاح ENTER. سنستعمل كلّا من db والصّنفين اللذ]ن يُشكلان كلّا من جدول المقالات والمُستخدمين للتّعامل مع البيانات فيها، وللوصول إلى كلّ من الكائن db والصّنفين Post و User يجب عليك أن تقوم باستيرادها: >>> from project import db >>> from project.models import Post, User إن حصلت على خطأ كما يلي: Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named project فهذا يعني بأنّك لست في مجلّد kalima لذا تأكّد من أنّك اتّبعت الإرشادات السّابقة على نحو صحيح. إدخال البيانات إلى قاعدة البيانات الآن، بعد استيراد كلّ من الكائن db والصّنفين Post وUser نستطيع القيام بأول عمليّة، ألا وهي عمليّة الإضافة، وسنُضيف أولا مُستخدما باسم khalid وبعدها سنُضيف مقالا له بعنوان Post 1. إضافة المُستخدم لإضافة مُستخدم سنُنشئ أولا كائنا من الصّنف User مع المعاملات التّي حدّدناها سابقا في دالّة init الخاصّة بالصّنف، ما يعني بأنّنا سنُنشئ مُستخدما كما يلي: user = User('khalid', 'email@example.com', 'password') وهنا يكون التّرتيب مُهمّا ومُطابقا لترتيب المُعاملات في الدّالة __init__، ويُمكنك كذلك تسميّة كلّ معامل وتغيير التّرتيب إن لم تتذكّر سوى أسماء المعاملات كما يلي: user = User(password='password', email='email@example.com',name='khalid') كما تُلاحظ عندما تذكر اسم كلّ معامل، فالتّرتيب غير مهم خلافا للمثال الأول. بعد إنشاء الكائن من صنف المُستخدم بالبيانات التّي نُريدها، يُمكننا الوصول إلى كل قيمة أو تغييرها ببساطة: >>> user = User('khalid', 'email@example.com', 'password') >>> user.name 'khalid' >>> user.email 'email@example.com' >>> user.password 'password' >>> user.email = 'khalid@example.com' >>> user.email 'khalid@example.com' >>> user <username: khalid | email: khalid@example.com > كما تُلاحظ، يُمكننا الوصول إلى كل قيمة من القيم التّي حدّدناها سابقا وكذا تعديلها بإسناد قيمة جديدة بكل بساطة. لاحظ كذلك مُخرجات آخر أمر، يُمكنك أن ترى بأنّ طريقة التّنسيق هذه هي نفسها ما قد حدّدناه سابقا في الدّالة __repr__ بالصّنف User، وإليك تذكيرا سريعا: def __repr__(self): return '<username: {} | email: {} >'.format(self.name, self.email) وأنبّه إلى أنّنا لم نغيّر أي شيء بعد في قاعدة البيانات، وإنشاء الكائن ليس سوى تمهيد لإضافته إلى جلسة تتواجد في الكائن db ثمّ تأكيد التّغييرات لإضافة المُستخدم إلى قاعدة البيانات حقيقة، ولإضافة الكائن user الذي أنشأناها قبل قليل إلى الجلسة نقوم بما يلي: >>> db.session.add(user) والجلسة هنا عبارة عن مكان لإضافة البيانات لوضعها بعد ذلك في قاعدة البيانات، وعند إضافة كل كائن إلى الجلسة لا يُضاف إلى قاعدة البيانات حقيقة إلى أن تنفّذ الأمر db.session.commit. لذا لإضافة المُستخدم خالد إلى قاعدة البيانات PostgreSQL فسننفّذ الأمر التّالي: >>> db.session.commit() بعد تنفيذ الأمر والعودة إلى أداة psql لعرض جميع البيانات في جدول المُستخدمين فستلاحظ بأنّ المُستخدم الذي أضفناه موجود بالفعل: kalima=# select * from users; id | name | email | password | created_date ----+--------+--------------------+----------+---------------------------- 1 | khalid | khalid@example.com | password | 2017-04-08 18:48:05.316805 (1 row) لاحظ بأنّ العمود id أخذ القيمة 1 رغم أنّنا لم نُحدّدها، ولو أضفنا مُستخدما آخر الآن لكان رقم مُعرّفه 2 ولو حذفت مثلا المُستخدم الذي يحمل رقم المعرّف 1 وأضفت مُستخدما آخر، فرقم مُعرّف هذا المُستخدم لن يأخذ مكان المُستخدم الأول بل سيأخذ رقما جديدا مُخالفا للأرقام السّابقة؛ ولاحظ كذلك بأنّ تاريخ الإضافة قد أضيف دون أن نقوم بتحديده يدويا. إضافة المقال بعد أن قُمنا بإضافة المُستخدم، حان الوقت لإضافة مقال خاص به، بالطّبع في التّطبيق المُستخدِم هو من سيُضيف مقالاته، وبعد تسجيله الدّخول، سنستطيع إضافة المقال ووضع قيمة مفتاح مُعرّفه كقيمة للمُعامل author_id، وسنقوم في هذا الجزء بإعطاء مثال لكيفيّة إضافة مقال وإسناد كاتب له، وفي الجزء التّالي سوف نضيف المزيد من المقالات والمُستخدمين لشرح كيفيّة الوصول إلى بيانات كل مُستخدم بما فيها مقالاته، وكذا كاتب كلّ مقال. لإضافة المقال ذي العنوان Post 1 نقوم بنفس الشّيء، أولا نُنشئ كائنا من الصّنف Post ثمّ نُسند له القيم التّي حدّدناها سابقا في الدّالة __init__ الخّاصّة بالصّنف، لكن هذه المرّة نقوم بإضافة مُعامل آخر، وهو عبارة عن قيمة رقم مُعرّف المُستخدم الذي أضاف المقال، وبما أنّنا نمتلك مُستخدما رقم مُعرّفه 1 فهذا يعني بأنّنا نستطيع أن نُسند له هذا المقال بصفته كاتبا له. >>> post = Post('Post 1', 'post 1 content', author_id=1) >>> post <title Post 1 | post 1 content > >>> db.session.add(post) >>> db.session.commit() >>> post.author <username: khalid | email: khalid@example.com > >>> post.author.name u'khalid' >>> post.author.email u'khalid@example.com' >>> post.author.password u'password' كما تُلاحظ، يُمكنك تحديد أسماء معاملات إن أردت، وترك أسماء أخرى على شرط أن تكون القيم مُرتّبة، فقد ذكرت اسم المُعامل author_id فقط لكي تفهم القيمة الثّالثة، وسيتوجّب عليك ذكر الاسم إن كان لك العديد من المفاتيح الأجنبيّة (أرقام مُعرّف تُشير إلى جداول كثيرة) لأنّها ستكون كلّها عبارة عن أرقام لا معنى لها لمن يقرأ الشّيفرة، ويجب عليك أن تتذكّر ترتيبها باستمرار، لذا من المُفضّل تجنّب هذا بذكر اسم كلّ معامل. لاحظ كذلك عندما نستدعي الكائن، فإنّ الدّالة __repr__ تستبدل كلّا من المنطقتين بالعنوان والمحتوى كما هو مُتوقّع. بعد إضافة المقال إلى الجلسة ثمّ تأكيد التّغييرات وكتابتها إلى قاعدة البيانات، أصبح بإمكاننا الآن الوصول إلى كاتب المقال عن طريق post.author والمُخرج عبارة عن كائن يحمل بيانات المُستخدم الذي أدخل البيانات كما لو أنّك حصلت عليه من قاعدة البيانات، إذ تستطيع الوصول إلى قيمة أي عمود في جدول المُستخدمين والنّتيجة تكون عبارة عن سلسلة نصيّة مسبوقة بحرف u للإشارة إلى أنّها عبارة عن Unicode وبالطّبع يُمكنك التّعامل معها كما تتعامل مع سلسلة نصيّة عاديّة. بعد الوصول إلى المُستخدم كاتب المقال، يُمكنك الحصول على مقالاته الأخرى كذلك: >>> post.author.posts.all() [<title Post 1 | post 1 content >] المُخرج عبارة عن قائمة من المقالات يُمكنك الدّوران حولها باستخدام حلقة for ولأنّنا لا نمتلك سوى مقال واحد حاليّا، سنقوم بالوصول إليه مُباشرة برقم العنصر في القائمة: >>> post.author.posts[0] <title Post 1 | post 1 content > >>> post.author.posts[0].title u'Post 1' >>> post.author.posts[0].content u'post 1 content' >>> post.author.posts[0].author <username: khalid | email: khalid@example.com > لاحظ أنّنا استطعنا الوصول إلى كاتب المقال مُجدّدا في آخر سطر، يُمكنك الاستمرار إلى ما لانهاية، المقال –> كاتبُه –> مقال كَتَبه –> كاتبُه –> مقال كَتَبه –> كاتبُه وهكذا… ما يعني بأنّ السّطر التّالي مُمكن: >>> post.author.posts[0].author.posts[0].author.posts[0].author.posts[0].author.posts[0].author.name u'khalid' بالطّبع، لا فائدة من استعمال SQLAlchemy بهذه الطّريقة، إنّما يجب عليك أن تفهم كيف يعمل، وبأنّ مثل هذه الأمور مُمكنة فربّما تُفيدك في تفادي بعض الأخطاء البرمجيّة. خاتمة تعرّفنا في هذا الدّرس على كيفيّة استعمال مُفسّر لغة بايثون للتّعامل مع قاعدة البيانات الخاصّة بنا، وتمكّنّا من إضافة سجلّ إلى جدول المُستخدمين وسجلّ آخر إلى جدول المقالات. في الدّرس القادم، سنطّلع على كيفيّة إنشاء العديد من السّجلات لنتمكّن من العمل معها في بقيّة الدّروس الخاصّة بالتّعامل مع قاعدة البيانات باستعمال مكتبة SQLAlchemy لتتمكّن من تطوير تطبيقات ويب أفضل وأكثر تعقيدا باستعمال إطار العمل Flask.
  13. تمهيد LVM اختصار لعبارة Logical Volume Management، عبارة عن تقنيّة لإدارة أجهزة التّخزين تُمكّن المُستخدمين من توحيد وتجريد التّخطيط الماديّ (الفعلي) لمكونات أجهزة التّخزين، لإدارتها بسهولة ومرونة. يُمكن استعمال النّسخة الحاليّة LVM2 بالاعتماد على إطار العمل الخاصّ بربط الأجهزة Device mapper في نواة لينكس لجمع أجهزة التّخزين المُتوفّرة في مجموعات وتخصيص وحدات منطقيّة Logical units من المساحة المُركّبة حسب الطّلب. التّجريد، المرونة والتّحكم من الميزات الرّئيسيّة لاستخدام LVM. يُمكن لوحدات التّخزين Volumes أن تحمل أسماء ذات معنى واضح مثل “database” أو “root-backup”. يُمكن إعادة ضبط حجم وحدات التّخزين ديناميكيًّا حسب تغيّر متطلّبات المساحة، يُمكن كذلك تهجيرها بين الأجهزة الماديّة داخل مجمع التخزين Storage pool أو على نظام قيد التّنفيذ. يُوفّر LVM كذلك ميزات مُتقدّمة مثل أخذ اللقطات Snapshotting، الدّمج Striping والمُطابقة Mirroring. في هذا الدّرس، سنتحدّث باختصار عن آليّة عمل LVM وبعدها سنستعرض بعضا من الأوامر التي ستحتاج إليها في البداية. مبادئ ومُصطلحات LVM قبل أن أن ننتقل إلى أوامر LVM الإداريّة، من المهمّ أن تفهم مبدئيًّا كيف ينظّم LVM أجهزة التّخزين وبعضا من المُصطلحات المُستعملة. بنيات مُدير التّخزين في LVM يعمل LVM عبر إنشاء طبقات مُجرّدة فوق أجهزة التّخزين الماديّة. الطّبقات التي يستعملها LVM بدءا بأكثرها بدائيّة هي كالتّالي: وحدات التّخزين الماديّة Physical Volumes: السابقة في أداة LVM: المقطع pv... الوصف: الأجهزة الماديّة أو الأجهزة التي تشبه الأقراص (مثلا، أجهزة تخزين أنشِئت باستعمال رابط الأجهزة Device Mapper مثل مصفوفات RAID)، وتعدّ المّادة الأساسيّة التي يستعملها LVM للطبقات العليا من التّجريد. وحدات التّخزين الماديّة عبارة عن أجهزة تخزين عاديّة. يكتب LVM ترويسة Header على الجهاز لتخصيصه ليكون قابلا للإدارة. مجموعات وحدات التّخزين Volume Groups: السابقة في أداة LVM: المقطع vg... الوصف: يجمع LVM وحدات التّخزين الماديّة في مساحات تخزينيّة موحّدة تُسمى “مجموعات وحدات التّخزين”. تجرّد مجموعات التّخزين هذه أجهزة التّخزين التّابعة لها من مواصفاتها لتعمل على شكل جهاز تخزين منطقيّ واحد مع جمع المساحات التّخزينيّة الخاصّة بوحدات التّخزين التي تُكوّن المجموعة. وحدات التّخزين المنطقيّة Logical Volumes: السابقة في أداة LVM: المقطع lv... (أدوات LVM العامّة تبدأ عادة بالمقطع lvm...) الوصف: يُمكن تقسيم مجموعة تخزين إلى أي عدد من وحدات التّخزين المنطقيّة. وحدات التّخزين المنطقيّة تُعادل وظيفيّا التجزئات Partitions في قرص ماديّ، لكنّها تتمتّع بمرونة أكثر. تعدّ وحدات التّخزين المنطقيّة المكوّن الأساسيّ الذي يتعامل معه المستخدمون والتّطبيقات. باختصار، يُمكن استعمال LVM لجمع وحدات التّخزين الماديّة في مجموعات تخزين لتوحيد مساحة التّخزين المتواجدة على نظام ما. بعدها، يُمكن للمدراء تقسيم مجموعة التّخزين إلى وحدات تخزين منطقيّة تعمل على شكل تجزئات مرنة. ما هي المداءات Extents؟ تُقسَّمُ كلّ وحدة تخزين ضمن مجموعة تخزين إلى قطع صغيرة ذات حجم ثابت تُسمّى المداءات (جمع مدى). تحدّد مجموعة التّخزين حجم المدى (جميع وحدات التّخزين بداخل المجموعة تحمل نفس حجم المدى). المداءات في وحدة تخزين ماديّة تُسمّى بالمداءات الماديّة، أمّا المداءات في وحدات التّخزين المنطقيّة فتُسمّى مداءات منطقيّة. وحدة تخزين منطقيّة عبارة ببساطة عن رابط يصونه LVM بين المداءات المنطقيّة و الماديّة. بسبب هذه العلاقة، يُمثّل حجم المداءات أصغر مقدار من المساحة التي يُمكن لـLVM تخصيصها. المداءات سبب رئيسيّ للمرونة والقوّة اللتان يتمتّع بهما LVM. إذ ليس من الضّروريّ على المداءات الماديّة الارتباط بالمداءات المنطقيّة المُمثّلة على شكل جهاز تخزين موحّد بواسطة LVM. يُمكن لـLVM نسخ وإعادة ترتيب المداءات الماديّة التي تُكوّن وحدة تخزين منطقيّة دون إعاقة سير الأمور بالنّسبة للمُستخدم. يُمكن كذلك توسيع أو تقليص وحدات التّخزين المنطقيّة ببساطة عبر إضافة أو إزالة المداءات من وحدة التّخزين. حالة الاستخدام البسيطة والآن بعد أن تعرّفنا على بعض من المُصطلحات والبنيات التي يستعملها LVM، يُمكننا استكشاف بعض من أكثر استخدامات LVM شيوعا. سنبدأ التّعرّف على إجراء بسيط يُمكّننا من استعمال قرصين ماديّين لإنشاء أربع وحدات تخزين منطقيّة. تنبيه: تأكّد من أنّ الأجهزة التّي ترغب باستعمالها مع LVM لا تحتوي على أيّة بيانات مُهمّة. استخدام هذه الأجهزة مع LVM سيؤدّي إلى الكتابة فوق المحتويات الحاليّة. إذا كانت لديك بيانات مهمّة على خادومك فأنشئ نسخا احتياطية قبل الاستمرار في تطبيق الدّرس. إن كنت تريد استكشاف آلية العمل بأمان فالأفضل أن تستخدم آلة افتراضية للتطبيق عليها. تحديد الأجهزة الماديّة Physical Devices لتُشكّل وحدات تخزين ماديّة Physical Volumes أول خطوة هي فحص النّظام للوصول إلى الأجهزة التّي يُمكن لـLVM رؤيتها وإدارتها. يُمكنك القيام بهذه الخطوة عبر كتابة ما يلي في الطّرفيّة: sudo lvmdiskscan المُخرَج سيكون عبارة عن قائمة بجميع الأجهزة التّي يُمكن لـLVM التّعامل معها: /dev/ram0 [ 64.00 MiB] /dev/sda [ 200.00 GiB] /dev/ram1 [ 64.00 MiB] . . . /dev/ram15 [ 64.00 MiB] /dev/sdb [ 100.00 GiB] 2 disks 17 partitions 0 LVM physical volume whole disks 0 LVM physical volumes من المُخرج أعلاه، يُمكننا أن نرى بأنّنا نتوفّر على قرصين و17 تجزئة. مُعظم التجزئات عبارة عن قرص ذاكرة عشوائيّة /dev/ram* لزيادة الأداء. الأقراص في هذا المثال هي /dev/sda الذي يحتوي على 200G من المساحة، و /dev/sdb ذي المساحة 100G. بعد تحديد الأجهزة الماديّة التي نريد استخدامها، يُمكننا الآن تخصيصها لتكون وحدات تخزين ماديّة داخل LVM باستخدام الأمر pvcreate: sudo pvcreate /dev/sda /dev/sdb المُخرَج: Physical volume "/dev/sda" successfully created Physical volume "/dev/sdb" successfully created ستقوم هذه العمليّة بكتابة ترويسة LVM على الأجهزة للإشارة إلى أنّها جاهزة للإضافة إلى مجموعة تخزين. يُمكنك التّحقّق من أنّ وحدات التّخزين الماديّة قد سُجّلت بنجاح من طرف LVM عبر كتابة الأمر التّالي: sudo pvs المُخرج: PV VG Fmt Attr PSize PFree /dev/sda lvm2 --- 200.00g 200.00g /dev/sdb lvm2 --- 100.00g 100.00g كما ترى، كلا الجهازان مُتواجدان تحت عمودPV (اختصار لـPhysical Volume). إضافة وحدات التّخزين الماديّة إلى مجموعة تخزين بعد أن أنشأنا وحدات تخزين ماديّة من أجهزتنا، يُمكننا الآن إنشاء مجموعة تخزين. سيتوجّب علينا اختيار اسم لمجموعة التّخزين، سنختار اسما عامّا لتبسيط الأمور. في معظم الأوقات، ستجد مجموعة واحدة فقط لكل نظام من أجل الحصول على أقصى درجة من المرونة في التّخصيص. سنُسمّي مجموعة التّخزين الخاصّة بنا بالاسم LVMVolGroup لتبسيط الأمور. لإنشاء مجموعة تخزين وإضافة وحدتي التّخزين الماديّتين إليها في أمر واحد، اكتب ما يلي: sudo vgcreate LVMVolGroup /dev/sda /dev/sdb المُخرج: Volume group "LVMVolGroup" successfully created إن اطّلعنا على مُخرج الأمر pvs مُجدّدا، يُمكننا أن نرى بأنّ وحدتي التّخزين الماديّتين أصبحتا مرتبطتين بمجموعة التّخزين الجديدة: sudo pvs المُخرَج: PV VG Fmt Attr PSize PFree /dev/sda LVMVolGroup lvm2 a-- 200.00g 200.00g /dev/sdb LVMVolGroup lvm2 a-- 100.00g 100.00g يُمكننا الحصول على خلاصة موجزة لمجموعة التّخزين عبر الأمر التّالي: sudo vgs المُخرَج: VG #PV #LV #SN Attr VSize VFree LVMVolGroup 2 0 0 wz--n- 299.99g 299.99g كما ترى، مجموعة التّخزين الخاصّة بنا تمتلك وحدتي تخزين ماديّتين، دون أية وحدات تخزين منطقيّة، كما لها مساحة تخزين تُساوي مجموعة مساحتي الجهازيْن المُستخدمين. إنشاء وحدات تخزين منطقيّة من مجموعة التّخزين المُوحّدة الآن وقد أصبحت لدينا مجموعة تخزين، يُمكننا استخدامها لتخصيص وحدات تخزين منطقيّة منها. على عكس تقسيم القرص التّقليديّ، فعند العمل مع وحدات التّخزين المنطقيّة، لا تحتاج إلى معرفة تخطيط وحدة التّخزين لأنّ LVM يتكلّف بالأمر من أجلنا. ستحتاج فقط إلى تمرير حجم وحدة التّخزين واسم لها. سننشئ أربعة وحدات تخزين منطقيّة من مجموعة التّخزين الخاصّة بنا: وحدة تخزين باسم projects بمساحة 10G، وحدة تخزين www بمساحة 5G لمحتوى الوِب، وحدة تخزين db بمساحة 20G لقاعدة البيانات، وحدة تخزين workspace للاستفادة من باقي المساحة. لإنشاء وحدات تخزين منطقيّة، نستعمل الأمر lvcreate. سيتوجّب علينا تمرير اسم مجموعة التّخزين، ويُمكننا تسميّة وحدة التّخزين المنطقيّة باستخدام الخيار n-. ولتحديد حجم المساحة مُباشرة، يُمكنك استخدام الخيار L-. إن أردت تحديد الحجم حسب عدد النّطاقات، يُمكنك استعمال الخيار l-. يُمكننا إنشاء أول ثلاثة وحدات تخزين منطقيّة باستخدام الخيار L- كالتّالي: sudo lvcreate -L 10G -n projects LVMVolGroup sudo lvcreate -L 5G -n www LVMVolGroup sudo lvcreate -L 20G -n db LVMVolGroup المُخرَج: Logical volume "projects" created. Logical volume "www" created. Logical volume "db" created. يُمكننا الاطّلاع على وحدات التّخزين المنطقيّة وعلاقتها بمجموعة التّخزين عبر تحديد مُخرج مُخصّص من الأمر vgs كما يلي: sudo vgs -o +lv_size,lv_name المُخرج: VG #PV #LV #SN Attr VSize VFree LSize LV LVMVolGroup 2 3 0 wz--n- 299.99g 264.99g 10.00g projects LVMVolGroup 2 3 0 wz--n- 299.99g 264.99g 5.00g www LVMVolGroup 2 3 0 wz--n- 299.99g 264.99g 20.00g db أضفنا آخر عمودين لنرى الحجم المُخصّص لكلّ وحدة تخزين منطقيّة. الآن، يُمكننا إسناد بقيّة المساحة في مجموعة التّخزين إلى وحدة التّخزين workspace باستعمال الخيار -l، التي تعمل حسب مبدأ المداءات. يُمكننا أيضا توفير نسبة مئويّة ووحدة قياس لإيصال الفكرة على نحو أوضح. في حالتنا، نريد أن نُخصّص باقي المساحة الفارغة، لذا سنُمرّر القيمة 100%FREE: sudo lvcreate -l 100%FREE -n workspace LVMVolGroup المُخرج: Logical volume "workspace" created. إذا أعدنا التّحقّق من معلومات مجموعة التّخزين، سنُلاحظ بأنّنا قد استعملنا كافّة المساحة المُتوفّرة: sudo vgs -o +lv_size,lv_name المُخرَج: VG #PV #LV #SN Attr VSize VFree LSize LV LVMVolGroup 2 4 0 wz--n- 299.99g 0 10.00g projects LVMVolGroup 2 4 0 wz--n- 299.99g 0 5.00g www LVMVolGroup 2 4 0 wz--n- 299.99g 0 20.00g db LVMVolGroup 2 4 0 wz--n- 299.99g 0 264.99g workspace كما ترى، فقد أُنشِئت وحدة التّخزين workspace ومجموعة التّخزين LVMVolGroup وقد خُصِّصتا بالكامل. تهيئة وتركيب وحدات التّخزين المنطقيّة أصبحت لدينا الآن وحدات تخزين منطقيّة جاهزة للاستعمال، يُمكننا استخدامها كما تُستَخدَم أجهزة التخزين العاديّة. الأجهزة المنطقيّة متواجدة داخل المُجلّد /dev/ كأي جهاز تخزين آخر. يُمكنك الوصول إليها بطريقتين: /dev/volume_group_name/logical_volume_name /dev/mapper/volume_group_name-logical_volume_name مع تغيير قيمة volume_group_name باسم مجموعة التّخزين، وتغيير قيمة logical_volume_name باسم وحدة التّخزين المنطقيّة. لذا لتهيئة وحدات التّخزين المنطقيّة الخاصّة بنا باستخدام نظام الملفّات Ext4، يُمكن أن نكتب ما يلي: sudo mkfs.ext4 /dev/LVMVolGroup/projects sudo mkfs.ext4 /dev/LVMVolGroup/www sudo mkfs.ext4 /dev/LVMVolGroup/db sudo mkfs.ext4 /dev/LVMVolGroup/workspace أو كما يلي: sudo mkfs.ext4 /dev/mapper/LVMVolGroup-projects sudo mkfs.ext4 /dev/mapper/LVMVolGroup-www sudo mkfs.ext4 /dev/mapper/LVMVolGroup-db sudo mkfs.ext4 /dev/mapper/LVMVolGroup-workspace بعد التّهيئة، يُمكننا إنشاء نقاط تركيب Mount points كما يلي: sudo mkdir -p /mnt/{projects,www,db,workspace} بعدها يُمكننا تركيب وحدات التّخزين المنطقيّة على المسار المُناسب: sudo mount /dev/LVMVolGroup/projects /mnt/projects sudo mount /dev/LVMVolGroup/www /mnt/www sudo mount /dev/LVMVolGroup/db /mnt/db sudo mount /dev/LVMVolGroup/workspace /mnt/workspace لتركيب النّقاط بطريقة دائمة، أضفها إلى /etc/fstab كما لو كانت أجهزة تخزين عاديّة: sudo nano /etc/fstab نضيف ما يلي إلى نهاية الملفّ: /dev/LVMVolGroup/projects /mnt/projects ext4 defaults,nofail 0 0 /dev/LVMVolGroup/www /mnt/www ext4 defaults,nofail 0 0 /dev/LVMVolGroup/db /mnt/db ext4 defaults,nofail 0 0 /dev/LVMVolGroup/workspace /mnt/workspace ext4 defaults,nofail 0 0 يجب على نظام التّشغيل الآن أن يركّب وحدات التّخزين المنطقيّة الخاصّة بـLVM آليًّا عند التشغيل. ختاما نأمل أن يكون لديك الآن فهم جيّد لمُختلف المُكوّنات التّي يُديرها LVM لإنشاء نظام تخزين مرن. يجب كذلك أن تكون لديك قدرة على إنشاء أجهزة واستعمالها مع LVM. هذا الدّرس مجرّد مُقدّمة وجيزة لما يُمكن لـLVM توفيره لمُدراء أنظمة Linux. للاستزادة حول كيفيّة العمل مع LVM، ألق نظرة على درس كيفيّة استخدام LVM مع Ubuntu 16.04. ترجمة - بتصرّف - للمقال An Introduction to LVM Concepts, Terminology, and Operations لكاتبه Justin Ellingwood.
  14. مقدّمة بعد أن تعرّفنا على كيفيّة تجهيز جدولي المقالات والمُستخدمين اللّذين سيُشكّلان أساس بيانات تطبيقنا، وبعد أن تعرّفنا في الدّرس السّابق على كيفيّة الرّبط بين الجدولين ليكون لكلّ كاتب مقالاته ولكل مقال كاتب خاص به، حان الوقت لإنشاء الجدولين في قاعدة البيانات والتّعرّف على كيفيّة استغلال كلّ من مكتبة SQLAlchemy وإضافة Flask-SQLAlchemy للتّعامل مع البيانات. لماذا الدّروس القادمة أساسيّة؟ هذا الدّرس والدّروس القادمة مُهمّة لك إن كنت ترغب بالاعتماد على قواعد بيانات SQL ومكتبة SQLAlchemy في تطوير تطبيقاتك، وما ستتعلّمه من هذه الدروس سيُفيدك في حالات كثيرة، وستتمكّن من القيام بأكثر العمليّات شيوعا باستخدام SQLAlchemy عوضا عن لغة SQL ما سيبقي شفرتك نظيفة وسيُمكّنك من العمل مع بياناتك بأريحيّة أكثر. ورغم أنّنا لن نستعمل الكثير من الأشياء التّي سأذكرها في تطبيق “كلمة”، إلّا أنّ الإلمام بها مهم جدّا، وعندما أقول بأنّ هذه المفاهيم مهمّة فأنا لا أعني أن تحفظها عن ظهر قلب، إذ يُمكنك أن تعود إلى درس مُعيّن في كلّ مرّة تُريد أن تتذكّر كيفيّة القيام بعمليّة معيّنة باستخدام مكتبة SQLAlchemy وإضافة Flask-SQLAlchemy، وأشجّعك على توظيف كل ما ستتعلّمه لإضافة ميّزات جديدة إلى التّطبيق الذي سنبنيه سويّا (مثلا إضافة جزء لعرض مقال عشوائي في كلّ مرّة يُعاد فيها تحميل الصّفحة)، وإن أردت أن تعرف كيفيّة القيام بعمليّة أخرى من عمليّات SQL التّقليديّة باستخدام SQLAlchemy فعد أولا إلى التّوثيق الرّسمي للمكتبة أو ضع سؤالا مصاغا بوضوح ولغة سليمة في قسم الأسئلة والأجوبة للحصول على إجابة كافيّة. إنشاء جدولي المقالات والمُستخدمين في قاعدة البيانات بعد أن أنشأنا الصّنفين المسؤولين عن إنشاء الجدولين في ملفّ models.py الذي يقع تحت مُجلّد project أصبح بإمكاننا إنشاء الجدولين عن طريق مكتبة SQLAlchemy اعتمادا على محتويات ملفّ models.py والكائن db الذي سبق لنا وأنشأناها بمُساعدة إضافة Flask-SQLAlchemy. بعد إنشاء الجدولين، ستُطبّق التّغييرات مُباشرة إلى خادوم PostgreSQL الذي نُصّب بجهازك المحلي، ما يعني بأنّك ستتمكّن من التّعامل مع قاعدة البيانات باستخدام لغة SQL والميّزات التي تُوفّرها قاعدة البيانات PostgreSQL. لإنشاء الجدولين في قاعدة بياناتنا، سنقوم أولا بإنشاء ملف باسم create_db.py في المجلّد الرّئيسي kalima وسنضع به ثلاثة أسطر فقط: # create_db.py from project import db from project.models import Post, User db.create_all() تأكّد فقط من أنّ إعداد SQLALCHEMY_DATABASE_URI يُشير إلى قاعدة بيانات PostgreSQL التّي أنشأناها سابقا باسم kalima وأنّ اسم المُستخدم وكلمة المرور صحيحان في ذات الإعداد، وللمزيد أعد إلقاء نظرة على درس تجهيز قاعدة البيانات PostgreSQL ودرس إنشاء جداول البيانات. كما تُلاحظ، الشّفرة بسيطة، أولا نستدعي الكائن db من حزمة المشروع، ثمّ نستدعي كلّا من الصّنف Post وUser لإعلام SQLAlchemy بأنّنا قد حدّدنا هذه الجداول والأعمدة الأساسيّة فيها، وبعد ذلك نقوم بإنشاء الجداول في قاعدة البيانات باستعمال الدّالة db.create_all. وبنفس الطّريقة لو أردت حذف الجداول يُمكنك استدعاء الدّالة db.drop_all عوضا عن db.create_all. وإن أمكنك الوصول إلى سطر أوامر PostgreSQL عن طريق أداة psql فيُمكنك الاتّصال بقاعدة البيانات kalima وعرض الجداول فيه، بالأمرين التّاليين: postgres=# \c kalima You are now connected to database "kalima" as user "postgres". kalima=# \d No relations found. الأمر الأول للاتّصال بقاعدة البيانات الخاصّة بتطبيقنا، وذلك لأنّ الخادوم يحتوي على أكثر من قاعدة بيانات واحدة، أمّا الأمر الثّاني فهو لعرض الجداول المُتواجدة بقاعدة البيانات، وبما أنّنا لم ننفّذ ملفّ create_db.py بعد فالنّتيجة هي بطبيعة الحال أنّنا لا نمتلك أية جداول أو علاقات كما تُلاحظ من الرّسالة No relations found. الآن، نفّذ الملفّ عبر الأمر: python create_db.py إن لم تلاحظ أية رسالة، فهذا يعني بأنّ كل شيء بخير، ولو عدت إلى سطر أوامر psql وأعدت تنفيذ الأمر \d للاحظت ما يلي: List of relations Schema | Name | Type | Owner --------+--------------+----------+---------- public | posts | table | postgres public | posts_id_seq | sequence | postgres public | users | table | postgres public | users_id_seq | sequence | postgres ربّما تختلف قيمة العمود Owner لديك لأنّها تُشير إلى اسم المُستخدم الذي أنشأ الجداول أو مالكها، وهذا الاسم هو نفسه الذي تُحدّده في إعداد قاعدة البيانات الذي سبق وأن أشرنا إليه، لاحظ معي فقط كلّا من الجدول posts و الجدول users: public | posts | table | postgres public | users | table | postgres بما أنّ نوع العلاقة هو table (جدول)، فهذا يعني بأنّنا استطعنا إنشاء الجدولين بنجاح، ونستطيع الآن التّعامل معه بلغة SQL مباشرة من أداة psql. في ما يلي استعلامان يُمكنك تنفيذهما للحصول على جميع السّجلات في كلّ جدول: select * from posts; select * from users; بالطّبع، لأنّنا لم نُضف أية سجلّات بعد، فالمُخرج سيكون كما يلي في كلتا الحالتين: Posts Table: id | title | content | created_date | author_id ----+-------+---------+--------------+----------- (0 rows) Users Table: id | name | email | password | created_date ----+------+-------+----------+-------------- (0 rows) وكما تُلاحظ، جميع الأعمدة التّي سبق وأن حدّدناها في ملفّ models.py باستعمال db.Column متواجدة في هذين الجدولين. يُمكنك بالطّبع إضافة بعض السّجلّات بلغة SQL إن أردت ذلك بالاعتماد على جملة INSERT INTO وكذا التّعامل مع البيانات بمُختلف الطّرق التّي تُتيحها PostgreSQL، ولكنّنا لن نستعمل لغة SQL لأنّنا نمتلك أداة SQLAlchemy وإضافة فلاسك الخاصّة به. ختاما تعرّفنا في هذا الدّرس على كيفيّة إنشاء جدولي المقالات والمُستخدمين في قاعدة البيانات مُباشرة باستعمال الدّالة db.create_all() التّي توفّرها لنا إضافة Flask-SQLAlchemy. في الدّرس القادم، سنتعرّف على كيفيّة استعمال مُفسّر لغة بايثون للتعامل مع قاعدة البيانات بمُساعدة من مكتبة SQLAlchemy، وبذلك سنتمكّن من التواصل مع قاعدة البيانات وإدارة سجلات الجداول فيها.
  15. مُقدّمة: بعد أن عرّفنا كلّا من جدول المقالات وجدول المُستخدمين، بقيت لنا خطوة الرّبط بينهما ليُشير كلّ مقال إلى كاتبه ونستطيع الوصول إلى مقالات كلّ مُستخدم، وسنقوم بهذا الأمر باستغلال خصائص قواعد بيانات SQL العلائقيّة لإنشاء علاقة واحد للعديد، بحيث يُمكن لكلّ مُستخدم أن يمتلك العديد من المقالات ويكون لكلّ مقال كاتب واحد فقط. المُشكلة عند تصفّحك لتطبيقات الوب في وقتنا الحالي، ستُلاحظ بأنّ المُستخدمين يمتلكون بياناتهم الخاصّة، مثلا يُمكن للمُستخدم الواحد أن يمتلك عدّة مقالات وتدرج تحت اسمه، ويُمكن أن يمتلك كذلك عدّة تعليقات باسمه، إذن كيف يُمكن أن نُدرج مقالات من جدول المقالات الخاصّ بنا إلى المُستخدم الذي يقوم بإضافتها؟ بمعنى آخر، كيف يُمكن للمُستخدم الواحد أن يمتلك عدّة مقالات مُندرجة باسمه؟ الحل الخاطئ الطّريقة التّي يُمكن أن تُفكّر فيها هي بإدراج رقم مُعرّف كل مقال يُضيفه المُستخدم إلى عمود خاص به مع الفصل بينها بمسافة أو شيء من هذا القبيل، بعدها تحصل عليها وتقوم باستخراج مقالات كل مُستخدم. الجدول سيكون كما يلي: id | name | posts 1 | Ali | 1, 3, 5 ... أهملت هنا عمودي البريد الإلكتروني وكلمة المرور لأنّها غير مُهمّة في مثالنا. الآن إن نظرت إلى العمود posts فستجد بأنّ المقالات ذات المُعرّفات 1 و 3 و 5 قد أضافها المُستخدم Ali. هذه الطّريقة فكرة سيّئة جدّا، فلو أردنا حذف مقال فحذف علاقته بالمُستخدم أمر مُعقّد، وهناك العديد من المشاكل مع استخدام هذه الطّريقة، وقد أشرت إليها لأنّها شائعة جدّا ويجب أن تحذفها من ذهنك قبل أن تحدث أمور أسوأ، فإن أردت أن تكون مُطوّر وب جيّدا فعليك تعلّم الطّرق الصّحيحة وعليك كذلك الإلمام بالطّرق الخاطئة في التّطوير. الطّريقة الصّحيحة لربط سجلّ واحد بالعديد من السّجلّات في جدولين مُختلفين علاقة الواحد-للعديد أو One-to-Many Relationship هي طريقة لربط جدولين أو أكثر بحيث يمتلك كلّ فرد في جدول العديد من السّجلّات في جدول آخر. في مثالنا، سيمتلك المُستخدم الواحد عدّة مقالات باسمه. للقيام بهذا الأمر، نقوم بوضع عمود آخر في الجدول الذي سيمتلك العديد من السّجلّات الخاصّة بفرد واحد من جدول آخر ليحمل قيمة رقم مُعرّف هذا الفرد، أي أننا سنُضيف عمودا آخر في جدول المقالات ليحمل رقم مُعرّف المُستخدم الذي أضاف المقال ليكون جدول المقالات كما يلي: | id | title | user_id | 1 | Post 1 | 1 | 2 | Post 2 | 2 | 3 | Post 3 | 1 | 4 | Post 4 | 3 لنفترض بأنّ لدينا ثلاثة مُستخدمين في جدول المُستخدمين كما يلي: | id | name | 1 | Ali | 2 | Abdelhadi | 3 | Hassan مُجدّدا، قمت بإهمال الأعمدة الأخرى لأنّها لا تهمّنا في هذا المثال، وكما تُلاحظ لكل مقال قيمة في عمود user_id لتُشير إلى المُستخدم الذي أنشأ هذا المقال، وعند النّظر إلى جدولي المقالات والمُستخدمين والسّجلّات المتواجدة فيها حاليّا، يتبيّن لنا بأنّ المستخدم Ali قد أضاف مقالين، المقال ذو رقم المُعرّف 1 و المقال ذو رقم المُعرّف 3، أمّا Abdelhadi فهو صاحب المقال ذي المُعرّف 2 أمّا المقال الأخير فمن الواضح بأنّ المُستخدم Hassan هو من أضافه. هذه هي علاقة الواحد للعديد ببساطة، عندما يمتلك سجلّ واحد من جدول العديد من السّجلّات في جدول آخر، فإنّنا نُضيف عمودا إلى الجدول الذي يحمل العديد من السّجلات ليحمل كل سجلّ منه قيمة المفتاح الأولي Primary Key للسّجل الواحد في الجدول الآخر والذي يُسمّى فيه مفتاحا أجنبيا Foreign Key، أي أنّ العمود user_id عبارة عن مفتاح أجنبي لأنّه يحمل قيمة المفتاح الأولي الخاصّ بالمُستخدم، وعندما نقوم بتحديد عمود على أنّه مفتاح أجنبي، فالعلاقة بين الجدولين تكون مفهومة بالنّسبة لقاعدة البيانات لدينا، كما يُساعدنا ذلك على تخطّي بعض المشاكل في حالة ما أضيفت قيمة خاطئة إلى العمود عوضا عن قيمة صحيحة. في SQLAlchemy يُمكننا إنشاء علاقة واحد للعديد بسهولة وبساطة بإضافة سطرين فقط إلى الشفرة التّي حدّدناها سابقا، سطر في صنف (جدول) المقالات لإضافة عمود باسم author_id والذي سيكون عبارة عن مفتاح أجنبي يُشير إلى قيمة المفتاح الأولي للمُستخدم، وسطر في صنف المُستخدم لنتمكّن من الوصول إلى مقالات كل مُستخدم ببساطة. أضف هذا السّطر في آخر الصّنف Post: # project/models.py author_id = db.Column(db.Integer, db.ForeignKey('users.id'), nullable=False) لتعريف مفتاح أجنبي، نستعمل الدّالة db.ForeignKey مع تمرير اسم الجدول واسم المفتاح الأولي مفصولين بنُقطة (في هذا المثال users.id) ونقوم كذلك بإضافة المُعامل nullable وإسناد القيمة المنطقيّة False له للتأكّد من أنّ الحقل الذي يربط بين المُستخدم والمقال الذي أضافه لا يحمل قيمة فارغة. بعد إضافة المفتاح الأجنبي، حان الوقت لإخبار SQLAlchemy بأنّنا نريد الحصول على مقالات كلّ مُستخدم، والمُستخدم الذي أضاف كلّ مقال انطلاقا من العلاقة بين الجدولين، لذا أضف السّطر التّالي في آخر الصّنف User: # project/models.py posts = db.relationship("Post", backref="author", lazy="dynamic") في هذا السّطر، نقوم بتعريف العلاقة بين المُستخدم والمقال عن طريق الدّالّة db.relationship مع تمرير ثلاثة مُعاملات، الأول عبارة عن اسم الصّنف الذي يشير لجدول المقالات، والمُعامل backref يُمكّننا من الوصول إلى المُستخدم الذي كتب المقال عن طريق الاسم author أمّا المعامل الأخير فهو لتحديد نوعيّة النّتيجة التّي سنحصل عليها عند طلب جميع المقالات التّي كتبها أحد المُستخدمين، وقد وضعنا القيمة dynamic لتكون النّتيجة عبارة عن استعلام ديناميكي لجميع المقالات التّي كتبها المُستخدم، وهكذا سنحصل على مرونة أكثر عند طلب المقالات وسنتمكّن من التّعامل معها على أنّها كائنات يُمكننا استغلالها بجميع ما توفّره مكتبة SQLAlchemy من طرق ودوال مُساعدة، وسنرى تطبيقا لهذا الكلام فيما بعد. سنُضيف كذلك عمود author_id إلى التّابع __init__ الخاصّة بالصّنف Post وبالتّالي سيُصبح التّابع كما يلي: def __init__(self, title, content, author_id, created_date = None): self.title = title self.content = content self.author_id = author_id self.created_date = datetime.utcnow() بعد تحديد العلاقة بين الجدولين، سنستطيع إضافة مقال وإسناد رقم مُعرّف المُستخدم أو المُستخدم ككاتب للمقال الذي أضافه لنتمكّن فيما بعد من الحصول على كاتب كل مقال بجميع معلوماته (بريده الإلكتروني، اسمه …)، وكذا المقالات التّي كتبها كلّ مُستخدم مع مرونة في التّعامل معها عبر ما تُوفّره لنا مكتبة SQLAlchemy من مُساعدة. خاتمة بعد أن تعرّفنا على طريقة ربط المُستخدم ومقالاته والمقالات وكاتبها، أصبحنا نستطيع تطبيق التّغييرات إلى قاعدة بياناتنا والتّعامل مع السّجلّات بعمليّات قواعد البيانات المعروفة اختصارا بـCRUD أو Create, Read, Update, Delete، أي الإضافة/الإنشاء، القراءة/العرض، التّعديل والحذف.