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

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

Kur instalimin dhe konfigurimin e një serveri Git, ngrihet çështja e organizimit të aksesit të disa përdoruesve në disa projekte. Kam kryer një hulumtim mbi çështjen dhe kam gjetur një zgjidhje që përmbush të gjitha kërkesat e mia: e thjeshtë, e sigurt, e besueshme.

Dëshirat e mia janë këto:

  • çdo pĂ«rdorues lidhĂ«t me llogarinĂ« e tij tĂ« vetme
  • mbi njĂ« projekt mund tĂ« punojnĂ« disa pĂ«rdorues
  • i njĂ«jti pĂ«rdorues mund tĂ« punojĂ« nĂ« disa projekte
  • çdo pĂ«rdorues ka akses vetĂ«m nĂ« projektet nĂ« tĂ« cilat ai punon
  • duhet tĂ« ketĂ« mundĂ«sinĂ« e aksesit pĂ«rmes komandĂ«s nĂ« linjĂ«, jo vetĂ«m pĂ«rmes njĂ« ndĂ«rfaqeje tĂ« caktuar web

Gjithashtu do të ishte e shkëlqyer:

  • tĂ« ofrohen tĂ« drejta vetĂ«m pĂ«r lexim pĂ«r personat qĂ« kontrollojnĂ«
  • tĂ« jetĂ« e lehtĂ« tĂ« administrohen tĂ« drejtat e aksesit tĂ« pĂ«rdoruesve nĂ« Git

Përmbledhje e mundësive të aksesit në serverin GIT

Para së gjithash, duhet të dihet se nga çfarë mund të zgjidhet, prandaj një përmbledhje e shkurtër e protokolleve Git.

  • ssh — pĂ«r akses nĂ« server pĂ«rdoret njĂ« llogari e krijuar posaçërisht pĂ«r pĂ«rdoruesin.
    • ËshtĂ« e çuditshme qĂ« Git nuk pĂ«rjashton nga rekomandimet pĂ«rdorimin e njĂ« llogarie pĂ«r akses nĂ« tĂ« gjitha repozitat. Kjo nuk pĂ«rmbush kĂ«rkesat e mia.
    • mund tĂ« pĂ«rdoren disa llogari, por si tĂ« kufizosh aksesin e pĂ«rdoruesit vetĂ«m nĂ« disa direktoriume?
      • Mbyllja nĂ« direktoriumin e shtĂ«pisĂ« nuk Ă«shtĂ« e pĂ«rshtatshme, sepse Ă«shtĂ« e vĂ«shtirĂ« tĂ« organizohet akses pĂ«r shkrim pĂ«r pĂ«rdorues tĂ« tjerĂ«
      • PĂ«rdorimi i lidhjeve simbolike nga direktoriumi i shtĂ«pisĂ« Ă«shtĂ« gjithashtu i komplikuar sepse Git nuk i interpreton ato si lidhje
      • TĂ« kufizosh aksesin nĂ« interpretor, mund tĂ« bĂ«het, por nuk ka garanci tĂ« plotĂ« qĂ« kjo do tĂ« funksionojĂ« gjithmonĂ«
        • Mund tĂ« lidhen pĂ«r pĂ«rdoruesit e tillĂ« interpretorĂ« tĂ« komandave tĂ« tyre, por,
          • nĂ« radhĂ« tĂ« parĂ«, ky Ă«shtĂ« njĂ« zgjidhje e ndĂ«rlikuar,
          • dhe nĂ« tĂ« dytĂ«, kjo mund tĂ« anashkalohet.

    Por, ndoshta nuk është një problem që përdoruesi mund të ekzekutojë komanda të ndryshme? Në përgjithësi, nuk duhet përjashtuar ky metodë, nëse të përcaktojmë se si të përdoret. Të kthehemi te ky metodë më vonë, për tani le të shqyrtojmë alternativat e tjera, ndoshta aty do të ketë diçka më të thjeshtë.

  • Protokolli git lokal mund tĂ« pĂ«rdoret nĂ« kombinim me sshfs, mund tĂ« pĂ«rdoren disa pĂ«rdorues, por nĂ« thelb, Ă«shtĂ« e njĂ«jta gjĂ« si rastin e mĂ«parshĂ«m.
  • http — vetĂ«m pĂ«r lexim.
  • git — vetĂ«m pĂ«r lexim.
  • https — e vĂ«shtirĂ« pĂ«r tu instaluar, kĂ«rkon softuer shtesĂ«, ndonjĂ«herĂ«. panairi i menaxhimit pĂ«r organizimin e qasjes sĂ« pĂ«rdoruesve... duket realizueshĂ«m, por ndonjĂ«herĂ« Ă«shtĂ« e komplikuar.

Përdorimi i protokollit ssh për organizimin e qasjes shumëpërdorueshe në serverin Git.

Kthehemi te protokolli ssh.

Duke qenë se përdoret qasja përmes ssh për git, duhen siguruar të dhënat e serverit. Përdoruesi që lidhet përmes ssh, përdor identifikuesin e vet në server Linux, prandaj ai mund të lidhet përmes klientit ssh dhe të ketë qasje në komandën e serverit.
Nuk ka mbrojtje të plotë nga qasja e tillë.

Por për përdoruesin nuk duhet të jenë interesante skedarët Linux. Informacioni i rëndësishëm ruhet vetëm në repositorin git. Prandaj, nuk është e nevojshme të kufizohet qasja përmes komandës, por me ndihmën e Linux-it mund të ndalohet përdoruesi të shohë projektet, përveç atyre në të cilat ai merr pjesë.
Padyshim është e qartë të përdoret sistemi i të drejtave të aksesit në Linux.

Siç është thënë më parë, është e mundur të përdoret vetëm një llogari për akses ssh. Kjo konfigurim është e pasigurt për disa përdorues, megjithëse ky mënyrë është përfshirë në listën e rekomandimeve për git.

Për realizimin e kërkesave të përmendura në fillim të artikullit, krijohet struktura e mëposhtme e direktorive me caktimin e të drejtave dhe pronarëve:

1) direktorët e projekteve

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)


ku
dir1, dir2, dir3 — janĂ« direktorĂ«t e projekteve: projekti 1, projekti 2, projekti 3.

proj1:proj1, proj2:proj2, proj3:proj3 — pĂ«rdoruesit e krijuar posaçërisht nĂ« Linux, tĂ« cilĂ«t emĂ«rohen pronarĂ« tĂ« direktorĂ«ve pĂ«rkatĂ«s tĂ« projekteve.

tĂ« drejtat nĂ« tĂ« gjitha direktorĂ«t caktosen nĂ« 0770 — qasje e plotĂ« pĂ«r pronarin dhe grupin e tij dhe ndalim tĂ« plotĂ« pĂ«r tĂ« gjithĂ« tĂ« tjerĂ«t.

2) llogaritë e zhvilluesve

Zhvilluesi 1: dev1:dev1,proj1,proj2
Zhvilluesi 2: dev2:dev2,proj2,proj3

Pika kyçe është se zhvilluesve u caktohet një grup shtesë i përdoruesit sistem pronar për projektin përkatës. Kjo bëhet nga administratori i serverit Linux me një komandë.

Në këtë shembull, "Zhvilluesi 1" po punon mbi projektin proj1 dhe proj2, ndërsa "Zhvilluesi 2" po punon mbi projektet proj2 dhe proj3.

Nëse ndonjë nga Zhvilluesit lidhet përmes ssh nëpërmjet komandës, të drejtat e tij do të jenë të pamjaftueshme edhe për të parë përmbajtjen e drejtorive të projekteve në të cilat nuk merr pjesë. Ai nuk mund ta ndryshojë këtë vetë.

Duke pasur parasysh se themeli i këtij principi është siguria bazë e të drejtave Linux, kjo skemë është e besueshme. Për më tepër, skema administrohet shumë lehtë.

Të kalojmë në praktikë.

Krijimi i repozitoreve Git në serverin Linux

Po 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

më ka ngelë të shkruaj 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

Sigurohemi se nga komanda nuk është e mundur të aksesosh repozitorët e të tjerëve dhe as të shikosh përmbajtjen e tyre.

[dev1@server ~]$ cd /var/gitservertest/proj3
-bash: cd: /var/gitservertest/proj3: Leje e refuzuar
[dev1@server ~]$ ls /var/gitservertest/proj3
ls: nuk mund të hapësh drejtorinë /var/gitservertest/proj3: Leje e refuzuar

Bashkëpunimi në Git i disa zhvilluesve mbi një projekt të vetëm

Nuk mbetet tjetër pyetje, nëse një zhvillues fut një skedar të ri, zhvilluesit e tjerë nuk mund ta ndryshojnë atë, sepse ai vetë është pronar (për shembull, dev1), dhe jo përdorues-pronar i projektit (për shembull, proj1). Duke pasur parasysh që kemi një repozitor serveri, para së gjithash, duhet të dimë si është strukturuar direktoria " .git" dhe nëse krijohen skedarë të rinj.

Krijimi i një repozitori lokal Git dhe push në serverin Git

Të kalojmë në makinën klient.

Microsoft Windows [Version 6.1.7601]
(c) Korporata Microsoft (Microsoft Corp.), 2009. Të gjitha të drejtat e rezervuara.

C:gittest>git init .
Repository i ri Git u inicializua në C: /gittest/ .git/ 

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

C:gittest>git add .

C:gittest>git status
Në degën master
Nuk ka komitë deri tani
Ndryshimet për t'u angazhuar:
  (përdorni "git rm --cached <file>..." për të hequr angazhimin)
        skedar i ri:   test1.txt

C:gittest>git commit -am "skedari i ri i testit u shtua"
[master (root-commit) a7ac614] skedari i ri i testit u shtua
 1 skedar ndryshuar, 1 shtesë (+)
 krijo gjendjen 100644 test1.txt
 
C:gittest>git remote add origin "ssh://dev1@10.1.1.11/var/gitservertest/proj2"

C:gittest>git push origin master
dev1:dev1@10.1.1.11's password:
Numërimi i objekteve: 3, përfunduar.
Shkruaj objektet: 100% (3/3), 243 bytes | 243.00 KiB/s, përfunduar.
Totali 3 (delta 0), e ripërdorur 0 (delta 0)
NĂ« ssh://10.1.1.11/var/gitservertest/proj2
 * [dega e re]      master -> master

C:gittest>

Në të njëjtën kohë, në server krijohen skedare të rinj, dhe ata i përkasin përdoruesit që bëri push.

[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 katalogë, 18 skedare
[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 ngarkohen ndryshime në server, krijohen skedare dhe katalogë shtesë, dhe pronari i tyre në të vërtetë është ai përdorues që bën ngarkimin. Por atëherë, grupi i këtyre skedarëve dhe katalogëve gjithashtu përputhet me grupin kryesor të këtij përdoruesi, dmth, grupi dev1 për përdoruesin dev1 dhe grupi dev2 për përdoruesin dev2 (ndryshimi i grupit kryesor të përdoruesit të zhvilluesit nuk do të ndihmojë, sepse si mund të punosh mbi disa projekte?). Në këtë rast, përdoruesi dev2 nuk do të jetë në gjendje të ndryshojë skedarët e krijuar nga përdoruesi dev1, dhe kjo rrezikon funksionalitetin.

Linux chown — ndryshimi i pronarit tĂ« skedarit nga njĂ« pĂ«rdorues i zakonshĂ«m.

Pronari i skedarit nuk mund të ndryshojë përkatësinë e tij. Por ai mund të ndryshojë grupin e skedarit, që i përket atij, dhe atëherë ky skedar mund të jetë në dispozicion për ndryshim nga përdorues të tjerë që janë në të njëjtin grup. Kjo është ajo që na nevojitet.

PĂ«rdorimi i Git hook

Direktoria e punës për hook është direktoria kryesore e projektit. Hook është një skedar ekzekutiv që ekzekutohet nën përdoruesin që bën push. Duke e ditur këtë, ne mund të realizojmë atë që kemi planifikuar.

[dev1@server proj2]$ mv hooks/post-update{.sample,}
[dev1@server proj2]$ sed -i '2,$ s/^/#/' hooks/post-update
[dev1@server proj2]$ cat <<> hooks/post-update

ose thjesht

vi hooks/post-update

Kthehemi në makinën 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:dev1@10.1.1.11's password:
   d22c66e..b045e22  master -> master

Në serverin Git kontrollojmë pas commit-it punën e skriptit hook post-update

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

— bosh, gjithçka Ă«shtĂ« nĂ« rregull.

Përfshirja e zhvilluesit të dytë në Git

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

NĂ« klient

C:gittest>git remote remove origin

C:gittest>git remote add origin "ssh://dev2@10.1.1.11/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
dev2@10.1.1.11's password:
   b045e22..55d49a6  master -> master

Ndërkohë, në server


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

— pĂ«rsĂ«ri bosh, gjithçka funksionon.

Fshirja e projektit Git dhe ngarkimi i projektit nga serveri Git

Mirë, mund të sigurohemi përsëri që të gjitha ndryshimet janë ruajtur.

C:gittest>rd /S /Q .
Procesi nuk mund të aksesojë skedarin sepse ky skedar është i angazhuar nga një proces tjetër.

— pĂ«r tĂ« fshirĂ« projektin Git, thjesht pastrojmĂ« plotĂ«sisht direktorinĂ«. TĂ« pajtohemi me gabimin e shfaqur, sepse nuk Ă«shtĂ« e mundur tĂ« fshihet direktoria aktuale me kĂ«tĂ« komandĂ«, por na duhet pikĂ«risht ky sjellje.

C:gittest>dir
 PĂ«rmbajtja e dosjes C:gittest

21.06.2019  08:43              .
21.06.2019  08:43              ..

C:gittest>git clone ssh://dev2@10.1.1.11/var/gitservertest/proj2
Klonimi në 'proj2'...
dev2@10.1.1.11's password:

C:gittest>cd proj2

C:gittestproj2>dir
 PĂ«rmbajtja e dosjes C:gittestproj2

21.06.2019  08:46              .
21.06.2019  08:46              ..
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"

Ndara e qasjes në Git

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

C:gittestproj2>git remote remove origin

C:gittestproj2>git remote add origin "ssh://dev2@10.1.1.11/var/gitservertest/proj1"

C:gittestproj2>git push origin master
dev2@10.1.1.11's password:
fatal: '/var/gitservertest/proj1' nuk ka dukur si një deposh git
fatal: Nuk mund të lexoj nga depoja e largët.

Ju lutemi sigurohuni që keni të drejtat e duhura të aksesit
dhe depoja ekziston.

Tani lejojmë aksesin

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

dhe pas kësaj gjithçka funksionon.

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

Informacione shtesë

Nëse ka një problem me të drejtat e parazgjedhura në krijimin e skedarëve dhe dosjeve, 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Ă«rtosh njĂ« pemĂ« katalogĂ«sh nĂ« Linux
  • si nĂ« sed tĂ« kalosh njĂ« gamĂ« adresash nga njĂ« rresht i caktuar deri nĂ« fund tĂ« skedarit, dmth, tĂ« bĂ«sh zĂ«vendĂ«sim nĂ« sed nĂ« tĂ« gjitha rreshtat pĂ«rveç rreshtit tĂ« parĂ«
  • Si nĂ« Linux tĂ« inversosh kushtin e kĂ«rkimit me find
  • si nĂ« shellin e Linux tĂ« kalosh disa rreshta nĂ« njĂ« cikĂ«l pĂ«rmes njĂ« njĂ«linjĂ«shi
  • si nĂ« bash tĂ« ekranoje citatet e vetme
  • si nĂ« komandĂ«n e Windows tĂ« fshish njĂ« dosje me tĂ« gjitha pĂ«rmbajtjet
  • Si me bash mv tĂ« rinomosh njĂ« skedare pa e shkruar atĂ« nga e para

Faleminderit për vëmendjen.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster