OpenLDAP Documentation

The lloadd load balancer uses a multi-threaded architecture to manage client and server (upstream) I/O. The runtime is organized into four main components:

1. Main Thread: Handles signals and manages the overall event base.
2. Listener Thread: Listens on rendezvous sockets and hands new connections to worker threads.
3. Worker Threads: A set of $n$ threads responsible for handling client and server I/O. These threads typically dispatch actual work to a thread pool.
4. Thread Pool: Dedicated threads used to execute the actual LDAP operations/work.

To maintain fairness and prevent starvation, the system uses queues and timeouts to ensure that requests are processed according to a principle of fairness: G( requested => ( F( progressed | failed ) ) ).

When an upstream sends data back to the client, the following flow occurs:

1. Read Upstream: Parses the PDU using ber_get_next(). It peeks at the msgid to resolve the corresponding client connection.
2. Validation: Checks if the operation is unsolicited, abandoned, or non-existent. If so, the PDU is dropped.
3. Write to Client: Reconstructs the final PDU and writes the BER to the client. If the write is incomplete, the client is marked as suspended.
4. Cleanup: If it is a final response, the operation counts for both the upstream and the client are decremented.
5. Response Handling: If the client is backlogged, the upstream is suspended and a callback is registered to unsuspend it once the client can accept more data.

To distribute load, lloadd selects an upstream using the following logic:

1. Level Selection: While a level is available, pick a random ordering of upstreams based on their configured weights.
2. Load Balancing: Within the selected level, find the least busy connection by checking the number of in-flight operations (requires locking the upstream map).
3. Availability: Check if a new connection should be opened and attempt to lock for a socket write. If no BER is currently queued, the upstream is available for use.

Upstream management follows an asynchronous lifecycle:

1. Async Connect: Establish connections up to the min_connections limit.
2. TLS Setup: Once connected, set up TLS if requested.
3. Bind: Perform the initial BIND interaction.
4. Registration: Once the bind is complete, add the connection to the upstream's connection list.
5. Scaling: If a connection is suspended or if the total connections exceed 75% of the operation limit, schedule the creation of a new connection (provided the connection limit has not been reached).

Before building the ppm module, ensure you have the following requirements met:

• OpenLDAP sources: Both the OpenLDAP source tree and the ppm source must be available.
• cracklib development files: Required if you want to test passwords against cracklib.
• pandoc: Required if you want to build the man page documentation.

To build and install the ppm module, navigate to the contrib/slapd-modules/ppm directory and run the standard make commands. By default, the installation prefix is /usr/local.

make clean
make
make test
make doc
make install

UTBM (Unicode Tuned Boyer-Moore) is a package designed to perform tuned Boyer-Moore searches on Unicode UCS2 text. It is capable of handling both high and low surrogates.

Core Assumptions

When using UTBM, the following conditions are assumed to be met:

• The search pattern and the target text are already normalized.
• Upper, lower, and title case conversions are one-to-one.
• For case conversions, UCS2 characters always convert to other UCS2 characters, and UTF-16 characters always convert to other UTF-16 characters.

The slapd (8) daemon uses backends to serve LDAP requests. Backends can be compiled statically into slapd or loaded dynamically if module support is enabled. You can configure multiple instances of a backend to serve different databases from a single slapd server.

Note that specific configuration options for each backend are found in their respective manual pages (e.g., slapd-mdb(5)).