Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste Überarbeitung Beide Seiten der Revision | ||
kb [2011/07/12 14:38] flacco |
kb [2012/01/06 14:09] flacco |
||
---|---|---|---|
Zeile 18: | Zeile 18: | ||
* Nach dem alten Schema beginnt jedes DNS-Objekt im LDAP mit dem Attribut "relativeDomainName", welches als Schlüssel-Attribut angesehen werden kann. Im DLZ-Schema nimmt das Attribut "dlzRecordID" diese Rolle ein. Eine Kennzeichnung des Objekts wird dabei erst über das Folge-Attribut erreicht: "dlzRecordID=05,dlzHostName=pc-buchhaltung,..." | * Nach dem alten Schema beginnt jedes DNS-Objekt im LDAP mit dem Attribut "relativeDomainName", welches als Schlüssel-Attribut angesehen werden kann. Im DLZ-Schema nimmt das Attribut "dlzRecordID" diese Rolle ein. Eine Kennzeichnung des Objekts wird dabei erst über das Folge-Attribut erreicht: "dlzRecordID=05,dlzHostName=pc-buchhaltung,..." | ||
* Während alle kennzeichnenden Informationen eines SOA-Records beim alten Schema im Attribut "sOARecord" zusammengefasst wurden, kennt das DLZ-Schema für jeden Wert ein eigenes Attribut: z.B. "dlzSerial", "dlzRefresh", usw. | * Während alle kennzeichnenden Informationen eines SOA-Records beim alten Schema im Attribut "sOARecord" zusammengefasst wurden, kennt das DLZ-Schema für jeden Wert ein eigenes Attribut: z.B. "dlzSerial", "dlzRefresh", usw. | ||
+ | * Die Daten der MX-Records sind beim DLZ-Schema nicht Teil des SOA-Eintrages, sondern werden als eigene LDAP-Objekte angelegt. | ||
* Das DLZ-Schema kennt weder Attribute noch Objektklassen für SRV-, mINFO, hINFO, SIG-, KEY-, sowie einige weitere DNS-Record-Typen. Diese können entweder über die Objektklasse "dlzGenericRecord" oder eigene Erweiterungen des Schemas realisiert werden. Für Letzteres ist mit "1.3.6.1.4.1.18420.1.3.X" im Schema ein eigener Object-Identifier (OID) vorgesehen. | * Das DLZ-Schema kennt weder Attribute noch Objektklassen für SRV-, mINFO, hINFO, SIG-, KEY-, sowie einige weitere DNS-Record-Typen. Diese können entweder über die Objektklasse "dlzGenericRecord" oder eigene Erweiterungen des Schemas realisiert werden. Für Letzteres ist mit "1.3.6.1.4.1.18420.1.3.X" im Schema ein eigener Object-Identifier (OID) vorgesehen. | ||
* Die meisten Attribute des DLZ-Schemas sind als Single-Values gekennzeichnet. D.H. gehören etwa zu einem Pointer-Record mehrere Hostnamen, können diese nicht in einem Objekt zusammengefasst werden, sondern es muss für jeden Hostnamen ein eigenes PTR-Objekt erzeugt werden. | * Die meisten Attribute des DLZ-Schemas sind als Single-Values gekennzeichnet. D.H. gehören etwa zu einem Pointer-Record mehrere Hostnamen, können diese nicht in einem Objekt zusammengefasst werden, sondern es muss für jeden Hostnamen ein eigenes PTR-Objekt erzeugt werden. | ||
Zeile 45: | Zeile 46: | ||
<code> | <code> | ||
- | dn: dlzRecordID=11,dlzHostName=@,dlzZoneName=invis-net.loc,ou=forward,ou=zone.master,ou=DNS-server,,dc=invis-net,dc=loc | + | dn: dlzRecordID=11,dlzHostName=@,dlzZoneName=invis-net.loc,ou=zone.master,ou=DNS-Server,dc=invis-net,dc=loc |
objectclass: dlzSOARecord | objectclass: dlzSOARecord | ||
dlzRecordID: 11 | dlzRecordID: 11 | ||
Zeile 57: | Zeile 58: | ||
dlzAdminEmail: root.invis-net.loc. | dlzAdminEmail: root.invis-net.loc. | ||
dlzPrimaryns: ns.invis-net.loc. | dlzPrimaryns: ns.invis-net.loc. | ||
+ | dlzTTL: 10 | ||
+ | </code> | ||
+ | |||
+ | <code> | ||
+ | dn: dlzRecordID=5,dlzHostName=@,dlzZoneName=invis-server.loc,ou=zone.master,ou=DNS-Server,dc=invis-server,dc=loc | ||
+ | objectclass: dlzMXRecord | ||
+ | dlzRecordID: 5 | ||
+ | dlzHostName: @ | ||
+ | dlzType: mx | ||
+ | dlzData: mail | ||
+ | dlzPreference: 10 | ||
dlzTTL: 10 | dlzTTL: 10 | ||
</code> | </code> | ||
Zeile 79: | Zeile 91: | ||
<code> | <code> | ||
- | dn: dlzRecordID=14,dlzHostName=invis5,dlzZoneName=invis-net.loc,ou=forward,ou=zone.master,ou=DNS-Server,dc=invis-net,dc=loc | + | dn: dlzRecordID=14,dlzHostName=invis5,dlzZoneName=invis-net.loc,ou=zone.master,ou=DNS-Server,dc=invis-net,dc=loc |
objectclass: dlzARecord | objectclass: dlzARecord | ||
dlzRecordID: 14 | dlzRecordID: 14 | ||
Zeile 108: | Zeile 120: | ||
* DLZ-Schema | * DLZ-Schema | ||
+ | <code> | ||
+ | dn: dlzHostName=10,dlzZoneName=220.168.192.in-addr.arpa,ou=zone.master,ou=DNS-Server,dc=invis-net,dc=loc | ||
+ | objectclass: dlzHost | ||
+ | dlzHostName: 10 | ||
+ | </code> | ||
+ | |||
+ | Die Begründung für diesen Eintrag finden Sie im nächsten Abschnitt. | ||
<code> | <code> | ||
- | dn: dlzRecordID=15,dlzHostName=10,dlzZoneName=220.168.192.in-addr.arpa,ou=reverse,ou=zone.master,ou=DNS-Server,dc=invis-net,dc=loc | + | dn: dlzRecordID=15,dlzHostName=10,dlzZoneName=220.168.192.in-addr.arpa,ou=zone.master,ou=DNS-Server,dc=invis-net,dc=loc |
objectclass: dlzPTRRecord | objectclass: dlzPTRRecord | ||
dlzRecordID: 15 | dlzRecordID: 15 | ||
Zeile 120: | Zeile 139: | ||
<code> | <code> | ||
- | dn: dlzRecordID=16,dlzHostName=10,dlzZoneName=220.168.192.in-addr.arpa,ou=reverse,ou=zone.master,ou=DNS-Server,dc=invis-net,dc=loc | + | dn: dlzRecordID=16,dlzHostName=10,dlzZoneName=220.168.192.in-addr.arpa,ou=zone.master,ou=DNS-Server,dc=invis-net,dc=loc |
objectclass: dlzPTRRecord | objectclass: dlzPTRRecord | ||
dlzRecordID: 16 | dlzRecordID: 16 | ||
Zeile 130: | Zeile 149: | ||
<code> | <code> | ||
- | dn: dlzRecordID=17,dlzHostName=10,dlzZoneName=220.168.192.in-addr.arpa,ou=reverse,ou=zone.master,ou=DNS-Server,dc=invis-net,dc=loc | + | dn: dlzRecordID=17,dlzHostName=10,dlzZoneName=220.168.192.in-addr.arpa,ou=zone.master,ou=DNS-Server,dc=invis-net,dc=loc |
objectclass: dlzPTRRecord | objectclass: dlzPTRRecord | ||
dlzRecordID: 15 | dlzRecordID: 15 | ||
Zeile 164: | Zeile 183: | ||
Letzteres eben im Falle mehrerer Records zu einem Host. | Letzteres eben im Falle mehrerer Records zu einem Host. | ||
+ | |||
+ | ==== Nameserver Konfiguration ==== | ||
+ | |||
+ | Grundsätzlich hat sich auch die Konfiguration des Nameservers bind in Sachen Zugriff auf das LDAP-Backend geändert. Statt getrennte Zonenkonfigurationen für Forward und Reverse Zonen gibt es nur noch einen Eintrag in der Datei named.conf. | ||
+ | |||
+ | <code> | ||
+ | ## LDAP Backend mit DLZ-Schema | ||
+ | dlz "ldap zone" { | ||
+ | database "ldap 2 | ||
+ | v3 simple {uid=Admin,ou=DNS-Server,dc=invis-server,dc=loc} {passwort} 127.0.0.1 | ||
+ | ldap:///dlzZoneName=$zone$,ou=zone.master,ou=DNS-Server,dc=invis-server,dc=loc???objectclass=dlzZone | ||
+ | ldap:///dlzHostName=$record$,dlzZoneName=$zone$,ou=zone.master,ou=DNS-Server,dc=invis-server,dc=loc?dlzTTL,dlzType,dlzPreference,dlzData,dlzIPAddr,dlzPrimaryNS,dlzAdminEmail,dlzSerial,dlzRefresh,dlzRetry,dlzExpire,dlzMinimum?sub?objectclass=dlzAbstractRecord"; | ||
+ | }; | ||
+ | </code> | ||
+ | |||
+ | Wichtig bei der Bearbeitung der Einträge ist, dass die einzelnen LDAP-URLs nicht umbrochen werden und keine Leerzeichnen enthalten dürfen. Die notwendigen Anpassungen dieses Eintrags auf die jeweilige Umgebung beschränken sich auf den Bind-DN, mit dem sich der Dienst am LDAP-Verzeichnis anmeldet und den DN, der Zonen in der ersten LDAP-URL. | ||
+ | |||
+ | Daneben ist ggf. noch die Möglichkeit von Interesse bind mit mehreren Threads gleichzeitig auf das LDAP-Verzeichnis zugreifen zu lassen. Dies ist vor allem bei hochfrequentierten Nameservern ein gutes Mittel die Performance des Nameservers zu steigern. In kleineren Umgebungen spielt die keine große Rolle. | ||
+ | |||
+ | Im Beispiel wurden zwei gleichzeitige Threads ermöglicht. Hierfür steht die Ziffer (2) am Beginn der Definition des Daten-Backends. Vorgegeben ist der Wert 1, da die Erhöhung nur dan funktioniert, wenn das zugrunde liegende System Multithreading-fähig ist. Bei modernen Linux-Systemen ist dies in der Regel der Fall. | ||
+ | |||
+ | ===== Postfix, Amavis & Dovecot ===== | ||
+ | |||
+ | Da wir uns über kurz oder lang möglichst wieder von Cyrus-IMAP verabschieden wollen kümmern wir uns derzeit intensiv um das reibungslose Zusammenspiel von Postfix, Amavis und Dovecot. Ziel des Setups ist es: | ||
+ | |||
+ | * Dovecot als SASL-Authentifizierungsbackend für Postfix zu nutzen. | ||
+ | * Dovecots Deliver als MDA einzusetzen. | ||
+ | * IMAP-ACLs zu ermöglichen. | ||
+ | * Amavis als content_filter zu nutzen. | ||
+ | |||
+ | Die genannten Anforderungen ergeben ein recht komplexes Setup, daher widme ich mich hier den Hintergründen. Zunächst allerdings nur dem Teil der Einlieferung neuer Mails via //**fetchmail**//. | ||
+ | |||
+ | Größte Schwierigkeit hierbei ist ein sauberes Mailrouting durch alle Komponenten. Dies beginnt bereits beim Fetchmail-Daemon. Zunächst ein schematischer Überblick über die Wege einer eingehenden Email: | ||
+ | |||
+ | |||
+ | ==== fetchmail ==== | ||
+ | |||
+ | In der Grundkonfiguration hat der fetchmail-Daemon auf openSUSE Systemen die unangenehme Eigenschaft eingehende Emails an Adressen des Schemas "user@//**localhost**//.domain.tld", statt an "user@domain.tld" weiterzuleiten. Dies kann das gesamte Verhalten der nachfolgenden Komponenten beeinflussen. Leider nicht zum Guten. | ||
+ | |||
+ | Dies kann auf zweierlei Wegen behoben werden. Entweder wird in der genutzten "fetchmailrc" Datei die korrekte Adresse des lokalen Empfängers eingetragen oder //**fetchmail**// wird mit der Option "-D domain.tld" aufgerufen. | ||
+ | |||
+ | Letzteres kann auf openSUSE Systemen in <file>/etc/sysconfig/fetchmail</file> bzw. auf invis-Servern in <file>/var/cornaz/sysconfig/fetchmail</file> konfiguriert werden: | ||
+ | |||
+ | <code> | ||
+ | ## Type: string | ||
+ | ## Default: "" | ||
+ | # | ||
+ | # Any additional fetchmail options. See fetchmail(1) manual page for | ||
+ | # more information. If you want to use --mda option, it may be required | ||
+ | # to change FETCHMAIL_USER to root. Consult your MDA documentation for | ||
+ | # more. | ||
+ | # | ||
+ | FETCHMAIL_EXPERT_OPTIONS="-D invis-net.loc" | ||
+ | </code> | ||
+ | |||
+ | Eingetragen werden muss an dieser Stelle die lokale Domain des Servers. | ||
+ |