log_rotation_method=d

Falls man diese Option zu hoch setzt bzw. selbst mittels Logrotate den Mechanismus aushebelt kann es passieren, dass Icinga ein Gigabyte großes Logfile erzeugt. Das hat zur Folge, dass der CGI Skript zur Verfügbarkeitsanalyse /cgi-bin/icinga/avail.cgi entweder nach einem Timeout abstürzt oder den gesamten RAM und SWAP des Systems beeinsprucht.

Da ich bereits auf dieses Problem gestoßen bin, war die einzige Lösung das riesige Logfile wieder zu splitten und nach /var/log/icinga/archives zu legen, damit die Scripte diese auswerten können.

Dafür habe ich folgenden Perl Script gebaut:


#!/usr/bin/perl
# nagios-log-split

use POSIX qw/strftime/;

if (!@ARGV[0]) {
print "Usage: nagios-log-split \n";
exit 1;
}

open(LOG,@ARGV[0]) || die "no Nagios log file named >>>>>>@ARGV[0]<<<<<<";

while () {
($part1, $part2) = split(/\s+/, $_, 2);
$part1 =~ s/\[//;
$part1 =~ s/\]//;
$filename = strftime "icinga-%m-%d-%Y-00.log", localtime($part1);
open (MYFILE, ">>$filename");
print MYFILE "[", $part1, "]\;$part2\n";
close (MYFILE);
};
close(LOG);


Aus diesem Grund habe ich das Theme meines Zweitblogs geekplace.de aufpoliert und Mobiltelefon fähig gemacht.
Der WordPress Entwickler Alex King bietet auf seiner Seite ein Plugin an, welches die Clientinformation auswertet und ein passendes Theme bereitstellt, bei Mobiltelefonen somit die abgespeckte WP-Mobile Version.

So sieht das ganze zum Beispiel auf meinem iPhone 4 aus:

Ich habe das System in etlichen größeren Umgebungen (bis zu 300 Clients) im Einsatz. Erfahrungsgemäß hat sich bei der täglichen Administration des Systems die Web-GUI “Bweb” durchgesetzt. Die GUI ist als Softwareprojekt nicht besonders wartungs- und erweiterungsfreudig.

Aus diesem Grund habe ich mir als Ziel gesetzt, ein neues webbasiertes Interface für Bacula zu entwickeln. Als Basis wird die Sprache Python und die Web-API Django benutzt.

Das Projekt ist bei Sourceforge gehosted und beinhaltet die ersten Interface Prototypen.

Wer Muse hat, sich an diesem Projekt zu beteiligen, ist sicher willkommen.

# vcbMounter -h esx.domain.com -u root -p password -a moref:432 -r /mnt/vmBackup/VM01

[2010-05-16 20:00:04.495 'vcbMounter' 3076449088 info] Got access method
[2010-05-16 20:00:04.498 'vcbMounter' 3076449088 info] Got coordinator object
[2010-05-16 20:00:04.502 'vcbMounter' 3076449088 info] Attempting data access.
[2010-05-16 20:00:04.509 'vcbMounter' 3076449088 info] Creating export directory
[2010-05-16 20:00:04.562 'vcbMounter' 3076449088 info] No snapshot info for this VM, nothing to do.
[2010-05-16 20:00:04.566 'vcbMounter' 3076449088 info] Creating snapshot
[2010-05-16 20:00:04.987 'vcbMounter' 3076449088 error] Error: Other error encountered: Snapshot creation failed: Custom pre-freeze script failed.
[2010-05-16 20:00:05.008 'vcbMounter' 3076449088 error] An error occurred, cleaning up...

Das Problem hängt mit den VMWare Tools zusammen und wird hoffentlich irgendwann in einer kommenden Version behoben.

Bis dahin habe ich folgenden Workaround. Man muss beim vcbMounter die Option Quiescing mit dem Schalter -Q ausschalten. Damit wird keine I/O Stilllegung auf der VM durchgeführt und diese kann problemlos gemounted werden:

# vcbMounter -h esx.domain.com -u root -p password -a moref:432 -r /mnt/vmBackup/VM01 -Q 0

1. LVM Volume mit identischen Parameter auf dem entfernten Host anlegen

lvcreate --size 10G --name volume1 /dev/volumes

2. Snapshot des aktuellen Volume anlegen

lvcreate --size 10G --snapshot --name volume1snap /dev/volumes/volume1

3. Snapshot per SSH auf den entfernten Host kopieren

dd if=/dev/volumes/volumes1nap | ssh 192.168.0.2 "dd of=/dev/volumes/volume1"

4. Snapshot auf der Ursprungsmaschine wieder löschen

lvremove /dev/volumes/volume1snap

Man könnte noch die Datenübertragung optimieren indem man ein Packer dazwischen schaltet (z.B. … | bz2 | …), damit man keine nullen durch die Gegend schieben muss.

Ich habe damit sehr einfach eine KVM Virtual Guest von einem Host auf den anderen Verschoben. Verwendungszwecke können allerdings ziemlich unterschiedlich sein.

Die zur Zeit aktuelle Version 0.0.9 enthält einen bösen Bug im Zusammenhang mit Termineinladungen. Wenn man vom Thunderbird AddOn Lightning aus einen Termin erstellt und jemand einladen möchte, wird das Häckchen für “Einladung Versenden” ausgegraut, beim Speichern wird auch keine Einladung verschickt.

Laut dem Hauptentwickler Andrew McMilian hängt das Problem mit dem CalDAV Scheduling zusammen, das genau in der Vesion 0.9.9 eingebaut wurde.

Dazu habe ich folgenden Workaround zum Rollback zusammengestellt:

Pakete entfernen:
aptitude purge davical libawl-php

Pakete in Vorgängerversion besorgen:
wget http://debian.mcmillan.net.nz/debian/dists/lenny/awm/binary-i386/libawl-php_0.42-0_all.deb
wget http://debian.mcmillan.net.nz/debian/dists/lenny/awm/binary-i386/davical_0.9.8.4-0_all.deb

Diese Pakete installieren:
dpkg -i libawl-php_0.42-0_all.deb davical_0.9.8.4-0_all.deb

Datenbank Korrigieren:
ALTER TABLE collection ADD COLUMN in_freebusy_set boolean;
ALTER TABLE collection ALTER COLUMN in_freebusy_set SET STORAGE PLAIN;
ALTER TABLE collection ALTER COLUMN in_freebusy_set SET DEFAULT true;
ALTER TABLE caldav_data DROP COLUMN weak_etag;

Danach müssen die User seine Kalender aus dem Lightning entfernen und neu einbinden.

Durch dieses Downgrade ist eine Wiederherstellung des funktionierenden Zustandes möglich ohne die Datenbank z.B. aus dem Backup wiederherstellen zu müssen.

Unerwartete Antwort von http://api.oscar.aol.com/aim/startOSCARSession erhalten

Dies ist wieder mal auf ein Serverproblem bei AOL zurück zu führen, tritt allerdings mit keinem anderen Client auf.

Lösung:
In der Kontenverwaltung bei Erweitert die Option clientLogin benutzen deaktivieren.

Die Software ist in Python geschrieben und wird bei Google Code gehosted [1].

Bei mir befindet sich die Software nun seit ca. einem Jahr im Einsatz und weist immer wieder in unregelmäßigen Abständen Instabilitäten auf. Die häufigste auswirkung ist das Disconnecten des Transports und Auftauchen folgender Fehlermeldung im Client:

Nachrichtenzustellung an icq.gorschkow.de fehlgeschlagen: (Code 500)

ICQ connection lost! Reason: [Failure instance: Traceback (failure with no frames): twisted.internet.error.ConnectionLost: Connection to the other side was lost in a non-clean fashion.]

Dazu gibt es bereits seit Dezember 2007 einen Bugreport, welcher sich allerdings noch im Status Accepted befindet. [2]

Trotzdem bleibt die Hoffnung auf eine Weiterentwicklung des Systems, was eine gewisse Freiheit von ICQ fähigen Clients erlaubt sowie auf eine Aussicht auf Umstieg der selbst denkender Menschen auf freie Dienste a´la Jabber hoffen lässt.

URLs:

[1] http://code.google.com/p/pyicqt/
[2] http://code.google.com/p/pyicqt/issues/detail?id=112

Ziel dieser Demo war es die Unzufriedenheit gegenüber der gegenwärtigen Stasi ähnlichen politischen Entwicklung im Land zu zeigen.

Dem CCC wurde folgendes Video übergeben, auf dem man sieht, wie ein Demonstrant, der eine Anzeige gegen einen Polizisten erstatten wollte, von diesen angegriffen wird. Dabei werden auch andere Passanten verletzt:

• http://ccc.mirrors.as250.net/fsa09-043-small.avi

Über den Sinn dieser Aktion braucht man sich nicht zu streiten, der genannte Demonstrant (im blauen T-Shirt) sieht mehr als unbedrohlich aus. Die Polizei hat damit auf sich wieder mal kein gutes Licht gelenkt und das ausgerechnet bei dieser Demonstration.

Zur Zeit wird auf allen Plattformen (Twitter, Blogs, etc.) aufgerufen, gegen diesen Übergriff zivilrechtlich vorzugehen. Alle Zeugen können sich dazu bei mail@ccc.de melden.

Genau das selbe Problem hat mir gerade eben das Leben schwer gemacht. Eines Tages konnte ich mein iPod Nano unter KUbuntu Jaunty (LK 2.6.28) nicht mehr mounten. Als erstes hat HAL gemeckert, dass das Device angeblich busy wäre. OK, dachte ich mir und habe es versucht mit der Brechstange (mount -f) auf /mnt/ipod einzuhängen. Kein Erfolg, das Device war angeblich in Benutzung, was lsof |grep /dev/sdb1 aber nicht bestätigen konnte. Außerdem war es auch nicht in der mtab enthalten.

Typischerweise überlegte ich “ich habe doch nichts verändert…”.

Dann hat mich folgendes Kernel Log (dmesg) stutzig gemacht:

[  290.716172] usb-storage: device scan complete
[  290.731301] scsi 6:0:0:0: Direct-Access     Apple    iPod             1.62 PQ: 0 ANSI: 0
[  290.732287] sd 6:0:0:0: [sdb] 950209 4096-byte hardware sectors: (3.89 GB/3.62 GiB)
[  290.732909] sd 6:0:0:0: [sdb] Write Protect is off
[  290.732912] sd 6:0:0:0: [sdb] Mode Sense: 68 00 00 08
[  290.732914] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[  290.734034] sd 6:0:0:0: [sdb] 950209 4096-byte hardware sectors: (3.89 GB/3.62 GiB)
[  290.734534] sd 6:0:0:0: [sdb] Write Protect is off
[  290.734536] sd 6:0:0:0: [sdb] Mode Sense: 68 00 00 08
[  290.734537] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[  290.734540]  sdb: sdb1
[  290.735840] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[  290.735898] sd 6:0:0:0: Attached scsi generic sg2 type 0
[  291.289947] sd 6:0:0:0: [sdb] Bad block number requested
[  291.289952] device-mapper: multipath: Failing path 8:16.
[  291.289964] Buffer I/O error on device dm-2, logical block 1
[  291.289967] Buffer I/O error on device dm-2, logical block 2
[  291.289970] Buffer I/O error on device dm-2, logical block 3
[  291.289989] Buffer I/O error on device dm-2, logical block 0
[  291.289997] Buffer I/O error on device dm-2, logical block 0
[  291.350939] sd 6:0:0:0: [sdb] Bad block number requested
[  291.350945] device-mapper: multipath: Failing path 8:16.
[  291.350956] Buffer I/O error on device dm-2, logical block 1
[  291.350960] Buffer I/O error on device dm-2, logical block 2
[  291.350963] Buffer I/O error on device dm-2, logical block 3
[  291.350990] Buffer I/O error on device dm-2, logical block 0
[  291.351033] Buffer I/O error on device dm-2, logical block 0

Dann fiel mir ein, dass ich vor einigen Tagen mit iSCSI und Multipathing herumprobiert hatte. Offensichtlich hat der Device Mapper das /dev/sdb aus den Experimenten weiterhin als iSCSI LUN einbinden wollen, was auch erklärt warum das Device blockiert war.

Die Ursache war, dass ich die iSCSI LUNs nicht sauber aus der Konfig entfernt habe.

Ich hoffe, ich konnte mit diesem kleinen Braindump jemand die Suche nach einem ähnlichen Fehler erleichtern.