Skip to content

Munin auf einen anderen Host umziehen

Munin-Laufzeiten - vorher und nachher.

Über die Einrichtung des Monitoring-Tools Munin habe ich bereits vor 2 Jahren geschrieben. Mittlerweile habe ich meine Installation aus den Debian-Backports auf die Version 1.4.5 geupdatet, die deutlich ressourcenhungriger zu sein scheint; überdies sind mittlerweile auch mehr Hosts durch Munin zu überwachen. Beides führte zu einer spürbaren Grundlast auf dem (älteren) System, das bislang den Munin-Server darstellte; daher habe ich Munin nunmehr auf eine andere Maschine umgezogen, was deutlich sichtbare Performance-Verbesserungen gebracht hat, die sich schon in einer Laufzeitverkürzung darstellen.

Bei dem Umzug sollten aber auf jeden Fall die bereits erstellten Statistiken aus den letzten beiden Jahren erhalten bleiben, um nicht komplett von vorne beginnen zu müssen. Eigentlich sollte ja nichts leichter als das sein: Munin auf dem neuen Rechner installieren, die Konfiguration des alten Systems übernehmen, das neue System auf allen Nodes für den Abruf freischalten, testen, dann die gesammelten Daten auf dem alten Rechner packen, auf den neuen transferieren und dort wieder auspacken, Munin auf dem alten Rechner anhalten, fertig. Ungefähr so geht das auch tatsächlich - wenn denn diebeiden Systeme dieselbe Architektur haben. Wenn aber der alte Rechner ein 32bit-System ist und der neue ein 64bit-System, dann sind die erzeugten RRD-Dateien nicht kompatibel. Autsch. Aber auch dafür gibt es glücklicherweise eine Lösung, die ich einem alten Eintrag aus dem Cacti-Forum abgeschaut habe. :-)

"Munin auf einen anderen Host umziehen" vollständig lesen

Scanner + Drucker = Kopierer: iCopy

Drucken ist eine Standardaufgabe - Scannen auch. Heutzutage gibt es dafür bereits Multifunktionsgeräte, die in der Regel Drucken und Scannen und in Kombination dieser beiden Funktionen auch kopieren können; teilweise beherrschen sie auch das Faxen.

Nicht immer aber hat man eines dieser Multifunktionsgeräte zur Verfügung, sondern hat nur Scanner und Drucker; oder man hat ein Multifunktionsgerät, aber es druckt nicht; oder man hat ein Multifunktionsgerät, will aber die Druckfunktion nicht nutzen, weil es sich bspw. um einen Tintenstrahldrucker handelt und der Ausdruck dort sowohl langsamer als auch teurer ist als auf dem gleichfalls vorhandenen Laserdrucker. In diesem Fall kann man dennoch Dokumente einscannen und danach dann ausdrucken. Sehr bequem ist es aber, wenn man dazu ein Tool hat, was das automatisiert.

iCopy ist ein solches Windows-Tool. Es erlaubt die Auswahl des zu verwendenden Scanners und Druckers und weitere Konfigurationseinstellungen - in der Regel genügt der Default -, und danach muß man nur noch auf den Kopierknopf klicken. Der Scanner scannt, und sobald das Bild eingescannt ist, druckt der Drucker es aus. Voilà. Selbst ohne automatischen Einzug am Scanner kann man so schnell und effizient einen ganzen Stapel Kopien anfertigen: Original einlegen, Abdeckung am Scanner schließen, Kopiertaste in iCopy anklicken, nach dem Scan das Original gegen das nächste tauschen, während der Drucker druckt, lather, rinse, repeat.

iCopy ist open source, aktuell ist derzeit Version 1.48 vom 05.01.2011.

Backup mit duply und duplicity

Niemand will Backup. Alle wollen Restore.

(Kristian Köhntopp zitiert einen Vertriebler - Fachbegriffe der Informatik #125)

Regelmäßige Backups sind wichtig und auch durch redundante Systeme wie RAIDs nicht zu ersetzen; ganz abgesehen davon, daß bei einem RAID 1 gerne die - meistens ja zum selben Zeitpunkt wie die erste in Betrieb genommene - zweite Platte beim notwendigen Rebuild zusammenbricht, schützt ein RAID auch nur gegen Datenverlust durch Ausfall einer Festplatte, aber weder gegen versehentliches oder böswilliges Löschen, Überschreiben oder Verändern von Daten, noch kann es gegen einen fatalen Schaden des gesamten Systems (Brand, Diebstahl, …) schützen. Backups sollten daher

  • regelmäßig durchgeführt werden,
  • versioniert sein (so daß man einen längeren Zeitraum zurückgehen kann) und
  • off-site transferiert werden können.

Zumindest dann, wenn man keine Kontrolle über die Infrastruktur hat, auf der die Backups gespeichert und über die sie transportiert werden, sollten Backups auch verschlüsselt sein. Diese letzte Anforderung ist typisch für sog. "Rootserver", also Mietserver, zu denen bei üblichen Angeboten auch ein sog. "Backupspace", also Speicherplatz auf einem Storage gehört, auf den zumeist nur per (unverschlüsseltem) FTP zugegriffen werden kann. Selbst wenn man dem Provider und seinen Mitarbeitern vertraut, kann man nicht ausschließen, daß auch Dritte - andere Kunden, … - zumindest den unverschlüsselten Datenverkehr zwischen dem zu sichernden Server und dem Storage "belauschen" können. Wenn man seine Backups also unverschlüsselt überspielt, kann die gesamte Konfiguration samt aller Paßworte usw. usf. mitgelesen werden.

Schließlich gibt es eine letzte Anforderung für sinnvolle Backups: sie sollten, einmal eingerichtet, möglichst wenig Aufwand bedeuten, optimalerweise automatisiert sein, denn nur dann werden sie auch wirklich regelmäßig durchgeführt.

Alle zuvor genannten Anforderungen erfüllt das Tool duplicity, für das die c’t bereits anno 2006 ein Frontend namens ftplicity entwickelt hat, das nunmehr unter dem Namen duply weiterentwickelt wird. duply unterscheidet sich u.a. dadurch von ftplicity, daß es nicht nur die Konfiguration der Übertragung via FTP unterstützt, sondern auch auf anderem Weg (was dann auch die Namensänderung erklärt).

duplicity sichert Dateien und Verzeichnisse in (nicht gepackte!) tar-Archive, verschlüsselt diese vermittels GnuPG und überträgt die Sicherungen in kleinen Häppchen auf verschiedenen Wegen (lokal, FTP, SCP, rsync, …) auf das Sicherungsmedium; dabei werden inkrementielle Backups über den rsync-Algorithmus erstellt, d.h. nicht alle veränderten Dateien gesichert, sondern ggf. nur ein diff, was wiederum Platz und Bandbreite spart. duplicity dürfte in den meisten Distributionen paketiert sein, duply ist es in Debian ab Squeeze, kann aber in jedem Fall trivial installiert werden.

"Backup mit duply und duplicity" vollständig lesen

Diagramm-Editoren und passende Iconbibliotheken

Auf der Suche nach einem Tool zur Erstellung von Diagrammen (bspw. Netzwerkdiagrammen etc. pp.) unter Windows, das nicht Visio heißt und vor allem nicht in dessen preislichen Regionen rangiert, bin ich auf das Freeware-Programm yED gestoßen, das mir schon recht gut gefällt. Was mir noch etwas fehlt sind passende Symbole (Shapes), derzeit namentlich für Netzwerkdiagramme und am besten optisch passend zu den bereits vorhandenen. ;-) Ein Musterdiagramm könnte bspw. so aussehen:

Demo-Diagramm, erstellt mit yED.

 

Das Symbol für den Router ist aber schon nicht so richtig passend, Laptops hat’s bisher auch nicht, usw. usf.

Wenn jemand noch bessere Software im Angebot hat, nehme ich natürlich auch Hinweise darauf gerne entgegen.

Tips und Tricks für den Umgang mit git

Bei meiner Arbeit mit git stehe ich immer wieder vor der Frage, ob man dieses oder jenes damit nicht einfach machen können müßte. Meistens lautet die Antwort auf diese Frage "ja", aber teilweise muß man schon etwas googeln, um diese Antwort zu finden. :-) Daher möchte ich ab und an kleine ergoogelte Wissensschnippsel mit der Leserschaft teilen; vielleicht steht ja noch einmal jemand anderes vor demelben Problem (und überdies sind deutschsprachige Informationen zu git nicht so wirklich umfänglich vorhanden).

Git über SSH und mehrere SSH-Keys pro Host

Mehr eine allgemeine SSH-Frage, aber da sie sich mir im Zusammenhang mit git gestellt hat …

Ein beliebter Zugriffsweg auf Git-Repositories ist der über SSH, insbesondere, wenn es auch um einen schreibenden Zugang geht und man diesen authentifizieren will. Zu diesem Zweck kann man sich den passenden SSH-Schlüssel für den Zugriff auf das Git-Repository über die SSH-Konfiguration definieren, bspw. durch einen Eintrag in ~/.ssh/config wie den folgenden:

Host git.example.org
Port 2022
IdentityFile ~/.ssh/gitkey

SSH-Zugriffe auf den Server "git.example.org"  erfolgen also auf Port 2022 (statt 22) und unter Verwendung des Schlüssels "gitkey". Der Git-Zugriff via SSH berücksichtigt diese Einstellungen dann automatisch.

Was aber tun, wenn man von demselben Client mit mehreren verschiedenen SSH-Schlüsseln auf denselben Server zugreifen muß, wie es insbesondere bei der Verwendung von Tools wie gitosis auf der Serverseite vorkommen kann? Dieselbe Frage stellt sich natürlich, wenn man sich neben dem Zugriff auf ein Git-Repository auch ganz normal per SSH auf dem Server einloggen können will. Auf die obige Art und Weise läßt sich nur ein Key für den Zugriff auf "git.example.org" vordefinieren - und will man wirklich immer einen abweichenden Schlüssel per Option angeben? Eine Lösung wäre die Vergabe von weiteren CNAMEs im DNS für git.example.org, aber das skaliert auf die Dauer auch nicht.

Die einfachste Lösung dafür bieten Aliase direkt in der SSH-Konfiguration, wie das Git-Wiki empfiehlt:

Host private.example.com
    User myname
    Hostname git.example.com
    IdentityFile ~/.ssh/private-identity
Host public.example.com
    User groupname
    Hostname git.example.com
    IdentityFile ~/.ssh/public-identity

Auf diese Art und Weise kann man denselben Server mit zwei verschiedenen Konfigurationen ansprechen.

"Tips und Tricks für den Umgang mit git" vollständig lesen

Neustart von Diensten nach Updates - checkrestart

Als Hobby-Admin *räusper* lernt man ständig dazu. Bekannt und bewußt war mir schon, daß nach (Sicherheits-)Updates von Bibliotheken, die von verschiedenen Programmen genutzt werden (man denken an OpenSSL), die entsprechenden laufenden Prozesse neu gestartet werden müssen, weil sie nur dann die dynamisch geladenen Bibliotheken neu laden und zuvor mit der alten Version arbeiten, was insbesondere bei sicherheitsrelevanten Updates nicht besonders hilfreich ist. Bisher ging ich allerdings (blauäugig) davon aus, daß die Paketverwaltung das schon richten wird. Durch einen Beitrag von Paul Wise in der Debian-Developer-Mailingliste wurde mir nun bewußt, daß das - jedenfalls / auch unter Debian - nicht der Fall ist, die betreffenden Dienste also manuell neu gestartet werden müssen.

Hilfreich ist in diesem Zusammenhang das im Paket debian-goodies enthaltene Tool checkrestart, das überprüft, welche laufenden Prozesse noch auf Dateien zugreifen, die mittlerweile gelöscht wurden, und diese auflistet (zusammen mit ggf. vorhandenen init-Scripts, um die Dienste neu zu starten).

Digitale Ausstellungsstücke

Wer (digitale) Fotos - in welcher Menge, Häufigkeit und Qualität auch immer - macht, der kennt das Problem, sie online verfügbar zu machen. Gut, das eigentliche Problem ist die Überwindung der eigenen Faulheit und das Auswählen, Sortieren, Umbenennen und ggf. Kommentieren einmal wirklich anzugehen, aber man möchte dazu auch die entsprechende, möglichst einfach verwendbare, aber alle notwendigen Funktionen bietende Software haben.

Man kann dazu Web-2.0-Dienste wie flickr nutzen, aber nicht jeder möchte das, sei es, daß man solchen Diensten generell nicht traut und/oder die Software lieber selbst installieren möchte, sei es, daß man am "Sharing" von Fotos gar nicht interessiert ist, sondern den Zugriff potentiell nur wenigen ermöglichen möchte. Insoweit habe ich dann schon einiges durch: mehr schlecht als recht selbst gebaute Implementationen für die Webseiten meiner Hilfsorganisation oder einer Newsgroup (seit ~ 2002), dann für meine private Homepage (ebenfalls seit ~ 2002) mig, ein sehr einfaches Script (auch deshalb, weil man von den Platzhirschen wie Gallery nicht viel Gutes über die Sicherheit hörte), und seit Anfang 2008 (nach dem Erhalt meiner neuen Kamera Weihnachten 2007) auch eine Gallery-2-Instanz, mit der ich allerdings nie so recht angefreundet hatte (zumal bis zu einem Kurzurlaub 2008 zurück noch Bilder zum Sortieren und Hochladen im Backlog liegen - siehe die einleitenden Worte zu diesem Artikel ;-)). Während ich jetzt darüber nachdachte, ob sich nicht ein Update auf Gallery 3 anbietet, bekam ich den weisen Rat, mir doch einmal piwigo anzusehen.

Und das hat mich überzeugt. Zumindest dann, wenn man eine Fotogalerie-Applikation nur für sich selbst ohne ausgefeiltes Benutzermanagement für mehrere Fotografen braucht (und wie oft teilt man sich eine Galerie wirklich zu mehreren?), ist piwigo eine tolle Lösung. Installation und Konfiguration sind einfach (Voraussetzungen: PHP und mySQL), wenn man das Prinzip einmal begriffen hat, der Upload ist übers Web wie auch einfach per FTP möglich, Thumbnails werden erstellt, Benutzer können in vorgegebene Rechtegruppen (Gast, Bekannter, Freund, Familie, …) oder in Nutzergruppen eingeteilt werden, und für Alben bzw. Fotos lassen sich dann die entsprechenden Zugriffsrechte setzen. Fotos lassen sich nicht nur in Alben, sondern in Kategorien zusammenfassen und zugleich noch beliebig taggen; der Benutzer kann sich die Fotos nach Kategorien oder Tags oder nach dem Kalender oder sonstwie anzeigen lassen, bekommt dabei aber immer nur die Fotos oder Kategorien zu sehen, für die er entsprechende Rechte hat. Außerdem gibt es eine Reihe vorgefertigter, recht ansehnlicher Skins.

Mir gefällt’s jedenfalls, und ich habe den heutigen Tag dann im wesentlichen dazu genutzt, aus den drei oder vier vorgenannten Quellen der letzten 10 Jahre die dort vorhandenen Fotos in einer Galerie zusammenzuführen und dann den Rest zu löschen. So gesehen also wie gestern ein weiterer Tag des Räumens und Sortierens. :-)

Digitale Archivalien

Stand der gestrige Tag unter dem Zeichen des Umherschiebens von Papier und Geräten, so waren heute Dateien dran.

Meine "IT-Landschaft", wenn man dieses bombastische Wort dafür verwenden darf, ist - wie man so schön sagt - organisch gewachsen und dementsprechend dysfunktional. Früher[tm] saß ich an meinem (einen) Rechner, machte ab und an mal ein Backup, und alles war gut. Neuer Rechner, Kopieren der Daten, voila. Dann begann ich vor knapp 10 Jahren damit, zusätzlich einen Laptop zu nutzen, zuerst nur im Haus, um via WLAN unabhängig vom Arbeitsplatz zu werden, dann aber als täglicher Pendler vor allem auf dem Hin- und Rückweg zur und von der Arbeit. Damit stellte sich dann bald das Problem, wie man die beiden Rechner miteinander synchronisiert - eine Frage, auf die weder Windows (damals Windows 2000) noch der von mir genutzte Mail- und Newsreader Agent (denn das war und ist das meiste, was ich mobil so tue) besonders hilfreiche Antworten zur Verfügung hatten, zumal dann, wenn man auf dem Laptop aus Platz- und Sicherungsgründen nur die aktuellen E-Mails und die Newsgroups-Beiträge der letzten Tage/Wochen hat. Die erste "Lösung" dafür war, News und Mail im wesentlichen auf dem Laptop zu betreiben, die Mails nach Abruf nicht zu löschen und auf dem Desktoprechner dann jeden Abend die Postings und Mails des Tages nochmals (diesmal endgültig) abzurufen und (jahresweise) zu archivieren. Die Outbox vom Laptop ab und an rüberkopieren (und dort löschen), und alles funktionierte, mehr oder weniger, mit einigermaßen vertretbarem Aufwand.

"Digitale Archivalien" vollständig lesen

Drucker-/Scannereinrichtung und Umräumen, Teil II

Nach einer arbeitsamen Woche tauchte heute plötzlich ein so gar nicht vorgesehener Eintrag auf meiner ToDo-Liste auf: Ich erhielt nämlich die Anregung, ich könne bei meiner ganzen Bastelei und Räumerei ja auch einmal zur Abwechslung etwas Sinnvolles tun und den vor vielen (!) Jahren günstig erhaltenen Farbtintenstrahler samt Scannereinheit endlich einmal anschließen, nachdem er mehrere Jahren in der alten und nun auch wieder mehrere Jahre in der neuen Wohnung Staub gefangen hat. Meine vorsichtige Anregung, es wäre doch viel besser, moderner und toller, stattdessen einfach gleich einen neuen Farblaserdrucker als Multifunktionsgerät zu kaufen wurde ohne weitere Aussprache abgelehnt, also habe ich mich dem Schicksal gefügt und meines Amtes gewaltet. Weil ich dann schon einmal dabei war, habe ich den (vorhandenen) Laserdrucker dann direkt ans andere Ende des langen Schreibtischs umgestellt und das "neue" Gerät umgesetzt, dabei diverse Papierstapel an andere Plätze geräumt ("Ablage machen" steht auch noch prominent auf der ToDo-Liste) und nach einigem hin und her dann auch Treiber und passende Software gefunden, um das Gerät in Betrieb zu nehmen.

Danach habe ich dann stundenlang damit gekämpft, den bisher problemlos funktionierenden Laserdrucker wieder in Betrieb zu nehmen … aber jetzt dürfte alles gut sein. Dann noch schnell eine neue Tonereinheit für den Laser bestellen (denn die bisherige versagt jetzt auch nach Schütteln den Dienst) und Farb- und Schwarzpatronen für den Tintenstrahler, damit man damit vielleicht nicht nur scannen, sondern auch wieder drucken kann, und jetzt kann ich wieder zu den Dingen zurückkehren, die auch wirklich auf dem Plan stehen. :-)

(War aber auch mal Zeit, das endlich zu erledigen.)

Update vom 12.01.2011: Die Tintenpatronen sind jetzt da und eingesetzt, meinen Nagel habe ich mir abgebrochen *seufz*, und der Drucker (übrigens ein Canon MP360) spuckt immer noch nur weißes Papier aus. Vermutlich hat der Druckkopf den jahrelangen Stillstand nicht verkfraftet, das soll eine Krankheit dieser Geräte sein, wie man liest. Wasser half auch nicht, also werde ich das Projekt "kaputt ist er nun schon, schlimmer kann’s also kaum werden, und wo ich jetzt Tinte gekauft habe, will ich auch drucken" demnächst mal mit Alkohol fortsetzen. Wenn das alles nicht hilft, kann ich ja meiner Anregung noch einmal näher treten. ;-)

Update vom 15.01.2011: Auch das Einlegen der Druckköpfe in Alkohol hat eine Verbesserung nur insofern gebracht, als jetzt ein leichter Rot-Schleier ausgedruckt wird … Also bleibt es erstmal bei einer Nutzung als Scanner, und alles weitere sehen wir später. :-)

Was lange währt ... - Agent 6.0

Seit 1998 ist mein bevorzugter Newsreader für die Newsgroups des Usenets der Forté Agent - damals schon spitze, aber mit lange stagnierender Entwicklung, bis die Rechte an dem Programm 2001 an den ursprünglichen Hersteller zurückgingen und einige neue Versionen erschienen. Bis zur Version 2.0 anno 2004 bin ich den Updates dann auch gefolgt, habe danach aber den Anschluß verloren und krebste seitdem mit einem nunmehr gut 6 Jahre alten (und von der bis zur Version 2.0 im wesentlichen unveränderten Struktur noch deutlich älterem) Programm herum, das nicht nur sehr altbacken wirkte, sondern dessen fehlende Funktionalität mir trotz Unterstützung durch Hamster, Korrnews und Co. zunehmend schmerzhafter bewußt wurde. Zaghafte Versuche mit anderen Clients, aber auch Upgrade-Versuche auf eine aktuellere Version (zuletzt Agent 4.0 anno 2006) habe ich dennoch immer wieder fremdelnd abgebrochen - zu gewöhnt war ich an die Bedienphilosohpie und die in über 10 Jahren in Fleisch und Blut übergegangenen Shortcuts, zu groß erschienen mir die Defizite der Alternativen.

Endlos kann das aber so natürlich nicht weitergehen, und heute war dann der große Tag: ich habe eine aktuelle Agent-Version 6.0 installiert, die Daten aus der alten Version herübergezogen und, soweit ich sehe, alles wieder so eingerichtet, wie ich es haben möchte. Bei dieser Gelegenheit habe ich dann endlich auch mit dem Unsinn des Parallelbetriebs von 2-3 Agent-Instanzen auf mehreren Rechnern aufgehört: auf dem Laptop News und Mails lesen und beantworten, aber - um früher einmal die Installation schlank zu halten - nicht archivieren, sondern löschen, mit einer dazu passenden Ordnerstruktur, auf dem Desktoprechner alles noch einmal herunterladen und zum Archivieren sortieren sah mal wie eine gute Idee aus, führt aber unterm Strich zu einem immensen Aufwand und zugleich dazu, daß man sein Mailarchiv nie da hat, wenn man es mal braucht. Das gilt natürlich insbesondere dann, wenn der betreffende Desktoprechner an einem Ort steht, an dem man nur noch alle paar Wochen vorbeikommt … Ich glaube, insofern jetzt aber eine brauchbare neue Struktur gefunden zu haben. Der Feinschliff kommt dann in den folgenden Tagen und Wochen, immer dann, wenn es hakt. :-)

Ein neuer Homeserver

Eigentlich wollte ich bereits vor gut zwei Jahren die Gelegenheit der Wohnungseinrichtung nutzen, mal einen neuen Rechner anzuschaffen, der dann als lokaler Server bereitsteht und vor allem auch die Dienste des bisherigen Geräts am alten Standort übernimmt: neuer, besser konfiguriert und vor allem unmittelbar erreichbar und nicht über eine dünne DSL-1000-Leitung angebunden und für Vor-Ort-Eingriffe eine dreistellige Anzahl Kilometer entfernt (die damit verbundenen Probleme habe ich ja in den vergangenen Jahren bereits mehrfach geschildet). Irgendwie hatte dann aber immer anderes Vorrang …

Nunmehr war es aber soweit, und noch am gestrigen letzten Tag des alten Jahres habe ich zugeschlagen und die bestellte neue Maschine abgeholt. Jetzt muß sie "nur noch" eingerichtet und konfiguriert werden. Mal gucken, ob das nochmal zwei Jahre braucht … ;-)

Zwischen den Jahren: Updates und andere Kleinigkeiten

Wie bereits vor einem Jahr habe ich die arbeitsfreien Tage "zwischen den Jahren" wieder zumindest teilweise dafür genutzt, allerlei Kleinigkeiten zu erledigen. Dazu gehört das Sortieren des Rechners bzw. der Rechner, das Installieren der zusammengekommenen Updates von Webapplikationen und anderer Software, das Aufräumen, das Abheften der oft lange gestapelten Post, diverse immer wieder aufgeschobene Bestellungen, das Beantworten einiger - bis jetzt leider längst nicht aller - E-Mails und was sich auf der nach unten offenen Todo-Liste sonst noch so alles angesammelt hat.

Immerhin sind die Updates jetzt (fast) alle erledigt, und auch im Arbeitszimmer sieht es deutlich ordentlicher aus. Eine Phalanx von Ablageordnern stapelt sich auf dem Schrank und wartet darauf, systematisch befüllt zu werden, Altpapier stapelt sich (erneut) zu großen Haufen. Alte Hardware ist an der bekannten Stelle aufgelistet, um abgegeben zu werden, und wir haben uns jetzt einen ruhigen, gemütlichen Abend verdient. :-)

Mehr Power!

Es ist offensichtlich etwas dran an der Bemerkung, man müsse nicht nur Batterien, sondern auch Akkus als Verbrauchsmaterial auffassen …

Mein Laptop (in Betrieb seit Mitte 2008) brauchte nach etwas mehr als einem Jahr einen neuen Akku, weil der originale einfach die Grätsche machte (durch die Elektronik als "defekt" erkannt - da rückt und rührt sich dann nichts mehr). Nachdem seine Leistung ohnehin schon nachgelassen hatte, fiel es mir dann leicht, schlicht Ersatz zu kaufen (wenn auch zu eher wenig günstigen Preisen). Dieser Ersatz allerdings fing nach einem weiteren Jahr (trotz zumindest anfangs möglichst akkuschonender Nutzung) dann arg zu schwächeln an; Laufzeiten von einer Stunde und weniger empfinde ich weder als praktikabel noch als zeitgemäß. Also habe ich erneut Ersatz beschafft, was mir diesmal deutlich leichter fiel als beim ersten Mal (wenn man sich erst einmal durch die völlig widersprüchlichen Artikel-, Bestell- und FRU-Nummern gewühlt hat, muß man nur noch gucken, was man beim letzten Mal geordert hat), und hatte heute dann Gelegenheit, den neuen Akku einzusetzen und über Nacht laden zu lassen.

Was soll ich sagen? Ich habe jetzt wieder Laufzeiten von rund 3 Stunden … und dieser Akku hat eine Kapazität von 5.2 AH aufgedruckt, wie auch der erste. Der zweite hatte nur 4.2 AH, obwohl beim selben Anbieter unter derselben Bestellnummer geordert - vielleicht mag auch da ein Grund für die schwache Leistung liegen.

Strato stromlos

Gestern abend kippte einer der von mir betreuten Server gegen halb zehn plötzlich aus dem Netz und war auch weder über die virtuelle Konsole zu erreichen noch für einen Reboot über das Webinterface zu begeistern (das sich auch sehr zähflüssig anfühlte). Eine andere dort gehostete Maschine blieb aber erreichbar. Noch während der Fehlersuche, gegen viertel vor elf, war die Maschine dann wieder da; nach den Logfiles ist sie eben zur o.g. Zeit stehengeblieben und hat dann kurz vor elf rebootet.

Nachdem ich beschlossen hatte, Ursachenforschung lieber erst am Folgetage - heute - zu betreiben, und das Bett aufgesucht hatte, fand ich dann heute morgen nochmals Mitteilungen der Serverüberwachung, daß um halb zwei noch einmal ein rund zehnminütiger Ausfall zu beklagen war, der sich in den Logs im übrigen wie zuvor darstellte.

Des Rätsels Lösung konnte man dann u.a. bei Isotopp und im Webinterface von Strato (und bei Twitter …) nachlesen: es gab einen Stromausfall, und ein Teil der Server wurde von einem Versagen der USV getroffen. Kann passieren, kann man nichts machen. (Aber eine Information per E-Mail (!) an die Kunden hätte ich im Nachgang schon ganz nett gefunden.)

RBLs, RBL-Checks und "sie wissen nicht, was sie tun"

RBLs (Realtime Blackhole Lists) sind mittlerweile über ein Jahrzehnt alt und eine weitverbreitete Methode der Filterung unerwünschter E-Mails. In diese Listen, die über das DNS propagiert werden, trägt der jeweilige Betreiber nach seinen Kriterien die IP-Adressen von Hosts ein, die gefiltert werden sollen. Manche dieser Listen sind sinnvoll, andere sind es nicht; manche zählen Spam-Quellen auf, offene Proxies und Relays, von Malware befallene Systeme, andere jedes System, dessen Betreibers Nase dem RBl-Provider nicht passt. Wer RBLs einsetzt, muß sich also informieren, welche Policy eine RBL verfolgt, und wie zuverlässig sie das tut.

Neben den RBLs gibt es auch Anbieter, die prüfen, ob bestimmte Systeme auf diesen RBLs landen; das sollte jeder Admin größerer Mailsysteme eigentlich selbst tun, um ggf. (das für die Listung ursächliche Problem zu beheben und dann) die Löschung von der jeweiligen RBL zu veranlassen, aber für diejenigen, die das nicht tun können oder möchten, sind solche Angebote sicher interessant. Nur sollten diese Anbieter von RBL-Checks auch wissen, was sie da eigentlich tun, was wohl nicht immer sichergestellt ist …

Ich bekam jedenfalls dieser Tage (mal wieder) einen Hinweis, eines meiner Systeme sei in der RBL hostkarma.junkemailfilter.com gelandet; wie der Name andeutet, versucht deren Betreiber Mailserver in gute, schlechte oder neutrale einzuteilen. Wie zuvor habe ich daraufhin mein System auf den Webseiten des RBL-Betreibers geprüft und bekam - wie immer - als Antwort, das System sei nicht gelistet. Diesmal bin ich der Sache nachgegangen und habe festgestellt, daß der RBL-Check-Anbieter grundsätzlich Recht hat: meine Maschine war tatsächlich in der RBL eingetragen! Aber warum bestreitet das der RBL-Provider dann? Nun, meinem System war dort der Wert "127.0.0.1" zugewiesen. Und der RBL-Provider meint zu diesem Wert folgendes:

127.0.0.1 - whitelist - trusted nonspam

Danke, keine weiteren Fragen mehr.