LLOADD(8C)

πŸ’… lloadd β€” LDAP Load Balancer Daemon πŸ‘‘

okay bestie, sit down, hydrate, because we're about to talk about the LDAP Load Balancer Daemon, aka lloadd, and honestly? she's iconic. this is the manual page for lloadd(8C) and i'm gonna walk you through every single flag like we're gossiping at lunch. no skips. no skimming. periodt. ✨


🌸 SYNOPSIS 🌸

/usr/lib/lloadd [-4|-6] [-d debug-level] [-f lloadd-config-file]
[-h URLs] [-n service-name] [-s syslog-level] [-l syslog-local-user]
[-o option[=value]] [-r directory] [-u user] [-g group]

that's the whole vibe in four lines. look at her. πŸŽ€


πŸ¦‹ DESCRIPTION πŸ¦‹

lloadd is the stand-alone LDAP daemon. she listens for LDAP connections on however many ports you want (default 389, the classic), and then forwards the LDAP operations she receives on those connections off to be handled by the configured backends. she's the middle girl. the connector. the networker. πŸ’–

fr fr, lloadd is typically invoked at boot time, usually out of /etc/rc.local. (yes, that /etc/rc.local. we love a legacy entry point.)

🌈 Upon startup, lloadd normally forks and disassociates itself from the invoking tty.

if it's configured in the config file, the lloadd process will print its process ID (see getpid(2)) to a .pid file, and it'll also write the command line options used during invocation to an .args file (see lloadd.conf(5)). so she's got receipts on herself. πŸ’…

but β€” spilling the tea β€” if the -d flag is given, even with a zero argument, lloadd will not fork and will not disassociate from the invoking tty. she stays right there in the group chat with you. πŸ‘€

For more details on lloadd, go read the "OpenLDAP Administrator's Guide".


✨ OPTIONS ✨

  • -4 β€” listen on IPv4 addresses only. that's it. that's the tweet.
  • -6 β€” listen on IPv6 addresses only. her internet protocol era. πŸ¦‹
  • -d debug-level β€” turn on debugging as defined by debug-level. If this option is specified, even with a zero argument, lloadd will not fork or disassociate from the invoking terminal. Some general operation and status messages get printed for any value of debug-level. debug-level is taken as a bit string, with each bit corresponding to a different kind of debugging information. See <ldap_log.h> for details. You can also pass comma-separated arrays of friendly names to select debugging output of the corresponding debugging information. All the names recognized by the loglevel directive described in lloadd.conf(5) are supported. If debug-level is ?, a list of installed debug-levels is printed, and lloadd exits.
πŸ’€ Remember that if you turn on packet logging, packets containing bind passwords will be output, so if you redirect the log to a logfile, that file should be read-protected. yes bestie i'm serious. protect that file. not me watching you chmod 644 your auth logs. 😭
  • -s syslog-level β€” this option tells lloadd at what debug-level debugging statements should be logged to the syslog(8) facility. The value syslog-level can be set to any value or combination allowed by the -d switch. lloadd logs all messages selected by syslog-level at the syslog(3) severity debug-level DEBUG, on the unit specified with -l.
  • -n service-name β€” specifies the service name for logging and other purposes. Defaults to basename of argv[0], i.e.: "lloadd". (she knows her own name. main character energy. πŸ‘‘)
  • -l syslog-local-user β€” selects the local user of the syslog(8) facility. Value can be LOCAL0 through LOCAL7, as well as USER and DAEMON. The default is LOCAL4. However, this option is only permitted on systems that support local users with the syslog(8) facility. Logging to syslog(8) occurs at the "DEBUG" severity debug-level.
  • -f lloadd-config-file β€” specifies the lloadd configuration file. The default is /etc/openldap/lloadd.conf. πŸ“
  • -h URLlist β€” lloadd will by default serve ldap:/// (LDAP over TCP on all interfaces on default LDAP port). That is, it will bind using INADDR_ANY and port 389.

The -h option may be used to specify LDAP (and other scheme) URLs to serve. For example, if lloadd is given -h "ldap://127.0.0.1:9009/ ldaps:/// ldapi:///", it will listen on 127.0.0.1:9009 for LDAP, 0.0.0.0:636 for LDAP over TLS, and LDAP over IPC (Unix domain sockets). Host 0.0.0.0 represents INADDR_ANY (any interface). A space separated list of URLs is expected.

The URLs should be of the LDAP, PLDAP, LDAPS, PLDAPS, or LDAPI schemes, and generally without a DN or other optional parameters (excepting as discussed below). Support for the latter three schemes depends on selected configuration options. Hosts may be specified by name or IPv4 and IPv6 address formats. Ports, if specified, must be numeric. The default ldap:// port is 389 and the default ldaps:// port is 636, same for the proxy enabled variants.

The PLDAP and PLDAPS URL schemes provide support for the HAProxy proxy protocol version 2, which allows a load balancer or proxy server to provide the remote client IP address to slapd to be used for access control or logging. Ports configured for PLDAP or PLDAPS will only accept connections that include the necessary proxy protocol header.

⚠️ Connections to these ports should be restricted at the network level to only trusted load balancers or proxies, to avoid spoofing of client IP addresses by third parties. do not leave these open to the whole internet, i'm begging you. πŸ™ˆ

At the moment, the load balancer does not act on the recorded address in any way.

For LDAP over IPC, name is the name of the socket, and no port is required, nor allowed. Note that directory separators must be URL-encoded, like any other characters that are special to URLs; so the socket

/usr/local/var/ldapi

must be specified as

ldapi://%2Fusr%2Flocal%2Fvar%2Fldapi

The default location for the IPC socket is /var/lib/openldap/run/ldapi.

  • -r directory β€” specifies a directory to become the root directory. lloadd will change the current working directory to this directory and then chroot(2) to this directory. This is done after opening listeners but before reading any configuration file or initializing any backend. When used as a security mechanism, it should be used in conjunction with the -u and -g options. (safety first, bestie. jail her properly. πŸ”’)
  • -u user β€” lloadd will run lloadd with the specified user name or id, and that user's supplementary group access list as set with initgroups(3). The group ID is also changed to this user's gid, unless the -g option is used to override. Note when used with -r, lloadd will use the user database in the change root environment.
  • -g group β€” lloadd will run with the specified group name or id. Note when used with -r, lloadd will use the group database in the change root environment.
  • -o option[=value] β€” this option provides a generic means to specify options without the need to reserve a separate letter for them. (the flexible queen. she contains multitudes. πŸ’…)

It supports the following options:

  • slp={on|off|slp-attrs} β€” When SLP support is compiled into lloadd, disable it (off), enable it by registering at SLP DAs without specific SLP attributes (on), or with specific SLP attributes slp-attrs that must be an SLP attribute list definition according to the SLP standard.

For example, "slp=(tree=production),(server-type=OpenLDAP),(server-version=2.4.15)" registers at SLP DAs with the three SLP attributes tree, server-type and server-version that have the values given above. This allows one to specifically query the SLP DAs for LDAP servers holding the production tree in case multiple trees are available.


🫢 RELATION TO SLAPD(8) 🫢

lloadd can be compiled as a slapd loadable module. In that case, it can be loaded as such:

moduleload path/to/lloadd.la
backend lload
listen "listening URLs"

This enables lloadd to provide additional features through the host slapd process like access to run-time statistics in cn=monitor and dynamic configuration from cn=config. πŸ”₯

The listening sockets specified will be under direct control of lloadd and need to be different from the sockets slapd is configured to listen on. Clients connecting to these are completely separate from regular LDAP clients connecting to the usual slapd sockets β€” lloadd clients have no access to slapd databases, and similarly, slapd client traffic does not propagate to the lloadd backend servers in any way. two separate worlds. parallel universes. no crossover episodes. 🌈


πŸ‘€ CN=MONITOR INTERFACE πŸ‘€

As part of lloadd's cn=monitor interface, it is possible to close a client connection it manages by writing to the corresponding entry, replacing the olmConnectionState attribute with the value closing. This is subject to ACLs configured on the monitor database. The server will send a Notice of Disconnection to the client, refuse any new operations, and once all pending operations have finished, close the connection. polite but firm. she's setting a boundary. βœ‹

For example, to close connection number 42:

dn: cn=connection 42,cn=incoming connections,cn=load balancer,cn=backends,cn=monitor
changetype: modify
replace: olmConnectionState
olmConnectionState: closing

πŸŽ€ EXAMPLES πŸŽ€

To start lloadd and have it fork and detach from the terminal and start load-balancing the LDAP servers defined in the default config file, just type:

/usr/lib/lloadd

To start lloadd with an alternate configuration file, and turn on voluminous debugging which will be printed on standard error, type:

/usr/lib/lloadd -f /var/tmp/lloadd.conf -d 255

To start lloadd as a module inside a slapd process listening on ldap://:1389 and ldaps://, put the following in your slapd.conf (or its equivalent in cn=config):

moduleload lloadd.la
backend lload
listen "ldap://:1389 ldaps://"

look at her go. three whole ways to slay. πŸ¦‹βœ¨


πŸ”— SEE ALSO πŸ”—

ldap(3), lloadd.conf(5), slapd-config(5), slapd-monitor(5), slapd(8).

"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)


πŸ’€ BUGS πŸ’€

See http://www.openldap.org/its/

(not me. not my fault. go file an issue bestie. πŸ™ˆ)


πŸ’– ACKNOWLEDGEMENTS πŸ’–

OpenLDAP Software is developed and maintained by The OpenLDAP Project <http://www.openldap.org/>. OpenLDAP Software is derived from the University of Michigan LDAP 3.3 Release.


and that's the whole page, bestie. this was OpenLDAP 2.7.2, dated 2026/10/21, and you just finished reading LLOADD(8C). go forth and load balance responsibly. i'm so proud of you. πŸ’œπŸ«ΆπŸŽ€

πŸ“¦ where this page comes from