ProHoster > Blog > İdarə > GIT serverinə çox istifadəçi girişinin təşkili

GIT serverinə çox istifadəçi girişinin təşkili

Git serverini quraşdırarkən və konfiqurasiya edərkən bir neçə istifadəçi üçün bir neçə layihəyə girişin təşkili ilə bağlı sual yaranır. Mən məsələni araşdırdım və bütün tələblərimə cavab verən bir həll tapdım: sadə, təhlükəsiz, etibarlı.

Arzularım bunlardır:

  • hər bir istifadəçi öz hesabı ilə əlaqə qurur
  • Bir layihə üzərində bir neçə istifadəçi işləyə bilər
  • eyni istifadəçi bir neçə layihə üzərində işləyə bilər
  • hər bir istifadəçinin yalnız üzərində işlədiyi layihələrə çıxışı var
  • Yalnız bir növ veb interfeysi vasitəsilə deyil, komanda xətti ilə qoşulmaq mümkün olmalıdır

Həm də əla olardı:

  • nəzarət edən şəxslərə yalnız oxumaq üçün icazələr verin
  • Git-də istifadəçi giriş hüquqlarını rahat şəkildə idarə edin

GIT serverinə daxil olmaq üçün mümkün variantların icmalı

Hər şeydən əvvəl, nə seçəcəyinizi bilməlisiniz, ona görə də burada Git protokollarının qısa icmalı var.

  • ssh - serverə daxil olmaq üçün xüsusi yaradılmış istifadəçi hesabı istifadə olunur.
    • Qəribədir ki, Git öz tövsiyələrindən bütün depolara daxil olmaq üçün bir hesabdan istifadə etməyi istisna etmir. Bu mənim tələblərimə qətiyyən cavab vermir.
    • Siz bir neçə hesabdan istifadə edə bilərsiniz, lakin istifadəçi girişini yalnız müəyyən kataloqlara necə məhdudlaşdıra bilərsiniz?
      • Ev kataloquna bağlanmaq uyğun deyil, çünki digər istifadəçilər üçün orada yazma girişini təşkil etmək çətindir
      • Ev kataloqunuzdan simvolik keçidlərdən istifadə etmək də çətindir, çünki Git onları keçid kimi şərh etmir
      • Tərcüməçiyə girişi məhdudlaşdırmaq mümkündür, lakin onun həmişə işləyəcəyinə tam zəmanət yoxdur
        • Siz ümumiyyətlə belə istifadəçilər üçün öz komanda tərcüməçinizi birləşdirə bilərsiniz, lakin
          • birincisi, bu artıq bir növ çətin qərardır,
          • ikincisi, bunun qarşısını almaq olar.

    Amma bəlkə istifadəçinin hər hansı əmrləri yerinə yetirə bilməsi problem deyil?.. Ümumiyyətlə, ondan necə istifadə edəcəyini dəqiq müəyyənləşdirsəniz, bu üsulu istisna etmək olmaz. Bu üsula daha sonra qayıdacağıq, amma hələlik digər alternativləri qısaca nəzərdən keçirəcəyik, bəlkə daha sadə bir şey olacaq.

  • Git yerli protokolu sshfs ilə birlikdə istifadə edilə bilər, birdən çox istifadəçi istifadə edilə bilər, lakin əvvəlki hal ilə eynidir
  • http - yalnız oxumaq üçün
  • git yalnız oxumaq üçündür
  • https - quraşdırmaq çətindir, istifadəçi girişini təşkil etmək üçün əlavə proqram təminatı, bir növ idarəetmə panelinə ehtiyacınız var... bu, mümkün görünür, amma nədənsə hər şey mürəkkəbdir.

Git serverinə çox istifadəçi girişini təşkil etmək üçün ssh protokolundan istifadə

ssh protokoluna qayıdaq.

Git üçün ssh girişindən istifadə etdiyiniz üçün server məlumatlarının təhlükəsizliyini təmin etməlisiniz. Ssh vasitəsilə qoşulan istifadəçi Linux serverində öz loginindən istifadə edir, beləliklə onlar ssh müştərisi vasitəsilə qoşula və serverin komanda xəttinə daxil ola bilərlər.
Belə girişdən tam qorunma yoxdur.

Lakin istifadəçi Linux faylları ilə maraqlanmamalıdır. Əhəmiyyətli məlumatlar yalnız git deposunda saxlanılır. Buna görə də, komanda xətti ilə girişi məhdudlaşdırmaq deyil, Linux alətlərindən istifadə edərək istifadəçinin iştirak etdiyi layihələr istisna olmaqla, layihələrə baxmasını qadağan etmək mümkündür.
Açıq seçim Linux icazə sistemindən istifadə etməkdir.

Artıq qeyd edildiyi kimi, ssh girişi üçün yalnız bir hesabdan istifadə etmək mümkündür. Bu konfiqurasiya bir neçə istifadəçi üçün təhlükəlidir, baxmayaraq ki, tövsiyə olunan git seçimləri siyahısına daxil edilmişdir.

Məqalənin əvvəlində verilən tələbləri həyata keçirmək üçün hüquq və sahiblərin verilməsi ilə aşağıdakı kataloq strukturu yaradılır:

1) layihə qovluqları

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
hara
dir1, dir2, dir3 - layihə qovluqları: layihə 1, layihə 2, layihə 3.

proj1:proj1, proj2:proj2, proj3:proj3 müvafiq layihə kataloqlarının sahibləri kimi təyin edilmiş xüsusi yaradılmış Linux istifadəçiləridir.

bütün kataloqlar üçün icazələr 0770-ə təyin edilmişdir - sahibi və onun qrupu üçün tam giriş və hər kəs üçün tam qadağa.

2) tərtibatçı hesabları

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

Əsas odur ki, tərtibatçılara müvafiq layihənin sistem istifadəçisi sahibinin əlavə qrupu təyin olunur. Bu, Linux server administratoru tərəfindən bir əmrlə edilir.

Bu nümunədə "Developer 1" proj1 və proj2 layihələri üzərində, "Developer 2" isə proj2 və proj3 layihələri üzərində işləyir.

Tərtibatçılardan hər hansı biri komanda xətti ilə ssh vasitəsilə qoşularsa, onların hüquqları hətta iştirak etmədikləri layihə kataloqlarının məzmununa baxmaq üçün kifayət etməyəcək. Özü də bunu dəyişə bilməz.

Bu prinsipin əsasını Linux hüquqlarının əsas təhlükəsizliyi təşkil etdiyi üçün bu sxem etibarlıdır. Bundan əlavə, sxemi idarə etmək çox asandır.

Gəlin praktikaya gedək.

Linux serverində Git depolarının yaradılması

yoxlayaq.

[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

Əllə yazmaqdan yoruldum...

[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

Əminik ki, komanda xəttindən başqa insanların depolarına daxil olmaq və hətta onların məzmununa baxmaq mümkün deyil.

[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-də eyni layihədə birdən çox tərtibatçı ilə əməkdaşlıq edin

Bir sual qalır, əgər bir tərtibatçı yeni bir fayl təqdim edərsə, digər tərtibatçılar onu dəyişdirə bilməzlər, çünki o, özü onun sahibidir (məsələn, dev1) və layihənin istifadəçi sahibi deyil (məsələn, proj1). Bizim server tərəfində repozitoriyamız olduğundan, ilk növbədə “.git” kataloqunun necə qurulduğunu və yeni faylların yaradılıb-yaradılmadığını bilməliyik.

Yerli Git deposu yaratmaq və Git serverinə itələmək

Gəlin müştəri maşınına keçək.

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>

Eyni zamanda, serverdə yeni fayllar yaradılır və onlar təkan həyata keçirən istifadəçiyə aiddir

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

Dəyişiklikləri Git serverinə yüklədiyiniz zaman əlavə fayllar və kataloqlar yaradılır və onların sahibi əslində yükləməni edən istifadəçidir. Lakin sonra bu faylların və qovluqların qrupu bu istifadəçinin əsas qrupuna, yəni dev1 istifadəçisi üçün dev1 qrupuna və dev2 istifadəçisi üçün dev2 qrupuna uyğun gəlir (developer istifadəçisinin əsas qrupunun dəyişdirilməsi kömək etməyəcək, çünki bir neçə layihə üzərində necə işləyə bilərsən?). Bu halda, dev2 istifadəçisi dev1 istifadəçisi tərəfindən yaradılmış faylları dəyişdirə bilməyəcək və bu, funksionallığın pozulmasına səbəb ola bilər.

Linux chown - fayl sahibinin adi istifadəçi tərəfindən dəyişdirilməsi

Faylın sahibi onun sahibliyini dəyişə bilməz. Lakin o, ona aid olan faylın qrupunu dəyişə bilər və sonra bu faylı eyni qrupda olan digər istifadəçilər də dəyişdirə bilər. Bizə lazım olan budur.

Git çəngəlindən istifadə

Hook üçün iş kataloqu layihənin kök kataloqudur. çəngəl təkan edən istifadəçinin altında işləyən icra olunan bir proqramdır. Bunu bilərək, planlarımızı həyata keçirə bilərik.

[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

və ya sadəcə 

vi hooks/post-update

Müştəri maşınına qayıdaq.

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 serverində biz öhdəçilikdən sonra çəngəl post-güncelləmə skriptinin işini yoxlayırıq 

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

- boş, hər şey yaxşıdır.

Git-də ikinci tərtibatçının qoşulması

İkinci tərtibatçının işini simulyasiya edək.

Müştəri üzərində

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

Və eyni zamanda serverdə...

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

— yenə boş, hər şey işləyir.

Git layihəsinin silinməsi və layihənin Git serverindən endirilməsi

Yaxşı, bütün dəyişikliklərin saxlandığına bir daha əmin ola bilərsiniz.

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

— Git layihəsini silmək üçün sadəcə qovluğu tamamilə təmizləyin. Yaranan səhvə dözək, çünki bu əmrdən istifadə edərək cari qovluğu silmək mümkün deyil, lakin bu, bizə lazım olan davranışdır.

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-də paylaşılan giriş

İndi əmin olaq ki, hətta Git vasitəsilə ikinci tərtibatçı işləmədiyi Proj1 layihəsinə daxil ola bilməz.

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.

İndi girişə icazə veririk

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

və bundan sonra hər şey işləyir.

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

Daha ətraflı məlumat üçün,

Əlavə olaraq, faylları və qovluqları yaratarkən standart icazələrlə bağlı problem varsa, CentOS-da əmrdən istifadə edə bilərsiniz.

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

Həm də məqalədə kiçik faydalı şeylərlə qarşılaşa bilərsiniz:

  • Linux-da kataloq ağacını necə qurmaq olar
  • sed-də bir sıra ünvanların müəyyən bir sətirdən faylın sonuna necə ötürülməsi, yəni birinci sətirdən başqa bütün sətirlərdə sed-də əvəz edilməsi
  • Linux tapmaqda axtarış şərtini necə çevirmək olar
  • Linux qabığında bir laynerdən istifadə edərək çoxlu sətirləri döngəyə necə ötürmək olar
  • Bash-da tək dırnaqlardan necə qaçmaq olar
  • Windows əmr satırında bütün məzmunu olan bir kataloqu necə silmək olar
  • Faylın adını yenidən yazmadan dəyişdirmək üçün bash mv-dən necə istifadə etmək olar

Diqqətinizə görə təşəkkür edirik.

Mənbə: www.habr.com

Добавить комментарий