HTTP-serveren Apache er en nettverksserver i tungvektsklassen som Subversion kan bruke. Ved hjelp av en spesiallaget modul gjør httpd Subversiondepoter tilgjengelig for klienter via WebDAV/DeltaV-protokollen, som er en utvidelse av HTTP 1.1 (se http://www.webdav.org/ for mer informasjon). Denne protokollen tar HTTP-protokollen som vi finner over alt, kjernen av World Wide Web, og legger til muligheter for skriving – mer spesifikt, versjonert skriving. Resultatet er et standardisert, robust system som går godt sammen med Apache 2.0-programvaren, støttet av et stort antall operativsystemer og tredjeparts programvare. Og systemadministratorer trenger ikke å åpne enda en port på systemet.[37] En Apache/Subversion-server har større funksjonalitet enn svnserve, men er også vanskeligere å sette opp. Med fleksibilitet kommer det ofte mer kompleksitet med på kjøpet.
Mye av den følgende diskusjonen inneholder referanser til konfigurasjonsdirektiver for Apache. Selv om noen eksempler inneholder bruk av disse direktivene, er det å beskrive dem i full detalj utenfor det som dette kapittelet dekker. Utviklerne bak Apache vedlikeholder fortreffelig dokumentasjon, offentlig tilgjengelig på hjemmesiden http://httpd.apache.org. En generell oversikt over konfigurasjonsdirektivene er for eksempel tilgjengelig på http://httpd.apache.org/docs-2.0/mod/directives.html.
I tillegg, etter hvert som du gjør forandringer til
Apacheoppsettet, kan det skje at en feil blir gjort på veien.
Hvis du ikke allerede kjenner til Apaches loggesystem, bør du bli
kjent med det.
I httpd.conf-fila di er det direktiver som
spesifiserer plasseringer på disken av aksess- og
feilmeldingsloggene som genereres av Apache (henholdsvis
direktivene CustomLog og
ErrorLog).
Subversions mod_dav_svn bruker også Apaches logging av
feilmeldinger.
Du kan alltids gå gjennom innholdet av disse filene etter
informasjon som kan vise kilden til et problem som ellers ikke er
lett å få øye på.
For å få depotet ditt på nettverk over HTTP, trenger du hovedsaklig fire komponenter, tilgjengelig i to pakker. Du trenger Apache httpd 2.0, DAV-modulen mod_dav som følger med Apache, Subversion og filsystemmodulen mod_dav_svn som kommer sammen med Subversion. Når du har alle disse komponentene er prosessen å få depotet på nett så enkel som å:
få httpd 2.0 opp og kjøre med mod_dav-modulen,
installere programtillegget mod_dav_svn til mod_dav, som bruker Subversions biblioteker til å aksessere depotet, og
konfigurere httpd.conf-fila di til
å eksportere (eller vise) depotet.
Du kan sette opp de første to elementene enten ved å
kompilere httpd og Subversion fra kildekode
eller ved å installere ferdigbygde pakker med dem på systemet.
For den mest oppdaterte informasjonen om hvordan du kompilerer
Subversion for bruk sammen med Apache HTTP-serveren og
hvordan kompilere og sette opp selve Apache for dette, se
INSTALL-fila på toppnivået av
kildekodetreet til Subversion.
Når du har alle de nødvendige komponentene installert på
systemet ditt, er alt som gjenstår å konfigurere Apache ved
hjelp av httpd.conf-fila.
Få Apache til å laste mod_dav_svn-modulen ved å bruke
LoadModule-direktivet.
Dette direktivet må komme foran alle andre Subversion-relaterte
elementer.
Hvis Apache ble installert med standard filplasseringer, er
mod_dav_svn-modulen plassert i
modules-katalogen der Apache er installert
(ofte /usr/local/apache2).
LoadModule-direktivet har en enkel syntaks
som kobler en navngitt modul til plasseringen
av et delt bibliotek på disken:
LoadModule dav_svn_module modules/mod_dav_svn.so
Legg merke til at hvis mod_dav ble
kompilert som et delt objekt (istedenfor å bli statisk linket
direkte til binærfila httpd) vil du også
trenge en tilsvarende LoadModule-linje for
dette.
Pass på at den kommer før
mod_dav_svn-linjen:
LoadModule dav_module modules/mod_dav.so LoadModule dav_svn_module modules/mod_dav_svn.so
På en senere plassering i konfigurasjonsfila må du fortelle
Apache hvor du har lagt Subversiondepotet (eller depotene).
Location-direktivet har en XML-lignende
notasjon som starter med et åpningselement og slutter med et
sluttelement med diverse andre konfigurasjonsdirektiver i
midten.
Formålet med Location-direktivet er å
instruere Apache til å gjøre noe spesielt når den behandler
forespørsler som går til en gitt URL eller et av dens barn.
I tilfellet med Subversion vil du at Apache gir støtte for URLer
som peker til en versjonert ressurs i DAV-laget.
Du kan instruere Apache til å delegere håndteringen av alle
URLer der en del av stien (den delen av URLen som kommer etter
servernavnet og det valgfrie portnummeret) som begynner med
/repos/ til en DAV-tjeneste som har depotet
plassert som /absolutt/sti/til/depotet ved
å bruke den følgende
httpd.conf-syntaksen:
<Location /repos> DAV svn SVNPath /absolutt/sti/til/depotet </Location>
Hvis du planlegger å ha flere Subversiondepoter som vil
ligge i den samme foreldrekatalogen på en lokal disk, kan du
bruke et alternativt direktiv,
SVNParentPath-direktivet, for å indikere
denne felles foreldrekatalogen.
Hvis du for eksempel vet at du vil opprette flere
Subversiondepoter i katalogen
/usr/local/svn som vil bli aksessert vie
URLer som http://min.server.com/svn/depot1,
http://min.server.com/svn/depot2 og så videre, kan
du bruke httpd.conf-konfigurasjonssyntaksen
i det følgende eksempelet:
<Location /svn> DAV svn # alle "/svn/foo"-URLer vil kobles til katalogen /usr/local/svn/foo SVNParentPath /usr/local/svn </Location>
Ved å bruke den foregående syntaksen vil Apache delegere
håndteringen av alle URLer der stien begynner med
/svn/ til DAV-tjenesten for Subversion som
deretter vil gå ut i fra at alle elementer i katalogen
spesifisert med SVNParentPath-direktivet
faktisk er Subversiondepoter.
Dette er en spesielt lettvint syntaks fordi i motsetning til
bruken av SVNPath-direktivet trenger du ikke
å starte Apache på nytt for å opprette nye depoter og få dem på
nett.
Pass på at den nye Location-defineringen
ikke overlapper med andre eksporterte plasseringer.
For eksempel, hvis hovedplasseringen av
DocumentRoot eksporteres til
/www, ikke eksporter et Subversiondepot med
<Location /www/repos>.
Hvis en forespørsel kommer for URIen
/www/repos/foo.c, vet ikke Apache om den
skal se etter fila repos/foo.c i
DocumentRoot eller om den skal delegere
jobben til mod_dav_svn for å returnere
foo.c fra Subversiondepotet.
På dette steget bør du sterkt vurdere spørsmålet angående rettigheter. Hvis du har kjørt Apache en stund som din vanlige webserver, har du sannsynligvis en samling med innhold – hjemmesider, skript og lignende. Disse elementene er allerede blitt satt opp med et sett rettigheter som gjør at de fungerer med Apache, eller rettere sagt, som gjør at Apache virker med disse filene. Når Apache brukes som en Subversionserver vil den også trenge de riktige rettighetene for å lese og skrive til Subversiondepotet.
Du må finne fram til et oppsett for rettighetssystemet som
tilfredsstiller Subversions krav uten å rote til noen av de
nettsidene eller skriptene som er installert fra før.
Dette kan bety å forandre rettighetene på Subversiondepotet til
å samsvare med de som brukes av andre ting som Apache håndterer
for deg, eller det kan innebære å bruke direktivene
User og Group i
httpd.conf for å spesifisere at Apache må
kjøre som den brukeren og gruppen som eier Subversiondepotet.
Det er ingen enkelt universalløsning for å sette opp
rettighetene, og hver administrator vil ha forskjellige grunner
for å gjøre ting på en spesiell måte.
Bare husk at rettighetsrelaterte problemer kanskje er det som
oftest blir oversett når et Subversiondepot settes opp for bruk
med Apache.
På dette punktet, hvis du satte opp
httpd.conf til å inneholde noe som
<Location /svn> DAV svn SVNParentPath /usr/local/svn </Location>
…er depotet ditt “anonymt” tilgjengelig for
hele verden.
Inntil du setter opp regler for autentisering og autorisasjon,
vil Subversiondepotene som du gjør tilgjengelig via
Location-direktivet generelt være
tilgjengelig for alle.
Med andre ord,
alle kan bruke Subversionklienten sin til å hente ut e arbeidskopi av en URL i depotet (eller enhver underkatalog under det),
alle kan interaktivt bla igjennom depotets seneste revisjon ved å bare gå til depot-URLen med nettleseren, og
alle kan foreta innlegginger i depotet.
Den enkleste måten å autentisere en klient er via den grunnleggende HTTP-autentiseringsmekanismen som rett og slett bruker et brukernavn og passord for å kontrollere at en bruker er den som hun sier at hun er. Apache har et program kalt htpasswd for å vedlikeholde listen med akseptable brukernavn og passord for de som du vil gi spesialtilgang til Subversiondepotet ditt. La oss gi Sally og Harry tilgang til å legge inn forandringer i depotet. Først må vi legge dem til passordfila.
$ ### Første gang: Bruk -c for å opprette fila $ ### Bruk -m for å bruke MD5-kryptering av passordet, noe som er sikrere $ htpasswd -cm /etc/svn-passord-fil harry New password: ***** Re-type new password: ***** Adding password for user harry $ htpasswd -m /etc/svn-passord-fil sally New password: ******* Re-type new password: ******* Adding password for user sally $
Det neste som du må gjøre er å legge til noen flere
httpd.conf-direktiver inne i
Location-blokken for å fortelle Apache hva
den skal gjøre med den nye passordfila.
AuthType-direktivet spesifiserer hvilken
type autentiseringssystem som skal brukes.
I dette tilfellet vil vi spesifisere
Basic-autentiseringssystemet.
AuthName er et vilkårlig navn som du angir
for autentiseringsområdet.
De fleste nettleserne vil vise dette navnet i et
oppsprettsvindu når nettleseren spør brukeren etter navn og
passord.
Til sist, bruk AuthUserFile-direktivet for
å angi plasseringen til passordfila som du opprettet ved å
bruke htpasswd.
Etter at du har lagt til disse tre direktivene, skal
<Location>-blokken din se ut omtrent
som dette:
<Location /svn> DAV svn SVNParentPath /usr/local/svn AuthType Basic AuthName "Subversiondepot" AuthUserFile /etc/svn-passord-fil </Location>
Denne <Location>-blokken er ikke
komplett enda, og vil ikke gjøre noe nyttig.
Den forteller bare Apache at hver gang det kreves autorisasjon
skal Apache hente et brukernavn og passord fra
Subversionklienten.
Det som mangler her er direktiver som forteller Apache
hvilke typer klientforespørsler som
krever autorisasjon.
Der autorisasjon kreves, vil Apache også forlange
autentisering.
Den enkleste tingen er å beskytte alle forespørsler.
Ved å legge til Require valid-user
forteller vi Apache at alle forespørsler må komme fra en
autentisert bruker:
<Location /svn> DAV svn SVNParentPath /usr/local/svn AuthType Basic AuthName "Subversiondepot" AuthUserFile /etc/svn-passord-fil Require valid-user </Location>
Pass på å lese den neste seksjonen (“Autorisasjonsvalg”) for flere detaljer
om Require-direktivet og andre måter å
sette opp autorisasjonsregler på.
En advarsel:
“HTTP Basic Auth”-passord blir sendt
omtrent i klartekst over nettverket, og er derfor ekstremt
usikkert.
Hvis du er bekymret for passordsniffing, er det best å bruke
en form for SSL-kryptering, så klienter autentiserer via
https:// istedenfor
http://; som et minimum kan du
sette opp Apache til å bruke et selvsignert
sertifikat.[38]
Konsulter Apaches dokumentasjon (og dokmentasjon om OpenSSL)
om hvordan det gjøres.
Forretninger som har behov for å utsette depotene for tilgang fra utsiden av firmabrannveggen bør være bevisst på muligheten for at uautoriserte parter kan “sniffe” nettverkstrafikken deres. SSL minsker sjansen for at denne formen for uønsket oppmerksomhet resulterer i sensitive datalekkasjer.
Hvis en Subversionklient er kompilert for å kunne bruke
OpenSSL, gir det muligheten til å snakke til en Apacheserver
via http://-URLer.
Neon-biblioteket som brukes av Subversionklienten er ikke bare
i stand til å kontrollere serversertifikater, men kan også
oppgi klientsertifikater når den blir spurt om det.
Når klienten og serveren har vekslet SSL-sertifikater og
klart å autentisere hverandre, vil all videre kommunikasjon
bli kryptert med en sesjonsnøkkel.
Det er utenfor temaet for denne boka å beskrive hvordan man lager klient- og serversertifikater, og hvordan Apache settes opp for å bruke dem. Mange andre bøker, inkludert Apaches egen dokumentasjon, beskriver denne oppgaven. Men det som kan bli dekket her er hvordan man vedlikeholder server- og klientsertifikater fra en vanlig Subversionklient.
Mens det snakkes med Apache via
https:// kan en Subversionklient motta to
typer informasjon:
et serversertifikat
krav om et klientsertifikat
Hvis klienten mottar et serversertifikat, må den sjekke at den stoler på sertifikatet – er serveren virkelig den som den påstår at den er? OpenSSL-biblioteket gjør dette ved å undersøke signatøren av serversertifikatet eller godkjenningsinstansen – certifying authority (CA). Hvis OpenSSL ikke er i stand til å automatisk stole på godkjenningsinstansen, eller hvis et annet problem oppstår (som et utgått sertifikat eller at servernavnet ikke stemmer), vil Subversionkommandolinjeklienten vil spørre deg om du vil stole på serversertifikatet uansett:
$ svn list https://server.example.com/repos/prosjekt Error validating server certificate for 'https://server.example.com:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: server.example.com - Valid: from Jan 30 19:23:56 2004 GMT until Jan 30 19:23:56 2006 GMT - Issuer: CA, example.com, Sometown, California, US - Fingerprint: 7d:e1:a9:34:33:39:ba:6a:e9:a5:c4:22:98:7b:76:5c:92:a0:9c:7b (R)eject, accept (t)emporarily or accept (p)ermanently?
Denne dialogen skulle se kjent ut, det er hovedsaklig det
samme spørsmålet som du har sett i nettleseren din (som jo
bare er en annen HTTP-klient lik Subversion!).
Hvis du velger det (p)ermanente valget, vil
serversertifikatet bli lagret i ditt private
auth/-område som brukes under kjøring på
omtrent den samme måten som brukernavnet og passordet ditt
blir lagret (se “Lagring av klientlegitimasjon”).
Hvis det blir lagret, vil Subversion automatisk huske dette
sertifikatet i framtidige forhandlinger.
servers-fila som brukes under kjøring
gir deg også muligheten til å la Subversionklienten automatisk
stole på spesifikke godkjenningsinstanser, enten globalt eller på en “per server”-basis.
Sett ganske enkelt variabelen
ssl-authority-files til en
semikolonseparert liste med PEM-kodede sertifikater:
[global] ssl-authority-files = /sti/til/CAcert1.pem;/sti/til/CAcert2.pem
Mange OpenSSL-installasjoner har også et forhåndsdefinert
sett av “standardiserte” godkjenningsinstanser
som det stoles omtrent universelt på.
Får å få Subversionklienten til å automatisk stole på disse
standardautoritetene, sett variabelen
ssl-trust-default-ca til
true.
Mens den snakker med Apache, kan en Subversionklient også motta et krav om et klientsertifikat. Apache spør klienten om å identifisere seg selv: Er klienten virkelig den som den sier at den er? Hvis alt går riktig for seg, sender Subversionklienten tilbake et privat sertifikat signert av en godkjenningsinstans som Apache stoler på. Et klientsertifikat blir vanligvis lagret på disken i et kryptert format, beskyttet av et lokalt passord. Når Subversion mottar denne forespørselen, vil den spørre deg etter både en sti til sertifikatet og passordet som beskytter det:
$ svn list https://server.example.com/repos/prosjekt Authentication realm: https://server.example.com:443 Client certificate filename: /sti/til/mitt/cert.p12 Passphrase for '/sti/til/mitt/cert.p12': ******** …
Legg merke til at klientsertifikatet er en “p12”-fil. For å bruke et klientsertifikat med Subversion, må det være i PKCS#12-format som er en portabel standard. De fleste nettlesere klarer allerede å importere og eksportere sertifikater i dette formatet. En annen mulighet er å bruke kommandolinjeverktøyene i OpenSSL for å konvertere eksisterende sertifikater til PKCS#12.
servers-fila som brukes under kjøring
lar deg automatisere denne forespørselen på en
per-server-basis.
En av eller begge delene informasjon kan bli
beskrevet med kjørevariabler:
[groups] examplehost = server.example.com [examplehost] ssl-client-cert-file = /sti/til/mitt/cert.p12 ssl-client-cert-password = etellerannetpassord
Når du har satt variablene
ssl-client-cert-file og
ssl-client-cert-password, kan
Subversionklienten automatisk svare på en
klientsertifikatforespørsel uten å spørre deg.[39]
På dette punktet har du konfigurert autentisering, men ikke autorisasjon. Apache er i stand til å foreta spørring mot klienter og godkjenne identiteter, men er ikke blitt fortalt hvordan adgangen skal begrenses eller hva disse klientene som har disse identitetene skal få lov til. Denne seksjonen beskriver to strategier for å kontrollere tilgangen til depotene dine.
Den enkleste formen for adgangskontroll er å autorisere visse brukere enten for leseaksess til et depot eller lese/skrive-tilgang til et depot.
Du kan begrense tilgangen til alle depotoperasjoner ved å
legge til Require valid-user-direktivet i
<Location>-blokken.
Ved å bruke det foregående eksempelet vil dette bety at bare
klienter som påstår å være enten harry
eller sally og som oppga korrekt passord
for de respektive brukernavnene vil få tilgang til å gjøre
noe med
Subversiondepotet:
<Location /svn> DAV svn SVNParentPath /usr/local/svn # hvordan brukeren autentiseres AuthType Basic AuthName "Subversiondepot" AuthUserFile /sti/til/brukerfil # bare autentiserte brukere får tilgang til depotet Require valid-user </Location>
Noen ganger trenger du ikke å ha en like streng
adgangskontroll.
Depotet til Subversions kildekodedepot på http://svn.collab.net/repos/svn tillater alle i verden
å utføre leseoperasjoner i depotet (som å hente ut
arbeidskopier og bla gjennom depotet med en nettleser), men
begrenser alle skriveoperasjoner til autentiserte brukere.
For å få til denne typen selektiv begrensning kan du bruke
konfigurasjonsdirektivene Limit og
LimitExcept.
I likhet med Location-direktivet har disse
blokkene start- og sluttelementer, og du legger dem inn i
<Location>-blokken.
Parametrene som brukes sammen med direktivene
Limit og LimitExcept er
typer av HTTP-forespørsler som blir påvirket av den blokken.
Hvis du for eksempel vil forby all tilgang til depotet unntatt
de foreløpig støttede leseoperasjonene, vil du bruke
LimitExcept-direktivet sammen med
forespørselstypene GET,
PROPFIND, OPTIONS og
REPORT.
Deretter plasseres det tidligere nevnte direktivet
Require valid-user inne i
<LimitExcept>-blokken istedenfor bare
inne i <Location>-blokken.
<Location /svn>
DAV svn
SVNParentPath /usr/local/svn
# hvordan brukeren skal autentiseres
AuthType Basic
AuthName "Subversiondepot"
AuthUserFile /sti/til/brukerfil
# For alle andre operasjoner enn disse kreves en autentisert bruker.
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>
Dette er bare noen få enkle eksempler.
For informasjon som går mer i dybden om Apaches
adgangskontroll og Require-direktivet, ta
en kikk på Security-seksjonen i
dokmentasjonssamlingen for Apache på http://httpd.apache.org/docs-2.0/misc/tutorials.html.
Det er mulig å sette opp mer finjusterte rettigheter ved å bruke en annen Apache httpd-modul, mod_authz_svn. Denne modulen tar for seg de forskjellige “uklare” URLene som blir sendt fra klienten til serveren, spør mod_dav_svn om å dekode dem og avgjør etter dette om forespørsler skal nektes, basert på tilgangsregler som er definert i en konfigurasjonsfil.
Hvis du har bygget Subversion fra kildekode, blir
mod_authz_svn automatisk bygget og
installert sammen med mod_dav_svn.
Mange binærdistribusjoner installerer den også automatisk.
For å kontrollere at den er riktig installert, pass på at den
kommer rett etter mod_dav_svns
LoadModule-direktiv i
httpd.conf:
LoadModule dav_module modules/mod_dav.so LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so
For å aktivere denne modulen må du sette opp
Location-blokken til å bruke
AuthSVNAccessFile-direktivet, som
spesifiserer en fil som inneholder regler for rettigheter til
stier i depotene dine.
(Vil vil diskutere formatet på denne fila om et
øyeblikk.)
Apache er fleksibel, så du har muligheten til å sette opp blokken etter ett av tre generelle mønstre. For å begynne, velg ett av disse grunnleggende konfigurasjonsmønstrene. (Eksemplene nedenfor er veldig enkle; se på Apaches egen dokumentasjon for mange flere detaljer om autentiserings- og autorisasjonsvalg i Apache.)
Den enkleste blokken gir tilgang til alle. I dette scenariet sender Apache aldri autentiseringsforespørsler, så alle brukerne blir behandlet som anonyme.
Eksempel 6.1. Et eksempel på oppsett for anonym tilgang.
<Location /repos>
DAV svn
SVNParentPath /usr/local/svn
# våre regler for tilgang
AuthzSVNAccessFile /sti/til/aksessfil
</Location>
I den andre enden av paranoiaskalaen kan du sette opp
blokken din til å forlange autentisering av alle.
Alle klienter må oppgi legitimasjon for å identifisere seg.
Blokken krever betingelsesløst autentisering via
Require valid-user-direktivet og definerer
en autentiseringsmåte.
Eksempel 6.2. Eksempel på oppsett for autentisert tilgang.
<Location /repos>
DAV svn
SVNParentPath /usr/local/svn
# våre regler for tilgang
AuthzSVNAccessFile /sti/til/aksessfil
# kun autentiserte brukere får tilgang til depotet
Require valid-user
# hvordan brukeren skal autentiseres
AuthType Basic
AuthName "Subversiondepot"
AuthUserFile /sti/til/brukerfil
</Location>
Et tredje, meget populært mønster er å tillate en
kombinasjon av autentisert og anonym tilgang.
For eksempel ønsker mange administratorer å tillate alle
anonyme brukere å lese visse depotkataloger, men vil at kun
autentiserte brukere kan lese (eller skrive til) mer sensitive
områder.
Med dette oppsettet starter alle brukerne med å aksessere
depotet anonymt.
Hvis reglene for adgangskontrollen på et eller annet punkt
krever et brukernavn, vil Apache forlange autentisering av
klienten.
For å gjøre dette, bruker du både Satisfy
Any og Require
Valid-user-direktivene sammen.
Eksempel 6.3. Eksempel på oppsett for blandet autentisert/anonym tilgang.
<Location /repos>
DAV svn
SVNParentPath /usr/local/svn
# våre regler for tilgang
AuthzSVNAccessFile /sti/til/aksessfil
# prøv først anononym tilgang og fall tilbake på skikkelig
# autentisering hvis det er nødvendig.
Satisfy Any
Require valid-user
# hvordan brukeren skal autentiseres
AuthType Basic
AuthName "Subversiondepot"
AuthUserFile /sti/til/brukerfil
</Location>
Once you've settled on one of these three
basic httpd.conf templates, you need to
create your file containing access rules for particular
paths within the repository. This is described in
“Path-Based Authorization”.
mod_dav_svn-modulen går gjennom en masse arbeid for å forsikre seg om at dataene som du har markert som “uleselig” ikke blir lekket ved en ulykke. Dette betyr at den må passe nøye på alle stiene og filinnhold som blir returnert av kommandoer som svn checkout eller svn update. Hvis disse kommandoene kommer over en sti som ikke er lesbar i følge en eller annen autorisasjonsregel, blir stien vanligvis totalt utelatt. Når det gjelder tråling av historien og navneskifter – for eksempel å kjøre en kommando som svn cat -r GAMMELREV foo.c på en fil som skiftet navn for lenge siden – vil trålingen av navneskiftet ganske enkelt stoppe hvis et av objektets tidligere navn blir anslått til å være beskyttet mot lesing.
Alle disse kontrollene av stier kan noen ganger være
ganske dyrekjøpte, spesielt i tilfellet med svn
log.
Når det hentes en liste med revisjoner, ser serveren på
alle stier som har forandret seg i hver revisjon og sjekker om
stien er leselig.
Hvis en uleselig sti blir funnet, utelates den fra listen med
forandrede stier i revisjonen (som man vanligvis ser med
--verbose-valget), og hele loggmeldingen blir
utelatt.
Dette kan føre til at mye tid blir brukt på revisjoner som
påvirker et stort antall filer.
Dette er prisen for sikkerhet:
Selv om du ikke har satt opp en modul som
mod_authz_svn i det hele tatt, ber
mod_dav_svn-modulen fortsatt Apache
httpd om å kjøre autorisasjonssjekker på
hver eneste sti.
mod_dav_svn-modulen har ingen formening om
hvilke autorisasjonsmoduler som er installert, så alt den kan
gjøre er å be Apache om å utføre alle som kan
eksistere.
På den annen side finnes det en slags nødløsning for dette, en som lar deg bytte
sikkerhetsfunksjonalitet mot hastighet.
Hvis du ikke gjennomfører noen form for katalogbasert
autorisasjon (det vil si at mod_authz_svn
eller en lignende modul ikke brukes) kan du slå av alt av
stikontroller.
Bruk SVNPathAuthz-direktivet i
httpd.conf-fila:
Eksempel 6.4. Slå av alle filstikontroller
<Location /repos>
DAV svn
SVNParentPath /usr/local/svn
SVNPathAuthz off
</Location>
SVNPathAuthz-direktivet er
“on” (aktivt) som standard.
Når det settes til “off”, slås all stibasert
autorisasjonskontroll av; mod_dav_svn lar
være å utføre autorisasjonssjekker på hver sti som den
finner.
Vi har dekket mesteparten av autentiserings- og autorisasjonsvalg for Apache og mod_dav_svn. Men det er noen andre fine ting som Apache tilbyr.
En av de nyttigste fordelene med å bruke et
Apache/WebDAV-oppsett for Subversiondepotet ditt er at de
yngste revisjonene av de versjonerte filene og katalogene er
øyeblikkelig tilgjengelig for visning gjennom en vanlig
nettleser.
Siden Subversion bruker URLer til å identifisere versjonerte
ressurser, kan disse URLene for HTTP-basert depottilgang bli
skrevet direkte inn i en nettleser.
Nettleseren vil foreta en HTTP
GET-forespørsel for denne URLen, og
avhengig om denne URLen representerer en versjonert katalog
eller fil vil mod_dav_svn svare med en katalogutlisting eller
innholdet av en fil.
Siden URLene ikke inneholder noen informasjon om hvilken versjon av ressursen du ønsker å se, vil mod_dav_svn alltid svare med den yngste versjonen. Denne funksjonaliteten har den ytterst stilfulle bieffekten at du kan sende Subversion-URLer til mottakere som referanser til dokumenter, og disse URLene vil alltid peke til den nyeste versjonen av dette dokumentet. Du kan selvfølgelig også til og med bruke URLene som hyperlinker fra andre hjemmesider.
When browsing a Subversion repository, the web browser
gets a clue about how to render a file's contents by
looking at the Content-Type: header
returned in Apache's response to the
HTTP GET request. The value of this
header is some sort of MIME type. By default, Apache will
tell the web browsers that all repository files are of
the “default” MIME type,
typically text/plain. This can be
frustrating, however, if a user wishes repository files to
render as something more meaningful — for example,
it might be nice to have a foo.html file
in the repository actually render as HTML when
browsing.
To make this happen, you only need to make sure that
your files have the
proper svn:mime-type set. This is
discussed in more detail in
“File Content Type”,
and you can even configure your client to automatically
attach proper svn:mime-type properties
to files entering the repository for the first time; see
“Automatic Property Setting”.
So in our example, if one were to set
the svn:mime-type property
to text/html on
file foo.html, then Apache would
properly tell your web browser to render the file as
HTML. One could also attach
proper image/* mime-type properties to
images, and by doing this, ultimately get an entire web
site to be viewable directly from a repository! There's
generalyl no problem with doing this, as long as the
website doesn't contain any dynamically-generated
content.
Vanligvis vil du få mer ut av URLer til versjonerte
filer – det er jo der alt det interessante innholdet har for
vane å ligge.
Men noen ganger må du bla direkte gjennom en katalogliste i
Subversion, og da legger du merke til at den genererte
HTML-en som brukes i utlistingen er ganske enkel, og i
hvertfall ikke ment å være en nytelse for øyet.
For å gjøre det mulig å tilpasse disse katalogvisningene,
har Subversion en XML-basert innholdsfunksjonalitet.
Et enkelt SVNIndexXSLT-direktiv i
depotets Location-blokk i
httpd.conf vil instruere mod_dav_svn
til å generere XML-data når den viser en katalogutlisting og
referere til XSLT-stilsettet som du har valgt:
<Location /svn> DAV svn SVNParentPath /usr/local/svn SVNIndexXSLT "/svnindex.xsl" … </Location>
Ved å bruke SVNIndexXSLT-direktivet og
et kreativt XSLT-stilsett, kan du få katalogutlistingene til
å følge fargevalgene og utseendet til andre deler av
hjemmesiden din.
Eller du kan bruke eksempelstilsettene som ligger i
Subversionkildekodens
tools/xslt-katalog.
Husk på at stien som gis til
SVNIndexXSLT-direktivet egentlig er en URL
— nettlesere må være i stand til å lese stilsettene dine for
å kunne bruke dem!
If you're serving a colllection of repositories from a
single URL via the SVNParentPath
directive, then it's also possible to have Apache display
all available repositories to a web browser. Just
activate the SVNListParentPath
directive:
<Location /svn> DAV svn SVNParentPath /usr/local/svn SVNListParentPath on … </Location>
If a user now points her web browser to the
URL http://host.example.com/svn/, she'll
see list of all Subversion repositories sitting
in /usr/local/svn. Obviously, this can
be a security problem, so this feature is turned off by
default.
Because Apache is an HTTP server at heart, it contains
fantastically flexible logging feature. It's beyond the
scope of this book to discuss all ways logging can be
configured, but we should point out that even the most
generic httpd.conf file will cause
Apache to produce two logs:
error_log
and access_log. These logs may appear
in different places, but are typically created in the
logging area of your Apache installation. (On Unix, they
often live
in /usr/local/apache2/logs/.)
The error_log describes any interal
errors that Apache runs into as it works.
The access_log file records every
incoming HTTP request received by Apache. This makes it
easy to see, for example, which IP addresses Subversion
clients are coming from, how often particular clients use
the server, which users are authenticating properly, and
which requests succeed or fail.
Unfortunately, because HTTP is a stateless protocol,
even the simplest Subversion client operation generates
multiple network requests. It's very difficult to look at
the access_log and deduce what the
client was doing — most operations look like a series
of cryptic PROPPATCH, GET,
PUT, and REPORT
requests. To make things worse, many client operations send
nearly-identical series of requests, so it's even harder to
tell them apart.
mod_dav_svn, however, can come to
your aid. By activating an “operational
logging” feature, you can
ask mod_dav_svn to create a separate log
file describing what sort of high-level operations your
clients are performing.
To do this, you need to make use of
Apache's CustomLog directive (which is
explained in more detail in Apache's own documentation).
Be sure to invoke this
directive outside of your
Subversion Location block:
<Location /svn>
DAV svn
…
</Location>
CustomLog logs/svn_logfile "%t %u %{SVN-ACTION}e" env=SVN-ACTION
In this example, we're asking Apache to create a special
logfile svn_logfile in the standard
Apache logs directory.
The %t and %u
variables are replaced by the time and username of the
request, respectively. The really important part are the
two instances of SVN-ACTION.
When Apache sees that variable, it substitutes the value of
the SVN-ACTION environment variable,
which is automatically set by mod_dav_svn
whenever it detects a high-level client action.
So instead of having to interpret a
traditional access_log like
this:
[26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc/!svn/vcc/default HTTP/1.1" 207 398 [26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc/!svn/bln/59 HTTP/1.1" 207 449 [26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc HTTP/1.1" 207 647 [26/Jan/2007:22:25:29 -0600] "REPORT /svn/calc/!svn/vcc/default HTTP/1.1" 200 607 [26/Jan/2007:22:25:31 -0600] "OPTIONS /svn/calc HTTP/1.1" 200 188 [26/Jan/2007:22:25:31 -0600] "MKACTIVITY /svn/calc/!svn/act/e6035ef7-5df0-4ac0-b811-4be7c823f998 HTTP/1.1" 201 227 …
… you can instead peruse a much more
intelligible svn_logfile like this:
[26/Jan/2007:22:24:20 -0600] - list-dir '/' [26/Jan/2007:22:24:27 -0600] - update '/' [26/Jan/2007:22:25:29 -0600] - remote-status '/' [26/Jan/2007:22:25:31 -0600] sally commit r60
Mye av funksjonaliteten som Apache tilbyr i sin rolle som
en robust webserver kan i tillegg bli satt opp for økt funksjonalitet eller sikkerhet
i Subversion.
Subversion kommuniserer med Apache ved bruk av Neon, som er et
generelt HTTP/WebDAV-bibliotek med støtte for mekanismer som
SSL (Secure Socket Layer, som
tidligere diskutert).
Hvis Subversionklienten din er bygget med støtte for SSL, kan
den aksessere Apacheservere via
https://.
Like nyttige funksjonaliteter i forholdet mellom Apache og Subversion er muligheten til å spesifisere en spesiell port (istedenfor den vanlige HTTP-porten 80) eller virtuelle domenenavn som Subversiondepoter skal aksesseres via, eller muligheten til å aksessere depotet gjennom en HTTP-mellomserver. Alle disse tingene støttes av Neon, så denne støtten får Subversion helt gratis.
Til sist, fordi mod_dav_svn forstår et utvalg av WebDAV/DeltaV-protokollen, er det mulig å aksessere depotet vie tredjeparts DAV-klienter. De fleste moderne operativsystemer (Win32, OS X og Linux) har muligheten til å montere en DAV-server som en standard delt ressurs på nettverket. Dette er et komplisert tema; for detaljer, les Tillegg C, WebDAV and Autoversioning.
[37] Det er noe som de virkelig hater.
[38] Selv om selvsignerte serversertifikater også er sårbare for “mann-i-midten”-angrep, vil et slikt angrep for en vanlig observatør være mye vanskeligere å få til, sammenlignet med å sniffe ubeskyttede passord
[39] Mer sikkerhetsbevisste folk vil kanskje ikke lagre
klientsertifikatpassordet i kjørefila
servers.
[40] På den tiden ble den kalt “ViewCVS”.