ProHoster > Blog > Administrazioa > GIT zerbitzarirako erabiltzaile anitzeko sarbidearen antolaketa

GIT zerbitzarirako erabiltzaile anitzeko sarbidearen antolaketa

Git zerbitzari bat instalatzean eta konfiguratzean, hainbat erabiltzailek hainbat proiektutarako sarbidea antolatzeko galdera sortzen da. Gaiari buruzko ikerketa batzuk egin eta nire baldintza guztiak betetzen dituen irtenbide bat aurkitu nuen: sinplea, segurua, fidagarria.

Nire nahiak hauek dira:

  • erabiltzaile bakoitza bere kontuarekin konektatzen da
  • Erabiltzaile anitzek lan egin dezakete proiektu berean
  • erabiltzaile berak hainbat proiektutan lan egin dezake
  • erabiltzaile bakoitzak lan egiten duen proiektuetarako soilik du sarbidea
  • komando-lerroaren bidez konektatzea posible izan beharko litzateke, eta ez web-interfaze baten bidez soilik

Oso ondo egongo litzateke:

  • kontrolpean dauden pertsonei irakurtzeko soilik eskubideak ematea
  • Erabiltzaileen baimenak eroso kudeatu Git-en

GIT zerbitzarian sartzeko aukera posibleen ikuspegi orokorra

Lehenik eta behin, zer aukeratu jakin behar duzu, beraz, Git protokoloen ikuspegi labur bat.

  • ssh - zerbitzarian sartzeko bereziki sortutako erabiltzaile-kontu bat erabiltzen da.
    • bitxia da Git-ek ez duela gomendatzen kontu bakarra biltegi guztietara sartzeko. Honek ez ditu batere betetzen nire eskakizunak.
    • Hainbat kontu erabil ditzakezu, baina nola muga dezakezu erabiltzaile baten sarbidea direktorio batzuetara soilik?
      • Hasierako direktoriora ixtea ez da egokia, zaila baita bertan beste erabiltzaileentzako idazketa sarbidea antolatzea
      • Hasierako direktorioko esteka sinbolikoak erabiltzea ere zaila da, Git-ek ez dituelako esteka gisa interpretatzen.
      • Murriztu interpretearen sarbidea, tira, egin dezakezu, baina ez dago beti funtzionatuko duen bermerik
        • Oro har, zure komandoen interpretea konekta dezakezu horrelako erabiltzaileentzat, baina,
          • Lehenik eta behin, hau erabaki zaila da dagoeneko,
          • eta 2, saihestu daiteke.

    Baina agian ez da arazorik erabiltzaileak komandoak exekutatu ahal izatea?... Orokorrean, metodo hau ezin da baztertu nola erabili zehatz-mehatz asmatzen baduzu. Metodo honetara geroago itzuliko gara, baina oraingoz gainerako alternatibak labur-labur aztertuko ditugu, agian zerbait sinpleagoa izango da.

  • git protokolo lokala sshfs-ekin konbinatuta erabil daiteke, hainbat erabiltzaile erabil daitezke, baina funtsean aurreko kasuaren berdina da
  • http - irakurtzeko soilik
  • git irakurtzeko soilik da
  • https instalatzen zaila da, software gehigarria behar duzu, erabiltzaileen sarbidea antolatzeko kontrol panel moduko bat ... bideragarria dirudi, baina nolabait dena konplikatua da.

Ssh protokoloa erabiltzea Git zerbitzarirako erabiltzaile anitzeko sarbidea antolatzeko

Itzuli gaitezen ssh protokolora.

Git-erako ssh sarbidea erabiltzen denez, zerbitzariaren datuak seguruak izan behar dira. Ssh bidez konektatzen den erabiltzaileak bere saio-hasiera erabiltzen du Linux zerbitzarian, ssh bezeroaren bidez konektatu eta zerbitzariaren komando-lerroan sartzeko.
Ez dago erabateko babesik sarbide hori lortzeko.

Baina erabiltzaileak ez luke Linux fitxategiak interesatu behar. Informazio esanguratsua git biltegian soilik gordetzen da. Hori dela eta, ezin duzu sarbidea mugatu komando-lerroaren bidez, baina Linux-en bidez, erabiltzaileari proiektuak ikustea debekatu, berak parte hartzen dituenak kenduta.
Argi dago Linux baimenen sistema erabiltzea.

Esan bezala, ssh sartzeko kontu bakarra erabil daiteke. Konfigurazio hau ez da segurua hainbat erabiltzailerentzat, git-en gomendatutako aukeren zerrendan sartuta dagoen arren.

Artikuluaren hasieran emandako eskakizunak ezartzeko, direktorio-egitura hau sortzen da eskubideen eta jabeen esleipenarekin:

1) proiektuen direktorioa

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
non
dir1, dir2, dir3 - proiektuen direktorioetan: 1. proiektua, 2. proiektua, 3. proiektua.

proj1:proj1, proj2:proj2, proj3:proj3 bereziki sortutako Linux erabiltzaileak dira, dagozkien proiektuen direktorioen jabe gisa esleituta daudenak.

direktorio guztien eskubideak 0770-n ezarrita daude - jabearen eta bere taldearen sarbide osoa eta gainontzeko guztientzat erabateko debekua.

2) garatzaileen kontuak

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

Gakoa da garatzaileei dagokien proiektuaren jabe den sistemaren erabiltzailearen talde gehigarri bat esleitzen zaiela. Linux zerbitzariaren administratzaileak komando batekin egiten du.

Adibide honetan, 1. garatzailea proj1 eta proj2 proiektuetan ari da lanean, eta 2. garatzailea proj2 eta proj3 proiektuetan.

Garatzaileren bat ssh bidez konektatzen bada komando-lerroaren bidez, orduan bere eskubideak ez dira nahikoak izango berak parte hartzen ez duen proiektuen direktorioetako edukiak ikusteko. Ezin du berak aldatu.

Printzipio honen oinarria Linux eskubideen oinarrizko segurtasuna denez, eskema hau fidagarria da. Gainera, eskema oso erraza da administratzen.

Joan praktikara.

Git biltegiak sortzea Linux zerbitzari batean

Egiaztatzen dugu.

[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

idazten nekatuta...

[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

Sinetsita gaude ezinezkoa dela besteen biltegietara komando-lerrotik sartzea eta baita haien edukia ikustea ere.

[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

Hainbat garatzaileren Git-en lankidetza proiektu batean

Galdera bat geratzen da, garatzaile batek fitxategi berri bat sartzen badu, beste garatzaile batzuek ezin dute aldatu, bera delako jabea (adibidez, dev1), eta ez proiektuaren jabe den erabiltzailea (adibidez, proj1). Zerbitzariaren biltegi bat dugunez, lehenik eta behin, “.git” direktorioa nola antolatzen den eta fitxategi berriak sortzen diren jakin behar dugu.

Sortu Git biltegi lokal bat eta bultzatu Git zerbitzari batera

Joan gaitezen bezeroaren makinara.

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>

Aldi berean, fitxategi berriak sortzen dira zerbitzarian, eta push-a egin duen erabiltzailearenak dira

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

Aldaketak Git zerbitzarian kargatzen direnean, fitxategi eta direktorio osagarriak sortzen dira eta benetan kargatzaileak dira. Baina gero fitxategi eta direktorio hauen taldea erabiltzaile honen talde nagusiari ere dagokio, hau da, dev1 taldeari dev1 erabiltzaileari eta dev2 taldeari dev2 erabiltzaileari (garatzaileen erabiltzailearen talde nagusia aldatzeak ez du lagunduko, orduan nola lan egin hainbat proiektutan?). Kasu honetan, dev2 erabiltzaileak ezin izango ditu aldatu dev1 erabiltzaileak sortutako fitxategiak, eta horrek funtzionaltasuna urratzen du.

Linux chown - erabiltzaile arrunt batek fitxategi baten jabea aldatzea

Fitxategi baten jabeak ezin du bere jabetza aldatu. Baina berari dagokion fitxategi baten taldea alda dezake, eta, ondoren, fitxategi hori talde berean dauden beste erabiltzaile batzuek alda dezakete. Hori da behar duguna.

Git Hook erabiliz

Hook-erako lan-direktorioa proiektuaren erro-direktorioa da. Hook bultzada egiten ari den erabiltzailearen azpian exekutatzen den exekutagarri bat da. hori jakinda, gure egitasmoak aurrera eraman ditzakegu.

[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

besterik ez 

vi hooks/post-update

Itzuli gaitezen bezeroaren makinara.

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 zerbitzarian, egiaztatu hook eguneratze osteko scriptaren lana konprometitu ondoren 

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

- hutsik, dena ondo dago.

Bigarren garatzaile bat Git-era konektatzea

Simula dezagun bigarren garatzailearen lana.

Bezeroaren gainean

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

Eta aldi berean, zerbitzarian...

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

- berriro hutsik, dena funtzionatzen du.

Git proiektu bat ezabatzea eta proiektu bat Git zerbitzari batetik kargatzea

Beno, berriro ere ziurtatu dezakezu aldaketa guztiak gorde direla.

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

- Git proiektu bat kentzeko, garbitu direktorioa erabat. Jarri dezagun emandako errorea, ezinezkoa baita uneko direktorioa ezabatzea komando honekin, baina horixe da behar dugun portaera.

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"

Git-en sarbidea partekatzea

Orain, ziurtatu bigarren garatzaileak ezin duela Git-en Proj1 proiektua sartu, eta horretan ez dabil lanean.

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.

Orain baimendu sarbidea

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

eta ondoren dena funtzionatzen du.

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

Informazio gehiago eskuratzeko,

Gainera, fitxategiak eta direktorioak sortzerakoan baimen lehenetsiekin arazoren bat badago, CentOS-en komandoa erabil dezakezu

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

Artikuluan ere gauza erabilgarriak topa ditzakezu:

  • nola eraiki direktorioen zuhaitza linux-en
  • nola pasa helbide-sorta bat lerro jakin batetik fitxategiaren amaierara sed-en, hau da, sed-en ordezkapen bat egin lerro guztietan lehen lerroan izan ezik
  • Nola alderantzikatu bilaketa-baldintza Linux aurkikuntzan
  • nola pasa hainbat lerro lerro bakarretik linux shell batean
  • bash-en komatxo bakarrean nola ihes egin
  • Windows komando-lerroko eduki guztiak dituen direktorio bat nola ezabatu
  • Nola aldatu fitxategi bat bash mv erabiliz berriro idatzi gabe

Eskerrik asko zure arretagatik.

Iturria: www.habr.com

Gehitu iruzkin berria