SSD Nodes Learn
تعلیمی Matt Connorتحریر: Matt Connor · اپ ڈیٹ شدہ 2026-07-25

Ubuntu 24.04 پر unattended-upgrades بطورِ افتراض فعال ہے؟

Ubuntu Server 24.04 پر unattended-upgrades موجود ہوتا ہے مگر 20auto-upgrades اسے فعال کرتا ہے۔ Automatic-Reboot بطورِ افتراض false رہتا ہے اور dry run سے پتہ چلتا ہے کہ کیا انسٹال ہوگا۔

خودکار سیکیورٹی اپڈیٹس کو ترتیب دینا کیوں بہترین ہے

ایک ایسا سرور جس میں پیچز نہیں لگائے گئے وہ انٹرنیٹ پر سب سے آسان ہدف ہے۔ چھوٹے سرورز میں زیادہ تر خلاف ورزیاں کوئی چالاکی نہیں ہوتیں؛ یہ صرف ایک پرانے پیکیج میں موجود ایک معروف خامی ہوتی ہے جسے مالک نے کبھی اپڈیٹ نہیں کیا۔ Ubuntu ایک ایسا ٹول فراہم کرتا ہے جو یہ کام خود بخود کرتا ہے: unattended-upgrades شیڈول کے مطابق خود بخود سیکیورٹی اپڈیٹس انسٹال کرتا ہے، بغیر آپ کے لاگ ان کیے۔ یہ VPS پر دستیاب سب سے سستا سیکیورٹی فائدہ ہے، اور Ubuntu پر اسے ترتیب دینے میں صرف چند منٹ لگتے ہیں۔

یہ ٹول جان بوجھ کر محتاط انداز میں بنایا گیا ہے۔ بطورِ افتراض یہ صرف سیکیورٹی اپڈیٹس لگاتا ہے، ہر پیکیج اپ گریڈ نہیں، کیونکہ ایک سیکیورٹی پیچ کا خطرہ کم ہوتا ہے اور اسے بغیر جائزہ لیے اپنانا بہتر ہے، جبکہ فیچر اپ گریڈ آپ کے انحصار کرنے والے رویے کو تبدیل کر سکتا ہے۔ یہ افتراضی ترتیب زیادہ تر سرورز کے لیے درست ہے، اور یہ رہنمائی اسی کو برقرار رکھتی ہے جبکہ آپ کو وہ چند ترتیبات بتاتی ہے جنہیں تبدیل کرنا بہتر ہے۔

مرحلہ 1: اسے انسٹال اور فعال کریں

Ubuntu 24.04 پر یہ پیکیج اکثر موجود ہوتا ہے لیکن ہمیشہ فعال نہیں ہوتا۔ اسے انسٹال کریں اور آن کریں:

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

dpkg-reconfigure پرامپٹ ایک ہاں یا نہ کا سوال پوچھتا ہے کہ آیا مستحکم اپڈیٹس خود بخود ڈاؤن لوڈ اور انسٹال کی جائیں۔ ہاں میں جواب دیں۔ یہ وہ فائل لکھتا ہے جو روزانہ کے کام کو آن کرتی ہے:

cat /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

پہلی لائن روزانہ پیکیج کی فہرست کو ریفریش کرتی ہے؛ دوسری روزانہ unattended upgrade چلاتی ہے۔ دونوں کو 1 پر سیٹ کرنے کا مطلب ہے کہ مشین ہر روز سیکیورٹی اپڈیٹس کی جانچ کرتی اور انہیں لاگو کرتی ہے، ایک systemd timer پر، آپ کی طرف سے بغیر کسی مزید کارروائی کے۔

مرحلہ 2: فیصلہ کریں کہ کیا خود بخود لاگو ہوگا

پالیسی /etc/apt/apt.conf.d/50unattended-upgrades میں موجود ہے۔ اسے کھولیں اور اوپری حصے کے قریب Allowed-Origins بلاک کو دیکھیں:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};

-security لائنیں وہ ہیں جو اہم ہیں، اور وہ بطورِ افتراض فعال ہیں۔ یہ محتاط پالیسی ہے: سیکیورٹی اپڈیٹس اندر آتی ہیں، عام فیچر اپڈیٹس آپ کے لیے چھوڑ دی جاتی ہیں تاکہ آپ انہیں اپنی مرضی سے خود لاگو کریں۔ آپ تمام اپڈیٹس کو خود بخود لاگو کرنے کے لیے "${distro_id}:${distro_codename}-updates" origin لائن شامل کر سکتے ہیں، لیکن ایک ایسے سرور کے لیے جو آپ کی اہمیت رکھنے والی کوئی چیز ہوسٹ کرتا ہے، صرف سیکیورٹی پیچز کو خود بخود لینا زیادہ محفوظ افتراض ہے۔ جب تک آپ کی کوئی مخصوص وجہ نہ ہو، اسے جیسے بھیجا گیا ہے ویسے ہی چھوڑ دیں۔

مرحلہ 3: ری بوٹ کو سنبھالیں

کچھ اپڈیٹس، جیسے کرنل یا ایک کور لائبریری، ری بوٹ کے بعد ہی مکمل اثر دکھاتی ہیں۔ unattended-upgrades آپ کے سرور کو ری بوٹ نہیں کرے گا جب تک آپ اسے ایسا کرنے نہ کہیں، جس کا مطلب ہے کہ پیچ شدہ کرنل استعمال نہ ہوئے رہ سکتا ہے جب تک آپ اتفاق سے اسے ری اسٹارٹ نہ کریں۔ فیصلہ کریں کہ آپ اسے کیسے سنبھالنا چاہتے ہیں، اور اسے 50unattended-upgrades میں واضح طور پر سیٹ کریں:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

یہ صبح چار بجے سرور کو ری بوٹ کرتا ہے جب، اور صرف اس وقت، کوئی اپڈیٹ اس کی ضرورت ہو۔ ایک ایسے واحد VPS پر جس میں فیل اوور کے لیے کوئی کلسٹر نہیں ہے، کرنل فکسز پر اپ ڈیٹ رہنے کے لیے صبح کا ایک مختصر ری بوٹ عام طور پر درست تبدیلی ہے۔ اگر آپ کا سرور کوئی ایسی چیز چلاتا ہے جسے کبھی اچانک ری اسٹارٹ نہیں ہونا چاہیے، تو ری بوٹ کو بند رکھیں اور /var/run/reboot-required کی جانچ کرنے کے بعد خود ری بوٹ کرنے کی عادت ڈالیں۔

مرحلہ 4: ثابت کریں کہ یہ کام کرتا ہے

یہ جاننے کے لیے کہ آیا کام چلتا ہے ایک دن کا انتظار نہ کریں۔ ایک dry run ٹرگر کریں جو بغیر کچھ تبدیل کیے یہ بتائے کہ کیا لاگو ہوتا:

sudo unattended-upgrade --dry-run --debug

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

cat /var/log/unattended-upgrades/unattended-upgrades.log

وہ لاگ "کیا میرا سرور واقعی خود کو پیچ کر رہا ہے" کا جواب ہے۔ اگر یہ شیڈول کے مطابق سیکیورٹی پیکیجز انسٹال ہوتے دکھا رہا ہے، تو کام درست چل رہا ہے۔

یہ کہاں فٹ بیٹھتا ہے

خودکار اپڈیٹس ایک مضبوط سرور کی ایک پرت ہیں، پوری چیز نہیں۔ یہ معروف خامیوں کو باقی رہنے سے روکتے ہیں، لیکن یہ اس بات سے کوئی تعلق نہیں رکھتے کہ کون لاگ ان ہو سکتا ہے یا کیا ظاہر ہے۔ انہیں صرف کلید والے SSH ہارڈننگ کے ساتھ جوڑیں تاکہ فرنٹ ڈور پر brute-force نہ کیا جا سکے، ایک default-deny UFW فائر وال تاکہ صرف آپ کی پسند کی چیزیں قابلِ رسائی ہوں، اور غیر مراعات یافتہ سروس صارفین تاکہ ایک سمجھوتہ ہوئی ایپ پورے سسٹم پر قبضہ نہ کر سکے۔ پیچنگ آپ کی معروف خامیوں کو بند کرتی ہے؛ دیگر پرتیں ان خامیوں سے ہونے والے نقصان کو محدود کرتی ہیں جنہیں آپ نہیں جانتے۔

FAQ

کیا unattended-upgrades ہر اپڈیٹ لاگو کرتا ہے یا صرف سیکیورٹی اپڈیٹس؟

بطورِ افتراض، صرف سیکیورٹی اپڈیٹس۔ /etc/apt/apt.conf.d/50unattended-upgrades میں Allowed-Origins بلاک -security origins کو فعال کرتا ہے اور عام فیچر اپڈیٹس آپ کے لیے چھوڑ دیتا ہے تاکہ آپ انہیں خود لاگو کریں۔ یہ جان بوجھ کر کیا گیا ہے: سیکیورٹی پیچز کم خطرہ والے ہوتے ہیں اور انہیں خود بخود لینا بہتر ہے، جبکہ فیچر اپ گریڈز رویے کو تبدیل کر سکتے ہیں، اس لیے زیادہ تر سرورز کو محتاط افتراض پر قائم رہنا چاہیے۔

کیا خودکار اپڈیٹس میرے سرور کو ری بوٹ کریں گے؟

صرف اگر آپ انہیں کہیں۔ کنفگ میں Unattended-Upgrade::Automatic-Reboot "true" اور ایک Automatic-Reboot-Time سیٹ کریں، اور سرور اس وقت ری بوٹ ہوگا جب کوئی اپڈیٹ اس کی ضرورت ہو، مثلاً کرنل پیچ کے بعد۔ بند چھوڑنے پر، پیچ شدہ کرنل آپ کے خود ری بوٹ کرنے تک انتظار کرتا ہے؛ جاننے کے لیے کہ کوئی ری بوٹ زیرِ التواء ہے، /var/run/reboot-required چیک کریں۔

میں کیسے چیک کروں کہ خودکار اپڈیٹس واقعی چل رہی ہیں؟

یہ دیکھنے کے لیے کہ ابھی کیا لاگو ہوتا، بغیر کچھ تبدیل کیے sudo unattended-upgrade --dry-run --debug چلائیں، اور پچھے چلانے کے ریکارڈ کے لیے /var/log/unattended-upgrades/unattended-upgrades.log پڑھیں؛ ہر خودکار انسٹالیشن /var/log/apt/history.log میں بھی درج ہوتی ہے۔ اگر لاگ روزانہ کے شیڈول پر سیکیورٹی پیکیجز انسٹال ہوتے دکھا رہا ہے، تو ٹائمر کام کر رہا ہے۔ اگر dry run No packages found that can be upgraded unattended پرنٹ کرتا ہے، تو یا تو سب کچھ پہلے ہی اپ ڈیٹ ہے یا آپ کی اجازت شدہ origins سیکیورٹی ریپوزٹری سے مماثل ہونے کے لیے بہت تنگ ہیں۔

کیا unattended-upgrades میرے سرور کو محفوظ رکھنے کے لیے کافی ہے؟

نہیں، لیکن یہ ایک ضروری پرت ہے۔ یہ معروف کمزوریوں کو غیر پیچ شدہ حالت میں رہنے سے روکتا ہے، جو خلاف ورزی کی سب سے عام قسم کو روکتا ہے، لیکن یہ رسائی یا نمائش کو کنٹرول نہیں کرتا۔ واقعی توڑنے میں مشکل سرور کے لیے اسے SSH ہارڈننگ، ایک default-deny فائر وال، اور کم سے کم مراعات والے سروس صارفین کے ساتھ ملائیں۔

#unattended-upgrades#ubuntu-24-04#security#updates#hardening