Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- kb [2011/07/12 14:18]
flacco
+++ kb [2012/01/06 14:16]
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,..."
   * 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.
+  * 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.
 ==== Aufbau der LDAP-Objekte ====
@@ Zeile 44: / Zeile 46: @@
 <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
 dlzRecordID: 11
@@ Zeile 56: / Zeile 58: @@
 dlzAdminEmail: root.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
 </code>
@@ Zeile 78: / Zeile 91: @@
 <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
 dlzRecordID: 14
@@ Zeile 107: / Zeile 120: @@
   * 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>
-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
 dlzRecordID: 15
@@ Zeile 115: / Zeile 135: @@
 dlzType: ptr
 dlzData: invis5.invis-net.loc.
+dlzTTL: 86400
+</code>
+<code>
+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
+dlzRecordID: 16
+dlzHostName: 10
+dlzType: ptr
+dlzData: mail.invis-net.loc.
+dlzTTL: 86400
+</code>
+<code>
+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
+dlzRecordID: 15
+dlzHostName: 10
+dlzType: ptr
+dlzData: ns.invis-net.loc.
 dlzTTL: 86400
 </code>
@@ Zeile 128: / Zeile 168: @@
 <code>ou=DNS-Server,ou=domain,ou=tld</code>
+Dem wurde beim alten Schema noch der Zonentyp (Master oder Slave), die Richtung der Auflösung sowie der Zonenname vorangestellt.
+<code>ou=domain.tld,ou=forward,ou=zone.master,...</code>
+Zukünftig wird sich dies Ändern. Zunächst ist der Zonenname hier mit einem eigenen Attribut gekennzeichnet, dafür eine eigene "Organizational Unit" (ou) in den DN (Distinguished Name) eines DNS-Objektes einzufügen ist also obsolet. Weiterhin entfällt wie bereits erwähnt die Unterscheidung zwischen Vorwärts- und Rückwärtsauflösung, etwas worauf wir auch schon früher hätten verzichten können. Zu guter Letzt fügen wir der DLZ-Empfehlung folgend allerdings bei Bedarf den Hostnamen als zusätzlichen Knoten ein. Dies ist dann sinvoll, wenn etwa zu einem Host mehrere Einträge, seien es A- oder PTR-Records, folgen:
+Also, entweder:
+<code>dlzZoneName=domain.tld,ou=zone.master,....</code>
+oder:
+<code>dlzHostname=host,dlzZoneName=domain.tld,ou=zone.master,....</code>
+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:
+{{:invis-postfix_dovecot.png|Überblick}}
+==== 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.
+==== Postfix ====
+Postfix spielt die zentrale Rolle im gesamten Mail-Setup.
+Da wir es bezogen auf ein invis-Server-Setup "lediglich" mit einem Mailserver in einem lokalen Netzwerk zu tun haben, werden die in der Grafik genannten Restrictions nicht konfiguriert. Unser Server bekommt emails entweder nur via //**fetchmail**// oder von lokalen Benutzern eingeliefert. In beiden Fällen ist das Einliefern von Mails ohne Beschränkung erlaubt.
+Zunächst muss Postfix der eigene Zuständigkeitsbereich bekannt gemacht werden. Die zugehörigen Einstellungen werden in <file>/etc/postfix/main.cf</file> vorgenommen.