I've never tried that method of updates, so I really couldn't say. It almost seems like you should try a full delete and then add. I'm putting your reply back on the list so someone else can comment.
On 10/18/07, Gessy gessycaetano@gmail.com wrote:
Hi Matthew,
Reading ldif(5) manual, i saw two LDIF types: Entry Records and Change Records. LDIF entry records are used to represent directory entries and LDIF change records are used to represent directory change requests.
Let me explain with this example:
Suppose i have on my directory a entry like:
uid=test,ou=people,dc=example,dc=com objectClass: account objectClass: posixAccount objectClass: SIPIdentity objectClass: top uid: test loginShell: /bin/bash uidNumber: 600 gidNumber: 100 homeDirectory: /home/test gecos: test userPassword: {SSHA}nswXaxRGB3jBPNnpYGzRiQrAt6k5eCyr SIPIdentitySIPURI: sip:00011080@voip.example.com SIPIdentityServiceLevel: AR SIPIdentityUserName: 10811080 SIPIdentityPassword: 8997e7a13ff2641ae6142f05b41efd6f
If i create a LDIF with other password and without SIP attributes like:
uid=test,ou=people,dc=example,dc=com objectClass: account objectClass: posixAccount objectClass: SIPIdentity objectClass: top uid: test loginShell: /bin/bash uidNumber: 600 gidNumber: 100 homeDirectory: /home/test gecos: test userPassword: {SSHA}xLkfk/Lt5F5VG872wEqbC0H5+AlP6bIu
And using ldapmodify to update the entry with LDIF above, i expect the all entry be replaced by LDIF data. Am i wrong?
if i use a Change record LDIF, it would be:
uid=test,ou=people,dc=example,dc=com changetype: modify replace: userPassword userPassword: {SSHA}xLkfk/Lt5F5VG872wEqbC0H5+AlP6bIu
delete: SIPIdentitySIPURI SIPIdentityServiceLevel SIPIdentityUserName SIPIdentityPassword SIPIdentitySIPURI: sip:00011080@voip.example.com SIPIdentityServiceLevel: AR SIPIdentityUserName: 10811080 SIPIdentityPassword: 8997e7a13ff2641ae6142f05b41efd6f
But i'd really use the entry record LDIF.
thanks a lot Gessy Jr.
On 10/17/07, matthew sporleder < msporleder@gmail.com> wrote:
On 10/17/07, Gessy < gessycaetano@gmail.com> wrote:
Hi,
I have tried replace entries on ldap directory with ldapmodify, my
server is
a gentoo linux running a OpenLDAP 2.3.35, but i realized a strange
behavior.
When I try replace a entry with follow LDIF:
# Test.ldif - test10 dn: uid=test10,ou=people,dc=ufmg,dc=br objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: eduPerson objectClass: brEduPerson objectClass: posixAccount objectClass: shadowAccount objectClass: ufmgEduPerson objectClass: SIPIdentity eduPersonOrgDN: o=UFMG eduPersonOrgUnitDN: ou=LCC eduPersonAffiliation: employee eduPersonPrimaryAffiliation: employee cn: Test10 givenName: Test sn: 10 mail: test10@ufmg.br gecos: CN=Test 10 uidNumber: 136617 gidNumber: 100 homeDirectory: /home/ufmg/test10 loginShell: /bin/bash uid: test10
ldapmodify -x -D"cn=manager,dc=ufmg,dc=br" -W -f test.ldif
The LDIF above should replace fully a old entry that contains a SIP attributes with only attributes shown in test.ldif , but it update the
entry
and keep the SIP attributes. I don't understant. Can someone help me?
ldapsearch -x uid=test10 -LLL dn: uid=test10,ou=people,dc=ufmg,dc=br SIPIdentitySIPURI: sip:xxxxx@aaa.bbb.br SIPIdentityServiceLevel: AR SIPIdentityUserName: 10811080 SIPIdentityPassword: 8997e7a13ff2641ae6142f05b41efd6f objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: eduPerson objectClass: brEduPerson objectClass: posixAccount objectClass: shadowAccount objectClass: ufmgEduPerson objectClass: SIPIdentity eduPersonOrgDN: o=UFMG eduPersonOrgUnitDN: ou=LCC eduPersonAffiliation: employee eduPersonPrimaryAffiliation: employee cn: Test10 givenName: Test sn: 10 mail: test10@ufmg.br gecos: CN=Test 10 uidNumber: 136617 gidNumber: 100 homeDirectory: /home/ufmg/test10 loginShell: /bin/bash uid: test10
Do you have a changetype defined somewhere that I'm missing? It looks like you want to do a changetype: modify, then add: someattribs, then someattribs: somevalues, repeat.
http://tools.ietf.org/html/rfc2849 (see page 10 or so)