ProHoster > blog > Gweinyddiaeth > Trefniadaeth mynediad aml-ddefnyddiwr i'r gweinydd GIT

Trefniadaeth mynediad aml-ddefnyddiwr i'r gweinydd GIT

Wrth osod a ffurfweddu gweinydd Git, mae'r cwestiwn yn codi ynghylch trefnu mynediad i sawl defnyddiwr i sawl prosiect. Ymchwiliais i'r mater a dod o hyd i ateb a oedd yn bodloni fy holl ofynion: syml, diogel, dibynadwy.

Fy nymuniadau yw:

  • mae pob defnyddiwr yn cysylltu â'i gyfrif ei hun
  • Gall nifer o ddefnyddwyr weithio ar un prosiect
  • gall yr un defnyddiwr weithio ar brosiectau lluosog
  • dim ond y prosiectau hynny y mae'n gweithio arnynt y mae gan bob defnyddiwr fynediad
  • Dylai fod yn bosibl cysylltu trwy'r llinell orchymyn, ac nid trwy ryw fath o ryngwyneb gwe yn unig

Byddai hefyd yn wych:

  • rhoi caniatâd darllen yn unig i reoli personau
  • Rheoli hawliau mynediad defnyddwyr yn Git yn gyfleus

Trosolwg o opsiynau posibl ar gyfer cyrchu gweinydd GIT

Yn gyntaf oll, mae angen i chi wybod beth i'w ddewis, felly dyma drosolwg cyflym o brotocolau Git.

  • ssh - mae cyfrif defnyddiwr a grëwyd yn arbennig yn cael ei ddefnyddio i gael mynediad i'r gweinydd.
    • Mae'n rhyfedd nad yw Git yn eithrio o'i argymhellion y defnydd o un cyfrif i gael mynediad i bob cadwrfa. Nid yw hyn yn bodloni fy ngofynion o gwbl.
    • Gallwch ddefnyddio cyfrifon lluosog, ond sut allwch chi gyfyngu mynediad defnyddwyr i gyfeiriaduron penodol yn unig?
      • Nid yw cau i mewn i'r cyfeiriadur cartref yn addas, oherwydd mae'n anodd trefnu mynediad ysgrifennu yno i ddefnyddwyr eraill
      • Mae defnyddio symlinks o'ch cyfeiriadur cartref hefyd yn anodd oherwydd nid yw Git yn eu dehongli fel dolenni
      • Mae'n bosibl cyfyngu mynediad i'r cyfieithydd, ond nid oes sicrwydd llawn y bydd bob amser yn gweithio
        • Yn gyffredinol, gallwch gysylltu eich cyfieithydd gorchymyn eich hun ar gyfer defnyddwyr o'r fath, ond
          • yn gyntaf, mae hwn eisoes yn rhyw fath o benderfyniad anodd,
          • ac yn ail, gellir osgoi hyn.

    Ond efallai nad yw'n broblem y bydd y defnyddiwr yn gallu gweithredu unrhyw orchmynion?... Yn gyffredinol, ni ellir diystyru'r dull hwn os ydych chi'n darganfod yn union sut i'w ddefnyddio. Byddwn yn dychwelyd at y dull hwn yn nes ymlaen, ond am y tro byddwn yn ystyried y dewisiadau eraill yn fyr, efallai y bydd rhywbeth symlach.

  • Gellir defnyddio'r protocol lleol git mewn cyfuniad â sshfs, gellir defnyddio defnyddwyr lluosog, ond yn y bôn yr un peth â'r achos blaenorol
  • http - darllen yn unig
  • mae git yn ddarllen-yn-unig
  • https - anodd ei osod, mae angen meddalwedd ychwanegol arnoch, rhyw fath o banel rheoli i drefnu mynediad defnyddwyr... mae'n edrych yn ymarferol, ond rhywsut mae popeth yn gymhleth.

Defnyddio'r protocol ssh i drefnu mynediad aml-ddefnyddiwr i'r gweinydd Git

Gadewch i ni ddychwelyd at y protocol ssh.

Gan eich bod yn defnyddio mynediad ssh ar gyfer git, mae angen i chi sicrhau diogelwch data'r gweinydd. Mae'r defnyddiwr sy'n cysylltu trwy ssh yn defnyddio eu mewngofnodi eu hunain ar y gweinydd Linux, fel y gallant gysylltu trwy'r cleient ssh a chyrchu llinell orchymyn y gweinydd.
Nid oes amddiffyniad llwyr yn erbyn mynediad o'r fath.

Ond ni ddylai'r defnyddiwr fod â diddordeb mewn ffeiliau Linux. Mae gwybodaeth sylweddol yn cael ei storio yn y gadwrfa git yn unig. Felly, mae'n bosibl peidio â chyfyngu mynediad trwy'r llinell orchymyn, ond defnyddio offer Linux i wahardd y defnyddiwr rhag gwylio prosiectau, ac eithrio'r rhai y mae'n cymryd rhan ynddynt.
Y dewis amlwg yw defnyddio'r system caniatâd Linux.

Fel y soniwyd eisoes, dim ond un cyfrif y mae'n bosibl ei ddefnyddio ar gyfer mynediad ssh. Mae'r cyfluniad hwn yn anniogel i sawl defnyddiwr, er ei fod wedi'i gynnwys yn y rhestr o opsiynau git a argymhellir.

Er mwyn gweithredu'r gofynion a roddir ar ddechrau'r erthygl, crëir y strwythur cyfeiriadur canlynol gyda'r aseiniad hawliau a pherchnogion:

1) cyfeiriaduron prosiect

dir1(prosiect1:proj1,0770)
dir2(prosiect2:proj2,0770)
dir3(prosiect3:proj3,0770)
...
lle
dir1, dir2, dir3 - cyfeiriaduron prosiect: project 1, project 2, project 3.

Mae proj1: proj1, proj2: proj2, proj3:proj3 yn ddefnyddwyr Linux a grëwyd yn arbennig sy'n cael eu neilltuo fel perchnogion y cyfeiriaduron prosiect cyfatebol.

mae caniatâd ar gyfer pob cyfeiriadur wedi'i osod i 0770 - mynediad llawn i'r perchennog a'i grŵp a gwaharddiad llwyr i bawb arall.

2) cyfrifon datblygwr

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

Y pwynt allweddol yw bod datblygwyr yn cael grŵp ychwanegol o berchennog defnyddiwr system y prosiect cyfatebol. Gwneir hyn gan weinyddwr gweinydd Linux gydag un gorchymyn.

Yn yr enghraifft hon, mae "Datblygwr 1" yn gweithio ar brosiectau proj1 a proj2, ac mae "Datblygwr 2" yn gweithio ar brosiectau proj2 a proj3.

Os bydd unrhyw un o'r Datblygwyr yn cysylltu trwy ssh trwy'r llinell orchymyn, yna ni fydd eu hawliau yn ddigonol hyd yn oed i weld cynnwys cyfeiriaduron prosiect nad ydynt yn cymryd rhan ynddynt. Ni all newid hyn ei hun.

Gan mai sail yr egwyddor hon yw diogelwch sylfaenol hawliau Linux, mae'r cynllun hwn yn ddibynadwy. Yn ogystal, mae'r cynllun yn hawdd iawn i'w weinyddu.

Gadewch i ni symud ymlaen i ymarfer.

Creu storfeydd Git ar weinydd Linux

Gadewch i ni wirio.

[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

Dwi wedi blino teipio gyda llaw...

[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

Rydym yn argyhoeddedig ei bod yn amhosibl cael mynediad i gadwrfeydd pobl eraill o'r llinell orchymyn a hyd yn oed weld eu cynnwys.

[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

Cydweithio â datblygwyr lluosog ar yr un prosiect yn Git

Erys un cwestiwn, os bydd un datblygwr yn cyflwyno ffeil newydd, yna ni all datblygwyr eraill ei newid, oherwydd ef ei hun yw ei berchennog (er enghraifft, dev1), ac nid perchennog defnyddiwr y prosiect (er enghraifft, proj1). Gan fod gennym ystorfa ochr y gweinydd, yn gyntaf oll, mae angen i ni wybod sut mae'r cyfeiriadur “.git” wedi'i strwythuro ac a yw ffeiliau newydd yn cael eu creu.

Creu ystorfa Git leol a gwthio i'r gweinydd Git

Gadewch i ni symud ymlaen i'r peiriant cleient.

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>

Ar yr un pryd, mae ffeiliau newydd yn cael eu creu ar y gweinydd, ac maen nhw'n perthyn i'r defnyddiwr a berfformiodd y gwthio

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

Pan fyddwch chi'n uwchlwytho newidiadau i'r gweinydd Git, mae ffeiliau a chyfeiriaduron ychwanegol yn cael eu creu, a'u perchennog mewn gwirionedd yw'r defnyddiwr sy'n llwytho i fyny. Ond yna mae'r grŵp o'r ffeiliau a'r cyfeirlyfrau hyn hefyd yn cyfateb i brif grŵp y defnyddiwr hwn, hynny yw, y grŵp dev1 ar gyfer y defnyddiwr dev1 a'r grŵp dev2 ar gyfer y defnyddiwr dev2 (ni fydd newid prif grŵp defnyddiwr y datblygwr yn helpu, oherwydd wedyn sut allwch chi weithio ar brosiectau lluosog?). Yn yr achos hwn, ni fydd defnyddiwr dev2 yn gallu newid ffeiliau a grëwyd gan user dev1, a allai arwain at ddadansoddiad mewn ymarferoldeb.

Linux chown - newid perchennog ffeil gan ddefnyddiwr rheolaidd

Ni all perchennog ffeil newid ei berchnogaeth. Ond gall newid y grŵp o ffeil sy'n perthyn iddo, ac yna gall y ffeil hon gael ei haddasu gan ddefnyddwyr eraill sydd yn yr un grŵp. Dyna sydd ei angen arnom.

Gan ddefnyddio bachyn Git

Y cyfeiriadur gweithio ar gyfer bachyn yw cyfeiriadur gwraidd y prosiect. bachyn yn weithredadwy sy'n rhedeg o dan y defnyddiwr yn gwneud y gwthio. O wybod hyn, gallwn roi ein cynlluniau ar waith.

[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

neu dim ond 

vi hooks/post-update

Gadewch i ni ddychwelyd i'r peiriant cleient.

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

Ar y gweinydd Git, rydym yn gwirio gweithrediad y sgript ôl-ddiweddariad bachyn ar ôl ymrwymo 

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

- gwag, popeth yn iawn.

Cysylltu ail ddatblygwr yn Git

Gadewch i ni efelychu gwaith yr ail ddatblygwr.

Ar y cleient

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

Ac ar yr un pryd, ar y gweinydd ...

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

- gwag eto, mae popeth yn gweithio.

Dileu prosiect Git a lawrlwytho'r prosiect o'r gweinydd Git

Wel, gallwch chi unwaith eto wneud yn siŵr bod yr holl newidiadau wedi'u cadw.

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

— i ddileu prosiect Git, cliriwch y cyfeiriadur yn llwyr. Gadewch i ni ddioddef y gwall a gynhyrchir, gan ei bod yn amhosibl dileu'r cyfeiriadur cyfredol gan ddefnyddio'r gorchymyn hwn, ond dyma'r union ymddygiad sydd ei angen arnom.

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"

Rhannu mynediad yn Git

Nawr, gadewch i ni sicrhau na all yr ail ddatblygwr, hyd yn oed trwy Git, gyrchu'r prosiect Proj1, nad yw'n gweithio arno.

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.

Nawr rydym yn caniatáu mynediad

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

ac ar ôl hynny mae popeth yn gweithio.

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

Am fwy o wybodaeth,

Yn ogystal, os oes problem gyda'r caniatâd diofyn wrth greu ffeiliau a chyfeiriaduron, yn CentOS gallwch ddefnyddio'r gorchymyn

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

Hefyd yn yr erthygl efallai y byddwch chi'n baglu ar bethau bach defnyddiol:

  • sut i adeiladu coeden cyfeiriadur yn Linux
  • sut i drosglwyddo ystod o gyfeiriadau mewn sed o linell benodol i ddiwedd y ffeil, hynny yw, gwneud un arall yn sed ym mhob llinell ac eithrio'r llinell gyntaf
  • Sut i wrthdroi cyflwr chwilio yn Linux find
  • Sut i basio llinellau lluosog i ddolen gan ddefnyddio un-leinin yn y gragen Linux
  • Sut i ddianc rhag dyfyniadau sengl yn bash
  • sut i ddileu cyfeiriadur gyda'i holl gynnwys yn llinell orchymyn windows
  • Sut i ddefnyddio bash mv i ailenwi ffeil heb ei hailysgrifennu eto

Diolch i chi am eich sylw.

Ffynhonnell: hab.com

Ychwanegu sylw