Linux सर्वर मेंटेनेंस के लिए जरूरी चेकलिस्ट

Linux सर्वर मेंटेनेंस का वास्तविक अर्थ

Linux सर्वर मेंटेनेंस एक निश्चित समय-सारणी पर किए जाने वाले कार्यों की एक छोटी सूची है, न कि कोई ऐसी परियोजना जिसका अंत हो। साप्ताहिक रूप से आप यह सुनिश्चित करते हैं कि अपडेट इंस्टॉल हो गए हैं, डिस्क में जगह उपलब्ध है, कोई भी सर्विस बंद नहीं हुई है, और बैकअप का कार्य पूरा हो गया है। मासिक रूप से आप रिस्टोर का परीक्षण करते हैं, सर्टिफिकेट की समाप्ति तिथि की जाँच करते हैं, अकाउंट्स और कीज़ (keys) का ऑडिट करते हैं, और पुराने कर्नेल (kernels) तथा लॉग्स को हटाते हैं। प्रत्येक डिस्ट्रीब्यूशन रिलीज़ पर आप वर्ज़न अपग्रेड की योजना बनाते हैं और उस रीबूट को पूरा करते हैं जिसे आप टालते रहे हैं।

सर्वर बनाना एक अलग कार्य है, और नए VPS पर शुरुआती दस मिनट में उस हिस्से को कवर किया गया है। यह पेज उसके बाद के एक वर्ष के बारे में है। नीचे दी गई प्रत्येक मद उस विफलता का नाम बताती है जिसे वह रोकती है, क्योंकि बिना परिणामों वाली चेकलिस्ट वह होती है जिसे लोग धीरे-धीरे चलाना बंद कर देते हैं।

यहाँ दिए गए कमांड्स केवल उदाहरण के लिए हैं और इन्हें चलाने से पहले पढ़ा जाना चाहिए। उनके आउटपुट की तुलना अपने सर्वर से करें, क्योंकि खाली जगह या प्रोसेस काउंट का सही मान इस पर निर्भर करता है कि सर्वर क्या काम कर रहा है। जहाँ कोई जाँच डिस्ट्रीब्यूशन के अनुसार अलग होती है, वहाँ टेक्स्ट में इसका उल्लेख किया गया है। उदाहरणों में Debian और Ubuntu के साथ apt का उपयोग किया गया है। RHEL परिवार पर टूलिंग dnf है और कई पाथ (paths) अलग हैं।

Linux सर्वर मेंटेनेंस की ऐसी समय-सीमा कैसे चुनें जिसे आप निभा सकें

साप्ताहिक जाँच उन चीजों को कवर करती है जो आपके बिना बदलती रहती हैं: packages, disk usage, service state और scheduled jobs। ये चीजें अपने आप बदलती हैं, इसलिए एक सप्ताह से अधिक समय तक इन्हें बिना देखे छोड़ना जोखिम भरा हो सकता है।

मासिक जाँच धीमी गति से होने वाले बदलावों को कवर करती है: समाप्ति के करीब पहुँच रहे certificates, ऐसे accounts जिन्हें किसी ने हटाया नहीं, /boot में जमा हो रहे kernels, और ऐसी log files जो उस rotation rule से बाहर हो गई हैं जो अब काम नहीं कर रहा। इनमें से कोई भी चीज कल ही खराब नहीं होगी। लेकिन अंततः ये सभी समस्या पैदा करेंगी।

Release जाँच कैलेंडर पर आधारित होती है। Distribution release एक ऐसा मेंटेनेंस कार्य है जिसकी एक बाहरी समय-सीमा होती है, क्योंकि आपके वर्तमान version का support इस बात से फर्क नहीं पड़ता कि आप तैयार हैं या नहीं, समाप्त हो ही जाता है।

इस कार्य के लिए एक निश्चित समय तय करें, जैसे साप्ताहिक जाँच के लिए सोमवार की सुबह और मासिक जाँच के लिए महीने की पहली तारीख। "जब समय मिलेगा तब कर लूँगा" वाली checklist वास्तव में कोई checklist नहीं होती। यदि आपके पास कई machines हैं, तो इन्हें हाथ से करने के बजाय एक ही जगह से चलाएं, जो कि एक ही स्थान से कई Linux servers को मैनेज करना का विषय है।

साप्ताहिक: क्या अपडेट वास्तव में इंस्टॉल हुए?

unattended-upgrades को सक्षम करना और उसके चलने की जानकारी होना, दोनों अलग बातें हैं। सर्विस masked हो सकती है, कॉन्फ़िगरेशन ऐसे ओरिजिन तक सीमित हो सकता है जिसका आप उपयोग नहीं करते, और एक held पैकेज उसके बाद के हर रन को बाधित कर सकता है। इसे इंस्टॉल करने की प्रक्रिया Ubuntu पर स्वचालित सुरक्षा अपडेट में दी गई है। साप्ताहिक जॉब का उद्देश्य यह साबित करना है कि जो आपने इंस्टॉल किया है, उसने अपना काम किया है।

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable ही सही पैमाना है, क्योंकि यह इरादे के बजाय वर्तमान स्थिति की रिपोर्ट करता है। यदि सुरक्षा अपडेट अभी भी उस सूची में मौजूद हैं, तो इसका मतलब है कि ऑटोमेशन अपना काम नहीं कर रहा है। इसलिए, यह मान लेने से पहले कि मशीन पैच हो चुकी है, लॉग को पढ़ें। apt-mark hold के साथ पिन किया गया पैकेज हमेशा के लिए छोड़ दिया जाता है और कोई रिपोर्ट नहीं देता, इसीलिए apt-mark showhold को उसी पास में शामिल करना आवश्यक है।

यह उस विफलता को रोकता है जहाँ आप महीनों तक एक ज्ञात-असुरक्षित (known-vulnerable) पैकेज चलाते रहते हैं, जबकि आपको लगता है कि अपडेट स्वचालित रूप से हो रहे हैं।

साप्ताहिक: डिस्क और इनोड (inode) की उपलब्धता

यदि root filesystem पूरी तरह भर जाए, तो ऐसी चीजें भी काम करना बंद कर देती हैं जिनका डिस्क से कोई सीधा संबंध नहीं दिखता। Database लिखना बंद कर देता है, logging रुक जाती है, package upgrade बीच में ही अटक जाता है, और कुछ setups में आप नया session भी शुरू नहीं कर पाते क्योंकि system अपनी अस्थायी फाइलें नहीं लिख पाता।

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i वह पहलू है जिसे ज्यादातर लोग नजरअंदाज कर देते हैं। Inodes वे निश्चित संख्या वाली संरचनाएं हैं जो फाइल का मेटाडेटा रखती हैं, और हो सकता है कि filesystem में इनोड खत्म हो जाएं जबकि df -h अभी भी खाली गीगाबाइट दिखा रहा हो। ऐसी स्थिति में, जब आप कुछ लिखने का प्रयास करते हैं तो No space left on device त्रुटि आती है, भले ही डिस्क में जगह खाली दिख रही हो; पहली बार ऐसा होने पर इसे समझने में काफी समय बर्बाद हो सकता है। इसका सामान्य कारण लाखों छोटी फाइलें होती हैं, जो अक्सर अटकी हुई mail queue या किसी ऐसे session directory के कारण जमा हो जाती हैं जिसे कोई साफ नहीं करता।

du -xh एक ही filesystem तक सीमित रहता है, जो कि bind mounts या attached storage वाले सर्वर के लिए सही है। Docker host पर इसका समाधान आमतौर पर image layers और बेकार हो चुके volumes को हटाने में होता है, जिसे VPS पर Docker डिस्क उपयोग को साफ करने के तरीके में समझाया गया है।

खाली जगह (free space) आपको केवल क्षमता के बारे में बताती है। इसके नीचे मौजूद स्टोरेज अपने स्वयं के चक्र के अनुसार खराब हो सकता है, जो कि एक अलग जांच का विषय है और इसे VPS पर डिस्क स्वास्थ्य की निगरानी में कवर किया गया है।

साप्ताहिक: क्या बिना सूचना दिए बंद हो गया?

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

जो unit क्रैश हो जाती है और अपनी restart limit तक पहुँच जाती है, वह failed state में ही बनी रहती है और कोई सूचना नहीं देती। इसके बारे में आपको कोई ईमेल नहीं मिलता। list-timers अधिक उपयोगी हिस्सा है: यह दिखाता है कि प्रत्येक timer आखिरी बार कब चला था और अगली बार कब चलेगा, इसलिए यदि LAST का मान timer के अपने interval से पुराना है, तो इसका मतलब है कि वह job बिल्कुल नहीं चली।

इसे restart करने से पहले unit के लिए journal को journalctl -u <unit> -n 100 --no-pager के साथ पढ़ें। एक restart केवल लक्षण को मिटाता है, और फिर आपके पास दोबारा जाँच करने का कोई कारण नहीं रहता जब तक कि वही समस्या किसी और खराब समय पर न हो जाए।

यह जिस विफलता को रोकता है: एक monitoring agent, एक queue worker या एक backup service जो तीन सप्ताह पहले memory spike के बाद से बंद पड़ी है।

साप्ताहिक: क्या बैकअप जॉब वास्तव में पूरी हुई?

शेड्यूल किया गया बैकअप और पूरा हो चुका बैकअप दो अलग-अलग तथ्य हैं, और केवल बाद वाला ही रिस्टोर करने में काम आता है। पूर्णता की जाँच करें।

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

दो चीजों की पुष्टि करें। अंतिम रन का exit status शून्य था, और नवीनतम आर्काइव हालिया है और उसका आकार लगभग उतना ही है जितना आप उम्मीद करते हैं। यदि कोई बैकअप फ़ाइल अचानक अपने सामान्य आकार की दसवां हिस्सा रह गई है, तो यह एक विफल डंप है जिसने एक फ़ाइल तो लिखी है, लेकिन यह बैकअप विफलता का सबसे खतरनाक रूप है क्योंकि इसके बाद की सभी प्रक्रियाएं सामान्य दिखाई देती हैं।

यदि आपकी स्क्रिप्ट डंप को कंप्रेसर में पाइप करती है, तो स्क्रिप्ट के शीर्ष पर set -o pipefail जोड़ें। इसके बिना, पाइपलाइन का exit status कंप्रेसर का होता है, और कंप्रेसर सफल रहा: इसने त्रुटि संदेश को कंप्रेस कर दिया। इसके बाद जॉब हर रात सफलता की रिपोर्ट देती है जबकि वास्तव में कुछ न होने का एक छोटा सा आर्काइव लिख रही होती है।

मासिक: किसी अन्य स्थान पर बैकअप रिस्टोर करें

यह वह कार्य है जिसे अधिकतर लोग छोड़ देते हैं, और यही वह बिंदु है जो यह तय करता है कि सूची के बाकी कार्यों का कोई महत्व था या नहीं।

बैकअप को किसी अलग मशीन या नए कंटेनर में रिस्टोर करें, कभी भी लाइव डेटा के ऊपर रिस्टोर न करें। इसके बाद रिस्टोर की गई सामग्री को खोलें और पुष्टि करें कि वह सही है। टेबल में पंक्तियों (rows) की गिनती करें। कोई दस्तावेज़ खोलें। रिस्टोर किए गए एप्लिकेशन में लॉग इन करें। एक सफल एक्सट्रैक्शन केवल यह सिद्ध करता है कि आर्काइव पढ़ने योग्य है, इससे अधिक कुछ नहीं।

रिपॉजिटरी टूल्स की अपनी सत्यापन प्रक्रिया होती है: restic check --read-data-subset=5% और borg check --verify-data इंडेक्स के बजाय संग्रहीत डेटा को पढ़ते हैं। इन्हें चलाएं, और इन्हें एक 'स्मोक टेस्ट' के रूप में मानें, न कि पूर्ण विकल्प के रूप में। सत्यापन यह जांचता है कि बाइट्स सुरक्षित हैं। रिस्टोर यह जांचता है कि क्या ये वही बाइट्स हैं जिनकी आपके एप्लिकेशन को आवश्यकता है।

दो विवरण ऐसे हैं जिन्हें लोग कठिन अनुभव से सीखते हैं। डिक्रिप्शन पासफ्रेज का परीक्षण ऐसी मशीन पर करें जिसमें पहले से की (key) किसी एजेंट में मौजूद न हो, क्योंकि जिस बैकअप को आप डिक्रिप्ट नहीं कर सकते, वह बैकअप नहीं है। और रिस्टोर में लगने वाले समय को मापें, क्योंकि वह अवधि ही आपका वास्तविक रिकवरी समय है, और इसे जानने का सामान्य समय आउटेज के दौरान ही होता है।

मासिक: कौन से certificates जल्द ही expire होने वाले हैं?

Renewal automation चुपचाप विफल हो जाता है। Certbot timer डिस्क पर फाइल को renew कर सकता है, लेकिन web server मेमोरी से पुराना certificate ही serve करता रहता है, क्योंकि service को reload करने वाला deploy hook नहीं चला। इसलिए, बाहर से server से पूछें कि वह क्या serve कर रहा है।

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

-servername flag SNI (server name indication) सेट करता है, जो एक से अधिक site host करने वाले किसी भी address पर आवश्यक है, अन्यथा आपको अपना certificate मिलने के बजाय default certificate मिलता है। यदि certbot को snap से install किया गया था, तो timer का नाम अलग होगा, इसलिए किसी अनुमानित unit के बजाय शब्द के आधार पर मिलान करें।

उन certificates को याद रखें जिनमें कोई automation नहीं है: mail server, VPN, या internal certificate authority। ये वे हैं जो weekend पर expire होते हैं, और browser तथा client चेतावनी देने के बजाय उन्हें पूरी तरह से अस्वीकार कर देते हैं।

मासिक कार्य: उपयोगकर्ता, sudo एक्सेस और SSH कीज़

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T कमांड हर Include के मर्ज होने के बाद प्रभावी कॉन्फ़िगरेशन को प्रिंट करता है, जिसे daemon वास्तव में उपयोग करेगा। हाल के Ubuntu इमेजेस में /etc/ssh/sshd_config.d/ में drop-in फाइलें होती हैं, और वे मुख्य फाइल को ओवरराइड कर सकती हैं, इसलिए केवल sshd_config को पढ़ने से आपको गलत जानकारी मिल सकती है। RHEL परिवार में प्रशासनिक समूह wheel होता है, न कि sudo, इसलिए getent लाइन को तदनुसार समायोजित करें।

इसके बाद स्वयं authorized_keys फाइलों को पढ़ें। एक्सेस अकाउंट के बजाय की (key) द्वारा प्रदान किया जाता है, इसलिए छह महीने पहले काम छोड़ चुके किसी कॉन्ट्रैक्टर द्वारा छोड़ी गई की एक सक्रिय लॉगिन है जिसे कोई भी उपयोगकर्ता सूची फ्लैग नहीं करेगी। कीज़ में एक कमेंट फील्ड होता है। इसका उपयोग करें, और ऐसी किसी भी चीज़ को हटा दें जिसे आप किसी व्यक्ति से नहीं जोड़ सकते।

लॉगिन इतिहास के लिए, journalctl -t sshd --since "30 days ago" | grep -i accepted यूनिट नाम के बजाय syslog आइडेंटिफ़ायर पर मैच करता है। यह महत्वपूर्ण है क्योंकि Ubuntu 24.04 एक सॉकेट के माध्यम से SSH को सक्रिय करता है, इसलिए प्रत्येक कनेक्शन एक जनरेट की गई प्रति-कनेक्शन यूनिट के तहत लॉग किया जाता है, और एक साधारण journalctl -u ssh उन्हें मिस कर सकता है।

मासिक कार्य: पुराने kernels और भरा हुआ /boot

/boot अक्सर stock VPS image पर कुछ सौ megabytes का एक अलग partition होता है। हर kernel update इसमें एक image और एक initramfs जोड़ता है। जब यह भर जाता है, तो अगला upgrade बीच में ही विफल हो जाता है और packages unconfigured रह जाते हैं। शुक्रवार को अचानक ऐसी स्थिति का सामना करना एक गंभीर समस्या हो सकती है।

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

uname -r सबसे पहले, हमेशा: यह उस kernel का नाम बताता है जिसे आप अभी चला रहे हैं, और जिसे आप हटाते हैं, उसे सुरक्षित रहना चाहिए। apt autoremove Debian और Ubuntu पर सामान्य स्थिति को संभालता है, क्योंकि kernels को automatically installed के रूप में चिह्नित किया जाता है और वर्तमान kernel सुरक्षित रहता है। विशेष स्थितियाँ, जैसे कि मैन्युअल रूप से install किया गया kernel या एक ऐसा /boot जो इतना भर चुका है कि वह apt को ही रोक रहा है, Ubuntu पर पुराने kernels को हटाना में कवर की गई हैं।

मासिक: लॉग वृद्धि और systemd journal

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

logrotate --debug एक ड्राई रन है और यह कुछ भी नहीं लिखता है, इसलिए लाइव सर्वर पर इसे चलाना सुरक्षित है। इसे चलाना इसलिए महत्वपूर्ण है क्योंकि रोटेशन नियम पाथ (paths) के आधार पर मेल खाते हैं: यदि किसी अपग्रेड के दौरान किसी एप्लिकेशन ने अपना लॉग लोकेशन बदल लिया है, तो वह अब अपने पुराने नियम के अंतर्गत नहीं आता है। ऐसी स्थिति में वह फाइल बिना किसी सीमा के बढ़ती रहती है और अंततः डिस्क को भर देती है।

journal का आकार systemd द्वारा सीमित होता है, लेकिन यह आपके द्वारा चुनी गई किसी निश्चित संख्या के बजाय फाइलसिस्टम के एक हिस्से (fraction) पर आधारित होता है। यदि आप एक निश्चित सीमा तय करना चाहते हैं, तो /etc/systemd/journald.conf में SystemMaxUse= को सेट करें और systemd-journald को रीस्टार्ट करें। sudo journalctl --vacuum-time=14d तुरंत जगह खाली कर देता है, और यह एक पॉलिसी के बजाय एक बार की जाने वाली क्रिया है, इसलिए इसे कॉन्फ़िगरेशन बदलाव के साथ ही उपयोग करें।

रिलीज़ के अनुसार: वह रीबूट जिसे आप टालते रहते हैं

डिस्क पर मौजूद अपडेटेड kernel पैकेज एक रनिंग kernel नहीं होता है। रीबूट होने तक, मशीन अभी भी पुराने kernel पर ही चलती है। लाइव पैचिंग, जहाँ उपलब्ध हो, केवल कुछ चुनिंदा सुधारों को ही कवर करती है।

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

वह फ्लैग फाइल Debian और Ubuntu की एक परंपरा है जिसे पैकेज स्क्रिप्ट द्वारा लिखा जाता है। RHEL परिवार के सिस्टम इसे नहीं बनाते हैं, और वहाँ इसी तरह के प्रश्न का उत्तर needs-restarting -r द्वारा दिया जाता है, जो dnf-utils से आता है। needrestart, जो हाल के Ubuntu सर्वर इमेज पर डिफ़ॉल्ट रूप से इंस्टॉल होता है, kernel के निचले स्तर की जानकारी देता है: यह उन प्रक्रियाओं को सूचीबद्ध करता है जो अभी भी उस लाइब्रेरी को मैप कर रही हैं जिसे डिस्क पर बदल दिया गया है। यही कारण है कि पैच की गई OpenSSL तब तक प्रभावी नहीं होती जब तक कि उसका उपयोग करने वाली सेवाएं रीस्टार्ट न हो जाएं।

रीबूट से बचने के बजाय उसे शेड्यूल करें। /etc/apt/apt.conf.d/50unattended-upgrades, Unattended-Upgrade::Automatic-Reboot "true"; और Unattended-Upgrade::Automatic-Reboot-Time "03:00"; में निर्णय को अपने चुने हुए समय पर छोड़ दें। एक नियोजित रीबूट ही यह परीक्षण करने का एकमात्र तरीका है कि क्या मशीन वापस चालू होती है, क्योंकि एक खराब fstab एंट्री या कोई ऐसी सेवा जिसे आपने कभी इनेबल नहीं किया, वह केवल बूट के समय ही सामने आती है और कहीं नहीं।

रिलीज़ के अनुसार: डिस्ट्रीब्यूशन अपग्रेड की योजना बनाना

Ubuntu LTS रिलीज़ पांच साल का स्टैंडर्ड सपोर्ट प्रदान करती हैं और अंतरिम रिलीज़ नौ महीने का, इसलिए आपका चुनाव आने वाले वर्षों के लिए आपके अपग्रेड वर्कलोड को निर्धारित करता है। यह ट्रेड-ऑफ सर्वर पर LTS बनाम अंतरिम रिलीज़ में समझाया गया है।

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade उस फ़ाइल को पढ़ता है, और Prompt=lts इसे केवल LTS-से-LTS अपग्रेड तक सीमित करता है। LTS-से-LTS का रास्ता सामान्यतः रिलीज़ के दिन के बजाय नए वर्ज़न की पहली पॉइंट रिलीज़ पर खुलता है, इसलिए यह जाँचें कि आपके मशीन को क्या ऑफर किया जा रहा है, न कि किसी अनुमानित तारीख के आधार पर योजना बनाएँ। जंप की प्रक्रिया Ubuntu 24.04 से 26.04 को अपग्रेड करना में दी गई है।

तीन महीने का मार्जिन लेकर चलें। एक स्नैपशॉट लें जिसे आपने रिस्टोर करके टेस्ट किया हो, अपनी थर्ड-पार्टी apt रिपॉजिटरी की सूची बनाएँ (अपग्रेड उन्हें डिसेबल कर देता है, और प्रत्येक को नए रिलीज़ के लिए एक नए टारगेट की आवश्यकता होती है), और शुरू करने से पहले रोलबैक की योजना तय कर लें। अगस्त 2026 तक, Ubuntu 24.04 LTS का स्टैंडर्ड सपोर्ट अप्रैल 2029 तक है, इसलिए यह एक शेड्यूलिंग का विषय है, न कि कोई आपातकालीन स्थिति।

क्या automate करें और क्या manual रखें

उन निर्णयों को automate करें जिन्हें आप पहले ही ले चुके हैं: security updates, log rotation, certificate renewal, और backup jobs। Alerting को भी automate करें, क्योंकि जो जाँच आपकी याददाश्त पर निर्भर है, वह रात के 2 बजे कभी नहीं होगी। एक external monitor, जैसे कि Uptime Kuma के साथ self-hosted status monitoring, वह एक चीज़ पकड़ लेता है जिसे कोई भी on-box script रिपोर्ट नहीं कर सकती, और वह है सर्वर का unreachable होना।

दो चीजों को manual रखें: restore test और account audit। दोनों में एक व्यक्ति की आवश्यकता होती है जो यह तय करे कि परिणाम सही है या नहीं। यदि आप terminal के बजाय browser में machine state देखना पसंद करते हैं, तो server management के लिए Cockpit बनाम Webmin दो सामान्य web consoles की तुलना करता है।

Automation को भी अपनी जाँच की आवश्यकता होती है, इसीलिए इस सूची में पहला साप्ताहिक कार्य updater को verify करना है। जो automation चुपचाप विफल (fail) हो जाता है, वह न होने से भी बदतर है, क्योंकि यह विफलता के साथ-साथ उसे देखने की आदत को भी खत्म कर देता है।

एक ही स्थान पर पूरी चेकलिस्ट

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

मुझे Linux सर्वर का रखरखाव कितनी बार करना चाहिए?

साप्ताहिक रूप से उन चीजों के लिए जो अपने आप बदलती हैं: अपडेट स्टेटस, डिस्क और inode की उपलब्धता, विफल यूनिट्स, और यह कि क्या बैकअप जॉब पूरी हो गई है। मासिक रूप से धीमी गिरावट की जाँच के लिए: रिस्टोर टेस्ट, सर्टिफिकेट की समाप्ति, अकाउंट और SSH की ऑडिट, पुराने कर्नेल, और लॉग का बढ़ना। प्रत्येक डिस्ट्रीब्यूशन रिलीज पर वर्जन अपग्रेड और वर्तमान कर्नेल में रीबूट के लिए। एक स्वस्थ सर्वर पर साप्ताहिक जाँच में कुछ ही मिनट लगते हैं, और यही इसे साप्ताहिक रूप से चलाने का उद्देश्य है, न कि तब जब कुछ गलत दिखे।

यदि बैकअप जॉब सफलता की रिपोर्ट देती है, तो भी रिस्टोर टेस्ट क्यों करें?

क्योंकि जॉब केवल अपने स्वयं के एग्जिट स्टेटस की रिपोर्ट देती है, और वह स्टेटस 'true' हो सकता है जबकि आर्काइव बेकार हो। यदि कोई डंप set -o pipefail के बिना कंप्रेसर में पाइप किया जाता है, तो वह कंप्रेसर का स्टेटस लौटाता है। इसलिए, एक विफल डंप जिसने केवल एक एरर मैसेज दिया, वह भी जीरो एग्जिट कोड देता है और एक छोटी फाइल लिखता है। किसी अलग मशीन पर रिस्टोर करें, डेटा खोलें और कुछ फाइलों की गिनती करें। रिस्टोर प्रक्रिया अपना समय भी लेती है, और वह अवधि ही आपका वास्तविक रिकवरी समय है।

क्या मुझे हर कर्नेल अपडेट के बाद रीबूट करना होगा?

नया कर्नेल रनिंग मोड में आए, इससे पहले आपको रीबूट करना होगा। Debian और Ubuntu पर /var/run/reboot-required की उपस्थिति यह बताती है कि किसी पैकेज ने इसके लिए अनुरोध किया है, और /var/run/reboot-required.pkgs यह बताता है कि कौन सा पैकेज। RHEL परिवार में वह फाइल मौजूद नहीं होती है, और dnf-utils से needs-restarting -r उसी प्रश्न का उत्तर देता है। इसे अनिश्चित काल के लिए टालने के बजाय /etc/apt/apt.conf.d/50unattended-upgrades में एक स्वचालित रीबूट विंडो सेट करें, क्योंकि जिस मशीन को एक साल से रीबूट नहीं किया गया है, उसका बूट पाथ भी अनटेस्टेड होता है और कर्नेल भी पुराना।

इनमें से किन जाँचों को मैं सुरक्षित रूप से स्वचालित (automate) कर सकता हूँ?

उन कार्यों को स्वचालित करें जिनका निर्णय पहले ही लिया जा चुका है: सुरक्षा अपडेट, लॉग रोटेशन, सर्टिफिकेट नवीनीकरण, और निर्धारित बैकअप। नोटिफिकेशन को भी स्वचालित करें, ताकि एक विफल यूनिट या भरती हुई डिस्क की सूचना आप तक पहुँच जाए, बिना किसी व्यक्ति के कमांड चलाए। रिस्टोर टेस्ट और की-ऑडिट को मैनुअल रखें, क्योंकि प्रत्येक के लिए यह निर्णय लेने हेतु एक व्यक्ति की आवश्यकता होती है कि परिणाम सही है या नहीं। फिर ऑटोमेशन पर ही एक जाँच जोड़ें, क्योंकि एक साइलेंट अपडेटर विफलता बिल्कुल वैसी ही दिखती है जैसे सब कुछ सही चल रहा हो।