GIT სერვერზე მრავალ მომხმარებლის წვდომის ორგანიზაცია

Git სერვერის ინსტალაციისა და კონფიგურაციისას, ჩნდება კითხვა რამდენიმე მომხმარებლისთვის რამდენიმე პროექტზე წვდომის ორგანიზების შესახებ. მე გამოვიკვლიე ეს საკითხი და ვიპოვე გამოსავალი, რომელიც აკმაყოფილებს ჩემს ყველა მოთხოვნას: მარტივი, უსაფრთხო, საიმედო.

ჩემი სურვილებია:

• თითოეული მომხმარებელი აკავშირებს საკუთარ ანგარიშს
• რამდენიმე მომხმარებელს შეუძლია ერთ პროექტზე მუშაობა
• ერთსა და იმავე მომხმარებელს შეუძლია იმუშაოს მრავალ პროექტზე
• თითოეულ მომხმარებელს აქვს წვდომა მხოლოდ იმ პროექტებზე, რომლებზეც ის მუშაობს
• შესაძლებელი უნდა იყოს დაკავშირება ბრძანების ხაზის მეშვეობით და არა მხოლოდ რაიმე სახის ვებ ინტერფეისის საშუალებით

ასევე კარგი იქნება:

• მაკონტროლებელ პირებს მიანიჭეთ მხოლოდ წაკითხვის ნებართვები
• მოხერხებულად მართეთ მომხმარებლის წვდომის უფლებები Git-ში

GIT სერვერზე წვდომის შესაძლო ვარიანტების მიმოხილვა

უპირველეს ყოვლისა, თქვენ უნდა იცოდეთ რა უნდა აირჩიოთ, ასე რომ, აქ არის Git პროტოკოლების სწრაფი მიმოხილვა.

• ssh - სპეციალურად შექმნილი მომხმარებლის ანგარიში გამოიყენება სერვერზე წვდომისთვის.
  • უცნაურია, რომ Git არ გამორიცხავს თავისი რეკომენდაციებიდან ერთი ანგარიშის გამოყენებას ყველა საცავში წვდომისთვის. ეს საერთოდ არ აკმაყოფილებს ჩემს მოთხოვნებს.
  • თქვენ შეგიძლიათ გამოიყენოთ მრავალი ანგარიში, მაგრამ როგორ შეგიძლიათ შეზღუდოთ მომხმარებლის წვდომა მხოლოდ გარკვეულ დირექტორიაზე?
    • მთავარი დირექტორიაში დახურვა არ არის შესაფერისი, რადგან ძნელია სხვა მომხმარებლებისთვის ჩაწერის ხელმისაწვდომობის ორგანიზება
    • სიმბოლური ბმულების გამოყენება თქვენი სახლის დირექტორიაში ასევე რთულია, რადგან Git არ განმარტავს მათ, როგორც ბმულებს
    • შესაძლებელია თარჯიმნის წვდომის შეზღუდვა, მაგრამ არ არსებობს სრული გარანტია, რომ ის ყოველთვის იმუშავებს
      • თქვენ შეგიძლიათ ზოგადად დააკავშიროთ თქვენი ბრძანების თარჯიმანი ასეთი მომხმარებლებისთვის, მაგრამ
        • ჯერ ერთი, ეს უკვე ერთგვარი რთული გადაწყვეტილებაა,
        • და მეორეც, ამის გვერდის ავლა შესაძლებელია.

  მაგრამ იქნებ არაა პრობლემა, რომ მომხმარებელმა შეძლოს რაიმე ბრძანების შესრულება?.. ზოგადად, ეს მეთოდი არ არის გამორიცხული, თუ ზუსტად გაერკვევით, როგორ გამოიყენოთ იგი. ჩვენ მოგვიანებით დავუბრუნდებით ამ მეთოდს, მაგრამ ახლა მოკლედ განვიხილავთ სხვა ალტერნატივებს, იქნებ იყოს რაიმე უფრო მარტივი.

• git ადგილობრივი პროტოკოლი შეიძლება გამოყენებულ იქნას sshfs-თან ერთად, შეიძლება გამოყენებულ იქნას მრავალი მომხმარებელი, მაგრამ არსებითად იგივეა, რაც წინა შემთხვევა
• http - მხოლოდ წასაკითხად
• git არის მხოლოდ წაკითხვადი
• https - რთული დასაინსტალირებელია, გჭირდებათ დამატებითი პროგრამული უზრუნველყოფა, რაიმე სახის მართვის პანელი მომხმარებლის წვდომის ორგანიზებისთვის... როგორც ჩანს შესასრულებლად, მაგრამ რაღაცნაირად ყველაფერი რთულია.

ssh პროტოკოლის გამოყენება Git სერვერზე მრავალ მომხმარებლის წვდომის ორგანიზებისთვის

დავუბრუნდეთ ssh პროტოკოლს.

ვინაიდან იყენებთ ssh წვდომას git-ისთვის, თქვენ უნდა უზრუნველყოთ სერვერის მონაცემების უსაფრთხოება. მომხმარებელი, რომელიც აკავშირებს ssh-ის საშუალებით, იყენებს საკუთარ შესვლას Linux სერვერზე, ასე რომ მათ შეუძლიათ დაკავშირება ssh კლიენტის მეშვეობით და სერვერის ბრძანების ხაზთან წვდომა.
არ არსებობს სრული დაცვა ასეთი წვდომისგან.

მაგრამ მომხმარებელი არ უნდა იყოს დაინტერესებული Linux ფაილებით. მნიშვნელოვანი ინფორმაცია ინახება მხოლოდ git საცავში. აქედან გამომდინარე, შესაძლებელია არა წვდომის შეზღუდვა ბრძანების ხაზის მეშვეობით, არამედ Linux-ის ინსტრუმენტების გამოყენებით, რათა მომხმარებელს აეკრძალოს პროექტების ნახვა, გამოკლებით ის, რომლებშიც ის მონაწილეობს.
აშკარა არჩევანია Linux-ის ნებართვების სისტემის გამოყენება.

როგორც უკვე აღვნიშნეთ, ssh წვდომისთვის შესაძლებელია მხოლოდ ერთი ანგარიშის გამოყენება. ეს კონფიგურაცია სახიფათოა რამდენიმე მომხმარებლისთვის, თუმცა ის შედის რეკომენდირებული 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 არის სპეციალურად შექმნილი Linux მომხმარებლები, რომლებიც მინიჭებულნი არიან შესაბამისი პროექტის დირექტორიების მფლობელებად.

ყველა დირექტორიის ნებართვა დაყენებულია 0770 - სრული წვდომა მფლობელისთვის და მისი ჯგუფისთვის და სრული აკრძალვა ყველა დანარჩენისთვის.

2) დეველოპერის ანგარიშები

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

მთავარი ის არის, რომ დეველოპერებს ენიჭებათ შესაბამისი პროექტის სისტემის მომხმარებლის მფლობელის დამატებითი ჯგუფი. ამას აკეთებს Linux სერვერის ადმინისტრატორი ერთი ბრძანებით.

ამ მაგალითში "დეველოპერი 1" მუშაობს პროექტებზე proj1 და proj2, ხოლო "დეველოპერი 2" მუშაობს proj2 და proj3 პროექტებზე.

თუ რომელიმე დეველოპერი დაუკავშირდება ssh-ის მეშვეობით ბრძანების ხაზის მეშვეობით, მაშინ მათი უფლებები არ იქნება საკმარისი იმ პროექტის დირექტორიების შიგთავსის სანახავადაც კი, რომელშიც ისინი არ მონაწილეობენ. ამას თვითონ ვერ შეცვლის.

ვინაიდან ამ პრინციპის საფუძველია Linux-ის უფლებების ძირითადი უსაფრთხოება, ეს სქემა საიმედოა. გარდა ამისა, სქემის ადმინისტრირება ძალიან მარტივია.

წასვლა პრაქტიკაში.

Git საცავების შექმნა Linux სერვერზე

ჩვენ ვამოწმებთ.

[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-ის მიერ შექმნილი ფაილების შეცვლას, რამაც შეიძლება გამოიწვიოს ფუნქციონირების დარღვევა.

Linux chown - ფაილის მფლობელის შეცვლა ჩვეულებრივი მომხმარებლის მიერ

ფაილის მფლობელს არ შეუძლია შეცვალოს მისი მფლობელობა. მაგრამ მას შეუძლია შეცვალოს ფაილის ჯგუფი, რომელიც მას ეკუთვნის და შემდეგ ეს ფაილი შეიძლება შეიცვალოს იმავე ჯგუფში მყოფი სხვა მომხმარებლების მიერ. სწორედ ეს გვჭირდება.

Git Hook-ის გამოყენებით

Hook-ის სამუშაო დირექტორია არის პროექტის root დირექტორია. Hook არის შესრულებადი, რომელიც მუშაობს მომხმარებლის ქვეშ, რომელიც აკეთებს ბიძგს. ამის გაცნობიერებით, ჩვენ შეგვიძლია განვახორციელოთ ჩვენი გეგმები.

[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 სერვერზე ჩვენ ვამოწმებთ Hook-ის ფუნქციონირებას განახლების შემდგომი სკრიპტის შესრულების შემდეგ

[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

ასევე სტატიაში შეიძლება წააწყდეთ პატარა სასარგებლო ნივთებს:

• როგორ ავაშენოთ დირექტორია ხე Linux-ში
• როგორ გადავიტანოთ მისამართების დიაპაზონი sed-ში გარკვეული ხაზიდან ფაილის ბოლომდე, ანუ ჩაანაცვლოთ sed-ში ყველა სტრიქონში, გარდა პირველი ხაზისა
• როგორ შეცვალოს საძიებო მდგომარეობა Linux Find-ში
• როგორ გადავიტანოთ მრავალი ხაზი მარყუჟში ერთი ლაინერის გამოყენებით Linux shell-ში
• როგორ გაექცეთ ცალკეულ ციტატებს bash-ში
• როგორ წაშალოთ დირექტორია მთელი მისი შინაარსით windows ბრძანების ხაზში
• როგორ გამოვიყენოთ bash mv ფაილის გადარქმევის მიზნით მისი ხელახლა გადაწერის გარეშე

დიდი მადლობა ყურადღებისთვის.

წყარო: www.habr.com