ProHoster > Blog > Bestjoer > Organisaasje fan meardere brûkers tagong ta de GIT-tsjinner

Organisaasje fan meardere brûkers tagong ta de GIT-tsjinner

By it ynstallearjen en konfigurearjen fan in Git-tsjinner, ûntstiet de fraach fan it organisearjen fan tagong foar ferskate brûkers ta ferskate projekten. Ik haw wat ûndersyk dien oer it probleem en fûn in oplossing dy't foldocht oan al myn easken: ienfâldich, feilich, betrouber.

Myn winsken binne:

  • elke brûker ferbynt mei har eigen akkount
  • Meardere brûkers kinne wurkje oan itselde projekt
  • deselde brûker kin wurkje oan meardere projekten
  • elke brûker hat allinich tagong ta dy projekten dêr't er oan wurket
  • it moat mooglik wêze om te ferbinen fia de kommandorigel, en net allinich fia in soarte fan webynterface

It soe ek geweldich wêze:

  • jouwe allinich-lêsrjochten oan kontrolearjende persoanen
  • maklik administraasje fan brûkersrjochten yn Git

Oersjoch fan mooglike opsjes foar tagong ta de GIT-tsjinner

Alderearst moatte jo witte wêrút te kiezen, dus in koart oersjoch fan 'e Git-protokollen.

  • ssh - in spesjaal oanmakke brûkersaccount wurdt brûkt om tagong te krijen ta de tsjinner.
    • it is nuver dat Git net advisearret om ien akkount te brûken om tagong te krijen ta alle repositories. Dit foldocht hielendal net oan myn easken.
    • Jo kinne meardere akkounts brûke, mar hoe kinne jo de tagong fan in brûker beheine ta allinich bepaalde mappen?
      • It sluten fan 'e thúsmap is net geskikt, om't it dreech is om skriuwtagong te organisearjen foar oare brûkers dêr
      • It brûken fan symboalyske keppelings út 'e thúsmap is ek lestich om't Git se net ynterpretearret as keppelings.
      • Beheine tagong ta de tolk, goed, do kinst, mar der is gjin folsleine garânsje dat dit sil altyd wurkje
        • Jo kinne oer it algemien jo eigen kommando-tolk ferbine foar sokke brûkers, mar,
          • earst, dit is al in soarte fan dreech beslút,
          • en 2, it kin wurde omjûn.

    Mar miskien is it gjin probleem dat de brûker alle kommando's kin útfiere? .. Yn 't algemien kin dizze metoade net útsletten wurde as jo útfine hoe't jo it brûke. Wy sille letter weromkomme nei dizze metoade, mar foar no sille wy de oerbleaune alternativen koart beskôgje, miskien sil d'r wat ienfâldiger wêze.

  • git lokaal protokol kin brûkt wurde yn kombinaasje mei sshfs, meardere brûkers kinne brûkt wurde, mar it is yn essinsje itselde as it foarige gefal
  • http - allinich lêzen
  • git is allinich lêzen
  • https is lestich te ynstallearjen, jo hawwe ekstra software nedich, in soarte fan kontrôlepaniel om brûkers tagong te organisearjen ... it liket mooglik, mar op ien of oare manier is alles yngewikkeld.

It ssh-protokol brûke om tagong fan meardere brûkers ta de Git-tsjinner te organisearjen

Litte wy weromgean nei it ssh-protokol.

Sûnt ssh-tagong wurdt brûkt foar git, moatte de servergegevens feilich wêze. De brûker dy't ferbynt fia ssh brûkt har eigen oanmelding op 'e Linux-tsjinner, sadat se kinne ferbine fia de ssh-client en tagong krije ta de kommandorigel fan 'e server.
Der is gjin folsleine beskerming tsjin it krijen fan sa'n tagong.

Mar de brûker moat net ynteressearre wêze yn Linux-bestannen. Sinfol ynformaasje wurdt allinich opslein yn it git-repository. Dêrom kinne jo tagong net beheine fia de kommandorigel, mar troch Linux ferbiede de brûker fan it besjen fan projekten, útsein dejingen wêryn hy meidocht.
It is fanselssprekkend om it Linux-tagongssysteem te brûken.

Lykas al neamd, is it mooglik om mar ien akkount te brûken foar ssh tagong. Dizze konfiguraasje is ûnfeilich foar ferskate brûkers, hoewol it is opnommen yn 'e list fan git mei oanrikkemandearre opsjes.

Om de easken oan it begjin fan it artikel út te fieren, wurdt de folgjende mapstruktuer makke mei de tawizing fan rjochten en eigners:

1) projektmappen

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
wêr
dir1, dir2, dir3 - projektmappen: projekt 1, projekt 2, projekt 3.

proj1: proj1, proj2: proj2, proj3: proj3 binne spesjaal makke Linux-brûkers dy't wurde tawiisd as de eigners fan de respektivelike projektmappen.

de rjochten op alle mappen binne ynsteld op 0770 - folsleine tagong foar de eigner en syn groep, en in folslein ferbod foar alle oaren.

2) ûntwikkeldersakkounts

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

It wichtichste punt is dat de ûntwikkelders in ekstra groep fan 'e systeembrûker wurde tawiisd dy't it oerienkommende projekt hat. Dit wurdt dien troch de Linux-tsjinnerbehearder mei ien kommando.

Yn dit foarbyld wurket Untwikkelder 1 oan projekten proj1 en proj2, en Untwikkelder 2 wurket oan projekten proj2 en proj3.

As ien fan 'e ûntwikkelders ferbynt fia ssh fia de kommandorigel, dan sille syn rjochten net genôch wêze, sels om de ynhâld fan' e mappen fan projekten te besjen wêryn hy net meidocht. Hy kin it sels net feroarje.

Sûnt de basis fan dit prinsipe is de basisfeiligens fan Linux-rjochten, is dit skema betrouber. Derneist is it skema tige maklik te administrearjen.

Litte wy trochgean nei de praktyk.

Git-repositories oanmeitsje op in Linux-tsjinner

Wy kontrolearje.

[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

wurch fan typen...

[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

Wy binne derfan oertsjûge dat it ûnmooglik is om tagong te krijen ta de repositories fan oaren fanút de kommandorigel en sels har ynhâld te besjen.

[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

Gearwurking yn Git fan ferskate ûntwikkelders op ien projekt

Ien fraach bliuwt, as ien ûntwikkelder in nij bestân yntrodusearret, dan kinne oare ûntwikkelders it net feroarje, om't hy sels de eigner is (bygelyks dev1), en net de brûker dy't it projekt hat (bygelyks proj1). Om't wy in serverrepository hawwe, moatte wy earst witte hoe't de map ".git" is regele en oft nije bestannen makke wurde.

Meitsje in lokale Git-repository en druk nei in Git-tsjinner

Lit ús gean nei de client masine.

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>

Tagelyk wurde nije bestannen generearre op 'e tsjinner, en se hearre ta de brûker dy't de push hat útfierd

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

As de wizigingen wurde opladen nei de Git-tsjinner, wurde ekstra bestannen en mappen oanmakke en binne eins eigendom fan de uploader. Mar dan komt de groep fan dizze bestannen en mappen ek oerien mei de haadgroep fan dizze brûker, dat is de dev1-groep foar de dev1-brûker en de dev2-groep foar de dev2-brûker (it feroarjen fan de haadgroep fan de ûntwikkeldersbrûker sil net helpe, om't dan hoe wurkje oan meardere projekten?). Yn dit gefal, de dev2 brûker sil net by steat wêze om te feroarjen de triemmen makke troch de dev1 brûker, en dit is beladen mei in ynbreuk op funksjonaliteit.

Linux chown - it feroarjen fan de eigner fan in bestân troch in normale brûker

De eigner fan in triem kin syn eigendom net feroarje. Mar hy kin feroarje de groep fan in triem dat heart by him, en dan dizze triem kin feroare wurde troch oare brûkers dy't yn deselde groep. Dat is wat wy nedich hawwe.

Mei help fan de Git Hook

De wurkmap foar hook is de rootmap fan it projekt. hook is in útfierbere triem dy't rint ûnder de brûker dy't de druk docht. wittende dit, kinne wy ​​útfiere ús plannen.

[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

of gewoan 

vi hooks/post-update

Litte wy weromgean nei de kliïntmasine.

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

Kontrolearje op 'e Git-tsjinner it wurk fan it hook post-update skript nei de commit 

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

- leech, alles is goed.

In twadde ûntwikkelder ferbine mei Git

Litte wy it wurk fan 'e twadde ûntwikkelder simulearje.

Op de klant

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

En tagelyk, op 'e server ...

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

- wer leech, alles wurket.

In Git-projekt wiskje en in projekt laden fan in Git-tsjinner

No, jo kinne opnij soargje dat alle wizigingen binne bewarre.

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

- om in Git-projekt te ferwiderjen, wiskje de map gewoan folslein. Litte wy de flater opjaan, om't it ûnmooglik is om de aktuele map te wiskjen mei dit kommando, mar dit is krekt it gedrach dat wy nedich binne.

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"

Tagong diele yn Git

Litte wy no derfoar soargje dat de twadde ûntwikkelder gjin tagong hat ta it Proj1-projekt fia Git, wêrop hy net wurket.

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.

Tastean no tagong

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

en dêrnei wurket alles.

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

Foar mear ynformaasje,

Derneist, as d'r in probleem is mei de standert tagongsrjochten by it meitsjen fan bestannen en mappen, kinne jo op CentOS it kommando brûke

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

Ek yn it artikel kinne jo stroffelje oer lytse nuttige dingen:

  • hoe't jo in mapbeam bouwe yn Linux
  • hoe't jo in berik fan adressen fan in bepaalde rigel trochjaan oan 'e ein fan' e triem yn sed, dat is, om in ferfanging te meitsjen yn sed yn alle rigels útsein de earste rigel
  • Hoe kinne jo sykbetingsten omkeare yn Linux fine
  • hoe't jo meardere rigels troch in one-liner passe yn in linux-shell
  • hoe te ûntkommen oan inkele sitaten yn bash
  • hoe't jo in map wiskje mei alle ynhâld yn 'e kommandorigel fan Windows
  • Hoe kinne jo in bestân omneame mei bash mv sûnder it oer te skriuwen

Tige tank foar jo oandacht.

Boarne: www.habr.com

Add a comment