Rocky Linux, AlmaLinux లలో dnf-automatic సెటప్ చేయడం ఎలా

Rocky Linux మరియు AlmaLinux లలో dnf-automatic ఏమి చేస్తుంది

Rocky Linux మరియు AlmaLinux లలో unattended security updates పొందడానికి dnf-automatic ఉపయోగపడుతుంది. ఇది ఒక చిన్న ప్రోగ్రామ్, దీనిని systemd timer ద్వారా ప్రారంభిస్తారు. ఇది /etc/dnf/automatic.conf ఫైల్‌ను చదివి, ఆ ఫైల్ అనుమతించిన పనులను అమలు చేస్తుంది. దీనిని ఇన్‌స్టాల్ చేయడానికి ఒకే కమాండ్ సరిపోతుంది. ఈ గైడ్‌లోని మిగిలిన భాగం, ఈ ప్రోగ్రామ్ సర్వర్‌ను రక్షిస్తుందా లేదా ఏమీ చేయకుండా నిశ్శబ్దంగా ఉంటుందా అని నిర్ణయించే సెట్టింగ్‌ల గురించి వివరిస్తుంది.

మీరు Debian లేదా Ubuntu నుండి వచ్చినట్లయితే, ఇది Ubuntu VPS పై unattended-upgrades చేసే పనినే చేస్తుంది. అన్నింటికంటే ముఖ్యమైన ఒక వ్యత్యాసం ఉంది: ప్యాకేజీ మేనేజర్ దృష్టిలో "security" అనే పదానికి అర్థం ఏమిటి అనేది. Ubuntu లో ఇది ఒక ప్రత్యేకమైన archive pocket. RHEL కుటుంబంలో ఇది ప్రచురించబడిన advisories కు జతచేయబడిన metadata. ఈ metadata లేకపోవచ్చు లేదా పాతది కావచ్చు. advisory డేటా లేని repository కి dnf-automatic ను పాయింట్ చేస్తే, అది ఏమీ ఇన్‌స్టాల్ చేయదు, కానీ అంతా విజయవంతమైందని నివేదిస్తుంది.

ఈ గైడ్ ఆగస్టు 2026 నాటికి Rocky Linux 9 మరియు AlmaLinux 9 ల కోసం వ్రాయబడింది, ఇవి DNF 4 ను ఉపయోగిస్తాయి (DNF అనేది RHEL కుటుంబంలో ప్యాకేజీ మేనేజర్). 10 వెర్షన్లు DNF5 కి మారాయి మరియు అక్కడ పేర్లు మారుతాయి, కాబట్టి వాటికి చివరలో ప్రత్యేక విభాగం ఉంటుంది. కింద ఉన్న ప్రతి కమాండ్ మీరు మీ స్వంత సర్వర్‌లో రన్ చేయవలసినది, దాని పక్కనే మీరు ఆశించవలసిన అవుట్‌పుట్ ఇవ్వబడింది.

dnf-automatic ని ఇన్‌స్టాల్ చేసి, అది అందించే కాన్ఫిగరేషన్‌ను చదవండి

ఆటోమేటిక్ అప్‌డేట్‌లను ఎనేబుల్ చేయడం అనేది కొత్త VPSలో మొదటి పది నిమిషాల సెటప్‌లో భాగంగా ఉండాలి. ఇది మీరు non-root యూజర్‌ను సృష్టించి, ఫైర్‌వాల్‌ను సెటప్ చేసిన తర్వాత చేయాలి. ఒకవేళ ఫైర్‌వాల్ సెటప్ ఇంకా పూర్తి కాకపోతే, Rocky మరియు AlmaLinux లలో firewalld డిఫాల్ట్‌గా వస్తుంది. కొన్ని కమాండ్ల ద్వారా SSHని, మీ సైట్ వినే పోర్ట్‌ను ఓపెన్ చేయవచ్చు మరియు రీబూట్ తర్వాత కూడా అవి పనిచేసేలా చేయవచ్చు.

sudo dnf install -y dnf-automatic
rpm -q dnf dnf-automatic
systemctl is-enabled dnf-automatic.timer

systemctl is-enabled కొత్త ఇన్‌స్టాలేషన్‌లో disabled అని చూపిస్తుంది, ఎందుకంటే ప్యాకేజీని ఇన్‌స్టాల్ చేసినంత మాత్రాన ఏ సేవ ప్రారంభం కాదు. "dnf-automatic ఉంది" అని అనుకునే సర్వర్లలో ఒక్క అప్‌డేట్ కూడా జరగకపోవడానికి ఇదే అత్యంత సాధారణ కారణం.

ఒక ఆప్షన్ కోసం DNF వెర్షన్ ముఖ్యమైనది. reboot సెట్టింగ్ DNF 4.15 లో అప్‌స్ట్రీమ్ ద్వారా వచ్చింది. Red Hat దీనిని నవంబర్ 2023లో RHBA-2023:6645 అడ్వైజరీ ద్వారా dnf-4.14.0-6.el9 లోకి బ్యాక్‌పోర్ట్ చేసింది. Rocky 9 మరియు AlmaLinux 9 ఈ ప్యాకేజీని రీబిల్డ్ చేస్తాయి, కాబట్టి ప్రస్తుత సర్వర్లలో ఇది ఉంటుంది, కానీ 2023 నుండి అప్‌డేట్ చేయని సర్వర్లలో ఇది ఉండకపోవచ్చు.

కాన్ఫిగరేషన్ ఫైల్ /etc/dnf/automatic.conf. ఈ బిల్డ్ అర్థం చేసుకోగల ప్రతి ఆప్షన్‌ను, దాని డిఫాల్ట్ విలువతో సహా ఈ ఫైల్‌లో కామెంట్ రూపంలో చూడవచ్చు. మీరు ఎడిట్ చేయడానికి ముందు ఒకసారి దీన్ని చదవండి, ఎందుకంటే మీ వెర్షన్‌కు సంబంధించి ఆ ఫైలే ప్రామాణికం.

ఏమి జరగాలనేది నిర్ణయించే రెండు స్విచ్‌లు

download_updates మరియు apply_updates అనేవి [commands] విభాగంలో ప్రవర్తనను నిర్ణయిస్తాయి. EL9 (Rocky 9 మరియు AlmaLinux 9 ల ఉమ్మడి ఆధారమైన enterprise Linux 9) లో ఇవి రెండూ డిఫాల్ట్‌గా no లో ఉంటాయి, కాబట్టి మీరు ఎనేబుల్ చేసిన ఎడిట్ చేయని dnf-automatic కేవలం ఏవి అందుబాటులో ఉన్నాయో మాత్రమే తెలియజేస్తుంది.

• రెండూ no: dnf-automatic అందుబాటులో ఉన్న అప్‌డేట్‌లను నివేదిస్తుంది, సర్వర్‌లో దేనినీ మార్చదు.
• download_updates = yes మరియు apply_updates = no: ప్యాకేజీలు DNF cache లోకి డౌన్‌లోడ్ అవుతాయి. దీనివల్ల ఇన్‌స్టాలేషన్ వేగంగా జరుగుతుంది మరియు నెట్‌వర్క్ అవసరం ఉండదు, కానీ ఆ రాత్రికి ఏ మార్పులూ జరగవు.
• రెండూ yes మరియు upgrade_type = default: భద్రతా అప్‌డేట్‌లతో సంబంధం లేకుండా అందుబాటులో ఉన్న ప్రతి అప్‌డేట్ ఇన్‌స్టాల్ అవుతుంది.
• రెండూ yes మరియు upgrade_type = security: కేవలం సెక్యూరిటీ అడ్వైజరీలో పేర్కొన్న ప్యాకేజీలు మాత్రమే ఇన్‌స్టాల్ అవుతాయి.

పబ్లిక్-ఫేసింగ్ VPS కోసం ఒక సహేతుకమైన ప్రారంభం:

[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
random_sleep = 0
network_online_timeout = 60
reboot = never

network_online_timeout అనేది నెట్‌వర్క్ పని చేసే వరకు రన్ ఎంత సమయం (సెకన్లలో) వేచి ఉండాలో నిర్ణయిస్తుంది, ఇది ఇప్పుడే బూట్ అయిన సర్వర్‌లకు చాలా ముఖ్యం. random_sleep అనేది అనేక మెషీన్ల మధ్య లోడ్‌ను పంపిణీ చేయడానికి ఉపయోగించే పాత పద్ధతి, ఇప్పుడు ఆ పనిని టైమర్ చేస్తోంది. సర్వీస్ ద్వారా పంపబడే ఖచ్చితమైన ఫ్లాగ్‌లను చూడటానికి systemctl cat dnf-automatic.service రన్ చేయండి.

06:00 వరకు వేచి ఉండకుండా, ఫైల్ మీరు అనుకున్నట్లుగా పని చేస్తుందో లేదో ఇలా పరీక్షించండి:

sudo systemctl start dnf-automatic.service
sudo journalctl -u dnf-automatic.service -n 50 --no-pager

ఈ రన్ ఏమి పరిగణనలోకి తీసుకుందో మరియు ఏమి చేసిందో journal చూపిస్తుంది. మీరు కమాండ్ లైన్ నుండి ఒక నిర్దిష్ట ప్రవర్తనను బలవంతంగా అమలు చేయవచ్చు, ఇది ఆ రన్‌కు మాత్రమే ఫైల్ సెట్టింగ్‌లను ఓవర్‌రైడ్ చేస్తుంది:

sudo dnf-automatic --downloadupdates --no-installupdates

Rocky మరియు Alma లలో upgrade_type = security అంటే ఏమిటి

DNF అనేది వెర్షన్ నంబర్లను పోల్చడం ద్వారా ఒక అప్‌డేట్ సెక్యూరిటీ అప్‌డేటా కాదా అని నిర్ణయించదు. ఇది errata మెటాడేటాను చదువుతుంది: రిపోజిటరీలో ప్రచురించబడిన updateinfo.xml అనే ఫైల్, ఇందులో ప్రతి అడ్వైజరీ దాన్ని పరిష్కరించే ప్యాకేజీలను జాబితా చేస్తుంది. AlmaLinux వీటిని ALSA అడ్వైజరీలుగా, Rocky వీటిని RLSAలుగా ప్రచురిస్తాయి. upgrade_type = security ఆ మెటాడేటా నుండి ఒక ఫిల్టర్‌ను తయారు చేసి, దానికి సరిపోయే ప్యాకేజీలను మాత్రమే అప్‌గ్రేడ్ చేస్తుంది.

దీని వల్ల రెండు పరిణామాలు ఉంటాయి, ఇవి చాలామందిని ఆశ్చర్యపరుస్తాయి.

మొదటిది, మెటాడేటా లేకపోతే అప్‌డేట్లు ఉండవు. రిపోజిటరీలో updateinfo.xml లేకపోతే, ఫిల్టర్ దేనికీ సరిపోదు మరియు రన్ జర్నల్‌లో ఈ లైన్‌తో ముగుస్తుంది:

No security updates needed, but 3 updates available

సర్వర్ ప్యాచ్ చేయబడదు, మరియు ఎటువంటి వైఫల్యం కూడా రిపోర్ట్ అవ్వదు. దీన్ని మీరే తనిఖీ చేయండి:

dnf updateinfo list --security
dnf check-update

dnf check-update ప్యాకేజీలను జాబితా చేసినప్పుడు dnf updateinfo list --security ఏమీ చూపించకపోతే, పెండింగ్‌లో ఉన్న వాటికి ఎటువంటి అడ్వైజరీ లేదని లేదా రిపోజిటరీలో చదవడానికి అడ్వైజరీ డేటా లేదని అర్థం. Rocky మరియు AlmaLinux రెండూ దీన్ని ప్రచురిస్తాయి, కాబట్టి ఆ రెండింటిలో ఖాళీ జాబితా సాధారణంగా వాస్తవమే. CentOS Stream దీన్ని అస్సలు ప్రచురించదు.

రెండవది, సెక్యూరిటీ మోడ్ అంటే అతి తక్కువ మార్పులు చేయడం కాదు. dnf-automatic సెక్యూరిటీ ఫిల్టర్‌ను జోడించి, ఆపై సాధారణ అప్‌గ్రేడ్ మార్గాన్ని అనుసరిస్తుంది. కాబట్టి అడ్వైజరీలో పేర్కొన్న ప్యాకేజీ రిపోజిటరీలోని సరికొత్త వెర్షన్‌కు మారుతుంది మరియు దాని డిపెండెన్సీలను కూడా వెంట తెచ్చుకుంటుంది. అడ్వైజరీని పరిష్కరించే అతి తక్కువ వెర్షన్‌కు మాత్రమే మారడం అనేది dnf upgrade-minimal --security ద్వారా మాన్యువల్‌గా చేసే ప్రక్రియ. dnf-automatic లో దీని కోసం ఎటువంటి సెట్టింగ్ లేదు.

Rocky కి సంబంధించి మరో ముఖ్యమైన విషయం ఉంది. Rocky తన errata ను Red Hat డేటా నుండి తన సొంత పైప్‌లైన్ ద్వారా రూపొందిస్తుంది, మరియు ఆ పైప్‌లైన్ వెనుకబడిపోయింది. సెప్టెంబర్ 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.timer

list-timers ఒక వరుసను, దాదాపు ఒక రోజు తర్వాత ఉండే NEXT సమయాన్ని చూపాలి. పట్టిక ఖాళీగా ఉంటే, timer ఎనేబుల్ కాలేదని అర్థం, కాబట్టి ఏదీ రన్ అవ్వదు.

షిప్ చేయబడిన timer *-*-* 6:00 వద్ద RandomizedDelaySec=60m మరియు Persistent=true తో రన్ అవుతుంది. ఈ random delay వల్ల సర్వర్లన్నీ ఒకే సెకనులో mirror ను తాకకుండా, ఒక గంట వ్యవధిలో పనులు జరుగుతాయి. Persistent=true అంటే, 06:00 గంటలకు పవర్ ఆఫ్ అయిన మెషీన్, ఆ రోజును వదిలేయకుండా, బూట్ అయిన వెంటనే ఆ మిగిలిపోయిన పనిని పూర్తి చేస్తుంది.

షెడ్యూల్‌ను మార్చడానికి drop-in ఉపయోగించండి. షిప్ చేయబడిన unit ను ఎడిట్ చేయవద్దు, ఎందుకంటే ప్యాకేజీ అప్‌గ్రేడ్ జరిగినప్పుడు /usr/lib/systemd/system లోని ఫైళ్లు భర్తీ చేయబడతాయి.

sudo systemctl edit dnf-automatic.timer

[Timer]
OnCalendar=
OnCalendar=*-*-* 03:30
RandomizedDelaySec=30m

ఖాళీగా ఉన్న OnCalendar= లైన్ తప్పనిసరి. OnCalendar విలువలు పేరుకుపోతాయి (accumulate), కాబట్టి ఆ రీసెట్ లేకపోతే మీరు 06:00 ఎంట్రీని అలాగే ఉంచి మరొకటి జోడిస్తారు, దీనివల్ల ఆ పని రోజుకు రెండుసార్లు రన్ అవుతుంది. ఫలితాన్ని systemctl list-timers dnf-automatic.timer తో నిర్ధారించుకుని, NEXT కాలమ్‌ను చూడండి. మీరు షెడ్యూల్ చేసే ఇతర పనులకు కూడా ఇదే drop-in నియమాలు వర్తిస్తాయి, దీని గురించి systemd service మరియు timer units రాయడం లో వివరించబడింది.

ఇప్పుడు అసలు చిక్కుముడి. ఈ ప్యాకేజీ మరో మూడు timer లను షిప్ చేస్తుంది: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer మరియు dnf-automatic-install.timer. ప్రతిదీ ఒకే ప్రోగ్రామ్‌ను command-line flags తో ప్రారంభిస్తుంది, ఆ flags మీ కాన్ఫిగరేషన్ ఫైల్‌లోని download_updates మరియు apply_updates లను ఓవర్‌రైడ్ చేస్తాయి. dnf-automatic.timer పక్కన వీటిలో ఒకదానిని ఎనేబుల్ చేస్తే, ఆ పని రెండు వేర్వేరు పద్ధతుల్లో రెండుసార్లు రన్ అవుతుంది, ఇది మీ కాన్ఫిగరేషన్ ఫైల్‌ను పట్టించుకోనట్లుగా కనిపిస్తుంది. ఏదైనా ఒక timer ను ఎనేబుల్ చేసి ఇలా తనిఖీ చేయండి:

systemctl list-unit-files 'dnf-automatic*'

ఏదైనా ఇన్‌స్టాల్ చేయబడిందో లేదో నాకు ఎలా తెలుస్తుంది?

emit_via లోని [emitters] విభాగం రిపోర్టింగ్‌ను నియంత్రిస్తుంది. systemd కింద, stdio ఎమిటర్ జర్నల్‌లోకి రాస్తుంది. ఇది నమ్మదగిన ఎంపిక, ఎందుకంటే దీనికి అదనంగా ఏదీ ఇన్‌స్టాల్ చేయాల్సిన అవసరం లేదు:

sudo journalctl -u dnf-automatic.service --since -7d --no-pager

motd ఎమిటర్ రిపోర్టును /etc/motd లోకి రాస్తుంది మరియు ఆ ఫైల్‌లోని కంటెంట్‌ను భర్తీ చేస్తుంది. మీరు అక్కడ లాగిన్ బ్యానర్‌ను ఉంచినట్లయితే, ఈ ఎమిటర్‌ను ఉపయోగించవద్దు.

email ఎమిటర్ email_host లోని email_port కి SMTP (simple mail transfer protocol) కనెక్షన్‌ను తెరుస్తుంది. ఇవి డిఫాల్ట్‌గా localhost మరియు 25 కి సెట్ చేయబడి ఉంటాయి. కొత్త VPSలో అక్కడ ఏ సేవలు వినబడవు (listening), కాబట్టి కనెక్షన్ తిరస్కరించబడుతుంది మరియు మెయిల్ పంపబడదు. మీరు దీనిపై ఆధారపడే ముందు ss -lnt | grep ':25' ని రన్ చేయండి, మరియు అవుట్‌పుట్ ఖాళీగా ఉంటే relay-only Postfix ని సెటప్ చేయండి. మెయిల్ పనిచేస్తున్నప్పుడు, సబ్జెక్ట్ Updates applied on 'web01'. అని ఉంటుంది, ఇది system_name నుండి పేరును తీసుకుంటుంది.

మరేదైనా ఇతర అవసరం కోసం, command ఎమిటర్ రిపోర్టును మీ ప్రోగ్రామ్‌కు 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 కి సెట్ చేయబడి ఉంటుంది, అంటే విఫలమైన రన్ ఏ సమాచారాన్ని అందించదు. దీన్ని ఆన్ చేయండి. కేవలం విజయవంతమైన వాటిని మాత్రమే తెలియజేసే ప్యాచింగ్ సిస్టమ్, ఏదీ లేకపోవడం కంటే ప్రమాదకరం, ఎందుకంటే నిశ్శబ్దాన్ని సిస్టమ్ ఆరోగ్యంగా ఉన్నట్లుగా పొరబడే అవకాశం ఉంది.

dnf-automatic మీ సర్వీసులను రీస్టార్ట్ చేయదు

ఒక ప్యాకేజీని ఇన్‌స్టాల్ చేసినప్పుడు డిస్క్‌లోని ఫైళ్లు భర్తీ చేయబడతాయి. ఇప్పటికే నడుస్తున్న ప్రాసెస్ పాత కోడ్‌నే మెమరీలో ఉంచుకుంటుంది, కాబట్టి గత నెలలో ప్రారంభమైన డెమోన్ (daemon) కోసం ప్యాచ్ చేసిన లైబ్రరీ ఏమీ చేయదు. ఇన్‌స్టాల్ చేసిన దానికి మరియు అమలులో ఉన్న దానికి మధ్య ఉండే ఈ వ్యత్యాసం వల్లే, అన్‌అటెండెడ్ ప్యాచింగ్‌కు కేవలం ఇన్‌స్టాల్ పాలసీ మాత్రమే కాకుండా, రీస్టార్ట్ పాలసీ కూడా అవసరం.

sudo dnf install -y dnf-plugins-core
dnf needs-restarting -s
dnf needs-restarting -r

-s అనేది సర్వీసులు ప్రారంభమైన తర్వాత వాటి ఫైళ్లు మారిన systemd సర్వీసుల జాబితాను చూపుతుంది. -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. వీటిలో ఏదైనా చివరి బూట్ తర్వాత ఇన్‌స్టాల్ చేయబడితే, మీకు మొదటి సమాధానం వస్తుంది. సర్వర్‌లో మరేదైనా మార్పుకు రీబూట్ అవసరమైనప్పుడు, /etc/dnf/plugins/needs-restarting.d/ కింద .conf తో ముగిసే ఫైల్‌లో మీ స్వంత ప్యాకేజీ పేర్లను జోడించండి.

స్క్రిప్ట్‌ల కోసం ఒక హెచ్చరిక: రీబూట్ అవసరమైనప్పుడు మరియు కమాండ్ విఫలమైనప్పుడు కూడా dnf needs-restarting -r నాన్-జీరో (non-zero) ఎగ్జిట్ స్టేటస్‌ను ఇస్తుంది, కాబట్టి కేవలం ఎగ్జిట్ స్టేటస్‌ను బట్టి రెండింటి మధ్య తేడాను గుర్తించలేము. అవుట్‌పుట్ టెక్స్ట్‌ను చదవండి.

సర్వీసును రీస్టార్ట్ చేయడం చిన్న పని మరియు సాధారణంగా అదే సరైన పద్ధతి. SSH డెమోన్‌ను రీస్టార్ట్ చేసేటప్పుడు, ఇప్పటికే తెరిచి ఉన్న రెండవ SSH సెషన్ నుండి చేయండి, తద్వారా తప్పు కాన్ఫిగరేషన్ వల్ల మీరు లాక్-అవుట్ అవ్వకుండా ఉంటారు. కొత్త కెర్నల్ విషయంలో మాత్రమే రీబూట్ అవసరమవుతుంది, ఎందుకంటే నడుస్తున్న కెర్నల్‌ను ఉన్నచోటే భర్తీ చేయడం సాధ్యం కాదు. ఒక రోజు జరిగిన అప్‌డేట్‌లను ఈ రెండు వర్గాలుగా విభజించాలనుకుంటే, ఏ అప్‌డేట్‌లకు రీబూట్ అవసరం మరియు వేటికి సర్వీస్ రీస్టార్ట్ అవసరం అనే గైడ్ ప్యాకేజీల వారీగా అవుట్‌పుట్‌ను విశ్లేషించడంలో సహాయపడుతుంది.

కంటైనర్లు వేరే విషయం, ఎందుకంటే dnf-automatic హోస్ట్ యొక్క ప్యాకేజీలను మాత్రమే ప్యాచ్ చేస్తుంది, ఇమేజ్‌లో ఉన్న యూజర్‌ల్యాండ్‌ను తాకదు. కాబట్టి Rocky Linux లేదా AlmaLinux పై Docker Engine నడుపుతున్న సర్వర్‌లో, ప్యాచ్‌లు అమలులోకి రావాలంటే ఇమేజ్‌లను మళ్లీ పుల్ (pull) చేసి, కంటైనర్లను రీక్రియేట్ చేయాల్సి ఉంటుంది.

సర్వర్ స్వయంచాలకంగా రీబూట్ అవ్వాలా?

[commands]
reboot = when-needed
reboot_command = shutdown -r +5 'Rebooting after applying package updates'

reboot = never అనేది డిఫాల్ట్ సెట్టింగ్. when-changed ఏదైనా అప్‌డేట్ అప్లై చేసిన తర్వాత రీబూట్ చేస్తుంది. when-needed అనేది needs-restarting -r వెనుక ఉన్న తనిఖీ ద్వారా ఏదైనా కోర్ ప్యాకేజీ మార్చబడిందని నిర్ధారించుకున్నప్పుడు మాత్రమే రీబూట్ చేస్తుంది; చాలా మంది సింగిల్-సర్వర్ వినియోగదారులు కోరుకునేది ఇదే, దీనికి వారు ఎంచుకున్న టైమర్ విండోను జత చేయవచ్చు. డిఫాల్ట్ reboot_command సెట్టింగ్, లాగిన్ అయి ఉన్న వినియోగదారులకు shutdown ద్వారా ఐదు నిమిషాల ముందుగానే హెచ్చరికను పంపుతుంది, మీరు ఈ సమయాన్ని పెంచుకోవచ్చు.

దీనిని ఆన్ చేసే ముందు రెండు విషయాలను ఖాయం చేసుకోండి. మీరు ఆధారపడే ప్రతి సేవ బూట్ సమయంలో స్వయంచాలకంగా ప్రారంభం కావాలి, సాధారణంగా మాన్యువల్‌గా ప్రారంభించిన Docker Compose stack విషయంలో ఇది లోపంగా ఉంటుంది. అలాగే, మీ ప్రొవైడర్ నుండి కన్సోల్ లేదా రెస్క్యూ యాక్సెస్ ఉండాలి, ఎందుకంటే బూట్ అవ్వని కెర్నల్‌ను SSH ద్వారా సరిచేయలేము. ఈ రెండింటిలో ఏది లేకపోయినా, reboot = never సెట్టింగ్‌నే ఉంచి, జర్నల్‌ను పరిశీలించిన తర్వాత మీరే స్వయంగా రీబూట్ చేయండి.

Rocky, AlmaLinux మరియు CentOS Stream: వీటి మధ్య తేడాలు

Rocky 9 మరియు AlmaLinux 9 లలో పైన పేర్కొన్నవన్నీ ఒకేలా ఉంటాయి, కాన్ఫిగరేషన్ పాత్ మరియు యూనిట్ పేర్లు కూడా మారవు. ఈ రెండూ errata ను ప్రచురిస్తాయి, కాబట్టి upgrade_type = security ఫిల్టర్ చేయడానికి డేటాను కలిగి ఉంటుంది. పైన పేర్కొన్న పాత Rocky errata సమస్య ఈ రెండింటి రోజువారీ పనితీరులో కనిపించే కొన్ని తేడాలలో ఒకటి. కాబట్టి, సర్వర్‌ను ఇంకా సిద్ధం చేయకపోతే, ఈ రెండింటినీ వేరు చేసే compatibility promise మరియు పాత-CPU సపోర్ట్ అంశాలను పరిగణనలోకి తీసుకోండి.

CentOS Stream ఒక మినహాయింపు, ఇది చాలా భిన్నమైనది. Stream రిపోజిటరీలలో updateinfo.xml ఉండవు, కాబట్టి సెక్యూరిటీ ఫిల్టర్ ఏ ఫలితాన్ని చూపదు మరియు ప్రతి రన్ No security updates needed అని రిపోర్ట్ చేస్తుంది. Stream లో, upgrade_type = default ఉపయోగించండి మరియు అన్ని అప్‌డేట్‌లను స్వీకరించడానికి సిద్ధపడండి. Stream, RHEL కంటే ముందు ఉంటుంది, కాబట్టి Rocky లేదా AlmaLinux తో పోలిస్తే Stream బాక్స్‌లో సెట్టింగ్‌లు తరచుగా మారుతుంటాయి. ఈ తేడా ప్యాకేజింగ్ వల్ల వచ్చినది కాదు, 2020లో Red Hat తీసుకున్న నిర్ణయం వల్ల CentOS ను RHEL యొక్క rolling preview గా మార్చారు. ఈ నిర్ణయం వల్లే Rocky Linux మరియు AlmaLinux ఉనికిలోకి వచ్చాయి.

Rocky 10 మరియు AlmaLinux 10 లు DNF5 కి మారాయి, ఇది పేర్లను మారుస్తుంది. అప్‌స్ట్రీమ్ DNF5 డాక్యుమెంటేషన్ ప్రకారం టైమర్ పేరు dnf5-automatic.timer, డిఫాల్ట్ సెట్టింగ్‌లు /usr/share/dnf5/dnf5-plugins/automatic.conf లో ఉంటాయి మరియు మీ ఓవర్‌రైడ్స్ /etc/dnf/automatic.conf లో ఉంటాయి. ఇది download_updates ను 'no' కి బదులుగా 'yes' కి డిఫాల్ట్ చేస్తుంది మరియు upgrade_type గా distro-sync ని జోడిస్తుంది. అడ్వైజరీ క్వెరీ dnf advisory list, దీనికి updateinfo ని alias గా ఉంచారు. వెర్షన్ 9 కోసం రాసిన గైడ్ నుండి ప్యాకేజీ లేదా యూనిట్ పేర్లను కాపీ చేసే ముందు, మీ సిస్టమ్‌లో ఏది ఇన్‌స్టాల్ అయిందో నిర్ధారించుకోండి:

dnf list --available '*automatic*'
systemctl list-unit-files '*automatic*'

ఈ అంశంపై ప్రచురించబడిన అనేక గైడ్‌లు కేవలం Rocky 8 కి మాత్రమే పరిమితమై ఉన్నాయి. ఆ గైడ్‌లు రాసినప్పటి నుండి ఆప్షన్లు పెరిగాయి, కాబట్టి పాత ఆర్టికల్‌ను నమ్మే బదులు మీ సర్వర్‌లోని కామెంట్ చేయబడిన ఫైల్‌ను తనిఖీ చేయండి.

వైఫల్య రీతులు మరియు మీకు కనిపించే స్ట్రింగ్‌లు

ఏదీ రన్ అవ్వడం లేదు. systemctl list-timers dnf-automatic.timer ఖాళీ పట్టికను ప్రింట్ చేస్తుంది మరియు systemctl is-enabled dnf-automatic.timer disabledని ప్రింట్ చేస్తుంది. ప్యాకేజీ ఇన్‌స్టాల్ చేయబడింది, కానీ టైమర్ ఇన్‌స్టాల్ కాలేదు.

జాబ్ రన్ అవుతుంది కానీ దేనినీ ఇన్‌స్టాల్ చేయదు. జర్నల్‌లో No security updates needed, but 3 updates available ఉంటుంది. సెక్యూరిటీ ఫిల్టర్ దేనినీ మ్యాచ్ చేయలేదు, ఎందుకంటే పెండింగ్‌లో ఉన్న వాటికి ఎటువంటి అడ్వైజరీ లేదు లేదా రిపోజిటరీ ఎటువంటి అడ్వైజరీ డేటాను ప్రచురించలేదు.

ఒక సెట్టింగ్ పట్టించుకోనట్లు కనిపిస్తుంది. DNF, automatic.confలో తెలియని ఆప్షన్‌ను డీబగ్ లెవల్‌లో లాగ్ చేస్తుంది, ఆపై డిఫాల్ట్ సెట్టింగ్‌ను ఉపయోగిస్తుంది. కాబట్టి తప్పుగా స్పెల్లింగ్ ఉన్న కీ ఏ మార్పు చేయదు మరియు ఎవరినీ హెచ్చరించదు. apply_update = yes అని వ్రాసినా, apply_updates అనేది no వద్దే ఉంటుంది, కాబట్టి బాక్స్ ఎప్పటికీ డౌన్‌లోడ్ అవుతూనే ఉంటుంది కానీ ఇన్‌స్టాల్ అవ్వదు. ఏదైనా ఎడిట్ చేసిన తర్వాత, sudo systemctl start dnf-automatic.service రన్ చేయండి మరియు ఫైల్‌ను నమ్మే బదులు జర్నల్‌ను చదవండి.

జాబ్ రోజుకు రెండుసార్లు రన్ అవుతుంది. రెండు టైమర్లు ఎనేబుల్ చేయబడ్డాయి. systemctl list-unit-files 'dnf-automatic*' ఏవి ఎనేబుల్ అయ్యాయో చూపిస్తుంది, మరియు అదనపు టైమర్లు మీ కాన్ఫిగరేషన్ ఫైల్ కంటే బలమైన ఫ్లాగ్‌లను పంపుతాయి.

ఎటువంటి మెయిల్ అందడం లేదు. email ఎమిటర్ కోసం పోర్ట్ 25పై ఏదీ వినడం లేదు, లేదా send_error_messages ఇంకా no గానే ఉంది మరియు రిపోర్ట్ చేయడానికి తగిన ఏకైక విషయం ఒక ఎర్రర్ మాత్రమే.

ప్యాచ్ చేయబడిన సర్వీస్ ఇంకా పాత వెర్షన్‌నే చూపిస్తుంది. డిస్క్‌లోని ఫైల్ కొత్తది, కానీ మెమరీలోని ప్రాసెస్ పాతది. dnf needs-restarting -s రీస్టార్ట్ చేయాల్సిన సర్వీసుల పేర్లను తెలియజేస్తుంది.

FAQ

Rocky Linuxలో dnf-automatic కేవలం security updates మాత్రమే ఇన్‌స్టాల్ చేస్తుందా?

మీరు upgrade_type = security ను /etc/dnf/automatic.conf లో సెట్ చేసినప్పుడు మరియు మీ repositories errata metadataను ప్రచురించినప్పుడు మాత్రమే ఇది సాధ్యమవుతుంది. Rocky Linux మరియు AlmaLinux రెండూ వీటిని ప్రచురిస్తాయి, కాబట్టి ఈ ఫిల్టర్ సరిపోలే advisoriesను గుర్తిస్తుంది. డిఫాల్ట్‌గా upgrade_type = default సెట్ చేయబడి ఉంటుంది, ఇది apply_updates = yes జరిగినప్పుడు అందుబాటులో ఉన్న అన్ని updatesను ఇన్‌స్టాల్ చేస్తుంది.

dnf-automatic "No security updates needed, but 3 updates available" అని ఎందుకు చూపిస్తుంది?

Repository నుండి updateinfo.xml ను చదవడం ద్వారా ఏది security update కిందకు వస్తుందో DNF నిర్ణయిస్తుంది; ప్రతి advisory లో దానికి సంబంధించిన packages జాబితా ఉంటుంది. ఈ metadata లేనప్పుడు లేదా పాతదైనప్పుడు, security filter ఏమీ గుర్తించదు, కానీ సాధారణ updates పెండింగ్‌లో ఉంటాయి, దీనివల్ల ఆ సందేశం కనిపిస్తుంది. CentOS Stream లో errata ఉండదు కాబట్టి ఇది సహజం. Rocky లేదా AlmaLinux లో అయితే, dnf updateinfo list --security ను dnf check-update తో పోల్చి చూసి, మీ metadata తాజాగా ఉందో లేదో తనిఖీ చేయండి.

kernel update తర్వాత dnf-automatic నా సర్వర్‌ను reboot చేస్తుందా?

మీరు కోరితే తప్ప ఇది జరగదు. reboot ఆప్షన్ డిఫాల్ట్‌గా never గా ఉంటుంది. reboot = when-needed సెట్ చేస్తే, dnf needs-restarting -r వెనుక ఉన్న తనిఖీ ద్వారా kernel లేదా glibc వంటి core packages బూట్ తర్వాత రీప్లేస్ అయ్యాయని తెలిస్తేనే 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 కాలమ్‌ను చూడండి.

సర్వర్ తనంతట తాను ప్యాచ్ చేసుకున్నా నేను దాన్ని తనిఖీ చేయాలా?

అవును. dnf-automatic కేవలం packagesను ఇన్‌స్టాల్ చేసి ఆగిపోతుంది. ఇది daemonsను రీస్టార్ట్ చేయదు. మీరు emit_via లో పేర్కొన్న emitter ను క్రమం తప్పకుండా చూడకపోతే, మీకు ఎటువంటి సమాచారం అందదు. కనీసం emit_via ను stdio కి సెట్ చేయండి, వైఫల్యాల గురించి తెలుసుకోవడానికి send_error_messages ను ఆన్ చేయండి, మరియు ప్యాచ్ విండో తర్వాత పాత కోడ్‌తో నడుస్తున్న సేవలను గుర్తించడానికి dnf needs-restarting -s రన్ చేయండి.