Thanks, Ray. That's what I'm doing as a hack internally to make it work as it
should. In the application I map batch requests to change values directly to
attributes however, and I didn't want to have to impose
'facsimiletelephonenumber' instead of 'fax' on my users.

--ted

Ray Cormier wrote:

> As stated in many places you should always use the actual attribute name and
> not the canonical names.
>
> "Ted Markowitz" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Folks,
> >
> > I'm writing a batch user provisioning tool in perl using perldap 1.4.1
> > and the 4.14 NS LDAP C SDK with iDS 4.13 on Win2K. While tidying up my
> > ADDATTRIBUTE routine, which as you'd guess adds an attribute value to a
> > user's entry,  I noticed something quite odd in the output from some
> > runs. When adding multiple test values for the "fax" attribute (which is
> > multivalued and a legit alias for "facsimiletelephonenumber" in
> > slap.at.conf) to the same user's entry, only the last "fax" value
> > remained after the processing was done.  However, if I used
> > "facsimiletelephonenumber" instead as the attribute name in the same
> > perldap "addValue" call and left everything else identical, then the
> > multiple "facsimiletelephonenumber" attributes were added just fine.
> > Looking at the OID's for the 2 attributes in the iPlanet Admin Console
> > shows that they are indeed the same for the 2 attributes.
> >
> > It appears that if I used "fax" as the attribute name rather than
> > "facsimiletelephonenumber", something outside of my code was changing
> > the LDAP add to an LDAP replace and thus only one fax # value was left
> > in the entry at the end. Here are two excerpts from the iDS audit log
> > which shows this . The 1st used "facsimiletelephonenumber" and the 2nd
> > used "fax" in the perldap "addValue" call...
> >
> >
> >      time: 20010924143347
> >      dn:
> >
> ehsguid=2cfce1e9-11ae-4192-8725-0ad14266dd8a,ou=people,o=xyz.com,o=beta,o=ab
> c
> >
> >      changetype: modify
> >      add: facsimiletelephonenumber
> >      facsimiletelephonenumber: 516-555-5555
> >      -
> >      replace: modifiersname
> >      modifiersname: cn=Directory Manager
> >      -
> >      replace: modifytimestamp
> >      modifytimestamp: 20010924183347Z
> >      -
> >
> >
> >
> >      time: 20010924143645
> >      dn:
> >
> ehsguid=2cfce1e9-11ae-4192-8725-0ad14266dd8a,ou=people,o=xyz.com,o=beta,o=ab
> c
> >
> >      changetype: modify
> >      replace: facsimiletelephonenumber
> >      facsimiletelephonenumber: 516-555-5555
> >      -
> >      replace: modifiersname
> >      modifiersname: cn=Directory Manager
> >      -
> >      replace: modifytimestamp
> >      modifytimestamp: 20010924183645Z
> >      -
> >
> > Has anyone seen this before? I'm inclined to think that something is
> > funky in the attribute alias handling code in perldap or in the LDAP SDK
> > itself. Any clues or thoughts would be appreciated.
> >
> > Thanks.
> >
> > --ted
> >  _______________________________________________
> > |          C O G N O S Y S   L L C
> > |
> > | Ted Markowitz
> > | Chief Architect
> > | 10 Hamilton Lane, Darien, CT 06820_2809
> > |
> > | 203.984.6565 (phone)  mailto:[EMAIL PROTECTED]
> > | 203.655.7746 (fax)    http://www.cognosys.net
> >  _______________________________________________
> >
> >
begin:vcard 
n:Markowitz;Ted
tel;cell:203-984-6565
tel;fax:203-655-7746
tel;work:203-655-7746
x-mozilla-html:TRUE
url:http://www.cognosys.net
org:Cognosys LLC
version:2.1
email;internet:[EMAIL PROTECTED]
title:Chief Architect
adr;quoted-printable:;;10 Hamilton Lane=0D=0A;Darien;CT;06820;USA
fn:Ted Markowitz
end:vcard

Reply via email to