[Date Prev][Date Next]
Should slurpd as a separate process?
I am working on storing replication information as subentries following the
LDUP Information model IETF draft (draft-ietf-ldup-infomod-04.txt) as
closely as possible. We need this feature because managing replicas using
config files with multi-master replication is a major pain.
Some time back, I had modified slapd code so that it can "trap" a replica
addition through LDAP and "reinitialize" it's known replica set. In the last
few days I've made changes to slurpd so that it can detect a "new" replica
and start a replica thread for it.
I have been thinking about the actual replica addition and deletion process
and facing some issues because slapd and slurpd are separate
processes. Here are examples of some issues I am facing.
1. Consider the no replica case; slurpd will not startup. As soon as the
first replica is added, slapd has to somehow start the slurpd process. A
workaround is to have an idle slurpd process around all the time.
2. Multiple OpenLDAP instances on a single box; since the replica
information is now in LDAP and not a conf file, slurpd needs to know the
slapd port. Workaround is to add a "slapdport" in the conf file or a
command line option to slurpd.
3. Initializing a new replica; i.e pushing the current directory information
tree (DIT) needs to be pushed to the new replica (currently done via
slapcat + slapadd or equivalent) is easier if driven from slapd instead
of slurpd reading it through LDAP first and then pushing it out again.
There are other cases that I can't remember right now. Any way, all these
issues leads me to wonder if we can just merge the two processes. slapd is
multi-threaded anyway, so there seems to be little logic maintaining a
separate process for a core functionality like replication.