जीआईटी सर्वर तक बहु-उपयोगकर्ता पहुंच का संगठन

Git सर्वर को स्थापित और कॉन्फ़िगर करते समय, कई उपयोगकर्ताओं के लिए कई परियोजनाओं तक पहुंच को व्यवस्थित करने का सवाल उठता है। मैंने इस मुद्दे पर शोध किया और एक समाधान पाया जो मेरी सभी आवश्यकताओं को पूरा करता था: सरल, सुरक्षित, विश्वसनीय।

मेरी इच्छाएँ हैं:

• प्रत्येक उपयोगकर्ता अपने स्वयं के खाते से जुड़ता है
• एक प्रोजेक्ट पर कई उपयोगकर्ता काम कर सकते हैं
• एक ही उपयोगकर्ता कई परियोजनाओं पर काम कर सकता है
• प्रत्येक उपयोगकर्ता के पास केवल उन्हीं परियोजनाओं तक पहुंच होती है जिन पर वह काम करता है
• कमांड लाइन के माध्यम से कनेक्ट करना संभव होना चाहिए, न कि केवल किसी प्रकार के वेब इंटरफ़ेस के माध्यम से

यह भी बहुत अच्छा होगा:

• नियंत्रित करने वाले व्यक्तियों को केवल पढ़ने की अनुमति प्रदान करें
• Git में उपयोगकर्ता पहुंच अधिकारों को सुविधाजनक रूप से प्रबंधित करें

जीआईटी सर्वर तक पहुंचने के संभावित विकल्पों का अवलोकन

सबसे पहले, आपको यह जानना होगा कि क्या चुनना है, इसलिए यहां Git प्रोटोकॉल का एक त्वरित अवलोकन दिया गया है।

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

  लेकिन शायद यह कोई समस्या नहीं है कि उपयोगकर्ता किसी भी कमांड को निष्पादित करने में सक्षम होगा?.. सामान्य तौर पर, इस पद्धति से इंकार नहीं किया जा सकता है यदि आप यह समझ लें कि इसका उपयोग कैसे करना है। हम बाद में इस पद्धति पर लौटेंगे, लेकिन अभी हम अन्य विकल्पों पर संक्षेप में विचार करेंगे, शायद कुछ आसान होगा।

• Git स्थानीय प्रोटोकॉल का उपयोग sshfs के साथ संयोजन में किया जा सकता है, एकाधिक उपयोगकर्ताओं का उपयोग किया जा सकता है, लेकिन अनिवार्य रूप से पिछले मामले के समान ही
• http - केवल पढ़ने के लिए
• गिट केवल पढ़ने के लिए है
• https - स्थापित करना कठिन है, आपको अतिरिक्त सॉफ़्टवेयर की आवश्यकता है, उपयोगकर्ता पहुंच को व्यवस्थित करने के लिए किसी प्रकार का नियंत्रण कक्ष... यह संभव लगता है, लेकिन किसी तरह सब कुछ जटिल है।

Git सर्वर तक बहु-उपयोगकर्ता पहुंच को व्यवस्थित करने के लिए ssh प्रोटोकॉल का उपयोग करना

आइए ssh प्रोटोकॉल पर वापस लौटें।

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

लेकिन उपयोगकर्ता को Linux फ़ाइलों में रुचि नहीं होनी चाहिए. महत्वपूर्ण जानकारी केवल git रिपॉजिटरी में संग्रहीत होती है। इसलिए, कमांड लाइन के माध्यम से पहुंच को प्रतिबंधित करना संभव नहीं है, लेकिन उपयोगकर्ता को उन परियोजनाओं को छोड़कर, जिनमें वह भाग लेता है, को देखने से रोकने के लिए लिनक्स टूल का उपयोग करना संभव है।
स्पष्ट विकल्प लिनक्स अनुमति प्रणाली का उपयोग करना है।

जैसा कि पहले ही उल्लेख किया गया है, एसएसएच एक्सेस के लिए केवल एक खाते का उपयोग करना संभव है। यह कॉन्फ़िगरेशन कई उपयोगकर्ताओं के लिए असुरक्षित है, हालाँकि यह अनुशंसित git विकल्पों की सूची में शामिल है।

लेख की शुरुआत में दी गई आवश्यकताओं को लागू करने के लिए, अधिकारों और मालिकों के असाइनमेंट के साथ निम्नलिखित निर्देशिका संरचना बनाई गई है:

1) परियोजना निर्देशिकाएँ

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
जहां
dir1, dir2, dir3 - प्रोजेक्ट निर्देशिकाएँ: प्रोजेक्ट 1, प्रोजेक्ट 2, प्रोजेक्ट 3।

proj1:proj1, proj2:proj2, proj3:proj3 विशेष रूप से बनाए गए लिनक्स उपयोगकर्ता हैं जिन्हें संबंधित प्रोजेक्ट निर्देशिकाओं के मालिकों के रूप में सौंपा गया है।

सभी निर्देशिकाओं के लिए अनुमतियाँ 0770 पर सेट हैं - स्वामी और उसके समूह के लिए पूर्ण पहुँच और बाकी सभी के लिए पूर्ण प्रतिबंध।

2) डेवलपर खाते

Разработчик 1: dev1:dev1,proj1,proj2
Разработчик 2: dev2:dev2,proj2,proj3

मुख्य बात यह है कि डेवलपर्स को संबंधित प्रोजेक्ट के सिस्टम उपयोगकर्ता स्वामी का एक अतिरिक्त समूह सौंपा जाता है। यह लिनक्स सर्वर प्रशासक द्वारा एक आदेश के साथ किया जाता है।

इस उदाहरण में, "डेवलपर 1" प्रोजेक्ट्स proj1 और proj2 पर काम कर रहा है, और "डेवलपर 2" प्रोजेक्ट्स proj2 और proj3 पर काम कर रहा है।

यदि कोई डेवलपर्स कमांड लाइन के माध्यम से एसएसएच के माध्यम से कनेक्ट होता है, तो उनके अधिकार उन प्रोजेक्ट निर्देशिकाओं की सामग्री को देखने के लिए भी पर्याप्त नहीं होंगे जिनमें वे भाग नहीं लेते हैं। इसे वह स्वयं नहीं बदल सकता.

चूँकि इस सिद्धांत का आधार लिनक्स अधिकारों की बुनियादी सुरक्षा है, इसलिए यह योजना विश्वसनीय है। इसके अलावा, योजना का संचालन करना बहुत आसान है।

आइए अभ्यास की ओर आगे बढ़ें।

Linux सर्वर पर Git रिपॉजिटरी बनाना

की जाँच करें।

[root@server ~]# cd /var/
[root@server var]# useradd gitowner
[root@server var]# mkdir gitservertest
[root@server var]# chown gitowner:gitowner gitservertest
[root@server var]# adduser proj1
[root@server var]# adduser proj2
[root@server var]# adduser proj3
[root@server var]# adduser dev1
[root@server var]# adduser dev2
[root@server var]# passwd dev1
[root@server var]# passwd dev2

मैं हाथ से टाइप करते-करते थक गया हूँ...

[root@server gitservertest]# sed "s/ /n/g" <<< "proj1 proj2 proj3" | while read u; do mkdir $u; chown $u:$u $u; chmod 0770 $u; done

[root@server gitservertest]# usermod -aG proj1 dev1
[root@server gitservertest]# usermod -aG proj2 dev1
[root@server gitservertest]# usermod -aG proj2 dev2
[root@server gitservertest]# usermod -aG proj3 dev2

हम आश्वस्त हैं कि कमांड लाइन से अन्य लोगों के रिपॉजिटरी तक पहुंचना और यहां तक ​​कि उनकी सामग्री को देखना भी असंभव है।

[dev1@server ~]$ cd /var/gitservertest/proj3
-bash: cd: /var/gitservertest/proj3: Permission denied
[dev1@server ~]$ ls /var/gitservertest/proj3
ls: cannot open directory /var/gitservertest/proj3: Permission denied

Git में एक ही प्रोजेक्ट पर एकाधिक डेवलपर्स के साथ सहयोग करें

एक प्रश्न शेष है, यदि एक डेवलपर एक नई फ़ाइल प्रस्तुत करता है, तो अन्य डेवलपर्स इसे बदल नहीं सकते हैं, क्योंकि वह स्वयं इसका स्वामी है (उदाहरण के लिए, dev1), न कि प्रोजेक्ट का उपयोगकर्ता स्वामी (उदाहरण के लिए, proj1)। चूँकि हमारे पास एक सर्वर-साइड रिपॉजिटरी है, सबसे पहले, हमें यह जानना होगा कि ".git" निर्देशिका कैसे संरचित है और क्या नई फ़ाइलें बनाई गई हैं।

एक स्थानीय Git रिपॉजिटरी बनाना और Git सर्वर पर पुश करना

चलिए क्लाइंट मशीन पर चलते हैं।

Microsoft Windows [Version 6.1.7601]
(c) Корпорация Майкрософт (Microsoft Corp.), 2009. Все права защищены.

C:gittest>git init .
Initialized empty Git repository in C:/gittest/.git/

C:gittest>echo "test dev1 to proj2" > test1.txt

C:gittest>git add .

C:gittest>git status
On branch master
No commits yet
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   test1.txt

C:gittest>git commit -am "new test file added"
[master (root-commit) a7ac614] new test file added
 1 file changed, 1 insertion(+)
 create mode 100644 test1.txt
 
C:gittest>git remote add origin "ssh://[email protected]/var/gitservertest/proj2"

C:gittest>git push origin master
dev1:[email protected]'s password:
Counting objects: 3, done.
Writing objects: 100% (3/3), 243 bytes | 243.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://10.1.1.11/var/gitservertest/proj2
 * [new branch]      master -> master

C:gittest>

उसी समय, सर्वर पर नई फ़ाइलें बनाई जाती हैं, और वे पुश करने वाले उपयोगकर्ता की होती हैं

[dev1@server proj2]$ tree
.
├── 1.txt
├── branches
├── config
├── description
├── HEAD
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── prepare-commit-msg.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   └── update.sample
├── info
│   └── exclude
├── objects
│   ├── 75
│   │   └── dcd269e04852ce2f683b9eb41ecd6030c8c841
│   ├── a7
│   │   └── ac6148611e69b9a074f59a80f356e1e0c8be67
│   ├── f0
│   │   └── 82ea1186a491cd063925d0c2c4f1c056e32ac3
│   ├── info
│   └── pack
└── refs
    ├── heads
    │   └── master
    └── tags

12 directories, 18 files
[dev1@server proj2]$ ls -l objects/75/dcd269e04852ce2f683b9eb41ecd6030c8c841
-r--r--r--. 1 dev1 dev1 54 Jun 20 14:34 objects/75/dcd269e04852ce2f683b9eb41ecd6030c8c841
[dev1@server proj2]$

जब आप Git सर्वर में परिवर्तन अपलोड करते हैं, तो अतिरिक्त फ़ाइलें और निर्देशिकाएँ बनाई जाती हैं, और उनका स्वामी वास्तव में अपलोड करने वाला उपयोगकर्ता होता है। लेकिन फिर इन फ़ाइलों और निर्देशिकाओं का समूह भी इस उपयोगकर्ता के मुख्य समूह से मेल खाता है, यानी, dev1 उपयोगकर्ता के लिए dev1 समूह और dev2 उपयोगकर्ता के लिए dev2 समूह (डेवलपर उपयोगकर्ता के मुख्य समूह को बदलने से मदद नहीं मिलेगी, क्योंकि फिर आप एकाधिक परियोजनाओं पर कैसे काम कर सकते हैं?) इस स्थिति में, उपयोगकर्ता dev2 उपयोगकर्ता dev1 द्वारा बनाई गई फ़ाइलों को बदलने में सक्षम नहीं होगा, जिससे कार्यक्षमता में खराबी आ सकती है।

लिनक्स चाउन - एक नियमित उपयोगकर्ता द्वारा फ़ाइल के मालिक को बदलना

किसी फ़ाइल का स्वामी उसका स्वामित्व नहीं बदल सकता. लेकिन वह उस फ़ाइल के समूह को बदल सकता है जो उसकी है, और फिर इस फ़ाइल को उसी समूह में मौजूद अन्य उपयोगकर्ताओं द्वारा संशोधित किया जा सकता है। हमें यही चाहिए.

गिट हुक का उपयोग करना

हुक के लिए कार्यशील निर्देशिका परियोजना की मूल निर्देशिका है। हुक एक निष्पादन योग्य है जो पुश करने वाले उपयोगकर्ता के नीचे चलता है। यह जानकर हम अपनी योजनाओं को क्रियान्वित कर सकते हैं।

[dev1@server proj2]$ mv hooks/post-update{.sample,}
[dev1@server proj2]$ sed -i '2,$ s/^/#/' hooks/post-update
[dev1@server proj2]$ cat <<< 'find . -group $(whoami) -exec chgrp proj2 '"'"'{}'"'"' ;' >> hooks/post-update

या केवल

vi hooks/post-update

चलिए क्लाइंट मशीन पर वापस आते हैं।

C:gittest>echo "dev1 3rd line" >> test1.txt

C:gittest>git commit -am "3rd from dev1, testing server hook"
[master b045e22] 3rd from dev1, testing server hook
 1 file changed, 1 insertion(+)

C:gittest>git push origin master
dev1:[email protected]'s password:
   d22c66e..b045e22  master -> master

Git सर्वर पर, हम कमिट के बाद हुक पोस्ट-अपडेट स्क्रिप्ट के संचालन की जाँच करते हैं

[dev1@server proj2]$ find . ! -group proj2

- खाली, सब कुछ ठीक है।

Git में दूसरे डेवलपर को कनेक्ट करना

आइए दूसरे डेवलपर के कार्य का अनुकरण करें।

ग्राहक पर

C:gittest>git remote remove origin

C:gittest>git remote add origin "ssh://[email protected]/var/gitservertest/proj2"

C:gittest>echo "!!! dev2 added this" >> test1.txt

C:gittest>echo "!!! dev2 wrote" > test2.txt

C:gittest>git add test2.txt

C:gittest>git commit -am "dev2 added to test1 and created test2"
[master 55d49a6] dev2 added to test1 and created test2
 2 files changed, 2 insertions(+)
 create mode 100644 test2.txt

C:gittest>git push origin master
[email protected]'s password:
   b045e22..55d49a6  master -> master

और साथ ही, सर्वर पर...

[dev1@server proj2]$ find . ! -group proj2

- फिर से खाली, सब कुछ काम करता है।

Git प्रोजेक्ट को हटाना और Git सर्वर से प्रोजेक्ट को डाउनलोड करना

खैर, आप एक बार फिर सुनिश्चित कर सकते हैं कि सभी परिवर्तन सहेजे गए हैं।

C:gittest>rd /S /Q .
Процесс не может получить доступ к файлу, так как этот файл занят другим процессом.

- Git प्रोजेक्ट को हटाने के लिए, बस निर्देशिका को पूरी तरह से साफ़ करें। आइए उत्पन्न होने वाली त्रुटि को स्वीकार करें, क्योंकि इस कमांड का उपयोग करके वर्तमान निर्देशिका को हटाना असंभव है, लेकिन यह बिल्कुल वही व्यवहार है जिसकी हमें आवश्यकता है।

C:gittest>dir
 Содержимое папки C:gittest

21.06.2019  08:43    <DIR>          .
21.06.2019  08:43    <DIR>          ..

C:gittest>git clone ssh://[email protected]/var/gitservertest/proj2
Cloning into 'proj2'...
[email protected]'s password:

C:gittest>cd proj2

C:gittestproj2>dir
 Содержимое папки C:gittestproj2

21.06.2019  08:46    <DIR>          .
21.06.2019  08:46    <DIR>          ..
21.06.2019  08:46               114 test1.txt
21.06.2019  08:46                19 test2.txt
C:gittestproj2>type test1.txt
"test dev1 to proj2"
"dev1 added some omre"
"dev1 3rd line"
"!!! dev2 added this"

C:gittestproj2>type test2.txt
"!!! dev2 wrote"

Git में पहुंच साझा करना

अब आइए यह सुनिश्चित करें कि Git के माध्यम से भी दूसरा डेवलपर Proj1 प्रोजेक्ट तक नहीं पहुंच सके, जिस पर वह काम नहीं कर रहा है।

C:gittestproj2>git remote remove origin

C:gittestproj2>git remote add origin "ssh://[email protected]/var/gitservertest/proj1"

C:gittestproj2>git push origin master
[email protected]'s password:
fatal: '/var/gitservertest/proj1' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

अब हम प्रवेश की अनुमति देते हैं

[root@server ~]# usermod -aG proj1 dev2

और उसके बाद सब कुछ काम करता है।

C:gittestproj2>git push origin master
[email protected]'s password:
To ssh://10.1.1.11/var/gitservertest/proj1
 * [new branch]      master -> master

अधिक जानकारी के लिए

इसके अतिरिक्त, यदि फ़ाइलें और निर्देशिका बनाते समय डिफ़ॉल्ट अनुमतियों में कोई समस्या है, तो CentOS में आप कमांड का उपयोग कर सकते हैं

setfacl -Rd -m o::5 -m g::7 /var/gitservertest

इसके अलावा लेख में आपको छोटी-छोटी उपयोगी बातें भी मिल सकती हैं:

• लिनक्स में डायरेक्टरी ट्री कैसे बनाएं
• एक निश्चित पंक्ति से फ़ाइल के अंत तक sed में पतों की एक श्रृंखला को कैसे पास करें, अर्थात, पहली पंक्ति को छोड़कर सभी पंक्तियों में sed में प्रतिस्थापन करें
• लिनक्स खोज में खोज स्थिति को कैसे पलटें
• लिनक्स शेल में एक-लाइनर का उपयोग करके एक लूप में एकाधिक लाइनें कैसे पास करें
• बैश में सिंगल कोट्स से कैसे बचें
• विंडोज़ कमांड लाइन में किसी निर्देशिका को उसकी सभी सामग्री के साथ कैसे हटाएं
• किसी फ़ाइल को दोबारा लिखे बिना उसका नाम बदलने के लिए बैश एमवी का उपयोग कैसे करें

आपका ध्यान के लिए धन्यवाद.

स्रोत: www.habr.com