Bei der Installation und Konfiguration eines Git-Servers stellt sich die Frage, ob der Zugriff mehrerer Benutzer auf mehrere Projekte organisiert werden soll. Ich habe das Problem untersucht und eine Lösung gefunden, die alle meine Anforderungen erfĂŒllt: einfach, sicher, zuverlĂ€ssig.
Meine WĂŒnsche sind wie folgt:
- Jeder Benutzer verbindet sich mit seinem eigenen Konto
- Mehrere Benutzer können an einem Projekt arbeiten
- Der gleiche Benutzer kann an mehreren Projekten arbeiten
- Jeder Benutzer hat nur Zugriff auf die Projekte, an denen er arbeitet
- sollte in der Lage sein, eine Verbindung ĂŒber die Befehlszeile und nicht nur ĂŒber eine Art Webschnittstelle herzustellen
Es wÀre auch toll:
- GewĂ€hren Sie Kontrollpersonen schreibgeschĂŒtzte Rechte
- Benutzerberechtigungen in Git bequem verwalten
Ăbersicht der Optionen fĂŒr den Zugriff auf den GIT-Server
ZunĂ€chst mĂŒssen Sie wissen, aus was Sie auswĂ€hlen können, um einen kurzen Ăberblick ĂŒber die Git-Protokolle zu erhalten.
- ssh - Ein speziell erstelltes Benutzerkonto wird verwendet, um auf den Server zuzugreifen.
- Es ist seltsam, dass Git die Verwendung eines einzelnen Kontos fĂŒr den Zugriff auf alle Repositorys nicht von den Empfehlungen ausschlieĂt. Dies entspricht nicht meinen Anforderungen.
- Sie können mehrere Konten verwenden, aber wie kann der Benutzerzugriff nur auf bestimmte Verzeichnisse beschrÀnkt werden?
- Das SchlieĂen zum Home-Verzeichnis ist nicht geeignet, da es schwierig ist, dort den Schreibzugriff fĂŒr andere Benutzer zu organisieren
- Die Verwendung symbolischer Links aus Ihrem Home-Verzeichnis ist ebenfalls schwierig, da Git sie nicht als Links interpretiert
- Es ist möglich, den Zugriff auf den Dolmetscher einzuschrĂ€nken, es gibt jedoch keine vollstĂ€ndige Garantie dafĂŒr, dass dies immer funktioniert
- Sie können sogar Ihren eigenen Befehlsinterpreter fĂŒr solche Benutzer anschlieĂen, aber,
- Erstens ist dies bereits eine schwierige Entscheidung.
- und in 2 kann dies umgangen werden.
Aber vielleicht ist dies kein Problem, dass der Benutzer Befehle ausfĂŒhren kann? .. Im Allgemeinen kann diese Methode nicht ausgeschlossen werden, wenn Sie wissen, wie sie verwendet wird. Wir werden spĂ€ter auf diese Methode zurĂŒckkommen, aber jetzt kurz die anderen Alternativen betrachten, vielleicht wird dort etwas einfacher.
- Das lokale Git-Protokoll kann in Kombination mit sshfs verwendet werden, es können mehrere Benutzer verwendet werden, dies ist jedoch im Wesentlichen dasselbe wie im vorherigen Fall
- http - schreibgeschĂŒtzt
- Git ist schreibgeschĂŒtzt
- https - Die Installation ist schwierig. Sie benötigen zusĂ€tzliche Software und eine Art Bedienfeld fĂŒr die Organisation des Benutzerzugriffs. Es sieht machbar aus, ist aber irgendwie kompliziert.
Verwenden des SSH-Protokolls zum Organisieren des Mehrbenutzerzugriffs auf den Git-Server
ZurĂŒck zum SSH-Protokoll.
Da der SSH-Zugriff fĂŒr Git verwendet wird, mĂŒssen Sie die Serverdaten sichern. Der Benutzer, der ĂŒber ssh eine Verbindung herstellt, verwendet sein eigenes Login auf dem Linux-Server, sodass er ĂŒber den ssh-Client eine Verbindung herstellen und Zugriff auf die Serverbefehlszeile erhalten kann.
Es gibt keinen vollstÀndigen Schutz gegen einen solchen Zugang.
Der Benutzer sollte sich jedoch nicht fĂŒr Linux-Dateien interessieren. Wichtige Informationen werden nur im Git-Repository gespeichert. Daher können Sie den Zugriff ĂŒber die Befehlszeile nicht einschrĂ€nken, aber Linux kann den Benutzer daran hindern, Projekte anzusehen, mit Ausnahme derjenigen, an denen er teilnimmt.
Offensichtlich mit dem Linux-Berechtigungssystem.
Wie bereits erwĂ€hnt, ist es möglich, nur ein Konto fĂŒr den SSH-Zugriff zu verwenden. Diese Konfiguration ist fĂŒr mehrere Benutzer nicht sicher, obwohl diese Methode in der Liste der empfohlenen Git-Optionen enthalten ist.
Um die am Anfang des Artikels angegebenen Anforderungen umzusetzen, wird die folgende Verzeichnisstruktur mit der Zuweisung von Rechten und EigentĂŒmern erstellt:
1) Projektverzeichnisse
dir1 (proj1: proj1,0770)
dir2 (proj2: proj2,0770)
dir3 (proj3: proj3,0770)
...
wo
dir1, dir2, dir3 - Projektverzeichnisse: Projekt 1, Projekt 2, Projekt 3.
proj1: proj1, proj2: proj2, proj3: proj3 - speziell erstellte Linux-Benutzer, die als Direktoren der jeweiligen Projektverzeichnisse ernannt werden.
Die Rechte an allen Verzeichnissen sind in 0770 festgelegt - vollstĂ€ndiger Zugriff fĂŒr den EigentĂŒmer und seine Gruppe und ein vollstĂ€ndiges Verbot fĂŒr alle anderen.
2) Entwicklerkonten
Entwickler 1: dev1: dev1, proj1, proj2
Entwickler 2: dev2: dev2, proj2, proj3
Der entscheidende Punkt ist, dass Entwicklern eine zusĂ€tzliche Gruppe des Systembenutzers zugewiesen wird, dem das entsprechende Projekt gehört. Dies wird vom Linux-Serveradministrator als einzelner Befehl ausgefĂŒhrt.
In diesem Beispiel arbeitet âEntwickler 1â an den Projekten proj1 und proj2 und âEntwickler 2â an den Projekten proj2 und proj3.
Wenn einer der Entwickler ĂŒber ssh ĂŒber die Befehlszeile eine Verbindung herstellt, reichen seine Rechte nicht einmal aus, um den Inhalt von Projektverzeichnissen anzuzeigen, an denen er nicht beteiligt ist. Er selbst kann dies in keiner Weise Ă€ndern.
Da die Grundlage dieses Prinzips die grundlegende Sicherheit von Linux-Rechten ist, ist dieses Schema zuverlĂ€ssig. DarĂŒber hinaus ist das Schema sehr einfach zu verwalten.
Lass uns weiter ĂŒben.
Erstellen von Git-Repositorys auf einem Linux-Server
Wir prĂŒfen.
[root@server ~]
mĂŒde vom Tippen mit meinen HĂ€nden ...
[root@server gitservertest]
Wir stellen sicher, dass es unmöglich ist, ĂŒber die Befehlszeile auf die Repositorys anderer Personen zuzugreifen und deren Inhalt anzuzeigen.
[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
Zusammenarbeit mehrerer Entwickler in Git an einem Projekt
Eine Frage bleibt, wenn ein Entwickler eine neue Datei einfĂŒhrt, kann der Rest der Entwickler sie nicht Ă€ndern, da er sie selbst besitzt (z. B. dev1) und nicht der Benutzer, dem das Projekt gehört (z. B. proj1). Da wir ein Server-Repository haben, mĂŒssen Sie zunĂ€chst wissen, wie das Verzeichnis ".git" angeordnet ist und ob neue Dateien erstellt werden.
Erstellen eines lokalen Git-Repositorys und Push auf einen Git-Server
Fahren wir mit dem Client-Computer fort.
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://dev1@10.1.1.11/var/gitservertest/proj2" C:\gittest>git push origin master dev1:dev1@10.1.1.11'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>
Gleichzeitig werden auf dem Server neue Dateien erstellt, die dem Benutzer gehören, der den Push ausgefĂŒhrt hat
[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]$
Wenn die Ănderungen auf den Git-Server hochgeladen werden, werden zusĂ€tzliche Dateien und Verzeichnisse erstellt, und gleichzeitig ist der Benutzer, der den Upload durchfĂŒhrt, der EigentĂŒmer. Die Gruppe dieser Dateien und Verzeichnisse entspricht dann aber auch der Hauptgruppe dieses Benutzers, dh der Gruppe dev1 fĂŒr den Benutzer dev1 und der Gruppe dev2 fĂŒr den Benutzer dev2 (das Ăndern der Hauptgruppe des Entwicklungsbenutzers hilft seitdem nicht mehr, wie man an mehreren Projekten arbeitet?). In diesem Fall kann der Benutzer dev2 die vom Benutzer dev1 erstellten Dateien nicht Ă€ndern, was zu einer Verletzung der FunktionalitĂ€t fĂŒhrt.
Linux chown - Ăndern des Besitzers einer Datei durch einen normalen Benutzer
Der EigentĂŒmer der Datei kann seinen EigentĂŒmer nicht Ă€ndern. Er kann jedoch die Gruppe der Datei Ă€ndern, die ihm gehört, und diese Datei kann dann fĂŒr andere Benutzer in derselben Gruppe geĂ€ndert werden. Das brauchen wir.
Git Hook verwenden
Das Arbeitsverzeichnis fĂŒr den Hook ist das Stammverzeichnis des Projekts. hook ist eine ausfĂŒhrbare Datei, die unter dem Benutzer ausgefĂŒhrt wird, der Push ausfĂŒhrt. Wenn wir das wissen, können wir unseren Plan erfĂŒllen.
[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
entweder nur
vi hooks/post-update
ZurĂŒck zum Client-Computer.
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:dev1@10.1.1.11's password: d22c66e..b045e22 master -> master
Auf dem Git-Server ĂŒberprĂŒfen wir nach dem Festschreiben die Funktion des Hook-Post-Update-Skripts
[dev1@server proj2]$ find . ! -group proj2
- leer, alles ist gut
Einen zweiten Entwickler mit Git verbinden
Wir werden die Arbeit des zweiten Entwicklers nachahmen.
Auf dem Client
C:\gittest>git remote remove origin C:\gittest>git remote add origin "ssh://dev2@10.1.1.11/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 dev2@10.1.1.11's password: b045e22..55d49a6 master -> master
Und gleichzeitig auf dem Server ...
[dev1@server proj2]$ find . ! -group proj2
- wieder leer, alles funktioniert.
Entfernen eines Git-Projekts und Herunterladen eines Projekts von einem Git-Server
Nun, Sie können erneut sicherstellen, dass alle Ănderungen erhalten bleiben.
C:\gittest>rd /S /Q . , .
- Um ein Git-Projekt zu entfernen, löschen Sie einfach das Verzeichnis vollstĂ€ndig. Wir werden den generierten Fehler ertragen, da es unmöglich ist, das aktuelle Verzeichnis fĂŒr diesen Befehl zu löschen, aber wir brauchen nur dieses Verhalten.
C:\gittest>dir C:\gittest 21.06.2019 08:43 <DIR> . 21.06.2019 08:43 <DIR> .. C:\gittest>git clone ssh://dev2@10.1.1.11/var/gitservertest/proj2 Cloning into 'proj2'... dev2@10.1.1.11's password: C:\gittest>cd proj2 C:\gittest\proj2>dir C:\gittest\proj2 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:\gittest\proj2>type test1.txt "test dev1 to proj2" "dev1 added some omre" "dev1 3rd line" "!!! dev2 added this" C:\gittest\proj2>type test2.txt "!!! dev2 wrote"
Freigabe des Zugriffs in Git
Stellen wir nun sicher, dass der zweite Entwickler selbst ĂŒber Git keinen Zugriff auf das Proj1-Projekt erhĂ€lt, an dem er nicht arbeitet.
C:\gittest\proj2>git remote remove origin C:\gittest\proj2>git remote add origin "ssh://dev2@10.1.1.11/var/gitservertest/proj1" C:\gittest\proj2>git push origin master dev2@10.1.1.11'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.
Erlauben Sie nun den Zugriff
[root@server ~]
und danach funktioniert alles.
C:\gittest\proj2>git push origin master dev2@10.1.1.11's password: To ssh://10.1.1.11/var/gitservertest/proj1 * [new branch] master -> master
ZusÀtzliche Informationen
Wenn beim Erstellen von Dateien und Verzeichnissen ein Problem mit den Standardberechtigungen auftritt, können Sie den Befehl in CentOS verwenden
setfacl -Rd -mo::5 -mg::7 /var/gitservertest
Auch im Artikel können Sie auf kleine nĂŒtzliche Dinge stoĂen:
- Wie erstelle ich einen Verzeichnisbaum unter Linux?
- wie man sed macht, um einen Adressbereich von einer bestimmten Zeile an das Ende der Datei zu ĂŒbertragen, dh um in sed in allen Zeilen auĂer der ersten Zeile einen Ersatz vorzunehmen
- Wie unter Linux finden, um einen Suchbegriff umzukehren
- Wie man in einer Linux-Shell mehrere Zeilen durch eine einzelne Zeile schleift
- wie man einfachen AnfĂŒhrungszeichen in Bash entgeht
- So löschen Sie das Verzeichnis mit allen Inhalten in der Windows-Befehlszeile
- So verwenden Sie bash mv, um eine Datei umzubenennen, ohne sie erneut zu schreiben
Vielen Dank fĂŒr Ihre Aufmerksamkeit.