Gitosis से Gitolite में दर्द रहित प्रवास

Gitosis अब समर्थित नहीं है, और डेबियन व्हीज़ी की एक स्थिर रिलीज़ दूर नहीं है, जिस पर यह अब नहीं होगा। इसलिए, जिगोलिट में प्रवास करने का निर्णय लिया गया। इस तथ्य के बावजूद कि एक संबंधित मैनुअल है , यह प्रश्न का उत्तर नहीं देता है - "यह कैसे करना है और कुछ भी नहीं तोड़ना है?"। इस पर अब चर्चा होगी।

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

चूंकि स्थापना एक उपयोगकर्ता पर की जाती है, इसलिए संघर्ष संभव है। इसलिए, यह पाया गया कि डिफ़ॉल्ट कॉन्फ़िगरेशन के दौरान, निम्न स्थानों में संघर्ष संभव है: उस फ़ोल्डर में जिसमें ~ / रिपॉजिटरी रिपॉजिटरी स्थित हैं और इन अनुप्रयोगों में स्वचालित रूप से उत्पन्न होने वाली ~ / .ssh / अधिकृत_की फ़ाइल में हैं। पहले मामले में, डिफ़ॉल्ट पथ को बदलना संभव है, लेकिन दूसरे मामले के लिए, गिटोलिट के लेखक ने ऐसा अवसर प्रदान नहीं किया। हालाँकि यह बहुत बुरा है, लेकिन इससे कोई फर्क नहीं पड़ता है - चलो एक छोटी सी प्रतिबद्धता ने स्थिति को ठीक कर दिया। स्रोत से स्थापित करने की सलाह दी जाती है, क्योंकि यह अधिक लचीलापन देता है। एक वैकल्पिक तरीका पैकेज का पुनर्निर्माण करना है, लेकिन फिर पैकेज को सीधे अपडेट करने से जुड़ा लाभ खो जाता है। तो पहला विकल्प बेहतर है।

मैं पूर्ण स्थापना को पेंट नहीं करूंगा, क्योंकि यह पहले से ही मेरे लिए किया गया है , और मैं केवल विशिष्ट बिंदुओं का वर्णन करूंगा। Gitolite सेटअप चलाने से पहले , आपको src / lib / Gitolite / Rc.pm फ़ाइल में GL_REPO_BASE और SSH_AUTH_KEY मापदंडों को बदलना होगा। उदाहरण के लिए, अधिकृत_कीप को अधिकृत_की__गोलिट से बदलें, और GL_REPO_BASE में हम एक अलग फ़ोल्डर निर्दिष्ट करेंगे। अब आप सुरक्षित रूप से स्थापना जारी रख सकते हैं, क्योंकि संघर्षों को बाहर रखा गया है।

Gitolite और gitosis एक ही समय में ssh के एक उदाहरण का उपयोग नहीं कर सकते हैं, तो चलिए दूसरे को बढ़ाते हैं। ऐसा करने के लिए, पते / etc / ssh / sshd_config के लिए कॉन्फ़िगरेशन की प्रतिलिपि बनाएँ, / etc / ssh / sshd_config_gitolite में कहें और बाद को बदलें।
इसमें ऑथराइज्डकेयसफाइल फ़ील्ड को अनइंस्टॉल करना आवश्यक है और जो फाइल पहले गिटोलिट कॉन्फिग में निर्दिष्ट की गई थी (हमारे मामले में, यह अधिकृत_की_सोलाइट है)। और पोर्ट पैरामीटर को किसी दूसरे के साथ बदलें, इसे 22222 होने दें।

अब ssh को डिबग मोड sudo / usr / sbin / sshd -ddd -f / etc / ssh / sshd_config_gitolite में चलाएं और इसके संचालन की जांच करें। ऐसा करने के लिए, हम टेस्ट रिपॉजिटरी git क्लोन ssh: // git @ git-server: 22222 / परीक्षण का क्लोन तैयार करते हैं। अगला, हम जिओलाइट मैनुअल में वर्णित माइग्रेशन पर आगे बढ़ते हैं: चाबियाँ जोड़ें, कॉन्फ़िगरेशन माइग्रेट करें, और एक्सेस अधिकारों का परीक्षण करें।

अंतिम चरण गिटोसिस से गिटोलिट पर स्विच करना है। ऐसा करने के लिए, हम .ssh / अधिकृत_की फ़ाइल को किसी अन्य स्थान पर ले जाकर सभी की पहुँच को काट देते हैं (ताकि कोई नया परिवर्तन न हो)। फिर दो तरीके हैं: या तो रिपॉजिटरी को ~ / रिपॉजिटरी से ~ / रेपो तक कॉपी कर लें या उनके साथ सहानुभूति बना लें। रिपॉजिटरी को स्थानांतरित करने के बाद, मैनुअल में वर्णित के रूप में गिटोलाइट सेटअप चलाएं । अंतिम चरण डिफ़ॉल्ट मान के साथ SSH_AUTH_KEY को प्रतिस्थापित करना है और अधिकृत_के_सोलाइट फाइल को अधिकृत_की को नाम देना है। इस प्रकार, प्रवास सफलतापूर्वक पूरा हो गया था।

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

अच्छा प्रवास करें!