گٹ سرور کو انسٹال اور کنفیگر کرتے وقت، سوال یہ پیدا ہوتا ہے کہ متعدد صارفین کے لیے کئی پروجیکٹس تک رسائی کو منظم کیا جائے۔ میں نے اس مسئلے کی تحقیق کی اور ایک ایسا حل تلاش کیا جو میری تمام ضروریات کو پورا کرتا ہے: سادہ، محفوظ، قابل اعتماد۔
میری خواہشات یہ ہیں:
- ہر صارف اپنے اکاؤنٹ سے جڑتا ہے۔
- کئی صارفین ایک پروجیکٹ پر کام کر سکتے ہیں۔
- ایک ہی صارف متعدد منصوبوں پر کام کر سکتا ہے۔
- ہر صارف کو صرف ان منصوبوں تک رسائی حاصل ہوتی ہے جن پر وہ کام کرتا ہے۔
- کمانڈ لائن کے ذریعے جڑنا ممکن ہونا چاہیے، نہ کہ کسی قسم کے ویب انٹرفیس کے ذریعے
یہ بھی بہت اچھا ہوگا:
- کنٹرول کرنے والے افراد کو صرف پڑھنے کی اجازت دیں۔
- Git میں صارف تک رسائی کے حقوق کا آسانی سے انتظام کریں۔
GIT سرور تک رسائی کے ممکنہ اختیارات کا جائزہ
سب سے پہلے، آپ کو یہ جاننے کی ضرورت ہے کہ کس چیز میں سے انتخاب کرنا ہے، لہذا یہاں گٹ پروٹوکولز کا ایک فوری جائزہ ہے۔
- ssh - سرور تک رسائی کے لیے خاص طور پر بنایا گیا صارف اکاؤنٹ استعمال کیا جاتا ہے۔
- یہ عجیب بات ہے کہ گٹ تمام ذخیروں تک رسائی کے لیے ایک اکاؤنٹ کے استعمال کو اپنی سفارشات سے خارج نہیں کرتا ہے۔ یہ میری ضروریات کو بالکل بھی پورا نہیں کرتا ہے۔
- آپ متعدد اکاؤنٹس استعمال کر سکتے ہیں، لیکن آپ صارف کی رسائی کو صرف مخصوص ڈائریکٹریوں تک کیسے محدود کر سکتے ہیں؟
- ہوم ڈائرکٹری میں بند کرنا مناسب نہیں ہے، کیونکہ دوسرے صارفین کے لیے وہاں تحریری رسائی کو منظم کرنا مشکل ہے۔
- آپ کی ہوم ڈائرکٹری سے symlinks کا استعمال کرنا بھی مشکل ہے کیونکہ Git ان کو لنکس سے تعبیر نہیں کرتا ہے۔
- مترجم تک رسائی کو محدود کرنا ممکن ہے، لیکن اس بات کی کوئی مکمل ضمانت نہیں ہے کہ یہ ہمیشہ کام کرے گا۔
- آپ عام طور پر ایسے صارفین کے لیے اپنے کمانڈ انٹرپریٹر کو جوڑ سکتے ہیں، لیکن
- سب سے پہلے، یہ پہلے سے ہی ایک قسم کا مشکل فیصلہ ہے،
- اور دوم، اس کو روکا جا سکتا ہے۔
- آپ عام طور پر ایسے صارفین کے لیے اپنے کمانڈ انٹرپریٹر کو جوڑ سکتے ہیں، لیکن
لیکن شاید یہ کوئی مسئلہ نہیں ہے کہ صارف کسی بھی حکم پر عمل کرنے کے قابل ہو جائے گا؟... عام طور پر، اس طریقہ کو مسترد نہیں کیا جا سکتا اگر آپ یہ جانتے ہیں کہ اسے کس طرح استعمال کرنا ہے۔ ہم بعد میں اس طریقہ پر واپس جائیں گے، لیکن ابھی کے لیے ہم دوسرے متبادلات پر مختصراً غور کریں گے، شاید کچھ آسان ہو جائے۔
- گٹ لوکل پروٹوکول کو sshfs کے ساتھ مل کر استعمال کیا جا سکتا ہے، متعدد صارفین استعمال کیے جا سکتے ہیں، لیکن بنیادی طور پر پچھلے کیس کی طرح ہی
- http - صرف پڑھنے کے لیے
- git صرف پڑھنے کے لیے ہے۔
- https - انسٹال کرنا مشکل ہے، آپ کو اضافی سافٹ ویئر کی ضرورت ہے، صارف کی رسائی کو منظم کرنے کے لیے کسی قسم کا کنٹرول پینل... یہ ممکن نظر آتا ہے، لیکن کسی نہ کسی طرح سب کچھ پیچیدہ ہے۔
Git سرور تک کثیر صارف کی رسائی کو منظم کرنے کے لیے ssh پروٹوکول کا استعمال
آئیے ssh پروٹوکول پر واپس آتے ہیں۔
چونکہ آپ گٹ کے لیے ssh رسائی استعمال کرتے ہیں، اس لیے آپ کو سرور ڈیٹا کی حفاظت کو یقینی بنانا ہوگا۔ جو صارف ssh کے ذریعے جڑتا ہے وہ لینکس سرور پر اپنا لاگ ان استعمال کرتا ہے، تاکہ وہ ssh کلائنٹ کے ذریعے رابطہ کر سکے اور سرور کی کمانڈ لائن تک رسائی حاصل کر سکے۔
اس طرح کی رسائی کے خلاف کوئی مکمل تحفظ نہیں ہے۔
لیکن صارف کو لینکس فائلوں میں دلچسپی نہیں ہونی چاہیے۔ اہم معلومات صرف گٹ ریپوزٹری میں محفوظ کی جاتی ہیں۔ لہذا، یہ ممکن ہے کہ کمانڈ لائن کے ذریعے رسائی کو محدود نہ کیا جائے، لیکن لینکس ٹولز کا استعمال کرتے ہوئے صارف کو پروجیکٹس دیکھنے سے منع کیا جائے، ان کو چھوڑ کر جن میں وہ حصہ لیتا ہے۔
واضح انتخاب لینکس پرمیشن سسٹم کو استعمال کرنا ہے۔
جیسا کہ پہلے ہی ذکر کیا گیا ہے، ssh رسائی کے لیے صرف ایک اکاؤنٹ استعمال کرنا ممکن ہے۔ یہ ترتیب متعدد صارفین کے لیے غیر محفوظ ہے، حالانکہ یہ تجویز کردہ گٹ اختیارات کی فہرست میں شامل ہے۔
مضمون کے آغاز میں دی گئی ضروریات کو نافذ کرنے کے لیے، حقوق اور مالکان کی تفویض کے ساتھ درج ذیل ڈائریکٹری کا ڈھانچہ بنایا گیا ہے۔
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 خاص طور پر بنائے گئے لینکس کے صارفین ہیں جنہیں متعلقہ پروجیکٹ ڈائریکٹریز کے مالکان کے طور پر تفویض کیا گیا ہے۔
تمام ڈائریکٹریز کے لیے اجازتیں 0770 پر سیٹ ہیں - مالک اور اس کے گروپ کے لیے مکمل رسائی اور باقی سب کے لیے مکمل پابندی۔
2) ڈویلپر اکاؤنٹس
Разработчик 1: dev1:dev1,proj1,proj2
Разработчик 2: dev2:dev2,proj2,proj3
اہم نکتہ یہ ہے کہ ڈویلپرز کو متعلقہ پروجیکٹ کے سسٹم صارف مالک کا ایک اضافی گروپ تفویض کیا جاتا ہے۔ یہ لینکس سرور ایڈمنسٹریٹر ایک کمانڈ کے ساتھ کرتا ہے۔
اس مثال میں، "ڈیولپر 1" پروجیکٹس proj1 اور proj2 پر کام کر رہا ہے، اور "Developer 2" proj2 اور proj3 پر کام کر رہا ہے۔
اگر ڈویلپرز میں سے کوئی بھی کمانڈ لائن کے ذریعے ssh کے ذریعے جڑتا ہے، تو ان کے حقوق کافی نہیں ہوں گے حتیٰ کہ پروجیکٹ ڈائریکٹریوں کے مواد کو دیکھنے کے لیے بھی جس میں وہ حصہ نہیں لیتے ہیں۔ وہ خود اس کو نہیں بدل سکتا۔
چونکہ اس اصول کی بنیاد لینکس کے حقوق کی بنیادی حفاظت ہے، اس لیے یہ اسکیم قابل اعتماد ہے۔ اس کے علاوہ، اسکیم کا انتظام کرنا بہت آسان ہے۔
آئیے پریکٹس کی طرف بڑھیں۔
لینکس سرور پر گٹ ریپوزٹری بنانا
ہم چیک کر رہے ہیں.
[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 deniedGit میں ایک ہی پروجیکٹ پر متعدد ڈویلپرز کے ساتھ تعاون کریں۔
ایک سوال باقی ہے، اگر ایک ڈویلپر ایک نئی فائل متعارف کراتا ہے، تو دوسرے ڈویلپر اسے تبدیل نہیں کر سکتے، کیونکہ وہ خود اس کا مالک ہے (مثال کے طور پر، 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 کی بنائی ہوئی فائلوں کو تبدیل نہیں کر سکے گا، جس کی وجہ سے فعالیت میں خرابی ہو سکتی ہے۔
لینکس چاؤن - ایک عام صارف کے ذریعہ فائل کے مالک کو تبدیل کرنا
فائل کا مالک اس کی ملکیت کو تبدیل نہیں کر سکتا۔ لیکن وہ اس فائل کے گروپ کو تبدیل کر سکتا ہے جو اس کی ہے، اور پھر اس فائل کو دوسرے صارفین بھی تبدیل کر سکتے ہیں جو اسی گروپ میں ہیں۔ ہمیں اسی کی ضرورت ہے۔
گٹ ہک کا استعمال
ہک کے لیے ورکنگ ڈائرکٹری پروجیکٹ کی روٹ ڈائرکٹری ہے۔ ہک ایک قابل عمل ہے جو دھکا کرنے والے صارف کے نیچے چلتا ہے۔ یہ جان کر ہم اپنے منصوبوں کو عملی جامہ پہنا سکتے ہیں۔
[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گٹ سرور پر، ہم کمٹ کے بعد ہک پوسٹ اپ ڈیٹ اسکرپٹ کے آپریشن کو چیک کرتے ہیں۔
[dev1@server proj2]$ find . ! -group proj2
- خالی، سب کچھ ٹھیک ہے۔
گٹ میں دوسرے ڈویلپر کو جوڑنا
آئیے دوسرے ڈویلپر کے کام کی نقل کرتے ہیں۔
کلائنٹ پر
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
- دوبارہ خالی، سب کچھ کام کرتا ہے۔
گٹ پروجیکٹ کو حذف کرنا اور گٹ سرور سے پروجیکٹ کو ڈاؤن لوڈ کرنا
ٹھیک ہے، آپ ایک بار پھر یہ یقینی بنا سکتے ہیں کہ تمام تبدیلیاں محفوظ ہو گئی ہیں۔
C:gittest>rd /S /Q .
Процесс не может получить доступ к файлу, так как этот файл занят другим процессом.- گٹ پروجیکٹ کو حذف کرنے کے لئے، صرف ڈائریکٹری کو مکمل طور پر صاف کریں۔ آئیے پیدا ہونے والی غلطی کا مقابلہ کرتے ہیں، کیونکہ اس کمانڈ کا استعمال کرتے ہوئے موجودہ ڈائریکٹری کو حذف کرنا ناممکن ہے، لیکن یہ بالکل وہی طرز عمل ہے جس کی ہمیں ضرورت ہے۔
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 کے ذریعے بھی دوسرا ڈویلپر 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اس کے علاوہ مضمون میں آپ چھوٹی مفید چیزوں پر ٹھوکر کھا سکتے ہیں:
- لینکس میں ڈائرکٹری کا درخت کیسے بنایا جائے۔
- ایک مخصوص لائن سے فائل کے آخر تک sed میں پتوں کی ایک رینج کو کیسے منتقل کیا جائے، یعنی پہلی لائن کے علاوہ تمام لائنوں میں sed کا متبادل بنائیں
- لینکس فائنڈ میں سرچ کنڈیشن کو کیسے تبدیل کریں۔
- لینکس شیل میں ون لائنر کا استعمال کرتے ہوئے ایک سے زیادہ لائنوں کو لوپ میں کیسے منتقل کیا جائے۔
- باش میں سنگل کوٹس سے کیسے بچیں۔
- ونڈوز کمانڈ لائن میں اس کے تمام مشمولات کے ساتھ ڈائریکٹری کو کیسے حذف کریں۔
- کسی فائل کو دوبارہ لکھے بغیر نام تبدیل کرنے کے لئے bash mv کا استعمال کیسے کریں۔
آپ کی توجہ کے لئے آپ کا شکریہ.
ماخذ: www.habr.com