کیا آپ کی VPN بائنری اسی CPU کے لیے بنی ہے؟ ELF ہیڈر پڑھیں

دونوں فائلیں 32 بٹ ہیں اور ان میں سے صرف ایک آپ کے بورڈ پر چلتی ہے۔ Intel کے لیے ELF32 بلڈ اور ARM کے لیے ELF32 بلڈ کلاس فیلڈ پر متفق ہیں اور ہر اہم چیز پر مختلف ہیں۔ 32 بٹ آپشن پیش کرنے والا ڈاؤن لوڈ صفحہ آپ کو تقریباً کچھ نہیں بتایا جب تک آپ اس فائل کا ہیڈر نہ پڑھیں جو آپ نے واقعی ڈاؤن لوڈ کی۔ اس کا نام بدلنے سے ایک بھی ہدایت نہیں بدلتی۔

کلاس اور مشین مختلف سوالات کے جواب دیتے ہیں

کلاس فیلڈ بتاتی ہے کہ فائل 32 بٹ یا 64 بٹ ڈھانچے استعمال کرتی ہے۔ مشین فیلڈ اس ہدایات کے مجموعے کا نام دیتی ہے جس کے لیے فائل کمپائل ہوئی۔ صرف پہلی پڑھنا ہی وہ طریقہ ہے جس سے x86 بلڈ مکمل طور پر قابلِ اعتماد دکھنے والے فائل نام کے ساتھ ARM بورڈ پر پہنچ جاتی ہے۔ دونوں قدریں ایک ہی کمانڈ سے آتی ہیں، اس لیے ایک کو چھوڑ دینا اتنا آسان ہے۔

یہی الجھن 64 بٹ لیبلوں پر بھی لاگو ہوتی ہے، جہاں aarch64 اور x86-64 ایک لفظ کا سائز بانٹتے ہیں اور کوئی ہدایت نہیں۔ ایک 64 بٹ ڈاؤن لوڈ کی فہرست دینے والا وینڈر صفحہ اپنی بلڈ بیان کرتا ہے، آپ کی مشین نہیں۔ صفحے کے کالم سرخی کے بجائے فائل کا ہیڈر جانچیں۔

readelf -h ./vendor-vpn
readelf -l ./vendor-vpn | head -20
file ./vendor-vpn

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

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

انسٹالر چلانے سے پہلے ہیڈر پڑھیں

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

مشین فیلڈ کا موازنہ چل رہے سسٹم کی پیکیج آرکیٹیکچر سے کریں، بورڈ کے مارکیٹنگ نام سے نہیں۔ 32 بٹ یوزر لینڈ چلانے والے 64 بٹ CPU کو 32 بٹ بلڈ چاہیے، اور یہی تفصیل طے کرتی ہے کہ کون سا ڈاؤن لوڈ مقامی ہے۔ بورڈ کی صلاحیت پابندی نہیں؛ نصب شدہ یوزر لینڈ پابندی ہے۔

dpkg --print-architecture
uname -m
getconf LONG_BIT

پہلی کمانڈ بتاتی ہے کہ سسٹم کس آرکیٹیکچر کے لیے پیکیجز نصب کرتا ہے، اور وہی قدر میل کھانی چاہیے۔ باقی دو کرنل اور لفظ کے سائز بیان کرتی ہیں، اور کثیر آرکیٹیکچر تنصیب میں وہ یوزر لینڈ سے مختلف ہو سکتی ہیں۔

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

انٹرپریٹر جانچیں، صرف آرکیٹیکچر نہیں

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

خرابی کا پیغام بتاتا ہے کہ آپ کس صورت میں ہیں، اور دونوں صورتوں کو خلط ملط کرنا آسان ہے۔ فارمیٹ یا آرکیٹیکچر کی مسترد ہونا غائب فائل یا انٹرپریٹر سے مختلف ہے، اور ان میں سے صرف ایک دوسرا پیکیج نصب کرنے سے درست ہوتی ہے۔

readelf -l ./vendor-vpn | grep -A1 INTERP
ls -l /lib64/ld-linux-x86-64.so.2

پہلی کمانڈ بائنری کے طلب کردہ انٹرپریٹر کا راستہ دکھاتی ہے۔ دوسری جانچتی ہے کہ وہ راستہ موجود ہے یا نہیں، جو غلط بلڈ کو غائب لوڈر سے الگ کرتی ہے۔

ناقابلِ اعتماد بائنری پر انحصار کی فہرست نہ چلائیں، کیونکہ کچھ عمل درآمد وہ فائل چلا سکتے ہیں جس کا وہ معائنہ کرتے ہیں۔ معائنہ صرف پڑھنے کے لیے رکھیں اور غیر معاون بلڈ کو شروع کرنے کے لیے لوڈر سمبولک لنکس شامل کرنے کے لالچ کا مقابلہ کریں۔

حقائق ہاتھ میں رکھ کر بلڈ مانگیں

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

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