1 / 16

Two Issues in Directory Operations

Two Issues in Directory Operations. Dr. Tom Barton The University of Memphis & Internet2. You will recognize this part of the talk as a middleware talk, using Brendan’s criteria: Rambling Incoherent And, lieu of the requirement for humor I’ll substitute monotone, mumbling vocals.

doraa
Download Presentation

Two Issues in Directory Operations

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. Two Issues in Directory Operations Dr. Tom Barton The University of Memphis & Internet2

  2. You will recognize this part of the talk as a middleware talk, using Brendan’s criteria: • Rambling • Incoherent And, lieu of the requirement for humor I’ll substitute monotone, mumbling vocals. Advanced CAMP

  3. And those 2 issues are… • Monitoring replication with iPlanet DS v4.X • A stateful automated provisioning model. Offered as dissections from which to learn,not as recommendations for best practice. Advanced CAMP

  4. Replica roles at UoM • Mailbox server only. High volume, just the indices necessary for this function. • General purpose email routing, white pages, RADIUS backend, everyday ldap client applications. Moderately indexed. • Low volume but high indexing demand for certain applications. • Master should ideally be write-only. Advanced CAMP

  5. Replicas – raison d’etre • Replica specific indexing and/or administrative limits to support dependent applications • Fault isolation & tolerance • Performance of ldap provided authN|Z services Advanced CAMP

  6. Replication channel delay concerns • At UoM, all updates to ldap directory are asynchronous – we never rebuild the DIT. • Daily updates from CBSs can range up to 100K changes • Many applications use replicas for authN|Z. Near real time propagation of changes is needed. • Some applications use enterprise ldap directory as repository – benefit from integration with enterprise data. • Netreg Advanced CAMP

  7. Solutions & challenges • All (well, almost all) changes are “dribbled” in to maintain headroom in replication channel. • Sleep for a set number of milliseconds after writing each transaction, by transaction type. • Big brother monitors replication backlog (details later). • Some apps go bad and dump tons of changes undribbled (e.g., webmail personal prefs, at times). Advanced CAMP

  8. Available replication data • Replication activity logging can be enabled (to errors log) – very granular. • Basic replication data stored in DIT by DSAs • Master (in root DSE): lastChangeNumber, netscapeReplicaState • Consumers (in object readable only by Directory Manager): replicaUpdateReplayed Advanced CAMP

  9. bb replication monitor • Simple model of replication channel headroom based on baseline TPM and data update intervals. • Experientially determined alarm levels. • BB checks each 5 minutes, and consumers only update data in DIT about that often. Advanced CAMP

  10. Observations • Valuable – issues with service noticed and corrected quickly. • Specific to iPlanet DS v4.X. • Even iPlanet DS v5.X doesn’t do replication the same way. In fact, DS v5.X does not maintain data with which replication delay can be witnessed… • LDUP’s Update Vector appears to provide sufficient data to characterize replication channel performance. Advanced CAMP

  11. Automated stateful provisioning • Basic account provisioning is guided by a finite state machine. • Managed resources include • shell accounts • IMAP/POP/HTTP mailbox service • campus-wide computing cluster access • variety of directory enabled application and web services that use an LDAP directory for access control, or that use the LDAP directory to determine eligibility for service. Advanced CAMP

  12. States embody levels of service Provisioning profiles • Full access to basic services • Faculty, staff, enrolled student • Email & identity management, including PIN maintenance for access to administrative web applications • Accepted student, registered student • Identifiers maintained for continued support for outsourced services • alum Steps between these and oblivion • Notification of impending doom • Access denied • Resources deleted Advanced CAMP

  13. Independent variables for state transitions • state • substate • date the present state was reached • date by which the present state might end (expiration date) • major affiliation (faculty, staff, enrolled student, accepted student, registered student, alum) • multivalued attribute holding the identifiers of resources being managed for this account. Advanced CAMP

  14. UoM next generation state model Advanced CAMP

  15. Operational benefits • “the basic value proposition schtick” (cf. “Middleware Business Case”) • Smooth over issues with feeds from source systems (grace state) • Provide continuity of service to persons who temporarily drop out of source systems • Absence from a CBS need not imply absence from Univ community. • Avoid deletion of resources for persons not in fact departed (limbo state). Advanced CAMP

  16. Issues • Expression of former affiliation • Exposed during graceful removal? • “accidental” nature of residual affiliation • Guest account management • manageGuest – thumbs up • Sponsored account management • Managed by humans – well, supposed to be.. Advanced CAMP

More Related