PHP: error_reporting setting in apache config

Schöner Denkfehler.

In der php.ini setzt man die error_reporting Stufen mittels Bitverknüpfung über Konstanten (Liste):

php_admin_value error_reporting E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED

Um für einen bestimmten vhost im Apache abweichende Werte zu setzen, gibt es die Settings “php_admin_value” und “php_admin_flag”. Kommt man jedoch (wie ich) auf die Idee es wie in der php.ini üblich einzutragen, erhält man nicht das gewünschte Ergebnis. Grund ist, dass PHP an dieser Stelle die Konstanten nicht auswerten kann.

# falsch
php_admin_value error_reporting E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
 
#richtig
php_admin_value error_reporting 22519

MacOS rsync: Zeichensalat

Ähnliches Problem wir hier.

Insbesondere beim Verwenden von “–delete” kommt die von MacOS mitgelieferte rsync-Version nicht mit Sonderzeichen klar. Daten mit Umlauten werden jedes mal gelöscht und danach erneut übertragen. Die mitgelieferte Version (2.6.9) hat noch keinen iconv-Support zum Konvertieren der Zeichensätze.

Abhilfe schafft es rsync 3.x zu installieren: Entweder selbst kompilieren oder ein Binary von z.B. hier verwenden. Rsync liegt danach unter /usr/local/bin/.

Für den Zeichensatz des Macs gibt es ein pseudo-UTF8: “UTF8-MAC”. So klappt es dann endlich mit dem rsync (hier Mac <=> Linux):

/usr/local/bin/rsync -av --delete --iconv=UTF8-MAC,UTF8 -e ssh otto@192.168.24.27:/home/otto/data/ data/

Optimale MTU feststellen

Statt endloser ping-Orgien mit unterschiedlichen Paketgrössen erledigt tracepath die Suche nach der optimalen MTU mit einem Kommando:

otto@thinkpad-otto:~$ tracepath 88.151.64.34
 1:  10.0.3.44                                             0.110ms pmtu 1500
 1:  10.0.0.254                                            0.739ms 
 1:  10.0.0.254                                            0.961ms 
 2:  10.0.0.254                                            0.709ms pmtu 1300
 2:  192.168.5.254                                         1.479ms 
 3:  79.173.156.177                                        2.790ms 
 4:  806.gi0-1.managed-lns01.inx.dsl.enta.net             21.856ms 
 5:  806.gi4-37.interxion.dsl.enta.net                    21.036ms 
 6:  te2-3.interxion.core.enta.net                        21.271ms asymm  9 
 7:  te5-1.gs1.core.enta.net                              21.556ms asymm  8 
 8:  te5-8.telehouse-east2.core.enta.net                  47.876ms asymm  7 
 9:  te5-7.telehouse-north0.core.enta.net                 26.689ms asymm  8 
10:  te5-4.amsterdam.core.enta.net                        27.880ms asymm  9 
11:  te-0-1-0.peer1.sara.ams.man-da.net                   28.509ms asymm 10 
12:  te-1-3-0-400.core1.fra1.ix.f.man-da.net              35.467ms 
13:  ge-1-2-9-0.core1.fra3.de.smartterra.net              35.483ms 
14:  xe-0-0-2-501.core1.dus2.de.smartterra.net            38.502ms 
15:  ge1-910.j-3.dus2.hk-net.de                           44.076ms asymm 16 
16:  ge1-99.j-1.dus1.hk-net.de                            42.926ms asymm 17 
17:  wan1.fw-1.dus1.hk-net.de                             39.980ms 
18:  ns2.hk-net.de                                        41.161ms reached
     Resume: pmtu 1300 hops 18 back 47 

Danke Hendrik!

http://127.0.0.1/ie-tab-l/indexIE.html

Seit ein paar Tagen tauchen bei mir im Error Log Meldungen mit dem Referrer “http://127.0.0.1/ie-tab-l/indexIE.html” auf. An sich nichts ungewöhnliches. Nur versucht der Referrer immer “favicon.ico” am Query String anzuhängen und nicht im Hauptverzeichnis des URI bzw. der Domain zu suchen:

z.B.

http://www.bergercity.de/test/?search=testfavicon.ico
http://www.bergercity.de/test/?search=helloworldfavicon.ico

Tippe mal auf ein verunglücktes IE-Addon. Oder sogar der IE selbst?

Update:
Seems like its caused by the “PC Tools Browser Guard Toolbar”: Technet, Bug Report

PDF in PNG/JPG umwandeln (mit ImageMagick)

Mal wieder ein Notizzettel. Alle PDF Dateien in einem Verzeichnis in PNG umwandeln. Dabei auf korrektes Farbprofil achten, die Schriften mit “Antialiasing” rendern und dann das PNG in 8bit Farbtiefe abspeichern:

#!/bin/bash
 
for f in `find . -name "*.pdf"`; do
echo $f
 
convert \
-profile CMYK/USWebCoatedSWOP.icc \
-profile RGB/AppleRGB.icc \
-density 480 ${f} -resize 25% \
-set filename:f '%t.%e' \
-flatten \
-colorspace rgb \
-background white \
-depth 8 \
-quality 84 \
PNG:'%[filename:f].png'
 
done;

Leicht abgewandelt geht das auch als JPG. Dafür nur die Ausgabe ändern. Der Qualityparameter findet nur bei JPEG Anwendung.

Etwas tricky ist die “density” Anweisung: Da ich im Output 120dpi haben möchte aber dennoch gerne einen Antialias Effekt beim Schriftrendering hätte, wird das Bild 4-Fach vergrößert aufgelöst und dann um 25% verkleinert…

Die Colorprofile liegen im Unterverz. “CMYK” und “RGB” und können hier von Adobe heruntergeladen werden. Den Hint mit den Color-Profilen habe ich vom Linux-Magazin.

Ubuntu 12.04 Precise: Kernel 3.8 mit LTS Support

Ubuntu 12.04.3 wird den Kernel 3.8 aus Quantal enthalten. Noch ist 12.04.3 nicht verfügbar, aber das Meta Package existiert schon:

sudo apt-get install linux-generic-lts-raring

Damit hat man auf seiner Ubuntu Longterm einen aktuellen Kernel (u.a. mit mdadm TRIM Support).

Eine Sache ist mir aber noch aufgefallen. Es scheint so zu sein, dass neuere Kernel-Header keine version.h mehr enthalten. Dadurch gibt es dann z.B. noch Probleme beim Bauen von Kernel-modulen (z.B. drbd8) mit module-assistant. Es kommt dann die Meldung dass die Kernel Header des aktuellen Kernels fehlen würden. Folgendes hat mir dann geholfen:

cp /usr/include/linux/version.h /usr/src/linux/include/linux/

mdadm Softraid on SSD with TRIM

Seit Kernel 3.7 unterstützt das mdadm Softraid den TRIM Befehl.

SSDs benötigen Idealerweise Raum für ihren Wear leveling Algorithmus. Da das mdadm RAID aber die gesamte Partition als “belegt” beansprucht, hat der SSD Controller wenig Ausweichmöglichkeiten und die Schreibperformance geht in den Keller. Da kann man nur die Spare Area mit hdparm vergrößern – verschenkt aber damit wertvollen Platz. Dateisysteme (z.B. ext4) verstehen schon länger den TRIM Befehl (Mountoption “discard”) – aber dies nützt(e) nichts wenn das Dateisystem auf einem Softraid liegt.

Bis Kernel 3.7 bekam man nur folgendes zu sehen:

root@node:~# fstrim /
fstrim: /: FITRIM ioctl failed: Operation not supported

Ab Kernel 3.7 sieht es dann besser aus:

root@node:~# fstrim -v /
/: 12858519552 bytes were trimmed