Rocky Linux, AlmaLinux-ல் dnf-automatic அமைப்பது எப்படி?
Rocky Linux மற்றும் AlmaLinux-ல் dnf-automatic மூலம் பாதுகாப்பு மேம்படுத்தல்களை தானியக்கமாக்குவது எப்படி? systemd timer, email alerts மற்றும் reboot கொள்கைகளை அமைக்க உதவும் வழிகாட்டி.
Rocky Linux மற்றும் AlmaLinux-ல் dnf-automatic-ன் செயல்பாடு
Rocky Linux மற்றும் AlmaLinux-ல் தானியங்கி பாதுகாப்பு மேம்படுத்தல்களைப் (unattended security updates) பெற dnf-automatic பயன்படுகிறது. இது systemd timer மூலம் இயக்கப்படும் ஒரு சிறிய நிரலாகும். இது /etc/dnf/automatic.conf கோப்பை வாசித்து, அதில் அனுமதிக்கப்பட்ட மாற்றங்களைச் செயல்படுத்துகிறது. இதை நிறுவுவதற்கு ஒரே ஒரு கட்டளை போதும். இந்த வழிகாட்டியின் மீதமுள்ள பகுதி, இந்த நிரல் உங்கள் server-ஐப் பாதுகாக்கிறதா அல்லது எந்த மாற்றமும் செய்யாமல் இருக்கிறதா என்பதைத் தீர்மானிக்கும் அமைப்புகளைப் பற்றியது.
நீங்கள் Debian அல்லது Ubuntu-விலிருந்து வந்தவர் என்றால், இது Ubuntu VPS-ல் unattended-upgrades செய்யும் அதே பணியைச் செய்கிறது. மற்ற அனைத்து வேறுபாடுகளையும் விட ஒரு வேறுபாடு முக்கியமானது: package manager-க்கு "security" என்ற சொல் எதைக் குறிக்கிறது என்பதுதான் அது. Ubuntu-வில் இது ஒரு தனி archive pocket ஆகும். RHEL குடும்பத்தில், இது வெளியிடப்பட்ட அறிவிப்புகளுடன் (advisories) இணைக்கப்பட்ட metadata ஆகும். இந்த metadata விடுபட்டிருக்கலாம் அல்லது காலாவதியாகியிருக்கலாம். advisory தரவு இல்லாத ஒரு repository-ஐ dnf-automatic-க்கு வழங்கினால், அது எதையும் நிறுவாது, ஆனால் வெற்றிகரமாகச் செயல்பட்டதாகவே காட்டும்.
இந்த வழிகாட்டி Rocky Linux 9 மற்றும் AlmaLinux 9-ஐ அடிப்படையாகக் கொண்டது. இவை ஆகஸ்ட் 2026 நிலவரப்படி DNF 4-ஐப் பயன்படுத்துகின்றன (DNF என்பது RHEL குடும்பத்தின் package manager ஆகும்). 10-வது பதிப்புகள் DNF5-க்கு மாறியுள்ளன, அங்கு பெயர்கள் மாறுபடுவதால், அவற்றுக்கென தனிப் பகுதி இறுதியில் கொடுக்கப்பட்டுள்ளது. கீழே உள்ள ஒவ்வொரு கட்டளையும் நீங்கள் உங்கள் சொந்த server-ல் இயக்க வேண்டியவை, அதனுடன் உங்களுக்குக் கிடைக்க வேண்டிய வெளியீடும் கொடுக்கப்பட்டுள்ளது.
dnf-automatic-ஐ நிறுவுதல் மற்றும் அதன் configuration கோப்பை வாசித்தல்
தானியங்கி மேம்படுத்தல்களை (automatic updates) செயல்படுத்துவது, புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற வழிகாட்டியில் உள்ள மற்ற அமைப்புகளுடன் சேர்த்து செய்யப்பட வேண்டும். இது root அல்லாத பயனர் மற்றும் firewall அமைத்த பிறகு செய்யப்பட வேண்டியது. firewall இன்னும் அமைக்கப்படவில்லை என்றால், Rocky மற்றும் AlmaLinux-ல் firewalld முன்னிருப்பாக வருகிறது. சில கட்டளைகள் மூலம் SSH மற்றும் உங்கள் தளம் இயங்கும் port-ஐத் திறந்து, reboot செய்த பிறகும் அவை செயல்படுமாறு அமைக்கலாம்.
sudo dnf install -y dnf-automatic
rpm -q dnf dnf-automatic
systemctl is-enabled dnf-automatic.timerபுதிதாக நிறுவிய பின் systemctl is-enabled கட்டளையை இயக்கினால் அது disabled என்று காட்டும், ஏனெனில் இந்த package-ஐ நிறுவுவதால் எந்தச் சேவையும் தானாகத் தொடங்காது. "dnf-automatic உள்ளது" என்று கருதப்படும் பல server-களில் ஒரு மேம்படுத்தல் கூட நடக்காமல் இருப்பதற்கு இதுவே மிக முக்கியமான காரணம்.
ஒரு குறிப்பிட்ட விருப்பத்திற்கு DNF-ன் பதிப்பு முக்கியமானது. reboot என்ற அமைப்பு DNF 4.15-ல் அறிமுகப்படுத்தப்பட்டது. Red Hat நிறுவனம் இதை நவம்பர் 2023-ல் RHBA-2023:6645 என்ற ஆலோசனையின் மூலம் dnf-4.14.0-6.el9-க்கு backport செய்தது. Rocky 9 மற்றும் AlmaLinux 9 இந்த package-ஐ மீண்டும் உருவாக்குவதால், தற்போதைய server-களில் இது இருக்கும்; ஆனால் 2023-க்குப் பிறகு புதுப்பிக்கப்படாத server-களில் இது இருக்காது.
இதன் configuration கோப்பு /etc/dnf/automatic.conf ஆகும். இந்த build-ல் உள்ள அனைத்து விருப்பங்களும், அவற்றின் முன்னிருப்பு மதிப்புகளும் (defaults) இந்த கோப்பில் comment செய்யப்பட்ட நிலையில் பட்டியலிடப்பட்டுள்ளன. நீங்கள் மாற்றங்களைச் செய்வதற்கு முன் ஒருமுறை இந்தக் கோப்பை வாசிக்கவும், ஏனெனில் உங்கள் பதிப்பிற்கு எது உண்மையானது என்பதை இந்தக் கோப்பே உறுதிப்படுத்தும்.
செயல்பாட்டைத் தீர்மானிக்கும் இரண்டு சுவிட்சுகள்
download_updates மற்றும் apply_updates ஆகியவை [commands] பிரிவில் செயல்பாட்டைத் தீர்மானிக்கின்றன. EL9-ல் (Rocky 9 மற்றும் AlmaLinux 9 ஆகியவற்றின் பொதுவான அடித்தளமான enterprise Linux 9) இவை இரண்டும் இயல்பாகவே no நிலையில் இருக்கும். எனவே, நீங்கள் மாற்றங்கள் செய்யாமல் dnf-automatic-ஐ enable செய்தால், அது என்னென்ன அப்டேட்கள் உள்ளன என்பதை மட்டுமே உங்களுக்குத் தெரிவிக்கும்.
- இரண்டும்
no:dnf-automaticகிடைக்கக்கூடிய அப்டேட்களைப் பட்டியலிடும், ஆனால் சர்வரில் எந்த மாற்றத்தையும் செய்யாது. download_updates = yesமற்றும்apply_updates = no: பேக்கேஜ்கள் DNF cache-க்கு பதிவிறக்கம் செய்யப்படும். இதனால் நிறுவல் (install) விரைவாக நடக்கும், நெட்வொர்க் தேவையில்லை, ஆனால் அந்த நேரத்தில் எந்த மாற்றமும் நிகழாது.- இரண்டும்
yesமற்றும்upgrade_type = default: பாதுகாப்பு அப்டேட்கள் மட்டுமின்றி, கிடைக்கக்கூடிய அனைத்து அப்டேட்களும் நிறுவப்படும். - இரண்டும்
yesமற்றும்upgrade_type = security: பாதுகாப்பு ஆலோசனைகளில் (security advisory) குறிப்பிடப்பட்டுள்ள பேக்கேஜ்கள் மட்டுமே நிறுவப்படும்.
பொது இணையத்தில் இயங்கும் VPS-க்கு இது ஒரு நியாயமான தொடக்கநிலை அமைப்பாகும்:
[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
random_sleep = 0
network_online_timeout = 60
reboot = nevernetwork_online_timeout என்பது நெட்வொர்க் கிடைக்கும் வரை இந்த ரன் (run) எவ்வளவு நொடிகள் காத்திருக்க வேண்டும் என்பதைக் குறிக்கிறது; இது பூட் ஆன உடனே இயங்கும் சர்வர்களுக்கு முக்கியமானது. random_sleep என்பது பல மெஷின்களில் சுமையைப் பகிர்ந்தளிக்கப் பயன்படுத்தப்பட்ட பழைய முறையாகும், இப்போது timer அந்த வேலையைச் செய்கிறது. ஷிப் செய்யப்பட்ட (shipped) service என்னென்ன flags-ஐப் பயன்படுத்துகிறது என்பதைப் பார்க்க systemctl cat dnf-automatic.service கட்டளையை இயக்கவும்.
காலை 06:00 மணி வரை காத்திருக்காமல், கோப்பு நீங்கள் நினைத்தபடி செயல்படுகிறதா என்பதைச் சரிபார்க்கவும்:
sudo systemctl start dnf-automatic.service
sudo journalctl -u dnf-automatic.service -n 50 --no-pagerஇந்த ரன் எதைக் கருத்தில் கொண்டது மற்றும் என்ன செய்தது என்பதை journal காட்டுகிறது. நீங்கள் கட்டளை வரியிலிருந்தே ஒரு குறிப்பிட்ட செயல்பாட்டை வற்புறுத்தலாம் (force), இது அந்த ஒரு ரன்னிற்கு மட்டும் கோப்பில் உள்ள அமைப்புகளை மீறிச் செயல்படும்:
sudo dnf-automatic --downloadupdates --no-installupdatesRocky மற்றும் Alma-வில் upgrade_type = security என்பதன் உண்மையான பொருள்
DNF என்பது பதிப்பு எண்களை (version numbers) ஒப்பிடுவதன் மூலம் ஒரு அப்டேட் பாதுகாப்பு சார்ந்ததா என்பதைத் தீர்மானிப்பதில்லை. இது errata மெட்டாடேட்டாவை வாசிக்கிறது: இது களஞ்சியத்திற்குள் (repository) வெளியிடப்படும் updateinfo.xml என்ற கோப்பாகும்; இதில் ஒவ்வொரு ஆலோசனையும் (advisory) அதைச் சரிசெய்யும் தொகுப்புகளைப் (packages) பட்டியலிடுகிறது. AlmaLinux இவற்றை ALSA ஆலோசனைகளாக வெளியிடுகிறது, Rocky இவற்றை RLSA என வெளியிடுகிறது. upgrade_type = security அந்த மெட்டாடேட்டாவிலிருந்து ஒரு வடிகட்டியை (filter) உருவாக்கி, அது பொருந்துகின்ற தொகுப்புகளை மட்டுமே மேம்படுத்துகிறது.
இதன் விளைவாக இரண்டு விஷயங்கள் நடக்கின்றன, இவை பயனர்களுக்கு ஆச்சரியத்தை அளிக்கலாம்.
முதலாவதாக, மெட்டாடேட்டா இல்லை என்றால் அப்டேட்களும் இல்லை. களஞ்சியத்தில் updateinfo.xml இல்லை என்றால், வடிகட்டி எதையும் கண்டறியாது மற்றும் செயல்முறை ஜர்னலில் இந்த வரியுடன் முடிவடையும்:
No security updates needed, but 3 updates availableசர்வர் பேட்ச் செய்யப்படாது, ஆனால் எந்தத் தோல்வியும் பதிவாகாது. நீங்களே சரிபார்க்கவும்:
dnf updateinfo list --security
dnf check-updatednf check-update தொகுப்புகளைப் பட்டியலிட்டு, அதே சமயம் dnf updateinfo list --security எதையும் காட்டவில்லை என்றால், நிலுவையில் உள்ள எதற்கும் ஆலோசனை இல்லை அல்லது களஞ்சியத்தில் வாசிப்பதற்கு ஆலோசனைத் தரவு இல்லை என்று பொருள். Rocky மற்றும் AlmaLinux ஆகிய இரண்டும் இதை வெளியிடுவதால், அந்த இரண்டிலும் பட்டியல் காலியாக இருப்பது உண்மையான நிலையைத்தான் குறிக்கிறது. CentOS Stream இதை வெளியிடுவதே இல்லை.
இரண்டாவதாக, பாதுகாப்பு முறை (security mode) என்பது மிகக்குறைந்த மாற்றங்களை மட்டும் செய்யும் முறை அல்ல. dnf-automatic பாதுகாப்பு வடிகட்டியைச் சேர்த்துவிட்டு, சாதாரண மேம்படுத்தல் பாதையிலேயே இயங்குகிறது. எனவே, ஆலோசனையில் குறிப்பிடப்பட்டுள்ள ஒரு தொகுப்பு களஞ்சியத்தில் உள்ள மிகப்புதிய பதிப்பிற்கு மேம்படுத்தப்படும், அதனுடன் அதன் சார்புகளும் (dependencies) மேம்படுத்தப்படும். ஆலோசனையைச் சரிசெய்யும் மிக ஆரம்பக்கட்ட பதிப்பிற்கு மட்டும் மாறுவது என்பது dnf upgrade-minimal --security மூலம் கைமுறையாகச் செய்ய வேண்டிய ஒன்று. dnf-automatic-ல் அதற்கான அமைப்பு இல்லை.
Rocky-க்கு மேலும் ஒரு எச்சரிக்கை உண்டு. Rocky தனது errata-வை Red Hat தரவுகளிலிருந்து தனது சொந்த pipeline மூலம் உருவாக்குகிறது, அந்த pipeline பின்தங்கியிருக்கலாம். செப்டம்பர் 2025-ல், Rocky 9 BaseOS updateinfo.xml டிசம்பர் 2024-க்குப் பிறகு மாறவில்லை என்று பயனர்கள் தெரிவித்தனர், இதனால் --security சமீபத்திய ஆலோசனைகளைத் தவறவிட்டது; இதை Rocky பணியாளர்கள் ஒரு அறியப்பட்ட சிக்கலாக உறுதிப்படுத்தினர். நீங்கள் upgrade_type = security-ஐ நம்பியிருந்தால், அவ்வப்போது ஆலோசனைப் பட்டியலை சமீபத்திய RLSA அறிவிப்புகளுடன் ஒப்பிட்டுப் பாருங்கள். மாற்றுக் கட்டுப்பாட்டை (change control) விட பாதுகாப்பு மிக முக்கியம் என்று கருதும் சர்வர்களில், upgrade_type = default-ஐ நீங்கள் விரும்பும் கால அட்டவணையில் பயன்படுத்துவதே பாதுகாப்பானது.
இதை இயக்கும் systemd timer
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timerlist-timers கட்டளை ஒரு வரிசையை அச்சிட வேண்டும், அதில் NEXT நேரம் சுமார் ஒரு நாள் இடைவெளியில் இருக்க வேண்டும். அட்டவணை காலியாக இருந்தால், timer செயல்படுத்தப்படவில்லை என்று பொருள், எனவே எதுவும் இயங்காது.
வழங்கப்பட்ட timer *-*-* 6:00 நேரத்தில் RandomizedDelaySec=60m மற்றும் Persistent=true ஆகியவற்றுடன் இயங்குகிறது. சீரற்ற தாமதம் (random delay) ஒரு மணி நேரத்திற்குள் பணிகளைப் பரப்புகிறது, இதனால் அனைத்து server-களும் ஒரே நொடியில் mirror-ஐ அணுகாது. Persistent=true என்பது, 06:00 மணிக்கு அணைக்கப்பட்டிருந்த ஒரு machine, boot ஆனவுடன் அந்தத் தவறிய பணியை உடனடியாக இயக்கும் என்பதைக் குறிக்கிறது; அந்த நாளைத் தவிர்க்காது.
ஒரு drop-in கோப்பைப் பயன்படுத்தி அட்டவணையை மாற்றவும். வழங்கப்பட்ட unit கோப்பைத் திருத்த வேண்டாம், ஏனெனில் package upgrade செய்யும்போது /usr/lib/systemd/system-ன் கீழ் உள்ள கோப்புகள் மாற்றப்படும்.
sudo systemctl edit dnf-automatic.timer[Timer]
OnCalendar=
OnCalendar=*-*-* 03:30
RandomizedDelaySec=30mகாலியான OnCalendar= வரிசை அவசியம். OnCalendar மதிப்புகள் ஒன்றிணையும் (accumulate), எனவே அந்த reset இல்லையென்றால், நீங்கள் 06:00 நேரத்தை வைத்திருப்பதோடு கூடுதலாக இன்னொன்றையும் சேர்ப்பீர்கள், இதனால் அந்தப் பணி ஒரு நாளைக்கு இரண்டு முறை இயங்கும். systemctl list-timers dnf-automatic.timer மூலம் முடிவை உறுதிசெய்து, NEXT நெடுவரிசையைப் பார்க்கவும். நீங்கள் அட்டவணைப்படுத்தும் மற்ற அனைத்துக்கும் இதே drop-in விதிகள் பொருந்தும், இது systemd service மற்றும் timer units எழுதுதல் பகுதியில் விளக்கப்பட்டுள்ளது.
இப்போது ஒரு சிக்கல். இந்த package மேலும் மூன்று timer-களை வழங்குகிறது: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer மற்றும் dnf-automatic-install.timer. ஒவ்வொன்றும் அதே நிரலை command-line flags-உடன் தொடங்குகின்றன, மேலும் அந்த flags உங்கள் config கோப்பில் உள்ள download_updates மற்றும் apply_updates ஆகியவற்றை மீறிச் செயல்படும் (override). dnf-automatic.timer-க்கு அருகில் அவற்றில் ஒன்றைச் செயல்படுத்தினால், அந்தப் பணி இரண்டு வெவ்வேறு செயல்பாடுகளுடன் இரண்டு முறை இயங்கும், இது உங்கள் config கோப்பு புறக்கணிக்கப்படுவது போலத் தோன்றும். ஒரு timer-ஐ மட்டும் செயல்படுத்திச் சரிபார்க்கவும்:
systemctl list-unit-files 'dnf-automatic*'ஒரு மென்பொருள் எப்போது நிறுவப்பட்டது என்பதை நான் எப்படி அறிவது?
emit_via, [emitters] பிரிவில் அறிக்கையிடலைக் கட்டுப்படுத்துகிறது. systemd-ன் கீழ், stdio emitter தகவல்களை journal-க்கு எழுதுகிறது. இதற்கு வேறு எந்த மென்பொருளும் தேவையில்லை என்பதால், இதுவே நம்பகமான விருப்பமாகும்:
sudo journalctl -u dnf-automatic.service --since -7d --no-pagermotd emitter அறிக்கையை /etc/motd கோப்பில் எழுதுகிறது மற்றும் அக்கோப்பின் முந்தைய உள்ளடக்கங்களை நீக்கிவிட்டு புதியவற்றைச் சேர்க்கிறது. நீங்கள் அக்கோப்பில் ஏதேனும் login banner வைத்திருந்தால், இந்த emitter-ஐப் பயன்படுத்த வேண்டாம்.
email emitter, email_host-ல் உள்ள email_port-க்கு ஒரு SMTP (simple mail transfer protocol) இணைப்பைத் திறக்கிறது. இவை முன்னிருப்பாக (default) localhost மற்றும் 25 என இருக்கும். புதிய VPS-ல் அந்த port-களில் எந்தச் சேவையும் இயங்காது என்பதால், இணைப்பு மறுக்கப்படும் மற்றும் மின்னஞ்சல் அனுப்பப்படாது. நீங்கள் இதைப் பயன்படுத்துவதற்கு முன்பு ss -lnt | grep ':25'-ஐ இயக்கவும். வெளியீடு கிடைக்கவில்லை எனில், relay-only Postfix-ஐ அமைக்கவும். மின்னஞ்சல் சரியாகச் செயல்படும்போது, அதன் தலைப்பு Updates applied on 'web01'. என்று இருக்கும், மேலும் system_name-லிருந்து பெயர் எடுத்துக்கொள்ளப்படும்.
பிற தேவைகளுக்கு, command emitter அறிக்கையை உங்கள் நிரலுக்கு standard input வழியாக வழங்குகிறது:
[emitters]
emit_via = stdio, command
system_name = web01.example.com
send_error_messages = yes
[command]
command_format = /usr/local/bin/notify-ops
stdin_format = {body}send_error_messages முன்னிருப்பாக no என்று இருக்கும், அதாவது ஒரு செயல்பாடு தோல்வியுற்றால் அது எதையும் தெரிவிக்காது. இதைச் செயல்படுத்தவும். வெற்றிகளை மட்டும் தெரிவிக்கும் ஒரு patching system, எந்த அமைப்பும் இல்லாததை விட மோசமானது; ஏனெனில், அமைதியாக இருப்பது எல்லாம் சரியாக இருப்பதாக ஒரு தவறான பிம்பத்தை உருவாக்கும்.
dnf-automatic உங்கள் services-ஐ restart செய்வதில்லை
ஒரு package-ஐ நிறுவுவது வட்டில் உள்ள கோப்புகளை மாற்றும். ஏற்கனவே இயங்கிக்கொண்டிருக்கும் ஒரு process, பழைய code-ஐயே நினைவகத்தில் (memory) வைத்திருக்கும். எனவே, கடந்த மாதம் தொடங்கப்பட்ட ஒரு daemon-க்கு, புதிதாகப் பொருத்தப்பட்ட library எந்த மாற்றத்தையும் ஏற்படுத்தாது. நிறுவப்பட்ட கோப்பிற்கும், நடைமுறையில் இயங்கும் கோப்பிற்கும் இடையே உள்ள இந்த இடைவெளிதான், unattended patching-க்கு வெறும் install policy மட்டும் போதாது, ஒரு restart policy-யும் தேவை என்பதை உணர்த்துகிறது.
sudo dnf install -y dnf-plugins-core
dnf needs-restarting -s
dnf needs-restarting -r-s, கோப்புகள் மாற்றப்பட்ட பிறகு, அவை தொடங்கப்பட்ட systemd services-ன் பட்டியலை வழங்குகிறது. -r ஒரு கேள்விக்கு விடையளித்து, பின்வரும் இரண்டு தொகுதிகளில் ஒன்றை வெளியிடும்:
Core libraries or services have been updated since boot-up:
* kernel
Reboot is required to fully utilize these updates.No core libraries or services have been updated since boot-up.
Reboot should not be necessary.-r என்பது ஒரு ஆழமான பகுப்பாய்வு அல்ல. இது ஒரு குறிப்பிட்ட package பட்டியலை மட்டுமே சரிபார்க்கிறது: kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon மற்றும் microcode_ctl. இவற்றில் ஏதேனும் ஒன்று கடைசி boot-க்கு பிறகு நிறுவப்பட்டிருந்தால், உங்களுக்கு முதல் பதில் கிடைக்கும். சர்வரில் உள்ள வேறு ஏதேனும் ஒரு மாற்றத்திற்கு reboot தேவைப்பட்டால், /etc/dnf/plugins/needs-restarting.d/-ன் கீழ் .conf-ல் முடியும் ஒரு கோப்பில் உங்கள் சொந்த package பெயர்களைச் சேர்க்கவும்.
scripts-க்கான ஒரு எச்சரிக்கை: dnf needs-restarting -r, reboot தேவைப்படும்போதும், command தோல்வியடையும்போதும் பூஜ்ஜியமற்ற (non-zero) exit status-ஐயே தருகிறது. எனவே, வெறும் exit status-ஐ வைத்து இரண்டையும் வேறுபடுத்த முடியாது. வெளியீட்டு உரையை (output text) வாசிக்கவும்.
ஒரு service-ஐ restart செய்வது சிறிய மற்றும் பெரும்பாலும் சரியான நடவடிக்கையாகும். SSH daemon-ஐ restart செய்யும்போது, ஏற்கனவே திறந்திருக்கும் இரண்டாவது SSH session-ஐப் பயன்படுத்தவும். அப்போதுதான் தவறான configuration காரணமாக நீங்கள் வெளியேற்றப்பட மாட்டீர்கள். புதிய kernel-ஐப் பொறுத்தவரை, reboot செய்வது மட்டுமே தீர்வாகும், ஏனெனில் இயங்கிக்கொண்டிருக்கும் kernel-ஐ அப்படியே மாற்ற முடியாது. ஒரு குறிப்பிட்ட நாளில் வந்த updates-ஐ இந்த இரண்டு வகைகளாகப் பிரிக்க விரும்பினால், எந்த updates-க்கு reboot தேவை மற்றும் எதற்கு service restart மட்டும் போதும் என்ற கட்டுரை ஒவ்வொரு package-ஆகப் பகுப்பாய்வு செய்து உதவும்.
Containers ஒரு தனிப்பட்ட வழக்கு. ஏனெனில், dnf-automatic என்பது host-ன் packages-ஐ மட்டுமே patch செய்யும்; image-க்குள் இருக்கும் userland-ஐ அது தொடாது. எனவே, Rocky Linux அல்லது AlmaLinux-ல் Docker Engine இயக்கும் ஒரு சர்வரில், ஒரு திருத்தம் (fix) நடைமுறைக்கு வர வேண்டுமானால், அதன் images மீண்டும் pull செய்யப்பட்டு, containers மீண்டும் உருவாக்கப்பட வேண்டும்.
Box தானாகவே reboot ஆக வேண்டுமா?
[commands]
reboot = when-needed
reboot_command = shutdown -r +5 'Rebooting after applying package updates'reboot = never என்பது இயல்புநிலை அமைப்பாகும். when-changed ஏதேனும் ஒரு update செய்யப்பட்ட பிறகு reboot செய்யும். when-needed என்பது needs-restarting -r-க்கு பின்னால் உள்ள சோதனையில் ஒரு core package மாற்றப்பட்டது என்று கண்டறியப்பட்டால் மட்டுமே reboot செய்யும்; இதுவே பெரும்பாலான single-server பயனர்கள் விரும்புவதாகும், இதனுடன் அவர்கள் தேர்ந்தெடுத்த timer window-வையும் இணைத்துக்கொள்ளலாம். இயல்புநிலையான reboot_command, உள்நுழைந்திருக்கும் பயனர்களுக்கு shutdown மூலம் ஐந்து நிமிட எச்சரிக்கையை வழங்கும், இதை நீங்கள் நீட்டிக்கவும் முடியும்.
இதைச் செயல்படுத்துவதற்கு முன் இரண்டு விஷயங்களை உறுதிப்படுத்திக் கொள்ளுங்கள். நீங்கள் சார்ந்திருக்கும் ஒவ்வொரு service-ம் boot-ன் போது தானாகவே தொடங்க வேண்டும், இதுவே கைமுறையாகத் தொடங்கப்பட்ட Docker Compose stack-களில் பொதுவாக விடுபடும் விஷயமாகும். மேலும், உங்கள் provider-விடமிருந்து console அல்லது rescue access வசதி இருக்க வேண்டும், ஏனெனில் boot ஆகாத kernel-ஐ SSH மூலம் சரிசெய்ய முடியாது. இந்த இரண்டில் எது இல்லையென்றாலும், reboot = never-ஐ அப்படியே வைத்துக்கொண்டு, journal-ஐப் படித்த பிறகு நீங்களே reboot செய்யுங்கள்.
Rocky, AlmaLinux மற்றும் CentOS Stream: இவற்றின் வேறுபாடுகள்
Rocky 9 மற்றும் AlmaLinux 9 ஆகியவற்றில் மேலே கூறப்பட்ட அனைத்தும், config path மற்றும் unit பெயர்கள் உட்பட, அப்படியே பொருந்தும். இவை இரண்டுமே errata-வை வெளியிடுவதால், upgrade_type = security-ல் வடிகட்டுவதற்குத் தேவையான தரவுகள் உள்ளன. முன்னதாகக் குறிப்பிட்ட Rocky errata-வின் காலாவதியான தன்மை மட்டுமே இவற்றின் அன்றாட செயல்பாட்டில் உள்ள ஒரு சில வேறுபாடுகளில் ஒன்றாகும். எனவே, server-ஐ இன்னும் உருவாக்கவில்லை என்றால், இவ்விரண்டையும் பிரிக்கும் compatibility promise மற்றும் பழைய CPU ஆதரவு ஆகியவற்றைக் கருத்தில் கொண்டு முடிவெடுக்கவும்.
CentOS Stream ஒரு விதிவிலக்கு, இது ஒரு முக்கியமான வேறுபாடு. Stream repositories-ல் updateinfo.xml இருப்பதில்லை, எனவே security filter எதனுடனும் பொருந்தாது மற்றும் ஒவ்வொரு முறையும் No security updates needed என்றே காட்டும். Stream-ல் upgrade_type = default-ஐப் பயன்படுத்தவும்; அனைத்து update-களையும் ஏற்றுக்கொள்வதைத் தவிர வேறு வழியில்லை. மேலும், RHEL-ஐ விட Stream முன்னிலையில் இருப்பதால், Rocky அல்லது AlmaLinux-ல் உள்ள அதே setting-ஐ விட, Stream-ல் அது அடிக்கடி மாறக்கூடும். இந்த வேறுபாடு packaging-ல் ஏற்பட்ட தவறு அல்ல; 2020-ல் Red Hat எடுத்த முடிவின் விளைவு இது. CentOS-ஐ RHEL-ன் rolling preview-ஆக மாற்றிய அந்த முடிவே, Rocky Linux மற்றும் AlmaLinux உருவாவதற்குக் காரணமாக அமைந்தது.
Rocky 10 மற்றும் AlmaLinux 10 ஆகியவை DNF5-க்கு மாறியுள்ளன, இது பெயர்களை மாற்றுகிறது. அதிகாரப்பூர்வ DNF5 ஆவணங்களின்படி, timer என்பது dnf5-automatic.timer ஆகும். இதில் வழங்கப்பட்ட defaults /usr/share/dnf5/dnf5-plugins/automatic.conf-லும், உங்கள் மாற்றங்கள் /etc/dnf/automatic.conf-லும் இருக்கும். இது download_updates-ஐ 'no' என்பதற்குப் பதிலாக 'yes' என இயல்பாகக் கொள்கிறது, மேலும் upgrade_type-ஆக distro-sync-ஐச் சேர்க்கிறது. advisory query என்பது dnf advisory list ஆகும், இதில் updateinfo ஒரு alias-ஆகத் தக்கவைக்கப்பட்டுள்ளது. பதிப்பு 9-க்காக எழுதப்பட்ட வழிகாட்டிகளிலிருந்து package அல்லது unit பெயர்களை நகலெடுக்கும் முன், உங்கள் release-ல் உண்மையில் என்ன நிறுவப்பட்டுள்ளது என்பதை உறுதிப்படுத்தவும்:
dnf list --available '*automatic*'
systemctl list-unit-files '*automatic*'இந்தத் தலைப்பில் வெளியிடப்பட்ட பல வழிகாட்டிகள் Rocky 8-ஐ மட்டுமே உள்ளடக்கியுள்ளன. அவை எழுதப்பட்ட காலத்திலிருந்து option தொகுப்புகள் வளர்ந்துவிட்டன, எனவே பழைய கட்டுரையை நம்புவதை விட, உங்கள் server-ல் உள்ள commented file-ஐச் சரிபார்க்கவும்.
தோல்வி முறைகள் மற்றும் நீங்கள் காணும் செய்திகள்
எதுவும் இயங்கவில்லை. systemctl list-timers dnf-automatic.timer ஒரு காலி அட்டவணையை அச்சிடுகிறது மற்றும் systemctl is-enabled dnf-automatic.timer ஆனது disabled என்று அச்சிடுகிறது. தொகுப்பு நிறுவப்பட்டது, ஆனால் டைமர் நிறுவப்படவில்லை.
பணி இயங்குகிறது ஆனால் எதையும் நிறுவவில்லை. ஜர்னலில் No security updates needed, but 3 updates available உள்ளது. பாதுகாப்பு வடிகட்டி எதையும் பொருத்தவில்லை; ஏனெனில் நிலுவையில் உள்ள எதற்கும் ஆலோசனை (advisory) இல்லை அல்லது களஞ்சியத்தில் (repository) ஆலோசனை தரவுகள் இல்லை.
ஒரு அமைப்பு புறக்கணிக்கப்பட்டதாகத் தெரிகிறது. DNF ஆனது automatic.conf-ல் உள்ள தெரியாத விருப்பத்தை பிழைத்திருத்த (debug) நிலையில் பதிவு செய்கிறது, பின்னர் இயல்புநிலையைப் பயன்படுத்துகிறது. எனவே, தவறாக எழுதப்பட்ட விசை எதையும் மாற்றாது மற்றும் யாருக்கும் எச்சரிக்கையும் தராது. apply_update = yes என்று எழுதினால், apply_updates ஆனது no-லேயே இருக்கும்; இதனால் கணினி எப்போதும் பதிவிறக்கம் செய்யும், ஆனால் எதையும் நிறுவாது. எந்தவொரு திருத்தத்திற்குப் பிறகும், sudo systemctl start dnf-automatic.service-ஐ இயக்கி, கோப்பை நம்புவதற்குப் பதிலாக ஜர்னலைப் படிக்கவும்.
பணி ஒரு நாளைக்கு இரண்டு முறை இயங்குகிறது. இரண்டு டைமர்கள் இயக்கப்பட்டுள்ளன. systemctl list-unit-files 'dnf-automatic*' எவை என்பதைத் தெரிவிக்கும், மேலும் கூடுதல் டைமர்கள் உங்கள் கட்டமைப்பு கோப்பை விட முன்னுரிமை பெறும் கொடிகளை (flags) அனுப்பும்.
மின்னஞ்சல் வரவில்லை. email வெளியீட்டிற்காக போர்ட் 25-ல் எதுவும் கேட்கவில்லை (listening), அல்லது send_error_messages இன்னும் no என்றே உள்ளது, மேலும் பிழையைத் தவிர வேறு எதையும் தெரிவிக்க வேண்டிய அவசியமில்லை.
திருத்தப்பட்ட சேவை இன்னும் பழைய பதிப்பையே காட்டுகிறது. வட்டில் உள்ள கோப்பு புதியது, ஆனால் நினைவகத்தில் உள்ள செயல்முறை பழையது. dnf needs-restarting -s மறுதொடக்கம் செய்ய வேண்டிய சேவைகளின் பெயர்களைக் குறிப்பிடுகிறது.
FAQ
Rocky Linux-ல் dnf-automatic பாதுகாப்பு மேம்படுத்தல்களை (security updates) மட்டும் நிறுவுமா?
/etc/dnf/automatic.conf கோப்பில் upgrade_type = security அமைப்பைச் சரியாக அமைத்தால் மட்டுமே இது நடக்கும். மேலும், உங்கள் repositories errata metadata-வை வெளியிடுகிறதா என்பதைப் பொறுத்தது. Rocky Linux மற்றும் AlmaLinux ஆகிய இரண்டும் இதை வெளியிடுவதால், இந்த filter-ஆல் advisories-ஐ ஒப்பிட்டுப் பார்க்க முடியும். இயல்பாக (default) இது upgrade_type = default என இருக்கும்; இது apply_updates = yes நிகழ்ந்தவுடன் கிடைக்கக்கூடிய அனைத்து மேம்படுத்தல்களையும் நிறுவிவிடும்.
"No security updates needed, but 3 updates available" என்று dnf-automatic ஏன் காட்டுகிறது?
Repository-ல் உள்ள updateinfo.xml-ஐப் படிப்பதன் மூலம் எது பாதுகாப்பு மேம்படுத்தல் என்பதை DNF தீர்மானிக்கிறது; ஒவ்வொரு advisory-யும் எந்தெந்த packages-ஐச் சரிசெய்கிறது என்பதைப் பட்டியலிடும். இந்த metadata விடுபட்டிருந்தாலோ அல்லது பழையதாக இருந்தாலோ, பாதுகாப்பு filter எதையும் கண்டறியாது, ஆனால் சாதாரண மேம்படுத்தல்கள் நிலுவையில் இருக்கும். இது CentOS Stream-ல் சாதாரணமாக நடக்கும், ஏனெனில் அது errata-வை வெளியிடுவதில்லை. Rocky அல்லது AlmaLinux-ல், dnf updateinfo list --security மற்றும் dnf check-update ஆகியவற்றை ஒப்பிட்டு, உங்கள் metadata தற்போதைய நிலையில் உள்ளதா என்பதைச் சரிபார்க்கவும்.
Kernel மேம்படுத்தலுக்குப் பிறகு dnf-automatic server-ஐ reboot செய்யுமா?
நீங்கள் கட்டளையிட்டால் மட்டுமே செய்யும். reboot விருப்பம் இயல்பாக never என்று இருக்கும். reboot = when-needed என்று அமைத்தால், dnf needs-restarting -r-க்கு பின்னால் உள்ள சோதனையில் kernel அல்லது glibc போன்ற core package-கள் மாற்றப்பட்டிருப்பது கண்டறியப்பட்டால் மட்டுமே reboot நடக்கும். reboot = when-changed எந்த மேம்படுத்தல் நடந்தாலும் reboot செய்யும். இவை இரண்டுமே reboot_command-ஐப் பயன்படுத்துகின்றன; இது இயல்பாக shutdown -r +5 என இருக்கும் மற்றும் உள்நுழைந்த பயனர்களுக்கு எச்சரிக்கை செய்தியை அனுப்பும்.
dnf-automatic இயங்கும் நேரத்தை நான் எப்படி மாற்றுவது?
sudo systemctl edit dnf-automatic.timer-ஐ இயக்கி, ஒரு [Timer] பகுதியைச் சேர்க்கவும். அதில் முதலில் ஒரு காலியான OnCalendar= வரியைச் சேர்த்து, பின் உங்கள் நேர அட்டவணையை இடவும் (உதாரணமாக: OnCalendar=*-*-* 03:30). காலியான வரி அவசியம், ஏனெனில் OnCalendar அமைப்புகள் ஒன்றன் பின் ஒன்றாகச் சேரும்; அதைத் தவிர்க்காவிட்டால், ஏற்கனவே உள்ள 06:00 நேரத்துடன் புதிய நேரமும் சேர்ந்து இரண்டு முறை இயங்கும். systemctl list-timers dnf-automatic.timer மூலம் சரிபார்த்து, NEXT நெடுவரிசையைப் பார்க்கவும்.
தானாகவே patch செய்துகொள்ளும் server-ஐ நான் இன்னும் கண்காணிக்க வேண்டுமா?
ஆம். dnf-automatic packages-ஐ மட்டுமே நிறுவும், அதோடு நின்றுவிடும். அது daemons-ஐ மறுதொடக்கம் (restart) செய்யாது. மேலும், emit_via-ல் நீங்கள் படிக்கும் ஒரு emitter-ஐக் குறிப்பிடவில்லை என்றால், அது எதையும் உங்களுக்குத் தெரிவிக்காது. குறைந்தபட்சம் emit_via-ஐ stdio என அமைக்கவும், தோல்விகள் குறித்துத் தெரியப்படுத்த send_error_messages-ஐ இயக்கவும், patch செய்த பிறகு பழைய code-ல் இயங்கும் services-ஐக் கண்டறிய dnf needs-restarting -s-ஐ இயக்கவும்.