stk schrieb:
Moin,
Schon klar - das war's was ich mit cronjobbing meinte. Alles was dir der Master an eigenen Einstellungen mit der nächsten Replizierung überfährt, mußt Du dann händisch oder eben zeitgesteuert automatisiert wieder nacharbeiten (lassen). Elegant ist freilich was anderes.
Aber wo wir hier schon mal LDAP-Wissen versammelt haben (wow - tjp!) ich hab da auch noch 'ne offene Position: wie muß ein Schema aussehen, das via LDAP lediglich das Adressbuch füllt, aber keine Benutzereinträge enthält? Und wie schaffe ich es, dieses Schema aus einer FileMaker-Datei zu extrahieren (ggf. auch über Umwege wie z.B. TabText zum Adressbuch und von dort via Addressbook2LDAP in den Server)?
Gruß Stefan
Zu 1)
Echte LDAP Replikation funktioniert so, daß auf dem Master Server alle Slave Server eingetragen werden. Desweiteren wird ein Replikationsaccount definiert, da dieser Account das Recht haben muß, alle Daten im DIT (Directory Information Tree, so nennt man die Information, die im Directory-Server abgelegt sind) schreiben zu dürfen. Die Slave-Server erlauben nur noch diesem Replikationsaccount den DIT zu ändern. Versucht das irgend ein anderer berechtigter Nutzer bekommt er einen LDAP Referal zurück, in dem die Info enthalten ist, wie er seine Änderung auf dem Master schreiben kann.
Ergo, kann man keine Replikation eines LDAP-Servers machen, wenn man keinen Vollzugriff auf den Server hat, hat man diesen kann man gleich den eingebauten Replikationsmechanismus benutzen.
Zu 2)
Ich glaube ich muß weiter ausholen. Das Schema definiert die Struktur möglicher Einträge im DIT, es ist aber nicht der DIT selbst. Der DIT ist natürlich auch strukturiert und nicht ohne Grund taucht der Begriff Tree (Baum) auf. Ein DIT hat immer eine Baumstruktur, sollte dies aus was für einen Grund nicht ausreichend sein, kann man mittels Alias Objekte diese starre Struktur durchbrechen und eine Netzstruktur indirekt erzeugen, in dem von bestimmten Stelle im Baum auf andere Stellen verwiesen wird.
Das Schema entspricht in etwa einer Tabellendefinition in einem RDBMS. Etwas Vergleichbares zu dem DIT gibt es in einem RDBMS nicht, da sind alle Tabellen flach und eben nicht strukturiert wie im DIT.
Was Du zum Anlegen eines Telephonverzeichnisses brauchst ist erstmal eine geeignete Objektklasse (d.h. sie erlaubt das Speicher der relevanten Informationen) aus dem Schema. Üblicherweise nimmt man die Objektklasse
inetOrgPerson für diesen Zweck. Da es sich um eine der Standardklassen handelt, sollte sie auf jedem aktuellen Server vorhanden sein. Jeder inetOrgPerson Eintrag
muß die Einträge cn, sn und objectclass enthalten (diese Anforderungen werden von organizationalPerson geerbt).
Nachdem klar ist welche Objektklasse(n) Du verwenden kannst, taucht die Frage auf wie lautet der Root-Eintrag Deines LDAP-Servers?
Wenn Du noch keinen hast, dann mußt Du Dir überlegen wie der DIT strukturiert werden soll. Üblich sind Strukturen wie "o=meine Firma" oder "c=DE", "dc=de" oder "dc=meineDomain,dc=de" oder oder oder der Phantasie sind da keinerlei Grenzen gesetzt. Man versucht meist eine Firmenstruktur oder Domainstruktur nachzubilden, da dies das Leben erleichtert, wenn man bestimmte Services mit LDAP zusammenbenutzen will.
Als einfach Bespiel nehme ich jetzt einfach "c=DE". Man definiert das beim Anlegen des DITs das so, wie das im einzelnen geht ist abhängig vom LDAP-Server.
Nehmen wir weiter an, Du willst die Telephonkontakte im DIT ablegen und diese z.B. nach privaten und geschäftlichen Kontakten aufteilen.
Dann legst Du als erstes eine Struktur unterhalb des Roots an (üblicherweise nimmt man dafür die Objektklasse organizationlUnit). Die Beschreibung des DITs erfolgt als LDIF Datei.
Code:
dn: ou=Telefon privat,c=DE
objectclass: top
objectclass: organizationalUnit
ou: Telefon privat
dn: ou=Telefon geschäftlich,c=DE
objectclass: top
objectclass: organizationalUnit
ou: Telefon geschäftlich
Damit hast Du erstmal die Grundstruktur angelegt. Jetzt kann man beide Verzeichnisse mit Daten befüllen.
Code:
dn: cn=Hans Mustermann,ou=Telefon privat,c=DE
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Hans Mustermann
sn: Mustermann
mail: [email protected]
postalAddress: Musterstraße 1
postalCode: 12345 Musterstadt
telephoneNumber: +49 XX XXXXXXXX
...
Das Spielchen treibt man solange bis man alle Einträge für den LDAP-Server definiert hat. Wichtig ist hierbei, wenn Du Objekt unter geschäftlich und privat einsortieren willst, immer den DN des Eintrages entsprechend zu gestalten. Desweiteren muß für einen gültigen Eintrag im DIT, der RDN (d.h. der neue Teil in diesem Fall cn=Hans Mustermann) des Eintrages mit demselben Attribut des Eintrages übereinstimmen (d.h. RDN cn=Hans Mustermann und das Attribut cn=Hans Mustermann müssen übereinstimmen).
Wenn Du nun Daten aus Filemaker exportieren willst, muß Du eine LDIF-Datei erzeugen und diese in den DIT importieren. Für neue Einträge auf dem LDAP-Server empfehle ich so Tools wie den LDAP-Editor
JXplorer. Damit kann man komfortabel Einträge auf dem LDAP-Server generieren. Bei Fehler weist der Editor einem auch gleich darauf hin.
Ergänzung:
Leider darf man in einem LDIF-keine Umlaute direkt reinschreiben, diese müssen speziell kodiert sein. D.h. sie meinen Beitrag nur als lesbares Beispiel wie man es in einem Editor eintippen würde. Wenn man das LDIF wirklich mit Umlauten schreiben will, muß das betreffende Feld erst UTF-8 und dann Base64 kodiert sein. Damit das beim Parsen erkannt wird folgt nach dem obligatorischen Namen und ":" ein weiterer ":".
Also statt
Code:
ou: Telefon geschäftlich
ou:: IrgendEineBase64Buchstabensuppe
. Nun will ich beim Wechsel auf OSX10.4-Server ein "externes" LDAP-System nutzen. Im ganzen Klinikum gibt es ein LDAP-System, in dem die Benutzer eh bekannt sind. Ich möchte nun, dass sich die (wenigen) Benutzer in meinem Bereich über ihr LDAP-ID und Kennwort anmelden. 
). Aber _echt_ vielen Dank!
.