FreeBSD سکیورٹی اپ ڈیٹس: base system اور packages

FreeBSD سکیورٹی اپ ڈیٹس کو کیسے سنبھالتا ہے

FreeBSD سکیورٹی اپ ڈیٹس کے لیے دو الگ tools استعمال کرتا ہے، کیونکہ FreeBSD server دو الگ حصوں پر مشتمل ہوتا ہے۔ base system، یعنی kernel اور وہ userland جو release کے ساتھ شامل تھا، کو freebsd-update کے ذریعے patch کیا جاتا ہے۔ اس کے اوپر install کی گئی ہر چیز package ہوتی ہے، اور packages کو pkg کے ذریعے patch کیا جاتا ہے۔ ایک command چلانے اور دوسری کو چھوڑ دینے سے machine کا نصف حصہ unpatched رہتا ہے، اور system پر کوئی چیز آپ کو یہ نہیں بتائے گی۔

SSD Nodes، FreeBSD images فراہم نہیں کرتا۔ ہمارے plans Linux چلاتے ہیں۔ اس کے باوجود یہ post یہاں موجود ہے، کیونکہ readers کا تعلق مکمل طور پر مشترک ہے: جو لوگ ہمارے Ubuntu اور Debian servers چلاتے ہیں، وہ firewall پر یا وراثت میں ملنے والی ایک machine پر FreeBSD بھی چلاتے ہیں۔ یہ split patching model وہ حصہ ہے جس سے Linux admin عموماً الجھتا ہے، اس لیے اسی حصے کو تحریر میں واضح کرنا ضروری ہے۔ ذیل میں موجود ہر command، advisory format اور support date کو August 2026 میں FreeBSD security page اور project کی manual pages کے مطابق verify کیا گیا تھا۔

Commands سے پہلے ایک بات۔ FreeBSD base system میں sudo install نہیں کرتا۔ یہاں ہر چیز کے لیے root درکار ہے۔ su - استعمال کریں، یا پہلے packages سے sudo یا doas install کریں۔

بنیادی نظام اور packages الگ دنیائیں ہیں

Ubuntu میں، apt پوری مشین کا انتظام کرتا ہے۔ kernel، openssl، nginx اور آپ کے اپنے tools سب ایک ہی tool سے .deb files کے طور پر آتے ہیں، اور apt upgrade ان سب کو ایک ساتھ منتقل کرتا ہے۔

FreeBSD اس نظام کو دو حصوں میں تقسیم کرتا ہے۔ بنیادی نظام ایک unit کے طور پر build اور ایک unit کے طور پر version کیا جاتا ہے: 15.1-RELEASE-p3 ایک واحد number ہے جو kernel، C library، sshd اور /usr/lib میں موجود OpenSSL copy کا احاطہ کرتا ہے۔ اس میں سے کوئی چیز pkg سے نہیں آتی۔ باقی سب کچھ /usr/local کے تحت رہتا ہے، ports tree سے build کیے گئے binary package کے طور پر آتا ہے، اور اس کا اپنا version ہوتا ہے۔

اس لیے ایک ہی box میں OpenSSL کی دو copies ہو سکتی ہیں: /usr/lib میں بنیادی copy، جسے صرف freebsd-update patch کرتا ہے، اور /usr/local/lib میں package copy، جسے صرف pkg patch کرتا ہے۔ کوئی program ان میں سے وہی copy استعمال کرتا ہے جس کے ساتھ اسے link کیا گیا ہو، اور packages سے install کیا گیا software عموماً package copy کے ساتھ link ہوتا ہے۔ ایک copy کو patch کرنے سے دوسری copy پر کوئی اثر نہیں پڑتا۔

یہ تین commands بتاتی ہیں کہ آپ کی موجودہ صورتِ حال کیا ہے:

freebsd-version -u
freebsd-version -k
uname -r

freebsd-version -u installed userland کا patch level دکھاتا ہے۔ freebsd-version -k installed kernel کا patch level دکھاتا ہے، اور freebsd-version(1) واضح کرتا ہے کہ یہ uname کے برابر کیوں نہیں ہے: "اگر نیا kernel install کیا گیا ہو لیکن system کو ابھی reboot نہ کیا گیا ہو تو freebsd-version نئے kernel کا version اور patch level دکھائے گا"۔ uname -r اس وقت چلنے والے kernel کو دکھاتا ہے۔ اس کے علاوہ freebsd-version -r بھی ہے، جو چلنے والا kernel دکھاتا ہے لیکن "environment variables سے متاثر نہیں ہوتا"۔ یہ jail کے اندر اہم ہے، جہاں UNAME_r اکثر کسی اور value پر set ہوتا ہے۔

سیکیورٹی ایڈوائزریز اور Errata نوٹس

FreeBSD Security Team کی طرف سے دو قسم کے نوٹس جاری ہوتے ہیں، اور دونوں کے معنی مختلف ہیں۔

Security Advisory میں base system کی سیکیورٹی کمزوری شامل ہوتی ہے۔ اس کا identifier FreeBSD-SA-26:55.elf جیسا ہوتا ہے: حروف SA، دو ہندسوں پر مشتمل سال، اس سال کے اندر بڑھتا ہوا نمبر، اور پھر متاثرہ component۔ FreeBSD-SA-26:52.if_wg اور FreeBSD-SA-26:50.kqueue دونوں 2026-07-29 کو شائع ہوئے تھے۔ مکمل فہرست FreeBSD advisories page پر موجود ہے۔

Errata Notice میں درستگی یا استحکام کا ایسا مسئلہ شامل ہوتا ہے جسے release branch میں شامل کرنا ضروری ہو، لیکن اس کا سیکیورٹی سے تعلق نہ ہو۔ اس کی ساخت بھی یہی ہوتی ہے، مگر SA کی جگہ EN ہوتا ہے: FreeBSD-EN-26:19.zfs، FreeBSD-EN-26:18.tzdata۔ time zone data update اس کی عام مثال ہے۔ فرسودہ time zone data سے کوئی آپ پر حملہ نہیں کر سکتا، لیکن fix لاگو کرنے تک آپ کے timestamps غلط رہیں گے۔ Errata کی فہرست FreeBSD errata notices page پر موجود ہے۔

دونوں اقسام کے نوٹس Security Officer کی PGP (pretty good privacy) key سے signed ہوتے ہیں اور security.FreeBSD.org پر archive کیے جاتے ہیں۔ دونوں آپ کی machine تک freebsd-update کے ذریعے پہنچتے ہیں۔

یہ وہ حصہ ہے جو Linux admins کو اکثر الجھاتا ہے۔ دونوں میں سے کوئی بھی packages کا احاطہ نہیں کرتا۔ سیکیورٹی صفحہ یہ بات واضح طور پر کہتا ہے: FreeBSD Ports Collection کے مسائل "FreeBSD VuXML document میں الگ سے شامل کیے جاتے ہیں"۔ nginx package میں موجود remote vulnerability کو کبھی بھی SA number نہیں ملے گا۔ اگر آپ صرف advisory feed monitor کرتے ہیں تو آپ کو اس کے بارے میں کبھی معلوم نہیں ہوگا۔

FreeBSD کی security update کے بارے میں کیسے اطلاع حاصل کی جائے؟

شامل ہونے والی mailing list freebsd-security-notifications ہے۔ اس کی moderation ہوتی ہے اور اس پر پیغامات کم تعداد میں آتے ہیں۔ اس پر advisories اور errata notices خود جاری کیے جاتے ہیں۔ lists.freebsd.org پر subscribe کریں۔

freebsd-announce کی بھی moderation ہوتی ہے، اور اس پر release announcements کے ساتھ advisories بھی آتی ہیں۔ اگر آپ ہر چیز کے لیے ایک ہی list چاہتے ہیں تو یہ موزوں ہے۔ freebsd-security discussion list ہے۔ اس کا مطالعہ مفید ہے، لیکن patch کی ضرورت معلوم کرنے کے لیے یہی list استعمال نہیں کی جاتی۔

ان تمام lists پر صرف base system کی خبریں آتی ہیں۔ Package vulnerabilities ای میل کے ذریعے کبھی نہیں آتیں۔ ان کے بارے میں command چلا کر معلوم کیا جاتا ہے۔

pkg audit اور اس کے پیچھے موجود database

VuXML، یعنی Vulnerabilities and Exposures Markup Language، FreeBSD project کا ports اور packages میں موجود security مسائل کا ریکارڈ ہے۔ ہر entry میں متاثرہ package، vulnerable versions کی ranges، CVE (common vulnerabilities and exposures) identifiers اور مختصر وضاحت درج ہوتی ہے۔ مکمل database VuXML index میں دیکھا جا سکتا ہے، جہاں اسے package، CVE یا تاریخ کے لحاظ سے sort کیا گیا ہے۔

pkg audit اسے پڑھنے والا tool ہے:

pkg audit -F

-F checking سے پہلے database کی تازہ copy fetch کرتا ہے۔ اسے ہر بار استعمال کریں۔ -F کے بغیر آپ اسی copy کے خلاف matching کر رہے ہوتے ہیں جو machine پر پہلے سے موجود ہے۔ یہ copy کئی ماہ پرانی ہو سکتی ہے، اس لیے clean result کا کوئی مطلب نہیں رہتا۔ یہ command ہر installed package version کا ہر VuXML entry سے موازنہ کرتا ہے، ہر match کو اس کے CVE numbers اور VuXML page کے link کے ساتھ دکھاتا ہے، پھر count line کے ذریعے بتاتا ہے کہ کتنے installed packages میں کتنے مسائل ملے۔

pkg-audit(8) کے دو مزید flags جاننا مفید ہے۔ pkg audit -r "prints packages that depend on vulnerable packages and are thus potentially vulnerable as well"۔ اس سے معلوم ہوتا ہے کہ vulnerable library اہم کیوں ہے، کیونکہ installed چھ چیزیں اس سے link ہو سکتی ہیں۔ pkg audit -R یہی result JSON یا کسی اور machine-readable format میں دکھاتا ہے۔ یہی output monitoring check کو دیا جاتا ہے۔

pkg package /usr/local/etc/periodic/security/410.pkg-audit پر ایک periodic script install کرتا ہے۔ یہ daily security check کے حصے کے طور پر چلتا ہے اور result root کو mail کرتا ہے۔ /etc/periodic.conf میں ایک line دیکھ کر تصدیق کریں کہ یہ enabled ہے:

daily_status_security_pkgaudit_enable="YES"

یہ daily mail اس چیز کے سب سے قریب ہے جو FreeBSD میں Ubuntu میں unattended-upgrades کا معمول فراہم کرتی ہے، اور یہی بنیادی فرق ہے: unattended-upgrades آپ کے سوتے وقت fix install کرتا ہے، جبکہ pkg audit صرف بتاتا ہے کہ fix درکار ہے۔ pkg audit reports۔ یہ کبھی patch نہیں کرتا۔ stock FreeBSD system پر آپ کی اجازت کے بغیر کوئی security update install نہیں ہوتی۔

کمزور package کو درست کرنا

pkg update
pkg upgrade

FreeBSD package repositories میں صرف security کے لیے مخصوص pocket موجود نہیں ہے۔ Ubuntu صرف noble-security سے packages حاصل کر سکتا ہے اور باقی ہر package کو اس کی موجودہ حالت میں چھوڑ سکتا ہے۔ FreeBSD میں اس کے مساوی کوئی طریقہ نہیں ہے، اس لیے ایک کمزور package کو درست کرنے کا مطلب repository کی جانب سے اس وقت پیش کیا جانے والا version، اور اس کے ساتھ منتقل ہونے والی dependencies، قبول کرنا ہے۔ Package patching کو background job نہیں بلکہ ایک change کے طور پر plan کریں۔

آپ کس repository branch پر ہیں، اس سے طے ہوتا ہے کہ fix آپ تک کتنی جلد پہنچے گا۔ Default quarterly branch ہے، جسے handbook صرف non-feature updates قبول کر کے "زیادہ قابل پیش گوئی اور مستحکم تجربہ" فراہم کرنے والی branch قرار دیتا ہے۔ Latest branch ہر چیز کا نیا ترین version لیتی ہے۔ اس لیے جب pkg audit -F کسی package کو vulnerable قرار دے اور pkg upgrade کہے کہ کرنے کے لیے کچھ نہیں ہے، تو fix ابھی آپ کی branch تک نہیں پہنچا۔ اسی طریقۂ کار کی وجہ سے یہ الجھن پیدا ہوتی ہے۔

کسی machine کو latest branch پر منتقل کرنے کے لیے system کے ساتھ آنے والی repository file کی copy بنائیں اور اس copy میں ترمیم کریں:

mkdir -p /usr/local/etc/pkg/repos
cp /etc/pkg/FreeBSD.conf /usr/local/etc/pkg/repos/FreeBSD.conf

Copy کی url line میں quarterly کو latest سے تبدیل کریں، پھر نیا catalogue حاصل کرنے کے لیے pkg update -f چلائیں۔ File کو copy کریں، repository کا نام حافظے سے نہ لکھیں: /etc/pkg/FreeBSD.conf کے اندر موجود نام وہی ہے جسے آپ کا system حقیقت میں استعمال کرتا ہے، اور /usr/local/etc/pkg/repos کے تحت موجود file صرف اسی repository کو override کرتی ہے جس کا نام اس سے بالکل مطابقت رکھتا ہو۔

بنیادی نظام کے patches لاگو کرنا

freebsd-update fetch
freebsd-update install

fetch آپ کی موجودہ release کے لیے patches download کرتا ہے اور ان files کی فہرست دکھاتا ہے جنہیں یہ تبدیل کرے گا۔ جب کرنے کے لیے کچھ نہ ہو تو یہ No updates needed to update system to 15.1-RELEASE-p3. دکھا کر بند ہو جاتا ہے۔ جب کوئی کارروائی درکار ہو تو یہ آخر میں آپ کو install command چلانے کی ہدایت دیتا ہے۔ جب تک آپ freebsd-update install نہ چلائیں، کچھ بھی لاگو نہیں ہوتا، اس لیے fetch کسی بھی وقت چلانا محفوظ ہے۔

freebsd-update(8) ALPHA، BETA، RC اور RELEASE versions کے لیے binary updates فراہم کرتا ہے، لیکن PRERELEASE، STABLE یا CURRENT کے لیے نہیں۔ اگر آپ stable/15 track کرتے ہیں تو آپ source سے build کرتے ہیں، اور اس tool کے پاس آپ کے لیے کچھ نہیں ہے۔

download خودکار بنائیں اور install دستی طور پر کریں۔ handbook میں /etc/crontab کے لیے درج command یہ ہے:

@daily                                  root    freebsd-update cron

freebsd-update cron 1 اور 3600 seconds کے درمیان بے ترتیب مدت تک انتظار کرتا ہے، پھر بالکل اسی طرح updates download کرتا ہے جیسے fetch کرتا ہے، اور جب کوئی update زیرِ التوا ہو تو root کو mail بھیجتا ہے۔ اس بے ترتیب انتظار کا مقصد یہ ہے کہ internet پر موجود ہر FreeBSD machine ایک ہی second میں update mirrors سے رابطہ نہ کرے۔

output میں دو چیزیں لوگوں کو الجھن میں ڈالتی ہیں۔ src component not installed, skipped ایسے server پر معمول کی بات ہے جس میں source tree موجود نہ ہو، اور یہ error نہیں ہے۔ components کا مجموعہ /etc/freebsd-update.conf میں موجود Components line سے متعین ہوتا ہے، اور اختیارات src، world اور kernel ہیں۔

اگر install میں مسئلہ پیدا ہو جائے تو freebsd-update rollback حالیہ طور پر install کیے گئے updates کو uninstall کرتا ہے۔ ZFS root پر آپ پہلے boot environment بنا کر مزید بہتر تحفظ حاصل کر سکتے ہیں:

bectl create pre-patch
freebsd-update fetch install

اگر patched system boot نہ ہو تو loader menu سے پرانا boot environment منتخب کریں، اور آپ پچھلی حالت میں واپس آ جائیں گے۔ یہی متبادل راستہ ZFS کو root filesystem کے طور پر چلانے کی عملی وجوہات میں سے ایک ہے، اور جب تک دونوں environments میں فرق پیدا نہ ہو، یہ تقریباً کوئی اضافی disk space استعمال نہیں کرتا۔

کیا میری FreeBSD release اب بھی supported ہے؟

ہر release ایک مقررہ مدت تک supported رہتی ہے۔ یہ مدت security page پر branch table کی صورت میں شائع کی جاتی ہے۔ August 2026 تک اس table میں یہ معلومات ہیں:

• releng/15.1، یعنی 15.1-RELEASE، 31 March 2027 تک
• releng/15.0، یعنی 15.0-RELEASE، 30 September 2026 تک
• releng/14.4، یعنی 14.4-RELEASE، 31 December 2026 تک
• stable/15، 31 December 2029 تک
• stable/14، 30 November 2028 تک

Point releases کے لیے مدت مختصر ہوتی ہے۔ 15.0-RELEASE کی support اس post کے لکھے جانے کے تقریباً سات ہفتے بعد ختم ہو جاتی ہے، کیونکہ 15.1 release ہو چکی ہے اور اس کی support مدت مقرر ہو گئی ہے۔ Stable branches کئی سال تک برقرار رہتی ہیں، اور یہ source branches ہوتی ہیں جنہیں freebsd-update serve نہیں کرتا۔

اپنے سسٹم کی version freebsd-version -u سے دیکھیں اور اسے table سے ملائیں۔ freebsd-update بھی آپ کو warning دیتا ہے۔ تاریخ قریب آنے پر fetch یہ output دکھاتا ہے:

WARNING: FreeBSD 15.0-RELEASE is approaching its End-of-Life date.
It is strongly recommended that you upgrade to a newer
release within the next 2 months.

تاریخ گزرنے کے بعد warning میں WARNING: FreeBSD 15.0-RELEASE HAS PASSED ITS END-OF-LIFE DATE. شامل ہو جاتا ہے۔ Unsupported release کام کرتی رہتی ہے، لیکن اسے security advisories موصول نہیں ہوتیں۔ اس کا مطلب ہے کہ base system میں آنے والی اگلی vulnerability ہمیشہ آپ کی ذمہ داری رہے گی۔

نئی release پر منتقل ہونے کے لیے پہلے freebsd-update -r 15.1-RELEASE upgrade، پھر freebsd-update install، اس کے بعد reboot، پھر دوبارہ freebsd-update install، پھر pkg-static upgrade -f تاکہ ہر package کو نئی libraries کے مطابق reinstall کیا جا سکے، اور آخر میں freebsd-update install چلائیں۔ Handbook کے مطابق تین کے بجائے صرف دو install phases بھی ہو سکتے ہیں، اس بات پر منحصر ہے کہ library version numbers میں کوئی تبدیلی ہوئی ہے یا نہیں۔ Maintenance window مقرر کریں، اور شروع کرنے سے پہلے FreeBSD 15 server setup guide پڑھیں۔

ریبوٹ کریں یا service restart کافی ہے؟

FreeBSD ایک موازنے سے اس کا جواب دیتا ہے:

freebsd-version -k
uname -r

freebsd-version -k disk پر موجود kernel ہے۔ uname -r memory میں موجود kernel ہے۔ مختلف strings کا مطلب ہے کہ نیا kernel install ہو چکا ہے، لیکن آپ اسے چلا نہیں رہے؛ اس لیے reboot کریں۔ یکساں strings کا مطلب ہے کہ patch نے kernel کو تبدیل نہیں کیا، اور reboot کرنے سے کوئی فائدہ نہیں ہوگا۔

userland patch کے لیے ہر وہ چیز restart کریں جو patched code استعمال کرتی ہے۔ /usr/lib میں موجود base OpenSSL کی اصلاح سے ایسے sshd پر کوئی اثر نہیں پڑتا جو تین ہفتے پہلے start ہوا تھا اور اب بھی اپنی address space میں پرانی library map کیے ہوئے ہے۔ disk پر موجود file نئی ہے۔ running process نیا نہیں ہے۔

service sshd restart

یہی اصول packages پر بھی لاگو ہوتا ہے۔ pkg upgrade disk پر موجود binary کو replace کرتا ہے، جبکہ running process پرانی binary کو کھولے رکھتا ہے؛ اس لیے service nginx restart وہ مرحلہ ہے جو fix کو مؤثر بناتا ہے۔

base system میں Debian کے needrestart کے برابر کوئی نظام نہیں ہے، اس لیے کوئی prompt ظاہر نہیں ہوتا اور کوئی فہرست بھی برقرار نہیں رکھی جاتی۔ یا تو معلوم رکھیں کہ کون سی services patched library سے link کرتی ہیں، یا base libraries کو متاثر کرنے والے ہر patch کے بعد reboot کریں۔ ایسے server پر جس کی configuration version control میں ہو، reboot ایک معمول کی کارروائی ہے۔ یہ اس غلط یقین سے کہیں کم مہنگا ہے کہ patch نافذ ہو چکا ہے، حالانکہ ایسا نہیں ہے۔

مشین پر jails چل رہی ہوں تو patching

ایک jail میزبان kernel کا اشتراک کرتی ہے، اس لیے kernel advisory میزبان کا مسئلہ ہوتی ہے اور اس box کی ہر jail اس سے متاثر ہوتی ہے۔ میزبان کو patch کرکے reboot کریں؛ اس کے بعد kernel سے متعلق کام سب jails کے لیے مکمل ہو جاتا ہے۔ ہر jail کے اندر userland ایک الگ installation ہوتی ہے اور اس کا اپنا patch level ہوتا ہے۔ میزبان سے freebsd-version -j <jail> اس کی رپورٹ فراہم کرتا ہے۔ jail کے اندر موجود packages بھی الگ ہوتے ہیں، اور pkg -j <jail> audit -F jail میں داخل ہوئے بغیر ان کا audit کرتا ہے۔ shared kernel اور الگ userland کی یہی ساختی تقسیم وہی بنیادی فرق ہے جو jails کا Docker containers سے موازنہ متعین کرتی ہے۔

Ubuntu کا ترجمہ

ہر FreeBSD عادت کا ایک متبادل موجود ہے، اس لیے آپ یہ معمول دونوں سمتوں میں اپنا سکتے ہیں۔

• بنیادی سسٹم کے patches: پہلے freebsd-update fetch، پھر freebsd-update install۔ Ubuntu میں apt update && apt upgrade استعمال کریں، جو بنیادی سسٹم اور باقی تمام اجزا کو ایک ہی بار update کرتا ہے۔
• Third-party software: FreeBSD میں pkg update && pkg upgrade۔ Ubuntu میں دوبارہ apt۔
• معلوم vulnerability کی جانچ: FreeBSD میں pkg audit -F۔ Ubuntu 24.04 میں اس کے قریب ترین command pro security-status ہے، جو installed packages کے لیے security updates دکھاتا ہے، جن میں Expanded Security Maintenance کا مواد بھی شامل ہے۔
• خودکار installation: Ubuntu میں unattended-upgrades آپ کے لیے security updates install کرتا ہے۔ FreeBSD میں اس کے مساوی کوئی built-in طریقہ موجود نہیں، اس لیے freebsd-update cron advisories download کرکے email کرتا ہے اور آپ updates دستی طور پر install کرتے ہیں۔
• Advisory feed: freebsd-security-notifications میں FreeBSD-SA اور FreeBSD-EN items شامل ہوتے ہیں۔ ubuntu-security-announce میں Ubuntu Security Notices شامل ہوتے ہیں۔
• Vulnerability database: FreeBSD ports اور packages کے لیے VuXML استعمال ہوتا ہے۔ Ubuntu packages کے لیے Ubuntu CVE tracker استعمال ہوتا ہے۔
• Reboot کی جانچ: FreeBSD میں freebsd-version -k کو uname -r کے مقابل چلا کر کریں۔ Ubuntu میں /var/run/reboot-required کی موجودگی دیکھیں۔
• Support window: FreeBSD security page پر branch table دیکھیں۔ Ubuntu میں release schedule اور pro security-status دیکھیں۔

دونوں systems پر بنیادی routine یکساں ہے: feed کو subscribe کریں، مقررہ schedule کے مطابق audit چلائیں، پھر فیصلہ کریں کہ کیا install کرنا ہے اور restart کب کرنا ہے۔ FreeBSD میں آپ کو routine کے دوسرے حصے کا فیصلہ خود کرنا پڑتا ہے، کیونکہ وہ یہ کام آپ کے لیے نہیں کرتا۔ Linux اور FreeBSD کا server platform کے طور پر وسیع تر تقابل میں بتایا گیا ہے کہ workload کو ایک system سے دوسرے system میں منتقل کرنے پر مزید کیا تبدیلیاں آتی ہیں۔

FAQ

کیا freebsd-update میرے packages کو بھی patch کرتا ہے؟

نہیں۔ freebsd-update صرف base system کا احاطہ کرتا ہے، یعنی kernel اور وہ userland جو release کے ساتھ جاری کیا گیا تھا۔ /usr/local کے تحت install کیا گیا software packages سے آتا ہے، اور اسے pkg upgrade کے ذریعے patch کیا جاتا ہے۔ یہ معلوم کرنے کے لیے pkg audit -F چلائیں کہ install کیے گئے کون سے packages میں معلوم vulnerabilities موجود ہیں، کیونکہ base advisories میں ان کا کبھی ذکر نہیں ہوتا اور security mailing lists بھی ان کا اعلان نہیں کرتیں۔

مجھے کیسے معلوم ہو کہ FreeBSD update کے لیے reboot ضروری ہے؟

freebsd-version -k کا موازنہ uname -r سے کریں۔ پہلی command disk پر install کیے گئے kernel کو دکھاتی ہے، جس میں وہ kernel بھی شامل ہے جو ابھی لکھا گیا ہو لیکن ابھی boot نہ ہوا ہو۔ دوسری command اس kernel کو دکھاتی ہے جو اس وقت چل رہا ہے۔ مختلف strings کا مطلب ہے کہ reboot ضروری ہے۔ یکساں strings کا مطلب ہے کہ patch صرف userland کے لیے تھا، اس لیے اس کے بجائے متاثرہ services کو restart کریں، مثلاً service sshd restart، کیونکہ running process restart ہونے تک پرانی library کو mapped رکھتا ہے۔

Security Advisory اور Errata Notice میں کیا فرق ہے؟

Security Advisory، جیسے FreeBSD-SA-26:55.elf، base system میں موجود security vulnerability کو درست کرتا ہے۔ Errata Notice، جیسے FreeBSD-EN-26:18.tzdata، correctness یا stability کے ایسے مسئلے کو درست کرتا ہے جس کا security impact نہیں ہوتا، مثلاً پرانا time zone data۔ دونوں میں year، colon، sequence number، component کا pattern استعمال ہوتا ہے۔ دونوں Security Officer کے دستخط شدہ ہوتے ہیں اور freebsd-update کے ذریعے فراہم کیے جاتے ہیں، اور دونوں میں ports یا packages سے install کیے گئے software کا احاطہ نہیں ہوتا۔

کیا FreeBSD کے لیے unattended-upgrades کا کوئی متبادل ہے؟

Base system میں نہیں۔ freebsd-update cron زیرِ التوا base patches download کرتا ہے اور root کو mail بھیجتا ہے، لیکن انہیں کبھی install نہیں کرتا۔ وہ periodic script جسے pkg install کرتا ہے، روزانہ pkg audit چلاتی ہے اور نتیجہ mail کرتی ہے، مگر یہ بھی کبھی upgrade نہیں کرتی۔ Unattended installation آپ کو خود cron job کے ذریعے بنانی ہوگی، اور چونکہ FreeBSD package upgrade صرف security-only backport کے بجائے newest version لیتا ہے، اس لیے زیادہ تر administrators mail پڑھ کر packages دستی طور پر install کرتے ہیں۔

میں کیسے جانچوں کہ میری FreeBSD release اب بھی supported ہے؟

اپنے userland version کے لیے freebsd-version -u چلائیں، پھر اس کا موازنہ FreeBSD security page پر موجود supported branch table سے کریں۔ Point releases کے support windows مختصر ہوتے ہیں: August 2026 تک، 15.0-RELEASE کی support 30 September 2026 کو ختم ہو جاتی ہے، جبکہ 15.1-RELEASE 31 March 2027 تک جاری رہتی ہے۔ تاریخ قریب آنے پر freebsd-update fetch آپ کو خبردار کرتا ہے، اور تاریخ گزرنے کے بعد یہ ایک line دکھاتا ہے جس میں لکھا ہوتا ہے کہ release HAS PASSED ITS END-OF-LIFE DATE۔ اس کے بعد مزید advisories آپ پر لاگو نہیں ہوتیں۔