Alexander (HH): Mailserver unter Linux - Rat erwünscht

Beitrag lesen

Moin Moin!

... die, wie ich weiter unten anmerkte, für meine Begriffe nahezu nicht existent ist. Zumindest nicht nach meinem Anspruch an Dokumentation: Doku muss vom eigentlichen Produkt losgelöst verfügbar sein,

Dann dürftest Du mit so ziemlich jeder kommerziellen Software ernsthafte Probleme haben.

sie muss klar aufzeigen, was das Produkt kann oder nicht kann, und seine Funktion in etwa beschreiben (in Wort oder Bild). Dazu gehört auch eine genaue Beschreibung der externen und -soweit für den Nutzer relevant- der internen Schnittstellen.

Ich stimme Dir da vollkommen zu, gerade weil ich gerade massiv unter fehlender Dokumentation bei den Millionen-Räder-Projekten leide.

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.

Da bin ich ganz entschieden anderer Meinung. Wenn mich schon die Dokumentation vom Umfang, von der Verfügbarkeit oder von der Art der Darreichung her nicht überzeugen kann, sehe ich mich halt nach Alternativen um. Lieber benutze ich ein weniger ausgefeiltes Produkt, das ich dafür bestmöglich verstehe, als ein Superduper-Highend-Produkt, das ich nicht kapiere.

Ich verstehe nicht, warum Du so ein Problem mit binc hast.

binc ist gepackt wie tausende anderer Projekte auch, ein gzip- oder bzip2-komprimiertes TAR, mit einem Verzeichnis auf oberster Ebene, darunter direkt die Dateien INSTALL und README, und verdächtige Verzeichnisse wie man und doc. In doc liegt sogar ein komplettes Handbuch, fix und fertig als Postscript-Datei.

bincimap-1.2.13final
|-- AUTHORS
|-- COPYING
|-- COPYING.OpenSSL
|-- ChangeLog
|-- INSTALL
|-- Makefile
|-- Makefile.am
|-- Makefile.in
|-- NEWS
|-- README
|-- README.SSL
|-- README.in
|-- TODO
|-- aclocal.m4
|-- bincimap.spec
|-- bincimap.spec.in
|-- conf
|   -- ... |-- config.guess |-- config.h |-- config.h.in |-- config.log |-- config.status |-- config.sub |-- configure |-- configure.in |-- contrib |   -- ...
|-- doc
|   |-- Makefile
|   |-- Makefile.am
|   |-- Makefile.in
|   |-- README
|   |-- bincimap-faq.html
|   |-- bincimap-goals.html
|   |-- bincimap-imapdir.html
|   |-- bincimap-tech.html
|   |-- bincimap.css
|   |-- manual
|   |   |-- Makefile
|   |   |-- Makefile.am
|   |   |-- Makefile.in
|   |   |-- bincimap-manual.dvi
|   |   |-- bincimap-manual.ps
|   |   -- bincimap-manual.tex |   |-- rfc1731.txt |   |-- rfc1732.txt         ... |   -- rfc3348.txt
|-- man
|   |-- Makefile
|   |-- Makefile.am
|   |-- Makefile.in
|   |-- bincimap-up.1
|   |-- bincimap.conf.5
|   -- bincimapd.1 |-- missing |-- mkinstalldirs |-- service |   -- ...
|-- src
|   -- ... -- ...

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.

Das ist *noch* ein zusätzlicher Aufwand, das ist es nicht wert.

Was ist zusätzlicher Aufwand? Das Bereitstellen der im Source-TAR vorhandenen Dokumentation an passender Stelle im binären Paket? Ja, das ist es. Genau deswegen baut man binäre Pakete. Fehlt dieser Schritt, ist das ein Bug.

Oder das Melden fehlender Dokumentation an den Package Maintainer? Einen Dreizeiler an eine Mailing List oder in ein Bugtracking-System tippen, damit die nachfolgenden User sich nicht mehr mit schlecht gepackten Paketen herumschlagen müssen?

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

Nein, nicht egal. Es kann nicht meine Aufgabe sein, ein eigenes Labor für Lebensmittelchemie zu betreiben, nur um herauszufinden, ob das im Supermarkt angebotene Puddingpulver lactosefrei ist. Information ist eine Holschuld, keine Bringschuld. Soweit bin ich bereit, dir zuzustimmen. Aber dabei setze ich voraus, dass die Information auch in einer angemessenen Weise zur Verfügung gestellt wird.

Der Vergleich hinkt doch sehr. Wenn Du Dir binc oder irgendeine andere Software selbst übersetzt, solltest Du Dir die beiliegende Doku durchlesen, idealerweise vor dem Übersetzen. Wenn Du das Compilieren dem Package Maintainer überläßt, solltest Du Dir wenigstens den Teil der Doku durchlesen, die das Paket mitbringt und der sich auf Installation und Betrieb der Software bezieht.

Um mal beim Pudding zu bleiben:

Kochen allein nach den Bildern im Kochbuch (compilieren aus dem Source) wird sehr wahrscheinlich scheitern, Du wirst kaum darum herumkommen, dir auch das Rezept durchzulesen. Mit Schulkochbüchern, die viele Arbeitsschritte im Detail zeigen, kommst Du vielleicht weiter als mit den "normalen" Kochbüchern, die nur das fertige Produkt abbilden, oft noch mit zahlreichen Tricks aufgehübscht. Was im Pudding drin steckt, kannst Du direkt aus dem Rezept ableiten, typischerweise nach der "man nehme"-Floskel oder einer expliziten Liste der Zutaten.

Kaufst Du Dir fertigen Pudding im Plastikbecher (Package installieren), sparst Du Dir viel Arbeit, mußt dabei aber hinnehmen, dass der Hersteller den Pudding nach seinem Geschmack gekocht hat (Compiler-Flags, Vorkonfiguration). Was im Pudding drin steckt, steht in Kurzform auf der Packung.

Was Laktose angeht, brauchst Du kein Labor. Laktosefreiheit wird bei Fertigprodukten explizit beworben, alles andere enthält sehr wahrscheinlich Laktose, von "offensichtlichen" Ausnahmen (z.B. Mineralwasser) mal abgesehen. Bei Deinem selbstgekochten Pudding kennst Du alle Zutaten, und wenn Du Kuhmilch benutzt, kannst Du sicher sein, dass der Pudding Laktose enthalten wird, auch wenn das weder im Rezept noch auf der Milchpackung steht.

Dream on. Gerade bei Open-Source-Software besteht die Dokumentation oft nur darin, dass der Autor sich hinstellt und sagt, "Was denn, der Code ist doch frei einsehbar". Meist sind es Dritte, die sich, der Not gehorchend, die Mühe machen, die Software zu erforschen und ihre Erkenntnisse auch anderen zur Verfügung zu stellen.

Das sehe ich nicht so. Bei trivialen Programmen stimme ich Dir zu, und ehrlich gesagt sehe ich es nicht ein, bei einem Programm, dass nur aus main() und ein oder zwei Schleifen besteht, 100 Seiten Dokumentation abzuliefern.

Die großen, bekannten Projekte sind gut dokumentiert, und auch viele kleine. Vorbildlich sind z.B. Apache, Perl, fast alle bei CPAN gelisteten Perl-Module, PHP soweit ich es kenne, Subversion, CVS, nmap, Samba, rsync, und sehr viele GNU-Projekte. Immer noch gut ist exim, das allerdings wie auch z.B. die gesamte djb-Doku und auch binc etwas darunter leidet, dass alles nur einmal dokumentiert ist. Der Linux-Kernel ist etwas knapp mit Dokumentation.

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

Frust - ja. Lernresistenz? Bedingt. Aber beides hat nichts miteinander zu tun.

Ich denke doch.

Ich habe gewisse Vorstellungen, wie die Welt oder Teile davon funktionieren sollten. Manche Teile enttäuschen mich in meinen Erwartungen. Andere Teile bieten mir genau das, was ich erwarte. Also nehme ich ein Angebot wahr, das meinen Vorstellungen entspricht, und lasse ein anderes links liegen. Es wurmt mich nur, wenn die Erkenntnis mehrere Tage braucht.
Lernresistenz habe ich nur dann, wenn ich keinen Sinn in dem erkenne, was ich da lernen soll.

Das ist ein riesiges Problem mit binc und der djb-Software. Du mußt ein völlig neues Konzept lernen, wie Programme miteinander interagieren, nämlich die Geschichte, Kommandozeilenparameter nur teilweise auszuwerten und den Rest stumpf an exec() weiterzureichen. Erst dann kannst Du diese Software wirklich voll nutzen.

Dovecot IMAP, das ich nun verwende, ist schön kompakt und übersichtlich: Ein Daemon, eine Konfigurationsdatei, die Maildir-Verzeichnisse und das IMAP-Protokoll zur Kommunikation. Alles drin. Und alles (zumindest alles, was ich bisher gesucht habe) dokumentiert. So wünsche ich mir das.

Und wie steht es mit der Sicherheit? Ich habe mal kurz auf die Dovecot-Website geschaut. Klar, 1000€ für ein Loch klingt toll, und "Dovecot's design and implementation is highly focused on security" liest sich auch nicht schlecht. Aber Dovecot läßt permanent etwas Code mit Root-Rechten laufen, dieser Prozess ist u.a. auch für das Logging zuständig. Bei daemontools läuft das Logging mit minimalen Rechten, typischerweise als nobody. Dovecot muß mal wieder inetd re-implementieren, um für eine neue Connection einen neuen Prozess zu fork()en. Dovecot leidet auch unter dem Wiki-Problem. Zum Mail Process Design liest mal nur FIXME. Natürlich gibt es zwei Wikis, wäre ja auch langweilig mit nur einem.

Das Source-Paket ist übrigens genauso organisiert wie bei binc. README und INSTALL, daneben ein doc-Verechnis. Letzteres ist übrigens nur ein Text-Dump des Wikis, noch nicht einmal verlinktes HTML.

Und wenn du jetzt glaubst, ich würde dir Vorwürfe machen, weil ich Binc auf deinen Rat hin ausgewählt und ausprobiert habe:

Nö, das denke ich nicht.

Nein, überhaupt nicht. Immerhin habe ich -frei nach Edison- dabei wieder etwas gelernt. Nämlich dass dieser Weg für mich nicht zufriedenstellend ist.

Vielleicht liest Du trotzdem mal das irgendwo in diesem Thread verlinkte thedjbway. Das hilft, die neuen, aber eigentlich uralten Konzepte hinter den djb-Programmen, binc und zahlreichen anderen Tools zu verstehen.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".