🥇Կազմակերպում բազմաֆունկցիոնալ մուտք դեպի GIT սերվեր

Git սերվերի տեղադրման և կազմաձևման ժամանակ հարց է առաջանում մի քանի օգտատերերի համար մի քանի նախագծերի հասանելիության կազմակերպման մասին: Ես ուսումնասիրեցի խնդիրը և գտա լուծում, որը համապատասխանում էր իմ բոլոր պահանջներին՝ պարզ, անվտանգ, հուսալի:

Իմ ցանկություններն են.

յուրաքանչյուր օգտվող կապվում է իր սեփական հաշվի հետ
Մի քանի օգտատերեր կարող են աշխատել մեկ նախագծի վրա
նույն օգտատերը կարող է աշխատել մի քանի նախագծերի վրա
յուրաքանչյուր օգտատեր մուտք ունի միայն այն նախագծերին, որոնց վրա նա աշխատում է
Պետք է հնարավոր լինի միանալ հրամանի տողի միջոցով, և ոչ միայն ինչ-որ վեբ ինտերֆեյսի միջոցով

Նաև հիանալի կլիներ.

տրամադրել միայն կարդալու թույլտվություններ վերահսկող անձանց
Հարմարավետորեն կառավարեք օգտվողների մուտքի իրավունքները Git-ում

GIT սերվեր մուտք գործելու հնարավոր տարբերակների ակնարկ

Առաջին հերթին, դուք պետք է իմանաք, թե ինչից ընտրել, այնպես որ ահա Git արձանագրությունների արագ ակնարկը:

ssh - հատուկ ստեղծված օգտվողի հաշիվն օգտագործվում է սերվեր մուտք գործելու համար:
- Տարօրինակ է, որ Git-ը չի բացառում իր առաջարկություններից մեկ հաշվի օգտագործումը բոլոր պահեստարաններ մուտք գործելու համար: Սա բացարձակապես չի համապատասխանում իմ պահանջներին:
- Դուք կարող եք օգտագործել բազմաթիվ հաշիվներ, բայց ինչպե՞ս կարող եք սահմանափակել օգտվողների մուտքը միայն որոշակի գրացուցակներ:
  - Տնային գրացուցակում փակելը հարմար չէ, քանի որ դժվար է այնտեղ գրելու հասանելիություն կազմակերպել այլ օգտվողների համար
  - Ձեր տնային գրացուցակից սիմհղումներ օգտագործելը նույնպես դժվար է, քանի որ Git-ը դրանք չի մեկնաբանում որպես հղումներ
  - Հնարավոր է սահմանափակել թարգմանչի մուտքը, բայց չկա լիարժեք երաշխիք, որ այն միշտ կաշխատի
    - Դուք կարող եք ընդհանուր առմամբ միացնել ձեր սեփական հրամանի թարգմանիչը նման օգտվողների համար, բայց
      - նախ, սա արդեն ինչ-որ բարդ որոշում է,
      - և երկրորդ՝ սա կարելի է շրջանցել։
Բայց միգուցե խնդիր չէ, որ օգտատերը կկարողանա որևէ հրաման կատարել: Մենք ավելի ուշ կվերադառնանք այս մեթոդին, բայց առայժմ հակիրճ կքննարկենք մյուս այլընտրանքները, գուցե ավելի պարզ բան լինի:
Git տեղական արձանագրությունը կարող է օգտագործվել sshfs-ի հետ համատեղ, կարող են օգտագործվել բազմաթիվ օգտվողներ, բայց ըստ էության նույնն է, ինչ նախորդ դեպքը:
http - միայն կարդալու համար
git-ը միայն կարդալու համար է
https - դժվար է տեղադրել, անհրաժեշտ է հավելյալ ծրագրակազմ, ինչ-որ կառավարման վահանակ՝ օգտատերերի մուտքը կազմակերպելու համար... թվում է, թե իրագործելի է, բայց ինչ-որ կերպ ամեն ինչ բարդ է։

Օգտագործելով ssh արձանագրությունը՝ Git սերվերին բազմակի օգտատերերի մուտքը կազմակերպելու համար

Վերադառնանք ssh արձանագրությանը։

Քանի որ դուք օգտագործում եք ssh մուտք git-ի համար, դուք պետք է ապահովեք սերվերի տվյալների անվտանգությունը: Օգտագործողը, ով միանում է 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 սերվերի ադմինիստրատորի կողմից մեկ հրամանով։

Այս օրինակում «Developer 1»-ն աշխատում է proj1 և proj2 նախագծերի վրա, իսկ «Developer 2»-ն աշխատում է proj2 և proj3 նախագծերի վրա:

Եթե Ծրագրավորողներից որևէ մեկը միանում է ssh-ի միջոցով հրամանի տողի միջոցով, ապա նրանց իրավունքները չեն բավարարի նույնիսկ նախագծի դիրեկտորիաների բովանդակությունը դիտելու համար, որոնց նրանք չեն մասնակցում: Նա ինքը չի կարող դա փոխել։

Քանի որ այս սկզբունքի հիմքը Linux-ի իրավունքների հիմնական անվտանգությունն է, այս սխեման հուսալի է: Բացի այդ, սխեման շատ հեշտ է կառավարել:

Անցնենք պրակտիկային։

Git պահեստների ստեղծում Linux սերվերի վրա

Եկեք ստուգենք.

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

Միևնույն ժամանակ սերվերում ստեղծվում են նոր ֆայլեր, և դրանք պատկանում են այն օգտագործողին, ով կատարել է 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-ի օգտագործումը

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 սերվերի վրա մենք ստուգում ենք կեռիկի հետթարմացումից հետո սկրիպտի աշխատանքը commit-ից հետո

[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 find-ում
Ինչպես մի քանի տողեր փոխանցել հանգույցի մեջ՝ օգտագործելով Linux-ի կեղևի մեկ տող
Ինչպես խուսափել միայնակ մեջբերումներից bash-ում
ինչպես ջնջել գրացուցակը իր ողջ բովանդակությամբ windows հրամանի տողում
Ինչպես օգտագործել bash mv ֆայլը վերանվանելու համար՝ առանց այն նորից գրելու

Շնորհակալություն ուշադրության համար:

Source: www.habr.com

GIT սերվերին բազմակի օգտատերերի հասանելիության կազմակերպում