Mailserver unter Linux - Rat erwünscht

[Alexander (HH)]

Moin Moin!

bincimap wird gar nicht direkt aufgerufen, sondern über eine Kaskade von Programmen, die jedes für sich nur einen kleinen Job erledigen.

Auch das erschließt sich mir aus den Beschreibungen nicht. Jetzt, wo du es sagst, passt es ins Bild, aber woher soll man das wissen?

Aus der Dokumentation.

(x)inetd sorgt dafür, dass bincimap-up mit STDIN und STDOUT zum IMAP-Client verbunden wird.
bincimap-up wertet die Konfiguration aus, springt ins Home-Verzeichnis des Users, springt von da in den konfigurierten Pfad (typischerweise "Maildir", damit ist das aktuelle Verzeichnis dann $HOME/Maildir), reduziert die Privilegien, und ersetzt sich selbst via exec() durch checkpassword. (Für System-Accounts, z.B. mit ungültigem Home-Verzeichnis in /etc/passwd, oder schlicht mit UID=0 (root), bricht bincimap-up schon vorher ab.)
checkpassword prüft, ob Benutzername und Password passen, und ersetzt sich bei erfolgreichem Login durch das nächste Programm in der Kette, typischerweise bincimap.

Waa! Ich krieg einen Knoten im Hirn!

Das geht vorbei. Sehr schnell.

Im Klartext: Es GIBT KEINEN Daemon bei binc.

Die Information hätte ich vor vier Tagen haben sollen. Hätte mir viel Sucherei erspart ...

Das steht so kurz und knapp tatsächlich nicht in der Doku. Aber Binc wird auch nicht als Daemon bezeichnet, sondern als Server. Haarspalterei, ich weiß ...

Lässt sich das nicht einfach auf die "übliche" Methode /etc/init.d/imapd start abbilden?
Nein, wozu?

Weil es für etliche andere Dienste auch so gemacht wird, und weil es bisher die einzige Methode ist, die ich kennengelernt und daher als "normal" begriffen habe.

/etc/init.d alias SysV-Init ist hauptsächlich vom Millionen-Fliegen-Prinzip getrieben. SysV-Init ist eine Idee aus alten Zeiten, als einige Leute davon genervt waren, ständig an den BSD-Init-Scripten herumschrauben zu müssen. Auf die Idee von djb, so etwas wie daemontools zu bauen, ist man damals trotz aller genialen Leute nicht gekommen.

SysV init must die  -- bezieht sich zwar auf runsv/runsvdir, das ist aber nur daemontools mit neuem Code.

Gibt es nirgends eine ordentliche Beschreibung der Konfiguration von Binc IMAP? Alles was ich finde, sind immer nur Bruchstücke, selbst bincimap.org hält sich mit konkreten Informationen sehr zurück.
Wie wäre es mit dem README in den Sources?

Jetzt mach aber mal'n Punkt. Soll man als Nutzer einer Software deren Sources durchsuchen? Das kann's nicht sein.

Da es binc vom Autor nur als Source gibt, ja.

Wenn Du es Dir von einem Dritten als fertiges Paket herunterlädst, ist es dessen Job, die Dokumentation an passender Stelle zur Verfügung zu stellen. Macht er das nicht, hat er seinen Job nicht ordentlich gemacht. => Bug Report.

Dein Job ist es, diese Doku zu lesen und zu verstehen. Egal ob die Doku aus dem Paket entpackt wurde oder dem Source beilag.

Abgesehen davon bin ich der Meinung, dass Informationen über ein Produkt auch zugänglich sein müssen, ohne dass man das Produkt erst kauft (bzw. das Programm installiert).

Wenn Du von einer wirklich vollständigen Doku sprichst: Dream on, insbesondere bei kommerzieller Software. Bei Open Source Software kannst Du Dir die komplette Software samt Dokumentation herunterladen, auspacken und die Dokumentation lesen. Bei binc liegen die Man-Pages im Standard-Format vor, die man direkt lesen kann. Man könnte der Website (bzw. deren Betreiber) ankreiden, dass die im Source-Paket vorhandene Dokumentation nicht auch direkt auf der Website lesbar ist. Das so etwas möglich ist, zeigt z.B. das Busybox-Projekt. DJB geht noch einen Schritt weiter und bietet NUR HTML-Seiten an.

Darüber habe ich mich bei Windows-Software schon oft genug geärgert: Erst wenn man das Programm installiert hat, bekommt man die Readme- oder Hilfedateien zu sehen, aus denen man schließlich erkennt, dass das Programm für den vorgesehenen Zweck gar nicht geeignet ist. Oder was man beim Installieren schon falsch gemacht hat.

Da bist Du sicherlich nicht allein. Was sagen denn die Anbieter der jeweiligen Programme zu Deinen Beschwerden?

Wenn ich daran denke, einen neuen Fernseher zu kaufen, erwarte ich ja auch, dass ich technische Daten oder die Bedienungsanleitung schon lesen kann, ohne dass ich das Gerät erst kaufe und dann nach ein paar Tagen zurückgebe.

Jaja, das Internet hat uns fürchterlich verwöhnt. Ein kluger Hersteller stellt solche Dokumente tatsächlich zur Verfügung, und idealerweise auch für alte Geräte. IBM hat z.B. noch nach dem Lenovo-Deal alle Service-Unterlagen bis hin zum Ur-PC kostenlos zur Verfügung gestellt. Siemens dagegen hat für alte Telefone alle Unterlagen an einen Verwerter verkauft, der sie nur gegen reichlich Kohle herausrückt. Und über Hersteller bzw. Etikettierer von Billigware reden wir besser gar nicht erst, da ist oft nicht einmal das aktuelle Sortiment brauchbar dokumentiert.

Was mich teilweise fürchterlich nervt ist der Trend, die Doku in ein Wiki zu stopfen, dort nur rudimentäre Informationen hinzurotzen und dabei nicht einmal nach Programmversionen zu unterscheiden, in der Hoffnung, dass die User sich irgendwann mal die Mühe machen, dass Programm ordentlich per Wiki zu dokumentieren.

OpenWRT macht diesen Unsinn, sogar so weit, dass man mittlerweile zwei Wikis hat, über die Fragmente der Dokumentation verstreut sind. Etherboot/gPXE sieht ähnlich aus, wenn auch nur mit einem Wiki. Die Informationen über die alten Etherboot-Versionen vor gPXE sind nicht mehr aufzufinden. Syslinux fängt auch gerade an, die Doku in ein Wiki zu überführen, statt einfach nur den für alle Loader gemeinsam geltenden Informationen aus syslinux.doc in eine common.doc zu verschieben.

Nichts gegen Wikis an sich, aber als einzige Programmdokumentation ist ein Wiki IMHO ungeeignet. Intern kann man vielleicht ein Wiki benutzen und als Dokumentation in einen Satz statischer Dateien exportieren, wenn man ein Release herausgibt.

Nach allem, was du beschrieben hast, hätte ich Binc wahrscheinlich sowieso nach einiger Zeit wieder entsorgt, weil mir das System zu undurchschaubar und zu verstrickt ist - selbst wenn ich es zum Laufen gebracht hätte.

Ich hab den Eindruck, das Du aus dem Frust heraus gerade eine Lernresistenz entwickelst.

Binc, daemontools und andere moderne Unix-Tools haben sicherlich eine etwas steilere Lernkurve, zumal man fork() und exec() verstanden haben muß. Insbesondere die Distributions-Packer scheinen lieber bei der Millionen-Fliegen-Software zu bleiben. Aber diese modernen Tools sind gerade eben nicht verstrickt und undurchschaubar, sondern kleine, einfache Tools, die stumpf hintereinander geschaltet werden und bei Bedarf sehr flexibel mit anderen Tools kombiniert werden können.

Sendmail und bind sind verstrickt, undurchschaubar und mit Tonnen von Legacy-Code überfrachtet. Sich in solche Tools einarbeiten zu müssen macht extrem viel Arbeit, und vor allem muß man für jedes dieser Tools von vorne anfangen. (x)inetd/ucspi-tcp lernst Du einmal, dann verstehst Du jeden TCP-Server, der darauf aufsetzt. checkpassword lernst Du einmal, dann verstehst Du jeden Service, der darüber User authentifiziert. daemontools lernst Du einmal, dann verstehst Du jeden Service, der darüber gesteuert wird.

Alexander