title: Slurpd, you can't get it at 7-11 link: https://onemoretech.wordpress.com/2004/09/05/slurpd-you-cant-get-it-at-7-11/ author: lembobro description: post_id: 762 created: 2004/09/05 20:25:00 created_gmt: 2004/09/05 20:25:00 comment_status: open post_name: slurpd-you-cant-get-it-at-7-11 status: publish post_type: post

Slurpd, you can't get it at 7-11

The OpenLDAP man page for slurpd defines it as the “Standalone LDAP Update Replication Daemon”. And so it is. Longer in production and more mature than its client-side replication cousin, syncrepl, slurpd provides a server-side “push” of changes from a master LDAP directory to designated replica (or slave) directories.

The directory service I use in my lab at home does not see alot of changes, so issues such as the relative robustness of slurpd over syncrepl are not really a concern there. Given the interest being shown in open source directory solutions in many places, however, I’ve begun to kick the tires on the daemon to re-familiarize myself with its inner workings.

Slurpd is built by default in a stock “configure, make, make install” of OpenLDAP. On FreeBSD it gets installed as part of the openldap-server port.

While I’ve never had this problem with a source build on Linux, the current FreeBSD port annoyingly hardcodes the daemon so that it will only work when the replication log file location (set using the replogfile directive in slapd.conf) is set to /var/db/openldap-slurp/replica.

What you wind up with in this configuration are a pair of replication log files (one for slapd, the other for slurpd) and their corresponding lock files. When a change gets made on the master, this gets recorded in the slapd replog (in my config, /var/db/openldap-slurp/replica/slapd.replog), and then passed over to the slurpd replog (on my server, /var/db/openldap-slurp/replica/slurpd.replog).

When an update fails, a record of it gets written to a separate *.rej log. The data in both replog files is written out in clear text, LDIF (LDAP Data Interchange) format with the requisite LDAP commands, and so should be secured with the same attention as the slapd database itself.

This particular method of formatting may make it possible to use these files as part of a custom synchronization system that could work with other vendor directories, such as Active Directory (something I’ve read has been done at the University of Michigan).

The slapd.replog file gets purged once slurpd reads it, while the slurpd.replog file maintains a running history of changes made. The latter, which can grow quite large, is therefore a candidate for log rotation by the newsyslog facility in FreeBSD. I’ve got mine set to top out at 1000 Kb (1 Mb), which is reasonable for my environment. Larger, more active, installations, may need to grow the file bigger.

Copyright 2004-2019 Phil Lembo