[Benji]

Alles klar, danke euch!

Soll ich mit dem Test von nullmailer noch warten bis das mit dem Prefix geklärt ist, oder soll ich schon loslegen?

Ich hab kein Problem mit /usr/local, nur wenn das morgen auf / geändert ist, wäre es verschenkte Lebenszeit :-)

[P3f]

Hallo Michi,

Den Prefix Eintrag habe ich nun eingebaut und auch neu bereitgestellt. Am besten gehst Du auf das vorherige Backup zurück? Kennst Du die Funktion „snapshot_manager“ auf der linuxshell schon ?

Gruß,

Pit

[Benji]

Hallo Pit,

jetzt isses leider "verschlimmbessert":

mld> strace nullmailer-send

Code: [Select]

openat(AT_FDCWD, "/home/unstable/nightbuild/amd64/nullmailer/src/nullmailer-2.2/usr/local/var/spool/nullmailer/trigger", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)

gestern wars noch "/usr/local/var/spool/nullmailer/trigger", bedingt durch PREFIX=/usr/local

es sieht für mich aus als hättest du den PREFIX komplett entfernt (was dazu führt dass 'cwd' verwendet wird), ich denke der müsste aber auf "/" gesetzt werden

(Falls diese Sourcen bzw. das Makefile noch mit PREFIX arbeiten, ist schon etwas her bei mir)

lg Michi

[P3f]

Hi Michi,

Also nun ist ein neues Paket online, da ist die Variable

Code: [Select]

QUEUE_DIR[]="//var/spool/nullmailer"; (der doppelte Slash sollte nicht stören.

Das Verzeichnis /var/spool/nullmailer können wir doch verwenden und dort auch den Trigger einbauen, oder?

Aktuell hab e ich es manuell gemacht, ohne zu wissen ob es richtig wäre mit den folgenden Befehlen:

Code: [Select]

mkfifo /var/spool/nullmailer/trigger
chmod 622 /var/spool/nullmailer/trigger
Danach erscheint auch die Datei mit den Beschreibungen aus der Dokumentation.

Code: [Select]

prw--w--w-    1 root     root             0 Dec  8 21:40 trigger
Ist das der richtige Weg?

Gruß,

Pit

P.S: Ich habe nun doch noch einen Parameter gefunden und in meinem Develserver eingebaut, bist Du gewechselt auf meinen unstable?

Code: [Select]

extern const char QUEUE_DIR[]="//var/spool/nullmailer";
extern const char CONFIG_DIR[]="//etc/nullmailer";
extern const char PROTOCOLS_DIR[]="/usr/local/libexec/nullmailer";
extern const char BIN_DIR[]="/usr/local/bin";
extern const char SBIN_DIR[]="/usr/local/sbin";

[Benji]

Hallo Pit,

erstmal ein (kleiner) Erfolg! ich habe eine (leider etwas verkrüppelte) Mail erfolgreich versendet.

allerdings musste ich da viel basteln, viel nach /usr/local kopieren usw... das mit dem Prefix haut noch nicht hin!

deine "Anpassung" erscheint mir zu kompliziert, das muss einfacher gehen... ohne euren Build-Prozess zu kennen, nehme ich an ihr verwendet auch automake/autoconf usw.

ein "configure --prefix=/" sollte eigentlich alle Pfade richtig setzen, und du musst nicht mehr einzelne Pfade (wo auch immer) anpassen.

richtig, das Trigger-Fifo solltest du in der /etc/init.d/nullmailer erzeugen. In Debian sieht das so aus:

Code: [Select]

    if [ ! -p /var/spool/nullmailer/trigger ]; then
rm -f /var/spool/nullmailer/trigger
mkfifo /var/spool/nullmailer/trigger
    fi
    chown mail:root /var/spool/nullmailer/trigger
    chmod 0622 /var/spool/nullmailer/trigger

(das "chown" kann man vermutlich weglassen)

und was auch noch ziemlich lästig ist: die ganzen nullmailer-Komponenten machen (derzeit) kein logging. Normalerweise (auf meinen anderen Systemen) wird hier ganz standardmäßig syslog verwendet, und man findet alles in /var/log/messages

Hmmm.... wie kommen wir hier schneller voran? Wie kompliziert ist es, eine (temporäre) Entwicklungsumgebung bei mir aufzusetzen?

lg Michi

[Benji]

Hallo Pit,

erstmal danke für die sehr angenehme und konstruktive Session gestern!

Ich denke wir sind fast am Ziel: Ich habe heute meine erste "schöne" Mail vom EPGSearch bekommen!

wir haben noch zwei Baustellen:

a) der nullmailer installiert zwei Hilfpsprogramme (qmqp und smtp) nach /usr/lib/nullmailer/, sucht sie aber unter /usr/libexec/nullmailer

ich denke da ist noch eine Kleinigkeit im Aufruf von configure anzupassen (ich hab das gestern eh aus dem Augenwinkel gesehen, aber nachdem die zwei Dateien dann unter /usr/lib/nullmailer kamen, hab ich mir erst ncihts weiter gedacht). Ich habe das temporär "gehackt" indem ich /usr/lib/nullmailer nach /usr/libexec/nullmailer kopiert habe (das ist aber uncool)

b) Logging mit syslog: macht er noch nicht, wäre aber wichtig. Das Hilfsprogramm "logger" wäre installiert und funktioniert auch; ich vermute da gehört in der /etc/init.d/nullmailer noch was eingebaut... da habts ihr sicher (von anderen Paketen?) eine Vorlage wo man abschreiben kann.

Kurzer Auflug ins debugging: Beim nullmailer arbeiten ein paar Programme Hand in Hand, und das ist anfangs etwas komplex zu verstehen...

1. /usr/bin/sendmail: das ist ein kleines Frontend zu nullmailer-inject (siehe 2). Wichtig: Das Ding funktioniert nicht wie "mail", sondern erwartet einen kompletten Body (mit Headern!) nach RFC irgendwas. Also ein simples "ech Hallo | sendmail michael@reinelt.co.at" funktioniert zwar, die Mail sieht aber entschieden sehr eigenartig aus. Das ist aber kein großes Problem, weil zB das EPGSearch-Plugin den sendmail bereits korrekt versorgt. Wollte man aber eine "generelles" Mail-Benachrichtigung einbauen, wäre noch ein Frontend (zB bsd-mailx) nötig.

PS das Ding bildet wirklich den guten alten sendmail nach, und über den habe ich ein ca. 8 cm dickes Buch im Regal stehen :-)

2. /usr/bin/nullmailer-inject: der nimmt die Mail (zB von sendmail) entgegen, bastelt noch etwas an den Headern rum, und stellt die Mail dann nach /var/spool/nullmailer/queue. Wenn man sich das ansehen möchte, ist es wichtig dass nullmailer-send NICHT läuft (also vorher mit "/etc/init.d/nullmailer stop" stoppen), dann kann man sich die Datei ansehen

Beispiel für so eine Datei:

Code: [Select]

system@reinelt.co.at
michael@reinelt.co.at

Received: (nullmailer pid 12684 invoked by uid 0);
Sun, 12 Dec 2021 12:58:14 -0000
Subject: Output from your job        1
To: root@mld.reinelt.local
Date: Sun, 12 Dec 2021 13:58:14 +0100
Message-Id: <1639313894.402414.12619.nullmailer@mld.reinelt.local>
From: root <root@mld.reinelt.local>

/usr/bin/appstarter.sh: line 24: startsurf: not found

1. Zeile: (gültiger!) Absender (Envelope)
2. Zeile: Empfänger (Envelope)
Leerzeile
Mail-Header (die sind zwar für den Versand nicht wichtig, weil Envelope sind die ersten beiden Zeilen, aber wenn die fehlen oder falsch sind, sieht die Mail eigenartig aus)
Leerzeile
Mail-Body

3. nullmailer-send: das ist der Daemon der laufen sollte (und per /etc/init.d/nullmailer) gestartet wird. Dieser überwacht die Queue bzw. das Fifo, und verschickt die Mail dann


Hilfreich ist vielleicht noch meine (lauffähige) Konfigurarion:

/etc/nullmailer/me:

Code: [Select]

mld.reinelt.local
enthält die Mail-Domäne des Absenders, aber nur für den Header (nicht Envelope!). Wenn also "root" eine Mail schickt, und da drinnnen wie bei mir "mld.reinelt.local" steht, dann kommt die Mail von "root@mld.reinelt.local". Normalerweise würde nullmailer den "Quasi-Standard" etc/mailname dafür verwenden, aber die gibts in der MLD nicht.

/etc/nullmailer/adminaddr:

Code: [Select]

michael@reinelt.co.at
Das ist ein Fallback, damit man eine Mail an "somebody@localhost" senden kann, der Empfänger wird dann entsprechend umgeschrieben (kann nie schaden)

/etc/nullmailer/allmailfrom:

Code: [Select]

system@reinelt.co.at
Die Datei ist ggf. wichtig: Hier steht der Envelope-Absender drinnen, der bei allen Mails eingesetzt wird. Wichtig insofern, als dass mein Mail-Provider nur (Envelope-) Absender akzeptiert, die er kennt (Spam-Vermeidung). Eine Mail von "viagra@reinelt.co.at" würde nicht akzeptiert, auch wenn sonst alles (Authentifizierung etc) passen würde (wenn ist würdelos) passte.

/etc/nullmailer/remotes:

Code: [Select]

bsmtp.a1.net smtp --port=587 --user=system@reinelt.co.at --pass=******* --starttls --insecure
Hier wird der Remote-Mailserver konfiguriert, der die Mail schlussendlich wirklich entgegennehmen und weiterleiten soll. "--starttls" ist der Grund für meinen Aufstand hier, ohne TLS akzeptiert mein Business-Account (deswegen bsmtp.a1.net) keine Mails. "--insecure" verzichtet auf die Zertifikatsprüfung (kann man, muss man nicht)


Das wars eigentlich...

PS falls jemand verwirrt ist wegen "Envelope": Stellts euch das so vor: Die Standard-Header (From, To, CC, Subject, ... stehen im Briefkopf "Briefpapier", dieses Briefpapier wird aber in einen Briefumschlag (Envelope) gesteckt (damit kann die Post natürlich den Briefkopf nicht lesen) und auf den Briefumschlag wird dann nochmal Absender und Empfänger draufgeschrieben. Niemand sagt dass Header und Envelope identisch sein müssen...

schönen Sonntag noch! Michi

[Benji]

Hallo Pit,

nach etwas Pause habe ich mich wieder mit dem nullmailer beschäftigt. Offensichtlich hast du ja in der Zwischenzeit daran weitergearbeitet :-)

ich habe immer noch das Problem, dass nullmailer-send seine "Plugins" smtp und qmqp unter /usr/libexec/nullmailer sucht, diese aber unter /usr/lib/nullmailer liegen. Im Moment habe ich Symlinks angelegt, aber ich denke das muss irgendwie besser gehen... leider kenne ich mich da selbst mit autoconf (speziell unter Debian) zu wenig aus...

Weiters funktioniert das init-Skript /etc/init.d/nullmailer nicht korrekt, speziell was den Redirect zum logger ind damit zu syslog bzw. /var/log/messages betrifft:

im Original ist da ein ">(command)" redirect drinnen, diese Syntax ist aber bash-spezifisch und wird von der busybox-shell so nicht verstanden. Dein Umbau auf ">> logger" ruft nicht den logger auf, sondern erstellt eine Datei "logger" und gibt die anderen Argumente an nullmailer-send weiter (die dieser glücklicherweise ignoriert)

Auch hier kenne ich mich leider mit init-skripts viel zu wenig aus... ich sehe aber zwei Möglichkeiten:

a) wir machen ein "normales" Redirect von stdout/stderr nach /var/log/nullmailer.log (keine Ahnung wie man das macht)

b) du durchsuchst alle eure anderen init-Skripts auf "logger" vielleicht findest du ein funktionierendes beispiel wie man das mit busybox macht.

lg Michi