Git में OpenVPN प्रोफ़ाइल: कमिट करने से पहले क्या हटाएँ

प्रोफ़ाइल एक साथ दो काम करते हैं: वे कनेक्शन सेटिंग दर्ज करते हैं, और वे काम करने योग्य क्रेडेंशियल का बंडल ले जाते हैं। फ़ाइल का एक्सटेंशन आपको यह नहीं बताता कि आपके हाथ में इनमें से कौन है। यह तय करने से पहले कि वह किसी रिपॉज़िटरी की है, सामग्री पढ़ें।

नीचे दिए गए चरण मानते हैं कि किसी क्लाइंट टेम्पलेट पर वर्ज़न नियंत्रण के लिए विचार किया जा रहा है। उन्हें क्रम से चलाएँ, और जो आप निरस्त नहीं कर सकते उसे कमिट करने से पहले रुकें।

जिस फ़ाइल को आप स्टेज करने वाले हैं उसे पढ़ें

असली बाइट्स से शुरू करें, क्योंकि अलग फ़ाइलों का संदर्भ देने वाला प्रोफ़ाइल उन्हें भीतर रखने वाले से बिलकुल अलग दिखता है। PEM ब्लॉक मार्कर और ca, cert, key, tls-auth तथा tls-crypt नाम वाले इनलाइन टैग खोजें, और वही पास आपको दोनों स्थितियाँ दिखा देगा। एन्क्रिप्ट की गई निजी कुंजी अब भी संवेदनशील सामग्री मानी जाती है, और साझा tls-auth या tls-crypt कुंजी क्रेडेंशियल है, भले ही वह किसी उपयोगकर्ता की पहचान न हो। वही समीक्षा उस सब पर लगाएँ जो प्रोफ़ाइल के साथ स्टेज किया जाता है, जिसमें वे अभिलेख और सेटअप स्क्रिप्ट शामिल हैं जो किसी क्रेडेंशियल फ़ाइल का संदर्भ देते हैं।

फिर कार्यशील ट्री नहीं, स्टेज किया गया सेट देखें। git diff --cached दिखाता है कि कमिट में वास्तव में क्या होगा, और इस निर्णय के लिए केवल वही संस्करण मायने रखता है।

तय करें कि रिपॉज़िटरी क्या वितरित कर सकती है

एक टेम्पलेट साझा, समीक्षित सेटिंग और नामित प्लेसहोल्डर ले जा सकता है, उस सबके लिए जो किसी व्यक्ति को नामांकन के समय मिलता है। जो वह नहीं ले जा सकता वह उपयोग योग्य पहचान है, क्योंकि रिपॉज़िटरी उन सबको वितरित होती है जो उसे पढ़ सकते हैं, और स्वचालन भी उनमें शामिल है। निजी रिपॉज़िटरी दर्शकों को सीमित करती है, पर यह प्रश्न नहीं बदलती कि क्या हर पाठक उस क्रेडेंशियल के लिए अधिकृत है।

अनदेखा नियम भविष्य के जोड़ों को रोकता है और जो पहले से दर्ज है उस पर कुछ नहीं करता। इस असमानता को पहले कमिट से पहले आत्मसात करना चाहिए, दसवें के बाद नहीं। अधोसंरचना के नाम और पते एक अलग निर्णय हैं: वे प्रमाणीकरण के रहस्य नहीं हैं, पर वे उससे अधिक उजागर कर सकते हैं जितना कोई टीम प्रकाशित करना चाहती है। हर पंक्ति को पासवर्ड या सार्वजनिक में बाँटने के बजाय वह निर्णय स्पष्ट रूप से लें।

अगर सामग्री पहले से इतिहास में है

नए कमिट में पंक्ति हटाना पुराने संस्करण को उस हर व्यक्ति के लिए अछूता छोड़ देता है जो उसे खींचता है। उजागर को वास्तविक मानें: क्रेडेंशियल का प्रकार पहचानें, फिर वह प्राधिकरण खोजें जो उसे अमान्य कर सकता है। क्लाइंट प्रमाणपत्र निरस्त होता है और निरस्तीकरण सूची फिर से बनाई जाती है; साझा नियंत्रण-चैनल कुंजी सर्वर पर और उसका उपयोग करने वाले हर क्लाइंट पर बदली जाती है।

दोनों का प्रभाव-दायरा बहुत अलग है, और योजना में शुरू करने से पहले बताया जाना चाहिए कि आप कौन सा चला रहे हैं। git log --all -S 'BEGIN PRIVATE KEY' जैसी खोज से वह कमिट खोजें जिसने सामग्री भीतर लाई, ताकि सफ़ाई का दायरा अनुमानित नहीं बल्कि ज्ञात हो। सहकर्मी का क्लोन या कोई फ़ोर्क पहले से पुरानी वस्तु रख सकता है, इसीलिए निरसन पहले और सफ़ाई बाद में आती है।

नियंत्रण के बाद ही सफ़ाई करें

इतिहास फिर से लिखना उस कमिट के बाद के हर कमिट को बदल देता है जिसे आप संपादित करते हैं, इसलिए पहले रिपॉज़िटरी के स्वामी और उसमें काम करने वाले लोगों की सहमति चाहिए। ज़बरदस्ती पुश कोई मरम्मत नहीं है; वह अपने ही वापसी-जोखिम वाली समन्वय घटना है। उसे निर्धारित करें, बैकअप लें, और टीम को बताएँ कि कब होगा।

उसके बाद टूल के सारांश पर भरोसा करने के बजाय वर्तमान ट्री और बचा हुआ इतिहास सत्यापित करें।

परिणाम को दो कलाकृतियों के रूप में रखें: वह टेम्पलेट जो साझा करने के लिए सुरक्षित है, और नामांकन प्रक्रिया से जारी क्रेडेंशियल की सूची। इनमें से किसी के लिए भी रिपॉज़िटरी में कोई उपयोग योग्य पहचान रहना ज़रूरी नहीं है।

यही अलगाव असली समाधान है, और प्रोफ़ाइल कमिट करना चाहने वाले अगले व्यक्ति के बाद भी टिका रहता है।