Hans-Dietrich Kirmse schrieb: > Hallo Holger, Hi Hans-Dietrich. > > zuersteinmal herzlichen Dank für deine Antwort. Kein Problem. >> Naja, es kommt auf Deine Konfiguration an. Wenn Du lokale Nutzer, also >> User mit Shellzugriff hast, brauchst Du nicht zwingend virtuelles >> Mapping. > > Es geht um einen Schulserver. Jeder Schüler hat einen Account (bei mir > ca. 400 Schüler). In den meisten Fällen aber keinen Shellaccount, weil > die Clients üblicherweise Windows-Clients sind. > >> Ich habe allerdings User, die nur für Services wie Mail oder >> SVN freigegeben sind und nicht als User auf dem eigentlichen Server >> existieren. Ergo brauch ich virtuelles Mapping. > > Solche User gibt es bei uns nicht. Wenn ich dich recht verstehe, brauche > ich da virtuelles Mapping nicht und es sollte damit eigentlich einfacher > zu konfigurieren sein - richtig? Das schöne an Postfix ist, das Du selbst bestimmst was welchen "Datentresor" benutzt. Du kannst also für Mailaliase Hash-Tabellen nehmen und für die virtuellen Domains (wenn Du mehr als eine Domain auf deinem Mailserver benutzt) sowohl über eine Hash-Tabelle also auch gegen ein LDAP. >>>> query_filter = >>>> (&(|(mail=%s)(mailAlternateAddress=%s))(|(AccountStatus=active)(accountStatus=shared))) >>>> >>>> >>>> result_attribute = mailMessageStore >>> Dazu die Frage, wo kommen die Attribute her bzw. wie bekomme ich die in >>> meinen LDAP? Postfix stellt ja prinzipiell kein Schema bereit. Aber >>> angenommen es gibt irgendwo ein Schema, dann weiss ich auch nicht, wie >>> ich das den smbldap-Tools unterjubeln könnte. >> Postfix benötigt auch kein Schema. Für die Mail-spezifischen >> Erweiterungen nutze ich das qmail.schema. Die Jungs von Goggel helfen >> Dir da beim Finden... > > dann hast du aber doch wegen Postfix ein Schema eingesetzt, eben das > qmail-schema. Nur: derzeit werden bei mir die Accounts unter Nutzung der > smbldap-Tools angelegt. Ich habe keine Stelle gefunden, wie ich diesen > Tools begreiflich mache, ein anderes Schema zu verwenden. Es sieht > bei mir eigentlich dann immer so aus: > > dn: uid=ffeuerstein,ou=people,ou=accounts,dc=delixs-schule,dc=de > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetOrgPerson > objectClass: posixAccount > objectClass: shadowAccount > objectClass: sambaSamAccount > uid: ffeuerstein > cn: Fred Feuerstein > sn: Feuerstein > givenName: Fred > uidNumber: 1234 > gidNumber: 1001 > homeDirectory: /home/teacher/ffeuerstein > loginShell: /bin/bash > gecos: Fred Feuerstein,TEACHER > > [...] > > mir stehen also die Attribute zur Verfügung, die durch diese 7 Objekt- > klassen definiert werden. Oder ich müßte auf diese Tools verzichten und > die Accounts irgendwie anders anlegen. Wie legst du die User an? Nun, Du könntest einfach das qmail Schema für die User zusätzlich definieren. Sollte sich nicht beissen. Ist ja durchaus eine gängige Konfiguration, das User sowohl SMB als auch Mail Accounts haben ;) Unabhängig davon: Das inetOrgPerson Schema definiert ja bereits das Attribut 'mail'. Dort kannst Du die entsprechende Mail ja eintragen und das "Problem" wäre schon erschlagen. > >>> nächste Frage: kann man auch ohne 'mailAlternateAddress','AccountStatus' >>> und 'mailMessageStore' auskommen? Ohne LDAP gibt es die doch auch nicht. >>> (Was gibt 'mailMessageStore' eigentlich an?) >> Klar, wenn Du andere Attribute hast, die beschreiben, welche >> Mailadressen ein User hat, > > ja: die Mailadresse ist <login>@<schuldomain>. Wäre hier bei diesem > Beispiel "ffeuerstein@delixs-schule.de". Die Schuldomain ist eh schon > hinterlegt und das Login ist ja durch das Attribut 'uid' immer gegeben. s.o. > In der Objektklasse 'inetOrgPerson' wird (als MAY) das Attribut 'mail' > angegeben. Habe zwar nicht herausgefunden, wo das definiert wird ( :( ), Schau Dir mal die Domain http://ldap.akbkhome.com/ an. Ist ein sehr nettes Verzeichnis von LDAP Specs wie Object Classes und Attributen. Dort bekommst auch die Vererbungen raus (wird teilweise direkt referenziert). > aber ich weiss, dass es ein multivalue-Attribut ist. Deshalb wäre das > aus meiner Sicht doch ein brauchbarer Container für Mailaliasse und > dadurch meine Hoffnung, dass ich mit dem vorhandenen Schemas auskommen > könnte. Wie gesagt, ich will nichts weiter, als (wenn möglich) ohne > großen Aufwand Postfix an den vorhandenen LDAP anbinden. Das ist dann ja auch super. Dann kannst Du den Postfix anweisen die Mails entsprechend der mail-Attributwerte des gerade authentifizierten Users zu prüfen. > >> und wo seine Mails auf der Platte gespeichert werden. > > die werden im Homeverzeichnis gespeichert. das wird doch auch in der > Konfiguration von Postfix hinterlegt und muss m.E. deswegen nicht extra > in den LDAP - oder sehe ich das falsch? Dann kannst Du ja auch das Homeverzeichnis vom Postfix aus dem LDAP abfragen lassen ;) Ist dann halt kein zusätzliches Verzeichnis wie bei mir. >> Die >> müsstest dann eben entsprechend Deines Schemas / Deiner Struktur >> anpassen. > > Und genau hier ist ein weiteres Problem. so wie ich das bis jetzt sehe, > sollte die vorhandene Struktur für meine Anforderungen ausreichen, > sodass ich kein neues/weiteres Schema brauche. die Literatur bzw. > Anleitungen die ich bis jetzt gefunden habe oder kenne gehen aber immer > von einen eigenen Schema aus und konfigurieren dann Postfix > entsprechend. Und bis jetzt immer mit virtuellen Mapping usw. Damit > werden natürlich gleich alle Anforderungen erschlagen, aber für einen > Anfänger und (unbezahlten) Hobbyadmin ist das m.E. wenig hilfreich. Naja gut, die Dinge kannst ja dann weg lassen. Es gibt leider selten Tutorials die 100%-ig auf den eigenen Use-Case zutreffen. >>> Achja, die Mailadresse soll sich einfach aus dem Login, also dem >>> Attribut 'uid' (mit angehängter Domain) ergeben und für die Mailaliasse >>> würde ich (wenn möglich) einfach das mail-Attribut nehmen. Das ist ja >>> ein multivalue-Attribut. Wäre das denkbar? >> Wie Du UIDs vergibst kannst Du ohne Probleme selber bestimmen. Wenn Du >> es eben so definierst musst Du nur entsprechend die Postfix >> Konfiguration anpassen. > > genau um letzteres geht es mir ja. ;) Gut, werden wir doch mal n bisschen genauer: Was genau soll aus dem LDAP denn kommen? So long, Holger
Attachment:
signature.asc
Description: OpenPGP digital signature