1 / 27

LDAP Content Synchronization

LDAP Content Synchronization. Kurt D. Zeilenga Jong Hyuk Choi OpenLDAP Project IBM Research. Title slide. Agenda. What is a directory? What is X.500? What is LDAP? What is the OpenLDAP Project? LDAP Content Synchronization Questions and Answers. Agenda slide. What is a Directory?.

brysong
Download Presentation

LDAP Content Synchronization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LDAP Content Synchronization Kurt D. Zeilenga Jong Hyuk Choi OpenLDAP Project IBM Research Title slide

  2. Agenda • What is a directory? • What is X.500? • What is LDAP? • What is the OpenLDAP Project? • LDAP Content Synchronization • Questions and Answers Agenda slide

  3. What is a Directory? • A database organized and/or optimized for lookup, searching, browsing, and other “read” activities. • Examples: • address books • web catalogs • whois(1) • dict(1) • operating system / network information services • Domain Name System

  4. What is X.500? • The set of ITU standards covering electronic directory services. • X.500 defines the OSI Directory Service • Hierarchical • Distributed • Replicated • Schema driven

  5. What is LDAP? • Lightweight Directory Access Protocol • an IETF Proposed Standard • A protocol for accessing X.500 directory services over the Internet (or networks using Internet Protocols).

  6. What is OpenLDAP? • OpenLDAP Software • “community developed LDAP software” • OpenLDAP Project • “a collaborative effort to develop a robust, commercial-grade, fully featured, and open source LDAP suite of applications and development tools” • OpenLDAP Foundation • Provides a legal umbrella for the OpenLDAP Project • http://www.openldap.org

  7. Request Response LDAP Overview User The Directory Closing slide

  8. Request Response Polling for content changes User The Directory X Closing slide

  9. Problems with simple “polling” • Cannot reliably detect whether the entry named by a DN is the same entry previously named by that DN. DNs are not stable identifiers! • A complete copy of each entry is transferred with each poll • Changes not apparent until next poll

  10. Stable Identifiers • Add an Universally Unique Identifier (UUID) to each entry. • Introduce entryUUID operational attribute • Add knowledge of superior’s UUID for each entry. • Introduce parentUUID operational attribute

  11. Reducing traffic • Each entry in LDAP has create and modify time stamps • (&(FILTER)(|(createTimeStamp>=TIME)(modifyTimeStamp>=TIME)) • where • FILTER is our original assertion and • TIME is the greatest seen in previous content. • All entries created/modified before TIME are not transferred. • Does not detect deleted (or modified ‘out of scope’) entries. • Does not detect unchanged entries now ‘in scope’ • Search operations are not necessarily isolated from directory modifications. One cannot assume all updates made before TIME appeared in the previous content.

  12. We need to extend LDAP to support a lightweight content synchronization mechanism!

  13. Target Applications • Heterogeneous Data Store Synchronization • “meta directory” applications • Local content shadowing • Directory-enabled services (web, email, etc.) • Mobile clients • LDAP Replication • Single master • Partial (Sparse and/or Fractional) Replication

  14. Design Goals • Less chatty than “simple polling” • Maintain consistency • Eventually convergent (inconsistencies are transient) • Support “polling” for changes • Support “listening” for changes • Support partial synchronization • Do not require pre-arranged synchronization agreements • Do not require server to maintain per client state information • Do not require server to maintain histories of changes • Lightweight / Simple

  15. Non-goals • Support bi-directional synchronization • Support very small clients (e.g., PDAs) • Attribute (or finer) granularity

  16. Synchronization Overview New Old Changed Content Renamed Content Added Content Deleted Content Unchanged Content

  17. Basic “Refresh Mode” Protocol Design Initial Content Request Send Entries Done with Cookie Content Refresh Request Send “Changed” Entries Send “Present” Messages Done with Cookie Repeat

  18. First things first… • Stable object identifiers • LDAP Distinguished Names are not stable • Solution: add entryUUID and parentUUID attributes to every entry • Time stamps • LDAP create/modify time stamps are generally good enough, but semantics are unclear • Solution: add change sequence numbers (CSNs) to every entry, well define the semantics

  19. The Cookie • Synchronization State Indicator • Greatest committed change sequence number (CSN) in context which is not greater than any outstanding CSN • e.g., Change Sequence Numbers != Commit Sequence Numbers

  20. Bandwidth

  21. Refresh: updates+present v. updates+deletes • If server has no histories, it cannot determine what to “delete” • If server maintains “tombstone” information for deleted entries but no content change history, it must send deletes for all new tombstones as well as all out-of-scope updated entries. • If the server can reliably determine which entries previously present in the shadow copy which are no longer present in the content and the number of such entries is less than equal the number of unchanged entries, the server may send “deletes” instead of “present” messages.

  22. OpenLDAP Implementation • No naming/change history • Each entry has: • entryUUID/parentUUID • entryCSN - updated on entry modify • namingCSN - updated on entry (not subtree) rename • Context has: • Outstanding CSNs - ordered list • Outstanding Naming CSNs – ordered list • Allows server to detect some “no deletes” cases.

  23. Repeat “Refresh & Persist Mode” Protocol Design Content Request Send Entries Refresh Done Send “Changed” Entries and/or “Deleted” messages New “Cookie” Cancel Done with Cookie / Acknowledge Cancel

  24. Special Cases • Operational Attributes • Must either be treated as part of the entry’s content if transferred. • structuralObjectClass • hasSubordinates • subschemaSubentry • Alias and Referral objects • No dereferencing • Treat as normal object • Collective Attributes • Not treated as content of entries of the collection • Client must ‘watch’ the collective attributes subentries • Access and other administrative controls • Server must either generate appropriate changes to sync client • OR force reload

  25. Summary • The LDAP Content Synchronization Operation appears to met our needs: • Supports both “Polling” and “Listening” modes • “Polling” mode is less chatty than “simple polling” • “Listening” mode is significantly less chatty than “simple polling” • Eventual convergence is assured, inconsistencies are transient. • No pre-arranged synchronization agreements are needed. • Server need not maintain histories or per-client state information. • Able to support our target applications: • Meta Directory • Content caching • LDAP Replication

  26. Availability • IETF Technical Specification: • draft-zeilenga-ldup-sync-xx.txt • draft-zeilenga-ldup-uuid-csn-xx.txt (available soon) • Last Call this summer (hopefully) • OpenLDAP Implementation: • LDAP-sync client and server implementations committed to HEAD • First-cut LDAP Replication engine committed to HEAD • Release target: OpenLDAP 2.2 in Summer of 2003

  27. Questions? Closing slide

More Related