Mit ‘apache’ getaggte Artikel

Erfahrungen aus der Subversion-Umstellung

von Khark am 1. November 2008 um 13:20 Uhr

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 :-)

Apache Spielerein mit mod_rewrite

von Khark am 28. November 2007 um 12:11 Uhr

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>

Apache und NTMLv2 Authentifizierung

von Khark am 13. November 2007 um 17:25 Uhr

Mal wieder etwas ähnliches wie hier.
Zwar geht es jetzt nicht um MySQL-Authentifizierung, aber um Authentifizierung mit NTLMv2.

In Windows Vista ist die Defaulteinstellung in den Gruppenrichtlinien für die Authentifizierung im Netzwerk: “Sende nur NTLMv2 Antworten.”
Zwar kann man dies ändern, aber sicherheitstechnisch macht ein Wechsel zu NTLMv2 schon Sinn.
So, nun setzen wir aber häufiger den Apache Webserver als Microsofts IIS Webserver ein. Zum Glück :-)

Und irgendwie gibt es kein Modul für Apache, das mit NTLMv2 umgehen kann.
Unter http://search.cpan.org/~speeves/Apache-AuthenNTLM/AuthenNTLM.pm
findet sich ein Perl-Modul das wir auch für NTLMv1 einsetzen.
Mit NTLMv2 mag dies aber nicht.
– Wobei ich da jetzt noch nicht mit 100%iger Sicherheit sagen kann, ob dies wirklich am Modul selbst liegt, oder an der Gegenstelle..

Die anderen Module die ich gefunden haben, schreiben explizit, das sie kein NTLMv2 können oder man findet nur Berichte, das es nicht geht.

Daher mal eine Rundfrage:
Wie macht ihr im Apache (und Tomcat, wo wir schon dabei sind) Authentifizierung mit NTLMv2 ?

Kein libapache2-mod-auth-mysql in Etch

von Khark am 18. Juli 2007 um 23:30 Uhr

Ich möchte mal erwähnen, das ich es beschissen finde, das in Debian Etch kein libapache2-mod-auth-mysql gibt.
In Sarge ist es enthalten und in Sid (Testing) auch. Nur in Etch nicht.
Wieso? Nun der Autor hat keinen Bock mehr auf das Apache-Modul-Gefrickel und seinen den Betreuerposten für das Paket aufgegeben.
Mittlerweile hat sich ein neuer gefunden, weswegen es auch wieder in Sid ist, aber für Stable hat es dann nicht gereicht.

Debian empfiehlt stattdessen libpam-mysql mit libapache2-mod-auth-pam zu nutzen.
Leider benötigt der Webserver dafür immer Leserechte auf die /etc/shadow. (Wenn dem nicht der Fall ist, bitte korrigiert mich.) Etwas das für mich einfach nicht vertretbar ist.
Den wenn ich von MySQL rede ist fast immer PHP mit im Spiel. Und PHP-Software kann teilw. schon recht eklig sein.
Dieser dann aber noch die Möglichkeit einräumen über den Webserver die /etc/shadow zu lesen.
- Nein danke.
Gut über so Sachen wie suPHP/suexec könnte man das ganze wieder eindämmen. Das ist dann wieder zuviel gefrickel. Da ist es einfacher die Benutzerauthentifizierung gegen MySQL in die Anwendung direkt einzubauen.
Zudem ist die Doku zu dem Umgang mit libpam-mysql dürftig. Zwar findet man die Direktiven irgendwo unterhalb von /usr/share/doc/libpam-mysql/README aber naja..

Nun gut. Jetzt ist es ja nicht so, das Apache keine anderen Module hat die man für die Authentifikation gegen eine MySQL-Datenbank nutzen könnte.
Zum Beispiel sieht mod_dbd zusammen mit mod-authn-dbd doch recht vielversprechend aus.

Unterstützt wird laut http://httpd.apache.org/docs/2.2/mod/mod_dbd.html#dbdparams Oracle, PostgreSQL, MySQL und SQLlite 2/3.
Schön. Allerdings kommt der Treiber für MySQL nicht mit, weil MySQL da andere Lizenzbedingungen hat als Debian.
Siehe: http://apache.webthing.com/database/
Selbst nachkompilieren geht nicht, weil ich den Apache-Source nicht habe, geschweige den apxs um das Modul zu basteln. Ich könnte ihn zwar installieren (Pakete apache2-src und apache2-threaded-dev) will ich aber nicht.
- Zuviel gefrickel.
Zudem sind die mod_dbd Direktiven nur im Server oder Virtual Server Kontext zulässig. Soll heißen das ich für jedes Verzeichnis, für jede Applikation bei der ich per mod_dbd und mod-authn-dbd die User authentifizieren will, einen eigenen virtuellen Host anlegen müsste.
In meinem Versuch klappt es nicht 2 unterschiedliche DBDParams-Direktiven in einem virtuellen Host anzulegen. (Getestet mit PostgreSQL.)
Man könnte das ganze ja wiederum über Include-Anweisungen lösen, dann müsste man zumindest nicht die DBD-Direktiven immer neu schreiben.
Aber ich mache doch nicht für jedes Verzeichniss einen eigenen virtuellen Host auf. Die Lösung über .htaccess oder die Directory-Direktiven fand ich da schon besser.

Also zur guckt man nach einer anderen Alternative. Zum Beispiel nachträglich erstellten MySQLAuth-Paketen für Debian Etch. (http://www.heuer.org/mod_auth_mysql/)
- Diese wollen aber auch nicht. “Floating point exception.” beim starten von Apache.

So langsam kann ich echt verstehen wieso der Autor das Paket aufgegeben hat.
Ich integriere die Benutzerauthentifizierung jetzt jedenfalls direkt in meine PHP-Anwendungen. Spart jede Menge Ärger, ist zukunftssicherer und macht die Applikation unabhängiger vom Webserver.

Mehrere HTTPS-Hosts mit einem SSL-Zertifikat

von Khark am 20. Januar 2007 um 14:03 Uhr

Genau sowas habe ich gesucht. :)

http://wiki.cacert.org/wiki/VhostsApache
Via: Migri

Evtl. auch ganz nützlich: http://wiki.cacert.org/wiki/VhostTaskForce
Via: IRC