ProHoster > Блог > басқарма > GIT серверіне көп қолданушының қол жеткізуін ұйымдастыру

GIT серверіне көп қолданушының қол жеткізуін ұйымдастыру

Git серверін орнату және конфигурациялау кезінде бірнеше пайдаланушылардың бірнеше жобаларға қол жеткізуін ұйымдастыру туралы сұрақ туындайды. Мен мәселені зерттеп, барлық талаптарыма сай шешім таптым: қарапайым, қауіпсіз, сенімді.

Менің тілектерім:

  • әрбір пайдаланушы өз есептік жазбасымен қосылады
  • Бір жобада бірнеше пайдаланушы жұмыс істей алады
  • бір пайдаланушы бірнеше жобаларда жұмыс істей алады
  • әрбір пайдаланушы өзі жұмыс істейтін жобаларға ғана қол жеткізе алады
  • Веб-интерфейстің қандай да бір түрі арқылы емес, пәрмен жолы арқылы қосылу мүмкіндігі болуы керек

Бұл да тамаша болар еді:

  • бақылаушы тұлғаларға тек оқуға рұқсаттар беріңіз
  • Git-те пайдаланушының қол жеткізу құқықтарын ыңғайлы басқарыңыз

GIT серверіне кірудің ықтимал нұсқаларына шолу

Ең алдымен, сіз не таңдау керектігін білуіңіз керек, сондықтан Git протоколдарына қысқаша шолу.

  • ssh - серверге кіру үшін арнайы жасалған пайдаланушы тіркелгісі пайдаланылады.
    • Git өз ұсыныстарынан барлық репозиторийлерге қол жеткізу үшін бір тіркелгіні пайдалануды алып тастамайтыны таңқаларлық. Бұл менің талаптарыма мүлдем сәйкес келмейді.
    • Сіз бірнеше тіркелгілерді пайдалана аласыз, бірақ пайдаланушының тек белгілі бір каталогтарға кіруіне қалай шектеу қоюға болады?
      • Басты каталогты жабу жарамайды, себебі басқа пайдаланушылар үшін ол жерде жазуға рұқсатты ұйымдастыру қиын
      • Үй каталогындағы символдық сілтемелерді пайдалану да қиын, өйткені Git оларды сілтеме ретінде түсіндірмейді
      • Аудармашыға қол жеткізуді шектеуге болады, бірақ оның әрқашан жұмыс істейтініне толық кепілдік жоқ
        • Мұндай пайдаланушылар үшін әдетте өзіңіздің командалық аудармашыңызды қосуға болады, бірақ
          • біріншіден, бұл әлдебір қиын шешім,
          • екіншіден, мұны айналып өтуге болады.

    Бірақ, бәлкім, пайдаланушы кез келген командаларды орындай алатындай проблема емес шығар?.. Жалпы, егер сіз оны қалай пайдалану керектігін нақты анықтасаңыз, бұл әдісті жоққа шығаруға болмайды. Біз бұл әдіске кейінірек ораламыз, бірақ әзірше біз басқа баламаларды қысқаша қарастырамыз, мүмкін қарапайым нәрсе болуы мүмкін.

  • Git жергілікті протоколын sshfs-пен бірге пайдалануға болады, бірнеше пайдаланушыларды пайдалануға болады, бірақ іс жүзінде алдыңғы жағдаймен бірдей
  • http - тек оқуға арналған
  • git тек оқуға арналған
  • https - орнату қиын, сізге қосымша бағдарламалық жасақтама қажет, пайдаланушының қол жеткізуін ұйымдастыру үшін басқару панелінің қандай да бір түрі... мүмкін болып көрінеді, бірақ әйтеуір бәрі күрделі.

Git серверіне көп пайдаланушының кіруін ұйымдастыру үшін ssh протоколын пайдалану

ssh протоколына оралайық.

Git үшін ssh қатынасын пайдаланатындықтан, сервер деректерінің қауіпсіздігін қамтамасыз ету керек. Ssh арқылы қосылатын пайдаланушы Linux серверінде өзінің логинін пайдаланады, осылайша олар ssh клиенті арқылы қосылып, сервердің пәрмен жолына қол жеткізе алады.
Мұндай қол жеткізуден толық қорғаныс жоқ.

Бірақ пайдаланушы Linux файлдарына қызығушылық танытпауы керек. Маңызды ақпарат тек git репозиторийінде сақталады. Сондықтан, пәрмен жолы арқылы қол жеткізуді шектемеуге болады, бірақ ол қатысатын жобаларды қоспағанда, пайдаланушыға жобаларды қарауға тыйым салу үшін Linux құралдарының көмегімен.
Ашық таңдау - Linux рұқсаттар жүйесін пайдалану.

Жоғарыда айтылғандай, ssh қатынасы үшін тек бір тіркелгіні пайдалануға болады. Бұл конфигурация бірнеше пайдаланушылар үшін қауіпті, бірақ ол ұсынылған git опцияларының тізіміне енгізілген.

Мақаланың басында берілген талаптарды жүзеге асыру үшін құқықтар мен меншік иелерін тағайындау арқылы келесі анықтамалық құрылым құрылған:

1) жоба каталогтары

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
қайда
dir1, dir2, dir3 - жоба каталогтары: жоба 1, жоба 2, жоба 3.

proj1:proj1, proj2:proj2, proj3:proj3 - сәйкес жоба каталогтарының иелері ретінде тағайындалған арнайы жасалған Linux пайдаланушылары.

барлық каталогтар үшін рұқсаттар 0770 мәніне орнатылған - иесі мен оның тобына толық қолжетімділік және қалғандардың барлығына толық тыйым салу.

2) әзірлеуші ​​шоттары

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

Ең бастысы, әзірлеушілерге сәйкес жобаның иесінің жүйе пайдаланушысының қосымша тобы тағайындалады. Мұны Linux серверінің әкімшісі бір пәрмен арқылы жасайды.

Бұл мысалда "Әзірлеуші ​​1" proj1 және proj2 жобаларында, ал "2 әзірлеуші" proj2 және proj3 жобаларында жұмыс істейді.

Егер әзірлеушілердің кез келгені пәрмен жолы арқылы ssh арқылы қосылса, олардың құқықтары тіпті олар қатыспайтын жоба каталогтарының мазмұнын көру үшін жеткіліксіз болады. Ол мұны өзі өзгерте алмайды.

Бұл принциптің негізі Linux құқықтарының негізгі қауіпсіздігі болғандықтан, бұл схема сенімді. Сонымен қатар, схеманы басқару өте оңай.

Тәжірибеге барайық.

Linux серверінде Git репозиторийлерін жасау

Тексеру.

[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

Қолмен теруден шаршадым...

[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

Біз пәрмен жолынан басқа адамдардың репозиторийлеріне қол жеткізу және тіпті олардың мазмұнын қарау мүмкін емес екеніне сенімдіміз.

[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

Git-те бір жобада бірнеше әзірлеушілермен бірлесіп жұмыс жасаңыз

Бір сұрақ қалады, егер бір әзірлеуші ​​жаңа файлды енгізсе, басқа әзірлеушілер оны өзгерте алмайды, өйткені ол жобаның пайдаланушы иесі емес (мысалы, proj1) емес, оның иесі (мысалы, dev1) болып табылады. Бізде серверлік репозиторий болғандықтан, ең алдымен, біз «.git» каталогының қалай құрылымдалғанын және жаңа файлдардың жасалғанын білуіміз керек.

Жергілікті Git репозиторийін жасау және Git серверіне жіберу

Клиенттік машинаға көшейік.

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>

Сонымен бірге серверде жаңа файлдар құрылады және олар push-ті орындаған пайдаланушыға тиесілі

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

Git серверіне өзгертулерді жүктеп салған кезде қосымша файлдар мен каталогтар жасалады және олардың иесі шын мәнінде жүктеп салуды жасайтын пайдаланушы болып табылады. Бірақ содан кейін бұл файлдар мен каталогтар тобы осы пайдаланушының негізгі тобына сәйкес келеді, яғни dev1 пайдаланушысы үшін dev1 тобы және dev2 пайдаланушысы үшін dev2 тобы (әзірлеуші ​​пайдаланушының негізгі тобын өзгерту көмектеспейді, өйткені бірнеше жобаларда қалай жұмыс істеуге болады?). Бұл жағдайда dev2 пайдаланушысы dev1 пайдаланушы жасаған файлдарды өзгерте алмайды, бұл функцияның бұзылуына әкелуі мүмкін.

Linux chown - файлдың иесін қарапайым пайдаланушының өзгертуі

Файлдың иесі оның иелігін өзгерте алмайды. Бірақ ол өзіне тиесілі файлдың тобын өзгерте алады, содан кейін бұл файлды сол топтағы басқа пайдаланушылар өзгерте алады. Бізге керегі де сол.

Git hook пайдалану

Ілмекке арналған жұмыс каталогы жобаның түбірлік каталогы болып табылады. ілмек - бұл пайдаланушының астында жұмыс істейтін орындалатын файл. Осыны біле отырып, біз өз жоспарларымызды жүзеге асыра аламыз.

[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

немесе жай ғана 

vi hooks/post-update

Клиенттік машинаға оралайық.

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 серверінде біз міндеттемеден кейін ілмектен кейінгі жаңарту сценарийінің жұмысын тексереміз 

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

- бос, бәрі жақсы.

Git-те екінші әзірлеушіге қосылу

Екінші әзірлеушінің жұмысын имитациялайық.

Клиент бойынша

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

Сонымен бірге серверде...

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

— қайтадан бос, бәрі жұмыс істейді.

Git жобасын жою және жобаны Git серверінен жүктеп алу

Барлық өзгертулердің сақталғанына тағы бір рет көз жеткізуге болады.

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

— Git жобасын жою үшін каталогты толығымен тазалаңыз. Осы пәрменді пайдаланып ағымдағы каталогты жою мүмкін болмағандықтан, туындаған қатеге шыдаймыз, бірақ бұл бізге қажет мінез-құлық.

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-те рұқсатты бөлісу

Енді Git арқылы екінші әзірлеуші ​​​​жұмыс істемейтін Proj1 жобасына қол жеткізе алмайтынына көз жеткізейік.

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.

Енді біз кіруге рұқсат етеміз

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

содан кейін бәрі жұмыс істейді.

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

қосымша ақпарат

Сонымен қатар, файлдар мен каталогтарды жасау кезінде әдепкі рұқсаттармен мәселе туындаса, CentOS жүйесінде пәрменді пайдалануға болады.

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

Сондай-ақ мақалада сіз шағын пайдалы нәрселерге тап болуыңыз мүмкін:

  • Linux жүйесінде каталогтар ағашын қалай құруға болады
  • sed-дегі адрестер ауқымын белгілі бір жолдан файлдың соңына дейін қалай беру керек, яғни бірінші жолдан басқа барлық жолдарда sed-де ауыстыруды жасау
  • Linux іздеу жүйесінде іздеу шартын қалай өзгертуге болады
  • Linux қабығындағы бір сызықты пайдаланып, бірнеше жолды циклге қалай өткізуге болады
  • Bash ішіндегі жалғыз тырнақшалардан қалай құтылуға болады
  • Windows пәрмен жолындағы барлық мазмұны бар каталогты қалай жоюға болады
  • Файлды қайта жазбай, атын өзгерту үшін bash mv қалай пайдалануға болады

Назарларыңызға рахмет.

Ақпарат көзі: www.habr.com

пікір қалдыру