I posted to the LDAP software list to find more information on this and
also enabled more debugging in my ldap server. It seems that there is a
bug of sorts that requires that content sync controls have the critical
flag set to 0. So I did this and the server is responding as expected
now. However a new problem has arisen.
It seems that the perl client is unable to decode the message(s) sent
back from the server.
Here is the full debug output:
> perl persist_search.pl
0
\uffff
Net::LDAP=HASH(0x831532c) sending:
BIND DEBUGGING REMOVED
Success
DOING SEARCH
Net::LDAP=HASH(0x831532c) sending:
30 81 A0 02 01 02 63 73 04 1C 64 63 3D 64 69 72 0.....cs..dc=dir
65 63 74 6F 72 79 2C 64 63 3D 73 65 6E 74 6F 2C ectory,dc=sento,
64 63 3D 63 6F 6D 0A 01 02 0A 01 00 02 01 00 02 dc=com..........
01 00 01 01 00 A3 11 04 03 75 69 64 04 0A 6C 65 .........uid..le
65 5F 6A 65 6E 73 65 6E 30 31 04 01 2A 04 0B 6F e_jensen01..*..o
62 6A 65 63 74 43 6C 61 73 73 04 15 73 74 72 75 bjectClass..stru
63 74 75 72 61 6C 4F 62 6A 65 63 74 43 6C 61 73 cturalObjectClas
73 04 08 65 6E 74 72 79 43 53 4E A0 26 30 24 04 s..entryCSN.&0$.
18 31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 34 32 30 .1.3.6.1.4.1.420
33 2E 31 2E 39 2E 31 2E 31 04 08 30 06 0A 01 03 3.1.9.1.1..0....
01 01 FF __ __ __ __ __ __ __ __ __ __ __ __ __ ...
0000 160: SEQUENCE {
0003 1: INTEGER = 2
0006 115: [APPLICATION 3] {
0008 28: STRING = 'dc=directory,dc=sento,dc=com'
0026 1: ENUM = 2
0029 1: ENUM = 0
002C 1: INTEGER = 0
002F 1: INTEGER = 0
0032 1: BOOLEAN = FALSE
0035 17: [CONTEXT 3] {
0037 3: STRING = 'uid'
003C 10: STRING = 'lee_jensen'
0048 : }
0048 49: SEQUENCE {
004A 1: STRING = '*'
004D 11: STRING = 'objectClass'
005A 21: STRING = 'structuralObjectClass'
0071 8: STRING = 'entryCSN'
007B : }
007B : }
007B 38: [CONTEXT 0] {
007D 36: SEQUENCE {
007F 24: STRING = '1.3.6.1.4.1.4203.1.9.1.1'
0099 8: STRING
009B : 30 06 0A 01 03 01 01 FF __ __ __ __ __ __ __ __
0.......
00A3 : }
00A3 : }
00A3 : }
Net::LDAP=HASH(0x831532c) received:
FULL ENTRY INFORMATION REMOVED FOR SPACE
Net::LDAP=HASH(0x831532c) received:
30 49 02 01 02 79 44 8A 18 31 2E 33 2E 36 2E 31 0I...yD..1.3.6.1
2E 34 2E 31 2E 34 32 30 33 2E 31 2E 39 2E 31 2E .4.1.4203.1.9.1.
34 8B 28 A2 26 04 24 63 73 6E 3D 32 30 30 35 30 4.(.&.$csn=20050
33 31 31 32 32 31 36 35 39 5A 23 30 30 30 30 30 311221659Z#00000
31 23 30 30 23 30 30 30 30 30 30 __ __ __ __ __ 1#00#000000
0000 73: SEQUENCE {
0002 1: INTEGER = 2
0005 68: [APPLICATION 25] {
0007 24: [CONTEXT 10]
0009 : 31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 34 32 30 33
1.3.6.1.4.1.4203
0019 : 2E 31 2E 39 2E 31 2E 34 __ __ __ __ __ __ __
__ .1.9.1.4
0021 40: [CONTEXT 11]
0023 : A2 26 04 24 63 73 6E 3D 32 30 30 35 30 33 31
31 .&.$csn=20050311
0033 : 32 32 31 36 35 39 5A 23 30 30 30 30 30 31 23 30
221659Z#000001#0
0043 : 30 23 30 30 30 30 30 30 __ __ __ __ __ __ __ __
0#000000
004B : }
004B : }
PAST SEARCH
decode error
at /usr/local/lib/perl5/site_perl/5.8.6/Convert/ASN1/_decode.pm line
230, <DATA> line 461.
1
Entering while
Some relevant log lines from slapd:
Mar 14 08:10:50 critter slapd[8376]: bdb_search_candidates: id=1
first=1666 last=1666
Mar 14 08:10:50 critter slapd[8376]: => send_search_entry:
dn="cn=lee_jensen,ou=Sento,ou=Users,dc=directory,dc=sento,dc=com"
Mar 14 08:10:50 critter slapd[8376]: <= send_search_entry
Mar 14 08:10:50 critter slapd[8376]: send_ldap_intermediate: err=0
oid=1.3.6.1.4.1.4203.1.9.1.4 len=40
Mar 14 08:10:50 critter slapd[8376]: send_ldap_response: msgid=2 tag=121
err=0
Below is the code that generates this:
$buf = $asn->encode(
mode => 3,
cookie => undef,
reloadHint => false
) or die;
print $buf, "\n";
$ctrl = Net::LDAP::Control->new(
type => '1.3.6.1.4.1.4203.1.9.1.1',
value => $buf,
critical => 0
);
$ldap = Net::LDAP->new('critter', debug => -1);
$ret = $ldap->bind('cn=slave_search,dc=directory,dc=sento,dc=com',
password => '[EMAIL PROTECTED]'
);
print $ret->error(), "\n";
print "DOING SEARCH\n";
$s = $ldap->search( base => 'dc=directory,dc=sento,dc=com',
scope => 'sub',
filter => '(uid=lee_jensen)',
attrs => [ '*', 'objectClass', 'structuralObjectClass',
'entryCSN' ],
deref => 'never',
control => [ $ctrl ]
);
print "PAST SEARCH\n";
print $s->error(), "\n";
print $s->count(),"\n";
print values %{$s->control()},"\n";
print "Entering while\n";
while ($ent = $s->pop_entry) {
...do stuff
}
The module seems to die when trying to parse the following intermediate
response message:
oid=1.3.6.1.4.1.4203.1.9.1.4
This OID refers to a message defined as follows in the RFC
The Sync Info Message is an LDAP Intermediate Response Message
[LDAPIRM] where responseName is the object identifier
1.3.6.1.4.1.4203.1.9.1.4 and responseValue contains a BER-encoded
syncInfoValue. The criticality is FALSE (and hence absent).
syncInfoValue ::= CHOICE {
newcookie [0] syncCookie,
refreshDelete [1] SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDone BOOLEAN DEFAULT TRUE
},
refreshPresent [2] SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDone BOOLEAN DEFAULT TRUE
},
syncIdSet [3] SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDeletes BOOLEAN DEFAULT FALSE,
syncUUIDs SET OF syncUUID
}
}
If anyone has some knowledge of the modules internals and could perhaps
give a cursory overview of how to modify it to accept these kind of
response messages I would appreciate it. Also in this refresh and
persist mode the server responds with a control for every entry
returned. Could the entry class be made to inherit from the message
class so controls can be retrieved from it?
Thanks for your help.
Lee
On Fri, 2005-03-11 at 13:31 -0600, Kurt D. Zeilenga wrote:
> At 09:32 AM 3/11/2005, Lee Jensen wrote:
> >When I print out $s->error() I get "control unavailable in context"
>
> This implies that the server is unwilling or unable
> to make use of the control in the particular context
> (e.g., database) that the target object is within.
> That is, you aren't using a database that supports
> the control.
>
> Kurt
>
