dynaperl

Damit Webalizer die Logfile Reports auf deutsch erstellt (ja es gibt Leute die das wollen) installiert man das Debian Paket locales und stellt de_DE@euro als Standard ein (oder setzt LC_ALL vor dem Aufruf von Webalizer).

Webalizer V2.01-10 (Linux 2.6.18-6-xen-amd64) locale: C
Using logfile /var/log/apache2/access.log.1 (clf)

apt-get install locales

Webalizer V2.01-10 (Linux 2.6.18-6-xen-amd64) locale: de_DE@euro
Verwende Protokolldatei /var/log/apache2/access.log.1 (clf)

Damit Webalizer die Logfile Reports auf deutsch erstellt (ja es gibt Leute die das wollen) installiert man das Debian Paket locales und stellt de_DE@euro als Standard ein (oder setzt LC_ALL vor dem Aufruf von Webalizer). Webalizer V2.01-10 (Linux 2.6.18-6-xen-amd64) locale: C Using logfile /var/log/apache2/access.log.1 (clf) apt-get install locales Webalizer V2.01-10 (Linux 2.6.18-6-xen-amd64) locale: de_DE@euro Verwende Protokolldatei /var/log/apache2/access.log.1 (clf)

Wie ich schon mal geschrieben habe funktioniert unter Debian Xen und Bonding nicht da das Xen Netzwerk Script nicht mit dem Bond-Interface umgehen kann. Eigentlich hatte ich gedacht das sie diesen offensichtlichen Fehler unter Lenny gefixt haben. Bin ich denn der einzige der auf seinen Xen Servern Bonding verwendet?

Hier gibt es den neuen Patch

Wie ich schon mal geschrieben habe funktioniert unter Debian Xen und Bonding nicht da das Xen Netzwerk Script nicht mit dem Bond-Interface umgehen kann. Eigentlich hatte ich gedacht das sie diesen offensichtlichen Fehler unter Lenny gefixt haben. Bin ich denn der einzige der auf seinen Xen Servern Bonding verwendet? Hier gibt es den neuen Patch

Die Dell R300 Server haben auf dem Board zwei Broadcom NetXtreme Netzwerkkarten für die der Debian Etch Treiber tg3 nicht funktioniert. Die Quellen kann man sich bei Broadcom besorgen und folgendermaßen kompilieren.

apt-get install linux-headers-2.6.18-6-xen-amd64
unzip linux-3.92n.zip
tar xzf tg3-3.92n.tar.gz
cd tg3-3.92n
make KVER=2.6.18-6-xen-amd64
insmod ./tg3.ko
dmesg|tail

Eine weitere Besonderheit ist das die OMSA Tools  (Version 5.5) auf den R300 keinen Storage Controller finden. Für die Lösung ist das Tool lsiutil nötig welches man wie folgt kompiliert.

wget ftp://ftp.lsil.com/HostAdapterDrivers/linux/lsiutil/lsiutil.tar.gz tar xvfz lsiutil.tar.gz
cd lsiutil
rm lsiutil
make
cp lsiutil /usr/local/bin/

Nun kann man mit dem Tool die Laufwerke scannen und nach einem OMSA-Neustart findet OMSA die Laufwerke.

lsiutil -s; /etc/init.d/dataeng restart;

Damit das auch nach einem Neustart funktioniert habe ich mir lsiutil -s am Anfang mit in die /etc/init.d/dataeng gepackt.

Die Dell R300 Server haben auf dem Board zwei Broadcom NetXtreme Netzwerkkarten für die der Debian Etch Treiber tg3 nicht funktioniert. Die Quellen kann man sich bei Broadcom besorgen und folgendermaßen kompilieren. apt-get install linux-headers-2.6.18-6-xen-amd64 unzip linux-3.92n.zip tar xzf tg3-3.92n.tar.gz cd tg3-3.92n make KVER=2.6.18-6-xen-amd64 insmod ./tg3.ko dmesg|tail Eine weitere Besonderheit ist das die OMSA Tools  (Version 5.5) auf den R300 keinen Storage ...

Bei SourceForge gibt es eine ziemlich alte aber gut funktionierende Websieve Version.  In dem Archiv ist auch ein Perl Modul (Sieve.pm) enthalten. Nach dem Update auf Lenny scheint dieses Perl Modul ein Problem mit der neuen Sasl Bibliothek zu haben. Das Perl Modul hängt an den Base64 kodierten String aus Username und Passwort immer noch ein Nullbyte an. Daran stört sich Sasl gibt folgende Fehlermeldung aus:

cyrus/sieve[20978]: badlogin: localhost[127.0.0.1] PLAIN error base64 decoding string

Als Lösung übergibt man der encoding Funktion einen leeren Zeilentrenner. Hier der Patch:

--- Sieve.pm    2008-12-18 17:41:56.779613529 +0100
+++ Sieve_neu.pm        2008-12-18 17:41:46.679333247 +0100
@@ -127,7 +127,8 @@
        $self->{'Capability'}=$_;
     }
     $userpass = "$self->{'Proxy'}\x00".$self->{'Login'}."\x00".$self->{'Password'};
-    $encode=encode_base64($userpass);
+#    $encode=encode_base64($userpass);
+    $encode=encode_base64($userpass, '');
     $len=length($encode);
     print $fh "AUTHENTICATE \"PLAIN\" {$len+}\r\n";

Bei SourceForge gibt es eine ziemlich alte aber gut funktionierende Websieve Version.  In dem Archiv ist auch ein Perl Modul (Sieve.pm) enthalten. Nach dem Update auf Lenny scheint dieses Perl Modul ein Problem mit der neuen Sasl Bibliothek zu haben. Das Perl Modul hängt an den Base64 kodierten String aus Username und Passwort immer ...

Bisher hatten wir einige Kalender mit Apache_moddav realisiert. Das führte aber immer wieder zu Problemen beim gleichzeitigen Zugriff mehrer Clients auf einen Kalender. Dabei kam dann teilweise die ICS-Datei abhanden.

Ich habe mir jetzt mal freie CalDav Server angeguckt (die Java basierenden Versionen Cosmo und Bedework habe ich gleich außen vorgelassen). DAViCal macht einen ganz interessanten Eindruck setzt aber PostgreSQL als Backend voraus. Zudem war die Liste der Abhängigkeiten (Apache + tausende Perl und Php Pakete) mir etwas zu lang. Positiv fällt allerdings auf das man Davical unter Lenny einfach als Paket installieren kann.

Ich habe mich jetzt für den Darwin Calendar Server entschieden. Der ist in Python geschrieben und unter Lenny als Debian Paket zu beziehen. Abgesehen von den unangenehmen plist Konfigurationsdateien ist mir noch nichts negatives aufgefallen. Über zwei Dateien sind schnell User und Gruppen (/etc/caldavd/accounts.xml) angelegt, x509 Zertifikat installiert und SSL aktiviert  (/etc/caldavd/caldavd.plist). Schon kann es los gehen.

Auf der Projekte Website ist die Konfiguration der Gängigen Clients beschrieben. Was hilfreich ist da sich die richtige URL zwischen Apple-iCal und Sunbird unterscheidet. Dabei ist noch anzumerken das Apples iCal die Verbindung verweigert wenn man SSL mit einem selbst signierten Zertifikat verwendet. Bevor die Anmeldung kalppt muß man sein Root-CA (oder das von cacert wenn man hier ein Zertifikat geordert hat) in der Schlüsselbundverwaltung importieren. Dazu zieht man die PAM kodierte Zertifikats Datei auf Schlüsselbunde/Anmeldung, öffnet das Zertifikat mit einem Doppelklick, öffnet den Punkt vertrauen und stellt die Auswahl auf immer vertrauen.

Der Server legt jeden Termin als eigene ics-Datei ab. Als Index verwendet er ein SQL-light Datenbank File. So funktionieren auch gleichzeitige Änderungen an einem Kalender problemlos. Ändern mal zwei Sunbird-Clients auch noch den gleichen Termin bekommt der eine von beiden (der langsamere) eine Warnung das sich der Eintrag in der Zwischenzeit geändert hat. Man hat nun die Auswahl seine Änderungen zu verwerfen oder die fremden Änderungen zu überschreiben.  Apples iCal gibt keine Warnung aus. Die Änderung geht verlohren.

Leider unterstützt der Darwin Calendar Server noch kein IPv6:

twisted.internet.error.CannotListenError: Couldn’t listen on [2001:7f0:23::42]:80: (-2, ‘Name or service not known’).

Update:

Der Server erkennt Änderungen an dem accounts.xml und liest das File neu ein. Das ist blöd wenn man einen Syntaxfehler gemacht hat und schön da man sich ein reload spart.

Offensichtlich kann man auch eine Directory Service wie LDAP oder Active Directory als Usersdatenbank verwenden. Das gucke ich mir dann als nächstes an.

Bisher hatten wir einige Kalender mit Apache_moddav realisiert. Das führte aber immer wieder zu Problemen beim gleichzeitigen Zugriff mehrer Clients auf einen Kalender. Dabei kam dann teilweise die ICS-Datei abhanden. Ich habe mir jetzt mal freie CalDav Server angeguckt (die Java basierenden Versionen Cosmo und Bedework habe ich gleich außen vorgelassen). DAViCal macht einen ganz ...

Die Webalizer Version 2.01.10 in Debian etch kommt mit IPv6 nicht klar. Vor dem ersten Doppelpunkt wird die Adresse abgeschnitten.

--> unresolved country for '2001' (GeoIP says (null):(null))

Allerdings gibt es bei bugs.debian.org schon einen Patch der das Problem behebt. Man kann also hoffen das wir in Lenny eine Version vorfinden die ipv6-ready ist. Mein AMD64-etch-Binary liegt hier. Nun gibt es nur noch ein Problem mit der GeoIP-Lib.

--> unresolved country for '2001:7f0:1000::2:13' (GeoIP says (null):(null))

Die Webalizer Version 2.01.10 in Debian etch kommt mit IPv6 nicht klar. Vor dem ersten Doppelpunkt wird die Adresse abgeschnitten. --> unresolved country for '2001' (GeoIP says (null):(null)) Allerdings gibt es bei bugs.debian.org schon einen Patch der das Problem behebt. Man kann also hoffen das wir in Lenny eine Version vorfinden die ipv6-ready ist. Mein AMD64-etch-Binary ...

Nach einem Upgrade (Sarge auf Etch) des libpam-mysql Paketes auf 0.5.0-6 schlägt die Authentifizierung fehl. Der Grund ist das standardmäßig die Mysql 4 Verschlüsselung verwendet wird. In meiner DB aber die Passwörter noch mit der 3er Version gehasht sind. Abhilfe schafft ein use_323_passwd=1 in /etc/pam.d/cyrus.

saslauthd[13558]: DEBUG: auth_pam: pam_authenticate failed: Permission denied
saslauthd[13558]: do_auth         : auth failure: [user=username] [service=imap]  [realm=] [mech=pam] [reason=PAM auth error]

Siehe auch /usr/share/doc/libpam-mysql/README.gz

Nach einem Upgrade (Sarge auf Etch) des libpam-mysql Paketes auf 0.5.0-6 schlägt die Authentifizierung fehl. Der Grund ist das standardmäßig die Mysql 4 Verschlüsselung verwendet wird. In meiner DB aber die Passwörter noch mit der 3er Version gehasht sind. Abhilfe schafft ein use_323_passwd=1 in /etc/pam.d/cyrus. saslauthd: DEBUG: auth_pam: pam_authenticate failed: Permission denied saslauthd: do_auth ...

Wer auf einem Dell PowerEdge 1950 unter Linux Xen als Virtualisierer verwenden will hat möglicherweise ein Problem mit der Xen Bridge. Standardmäßig richtet Xen eine Bridge (xenbr0) zwischen dem physikalischen Host Interface und den virtuellen Interfaceses der Gäste ein. Die Firmware der Broadcom NetXtreme II (BCM5708) Interfaces auf dem PE1950 Board hat allerdings einen Fehler. Nach dem Starten der Bridge ist kein Netzwerkverkehr mehr möglich. Alle Nic’s sind tot.

Der Dell Support weiß natürlich nichts von dem Problem. Hat auch keine Lösung parat. Und wenn man ihnen erzählt das man Debian verwendet liegt es natürlich daran. Da hilft auch kein Gold Support nicht.

http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=777

Gefunden habe ich die Lösung dann in einem Gmane Post. Das Problem ist wohl eine Management Funktion der Broadcom Interfaces die man allerdings eigentlich sowieso nicht braucht. Also schalten wir sie ab und sind zufrieden. Dazu laden wir uns von Dell ein Utilitie runter mit dem wir Einstellungen der NIC’s abfragen und ändern können.

1. Nach dem Download entpacken wird das Archiv durch Doppelklick der EXE
2. uxdiag.exe auf eine Bootfähige Diskette (ja Diskette) kopieren
3. Diskette booten und dann für beide NIC’s MGM Firmware deaktivieren

uxdiag.exe -c 1 -mfw 0
uxdiag.exe -c 2 -mfw 0

Bei mir gab es die Fehlermledung Register Test: Failed Reason: unknown
chip 5708B2.rdf. Die Funktion konnte aber trotzdem deaktiviert werden.

Update: ein halbes Jahr später gab es das Problem beim Nachfolgemodell 1950III immer noch.

Wer auf einem Dell PowerEdge 1950 unter Linux Xen als Virtualisierer verwenden will hat möglicherweise ein Problem mit der Xen Bridge. Standardmäßig richtet Xen eine Bridge (xenbr0) zwischen dem physikalischen Host Interface und den virtuellen Interfaceses der Gäste ein. Die Firmware der Broadcom NetXtreme II (BCM5708) Interfaces auf dem PE1950 Board hat allerdings einen ...

Das Kompilieren des iSCSI Enterprise Target Version 0.4.15 gegen einen aktuellen Kernel (z.B. 2.6.22.18 oder 2.6.24.2) schlägt mit folgender Fehlermeldung fehl:

/usr/src/iscsitarget-0.4.15/kernel/event.c: In function event_init:
/usr/src/iscsitarget-0.4.15/kernel/event.c:98: warning: passing argument 4 of netlink_kernel_create from incompatible pointer type
/usr/src/iscsitarget-0.4.15/kernel/event.c:98: error: too few arguments to function netlink_kernel_create

Die Lösung ist dieses mal wirklich sehr einfach. Man übergibt der Funktion einfach so viele Parameter wie sie möchte. Hier der Patch:

— /usr/src/iscsitarget-0.4.15/kernel/event.c 2008-02-13 15:56:50.000000000 +0000
+++ /usr/src/iscsitarget-0.4.15/kernel/event_orig.c 2008-02-13 16:01:28.000000000 +0000
@@ -95,7 +95,7 @@int event_init(void)
{
- nl = netlink_kernel_create(NETLINK_IET, 1, event_recv, THIS_MODULE, NULL);
+ nl = netlink_kernel_create(NETLINK_IET, 1, event_recv, THIS_MODULE);
if (!nl)
return -ENOMEM;
else

Fundstelle der Lösung.

Das Kompilieren des iSCSI Enterprise Target Version 0.4.15 gegen einen aktuellen Kernel (z.B. 2.6.22.18 oder 2.6.24.2) schlägt mit folgender Fehlermeldung fehl: /usr/src/iscsitarget-0.4.15/kernel/event.c: In function event_init: /usr/src/iscsitarget-0.4.15/kernel/event.c:98: warning: passing argument 4 of netlink_kernel_create from incompatible pointer type /usr/src/iscsitarget-0.4.15/kernel/event.c:98: error: too few arguments to function netlink_kernel_create Die Lösung ist dieses mal wirklich sehr einfach. Man übergibt der Funktion einfach so ...

Nach einem Kernel Update von 2.6.18-6-686 (Debian Kernel) auf 2.6.22 oder höher blieb eine meiner Kisten mit der Fehlermeldung “Warning: unable to open an initial console.” hängen. Kurz vorher hatte er noch das Root-Dateisystem ro gemountet. Google findet hierzu eine ganze Reihe Treffer. Eigentliche Grund ist das /dev/console bzw. /dev/tty* fehlen. Das kann nun einige Ursachen haben. Was mir noch nicht ganz klar ist wie so es mit Kernel 2.6.18 noch ging und nach dem Update dann nicht mehr. Beim Booten wird eine Ramdisk (tmpfs) angelegt in der udev automatisch die nötigen Device-Files anlegt. Dabei wird das originale /dev aus dem Root-Filesystem unter /dev/.static gemountet. Bei mir fehlten nun die o.g. Dev-Files seit einer Rücksicherung aus dem Backup. Nur war das bisher dank udev nicht aufgefallen.

Nach einem Kernel Update von 2.6.18-6-686 (Debian Kernel) auf 2.6.22 oder höher blieb eine meiner Kisten mit der Fehlermeldung "Warning: unable to open an initial console." hängen. Kurz vorher hatte er noch das Root-Dateisystem ro gemountet. Google findet hierzu eine ganze Reihe Treffer. Eigentliche Grund ist das /dev/console bzw. /dev/tty* fehlen. Das kann nun ...