- openldap-bugs - openldap.org

Re: (ITS#5554) slapd.conf man page missing TLSCipherSuite
by hyc＠symas.com 12 Jun '08

12 Jun '08

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > http://www.openldap.org/software/man.cgi?query=slapd.conf&sektion=5&apropos… > missing TLSCipherSuite > > > No. The Admin Guide is missing the note about GnuTLS under the TLSCipherSuite description. The note is present in slapd.conf(5). -- -- 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

(ITS#5554) slapd.conf man page missing TLSCipherSuite
by ghenry＠OpenLDAP.org 12 Jun '08

12 Jun '08

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) http://www.openldap.org/software/man.cgi?query=slapd.conf&sektion=5&apropos… missing TLSCipherSuite

1 0

Re: (ITS#5551) assertion causes application failure
by ghenry＠OpenLDAP.org 12 Jun '08

12 Jun '08

> Is there debug output you would like from me? See http://www.openldap.org/faq/data/cache/59.html -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by h.b.furuseth＠usit.uio.no 12 Jun '08

12 Jun '08

hyc(a)symas.com writes: >>> monitorContext, readOnly and the olc* attributes are defined by OpenLDAP >>> (their OIDs start with 1.3.6.1.4.1.4203) and can be modified if we feel >>> like it. Personally I prefer attrs to have the matching rules they can >>> have unless there is a reason not to, but I didn't write these modules >>> so I don't know if there _is_ a reason not to. > > For the config attributes, I just assumed no one needs to search on > them (so no filter capability needed) and for single-valued > attributes, there's no need to consider modifies... Oh, good. No reason not to add matching rules then:-) I search for one config attrs or another once in a while. Mostly for olcSuffix and with presence filters, but it'd be nice if e.g. (olcAccess:caseIgnoreSubstringsMatch:=*userPassword*) worked. Also some day I'll want to use assertion controls as a check on modify operations someday. Still, I'm not proposing to add more work than necessary to this ITS. Get it right first, then think of "nice to have"-features if/when anyone bothers. -- Hallvard

1 0

Re: (ITS#5553) Inconsistent sasl.c logging format
by h.b.furuseth＠usit.uio.no 12 Jun '08

12 Jun '08

hyc(a)symas.com writes: >> Would it be reasonable to change the 6 debug statements in sasl.c to >> use the first format? > > I don't see any reason not to. I do: Currently that format is more or less reserved for loglevel stats/stats2, and is useful when grepping a more chatty log for stats. Though it could certainly be useful to normalize log formats a little. -- Hallvard

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com 12 Jun '08

12 Jun '08

unix.gurus(a)gmail.com wrote: >>> namingContexts >>> configContext >>> dynamicSubtrees >>> >>> These attributes do not have equality matching rules, but probably >>> should. I add 'EQUALITY distinguishedNameMatch' to them in >>> schema_prep.c. >> No, that breaks the definitions in the RFCs they come from. (See their >> DESC strings.) I don't know why they lack EQUALITY rules, maybe we just >> forgot when we defined them, but that's the way it is. Same with >> supportedControl. configContext is OpenLDAP-specific. It is also single-valued, so it seemed to me it did not need an EQ rule. > Ok, so we should not define nvals for them? No normalizer, therefore, cannot provide nval... >> monitorContext, readOnly and the olc* attributes are defined by OpenLDAP >> (their OIDs start with 1.3.6.1.4.1.4203) and can be modified if we feel >> like it. Personally I prefer attrs to have the matching rules they can >> have unless there is a reason not to, but I didn't write these modules >> so I don't know if there _is_ a reason not to. For the config attributes, I just assumed no one needs to search on them (so no filter capability needed) and for single-valued attributes, there's no need to consider modifies... -- -- 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#5553) Inconsistent sasl.c logging format
by hyc＠symas.com 12 Jun '08

12 Jun '08

unix.gurus(a)gmail.com wrote: > Full_Name: Sean Burford > Version: 2.4.8 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (72.14.227.1) > > > Most connection logs are of the format: > conn=\d+ fd=\d+ MSG > > sasl.c Debug logs are of the format: > SASL .*[conn=\d+]: MSG > > Would it be reasonable to change the 6 debug statements in sasl.c to use the > first format? I don't see any reason not to. > > This is not an important issue, just a small inconsistency. -- -- 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

(ITS#5553) Inconsistent sasl.c logging format
by unix.gurus＠gmail.com 12 Jun '08

12 Jun '08

Full_Name: Sean Burford Version: 2.4.8 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.14.227.1) Most connection logs are of the format: conn=\d+ fd=\d+ MSG sasl.c Debug logs are of the format: SASL .*[conn=\d+]: MSG Would it be reasonable to change the 6 debug statements in sasl.c to use the first format? This is not an important issue, just a small inconsistency.

1 0

(ITS#5552) Ppolicy overlay doesn't accept unquoted DN for "olcPpolicyDefault"
by ralf＠OpenLDAP.org 12 Jun '08

12 Jun '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.189.171) Submitted by: ralf Adding an unquoted DN (containing white spaces) to olcPpolicyDefault results in the following error: ldap_modify: Constraint violation (19) additional info: <olcPPolicyDefault> extra cruft after <policyDN> Fix is on the way to CVS.

1 0

Re: (ITS#5550) Unable to do scp from and to server ldap
by hyc＠symas.com 12 Jun '08

12 Jun '08

karim.bourenane(a)orange-ftgroup.com wrote: > Full_Name: Bourenane > Version: Openldap-server-2.3.41 / and clien > OS: FreeBSD 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (57.250.229.136) > > > Hi All > > My server running fine, with ldap and ldaps. > Is i do a command SCP from any server to user i have : > > server# scp kbourena@ldap-rain:/home/kbourena/toto.txt . > Password: > unknown user 1206 > server# > > On ldap-rain scp is not OpenLDAP software. Since you already said your server is running fine, this is clearly not an OpenLDAP software issue, and therefore does not belong in the OpenLDAP ITS. 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#5462) Allow setting of RANDOM_FILE for gnutls
by pogma＠thewrittenword.com 12 Jun '08

12 Jun '08

On Tue, Jun 10, 2008 at 12:50:22PM -0700, Howard Chu wrote: > pogma(a)thewrittenword.com wrote: >> Full_Name: Peter O'Gorman >> Version: 2.4.8 >> OS: multiple >> URL: ftp://ftp.openldap.org/incoming/the-written-word-080410.patch >> Submission from: (NULL) (24.76.165.223) >> >> >> gcrypt-1.4.x and later allow the egd socket path to be set. This patch allows >> the conf file option to work when building openldap with gnutls on systems that >> do not have a /dev/random. > > Hm, this patch is a silent no-op if the gcrypt function is missing. > Currently the randfile option is already documented as being ignored by > GNUtls. I would prefer that the behavior is absolutely consistent - either > the feature always works or is always ignored. Perhaps we should require > gcrypt 1.4 or newer? Requiring gcrypt-1.4.x or newer is ok with us. Peter -- Peter O'Gorman pogma(a)thewrittenword.com

1 0

Re: (ITS#5551) assertion causes application failure
by aej＠WPI.EDU 12 Jun '08

12 Jun '08

I ran the thing again to get a trace back, and went to attach the code and found a free() which was at the wrong location. I think I caused the problem. I still don't know what's happening with ldap on the mail server, but my application bug was not related after all.

1 0

(ITS#5551) assertion causes application failure
by aej＠wpi.edu 12 Jun '08

12 Jun '08

Full_Name: Allan E. Johannesen Version: 2.4.10 OS: Linux EL 4 URL: Submission from: (NULL) (130.215.24.208) Recently, incorrect "User unknown" have been appearing in the mail logs with some frequency, accompanied by nss ldap error messages. I can't see into that application, so I'm not sure what's going on. At another place, I've had an application failing where it sees an assertion fail, so this may be the cause of the other problem. Did some debug code remain in the 2.4.10 release? [New Thread 1367456096 (LWP 14151)] [New Thread 1388435808 (LWP 14165)] [Thread 1514314080 (LWP 14129) exited] [New Thread 1514314080 (LWP 14178)] [Thread 1252067680 (LWP 13877) exited] [Thread 1241577824 wpi closed] [Thread 1241577824 (LWP 13824) exited] [New Thread 1241577824 (LWP 14188)] [Thread 1199618400 (LWP 13994) exited] [Thread 1231087968 wpi closed] [Thread 1231087968 (LWP 13888) exited] [New Thread 1231087968 (LWP 14199)] [Thread 1115699552 wpi closed] [Thread 1115699552 (LWP 13946) exited] [Thread 1126189408 alum_connect ldap://alum.wpi.edu] [New Thread 1115699552 (LWP 14212)] [Thread 1136679264 wpi_connect ldap://ldapv2back.wpi.edu] [New Thread 1199618400 (LWP 14223)] [Thread 1105209696 (LWP 14011) exited] [New Thread 1105209696 (LWP 14234)] [Thread 1294027104 (LWP 13865) exited] [Thread 1335986528 (LWP 13839) exited] [Thread 1094719840 (LWP 14057) exited] [New Thread 1094719840 (LWP 14251)] [Thread 1346476384 alum_connect ldap://alum.wpi.edu] [New Thread 1335986528 (LWP 14271)] [New Thread 1294027104 (LWP 14285)] [Thread 1126189408 alum closed] [New Thread 1252067680 (LWP 14286)] [Thread 1126189408 (LWP 14022) exited] [New Thread 1398925664 (LWP 14297)] [New Thread 1126189408 (LWP 14308)] [Thread 1294027104 (LWP 14285) exited] [New Thread 1409415520 (LWP 14318)] [Thread 1157658976 wpi closed] [Thread 1157658976 (LWP 13960) exited] [New Thread 1157658976 (LWP 14329)] [New Thread 1294027104 (LWP 14342)] [Thread 1377945952 (LWP 13928) exited] [New Thread 1377945952 (LWP 14353)] [New Thread 1419905376 (LWP 14363)] [Thread 1325496672 (LWP 14100) exited] [Thread 1294027104 (LWP 14342) exited] [Thread 1136679264 wpi closed] [Thread 1136679264 (LWP 14033) exited] [New Thread 1136679264 (LWP 14380)] [Thread 1262557536 (LWP 13971) exited] [Thread 1220598112 (LWP 14111) exited] [Thread 1283537248 (LWP 14140) exited] [Thread 1346476384 alum closed] [Thread 1346476384 (LWP 14069) exited] [Thread 1367456096 wpi_connect ldap://ldapv2back.wpi.edu] phish+: decode.c:779: ber_scanf: Assertion `((ber)->ber_opts.lbo_valid==0x2)' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 1367456096 (LWP 14151)] 0x000000382342e25d in raise () from /lib64/tls/libc.so.6 (gdb) quit The program is running. Exit anyway? (y or n) y Is there debug output you would like from me?

1 0

(ITS#5550) Unable to do scp from and to server ldap
by karim.bourenane＠orange-ftgroup.com 12 Jun '08

12 Jun '08

Full_Name: Bourenane Version: Openldap-server-2.3.41 / and clien OS: FreeBSD 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (57.250.229.136) Hi All My server running fine, with ldap and ldaps. Is i do a command SCP from any server to user i have : server# scp kbourena@ldap-rain:/home/kbourena/toto.txt . Password: unknown user 1206 server# On ldap-rain

1 0

(ITS#5549) slapd SEGV faults in entry_partsize when monitoring
by andreas.mueller＠othello.ch 11 Jun '08

11 Jun '08

Full_Name: Andreas Mueller Version: 2.4.9 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.134.170.35) We have four slapd servers in a mirrormode configuration. This generally works well. We monitor these servers using ldapsearches to cn=Monitor every minute, and collect performance data to construct load/performance graphs with rrdtool. Unfortunately, it sometimes happens that slapd crashes during the monitoring query. Using gdb, we were able to get a stack backtrace: Core was generated by `/usr/local/libexec/slapd'. Program terminated with signal 11, Segmentation fault. #0 0x0005fd48 in entry_partsize () (gdb) bt #0 0x0005fd48 in entry_partsize () #1 0x000603b4 in entry_flatsize () #2 0x0006a5c8 in slap_send_search_entry () #3 0x00134330 in monitor_send_children () #4 0x001348e0 in monitor_back_search () #5 0x000523ac in fe_op_search () #6 0x00051b64 in do_search () #7 0x0004dd8c in connection_operation () #8 0x0004e4c4 in connection_read_thread () #9 0x001a22a8 in ldap_int_thread_pool_wrapper () #10 0xfe3c5800 in __tbl_10_huge_digits () from /lib/libc.so.1 All cores obtained so far show that the segmentation fault occured at the same location inside entry_partsize. Unfortunately we cannot systematically reproduce this behaviour, and we also cannot get the line number (binaries are stripped). We have not tried other versions or other platforms. For production, we use the versions available in package form from www.sunfreeware.com, but the error also happens on servers we have compiled ourselves from the sources.

1 0

(ITS#5548) syncprov evaluates ACL rules with wrong connection info
by rein＠OpenLDAP.org 11 Jun '08

11 Jun '08

Full_Name: Rein Tollevik Version: 2.4.10 (CVS head) OS: linux, solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.215.2.34) Submitted by: rein Access control rules that uses connection data are evaluated using the wrong connection structure. The problem is in syncprov_matchop() where it around line 1233 assigns: op2.o_hdr = op->o_hdr; This causes ACL rules to be tested against the connection that made the change, not the syncrepl connection. It should retain the value from ss->s_op. Rein Tollevik Basefarm AS

1 0

(ITS#5547) JLDAP: unauthenticated bind silently converted to anonymous bind
by johannes.geiger＠vkb.de 11 Jun '08

11 Jun '08

Full_Name: Johannes Geiger Version: n/a OS: Windows, Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.245.172.60) While the documentation of JLDAP states that only authenticated and anonymous bind are supported, JLDAP silently converts an unauthenticated bind to an anonymous one. >From LDAPconnection.java boolean anonymous = false; if( passwd.length == 0) { anonymous = true; // anonymous, passwd length zero with simple bind dn = ""; // set to null if anonymous } (I even think there is a bug in this, as the flag "anonymous" stays on false, if there is a password given but no dn.) This is in fact a security issue, as - while unauthenticated bind usually is forbidden by the server, anonymous bind is allowed - the client using bind for authentication reasons might be led to believe in successful authentication whereas the server only accepted an anonymous bind and did not do any credential verification.

1 0

(ITS#5546) slapd aborts using slapo-pcache when caching negative searches
by toby＠inf.ed.ac.uk 11 Jun '08

11 Jun '08

Full_Name: Toby Blake Version: 2.4.10 OS: Scientific Linux 5.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.215.218.33) Hi there, If I specify a negative ttl when using slapo-pcache, e.g... overlay pcache proxycache bdb 5000 1 500 300 proxycachequeries 10000 proxyattrset 0 uid # proxytemplate using ttl and negative ttl of 1800 proxytemplate (uid=) 0 1800 1800 ... slapd aborts whenever there is a negative search to cache. The cause of this seems to be the assert(0) in pcache.c:pcache_op_cleanup, code fragment starting line 2010... switch ( si->caching_reason ) { case PC_POSITIVE: cache_entries( op, rs, &qc->q_uuid ); break; case PC_SIZELIMIT: qc->q_sizelimit = rs->sr_nentries; break; default: assert( 0 ); break; } The value of si>caching_reason when slapd SIGABRTs is PC_NEGATIVE (which isn't handled by the switch statement). Let me know if you need any more info... Cheers Toby Blake School of Informatics University of Edinburgh

1 0

(ITS#5545) Inconsistency in multi-master setup
by st＠itsc.cuhk.edu.hk 11 Jun '08

11 Jun '08

Full_Name: SiuTo Wong Version: 2.4.10 OS: CentOS 5 (Final) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (137.189.29.184) Have setup 2-node multi-master configuration. Found that when operating on same set of users at high loading, there will be consistency between the masters. The problem can be simulated by running copies of perl script to add/delete the same set of users simultaneously, e.g. add user a001 - a100 & delete user a001 - a100 & or add user a001 - a100 & add user a001 - a100 & There is no problem if multiple threads of add/delete are running, when operating on different sets of users. Attached please find snap of syncrepl setting of one of the servers. All attributes are the same on both masters, except serverId, rid, and provider. Thanks a lot. ====================== cut here ====================== index entryCSN,entryUUID eq lastmod on serverId 2 syncrepl rid=002 provider=ldap://192.168.28.70 starttls=yes tls_reqcert=never tls_cacert=/etc/CA/cacert.pem type=refreshAndPersist retry="5 + 5 +" searchbase="dc=mydomain,dc=hk" schemachecking=off bindmethod=simple binddn="cn=srAdmin,ou=People,dc=mydomain,dc=hk" credentials=youguess interval=00:00:00:05 mirrormode true overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 limits dn.exact="cn=srAdmin,ou=People,dc=cuhk,dc=edu,dc=hk" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited ====================== cut here ======================

1 0

Re: (ITS#5462) Allow setting of RANDOM_FILE for gnutls
by hyc＠symas.com 10 Jun '08

10 Jun '08

pogma(a)thewrittenword.com wrote: > Full_Name: Peter O'Gorman > Version: 2.4.8 > OS: multiple > URL: ftp://ftp.openldap.org/incoming/the-written-word-080410.patch > Submission from: (NULL) (24.76.165.223) > > > gcrypt-1.4.x and later allow the egd socket path to be set. This patch allows > the conf file option to work when building openldap with gnutls on systems that > do not have a /dev/random. Hm, this patch is a silent no-op if the gcrypt function is missing. Currently the randfile option is already documented as being ignored by GNUtls. I would prefer that the behavior is absolutely consistent - either the feature always works or is always ignored. Perhaps we should require gcrypt 1.4 or newer? -- -- 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#5464) ucred guarded by __USE_GNU in glibc 2.8
by hyc＠symas.com 06 Jun '08

06 Jun '08

rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: Any > OS: Linux (glibc 2.8) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.8.71.17) > > > Newer glibc Version guards the definition of struct ucred (e.g. used in > liblutil/getpeereid.c) by __USE_GNU, hence it is only available when _GNU_SOURCE > is defined. > > The matching glibc changelog only say "Cleanup namespace.". Here's the diff: > > http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/bits/… This is a bug in glibc. Luca Scamoni reported it upstream here http://sources.redhat.com/bugzilla/show_bug.cgi?id=6545 -- -- 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#5517) add superclass of existing class fails
by Kurt＠OpenLDAP.org 05 Jun '08

05 Jun '08

On Jun 5, 2008, at 6:31 AM, h.b.furuseth(a)usit.uio.no wrote: > And when they add the absent A and that fails, but we can fix that. I think the best is option is disallow addition of an unlisted subject and disallow the removal of a unlisted subclass (except by replace). This will provide more a more consistent and symmetric behavior. In your initial report, it was this inconsistent and non-symmetric behavior that was your most significant concern. As far as RFC conformance goes, I argue that with this change, the behavior would be fully conformant. No where in the RFCs does it require servers to return implicitly added values, no where in the RFCs does it preclude servers from removing implicitly added values upon removal of values which caused there addition. The concern I have is impact on clients which add a class and then delete that class, expecting it just to work. But if that class is subclass, and the add causes the insertion of some other class, then the delete will either leave that other class there or lead to an error, both undesirable and unexpected behaviors. I think the mistake that LDAP designers made (long ago) was not to require LDAP CLIENTS to provide all (non-top) classes, as is required of DAP clients. Regarding objectClass being special (especially with regard to its equality matching rule): consider (objectClass=top) and X.500 "top may be omitted" statement. -- Kurt

1 0

Re: (ITS#5517) add superclass of existing class fails
by h.b.furuseth＠usit.uio.no 05 Jun '08

05 Jun '08

(I seem to be arguing myself into two different corners here, but anyway...) Kurt(a)OpenLDAP.org writes: >On May 24, 2008, at 2:37 PM, h.b.furuseth(a)usit.uio.no wrote: >> ando(a)sys-net.it writes: >>> The issue right now is caused by the fact that comparing present >>> values with the asserted one causes objectSubClassMatch() to check >>> for match including superiors. >> >> This looks like a bug to me. > > Maybe in the RFCs. Yes, to my eyes it cleary says what you say was not intended. >> objectClass has EQUALITY matching rule >> objectIdentifierMatch, which does not follow the object class >> inheritance chain. > > Yes, but objectClass is quite special (despite being a > userApplications attribute). Hpmh. Not very, according to RFCs 4511-12. Maybe we all "knew" it so well that we never noticed, during several IETF WGs. > For instance, (objectClass=*) is to match DSEs which don't have an > objectClass attribute. That's explicitly mentioned in RFC 4512 for the root DSE, as is the (objectClass=subschema) special case. Section RFC 4512 section 3.3 says each entry in the DIT has an 'objectClass' attribute. Are other DSEs not in the DIT? There is RFC 4511 section 4.5.1 (Search Request)'s statement that List and Read operations can be emulated with a search for (objectClass=*). Nowhere else can I find that (objectClass=*) is special. > Likewise, objectClass=foo can match objectClass attributes which > don't explicitly contain foo. Not according what the RFCs say to my eyes, (below): >> See RFC 4517 section 4.2.26. RFC 4512 section 3.3 >> (the 'objectClass' attribute) does not special-case this. >> >> What makes slapd work is that it also disobeys RFC 4512 section 3.3: >> "When creating an entry or adding an 'objectClass' value to an >> entry, >> all superclasses of the named classes SHALL be implicitly added as >> well if not already present." > >> This doesn't say the classes shall be considered to be implicitly >> present, like slapd does. > > You are reading 3.3 as if it said "SHALL be added (by the server)". > It doesn't say "SHALL be added (by the server). It says "SHALL be > implicitly added" (presumedly by the server). I don't see how that changes anything, but then I'm not a native English speaker. > This was discussed during LDAPbis discussions. As the Editor of RFC > 4512, I can say that it was my intent to allow servers to merely treat > superclasses as being present. Hard do argue with that. I couldn't find these discussions though. Do you remember where/when? All I found was this, which seems to imply the opposite: http://www.openldap.org/lists/ietf-ldapbis/200403/msg00023.html >> Instead slapd should add the missing classes to the actual object, > > Doing so is problematic. A client which adds B then deletes B would > be surprised by non-net-zero result of the operation(s). Clients will be surprised anyway. Currently clients are being surprised when (objectClass=A) matches even though A is absent. And when they add the absent A and that fails, but we can fix that. >> just like it adds some other attribute/values >> implicitly (createTimestamp, subschemaSubentry, etc). > > These are operational attributes. ObjectClass is an userApplications > attribute. Servers should not muck with the values of userApplication > attributes. Well, it does when it adds missing naming attributes (since RFC4511, ITS#5412). I guess that is a better example. And it "mucks with" objectClass in a different way anyway, as you've just pointed out. -- Hallvard

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 05 Jun '08

05 Jun '08

Hi, On Wed, Jun 4, 2008 at 2:20 PM, Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no> wrote: > I haven't follwed this ITS, but a few notes anyway: > > unix.gurus(a)gmail.com writes: >> monitorCounter >> monitorCounter does not have an equality matching rule, > > Yes it does. back-monitor/init.c line 1710. What are you looking at? > (Hmm, I too had the impression it had no EQUALITY rule...) I'm working with OpenLDAP 2.4.9. You're right. integerMatch has an equality rule but no normalizing function. The logic that determines whether a normalized value should exist says: have_norm = a->a_desc->ad_type->sat_equality != NULL && a->a_desc->ad_type->sat_equality->smr_normalize != NULL; ... new_nval = nvals != NULL; ... if ( have_norm != new_nval ) { assert() So we don't need nvals for integers. For this reason I was right to remove the nval for monitorCounter, monitorOpInitiated, monitorOpCompleted, but my reasoning was wrong. >> monitorOpCompleted >> monitorOpInitiated >> These attributes do not have equality matching rules, > > These do too, inherited from monitorCounter. See above. > it doesn't work right in 2.3 however: > > ldapsearch -LLL -bcn=monitor -s one '(monitorCounter=0)' monitorCounter > dn: cn=Operations,cn=Monitor > monitorOpInitiated: 231542983 > monitorOpCompleted: 231542982 I wonder if val is being maintained and nval is being left at 0. The code at the end of monitor_subsys_ops_update() maintains a_vals but not a_nvals, so that is probably the problem: /* NOTE: no minus sign is allowed in the counters... */ UI2BV( &a->a_vals[ 0 ], nInitiated ); ldap_pvt_mp_clear( nInitiated ); ... /* NOTE: no minus sign is allowed in the counters... */ UI2BV( &a->a_vals[ 0 ], nCompleted ); ldap_pvt_mp_clear( nCompleted ); >> namingContexts >> configContext >> dynamicSubtrees >> >> These attributes do not have equality matching rules, but probably >> should. I add 'EQUALITY distinguishedNameMatch' to them in >> schema_prep.c. > > No, that breaks the definitions in the RFCs they come from. (See their > DESC strings.) I don't know why they lack EQUALITY rules, maybe we just > forgot when we defined them, but that's the way it is. Same with > supportedControl. Ok, so we should not define nvals for them? > monitorContext, readOnly and the olc* attributes are defined by OpenLDAP > (their OIDs start with 1.3.6.1.4.1.4203) and can be modified if we feel > like it. Personally I prefer attrs to have the matching rules they can > have unless there is a reason not to, but I didn't write these modules > so I don't know if there _is_ a reason not to. -- Thanks, Sean Burford

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by h.b.furuseth＠usit.uio.no 04 Jun '08

04 Jun '08

I haven't follwed this ITS, but a few notes anyway: unix.gurus(a)gmail.com writes: > monitorCounter > monitorCounter does not have an equality matching rule, Yes it does. back-monitor/init.c line 1710. What are you looking at? (Hmm, I too had the impression it had no EQUALITY rule...) > monitorOpCompleted > monitorOpInitiated > These attributes do not have equality matching rules, These do too, inherited from monitorCounter. it doesn't work right in 2.3 however: ldapsearch -LLL -bcn=monitor -s one '(monitorCounter=0)' monitorCounter dn: cn=Operations,cn=Monitor monitorOpInitiated: 231542983 monitorOpCompleted: 231542982 > namingContexts > configContext > dynamicSubtrees > > These attributes do not have equality matching rules, but probably > should. I add 'EQUALITY distinguishedNameMatch' to them in > schema_prep.c. No, that breaks the definitions in the RFCs they come from. (See their DESC strings.) I don't know why they lack EQUALITY rules, maybe we just forgot when we defined them, but that's the way it is. Same with supportedControl. monitorContext, readOnly and the olc* attributes are defined by OpenLDAP (their OIDs start with 1.3.6.1.4.1.4203) and can be modified if we feel like it. Personally I prefer attrs to have the matching rules they can have unless there is a reason not to, but I didn't write these modules so I don't know if there _is_ a reason not to. -- Hallvard

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 04 Jun '08

04 Jun '08

HI, On Fri, May 30, 2008 at 2:40 AM, <hyc(a)symas.com> wrote: > hyc(a)symas.com wrote: >> We'll probably need to discuss on the -devel list what steps to take from here. >> > I wrote the attached patch for the original issue. Unfortunately it asserted > right away: > ... > > It was adding the createTimestamp attribute, without providing normalized > values. slap_add_opattrs was written before the generalizedTimeNormalize > function was written... I suspect there will be a fair number of cases that > need to be cleaned up. I've identified these attributes as having differences between their nval population and their schema. I've been using Google coredumper instead of assertions to mark places where normalization looks bad. In this way, I get a bunch of core files to look through after a run instead of a single assertion. Once all of the attributes that have bad normalization have been identified in this way, I'll go back over the source and look for other places where they are used. I haven't found all of the normalization differences yet, but I wanted to check in to ensure I'm on the right path. I would like your comments on whether these look like the right changes to make. You can refer to ftp://ftp.openldap.org/incoming/sburford-initial-normalization-20080604.pat… for the details. createTimestamp createTimestamp does have an equality matching rule, as I think it should. The buffer timestamp is populated with a generalized time by slap_timestamp(), so I add &timestamp as the nval for the calls to attr_merge_one in add.c slap_add_opattrs() and schema.c schema_info(). I also use a slight variation of this for createTimestamp in slapadd.c slapadd(). modifyTimestamp Same arguments and modifications as createTimestamp. modifyTimestamp is also used in modify.c slap_mods_opattrs(), where I ch_malloc a new BerVarray for the mod->sml_nvalues. I dont use the same BerVarray for vals and nvals in case whatever frees mod entries frees them as separate pointers (double free). Does something free all of the vals and nvals in the modify list? entryCSN entryCSN does have an equality matching rule, as I think it should. In add.c slap_add_opattrs() I change the attr_merge_one into an attr_merge_normalize_one with op->o_tmpmemctx as the memory context. I haven't looked into the memory context argument, but assume it contains a list of things to free when the context is finished with? In slapadd I also change the attr_merge_one into an attr_merge_normalize_one but I pass a NULL memory context, since slapadd is short lived and there are other examples like this in the nearby source code. In modify.c slap_mods_opattrs() I ch_malloc a new BerVarray for the entryCSN nval and use attr_normalize_one to populate it. Again I assume something frees the components of the modify list later. contextCSN contextCSN does have an equality matching rule, as I think it should. In ctxcsn.c slap_create_context_csn_entr() I change attr_merge_one into attr_merge_normalize_one with a NULL memory context. In overlays/syncprov.c syncprov_checkpoint() and syncrepl.c syncrepl_updateCookie() it is a bit more difficult because a local modlist is created without any attr_merge calls, so I ch_malloc an array for the nvals, and populate it with attr_normalize and use ber_array_bvfree to free it. monitorCounter monitorCounter does not have an equality matching rule, so I remove the nval argument from attr_merge_one() in back-monitor/conn.c monitor_subsys_conn_init() (affects counters for max FD, total conns and current conns). monitorOpCompleted monitorOpInitiated These attributes do not have equality matching rules, so I remove the nval argument from attr_merge_one() in back-monitor/operation.c monitor_subsys_ops_init(). monitorContext namingContexts configContext dynamicSubtrees These attributes do not have equality matching rules, but probably should. I add 'EQUALITY distinguishedNameMatch' to them in schema_prep.c. olcRootDN olcSchemaDN These attributes do not have equality matching rules, but probably should. I add 'EQUALITY distinguishedNameMatch' to them in bconfig.c. supportedControl This attribute does not have an equality matching rule, but probably should. I add 'EQUALITY objectIdentifierMatch' to it in schema_prep.c. readOnly This attribute does not have an equality matching rule, I don't know if it should. I NULLed the nval passed to attr_merge_one in back-monitor/database.c. default_referral: In rootdse.c root_dse_info() I change attr_merge to attr_merge_normalize for default_referral, since it has an equality matching rule. There doesn't seem to be a memory context in use here. I suspect this normalization might result in memory leakage unless followed by a free in root_dse_info()? Also, bconfig.c config_build_attrs() contains this logic which calls attr_merge_normalize() for values that don't need normalization. attr_merge_normalize won't normalize them though, so it should be fine: if ( c->rvalue_nvals ) attr_merge(e, ct[i].ad, c->rvalue_vals, c->rvalue_nvals); else attr_merge_normalize(e, ct[i].ad, c->rvalue_vals, NULL); > I don't have time at the moment to chase them all down. > Anyone else want to jump in here? If not, we may have to push this back a bit. > Note that this patch will probably require a fair number of databases to be > reloaded. The attributes listed above tend to agree with that, but if they really were not being normalized before storage I'm surprised that the original assertion wasn't hit more often? -- Thanks, Sean Burford

1 0

Re: (ITS#5544) libRSAglue not found
by hyc＠symas.com 04 Jun '08

04 Jun '08

quanah(a)zimbra.com wrote: > --On Tuesday, June 03, 2008 9:01 PM +0000 steven(a)vaningelgem.be wrote: > >> ------=_Part_3208_8915130.1212526882765 >> Content-Type: text/plain; charset=UTF-8 >> Content-Transfer-Encoding: 7bit >> Content-Disposition: inline >> >> Hi Howard, >> >> >> I did read the INSTALL file, and I know about the LIBS variable... Let's >> see... I added a LIBS="-lssl -lsasl2" to it... So in the config.log that >> changed the line to include (at the end) -lssl -lsasl2, as it's supposed >> to do... >> But it didn't changed the fact that -lRSAglue was still included, which is >> the original reason I posted this. >> >> When I check out the openSSL sources, I see that the v0.9.6 branch op >> OpenSSL is the only branch having that RSAglue in it (with the latest >> version from March 2004)... All later versions (0.9.7 and higher) don't >> have this RSAglue in it anymore... >> >> Would that mean that I should build OpenLDAP against a version of OpenSSL >> of 4 years ago? >> >> That's why I submitted the bug in the first place! Because this RSAglue >> library cannot be found anymore... As you've already noted, no current version of OpenSSL uses libRSAglue. If you're running into this, then something is flaky in your OpenSSL build. That is not an OpenLDAP issue. However, if you examine the error messages in config.log, you should be able to see what tests are failing with libssl. > I build OpenLDAP against OpenSSL 0.9.8g all the time without problem in my > own custom location (/opt/zimbra/openssl/lib). You simply need to define > your various variables to gcc correctly. > > I suggest reading the OpenLDAP FAQ, which has an article or two on linking > against non-standard locations. My guess is you have some other library > pulling in libRSAglue. -- -- 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#5544) libRSAglue not found
by quanah＠zimbra.com 04 Jun '08

04 Jun '08

--On Tuesday, June 03, 2008 9:01 PM +0000 steven(a)vaningelgem.be wrote: > ------=_Part_3208_8915130.1212526882765 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > Hi Howard, > > > I did read the INSTALL file, and I know about the LIBS variable... Let's > see... I added a LIBS="-lssl -lsasl2" to it... So in the config.log that > changed the line to include (at the end) -lssl -lsasl2, as it's supposed > to do... > But it didn't changed the fact that -lRSAglue was still included, which is > the original reason I posted this. > > When I check out the openSSL sources, I see that the v0.9.6 branch op > OpenSSL is the only branch having that RSAglue in it (with the latest > version from March 2004)... All later versions (0.9.7 and higher) don't > have this RSAglue in it anymore... > > Would that mean that I should build OpenLDAP against a version of OpenSSL > of 4 years ago? > > That's why I submitted the bug in the first place! Because this RSAglue > library cannot be found anymore... I build OpenLDAP against OpenSSL 0.9.8g all the time without problem in my own custom location (/opt/zimbra/openssl/lib). You simply need to define your various variables to gcc correctly. I suggest reading the OpenLDAP FAQ, which has an article or two on linking against non-standard locations. My guess is you have some other library pulling in libRSAglue. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5544) libRSAglue not found
by steven＠vaningelgem.be 03 Jun '08

03 Jun '08

------=_Part_3208_8915130.1212526882765 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Howard, I did read the INSTALL file, and I know about the LIBS variable... Let's see... I added a LIBS="-lssl -lsasl2" to it... So in the config.log that changed the line to include (at the end) -lssl -lsasl2, as it's supposed to do... But it didn't changed the fact that -lRSAglue was still included, which is the original reason I posted this. When I check out the openSSL sources, I see that the v0.9.6 branch op OpenSSL is the only branch having that RSAglue in it (with the latest version from March 2004)... All later versions (0.9.7 and higher) don't have this RSAglue in it anymore... Would that mean that I should build OpenLDAP against a version of OpenSSL of 4 years ago? That's why I submitted the bug in the first place! Because this RSAglue library cannot be found anymore... I would be very happy if you could correct me! I really would like you to give me a little more explanation as to how the LIBS environment variable would solve the problem... Warm Regards, Steven 2008/6/3 Howard Chu <hyc(a)symas.com>: > steven(a)vaningelgem.be wrote: > >> Full_Name: Steven Van Ingelgem >> Version: CVS >> OS: Ubuntu 8.04 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (194.78.5.130) >> >> >> I compiled openssl 0.9.8g in static mode and put those files inside >> /myssl/lib >> or /myssl/include >> >> Now when I configure OpenLDAP with the following command: >> >> chmod +x configure build/version.sh&& LDFLAGS="-L/myssl/lib" >> CPPFLAGS="-I/myssl/include" CFLAGS="-I/myssl/include" ./configure >> --disable-debug --disable-slapd --disable-backends --disable-local >> --disable-ipv6 --disable-syslog --enable-dynamic --enable-static >> --disable-shared --with-cyrus-sasl --with-tls=openssl >> >> >> It complains it cannot find openssl (due to it not being able to find >> "-lRSAglue")... I've been looking around for quite some time, but it seems >> not >> to exist (also not in some default packages in both Ubuntu and Debian). >> Also information for rsaref is sparse, but I could find it inside the >> openssl >> package as in "demos/engines"... >> >> This seems all very strange... Is there something I'm missing or is this >> really >> a bug in OpenLDAP? >> > > Not an OpenLDAP bug. Specify the correct libraries in LIBS when running > configure, like the INSTALL file says. 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/ > ------=_Part_3208_8915130.1212526882765 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Howard, I did read the INSTALL file, and I know about the LIBS variable... Let's see... I added a LIBS="-lssl -lsasl2" to it... So in the config.log that changed the line to include (at the end) -lssl -lsasl2, as it's supposed to do... But it didn't changed the fact that -lRSAglue was still included, which is the original reason I posted this. When I check out the openSSL sources, I see that the v0.9.6 branch op OpenSSL is the only branch having that RSAglue in it (with the latest version from March 2004)... All later versions (0.9.7 and higher) don't have this RSAglue in it anymore... Would that mean that I should build OpenLDAP against a version of OpenSSL of 4 years ago? That's why I submitted the bug in the first place! Because this RSAglue library cannot be found anymore... I would be very happy if you could correct me! I really would like you to give me a little more explanation as to how the LIBS environment variable would solve the problem... Warm Regards, Steven <div class="gmail_quote">2008/6/3 Howard Chu <<a href="mailto:hyc@symas.com">hyc(a)symas.com</a>>: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <a href="mailto:steven@vaningelgem.be" target="_blank">steven(a)vaningelgem.be</a> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Full_Name: Steven Van Ingelgem Version: CVS OS: Ubuntu 8.04 URL: <a href="ftp://ftp.openldap.org/incoming/" target="_blank">ftp://ftp.openldap.org/incoming/</a> Submission from: (NULL) (<a href="http://194.78.5.130" target="_blank">194.78.5.130</a>) I compiled openssl 0.9.8g in static mode and put those files inside /myssl/lib or /myssl/include Now when I configure OpenLDAP with the following command: chmod +x configure build/version.sh&&  LDFLAGS="-L/myssl/lib" CPPFLAGS="-I/myssl/include" CFLAGS="-I/myssl/include" ./configure --disable-debug --disable-slapd --disable-backends --disable-local --disable-ipv6 --disable-syslog --enable-dynamic --enable-static --disable-shared --with-cyrus-sasl --with-tls=openssl It complains it cannot find openssl (due to it not being able to find "-lRSAglue")... I've been looking around for quite some time, but it seems not to exist (also not in some default packages in both Ubuntu and Debian). Also information for rsaref is sparse, but I could find it inside the openssl package as in "demos/engines"... This seems all very strange... Is there something I'm missing or is this really a bug in OpenLDAP? </blockquote> Not an OpenLDAP bug. Specify the correct libraries in LIBS when running configure, like the INSTALL file says. This ITS will be closed. --  -- Howard Chu  CTO, Symas Corp.           <a href="http://www.symas.com" target="_blank">http://www.symas.com</a>  Director, Highland Sun     <a href="http://highlandsun.com/hyc/" target="_blank">http://highlandsun.com/hyc/</a>  Chief Architect, OpenLDAP  <a href="http://www.openldap.org/project/" target="_blank">http://www.openldap.org/project/</a> </blockquote></div> ------=_Part_3208_8915130.1212526882765--

1 0

Re: (ITS#5544) libRSAglue not found
by hyc＠symas.com 03 Jun '08

03 Jun '08

steven(a)vaningelgem.be wrote: > Full_Name: Steven Van Ingelgem > Version: CVS > OS: Ubuntu 8.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.78.5.130) > > > I compiled openssl 0.9.8g in static mode and put those files inside /myssl/lib > or /myssl/include > > Now when I configure OpenLDAP with the following command: > > chmod +x configure build/version.sh&& LDFLAGS="-L/myssl/lib" > CPPFLAGS="-I/myssl/include" CFLAGS="-I/myssl/include" ./configure > --disable-debug --disable-slapd --disable-backends --disable-local > --disable-ipv6 --disable-syslog --enable-dynamic --enable-static > --disable-shared --with-cyrus-sasl --with-tls=openssl > > > It complains it cannot find openssl (due to it not being able to find > "-lRSAglue")... I've been looking around for quite some time, but it seems not > to exist (also not in some default packages in both Ubuntu and Debian). > Also information for rsaref is sparse, but I could find it inside the openssl > package as in "demos/engines"... > > This seems all very strange... Is there something I'm missing or is this really > a bug in OpenLDAP? Not an OpenLDAP bug. Specify the correct libraries in LIBS when running configure, like the INSTALL file says. 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#5503) Openldap segmentation fault when running syncrepl.
by chuck.short＠canonical.com 03 Jun '08

03 Jun '08

With this patch applied I was unable to reproduce this crash. Thanks chuck openldap-its(a)OpenLDAP.org wrote: > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#5503. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#5503) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#5503) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=5503 > > Please remember to retain your issue tracking number (ITS#5503) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > >

1 0

(ITS#5544) libRSAglue not found
by steven＠vaningelgem.be 03 Jun '08

03 Jun '08

Full_Name: Steven Van Ingelgem Version: CVS OS: Ubuntu 8.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.78.5.130) I compiled openssl 0.9.8g in static mode and put those files inside /myssl/lib or /myssl/include Now when I configure OpenLDAP with the following command: chmod +x configure build/version.sh && LDFLAGS="-L/myssl/lib" CPPFLAGS="-I/myssl/include" CFLAGS="-I/myssl/include" ./configure --disable-debug --disable-slapd --disable-backends --disable-local --disable-ipv6 --disable-syslog --enable-dynamic --enable-static --disable-shared --with-cyrus-sasl --with-tls=openssl It complains it cannot find openssl (due to it not being able to find "-lRSAglue")... I've been looking around for quite some time, but it seems not to exist (also not in some default packages in both Ubuntu and Debian). Also information for rsaref is sparse, but I could find it inside the openssl package as in "demos/engines"... This seems all very strange... Is there something I'm missing or is this really a bug in OpenLDAP? Thanks

1 0

Re: (ITS#5541) slapd segfaults with specific search on string bdb and hdb backend (closing, already solved)
by hyc＠symas.com 03 Jun '08

03 Jun '08

Piotr Wadas wrote: > It works as expected with CVS current OPENLDAP_REL_ENG_2_4 > version (didn't test -devel version), > Deep respect& many thanks for your amazing work with free ldap software - Thanks for the feedback, glad it's working for you. This ITS will be closed. > Piotr Wadas > > On Mon, 2 Jun 2008, Howard Chu wrote: > >> pwadas(a)jewish.org.pl wrote: >>> This message is in MIME format. The first part should be readable text, >>> while the remaining parts are likely unreadable without MIME-aware tools. >> Looks like you didn't have the correct frame selected before issuing those >> print commands. >> >> At any rate, I suspect this issue has already been fixed in the 2.4.10 release >> candidate. Please test with the 2.4 release in CVS. >> >>>> =20 >>>> Hello, >>>> Regarding http://www.openldap.org/its/index.cgi?findid=3D5541 >>>> =20 >>>> Link to indexes file and full schema, including custom schema >>>> is mailed to Howard Chu, as I'd like to avoid spreading it. >>>> It says there's no variable "ava" nor "mr", as below >>>> =20 >>>> I keep gdb on detached screen, so I additional variables >>>> need to be printed I have'em at hand. >>>> =20 >>>> ------------------------------- >>>> (gdb) print *ava->aa_desc >>>> No symbol "ava" in current context. >>>> (gdb) print *mr >>>> No symbol "mr" in current context. >>>> (gdb) print ava->aa_desc >>>> No symbol "ava" in current context. >>>> (gdb) print mr >>>> No symbol "mr" in current context. >> >> > -- -- 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#5541) slapd segfaults with specific search on string bdb and hdb backend (closing, already solved)
by pwadas＠jewish.org.pl 02 Jun '08

02 Jun '08

It works as expected with CVS current OPENLDAP_REL_ENG_2_4 version (didn't test -devel version), Deep respect & many thanks for your amazing work with free ldap software - Piotr Wadas On Mon, 2 Jun 2008, Howard Chu wrote: > pwadas(a)jewish.org.pl wrote: > > This message is in MIME format. The first part should be readable text, > > while the remaining parts are likely unreadable without MIME-aware tools. > > Looks like you didn't have the correct frame selected before issuing those > print commands. > > At any rate, I suspect this issue has already been fixed in the 2.4.10 release > candidate. Please test with the 2.4 release in CVS. > > > > =20 > > > Hello, > > > Regarding http://www.openldap.org/its/index.cgi?findid=3D5541 > > > =20 > > > Link to indexes file and full schema, including custom schema > > > is mailed to Howard Chu, as I'd like to avoid spreading it. > > > It says there's no variable "ava" nor "mr", as below > > > =20 > > > I keep gdb on detached screen, so I additional variables > > > need to be printed I have'em at hand. > > > =20 > > > ------------------------------- > > > (gdb) print *ava->aa_desc > > > No symbol "ava" in current context. > > > (gdb) print *mr > > > No symbol "mr" in current context. > > > (gdb) print ava->aa_desc > > > No symbol "ava" in current context. > > > (gdb) print mr > > > No symbol "mr" in current context. > > >

1 0

Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie
by rein＠OpenLDAP.org 02 Jun '08

02 Jun '08

On Mon, 2 Jun 2008, hyc(a)symas.com wrote: > Rein Tollevik wrote: > >> I see you have commited an alternative version to syncrepl.c. This >> version don't include the serverID in the cookie when syncrepl is used on >> the glue database itself, only when used on subordinate DBs. And >> unfortunately, it is when used on the glue database it is needed (at least >> in my configuration). > > Hm, can you show the configuration you're dealing with now? Is it still > similar to your test053 setup? (By the way, the test053 in HEAD works > with the current code. No, that test has a stripped down config used to trigger that bug. To show this problem the producer2 would have to syncrepl the basedn back from the first producer, and producer2 would need a subordinate database which it manages itself (the base DN for the syncrepl used by the first producer). I'm thinking about creating a new test script that tests more of my configuration. It seems as my config is a bit off the usual, as I have managed to hit a lot of bugs lately... And there are still a few open issues I would like solved before everything works as I wish, although I think all (or at least most) of my critical problems has been solved now. >> So, I still think we have to always include it when it is configured. > > Probably. But when I went down that route it seemed to require configuring it > in several cases that never needed it before, which is why I changed approach. It was my intention to avoid changes to existing configurations, and I do believe it wasn't needed with my approach. Although I think it would be preferrable (but not necessary) if we could forbid explicit usage of serverID=0. That would require a config change for those that used it. But a change to another unused ID should be sufficient, i.e no changes to existing databases. >> Unless there exist some easy way to know that a subordinate DB is not >> managed by syncrepl. The only solution I know to that is to loop through >> all the subordinate DBs and compare the rootdn values. > > We can think about this some more but I'd like to get 2.4.10 out now. A final > resolution of this issue may have to wait for 2.4.11. That should be OK, this bug isn't critical as it is possible to configure around it. Rein

1 0

Re: (ITS#5541) slapd segfaults with specific search on string bdb and hdb backend
by hyc＠symas.com 02 Jun '08

02 Jun '08

pwadas(a)jewish.org.pl wrote: > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. Looks like you didn't have the correct frame selected before issuing those print commands. At any rate, I suspect this issue has already been fixed in the 2.4.10 release candidate. Please test with the 2.4 release in CVS. >> =20 >> Hello, >> Regarding http://www.openldap.org/its/index.cgi?findid=3D5541 >> =20 >> Link to indexes file and full schema, including custom schema >> is mailed to Howard Chu, as I'd like to avoid spreading it. >> It says there's no variable "ava" nor "mr", as below >> =20 >> I keep gdb on detached screen, so I additional variables >> need to be printed I have'em at hand. >> =20 >> ------------------------------- >> (gdb) print *ava->aa_desc >> No symbol "ava" in current context. >> (gdb) print *mr >> No symbol "mr" in current context. >> (gdb) print ava->aa_desc >> No symbol "ava" in current context. >> (gdb) print mr >> No symbol "mr" in current context. -- -- 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#5541) slapd segfaults with specific search on string bdb and hdb backend
by pwadas＠jewish.org.pl 02 Jun '08

02 Jun '08

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589865158-1366188462-1212434906=:9248 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <Pine.LNX.4.64.0806022128461.9248(a)kehillah.jewish.org.pl> Hello, Forwarding as requested, sorry for mislead. Regards, PW. ---------- Forwarded message ---------- Date: Mon, 02 Jun 2008 10:33:14 -0700 From: Quanah Gibson-Mount <quanah(a)zimbra.com> To: Piotr Wadas <pwadas(a)jewish.org.pl>, openldap-software(a)openldap.org Subject: Re: slapd 2.4.7-2.4.9 segfaults with some specific search Information for your ITS should be sent to the ITS address with the bug num= ber in the subject, as the email you were sent after filing the ITS instructed,= and not to openldap-software. Thanks. --Quanah --On May 31, 2008 8:11:46 AM +0200 Piotr Wadas <pwadas(a)jewish.org.pl> wrote= : >=20 > Hello, > Regarding http://www.openldap.org/its/index.cgi?findid=3D5541 >=20 > Link to indexes file and full schema, including custom schema > is mailed to Howard Chu, as I'd like to avoid spreading it. > It says there's no variable "ava" nor "mr", as below >=20 > I keep gdb on detached screen, so I additional variables > need to be printed I have'em at hand. >=20 > ------------------------------- > (gdb) print *ava->aa_desc > No symbol "ava" in current context. > (gdb) print *mr > No symbol "mr" in current context. > (gdb) print ava->aa_desc > No symbol "ava" in current context. > (gdb) print mr > No symbol "mr" in current context. > (gdb) info variables ava > All variables matching regular expression "ava": >=20 > Non-debugging symbols: > 0xb7cc61ac __set_robust_list_avail > 0xb7cc61ac __set_robust_list_avail > 0xb7c8d10e not_available > 0xb7f75da0 available_ciphers > (gdb) info variables mr > All variables matching regular expression "mr": > ---------------- >=20 > But I found this may be also relevant: >=20 > frame 3: >=20 > (gdb) frame 3 > # 3 0xb7f18235 in ber_bvarray_free_x (a=3D0xa976b354, ctx=3D0x8279658) a= t > /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory. > c:731 731 ber_memfree_x(a[i].bv_val, ctx); > (gdb) info args > a =3D (BerVarray) 0xa976b354 > ctx =3D (void *) 0x8279658 > (gdb) print *a > $30 =3D {bv_len =3D 4, bv_val =3D 0xa976b36c "\200"} > (gdb) print *a->bv_val > $31 =3D -128 '\200' >=20 > frame 4 >=20 >=20 > $44 =3D > { > o_hdr =3D 0x82793b8, o_tag =3D 99, o_time =3D 1212212344, o_tincr =3D 1= , o_bd =3D > 0xa9c6af80, o_req_dn =3D > { > bv_len =3D 29, bv_val =3D 0xa976b154 "dc=3Ddns,dc=3Dnameservers,dc=3Dco= m,dc=3Deu"} > , o_req_ndn =3D > { > bv_len =3D 29, bv_val =3D 0xa976b1a4 "dc=3Ddns,dc=3Dnameservers,dc=3Dco= m,dc=3Deu"} > , o_request =3D > { > oq_add =3D > { > rs_modlist =3D 0x2, rs_e =3D 0x0} > , oq_bind =3D > { > rb_method =3D 2, rb_cred =3D > { > bv_len =3D 0, bv_val =3D 0xffffffff < Address 0xffffffff out of bou= nds > >} , rb_edn =3D > { > bv_len =3D 4294967295, bv_val =3D 0x0} > , rb_ssf =3D 0, rb_mech =3D > { > bv_len =3D 0, bv_val =3D 0xa976b2bc "=A0"} > } > , oq_compare =3D > { > rs_ava =3D 0x2} > , oq_modify =3D > { > rs_mods =3D > { > rs_modlist =3D 0x2, rs_no_opattrs =3D 0 '\0'} > , rs_increment =3D -1} > , oq_modrdn =3D > { > rs_mods =3D > { > rs_modlist =3D 0x2, rs_no_opattrs =3D 0 '\0'} > , rs_deleteoldrdn =3D -1, rs_newrdn =3D > { > bv_len =3D 4294967295, bv_val =3D 0x0} > , rs_nnewrdn =3D > { > bv_len =3D 0, bv_val =3D 0x0} > , rs_newSup =3D 0xa976b2bc, rs_nnewSup =3D 0x79} > , oq_search =3D > { > rs_scope =3D 2, rs_deref =3D 0, rs_slimit =3D -1, rs_tlimit =3D > =09-1, rs_limit =3D 0x0, rs_attrsonly =3D 0, rs_attrs =3D > =090x0, rs_filter =3D 0xa976b2bc, rs_filterstr =3D > { > bv_len =3D 121, bv_val =3D > =09 0xa976b2cc >=20 > "(&(objectClass=3DdNSDomain)(associatedDomain=3D*fakedomain.com)(customer= ID=3D1 > 0125)(sOARecord=3D*)(nSRecord=3D*)(topLevelDomain=3DTRUE))"} } > , oq_abandon =3D > { > rs_msgid =3D 2} > , oq_cancel =3D > { > rs_msgid =3D 2} > , oq_extended =3D > { > rs_reqoid =3D > { > bv_len =3D 2, bv_val =3D 0x0} > , rs_flags =3D -1, rs_reqdata =3D 0xffffffff} > , oq_pwdexop =3D > { > rs_extended =3D > { > =09rs_reqoid =3D > =09{ > =09bv_len =3D 2, bv_val =3D 0x0} > , rs_flags =3D -1, rs_reqdata =3D 0xffffffff} > , rs_old =3D > { > bv_len =3D 0, bv_val =3D 0x0} > , rs_new =3D > { > bv_len =3D 0, bv_val =3D 0xa976b2bc "=A0"} > , rs_mods =3D 0x79, rs_modtail =3D 0xa976b2cc} > } > , o_abandon =3D 0, o_cancel =3D 0, o_groups =3D 0x0, > o_do_not_cache =3D 0 '\0', o_is_auth_check =3D 0 '\0', o_acl_priv =3D > ACL_NONE, o_nocaching =3D 0 '\0', o_delete_glue_parent =3D > 0 '\0', o_no_schema_check =3D 0 '\0', o_no_subordinate_glue =3D > 0 '\0', o_ctrlflag =3D '\0' < repeats 31 times >, o_controls =3D > 0x82794e4, o_authz =3D > { > sai_method =3D 128, sai_mech =3D > { > bv_len =3D 0, bv_val =3D 0x0} > , sai_dn =3D > { > bv_len =3D 28, bv_val =3D 0x8279b70 "cn=3DDirectory Manager,dc=3Dcom,= dc=3Deu"} > , sai_ndn =3D > { > bv_len =3D 28, bv_val =3D 0x8279b98 "cn=3Ddirectory manager,dc=3Dcom,= dc=3Deu"} > , sai_ssf =3D 0, sai_transport_ssf =3D 0, sai_tls_ssf =3D 0, sai_sasl_s= sf =3D 0} > , o_ber =3D 0x8264b98, o_res_ber =3D 0x0, o_callback =3D > 0xa9c6b07c, o_ctrls =3D 0x0, o_csn =3D > { > bv_len =3D 0, bv_val =3D 0x0} > , o_private =3D 0x0, o_extra =3D > { > slh_first =3D 0x0} > , o_next =3D > { > stqe_next =3D 0x0} > } >=20 -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --1589865158-1366188462-1212434906=:9248--

1 0

Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie
by hyc＠symas.com 02 Jun '08

02 Jun '08

Rein Tollevik wrote: > I see you have commited an alternative version to syncrepl.c. This > version don't include the serverID in the cookie when syncrepl is used on > the glue database itself, only when used on subordinate DBs. And > unfortunately, it is when used on the glue database it is needed (at least > in my configuration). Hm, can you show the configuration you're dealing with now? Is it still similar to your test053 setup? (By the way, the test053 in HEAD works with the current code.) > So, I still think we have to always include it when it is configured. Probably. But when I went down that route it seemed to require configuring it in several cases that never needed it before, which is why I changed approach. > Unless there exist some easy way to know that a subordinate DB is not > managed by syncrepl. The only solution I know to that is to loop through > all the subordinate DBs and compare the rootdn values. We can think about this some more but I'd like to get 2.4.10 out now. A final resolution of this issue may have to wait for 2.4.11. -- -- 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#5536) Always use a configured serverID in the syncrepl cookie
by rein＠OpenLDAP.org 02 Jun '08

02 Jun '08

On Thu, 29 May 2008, hyc(a)symas.com wrote: > rein(a)OpenLDAP.org wrote: >> On Wed, 28 May 2008, Howard Chu wrote: >> >>> rein(a)OpenLDAP.org wrote: >> >>>> Syncrepl includes the serverID in the syncCookie in multi-master mode only, >>>> but >>>> there are other configuration that would benefit from it as well. >> >> The commited fix for this bug causes test033-glue-syncrepl to fail. The >> serverID is not set by the config, which makes syncprov_qresp() skip the >> delete when it fins that the consumer presented a cookie with its own sid >> value. > > OK then I guess you're right and we need the default to be -1. I see you have commited an alternative version to syncrepl.c. This version don't include the serverID in the cookie when syncrepl is used on the glue database itself, only when used on subordinate DBs. And unfortunately, it is when used on the glue database it is needed (at least in my configuration). So, I still think we have to always include it when it is configured. Unless there exist some easy way to know that a subordinate DB is not managed by syncrepl. The only solution I know to that is to loop through all the subordinate DBs and compare the rootdn values. Rein

1 0

Re: (ITS#5532) incorrect timestamp of slapd replica log
by quanah＠zimbra.com 02 Jun '08

02 Jun '08

--On June 2, 2008 8:34:12 AM -0400 Francis Swasey <Frank.Swasey(a)uvm.edu> wrote: > Quanah; > > Thank you for that completely unbiased opinion. > > Sheesh... I never had such terrible problems with slurpd. The problem > with slurpd was no one wanted to maintain it anymore. So, with major > changes in slapd came incompatibilities that no one had interest in > working to fix. > > Personally -- I like Scotties comment... the fancier they make the > plumbing, the easier it is to stop it up. > > Syncrepl has some really interesting failure modes. And figuring out > that syncrepl is what loused up your replica can take a while. True, syncrepl has definitely had some interesting issues to sort out. But slurpd did have a lot of problems, and could mess things up just as badly, for very obscure reasons as well. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5532) incorrect timestamp of slapd replica log
by Frank.Swasey＠uvm.edu 02 Jun '08

02 Jun '08

Quanah; Thank you for that completely unbiased opinion. Sheesh... I never had such terrible problems with slurpd. The problem with slurpd was no one wanted to maintain it anymore. So, with major changes in slapd came incompatibilities that no one had interest in working to fix. Personally -- I like Scotties comment... the fancier they make the plumbing, the easier it is to stop it up. Syncrepl has some really interesting failure modes. And figuring out that syncrepl is what loused up your replica can take a while. F On 5/29/08 12:02 AM, quanah(a)zimbra.com wrote: > --On Thursday, May 29, 2008 11:16 AM +0800 Hai <hai.zhao(a)gmail.com> wrote: > >> Hi, Quanah: >> >> I'm considering upgrading from 2.3 to 2.4.x. I haven't test 2.4.x yet. >> Does this bug exist in 2.4.x too? > > Since slurpd was removed because it is completely unreliable and buggy, no, > it does not exist. Sane people use syncrepl replication. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

RE: (ITS#5542) Bug in libldap/t61.c (for your information)
by emmanuel.duru＠atosorigin.com 02 Jun '08

02 Jun '08

I am currently working on synchronisation between OpenLDAP and X.500 directories. > -----Message d'origine----- > De : Howard Chu [mailto:hyc@symas.com] > Envoyé : vendredi 30 mai 2008 17:31 > À : emmanuel.duru(a)atosorigin.com > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#5542) Bug in libldap/t61.c (for your information) > > emmanuel.duru(a)atosorigin.com wrote: > > Full_Name: Emmanuel Duru > > Version: 2.3.39 > > OS: Windows > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (195.68.44.148) > > > In t61.c/ldap_utf8s_to_t61s(), the second loop is an infinite loop, > there misses > > a "i += j; c += j" at the end of the loop. > > Congratulations, you're the first person to use this code in over 6 years. > Out > of curiosity, why do you need it? > > Thanks for the report, fixed in CVS. > > -- > -- 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#5543) id2entry corrupt
by pierangelo.masarati＠sys-net.it 01 Jun '08

01 Jun '08

dyxyd_dyd(a)yahoo.com wrote: > Full_Name: Adrian > Version: 2.3 > OS: Win XP Prof sp2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.120.23.23) > > > Hello, > > i have a huge problem with my openldap database. Even though db_recover doesn't > indicate nothing wrong in my id2entry.bdb file, i couldn't start slapd. > > This is a database from a client of mine who couldn't tell me more exactly what > happened. > > All i know is that id2entry.bdb is corrupt in some way. Only this file is > corrupt, as I tried to start slapd with all other files and an older > "id2entry.bdb". > > db_recover couldnt do anything. > > Is there any other recovery tool I could use to resuscitate this file, maybe to > localize the corrupt places in the file and somehow remove them or fix them? > > Have yoy ever had this problem? > > Thanks a lot Your message does not contain enough useful information to configure as a bug report (OpenLDAP version, Berkeley BDB version, cause of issue, anything logged by slapd, ...). Please direct software usage questions to the openldap-software list. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5543) id2entry corrupt
by dyxyd_dyd＠yahoo.com 01 Jun '08

01 Jun '08

Full_Name: Adrian Version: 2.3 OS: Win XP Prof sp2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.120.23.23) Hello, i have a huge problem with my openldap database. Even though db_recover doesn't indicate nothing wrong in my id2entry.bdb file, i couldn't start slapd. This is a database from a client of mine who couldn't tell me more exactly what happened. All i know is that id2entry.bdb is corrupt in some way. Only this file is corrupt, as I tried to start slapd with all other files and an older "id2entry.bdb". db_recover couldnt do anything. Is there any other recovery tool I could use to resuscitate this file, maybe to localize the corrupt places in the file and somehow remove them or fix them? Have yoy ever had this problem? Thanks a lot. Adrian

1 0

Re: (ITS#5533) test035-meta crashes --without-threads
by pierangelo.masarati＠sys-net.it 31 May '08

31 May '08

Hallvard B Furuseth wrote: > pierangelo.masarati(a)sys-net.it writes: > >> I couldn't reproduce this issue with HEAD; do you confirm it's a re24 only? >> > > Still happens in HEAD as well as RE24. Not RE23 though. > Odd. I've been running test035 in HEAD for >100 times after rebuilding --without-threads with no failure. Anything I might be missing? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5533) test035-meta crashes --without-threads
by h.b.furuseth＠usit.uio.no 31 May '08

31 May '08

pierangelo.masarati(a)sys-net.it writes: > I couldn't reproduce this issue with HEAD; do you confirm it's a re24 only? Still happens in HEAD as well as RE24. Not RE23 though. -- Hallvard

1 0

Re: (ITS#5533) test035-meta crashes --without-threads
by pierangelo.masarati＠sys-net.it 31 May '08

31 May '08

h.b.furuseth(a)usit.uio.no wrote: > quanah(a)zimbra.com writes: > >> Isn't this just a duplicate of ITS#5489? >> > > Apparently not. Got it again at 4th run with daemon.c 1.380.2.12. > Also in a somewhat patched HEAD with the same configuration. > > Hm, the crashes happen for extended operations. So far > 6 times "Passwd ExOp failed (1)!", once "WhoAmI failed (49)!". > I couldn't reproduce this issue with HEAD; do you confirm it's a re24 only? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com 31 May '08

31 May '08

Sean Burford wrote: > Hi, > > On Fri, May 30, 2008 at 2:40 AM,<hyc(a)symas.com> wrote: >> I wrote the attached patch for the original issue. Unfortunately it asserted >> right away: > ... >> It was adding the createTimestamp attribute, without providing normalized >> values. slap_add_opattrs was written before the generalizedTimeNormalize >> function was written... I suspect there will be a fair number of cases that >> need to be cleaned up. I don't have time at the moment to chase them all down. >> Anyone else want to jump in here? If not, we may have to push this back a bit. > > I've modified my copy of the source to normalize data where needed. > slapd starts up and my test can run. With the old assertion in place > it fails exactly as it did before, because the old attr_merge() > assertion runs before your new attr_valadd() normalization check. That aspect of the patch is not optional. The old check is in the wrong place and must be removed. It misses the other places where attrs are being added, while attr_valadd catches all of them. > Removing the old attr_merge() assertion results in your new > attr_valadd() check being triggered. Removing the old assertion looks > safe, since attr_merge() calls attr_valadd() almost immediately after > the assertion anyway. > > With these changes, running my test script from the original tarball results in: > bdb_modify_internal: add testAttribute > attr_valadd: database inconsistent with schema definition of > testAttribute, reload the DB > bdb_modify_internal: 80 modify/add: testAttribute: merge error (80) > hdb_modify: modify failed (80) > > I'm working through 'make test' now to find more instances that need > fixing. After that I'll send some patches. > >> Note that this patch will probably require a fair number of databases to be >> reloaded. > > I'm not even sure that attributes can be automatically renormalized > when a problem is detected, since bugs (eg. with the generation of > timestamps, CSNs or referalls) can also trigger the normalization > checks. I think it's important to continue to assert as in my patch, at least at this stage, so we can catch all of those bugs. I also don't think we can silently renormalize just the cases that the "reload the DB" message detects, because that's obviously only going to happen on entries that are explicitly modified, and the rest of the DB will still have problems. -- -- 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#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 31 May '08

31 May '08

I'm having some trouble working out where to set the normalized value for ContextCSN in the modlist for the syncrepl refresh consumer (test017-syncreplication-refresh fails). The assertion backtrace looks like this: #0 0x00007f472879d095 in raise () from /lib/libc.so.6 #1 0x00007f472879eaf0 in abort () from /lib/libc.so.6 #2 0x00007f47287962df in __assert_fail () from /lib/libc.so.6 #3 0x0000000000425903 in attr_valadd (a=0x8fb380, vals=0xc72130, nvals=0x0, nn=1) at attr.c:398 #4 0x000000000046714c in modify_add_values (e=0x41ff5bb0, mod=0x41ff60e0, permissive=0, text=0x41ff6090, textbuf=0x41ff5cb0 "", textlen=256) at mods.c:155 #5 0x000000000048147d in bdb_modify_internal (op=0x41ff6780, tid=0xc71f50, modlist=0x41ff60e0, e=0x41ff5bb0, text=0x41ff6090, textbuf=0x41ff5cb0 "", textlen=256) at modify.c:133 #6 0x0000000000481f6d in bdb_modify (op=0x41ff6780, rs=0x41ff6070) at modify.c:578 #7 0x0000000000477d32 in overlay_op_walk (op=0x41ff6780, rs=0x41ff6070, which=op_modify, oi=0x858990, on=0x0) at backover.c:646 #8 0x00000000004782b3 in over_op_func (op=0x41ff6780, rs=0x41ff6070, which=op_modify) at backover.c:698 #9 0x000000000046dc59 in syncrepl_updateCookie (si=0x858560, op=0x249e, pdn=<value optimized out>, syncCookie=0x41ff6310) at syncrepl.c:2785 #10 0x0000000000472bea in do_syncrep2 (op=0x41ff6780, si=0x858560) at syncrepl.c:961 #11 0x0000000000475072 in do_syncrepl (ctx=0x0, arg=0x8588f0) at syncrepl.c:1276 #12 0x00000000004daa4a in ldap_int_thread_pool_wrapper (xpool=0x82e440) at tpool.c:663 #13 0x00007f47296d03f7 in start_thread () from /lib/libpthread.so.0 #14 0x00007f4728842b2d in clone () from /lib/libc.so.6 #15 0x0000000000000000 in ?? () In frame 3 a->a_desc->ad_type->sat_equality has a value but nvals has not been set, which is why the assertion triggers: (gdb) print a->a_desc->ad_type->sat_equality $39 = (MatchingRule *) 0x821be0 Way back in frame 10 do_syncrepl passes a modlist containing an unnormalized contextCSN to do_syncrep2, leading me to believe that I've missed something in syncrepl.c: (gdb) print *op->o_request->oq_modify->rs_mods->rs_modlist $44 = {sml_mod = {sm_desc = 0x824b70, sm_values = 0xc72130, sm_nvalues = 0x0, sm_numvals = 1, sm_op = 2, sm_flags = 0, sm_type = {bv_len = 10, bv_val = 0x824be0 "contextCSN"}}, sml_next = 0x0} The debug output up to the assertion is: slap_queue_csn: queing 0xc72ae0 20080531010928.580166Z#000000#000#000000 daemon: epoll: listen=10 active_threads=0 tvp=zero => bdb_entry_get: ndn: "dc=example,dc=com" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("dc=example,dc=com") => bdb_entry_get: found entry: "dc=example,dc=com" bdb_entry_get: rc=0 bdb_modify: dc=example,dc=com bdb_dn2entry("dc=example,dc=com") bdb_modify_internal: 0x00000001: dc=example,dc=com <= acl_access_allowed: granted to database root bdb_modify_internal: replace contextCSN slapd: attr.c:398: attr_valadd: Assertion `have_norm == new_nval' failed. -- Thanks, Sean Burford

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 31 May '08

31 May '08

Hi, On Fri, May 30, 2008 at 2:40 AM, <hyc(a)symas.com> wrote: > > I wrote the attached patch for the original issue. Unfortunately it asserted > right away: ... > It was adding the createTimestamp attribute, without providing normalized > values. slap_add_opattrs was written before the generalizedTimeNormalize > function was written... I suspect there will be a fair number of cases that > need to be cleaned up. I don't have time at the moment to chase them all down. > Anyone else want to jump in here? If not, we may have to push this back a bit. I've modified my copy of the source to normalize data where needed. slapd starts up and my test can run. With the old assertion in place it fails exactly as it did before, because the old attr_merge() assertion runs before your new attr_valadd() normalization check. Removing the old attr_merge() assertion results in your new attr_valadd() check being triggered. Removing the old assertion looks safe, since attr_merge() calls attr_valadd() almost immediately after the assertion anyway. With these changes, running my test script from the original tarball results in: bdb_modify_internal: add testAttribute attr_valadd: database inconsistent with schema definition of testAttribute, reload the DB bdb_modify_internal: 80 modify/add: testAttribute: merge error (80) hdb_modify: modify failed (80) I'm working through 'make test' now to find more instances that need fixing. After that I'll send some patches. > Note that this patch will probably require a fair number of databases to be > reloaded. I'm not even sure that attributes can be automatically renormalized when a problem is detected, since bugs (eg. with the generation of timestamps, CSNs or referalls) can also trigger the normalization checks. -- Thanks, Sean Burford

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs