Nur eine kleine banale Notiz am Rande: Die Libnotify-Extension funktioniert seit Version 0.1.4-beta auch mit dem Thunderbird 3 unter Ubuntu.
Damit klinkt sich Thunderbird in das Notify System von Ubuntu/Gnome ein und liefert nette Mail-Notification-Popups auf den Desktop…
Komisch, gestern an Sylvester dachte ich noch daran welcher Hype damals vor 10 Jahren (!) um das Jahr 2000 gemacht wurde.
Jetzt scheint es wirklich ein kleines Jahr 2010 Problem zu geben: Spamassassin markiert nämlich ab heute alle Mails mit einem relativ hohen Score weil sie ein Datum aus einem Jahr größer 2010 besitzen. Näheres hier bei heise bzw. im SA-Bug-Report.
Auf die schnelle (bis sa-update einen Fix liefert) habe ich erstmal in der local.cf den Score für den betroffenen Filter heruntergesetzt:
# /etc/mail/spamassassin/local.cf
score FH_DATE_PAST_20XX 0.0
Autodiscovery in OpenNMS ist ein tolles Feature. Leider ist es nicht immer zu gebrauchen, da es derzeit nur begrenzt konfigurierbar ist. So möchte ich z.B. in einem bestimmten Netzbereich nur die jeweiligen Router der Teilnetze abfragen – und nicht alle Hosts auf Services scannen. Klar kann man auch Bereiche excluden bzw. includen – aber ich wollte ja Autodiscovery ;).
In der kommenden OpenNMS Version 1.8 sollen die Discovery bzw. die Capability-Checks (capsd) von einem neuen Daemon (“provisiond”) abgelöst werden welcher sich wohl auch besser an eigene Bedürfnisse anpassen lässt – z.B. ist als nettes Feature dann z.B. auch der Import von DNS-Zonen möglich. Dies aber nur Nebenbei.
Auf der Suche nach einem alternativen Import bin ich bei XML gelandet. Da die zu überwachenden Hosts in einem internen Wiki (Mediawiki) gepflegt werden, stehen diese über die eingebaute Export-Funktion auch als XML zur verfügung. So ist z.B. der OpenNMS Artikel bei Wikipedia auch als reines XML verfügbar: http://en.wikipedia.org/wiki/Special:Export/OpenNMS.
Ein cooles Tool zum verarbeiten von XML auf der Kommandozeile ist “xml2” (in vielen Distro-Repositories verfügbar). Kombiniert mit ein paar regulären Ausdrücken landen die richtigen IPs in einer Datei für den automatischen Import in OpenNMS:
wget -q -O - --http-user admin --http-passwd secret \
http://wiki.example.com/index.php/Spezial:Exportieren/IP_Plan \
| xml2 \
| awk '/(page\/revision\/text)*([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)*(NMS:host)/ {print $2}' \
> /opt/include-hosts
Bei etlichen Routern die snmp-Community per telnet zu setzen kann mühsam werden. Ein Script muss her. Das telnet-Kommando ist anscheinend so nicht gut dafür geeignet um eingaben von STDIN zu verarbeiten. Durch google bin ich darauf gekommen, dass viele es mit “expect” lösen. Hier mein Script:
#!/bin/bash
for host in `cat /root/hosts` ; do
expect << EOF
spawn telnet $host
expect "Login: "
send "admin\r"
expect "Password: "
send "secret\r"
expect -exact "-->"
send "snmp set communityname xxx manager xxx\r"
expect -exact "-->"
send "user logout\r"
EOF
done;
Die Hosts stehen in der Datei /root/hosts. Je in einer Zeile.
Um schnell herauszubekommen was genau für ein OS bzw. welche Version auf einer Remote-Maschine läuft schreibe ich jetzt mal die zugehörigen Befehle auf…
Quick and dirty:
# Funktioniert zumindest mit Centos, Redhat, Fedora, Ubuntu, Debian
cat /etc/issue
Ubuntu 8.04.3 LTS \n \l
(/etc/issue ist ein Template welches vom System für den Login-Prompt verwendet wird. Je nach Distribution werden dort z.B. noch Kernelversion und Architektur angezeigt, daher werden auch u.U. noch ein paar Platzhalter ausgegeben…)
Nach diversen apt-sessions (z.B. dist-upgrade) sammeln sich allerhand Restbestände von alten Paketen an. Folgendes mache ich immer um ein wenig aufzuräumen. Nutzung auf eigene Gefahr!
# Folgende Kommandos als Superuser
sudo su
# Paketdownloads entfernen
apt-get clean
# Nicht benötigte Pakete entfernen
apt-get autoremove
# Reste (z.B. Konfigurationsdateien) von bereits deinstallieren Paketen entfernen
dpkg -l | grep ^rc | cut -d ' ' -f3 | xargs dpkg -P
Das ganze sollte auch unter Debian klappen…
Man sollte in diesen Zeiten vorsichtig mit dem Begriff umgehen, aber meine Puppet-Instanzen haben sich heute alle selbst beendet.
Eigentlich wollte ich nur die Puppet-Konfigurationsdatei selbst auch per Puppet verteilen. Leider vergaß ich bei der Definition des Services die Option “hasrestart” – welche Puppet sagt, dass das init-Script des betreffenden Services auch eine restart Option hat. Ansonsten wird der Service erst gestoppt und dann gestartet. Was in meinem Fall passiert ist kann sich jeder denken…
service { puppet :
ensure => running,
enable => true,
hasrestart => true,
subscribe => [Remotefile["puppet.conf"]],
}
Bisher lief die Einrichtung und Konfiguration von OpenNMS seit einigen Wochen sehr erfolgreich. Anfängliche Konfigurationsfehler sowie die Einrichtung weiterer Services konnten bisher immer mit Hilfe der Mailingliste und des Wikis schnell behoben werden.
Die (für OpenNMS sehr wichtige) SNMP Kommunikation lief aber nicht ganz so zuverlässig. Ab und an erschienen folgende Meldungen im Eventlog:
SNMP data collection on interface x.x.x.x failed.
snmp4j-internal.log lieferte dann andauernd:
Received response that cannot be matched to any outstanding request ...
Merkwürdigerweise immer nur bei bestimmten Hosts… Nach erfolgloser Suche bin ich dann nochmal die Konfiguration durchgegangen. In der snmp-config.xml fand ich dann die Ursache:
OpenNMS Experten werden jetzt sicherlich nur süffisant grinsen. Bei der anfänglichen Einrichtung von OpenNMS wusste ich damals noch nicht, dass OpenNMS generell Timeouts in Millisekunden angibt…
So ist es besser:
Erstaunlich das es überhaupt so viele externe Hosts geschafft haben innerhalb der 10ms zu Antworten – spricht für die Infrastruktur ;)
Derzeit bin ich auf der Suche nach einem geeignetem Weg um meinen Homeserver ins Rechenzentrum zu sichern. Zunächst ist mir natürlich rsync over ssh eingefallen, aber ich hätte die Daten gerne auf der Remote-Seite verschlüsselt abgelegt… Mit TrueCrypt lokal einen Backup-Container anlegen und dann per rsync sichern? Zu unflexibel. Auf der Remote-Seite einen TrueCrypt Container anlegen? Toll, mindestens jeder root-user kommt ran ;)
Was sich als Ideal herausstellt ist das Tool “duplicity“. Mir ist es irgendwann schon mal aufgefallen da es bei der Synchronisation mit Amazon S3 auch auf librsync setzt. Das es auch verschlüsselt war mir irgendwie entfallen.
Um nur ein paar Features zu nennen: Verschlüsselung mittels gnuPG, Vollsicherung, Incrementelle Sicherung. Dabei setzt es wie gesagt auch die Trafficschonende rsync library ein.
Der Clou sind aber auch die unterstützten Backends/Transportwege. Neben ssh und ftp tauchen auch u.A. AmazonS3 und sogar IMAP in der Liste auf…
Das werde ich auf jeden Fall testen!
Folgendes reciept für Procmail filtert für mich jetzt diverse Arten von “failure notices”.
Klar, man könnte sicherlich auch einige Zeilen zusammenfassen, aber ich finde es so übersichtlicher. Ausserdem kenne ich jetzt eine weitere Möglichkeit “komplexe” Regeln mit ODER zu verknüpfen…
SUBJECT_DELIVERFAIL=
:0
* 1^0 ^Subject: *failure notice
* 1^0 ^Subject: *(|Mail )delivery \(?fail(ed|ure)
* 1^0 ^Subject: *((Returned|Undelivered) mail|Message)(: (.*User unknown|see transcript for details))?
* 1^0 ^Subject: *Undeliver(ed|able) (Mail|Message):? Returned to Sender
* 1^0 ^Subject: *Undeliverable:
* 1^0 ^Subject:.*undeliverable mail
* 1^0 ^Subject: *Mail System Error.*Returned Mail
* 1^0 ^Subject: *Delivery Status Notification
* 1^0 ^Subject:.*Message you sent blocked
* 1^0 ^Subject:.*Delivery Notification: Delivery has failed
* 1^0 ^Subject:.*Mail status report
* 1^0 ^Subject:.*Benachrichtung zum .*Fehlgeschlagen
* 1^0 ^Subject:.*Message you sent was blocked
* 1^0 ^Subject:.*Warning: could not send message for past
{ SUBJECT_DELIVERFAIL=1 }
:0 w
* SUBJECT_DELIVERFAIL ?? ^^1^^
./Maildir/.Trash/