openldap development
Skip this Video
Download Presentation
OpenLDAP Development

Loading in 2 Seconds...

play fullscreen
1 / 13

OpenLDAP Development - PowerPoint PPT Presentation

  • Uploaded on

OpenLDAP Development. Back-config –Configuration Backend Howard Chu [email protected] ODD/Wien July 18, 2003. Objectives. Support runtime reconfiguration without requiring server restarts Allow ACL reconfiguration Allow schema modification Support remote administration of slapd

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' OpenLDAP Development' - papina

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
openldap development

OpenLDAP Development

Back-config –Configuration Backend

Howard Chu [email protected]

ODD/Wien July 18, 2003

  • Support runtime reconfiguration without requiring server restarts
    • Allow ACL reconfiguration
    • Allow schema modification
  • Support remote administration of slapd
    • Enable performing all configuration via LDAP
  • The objectives are not mutually assured:
    • Could e.g. use SIGHUP to force reread of config file, thus allowing runtime changes, but not allowing remote administration
    • Could provide LDAP interface to rewrite config file, without any mechanism for slapd to reload the changed configuration
  • Fulfilling both objectives is desirable
  • Either one may require significant effort
runtime reconfiguration
Runtime Reconfiguration
  • Preliminary support embodied in Gentle HUP processing:
    • Aimed at allowing a new slapd instance to be started with minimal impact on existing sessions
    • The new slapd instance can use the same BDB database as the old, or can use a separate database
gentle hup cont d
Gentle HUP, cont’d
  • Implementation is awkward at best
    • Requires descriptor-passing to avoid session interruption
    • Database sharing requires back-bdb and shared mutex support
  • Some benefits from starting a new instance
    • New executables can be installed with minimal service impact
    • Can temporarily recover from memory leaks
runtime constraints
Runtime Constraints
  • Config processing is currently single-threaded
    • Config file is processed before threads are spawned
    • Config data is not mutex protected
    • Adding mutexes may harm overall performance
ensuring config consistency
Ensuring Config Consistency
  • Use a single rdwr lock for access to global variables
    • Highly invasive code change, requires locking in many places
    • Doesn’t ensure consistency within the life of an operation
  • Disable the thread pool
    • Wait for all executing operations to complete
    • Prevent new operations from being dispatched until config changes are processed
remote administration
Remote Administration
  • Varying degrees of “LDAP enablement” possible
    • Expose slapd.conf as generic text attributes, with no semantic awareness
    • Map coarse set of objects onto slapd.conf, minimal semantic awareness
    • Replace slapd.conf with LDIF/attribute-based format
  • Each approach has tradeoffs
slapd conf as generic text
Slapd.conf as generic text
  • Implementation is fairly trivial
    • Models already exist (e.g. back-passwd) for using flat text files as backends.
    • Has no impact on current config processing code
  • Major disadvantages
    • Very difficult to support runtime reconfig
    • Ignores “include” directives
    • Makes it too easy to shoot yourself in the foot
slapd conf with partial semantics
Slapd.conf with partial semantics
  • Targets specific functionality with explicit attributes, leaves remainder as generic text
    • Handle include, access, and schema keywords
    • Optionally handle database keywords as separate objects
  • Drawbacks
    • Loses config file comments
    • Still requires some changes to existing config parsing code
slapd conf as ldif
Slapd.conf as LDIF
  • Provides the most client-friendly support
    • Defines schema for all existing config functionality
  • Requires extensive changes in slapd
    • Config parsing must be completely rewritten for slapd and all backends
      • Needs to be table-driven
      • Needs OID allocation methodology, etc.
    • Requires support for per-backend schema to avoid config syntax clashes
which is best
Which is best?
  • Using generic text precludes changes taking effect immediately
  • Supporting a small set of keywords provides some essential features now, others later/never
  • Migrating to LDIF requires major overhauling of slapd
  • The pure generic text solution is not useful enough
  • The full LDIF solution is taking too much effort to complete
  • Will probably fall back to partial support
  • Open to suggestions and assistance!