2012-07-11 // Kurztipp: SQLite2 PHP-Erweiterung unter Ubuntu 12.04
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
2011-12-31 // Neulich im Baumarkt...
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
2011-10-08 // Some really high Load averages
Using Apache Benchmark (ab)
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).
Using stress
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:
2011-09-14 // Fundstück: OpenOffice Profil in /var/www
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.
Wenn /var/www
als Webroot einer Seite und nicht als Oberverzeichnis mehrere Seiten genutzt wird, sollte der Zugriff auf den Ordner .openoffice.org
evtl. abgesichert werden:
<Directory "/var/www/.openoffice.org"> Order deny,allow Deny from all </Directory>