English ▾ Themen ▾ Neueste Version ▾ git-http-backend zuletzt aktualisiert in 2.49.0

NAME

git-http-backend - Serverseitige Implementierung von Git über HTTP

SYNOPSIS

git http-backend

BESCHREIBUNG

Ein einfaches CGI-Programm, um den Inhalt eines Git-Repositorys für Git-Clients bereitzustellen, die über http:// und https://-Protokolle auf das Repository zugreifen. Das Programm unterstützt Clients, die sowohl das Smart-HTTP-Protokoll als auch das abwärtskompatible Dumb-HTTP-Protokoll zum Abrufen verwenden, sowie Clients, die das Smart-HTTP-Protokoll zum Pushen verwenden. Es unterstützt auch das effizientere "v2"-Protokoll von Git, wenn es richtig konfiguriert ist; siehe die Erörterung von GIT_PROTOCOL im Abschnitt UMWELT unten.

Es prüft, ob das Verzeichnis die magische Datei "git-daemon-export-ok" hat, und weigert sich, ein Git-Verzeichnis zu exportieren, das nicht explizit auf diese Weise für den Export markiert wurde (es sei denn, die Umgebungsvariable GIT_HTTP_EXPORT_ALL ist gesetzt).

Standardmäßig ist nur der Dienst upload-pack aktiviert, der git fetch-pack und git ls-remote-Clients bedient, die von git fetch, git pull und git clone aufgerufen werden. Wenn der Client authentifiziert ist, ist der Dienst receive-pack aktiviert, der git send-pack-Clients bedient, die von git push aufgerufen werden.

DIENSTE

Diese Dienste können über die repository-spezifische Konfigurationsdatei aktiviert/deaktiviert werden

http.getanyfile

Dies bedient Git-Clients älter als Version 1.6.6, die den Upload-Pack-Dienst nicht verwenden können. Wenn aktiviert, können Clients jede Datei innerhalb des Repositorys lesen, einschließlich Objekten, die nicht mehr von einem Branch erreichbar, aber noch vorhanden sind. Er ist standardmäßig aktiviert, aber ein Repository kann ihn deaktivieren, indem dieser Konfigurationswert auf false gesetzt wird.

http.uploadpack

Dies bedient git fetch-pack und git ls-remote-Clients. Er ist standardmäßig aktiviert, aber ein Repository kann ihn deaktivieren, indem dieser Konfigurationswert auf false gesetzt wird.

http.receivepack

Dies bedient git send-pack-Clients, was das Pushen ermöglicht. Er ist standardmäßig für anonyme Benutzer deaktiviert und für Benutzer, die vom Webserver authentifiziert wurden, standardmäßig aktiviert. Er kann deaktiviert werden, indem dieser Eintrag auf false gesetzt wird, oder für alle Benutzer, einschließlich anonyme Benutzer, aktiviert werden, indem er auf true gesetzt wird.

http.uploadarchive

Dies bedient git archive-Clients für Remote-Archive über HTTP/HTTPS-Protokolle. Er ist standardmäßig deaktiviert. Er funktioniert nur im Protokoll v2.

URL-ÜBERSETZUNG

Um den Speicherort des Repositorys auf der Festplatte zu ermitteln, verkettet git http-backend die Umgebungsvariablen PATH_INFO, die automatisch vom Webserver gesetzt wird, und GIT_PROJECT_ROOT, die manuell in der Webserverkonfiguration gesetzt werden muss. Wenn GIT_PROJECT_ROOT nicht gesetzt ist, liest git http-backend PATH_TRANSLATED, das ebenfalls automatisch vom Webserver gesetzt wird.

BEISPIELE

Alle folgenden Beispiele bilden http://$hostname/git/foo/bar.git auf /var/www/git/foo/bar.git ab.

Apache 2.x

Stellen Sie sicher, dass mod_cgi, mod_alias und mod_env aktiviert sind, setzen Sie GIT_PROJECT_ROOT (oder DocumentRoot) entsprechend und erstellen Sie einen ScriptAlias für das CGI

SetEnv GIT_PROJECT_ROOT /var/www/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/

# This is not strictly necessary using Apache and a modern version of
# git-http-backend, as the webserver will pass along the header in the
# environment as HTTP_GIT_PROTOCOL, and http-backend will copy that into
# GIT_PROTOCOL. But you may need this line (or something similar if you
# are using a different webserver), or if you want to support older Git
# versions that did not do that copying.
#
# Having the webserver set up GIT_PROTOCOL is perfectly fine even with
# modern versions (and will take precedence over HTTP_GIT_PROTOCOL,
# which means it can be used to override the client's request).
SetEnvIf Git-Protocol ".*" GIT_PROTOCOL=$0

Um anonymen Lesezugriff, aber authentifizierten Schreibzugriff zu ermöglichen, fordern Sie die Autorisierung sowohl für die anfängliche Ref-Anzeige (die wir als Push über den Service-Parameter in der Abfragezeichenkette erkennen) als auch für den Aufruf von receive-pack selbst an

RewriteCond %{QUERY_STRING} service=git-receive-pack [OR]
RewriteCond %{REQUEST_URI} /git-receive-pack$
RewriteRule ^/git/ - [E=AUTHREQUIRED:yes]

<LocationMatch "^/git/">
	Order Deny,Allow
	Deny from env=AUTHREQUIRED

	AuthType Basic
	AuthName "Git Access"
	Require group committers
	Satisfy Any
	...
</LocationMatch>

Wenn Sie mod_rewrite nicht zum Abgleichen mit der Abfragezeichenkette zur Verfügung haben, reicht es aus, nur git-receive-pack selbst zu schützen, wie:

<LocationMatch "^/git/.*/git-receive-pack$">
	AuthType Basic
	AuthName "Git Access"
	Require group committers
	...
</LocationMatch>

In diesem Modus fordert der Server keine Authentifizierung an, bis der Client tatsächlich die Objektverhandlungsphase des Push-Vorgangs beginnt, anstatt während des ersten Kontakts. Aus diesem Grund müssen Sie auch die Konfigurationsoption http.receivepack in allen Repositorys aktivieren, die einen Push akzeptieren sollen. Das Standardverhalten, wenn http.receivepack nicht gesetzt ist, ist die Ablehnung jeglicher Push-Vorgänge durch nicht authentifizierte Benutzer; die anfängliche Anfrage meldet dem Client daher 403 Forbidden, ohne auch nur eine Möglichkeit zur Authentifizierung zu geben.

Um die Authentifizierung für Lese- und Schreibvorgänge zu verlangen, verwenden Sie eine Location-Direktive um das Repository oder eines seiner übergeordneten Verzeichnisse

<Location /git/private>
	AuthType Basic
	AuthName "Private Git Access"
	Require group committers
	...
</Location>

Um gitweb unter derselben URL bereitzustellen, verwenden Sie ein ScriptAliasMatch nur für die URLs, die git http-backend verarbeiten kann, und leiten Sie den Rest an gitweb weiter

ScriptAliasMatch \
	"(?x)^/git/(.*/(HEAD | \
			info/refs | \
			objects/(info/[^/]+ | \
				 [0-9a-f]{2}/[0-9a-f]{38} | \
				 pack/pack-[0-9a-f]{40}\.(pack|idx)) | \
			git-(upload|receive)-pack))$" \
	/usr/libexec/git-core/git-http-backend/$1

ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/

Um mehrere Repositorys aus verschiedenen gitnamespaces[7] in einem einzigen Repository bereitzustellen

SetEnvIf Request_URI "^/git/([^/]*)" GIT_NAMESPACE=$1
ScriptAliasMatch ^/git/[^/]*(.*) /usr/libexec/git-core/git-http-backend/storage.git$1
Beschleunigtes statisches Apache 2.x

Ähnlich wie oben, aber Apache kann verwendet werden, um statische Dateien zurückzugeben, die auf der Festplatte gespeichert sind. Auf vielen Systemen kann dies effizienter sein, da Apache den Kernel bitten kann, die Dateiinhalte direkt vom Dateisystem ins Netzwerk zu kopieren

SetEnv GIT_PROJECT_ROOT /var/www/git

AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$          /var/www/git/$1
AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/

Dies kann mit der gitweb-Konfiguration kombiniert werden

SetEnv GIT_PROJECT_ROOT /var/www/git

AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$          /var/www/git/$1
AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1
ScriptAliasMatch \
	"(?x)^/git/(.*/(HEAD | \
			info/refs | \
			objects/info/[^/]+ | \
			git-(upload|receive)-pack))$" \
	/usr/libexec/git-core/git-http-backend/$1
ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
Lighttpd

Stellen Sie sicher, dass mod_cgi, mod_alias, mod_auth, mod_setenv geladen sind, setzen Sie dann GIT_PROJECT_ROOT entsprechend und leiten Sie alle Anfragen an das CGI weiter

alias.url += ( "/git" => "/usr/lib/git-core/git-http-backend" )
$HTTP["url"] =~ "^/git" {
	cgi.assign = ("" => "")
	setenv.add-environment = (
		"GIT_PROJECT_ROOT" => "/var/www/git",
		"GIT_HTTP_EXPORT_ALL" => ""
	)
}

Um anonymen Lesezugriff, aber authentifizierten Schreibzugriff zu ermöglichen

$HTTP["querystring"] =~ "service=git-receive-pack" {
	include "git-auth.conf"
}
$HTTP["url"] =~ "^/git/.*/git-receive-pack$" {
	include "git-auth.conf"
}

wobei git-auth.conf etwa wie folgt aussieht

auth.require = (
	"/" => (
		"method" => "basic",
		"realm" => "Git Access",
		"require" => "valid-user"
	       )
)
# ...and set up auth.backend here

Um die Authentifizierung für Lese- und Schreibvorgänge zu verlangen

$HTTP["url"] =~ "^/git/private" {
	include "git-auth.conf"
}

UMGEBUNG

git http-backend verlässt sich auf die CGI-Umgebungsvariablen, die vom aufrufenden Webserver gesetzt werden, einschließlich

  • PATH_INFO (wenn GIT_PROJECT_ROOT gesetzt ist, andernfalls PATH_TRANSLATED)

  • REMOTE_USER

  • REMOTE_ADDR

  • CONTENT_TYPE

  • QUERY_STRING

  • REQUEST_METHOD

Die Umgebungsvariable GIT_HTTP_EXPORT_ALL kann an git-http-backend übergeben werden, um die Prüfung auf die Datei "git-daemon-export-ok" in jedem Repository zu umgehen, bevor der Export dieses Repositorys erlaubt wird.

Die Umgebungsvariable GIT_HTTP_MAX_REQUEST_BUFFER (oder die Konfigurationsoption http.maxRequestBuffer) kann gesetzt werden, um die größte Ref-Verhandlungsanfrage zu ändern, die Git bei einem Fetch verarbeitet; jeder Fetch, der einen größeren Puffer benötigt, wird nicht erfolgreich sein. Dieser Wert muss normalerweise nicht geändert werden, kann aber hilfreich sein, wenn Sie von einem Repository mit einer extrem großen Anzahl von Refs fetchen. Der Wert kann mit einer Einheit angegeben werden (z. B. 100M für 100 Megabyte). Der Standardwert ist 10 Megabyte.

Clients können optionale Protokollfähigkeiten (wie das v2-Protokoll) über den Git-Protocol HTTP-Header abfragen. Um diese zu unterstützen, muss der Inhalt dieses Headers in der Umgebungsvariable GIT_PROTOCOL enthalten sein. Die meisten Webserver leiten diesen Header über die Variable HTTP_GIT_PROTOCOL an das CGI weiter, und git-http-backend kopiert diesen automatisch in GIT_PROTOCOL. Einige Webserver sind jedoch möglicherweise wählerischer, welche Header sie weiterleiten. In diesem Fall müssen sie explizit konfiguriert werden (siehe die Erwähnung von Git-Protocol in der Apache-Konfiguration aus dem vorherigen BEISPIELE-Abschnitt).

Der Backend-Prozess setzt GIT_COMMITTER_NAME auf $REMOTE_USER und GIT_COMMITTER_EMAIL auf ${REMOTE_USER}@http.${REMOTE_ADDR}, um sicherzustellen, dass alle von git-receive-pack erstellten Reflogs einige identifizierende Informationen über den entfernten Benutzer, der den Push durchgeführt hat, enthalten.

Alle CGI-Umgebungsvariablen sind für jeden der von git-receive-pack aufgerufenen Hooks verfügbar.

GIT

Teil der git[1] Suite