Inzwischen habe ich Zeit gehabt, mein EMail-Setup im Alltag zu testen und noch ein paar Verbesserungen anzubringen. Die größte Änderung ist dabei die Einbindung von procmail gewesen.

Gefiltert

Ich bin ein großer Freund von Mailinglisten, und komme allein deswegen um das Filtern nicht herum (lies: Listenmail soll in passende Ordner wegsortiert werden, um den Posteingang freizuhalten). Bei dienstlichen Mails habe ich dafür auf die etwas umständlich einzurichtenden Filterregeln des Exchange-Serers zurückgegriffen, privat Mails blieben einfach ungefiltert, weil mein Provider hier nichts anbietet. Beides ist kein haltbarer Zustand, es musste also eine lokale Lösung her.

Geliefert

Procmail ist ein Mail delivery agent (MDA), der sehr mächtige Filterfunktionen bietet (die weit über das bloße Wegsortieren hinausgehen). Diesen galt es jetzt nur noch mit offlineimap zu verheiraten. Mein erster Ansatz -- ein Cronjob, der die gesammelten Mails auf Neuzugänge durchsucht -- erwies sich als unzureichend:  viel zu leicht hat man eine exponentiell arbeitende Mail-Loop gebaut. Hier lohnt es sich gar nicht, die genauen Fehler zu suchen, denn schon das Konzept stimmt nicht: ein MDA stellt Mail zu, wenn aber offlineimap die lokalen Mails mit dem Server abgleicht, sind sie schon längst zugestellt.

Gekriegt

Ich musste also die Mail aus der Inbox des Servers erst zustellen, bevor offlineimap sie zu Gesicht bekam. Dazu kann man z.B. Fetchmail verwenden oder aber das modernere getmail. Dessen Autor hat übrigens ein paar deutliche Worte für fetchmail übrig. 

Ich habe mich dann für einen Fork entschieden, der auf meine verschlüsselte Passwortdatei zugreifen kann:

passwordeval = gpg -d ~/.mutt/pw.gpg |awk '/my_gwdg/{print $NF}' |tr -d '"'

Getmail kann die Zustellung an Procmail delegieren:

[destination]
type = MDA_external
path = /usr/bin/procmail
arguments = ("$HOME/.procmailrc.gwdg",)

[options]
delete = true
message_log = ~/Mail/getmail.log

Die Inbox liegt in der Mailverarbeitung jetzt also vor der Zustellung und ist für offlineimap tabu:

folderfilter = lambda folder: folder not in ['INBOX']

Das heißt andererseits, daß ich lokal einen neuen Posteingang brauche, damit offlineimap diesen wieder mit dem Server synchronisieren kann. Das geht mit einer passenden Zeile in der procmailrc:

DEFAULT=SPOOL/

Fazit

Jetzt word meine Mail per Getmail vom Server nur aus der Inbox abgeholt, üer procmail hefiltert und zugestellt, befor sie per offlineimap wieder auf dem Server landet, und zwar schön sortiert in Dutzenden von Ordnern -- bloß nicht in der Inbox, sonst haben wir doch woeder eine Loop. und hanz nebenbei bietet mir procmail die Möglichkeit, nach Herzenslust Mailinglist-Tags aus Betreffzeilen zu entfernen oder z.B. Mails von mir an mich gleich in Todos zu verwandeln.

Kein Kommentar

von kirjoittaessani


Ein paar Gedanken zu Terror der Tentakel von A. Lee Martinez:

Für eine richtige Rezension fehlen mir Zeit und Lust, aber zwei Punkte, die mich besonders gestört haben, will ich erwähnen. Zum einen vermisse ich "Show, don't tell" -- stattdessen finden sich endlose, ziemlich witzlose Dialoge, die die Story voranbringen sollen. Zum anderen gibt es viel zu viel erzählerische Magie -- ob die Handelnden z.B. einen Kampf gewinnen oder durch Konstruktion einer aberwitzigen Maschine einen Ausweg aus einer schwierigen Lage finden, richtet sich rein nach den Wünschen des Autors, ist aus der inneren Logik der Geschichte aber nicht zu erklären. Da müssen drei von fünf Sternen reichen. 

Kein Kommentar

von kirjoittaessani


Als ich vor einigen Monaten meinem alten Betriebssystemhersteller wegen seltsamer Allüren die Gefolgschaft aufgekündigt habe, mußte unter anderem Ersatz für das Mailprogramm her. Ich habe mich ein bißchen im Netz schlau gemacht und festgestellt, daß die beiden verbreitetsten Alternativen Thunderbird und KMail sind. Ersteres sollte wohl das bessere Programm sein. 

Ich habe mich anfangs etwas schwergetan, weil das Ganze doch eine ziemlich hakelige Angelegenheit war. Im Läufe der Zeit reifte dann die Erkentnis, das Thunderbird schlicht unbrauchbar ist: an allen Ecken hakelt es, manches ist lahm, anderes geht nicht, und man hat kaum eine Chance, den Grund herauszufinden. Den meisten Benutzern dürfte das nicht einmal auffallen, weil ein Großteil heutiger (GUI-) Programme solcherlei Probleme aufweist, miese Softwarequalität ist die Norm. 

Durch einen Tipp von Digastricus bin ich dann bei Mutt gelandet -- und mußte mich fragen, was mich vor Jahren geritten hat, dieses Programm aufzugeben. Ich kann nur vermuten, daß es Eye Candy bei Apples Mailprogramm war.

Jetzt habe ich jedenfalls zurückgefunden und bin vollauf zufrieden. Selbst exotischere Wünsche sind kein Problem: zum Beispiel kann ich für unterschiedliche Empfänger auch unterschiedliche Absenderadressen verwenden (wichtig bei Mailinglisten).

Links

Caleb McDaniel hat mir bei der ersten Konfiguration geholfen und nebenbei dafür gesorgt, daß ich mit GTD angefangen habe -- auch eine lohnende Sache. Bei Superuser gibt es einen Tipp zur sicheren Passwort-Konfiguration. Inzwischen verwende ich Offlineimap, die verschlüsselte Passwortdatei funktioniert aber auch hier. Die Einrichtung von Offlineimap, notmuch (Volltextsuche) und nottoomuch (Adressliste) ist beim Tshirtman beschrieben. 
Überhaupt hat mir die ganze Geschichte deutlich die Vorteile der Kommandozeile (mit der ich ohnehin jeden Tag arbeite) vor Augen geführt, aber das hebe ich mir für einen anderen Post auf.

1 Kommentar

von kirjoittaessani


12 Jahre Kartoffeln.

Da ist wohl ein Ersatzteil fällig.

Kein Kommentar

von kirjoittaessani


Tags:

Ich bin in den letzten Wochen ein wenig in die axiomatische Mengenlehre gerutscht. Das meiste ist ziemlich einfach und einleuchtend. Auch bei \emptyset=\{x:x\neq x\} habe ich nicht zweimal hingesehen.

Bei \emptyset=\{x:x = x\} allerdings schon.

Stimmt aber. Sauber aus den Axiomen hergeleitet und konsistent.

Kein Kommentar

von kirjoittaessani


Schon etwas älter, aber heute wieder mal gehört, als er auf den Arm wollte:

Ich will tragen gewerdt.

Kein Kommentar

von kirjoittaessani


Maailman ja ihmisen väliin tarvitaan jotain pehmeää

Kein Kommentar

von kirjoittaessani


Jetzt ist also Firefox der letzte größere Community-Browser.

Tschüß, Camino. Es war schön mit Dir.

Kein Kommentar

von kirjoittaessani


Vor ein paar Wochen hatte ich von Gitzilla berichtet, das aus git-Commits automatisch Bugzilla-Kommentare generiert. Gestern ist mir eine neue Idee gekommen. Dazu muß ich aber etwas weiter ausholen.
Ein Rechencluster funktioniert ein bisschen wie eines von den ganz alten Rechenzentren. Dort hat man sein Programm in Form eines Stapels Lochkarten abgegeben. Wenn ein Rechner frei wurde, hat ein RZ-Mitarbeiter (Operator) den Stapel abarbeiten lassen, und das Ergebnis wurde vom Schnelldrucker ausgegeben, so daß man es sich später abholen konnte.
Heutzutage ist der Lochkartenstapel einer Datei gewichen, die Aufgabe des Operators hat eine Software namens Batch-System übernommen, und die Ausgabe landet statt auf dem Schnelldrucker auf der Festplatte -- aber das Prinzip ist gleich geblieben, interaktives Arbeiten wie auf dem PC am Arbeitsplatz gibt es hier nicht.
Unser Cluster ist meist bis zum Anschlag voll mit Jobs, aber gelegentlich sind doch einige Nodes frei -- besonders die älteren haben nicht immer voll zu tun. Weil Strom teuer ist,[1] haben wir ein Lights-Out-Management, das unbenutzte Nodes abschaltet.[2]
Idealerweise sollte das vom Batchsystem erledigt werden, denn das ist die Instanz, die am besten weiß, welche Sorte Nodes wann in welcher Zahl benötigt wird. Die SGE kann das aber nicht, und so läuft bei uns ein externes System. Neben dem bloßen Ein- und Ausschalten nach Bedarf kann es auch noch ein paar weitere Sachen, zum Beispiel kann man defekte Nodes als "poweroff" markieren.
Das Lightsout-Management solche Nodes dann für neue Jobs, wartet ab, bis die aktuellen abgearbeitet sind, und schaltet die Node dann ab. Jetzt kann sich einer der Kollegen an die Reparatur machen -- wenn er merkt, das die Node aus ist.
Da wäre es doch schön, Lightsout und Bugzilla so zu integrieren, das eine Meldung über das Abschalten gleich in dem Bug erscheint, der für die defekte Node angelegt worden ist. Ich habe große Teile des heutigen Tages damit verbracht, eine sinnvolle Implementation dazu zu finden -- aber viel gebracht hat das nicht, außer, daß ich einiges über Web-Services gelernt habe. Die Kurzform geht ungefähr so: es gibt verschiedene Protokolle, z.B. JSON, REST, XML/rpc und SOAP. Leider unterstützt Bugzilla nur JSON und XML/rpc, für Ada habe ich aber nur eine Bibliothek für SOAP gefunden.[3] Da ist wohl eine Eigenentwicklung angesagt. Look for me on Github. Mal sehen, wie aufwendig das wird.

  1. typischerweise erreichen die Stromkosten über drei Jahre Dauerbetrieb den Anschaffungspreis
  2. und bei Bedarf natürlich auch wieder an
  3. Und REST? Mir schwirrt schon der Kopf
Kein Kommentar

von kirjoittaessani


(Hinweis: der Artikel ist sicher leichter zu verstehen, wenn man sich die Grafik auf Vincents Seite daneben legt)

Nachdem ich Gitflow nun einige Zeit in mehreren Projekten verwendet habe, möchte ich noch ein paar Dinge berichten, die mir aufgefallen sind. Zur Erinnerung: Man benutzt mehrere Zweige,[1] die nebeneinanderher laufen. Neben develop, auf dem die Entwicklung vorangetrieben wird, gibt es master, der nur veröffentlichte Versionen[2] enthält, Feature-Zweige (auf denen größere Neuerungen entwickelt werden; ein Zweig pro Feature), Hotfixes[3] und Releases.[4]

Man kann zwar mehrere Feature-Zweige gleichzeitig offen haben, um einen neuen Hotfix- oder Release-Zweig zu starten, muß der vorhergehende aber abgeschlossen werden. Das war zunächst etwas schwer verdaulich für mich, ist aber letztlich sicher sinnvoll: Releases folgen aufeinander, sie können nicht parallel laufen; eigentlich könnte man auch mit einem einzigen Release-Zweig leben, nur wird dann das Tagging schwieriger. Für Hotfixes gilt das nicht so eindeutig, aber git flow verwendet einen Hotfix-Zweig pro Version, nicht einen pro zu behebenden Bug.

Heute habe ich dann etwas Dummes gemacht: nachdem ich einige Zeit an Feature X gearbeitet hatte, habe ich ein paar Bugs in der Produktionsversion behoben -- ein klassischer Hotfix. Die git flow Tools sorgen dafür, daß diese Fehlerkorrekturen in develop und in den Releases auftauchen -- nur mein Feature-Zweig war weiter verbuggt. Was tun? Ich habe mich dafür entschieden, den Feature-Zweig mittels Rebase an der aktuellen develop-Version zu starten. Das war ein großer Fehler. Durch das Rebase gab es nämlich Diskrepanzen zwischen meinem lokalen Repository und der zentralen Version, die sich nicht leicht (und vor allem nur fehleranfällig) korrigieren ließen. Git flow bemerkt das auch und verweigert an viele Stellen gleich den Dienst. Ich habe es zwar hinbekommen, aber mein Commit-Graph ist ziemlich unübersichtlich geworden.

Lektion gelernt: man kann jederzeit Feature-Zweige nach develop Mergen,[5] aber nicht umgekehrt. Die letzten Bugfixes sind bei einer reinen Entwicklerversion oft auch überflüssig; und wenn man sie wirklich braucht, ist wahrscheinlich Cherry-Picking die beste Methode.

Übrigens hat git eine unangenehme Eigenschaft, die mich überhaupt erst in diese missliche Lage gebracht hat: Man kann die Geschichte umschreiben (rewriting history), i.e. es gibt git-Kommandos, die nicht nur neue Vertizes zum Commit-Graphen hinzufügen, sondern bestehende Vertizes löschen oder ändern. Das widerspricht meinen Erwartungen an ein Versionskontrollsystem sehr, es liegt aber wohl im Konzept der verteilten Repositories, und ließe sich nur mit schweren Nachteilen ausschließen.

  1. Branches
  2. oder zumindest solche, die man veröffentlichen könnte
  3. schwerere Bugs, die zwischendurch behoben werden müssen
  4. Feinschliff zur nächsten Version
  5. ich schrieb ja schon, daß man diese Begriffe nicht sinnvoll übersetzen kann
Kein Kommentar

von kirjoittaessani