Git-এ OpenVPN প্রোফাইল: কমিট করার আগে কী বাদ দিতে হবে

প্রোফাইল একসঙ্গে দুটি কাজ করে: এটি সংযোগের সেটিংস লিপিবদ্ধ করে এবং একটি কার্যকর পরিচয়পত্রের বান্ডেল বহন করে। ফাইলের এক্সটেনশন আপনাকে কিছুই বলে না যে আপনি কোনটি হাতে ধরে আছেন। এটি রিপোজিটরির অন্তর্গত বলে সিদ্ধান্ত নেওয়ার আগে ভেতরের বিষয়বস্তু পড়ুন।

নিচের ধাপগুলি ধরে নেয় একটি ক্লায়েন্ট টেমপ্লেট ভার্সন নিয়ন্ত্রণের জন্য বিবেচিত হচ্ছে। সেগুলি ক্রম অনুসারে চালান, এবং যা আপনি বাতিল করতে পারবেন না তা কমিট করার আগেই থামুন।

আপনি যে ফাইলটি স্টেজ করতে চলেছেন সেটি পড়ুন

প্রকৃত বাইট দিয়ে শুরু করুন, কারণ আলাদা ফাইলের প্রতি ইঙ্গিত করা প্রোফাইল সেগুলি ভেতরে ধারণ করা প্রোফাইলের থেকে সম্পূর্ণ আলাদা দেখায়। PEM ব্লক মার্কার এবং ca, cert, key, tls-auth ও tls-crypt নামের ইনলাইন ট্যাগ খুঁজুন, এবং একই অনুসন্ধান আপনাকে দুই ক্ষেত্রই দেখাবে। এনক্রিপ্ট করা প্রাইভেট কীও সংবেদনশীল উপাদান হিসেবেই গণ্য, আর শেয়ার করা tls-auth বা tls-crypt কী একটি পরিচয়পত্র, যদিও তা কোনো ব্যবহারকারীর পরিচয় নয়। প্রোফাইলের সঙ্গে স্টেজ করা সবকিছুর উপরও একই পর্যালোচনা প্রয়োগ করুন, যার মধ্যে আছে আর্কাইভ এবং এমন সেটআপ স্ক্রিপ্ট যা কোনো পরিচয়পত্র ফাইলের প্রতি ইঙ্গিত করে।

তারপর ওয়ার্কিং ট্রি নয়, স্টেজ করা সেটটির দিকে তাকান। git diff --cached দেখায় কমিটে আসলে কী থাকবে, এবং এই সিদ্ধান্তের জন্য কেবল সেই সংস্করণই প্রাসঙ্গিক।

রিপোজিটরি কী বিতরণ করতে পারবে তা ঠিক করুন

একটি টেমপ্লেট শেয়ার করা, পর্যালোচিত সেটিংস এবং নথিভুক্তির সময় একজন ব্যক্তি যা পান তার জন্য নামযুক্ত প্লেসহোল্ডার বহন করতে পারে। যা বহন করতে পারে না তা হল কার্যকর পরিচয়, কারণ রিপোজিটরি তাকে বিতরণ করে যে কেউ তা পড়তে পারে, অটোমেশনসহ। একটি ব্যক্তিগত রিপোজিটরি দর্শককে সংকুচিত করে, কিন্তু প্রতিটি পাঠক সেই পরিচয়পত্রের জন্য অনুমোদিত কি না সেই প্রশ্ন বদলায় না।

একটি ইগনোর নিয়ম ভবিষ্যতের সংযোজন প্রতিরোধ করে এবং ইতিমধ্যে লিপিবদ্ধ থাকা বিষয়ে কিছুই করে না। প্রথম কমিটের আগেই এই অসমতার কথা হজম করা উচিত, দশমটির পরে নয়। পরিকাঠামোর নাম ও ঠিকানা আলাদা একটি বিচার: সেগুলি প্রমাণীকরণের গোপন তথ্য নয়, তবে কোনো দল প্রকাশ করতে চায় তার চেয়ে বেশি ফাঁস করতে পারে। প্রতিটি লাইনকে পাসওয়ার্ড বা প্রকাশ্য বলে ভাগ করার বদলে সেই সিদ্ধান্ত স্পষ্টভাবে নিন।

উপাদানটি ইতিমধ্যে ইতিহাসে থাকলে

নতুন কমিটে লাইনটি সরানো যে কেউ এটি নিয়ে আসবে তার জন্য পুরনো সংস্করণ অক্ষত রেখে দেয়। প্রকাশকে সত্য বলে ধরুন: পরিচয়পত্রের ধরন শনাক্ত করুন, তারপর যে কর্তৃপক্ষ এটি বাতিল করতে পারে তাকে খুঁজুন। ক্লায়েন্ট সার্টিফিকেট বাতিল করা হয় এবং বাতিল তালিকা নতুন করে তৈরি হয়; শেয়ার করা নিয়ন্ত্রণ-চ্যানেল কী সার্ভারে এবং এটি ব্যবহার করা প্রতিটি ক্লায়েন্টে প্রতিস্থাপিত হয়।

দুটির প্রভাবের পরিধি খুব আলাদা, এবং শুরু করার আগে পরিকল্পনায় বলা উচিত আপনি কোনটি চালাচ্ছেন। git log --all -S 'BEGIN PRIVATE KEY'-এর মতো একটি অনুসন্ধান দিয়ে যে কমিট উপাদানটি এনেছে তা খুঁজে বের করুন, যাতে পরিচ্ছন্নতার পরিধি অনুমান নয়, জানা থাকে। সহকর্মীর ক্লোন বা ফোর্ক ইতিমধ্যে পুরনো অবজেক্টটি ধরে রাখতে পারে, সেই কারণেই বাতিল করা আগে এবং পরিচ্ছন্নতা পরে।

নিয়ন্ত্রণে আনার পরেই পরিচ্ছন্ন করুন

ইতিহাস নতুন করে লেখা আপনার সম্পাদিত কমিটের পরের প্রতিটি কমিট বদলে দেয়, তাই আগে রিপোজিটরির মালিক এবং এতে কাজ করা মানুষের সম্মতি দরকার। জোর করে পুশ করা কোনো মেরামত নয়; এটি নিজস্ব রোলব্যাক ঝুঁকিসহ একটি সমন্বয়মূলক ঘটনা। এটি সময় নির্ধারণ করুন, ব্যাকআপ নিন, এবং কখন ঘটবে তা দলকে জানান।

এরপর টুলের সারাংশে ভরসা না করে বর্তমান ট্রি এবং অবশিষ্ট ইতিহাস যাচাই করুন।

ফলাফলটি দুটি নিদর্শন হিসেবে রাখুন: শেয়ার করার জন্য নিরাপদ টেমপ্লেট, এবং নথিভুক্তি প্রক্রিয়ায় জারি করা পরিচয়পত্রের তালিকা। কোনোটিরই জন্য রিপোজিটরিতে কার্যকর পরিচয় বাস করতে হয় না।

এই বিভাজনই আসল সমাধান, এবং প্রোফাইল কমিট করতে চাওয়া পরের মানুষটিকেও এটি টিকে থাকবে।