- openldap-bugs - openldap.org

[Issue 9977] New: ContourCafe
by openldap-its＠openldap.org 05 Jan '23

05 Jan '23

https://bugs.openldap.org/show_bug.cgi?id=9977 Issue ID: 9977 Summary: ContourCafe Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: countourcafe7061(a)gmail.com Target Milestone: --- Created attachment 940 --> https://bugs.openldap.org/attachment.cgi?id=940&action=edit ContourCafe Contour Cafe is a popular website that offers numerous articles, contents about the things that make you beautiful, classy, and trendy. One can find fabulous content in the contour cafe. The quality of the articles of contour cafe on every topic let it be appearance, clothes, hair, cosmetics, nails or skincare is a great one. Contour Cafe is the best site to explore every category. Read More:- https://www.contourcafe.com/2021/06/26/best-purple-shampoo-for-blonde/ -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9975] New: Tattoomagz
by openldap-its＠openldap.org 05 Jan '23

05 Jan '23

https://bugs.openldap.org/show_bug.cgi?id=9975 Issue ID: 9975 Summary: Tattoomagz Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: tattoomagz3(a)gmail.com Target Milestone: --- Created attachment 939 --> https://bugs.openldap.org/attachment.cgi?id=939&action=edit Tattoomagz Tattoomagz is our sole enthusiasm in wonderful tattoo plans and ink works, manufactured and created as an online accumulation display serving a large number of the coolest tattoo structures and stunning custom ink-works. Read More:- https://tattoomagz.com/eyes-tattoos-on-arms/ -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9974] New: Einsteinhorsemag
by openldap-its＠openldap.org 03 Jan '23

03 Jan '23

https://bugs.openldap.org/show_bug.cgi?id=9974 Issue ID: 9974 Summary: Einsteinhorsemag Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: einsteinhorsemag(a)gmail.com Target Milestone: --- Created attachment 938 --> https://bugs.openldap.org/attachment.cgi?id=938&action=edit Einsteinhorsemag Einsteinhorsemag.com is a blogging website with the best blogs in beauty, health, nutrition, lifestyle, news, technology, and entertainment. Our website includes blogs covering various topics, from fractions to conversions in our day-to-day life, lyrics of your favourite song to food recipes you love- you will get it all. Visit our website for more entertaining blogs. Read Blog- https://einsteinhorsemag.com/80-kg-to-lbs/ -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9973] New: Fashionhikes
by openldap-its＠openldap.org 02 Jan '23

02 Jan '23

https://bugs.openldap.org/show_bug.cgi?id=9973 Issue ID: 9973 Summary: Fashionhikes Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: fashionhikes(a)gmail.com Target Milestone: --- Created attachment 937 --> https://bugs.openldap.org/attachment.cgi?id=937&action=edit Fashionhikes We at Fashionhikes.com are here to serve all your requirements! Check out our website that offers you a plethora of answers to your queries on health, technology, geography, economics, global knowledge and what not! Read Blog- https://fashionhikes.com/0-3-as-a-fraction/ -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9971] New: Tech99
by openldap-its＠openldap.org 02 Jan '23

02 Jan '23

https://bugs.openldap.org/show_bug.cgi?id=9971 Issue ID: 9971 Summary: Tech99 Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: tech99.856(a)gmail.com Target Milestone: --- Created attachment 936 --> https://bugs.openldap.org/attachment.cgi?id=936&action=edit Tech99 The Tech99.co website delivers blogs with the latest breaking news and videos. It is the perfect online destination for all entertainment lovers. More swiftly than any website, it offers helpful guidance on various how-tos, health, lifestyle and trending topics for netizens. There are some fantastic entertaining blogs on this website. Visit our website to read more! https://tech99.co/how-to-check-ufone-number/ -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9970] New: 2plus2four
by openldap-its＠openldap.org 30 Dec '22

30 Dec '22

https://bugs.openldap.org/show_bug.cgi?id=9970 Issue ID: 9970 Summary: 2plus2four Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: 2plus2four896(a)gmail.com Target Milestone: --- Created attachment 935 --> https://bugs.openldap.org/attachment.cgi?id=935&action=edit 2plus2four 2plus2four.net is your ultimate gateway to the latest movies, queries and hacks that you wish to know. We provide you the perfect plinth on which you can place all your doubts! Check our site out to know more! Read Blog- https://2plus2four.net/time-today-lyrics-moneybagg-yo/ -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9969] New: Sharetok
by openldap-its＠openldap.org 30 Dec '22

30 Dec '22

https://bugs.openldap.org/show_bug.cgi?id=9969 Issue ID: 9969 Summary: Sharetok Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: sre79132(a)gmail.com Target Milestone: --- Created attachment 934 --> https://bugs.openldap.org/attachment.cgi?id=934&action=edit Sharetok ShareTok is your place where you can advertise your services, goods and everything else as well; we do it with the help of various well-designed advertising campaigns on social media and with the help of some impressive good persuading content. You can connect with us online through the website.ShareTok is your place where you can advertise your services, goods and everything else as well; we do it with the help of various well-designed advertising campaigns on social media and with the help of some impressive good persuading content. You can connect with us online through the website. Read Blog- https://www.sharetok.com/transformar-powerpoint-em-pdf/ -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9968] New: Sportspassion
by openldap-its＠openldap.org 30 Dec '22

30 Dec '22

https://bugs.openldap.org/show_bug.cgi?id=9968 Issue ID: 9968 Summary: Sportspassion Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: sportspassion456(a)gmail.com Target Milestone: --- Created attachment 933 --> https://bugs.openldap.org/attachment.cgi?id=933&action=edit Sportspassion Sports-passion.net is the best stop point for all types of how-to guides, blogs, articles, and all such content related to differentiation. Here, in the form of articles and all other such content, you will get all the important latest information related to a lot of things around the world. Read Blog- https://sports-passion.net/difference-between-parameter-and-statistic/ -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9965] New: Byte Bell
by openldap-its＠openldap.org 21 Dec '22

21 Dec '22

https://bugs.openldap.org/show_bug.cgi?id=9965 Issue ID: 9965 Summary: Byte Bell Product: JLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: JDBC Assignee: bugs(a)openldap.org Reporter: bellbyte46(a)gmail.com Target Milestone: --- Bytebell.com is the place where you can get to read many featured stories about a lot of things like mental health, food, nutrition and many more. To read more: https://bytebell.com/spectrum-wave-2-router/ -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9964] New: He and she Fitness
by openldap-its＠openldap.org 21 Dec '22

21 Dec '22

https://bugs.openldap.org/show_bug.cgi?id=9964 Issue ID: 9964 Summary: He and she Fitness Product: JLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: JDBC Assignee: bugs(a)openldap.org Reporter: heandshefitness1(a)gmail.com Target Milestone: --- He and she fitness is here for you with all the secrets that can be helpful for you in the proper maintenance of the fitness of your body. To read more: https://www.heandshefitness.com/2021/06/01/how-many-calories-does-skipping-… -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9963] New: Wheels Inpak
by openldap-its＠openldap.org 21 Dec '22

21 Dec '22

https://bugs.openldap.org/show_bug.cgi?id=9963 Issue ID: 9963 Summary: Wheels Inpak Product: JLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: JDBC Assignee: bugs(a)openldap.org Reporter: wheelsinpak1(a)gmail.com Target Milestone: --- Wheelsinpak.com is the right place for you if you are looking for some kind of services, here you can search for the right providers of many needed services along with car and bike info. To read more: https://www.wheelsinpak.com/2021/12/08/kia-cars-price-in-pakistan-2021/ -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9962] New: Etrends News
by openldap-its＠openldap.org 19 Dec '22

19 Dec '22

https://bugs.openldap.org/show_bug.cgi?id=9962 Issue ID: 9962 Summary: Etrends News Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: etrendsnews07(a)gmail.com Target Milestone: --- Created attachment 932 --> https://bugs.openldap.org/attachment.cgi?id=932&action=edit etrendsnews.com This etrendsnews.com is the new stop for all types of news updates, you can get info about cars here and other than that there are many more things for which you can take reference from the website. https://etrendsnews.com/2021/05/04/deena-cortese-welcomes-her-2nd-baby-firs… -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9600] New: Rework lloadd's cn=monitor interface (connections)
by openldap-its＠openldap.org 12 Dec '22

12 Dec '22

https://bugs.openldap.org/show_bug.cgi?id=9600 Issue ID: 9600 Summary: Rework lloadd's cn=monitor interface (connections) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- At the moment, most of the lloadd's monitor entries are generated on demand for the search. To support management of the server and its connections, an entry should be created when a connection is set up and torn down accordingly. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9958] New: Problem extracting openldap-2.5.5.tgz
by openldap-its＠openldap.org 06 Dec '22

06 Dec '22

https://bugs.openldap.org/show_bug.cgi?id=9958 Issue ID: 9958 Summary: Problem extracting openldap-2.5.5.tgz Product: OpenLDAP Version: 2.5.5 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: harshad.ghorpade(a)gmail.com Target Milestone: --- Created attachment 931 --> https://bugs.openldap.org/attachment.cgi?id=931&action=edit 7zip extracting issue Hello, we have downloaded the the openldap version 2.5.5(https://www.openldap.org/software/download/OpenLDAP/openldap-release/… from the given link but we are seeing a problem unzipping those tgz files via 7 zip on windows platform, seems like symlinks are broken(find attached screenshot). This is causing us a issue in one of our tool used for software composition analysis when it unzips the archive, if the archives are fixed that would be great. if you see in screenshot, it points to 2 files in "servers\lload\design.md" and "servers\lload\nt_svc.c". we tried removing these files(as they are of 0 size) and tar it back again and creating a tgz file out of it, it works. but we would like to use the official released version rather than one changed by us. Thank you. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9948] New: tls_ciphers with TLSv1.2 cipher_suite gives list of TLSv1.3 ciphers in TLS Client Hello message
by openldap-its＠openldap.org 06 Dec '22

06 Dec '22

https://bugs.openldap.org/show_bug.cgi?id=9948 Issue ID: 9948 Summary: tls_ciphers with TLSv1.2 cipher_suite gives list of TLSv1.3 ciphers in TLS Client Hello message Product: OpenLDAP Version: 2.4.57 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: nikigen68(a)gmail.com Target Milestone: --- Created attachment 928 --> https://bugs.openldap.org/attachment.cgi?id=928&action=edit TLS server only supports TLSv1.3 in this case, and I would expect it to be rejected. For example: ldap.conf:: tls_ciphers ECDHE-ECDSA-CHACHA20-POLY1305 will give ClientHello with these cipher suites: TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256 TLS_CHACHA20_POLY1305_SHA256 ECDHE-ECDSA-CHACHA20-POLY1305 and supported versions: TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3 Why do we have listed default TLSv1.3 ciphers? I would expect only ECDHE-ECDSA-CHACHA20-POLY1305. Also, why do we have listed TLSv1.0 and TLSv1.1 as supported versions when those are considered vulnerable? -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9955] UTF8bvnormalize() overruns
by openldap-its＠openldap.org 05 Dec '22

05 Dec '22

https://bugs.openldap.org/show_bug.cgi?id=9955 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Note: Not exploitable, no operational or security impact. head: • 31e6efeb by Howard Chu at 2022-12-01T14:58:37+00:00 ITS#9955 liblunicode: fix buffer size in UTF8bvnormalize RE26: • 261a4185 by Howard Chu at 2022-12-05T16:29:07+00:00 ITS#9955 liblunicode: fix buffer size in UTF8bvnormalize RE25: • cd1d0886 by Howard Chu at 2022-12-05T16:30:29+00:00 ITS#9955 liblunicode: fix buffer size in UTF8bvnormalize -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9955] UTF8bvnormalize() overruns
by openldap-its＠openldap.org 29 Nov '22

29 Nov '22

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

1 0

[Issue 9916] New: slapd crashes due to unaligned access in mdb.c on Linux SPARC
by openldap-its＠openldap.org 28 Nov '22

28 Nov '22

https://bugs.openldap.org/show_bug.cgi?id=9916 Issue ID: 9916 Summary: slapd crashes due to unaligned access in mdb.c on Linux SPARC Product: OpenLDAP Version: 2.6.3 Hardware: Other OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: glaubitz(a)physik.fu-berlin.de Target Milestone: --- The testsuite of the openldap package in Debian unstable fails on sparc64 with a "bus error" which indicates an unaligned access [1]: >>>>> Test succeeded >>>>> 00:00:02 Finished test000-rootdse for mdb after 1 seconds. >>>>> 00:00:02 Starting test001-slapadd for mdb... running defines.sh Running slapadd to build slapd database... Bus error slapadd failed (138)! >>>>> 00:00:03 Failed test001-slapadd for mdb after 1 seconds (exit 138) Building openldap from git and running the affected test with GDB results in the following backtrace: (gdb) bt #0 0x00000100000cc36c in mdb_node_add (mc=0x100004316e8, indx=<optimized out>, key=0x7feffffe570, data=0x7feffffe560, pgno=0, flags=0) at ./../../../libraries/liblmdb/mdb.c:7358 #1 0x00000100000d0894 in mdb_cursor_put (mc=0x100004316e8, key=0x7feffffe570, data=0x7feffffe560, flags=16) at ./../../../libraries/liblmdb/mdb.c:6960 #2 0x00000100000d1224 in mdb_cursor_put (mc=0x10000431560, key=0x7feffffe6b0, data=0x7feffffe6c0, flags=36) at ./../../../libraries/liblmdb/mdb.c:7007 #3 0x00000100000f0d24 in mdb_dn2id_add (op=0x7feffffea28, mcp=0x10000431560, mcd=0x100004267a0, pid=<optimized out>, nsubs=<optimized out>, upsub=<optimized out>, e=0x1000044c6b8) at dn2id.c:141 #4 0x00000100000dd79c in mdb_tool_next_id (op=0x7feffffea28, tid=<optimized out>, e=0x1000044c6b8, text=0x7feffffec78, hole=<optimized out>) at tools.c:519 #5 0x00000100000de67c in mdb_tool_entry_put (be=0x100003d9080, e=0x1000044c6b8, text=0x7feffffec78) at tools.c:731 #6 0x00000100000b72f4 in slapadd (argc=<optimized out>, argv=<optimized out>) at slapadd.c:453 #7 0x0000010000016858 in main (argc=<optimized out>, argv=0x7fefffff438) at main.c:540 (gdb) This was reproduced with: $ gdb --args /home/glaubitz/openldap/servers/slapd/slapd -Ta -d 0 -f /home/glaubitz/openldap/tests/testrun/slapadd.conf -l ./testdata/test-ordered.ldif On the machine gcc202 running Debian on sparc64 in the GCC compile farm. Access to the machines in the GCC compile farm can be obtained by any developer [2]. > [1] https://buildd.debian.org/status/fetch.php?pkg=openldap&arch=sparc64&ver=2.… > [2] https://gcc.gnu.org/wiki/CompileFarm -- You are receiving this mail because: You are on the CC list for the issue.

1 25

[Issue 9806] New: MDB_PAGE_FULL on mdb_put
by openldap-its＠openldap.org 28 Nov '22

28 Nov '22

https://bugs.openldap.org/show_bug.cgi?id=9806 Issue ID: 9806 Summary: MDB_PAGE_FULL on mdb_put Product: LMDB Version: unspecified Hardware: Other OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: casey(a)rodarmor.com Target Milestone: --- I'm using the using latest lmdb from OpenLDAP, commit e8813b12b6188d5ba5f174ff8726c438c8ca4bfd. I'm getting an MDB_PAGE_FULL error after calling `mdb_put`. If I delete the database and perform the same sequence of inserts, I get the same error in on the same mdb_put. If there's any information I can provide to help debug this, let me know. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9954] New: RE26 make test fails on riscv64
by openldap-its＠openldap.org 20 Nov '22

20 Nov '22

https://bugs.openldap.org/show_bug.cgi?id=9954 Issue ID: 9954 Summary: RE26 make test fails on riscv64 Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- Created attachment 929 --> https://bugs.openldap.org/attachment.cgi?id=929&action=edit Excerpt of OBS' build log In openSUSE build system make test fails for RE26 on riscv64 (see attached file including tests/testrun/slapd.1.log). -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9950] New: Need example configuration backend-sock
by openldap-its＠openldap.org 15 Nov '22

15 Nov '22

https://bugs.openldap.org/show_bug.cgi?id=9950 Issue ID: 9950 Summary: Need example configuration backend-sock Product: OpenLDAP Version: 2.4.57 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: earyutin(a)gmail.com Target Milestone: --- Hi all ! I set up two backends on different ports, one is a proxy for MS AD, and the second is a backend shell. I want to update to the latest version of OpenLDAP, but there is no backend shell support in the next versions. I can't find any documentation or examples that I could rely on to set up a backend for backend sock. Added the following to the files: port 389 include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema modulepath /usr/lib/ldap moduleload back_ldap.la moduleload rwm.la pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args database ldap readonly yes protocol-version 3 rebind-as-user yes uri "ldap://ldap.test.com" suffix "dc=test,dc=com" overlay rwm rwm-map attribute uid sAMAccountName rwm-map attribute mail proxyAddresses rebind-as-user yes access to attrs=userPassword by self write by anonymous auth by * none access to * by self write by * none port 9000 modulepath /usr/lib/ldap moduleload back_sock.la moduleload back_sock database sock suffix "dc=test,dc=com" socketpath /tmp/slapd.sock Next, I don't know where to go. Could you demonstrate a working example of running and processing scripts based on the backend-sock? I need to launch my own script that would check the second factor (should check for the presence of a certain attribute in the Active Directors directory and then skip or not skip authorization based on a given condition). Help me figure it out please.. Thank you ! -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9949] New: MDB_RDONLY txn segfaults on newly created database
by openldap-its＠openldap.org 14 Nov '22

14 Nov '22

https://bugs.openldap.org/show_bug.cgi?id=9949 Issue ID: 9949 Summary: MDB_RDONLY txn segfaults on newly created database Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: jeffrey.reynolds(a)ticketmaster.com Target Milestone: --- The very simple code will cause a seg fault. ``` auto env = create_env("env_name"); // creates the environment. not included here because this part is in rust // it will open or create the database. i don't think the problem lies in here. MDB_txn* txn{}; mdb_txn_begin(*env, nullptr, MDB_RDONLY, &txn); MDB_dbi dbi{}; mdb_dbi_open(txn, "db_name", MDB_CREATE, &dbi); ``` This segfaults on `liblmdb/mdb.c:11050`. Specifically `tracked->mc_next = *tp;` However, the problem isn't in mdb_dbi_open, it is failing because mt_cursors is never initialized. A small change ` mdb_txn_begin(*env, nullptr, 0, &txn);` and mt_cursors will be initialized with the default env->me_txn0, that has a properly initialized mt_cursors, per this line `liblmdb/mdb.c:5581`, `txn->mt_cursors = (MDB_cursor **)(txn->mt_dbs + env->me_maxdbs);` for the MDB_RDONLY transaction, it looks like it will initialize mt_cursors _if_ it happens to have a parent, `liblmdb/mdb.c:3178`, but otherwise it leaves it uninitialized. Is this a bug, or do have i have to a parent to start a readonly transaction on a new database? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 8988] Undefined Behavior in slapadd
by openldap-its＠openldap.org 14 Nov '22

14 Nov '22

https://bugs.openldap.org/show_bug.cgi?id=8988 --- Comment #24 from Howard Chu <hyc(a)openldap.org> --- (In reply to openldap-technical(a)kolttonen.fi from comment #21) > Hello, > Spending long time on comp.lang.c should be mandatory for all C > programmers out there. It is shocking to invoke UB and not bother to fix > it, instead blaming compiler writers and C standard writers. > > Best regards, > Jokke Hämäläinen I'm quite sure I've spent more time on comp.lang.c than most people out there. https://groups.google.com/g/comp.lang.c/c/BiVJrHbtZE4/m/W1C3fC-n2pEJ https://groups.google.com/g/comp.lang.c/c/3TGIxk3epBw/m/CXVzV5aEehsJ ... I was also a gcc maintainer from gcc 1.x to 2.x days. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9946] New: TLS: could not load verify locations
by openldap-its＠openldap.org 04 Nov '22

04 Nov '22

https://bugs.openldap.org/show_bug.cgi?id=9946 Issue ID: 9946 Summary: TLS: could not load verify locations Product: OpenLDAP Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hrishikesh.durg(a)gmail.com Target Milestone: --- Hi, Am seeing below errors on one of ldap proxy server --ANy clue how to fix it ? =============== 635a3252 openotp_parse_conf: global: server_url = https://iad37-c-sec-afe-01.us6.oraclecloud.com:443/openotp/,https://ch3-c-s… 635a3252 openotp_parse_conf: global: soap_timeout = 10 635a3252 openotp_parse_conf: global: user_settings = ChallengeMode=No 635a3252 openotp_parse_conf: global: uid_attribute = uid, cn 635a3252 openotp_parse_conf: global: client_id = LDAP 635a3252 openotp_parse_conf: global: default_domain = oraclecloud 635a3252 openotp_parse_conf: global: server_policy = 1 635a3252 openotp_parse_conf: global: status_cache = 10 635a3252 openotp_parse_conf: global: nolock_usernames = ldapro-oci-sharedservices,ldapro-saas,ldapro-sbs 635a3252 openotp_parse_conf: global: denied_usernames = (none) 635a3252 openotp_init: Initializing libopenotp TLS: could not load verify locations (file:`/opt/ldproxy/conf/ca.crt',dir:`'). TLS: error:02001002:system library:fopen:No such file or directory bss_file.c:175 TLS: error:2006D080:BIO routines:BIO_new_file:no such file bss_file.c:182 TLS: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib by_file.c:253 635a3252 main: TLS init def ctx failed: -1 635a3252 slapd stopped. 635a3252 connections_destroy: nothing to destroy. =========== Not seeing anything when checked on location specified from logs : [root@ldap-proxy-01 certs]# ls -l /opt/ldproxy total 0 drwxr-xr-x. 2 root root 48 Nov 4 08:27 logs [root@ldap-proxy-01 certs]# ============== ldap.conf file looks as below : # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLS_CACERTDIR /etc/openldap/certs # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on Any help /clue is much appreciated -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9945] New: Unable to import initial configuration (cn=config)
by openldap-its＠openldap.org 04 Nov '22

04 Nov '22

https://bugs.openldap.org/show_bug.cgi?id=9945 Issue ID: 9945 Summary: Unable to import initial configuration (cn=config) Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: annamariet(a)crimsonlogic.com Target Milestone: --- Created attachment 927 --> https://bugs.openldap.org/attachment.cgi?id=927&action=edit slapd.ldif I was able to install openldap 2.5.13 successfully but I was getting error below whenever I will import the initial configuration using this command: /usr/local/sbin/slapadd -n 0 -F /usr/local/etc/slapd.d -l /usr/local/etc/openldap/slapd.ldif Error: str2entry: entry -1 has multiple DNs "cn=config" and "cn=module,cn=config" slapadd: could not parse entry (line=1) Closing DB... In my slapd.ldif file, both DNs are enabled. Only this cn=module is throwing error while other dn e.g. dn: cn=schema,cn=config are accepted. Am I missing some packages or RPMs? dn: cn=config objectClass: olcGlobal cn: config . . . dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/local/libexec/openldap olcModuleload: back_mdb.la olcModuleload: back_ldap.la olcModuleload: back_passwd.la olcModuleload: back_shell.la . . . -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9045] Crashes in cn=config (test050)
by openldap-its＠openldap.org 02 Nov '22

02 Nov '22

https://bugs.openldap.org/show_bug.cgi?id=9045 --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Removed from RE25 as it is missing the requisite libldap functionality to fix the issue there. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9045] Crashes in cn=config (test050)
by openldap-its＠openldap.org 02 Nov '22

02 Nov '22

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

1 0

[Issue 9045] Crashes in cn=config (test050)
by openldap-its＠openldap.org 01 Nov '22

01 Nov '22

https://bugs.openldap.org/show_bug.cgi?id=9045 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|CONFIRMED |RESOLVED --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • a6f3106a by Ondřej Kuzník at 2022-10-31T18:16:42+00:00 ITS#9045 Do not share cn=config entries with outside code RE26: • 99a7c141 by Ondřej Kuzník at 2022-11-01T17:05:36+00:00 ITS#9045 Do not share cn=config entries with outside code RE25: • ce7a7997 by Ondřej Kuzník at 2022-11-01T17:07:15+00:00 ITS#9045 Do not share cn=config entries with outside code -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9045] Crashes in cn=config (test050)
by openldap-its＠openldap.org 31 Oct '22

31 Oct '22

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

1 0

[Issue 9938] New: Deprecate STARTTLS, recommend LDAPS
by openldap-its＠openldap.org 31 Oct '22

31 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9938 Issue ID: 9938 Summary: Deprecate STARTTLS, recommend LDAPS Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: martin.von.wittich(a)iserv.eu Target Milestone: --- This has been discussed on the mailing list before, but unfortunately it seems to have gotten lost in the shuffle: https://www.openldap.org/lists/openldap-technical/201802/msg00004.html > To me this rationale for SMTP submission with implicit TLS seems also > applicable to LDAPS vs. StartTLS: > > https://tools.ietf.org/html/rfc8314#appendix-A > > So LDAPS should not be considered deprecated. Rather it should be > recommended and the _optional_ use of StartTLS should be strongly > discouraged. Currently, https://www.openldap.org/faq/data/cache/605.html (Start TLS v. ldaps://) still recommends STARTTLS over LDAPS. This unfortunately leads LDAP client implementers to create clients that only support STARTTLS, e.g. here: https://github.com/odoo/odoo/issues/9772#issuecomment-159943316 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9943] New: pw-radius
by openldap-its＠openldap.org 28 Oct '22

28 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9943 Issue ID: 9943 Summary: pw-radius Product: OpenLDAP Version: 2.4.57 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: earyutin(a)gmail.com Target Milestone: --- Good evening, dear developers! I'm using Debian 11 Faced with the problem of compiling the module for authorization through FreeRadius, users connecting to OpenLDAP. There is little information on the net, but I managed to find the following: https://github.com/openldap/openldap/blob/master/contrib/slapd-modules/pass… moduleload pw-radius.so gcc -shared -I../../../include -Wall -g -o pw-radius.so radius.c -lradius Installed: apt install slapd ldap-utils Version: slapd -V @(#) $OpenLDAP: slapd 2.4.57+dfsg-3+deb11u1 gcc -shared -I /usr/lib/ldap/ -Wall -g -o pw-radius.so radius.c -lradius gcc: error: radius.c: No such file or directory 1. Download "openldap-2.5.13.tgz" 2. tar -zxvf openldap-2.5.13.tgz 3. find /root/openldap-2.5.13/ -name "radius.c" /root/openldap-2.5.13/contrib/slapd-modules/passwd/radius.c 4. cd /root/openldap-2.5.13/contrib/slapd-modules/passwd/ 5. gcc -shared -I ../../../include -Wall -g -o pw-radius.so radius.c -lradius" Errors appear 5.1. radius.c:16:10: fatal error: portable.h: No such file or directory 16 | #include "portable.h" 5.2. find /root/openldap-2.5.13/ -name "portable.*" /root/openldap-2.5.13/include/portable.hin 5.3. cp /root/openldap-2.5.13/include/portable.hin /root/openldap-2.5.13/include/portable.h 5.4. gcc -shared -I ../../../include -Wall -g -o pw-radius.so radius.c -lradius" 5.5. In file included from radius.c:16: ../../../include/portable.h:1188:10: fatal error: ldap_features.h: No such file or directory 1188 | #include "ldap_features.h" 5.6. find /root/openldap-2.5.13/ -name "ldap_features.*" /root/openldap-2.5.13/include/ldap_features.hin cp /root/openldap-2.5.13/include/ldap_features.hin /root/openldap-2.5.13/include/ldap_features.h ... After changing the names of all bad files, a bunch of errors come out: gcc -shared -I ../../../include -Wall -g -o pw-radius.so radius.c -lradius In file included from ../../../include/lber.h:29, from radius.c:20: ../../../include/lber_types.h:42:9: error: unknown type name ‘LBER_INT_T’ 42 | typedef LBER_INT_T ber_int_t; | ^~~~~~~~~~ ../../../include/lber_types.h:45:27: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ber_sint_t’ 45 | typedef signed LBER_INT_T ber_sint_t; | ^~~~~~~~~~ ../../../include/lber_types.h:46:29: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ber_uint_t’ 46 | typedef unsigned LBER_INT_T ber_uint_t; | ^~~~~~~~~~ ../../../include/lber_types.h:49:29: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ber_tag_t’ 49 | typedef unsigned LBER_TAG_T ber_tag_t; | ^~~~~~~~~ ../../../include/lber_types.h:52:9: error: unknown type name ‘LBER_SOCKET_T’ 52 | typedef LBER_SOCKET_T ber_socket_t; | ^~~~~~~~~~~~~ ../../../include/lber_types.h:55:29: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ber_len_t’ 55 | typedef unsigned LBER_LEN_T ber_len_t; | ^~~~~~~~~ ../../../include/lber_types.h:58:27: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ber_slen_t’ 58 | typedef signed LBER_LEN_T ber_slen_t; | ^~~~~~~~~~ In file included from ../../../include/portable.hin:1187, from radius.c:16: ../../../include/lber.h:121:42: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 121 | typedef void* (BER_MEMALLOC_FN) LDAP_P(( ber_len_t size, void *ctx )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:122:43: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 122 | typedef void* (BER_MEMCALLOC_FN) LDAP_P(( ber_len_t n, ber_len_t size, void *ctx )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:122:56: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 122 | typedef void* (BER_MEMCALLOC_FN) LDAP_P(( ber_len_t n, ber_len_t size, void *ctx )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:123:53: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 123 | typedef void* (BER_MEMREALLOC_FN) LDAP_P(( void *p, ber_len_t size, void *ctx )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ In file included from radius.c:20: ../../../include/lber.h:127:2: error: unknown type name ‘BER_MEMALLOC_FN’ 127 | BER_MEMALLOC_FN *bmf_malloc; | ^~~~~~~~~~~~~~~ ../../../include/lber.h:128:2: error: unknown type name ‘BER_MEMCALLOC_FN’ 128 | BER_MEMCALLOC_FN *bmf_calloc; | ^~~~~~~~~~~~~~~~ ../../../include/lber.h:129:2: error: unknown type name ‘BER_MEMREALLOC_FN’ 129 | BER_MEMREALLOC_FN *bmf_realloc; | ^~~~~~~~~~~~~~~~~ ../../../include/lber.h:191:2: error: expected specifier-qualifier-list before ‘ber_slen_t’ 191 | ber_slen_t (*sbi_read)( Sockbuf_IO_Desc *sbiod, void *buf, | ^~~~~~~~~~ ../../../include/lber.h:213:2: error: unknown type name ‘ber_len_t’ 213 | ber_len_t bv_len; | ^~~~~~~~~ In file included from ../../../include/portable.hin:1187, from radius.c:16: ../../../include/lber.h:230:25: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 230 | LDAP_CONST char *data, ber_len_t len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:244:9: error: unknown type name ‘ber_tag_t’ 244 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:248:9: error: unknown type name ‘ber_tag_t’ 248 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:251:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 251 | ber_len_t *len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:253:9: error: unknown type name ‘ber_tag_t’ 253 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:256:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 256 | ber_len_t *len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:258:9: error: unknown type name ‘ber_tag_t’ 258 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:263:9: error: unknown type name ‘ber_tag_t’ 263 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:268:9: error: unknown type name ‘ber_tag_t’ 268 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:273:9: error: unknown type name ‘ber_tag_t’ 273 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:278:9: error: unknown type name ‘ber_tag_t’ 278 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:288:9: error: unknown type name ‘ber_tag_t’ 288 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:292:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 292 | ber_len_t *len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:301:9: error: unknown type name ‘ber_tag_t’ 301 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:307:9: error: unknown type name ‘ber_tag_t’ 307 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:312:9: error: unknown type name ‘ber_tag_t’ 312 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:317:9: error: unknown type name ‘ber_tag_t’ 317 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:321:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 321 | ber_len_t *len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:323:9: error: unknown type name ‘ber_tag_t’ 323 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:327:9: error: unknown type name ‘ber_tag_t’ 327 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:332:9: error: unknown type name ‘ber_tag_t’ 332 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:335:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 335 | ber_len_t *len, | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:338:9: error: unknown type name ‘ber_tag_t’ 338 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:341:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 341 | ber_len_t *len, | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:344:9: error: unknown type name ‘ber_tag_t’ 344 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:371:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 371 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:377:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 377 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:383:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 383 | ber_len_t len, | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:384:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 384 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:390:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 390 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:396:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 396 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:402:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 402 | ber_len_t bitlen, | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:403:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 403 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:408:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 408 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:414:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 414 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:419:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 419 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:424:2: error: unknown type name ‘ber_tag_t’; did you mean ‘ber_int_t’? 424 | ber_tag_t tag )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:445:9: error: unknown type name ‘ber_slen_t’ 445 | LBER_F( ber_slen_t ) | ^~~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:448:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 448 | ber_len_t len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:450:9: error: unknown type name ‘ber_slen_t’ 450 | LBER_F( ber_slen_t ) | ^~~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:454:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 454 | ber_len_t len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:456:9: error: unknown type name ‘ber_slen_t’ 456 | LBER_F( ber_slen_t ) | ^~~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:460:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 460 | ber_len_t len, | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:501:9: error: unknown type name ‘ber_tag_t’ 501 | LBER_F( ber_tag_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:504:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 504 | ber_len_t *len, | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:600:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 600 | ber_len_t s )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:605:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 605 | ber_len_t s )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:609:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 609 | ber_len_t n, | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:610:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 610 | ber_len_t s )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:643:21: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 643 | LDAP_CONST char *, ber_len_t len, int duplicate, struct berval *bv)); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:647:21: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 647 | LDAP_CONST char *, ber_len_t len, int duplicate, struct berval *bv)); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:656:9: error: unknown type name ‘ber_len_t’ 656 | LBER_F( ber_len_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber.h:658:22: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 658 | LDAP_CONST char *s, ber_len_t len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber.h:662:22: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 662 | LDAP_CONST char *s, ber_len_t l )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ In file included from radius.c:21: ../../../include/lber_pvt.h:45:2: error: unknown type name ‘ber_len_t’ 45 | ber_len_t buf_size; | ^~~~~~~~~ ../../../include/lber_pvt.h:46:2: error: unknown type name ‘ber_len_t’ 46 | ber_len_t buf_ptr; | ^~~~~~~~~ ../../../include/lber_pvt.h:47:2: error: unknown type name ‘ber_len_t’ 47 | ber_len_t buf_end; | ^~~~~~~~~ In file included from ../../../include/portable.hin:1187, from radius.c:16: ../../../include/lber_pvt.h:66:9: error: unknown type name ‘ber_slen_t’ 66 | LBER_F( ber_slen_t ) | ^~~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber_pvt.h:76:51: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 76 | ber_pvt_sb_grow_buffer LDAP_P(( Sockbuf_Buf *buf, ber_len_t minsize )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber_pvt.h:78:9: error: unknown type name ‘ber_len_t’ 78 | LBER_F( ber_len_t ) | ^~~~~~~~~ ../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’ 136 | # define LBER_F(type) extern type | ^~~~ ../../../include/lber_pvt.h:79:59: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 79 | ber_pvt_sb_copy_out LDAP_P(( Sockbuf_Buf *sbb, char *buf, ber_len_t len )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber_pvt.h:89:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 89 | ber_len_t s, void *ctx)); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber_pvt.h:94:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 94 | ber_len_t s, void *ctx )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber_pvt.h:98:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 98 | ber_len_t n, | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber_pvt.h:99:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 99 | ber_len_t s, void *ctx )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber_pvt.h:128:21: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 128 | LDAP_CONST char *, ber_len_t len, int dup, struct berval *bv, void *ctx)); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lber_pvt.h:132:21: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 132 | LDAP_CONST char *, ber_len_t len, int dup, struct berval *bv, void *ctx)); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ In file included from ../../../include/lutil.h:21, from radius.c:22: ../../../include/ac/socket.h:233:46: error: unknown type name ‘uid_t’ 233 | LDAP_LUTIL_F( int ) lutil_getpeereid( int s, uid_t *, gid_t * ); | ^~~~~ ../../../include/ac/socket.h:233:55: error: unknown type name ‘gid_t’ 233 | LDAP_LUTIL_F( int ) lutil_getpeereid( int s, uid_t *, gid_t * ); | ^~~~~ ../../../include/ac/socket.h:238:18: error: field ‘sa_addr’ has incomplete type 238 | struct sockaddr sa_addr; | ^~~~~~~ ../../../include/ac/socket.h:239:21: error: field ‘sa_in_addr’ has incomplete type 239 | struct sockaddr_in sa_in_addr; | ^~~~~~~~~~ In file included from ../../../include/portable.hin:1187, from radius.c:16: ../../../include/lutil.h:68:2: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 68 | ber_len_t nbytes )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ ../../../include/lutil.h:137:51: error: unknown type name ‘ber_len_t’; did you mean ‘ber_int_t’? 137 | lutil_passwd_generate LDAP_P(( struct berval *pw, ber_len_t )); | ^~~~~~~~~ ../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’ 32 | # define LDAP_P(protos) protos | ^~~~~~ radius.c:27:10: fatal error: radlib.h: No such file or directory 27 | #include <radlib.h> Help me please. Thank you ! -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 5693] [enhancement] extension of slapo-translucent filtering approach
by openldap-its＠openldap.org 25 Oct '22

25 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=5693 --- Comment #5 from salleman(a)math.u-bordeaux.fr --- Hi, I have a similar issue with search on translucent overlay : I override ObjectClass with posixAccount. I set translucent with : olcTranslucentLocal: uidNumber olcTranslucentLocal: gidNumber olcTranslucentLocal: homeDirectory olcTranslucentLocal: loginShell olcTranslucentLocal: mailAlternateAddress olcTranslucentLocal: memberUid olcTranslucentLocal: objectClass It works except when I search with filter like this : "(&(loginShell=/bin/bash)(sn=Smith))". On the remote backend, the search is : SRCH base="uid=dupont,ou=people,dc=u-bordeaux,dc=fr" scope=0 deref=0 filter="(objectClass=*) SEARCH RESULT tag=101 err=0 qtime=0.000013 etime=0.000146 nentries=1 text=" which is a entry contains loginShell=/bin/bash. It seems that when a composed filter with local and remote attributes returns many results from local (loginShell), the search on remote would apply for each dn founds but translucent fails on the first (because second part of filter is not verified (sn=Smith)). -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9045] Crashes in cn=config (test050)
by openldap-its＠openldap.org 24 Oct '22

24 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9045 --- Comment #4 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Created attachment 926 --> https://bugs.openldap.org/attachment.cgi?id=926&action=edit A more recent crash -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9045] Crashes in cn=config (test050)
by openldap-its＠openldap.org 24 Oct '22

24 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9045 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CONFIRMED Ever confirmed|0 |1 Resolution|WORKSFORME |--- --- Comment #3 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Got another one, in do_syncrep1, attached. I gather it's because syncrepl got it through entry_get() while there is a modify request on cn=config that freed it in the meantime. Sounds like ldap_pvt_thread_rdwr_rlock( &cfb->cb_rwlock ) in config_back_entry_get (and the reverse in config_entry_release()) might do the trick, except that anyone getting that entry needs to release it before they yield processing - as bconfig might decide it wants to pause and wlock. Or we just entry_dup it unconditionally which means we never interfere with anyone else. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9939] New: datamorph test fails
by openldap-its＠openldap.org 24 Oct '22

24 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9939 Issue ID: 9939 Summary: datamorph test fails Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: patrick+openldap.org(a)laimbock.com Target Milestone: --- [snip] + for MOD in datamorph ppm variant + pushd contrib/slapd-modules/datamorph ~/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph ~/build/BUILD/openldap-2.6.3 + /usr/bin/make -O -j1 V=1 VERBOSE=1 test ln -s /builddir/build/BUILD/openldap-2.6.3/clients clients ln -s /builddir/build/BUILD/openldap-2.6.3/servers servers ln -s /builddir/build/BUILD/openldap-2.6.3/tests/progs tests/progs cd tests; \ SRCDIR=/builddir/build/BUILD/openldap-2.6.3 \ LDAP_BUILD=/builddir/build/BUILD/openldap-2.6.3 \ TOPDIR=/builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph \ LIBTOOL=/builddir/build/BUILD/openldap-2.6.3/libtool \ /builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph/tests/run all Running /builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph/tests/scripts/all for mdb... >>>>> Executing all LDAP tests for mdb >>>>> Starting test001-config for mdb... running defines.sh /builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph/tests/scripts/common.sh: line 26: /servers/slapd/slapd: No such file or directory /builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph/tests/scripts/common.sh: line 28: /servers/slapd/slapd: No such file or directory Starting slapd on TCP/IP port 9011 for configuration... Waiting 7 seconds for slapd to start... Waiting 7 seconds for slapd to start... Waiting 7 seconds for slapd to start... Waiting 7 seconds for slapd to start... Waiting 7 seconds for slapd to start... Waiting 7 seconds for slapd to start... Failed testing for module load entry >>>>> test001-config failed for mdb (exit 127) make: *** [tests/Rules.mk:12: test] Error 127 This test also fails on the latest 2.6 branch. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 8610] ldaps not usable with DNS SRV
by openldap-its＠openldap.org 21 Oct '22

21 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=8610 --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- The FAQ is historic, 99% of what's in it is incorrect. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9933] New: pamcompany
by openldap-its＠openldap.org 19 Oct '22

19 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9933 Issue ID: 9933 Summary: pamcompany Product: JLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: JDBC Assignee: bugs(a)openldap.org Reporter: packersnmoversservices(a)gmail.com Target Milestone: --- A trustworthy and expert moving business in Bangalore's Hebbal is PAM Bangalore. This business is regarded as one of the top packers and movers hebbal service providers because of its reputation for offering high-quality moving and shifting services at reasonable pricing. Relocators who require storage or house transferring services in Bangalore seek them. A firm with a team of professional packers and movers offers a hassle-free, damage-free, and stress-free move at a reasonable cost. https://www.packersmoversinbangalore.co.in/packers-and-movers-in-hebbal/ -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9927] New: mdb/0.9 update makes strange problems
by openldap-its＠openldap.org 13 Oct '22

13 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9927 Issue ID: 9927 Summary: mdb/0.9 update makes strange problems Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- Created attachment 919 --> https://bugs.openldap.org/attachment.cgi?id=919&action=edit strace outfput of failed start I changed on the 2.6 branch at this commit 18f6cc1609fe80ae30702f68875a6fc793e29ffd (origin/OPENLDAP_REL_ENG_2_6, OPENLDAP_REL_ENG_2_6) Merge: 8b4c915a6 d87d682b6 Author: Quanah Gibson-Mount <quanah(a)openldap.org> Date: Tue Oct 4 14:29:39 2022 +0000 Merge remote-tracking branch 'origin/mdb.RE/0.9' into OPENLDAP_REL_ENG_2_6 and things stopped working: after several times restarting slapd refused to start. Then I went back to commit: commit 8b4c915a655373973a834719f942bcdc09a7b516 (HEAD) Author: Quanah Gibson-Mount <quanah(a)openldap.org> Date: Mon Oct 3 20:26:19 2022 +0000 ITS#9915 and things worked again. I changed back to commit 18f6cc1609fe8, and slapd does run properly. Of course, I assume the LMDB database format has not changed and I have not done export to LDIF and then import from LDIF to LMDB. I have disabled syslog and debugging: $ ./configure --disable-ipv6 --enable-spasswd --disable-static --disable-syslog --disable-debug --enable-sssvlv --disable-relay The file FAILED.txt, produced on dysfunctional slapd by executing # strace /usr/local/libexec/slapd -d0 -u openldap -r /home/openldap -F /etc/openldap/ -h'ldap://ldap.aegee.org/ ldaps://ldap.aegee.org ldapi://%%2Fvar%%2Frun%%2Fldapi' > FAILED.txt is attached. This is very similar to https://bugs.openldap.org/show_bug.cgi?id=9879 : upgrading to the newest version fails. Using a slightly older version than the tip of the tree does not fail any more. Then upgrading to the newest version does work. Note that yesterday, or two-three days ago I also upgraded to the newest tip of git and things worked, but I cannot say which commit was this. # journalctl --unit openldap Oct 04 08:04:31 mail systemd[1]: Stopping OpenLDAP... Oct 04 08:04:33 mail systemd[1]: openldap.service: Deactivated successfully. Oct 04 08:04:33 mail systemd[1]: Stopped OpenLDAP. Oct 04 08:04:33 mail systemd[1]: openldap.service: Consumed 50.080s CPU time. Oct 04 08:04:33 mail systemd[1]: Starting OpenLDAP... Oct 04 08:04:36 mail systemd[1]: Started OpenLDAP. Oct 04 08:10:33 mail systemd[1]: Stopping OpenLDAP... Oct 04 08:10:34 mail systemd[1]: openldap.service: Deactivated successfully. Oct 04 08:10:34 mail systemd[1]: Stopped OpenLDAP. Oct 04 08:10:37 mail systemd[1]: Starting OpenLDAP... Oct 04 08:10:37 mail systemd[1]: Started OpenLDAP. Oct 05 07:33:36 mail systemd[1]: Stopping OpenLDAP... Oct 05 07:33:37 mail systemd[1]: openldap.service: Failed with result 'resources'. Oct 05 07:33:37 mail systemd[1]: Stopped OpenLDAP. Oct 05 07:33:37 mail systemd[1]: openldap.service: Consumed 7.453s CPU time. Oct 05 07:33:37 mail systemd[1]: Starting OpenLDAP... Oct 05 07:33:38 mail systemd[1]: openldap.service: Main process exited, code=exited, status=255/EXCEPTION Oct 05 07:33:38 mail systemd[1]: openldap.service: Failed with result 'exit-code'. Oct 05 07:33:38 mail systemd[1]: Failed to start OpenLDAP. Oct 05 07:33:43 mail systemd[1]: Starting OpenLDAP... Oct 05 07:33:43 mail systemd[1]: openldap.service: Main process exited, code=exited, status=255/EXCEPTION Oct 05 07:33:43 mail systemd[1]: openldap.service: Failed with result 'exit-code'. Oct 05 07:33:43 mail systemd[1]: Failed to start OpenLDAP. Oct 05 07:38:22 mail systemd[1]: Starting OpenLDAP... so it worked likely without problems on the most current 2.6 commit at Oct 04 08:04:33 UTC. Note that the failing slapd does terminate before reading the configuration files with newfstatat(AT_FDCWD, "/etc/openldap/", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 newfstatat(AT_FDCWD, "/etc/openldap/", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f03c36d1000 openat(AT_FDCWD, "/etc/openldap//cn=config.ldif", O_RDONLY) = 9 newfstatat(9, "", {st_mode=S_IFREG|0600, st_size=817, ...}, AT_EMPTY_PATH) = 0 so it shall be irrelevant how MDB handles the data. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9932] New: Sync failing between two LDAP servers
by openldap-its＠openldap.org 13 Oct '22

13 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9932 Issue ID: 9932 Summary: Sync failing between two LDAP servers Product: OpenLDAP Version: 2.4.58 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: shikhar81(a)gmail.com Target Milestone: --- Hi Team, We have noticed a sync issue in our environment. We have two production servers namely A and B and two DR servers namely C and D. A and B are in bi-directional sync A and C are in bi-directional sync B and D are in bi-directional sync Since the last few days the sync between A and C and B and D has broken and we are unable to see any concrete error in logs Just to add here that server A and server B are in the same subnet and server C & server D are in a different subnet. However, this setup has been working fine since the last many years with no issues at all. Since the last few days the connection has broken as mentioned earlier. Now we also tried to initiate a sync between C and D (DR servers) which are in the same subnet. But still it is not syncing and we get a "no connection" error message in the logs after trying for 2-3 hrs. Can you please suggest what can be done here. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9928] New: ldap_search_ext_s always hangs on 2.6.3
by openldap-its＠openldap.org 12 Oct '22

12 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9928 Issue ID: 9928 Summary: ldap_search_ext_s always hangs on 2.6.3 Product: OpenLDAP Version: 2.6.3 Hardware: All OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: filipe.custodio(a)gmail.com Target Milestone: --- Created attachment 920 --> https://bugs.openldap.org/attachment.cgi?id=920&action=edit Minimal AD query that consistently hangs on ldap_search_ext_s call Dear Experts, When using ldap_search_ext_s() from libldap v2.6.3 to do a simple search on our production Windows Domain Controller, the client consistently hangs forever. Using ldap_search_ext() & ldap_result() also hangs after delivering the first information item. It seems the client is left waiting, not realising no more results are coming from the server. Using the development image from Oct. 9 2022, the ldap_search_ext_s() call works, although it gives an "Operations Error". Shall I deploy the new libldap from the development branch in our production environment to solve this problem or is there another way around the issue? Best regards, Filipe Custódio -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9919] New: The use of a separate section for cold code can cause linking issues on macOS
by openldap-its＠openldap.org 03 Oct '22

03 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9919 Issue ID: 9919 Summary: The use of a separate section for cold code can cause linking issues on macOS Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: mh-bcrayqnc(a)glandium.org Target Milestone: --- See e.g. https://github.com/llvm/llvm-project/issues/52767 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9365] New: Mem leaks with Æ-DIR providers
by openldap-its＠openldap.org 03 Oct '22

03 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9365 Issue ID: 9365 Summary: Mem leaks with Æ-DIR providers Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- Created attachment 772 --> https://bugs.openldap.org/attachment.cgi?id=772&action=edit valgrind output on openSUSE Tumbleweed x86_64 An Æ-DIR installation with self-compiled OpenLDAP 2.4.53 on Debian (now buster) has memory leak issues on the Æ-DIR providers. The read-only consumers do not have this issue. The provider config is more complex with more overlays and more ACLs. In this production deployment slapd is automatically restarted (by monit) when memory consumption reaches 80%. Thus monitoring clearly shows a frequent saw tooth pattern. I've also tested on openSUSE Tumbleweed x86_64 with a RE24 build [1] by running slapd under control of valgrind for a couple of minutes continously sending simple bind operations (additional to the monitoring and other back-ground jobs running). Find valgrind output of my first attempt attached. Does that make sense at all? -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9923] New: extensible match ignored
by openldap-its＠openldap.org 28 Sep '22

28 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9923 Issue ID: 9923 Summary: extensible match ignored Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: francois(a)rcdevs.com Target Milestone: --- Hi, I'm trying to use a matching rule with slapd as a proxy in front of Active Directory with back-ldap The request is something similar to '(memberOf:1.2.840.113556.1.4.1941:=cn=gp1,o=Root)' It works if I use it directly on AD. Unfortunately, the request is ignored by slapd and not forwarded, I receive a "success" but the result is empty. The request is forwarded if I use something like this: '(memberOf=cn=gp1,o=Root)' Could it be possible to forward the request to the backend? slapd doesn't need to understand the meaning of the OID. slapd with matching rule: [2022-09-28 11:07:39] begin get_filter [2022-09-28 11:07:39] EXTENSIBLE [2022-09-28 11:07:39] daemon: activity on 1 descriptor [2022-09-28 11:07:39] end get_filter 0 [2022-09-28 11:07:39] filter: (?=undefined) [2022-09-28 11:07:39] attrs: dn [2022-09-28 11:07:39] conn=1000 op=1 SRCH base="o=root" scope=2 deref=0 filter="(?=undefined)" slapd without matching rule: [2022-09-28 11:07:47] begin get_filter [2022-09-28 11:07:47] EQUALITY [2022-09-28 11:07:47] get_ava: unknown attributeType memberOf [2022-09-28 11:07:47] [2022-09-28 11:07:47] end get_filter 0 [2022-09-28 11:07:47] daemon: epoll: listen=7 active_threads=0 tvp=NULL [2022-09-28 11:07:47] daemon: epoll: listen=8 active_threads=0 tvp=NULL [2022-09-28 11:07:47] filter: (?memberOf=cn=gp1,o=Root) [2022-09-28 11:07:47] attrs: dn [2022-09-28 11:07:47] conn=1001 op=1 SRCH base="o=root" scope=2 deref=0 filter="(?memberOf=cn=gp1,o=Root)" searchrequest dump: 0000 30 56 02 01 02 63 51 04 06 6f 3d 72 6f 6f 74 0a 0V...cQ..o=root. 0010 01 02 0a 01 00 02 01 00 02 01 00 01 01 00 a9 32 ...............2 0020 81 17 31 2e 32 2e 38 34 30 2e 31 31 33 35 35 36 ..1.2.840.113556 0030 2e 31 2e 34 2e 31 39 34 31 82 08 6d 65 6d 62 65 .1.4.1941..membe 0040 72 4f 66 83 0d 63 6e 3d 67 70 31 2c 6f 3d 52 6f rOf..cn=gp1,o=Ro 0050 6f 74 30 04 04 02 64 6e ot0...dn -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9878] New: test043 failures in 2.5/2.6
by openldap-its＠openldap.org 26 Sep '22

26 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9878 Issue ID: 9878 Summary: test043 failures in 2.5/2.6 Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- With test043 update for ITS#9823, we manage to introduce a scenario where the server is completely idle except for a runqueue change. This is partly identical with ITS#9642 and a similar approach would work. Except that changes our module facing ABI so might not be something we can backport. For the streams we can't, we might have to change the test to make the server not idle. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9922] New: Uninitialized value reading in clients/tools/common.c:tool_bind()
by openldap-its＠openldap.org 26 Sep '22

26 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9922 Issue ID: 9922 Summary: Uninitialized value reading in clients/tools/common.c:tool_bind() Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- One possible flow in https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/comm… is: int err; if ( result ) { rc = ldap_parse_result( ld, result, &err, &matched, &info, &refs, &ctrls, 1 ); if ( rc != LDAP_SUCCESS ) { tool_perror( "ldap_bind parse result", rc, NULL, matched, info, refs ); tool_exit( ld, LDAP_LOCAL_ERROR ); } } if ( err != LDAP_SUCCESS … When result is NULL, err is not initialized, and the last line reads uninitialized value. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9030] Use sys/cachectl.h rather than asm/cachectl.h on mips
by openldap-its＠openldap.org 26 Sep '22

26 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9030 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |0.9.30 --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE0.9: • 4bb20ed0 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9030] Use sys/cachectl.h rather than asm/cachectl.h on mips
by openldap-its＠openldap.org 23 Sep '22

23 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9030 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- patched in mdb.master ; mdb.master3 ; mdb.RE/0.9 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9918] New: Can't log on git.openldap.org
by openldap-its＠openldap.org 22 Sep '22

22 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9918 Issue ID: 9918 Summary: Can't log on git.openldap.org Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: mh-bcrayqnc(a)glandium.org Target Milestone: --- Followup for https://github.com/LMDB/lmdb/pull/23#issuecomment-1254532527. I created the account in February, apparently, with login glandium, but I'm not sure what email. Presumably the one from this bugzilla account. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9524] New: Removing last entry in database triggers MDB_PROBLEM
by openldap-its＠openldap.org 21 Sep '22

21 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9524 Issue ID: 9524 Summary: Removing last entry in database triggers MDB_PROBLEM Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- With a fresh database, if you have have an open read transaction, and you create a new entry in a write transaction and commit it, and then create a new transaction and delete that entry, when you commit, it will return an MDB_PROBLEM from approximately line 4408 from the mt_loose_count/dirty_list check. This seems to occur on mdb.master3, but not mdb.master. Here is a minimal example/test-case of how to reproduce: MDB_env* env; mdb_env_create(&env); int rc, flags = 0; mdb_env_open(env, "test", flags, 0664); MDB_txn* readonly_txn; mdb_txn_begin(env, nullptr, MDB_RDONLY, &readonly_txn); MDB_txn* txn; MDB_dbi dbi; mdb_txn_begin(env, nullptr, 0, &txn); mdb_dbi_open(txn, nullptr, MDB_CREATE, &dbi); MDB_val val; val.mv_data = (void*) "test"; val.mv_size = 4; mdb_put(txn, dbi, &val, &val, 0); mdb_txn_commit(txn); mdb_txn_begin(env, nullptr, 0, &txn); mdb_del(txn, dbi, &val, nullptr); rc = mdb_txn_commit(txn); // this returns MDB_PROBLEM (let me know if this should be submitted differently) -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9910] New: undefined MDB_FDATASYNC in mdb.master3 on macOs
by openldap-its＠openldap.org 21 Sep '22

21 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9910 Issue ID: 9910 Summary: undefined MDB_FDATASYNC in mdb.master3 on macOs Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: info(a)parlepeuple.fr Target Milestone: --- Created attachment 912 --> https://bugs.openldap.org/attachment.cgi?id=912&action=edit patch I am using the mdb.master3 branch which contains the encryption codebase. While testing on macOS, compilation fails with "undefined MDB_FDATASYNC" This is because commit #d85fe32 https://git.openldap.org/openldap/openldap/-/commit/d85fe32dab55b88cec25fc7… introduced a bug in the sense that the #elif on line 167 is not executed if the previous #elif is true. So when defined(__APPLE__) && !defined(MDB_USE_ROBUST) is true, the following #elif is skipped. But this seconf @elif is essential, as it defines MDB_FDATASYNC Proposed patch: --- libraries/liblmdb/mdb.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 5bdec70..b54c8ae 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -164,9 +164,10 @@ typedef SSIZE_T ssize_t; #if defined(__FreeBSD__) && defined(__FreeBSD_version) && __FreeBSD_version >= 1100110 # define MDB_USE_POSIX_MUTEX 1 # define MDB_USE_ROBUST 1 -#elif defined(__APPLE__) && !defined(MDB_USE_ROBUST) -# define MDB_USE_POSIX_SEM 1 #elif defined(__APPLE__) || defined (BSD) || defined(__FreeBSD_kernel__) +# if defined(__APPLE__) && !defined(MDB_USE_ROBUST) +# define MDB_USE_POSIX_SEM 1 +# endif # if !(defined(MDB_USE_POSIX_MUTEX) || defined(MDB_USE_POSIX_SEM)) # define MDB_USE_SYSV_SEM 1 # endif -- -- You are receiving this mail because: You are on the CC list for the issue.

1 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs