Git میں OpenVPN پروفائل: commit سے پہلے کیا ہٹانا ہے

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

نیچے دیے گئے مراحل یہ فرض کرتے ہیں کہ کلائنٹ ٹیمپلیٹ کو ورژن کنٹرول کے لیے زیر غور لیا جا رہا ہے۔ انہیں ترتیب سے چلائیں، اور جو آپ منسوخ نہیں کر سکتے اسے commit کرنے سے پہلے رک جائیں۔

وہ فائل پڑھیں جو آپ انڈیکس میں رکھنے والے ہیں

اصل بائٹس سے شروع کریں، کیونکہ الگ فائلوں کا حوالہ دینے والا پروفائل انہیں اندر رکھنے والے سے بالکل مختلف دکھتا ہے۔ PEM بلاک کے نشانات اور ca, cert, key, tls-auth اور tls-crypt نامی ان لائن ٹیگز تلاش کریں، اور وہی جانچ آپ کو دونوں صورتیں دکھا دے گی۔ خفیہ کردہ نجی کلید اب بھی حساس مواد شمار ہوتی ہے، اور مشترکہ tls-auth یا tls-crypt کلید اسناد ہے اگرچہ وہ کسی صارف کی شناخت نہ ہو۔ وہی جائزہ ہر اس چیز پر لگائیں جو پروفائل کے ساتھ انڈیکس میں رکھی جاتی ہے، بشمول وہ محفوظ شدہ فائلیں اور سیٹ اپ اسکرپٹس جو اسناد کی فائل کا حوالہ دیتے ہیں۔

پھر کام کرنے والے درخت کے بجائے انڈیکس میں رکھا گیا مجموعہ دیکھیں۔ git diff --cached دکھاتا ہے کہ commit میں واقعی کیا ہوگا، اور اسی فیصلے کے لیے صرف وہی ورژن اہم ہے۔

فیصلہ کریں کہ ذخیرہ کیا تقسیم کر سکتا ہے

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

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

اگر مواد پہلے ہی تاریخ میں موجود ہے

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

دونوں کا اثر وسیع پیمانے پر مختلف ہے، اور منصوبے کو شروع کرنے سے پہلے بتانا چاہیے کہ آپ کون سا چلا رہے ہیں۔ git log --all -S 'BEGIN PRIVATE KEY' جیسی تلاش سے وہ commit تلاش کریں جس نے مواد شامل کیا، تاکہ صفائی کا دائرہ اندازے کے بجائے معلوم ہو۔ ساتھی کا کلون یا فورک پہلے سے پرانی شے رکھ سکتا ہے، اسی لیے منسوخی پہلے اور صفائی بعد میں آتی ہے۔

قابو میں لانے کے بعد ہی صفائی کریں

تاریخ دوبارہ لکھنا آپ کے ترمیم کردہ commit کے بعد کے ہر commit کو بدل دیتا ہے، اس لیے پہلے ذخیرے کے مالک اور اس میں کام کرنے والے لوگوں کی رضامندی درکار ہے۔ زبردستی push مرمت نہیں؛ یہ اپنی واپسی کے خطرے کے ساتھ ایک ہم آہنگی کا واقعہ ہے۔ اسے شیڈول کریں، بیک اپ لیں، اور ٹیم کو بتائیں کہ کب ہوگا۔

اس کے بعد، آلے کے خلاصے پر بھروسا کرنے کے بجائے موجودہ درخت اور باقی تاریخ کی تصدیق کریں۔

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

یہی تقسیم اصل حل ہے، اور پروفائل commit کرنے کا خواہش مند اگلا شخص گزرنے کے بعد بھی یہ قائم رہتی ہے۔