ProHoster > Blog > Stjórnsýsla > Skipulag fjölnotendaaðgangs að GIT þjóninum

Skipulag fjölnotendaaðgangs að GIT þjóninum

Þegar þú setur upp og stillir Git miðlara, vaknar spurningin um að skipuleggja aðgang fyrir nokkra notendur að nokkrum verkefnum. Ég rannsakaði málið og fann lausn sem uppfyllti allar kröfur mínar: einföld, örugg, áreiðanleg.

Mínar óskir eru:

  • hver notandi tengist eigin reikningi
  • Nokkrir notendur geta unnið að einu verkefni
  • sami notandi getur unnið að mörgum verkefnum
  • hver notandi hefur aðeins aðgang að þeim verkefnum sem hann vinnur að
  • Það ætti að vera hægt að tengjast í gegnum skipanalínuna, en ekki bara í gegnum einhvers konar vefviðmót

Það væri líka frábært:

  • veita skrifvarandi heimildir til stjórnenda
  • Stjórnaðu notendaaðgangsréttindum á þægilegan hátt í Git

Yfirlit yfir mögulega valkosti til að fá aðgang að GIT þjóninum

Fyrst af öllu þarftu að vita hvað á að velja úr, svo hér er fljótlegt yfirlit yfir Git samskiptareglur.

  • ssh - sérstakur notendareikningur er notaður til að fá aðgang að þjóninum.
    • Það er undarlegt að Git útilokar ekki frá ráðleggingum sínum notkun á einum reikningi til að fá aðgang að öllum geymslum. Þetta uppfyllir alls ekki kröfurnar mínar.
    • Þú getur notað marga reikninga, en hvernig geturðu takmarkað aðgang notenda við aðeins ákveðnar möppur?
      • Það hentar ekki að loka inn í heimaskrána þar sem erfitt er að skipuleggja skrifaðgang þar fyrir aðra notendur
      • Það er líka erfitt að nota tákntengla úr heimaskránni þinni vegna þess að Git túlkar þá ekki sem tengla
      • Það er hægt að takmarka aðgang að túlknum en engin full trygging er fyrir því að það virki alltaf
        • Þú getur almennt tengt þinn eigin skipanatúlk fyrir slíka notendur, en
          • í fyrsta lagi er þetta nú þegar einhvers konar erfið ákvörðun,
          • og í öðru lagi er hægt að sniðganga þetta.

    En kannski er það ekki vandamál að notandinn geti framkvæmt einhverjar skipanir?.. Almennt séð er ekki hægt að útiloka þessa aðferð ef þú finnur út nákvæmlega hvernig á að nota hana. Við munum snúa aftur að þessari aðferð síðar, en í bili munum við íhuga aðra valkosti í stuttu máli, kannski verður eitthvað einfaldara.

  • Hægt er að nota git staðbundna samskiptareglur ásamt sshfs, hægt er að nota marga notendur, en í meginatriðum það sama og fyrra tilvikið
  • http - skrifvarinn
  • git er skrifvarinn
  • https - erfitt að setja upp, þú þarft viðbótarhugbúnað, einhvers konar stjórnborð til að skipuleggja aðgang notenda... það lítur út fyrir að vera gerlegt, en einhvern veginn er allt flókið.

Notkun ssh samskiptareglur til að skipuleggja aðgang margra notenda að Git netþjóninum

Snúum okkur aftur að ssh samskiptareglunum.

Þar sem þú notar ssh aðgang fyrir git þarftu að tryggja öryggi netþjónsgagnanna. Notandinn sem tengist í gegnum ssh notar eigin innskráningu á Linux þjóninum, þannig að þeir geta tengst í gegnum ssh biðlarann ​​og fengið aðgang að skipanalínu þjónsins.
Það er engin fullkomin vörn gegn slíkum aðgangi.

En notandinn ætti ekki að hafa áhuga á Linux skrám. Mikilvægar upplýsingar eru aðeins geymdar í git geymslunni. Þess vegna er ekki hægt að takmarka aðgang í gegnum skipanalínuna heldur nota Linux verkfæri til að banna notandanum að skoða verkefni, að undanskildum þeim sem hann tekur þátt í.
Augljósi kosturinn er að nota Linux leyfiskerfið.

Eins og áður hefur komið fram er aðeins hægt að nota einn reikning fyrir ssh aðgang. Þessi uppsetning er óörugg fyrir nokkra notendur, þó hún sé innifalin á listanum yfir ráðlagða git valkosti.

Til að innleiða kröfurnar sem gefnar eru upp í upphafi greinarinnar er eftirfarandi skráarskipulag búið til með framsali réttinda og eigenda:

1) verkefnaskrár

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
þar sem
dir1, dir2, dir3 - verkefnaskrár: verkefni 1, verkefni 2, verkefni 3.

proj1:proj1, proj2:proj2, proj3:proj3 eru sérstaklega búnir Linux notendur sem eru úthlutaðir sem eigendum samsvarandi verkefnaskráa.

heimildir fyrir allar möppur eru stilltar á 0770 - fullur aðgangur fyrir eiganda og hóp hans og algjört bann fyrir alla aðra.

2) þróunarreikningar

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

Lykilatriðið er að verktaki er úthlutað viðbótarhópi kerfisnotenda eiganda samsvarandi verkefnis. Þetta er gert af Linux netþjónsstjóra með einni skipun.

Í þessu dæmi er "Þróandi 1" að vinna að verkefnum proj1 og proj2 og "Þróandi 2" er að vinna að verkefnum proj2 og proj3.

Ef einhver af hönnuðunum tengist í gegnum ssh í gegnum skipanalínuna, þá mun réttindi þeirra ekki nægja jafnvel til að skoða innihald verkefnaskráa sem þeir taka ekki þátt í. Hann getur ekki breytt þessu sjálfur.

Þar sem grundvöllur þessarar meginreglu er grunnöryggi Linux réttinda er þetta kerfi áreiðanlegt. Að auki er kerfið mjög auðvelt í umsjón.

Við skulum halda áfram að æfa.

Að búa til Git geymslur á Linux netþjóni

Við skulum athuga.

[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

Ég er þreytt á að skrifa í höndunum...

[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

Við erum sannfærð um að það er ómögulegt að fá aðgang að geymslum annarra frá skipanalínunni og jafnvel skoða innihald þeirra.

[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

Vertu í samstarfi við marga forritara um sama verkefni í Git

Ein spurning er eftir, ef einn verktaki kynnir nýja skrá, þá geta aðrir forritarar ekki breytt henni, vegna þess að hann sjálfur er eigandi hennar (til dæmis dev1), en ekki notandi eigandi verkefnisins (til dæmis proj1). Þar sem við erum með geymsla á þjóninum, þurfum við fyrst og fremst að vita hvernig „.git“ skráin er byggð upp og hvort nýjar skrár eru búnar til.

Að búa til staðbundna Git geymslu og ýta á Git netþjóninn

Við skulum halda áfram í biðlaravélina.

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>

Á sama tíma eru nýjar skrár búnar til á þjóninum og þær tilheyra notandanum sem framkvæmdi ýtuna

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

Þegar þú hleður upp breytingum á Git netþjóninn verða viðbótarskrár og möppur búnar til og eigandi þeirra er í raun notandinn sem gerir upphleðsluna. En þá samsvarar hópurinn af þessum skrám og möppum líka aðalhópi þessa notanda, það er dev1 hópurinn fyrir dev1 notandann og dev2 hópinn fyrir dev2 notandann (að breyta aðalhópi þróunarnotandans hjálpar ekki, því hvernig geturðu þá unnið að mörgum verkefnum?). Í þessu tilviki mun notandi dev2 ekki geta breytt skrám sem eru búnar til af notanda dev1, sem gæti leitt til sundurliðunar á virkni.

Linux chown - að skipta um eiganda skráar af venjulegum notanda

Eigandi skráar getur ekki breytt eignarhaldi hennar. En hann getur breytt hópnum á skrá sem tilheyrir honum, og þá geta aðrir notendur sem eru í sama hópi breytt þessari skrá. Það er það sem við þurfum.

Notaðu Git hook

Vinnuskráin fyrir krók er rótarskrá verkefnisins. hook er keyrsla sem keyrir undir notandanum sem ýtir. Með því að vita þetta getum við framkvæmt áætlanir okkar.

[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

eða bara 

vi hooks/post-update

Snúum okkur aftur að viðskiptavinavélinni.

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 þjóninum athugum við virkni króks eftir uppfærslu skriftu eftir commit 

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

- tómt, allt er í lagi.

Að tengja annan forritara í Git

Við skulum líkja eftir vinnu seinni verktaki.

Á viðskiptavininn

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

Og á sama tíma, á þjóninum...

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

— aftur tómt, allt virkar.

Að eyða Git verkefni og hlaða niður verkefninu af Git þjóninum

Jæja, þú getur enn og aftur gengið úr skugga um að allar breytingar hafi verið vistaðar.

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

— til að eyða Git verkefni, hreinsaðu einfaldlega möppuna alveg. Við skulum sætta okkur við villuna sem myndast, þar sem það er ómögulegt að eyða núverandi möppu með þessari skipun, en þetta er nákvæmlega hegðunin sem við þurfum.

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"

Að deila aðgangi í Git

Nú skulum við ganga úr skugga um að jafnvel í gegnum Git hefur annar verktaki ekki aðgang að Proj1 verkefninu, sem hann er ekki að vinna í.

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.

Nú leyfum við aðgang

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

og eftir það virkar allt.

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

Fyrir frekari upplýsingar,

Að auki, ef það er vandamál með sjálfgefna heimildir þegar þú býrð til skrár og möppur, í CentOS geturðu notað skipunina

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

Einnig í greininni gætirðu lent í litlum gagnlegum hlutum:

  • hvernig á að byggja upp möpputré í Linux
  • hvernig á að senda fjölda vistfönga í sed frá ákveðinni línu til loka skráarinnar, það er að skipta út í sed í öllum línum nema fyrstu línu
  • Hvernig á að snúa við leitarskilyrði í Linux finna
  • Hvernig á að senda margar línur í lykkju með því að nota einnar línu í Linux skelinni
  • Hvernig á að flýja stakar tilvitnanir í bash
  • hvernig á að eyða möppu með öllu innihaldi hennar í Windows skipanalínunni
  • Hvernig á að nota bash mv til að endurnefna skrá án þess að endurskrifa hana aftur

Þakka þér fyrir athygli þína.

Heimild: www.habr.com

Bæta við athugasemd