ProHoster > Blog > administratë > Organizimi i aksesit me shumë përdorues në serverin GIT

Organizimi i aksesit me shumë përdorues në serverin GIT

Kur instaloni dhe konfiguroni një server Git, lind pyetja në lidhje me organizimin e aksesit për disa përdorues në disa projekte. E hulumtova çështjen dhe gjeta një zgjidhje që plotësonte të gjitha kërkesat e mia: e thjeshtë, e sigurt, e besueshme.

Dëshirat e mia janë:

  • çdo përdorues lidhet me llogarinë e vet
  • Disa përdorues mund të punojnë në një projekt
  • i njëjti përdorues mund të punojë në shumë projekte
  • çdo përdorues ka qasje vetëm në ato projekte në të cilat ai punon
  • Duhet të jetë e mundur të lidheni përmes linjës së komandës, dhe jo vetëm përmes një ndërfaqeje në internet

Gjithashtu do të ishte mirë:

  • jepni leje vetëm për lexim për personat kontrollues
  • Menaxhoni me lehtësi të drejtat e aksesit të përdoruesit në Git

Pasqyrë e opsioneve të mundshme për të hyrë në serverin GIT

Para së gjithash, duhet të dini se nga të zgjidhni, kështu që këtu është një përmbledhje e shpejtë e protokolleve Git.

  • ssh - një llogari përdoruesi e krijuar posaçërisht përdoret për të hyrë në server.
    • Është e çuditshme që Git nuk përjashton nga rekomandimet e tij përdorimin e një llogarie për të hyrë në të gjitha depot. Kjo nuk i plotëson aspak kërkesat e mia.
    • Ju mund të përdorni shumë llogari, por si mund ta kufizoni aksesin e përdoruesve vetëm në drejtori të caktuara?
      • Mbyllja në direktorinë kryesore nuk është e përshtatshme, sepse është e vështirë të organizohet aksesi i shkrimit atje për përdoruesit e tjerë
      • Përdorimi i lidhjeve simbolike nga direktoria juaj kryesore është gjithashtu e vështirë sepse Git nuk i interpreton ato si lidhje
      • Është e mundur të kufizohet qasja te përkthyesi, por nuk ka asnjë garanci të plotë se ai do të funksionojë gjithmonë
        • Në përgjithësi mund të lidhni përkthyesin tuaj të komandës për përdorues të tillë, por
          • së pari, ky është tashmë një lloj vendimi i vështirë,
          • dhe së dyti, kjo mund të anashkalohet.

    Por ndoshta nuk është problem që përdoruesi do të jetë në gjendje të ekzekutojë ndonjë komandë?.. Në përgjithësi, kjo metodë nuk mund të përjashtohet nëse e kuptoni saktësisht se si ta përdorni. Ne do t'i kthehemi kësaj metode më vonë, por tani për tani do të shqyrtojmë shkurtimisht alternativat e tjera, ndoshta do të ketë diçka më të thjeshtë.

  • Protokolli lokal git mund të përdoret në kombinim me sshfs, mund të përdoren shumë përdorues, por në thelb i njëjtë me rastin e mëparshëm
  • http - vetëm për lexim
  • git është vetëm për lexim
  • https - e vështirë për t'u instaluar, keni nevojë për softuer shtesë, një lloj paneli kontrolli për të organizuar aksesin e përdoruesit ... duket e realizueshme, por disi gjithçka është e ndërlikuar.

Përdorimi i protokollit ssh për të organizuar aksesin me shumë përdorues në serverin Git

Le të kthehemi te protokolli ssh.

Meqenëse përdorni aksesin ssh për git, duhet të siguroni sigurinë e të dhënave të serverit. Përdoruesi që lidhet përmes ssh përdor hyrjen e tij në serverin Linux, kështu që ata mund të lidhen përmes klientit ssh dhe të hyjnë në linjën e komandës së serverit.
Nuk ka mbrojtje të plotë kundër një aksesi të tillë.

Por përdoruesi nuk duhet të interesohet për skedarët Linux. Informacioni i rëndësishëm ruhet vetëm në depon e git. Prandaj, është e mundur të mos kufizohet qasja përmes linjës së komandës, por duke përdorur mjete Linux për të ndaluar përdoruesin të shikojë projekte, duke përjashtuar ato në të cilat ai merr pjesë.
Zgjedhja e qartë është përdorimi i sistemit të lejeve Linux.

Siç është përmendur tashmë, është e mundur të përdoret vetëm një llogari për qasje ssh. Ky konfigurim është i pasigurt për disa përdorues, megjithëse përfshihet në listën e opsioneve të rekomanduara të git.

Për të zbatuar kërkesat e dhëna në fillim të artikullit, krijohet struktura e mëposhtme e drejtorisë me caktimin e të drejtave dhe pronarëve:

1) drejtoritë e projekteve

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
ku
dir1, dir2, dir3 - drejtoritë e projektit: projekti 1, projekti 2, projekti 3.

proj1:proj1, proj2:proj2, proj3:proj3 janë përdorues të Linux të krijuar posaçërisht, të cilët janë caktuar si pronarë të drejtorive përkatëse të projektit.

lejet për të gjitha drejtoritë janë vendosur në 0770 - akses i plotë për pronarin dhe grupin e tij dhe një ndalim i plotë për të gjithë të tjerët.

2) llogaritë e zhvilluesit

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

Pika kryesore është se zhvilluesve u caktohet një grup shtesë i pronarit të përdoruesit të sistemit të projektit përkatës. Kjo bëhet nga administratori i serverit Linux me një komandë.

Në këtë shembull, "Zhvilluesi 1" është duke punuar në projektet proj1 dhe proj2, dhe "Zhvilluesi 2" po punon në projektet proj2 dhe proj3.

Nëse ndonjë nga Zhvilluesit lidhet përmes ssh përmes linjës së komandës, atëherë të drejtat e tyre nuk do të jenë të mjaftueshme as për të parë përmbajtjen e drejtorive të projektit në të cilat ata nuk marrin pjesë. Ai nuk mund ta ndryshojë këtë vetë.

Meqenëse baza e këtij parimi është siguria bazë e të drejtave të Linux, kjo skemë është e besueshme. Përveç kësaj, skema është shumë e lehtë për t'u administruar.

Le të kalojmë në praktikë.

Krijimi i depove Git në një server Linux

Ne kontrollojmë.

[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

Jam lodhur duke shkruar me dorë...

[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

Jemi të bindur se është e pamundur të qasesh në depot e njerëzve të tjerë nga linja e komandës dhe madje të shikosh përmbajtjen e tyre.

[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

Bashkëpunoni me zhvillues të shumtë në të njëjtin projekt në Git

Mbetet një pyetje, nëse një zhvillues prezanton një skedar të ri, atëherë zhvilluesit e tjerë nuk mund ta ndryshojnë atë, sepse ai vetë është pronari i tij (për shembull, dev1), dhe jo pronari i përdoruesit të projektit (për shembull, proj1). Meqenëse kemi një depo nga ana e serverit, para së gjithash, duhet të dimë se si është strukturuar direktoria “.git” dhe nëse krijohen skedarë të rinj.

Krijimi i një depoje lokale Git dhe shtyrja te serveri Git

Le të kalojmë te makina e klientit.

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>

Në të njëjtën kohë, skedarët e rinj krijohen në server, dhe ato i përkasin përdoruesit që ka kryer shtytjen

[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]$

Kur ngarkoni ndryshime në serverin Git, krijohen skedarë dhe drejtori shtesë dhe pronari i tyre është në të vërtetë përdoruesi që bën ngarkimin. Por atëherë grupi i këtyre skedarëve dhe drejtorive korrespondon gjithashtu me grupin kryesor të këtij përdoruesi, domethënë grupin dev1 për përdoruesin dev1 dhe grup dev2 për përdoruesin dev2 (ndryshimi i grupit kryesor të përdoruesit të zhvilluesit nuk do të ndihmojë, sepse atëherë si mund të punoni në projekte të shumta?). Në këtë rast, përdoruesi dev2 nuk do të jetë në gjendje të ndryshojë skedarët e krijuar nga përdoruesi dev1, gjë që mund të çojë në një prishje të funksionalitetit.

Linux chown - ndryshimi i pronarit të një skedari nga një përdorues i rregullt

Zotëruesi i një skedari nuk mund të ndryshojë pronësinë e tij. Por ai mund të ndryshojë grupin e një skedari që i përket, dhe më pas ky skedar mund të modifikohet nga përdorues të tjerë që janë në të njëjtin grup. Kjo është ajo që ne kemi nevojë.

Duke përdorur grepin Git

Drejtoria e punës për hook është direktoria kryesore e projektit. hook është një ekzekutues që funksionon nën përdoruesin që bën shtytjen. Duke e ditur këtë, ne mund të zbatojmë planet tona.

[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

ose vetëm 

vi hooks/post-update

Le të kthehemi te makina e klientit.

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

Në serverin Git, ne kontrollojmë funksionimin e skriptit pas përditësimit të goditjes pas kryerjes 

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

- bosh, gjithçka është në rregull.

Lidhja e një zhvilluesi të dytë në Git

Le të simulojmë punën e zhvilluesit të dytë.

Mbi klientin

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

Dhe në të njëjtën kohë, në server ...

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

- përsëri bosh, gjithçka funksionon.

Fshirja e një projekti Git dhe shkarkimi i projektit nga serveri Git

Epo, mund të siguroheni edhe një herë që të gjitha ndryshimet janë ruajtur.

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

— për të fshirë një projekt Git, thjesht pastroni plotësisht drejtorinë. Le të përballojmë gabimin që krijohet, pasi është e pamundur të fshijmë drejtorinë aktuale duke përdorur këtë komandë, por kjo është pikërisht sjellja që na nevojitet.

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"

Ndarja e aksesit në Git

Tani le të sigurohemi që edhe përmes Git zhvilluesi i dytë nuk mund të hyjë në projektin Proj1, në të cilin ai nuk po punon.

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.

Tani ne lejojmë aksesin

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

dhe pas kësaj gjithçka funksionon.

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

Për më shumë informacion,

Për më tepër, nëse ka një problem me lejet e paracaktuara gjatë krijimit të skedarëve dhe drejtorive, në CentOS mund të përdorni komandën

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

Gjithashtu në artikull mund të hasni në gjëra të vogla të dobishme:

  • si të ndërtoni një pemë drejtorie në Linux
  • si të kaloni një varg adresash në sed nga një rresht i caktuar në fund të skedarit, domethënë, të bëni një zëvendësim në sed në të gjitha rreshtat përveç rreshtit të parë
  • Si të përmbysni një kusht kërkimi në gjetjen e Linux
  • Si të kaloni linja të shumta në një lak duke përdorur një rreshtim të vetëm në guaskën Linux
  • Si të shpëtoni nga kuotat e vetme në bash
  • si të fshini një direktori me të gjithë përmbajtjen e tij në vijën komanduese të Windows
  • Si të përdorni bash mv për të riemërtuar një skedar pa e rishkruar atë përsëri

Faleminderit për vëmendjen tuaj.

Burimi: www.habr.com

Shto një koment