Der Martin: Mailserver unter Linux - Rat erwünscht

Hallo miteinander,

fast 7 Jahre, weit über 50'000 Betriebsstunden, hat mich ein kleiner PC mit EPIA-Board im Mini-ITX-Format, VIA C3-CPU und nur knapp 30W Leistungsaufnahme als treuer hausinterner Server begleitet. Basierend auf Windows 2000 diente er LAN-intern als Fileserver, Webserver, IMAP-Server, fallweise auch als mySQL-Server. Nun hat die Hardware das Zeitliche gesegnet - R.I.P. Windows bootet nicht einmal mehr, läuft meist schon vor dem Anmeldedialog auf einen Bluescreen auf (auch im abgesicherten Modus). Manchmal gelingt der Systemstart und die Anmeldung noch, dann läuft die Kiste noch ein paar Minuten bis ein paar Stunden, bevor schließlich aus heiterem Himmel der nächste Bluescreen auftritt. Die Fehlermeldung bzw. der Fehlercode ist immer mal wieder etwas anders.
Dass es ein Hardwareproblem ist, kann ich mit Sicherheit diagnostizieren, denn ein Ubuntu als Live-System stürzt ebenfalls an unterschiedlichen Stellen schon während des Bootvorgangs ab. RAM-Modul probehalber getauscht, keine Besserung.
Nun habe ich die Tatsache akzeptiert, dass der Rechner wohl wirklich hinüber ist, und habe das gute Stück heute morgen demontiert.

Ein Nachfolgegerät im stromsparenden Design (auf Intel Atom basierend, Gesamt-Leistungsaufnahme nur noch um 10W im Mittel, ca. 25W Spitze) ist schon da; ein Gentoo läuft darauf, Samba als Fileserver ebenfalls schon. Apache/PHP und mySQL eilt nicht, da erwarte ich aber auch keine allzu großen Schwierigkeiten, das sind schließlich Standardpakete.

Aber vielleicht mag mich ein Linux-Kenner mal ein wenig beraten ...
Denn die Büchse soll ja möglichst bald auch wieder als Mailserver da sein. Anforderungen:
 * LAN-interner IMAP-Server
 * Speicherung im Maildir-Format (jede Mailnachricht als eine Datei)
 * Regelmäßiges Einsammeln externer Mails von mehreren Accounts per POP3
 * Filtern eingehender Mails nach eigenen Kriterien, ggf. Aufruf bestimmter Programme anhand
   von Mail-Inhalten (z.B. Status-Reports parsen und in DB eintragen)
Nach einiger Suche kam ich auf die Kombination Binc IMAP, fetchmail und procmail. Ist das angemessen oder eher mit Elefanten auf Mücken geschossen? Die Einrichtung dieser Programmme scheint mir zwar nicht gerade trivial, aber durchaus beherrschbar.

Für ausgehende Mails verbinden sich meine Mailclients (Thunderbird) direkt mit dem SMTP-Server des Providers und legen dann eine Kopie im entsprechenden IMAP-Ordner ab. Aber wie sieht das aus, wenn ich von PHP aus Mails versenden möchte? Die sollten bitte auch über den SMTP-Server des Providers eingereicht werden. Vermutlich kann PHP auch unter Linux so konfiguriert werden, dass es sich mit einem SMTP-Server zum Versand verbindet wie unter Windows, aber der Provider verlangt SMTP-AUTH (Wowereit!), und das kann PHP nicht. Was eignet sich also hier noch als Vermittlung nach dem KISS-Prinzip? Beschreibungen und Manuals von Programmen kann ich natürlich selbst lesen, aber Anregungen wären schön, damit ich wenigstens einen Anhaltspunkt für meine Suche habe.

Vielen Dank schon vorab für alle guten Tipps, die da kommen mögen ...

Ciao,
 Martin

--
Die letzten Worte der Challenger-Crew:
Lasst doch mal die Frau ans Steuer!
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
  1. Tach,

    Nach einiger Suche kam ich auf die Kombination Binc IMAP, fetchmail und procmail. Ist das angemessen oder eher mit Elefanten auf Mücken geschossen? Die Einrichtung dieser Programmme scheint mir zwar nicht gerade trivial, aber durchaus beherrschbar.

    ich kenne Binc nicht und hätte vermutlich Cyrus als Alternative genannt.

    Für ausgehende Mails verbinden sich meine Mailclients (Thunderbird) direkt mit dem SMTP-Server des Providers und legen dann eine Kopie im entsprechenden IMAP-Ordner ab. Aber wie sieht das aus, wenn ich von PHP aus Mails versenden möchte?

    Dann benötigst du einen MTA (z.B. exim oder postfix)

    Die sollten bitte auch über den SMTP-Server des Providers eingereicht werden.

    Kein Problem, Stichwort Smarthost.

    Vermutlich kann PHP auch unter Linux so konfiguriert werden, dass es sich mit einem SMTP-Server zum Versand verbindet wie unter Windows

    So weit ich weiß nein.

    mfg
    Woodfighter

    1. Hi,

      Nach einiger Suche kam ich auf die Kombination Binc IMAP, fetchmail und procmail. Ist das angemessen oder eher mit Elefanten auf Mücken geschossen? Die Einrichtung dieser Programmme scheint mir zwar nicht gerade trivial, aber durchaus beherrschbar.
      ich kenne Binc nicht und hätte vermutlich Cyrus als Alternative genannt.

      Binc IMAP wurde hier im Forum vor einiger Zeit von Alexander (HH) mal lobend erwähnt, dem ich ein kompetentes Urteil zutraue; ich hab inzwischen ein wenig darüber gelesen, und was ich gelesen habe, überzeugt mich.
      Cyrus scheint mir etwas oversized ...

      Für ausgehende Mails verbinden sich meine Mailclients (Thunderbird) direkt mit dem SMTP-Server des Providers und legen dann eine Kopie im entsprechenden IMAP-Ordner ab. Aber wie sieht das aus, wenn ich von PHP aus Mails versenden möchte?
      Dann benötigst du einen MTA (z.B. exim oder postfix)

      Ich ahnte es schon.

      Vermutlich kann PHP auch unter Linux so konfiguriert werden, dass es sich mit einem SMTP-Server zum Versand verbindet wie unter Windows
      So weit ich weiß nein.

      Danke - ich wusste es eben *nicht* und habe daher nur vermutet.
      Wundert mich aber doch, bei aller Flexibilität, die man von Linux sonst erwartet.

      Ciao,
       Martin

      --
      Zwischen Leber und Milz
      passt immer noch'n Pils.
      Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
      1. Tach,

        Wundert mich aber doch, bei aller Flexibilität, die man von Linux sonst erwartet.

        das hat ja mit Linux nicht zu tun sondern mit PHP. Da allerdings unter *NIX-Systemen eigentlich immer ein MTA läuft, wundert mich das nicht im geringsten.

        mfg
        Woodfighter

      2. Wundert mich aber doch, bei aller Flexibilität, die man von Linux sonst erwartet.

        Linux braucht ja quasi nen MTA da Fehlermeldungen usw. per Mail versendet werden, auch wenns nur lokal ist.
        Dadurch sollte sich dein Problem darüber leicht lösen lassen. Debian installiert exim4 mit, Postfix ist schnell nachinstalliert. Bei anderen Systemen dürfte es ähnlich sein, da sendmail wohl nur noch für Masochisten interessant ist :D

      3. Moin Moin!

        Binc IMAP wurde hier im Forum vor einiger Zeit von Alexander (HH) mal lobend erwähnt,

        Ich wollte es gerade wieder tun. exim als MTA dazu, fetchmail zum Einsammeln der Mails vom POP3 des Providers, ggf. procmail für automatische Mailbehandlung. Und weil mit checkpassword für BincIMAP ohnehin DJB-Software auf der Maschine landet, kann man auch gleich noch die gepatchten Daemontools dazu packen und denen die Kontrolle über exim und fetchmail überlassen. Das läuft bei mir seit Jahren absolut schmerzfrei.

        dem ich ein kompetentes Urteil zutraue

        Merci.

        Für ausgehende Mails verbinden sich meine Mailclients (Thunderbird) direkt mit dem SMTP-Server des Providers und legen dann eine Kopie im entsprechenden IMAP-Ordner ab.

        So läuft das bei mir auch, vor allem, weil ich zu faul bin, exim mal so sauber zu konfigurieren, dass es den Provider-Mailserver als Smarthost nutzt.

        »»»» »» Aber wie sieht das aus, wenn ich von PHP aus Mails versenden möchte?

        Dann benötigst du einen MTA (z.B. exim oder postfix)

        Ich ahnte es schon.

        Nicht zwingend. Wenn Du nur ins Internet mailen willst, kann PHP sich auch gleich an den Mailserver des Providers wenden.

        Wenn Du aber (wie ich) tägliche Berichte von Deinem Rechner haben willst (z.B. Backup-Log), dann ist ein lokaler MTA sehr hilfreich.

        Vermutlich kann PHP auch unter Linux so konfiguriert werden, dass es sich mit einem SMTP-Server zum Versand verbindet wie unter Windows
        So weit ich weiß nein.

        Warum denn das nicht? Das wäre eine extrem dämliche Einschränkung. (Im Zweifel mal in die Doku schauen -- http://de2.php.net/manual/en/mail.configuration.php sagt tatsächlich, dass PHP nur unter Windoof SMTP kann -- D'oh!) In ein Programm namens sendmail zu pipen ist auf Unix-Systemen zwar üblich, aber SMTP zu localhost oder dem MX der lokalen Domain ist auch möglich. Exim bringt auf jeden Fall einen Ersatz für sendmail mit -- einen einfachen Symlink auf exim. exim, aufgerufen als sendmail, kann mit allen gängigen sendmail-Kommandozeilenparametern umgehen und beherrscht natürlich auch das "Pipe-into-sendmail-Protokoll".

        Danke - ich wusste es eben *nicht* und habe daher nur vermutet.
        Wundert mich aber doch, bei aller Flexibilität, die man von Linux sonst erwartet.

        Linux kennt nicht mal sendmail. Linux ist Kernelspace. Der Userspace mit sendmail ist in aller Regel vom GNU-Projekt "geliehen", mit ein paar Spezialanwendungen für Linux. PHP hat weder mit Linux noch mit GNU etwas zu tun, außer dass es mit dem GNU-Userspace, eingen Linux-Kerneln, diversen Anwendungen und tonnenweise Sources auf diversen Installationsmedien für GNU/Linux zu finden ist.

        Alexander

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

          »»»» »» Aber wie sieht das aus, wenn ich von PHP aus Mails versenden möchte?

          Dann benötigst du einen MTA (z.B. exim oder postfix)

          Ich ahnte es schon.

          Nicht zwingend. Wenn Du nur ins Internet mailen willst, kann PHP sich auch gleich an den Mailserver des Providers wenden.

          Wenn Du aber (wie ich) tägliche Berichte von Deinem Rechner haben willst (z.B. Backup-Log), dann ist ein lokaler MTA sehr hilfreich.

          Mist, einen etwas schrägen Weg vergessen: Mit IMAP hast Du auch die Möglichkeit, Mails auf den Server zu schreiben. Du könntest also statt sendmail und SMTP auch stumpf IMAP benutzen, um Mails aus PHP in lokale Mailboxen zu schaufeln.

          Das ist noch nicht einmal meine Idee, es ist ein durchaus praktiziertes Konzept, dass man eine Mail per IMAP in ein besonderes Verzeichnis auf den IMAP-Server packt und der Server die Mail von dort aus in die weite Welt verschickt. (Frag mich aber bloß nicht, wer so etwas tatsächlich benutzt, das ist mir entfallen und ich habe keinen Nerv, das jetzt nachzuforschen.)

          Und schließlich nutzt Du das IMAPdir-Format, das über maildir++ von DJB's maildir-Format abstammt. Wenn Du PHP entsprechende Rechte verschaffst, notfalls über einen Wrapper mit höheren Rechten, kannst Du die Mails auch direkt ins Dateisystem schreiben. Das maildir-Protokoll erlaubt durchaus parallele, schreibende Zugriffe auf die maildir-Verzeichnisse, ohne dass Du dich mit Locks herumschlagen mußt.

          Aber alles in allem ist ein lokaler MTA, wenn er erstmal läuft, wesentlich einfacher.

          Alexander

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

          da ist ja der Anstifter! :-)

          Binc IMAP wurde hier im Forum vor einiger Zeit von Alexander (HH) mal lobend erwähnt,
          Ich wollte es gerade wieder tun.

          ich bin gerade so weit, dass ich mir das Kapitel "Mail" für morgen vorgenommen habe. Bisher habe ich das Basissystem erstmal auf den aktuellen Stand gebracht und dabei fast einen Tag gebraucht, um Ursache und Abhilfe für eine Blockade zwischen den Komponenten udev und device-mapper zu finden - vor allem, weil dieser Konflikt noch nicht da war, als ich so um den Jahreswechsel das Grundsystem aufgesetzt habe.
          Inzwischen läuft Samba so, wie ich mir das wünsche, und die Büchse hat mit dnsmasq die Rolle des zentralen DHCP- und DNS-Servers im LAN übernommen. Außerdem hat sie physisch wie logisch ihren festen und vermutlich endgültigen Platz in der internen Infrastruktur gefunden.
          Allerdings hat dnsmasq noch eine Eigenart, die ich mir momentan noch nicht erklären kann: Eine DNS-Anfrage nach dem Namen des Hosts, auf dem dnsmasq selbst läuft, wird nicht beantwortet. Sei "spine" der Name des Rechners, auf dem dnsmasq läuft, und habe er die IP-Adresse 192.168.123.15. In der hosts-Datei auf spine, die dnsmasq ja zur Beantwortung von DNS-Requests mit auswertet, findet sich der Eintrag

          192.168.123.15  spine

          Ein nslookup von einem Ubuntu-Rechner nach "spine" wird aber mit "kenn ich nicht" beantwortet, auch ein ping auf den Hostnamen spine schlägt logischerweise fehl (direkt auf die IP-Adresse okay), während alle anderen Host/IP-Kombinationen in der hosts-Datei korrekt übermittelt werden. Von einem Windows-Rechner aus ist spine mit Namen ansprechbar, vermutlich weil Windows alternativ die NETBIOS-Namensauflösung verwendet.

          Außerdem stört mich noch, dass der Rechner permanent, auch wenn "nichts zu tun" ist, alle paar Sekunden kurz, aber hörbar auf die Festplatte zugreift. Kann man feststellen, wer das auslöst, und das eventuell eindämmen? Wenn alle anderen Rechner aus sind und Ruhe im Arbeitszimmer ist, klingt das nämlich, als wäre irgendwo eine Heuschrecke in einer Schachtel gefangen, die alle paar Sekunden mal einen Sprung macht. Lästig.

          fetchmail zum Einsammeln der Mails vom POP3 des Providers, ggf. procmail für automatische Mailbehandlung.

          Genau, so weit war ich ja mit meinen Überlegungen auch schon.

          Und weil mit checkpassword für BincIMAP ohnehin DJB-Software auf der Maschine landet, kann man auch gleich noch die gepatchten Daemontools dazu packen und denen die Kontrolle über exim und fetchmail überlassen. Das läuft bei mir seit Jahren absolut schmerzfrei.

          Was zum Geier ist DJB, was macht es, tut das weh, wozu braucht man das? Google und Wikipedia geben mir da auch keine Anhaltspunkte. Und was für Daemontools? Ich kenne daemon tools als Windows-Software, die anhand einer ISO-Imagedatei ein virtuelles CD/DVD-Laufwerk generiert.

          Wenn Du nur ins Internet mailen willst, kann PHP sich auch gleich an den Mailserver des Providers wenden.

          Tatsächlich? Das würde mir vollkommen genügen. Denn intern kann ich Protokolle auch einfach in Protokolldateien schreiben, das ist mir lieber. Aus Mails müsste ich sie ja erst wieder rauspopeln.
          Wobei - wenn ich es mir recht überlege, brauche ich gar keinen MTA. Wichtig ist mir nur, dass ich mail() in PHP zum Testen verwenden kann. Ob die so versendeten Mails dann über reguläre e-Mail-Versandwege laufen oder auf dem kurzen Weg direkt ins interne Mail-Processing, ist eigentlich egal.

          Vermutlich kann PHP auch unter Linux so konfiguriert werden, dass es sich mit einem SMTP-Server zum Versand verbindet wie unter Windows
          So weit ich weiß nein.
          Warum denn das nicht? Das wäre eine extrem dämliche Einschränkung. (Im Zweifel mal in die Doku schauen -- http://de2.php.net/manual/en/mail.configuration.php sagt tatsächlich, dass PHP nur unter Windoof SMTP kann -- D'oh!) In ein Programm namens sendmail zu pipen ist auf Unix-Systemen zwar üblich, aber SMTP zu localhost oder dem MX der lokalen Domain ist auch möglich.

          Aus rein akademischen Interesse: Wie? Hinweis, Fingerzeig?

          Wundert mich aber doch, bei aller Flexibilität, die man von Linux sonst erwartet.
          Linux kennt nicht mal sendmail. Linux ist Kernelspace.

          Das ist mir klar, sorry. Ich verfalle nur auch oft der laienhaften schlechten Angewohnheit, mit dem Begriff "Linux" das gesamte System einschließlich aller Daemons zu meinen, die da so rumwerkeln. So wie man mit "Windows" halt auch nicht nur den Kernel meint, sondern das komplette Software-Paket mit allen Zubehörkomponenten (nur dass das im Falle von Windows korrekt ist, bei Linux nicht, ich weiß).

          So long,
           Martin

          --
          Noch Fragen? - Ich weiß es auch nicht.
          Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
          1. Hi,

            Inzwischen läuft Samba so, wie ich mir das wünsche, ...

            jedenfalls beinahe. Eben entdecke ich, dass ich offensichtlich noch ein Problem mit der Zeichencodierung bei den Dateinamen habe:
            Kopiere ich von Windows 2000 aus eine Datei mit einem Nicht-ASCII-Zeichen im Namen auf den Samba-Server (Samba 3.4.6), und schaue mir dann das Verzeichnis an, sieht es korrekt aus. Schaue ich aber von einem Linux-PC aus, sind beispielsweise Umlaute in den Dateinamen verstümmelt (werden als Raute mit Fragezeichen angezeigt).
            Umgekehrt das gleiche Problem: Windows zeigt Umlaute in Dateinamen, die von Linux aus gespeichert wurden, als Kästchen an.

            Die Samba-Dokumentation sagt:
            "Newer clients (Windows NT, 200x, XP) talk Unicode over the wire."
            Und im Abschnitt direkt drunter:
            "As of Samba-3, Samba can (and will) talk Unicode over the wire."

            Nun sagt "Unicode" ja noch nichts über die Codierung aus; Windows speichert Dateinamen beispielsweise in UCS-2 (eine Abart von UTF-16), Samba in UTF-8. In welcher Codierung die Namen tatsächlich übermittelt werden, bleibt unklar. Jedenfalls sind sich Samba und Windows darüber nicht einig.

            Ich finde zwar haufenweise Beiträge von Nutzern, die den gleichen Effekt beklagen, aber keine wirkliche Lösung ... :-(

            Ciao,
             Martin

            --
            Wenn Zeit das Kostbarste ist, was wir haben, dann ist Zeitverschwendung die größte aller Verschwendungen.
              (Benjamin Franklin, amerikanischer Tüftler und Politiker)
            Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
            1. Hi!

              Eben entdecke ich, dass ich offensichtlich noch ein Problem mit der Zeichencodierung bei den Dateinamen habe:
              Ich finde zwar haufenweise Beiträge von Nutzern, die den gleichen Effekt beklagen, aber keine wirkliche Lösung ... :-(

              Sieht bei mir so aus:
              [global]
                      ...
                      dos filetimes = yes
                      dos filetime resolution = yes
                      dos charset = 850
                      unix charset = utf-8
                      display charset = utf-8

              Ob die dritte Zeile nötig ist, weiß ich nicht. Die beiden ersten jedenfalls beheben auch noch ein Problem mit der unterschiedlichen Auflösung bei Zeitangaben, was wichtig für CVS-Systeme ist, die sonst geänderte Dateien entdecken.

              (In meiner /etc/locale.gen unter Gentoo hab ich übrigens nur en_US.UTF-8 UTF-8 stehen, damit ist das System grundlegend auf UTF-8 gestellt.)

              Lo!

              1. Hallo,

                Sieht bei mir so aus:
                [global]
                        ...
                        dos filetimes = yes
                        dos filetime resolution = yes
                        dos charset = 850
                        unix charset = utf-8
                        display charset = utf-8

                habe ich eben nachgestellt. Test negativ:

                1. Vom Ubuntu-Client aus eine Datei "Tröte.test" erstellt
                   "ls" direkt auf der Samba-Maschine zeigt "Tr??????te.test" an (sechs Fragezeichen!)
                   Windows-Client zeigt "Tr□□te.test" (zwei Kästchen)

                2. Vom Windows-Client aus eine Datei "Tröte.test" erstellt
                   "ls" direkt auf der Samba-Maschine zeigt "Tr??te.test" an (zwei Fragezeichen)
                   Ubuntu-Client zeigt "Tr◊te.test" (eine Raute mit Fragezeichen)

                3. Der Hammer: Direkt auf der Samba-Maschine von der Shell aus "Tröte.test" erstellt
                   "ls" direkt auf der Samba-Maschine zeigt schon "Tr??te.test" an (zwei Fragezeichen)
                   Ubuntu-Client zeigt "Tr◊te.test" (eine Raute mit Fragezeichen)
                   Windows-Client zeigt "Tröte.test" (korrekte Anzeige!)

                Ich werde daraus noch nicht schlau ...
                Ach so, die Samba-Freigabe liegt auf einem ext3-Filesystem, falls das eine Rolle spielt.

                (In meiner /etc/locale.gen unter Gentoo hab ich übrigens nur en_US.UTF-8 UTF-8 stehen, damit ist das System grundlegend auf UTF-8 gestellt.)

                Dito.

                Ciao,
                 Martin

                --
                Solange der Nagellack nicht trocken ist,
                ist eine Frau praktisch wehrlos.
                  (Burt Reynolds, US-Schauspieler)
                Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                1. Hi!

                  1. Vom Ubuntu-Client aus eine Datei "Tröte.test" erstellt
                       "ls" direkt auf der Samba-Maschine zeigt "Tr??????te.test" an (sechs Fragezeichen!)
                       Windows-Client zeigt "Tr□□te.test" (zwei Kästchen)

                  Kann es sein, dass deine Shell nicht UTF-8-fähig ist? Ich weiß jetzt aber auch nicht, wie man das nachprüft und gegebenenfalls umstellt. Für Gentoo gibt es da ja reichlich Literatur, aber von Ubuntu weiß ich nur, dass es System dieses Namens gibt.

                  1. Der Hammer: Direkt auf der Samba-Maschine von der Shell aus "Tröte.test" erstellt
                       "ls" direkt auf der Samba-Maschine zeigt schon "Tr??te.test" an (zwei Fragezeichen)
                       Ubuntu-Client zeigt "Tr◊te.test" (eine Raute mit Fragezeichen)
                       Windows-Client zeigt "Tröte.test" (korrekte Anzeige!)

                  Scheint mir noch weniger ein Samba-Problem zu sein. Erstell doch mal eine Datei auf dem Ubuntu-Client, die Nicht-ISO-8859-1-Zeichen enthält,
                  z.B. touch 马丁.txt oder wenn du das nicht eingegeben/kopiert bekommst, was mit der Compose-Taste zusammenbauen Mąŗŧĩn.txt (mit ,a ,r -t ~i oder so)

                  Lo!

                  1. Moin,

                    zurück zum Thema ...

                    Kann es sein, dass deine Shell nicht UTF-8-fähig ist?

                    Kann ich nicht mit Sicherheit sagen; es würde mich aber doch sehr wundern, denn es handelt sich um die ganz normale bash "out of the box", und locale en_US.UTF-8. Das gilt doch nach meinem dürftigen Verständnis auch für die Shell.

                    Erstell doch mal eine Datei auf dem Ubuntu-Client, die Nicht-ISO-8859-1-Zeichen enthält

                    Gute Idee. Bleiben wir beim Tröten.
                    Vom Ubuntu-Client, auch auf en_US.UTF-8, erzeuge ich eine Datei mit dem Namen "trœt". Die sieht auf dem Ubuntu-Client sowohl in der Shell (ls) als auch in Thunar, dem GUI-Dateimanager korrekt aus. Ein ls auf der Gentoo-Maschine (wo Samba läuft) zeigt "tr?????t" an, diesmal mit fünf Fragezeichen. Und der Windows-Client zeigt schließlich "tr□ôt" an (ein Kästchen, ein o circonflex), bei genauer Untersuchung finde ich im Dateinamen die Byte-Sequenz 74 72 E2 94 BC C3 B4 74. Das nach UTF-8 decodiert ergibt, wenn ich richtig gerechnet habe U+0074, U+0072, U+263C, U+00F4, U+0074.

                    Jetzt der umgekehrte Weg.
                    Ein "trœt" vom Windows-Client angelegt, sieht die Gentoo-Shell als "tr??t", der Ubuntu-Client als "tr?t" - wobei der das Fragezeichen hier als echtes Fragezeichen sieht, es ist also schon an anderer Stelle ein Codierungsfehler aufgetreten.

                    Übrigens stimme ich dir mittlerweile zu, dass die bash auf der Gentoo-Maschine tatsächlich keinen UTF-8-Support hat; sie stellt bei ls jedes einzelne Byte im Dateinamen oberhalb von 0x80 als '?' dar. Sieht aus wie ASCII only. Das werde mal konkret weiter verfolgen.
                    Könnte natürlich sein, dass zwischen Windows und Samba alles korrekt läuft (und die Gentoo-bash nur kein UTF-8 versteht), und stattdessen der Ubuntu-Rechner derjenige ist, der da querschießt.

                    Puh. Ich blick da echt nicht durch. Vor allem, weil ich hier ein System habe, bei dem an mehreren Stellen eine Umwandlung oder Uminterpretation erfolgt, und ich nicht jede einzelne Stelle verfolgen kann. Oder habe ich eine Möglichkeit, Samba tatsächlich beim Interpretieren und ggf. Umcodieren auf die Finger zu schauen?

                    Das Phänomen mit dnsmasq besteht auch noch: Der DNS-Server weigert sich bei manchen in der hosts-Datei eingetragenen Hostnamen beharrlich, diese aufzulösen. Nicht nur bei seinem eigenen, sondern auch bei ein paar anderen probehalber eingetragenen. Ich finde keine Gesetzmäßigkeit. Es scheint auch keine Rolle zu spielen, ob der gefragte Hostname im Netz aktiv existiert oder nur ausgedacht ist; dnsmasq löst sowohl anwesende Hostnamen auf, als auch solche, die nie da waren. Ebenso bei denen, die dnsmasq "nicht kennt" und daher an den nächsten DNS weiterreicht, der sie auch nicht kennt, so dass zum Schluss NXDOMAIN herauskommt.

                    Wer hätte gedacht, dass der Teufel so im Detail stecken kann ...

                    So long,
                     Martin

                    --
                    F: Was ist schneller: Das Licht oder der Schall?
                    A: Offensichtlich der Schall. Wenn man den Fernseher einschaltet, kommt immer erst der Ton, und dann erst das Bild.
                    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                    1. Hi!

                      Erstell doch mal eine Datei auf dem Ubuntu-Client, die Nicht-ISO-8859-1-Zeichen enthält
                      Gute Idee. Bleiben wir beim Tröten.
                      Vom Ubuntu-Client, auch auf en_US.UTF-8, erzeuge ich eine Datei mit dem Namen "trœt".

                      Die chinesischen Zeichen und die anderen wählte ich mit dem Hintergedanken, dass auch kein Win-1252 mitspielt, dieses aber in dem Fall das œ kennt.

                      Ich hab den Rest vom Thread nicht richtig mitverfolgt, hattest du irgendwo deine Konfiguration aufgezeigt, also wie das Ubuntu mit dem Samba-Gentoo verbunden ist? Windows vs. Gentoo ist ja klar, das redet sicher nicht direkt mit Ubuntu.

                      Ein ls auf der Gentoo-Maschine (wo Samba läuft) zeigt "tr?????t" an, diesmal mit fünf Fragezeichen. Und der Windows-Client zeigt schließlich "tr□ôt" an (ein Kästchen, ein o circonflex), bei genauer Untersuchung finde ich im Dateinamen die Byte-Sequenz 74 72 E2 94 BC C3 B4 74. Das nach UTF-8 decodiert ergibt, wenn ich richtig gerechnet habe U+0074, U+0072, U+263C, U+00F4, U+0074.

                      Tipp- oder Rechenfehler, das muss ein U+253C sein. Jedenfalls ergibt das ┼ô, was nach CP850 (und auch CP437) C5 93 ist und als UTF-8 gelesen œ ergibt. Da haben also deine Systeme ein UTF-8-œ einzelbyteweise als CP850 interpretiert und diese beiden Zeichen wieder zu UTF-8 gemacht, was deine fünf Fragezeichen sind.

                      Ein "trœt" vom Windows-Client angelegt, sieht die Gentoo-Shell als "tr??t", der Ubuntu-Client als "tr?t" - wobei der das Fragezeichen hier als echtes Fragezeichen sieht, es ist also schon an anderer Stelle ein Codierungsfehler aufgetreten.

                      Sind da auch ein UTF-8-Fonts eingestellt? Andererseits deuten echte ? auf die Nichtexistenz eines Zeichens in der Zielkodierung hin.

                      Übrigens stimme ich dir mittlerweile zu, dass die bash auf der Gentoo-Maschine tatsächlich keinen UTF-8-Support hat; sie stellt bei ls jedes einzelne Byte im Dateinamen oberhalb von 0x80 als '?' dar. Sieht aus wie ASCII only. Das werde mal konkret weiter verfolgen.

                      Die Baustelle solltest du erst einmal klären. Gentoo hat USE-Flags für unicode und vielleicht auch utf8. Schau mal, ob die gesetzt sind (ufed ist ein ganz passables Tool für die USE-Flag-Verwaltung).

                      Oder habe ich eine Möglichkeit, Samba tatsächlich beim Interpretieren und ggf. Umcodieren auf die Finger zu schauen?

                      Vielleicht in Log-Files? Ich hab mich der Überwachung des Sambas noch nicht beschäftigt.

                      Der DNS-Server weigert sich bei manchen in der hosts-Datei eingetragenen Hostnamen beharrlich, diese aufzulösen.

                      Ist das überhaupt seine Aufgabe? Die /etc/hosts gilt doch nur lokal und nicht netzweit. Wenn du allerdings meinst, dass die Maschine ihre eigene /etc/hosts nicht lesen will, dann würde ich /etc/resolv.conf als Übeltäter vermuten, denn da steht die Reihenfolge der abzuklappernden Quellen bei einer Namensauflösung drin.

                      Lo!

                      1. Hallo,

                        Die chinesischen Zeichen und die anderen wählte ich mit dem Hintergedanken, dass auch kein Win-1252 mitspielt, dieses aber in dem Fall das œ kennt.

                        ah, daran hatte ich nicht gedacht. Ich glaube, das war trotzdem aufschlussreich.

                        Ich hab den Rest vom Thread nicht richtig mitverfolgt, hattest du irgendwo deine Konfiguration aufgezeigt, also wie das Ubuntu mit dem Samba-Gentoo verbunden ist?

                        Nein, hatte ich versäumt, sorry.
                        Ubuntu bindet Samba-Shares und Windows-Freigaben als CIFS-Filesystem ein, dabei springt wohl der Samba-Client ein.

                        Auf dem Ubuntu-Host läuft außerdem ebenfalls ein Samba, damit jeder Rechner im LAN sowohl Server- als auch Clientfunktion haben kann (Freigaben auf jedem PC). Ausgenommen davon ist nur die Gentoo-Maschine, die *ausschließlich* Server sein soll. Das hat damit aber AFAIS nichts zu tun.

                        Windows vs. Gentoo ist ja klar, das redet sicher nicht direkt mit Ubuntu.

                        Doch - und jetzt, wo du's erwähnst: Den Ärger mit Sonderzeichen in Dateinamen habe ich auch schon im Zusammenspiel von Windows und Ubuntu.

                        Tipp- oder Rechenfehler, das muss ein U+253C sein.

                        Ablesefehler vom Schmierzettel. :-)

                        Jedenfalls ergibt das ┼ô, was nach CP850 (und auch CP437) C5 93 ist und als UTF-8 gelesen œ ergibt. Da haben also deine Systeme ein UTF-8-œ einzelbyteweise als CP850 interpretiert und diese beiden Zeichen wieder zu UTF-8 gemacht, was deine fünf Fragezeichen sind.

                        Klingt überzeugend. Nur: Warum?

                        Ein "trœt" vom Windows-Client angelegt, sieht die Gentoo-Shell als "tr??t", der Ubuntu-Client als "tr?t" - wobei der das Fragezeichen hier als echtes Fragezeichen sieht, es ist also schon an anderer Stelle ein Codierungsfehler aufgetreten.
                        Sind da auch ein UTF-8-Fonts eingestellt?

                        Nach bestem Wissen und Gewissen, ja. Zumindest kann ich auf dem Ubuntu-PC problemlos Zeichen aus dem ganzen Unicode-Bereich in Dateinamen verwenden, und die werden dann auch sowohl im GUI-Dateimanager als auch auf der Shell übereinstimmend korrekt angezeigt. Erst im Dialog mit einem anderen Rechner gibt's wohl Interpretationskonflikte.

                        Übrigens stimme ich dir mittlerweile zu, dass die bash auf der Gentoo-Maschine tatsächlich keinen UTF-8-Support hat; sie stellt bei ls jedes einzelne Byte im Dateinamen oberhalb von 0x80 als '?' dar. Sieht aus wie ASCII only. Das werde mal konkret weiter verfolgen.
                        Die Baustelle solltest du erst einmal klären.

                        Einerseits ja, andererseits ist mir aber auch piepegal, ob die Shell eines Servers Dateinamen richtig anzeigen kann, solange die Serverprozesse richtig damit umgehen. Und nach allem, was ich bisher im Internet finden konnte, sind sämtliche Voraussetzungen erfüllt, dass die bash Unicode korrekt verarbeiten müsste. Es muss irgendwas geben, was ich bisher übersehe, und was vielleicht derart trivial ist, dass es auch bei den meisten Lösungsvorschlägen nicht erwähnt wird.
                        bash 4.0, readline.so 6.1, UNICODE="yes" in /etc/rc.conf, kein X11, nur Konsole, gleiche Anzeige an der lokalen Konsole und über ssh ... was noch?

                        Gentoo hat USE-Flags für unicode und vielleicht auch utf8. Schau mal, ob die gesetzt sind

                        Sind sie - besser gesagt, *ist es*.

                        ufed ist ein ganz passables Tool für die USE-Flag-Verwaltung.

                        Danke, guter Tipp. Damit konnte ich nur ein generelles USE-Flag zum Thema finden:
                         (+) unicode        (+  ) Adds support for Unicode
                        Das war von Anfang an gesetzt, ist AFAIK sogar die Defaulteinstellung.
                        Dafür habe ich ein paar andere USE-Flags gefunden (die mit dem Thema nichts zu tun haben), die ich bei der Gelegenheit geändert habe. Weißt du aus dem FF (oder dezimal 255), was ich tun muss, um die betroffenen Pakete, und möglichst *nur* die, unter Berücksichtigung dieser Änderungen neu zu compilieren?

                        Der DNS-Server weigert sich bei manchen in der hosts-Datei eingetragenen Hostnamen beharrlich, diese aufzulösen.
                        Ist das überhaupt seine Aufgabe? Die /etc/hosts gilt doch nur lokal und nicht netzweit.

                        Grundsätzlich schon - dnsmasq ist aber von seiner Anatomie her zunächst ein DNS-Forwarder, der aber zusätzlich die hosts-Datei seines Heimsystems auswertet und die eingetragenen Pärchen bei einer passenden DNS-Anfrage als Antwort zurückgibt. Das macht ihn ja so attraktiv für kleine Netze - man muss sich nicht in komplexe Systeme wie BIND einarbeiten, die für ein Netz mit einem Dutzend Hosts sowieso Overkill wären.

                        Den Fehler habe ich inzwischen gefunden - ein Syntaxfehler in der Konfigurationsdatei /etc/dnsmasq.conf, den das Tool aber leider nur beim Start/Restart des Dienstes meldet. Ändert sich die Konfigurationsdatei im Betrieb, wird die Änderung sofort transparent übernommen; ist die Konfiguration dann aber fehlerhaft, reagiert dnsmasq wohl etwas eigenartig.

                        Ciao,
                         Martin

                        --
                        Man soll den Tag nicht vor dem Abend loben.
                        Und den Mann nicht vor dem Morgen.
                          (alte Volksweisheit)
                        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                        1. Hurra,

                          das Codierungsproblem scheint gelöst!
                          http://www.gentoo.org/doc/en/utf-8.xml nochmal aufmerksam durchgelesen - und da fiel mir auf, dass die Jungs behaupteten, es gäbe eine Datei /etc/env.d/02locale. Die existierte bei mir aber nicht! Ich habe sie -zunächst ohne zu wissen, was es damit auf sich hat- mit dem beschriebenen Inhalt angelegt, ein env-update und source /etc/profile durchgeführt und - tadaa! Die Gentoo-Shell zeigte alle Umlaute und sonstige Exotenzeichen in Dateinamen korrekt an. Das heißt, Windows, Samba und bash sind sich jetzt einig, was die Codierung angeht.

                          Nun scheint nur Ubuntu noch der Übeltäter zu sein. Aber das ist eine andere Geschichte, die ich in naher Zukunft verfolgen werde; im Moment scheint mir das unwichtig.

                          Danke jedenfalls für die Hilfe, auch wenn sie zum Großteil aus "Anregen zum Nachdenken" bestand. Das ist manchmal besser als Vorsagen.

                          Schönes Wochenende schon mal,
                           Martin

                          --
                          Paradox ist, wenn jemand eingefleischter Vegetarier ist.
                          Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                          1. Hi,

                            falls es noch jemanden interessiert:

                            Nun scheint nur Ubuntu noch der Übeltäter zu sein. Aber das ist eine andere Geschichte, die ich in naher Zukunft verfolgen werde; im Moment scheint mir das unwichtig.

                            Ich hab's schon rausgefunden: Ubuntu (zumindest jaunty vom letzten Jahr) enthält noch Samba 2.3.3, und der spricht noch kein UTF-8. Jedenfalls nicht freiwillig. Dem muss man das in der smb.conf bzw. in den mount-Optionen noch ausdrücklich vorschreiben.
                            Dann klappt's auch mit den anderen. ;-)

                            Ciao,
                             Martin

                            --
                            Ordnung ist, wenn man etwas findet, was man gar nicht sucht.
                            Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                        2. Hi!

                          Dafür habe ich ein paar andere USE-Flags gefunden (die mit dem Thema nichts zu tun haben), die ich bei der Gelegenheit geändert habe. Weißt du aus dem FF (oder dezimal 255), was ich tun muss, um die betroffenen Pakete, und möglichst *nur* die, unter Berücksichtigung dieser Änderungen neu zu compilieren?

                          emerge -auvtND world

                          Eins davon berücksichtigt geänderte USE-Flags. Kannst du ohne zu zögern abschicken, das a sorgt dafür, dass vor dem richtigen Loslegen noch gefragt wird. Die geänderten USE-Flags werden hellgrün angezeigt.

                          Lo!

                          1. Hallo,

                            Weißt du aus dem FF (oder dezimal 255), was ich tun muss, um die betroffenen Pakete, und möglichst *nur* die, unter Berücksichtigung dieser Änderungen neu zu compilieren?
                            emerge -auvtND world

                            perfekt, danke! Werde ich heute abend mal anstoßen und ggf. über Nacht durchlaufen lassen. Ich rechne damit, dass das einige Zeit dauert; immerhin dauerte letztens allein das Compilieren von Samba und seinen Dependencies über 2 Stunden, AFAIR.

                            Eins davon berücksichtigt geänderte USE-Flags. Kannst du ohne zu zögern abschicken, das a sorgt dafür, dass vor dem richtigen Loslegen noch gefragt wird. Die geänderten USE-Flags werden hellgrün angezeigt.

                            Werde ich dann sehen. Ja, zumindest -a habe ich schon ab und zu eingesetzt. ;-)

                            Thanks a lot,
                             Martin

                            --
                            Die letzten Worte des Systemadministrators:
                            Nur gut, dass ich ein intaktes Backup habe.
                            Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                            1. Tach,

                              Weißt du aus dem FF (oder dezimal 255), was ich tun muss, um die betroffenen Pakete, und möglichst *nur* die, unter Berücksichtigung dieser Änderungen neu zu compilieren?
                              emerge -auvtND world

                              anschließend ist meist noch ein revdep-rebuild zu empfehlen.

                              mfg
                              Woodfighter

                              1. Hallo,

                                Weißt du aus dem FF (oder dezimal 255), was ich tun muss, um die betroffenen Pakete, und möglichst *nur* die, unter Berücksichtigung dieser Änderungen neu zu compilieren?
                                emerge -auvtND world
                                anschließend ist meist noch ein revdep-rebuild zu empfehlen.

                                das habe ich neulich schon einmal irgendwo als Empfehlung gelesen, und dann festgestellt, dass mein Gentoo das nicht kennt. Jetzt stelle ich fest, dass ich dazu wohl erst gentoolkit nachinstallieren muss. Scheint aber ganz nützlich zu sein ...

                                So long,
                                 Martin

                                --
                                Der Stress von heute ist die gute alte Zeit von morgen.
                                Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
          2. Moin Moin!

            Allerdings hat dnsmasq noch eine Eigenart, die ich mir momentan noch nicht erklären kann: Eine DNS-Anfrage nach dem Namen des Hosts, auf dem dnsmasq selbst läuft, wird nicht beantwortet. Sei "spine" der Name des Rechners, auf dem dnsmasq läuft, und habe er die IP-Adresse 192.168.123.15. In der hosts-Datei auf spine, die dnsmasq ja zur Beantwortung von DNS-Requests mit auswertet, findet sich der Eintrag

            192.168.123.15  spine

            Ein nslookup von einem Ubuntu-Rechner nach "spine" wird aber mit "kenn ich nicht" beantwortet, auch ein ping auf den Hostnamen spine schlägt logischerweise fehl (direkt auf die IP-Adresse okay), während alle anderen Host/IP-Kombinationen in der hosts-Datei korrekt übermittelt werden. Von einem Windows-Rechner aus ist spine mit Namen ansprechbar, vermutlich weil Windows alternativ die NETBIOS-Namensauflösung verwendet.

            Vermutlich.

            dnsmasq hat einige Option, mit denen man recht perverse Konstruktionen basteln kann. Unter anderem liest es eine Konfigurationsdatei (/etc/dnsmasq.conf), die aber nicht Bestandteil von dnsmasq ist. Es gibt eine Beispieldatei mit vielen auskommentierten, abenteuerlichen Geschichten. Je nach Distribution wird diese Beispieldatei auch mal als echte Konfigurationsdatei genommen, teilweise mit aktiv geschalteten Optionen.

            Prüf mal auf dem Ubuntu-Rechner, was in /etc/resolv.conf steht. Ich würde da folgendes erwarten:

            Generated by dhcpcd for interface eth0

            search dein.lokales.lan nameserver 192.168.123.15

            Wenn der Ubuntu einen anderen Nameserver-Eintrag als den dnsmasq-Server hat, kann das natürlich nicht funktionieren.

            Warum es mit anderen Rechnern doch klappt, ist halbwegs erklärbar: Vermutlich hast Du einen kleinen Router mit DNS-Server (oft auch DNSMasq), der die per DHCP(!) angefragten Hostnamen per DNS verteilt. Windows packt in DHCP-Anfragen den eigenen Hostnamen standardmäßig mit rein, Linux-Maschinen machen das normalerweise nicht. dhcpcd kann man mit -h HOSTNAME dazu bringen, andere DHCP-Clients entsprechend.

            Gemeines Detail am Rande: Wenn die Maschine mit dnsmasq selbst per DHCP oder PPP konfiguriert wird, liest dnsmasq (normalerweise) die /etc/resolv.conf, um die "höhergelegenen" Nameserver zu finden (typischerweise beim Provider). dhcpcd und andere DHCP- bzw. PPP-Clients erzeugen diese Datei, sobald eine IP-Adresse zugeteilt wurde.

            Natürlich lesen auch alle anderen Programme (über die libc) auf dem Rechner die /etc/resolv.conf, und damit fragen sie beim Provider (bzw. beim Router) nach Maschinen, die zwar DNSmasq kennt, aber nicht der Provider oder der Router.

            Workaround (siehe dnsmasq-Doku): DHCP-Client bzw. PPP-Daemon in eine andere Datei schreiben lassen (z.B. /etc/ppp/resolv.conf oder /etc/dhcpc/resolv.conf), dnsmasq über die alternative Resolver-Datei informieren (RTFM) und /etc/resolv.conf auf dnsmasq zeigen lassen ("search dein.lokales.lan" und "nameserver 127.0.0.1" oder "nameserver 192.168.123.15").

            Außerdem stört mich noch, dass der Rechner permanent, auch wenn "nichts zu tun" ist, alle paar Sekunden kurz, aber hörbar auf die Festplatte zugreift.

            Linux hat, wie alle Unixe, einen sehr effektiven Plattencache, der aber auch zu teilweise sehr asynchronen Schreibzugriffen führt. Unter anderem führen auch LESEzugriffe auf Dateien, selbst auf solche, die seit Ewigkeiten im Cache liegen, zu SCHREIBzugriffen auf die Metadaten: Die Last-Access-Time (A-Time) wird aktualisiert. Es sei denn, Du schaltest das über noatime beim expliziten mount-Aufruf oder in /etc/fstab ab.

            Außerdem gibt es noch Syslog, der alle 20 Minuten einen Dummy-Eintrag in die Logdateien schreibt, wenn man das nicht explizit abschaltet.

            Weiteres: Ecology-HOWTO, Battery-Powered-HOWTO (schon etwas angestaubt)

            Und weil mit checkpassword für BincIMAP ohnehin DJB-Software auf der Maschine landet, kann man auch gleich noch die gepatchten Daemontools dazu packen und denen die Kontrolle über exim und fetchmail überlassen. Das läuft bei mir seit Jahren absolut schmerzfrei.

            Was zum Geier ist DJB,

            Nicht was, wer.

            was macht es,

            Vieles. Unter anderem daemontools, qmail, djbdns.

            tut das weh,

            Ja, gelegentlich. djb tritt offenbar Leuten gerne auf die Füße, aber er liefert sehr hochwertige Software, so frei wie es nur geht: Public Domain.

            Und djb hat eine Allergie gegen #include <errno.h>, was sich darin äußert, dass sich seine Software auf Linux nicht ohne weiteres (Patches bzw. Compiler-Optionen) übersetzen läßt.

            Kleinere Nerverreien sind sein völlig eigenes Konzept, Software zu verteilen, zu compilieren und zu installieren. Aber es funktioniert.

            Leseempfehlung: http://thedjbway.b0llix.net/ (Mirror vom Original thedjbway.org, das von einem Domain-Grabber in Linkfarm für Pornoseiten umgewandelt wurde), dort gibt es auch (Links auf) Patches für Linux und für SIGQUIT/SIGUSR1/SIGUSR2.

            wozu braucht man das?

            daemontools: Daemons managen und Code sparen. Daemontools kümmern sich um Dinge wie automatischen Neustart, zuverlässiges Logging, etc.

            Vor allem aber nutzen die djb-Programme Unix-Features, statt das Rad ewig neu zu erfinden. Wenn man das Prinzip einmal verstanden hat, fragt man sich, warum sich Leute immer noch damit quälen, Programme "in den Hintergrund bringen" zu wollen, PID-Files zu verwalten, oder ein brauchbares Logging auf die Reihe zu bekommen. Das alles ist mit Unix-Derivaten völlig unnötig.

            Google und Wikipedia geben mir da auch keine Anhaltspunkte.

            Schade eigentlich.

            Und was für Daemontools? Ich kenne daemon tools als Windows-Software, die anhand einer ISO-Imagedatei ein virtuelles CD/DVD-Laufwerk generiert.

            Ja, auch. Aber die schreibt sich "laut" und mit Bindestrich.

            Die "wahren" daemontools schreibt man "leise" und ohne Bindestrich, und vor allem haben sie nichts mit Windows zu tun.

            Wenn Du nur ins Internet mailen willst, kann PHP sich auch gleich an den Mailserver des Providers wenden.

            Tatsächlich? Das würde mir vollkommen genügen. Denn intern kann ich Protokolle auch einfach in Protokolldateien schreiben, das ist mir lieber. Aus Mails müsste ich sie ja erst wieder rauspopeln.

            Du weißt, dass diverse Dienste auf typischen Unixen (und Linux-Distributionen aller Art) an User oder root mailen? Allen voran cron, aber auch mdadm oder smartd, die RAID-Volumes bzw. Festplatten überwachen.

            Mein Backup-Script mailt mir auch jede Nacht via cron, ob und wie das Backup gelaufen ist. Und mdadm und smart warnen natürlich auch, wenn Platten sterben. So muß ich eben NICHT regelmäßig in irgendwelchen über die Platte verstreuten Logs wühlen, ob irgendetwas schief gelaufen ist. Ich sehe es quasi sofort in meinen Mails.

            Wobei - wenn ich es mir recht überlege, brauche ich gar keinen MTA. Wichtig ist mir nur, dass ich mail() in PHP zum Testen verwenden kann. Ob die so versendeten Mails dann über reguläre e-Mail-Versandwege laufen oder auf dem kurzen Weg direkt ins interne Mail-Processing, ist eigentlich egal.

            Wenn Du die mail()-Funktion in PHP benutzen willst, wirst Du um einen MTA kaum herumkommen, es sei denn, Du ersetzt sendmail durch ein eigenes Programm, dass alle Aufrufe inklusive STDIN ausführlich dokumentiert.

            Vermutlich kann PHP auch unter Linux so konfiguriert werden, dass es sich mit einem SMTP-Server zum Versand verbindet wie unter Windows So weit ich weiß nein. Warum denn das nicht? Das wäre eine extrem dämliche Einschränkung. (Im Zweifel mal in die Doku schauen -- http://de2.php.net/manual/en/mail.configuration.php sagt tatsächlich, dass PHP nur unter Windoof SMTP kann -- D'oh!) In ein Programm namens sendmail zu pipen ist auf Unix-Systemen zwar üblich, aber SMTP zu localhost oder dem MX der lokalen Domain ist auch möglich.

            Aus rein akademischen Interesse: Wie? Hinweis, Fingerzeig?

            Was meinst Du? SMTP zu localhost?

            telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 meine.kiste ESMTP Exim 4.60 Tue, 29 Jun 2010 16:58:25 +0200 HELO localhost 250 meine.kiste Hello localhost [127.0.0.1] MAIL FROM: alex@localhost 250 OK RCPT TO: alex@localhost 250 Accepted DATA 354 Enter message, ending with "." on a line by itself Hallo Welt . 250 OK id=1OTcH2-0004Ay-It QUIT 221 meine.kiste closing connection Connection closed by foreign host.

            Das war's, extrem kurz. Länger:

            Es gibt keinen verbindlichen Weg herauszufinden, wie man als Programm seine Mails los wird.

            Man kann es "stumpf und dumm" damit versuchen, ein anderes Programm namens sendmail zu finden, typischerweise in $PATH, /usr/lib oder /usr/sbin. Das ruft man dann mit ein paar "magischen" Parametern auf, die das Originale sendmail seit Urzeiten verträgt, und hofft, dass das Programm wirklich die per STDIN angelieferte Mail verschickt.

            Man kann versuchen herauszufinden, welcher Mailserver für den Rechner des Empfängers bzw. der Empfänger zuständig ist, und und mit diesen direkt kommunizieren. Dazu befragt man das DNS nach MX-Records für die jeweiligen Hosts bzw. Domains. Das scheitert immer öfter an Blacklists, weil die etablierten Mailserver der Provider etwas "gleicher" als die Server auf Dial-Up-IP-Adressen sind.

            Man kann versuchen herauszufinden, welcher Mailserver für die lokale Maschine (bzw. das lokale Netz) zuständig ist (ebenfalls über DNS / MX-Records), und hoffen, dass der MX erstens richtig konfiguriert ist, zweitens Relaying (weiterleiten an beliebige andere Mail-Adressen) erlaubt, und drittens überhaupt Mails annimmt.

            Man kann stumpf voraussetzen, dass auf der lokalen Maschine ein Mailserver (MTA) läuft.

            Mein Standard-Ansatz ist, in der jeweiligen Programmkonfiguration SMTP-Server, SMTP-Port, User-Name und Passwort einstellbar zu machen, und den Rest einer SMTP-Library (in Perl typischerweise MIME::Lite) zu überlassen.

            Wenn auf einer Maschine sendmail funktioniert, arbeitet sendmail meistens auch als MTA, d.h. ich kann per SMTP über Port 25 oder 587 meine Mails loswerden.

            Ohne sendmail oder bei "besonderen Umständen" (dämliche DNS-Admins, paranoide Mail-Admins, Microsoft-only-Laden)  gibt es im LAN oder spätestens beim Provider einen Server, der mitspielt. Das kann auch mal Exchange, Groupwise oder Notes sein, ggf. mit einem entsprechenden "Adapter".

            SMTP zu sprechen ist nicht sonderlich schwer, siehe oben. Der Teufel steckt im Detail, weil SMTP eben eines der ältesten Protokolle im Netz ist, aus Zeiten, als Datenverbindungen oft nur 7 Bit übertragen konnten und Hacker noch ein rein positiver Begriff war. Du öffnest einen TCP-Socket zu Port 25 oder 587 des Mailservers, wartest auf die Begrüßung des Servers, wertest den Statuscode am Zeilenanfang aus, und arbeitest Dich dann weiter durch die Kette HELO name.des.client.rechners, ggf. Login, MAIL FROM: absender@example.com, RCPT TO: empfaenger1@example.com, RCPT TO: empfaenger2@example.com, DATA, Mailtext, ".", QUIT, mit einer Auswertung des Statuscodes nach jedem gesendeten Kommando. In der Praxis überläßt Du SMTP besser einer Library, die sich um die ganzen Details kümmert, und auch das Konstruieren einer Mail mit allem Firlefanz (insbesondere MIME) überläßt Du besser einer Library.

            Weiteres: Mail-Format ist in RFC2822 definiert, SMTP in RFC2821, IMAP4rev1 in RFC3501, POP3 in RFC1939 und RFC2449, DNS in rund 20 RFCs

            Alexander

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

              Allerdings hat dnsmasq noch eine Eigenart, [...]
              dnsmasq hat einige Option, mit denen man recht perverse Konstruktionen basteln kann.

              das mag schon sein, aber die Lösung für *dieses* Phänomen war ja schlicht und ergreifend ein Konfigurationsfehler, der ohne Neustart des Dienstes zwar seltsame Effekte hervorruft, aber nicht gemeldet wird.

              Unter anderem liest es eine Konfigurationsdatei (/etc/dnsmasq.conf), die aber nicht Bestandteil von dnsmasq ist.

              Nein? Bei mir war die aber AFAIR mit dem emergen von dnsmasq plötzlich da, und wird auch als die Konfigurationsdatei dokumentiert, die dnsmasq verwendet.

              Prüf mal auf dem Ubuntu-Rechner, ...

              Wie gesagt: Hat sich erledigt, Problem klar identifiziert und gelöst.

              Warum es mit anderen Rechnern doch klappt, ist halbwegs erklärbar: Vermutlich hast Du einen kleinen Router mit DNS-Server (oft auch DNSMasq), der die per DHCP(!) angefragten Hostnamen per DNS verteilt.

              Nö. Den DHCP- und DNS-Server des Routers habe ich deaktiviert, *bevor* ich dnsmasq scharf geschaltet habe. Zwei DHCP-Server im Netz können nicht wirklich gut sein, das war mir schon klar ...

              Windows packt in DHCP-Anfragen den eigenen Hostnamen standardmäßig mit rein, Linux-Maschinen machen das normalerweise nicht. dhcpcd kann man mit -h HOSTNAME dazu bringen, andere DHCP-Clients entsprechend.

              Nice to know, gibt mir aber in meinem Setup keinen Vorteil. Denn ich habe ja außer Windows- und Linux-PCs auch noch andere Geräte im Netz, die sich ebenfalls per DHCP konfigurieren lassen (ein Drucker, einen DVBC-Receiver, einen HDD-Videorecorder). Also habe ich nur die MAC-Adresse als allgemeines Erkennungsmerkmal.

              Weiteres: Ecology-HOWTO, Battery-Powered-HOWTO (schon etwas angestaubt)

              Egal, Futter fürs Brain, danke. :-)

              Vieles. Unter anderem daemontools, ...

              Habe ich zusammen mit Binc wieder entsorgt.

              Daemontools kümmern sich um Dinge wie automatischen Neustart, zuverlässiges Logging, etc.

              Verstehe. Also nichts, was man unbedingt bräuchte.

              Und was für Daemontools? Ich kenne daemon tools als Windows-Software, die anhand einer ISO-Imagedatei ein virtuelles CD/DVD-Laufwerk generiert.
              Ja, auch. Aber die schreibt sich "laut" und mit Bindestrich.

              Mit Blank, nicht mit Bindestrich.

              Wobei - wenn ich es mir recht überlege, brauche ich gar keinen MTA. Wichtig ist mir nur, dass ich mail() in PHP zum Testen verwenden kann. Ob die so versendeten Mails dann über reguläre e-Mail-Versandwege laufen oder auf dem kurzen Weg direkt ins interne Mail-Processing, ist eigentlich egal.
              Wenn Du die mail()-Funktion in PHP benutzen willst, wirst Du um einen MTA kaum herumkommen, es sei denn, Du ersetzt sendmail durch ein eigenes Programm, dass alle Aufrufe inklusive STDIN ausführlich dokumentiert.

              Oder durch einen MDA (LDA).

              Aus rein akademischen Interesse: Wie? Hinweis, Fingerzeig?
              Was meinst Du? SMTP zu localhost?

              Nein, SMTP von PHP aus. Weil du behauptet hast, das sei mit Linux-PHP auch möglich, die Doku aber etwas anderes behauptet.

              SMTP zu sprechen ist nicht sonderlich schwer, siehe oben.

              Ich weiß, ich kenne das Protokoll einigermaßen. Habe mich selbst schon in Debugging-Sessions damit vergnügt.

              In der Praxis überläßt Du SMTP besser einer Library, die sich um die ganzen Details kümmert, und auch das Konstruieren einer Mail mit allem Firlefanz (insbesondere MIME) überläßt Du besser einer Library.

              Nö. Das wäre ja langweilig. :-)

              Ciao,
               Martin

              --
              Ich stehe eigentlich gern früh auf.
              Außer morgens.
              Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
              1. Moin Moin!

                Windows packt in DHCP-Anfragen den eigenen Hostnamen standardmäßig mit rein, Linux-Maschinen machen das normalerweise nicht. dhcpcd kann man mit -h HOSTNAME dazu bringen, andere DHCP-Clients entsprechend.

                Nice to know, gibt mir aber in meinem Setup keinen Vorteil. Denn ich habe ja außer Windows- und Linux-PCs auch noch andere Geräte im Netz, die sich ebenfalls per DHCP konfigurieren lassen (ein Drucker, einen DVBC-Receiver, einen HDD-Videorecorder). Also habe ich nur die MAC-Adresse als allgemeines Erkennungsmerkmal.

                Nicht als Erkennungsmerkmal, sondern ausschließlich dazu, dass sich Rechner selbst mit ihrem "Wunschnamen" ins DNS eintragen können. Wenn Du in Microsoft-Shops einen kleinen Linux-Server einführen willst, die per DNS erreichbar sein soll, ohne dass Tonnen von Papier ausgefüllt werden, ist die Hostname-Option im DHCP-Request oft der einzige Weg. Analog für einige blöde DSL-Router, die zwar DHCP und DNS bieten, aber keinen Weg haben, um eigene DNS-Host-Einträge zu erzeugen.

                Vieles. Unter anderem daemontools, ...

                Habe ich zusammen mit Binc wieder entsorgt.

                Schade, Du hättest viel gelernt.

                Daemontools kümmern sich um Dinge wie automatischen Neustart, zuverlässiges Logging, etc.

                Verstehe. Also nichts, was man unbedingt bräuchte.

                Nee, is klar ...

                Aus rein akademischen Interesse: Wie? Hinweis, Fingerzeig?
                Was meinst Du? SMTP zu localhost?

                Nein, SMTP von PHP aus. Weil du behauptet hast, das sei mit Linux-PHP auch möglich, die Doku aber etwas anderes behauptet.

                Wo habe ich das behauptet? Ich zitiere mal aus https://forum.selfhtml.org/?t=198607&m=1334581:

                Vermutlich kann PHP auch unter Linux so konfiguriert werden, dass es sich mit einem SMTP-Server zum Versand verbindet wie unter Windows
                So weit ich weiß nein.

                Warum denn das nicht? Das wäre eine extrem dämliche Einschränkung. (Im Zweifel mal in die Doku schauen -- http://de2.php.net/manual/en/mail.configuration.php sagt tatsächlich, dass PHP nur unter Windoof SMTP kann -- D'oh!)

                Natürlich kann auch PHP unter Linux SMTP, aber nicht über die Standard-Funktion mail(). PHP kann TCP-Sockets öffnen und hat Libraries bzw. Includes. Das reicht, um einen SMTP-Client zu implementieren. Wahrscheinlich haben das zwei bis zweihundert Leute auch schon gemacht.

                Man könnte natürlich auch stumpf den Code, der nur unter Windows compiliert wird, auch für Unixe compilieren lassen, ggf. mit leichten Anpassungen. So tief im Dreck will ich aber gar nicht wühlen.

                In der Praxis überläßt Du SMTP besser einer Library, die sich um die ganzen Details kümmert, und auch das Konstruieren einer Mail mit allem Firlefanz (insbesondere MIME) überläßt Du besser einer Library.

                Nö. Das wäre ja langweilig. :-)

                Jaja, den Ansatz kenne ich. Mein aktueller Arbeitsplan sieht vor, mich mindestens die nächsten zwei Jahre nur mit millionenfach neu erfundenen Rädern (Halb- und Dreivierteilkreis, quadratisch, drei- und fünfeckig, aus Holz, Alu, Papier, Draht und Klebeband, für Feldwege, nördlich oder westlich, aber nicht südlich führende Dorfstraßen, dreispurige Aurobahnen, usw.) zu beschäftigen und die diversen kleinen Problemchen zu beseitigen, die dabei entstanden sind. Erwähnte ich, dass es keine Pläne gibt?

                Wenigstens stimmt das Schmerzensgeld. ;-)

                Alexander

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

    ich komme mit der Konfiguration von Binc IMAP irgendwie nicht weiter. Ich scheitere momentan an ein paar grundsätzlichen Fragen/Problemen.

    * IMAP-Accounts
    Ich kann bisher nicht finden, wie ich für Binc IMAP einen Mail-Account anlege. Ich gehe davon aus, dass ich dem Mailserver erstmal klarmachen muss, welche IMAP-Accounts es geben soll - also zumindest Benutzernamen, Passwort und Basisverzeichnis des IMAPdir-Verzeichnisbaums für diesen User. In der bincimap.conf kann ich ja nur *einen* Pfad eintragen - aber auch keine Login-Namen und Passwörter.
    Ich möchte eine Verzeichnisstruktur in etwa nach folgendem Muster realisieren:
     /
     +- mailsrv
        +- account1
        |   +- inbox
        |   +- sent
        |   +- anotherfolder
        |
        +- account2
        |   +- inbox
        |   +- sent
        |   +- anotherfolder
        |
        +- account2
        |   +- inbox
        |   +- sent
        |   +- anotherfolder
    ... etc.

    * Start des IMAP-Daemons
    Der Start des Servers scheint mir sehr umständlich und kompliziert realisiert - so umständlich, dass ich ihn noch nicht begriffen habe. Lässt sich das nicht einfach auf die "übliche" Methode /etc/init.d/imapd start abbilden? Was hat es mit dem inetd bzw. den zusätzlichen daemontools auf sich? Wozu sind die gut?

    * Dokumentation
    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.

    Anscheinend hat Alexander Foken ja schon Erfahrung mit dem Einsatz; zumindest er müsste mich da eigentlich ein wenig unterstützen können.

    Schönes Wochenende schon mal,
     Martin

    --
    Man gewöhnt sich an allem, sogar am Dativ.
    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
    1. Hallo,

      ich möchte mich noch mit vielen neuen Erfahrungen kurz zurückmelden ...

      ich komme mit der Konfiguration von Binc IMAP irgendwie nicht weiter.

      Und daran hat sich auch nichts geändert. Nachdem ich rund zwei Tage lang recherchiert, Dutzende von Forenbeiträgen quer durchs Netz gelesen, die schwache Doku von Binc fast auswendig gelernt und vieles ausprobiert habe, was dann immer noch nicht absolut klar war, habe ich das Programm für unbrauchbar erklärt.
      Ich habe es in dieser Zeit nicht einmal geschafft, Binc überhaupt zu starten, so dass ich zum Testen eine Telnet-Session an Port 143 hätte machen können.

      * IMAP-Accounts
      Ich kann bisher nicht finden, wie ich für Binc IMAP einen Mail-Account anlege.

      Da habe ich mittlerweile begriffen, dass Binc sich wohl ausschließlich an den Linux-Useraccounts orientiert. Das war ein weiterer Grund für mich, Binc in die Wüste zu schicken. Ich möchte, dass der IMAP-Daemon unter *einem* bestimmten wählbaren Useraccount läuft, der nichts mit den Namen zu tun hat, mit denen sich ein IMAP-Client anmelden bzw. authentifizieren kann.

      Ich bin inzwischen von Binc IMAP auf Dovecot übergegangen. Works like a charm!
      Etwa zwei Stunden Doku lesen, eine halbe Stunde emergen und Konfiguration editieren, und schon lief die Sache. Naja, fast. Ich hatte erst noch ein Permission-Denied-Problem beim Zugriff auf die Mail-Verzeichnisse, weil ich diese Verzeichnisse als root angelegt und vergessen hatte, sie auch dem Mail-User zu übereignen.

      Ich hatte mir in diesem Thread eigentlich mehr Aktivität gewünscht; denen, die sich beteiligt haben (auch am Nebenschauplatz Samba), möchte ich trotzdem nochmal herzlich danken. Denn auch wenn der Weg steinig ist, was bei Gentoo wohl normal ist, hat es mich doch wesentlich weitergebracht. Und wenn's endlich mal läuft, weiß man auch, warum! ;-)

      So long,
       Martin

      --
      Wenn alle das täten, wass sie mich können,
      käme ich gar nicht mehr zum Sitzen.
      Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
      1. Hi!

        ich komme mit der Konfiguration von Binc IMAP irgendwie nicht weiter.
        Und daran hat sich auch nichts geändert.

        Ich für meinen Teil habe UW-IMAP verwendet, das machte mir in der Vergangenheit keine Arbeit und lief einfach still und leise vor sich hin.

        * IMAP-Accounts
        Ich kann bisher nicht finden, wie ich für Binc IMAP einen Mail-Account anlege.

        Bei UW-IMAP ist es der Unix-Account. Aber das willst du ja nicht :-(

        Da habe ich mittlerweile begriffen, dass Binc sich wohl ausschließlich an den Linux-Useraccounts orientiert. Das war ein weiterer Grund für mich, Binc in die Wüste zu schicken. Ich möchte, dass der IMAP-Daemon unter *einem* bestimmten wählbaren Useraccount läuft, der nichts mit den Namen zu tun hat, mit denen sich ein IMAP-Client anmelden bzw. authentifizieren kann.

        Was ist der Grund, dass du so ein System benötigst? Dann bliebe doch quasi nur der Superuser übrig. Ich stelle mir das sicherheitstechnisch nicht gerade prickelnd vor, wenn auf sämtliche Post mit dem selben User zugegriffen werden kann. Dann benötigst du innerhalb des IMAP-Servers eine Nachbildung der schon von Haus aus vorhandenen Nutzeraccounts. Wenn du nicht gerade Massenhoster bist, sehe ich da nicht wirklich den Bedarf.

        Ich hatte mir in diesem Thread eigentlich mehr Aktivität gewünscht;

        Tja, da bist du hier nicht der einzige. Ab einer gewissen Problemhöhe, Zielerreichungsaufwand und Qualitätsanforderung nimmt die Anzahl der Mitarbeiter ganz schön ab.

        Lo!

        1. Mahlzeit,

          ich komme mit der Konfiguration von Binc IMAP irgendwie nicht weiter.
          Und daran hat sich auch nichts geändert.
          Ich für meinen Teil habe UW-IMAP verwendet, das machte mir in der Vergangenheit keine Arbeit und lief einfach still und leise vor sich hin.

          über UW-IMAP habe ich auch mal ein bisschen gelesen. Ich weiß nicht mehr, warum ich das für mich nicht in engere Wahl gezogen habe - vielleicht war ich der Meinung, das sei zu umfangreich? Ich weiß es echt nicht mehr, ist schon ein paar Wochen her.

          Ich möchte, dass der IMAP-Daemon unter *einem* bestimmten wählbaren Useraccount läuft, der nichts mit den Namen zu tun hat, mit denen sich ein IMAP-Client anmelden bzw. authentifizieren kann.
          Was ist der Grund, dass du so ein System benötigst?

          Frei nach einem aktuellen Fernseh-Werbespot: Nein, ich brauche es nicht. Aber ich will es.
          Ernsthaft: Ich vertrete den Standpunkt, dass ein Server-Dienst gegenüber dem Betriebssystem, unter dem er läuft, ein ganz gewöhnlicher Prozess ist, der unter einem dedizierten Benutzeraccount läuft. Wenn der Dienst, den dieser Server anbietet, nicht unmittelbar mit der Verwaltung des Hostsystems oder dem interaktiven Kontakt mit dem System an sich zusammenhängt (wie etwa bei einer SSH-Shell), dann sollten Dienst-Nutzer und System-Nutzer voneinander getrennt bleiben, und der Dienst hat sich selbst um die Authentifizierung seiner Nutzer zu kümmern. Schließlich möchte ich die Anzahl der System-User der Übersicht wegen so gering wie möglich halten.
          Beim Apachen lege ich die User für HTTP-AUTH ja auch nicht als Unix-User an, und Samba hat auch nicht notwendigerweise eine 1:1-Abbildung des Samba-Accounts auf den Systemaccount.

          Dann bliebe doch quasi nur der Superuser übrig.

          Nein, im Gegenteil, ich habe dazu einen dedizierten User "maild" mit minimalen Rechten, dem die gesamten Maildirs gehören. Der Mailserver sorgt dann dafür, dass der authentifizierte IMAP-User jeweils nur "sein" Maildir sieht.

          Ich stelle mir das sicherheitstechnisch nicht gerade prickelnd vor, wenn auf sämtliche Post mit dem selben User zugegriffen werden kann.

          Du möchtest also lieber jeden Mitarbeiter einzeln für den ordnungsgemäßen Zustand und die Verfügbarkeit der Werkzeuge verantwortlich machen, anstatt *einen* zu benennen, der für die Werkzeugausgabe zuständig ist und gegen Unterschrift ins Werkzeugbuch das Gewünschte heraussucht?

          Ich hatte mir in diesem Thread eigentlich mehr Aktivität gewünscht;
          Tja, da bist du hier nicht der einzige. Ab einer gewissen Problemhöhe, Zielerreichungsaufwand und Qualitätsanforderung nimmt die Anzahl der Mitarbeiter ganz schön ab.

          Das ist schön formuliert, aber auch für mich keine neue Erkenntnis. Anders ausgedrückt: Fachwissen ist was Feines, aber leider nimmt die Anzahl der Leute immer mehr ab, die man dann noch um Rat fragen kann, wenn man selbst mal nicht mehr weiter weiß.

          So long,
           Martin

          --
          Wer mit dem Finger droht, sollte ihn am Abzug haben, und nicht in der Nase.
          Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
          1. Hi!

            Beim Apachen lege ich die User für HTTP-AUTH ja auch nicht als Unix-User an, und Samba hat auch nicht notwendigerweise eine 1:1-Abbildung des Samba-Accounts auf den Systemaccount.

            Der Apache braucht üblicherweise keinen Speicherplatz pro User. Der Samba kann (muss aber nicht) persönliche Verzeichnisse verwalten. Ein Mail-Server braucht auf alle Fälle Speicherplatz pro User. Wenn man dazu die vom System bereitgehaltenen Ressourcen, wie Quota und ähnliches nutzen kann, muss man das Rad nicht neu implementieren.

            Nein, im Gegenteil, ich habe dazu einen dedizierten User "maild" mit minimalen Rechten, dem die gesamten Maildirs gehören. Der Mailserver sorgt dann dafür, dass der authentifizierte IMAP-User jeweils nur "sein" Maildir sieht.

            Ich verstehe dein Anliegen, aber nicht immer ist eine solche Trennung nach Zuständigkeiten inklusive der möglichen Redundanzen bei der Nutzerverwaltung als ideal anzusehen.

            Ich stelle mir das sicherheitstechnisch nicht gerade prickelnd vor, wenn auf sämtliche Post mit dem selben User zugegriffen werden kann.

            Du möchtest also lieber jeden Mitarbeiter einzeln für den ordnungsgemäßen Zustand und die Verfügbarkeit der Werkzeuge verantwortlich machen, anstatt *einen* zu benennen, der für die Werkzeugausgabe zuständig ist und gegen Unterschrift ins Werkzeugbuch das Gewünschte heraussucht?

            Für den Knast ist die Verwaltung zuständig. Die Nutzer aber agieren schön getrennt voneinander. In seiner Zelle kann jeder machen was er will. Es reicht wenn da Mauern sind. Da muss nicht immer jemand auf die Nichtüberschreitung der Grenzlinien achten.

            Lo!

    2. Moin Moin!

      * IMAP-Accounts
      Ich kann bisher nicht finden, wie ich für Binc IMAP einen Mail-Account anlege. Ich gehe davon aus, dass ich dem Mailserver erstmal klarmachen muss, welche IMAP-Accounts es geben soll - also zumindest Benutzernamen, Passwort und Basisverzeichnis des IMAPdir-Verzeichnisbaums für diesen User.

      Nö, mußt Du nicht. Alle Unix-User des Systems sind automatisch IMAP-User.

      In der bincimap.conf kann ich ja nur *einen* Pfad eintragen

      Richtig. Der Pfad bezieht sich außerdem noch auf das aktuelle Verzeichnis. Weil, naja, kommt gleich ...

      • aber auch keine Login-Namen und Passwörter.

      Das ist ja auch gar nicht nötig. checkpassword überprüft, ob Benutzername und Passwort gültig sind. Und zwar genauso wie login, d.h. anhand der Unix-Accounts.

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

      (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.

      bincimap selbst erwartet die Mails im aktuellen Verzeichnis und spricht den Teil von IMAP, der nichts mehr mit Login zu tun hat.

      Ich möchte eine Verzeichnisstruktur in etwa nach folgendem Muster realisieren:
      /
      +- mailsrv
          +- account1
          |   +- inbox
          |   +- sent
          |   +- anotherfolder
          |
          +- account2
          |   +- inbox
          |   +- sent
          |   +- anotherfolder
          |
          +- account2
          |   +- inbox
          |   +- sent
          |   +- anotherfolder
      ... etc.

      So wollte ich das auch haben. Wie Du siehst, geht bincimap aber davon aus, dass Mails im $HOME des jeweiligen Benutzers liegen. Ich habe daher in die Kette noch ein kleines Programm eingeklinkt, dass das Verzeichnis vor dem Aufruf von bincimapd noch einmal wechselt, zu /var/spool/maildir/$USERNAME.

      cat gotomaildir.c

        
      /*  
       * Usage: gotomaildir /var/spool/maildir program [args]  
       */  
        
      #include <sys/types.h> /* for struct passwd, uid_t */  
      #include <pwd.h> /* for getpwuid() */  
      #include <unistd.h> /* for chdir(), getuid(), execv() */  
        
      int main(int argc, char ** argv)  
      {  
              struct passwd * pw;  
        
              /*  
               * argv[0] = '/path/to/gotomaildir'  
               * argv[1] = maildir  
               * argv[2] = program  
               * argv[3..n] = args  
               */  
              if (argc<3) return 111;  
        
              /* chdir to maildir */  
              if (chdir(argv[1])==-1) return 111;  
        
              /* remove argv[0] and argv[1] */  
              argv++;  
              argv++;  
        
              /* get user login */  
              if (NULL==(pw=getpwuid(getuid()))) return 111;  
        
              /* chdir to username */  
              if (chdir(pw->pw_name)==-1) return 111;  
        
              /* now we are in /var/spool/maildir/$username */  
        
              execv(argv[0],argv);  
              return 111;  
      }  
      
      

      * Start des IMAP-Daemons
      Der Start des Servers scheint mir sehr umständlich und kompliziert realisiert - so umständlich, dass ich ihn noch nicht begriffen habe.

      Das ist nicht umständlich, das ist Unix. ;-)

      Im Klartext: Es GIBT KEINEN Daemon bei binc. Viele kleine Programme arbeiten zusammen, um einen großen Job zu erledigen. Genauso wie man z.B. find, xargs, cat und wc kombinieren kann, um herauszufinden, wie viele Codezeilen ein Projekt hat (find . -name '*.c' -or -name '*.h' -print0 | xargs -0 cat | wc -l).

      Natürlich kann man dafür auch ein eigenes, einzelnes Programm schreiben. Die Eleganz kommt, wenn Du mehr willst. Entweder stopfst Du das eine große Programm mit Features voll, die Du alle debuggen mußt, oder Du fügst nur ein weiteres Programm in die Kette ein, das einen weiteren Aspekt implementiert.

      Im Beispiel könntest Du z.B. sagen, dass leere Zeilen nicht als Code zählen sollen:

      find . -name '*.c' -or -name '*.h' -print0 | xargs -0 cat | grep -v ^$ |wc -l

      Voila, nicht eine Zeile Programmcode für die neue Funktion geschrieben.

      Für binc erlaubt diese Technik überhaupt erst, die Mail-Verzeichnisse aus dem HOME-Verzeichnis des Users herauszuhalten. Siehe oben, gotomaildir.c.

      Und weil sehr schnell sehr lange Kommandozeilen entstehen, die in inetd.conf nicht wirklich hübsch sind, habe ich binc in ein Wrapper-Script verpackt:

        
      #!/bin/ash  
      # ^-- ash is smaller and faster than bash  
      # If you don't have ash, use bash.  
        
      BINCETC=/opt/bincimap/etc  
      BINCBIN=/opt/bincimap/bin  
      CHKPWBIN=/opt/bincimap/bin  
      GOTOBIN=/opt/bincimap/bin  
      MAILDIR=/var/spool/maildir  
        
      exec \  
              "$BINCBIN/bincimap-up" --conf="$BINCETC/bincimap.conf" --logtype=syslog -- \  
              "$CHKPWBIN/checkpassword" \  
              "$GOTOBIN/gotomaildir" \  
              "$MAILDIR" "$BINCBIN/bincimapd"  
      
      

      In inetd.conf steht dann nur:

        
      #imap2   stream  tcp     nowait  root    /usr/sbin/tcpd  imapd  
      imap2   stream  tcp     nowait  root    /opt/bincimap/bin/imap-wrapper /opt/bincimap/bin/imap-wrapper  
      
      

      Weil gotomaildir schon ins passende Verzeichnis wechselt, steht in bincimap.conf in der Mailbox-Sektion für path nur "".

      binc legt die notwendigen Verzeichnisse ggf. selbst an, nur das leere Maildir-Verzeichnis für die User mußt Du selbst anlegen, mit Mode 770 (drwxrwx---), Eigentümer ist der jeweilige User (damit binc dort schreiben kann), Gruppe ist mail (damit exim dort schreiben kann). INBOX/cur, INBOX/new und INBOX/tmp kannst Du auch angelegen, mit identischen Rechten. Der Rest geht definitiv per IMAP-Client via binc.

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

      Nein, wozu? Binc wird über (x)inetd gestartet, wie diverse andere TCP- und UDP-Server auch.

      Was hat es mit dem inetd bzw. den zusätzlichen daemontools auf sich?
      Wozu sind die gut?

      Och komm, inetd ist in der Wikipedia beschrieben.

      Den Job, eingehende TCP-Verbindungen anzunehmen, hat inetd, xinetd, oder ucspi-tcp. Die Verbindung wird via STDIN und STDOUT weitergereicht an bincimap-up.

      Bincimap-up kümmert sich um Konfiguration und Privilegien, reicht weiter an checkpassword.

      Checkpassword kümmert sich um Login, ersetzt sich dann per exec() durch bincimapd (Bei mir: durch gotomaildir, dass sich nach einem chdir() dann durch bincimapd ersetzt).

      Bincimapd kümmert sich um IMAP nach der Login-Phase und um die Mail-Dateien.

      Daemontools brauchst Du nicht zwingend für binc, aber sie ersparen Dir das Theater mit PID-Files, zickenden Init-Scripts usw. Siehe mein anderes Posting von heute.

      * Dokumentation
      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? Man-Pages sind auch dabei. Es hilft allerdings ENORM, "the djb way" verstanden zu haben.

      Der feine Trick bei daemontools wie bei binc ist, dass die Programme massiv ausnutzen, dass ein Programm mit sehr vielen Parametern aufgerufen werden kann. Dabei nimmt das erste aufgerufene Programm gar keine oder nur sehr wenige Parameter für sich, der Rest ist das nächste aufzurufende Programm und dessen Parameter. Das erste Programm ersetzt sich dabei selbst per exec() durch das nächste Programm. (Unter Windows funktioniert das mangels brauchbarer Prozess-API nicht.)

      Die Kommandozeilen sind daher sehr lang und ohne Umbruch einfach unverständlich.

      Beispiel:
          bincimap-up --conf=/etc/bincimap.conf --logtype=syslog -- checkpassword gotomaildir /var/spool/maildir bincimapd

      Sauber eingerückt (mit \ am Zeilenende, um es vor der Shell zu verstecken)
          bincimap-up --conf=/etc/bincimap.conf --logtype=syslog -- \     checkpassword                                            \     gotomaildir /var/spool/maildir                           \     bincimapd

      Aufgerufen wird bincimap-up mit allen Parametern. bincimap-up nimmt sich selbst (argv[0]) und alle Parameter bis einschließlich "--" weg, und ruft am Ende exec() mit den übrig gebliebenen Parametern auf. Also:

      checkpassword gotomaildir /var/spool/maildir bincimapd

      Checkpassword nimmt nur sich selbst weg, ruft am Ende per exec() den Rest auf. Also:

      gotomaildir /var/spool/maildir bincimapd

      Gotomaildir nimmt sich selbst und einen Parameter weg, ruft am Ende wieder den Rest per exec() auf:

      bincimapd

      Jedes Programm auf dem Weg zu bincimapd hat eine einzige, kleine Aufgabe absolviert und sich dann selbst aus dem Speicher befördert, ohne dass sich Dinge wie STDIN, STDOUT, Environment oder Prozess-ID geändert hätten (außer genau das ist Aufgabe des jeweiligen Programms). Das ist wesentlich Resourcen schondender als ein fettes Binary, dass alles auf einmal implementiert. Ganz nebenbei wird so z.B. der Code, der mit Root-Rechten läuft, komplett aus dem Speicher geworfen. Fehler in bincimapd können nicht mehr zu erhöhten Privilegien führen, weil bincimapd nur noch mit Benutzerrechten läuft. So muß auch nur der Code in bincimap-up auf Root-Lücken überprüft werden, nicht der gesamte Code. Das geht mit kurzem, übersichtlichen Code wesentlich einfacher als mit einer All-in-one-Lösung.

      Und wenn Du nicht willst, dass IMAP-User sich mit dem Unix-Passwort anmelden, sondern mit einem anderen, schreibst Du Dir "einfach" einen Ersatz für checkpassword, der sich an das Protokoll hält. Ganz trivial könntest Du z.B. verlangen, dass das IMAP-Passwort das rückwärts geschriebene Unix-Passwort ist. Dann nimmst Du den Source von checkpassword, drehst das Passwort vor der Prüfung um, und compilierst das ganze als checkreversepassword. Dann ersetzt Du checkpassword durch checkreversepassword im Aufruf von bincimap-up und schon müssen IMAP-User ihr Passwort rückwärts tippen.

      Die Möglichkeiten sind fast unbegrenzt, z.B. eine Passwort-Datei im HOME des Users, eine SQLite-Datei mit IMAP-Passwörtern, LDAP, gar kein Passwort, dafür aber eine feste IP-Adresse, RSA-Token-Code + Passwort. Alles, ohne an binc herumzupatchen.

      Anscheinend hat Alexander Foken ja schon Erfahrung mit dem Einsatz; zumindest er müsste mich da eigentlich ein wenig unterstützen können.

      Klar, aber irgendwann hab ich auch mal Internet-freie Zeit. Du hast leider Pech gehabt, dass Du erstens keinen Service-Vertrag mit mir hast und zweitens die freie Zeit genau Deinen Thread getroffen hat.

      Alexander

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

        Ich kann bisher nicht finden, wie ich für Binc IMAP einen Mail-Account anlege. Ich gehe davon aus, dass ich dem Mailserver erstmal klarmachen muss, welche IMAP-Accounts es geben soll - also zumindest Benutzernamen, Passwort und Basisverzeichnis des IMAPdir-Verzeichnisbaums für diesen User.
        Nö, mußt Du nicht. Alle Unix-User des Systems sind automatisch IMAP-User.

        das habe ich inzwischen auch herausgefunden - aber auf die Idee muss man erstmal kommen. Für mich ist das nämlich alles andere als logisch oder gar selbstverständlich. Und so habe ich mehrere Stunden damit verbracht, die Antwort auf eine Frage zu finden, die sich eigentlich gar nicht stellt.

        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?

        (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!

        Der Start des Servers scheint mir sehr umständlich und kompliziert realisiert - so umständlich, dass ich ihn noch nicht begriffen habe.
        Das ist nicht umständlich, das ist Unix. ;-)

        Ja, mag sein. Deswegen muss man das aber nicht unbedingt gut finden.

        Im Klartext: Es GIBT KEINEN Daemon bei binc.

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

        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.

        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. 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). 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.
        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.

        Anscheinend hat Alexander Foken ja schon Erfahrung mit dem Einsatz; zumindest er müsste mich da eigentlich ein wenig unterstützen können.
        Klar, aber irgendwann hab ich auch mal Internet-freie Zeit. Du hast leider Pech gehabt, dass Du erstens keinen Service-Vertrag mit mir hast und zweitens die freie Zeit genau Deinen Thread getroffen hat.

        Gut, mit sowas muss ich rechnen. Immerhin bin ich in der Zwischenzeit auch selbständig zu einer Lösung gekommen - nämlich einen anderen IMAP-Server zu verwenden, der auf Anhieb so funktioniert, wie ich mir das vorstelle. 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.

        Schönen Abend noch,
         Martin

        --
        Ungeschehene Ereignisse können einen katastrophalen Mangel an Folgen nach sich ziehen.
          (Unbekannter Politiker)
        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
        1. 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

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

            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.

            ... 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, 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.

            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.

            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.

            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.

            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.

            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.

            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?

            Nichts. Meist werden Anfragen oder Kommentare nicht einmal beantwortet.

            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.

            Frust - ja. Lernresistenz? Bedingt. Aber beides hat nichts miteinander zu tun.
            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.

            Sendmail und bind sind verstrickt, undurchschaubar und mit Tonnen von Legacy-Code überfrachtet.

            Für BIND stimme ich zu, sendmail kenne ich nur flüchtig von außen, kann also kein Urteil fällen. 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 wenn du jetzt glaubst, ich würde dir Vorwürfe machen, weil ich Binc auf deinen Rat hin ausgewählt und ausprobiert habe: Nein, überhaupt nicht. Immerhin habe ich -frei nach Edison- dabei wieder etwas gelernt. Nämlich dass dieser Weg für mich nicht zufriedenstellend ist.

            Ciao,
             Martin

            --
            Die meisten Menschen werden früher oder später durch Computer ersetzt.
            Für manche würde aber auch schon ein einfacher Taschenrechner genügen.
            Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
            1. 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".
              1. Hi,

                ... 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.

                mit so mancher, ja. Wobei mein häufigster Kritikpunkt der ist, dass dem Programm ein geheimnisvoller Installer beiliegt, der vollautomatisch und möglicherweise korrekt "irgendwas" tut, und man weiß nicht, was dieses "irgendwas" ist. Eine Anleitung, wie die Software alternativ manuell zu installieren wäre, vermisse ich tatsächlich oft.
                Angaben zum Funktionsumfang, den nötigen Rahmenbedingungen oder der Interoperabilität sind aber meistens problemlos zu kriegen.

                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.

                Nicht mit Binc, sondern mit dessen Friss-oder-stirb-Konzept. Das gilt für manche andere Software auch.

                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, ...

                Ja. Und diese beiden Dateien auch separat an prominenter Stelle bereitzuhalten (z.B. auf der Website des Projekts), wäre das absolute Minimum, was ich erwarte.

                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 Sich-Beschweren. Da gehe ich lieber zum nächsten Anbieter, und gut is'. Es sei denn, ich bin auf eben dieses eine Angebot angewiesen, weil es nichts Gleichwertiges gibt. Das ist ja das Schöne an der Vielfalt: Es ist für jeden was dabei.

                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.
                [...]
                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.

                Apache, PHP, mySQL, Samba sind tatsächlich vorbildlich dokumentiert; darüber hinaus sind sie so verbreitet (und schon so lange am Markt), dass es unzählige Bücher gibt, die entweder in Details noch weiter in die Tiefe gehen oder bestimmte Bereiche anfängertauglich aufbereiten. Die anderen Beispiele, die du genannt hast, kenne ich nur dem Namen nach.
                Aber gerade Consumer-Ware erfreut sich teilweise eines nahezu völligen Fehlens jeglicher Doku, etwa die Mozilla-Produkte. Gäbe es da nicht Millionen von Anwendern, die immer mal wieder irgendwas herausfinden, oder Programmierer, die sich wirklich die Mühe machen, die Sources zu analysieren, um herauszufinden, was da wirklich abläuft ...

                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.

                Nein. Wie gesagt: Lernresistenz liegt bei mir dann vor, wenn ich kein klares Ziel vor Augen habe. Ich bin gern bereit, Neues zu lernen, wenn ich absehen kann, wozu es gut ist, und dass dieses Ziel auch wirklich meinen Vorsellungen entspricht. Lernen nur aus reiner Neugier? Oder weil jemand sagt, "Hier, lies mal, ist interessant"? Nicht mein Ding. Ich bin zielorientiert. Erst wenn das Ziel steht, möchte ich auch den Weg ganz genau kennen.

                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.

                Okay, das habe ich so zur Kenntnis genommen und sage: Danke, aber es gibt andere Methoden, die offenbar das gleiche erreichen, und die mir bereits vertrauter sind. Ich sehe nicht ein, wieder etwas anderes zu lernen, ohne dessen Vorzug klar sehen zu können.

                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?

                Wenn man der Beschreibung glauben darf, ziemlich gut. Aber das ist auch für mich ein nebensächliches Thema - ich bin alleiniger Nutzer des Systems und muss mich nicht vor mir selbst schützen. Wichtig ist mir Stabilität (also störungsfreier Betrieb), leichte Administrierbarkeit und kompaktes Design. Die Tatsache, dass ich als Linux-Greenhorn das Teil in knapp drei Stunden fix und fertig zum Laufen gebracht habe, spricht für sich, finde ich. DAS sind Dinge, die mir wichtig sind, nicht ein Award für elegantes und ästhetisches Softwaredesign.

                Aber Dovecot läßt permanent etwas Code mit Root-Rechten laufen, dieser Prozess ist u.a. auch für das Logging zuständig.

                Ja. Na und?

                Zum Mail Process Design liest mal nur FIXME.

                Hehe, das habe ich auch noch nicht gesehen.

                Natürlich gibt es zwei Wikis, wäre ja auch langweilig mit nur einem.

                Zwei? Ich habe nur ein gefunden.

                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.

                Ja, mag sein. Aber diese Informationen sind eben auch zugänglich, ohne dass man das Source-Archiv bereits in der Hand hat. So wie ich das erwarte und voraussetze.

                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.

                Mach ich - wenn ich mal wirklich Zeit und Muße habe.

                Ciao,
                 Martin

                --
                Fettflecke werden wieder wie neu, wenn man sie regelmäßig mit etwas Butter einschmiert.
                Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                1. Moin Moin!

                  ... 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.

                  mit so mancher, ja. Wobei mein häufigster Kritikpunkt der ist, dass dem Programm ein geheimnisvoller Installer beiliegt, der vollautomatisch und möglicherweise korrekt "irgendwas" tut, und man weiß nicht, was dieses "irgendwas" ist. Eine Anleitung, wie die Software alternativ manuell zu installieren wäre, vermisse ich tatsächlich oft.

                  Das haben Microsoft und die Installer-Hersteller Anwendern und Entwicklern in den letzten 20 Jahren gründlich abgewöhnt. Unter Windows ist eine Installation von Software, die intensiv MS-Technik benutzt, ohnehin mit massiven Eingriffen in die große Müllhalde alias Registry verbunden, da ist ein guter Installer zumindest der stabilere Weg für den Normalanwender.

                  Ich fand die Installation unter klassischem MacOS schon immer elegant: Disk Image bzw. Archiv öffnen, Programm auf die Platte kopieren, fertig.

                  Das geht mit Windows-Software auch, kommt aber eben bei Registry-Geschichten (ActiveX-Controls, ...) schnell an seine Grenzen.

                  Einige Software gibt es in beiden Varianten: Als Archiv mit Executables und Doku, und als Installer (EXE oder MSI). Beispiele: PuTTY, Startup Control Panel, TightVNC

                  Die großen, bekannten Projekte sind gut dokumentiert [...]

                  Aber gerade Consumer-Ware erfreut sich teilweise eines nahezu völligen Fehlens jeglicher Doku, etwa die Mozilla-Produkte. Gäbe es da nicht Millionen von Anwendern, die immer mal wieder irgendwas herausfinden, oder Programmierer, die sich wirklich die Mühe machen, die Sources zu analysieren, um herauszufinden, was da wirklich abläuft ...

                  Mozilla kenne ich nicht von innen, aber ich denke, dass da noch jede Menge Altlasten aus Netscape-Zeiten mitgeschleppt werden. Vielleicht nicht unbedingt im Code, aber in der Art und Weise, wie die Projekte die entwickelt werden. Mozilla, und dort vor allem Firefox und Thunderbird, hat natürlich ein riesiges Problem, das andere Projekte nicht dermaßen stark haben: Es gibt reichlich Konkurrenz und sehr viele "Kunden", die schnell zu einem Konkurrenzprodukt wechseln, wenn es nicht regelmäßig sichtbare Updates gibt und in vielen Punkten nicht mindestens das Niveau der Konkurrenz erreicht wird.

                  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.

                  Okay, das habe ich so zur Kenntnis genommen und sage: Danke, aber es gibt andere Methoden, die offenbar das gleiche erreichen, und die mir bereits vertrauter sind. Ich sehe nicht ein, wieder etwas anderes zu lernen, ohne dessen Vorzug klar sehen zu können.

                  Fang an, mit Maschinen unter Last zu arbeiten und Du wirst den Vorteil dieser Methode sehen. Das muß nicht zwangsläufig "Big Iron" sein, auch auf kleinen Embedded-Systemen kann man so sehr viel erreichen, ohne 100W Grundlast aus der Steckdose zu saugen.

                  Und wie steht es mit der Sicherheit?

                  Wenn man der Beschreibung glauben darf, ziemlich gut. Aber das ist auch für mich ein nebensächliches Thema - ich bin alleiniger Nutzer des Systems und muss mich nicht vor mir selbst schützen. Wichtig ist mir Stabilität (also störungsfreier Betrieb), leichte Administrierbarkeit und kompaktes Design. Die Tatsache, dass ich als Linux-Greenhorn das Teil in knapp drei Stunden fix und fertig zum Laufen gebracht habe, spricht für sich, finde ich. DAS sind Dinge, die mir wichtig sind, nicht ein Award für elegantes und ästhetisches Softwaredesign.

                  Dir ist bewußt, dass Du Daten aus dem Netz verarbeitest? Werden die validiert, bevor sie in Dovecot hineinlaufen? Wohl kaum. Und genau deswegen ist es auch auf Single-User-Systemen hinter NAT-Routern wichtig, dass die Software sicher ist.

                  Aber Dovecot läßt permanent etwas Code mit Root-Rechten laufen, dieser Prozess ist u.a. auch für das Logging zuständig.

                  Ja. Na und?

                  Ein Loch an der Stelle und ein Angreifer ist root. Loggt man mit nobody-Rechten, ist ein Angreifer erstmal nur nobody und muß noch ein zweites Loch finden, um root zu werden.

                  Ich spreche hier noch nicht einmal von gezielten Angriffen, das normale "Grundrauschen" durch Botnetze und Scriptkiddies ist schon schlimm genug.

                  Zum Mail Process Design liest mal nur FIXME.

                  Hehe, das habe ich auch noch nicht gesehen.

                  Eine der ersten Seiten, auf die ich beim willkürlichen Klicken gestoßen bin. Das vermiest den Eindruck eines Projektes schonmal merklich.

                  Natürlich gibt es zwei Wikis, wäre ja auch langweilig mit nur einem.

                  Zwei? Ich habe nur ein gefunden.

                  http://wiki2.dovecot.org/ -- ganz oben im ersten Wiki verlinkt. "Wer lesen kann, ist klar im Vorteil" pflegte mein Ex-Kollege in solchen Fällen zu sagen.

                  Ja, mag sein. Aber diese Informationen sind eben auch zugänglich, ohne dass man das Source-Archiv bereits in der Hand hat. So wie ich das erwarte und voraussetze.

                  busybox macht das, binc leider nicht. Blöd, insbesondere weil das wirklich wenig Mühe machen würde.

                  Alexander

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

                    Wobei mein häufigster Kritikpunkt der ist, dass dem Programm ein geheimnisvoller Installer beiliegt, der vollautomatisch und möglicherweise korrekt "irgendwas" tut, und man weiß nicht, was dieses "irgendwas" ist. Eine Anleitung, wie die Software alternativ manuell zu installieren wäre, vermisse ich tatsächlich oft.
                    Das haben Microsoft und die Installer-Hersteller Anwendern und Entwicklern in den letzten 20 Jahren gründlich abgewöhnt. Unter Windows ist eine Installation von Software, die intensiv MS-Technik benutzt, ohnehin mit massiven Eingriffen in die große Müllhalde alias Registry verbunden, da ist ein guter Installer zumindest der stabilere Weg für den Normalanwender.

                    ja, das sehe ich ein - aber trotzdem kein Grund für die Software-Anbieter, die Vorgänge zu verheimlichen, die bei der automatischen Installation ablaufen. Wenn ich keine akzeptable Alternative zu einem undurchschaubaren Installer sehe, heißt das für mich: Komplettbackup (Image) der Systempartition, Installer starten und sämtliche Änderungen an Registry und Windows-Dateibestand überwachen. Danach habe ich wenigstens ein Protokoll der durchgeführten Eingriffe und kann ggf. manuell korrigieren (z.B. Bibliotheken vom Windows-Verzeichnis ins Programmverzeichnis verschieben und die Registry-Einträge anpassen).

                    Ich fand die Installation unter klassischem MacOS schon immer elegant: Disk Image bzw. Archiv öffnen, Programm auf die Platte kopieren, fertig.

                    So ist es optimal.

                    Einige Software gibt es in beiden Varianten: Als Archiv mit Executables und Doku, und als Installer (EXE oder MSI). Beispiele: PuTTY, Startup Control Panel, TightVNC

                    Videolan, früher auch Firefox, Apache, mySQL, ...

                    Mozilla, und dort vor allem Firefox und Thunderbird, hat natürlich ein riesiges Problem, das andere Projekte nicht dermaßen stark haben: Es gibt reichlich Konkurrenz ...

                    Thunderbird ist meiner Ansicht nach unter Windows konkurrenzlos. Höchstens Outlook Express kam in die Nähe, war in einzelnen Punkten etwas pfiffiger, in anderen weniger raffiniert, aber insgesamt eine Alternative.

                    Und wie steht es mit der Sicherheit?
                    Wenn man der Beschreibung glauben darf, ziemlich gut. Aber das ist auch für mich ein nebensächliches Thema ...
                    Dir ist bewußt, dass Du Daten aus dem Netz verarbeitest?

                    Ja, und genau das: Daten. Daten, die überall, außer ganz am Ende der Kette im Mailclient, nur durchgereicht werden.

                    Werden die validiert, bevor sie in Dovecot hineinlaufen? Wohl kaum.

                    Nein. Aber sie werden ja auch nicht in dem Sinn "benutzt", sondern einfach nur gespeichert und zum Abruf bereitgehalten. Was will ich an e-Mails validieren? Das sind Textfetzen, von denen der Mailclient als letzte Instanz Teile auch noch als Dateianhang interpretieren und speichern kann.
                    So gesehen könnte es mir sogar egal sein, wenn irgendein anderer Prozess außer dem fetchmail/procmail-Tandem zusätzliche Dateien in die Maildirs schreibt, solange er nicht vorhandene Daten verändert oder löscht.

                    Aber Dovecot läßt permanent etwas Code mit Root-Rechten laufen, dieser Prozess ist u.a. auch für das Logging zuständig.
                    Ja. Na und?
                    Ein Loch an der Stelle und ein Angreifer ist root.

                    Und wo soll dieser Angreifer herkommen?

                    Ciao,
                     Martin

                    --
                    Abraham sprach zu Bebraham: Kann i mal dei Cebra ham?
                    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                    1. Moin Moin!

                      Thunderbird ist meiner Ansicht nach unter Windows konkurrenzlos.

                      Sag sowas nicht laut, wenn Outlook-Fetischisten in der Nähe sind ... ;-)

                      Und wie steht es mit der Sicherheit?
                      Wenn man der Beschreibung glauben darf, ziemlich gut. Aber das ist auch für mich ein nebensächliches Thema ...
                      Dir ist bewußt, dass Du Daten aus dem Netz verarbeitest?

                      Ja, und genau das: Daten. Daten, die überall, außer ganz am Ende der Kette im Mailclient, nur durchgereicht werden.

                      Irrtum!

                      Schon fetchmail interpretiert und manipuliert die Daten, die aus dem Netz kommen. Und erst recht der lokale MTA, der anhand der via SMTP angelieferten Daten entscheiden muß, ob, wie und wohin diese Daten weitergereicht oder abgelegt werden. Und auch Dovecot muß die Daten interpretieren, wenigstens wenn Du das mbox-Format benutzt.

                      Werden die validiert, bevor sie in Dovecot hineinlaufen? Wohl kaum.

                      Nein. Aber sie werden ja auch nicht in dem Sinn "benutzt", sondern einfach nur gespeichert und zum Abruf bereitgehalten.

                      Nein, eben nicht.

                      Was will ich an e-Mails validieren? Das sind Textfetzen, von denen der Mailclient als letzte Instanz Teile auch noch als Dateianhang interpretieren und speichern kann.

                      Irrtum. Mails haben ein recht komplexes Format, bei dem es immer wieder Interpretationsspielräume gab und gibt. Das führt zu unterschiedlichem Verhalten bis hin zu Fehlern.

                      So gesehen könnte es mir sogar egal sein, wenn irgendein anderer Prozess außer dem fetchmail/procmail-Tandem zusätzliche Dateien in die Maildirs schreibt, solange er nicht vorhandene Daten verändert oder löscht.

                      Erstens ist außer fetchmail und procmail auch noch der MTA beteiligt.

                      Zweitens ist es bei Maildir/Maildir++/IMAPdir sogar erlaubt, zusätzliche Dateien in die Verzeichnisse zu packen -- aber eben durch Anwendungen, nicht durch Malware.

                      Drittens hast Du in dem Moment ein Riesenproblem, in dem Malware Schreibrechte auf den Maildirs hat. Damit hat sie nämlich auch automatisch das Recht, Dateien zu löschen.

                      Aber Dovecot läßt permanent etwas Code mit Root-Rechten laufen, dieser Prozess ist u.a. auch für das Logging zuständig.
                      Ja. Na und?
                      Ein Loch an der Stelle und ein Angreifer ist root.

                      Und wo soll dieser Angreifer herkommen?

                      Aus dem Netz, woher sonst? Das muß nicht einmal gezielt auf Dich gerichtet sein. Genauso wie der ILOVEYOU/LOVELETTER-Wurm nicht gezielt auf einen bestimmten User gerichtet war, sondern stumpf gegen jeden Outlook-Nutzer gerichtet war. Genauso wie der SQL Slammer. Ein einziger Buffer Overflow reicht schon aus.

                      Wenn Du mal Zeit hast, arbeite Dich durch http://cr.yp.to/2004-494.html.

                      Alexander

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

                        Thunderbird ist meiner Ansicht nach unter Windows konkurrenzlos.
                        Sag sowas nicht laut, wenn Outlook-Fetischisten in der Nähe sind ... ;-)

                        ich hab keine Angst vor denen!

                        Dir ist bewußt, dass Du Daten aus dem Netz verarbeitest?
                        Ja, und genau das: Daten. Daten, die überall, außer ganz am Ende der Kette im Mailclient, nur durchgereicht werden.
                        Irrtum!
                        Schon fetchmail interpretiert und manipuliert die Daten, die aus dem Netz kommen.

                        Nach meinem bisherigen Verständnis nicht. Es holt die Mails per POP3 vom Provider ab und gibt sie ohne weitere Aktionen an procmail weiter. Und procmail hat (derzeit noch) Anweisung, sie direkt im INBOX-Verzeichnis des IMAP-Maildirs abzulegen. Ohne jegliche Interpretation.
                        Dass dabei Fragmente von Informationen aus den Headerzeilen (Absender, Subject) gelesen und in Logdateien geschrieben werden, spielt keine Rolle, denn hier handelt es sich auch nur um eine Mustererkennung und das Extrahieren und Speichern von Textdaten.

                        Und erst recht der lokale MTA, der anhand der via SMTP angelieferten Daten entscheiden muß, ...

                        Ich hab auf dieser Büchse keinen MTA, und ich hab nichts, was SMTP spricht. Und sie bietet auch keine Serverdienste "nach draußen" an, sondern auf 192.168.123.0/24 beschränkt.

                        Und auch Dovecot muß die Daten interpretieren, wenigstens wenn Du das mbox-Format benutzt.

                        Das ist etwas, das ich von vornherein vermeiden wollte. Deshalb Maildir.

                        Was will ich an e-Mails validieren? Das sind Textfetzen, von denen der Mailclient als letzte Instanz Teile auch noch als Dateianhang interpretieren und speichern kann.
                        Irrtum. Mails haben ein recht komplexes Format, bei dem es immer wieder Interpretationsspielräume gab und gibt. Das führt zu unterschiedlichem Verhalten bis hin zu Fehlern.

                        Ja, aber solange ein Stück Information nur als Text verarbeitet wird, kann nichts passieren. Okay, es kann passieren, dass einzelne Mails aufgrund von Formfehlern nicht bearbeitet, d.h. nicht gespeichert oder weitergereicht werden. Es kann auch passieren, dass der Inhalt verstümmelt wird. Das ist aber alles nichts, was das Hostsystem in irgendeiner Weise aus der Ruhe bringen kann.

                        So gesehen könnte es mir sogar egal sein, wenn irgendein anderer Prozess außer dem fetchmail/procmail-Tandem zusätzliche Dateien in die Maildirs schreibt, solange er nicht vorhandene Daten verändert oder löscht.
                        Erstens ist außer fetchmail und procmail auch noch der MTA beteiligt.

                        Nein. Es gibt keinen.

                        Drittens hast Du in dem Moment ein Riesenproblem, in dem Malware Schreibrechte auf den Maildirs hat. Damit hat sie nämlich auch automatisch das Recht, Dateien zu löschen.

                        Ja. Das will ich natürlich nicht, und deswegen ist der Zugriff auf die Maildir-Verzeichnisse auch stark eingeschränkt. Aber selbst wenn dieser Unfall auftreten sollte, würde er nur Nutzdaten betreffen, das System und die Software an sich aber nicht gefährden.

                        Und wo soll dieser Angreifer herkommen?
                        Aus dem Netz, woher sonst? Das muß nicht einmal gezielt auf Dich gerichtet sein.

                        Mich würde brennend interessieren, wie das funktionieren könnte.

                        Wenn Du mal Zeit hast, arbeite Dich durch http://cr.yp.to/2004-494.html.

                        Bah, alles nur PDF ... :-(

                        Ciao,
                         Martin

                        --
                        Frage an Radio Eriwan: Kann man eigentlich ein guter Kommunist und gleichzeitig ein guter Christ sein?
                        Radio Eriwan antwortet: Im Prinzip ja - aber warum sollte man sich das Leben doppelt schwer machen?
                        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                        1. Hi!

                          Schon fetchmail interpretiert und manipuliert die Daten, die aus dem Netz kommen.
                          Dass dabei Fragmente von Informationen aus den Headerzeilen (Absender, Subject) gelesen und in Logdateien geschrieben werden, spielt keine Rolle, denn hier handelt es sich auch nur um eine Mustererkennung und das Extrahieren und Speichern von Textdaten.

                          Und was ist Mustererkennung? Stringverarbeitung. Dafür braucht man ausreichend dimensionierte Puffer und einen Test, dass die Daten kleiner sind als der Puffer. Sonst gibt es Pufferüberlauf. Aber das solltest du eigentlich wissen.

                          Ja, aber solange ein Stück Information nur als Text verarbeitet wird, kann nichts passieren.

                          In Sprachen wie C#, Java, PHP, Python usw. in denen sich der Programmierer in der Regel keine Gedanken über String- und Puffergrößen zu machen braucht, passiert bei Stringverarbeitung nicht viel. Aber C sieht da schon ganz anders aus.

                          Drittens hast Du in dem Moment ein Riesenproblem, in dem Malware Schreibrechte auf den Maildirs hat. Damit hat sie nämlich auch automatisch das Recht, Dateien zu löschen.
                          Ja. Das will ich natürlich nicht, und deswegen ist der Zugriff auf die Maildir-Verzeichnisse auch stark eingeschränkt.

                          Das nützt dir nur nichts, wenn das kompromittierbare Glied in der Kette Root-Rechte benötigt. Einer der für viele arbeiten soll, braucht auch Rechte für eben diese Gruppe und kann dann auch mal eben alle Daten der Gruppe löschen. Auch wenn er zur Erledigung der Aufgabe weniger berechtigte Child-Prozesse abspaltet, muss er erst einmal wissen, für wen er diesen Childprozess aufsetzen muss, wofür er unter einer generellen Berechtigung Daten analysieren muss.

                          Bei einem generellen Posteingang lässt sich das nicht vermeiden, aber in deinem Fall geht es um IMAP-Zugriff, also ein bestimmter Anwender will sein Postfach abfragen. Und da reicht es, wenn der Abfrageprozess unter seiner Kennung arbeitet und nicht mit einer Gruppenkennung. Stringverarbeitung mit potentiellen Pufferüberläufen gibt es auch bei IMAP, beispielsweise beim Anlegen von Ordnern.

                          Lo!