Re: BUG? add() fails with resultCode=>32, errorMessage=>''

Thank you both for this clarification -

It was my mistake, in that when I tried to do:

1:     $ldap->add( 'cn='.$myUserObject{cn}.',uid='.${myUserObject}{uid}.',o=att.com', $myUserObject) # FAILS 

As Dieter explains, " the superior distinguished name of the new entry does not exist " 
(ie. cn=$UserName,uid=$UserId,o=att.com), whereas with :

2:     $ldap->add( 'uid='.${myUserObject}{uid}.',o=att.com', $myUserObject) # SUCCEEDS

The superior DN (o=att.com) does exist. 

What confused me is that when I list user objects their DNs all print out as
       "cn=$user_name,uid=$user_id,o=att.com" ;
I thought that "cn" is just an attribute as is "uid", and by definition, when creating
a new object, the object that contains cn and uid does not exist ? So I still don't 
quite understand the difference. 

So it seems the Net::LDAP issue (very minor bug) is that in case 1 above, 
Net::LDAP gets this response:

"
LDAP::process
Net::LDAP=HASH(0xca22c0) received:23 bytes

30 15 02 01 02 69 10 0A 01 20 04 09 6F 3D 61 74 0....i... ..o=at
74 2E 63 6F 6D 04 00 __ __ __ __ __ __ __ __ __ t.com..

0000   21: SEQUENCE {
0002    1:   INTEGER = 2
0005   16:   [APPLICATION 9] {
0007    1:     ENUM = 32
000A    9:     STRING = 'o=att.com'
0015    0:     STRING = ''
0017     :   }
0017     : }
"

And Net::LDAP returns an error status mesg with "resultCode=>32" for the case #1 add() ; 
$VAR1 = bless( {
                 'parent' => bless( {
                                      'net_ldap_version' => 3,
                                      'net_ldap_scheme' => 'ldap',
                                      'net_ldap_debug' => 1,
                                      'net_ldap_socket' => bless( \*Symbol::GEN1, 'IO::Socket::INET' ),
                                      'net_ldap_onerror' => sub { "DUMMY" },
                                      'net_ldap_host' => 'localhost',
                                      'net_ldap_uri' => 'localhost',
                                      'net_ldap_resp' => {},
                                      'net_ldap_mesg' => {},
                                      'net_ldap_async' => 0,
                                      'net_ldap_port' => '389',
                                      'net_ldap_refcnt' => 1
                                    }, 'Net::LDAP' ),
                 'errorMessage' => '',
                 'ctrl_hash' => undef,
                 'resultCode' => 32,
                 'callback' => undef,
                 'mesgid' => 2,
                 'matchedDN' => 'o=att.com',
                 'controls' => undef,
                 'raw' => undef
               }, 'Net::LDAP::Add' );

but I think it should also be returning an "errorMessage=>'no such object'" in this case, 
whereas it returned an empty string in errorMessage - an error string would have greatly 
helped in diagnosing the problem and correcting my mistake.

Thanks & Regards,

Jason

On Friday 17 October 2008 08:28:42 Dieter Kluenter wrote:
> Jason Vas Dias <[email protected]> writes:
> 
> > Please excuse me if I am misunderstanding something (I'm an LDAP newbie) - 
> > but is this a Net::LDAP bug:
> >
> > Supplying an extra attribute to the "dn" of a Net::LDAP::add request,
> > as with:
> >
> >    $ldap->add( 'cn='.$myUserObject{cn}.',uid='.${myUserObject}{uid}.',o=att.com', $myUserObject) # FAILS 
> >
> > results in an error response with an error code of 32 and an empty error 
> > message - while removing the "cn=" portion of the DN allows the add to succeed:
> >
> >    $ldap->add( 'uid='.${myUserObject}{uid}.',o=att.com', $myUserObject) # SUCCEEDS
> >
> > It seems to me that if the "FAILS" request contains a bad DN, Net::LDAP ought to
> > detect this and report a "Bad DN" error message, as it does for other types of bad dn .
> 
> Error code 32 is 'no such object', that is, the superior distinguished
> name of the new entry does not exist. For more information RFC-4511,
> section 4.1.9 Result Message. In your particular case you want to add
> an object
> dn: cn=some user,uid=some user,o=att.com
> but the superior object of this DN 'uid=some user,o=att.com' does not
> exist. The error is not Net::LDAP related but due to poor tree design.
> You should probably read
> http://www.openldap.org/doc/admin24/
> and some basics on how to design a directory tree and directory
> objects.
> 
> -Dieter
> 
> -- 
> Dieter Klünter | Systemberatung
> http://www.dpunkt.de/buecher/2104.html
> GPG Key ID:8EF7B6C6
> 53°08'09,95"N
> 10°08'02,42"E

On Friday 17 October 2008 10:24:51 Graham Barr wrote:
> On Oct 16, 2008, at 6:46 PM, Jason Vas Dias wrote:
> > Please excuse me if I am misunderstanding something (I'm an LDAP  
> > newbie) -
> > but is this a Net::LDAP bug:
> >
> > Supplying an extra attribute to the "dn" of a Net::LDAP::add request,
> > as with:
> >
> >   $ldap->add( 'cn='.$myUserObject{cn}.',uid='.${myUserObject} 
> > {uid}.',o=att.com', $myUserObject) # FAILS
> >
> > results in an error response with an error code of 32 and an empty  
> > error
> > message - while removing the "cn=" portion of the DN allows the add  
> > to succeed:
> 
> What code were you using to get the error message ? In you example you  
> are not capturing the response.
> 
> It does look like your server is returning an empty message, but if  
> you use
> 
> 
>    $mesg = $ldap->add( ....
> 
>    warn $mesg->error if $mesg->code;
> 
> you should see
> 
>    "No such attribute"
> 
> Graham.
> 
>