108473 - LDAPModify -a fails if the LDIF file contains changetype fields

Status: RESOLVED WONTFIX

(Directory Graveyard :: LDAP Java SDK, enhancement, P5)

Description

[Bemtya Joshi]

I'm trying to use LDAPModify to upload an ldif.

The ldif is as follows:

dn: cn=scarter, ou=orgunit, o=company.com
changeType: add
roomnumber: 4612
givenname: Sam
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
ou: orgunit
facsimiletelephonenumber: [phone]
mail: [e-mail]
cn: scarter
telephonenumber: [phone]
l: Sunnyvale
sn: Carter


[root@eureka:~/TestDrivers] java LDAPModify -debug -D "cn=Directory Manager" -
w "password" -p 10000 -h eureka.company.com -f user.ldif -v -a

adding new entry cn=scarter, ou=orgunit, o=company.com
        LDAPAttribute {type='mail', values='[e-mail]'}
        LDAPAttribute {type='objectclass', 
values='top,person,organizationalPerson,inetOrgPerson'}
        LDAPAttribute {type='givenname', values='Sam'}
        LDAPAttribute {type='telephonenumber', values='[phone]'}
        LDAPAttribute {type='cn', values='scarter'}
        LDAPAttribute {type='changetype', values='add'}
        LDAPAttribute {type='roomnumber', values='4612'}
        LDAPAttribute {type='sn', values='Carter'}
        LDAPAttribute {type='ou', values='orgunit'}
        LDAPAttribute {type='facsimiletelephonenumber', values='+1 408 555 
9751'}
        LDAPAttribute {type='l', values='Sunnyvale'}
cn=scarter, ou=orgunit, o=company.com: Object class violatio

This works with the default ldapmodify that ships with Solaris 8.  The 
directory log is

[04/Nov/2001:20:33:23 -0800] conn=78 fd=70 slot=70 connection from 
10.66.131.250 to 10.66.131.250
[04/Nov/2001:20:33:23 -0800] conn=78 op=0 BIND dn="" method=128 version=3
[04/Nov/2001:20:33:23 -0800] conn=78 op=0 RESULT err=0 tag=97 nentries=0 etime=0
[04/Nov/2001:20:33:24 -0800] conn=78 op=1 ADD 
dn="cn=scarter,ou=getAccess,o=entrust.com"
[04/Nov/2001:20:33:24 -0800] conn=78 op=1 RESULT err=65 tag=105 nentries=0 
etime=0
[04/Nov/2001:20:33:24 -0800] conn=78 op=-1 fd=70 closed - B1

The log from ldapmodify is

[04/Nov/2001:20:34:41 -0800] conn=80 fd=68 slot=68 connection from 
10.66.131.250 to 10.66.131.250
[04/Nov/2001:20:34:41 -0800] conn=80 op=0 BIND dn="cn=Directory Manager" 
method=128 version=3
[04/Nov/2001:20:34:41 -0800] conn=80 op=0 RESULT err=0 tag=97 nentries=0 etime=0
[04/Nov/2001:20:34:41 -0800] conn=80 op=1 ADD 
dn="cn=scarter,ou=getAccess,o=entrust.com"
[04/Nov/2001:20:34:41 -0800] conn=80 op=1 RESULT err=0 tag=105 nentries=0 
etime=0
[04/Nov/2001:20:34:41 -0800] conn=80 op=2 UNBIND
[04/Nov/2001:20:34:41 -0800] conn=80 op=2 fd=68 closed - U1

So from the looks of it, the bind credentials aren't being passed right.  I'm 
not sure why they get lost in between.  Also, why should the directory throw a 
objectclass violation ..but that's a different story meant of a different bug 
tracking system. I'm using 4.15 iplanet directory.

regards,
bemtya joshi.

Comment 1

[Mark Smith [:mcs]]

Reassigned to Miodrag, one of the LDAP JDK engineers.

Comment 2

[Mark Smith [:mcs]]

Really reassiging to Miodrag this time!

Comment 3

[rweltman]

The add is failing because LDAPModify is being called with the -a flag (treat
all entries as data to be added) while the LDIF file contains an explicit
changetype instruction. You should use one or the other. The C version of
ldapmodify allows you to override the -a flag with explicit changetype
instructions while the Java version doesn't. The Java version could be altered
to also allow overrides, but that goes beyond what it has been specified to do.
I'm changing the severity from "critical" to "enhancement" and the priority from
"-" to "P4".

Comment 4

[rweltman]

Changed summary from "LDAPModify fails with basic inetOrgPerson entry." to
"'LDAPModify -a' fails if the LDIF file contains changetype fields".

Comment 5

[Frankie]

Spam for bug 129472

Comment 6

[Mark Smith [:mcs]]

Reassign LDAP JDK bugs owned by Miodrag ([e-mail]) to
E-Y ([e-mail])

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Not activity for at least 6 years, closing.