- openldap-bugs - openldap.org

[Issue 9658] New: libldap fails to compile on Hurd: MAXPATHLEN undeclared
by openldap-its＠openldap.org 31 Aug '21

31 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9658 Issue ID: 9658 Summary: libldap fails to compile on Hurd: MAXPATHLEN undeclared 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: ryan(a)openldap.org Target Milestone: --- OpenLDAP 2.5 and later fails to compile on GNU/Hurd: libtool: compile: cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c request.c -fPIC -DPIC -o .libs/request.o 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]; | ^~~~~~~~~~~~~~ Makefile:435: recipe for target 'request.lo' failed make[2]: *** [request.lo] Error 1 This is not the same as ITS#9648. I have pulled latest master and the patch for that one does not solve it. GNU/Hurd actually does not have a MAXPATHLEN constant at all; paths are expected to be dynamically allocated. See: https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_… This is a low priority issue for me personally. I'm just filing it for tracking. I'm hoping someone from the GNU/Hurd community might be able to work on a patch. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 31 Aug '21

31 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #7 from Ondřej Kuzník <ondra(a)mistotebe.net> --- It seems this is limited to slapd main.c so a standalone lloadd keeps the original logging configuration/code/format. Maybe the logging code could move to a separate file so it can be shared between the two. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9657] New: Different access privileges required for SIMPLE BIND (attr: userPassword) and SASL BIND (whole entry)
by openldap-its＠openldap.org 31 Aug '21

31 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9657 Issue ID: 9657 Summary: Different access privileges required for SIMPLE BIND (attr: userPassword) and SASL BIND (whole entry) Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- I configure a database with: dn: cn=config objectClass: olcGlobal cn: config olcAuthzRegexp: uid=([^@,]+)(@aegee.org)?(,cn=aegee.org)?,cn=[^,]*,cn=auth uid=$1,ou=persons,o=AEGEE olcSaslSecProps: none ####################################################################### # LMDB database definitions ####################################################################### # dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbMaxSize: 10485760 olcSuffix: o=AEGEE olcRootDN: uid=zzz,ou=persons,o=AEGEE olcRootPW: zzz olcDbDirectory: /home/d/ldap/aegee olcDbIndex: objectClass eq olcAccess: to dn.one="ou=persons,o=AEGEE" attrs=userPassword by anonymous auth olcAccess: to dn.one="ou=persons,o=AEGEE" by self read fill the database with /usr/local/bin/ldapadd -x -w zzz -D "uid=zzz;ou=persons;o=AEGEE" -H ldap://localhost <<ABC dn:o=AEGEE o:AEGEE objectClass:organization telephoneNumber:+32 2 246 0320 street:Rue du Noyer / Notelaarsstraat 55 st:Brussels postalAddress:Rue du Noyer / Notelaarsstraat 55, 1000 Brussels, Belgium dn:ou=persons,o=AEGEE objectClass:organizationalUnit description:AEGEE members (persons) with account at https://my.aegee.eu/ dn: uid=lui.veve,ou=persons,o=AEGEE objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson sn: Veve cn: Lui Veve uid: lui.veve employeeNumber: 444 givenName: Lui mail: lui.veve@zzzz userPassword:: dXAx structuralObjectClass: inetOrgPerson ABC Its content is ( slapcat -n1 -F conf/ ) ---- dn: o=AEGEE o: AEGEE objectClass: organization telephoneNumber: +32 2 246 0320 street: Rue du Noyer / Notelaarsstraat 55 st: Brussels postalAddress: Rue du Noyer / Notelaarsstraat 55, 1000 Brussels, Belgium structuralObjectClass: organization entryUUID: 223703d3-812e-405c-b57e-4233b55847c3 creatorsName: uid=zzz,ou=persons,o=AEGEE createTimestamp: 20210830161645Z entryCSN: 20210830161645.797291Z#000000#000#000000 modifiersName: uid=zzz,ou=persons,o=AEGEE modifyTimestamp: 20210830161645Z dn: ou=persons,o=AEGEE objectClass: organizationalUnit description: AEGEE members (persons) with account at https://my.aegee.eu/ structuralObjectClass: organizationalUnit ou: persons entryUUID: 17f8ff72-250b-4cbd-873f-340aaed2f0d9 creatorsName: uid=zzz,ou=persons,o=AEGEE createTimestamp: 20210830161645Z entryCSN: 20210830161645.802430Z#000000#000#000000 modifiersName: uid=zzz,ou=persons,o=AEGEE modifyTimestamp: 20210830161645Z dn: uid=lui.veve,ou=persons,o=AEGEE objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson sn: Veve cn: Lui Veve uid: lui.veve employeeNumber: 444 givenName: Lui mail:: bHVpLnZldmVAenp6eiA= userPassword:: dXAx structuralObjectClass: inetOrgPerson entryUUID: 2e37d641-6865-4a08-87f9-b12653f52d12 creatorsName: uid=zzz,ou=persons,o=AEGEE createTimestamp: 20210830161645Z entryCSN: 20210830161645.806532Z#000000#000#000000 modifiersName: uid=zzz,ou=persons,o=AEGEE modifyTimestamp: 20210830161645Z ---- When I try to authenticate with SIMPLE BIND, OpenLDAP requests only access to the userPassword attribute: ldapwhoami -x -D "uid=lui.veve;ou=persons;o=AEGEE" -v -w up1 -H ldap://localhost/ logs: 612d04f3.27f67994 0x7f50731ac640 <= ldap_dn2bv(uid=lui.veve,ou=persons,o=AEGEE)=0 612d04f3.27f6a83b 0x7f50731ac640 => ldap_dn2bv(272) 612d04f3.27f6cbf9 0x7f50731ac640 <= ldap_dn2bv(uid=lui.veve,ou=persons,o=aegee)=0 612d04f3.27f6e92a 0x7f50731ac640 <<< dnPrettyNormal: <uid=lui.veve,ou=persons,o=AEGEE>, <uid=lui.veve,ou=persons,o=aegee> 612d04f3.27f7035b 0x7f50731ac640 conn=1001 op=0 BIND dn="uid=lui.veve,ou=persons,o=AEGEE" method=128 612d04f3.27f744d5 0x7f50731ac640 do_bind: version=3 dn="uid=lui.veve,ou=persons,o=AEGEE" method=128 612d04f3.27f77c7c 0x7f50731ac640 ==> mdb_bind: dn: uid=lui.veve,ou=persons,o=AEGEE 612d04f3.27f82a00 0x7f50731ac640 mdb_dn2entry("uid=lui.veve,ou=persons,o=aegee") 612d04f3.27f847bd 0x7f50731ac640 => mdb_dn2id("uid=lui.veve,ou=persons,o=aegee") 612d04f3.27f8a6f4 0x7f50731ac640 <= mdb_dn2id: got id=0x3 612d04f3.27f916cf 0x7f50731ac640 => mdb_entry_decode: 612d04f3.27f942bb 0x7f50731ac640 <= mdb_entry_decode 612d04f3.27f96490 0x7f50731ac640 => access_allowed: result not in cache (userPassword) 612d04f3.27f97b35 0x7f50731ac640 => access_allowed: auth access to "uid=lui.veve,ou=persons,o=AEGEE" "userPassword" requested 612d04f3.27f9ab7f 0x7f50731ac640 => dn: [1] ou=persons,o=aegee 612d04f3.27f9ccc7 0x7f50731ac640 => acl_get: [1] matched 612d04f3.27f9ddb2 0x7f50731ac640 => acl_get: [1] attr userPassword 612d04f3.27f9f63f 0x7f50731ac640 => acl_mask: access to entry "uid=lui.veve,ou=persons,o=AEGEE", attr "userPassword" requested 612d04f3.27fa0913 0x7f50731ac640 => acl_mask: to value by "", (=0) 612d04f3.27fa24a1 0x7f50731ac640 <= check a_dn_pat: anonymous 612d04f3.27fa492f 0x7f50731ac640 <= acl_mask: [1] applying auth(=xd) (stop) 612d04f3.27fa5bbd 0x7f50731ac640 <= acl_mask: [1] mask: auth(=xd) 612d04f3.27fa721c 0x7f50731ac640 => slap_access_allowed: auth access granted by auth(=xd) 612d04f3.27fa8306 0x7f50731ac640 => access_allowed: auth access granted by auth(=xd) 612d04f3.27fa9f20 0x7f50731ac640 conn=1001 op=0 BIND dn="uid=lui.veve,ou=persons,o=AEGEE" mech=SIMPLE bind_ssf=0 ssf=0 612d04f3.27fb0385 0x7f50731ac640 do_bind: v3 bind: "uid=lui.veve,ou=persons,o=AEGEE" to "uid=lui.veve,ou=persons,o=AEGEE" When I try to SASL connect, then OpenLDAP requests access to the whole uid=lui.veve,ou=persons,o=AEGEE entry: ldapwhoami -Y LOGIN -U"lui.veve" -v -w up1 -H ldap://localhost/ logs: 612d053d.03ab64b8 0x7f50731ac640 => ldap_bv2dn(uid=lui.veve,ou=persons,o=AEGEE,0) 612d053d.03abb462 0x7f50731ac640 <= ldap_bv2dn(uid=lui.veve,ou=persons,o=AEGEE)=0 612d053d.03abddda 0x7f50731ac640 => ldap_dn2bv(272) 612d053d.03abf0ad 0x7f50731ac640 <= ldap_dn2bv(uid=lui.veve,ou=persons,o=aegee)=0 612d053d.03ac070c 0x7f50731ac640 <<< dnNormalize: <uid=lui.veve,ou=persons,o=aegee> 612d053d.03ac2626 0x7f50731ac640 <==slap_sasl2dn: Converted SASL name to uid=lui.veve,ou=persons,o=aegee 612d053d.03ac68fe 0x7f50731ac640 slap_sasl_getdn: dn:id converted to uid=lui.veve,ou=persons,o=aegee 612d053d.03ac82e9 0x7f50731ac640 SASL Canonicalize [conn=1002]: slapAuthcDN="uid=lui.veve,ou=persons,o=aegee" 612d053d.03acd965 0x7f50731ac640 => mdb_search 612d053d.03ada119 0x7f50731ac640 mdb_dn2entry("uid=lui.veve,ou=persons,o=aegee") 612d053d.03adcf7a 0x7f50731ac640 => mdb_dn2id("uid=lui.veve,ou=persons,o=aegee") 612d053d.03ae10f4 0x7f50731ac640 <= mdb_dn2id: got id=0x3 612d053d.03ae33e0 0x7f50731ac640 => mdb_entry_decode: 612d053d.03ae6313 0x7f50731ac640 <= mdb_entry_decode 612d053d.03ae845b 0x7f50731ac640 => access_allowed: auth access to "uid=lui.veve,ou=persons,o=AEGEE" "entry" requested 612d053d.03aea02f 0x7f50731ac640 => dn: [1] ou=persons,o=aegee 612d053d.03aeba1a 0x7f50731ac640 => acl_get: [1] matched 612d053d.03aed0bf 0x7f50731ac640 => dn: [2] ou=persons,o=aegee 612d053d.03aee392 0x7f50731ac640 => acl_get: [2] matched 612d053d.03aef47c 0x7f50731ac640 => acl_get: [2] attr entry 612d053d.03af0c39 0x7f50731ac640 => acl_mask: access to entry "uid=lui.veve,ou=persons,o=AEGEE", attr "entry" requested 612d053d.03af2f6a 0x7f50731ac640 => acl_mask: to all values by "", (=0) 612d053d.03af45c9 0x7f50731ac640 <= check a_dn_pat: self 612d053d.03af513f 0x7f50731ac640 <= acl_mask: no more <who> clauses, returning =0 (stop) 612d053d.03af626f 0x7f50731ac640 => slap_access_allowed: auth access denied by =0 612d053d.03af7a71 0x7f50731ac640 => access_allowed: no more rules This is inconsistent. SASL bind shall also request only AUTH access to the userPassword, just as SIMPLE BIND does. Moreover, https://www.openldap.org/doc/admin25/access-control.html#Basic%20ACLs does suggest: Generally one should start with some basic ACLs such as: access to attrs=userPassword by self =xw by anonymous auth by * none access to * by self write by users read by * none So the suggestion is to grant "by anonymous auth" access only to attrs=userPassword , before granting any other access. If I change to olcAccess: to dn.one="ou=persons,o=AEGEE" by self read by anonymous auth then both SASL BIND and SIMPLE BIND work. Version 2.5.7-g22d1c5954e8629b. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9655] New: Expose the SNI hostname to olcAccess
by openldap-its＠openldap.org 30 Aug '21

30 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9655 Issue ID: 9655 Summary: Expose the SNI hostname to olcAccess Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- Since OpenLDAP now supports SNI, it apparently knows to which Host the client has connected, when the server is reachable under many names. • Expose the negotiated hostname to oclAccess and provide example how to limit the namingContext on the root DSE based on the requested host Rationale: HTTP servers offer the concept of virtual domains, where they serve different content behind the same IP, based on the Host: header. I want to offer public, anonymous LDAP access, but the returned results shall be completely different, and depend on the contacted host. The statements in the <WHO> field peername=<peername>, sockname=<sockname>, domain=<domain>, and sockurl=<sockurl> are evaluated only based on the contacting system (do not depend on the requested domain). (Maybe the “contacting sockurl” can do this, but this is not very clear from the documentation). So they serve similar purpose, but ignore SNI. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9654] New: Allow using both Elliptic curves and RSA certificate
by openldap-its＠openldap.org 30 Aug '21

30 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9654 Issue ID: 9654 Summary: Allow using both Elliptic curves and RSA certificate Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- sendmail and Cyrus IMAP allow to set two TLS server certificates -one RSA and EC. When the client supports Elliptic curves, the smaller EC certificate is used. Likewise it accepts two private keys, in case the private key is not included in the certificate file. In sendmail and Cyrus IMAP, two certificates are set in the same directive, separated with comma: define(`confSERVER_CERT', `/etc/zzz/fullchain.pem,/etc/zzz/fullchain_ec.pem') define(`confSERVER_KEY', `/etc/zzz/privkey.pem,/etc/zzz/privkey_ec.pem') In Cyrus IMAP the code dealing with this for OpenSSL is at https://github.com/cyrusimap/cyrus-imapd/blob/master/imap/tls.c#L453 : cf1/kf1 is the fist public/private key, cf2/kf2 are the second. In sendmail the code is in sendmail/tls.c:inittls() - it calls SSL_CTX_use_PrivateKey_file twice - once with keyfile and once with kf2 (keyfile 2). • Extend OpenLDAP to accept several certificates (RSA/EC) - either per permitting several (comma separated) values in olcTLSCertificateFile/olcTLSCertificateKeyFile , or by allowing several occurrences of the property. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9587] New: Admin guide: Need example partial replication configuration
by openldap-its＠openldap.org 27 Aug '21

27 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9587 Issue ID: 9587 Summary: Admin guide: Need example partial replication configuration Product: OpenLDAP Version: 2.5.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The admin guide states: Syncrepl supports partial, sparse, and fractional replications but there are no example configurations for partial replication to draw from. This needs to be added to the guide. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

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

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9156 --- Comment #13 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • c4d399c2 by Quanah Gibson-Mount at 2021-08-26T15:43:24+00:00 ITS#9156 - Remove ppolicy.schema from README Also remove nadf.schema, that got removed some time long ago -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8862] typos manual slapd-mdb
by openldap-its＠openldap.org 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=8862 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Quanah Gibson-Mount from comment #6) > (In reply to dpa-openldap(a)aegee.org from comment #5) > > For me “as large a value as possible…” sounds without “a” better. > > Then it would no longer be grammatically correct. > > "as large a value as possible" is correct. An alternative way to phrase it would be "as large of a value as possible", but both are correct statements. "as large value as possible" is not a correct statement in any form in this context. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8862] typos manual slapd-mdb
by openldap-its＠openldap.org 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=8862 --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to dpa-openldap(a)aegee.org from comment #5) > For me “as large a value as possible…” sounds without “a” better. Then it would no longer be grammatically correct. "as large a value as possible" is correct. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8862] typos manual slapd-mdb
by openldap-its＠openldap.org 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=8862 --- Comment #5 from dpa-openldap(a)aegee.org <dpa-openldap(a)aegee.org> --- For me “as large a value as possible…” sounds without “a” better. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8862] typos manual slapd-mdb
by openldap-its＠openldap.org 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=8862 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to dpa-openldap(a)aegee.org from comment #3) > How about this sentence: > > > It is important to set this to as large a value as possible… What about it? It's a correct statement. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8862] typos manual slapd-mdb
by openldap-its＠openldap.org 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=8862 --- Comment #3 from dpa-openldap(a)aegee.org <dpa-openldap(a)aegee.org> --- How about this sentence: > It is important to set this to as large a value as possible… -- 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 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=6949 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mhardin(a)symas.com --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** Issue 9492 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 6097] MMR problems with deletes
by openldap-its＠openldap.org 24 Aug '21

24 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=6097 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9647 -- 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 19 Aug '21

19 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=6097 --- Comment #4 from Ondřej Kuzník <ondra(a)mistotebe.net> --- So testing confirms the systems converge right now, extremely noisily (the add or delete fails, we go into refresh, etc.) but things settle in the right way (the parent is removed (made into glue) and the child remains. There are situation where is fails but those are bugs (to be) filed separately. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9628] New: Incorrect handling of c_n_ops_executing counter when using an asynchronous backend (back-asyncmeta)
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9628 Issue ID: 9628 Summary: Incorrect handling of c_n_ops_executing counter when using an asynchronous backend (back-asyncmeta) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9611] New: no structural objectclass in configuration table
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9611 Issue ID: 9611 Summary: no structural objectclass in configuration table Product: OpenLDAP Version: 2.5.5 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: jb00356987(a)techmahindra.com Target Milestone: --- Dears, When I tried to start sldap 2.5.5 I get following error : 60eff599.06749e9d 0x7fb62750f740 <<< dnNormalize: <cn=manager,cn=config> 60eff599.0674bad5 0x7fb62750f740 <= str2entry(cn=module{0}) -> 0x1193828 60eff599.06752650 0x7fb62750f740 : config_add_internal: DN="cn=module{0},cn=config" no structural objectClass in configuration table 60eff599.06753c3c 0x7fb62750f740 config error processing cn=module{0},cn=config: 60eff599.0675a8bc 0x7fb62750f740 send_ldap_result: conn=-1 op=0 p=0 60eff599.067611e4 0x7fb62750f740 build-corp-M1 destroy: freeing system resources. 60eff599.06767673 0x7fb62750f740 slapd stopped. 60eff599.06770970 0x7fb62750f740 connections_destroy: nothing to destroy. I don't understand why I get it as I'm able to run slapd 2.4.59 with same config/DB. Can you advice ? Thx, J-L. -- You are receiving this mail because: You are on the CC list for the issue.

1 15

[Issue 9569] New: objectClass Violation with lastbind and delta-syncrepl
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9569 Issue ID: 9569 Summary: objectClass Violation with lastbind and delta-syncrepl Product: OpenLDAP Version: 2.4.58 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gnoe(a)symas.com Target Milestone: --- If olcLastBind is set to true in a delta-syncrepl environment, slapd fails to add auditModify entries for lastbind to the accesslog due to an objectClass violation. The auditModify object lacks the required reqMod attributes. The lastbind module is not in use. The ppolicy overlay is also in use. It shows in the slapd log as: Jun 03 13:05:34 l-02992-d5a slapd[18715]: Entry(reqStart=20210603170529.000262Z,cn=accesslog): object class 'auditModify' requires attribute 'reqMod' Jun 03 13:05:34 l-02992-d5a slapd[18715]: accesslog_response: got result 0x41 adding log entry reqStart=20210603170529.000262Z,cn=accesslog -- You are receiving this mail because: You are on the CC list for the issue.

1 15

[Issue 9625] New: ppolicy: spamming log
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9625 Issue ID: 9625 Summary: ppolicy: spamming log Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Noticed on a few recent deployments that ppolicy is spamming the logs with: ppolicy_bind: Setting warning for password expiry <DN> = 0 second on every bind. Haven't noticed this in the past but the code has been like this since 2004. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9624] New: Issues in client state tracking
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9624 Issue ID: 9624 Summary: Issues in client state tracking Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- There are two places that don't track client state (BINDING/OPEN) correctly: - handle_one_request() reads c_state/c_io_state without holding the appropriate mutex - operation_unlink_client() assumes that if state is BINDING, the operation we're just unlinking is a bind request. However the client could have sent another operation without waiting for the bind response, we shouldn't touch state when disposing of those -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9549] New: ldapvc needs a man page
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9549 Issue ID: 9549 Summary: ldapvc needs a man page Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- The ldapvc tool was added in 2.5, but there is no man page for it yet. I've opened this as a separate ITS, rather than append to ITS#9284, because ldapvc is not in contrib and is always installed. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9443] New: Admin guide: Need section on lloadd and load balancer as slapd module
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9443 Issue ID: 9443 Summary: Admin guide: Need section on lloadd and load balancer as slapd module Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: blocker Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The admin guide currently has no documentation on the new lloadd daemon or the ability to set up the load balancer as a module inside of slapd. This is a release requirement. -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 9637] New: back-mdb idlexp max is 30, not 31
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9637 Issue ID: 9637 Summary: back-mdb idlexp max is 30, not 31 Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Even so, it's ridiculous to use 2 billion slot IDLs (16GB each) unless you have hundreds of GB of RAM. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9630] New: back-sql leaves db transaction open after a bind or search operation
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9630 Issue ID: 9630 Summary: back-sql leaves db transaction open after a bind or search operation Product: OpenLDAP Version: 2.4.58 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: aapo.romu(a)eficode.com Target Milestone: --- Created attachment 833 --> https://bugs.openldap.org/attachment.cgi?id=833&action=edit Close transactions after bind or search operation back-sql leaves db transaction open after a bind or search operation. This prevents ie. PostgreSQL to perform VACUUM operations and seems also contribute to decreased performance. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9621] New: back-mdb multival NULL matchingrule crash
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9621 Issue ID: 9621 Summary: back-mdb multival NULL matchingrule crash Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When configured for multival, back-mdb may crash if the attribute schema has no equality matching rule. -- 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