كيفية مسح سجلات تدقيق Zimbra لتحرير مساحة القرص بأمان

ابدأ بتحديد ما تحتاج إلى إزالته فعلياً

قد يُشعرك نقص مساحة القرص في خادم Zimbra بضرورة تنظيف سجلات النظام، لكنها /opt/zimbra/log/audit.logليست مجرد بيانات تشخيصية يمكن التخلص منها. إذ يُوثّقها Zimbra كسجل تدقيق لأحداث المصادقة والأنشطة الإدارية. وهذا يعني أن أفضل طريقة للتنظيف تعتمد على ما إذا كنت بحاجة إلى مساحة فورية، أو أدلة تاريخية، أو حل للاحتفاظ بالبيانات على المدى الطويل.

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

تُصنّف وثائق تسجيل Zimbra الخاصة بـ Log4j audit.logضمن /opt/zimbra/logالمكونات المسؤولة عن تدوير ملفات مثل audit.log. mailbox.logقد تستخدم سجلات Zimbra الأخرى إعدادات نظام التشغيل logrotate، لذا لا تفترض أن جميع الملفات في الدليل تتبع الآلية نفسها. راجع مرجع ملفات سجلات Zimbra الرسمي وملاحظات تدوير سجلات Zimbra .

قارن خيارات التنظيف قبل اتخاذ أي إجراء

الخطوة الأولى: قياس المشكلة قبل حذف أي شيء

تأكد أولاً من أن سجلات التدقيق هي المسؤولة فعلاً عن الضغط. قم بتشغيلها كالتالي root:

df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*

يُظهر الأمر الأول مدى امتلاء نظام الملفات /opt. أما الأمر الثاني فيُظهر حجم سجلات Zimbra الإجمالي. بينما يُظهر الأمر الثالث ملف التدقيق النشط وأي نسخ مُدارة. إذا كانت ملفات التدقيق تُمثل جزءًا صغيرًا فقط من نظام الملفات، فقد لا يُؤدي مسحها إلى حل المشكلة الحقيقية؛ إذ قد تكون مخازن البريد، أو النسخ الاحتياطية، أو ملفات قواعد البيانات، أو نوع آخر من السجلات هي التي تستهلك المساحة.

قم أيضاً بتسجيل الإصدار المثبت لديك قبل تغيير السلوك:

su - zimbra -c 'zmcontrol -v'

هذا الأمر مهم لأن توثيق Zimbra يشمل أجيالًا متعددة من المنتج، وقد تختلف صيغة Log4j الدقيقة، والتكوين المُنشأ، ووظائف الحذف. لذا، لا تنسخ قيمة الاحتفاظ من مثال قديم في ويكي وتفترض أنها القيمة الافتراضية الحالية.

تحقق من استخدام نظام الملفات، وإجمالي حجم سجلات Zimbra، وإصدارات سجلات التدقيق الفردية قبل اتخاذ قرار بشأن ما يجب إزالته.

الخطوة الثانية: تحقق من كيفية قيام هذا الخادم بتدوير السجلات وحذفها

تُوثّق زيمبرا آليتين مهمتين: Log4j للملفات التي تتضمن ملفات .log audit.log، وآلية نظام التشغيل logrotateللعديد من سجلات زيمبرا الأخرى. كما تُشير إلى أن جدول مهام crontab الخاص بزيمبرا قد يحتوي على مهام صيانة السجلات. راجع الإعدادات الحالية بدلاً من التخمين.

su - zimbra
crontab -l
exit

grep -n "audit.log" /opt/zimbra/conf/log4j.properties
grep -n "audit.log" /opt/zimbra/conf/log4j.properties.in

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

بالنسبة للخوادم التي تشهد حجم تدقيق مرتفعًا بشكل غير متوقع، تحقق مما إذا تم تفعيل تسجيل إضافي عمدًا. توضح ملاحظات إصدار Zimbra 10.0.6 zimbra_additional_loggingسمة التكوين المحلي، التي يمكنها إضافة المزيد من أحداث المصادقة الفاشلة أو المفيدة audit.log. لا تعطل تسجيل الأمان المفيد لمجرد توفير مساحة؛ إذا كان حجم البيانات مبررًا، فالحل الأمثل عادةً هو الاحتفاظ بالسجلات أو ضغطها أو تخزينها مركزيًا. راجع ملاحظات إصدار Zimbra 10.0.6 الرسمية .

راجع إعدادات crontab و Log4j الفعلية للخادم قبل تغيير سلوك الاحتفاظ أو التدوير.

الخطوة 3: يُفضل أرشفة أو حذف السجلات المُدارة أولاً

بالنسبة لمعظم المسؤولين، تُعد سجلات التدقيق القديمة المُدارة الخيار الأمثل للبدء. استخدمها findفي وضع التقارير فقط قبل حذف أي شيء. يعرض المثال التالي سجلات تدقيق مُدارة أقدم من 30 يومًا؛ 30 يومًا هو مجرد حدٍّ تقريبي، وليس فترة احتفاظ مُحددة من قِبل Zimbra.

find /opt/zimbra/log -maxdepth 1 -type f -name 'audit.log.*' -mtime +30 -print

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

mkdir -p /mnt/backup/zimbra-audit-logs
cp --preserve=mode,ownership,timestamps   /opt/zimbra/log/audit.log.OLD_GENERATION   /mnt/backup/zimbra-audit-logs/

كرر العملية مع أسماء الملفات التي راجعتها بالضبط. تحقق من النسخة الاحتياطية قبل حذف المصدر. تجنب الأنماط العامة مثل rm -f /opt/zimbra/log/audit.log*;، فهذا النمط يطابق الملف النشط أيضًا.

إذا كنت ترغب في الاحتفاظ بالسجلات القديمة محليًا ولكن تقليل حجمها، فقم بضغط الملفات التي تم تدويرها فقط:

gzip /opt/zimbra/log/audit.log.OLD_GENERATION

يعتمد جدوى الضغط على إعدادات التناوب الحالية لديك. قد تقوم بعض عمليات النشر بضغط السجلات التاريخية كجزء من الصيانة. تحقق من السجلات الموجودة فعليًا قبل إضافة طبقة أخرى.

كما تحذر إرشادات تسجيل البيانات التاريخية في زيمبرا من أن سجلات التدقيق قد تحتوي على بيانات حساسة. لذا، يجب التعامل مع الأرشيفات بنفس ضوابط الوصول المطبقة على السجلات الحية. راجع إرشادات تسجيل البيانات الرسمية في زيمبرا .

قم بإدراج الملفات القديمة التي تم تدويرها أولاً، ثم انسخ السجل المطلوب إلى وحدة تخزين منفصلة، ​​وبعد ذلك فقط قم بإزالة الأجيال التي تمت مراجعتها.

متى يكون اقتطاع ملف سجل التدقيق النشط مبرراً؟

إذا لم تكن الملفات المُدوّرة هي المشكلة، وكان الملف النشط audit.logنفسه يستهلك مساحةً حرجة، فإنّ الاقتطاع يُمكن أن يُعيد المساحة فورًا. وهو أيضًا الخيار ذو العيب الأوضح: إذ يتم حذف سجل التدقيق الحالي بمجرد اقتطاع الملف.

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

su - zimbra -c 'zmmailboxdctl stop'

cp --preserve=all /opt/zimbra/log/audit.log   /mnt/backup/audit.log.$(date +%Y%m%d-%H%M%S)

truncate -s 0 /opt/zimbra/log/audit.log

su - zimbra -c 'zmmailboxdctl start'

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

لا تستخدم rmسجل العمليات النشط كخيار أول. قد تستمر العملية في الكتابة عبر مُعرّف ملف مفتوح حتى بعد حذف مدخل الدليل، لذا قد لا يتم استعادة مساحة القرص المتوقعة فورًا. يُعد اقتطاع عقدة البيانات الموجودة أكثر قابلية للتنبؤ عند الحاجة الفعلية إلى مسح طارئ.

الخطوة الرابعة: التحقق من استعادة القرص واستمرار تسجيل الأحداث

بعد التنظيف، تأكد من النتيجة بدلاً من الاعتماد على عدم وجود أخطاء:

df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*
tail -n 20 /opt/zimbra/log/audit.log
su - zimbra -c 'zmcontrol status'

تتجلى النتيجة الجيدة بثلاث علامات: زيادة المساحة الحرة على نظام الملفات المستهدف، audit.logواستمرار وجودها واستقبالها للأحداث الجديدة، واستمرار تشغيل خدمات Zimbra ذات الصلة. إذا dfاستمر نظام الملفات في إظهار امتلاءه بينما duانخفضت المساحة الحرة بشكل حاد، فتحقق من وجود ملفات محذوفة لا تزال مفتوحة بسبب عمليات جارية قبل حذف المزيد من البيانات.

تحقق من المساحة المستعادة، ونشاط التدقيق الأخير، وحالة الخدمة بعد التنظيف.

اختر الحل طويل الأمد بناءً على سبب ازدياد حجم السجلات

إذا كان النمو طبيعيًا ولكن فترة الاحتفاظ طويلة جدًا

لا تُعدّل عملية الاحتفاظ بالبيانات أو حذفها إلا بعد توثيق فترة السجل المطلوبة. افحص إعدادات Zimbra crontab وLog4j الحالية، ثم أجرِ أصغر تغيير مناسب للإصدار. احتفظ بنسخة من الإعدادات الأصلية واختبر ما إذا كانت عملية التدوير التالية تُنشئ الملفات المتوقعة بالفعل.

إذا كان ضجيج المصادقة هو ما يرفع مستوى الصوت

بدلاً من مجرد الحذف السريع، ابحث عن المصدر. فمحاولات تسجيل الدخول المتكررة، أو إعدادات العملاء الخاطئة، أو أدوات المراقبة، أو توسيع سجلات المصادقة عمداً، كلها عوامل تزيد من حجم التدقيق. ولأن audit.logهذه المعلومات مفيدة للتحقيقات الأمنية، فإن تقليل التشويش الناتج عنها أفضل عادةً من إخفاء الأدلة.

إذا كان عليك الاحتفاظ بسجل التدقيق لعدة أشهر

انقل أو أرسل سجلات النظام إلى وحدة تخزين مصممة للاحتفاظ بها. يفصل نظام التسجيل المركزي، أو تخزين الكائنات، أو نظام ملفات السجلات المخصص، سجل الامتثال عن السعة المطلوبة لمنصة البريد. تتناول وثائق ملفات سجلات Zimbra بالتفصيل خيارات التسجيل المركزي المتاحة، بما في ذلك audit.log...

ما لا يجب فعله

• لا تقم بالحذف audit.log*باستخدام رمز بدل غير مراجع.
• لا تفترض /etc/logrotate.d/zimbraأن التحكم في سجل التدقيق النشط يتم في كل إصدار؛ توثق Zimbra أن Log4j هي ​​آلية التدوير لـ audit.log.
• لا تقم بضغط الملفات أو أرشفتها على نفس نظام الملفات شبه الممتلئ إلا إذا تأكدت من وجود مساحة مؤقتة كافية.
• لا تقم بتقصير مدة الاحتفاظ بالبيانات دون التحقق من المتطلبات التنظيمية أو القانونية أو الأمنية.
• لا تقم بتعديل ملفات Log4j التي تم إنشاؤها بشكل دائم دون فهم ما إذا كان Zimbra سيعيد إنشائها من قالب.

الفحص النهائي

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