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

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

Kur ndodhe instalimi dhe konfigurimi i një serveri Git, ngrihet pyetja për organizimin e qasjes së disa përdoruesve në disa projekte. Kam bërë një hulumtim mbi këtë çështje dhe kam gjetur një zgjidhje që përmbush të gjitha kërkesat e mia: e thjeshtë, të sigurt dhe të besueshme.

Dëshirat e mia janë si më poshtë:

  • çdo pĂ«rdorues lidhet me llogarinĂ« e tij personale
  • mbi njĂ« projekt mund tĂ« punojnĂ« disa pĂ«rdorues
  • i njĂ«jti pĂ«rdorues mund tĂ« punojĂ« mbi disa projekte
  • çdo pĂ«rdorues ka qasje vetĂ«m nĂ« projektet mbi tĂ« cilat punon
  • duhet tĂ« ketĂ« mundĂ«sinĂ« e lidhjes pĂ«rmes komandĂ«s, jo vetĂ«m pĂ«rmes njĂ« ndĂ«rfaqeje web

Gjithashtu do të ishte mirë:

  • tĂ« ofrohen tĂ« drejtat vetĂ«m pĂ«r lexim pĂ«r personat qĂ« mbikĂ«qyrin
  • tĂ« jetĂ« e lehtĂ« pĂ«r tĂ« menaxhuar tĂ« drejtat e pĂ«rdoruesve nĂ« Git

Konsiderata mbi mundësitë e qasjes në serverin GIT

Para së gjithash, është e nevojshme të kuptohet se nga çfarë duhet të zgjedhim, prandaj një përmbledhje e shkurtër e protokolleve Git.

  • ssh — pĂ«r qasje nĂ« server pĂ«rdoret njĂ« llogari pĂ«rdoruesi e caktuar.
    • e çuditshme, qĂ« Git nuk pĂ«rjashton nga rekomandimet pĂ«rdorimin e njĂ« llogarie pĂ«r qasje nĂ« tĂ« gjitha repozitat. Kjo nuk i pĂ«rputhet kĂ«rkesave tĂ« mia.
    • mund tĂ« pĂ«rdoren disa llogari, por si mund tĂ« kufizohet qasja e pĂ«rdoruesit vetĂ«m nĂ« drejtoritĂ« e caktuara?
      • Mbyllja nĂ« drejtorinĂ« e shtĂ«pisĂ« nuk Ă«shtĂ« e pĂ«rshtatshme, sepse Ă«shtĂ« e vĂ«shtirĂ« tĂ« organizohet qasje shkruese pĂ«r pĂ«rdoruesit e tjerĂ«.
      • PĂ«rdorimi i lidhjeve simbolike nga direktorĂ«t e shtĂ«pisĂ« Ă«shtĂ« gjithashtu i nd tricky pĂ«r shkak se Git nuk i interpreton ato si lidhje.
      • Kufizimi i qasjes nĂ« interpretuese, mundet, por nuk ka njĂ« garanci tĂ« plotĂ« se do tĂ« funksionojĂ« gjithmonĂ«.
        • Mund tĂ« lidhet pĂ«r kĂ«ta pĂ«rdorues njĂ« interpretuese komande e veçantĂ«, por
          • nĂ« radhĂ« tĂ« parĂ«, kjo Ă«shtĂ« njĂ« zgjidhje mjaft e komplikuar,
          • dhe nĂ« radhĂ« tĂ« dytĂ«, mund tĂ« anashkalohet.

    Por, ndoshta, kjo nuk është një problem që përdoruesi mund të ekzekutojë çfarëdo komandash?.. Në përgjithësi, nuk mund të përjashtohet ky metodë, nëse mendojmë se si të përdoret. Le të kthehemi te ky metodë më vonë, ndërkohë le të shqyrtojmë alternativat e tjera, ndoshta aty do të gjejmë diçka më të thjeshtë.

  • protokolli git local mund tĂ« pĂ«rdoret nĂ« kombinim me sshfs, mund tĂ« pĂ«rdoren disa pĂ«rdorues, por nĂ« thelb, Ă«shtĂ« e njĂ«jta gjĂ« si rasti i mĂ«parshĂ«m.
  • http — vetĂ«m pĂ«r lexim
  • git — vetĂ«m pĂ«r lexim
  • https — i vĂ«shtirĂ« pĂ«r t’u instaluar, ka nevojĂ« pĂ«r ekstra software, ndonjĂ« paneli i menaxhimit pĂ«r organizimin e qasjes sĂ« pĂ«rdoruesve
 duket e realizueshme, por gjithçka duket e komplikuar.

Përdorimi i protokollit ssh për organizimin e qasjes me disa përdorues në serverin Git

Le të kthehemi në protokollin ssh.

Duke qenë se përdoret qasja përmes ssh në git, duhet të sigurohet sigurimi i të dhënave të serverit. Përdoruesi që lidhet përmes ssh përdor identifikimin e tij në serveri Linux, për këtë arsye mund të lidhë përmes klientit ssh dhe të ketë qasje në komandën e serverit.
Nuk ka një mbrojtje të plotë nga marrja e tillë e qasjes.

Por për përdoruesin nuk duhet të jenë interesante skedarët e Linux. Informacioni thelbësor ruhet vetëm në repozitorin git. Prandaj nuk është e nevojshme të kufizohet qasja përmes komandës, por me mjetet e Linux duhet të ndalohet përdoruesi të shikojë projektet, përveç atyre në të cilat merr pjesë.
Pa dyshim duhet të përdoret sistemi i të drejtave të qasjes të Linux.

Siç përmendëm më parë, është e mundur të përdoret vetëm një llogari për qasjen ssh. Kjo konfigurim është jo e sigurt për disa përdorues, megjithatë ky metodë është përfshirë në listën e mundësive të rekomanduara nga git.

Për të realizuar kërkesat e përmendura në fillim të artikullit, do të krijohet struktura e mëposhtme e direktorive me të drejtat dhe pronarët të caktuar:

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 — janĂ« pĂ«rdoruesit e krijuar posaçërisht nĂ« Linux, tĂ« cilĂ«ve u caktohen pronarĂ«t e direktorĂ«ve tĂ« projekteve pĂ«rkatĂ«se.

tĂ« drejtat pĂ«r tĂ« gjitha direktorĂ«t janĂ« caktuar 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 kryesore është që zhvilluesve u caktohet një grup shtesë i përdoruesit sistematik pronar i projektit përkatës. Kjo bëhet nga administratori i serverit Linux me një komandë.

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

Nëse ndonjë nga Zhvilluesit lidhet përmes ssh përmes komandës, ai do të ketë të drejta të pamjaftueshme 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 qenë se baza e këtij principi është siguria themelore e të drejtave Linux, ky skemë është e besueshme. Për më tepër, skema është shumë e lehtë për t'u administruar.

Le të kalojmë në praktikë.

Krijimi i git repositorive 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

e kam të mërzitshme 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

Jemi të sigurt se, nga linjëja e komandës, nuk është e mundur të aksesosh repo të të tjerëve dhe madje as të shohësh 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

Puna në grup në Git nga disa zhvillues mbi një projekt të vetëm

Ka mbetur njĂ« pyetje, nĂ«se njĂ« zhvillues shton njĂ« skedh tĂ« ri, zhvilluesit e tjerĂ« nuk mund ta ndryshojnĂ« atĂ«, sepse ai vetĂ« Ă«shtĂ« pronari i saj (pĂ«r shembull, dev1), dhe jo pĂ«rdoruesi-pronar i projektit (pĂ«r shembull, proj1). Duke qenĂ« se kemi njĂ« repozitor tĂ« serverit, para sĂ« gjithash, duhet tĂ« dimĂ« si funksionon direktoria “.git” dhe nĂ«se krijohen skedarĂ« tĂ« rinj.

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

Le të kalojmë në makinën klient.

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

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 ..." 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://dev1@10.1.1.11/var/gitservertest/proj2"

C:gittest>git push origin master
dev1:dev1@10.1.1.11'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ë, në server krijohen skedarë 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 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 ndryshimet në server, Git krijon skedarë dhe drejtorë shtesë, dhe pronari i tyre është saktësisht përdoruesi që bën ngarkimin. Por atëherë grupi i këtyre skedarëve dhe drejtorive gjithashtu i përket grupit 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 zhvillues nuk ndihmon, pasi si mund të punoni me 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 do të shkaktojë probleme funksionaliteti.

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, dhe atëherë ky skedar mund të jetë i aksesueshëm për ndryshim nga përdoruesit e tjerë që janë në të njëjtin grup. Ky ë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, i cili ekzekutohet nga përdoruesi që bëri push. Duke e ditur këtë, ne mund ta 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

Le të kthehemi në makinën klient.

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 komitimit funksionimin e skriptit hook post-update

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

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

Kyçja e zhvilluesit të dytë në Git

Do të imitojmë 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

Dhe në të njëjtën kohë, 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

Mund të sigurohemi sërish që të gjitha ndryshimet janë ruajtur.

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

— pĂ«r tĂ« fshirĂ« projektin Git, thjesht pastroni direktorinĂ« plotĂ«sisht. Do tĂ« pajtohemi me gabimin e dhĂ«nĂ«, pasi nuk Ă«shtĂ« e mundur tĂ« fshihet direktoria aktuale me kĂ«tĂ« komandĂ«, por nĂ« tĂ« vĂ«rtetĂ« na nevojitet ky funksionim.

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
Cloning into '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"

Bashkimi i aksesit në Git

Tani do të sigurohemi se edhe përmes Git zhvilluesi i dytë nuk mund të aksesojë projektin Proj1, në të cilin ai nuk 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 duket si një depo git
fatal: Nuk mund të lexoj nga depoja remote.

Ju lutem 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:
NĂ« ssh://10.1.1.11/var/gitservertest/proj1
 * [një degë e re]      master -> master

Informacione të tjera

Për më tepër, nëse ka një problem me të drejtat e paracaktuar 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

Në këtë artikull gjithashtu mund të gjeni disa gjëra të dobishme:

  • si tĂ« ndĂ«rtoni njĂ« pemĂ« katalogĂ«sh nĂ« Linux
  • si tĂ« dĂ«rgoni njĂ« diapazon adresash nĂ« sed nga njĂ« rresht i caktuar deri nĂ« fund tĂ« skedarit, pra, tĂ« bĂ«ni nĂ« sed zĂ«vendĂ«sim nĂ« tĂ« gjitha rreshtat pĂ«rveç rreshtit tĂ« parĂ«
  • Si tĂ« invertoni kushte kĂ«rkimi me find nĂ« Linux
  • si tĂ« dĂ«rgoni disa rreshta nĂ« njĂ« cikĂ«l pĂ«rmes njĂ« linje tĂ« vetme nĂ« shell-in Linux
  • si tĂ« ekranuar njĂ«zit e vetme nĂ« bash
  • si tĂ« fshini njĂ« direktori me tĂ« gjithĂ« pĂ«rmbajtjen nĂ« komandĂ«n e linjĂ«s nĂ« Windows
  • Si me bash mv tĂ« riemĂ«roni njĂ« skedar, pa e ripĂ«rvjetuar atĂ«

Faleminderit për vëmendjen.

Burimi: habr.com

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