میں نے اپنا نیٹ ورک ریکوری سرور بنایا ہے اور اب میرے پاس اپنے ہوم لیب پی سی پر انڈو بٹن ہے۔

کام کرنے والے ہوم لیب سرور پر آپریٹنگ سسٹم کو دوبارہ انسٹال کرنے اور دوبارہ بنانے میں پوری شام گزارنے کے لیے صرف ایک غلط کنفیگریشن تبدیلی کی ضرورت ہے۔ VMware ESXi ورچوئل مشینوں کے لیے راستہ فراہم کر سکتا ہے، لیکن فزیکل پی سی کا کیا ہوگا؟

USB ریکوری ٹولز کام کر سکتے ہیں، لیکن یہ پھر بھی اس بات پر منحصر ہے کہ آیا آپ کو صحیح ڈرائیو ملی اور ہارڈ ڈرائیو کو کلون کرنا یاد ہے۔ مفت اوپن سورس گھوسٹ (FOG) ایک بہت بہتر آپشن فراہم کرتا ہے۔ ایک خود میزبان امیجنگ سرور جو کمپیوٹر کو نیٹ ورک پر بوٹ کرنے کے لیے PXE کا استعمال کرتا ہے اور مرکزی طور پر مکمل ڈسک امیجز کو اسٹور کرتا ہے۔

ہم نے حقیقی ہارڈ ویئر کے قریب رکھنے سے پہلے VMware ورک سٹیشن ہائپر وائزر کے اندر ایک پروف آف تصور ورژن بنایا، ترتیب شدہ UEFI Linux Mint سسٹم کو پکڑا، اسے جان بوجھ کر مرمت سے باہر نقصان پہنچایا، اور 16 سیکنڈ سے بھی کم وقت میں ایک قیاس شدہ پی سی کو بحال کیا۔

ہم نے VMware کے اندر ایک پورا ریکوری نیٹ ورک بنایا ہے۔

الگ تھلگ VMnet نے FOG کے DHCP سرور کو فزیکل نیٹ ورک سے دور رکھا۔

میرے لیپ ٹاپ میں صرف 16 جی بی ریم ہے، لہذا میں اس سینڈ باکس سے نمٹنے کے لیے کمپیوٹنگ میں کافی نہیں ہوں۔ FOG سرور Ubuntu Server 24.04 LTS کو 2 vCPUs اور 2GB RAM کے ساتھ چلاتا ہے۔ میں نے VM کو 20GB vDisk دیا اور پھر اس کے بعد نصب ایک 80GB ڈرائیو شامل کی۔ /images میں نے اسے fstab کا استعمال کرتے ہوئے مستقل بنایا۔

sudo mount /dev/sdb1 /images
sudo nano /etc/fstab
LABEL=fog-images /images ext4 defaults 0 2

لینکس منٹ باکس نے ایک اضافی 4GB RAM کا استعمال کیا، پوری دو VM لیب کو کافی قابل انتظام 6GB پر رکھا۔

نیٹ ورکنگ کو ہارڈ ویئر سے تھوڑی زیادہ توجہ کی ضرورت ہے۔ میں نے VMnet7 کو صرف میزبان نیٹ ورک کے طور پر بنایا اور اس پر VMware کے DHCP سرور کو غیر فعال کر دیا۔ FOG سرور کے پاس پیکیج ڈاؤن لوڈز کے لیے ایک NAT اڈاپٹر اور VMnet7 سے منسلک دوسرا اڈاپٹر تھا۔ میں نے تفویض کیا۔ 192.168.77.2/24 دوسرے انٹرفیس کے طور پر، ens34. میں نے ونڈوز ورچوئل ہوسٹ اڈاپٹر کو اس پر سیٹ کیا: 192.168.77.1 لہذا میں اپنے لیپ ٹاپ سے FOG ڈیش بورڈ تک رسائی حاصل کرنے کے قابل تھا۔

FOG Preboot Execution Environment (PXE) کے ذریعے کام کرتا ہے۔ PXE کمپیوٹر کے فرم ویئر کو نیٹ ورک سے شروع کرنے کی اجازت دیتا ہے اس سے پہلے کہ OS سنبھالے اور سسٹم کو لوڈ کرے۔ میری لیب میں، Kea DHCP نے ایڈریس اور بوٹ سرور کی تفصیلات فراہم کیں، TFTP نے iPXE فراہم کی، جس نے میموری میں FOG کا امیجنگ ماحول شروع کیا، اور نیٹ ورک فائل سسٹم (NFS) نے ڈسک کی تصاویر کو منظم کیا۔

یہ نفٹی سیٹ اپ FOG کے لیے ایسی ڈرائیوز کو بازیافت کرنے کا ایک طریقہ ہے جو اب بوٹ نہیں ہوتی ہیں۔ یہی وجہ ہے کہ ہم VMnet7 نیٹ ورک استعمال کرتے ہیں۔ اس کی وجہ یہ ہے کہ اگر FOG نیٹ ورک الگ تھلگ نہیں ہے، تو PXE اپنے LAN پر DHCP سرور سے اپنا IP پتہ حاصل کرتا ہے۔

FOG 1.5.10.2254 نے سب کچھ ٹھیک انسٹال کیا، بشمول:

• ڈیش بورڈ

• ڈیٹا بیس

• سرٹیفکیٹ

• محفوظ کریں

• TFTP

• این ایف ایس

Kea DHCP ایک پریشان کن مسئلہ بن کر ختم ہوا۔ کنفیگریشن فائل درست طریقے سے انسٹال ہے، لیکن جب میں توثیق کمانڈ استعمال کرتا ہوں تو سروس نہیں کھلتی۔

sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf

مجھے Kea کے مسئلے کا جواب کرنل لاگ میں ملا، جہاں AppArmor کو Kea کی سیلف کنفیگریشن ڈائرکٹری کھولنے کی اجازت سے انکار کر دیا گیا تھا۔ فولڈر کے پاس محدود اجازتیں ہیں اور اس کا تعلق صرف درج ذیل فولڈرز سے ہے: _kea:_keaیہ سچ ہے یہاں تک کہ اگر ڈیمون کو جڑ کے طور پر شروع کیا گیا ہو۔ کنفیگریشن فائل کو خود پڑھنے کے قابل ہونے کے باوجود، AppArmor نے ملکیت میں مماثلت کی وجہ سے کام نہیں کیا۔ میں نے اسے چھوڑتے وقت جڑ کو مالک بنا کر حل کیا۔_kea اجازت یافتہ گروپس:

sudo chown root:_kea /etc/kea
sudo chmod 750 /etc/kea

ایک بار جب یہ مسئلہ حل ہو گیا، Kea 192.168.77.0/24 ذیلی نیٹ سے منسلک ens34.

ریکوری ڈرائیو کے بغیر UEFI PXE کیپچر منٹ

FOG نے ہر مفت گیگا بائٹ کو نقل کرنے کے بجائے استعمال شدہ بلاکس کو کاپی کیا۔

میرے لینکس منٹ وی ایم ٹیسٹ کلائنٹ کے پاس معقول سائز کی 32 جی بی ڈسک تھی۔ میں نے VMware کو UEFI استعمال کرنے کے لیے کنفیگر کیا اور VM کو ایک نیٹ ورک اڈاپٹر دیا اور اسے VMnet 7 پر سیٹ کیا۔ OS انسٹال کرنے کے بعد، میں نے اس اڈاپٹر کو عارضی طور پر VMnet8 NAT میں منتقل کر دیا تاکہ میں اپ ڈیٹس اور چند ایپلیکیشنز انسٹال کر سکوں، پھر اسے VMnet7 میں واپس منتقل کر دیا۔

کیپچر کرنے سے پہلے، میں نے ثبوت کے طور پر استعمال کرنے کے لیے کچھ فائلیں بنائیں کہ OS کو صحیح طریقے سے بحال کیا گیا تھا۔

• BEFORE-FOG-CAPTURE.txt

• recovery.txt کو روکیں۔

• منفرد مارکر "PHOENIX-7714”

• ریکوری فائل کا SHA-256 چیکسم۔

sha256sum recovery-proof.txt | tee recovery-proof.sha256

recovery-proof.txt پر لکھیں:

907147bbf68be8a7e86341bb5c1c989ba2d64d03085cfe0d05ccb312307b45e5  recovery-proof.txt

پھر میں نے Kea سے ایڈریس کی درخواست کرنے والے فرم ویئر کے ساتھ VM کو دوبارہ شروع کیا۔ Kea واپس آ گیا ہے 192.168.77.2 میں نے اسے بوٹ سرور کے طور پر استعمال کیا اور صحیح UEFI بوٹ فائلیں فراہم کیں۔ TFTP بھری ہوئی iPXE اور iPXE نے میری پسند کا FOG مینو کھول دیا۔ تیز رجسٹریشن اور انوینٹری. اس نے ریکوری ایجنٹ کو انسٹال کرنے کی ضرورت کے بغیر ورچوئل نیٹ ورک کارڈ کے میک ایڈریس کا استعمال کرتے ہوئے VM کو شامل کیا۔

آپ نے اس میزبان کو FOG ڈیش بورڈ میں لینکس امیج کے ساتھ منسلک کیا ہے۔ linux-mint-golden. ترتیب مندرجہ ذیل ترتیب دی گئی تھی:

• ایک واحد ڈسک کا استعمال کرتا ہے – سائز تبدیل کرنے کے قابل

• تمام پارٹیشنز منتخب ہیں۔

• پارٹ کلون بطور امیج مینیجر

• کمپریشن کے لیے Zstandard

میں نے "فوری” امیج کیپچر کا شیڈول بنایا اور نیٹ ورک نے VM کو دوبارہ بوٹ کیا۔ وہاں سے، FOG نے مینو کو چھوڑ دیا اور لانچ کیا۔ Partclone خود بخود

اصل ڈسک 32GB تھی، لیکن FOG نے خالی سیکٹرز کو کاپی نہیں کیا۔ Partclone جبکہ یہ اصل میں فائل سسٹم سے استعمال شدہ بلاکس کو پڑھتا ہے، FOG انہیں کمپریس کرتا ہے اور انہیں نیچے اسٹور کرتا ہے۔ /image/linux-mint-golden. تصویر کھینچنے کے عمل میں 7.12 GB/منٹ کی منتقلی کی شرح کے ساتھ ایک منٹ سے بھی کم وقت لگا اور صرف 14.5 GB استعمال ہوا۔ تیار شدہ تصویر نے صرف 3.0 GB استعمال کیا۔

میں نے بوٹ لوڈر کو توڑ دیا اور FOG نے سب کچھ واپس کر دیا۔

مشین ناقابل بوٹ سے 16 سیکنڈ میں درست طریقے سے پکڑی گئی۔

یہ ثابت کرنے کے لیے ریکوری کی ضرورت تھی کہ ریکوری سسٹم کام کر رہا ہے۔ لہذا، میں نے پہلے VM کو تباہ کرنا شروع کیا جیسے کہ وال پیپر کو تبدیل کرنا اور پروف فائلوں کو حذف کرنا۔ اس کے بعد ہم ایک ناکامی کی طرف بڑھے جس نے ٹکسال کو اپنی مرمت میں مدد کرنے سے روک دیا۔

findmnt یہ مجھے دکھایا /dev/sda1 چونکہ یہ FAT32 EFI سسٹم پارٹیشن نصب تھا، مجھے اسے منتقل کرنا پڑا۔ منٹ کا ڈیفالٹ UEFI لوڈر اس پر واقع تھا: /boot/efi/EFI/ubuntu فال بیک لوڈر پر قبضہ کر لیا گیا ہے۔ /boot/efi/EFI/BOOT. میں نے VM کے اندر دونوں ڈائریکٹریوں کا نام بدل دیا۔

sudo mv /boot/efi/EFI/ubuntu /boot/efi/EFI/ubuntu.broken
sudo mv /boot/efi/EFI/BOOT /boot/efi/EFI/BOOT.broken

پھر میں نے زیر التواء تحریروں کو فلش کیا اور دوبارہ شروع کیا۔ VMware کا UEFI فرم ویئر ناکام ہو گیا کیونکہ اسے مزید کام کرنے والا مقامی بوٹ لوڈر نہیں مل سکا۔ منٹ کو لانچ کرنے کے بجائے، میں نیٹ ورک اڈاپٹر کے ذریعے FOG پر واپس آیا۔ اب آپ کا VM اس طرح کرپٹ ہو گیا ہے کہ عام طور پر آپ کو انسٹالیشن میڈیا تلاش کرنے کی کوشش میں مایوسی ہو جاتی ہے۔

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

اگلے PXE بوٹ پر، FOG نے زیر التواء تعیناتی کا پتہ لگایا اور باقاعدہ مینو کو چھوڑ دیا۔ پارٹیشن ٹیبل اور EFI پارٹیشن کو دوبارہ بنانے کے بعد، Partclone میں نے منٹ کے فائل سسٹم، ایپلیکیشنز، سیٹنگز، اور فائلوں کو اس سے بحال کیا: linux-mint-golden ویڈیو

پوری تعیناتی 16 سیکنڈ سے بھی کم وقت میں مکمل ہو گئی۔ میں نے کبھی بھی Mint ISO، USB ریکوری، دوبارہ انسٹال کرنے کا عمل یا VMware سنیپ شاٹ کو دھوکہ نہیں دیا ہے۔ ٹکسال مقامی ڈسک سے بوٹ کیا گیا اور ہر چیز کو بحال کیا گیا جیسے کچھ ہوا ہی نہیں تھا۔

ثبوت فائل BEFORE-FOG-CAPTURE.txt اور recovery-proof.txt یہ واپس آ گیا اور دونوں .broken bootloader ڈائریکٹریز ختم ہو گئیں۔

ذخیرہ شدہ چیکسم نے سب سے مضبوط ثبوت فراہم کیا۔

cd ~/Desktop/FOG-Recovery-Test && sha256sum -c recovery-proof.sha256

یہ ہے جو واپس کیا گیا ہے:

recovery-proof.txt: ok

تمام اصل UEFI ڈائرکٹریز کو بحال کر دیا گیا، فائل کے مواد کے عین مطابق مماثلت ہوئی، اور ٹکسال کو عام طور پر بوٹ کیا گیا۔ آپ کے ڈیسک ٹاپ کو بالکل اسی طرح دوبارہ ظاہر ہوتا دیکھ کر جیسے آپ نے اسے پکڑا تھا، FOG کو ایک حقیقی کالعدم بٹن کی طرح محسوس ہوتا ہے۔

FOG ایک انڈو بٹن ہے، لیکن بیک اپ نہیں۔

مکمل ڈسک کی بازیافت تیز، تباہ کن، اور صرف آپ کی آخری تصویر کی طرح موجودہ ہے۔

FOG کو بجا طور پر ایک انڈو بٹن کے طور پر بیان کیا گیا ہے، لیکن اس کے لیے باقاعدہ بیک اپ سے کہیں زیادہ انفراسٹرکچر کی ضرورت ہوتی ہے۔ صرف میرے تصور کا ثبوت درکار ہے:

• اوبنٹو سرور

• الگ الگ تصاویر محفوظ کریں۔

• DHCP کام کر رہا ہے۔

• TFTP

• iPXE

• این ایف ایس

• ویب ڈیش بورڈ

• علیحدہ نیٹ ورک یا VLAN

اس پر عمل درآمد کچھ نہیں ہے جو آپ چند منٹوں میں کر سکتے ہیں۔ امیجنگ خود بھی خلل ڈالنے والی ہے۔ FOG کے لیے کلائنٹ کو اپنے ماحول میں ریبوٹ کرنے کی ضرورت ہوتی ہے تاکہ فائل سسٹم کو پکڑا جا سکے۔ اس کا مطلب ہے کہ انسٹال شدہ آپریٹنگ سسٹم آف لائن ہونا چاہیے۔

پروف آف تصور لیب بھی ایک مثالی ماحول تھا۔ ایک حقیقی گھریلو لیب کو ڈرائیوروں، فرم ویئر، نیٹ ورک اڈاپٹر اور محفوظ بوٹ کو سنبھالنے کی ضرورت ہے۔ لہذا، 16 سیکنڈ کی تعیناتی بہترین سینڈ باکس نتیجہ ہے۔ عملی طور پر، جسمانی مشین کی بحالی کا انحصار ڈسک کی رفتار، تصویر کے سائز، اور نیٹ ورک بینڈوتھ پر ہوتا ہے۔

FOG بھی ایک اضافی بیک اپ نہیں ہے۔ FOG ایک کیپچر کو شیڈول کر سکتا ہے، لیکن اسی تفویض کردہ تصویر کی ایک اور کیپچر موجودہ فائل کو اوور رائٹ کر دے گی۔ تاہم، آپ ویب ڈیش بورڈ میں تصویر کا نام تبدیل کرکے دستی ورژن کی تاریخ بنا کر اس مسئلے پر قابو پا سکتے ہیں۔

جی ہاں حدود ہیں، لیکن میری رائے میں، وہ انعامات کو نہیں مٹاتے ہیں۔ ایک FOG سرور متعدد سسٹمز کے لیے معروف اچھی تصاویر رکھ سکتا ہے، اور سمجھوتہ کرنے والے کلائنٹس کو کام کرنے والے آپریٹنگ سسٹم کی ضرورت بھی نہیں ہے۔ آپ کو صرف ایک ورکنگ نیٹ ورک فرم ویئر اور FOG ریکوری سرور تک رسائی کی ضرورت ہے تاکہ ان احمقانہ تبدیلیوں کو واپس کیا جا سکے جنہوں نے آپ کی مشین کو پہلی جگہ توڑ دیا۔

ہم فزیکل ہوسٹس کے لیے FOG کو رول آؤٹ کریں گے تاکہ اسے ہمارے نیٹ ورک پر استعمال کیا جا سکے، لیکن ہم ایک OpenWRT راؤٹر پر بھی کام کریں گے جو عام ایڈریس، گیٹ وے، DNS، اور PXE آپشنز 66 اور 67 فراہم کرتا ہے۔

یہ تجربہ اس بات کا تعین کرنا تھا کہ آیا FOG کو میرے گھر کی لیب میں جگہ ملے گی۔ ایک ناقابل بوٹ لینکس پی سی کو 16 سیکنڈ میں بحال کرنے کے بعد، میں نے اسے جانے کا فیصلہ کیا۔