Achtung: Ob man die Variable $USER an den Stellen, wo sie verwendet wird, auch wirklich nutzen sollte, habe ich nicht überprüft. Manuell den Nutzer eintragen ist sicherer.
Langer Titel, langer Weg dahin:
Alles fing damit an, dass “mal eben” zwei an einem Git-Repo arbeiten wollen, und da ich eben uberspace.de mag und dort Git zu Verfügung hatte, nutzten wir eben gitolite. Wir fingen an, doch bald stellte sich das erste Problem: Wie sollen andere das Repo “test.git” clonen? Wir können (dank dem SSH-Key) ja mal eben
git clone user@cetus.uberspace.de:test
machen, und haben halt einen Klon auf dem Rechner. Will man das ganze verlinken, kam Jonas als erstes die Idee, das Repo in einen für den Apachen erreichbaren Ordner zu verschieben und einen (wer hätte es gedacht) Link zu erstellen:
mkdir /var/www/virtual/$USER/git.$USER.cetus.uberspace.de cd /var/www/virtual/$USER/git.$USER.cetus.uberspace.de mv /home/$USER/repositories/test.git test.git ln -s /var/www/virtual/$USER/git.$USER.cetus.uberspace.de/test.git /home/$USER/repositories/test.git
Wenn man jetzt aber versucht, das Repo zu clonen, wird das an einem 403 scheitern:
$ git clone http://git.user.cetus.uberspace.de/test.git Cloning into 'test'... error: The requested URL returned error: 403 while accessing http://git.user.cetus.uberspace.de/test.git/info/refs?service=git-upload-pack fatal: HTTP request failed
Das liegt an der Berechtigung. Der Ordner /var/www/virtual/$USER/git.$USER.cetus.uberspace.de hat von sich aus einen chmod von 700, und diverse Unterverzeichnisse bekommen den bei jedem push. Also jedes mal einen chmod setzen, ist sinnfrei. Damit alles funktioniert, braucht das Verzeichnis /var/www/virtual/$USER/git.$USER.cetus.uberspace.de/test.git einen chmod von 705, und alle Unterordner und Dateien auch. Direkt nach dem erstellen des Repos sollte man es schon verschieben und diverse Handlungen vornehmen, auch vor dem ersten push. Als erstes wären da die update-server-infos , und der chmod:
cd /var/www/virtual/$USER/git.$USER.cetus.uberspace.de/test.git git update-server-info cd .. chmod -R 705 test.git
…jetzt sind da noch ein paar Sachen. Damit wir genau das nicht nach jedem push machen müssen, automatisieren wir uns das. Und zwar so, dass auch zukünftige Repos was davon haben:
cat > ~/repo.sh <<__EOF__ #!/bin/sh #Example: user "max-mustermann" with subdomain "git.mustermann.tld": #chmod -R 705 /var/www/virtual/max-mustermann/git.mustermann.tld/$1 chmod -R 705 /var/www/virtual///$1 __EOF__ chmod +x ~/repo.sh
Jetzt hätten wir die Datei repo.sh im /home , also jetzt weiter an das Repo selbst, denn dort brauchen wir einen sogenannten Hook:
cd /var/www/virtual/$USER/git.$USER.cetus.uberspace.de/test.git/hooks cat > post-receive <<__EOF__ #!/bin/sh #ACHTUNG: User und Name des Repos manuell setzen! git update-server-info /home//repo.sh test.git __EOF__ chmod +x post-receive
Dann einfach mal den ersten push machen, und der Hook wird abgefeuert. Das wars eigentlich, die Repos sind nun per HTTP clonbar. Sollte es Fragen zu diesem kleinen Post geben, einfach mal eben ein Kommentar schreiben :)
2 Responses
Hi,
Ich kriege leider immer einen return code 22, wenn ich mir das repo gecloned habe mit “git clone http://git.MeinName.phoenix.uberspace.de/meinRepo.git” und danach einen commit pushen möchte.
Ich habe das Gefühl eine Kleinigkeit übersehen zu haben bei deiner Beschreibung.
Vielen Dank und Viele Grüße
Jan
Hallo Jan,
du scheinst, in das Repo per HTTP pushen zu wollen. Das geht so nicht ohne weiteres, du kannst nachwievor nur per SSH an MeinName@phoenix.uberspace.de:meinRepo.git pushen. Die Variante über HTTP entspricht einem read-only-Zugriff, der eher dafür gedacht ist, dass sich potentielle User deiner Software den aktuellen Stand clonen können, die sowieso keinen Schreibzugriff haben. Schreibzugriff ist damit nicht möglich, das geht nur per SSH wie auch im Wiki von uberspace beschrieben.
Viele Grüße,
Lucas