- openldap-bugs - openldap.org

Re: (ITS#6891)
by quanah＠zimbra.com 12 Apr '11

12 Apr '11

--On Tuesday, April 12, 2011 3:04 PM -0400 Tyler Gates <tgates81(a)gmail.com> wrote: > I can't get a back trace because it doesn't crash under gdb, slapd > only responds to queries with error: > > client: > result: 80 Other (e.g., implementation specific) error > text: internal error > server: > bdb(dc=example,dc=com): PANIC: fatal region error detected; run recovery > > Apr 12 14:25:34 directory-proxy2 slapd[2526]: backend_startup_one > (type=hdb, suffix="(null)"): bi_db_open failed! (-1) These all indicate permissions issues. It sounds like the slapd instance does not have permissions to access the database. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by ipuleston＠SonicWALL.com 12 Apr '11

12 Apr '11

The patch that I submitted above has a memory leak due not freeing "ber" when returning error LDAP_X_CONNECTING from function ldap_send_initial_request(). I have uploaded a new version of the patch with this fixed to ftp.openldap.org/incoming as ian-puleston-110412.patch.2 (note the .2 on the end - it was a 2nd attempt after I forgot to specify ASCII mode).

1 0

Re: (ITS#6891)
by tgates81＠gmail.com 12 Apr '11

12 Apr '11

I can't get a back trace because it doesn't crash under gdb, slapd only responds to queries with error: client: result: 80 Other (e.g., implementation specific) error text: internal error server: bdb(dc=example,dc=com): PANIC: fatal region error detected; run recovery This happens after every restart, even after starting with fresh database directory. I've never had to specify a suffix dn inside of the database backend to pcache before, so I'm a little confused as to why this needed. When I had started slapd fresh from after upgrading 2.4.24 (when it was working fine) to 2.4.25, I got these error messages about it not having one: Apr 12 14:25:34 directory-proxy2 slapd[2526]: slapd startup: initiated. Apr 12 14:25:34 directory-proxy2 slapd[2526]: backend_startup: warning, database 0 (hdb) has no suffix Apr 12 14:25:34 directory-proxy2 slapd[2526]: backend_startup_one: starting "(unknown)" Apr 12 14:25:34 directory-proxy2 slapd[2526]: hdb_db_open: need suffix. Apr 12 14:25:34 directory-proxy2 slapd[2526]: backend_startup_one (type=hdb, suffix="(null)"): bi_db_open failed! (-1) Apr 12 14:25:34 directory-proxy2 slapd[2526]: slapd shutdown: initiated Apr 12 14:25:34 directory-proxy2 slapd[2526]: ====> bdb_cache_release_all Apr 12 14:25:34 directory-proxy2 slapd[2526]: ====> bdb_cache_release_all Apr 12 14:25:34 directory-proxy2 slapd[2526]: slapd destroy: freeing system resources. Apr 12 14:25:34 directory-proxy2 slapd[2526]: slapd stopped. I have output from strace and I can provide it if needed but it is very lengthy and doesn't seem to provide any useful information. On Mon, Apr 11, 2011 at 1:43 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Monday, April 11, 2011 3:32 PM +0000 tgates81(a)gmail.com wrote: > >> Can someone confirm whether or not this is a bug or just a >> misconfiguration error on my part? I am at a complete loss. >> > > None of what you provided as output from gdb was output from gdb. Get a > valid backtrace. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

Re: (ITS#6903) BerkeleyDB
by quanah＠zimbra.com 12 Apr '11

12 Apr '11

--On Tuesday, April 12, 2011 9:38 AM +0000 h.b.furuseth(a)usit.uio.no wrote: > matdave(a)yahoo.com writes: >> New to openldap, downloaded latest stable version and tried to configure >> with Berkeley 11g from Oracle. >> Configure message along the lines of 'Berkeley (default) no' >> 'Berkeley not enabld/installed' > > See README, "REQUIRED SOFTWARE": > SLAPD: > BDB and HDB backends require Oracle Berkeley DB 4.4, 4.5, > 4.6, 4.7, or 4.8. It is highly recommended to apply the > patches from Oracle for a given release. > > Closing this ITS. And please use openldap-technical(a)openldap.org > for help requests. ITS is for bug reports and contributions. Probably worth reporting later versions of OpenLDAP support compiling against 5.x with no problem. 2.4.23 can be made to build against 5.x as well with the appropriate patch to configure. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6904) correct the recommended backend verbiage in slapd.backends(5)
by Tim.Mooney＠ndsu.edu 12 Apr '11

12 Apr '11

Full_Name: Tim Mooney Version: 2.4.25 OS: Linux, Solaris URL: ftp://ftp.openldap.org/incoming/0001-Update-to-reflect-that-hdb-is-now-pref… Submission from: (NULL) (2001:4930:106:0:18bb:1140:fa3d:f713) The slapd.backends(5) man page still indicates that the bdb backend is the recommended database, even though Quanah has confirmed that for 2.4 and later, hdb is now preferred, see http://www.openldap.org/lists/openldap-technical/201104/msg00123.html I've uploaded a patch to ftp://ftp.openldap.org/incoming against HEAD that addresses this issue, you can find it as 0001-Update-to-reflect-that-hdb-is-now-preferred-backend.patch (Sorry for the name, I'll be more careful to follow the recommended naming conventions next time). Note that I used the word "supplanted" rather than "deprecated" in the new verbiage about bdb, since deprecated seems stronger. If you would prefer the term deprecated, let me know and I can upload a new patch with that change.

1 0

Re: (ITS#6903) BerkeleyDB
by h.b.furuseth＠usit.uio.no 12 Apr '11

12 Apr '11

matdave(a)yahoo.com writes: > New to openldap, downloaded latest stable version and tried to configure with > Berkeley 11g from Oracle. > Configure message along the lines of 'Berkeley (default) no' > 'Berkeley not enabld/installed' See README, "REQUIRED SOFTWARE": SLAPD: BDB and HDB backends require Oracle Berkeley DB 4.4, 4.5, 4.6, 4.7, or 4.8. It is highly recommended to apply the patches from Oracle for a given release. Closing this ITS. And please use openldap-technical(a)openldap.org for help requests. ITS is for bug reports and contributions. -- Hallvard

1 0

(ITS#6903) BerkeleyDB
by matdave＠yahoo.com 12 Apr '11

12 Apr '11

Full_Name: Terry Bennett Version: 2.4.23 OS: RHEL 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.17.5.3) New to openldap, downloaded latest stable version and tried to configure with Berkeley 11g from Oracle. Configure message along the lines of 'Berkeley (default) no' 'Berkeley not enabld/installed' (Sorry at work no access to actual message) General email search suggested LD_LIBRARY_PATH, CPPFLAGS etc - tried no success. Is there a compatability issue between these too versions. Regards Terry Bennett

1 0

Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
by daniel＠pluta.biz 12 Apr '11

12 Apr '11

A small but important bugfix for my patch, that also honors access "to all values", can be found here: ftp://ftp.openldap.org/incoming/Daniel-Pluta-20110412.patch

1 0

Re: (ITS#6902) test008-concurrency failed on test
by vorgusa＠earthlink.net 11 Apr '11

11 Apr '11

ahhh you are right. Tests finished without any problem. Guess my VM was too minimal. Thanks for the help On 04/11/2011 01:42 PM, Quanah Gibson-Mount wrote: > --On Monday, April 11, 2011 5:05 PM +0000 vorgusa(a)earthlink.net wrote: > > >> ./scripts/test008-concurrency: 62: time: not found > > I suggest you install the "time" command. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

RE: (ITS#6891)
by quanah＠zimbra.com 11 Apr '11

11 Apr '11

--On Monday, April 11, 2011 3:32 PM +0000 tgates81(a)gmail.com wrote: > Can someone confirm whether or not this is a bug or just a > misconfiguration error on my part? I am at a complete loss. > None of what you provided as output from gdb was output from gdb. Get a valid backtrace. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6902) test008-concurrency failed on test
by quanah＠zimbra.com 11 Apr '11

11 Apr '11

--On Monday, April 11, 2011 5:05 PM +0000 vorgusa(a)earthlink.net wrote: > ./scripts/test008-concurrency: 62: time: not found I suggest you install the "time" command. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6902) test008-concurrency failed on test
by vorgusa＠earthlink.net 11 Apr '11

11 Apr '11

Full_Name: Chris Version: 2.4.25 OS: Ubuntu Server URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.47.84.194) after running make test I received the below errors. I have my configuration options below and the configuration passed Configuration options ./configure --enable-sql --enable-ldap --enable-ppolicy MAKE TEST >>>>> Starting test008-concurrency for bdb... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... MONITORDB yes SRCDIR ./testdata DSTDIR /opt/openldap-2.4.25/tests/testrun pwd /opt/openldap-2.4.25/tests Using tester for concurrent server access... ./scripts/test008-concurrency: 62: time: not found slapd-tester failed (127)! >>>>> ./scripts/test008-concurrency failed for bdb (exit 127) make[2]: *** [bdb-yes] Error 127 make[2]: Leaving directory `/opt/openldap-2.4.25/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/opt/openldap-2.4.25/tests' make: *** [test] Error 2

1 0

RE: (ITS#6891)
by tgates81＠gmail.com 11 Apr '11

11 Apr '11

Can someone confirm whether or not this is a bug or just a misconfiguration error on my part? I am at a complete loss.

1 0

(ITS#6901) openldap crash
by m.sheldyakov＠hostcomm.ru 11 Apr '11

11 Apr '11

Full_Name: Michail Sheldyakov Version: 2.4.25 OS: FreeBSD 8.1-RELEASE-p1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.189.112.7) Modify with ldapvi: dn: cn=ovz678.hc.ru,ou=ovz,ou=hosts,ou=hosting,ou=sites,o=hc changetype: add macAddress: hostType: main cn: ovz678.hc.ru objectClass: device objectClass: ipHost objectClass: intraExtra objectClass: intraHost objectClass: ieee802Device description: ovz678.hc.ru ipHostNumber: 127.0.0.1 unique overlay olcUniqueURI: ldap:///ou=sites,o=hc?macAddress?sub?(&(objectClass=ipHost)(|(hostType=main)(hostType=xen)(hostType=service))) openldap crash with core dump.

1 0

(ITS#6900) dnattr acl statement: users can produce dangling entries
by daniel＠pluta.biz 10 Apr '11

10 Apr '11

Full_Name: Daniel Pluta Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/Daniel-Pluta-110410.patch Submission from: (NULL) (2001:4ca0:0:fe11::1) Hi, I'm not quite sure whether the below described scenario can be successfully avoided eg. using current slapd in combination with some kind of tricky ACL configuration statements (if so, any advice is strongly appreciated). Nevertheless, attached below you'll find a small patch that implements a slightly enhanced (aka more restictive!) dnattr acl processing in case of ACL_WDEL operations: In case the currently authenticated user tries to delete his bindDN from the attribute referenced by the dnattr= acl statement, access is denied. Example scenario based on the following (nearly) minimal standard ACL configuration: access to dn.base="ou=groups,dc=foo,dc=bar" attrs=children by users =w by * none access to dn.onelevel="ou=groups,dc=foo,dc=bar" by dnattr=owner write by * none access to dn.subtree="dc=foo,dc=bar" by users read by * none ... at first a user (user1) successfully creates (add) a new group entry, where/because user1's DN is contained within the entry's owner attribute: OPTS="-Z -D 'uid=user1,ou=users,dc=foo,dc=bar' -w 'user1'" cat <<EOF | ldapadd ${OPTS} dn: cn=test,ou=groups,dc=foo,dc=bar objectClass: groupOfNames objectClass: top cn: test member: cn=otheruser,ou=users,dc=foo,dc=bar description: test group entry owner: uid=user1,ou=users,dc=foo,dc=bar EOF Then, user1 (by mistake but) successfully modifies the just before created and personaly owned entry, deleting his DN from the owner attribute: cat <<EOF | ldapmodify ${OPTS} dn: cn=test,ou=groups,dc=foo,dc=bar changetype: modify delete: owner owner: uid=user1,ou=users,dc=foo,dc=bar EOF As a sideeffect from this second operation user1 has no chance to revert his mistake because he has lost the previous assigned access rights to access this entry by write. In fact nobody else (other than the rootdn) has a chance to correct/delete the dangline group entry. Another disabdvantage of the current implementation is the possibility to move currently managed/owned entries (e.g. users or groups) to other owners/managers without their notice/interaction. The attached patch only interact in case of value delete operations. Thus, based on the patch other owners/managers can be added/deleted as usual (except the DN of the modifyer himself). Added owners/managers can take solely responsibility of an entry by deleting all other owners/managers. I would be very happy in case this patch or at least the based idea could find a way into slapd's code. I don't mind whether this feature is implemented as an extension of current dnattr processing (backward compatibility?) or as an additional configuration option, e.g. "strictdnattr=..." (update documentation?). Also I'm not sure whether set acl statements should or need to be extended into this direction, too... Thank you very much and best regards Daniel

1 0

RE: (ITS#6898)
by quanah＠zimbra.com 09 Apr '11

09 Apr '11

--On Saturday, April 09, 2011 7:56 PM +0000 quanah(a)zimbra.com wrote: > --On Friday, April 08, 2011 9:25 PM -0400 Tyler Gates > <tgates81(a)gmail.com> wrote: > >> I can confirm this is happening too, since 2.4.24. It was working in >> 2.4.21, not sure about anything in between. > >> From the debian list: > > I've checked it with gdb too, and it locks at > libraries/libldap/options.c:455 > That is in the function ldap_set_option, still no clue why it is locking > there. Full backtrace: (gdb) thr apply all bt Thread 1 (Thread 0x7f34820c4700 (LWP 26379)): #0 0x00007f34803d6464 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f34803d15d9 in _L_lock_953 () from /lib/libpthread.so.0 #2 0x00007f34803d13fb in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f3481c62ff5 in ldap_pvt_thread_mutex_lock (mutex=0x1cac2a0) at thr_posix.c:296 #4 0x00007f3481c87fb9 in ldap_set_option (ld=0x1cab030, option=17, invalue=0x6164a8) at options.c:455 #5 0x000000000040ad83 in tool_conn_setup (dont=0, private_setup=0x405367 <private_conn_setup>) at common.c:1347 #6 0x00000000004059c7 in main (argc=8, argv=0x7fff16202148) at ldapsearch.c:906 --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#6898)
by quanah＠zimbra.com 09 Apr '11

09 Apr '11

--On Friday, April 08, 2011 9:25 PM -0400 Tyler Gates <tgates81(a)gmail.com> wrote: > I can confirm this is happening too, since 2.4.24. It was working in > 2.4.21, not sure about anything in between. >From the debian list: I've checked it with gdb too, and it locks at libraries/libldap/options.c:455 That is in the function ldap_set_option, still no clue why it is locking there. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

ITS#6893 published: SECURITY: SHA2 Password Hashing not working
by openldap-its＠OpenLDAP.org 09 Apr '11

09 Apr '11

Private ITS#6893 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6893

1 0

RE: (ITS#6898)
by tgates81＠gmail.com 09 Apr '11

09 Apr '11

I can confirm this is happening too, since 2.4.24. It was working in 2.4.21, not sure about anything in between.

1 0

(ITS#6899) Read Entry Control response value is not compliant to definition of SearchResultEntry
by michael＠stroeder.com 08 Apr '11

08 Apr '11

Full_Name: Michael Ströder Version: 2.4.25 OS: URL: Submission from: (NULL) (84.163.53.138) The very same client code was successfully tested with OpenDJ 2.4.1 but does not work with OpenLDAP 2.4.25. See analysis by pyasn1 developer on the pyasn1 mailing list: --------------------------------- snip --------------------------------- It looks to me that your BER data does not fully match ASN.1 specification for the SearchResultEntry object. According to RFC2251, the grammar is as follows: SearchResultEntry ::= [APPLICATION 4] SEQUENCE { objectName LDAPDN, attributes PartialAttributeList } ... Notice the [implicitly] tagged outer SEQUENCE. In your BER data, that additional tag seems to be missing and default tag for SEQUENCE type is used instead. If you modify the original pyasn1 grammar for SearchResultEntry object to match your BER data (but not the standard!), pyasn1 decoder succeeds. >>> from pyasn1_modules.rfc2251 import SearchResultEntry >>> from pyasn1.type.univ import Sequence >>> from pyasn1.codec.ber import decoder >>> ber = '0c\x043cn=Samba Unix UID Pool,ou=Testing,dc=stroeder,dc=de0,0\x14\x04\tuidNumber1\x07\x04\x05100050\x14\x04\tgidNumber1\x07\x04\x0510005' >>> SearchResultEntry.tagSet TagSet(Tag(tagClass=64, tagFormat=32, tagId=4)) # the following statement will invalidate SearchResultEntry grammar! >>> SearchResultEntry.tagSet = univ.Sequence.tagSet >>> SearchResultEntry.tagSet TagSet(Tag(tagClass=0, tagFormat=32, tagId=16)) >>> searchResultEntry, _ = decoder.decode(ber,asn1Spec=SearchResultEntry()) >>> print searchResultEntry.prettyPrint() SearchResultEntry: objectName='cn=Samba Unix UID Pool,ou=Testing,dc=stroeder,dc=de' attributes=PartialAttributeList: Sequence: type='uidNumber' vals=SetOf: '10005' Sequence: type='gidNumber' vals=SetOf: '10005' >>> Therefore my impression is that OpenLDAP yields incorrect BER data for SearchResultEntry object. What do you think? Cheers, Ilya > I'd like to decode a LDAPv3 control value returned by OpenLDAP 2.4.25 when > Pre-Read-Control was sent along with a LDAP modify request. But decoding it > does not work. > > Short example: > >>>> from pyasn1_modules.rfc2251 import SearchResultEntry >>>> from pyasn1.codec.ber import decoder >>>> ber = '0c\x043cn=Samba Unix UID > Pool,ou=Testing,dc=stroeder,dc=de0,0\x14\x04\tuidNumber1\x07\x04\x05100050\x14\x04\tgidNumber1\x07\x04\x0510005' >>>> decoder.decode(ber,asn1Spec=SearchResultEntry()) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File > "/usr/local/lib/python2.6/site-packages/pyasn1-0.0.13a-py2.6.egg/pyasn1/codec/ber/decoder.py", > line 663, in __call__ > '%s not in asn1Spec: %s' % (tagSet, repr(asn1Spec)) > pyasn1.error.PyAsn1Error: TagSet(Tag(tagClass=0, tagFormat=32, tagId=16)) not > in asn1Spec: SearchResultEntry() >>>>

1 0

Re: (ITS#6892) Segfault in Syncprov overlay
by ghola＠rebelbase.com 08 Apr '11

08 Apr '11

--000e0cd3f872854fb804a05e0ce0 Content-Type: text/plain; charset=ISO-8859-1 More information; This server is both a producer and a consumer. Here are the logs preceeding the crash: Apr 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000 Apr 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000 Apr 8 00:50:40 test-ldap01 slapd[8732]: conn=1007 op=1 ENTRY dn="widget=ldap02,ou=widgets,dc=domain,dc=net" Apr 8 00:50:40 test-ldap01 slapd[8732]: conn=1005 op=1 ENTRY dn="widget=ldap02,ou=widgets,dc=domain,dc=net" Apr 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000 Apr 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000 Apr 8 00:50:40 test-ldap01 slapd[8732]: conn=1004 op=1 ENTRY dn="widget=ldap02,ou=widgets,dc=domain,dc=net" Apr 8 00:50:40 test-ldap01 slapd[8732]: conn=1003 op=1 ENTRY dn="widget=ldap02,ou=widgets,dc=domain,dc=net" Apr 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000 Apr 8 00:50:40 test-ldap01 slapd[8732]: conn=1002 op=1 ENTRY dn="widget=ldap02,ou=widgets,dc=domain,dc=net" Apr 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000 Apr 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000 Apr 8 00:50:40 test-ldap01 slapd[8732]: conn=1001 op=1 ENTRY dn="widget=ldap02,ou=widgets,dc=domain,dc=net" Apr 8 00:50:40 test-ldap01 slapd[8732]: slap_graduate_commit_csn: removing 0x20494b70 20110408005040.759389Z#000000#000#000000 Apr 8 00:50:40 test-ldap01 slapd[8732]: conn=1000 op=1 ENTRY dn="widget=ldap02,ou=widgets,dc=domain,dc=net" Apr 8 00:50:40 test-ldap01 slapd[8732]: syncrepl_entry: rid=001 be_modify widget=ldap02,ou=widgets,dc=domain,dc=net (0) Apr 8 00:50:40 test-ldap01 slapd[8732]: slap_queue_csn: queing 0x2055d810 20110408005040.759389Z#000000#000#000000 --000e0cd3f872854fb804a05e0ce0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable More information; This server is both a producer and a consumer. Her= e are the logs preceeding the crash: Apr=A0 8 00:50:40 test-ldap01 s= lapd[8732]: syncprov_sendresp: cookie=3Drid=3D001,csn=3D20110408005040.7593= 89Z#000000#000#000000 Apr=A0 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=3Drid= =3D001,csn=3D20110408005040.759389Z#000000#000#000000 Apr=A0 8 00:50:40 = test-ldap01 slapd[8732]: conn=3D1007 op=3D1 ENTRY dn=3D"widget=3Dldap0= 2,ou=3Dwidgets,dc=3Ddomain,dc=3Dnet" Apr=A0 8 00:50:40 test-ldap01 slapd[8732]: conn=3D1005 op=3D1 ENTRY dn=3D&q= uot;widget=3Dldap02,ou=3Dwidgets,dc=3Ddomain,dc=3Dnet" Apr=A0 8 00:= 50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=3Drid=3D001,csn=3D= 20110408005040.759389Z#000000#000#000000 Apr=A0 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=3Drid= =3D001,csn=3D20110408005040.759389Z#000000#000#000000 Apr=A0 8 00:50:40 = test-ldap01 slapd[8732]: conn=3D1004 op=3D1 ENTRY dn=3D"widget=3Dldap0= 2,ou=3Dwidgets,dc=3Ddomain,dc=3Dnet" Apr=A0 8 00:50:40 test-ldap01 slapd[8732]: conn=3D1003 op=3D1 ENTRY dn=3D&q= uot;widget=3Dldap02,ou=3Dwidgets,dc=3Ddomain,dc=3Dnet" Apr=A0 8 00:= 50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=3Drid=3D001,csn=3D= 20110408005040.759389Z#000000#000#000000 Apr=A0 8 00:50:40 test-ldap01 slapd[8732]: conn=3D1002 op=3D1 ENTRY dn=3D&q= uot;widget=3Dldap02,ou=3Dwidgets,dc=3Ddomain,dc=3Dnet" Apr=A0 8 00:= 50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=3Drid=3D001,csn=3D= 20110408005040.759389Z#000000#000#000000 Apr=A0 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=3Drid= =3D001,csn=3D20110408005040.759389Z#000000#000#000000 Apr=A0 8 00:50:40 = test-ldap01 slapd[8732]: conn=3D1001 op=3D1 ENTRY dn=3D"widget=3Dldap0= 2,ou=3Dwidgets,dc=3Ddomain,dc=3Dnet" Apr=A0 8 00:50:40 test-ldap01 slapd[8732]: slap_graduate_commit_csn: removi= ng 0x20494b70 20110408005040.759389Z#000000#000#000000 Apr=A0 8 00:50:40= test-ldap01 slapd[8732]: conn=3D1000 op=3D1 ENTRY dn=3D"widget=3Dldap= 02,ou=3Dwidgets,dc=3Ddomain,dc=3Dnet" Apr=A0 8 00:50:40 test-ldap01 slapd[8732]: syncrepl_entry: rid=3D001 be_mod= ify widget=3Dldap02,ou=3Dwidgets,dc=3Ddomain,dc=3Dnet (0) Apr=A0 8 00:50= :40 test-ldap01 slapd[8732]: slap_queue_csn: queing 0x2055d810 201104080050= 40.759389Z#000000#000#000000 --000e0cd3f872854fb804a05e0ce0--

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by marco.pizzoli＠gmail.com 07 Apr '11

07 Apr '11

--20cf300fb269cc453c04a055d2f8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I tried today to compile accesslog with this feature. Probably I didn't follow the correct procedure, but I would prefer to ask anyway to leave myself any doubt. - I took the vanilla openldap-2.4.25 distribution - unpacked the archive - substituted the accesslog.c file with the corresponding one as available in HEAD/MASTER - compiled the software as if it were the 2.4.25 vanilla distribution Now I obtain the following, at the startup: [cut] line 24 (logpurge 10+00:00 08:00) line 28 (logsuccess FALSE) line 30 (logbase all ou=3Dpeople,dc=3Dlancse,dc=3Dcsebo.it) /opt/openldap2.4.25/libexec/slapd: symbol lookup error: /opt/openldap2.4.25/libexec/openldap/accesslog-2.4.so.2: undefined symbol: verbstring_to_mask Could you help me? Thanks in advance Marco On Wed, Feb 23, 2011 at 10:02 AM, Marco Pizzoli <marco.pizzoli(a)gmail.com>wr= ote: > > On Wed, Feb 23, 2011 at 9:57 AM, Howard Chu <hyc(a)symas.com> wrote: > >> Marco Pizzoli wrote: >> >>> Hi Howard, >>> thanks for this work. >>> >>> I noticed that you give me a baseDN under which I can have operations >>> logged. >>> If I would like to exclude one subtree from my principal tree, I need t= o >>> specify all the baseDN of other sibling-subtrees. >>> To do this do I need to poli-invoke accesslog overlay? >>> >> >> No, you can specify logbase multiple times in a single overlay. >> > > Ok, thanks. > > > >> Possibly we can extend the directive to handle exclusion as well as >> inclusion, to simplify this case. >> > > This is effectively what I would need, in this case. > > > --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --20cf300fb269cc453c04a055d2f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I tried today to compile accesslog with this feature. Probably I didn&#3= 9;t follow the correct procedure, but I would prefer to ask anyway to leave= myself any doubt. - I took the vanilla openldap-2.4.25 distribution= - unpacked the archive - substituted the accesslog.c file with the corre= sponding one as available in HEAD/MASTER - compiled the software as if i= t were the 2.4.25 vanilla distribution Now I obtain the following, = at the startup: [cut] line 24 (l= ogpurge 10+00:00 08:00) line 28 (logsucces= s FALSE) line 30 (logbase all ou= =3Dpeople,dc=3Dlancse,dc=3D<a href=3D"http://csebo.it">csebo.it</a>)= /opt/openldap2.4.25/libexec/slapd: symbol lookup= error: /opt/openldap2.4.25/libexec/openldap/accesslog-2.4.so.2: undefined = symbol: verbstring_to_mask Could you help me? Thanks in advance Marco <div cl= ass=3D"gmail_quote">On Wed, Feb 23, 2011 at 10:02 AM, Marco Pizzoli <<a href=3D"mailto:marco.pizzoli@gmail.com">marco.pizzoli@gma= il.com</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class=3D= "gmail_quote"><div class=3D"im">On Wed, Feb 23, 2011 at 9:57 AM, Howard Chu= <<a href=3D"mailto:hyc@symas.com" target=3D"_blank">h= yc(a)symas.com</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div>Marco Pizzoli wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Hi Howard, thanks for this work. I noticed that you give me a baseDN under which I can have operations logge= d. If I would like to exclude one subtree from my principal tree, I need to<br= > specify all the baseDN of other sibling-subtrees. To do this do I need to poli-invoke accesslog overlay? </blockquote> </div> No, you can specify logbase multiple times in a single overlay. </blockq= uote></div><div> Ok, thanks. =A0</div><div class=3D"im"><blockquo= te class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1= px solid rgb(204, 204, 204); padding-left: 1ex;"> Possibly we can extend the directive to handle exclusion as well as inclusi= on, to simplify this case. </blockquote></div><div> This is effective= ly what I would need, in this case. </div></div> </blockquote></div> -- _______________________= __________________ Non =E8 forte chi non cade, ma chi cadendo ha la forz= a di rialzarsi. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jim Morrison --20cf300fb269cc453c04a055d2f8--

1 0

Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 07 Apr '11

07 Apr '11

* alexs(a)ulgsm.ru <alexs(a)ulgsm.ru> [2010-01-19 07:25:25 +0000]: OpenLDAP 2.4.25, 8.2-RELEASE is still crashed. -- alexs

1 0

(ITS#6892) Segfault in Syncprov overlay
by ghola＠rebelbase.com 07 Apr '11

07 Apr '11

Full_Name: Duncan Idaho Version: 2.4.25 OS: RHEL 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.10.36.147) In my configuration slapd segfaults within a few hours repeatably when a NULL value is somehow passed as a filter to test_filter in the syncprov overlay. I'm running "threads 64" as I have 62 consumers connecting and this was required to prevent unrelated searches from timing out when all the consumers connect at once. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x59832940 (LWP 2042)] test_filter (op=0x59830770, e=0x2aab11861068, f=0x0) at filterentry.c:69 69 if ( f->f_choice & SLAPD_FILTER_UNDEFINED ) { (gdb) bt #0 test_filter (op=0x59830770, e=0x2aab11861068, f=0x0) at filterentry.c:69 #1 0x00000000004db315 in syncprov_matchops (op=0x59831130, opc=0xbc91750, saveit=1) at syncprov.c:1314 #2 0x00000000004db6b5 in syncprov_op_mod (op=0x59831130, rs=<value optimized out>) at syncprov.c:2124 #3 0x000000000047e62a in overlay_op_walk (op=0x59831130, rs=0x59830f40, which=op_modify, oi=0x8d7b50, on=0x8dc540) at backover.c:659 #4 0x000000000047ec07 in over_op_func (op=0x59831130, rs=0x59830f40, which=op_modify) at backover.c:721 #5 0x000000000047404d in syncrepl_updateCookie (si=0x8d74e0, op=0x59831130, syncCookie=0x59831aa0) at syncrepl.c:3292 #6 0x0000000000479d0d in do_syncrep2 (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:959 #7 do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:1455 #8 0x000000000041f7aa in connection_read_thread (ctx=0x59831d70, argv=<value optimized out>) at connection.c:1251 #9 0x00000000004ec5ec in ldap_int_thread_pool_wrapper (xpool=0x84de50) at tpool.c:685 #10 0x000000301b20673d in start_thread (arg=<value optimized out>) at pthread_create.c:301 #11 0x000000301aad44bd in clone () from /lib64/libc.so.6 Let me know if I can provide more info.

1 0

Re: (ITS#6884) contrib: password syntax checking overlay
by mathieu.baeumler＠gmail.com 06 Apr '11

06 Apr '11

On Wed, Mar 30, 2011 at 12:43 AM, Kurt Zeilenga <Kurt(a)openldap.org> wrote: > Your submission lacks a notice of origin. Please review http://www.openldap.org/devel/contributing.html > > Please also note that git-format-patch(1) format submissions are now preferred. ok, I'm trying again, sorry I didn't catch the change to git... I've uploaded the patch created using git-format-patch in: incoming/mathieu-baeumler-110406.patch Here is the updated notice of origin followed by rights statement, included in every files contained in the patch: The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Mathieu Baeumler <mathieu.baeumler(a)gmail.com>. I have not assigned rights and/or interest in this work to any party. Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. A copy of this license is available in the file LICENSE in the top-level directory of the distribution or, alternatively, at <http://www.OpenLDAP.org/license.html>. Hope it's correct now. -- Mathieu

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs