- openldap-bugs - openldap.org

[Issue 9644] New: provide a man page for ppm
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9644 Issue ID: 9644 Summary: provide a man page for ppm Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Provide a man page for ppm proposed PR is coming -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9648] New: 'MAXPATHLEN' undeclared on some systems
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9648 Issue ID: 9648 Summary: 'MAXPATHLEN' undeclared on some systems Product: OpenLDAP Version: 2.5.4 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: git(a)freundtech.com Target Milestone: --- Created attachment 834 --> https://bugs.openldap.org/attachment.cgi?id=834&action=edit Docker reproduction I'm trying to compile OpenLDAP 2.5.7 on Alpine Linux, but have verified that the problem exists since 2.5.4. Version 2.4.59 compiles correctly with everything else equal. Compilation fails with In file included from ldap-int.h:119, from request.c:53: request.c: In function 'ldap_dump_connection': ../../include/ldap_pvt.h:181:25: error: 'MAXPATHLEN' undeclared (first use in this function) 181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH=")) | ^~~~~~~~~~ request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN' 859 | char from[LDAP_IPADDRLEN]; | ^~~~~~~~~~~~~~ ../../include/ldap_pvt.h:181:25: note: each undeclared identifier is reported only once for each function it appears in 181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH=")) | ^~~~~~~~~~ request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN' 859 | char from[LDAP_IPADDRLEN]; | ^~~~~~~~~~~~~~ make[2]: Leaving directory '/tmp/openldap/libraries/libldap' Thanks to JoBbZ on IRC I found out that including <ac/param.h> in ldap_pvt.h seems to fix the issue. My best guess as to why this fails on Alpine Linux and not on other distributions is that Alpine uses musl instead of glibc as it's libc implementation. I have attacked an (unfinished) dockerfile for reproduction of the issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 17

[Issue 9712] New: back-mdb multival delete isn't deleting
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9712 Issue ID: 9712 Summary: back-mdb multival delete isn't deleting Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When deleting an entry that has multival-related attributes, those attribute values weren't getting deleted. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9631] New: slapd-wt tests often fail/timeout
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9631 Issue ID: 9631 Summary: slapd-wt tests often fail/timeout Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Since merging wt into master, tests started to fail ~80-90% of the time, partly due to bugs in wt (https://git.openldap.org/openldap/openldap/-/jobs/8458) or timeouts in CI. I am about to remove the backend from make test for now (keeping it in alltests), opening this issue to discuss further. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9463] New: back-wt: cumulative fix
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9463 Issue ID: 9463 Summary: back-wt: cumulative fix Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- Hi, This is cumulative fix for back-wt. I'm sorry to making 2.5 patch has been delayed due to we're still using 2.4. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 7335] Create process for updating man pages to handle both cn=config and slapd.conf configurations
by openldap-its＠openldap.org 07 Oct '21

07 Oct '21

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

1 0

[Issue 6097] MMR problems with deletes
by openldap-its＠openldap.org 07 Oct '21

07 Oct '21

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

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 05 Oct '21

05 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #22 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE26: • ce073522 by Ondřej Kuzník at 2021-10-05T01:42:43+00:00 ITS#6949 Fix and emit error messages • 15ac53a7 by Ondřej Kuzník at 2021-10-05T01:42:48+00:00 ITS#6949 Remove dead code from lloadd • 466e0321 by Ondřej Kuzník at 2021-10-05T01:42:52+00:00 ITS#6949 Port rest of the features to lloadd -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 05 Oct '21

05 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=6949 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |TEST --- Comment #21 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • a3dea08c by Ondřej Kuzník at 2021-10-04T14:46:22+01:00 ITS#6949 Fix and emit error messages • 8894f00f by Ondřej Kuzník at 2021-10-04T14:46:26+01:00 ITS#6949 Remove dead code from lloadd • 3c07544b by Ondřej Kuzník at 2021-10-04T14:46:26+01:00 ITS#6949 Port rest of the features to lloadd -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 04 Oct '21

04 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #20 from Ondřej Kuzník <ondra(a)mistotebe.net> --- I would also note that there's a fair amount of fprintf( stderr, ... ) peppered around the code, that might also need cleaning up at some point. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9692] New: Insertion rate in large groups slows unexpectedly
by openldap-its＠openldap.org 04 Oct '21

04 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9692 Issue ID: 9692 Summary: Insertion rate in large groups slows unexpectedly Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Created attachment 843 --> https://bugs.openldap.org/attachment.cgi?id=843&action=edit slapd.conf Observed during jmeter tests[1] that perform ldapmod operations, adding members into a group. The insertion speed decreases unexpectedly, as the size of the group increases. A test run starts 10 jmeter threads, each doing 1000 mods = 100,000 members added altogether to a group. At the beginning of the test, throughput is approximately 200/s. At the end, the mod rate slows down to < 10/s. Multival and sortval are enabled (slapd.conf attached): sortvals member multival member 500,3 *** Server info Ubuntu20 2 CPU Cores 4GB RAM symas-openldap-server 2.5.7-1focal1 *** To verify multival is enabled: ``` data/dc=example,dc=com# mdb_stat -s id2v . Status of id2v Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 746316 ``` [1][ldap-load-gen](https://gitlab.symas.net/symas-public/ldap-load-gen) -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9639] New: slapd -r : what must be present in the chroot environment
by openldap-its＠openldap.org 01 Oct '21

01 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9639 Issue ID: 9639 Summary: slapd -r : what must be present in the chroot environment Product: OpenLDAP Version: 2.4.59 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- `man slapd` - https://www.openldap.org/software/man.cgi?query=slapd&apropos=0&sektion=0&m… - says that the -r option calls chroot. Please clarify, what must be present in the chroot environment: /proc, /tmp, /dev/shm , libc -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 30 Sep '21

30 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #19 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 66c62841 by Howard Chu at 2021-09-30T04:23:29+01:00 ITS#6949 fixup loglevel delete, consolidate redundant code RE26: • e2739d9f by Howard Chu at 2021-09-30T15:32:11+00:00 ITS#6949 fixup loglevel delete, consolidate redundant code -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9156] latest ppolicy draft support
by openldap-its＠openldap.org 30 Sep '21

30 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9156 --- Comment #15 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: commit 4cd096defffc278f13edf9a194f4bc62095a947e Author: Ondřej Kuzník <ondra(a)mistotebe.net> Date: Mon Jun 7 15:52:25 2021 +0100 ITS#9156 Do not spam the logs on account of lastbind Re25: • 667ea288 by Ondřej Kuzník at 2021-09-30T16:02:34+00:00 ITS#9156 Do not spam the logs on account of lastbind -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9710] New: integrated lastbind debug statement at ANY level
by openldap-its＠openldap.org 30 Sep '21

30 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9710 Issue ID: 9710 Summary: integrated lastbind debug statement at ANY level Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For some reason, a debug statement for the newly integrated lastbind code is logging at ANY level, which seems incorrect: Debug( LDAP_DEBUG_ANY, "fe_op_lastbind: " "old pwdLastSuccess value=%s %lds ago\n", a->a_nvals[0].bv_val, bindtime == (time_t)-1 ? -1 : op->o_time - bindtime ); This results in log lines with every bind like: Sep 30 01:41:42 ub18 slapd[5980]: fe_op_lastbind: old pwdLastSuccess value=20210930014121Z 21s ago I think a different loglevel should be in use here. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9156] latest ppolicy draft support
by openldap-its＠openldap.org 30 Sep '21

30 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9156 --- Comment #14 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** Issue 9710 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 29 Sep '21

29 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #18 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: Commits: • 10fb8c0a by Howard Chu at 2021-09-29T14:39:28+01:00 ITS#6949 fix logfile_only regression in prev commit RE26: Commits: • 74d1475a by Howard Chu at 2021-09-29T21:29:15+00:00 ITS#6949 fix logfile_only regression in prev commit -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9708] New: null (empty) attribute values of type Directory String pass the dry-run validation
by openldap-its＠openldap.org 29 Sep '21

29 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9708 Issue ID: 9708 Summary: null (empty) attribute values of type Directory String pass the dry-run validation Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: mheyman(a)symas.com Target Milestone: --- On behalf of Aaron Bliss at Paychex ---- I'm pretty confident that I've identified a bug when running slapadd with the dry-run switch. As a step of migrating a given replica set from oDSEE to OpenLDAP, we of course make use of the dry-run switch after sanitizing a given oDSEE export. However on a few migrations I've noticed that null (empty) attribute values of type Directory String (which are illegal per the RFC) pass the dry-run validation. This becomes really problematic because a subsequent slapadd in which the quick switch is passed will load the invalid data into the database. I understand that loading a given ldif using the quick switch performs fewer consistency checks on the input data however with our largest dataset's, it's not viable for us to migrate a given replica set from oDSEE to OpenLDAP without using the quick switch (it would require an outage that's far longer than we can allow for on the customer side of things). It makes total sense for sure that OpenLDAP will not allow for null values for this attribute type in keeping with the standard but unfortunately oDSEE allows for it as such we have to account for it. Would it be possible to catch the null attribute value scenario when performing a dry run and if so is there any way this could be prioritized (doing so would be of tremendous help to us)? If not then I'll have to write my own validation (not at all ideal) to check for this scenario but for sure would be better if slapadd can catch this condition. Thanks much as always. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 27 Sep '21

27 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #17 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE26: • c23c6563 by Howard Chu at 2021-09-27T19:20:18+00:00 ITS#6949 honor specified loglevel, not just debuglevel -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 27 Sep '21

27 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|hyc(a)openldap.org |ondra(a)mistotebe.net --- Comment #16 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Assigning to Ondrej for the load balancer portion -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 27 Sep '21

27 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #15 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 77adb192 by Howard Chu at 2021-09-27T16:54:24+00:00 ITS#6949 honor specified loglevel, not just debuglevel But skip calls to syslog() if logfile_only is set. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9709] New: Invalid link for Symas website
by openldap-its＠openldap.org 27 Sep '21

27 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9709 Issue ID: 9709 Summary: Invalid link for Symas website Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The Symas website link in the powered by portion is invalid. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9705] New: synprov put add info into wrong cookie while performing test059-consumer-config
by openldap-its＠openldap.org 27 Sep '21

27 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9705 Issue ID: 9705 Summary: synprov put add info into wrong cookie while performing test059-consumer-config Product: OpenLDAP Version: 2.4.59 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: gil77for(a)gmail.com Target Milestone: --- There is an issue with syncrepl and syncprov working together in parallel. The issue can be seen in provider LDAP server logs of test059-consumer-config. For linux this problem does not cause the test to malfunction, but it may cause replication to malfunction on other systems (or possibly on linux in a different situation from the test). In case of OpenVMS we have this issue. The problem is detected under the following circumstances, followed by a step-by-step description of the actions in test 059 that lead to malfunction: 1. Adding replication configuration for the dn: olcDatabase={1}ldif,cn=config dn: olcDatabase={1}ldif,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: {0}rid=001 provider=ldap://localhost:9001/ binddn="cn=config" bindmethod=simple credentials=******** searchbase="cn=schema,cn=config" type=refreshAndPersist retry="3 5 300 5" timeout=3 suffixmassage="cn=schema,cn=config,cn=consumer" this registers a syncInfo structure with the parameter rid=001 inside the syncrepl engine. the corresponding syncCookie and cookieState are also created inside this structure 2. adding includes by ldapadd to the configuration, this causes {1}ldif,cn=config to be filled on the provider and register this adding in rid=001 syncInfo cookies with sid=001: include: file:///LDAP$SCHEMA:core.ldif include: file:///LDAP$SCHEMA:cosine.ldif include: file:///LDAP$SCHEMA:inetorgperson.ldif include: file:///LDAP$SCHEMA:openldap.ldif include: file:///LDAP$SCHEMA:nis.ldif 3. Adding replication configuration for the dn: olcDatabase={1}mdb,cn=config,cn=consumer: dn: olcDatabase={1}mdb,cn=config,cn=consumer objectClass: olcDatabaseConfig objectClass: olcmdbConfig olcDatabase: {1}mdb olcSuffix: dc=example,dc=com olcDbDirectory: [.testdir.db_2_a] olcRootDN: cn=Manager,dc=example,dc=com olcRootPW: secret olcSyncRepl: rid=002 provider=ldap://localhost:9001/ binddn="cn=Manager,dc=example,dc=com" bindmethod=simple credentials=secret searchbase="dc=example,dc=com" type=refreshAndPersist retry="3 5 300 5" timeout=3 olcUpdateRef: ldap://localhost:9001/ this registers new syncInfo structure with the parameter rid=002 inside the syncrepl engine. Should also be added info into cookies of this structure but this is the issue. The info about {1}mdb,cn=config,cn=consumer is added to the cookie of structure with rid=001 (!!!). Thus the cookie about {1}ldif is overrides by this new cookie data. It can be seen in provider server logs (was run on linux): …… 61275c7d ldif_back_add: "olcDatabase={1}mdb,cn=config,cn=consumer" 61275c7d oc_check_required entry (olcDatabase={1}mdb,cn=config,cn=consumer), objectClass "olcMdbConfig" …… 61275c7d slap_get_csn: conn=1007 op=3 generated new csn=20210826091853.649104Z#000000#001#000000 manage=1 61275c7d slap_queue_csn: queueing 0x7fcdf4106bc0 20210826091853.649104Z#000000#001#000000 61275c7d ldif_write_entry: wrote entry "olcDatabase={1}mdb,cn=config,cn=consumer" 61275c7d ldif_back_add: err: 0 text: 61275c7d send_ldap_result: conn=1007 op=3 p=3 61275c7d send_ldap_result: err=0 matched="" text="" 61275c7d conn=1007 op=3 syncprov_matchops: recording uuid for dn=olcDatabase={1}mdb,cn=config,cn=consumer on opc=0x7fcdf4001608 …… 61275c7d slap_graduate_commit_csn: removing 0x7fcdf4106bc0 20210826091853.649104Z#000000#001#000000 61275c7d conn=1004 op=1 syncprov_sendresp: cookie=rid=001,sid=001,csn=20210826091853.649104Z#000000#001#000000 61275c7d conn=1004 op=1 syncprov_sendresp: sending LDAP_SYNC_ADD, dn=olcDatabase={1}mdb,cn=config,cn=consumer …… rid=002 should be there! When running on linux, this does not cause a problem for the test, because syncprov task works later than the ldif database replication on consumer by syncrepl task. And the overlapped cookie entry does not matter anymore. In our case (OpenVMS) the order of asynchronous tasks (syncrepl and syncprov) is different and overwriting the cookie leads to loss of ldif database replication and failure of the test. The consumer does not receive scheme data. The differences in the order of tasks are caused by the features of pthreads library implementation for the VMS. But it should not matter for LDAP operation. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9703] New: init_config_ocs: register_oc failed
by openldap-its＠openldap.org 23 Sep '21

23 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9703 Issue ID: 9703 Summary: init_config_ocs: register_oc failed Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: goudal(a)enseirb.fr Target Milestone: --- Hello, I just compiled openldap2.5.7 from source with the following command : ./configure '--enable-overlays' '--enable-crypt' '--with-tls' '--enable-backends' '--with-cyrus-sasl' '--disable-ndb' '--enable-modules' Distribution is Ubuntu20.04 When I start slapd it exits with the error init_config_ocs: register_oc failed With -d -1 flag I got the the following : 6149e48c.212556fe 0x7f20fc933740 wt_back_initialize: initialize WiredTiger backend 6149e48c.21544f14 0x7f20fc933740 wt_back_initialize: WiredTiger 2.9.3: (June 26, 2017) 6149e48c.21558481 0x7f20fc933740 register_oc: objectclass "( OLcfgDbOc:9.1 NAME 'olcWtConfig' DESC 'Wt backend configuration' SUP olcDatabaseConfig MUST olcDbDirectory MAY ( olcWtConfig $ olcDbIndex ) )": Inconsistent duplicate \ objectClass, 1.3.6.1.4.1.4203.1.12.2.4.2.9.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9690] New: 2.5.7: test suite is failing
by openldap-its＠openldap.org 23 Sep '21

23 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9690 Issue ID: 9690 Summary: 2.5.7: test suite is failing Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: kloczko.tomasz(a)gmail.com Target Milestone: --- Created attachment 842 --> https://bugs.openldap.org/attachment.cgi?id=842&action=edit Test suite log Source code configured with below options: %configure \ --disable-debug \ --disable-ndb \ --disable-slp \ --disable-sql \ --disable-wt \ --disable-static \ --enable-backends=mod \ --enable-bdb=yes \ --enable-cleartext \ --enable-crypt \ --enable-dynacl \ --enable-dynamic \ --enable-hdb \ --enable-lmpasswd \ --enable-mdb=yes \ --enable-modules \ --enable-monitor \ --enable-overlays=mod \ --enable-rewrite \ --enable-rlookups \ --enable-slapi \ --enable-spasswd \ --libexecdir=%{_libdir} \ --with-cyrus-sasl \ --with-gnu-ld \ --without-fetch \ --with-pic \ --with-threads \ %{nil} Test suite log is in attachment Please let me know if you need more details or want me to perform some diasgnostics. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs