Einrichten von Subversion auf einem vServer mit Plesk

[ONeinONeill]

Hi Leute,

hab mir nen kleinen vServer zugelegt und versuche nun dort Subversion zugänglich zu machen. Habe also alle grundlegenden Einstellungen vorgenommen:

Apache Module installiert, Benutzer/Gruppen angeelegt, Repos Verzeichnis angelegt, Zugriffsrechte bestimmt, Repos erzeugt, Zugangsbenutzer angelegt.

Dann habe ich in Pleks nun eine Subdomain angelegt: svn.<server>.de und möchte nun dass ich über diese subdomain auf das Subversion Repos zugreifen kann.

Dafür habe ich nun versucht die vhost Datei im conf Ordner der Subdomain mit korrekten Werten zu füllen, aber ich krieg den redirect mit Zugriffsbeschränkung einfahc nicht hin. Auch die Informationen über google bringen keinen Erfolg. Hat das vieleicht jemand schonmal gemacht und könnte mir da weiterhelfen und sagen wie das auszuesehen hat?

Danke schonmal

[Chromanoid]

Also so klappt[e] das bei mir (SVN über Apache) ([e] weil das schon ne weile her ist, dass ich das benutzt habe :) und ich nicht genau weiss ob das immer noch so geht...)
Bei Port einfach deinen gewünschten reinhauen und bei Servername dann die subdomain... Das müsste dann eigentlich gehen.
Natürlich dann noch die Verzeichnisse anpassen. Achtung ich glaube "\" bzw. "/" werden bei AuthzSVNAccessFile und AuthUserFile je nach System benötigt.
(Listen natürlich nur wenns nicht 80 sein soll)... ;)

Code: Alles auswählen

Listen 90
<VirtualHost *:90>
    ServerName localhost:90 
    DocumentRoot "D:\Programme\Apache Group\Apache2\htdocs"
<Location />
DAV svn
SVNParentPath "D:/SVN"
SVNReposName Repositories
AuthzSVNAccessFile "D:\SVN\access"
AuthType Basic
AuthName "Repositories"
AuthUserFile "D:\SVN\pwd"
Require valid-user
</Location>
</VirtualHost>

oben

Code: Alles auswählen

LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so

nicht vergessen... ;)

[ONeinONeill]

Danke schonmal. Also die Module werden eh geladen.

Wenn ich deine angepassten Daten anwende, kommt:

Syntax error on line 1 of /srv/www/vhosts/vs250010.vserver.de/subdomains/svn/conf/vhost.conf:
<VirtualHost> cannot occur within <VirtualHost> section

Was eventuell damit zusammenhängt, dass es ja eine subdomain ist, kenn mich da nicht so gut aus mit dem Apache.
Dann habe ich folgende vhost versucht:

<Location />
DAV svn
SVNParentPath /srv/svn/repos
SVNReposName Repositories
AuthzSVNAccessFile /srv/svn/auth/htpasswd
AuthType Basic
AuthName "Repositories"
AuthUserFile /srv/svn/auth/htpasswd
Require valid-user
</Location>

Aber über meine gewünschte subdomain Adresse kriege ich einen 500 Internal Server Error.

[Chromanoid]

mmh probiers mal einfach ohne <VirtualHost> und statt Location mit Directory

Code: Alles auswählen

<Directory "/srv/svn/repos"> 
DAV svn
SVNParentPath "D:/SVN"
SVNReposName Repositories
AuthzSVNAccessFile "D:\SVN\access"
AuthType Basic
AuthName "Repositories"
AuthUserFile "D:\SVN\pwd"
Require valid-user
</Directory>

Evt. oben noch ServerName localhost:90 reinpacken...
mmh ich glaub mit Directory gehts net :)
Klappts denn mit normalem HTTP Verkehr?
Wie sah die Datei eigentlich aus als Plesk sie generiert hat?

Eigentlich müsste das mit Location wie oben beschrieben gehen... (ohne VirtualHost drum herum)
Hast du auch die conf Datei von Plesk neu einlesen lassen? ->

Code: Alles auswählen

/usr/local/psa/admin/sbin/websrvmng --reconfigure-vhost --vhost-name=example.com

[ONeinONeill]

Hey,

also ich habe jedesmal die host Datei neu einlesen lassen und den Apache neugestartet. Ich bin auch generell über den HTTP Port gegangen. Plesk ansich hat dort keine vhost.conf erstellt. Die musste ich neu erstellen.

Also mir ist aufgefallen, dass ich die falsche auth Datei angegeben habe. Ich habe nun folgende Datei:

<Location />
DAV svn
SVNParentPath /srv/svn/repos
SVNReposName Repositories
#AuthzSVNAccessFile /srv/svn/auth/svn.htpasswd
AuthType Basic
AuthName "Repositories"
AuthUserFile /srv/svn/auth/svn.htpasswd
Require valid-user
</Location>

Diese klappt nun. Ich hatte mich etwas in der Struktur verirrt. Oh man. Soweit war ich das ganze Wochenende auch, aber hab den Fehler in der vhost Datei gesucht :((

Naja, danke für deine Hilfe! :)

[Chromanoid]

Die AuthzSVNAccessFile ist für die Repository-Berechtigungen und Gruppen Einstellungen, da muss was anderes als htpasswd rein.
Ich hab mal für meinen Arbeitgeber nen Benutzer/Gruppen/Repository Manager geschrieben, schade dass ich den jetzt nicht rausgeben kann :D, aber da gibts glaube ich mittlerweile auch gute Open Source Sachen :).

[ONeinONeill]

Lag jetzt gar net an der auskommentierten Zeile. Sondern ich habe eine Ebene zu früh angesetzt für das Repository. :P
Aber danke für den Hinweis wofür sie da ist, das wusste ich nicht. ;-)

[Thoran]

Das ist jetzt nicht 100% zu deine Frage, aber generell würde ich dir empfehlen dein svn als svn+ssh aufzusetzen. Meiner Ansicht nach dürfte das sicherer sein als svn über http. Vorallem wenn du es auf einem vServer hostest, der als Angriffsziel schon eher in Frage kommen, als ein Privatrechner.

Thoran

[whiteambit]

Wenn es ein windows system ist kann ich dir "Visual SVN" empfehlen: right thing, done right...

Ein doppelklick und der SVN-Server läuft, und über die schlichte GUI lassen sich schnell und einfach neue repositorys anlegen, so wie das userhandling durchführen. NICE...

[ONeinONeill]

@White

Ich benutze Linux aber es funktioniert auch alles wunderbar, zumindest bis jetzt. :D

@All

Also ich muss nochmal den Thread hier bemühen, denn der Server handelt für mich unlogisch. :)

Also hab den Subversion Server korrekt aufgesetzt und kann über den vhost auch verbinden und alles. Das klappte jetzt so 2-3 Tage, wo ich committet, geupdated, etc. habe und das ohne Probleme.

Jetzt aber auf einmal kann ich nicht mehr comitten. Es kommt folgende Fehlermeldung:

Commit
G:\Beruf\Studium\02_Semester\Qualitätssicherung\Vorlesung\QS2009_-_Kapitel_7_-_Modellbasiertes_Testen_v0_2.pdf
Übertragen schlug fehl (Details folgen):
Could not open the requested SVN filesystem

Updaten geht aber ohne Probleme, d.h. lesend hat er wohl noch Zugriff auf den Server. JEtzt habe ich zuerst gedacht, dass es Schreibrechte sein können und habe alle Repos testweise mit 777 Rechten versehen.

Aber es hat sich nichts geändert.

Dieses VErhalten ist also ganz plötzlich aufgetaucht, ich habe am eigentlichen Server nichts gemacht.

Kann es irgendwie an Dateinamen liegen, oder ähnliches? Oder woran kann es weiterhin liegen? Eventuell macht der v-Server irgendetwas was den Subversion Server behindert?

Danke schonmal für eure Hilfe

[Thoran]

Du solltest schon mehr Infos reinschreiben, z.B. wie du deinen SVN-Server jetzt letztenendes aufgesetzt hast (Protokoll, etc.)
Dann schau mal ob du auf deinem Server lokal auschecken und commiten kannst über file://
Wenn das geht ist es wohl ein Problem mit dem Zugriff über deinen Daemon, was immer du da auch verwendest.

Ansonsten hilft auch eine Suche in Google nach der exakten Fehlermeldung, wie z.B.
http://www.google.de/search?q=Could+not ... filesystem

Ich kenn da aber deinen Server nicht genau genug, um mich soweit aus dem Fenster lehnen zu können und zu sagen, voila Link x in den Google-Ergebnissen ist deine Lösung.

Ich wiederhole mich nochmals: Prinzipiell halte ich svn+ssh:// als die sicherste Lösung.

Thoran

[ONeinONeill]

Protokoll ist weiterhin HTTP.

Ich werde deinen ersten Ratschlag mal versuchen.

Bezüglich google: Die komplette erste Seite ist schon als besucht markiert! ;-)

[ONeinONeill]

Also habe jetzt mal lokales checkout gemacht, was auch funktioniert hat. Das hat allerdings auch von ausserhalb funktioniert.

Dann habe ich versucht eine Datei Datei lokal zu commiten, was zu folgender Fehlermeldung führte:

svn: Commit failed (details follow):
svn: Can't create directory '/srv/svn/repos/Webseite/db/transactions/1-1.txn': ermission denied

Dann habe ich die rechte mal auf 777 gesetzt und ich konnte dann lokal commiten.

Dann habe ich auf meinem Rechner ein Update durchgeführt und die comitete Datei wurde auch heruntergeladen. Dann habe ich eine neue angelegt und diese hinzugefügt und committet und es kam zur bekannten Fehlermeldung:

G:\Server\Webseite\test2.txt
Übertragen schlug fehl (Details folgen):
Could not open the requested SVN filesystem

[Chromanoid]

Manchmal kann es schon passieren, dass Repositories durch Systemabstürze oder Ähnliches kompromittiert werden. Schon mal das Repository neu eingerichtet? Es gibt außerdem glaube ich Wiederherstellungs/Aufräum Maßnahmen die du mit svnadmin o.Ä. durchführen kannst...

[ONeinONeill]

Ja, habe die Repos schon mehrmals neu angelegt und danach lief auch erstmal wieder alles. Bis nach einer unbestimmten Zeit diese Fehler beim Commiten kommen.

Es ist ein vServer, daher weiß ich nicht ganz genau was noch passiert, aber in den logs steht zumindest nichts drin.

[Chromanoid]

Das ganze passiert also nach einer bestimmten zeit, nicht nach einem bestimmten Commit? Weil du könntest ja mal ein Repository auf deinem Heimrechner und eins auf deinem vServer pflegen. Und dann schauen ob beide zur selben Zeit in einen fehlerhaften Zustand geraten.

Benutzt das Subversion auf deinem vServer die BerkeleyDB? Wenn ja:

Berkeley DB Recovery
As mentioned in the section called “Berkeley DB”, a Berkeley DB repository can sometimes be left in a frozen state if not closed properly. When this happens, an administrator needs to rewind the database back into a consistent state. This is unique to BDB-backed repositories, though—if you are using FSFS-backed ones instead, this won't apply to you. And for those of you using Subversion 1.4 with Berkeley DB 4.4 or later, you should find that Subversion has become much more resilient in these types of situations. Still, wedged Berkeley DB repositories do occur, and an administrator needs to know how to safely deal with this circumstance.

To protect the data in your repository, Berkeley DB uses a locking mechanism. This mechanism ensures that portions of the database are not simultaneously modified by multiple database accessors, and that each process sees the data in the correct state when that data is being read from the database. When a process needs to change something in the database, it first checks for the existence of a lock on the target data. If the data is not locked, the process locks the data, makes the change it wants to make, and then unlocks the data. Other processes are forced to wait until that lock is removed before they are permitted to continue accessing that section of the database. (This has nothing to do with the locks that you, as a user, can apply to versioned files within the repository; we try to clear up the confusion caused by this terminology collision in the sidebar The Three Meanings of “Lock”.)

In the course of using your Subversion repository, fatal errors or interruptions can prevent a process from having the chance to remove the locks it has placed in the database. The result is that the backend database system gets “wedged.” When this happens, any attempts to access the repository hang indefinitely (since each new accessor is waiting for a lock to go away—which isn't going to happen).

If this happens to your repository, don't panic. The Berkeley DB filesystem takes advantage of database transactions, checkpoints, and prewrite journaling to ensure that only the most catastrophic of events [34] can permanently destroy a database environment. A sufficiently paranoid repository administrator will have made off-site backups of the repository data in some fashion, but don't head off to the tape backup storage closet just yet.

Instead, use the following recipe to attempt to “unwedge” your repository:

Make sure no processes are accessing (or attempting to access) the repository. For networked repositories, this also means shutting down the Apache HTTP Server or svnserve daemon.

Become the user who owns and manages the repository. This is important, as recovering a repository while running as the wrong user can tweak the permissions of the repository's files in such a way that your repository will still be inaccessible even after it is “unwedged.”

Run the command svnadmin recover /var/svn/repos. You should see output such as this:

Repository lock acquired.
Please wait; recovering the repository may take some time...

Recovery completed.
The latest repos revision is 19.

This command may take many minutes to complete.

Restart the server process.

This procedure fixes almost every case of repository wedging. Make sure that you run this command as the user that owns and manages the database, not just as root. Part of the recovery process might involve re-creating from scratch various database files (shared memory regions, e.g.). Recovering as root will create those files such that they are owned by root, which means that even after you restore connectivity to your repository, regular users will be unable to access it.

If the previous procedure, for some reason, does not successfully unwedge your repository, you should do two things. First, move your broken repository directory aside (perhaps by renaming it to something like repos.BROKEN) and then restore your latest backup of it. Then, send an email to the Subversion users mailing list (at <users@subversion.tigris.org>) describing your problem in detail. Data integrity is an extremely high priority to the Subversion developers.