- openldap-bugs - openldap.org

[Issue 6128] slapd pcache assert
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6128 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |SUSPENDED --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Need reproduction steps, likely fixed. -- 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 03 Jun '21

03 Jun '21

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

1 0

[Issue 5971] back-ldap: Referral chasing is broken
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=5971 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|slapd |backends Summary|Referral chasing is broken |back-ldap: Referral chasing | |is broken -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5971] Referral chasing is broken
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=5971 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Debug mode "fixes" |Referral chasing is broken |authentication issue | -- 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 03 Jun '21

03 Jun '21

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

1 0

[Issue 5582] Default OpenSSL certs are only used when TLS_CACERT(DIR)
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

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

1 0

[Issue 5399] LDAP Syntax 1.3.6.1.4.1.1466.115.121.1.58 (Substring Assertion) not listed in subschema subentry
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=5399 --- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Hi Michael, Do you have an example test case/use case you can provide? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5500] comments in cn=config entries
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

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

1 0

[Issue 5399] LDAP Syntax 1.3.6.1.4.1.1466.115.121.1.58 (Substring Assertion) not listed in subschema subentry
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

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

1 0

[Issue 5344] Wrong check for bad Modify DN
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

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

1 0

[Issue 5335] Update test044 to confirm ACL with "by group.X" clause using a dynamic group functions correctly
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

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

1 0

[Issue 7853] Improve safety of mdb_env_close
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=7853 --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- (In reply to Howard Chu from comment #4) > (In reply to dw(a)hmmz.org from comment #0) > > Full_Name: David Wilson > > Version: LMDB 0.9.11 > > OS: > > URL: > > https://raw.githubusercontent.com/dw/py-lmdb/master/misc/readers_mrb_env. > > patch > > Submission from: (NULL) (178.238.153.20) > > > > > > Currently if a user (wilfully or accidentally, say, through composition of > > third party libs) opens the same LMDB environment twice within a process, and > > maintains active read transactions at the time one mdb_env_close() is called, > > all reader slots will be deallocated in all environments due to the logic > > around line 4253 that unconditionally clears reader slots based on PID. > > > > I'd like to avoid this in py-lmdb, and seems there are a few alternatives to > > fix it: > > > 4) Modify lock.mdb to include MDB_env* address within the process, and update > > mdb_env_close() to invalidate only readers associated with the environment > > being closed. I dislike using the MDB_env* as an opaque publicly visible > > cookie, but perhaps storing this field might be reused for other things in > > future. > > I was looking at this approach, which initially seems harmless. But > unfortunately it does nothing to address the fact the fcntl lock on the > lock file will still go away on the first env_close() call. If there are > no other processes with the env open, then the next process that opens > the env will re-init the lock file, because it doesn't know about the > existing process. At that point the existing process is hosed anyway. Another possibility here is to detect that there were multiple envs for the same PID, and not close the descriptors in that case. This means intentionally leaking a file descriptor, but keeps the locks intact. Still ugly, but not as bad as inviting corruption. And, this would only happen due to a library misuse, so it would still be a rare situation. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9568] New: ldapsearch command not working with ECC certificates
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9568 Issue ID: 9568 Summary: ldapsearch command not working with ECC certificates Product: OpenLDAP Version: 2.4.56 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: adisheshsm(a)gmail.com Target Milestone: --- Hi, ldap server is configured with ECC certificate. ldap server certificates are generated using openssl command. mTLS is enabled on ldap server side. for ldap client ldapsearch purpose, we have tried client certs using RSA and ECC. when server is configured with ECC certs, client is not able to connect to server. please let us know if openldap clients work with ECC certificates (prime256v1 curve). we tried below scenarios: both are not working 1. openldap server and client with ECC certificates 2. openldap server with ECC certificate and client with RSA certificate. we are getting below errors. --------client side details----------------- ---------------------------------------- $ cat ~/.ldaprc TLS_CACERT /tmp/ec_cacert.pem TLS_CERT /tmp/rsa_client.pem TLS_KEY /tmp/rsa_client.key TLS_REQCERT never TLS_PROTOCOL_MIN 3.2 -------------------------------------------------- ## ldapsearch command is failing (with -Z and -ZZ) $ ldapsearch -x -h 10.21.21.2 -p 389 -D "cn=admin" -w 'admin1' -b "uid=001,dc=test1" -Z -d 1 ldap_create ldap_url_parse_ext(ldap://10.21.21.2:389) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 10.21.21.2:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.21.21.2:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x7f94593a6210 msgid 1 wait4msg ld 0x7f94593a6210 msgid 1 (infinite timeout) wait4msg continue ld 0x7f94593a6210 msgid 1 all 1 ** ld 0x7f94593a6210 Connections: * host: 10.21.21.2 port: 389(default) refcnt: 2 status: Connected last used: Thu Jun 3 11:28:26 2021 ** ld 0x7f94593a6210 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x7f94593a6210 request count 1 (abandoned 0) ** ld 0x7f94593a6210 Response Queue: Empty ld 0x7f94593a6210 response count 0 ldap_chkResponseList ld 0x7f94593a6210 msgid 1 all 1 ldap_chkResponseList returns ld 0x7f94593a6210 NULL ldap_int_select read1msg: ld 0x7f94593a6210 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 38 contents: read1msg: ld 0x7f94593a6210 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x7f94593a6210 0 new referrals read1msg: mark request completed, ld 0x7f94593a6210 msgid 1 request done: ld 0x7f94593a6210 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ber_scanf fmt (a) ber: ber_scanf fmt (O) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (x) ber: ber_scanf fmt (x) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS: certdb config: configDir='/etc/openldap/certs' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: using moznss security dir /etc/openldap/certs prefix . TLS: loaded CA certificate file /tmp/ec_cacert.pem. TLS: error: the certificate '/tmp/rsa_client.pem' could not be found in the database - error -8174:security library: bad database.. TLS: certificate '/tmp/rsa_client.pem' successfully loaded from PEM file. TLS: no unlocked certificate for certificate 'CN=ldapclient,OU=test,O=example,L=Banaglore,ST=Karnataka,C=IN'. TLS: certificate [CN=ldapclient,OU=test,O=example,L=Banaglore,ST=Karnataka,C=IN] is valid TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory TLS: error: connect - force handshake failure: errno 21 - moznss error -5938 TLS: can't connect: TLS error -5938:Encountered end of file. ldap_err2string ldap_start_tls: Connect error (-11) additional info: TLS error -5938:Encountered end of file ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 30 bytes to sd 3 ldap_result ld 0x7f94593a6210 msgid 2 wait4msg ld 0x7f94593a6210 msgid 2 (infinite timeout) wait4msg continue ld 0x7f94593a6210 msgid 2 all 1 ** ld 0x7f94593a6210 Connections: * host: 10.21.21.2 port: 389 (default) refcnt: 2 status: Connected last used: Thu Jun 3 11:28:26 2021 ** ld 0x7f94593a6210 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x7f94593a6210 request count 1 (abandoned 0) ** ld 0x7f94593a6210 Response Queue: Empty ld 0x7f94593a6210 response count 0 ldap_chkResponseList ld 0x7f94593a6210 msgid 2 all 1 ldap_chkResponseList returns ld 0x7f94593a6210 NULL ldap_int_select read1msg: ld 0x7f94593a6210 msgid 2 all 1 ber_get_next ldap_err2string ldap_result: Can't contact LDAP server (-1) ldap_free_request (origid 2, msgid 2) ldap_free_connection 1 1 ldap_free_connection: actually freed $ Thanks and regards, Adishesh -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9566] New: OpenLDAP Proxy crashes when idassertauthzfrom is set to dn:*
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9566 Issue ID: 9566 Summary: OpenLDAP Proxy crashes when idassertauthzfrom is set to dn:* Product: OpenLDAP Version: 2.4.56 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nevillem(a)issquaredinc.com Target Milestone: --- Set olcDbIDAssertAuthzFrom to {0}dn:* Set olcDbIDAssertBind when flag is set to prescriptive or non-prescriptive Stop slapd Start slapd - It does not start, errors out. It works when olcDbIDAssertBind has flags set to flags=proxy-authz-non-critical -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 8392] Opening multiple databases from the same process
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=8392 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 8276] [PATCH 2/2] Add an application context pointer into user-defined key compare and dupsort functions
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=8276 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 8010] LMDB: New mdb_txn_begin() flag to init as reset
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=8010 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 8124] Patch "Context for compare functions"
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=8124 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 7980] LMDB added support for user context in compare function
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=7980 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 7842] mdb readers/writer exclusion protocol, as implemented, is racy.
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=7842 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 7969] LMDB: Globally shared fields of meta-data are not 'volatile'.
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=7969 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 8392] Opening multiple databases from the same process
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=8392 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8276] [PATCH 2/2] Add an application context pointer into user-defined key compare and dupsort functions
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=8276 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Howard Chu <hyc(a)openldap.org> --- *** This issue has been marked as a duplicate of issue 7980 *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7980] LMDB added support for user context in compare function
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=7980 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pmedvedev(a)gmail.com --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- *** Issue 8276 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 8010] LMDB: New mdb_txn_begin() flag to init as reset
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=8010 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Howard Chu <hyc(a)openldap.org> --- *** This issue has been marked as a duplicate of issue 8250 *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8250] Allowing transaction to be created in the reset state
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=8250 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |scott(a)gameranger.com --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- *** Issue 8010 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 8124] Patch "Context for compare functions"
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=8124 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- *** This issue has been marked as a duplicate of issue 7980 *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7980] LMDB added support for user context in compare function
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=7980 --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- *** Issue 8124 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 7980] LMDB added support for user context in compare function
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=7980 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Howard Chu <hyc(a)openldap.org> --- Not needed. Pass additional state using the MDB_val *a pointer. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7853] Improve safety of mdb_env_close
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=7853 --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- (In reply to dw(a)hmmz.org from comment #0) > Full_Name: David Wilson > Version: LMDB 0.9.11 > OS: > URL: > https://raw.githubusercontent.com/dw/py-lmdb/master/misc/readers_mrb_env. > patch > Submission from: (NULL) (178.238.153.20) > > > Currently if a user (wilfully or accidentally, say, through composition of > third party libs) opens the same LMDB environment twice within a process, and > maintains active read transactions at the time one mdb_env_close() is called, > all reader slots will be deallocated in all environments due to the logic > around line 4253 that unconditionally clears reader slots based on PID. > > I'd like to avoid this in py-lmdb, and seems there are a few alternatives to > fix it: > 4) Modify lock.mdb to include MDB_env* address within the process, and update > mdb_env_close() to invalidate only readers associated with the environment > being closed. I dislike using the MDB_env* as an opaque publicly visible > cookie, but perhaps storing this field might be reused for other things in > future. I was looking at this approach, which initially seems harmless. But unfortunately it does nothing to address the fact the fcntl lock on the lock file will still go away on the first env_close() call. If there are no other processes with the env open, then the next process that opens the env will re-init the lock file, because it doesn't know about the existing process. At that point the existing process is hosed anyway. So the question is, if a process has made the mistake of opening the same env twice, what is the anticipated lifetime of each env instance? If the code was written according to doc guidelines, then both env instances should only be closed after all processing is done and just before program exit. In that case it doesn't really matter what happens to the reader table or the fcntl lock. But if the two instances have drastically different lifetimes, then all bets are off. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7842] mdb readers/writer exclusion protocol, as implemented, is racy.
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=7842 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- *** This issue has been marked as a duplicate of issue 7969 *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7969] LMDB: Globally shared fields of meta-data are not 'volatile'.
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=7969 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rsbx(a)acm.org --- Comment #18 from Howard Chu <hyc(a)openldap.org> --- *** Issue 7842 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 7969] LMDB: Globally shared fields of meta-data are not 'volatile'.
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=7969 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #17 from Howard Chu <hyc(a)openldap.org> --- Patch committed, fix released in LMDB 0.9.15 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7668] LMDB enhancement, corruption detection
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=7668 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |TEST --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- MDB_PREVSNAPSHOT flag was added for LMDB 1.0 to allow opening env with the previous instead of current meta page. mdb_env_set_checksum() was added for LMDB 1.0 to allow specifying per-page checksums. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7165] Killing slap tools breaks the running mdb
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=7165 --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- Most of this bug appears to be obsolete. (In reply to Hallvard Furuseth from comment #0) > Full_Name: Hallvard B Furuseth > Version: master, d861910f55cb1beb5e443caa7e961ed760074352 > OS: Linux x86_64 > URL: > Submission from: (NULL) (195.1.106.125) > Submitted by: hallvard > > > Aborting an MDB process can break MDB if another MDB process is > running, because then locks/reader table info are not reset. Using mdb_stat -rr will purge stale readers. I suppose we could tweak back-mdb to also do a reader purge if it ever gets a MDB_READERS_FULL error from mdb_txn_begin. > > The problems below go away when the last slap process terminates > so the lockfile can be reset. Sometimes kill -KILL is needed. > > > ==== lock.conf ==== > include servers/slapd/schema/core.schema > database mdb > suffix o=hi > directory lock.dir > > > (A) If a process holding a shared mutex dies, other processes' ops > on the mutex can hang/fail: Robust mutex support was added in a2ac10107e2fb845c4a38a339239063ec4407d84 in 2014. > > rm -rf lock.dir; mkdir lock.dir > servers/slapd/slapd -f lock.conf -h ldapi://ldapi -d0 & > MDB_KILL_R=true servers/slapd/slapd -Tcat -f lock.conf > ldapsearch -xLLH ldapi://ldapi -b o=hi l=x 1.1 > ^C (kills ldapsearch which is waiting for results) > kill %% (fails to kill slapd) > kill -KILL %% > > The Posix fix, robust mutexes, is outlined below. With _WIN32, > check return code WAIT_ABANDONED. __APPLE__ Posix semaphores: > Don't know. SysV semaphores have SEM_UNDO to cancel the process' > effect if the process dies, but the peers do not seem to be > informed that this happened. > > if ((rc = pthread_mutexattr_init( &mattr )) || > (rc = pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_SHARED)) || > (rc = pthread_mutexattr_setrobust( &mattr, PTHREAD_MUTEX_ROBUST )) || > (rc = pthread_mutex_init(&mutex, &mattr ))) > return rc; > ... > switch (pthread_mutex_lock(&mutex)) { > case 0: > break; > case EOWNERDEAD: > Repair the possibly half-updated data protected by <mutex>; > if (successful repair) { > pthread_mutex_consistent(&mutex); > break; > } > /* With Posix mutexes, make future use of <mutex> return failure: */ > pthread_mutex_unlock(&mutex); > /* FALLTHRU */ > default: > return MDB_PANIC; > } > ... > pthread_mutex_unlock(&mutex); > > > BTW, the above also happens with MDB_KILL_W=true slapcat followed > by ldapadd, dunno why slapcat uses a txn without MDB_TXN_RDONLY. slapcat already opens the env RDONLY. In 3e47e825fd61e1bff001c01f40d70263c89ffabd in 2012 was patched to also create the txn RDONLY. > In this case, raise(SIGINT) is sufficient. With MDB_KILL_R, that > does not kill slapd and we need SIGKILL - it catches SIGINT I > guess. Don't know if that difference is intentional. > > > (B1) Repeated kill -KILL slap<tool> while slapd is running can use > up the reader table since it does not clear its table slots, > making the db unusable. > > (B2) slapcat report no error after it fails to read the db due to > full reader table, it exits with success status. Unable to reproduce, dunno when this was fixed but it returns an error code now. > > (B3) After one "kill -KILL slap<tool>" while slapd is running, I > imagine the stale slot which does not go away can prevent freelist > reuse so the db grows quickly. But I have not seen that. Depends on timing I suppose; it's possible that there was no active read txn at the moment, in which case the stale reader slot has no effect on page reuse. > > bash$ rm -rf lock.dir; mkdir lock.dir > bash$ servers/slapd/slapd -f lock.conf -h ldapi://ldapi -d0 & > bash$ for (( i=0; i<130; i++)) { > MDB_KILL_UR=true servers/slapd/slapd -Tcat -f lock.conf > } > /dev/null > bash$ servers/slapd/slapd -Tcat -f lock.conf -d-1 2>cat.out > (success result, no output, no errors in the log) > bash$ ldapsearch -xLLH ldapi://ldapi -b o=hi l=x 1.1 > version: 1 > > [R..RLOCKED..R1] Other (e.g., implementation specific) error (80) > Additional information: internal error > bash$ > > Maybe it's easier to have a per-process reader table after all, > and a shared table with just the oldest txn per process. > > Or, each transaction chould have an exclusive file region lock. > A writer could try to grab the oldest txn's region lock if that > belongs to another process, and clear the txn it if successful. > A reader, before giving up, would just search for another pid's > txn whose lock it can grab. The current code uses an fcntl lock to detect process liveness. > > Except since the system reuses pids, the ID would either have to > be more exclusive (e.g. pid + mdb_env_open() time) or mdb_env_open > must clear away reader table entries with its own pid. > > Speaking of which, I don't see the use of the repeated getpid() > calls. Should be enough to store the pid in the MDB_env. fcntl > record locks do not survive fork(), so an MDB_env doesn't either. > And the thread ID is unsed, and must be reset with memset, not > 'mr_tid = 0' since pthread_t can be a struct. > The above is no longer true. > > (C) Mentioned earlier: Startup can fail due to a race condition, > when another process starts MDB at the same time and then aborts: > - Process 1 starts MDB, gets write lock in mdb_env_setup_locks(). > - Process 2 starts MDB, awaits read lock since write lock is taken. > - Process 1 dies. > - Process 2 gets the read lock and proceeds, but with an uninitialized > lockfile since it expects that process 1 initialized it. Probably still true, but already doc'd in Caveats. > > Fix: An extra exclusive lock around the current lock setup code. > > kill slapd process, if any > rm -rf lock.dir; mkdir lock.dir > MDB_RACE=true servers/slapd/slapd -Tcat -f lock.conf & sleep 1; \ > servers/slapd/slapd -Tcat -f lock.conf > > In addition, the above dumps core in mdb_env_close: > for (i=0; i<env->me_txns->mti_numreaders; i++) > where env->me_txns == (MDB_txninfo *) 0xffffffffffffffff. > > > (D) And of course ^Z when holding a mutex can block other processes' > threads, but I suppose BDB has the same problem. > > DB_SUSPEND=true servers/slapd/slapd -Tadd -f lock.conf < /dev/null > servers/slapd/slapd -Tadd -f lock.conf < /dev/null > (hanging...) ^C > kill %% > > The fix I can see for now is "don't do that" in the doc. MDB > could in addition use pthread_mutex_timedlock() so slapd at least > can keep running and can be killed without kill -KILL. Final fix > = a lock-free library, when a useful portable one emerges. At this point the only potential action I see is to add a check for MDB_READERS_FULL as noted at the beginning of this reply. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9565] New: radlib.h: No such file or directory - passwd slapd-module
by openldap-its＠openldap.org 29 May '21

29 May '21

https://bugs.openldap.org/show_bug.cgi?id=9565 Issue ID: 9565 Summary: radlib.h: No such file or directory - passwd slapd-module Product: OpenLDAP Version: 2.5.4 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: rguichardspam(a)Gmail.com Target Milestone: --- Hi, while compile passwd slapd-modules, I've got error on Radius compilation. gcc -DOPENLDAP_FD_SETSIZE=4096 -O2 -g -DSLAP_SCHEMA_EXPOSE -g -O2 -I/usr/kerberos/include -I../../../include -I../../../include -I../../../servers/slapd -c radius.c -fPIC -DPIC -o .libs/radius.o radius.c:27:20: fatal error: radlib.h: No such file or directory #include <radlib.h> I've searched which package could provide the radlib file but I didn't found it. Please confirm which package should be used .. or link to the source.. I'm on CentOS -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9567] New: Double free error after attempt to insert a duplicate entry
by openldap-its＠openldap.org 29 May '21

29 May '21

https://bugs.openldap.org/show_bug.cgi?id=9567 Issue ID: 9567 Summary: Double free error after attempt to insert a duplicate entry Product: LMDB Version: 0.9.17 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: wietse(a)porcupine.org Target Milestone: --- This problem was originally discovered by Adi Prasaja on Ubuntu with lmdb-0.9.24, and reproduced by me on Fedora with lmdb-0.9.25, as well as multiple source repo branches from github.com/openldap. The problem was introduced with lmdb version 0.9.17 and still exists in the 'head' version 0.9.70 as retrieved from github.com on May 28, 2021. Quick demo (any Postfix version with LMDB support): create a key-value store from a file containing one (key, value) per line. $ cat /tmp/aa aa 1 aa 2 $ postmap lmdb:/tmp/aa postmap: warning: lmdb:/tmp/aa: duplicate entry: "aa" <== Postfix message free(): double free detected in tcache 2 <== libc message Aborted (core dumped) Commenting out the free(env->me_txn0) call mdb_env_close0() will prevent the double free() error. Of course, that results in a memory leak when the input contains no duplicate line. The remainder of this message show the steps to reproduce this with lmdb version 0.9.70 (from github 'head') on Fedora 32 with postfix-3.7-20210424. These steps have been verified to also work for Postfix 3.2. The steps assume that the LMDB library and header files are installed in /usr/local, by using the default lmdb Makefile. $ cat >makemakefiles-lmdb-local <<'EOF' #!/bin/sh export OPT="" export CCARGS="-DNO_NIS" export AUXLIBS="" # Add LMDB export CCARGS="$CCARGS -DHAS_LMDB" export AUXLIBS_LMDB="-L/usr/local/lib -Wl,-rpath,/usr/local/lib -llmdb" unset shlib_directory make -f Makefile.in makefiles shared=no dynamicmaps=no CCARGS="-I/usr/local/include $CCARGS" AUXLIBS="$AUXLIBS $AUXLIBS_LMDB" EOF $ make tidy [some output] $ sh makemakefiles-lmdb-local $ make -j8 [lots of output] $ cat >/tmp/aa << EOF aa 1 aa 2 EOF $ valgrind --tool=memcheck bin/postmap lmdb:/tmp/aa ==340318== Memcheck, a memory error detector ==340318== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==340318== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==340318== Command: bin/postmap lmdb:/tmp/aa ==340318== postmap: warning: lmdb:/tmp/aa: duplicate entry: "aa" ==340318== Invalid free() / delete / delete[] / realloc() ==340318== at 0x483B9F5: free (vg_replace_malloc.c:538) ==340318== by 0x4858CFD: mdb_env_close0 (in /usr/local/lib/liblmdb.so) ==340318== by 0x4859B0C: mdb_env_close (in /usr/local/lib/liblmdb.so) ==340318== by 0x13CBC3: slmdb_close (slmdb.c:780) ==340318== by 0x13B297: dict_lmdb_close (dict_lmdb.c:475) ==340318== by 0x113DFF: mkmap_close (mkmap_open.c:211) ==340318== by 0x10F080: postmap (postmap.c:557) ==340318== by 0x1108E4: main (postmap.c:1140) ==340318== Address 0x7320c30 is 0 bytes inside a block of size 258 free'd ==340318== at 0x483B9F5: free (vg_replace_malloc.c:538) ==340318== by 0x48561DE: mdb_txn_commit (mdb.c:4130) ==340318== by 0x13CB7D: slmdb_close (slmdb.c:771) ==340318== by 0x13B297: dict_lmdb_close (dict_lmdb.c:475) ==340318== by 0x113DFF: mkmap_close (mkmap_open.c:211) ==340318== by 0x10F080: postmap (postmap.c:557) ==340318== by 0x1108E4: main (postmap.c:1140) ==340318== Block was alloc'd at ==340318== at 0x483CAE9: calloc (vg_replace_malloc.c:760) ==340318== by 0x48599F2: mdb_env_open (in /usr/local/lib/liblmdb.so) ==340318== by 0x13CD91: slmdb_open (slmdb.c:851) ==340318== by 0x13B6C6: dict_lmdb_open (dict_lmdb.c:612) ==340318== by 0x113F50: mkmap_open (mkmap_open.c:283) ==340318== by 0x10EC02: postmap (postmap.c:438) ==340318== by 0x1108E4: main (postmap.c:1140) ==340318== ==340318== ==340318== HEAP SUMMARY: ==340318== in use at exit: 27,608 bytes in 634 blocks ==340318== total heap usage: 1,430 allocs, 797 frees, 3,356,293 bytes allocated ==340318== ==340318== LEAK SUMMARY: ==340318== definitely lost: 0 bytes in 0 blocks ==340318== indirectly lost: 0 bytes in 0 blocks ==340318== possibly lost: 27,582 bytes in 633 blocks ==340318== still reachable: 26 bytes in 1 blocks ==340318== suppressed: 0 bytes in 0 blocks ==340318== Rerun with --leak-check=full to see details of leaked memory ==340318== ==340318== For lists of detected and suppressed errors, rerun with: -s ==340318== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Similar errors happen with lmdb-0.9.17. The problem does not exist in lmdb-0.9.16 or earlier versions. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9564] New: Race condition with freeing the spilled pages from transaction
by openldap-its＠openldap.org 27 May '21

27 May '21

https://bugs.openldap.org/show_bug.cgi?id=9564 Issue ID: 9564 Summary: Race condition with freeing the spilled pages from transaction Product: LMDB Version: 0.9.29 Hardware: Other OS: Mac OS Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 825 --> https://bugs.openldap.org/attachment.cgi?id=825&action=edit Free the spilled pages and dirty overflows before unlocking the write mutex The spilled pages (a transaction's mt_spill_pgs) is freed *after* a write transaction's mutex is unlocked (in mdb.master3). This can result in a race condition where a second transaction can start and subsequently assign a new mt_spill_pgs list to the transaction structure that it reuses. If this occurs after the first transaction unlocks the mutex, but before it performs the free operation on mt_spill_pgs, then the first transaction will end up calling a free on the same spilled page list as the second transaction, resulting in a double free (and crash). It would seem to be an extremely unlikely scenario to actually happen, since the free call is literally the next operation after the mutex is unlocked, and the second transaction would need to make it all the way to the point of saving the freelist before a page spill list is likely to be allocated. Consequently, this probably has rarely happened. However, one of our users (see https://github.com/DoctorEvidence/lmdb-store/issues/48 for the discussion) has noticed this occurring, and it seems that it may be particularly likely to happen on MacOS on the new M1 silicon. Perhaps there is some peculiarity to how the threads are more likely to yield execution after a mutex unlock, I am not sure. I was able to reproduce the issue by intentionally manipulating the timing (sleeping before the free) to verify that the race condition is technically feasible, and apparently this can happen "in the wild" on MacOS, at least with an M1. It is also worth noting that this is due to (or a regression from) the fix for ITS#9155 (https://github.com/LMDB/lmdb/commit/cb256f409bb53efeda4ac69ee8165a0b4fc1a277) where the free call was moved outside the conditional (for having a parent) that had previously never been executed after the mutex is unlocked, but now is called after the unlock. Anyway, the solution is relatively simple, the free call simply has to be moved above the unlock. In my patch, I also moved the free call for mt_dirty_ovs. I am not sure what OVERFLOW_NOTYET/mt_dirty_ovs is for, but presumably it should be handled the same. This could alternately be solved by saving the reference to these lists before unlocking, and freeing after unlocking, which would slightly decrease the amount of processing within the mutex guarded code. Let me know if you prefer a patch that does that. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9563] New: OpenLDAP enable TLS1.3
by openldap-its＠openldap.org 26 May '21

26 May '21

https://bugs.openldap.org/show_bug.cgi?id=9563 Issue ID: 9563 Summary: OpenLDAP enable TLS1.3 Product: OpenLDAP Version: 2.4.45 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: santhu227(a)gmail.com Target Milestone: --- How we can enable TLS1.3 on OopenLDAP for ubuntu 18.04.5 LTS. Package details : OS PRETTY_NAME="Ubuntu 18.04.5 LTS" VERSION_ID="18.04" OpenSSL 1.1.1g 21 Apr 2020. grep -R olcTLS /etc/ldap/slapd.d/ /etc/ldap/slapd.d/cn=config.ldif:olcTLSCRLCheck: none /etc/ldap/slapd.d/cn=config.ldif:olcTLSProtocolMin: 3.4 /etc/ldap/slapd.d/cn=config.ldif:olcTLSCipherSuite: NORMAL /etc/ldap/slapd.d/cn=config.ldif:olcTLSVerifyClient: try /etc/ldap/slapd.d/cn=config.ldif:olcTLSCACertificateFile: /etc/ldap/sasl2/ldap_server_new_13.crt /etc/ldap/slapd.d/cn=config.ldif:olcTLSCertificateKeyFile: /etc/ldap/sasl2/ldap_server_new_13.key /etc/ldap/slapd.d/cn=config.ldif:olcTLSCertificateFile: /etc/ldap/sasl2/ldap_server_new_13.crt dpkg -s slapd | grep Version Version: 2.4.45+dfsg-1ubuntu1.10 Is there any possibility to enable TLS1.3 on slapd service(OpenLDAP server) for above configuration. If need to upgrade any package will it be possible to upgrade or update on Ubuntu 18.04.5. openssl client output where openssl is not able to connecte with TLS1.3. Same will list ciphers for TLS1.2 openssl s_client -connect <host>:636 -tls1_3 CONNECTED(00000003) write:errno=0 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 215 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9562] New: Unable to setup TLS1.3
by openldap-its＠openldap.org 26 May '21

26 May '21

https://bugs.openldap.org/show_bug.cgi?id=9562 Issue ID: 9562 Summary: Unable to setup TLS1.3 Product: OpenLDAP Version: 2.4.45 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: santhu227(a)gmail.com Target Milestone: --- How we can enable TLS1.3 on OopenLDAP for ubuntu 18.04.5 LTS. Package details : OS PRETTY_NAME="Ubuntu 18.04.5 LTS" VERSION_ID="18.04" OpenSSL 1.1.1g 21 Apr 2020. grep -R olcTLS /etc/ldap/slapd.d/ /etc/ldap/slapd.d/cn=config.ldif:olcTLSCRLCheck: none /etc/ldap/slapd.d/cn=config.ldif:olcTLSProtocolMin: 3.3 /etc/ldap/slapd.d/cn=config.ldif:olcTLSCipherSuite: NORMAL /etc/ldap/slapd.d/cn=config.ldif:olcTLSVerifyClient: try /etc/ldap/slapd.d/cn=config.ldif:olcTLSCACertificateFile: /etc/ldap/sasl2/ldap_server_new_13.crt /etc/ldap/slapd.d/cn=config.ldif:olcTLSCertificateKeyFile: /etc/ldap/sasl2/ldap_server_new_13.key /etc/ldap/slapd.d/cn=config.ldif:olcTLSCertificateFile: /etc/ldap/sasl2/ldap_server_new_13.crt dpkg -s slapd | grep Version Version: 2.4.45+dfsg-1ubuntu1.10 Is there any possibility to enable TLS1.3 on slapd service(OpenLDAP server) for above configuration. If need to upgrade any package will it be possible to upgrade or update on Ubuntu 18.04.5. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9560] New: Dead images in documentation
by openldap-its＠openldap.org 25 May '21

25 May '21

https://bugs.openldap.org/show_bug.cgi?id=9560 Issue ID: 9560 Summary: Dead images in documentation Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: shea.ramage(a)gmail.com Target Milestone: --- Created attachment 823 --> https://bugs.openldap.org/attachment.cgi?id=823&action=edit Screenshot of broken images Documentation release 2.5 (https://www.openldap.org/doc/admin25) contains several dead image links. One example (Figure 3.1) https://www.openldap.org/doc/admin25/config_local.png results in a 404 not found error, however changing the '5' in the URL to a '4' loads an image correctly. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9558] New: unable to add DB DIT , getting value #0 invalid per syntax error
by openldap-its＠openldap.org 25 May '21

25 May '21

https://bugs.openldap.org/show_bug.cgi?id=9558 Issue ID: 9558 Summary: unable to add DB DIT , getting value #0 invalid per syntax error Product: OpenLDAP Version: 2.4.50 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: govind.rathod(a)hpe.com Target Milestone: --- unable to add DB DIT , getting value #0 invalid per syntax error command used : ldapadd -x -D 'cn=config' -w secret -f create_sns_db.ldif below is the content of "create_sns_db.ldif" file dn: olcDatabase=mdb,cn=config objectClass: olcMdbConfig olcDatabase: mdb olcDbMaxSize: 1073741824 olcSuffix: dc=smartsan olcDbDirectory: /usr/local/var/openldap-data/sns_db olcRootDN: cn=admin,dc=smartsan olcRootPW: secret2 olcDbIndex: objectClass eq below is the debug output for the ldapadd command used: #ldapadd -x -D 'cn=config' -w secret -f create_sns_db.ldif -d 255 ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 ldap_new_socket: 4 ldap_prepare_socket: 4 ldap_connect_to_host: Trying ::1 389 ldap_pvt_connect: fd: 4 tm: -1 async: 0 attempting to connect: connect success ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x7f1aa9d18010 ptr=0x7f1aa9d18010 end=0x7f1aa9d1802d len=29 0000: 30 1b 02 01 01 60 16 02 01 03 04 09 63 6e 3d 63 0....`......cn=c 0010: 6f 6e 66 69 67 80 06 73 65 63 72 65 74 onfig..secret ber_scanf fmt ({i) ber: ber_dump: buf=0x7f1aa9d18010 ptr=0x7f1aa9d18015 end=0x7f1aa9d1802d len=24 0000: 60 16 02 01 03 04 09 63 6e 3d 63 6f 6e 66 69 67 `......cn=config 0010: 80 06 73 65 63 72 65 74 ..secret ber_flush2: 29 bytes to sd 4 0000: 30 1b 02 01 01 60 16 02 01 03 04 09 63 6e 3d 63 0....`......cn=c 0010: 6f 6e 66 69 67 80 06 73 65 63 72 65 74 onfig..secret ldap_write: want=29, written=29 0000: 30 1b 02 01 01 60 16 02 01 03 04 09 63 6e 3d 63 0....`......cn=c 0010: 6f 6e 66 69 67 80 06 73 65 63 72 65 74 onfig..secret ldap_result ld 0x7f1aaa121dc0 msgid 1 wait4msg ld 0x7f1aaa121dc0 msgid 1 (infinite timeout) wait4msg continue ld 0x7f1aaa121dc0 msgid 1 all 1 ** ld 0x7f1aaa121dc0 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Tue May 25 05:42:41 2021 ** ld 0x7f1aaa121dc0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x7f1aaa121dc0 request count 1 (abandoned 0) ** ld 0x7f1aaa121dc0 Response Queue: Empty ld 0x7f1aaa121dc0 response count 0 ldap_chkResponseList ld 0x7f1aaa121dc0 msgid 1 all 1 ldap_chkResponseList returns ld 0x7f1aaa121dc0 NULL ldap_int_select read1msg: ld 0x7f1aaa121dc0 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 61 07 0a 0....a.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x7f1aaa048b10 ptr=0x7f1aaa048b10 end=0x7f1aaa048b1c len=12 0000: 02 01 01 61 07 0a 01 00 04 00 04 00 ...a........ read1msg: ld 0x7f1aaa121dc0 msgid 1 message type bind ber_scanf fmt ({eAA) ber: ber_dump: buf=0x7f1aaa048b10 ptr=0x7f1aaa048b13 end=0x7f1aaa048b1c len=9 0000: 61 07 0a 01 00 04 00 04 00 a........ read1msg: ld 0x7f1aaa121dc0 0 new referrals read1msg: mark request completed, ld 0x7f1aaa121dc0 msgid 1 request done: ld 0x7f1aaa121dc0 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x7f1aaa048b10 ptr=0x7f1aaa048b13 end=0x7f1aaa048b1c len=9 0000: 61 07 0a 01 00 04 00 04 00 a........ ber_scanf fmt (}) ber: ber_dump: buf=0x7f1aaa048b10 ptr=0x7f1aaa048b1c end=0x7f1aaa048b1c len=0 ldap_msgfree adding new entry "olcDatabase=mdb,cn=config" ldap_add_ext ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x7f1aa9d18020 ptr=0x7f1aa9d18020 end=0x7f1aa9d18148 len=296 0000: 30 82 01 24 02 01 02 68 82 01 1d 04 19 6f 6c 63 0..$...h.....olc 0010: 44 61 74 61 62 61 73 65 3d 6d 64 62 2c 63 6e 3d Database=mdb,cn= 0020: 63 6f 6e 66 69 67 30 81 ff 30 1d 04 0b 6f 62 6a config0..0...obj 0030: 65 63 74 43 6c 61 73 73 31 0e 04 0c 6f 6c 63 4d ectClass1...olcM 0040: 64 62 43 6f 6e 66 69 67 30 14 04 0b 6f 6c 63 44 dbConfig0...olcD 0050: 61 74 61 62 61 73 65 31 05 04 03 6d 64 62 30 1c atabase1...mdb0. 0060: 04 0c 6f 6c 63 44 62 4d 61 78 53 69 7a 65 31 0c ..olcDbMaxSize1. 0070: 04 0a 31 30 37 33 37 34 31 38 32 34 30 1a 04 09 ..10737418240... 0080: 6f 6c 63 53 75 66 66 69 78 31 0d 04 0b 64 63 3d olcSuffix1...dc= 0090: 73 6d 61 72 74 73 61 6e 30 31 04 0e 6f 6c 63 44 smartsan01..olcD 00a0: 62 44 69 72 65 63 74 6f 72 79 31 1f 04 1d 2f 76 bDirectory1.../v 00b0: 61 72 2f 6c 69 62 2f 6f 70 65 6e 6c 64 61 70 2d ar/lib/openldap- 00c0: 64 61 74 61 2f 73 6e 73 5f 64 62 30 23 04 09 6f data/sns_db0#..o 00d0: 6c 63 52 6f 6f 74 44 4e 31 16 04 14 63 6e 3d 61 lcRootDN1...cn=a 00e0: 64 6d 69 6e 2c 64 63 3d 73 6d 61 72 74 73 61 6e dmin,dc=smartsan 00f0: 30 16 04 09 6f 6c 63 52 6f 6f 74 50 57 31 09 04 0...olcRootPW1.. 0100: 07 73 65 63 72 65 74 32 30 1e 04 0a 6f 6c 63 44 .secret20...olcD 0110: 62 49 6e 64 65 78 31 10 04 0e 6f 62 6a 65 63 74 bIndex1...object 0120: 43 6c 61 73 73 20 65 71 Class eq ber_scanf fmt ({) ber: ber_dump: buf=0x7f1aa9d18020 ptr=0x7f1aa9d18027 end=0x7f1aa9d18148 len=289 0000: 68 82 01 1d 04 19 6f 6c 63 44 61 74 61 62 61 73 h.....olcDatabas 0010: 65 3d 6d 64 62 2c 63 6e 3d 63 6f 6e 66 69 67 30 e=mdb,cn=config0 0020: 81 ff 30 1d 04 0b 6f 62 6a 65 63 74 43 6c 61 73 ..0...objectClas 0030: 73 31 0e 04 0c 6f 6c 63 4d 64 62 43 6f 6e 66 69 s1...olcMdbConfi 0040: 67 30 14 04 0b 6f 6c 63 44 61 74 61 62 61 73 65 g0...olcDatabase 0050: 31 05 04 03 6d 64 62 30 1c 04 0c 6f 6c 63 44 62 1...mdb0...olcDb 0060: 4d 61 78 53 69 7a 65 31 0c 04 0a 31 30 37 33 37 MaxSize1...10737 0070: 34 31 38 32 34 30 1a 04 09 6f 6c 63 53 75 66 66 418240...olcSuff 0080: 69 78 31 0d 04 0b 64 63 3d 73 6d 61 72 74 73 61 ix1...dc=smartsa 0090: 6e 30 31 04 0e 6f 6c 63 44 62 44 69 72 65 63 74 n01..olcDbDirect 00a0: 6f 72 79 31 1f 04 1d 2f 76 61 72 2f 6c 69 62 2f ory1.../var/lib/ 00b0: 6f 70 65 6e 6c 64 61 70 2d 64 61 74 61 2f 73 6e openldap-data/sn 00c0: 73 5f 64 62 30 23 04 09 6f 6c 63 52 6f 6f 74 44 s_db0#..olcRootD 00d0: 4e 31 16 04 14 63 6e 3d 61 64 6d 69 6e 2c 64 63 N1...cn=admin,dc 00e0: 3d 73 6d 61 72 74 73 61 6e 30 16 04 09 6f 6c 63 =smartsan0...olc 00f0: 52 6f 6f 74 50 57 31 09 04 07 73 65 63 72 65 74 RootPW1...secret 0100: 32 30 1e 04 0a 6f 6c 63 44 62 49 6e 64 65 78 31 20...olcDbIndex1 0110: 10 04 0e 6f 62 6a 65 63 74 43 6c 61 73 73 20 65 ...objectClass e 0120: 71 q ber_flush2: 296 bytes to sd 4 0000: 30 82 01 24 02 01 02 68 82 01 1d 04 19 6f 6c 63 0..$...h.....olc 0010: 44 61 74 61 62 61 73 65 3d 6d 64 62 2c 63 6e 3d Database=mdb,cn= 0020: 63 6f 6e 66 69 67 30 81 ff 30 1d 04 0b 6f 62 6a config0..0...obj 0030: 65 63 74 43 6c 61 73 73 31 0e 04 0c 6f 6c 63 4d ectClass1...olcM 0040: 64 62 43 6f 6e 66 69 67 30 14 04 0b 6f 6c 63 44 dbConfig0...olcD 0050: 61 74 61 62 61 73 65 31 05 04 03 6d 64 62 30 1c atabase1...mdb0. 0060: 04 0c 6f 6c 63 44 62 4d 61 78 53 69 7a 65 31 0c ..olcDbMaxSize1. 0070: 04 0a 31 30 37 33 37 34 31 38 32 34 30 1a 04 09 ..10737418240... 0080: 6f 6c 63 53 75 66 66 69 78 31 0d 04 0b 64 63 3d olcSuffix1...dc= 0090: 73 6d 61 72 74 73 61 6e 30 31 04 0e 6f 6c 63 44 smartsan01..olcD 00a0: 62 44 69 72 65 63 74 6f 72 79 31 1f 04 1d 2f 76 bDirectory1.../v 00b0: 61 72 2f 6c 69 62 2f 6f 70 65 6e 6c 64 61 70 2d ar/lib/openldap- 00c0: 64 61 74 61 2f 73 6e 73 5f 64 62 30 23 04 09 6f data/sns_db0#..o 00d0: 6c 63 52 6f 6f 74 44 4e 31 16 04 14 63 6e 3d 61 lcRootDN1...cn=a 00e0: 64 6d 69 6e 2c 64 63 3d 73 6d 61 72 74 73 61 6e dmin,dc=smartsan 00f0: 30 16 04 09 6f 6c 63 52 6f 6f 74 50 57 31 09 04 0...olcRootPW1.. 0100: 07 73 65 63 72 65 74 32 30 1e 04 0a 6f 6c 63 44 .secret20...olcD 0110: 62 49 6e 64 65 78 31 10 04 0e 6f 62 6a 65 63 74 bIndex1...object 0120: 43 6c 61 73 73 20 65 71 Class eq ldap_write: want=296, written=296 0000: 30 82 01 24 02 01 02 68 82 01 1d 04 19 6f 6c 63 0..$...h.....olc 0010: 44 61 74 61 62 61 73 65 3d 6d 64 62 2c 63 6e 3d Database=mdb,cn= 0020: 63 6f 6e 66 69 67 30 81 ff 30 1d 04 0b 6f 62 6a config0..0...obj 0030: 65 63 74 43 6c 61 73 73 31 0e 04 0c 6f 6c 63 4d ectClass1...olcM 0040: 64 62 43 6f 6e 66 69 67 30 14 04 0b 6f 6c 63 44 dbConfig0...olcD 0050: 61 74 61 62 61 73 65 31 05 04 03 6d 64 62 30 1c atabase1...mdb0. 0060: 04 0c 6f 6c 63 44 62 4d 61 78 53 69 7a 65 31 0c ..olcDbMaxSize1. 0070: 04 0a 31 30 37 33 37 34 31 38 32 34 30 1a 04 09 ..10737418240... 0080: 6f 6c 63 53 75 66 66 69 78 31 0d 04 0b 64 63 3d olcSuffix1...dc= 0090: 73 6d 61 72 74 73 61 6e 30 31 04 0e 6f 6c 63 44 smartsan01..olcD 00a0: 62 44 69 72 65 63 74 6f 72 79 31 1f 04 1d 2f 76 bDirectory1.../v 00b0: 61 72 2f 6c 69 62 2f 6f 70 65 6e 6c 64 61 70 2d ar/lib/openldap- 00c0: 64 61 74 61 2f 73 6e 73 5f 64 62 30 23 04 09 6f data/sns_db0#..o 00d0: 6c 63 52 6f 6f 74 44 4e 31 16 04 14 63 6e 3d 61 lcRootDN1...cn=a 00e0: 64 6d 69 6e 2c 64 63 3d 73 6d 61 72 74 73 61 6e dmin,dc=smartsan 00f0: 30 16 04 09 6f 6c 63 52 6f 6f 74 50 57 31 09 04 0...olcRootPW1.. 0100: 07 73 65 63 72 65 74 32 30 1e 04 0a 6f 6c 63 44 .secret20...olcD 0110: 62 49 6e 64 65 78 31 10 04 0e 6f 62 6a 65 63 74 bIndex1...object 0120: 43 6c 61 73 73 20 65 71 Class eq ldap_result ld 0x7f1aaa121dc0 msgid 2 wait4msg ld 0x7f1aaa121dc0 msgid 2 (timeout 100000 usec) wait4msg continue ld 0x7f1aaa121dc0 msgid 2 all 1 ** ld 0x7f1aaa121dc0 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Tue May 25 05:42:41 2021 ** ld 0x7f1aaa121dc0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x7f1aaa121dc0 request count 1 (abandoned 0) ** ld 0x7f1aaa121dc0 Response Queue: Empty ld 0x7f1aaa121dc0 response count 0 ldap_chkResponseList ld 0x7f1aaa121dc0 msgid 2 all 1 ldap_chkResponseList returns ld 0x7f1aaa121dc0 NULL ldap_int_select read1msg: ld 0x7f1aaa121dc0 msgid 2 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 34 02 01 02 69 2f 0a 04...i/. ldap_read: want=46, got=46 0000: 01 15 04 00 04 28 6f 62 6a 65 63 74 43 6c 61 73 .....(objectClas 0010: 73 3a 20 76 61 6c 75 65 20 23 30 20 69 6e 76 61 s: value #0 inva 0020: 6c 69 64 20 70 65 72 20 73 79 6e 74 61 78 lid per syntax ber_get_next: tag 0x30 len 52 contents: ber_dump: buf=0x565118724fb0 ptr=0x565118724fb0 end=0x565118724fe4 len=52 0000: 02 01 02 69 2f 0a 01 15 04 00 04 28 6f 62 6a 65 ...i/......(obje 0010: 63 74 43 6c 61 73 73 3a 20 76 61 6c 75 65 20 23 ctClass: value # 0020: 30 20 69 6e 76 61 6c 69 64 20 70 65 72 20 73 79 0 invalid per sy 0030: 6e 74 61 78 ntax read1msg: ld 0x7f1aaa121dc0 msgid 2 message type add ber_scanf fmt ({eAA) ber: ber_dump: buf=0x565118724fb0 ptr=0x565118724fb3 end=0x565118724fe4 len=49 0000: 69 2f 0a 01 15 04 00 04 28 6f 62 6a 65 63 74 43 i/......(objectC 0010: 6c 61 73 73 3a 20 76 61 6c 75 65 20 23 30 20 69 lass: value #0 i 0020: 6e 76 61 6c 69 64 20 70 65 72 20 73 79 6e 74 61 nvalid per synta 0030: 78 x read1msg: ld 0x7f1aaa121dc0 0 new referrals read1msg: mark request completed, ld 0x7f1aaa121dc0 msgid 2 request done: ld 0x7f1aaa121dc0 msgid 2 res_errno: 21, res_error: <objectClass: value #0 invalid per syntax>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x565118724fb0 ptr=0x565118724fb3 end=0x565118724fe4 len=49 0000: 69 2f 0a 01 15 04 00 04 28 6f 62 6a 65 63 74 43 i/......(objectC 0010: 6c 61 73 73 3a 20 76 61 6c 75 65 20 23 30 20 69 lass: value #0 i 0020: 6e 76 61 6c 69 64 20 70 65 72 20 73 79 6e 74 61 nvalid per synta 0030: 78 x ber_scanf fmt (}) ber: ber_dump: buf=0x565118724fb0 ptr=0x565118724fe4 end=0x565118724fe4 len=0 ldap_msgfree ldap_err2string ldap_add: Invalid syntax (21) additional info: objectClass: value #0 invalid per syntax ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 4 0000: 30 05 02 01 03 42 00 0....B. ldap_write: want=7, written=7 0000: 30 05 02 01 03 42 00 0....B. ldap_free_connection: actually freed Note: i have manually typed the contents of the ldif file to make sure no extra characters are there. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9539] New: ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(env, 0)
by openldap-its＠openldap.org 25 May '21

25 May '21

https://bugs.openldap.org/show_bug.cgi?id=9539 Issue ID: 9539 Summary: ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(env, 0) Product: LMDB Version: 0.9.28 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: igfoo(a)github.com Target Milestone: --- On Windows, with the attached program and the commands below, I am getting ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(env, 0) on the latest 0.9.28 release. The program works as expected on mdb.master. git clone https://github.com/LMDB/lmdb.git cd lmdb git reset --hard LMDB_0.9.28 cd .. call "c:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvars64.bat" cl -Femain.exe -Ilmdb/libraries/liblmdb main.c lmdb/libraries/liblmdb/mdb.c lmdb/libraries/liblmdb/midl.c Advapi32.lib cl -Feloop.exe -Ilmdb/libraries/liblmdb loop.c lmdb/libraries/liblmdb/mdb.c lmdb/libraries/liblmdb/midl.c Advapi32.lib .\main.exe Example output: Loop 300000 400000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 500000 600000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 200000 300000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 400000 500000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 600000 700000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 100000 200000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 700000 800000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 900000 1000000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 800000 900000 starting. Loop 800000 900000 done. Non-zero 0 exit code 1. Non-zero 1 exit code 1. Non-zero 2 exit code 1. Non-zero 3 exit code 1. Non-zero 4 exit code 1. Non-zero 5 exit code 1. Non-zero 6 exit code 1. Non-zero 8 exit code 1. All done. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8882] Null Attribute Value Overlay
by openldap-its＠openldap.org 21 May '21

21 May '21

https://bugs.openldap.org/show_bug.cgi?id=8882 --- Comment #10 from Matthew Hardin <mhardin(a)symas.com> --- It appears that the source code for the module is no longer on the FTP server. Would someone from daasi please upload it and mark the correct URL in the comment? Thanks, -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 20 May '21

20 May '21

https://bugs.openldap.org/show_bug.cgi?id=6467 --- Comment #9 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • c216ef53 by Ondřej Kuzník at 2021-05-15T10:01:18+01:00 ITS#6467 Reset avl root after releasing the tree • 5943a334 by Ondřej Kuzník at 2021-05-15T10:01:51+01:00 ITS#6467 Adjust log message -- You are receiving this mail because: You are on the CC list for the issue.

1 0

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

20 May '21

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

1 0

[Issue 8882] Null Attribute Value Overlay
by openldap-its＠openldap.org 20 May '21

20 May '21

https://bugs.openldap.org/show_bug.cgi?id=8882 --- Comment #9 from tamim.ziai(a)daasi.de <tamim.ziai(a)daasi.de> --- The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by DAASI International. DAASI International has not assigned rights and/or interest in this work to any party. I, Tamim Ziai is authorized by DAASI International to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2019 DAASI International Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8679] Update release download page
by openldap-its＠openldap.org 19 May '21

19 May '21

https://bugs.openldap.org/show_bug.cgi?id=8679 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 8679] Update release download page
by openldap-its＠openldap.org 19 May '21

19 May '21

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

1 0

[Issue 9487] New: Committed changes not saved to accesslog during shutdown
by openldap-its＠openldap.org 17 May '21

17 May '21

https://bugs.openldap.org/show_bug.cgi?id=9487 Issue ID: 9487 Summary: Committed changes not saved to accesslog during shutdown Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: replication Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If there is inbound write traffic when slapd is asked to shut down, some of these operations get written to the main database but accesslog might be prevented from ADDing the log entry into its own database (presumably since slapd is shutting down already). This prevents these updates from being replicated in a deltasync scenario and silently desync. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs