Daran, dass der jeweils neueste (Alpha-) BOINC-Client beim Reaktivieren der Netzwwerkverbindung ganz gerne mal abstürzt, habe ich mich ja schon gewöhnt. Dann warte ich eben, bis die Wissenschaftlichen Anwendungen nach 30 Sekunden ohne heartbeat vom Client sich beenden, und starte den BOINC-Manager neu. Heute früh hat das aber nicht gereicht. Anscheinend hat der CoreClient die client_state.xml in einem inkonsistenten Zustand hinterlassen, beim Neustart waren jedenfalls alle Tasks weg. Zu meiner großen Freude habe ich aber eine Kopie der client_state.xml von vor einer Woche wiedergefunden, die ich dann testhalber mal eingesetzt habe (Ich lege ja keinen gesteigerten Wert darauf, die bisher erbrachte CPU-Zeit für CPDN zu opfern oder die noch offenen QMC-Tasks von
Anfang Juli. Der Versuch hat auch insofern funktioniert, als eben diese Tasks dem CoreClient wieder bekannt waren. Zusätzlich waren allerdings auch ein paar Tasks enthalten, die inzwischen schon erfolgreich berechnet, hochgeladen und zurückgemeldet worden waren. Diverse Tasks haben recht schnell ihre Eingabedateien vermisst und sind mit Berechnungsfehlern abgebrochen. Zur Sicherheit, dass ich nicht QMC-Tasks doppelt berechne, habe ich auch noch zwei Tasks manuell abgebrochen, aber ob das reicht, weiß ich erst, wenn die erste Task demnächst zurückgemeldet wird. Sicherheitshalber habe ich eben noch eine Kopie der client_state gemacht, man weiß ja nie, ob das Problem nicht demnächst wieder zurückkommt.
So, jetzt habe ich nicht nur einen halbautomatischen Spam-Trainer für
meinen SpamAssassin, sondern auch einen Ham-Trainer, der einfach alle MAil-Verzeichnisse kopiert, und dann darauf
sa-learn --ham aufruft. Okay, der Kopierschritt kann noch verbessert werden, ich lasse den im Moment einfach mal die einzelnen Verzeichnisse händisch kopieren. Das ist zwar nicht sonderlich eleganz, aber es funktioniert. Immerhin muss ich mir keine Sorgen darüber machen, dass mal versehentlich der SPAM als ham gelernt wird.
Als ich eben hier ankam, durfte ich feststellen, dass mein Lieblingsrechner wohl ziemlich früh ziemlich deutlich abgestürzt ist, weil er irgendwie den Festplattenzugriff verloren hatte. Das heißt, mein RSS-Reader konnte nicht tagsüber sammeln und auch mein Mail-System hat keine Mails abgeholt. So ein beherzter REboot muss manchmal einfach sein... :mad:
Nach der
Einrichtung des Mail-Servers sind ganz offensichtlich nicht alle SpamAssassin-Module aktiv gewesen. Auch, wenn der Heise-Text darlegt, Razor2 wäre automatisch aktiv, muss das wohl noch in der Konfigurationsdatei des SpamAssassin aktiviert werden. Mit aktivem Razor2 erwischt der Assassin aber deutlich mehr unerwünschte Mails als vorher.
"Weitergebastelt" vollständig lesen
Ich hab dann gestern Abend noch den lokalen Mailserver von der
Todo-Liste abgearbeitet. Mittlerweile scheint das auch soweit zu funktionieren. Nur mein Google-Mail-Account läuft noch nicht über den Server, weil ich erst noch herausfinden muss, wie ich fetchmail dafür konfigurieren muss. Der Spam-Mörder (aka
Spamassasin) funktioniert jedenfalls schon brav.
Bei der Einrichtung habe ich mich an die Anleitung von Heise open gehalten, wenn man mal davon absieht, dass ich nicht extra einen Server für den Mail-Empfang freigestellt habe, sondern einfach meinen normalen Desktop-Rechner verwende. Allerdings sind ein paar Änderungen im Vergleich zu der Anleitung nötig gewesen.
Achtung, es folgt Geek-Content!
"Bastelei" vollständig lesen
Warum kann eigentlich mein Mail-Filter (Thunderbird 1.5 mit eingebautem Spam-Filter) nicht so gut funktionieren, wie der
Blog-Filter? Okay, zugegeben, ich habe eit einiger Zeit nur falsch Negative, will heißen, der Donnervogel meint, eine Mail wäre kein Werbemüll, dabei ist die Mail eben doch Werbemüll. So nervt das jedenfalls ziemlich.
Da ist man mal kurz nicht da, und schon dreht der BOINC-Client durch.
Ich habe jetzt die lauschige Anzahl von 264 Tasks auf dem Notebook.
Das setzt sich dann so zusammen:
52 x Rosette (drei Stunden Laufzeit, fällig am 8.7.)
51 x Simap (1,5 Stunden jeweils, fällig am 11.7.)
73 x Leiden (Laufzeiten von unter 10 Minuten bis 30 Minuten, fällig am 7.7.)
1 x ClimatePrediction (Rest-Laufzeit von < 2500 Stunden, fällig zu Weihnachten 2007)
9 x Einstein@home (Laufzeiten von knapp 24 Stunden, fällig am 15.7.)
14 x QMC@HOME (Laufzeit von 37 Stunden, fällig am 17.8.)
2 x RALPH (Laufzeit eine knappe Stunde, fällig am 4.7.)
21 x SETI (Laufzeiten zwischen 5 und 10 Stunden, fällig zwischen dem 14. und dem 26.7.)
31 x Seti-Beta (Laufzeiten knapp über 3 Stunden, fällig am 24.7.)
5 x uFluids (Laufzeit je knapp 30 Stunden, fällig am 15.7., die Teile schreiben immernoch keine Checkpoints)
5 x XtremLab (Laufzeit von 10 Minuten, fällig am 6.7.)
Daran hat der neue Scheduler jetzt jedenfalls erstmal zu knabbern. Erstmal versucht er sich an den Leiden-WUs, von denen er gleich vier weggecruncht hat.