- openldap-bugs - openldap.org

[Issue 10037] New: Instructions for building argon2.so are inaccurate
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10037 Issue ID: 10037 Summary: Instructions for building argon2.so are inaccurate Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: sclassen(a)lbl.gov Target Milestone: --- The instructions for building the argon2.so shared library are inaccurate. According to: servers/slapd/pwmods/README.argon2 Building -------- 1) Customize the OPENLDAP variable in Makefile to point to the OpenLDAP source root. For initial testing you might also want to edit DEFS to define SLAPD_ARGON2_DEBUG, which enables logging to stderr (don't leave this on in production, as it prints passwords in cleartext). 2) Run 'make' to produce argon2.so 3) Copy argon2.so somewhere permanent. 4) Edit your slapd.conf (eg. /etc/ldap/slapd.conf), and add: moduleload ...path/to/argon2.so 5) Restart slapd. When I run make from within servers/slapd/pwmods/ I get the following error: [user@machine openldap-2.6.4]# cd servers/slapd/pwmods/ [user@machine pwmods]# make make: *** No rule to make target 'dummyvalue', needed by 'all-common'. Stop. I’m not sure what “dummyvalue” is supposed to be so I commented out line 288 in servers/slapd/pwmods/Makefile # LIBRARY = dummyvalue And get this error: [user@ machine pwmods]# make /bin/sh ../../../libtool --tag=disable-static --mode=compile cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -DSLAPD_IMPORT -c version.c libtool: compile: cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -DSLAPD_IMPORT -c version.c -fPIC -DPIC -o .libs/version.o version.c:1:6: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘:’ token usage: mkversion [-c] [-s] [-p package] [-v version] application ^ make: *** [Makefile:310: version.lo] Error 1 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10033] New: olcDbCacheSize in mdb configuration example
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10033 Issue ID: 10033 Summary: olcDbCacheSize in mdb configuration example Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: stefan(a)kania-online.de Target Milestone: --- on Page: https://openldap.org/doc/admin26/overlays.html#The%20Proxy%20Cache%20Engine There is an example for pcache-db configuration for a mdb-database: ----------- dn: olcDatabase={0}mdb,olcOverlay={0}pcache,olcDatabase={2}ldap,cn=config objectClass: olcMdbConfig objectClass: olcPcacheDatabase olcDatabase: {0}mdb olcDbDirectory: ./testrun/db.2.a olcDbCacheSize: 20 olcDbIndex: objectClass eq olcDbIndex: cn,sn,uid,mail pres,eq,sub ----------- But olcDbCacheSize is an bdb/hdb attribute. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9999] New: Potential memory leak in tests/progs/slapd-search.c
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=9999 Issue ID: 9999 Summary: Potential memory leak in tests/progs/slapd-search.c Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: 1061499390(a)qq.com Target Milestone: --- Version: Github:master Potential memory leak in slapd-search.c line 207.Calling ldap_search_ext_s() without calling ldap_msgfree() to free the memory will cause a memory leak. Doc says "Note that res parameter of ldap_search_ext_s() and ldap_search_s() should be freed with ldap_msgfree() regardless of return value of these functions." in https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0… -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10046] New: Wrong ObjectClass Name in example in manpage slapo-variant
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10046 Issue ID: 10046 Summary: Wrong ObjectClass Name in example in manpage slapo-variant Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: stefan(a)kania-online.de Target Milestone: --- Manpage is telling: ---------- # share the Headquarters' address as the company address dn: olcVariantVariantAttribute=postaladdress,name={0}example,olcOverlay={x}variant,$DATABASE objectClass: olcVariantVariantAttribute olcVariantVariantAttribute: postaladdress olcVariantAlternativeAttribute: postaladdress olcVariantAlternativeEntry: ou=Headquarters,dc=example,dc=com ---------- But the name of the ObjectClass is objectClass=olcVariantAttribute -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9996] New: Potential memory leak in libraries/librewrite/ldapmap.c
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=9996 Issue ID: 9996 Summary: Potential memory leak in libraries/librewrite/ldapmap.c Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 1061499390(a)qq.com Target Milestone: --- Version: Github:master Potential memory leak in ldapmap.c line 359.Calling ldap_search_ext_s() without calling ldap_msgfree() to free the memory will cause a memory leak. Doc says "Note that res parameter of ldap_search_ext_s() and ldap_search_s() should be freed with ldap_msgfree() regardless of return value of these functions." in https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0… -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10030] New: Add support for OpenSSL 3.0 to 2.5 stable release
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10030 Issue ID: 10030 Summary: Add support for OpenSSL 3.0 to 2.5 stable release Product: OpenLDAP Version: 2.5.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- As OpenSSL 1.1.1 is being sunset September 2023 we will need to add OpenSSL 3.0 support to the 2.5 series. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10041] New: unnecessary dynlist evaluation
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10041 Issue ID: 10041 Summary: unnecessary dynlist evaluation Product: OpenLDAP Version: 2.5.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Created attachment 963 --> https://bugs.openldap.org/attachment.cgi?id=963&action=edit openldap config + data for showing the dynlist usecase Evaluation of member of dynamic groups by dynlist can be slow. However, in some context, the evaluation is not necessary, especially when searching object that are not dynamic groups. You can find attached a configuration and data file showing the use case: - 10000 users - 100 static groups - 5000 dynamic groups, with a filter (&(uid=user*)(objectClass=person), grabbing all users Example of "normal" slow search ~ 115s: ldapsearch -x -H 'ldap://localhost:389/' -D 'uid=admin,ou=people,dc=my-organization,dc=com' -w 'secret' -b 'ou=groups,dc=my-organization,dc=com' '(member=uid=user1,ou=people,dc=my-organization,dc=com)' Example of abnormal slow search ~ 115s: ldapsearch -x -H 'ldap://localhost:389/' -D 'uid=admin,ou=people,dc=my-organization,dc=com' -w 'secret' -b 'ou=groups,dc=my-organization,dc=com' '(&(objectClass=groupOfNames)(member=uid=user1,ou=people,dc=my-organization,dc=com))' Here, the filter about the objectClass could be evaluated first to avoid unnecessary search in dynamic groups. Example of rapid search with DSA IT ~ 1ms: ldapsearch -x -H 'ldap://localhost:389/' -D 'uid=admin,ou=people,dc=my-organization,dc=com' -w 'secret' -b 'ou=groups,dc=my-organization,dc=com' '(&(objectClass=groupOfNames)(member=uid=user1,ou=people,dc=my-organization,dc=com))' -M -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10000] New: Potential memory leak in tests/progs/slapd-watcher.c
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10000 Issue ID: 10000 Summary: Potential memory leak in tests/progs/slapd-watcher.c Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: 1061499390(a)qq.com Target Milestone: --- Version: Github:master Potential memory leak in slapd-watcher.c line 517.Calling ldap_search_ext_s() without calling ldap_msgfree() to free the memory will cause a memory leak. Doc says "Note that res parameter of ldap_search_ext_s() and ldap_search_s() should be freed with ldap_msgfree() regardless of return value of these functions." in https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0… -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10023] New: Asynchronous connects are broken
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10023 Issue ID: 10023 Summary: Asynchronous connects are broken Product: OpenLDAP Version: 2.5.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ipuleston(a)sonicwall.com Target Milestone: --- We have a port of OpenLDAP client running in an embedded system, which is using asynchronous connects to the LDAP server. We have been using OpenLDAP 2.4.40 for a long time, and I just upgraded it to use 2.5.14 (as the current LTS release). After doing this, async connects to the LDAP server no longer work. You can see this in the following debug output: A successful async connect with 2.4.40: ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP Ian-DC1.sd80.com:389 ldap_pvt_gethostbyname_a: host=Ian-DC1.sd80.com, r=0 ldap_new_socket: 251 ldap_prepare_socket: 251 ldap_connect_to_host: Trying 192.168.168.3:389 ldap_pvt_connect: fd: 251 tm: 10 async: -1 ldap_ndelay_on: 251 attempting to connect: connect errno: 115 ldap_int_poll: fd: -1 tm: 0 A failed async connect with 2.5.14: ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP Ian-DC1.sd80.com:389 ldap_pvt_gethostbyname_a: host=Ian-DC1.sd80.com, r=0 ldap_new_socket: 247 ldap_prepare_socket: 247 ldap_connect_to_host: Trying 10.21.61.3:389 ldap_pvt_connect: fd: 247 tm: 10 async: -1 ldap_ndelay_on: 247 attempting to connect: connect errno: 115 ldap_open_defconn: successful ldap_send_server_request Sending Bind Request, len=0x6ca10c1f ldap_write: want=63 error=Resource temporarily unavailable Note that in both cases the connect attempt returns errno 115, EINPROGRESS, meaning that it has not completed. But after that: ● 2.4.40 calls ldap_int_poll (via ldap_send_initial_request -> ldap_int_check_async_open) to begin the wait for async completion. ● 2.5.14 instead reports a successful connect, and tries to send the bind which fails since thre socket is not yet connected. I tracked the problem down to a change made for ITS #8022 "an async connect may still succeed immediately" in this commit: https://git.openldap.org/openldap/openldap/-/commit/ae6347bac12bbf843678a83… That change in ldap_new_connection makes it set lconn_status for an async connect to LDAP_CONNST_CONNECTED rather than LDAP_CONNST_CONNECTING if ldap_int_open_connection returns 0. The problem is that ldap_int_open_connection returns 0 after getting the EINPROGRESS. ldap_connect_to_host returns -2 for the latter, but ldap_int_open_connection doesn't check for that, returning 0 for any return code other than -1. I think that the bug is actually in ldap_int_open_connection rather than in the above commit. It should probably return -2 when ldap_connect_to_host returns that. -- You are receiving this mail because: You are on the CC list for the issue.

1 18

[Issue 10011] New: Incompatibilities with stricter C99 compilers
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10011 Issue ID: 10011 Summary: Incompatibilities with stricter C99 compilers Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: sam(a)gentoo.org Target Milestone: --- Newer C compilers (>= Clang 16 and likely >= GCC 14) reject some constructs removed in C99 like implicit function declarations and implicit ints. Some compilers are also starting to reject obsolete K&R prototypes which were removed in C23. I've filed an MR at https://git.openldap.org/openldap/openldap/-/merge_requests/605 to address the issues in configure as well as a small number of issues in the codebase itself. For more information, see LWN.net [0] or LLVM's Discourse [1], the Gentoo wiki [2], or the (new) c-std-porting mailing list [3]. [0] https://lwn.net/Articles/913505/ [1] https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-… [2] https://wiki.gentoo.org/wiki/Modern_C_porting [3] hosted at lists.linux.dev. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10079] New: Facing syncrepl issue after selecting filter and attrs
by openldap-its＠openldap.org 06 Jul '23

06 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10079 Issue ID: 10079 Summary: Facing syncrepl issue after selecting filter and attrs Product: OpenLDAP Version: 2.4.49 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ramprasad.sharma(a)orange.com Target Milestone: --- I'm facing an issue, when I'm using replication without filter and attrs, it works fine but when I try it with filter and attrs , I get nentries=0 and replication dont happen.. what could be the possible issue, I tried many thing.. syncrepl rid=<%= @%> provider=ldaps://master.<%= @%>h:636/ bindmethod=simple binddn="cn=replication,dc=di-diod,dc=tech" credentials=<%= @%> searchbase="ou=people,dc=di-diod,dc=tech" filter="(objectClass=posixAccount)" attrs="cn,uid,x1sshPubKey,x2sshPubKey,uidNumber,gidNumber,homeDirectory,gecos,loginShell,description,sshPublicKey" scope=sub schemachecking=on type=refreshOnly interval=00:00:00:01 retry="30 5 300 3" I can use any help on call also.. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10078] New: segfault error 4 in in dynlist-2.5.so.0.1.8
by openldap-its＠openldap.org 05 Jul '23

05 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10078 Issue ID: 10078 Summary: segfault error 4 in in dynlist-2.5.so.0.1.8 Product: OpenLDAP Version: 2.5.13 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: gustav(a)spllg.de Target Milestone: --- whenever i execute an ldapsearch, slapd crashes and i find the following lines in /var/log/syslog segfault at 0 ip 00007f876bece9c1 sp 00007f876a1fc0c0 error 4 in dynlist-2.5.so.0.1.8[7f876becb000+6000] likely on CPU 0 (core 0, socket 0) Code: 48 29 d0 48 89 d7 48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24 10 02 00 00 4c 89 ef c7 84 24 a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39 73 64 74 09 45 84 e4 0f 85 22 03 00 00 48 Stopping OpenLDAP: slapd. slapd.service: Deactivated successfully. the database had been imported from ldap-2.4.57 where ldap runs fine. is there anything i can do to fix the problem? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10075] New: back-sql regression between 2.4.40 and 2.4.44
by openldap-its＠openldap.org 28 Jun '23

28 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=10075 Issue ID: 10075 Summary: back-sql regression between 2.4.40 and 2.4.44 Product: OpenLDAP Version: 2.4.44 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: daniel.walker(a)ncas.ac.uk Target Milestone: --- I have just upgraded from CentOS6 to CentOS7 ( I know, not my pick :). On OpenLdap back-sql 2.4.40 on CentOS6, this seems to be honoured: "Multiple attributeType definitions are allowed for an entry; that is, multiple ldap_attr_mappings rows can refer to the same ldap_oc_mappings row with the same name; the resulting attribute values are honored for multivalued attributes in search filters, in search results, in compare AVAs. However, only rules according to the first instance of that attributeType are followed in add, modify and delete operations. This limitation, under certain circumstances, may be removed in the future." (from https://www.openldap.org/faq/data/cache/978.html ) I was using this feature to get memberAddress attributes from two separate tables in my SQL (internal people and external people) Upon upgrading to 2.4.44 on CentOS7, the second entry is no longer honoured. Relevant entries: MariaDB [ncas_database]> SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=4 AND name='memberAddress'; +---------------+--------------------------------------+------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+-------------+-------------+---------------+------------+ | name | sel_expr | from_tbls | join_where | add_proc | delete_proc | param_order | expect_return | sel_expr_u | +---------------+--------------------------------------+------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+-------------+-------------+---------------+------------+ | memberAddress | CONCAT(emails.address,"@domain.name") | groups,people_groups AS ps,people,emails | groups.id=ps.group_id AND ps.person_id=people.id AND people.id=emails.person_id AND emails.main=1 AND (people.contract_end > NOW() OR people.contract_end IS NULL) | NULL | NULL | 3 | 0 | NULL | | memberAddress | email | groups,external_members | groups.id=external_members.group_id | NULL | NULL | 3 | 0 | NULL | +---------------+--------------------------------------+------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+-------------+-------------+---------------+------------+ 2 rows in set (0.000 sec) The second one is ignored; no requests to the external_members table show in the logs. Is this a known bug? I did look through the archives, but I wasn't able to find it. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10069] New: Error when installing openldap from brew on Macos Catalina
by openldap-its＠openldap.org 22 Jun '23

22 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=10069 Issue ID: 10069 Summary: Error when installing openldap from brew on Macos Catalina Product: OpenLDAP Version: 2.6.4 Hardware: x86_64 OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: marianogedisman(a)gmail.com Target Milestone: --- Hello! I'm getting this error when installing from Homebrew on MacOS Catalina: ==> ./configure --prefix=/usr/local/Cellar/openldap/2.6.4 --sysconfdir=/usr/loca n==> make install Error: inreplace failed /usr/local/etc/openldap/slapd.conf: expected replacement of #<Pathname:/usr/local/Cellar/openldap/2.6.4> with #<Pathname:/usr/local/opt/openldap> /usr/local/etc/openldap/slapd.ldif: expected replacement of #<Pathname:/usr/local/Cellar/openldap/2.6.4> with #<Pathname:/usr/local/opt/openldap> -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 4066] Uniqueness overlay incorrectly checks for dupes with MODs outside of its seach base
by openldap-its＠openldap.org 19 Jun '23

19 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=4066 --- Comment #6 from knotmecute <kmcbacklink(a)gmail.com> --- https://knotmecute.com/ https://knotmecute.com/handmade/banjaran-collection/ https://knotmecute.com/handmade/mehfil-collection/ -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 4066] Uniqueness overlay incorrectly checks for dupes with MODs outside of its seach base
by openldap-its＠openldap.org 19 Jun '23

19 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=4066 --- Comment #5 from knotmecute <kmcbacklink(a)gmail.com> --- Step into the vibrant world of Knotmecute's Banjaran collection, where exquisite bohemian jewelry takes center stage, inspired by tribal aesthetics and vibrant cultures. Our brand strives to revive the rich heritage art of tribes, incorporating abstract patterns and colorful mirror work into stunning pieces that make a bold and stylish statement. Crafted with meticulous precision and attention to detail, our luxury bohemian jewels are designed to complement a variety of occasions, from carefree beach travels to destination weddings. Each piece is thoughtfully created to evoke a sense of wanderlust and adventure, adding a touch of boho charm to your jewelry ensemble. The Banjara collection offers a wide range of accessories that cater to every woman's unique style and trending preferences. Whether you desire a statement necklace to elevate your evening attire or vibrant earrings to accentuate your beachy look, we have the perfect piece to fulfill your needs. Every jewelry piece in the Banjara collection is a work of art, meticulously handcrafted with vibrant colors, intricate mirror work, and captivating patterns. These colorful jewels go beyond being mere accessories—they carry a personalized touch, reflecting the essence of your vibrant spirit. Embrace the beauty of bohemian aesthetics with Knotmecute's Banjara brand. Discover our collection and adorn yourself with these stunning jewels that will turn heads wherever you go. Experience the joy of wearing luxurious, colorful bohemian jewelry that reflects your individuality and leaves a lasting impression. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10066] New: fsync -> fcntl(F_FULLFSYNC) on Apple platforms?
by openldap-its＠openldap.org 15 Jun '23

15 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=10066 Issue ID: 10066 Summary: fsync -> fcntl(F_FULLFSYNC) on Apple platforms? Product: LMDB Version: unspecified Hardware: All OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: christophersauer(a)pacbell.net Target Milestone: --- Hi, Howard, I was thinking of adopting LMDB for a cross-platform project, but when quickly browsing the code, didn't see specializations for Apple platform' weakened fsync -> fcntl(F_FULLFSYNC). (Doc quick link, if useful: https://developer.apple.com/library/archive/documentation/System/Conceptual…) Should I be concerned? I think it's very likely that you're way ahead of me, but I just wanted to check in. (And couldn't otherwise find anything online about this.) Thanks so much for all you do! Chris -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10054] New: Value size limited to 2,147,479,552 bytes
by openldap-its＠openldap.org 12 Jun '23

12 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=10054 Issue ID: 10054 Summary: Value size limited to 2,147,479,552 bytes Product: LMDB Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: louis(a)meilisearch.com Target Milestone: --- Hello, According to the documentation[0], a database that is not using `MDB_DUPSORT` can store values up to `0xffffffff` bytes (around 4GB). In practice, under Linux, the actual limit is `0x7ffff000` though (2^31 - 4096, so around 2GB). This is due to the write loop in `mdb_page_flush`. The `wsize` value determining how many bytes will be written can be as big as `4096*dp->mp_pages`[1], and the number of overflow pages grows with the size of the value put inside the DB. The `wsize` is not split in smaller chunks in the case where there are many overflow pages to write, and as a result the call to `pwrite`[2] does not perform a full write, but only a "short" write of 2147479552 bytes (the maximum allowed on a call to `pwrite` on Linux[3]). This would be OK if the short write condition was handled by looping and performing another `pwrite` with the rest of the data, but instead `EIO` is returned[4]. There seems to be a related, but different issue on macOS when trying to `pwrite` more the 2^31 bytes, that was already reported[5]. This issue was reported to me by a Meilisearch user because it causes their database indexing to fail[6]. I had to investigate a bit because their setup was peculiar (high number of documents in their database) and the `EIO` error code is not very descriptive of the underlying issue. I join a C reproducer of the issue that attempts to add a 2147479553 bytes value to the DB and fails with `EIO` (decreasing `nb_items` to a smaller value such as `2107479552` does succeed)[7]. Thank you for making LMDB! Louis Dureuil. [0]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/lmdb.h#LL284… [1]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#LL3770… [2]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#L3820 [3]: https://stackoverflow.com/questions/70368651/why-cant-linux-write-more-than… [4]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#L3840 [5]: https://bugs.openldap.org/show_bug.cgi?id=9736 [6]: https://github.com/meilisearch/meilisearch/issues/3654 [7]: https://github.com/dureuill/lmdb_3654/tree/main -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10062] New: How to store a data item of length greater than 511 in a dupsort db
by openldap-its＠openldap.org 12 Jun '23

12 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=10062 Issue ID: 10062 Summary: How to store a data item of length greater than 511 in a dupsort db Product: LMDB Version: 0.9.30 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: mega.alpha100(a)gmail.com Target Milestone: --- Is there a workaround to storing a data item with a length greater than the value of `fn mdb_env_get_maxkeysize()` or 511 in a dupsort db? Also, I tried to change the value of the `MDB_MAXKEYSIZE` macro but that led to an illegal instruction -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10050] New: Use of stack allocated string in mdb_strerror
by openldap-its＠openldap.org 12 Jun '23

12 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=10050 Issue ID: 10050 Summary: Use of stack allocated string in mdb_strerror Product: LMDB Version: unspecified Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: es(a)m-labs.hk Target Milestone: --- https://git.openldap.org/openldap/openldap/-/blob/mdb.master/libraries/libl… This piece of code exists from 2014, and these lines are not working outside of MSVC. Moreover, they lead to segfaults in MINGW compiled environments. Please see the patch we use for potential fix: https://github.com/msys2/MINGW-packages/blob/31012dd33a32390d1e5f9b93388799… -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10061] New: Query on setting TLSVerifyClient option set to demand
by openldap-its＠openldap.org 12 Jun '23

12 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=10061 Issue ID: 10061 Summary: Query on setting TLSVerifyClient option set to demand Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ramajay52(a)gmail.com Target Milestone: --- Dear Experts, In my case, I had set TLSVerifyClient to demand. I couldn't be able to establish a connection While providing TLSCACertificateFile alone. While setting the TLSVerifyClient option demand is it mandatory to provide the following option? 1. TLSCACertificateFile 2. TLSCertificateKeyFile 3. TLSCertificateFile Regards, Ram -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 8447] LMDB: Overwriting values in MDB_DUPSORT databases broken
by openldap-its＠openldap.org 25 May '23

25 May '23

https://bugs.openldap.org/show_bug.cgi?id=8447 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Fixed in RE0.9: • 76bad923 by Howard Chu at 2023-05-25T19:33:44+00:00 ITS#8447 fix cursor_put(MDB_CURRENT) on DUPSORT DB with different-sized data -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9736] New: pwrite bug in OSX breaking LMDB promise about the maximum value size
by openldap-its＠openldap.org 22 May '23

22 May '23

https://bugs.openldap.org/show_bug.cgi?id=9736 Issue ID: 9736 Summary: pwrite bug in OSX breaking LMDB promise about the maximum value size Product: LMDB Version: unspecified Hardware: All OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: renault.cle(a)gmail.com Target Milestone: --- Hi, I was working with LMDB and found an issue when trying to write a value of approximately 3.3GiB in the database, I dive into the LMDB source code of the mdb_put method using the lldb debugger and found out that it was not related to an issue in LMDB itself but rather a bug in the pwrite function of the Mac OS libc implementation. The pwrite function is given four parameters, the file descriptor, the buffer, the count of bytes to write from the buffer and, the offset of where to write it in the file. On Mac OS the count of bytes is a size_t that must be a 64bits unsigned integer but when you call pwrite with a number bigger or equal to 2^31 it returns an error 22 (invalid argument). LMDB was returning a 22 error from the mdb_put call and not an EINVAL because the error was cause by an internal issue and not something catchable by LMDB. I am not sure about what we can do, can we implement this single pwrite [1] as multiple pwrite with counts smaller than 2^31 in a loop, just for Mac OS? Like for Windows where we do specific things for this operating system too? I also found this issue on the RocksDB repository [2] about a similar problem they have with pwrite and write on Mac OS it seems. I understand that this is not a real promise that LMDB is specifying but rather an "in theory" rule [3]. Thank you for your time, kero [1]: https://github.com/LMDB/lmdb/blob/01b1b7dc204abdf3849536979205dc9e3a0e3ece/… [2]: https://github.com/facebook/rocksdb/issues/5169 [3]: http://www.lmdb.tech/doc/group__mdb.html#structMDB__val -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10055] New: EOS EOL
by openldap-its＠openldap.org 19 May '23

19 May '23

https://bugs.openldap.org/show_bug.cgi?id=10055 Issue ID: 10055 Summary: EOS EOL Product: OpenLDAP Version: 2.4.44 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: andrew.hudson(a)rtx.com Target Milestone: --- Hello, I work with Raytheon Intelligence and Space. I just have a quick question. I am in charge of keeping track of the software that is on my program's environment. We are on version 2.4.44. I am just wondering what the End of Support and the end of life of this version. Thank you very much. Andrew Hudson -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 4501] jdbcldap: use of enum reserved work (Java 1.5)
by openldap-its＠openldap.org 15 May '23

15 May '23

https://bugs.openldap.org/show_bug.cgi?id=4501 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs