Der Vorteil liegt hier daran, dass bereits fast alle Komponenten von Zend mitgeliefert werden. So ist Out of the Box bereits Zend Data Cache, der Zend Debugger und Zend Optimizer+ installiert. Netterweise ist sogar das Zend Framework schon mit an Board.

Der Zend Server ist vorallem in Zusammenarbeit mit Zend Studio ein ziemlich mächtiges Entwicklerwerkzeug. Aber auch sonst bekommt man eine deutlich schönere Vorkonfiguration als bei XAMPP.

Der Zend Server arbeitet dabei mit dem Apache2 zusammen – unter Windows besteht auch die Möglichkeit ihn mit einem IIS laufen zu lassen.

Neben diesen Features liefert der Zend Server noch ein webbasiertes Konfigurationsinterface an. Dort lassen sich etwa PHP Erweiterungen per Klick aktivieren/deaktivieren, Direktiven in der php.ini setzen und die Zend Komponenten laden oder entladen.

Sehr schön ist dort auch der Logging Bereich, in dem man seine PHP Applikationen auf Errors und Warnings überwachen kann. Hier sind die Funktionen in der Community Edition gegenüber dem großen (kostenpflichtigen) Bruder recht beschränkt. Als Entwicklungsumgebung und für kleinere Projekte reicht die Community Edition aber durchaus aus.

Installation des Zend Servers CE
Für Debian werden bereits fertige Pakete von der Firma Zend selbst angeboten. Zur Installation führt man folgende hier Befehle aus:

wget http://repos.zend.com/deb/zend.key -O- | apt-key add -
deb http://repos.zend.com/zend-server/deb server non-free >> /etc/apt/sources.list
apt-get update
apt-get install zend-server-ce-php-5.3

Für Windows, Mac und andere Linux Distributionen kann man den Server hier herunterladen.

Die Public API reicht allerdings für die meisten Zwecke vollkommen, mit ihr kann man z. B. per Script die Sendung eines Pakets überwachen. Hier meine kleine, beispielhafte-Funktion:

function dhl_tracking($trackingnumber)
{
	$data  = '<?xml version="1.0" encoding="ISO-8859-1" ?>';
	$data .= '<data appname="nol-public" password="anfang" request="get-status-for-public-user" language-code="de">';
	$data .= '  <data piece-code="'.$trackingnumber.'"></data>';
	$data .= '</data>';

	// URL bauen und File hohlen
	$xml = simplexml_load_file(sprintf(
		'http://nolp.dhl.de/nextt-online-public/direct/nexttjlibpublicservlet?xml=%s', $data
	));

	// FALSE, wenn Syntax oder HTTP Error
	if ($xml === false) return false;

	// Wandelt das SimpleXML Objekt in ein Array um
	foreach ($xml->data->data->attributes() as $key => $value) {
		$return[$key] = (string) $value;
	}
	return $return;
}

// Aufruf der Funktion
print_r(dhl_tracking($tracking_number));

Sollte die Funktion false zurück liefern gab es einen Problem mit dem Tomcat Server und der Anfrage (etwa falscher Syntax, fehlerhaftes XML). Wenn piece-status einen anderen Wert als 0 enthält liegt ein Problem mit dem Datensatz selbst vor (z. B. keine Daten vorhanden).

Als Ergebnis erhält man dann ein Array, etwa mit folgenden Werten (hier etwas gekürzt, tatsächlich sind es einiges mehr an Infos):

Array
(
    [status] => Die Sendung wurde erfolgreich zugestellt.
    [recipient-id-text] => Nachbar
    [product-name] => DHL PAKET
    [pan-recipient-name] => SIMON LAUGER
)

Insbesondere für Shop-Betreiber, die ihren Kunden die Möglichkeit geben wollen in ihrem Shop den Status der Lieferung anzusehen sollte das recht interessant sein.

Doch gerade Basic und Diggest Authentifikation über Datenbanken ist so ein Fall, denn ich derzeit viel zu oft brauche. Um es kurz für andere festzuhalten, die eventuell auch mal in die Situation kommen: Das ganze zu implementieren sind effektiv ~5 Zeilen Code:

class Zend_Auth_Adapter_Http_Resolver_DbTable implements Zend_Auth_Adapter_Http_Resolver_Interface
{
	protected $_dbh = null;

	public function __construct(Zend_Db $dbh)
	{
		$this->_dbh = $dbh;
	}

	public function resolve($username, $realm)
	{
		$stmt = $this->_dbh->prepare(
			'SELECT password FROM users WHERE username = :username LIMIT 1'
		);
		$stmt->bindParam(':username', $username);
		$stmt->execute();

		// Gibt das Passwort des Users zurueck
		return $stmt->fetch(PDO::FETCH_OBJ)->password;
	}
}

Benutzt wird das ganze dann wie folgt:

$auth = new Zend_Auth_Adapter_Http(array(
	'accept_schemes'	=> 'basic',
	'realm'				=> 'area51'
));

// Unsere Helferklasse als Resolver für das Passwort einbinden.
// Als Parameter für __construct wird eine Zend_Db Instanz mit übergeben
$auth->setBasicResolver(
  new Zend_Auth_Adapter_Http_Resolver_DbTable(Zend_Db::factory($config))
);

// Benötigte Response und Request Klassen starten
$auth->setRequest($request = new Zend_Controller_Request_Http());
$auth->setResponse($response = new Zend_Controller_Response_Http());

// Die eigentliche Authentifikation
$result = $auth->authenticate();

// Erscheint beim klick auf "abbrechen"
if (!$result->isValid()) die("Try again!");

$response->sendResponse();

Das ganze funktioniert natürlich auch mit HTTP Digest. Da hier das Passwort aber verschlüsselt übertragen wird, muss eine Kleinigkeit angepasst werden:

public function resolve($username, $realm) {
	...
	// MD5 Hash von "benutzername:realm:passwort"
	return md5($username.':'.$realm.':'.$stmt->fetch(PDO::FETCH_OBJ)->password);
}

Auch die bekannte Bloggingsoftware WordPress enzieht sich dessen nicht. Auch in Zeiten von Glasfaserleitungen und Breitbandinternet ist es weiterhin wichtig, einen schnellen Seitenaufbau an den Tag zu legen, da mittlerweile auch Google im PageRank darauf wert legt.

In diesem Beitrag möchte ich euch einige einfache Tipps zur Verbesserung der Performance eures WordPress Blogs zeigen.

WordPress Template aufräumen
Eine Sache, die sich bei WordPress immer anbietet ist die header.php in den Templates soweit es geht statisch zu machen. Standardmäßig sieht der Code des Default Kubrick-Themes beispielsweiße so aus:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" <?php language_attributes(); ?>>
<head profile="http://gmpg.org/xfn/11">
<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />

Für die Usability ist das auch durchaus eine tolle Sache – man kann alles toll via GUI im Adminpanel anpassen. Allerdings kann man sich diese ganzen SQL-Queries auf die Datenbank auch sparen, denn eigentlich sollten sich Dinge wie der Seitentitel oder die Feed-URLs eh nicht ändern.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr">
<head profile="http://gmpg.org/xfn/11">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Das ganze macht man nun mit Seitentitel, RSS-URLs, Stylesheets und der Pingback URL.

Wenn man alles angepasst hat, sollte man pro Seitenarufruf mindestens 3 SQL-Queries weniger haben. Im Footer des Templates (footer.php) lässt sich das natürlich gleichermaßen anwenden. Auch dort wird der Titel des Blogs und die Feed URLs aus der Datenbank gehohlt.

WordPress wp_head() entschlacken
Nun kann man noch einige unnötige Sachen aus dem head-Bereich entfernen, welche durch WordPress automatisch hinzugefügt werden. Dazu fügt man diesen Code in der Datei functions.php in seinem Template (wp-content/themes/default/) ein.

remove_action('wp_head', 'wp_generator'); // WordPress Version nicht anzeigen
remove_action('wp_head', 'index_rel_link'); // Index Link deaktivieren
remove_action('wp_head', 'parent_post_rel_link', 10, 0); // Prev Link deaktivieren
remove_action('wp_head', 'start_post_rel_link', 10, 0); // Start Link deaktivieren
remove_action('wp_head', 'adjacent_posts_rel_link', 10, 0); // Und noch mehr davon...
remove_action( 'wp_head', 'wlwmanifest_link'); // Windows Live Writer Link deaktivieren
remove_action( 'wp_head', 'rsd_link'); // "Really Simple Discovery"-Service Link deaktivieren
remove_action('wp_head', 'post_comments_feed_link'); // Keinen Extra Feed für einzelne Artikel/deren Kommentare anzeigen

Die entsprechenden Hooks haben dabei folgende Aufgaben:

• wp_generator: Broadcasten der benutzen WordPress Verison
• post_rel_link: Hinzufügen unnötiger Links in den Head-Bereich
• wlwmanifest_link: Wird nur für den Windows Live Writer benötigt
• rsd_link: Really Simple Discovery Link
• post_comments_feed_link: Zusätzliche Feeds für die Kommentare zu einzelnen Posts

Caching Plugin installieren
Da man mit einem “normalen” Blog zu 95% statischen Content ausliefert, kann man sich nun noch ein Caching Plugin installieren. Das heißt die Seiten werden beim Aufruf nicht Live generiert, sondern es wurde vorher bereits eine statische Version von Ihnen abgespeichert.

Als Beispiele sind hier WP Cache oder WP Super Cache zu nennen (ich verwende letzteres).

Nachteil hier ist natürlich, dass beispielsweiße kann PHP-Code mehr in den Sidebars verwendet werden kann oder bestimmte Statistik-Plugins nicht mehr funktionieren. Dafür ist der Vorteil durch die gewonnene Geschwindigkeit deutlich größer.

Dabei möchte man es denn Übersetzern natürlich möglichst einfach gestalten und das Script so schreiben, dass eine weitere Sprache im Nachhinein im System einzupflegen einen möglichst geringen Aufwand bereitet.

Ansätze gibt es mehrere. Eine Möglichkeit ist die Sprachvariablen in ein Array auszulagern…

<?php

if (!is_array($lang) || empty($lang)) {
  $lang = array();
}

$lang = array_merge(
  'post_geloescht' => 'Dieser Eintrag wurde leider geloescht',
  'post_hinzufuegen' => 'Einen neuen Eintrag hinzufuegen',
);

?>

Und im Maincode dann beispielsweise…

<?php
// Natürlich ist dieser Code in echten Projekten tödlich für die Sicherheit
// Nur als Beispiel, es fehlen diverse Checks gegen Remote Inclusions

$user_lang = (isset($_SESSION['user_language']) && !empty($_SESSION['user_language'])) ? $_SESSION['user_language'] : '';

$user_lang = (!empty($user_lang) && is_file(dirname(__FILE__) . '/language/main_' . $user_lang . '.php')) ? $user_lang : 'de';

include_once dirname(__FILE__) . '/language/main_' . $user_lang . '.php';

echo $lang['post_geloescht']);

?>

Jeder Entwickler muss, sofern er eine neue Sprachvariable braucht, diese in zwei verschiedenen Teilen des Codes einfügen. Dann natürlich noch jeweils eine zusätzliche Änderung pro weiteres Sprachpaket – nicht allzu komfortabel. Zudem ist dieses Konzept auch noch recht fehleranfällig, insbesondere weil wir Programmierer ja meistens eher Schreibfaul sind.

Zusätzlich muss man den Fall absichern, dass ein Übersetzer ein Feld im Array komplett aus seiner Übersetzung vergessen hat.

Bei kleinen Projekten ist das alles durchaus akzeptabel. Problematisch wird es eher, wenn man mehrere hundert Variablen speichern muss.

Lokalisierung mit setlocale

Diese Methode wird bei diversen größeren quell offenen Scripten wie auch Beispielsweise WordPress verwandt.

Mit den gettext Tools kann automatisch ein Übersetzungstemplate generiert werden. Dieses kann man dem Übersetzungsteam bei jedem neuen Release einfach zusenden und fertig.

Eine schöne Sache ist dabei, dass man sich auch nicht mehr um einen Fallback kümmern muss. Falls ein Feld in der Sprachdatei nicht existiert oder im worst case das Sprachfile nicht gelesen werden kann wird der “Standard” (nicht übersetzte) Text ausgegeben.

Der größte Vorteil liegt jedoch darin, dass man, sofern man gettext von Anfang an in seine Scripte einpflegt, mit niedrigsten Aufwand eine Anwendung auch noch später lokalisieren kann – vielleicht ohne das dies Anfangs überhaupt geplant war.

<?php

setlocale(LC_ALL, 'de_DE'); // Sprache auf Deutsch stellen
bindtextdomain('messages', './locale'); // Pfad der Uebersetzungstabellen
textdomain('messages'); // Domain auswaehlen

echo _('Hello World'); // Beispiel Ausgabe (_() ist der Alias zu gettext())

?>

Aus diesem Code kann man sich nun mittels des folgenden Befehls ein Übersetzungstemplate generieren lassen:

root@localhost: xgettext index.php

Dieses File kann man nun seinen Übersetzern zukommen lassen. Wichtig ist hier vor allem, dass der der Zeichensatz angepasst wird. Fertig sieht das ganze etwa so aus:

# German Translation for MyProject
# Copyright (C) 2010 MyProject Translation Team
# This file is distributed under the same license as the MyProject package.
# Tom Riddle &gtn;foobar@example.com&ltn;, 2010.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: 1.0\n"
"Report-Msgid-Bugs-To: bugs@example.com\n"
"POT-Creation-Date: 2010-02-22 22:42+0100\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: Tom Riddle foobar@example.com\n"
"Language-Team: de_DE foo@li.org\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: index.php:14
msgid "Hello World"
msgstr "Hallo Welt"

Ist das geschafft muss das Template “kompiliert” werden, sprich in Maschinensprache übersetzt werden. Das geschieht mit diesem Befehl:

root@localhost: msgfmt -o messages.mo messages.po

Man erhält nun eine Datei messages.mo. Diese verschiebt man nach locale/de_DE/LC_MESSAGES/messages.mo.

Wenn man nun die Anwendung startet sollte “Hallo Welt” auf dem Schirm erscheinen. Gibt es irgendeinen Fehler, oder wurde das File nicht gefunden erscheint “Hello World.”

Alternative Tools für das bearbeiten der Sprachfiles

• PoEdit – Windows, Mac OS X and UNIX/Linux
• KBabel – Linux (KDE)

Weitere Infos gibt es in der PHP Doku auf den Seiten zu Gettext.

So wurden mit PHP 5.3 Beispielweise Namespaces und Late Static Bindings integriert. In PHP 6.0 werden überflüssige Funktionen wie register_globals, magic_quotes, register_long_arrays und der safe_mode abgeschafft, dafür gibt es einen vollständigen Unicode Support.

Leider kommt man bei diversen Linux Distributionen als PHP Entwickler immer nur mit recht viel Geduld zum Genuss der teilweise recht praktischen Neuerungen.
Deshalb gibt es die Möglichkeit PHP manuell aus dem Quellcode heraus zu installieren, bzw. sich selbst ein kleines .deb-Paket zu basteln.

Das ganze wurde auf einem Debian Lenny getestet, sollte sich aber mit kleineren Änderungen (ggf. andere Paketnamen bei den Abhängigkeiten) auch auf ähnliche Systeme wie Ubuntu übertragen lassen.

Vorarbeiten
Vor einer manuellen Installation sollten alle Pakete von PHP komplett entfernt werden.

apt-get --purge remove php5 php5-* libapache2-mod-php5

Der folgende Prozess erstellt ein “All-in-One” Paket, welches bereits alle zusätzlichen Erweiterungen (wie php5-curl, php5-mysql usw.) enthält.

Aufgrund dessen kann es eventuell zu mehren Abhänigkeitsproblemen bei Applikationen wie phpMyAdmin und anderen aus den Repositorys installieren Paketen kommen. Als Workaround kann man diese Pakete mit mittels –force Parameter installieren, oder aber sie einfach nur mehr komplett per Hand pflegen.

Bau des Paketes
Um PHP kompilieren zu können, werden für die Abhängigkeiten zunächst einige Pakete benötigt.

apt-get install gcc automake make checkinstall libjpeg62-dev libpng12-dev apache2-prefork-dev libbz2-dev libcurl4-openssl-dev libjpeg-dev libpng-dev libxpm-dev libxft-dev libt1-dev libgd2-xpm-dev libgmp3-dev libsasl2-dev freetds-dev libmysqlclient15-dev unixodbc-dev libpspell-dev librecode-dev libsnmp-dev libsqlite0-dev libtidy-dev libxslt1-dev x11proto-core-dev libxau-dev libpthread-stubs0 libpthread-stubs0-dev libxdmcp-dev libxcb1-dev libxcb-xlib0-dev x11proto-input-dev x11proto-kb-dev xtrans-dev libx11-dev libxpm-dev libexpat1-dev libfreetype6-dev pkg-config libfontconfig1-dev apache2-mpm-prefork apache2-utils apache2.2-common comerr-dev libapr1 libapr1-dev libaprutil1 libaprutil1-dev libaspell-dev freetds-common libdb4.6-dev libgmpxx4ldbl libice-dev libidn11-dev libkadm55 libkrb5-dev libldap2-dev libodbcinstq1c2 libpcre3-dev libpq-dev libsensors-dev libsm-dev libsnmp-perl libsqlite3-dev libssl-dev libsybdb5 libt1-5 libtidy-0.99-0 libwrap0-dev libxaw7-dev libxaw7-dev libxext-dev libxmu-dev libxmu-headers libxrender-dev libxt-dev uuid-dev x11proto-render-dev x11proto-xext-dev libmcrypt4 libmcrypt-dev libmhash-dev

Zusätzlich, wenn PHP6 installiert wird ist noch das folgende Paket von nöten:

apt-get install libicu-dev

Nun kann man den Sourcecode von PHP 5.3 herunterladen und entpacken.

cd /usr/src && wget http://de3.php.net/get/php-5.3.0.tar.gz/from/de.php.net/mirror
tar xf php-5.3.0.tar.gz && cd php-5.3.0

Bzw. wenn man PHP 6.0 aus den täglichen Snapshots installieren möchte:

cd /usr/src && wget http://snaps.php.net/php6.0-latest.tar.gz
tar xf php6.0-latest.tar.gz && cd php6.0-*/

Nun ist es Zeit für das configure Script. Für PHP 5.3 führt man hier folgendes aus:

./configure --prefix=/usr --with-apxs2=/usr/bin/apxs2 --with-config-file-path=/etc/php5/apache2 --with-config-file-scan-dir=/etc/php5/apache2/conf.d --mandir=/usr/share/man --disable-debug --with-regex=php --disable-rpath --disable-static --with-pic --with-layout=GNU --with-pear=/usr/share/php --enable-calendar --enable-sysvsem --enable-sysvshm --enable-sysvmsg --enable-bcmath --with-bz2 --enable-ctype --with-db4 --without-gdbm --with-iconv --enable-exif --enable-ftp --with-gettext --enable-mbstring --with-pcre-regex=/usr --enable-shmop --enable-sockets --enable-wddx --with-libxml-dir=/usr --with-zlib --with-kerberos=/usr --with-openssl=/usr --enable-soap --enable-zip --with-exec-dir=/usr/lib/php5/libexec --without-mm --with-curl=shared,/usr --with-zlib-dir=/usr --with-gd=shared,/usr --enable-gd-native-ttf --with-gmp=shared,/usr --with-jpeg-dir=shared,/usr --with-xpm-dir=shared,/usr/X11R6 --with-png-dir=shared,/usr --with-freetype-dir=shared,/usr --with-t1lib=shared,/usr --with-ldap=shared,/usr --with-ldap-sasl=/usr --with-mhash=shared,/usr --with-mysql=shared,/usr --with-mysqli=shared,/usr/bin/mysql_config --with-pspell=shared,/usr --with-unixODBC=shared,/usr --with-xsl=shared,/usr --with-snmp=shared,/usr --with-sqlite=shared,/usr --with-mssql=shared,/usr --with-tidy=shared,/usr --with-xmlrpc=shared --with-pgsql=shared,/usr --enable-gd-native-ttf --enable-dba=shared --with-openssl-dir=shared,/usr --enable-gd-jis-conv --enable-json --with-mcrypt=shared,/usr --enable-pcntl --with-pdo-mysql --with-pdo-odbc=unixODBC,/usr --with-pdo-pgsql=shared,/usr --with-pdo-sqlite --enable-xmlreader --with-tsrm-pthreads

Für PHP 6.0, mit minimalen Änderungen:

./configure --prefix=/usr --with-apxs2=/usr/bin/apxs2 --with-config-file-path=/etc/php6/apache2 --with-config-file-scan-dir=/etc/php6/apache2/conf.d --mandir=/usr/share/man --disable-debug --with-regex=php --disable-rpath --disable-static --with-pic --with-layout=GNU --enable-calendar --enable-sysvsem --enable-sysvshm --enable-sysvmsg --enable-bcmath --with-bz2 --enable-ctype --with-db4 --without-gdbm --with-iconv --enable-exif --enable-ftp --with-gettext --enable-mbstring --with-pcre-regex=/usr --enable-shmop --enable-sockets --enable-wddx --with-libxml-dir=/usr --with-zlib --with-kerberos=/usr --with-openssl=/usr --enable-soap --enable-zip --libexecdir=/usr/lib/php6/libexec --without-mm --with-curl=shared,/usr --with-zlib-dir=/usr --with-gd --enable-gd-native-ttf --with-gmp=shared,/usr --with-jpeg-dir=shared,/usr --with-xpm-dir=shared,/usr/X11R6 --with-png-dir=shared,/usr --with-freetype-dir=shared,/usr --with-t1lib=shared,/usr --with-ldap=shared,/usr --with-ldap-sasl=/usr --with-mhash=shared,/usr --with-mysql=shared,/usr --with-mysqli=shared,/usr/bin/mysql_config --with-pspell=shared,/usr --with-unixODBC=shared,/usr --with-xsl=shared,/usr --with-snmp=shared,/usr --with-sqlite=shared,/usr --enable-sqlite-utf8 --with-mssql=shared,/usr --with-tidy=shared,/usr --with-xmlrpc=shared --with-pgsql=shared,/usr --enable-gd-native-ttf --with-icu-dir=/usr --enable-dba=shared --with-openssl-dir=shared,/usr --enable-gd-jis-conv --enable-json --with-mcrypt=shared,/usr --enable-pcntl --with-pdo-mysql --with-pdo-odbc=unixODBC,/usr --with-pdo-pgsql=shared,/usr --with-pdo-sqlite --enable-xmlreader --with-tsrm-pthreads

Jetzt kann man den make Befehl ausführen. Hat man einen Dualcore/Quadcore Prozessor, kann man den Prozess mittels dem Parameter -jX (X für die Anzahl an Kernen) beschleunigen.

make -j2

Um im letzten Schritt das Debian Paket zu erstellen, gibt man für PHP 5.3 den folgenden Befehl ein:

checkinstall -D --install=no --fstrans=no --maintainer=root@example.org --reset-uids=yes --nodoc --pkgname=php5 --pkgversion=5.3.0 --pkgrelease=`date +%Y%m%d%H%M` --arch=amd64

Oder für Version 6.0:

sudo checkinstall -D --install=no --fstrans=no --maintainer=root@example.org --reset-uids=yes --nodoc --pkgname=php6 --pkgversion=6.0.0-dev --pkgrelease=`date +%Y%m%d%H%M` --arch=amd64

Sollte man kein 64 Bit Debian/Ubuntu betreiben, so muss man –arch=amd64 entsprechend anpassen (auf i386, i486 oder i586 usw.). Der Switch –maintainer sollte auch noch an die eigene E-Mail Adresse angepasst werden.

checkinstall frägt auch noch nach einer Beschreibung des Paketes und zusätzlichen Infos. Dies kann man aber alles getrost ignorieren und mit Enter bestätigen.

Fehler bei checkinstall
Bricht checkinstall mit einem Fehler ala “Error: At least one `LoadModule’ directive already has to exist…”, liegt das daran, dass die httpd.conf des Apache2 Webservers leer ist. Hier gibt es einen kleinen Workaround:

echo "#LoadModule directive to aid module installations" >> /etc/apache2/httpd.conf
echo "#LoadModule dummy_module /usr/lib/apache2/modules/mod_dummy.so" >> /etc/apache2/httpd.conf

Anschließend checkinstall erneut ausführen.

Installation und Test
Ist der Prozess abgeschlossen befindet sich im aktuellen Verzeichnis ein Paket, welches man wie folgt installieren kann:

dpkg -i *.deb

Um zu testen ob PHP korrekt installiert wurde kann man in der Shell den Befehl “php -v” ausführen. Angezeigt werden sollte die entsprechende Version und das Build Datum, z. B. “PHP 5.3.0 (cli) (built: Sep 23 2009 00:00:00)”.

Hier ein Video von der Website des Entwicklers, das die Funktionalität von Kon-Boot auf einem Debian Linux demonstriert (vermutlich ein Etch):

Das System wird mittels der KonBoot Live Disc gestartet und normal gebootet. Beim Login Prompt gibt man einfach den Usernamen “kon-usr” ein und hat direkt Root-Zugriff. Hilfreich wenn beispielsweise ein Passwort für den GRUB Bootloader vergeben wurde und so ein init=/bin/bash nicht direkt klappt.

Bei einem Windows System entfällt das Login Prompt komplett und man landet ohne weiteres mucksen direkt auf dem Desktop, natürlich als Administrator.

Kon-Boot unterstützt, wie schon angesprochen viele Systeme von Windows Server 2008 über Windows XP bis hin zu Windows 7 und nahezu alle verfügbaren Linux Distributionen. Leider ausschließlich 32 Bit Systeme.

Was mich absolut an diesem Programm fasziniert ist die Einfachheit. CD einlegen und fertig. Mehr ist nicht zu tun. Schützen kann man sich dagegen nicht wirklich. Der einzige wirksame Schutz, und das gilt sowieso generell: Die wichtigen und privaten Daten verschlüsseln (z. B. mittels DM-Crypt oder TrueCrypt).

Herunterladen kann man das ganze auf piotrbania.com, wahlweiße als Disketten-Image oder CD.

Firefox hat ein seltsames Phänomen: Bei einem eingestellten SOCKS5-Proxy löst Firefox die IP-Adressen nicht standardmäßig über die DNS-Server des Remote-Hosts auf, sondern benutzt zuerst einmal die DNS-Server des Providers.

In meinem Fall wären das die T-Online DNS-Server – aber wer will heute denn noch die DNS-Server von Zensurprovidern benutzen?

Dies ganze lässt sich glücklicherweiße sehr einfach fixen. In der about:config des Firefox stellt man die Konfigurationsvariable proxy.socks_remote_dns auf true.

network.proxy.socks_remote_dns = true
network.http.sendRefererHeader = 0

sendRefererHeader auf 0 zu stellen empfiehlt sich zusätzlich für diejenigen, die den Webmastern nicht preisgeben wollen, wonach sie soeben bei Google gesucht haben, oder über welchen Link sie auf eine Webseite gelangt sind.

Ein weiteres Problem ist das Prefetching im Firefox. Link-Prefetching ist eine Technologie, mit der verlinkte Webseiten schon im Voraus geladen werden. Diese wird zum Beispiel schon bei Google verwandt, um gesuchte Seiten im Hintergrund schon einmal vorzuladen.

Das Problem dabei ist: so erscheint man in den Logs diverser Webserver, obwohl man die Seiten eigentlich niemals selbst angesurft hat. Auch das lässt sich mit dem Umstellen der Konfigurationsvariable beheben.

network.prefetch-next = false

Und schon sollte das Problem gelöst sein.

Auf der Enwicklerseite wird CopSSH folgendermaßen beschrieben:

Copssh is an ssh server and client implementation for windows systems. It is a yet another packaging of portable openssh, cygwin, some popular utilites, plus implementation of some best practices regarding security. You can use copssh for remote administration of your systems or gathering remote information in a secure way.

Damit CopSSH ist quasi die “One-Click”-Variante um einen SSH Server unter Windows bereitzustellen. Dabei hat man dann alle Vorteile von einer Linuxartigen Umgebung.

Download
CopSSH kann man sich von dieser Seite herunterladen. Das ganze Paket ist dabei circa 5 MB groß.

Konfiguration
Die Konfiguration des SSHDs geschieht durch eine grafische Oberfläche und ist so recht selbsterklärend. Im Startmenü unter CopSSH ruft man dazu den Menüpunkt “Activate a user” auf.

Auf der linken Seite des Konfigurationsassistenten legt man einen lokalen Systembenutzer fest, auf der rechten weißt man diesen einen speziellen SSH-Zugang zu.

Dabei kann man entscheiden, ob der User eine normale Shell auf dem System erhalten soll, oder ledeglich ein Login via SCP/SFTP möglich ist.

Selektiert man die Option “Create keys for public key authentification” wird man auf der nächsten Seite nach einer Passphrase für den Key gefragt. Ein erneutes weiter meldet, dass der User nun aktiviert ist.

Verbindung lokal testen
Nun kann man testen ob die Verbindung mit dem angelegten Benutzer funktioniert. Im Startmenü unter CopSSH findet man den Menüpunkt “Start a Unix BASH Shell”. Diese öffnet man nun und gibt diesen Befehl ein:

ssh "Mein Benutzername"@127.0.0.1

Wobei “Mein Benutzername” natürlich für den lokalen Windows User steht.

Fazit
CopSSH ist eine wirklich geniale, einfache und vorallem schnelle Möglichkeit einen SSHD unter Windows aufzusetzen und per Remote sein Windows-System zu administrieren. Ich bin auf jedenfall absolut davon begeistert.

Außerdem bin ich mittlerweile ein echter Fan des CopSSH SSH-Clients geworden, man kann damit einfach schneller arbeiten als mit PuTTY etc. Sowas hatte ich unter Windows lange Zeit vermisst.

Weitere Infos gibt es auf der Seite des Entwicklers.

http://www.itefix.no/i2/copssh

Der Bug mit open_basedir und den Plugininstallationen von dem ich vor kurzem geschrieben hatte besteht leider auch in WordPress 2.8 weiter.

Ich habe dieses mal einen kleinen Plugin Patch geschrieben. Einziges Problem: Für den Plugin Patch wird die Zend Extension APD (Advanced PHP Debugger) benötigt, denn PHP unterstützt standardmäßig kein Überladen von Funktionen.

Infos über APD erhält man unter den folgenden Links:

• http://pecl.php.net/package/apd
• http://de.php.net/manual/de/ref.apd.php

Installation
Zur Installation des Plugins muss dieses ledeglich ins Plugin Verzeichnis verschoben werden und dann ganz normal via Admininterface aktiviert werden.

Meldet das Interface “Das Plugin kann nicht aktiviert werden, da es einen fatalen Fehler erzeugt. Fatal error: Call to undefined function rename_function()”, so ist die Extension APD nicht vorhanden und es muss auf den manuellen Patch zurückgegriffen werden.

Download
Plugin für WordPress 2.7 und höher
wp-2.8-open_basedir.txt.gz (8 kb)

Gepatchte Datei für WordPress 2.8
wp-2.8-file.txt.gz (1 kb)