Amish Geeks » mod_rewrite Hier steht mal irgendwann ein toller Titel. Mon, 07 May 2012 20:22:54 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 Erfahrungen aus der Subversion-Umstellung /blog/erfahrungen-aus-der-subversion-umstellung/ /blog/erfahrungen-aus-der-subversion-umstellung/#comments Sat, 01 Nov 2008 11:20:13 +0000 Khark https://amish-geeks.de/blog/erfahrungen-aus-der-subversion-umstellung/ Ich habe bei mir in der Firma letzte Nacht sämtliche unserer SVN-Repositories vom SVN-Server unserer ehemaligen Mutterfirma auf unsereren eigenen migriert.
Knapp 14GB Daten an SVN-Dumps und gut 50 Repositories.

Was ich dabei gelernt habe war:
0. Die alten Repository-URLs per mod_rewrite auf die neuen Umzulenken war eine gute Idee und klappt problemlos. Auch wenn an 2 Stellen an der URL herumgeschrieben werden muss und das ganze von extern nach intern über eine ProxyPass und ProxyPassReverse-Direktive laufen muss.

1. PROPFIND vergessen zu definieren eine blöde Idee. Man erhält so wünderschöne Fehlermeldungen wie:
“Repository moved temporarily to $NEUER_PFAD please relocate”, wobei $NEUER_PFAD bereits der Pfad ist, unter dem das Repository dann letzten Endes nach der Umstellung auch liegt. TortoiseSVN konnte bei einem Relocate lediglich die Repository-Konfig nicht einlesen und verweigert somit die Umstellung..

Ein simples

<Limit PROPFIND>
Require valid-user
<Limit>

in Directory-Container für das SVN-Verzeichnis in der Vhost-Konfig behob dann das Problem.

3. Wenn Entwickler mit SVN nicht umzugehen wissen ist das blöd. Wir hatten ein Repository mit knapp 17.893 Commits. Es war aber nur 50MB groß. (Das sind nur 2,86 KB pro Commit!)
Des Rätsels Lösung?
Es wurden erst knapp 30MB an .xml-Dateien eingecheckt, dann mit dem nächsten Commit wieder gelöscht. Dann wieder eingecheckt usw. Nur ganz selten wurde mal eine .xml-Datei geändert.
Subversion hat dann immer brav alles eingespielt, wieder gelöscht usw.
Hat knapp 45min gedauert das Repository einzuspielen..

4. Sämtliche Gruppen-, Repository- und Benutzernamen ein jeweils eigenes Namensschema zu geben und die groups und htpasswd Dateien alphabetisch sortieren zu lassen war auch eine gute Idee.
Man findet sich auf Anhieb wieder zurecht :-)
Ich habe die Repositorynamen jetzt immer Kleingeschrieben und die Gruppen des Repositories heißen wie das Repository. Wenn keine Lese-/Schreibrechte vorhanden sind, werden die Rechte durch Unterstrich getrennt auch im Gruppennamen deutlich.
Wird Pfad-basierte Authentifizierung verwendet, werden die Pfad direkt nach dem Root-Verzeichnis des Repositories festgelegt.

Also z.B.:
[repo1:/]
@repo1 = rw
@repo1_read = r
[repo1:/Dokumentation]
@repo1 = rw
@repo1_read =

Wie das vorher aussah will man nicht wissen :-)

]]>
/blog/erfahrungen-aus-der-subversion-umstellung/feed/ 1
Apache Spielerein mit mod_rewrite /blog/apache-spielerein-mit-mod_rewrite/ /blog/apache-spielerein-mit-mod_rewrite/#comments Wed, 28 Nov 2007 11:11:01 +0000 Khark /blog/apache-spielerein-mit-mod_rewrite/ Da wir schon länger nichts zu Apache und so hatten, mal ein kleiner Beitrag.

Ich wollte eine PHP-Applikation für den Rest der Welt so gut es geht verstecken.
In VHost selbst ist der Zugriff auf das Verzeichnis nur von einer bestimmten IP erlaubt. Alle andere erhalten eine 403-Fehlermeldung (Zugriff verboten).

Ich wollte aber ganz gerne, das diese Leute eine 404-Meldung bekommen, damit man gar nicht merkt, das hinter dieser URL besagte Applikation steckt.
Dies erledigt folgender Anweisungsblock:

Wenn die IP, nicht der einzig zugelassenen entspricht und die URI /phpmyadmin/ ist, dann änder die URL nicht (hier wird /phpmyadmin/ durch /phpmyadmin/ ersetzt..) und sende den Statuscode 404.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^ip.ip.ip.ip$
RewriteCond %{REQUEST_URI} ^/phpmyadmin/$
RewriteRule ^/phpmyadmin/$ ^/phpmyadmin/$ [R=404]
</IfModule>

]]>
/blog/apache-spielerein-mit-mod_rewrite/feed/ 0