Fehler in der Mailserver-Konfiguration? – Gruppe "vmail"

[CHF]

Hallo,

nach der Mailserver-Einrichtung ergaben sich hier äußerst seltsame Fehlermeldungen:

/var/log/mail.warn.1:Oct 31 23:25:15 sd-150199 postfix/smtpd[13965]: warning: SASL: Connect to private/auth failed: No such file or directory
/var/log/mail.warn.1:Oct 31 23:25:15 sd-150199 postfix/smtpd[13965]: fatal: no SASL authentication mechanisms

Nach langer Suche habe ich diese wegbekommen. In der Konfigurationsdatei, die Froxlor erzeugt hatte und die ich anlegen sollte, gab es eine Gruppe vmail, die nicht existierte, auch hat Froxlor mich nicht aufgefordert, eine solche anzulegen. Daher habe ich in der Konfigurationsdatei die vom Betriebssystem „mitgelieferte“ Gruppe mail verwendet, nun scheint es zu laufen. Ist das ein Fehler in Froxlor oder stimmt bei mir irgendetwas nicht? Spricht etwas dagegen, die Gruppe mail dort zu verwenden, wo Froxlor vmail vorsieht?

Version: 0.10.21-1 (DB: 202009070)

[d00p]

vmail wird durchaus in den konfigurationsschritten angelegt, user wie gruppe, allerdings nur sofern diese nicht existieren. Welche distro/config-templates hast du denn genutzt?

[CHF]

Debian Buster, Postfix & Dovecot. Kann ich es auch bei „mail“ belassen oder spricht da was gegen?

[d00p]

Das komplette setup basiert darauf, leg den user doch einfach korrekt an:

groupadd -g 2000 vmail
useradd -u 2000 -g vmail vmail

 

[CHF]

Gerade habe ich noch einmal nachgeschaut: weder bei Postfix, noch bei Dovecot fordert es mich auf, die Gruppe oder den Benutzer anzulegen, obschon nichts davon existiert.

[CHF]

Ist die ID 2000 auch wichtig oder läuft alles über den Namen?

[d00p]

27 minutes ago, CHF said:

Ist die ID 2000 auch wichtig oder läuft alles über den Namen?

Auch wichtig, sofern du 2000 in den froxlor Einstellungen hinterlegt hast dafür. Tlw für die configs bei Ersterstellung

30 minutes ago, CHF said:

Gerade habe ich noch einmal nachgeschaut: weder bei Postfix, noch bei Dovecot fordert es mich auf, die Gruppe oder den Benutzer anzulegen, obschon nichts davon existiert.

k.A. hat bei mir immer wunderbar geklappt beim Setup. Hast du irgendein spezielles Setup, selinux oder irgendwas? Mit Default Buster tut das alles wunderbar

[CHF]

Nein, sowas habe ich nicht, erscheint mir übertrieben, man kann's auch „überkomplex“ machen mit der Sicherheit und dabei dann Fehler übersehen und dann wäre es schlechter als ohne diesen zusätzlichen Sicherheitskram. Aber inzwischen habe ich einen Verdacht. Ich habe nämlich nirgendwo 2000 hinterlegt; kann es aber sein, daß das der Standard-Vorschlag für den Benutzer und die Gruppe ist, der die Mails gehören sollen?

[d00p]

Ja das ist so. Wenn du halt uid/gid anderst z.b. von einem User den es schon gibt und der vllt gar nicht dafür gedacht ist, dann funktioniert da natürlich nix

[CHF]

Also, inzwischen habe ich es nachvollziehen können (hab' mir angewöhnt, von solchen Servern ein Log aller wichtigen Aktionen von Hand mitzuschreiben):

Mir wurde da (weil ich die Konfigurations-Einstellungs-Dinger im wesentlichen in der Reihenfolge ihrer Anzeige in der Verwaltungs-Oberfläche nach durchgegangen bin) „plötzlich“ eine ID 2000 für die Mails angezeigt. Als nicht ganz unfähiger Administrator habe ich an der Stelle als erstes nachgeschaut, ob es die vorgeschlagene ID in meinem „frischen“ Debian mit neu installiertem Froxlor-Paket überhaupt gibt – tat sie natürlich nicht. Sodann habe ich überlegt, was da nun also am besten zu tun wäre. An der Stelle war nicht einmal ansatzweise erkennbar, wie ein anzulegendes Benutzer-Gruppen-Pärchen denn namentlich hätte heißen sollen. Nun hat Debian für solche Zwecke jedoch bereits die traditionelle ID 8 (mail) vorgesehen – alle Mail-Pakete bringen bei Bedarf ihre eigenen zusätzlichen Systembenutzer und -Gruppen mit (postfix, dovecot, dovenull beispielsweise) und die traditionelle ID bleibt für generische Zwecke übrig. Die war demnach am passendsten, also habe ich sie einfach genommen. Nicht existierende, willkürliche Zahlen dort stehen zu lassen, erschien mir nicht sinnvoll. Froxlor hat nunmehr richtig erkannt, daß die IDs bereits existieren und daher nicht mehr angelegt zu werden brauchen, aber stillschweigend vorausgesetzt, daß die Eintragungen mit Namen gefälligst „vmail“ zu heißen hätten.

Damit wären wir bei meinem Punkt: das ist ein Fehler in Froxlor und kein Fall von einem Administrator, der „mal eben“ die Vorgaben ändert, ganz ohne zu wissen, was er da tut. Gerade dann, wenn man nachdenkt und nicht einfach auf „weiter“ klickt, wird man in die Irre geführt. Entweder müßte im Beschreibungstext darauf hingewiesen werden, daß es um Froxlor-eigene System-IDs mit Namen „vmail“ geht, oder Froxlor müßte bei Angabe bereits bestehender Konten auch deren Namen übernehmen. So wie es ist, ist das irreführend! Es kommt erschwerend hinzu, daß in diesem Fall kryptische SASL-Fehlermeldungen auftreten, die keineswegs bei der Problemlösung weiterhelfen, sondern weiter in die Irre führen.

Die gute Nachricht: ersetzt man die paar Vorkommnisse von „vmail“, durch „mail“, funktioniert es auch.

Vorschläge:

1.  Den Hinweistext anpassen, so daß man weiß, daß man die IDs einfach übernehmen kann, beziehungsweise diese später angelegt werden und daß Froxlor dann erwartet, daß die vmail heißen.
2. Wenn jemand eigene angibt, bei der Existenz-Prüfung nicht nur entscheiden, daß das Anlegen unterbleiben kann, sondern auch die bestehenden Namen übernehmen, sofern sie von vmail abweichen.
3. Gegebenenfalls die Paketverwaltung benutzen, um erwartete System-Gruppen und Benutzer anzulegen.

Die Vorschläge sind teilweise als Alternativen gedacht, das heißt: 1. wäre sozusagen das Mindestmaß ohne wesentlichen Aufwand, um versehentliche Irreführung zu verhindern, nur eine Formulierungsfrage. 2. könnte parallel umgesetzt werden und wäre eine signifikante Verbesserung, die verhindern würde, daß Benutzer „sich ins Knie schießen“. 3. wäre hingegen eher eine Alternative zu den vorgenannten, denn eine Ergänzung, sollte man sich auf den Weg zur „Vollautomatisierung“ begeben wollen, so wie das beispielsweise bei Plesk gemacht wird.

Mir ist klar, daß 3. Aufwand ist, den man eigentlich ganz gerne vermeiden möchte, weil das jeweils je nach Distribution/Plattform unterschiedlich zu handhaben wäre, zumindest zwischen RPM und APT wäre zu unterscheiden – das tut man aber bei der Konfiguration eh schon, um die Befehle zum Kopieren fertig vorgeben zu können.

Zurück zur „Vollautomatisierung“: Plesk hatte ich nicht von ungefähr erwähnt, neben dem Preis war es vor allem die Intransparenz, die mich stets gestört hatte.

Insofern ist es schon mal kein schlechter Ansatz, den installierenden Administratoren auch anzuzeigen, was im Hintergrund abläuft – inwieweit man das dann „durchautomatisieren“ sollte, bin ich mir auch nicht sicher – wenn alles „von selber geht“, ist so gut wie sicher, daß die Mehrheit das alles nicht einmal mehr liest.

Indes sollte man schon überlegen, wo Froxlor „hinführen“ soll – der Status Quo kommt mir vor, als müsse man einerseits Experte für unixartige Betriebssysteme sein, andererseits aber auch für Froxlor selbst, um es erfolgreich anzuwenden. Weiß man beispielsweise „zu viel“ über Linux und zu wenig über Froxlor, wird sich das rächen, weil Anpassungen an den Einstellungen eben nicht unbedingt (nur) bewirken, was man erwartet – die sind eben schon ein Stück zu weit „wegabstrahiert“ von den Konfigurationsdateien: man weiß nicht genau, in welche Datei(en) eine Einstellungsoption einfließt.

Mir ist klar, daß ein solches Programm die Konfigurationsfreiheit einschränkt, dafür muß es dann aber Erleichterungen bringen; im Moment scheint es eine Tendenz zu geben, daß wer es erfolgreich einsetzen kann, es im Grunde nicht bräuchte. Anziehen tut man so doch eher die Klientel, die definitiv zu wenig weiß und glaubt, die „Ahnung von Linux“ durch ein „Panel“ ersetzen zu können.

Gerade weiß ich nicht so genau, wie ich das ausdrücken soll, worauf ich im Kern hinauswill, fällt mir bestimmt die Tage noch ein…

Als Beispiel nehme ich mal was, was alle kennen dürften und vordergründig nichts mit Froxlor zu tun hat: es gibt unzählige kleine Windows-Progrämmchen, wo sich der Programmierer „mal eben“ mit Installshield ein Installationsprogramm „zusammengeklickt“ hat. Alles schön auf den Voreinstellungen belassen, als erstes darf man also vorgeblich den Pfad aussuchen, wohin man es installiert haben möchte – aber WEHE, man ändert die Vorgabe: im eigentlichen Programm ist „C:\Program Files\whatever“ hartcodiert.

Sowas krasses habe ich bei Froxlor nicht entdeckt, aber der vorliegende „Vmail-Fall“ hat etwas von dieser Problematik:

Man kann die IDs von 2000 auf andere ändern, ABER:

1. Es funktioniert, wenn noch kein(e) Benutzer/Gruppe „vmail“ existiert und man freie IDs auswählt.
2. Es funktioniert, wenn „vmail“ existiert, genau dann, wenn man  deren ID(s) eingibt. Das kann man aber kaum wissen.
3. In allen anderen Fällen gibt es Bruch, insbesondere auch, wenn 2000 bereits von was anderem als vmail belegt wird und der installierende Administrator die Vorgaben einfach so läßt, wie sie sind, was ja stets empfohlen wird.

Man kann mir da jetzt mit Wahrscheinlichkeiten bei frisch installierten Servern mit den üblichen Distributionen kommen: genau! Das ist der einzige Grund, warum das nicht DAUERND auf die Nase fällt.

Noch was zum Hintergrund: das soll kein Rundumschlag gegen Froxlor sein; ich würde mir kaum die Mühe machen, so viel zu schreiben, würde es mir nicht im Grunde auf den ersten Blick recht gut gefallen. Zum besseren Verständnis, aus welchem Blickwinkel ich das ganze betrachte: früher hatte ich jahrelang als Administrator „im Hintergrund“ für so einen „Mini-Hoster“ gearbeitet, einen „Windows-Menschen“, der sich im „Tagesgeschäft“ durch Plesk geklickt hat; den „Unterbau“ habe ich am Laufen gehalten und die Oberfläche möglichst nicht angefaßt. Nun setze ich einen Server für's Familienunternehmen auf und habe an sowas wie Froxlor gedacht, um simple Sachen delegieren zu können: die Mailadresse neuzugang@firma anlegen könnten die Halbwissenden dann auch selber.

Viele Grüße, Christoph