Rocky Linux اور AlmaLinux پر dnf-automatic کی ترتیب

Rocky Linux اور AlmaLinux پر dnf-automatic کیا کام کرتا ہے

dnf-automatic وہ طریقہ ہے جس سے آپ Rocky Linux اور AlmaLinux پر خودکار سیکیورٹی اپ ڈیٹس حاصل کرتے ہیں۔ یہ ایک چھوٹا سا پروگرام ہے جسے systemd ٹائمر کے ذریعے چلایا جاتا ہے، جو /etc/dnf/automatic.conf کو پڑھتا ہے اور اس فائل میں دی گئی اجازتوں کے مطابق عمل کرتا ہے۔ اس کی تنصیب صرف ایک کمانڈ سے مکمل ہو جاتی ہے۔ اس گائیڈ کا باقی حصہ ان ترتیبات کے بارے میں ہے جو یہ طے کرتی ہیں کہ آیا یہ آپ کے سرور کو محفوظ بناتا ہے یا خاموشی سے کچھ بھی نہیں کرتا۔

اگر آپ Debian یا Ubuntu سے آئے ہیں، تو یہ وہی کام ہے جو Ubuntu VPS پر unattended-upgrades کرتا ہے۔ ایک فرق باقی تمام باتوں سے زیادہ اہم ہے: پیکیج مینیجر کے لیے "سیکیورٹی" کے لفظ کا کیا مطلب ہے۔ Ubuntu پر یہ ایک الگ آرکائیو پاکٹ ہے۔ RHEL فیملی میں یہ شائع شدہ ایڈوائزریز (advisories) کے ساتھ منسلک میٹا ڈیٹا ہے، اور یہ میٹا ڈیٹا غائب یا پرانا ہو سکتا ہے۔ اگر آپ dnf-automatic کو ایسی ریپوزٹری کی طرف موڑ دیں جس میں ایڈوائزری ڈیٹا نہ ہو، تو یہ کچھ بھی انسٹال نہیں کرے گا اور کامیابی کی رپورٹ دے گا۔

یہ گائیڈ Rocky Linux 9 اور AlmaLinux 9 کے لیے لکھی گئی ہے، جو اگست 2026 تک DNF 4 (جو RHEL فیملی کا پیکیج مینیجر ہے) استعمال کرتے ہیں۔ 10 ریلیزز DNF5 پر منتقل ہو چکی ہیں اور وہاں نام تبدیل ہو گئے ہیں، اس لیے ان کے لیے آخر میں ایک الگ سیکشن موجود ہے۔ نیچے دی گئی ہر کمانڈ وہ ہے جسے آپ کو اپنے سرور پر چلانا ہے، اور اس کے ساتھ وہ آؤٹ پٹ ہے جس کی آپ کو توقع رکھنی چاہیے۔

dnf-automatic انسٹال کریں اور اس کی فراہم کردہ کنفیگریشن پڑھیں

خودکار اپ ڈیٹس کو فعال کرنا نئے VPS پر ابتدائی دس منٹ کے سیٹ اپ کا حصہ ہے، جو کہ 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 (انٹرپرائز لینکس 9، جو Rocky 9 اور AlmaLinux 9 کی مشترکہ بنیاد ہے) پر یہ دونوں بائی ڈیفالٹ no ہوتے ہیں، لہذا اگر آپ بغیر ترمیم کیے dnf-automatic کو فعال کرتے ہیں تو یہ صرف آپ کو بتائے گا کہ کیا دستیاب ہے۔

• دونوں no: dnf-automatic دستیاب اپ ڈیٹس کی اطلاع دیتا ہے اور سسٹم میں کوئی تبدیلی نہیں کرتا۔
• download_updates = yes کے ساتھ apply_updates = no: پیکجز کو DNF کیشے میں ڈاؤن لوڈ کیا جاتا ہے۔ اس کے بعد انسٹالیشن تیز ہوتی ہے اور نیٹ ورک کی ضرورت نہیں پڑتی، لیکن اس رات کچھ بھی تبدیل نہیں ہوتا۔
• دونوں 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

جرنل دکھاتا ہے کہ رن نے کن چیزوں پر غور کیا اور کیا کارروائی کی۔ آپ کمانڈ لائن سے بھی کسی ایک رویے کو زبردستی نافذ کر سکتے ہیں، جو صرف اس رن کے لیے فائل کی سیٹنگز کو اوور رائڈ کر دے گا:

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

Rocky اور Alma پر upgrade_type = security کا اصل مطلب کیا ہے

DNF ورژن نمبرز کا موازنہ کر کے یہ طے نہیں کرتا کہ کوئی اپ ڈیٹ سیکیورٹی اپ ڈیٹ ہے یا نہیں۔ یہ errata metadata پڑھتا ہے: ایک فائل جسے 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 اعلانات سے کریں۔ ایسے سسٹم پر جہاں تبدیلی کے کنٹرول سے زیادہ کوریج اہمیت رکھتی ہو، آپ کی منتخب کردہ شیڈول پر upgrade_type = default زیادہ محفوظ سیٹنگ ہے۔

وہ systemd timer جو درحقیقت اسے چلاتا ہے

sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer

list-timers کو ایک قطار دکھانی چاہیے جس میں NEXT کا وقت تقریباً ایک دن بعد کا ہو۔ خالی ٹیبل کا مطلب ہے کہ ٹائمر فعال (enabled) نہیں ہے، لہذا کچھ بھی نہیں چلے گا۔

فراہم کردہ ٹائمر *-*-* 6:00 پر RandomizedDelaySec=60m اور Persistent=true کے ساتھ چلتا ہے۔ بے ترتیب تاخیر (random delay) ایک گھنٹے کے دوران لوڈ کو تقسیم کرتی ہے تاکہ تمام سرورز ایک ہی سیکنڈ میں مرر (mirror) پر بوجھ نہ ڈالیں۔ Persistent=true کا مطلب ہے کہ اگر کوئی مشین 06:00 بجے بند تھی، تو وہ بوٹ ہونے کے فوراً بعد چھوٹا ہوا کام مکمل کر لے گی، بجائے اس کے کہ پورا دن ضائع ہو جائے۔

شیڈول تبدیل کرنے کے لیے drop-in کا استعمال کریں۔ فراہم کردہ یونٹ میں ترمیم نہ کریں، کیونکہ پیکیج اپ گریڈ /usr/lib/systemd/system کے تحت موجود فائلوں کو تبدیل کر دیتا ہے۔

sudo systemctl edit dnf-automatic.timer

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

خالی OnCalendar= لائن ضروری ہے۔ OnCalendar جمع ہوتا رہتا ہے، لہذا اس ری سیٹ کے بغیر آپ 06:00 والی انٹری برقرار رکھیں گے اور ایک دوسری انٹری شامل کر دیں گے، جس سے کام دن میں دو بار چلے گا۔ نتیجے کی تصدیق systemctl list-timers dnf-automatic.timer سے کریں اور NEXT کالم پڑھیں۔ یہی drop-in اصول ہر اس چیز پر لاگو ہوتے ہیں جسے آپ شیڈول کرتے ہیں، جس کی تفصیل systemd سروس اور ٹائمر یونٹس لکھنا میں موجود ہے۔

اب ایک اہم احتیاط۔ پیکیج تین مزید ٹائمرز کے ساتھ آتا ہے: dnf-automatic-notifyonly.timer، dnf-automatic-download.timer اور dnf-automatic-install.timer۔ ہر ایک اسی پروگرام کو کمانڈ لائن فلیگز کے ساتھ شروع کرتا ہے، اور یہ فلیگز آپ کی کنفیگریشن فائل سے download_updates اور apply_updates کو اوور رائیڈ (override) کر دیتے ہیں۔ اگر آپ dnf-automatic.timer کے ساتھ ان میں سے کوئی ایک فعال کرتے ہیں تو کام دو مختلف رویوں کے ساتھ دو بار چلے گا، جو ایسا لگے گا جیسے آپ کی کنفیگریشن فائل کو نظر انداز کر دیا گیا ہے۔ صرف ایک ٹائمر فعال کریں اور چیک کریں:

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

مجھے کیسے معلوم ہوگا کہ کوئی چیز کب انسٹال ہوئی تھی؟

emit_via سیکشن [emitters] میں رپورٹنگ کو کنٹرول کرتا ہے۔ systemd کے تحت stdio ایمیٹر journal میں لکھتا ہے، جو کہ ایک قابل اعتماد آپشن ہے کیونکہ اس کے لیے کسی اور چیز کی تنصیب کی ضرورت نہیں ہوتی:

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 پر ہوتا ہے، جس کا مطلب ہے کہ ناکام رن (failed run) کی کوئی رپورٹ نہیں ملتی۔ اسے آن کریں۔ ایک ایسا پیچنگ سسٹم جو صرف اپنی کامیابیوں کا اعلان کرتا ہے، کسی بھی سسٹم کے نہ ہونے سے بدتر ہے، کیونکہ خاموشی کو صحت مند ہونے کی علامت سمجھ لیا جاتا ہے۔

dnf-automatic آپ کی سروسز کو ری اسٹارٹ نہیں کرتا

کسی پیکیج کو انسٹال کرنے سے ڈسک پر موجود فائلیں تبدیل ہو جاتی ہیں۔ جو پروسیس پہلے سے چل رہا ہوتا ہے وہ پرانا کوڈ میموری میں رکھتا ہے، لہذا پیچ شدہ لائبریری اس ڈیمن (daemon) کے لیے کچھ نہیں کرتی جو پچھلے مہینے شروع ہوا تھا۔ انسٹال شدہ اور مؤثر (effective) ہونے کے درمیان یہی فرق وہ وجہ ہے جس کی بنا پر غیر حاضر (unattended) پیچنگ کے لیے صرف انسٹالیشن پالیسی نہیں بلکہ ری اسٹارٹ پالیسی کی بھی ضرورت ہوتی ہے۔

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 ہوسٹ کے پیکیجز کو پیچ کرتا ہے اور امیج میں موجود یوزر لینڈ (userland) کو کبھی نہیں چھیڑتا، لہذا 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 پر اوپر بیان کردہ تمام چیزیں یکساں ہیں، بشمول configuration path اور unit names۔ دونوں errata شائع کرتے ہیں، لہذا upgrade_type = security کے پاس فلٹر کرنے کے لیے ڈیٹا موجود ہوتا ہے۔ پہلے بیان کردہ پرانا Rocky errata ان چند مقامات میں سے ایک ہے جہاں ان کا روزمرہ کا رویہ حقیقت میں مختلف ہوتا ہے، لہذا اگر سرور ابھی تک تیار نہیں ہوا ہے، تو اس کا موازنہ compatibility promise اور پرانے CPU کی سپورٹ کے ساتھ کریں جو ان دونوں کو الگ کرتے ہیں۔

CentOS Stream ایک استثنا ہے، اور یہ ایک مشکل استثنا ہے۔ Stream repositories میں کوئی updateinfo.xml نہیں ہوتا، لہذا security filter کبھی میچ نہیں کر سکتا اور ہر رن No security updates needed رپورٹ کرتا ہے۔ Stream پر، upgrade_type = default استعمال کریں اور تسلیم کریں کہ آپ ہر اپ ڈیٹ قبول کر رہے ہیں۔ Stream، RHEL سے آگے چلتا ہے، لہذا Rocky یا AlmaLinux کے مقابلے میں Stream باکس پر سیٹنگز زیادہ تبدیل ہوتی ہیں۔ یہ فرق پیکیجنگ کی غلطی نہیں بلکہ Red Hat کے 2020 کے اس فیصلے کا نتیجہ ہے جس میں CentOS کو RHEL کا rolling preview بنا دیا گیا، جو کہ وہی فیصلہ ہے جس نے Rocky Linux اور AlmaLinux کو وجود بخشا۔

Rocky 10 اور AlmaLinux 10 میں DNF5 استعمال ہوا ہے، جس نے چیزوں کے نام تبدیل کر دیے ہیں۔ اپ اسٹریم DNF5 دستاویزات کے مطابق ٹائمر dnf5-automatic.timer ہے، ڈیفالٹس /usr/share/dnf5/dnf5-plugins/automatic.conf میں موجود ہیں جبکہ آپ کے overrides اب بھی /etc/dnf/automatic.conf میں ہیں، download_updates اب 'no' کے بجائے 'yes' پر ڈیفالٹ ہوتا ہے، اور distro-sync کو بطور upgrade_type شامل کیا گیا ہے۔ ایڈوائزری کوئری 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 موجود ہوتا ہے۔ سیکیورٹی فلٹر کسی چیز سے میچ نہیں ہوا، یا تو اس لیے کہ زیر التواء (pending) کسی چیز میں کوئی ایڈوائزری شامل نہیں ہے یا اس لیے کہ ریپوزٹری کوئی ایڈوائزری ڈیٹا شائع نہیں کرتی۔

ایک سیٹنگ نظر انداز شدہ لگتی ہے۔ DNF، automatic.conf میں ڈیبگ لیول پر ایک نامعلوم آپشن لاگ کرتا ہے اور پھر ڈیفالٹ کا استعمال کرتا ہے، لہذا غلط ہجے والی کی (key) کچھ تبدیل نہیں کرتی اور کسی کو خبردار بھی نہیں کرتی۔ apply_update = yes لکھیں اور apply_updates، no پر ہی رہتا ہے، لہذا باکس ہمیشہ ڈاؤن لوڈ کرتا رہتا ہے اور کبھی انسٹال نہیں کرتا۔ کسی بھی ترمیم کے بعد، sudo systemctl start dnf-automatic.service چلائیں اور فائل پر بھروسہ کرنے کے بجائے جرنل پڑھیں۔

جاب دن میں دو بار چلتی ہے۔ دو ٹائمر فعال (enabled) ہیں۔ systemctl list-unit-files 'dnf-automatic*' دکھاتا ہے کہ کون سے، اور اضافی ٹائمرز ایسے فلیگز پاس کرتے ہیں جو آپ کی کنفیگریشن فائل کو اوور رائیڈ کر دیتے ہیں۔

کوئی میل موصول نہیں ہوتی۔ یا تو email ایمیٹر کے لیے پورٹ 25 پر کوئی چیز لسن (listen) نہیں کر رہی، یا send_error_messages ابھی بھی no ہے اور رپورٹ کرنے کے قابل واحد چیز ایک ایرر تھی۔

ایک پیچ شدہ (patched) سروس اب بھی پرانا ورژن رپورٹ کرتی ہے۔ ڈسک پر موجود فائل نئی ہے اور میموری میں موجود پروسیس پرانا ہے۔ dnf needs-restarting -s ان سروسز کے نام بتاتا ہے جنہیں ری سٹارٹ کرنے کی ضرورت ہے۔

FAQ

کیا dnf-automatic صرف Rocky Linux پر سیکیورٹی اپ ڈیٹس انسٹال کرتا ہے؟

صرف تب جب آپ upgrade_type = security کو /etc/dnf/automatic.conf میں سیٹ کریں، اور صرف تب جب آپ کی repositories errata metadata شائع کرتی ہوں۔ Rocky Linux اور AlmaLinux دونوں اسے شائع کرتے ہیں، لہذا فلٹر کے پاس موازنہ کرنے کے لیے advisories موجود ہوتی ہیں۔ ڈیفالٹ سیٹنگ upgrade_type = default ہے، جو apply_updates = yes ہونے پر ہر دستیاب اپ ڈیٹ انسٹال کر دیتی ہے۔

dnf-automatic یہ رپورٹ کیوں دیتا ہے کہ "No security updates needed, but 3 updates available"؟

DNF اس بات کا تعین repository سے updateinfo.xml پڑھ کر کرتا ہے کہ سیکیورٹی اپ ڈیٹ کیا ہے، جہاں ہر advisory ان پیکیجز کی فہرست دیتی ہے جو اسے ٹھیک کرتے ہیں۔ جب یہ metadata غائب یا پرانا ہو، تو سیکیورٹی فلٹر کسی چیز سے میچ نہیں کرتا جبکہ عام اپ ڈیٹس ابھی بھی باقی ہوتی ہیں، جس سے بالکل یہی لائن ظاہر ہوتی ہے۔ یہ CentOS Stream پر متوقع ہے، جو کوئی errata شائع نہیں کرتا۔ Rocky یا AlmaLinux پر، dnf updateinfo list --security کا موازنہ dnf check-update سے کریں اور یقینی بنائیں کہ آپ کا metadata تازہ ترین ہے۔

کیا dnf-automatic کرنل اپ ڈیٹ کے بعد میرے سرور کو ریبوٹ کرے گا؟

نہیں، جب تک آپ اسے ایسا کرنے کا نہ کہیں۔ reboot آپشن کا ڈیفالٹ never ہے۔ reboot = when-needed سیٹ کریں، تب رن صرف تب ریبوٹ کرے گا جب dnf needs-restarting -r کے پیچھے موجود چیک یہ پائے کہ kernel یا glibc جیسا کوئی بنیادی پیکیج بوٹ کے بعد تبدیل ہوا ہے۔ reboot = when-changed کسی بھی اپلائی شدہ اپ ڈیٹ کے بعد ریبوٹ کرتا ہے۔ دونوں 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 صرف پیکیجز انسٹال کرتا ہے اور وہیں رک جاتا ہے۔ یہ daemons کو دوبارہ شروع نہیں کرتا، اور یہ آپ کو کچھ بھی رپورٹ نہیں کرے گا جب تک کہ emit_via میں کوئی ایسا emitter نہ ہو جسے آپ واقعی پڑھتے ہیں۔ کم از کم emit_via کو stdio پر سیٹ کریں، send_error_messages کو آن کریں تاکہ ناکامیاں بھی رپورٹ ہوں، اور پیچ ونڈو کے بعد dnf needs-restarting -s چلائیں تاکہ ان سروسز کا پتہ چل سکے جو ابھی بھی پرانا کوڈ چلا رہی ہیں۔