[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Odd Error
Thanks again Ace. I'd happily work on a short 1-2 page totorial if I understood LDAP schema more. I'd just like to understand the meaning of all of the different elements of an attributetype or objectclass definition. I'd happily write up a summary of these if I knew the meaning of each element and how the SYNTAX inheritance worked.
Here's my general issue:
Basically we moved from an old version of OpenLDAP provided by our mail server vendor (Mirapoint) and in that server the core.schema defines
attributetype ( 2.5.4.23 NAME ( 'facsimileTelephoneNumber' 'fax' )
EQUALITY telephoneNumberMatch
SUBSTR telephoneNumberSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
In the OpenLDAP 2.1.25 schema we find
attributetype ( 2.5.4.23 NAME ( 'facsimileTelephoneNumber' 'fax' )
DESC 'RFC2256: Facsimile (Fax) Telephone Number'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
Interestingly enough the equality matching rule has been removed in the new version.
Some existing code which wasn't ours in the first place and is actually in the process of being replaced, requires that we specify a facsimileTelephoneNumber to it for it to update LDAP for a particular user. The problem is that the part of our application that calls this code doesn't know the proper value for facsimileTelephoneNumber and so passes "" (empty string). The offending code notices that "" is different than the current value and tries to ldap_modify the entry using the code below which, for some reason, apparently doesn't replace the existing value of facsimileTelephoneNumber and ends up being a no-op. It basically tries to add the value of an empty string. When we moved to OpenLDAP 2.1.25 the offending code now breaks because the new schema doesn't allow a value of "" for facsimileTelephoneNumber. I can't update the core.schema to specify an equality matching rule for facsimileTelephoneNumber (bad practice I know but we're reworking all of our mail/LDAP stuff in the next 3 months and this is a temporary patch) because I get the following error and slapd won't start:
/apps/openldap/2.1.25/etc/openldap/schema/core.schema: line 143: AttributeType inappropriate matching rule: "telephoneNumberMatch"
This must have something to do with inheritance of the facsimileTelephoneNumber from some other attribute definition via the SYNTAX clause (which I don't really understand yet) or some of the basic core.schema values are hard-coded in the server (fine, it's RFC compliant and we're not).
Any thoughts on getting around this?
<offending code>
function ldap_modifyentry ($entrydn, $newattribute_ar, $newattribute_list, $fail
ure_ar, $err_msg = "")
{
axlog (4, __FILE__, __LINE__, "Function: ldap_modifyentry, start. (passed: $
entrydn, $newattribute_ar, $newattribute_list, $failure_ar, $err_msg)");
global $LDAPhost, $LDAPport, $LDAPsbase, $LDAPBindDn, $LDAPDnPW, $LDAPrules,
$LDAP_err_msg, $LDAP_err_no;
#START debug
reset ($newattribute_ar);
while (strlen(key($newattribute_ar)))
{
$dbgKey = key($newattribute_ar);
$dbgValCnt = count($newattribute_ar[$dbgKey]);
# axlog (4, __FILE__, __LINE__, "Function:ldap_modifyentry:debug:count(newa
ttribute_ar[$dbgKey])=$dbgValCnt");
for($dbgValI=0; $dbgValI < $dbgValCnt; $dbgValI++)
{
$dbgVal = $newattribute_ar[$dbgKey][$dbgValI];
if (is_null($dbgVal))
{
$dbgVal = 'NULL';
}
else
{
$dbgVal = "'$dbgVal'";
}
axlog (4, __FILE__, __LINE__, "Function:ldap_modifyentry:debug:newattrib
ute_ar['$dbgKey']=$dbgVal");
} #end for ...
next($newattribute_ar);
} #end while..
#END debug
#initialise global LDAP_err_msg
$LDAP_err_msg="";
$LDAP_err_no="";
$returncode = 0;
$li = ldap_connect_ext ();
if ($li) {
$br = ldap_bind_ext ($li);
if ($br) {
$modifystatus = ldap_modify ($li, $entrydn, $newattribute_ar);
$LDAP_err_msg=ldap_error($li);
$LDAP_err_no=ldap_errno($li);
if ($modifystatus)
$returncode = 1;
}
else {
axlog (1, __FILE__, __LINE__, "Function: ldap_modifyentry, end. Could
not bind to LDAP server");
$LDAP_err_msg=ldap_error($li);
$LDAP_err_no=ldap_errno($li);
}
}
else {
axlog (1, __FILE__, __LINE__, "Function: ldap_modifyentry, end. Could not
connect to LDAP server");
}
if(strlen($LDAP_err_msg))
axlog (4, __FILE__, __LINE__, "Function:ldap_modifyentry:LDAP_err_msg=$LDA
P_err_msg");
axlog (4, __FILE__, __LINE__, "Function: ldap_modifyentry, end. (returned: $
returncode)");
return $returncode;
}
</offending code>
-----Original Message-----
From: Ace Suares [mailto:ace@suares.nl]
Sent: Tuesday, January 06, 2004 4:33 AM
To: James Courtney
Subject: Re: Odd Error
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi James,
> Thanks Ace,
> I suppose I should have been more clear in that I was trying to understand
> the meaning of add/delete vs. replace WRT the ldap_modify PHP API call when
> using single and two dimensional arrays for multi-valued attributes.
I think, you should never have to use single arrays, always use 2 dimensional,
as pointed out in my comment at the php.net site.
> Thanks for the useful links. I think I need to not have the attribute be
> the empty string. You don't happen to know where I can find a good
> schema/syntax tutorial do you? Thanks again!
No, schema/syntax is difficult for me too. We can write such a tutorial if you
have spare time :-)
In general, when you have an entry with atributes:
a=1
b=2
b=3
c=4
and you want to modify this to
a=2
c=3
then you need following php array:
array(
"a" => array( "2"),
"b" => array( ),
"c" => array( "3")
)
Note that attribute b will be deleted completely (if it has MAY in the
objectcalss definition ! Else error !) by passing an emopty array (not an
empty string) to ldap_modify.
Cheers,
ace
>
> Jamey
>
>
> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Ace Suares
> Sent: Monday, January 05, 2004 10:23 PM
> To: openldap-software@OpenLDAP.org
> Subject: Re: Odd Error
>
> > An add operation creates an attribute/value pair, a delete operation
> > removes an attribute/value pair, and a replace operation changes
> > attribute/value1 to attribute/value2
>
> True, by definition.
>
> > > Is the update to an empty string equivalent to an update to NULL (in
> > > SQL speak) in OpenLDAP?
> >
> > No, No, and No. There is no NULL in LDAP, and no equivalent.
>
> Not neccessarily, as discussed in
> http://www.openldap.org/lists/openldap-software/200312/msg00158.html
>
> > > Is the update to an empty string causing a problem vs. just removing
> > > the attribute?
> >
> > Remove the attribute. If it formerly had a value and does not now
> > (string length 0) you want a delete operation.
>
> See also
> http://www.openldap.org/lists/openldap-software/200312/msg00166.html
> and
> http://www.php.net/manual/en/function.ldap-modify.php
>
>
> As to your original question, I don't have the answer to it.
>
> _Ace
>
> website: http://www.suares.nl * http://www.qwikzite.nl
- --
Ace Suares' Internet Consultancy
NIEUW ADRES: Postbus 2599, 4800 CN Breda
telefoon: 06-244 33 608
fax en voicemail: 0848-707 705
website: http://www.suares.nl * http://www.qwikzite.nl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
iD8DBQE/+qsHy7boE8xtIjURAhcxAJsF8eDjRpwdgrL+pHPWFc+gtSd2bACeN3Py
m4xMcGa898HpSURTnHgkhLI=
=ceqU
-----END PGP SIGNATURE-----