Linux server பராமரிப்பு செய்வது எப்படி? முழுமையான பட்டியல்

Linux server பராமரிப்பு என்பது உண்மையில் என்ன

Linux server பராமரிப்பு என்பது ஒரு குறிப்பிட்ட கால இடைவெளியில் செய்யப்படும் சிறிய அளவிலான சோதனைகளின் தொகுப்பாகும்; இது முடிவற்ற ஒரு தொடர் செயல்முறை. வாரந்தோறும், updates சரியாக நிறுவப்பட்டுள்ளதா, வட்டில் (disk) போதுமான இடம் உள்ளதா, ஏதேனும் service நின்றுவிட்டதா, மற்றும் backup பணி முடிவடைந்துள்ளதா என்பதை உறுதிப்படுத்த வேண்டும். மாதந்தோறும், ஒரு restore சோதனையைச் செய்து பார்க்க வேண்டும், certificate காலாவதி தேதியைச் சரிபார்க்க வேண்டும், கணக்குகள் (accounts) மற்றும் keys-களை தணிக்கை செய்ய வேண்டும், மேலும் பழைய kernels மற்றும் logs-களை நீக்க வேண்டும். ஒவ்வொரு distribution release-க்கும் ஒருமுறை, version upgrade-க்குத் திட்டமிட்டு, நீங்கள் தள்ளிப்போட்டுக்கொண்டே இருக்கும் reboot-ஐச் செய்ய வேண்டும்.

Server-ஐ உருவாக்குவது ஒரு தனி வேலை, புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற பகுதி அதை விளக்குகிறது. இந்தப் பக்கம் அதற்குப் பிந்தைய ஓராண்டு காலத்திற்கான வழிகாட்டி. கீழே உள்ள ஒவ்வொரு உருப்படியும் அது தடுக்கும் தோல்வியைக் குறிப்பிடுகிறது, ஏனெனில் விளைவுகள் தெரியாத checklist-களை மக்கள் மெதுவாகச் செய்ய நிறுத்திவிடுவார்கள்.

இங்கே கொடுக்கப்பட்டுள்ள கட்டளைகள் விளக்கத்திற்காக மட்டுமே; அவற்றை இயக்குவதற்கு முன்பு படித்துப் புரிந்துகொள்ள வேண்டும். வட்டில் உள்ள காலி இடம் அல்லது process எண்ணிக்கை போன்ற மதிப்புகள் உங்கள் server-ன் பயன்பாட்டைப் பொறுத்து மாறுபடும் என்பதால், அவற்றின் வெளியீட்டை உங்கள் server-உடன் ஒப்பிட்டுப் பார்க்கவும். சோதனைகள் distribution-க்கு ஏற்ப மாறும்போது, அது உரையில் குறிப்பிடப்பட்டுள்ளது. எடுத்துக்காட்டுகள் Debian மற்றும் Ubuntu-வை apt உடன் பயன்படுத்துகின்றன. RHEL குடும்பத்தில், கருவிகள் dnf ஆக இருக்கும் மற்றும் பல கோப்புப் பாதைகள் (paths) மாறுபடும்.

Linux server பராமரிப்பு கால அட்டவணையை எவ்வாறு தேர்வு செய்வது

வாராந்திர சோதனைகள் உங்கள் தலையீடு இன்றி மாறும் விஷயங்களை உள்ளடக்கியவை: packages, disk usage, service state, மற்றும் scheduled jobs. இவை தானாகவே மாறுபவை என்பதால், ஒரு வாரம் என்பது இவற்றை கவனிக்காமல் இருக்கக்கூடிய அதிகபட்ச காலமாகும்.

மாதாந்திர சோதனைகள் மெதுவாக ஏற்படும் மாற்றங்களைக் கவனிக்கின்றன: காலாவதியாகும் certificates, நீக்கப்படாத accounts, /boot-ல் குவியும் kernels, மற்றும் rotation விதிகளுக்கு உட்படாத log files. இவை உடனடியாகப் பாதிப்பை ஏற்படுத்தாது. ஆனால், காலப்போக்கில் இவை நிச்சயம் சிக்கலை உருவாக்கும்.

Release சோதனைகள் காலண்டரை அடிப்படையாகக் கொண்டவை. ஒரு distribution release என்பது வெளிப்புற காலக்கெடுவைக் கொண்ட பராமரிப்புப் பணியாகும். ஏனெனில், நீங்கள் தயாராக இருந்தாலும் இல்லாவிட்டாலும், உங்கள் தற்போதைய பதிப்பிற்கான ஆதரவு முடிவுக்கு வரும்.

பராமரிப்புப் பணிகளை ஒரு குறிப்பிட்ட நேரத்தில் செய்யுங்கள்; வாராந்திரப் பணிகளுக்கு திங்கள் காலை மற்றும் மாதாந்திரப் பணிகளுக்கு மாதத்தின் முதல் தேதியை ஒதுக்குங்கள். "நேரம் கிடைக்கும்போது செய்யலாம்" என்று வைத்திருக்கும் checklist ஒருபோதும் முழுமையடையாது. சில server-களுக்கு மேல் நிர்வகிக்கும்போது, இவற்றை ஒவ்வொன்றாகச் செய்வதற்குப் பதிலாக ஒரே இடத்திலிருந்து செய்யுங்கள். இதைப் பற்றி ஒரே இடத்திலிருந்து பல Linux server-களை நிர்வகித்தல் பகுதியில் விரிவாகக் காணலாம்.

வாராந்திர ஆய்வு: மேம்படுத்தல்கள் உண்மையில் நிறுவப்பட்டனவா?

unattended-upgrades-ஐ செயல்படுத்துவது, அது இயங்கியதை உறுதிப்படுத்துவதற்குச் சமமல்ல. ஒரு service-ஐ masked நிலையில் வைத்திருக்கலாம், நீங்கள் பயன்படுத்தாத ஒரு source-க்கு மட்டும் configuration-ஐக் கட்டுப்படுத்தலாம், மேலும் ஒரு package-ஐ hold செய்திருந்தால் அது அடுத்தடுத்த அனைத்து இயக்கங்களையும் பாதிக்கும். இதை நிறுவுவது 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 என்பது தற்போதைய நிலையைத் துல்லியமாகத் தெரிவிப்பதால், இதுவே உண்மையான அளவீடு ஆகும். அந்தப் பட்டியலில் பாதுகாப்பு மேம்படுத்தல்கள் இன்னும் அப்படியே இருந்தால், தானியங்கி முறை சரியாகச் செயல்படவில்லை என்று அர்த்தம். எனவே, கணினி patch செய்யப்பட்டுவிட்டது என்று கருதுவதற்கு முன் log-ஐப் படிக்கவும். apt-mark hold மூலம் pinned செய்யப்பட்ட ஒரு package எப்போதும் தவிர்க்கப்படும் மற்றும் அது எதையும் தெரிவிக்காது, இதனால்தான் apt-mark showhold-ஐ அதே pass-ல் சேர்க்க வேண்டும்.

இது தடுக்கும் தோல்வி: மேம்படுத்தல்கள் தானாகவே நடப்பதாக நம்பிக்கொண்டு, பாதிப்புள்ள (vulnerable) ஒரு package-ஐ மாதக்கணக்கில் இயக்குவதைத் தவிர்க்கலாம்.

வாராந்திர ஆய்வு: disk மற்றும் inode இருப்பு

Root filesystem முழுமையாக நிரம்பினால், disk-உடன் தொடர்பில்லாதது போலத் தோன்றும் பல சிக்கல்கள் ஏற்படும். Database-ல் தரவுகளை எழுத முடியாது, logging நின்றுவிடும், package upgrade பாதியில் நின்றுவிடும். சில அமைப்புகளில், புதிய session-களைத் தொடங்கத் தேவையான கோப்புகளை எழுத முடியாததால், உங்களால் login செய்யவே முடியாமல் போகலாம்.

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

df -i என்பது பெரும்பாலானோர் கவனிக்கத் தவறும் ஒரு பகுதியாகும். Inodes என்பது கோப்புகளின் metadata-வைச் சேமிக்கும் நிலையான எண்ணிக்கையிலான கட்டமைப்புகள் ஆகும். df -h கட்டளை இன்னும் சில gigabytes காலியாக இருப்பதாகக் காட்டினாலும், filesystem-ல் inodes தீர்ந்துபோக வாய்ப்புள்ளது. அப்போது, போதிய இடம் இருப்பதாகக் காட்டும் வெளியீட்டிற்கு அருகிலேயே No space left on device பிழை தோன்றி, எழுதும் செயல்பாடு தோல்வியடையும். இது முதல்முறை நிகழும்போது, காரணத்தைப் புரிந்துகொள்ள நீண்ட நேரம் எடுக்கும். தேங்கிக் கிடக்கும் mail queue அல்லது யாரும் சுத்தம் செய்யாத session directory போன்ற இடங்களில் உள்ள லட்சக்கணக்கான சிறிய கோப்புகளே இதற்கு முக்கியக் காரணமாகும்.

du -xh ஒரே filesystem-ல் மட்டுமே செயல்படும்; bind mounts அல்லது இணைக்கப்பட்ட storage உள்ள server-களில் இதுவே உங்களுக்குத் தேவை. Docker host-ஐப் பொறுத்தவரை, இதற்கான தீர்வு பெரும்பாலும் image layers மற்றும் பயன்பாடற்ற volumes-ல் உள்ளது. இவற்றை VPS-ல் Docker disk பயன்பாட்டைச் சுத்தம் செய்தல் என்பதில் விவரிக்கப்பட்டுள்ளபடி நீக்கலாம்.

Free space என்பது உங்கள் சேமிப்பகத்தின் கொள்ளளவை மட்டுமே குறிக்கும். அதன் அடியில் உள்ள storage வன்பொருள் அதன் சொந்த கால அட்டவணையின்படி செயலிழக்கலாம். இது தனிப்பட்ட சோதனையாகும், இதைப் பற்றி VPS-ல் disk ஆரோக்கியத்தைக் கண்காணித்தல் என்பதில் காணலாம்.

வாராந்திர ஆய்வு: அறிவிப்பின்றி நின்றவை எவை?

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

ஒரு unit செயலிழந்து, அதன் restart வரம்பை எட்டிய பிறகு, அது failed நிலையில் அமைதியாகத் தங்கிவிடும். இது குறித்து உங்களுக்கு எந்த மின்னஞ்சல் அறிவிப்பும் வராது. list-timers என்பது இதில் மிகவும் பயனுள்ள பாதியாகும்: இது ஒவ்வொரு timer-ம் கடைசியாக எப்போது இயங்கியது மற்றும் அடுத்த முறை எப்போது இயங்கும் என்பதைக் காட்டுகிறது. எனவே, ஒரு LAST மதிப்பு, அந்த timer-ன் கால இடைவெளியை விட அதிகமாக இருந்தால், அந்தப் பணி இயங்கவில்லை என்று அர்த்தம்.

ஒரு unit-ஐ restart செய்வதற்கு முன்பு, journalctl -u <unit> -n 100 --no-pager கட்டளையைப் பயன்படுத்தி அதன் journal பதிவுகளைப் படிக்கவும். ஒரு restart அந்த அறிகுறியை நீக்கிவிடும், அதன் பிறகு அதே பிரச்சனை மோசமான நேரத்தில் மீண்டும் நிகழும் வரை அதைப் பார்க்க உங்களுக்குக் காரணம் இருக்காது.

இது தடுக்கும் தோல்வி: மூன்று வாரங்களுக்கு முன்பு ஏற்பட்ட memory spike காரணமாக நின்றுபோன ஒரு monitoring agent, queue worker அல்லது backup service போன்றவற்றை இது கண்டறிய உதவுகிறது.

வாராந்திர ஆய்வு: backup பணி உண்மையில் முடிவடைந்ததா?

திட்டமிடப்பட்ட backup-க்கும், வெற்றிகரமாக முடிந்த backup-க்கும் பெரிய வித்தியாசம் உள்ளது; முழுமையான backup மட்டுமே தரவை மீட்டெடுக்க உதவும். எனவே, பணி முடிவடைந்ததை உறுதிப்படுத்தவும்.

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 பூஜ்ஜியமாக (zero) இருந்ததா என்பதையும், புதிய archive கோப்பு சமீபத்தியதாகவும், எதிர்பார்க்கப்படும் அளவில் உள்ளதா என்பதையும் பார்க்கவும். ஒரு backup கோப்பு வழக்கமான அளவில் பத்தில் ஒரு பங்காகக் குறைந்திருந்தால், அது தோல்வியுற்ற dump ஆகும். இது ஒரு கோப்பை உருவாக்கியிருக்கும் என்பதால், backup தோல்வியடைந்ததை கண்டறிவது கடினம்; ஆனால், downstream-ல் உள்ள அனைத்து செயல்பாடுகளும் சாதாரணமாகத் தெரிவதால் இதுவே மிகவும் ஆபத்தான தோல்வி நிலையாகும்.

உங்கள் script ஒரு dump-ஐ compressor-க்கு pipe செய்கிறது என்றால், script-ன் தொடக்கத்தில் set -o pipefail-ஐச் சேர்க்கவும். இதைச் சேர்க்கவில்லை எனில், pipeline-ன் exit status என்பது compressor-ன் நிலையையே குறிக்கும். compressor பிழைச் செய்தியைச் சுருக்கி (compress) வெற்றிகரமாக முடித்திருக்கும். இதனால், ஒவ்வொரு இரவும் வெறும் காலி கோப்பை உருவாக்கிவிட்டு, அந்தப் பணி வெற்றிகரமாக முடிந்ததாகவே அறிக்கை அளிக்கும்.

மாதாந்திர பணி: வேறொரு இடத்தில் backup-ஐ restore செய்தல்

பெரும்பாலானோர் தவிர்க்கும் இந்த செயல்முறைதான், உங்கள் மற்ற அனைத்து முயற்சிகளும் பயனுள்ளதா என்பதைத் தீர்மானிக்கிறது.

நேரடியாக இயங்கும் தரவுகளின் மேல் overwrite செய்யாமல், வேறொரு machine அல்லது புதிய container-ல் restore செய்யவும். பின்னர், restore செய்யப்பட்ட தரவுகளைத் திறந்து அவை சரியாக உள்ளனவா என்பதை உறுதிப்படுத்தவும். ஒரு table-ல் உள்ள rows-களை எண்ணிப் பார்க்கவும். ஒரு document-ஐத் திறந்து பார்க்கவும். restore செய்யப்பட்ட application-ல் login செய்யவும். ஒரு extraction முடிவடைந்தது என்பது archive படிக்கக்கூடிய நிலையில் உள்ளது என்பதை மட்டுமே குறிக்கும், அது தரவு சரியாக உள்ளது என்பதற்குச் சான்றல்ல.

Repository கருவிகளுக்கு எனத் தனிப்பட்ட சரிபார்ப்பு முறைகள் உள்ளன: restic check --read-data-subset=5% மற்றும் borg check --verify-data ஆகியவை index-ஐப் பார்ப்பதற்குப் பதிலாக, சேமிக்கப்பட்ட தரவுகளை நேரடியாக வாசிக்கின்றன. இவற்றை இயக்கவும், ஆனால் இவற்றை ஒரு முழுமையான தீர்வாகக் கருதாமல், ஒரு ஆரம்பகட்ட சோதனையாக (smoke test) மட்டும் பயன்படுத்தவும். Verification என்பது bytes சிதையாமல் இருப்பதை மட்டுமே உறுதி செய்யும். ஒரு restore என்பது உங்கள் application-க்குத் தேவையான தரவுகள் சரியாக உள்ளனவா என்பதை உறுதி செய்யும்.

மக்கள் அனுபவப்பூர்வமாக உணரும் இரண்டு முக்கியமான விஷயங்கள் இவை. decryption passphrase-ஐ, ஏற்கனவே key-ஐ வைத்திருக்காத ஒரு machine-ல் வைத்துச் சோதிக்கவும்; ஏனெனில் உங்களால் decrypt செய்ய முடியாத backup, ஒரு backup-ஆகக் கருதப்படாது. மேலும், restore செய்ய எவ்வளவு நேரம் ஆகிறது என்பதைக் கணக்கிடுங்கள்; அந்த கால அளவுதான் உங்கள் உண்மையான recovery நேரம். இதைச் சேவை முடக்கம் (outage) ஏற்படும்போது கண்டறிவதை விட, முன்கூட்டியே தெரிந்துகொள்வது அவசியம்.

மாதாந்திரப் பணி: எந்தச் சான்றிதழ்கள் விரைவில் காலாவதியாகின்றன?

புதுப்பித்தல் தானியங்கி முறை (renewal automation) அமைதியாகத் தோல்வியடையலாம். Certbot timer வட்டில் உள்ள கோப்பைப் புதுப்பித்தாலும், web server பழைய சான்றிதழையே நினைவகத்திலிருந்து (memory) வழங்கக்கூடும்; ஏனெனில், service-ஐ reload செய்யும் deploy hook இயங்காமல் போயிருக்கலாம். எனவே, இயங்கும் server-இடம் அது எதை வழங்குகிறது என்பதை வெளியிலிருந்து சரிபார்க்கவும்.

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)-ஐ அமைக்கிறது. ஒன்றுக்கும் மேற்பட்ட தளங்களை வழங்கும் எந்தவொரு முகவரியிலும் இது அவசியம்; இல்லையெனில், உங்களுடைய சான்றிதழுக்குப் பதிலாக default சான்றிதழே உங்களுக்கு வழங்கப்படும். Certbot ஒரு snap மூலம் நிறுவப்பட்டிருந்தால், அதன் timer பெயர் வேறாக இருக்கும்; எனவே, நீங்கள் யூகித்த unit பெயரைத் தேடாமல், அந்தச் சொல்லின் அடிப்படையில் தேடவும்.

எந்தவிதமான தானியங்கி வசதியும் இல்லாத சான்றிதழ்களை நினைவில் கொள்க: ஒரு mail server, ஒரு VPN, அல்லது ஒரு internal certificate authority. இவைதான் வார இறுதியில் காலாவதியாகும் சான்றிதழ்கள்; இவற்றை browsers மற்றும் clients எச்சரிக்கையோடு அணுகாமல், நேரடியாக நிராகரித்துவிடும்.

மாதாந்திரப் பணி: பயனர்கள், 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 உண்மையில் பயன்படுத்தும் இறுதி configuration-ஐக் காட்டும். சமீபத்திய Ubuntu பதிப்புகளில் /etc/ssh/sshd_config.d/ கோப்பகத்தில் கூடுதல் கோப்புகள் (drop-in files) உள்ளன. இவை முதன்மை கோப்பை மாற்றியமைக்கக்கூடும் என்பதால், sshd_config கோப்பை மட்டும் படிப்பது தவறான தகவலைத் தரலாம். RHEL குடும்பத்தில் நிர்வாகக் குழு wheel என்று அழைக்கப்படுகிறது, sudo அல்ல. எனவே, getent வரியை அதற்கேற்ப மாற்றவும்.

அதன்பிறகு, authorized_keys கோப்புகளை நேரடியாகப் படிக்கவும். அணுகல் என்பது கணக்கின் அடிப்படையில் அல்ல, சாவியின் (key) அடிப்படையில் வழங்கப்படுகிறது. ஆறு மாதங்களுக்கு முன்பு பணியை முடித்த ஒரு ஒப்பந்ததாரரின் சாவி இன்னும் இருந்தால், அது ஒரு செயல்பாட்டில் உள்ள login ஆகும். எந்தவொரு பயனர் பட்டியலும் இதைச் சுட்டிக்காட்டாது. சாவிகளில் கருத்து (comment) பகுதி உள்ளது. அதைப் பயன்படுத்தி, எந்த நபருக்கு உரியது என்று அடையாளம் காண முடியாத சாவிகளை நீக்கிவிடவும்.

Login வரலாற்றைப் பார்க்க, journalctl -t sshd --since "30 days ago" | grep -i accepted கட்டளையானது unit பெயருக்குப் பதிலாக syslog அடையாளங்காட்டியை (identifier) அடிப்படையாகக் கொண்டு தேடும். இது முக்கியமானது, ஏனெனில் Ubuntu 24.04-ல் SSH ஒரு socket மூலம் இயக்கப்படுகிறது. இதனால் ஒவ்வொரு இணைப்பும் ஒரு தனிப்பட்ட unit-ன் கீழ் பதியப்படும். எனவே, சாதாரண journalctl -u ssh கட்டளையைப் பயன்படுத்தினால் அந்தத் தகவல்கள் விடுபடக்கூடும்.

மாதாந்திர பராமரிப்பு: பழைய kernels மற்றும் நிறைந்த /boot

/boot என்பது பொதுவாக ஒரு VPS image-ல் சில நூறு மெகாபைட் அளவுள்ள தனி partition ஆகும். ஒவ்வொரு kernel update-ன் போதும் ஒரு புதிய image மற்றும் initramfs அதில் சேர்க்கப்படும். அது நிரம்பிவிட்டால், அடுத்த upgrade பாதியிலேயே நின்றுவிடும் மற்றும் packages சரியாக configure செய்யப்படாது. வெள்ளிக்கிழமை மாலை நேரத்தில் இத்தகைய சூழலை எதிர்கொள்வது சிக்கலானது.

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

uname -r முதலில், எப்போதும் இதைச் செய்யவும்: இது நீங்கள் தற்போது இயக்கும் kernel-ஐக் காட்டும். நீங்கள் எதை நீக்கினாலும், இந்த kernel-ஐ மட்டும் நீக்கக்கூடாது. apt autoremove என்பது Debian மற்றும் Ubuntu-வில் வழக்கமான சூழல்களைக் கையாளும்; ஏனெனில் kernels தானாகவே நிறுவப்பட்டதாகக் குறிக்கப்படும் மற்றும் தற்போதைய kernel பாதுகாக்கப்படும். கைமுறையாக நிறுவப்பட்ட kernel அல்லது /boot ஏற்கனவே நிரம்பி apt-ஐயே இயங்கவிடாமல் தடுக்கும் அரிதான சூழல்கள், 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 ஆகும், இது எதையும் எழுதாது, எனவே இயங்கும் server-ல் இதைப் பயன்படுத்துவது பாதுகாப்பானது. log rotation விதிகள் கோப்புப் பாதைகளை (paths) அடிப்படையாகக் கொண்டு செயல்படுவதால், இதை இயக்குவது அவசியம்: ஒரு upgrade-ன் போது log கோப்பின் இருப்பிடத்தை மாற்றியிருந்தால், பழைய விதி அந்த கோப்பிற்குப் பொருந்தாது. இதனால், அந்த கோப்பு வட்டு (disk) நிறையும் வரை கட்டுப்பாடின்றி வளரும்.

Journal-ன் அளவு systemd மூலம் கட்டுப்படுத்தப்படுகிறது, ஆனால் இது நீங்கள் குறிப்பிடும் ஒரு குறிப்பிட்ட எண்ணிற்குப் பதிலாக, கோப்பு முறைமையின் (filesystem) ஒரு குறிப்பிட்ட விகிதத்தில் அமைகிறது. உங்களுக்கு ஒரு குறிப்பிட்ட உச்ச வரம்பு தேவைப்பட்டால், /etc/systemd/journald.conf கோப்பில் SystemMaxUse=-ஐ அமைக்கவும், பின்னர் systemd-journald-ஐ restart செய்யவும். sudo journalctl --vacuum-time=14d உடனடியாக இடத்தைச் சுத்தம் செய்யும்; இது ஒரு கொள்கை (policy) அல்ல, ஒருமுறை மட்டுமே செயல்படும் செயல் என்பதால், இதை configuration மாற்றத்துடன் சேர்த்துச் செய்யவும்.

வெளியீடு வாரியாக: நீங்கள் தள்ளிப்போடும் reboot

வட்டில் உள்ள ஒரு மேம்படுத்தப்பட்ட kernel package என்பது இயங்கிக்கொண்டிருக்கும் kernel அல்ல. நீங்கள் reboot செய்யும் வரை, அந்த machine பழைய kernel-லையே இயக்கும். Live patching வசதி இருந்தாலும், அது சில குறிப்பிட்ட திருத்தங்களை மட்டுமே உள்ளடக்கும்.

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

அந்த flag file என்பது Debian மற்றும் Ubuntu-வில் package scripts மூலம் உருவாக்கப்படும் ஒரு மரபு. RHEL குடும்ப அமைப்புகள் இதை உருவாக்குவதில்லை; அங்கு இதற்கான விடை needs-restarting -r மூலம் கிடைக்கிறது, இது dnf-utils-லிருந்து வருகிறது. சமீபத்திய Ubuntu server images-ல் இயல்பாகவே நிறுவப்படும் needrestart, kernel-க்கு அடுத்த நிலையில் உள்ள சிக்கல்களைத் தீர்க்கிறது: வட்டில் மாற்றப்பட்ட ஒரு library-ஐ இன்னும் பயன்படுத்திக்கொண்டிருக்கும் process-களின் பட்டியலை இது காட்டுகிறது. இதனால்தான், OpenSSL-ஐ patch செய்தாலும், அதைப் பயன்படுத்தும் services-ஐ restart செய்யும் வரை அந்த மாற்றம் நடைமுறைக்கு வருவதில்லை.

Reboot-ஐத் தவிர்ப்பதற்குப் பதிலாக, அதைத் திட்டமிடுங்கள். /etc/apt/apt.conf.d/50unattended-upgrades-ல், Unattended-Upgrade::Automatic-Reboot "true"; மற்றும் Unattended-Upgrade::Automatic-Reboot-Time "03:00"; ஆகியவை நீங்கள் தேர்ந்தெடுக்கும் நேரத்தில் reboot-ஐச் செய்ய அனுமதிக்கின்றன. திட்டமிடப்பட்ட ஒரு reboot மட்டுமே, அந்த machine மீண்டும் சரியாகத் தொடங்குகிறதா என்பதைச் சோதிக்கும் ஒரே வழியாகும். ஏனெனில், தவறான fstab entry அல்லது நீங்கள் enable செய்ய மறந்த ஒரு service, boot-ன் போது மட்டுமே வெளிப்படும்; மற்ற நேரங்களில் அது தெரியாது.

வெளியீடு வாரியாக: distribution upgrade-ஐத் திட்டமிடுதல்

Ubuntu LTS வெளியீடுகள் ஐந்து ஆண்டுகளுக்கான standard support-ஐக் கொண்டுள்ளன, இடைக்கால வெளியீடுகள் ஒன்பது மாதங்களுக்கான ஆதரவைக் கொண்டுள்ளன. எனவே, உங்கள் தேர்வு பல ஆண்டுகளுக்கான upgrade பணிச்சுமையை நிர்ணயிக்கிறது. இந்தத் தேர்வு குறித்த கூடுதல் விவரங்களுக்கு server-ல் LTS மற்றும் இடைக்கால வெளியீடுகளுக்கு இடையிலான வேறுபாடு என்பதைப் பார்க்கவும்.

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

do-release-upgrade அந்த கோப்பை வாசிக்கிறது, மேலும் Prompt=lts அதை LTS-to-LTS மாற்றங்களுக்கு மட்டுமே கட்டுப்படுத்துகிறது. LTS-to-LTS பாதை பொதுவாக வெளியீட்டு நாளில் திறக்கப்படாமல், புதிய பதிப்பின் முதல் point release-ன் போதே திறக்கப்படும். எனவே, நீங்கள் ஒரு தேதியைத் திட்டமிடுவதற்குப் பதிலாக, உங்கள் machine-க்கு என்ன வழங்கப்படுகிறது என்பதைச் சரிபார்க்கவும். இந்த மாற்றத்திற்கான வழிமுறைகள் Ubuntu 24.04-லிருந்து 26.04-க்கு upgrade செய்தல் என்பதில் உள்ளன.

மூன்று மாத கால அவகாசத்தைத் திட்டமிடுங்கள். மீட்டமைத்துச் சோதிக்கப்பட்ட ஒரு snapshot-ஐ எடுங்கள், உங்கள் third-party apt repositories-ன் பட்டியலைத் தயார் செய்யுங்கள் (upgrade அவற்றை முடக்கிவிடும், ஒவ்வொன்றிற்கும் புதிய வெளியீட்டிற்கான புதிய இலக்கு தேவைப்படும்), மேலும் தொடங்குவதற்கு முன்பே rollback திட்டத்தை முடிவு செய்யுங்கள். ஆகஸ்ட் 2026 நிலவரப்படி, Ubuntu 24.04 LTS ஏப்ரல் 2029 வரை standard support-ஐக் கொண்டுள்ளது. எனவே, இது அவசரநிலை அல்ல, திட்டமிடல் மட்டுமே.

எவற்றை தானியக்கமாக்க வேண்டும், எவற்றை கைமுறையாக வைத்திருக்க வேண்டும்

நீங்கள் ஏற்கனவே எடுத்த முடிவுகளை தானியக்கமாக்குங்கள்: security updates, log rotation, certificate renewal, backup jobs. Alerting-ஐயும் தானியக்கமாக்குங்கள், ஏனெனில் நீங்கள் நினைவில் வைத்துக்கொள்ள வேண்டிய ஒரு சரிபார்ப்பு, அதிகாலை 2 மணிக்கு நடக்க வாய்ப்பில்லை. Uptime Kuma மூலம் self-hosted status monitoring போன்ற ஒரு external monitor, எந்த ஒரு on-box script-ஆலும் கண்டறிய முடியாத, server-ஐ அணுக முடியாத நிலையைத் துல்லியமாகக் கண்டறியும்.

இரண்டு விஷயங்களை மட்டும் கைமுறையாக வைத்திருங்கள்: restore test மற்றும் account audit. இவை இரண்டிற்கும் முடிவு சரியாக உள்ளதா என்பதை ஒரு நபர் தீர்மானிக்க வேண்டும். நீங்கள் terminal-ஐ விட browser-ல் machine state-ஐப் பார்க்க விரும்பினால், server நிர்வாகத்திற்கான Cockpit மற்றும் Webmin ஒப்பீடு இரண்டு பொதுவான web console-களை ஒப்பிடுகிறது.

தானியக்கமாக்கல் முறைக்கு அதன் சொந்த சரிபார்ப்பு தேவை, அதனால்தான் இந்த பட்டியலில் வாராந்திர முதல் பணியாக updater-ஐச் சரிபார்ப்பது உள்ளது. அமைதியாகத் தோல்வியடையும் தானியக்கமாக்கல், தானியக்கமாக்கல் இல்லாததை விட மோசமானது; ஏனெனில் அது தோல்வியையும், அதே நேரத்தில் கவனிக்கும் பழக்கத்தையும் ஒரே நேரத்தில் நீக்கிவிடுகிறது.

ஒரே இடத்தில் முழுமையான சரிபார்ப்புப் பட்டியல்

# 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 பராமரிப்பை எவ்வளவு அடிக்கடி செய்ய வேண்டும்?

தானாகவே மாற்றமடையும் எதற்கும் வாராந்திர பராமரிப்பு அவசியம்: update நிலை, disk மற்றும் inode கொள்ளளவு, தோல்வியடைந்த units, மற்றும் backup பணி முடிவடைந்ததா என்பதைச் சரிபார்க்கவும். மெதுவான தேய்மானத்தைக் கண்டறிய மாதந்தோறும் செய்ய வேண்டியவை: restore சோதனை, certificate காலாவதி, கணக்கு மற்றும் SSH key தணிக்கை, பழைய kernels, மற்றும் log வளர்ச்சி. ஒவ்வொரு distribution release-க்கும் ஒருமுறை version upgrade செய்யவும், தற்போதைய kernel-ல் reboot செய்யவும். ஆரோக்கியமான server-ல் வாராந்திர சோதனையை முடிக்க சில நிமிடங்கள் மட்டுமே ஆகும்; ஏதேனும் தவறு நடக்கும் வரை காத்திருக்காமல் வாராவாரம் செய்வதன் நோக்கம் இதுவே.

Backup பணி வெற்றிகரமாக முடிந்ததாகக் காட்டினாலும், ஏன் restore சோதிக்க வேண்டும்?

ஏனெனில், அந்தப் பணி அதன் சொந்த exit status-ஐ மட்டுமே தெரிவிக்கிறது; archive பயனற்றதாக இருந்தாலும் அந்த status உண்மையாக இருக்கலாம். set -o pipefail இல்லாமல் compressor-க்கு அனுப்பப்படும் dump, compressor-ன் status-ஐயே திருப்பித் தரும். எனவே, error message-ஐ மட்டும் உருவாக்கிய தோல்வியடைந்த dump கூட zero status-ஐத் தந்து சிறிய கோப்பை உருவாக்கும். வேறொரு machine-ல் restore செய்து, தரவைத் திறந்து, ஏதேனும் ஒன்றை எண்ணிச் சரிபார்க்கவும். இந்த restore செயல்முறை நேரத்தையும் கணக்கிடும், அந்த கால அளவே உங்கள் உண்மையான மீட்பு நேரம் (recovery time) ஆகும்.

ஒவ்வொரு kernel update-க்குப் பிறகும் நான் reboot செய்ய வேண்டுமா?

புதிய kernel இயங்குவதற்கு முன்பு நீங்கள் reboot செய்ய வேண்டும். Debian மற்றும் Ubuntu-வில் /var/run/reboot-required இருப்பது, ஒரு package reboot-ஐக் கோருகிறது என்பதைக் குறிக்கும், மேலும் /var/run/reboot-required.pkgs எந்த package என்று பெயரிடும். RHEL குடும்பத்தில் அக்கோப்பு இல்லை, அதற்குப் பதிலாக dnf-utils-லிருந்து வரும் needs-restarting -r அதே கேள்விக்கு விடையளிக்கும். காலவரையின்றி தள்ளிப்போடுவதற்குப் பதிலாக, /etc/apt/apt.conf.d/50unattended-upgrades-ல் தானியங்கி reboot கால இடைவெளியை அமைக்கவும். ஏனெனில், ஒரு வருடம் reboot செய்யப்படாத machine-ல் பழைய kernel இருப்பதுடன், அதன் boot path-ம் சோதிக்கப்படாமல் இருக்கும்.

இதில் எந்தெந்த சோதனைகளை நான் பாதுகாப்பாக automate செய்யலாம்?

ஏற்கனவே முடிவு செய்யப்பட்ட செயல்களை automate செய்யவும்: security updates, log rotation, certificate renewal, மற்றும் திட்டமிடப்பட்ட backups. அறிவிப்புகளையும் (notifications) automate செய்யவும், இதனால் தோல்வியடைந்த unit அல்லது நிரம்பும் disk குறித்து ஒரு மனிதர் command-ஐ இயக்காமலேயே உங்களுக்குத் தகவல் கிடைக்கும். Restore சோதனை மற்றும் key தணிக்கையை manual-ஆகவே வைத்திருக்கவும், ஏனெனில் முடிவு சரியாக உள்ளதா என்பதைத் தீர்மானிக்க ஒரு மனிதரின் பார்வை தேவை. பின்னர், automation செயல்பாட்டின் மீதே ஒரு சோதனையைச் சேர்க்கவும், ஏனெனில் அமைதியான updater தோல்வி, அனைத்தும் சரியாக நடப்பது போலவே தோன்றும்.