يحل Logwatch مسألة تبقى بلا حل لولاه: فهو يقرأ عنك كل سجلات الخادم ويرسل ملخّصًا لليوم الماضي. فلا أحد يستعرض auth.log وسجلات خادم الويب يوميًا، بينما قراءة رسالة واحدة صباحًا أمر ممكن.

والمشكلة المعروفة: تصل الرسالة الأولى بعدة مئات من الأسطر، ويُلقى على الثانية نظرة عابرة، وبعد أسبوع ترسلها قاعدة بريد إلى مجلد منفصل، وعند هذا الحد تنتهي المراقبة. والسبب في الإعدادات الافتراضية دائمًا تقريبًا، وإصلاحه يستغرق عشر دقائق.

التثبيت وأين تُغيَّر الإعدادات

sudo apt install logwatch

وأين تضع قيمك أمر مهم. فالملف /usr/share/logwatch/default.conf/logwatch.conf لا يجوز المساس به — إذ يُستبدل عند تحديث الحزمة. أما ملفك فهو /etc/logwatch/conf/logwatch.conf. وقد يكون فارغًا؛ ويكفي أن تضيف ما تغيّره فقط.

Output = mail
Format = html
MailTo = admin@example.com
Detail = Low
Range = yesterday

مستوى التفصيل يحسم كل شيء

يقبل Detail قيمًا من 0 إلى 10 أو الكلمات Low وMed وHigh. والفرق هائل: فعند High يشمل التقرير كل اتصال وكل طلب؛ وعند Low المجاميع والشذوذ فقط.

والممارسة هي: Low عمومًا، مع رفع التفصيل انتقائيًا للخدمات التي تهمّك فعلًا. وتوضع إعدادات كل خدمة في /etc/logwatch/conf/services/ — مثلًا ملف sshd.conf فيه السطر Detail = High.

ومعيار للتحقق: ينبغي أن يتّسع التقرير في شاشة أو شاشة ونصف. وكل ما هو أطول سيتوقف الناس عن قراءته — لا كسلًا بل لأن الانحراف غير مرئي وسط ثلاثمئة سطر من الروتين.

ولرؤية النتيجة دون انتظار الصباح:

sudo logwatch --detail Low --range today --output stdout

قسم SSH فارغ على Debian 12

فخ منفصل على الأنظمة الحديثة. يقرأ Logwatch ملفات نصية في /var/log، وقد توقف Debian 12 و Ubuntu 24.04 عن تثبيت rsyslog افتراضيًا — فالملف /var/log/auth.log ببساطة غير موجود، ويذهب كل شيء إلى سجل systemd. ويظل التقرير يصل بانتظام، لكن القسم الأهم — عمليات دخول SSH — يخرج فارغًا أو يغيب.

والفحص يستغرق ثانية:

ls -l /var/log/auth.log

وإن لم يوجد الملف، فإما أن تثبّت rsyslog أو أن تقبل بأن Logwatch على هذه الآلة يعرض صورة ناقصة. والقسم الفارغ يسهل قراءته على أنه «لم يحدث شيء»، وهذه أخطر نتيجة.

إلى أين يذهب البريد

السبب الشائع الثاني لعبارة «التقارير لا تصل»: الخادم بلا تسليم بريد مضبوط. فيسلّم Logwatch الرسالة إلى وكيل النظام، وهذا لا يرسلها إلى أي مكان، فتستقر في صندوق root المحلي الذي لا ينظر فيه أحد أبدًا:

sudo cat /var/mail/root | tail -50

وثمة خياران. إما ضبط التسليم عبر مرحّل SMTP خارجي، أو ألا تستخدم البريد إطلاقًا وتكتب التقرير في ملف:

Output = file
Filename = /var/log/logwatch/report.txt

والثاني أصدق: فرسالة لا يستطيع أحد تسليمها تخلق وهم المراقبة، بينما ملف على القرص يمكن فتحه على الأقل.

ماذا تقرأ في التقرير

بترتيب تنازلي للفائدة:

  • sshd. عمليات الدخول الناجحة — من وأين. الناجحة تحديدًا لا آلاف الإخفاقات: فالإخفاقات خلفية، بينما الدخول من عنوان غير مألوف يحتاج تفسيرًا؛
  • sudo و pam_unix. من رفع الصلاحيات ومن أنشأ مستخدمين؛
  • Disk Space. سطر واحد يحذّر مسبقًا من قرص يمتلئ؛
  • cron. المهام التي ظهرت والمهام التي أخفقت؛
  • http. قفزة في استجابات 404 تعني عادة جسّ المسارات؛ وقفزة في 500 تعني أن شيئًا لديك قد تعطّل؛
  • postfix، إن كان الخادم يرسل بريدًا: فطابور صادر متزايد علامة نموذجية على أن الخادم صار يُستخدم مرحّلًا للبريد المزعج.

حدوده

Logwatch ملخّص لليوم الماضي لا تنبيه. فهو لن يوقظك ليلًا وهو متأخر بحكم التعريف: إذ يعمل من مهمة يومية في الساعات الأولى ويغطي الأمس. وهو ليس مناسبًا لـ «شيء يحدث الآن» ولا مخصصًا له.

وقوته في مكان آخر — فهو يُظهر لك شكل اليوم العادي. وبعد شهر من القراءة تعرف كم عملية دخول فاشلة تحدث لديك عادة، وكم طلبًا يستقبل الموقع، وكم بريدًا يخرج؛ وحين يتضاعف أحد هذه الأرقام يظهر ذلك فورًا، بلا أي عتبات ولا قواعد. ولهذا يستحق التقرير أن يُحفظ حيث يقع في عينك لا في مجلد بريد. وشكل ذلك على صفحة يعرضه العرض التوضيحي أدناه.