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

Re: LDAP slurp problem [auf Viren überprüft]

Andreas Hasenack wrote:

On Wed, Jan 19, 2005 at 01:41:31PM +0100, Hans Moser wrote:

Pierangelo Masarati schrieb das Folgende am 18.01.2005 22:10:

Same here with 2.2.17.
I splited the DIT into two partions: root and ou=system.
First I replicated ou=system to two slaves. One database with a single replogfile. Everything works fine.
Today I added a replica-statement for the root-partition to replicate it to slave1. I added a replogfile there. But replication only works for one database, the second is ignored.
I disabled the two replogfiles and set a new one outside the databases.
Replication works, but slurpd seems to attempt to add the changes two times to slave1.
So I changed host for slave1 too SLAVE1 in one database and it works.

Yes, there is even an ITS on this (#3223). The final answer was
"None of the project developers has taken any interest in this issue, but you can always submit a patch that would be considered for incorporation."

You see, there is no clear solution for this problem. The best, to my knowledge, would be to modify slurpd so that ismine(), the function that determines whether a thread of slurpd should process an update, works on a string that contains the host, the port and the identity of the DN that's used to bind. In fact, those are the parameters that characterize an operation. Moreover, it should be given the possibility to consider a namingContext to work with, so each processing should look for a sort of an URI that uniquely identifies the entry as "ldap://<host>:<port>/<authcDN>" and, if the namingContext is defined, check whether dnIsSuffix(<entryDN>, <namingContext>), the default being "" so that any will match. These comparisons require all items to be properly normalized, and entries, as well as hostnames, in replog are not (that's why uppercasing works around the problem). This doesn't sound like a large project, but I really don't see all the need to spend cycles on something that's going to die shortly, as soon as 2.3 is out or so.


SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497