کیا پرانا openfortivpn .deb آپ کے Raspberry Pi کے لیے موزوں ہے؟

فورم کا جواب آپ کو مکمل فائل نام دیتا ہے، اور نام حل جیسا لگتا ہے: ایک .deb، ایک کمانڈ، ہو گیا۔ وہ سٹرنگ دراصل پیکیج ورژن، CPU آرکیٹیکچر اور وہ ڈسٹری بیوشن سوٹ انکوڈ کرتی ہے جس کے خلاف اسے اس دن بنایا گیا تھا جس دن کسی نے پوسٹ لکھی۔ ان تینوں میں سے کوئی بھی آپ کی میز پر رکھے بورڈ کو خودکار طور پر بیان نہیں کرتا۔ پرانا ڈاؤن لوڈ ایک مشین کی حالت کا اسنیپ شاٹ ہے، آپ کے لیے انسٹالیشن پلان نہیں۔

فائل نام خاموشی سے کیا پن کرتا ہے

openfortivpn_1.17.0-1_armhf.deb جیسا نام دائیں سے بائیں پڑھیں۔ لاحقہ وہ آرکیٹیکچر ہے جس کے لیے بائنری کمپائل ہوئی، درمیانی فیلڈ اپ اسٹریم اور پیکیجنگ ریویژن ہے، اور مضمر چوتھا فیلڈ اس سوٹ کی لائبریری سیٹ ہے جس میں یہ بنایا گیا۔

64-بٹ Raspberry Pi OS انسٹال پر سسٹم آرکیٹیکچر arm64 ہے، اس لیے dpkg -i آرکیٹیکچر کی عدم مطابقت کی وجہ سے armhf پیکیج مسترد کرتا ہے۔ جہاں multiarch انسٹال ممکن بناتا ہے وہاں بھی، بائنری اسی ریلیز کی لائبریری ورژنز کی توقع کرتی ہے جس کے خلاف یہ بنی، اور نیا بیس سسٹم وہ اب فراہم نہ کرے۔ نتیجہ ایک انسٹال شدہ پیکیج ہے جس کا ایکزی کیوٹ ایبل شروع نہیں ہوتا، اور یہی وہ ناکامی ہے جسے لوگ عام طور پر خود کلائنٹ کے خراب ہونے سے غلط تعبیر کرتے ہیں۔

بورڈ کا ARM ڈیوائس ہونا ARM پیکیج کو موزوں نہیں بناتا۔ آرکیٹیکچر ایک محور ہے؛ ریلیز اور ABI دوسرے دو ہیں، اور وہ آزادانہ ناکام ہوتے ہیں۔

ڈاؤن لوڈ لنک مانگنے سے پہلے ڈسٹری بیوشن سے پوچھیں

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

cat /etc/os-release
dpkg --print-architecture
apt-cache policy openfortivpn

ورژن اور ریپوزٹری نام والی امیدوار لائن کا مطلب ہے کہ ڈسٹری بیوشن کے پاس اس سسٹم کے لیے پہلے سے بلڈ ہے۔ امیدوار کا نہ ہونا، یا ایسے سوٹ سے امیدوار آنا جسے آپ استعمال کرنے کا ارادہ نہیں رکھتے تھے، آپ کے ماخذوں کے بارے میں معلومات ہے، اس بارے میں نہیں کہ سافٹ ویئر کہیں موجود ہے۔

اگر میٹا ڈیٹا ریفریش ناکام ہو تو اس ناکامی کو پیکیج کے سوال سے الگ رکھیں۔ نام کا حل، ریپوزٹری ٹرانسپورٹ، غائب Release دستخط اور زندگی کے آخر میں موجود سوٹ—سب کلائنٹ کے شامل ہونے سے پہلے apt update توڑ دیتے ہیں۔ ماخذ درست کرنا VPN کلائنٹ چننے سے مختلف کام ہے، اور دونوں کو ملانا ہی وہ طریقہ ہے جس سے لوگ موجودہ سسٹم کو پرانی ریلیز کی طرف اشارہ کرتے ہیں۔

apt کیا تصدیق کرتا ہے، اور ڈاؤن لوڈ شدہ فائل کیا حاصل نہیں کرتی

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

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

پرانی ہدایت کو چلتا رکھنے کے لیے دستخط کی خرابیوں کو دبانا یا TLS تصدیق بند کرنا عمل کا وہ واحد حصہ ہٹا دیتا ہے جو کچھ جانچ رہا تھا۔ اس کے بجائے ناکام ہونے والی جانچ بحال کریں۔

کلائنٹ انسٹال کریں، پھر کنکشن کو الگ ڈیبگ کریں

جب برقرار رکھا گیا امیدوار موجود ہو، اسے عام جائزہ شدہ ٹرانزیکشن کے ذریعے انسٹال کریں اور پیکیج مینیجر کو ریکارڈ کرنے دیں کہ اس نے کیا کیا۔

اگر تعیناتی کو واقعی اپ اسٹریم بلڈ درکار ہو تو پروجیکٹ کی موجودہ بلڈ ہدایات پر عمل کریں اور اسے ایسے سافٹ ویئر کے طور پر لیں جو اب آپ برقرار رکھتے ہیں: ڈویلپمنٹ پیکیجز، pkg-config، TLS لائبریری کے ہیڈر اور PPP ڈیمون حقیقی انحصار ہیں، اور وہ ہٹانے کا طریقہ کار بھی جو آپ کو بعد میں درکار ہوگا۔

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

وہ منصوبہ جو پرانے فائل نام کی جگہ لینا چاہیے

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

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

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