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

يتوقف ووردبريس عن العمل في بعض الأحيان، فعند زيارة موقعك ستجد صفحة بيضاء فارغة والتي يشار إليها بـ "شاشة الموت البيضاء" ("white screen of death"). سيكون هذا الأمر محبطا للغاية وسيتسبب لك بمشاكل خاصةََ وأنك لا ترى أية أخطاء PHP تخبرك سبب المشكلة. يمكنك تخمين سبب المشكلة، لكن سيتطلب هذا وقتا طويلا، ولحسن الحظ، توجد خطوات يمكنك اتباعها لاكتشاف المشكلة بسرعة. في هذا الدرس، سنلقي نظرة على عملية اكتشاف أخطاء الشاشة البيضاء، والتي قد تتضمن بعضا من البرمجة أو استخدام الملحقات، وباتباع هذه الملاحظات، سيعود موقعك للعمل في وقت قصير للغاية. اكتشاف الأخطاء وإصلاحها عن طريق البرمجة إن ملف wp-config.php الموجود في مجلد الجذر لووردبريس هو مفتاح اكتشاف الخطأ في موقعك. كل ما تحتاجه هو إضافة بضعة أسطر برمجية لتشغيل وضع التنقيح (debugging) في موقعك. إن تشغيل وضع التنقيح سيعرض لك قائمة الأخطاء الحالية، إذا كان موقعك مثبّتًا محليا، ستحتاج إلى إضافة هذا السطر إلى ملف wp-config.php: define( 'WP_DEBUG', true ); ضعه فوق السطر التالي: /* That's all, stop editing! Happy blogging. */ إذا وجدت شيفرة WP_DEBUG موجودة في ملف wp-config.php، فقم ببساطة بجعلها true بدون علامات الاقتباس. إذا كنت على موقع حي (على الإنترنت)، لا تستخدم هذه الشيفرة البرمجية لأن جميع الأخطاء ستظهر في الصفحة الرئيسية لموقعك بالإضافة إلى مسار ملفاتك وجميع البيانات الأخرى الحساسة. وبدلا من ذلك توجد طريقة أخرى لتفعيل التنقيح على المواقع المباشرة والحد من رسائل الخطأ إلى ملف سجل خاص فقط. لتفعيل سجل الخطأ والتنقيح للمواقع الحية، أدخل الشيفرة البرمجية التالية إلى ملف wp-config.php فوق سطر Happy blogging: // Enable WP_DEBUG mode define('WP_DEBUG', true); // Enable Debug logging to the /wp-content/debug.log file define('WP_DEBUG_LOG', true); // Disable display of errors and warnings define('WP_DEBUG_DISPLAY', false); @ini_set('display_errors',0); // Use dev versions of core JS and CSS files (only needed if you are modifying these core files) define('SCRIPT_DEBUG', true); إذا عدّلت أية ملفات جافاسكربت أو CSS قبل أن يعرض موقعك شاشة الموت البيضاء، فضمّن السطر الأخير في المثال أعلاه، أما إذا لم تقم بأية تعديلات من هذا النوع، فيمكنك ترك هذا السطر. لا تنس أنه إذا وجدت هذه الشيفرات البرمجية موجودة بالفعل، فقم ببساطة بتبديل القيم المنطقية (true/false) كما في المثال أعلاه. بمجرد أن تنتهي من ذلك، يمكنك التأكد من رسائل الخطأ في الواجهة الأمامية (front end) لموقعك للتثبيتات المحلية و في سجل الأخطاء في التثبيتات الحية والذي ستجده في wp-content/debug.log/ بين ملفات ووردبريس الخاصة بك. عندما تتحقق وتجد الخطأ، يمكنك البدء في إصلاحه. استكشاف الأخطاء وإصلاحها باستخدام ملحق توجد العديد من الملحقات التي يمكنها مساعدتك في اكتشاف وإصلاح أخطاء موقعك، فإذا كنت لا تزال تستطيع الوصول إلى لوحة التحكم الخاصة بإدارة الموقع، فيمكنك تثبيت ملحق لمساعدتك في معرفة الأخطاء. لتشغيل وضع التنقيح فقط، يمكنك استخدام ملحق Debug، أما لو أردت المزيد من الخيارات لاكتشاف وإصلاح الأخطاء فيمكنك استخدام ملحق Debug Bar. بالنسبة للنسخة مُتعدّدة المواقع من ووردبريس (Multisite installs)، يوجد ملحق مخصص للشبكات والمدراء الكبار للأنظمة لاكتشاف وإصلاح الأخطاء ويسمى بـ Debug This، ويحتوي هذا الملحق على تفاصيل أكثر من أي ملحقات تنقيح أخرى. هذه الملحقات الثلاثة موثوق بها ويتم تحديثها باستمرار لضمان الجودة والاستقرار، بمجرد اختيار واحدة، ثبّتها وابدأ في البحث عن الأخطاء التي تحتاج إلى إصلاح. التحقق من سجل الأخطاء في لوحة التحكم إذا كنت تستخدم cPanel، يمكنك التأكد من سجل الأخطاء بالنقر على زر Error Log الموجود في قسم Logs. إذا كنت تستخدم Plesk، فانقر على علامة تبويب Files الموجودة في أعلى الصفحة، ثم اختر السجلات في القائمة الموجودة على يسار الصفحة، ثم اختر error_log من القائمة. إذا كنت تستخدم نوعًا آخر من لوحات التحكم ولم تعرف كيف تصل إلى سجل الأخطاء، فتحقق من شركة الاستضافة أو ابحث في جوجل على الإجابة. نصائح أخرى مفيدة توجد أشياء أخرى يمكنها مساعدتك على تصحيح الوضع ومعرفة سبب المشكلة. عد إلى قالب Twenty Fifteen الافتراضي، فإذا اختفت الشاشة البيضاء وظهر موقعك فهذا معناه أن القالب الذي تستخدمه يحتوي على علل (bugs) أو أنه يتعارض مع واحدة من الملحقات التي تستخدمها. عطّل جميع الملحقات، فإذا عاد موقعك للعمل فابدأ بتفعيل الملحقات كلّ على حدة حتى تظهر الشاشة البيضاء، ففي تلك الحالة ستعرف أن الملحق الأخير يحتوي على علل. هل تستخدم ملحق للتخزين المؤقت؟ يمكنك تنظيف التخزين المؤقت لموقعك بشكل يدوي عن طريق الإعدادات، فووردبريس لا يأتي مع تخزين مؤقت بشكل افتراضي. تحقق من حد عرض الحزمة (bandwidth)، هل قمت بتجاوزه؟ فهذا قد يسبب خطأ الشاشة البيضاء، وإذا كان هذا هو السبب فيجب عليك التواصل مع موفّر الاستضافة. الخاتمة يعتبر خطأ الشاشة البيضاء من الأخطاء الصعبة خاصة عندما لا تواجه رسائل خطأ واضحة على الفور، لكن لحسن الحظ، هذه النصائح يمكنها مساعدتك على معرفة ذلك. هل واجهت شاشة الموت البيضاء سابقا؟ لا تتردد في إخبارنا عن تجربتك وتَعلّم من تجارب الآخرين في التعليقات في الأسفل. ترجمة -وبتصرف- للمقال: Troubleshooting White Screen of Death Errors in WordPress لصاحبه Jenni McKinnon.

إنّ السجلّات logs أمر ضروري لحل مشاكل تثبيت Redis، وقد تتساءل عن مكان تواجد هذه السجلّات أو عن المكان الذي يقوم Redis بتخزين السجلّات فيه على نظام Ubuntu. عند تثبيت Redis بالطريقة الافتراضية باستخدام apt-get على Ubuntu 14.04 فسيقوم Redis بإنشاء سجلّاته في المسار var/log/redis/redis-server.log/. لاستعراض آخر 10 أسطر في سجلّات redis، نقوم بتنفيذ الأمر التالي: $ sudo tail /var/log/redis/redis-server.log لاحظ في الأمر السابق استخدامنا لـ sudo نظرًا لأننا نحتاج لصلاحيات أعلى لنتمكن من قراءة سجلّات redis. أما في حال تثبيت Redis من ملفّات الشيفرة المصدرية على Ubuntu 14.04، فسيقوم بتخزين السجلّات في المسار var/log/redis_6379.log/. ولاستعراض آخر 10 أسطر نستخدم الأمر: $ sudo tail /var/log/redis_6379.log التحقق من السجلات المؤرشفة يقوم Redis بأرشفة ملفّات السجلّات القديمة، ولاستعراض قائمة الملفّات المتوفرة ننفذ الأمر: $ ls /var/log/redis فسيظهر الخرج بما يشبه التالي: redis-server.log redis-server.log.1.gz ولاستعراض آخر 10 أسطر من سجل مؤرشف نحتاج أولًا أن نقوم بفك ضغطه، ونستخدم gunzip لفك ضغط الملفات من نوع gz، كما في الأمر التالي: $ sudo gunzip /var/log/redis/redis-server.log.1.gz انتبه: يقوم gunzip بفك ضغط ملفات gz وحذف الملف الأساسي المضغوط، لذا إن كنت تريد المحافظة على الأرشيف المضغوط توفيرًا للمساحة واستعراض محتويات الملف المضغوط بشكل مؤقت فقم بنسخه إلى المسار المؤقت tmp/ وقم بفك ضغطه هناك. ومن ثم ننفذ الأمر tail مع الملف الذي نحصل عليه: $ sudo tail /var/log/redis/redis-server.log.1 البحث عن ملفات السجلات باستخدام أمر find إن لم تكن ملفّات السجلّات في المسارات المذكورة السابقة، فمن الممكن تنفيذ عملية بحث واسعة باستخدام الأمر find في المسار var/logs/ على الشكل التالي: $ find /var/log/* -name *redis* أو البحث في كامل النظام. قد تأخذ عملية البحث بهذا الشكل بعض الوقت إن كنت تملك الكثير من الملفّات، وقد تظهر لك بعض التحذيرات حول عدم كفاية الصلاحيات للبحث في بعض المسارات، وهذا أمر طبيعي، بالرغم من أنّنا نتجنب أسوأ مسارين للبحث فيهما وهما proc/ و sys/ باستعمال المعامل prune-. سيظهر تنفيذ الأمر التالي جميع الملفّات التي تحوي على كلمة redis في اسمه، بما في ذلك ملفات التثبيت: $ find / -path /sys -prune -o -path /proc -prune -o -name *redis* تحديد مسار تخزين السجلات في ملف إعدادات Redis نستطيع تغيير مسار تخزين ملفات السجلّات وذلك بتغيير المسار في ملف الإعدادات redis.conf، ويتواجد الملف غالبًا في المسار etc/redis/redis.conf/ نقوم بفتح الملف بمحرر نصوص مثل nano أو أي محرر آخر تفضّله: $ sudo nano /etc/redis/redis.conf ونبحث عن السطر الذي يبدأ بـ logfile ونقوم بتغيير المسار الذي يظهر فيه إلى المسار الجديد، كما بالإمكان تغيير اسم ملف السجل الأساسي: logfile /var/log/redis/redis-server.log التحقق من سجلات systemd باستخدام journalctl في Ubuntu 15.04 والإصدارات الأحدث منه قد نحتاج أن نتحقق من سجلّات Redis التي يقوم بالتقاطها سجل النظام systemd (يستخدم نظام Ubuntu 15.04 والأحدث منه سجل النظام systemd، بينما يستخدم Ubuntu 14.04 سجّلات Upstart بشكل افتراضي). الخلاصة لتتعلّم المزيد حول إعدادات Redis، يرجى قراءة هذا المقال حول إعداد عنقود Redis cluster. ترجمة -وبتصرّف- للمقال How To Find Redis Logs on Ubuntu لصاحبته Sharon Campbell.

يتناول هذا المقال الأدوات الأساسية للتراجع عن التعديلات في Git. ينبغي دائما الحذر عند التعامل مع أوامر التراجع، إذ أن التراجع من الأمور القليلة في Git التي قد تجعلك تخسر العمل إن أجريتها بطريقة خاطئة. يكثر استخدام التراجع عند الإيداع قبل أن تكون جاهزا لذلك؛ مثلا بنسيان ملفات أو رسائل الإيداع. في هذه الحالة يمكنك إعادة الإيداع باستخدام الخيار amend--: git commit --amend يأخذ الأمر أعلاه محتويات منطقة الإدراج Staging area ويستخدمها في الإيداع. إن لم تحدث أية تغييرات منذ آخر عملية إيداع (عند تنفيذ الأمر مثلا مباشرة بعد تطبيق الإيداع السابق) فسيكون بإمكانك التعديل على رسالة الإيداع الأخيرة التي ستظهر في المحرّر. بهذه الطريقة تكون عدلت على رسالة الإيداع السابق دون أن تضيف إيداعا جديدا. بنفس الطريقة، تمكن إضافة ملف منسي إلى الإيداع. نفترض أنك مثلا بعد إرسال الإيداع فطنت إلى نسيان ملف باسم forgotten_file كان يجب أن يكون فيه؛ في هذه الحالة تستخدم نفس الأمر كما في المثال التالي: git commit -m 'initial commit' git add forgotten_file git commit --amend أرسلنا الإيداع في الأمر الأول، ثم أضفنا في الأمر الثاني ملفا جديدا إلى منطقة الإدراج واستخدمنا خيار amend-- مع git commit. نحصُل في النهاية على إيداع واحد يحل محل الأول ويوجد فيه الملف المنسي. التراجع عن إضافة الملفات إلى منطقة الإدراج سنتطرق في الفقرتين التاليتين إلى كيفية التراجع عن التعديلات على منطقة الإدراج ومجلد العمل. من الجميل أن الأمر الذي يريك حالة هاتين المنطقتين يذكرك بكيفية التراجع عن التعديلات عليهما. لنفترض مثلا أنك عدلت على ملفين وتريد إيداعهما منفصلين (إيداع لكل ملف)، ولكنك نفذت الأمر * git add بالخطأ، وأضفتهما في نفس الوقت إلى منطقة الإدراج. كيف يمكنك نزع الاثنين من منطقة الإدراج؟ أمر git status يذكرك بالكيفية: git add * git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) renamed: README.md -> README modified: CONTRIBUTING.md مباشرة تحت عبارة Changes to be committed (التعديلات المهيّأة للإيداع) يوجد التذكير الذي يقول "استخدام reset HEAD... للتراجع عن إضافة ملف إلى منطقة الإدراج". إن قررنا اتباع النصيحة والتراجع عن إضافة ملف (وليكن CONTRIBUTING.md) إلى منطقة الإدراج: git reset HEAD CONTRIBUTING.md نحصل على الرسالة التالية: Unstaged changes after reset: M CONTRIBUTING.md وعند التحقق الآن من الحالة: git status نحصل على النتيجة التالية: On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) renamed: README.md -> README Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: CONTRIBUTING.md عدلنا على الملف CONTRIBUTING.md إلا أنه الآن خارج منطقة الإدراج. ملحوظة: استخدام أمر git reset يمكن أن يكون خطرا عند استخدام الخيار hard-- إلا أنه ليس كذلك إن استخدم دون خيارات، في هذه الحالة يتعامل مع منطقة الإدراج فقط. التراجع عن تعديل ملفات ما ذا لو قررت أنك لا تريد الاحتفاظ بالتعديلات التي أجريتها على الملف CONTRIBUTING.md؟ كيف يمكن التراجع عن التعديلات بسهولة، إعادته إلى ما كان عليه قبل آخر إيداع مثلا؟ يخبرك أمر git status بكيفية ذلك، مثل ما فعل مع إضافة الملفات إلى منطقة الإدراج. في مخرجات المثال أعلاه تبدو منطقة الإدراج على النحو التالي: Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: CONTRIBUTING.md تخبرك الرسالة "..."use "git checkout" بكيفية إلغاء التعديلات على ملفات مجلد العمل. نطبق التعليمات: git checkout -- CONTRIBUTING.md ثم نتحقق من تأثير الأمر: git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) renamed: README.md -> README تمكن ملاحظة أن التعديلات ألغيت. هام: من المهم فهمُ أن أمر git checkout خطير جدا. يلغي الأمر أي تعديل أجريته بلا رجعة، ولن يمكنك إعادته. استخدم هذا الأمر فقط عندما تكون متأكدا من أنك لم تعد ترغب في التعديلات. تذكر أن كل ما أودِع Commited في Git يمكن غالبا إرجاعه؛ حتى الإيداعات الموجودة على فروع Branches محذوفة أو تلك التي عدل عليها باستخدام خيار amend--. إلا أن البيانات التي لم تودع تُفقَد -على الأرجح- بغير رجعة. ترجمة -وبتصرّف- للفصل Git Basics - Undoing Things من كتاب Pro Git لصاحبه Scott Chacon.

توجد طريقتان أساسيتان في Git لتضمين التعديلات من تفريع إلى آخر: merge و rebase. يشرح هذا المقال ماهية إعادة تأسيس التفريعات Rebasing، كيفيتها، الفائدة منها والحالات التي يجدر بك عدم استخدام إعادة التأسيس فيها. مبادئ إعادة التأسيس يمكن بالعودة إلى المثال في درس المبادئ الأساسية لدمج التفريعات رؤية تمايز أعمالك بإضافة إيداعات إلى كلٍّ من التفريعين. استخدام أمر git merge هو أسهل طريقة، مثل ما رأينا سابقا، لتضمين تفريع في آخر. ينفّذ الأمرُ الدمجَ الثلاثي بين آخر لقطتين في كلّ تفريع (C3 وC4) واللقطة المشتركة الأقرب (C2) منشئا بذلك لقطة (وإيداعا) جديدة. إلا أنه توجد طريقة أخرى: يمكنك أخذ الترقيع Patch الذي أضافه الإيداع C4 ثم تطبيقه على الإيداع C3. تسمى هذه العملية في Git بإعادة التأسيس. يتيح الأمر rebase أخذ جميع الإيداعات التي أضيفت إلى تفريع وتكرارها على تفريع آخر. يكون تطبيق هذا المبدأ على المثال في الصورة بتنفيذ الأمر على النحو التالي: git checkout experiment git rebase master First, rewinding head to replay your work on top of it... Applying: added staged command يعمل الأمر بالرجوع إلى الإيداع السابق المشترك بين التفريعين (التفريع الذي تعمل عليه الآن، والتفريع الذي تريد إعادة التأسيس عليه)، الحصول على التغييرات التي أدرجها كل إيداع على التفريع الحالي وتخزينها في ملف ظرفي، ضبط التفريع الحالي على آخر إيداع في التفريع الذي نريد إعادة التأسيس عليه ثم في الأخير تطبيق التعديلات بالترتيب. نستطيع بالوصول إلى هذه النقطة العودة إلى التفريع master وتنفيذ دمج بتقدم سريع: git checkout master git merge experiment يشير الإيداع 'C4 إلى نفس اللقطة التي يشير إليها الإيداع C5 في مثال الدمج الذي تحدثنا عنه في البداية. لا يوجد فرق في المنتوج النهائي بين الاثنين؛ إلا أن إعادة التأسيس تجعل سجل التعديلات أكثر وضوحا. يبدو سجل الإيداعات في تفريع أعيد تأسيسه خطيًّا: تظهر الأعمال كما لو أنها حدثت بالتتالي، حتى لو كان الواقع أنها كانت بالتوازي. يُلجَأ عادة لتأسيس التفريعات للتأكد من أن الإيداعات تُطبَّق دون مشاكل على تفريع بعيد؛ مثلا عند المشاركة في مشروع لا تتولى صيانته. تعمل في هذه الحالة على تفريع ثم تعيد تأسيس التفريع على origin/master عندما تكون جاهزا لإرسال الترقيع إلى المشروع الرئيس. لن يحتاج مسؤول المشروع في هذه الحالة إلا إلى دمج سريع. انتبه إلى أن اللقطة التي يشير إليها التفريع هي نفسها، سواء كانت الأخيرة من إيداعات بعد إعادة تأسيس التفريع أو إيداع دمج. وجه الاختلاف هو فقط سجل التغييرات. تكرّر إعادة التأسيس التغييرات من خط عمل على آخر بالترتيب الذي حدثت به في حين يأخذ الدمج نقطتي النهاية ويدمجهما معا. إعادات تأسيس متقدمة يتيح Git إمكانية تطبيق إعادة التأسيس على أمور أخرى غير التفريع المستهدف بإعادة التأسيس. نأخذ المثال الموضَّح في الصورة أدناه. أنشأت تفريعا جديدا باسم server (تفريع موضوع Topic branch) لإضافة ميزات من جهة الخادوم إلى مشروعك وأضفت إيداعا إلى هذا التفريع؛ ثم أنشأت بعدها تفريعا جديدا لميزات تعمل في جانب العميل client وأضفت عليه إيداعات متتابعة. عدت في الأخير إلى تفريع server وأضفت إليه إيداعات أخرى. نريد الآن دمج التغييرات في جانب العميل إلى التفريع الرئيس وفي نفس الوقت ترك التعديلات في جانب الخادوم لاختبارها أكثر. نستخدم خيار onto-- مع أمر git rebase لأخذ الإيداعات الموجودة على التفريع client دون أن تكون موجودة على server (أي الإيداعات C8 وC9): git rebase --onto master server client يمكن تفسير الأمر السابق بـ”افحص تفريع client، اعثر على الإيداعات التالية للإيداع المشترك بينه والتفريع server ثم طبقها على التفريع master“. يبدو الأمر معقّدا إلا أن النتيجة مذهلة. يمكن بعدها تطبيق دمج سريع على التفريع الرئيس: git checkout master git merge client نرغب الآن في تضمين التفريع server أيضا. تمكننا إعادة تأسيس التفريع server على التفريع master دون الحاجة لفحصه أولا بتنفيذ الأمر [git rebase [basebranch] [topicbranc. يفحص الأمر تفريع الموضوع (أي التفريع server في هذه الحالة) تلقائيا ثم يؤسسه على التفريع القاعدي (master): git rebase master server يُعيد الأمر تأسيس التفريع server على التفريع master على النحو الموضَّح في الصورة التالية. نطبق دمجا سريعا للتفريع القاعدي master: git checkout master git merge server يمكن الآن حذف التفريعين server وclient لأن جميع الأعمال فيهما أدمجت في التفريع الرئيس ولم تعد بحاجة إليها. git branch -d client git branch -d server يبدو سجل التعديلات كما يظهر في الصورة أدناه. مشاكل إعادة التأسيس يمكن إجمال مخاطر إعادة تأسيس التفريعات في النصيحة التالية: لا تُعِد تأسيس إيداعات موجودة خارج مستودعك. تهجُر عندما تعيد تأسيس تفريع، إيداعاتٍ موجودةً وتبدلها بأخرى جديدة مشابهة إلا أنها مختلفة. تصبح الأمور صعبة وغير مرتبة عند استخدام إعادة التأسيس بما يخالف النصيحة أعلاه، مثلا عندما تدفع إيداعات إلى مستودع مشترك ثم يجلبها آخرون ويعملون عليها، ثم تعيد كتابة الإيداعات باستخدام أمر git rebase وتدفعها إلى المستودع مرة أخرى. سيحتاج مشاركوك في هذه الحالة لإعادة دمج أعمالهم ويمكن أن تحدث مشاكل عندما يريدون دفع أعمالهم بعدك. فلنأخذ مثالا لحالة يمكن أن تؤدي فيها إيداعات - أعيد تأسيسها ووُفِّرت للعموم - إلى مشاكل. نفترض أنك نسخت مستودعا من خادوم مركزي ثم أجريت أعمالا عليه. يبدو سجل الإيداعات على النحو الموضَّح في الصورة التالية. يعمل أحدهم في هذه الأثناء على إضافة تعديلات إلى المستودع من ضمنها دمج تفريع ثم يدفع النتيجة إلى الخادوم المركزي، تأتي أنت وتفتش عن الجديد على المستودع البعيد وتدمج التفريع البعيد الجديد إلى عملك؛ يصبح سجل الإيداعات على النحو التالي. يقرّر الشخص الذي دفع التفريع المدموج التراجع وإعادة تأسيس التفريع بدلا من ذلك؛ ينفذ أمر: git push --force لتغيير سجل الإيداعات على الخادوم، ثم تأتي أنت للتفتيش عن جديد المستودع البعيد وتجلب الإيداعات الجديدة. أنتما الآن في ورطة: تنفيذك لأمر: git pull سينشئ إيداعَ دمج يتضمّن سجلي التعديلات وسيبدو المستودع لديك كالتالي: سيظهر عند تنفيذ أمر git log على سجل التعديلات أعلاه إيداعان لديهما نفس الكاتب، التاريخ والرسالة؛ أمر مربك. علاوة على ذلك، يؤدي دفع بيانات بسجل التغيير هذا إلى الخادوم إلى إدخال كل هذه الإيداعات المعاد تأسيسها إلى الخادوم وهو ما سيربك الآخرين أكثر. من الآمَن في هذه الحالة افتراضُ أن المطوّر الآخر لا يريد أن يَبقى الإيداعان C4 وC6 في سجل الإيداعات؛ ولهذا السبب أعاد التأسيس أصلا. إصلاح ما أفسدته إعادة التأسيس يوفر Git آليات إضافية لحالات مثل التي رأيناها في الفقرة السابقة. التحدي في المواقف التي يدفع فيها أحد أعضاء الفريق تعديلات تغير تلك التي أعدت تأسيس عملك عليها هو التفريق بين عملك وبين ما أعيدت كتابته. يحسب Git، إضافة إلى مجموع التحقق (دالة SHA-1) الخاص بالإيداع مجموع تحقق خاص بالترقيع Patch الذي أضيف مع الإيداع؛ يسمّى مجموع التحقق هذا بمعرّف الترقيع Patch id. يمكن لـGit، عندما تجلب بيانات أعيدت كتابتها ثم تعيد التأسيس لها على الإيداعات الجديدة من الشريك، أن يتعرّف على الإيداعات الخاصة بك ثم يطبقها على التفريع الجديد. بدلا من تنفيذ أمر git merge بعد أن نفّذ الشريك أمر git push --force في المثال السابق (الحالة الموضَّحة في الصورة قبل الأخيرة) نفّذ الأمر git rebase teamone/master وسيقوم Git بالتالي: تحديد الإيداعات الخاصة بتفريعك فقط (أي الإيداعات C6، C4، C3، C2 وC7). التعرف على الإيداعات التي ليست إيداعات دمج (C3، C2 وC4). تحديد الإيداعات التي لم تُعد كتابتها في التفريع الوجهة (التفريعان C2 وC3 فالإيداعان C4 و'C4 هما نفس الترقيع، أي أن تعديلاتهما هي نفسها). تطبيق هذه الإيداعات على التفريع teamone/master. ينتج عن الخطوات المتّبعة الوضعية التالية بدلا من تلك التي كنا سنجد فيها أنفسنا لو نفّذنا أمر git pull. تعمل الطريقة أعلاه فقط إن كان الإيداعان C4 و'C4 الذين أضافهما شريكك متطابقين تقريبا؛ وإلا فإن أمر rebase لن يكون قادرا على معرفة أيهما المكرَّر وسيضيف إيداعا جديدا مشابها لـ'C4 (يُحتمَل جدّا ألا يُطبَّق نظرا لأن التعديلات ستكون غالبا موجودة في مكان ما). يمكن تسهيل الأمر بتنفيذ git pull --rebase بدلا من git pull عادي؛ أو التأسيس يدويا بتنفيذ أمر git fetch تتبعه بـ git rebase teamone/master في هذه الحالة. توجد طريقة لجعل خيار rebase-- مبدئيا عند تنفيذ أمر git pull وهي إعداد المعطى pull.rebase في الإعدادات ليأخذ القيمة git config --global pull.rebase true. ستجري الأمور بخير ما دمت تستخدم إعادة التأسيس بوصفها طريقة لتنسيق الإيداعات والعمل عليها قبل دفعها وما ظللت ملتزما بإعادة تأسيس الإيداعات التي لم تتوفر أبدا للعموم دون غيرها. في الجانب الآخر، تتعرّض للكثير من المخاطر بإعادة التأسيس على إيداعات سبق دفعها إلى مستودعات عمومية ويمكن أن يكون بعض شركائك أسسوا عملهم عليها. تأكد من تنفيذ جميع أعضاء الفريق لأمر git pull --rebase لمحاولة التقليل من المشاكل بعد إعادة تأسيس أحدهم على إيداعات جلبها من المستودع العمومي. إعادة التأسيس أم الدمج؟ ربما تتساءل الآن بعد الخوض في كلّ من إعادة التأسيس والدمج، أيهما أنسب؟ سنعود إلى الوراء قليلا قبل الإجابة على التساؤل لندقّق في معنى سجل المستودع. يمكن رؤية الموضوع على أساس أن سجل المستودع هو تسجيل لما حدث فيه، بمعنى أنه وثيقة تاريخية قيّمة بذاتها، ولا يجوز التلاعب بها. يعدّ تغيير السجلّ من وجهة النظر هذه خطأ كبيرا؛ فذلك يعني تزوير الوقائع. ماذا لو حدثت فوضى في المستودع بعد متتالية من الإيداعات؟ هذه هي الوقائع ويجب أن تظل مسجّلة تقول وجهة النظر هذه. توجد رؤية مغايرة للموضوع، تقول إن سجل الإيداعات هو رواية لكيفية بناء المشروع. يحتاج دليل صيانة البرنامج لنفس الحذر الذي يتطلبه نشر كتاب، فلا يجوز أن تنشر كتابا مازال في طور المسودة. يتبنى وجهة النظر هذه من يستخدمون أدوات مثل git rebaseوgit filter-branch لسرد القصة بأفضل طريقة للقراء المستقبليين. يتضح الآن أن سؤال أيها أستخدم، إعادة التأسيس أم الدمج؟ ليس بتلك السهولة. Git أداة قوية تسمح بفعل الكثير من الأشياء للسجّل وبه؛ إلا أن كلّ فريق مختلف وكذلك المشاريع. يعود الأمر إليك، بعد فهم طريقة عمل الاثنين، لاختيار ما يناسب الفريق الذي تعمل معه والمشروع الذي تعمل عليه. المبدأ العام للحصول على أفضل ما في الطريقتين هو إعادة تأسيس التعديلات المحلية التي لم تشارَك بعد قبل أن تدفعها من أجل تقديم القصة؛ والابتعاد تماما عن إعادة تأسيس أي شيء سبق دفعه إلى مستودع عمومي. خاتمة غطينا في هذه السلسلة أساسيات التفريع والدمج في Git. يجدر بك أن تكون مرتاحا للعمل على إنشاء التفريعات الجديدة والانتقال للعمل عليها، التبديل بين التفريعات ودمجها ودمج التفريعات المحلية معا؛ بالإضافة إلى تشارك التفريعات بدفعها إلى خادوم مشترك، العمل مع آخرين على تفريعات مشتركة وإعادة تأسيس تفريعاتك فبل أن تشاركها. الخطوة الموالية هي معرفة ما تحتاجه لتشغيل خادوم Git خاص بك لتشارك المستودعات. ترجمة -بتصرف- للفصل Git Branching - Rebasing من كتاب Pro Git لصاحبه Scott Chacon.

في كثير من الأحيان يحتاج مدراء أنظمة لينكس للإطلاع على ملفات السجلات (log files) للكشف عن الأخطاء والمشاكل، وهذا الأمر في الحقيقة يجب على أي مدير نظام القيام به. يستطيع نظام لينكس ومُختلف التطبيقات توليد مختلف أنواع الرسائل والتي يتم تسجيلها في ملفات السجلات المختلفة، ويستخدم نظام لينكس مجموعة من ملفات الإعدادات والمجلدات والبرامج والأوامر والعفاريت (daemons) لإنشاء وتخزين وحذف رسائل السجل. ولذلك فإن معرفة المكان الذي يحتفظ فيه النظام على ملفات السجلات وكيفية استخدام الأوامر المتعلقة به يمكن أن يساعدك على توفير وقتك الثمين أثناء استكشاف الأخطاء وإصلاحها. في هذا الدرس، سنلقي نظرة على مُختلف جوانب السّجلات وإدارتها على أنظمة لينكس ملاحظة: تم اختبار هذه الأوامر على أنظمة CentOS 6.4 و Ubuntu 12 و Debian 7. الموقع الافتراضي لملفات السجلات إن الموقع الافتراضي لملفات السجلات هو var/log/. يمكنك رؤية قائمة الملفات الموجودة في هذا المجلد عن طريق الأمر: ls -l /var/log هذه قائمة ملفات السجلات الموجودة في نظام CentOS الخاص بي: total 1472 -rw-------. 1 root root 4524 Nov 15 16:04 anaconda.ifcfg.log -rw-------. 1 root root 59041 Nov 15 16:04 anaconda.log -rw-------. 1 root root 42763 Nov 15 16:04 anaconda.program.log -rw-------. 1 root root 299910 Nov 15 16:04 anaconda.storage.log -rw-------. 1 root root 40669 Nov 15 16:04 anaconda.syslog -rw-------. 1 root root 57061 Nov 15 16:04 anaconda.xlog -rw-------. 1 root root 1829 Nov 15 16:04 anaconda.yum.log drwxr-x---. 2 root root 4096 Nov 15 16:11 audit -rw-r--r-- 1 root root 2252 Dec 9 10:27 boot.log -rw------- 1 root utmp 384 Dec 9 10:31 btmp -rw-------. 1 root utmp 1920 Nov 28 09:28 btmp-20131202 drwxr-xr-x 2 root root 4096 Nov 29 15:47 ConsoleKit -rw------- 1 root root 2288 Dec 9 11:01 cron -rw-------. 1 root root 8809 Dec 2 17:09 cron-20131202 -rw-r--r-- 1 root root 21510 Dec 9 10:27 dmesg -rw-r--r-- 1 root root 21351 Dec 6 16:37 dmesg.old -rw-r--r--. 1 root root 165665 Nov 15 16:04 dracut.log -rw-r--r--. 1 root root 146876 Dec 9 10:44 lastlog -rw------- 1 root root 950 Dec 9 10:27 maillog -rw-------. 1 root root 4609 Dec 2 17:00 maillog-20131202 -rw------- 1 root root 123174 Dec 9 10:27 messages -rw-------. 1 root root 458481 Dec 2 17:00 messages-20131202 -rw------- 1 root root 2644 Dec 9 10:44 secure -rw-------. 1 root root 15984 Dec 2 17:00 secure-20131202 -rw------- 1 root root 0 Dec 2 17:09 spooler -rw-------. 1 root root 0 Nov 15 16:02 spooler-20131202 -rw-------. 1 root root 0 Nov 15 16:02 tallylog -rw-rw-r--. 1 root utmp 89856 Dec 9 10:44 wtmp -rw------- 1 root root 3778 Dec 6 16:48 yum.log عرض محتويات ملف السجل هذه قائمة من ملفات السجلات الشائعة التي يمكن أن تجدها في مجلد /var/log/: wtmp utmp dmesg messages maillog أو mail.log spooler auth.log أو secure إن ملفات wtmp و utmp تتبع تسجيل دخول وخروج المستخدمين ولا يمكنك عرض محتويات هذه الملفات باستخدام الأمر cat أو ما شابه، فهنالك أوامر خاصة لفعل ذلك. سوف نتعلم في هذا الدرس بعضا من هذه الأوامر. لتعرف من الذي سجّل دخوله حاليا في خادوم لينكس يمكنك بسهولة استخدام الأمر who، وهذا الأمر يحصل على بياناته من ملف var/run/utmp/ (لأنظمة CentOS وDebian) أو من ملف run/utmp/ (لأنظمة أوبنتو). هذا مثال من نظام CentOS: who root tty1 2013-12-09 10:44 root pts/0 2013-12-09 10:29 (10.0.2.2) sysadmin pts/1 2013-12-09 10:31 (10.0.2.2) joeblog pts/2 2013-12-09 10:39 (10.0.2.2) في هذه الحالة بالذات، أنا المستخدم الوحيد للنظام ولقد شغّلت الخادوم من Oracle VirtualBox ومن ثم استطعت الوصول إليه كمستخدم جذر من الطرفية من جلسة SSH، أما بالنسبة للمستخدميْن الآخريْن (sysadmin وjoebolg) فهم أيضا فتحا جلسات لهما على النظام. الأمر last يخبرنا بتاريخ تسجيل الدخول للمستخدمين: last | grep sysadmin sysadmin pts/1 10.0.2.2 Mon Dec 9 10:31 still logged in sysadmin pts/0 10.0.2.2 Fri Nov 29 15:42 - crash (00:01) sysadmin pts/0 10.0.2.2 Thu Nov 28 17:06 - 17:13 (00:06) sysadmin pts/0 10.0.2.2 Thu Nov 28 16:17 - 17:05 (00:48) sysadmin pts/0 10.0.2.2 Thu Nov 28 09:29 - crash (06:04) sysadmin pts/0 10.0.2.2 Wed Nov 27 16:37 - down (00:29) sysadmin tty1 Wed Nov 27 14:05 - down (00:36) sysadmin tty1 Wed Nov 27 13:49 - 14:04 (00:15) في هذا المثال، أحاول إيجاد تاريخ تسجيل الدخول لمستخدم sysadmin، وكما ترى، فهنالك أمثلة لبضعة حالات توقّف فيها النظام. لتعرف متى كانت آخر مرة تم إعادة تشغيل (reboot) النظام، يمكننا كتابة الأمر التالي: last reboot وستكون النتيجة مشابهة لهذه: reboot system boot 2.6.32-358.el6.x Mon Dec 9 10:27 - 10:47 (00:19) reboot system boot 2.6.32-358.el6.x Fri Dec 6 16:37 - 10:47 (2+18:10) reboot system boot 2.6.32-358.el6.x Fri Dec 6 16:28 - 16:36 (00:08) reboot system boot 2.6.32-358.el6.x Fri Dec 6 11:06 - 16:36 (05:29) reboot system boot 2.6.32-358.el6.x Mon Dec 2 17:00 - 16:36 (3+23:36) reboot system boot 2.6.32-358.el6.x Fri Nov 29 16:01 - 16:36 (7+00:34) reboot system boot 2.6.32-358.el6.x Fri Nov 29 15:43 - 16:36 (7+00:53) ... ... wtmp begins Fri Nov 15 16:11:54 2013 وإذا أردت معرفة متى سجّل شخص معين دخوله آخر مرة إلى النظام، استخدم الأمر lastlog: lastlog في نظامي، ستكون النتيجة مشابهة لهذه: Username Port From Latest root tty1 Mon Dec 9 10:44:30 +1100 2013 bin **Never logged in** daemon **Never logged in** adm **Never logged in** lp **Never logged in** sync **Never logged in** shutdown **Never logged in** halt **Never logged in** mail **Never logged in** uucp **Never logged in** operator **Never logged in** games **Never logged in** gopher **Never logged in** ftp **Never logged in** nobody **Never logged in** vcsa **Never logged in** saslauth **Never logged in** postfix **Never logged in** sshd **Never logged in** sysadmin pts/1 10.0.2.2 Mon Dec 9 10:31:50 +1100 2013 dbus **Never logged in** joeblog pts/2 10.0.2.2 Mon Dec 9 10:39:24 +1100 2013 بالنسبة لبقية ملفات السجل النصية، يمكنك استخدام أوامر cat أو head أو tail لقراءة محتوياتها. في المثال بالأسفل، أحاول النظر إلى آخر 10 أسطر من ملف var/log/messages/ في نظام Debian: sudo tail /var/log/messages ستكون المخرجات كالآتي: Dec 16 01:21:08 debian kernel: [ 9.584074] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 Dec 16 01:21:08 debian kernel: [ 9.584074] Bluetooth: BNEP filters: protocol multicast Dec 16 01:21:08 debian kernel: [ 9.648220] Bridge firewalling registered Dec 16 01:21:08 debian kernel: [ 9.696728] Bluetooth: SCO (Voice Link) ver 0.6 Dec 16 01:21:08 debian kernel: [ 9.696728] Bluetooth: SCO socket layer initialized Dec 16 01:21:08 debian kernel: [ 9.832215] lp: driver loaded but no devices found Dec 16 01:21:08 debian kernel: [ 9.868897] ppdev: user-space parallel port driver Dec 16 01:21:11 debian kernel: [ 12.748833] [drm] Initialized drm 1.1.0 20060810 Dec 16 01:21:11 debian kernel: [ 12.754412] pci 0000:00:02.0: PCI INT A -> Link[LNKB] -> GSI 11 (level, low) -> IRQ 11 Dec 16 01:21:11 debian kernel: [ 12.754412] [drm] Initialized vboxvideo 1.0.0 20090303 for 0000:00:02.0 on minor 0 عفريت rsyslog في قلب آلية التّسجيل نجد عفريت rsyslog، وهذه الخدمة مسؤولة عن الاستماع إلى رسائل السجلات من مختلف أجزاء نظام لينكس ومن ثم توجيه الرسالة إلى ملف السجل الصحيح في مجلد var/log/ وكما يمكنها إعادة إرسال رسائل السجلات إلى خواديم لينكس آخرى. ملف إعدادات rsyslog يحصل عفريت rsyslog على إعداداته من ملف rsyslog.conf الموجود في مجلد etc/، ويعمل هذا الملف أساسا على اخبار عفريت rsyslog أين يحفظ رسائل السجلات، وهذه التعليمات تأتي من سلسلة أسطر متكونة من جزئين داخل الملف. يمكن إيجاد هذا الملف في rsyslog.d/50-default.conf في نظام أوبنتو. تتكون مجموعتا التعليمات من محدد (selector) وإجراء (action)، ويتم الفصل بين الجزئين بفراغ. يُحدد جزء "المحدد" مصدر وأهمية رسالة السجل وأما جزء "الإجراء" فيحتوي على ما يجب فعله مع تلك الرسالة. ينقسم جزء "المحدد" إلى جزئين مفصولين بنقطة .، ويسمى الجزء الأول بـ facility (جزء أصل الرسالة) وأما الثاني وهو الذي يأتي بعد النقطة فيسمى بـ priority (جزء درجة أهمية الرسالة) ومعا، أي جزئي facility/priority والإجراء يخبران rsyslog ماذا يفعل عندما يتم إنشاء رسالة تتطابق مع المعايير. هذا مقتطف من ملف rsyslog.conf على توزيعة CentOS: # rsyslog v5 configuration file ... ... # Include all config files in /etc/rsyslog.d/ IncludeConfig /etc/rsyslog.d/*.conf #### RULES #### # Log all kernel messages to the console. # Logging much else clutters up the screen. #kern.* /dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none /var/log/messages # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* -/var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg * # Save news errors of level crit and higher in a special file. uucp,news.crit /var/log/spooler # Save boot messages also to boot.log local7.* /var/log/boot.log ... ... لنفهم السطور السابقة، دعونا ننظر في أنواع المختلفة من المنشئات (facilities) التي يعترف بها نظام لينكس: auth أو authpriv: الرسائل التي تأتي من الأحداث المرتبطة بالأمن والتراخيص (authorization). kern: للرسائل القادمة من نواة لينكس. mail: للرسائل التي تم إنشاؤها من نظام الفرعي للبريد. cron: للرسائل المتعلقة بعفريت Cron. daemon: للرسائل القادمة من العفاريت. news: للرسائل القادم من النظام الفرعي لأخبار الشبكة. lpr: لرسائل السجل المتعلقة بالطباعة. user: لرسائل السجل القادمة من برامج المستخدم. من local0 إلى local7: محجوزة للاستخدام المحلي. وهذه قائمة من الأولويات بترتيب تصاعدي: debug: بيانات تنقيح البرامج. info: رسالة معلومات بسيطة - لا يلزم التدخل. notice: حالة قد تتطلب الاهتمام. warn: تحذير. err: خطأ. crit: حالة حرجة. alert: حالة تتطلب تدخلًا فوريًا. emerg: حالة طارئة مستعجلة. والآن دعونا ننظر إلى هذا السطر من الملف: cron.* /var/log/cron هذا السطر سيخبر عفريت rsyslog بحفظ جميع الرسائل من عفريت cron في ملف يدعى var/log/cron/، وأما رمز * بعد النقطة فيعني أن الرسائل من جميع الأولويات سيتم تسجيلها، وبالمثل فإذا تم وضع رمز * في المنشأ (facility) فذلك يعني لجميع المصادر. يمكن أن تكون المنشئات والأولويات مرتبطة بعدة طرق، ففي الشكل الافتراضي، عندما يكون هنالك أولوية واحد محددة بعد النقطة، فذلك يعني تحديد جميع الأحداث التي أولويتها أكبر أو تساوي تلك الأولوية، لذلك في الموجه التالي فإنه سيتم تسجيل جميع الرسائل القادمة من نظام الفرعي للبريد والتي تكون أولويتها من نوع تحذير فما فوق في ملف خاص داخل مجلد var/log/: mail.warn /var/log/mail.warn سيتم تسجيل جميع الرسائل التي تساوي أولويتها لـ "تحذير" فما فوق وتتُرك بقية الرسائل التي تكون أولويتها أقل من ذلك، أي أن الرسائل ذات أولوية err أو crit أو alert أو emerg لن يتم تسجيلها في الملف. إذا تم استخدام رمز المساواة = بعد النقطة فسيتم تسجيل فقط الأولوية المطابقة، أي أنه إذا أردت الحصول على رسائل info فقط القادمة من نظام الفرعي للرسائل، فإنك ستكتب شيء مشابه لهذا: mail.=info /var/log/mail.info مرة أخرى، إذا أردت الحصول على جميع الرسائل من نظام الفرعي للبريد ماعدا رسائل info، فإنك ستكتب شيئًا مشابهًا لهذا: mail.!info /var/log/mail.info أو هذا: mail.!=info /var/log/mail.info في الحالة الأولى، سيحتوي ملف mail.info على جميع الرسائل التي تملك أولوية أقل من info، وفي الحالة الثانية، سيحتوي هذا الملف على جميع الرسائل التي تملك أولوية أكبر من info. في حالة وجود أكثر من مَنشأ على نفس السطر فيجب الفصل بينها بواسطة فواصل، وفي حالة وجود مصادر متعددة (facility.priority) في نفس السطر فيجب الفصل بينها بواسطة الفاصلة المنقوطة. عندما يتم وضع علامة * لأحد الإجراءات فهذا يعني أن الإجراء لجميع المستخدمين. هذا السطر في ملف rsyslog.conf في نظام CentOS يخبرنا بهذا الشيء: # Everybody gets emergency messages *.emerg * حاول أن تعرف ماذا يقول ملف rsyslog.conf في نظام لينكس، فهذا مقتطف من خادوم نظام ديبيان الذي أعمل عليه: # /etc/rsyslog.conf Configuration file for rsyslog. # # For more information see # /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html ... ... auth,authpriv.* /var/log/auth.log *.*;auth,authpriv.none -/var/log/syslog #cron.* /var/log/cron.log daemon.* -/var/log/daemon.log kern.* -/var/log/kern.log lpr.* -/var/log/lpr.log mail.* -/var/log/mail.log user.* -/var/log/user.log # # Logging for the mail system. Split it up so that # it is easy to write scripts to parse these files. # mail.info -/var/log/mail.info mail.warn -/var/log/mail.warn mail.err /var/log/mail.err # # Logging for INN news system. # news.crit /var/log/news/news.crit news.err /var/log/news/news.err news.notice -/var/log/news/news.notice كما ترى، يحفظ ديبيان جميع الرسائل ذات مستوى أمني/تراخيص في var/log/auth.log/ في حين أن CentOS يحفظها في var/log/secure/. إن إعدادات rsyslog يمكن أن تأتي من ملفات خاصة أخرى، هذه الملفات الخاصة موجودة في العادة في مجلدات مختلفة داخل مجلد etc/rsyslog.d/ ويحتوي ملف rsyslog.conf على جميع هذه المجلدات باستخدام موجه IncludeConfig$. هكذا يبدو شكلها في نظام أوبنتو: # Default logging rules can be found in /etc/rsyslog.d/50-default.conf .... .... $IncludeConfig /etc/rsyslog.d/*.conf تبدو المحتويات الموجودة في مجلد etc/rsyslog.d/ كالتالي: -rw-r--r-- 1 root root 311 Mar 17 2012 20-ufw.conf -rw-r--r-- 1 root root 252 Apr 11 2012 21-cloudinit.conf -rw-r--r-- 1 root root 1655 Mar 30 2012 50-default.conf لا يجب أن تكون وجهة رسائل السجل بالضرورة هي ملف السجل، فيمكن أن تُرسل الرسالة إلى طرفية المستخدم، وفي هذه الحالة، سيحتوي حقل الإجراء على اسم المستخدم، وإذا كنت تحتاج إلى إرسال الرسالة إلى أكثر من مستخدم واحد، فيجب فصل أسماء المستخدمين بفواصل وإذا أردت إرسالها لجميع المستخدمين فيمكنك وضع الرمز * في حقل الإجراء. بما أن عفريت rsyslog جزء من نظام تشغيل الشبكة، فلا يُمكنه حفظ السّجلات محليا فحسب، وإنما يمكنه أن يُرسلها إلى خواديم لينكس أخرى في الشبكة أو أن يُصبح مستودعًا لبقية الأنظمة. فالعفريت يستمع لرسائل السجل من منفذ UDP 514. المثال التالي سيُغير وجهة الرسائل الحرجة للنواة إلى خادوم يدعى texas. kern.crit @texas إنشاء واختبار رسائل سجل الخاصة بك حان الآن وقت إنشاء ملفات سجل خاصة بنا، ولتجربة هذا سنحتاج إلى التالي: إضافة مواصفات ملف السجل في ملف etc/rsyslog.conf/ إعادة تشغيل عفريت rsyslog تجربة الإعدادات باستخدام أداة logger في المثال التالي، أضفت سطرين جديدين إلى ملف rsyslog.conf التابع لنظام لينكس CentOS الخاص بي، وكما ترى، كل واحد منها قادم من منشأ يدعى local4 ولديهم أولويات مختلفة. vi /etc/rsyslog.conf .... .... # New lines added for testing log message generation local4.crit /var/log/local4crit.log local4.=info /var/log/local4info.log بعد ذلك، سيتم إعادة تحميل ملف الإعدادات عند إعادة تشغيل الخدمة: /etc/init.d/rsyslog restart Shutting down system logger: [ OK ] Starting system logger: [ OK ] الآن، تم استدعاء تطبيق التسجيل لإنشاء رسالة سجل: logger -p local4.info " This is a info message from local 4" الآن، عند النظر إلى مجلد var/log/ سوف تجد ملفين جديدين: ... ... -rw------- 1 root root 0 Dec 9 11:21 local4crit.log -rw------- 1 root root 72 Dec 9 11:22 local4info.log إن حجم ملف local4info.log لا يساوي صفر، لذلك عندما يتم فتحه، سأرى الرسالة التي تم تسجيلها: cat /var/log/local4info.log Dec 9 11:22:32 TestLinux root: This is a info message from local 4 تدوير ملفات السجل كلما زادت المعلومات المكتوبة في ملفات السجل ازداد حجمها، ومن الواضح أن هذا الأمر سيقلل من الأداء وستكون إدارة هذه الملفات عملية متعبة. لينكس يستخدم مفهوم "التدوير" لملفات السجل بدلا من تنظيفها أو حذفها، عندما يتم تدوير سجل معين، سيتم إنشاء ملف جديد وتغيير اسم الملف القديم وضغطه بشكل إختياري. يمكن لملف السجل أن يملك عدة نسخ قديمة لا تزال موجودة، وهذه الملفات قد تعود لفترات قديمة من الزمن وستكون كسجل متراكم، وعند إنشاء عدد معين من هذه المتراكمات سيتسبب السجل المُدوّر بحذف ملف السجل الأقدم . يتم تشغيل التدوير عن طريق أداة logrotate. ملف إعدادات logrotate يعتمد logrotate مثل rsyslog على ملف الإعدادات واسم هذا الملف هو logrotate.conf وهو موجود في etc/. هذا ما أراه في ملف logrotate.conf على خادوم ديبيان الخاص بي: cat /etc/logrotate.conf # see "man logrotate" for details # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # create new (empty) log files after rotating old ones create # uncomment this if you want your log files compressed #compress # packages drop log rotation information into this directory include /etc/logrotate.d # no packages own wtmp, or btmp -- we'll rotate them here /var/log/wtmp { missingok monthly create 0664 root utmp rotate 1 } /var/log/btmp { missingok monthly create 0660 root utmp rotate 1 } # system-specific logs may be configured here الأسطر مفهومة وتشرح نفسها بنفسها، بشكل افتراضي، ملفات السجل يتم تدويرها بشكل أسبوعي مع الإبقاء على أربع سجلات في وقت واحد، عندما يشتغل البرنامج سيتم إنشاء ملف سجل جديد وسيتم ضغط الملف القديم اختياريا. الاستثناء الوحيد هو في ملفات wtmp و btmp، فملفات wtmp تتبع تسجيلات الدخول للنظام وأما btmp فهي تتبع تسجيلات الدخول النظام الخاطئة، كلا هذين الملفين يتم تدوريهما كل شهر ولن يتم إرجاع أي خطأ إذا كان أحد الملفات السابقة لـ wtmp أو btmp غير موجود. يتم الاحتفاظ بملفات إعدادات التّدوير المخصصة في مجلد etc/logrotate.d/، وهذه أيضا يتم تضمينها في ملف logrotate.conf مع التوجيه. يعرض لي نظام ديبيان محتويات هذا المجلد: ls -l /etc/logrotate.d total 44 -rw-r--r-- 1 root root 173 Apr 15 2011 apt -rw-r--r-- 1 root root 79 Aug 12 2011 aptitude -rw-r--r-- 1 root root 135 Feb 24 2010 consolekit -rw-r--r-- 1 root root 248 Nov 28 2011 cups -rw-r--r-- 1 root root 232 Sep 19 2012 dpkg -rw-r--r-- 1 root root 146 May 12 2011 exim4-base -rw-r--r-- 1 root root 126 May 12 2011 exim4-paniclog -rw-r--r-- 1 root root 157 Nov 16 2010 pm-utils -rw-r--r-- 1 root root 94 Aug 8 2010 ppp -rw-r--r-- 1 root root 515 Nov 30 2010 rsyslog -rw-r--r-- 1 root root 114 Nov 26 2008 unattended-upgrades محتويات ملف rsyslog تظهر لك كيف يتم تدوير بعض ملفات السجل: cat /etc/logrotate.d/rsyslog /var/log/syslog { rotate 7 daily missingok notifempty delaycompress compress postrotate invoke-rc.d rsyslog reload > /dev/null endscript } /var/log/mail.info /var/log/mail.warn /var/log/mail.err /var/log/mail.log /var/log/daemon.log /var/log/kern.log /var/log/auth.log /var/log/user.log /var/log/lpr.log /var/log/cron.log /var/log/debug /var/log/messages { rotate 4 weekly missingok notifempty compress delaycompress sharedscripts postrotate invoke-rc.d rsyslog reload > /dev/null endscript } كما ترى، إن ملف syslog ستتم إعادة تهيئته يوميا مع إبقاء ملفات السجل لمدة 7 أيام، أما بقية ملفات السجل فيتم تدويرها أسبوعيا. كما لا ننسى موجه postrotate فهو جدير بالذكر أيضا، فهذا الإجراء يحدد ماذا يحدث بعد الانتهاء من كامل عملية إعادة تدوير ملف السجل. تجربة التدوير يمكن أن يشتغل Logrotate يدويا لإعادة تدوير ملف أو أكثر، ولفعل ذلك، يمكننا ببساطة تحديد ملف الإعدادات الخاص بالأمر كمعامل لهذا الأمر. لنرى كيف يعمل، هذه قائمة جزئية من ملفات السجل موجود في مجلد var/log/ على الخادوم التجريبي CentOS الخاص بي: ls -l /var/log total 800 ... -rw------- 1 root root 359 Dec 17 18:25 maillog -rw-------. 1 root root 1830 Dec 16 16:35 maillog-20131216 -rw------- 1 root root 30554 Dec 17 18:25 messages -rw-------. 1 root root 180429 Dec 16 16:35 messages-20131216 -rw------- 1 root root 591 Dec 17 18:28 secure -rw-------. 1 root root 4187 Dec 16 16:41 secure-20131216 ... ... سوف تبدو المحتويات الجزئية لملف logrotate.conf كالتالي: cat /etc/logrotate.conf # see "man logrotate" for details # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # create new (empty) log files after rotating old ones create ... ... بعد ذلك قمنا بتشغيل أمر logrotate: logrotate -fv /etc/logrotate.conf سيتم نقل الرسائل عند إنشاء الملفات الجديدة والتعامل مع الأخطاء. وعندما يتنهي كل هذا، سنحاول التأكد من ملفات mail وsecure و messages الجديدة: ls -l /var/log/mail* -rw------- 1 root root 0 Dec 17 18:34 /var/log/maillog -rw-------. 1 root root 1830 Dec 16 16:35 /var/log/maillog-20131216 -rw------- 1 root root 359 Dec 17 18:25 /var/log/maillog-20131217 ls -l /var/log/messages* -rw------- 1 root root 148 Dec 17 18:34 /var/log/messages -rw-------. 1 root root 180429 Dec 16 16:35 /var/log/messages-20131216 -rw------- 1 root root 30554 Dec 17 18:25 /var/log/messages-20131217 ls -l /var/log/secure* -rw------- 1 root root 0 Dec 17 18:34 /var/log/secure -rw-------. 1 root root 4187 Dec 16 16:41 /var/log/secure-20131216 -rw------- 1 root root 591 Dec 17 18:28 /var/log/secure-20131217 كما ترى، تم إنشاء ملفات السجل الجديدة الثلاث، ملفات maillog و secure لاتزال فارغة، في حين أن ملف messages يملك بعض المعلومات. خاتمة نأمل أن يكون هذا الدرس قد أعطاك بعض الأفكار حول سجلات نظام لينكس، يمكنك أن تحاول وتجرب على خادومك التجريبي حتى تكون لديك فكرة أفضل، حالما تتعود على أماكن ملفات السجل وإعداداتها، استخدم معرفتك لدعم نظم الإنتاج الخاصة بك، وحينها، يمكنك إنشاء بعض الكُنيات aliases لتوفير بعض الوقت . ترجمة -وبتصرف- للمقال: How To View and Configure Linux Logs on Ubuntu and Centos لصاحبه Sadequl Hussain.