Hallo allerseits, irgendwie macht mich das mit dem SASL wahnsinnig... ;) Ich begreife einfach nicht, ob da ein Fehler drinsteckt, oder ob ich nur die Materie nicht löffle. Zum Problem: - SuSE 8.2 - Cyrus IMAPd - saslauthd ist installiert (scheinbar standardmäßig) beides gestartet Nun ist es ja so, dass in der /etc/imapd.conf als Authmechanismus sasl_pwcheck_method: saslauthd eingetragen ist, er also nach allem Dafürhalten auf den saslauthd zurückgreifen sollte. SASL wiederum ist ja, wenn ich das richtig verstanden habe, nur eine Abstraktionsschicht, um vereinfacht Plaintext- Benutzerauthentifizierung durchführen zu können, ohne sich um die dahinterstehende Art der Benutzerdatenbank Gedanken machen zu müssen. Allerdings klappt da entweder was nicht, oder ich hab den letzten notwendigen Zwischenschritt nicht verstanden, der notwenig ist, um dem Cyrus IMAPd über den Umweg des saslauthd, der wiederum via PAM in welche Benutzerdatenbank auch immer hineinschauen soll, klarzumachen, wie und als wer ich mich jetzt zu authentifizieren gedenke. Beispiel: Ich möchte mich gern als Benutzer cyrus mittels cyradm anmelden, um Mailboxen anzulegen. Der Benutzer cyrus existiert zwar im System, aber ist gelockt. Weitere Benutzer namens cyrus habe ich noch nirgendwo angelegt, speziell mit saslpasswd2 nicht, da ich erstmal verstehen will, inwiefern denn da der saslauthd ins Spiel kommt, bzw. wofür der überhaupt benötigt wird. asterix:~ # cyradm --user cyrus asterix.chdintern.de dann wartet cyradm hier scheinbar auf ein Passwort, also tipp ich mal irgendwas hin. Im Logfile taucht Folgendes auf: Sep 29 23:15:31 asterix master[9273]: about to exec /usr/lib/cyrus/bin/imapd Sep 29 23:15:31 asterix imap[9273]: executed Sep 29 23:15:31 asterix imapd[9273]: accepted connection Sep 29 23:15:31 asterix imapd[9273]: OTP unavailable because can't read/write key database /etc/opiekeys: No such file or directory Sep 29 23:15:31 asterix imapd[9273]: DIGEST-MD5 server step 1 Sep 29 23:15:31 asterix perl: DIGEST-MD5 client step 2 Sep 29 23:16:36 asterix imapd[9273]: unable to open Berkeley db /etc/sasldb2: No such file or directory Sep 29 23:16:36 asterix imapd[9273]: unable to open Berkeley db /etc/sasldb2: No such file or directory Sep 29 23:16:36 asterix imapd[9273]: no secret in database Sep 29 23:16:36 asterix imapd[9273]: badlogin: asterix.chdintern.de[192.168.100.251] DIGEST-MD5 [SASL(-13): user not found: no secret in database] Sep 29 23:16:39 asterix perl: No worthy mechs found Warum versucht der denn hier, auf die sasldb zuzugreifen, obwohl in der imapd.conf eindeutig was von saslauthd steht? Wenn ich in die sasldb einen Benutzer namens cyrus eintrage, klappt es wunderbar, aber wozu brauch ich dann den saslauthd? Also versuch ich es anders: asterix:~ # cyradm --user cyrus --auth saslauthd asterix.chdintern.de Das erzeugt sofort die Meldung cyradm: cannot authenticate to server with saslauthd as cyrus und im Logfile steht Folgendes: Sep 29 23:20:27 asterix imapd[9275]: accepted connection Sep 29 23:20:27 asterix imapd[9275]: OTP unavailable because can't read/write key database /etc/opiekeys: No such file or directory Sep 29 23:20:27 asterix perl: No worthy mechs found Meine Frage ist ganz einfach: was hab ich hier nicht geschnallt? Wozu ist der saslauthd da, wenn er nicht benutzt wird, bzw. wenn er benutzt wird (wonach es nicht aussieht, denn ich bekomme von selbigem keine einzige Zeile im Logfile, obwohl ich ihn sicherheitshalber mal mit der Option -d [Debugmodus] gestartet habe), wo müsste ich dann die Benutzer anlegen? Ratlose Grüße, verbunden mit einem schuldbewussten Sorry für die Megamail, Hannes -- Heutzutage ist Resignation schon ein viel zu grosses persönliches Engagement. (unbekannter Autor)
* Andreas Winkelmann <ml@awinkelmann.de> [2003-09-30 07:55]:
Johannes Studt wrote:
asterix:~ # cyradm --user cyrus --auth saslauthd asterix.chdintern.de
# cyradm --user cyrus --auth login localhost
Hhmm... das geht erstmal, klar. Aber sage ich dem IMAPd damit nicht nur, dass er bitteschön nicht saslauthd oder sonst irgendwas, sondern login als Authmechanismus benutzen soll? Und ausserdem: was nutzt es mir, wenn ich den Authmechanismus angeben muss? Mit dem MUA kann ich das schliesslich auch nicht machen, da muss es einfach funktionieren. Wenn ich die Option --auth aber weglasse, versucht IMAPd mich steif und fest gegen die sasldb zu authentifizieren. Warum? Wenn man Pferd mal andersherum aufzäumt, nämlich von der Seite, was ich eigentlich erreichen will, kann mir dann einer erklären, was ich tun muss, um es umzusetzen? Ich möchte gern erreichen, dass mehrere Benutzer auf diesem Server Mailboxen haben können, und zwar teils Benutzer, die auch eine Loginshell haben, und andere, die nur Emailpostfächer haben sollen. Daher sähe ich es gern, wenn die Authentifizierung erst gegen die normale Logindatenbank durchgeführt wird, und nur, wenn der Benutzer dort nicht existiert, in der sasldb nachgeschaut wird. Utopie? Nicht viel schlauere Grüße als gestern, ;) Hannes -- E-mail Disclaimer: Sollten Sie diese E-mail irrtuemlich erhalten haben, machen Sie doch damit, was Sie fuer richtig halten, bitte jedoch im Rahmen dessen, was der gesunde Menschenverstand Ihnen vorschreibt. (found on http://www.causse.de/recht/angstklauseln.html)
Johannes Studt wrote:
asterix:~ # cyradm --user cyrus --auth saslauthd asterix.chdintern.de
# cyradm --user cyrus --auth login localhost
Hhmm... das geht erstmal, klar. Aber sage ich dem IMAPd damit nicht nur, dass er bitteschön nicht saslauthd oder sonst irgendwas, sondern login als Authmechanismus benutzen soll? Und ausserdem: was nutzt es mir, wenn
saslauthd ist kein Authentifizierungsmechanismus. Dazu gehören PLAIN, LOGIN, CRAM-MD5, DIGEST-MD5, KERBEROS...
ich den Authmechanismus angeben muss? Mit dem MUA kann ich das schliesslich auch nicht machen, da muss es einfach funktionieren. Wenn
MUA und dieser cyradm sind zwei verschiedene Dinge. Der MUA baut eine Verbindung zum Server auf und bekommt dann vom Server mitgeteilt, was der alles so an Authentifizierungsmechanismen kann. Dort sucht sich der Client dann das passende raus. Dieser cyradm ist wirklich nicht klasse, nimm das Ding zum konfigurieren und zu mehr auch nicht.
ich die Option --auth aber weglasse, versucht IMAPd mich steif und fest gegen die sasldb zu authentifizieren. Warum?
Weil er sich dann wahrscheinlich "bessere" Authetifizierungsmechanismen raussucht, die aber nicht über saslauthd funktionieren. Deshalb versucht er dann die auxprop-plugins durch, wozu auch die sasldb gehört.
Wenn man Pferd mal andersherum aufzäumt, nämlich von der Seite, was ich eigentlich erreichen will, kann mir dann einer erklären, was ich tun muss, um es umzusetzen? Ich möchte gern erreichen, dass mehrere Benutzer auf diesem Server Mailboxen haben können, und zwar teils Benutzer, die auch eine Loginshell haben, und andere, die nur Emailpostfächer haben sollen. Daher sähe ich es gern, wenn die Authentifizierung erst gegen die normale Logindatenbank durchgeführt wird, und nur, wenn der Benutzer dort nicht existiert, in der sasldb nachgeschaut wird. Utopie?
Prinzipiell ginge das so: /etc/imapd.conf: sasl_pwcheck_method: saslauthd auxprop sasl_auxprop_plugin: sasldb sasl_mech_list: plain login Dabei gibt es aber ein bis zwei Wermutstropfen, saslauthd kann nur plain und login, deswegen musst Du sasldb ebenfalls beschneiden. Und ich weiss nicht wie er auf die realms reagiert, das müsstest Du mal ausprobieren. Die Konfiguration bietet es an, dass heisst aber nicht dass es auch funktioniert. Aus dem Bauch heraus würde ich Dir dann doch lieber direkt die sasldb empfehlen. -- Andreas
Hallo Andreas, vorweg erstmal ein Dankeschön, dass Du Dir die Zeit nimmst, meine Fragen derart ausführlich zu beantworten, das finde ich äußerst nett. :) * Andreas Winkelmann <ml@awinkelmann.de> [2003-09-30 13:16]:
MUA und dieser cyradm sind zwei verschiedene Dinge.
Zum Glück. ;)
Der MUA baut eine Verbindung zum Server auf und bekommt dann vom Server mitgeteilt, was der alles so an Authentifizierungsmechanismen kann. Dort sucht sich der Client dann das passende raus.
Und cyradm baut seine Verbindung zum Server anders auf als ein MUA? Oder warum benötigt der die Mechanismenansage?
Weil er sich dann wahrscheinlich "bessere" Authetifizierungsmechanismen raussucht, die aber nicht über saslauthd funktionieren. Deshalb versucht er dann die auxprop-plugins durch, wozu auch die sasldb gehört.
Aber woher nimmt er sich das Recht, dieses zu tun und mich zu verwirren? ;) Davon steht nämlich nix in der imapd.conf. Und vor allem: wenn er damit auf die Nase fällt, warum macht er es dann nicht so, wie es ihm in der imapd.conf vorgeschrieben wurde, nämlich mittels den über den saslauthd zur Verfügung stehenden Mechanismen? Mich beschleicht irgendwie das Gefühl, dass da ein paar Sachen nebeneinander herentwickelt wurden und nix so recht aufeinander abgestimmt ist. Ich habe nämlich auch im Internet bei meiner Suche nicht wirklich viel dazu gefunden, was erklärt, /warum/ etwas /wie/ funktioniert, sondern immer nur einige kurze Anweisungen, wie man es konfigurieren kann, /dass/ es funktioniert. Mit den bei SuSE 8.0 beiliegenden Versionen von Cyrus IMAP und SASL hab ich es auch ans Funktionieren bekommen, nur weiß ich eben gar nicht so recht, /warum/ es funktioniert, und das stört mich ein wenig... Auf dem SuSE 8.0-System steht in der /etc/imapd.conf der Eintrag sasl_pwcheck_method: pam (das habe ich basierend auf einem Tip aus der Liste hier reingeschrieben) und nun werden dort seit Jahr und Tag die Clients entweder gegen die Logindatenbank oder gegen die sasldb authentifiziert, und zwar abhängig vom Client, und ich verstehe nicht, wieso. ;) Squirrelmail, welches direkt auf dem Rechner läuft, authentifiziert gegen die Logindatenbank, und wenn ich mit mutt von einem anderen Client aus eine Verbindung zu dem IMAP-Server aufbaue, wird dieser Versuch gegen die sasldb geprüft (ich merke das nur daher, weil die Passwörter der gleichen Benutzer in den Benutzerdatenbanken unterschiedlich sind). Mir fehlt hier einfach der eine Zwischenschritt, der mir klarmacht, anhand welcher Kriterien sich der IMAP-Server für die Benutzerdatenbank entscheidet. Ist sicher alles ganz einfach, und sobald ich das Brett vor meinem Kopf zerbissen habe, kann ich bestimmt selbst drüber lachen, aber momentan verzweifle ich echt daran... ;)
/etc/imapd.conf: sasl_pwcheck_method: saslauthd auxprop sasl_auxprop_plugin: sasldb sasl_mech_list: plain login
Dabei gibt es aber ein bis zwei Wermutstropfen, saslauthd kann nur plain und login, deswegen musst Du sasldb ebenfalls beschneiden. Und ich weiss nicht wie er auf die realms reagiert, das müsstest Du mal ausprobieren.
Werde ich machen, wenn ich die einfachen Zusammenhänge begriffen habe, danke. :)
Die Konfiguration bietet es an, dass heisst aber nicht dass es auch funktioniert.
Aus dem Bauch heraus würde ich Dir dann doch lieber direkt die sasldb empfehlen.
Also in die /etc/imapd.conf sasl_pwcheck_method: auxprop sasl_auxprop_plugin: sasldb und den saslauthd disablen? Oder noch ganz anders? Versteh mein hartnäckiges Nachfragen bitte nicht falsch, ich suche hier parallel dazu auch kräftig im Internet nach Antworten. Mir geht es nicht allein darum, das /irgendwie/ ans Rennen zu bekommen (das ginge bestimmt recht schnell), sondern vor allem auch darum, es zu /verstehen/. Wenn Du keine Lust oder Möglichkeit hast, mir ohne fehlenden dringenden Anlass jede Menge Zeit zu opfern, könnte ich das gut verstehen, Du musst es nur sagen und ich lass Dich mit meiner Fragerei in Ruhe. ;-) Allerdings wäre das schade, denn ich vermute fast, dass sich mit diesem Thema kaum einer ausser Dir richtig gut auskennt, sonst wäre ich hier sicherlich mit Hinweisen und Ratschlägen zugeschüttet worden wie fast alle anderen Hilfesuchenden hier... Gruß, Hannes -- Der Horizont vieler Menschen ist ein Kreis mit Radius Null - und das nennen sie ihren Standpunkt. (Albert Einstein)
Johannes Studt wrote:
vorweg erstmal ein Dankeschön, dass Du Dir die Zeit nimmst, meine Fragen derart ausführlich zu beantworten, das finde ich äußerst nett. :)
* Andreas Winkelmann <ml@awinkelmann.de> [2003-09-30 13:16]:
MUA und dieser cyradm sind zwei verschiedene Dinge.
Zum Glück. ;)
Der MUA baut eine Verbindung zum Server auf und bekommt dann vom Server mitgeteilt, was der alles so an Authentifizierungsmechanismen kann. Dort sucht sich der Client dann das passende raus.
Und cyradm baut seine Verbindung zum Server anders auf als ein MUA? Oder warum benötigt der die Mechanismenansage?
Weil er sich dann wahrscheinlich "bessere" Authetifizierungsmechanismen raussucht, die aber nicht über saslauthd funktionieren. Deshalb versucht er dann die auxprop-plugins durch, wozu auch die sasldb gehört.
Aber woher nimmt er sich das Recht, dieses zu tun und mich zu verwirren? ;) Davon steht nämlich nix in der imapd.conf. Und vor allem: wenn er damit auf die Nase fällt, warum macht er es dann nicht so, wie es ihm in der imapd.conf vorgeschrieben wurde, nämlich mittels den über den saslauthd zur Verfügung stehenden Mechanismen?
Mich beschleicht irgendwie das Gefühl, dass da ein paar Sachen nebeneinander herentwickelt wurden und nix so recht aufeinander abgestimmt ist. Ich habe nämlich auch im Internet bei meiner Suche nicht wirklich viel dazu gefunden, was erklärt, /warum/ etwas /wie/ funktioniert, sondern immer nur einige kurze Anweisungen, wie man es konfigurieren kann, /dass/ es funktioniert. Mit den bei SuSE 8.0
Na denn "Willkommen im Cyrus-Land". Die Produkte aus dem Hause Cyrus, mit denen ich mich bisher beschäftigt habe, haben eines gemeinsam. Die Dokumentationen sind einfach nur bescheiden. Aber der Spitzenreiter ist SASL, es gibt zwar eine Handvoll Dokus, die man sich zusammensuchen muss, aber je mehr man findet, desto größer werden eigentlich die Lücken dazwischen. Und es scheint sich auch in absehbarer Zeit nicht wirklich zu bessern. SASL kommt einem manchmal ein wenig wie ein Flickenteppich vor. Die einzige sinnvolle Dokumentation zu SASL ist der Sourcecode ;-)
beiliegenden Versionen von Cyrus IMAP und SASL hab ich es auch ans Funktionieren bekommen, nur weiß ich eben gar nicht so recht, /warum/ es funktioniert, und das stört mich ein wenig... Auf dem SuSE 8.0-System steht in der /etc/imapd.conf der Eintrag
sasl_pwcheck_method: pam
Das ist von SASL-V1, unter V2 wird pam über saslauthd gemacht.
(das habe ich basierend auf einem Tip aus der Liste hier reingeschrieben) und nun werden dort seit Jahr und Tag die Clients entweder gegen die Logindatenbank oder gegen die sasldb authentifiziert, und zwar abhängig vom Client, und ich verstehe nicht, wieso. ;) Squirrelmail, welches direkt auf dem Rechner läuft, authentifiziert gegen die Logindatenbank, und wenn ich mit mutt von einem anderen Client aus eine Verbindung zu dem IMAP-Server aufbaue, wird dieser Versuch gegen die sasldb geprüft (ich merke das nur daher, weil die Passwörter der gleichen Benutzer in den Benutzerdatenbanken unterschiedlich sind). Mir fehlt hier einfach der eine Zwischenschritt, der mir klarmacht, anhand welcher Kriterien sich der IMAP-Server für die Benutzerdatenbank entscheidet. Ist sicher alles ganz einfach, und sobald ich das Brett vor meinem Kopf zerbissen habe, kann ich bestimmt selbst drüber lachen, aber momentan verzweifle ich echt daran... ;)
Hmm, bei der Initialisierung von SASL wird das /lib/sasl[2]/ Verzeichnis nach auth-mechs durchsucht. Das sind dann die Libs wie libplain.*, liblogin.*, libcrammd5.*, libdigestmd5.*.... Dann werden die erwünschten mit der Konfigurationsoption "mech_list" herausgefiltert. Dann wird nochmal vom Server gefiltert z.B. Postfix oder auch IMAPd und das Resultat wird dem Client dann angeboten. Nehmen wir mal an es wird kein Filter benutzt, dann sieht der Client "CRAM-MD5 DIGEST-MD5 PLAIN LOGIN". Dann wählt er daraus die raus die er unterstüzt, OutlookExpress z.B. kann nur PLAIN/LOGIN und sagt dem Server mit welchem Mechanismus er sich authentifizieren möchte. Normalerweise wählt der Client dann die "Sicheren" raus z.B. "DIGEST-MD5". So und da kommt Dein Problem, saslauthd kann das nicht. Jetzt ignoriert SASL die Konfigoption "pwcheck_method: saslauthd" und versucht die Auxprop-Plugins. Dort liegt standardmässig halt libsasldb.* und er greift auf die sasldb zu. Dieses verhalten könntest Du dann mit "mech_list: plain login" schon im Vorfeld unterdrücken. Ich vermute mal das könnte Dein oben angesprochenes Phänomen erklären.
/etc/imapd.conf: sasl_pwcheck_method: saslauthd auxprop sasl_auxprop_plugin: sasldb sasl_mech_list: plain login
Dabei gibt es aber ein bis zwei Wermutstropfen, saslauthd kann nur plain und login, deswegen musst Du sasldb ebenfalls beschneiden. Und ich weiss nicht wie er auf die realms reagiert, das müsstest Du mal ausprobieren.
Werde ich machen, wenn ich die einfachen Zusammenhänge begriffen habe, danke. :)
Die Konfiguration bietet es an, dass heisst aber nicht dass es auch funktioniert.
Aus dem Bauch heraus würde ich Dir dann doch lieber direkt die sasldb empfehlen.
Also in die /etc/imapd.conf
sasl_pwcheck_method: auxprop sasl_auxprop_plugin: sasldb
und den saslauthd disablen? Oder noch ganz anders?
Nö, das wäre oki.
Versteh mein hartnäckiges Nachfragen bitte nicht falsch, ich suche hier parallel dazu auch kräftig im Internet nach Antworten. Mir geht es nicht allein darum, das /irgendwie/ ans Rennen zu bekommen (das ginge bestimmt recht schnell), sondern vor allem auch darum, es zu /verstehen/. Wenn Du keine Lust oder Möglichkeit hast, mir ohne fehlenden dringenden Anlass jede Menge Zeit zu opfern, könnte ich das gut verstehen, Du musst es nur sagen und ich lass Dich mit meiner Fragerei in Ruhe. ;-) Allerdings wäre das schade, denn ich vermute fast, dass sich mit diesem Thema kaum einer ausser Dir richtig gut auskennt, sonst wäre ich hier sicherlich mit Hinweisen und Ratschlägen zugeschüttet worden wie fast alle anderen Hilfesuchenden hier...
-- Andreas
* Andreas Winkelmann <ml@awinkelmann.de> [2003-09-30 16:24]:
Na denn "Willkommen im Cyrus-Land".
Die Produkte aus dem Hause Cyrus, mit denen ich mich bisher beschäftigt habe, haben eines gemeinsam. Die Dokumentationen sind einfach nur bescheiden. Aber der Spitzenreiter ist SASL, es gibt zwar eine Handvoll Dokus, die man sich zusammensuchen muss, aber je mehr man findet, desto größer werden eigentlich die Lücken dazwischen. Und es scheint sich auch in absehbarer Zeit nicht wirklich zu bessern. SASL kommt einem manchmal ein wenig wie ein Flickenteppich vor. Die einzige sinnvolle Dokumentation zu SASL ist der Sourcecode ;-)
Gut, ich hatte schon befürchtet, dass ich der Einzige bin, der da ins Rudern gerät. [...]
"Sicheren" raus z.B. "DIGEST-MD5". So und da kommt Dein Problem, saslauthd kann das nicht. Jetzt ignoriert SASL die Konfigoption "pwcheck_method: saslauthd" und versucht die Auxprop-Plugins. Dort liegt standardmässig halt libsasldb.* und er greift auf die sasldb zu. Dieses verhalten könntest Du dann mit "mech_list: plain login" schon im Vorfeld unterdrücken.
Ich vermute mal das könnte Dein oben angesprochenes Phänomen erklären.
Hhmm... aber auf der 8.0-Box gibt es keinen saslauthd.
Nö, das wäre oki.
Dann mach ich das erstmal so. Müssen sich die Leute eben im Zweifel zwei verschiedene Passwörter merken. Danke Dir soweit. :) Hannes -- E-mail Disclaimer: Sollten Sie diese E-mail irrtuemlich erhalten haben, machen Sie doch damit, was Sie fuer richtig halten, bitte jedoch im Rahmen dessen, was der gesunde Menschenverstand Ihnen vorschreibt. (found on http://www.causse.de/recht/angstklauseln.html)
* Andreas Winkelmann <ml@awinkelmann.de> [2003-09-30 16:24]:
Johannes Studt wrote:
Also in die /etc/imapd.conf
sasl_pwcheck_method: auxprop sasl_auxprop_plugin: sasldb
und den saslauthd disablen? Oder noch ganz anders?
Nö, das wäre oki.
So ok ist es dann doch auch wieder nicht, weil Postfix zu doof ist, die /etc/sasldb zu verstehen, und damit alle Emails an Empfänger, die zwar ein Postfach und einen korrespondierenden Eintrag in der sasldb haben, nicht zugestelt werden mit dem Hinweis, dass der Empfänger in dieser Domain nicht existiert. Da hilft es auch nicht, die /etc/sasldb zu den local_recipient_maps hinzuzufügen, da die sasldb zwar auch eine Berkeley-DB ist, aber Postfix damit nicht zurechtkommt. Also muss man wieder zwangsweise alle Benutzer auch als lokale Unix-Benutzer anlegen, und damit hab ich denselben Zustand wie auf der vorigen Box, den ich eigentlich vermeiden wollte. Ich seh schon, ich komme wohl nicht drumherum, das ganze mal mit einem Verzeichnis zu verknüppern. ;) Hannes --
Johannes Studt wrote:
So ok ist es dann doch auch wieder nicht, weil Postfix zu doof ist, die /etc/sasldb zu verstehen, und damit alle Emails an Empfänger, die zwar ein Postfach und einen korrespondierenden Eintrag in der sasldb haben, nicht zugestelt werden mit dem Hinweis, dass der Empfänger in dieser Domain nicht existiert. Da hilft es auch nicht, die /etc/sasldb zu den local_recipient_maps hinzuzufügen, da die sasldb zwar auch eine Berkeley-DB ist, aber Postfix damit nicht zurechtkommt. Also muss man
Darüber kann man sich ja wohl kaum beschweren.
wieder zwangsweise alle Benutzer auch als lokale Unix-Benutzer anlegen,
Wieso das denn? Eine Tabelle reicht vollkommen. Sie muss halt nur im richtigen Format sein.
und damit hab ich denselben Zustand wie auf der vorigen Box, den ich eigentlich vermeiden wollte. Ich seh schon, ich komme wohl nicht drumherum, das ganze mal mit einem Verzeichnis zu verknüppern. ;)
Dann nimm mysql oder ldap. -- Andreas
* Andreas Winkelmann <ml@awinkelmann.de> [2003-10-03 13:54]:
Johannes Studt wrote:
local_recipient_maps hinzuzufügen, da die sasldb zwar auch eine Berkeley-DB ist, aber Postfix damit nicht zurechtkommt. Also muss man Darüber kann man sich ja wohl kaum beschweren.
Jaja, so ernst war es ja nun auch wieder nicht gemeint mit dem "doof" ;) Aber schön wär es schon gewesen...
wieder zwangsweise alle Benutzer auch als lokale Unix-Benutzer anlegen, Wieso das denn? Eine Tabelle reicht vollkommen. Sie muss halt nur im richtigen Format sein.
Klar. Ich kann auch SASL mit der Unix-Benutzerdatenbank arbeiten lassen, das hatten wir ja weiter oben schon. Das hat aber auf meiner alten Box nicht wirklich richtig funktioniert, siehe dieser Thread weiter vorn.
drumherum, das ganze mal mit einem Verzeichnis zu verknüppern. ;) Dann nimm mysql oder ldap.
Genau das werde ich tun. Hast Du mit einem von beiden schon Erfahrungen gesammelt? Was ist einfacher umzusetzen? Sicherlich mysql, oder? Hannes -- Der Horizont vieler Menschen ist ein Kreis mit Radius Null - und das nennen sie ihren Standpunkt. (Albert Einstein)
Johannes Studt wrote:
wieder zwangsweise alle Benutzer auch als lokale Unix-Benutzer anlegen,
Wieso das denn? Eine Tabelle reicht vollkommen. Sie muss halt nur im richtigen Format sein.
Klar. Ich kann auch SASL mit der Unix-Benutzerdatenbank arbeiten lassen, das hatten wir ja weiter oben schon. Das hat aber auf meiner alten Box nicht wirklich richtig funktioniert, siehe dieser Thread weiter vorn.
Ich meinte nicht die Benutzer real anlegen, sondern nur eine einfach Tabelle mit den Benutzernamen.
drumherum, das ganze mal mit einem Verzeichnis zu verknüppern. ;)
Dann nimm mysql oder ldap.
Genau das werde ich tun. Hast Du mit einem von beiden schon Erfahrungen gesammelt? Was ist einfacher umzusetzen? Sicherlich mysql, oder?
Ich hatte mal mysql ausprobiert, lief auch. sasl-ldap will ich mir in den nächsten Tagen mal anschauen. mysql ist nicht so schwer zu konfigurieren, solange Du keine verschlüsselten Passwörter in der Datenbank haben möchtest. Allerdings musst Du sasl neu kompilieren, libmysql.* gibt es bei Suse nicht. LDAP ginge bei der Suse über saslauthd->pam_ldap->ldap, ist allerdings ein Krampf. Könnte aber gehen. Würde aber ein libldap.* machen, also auch neu kompilieren. -- Andreas
* Andreas Winkelmann <ml@awinkelmann.de> [2003-10-03 14:28]:
Johannes Studt wrote: Ich meinte nicht die Benutzer real anlegen, sondern nur eine einfach Tabelle mit den Benutzernamen.
Achso, klar, ja, Das könnte ich machen. Die Benutzer in der Unix-Benutzerdatenbank einzutragen hat ja auch den kleinen Vorteil, dass man ihnen als Loginshell saslpasswd2 geben kann, damit sie ihr Postfachpasswort ändern können.
Ich hatte mal mysql ausprobiert, lief auch. sasl-ldap will ich mir in den nächsten Tagen mal anschauen. mysql ist nicht so schwer zu konfigurieren, solange Du keine verschlüsselten Passwörter in der Datenbank haben möchtest. Allerdings musst Du sasl neu kompilieren, libmysql.* gibt es bei Suse nicht.
Aha.
LDAP ginge bei der Suse über saslauthd->pam_ldap->ldap, ist allerdings ein Krampf. Könnte aber gehen. Würde aber ein libldap.* machen, also auch neu kompilieren.
Ich sehe, Du kannst den saslauthd auch nicht leiden... ;-) Ich werde sicherlich das mit mysql mal angehen, spätestens dann, wenn ich die Nase voll habe davon, dass ich kein ordentliches Adressbuch habe und anfange, da mal eine Tabelle zusammenzubauen, die ich auch aus mutt heraus nutzen kann. Danke erstmal. mfg, Hannes -- Was den Menschen vom Tier unterscheidet, sind die Geldsorgen. (unbekannter Autor)
Johannes Studt wrote:
LDAP ginge bei der Suse über saslauthd->pam_ldap->ldap, ist allerdings ein Krampf. Könnte aber gehen. Würde aber ein libldap.* machen, also auch neu kompilieren.
Ich sehe, Du kannst den saslauthd auch nicht leiden... ;-)
Es geht so, habe da halt ein bis zwei Probleme mit. Eine Sache ist, dass die Passwörter unverschlüsselt über die Leitung gehen, das finde ich nicht so toll. Und bzgl. ldap, ist mir der Weg einfach zu weit. Wozu über zwei Instanzen zu gehen, wenn es auch direkt geht. Ist wohl auch etwas merh Arbeit zur Fehlersuche.
Ich werde sicherlich das mit mysql mal angehen, spätestens dann, wenn ich die Nase voll habe davon, dass ich kein ordentliches Adressbuch habe und anfange, da mal eine Tabelle zusammenzubauen, die ich auch aus mutt heraus nutzen kann.
Liest mutt Adressbücher aus einer mysql-db? Würde wohl eher ldap dafür nehmen. -- Andreas
* Andreas Winkelmann <ml@awinkelmann.de> [2003-10-03 15:00]:
über zwei Instanzen zu gehen, wenn es auch direkt geht. Ist wohl auch etwas merh Arbeit zur Fehlersuche.
Ja, das sicherlich.
Liest mutt Adressbücher aus einer mysql-db? Würde wohl eher ldap dafür nehmen.
Weiß nicht, aber ich empfinde LDAP auf einem System mit einigen wenigen Benutzern als deutlich überdimensioniert. Was allerdings dafür spräche, wäre der Lerneffekt. Mal sehen... Hannes -- Der Horizont vieler Menschen ist ein Kreis mit Radius Null - und das nennen sie ihren Standpunkt. (Albert Einstein)
Hallo Hannes,
Weiß nicht, aber ich empfinde LDAP auf einem System mit einigen wenigen Benutzern als deutlich überdimensioniert. Was allerdings dafür spräche, wäre der Lerneffekt. Mal sehen...
Ich habe gestern mal etwas mit ldap rumgespielt - uff, das war ein krampf. Muss mir erst mal die howtos richtig durchlesen - so ein globales adressbuch wäre echt nicht schlecht. würde mir vorerst reichen. gruss michael -- make it run, make it safe, make it fast
Michael Grundmann wrote:
Weiß nicht, aber ich empfinde LDAP auf einem System mit einigen wenigen Benutzern als deutlich überdimensioniert. Was allerdings dafür spräche, wäre der Lerneffekt. Mal sehen...
Ich habe gestern mal etwas mit ldap rumgespielt - uff, das war ein krampf. Muss mir erst mal die howtos richtig durchlesen - so ein globales adressbuch wäre echt nicht schlecht. würde mir vorerst reichen.
Jo, ist ganz nett. Es ist aber besser nicht allzuviel zu erwarten, bis Du es mal mit dem Mailer Deines Vertrauens gesehen bzw. ausprobiert hast. -- Andreas
Hall Andreas,
Ich hatte mal mysql ausprobiert, lief auch. sasl-ldap will ich mir in den nächsten Tagen mal anschauen. mysql ist nicht so schwer zu konfigurieren, solange Du keine verschlüsselten Passwörter in der Datenbank haben möchtest. Allerdings musst Du sasl neu kompilieren, libmysql.* gibt es bei Suse nicht.
LDAP ginge bei der Suse über saslauthd->pam_ldap->ldap, ist allerdings ein Krampf. Könnte aber gehen. Würde aber ein libldap.* machen, also auch neu kompilieren.
muss dafür nicht Postfix neu compiliert werden? gruss michael -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht widerstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach
Michael Grundmann wrote:
Hall Andreas,
Ich hatte mal mysql ausprobiert, lief auch. sasl-ldap will ich mir in den nächsten Tagen mal anschauen. mysql ist nicht so schwer zu konfigurieren, solange Du keine verschlüsselten Passwörter in der Datenbank haben möchtest. Allerdings musst Du sasl neu kompilieren, libmysql.* gibt es bei Suse nicht.
LDAP ginge bei der Suse über saslauthd->pam_ldap->ldap, ist allerdings ein Krampf. Könnte aber gehen. Würde aber ein libldap.* machen, also auch neu kompilieren.
muss dafür nicht Postfix neu compiliert werden?
Nö, sasl reicht. Sind ja Libraries. BTW, bitte stell in Deinem Mailer ein vernünftiges Quote-Zeichen ein, dachte schon ich hätte mich selbst was gefragt. -- Andreas
Am Samstag, 04.10.03, um 07:54 Uhr (Europe/Berlin) schrieb Andreas Winkelmann:
Michael Grundmann wrote:
Hall Andreas, Ich hatte mal mysql ausprobiert, lief auch. sasl-ldap will ich mir in den nächsten Tagen mal anschauen. mysql ist nicht so schwer zu konfigurieren, solange Du keine verschlüsselten Passwörter in der Datenbank haben möchtest. Allerdings musst Du sasl neu kompilieren, libmysql.* gibt es bei Suse nicht. LDAP ginge bei der Suse über saslauthd->pam_ldap->ldap, ist allerdings ein Krampf. Könnte aber gehen. Würde aber ein libldap.* machen, also auch neu kompilieren. muss dafür nicht Postfix neu compiliert werden?
Nö, sasl reicht. Sind ja Libraries.
ok - bevor ich hier wild das system ändere, erstmal ein paar fragen :) wenn ich sasl mit libmysql komipliere kann ich die accounts normal unter mysql eingeben und brauche die nicht lokal anlegen. gibt es hierzu fertige tabellen fuer mysql? irgendwelche vorschläge? gruss michael -- unix is just simple, but sometimes it takes some genius to understand the simplethy
Michael Grundmann wrote:
ok - bevor ich hier wild das system ändere, erstmal ein paar fragen :) wenn ich sasl mit libmysql komipliere kann ich die accounts normal unter mysql eingeben und brauche die nicht lokal anlegen.
Klar, sonst wäre das ja ganz grosser Unsinn ;-)
gibt es hierzu fertige tabellen fuer mysql? irgendwelche vorschläge?
So sieht meine aus: +--------------------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------------------+--------------+------+-----+---------+----------------+ | userid | int(11) | | PRI | NULL | auto_increment | | username | varchar(60) | | | | | | userrealm | varchar(60) | YES | | NULL | | | userPassword | varchar(60) | YES | | NULL | | userid brauchst Du eigentlich nicht, ist aber vielleicht besser so. Ausserdem habe ich keine realms benutzt. userPassword ist das unverschlüsselte Passwort, es gibt auch Möglichkeiten verschlüsselte einzusetzen, dann musst Du aber sasl patchen, weil die sasl-verschlüsselung nicht zum Rest vom System passt (Cyrus halt), da gibt es aber einen Patch, damit kann man sich sogar aussuchen, wie es verschlüsselt sein soll. So in etwa die smtpd.conf: pwcheck_method: auxprop auxprop_plugin: mysql mysql_user: username mysql_passwd: password mysql_hostnames: localhost mysql_database: sasldb mysql_statement: select userPassword from users where username = '%u' mysql_verbose: true Das Loging verhalten dieses Plugins ist ganz ok. Hatte es zwar noch etwas modifiziert bzw. aufgebohrt, war aber nur für diese Verschlüsselungs-Geschichte notwendig. -- Andreas
Am Samstag, 04.10.03, um 08:49 Uhr (Europe/Berlin) schrieb Andreas Winkelmann:
Michael Grundmann wrote:
ok - bevor ich hier wild das system ändere, erstmal ein paar fragen :) wenn ich sasl mit libmysql komipliere kann ich die accounts normal unter mysql eingeben und brauche die nicht lokal anlegen.
Klar, sonst wäre das ja ganz grosser Unsinn ;-)
Hallo Andreas, wenn wir hier über sasl sprechen, dann ist das doch cyrus-sasl und dieses wird mit saslauthd gestartet, oder? Die Frage ist auch, kann ich cyrus-imapd-2.1.12 verwenden und cyrus-sasl-2.1.15 zusammen verwenden, oder muss ich beide Packete neu installieren? Gruß Michael -- Aber warum willst Du den Rechner eigentlich herunterfahren? Linux- rechner bootet man nicht alle paar Tage, sondern alle paar Monate, wenn man einen neuen Kernel installiert hat oder neue Hardware integrieren will und dafür den Strom abstellen muß. --- Bernd Brodesser
Michael Grundmann wrote:
ok - bevor ich hier wild das system ändere, erstmal ein paar fragen :) wenn ich sasl mit libmysql komipliere kann ich die accounts normal unter mysql eingeben und brauche die nicht lokal anlegen.
Klar, sonst wäre das ja ganz grosser Unsinn ;-)
wenn wir hier über sasl sprechen, dann ist das doch cyrus-sasl und dieses wird mit saslauthd gestartet, oder?
Der saslauthd ist ein Bestandteil von dem Paket Cyrus-SASL (V2). "saslauthd" ist ein Daemon, der von den SASL-Libs benutzt wird. Auf diese wiederum wird von der Anwendung z.B. Postfix oder Cyrus-IMAPd zugegriffen.
Die Frage ist auch, kann ich cyrus-imapd-2.1.12 verwenden und cyrus-sasl-2.1.15 zusammen verwenden, oder muss ich beide Packete neu installieren?
cyrus-imapd und cyrus-sasl sind zwei getrennte Produkte. Wenn Du sie dynamisch kompilierst, was die Regel ist, dann kannst Du sie getrennt updaten. Wenn Du sie statisch kompilierst, dann sind die sasl-libs direkt in der Anwendung drin, dann müsstest Du alles neu kompilieren. Das ist aber sehr selten der Fall. -- Andreas
cyrus-imapd und cyrus-sasl sind zwei getrennte Produkte. Wenn Du sie dynamisch kompilierst, was die Regel ist, dann kannst Du sie getrennt updaten. Wenn Du sie statisch kompilierst, dann sind die sasl-libs direkt in der Anwendung drin, dann müsstest Du alles neu kompilieren. Das ist aber sehr selten der Fall.
Hallo Andreas, also kann ich auch einfach nur das entsprechende lib in das jeweilige Verzeichnis kopieren und es funktioniert???? Gruß Michael -- Linux macht Spass, weil es von intelligenten Menschen gemacht ist. [Ratti in suse-linux]
Michael Grundmann wrote:
cyrus-imapd und cyrus-sasl sind zwei getrennte Produkte. Wenn Du sie dynamisch kompilierst, was die Regel ist, dann kannst Du sie getrennt updaten. Wenn Du sie statisch kompilierst, dann sind die sasl-libs direkt in der Anwendung drin, dann müsstest Du alles neu kompilieren. Das ist aber sehr selten der Fall.
also kann ich auch einfach nur das entsprechende lib in das jeweilige Verzeichnis kopieren und es funktioniert????
Wenn Du sie vorher zu der SASL-Version passend erstellt hast, ja. Bei Suse ins /usr/lib/sasl2 Verzeichnis (Gehe mal davon aus Du meinst mysql). Und natürlich noch den Cache neumachen und Postfix neustarten. # ldconfig # rcpostfix restart -- Andreas
Am Montag, 29. September 2003 23:26 schrieb Johannes Studt:
Nun ist es ja so, dass in der /etc/imapd.conf als Authmechanismus
sasl_pwcheck_method: saslauthd sasl_mech_list: plain login
Das verhindert die Fehlermeldungen:
Sep 29 23:20:27 asterix imapd[9275]: OTP unavailable because can't read/write key database /etc/opiekeys: No such file or directory Sep 29 23:20:27 asterix perl: No worthy mechs found
asterix:~ # cyradm --user cyrus asterix.chdintern.de Das funktioniert mit Deiner SASL2-Implemantation so nicht mehr: cyradm -user cyrus -server localhost -auth login
Robert
* Hans-Robert Wagner <robert@hr-wagner.de> [2003-09-30 18:11]:
sasl_mech_list: plain login
Das verhindert die Fehlermeldungen:
Hhmm. Ich habe es mit der von Andreas Winkelmann aufgezeigten Holzhammermethode erledigt, weil ich OTPs sicher eh nie benötigen werde.
Das funktioniert mit Deiner SASL2-Implemantation so nicht mehr: cyradm -user cyrus -server localhost -auth login
Und warum? ;) Hannes -- Das Licht am Ende des Tunnels ist ein entgegenkommender Zug. (unbekannter Autor)
participants (4)
-
Andreas Winkelmann -
Hans-Robert Wagner -
Johannes Studt -
Michael Grundmann