ProHoster > Блог > Administrado > Organizo de pluruza aliro al la GIT-servilo

Organizo de pluruza aliro al la GIT-servilo

Kiam oni instalas kaj agordas Git-servilon, staras la demando pri organizado de aliro por pluraj uzantoj al pluraj projektoj. Mi esploris la aferon kaj trovis solvon, kiu plenumas ĉiujn miajn postulojn: simpla, sekura, fidinda.

Miaj deziroj estas:

  • ĉiu uzanto konektas kun sia propra konto
  • Multoblaj uzantoj povas labori pri la sama projekto
  • la sama uzanto povas labori pri pluraj projektoj
  • ĉiu uzanto havas aliron nur al tiuj projektoj pri kiuj li laboras
  • devus ebli konekti per la komandlinio, kaj ne nur per ia retinterfaco

Ĝi ankaŭ estus bonega:

  • donu nurlegeblajn rajtojn al regantaj personoj
  • komforte administru uzantpermesojn en Git

Superrigardo de eblaj opcioj por aliri la GIT-servilon

Antaŭ ĉio, vi devas scii el kio elekti, do mallonga superrigardo de la Git-protokoloj.

  • ssh - speciale kreita uzantkonto estas uzata por aliri la servilon.
    • estas strange, ke Git ne rekomendas uzi unu konton por aliri ĉiujn deponejojn. Ĉi tio tute ne plenumas miajn postulojn.
    • Vi povas uzi plurajn kontojn, sed kiel vi povas limigi la aliron de uzanto nur al certaj dosierujoj?
      • Fermi al la hejma dosierujo ne taŭgas, ĉar estas malfacile organizi skriban aliron por aliaj uzantoj tie
      • Uzi simbolajn ligilojn de la hejma dosierujo ankaŭ estas malfacila ĉar Git ne interpretas ilin kiel ligilojn.
      • Limigu aliron al la interpretisto, nu, vi povas, sed ne estas plena garantio, ke ĉi tio ĉiam funkcios
        • Vi povas ĝenerale konekti vian propran komandinterpretilon por tiaj uzantoj, sed,
          • unue, ĉi tio jam estas ia malfacila decido,
          • kaj 2, ĝi povas esti preterpasita.

    Sed eble ne estas problemo, ke la uzanto povos ekzekuti iujn komandojn? .. Ĝenerale, ĉi tiu metodo ne povas esti forĵetita, se vi eltrovas ĝuste kiel uzi ĝin. Ni revenos al ĉi tiu metodo poste, sed nuntempe ni mallonge konsideros la ceterajn alternativojn, eble estos io pli simpla.

  • git loka protokolo povas esti uzata kombine kun sshfs, pluraj uzantoj povas esti uzataj, sed ĝi estas esence la sama kiel la antaŭa kazo
  • http - nur legata
  • git estas nurlegebla
  • https estas malfacile instalebla, vi bezonas aldonan programaron, ian kontrolpanelon por organizi uzantan aliron ... ĝi aspektas farebla, sed iel ĉio estas komplika.

Uzante la ssh-protokolon por organizi multi-uzantan aliron al la Git-servilo

Ni revenu al la protokolo ssh.

Ĉar ssh-aliro estas uzata por git, la servilaj datumoj devas esti sekuraj. La uzanto, kiu konektas per ssh, uzas sian propran ensaluton sur la Linukso-servilo, do ili povas konektiĝi per la ssh-kliento kaj aliri la komandlinion de la servilo.
Ne ekzistas kompleta protekto kontraŭ akiro de tia aliro.

Sed la uzanto ne devus interesiĝi pri Linuksaj dosieroj. Signifaj informoj estas konservitaj nur en la git-deponejo. Sekve, vi ne povas limigi la aliron per la komandlinio, sed per Linukso, malpermesi al la uzanto vidi projektojn, ekskludante tiujn, en kiuj li partoprenas.
Estas evidente uzi la Linuksan permessistemon.

Kiel jam menciite, eblas uzi nur unu konton por ssh-aliro. Ĉi tiu agordo estas nesekura por pluraj uzantoj, kvankam ĝi estas inkluzivita en la listo de rekomenditaj elektoj de git.

Por efektivigi la postulojn donitajn komence de la artikolo, la sekva dosierujo-strukturo estas kreita kun la atribuo de rajtoj kaj posedantoj:

1) projektaj dosierujoj

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
kie
dir1, dir2, dir3 - projektaj dosierujoj: projekto 1, projekto 2, projekto 3.

proj1:proj1, proj2:proj2, proj3:proj3 estas speciale kreitaj Linuksaj uzantoj, kiuj estas asignitaj kiel posedantoj de la respektivaj projektaj dosierujoj.

la rajtoj al ĉiuj dosierujoj estas fiksitaj al 0770 - plena aliro por la posedanto kaj lia grupo, kaj kompleta malpermeso por ĉiuj aliaj.

2) kontoj de programistoj

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

La ŝlosila punkto estas, ke la programistoj ricevas plian grupon de la sistemuzanto, kiu posedas la respondan projekton. Ĉi tio estas farita de la administranto de Linuksa servilo per unu komando.

En ĉi tiu ekzemplo, Programisto 1 laboras pri projektoj proj1 kaj proj2, kaj Programisto 2 laboras pri projektoj proj2 kaj proj3.

Se iu el la Programistoj konektas per ssh per la komandlinio, tiam liaj rajtoj ne sufiĉos eĉ por vidi la enhavon de la dosierujoj de projektoj, en kiuj li ne partoprenas. Li mem ne povas ŝanĝi ĝin.

Ĉar la bazo de ĉi tiu principo estas la baza sekureco de Linukso-rajtoj, ĉi tiu skemo estas fidinda. Krome, la skemo estas tre facile administrebla.

Ni plu praktiku.

Kreante Git-deponejojn sur Linuksa Servilo

Ni kontrolas.

[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

tedas de tajpi...

[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

Ni estas konvinkitaj, ke estas neeble aliri la deponejojn de aliaj homoj de la komandlinio kaj eĉ vidi ilian enhavon.

[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

Kunlaboro en Git de pluraj programistoj pri unu projekto

Unu demando restas, se unu programisto enkondukas novan dosieron, tiam aliaj programistoj ne povas ŝanĝi ĝin, ĉar li mem estas ĝia posedanto (ekzemple dev1), kaj ne la uzanto kiu posedas la projekton (ekzemple proj1). Ĉar ni havas servilan deponejon, antaŭ ĉio, ni devas scii kiel la dosierujo ".git" estas aranĝita kaj ĉu novaj dosieroj estas kreitaj.

Kreu lokan Git-deponejon kaj premu al Git-servilo

Ni transiru al la klienta maŝino.

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>

Samtempe, novaj dosieroj estas generitaj sur la servilo, kaj ili apartenas al la uzanto, kiu faris la puŝon

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

Kiam la ŝanĝoj estas alŝutitaj al la Git-servilo, pliaj dosieroj kaj dosierujoj estas kreitaj kaj estas fakte posedataj de la alŝutanto. Sed tiam la grupo de ĉi tiuj dosieroj kaj dosierujoj ankaŭ respondas al la ĉefa grupo de ĉi tiu uzanto, tio estas, la dev1-grupo por la dev1-uzanto kaj la dev2-grupo por la dev2-uzanto (ŝanĝi la ĉefgrupon de la programisto-uzanto ne helpos, ĉar tiam kiel labori pri pluraj projektoj?). En ĉi tiu kazo, la uzanto dev2 ne povos modifi la dosierojn kreitajn de la uzanto dev1, kaj ĉi tio estas plena de malobservo de funkcieco.

Linukso chown - ŝanĝante la posedanton de dosiero fare de normala uzanto

La posedanto de dosiero ne povas ŝanĝi sian proprieton. Sed li povas ŝanĝi la grupon de dosiero, kiu apartenas al li, kaj tiam ĉi tiu dosiero povas esti ŝanĝita de aliaj uzantoj, kiuj estas en la sama grupo. Tion ni bezonas.

Uzante la Git Hoko

La labordosierujo por hook estas la radika dosierujo de la projekto. hoko estas ekzekutebla kiu funkcias sub la uzanto kiu faras la puŝon. sciante tion, ni povas plenumi niajn planojn.

[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

ĉu nur 

vi hooks/post-update

Ni reiru al la klienta maŝino.

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

Sur la Git-servilo, kontrolu la laboron de la hoka post-ĝisdatiga skripto post la kommit 

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

- malplena, ĉio estas en ordo.

Konektante Duan Ellaboranton al Git

Ni simulu la laboron de la dua programisto.

Sur la kliento

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

Kaj samtempe, sur la servilo...

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

- denove malplena, ĉio funkcias.

Forigo de Git-Projekto kaj Ŝargado de Projekto de Git-Servilo

Nu, vi povas denove certigi, ke ĉiuj ŝanĝoj estas konservitaj.

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

- por forigi Git-projekton, simple purigu la dosierujon tute. Ni toleru la eraron donitan, ĉar estas neeble forigi la nunan dosierujon per ĉi tiu komando, sed ĉi tio estas ĝuste la konduto, kiun ni bezonas.

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"

Kunhavigo de Aliro en Git

Nun ni certigu, ke la dua programisto ne povas aliri la projekton Proj1 per Git, pri kiu li ne laboras.

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.

Nun permesu aliron

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

kaj post tio ĉio funkcias.

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

Por pliaj informoj,

Krome, se estas problemo kun la defaŭltaj permesoj dum kreado de dosieroj kaj dosierujoj, ĉe CentOS vi povas uzi la komandon

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

Ankaŭ en la artikolo vi povas trovi malgrandajn utilajn aferojn:

  • kiel konstrui dosierujon en Linukso
  • kiel pasi gamon da adresoj de certa linio al la fino de la dosiero en sed, tio estas, fari anstataŭaĵon en sed en ĉiuj linioj krom la unua linio
  • Kiel inversigi serĉkondiĉon en Linukso-trovo
  • kiel pasi plurajn liniojn tra unu-linio en linuksa ŝelo
  • kiel eskapi unuopaj citiloj en bash
  • kiel forigi dosierujon kun ĉiuj enhavoj en vindoza komandlinio
  • Kiel renomi dosieron uzante bash mv sen reverki ĝin

Dankon pro via atento.

fonto: www.habr.com

Aldoni komenton