ProHoster > blog > Utawala > Shirika la ufikiaji wa watumiaji wengi kwa seva ya GIT

Shirika la ufikiaji wa watumiaji wengi kwa seva ya GIT

Wakati wa kufunga na kusanidi seva ya Git, swali linatokea kuhusu kuandaa upatikanaji wa watumiaji kadhaa kwa miradi kadhaa. Nilitafiti suala hilo na nikapata suluhisho ambalo lilikidhi mahitaji yangu yote: rahisi, salama, na ya kutegemewa.

Matakwa yangu ni:

  • kila mtumiaji anaunganisha na akaunti yake mwenyewe
  • Watumiaji kadhaa wanaweza kufanya kazi kwenye mradi mmoja
  • mtumiaji huyo huyo anaweza kufanya kazi kwenye miradi mingi
  • kila mtumiaji ana ufikiaji wa miradi hiyo ambayo anafanya kazi
  • Inapaswa kuwa inawezekana kuunganisha kupitia mstari wa amri, na si tu kupitia aina fulani ya interface ya mtandao

Itakuwa nzuri pia:

  • toa ruhusa za kusoma tu kwa kudhibiti watu
  • Dhibiti kwa urahisi haki za ufikiaji wa mtumiaji katika Git

Muhtasari wa chaguzi zinazowezekana za kufikia seva ya GIT

Kwanza kabisa, unahitaji kujua cha kuchagua kutoka, kwa hivyo hapa kuna muhtasari wa haraka wa itifaki za Git.

  • ssh - akaunti ya mtumiaji iliyoundwa maalum hutumiwa kufikia seva.
    • Inashangaza kwamba Git haizuii kutoka kwa mapendekezo yake matumizi ya akaunti moja kupata hazina zote. Hii haikidhi mahitaji yangu hata kidogo.
    • Unaweza kutumia akaunti nyingi, lakini unawezaje kupunguza ufikiaji wa mtumiaji kwa saraka fulani tu?
      • Kufunga kwenye saraka ya nyumbani haifai, kwa sababu ni vigumu kuandaa upatikanaji wa kuandika huko kwa watumiaji wengine
      • Kutumia ulinganifu kutoka kwa saraka yako ya nyumbani pia ni ngumu kwa sababu Git haifasiri kama viungo
      • Inawezekana kuzuia ufikiaji wa mkalimani, lakini hakuna dhamana kamili kwamba itafanya kazi kila wakati
        • Kwa ujumla unaweza kuunganisha mkalimani wako wa amri kwa watumiaji kama hao, lakini
          • kwanza, hii tayari ni aina fulani ya uamuzi mgumu,
          • na pili, hii inaweza kuepukwa.

    Lakini labda sio tatizo kwamba mtumiaji ataweza kutekeleza amri yoyote? .. Kwa ujumla, njia hii haiwezi kutengwa ikiwa unatambua jinsi ya kutumia. Tutarudi kwa njia hii baadaye, lakini kwa sasa tutazingatia kwa ufupi njia nyingine, labda kutakuwa na kitu rahisi zaidi.

  • Itifaki ya eneo la git inaweza kutumika pamoja na sshfs, watumiaji wengi wanaweza kutumika, lakini kimsingi ni sawa na kesi iliyopita.
  • http - kusoma tu
  • git ni ya kusoma tu
  • https - vigumu kufunga, unahitaji programu ya ziada, aina fulani ya jopo la kudhibiti ili kuandaa upatikanaji wa mtumiaji ... inaonekana kuwa inawezekana, lakini kwa namna fulani kila kitu ni ngumu.

Kutumia itifaki ya ssh kupanga ufikiaji wa watumiaji wengi kwa seva ya Git

Wacha turudi kwenye itifaki ya ssh.

Kwa kuwa unatumia ufikiaji wa ssh kwa git, unahitaji kuhakikisha usalama wa data ya seva. Mtumiaji anayeunganisha kupitia ssh hutumia kuingia kwake mwenyewe kwenye seva ya Linux, ili waweze kuunganishwa kupitia mteja wa ssh na kufikia safu ya amri ya seva.
Hakuna ulinzi kamili dhidi ya ufikiaji kama huo.

Lakini mtumiaji haipaswi kupendezwa na faili za Linux. Habari muhimu huhifadhiwa tu kwenye hazina ya git. Kwa hiyo, inawezekana si kuzuia upatikanaji kupitia mstari wa amri, lakini kutumia zana za Linux ili kumkataza mtumiaji kutazama miradi, ukiondoa wale ambao anashiriki.
Chaguo dhahiri ni kutumia mfumo wa ruhusa wa Linux.

Kama ilivyotajwa tayari, inawezekana kutumia akaunti moja tu kwa ufikiaji wa ssh. Usanidi huu sio salama kwa watumiaji kadhaa, ingawa umejumuishwa kwenye orodha ya chaguzi zinazopendekezwa za git.

Ili kutekeleza mahitaji yaliyotolewa mwanzoni mwa kifungu, muundo wa saraka ufuatao huundwa na mgawo wa haki na wamiliki:

1) saraka za mradi

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
ambapo
dir1, dir2, dir3 - saraka za mradi: mradi 1, mradi 2, mradi 3.

proj1:proj1, proj2:proj2, proj3:proj3 ni watumiaji wa Linux walioundwa mahususi ambao wametumwa kama wamiliki wa saraka zinazolingana za mradi.

ruhusa za saraka zote zimewekwa kuwa 0770 - ufikiaji kamili kwa mmiliki na kikundi chake na marufuku kamili kwa kila mtu mwingine.

2) akaunti za msanidi programu

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

Jambo kuu ni kwamba watengenezaji wanapewa kikundi cha ziada cha mtumiaji wa mfumo wa mradi unaofanana. Hii inafanywa na msimamizi wa seva ya Linux kwa amri moja.

Katika mfano huu, "Msanidi programu 1" anafanya kazi kwenye miradi ya proj1 na proj2, na "Msanidi programu 2" anafanya kazi kwenye miradi ya proj2 na proj3.

Ikiwa yeyote kati ya Wasanidi Programu ataunganishwa kupitia ssh kupitia safu ya amri, basi haki zao hazitatosha hata kutazama yaliyomo kwenye saraka za mradi ambapo hawashiriki. Hawezi kubadilisha hii mwenyewe.

Kwa kuwa msingi wa kanuni hii ni usalama wa msingi wa haki za Linux, mpango huu ni wa kuaminika. Kwa kuongeza, mpango huo ni rahisi sana kusimamia.

Tuendelee na mazoezi.

Kuunda hazina za Git kwenye seva ya Linux

Hebu tuangalie.

[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

Nimechoka kuandika kwa mkono...

[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

Tuna hakika kuwa haiwezekani kufikia hazina za watu wengine kutoka kwa mstari wa amri na hata kutazama yaliyomo.

[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

Shirikiana na watengenezaji wengi kwenye mradi mmoja katika Git

Swali moja linabakia, ikiwa msanidi mmoja ataanzisha faili mpya, basi watengenezaji wengine hawawezi kuibadilisha, kwa sababu yeye mwenyewe ndiye mmiliki wake (kwa mfano, dev1), na sio mtumiaji wa mradi (kwa mfano, proj1). Kwa kuwa tuna hazina ya upande wa seva, kwanza kabisa, tunahitaji kujua jinsi saraka ya ".git" imeundwa na ikiwa faili mpya zinaundwa.

Kuunda hazina ya Git ya ndani na kusukuma kwa seva ya Git

Wacha tuendelee kwenye mashine ya mteja.

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>

Wakati huo huo, faili mpya zinaundwa kwenye seva, na ni za mtumiaji aliyefanya kushinikiza

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

Unapopakia mabadiliko kwenye seva ya Git, faili na saraka za ziada huundwa, na mmiliki wao ndiye mtumiaji anayepakia. Lakini basi kikundi cha faili hizi na saraka pia inalingana na kikundi kikuu cha mtumiaji huyu, ambayo ni, kikundi cha dev1 cha mtumiaji wa dev1 na kikundi cha dev2 cha mtumiaji wa dev2 (kubadilisha kikundi kikuu cha mtumiaji wa msanidi hautasaidia, kwa sababu basi unawezaje kufanya kazi kwenye miradi mingi?). Katika hali hii, mtumiaji dev2 hataweza kubadilisha faili zilizoundwa na mtumiaji dev1, ambayo inaweza kusababisha kuvunjika kwa utendakazi.

Linux chown - kubadilisha mmiliki wa faili na mtumiaji wa kawaida

Mmiliki wa faili hawezi kubadilisha umiliki wake. Lakini anaweza kubadilisha kundi la faili ambalo ni lake, na kisha faili hii inaweza kurekebishwa na watumiaji wengine walio katika kundi moja. Hiyo ndiyo tunayohitaji.

Kutumia ndoano ya Git

Saraka ya kufanya kazi kwa ndoano ni saraka ya mizizi ya mradi. ndoano ni inayoweza kutekelezwa ambayo inaendesha chini ya mtumiaji anayesukuma. Kwa kujua hili, tunaweza kutekeleza mipango yetu.

[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

au tu 

vi hooks/post-update

Wacha turudi kwenye mashine ya mteja.

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

Kwenye seva ya Git, tunaangalia utendakazi wa hati ya kusasisha ndoano baada ya ahadi 

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

- tupu, kila kitu ni sawa.

Kuunganisha msanidi wa pili katika Git

Wacha tuige kazi ya msanidi wa pili.

Juu ya mteja

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

Na wakati huo huo, kwenye seva ...

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

- tupu tena, kila kitu kinafanya kazi.

Kufuta mradi wa Git na kupakua mradi kutoka kwa seva ya Git

Kweli, unaweza tena kuhakikisha kuwa mabadiliko yote yamehifadhiwa.

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

- kufuta mradi wa Git, futa saraka kabisa. Wacha tuvumilie kosa ambalo linazalishwa, kwani haiwezekani kufuta saraka ya sasa kwa kutumia amri hii, lakini hii ndio tabia tunayohitaji.

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"

Kushiriki ufikiaji katika Git

Sasa hebu tuhakikishe kwamba hata kupitia Git msanidi wa pili hawezi kufikia mradi wa Proj1, ambao haufanyi kazi.

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.

Sasa tunaruhusu ufikiaji

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

na baada ya hapo kila kitu hufanya kazi.

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

Kwa habari zaidi,

Kwa kuongeza, ikiwa kuna shida na ruhusa chaguo-msingi wakati wa kuunda faili na saraka, katika CentOS unaweza kutumia amri.

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

Pia katika kifungu hicho unaweza kujikwaa juu ya vitu vidogo muhimu:

  • jinsi ya kuunda mti wa saraka katika Linux
  • jinsi ya kupitisha anuwai ya anwani katika sed kutoka kwa mstari fulani hadi mwisho wa faili, ambayo ni, fanya uingizwaji wa sed katika mistari yote isipokuwa safu ya kwanza.
  • Jinsi ya kugeuza hali ya utaftaji kwenye Linux find
  • Jinsi ya kupitisha mistari mingi kwenye kitanzi kwa kutumia mjengo mmoja kwenye ganda la Linux
  • Jinsi ya kutoroka nukuu moja kwenye bash
  • jinsi ya kufuta saraka na yaliyomo yake yote kwenye mstari wa amri ya windows
  • Jinsi ya kutumia bash mv kubadili jina la faili bila kuiandika tena

Asante kwa mawazo yako.

Chanzo: mapenzi.com

Kuongeza maoni