Mein Zweithirn

Wenn man mehrere virtuelle Maschinen für verschiedene Webdienste mit einer IP betreiben will, kommt man nicht umhin einen Proxy zu verwenden. Dafür eignet z.B. mod_proxy mit mod_proxy_http.

ProxyPass /myApp http://internerServer:8080/myApp ProxyPassReverse /myApp http://internerServer:8080/myApp

Dies leitet alle Anfragen an /myApp an den entfernten Host weiter, der nur im internen Netz erreichbar ist, und kümmert sich drum, dass alle Hostnamen in den HTTP-Headern entsprechend geändert werden. Die ausgegebene Webseite wird jedoch nicht verändert, so dass absolute Links möglicherweise auf die falsche Adresse linken. Wenn die hinter dem Proxy laufende Software damit nicht umgehen kann, empfielt sich mod_proxy_html, welches versucht alle absoluten Pfade im HTML zu ersetzen. Wenn die Software die Links jedoch entsprechend der URL generiert, mit der sie aufgerufen wurde, kann man mit der Direktive

ProxyPreserveHost On

den Apache dazu bringen, die Anfrage ohne Änderung des Host:-Headers weiterzuleiten. Lohnt sich vorallem bei der Generierung von RSS-Feeds. Quellen: [1] http://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypreservehost [2] http://www.atlassian.com/software/jira/docs/latest/apacheintegration.html

Mit Subversion Version 1.5 gibt ein neues Feature: Sparse Checkouts Das ist vorallem bei großen Repositories nützlich, wenn man nur an einem kleinen Teil arbeiten möchte und deswegen nicht den ganzen Branch z.B. auschecken will. Ein Szenario ist z.B. die Betreuung mehrerer Branches eines Projekts. z.B. ein Branch STABLE, in den nur wichtige Bugfixes eingepflegt werden und auf der anderen Seite trunk mit der aktuellsten Entwicklerversion.

pegro@grossesp ~/myProject $ find * | grep -v .svn | sort branches branches/BROKEN branches/BROKEN/file1 branches/BROKEN/file10 branches/BROKEN/file2 branches/BROKEN/file3 branches/BROKEN/file4 branches/BROKEN/file5 branches/BROKEN/file6 branches/BROKEN/file7 branches/BROKEN/file8 branches/BROKEN/file9 branches/STABLE branches/STABLE/source.c tags trunk trunk/source.c

Findet man nun einen Bug, der sowohl in der Stable- als auch in der Entwicklerversion auftritt, im Beispiel in der Datei source.c, wäre es ja wünschenswert, ihn mit einem Commit für beide Versionen zu beheben. Dazu müsste man aber von der obersten Ebene an auschecken und so das komplette Repository als Arbeitskopie liegen haben. Das kann bei größeren Projekten zu einem echten Problem werden. Sparse checkouts funktionieren über eine neue Variable --depth, für die es 3 Werte gibt: empty, immediates und infinity. Was das bedeutet, versuche ich mal an Beispielen deutlich zu machen: empty:

pegro@grossesp ~ $ svn co https://subversion/repos/myProject/ myProject --depth empty Checked out revision 1.

enthält somit nur ein .svn-Verzeichnis, keine Ordner und keien Dateien. immediates:

pegro@grossesp ~ $ svn co https://subversion/repos/myProject/ myProject --depth immediates A myProject/trunk A myProject/branches A myProject/tags Checked out revision 1.

checkt nur Dateien und direkte Unterordner aus, jedoch nicht deren Unterordner oder Dateien. infinity: Das ist bei Checkout dasselbe, wie ohne diesen Parameter: Alles landet in der Workingcopy. Diese Tiefenangabe wird persistent für diese Arbeitskopie gespeichert, sodass beim svn update auch nur das notwendigste aktualisiert wird. Jedoch kann man diese Angabe verzeichnisweise überschreiben. Ziel im Beispiel ist also nun, das Repository auszuchecken ohne den Branch BROKEN. Beginnen wir mit den Ordnern auf der obersten Ebene:

pegro@grossesp ~ $ svn co https://subversion/repos/myProject myProject --depth immediates A myProject/trunk A myProject/branches A myProject/tags Checked out revision 1.

Dann folgen noch die immediates vom branches-Ordner:

pegro@grossesp ~ $ svn up myProject/branches/ --set-depth immediates A myProject/branches/BROKEN A myProject/branches/STABLE Updated to revision 1.

Bei initialen Checkout wird die Tiefe mit --depth gesetzt. Für dieses Update muss der Wert mit --set-depth für den Ordner überschrieben werden, damit dessen Unterordner erscheinen. Den trunk und den STABLE-Branch wollen wir hingegen komplett auf der Festplatte:

pegro@grossesp ~ $ svn up myProject/branches/STABLE --set-depth infinity A myProject/branches/STABLE/source.c Updated to revision 1. pegro@grossesp ~ $ svn up myProject/trunk --set-depth infinity A myProject/trunk/source.c Updated to revision 1.

Somit haben wir nun die gewünschte teilweise Arbeitskopie ohne den BROKEN-Branch:

pegro@grossesp ~/myProject $ find * | grep -v .svn | sort branches branches/BROKEN branches/STABLE branches/STABLE/source.c tags trunk trunk/source.c

Nun kann man seine Änderung in beide Zweige mit einem Commit einchecken:

pegro@grossesp ~/myProject $ svn commit --message "fixes bug #1" Sending branches/STABLE/source.c Sending trunk/source.c Transmitting file data .. Committed revision 2.

Quellen: [1] http://svnbook.red-bean.com/nightly/en/svn.advanced.sparsedirs.html [2] http://subversion.tigris.org/svn_1.5_releasenotes.html#sparse-checkouts

Also ich hab ja schon viel gesehen, aber das ist mir noch nicht passiert. Durch einen Bug konnte ein Cronscript nicht sauber durchlaufen und startete deswegen alle 5 Minuten und schrieb mir einige nette Mails. Das Problem war eine nicht geprüfte Variable. Also einfach eine if-Schleife mit

if(empty(calcReturnValue($variable))) { ...

dachte ich sollte das Problem beheben. Denkste.

Fatal error: Can't use function return value in write context in /path/to/script on line irrelevant

Da hab ich nicht schlecht gestaunt. Denn empty kann nur Variablen auf "leer" prüfen:

Note: empty() only checks variables as anything else will result in a parse error. In other words, the following will not work: empty(trim($name)).

Und ja, empfohlen wird

$result = calcReturnValue($variable); if(empty($result)) { ...

Sachen gibts... Quelle: http://www.php.net/manual/en/function.empty.php