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/ में जाती हैं — जैसे Detail = High पंक्ति वाली फ़ाइल sshd.conf।
जाँचने का पैमाना: रिपोर्ट एक या डेढ़ स्क्रीन में समा जानी चाहिए। इससे लंबी चीज़ पढ़ी जानी बंद हो जाएगी — आलस से नहीं, बल्कि इसलिए कि तीन सौ पंक्तियों की रोज़मर्रा में कोई विचलन दिखता ही नहीं।
सुबह का इंतज़ार किए बिना नतीजा देखने के लिए:
sudo logwatch --detail Low --range today --output stdout
Debian 12 पर ख़ाली SSH खंड
नए सिस्टमों पर एक अलग जाल। 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 पिछले दिन का सार है, चेतावनी नहीं। यह आपको रात में नहीं जगाएगा और परिभाषा से पीछे रहता है: यह तड़के रोज़ाना के कार्य से चलता है और कल को ढँकता है। और «अभी कुछ हो रहा है» के लिए यह न उपयुक्त है न उसके लिए बना है।
इसकी ताक़त कहीं और है — यह आपको एक आम दिन की शक्ल दिखाता है। एक महीने पढ़ने के बाद आप जानते हैं कि सामान्य हालत में कितने असफल लॉगिन होते हैं, साइट कितने अनुरोध लेती है और कितनी मेल बाहर जाती है; और जब इनमें से कोई आँकड़ा दोगुना हो जाए तो यह तुरंत दिख जाता है, बिना किसी सीमा और बिना किसी नियम के। इसीलिए रिपोर्ट को वहाँ रखना चाहिए जहाँ वह नज़र में आए, न कि मेल के किसी फ़ोल्डर में। एक पन्ने पर यह कैसा लगता है, नीचे डेमो पर।