Blogix

Seit TYPO3 4.4 werden beim Einfügen von CSS-Dateien mittels includeCSS Zeitstempel an den Dateinamen angehängt um die Eindeutigkeit zu garantieren und Cache-Problemen vorzubeugen. Die Konfiguration für ältere TYPO3-Versionen sieht wie folgt aus:

pdf_generator = PAGE
pdf_generator {
	includeCSS.pdf = fileadmin/templates/blogix/css/pdf.css
}

Die Ausgabe im Frontend von TYPO3 4.4 mit Zeitstempel sieht dann in etwa wie folgt aus:

<link rel="stylesheet" type="text/css" href="fileadmin/templates/blogix/css/pdf.css?1282730709" media="all" />

Der PDF Generator bzw. das verwendete html2ps können damit leider nicht umgehen und das CSS wird deshalb im PDF nicht verwendet. Abhilfe schafft man, indem man die Konfiguration um zwei Zeilen erweitert und eine Ersetzung mittels regulärem Ausdruck (RegExp) durchführt:

pdf_generator = PAGE
pdf_generator {
	includeCSS.pdf = fileadmin/templates/blogix/css/pdf.css
	config.pdf_generator2 {
		regexp_search1 = /pdf\.css\?([0-9]{10})/
		regexp_replace1 = pdf.css
	}
}

PHP-Caches sind nicht immer nur für massive Performance-Gewinne, sondern manchmal auch für unerklärliche Fehler verantwortlich. So vertragen sich z.B. Horde und eAccelerator nicht. Die generierte Fehlermeldung lässt andere Fehlerquellen vermuten, an eAccelerator denkt man dabei aber vorerst nicht:

Warning: IMAP_Tree::require_once() [function.IMAP-Tree-require-once]: open_basedir restriction in effect. File(Horde/SessionObjects.php) is not within the allowed path(s): (/usr/share/php:/usr/share/pear:/usr/share/horde3:/etc/horde:/usr/lib:/usr/sbin:/var/log) in /usr/share/horde3/lib/Horde/IMAP/Tree.php on line 311

Fatal error: Can’t load Horde/SessionObjects.php, open_basedir restriction. in /usr/share/horde3/lib/Horde/IMAP/Tree.php on line 311

Man erhält also eine “open_basedir restriction”-Fehlermeldung, wie man sie schon häufig gesehen hat. Erste Vermutung ist natürlich, dass die in der php.ini konfigurierten Pfade für open_basedir nicht korrekt sind. Also sucht man zuerst nach der Datei “Horde/SessionObjects.php” und erkennt, dass sich diese an “/usr/share/horde3/lib/Horde/SessionObjects.php” befindet – dieser Pfad ist lt. open_basedir-Einstellung “…:/usr/share/horde3:…” aber eindeutig erlaubt. Die Suche geht weiter und weiter und… bis man auf die Idee kommt, dass man vor ein paar Tagen einen PHP-Cache installiert hat. Sofort nach der Deaktivierung desselbigen funktioniert wieder alles problemlos. Wie meine weiteren Recherchen herausgestellt haben, tritt dieses Problem nicht nur mit eAccelerator auf, sondern auch mit APC, usw.

Probleme mit Zeichensätzen im Zusammenhang mit MySQL aber auch mit Dateien sind wohl das häufigste Problem, das einem bei der Webentwicklung begegnet. Bei MySQL wird die Datenbank häufig als UTF-8 exportiert, beim Import auf die Angabe des Datensatzes vergessen und somit häufig mit ISO-8859-1 importiert. Das führt dazu, dass auf der Webseite anstelle der Umlaute überall “?” angezeigt werden. Achtet man beim Import gleich darauf den Zeichensatz anzugeben, erspart man sich häufig einen zweiten Import bzw. eine Fehlersuche.

Der Parameter “–default-character-set=utf8″ beim Import auf der Konsole ist dabei entscheidend:

mysql -u root -p --default-character-set=utf8 database < database.sql

Mit der Version 4.1 fanden Zeichensätze Einzug in MySQL. Man möchte meinen mit der gewünschten Einstellung von Datenbank- bzw. Feld-Kollationen seien alle Probleme beseitigt, dem ist aber nicht immer so. Zeichensätze führen häufig zu Problemen, da mehrere Komponenten beteiligt sind und somit an vielen Stellen die korrekte Angabe nötig ist, z.B. auch bei der Auslieferung des HTMLs an den Browser. Die häufigsten Problem treten aber in Verbindung mit MySQL auf.

Vor der Einführung von Zeichensätzen in MySQL wurden alle Daten als ISO-8859-1 gespeichert. Der MySQL-Client führt deshalb in der Standardkonfigurationen Anfragen an den Server weiterhin mit diesem Zeichensatz durch, um die Kompatiblität aufrecht zu erhalten. Ist nun die Kollation seitens des MySQL-Servers auf UTF-8 eingestellt, führt es unweigerlich zu Problemen, wenn der MySQL-Client mit diesem in ISO-8859-1 kommuniziert. Deshalb ist es notwendig, nach der Initalisierung der Verbindung den korrekten Zeichensatz für die Verbindung festzulegen – die geschieht mit:

SET NAMES 'UTF-8'

Diese Abfrage überschreibt für die aktuelle Verbindung die Standardeinstellung für character_set_client, character_set_connection und character_set_results. Alternativ wäre es natürlich auch möglich die Konfiguration entsprechend anzupassen und standardmäßig auf UTF-8 einzustellen. Aus Kompatibilitätsgründen sollte man darauf verzichten, solange nicht wirklich alle darauf zugreifenden Komponenten mit dieser Einstellung umzugehen wissen. Denn eine Kommunikation mittels UTF-8 mit einer ISO-8859-1-Datenbank führt unweigerlich zum selben Problem.

Zur Überprüfung ob die über apt-get/aptitude geladenen Dateien aus einer vertrauenswürdigen Quelle stammen werden diese auf der Seite von Debian mit einem privaten Schlüssel signiert und auf der Benutzer-Seite mit dem zugehörigen öffentlichen Schlüssel auf Korrektheit geprüft. Die Schlüsselpaare haben bei Debian eine Gültigkeit von drei Jahren, danach müssen diese aktualisiert werden. Der alte Schlüsselpaar verliert mit 01.07.2009 seine Gültigkeit, das neue Schlüsselpaar wird ab 13.06.2009 eingesetzt. Damit die neuen öffentlichen Schlüssel auf dem System bekannt sind, müssen diese aktualisiert werden.

Führt man “apt-get update” oder “aptitude update” ohne Aktualisierung der Schlüssel aus, wird folgende Meldung ausgegeben:

W: There is no public key available for the following key IDs:
9AA38DCD55BE302B
W: There is no public key available for the following key IDs:
9AA38DCD55BE302B
W: GPG error: ftp://ftp.hosteurope.de etch Release: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY 9AA38DCD55BE302B
W: GPG error: http://ftp.de.debian.org etch Release: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY 9AA38DCD55BE302B
W: Probieren Sie "apt-get update", um diese Probleme zu korrigieren.

Mit dem Befehl “apt-get install debian-archive-keyring” bzw. “aptitude install debian-archive-keyring” (je nachdem ob man apt-get oder aptitude bevorzugt) können die öffentlichen Schlüssel aktualisiert werden. Aus Sicherheitsgründen muss noch eine Frage mit “Ja” bestätigt werden:

Muss 12,8kB an Archiven herunterladen. Nach dem Entpacken werden 4096B zusätzlich belegt sein.
Wollen Sie fortsetzen? [Y/n/?] Y
WARNUNG: nichtvertrauenswürdige Versionen der folgenden Pakete werden installiert!

Nichtvertrauenswürdige Pakete können die Sicherheit Ihres Systems gefährden.
Sie sollten nur dann mit der Installation fortfahren, wenn Sie sicher sind, dass
dies das ist, was Sie wollen.

debian-archive-keyring

Wollen Sie diese Warnung ignorieren und trotzdem weitermachen?
Geben Sie zum Weitermachen "Ja", zum Abbrechen "Nein" ein: Ja

Die Installation wird daraufhin durchgeführt:

Schreibe erweiterte Statusinformationen... Fertig
Hole:1 ftp://ftp.hosteurope.de etch/main debian-archive-keyring 2009.01.31 [12,8kB]
12,8kB wurden in 0s heruntergeladen (81,1kB/s)
(Lese Datenbank ... 29059 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereiten zum Ersetzen von debian-archive-keyring 2007.07.31~etch1 (durch .../debian-archive-keyring_2009.01.31_all.deb) ...
Entpacke Ersatz für debian-archive-keyring ...
Richte debian-archive-keyring ein (2009.01.31) ...
gpg: key 6070D3A1: "Debian Archive Automatic Signing Key (4.0/etch) <ftpmaster@debian.org>" not changed
gpg: key ADB11277: "Etch Stable Release Key <debian-release@lists.debian.org>" not changed
gpg: key BBE55AB3: "Debian-Volatile Archive Automatic Signing Key (4.0/etch)" not changed
gpg: key F42584E6: public key "Lenny Stable Release Key <debian-release@lists.debian.org>" imported
gpg: key 55BE302B: public key "Debian Archive Automatic Signing Key (5.0/lenny) <ftpmaster@debian.org>" imported
gpg: key 6D849617: public key "Debian-Volatile Archive Automatic Signing Key (5.0/lenny)" imported
gpg: Total number processed: 6
gpg:               imported: 3  (RSA: 2)
gpg:              unchanged: 3
gpg: no ultimately trusted keys found

Abschließend kann man die installierten Schlüssel noch mit “apt-get list” ansehen:

/etc/apt/trusted.gpg
--------------------
pub   1024D/6070D3A1 2006-11-20 [expires: 2009-07-01]
uid                  Debian Archive Automatic Signing Key (4.0/etch) <ftpmaster@debian.org>

pub   1024D/ADB11277 2006-09-17
uid                  Etch Stable Release Key <debian-release@lists.debian.org>

pub   1024D/BBE55AB3 2007-03-31 [expires: 2010-03-30]
uid                  Debian-Volatile Archive Automatic Signing Key (4.0/etch)
sub   2048g/36CA98F3 2007-03-31 [expires: 2010-03-30]

pub   1024D/F42584E6 2008-04-06 [expires: 2012-05-15]
uid                  Lenny Stable Release Key <debian-release@lists.debian.org>

pub   4096R/55BE302B 2009-01-27 [expires: 2012-12-31]
uid                  Debian Archive Automatic Signing Key (5.0/lenny) <ftpmaster@debian.org>

pub   2048R/6D849617 2009-01-24 [expires: 2013-01-23]
uid                  Debian-Volatile Archive Automatic Signing Key (5.0/lenny)