Linux server maintenance checklist: వారపు, నెలవారీ checks

Linux server maintenance అంటే వాస్తవంగా ఏమిటి

Linux server maintenance అనేది ముగింపు లేని project కాదు. ఇది నిర్ణయించిన schedule ప్రకారం నిర్వహించే కొద్దిపాటి checks సమాహారం. ప్రతి వారం updates install అయ్యాయా, disk లో తగినంత స్థలం ఉందా, ఏదైనా service నిలిచిపోయిందా, backup job పూర్తయిందా అనే విషయాలను నిర్ధారించాలి. ప్రతి నెల restore ను test చేయాలి, certificate expiry ను తనిఖీ చేయాలి, accounts మరియు keys ను audit చేయాలి, పాత kernels మరియు logs ను తొలగించాలి. ప్రతి distribution release కు ఒకసారి version upgrade కోసం ప్రణాళిక వేయాలి. వాయిదా వేస్తూ వచ్చిన reboot ను అప్పుడు నిర్వహించాలి.

Server ను నిర్మించడం వేరే పని. కొత్త VPS పై మొదటి పది నిమిషాలు ఆ భాగాన్ని వివరిస్తుంది. ఈ పేజీ దాని తరువాతి ఏడాది నిర్వహణ గురించి. క్రింద ఉన్న ప్రతి అంశం అది నివారించే failure ను పేర్కొంటుంది. కారణాలు తెలియని checklist ను ప్రజలు నిశ్శబ్దంగా అమలు చేయడం మానేస్తారు.

ఇక్కడి commands ఉదాహరణల కోసం మాత్రమే. వాటిని run చేయడానికి ముందు చదవాలి. వాటి output ను మీ server తో పోల్చండి. Free space లేదా process count కు సరైన విలువ server నిర్వహించే పనిపై ఆధారపడి ఉంటుంది. Distributions మధ్య ఏదైనా check మారితే, పాఠ్యంలో అది పేర్కొనబడుతుంది. ఉదాహరణలు Debian మరియు Ubuntu ను apt తో ఉపయోగిస్తాయి. RHEL family లో tooling dnf, అలాగే అనేక paths భిన్నంగా ఉంటాయి.

మీరు పాటించగల Linux server maintenance cadence ను ఎలా ఎంచుకోవాలి

Weekly checks ద్వారా మీ ప్రమేయం లేకుండానే మారే అంశాలను పరిశీలిస్తారు: packages, disk usage, service state, scheduled jobs. ఇవి స్వయంగా మారుతుంటాయి. అందువల్ల వాటిని చదవకుండా వదిలేయగల గరిష్ఠ వ్యవధి సుమారు ఒక వారం.

Monthly checks ద్వారా నెమ్మదిగా ఏర్పడే సమస్యలను పరిశీలిస్తారు: expiry కి చేరువవుతున్న certificates, ఎవరూ తొలగించని accounts, /boot లో పేరుకుపోతున్న kernels, rotation rule కు సరిపోకుండా పెరుగుతున్న log files. వీటిలో ఏదీ రేపే విఫలం కాదు. కానీ చివరికి అన్నీ విఫలమవుతాయి.

Release checks క్యాలెండర్ ఆధారంగా జరుగుతాయి. మీ ప్రస్తుత version కు support ముగిసే తేదీ మీ సంసిద్ధతతో సంబంధం లేకుండా వస్తుంది. అందువల్ల distribution release అనేది బాహ్య గడువు కలిగిన ఏకైక maintenance అంశం.

ఈ పనికి ఒక స్థిరమైన సమయాన్ని కేటాయించండి: weekly pass కోసం సోమవారం ఉదయం, monthly pass కోసం నెలలో మొదటి రోజు. “సమయం దొరికినప్పుడు” చేసే checklist run అసలు checklist కాదు. కొన్ని machines దాటిన తర్వాత వీటిని చేతితో కాకుండా ఒకే స్థానం నుంచి నిర్వహించండి. దీనినే ఒకే స్థానం నుంచి అనేక Linux servers ను నిర్వహించడం గురించి తర్వాతి భాగంలో వివరిస్తారు.

వారానికి ఒకసారి: updates నిజంగా install అయ్యాయా?

unattended-upgrades ను enable చేయడం మాత్రమే అది run అయిందని నిర్ధారించదు. Service masked అయి ఉండవచ్చు. Configuration మీరు ఉపయోగించని origin కు పరిమితం అయి ఉండవచ్చు. Holdలో ఉన్న ఒక package తరువాత జరిగే ప్రతి run ను విఫలమయ్యేలా చేయవచ్చు. దీన్ని install చేసే విధానం Ubuntuలో automatic security updates లో ఉంది. మీరు install చేసిన వ్యవస్థ నిజంగా పని చేసిందని నిర్ధారించడమే వారపు job ఉద్దేశం.

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 వాస్తవ స్థితిని తెలియజేస్తుంది కాబట్టి ఇది నమ్మదగిన కొలత. ఇది ఉద్దేశాన్ని కాకుండా ప్రస్తుత state ను report చేస్తుంది. ఆ జాబితాలో ఇంకా security updates ఉంటే automation సరిగ్గా పని చేయడం లేదు. కాబట్టి machine patched అయిందని అనుకునే ముందు log చదవండి. apt-mark hold తో pinned చేసిన package ఎప్పటికీ skip అవుతుంది, అయితే ఎలాంటి సమాచారం report చేయదు. అందుకే అదే passలో apt-mark showhold ను కూడా పరిశీలించాలి.

దీని వల్ల నివారించేది: updates automaticగా జరుగుతున్నాయని నమ్ముతూ, తెలిసిన vulnerability ఉన్న package ను నెలల తరబడి run చేయడం.

వారానికి ఒకసారి: డిస్క్ మరియు inode ఖాళీ సామర్థ్యం

root filesystem నిండిపోతే, డిస్క్‌కు సంబంధం లేనట్టుగా కనిపించే సమస్యలు కూడా ఏర్పడతాయి. Database writeలను నిరాకరిస్తుంది, logging ఆగిపోతుంది, package upgrade సగం configuration తర్వాత విఫలమవుతుంది. కొన్ని setupsలో, సొంత files రాయలేకపోవడం వల్ల కొత్త session‌ను కూడా తెరవలేరు.

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

df -i అనేది చాలా మంది దాటవేసే సగం. Inodes అనేవి file metadataను నిల్వ చేసే స్థిర సంఖ్యలో ఉండే structures. df -h ఇంకా gigabytes ఖాళీగా ఉన్నాయని చూపిస్తున్నప్పటికీ, filesystem inodes అయిపోవచ్చు. అప్పుడు space మిగిలి ఉందని చూపించే output పక్కనే No space left on device తో writes విఫలమవుతాయి. ఇది మొదటిసారి ఎదురైనప్పుడు కారణాన్ని గుర్తించడానికి ఒక గంట వరకు గందరగోళంగా వెచ్చించాల్సి రావచ్చు. Stuck mail queue లేదా ఎవరూ prune చేయని session directory నుంచి ఏర్పడే లక్షల చిన్న files సాధారణ కారణాలు.

du -xh ఒకే filesystemలోనే ఉంటుంది. Bind mounts లేదా attached storage ఉన్న boxలో ఇదే కావాలి. Docker hostలో సమాధానం సాధారణంగా image layers మరియు dead volumesలో ఉంటుంది. VPSలో Docker disk వినియోగాన్ని prune చేయడంలో వివరించిన విధంగా వాటిని తొలగించవచ్చు.

Free space capacity గురించి చెబుతుంది. దాని కింద ఉన్న storage తన స్వంత కాలక్రమంలో విఫలమవుతుంది. ఇది వేరుగా పరిశీలించాల్సిన విషయం. దీనిని VPSలో disk health monitoringలో వివరించాం.

వారానికొకసారి: ఏది మీకు తెలియకుండా ఆగిపోయింది?

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

క్రాష్ అయి, పునఃప్రారంభ పరిమితిని చేరుకున్న unit failed స్థితిలోనే ఉండిపోతుంది. అది మీకు ఎలాంటి notification పంపదు. list-timers మరింత ఉపయోగకరమైన భాగం: ప్రతి timer చివరిసారి ఎప్పుడు అమలైందో, తదుపరి సారి ఎప్పుడు అమలవుతుందో ఇది చూపిస్తుంది. అందువల్ల timer యొక్క స్వంత interval కంటే పాత LAST విలువ ఉంటే, ఆ job అసలు అమలు కాలేదని అర్థం.

దాన్ని పునఃప్రారంభించే ముందు journalctl -u <unit> -n 100 --no-pager తో ఆ unit కు సంబంధించిన journal ను చదవండి. Restart చేస్తే కనిపిస్తున్న లక్షణం తాత్కాలికంగా తొలగిపోతుంది. ఆ తర్వాత అదే సమస్య మరింత అనుకూలం కాని సమయంలో మళ్లీ వచ్చే వరకు మీరు తిరిగి పరిశీలించకపోవచ్చు.

దీని వల్ల నివారించబడే వైఫల్యం: మూడు వారాల క్రితం memory spike తర్వాత పనిచేయకుండా ఉన్న monitoring agent, queue worker లేదా backup service.

వారానికి ఒకసారి: backup job నిజంగా పూర్తయిందా?

షెడ్యూల్ చేసిన backup మరియు పూర్తయిన backup రెండు వేర్వేరు విషయాలు. Restore చేయడానికి ఉపయోగపడేది పూర్తయిన backup మాత్రమే. Completion ను తనిఖీ చేయండి.

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

రెండు విషయాలను నిర్ధారించండి. చివరి run zero తో ముగిసిందా, అలాగే కొత్త archive తాజాగా ఉందా మరియు మీరు ఆశించే పరిమాణానికి సుమారుగా సరిపోతుందా చూడండి. సాధారణ పరిమాణంలో పదో వంతుగా అకస్మాత్తుగా మారిన backup file, file ను రాసినప్పటికీ విఫలమైన dump కావచ్చు. ఇది అత్యంత ప్రమాదకరమైన backup failure రూపం, ఎందుకంటే తరువాతి అన్ని దశలు సాధారణంగానే కనిపిస్తాయి.

మీ script dump ను compressor కు pipe చేస్తే, ప్రారంభంలో set -o pipefail ను జోడించండి. ఇది లేకపోతే pipeline యొక్క exit status compressor కు చెందినదిగా ఉంటుంది. Compressor విజయవంతమైంది: అది error message ను compress చేసింది. ఫలితంగా job ప్రతి రాత్రి success ను report చేస్తూనే ఉంటుంది, కానీ ఖాళీ డేటాతో చిన్న archive ను రాస్తుంది.

నెలవారీగా: backup ను వేరే చోట restore చేయండి

చాలామంది దాటవేసే అంశం ఇదే. మిగతా జాబితా ఉపయోగపడిందా లేదా అన్నది దీనిపైనే ఆధారపడి ఉంటుంది.

దీన్ని live data పై ఎప్పుడూ చేయకండి. బదులుగా వేరే machine లేదా కొత్త container కు restore చేయండి. తరువాత restore చేసినదాన్ని తెరిచి, అది నిజంగా ఉపయోగపడే data కాదో నిర్ధారించండి. ఒక table లోని rows ను లెక్కించండి. ఒక document ను తెరవండి. restore చేసిన application లో login చేయండి. Extraction పూర్తయిందంటే archive చదవగలమని మాత్రమే నిర్ధారించబడుతుంది. అంతకంటే ఎక్కువ కాదు.

Repository tools కు స్వంత verification విధానాలు ఉంటాయి: restic check --read-data-subset=5% మరియు borg check --verify-data index ను కాకుండా నిల్వ చేసిన data ను చదువుతాయి. వాటిని run చేయండి. అయితే వాటిని smoke test గా మాత్రమే పరిగణించండి; పూర్తి ప్రత్యామ్నాయంగా కాదు. Verification ద్వారా bytes సురక్షితంగా ఉన్నాయా అని తెలుస్తుంది. Restore ద్వారా ఆ bytes మీ application కు అవసరమైనవేనా అని నిర్ధారించబడుతుంది.

రెండు విషయాలను చాలామంది సమస్య ఎదురైన తర్వాతే నేర్చుకుంటారు. Decryption passphrase ను ఇప్పటికే agent లో key ఉన్న machine పై కాకుండా, వేరే machine పై పరీక్షించండి. మీరు decrypt చేయలేని backup, backup కాదు. అలాగే restore కు పట్టే సమయాన్ని కొలవండి. అదే మీ వాస్తవ recovery time. ఆ సమయం ఎంతనేది సాధారణంగా outage సమయంలోనే తెలుస్తుంది.

నెలవారీగా: త్వరలో గడువు ముగియనున్న certificates ఏవి?

Renewal automation నిశ్శబ్దంగా విఫలమవుతుంది. web server memoryలో పాత certificateనే అందిస్తూ ఉండగా, certbot timer diskపై ఉన్న fileను renew చేయవచ్చు. Serviceను reload చేసే deploy hook అమలు కాకపోవడం దీనికి కారణం. అందువల్ల server బయట నుంచి, ప్రస్తుతం నడుస్తున్న server ఏ certificateను అందిస్తోందో అడగాలి.

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) ను సెట్ చేస్తుంది. ఒకే addressపై ఒకటి కంటే ఎక్కువ sites host చేస్తున్నప్పుడు ఇది అవసరం. లేకపోతే మీ certificateకు బదులుగా default certificate అందుతుంది. certbot ను snap నుంచి install చేసి ఉంటే timer పేరు వేరుగా ఉంటుంది. కాబట్టి మీరు ఊహించిన unit పేరు కాకుండా, ఆ పదాన్ని సరిపోల్చండి.

అసలు automation ఏదీ లేని certificatesను కూడా గుర్తుంచుకోండి: mail server, VPN, internal certificate authority. వీటి గడువు వారాంతంలో ముగిసే అవకాశం ఉంది. Browsers మరియు clients warning చూపించకుండా వాటిని పూర్తిగా తిరస్కరిస్తాయి.

నెలవారీ: వినియోగదారులు, sudo ప్రాప్యత మరియు SSH keys

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 merge చేసిన తర్వాత అమలులో ఉండే configuration ను చూపిస్తుంది. Daemon వాస్తవంగా ఉపయోగించేది అదే configuration. ఇటీవలి Ubuntu images లో /etc/ssh/sshd_config.d/ లో drop-in files ఉంటాయి. ఇవి ప్రధాన file లోని settings ను override చేయవచ్చు. అందువల్ల sshd_config ను మాత్రమే చదివితే వాస్తవానికి విరుద్ధమైన నిర్ధారణకు రావచ్చు. RHEL family లో administrative group wheel, sudo కాదు. కాబట్టి getent line ను సవరించండి.

తర్వాత authorized_keys files ను నేరుగా చదవండి. ప్రాప్యత account ఆధారంగా కాదు, key ఆధారంగా మంజూరు అవుతుంది. కాబట్టి ఆరు నెలల క్రితం పని ముగించిన contractor వదిలిన key ఇప్పటికీ పనిచేసే login అవుతుంది. ఏ user list కూడా దాన్ని గుర్తించకపోవచ్చు. Keys లో comment field ఉంటుంది. దాన్ని ఉపయోగించండి. ఏ వ్యక్తికి చెందినదో నిర్ధారించలేని వాటిని తొలగించండి.

Login history కోసం journalctl -t sshd --since "30 days ago" | grep -i accepted unit name కంటే syslog identifier ఆధారంగా సరిపోల్చుతుంది. ఇది ముఖ్యమైన విషయం. Ubuntu 24.04 SSH ను socket ద్వారా activate చేస్తుంది. అందువల్ల ప్రతి connection, ఆ connection కోసం రూపొందించిన ప్రత్యేక unit కింద log అవుతుంది. సాధారణ journalctl -u ssh వాటిని గుర్తించకపోవచ్చు.

నెలవారీ నిర్వహణ: పాత kernels మరియు పూర్తిగా నిండిన /boot

/boot సాధారణ 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 పేరును ఇది చూపిస్తుంది. మీరు తొలగించే ఏ kernel అయినా ఈ kernel మిగిలి ఉండాలి. Debian మరియు Ubuntuలో సాధారణ పరిస్థితిని apt autoremove నిర్వహిస్తుంది. ఎందుకంటే kernels ను automatically installed గా గుర్తిస్తారు, అలాగే ప్రస్తుతం నడుస్తున్న kernelకు రక్షణ ఉంటుంది. manually installed kernel లేదా apt ను కూడా అడ్డుకునేంతగా ఇప్పటికే నిండిపోయిన /boot వంటి ప్రత్యేక పరిస్థితులకు Ubuntuలో పాత kernels ను తొలగించడంలో విధానం ఉంది.

నెలవారీ: log పెరుగుదల మరియు systemd journal

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

logrotate --debug అనేది dry run. ఇది ఏదీ రాయదు కాబట్టి live boxపై సురక్షితం. దీన్ని అమలు చేయడం ఉపయోగకరం, ఎందుకంటే rotation నియమాలు paths ఆధారంగా వర్తిస్తాయి. Upgrade సమయంలో application తన log location ను మార్చితే, ఆ application యొక్క స్వంత నియమం ఇక వర్తించదు. ఆ file disk నిండే వరకు పరిమితి లేకుండా పెరుగుతుంది.

systemd journal కు పరిమితి ఉంటుంది. అయితే అది మీరు ఎంచుకున్న సంఖ్య ఆధారంగా కాకుండా filesystem లోని కొంత భాగం ఆధారంగా ఉంటుంది. నిర్దిష్ట గరిష్ఠ పరిమితి కావాలంటే /etc/systemd/journald.conf లో SystemMaxUse= ను సెట్ చేసి, systemd-journald ను restart చేయండి. sudo journalctl --vacuum-time=14d స్థలాన్ని వెంటనే తిరిగి పొందుతుంది. ఇది policy కాదు, ఒకసారి చేసే చర్య మాత్రమే. అందువల్ల దీన్ని configuration మార్పుతో కలిపి అమలు చేయండి.

ప్రతి విడుదలలో: మీరు పదేపదే వాయిదా వేస్తున్న reboot

డిస్క్‌లో ఉన్న updated kernel package అమలులో ఉన్న kernel కాదు. reboot చేసే వరకు machine పాత kernel పైనే నడుస్తుంది. live patching అందుబాటులో ఉన్నప్పటికీ, అది కొన్ని fixes కు మాత్రమే వర్తిస్తుంది.

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

ఆ flag file ను package scripts రాసే Debian మరియు Ubuntu convention గా ఉపయోగిస్తాయి. RHEL family systems దాన్ని సృష్టించవు. అక్కడ సమానమైన ప్రశ్నకు needs-restarting -r సమాధానం ఇస్తుంది. అది dnf-utils నుంచి వస్తుంది. ఇటీవలి Ubuntu server images లో default గా install అయ్యే needrestart, kernel కంటే దిగువ స్థాయిని చూపిస్తుంది. డిస్క్‌లో replace చేసిన library ను ఇప్పటికీ map చేస్తున్న processes ను ఇది జాబితా చేస్తుంది. అందుకే patched OpenSSL ను ఉపయోగిస్తున్న services restart అయ్యే వరకు ఆ patch అమలులోకి రాదు.

reboot ను నివారించకుండా దాన్ని schedule చేయండి. /etc/apt/apt.conf.d/50unattended-upgrades, Unattended-Upgrade::Automatic-Reboot "true"; మరియు Unattended-Upgrade::Automatic-Reboot-Time "03:00"; లో నిర్ణయాన్ని మీరు ఎంచుకున్న సమయానికి అప్పగించవచ్చు. planned reboot ద్వారా మాత్రమే box తిరిగి సరిగా ప్రారంభమవుతుందో పరీక్షించవచ్చు. ఎందుకంటే తప్పుగా ఉన్న fstab entry లేదా మీరు ఎప్పుడూ enable చేయని service boot సమయంలోనే బయటపడుతుంది; మరెక్కడా కనిపించదు.

ప్రతి విడుదలకు: distribution upgrade ప్రణాళిక

Ubuntu LTS releases కు ఐదు సంవత్సరాల standard support ఉంటుంది. interim releases కు తొమ్మిది నెలల support ఉంటుంది. కాబట్టి ఈ ఎంపిక మీ upgrade పనిభారాన్ని అనేక సంవత్సరాలకు నిర్ణయిస్తుంది. ఈ trade-off గురించి సర్వర్‌లో LTS మరియు interim releases మధ్య ఎంపిక చూడండి.

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

do-release-upgrade ఆ file ను చదువుతుంది. Prompt=lts దానిని LTS-to-LTS మార్పులకు మాత్రమే పరిమితం చేస్తుంది. LTS-to-LTS మార్గం సాధారణంగా కొత్త version విడుదలైన రోజున కాకుండా, ఆ version యొక్క మొదటి point release వచ్చినప్పుడు ప్రారంభమవుతుంది. కాబట్టి మీరు ఊహించిన తేదీ ఆధారంగా ప్రణాళిక చేయకుండా, మీ machine కు ఏది అందుబాటులో ఉందో పరిశీలించండి. Upgrade చేసే విధానం Ubuntu 24.04 ను 26.04 కు upgrade చేయడం లో ఉంది.

మూడు నెలల అదనపు సమయాన్ని ప్రణాళికలో ఉంచండి. Restore చేసి పరీక్షించిన snapshot తీసుకోండి. మీ third-party apt repositories జాబితాను తయారు చేయండి. Upgrade సమయంలో అవి disable అవుతాయి. కొత్త release కోసం ప్రతి repository కి కొత్త target అవసరం. Upgrade ప్రారంభించే ముందు rollback విధానాన్ని నిర్ణయించండి. August 2026 నాటికి Ubuntu 24.04 LTS కు April 2029 వరకు standard support ఉంది. కాబట్టి ఇది అత్యవసర చర్య కాదు; scheduling అవసరం.

ఏవి ఆటోమేట్ చేయాలి, ఏవి మాన్యువల్‌గా ఉంచాలి

మీరు ఇప్పటికే తీసుకున్న నిర్ణయాలను ఆటోమేట్ చేయండి: security updates, log rotation, certificate renewal, backup jobs. Alerting ను కూడా ఆటోమేట్ చేయండి. ఎందుకంటే మీరు గుర్తుంచుకున్నప్పుడే జరిగే check, రాత్రి 2am సమయంలో జరగకపోవచ్చు. Uptime Kumaతో self-hosted status monitoring వంటి external monitor, on-box script ఏదీ report చేయలేని ఒక విషయాన్ని గుర్తిస్తుంది: server అందుబాటులో లేకపోవడం.

రెండు పనులను మాన్యువల్‌గా ఉంచండి: restore test మరియు account audit. రెండింటిలోనూ ఫలితం సరైనదేనా అని ఒక వ్యక్తి నిర్ణయించాలి. Terminal కంటే browserలో machine state చూడాలనుకుంటే, server management కోసం Cockpit మరియు Webmin మధ్య తులన సాధారణంగా ఉపయోగించే ఈ రెండు web consoles ను పోల్చి చూపుతుంది.

Automation కు కూడా స్వంత check అవసరం. అందుకే ఈ జాబితాలోని మొదటి weekly item updater ను verify చేయడం. నిశ్శబ్దంగా విఫలమయ్యే automation, automation లేకపోవడంకన్నా ప్రమాదకరం. ఎందుకంటే అది failure ను కూడా, అదే సమయంలో పరిశీలించే అలవాటును కూడా తొలగిస్తుంది.

మొత్తం checklist ఒకే చోట

# 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 server maintenance ను ఎంత తరచుగా నిర్వహించాలి?

తనంతట తానే మారే అంశాలను ప్రతి వారం పరిశీలించండి: update status, disk మరియు inode headroom, failed units, అలాగే backup job పూర్తయిందా లేదా అన్నది. నెమ్మదిగా క్షీణించే అంశాలను ప్రతి నెల పరిశీలించండి: restore test, certificate expiry, account మరియు SSH key audit, పాత kernels, log growth. Version upgrade మరియు ప్రస్తుత kernel లోకి reboot కోసం ప్రతి distribution release సమయంలో ఒకసారి నిర్వహించండి. ఆరోగ్యంగా ఉన్న server పై వారపు పరిశీలనకు కొన్ని నిమిషాలే పడతాయి. ఏదైనా తప్పుగా కనిపించినప్పుడు మాత్రమే కాకుండా ప్రతి వారం నిర్వహించడంలో ఉద్దేశం ఇదే.

Backup job విజయవంతమైందని చూపించినా restore ను ఎందుకు పరీక్షించాలి?

ఎందుకంటే job తన స్వంత exit status ను నివేదిస్తుంది. ఆ status విజయవంతంగా ఉన్నప్పటికీ archive ఉపయోగించలేనిదిగా ఉండవచ్చు. set -o pipefail లేకుండా dump ను compressor కు pipe చేస్తే compressor యొక్క status తిరిగి వస్తుంది. అందువల్ల error message మాత్రమే ఉత్పత్తి చేసిన failed dump కూడా zero తో exit అయి చిన్న file ను రాయవచ్చు. వేరే machine కు restore చేసి, data ను తెరిచి, ఏదైనా అంశాల సంఖ్యను లెక్కించండి. Restore కు పట్టిన సమయాన్ని కూడా నమోదు చేయండి. ఆ వ్యవధే మీ వాస్తవ recovery time.

ప్రతి kernel update తర్వాత reboot చేయాలా?

కొత్త kernel running kernel కావడానికి ముందు reboot చేయాలి. Debian మరియు Ubuntu లో /var/run/reboot-required ఉండటం ఒక package దాన్ని కోరిందని సూచిస్తుంది. ఏ package కోరిందో /var/run/reboot-required.pkgs చూపిస్తుంది. RHEL family లో ఆ file ఉండదు. అక్కడ dnf-utils నుంచి వచ్చిన needs-restarting -r అదే ప్రశ్నకు సమాధానం ఇస్తుంది. /etc/apt/apt.conf.d/50unattended-upgrades లో automatic reboot window ను సెట్ చేయండి. దాన్ని నిరవధికంగా వాయిదా వేయకండి. ఒక సంవత్సరం reboot కాని machine లో పాత kernel మాత్రమే కాకుండా, పరీక్షించని boot path కూడా ఉంటుంది.

వీటిలో ఏ checks ను సురక్షితంగా automate చేయవచ్చు?

ఇప్పటికే నిర్ణయం స్పష్టంగా ఉన్న చర్యలను automate చేయండి: security updates, log rotation, certificate renewal, scheduled backups. Notification ను కూడా automate చేయండి. అప్పుడు failed unit లేదా నిండిపోతున్న disk గురించి ఎవరైనా command నడిపే వరకు వేచి ఉండకుండా మీకు సమాచారం అందుతుంది. Restore test మరియు key audit ను manual గా ఉంచండి. ప్రతి ఫలితం సరైనదేనా అని వ్యక్తి నిర్ణయించాల్సి ఉంటుంది. Automation పైన కూడా ఒక check జోడించండి. ఎందుకంటే నిశ్శబ్దంగా విఫలమైన updater, ప్రతిదీ సక్రమంగా పనిచేస్తున్నట్లే కనిపిస్తుంది.