Eigentlich ist suPHP eine nette Sache. Das Apache Modul mod_suphp sorgt in Kombination mit einem SetUID Binary dafür, dass PHP-Skripte mit den Berechtigungen des Benutzers, dem sie gehören, ausgeführt werden. Damit das funktioniert muss man in Binär-Distributionen wie etwa Debian Linux nicht mehr tun, als dass Modul zu installieren, einen Blick auf dessen Konfiguration zu werfen und es anschließend zu aktivieren. Vielleicht ist es gerade diese Einfachheit (deren Preis die Starrheit ist), die es so beliebt macht.

Ein großes Problem tut sich aber dann auf, wenn man PHP-Caches wie APC, TurckMM oder eAccelerator verwenden möchte. Denn all diese Caches funktionieren nicht im Zusammenspiel mit suPHP. Zwar lässt sich eine solche Kombination verwenden, doch ist sie leider nutzlos, da nichts gecached wird.

Eine wundervolle Alternative zu der Verwendung von suPHP ist eine Kombination aus Apache, SuExec, FCGID und PHP-CGI. Mit dieser Kombination funktioniert auch das Caching problemlos. Eine Anleitung zum Aufsetzen dieser Kombination findet sich bei Hetzner.de.

Wer seine Websites nicht in dem von der jeweils genutzten Linux Distribution dafür vorgesehenen Verzeichnis ablegt sondern stattdessen beispielsweise in /home/*/public_html/ muss darauf achten, SuExec selbst zu kompilieren oder auf Debian-Systemen die gepatchte Version apache2-suexec-common zu verwenden. Aus Sicherheitsgründen erwartet SuExec bereits bei der Kompilierung den Pfad zum Docroot. Bei der Verwendung von apache2-suexec-common lässt sich das Docroot in der Datei /etc/apache2/suexec/www-data angeben.

Lange Zeit habe ich davor gescheut, meine Wordpress-Installation zu aktualisieren. Hauptsächlich, weil ich Angst vor dem Aufwand hatte, schließlich habe ich noch Wordpress 2.1 benutzt (aktuell ist 2.8.4) und daher mit zahlreichen Inkompabilitäten gerechnet. Letzte Nacht habe ich es dann trotzdem gewagt und das Wordpress Update durchgeführt.

Und es geht doch…
…uralte Wordpress-Installationen problemlos zu aktualisieren. Sogar ziemlich einfach. Orientiert habe ich mich dabei an diesem Artikel. Mir persönlich erschien es dabei aber sauberer, die neue Version herunter zu laden und die paar Sachen (Bilder), die ich aus der der alten Installation benötigte in die neue hinein zu kopieren. Dies ermöglicht es einem, eine Subdomain anzulegen, auf der man die neue Installation erst einmal testen kann. Anschließend kann man mit einem Symlink einfach die verwendete Installation wechseln.

Das Loop Disk Image einer XEN DomU ist zu klein geworden? Solang die Festplatte des Hypervisors noch genügend Platzreserven hat, ist das glücklicherweise kein unlösbares Problem. Loop Disk Images können mit Bordmitteln vergrößert werden. Zwei kleine Beispiele für die Vorgehensweise bei EXT2, EXT3 und XFS Dateisystem:

EXT2 / EXT3 Dateisystem
VM herunterfahren:

xm shutdown domu.blub.local

Image um 30GB vergrößern:

dd if=/dev/zero bs=1024k count=30720 >> disk.img

Fehler im Dateisystem korrigieren:

e2fsck -f disk.img

Dateisystem auf die Größe des Images vergrößern:

resize2fs disk.img

XFS Dateisystem
VM herunterfahren:

xm shutdown domu.blub.local

Image um 30GB vergrößern:

dd if=/dev/zero bs=1024k count=30720 >> disk.img

Fehler im Dateisystem korrigieren:

xfs_repair -f disk.img

Dateisystem auf die Größe des Images vergrößern:

mount disk.img /mnt/tmp/ -o loop
xfs_growfs -d /mnt/tmp/

Einfach nur herrlich dieser Clip. Es trifft zwar glücklicher Weise nur auf wenige potentielle Auftraggeber zu aber dennoch begegnet einem diese Spezies immer wieder: Menschen mit dem Wunsch die perfekte Website innerhalb kürzester Zeit zu erhalten – selbstverständlich zum Ramschpreis. Das Video zeigt, wie sie außerhalb ihrer geschäftlichen Tätigkeit agieren.

Mein MacBook hat sich heute morgen geweigert zu starten. Fünf Anläufe waren nötig, damit das Teil endlich lief. Als es dann endlich geklappt hat, konnte ich mir erst einmal die Schweißperlen von der Stirn wischen, die bei dem Gedanken an meine Abschlussarbeit auf dem Gerät entstanden. Aber etwas war anders als sonst: Die Grüne LED neben der iSight Kamera leuchtete plötzlich permanent auf. Eigentlich zeigt diese an, dass die Kamera aktiv ist, was aber nicht der Fall war. In Photo Booth blieb das Bild schwarz. Neustart & co brachten keine Besserung. Folgendes hingegen schon:

• MacBook ausschalten
• Netzteil-Kabel entfernen und Batterie herausnehmen
• 5 Sekunden auf den Einschalter drücken
• Batterie wieder einlegen, Netzteil-Kabel wieder ran und tata – alles funktioniert wieder wie gewünscht

Magento gestaltet einen Serverumzug leider schwieriger, als er sein müsste. Die Entwickler haben zahlreiche Stolpersteine versteckt, die es eigentlich gar nicht geben müsste (etwa das speichern vollständiger URLs in der Datenbank). Dennoch ist ein Serverwechsel einfacher, als man mancherorts liest:

1. Im Magento Backend unbedingt den Cache deaktivieren, zumindest den Konfigurations-Cache, denn auch die MySQL Zugangsdaten werden gecached, was dazu führt, dass nach dem Umzug nichts funktioniert und keine Möglichkeit dazu besteht, mit akzeptablen Aufwand den Cache zu leeren – der Login im Adminbereich geht dann nämlich auch nicht mehr.

2. SQL-Dump erzeugen:

mysqldump -uBENUTZER -pPASSWORT DATENBANK > magento.sql

3. Leider speichert Magento Komplette URLs in der Datenbank, etwa die Base URL und die Secure Base URL.
Daher ist es notwendig, die verwendeten IPs / Domains in dem Dump zu suchen und zu ersetzen, sofern sich diese geändert haben.
Den Dump dazu einfach in mit dem Lieblings-Texteditor (z.B. nano) öffnen oder alternativ mit reichlich Kommandozeilen-Magic (grep, sed). Ersteres geht in diesem Fall ausnahmsweise schneller

4. GZIP-komprimiertes Tararchiv aus dem Magento-Rootverzeichnis und dem SQLdump erzeugen:

tar cfz magento.tgz ~/public_html/magento magento.sql

5. Das Archiv per SCP oder FTP auf den neuen Server schieben, z.B.:

scp magento.tgz user@host:/absoluter_verzeichnis_pfad/

6. Das Archiv auf dem neuen Server entpacken:

tar xfz magento.tgz

7. Falls notwendig die entpackten Dateien / Verzeichnisse via mv ins neue htdocs verschieben…

8. Den entpackten Dump in die neue Datenbank einspielen:

mysql -uBENUTZER -pPASSWORT DATENBANK < magento.sql

9. Leider speichert Magento absolute Pfade, die für die Installation von Erweiterungen via Pear (bzw. Magento Connect als Frontend) verwendet werden.
Um diese Pfade zu aktualisieren muss man ins neue Magento-Wurzelverzeichnis wechseln und dort folgenden befehl ausführen:

./pear mage-setup

Ansonsten ist es nicht möglich Erweiterungen via Magento Connect einzuspielen!

In manchen Fällen können Bit Flags in PHP-Skripten sehr nützlich sein. Etwa wenn es darum geht,
anhand eines “action”-Parameters zu entscheiden, welche Objekte instanziiert werden sollen. U.a. auf diese Weise kann
- sonst redundanter – Code gesparrt werden.

Kennern des binären Zahlensystems sollten also mal einen Blick darauf werfen. Alle anderen sollten dringend zu
diesen Kennern werden – das macht nicht nur das Verständniss des folgenden Codesnippets sondern das ganze (IT-) Leben einfacher

Das Prinzip ist eigentlich ganz einfach: Es werden einzelne Bits einer Integer Variablen gesetzt. Mit einer
logisch AND Verknüpfung kann dann geprüft werden, ob einzelne Bits gesetzt wurden. Mit AND können Bits gelöscht werden,
mit OR werden sie hinzu addiert. Jedes Bit stellt ein Flag dar. Ist ein Flag gesetzt werden entsprechende Aktionen ausgeführt.

Ein kleines Beispiel zu Bit Flags in PHP5:

class example_controller {
	/**
	 * Flags set by $this->setFlags()
	 *
	 * @var int
	 */
	private		$flags			=	0;
	/**
	 * Instantiate the renderer object if this flag is set
	 *
	 * @var int
	 */
	const		FLAG_RENDERER		=	1;
	/**
	 * Do something cool if this flag is set
	 *
	 * @var int
	 */
	const		FLAG_DO_COOL_STUFF	=	2;
	/**
	 * Do even more cool stuff if this flag is set
	 *
	 * @var int
	 */
	const		FLAG_EVEN_MORE_STUFF	=	4;

	/**
	 * Initializes this object
	 *
	 */
	public function init() {
		$this->setFlags();
		$this->processFlags();
	}

	/**
	 * Setting the flags according to parameters
	 *
	 */
	private function setFlags() {
		if(!empty($_GET['action'])) {
			switch($_GET['action']) {
				case 'createFoo':
					$this->flags |= self::FLAG_RENDERER;
					break;
				case 'saveFoo':
					$this->flags |= self::FLAG_RENDERER;
					$this->flags |= self::FLAG_DO_COOL_STUFF;
					break;
			}
		}
	}

	/**
	 * Instantiates objects by flags
	 *
	 */
	private function processFlags() {
		// instantiate renderer
		if(($this->flags & self::FLAG_RENDERER) > 0) {
			require_once(EXTENSION_LIBPATH . 'class.example_renderer.php');
			$this->renderer = example_renderer::getInstance();
			$this->renderer->init();
		}
		// do cool stuff
		if(($this->flags & self::FLAG_DO_COOL_STUFF) > 0) {
			require_once('./lib/class.cool_stuff_factory.php');
			$myCoolStuff = cool_stuff_factory::makeInstance();
			$myCoolStuff->save();
		}
		// do even more cool stuff
		if(($this->flags & self::FLAG_EVEN_MORE_STUFF) > 0) {
			require_once('./lib/class.even_more_stuff.php');
		}
	}
}

Als ich heute in der Firma saß wurden sämtliche Anwendungen, die auf meinem MacBook liefen, plötzlich ziemlich langsam. Doch welcher Prozess sorgte dafür?

Zu meiner Überraschung fand sich der Prozess kernel_task bezüglich seines CPU Appetits auf Platz Eins wieder. Wenn ich das ganze richtig verstanden habe ist kernel_task eine Zusammenfassung sämtlicher Kernelprozesse (inkl. derer von Kernel Extensions (.kext Dateien), welche als Thread dieses Prozesses laufen. Diese Prozesse werden also anders als etwa bei Linux und BSD zusammengefasst dargestellt. Wenn man auf der Suche nach der Ursache für den von mir beobachteten Leistungsabfall ist, stört das ganz ungemein, denn man kann z.B. nicht sofort erkennen ob das Problem etwa vom Kernel Modul für das verwendete Dateisystem herrührt.

Eine Google Suche offenbarte zwar diverse Foren- und Mailinglistenbeiträge, bei denen sehr ähnliche Probleme geschildert wurden, eine Lösung fand sich jedoch nicht. So blieb mir nur noch Raten. Da ich am Vortrag Virtualbox installiert habe, wodurch auch einige Kernelmodule mitinstalliert wurden, lag dort mein erster Verdacht. Also Virtualbox samt der Module mit dem mitgelieferten Shell (Bash?) -Skript deinstalliert. Die Module wurden sofort unloaded (hm, irgendwie fällt mir gerade kein sinnvolles, deutsches Wort dafür ein… entladen oder ausladen klingt doof) doch die Prozessor-Auslastung nahm nicht ab. Aus einem komplett anderen Grund habe ich später die Dateirechte Reparieren Funktion von Disk Util angehauen. Keine sofortige Veränderung. Irgendwann ausgeschaltet.

Als ich das MacBook gerade wieder eingeschaltet habe ist wieder alles super. Da ich zwischenzeitlich diverse Versuche mit anschließenden Neustarts (etwa PRAM reset) versucht habe, glaube ich, dass eine der beiden Aktionen etwas bewirkt hat. Sie waren das letzte, was ich gemacht habe. Irgendwie fände ich es logisch wenn es die erstere gewesen ist aber vielleicht war es ja auch einfach Magie

Mein System ist übrigens ein 10.5.6.

Renderer sind stets einmalig. Das Singleton Design Pattern bilded genau dies ab: Es wird lediglich eine einzige Instanz der Klasse erzeugt und zurückgegeben. Die folgende Klasse kann als Basis für die View-Schicht der eigenen TYPO3 Extension verwendet werden. Sie ist von pi_base abgeleitet und bietet so den gewohnten Funktionsumfang. Der Codeschnipsel stammt aus einer mini TYPO3 Extension, an der ich gerade privat bastel.

<?php
/***************************************************************
*  Copyright notice
*
*  (c) 2009 Thorsten Boock <thorsten (at) nerdcenter.de>
*  All rights reserved
*
*  This script is part of the TYPO3 project. The TYPO3 project is
*  free software; you can redistribute it and/or modify
*  it under the terms of the GNU General Public License as published by
*  the Free Software Foundation; either version 2 of the License, or
*  (at your option) any later version.
*
*  The GNU General Public License can be found at
*  http://www.gnu.org/copyleft/gpl.html.
*
*  This script is distributed in the hope that it will be useful,
*  but WITHOUT ANY WARRANTY; without even the implied warranty of
*  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
*  GNU General Public License for more details.
*
*  This copyright notice MUST APPEAR in all copies of the script!
***************************************************************/

require_once(PATH_tslib . 'class.tslib_pibase.php');

/**
 * Frontend Renderer
 * Till PHP 5.3 this class has to be declared as final because
 * we don't know the names of the classes extending this one.
 *
 * @author Thorsten Boock <thorsten (at) nerdcenter.de>
 */
final class tx_tbwhoisonline_renderer_fe extends tslib_pibase {
	/**
	 * Instance of this class (Singleton Design Pattern)
	 *
	 * @var tx_whoisonline_renderer_fe
	 */
	private static		$instance					=	null;
	/**
	 * Path to the template file used for rendering
	 *
	 * @var string
	 */
	private				$templateFile				=	'';
	/**
	 * The contents of the file $this->templateFile
	 *
	 * @var string
	 */
	private				$templateHTML				=	'';

	/**
	 * Empty constructor (Singleton Design Pattern)
	 *
	 */
	private function __construct() {

	}

	/**
	 * Empty clone function (Singleton Design Pattern)
	 *
	 */
	private function __clone() {

	}

	/**
	 * Instantiating this object (Singleton Design Pattern)
	 *
	 * @return tx_tbwhoisonline_renderer_fe
	 */
	public static function getInstance() {
		if(self::$instance == null) {
			self::$instance = new tx_tbwhoisonline_renderer_fe();
		}
		return self::$instance;
	}

	/**
	 * Initializing this object
	 *
	 * @param array $conf
	 */
	public function init($conf) {
		// init tslib_pibase
		$this->conf = $conf;
		$this->pi_setPiVarDefaults();
		$this->pi_loadLL();
		// get cObj instance and load template
 		$this->cObj = t3lib_div::makeInstance('tslib_cObj');
 		$this->templateHTML = $this->cObj->fileResource($this->templateFile);
		// override defaults with typoscript configuration
		foreach($this->conf as $key => $value) {
			$key = str_replace('.', '', $key);
			if(isset($this->$key)) {
				$this->$key = $value;
			}
		}
	}
}
?>

Mir sind gerade fast die Augen rausgefallen als ich bei einem Blick ins Error-Log des Apache Webservers unter Debian Etch abertausende Zeilen mit der Fehlermeldung "PHP Warning: Module ‘json’ already loaded in Unknown on line 0" sah. Jeder Seitenaufruf erzeugte diesen Fehler. Die installierten Pakete (php5-cgi + Module sowie apache2 + Module) entstammen dem offiziellen Debian Etch Repository, das Problem betrifft also wahrscheinlich auch noch viele weitere Systeme, bei denen nicht ständig ins Error-Log geschaut wird. Wahrscheinlich wird beim Start des php-cgi Prozesses noch eine andere Konfigurationsdatei als /etc/php5/cgi/php.ini, mit der Anweisung das Modul zu laden, ausgelesen.

Beheben lässt sich das Problem durch das Editieren von /etc/php5/cgi/php.ini. Dort die Zeile, die das json-Modul lädt, einfach auskommentieren und den Apache neustarten.