- openldap-bugs - openldap.org

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

12 Apr '11

I've uploaded an additional patch, TimMooney-110412-03.patch, for slapd-bdb.5/slapd-hdb.5, that switches the "recommended" status from bdb to hdb. This should likely be applied in addition to the patch mentioned in the initial report.

1 0

(ITS#6905) fix up intros to chapters 5 and 6
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/TimMooney-110412-02.patch Submission from: (NULL) (2001:4930:106:0:18bb:1140:fa3d:f713) As I mentioned here http://www.openldap.org/lists/openldap-technical/201104/msg00088.html the LDAP admin guide is very good, but I think that the intros to chapters 5 (configuring slapd via slapd-config) and chapter 6 (configuring slapd via slapd.conf) needed a bit of updating. Specifically - it's not very explicit that slapd-config is now preferred and slapd.conf should only be used as a last resort. - the Note that some backends don't support slapd-config was vague enough that it would prevent many people from choosing that route, because they wouldn't know whether a backend they needed would support the new-style config system. By specifically listing which backends don't support slapd-config, hopefully more people will be willing to begin with (or convert to) slapd-config. I also tried to - make it clear that chapters 5 and 6 were essentially explaining the same thing, but the slapd-config way is preferred. - Although slapd-config stores its configuration in text files, they shouldn't be edited manually. The patch against head has been uploaded. Any and all comments and feedback welcome.

1 0

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

12 Apr '11

Hi Quanah, slapd does have access to the files because it re-created after I deleted them on start. root@directory-proxy2:/var/lib/ldap# ls -la total 11752 drwxr-x--- 2 openldap openldap 4096 2011-04-12 16:01 . drwxr-xr-x 44 root root 4096 2011-03-25 12:47 .. -rw-r--r-- 1 openldap openldap 4096 2011-04-12 16:01 alock -rw------- 1 openldap openldap 24576 2011-04-12 16:01 __db.001 -rw------- 1 openldap openldap 843776 2011-04-12 16:01 __db.002 -rw------- 1 openldap openldap 13115392 2011-04-12 16:01 __db.003 -rw------- 1 openldap openldap 2359296 2011-04-12 16:01 __db.004 -rw------- 1 openldap openldap 540672 2011-04-12 16:01 __db.005 -rw------- 1 openldap openldap 32768 2011-04-12 16:01 __db.006 -rw-r--r-- 1 openldap openldap 120 2011-04-12 14:29 DB_CONFIG -rw------- 1 openldap openldap 8192 2011-04-12 14:29 dn2id.bdb -rw------- 1 openldap openldap 32768 2011-04-12 14:29 id2entry.bdb -rw------- 1 openldap openldap 10485760 2011-04-12 16:01 log.0000000001 root@directory-proxy2:/var/lib/ldap# ps aux |grep slapd openldap 5519 0.0 0.6 56244 6316 ? Ssl 16:01 0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d I've disabled apparmor as well.. On Tue, Apr 12, 2011 at 3:42 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --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#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 11 Apr '11

11 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 11 Apr '11

11 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 08 Apr '11

08 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 07 Apr '11

07 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 06 Apr '11

06 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

(ITS#6891) pcache crashes after 2.4.25 upgrade; complains of unclean shutdowns and missing DB_CONFIGs after every restart
by tgates81＠gmail.com 05 Apr '11

05 Apr '11

Full_Name: Tyler Gates Version: 2.4.25 OS: Ubuntu 10.04 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.184.61.44) After upgrading from 2.4.24 to 2.4.25 my pcache overlay using hdb backend first failed to start with messages complaining about a missing suffix. Now that I've added one I'm getting the following message: hdb_db_open: database "dc=example,dc=com": unclean shutdown detected; attempting recovery. hdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (14).#012Expect poor performance for suffix "dc=example,dc=com". slapd starting bdb(dc=example,dc=com): PANIC: fatal region error detected; run recovery last message repeated 3 times But DB_CONFIG does exist and has proper permissions and the unclean shutdown message repeats after every restart. I've never had to add the suffix to the pcache backend database before and the documentation examples (http://www.openldap.org/doc/admin24/proxycache.html) never mention it either. PCACHE OVERLAY: dn: olcOverlay={0}pcache objectClass: olcOverlayConfig objectClass: olcPcacheConfig olcOverlay: {0}pcache olcPcache: hdb 100000 3 1000 100 olcPcacheAttrset: 0 uid userPassword uidNumber gidNumber cn homeDirectory logi nShell gecos description memberUid uniqueMember objectClass olcPcacheAttrset: 1 cn automountInformation olcPcacheAttrset: 2 cn mail olcPcacheTemplate: "(|(cn=)(mail=)(sn=))" 2 7200 0 0 0 olcPcacheTemplate: "(&(objectClass=)(|(cn=)(cn=)(cn=)))" 1 3600 600 0 0 olcPcacheTemplate: "(&(objectClass=)(|(cn=)(cn=)))" 1 3600 600 0 0 olcPcacheTemplate: "(&(objectClass=)(|(cn=)(gidNumber=)))" 1 3600 600 0 0 olcPcacheTemplate: "(&(objectClass=)(gidNumber=))" 0 1800 0 0 0 olcPcacheTemplate: "(&(objectClass=)(uidNumber=))" 0 1800 0 0 0 olcPcacheTemplate: "(&(objectClass=)(uniqueMember=))" 0 1800 900 0 0 olcPcacheTemplate: "(&(objectClass=)(memberUid=))" 0 1800 900 0 0 olcPcacheTemplate: "(objectClass=)" 0 1800 0 0 0 olcPcacheTemplate: "(&(objectClass=))" 0 1800 0 0 0 olcPcacheTemplate: "(&(objectClass=)(cn=))" 0 1800 0 0 0 olcPcacheTemplate: "(&(objectClass=)(uid=))" 0 1800 0 0 0 olcPcacheTemplate: "(&(objectClass=)(|(memberUid=)(uniqueMember=)))" 0 1800 0 0 0 olcPcachePosition: tail olcPcacheMaxQueries: 10000 olcPcachePersist: FALSE olcPcacheValidate: FALSE olcPcacheOffline: FALSE HDB backend: dn: olcDatabase={0}hdb objectClass: olcHdbConfig objectClass: olcPcacheDatabase olcDatabase: {0}hdb olcDbDirectory: /var/lib/ldap olcDbCacheSize: 1000 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 3000 olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 createTimestamp: 20110225174535Z olcDbConfig: {0}set_cachesize 0 10485760 1 olcDbConfig: {1}set_lg_regionmax 262144 olcDbConfig: {2}set_lg_bsize 2097152 olcDbConfig: {3}set_flags DB_LOG_AUTOREMOVE olcDbConfig: {4}set_lg_max 10485760 olcDbIndex: objectClass eq olcDbIndex: cn eq,subinitial olcDbIndex: uid eq,subinitial olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: userPassword eq olcDbIndex: description eq olcDbIndex: loginShell eq olcDbIndex: homeDirectory eq olcDbIndex: memberUid eq olcDbIndex: gecos eq olcDbIndex: automountInformation eq olcDbIndex: uniqueMember eq olcDbIndex: mail eq,subinitial olcDbIndex: sn eq,subinitial olcDbIndex: givenName eq,subinitial olcDbIndex: member eq olcDbIndex: nisMapName eq olcDbIndex: pcacheQueryID eq olcSuffix: dc=example,dc=com slapd doesn't actually 'crash' as in stops running but querying is rendered useless. Here's the output from gdb: >>> slap_listener(ldapi:///) daemon: listen=9, new connection on 12 daemon: added 12r (active) listener=(nil) conn=1000 fd=12 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=9 active_threads=1 tvp=zero daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read active on 12 daemon: epoll: listen=9 active_threads=1 tvp=zero connection_get(12) connection_get(12): got connid=1000 connection_read(12): checking for input on id=1000 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 60 07 02 0....`.. ldap_read: want=6, got=6 0000: 01 03 04 00 80 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0xb891a5a0 ptr=0xb891a5a0 end=0xb891a5ac len=12 0000: 02 01 01 60 07 02 01 03 04 00 80 00 ...`........ op tag 0x60, time 1302056893 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=1000 op=0 do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0xb891a5a0 ptr=0xb891a5a3 end=0xb891a5ac len=9 0000: 60 07 02 01 03 04 00 80 00 `........ ber_scanf fmt (m}) ber: ber_dump: buf=0xb891a5a0 ptr=0xb891a5aa end=0xb891a5ac len=2 0000: 00 00 .. >>> dnPrettyNormal: <> daemon: activity on 1 descriptor <<< dnPrettyNormal: <>, <> conn=1000 op=0 BIND dn="" method=128 do_bind: version=3 dn="" method=128 send_ldap_result: conn=1000 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 12 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ conn=1000 op=0 RESULT tag=97 err=0 text= do_bind: v3 anonymous bind daemon: activity on: daemon: epoll: listen=9 active_threads=1 tvp=zero daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read active on 12 daemon: epoll: listen=9 active_threads=1 tvp=zero connection_get(12) connection_get(12): got connid=1000 connection_read(12): checking for input on id=1000 ber_get_next ldap_read: want=8, got=8 0000: 30 44 02 01 02 63 3f 04 0D...c?. ldap_read: want=62, got=62 0000: 16 64 63 3d 63 61 73 74 6c 65 62 72 61 6e 63 68 .dc=castlebranch 0010: 2c 64 63 3d 63 6f 6d 0a 01 02 0a 01 03 02 01 00 ,dc=com......... 0020: 02 01 00 01 01 00 a0 10 a3 0e 04 03 75 69 64 04 ............uid. 0030: 07 74 6a 67 61 74 65 73 30 04 04 02 64 6e .tjgates0...dn ber_get_next: tag 0x30 len 68 contents: ber_dump: buf=0xb891a570 ptr=0xb891a570 end=0xb891a5b4 len=68 0000: 02 01 02 63 3f 04 16 64 63 3d 63 61 73 74 6c 65 ...c?..dc=castle 0010: 62 72 61 6e 63 68 2c 64 63 3d 63 6f 6d 0a 01 02 branch,dc=com... 0020: 0a 01 03 02 01 00 02 01 00 01 01 00 a0 10 a3 0e ................ 0030: 04 03 75 69 64 04 07 74 6a 67 61 74 65 73 30 04 ..uid..tjgates0. 0040: 04 02 64 6e ..dn op tag 0x63, time 1302056893 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=1000 op=1 do_search ber_scanf fmt ({miiiib) ber: ber_dump: buf=0xb891a570 ptr=0xb891a573 end=0xb891a5b4 len=65 0000: 63 3f 04 16 64 63 3d 63 61 73 74 6c 65 62 72 61 c?..dc=castlebra 0010: 6e 63 68 2c 64 63 3d 63 6f 6d 0a 01 02 0a 01 03 nch,dc=com...... 0020: 02 01 00 02 01 00 01 01 00 a0 10 a3 0e 04 03 75 ...............u 0030: 69 64 04 07 74 6a 67 61 74 65 73 30 04 04 02 64 id..tjgates0...d 0040: 6e n >>> dnPrettyNormal: <dc=castlebranch,dc=com> => ldap_bv2dn(dc=castlebranch,dc=com,0) <= ldap_bv2dn(dc=castlebranch,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=castlebranch,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=castlebranch,dc=com)=0 <<< dnPrettyNormal: <dc=castlebranch,dc=com>, <dc=castlebranch,dc=com> SRCH "dc=castlebranch,dc=com" 2 3 0 0 0 begin get_filter AND begin get_filter_list daemon: activity on 1 descriptor begin get_filter EQUALITY ber_scanf fmt ({mm}) ber: ber_dump: buf=0xb891a570 ptr=0xb891a59e end=0xb891a5b4 len=22 0000: a3 0e 04 03 75 69 64 04 07 74 6a 67 61 74 65 73 ....uid..tjgates 0010: 30 04 04 02 64 6e 0...dn end get_filter 0 end get_filter_list end get_filter 0 filter: (&(uid=tjgates)) ber_scanf fmt ({M}}) ber: ber_dump: buf=0xb891a570 ptr=0xb891a5ae end=0xb891a5b4 len=6 0000: 00 04 04 02 64 6e ....dn attrs: dn conn=1000 op=1 SRCH base="dc=castlebranch,dc=com" scope=2 deref=3 filter="(&(uid=tjgates))" conn=1000 op=1 SRCH attr=dn ==> limits_get: conn=1000 op=1 self="[anonymous]" this="dc=castlebranch,dc=com" => hdb_search bdb(dc=castlebranch,dc=com): PANIC: fatal region error detected; run recovery daemon: activity on: daemon: epoll: listen=9 active_threads=1 tvp=zero bdb(dc=castlebranch,dc=com): PANIC: fatal region error detected; run recovery bdb(dc=castlebranch,dc=com): PANIC: fatal region error detected; run recovery bdb(dc=castlebranch,dc=com): PANIC: fatal region error detected; run recovery send_ldap_result: conn=1000 op=1 p=3 send_ldap_result: err=80 matched="" text="internal error" send_ldap_response: msgid=2 tag=101 err=80 ber_flush2: 28 bytes to sd 12 0000: 30 1a 02 01 02 65 15 0a 01 50 04 00 04 0e 69 6e 0....e...P....in 0010: 74 65 72 6e 61 6c 20 65 72 72 6f 72 ternal error ldap_write: want=28, written=28 0000: 30 1a 02 01 02 65 15 0a 01 50 04 00 04 0e 69 6e 0....e...P....in 0010: 74 65 72 6e 61 6c 20 65 72 72 6f 72 ternal error conn=1000 op=1 SEARCH RESULT tag=101 err=80 nentries=0 text=internal error daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read active on 12 daemon: epoll: listen=9 active_threads=1 tvp=zero connection_get(12) connection_get(12): got connid=1000 connection_read(12): checking for input on id=1000 ber_get_next ldap_read: want=8, got=7 0000: 30 05 02 01 03 42 00 0....B. ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=0xb88fc8f8 ptr=0xb88fc8f8 end=0xb88fc8fd len=5 0000: 02 01 03 42 00 ...B. op tag 0x42, time 1302056893 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=1000 op=2 do_unbind conn=1000 op=2 UNBIND connection_closing: readying conn=1000 sd=12 for close connection_resched: attempting closing conn=1000 sd=12 connection_close: conn=1000 sd=12 =>ldap_back_conn_destroy: fetching conn 1000 daemon: removing 12 conn=1000 fd=12 closed daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=9 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(9): daemon: epoll: listen=9 busy >>> slap_listener(ldapi:///) daemon: listen=9, new connection on 12 daemon: added 12r (active) listener=(nil) conn=1001 fd=12 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=9 active_threads=1 tvp=zero daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read active on 12 daemon: epoll: listen=9 active_threads=1 tvp=zero connection_get(12) connection_get(12): got connid=1001 connection_read(12): checking for input on id=1001 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 60 07 02 0....`.. ldap_read: want=6, got=6 0000: 01 03 04 00 80 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0xb891acc8 ptr=0xb891acc8 end=0xb891acd4 len=12 0000: 02 01 01 60 07 02 01 03 04 00 80 00 ...`........ op tag 0x60, time 1302056901 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=1001 op=0 do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0xb891acc8 ptr=0xb891accb end=0xb891acd4 len=9 0000: 60 07 02 01 03 04 00 80 00 `........ ber_scanf fmt (m}) ber: ber_dump: buf=0xb891acc8 ptr=0xb891acd2 end=0xb891acd4 len=2 0000: 00 00 .. >>> dnPrettyNormal: <> daemon: activity on 1 descriptor <<< dnPrettyNormal: <>, <> conn=1001 op=0 BIND dn="" method=128 do_bind: version=3 dn="" method=128 send_ldap_result: conn=1001 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 12 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ conn=1001 op=0 RESULT tag=97 err=0 text= do_bind: v3 anonymous bind daemon: activity on: daemon: epoll: listen=9 active_threads=1 tvp=zero daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read active on 12 daemon: epoll: listen=9 active_threads=1 tvp=zero connection_get(12) connection_get(12): got connid=1001 connection_read(12): checking for input on id=1001 ber_get_next ldap_read: want=8, got=8 0000: 30 44 02 01 02 63 3f 04 0D...c?. ldap_read: want=62, got=62 0000: 16 64 63 3d 63 61 73 74 6c 65 62 72 61 6e 63 68 .dc=castlebranch 0010: 2c 64 63 3d 63 6f 6d 0a 01 02 0a 01 03 02 01 00 ,dc=com......... 0020: 02 01 00 01 01 00 a0 10 a3 0e 04 03 75 69 64 04 ............uid. 0030: 07 74 6a 67 61 74 65 73 30 04 04 02 64 6e .tjgates0...dn ber_get_next: tag 0x30 len 68 contents: ber_dump: buf=0xb891a570 ptr=0xb891a570 end=0xb891a5b4 len=68 0000: 02 01 02 63 3f 04 16 64 63 3d 63 61 73 74 6c 65 ...c?..dc=castle 0010: 62 72 61 6e 63 68 2c 64 63 3d 63 6f 6d 0a 01 02 branch,dc=com... 0020: 0a 01 03 02 01 00 02 01 00 01 01 00 a0 10 a3 0e ................ 0030: 04 03 75 69 64 04 07 74 6a 67 61 74 65 73 30 04 ..uid..tjgates0. 0040: 04 02 64 6e ..dn op tag 0x63, time 1302056901 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=1001 op=1 do_search ber_scanf fmt ({miiiib) ber: ber_dump: buf=0xb891a570 ptr=0xb891a573 end=0xb891a5b4 len=65 0000: 63 3f 04 16 64 63 3d 63 61 73 74 6c 65 62 72 61 c?..dc=castlebra 0010: 6e 63 68 2c 64 63 3d 63 6f 6d 0a 01 02 0a 01 03 nch,dc=com...... 0020: 02 01 00 02 01 00 01 01 00 a0 10 a3 0e 04 03 75 ...............u 0030: 69 64 04 07 74 6a 67 61 74 65 73 30 04 04 02 64 id..tjgates0...d 0040: 6e n >>> dnPrettyNormal: <dc=castlebranch,dc=com> daemon: activity on 1 descriptor => ldap_bv2dn(dc=castlebranch,dc=com,0) <= ldap_bv2dn(dc=castlebranch,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=castlebranch,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=castlebranch,dc=com)=0 <<< dnPrettyNormal: <dc=castlebranch,dc=com>, <dc=castlebranch,dc=com> SRCH "dc=castlebranch,dc=com" 2 3 0 0 0 begin get_filter AND begin get_filter_list begin get_filter EQUALITY ber_scanf fmt ({mm}) ber: ber_dump: buf=0xb891a570 ptr=0xb891a59e end=0xb891a5b4 len=22 0000: a3 0e 04 03 75 69 64 04 07 74 6a 67 61 74 65 73 ....uid..tjgates 0010: 30 04 04 02 64 6e 0...dn end get_filter 0 end get_filter_list end get_filter 0 filter: (&(uid=tjgates)) ber_scanf fmt ({M}}) ber: ber_dump: buf=0xb891a570 ptr=0xb891a5ae end=0xb891a5b4 len=6 0000: 00 04 04 02 64 6e ....dn attrs: dn conn=1001 op=1 SRCH base="dc=castlebranch,dc=com" scope=2 deref=3 filter="(&(uid=tjgates))" conn=1001 op=1 SRCH attr=dn ==> limits_get: conn=1001 op=1 self="[anonymous]" this="dc=castlebranch,dc=com" => hdb_search bdb(dc=castlebranch,dc=com): PANIC: fatal region error detected; run recovery daemon: activity on: daemon: epoll: listen=9 active_threads=1 tvp=zero bdb(dc=castlebranch,dc=com): PANIC: fatal region error detected; run recovery bdb(dc=castlebranch,dc=com): PANIC: fatal region error detected; run recovery bdb(dc=castlebranch,dc=com): PANIC: fatal region error detected; run recovery send_ldap_result: conn=1001 op=1 p=3 send_ldap_result: err=80 matched="" text="internal error" send_ldap_response: msgid=2 tag=101 err=80 ber_flush2: 28 bytes to sd 12 0000: 30 1a 02 01 02 65 15 0a 01 50 04 00 04 0e 69 6e 0....e...P....in 0010: 74 65 72 6e 61 6c 20 65 72 72 6f 72 ternal error ldap_write: want=28, written=28 0000: 30 1a 02 01 02 65 15 0a 01 50 04 00 04 0e 69 6e 0....e...P....in 0010: 74 65 72 6e 61 6c 20 65 72 72 6f 72 ternal error conn=1001 op=1 SEARCH RESULT tag=101 err=80 nentries=0 text=internal error daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read active on 12 daemon: epoll: listen=9 active_threads=1 tvp=zero connection_get(12) connection_get(12): got connid=1001 connection_read(12): checking for input on id=1001 ber_get_next ldap_read: want=8, got=7 0000: 30 05 02 01 03 42 00 0....B. ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=0xb88f9d00 ptr=0xb88f9d00 end=0xb88f9d05 len=5 0000: 02 01 03 42 00 ...B. op tag 0x42, time 1302056901 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=1001 op=2 do_unbind conn=1001 op=2 UNBIND connection_closing: readying conn=1001 sd=12 for close connection_resched: attempting closing conn=1001 sd=12 connection_close: conn=1001 sd=12 =>ldap_back_conn_destroy: fetching conn 1001 daemon: removing 12 conn=1001 fd=12 closed daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=9 active_threads=0 tvp=NULL I don't know if it is related but I have been having crashing issues with previous versions of openldap using pcache which I have submitted and ITS(6878) for: http://www.openldap.org/its/index.cgi/Incoming?selectid=6878;statetype=-1

1 0

(ITS#6890) SHA2 Password Hashing not working
by sudharma.thikkavarapu＠siemens.com 04 Apr '11

04 Apr '11

Full_Name: SUDHARMA Version: $OpenLDAP: slapd 2.4.23 (Apr 4 2011 13:48:06) OS: AIX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (161.134.39.30) Hello, we are planning to encrypt the password using SHA2 so i have followed the steps that are required to use slapd-modules/passwd/sha2 in openLDAP code. I have modified the slapd.conf file to load the correct libraries etc.. when i try to generate the hash value for a password i get the following error. testdev# slappasswd -h {SHA512} New password: Re-enter new password: Password generation failed for scheme {SHA512}: scheme not recognized I have to mention that i had problems compiling the sha2 source code with the cc compiler but when i use the xlc i had no issues and compiled the source successfully. Here are the commands xlc -I/home/openldap-2.4.23/include -g -c slapd-sha2.c xlc -I/home/openldap-2.4.23/include -g -c sha2.c xlc -G -I/home/openldap-2.4.23/include -g sha2.o slapd-sha2.o -o slapd-sha2.so hope i haven't done anything wrong. Please suggest me how to make this work. Thank you much for your help. Best Regards, Sudharma

1 0

(ITS#6889) client libraries not linked against libfetch when building with it
by delphij＠FreeBSD.org 04 Apr '11

04 Apr '11

Full_Name: Xin LI Version: 2.4.25 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.40.55.65) When OpenLDAP is configured with fetch(3) support on FreeBSD, client libraries are not linked against libfetch.so, but rather link it against management binaries. This would cause problem when the consumer does not explicitly request libfetch.so linkage. We currently have a very brute force fix in FreeBSD port to solve this: http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/openldap24-server/files/pat…

1 0

Re: (ITS#6888) slapd 2.4.23 terminating with 'SIGABRT'
by jwebb＠localnet.com 03 Apr '11

03 Apr '11

The reason we are running 5 clients (each with 10 threads) performing concurrent wildcard searches on "unindexed attributes", is purely and simply.... load testing. the test seems reasonable enough that (with our current configuration) slapd should be able to handle it with terminating with a 'SIGABRT'... am i wrong in assuming this? J

1 0

Re: (ITS#6888) slapd 2.4.23 terminating with 'SIGABRT'
by jwebb＠localnet.com 03 Apr '11

03 Apr '11

Additional info about our server: we are running 32 bit for all installed /compiled programs Josiah

1 0

Re: (ITS#6878) ppcache segfault with tavl_delete
by tjgates＠castlebranch.com 03 Apr '11

03 Apr '11

------=_Part_481677_474224743.1301865460773 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Just checking in.. Is there anything I can do to help? If it helps, running slapd in debug mode wouldn't crash on me after over 2 1/2 weeks of running. Maybe a race condition among all the different threads? -- Tyler Gates Systems Administrator Castle Branch Inc. 910-815-3880 ext 7230 tjgates(a)castlebranch.com This e-mail message, including any attachments, may contain private, confidential, and privileged information for the restricted use of the intended recipient(s). If you are not the intended recipient(s), you may NOT use, disclose, copy, or disseminate this information. Please notify the sender by return e-mail of this misdirected correspondence and destroy all copies of the original message including all attachments. Your cooperation is appreciated. ------=_Part_481677_474224743.1301865460773 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Arial; font-size: 12pt; color: #000000'>Just checking in.. Is there anything I can do to help? If it helps, running slapd in debug mode wouldn't crash on me after over 2 1/2 weeks of running. Maybe a race condition among all the different threads? -- Tyler Gates Systems Administrator Castle Branch Inc. 910-815-3880 ext 7230 tjgates(a)castlebranch.com This e-mail message, including any attachments, may contain private, confidential, and privileged information for the restricted use of the intended recipient(s). If you are not the intended recipient(s), you may NOT use, disclose, copy, or disseminate this information. Please notify the sender by return e-mail of this misdirected correspondence and destroy all copies of the original message including all attachments. Your cooperation is appreciated. </div></body></ html> ------=_Part_481677_474224743.1301865460773--

1 0

Re: (ITS#6887) authz-regexp: backslash escaping/normalization
by daniel＠pluta.biz 03 Apr '11

03 Apr '11

Update: The above report belongs to Version 2.4.24

1 0

(ITS#6888) slapd 2.4.23 terminating with 'SIGABRT'
by jwebb＠localnet.com 03 Apr '11

03 Apr '11

Full_Name: Josiah Webb Version: 2.4.23 OS: Debian Lenny (5.0.2) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (146.115.147.2) When running 5 concurrent ldapsearch clients (each with 10 concurrent threads) for unindexed attributes, slapd terminates with a SIGABRT about 3/4 of the way through all dn's. here is the gdb interpreted core file dump and backtrace: ----------------------------------------------------------------- awesome@ldapmaster-dev:~$ gdb /usr/local/libexec/slapd core.12907 GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu"... warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/local/lib/libtcmalloc.so.0...done. Loaded symbols for /usr/local/lib/libtcmalloc.so.0 Reading symbols from /usr/lib/libltdl.so.3...done. Loaded symbols for /usr/lib/libltdl.so.3 Reading symbols from /lib/i686/cmov/libdl.so.2...done. Loaded symbols for /lib/i686/cmov/libdl.so.2 Reading symbols from /usr/lib/libdb-4.6.so...done. Loaded symbols for /usr/lib/libdb-4.6.so Reading symbols from /lib/i686/cmov/libpthread.so.0...done. Loaded symbols for /lib/i686/cmov/libpthread.so.0 Reading symbols from /usr/lib/i686/cmov/libssl.so.0.9.8...done. Loaded symbols for /usr/lib/i686/cmov/libssl.so.0.9.8 Reading symbols from /usr/lib/i686/cmov/libcrypto.so.0.9.8...done. Loaded symbols for /usr/lib/i686/cmov/libcrypto.so.0.9.8 Reading symbols from /lib/i686/cmov/libcrypt.so.1...done. Loaded symbols for /lib/i686/cmov/libcrypt.so.1 Reading symbols from /lib/i686/cmov/libresolv.so.2...done. Loaded symbols for /lib/i686/cmov/libresolv.so.2 Reading symbols from /lib/i686/cmov/libc.so.6...done. Loaded symbols for /lib/i686/cmov/libc.so.6 Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/i686/cmov/libm.so.6...done. Loaded symbols for /lib/i686/cmov/libm.so.6 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/i686/cmov/libnss_files.so.2...done. Loaded symbols for /lib/i686/cmov/libnss_files.so.2 Core was generated by `/usr/local/libexec/slapd -d -1'. Program terminated with signal 6, Aborted. [New process 12911] [New process 12935] [New process 12934] [New process 12933] [New process 12932] [New process 12931] [New process 12930] [New process 12929] [New process 12928] [New process 12927] [New process 12926] [New process 12925] [New process 12924] [New process 12912] [New process 12907] [New process 12910] [New process 12909] [New process 12908] #0 0xb7f43424 in __kernel_vsyscall () (gdb) backtrace #0 0xb7f43424 in __kernel_vsyscall () #1 0xb7a7c640 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb7a7e018 in abort () from /lib/i686/cmov/libc.so.6 #3 0xb7a755be in __assert_fail () from /lib/i686/cmov/libc.so.6 #4 0x0809853b in ch_malloc (size=1407) at ch_malloc.c:57 #5 0x08132a7a in hdb_id2entry (be=0x15ef5f64, tid=0xbb232d0, id=170395, e=0x15e35d08) at id2entry.c:143 #6 0x08128fea in hdb_cache_find_id (op=0xc429000, tid=0xbb232d0, id=170395, eip=0x15ef5eec, flag=2, lock=0x15ef5e44) at cache.c:998 #7 0x08103923 in hdb_search (op=0xc429000, rs=0x15ef7148) at search.c:707 #8 0x080e40dc in overlay_op_walk (op=0xc429000, rs=0x15ef7148, which=op_search, oi=0x9e39100, on=0x9e39400) at backover.c:669 #9 0x080e4ba1 in over_op_func (op=0xc429000, rs=0x15ef7148, which=op_search) at backover.c:721 #10 0x0807dc63 in fe_op_search (op=0xc429000, rs=0x15ef7148) at search.c:366 #11 0x0807e4d8 in do_search (op=0xc429000, rs=0x15ef7148) at search.c:217 #12 0x0807b546 in connection_operation (ctx=0x15ef7228, arg_v=0xc429000) at connection.c:1109 #13 0x0807c17f in connection_read_thread (ctx=0x15ef7228, argv=0x13) at connection.c:1245 #14 0x081590ec in ldap_int_thread_pool_wrapper (xpool=0x9e0a0b0) at tpool.c:685 #15 0xb7d924c0 in start_thread () from /lib/i686/cmov/libpthread.so.0 #16 0xb7b316de in clone () from /lib/i686/cmov/libc.so.6 --------------------------------------------------------------- the slapd standard log (/var/log/syslog), logged no errors whatsoever, slapd simply "stopped: no "out of memory" issues either free -m (taken at the exact time of the SIGABRT): total used free shared buffers cached Mem: 8115 7492 623 0 226 1895 -/+ buffers/cache: 5370 2744 Swap: 2055 0 2055 Running a freshly compiled 2.4.23 openldap, which was compiled against tcmalloc (malloc replacement) from google-perftools-1.7 (standard build commands: ./configure, make, make install (no errors) openldap compiled as follows: ./configure LDFLAGS="-fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -ltcmalloc" --enable-slapd --enable-bdb --enable-modules --enable-accesslog --enable-syncprov --enable-crypt --enable-cleartext --enable-syslog --enable-debug make depend make make test make install STRIP="" no errors during build. backend is Berkely DB 4.6.21-16, which contains the following patches: http://www.oracle.com/technetwork/database/berkeleydb/patch-098875.html slapd.conf as follows: ##################### # Global Directives # ##################### allow bind_v2 include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/qmail.schema include /usr/local/etc/openldap/schema/radius.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats sync config none threads 16 gentlehup on sizelimit 500 tool-threads 4 backend hdb ############################## # Main Backend DB Directives # ############################## database hdb suffix "dc=localnet,dc=com" rootdn "cn=Manager,dc=localnet,dc=com" rootpw {SSHA}Kcv02GxN6YBuUVV+ct10VAxrc3c1iPei directory "/local/var/openldap-bdb" dbconfig set_cachesize 2 147483648 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 cachesize 50000 idlcachesize 200000 cachefree 1000 index objectClass eq index cn eq index sn eq index uid eq index mail eq index mailAlternateAddress eq index mailForwardingAddress eq index radiusUID eq index uidNumber eq index gidNumber eq index overquota eq index mailhost eq index entryCSN eq index entryUUID eq overlay accesslog logdb "cn=accesslog" logops writes logsuccess TRUE logpurge 02+00:00 01+00:00 overlay syncprov syncprov-checkpoint 10 5 checkpoint 1024 5 limits dn.exact="cn=Manager,dc=localnet,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited ################################### # Accesslog Backend DB Directives # ################################### database hdb suffix "cn=accesslog" directory "/usr/local/var/openldap-data" dbconfig set_cachesize 0 268435456 1 dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 10485760 dbconfig set_lg_bsize 2097152 dbconfig set_lg_dir /usr/local/var/openldap-data dbconfig set_tmp_dir /tmp dbconfig set_flags DB_LOG_AUTOREMOVE cachesize 2000 idlcachesize 8000 cachefree 100 checkpoint 1024 5 lastmod on index default eq index objectClass index entryCSN index reqEnd index reqResult index reqStart overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE limits dn.exact="cn=Manager,dc=localnet,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited ######################### # Access ACL Directives # ######################### access to * by dn="cn=Manager,dc=localnet,dc=com" write by * read by anonymous auth by self write # end slapd.conf Server is a 4 core Intel Xeon E5320 Debian Lenny box with 2.6.26-2-686-bigmem kernel and 8GB of physical memory. Our entire data set (.bdb) including indexes totals 1.3GB. we have a large enough set_cachesize to store our entire data set in memory. Our LDAP tree contains around 200,000 dn's please advise, or let me know if you need further details or information thanks!

1 0

(ITS#6887) authz-regexp: backslash escaping/normalization
by daniel＠pluta.biz 02 Apr '11

02 Apr '11

Full_Name: Daniel Pluta Version: 2.4.23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4ca0:0:fe15::1) 1.) Following authz-regexp statement looks and works fine with slapd: authz-regexp uid=([^,]+)@([^,]+),cn=(PLAIN|LOGIN|DIGEST-MD5|CRAM-MD5),cn=auth "ldap:///ou=users,ou=$1,dc=foo,dc=bar??one?(mail=$2)" do_bind: dn () SASL mech DIGEST-MD5 SASL [conn=1000] Debug: DIGEST-MD5 server step 2 slap_sasl_getdn: u:id converted to uid=domain@user,cn=DIGEST-MD5,cn=auth >>> dnNormalize: <uid=domain@user,cn=DIGEST-MD5,cn=auth> <<< dnNormalize: <uid=domain@user,cn=digest-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=domain@user,cn=digest-md5,cn=auth to a DN ==> rewrite_context_apply [depth=1] string='uid=domain@user,cn=digest-md5,cn=auth' ==> rewrite_rule_apply rule='uid=([^,]+)@([^,]+),cn=(PLAIN|LOGIN|DIGEST-MD5|CRAM-MD5),cn=auth' string='uid=domain@user,cn=digest-md5,cn=auth' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'ldap:///ou=users,ou=domain,dc=foo,dc=bar??one?(mail=user)'} slap_parseURI: parsing ldap:///ou=users,ou=domain,dc=foo,dc=bar??one?(mail=user) ldap_url_parse_ext(ldap:///ou=users,ou=domain,dc=foo,dc=bar??one?(mail=user)) put_filter: "(mail=user)" put_filter: simple put_simple_filter: "mail=user" ber_scanf fmt ({mm}) ber: >>> dnNormalize: <ou=users,ou=domain,dc=foo,dc=bar> <<< dnNormalize: <ou=users,ou=domain,dc=foo,dc=bar> slap_sasl2dn: performing internal search (base=ou=users,ou=domain,dc=foo,dc=bar, scope=1) => hdb_search bdb_dn2entry("ou=users,ou=domain,dc=foo,dc=bar") => hdb_dn2id("ou=domain,dc=foo,dc=bar") ========================================================================== 1.) Following authz-regexp where the @-separator is replaced by a \-separator seems to cause problems: authz-regexp uid=([^,]+)\\([^,]+),cn=(PLAIN|LOGIN|DIGEST-MD5|CRAM-MD5),cn=auth "ldap:///ou=users,ou=$1,dc=foo,dc=bar??one?(mail=$2)" Looks strange: do_bind: dn () SASL mech DIGEST-MD5 SASL [conn=1000] Debug: DIGEST-MD5 server step 2 slap_sasl_getdn: u:id converted to uid=domain\5Cuser,cn=DIGEST-MD5,cn=auth >>> dnNormalize: <uid=domain\5Cuser,cn=DIGEST-MD5,cn=auth> <<< dnNormalize: <uid=domain\5Cuser,cn=digest-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=domain\5Cuser,cn=digest-md5,cn=auth to a DN ==> rewrite_context_apply [depth=1] string='uid=domain\5Cuser,cn=digest-md5,cn=auth' ==> rewrite_rule_apply rule='uid=([^,]+)\([^,]+),cn=(PLAIN|LOGIN|DIGEST-MD5|CRAM-MD5),cn=auth' string='uid=domain\5Cuser,cn=digest-md5,cn=auth' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'uid=domain\5Cuser,cn=digest-md5,cn=auth'} slap_parseURI: parsing uid=domain\5Cuser,cn=digest-md5,cn=auth ldap_url_parse_ext(uid=domain\5Cuser,cn=digest-md5,cn=auth) >>> dnNormalize: <uid=domain\5Cuser,cn=digest-md5,cn=auth> <<< dnNormalize: <uid=domain\5Cuser,cn=digest-md5,cn=auth> <==slap_sasl2dn: Converted SASL name to uid=domain\5Cuser,cn=digest-md5,cn=auth slap_sasl_getdn: dn:id converted to uid=domain\5Cuser,cn=digest-md5,cn=auth ========================================================================== 3. Just one more try to using "[\\]" instead of "\\" authz-regexp uid=([^,]+)[\\]([^,]+),cn=(PLAIN|LOGIN|DIGEST-MD5|CRAM-MD5),cn=auth "ldap:///ou=users,ou=$1,dc=foo,dc=bar??one?(mail=$2)" Looks strange too: do_bind: dn () SASL mech DIGEST-MD5 SASL [conn=1000] Debug: DIGEST-MD5 server step 2 slap_sasl_getdn: u:id converted to uid=domain\5Cuser,cn=DIGEST-MD5,cn=auth >>> dnNormalize: <uid=domain\5Cuser,cn=DIGEST-MD5,cn=auth> <<< dnNormalize: <uid=domain\5Cuser,cn=digest-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=domain\5Cuser,cn=digest-md5,cn=auth to a DN ==> rewrite_context_apply [depth=1] string='uid=domain\5Cuser,cn=digest-md5,cn=auth' ==> rewrite_rule_apply rule='uid=([^,]+)[\]([^,]+),cn=(PLAIN|LOGIN|DIGEST-MD5|CRAM-MD5),cn=auth' string='uid=domain\5Cuser,cn=digest-md5,cn=auth' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'ldap:///ou=users,ou=domain,dc=foo,dc=bar??one?(mail=5Cuser)'} slap_parseURI: parsing ldap:///ou=users,ou=domain,dc=foo,dc=bar??one?(mail=5Cuser) ldap_url_parse_ext(ldap:///ou=users,ou=domain,dc=foo,dc=bar??one?(mail=5Cuser)) put_filter: "(mail=5Cuser)" put_filter: simple put_simple_filter: "mail=5Cuser" ber_scanf fmt ({mm}) ber: >>> dnNormalize: <ou=users,ou=domain,dc=foo,dc=bar> <<< dnNormalize: <ou=users,ou=domain,dc=foo,dc=bar> slap_sasl2dn: performing internal search (base=ou=users,ou=domain,dc=foo,dc=bar, scope=1)

1 0

[PATCH] More for ITS#6872
by cmikk＠qwest.net 30 Mar '11

30 Mar '11

[Note: The previous patch did not fix the problem when the consumer's access was restricted to the replicated subtree. This patch fixes that.] Perform the internal FIND_CSN search based at the backend's suffix with the privileges of the backend's root DN. --- servers/slapd/overlays/syncprov.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c index 0c148f9..a058e19 100644 --- a/servers/slapd/overlays/syncprov.c +++ b/servers/slapd/overlays/syncprov.c @@ -661,6 +661,8 @@ again: if ( BER_BVISEMPTY( &cf.f_av_value )) { cf.f_av_value = *csn; } + fop.o_dn = op->o_bd->be_rootdn; + fop.o_ndn = op->o_bd->be_rootndn; fop.o_req_dn = op->o_bd->be_suffix[0]; fop.o_req_ndn = op->o_bd->be_nsuffix[0]; /* Look for exact match the first time */ -- 1.7.1.1

1 0

(ITS#6886) slapo-dds: Wrong tag in Refresh Response
by michael＠stroeder.com 30 Mar '11

30 Mar '11

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (195.145.144.134) The Refresh Response sent back by slapo-dds contains tag [0] instead of [1] as described in section 4.2 of RFC 2589: The response field will contain as a value the DER-encoding of the following ASN.1 data type: SEQUENCE { responseTtl [1] INTEGER } If I assume [0] in my client when decoding it works...

1 0

Re: (ITS#6878) ppcache segfault with tavl_delete
by tjgates＠castlebranch.com 30 Mar '11

30 Mar '11

Just crashed: Program received signal SIGABRT, Aborted. [Switching to Thread 0xb07f3b70 (LWP 24359)] 0xb77a7430 in __kernel_vsyscall () (gdb) (gdb) bt #0 0xb77a7430 in __kernel_vsyscall () #1 0xb727a651 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb727da82 in *__GI_abort () at abort.c:92 #3 0xb72b149d in __libc_message (do_abort=2, fmt=0xb7385f98 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #4 0xb72bb591 in malloc_printerr (action=<value optimized out>, str=0x6 <Address 0x6 out of bounds>, ptr=0xb8d93a40) at malloc.c:6266 #5 0xb72bcde8 in _int_free (av=<value optimized out>, p=<value optimized out>) at malloc.c:4794 #6 0xb72bfecd in *__GI___libc_free (mem=0xb8d93a40) at malloc.c:3738 #7 0xb7750c20 in ber_memfree_x () from /usr/lib/liblber-2.4.so.2 #8 0xb7750caf in ber_bvarray_free_x () from /usr/lib/liblber-2.4.so.2 #9 0xb7750cf5 in ber_bvarray_free () from /usr/lib/liblber-2.4.so.2 #10 0xb7808f3d in attr_clean (a=0xb688ff64) at /tmp/buildd/openldap-2.4.24/servers/slapd/attr.c:146 #11 0xb7808fdb in attrs_free (a=0xb688ff64) at /tmp/buildd/openldap-2.4.24/servers/slapd/attr.c:196 #12 0xb6e2db0f in hdb_cache_modify (bdb=0xb8c104b0, e=0xb8c57b5c, newAttrs=0xb688ed64, txn=0xb8d93ea8, lock=0xb07f11f0) at cache.c:1226 #13 0xb6e1901c in hdb_modify (op=0xb07f152c, rs=0xb07f1368) at modify.c:669 #14 0xb6e47258 in merge_entry (op=<value optimized out>, e=0xb8c58264, dup=0, query_uuid=0xb8c9b130) at /tmp/buildd/openldap-2.4.24/servers/slapd/overlays/pcache.c:874 #15 0xb6e4effc in cache_entries (op=<value optimized out>, query_uuid=<value optimized out>) at /tmp/buildd/openldap-2.4.24/servers/slapd/overlays/pcache.c:2291 #16 0xb6e4f3ed in pcache_op_cleanup (op=0xb8c829d8, rs=0xb07f2ffc) at /tmp/buildd/openldap-2.4.24/servers/slapd/overlays/pcache.c:2396 #17 0xb78102ee in slap_cleanup_play (op=<value optimized out>, rs=<value optimized out>) at /tmp/buildd/openldap-2.4.24/servers/slapd/result.c:539 #18 0xb7810fa9 in send_ldap_response (op=0xb8c829d8, rs=0xb07f2ffc) at /tmp/buildd/openldap-2.4.24/servers/slapd/result.c:724 #19 0xb781209c in slap_send_ldap_result (op=0xb8c829d8, rs=0xb07f2ffc) at /tmp/buildd/openldap-2.4.24/servers/slapd/result.c:851 #20 0xb6e6a987 in ldap_back_search (op=0xb8c829d8, rs=0xb07f2ffc) at /tmp/buildd/openldap-2.4.24/servers/slapd/back-ldap/search.c:574 #21 0xb787802b in overlay_op_walk (op=0xb8c829d8, rs=0xb07f2ffc, which=op_search, oi=0xb8c10fe0, on=0xb8c10260) at /tmp/buildd/openldap-2.4.24/servers/slapd/backover.c:669 #22 0xb7878d58 in over_op_func (op=<value optimized out>, rs=<value optimized out>, which=op_search) at /tmp/buildd/openldap-2.4.24/servers/slapd/backover.c:721 #23 0xb7800b54 in fe_op_search (op=0xb8c829d8, rs=0xb07f2ffc) at /tmp/buildd/openldap-2.4.24/servers/slapd/search.c:372 #24 0xb78014e7 in do_search (op=0xb8c829d8, rs=0xb07f2ffc) at /tmp/buildd/openldap-2.4.24/servers/slapd/search.c:217 #25 0xb77fd994 in connection_operation (ctx=0xb07f31dc, arg_v=0xb8c829d8) at /tmp/buildd/openldap-2.4.24/servers/slapd/connection.c:1113 #26 0xb77fe492 in connection_read_thread (ctx=0xb07f31dc, argv=0x28) at /tmp/buildd/openldap-2.4.24/servers/slapd/connection.c:1249 #27 0xb77634f4 in ?? () from /usr/lib/libldap_r-2.4.so.2 #28 0xb73af96e in start_thread (arg=0xb07f3b70) at pthread_create.c:300 #29 0xb731da4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 (gdb) she gdb shell is still open, let me know if I can provide any further information. On 03/24/2011 01:34 PM, Quanah Gibson-Mount wrote: > --On Thursday, March 24, 2011 4:28 PM +0000 tjgates(a)castlebranch.com > wrote: > >> Full_Name: Tyler Gates >> Version: 2.4.21 >> OS: Ubuntu 10.04.2 LTS/CentOS 5.4 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (24.106.216.17) >> >> >> I have a caching proxy server (2.4.21) in front of two multi-masters. >> After about 1 to 3 days it will segfault only when caching is enabled. >> Log files are normally pretty useless but are normally in the operation >> of removing stale queries: > > Bug reports with 2.4.21 are not being pursued. Please use a current > release (2.4.24) and verify whether or not the issue still exists 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 -- Tyler Gates Systems Administrator Castle Branch Inc. 910-815-3880 ext 7230 tjgates(a)castlebranch.com This e-mail message, including any attachments, may contain private, confidential, and privileged information for the restricted use of the intended recipient(s). If you are not the intended recipient(s), you may NOT use, disclose, copy, or disseminate this information. Please notify the sender by return e-mail of this misdirected correspondence and destroy all copies of the original message including all attachments. Your cooperation is appreciated.

1 0

Re: (ITS#6885) Compile error in liblutil/meter.c without HAVE_GETTIMEOFDAY
by h.b.furuseth＠usit.uio.no 30 Mar '11

30 Mar '11

adam(a)anope.org writes: > Line 92 should be: > *now = (double) tm; Thanks. Fixed in the master branch. -- Hallvard

1 0

(ITS#6885) Compile error in liblutil/meter.c without HAVE_GETTIMEOFDAY
by adam＠anope.org 29 Mar '11

29 Mar '11

Full_Name: Adam Version: 2.4 OS: cygwin on Windows URL: Submission from: (NULL) (97.101.44.106) http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… Line 92 should be: *now = (double) tm;

1 0

Re: (ITS#6884) contrib: password syntax checking overlay
by Kurt＠OpenLDAP.org 29 Mar '11

29 Mar '11

On Mar 29, 2011, at 2:11 PM, mathieu.baeumler(a)gmail.com wrote: > Full_Name: Mathieu Baeumler > Version: 2.4.24 > OS: Debian GNU/Linux > URL: ftp://ftp.openldap.org/incoming/mathieu-baeumler-110329.tgz > Submission from: (NULL) (94.252.66.219) > > > Hello, > > Please find a new overlay that enforces syntactic constraints on passwords. This > overlay can also be used in conjunction with the ppolicy overlay, as it > implements the check_password function. > > See the man page (slapo-pwdconstraint.5) for details on how to use it. > > Regards, > > Mathieu Baeumler > > /* > * Copyright 2011 Mathieu Baeumler, Dimension Data. All rights reserved. > * > * OIDs under 1.3.6.1.4.1.10076 courtesy of European Commission. This doesn't seem like text appropriately placed in a copyright notice. > * > * 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>. > */ 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. -- Kurt

1 0

[PATCH] ITS#6872
by cmikk＠qwest.net 29 Mar '11

29 Mar '11

--- servers/slapd/overlays/syncprov.c | 19 +++++++------------ 1 files changed, 7 insertions(+), 12 deletions(-) diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c index 3c64763..0c148f9 100644 --- a/servers/slapd/overlays/syncprov.c +++ b/servers/slapd/overlays/syncprov.c @@ -586,7 +586,7 @@ findpres_cb( Operation *op, SlapReply *rs ) } static int -syncprov_findcsn( Operation *op, find_csn_t mode ) +syncprov_findcsn( Operation *op, find_csn_t mode, struct berval *csn ) { slap_overinst *on = (slap_overinst *)op->o_bd->bd_info; syncprov_info_t *si = on->on_bi.bi_private; @@ -659,15 +659,10 @@ again: break; case FIND_CSN: if ( BER_BVISEMPTY( &cf.f_av_value )) { - cf.f_av_value = srs->sr_state.ctxcsn[0]; - /* If there are multiple CSNs, use the smallest */ - for ( i=1; i<srs->sr_state.numcsns; i++ ) { - if ( ber_bvcmp( &cf.f_av_value, &srs->sr_state.ctxcsn[i] ) - > 0 ) { - cf.f_av_value = srs->sr_state.ctxcsn[i]; - } - } + cf.f_av_value = *csn; } + fop.o_req_dn = op->o_bd->be_suffix[0]; + fop.o_req_ndn = op->o_bd->be_nsuffix[0]; /* Look for exact match the first time */ if ( findcsn_retry ) { cf.f_choice = LDAP_FILTER_EQUALITY; @@ -2624,7 +2619,7 @@ no_change: if ( !(op->o_sync_mode & SLAP_SYNC_PERSIST) ) { } } /* Is the CSN still present in the database? */ - if ( syncprov_findcsn( op, FIND_CSN ) != LDAP_SUCCESS ) { + if ( syncprov_findcsn( op, FIND_CSN, &mincsn ) != LDAP_SUCCESS ) { /* No, so a reload is required */ /* the 2.2 consumer doesn't send this hint */ if ( si->si_usehint && srs->sr_rhint == 0 ) { @@ -2648,7 +2643,7 @@ no_change: if ( !(op->o_sync_mode & SLAP_SYNC_PERSIST) ) { } else { gotstate = 1; /* If changed and doing Present lookup, send Present UUIDs */ - if ( do_present && syncprov_findcsn( op, FIND_PRESENT ) != + if ( do_present && syncprov_findcsn( op, FIND_PRESENT, 0 ) != LDAP_SUCCESS ) { if ( ctxcsn ) ber_bvarray_free_x( ctxcsn, op->o_tmpmemctx ); @@ -2976,7 +2971,7 @@ syncprov_db_otask( void *ptr ) { - syncprov_findcsn( ptr, FIND_MAXCSN ); + syncprov_findcsn( ptr, FIND_MAXCSN, 0 ); return NULL; } -- 1.7.1.1

1 0

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

29 Mar '11

Full_Name: Mathieu Baeumler Version: 2.4.24 OS: Debian GNU/Linux URL: ftp://ftp.openldap.org/incoming/mathieu-baeumler-110329.tgz Submission from: (NULL) (94.252.66.219) Hello, Please find a new overlay that enforces syntactic constraints on passwords. This overlay can also be used in conjunction with the ppolicy overlay, as it implements the check_password function. See the man page (slapo-pwdconstraint.5) for details on how to use it. Regards, Mathieu Baeumler /* * Copyright 2011 Mathieu Baeumler, Dimension Data. All rights reserved. * * OIDs under 1.3.6.1.4.1.10076 courtesy of European Commission. * * 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>. */

1 0

Re: (ITS#6883) Improved Makefiles for contrib modules
by quanah＠zimbra.com 29 Mar '11

29 Mar '11

--On Tuesday, March 29, 2011 3:25 PM +0000 bgmilne(a)staff.telkomsa.net wrote: > Full_Name: Buchan Milne > Version: 2.4.25 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (196.25.124.16) > > > While the code in contrib is not supported, some overlays provide make > files, some don't, and there were variations in a lot of the make files > (e.g. use of DESTDIR or not). > > In order to add make files for overlays that don't have them, improve the > consistency of the make files between overlays that had them, and to > provide some basic sanity testing in a 'test' target, I have created the > patch at: > http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/openldap/curre > nt/SOURCES/openldap-2.4.25-contrib-makefiles-with-tests.patch?revision=64 > 8744&view=markup > > The patch is against 2.4.25, but should apply to master (except that > there two additional overlays are present in master). Where feasible I > have retained the majority of an existing make file, in other cases, > where modifications would exceed the original content, I have replaced > existing make files wholesale. > > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following patch(es) > were developed by Buchan Milne (bgmilne(a)staff.telkomsa.net). I have not > assigned rights and/or interest in this work to any party. Hi Buchan, Can you make the patch available via git-format-patch? Thanks, 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: Another fix for (ITS#6872)
by quanah＠zimbra.com 29 Mar '11

29 Mar '11

--On Tuesday, March 29, 2011 5:46 PM +0000 cmikk(a)qwest.net wrote: > I've corrected the above patch (si->si_contextdn was only > coincidentally the correct value to use there), combined > it with the previous patch, and posted the result at: > > http://mikk.net/~chris/syncprov/patch-syncprov.c Hi Chris, We just finished our migration to git. As git is now available, patches via git-format-patch are now preferred. Thanks! --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: Another fix for (ITS#6872)
by cmikk＠qwest.net 29 Mar '11

29 Mar '11

I've corrected the above patch (si->si_contextdn was only coincidentally the correct value to use there), combined it with the previous patch, and posted the result at: http://mikk.net/~chris/syncprov/patch-syncprov.c Thanks, -Chris

1 0

(ITS#6883) Improved Makefiles for contrib modules
by bgmilne＠staff.telkomsa.net 29 Mar '11

29 Mar '11

Full_Name: Buchan Milne Version: 2.4.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.25.124.16) While the code in contrib is not supported, some overlays provide make files, some don't, and there were variations in a lot of the make files (e.g. use of DESTDIR or not). In order to add make files for overlays that don't have them, improve the consistency of the make files between overlays that had them, and to provide some basic sanity testing in a 'test' target, I have created the patch at: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/openldap/current… The patch is against 2.4.25, but should apply to master (except that there two additional overlays are present in master). Where feasible I have retained the majority of an existing make file, in other cases, where modifications would exceed the original content, I have replaced existing make files wholesale. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Buchan Milne (bgmilne(a)staff.telkomsa.net). I have not assigned rights and/or interest in this work to any party.

1 0

Re: (ITS#6882) Mirror in Hamburg, germany
by Kurt Zeilenga 29 Mar '11

29 Mar '11

While we appreciate your re-newed offer, as our needs have not changed we continue not to accept new official mirrors. This, and well as your previous offer, will remain on file in case our needs do change. Regards, Kurt

1 0

(ITS#6882) Mirror in Hamburg, germany
by mirror＠artfiles.org 29 Mar '11

29 Mar '11

Full_Name: Andreas Worbs Version: OS: URL: Submission from: (NULL) (80.252.98.63) Hi, i wrote you a few months ago about our mirror but you weren't interested. So i want to ask you if you are interested now? Our mirror is in Hamburg, Germany and has a bandwith of 1 Gbit/s. The URLs: http://artfiles.org/openldap.org/ ftp://artfiles.org/openldap.org/

1 0

Re: (ITS#6868) When used in conjunction with the translucent overlay, the rwm overlay filters out auxiliary objectclasses
by h.b.furuseth＠usit.uio.no 29 Mar '11

29 Mar '11

Note, this bug is not related to auxiliary classes. The same thing happens if you add a superclass like 'top' instead of extensibleObject. ali.pouya(a)free.fr writes: > Can someone help me about this problem ? > We use Samba in our project and it needs some auxiliary classes which > disappear in this configuration. > The design of my project depends on the correction of this bug. OpenLDAP is volunteer-driven, currently busy with migration from CVS to Git, and we'll get to the bug when we get to it. If you can't wait to see if that'll be soon, the openldap-technical mailinglist has a wider readership than the bug database. Maybe your problem can be solved differently if you describe what you want in more detail, and someone there can think of how: http://www.openldap.org/lists/mm/listinfo/openldap-technical Or you can pay someone to fix the bug: http://www.openldap.org/support/ I can think of a things to try myself. Maybe you can rearrange your setup to put rwm on another database, or maybe it's a recent bug and it works with an earlier OpenLDAP version. -- Hallvard

1 0

Re: (ITS#6868) When used in conjunction with the translucent overlay, the rwm overlay filters out auxiliary objectclasses
by ali.pouya＠free.fr 29 Mar '11

29 Mar '11

Hi all, Can someone help me about this problem ? We use Samba in our project and it needs some auxiliary classes which disappear in this configuration. The design of my project depends on the correction of this bug. Thanks a lot Best Regards Ali Pouya

1 0

Re: (ITS#6878) ppcache segfault with tavl_delete
by tjgates＠castlebranch.com 27 Mar '11

27 Mar '11

I've installed version 2.4.24 and been running it for a few days now. I'll report back in a few days on it's outcome. On Mar 24, 2011, at 1:34 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, March 24, 2011 4:28 PM +0000 tjgates(a)castlebranch.com wrote: > >> Full_Name: Tyler Gates >> Version: 2.4.21 >> OS: Ubuntu 10.04.2 LTS/CentOS 5.4 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (24.106.216.17) >> >> >> I have a caching proxy server (2.4.21) in front of two multi-masters. >> After about 1 to 3 days it will segfault only when caching is enabled. >> Log files are normally pretty useless but are normally in the operation >> of removing stale queries: > > Bug reports with 2.4.21 are not being pursued. Please use a current release (2.4.24) and verify whether or not the issue still exists 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#6880 published: SECURITY: ldap_free_urllist segfault
by openldap-its＠OpenLDAP.org 27 Mar '11

27 Mar '11

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

1 0

(ITS#6881)
by rottex＠gmx.net 26 Mar '11

26 Mar '11

This is a multi-part message in MIME format. --------------090304070908010006050102 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit double post of ITS#6880 since openldap homepage had an error while submitting. please delete this one ! THX --------------090304070908010006050102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body bgcolor="#ffffff" text="#000000"> double post of ITS#6880 since openldap homepage had an error while submitting. please delete this one ! THX </body> </html> --------------090304070908010006050102--

1 0

Another fix for (ITS#6872)
by cmikk＠qwest.net 25 Mar '11

25 Mar '11

I have found another corner case which can cause this behavior. If syncprov_findcsn() cannot find an entry with CSN matching the cookie mincsn, it tries to search for an entry with CSN less than or equal to the mincsn. For this search, it sets the unchecked limit to 1. If the scope of the search is not the whole database, this can cause the search to fail. The entryCSN filter identifies one candidate, and if that candidate is out of scope the search will fail, causing a full refresh. Two potential fixes here would be: 1) Set the hard or soft limits to 1 instead of the unchecked limit. This search is used to determine if an expensive full refresh is necessary, so a more expensive check may be acceptable. 2) Search the overlaid database for the desired entryCSN instead of just the replicated subtree. This is what I've implemented locally. The patch (against 2.4.24): diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c index 349b580..a7147a2 100644 --- a/servers/slapd/overlays/syncprov.c +++ b/servers/slapd/overlays/syncprov.c @@ -679,6 +679,8 @@ again: fop.ors_limit = &fc_limits; memset( &fc_limits, 0, sizeof( fc_limits )); fc_limits.lms_s_unchecked = 1; + fop.o_req_dn = si->si_contextdn; + fop.o_req_ndn = si->si_contextdn; fop.ors_filterstr.bv_len = snprintf( buf, sizeof( buf ), "(entryCSN<=%s)", cf.f_av_value.bv_val ); } -- Chris Mikkelson | Problems are posed by fools like me; cmikk(a)qwest.net | But only Heuristics can search a tree.

1 0

Re: (ITS#6879) Typo in Makefile of slapo-lastbind
by quanah＠zimbra.com 25 Mar '11

25 Mar '11

--On Friday, March 25, 2011 7:37 PM +0000 michael(a)stroeder.com wrote: > Full_Name: Michael Str?der > Version: RE24 > OS: > URL: > Submission from: (NULL) (84.128.253.71) > > > There's a typo in the Makefile for slapo-lastbind found under contrib/ Fixed. --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#6879) Typo in Makefile of slapo-lastbind
by michael＠stroeder.com 25 Mar '11

25 Mar '11

Full_Name: Michael Ströder Version: RE24 OS: URL: Submission from: (NULL) (84.128.253.71) There's a typo in the Makefile for slapo-lastbind found under contrib/ Index: Makefile =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/contrib/slapd-modules/lastbind/Makefile,v retrieving revision 1.2.2.3 diff -u -r1.2.2.3 Makefile --- Makefile 24 Mar 2011 18:13:52 -0000 1.2.2.3 +++ Makefile 25 Mar 2011 17:40:25 -0000 @@ -31,4 +31,4 @@ install: lastbind.la mkdir -p $(prefix)/libexec/openldap - $(LIBTOOL) --mode=onstall cp lastbind.la $(prefix)/libexec/openldap + $(LIBTOOL) --mode=install cp lastbind.la $(prefix)/libexec/openldap

1 0

Re: (ITS#6878) ppcache segfault with tavl_delete
by quanah＠zimbra.com 24 Mar '11

24 Mar '11

--On Thursday, March 24, 2011 4:28 PM +0000 tjgates(a)castlebranch.com wrote: > Full_Name: Tyler Gates > Version: 2.4.21 > OS: Ubuntu 10.04.2 LTS/CentOS 5.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.106.216.17) > > > I have a caching proxy server (2.4.21) in front of two multi-masters. > After about 1 to 3 days it will segfault only when caching is enabled. > Log files are normally pretty useless but are normally in the operation > of removing stale queries: Bug reports with 2.4.21 are not being pursued. Please use a current release (2.4.24) and verify whether or not the issue still exists 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#6878) ppcache segfault with tavl_delete
by tjgates＠castlebranch.com 24 Mar '11

24 Mar '11

Full_Name: Tyler Gates Version: 2.4.21 OS: Ubuntu 10.04.2 LTS/CentOS 5.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.106.216.17) I have a caching proxy server (2.4.21) in front of two multi-masters. After about 1 to 3 days it will segfault only when caching is enabled. Log files are normally pretty useless but are normally in the operation of removing stale queries: Mar 24 09:55:36 directory-proxy2 slapd[5363]: REMOVING TEMP ATTR : TEMPLATE=ba2c2b64-ea65-102f-96bd-2f354737277c Mar 24 09:55:36 directory-proxy2 slapd[5363]: STALE QUERY REMOVED, SIZE=0 Mar 24 09:55:36 directory-proxy2 slapd[5363]: STORED QUERIES = 22 Mar 24 09:55:36 directory-proxy2 slapd[5363]: STALE QUERY REMOVED, CACHE =1 entries Mar 24 09:55:36 directory-proxy2 slapd[5363]: Lock CR index = 0xb8848c00 I've attached to the running process using gdb and got the following: ************************************************************************** Program received signal SIGPIPE, Broken pipe. Program received signal SIGPIPE, Broken pipe. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb61b4b70 (LWP 5365)] tavl_delete (root=0x0, data=0xb890bac0, fcmp=0xb6b64910 <pcache_query_cmp>) at /build/buildd/openldap-2.4.21/libraries/liblutil/tavl.c:200 200 /build/buildd/openldap-2.4.21/libraries/liblutil/tavl.c: No such file or directory. in /build/buildd/openldap-2.4.21/libraries/liblutil/tavl.c (gdb) Continuing. [Thread 0xb1effb70 (LWP 7113) exited] [Thread 0xb2d9cb70 (LWP 10996) exited] [Thread 0xb3a9fb70 (LWP 9738) exited] [Thread 0xb47a2b70 (LWP 8550) exited] [Thread 0xb65b5b70 (LWP 5364) exited] [Thread 0xb61b4b70 (LWP 5365) exited] [Thread 0xb5cb2b70 (LWP 5673) exited] Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. (gdb) bt No stack. ********************************************************************** As you can see I cannot get a back trace, but I still have the gdb shell running so I run any other commands if needed. I've run version 2.4.18 on a CentOS machine with the same setup and I get segfaults only when pcache is enabled although I've never run it under gdb.

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24 - Fixed
by frank.offermanns＠caseris.de 24 Mar '11

24 Mar '11

I can confirm that HEAD can be build with MSYS and Windows now. This ITS can be closed. Thanks a lot for your help. Best regards, Frank Offermanns

1 0

(ITS#6877) Bug in slapo-cloack Makefile(?)
by marco.pizzoli＠gmail.com 24 Mar '11

24 Mar '11

Full_Name: Marco Pizzoli Version: 2.4.24/HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.174.164.11) Hi, in trying to compile overlay slapo-cloack I needed to hack a little the associated Makefile. I needed to add the following line: BEFORE: ==================== CPPFLAGS+=-I../../../include_-I../../../servers/slapd_ CPPFLAGS+=-DSLAPD_OVER_CLOAK=SLAPD_MOD_DYNAMIC LIBS=-lldap_r_-llber_-lcrypto ===================== AFTER: ==================== CPPFLAGS+=-I../../../include -I../../../servers/slapd CPPFLAGS+=-DSLAPD_OVER_CLOAK=SLAPD_MOD_DYNAMIC LIBTOOL=../../../libtool LIBS=-lldap_r -llber -lcrypto ==================== Hope this helps. Marco Pizzoli

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24 - Build still broken
by hyc＠symas.com 24 Mar '11

24 Mar '11

frank.offermanns(a)caseris.de wrote: > Now I get the next compile error: Should be fixed now in HEAD. > > c:\mingw\bin\ar.exe: creating ../liboverlays.a > make[3]: Leaving directory `/openldap-2.4.24/servers/slapd/overlays' > ../../build/mkversion -v "2.X" -s -n Versionstr slapd> version.c > gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o > main.o > main.c > gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o > globals > .o globals.c > gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o > bconfig > .o bconfig.c > gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o > config. > o config.c > gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o > daemon. > o daemon.c > daemon.c: In function `slapd_daemon_init': > daemon.c:1644: error: incompatible types in assignment > daemon.c:1644: error: incompatible types in assignment > daemon.c: In function `slapd_daemon': > daemon.c:2904: error: incompatible types in assignment > daemon.c:2904: error: incompatible types in assignment > make[2]: *** [daemon.o] Error 1 > make[2]: Leaving directory `/openldap-2.4.24/servers/slapd' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `/openldap-2.4.24/servers' > make: *** [all-common] Error 1 > > Regards, > Frank Offermanns > > > -- -- 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#6870) Undefined reference to ber_* with 2.4.24 - Build still broken
by frank.offermanns＠caseris.de 24 Mar '11

24 Mar '11

Now I get the next compile error: c:\mingw\bin\ar.exe: creating ../liboverlays.a make[3]: Leaving directory `/openldap-2.4.24/servers/slapd/overlays' ../../build/mkversion -v "2.X" -s -n Versionstr slapd > version.c gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o main.o main.c gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o globals .o globals.c gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o bconfig .o bconfig.c gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o config. o config.c gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o daemon. o daemon.c daemon.c: In function `slapd_daemon_init': daemon.c:1644: error: incompatible types in assignment daemon.c:1644: error: incompatible types in assignment daemon.c: In function `slapd_daemon': daemon.c:2904: error: incompatible types in assignment daemon.c:2904: error: incompatible types in assignment make[2]: *** [daemon.o] Error 1 make[2]: Leaving directory `/openldap-2.4.24/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/openldap-2.4.24/servers' make: *** [all-common] Error 1 Regards, Frank Offermanns

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by hyc＠symas.com 23 Mar '11

23 Mar '11

richm(a)stanfordalumni.org wrote: > On 03/22/2011 08:31 AM, rhafer(a)suse.de wrote: >> Am Dienstag 22 M=E4rz 2011, 11:39:33 schrieb hyc(a)symas.com: >>> hyc(a)symas.com wrote: >>>> Ralf Haferkamp wrote: >>>>> I changed the state back to "Open" as the problem is not really >>>>> solved yet. I wonder if we should revert the original fix to >>>>> liblutil/Makefile.in for now to have at least a working built back >>>>> on non-Windows Platforms. >>>> =20 >>>> Revert is fine to get HEAD building cleanly for now. Seems like the >>>> best solution longterm is to move libldif into its own directory >>>> since the rest of liblutil doesn't depend on it. >>> =20 >>> And as yet another option, why not build it alongside libldap... >> Shouldn't we just integrate it with libldap? AFAICS libldif uses stuff=20 >> from libldap (ldap_pvt_hex_unescape) anyways and libldap (ldifutil.c)=20 >> needs libldif. Yeah, that makes the most sense. I've just moved it over for now, the code is untouched so the names are still ldif_* (as opposed to ldap_ldif_*). I don't see any good reason to change the names. >> I am bit confused about how this was supposed to work orginally (libldif=20 >> as a standalone library). > I don't know if openldap ever had a truly standalone libldif. It's fine > with me if the ldif functionality is provided by libldap. Sounds good. HEAD now builds cleanly. -- -- 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#6875) openldap distribution list
by perfectwant＠hotmail.com 23 Mar '11

23 Mar '11

--_cbeddd50-e8ab-4067-9263-41b148d632ab_ Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 8bit Dear Support, The p[em;da[-technical list seems to list all related e-mail and forward to my e-mail. Is that true? BR Jonathan > Date: Mon, 21 Mar 2011 10:00:26 +0000 > From: openldap-its(a)OpenLDAP.org > To: perfectwant(a)hotmail.com > Subject: Re: (ITS#6875) openldap distribution list > CC: openldap-its(a)OpenLDAP.org > > The OpenLDAP-ITS address is for reporting bugs in OpenLDAP software. > Nothing in your report is indicative of a bug in OpenLDAP. > If you have questions about use of OpenLDAP Software which are > not answered in the documentation, FAQ, and archives, use the > OpenLDAP-technical list. This issue report will be closed. --_cbeddd50-e8ab-4067-9263-41b148d632ab_ Content-Type: text/html; charset="big5" Content-Transfer-Encoding: 8bit <html> <head> <style></style> </head> <body class='hmmessage'>  Dear Support,   The p[em;da[-technical list seems to list all related e-mail and forward to my e-mail. Is that true?   BR Jonathan > Date: Mon, 21 Mar 2011 10:00:26 +0000 > From: openldap-its(a)OpenLDAP.org > To: perfectwant(a)hotmail.com > Subject: Re: (ITS#6875) openldap distribution list > CC: openldap-its(a)OpenLDAP.org > > The OpenLDAP-ITS address is for reporting bugs in OpenLDAP software. > Nothing in your report is indicative of a bug in OpenLDAP. > If you have questions about use of OpenLDAP Software which are > not answered in the documentation, FAQ, and archives, use the > OpenLDAP-technical list. This issue report will be closed. </body> </html> --_cbeddd50-e8ab-4067-9263-41b148d632ab_--

1 0

Re: (ITS#5628) dereferencing user with translucent overlay
by akreffett＠cert.org 23 Mar '11

23 Mar '11

I ran in to this issue when attempting to enforce group ACLs on a translucent proxy where all group information is stored on the proxied directory. I implemented a hack in 2.3.43 (RHEL-5, we're a bit behind the times) to implement bi_entry_get_rw on slapo-translucent and rewire calls within the overlay from be_entry_get_rw to overlay_entry_get_ov. To prevent internal calls to be_entry_get_rw from invoking the new function (and potentially resulting in infinite recursion) I reworked the calls to overlay_entry_get_ov to use on->on_next instead of the top of the overlay stack. I believe that this was the original intent of these uses anyway to obtain the local-backend information so the call should start at the next overlay, or directly to the underlying database if there are no other overlays on the stack. I also applied a small patch to backover.c to support passing NULL to the on parameter of overlay_entry_get_ov and its release function to signify that the bottom of the overlay stack has been reached and to just call the backend database. When merging remote and local records the local records were duped and released immediately and the dupes appended to the returned entry and the caller left responsible to call entry_free. I have not thoroughly tested this code and I will need to rewrite it for 2.4 anyway (when we move to it, hopefully later this year) but wanted to check if there has been any progress on this issue that would obviate my need to port this to 2.4. If not, aside from what I described above am I missing any glaring issues that I would need to address to get a complete solution to this issue? Thanks, Aaron Reffett

1 0

(ITS#6876) Ldaps fault tolerance not working
by koshikov＠gmail.com 23 Mar '11

23 Mar '11

Full_Name: Nikita Koshikov Version: 2.4.24 OS: gentoo-linux kernel 2.6.26 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.82.218.210) Using openldap libraries for connection to Microsoft AD server with different software(dovecot\squid) fault tolerance not working with ldaps protocol. Example: uris = ldaps://host1 ldaps://host2 When host1 is completly down - ldapsearch successfully connects to host2 and get data, but when host1 is up, but rejecting connection on port - library not trying host2 - it just return error - connection reject. This have been tested with openldap version 2.4.24 and 2.3.43(centos 5) - both works the same. This behavior observed with ldapsearch, dovecot-imap server, squid server.

1 0

Fix for (ITS#6872)
by cmikk＠qwest.net 22 Mar '11

22 Mar '11

I have uploaded a patch to the ftp incoming directory as: chris-mikkelson-20110322.patch The issue was that, when called from syncprov_op_search, syncprov_findcsn uses the minimum CSN from the consumer cookie rather than the mincsn value calculated by syncprov_op_search. The patch passes syncprov_findcsn() the mincsn value calculated in syncprov_op_search(). This appears to fix the issue in my tests. Thanks, -- Chris Mikkelson | Disclaimer: the plural of "anecdote" is not "data." cmikk(a)qwest.net | -- spencer(a)engin.umich.edu

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by richm＠stanfordalumni.org 22 Mar '11

22 Mar '11

On 03/22/2011 08:31 AM, rhafer(a)suse.de wrote: > Am Dienstag 22 M=E4rz 2011, 11:39:33 schrieb hyc(a)symas.com: >> hyc(a)symas.com wrote: >>> Ralf Haferkamp wrote: >>>> I changed the state back to "Open" as the problem is not really >>>> solved yet. I wonder if we should revert the original fix to >>>> liblutil/Makefile.in for now to have at least a working built back >>>> on non-Windows Platforms. >>> =20 >>> Revert is fine to get HEAD building cleanly for now. Seems like the >>> best solution longterm is to move libldif into its own directory >>> since the rest of liblutil doesn't depend on it. >> =20 >> And as yet another option, why not build it alongside libldap... > Shouldn't we just integrate it with libldap? AFAICS libldif uses stuff=20 > from libldap (ldap_pvt_hex_unescape) anyways and libldap (ldifutil.c)=20 > needs libldif. > > I am bit confused about how this was supposed to work orginally (libldif=20 > as a standalone library). I don't know if openldap ever had a truly standalone libldif. It's fine with me if the ldif functionality is provided by libldap. > Ralf > >

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by rhafer＠suse.de 22 Mar '11

22 Mar '11

Am Dienstag 22 M=E4rz 2011, 11:39:33 schrieb hyc(a)symas.com: > hyc(a)symas.com wrote: > > Ralf Haferkamp wrote: > >> I changed the state back to "Open" as the problem is not really > >> solved yet. I wonder if we should revert the original fix to > >> liblutil/Makefile.in for now to have at least a working built back > >> on non-Windows Platforms. > >=20 > > Revert is fine to get HEAD building cleanly for now. Seems like the > > best solution longterm is to move libldif into its own directory > > since the rest of liblutil doesn't depend on it. >=20 > And as yet another option, why not build it alongside libldap... Shouldn't we just integrate it with libldap? AFAICS libldif uses stuff=20 from libldap (ldap_pvt_hex_unescape) anyways and libldap (ldifutil.c)=20 needs libldif. I am bit confused about how this was supposed to work orginally (libldif=20 as a standalone library). Ralf

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by hyc＠symas.com 22 Mar '11

22 Mar '11

hyc(a)symas.com wrote: > Ralf Haferkamp wrote: >> I changed the state back to "Open" as the problem is not really solved yet. I >> wonder if we should revert the original fix to liblutil/Makefile.in for now to >> have at least a working built back on non-Windows Platforms. > > Revert is fine to get HEAD building cleanly for now. Seems like the best > solution longterm is to move libldif into its own directory since the rest of > liblutil doesn't depend on it. And as yet another option, why not build it alongside libldap... -- -- 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#6870) Undefined reference to ber_* with 2.4.24
by hyc＠symas.com 22 Mar '11

22 Mar '11

Ralf Haferkamp wrote: > I changed the state back to "Open" as the problem is not really solved yet. I > wonder if we should revert the original fix to liblutil/Makefile.in for now to > have at least a working built back on non-Windows Platforms. Revert is fine to get HEAD building cleanly for now. Seems like the best solution longterm is to move libldif into its own directory since the rest of liblutil doesn't depend on it. -- -- 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#6870) Undefined reference to ber_* with 2.4.24
by Ralf Haferkamp 22 Mar '11

22 Mar '11

I changed the state back to "Open" as the problem is not really solved yet. I wonder if we should revert the original fix to liblutil/Makefile.in for now to have at least a working built back on non-Windows Platforms. Ralf

1 0

Re: (ITS#6874) slapd crashes while modifying a database
by rhafer＠suse.de 21 Mar '11

21 Mar '11

Am Samstag 19 M=E4rz 2011, 14:37:46 schrieb dieter(a)dkluenter.de: > While modifying a database, either subordinate or not, slapd crashes. > Debugging and configuration information can be found here: > http://pastebin.de/16349 (debugging) > http://pastebin.de/16350 (slapd.conf) I wonder if such a configuration is even supposed to work. The accesslog=20 overlay on the master is configured for the glued database=20 (dc=3Ddkluenter,dc=3Dde). On the slave however you have individual syncrepl= =20 configuration for each subordinate database. Wouldn't it be correct to=20 have separate accesslog databases for the subordinates? Additionally I think that at least the "overlay syncprov" for the=20 subordinate databases on the master is wrong (as syncprov is already=20 configured for the glued database). Not sure if it is harmful though. A more selfcontained and stripped down example configuration with actual=20 data and information on which operation exactly fails could also help=20 debugging this (assuming that your config turns out to be valid). Ralf

1 0

Re: (ITS#6875) openldap distribution list
by Ralf Haferkamp 21 Mar '11

21 Mar '11

The OpenLDAP-ITS address is for reporting bugs in OpenLDAP software. Nothing in your report is indicative of a bug in OpenLDAP. If you have questions about use of OpenLDAP Software which are not answered in the documentation, FAQ, and archives, use the OpenLDAP-technical list. This issue report will be closed.

1 0

(ITS#6810) closing issue...
by bruno.haleblian＠gmail.com 21 Mar '11

21 Mar '11

Valgrind only crashes and complains about running out of memory. Current issue has been solved anyway. Explananation : A partner site had connected a replica thru a load balanced Virtual IP adress. Correcting this misconfiguration obviously stopped crashing. I'm now facing a memory leak with 2.4.24 for which I'll open a new Issue if necessary. Thanks for your support. B.

1 0

Re: (ITS#6534) bad ifdef/elif clause in liblutil
by hyc＠symas.com 20 Mar '11

20 Mar '11

mm(a)FreeBSD.org wrote: > This problem is a generic problem of gcc version 4.4 and later. You're replying to a closed ITS. Not much point to that. > The new behaviour documented by GCC: > http://gcc.gnu.org/gcc-4.4/porting_to.html > > I recommend importing the patch from > http://www.openldap.org/its/index.cgi/Build?id=6832 The patch from ITS#6832 is already in CVS. That's what the "fixed in HEAD" status means. There's really nothing left to say or do here. > More information: > http://www.cyrius.com/journal/gcc/gcc-4.4-preprocessor-errors > http://gcc.gnu.org/viewcvs?view=revision&revision=136209 -- -- 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#6875) openldap distribution list
by perfectwant＠hotmail.com 20 Mar '11

20 Mar '11

Full_Name: Jonathan Y Version: 3 OS: Ubuntu 10.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (219.76.238.78) Dear all, I would like to make a distribution list in openldap, also tried to use the FAQ posted method (proxyaddress) but it doesn't work. Any detail step by step documentation available about making distribution list? Thanks all. BR Jonathan

1 0

Re: (ITS#6832) fix #elif statement
by mm＠FreeBSD.org 20 Mar '11

20 Mar '11

To provide some background information, this problem is caused by a behaviour change of gcc version 4.4 and later. The new behaviour documented by GCC: http://gcc.gnu.org/gcc-4.4/porting_to.html More information: http://www.cyrius.com/journal/gcc/gcc-4.4-preprocessor-errors http://gcc.gnu.org/viewcvs?view=revision&revision=136209

1 0

Re: (ITS#6534) bad ifdef/elif clause in liblutil
by mm＠FreeBSD.org 20 Mar '11

20 Mar '11

This problem is a generic problem of gcc version 4.4 and later. The new behaviour documented by GCC: http://gcc.gnu.org/gcc-4.4/porting_to.html I recommend importing the patch from http://www.openldap.org/its/index.cgi/Build?id=6832 More information: http://www.cyrius.com/journal/gcc/gcc-4.4-preprocessor-errors http://gcc.gnu.org/viewcvs?view=revision&revision=136209

1 0

(ITS#6874) slapd crashes while modifying a database
by dieter＠dkluenter.de 19 Mar '11

19 Mar '11

Full_Name: Dieter Kluenter Version: 2.4.24 OS: SLES11_x64 URL: Submission from: (NULL) (88.71.14.24) While modifying a database, either subordinate or not, slapd crashes. Debugging and configuration information can be found here: http://pastebin.de/16349 (debugging) http://pastebin.de/16350 (slapd.conf) linked libraries are /usr/lib/openldap> ldd slapd linux-vdso.so.1 => (0x00007fff8e9e1000) libldap_r-2.4.so.2 => /usr/lib64/libldap_r-2.4.so.2 (0x00007f633361e000) liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f633340f000) libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x00007f6333205000) libdb-4.5.so => /usr/lib64/libdb-4.5.so (0x00007f6332ece000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6332cb1000) libslp.so.1 => /usr/lib64/libslp.so.1 (0x00007f6332a97000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007f633287c000) libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007f63324cd000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f6332292000) libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f6332087000) libc.so.6 => /lib64/libc.so.6 (0x00007f6331d27000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f6331b10000) libssl.so.1.0.0 => /lib64/libssl.so.1.0.0 (0x00007f63318b4000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f63316b0000) /lib64/ld-linux-x86-64.so.2 (0x00007f633386f000) libz.so.1 => /lib64/libz.so.1 (0x00007f633149a000) -Dieter

1 0

(ITS#6873) Feature request slapo-lastbind: authTimestamp and relax rules control
by michael＠stroeder.com 19 Mar '11

19 Mar '11

Full_Name: Michael Ströder Version: RE24 OS: URL: Submission from: (NULL) (84.163.41.116) Attribute authTimestamp should be writeable by a client if relax rules control is sent along with the add/modify request (similar to modifyTimestamp).

1 0

(ITS#6872) syncprov performs unnecessary refreshes when replicating a subtree.
by cmikk＠qwest.net 18 Mar '11

18 Mar '11

Full_Name: Chris Mikkelson Version: 2.4.24 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.147.85.37) I have a multi-master LDAP master, with slaves replicating different subtrees of the directory. If a slave disconnects, a change is made on the master, and the slave reconnects, the master sends the complete subtree rather than the changed entries or a NEW_COOKIE message. Slaves which replicate the complete directory work fine -- only the changed entries are sent. The following script recreates this: http://mikk.net/~chris/syncprov-bug/syncprov-bug-demo (This script assumes that schemas are in /usr/local/etc/openldap/schema and the slapd binary is in /usr/local/libexec. Both are default for the FreeBSD port of OpenLDAP, but may need to be modified for other environments.) The script output is here: http://mikk.net/~chris/syncprov-bug/syncprov-bug-demo.out Note that the first ldapsearch with base dc=qwest,dc=net receives just the changed entry, but the second search with the same cookie and base ou=accounts,dc=qwest,dc=net receives the complete ou=accounts subtree.

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24 - next undefined reference
by rhafer＠suse.de 18 Mar '11

18 Mar '11

Am Freitag 18 M=E4rz 2011, 15:45:59 schrieb frank.offermanns(a)caseris.de: > Thanks for your help. > Now I have the next error: >=20 > Creating library file: .libs/libldif.dll.a > .libs/fetch.o: In function `ldif_open_url': > C:/msys/1.0/openldap-2.4.24/libraries/liblutil/fetch.c:67: undefined > reference to `ldap_pvt_hex_unescape' > collect2: ld returned 1 exit status > make[2]: *** [libldif.la] Error 1 > make[2]: Leaving directory `/openldap-2.4.24/libraries/liblutil' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `/openldap-2.4.24/libraries' > make: *** [all-common] Error 1 Hm, bad. Additionally it seems my last commit was wrong as well. It seems liblber=20 has a dependency on liblutil at least in some cases. I'll revert it again=20 for now. Ralf

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24 - next undefined reference
by frank.offermanns＠caseris.de 18 Mar '11

18 Mar '11

Thanks for your help. Now I have the next error: Creating library file: .libs/libldif.dll.a .libs/fetch.o: In function `ldif_open_url': C:/msys/1.0/openldap-2.4.24/libraries/liblutil/fetch.c:67: undefined reference to `ldap_pvt_hex_unescape' collect2: ld returned 1 exit status make[2]: *** [libldif.la] Error 1 make[2]: Leaving directory `/openldap-2.4.24/libraries/liblutil' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/openldap-2.4.24/libraries' make: *** [all-common] Error 1 Best regards, Frank Offermanns

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by rhafer＠suse.de 18 Mar '11

18 Mar '11

Am Freitag 18 M=E4rz 2011, 08:49:08 schrieb frank.offermanns(a)caseris.de: > Now I get the following error: > make[2]: *** No rule to make target > `../../libraries/liblber/liblber.la', needed > by `liblutil.a'. Stop. > make[2]: Leaving directory `/openldap-2.4.24/libraries/liblutil' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `/openldap-2.4.24/libraries' > make: *** [all-common] Error 1 Yes, I just stumbled across the same problem. Reodering the directories=20 in libraries/Makefile.in to build liblber before liblutil and removing=20 the liblutil dependency from the test binaries in liblber (which isn't=20 needed anyways AFAICS) fixes the problem for me. =46ix commited to HEAD. Ralf

1 0

(ITS#6871) Feature Request: slapo-lastbind authTimeStamp attribute replicated in MMR deploy
by marco.pizzoli＠gmail.com 18 Mar '11

18 Mar '11

Full_Name: Marco Pizzoli Version: 2.4.24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.174.164.11) This is a feature request. I would like to obtain authTimestamp attribute (as created by contrib/slapo-lastbind) being replicated by MultiMaster Replication. Actually, to obtain this information I need to query each server and take the more recent entry found. Thanks Marco Pizzoli

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by frank.offermanns＠caseris.de 18 Mar '11

18 Mar '11

Now I get the following error: make[2]: *** No rule to make target `../../libraries/liblber/liblber.la', needed by `liblutil.a'. Stop. make[2]: Leaving directory `/openldap-2.4.24/libraries/liblutil' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/openldap-2.4.24/libraries' make: *** [all-common] Error 1

1 0

Re: (ITS#6867) Password replication does not work properly in LDAP using openldap 2.4.23
by hyc＠symas.com 17 Mar '11

17 Mar '11

djadeja(a)avaya.com wrote: > Full_Name: Divyaraj Jadeja > Version: 2.4.23 > OS: RHEL 5.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.152.14.67) > > > Issue : Password replication does not work properly in LDAP using openLDAP > 2.4.23. Bug reports in 2.4.23 are no longer being investigated. 2.4.24 is the current release. This report is lacking critical details, particularly the actual configurations used on each server, including ACLs, relevant password policies, exact LDAP commands issued in each step, etc. > > Scenario1a: > Steps to Reproduce: > 1. Installed my custom software on 2 machines with HA LDAP configured. > 2. Verify that the connectivity between both the machines is working fine. > 3. Stopped slapd on Machine2. > 4. Created a new user test1 of a particular group on the Machine1. > 5. Started slapd on Machine2. > 6. Verified that test1 user created in step 4 is present in the LDAP DB on > Machine2. > 7. Login user test1 on the Machine2. The password of user test1 expires, login > of the user is successful after changing the password. > 8. Login the same user test1 on Machine1. > > Actual Result : > The changed password is not accepted on Machine1. > If the original password of user test1 is entered then the password is accepted > and the password expires again. > > Scenario 1b (minor modification in steps): > Created a new user. Ensure slapd on both Machine1& Machine2 is up& running. > Login this user on Machine2, password of this user expires, change the password. > Run ldapsearch command on both the machines. Password is changed on the > secondary dialer but the same is not replicated on the primary dialer. > > Expected Result : User's password must get replicated across all the Machines. > > Scenario 2 in which LDAP replication does not work. > > Steps to Reproduce: > 1. Set up 2 machines with HA-LDAP configured. > 2. Ensure that there is proper connectivity between both the machines. > 3. Stop slapd on machine1. > 4. Create a new user test2. > 5. Start slapd on machine1. > 6. Verify that the user is replicated on machine1. > 7. Cange the password, group& description and save. > > Actual Result : Changes are present on Machine1 but do not get replicated to > Machine2 even though slapd is up on both the machines. > > Additional Observations: > 1. This was observed intermittently. The default log is not leading anywhere, > will try setting advanced log& then replicating the issue. > 2. The pwd not replicating replicates after some time arnd 10 mins approx, will > find the time again. -- -- 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#6870) Undefined reference to ber_* with 2.4.24
by hyc＠symas.com 17 Mar '11

17 Mar '11

Frank.Offermanns(a)caseris.de wrote: > Full_Name: Frank Offermanns > Version: 2.4.24 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.6.189.243) > > > I am able to compile OpenLDAP 2.4.23 with Berkeley DB 4.8.30 with MSYS and > windows with configure params: > configure --prefix=/mingw --enable-acceslog --with-tls > > But if I try to compile OpenLDAP 2.4.24 I get several undefined references to > ber_* functions when liblutil is build. > > According to Howard Chu it seems to be a bug in the Makefile introduced with the > new libldif. > > Thanks for your help, > Frank Offermanns > Now fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6870) Undefined reference to ber_* with 2.4.24
by Frank.Offermanns＠caseris.de 17 Mar '11

17 Mar '11

Full_Name: Frank Offermanns Version: 2.4.24 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.6.189.243) I am able to compile OpenLDAP 2.4.23 with Berkeley DB 4.8.30 with MSYS and windows with configure params: configure --prefix=/mingw --enable-acceslog --with-tls But if I try to compile OpenLDAP 2.4.24 I get several undefined references to ber_* functions when liblutil is build. According to Howard Chu it seems to be a bug in the Makefile introduced with the new libldif. Thanks for your help, Frank Offermanns

1 0

Re: (ITS#6869) slapd segfaults during search traffic spike
by Howard Chu 16 Mar '11

16 Mar '11

This bug report is nonsense. The stack trace you attached does not come from slapd at all.

1 0

(ITS#6869) slapd segfaults during search traffic spike
by smkoch＠ornl.gov 16 Mar '11

16 Mar '11

Full_Name: Scott Koch Version: 2.4.23 OS: Centos 5.5 URL: Submission from: (NULL) (160.91.194.16) Problem Description: slapd segfaults during spike of ldap lookups. There are no error messages in the logs. See the gdb output below. Server Information: There are three identical read only(searches only) replicas(using syncrepl) that all demonstrate this problem that sit behind an IPVS load balancer. The servers run on Centos 5.5 x86_64 Vmware ESX4.0 virtual machines with 2GB of ram. The directory being served has just over 10,000 entries using the hdb database backend. openldap: @(#) $OpenLDAP: slapd 2.4.23 (Sep 24 2010 08:31:21) $ bdb: Berkeley DB 4.8.30: (April 9, 2010) gdb bt: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x40b5c940 (LWP 21140)] 0x00002b9c35b6b6b8 in pSD_WalkWorkQueue (Context=0x40b5c070, pWorkQueueVoid=0x0, HashKey=0, pfnbMatchEntry=0x2b9c35b58479 <bMgtCallback>, pSearchEntry=0x0) at work_queue.c:803 803 work_queue.c: No such file or directory. in work_queue.c (gdb) bt #0 0x00002b9c35b6b6b8 in pSD_WalkWorkQueue (Context=0x40b5c070, pWorkQueueVoid=0x0, HashKey=0, pfnbMatchEntry=0x2b9c35b58479 <bMgtCallback>, pSearchEntry=0x0) at work_queue.c:803 #1 0x00002b9c35b58435 in MgtSendThread (param=0x0) at acmgt.c:169 #2 0x00000033c560673d in start_thread () from /lib64/libpthread.so.0 #3 0x00000033c4ed3d1d in clone () from /lib64/libc.so.6 Let me know if there is more information and/or configuration files that I can provide to assist in tracking this down. Thanks, -Scott

1 0

(ITS#6868) When used in conjunction with the translucent overlay, the rwm overlay filters out auxiliary objectclasses
by ali.pouya＠free.fr 16 Mar '11

16 Mar '11

Full_Name: Ali POUYA Version: 2.4.24 OS: Redhat EL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.3) When used in conjunction with the translucent overlay, the rwm overlay filters out auxiliary objectclasses To produce the problem in the test environment you can proceed as follows : # Go to the tests directory : cd openldap-2.4.24/tests # Save the files which will be modified : cp data/test-translucent-add.ldif data/test-translucent-add.ldif.orig cp data/slapd-translucent-local.conf data/slapd-translucent-local.conf.orig # Add an auxiliary objectClass to the local directory LDIF file : cat >> data/test-translucent-add.ldif << ! > objectClass: extensibleObject > ! # Run the translucent test : ./run test034-translucent # The test does not succed, which is normal because we added an auxiliary objectClass. # Now simply add "overlay rwm" in the local config : sed -i 's/^database config/\noverlay rwm\n\ndatabase config/' data/slapd-translucent-local.conf # The test succeeds ! meaning that the auxiliary objectClass was filtered out by the rwm (was hided). I confirm that rwm works fine for the auxiliary objectClasses when used without the translucent overlay. Thanks for your help Best Regards Ali Pouya

1 0

(ITS#6867) Password replication does not work properly in LDAP using openldap 2.4.23
by djadeja＠avaya.com 16 Mar '11

16 Mar '11

Full_Name: Divyaraj Jadeja Version: 2.4.23 OS: RHEL 5.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.152.14.67) Issue : Password replication does not work properly in LDAP using openLDAP 2.4.23. Scenario1a: Steps to Reproduce: 1. Installed my custom software on 2 machines with HA LDAP configured. 2. Verify that the connectivity between both the machines is working fine. 3. Stopped slapd on Machine2. 4. Created a new user test1 of a particular group on the Machine1. 5. Started slapd on Machine2. 6. Verified that test1 user created in step 4 is present in the LDAP DB on Machine2. 7. Login user test1 on the Machine2. The password of user test1 expires, login of the user is successful after changing the password. 8. Login the same user test1 on Machine1. Actual Result : The changed password is not accepted on Machine1. If the original password of user test1 is entered then the password is accepted and the password expires again. Scenario 1b (minor modification in steps): Created a new user. Ensure slapd on both Machine1 & Machine2 is up & running. Login this user on Machine2, password of this user expires, change the password. Run ldapsearch command on both the machines. Password is changed on the secondary dialer but the same is not replicated on the primary dialer. Expected Result : User's password must get replicated across all the Machines. Scenario 2 in which LDAP replication does not work. Steps to Reproduce: 1. Set up 2 machines with HA-LDAP configured. 2. Ensure that there is proper connectivity between both the machines. 3. Stop slapd on machine1. 4. Create a new user test2. 5. Start slapd on machine1. 6. Verify that the user is replicated on machine1. 7. Cange the password, group & description and save. Actual Result : Changes are present on Machine1 but do not get replicated to Machine2 even though slapd is up on both the machines. Additional Observations: 1. This was observed intermittently. The default log is not leading anywhere, will try setting advanced log & then replicating the issue. 2. The pwd not replicating replicates after some time arnd 10 mins approx, will find the time again.

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by hyc＠symas.com 16 Mar '11

16 Mar '11

This is a multi-part message in MIME format. --------------070307090101090304000508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Quanah Gibson-Mount wrote: > > > --On March 9, 2011 9:42:18 AM -0800 Howard Chu<hyc(a)symas.com> wrote: > >> Quanah Gibson-Mount wrote: >>> >>> >>> --On March 4, 2011 11:14:46 PM +0000 dhawes(a)vt.edu wrote: >>>> Tested, and working. Thanks for the fix. >>> >>> We're still seeing this happen sporadically with slapindex -q<attribute> >>> >>> i.e., reindexing a single attribute instead of the entire DB >> >> Can't reproduce it here, need a test case. > > It's hard to come up with one. We've only had this one instance on one > machine. I reproduced your hang by adding a sleep(1) in front of the trickle task. This patch fixes it. I can't commit at the moment because cvs-master.openldap.org is not answering. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------070307090101090304000508 Content-Type: text/plain; name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dif.txt" Index: tools.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/tools.c,v retrieving revision 1.141 diff -u -r1.141 tools.c --- tools.c 11 Mar 2011 21:16:13 -0000 1.141 +++ tools.c 16 Mar 2011 06:35:09 -0000 @@ -1,5 +1,5 @@ /* tools.c - tools for slap tools */ -/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/tools.c,v 1.141 2011-03-11 21:16:13 hyc Exp $ */ +/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/tools.c,v 1.141 2011/03/11 21:16:13 hyc Exp $ */ /* This work is part of OpenLDAP Software <http://www.openldap.org/>. * * Copyright 2000-2011 The OpenLDAP Foundation. @@ -162,6 +162,12 @@ slapd_shutdown = 1; #ifdef USE_TRICKLE ldap_pvt_thread_mutex_lock( &bdb_tool_trickle_mutex ); + + /* trickle thread may not have started yet */ + while ( !bdb_tool_trickle_active ) + ldap_pvt_thread_cond_wait( &bdb_tool_trickle_cond_end, + &bdb_tool_trickle_mutex ); + ldap_pvt_thread_cond_signal( &bdb_tool_trickle_cond ); while ( bdb_tool_trickle_active ) ldap_pvt_thread_cond_wait( &bdb_tool_trickle_cond_end, @@ -1256,6 +1262,7 @@ ldap_pvt_thread_mutex_lock( &bdb_tool_trickle_mutex ); bdb_tool_trickle_active = 1; + ldap_pvt_thread_cond_signal( &bdb_tool_trickle_cond_end ); while ( 1 ) { ldap_pvt_thread_cond_wait( &bdb_tool_trickle_cond, &bdb_tool_trickle_mutex ); --------------070307090101090304000508--

1 0

Re: (ITS#6862) Patch - Mozilla NSS - redux: disable pkcs11 fork checking for the software token
by hyc＠symas.com 15 Mar '11

15 Mar '11

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.24 (current CVS HEAD) > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.24-use-strdup-for-nofork-envva… > Submission from: (NULL) (76.113.111.209) > > > There was still a problem with the fix for > http://www.openldap.org/its/index.cgi?findid=6811 > > Under certain conditions, and with certain shells, the PR_SetEnv with the > constant string was causing free() assertion failures in unrelated software. > > # su - foo > free(0x173bd2) below bottom of memory. (memtop = 0x9898800 membot = 0x973e000) > # gdb /bin/tcsh coredump > (gdb) bt > #0 0x00ed9416 in __kernel_vsyscall () > #1 0x006e02f1 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #2 0x006e1d5e in abort () at abort.c:92 > #3 0x08084e6a in free (cp=0x8f2bd2) at tc.alloc.c:313 > #4 0x08063d83 in blkfree (av0=0x9e7d988) at sh.misc.c:158 > #5 0x0805af6f in tsetenv (name=0x80a3420 L"GROUP", val=0x9e32608 > L"valid_group") at sh.func.c:1725 > #6 0x0804d910 in main (argc=<value optimized out>, argv=0xbfa7e4f4) at > sh.c:561 > > Using PR_SetEnv with a strdup()ed string solved the problem. At the expense of a small memory leak. Whatever happened to making PR_SetEnv() take care of this itself? http://osdir.com/ml/mozilla.devel.nspr/2005-02/msg00011.html I thought the point of NSPR was to provide a consistent cross-platform API. If PR_SetEnv() is documented to behave a particular way, and it doesn't, then this bug should be fixed in NSPR. If NSPR is unable to provide a consistent API... I'm getting the feeling that you're plugging an unmaintainable code base in here. -- -- 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#6866) Math Error in Discussion of Delta-Syncrepl
by jong.limb＠dss.virginia.gov 15 Mar '11

15 Mar '11

Full_Name: Jong K. Limb Version: 2.4.23 OS: Linux URL: Submission from: (NULL) (166.67.66.8) In the Replication chapter, section 18.2.1 discusses the drawbacks to LDAP Sync replication. It gives the following paragraph: For example, suppose you have a database consisting of 100,000 objects of 1 KB each. Further, suppose you routinely run a batch job to change the value of a single two-byte attribute value that appears in each of the 100,000 objects on the master. Not counting LDAP and TCP/IP protocol overhead, each time you run this job each consumer will transfer and process 1 GB of data to process 200KB of changes! The math is incorrect. If 100,000 objects are of 1000 bytes each, that results in 100,000,000 bytes which is 100MB, not 1GB. This gives a false impression of the drawbacks of LDAP Sync replication.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs