Ab sofort betreiben wir ein Debian Software Repository, das unter anderem SilverStripe als Debian- bzw. Ubuntu-Paket enthält. Die URL des Repositories lautet: http://repos.echostudios.ch/debian
Bevor Pakete aus unserem Repository installiert werden können, muss zuerst noch der Public Key zum APT Keyring hinzugefügt werden.
Wie das alles im Detail funktioniert wird unter dem folgenden Link beschrieben: SilverStripe Debian Packet installieren
Um seine Serversysteme ständig auf einem sicheren Stand zu halten, sind regelmässige updates unerlässlich. Paketmanagement-Software wie APT bei Debian (oder Debian-basierenden Systemen wie Ubuntu) erleichtert diese Aufgabe ungemein. Wenn man jedoch Updates nicht automatisch installieren lassen will (was mit gewissen Risiken verbunden ist und ein System unbootbar machen kann), ist es nützlich darüber informiert zu werden, sobald Updates verfügbar sind.
Nagios ist eine hervorragende Überwachungssoftware für lokale und remote Systeme. Es erlaubt eine komfortable Überwachung diverser Hosts und Dienste wie z.B. SSH, POP, SMTP, etc. Des weiteren ist es sehr einfach, Erweiterungen für Nagios, sogenannte Plugins, selber zu schreiben.
Basierend auf der Idee von nagios apt watch habe ich ein Python-Plugin für Nagios geschrieben, das überprüft, ob Paketupdates verfügbar sind.
Im Unterschied zu nagios apt watch wurden einige Verbesserungen vorgenommen:
Die Installation und Bedienung des Plugins sind fast identisch mit nagios apt watch, weshalb ich zur Installation gerne auf folgende Anleitung verlinke: Nagios apt watch installieren
Zum Betrieb werden python-apt und python-argparse benötigt. Zur Ausführung auf remote Systemen empfehle ich NRPE.
Um die zusätzlichen Optionen des Plugins anzuzeigen, ruft man es einfach mit der Option -h auf:
python nagios-apt-check.py -h
Nagios APT Check steht unter der BSD-Lizenz
Auf der Suche nach einem Syntax Highlighting Modul für SilverStripe bin ich auf Pastie gestossen. Pastie ist ein Modul, das unter anderem den populären GeShi Syntax Highlighter wrappt und nahtlos in SilverStripe integriert.
Da ich zu doof war, eine Downloadmöglichkeit auf der Pastie-Website zu finden, ist es mir nur gelungen, den Code über git auszuchecken (direkt im SilverStripe Wurzelordner):
git clone https://github.com/hamishcampbell/silverstripe-pastie.git pastie
Danach ruft man (wie üblich) http://example.com/dev/build auf, um das Modul zu installieren und die notwendigen Tabellen in der Datenbank zu erstellen.
Im Prinzip wars das eigentlich schon. Nun kann man im Content Editor beliebiger Seiten z.B. folgenden Shortcode einfügen:
[code lang='bash']echo 123[/bash]
Selbstverständlich ist auch Code anderer Sprachen möglich, wobei so viele Sprachen unterstützt werden, dass ich sie gar nicht hier aufzählen kann. Eine vollständige Liste ist auf der GeShi-Website zu finden.
Beim Einfügen von PHP-Code ist mir ein kleiner Bug in Pastie aufgefallen: Wenn man Zeichen verwendet, die zur Ausgabe in HTML normalerweise escaped werden (z.B. < und >), werden diese doppelt escaped (es wird z.B. < statt < im Quellcode angezeigt). Besonders bei PHP, wo "<?php" der Beginn eines zu interpretierenden Blocks darstellt, ist das natürlich besonders nervig.
Die Problemstelle war dann auch relativ schnell gefunden: Es handelt sich um die Datei pastie/code/PastieSnippet.php . Am Anfang der Funktion "shortcode_handler" fügt man nach dem
$content = str_replace('<br/>',"\n", $content);
einfach folgende Zeile ein:
$content = html_entity_decode($content);
Wer zu faul ist, dies selber zu erledigen, findet den Patch unter dem folgenden Link: Pastie Decode Patch
Mit Freude dürfen wir bekannt geben, dass Version 0.1b von pyTesseract ab sofort frei verfügbar ist.
pyTesseract ist eine native Python-Anbindung an die exzellente OCR-Engine Tesseract und ermöglicht es Python-Entwicklern, diese einfach und nahtlos in die eigenen Apps zu integrieren.
Happy coding!
Wer schon einmal mit Debian oder einem Derivat davon wie z.B. Ubuntu gearbeitet hat, wird direkt oder indirekt schon einmal mit dem Paketverwaltungssystem Dpkg oder dem dazugehörigen Frontend APT in Kontakt gekommen sein. Für Systemadministratoren ist Packetmanagement ein Segen: sie erlauben einem mit wenig Aufwand, die installierte Software aktuell zu halten und vor allem aktuelle Sicherheitsupdates schnell einzuspielen.
Da insbesondere Web-Applikationen für Sicherheitslücken wie SQL Injections prädestiniert sind, ist es unabdingbar, auftretende Sicherheitslöcher schnellstmöglich durch Softwareupdates zu stopfen.
Dieses kleine HOWTO zeigt eine einfache Konfiguration einer WordPress-Applikation auf einem Debian-Host, wenn lighttpd als Webserver eingesetzt wird.
Ich gehe von folgender Konfiguration aus:
Falls diese Voraussetzungen nicht gegeben sind, befindet sich unter dem folgenden Link ein HOWTO, wie sie dies unter Debian Lenny erreichen können: PHP5 und MySQL in Lighttpd unter Debian 5.0
Im folgenden wird davon ausgegangen, dass ein Blog für die Domain blog.example.com erstellt wird und dass das Wurzelverzeichnis des Blogs in /var/www/blog.example.com liegen soll. Selbstverständlich müssen diese Angaben für jede Installation angepasst werden.
apt-get install -t testing wordpress
Ein “dpkg -L” verrät, dass sich WordPress nach /usr/share/wordpress und /etc/wordpress installiert hat. Dabei enthält /usr/share/wordpress den PHP-Code und /etc/wordpress die Konfigurationsdatei bzw. die Konfigurationsdateien, falls mehrere Blogs installiert werden sollen.
Nun erstellen wir einen symbolischen Link nach /usr/share/wordpress an dem Ort, wo später das Wurzelverzeichnis unseres Blogs liegen soll, wie folgt:
ln -s /usr/share/wordpress /var/www/blog.example.com
Die Debian’sche WordPress-Konfiguration unterscheidet sich geringfügig von der normalen WordPress Konfiguration. Da Sie wie oben schon angetönt für die Installation mehrerer Blogs gedacht ist, sucht WordPress anhand des Domainnamens in /etc/wordpress nach einer passenden Konfigurationsdatei für den aufgerufenen Blog. Im Klartext heisst das, die Konfigurationsdatei für unser Beispiel muss in /etc/wordpress/config-blog.example.com.php abgespeichert werden.
Über die WordPress-spezifische Konfiguration für Datenbank, Sprache etc. soll an dieser Stelle nicht genauer eingegangen werden. Eine gute Übersicht ist unter dem folgenden Link zu finden: WordPress Konfiguration
Eine Beispielkonfiguration könnte wie folgt aussehen (die SALTs und KEYs müssen unbedingt vor einer Installation angepasst werden, ansonsten wird die Sicherheit beeinträchtigt!):
<?php
/** The name of the database for WordPress */
define('DB_NAME', 'exampleblog');
/** MySQL database username */
define('DB_USER', 'exampleblog');
/** MySQL database password */
define('DB_PASSWORD', 'neHkpkEu3LpF');
/** MySQL hostname */
define('DB_HOST', 'localhost');
/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');
/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');
/**#@+
* Authentication Unique Keys and Salts.
*
* Change these to different unique phrases!
* You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
* You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
*
* @since 2.6.0
*/
define('AUTH_KEY', 'GVxU?`)aD]G4fPePb9JNa[IPo{Rj5l9C +g~z|(-7:rgBtwvO?`4~(4wS8QhSfdG');
define('SECURE_AUTH_KEY', '#`GWGET(+2CausH>}W(V*2j;,DddjFKLtCm>#wmkal|3r@57~1feSVJ`s8*U}+.W');
define('LOGGED_IN_KEY', '2jOLmK3;svT8j!lt?Ohe)|ZJq[R[[h9T9wW<!gNA?@QqNfaH&|{XsJn$Rh<x>Tkg');
define('NONCE_KEY', 'bi+$JxRDEF]}kg$el{$+d^Yip6:26e](dxD?AKMHep}3++|KQlub-bTL*{qN#wFS');
define('AUTH_SALT', '6R,.?^|5)(.9J +EGQ}V*M.CkuNb.&J2-OT]5hK#M,]c%E=$<UuJ{^z.p;xj-mKC');
define('SECURE_AUTH_SALT', '6<BHa,bEmZAcHAa1_~p0$wzeTT{t#~9PF3|5,{<<o|>S?7|}/F1|^GG(z{H~%+uC');
define('LOGGED_IN_SALT', 'A?2Z9^&42W6%l.ZKuG&/[=xJAp$@Q[</]-N|8|wr$[sai-AFi6EbAy=8zC_j<1Ru');
define('NONCE_SALT', '4;5O%~WP7nHbIA21-tg+Rwr-BGB!$c2mY]!+8WzBKz|HY[!1||-vLK)bi059%T06');
/**
* WordPress Database Table prefix.*/
$table_prefix = 'wp_';
/**
* WordPress Localized Language, defaults to English.
*/
define ('WPLANG', 'de_DE');
/**
* For developers: WordPress debugging mode.
*/
define('WP_DEBUG', false);
?>
Bisher haben wir ein installiertes und konfiguriertes WordPress, das jedoch noch nicht übers Web erreichbar ist. Um letzteren Umstand zu beheben muss noch eine Konfigurationsdatei für lighttpd erstellt werden. Dazu erstellen wir die Datei /etc/lighttpd/conf-enabled/blog.example.com.conf und füllen sie mit dem folgenden Inhalt:
$HTTP["host"] == "blog.example.com" {
server.document-root = "/var/www/blog.example.com"
url.rewrite-once = (
"^/(xmlrpc\.php|robots\.txt|index\.php|sitemap\.xml|wp-.*)" => "$0",
"^/(.*)$" => "/index.php/$1"
)
}
Besondere Aufmerksamkeit ist hier den rewrite-rules zu schenken. Diese sorgen dafür, dass die Permalinks schön aussehen dürfen und weitere wichtige Dateien wie xmlrpc.php oder robots.txt etc. trotzdem erreichbar bleiben.
Mit einem
/etc/init.d/lighttpd restart
wird lighttpd neu gestartet und der Blog ist nun unter blog.example.com erreichbar.
Wir verfügen nun über eine WordPress-Installation, welche einfach durch weitere Blogs zu erweitern ist (einfach die letzten beiden Kapitel für jeden weiteren Blog wiederholen) und einfach über
apt-get update && apt-get upgrade
aktualisiert wird, sofern Aktualisierungen verfügbar sind. Komfortabel, oder nicht?