[linux-l] Subversion und Authentifizierung durch Apache (was: Neuorganisation der Berlinux-Seiten)

[Volker Grabsch]

On Mon, Nov 21, 2005 at 03:23:27PM +0100, Mike Dornberger wrote:
> Manchmal habe ich den Eindruck, alle User sollen ausschließlich per Wiki auf
> das Repository zugreifen. Dann scheint es mal wieder so, als sollte alles
> über mod_dav_svn laufen. Dann, daß die User noch andere
> Zugriffsmöglichkeiten auf das Repository haben sollen, z. B.: ssh+svn:// Zum
> Schluß schreibst Du etwas, daß das Repository auf einem ganz anderen Rechner
> liegen soll.

Ich wollte die Möglichkeiten gegeneinander abwägen, aber das ist wohl zu
chaotisch geworden.

> Wenn auf das Repository über mod_dav_svn zugegriffen werden soll, muß daß
> Repository auf dem gleichen Rechner liegen, da dann Apache nämlich volle
> Schreib-/Leserechte auf z. B. die Berkeley-DB benötigt.

Nein, der Subversion-Server kann auch seinen eigenen Apache haben.

> Vielleicht sollten wir erst einmal klären, wer wann wo warum worauf zugreift
> und hier nicht so allgemein über irgendwelche Zugriffsmöglichkeiten auf
> irgendein svn-Repository reden.

ACK.

> Von dem, was ich auf
> http://svn.webdav.org/repos/projects/subwiki/trunk/INSTALL.html gelesen
> habe, bekomme ich den Eindruck, daß das SubWiki-Repository lokal auf dem
> Rechner liegen muß und daß das CGI nicht durch den svn Command-Line-Client,
> sondern über die Subversion-Libraries (s. auch Kap. 8 svnbook) auf das
> Repository zugreift.

Dass es die Library und nicht die Kommandozeile nutzt, ist doch okay.
Aber dennoch müssten Remote-Zugriffe möglich sein. Daher finde ich
es irrelevant, ob via Kommanzoteilentool oder SVN-Library auf das
Repository zugegriffen wird. Beide können gleich viel.

> Und an dieser Stelle reicht es wirklich schon, sich per
> Apache zu authentifizieren. Wenn man dann überhaupt das "Schreib-CGI"
> ausführen darf, besteht überhaupt kein Grund mehr, daß Paßwort ein weiteres
> Mal zu benutzen. O. g. URL sagt _mir_, man kann zusätzlich das Repository z.
> B. per mod_dav_svn zugänglich machen, aber das ist eine ganz andere
> Baustelle und hat in dem Sinne jetzt schon gar nichts mehr mit SubWiki zu
> tun.

Nein, das hat es sehr wohl.

Wenn man nämlich das Subversion-Repos. nämlich ohnehin nach außen
zugänglich macht (egal, ob via svn+ssh oder via Apache2+mod_dav_svn),
dann sollte das Wiki eben diesen Zugang *ebenfalls* benutzen, und
nicht direkt darauf arbeiten.

> _Jetzt_ kommt man dann vielleicht an einen Punkt, wo verschiedene
> User/Paßwort-Dateien nicht mehr zueinander passen.

Ja, genau! Und noch ein paar andere Probleme.

> Aber mal um auf das ursprünglich(er)e Thema zurückzukommen: Will man denn
> wirklich ein Wiki für die Berlinux-Seiten? Sind andere Methoden nicht doch
> besser geeignet? Vielleicht ist es Zeit für eine Umfrage...

Erstmal sind Ideen nötig, oder?
Ich meine, bisher sehen die Alternativen noch immer sehr spärlich aus:

* direktes Arbeiten an den HTML-Dateien, via Versionskontrolle
* Typo3
* Dokumentieren in einer Wiki-Sprache, via Versionskontrolle,
  eventuell mit Webinterface (klassisches Wiki)


Also erkläre ich nochmal meinen Vorschlag:

Die Seiten werden in einer einfachen Sprache geschrieben sein, z.B.
einer beliebigen Wiki-Sprache, meine Empfehlung wäre reST. Aber es
gibt genug andere Möglichkeiten.

Diese Seiten, zusammen mit Vortragsfolien, Stylesheets, etc. liegen
in einer Versionskontrolle, am besten Subversion. Jeder, der
mitarbeitet, bekommt einen Account in dem Repository. Er kann die
Seiten auschecken, bei sich lokal bearbeiten, und committen. Wie
bei freier Software auch. Zum Schreiben in das Repository braucht
man einen Acount, auslesen hingegen kann jeder. Das Repository
wird z.B. via Apache2+mod_dav_svn öffentlich verfügbar gemacht.
(eventuell geht auch ssh+svn, ist aber schwieriger)

Diese Seiten werden automatisch in Webseiten umgewandelt. Das kann
on-the-fly passieren (ähnlich Subwiki), oder statisch (jede
Minute per Cronjob bzw. nach jedem Commit). Egal, was von beiden
der Fall ist: Der HTML-Generator holt sich über die Subversion-URL
die aktuelle Version der jeweiligen Seite und konvertiert sie.
Er greift nicht lokal auf das Repository zu.

Für diejenigen, die mit Subversion nicht umgehen können / wollen,
gibt es noch ein Wiki-Interface, d.h. jede Seite hat einen bearbeiten-
Button, hinter dem das CGI-Script steht, das letztlich ein einfacher
SVN-Client ist. Es nutzt die Authentifikation des Web-Benutzers, um
sich gegenüber Subversion zu authentifizieren. Es hat keinen speziellen
Account und greift nicht direkt (per Dateisystem) auf das Repository zu.
Auch das Hochladen von z.B. Vortragsfolien könnte über so ein Script
geregelt werden. Es ist also weniger ein Wiki, sonder eher ein
vereinfachter Web-Subversion-Client.


Nachdem mein Vorschlag nun hoffentlich klar geworden ist, noch ein
paar Details:

Würde das Subversion-Repository nur intern genutzt werden, d.h.
wenn es für alle Leute *nur* Web-Zugriff und keinen Subversion-
Zugriff gäbe, dann sähe das sicher anders aus. Dann würde ich
dir zustimmen, dass die Authentifikation via HTTP-Auth geschehen
sollte und dass das Wiki sich sein eigenes SVN-Repository hält,
auch das es lokal zugreift. (ob via Kommandozeilentools oder
SVN-Lib, ist dabei irrelevant)

Falls die Seiten dynamisch erzeugt werden, würde sich der HTML-
Generator die aktuelle Version der Quell-Wiki-Seiten direkt
aus Subversion holen, z.B. via SVN-Lib, SVN-Kommandozeilentools,
oder sogar via HTTP. Wenn das Repository per Apache2+mov_dav_svn
veröffentlich wird, braucht die dynamische Seitengenerierung
also noch nicht einmal etwas über Subversion zu wissen.

Falls die Seiten statisch erzeugt werden, wäre es wohl sinnvoll,
wenn es auf dem Server eine Arbeitskopie gäbe. Zum Zeitpunkt X
(d.h. per Cronjob bzw. nach jedem Commit) gibt es dort ein
"svn update && make", wobei das Makefile nur diejenigen Seiten
aktualisiert, die nötig sind. Wenn "svn update" also keine neuen
Seiten findet, wird "make" sie auch nicht aktualisieren.
Kurz: Statische Seitenerzeugung kann sehr effizient ablaufen.

Falls Subversion und Webserver auf einem Rechner liegen, und
Subversion via Apache2+mod_dav_svn zugänglich gemacht wurde,
gibt es noch eine Möglichkeit (die du vielleicht meintest):
Subversion besitzt ohnehin eine htpasswd-Datei, diese Datei
könnte gleich mit benutzt werden, um auch das Wiki-Edit-CGI-Script
zu schützen. Das hätte aber zur Folge, dass das CGI-Script direkten
Subversion-Repository-Zugriff braucht. Diese Zugriff kann lokal
geschehen, dann müsste das CGI-Script aber unter den Rechten des
Webservers laufen. Oder er geschieht über Apache2+mod_svn_dav,
dann braucht das CGI-Script einen extra Schreib-Account.
Der Vorteil gegenüber meiner Variante wäre, dass das CGI-Script
sich nicht um die Authentifikations-Daten kümmern braucht.
Der Nachteil wäre, dass es ein Loch gibt, über das jedes weitere
CGI-Script ebenfalls uneingeschränkten SVN-Zugriff hätte.

Wenn man außerdem das Respository für andere Zwecke noch verwendet
(entsprechend mehr Accounts dort hätte), oder feinere Zugriffs-
Kontrollen braucht (dass z.B. jemand was ins Wiki schreiben darf,
aber keine Dateien hochladen darf), dann gäbe es ein riesen Problem.
Dann müsste sich das CGI-Script um Autorisierung kümmern, und
spätestens dann wäre dein Weg nicht mehr gangbar.


Grundsätzlich ist aber beides machbar. Bei meiner Lösung dachte
ich vorallem daran, OpenSource-Projekte auf diese Weise zu
managen, wo im Repository sowohl der Quellcode als auch die
Dokumentation liegt, und man an der Dokumentation im Wiki-Stil
mehr Leute ranlässt als an den Quellcode. Daher ist meine Idee
ohnehin etwas allgemeiner: einfaches Projektmanagement ohne
zuviel Overhead mit möglichst einfachen, kleinen Komponenten
und sehr viel Wiederverwendung.


So, jetzt haben wir hoffentlich eine konkrete Diskussionsgrundlage.
Auf eure Meinungen / Einwände bin ich sehr gespannt.


Viele Grüße,

	Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR