php-sqlite unter Enterprise Linux

Die Tage hatte ich das Problem, dass eine SQLite-Anwendung auf einem Enterprise Linux-System installiert werden sollte. “Nichts leichter als das“, dachte ich mir und suchte in der Paketverwaltung nach “php-sqlite” – den Paketnamen hatte ich noch von meinem letzten SQLite-Experiment unter Debian in Erinnerung. Dummerweise gibt es ein solches Paket nicht für CentOS oder dergleichen.

Auch in zusätzlichen Repositories, wie ELRepo oder Repoforge, bin ich nicht fündig geworden. Also blieb nur eine händische Kompilation..

Wichtig ist, dass neben PHP und SQLite auch das PHP-Entwicklungspaket sowie der PHP-PDO Treiber und einige Entwicklertools installiert sind:

# yum install httpd php sqlite php-devel make gcc php-pdo

Für die installierte Version von PHP muss nun der Quellcode bezogen werden. Zum Zeitpunkt der Erstellung dieses Artikels war das bei CentOS und RedHat 6.3 die Version 5.3.3. Verifzieren lässt sich das Ganze recht einfach mittels YUM:

# yum info php | grep Version
Version     : 5.3.3

Der Download erfolgt dann über das alte Downloadarchiv von PHP – der Tarball wird anschließend entpackt. Im extrahierten Ordner befindet sich für das SQLite-Modul ein Ordner unterhalb “ext/sqlite“. In diesem Ordner wird das Tools phpize ausgeführt und das Modul letztendlich übersetzt und installiert:

# cd /usr/src
# wget http://museum.php.net/php5/php-5.3.3.tar.gz
# tar xvfz php-5.3.3.tar.gz
# cd php-5.3.3/ext/sqlite
# phpize
# ./configure
# make
# make install

Für das neue Modul wird anschließend eine Konfigurationsdatei erstellt und der Apache-Dienst neugestartet. Wer sicher gehen will, dass das neue Modul auch tatsächlich verwendet wird, kann ein kleines PHP-Skript “test.php” basteln, dass die Konfiguration von PHP ausgibt.

# echo 'extension=sqlite.so' > /etc/php.d/sqlite.ini
# service httpd restart
# echo '<?php phpinfo(); ?>" > /var/www/html/test.php

Auf der genertierten Webseite sollte es nun unter anderem die Abschnitte “pdo_sqlite” und “SQLite” geben:

phpinfo() nach SQLite-Installation

phpinfo() nach SQLite-Installation

Ist dies der Fall, scheint das Modul zu funktionieren. :)

Wer möchte, kann mit dem folgenden Skript eine kleine SQLite-Datenbank aufbauen und testen – dazu muss unterhalb /var/www/html ein Ordner db existieren, der volle Schreibrechte hat:

# cd /var/www/html
# mkdir db
# chmod 777 db
# vi test_sqlite.php
<?php
//Verbindung herstellen
try { $database = new SQLiteDatabase('db/test.sqlite', 0666, $error_msg); }
catch(Exception $e) { die($error_msg); }
//Dummy-Tabelle erstellen
$query = 'CREATE TABLE Test ' .
        '(vorname TEXT, nachname TEXT)';
if(!$database->queryExec($query, $error_msg)) { die($error_msg); }
//Eintrag vornehmen
$query = "INSERT INTO Test(vorname, nachname) VALUES ('Max', 'Mustermann')";
if(!$database->queryExec($query, $error_msg)) { die($error); }
?>

Nach Ausführung des Skriptes über den Webbrowser existiert unterhalb des Ordners db eine Datei, deren Inhalt man ansatzweise mit strings auslesen kann:

# strings db/test.sqlite
** This file contains an SQLite 2.1 database **
Htable
Test
Test
CREATE TABLE Test (vorname TEXT, nachname TEXT)
Mustermann

…und schon klappt’s auch mit SQLite unter PHP auf Enterprise Linux. :)

Kurztipp: URL eines WordPress-Auftritts ändern

Wer Webseiten mit WordPress implementiert, arbeitet vielleicht auch mit einer geschlossenen Testumgebung und exportiert gelegentlich den aktuellen Stand der Webseite auf einen öffentlichen Server, um diesen mit dem Kunden zu besprechen.

Mit dem Kopieren der Datenbank inklusive Inhalte und des WordPress-Ordners ist es allerdings noch nicht getan – WordPress vermerkt die URL in der Regel auch in der MySQL-Datenbank.

Eigentlich sollte es auch genügen, zwei Variablen in der wp-config.php anzupassen – bei mir half das schon einige Male nicht, weswegen ich immer den Datenbank-Wert und die Variablen in der wp-config.php anpasse, um die Seitenurl zu ändern:

mysql> UPDATE wp_options SET option_value='http://NEUE-URL' WHERE option_name='siteurl';
...
# vi wp-config.php
define('WP_HOME','http://NEUE-URL');
define('WP_SITEURL','http://NEUE-URL');

Unglücklicherweise befinden sich in der Posts-Tabelle auch absolute Dateipfade – im Test funktionierte die Umstellung bei mir nach Anpassen der wp-config.php wie oben erwähnt.

Danke an Dirk für den Hinweis!

Meine Top-5 der Dokuwiki-Plugins

DokuWiki ist eine schlanke und sehr smarte Wiki-Software – ich selbst habe vor einigen Jahren mein (Media)Wiki komplett auf DokuWiki umgestellt und habe den Schritt seither nicht bereut. Wer eine simple und einfach zu administrierende Wiki-Software sucht, wird (meiner persönlichen Meinung nach) mit DokuWiki glücklicher sein als mit MediaWiki.

Für DokuWiki gibt es zahlreiche Plugins, von denen ich euch heute 5 präsentiere, die – meiner Meinung nach – absolut empfehlenswert sind:

 

Note

Das Note-Plugin wird dazu verwendet, Hinweise in Artikeln deutlich durch passende Boxen zu kennzeichen. Man unterscheidet zwischen Hinweisen, Tips und Warnungen. Die Umsetzung im Artikel ist wirklich einfach – anbei ein Beispiel und dessen Code:

plugin:notes

plugin:notes

<note>Das ist eine Notiz</note>
<note tip>Das ist ein nützlicher Hinweis</note>
<note important>Vorsicht - hier sollte man aufpassen!</note>
<note warning>Warnung - bitte beachten, sonst gibt's ggf. Probleme!</note>

Installationshinweise sind der offiziellen DokuWiki-Internetpräsenz zu entnehmen.

 

Imagereference

Wer schon einmal MediaWiki benutzt hat, kennt die Funktion, Bilder dynamisch verkleinert in einem Artikel einzubinden – beispielsweise in einer Schritt-für-Schritt-Anleitung. Diese Funktion gibt es so leider nicht unter DokuWiki – macht aber nichts ,denn dafür gibt es das o.g. Plugin.

Ein Bild lässt sich mithilfe des folgenden Codes beispielsweise rechts als Miniatur einbinden:

====Oracle-Benutzer====
{{ DATEINAME.JPG?100|Kurzbeschreibung des Bildes}}
Icinga benötigt einen dedizierten Datenbank-Benutzer...
plugin:imagereference

plugin:imagereference

Weitere Details sind auf der DokuWiki-Webseite einsehbar.

 

Redirect

Das Verschieben von Inhalten bleibt bei der Pflege eines Wikis nicht aus. Oftmals kristallisieren sich erst im Nachhinein brilliante Ideen, wie Inhalte besser strukturiert werden können und so müssen die Inhalte neu aufgeteilt werden. Doof ist dann, wenn man den Artikel auf anderen Webseiten verlinkt hat – dann werden die Inhalte an der alten Stelle natürlich nicht mehr gefunden.

Hierfür gibt es das Redirect-Plugin – man kann ganz leicht in einer zentralen Datei Weiterleitungen definieren:

alte_kategorie:alter_artikel neue_kategorie:neuer_artikel

Ideal, wenn man seine Besucher nicht mit klassischen 404-Fehlern verärgern möchte. Nicht jeder hat bei einer schnellen Recherche Lust, Suchfunktionen zu verwenden. ;)

Mehr Informationen über dieses Plugin gibt es auf der DokuWiki-Internetpräsenz.

 

OpenOffice.org Export

Mithilfe des ODT-Plugins können Seiteninhalte dynamisch in ODT-Dokumente konvertiert werden – ideal, wenn man einen Artikel “druckoptimiert” zu Papier bringen möchte. Hierfür muss ggf. das Theme angepasst werden, da ein Button bzw. ein HTML-Formular eingefügt werden muss:

<a href="<?php echo exportlink($ID, 'odt')?>"><img src="<?php echo DOKU_BASE?>lib/images/fileicons/odt.png" alt="Als ODT exportieren" /></a>

Installationshinweise und Beispiele finden sich auf der entsprechenden Plugin-Seite auf der DokuWiki-Internetpräsenz.

 

Diagram

Wer häufig Zeichnungen von technischen Abläufen oder Programmstrukturen anfertigt, wird dieses Plugin sehr zu schätzen wissen. Mithilfe dieses Plugins können diese Zeichnungen dynamisch im Code der Seite generiert werden – Zeichnungen müssen nicht mehr mit externen Programmen erstellt und hochgeladen werden und Änderungen können blitzschnell vorgenommen werden.

Für die Zeichnungen gibt es einen einfachen ASCII-Syntax, der Programmierern vermutlich aus der ein oder anderen Infopage schon bekannt vorkommen wird.

Am Besten, man wirft man einen Blick auf die Projektseite: [klick mich!]

Wie öffentliche IP-Adresse vom Heimnetzwerk herausfinden wenn der DynDNS-Hostname nicht funktioniert?

Genau diese Frage habe ich mir heute gestellt. Offensichtlich gibt es bei DynDNS technische Probleme oder Limitierungen bei den begehrten Free-Accounts, die es einem beispielsweise ermöglichen, auf einfache Art und Weise auf das Netzwerk zuhause zuzugreifen ohne täglich IPs zu notieren.

 

Ich verwende einen solchen DynDNS-Hostname, um mich täglich ab und an daheim einzuwählen um auf meine Nagios-Instanz zuzugreifen. Die letzten Wochen und Monate habe ich regelmäßig das Problem, dass mein DynDNS-Hostname nicht auf die aktuelle IP-Adresse gelinkt wird. Das ist natürlich unschön, da mein VPN-Login mit dem DynDNS-Hostname vorgenommen wird. In einem solchen Fall kann ich mich also nicht einloggen, da mich der Hostname ins Timeout-Nirvana führt.

 

Hierfür habe ich jetzt eine schicke Lösung – benötigt wird lediglich ein Webserver im Internet und ein aktiver Host im Heimnetzwerk, auf dem man 2 kleine PHP-Skripte und ein temporäres Lockfile anlegt. Heutzutage kein Problem, einen öffentlichen Webspace haben die meisten ohnehin. Das Prinzip ist folgendes:

  • Tritt der DynDNS Hostname-Fehler auf, wird Skript 1 (ip.php) aufgerufen, welches ein temporäres Lockfile anlegt (dem entsprechenden Zielordner müssen vorher Schreibrechte eingeräumt worden sein)
  • Der aktive Host im Heimnetzwerk prüft periodisch mittels Skript 2 (ip_request.php) ob ein Lockfile vorhanden ist
  • Ist ein Lockfile vorhanden wird mittels PHP mail() eine Mail mit der öffentlichen IP versendet und das Lockfile gesendet
  • Idealerweise schützt man das Verzeichnis auf dem Webserver mittels HTAccess

 

Am besten realisiert man das Ganze auf dem Host im Heimnetzwerk mit einem kleinen Cronjob:

 

*/2 * * * * root        wget http://BENUTZERNAME:PASSWORT@WEBSERVER.TLD/ip_request.php -O /dev/null

 

 

ip.php:

 

<?php
 if(is_file("tmp/ip_request") == false)
 {
 $datei = fopen("tmp/ip_request","w");
 fwrite($datei, "foo");
 fclose($datei);
 echo "Request sent.";
 }
 else { echo "Request to get IP was already sent."; }
 ?>

 

 

 

ip_request.php:

 

<?php
 if(is_file("tmp/ip_request"))
 {
 mail("DEINE-MAIL@SERVER.TLD", "My current IP",
 "My current IP is: ".$_SERVER['REMOTE_ADDR'],
 "From: DEIN NAME <DEINE-MAIL@SERVER.TLD>");
 unlink("tmp/ip_request");
 echo "Request answered, thanks.";
 }
 ?>

 

 

Funktioniert bei mir wunderbar – ideal, wenn man ohnehin irgendwo noch einen Host im Netzwerk am Laufen hat. :-)