ubuntuusers.de

Hallo zusammen,

Ich war in meinem anderen Thread etwas vorschnell. Daher muss ich die Problemstellung nochmal posten und aktualisieren:

Nachdem ich auf meiner neuen Platte Ubuntu ans Laufen bekommen habe, SSH, Apache2(+SSL), MYSQL, PHP und phpmyadmin nun auch läuft, hab ich mich ans svn gemacht. Ich richtete mich nach dem Wiki-Eintrag: http://wiki.ubuntuusers.de/Subversion?highlight=svn .

Das Problem ist, dass ich nun immer noch nicht via Tortoise (Vista) darauf zugreifen kann, sondern nur via Browser. Aber auch das scheint nicht fehlerfrei zu funktionieren.

Firefox 3.0.8 (Vista) sagt mir nachdem ich auf der Seite "Collection of Repositories" ein Repository angewählt habe:

Mit dieser XML-Datei sind anscheinend keine Style-Informationen verknüpft. Nachfolgend wird die Baum-Ansicht des Dokuments angezeigt.
<D:error>
<C:error/>
<m:human-readable errcode="2">
Could not open the requested SVN filesystem
</m:human-readable>
</D:error>

Tortoise gibt mir wieder den Fehler:

Repository moved permanently to 'https://192.168.0.10/svn/'; please relocate

Ich habe schon Lösungsansätze verfolgt. Die helfen allerdings nicht. Das Repository liegt bei /var/svn. Also nicht innerhalb des DocRoots von Apache2.

Aber, es klappt via http:// und https://. Über svn:// leider nicht. Vielleicht ist das das Problem? Wo ist da der genaue Unterschied in den Protokollen?

Desweiteren hat mein DocRoot von Apache2 (/var/www/), Zugriff für root/root. Ich hatte jetzt mehrfach gelesen, dass der Nutzer www-data und die gleichnamige Gruppe wichtig sind. Allerdings gibt es weder den Nutzer, noch die Gruppe auf meinem System. Verstehe ich das vielleicht falsch und www-data existiert nur, wenn ich mod_userdir benutze? Also die Möglichkeit des nutzerspezifischen public_html-Verzeichnisses? Das möchte ich nicht. Ich brauche nur ein zentrales htdocs bzw. www.

Ach ja, wichtig ist sicher, dass ich das Apache2-Modul webDAV nutze.

Wäre es möglich, falls jemand sich die Zeit nehmen kann und die Mühe machen möchte, mich persönlich zu betreuen bei der Einrichtung meines LAN-WebDevelopment-Servers? Gerne über Skype oder ICQ (bitte per PN anfragen). Würde mich sehr darüber freuen, da ich seit 3 Tagen dran sitze und verbale Hilfe sicherlich hilfreicher ist. Ich poste natürlich trotzdem die Lösungen meiner Probleme. ☺

Vielen Dank für alle Hilfestellungen, SissK

Welche Informationen wären noch sinnvoll für eine Hilfestellung? Habe ich was vergessen?

Kann mir vielleicht jemand bestimmte Tutorials empfehlen? Dann remove ich alles und installiere nochmal.

Irgendwie muss ich das doch hinkriegen...

1. Ziel: Ubuntu mit Apache2 und SVN samt WebDAV 2. Ziel: Von Vista-PC via LAN(wahlweise WAN mittels DynDNS, wenn ich mal unterwegs bin) auf SVN zugreifen. 3. Ziel: Post-Commit-Hook machen, der nach nem Commit den Repos-Inhalt nach /var/www packt.

Ich habs jetzt 5 mal probiert, immer nach anderen Tutorials. Tortoise kann nichts auslesen, weil ich ständig (egal wo man repos im verzeichnisbaum liegt) den Fehler 301 bekomme.

Okay, hier meine config (jeweils exklusive der #-Zeilen):

web_dav.conf

<Location /svn>
  DAV svn
  SVNParentPath /var/svn
  SVNListParentPath on
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd
  Require valid-user
  SVNAutoversioning on
</Location>

Die Datei dav_svn.passwd existiert. Die Nutzerauthentifizierung funktioniert. Er fängt falsche Benutzeranmeldungen ab und lässt nur die richtige zu.

Owner/Group vom Verzeichnis /var/svn ist www-data. Das Verzeichnis hat die Rechte 775. Die Repos ab /var/svn (/var/svn/repos1, /var/svn/repos2, ...) haben die Rechte 755.

Gemäß: http://www.debuntu.org/2006/05/20/54-how-to-subversion-svn-with-apache2-and-dav

Allerdings kann ich weder über die Vista-WebDAV-Schnittstelle noch über Tortoise verbinden.

Was trägst du denn jeweils als Repository-URL ein?

Wenn ich via Tortoise oder Vista auf den SVN will?

http://<DNSName>/svn/ oder https://<DNSName>/svn/

funktioniert beides.

SissK schrieb:

Wenn ich via Tortoise oder Vista auf den SVN will?

http://<DNSName>/svn/ oder https://<DNSName>/svn/

funktioniert beides.

Okay, und was genau funktioniert dann nicht?

Tortoise gibt mir wieder den Fehler:

Repository moved permanently to 'https://192.168.0.10/svn/'; please relocate

Vista findet überhaupt nichts und sagt, dass der eingebene Ordner ungültig sei.

Würde sich jemand zutrauen sich bei mir via SSH anzumelden und sich das mal anzuschauen? Ich find den Fehler immer noch nicht.

Vielen Dank für die Hilfe,

ich habe einen workaround probiert und der hat funktioniert.

Einfach die beiden Einträge SVNParentPath und SVNListParentPath auskommentieren und das repos über SVNPath ansprechen.

Ich muss jetzt halt jedes Repository einzelnd ansprechen / verwalten. Scheinbar bin ich zu blöd für die SVNParentPath-Funktion.

Du bekommst da eigentlich gar keinen Fehler, sondern einen Hinweis, der vom SVN Client auch etwas blöd formuliert ist.

Dein Repo (die Repos) hatten in deiner alten config (mit SVNParentPath) offensichtlich mehrere Zugriffs URLs. Weiter scheint aber deine config nicht einfach jede zugriffs url so zu behandeln, als dass der server die angeforderten ressourcen ausliefert, sondern zunächst beisp. über url rewriting den client anweist eine andere url aufzurufen (nämlich eine der anderen gültigen zugriffs URLs und diese dann einfach mit den gleichen Parametern des Ursprungs Requests)

Beispiel:

SVN Projekt: "weltherrschaft" SVN Server: http://svn.zentrumdermacht.de/

SVN Projekt URL: http://svn.zentrumdermacht.de/weltherrschaft

// habe einen eigenen vhost und daher die Location für svndav auf "/" statt auf dem gängigen "/svn" stehen

Innerhalb meines lokalen Netzes kann ich dank eigener Namensauflösung den Server (genauer den SVN Vhost auf dem Server) zusätzlich auch über "http://svn/" erreichen.

Wenn man aber dann lokal das Projekt über http//svn/weltherrschaft auscheckt könnte man wenn man mal unterwegs ist keine updates/commits machen, da er die dann auch an/von diese(r) Url schicken/laden will.

Ergo machen wir im VHOST eine Weiterleitung für http://svn/<AufgerufenerPfad> nach http://svn.zentrumdermacht.de/<AufgerufenerPfad>

Ziel wäre nun, dass wir beim Aufruf erst weitergeleitet werden und der Client das Projekt dann von der URL auscheckt die auch erreichbar ist wenn ich unterwegs bin....

Aber Pustekuchen!!

Der SVN Client erzählt mir dass er weitergeleitet wurde an einen URL "http://svn.zentrumdermacht.de/weltherrschaft" und dass das Projekt wohl nun da liegen soll und ich doch bitte diese URL beim Checkout abgeben soll. Tue ich das, funktioniert es dann auch.

Wenn man aber statt einem Checkout mit dem SVN Client einfach mit dem Browser auf "http://svn/weltherrschaft" geht, landet man anschließend auch ordnungsgemäß auf dem Inhalt des Repositories und in der NavLeiste steht nun "http://svn.zentrumdermacht.de/weltherrschaft"

FAZIT: DU HATTEST NICHT DIREKT EINEN FEHLER

stelle Deine Config ruhig wieder auf SVNParentPath und schaue, dass Dein Server keine Redirects macht (Allenfalls Url Rewrites ohne Weiterleitung wenn unbedingt notwendig)

ODER

befolge einfach den Hinweis, den dein svn client die ausgibt und setze dein svn command an diese URL ab, von der der client behauptet, dass das projekt nun permanent oder zeitweilig dort liegen würde.

(es wäre natürlich geil, wenn der client das einfach selbst machen würde, genau wie alle halbwegs neuen der beschissensten browser (wie IE) in der Lage sind Weiterleitungen zu folgen.... von mir aus auch in einem client setting was erst aktiviert werden müßte oder so)

Ich vergaß:

Deine Repository Verzeichnisse müssen im Dateisystem für den User lesbar und schreibbar sein, der den Webserver Prozess ausführt.

Unter Ubuntu startet zwar der Apache als root, jedoch ist dies nur der Hauptprozess, der keine Requests verarbeitet sondern nur entsprechend konfigurierte/benötigte Chikld Prozesse als User "www-data" startet, welche dann die Requests annhemen und verarbeiten.

Wenn Du tatsächlich keinen www-data haben solltest, könnte er bei dir vieleicht apache (ist beisp. der Standard bei Gentoo Linux) oder http oder so heißen.

Du kannst das nochmal prüfen mit:

grep "www-data" /etc/passwd -Hn --color grep "www-data" /etc/group -Hn --color

grep "apache" /etc/passwd -Hn --color grep "apache" /etc/group -Hn --color

gruß, heysa

da heut sonntag ist und alle guten dinge zu dritt unterwegs sind:

du hast svn repositories die im Dateisystem liegen und erstmal nur auf der Console völlig OHNE irgend einen laufenden DIENST erreichbar sind mit

file:///var/svn/<Dein_Projekt_1> oder file:///var/svn/<Dein_Projekt_2>

nun konfigurierst Du SvnDAV und ermöglichst dem permanent laufenden DIENST Apache Zugriff auf die Repositories. Daher ist dieser DIENST (apache) nun in der Lage die Repositories (so wie er es mit Webseiten ja auch macht) im Netzwerk anzubieten. D.h. ein Netzwerkclient (Browser/SVN Client) kann nun über das Protokoll, welches der Apache spricht, nämlich http(s), an die IP und den Port auf welchem der Apache lauscht (<deinserver>:80) Anfragen stellen. (Vorteil dieser Variante: Zugriff auch von anderen Rechnern, wobei eine etwaige Authentifizierung vom Apache übernommen werden kann. Zwar nicht sehr feingranular, allerdings dafür völlig ohne zusätzliche ACL Mechanismen seitens SVN, wechlche man aber wenn benötigt zusätzlich mit nutzbar machen könnte)

eine alternative Möglichkeit bietet der SVNserve DIENST. Mit diesem habe ich auch nicht viel Erfahrung, aber ich weiß, dass es einen gibt und man diesen starten kann. SVNserve ist nun ein DIENST, welcher selbst einen Port auf dem Server öffnet und auf diesem nach eingehenden Requests lauscht. Welchen Port er dafür wählt weiß ich nicht genau, aber das Protokoll, welches bei den Verbindungen dann gesprochen wird ist "svn" ☺ Daher die URLs mit svn:// In dieser Variante werden Authentifizierung und Autorisierung natürlich vom SVNserve DIENST übernommen. Wie er dann was genau macht bzw. erwartet weiß ich allerdings nicht.

Ich persönlich bin mit der SvnDAV Variante mehr als zufrieden und freue mich, dass die Anbindung an mein LDAP so einfach war ☺

HINWEIS:

man kann auf dem Server wie oben beschrieben die Projekte auch direkt innerhalb des Dateisystems ohne Umweg über Netzwerkdienste auschecken... Sollen diese Checkouts aber auch (weil über Feigaben von anderen Rechnern aus erreichbar) von anderen Rechnern und dann wieder über Netzwerkdienst bedienbar sein, funktioniert es nicht, weil der RepoPfad der Arbeitskopie ein file:// Url ist und dieser dann auf dem anderen Rechner interetiert wird und es diesen dort nicht gibt.

Lösung:

In solchen Fällen auch wenn mit file:// einfacher/schneller trotzalem den Netzwerkpfad http://svn.server/ nutzen..

gruß, daywalker 😉