[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: back-config

Overall this makes sense to me. Then instead of pointing slurpd at a config file, one would invoke it with an LDAPuri like
or ... cn=replog,olcDatabase={0}frontend,cn=config??sub

I note that our back-ldif implementation (which still needs to be submitted to ITS) stores one entry per filesystem file, so one might also use

Pierangelo Masarati wrote:

I think replication in general might need some reordering; asn long as we
intend to keep slurpd around, we need to identify what's key to


So, I think it would be good to have a separate entry for: "replica",
"syncrepl", "replog", each containing the appropriate data as attributes:

- uri (I'd drop the "host" option, since an hostport can always be written
as a URI)

Yes, I've pretty much done that - a "host" option on input is emitted as a URI.

- bindmethod
- binddn
- cred
- ...

- uri
- ...

- replogfile
- slurp-argfile
- slurp-pidfile

The presence of a (unique) "shadow" entry as child of a database could
indicate it's shadowed; if the type is "syncrepl", it means it's a
syncrepl consumer, otherwise only the "updateref" and "updatedn" fields
should be allowed.

The presence of a (unique) "syncprov" entry a child of a database could
indicate it's a syncrepl producer;

The syncprov overlay object already appears as a child of the database, that doesn't seem to need any changing.

the presence of a (unique) "replog"
entry as child of a database could indicate it's a slurpd master; the
presence of (multiple) "replica" entries as children of the "replog" entry
would store each replica's data.

Except this doesn't reflect the current implementation, where a single replog object (the global one) would logically be the parent of many per-database replica objects. That disconnect needs to be addressed.

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support