LDAP – logging, loglevel, seperate logfile, logrotate

Das loglevel wird in der /etc/ldap/slapd.conf mit dem Eintrag

 loglevel INTEGER

festgelegt. Moegliche Werte sind (man slapd.conf)

  • 1 (0x1 trace) trace function calls
  • 2 (0x2 packets) debug packet handling
  • 4 (0x4 args) heavy trace debugging (function args)
  • 8 (0x8 conns) connection management
  • 16 (0x10 BER) print out packets sent and received
  • 32 (0x20 filter) search filter processing
  • 64 (0x40 config) configuration file processing
  • 128 (0x80 ACL) access control list processing
  • 256 (0x100 stats) connections, LDAP operations, results (recommended)
  • 512 (0x200 stats2) stats log entries sent
  • 1024 (0x400 shell) print communication with shell backends
  • 2048 (0x800 parse) entry parsing
  • 16384 (0x4000 sync) LDAPSync replication
  • 32768 (0x8000 none) only messages that get logged whatever log level is set

Diese Zahlen sind auch beliebig kombinierbar. Moechte man z.B. das loglevel 128 und 32 kombiniert haben, traegt man loglevel 160 ein.

Der LDAP logt normalerweise nach /var/log/syslog. Moechte man eine eigene Logfile haben, z.B. /var/log/slapd.log, dann die folgende Zeile in /etc/syslog.conf bzw. /etc/rsyslog.conf hinzufuegen:

 local4.*		/var/log/sldap.log

Um die logfile in logrotate mit aufzunehmen die Datei /etc/logrotate.d/slapd anlegen und wie folgt fuettern:

/var/log/slapd.log
{
	rotate 7
	daily
	missingok
	notifempty
	delaycompress
	compress
	postrotate
		invoke-rc.d rsyslog reload > /dev/null
	endscript
}

Nach entsprechenden Aenderungen natuerlich die jeweiligen Dienste (ldap, rsyslog) neustarten…

Skript: Netzwerkinterface neustarten

Ich hatte eine Debian etch Maschine, virtualisiert mit KVM, bei der brach unter Last immer die Netzwerkverbindung zusammen. Reproduzierbar. Das Update auf Lenny brachte nix. Ich habe die Maschine gestern mit Lenny neu aufgesetzt und die Probleme existieren nicht mehr. Hier nun das Skript was ueberprueft ob eine Verbindung nach aussen moeglich ist und ggfs. das Interface neustartet, ich brauche es nicht mehr, aber bevor ich es loesche hier noch einmal dokumentiert:

#!/bin/bash
##
#  check if network is available and if not restart
#  the network interface
##
 
if ping -c 1 -w 1 -q www.google.de &>/dev/null; then
#  echo "Network is up, no further action required"
  echo ""&>/dev/null
else
  echo "Network is down, restarting the interface..."
  ifdown eth0 && ifup eth0
 fi

Howto: Mobile Webinterface

Ich schrieb ja vor kurzem darueber, dass ich eine kleine Werder Bremen Newsuebersicht erstellt habe. Als ich nun fuer ein paar Tage im Kurzurlaub war und die Seite ueber mein Handy aufrief, fiel mir auf, dass sie ein mobiles Interface gebrauchen koennte. Das Bild war zu gross, und generell haette man wohl auch was bei den Ladezeiten optimieren koennen. Wieder zurueck habe ich mich dann gleich an die Arbeit gemacht. Schnell bin ich auf zwei sehr nette Loesungen gestossen und habe kurzerhand beide miteinander Kombiniert. Die Loesungen findet Ihr auf den beiden Seiten:

Der erste Blogeintrag beschreibt, worauf man achten muss wenn man ein mobile Webseite erstellt, und beinhaltet eine Anleitung um seine eigene Seite mobil-Freundlich mit einer Subdomain zu erstellen. Der Weg ist recht simpel: Man erstellt eine Subdomain, z.B. von www.pregos.info dann mobile.pregos.info und weist der Subdomain den gleichen DocumentRoot zu. Anschliessend erstellt man zwei PHP Dateien und legt diese in den DocumentRoot. Beide PHP-Dateien werden ueber eine .htaccess vor und nach jeder HTML-Seite aufgerufen. Dabei wird ueberprueft ob die mobile.pregos.info Subdomain aufgerufen wurde, und wenn ja der HTML-Quelltext durch verschiedene Filter gejagt, die dann die Seite entsprechend anpassen.

Dieser Weg ist sehr schnell eingerichtet und funktioniert wunderbar. Ich finde ihn aber nicht schoen, denn das Szenario was mir vorschwebt ist eine mobile Seite von http://werder.pregos.info unter der gleichen Domain, da  jetzt noch ne Subdomain ranzuhaengen http://m.werder.pregos.info, nee, zuviel. Ich moechte, dass die Seite je nachdem von welchem Geraet sie aufgerufen wird, entweder als mobile Version oder als normale zu sehen ist.

Ein simpler Weg dieses zu erreichen waere z.B. mittels JavaScript festzustellen wie gross die Bildschirmaufloesung des anzeigenden Browsers ist und dementsprechend die Seite mittels CSS zu layouten. Das bedeutet aber gleichzeitig, dass ich mit JavaScript arbeiten muss und alle Browser das unterstuetzen muessen und Rechenleistung auf dem mobilen Geraet und und und… Ich will EINE Domain, EINE URL und SELBSTERKENNUNG des Servers.

Ueber WURFL (Wireless Universal Ressource File) bin ich dann irgendwie zu dem Projekt Apache Mobile Filter gestossen. Apache Mobile Filter ist eine Apache-Plugin, dass die Funktionen von WURFL direkt in Apache zur Verfuegung stellt. WURFL kennt z.B. alle UserAgents (z.Zt. 8661 verschiedene) und kann auf dieser Basis sagen, ob das gerade aufrufende Geraet ein mobiles Geraet ist oder nicht. Ueberpruefen und sehen was AMF alles so an Variablen zur Verfuegung stellt koennt Ihr unter der Adresse: http://apachemobilefilter.nogoogle.it/php_test.php

Das schoene ist, dass AMF diese Variablen in PHP unter Apache als dessen Server Enviroment Variablen zur Verfuegung stellt. Ich kann also in PHP z.B. mit der Variable $_SERVER[‚AMF_IS_WIRELESS_DEVICE‘] arbeiten. Mit dieser Loesung kann ich nun serverseitig ueberpruefen ob es sich um ein mobiles Endgeraet handelt oder nicht, und dementsprechend die mobile Version der Seite anzeigen lassen oder nicht.

Nur der Weg dahin brauchte noch etwas, der Support von Apache Mobile Filter war aber allererste Sahne, echt super, kann man nicht anders sagen, und fuer die Nachwelt hier nochmal ein Auszug aus meiner .bash_history:

mkdir foo
cd foo
wget http://downloads.sourceforge.net/project/mobilefilter/ApacheMobileFilter/2.21/Apache2-WURFLFilter-2.21.tar.gz?use_mirror=dfn
tar -xzvf Apache2-WURFLFilter-2.21.tar.gz
cd Apache2-WURFLFilter-2.21/
perl Makefile.PL
make install
aptitude install libapache2-mod-perl2 libgd-gd2-perl libgd-tools
a2enmod perl
cpan Apache2::WURFLFilter Apache2::Filter Apache2::RequestRec Apache2::RequestUtil Apache2::Connection Apache2::SubRequest Apache2::Log CGI::Cookie APR::Table CGI::Cookie LWP::Simple Image::Resize IO::Uncompress::Unzip Cache::FileBackend
mkdir /var/www/MobileFilter
chown www-data:www-data /var/www/MobileFilter

Dazu habe ich noch in die /etc/apache2/httpd.conf die folgenden Eintraege hineingeschrieben:

PerlSetEnv MOBILE_HOME /var/www/MobileFilter
PerlSetEnv CacheDirectoryStore /tmp
PerlSetEnv WurflNetDownload true
PerlSetEnv DownloadWurflURL  http://downloads.sourceforge.net/wurfl/wurfl-latest.zip
PerlSetEnv LoadWebPatch true
PerlSetEnv PatchWurflNetDownload true
PerlSetEnv PatchWurflUrl http://wurfl.sourceforge.net/web_browsers_patch.xml
PerlSetEnv CookieCacheSystem true
PerlSetEnv CapabilityList all
PerlModule Apache2::WURFLFilter
PerlTransHandler +Apache2::WURFLFilter
#PerlOutputFilterHandler Apache2::AMFDeviceMonitor

Anschliessend muss der Apache Webserver mit einem /etc/init.d/apache2 restart neu gestartet werden.

Welche Variablen euch dann zur Verfuegung stehen und ob alles funktioniert kann man mit der Test-PHP Seite ueberpruefen die ich oben bereits einmal verlinkt habe. Diese koennt Ihr euch ganz einfach auf euren eigenen Server schmeissen, gibts hier zum Download.

Wenn irgendwelche Fehler auftauchen oder (wie bei mir zu Anfang) die Variablen nicht zur Verfuegung stehen, einfach nochmal ein rm -rf /tmp/wurfl* machen und Apache neustarten.

Ach so… um die mobile Seite jetzt zu implementieren habe ich die bereits beschriebene Loesung mit den PHP-Files und der .htaccess genommen und einfach in der global_prepend.php und die Zeile:

if ($_SERVER['SERVER_NAME'] == 'mobile.myawesomeblog.com') {

ersetzt durch

 if ($_SERVER['AMF_IS_WIRELESS_DEVICE'] == 'true') {

sowie die nachfolgende Zeile mit der URL-Ersetzung von normaler zu mobile-URL einfach weggelassen.