ProHoster > Blog > башкаруу > 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 бир эле долбоор боюнча бир нече иштеп чыгуучулар менен кызматташат

Бир суроо бойдон калууда, эгерде бир иштеп чыгуучу жаңы файлды киргизсе, анда башка иштеп чыгуучулар аны өзгөртө алышпайт, анткени ал өзү анын ээси (мисалы, dev1) эмес, долбоордун колдонуучусу (мисалы, proj1). Бизде сервердик репозиторий болгондуктан, биринчиден, биз “.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>

Ошол эле учурда серверде жаңы файлдар түзүлөт жана алар түртүүнү аткарган колдонуучуга таандык

[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 колдонуу

Hook үчүн жумушчу каталогу долбоордун түпкү каталогу болуп саналат. 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 кантип колдонсо болот

Конул бурганын учун рахмат.

Source: www.habr.com

Комментарий кошуу