sabel's blog

Hab grad auf die Schnelle ein init-script im Gentoo-Stil gebastelt, das nix andres macht als Apache und MySQL zu starten/stoppen.

#!/sbin/runscript

depend() {
	use apache2 mysql
}

start() {
	ebegin "Starting Apache"
	/etc/init.d/apache2 start
	eend $?

	ebegin "Starting Mysql"
	/etc/init.d/mysql start
	eend $?
}

stop() {
	ebegin "Stopping Apache"
	/etc/init.d/apache2 stop
	eend $?

	ebegin "Stopping Mysql"
	/etc/init.d/mysql stop
	eend $?

	eend 0
}

Hi,

im letzten Post habe ich über eine komprimierte Variante der neuesten Prototype-Version geschrieben. Wie versprochen werde ich in diesem Post erklären, wie man so eine mit gzip-komprimierte Datei möglichst elegant und flexibel in seine Seite einbindet.

Dazu legt man einfach eine .htaccess-Datei mit folgendem Inhalt an:

RewriteCond %{HTTP:Accept-Encoding} .*gzip.*
RewriteCond %{REQUEST_FILENAME} ^.+\.(js|css)$
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.+) $1.gz [QSA,L]
RemoveType .gz
AddEncoding x-gzip .gz

Wichtig: der Apache muss mod_rewrite aktiviert haben!

Jetzt muss man nur noch für alle Dateien, die man komprimiert ausliefern will eine entsprechende Variante mit dem Suffix .gz im gleichen Verzeichnis in dem das Original liegt anlegen.

Ist eine solche gzip Datei vorhanden wird diese anstatt der unkomprimierten Variante übertragen, ansonsten ändert sich nichts.

Hinweis: folgende Zeile war bei mir zwingend nötig um die globale Einstellung vom Apache zu überschreiben. Keine der Lösungen, die im Netz gefunden habe, weist darauf hin!

RemoveType .gz

Unterstützt ein Browser keine Komprimierung (sowas gibts hoffentlich nicht mehr, selbst der IE4 kann das) werden die Regeln einfach ignoriert.

Das wars auch schon. Mit dieser kleinen, aber feinen Lösung verkürzt man die Ladezeit seiner Seite erheblich.

Und weil wir grad beim Thema Subversion und Apache sind. Ich bin letztens auch über etwas anderes gestolpert.
Wenn sich euer Subverion Client weigert eure .htaccess Datei auszuchecken, dann liegt das vermutlich an der Konfiguration eures Apaches.

Standardmäßig ist folgendes eingestellt:

<FilesMatch "^\.ht">
        Order allow,deny
        Deny from all
</FilesMatch>

Ändert das global(keine gute Idee) oder für euren vhost in:

<FilesMatch "^\.ht">
        Order allow,deny
        Allow from all
</FilesMatch>

Und schon flutscht auch Subversion.

Hiho,

heute bin ich wieder auf einen sehr nervenden Fehler gestoßen. Da es eine Weile gedauert hat, bis ich eine Lösung gefunden hatte, will ich sie euch nicht vorenthalten.

Folgendes Szenario:

• du checkst dir ein Repository aus
• bearbeitest eine Datei
• updatest deine Arbeitskopie
• commitest deine Änderungen

Bis hier sollte alles ohne Probleme funktionieren.
Wiederholt man aber die Schritte kann es bei einem bestimmten Szenario zu folgendem Problem kommen.

svn: Commit failed (details follow)
svn: Your file or directory ‘bla.txt’ is probably out of date
svn: The version resource does not correspond to the resource within the transaction. Either the requested version resource is out of date (needs to be updated), or the requested version resource is newer than the transaction root (restart the commit).

Der Übeltäter ist die Datei “all-wcprops” im entsprechenden .svn-Verzeichnis, in der sich die Datei befindet.
Eine Lösung wäre diese Datei einfach zu löschen und danach ein Update auszuführen. Das hat aber 2 Nachteile.

1. Man sollte NIE manuell im .svn-Verzeichnis rumbauen – geht meistens schief
2. Es ist verdammt nervig, denn der Fehler tritt ständig auf
3. Damit lindert man nur die Schmerzen, bekämpft aber nicht die Krankheit

Der Grund des Übels liegt nämlich nicht lokal, sondern beim Apache-Server.

Bug: http://subversion.tigris.org/issues/show_bug.cgi?id=1851

Workaround:
Do not put your repository at
i.e. https://svn.myhost.cno/repos/
not https://svn.myhost.cno/

Quelle: http://svn.haxx.se/users/archive-2004-09/0210.shtml

Tja, so einfach kanns manchnal sein.

Ich hoffe, ich konnte jemandem damit helfen.

Hi,

wie bereits im vorherigen Eintrag angekündigt, will ich euch natürlich mitteilen, wie ich den Apache dazu gebracht habe sich an einem MySQL-Server zu authentifizieren.

An sich ist das ja kein Problem, solange man sich aussuchen kann in welcher verschlüsselten Form die Passwörter in der Datenbank abgespeichert sind. Will man aber ein bereits bestehendes System nutzen kann es unter Umständen schon heikler werden. In meinem Fall lagen die Passwörter als SHA1-Hash vor.

Wie bereits erwähnt, mangelt es MySQL an Funktionen für die Base64 De-/Kodierung. Hat man diese aber nachgerüstet, lässt sich der Apache relativ einfach dazu bewegen auch SHA1 zu schlucken.

Es hat eine Weile gedauert bis ich auf diese Seite gestoßen bin, die genau erklärt, in welchem Format mod_authn_dbd die Passwörter erwartet.

Danach war es nur noch eine Kleinigkeit und herausgekommen ist:

AuthDBDUserPWQuery "SELECT CONCAT('{SHA}',BASE64_ENCODE(UNHEX(hashed_password))) AS pass FROM users WHERE login=%s"

Ich hoffe, ich konnte dem ein oder anderen ein paar Stunden Suche ersparen!