p0p0c4t3p3t3l hat geschrieben:
TODO: fetchmailrc and procmailrc examples
TODO: echeck, optional?
Ich denke einfache Beispiele würden schon reichen.
Ich erkläre mal, wie ich es mache, und erzähle dann, was daran alles suboptimal ist.
Status QuoMeine .procmailrc enthält Regeln, die bei eingegangenem Befehl ein Python-Skript startet, das die Mail auseinander zwirbelt, und als Textdatei ins Dateisystem legt. Die Regeln sehen so aus:
Code:
:0
* ^Subject:.*ERE.* BEF.*
| $HOME/bin/orders-accept 2 de
:0
* ^Subject:.*ERE.* ORD.*
| $HOME/bin/orders-accept 2 en
Das sind zwei, weil ich mir für ECheck merken muss, in welcher Sprache die Befehle kamen (das kriegt das Skript als Parameter mit gegeben). Wenn man nur in einer Sprache spielt, oder keine ECheck-Antworten schickt, kann man sich das sparen. Ohne ECheck wird eh alles einfacher.
Fetchmail läuft als Dämon (An der Kommandozeile mit -d 300 für alle 5 Minuten Mail holen), weil mein Rechner permanent am Internet ist, wenn man auf Dial-Up ist (wie in den frühen Jahren des Spieles) muss man das von einem Skript aus triggern, glaube ich. Das habe ich aber nie miterlebt.
procmail selbst wird von fetchmail ausgelöst. Meine .fetchmailrc sieht so aus:
Code:
poll mail.kn-bremen.de with proto POP3
user 'eressea' there with password '********' is eressea here
options nokeep
sslfingerprint 'B0:BD:0C:FF:90:88:28:3E:35:25:C2:85:0A:FD:F6:86'
mda "/usr/bin/procmail -f %F -d %T";
Das holt also die Mail vom user eressea mit POP3 bei mail.kn-bremen.de ab, mit dem Passwort, dass ich hier nicht sage, merkt sich die löscht die Mail anschliessend vom Server (nokeep), und liefert die Mails dann eine nach der anderen an den MDA aus (per stdin an in das procmail-Kommando), macht also einen procmail-Prozess per Mail. Der Prozess forkt dann das o.g. orders-accept Skript. Früher hat das Skript auch ECheck sofort mit gemacht, damit habe ich mir den Server mal gekillt, weil eine rieisge Menge Mails am Samstag Abend kamen, jede hat ein Trippel aus procmail, python und ECheck Prozessen gestartet, und ECheck hatte eine Endlos-Schleife, die ein Spieler scheinbar gefunden hatte (von dem die ganzen Mails waren). Bravo. So also besser nicht implementieren.
Das SSL Zertifikat des Servers ist self-signed und machte mal Probleme, deshalb ist der Fingerprint dort mit angegeben, aber normal braucht man den nicht, glaube ich.
Fehlt also nur das sagenumwobene Skript, dass die Mails liest. Das kann MIME Attachments lesen, und muss die Befehle in UTF-8 umwandeln. Dann legt es sie (bei mir) in ~/eressea/game-2/orders.dir ab, ein Verzeichnis, dass jede Woche vor der Auswertung rotiert wird (umbenannt in orders.dir.
turn). Jede Befehlsabgabe ist eine einzelne Datei, deren Datum im Filesystem nach dem Date: Header der Email gesetzt wird. Die Auswertung nimmt diese Dateien in chronologischer Reihenfolge (ls -rt), und schmeißt sie alle hintereinander mit cat in eine gemeinsame Datei orders.
turn, die den Input für den Server darstellt.
Hier ist mein orders-accept Skript:
https://github.com/eressea/server/blob/ ... ers-acceptDas Skript schreibt außerdem eine Datei orders.queue, in der Metadaten stehen: Dateiname, Absender, Sprache, die für einen ECheck-Prozess verwendet werden. Das ist ein Cronjob, der auch alle 5 Minuten läuft, und diese Datei anschaut. Wenn was drin steht, wird Echeck über die Datei gemacht, und eine Mail mit dem Ergebnis an die Absender-Adresse geschickt. Außerdem testet dieses Skript auch noch das Passwort, was nicht zu einer Ablehnung der Befehle führt (das macht der Server chon selber), aber zu einer Warnung an den Spieler.
Das Skript ist diese hier:
https://github.com/eressea/server/blob/ ... rs-processKritikDas ganze ist ziemliches Hack. Metadaten liegen in Dateien, die teilweise mit Lockfiles gegen gleichzeitige Benutzung gesperrt sind, teilweise nicht (aua). Die orders.queue Datei ist ganz schlimm. Der ECheck-Cron regt sich bei jeder Auswertung einmal auf, weil die Dateien, die in orders.queue stehen, nicht mehr im orders.dir Verzeichnis liegen, weil das seitdem vom Auswertungs-Prozess rotiert wurde. Die Befehls-Dateien müssen eindeutige Namen haben, was ganz sicher eine Race-Condition hat. Ich hänge einfach eine Zahl an die Absende-Adresse, gucke ob es die Datei mit dem Namen schon gibt, und erhöhe die Zahl um 1, bis dem nicht so ist, dann speichere ich. Wenn das zwei Prozesse gleichzeitig machen, geht das bestimmt schief, aber es scheint eh niemand auf die "Befehle erhalten" Emails zu schauen... Das ganze hat nur unzulängliches logging, wenn also mal etwas schief geht, ist es schwer nachvollziehbar, was los war.
Ich würde da heute eine SQLite Datenbank für den ganzen Kram benutzen, wenn ich es neu machen würde. Für die Interaktion mit ECheck, die Metadaten (Absender, Dateiname, Datum), und den Passwort-Check mindestens. Andereseits soll man ja in "Running System" niemals anrühren, deshalb ist das alles nur auf meiner Featurewunsch-Liste, zu der ich wohl eh nie kommen werde.