- openldap-bugs - openldap.org

(ITS#5789) using IP address in CN with GnuTLS
by leva＠ecentrum.hu 04 Nov '08

04 Nov '08

Full_Name: LÉVAI Dániel Version: 2.4.11 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.131.56.68) I'm using OpenLDAP 2.4.11 on a Debian testing/lenny system. The GnuTLS version is 2.4.2. So I'm having a lot of problems using OpenLDAP with GnuTLS, and I've decided to take another route in troubleshooting; I've recreated my cert/key pair, using my machine's ip address in the CN field. The weirdest thing happened: $ ldapsearch -d 1 -ZZWx '(objectclass=*)' -H ldap://192.168.1.3 ldap_url_parse_ext(ldap://192.168.1.3) ldap_create ldap_url_parse_ext(ldap://192.168.1.3:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 192.168.1.3:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.1.3:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x6120a0 msgid 1 wait4msg ld 0x6120a0 msgid 1 (infinite timeout) wait4msg continue ld 0x6120a0 msgid 1 all 1 ** ld 0x6120a0 Connections: * host: 192.168.1.3 port: 389 (default) refcnt: 2 status: Connected last used: Fri Oct 31 22:36:46 2008 ** ld 0x6120a0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x6120a0 request count 1 (abandoned 0) ** ld 0x6120a0 Response Queue: Empty ld 0x6120a0 response count 0 ldap_chkResponseList ld 0x6120a0 msgid 1 all 1 ldap_chkResponseList returns ld 0x6120a0 NULL ldap_int_select read1msg: ld 0x6120a0 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x6120a0 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x6120a0 0 new referrals read1msg: mark request completed, ld 0x6120a0 msgid 1 request done: ld 0x6120a0 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS: hostname (192.168.1.3) does not match common name in certificate (192.168.1.3). ldap_err2string ldap_start_tls: Connect error (-11) So it seems, according to OpenLDAP, 192.168.1.3 != 192.168.1.3. Why is that? And please allow me include some additional information, which was told me by Philip Guenther on openldap-software@: "It appears the routine used with GNUtls refuses to match IP addresses against a CN subjects component, thus explaining that weird message. (In ldap_pvt_tls_check_hostname(), 'len1' is only non-zero if the hostname doesn't look like an IPv6 or IPv4 address, while the subject CN test needs 'len1' to be the same as the length of the CN value.)" Daniel

1 0

Re: (ITS#5701) connection.c asserting during test008
by hyc＠symas.com 03 Nov '08

03 Nov '08

ando(a)sys-net.it wrote: > richton(a)nbcs.rutgers.edu wrote: > >> Rare connection.c assertion during test008s of RE24. Here are three different >> examples: > >> [6] monitor_subsys_conn_create(op = 0x103a359b0, rs = 0xffffffff76bff998, ndn >> = (nil), e_parent = 0x1005c03d8, ep = 0xffffffff76bff230), line 500 in "conn.c" > > >> [6] monitor_subsys_rww_update(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e = >> 0x1005c1b98), line 187 in "rww.c" > >> [7] monitor_subsys_rww_update(op = 0x100922640, rs = 0xffffffff78fff998, e = >> 0x1005c1b98), line 185 in "rww.c" > > > Sorry, I overlooked the fact that all those issues are occurring from > within back-monitor. In all cases, it's within code that loops through > the connection array using connection_{first,next,close}(). Apparently, > those calls are used in the right way. Can you print more information > about those connections? E.g. c->c_struct_state, and *index from within > connection_next()? Or even better, the whole *c structure? Looks like it may be related to #5586. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5749) client didn't send its own certificate to the server
by hyc＠symas.com 03 Nov '08

03 Nov '08

bugs(a)shiva.hostoffice.hu wrote: > Full_Name: Gabor Mayer > Version: 2.4.11 > OS: debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (91.120.131.147) > > > i discovered it when i turned on the peer verification at server side. > > i'm using the following configuration at client side: > > ldap.conf: > > BASE dc=example,dc=org > URI ldaps://ldap.example.org > > TLS_CACERT /etc/ldap/server.crt > > /root/.ldaprc: > > TLS_CERT /etc/ldap/client.crt > TLS_KEY /etc/ldap/client.key > > i tried TLS_CERT& TLS_KEY in ldap.conf and in .ldaprc without success. > > i tested it with ldapsearch -x and i got the following debug message at server > if the TLSVerifyClient was turned on: > > TLS trace: SSL3 alert write:fatal:handshake failure > TLS trace: SSL_accept:error in SSLv3 read client certificate B > TLS: can't accept. > TLS: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return > a certificate s3_srvr.c:2455 > > i captured the tcp flow at client side and i saw the server's certificate only. > the client didn't send its own certificate to the server! Works for me on Ubuntu 8.10 using GNUtls 2.4.1. I suggest you contact the Debian folks about this. This ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5739) "host:port" does not work
by h.b.furuseth＠usit.uio.no 03 Nov '08

03 Nov '08

hyc(a)symas.com writes: > OpenLDAP has been this way since at least 2003, no one else has > cared since then... No, it works with 2.3.43. And "LDAPHOST=ldap:3890 ldapwhoami -x" still works in HEAD. It's ldap_url_desc2str() in libraries/libldap/url.c which changed to assume IPv6 if strchr( u->lud_host, ':' ). -- Hallvard

1 0

Re: (ITS#5739) "host:port" does not work
by hyc＠symas.com 03 Nov '08

03 Nov '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> Why are you reporting this? "-h" has always been documented to only >> accept a hostname, > > No. Look at man ldap_init: > (...) each host may optionally by of the form host:port. If > present, the :port overrides the port parameter (...) > > So sometimes this option is called hostport. > > It's been that way since umich ldap 3.2. > Perhaps so, but... clients/tools/common.c: 1.1 (hallvard 12-Dec-02): if( ( ldaphost != NULL || ldapport ) && ( ldapuri == NULL ) ) { 1.26 (kurt 14-Dec-03): /* construct URL */ 1.26 (kurt 14-Dec-03): LDAPURLDesc url; 1.26 (kurt 14-Dec-03): memset( &url, 0, sizeof(url)); 1.26 (kurt 14-Dec-03): 1.26 (kurt 14-Dec-03): url.lud_scheme = "ldap"; 1.26 (kurt 14-Dec-03): url.lud_host = ldaphost; 1.26 (kurt 14-Dec-03): url.lud_port = ldapport; 1.26 (kurt 14-Dec-03): url.lud_scope = LDAP_SCOPE_DEFAULT; 1.26 (kurt 14-Dec-03): 1.26 (kurt 14-Dec-03): ldapuri = ldap_url_desc2str( &url ); OpenLDAP has been this way since at least 2003, no one else has cared since then... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

RE: (ITS#5788) Search does not work with nested naming contexts
by emmanuel.duru＠atosorigin.com 03 Nov '08

03 Nov '08

OK, thank you. I didn't see this configuration directive in the admin guide... > # need to inform slapd that this DB is subordinate > subordinate

1 0

Re: (ITS#5745) slapcat doesn't return correct error status for bdb fatal error
by hyc＠symas.com 03 Nov '08

03 Nov '08

Guillaume Rousse wrote: > Howard Chu a écrit : >> How did you create this situation? I can't test a fix without some way >> to break the DB in the first place, and generally the DB doesn't fail... > I just upgraded to 2.4.12, as described at > http://www.openldap.org/lists/openldap-software/200810/msg00087.html. OK, fixed now in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5788) Search does not work with nested naming contexts
by ando＠sys-net.it 03 Nov '08

03 Nov '08

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.4.11 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.78.0.137) > > > I want to run a directory server with a "c=fr" suffix, and a replicated subtree: > "ou=test,o=myorg,c=fr". > To do this, I define two bdb databases, the first one with a > "ou=test,o=myorg,c=fr" suffix, the second one with a "c=fr" suffix. > But when I perform a search, the entries from the first base are not returned. > For example, search with base "o=myorg,c=fr" and scope one level returns > "ou=test2,o=myorg,c=fr" but not "ou=test,o=myorg,c=fr" whereas search with base > "ou=test,o=myorg,c=fr" returns the entry. > If this is a configuration problem, please tell me what is wrong. > > Here follows my slapd.conf file: > > include schema/core.schema > include schema/cosine.schema > include schema/inetorgperson.schema > pidfile slapd.pid > argsfile slapd.args > access to * attrs=userPassword > by self write > by anonymous auth > by * none > access to * > by self write > by users read > by anonymous read > by * none > database bdb > suffix "ou=test,o=myorg,c=fr" # need to inform slapd that this DB is subordinate subordinate > rootdn "cn=manager,c=fr" > updatedn "cn=replicator,ou=test,o=myorg,c=fr" > cachesize 20000 > checkpoint 10000 10 > directory db1 > index objectClass,entryCSN,entryUUID eq > index cn,sn eq,sub > database bdb > suffix "c=fr" > rootdn "cn=manager,c=fr" > rootpw {SSHA}IcRbIFvDVZ9j6g8hWK9bbgo7xhSrMMTf > cachesize 20000 > checkpoint 10000 10 > directory db2 > index objectClass,entryCSN,entryUUID eq > index cn,sn eq,sub > > p.

1 0

(ITS#5788) Search does not work with nested naming contexts
by emmanuel.duru＠atosorigin.com 03 Nov '08

03 Nov '08

Full_Name: Emmanuel Duru Version: 2.4.11 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.78.0.137) I want to run a directory server with a "c=fr" suffix, and a replicated subtree: "ou=test,o=myorg,c=fr". To do this, I define two bdb databases, the first one with a "ou=test,o=myorg,c=fr" suffix, the second one with a "c=fr" suffix. But when I perform a search, the entries from the first base are not returned. For example, search with base "o=myorg,c=fr" and scope one level returns "ou=test2,o=myorg,c=fr" but not "ou=test,o=myorg,c=fr" whereas search with base "ou=test,o=myorg,c=fr" returns the entry. If this is a configuration problem, please tell me what is wrong. Here follows my slapd.conf file: include schema/core.schema include schema/cosine.schema include schema/inetorgperson.schema pidfile slapd.pid argsfile slapd.args access to * attrs=userPassword by self write by anonymous auth by * none access to * by self write by users read by anonymous read by * none database bdb suffix "ou=test,o=myorg,c=fr" rootdn "cn=manager,c=fr" updatedn "cn=replicator,ou=test,o=myorg,c=fr" cachesize 20000 checkpoint 10000 10 directory db1 index objectClass,entryCSN,entryUUID eq index cn,sn eq,sub database bdb suffix "c=fr" rootdn "cn=manager,c=fr" rootpw {SSHA}IcRbIFvDVZ9j6g8hWK9bbgo7xhSrMMTf cachesize 20000 checkpoint 10000 10 directory db2 index objectClass,entryCSN,entryUUID eq index cn,sn eq,sub

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by toby＠inf.ed.ac.uk 03 Nov '08

03 Nov '08

Hi there, is there any further debugging I could usefully carry out for this issue, or does it need someone who understands the code a bit better? Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#5745) slapcat doesn't return correct error status for bdb fatal error
by Guillaume.Rousse＠inria.fr 03 Nov '08

03 Nov '08

Howard Chu a écrit : > Guillaume.Rousse(a)inria.fr wrote: >> Full_Name: Guillaume Rousse >> Version: 2.4.12 >> OS: >> URL: >> Submission from: (NULL) (193.55.250.67) >> >> >> [root@etoile ~]# slapcat -b dc=msr-inria,dc=inria,dc=fr >> ... >> bdb(dc=msr-inria,dc=inria,dc=fr): pthread lock failed: Invalid argument >> bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: Invalid argument >> bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: DB_RUNRECOVERY: Fatal error, run >> database recovery >> bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: fatal region error detected; run >> recovery >> bdb_db_close: database "dc=msr-inria,dc=inria,dc=fr": close failed: >> DB_RUNRECOVERY: Fatal error, run database recovery (-30975) >> [root@etoile ~]# echo $? >> 0 >> >> It makes a bit difficult to know if slapcat-based backup were successful. > > How did you create this situation? I can't test a fix without some way > to break the DB in the first place, and generally the DB doesn't fail... I just upgraded to 2.4.12, as described at http://www.openldap.org/lists/openldap-software/200810/msg00087.html. -- Guillaume Rousse Service des Moyens Informatiques INRIA Saclay - Ile de France Tel: 01 69 35 69 62

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by hyc＠symas.com 02 Nov '08

02 Nov '08

Ali Pouya wrote: > Howard Chu a écrit : >> The startup scan is only performed inside the syncprov overlay. If >> server C is only a consumer, then it does not need the syncprov overlay. >> > Yes, you are right for the point 1). Thank you. > > But I'm also bothered with the point 2) reproduced below : > > .... > 2) If I do only one write operation on B, then I get two contextCSN values, > which is normal. > > But il this case slapd on B scans, at each startup, all objecs written on A > after the write operation on B. > The log and the effect are similar to those explained above. I see. This has been fixed for back-bdb/hdb in HEAD. If the database was shut down cleanly before, there will be no scan on the next startup. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5786) too many arguments to function slap_get_commit_csn
by hyc＠symas.com 02 Nov '08

02 Nov '08

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.100.88) > > > HEAD synced, invoked configure after make distclean > > cd overlays; make -w static > make[3]: Entering directory > `/usr/src/michael/openldap/HEAD/openldap/servers/slapd/overlays' > gcc -g -O4 -I../../../include -I../../../include -I.. -I./.. > -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DDEVEL -c -o > syncprov.o syncprov.c > syncprov.c: In function syncprov_op_response: > syncprov.c:1612: error: too many arguments to function slap_get_commit_csn > syncprov.c:1621: error: too many arguments to function slap_get_commit_csn > make[3]: *** [syncprov.o] Error 1 > make[3]: Leaving directory > `/usr/src/michael/openldap/HEAD/openldap/servers/slapd/overlays' > make[2]: *** [liboverlays.a] Error 2 > make[2]: Leaving directory > `/usr/src/michael/openldap/HEAD/openldap/servers/slapd' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/servers' > make: *** [all-common] Error 1 Incomplete commit. Fixed now. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5787) Implement support for "Codice Fiscale" syntax
by ando＠sys-net.it 02 Nov '08

02 Nov '08

Further info is available here: <http://www.openldap.org/faq/data/cache/1471.html> p.

1 0

(ITS#5787) Implement support for "Codice Fiscale" syntax
by ando＠sys-net.it 02 Nov '08

02 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/cf.tar.gz Submission from: (NULL) (81.72.89.40) Submitted by: ando This module registers the "Codice Fiscale" syntax, derived from directoryString, and makes it compatible with the caseExactMatch matchingRule. It also defines a "codiceFiscale" attribute and the "codiceFiscaleBase" and "codiceFiscaleObject" objectClasses. I believe this software and these schema items will probably be mainly useful to Italian users and developers of OpenLDAP software. This software has been developed by myself, based on publicly available information. It is released under the OpenLDAP license for use with OpenLDAP software. p.

1 0

Re: (ITS#5785) dontUseCopy in slapd requires criticality to be TRUE
by ando＠sys-net.it 02 Nov '08

02 Nov '08

See also <http://www.openldap.org/lists/openldap-devel/200811/msg00000.html> and specifically <http://www.openldap.org/lists/openldap-devel/200811/msg00006.html> dontUseCopy needs to be fixed, but specific "disallow" flags could be added to alter per-RFC4511 behavior. p.

1 0

(ITS#5786) too many arguments to function slap_get_commit_csn
by michael＠stroeder.com 02 Nov '08

02 Nov '08

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.100.88) HEAD synced, invoked configure after make distclean cd overlays; make -w static make[3]: Entering directory `/usr/src/michael/openldap/HEAD/openldap/servers/slapd/overlays' gcc -g -O4 -I../../../include -I../../../include -I.. -I./.. -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DDEVEL -c -o syncprov.o syncprov.c syncprov.c: In function syncprov_op_response: syncprov.c:1612: error: too many arguments to function slap_get_commit_csn syncprov.c:1621: error: too many arguments to function slap_get_commit_csn make[3]: *** [syncprov.o] Error 1 make[3]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/servers/slapd/overlays' make[2]: *** [liboverlays.a] Error 2 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/servers' make: *** [all-common] Error 1

1 0

Re: (ITS#5785) dontUseCopy in slapd requires criticality to be TRUE
by ando＠sys-net.it 02 Nov '08

02 Nov '08

michael(a)stroeder.com wrote: > ando(a)sys-net.it wrote: >> The "dontUseCopy" control requires criticality to be TRUE. While this is the >> desirable value, > > Why is this a desirable value? The answer Kurt gave on ldap-ext mailing > list just mentioned direct mapping to X.511 dontUseCopy option. Because. If you need to avoid using copy, then you strongly need it. If it's just a wish, then don't use it, assuming the DSA you contact will do no more than what it can to provide you valid data. You would otherwise be misuing the control. >> a DUA could use the control with the criticality set to FALSE. Yes, perfectly legitimate (from a DSA's point of view, as per RFC4511) but contrary to the control's specification (and, IMHO, to common sense). > As I stated on ldap-ext mailing list in this case I'd simply accept a > best effort on the DSA side. IMHO you already get the best effort by not using the control. > So sending "dontUseCopy" control with > criticality FALSE would mean: If the DSA supports this control it should > *process* it according to what's specified in > draft-zeilenga-ldap-dontusecopy. Otherwise ignore it. No. The spec looks broken to me, because it contradicts RFC4511 (from the DSA's point of view). The DUA must use TRUE to comply with dontUseCopy. If it doesn't, then the DSA can do its best to honor it, but nothing more. If the DSA finds out it can chain a request, but this would cost resources, it could return a referral, or simply ignore the control. All of these behaviors would comply with criticality to FALSE. > The main problem is that a DUA cannot determine in advance whether a DSA > supports a certain control for a certain backend. It turned out in > practice that looking a supportedControl in rootDSE does not have any > meaning at all. You got a clear answer: the only ultimate way to know is to try. If you use FALSE, you'll never know. > IMO yet another control does not solve this. It does: you add dontUseCopy with criticality set to TRUE; you add the whatFailed control; if dontUseCopy fails, you'd know for sure. Then you don't need to use it any more, as using it with FALSE would make no sense. >> For full conformance with RFC4511, if the control is syntactically well-formed >> and criticality is set to FALSE, slapd MUST accept it if recognized, or MUST >> ignore it if not recognized, but CANNOT question the fact that the value of >> criticality is violating the control's specification. > > I'm not sure whether this statement can be made generally. I'd wish so > and I'd rephrase "accept it" to "process it". With "accept" I mean: "recognize it"; with "process" I'd mean "apply it to the operation". If you set criticality to FALSE and the DSA does not recognize it, the DSA will just ignore it. If the DSA recognizes it, it is at the DSA's discretion to either apply it or not, based on what the DSA considers best (including interoperability with the specific operation, with other extensions, with resource consumption and any other consideration about the opportunity to process it). I'm pretty sure you agree that elaving so much discretion to the DSA about something related to data integrity does not differ too much from not using the control at all. p.

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 02 Nov '08

02 Nov '08

Howard Chu a écrit : > > The startup scan is only performed inside the syncprov overlay. If > server C is only a consumer, then it does not need the syncprov overlay. > Yes, you are right for the point 1). Thank you. But I'm also bothered with the point 2) reproduced below : .... 2) If I do only one write operation on B, then I get two contextCSN values, which is normal. But il this case slapd on B scans, at each startup, all objecs written on A after the write operation on B. The log and the effect are similar to those explained above. Best Regards Ali

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by hyc＠symas.com 02 Nov '08

02 Nov '08

ali.pouya(a)free.fr wrote: > Full_Name: Ali Pouya > Version: 2.4.11 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (145.242.11.4) > > > I have a test directory with two mirrors A and B and a replica C connected to > A. > I usaually use server A for write operations. > > I encounter the following problems : > > > 1) If the data base is initiated in stand alone (so serverID defaults to zero) > and then I set serverIDs 1 and 2 for A and B then each time I start up slapd on > C it scans all of the objects writtent on A afterwards, producing the followin > log for each object : The startup scan is only performed inside the syncprov overlay. If server C is only a consumer, then it does not need the syncprov overlay. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5709) slapd sync provider skips some objects
by hyc＠symas.com 02 Nov '08

02 Nov '08

hyc(a)symas.com wrote: > sylvain.thomas(a)gmail.com wrote: >> On 10/30/08, Gavin Henry<ghenry(a)openldap.org> wrote: >>> Can you upload these zip attachments to our ftp server or somewhere else >>> with online >>> access please. Then we can test. >>> >> I have uploaded the two files to your ftp server (incoming folder). > > I can confirm that the problem is easily reproducable. Fixed now in HEAD. A couple of bad assumptions from 1.234-1.236... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5785) dontUseCopy in slapd requires criticality to be TRUE
by michael＠stroeder.com 01 Nov '08

01 Nov '08

ando(a)sys-net.it wrote: > > The "dontUseCopy" control requires criticality to be TRUE. While this is the > desirable value, Why is this a desirable value? The answer Kurt gave on ldap-ext mailing list just mentioned direct mapping to X.511 dontUseCopy option. > a DUA could use the control with the criticality set to FALSE. As I stated on ldap-ext mailing list in this case I'd simply accept a best effort on the DSA side. So sending "dontUseCopy" control with criticality FALSE would mean: If the DSA supports this control it should *process* it according to what's specified in draft-zeilenga-ldap-dontusecopy. Otherwise ignore it. The main problem is that a DUA cannot determine in advance whether a DSA supports a certain control for a certain backend. It turned out in practice that looking a supportedControl in rootDSE does not have any meaning at all. IMO yet another control does not solve this. > For full conformance with RFC4511, if the control is syntactically well-formed > and criticality is set to FALSE, slapd MUST accept it if recognized, or MUST > ignore it if not recognized, but CANNOT question the fact that the value of > criticality is violating the control's specification. I'm not sure whether this statement can be made generally. I'd wish so and I'd rephrase "accept it" to "process it". Ciao, Michael.

1 0

(ITS#5785) dontUseCopy in slapd requires criticality to be TRUE
by ando＠sys-net.it 01 Nov '08

01 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando The "dontUseCopy" control requires criticality to be TRUE. While this is the desirable value, a DUA could use the control with the criticality set to FALSE. For full conformance with RFC4511, if the control is syntactically well-formed and criticality is set to FALSE, slapd MUST accept it if recognized, or MUST ignore it if not recognized, but CANNOT question the fact that the value of criticality is violating the control's specification. p. PS: other controls with similar requirements for the DUA accept any value for criticality (e.g. RFC4370).

1 0

(ITS#5784) [enhancement] add support for "What Failed?" LDAP control
by ando＠sys-net.it 01 Nov '08

01 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando I'm about to add support for what I termed the "What Failed?" LDAP control, which allows to request detailed information about what extension caused the failure of a request. The commit includes a preliminary version of what I intend to submit as an I.D. shortly. p.

1 0

Re: (ITS#5709) slapd sync provider skips some objects
by hyc＠symas.com 31 Oct '08

31 Oct '08

sylvain.thomas(a)gmail.com wrote: > On 10/30/08, Gavin Henry<ghenry(a)openldap.org> wrote: >> Can you upload these zip attachments to our ftp server or somewhere else >> with online >> access please. Then we can test. >> > > I have uploaded the two files to your ftp server (incoming folder). I can confirm that the problem is easily reproducable. Adding a debug message here diff -u -r1.248 syncprov.c --- syncprov.c 17 Oct 2008 15:40:49 -0000 1.248 +++ syncprov.c 31 Oct 2008 21:06:56 -0000 @@ -1638,6 +1638,7 @@ si->si_sids[i] = sid; } } else { + Debug( LDAP_DEBUG_SYNC, "Empty maxcsn for %s\n", op->o_req_dn.bv_val, 0, 0 ); /* internal ops that aren't meant to be replicated */ ldap_pvt_thread_rdwr_wunlock( &si->si_csn_rwlock ); return SLAP_CB_CONTINUE; shows that some of the missing entries are caused by this situation, but not necessarily all. Still investigating. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs