[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: replicating attribute with no value
I experienced the same problem. I posted to the list a few days ago about it. It details what I did to work around it. It's not the exact same problem, since I'm using perldap, but the issue is the same. Basically, I had to do a delete, then an add, instead of replace.
Here's a copy of my post:
Daniel Ceregatti wrote:
> I've been battling this problem for 2 days now. Here's what I've concluded:
>
> Equipment used:
>
> 1 Master (Stock Redhat Linux 6.2) with openldap 1.2.11 compiled frrom source
>
> 2 Slaves (1 - Stock Redhat Linux 6.1 with openldap 1.2.11 rpm, and 1 E250 Solaris 8, openldap 1.2.11 compiled from source)
>
> I mostly use the java based LDAP Browser 2.8 (http://www-unix.mcs.anl.gov/~gawor/ldap/) to manage the master. When making changes to the master, I have verified that all changes are being properly replicated on the two slaves by connecting to the slaves with the java client and manually verifying all changes. I also tail the replication log file on the master (/usr/tmp/replica/slurpd.replog).
>
> I have been creating a set of web pages using perldap 1.4 to better manage LDAP. The web pages can successfully make changes on the master. The problem is, these changes for the uid I'm changing in ou=people,dc=domain,dc=com dn are NOT replicated onto the slaves, even though I can see the entries flying by while tailing the replication log on the master. All other dn's are replicated. The entries in the replication log look normal, and I don't see any errors.
>
> I've done some testing and have determined that when I do an $entry->setValues('foo', 'bar'), the master updates, but the slaves do not. The replication log shows an attempted "replace" on the entries.
>
> I have since changed the script to do a $entry->remove('foo'), $conn->update($entry), then an $entry->addValue('foo', 'bar'), followed by another $conn->update($entry). This works! The replication logs show a "delete", then an "add".
>
> I guess my question is, should slurpd replicate, regardless of how the master is changed? Do I simply not understand?
>
> I have read the openldap docs (somewhat) and I the way understand it, replication should be client agnostic. It's basically up to slapd to write replication information to a file, and up to slurpd to read the file and propagate the changes. Why would a particular update method cause replication to fail?
>
> I've used 3 different clients to query the slaves to make sure the changes are in fact not replicating. I can positively state that the changes are not replicating.
>
> So, I've resorted to asking the list. I have searched the list and have not found any relevant posts.
>
> Thanks in advance.
>
> Daniel Ceregatti
Siao Chiun wrote:
> Hi,I have OpenLDAP version 1.2.11 running on 2 of my (solaris 2.7) servers. One as the master and the other as slave. The problem i am facing now is:When i do a modification to the master using netscape's ldapjdk(LDAPModification.REPLACE), entries are modified in the master but it is not repliated to the slave. After much testing, I found out that it is due to some attributes with empty string. This is a snapshot of the slapd.replog: replica: 123.123.1.1
> time: 975032627
> dn: UID=PRODSC1,OU=MEMBERS,O=MYABC.COM
> changetype: modify
> replace: cn
> cn: sc
> -
> replace: sn
> sn: wee
> -
> replace: age
> age:-
> replace: gender
> gender: F
> - The attribute age has no value (It is not an required attribute). The master ldap has no problem with that but it seems that the replication to the slave ldap doesn't like that. Only when i removed these lines: replcae:age age: - The modification can be repliated over. Does anyone has a solution for that? Thanks in advance. Regards,Siao-Chiun