meta directory backend and rewriting option '|'
Hello! I have a question concerning the pipe option '|' when using the meta directory backend and rewriting. In the manual pages the '|' option is marked as not implemented. Does this reflect the actual state of the software or has somebody just forgotten to update the man page? Regards, Hartmut
Re: Q: status of component matching?
Hi all! I have debugged a little bit more and discovered that the decoding of the ANY type of the Algorithm parameter (that in fact is the Null) fails; in the BDecComponentAny function (file contrib/slapd-modules/comp_match/componentlib.c) the pointer result-cai is the NULL pointer, so no function to decode the parameter is defined. Can anybody help? Regards, Hartmut
Re: Q: status of component matching?
Hi all!
To avoid the slapd's core dump when using component match filters (see
ITS # 6556) I removed line 556 of file servers/slapd/filter.c:
case LDAP_FILTER_EXT:
//mra_free( op, f-f_mra, 1 );
break;
Now component match filter search requests are answered by slapd but
don't work correctly. In fact nothing is found! For example the request
/home/openldap/openldap-2.4.21-install/bin/ldapsearch -h localhost -p
9389 -D cn=openldapadmin -w welcome -b o=CustomerCA,c=de -s sub
(userCertificate:componentFilterMatch:=item:{ component
\toBeSigned.serialNumber\, rule allComponentsMatch, value 449 })
sncertnr
Is answered with
# extended LDIF
#
# LDAPv3
# base o=CustomerCA,c=de with scope subtree
# filter: (userCertificate:componentFilterMatch:=item:{ component
toBeSigned.serialNumber, rule allComponentsMatch, value 449 })
# requesting: sncertnr
#
# search result
search: 2
result: 0 Success
# numResponses: 1
But in the database of slapd there are several certificates with
serialNumber 449:
lehnert.hart...@sn-ocspr4:/opt/lehnert/Openldap-Support$ ./dumpasn1
449.cer
0 30 702: SEQUENCE {
4 30 551: SEQUENCE {
8 A03: [0] {
10 021: INTEGER 2
: }
13 022: INTEGER 449
17 30 13: SEQUENCE {
19 069: OBJECT IDENTIFIER
: sha256WithRSAEncryption (1 2 840 113549 1 1 11)
30 050: NULL
: }
32 30 111: SEQUENCE {
34 31 11: SET {
36 309: SEQUENCE {
38 063: OBJECT IDENTIFIER countryName (2 5 4 6)
43 132: PrintableString 'DE'
: }
: }
47 31 12: SET {
On slapd's side the debug message
bdb_search: integer does not match filter
is written out for every record.
What's going wrong here?
Regards,
Hartmut
AW: Q: status of component matching?
Hi Dieter! ulimit -c is set to unlimited. No core file is produced. The actual problem is that the slapd terminates (normally) because it detects the undefined function GenBufFreeBuf (that is called from whithin init.c) when using functionality from the comp match module. The problem is not: who calles GenBufFreeBuf, but: where is it defined? In the actual snacc and comp match module source code GenBufFreeBuf is defined NOWHERE!!! So I need the source code for GenBufFreeBuf function to prevent slapd from terminating when it calls into the comp match module. Regards, Hartmut -Ursprüngliche Nachricht- Von: openldap-technical-bounces+hartmut.lehnert=secunet@openldap.org [mailto:openldap-technical-bounces+hartmut.lehnert=secunet@openldap.org] Im Auftrag von Dieter Kluenter Gesendet: Mittwoch, 26. Mai 2010 12:48 An: openldap-technical@openldap.org Betreff: Re: Q: status of component matching? Lehnert, Hartmut hartmut.lehn...@secunet.com writes: Hi Dieter! I built slapd and the comp match module with CFLAGS=-g option but a core dump isn't generated. I don't think that a core dump analysis is necessary to solve the problem because the slapd output You may have to call ulimit -c unlimited in order to create a core dump. /home/openldap/openldap-2.4.21-install/libexec/slapd: symbol lookup error: /home/openldap/openldap-2.4.21-install/libexec/openldap/compmatch.so.0: undefined symbol: GenBufFreeBuf is clear enough: the symbol GenBufFreeBuf is simply missing in the source code and binary of the comp match module. So once again: do you know where I can get the missing source code? As I mentioned, GenBufFreeBuf is called in comp_match/init.c -Dieter -- Dieter Klünter | Systemberatung sip: +49.40.20932173 http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6
AW: use of server-side sorting and virtual list view controlsblocksslapd
Hello Dieter! I got the error serverSort control: No ordering rule before I altered the LDAP schema adding an ordering rule: attributetype ( OCSP-R-LDAP-attributetype:10 NAME 'SNcertNr' DESC 'secunet OCSP-R-LDAP-attributetype:10' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) After receiving 10 entries on client side I press enter but after that the client immediately outputs the sizelimit exceeded stuff. It doesn't matter if I mark the extensions as critical or not: the effect remains the same (sizelimit exceeded). Regards, Hartmut -Ursprüngliche Nachricht- Von: openldap-technical-bounces+hartmut.lehnert=secunet@openldap.org [mailto:openldap-technical-bounces+hartmut.lehnert=secunet@openldap.org] Im Auftrag von Dieter Kluenter Gesendet: Mittwoch, 26. Mai 2010 18:37 An: openldap-technical@openldap.org Betreff: Re: use of server-side sorting and virtual list view controlsblocksslapd Lehnert, Hartmut hartmut.lehn...@secunet.com writes: Hi Dieter! I use the search command /home/openldap/openldap-2.4.21-install/bin/ldapsearch -h localhost -p 9389 -D cn=openldapadmin -w welcome -b o=CustomerCA,c=de -s sub -E!sss=sncertnr -E!vlv=0/9/0/1:objectclass=SN-ISIS-MTT-MainCert sncertnr I just wonder that you don't get an error, something like: result: 18 Inappropriate matching text: serverSort control: No ordering rule because you don't provide an ordering rule for sncertnr On client side this looks like as follows: # extended LDIF # # LDAPv3 # base o=CustomerCA,c=de with scope subtree # filter: (objectclass=*) # requesting: sncertnr # with server side sorting critical control # with virtual list view critical control: 0/9/0/1 # # R\C3\BCger OttoSER:9000, testsuite, CustomerCA, de dn:: Y249UsO8Z2VyIE90dG9TRVI6OTAwMCxvdT10ZXN0c3VpdGUsbz1DdXN0b21lckNBLGM9ZGU= SNcertNr: 9000 [SNcertNr: from 9001 to 9008] # R\C3\BCger OttoSER:9009, testsuite, CustomerCA, de dn:: Y249UsO8Z2VyIE90dG9TRVI6OTAwOSxvdT10ZXN0c3VpdGUsbz1DdXN0b21lckNBLGM9ZGU= SNcertNr: 9009 # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.474 false MAMKAQA= sortResult: (0) Success control: 2.16.840.1.113730.3.4.10 false MA8CAQACAQwCAQAEBBD9LAg= vlvResult: pos=0 count=12 context=EP0sCA== (0) Success # numResponses: 11 # numEntries: 10 Press [before/after(/offset/count|:value)] Enter for the next window. According to your virtual view values you require 9 entries, out of 12 and you recieved 10 Did you press Return in oder to present the next entries out of a total of 12? # extended LDIF # # LDAPv3 # base o=CustomerCA,c=de with scope subtree # filter: (objectclass=*) # requesting: sncertnr # with server side sorting critical control # with virtual list view critical control: 0/9/9/12 # # search result search: 3 result: 4 Size limit exceeded # numResponses: 1 It seems you have started a new search without interrupting the previous search. Debug output of the slapd server that concerns to this request: daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(7): slap_listener(ldap://0.0.0.0:9389/) daemon: listen=7, new connection on 11 daemon: added 11r (active) listener=(nil) conn=1000 fd=11 ACCEPT from IP=127.0.0.1:44124 (IP=0.0.0.0:9389) [...] conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=10 text= For connection 10 entries were found [...] ber_get_next on fd 11 failed errno=0 (Success) connection_read(11): input error=-2 id=1000, closing. connection_closing: readying conn=1000 sd=11 for close connection_close: deferring conn=1000 sd=11 conn=1000 op=3 do_unbind conn=1000 op=3 UNBIND connection_resched: attempting closing conn=1000 sd=11 connection_close: conn=1000 sd=11 daemon: removing 11 conn=1000 fd=11 closed daemon: epoll: listen=7 active_threads=0 tvp=NULL Here connection 1000 got unbind and the connection has been closed, and 0 active threads. Sending the search request again blocks the server; see output on client side: # extended LDIF # # LDAPv3 # base o=CustomerCA,c=de with scope subtree # filter: (objectclass=*) # requesting: sncertnr # with server side sorting critical control # with virtual list view critical control: 0/9/0/1 # # search result search: 2 result: 51 Server is busy text: Other sort requests already in progress The corresponding server debug output looks like this: daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(7): slap_listener(ldap://0.0.0.0:9389/) daemon: listen=7, new connection on 11 daemon: added 11r (active) listener=(nil) conn=1001 fd=11 ACCEPT from IP=127.0.0.1:37542 (IP=0.0.0.0:9389) [...] conn=1001 op=0 BIND dn=cn=openldapadmin method=128 do_bind: version=3 dn=cn=openldapadmin method=128 == bdb_bind: dn: cn=openldapadmin conn=1001 op=0 BIND dn=cn=openldapadmin mech=SIMPLE ssf=0 do_bind
AW: AW: Q: status of component matching?
Hello Aaron! The head of snacc code resolves the problem of the unresolved symbol GenBufFreeBuf, but the core dump of slapd still persists as already described in ITS # 6556. Thank you. Regards, Hartmut -Ursprüngliche Nachricht- Von: Aaron Richton [mailto:rich...@nbcs.rutgers.edu] Gesendet: Donnerstag, 27. Mai 2010 15:29 An: Lehnert, Hartmut Cc: openldap-technical@openldap.org Betreff: Re: AW: Q: status of component matching? On Thu, 27 May 2010, Lehnert, Hartmut wrote: The problem is not: who calles GenBufFreeBuf, but: where is it defined? It's in exp-buf.c r1.4, i.e. see: http://www.openldap.org/devel/cvsweb.cgi/~checkout~/c-lib/src/exp-buf.c?cvsroot=SNACC Apparently openldap-snacc-2.3.6 ships with r1.3 of that file which does not contain the function definition. So you may patch: http://www.openldap.org/devel/cvsweb.cgi/c-lib/src/exp-buf.c.diff?r1=1.3r2=1.4cvsroot=SNACChideattic=1sortbydate=0 or just use a HEAD checkout. Perhaps you should file an ITS for a new release of openldap-snacc to be prepared; diff -ru shows that as the change from the 2.3.6 release (and actually, looking at the CVS tags involved, it looks like this may have been an oversight of a sort).
AW: Q: status of component matching?
Hi Dieter!
I built slapd and the comp match module with CFLAGS=-g option but a core dump
isn't generated.
I don't think that a core dump analysis is necessary to solve the problem
because the slapd output
/home/openldap/openldap-2.4.21-install/libexec/slapd: symbol lookup error:
/home/openldap/openldap-2.4.21-install/libexec/openldap/compmatch.so.0:
undefined symbol: GenBufFreeBuf
is clear enough: the symbol GenBufFreeBuf is simply missing in the source code
and binary of the comp match module. So once again: do you know where I can get
the missing source code?
Thank you for looking at this problem.
Regards,
Hartmut
-Ursprüngliche Nachricht-
Von: openldap-technical-bounces+hartmut.lehnert=secunet@openldap.org
[mailto:openldap-technical-bounces+hartmut.lehnert=secunet@openldap.org] Im
Auftrag von Dieter Kluenter
Gesendet: Dienstag, 25. Mai 2010 17:38
An: openldap-technical@openldap.org
Betreff: Re: Q: status of component matching?
Am Tue, 25 May 2010 15:51:40 +0200
schrieb Lehnert, Hartmut hartmut.lehn...@secunet.com:
Hi Dieter!
Thank you very much! I used CFLAGS=-DLDAP_COMP_MATCH when configuring
the slapd and now it's able to load our component match module.
But some problems are still left: When running the following LDAP
search command using component matching filter
/home/openldap/openldap-2.4.21-install/bin/ldapsearch -h localhost -p
9389 -D cn=openldapadmin -w welcome -b o=CustomerCA,c=de -s children
(userCertificate:componentFilterMatch:=item:{ component
\toBeSigned.serialNumber\, rule integerMatch, value 449 })
against slapd it terminates:
/home/openldap/openldap-2.4.21-install/libexec/slapd: symbol lookup
error:
/home/openldap/openldap-2.4.21-install/libexec/openldap/compmatch.so.0:
undefined symbol: GenBufFreeBuf
In the source code of both snacc and component match module no
definition for function GenBufFreeBuf can be found. Where can I get
it?
The function is called in comp_match/init.c, could you please build
slapd with debugging symbols enabled (-g) and when installing don't
strip, that is 'make install STRIP= ', If possible create a core dump
and run core and slapd in gdb in order to create a backtrace?
-Dieter
--
Dieter Klünter | Systemberatung
sip: +49.40.20932173
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6
WG: Q: status of component matching?
Hello Dieter!
Nevertheless I generated a core dump in the mean time - but this was only
possible by adding the GenBufFreeBuf function as a dummy to init.c file of the
comp match module:
void GenBufFreeBuf (void *p)
{
}
The back trace of the core:
(gdb) bt
#0 0x080e17d4 in slap_sl_free (ptr=0xb6f981d2, ctx=0x82d01a8) at
sl_malloc.c:487
#1 0x0809ecf1 in ch_free (ptr=0xb6f981d2) at ch_malloc.c:137
#2 0x080dedae in mra_free (op=0x82cfde8, mra=0xb6f98288, freeit=1) at mra.c:43
#3 0x0808273f in filter_free_x (op=0x82cfde8, f=0xb6f982c8, freeme=1) at
filter.c:556
#4 0x08080834 in do_search (op=0x82cfde8, rs=0xb7499134) at search.c:230
#5 0x0807da51 in connection_operation (ctx=0xb7499220, arg_v=0x82cfde8) at
connection.c:1109
#6 0x0807df99 in connection_read_thread (ctx=0xb7499220, argv=0xb) at
connection.c:1245
#7 0x08162082 in ldap_int_thread_pool_wrapper ()
#8 0xb7cc11b5 in start_thread () from /lib/libpthread.so.0
#9 0xb7da738e in clone () from /lib/libc.so.6
(gdb)
Does this cover any new information?
Thank you.
Regards,
Hartmut
-Ursprüngliche Nachricht-
Von: Lehnert, Hartmut
Gesendet: Mittwoch, 26. Mai 2010 10:10
An: openldap-technical@openldap.org
Betreff: AW: Q: status of component matching?
Hi Dieter!
I built slapd and the comp match module with CFLAGS=-g option but a core dump
isn't generated.
I don't think that a core dump analysis is necessary to solve the problem
because the slapd output
/home/openldap/openldap-2.4.21-install/libexec/slapd: symbol lookup error:
/home/openldap/openldap-2.4.21-install/libexec/openldap/compmatch.so.0:
undefined symbol: GenBufFreeBuf
is clear enough: the symbol GenBufFreeBuf is simply missing in the source code
and binary of the comp match module. So once again: do you know where I can get
the missing source code?
Thank you for looking at this problem.
Regards,
Hartmut
-Ursprüngliche Nachricht-
Von: openldap-technical-bounces+hartmut.lehnert=secunet@openldap.org
[mailto:openldap-technical-bounces+hartmut.lehnert=secunet@openldap.org] Im
Auftrag von Dieter Kluenter
Gesendet: Dienstag, 25. Mai 2010 17:38
An: openldap-technical@openldap.org
Betreff: Re: Q: status of component matching?
Am Tue, 25 May 2010 15:51:40 +0200
schrieb Lehnert, Hartmut hartmut.lehn...@secunet.com:
Hi Dieter!
Thank you very much! I used CFLAGS=-DLDAP_COMP_MATCH when configuring
the slapd and now it's able to load our component match module.
But some problems are still left: When running the following LDAP
search command using component matching filter
/home/openldap/openldap-2.4.21-install/bin/ldapsearch -h localhost -p
9389 -D cn=openldapadmin -w welcome -b o=CustomerCA,c=de -s children
(userCertificate:componentFilterMatch:=item:{ component
\toBeSigned.serialNumber\, rule integerMatch, value 449 })
against slapd it terminates:
/home/openldap/openldap-2.4.21-install/libexec/slapd: symbol lookup
error:
/home/openldap/openldap-2.4.21-install/libexec/openldap/compmatch.so.0:
undefined symbol: GenBufFreeBuf
In the source code of both snacc and component match module no
definition for function GenBufFreeBuf can be found. Where can I get
it?
The function is called in comp_match/init.c, could you please build
slapd with debugging symbols enabled (-g) and when installing don't
strip, that is 'make install STRIP= ', If possible create a core dump
and run core and slapd in gdb in order to create a backtrace?
-Dieter
--
Dieter Klünter | Systemberatung
sip: +49.40.20932173
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6
Re: use of server-side sorting and virtual list view controls blocks slapd
Hi Dieter! We tried Sizelimit unlimited In slapd.conf, but the effect is the same, slapd answers size limit exceeded. The search request command is /home/openldap/openldap-2.4.21-install/bin/ldapsearch -h localhost -p 9389 -D cn=openldapadmin -w welcome -b o=CustomerCA,c=de -s children -E!sss=sncertnr:2.5.13.3 -E!vlv=0/9/0/1:objectclass=SN-ISIS-MTT-MainCert objectclass=* sncertnr Besides this effect we only have 10 records stored in the LDAP database ;-) For the supported features see the following list: openl...@ocsp-openldap24:~/openldap-snacc-2.3.6/c-lib /home/openldap/openldap-2.4.21-install/bin/ldapsearch -h localhost -p 9389 -D cn=openldapadmin -w welcome -b -s base + # extended LDIF # # LDAPv3 # base with scope baseObject # filter: (objectclass=*) # requesting: + # # dn: structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 entryDN: subschemaSubentry: cn=Subschema # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 The OID 1.3.6.1.4.1.4203.666.8.1 is missing here but this OID is marked as kind of experimental. Why do I need this feature and how can I enable this? Regards, Hartmut
