Re: [389-users] entryrdn-index error message in error log

[Noriko Hosoi <nhosoi@xxxxxxxxxx>]

Thank you so much for the update, Andrey.  You eliminated one of our concerns!  (Of course, there are plenty more. ;)
--noriko

On 08/25/2010 12:44 PM, Andrey Ivanov wrote:

Well, i've sorted out this problem. Rich has pointed out that it's an html/xml escape. He was right. Since i was working on our production servers there were some requests constantly coming in. I've searched through the access logs and found that the source of the problem is a broken web application  that requests an incorrect DN :

[25/Aug/2010:21:25:21 +0200] conn=4201 op=1 SRCH base="cn=cadre d&#039,astreinte,ou=objets,dc=id,dc=polytechnique,dc=edu" scope=0 filter="(&(&(objectClass=X-Object)(ou=*)))" attrs="* modifyTimestamp"
[25/Aug/2010:21:25:21 +0200] conn=4201 op=1 RESULT err=32 tag=101 nentries=0 etime=0.002000

These requests generate the messages i've seen in error log :
[25/Aug/2010:21:25:21 +0200] entryrdn-index - entryrdn_index_read: Param error: Failed to convert cn=cadre d&#039,astreinte,ou=objets,dc=id,dc=polytechnique,dc=edu to Slapi_RDN
[25/Aug/2010:21:25:21 +0200] - dn2entry: Failed to get id for cn=cadre d&#039,astreinte,ou=objets,dc=id,dc=polytechnique,dc=edu from entryrdn index (34)
[25/Aug/2010:21:25:21 +0200] entryrdn-index - entryrdn_index_read: Param error: Failed to convert astreinte,ou=objets,dc=id,dc=polytechnique,dc=edu to Slapi_RDN

So there is no problem in the server code, it's a broken application. It applies to both 6rc7  and 7rc1 versions of course. The reason why i thought there was no problem in rc7 case is that i've made the tests with rc7 at 21h00, at this time there were no users and so no requests from the above-mentioned application :))
I was alarmed because on our servers there are very few error messages in error logs and i know them all. This sort of error message (incorrect DN or filter in ldap search requests) was not logged in previous 389 versions, it's a behavour change... 

So the only thing that i should look into is the server crash during SSL incremental replication in the current git version.

2010/8/25 Noriko Hosoi <nhosoi@xxxxxxxxxx>
>
>  On 08/25/2010 10:44 AM, Rich Megginson wrote:
>>
>> Noriko Hosoi wrote:
>>>
>>>  Hi Andrey,
>>>
>>> Looking at this line,&#039, is not a UTF-8 representation of
>>> apostrophe.  Rather a Latin-1 representation?  Also, it contains ','
>>> in the rdn value without an escape.  It's considered a separator
>>> between rdns. I wonder who created the input DN...?
>>>
>>> entryrdn-index - entryrdn_index_read: Param error: Failed to convert
>>> cn=salon d&#039,honneur,ou=objets,dc=id,dc=polytechnique,dc=edu to
>>> Slapi_RDN
>>>
>> &#039, looks like some sort of html/xml escape?
>> http://www.theukwebdesigncompany.com/articles/entity-escape-characters.php
>
> Thanks, Rich!  You are right!  And I don't think our DN normalizer supports it.
>
> Andrey, what you observe is ...
> 389 v1.2.6.rc7 has no problem to handle cn=salon d&#039,honneur, but 1.2.7.a1 does?
>
> We haven't touched the normalizer between 1.2.6.rc7 and 1.2.7.a1, I think...
> --noriko
>>>
>>> Thanks,
>>> --noriko
>>>
>>> On 08/25/2010 08:35 AM, Andrey Ivanov wrote:
>>>>
>>>> Hi,
>>>>
>>>> i'm continuing to test the latest version of 389. Here are the error
>>>> messages that i've seen (it happened only once for now) in error log :
>>>>
>>>> [25/Aug/2010:17:21:10 +0200] entryrdn-index - entryrdn_index_read:
>>>> Param error: Failed to convert cn=salon
>>>> d&#039,honneur,ou=objets,dc=id,dc=polytechnique,dc=edu to Slapi_RDN
>>>> [25/Aug/2010:17:21:10 +0200] - dn2entry: Failed to get id for
>>>> cn=salon d&#039,honneur,ou=objets,dc=id,dc=polytechnique,dc=edu from
>>>> entryrdn index (34)
>>>> [25/Aug/2010:17:21:10 +0200] entryrdn-index - entryrdn_index_read:
>>>> Param error: Failed to convert
>>>> honneur,ou=objets,dc=id,dc=polytechnique,dc=edu to Slapi_RDN
>>>> [25/Aug/2010:17:21:10 +0200] - dn2entry: Failed to get id for
>>>> honneur,ou=objets,dc=id,dc=polytechnique,dc=edu from entryrdn index (34)
>>>>
>>>>
>>>> The object in question is
>>>> cn=SALON D'HONNEUR,ou=Objets,dc=id,dc=polytechnique,dc=edu
>>>> departmentNumber: DG/SG/MG/REST
>>>> objectClass: top
>>>> cn: SALON D'HONNEUR
>>>>
>>>> What is the problem with this entry, conversion to Slapi_DN and
>>>> entryrdn index? Here are the
>>>> corresponding entries extracted with dbscan :
>>>>
>>>> 5370:cn=salon d'honneur
>>>>    ID: 5370; RDN: "cn=SALON D'HONNEUR"; NRDN: "cn=salon d'honneur"
>>>>
>>>> C3106:ou=objets
>>>>    ID: 5370; RDN: "cn=SALON D'HONNEUR"; NRDN: "cn=salon d'honneur"
>>>>
>>>> P5370:cn=salon d'honneur
>>>>    ID: 3106; RDN: "ou=Objets"; NRDN: "ou=objets"
>>>>
>>>>
>>>>
>>>> I have not made any upgrades of the existing server. Instead, i have
>>>> exported the ldif by db2ldif and then imported it into the new server,
>>>> so there was no conversion phase.
>>>>
>>>>
>>>> Andrey Ivanov
>>>> tel +33-(0)1-69-33-99-24
>>>> fax +33-(0)1-69-33-99-55
>>>>
>>>> Direction des Systemes d'Information
>>>> Ecole Polytechnique
>>>> 91128 Palaiseau CEDEX
>>>> France
>>>>
>>>> --
>>>> 389 users mailing list
>>>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>> ------------------------------------------------------------------------
>>>
>>> --
>>> 389 users mailing list
>>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>> --
>> 389 users mailing list
>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
> --
> 389 users mailing list
> 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

<<attachment: smime.p7s>>

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users