openldap-bugs April 2021

openldap-bugs@openldap.org

1 participants
221 discussions

[Issue 9515] New: datamorph overlay fails to build
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9515 Issue ID: 9515 Summary: datamorph overlay fails to build Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- datamorph.c:1706:30: error: 'avl_dup_error' undeclared (first use in this function); did you mean 'ldap_avl_dup_error'? transformation_info_cmp, avl_dup_error ); ^~~~~~~~~~~~~ ldap_avl_dup_error datamorph.c:1706:30: note: each undeclared identifier is reported only once for each function it appears in datamorph.c: In function 'datamorph_add_mapping': datamorph.c:1771:33: error: 'avl_dup_error' undeclared (first use in this function); did you mean 'ldap_avl_dup_error'? transformation_mapping_cmp, avl_dup_error ); ^~~~~~~~~~~~~ ldap_avl_dup_error datamorph.c: In function 'datamorph_ldadd_info_cleanup': datamorph.c:1795:4: error: 'avl_dup_error' undeclared (first use in this function); did you mean 'ldap_avl_dup_error'? avl_dup_error ) ) { ^~~~~~~~~~~~~ ldap_avl_dup_error datamorph.c: In function 'datamorph_ldadd_mapping_cleanup': datamorph.c:1853:4: error: 'avl_dup_error' undeclared (first use in this function); did you mean 'ldap_avl_dup_error'? avl_dup_error ) ) { ^~~~~~~~~~~~~ ldap_avl_dup_error datamorph.c: In function 'datamorph_config_build_attr': datamorph.c:1965:10: warning: implicit declaration of function 'avl_apply'; did you mean 'acl_append'? [-Wimplicit-function-declaration] return avl_apply( info->ti_enum.to_db, datamorph_config_build_enum, ^~~~~~~~~ acl_append datamorph.c: In function 'datamorph_cfadd': datamorph.c:1988:30: error: 'avl_dup_error' undeclared (first use in this function); did you mean 'ldap_avl_dup_error'? transformation_info_cmp, avl_dup_error ); ^~~~~~~~~~~~~ ldap_avl_dup_error -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9511] New: make depend shouldn't error on slapi/plugin.c if no ltdl.h found
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9511 Issue ID: 9511 Summary: make depend shouldn't error on slapi/plugin.c if no ltdl.h found Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- make depend throws the following error if ltdl.h is not found: make[3]: Entering directory '/home/quanah/qtest/openldap/qbuild/servers/slapd/slapi' ../../../../build/mkdep -l -d "../../../../servers/slapd/slapi" -c "cc" -m "-M" -I../../../include -I.. -I. -I../../../../include -I../../../../servers/slapd/slapi/.. -I../../../../servers/slapd/slapi plugin.c slapi_pblock.c slapi_utils.c printmsg.c slapi_ops.c slapi_dn.c slapi_ext.c slapi_overlay.c ../../../../servers/slapd/slapi/plugin.c:33:10: fatal error: ltdl.h: No such file or directory #include <ltdl.h> ^~~~~~~~ I.e., it should probably just exit if HAVE_LTDL_H is not true or similar. At the least: diff --git a/servers/slapd/slapi/plugin.c b/servers/slapd/slapi/plugin.c index 7ebc23f3a..f816ea34e 100644 --- a/servers/slapd/slapi/plugin.c +++ b/servers/slapd/slapi/plugin.c @@ -30,7 +30,9 @@ /* * Note: if ltdl.h is not available, slapi should not be compiled */ +#ifdef HAVE_LTDL_H #include <ltdl.h> +#endif gets rid of the error during make depend -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9396] New: Docs might recommend applicationProcess for ppolicy entries
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9396 Issue ID: 9396 Summary: Docs might recommend applicationProcess for ppolicy entries Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Created attachment 779 --> https://bugs.openldap.org/attachment.cgi?id=779&action=edit Suggested doc patch Hello, The ppolicy section of the Admin Guide does not say why the "people" object class is present in the example policy entry. I suggest that the docs explain. Otherwise the reader is left wondering why the particular choice of structural object class was made. The less informed reader is left wondering why a second object class is required at all. I also suggest that instead of the "people" object class, that the applicationProcess object class be used in the example to provide the structural object class the entry requires. The slapo-ppolicy man page might also provide guidance. Attached is a suggested patch, provided so that you have something to work from. If you're not happy with the patch go ahead and discard it, I'm not advocating any particular wording. I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9337] New: Slapd crash with lastbind overlay
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9337 Issue ID: 9337 Summary: Slapd crash with lastbind overlay Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: frederic.poisson(a)admin.gmessaging.net Target Milestone: --- Hello, I have an issue with a 2.4.50 OpenLDAP instance configured with replication (1 master and 1 replica), and when i activate the lastbind overlay. The replica server crash like this : slapd[8433]: segfault at 1d0 ip 000000000049f70b sp 00007f189f7fd1a0 error 4 in slapd[400000+1d8000] The database is this one with overlay loaded : dn: cn=module{0},cn=config olcModuleLoad: {0}sssvlv.la olcModuleLoad: {1}ppolicy.la olcModuleLoad: {2}syncprov.la olcModuleLoad: {3}lastbind.la olcModuleLoad: {4}pw-sha2.la dn: olcDatabase={3}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcUpdateRef: ldap://master.server:389/ If i add this configuration it crash : dn: olcOverlay={2}lastbind objectClass: olcOverlayConfig objectClass: olcLastBindConfig olcOverlay: {2}lastbind olcLastBindPrecision: 60 olcLastBindForwardUpdates: TRUE Does the release 2.5.51 or 2.5.52 could solve this issue ? Regards, -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9500] New: back-mdb: index generation failiure
by openldap-its＠openldap.org 06 May '21

06 May '21

https://bugs.openldap.org/show_bug.cgi?id=9500 Issue ID: 9500 Summary: back-mdb: index generation failiure Product: OpenLDAP Version: 2.5 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Operating system CentOS Linux release 8.3.2011 OpenLDAP version 2.5.2 beta Error adding records. After app. 65539 records. Clientside error: index generation failed Server log: Mar 12 19:17:48 tx01 slapd[30394]: conn=1015 op=4 ADD dn="cn=foo,ou=Roles,ou=RBAC,dc=example,dc=com" Mar 12 19:17:48 tx01 slapd[30394]: slap_get_csn: conn=1015 op=4 generated new csn=20210312191748.484367Z#000000#001#000000 manage=1 Mar 12 19:17:48 tx01 slapd[30394]: slap_queue_csn: queueing 0x7d3d842146e0 20210312191748.484367Z#000000#001#000000 Mar 12 19:17:48 tx01 slapd[30394]: => mdb_idl_insert_keys: c_get hi failed: MDB_NOTFOUND: No matching key/data pair found (-30798) Mar 12 19:17:48 tx01 slapd[30394]: conn=1015 op=4 RESULT tag=105 err=80 qtime=0.000042 etime=0.001244 text=index generation failed Mar 12 19:17:48 tx01 slapd[30394]: slap_graduate_commit_csn: removing 0x7d3d842146e0 20210312191748.484367Z#000000#001#000000 -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9461] New: Deletion causes cursor to repeat
by openldap-its＠openldap.org 06 May '21

06 May '21

https://bugs.openldap.org/show_bug.cgi?id=9461 Issue ID: 9461 Summary: Deletion causes cursor to repeat Product: LMDB Version: 0.9.27 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: github(a)nicwatson.org Target Milestone: --- Created attachment 795 --> https://bugs.openldap.org/attachment.cgi?id=795&action=edit repro of cursor delete bug See attached source code for reproduction. The test behaves correctly in 0.9.26 and fails in 0.9.27 and 0.9.28. The failing sequence is: 1. In a dupsort DB, create two different keys and values. 2. Create a cursor, setting the position to the second key. 3. Delete the first key. 4. Have the cursor get the next key. mdb_get_key will return the second key instead of returning MDB_NOT_FOUND. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 8078] The configured TimeOut in back-meta overlay is not used during the connection phase
by openldap-its＠openldap.org 28 Apr '21

28 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8078 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 8078] The configured TimeOut in back-meta overlay is not used during the connection phase
by openldap-its＠openldap.org 28 Apr '21

28 Apr '21

1 0

[Issue 8078] The configured TimeOut in back-meta overlay is not used during the connection phase
by openldap-its＠openldap.org 28 Apr '21

28 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8078 --- Comment #2 from nivanova(a)symas.com <nivanova(a)symas.com> --- I don't think this is actually a bug. This is not what network_timeout is meant for. The timeout value for receiving a response is actually the per-operation timeouts, and these are, in fact, honored. ldap_result is called with a tv of LDAP_BACK_RESULT_UTIMEOUT to avoid multiple threads getting stuck waiting for the same connection to become available, but the call is repeated until the configured operation timeout is reached. This is how both back-ldap and back-meta operate, and it is by design. network-timeout is provided (by setting LDAP_OPT_NETWORK_TIMEOUT) to ldap_pvt_poll when a new connection is created or an ldap request is sent. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9533] New: OpenLdap hangs when creating many databases
by openldap-its＠openldap.org 28 Apr '21

28 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=9533 Issue ID: 9533 Summary: OpenLdap hangs when creating many databases Product: OpenLDAP Version: 2.4.57 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: akrush24(a)gmail.com Target Milestone: --- I initialize openldap cluster with config: ``` dn: cn=config objectClass: olcGlobal cn: config olcPidFile: /run/openldap/slapd.pid olcArgsFile: /run/openldap/slapd.args olcServerID: 1 ldaps://ldap.ldap01.xxx.ru:637 olcServerID: 2 ldaps://ldap.ldap02.xxx.ru:637 olcServerID: 3 ldaps://ldap.ldap03.xxx.ru:637 olcTLSCACertificateFile: /etc/openldap/ssl/ca.pem olcTLSCertificateKeyFile: /etc/openldap/ssl/private.key olcTLSCertificateFile: /etc/openldap/ssl/server.crt dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib/openldap olcModuleload: back_mdb.so olcModuleload: syncprov.so dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///etc/openldap/schema/core.ldif include: file:///etc/openldap/schema/cosine.ldif include: file:///etc/openldap/schema/inetorgperson.ldif include: file:///etc/openldap/schema/nis.ldif dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage olcRootPW: Ohtheis7ur9Qua6e olcSyncRepl: rid=001 provider=ldaps://ldap.ldap01.xxx.ru:637 binddn=cn=config bindmethod=simple credentials=Ohtheis7ur9Qua6e searchbase=cn=config type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldaps://ldap.ldap02.xxx.ru:637 binddn=cn=config bindmethod=simple credentials=Ohtheis7ur9Qua6e searchbase=cn=config type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=003 provider=ldaps://ldap.ldap03.xxx.ru:637 binddn=cn=config bindmethod=simple credentials=Ohtheis7ur9Qua6e searchbase=cn=config type=refreshAndPersist retry="5 5 300 5" timeout=1 olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov ``` Then I try to create many bases in a loop: My base template: ``` /etc/openldap/conf.d # cat > newdb.ldiff.template <<EOF! dn: olcDatabase={#DITID#}mdb,cn=config changetype: add objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {#DITID#}mdb olcSuffix: dc=devmail,dc=srv,dc=local olcDbMaxSize: 1073741824 olcRootDN: cn=admin,dc=devmail,dc=srv,dc=local olcRootPW: 123 olcDbDirectory: /var/lib/openldap/openldap-data/ olcDbIndex: objectClass eq olcSyncRepl: rid=001 provider=ldaps://ldap.ldap01.xxx.local:637 binddn=cn=admin,dc=devmail,dc=srv,dc=local bindmethod=simple credentials=123 searchbase=dc=devmail,dc=srv,dc=local type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldaps://ldap.ldap02.xxx.local:637 binddn=cn=admin,dc=devmail,dc=srv,dc=local bindmethod=simple credentials=123 searchbase=dc=devmail,dc=srv,dc=local type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=003 provider=ldaps://ldap.ldap03.xxx.local:637 binddn=cn=admin,dc=devmail,dc=srv,dc=local bindmethod=simple credentials=123 searchbase=dc=devmail,dc=srv,dc=local type=refreshAndPersist retry="5 5 300 5" timeout=1 olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={#DITID#}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov EOF! ``` For example 100 dbs ``` for I in $(seq 1 100);do sed -e "s/devmail/devmail${I}/g" -e "s/#DITID#/${I}/g" ./newdb.ldiff.template > newdb${I}.ldiff ldapmodify -H ldapi://%2Fvar%2Frun%2Fopenldap%2Fldapi -Y EXTERNAL -f ./newdb${I}.ldiff done ``` As a result my cluster first slows down and then nodes hang up. Logs show nothing, no activity. Connect via ldapmodify or other cli utilities just hangs. In such a situation rebooting a single node of the cluster helps, until the cluster becomes unresponsive once again. Please tell me what could be the problem? Could my cluster configuration be incorrect? The problem manifests itself only in situation where I have many databases, e.g. more than 10. With one-two dbs all works as expected. I have also tried using different in-built database backends, to no avail. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

← Newer
1
...
7
8
9
10
11
12
13
...
23
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2021