- openldap-bugs - openldap.org

[Issue 9920] New: MDB_PAGE_FULL with master3 (encryption) because there is no room for the authentication data (MAC)
by openldap-its＠openldap.org 25 Oct '24

25 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9920 Issue ID: 9920 Summary: MDB_PAGE_FULL with master3 (encryption) because there is no room for the authentication data (MAC) Product: LMDB Version: unspecified Hardware: x86_64 OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: info(a)parlepeuple.fr Target Milestone: --- Created attachment 915 --> https://bugs.openldap.org/attachment.cgi?id=915&action=edit proposed patch Hello, on master3, using the encryption at rest feature, I am testing as follow: - on a new named database, i set the encryption function with mdb_env_set_encrypt(env, encfunc, &enckey, 32) - note that I chose to have a size parameter (The size of authentication data in bytes, if any. Set this to zero for unauthenticated encryption mechanisms.) of 32 bytes. - I add 2 entries on the DB, trying to saturate the first page. I chose to add a key of 33 Bytes and a value of 1977 Bytes, so the size of each node is 2010 Bytes (obviously the 2 keys are different). - This passes and the DB has just one leaf_pages, no overflow_pages, no branch_pages, an a depth of 1. - If I add one byte to the values I insert (starting again from a blank DB), then , instead of seeing 2 overflow_pages, I get an error : MDB_PAGE_FULL. - this clearly should not have happened. - Here is some tracing : add to leaf page 2 index 0, data size 48 key size 7 [74657374646200] add to leaf page 3 index 0, data size 1978 key size 33 [000000000000000000000000000000000000000000000000000000000000000000] add to branch page 5 index 0, data size 0 key size 0 [null] add to branch page 5 index 1, data size 0 key size 33 [000000000000000000000000000000000000000000000000000000000000000000] add to leaf page 4 index 0, data size 1978 key size 33 [000000000000000000000000000000000000000000000000000000000000000000] add to leaf page 4 index 1, data size 1978 key size 33 [020202020202020202020202020202020202020202020202020202020202020202] not enough room in page 4, got 1 ptrs upper-lower = 2020 - 2 = 2016 node size = 2020 Looking at the code, I understand that there is a problem at line 9005 : } else if (node_size + data->mv_size > mc->mc_txn->mt_env->me_nodemax) { where me_nodemax is incorrect, as it is not taking into account that some bytes will be needed for the MAC authentication code, which size is in env->me_esumsize. me_nodemax is calculated at line 5349: env->me_nodemax = (((env->me_psize - PAGEHDRSZ ) / MDB_MINKEYS) & -2) - sizeof(indx_t); So I substract me_esumsize with a "- env->me_esumsize" here: env->me_nodemax = (((env->me_psize - PAGEHDRSZ - env->me_esumsize) / MDB_MINKEYS) & -2) - sizeof(indx_t); I also substract it from me_maxfree_1pg in the line above, and in pmax in line 10435. I do not know if my patch is correct, but it solves the issue. Maybe there are other places in the code where the me_esumsize should be substracted from the available size. By example, when calculating the number of overflow pages in OVPAGES, it does not take into account me_esumsize, but I think it is ok, because there is only one MAC for the entire set of OV pages, and there is room for it in the first OV page. See the attached proposed patch. -- You are receiving this mail because: You are on the CC list for the issue.

1 40

[Issue 9596] New: Python test suite
by openldap-its＠openldap.org 24 Oct '24

24 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9596 Issue ID: 9596 Summary: Python test suite Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- The bash test suite is extremely limited, hard to write for and slow. We can't lose it as it is also portable, but something should be introduced for developers/CI on more modern systems and increase coverage. A Python 3 seed for one is in development in MR!347. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 8149] nssov loginStatus doesn't play well with replication
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

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

1 0

[Issue 9982] New: Linker error when building with LDAP_CONNECTIONLESS
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9982 Issue ID: 9982 Summary: Linker error when building with LDAP_CONNECTIONLESS Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: invokesus+openldap(a)gmail.com Target Milestone: --- Created attachment 942 --> https://bugs.openldap.org/attachment.cgi?id=942&action=edit Build log I'm encountering the following linker error when building from the master branch, with LDAP_CONNECTIONLESS defined. /nix/store/jbnmj9fljgnfyc1iswnrpfhlkpnnwiii-binutils-2.39/bin/ld: ./.libs/libldap.so: undefined reference to `ber_sockbuf_io_udp' Seems to have been happening since https://git.openldap.org/openldap/openldap/-/commit/4a87d7aad200aaa91cb0cb8…. Attaching the full build log. Also, attaching in the next update, a patch to fix the error. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 8070] test023 failures
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=8070 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9596 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8677] back-sock segfaults on CONTINUE (database sock)
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

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

1 0

[Issue 8677] back-sock segfaults on CONTINUE (database sock)
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=8677 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 66edd345 by Howard Chu at 2023-11-14T17:02:18+00:00 ITS#8677 back-sock: return error for CONTINUE -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5738] back-monitor: registering a new backend (via moduleload) should add the corresponding entry in cn=monitor
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

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

1 0

[Issue 10273] New: Unable to run multiple bitnami openldap containers with common shared volume
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10273 Issue ID: 10273 Summary: Unable to run multiple bitnami openldap containers with common shared volume Product: OpenLDAP Version: 2.6.0 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: jvishwanath66(a)gmail.com Target Milestone: --- **Name and Version:** openldap2.6 **What architecture are you using?:** amd64 **What steps will reproduce the bug?** - Add custom ldif files under the /ldifs directory and create another container image named `localhost:32000/custom-openldap` - create a common directory that will be mounted to all the ldap containers (`/root/openldap`) Create multiple container images which are mounted to the same directory (`/root/openldap`) using the following command - Add custom ldif files under the /ldifs directory and create another container image named localhost:32000/custom-openldap - create a common directory that will be mounted to all the ldap containers (`/root/openldap`) Create multiple container images which are mounted to the same directory (`/root/openldap`) using the following command ``` docker run -d -e BITNAMI_DEBUG="true" -e LDAP_ADMIN_USERNAME="superuser" -e LDAP_BINDDN="cn=ldap_bind_user,ou=people,dc=example,dc=com" -e LDAP_ENABLE_TLS="no" -e LDAP_EXTRA_SCHEMAS="cosine,general-acl,my-permissions,my-roles,ppolicy,nis,inetorgperson" -e LDAP_ROOT="dc=example,dc=com" -e LDAP_SKIP_DEFAULT_TREE="yes" -e LDAP_URI="ldap://ldap-server-service.my-namespace.svc.cluster.local" -e USER_DESCRIPTION_MAX_LEN="100" -e USER_FIRST_AND_LAST_NAME_MAX_LEN="100" -e USER_NAME_MAX_LEN="100" -e LDAP_ADMIN_PASSWORD="admin123" -e LDAP_READONLY_USER_PASSWORD="admin123" -e proxyBindPassword="" -v /root/openldap:/bitnami/openldap localhost:32000/custom-openldap ``` - List container images using the docker ps command: ``` docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f77ef5455f5f localhost:32000/custom-openldap "/opt/bitnami/script…" 2 minutes ago Up 2 minutes 1389/tcp, 1636/tcp upbeat_raman 9cccd41f02d2 localhost:32000/custom-openldap "/opt/bitnami/script…" 17 minutes ago Up 17 minutes 1389/tcp, 1636/tcp nostalgic_antonelli 5434761c9281 localhost:32000/custom-openldap "/opt/bitnami/script…" 23 minutes ago Up 23 minutes 1389/tcp, 1636/tcp objective_mayer ca40ef1a68a2 localhost:32000/custom-openldap "/opt/bitnami/script…" 26 minutes ago Up 26 minutes 1389/tcp, 1636/tcp angry_margulis ``` - Execute the following ldapsearch command in all the containers ``` ldapsearch -H ldap://localhost:1389 -b "dc=example, dc=com" -D "cn=superuser,dc=example,dc=com" -w admin123 ``` **What is the expected behavior?** The expected behavior is that ldapsearch should work on all the pods correctly **What do you see instead?** Ldapsearch is working on one container image whereas on other container images, we see the following error ``` $ ldapsearch -H ldap://localhost:1389 -b "dc=example, dc=com" -D "cn=superuser,dc=example,dc=com" -w admin123 # extended LDIF # # LDAPv3 # base <dc=example, dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 80 Other (e.g., implementation specific) error text: internal error # numResponses: 1 ``` I wanted to know whether it is feasible/possible to use the same mount point for multiple openldap containers. **Additional information** Following is the list of container images ``` $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f77ef5455f5f localhost:32000/custom-openldap "/opt/bitnami/script…" 2 minutes ago Up 2 minutes 1389/tcp, 1636/tcp upbeat_raman 9cccd41f02d2 localhost:32000/custom-openldap "/opt/bitnami/script…" 17 minutes ago Up 17 minutes 1389/tcp, 1636/tcp nostalgic_antonelli 5434761c9281 localhost:32000/custom-openldap "/opt/bitnami/script…" 23 minutes ago Up 23 minutes 1389/tcp, 1636/tcp objective_mayer ca40ef1a68a2 localhost:32000/custom-openldap "/opt/bitnami/script…" 26 minutes ago Up 26 minutes 1389/tcp, 1636/tcp angry_margulis ``` And following is the ldapsearch output on all the containers: f77ef5455f5f ``` $ docker exec -it f77ef5455f5f bash $ ldapsearch -H ldap://localhost:1389 -b "dc=example, dc=com" -D "cn=superuser,dc=example,dc=com" -w admin123 # extended LDIF # # LDAPv3 # base <dc=example, dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 80 Other (e.g., implementation specific) error text: internal error # numResponses: 1 ``` 9cccd41f02d2: ``` $ ldapsearch -H ldap://localhost:1389 -b "dc=example, dc=com" -D "cn=superuser,dc=example,dc=com" -w admin123 # extended LDIF # # LDAPv3 # base <dc=example, dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 80 Other (e.g., implementation specific) error text: internal error # numResponses: 1 ``` 5434761c9281: ``` $ ldapsearch -H ldap://localhost:1389 -b "dc=example, dc=com" -D "cn=superuser,dc=example,dc=com" -w admin123 # extended LDIF # # LDAPv3 # base <dc=example, dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # example.com dn: dc=example,dc=com objectClass: top objectClass: domain dc: example # groups, example.com dn: ou=groups,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: groups ``` - ca40ef1a68a2 (Somehow LDAP bind failed on this container, there seems to be some environmental issue) ```$ ldapsearch -H ldap://localhost:1389 -b "dc=example, dc=com" -D "cn=superuser,dc=example,dc=com" -w admin123 ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)``` -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 8047] TIMEOUT and NETWORK_TIMEOUT don't work properly with SSL
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=8047 --- Comment #13 from maxime.besson(a)worteks.com <maxime.besson(a)worteks.com> --- Hi Ondřej, your patch worked for me, TLS handshake timeout was properly applied in all (synchronous) combinations of: * unreachable network / unresponsive service * OpenSSL / GnuTLS * ldaps:// / ldap:// + StartTLS Thanks! -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9042] loglevel setting that allows seeing attribute values for MOD operations
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9042 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1 --- Comment #2 from Ondřej Kuzník <ondra(a)mistotebe.net> --- https://git.openldap.org/openldap/openldap/-/merge_requests/728 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8047] TIMEOUT and NETWORK_TIMEOUT don't work properly with SSL
by openldap-its＠openldap.org 21 Oct '24

21 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=8047 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net --- Comment #12 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Hi Maxine/Allen, can you try MR!727 linked below and tell us if this fixes your issues? https://git.openldap.org/openldap/openldap/-/merge_requests/727 It would be helpful if people setting LDAP_BOOL_CONNECT_ASYNC could also confirm this doesn't cause regressions for them. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8047] TIMEOUT and NETWORK_TIMEOUT don't work properly with SSL
by openldap-its＠openldap.org 17 Oct '24

17 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=8047 --- Comment #11 from maxime.besson(a)worteks.com <maxime.besson(a)worteks.com> --- Hi, I understand that fixing timeouts during SSL handshake is not possible in the current state of SSL libraries, but I would like to report what seems to me like a regression in OpenLDAP 2.5/2.6 On my RHEL7 and RHEL8 systems ( OpenLDAP 2.4 built with OpenSSL), I was somehow not able to reproduce the issue mentioned here: NETWORK_TIMEOUT works for ldaps:// URLs and TIMEOUT works for ldap:// URLS + StartTLS In OpenLDAP 2.4.49 + GnuTLS (Ubuntu Focal), NETWORK_TIMEOUT does not work for ldaps:// URLs but TIMEOUT works for StartTLS However starting with 2.5 (Debian Bookworm, RHEL9, and also reproduced with a source build of OPENLDAP_REL_ENG_2_6 as well), I observe a different behavior, affecting both GnuTLS and OpenSSL: The following command enters the CPU loop reported in ITS#10141, and never times out > ldapsearch -H ldaps://stuck-slapd -o network_timeout=5 The following command still times out as expected > ldapsearch -H ldap://stuck-slapd -Z -o timeout=5 To clarify, users of OpenLDAP + OpenSSL will start noticing a large CPU spike that does not timeout, instead of a clean timeout, when a LDAP server becomes unreachable for non-TCP reasons. For instance: I discovered this issue while investigating an outage following a storage issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9356] New: Add list of peerSIDs to consumer cookie to reduce cross traffic
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9356 Issue ID: 9356 Summary: Add list of peerSIDs to consumer cookie to reduce cross traffic Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- If we add a list of peersids to the cookie, each consumer can tell the providers who else the consumers talk to and then the provider can omit sending updates to that consumer, originating from those peers There's some special handling needed if a connection dies If a consumer loses one of its peer connections, and after N retries is still not connected, it should send a new cookie to its remaining peers saying "here's my new peer list" with the missing one removed. Likewise, if a retry eventually connects again, it can send a new cookie again Make that peer list reset configurable in the syncrepl config stanza. This can help account for end admin knowledge that some links may be more or less stable than other ones. The idea here is that if one of your other peers can still see the missing peer, they can start routing updates to you again It should abandon all existing persist sessions and send a new sync search with the new cookie to all remaining peers For consumer side, also means adding the sid for a given provider into the syncrepl stanza to save on having to try and discover the peer sid. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Bug 9219] New: Streamline tool API for 2.5
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9219 Bug ID: 9219 Summary: Streamline tool API for 2.5 Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The current tool API is a mess and needs fixing for 2.5. This affects things like slapacl (The fix for bug#7920 was a kludge to deal with this, needs revisiting). -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Issue 7920] MDB_BAD_RSLOT while executing slapacl
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=7920 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9219 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9080] Feature request: support DNS SRV lookups in ldap.conf
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

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

1 0

[Issue 5919] URI syntaxe (ldap:///dc=my%2cdc=domaine)
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=5919 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=7027 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7027] [PATCH] Implement priority/weight for DNS SRV records
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=7027 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=5919 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5919] URI syntaxe (ldap:///dc=my%2cdc=domaine)
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=5919 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=8204 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8204] rfc2782 shuffle implementation doesn't treat equal-weight records equally
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=8204 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=5919 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5919] URI syntaxe (ldap:///dc=my%2cdc=domaine)
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=5919 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=6462 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6462] DNS SRV records: ldaps ???
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=6462 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=5919 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9080] Feature request: support DNS SRV lookups in ldap.conf
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9080 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** This issue has been marked as a duplicate of issue 5919 *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5919] URI syntaxe (ldap:///dc=my%2cdc=domaine)
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=5919 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gray(a)nxg.name --- Comment #33 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** Issue 9080 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs