Rocky Linux-ல் dnf-automatic அமைப்பது எப்படி?
Rocky Linux மற்றும் AlmaLinux-ல் dnf-automatic மூலம் பாதுகாப்பு மேம்படுத்தல்களை தானியக்கமாக்குங்கள். systemd timer, மின்னஞ்சல் எச்சரிக்கைகள் மற்றும் 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 குடும்பத்தில், இது வெளியிடப்பட்ட அறிவிப்புகளுடன் இணைக்கப்பட்ட metadata ஆகும். சில நேரங்களில் இந்த metadata விடுபட்டிருக்கலாம் அல்லது பழையதாக இருக்கலாம். அறிவிப்புத் தரவு (advisory data) இல்லாத ஒரு repository-ஐ dnf-automatic-க்குக் காட்டினால், அது எதையும் நிறுவமலே வெற்றிகரமாக முடிந்துவிட்டதாகத் தெரிவிக்கும்.
இந்த வழிகாட்டி ஆகஸ்ட் 2026 நிலவரப்படி, DNF 4-ஐப் பயன்படுத்தும் Rocky Linux 9 மற்றும் AlmaLinux 9-ஐ அடிப்படையாகக் கொண்டது (DNF என்பது RHEL குடும்பத்தின் package manager ஆகும்). 10-வது பதிப்புகள் DNF5-க்கு மாறியுள்ளன, அங்கு பெயர்கள் மாறுபடுவதால், அதற்கென தனிப் பகுதி இறுதியில் கொடுக்கப்பட்டுள்ளது. கீழே உள்ள ஒவ்வொரு கட்டளையையும் உங்கள் server-ல் நீங்கள் இயக்க வேண்டும்; அதற்குக் கீழே நீங்கள் எதிர்பார்க்க வேண்டிய வெளியீடு கொடுக்கப்பட்டுள்ளது.
dnf-automatic-ஐ நிறுவி, அதனுடன் வரும் configuration-ஐ வாசித்தல்
தானியங்கி மேம்படுத்தல்களை (automatic updates) செயல்படுத்துவது, புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற பகுதியில் உள்ள மற்ற அமைப்புகளுடன் செய்யப்பட வேண்டும். root அல்லாத பயனர் மற்றும் firewall-ஐ உருவாக்கிய பிறகு இதைச் செய்யவும்.
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-ல், ஒரு மேம்படுத்தல் கூட நடக்காமல் இருப்பதற்கு இதுவே மிக முக்கியமான காரணம்.
ஒரு குறிப்பிட்ட விருப்பத்திற்கு (option) DNF-ன் பதிப்பு முக்கியமானது. reboot அமைப்பு DNF 4.15-ல் அறிமுகப்படுத்தப்பட்டது. Red Hat நிறுவனம் இதை நவம்பர் 2023-ல் RHBA-2023:6645 என்ற advisory மூலம் dnf-4.14.0-6.el9-க்கு backport செய்தது. Rocky 9 மற்றும் AlmaLinux 9 ஆகியவை அந்த package-ஐ மீண்டும் கட்டமைத்துள்ளன. எனவே, தற்போதைய server-களில் இது இருக்கும், ஆனால் 2023-க்குப் பிறகு மேம்படுத்தப்படாத server-களில் இது இருக்காது.
இதன் configuration file /etc/dnf/automatic.conf ஆகும். இதில் உள்ள ஒவ்வொரு விருப்பமும், அதன் default மதிப்பும் comment செய்யப்பட்ட நிலையில் பட்டியலிடப்பட்டிருக்கும். நீங்கள் திருத்துவதற்கு முன் ஒருமுறை இதை வாசிக்கவும், ஏனெனில் உங்கள் பதிப்பிற்கு எது பொருந்தும் என்பதை அந்த file-தான் துல்லியமாகத் தெரிவிக்கும்.
செயல்பாட்டைத் தீர்மானிக்கும் இரண்டு சுவிட்சுகள்
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: தொகுப்புகள் (packages) 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 என்பது, கணினி boot ஆன பிறகு, இணையத் தொடர்பு கிடைப்பதற்காக இந்தச் செயல்முறை எவ்வளவு வினாடிகள் காத்திருக்க வேண்டும் என்பதைக் குறிக்கிறது. 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 என்பதன் உண்மையான பொருள்
பதிப்பு எண்களை ஒப்பிடுவதன் மூலம் ஒரு update பாதுகாப்பு தொடர்பானதா என்பதை DNF தீர்மானிப்பதில்லை. இது errata metadata-வை வாசிக்கிறது: இது களஞ்சியத்திற்குள் (repository) வெளியிடப்படும் updateinfo.xml எனப்படும் கோப்பாகும். இதில் ஒவ்வொரு ஆலோசனையும் (advisory) அதைச் சரிசெய்யும் தொகுப்புகளைப் (packages) பட்டியலிடுகிறது. AlmaLinux இவற்றை ALSA ஆலோசனைகளாக வெளியிடுகிறது, Rocky இவற்றை RLSA என வெளியிடுகிறது. upgrade_type = security அந்த metadata-விலிருந்து ஒரு வடிகட்டியை (filter) உருவாக்கி, அது பொருந்தும் தொகுப்புகளை மட்டுமே மேம்படுத்துகிறது.
இதன் விளைவாக இரண்டு விஷயங்கள் நடக்கின்றன, இவை பயனர்களுக்கு ஆச்சரியத்தை அளிக்கலாம்.
முதலாவதாக, metadata இல்லையென்றால் updates-ம் இருக்காது. களஞ்சியத்தில் updateinfo.xml இல்லை என்றால், வடிகட்டி எதனுடனும் பொருந்தாது மற்றும் செயல்பாடு journal-ல் இந்த வரியுடன் முடிவடையும்:
No security updates needed, but 3 updates availableசர்வர் பேட்ச் (patch) செய்யப்படாது, ஆனால் தோல்வி எதையும் அது தெரிவிக்காது. நீங்களே சரிபார்க்கவும்:
dnf updateinfo list --security
dnf check-updatednf check-update தொகுப்புகளைப் பட்டியலிட்டு, அதே சமயம் dnf updateinfo list --security எதையும் காட்டவில்லை என்றால், நிலுவையில் உள்ள எதற்கும் ஆலோசனை இல்லை அல்லது களஞ்சியத்தில் வாசிப்பதற்கு ஆலோசனை தரவுகள் இல்லை என்று அர்த்தம். Rocky மற்றும் AlmaLinux ஆகிய இரண்டும் இதை வெளியிடுகின்றன, எனவே அந்த இரண்டிலும் காலியான பட்டியல் என்பது பெரும்பாலும் உண்மையானது. CentOS Stream இதை வெளியிடுவதே இல்லை.
இரண்டாவதாக, பாதுகாப்பு முறை (security mode) என்பது மிகச்சிறிய மாற்றத்தை மட்டும் செய்வதல்ல. dnf-automatic பாதுகாப்பு வடிகட்டியைச் சேர்த்துவிட்டு, சாதாரண மேம்பாட்டுப் பாதையில் (upgrade path) இயங்குகிறது. எனவே, ஒரு ஆலோசனையில் குறிப்பிடப்பட்டுள்ள தொகுப்பு களஞ்சியத்தில் உள்ள புதிய பதிப்பிற்கு மாறுவதுடன், அதன் சார்புள்ள (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 உடன் சேர்த்து அவற்றில் ஒன்றையும் நீங்கள் enable செய்தால், அந்த வேலை இரண்டு வெவ்வேறு செயல்பாடுகளுடன் இரண்டு முறை இயங்கும். இது உங்கள் config கோப்பு புறக்கணிக்கப்படுவது போன்ற தோற்றத்தை உருவாக்கும். எனவே, ஒரு timer-ஐ மட்டும் enable செய்து சரிபார்க்கவும்:
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) இணைப்பைத் திறக்கிறது. இது இயல்பாக 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 உங்கள் service-களை restart செய்வதில்லை
ஒரு package-ஐ நிறுவுவது வட்டில் உள்ள கோப்புகளை மாற்றுகிறது. ஏற்கனவே இயங்கிக்கொண்டிருக்கும் ஒரு process, பழைய code-ஐயே நினைவகத்தில் (memory) வைத்திருக்கும். எனவே, கடந்த மாதம் தொடங்கப்பட்ட ஒரு daemon-க்கு, புதிதாகப் புதுப்பிக்கப்பட்ட library எந்த மாற்றத்தையும் ஏற்படுத்தாது. நிறுவப்பட்ட கோப்பிற்கும், நடைமுறையில் இயங்கும் கோப்பிற்கும் இடையே உள்ள இந்த இடைவெளிதான், தானியங்கி patch-களை நிறுவும்போது, வெறும் நிறுவல் கொள்கை (install policy) மட்டும் போதாது, ஒரு restart கொள்கையும் தேவை என்பதற்கான காரணமாகும்.
sudo dnf install -y dnf-plugins-core
dnf needs-restarting -s
dnf needs-restarting -r-s, service-கள் தொடங்கப்பட்ட பிறகு அவற்றின் கோப்புகள் மாற்றப்பட்ட systemd service-களின் பட்டியலைக் காட்டுகிறது. -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 என்பது ஒரு ஆழமான பகுப்பாய்வு கருவி அல்ல. இது kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon மற்றும் microcode_ctl போன்ற குறிப்பிட்ட சில package-களை மட்டுமே சரிபார்க்கிறது. இவற்றில் ஏதேனும் ஒன்று கடைசி reboot-க்கு பிறகு நிறுவப்பட்டிருந்தால், உங்களுக்கு முதல் விடை கிடைக்கும். உங்கள் server-ல் உள்ள வேறு ஏதேனும் ஒரு service-க்கு reboot தேவைப்பட்டால், /etc/dnf/plugins/needs-restarting.d/ கோப்பகத்தில் .conf என முடியும் ஒரு கோப்பை உருவாக்கி, அதில் அந்த package-ன் பெயர்களைச் சேர்க்கவும்.
Script-களைப் பயன்படுத்துபவர்களுக்கு ஒரு எச்சரிக்கை: dnf needs-restarting -r, reboot தேவைப்படும்போதும் சரி, அல்லது அந்த command-யே தோல்வியடையும்போதும் சரி, பூஜ்ஜியம் அல்லாத (non-zero) exit status-ஐயே வழங்கும். எனவே, வெறும் exit status-ஐ வைத்து மட்டும் எதனால் தோல்வி ஏற்பட்டது என்பதை அறிய முடியாது. வெளியீட்டு உரையை (output text) வாசிக்கவும்.
ஒரு service-ஐ restart செய்வது எளிதானது மற்றும் பெரும்பாலும் அதுவே சரியான நடவடிக்கையாகும். SSH daemon-ஐ restart செய்யும்போது, ஏற்கனவே திறந்திருக்கும் மற்றொரு SSH session மூலம் அதைச் செய்யவும். அப்போதுதான், தவறான configuration காரணமாக நீங்கள் server-லிருந்து வெளியேற்றப்படாமல் (lockout) இருக்க முடியும். புதிய kernel-ஐப் பொறுத்தவரை, இயங்கிக்கொண்டிருக்கும் kernel-ஐ அப்படியே மாற்ற முடியாது என்பதால், reboot செய்வது மட்டுமே ஒரே தீர்வாகும்.
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-ல் வடிகட்டுவதற்குத் தேவையான தரவுகள் உள்ளன.
CentOS Stream இதற்கு விதிவிலக்கு, இது ஒரு சிக்கலான மாற்றமாகும். Stream repositories-ல் updateinfo.xml இருப்பதில்லை, எனவே security filter எதனுடனும் பொருந்தாது மற்றும் ஒவ்வொரு முறையும் No security updates needed என்றே காட்டும். Stream-ல், upgrade_type = default-ஐப் பயன்படுத்தவும், அனைத்து அப்டேட்களையும் ஏற்றுக்கொள்வதைத் தவிர வேறு வழியில்லை என்பதைப் புரிந்துகொள்ளவும். மேலும், Stream ஆனது RHEL-ஐ விட முன்னிலையில் இருப்பதால், Rocky அல்லது AlmaLinux-ல் உள்ள அதே அமைப்பை விட, Stream-ல் அந்த அமைப்பு அடிக்கடி மாறக்கூடும்.
Rocky 10 மற்றும் AlmaLinux 10 ஆகியவை DNF5-க்கு மாறியுள்ளன, இது பெயர்களை மாற்றுகிறது. அதிகாரப்பூர்வ DNF5 ஆவணங்களின்படி, timer என்பது dnf5-automatic.timer என்று அழைக்கப்படுகிறது, இயல்புநிலை அமைப்புகள் /usr/share/dnf5/dnf5-plugins/automatic.conf-ல் உள்ளன, உங்கள் மாற்றங்கள் /etc/dnf/automatic.conf-ல் இருக்க வேண்டும், download_updates என்பது 'no' என்பதற்குப் பதிலாக 'yes' என்று இயல்பாகவே அமைக்கப்பட்டுள்ளது, மேலும் distro-sync என்பது ஒரு upgrade_type ஆக சேர்க்கப்பட்டுள்ளது. advisory query என்பது dnf advisory list ஆகும், updateinfo என்பது ஒரு alias-ஆகத் தக்கவைக்கப்பட்டுள்ளது. பதிப்பு 9-க்காக எழுதப்பட்ட வழிகாட்டிகளிலிருந்து package அல்லது unit பெயர்களை நகலெடுக்கும் முன், உங்கள் கணினியில் எந்தப் பதிப்பு நிறுவப்பட்டுள்ளது என்பதை உறுதிப்படுத்தவும்:
dnf list --available '*automatic*'
systemctl list-unit-files '*automatic*'இந்தத் தலைப்பிற்கான பல வெளியிடப்பட்ட வழிகாட்டிகள் Rocky 8-ஐ மட்டுமே உள்ளடக்கியுள்ளன. அவை எழுதப்பட்ட காலத்திலிருந்து விருப்பத்தேர்வுகள் (option set) அதிகரித்துள்ளன, எனவே பழைய கட்டுரைகளை நம்புவதற்குப் பதிலாக, உங்கள் கணினியில் உள்ள comment செய்யப்பட்ட கோப்பைச் சரிபார்க்கவும்.
தோல்வி நிலைகளும் நீங்கள் காணும் செய்திகளும்
எதுவும் இயங்கவில்லை. systemctl list-timers dnf-automatic.timer ஒரு காலி அட்டவணையை அச்சிடுகிறது மற்றும் systemctl is-enabled dnf-automatic.timer, disabled என்பதை அச்சிடுகிறது. தொகுப்பு (package) நிறுவப்பட்டது, ஆனால் டைமர் (timer) நிறுவப்படவில்லை.
பணி இயங்குகிறது, ஆனால் எதையும் நிறுவவில்லை. ஜர்னலில் (journal) No security updates needed, but 3 updates available உள்ளது. பாதுகாப்பு வடிகட்டி (security filter) எதையும் பொருத்தவில்லை; நிலுவையில் உள்ள எதற்கும் ஆலோசனை (advisory) இல்லை அல்லது களஞ்சியம் (repository) எந்த ஆலோசனை தரவையும் வெளியிடவில்லை என்பதே இதற்குக் காரணம்.
ஒரு அமைப்பு புறக்கணிக்கப்பட்டதாகத் தெரிகிறது. DNF, automatic.conf-ல் உள்ள ஒரு தெரியாத விருப்பத்தை (option) பிழைத்திருத்த நிலையில் (debug level) பதிவு செய்கிறது, பின்னர் இயல்புநிலை அமைப்பைப் பயன்படுத்துகிறது. எனவே, தவறாக எழுதப்பட்ட ஒரு விசை (key) எதையும் மாற்றாது, யாருக்கும் எச்சரிக்கையும் தராது. apply_update = yes என்று எழுதினால், apply_updates என்பது no-லேயே இருக்கும்; இதனால் கணினி எப்போதும் பதிவிறக்கம் செய்யும், ஆனால் எதையும் நிறுவாது. எந்தவொரு மாற்றத்திற்குப் பிறகும், sudo systemctl start dnf-automatic.service-ஐ இயக்கி, கோப்பை நம்புவதற்குப் பதிலாக ஜர்னலைப் படிக்கவும்.
பணி ஒரு நாளைக்கு இரண்டு முறை இயங்குகிறது. இரண்டு டைமர்கள் செயல்படுத்தப்பட்டுள்ளன. systemctl list-unit-files 'dnf-automatic*' எவை என்பதைத் தெளிவாகக் காட்டும், மேலும் கூடுதல் டைமர்கள் உங்கள் கட்டமைப்பு கோப்பை (config file) மீறும் கொடிகளை (flags) அனுப்பும்.
மின்னஞ்சல் வரவில்லை. email வெளியீட்டிற்காக 25-வது போர்ட்டில் (port) எதுவும் கேட்கவில்லை (listening), அல்லது send_error_messages இன்னும் no என்ற நிலையிலேயே உள்ளது; மேலும் அறிக்கையிடத் தகுந்த ஒரே விஷயம் பிழையாக மட்டுமே இருந்தது.
திருத்தப்பட்ட (patched) சேவை இன்னும் பழைய பதிப்பையே காட்டுகிறது. வட்டில் (disk) உள்ள கோப்பு புதியது, ஆனால் நினைவகத்தில் (memory) உள்ள செயல்முறை (process) பழையது. 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 எதையும் கண்டறியாது, ஆனால் சாதாரண மேம்படுத்தல்கள் நிலுவையில் இருக்கும். இதுவே அந்தச் செய்தியைக் காட்டுகிறது. Errata-வை வெளியிடாத CentOS Stream-ல் இது சாதாரணமாக நடக்கும். 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 போன்ற ஒரு முக்கிய package boot-க்கு பிறகு மாற்றப்பட்டதைக் கண்டறிந்தால் மட்டுமே reboot செய்யும். reboot = when-changed என்பது எந்த மேம்படுத்தல் செய்யப்பட்டாலும் reboot செய்யும். இவை இரண்டுமே reboot_command-ஐப் பயன்படுத்துகின்றன, இது இயல்பாகவே shutdown -r +5 என்று அமைக்கப்பட்டிருக்கும், மேலும் இது உள்நுழைந்திருக்கும் பயனர்களுக்கு எச்சரிக்கை செய்தியை அனுப்பும்.
dnf-automatic இயங்கும் நேரத்தை நான் எப்படி மாற்றுவது?
sudo systemctl edit dnf-automatic.timer-ஐ இயக்கி, ஒரு [Timer] பகுதியைச் சேர்க்கவும். அதில் முதலில் ஒரு காலி OnCalendar= வரியையும், அதைத் தொடர்ந்து உங்கள் கால அட்டவணையையும் (உதாரணமாக OnCalendar=*-*-* 03:30) குறிப்பிடவும். அந்த காலி வரி அவசியம், ஏனெனில் OnCalendar என்பது முன்னரே உள்ளவற்றுடன் சேரும் (accumulate). அதைத் தவிர்க்காவிட்டால், ஏற்கனவே உள்ள 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-ஐ இயக்கவும். பழைய code-ல் இயங்கும் services-ஐக் கண்டறிய patch window-க்கு பிறகு dnf needs-restarting -s-ஐ இயக்கவும்.