Am 23. Juni 2007 haben Birgit, Werner und ich uns auf den Weg zum Hochturm gemacht. Ausgangspunkt war das Hiaslegg. Das Wetter war uns anfangs nicht sehr wohl gesonnen, weshalb wir den Aufstieg auf den Edelweissboden im Regen gehen mussten. Zum Glück ließ der Regen dann auf der Anhöhe nach und wir konnten bei angenehmen Wanderwetter den Gipfel des Hochturms erreichen.
Wanderroute für Google Earth: Download
Seit einiger Zeit schon ist eine eigene Mailingliste für Preplan aktiv.
Wer Lust hat, sich dort einzutragen um über die neuesten Vorkommnisse in unserem Bekanntenkreis informiert zu werden, der muss nur eine Email an preplan4you-subscribe@fladi.at senden und dann den Anweisungen in der automatisch generierten Antwort-Email folgen.
Am 30. Juni 2007 werde ich durch die Bärenschützklamm zum GH "Steirischer Jokl" wandern. Die Preplan-Mitglieder wurden bereits informiert. Wer Lust und Laune hat, sich daran zu beteiligen ist herzlich dazu eingeladen, sich auf preplan4you@fladi.at anzumelden.
Ich benutze es zwar nicht mehr, aber da es noch immer keine offiziellen Packages für Debian gibt, stelle ich hier weiterhin die aktuellsten für Debian Sid zur Verfügung.
Um eine optimale Konfiguration zu erzielen wurde ein Berater von der Inetra de GmbH hinzugezogen.
Die dann folgende Einführung in das GWAVA 4 System offenbarte dann aber 3 erhebliche Mängel, welche vom anwesenden Berater jedoch als "Intended-by-design" erklärt wurden.
- Die Verwendung von RBLs in den Received-Headern einer RFC821/SMTP Nachricht:
GWAVA 4 prüft jede (!!!) IP-Adresse in einer Email gegen eine Liste von definierbaren RBLs. Was sich zuerst harmlos liest erweist sich aber nach kurzer Betrachtung als fataler Fehler, sollten RBLs zum Einsatz kommen, die dynamische IP-Adressen listen. Der erste Received-Header, der in eine RFC821 Nachricht geschrieben wird, wird bei legitimen Emails vom SMTP-Server der jeweiligen Firma oder ISP geschrieben, der die Email von der Client-Anwendung entgegengenommen hat, z.B.:
Received: from endor.clients.fladi.at ([::ffff:85.127.229.xxx]) (AUTH: LOGIN xxxxxxxxxx) by uni.fladi.at with esmtp; Thu, 14 Jun 2007 23:29:56 +0200 id 0006B2A8.4671B354.xxxxxxxxxx
Hier nimmt der SMTP-Server auf uni.fladi.at die Email nach einem SMTP-AUTH von dem Client endor.clients.fladi.at an, welcher aber eine dynamische IP besitzt. Wenn uni.fladi.at nun diese Nachricht an ein System relayen würde, das GWAVA 4 im Einsatz hat, wird die IP 85.127.229.xxx dort von einer RBL als dyn. IP erkannt und die Email, obwohl sie absolut legitim ist, von GWAVA 4 als Spam erkannt werden und je nach Einstellung diese Email sogar droppen. Somit können alle SMTP-Server, die ein Relay für alle authentifizierten User (meist über SMTP-AUTH) oder bei IPSs, die ihre IP-Ranges (meist dyn. IP) über ihren SMTP-Server relayen von GWAVA fälschlicherweise als Spam eingestuft werden. Der Designfehler liegt hier darin, dass GWAVA 4 nur noch die bereits vom GWIA angenommene Nachricht im Dateisystem des Servers abgreit, und somit die IP-Adressen nur noch aus dem Header lesen kann, jedoch nicht mehr die IP-Adresse zu sehen bekommt, mit der sich der Remotehost zum GWIA verbunden hat. Auf dieses Problem angesprochen verwies der Berater von Inetra auf Spamhaus.org, welche mehrere RBLs betreiben. Auf der Homepage dort sollte laut ihm angeblich darauf hingewiesen werden, dass die Überprüfung von Received-Headern empfohlen wird. Jedoch dürfte er hier wohl die Anwendung von SBLs mit derer von RBLs verwechselt haben. Jedoch findet sich auf keiner namhaften Anti-Spam-Seite eine Empfehlung für die Überprüfung von Received-Headern, es wird sogar auf verschiedenen Mailingliste explizit davon abgeraten. - RBLs sollten immer nur direkt vom GWIA benutzt werden da nur dieser zuverlässig die IP des Gegenüber kennt, und diese gegen eine RBL prüfen kann.
- GWAVA 4 bietet keine Ausfallssicherheit: Es können zwar mehrere Scanner auf eine gemeinsame sogenannte Engine geschaltet werden, um einheitliche Filtersets zu gewährleisten. Fällt jedoch diese Engine aus, so können auch die verteilten Filter nicht mehr arbeiten. Eine Lösung für eine Synchronisation von mehrereren verteilten Engines gibt es nicht.
Auch wenn ich in einem vorherigen Post einmal GWAVA empfohlen habe, so muss ich inzwischen nach diesen Erfahrungen vom Einsatz von GWAVA 4 im produktiven Betrieb abraten!
Da die täglichen SSH-Attacken auf die Server ja bereits zur Routine gehören, und die meisten Lösungen dafür etwas altbacken wirken, gibt es direkt auf der Ebene von PAM dir Möglichkeit, erfolglose Loginversuche zu protokollieren, und nach einer festgelegten Anzahl innerhalb eines Zeitraumes, den betreffenden Login oder Remote-Host zu sperren. Dafür zuständig ist das PAM-Modul libpam-abl, wleches ich hier als Package für Debian Sid anbieten möchte.
Wer eine WS2300 Wetterstation sein eigen nennt, wird sicher die Möglichkeit nutzen wollen, die Daten auch am PC nutzbar zu machen. Für alle Debian-User ist deshalb das Package open2300 (für Debian Sid) zu empfehlen. Es bietes vielfältige Möglichkeiten, die Daten der Wetterstation am PC weiter zu verarbeiten.
Download open2300_1.10-1.1_i386.deb Download open2300_1.10.orig.tar.gz Download open2300_1.10-1.1.diff.gz Download open2300_1.10-1.1.dsc
Um Pfade durch eine Reihe von Wegpunkten bzw. Kanten innerhalb einer PostgreSQL Datenbank zu finden, eigenet sich diese Libary, welche direkt in den PostgreSQL-Server geladen werden kann. Es benutzt die Dijkstra-Funktion, welche direkt aus einem SQL-Statement heraus benutzt werden kann. Das Package wurde für Debian Sid gebaut.
Da soll noch mal jemand behaupten, wir wären nicht kreativ. Die offizielle Anfahrtsskizze zum Treffpunkt für unseren Ausflug am Samstag. Ich sehe schon das Ende von Google Maps/Earth kommen