Chapters ▾ 2nd Edition

4.6 Git on the Server - Slim HTTP (Smart HTTP)

Slim HTTP (Smart HTTP)

Ons het nou geverifieerde toegang (authenticated access) deur SSH en ongeverifieerde toegang deur git://, maar daar is ook 'n protokol wat albei tegelykertyd kan doen. Die opstel van Smart HTTP is basies net die aktiveer van 'n CGI-skrip wat saam met Git voorsien word, genaamd git-http-backend op die bediener (server). Hierdie CGI sal die pad (path) en opskrifte (headers) lees wat deur 'n git fetch of 'n git push na 'n HTTP-URL gestuur word, en vasstel of die kliënt oor HTTP kan kommunikeer (wat waar is vir enige kliënt sedert weergawe 1.6.6). As die CGI sien dat die kliënt slim is, sal dit slim daarmee kommunikeer; anders sal dit terugval op die dom gedrag (sodat dit agterwaarts versoenbaar / backward compatible is vir leeswerk met ouer kliënte).

Kom ons stap deur 'n baie basiese opstelling. Ons gaan dit opstel met Apache as die CGI-bediener. As jy nie Apache opgestel het nie, kan jy dit op 'n Linux-boks doen met iets soos dit:

$ sudo apt-get install apache2 apache2-utils
$ a2enmod cgi alias env

Dit aktiveer ook die mod_cgi, mod_alias en mod_env modules, wat almal nodig behoort te wees om dit behoorlijk te laat werk.

Jy sal ook die Unix-gebruikersgroep van die /srv/git gidse na www-data moet stel sodat jou webbediener lees- en skryftoegang tot die bewaarplekke (repositories) kan hê, omdat die Apache-instansie wat die CGI-skrip laat loop (by verstek / by default) as daardie gebruiker sal loop:

$ chgrp -R www-data /srv/git

Vervolgens moet ons 'n paar dinge by die Apache-konfigurasie voeg om die git-http-backend te laat loop as die hanteerder (handler) vir enigiets wat by die /git pad van jou webbediener inkom.

SetEnv GIT_PROJECT_ROOT /srv/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/lib/git-core/git-http-backend/

As jy die GIT_HTTP_EXPORT_ALL omgewingsveranderlike weerskryf (leave out), sal Git slegs bewaarplekke met die git-daemon-export-ok lêer daarin aan ongeverifieerde kliënte bedien, net soos die Git-daemon gedoen het.

Ten slotte sal jy vir Apache wil sê om versoeke aan git-http-backend toe te laat en skryfbewerking op een of ander manier geverifieer te maak, moontlik met 'n Auth-blok soos hierdie:

<Files "git-http-backend">
    AuthType Basic
    AuthName "Git Access"
    AuthUserFile /srv/git/.htpasswd
    Require expr !(%{QUERY_STRING} -strmatch '*service=git-receive-pack*' || %{REQUEST_URI} =~ m#/git-receive-pack$#)
    Require valid-user
</Files>

Dit sal van jou vereis om 'n .htpasswd lêer te skep wat die wagwoorde van al die geldige gebruikers bevat. Hier is 'n voorbeeld van die byvoeging van 'n “schacon” gebruiker by die lêer:

$ htpasswd -c /srv/git/.htpasswd schacon

Daar is talle maniere om te sorg dat Apache gebruikers verifieer; jy sal een van hulle moet kies en implementeer. Dit is net die eenvoudigste voorbeeld waaraan ons kon dink. Jy sal dit byna seker ook oor SSL wil opstel sodat al hierdie data geënkripteer word.

Ons wil nie too veel in die diep ent ingaan oor spesifieke Apache-konfigurasies nie, aangesien jy dalk 'n ander bediener gebruik of verskillende verifikasiebehoeftes het. Die idee is dat Git met 'n CGI genaamd git-http-backend kom wat, wanneer dit geroep word, al die onderhandeling sal doen om data oor HTTP te stuur en te ontvang. Dit implementeer nie self enige verifikasie nie, maar dit kan maklik beheer word op die vlak van die webbediener wat dit aanroep. Jy kan dit met prakties enige CGI-bekwame webbediener doen, so gaan met die een wat jy die beste ken.

Note

Vir meer inligting oor die opstel van verifikasie in Apache, kyk na die Apache-dokumentasie hier: https://httpd.apache.org/docs/current/howto/auth.html.