Wer im aktuellen Ubuntu für eine Webanwendung wie z.B. dem BlogTNG Plugin die SQLite2 PHP Erweiterung benötigt, kommt um ein kleines Workaround nicht herum. Der Grund liegt darin, dass in der verwendeten PHP-Version die SQLite2 Extension nicht mehr eingebaut ist. So findet sich nur nur noch die Erweiterung für SQLite3.
Mehr zu dieser Problematik findet sich unter anderem bei Ask Ubuntu. Mein Workaround orientiert sich an diesem Blogpost.

Zunächst sollte sichergestellt werden, dass SQLite und die PHP Erweiterung wirklich auch installiert sind:

$ sudo apt-get install php5-sqlite sqlite sqlite3 libsqlite0

Danach besorgt man sich ein älteres php5-sqlite (z.B. aus Natty) um an die Datei sqlite.so zu kommen, die man anschließend nach /usr/lib/php5/ kopiert:

$ cd /tmp
$ wget http://security.ubuntu.com/ubuntu/pool/main/p/php5/php5-sqlite_5.3.5-1ubuntu7.10_amd64.deb  #URL evtl. anpassen!
$ mkdir sqlite
$ dpkg -x php5-sqlite_5.3.5-1ubuntu7.10_amd64.deb sqlite/              #Dateiname auch anpassen!
$ sudo cp -v sqlite/usr/lib/php5/20090626/sqlite.so /usr/lib/php5/20090626/     #Pfade können sich verändern!

Nun legt man mit einem Editor die Datei /etc/php5/conf.d/sqlite.ini an:

$ sudo nano /etc/php5/conf.d/sqlite.ini

…und fügt folgenden Inhalt ein:

; configuration for php SQLite module
extension=sqlite.so

Anschließend muss man noch den jew. Webserver (hier Apache) neustarten:

$ sudo service apache2 restart

Vor kurzem konnte ich in einem gewissen Baumarkt am Uhu „Stand“ folgende Fehlermeldung auf einer Embedded-Maschine mit Touchscreen, die eigentlich, wie ich bei meinem Besuch zwei Wochen später herausfinden konnte, zur Auswahl des richtigen Klebestoffes da ist (und nicht zum Anzeigen von lokalen Apache 404ern), zu Gesicht bekommen:

Wie aus den Bilder (leider relativ schlechte Qualität) unschwer zu erkennen ist läuft diese Maschine mit Ubuntu – ich hätte eher auf ein Windows CE oder ähnliches getippt. Auch scheint der Apache tatsächlich auf der kleinen Box laufen, was an dem Footer „Apache … Server at localhost Port 80“ erkennbar ist. Die auf jenem System verwendete Software ist aber gnadenlos veraltet (Apache 2.0.55 und PHP 5.1.2). Zum Vergleich die Versionen auf einem Lucid Server:

ich@server:~$ dpkg -l | grep apache
ii  apache2                                   2.2.14-5ubuntu8.7
ich@server:~$ dpkg -l | grep php5
ii  php5                                      5.3.2-1ubuntu4.11

About two months ago I've benchmarked my Apache with ab:

$ ab -n 2000 -c 100 http://host

• 2000 requests to perform
• 100 multiple requests to perform at a time

$ w
 17:28:41 up 17:10,  3 users,  load average: 107,34, 71,08, 32,14
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT

The result was a load average of 107.34 – on a Intel Atom Dual Core with HT (Hyper Threading). That was - until there - definitely my record. Although the optimal load of this system is a average of 4, the system was even accessible and able to reply other request (e.g. Cyrus, NFS, DNS, SSH connections).

Today I performed on a backup server with a old Intel Celeron Single Core CPU a stress test with stress:

$ stress -i 10000

…but just on sync() to keep the CPU usage down.
On the left you can see the result of such a stress test and below an output of w before the screenshot was taken.

$ w
 17:28:41 up 22 min,  3 users,  load average: 983,11, 869,82, 904,16
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT

While the system reached a load average of over 1000 it was even reachable! So Munin (on another server) was able to connect to the Munin-Node and generate this graph:

Heute musste ich meines Verwunderns in /var/www den Ordner .openoffice.org finden. Der Ordner enthielt logischerweise die Benutzereinstellungen eines OpenOffice Users. Doch welches? Ich konnte mich nicht daran erinnern, ein OO-Profil nach /var/www kopiert zu haben – warum auch? Aus meinen Backups und den Timestamps konnte ich etwa rekonstruieren, wann der Ordner angelegt wurde. Allerdings hatte ich in diesem Zeitraum einfach mit zu vielen Komponenten experimentiert, was die Suche nach der genauen Ursache unmöglich machte.

Wie üblich warf ich Google an und wurde auf ubuntuforums.org fündig: Erwartungsgemäß handelte es sich um das OO-Profil eines Users …und da /var/www das Homeverzeichnis von www-data ist, folglich um die Benutzereinstellungen von www-data.

Nun wurde mir auch klar, wie das Profil dort hin kam. In dem Zeitrahmen der Timestamps hatte ich verschiedenen eyeOS Versionen (1.9 und 2.5) getestet und im Zuge dessen die Office-Tauglichkeit von eyeOS 1.9.0 erprobt, was die Installation von OpenOffice erforderte. Durch die Nutzung von OpenOffice durch eyeOS wurde daraufhin jenes Benutzerprofil in /var/www angelegt.

<Directory "/var/www/.openoffice.org">
  Order deny,allow
  Deny from all
</Directory>