openldap-bugs

openldap-bugs@openldap.org

1 participants
20896 discussions

[Issue 8820] ldap_get_attribute_ber() function needs to be documented
by openldap-its＠openldap.org 06 May '21

06 May '21

https://bugs.openldap.org/show_bug.cgi?id=8820 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.4 |2.5.5 -- 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 06 May '21

06 May '21

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

1 0

[Issue 8721] Quarantine in meta backend
by openldap-its＠openldap.org 06 May '21

06 May '21

https://bugs.openldap.org/show_bug.cgi?id=8721 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Assignee|smckinney(a)symas.com |ondra(a)mistotebe.net Status|UNCONFIRMED |IN_PROGRESS --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- https://git.openldap.org/openldap/openldap/-/merge_requests/327 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9545] New: Compile warnings in OpenLDAP 2.4 branch
by openldap-its＠openldap.org 04 May '21

04 May '21

https://bugs.openldap.org/show_bug.cgi?id=9545 Issue ID: 9545 Summary: Compile warnings in OpenLDAP 2.4 branch Product: OpenLDAP Version: 2.4.58 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- There are a few compile warnings that are present in OPENLDAP_REL_ENG_2_4 libraries. I understand that 2.4 is not in an active development state anymore but I think it's important to keep it as clean as possible as the libraries are actively used by other projects. The warnings: tls2.c: In function ‘ldap_int_tls_connect’: tls2.c:378:9: warning: implicit declaration of function ‘ldap_pvt_tls_check_hostname’ [-Wimplicit-function-declaration] 378 | err = ldap_pvt_tls_check_hostname( ld, ssl, host ); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ thr_posix.c: In function ‘ldap_pvt_thread_set_concurrency’: thr_posix.c:93:9: warning: implicit declaration of function ‘pthread_setconcurrency’ [-Wimplicit-function-declaration] 93 | return pthread_setconcurrency( n ); | ^~~~~~~~~~~~~~~~~~~~~~ thr_posix.c: In function ‘ldap_pvt_thread_get_concurrency’: thr_posix.c:107:9: warning: implicit declaration of function ‘pthread_getconcurrency’; did you mean ‘ldap_pvt_thread_get_concurrency’? [-Wimplicit-function-declaration] 107 | return pthread_getconcurrency(); | ^~~~~~~~~~~~~~~~~~~~~~ | ldap_pvt_thread_get_concurrency charray.c: In function ‘ldap_charray2str’: charray.c:269:3: warning: ‘strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=] 269 | strncpy( p, *v, len ); | ^~~~~~~~~~~~~~~~~~~~~ charray.c:268:9: note: length computed here 268 | len = strlen( *v ); | ^~~~~~~~~~~~ Additional information: The 'implicit declaration' warnings can be potentially harmful. If the compiler does not see the declaration of a function _before_ it is called, it assumes the following implicit declaration instead: int fnc_name(); ... which has severe consequences: 1. Only sizeof(int) bytes are read from the return value even if the function returns a different type. 2. Count and type of the arguments passed to the functions are not checked at all because the compiler has no means to know what the callee expects as parameters. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9543] New: Patch : Customize CN check on TLS
by openldap-its＠openldap.org 01 May '21

01 May '21

https://bugs.openldap.org/show_bug.cgi?id=9543 Issue ID: 9543 Summary: Patch : Customize CN check on TLS Product: OpenLDAP Version: unspecified Hardware: i386 OS: Other Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: julien.wadel(a)belledonne-communications.com Target Milestone: --- Created attachment 821 --> https://bugs.openldap.org/attachment.cgi?id=821&action=edit Patch on master Hi, I added a feature that allow to customize the domain name on TLS hostname verification. With it, we can use an IP that comes from our DNS resolver. It is mainly used when we want launch test units with a private server where the IP and domains are private. In our case, we use our own dns resolver (internal code) which give us an IP that is passed to LDAP. As we know the domain name but not LDAP, we pass it to it for checking (it's not an ignore option) Here is the commit from our repository (based from 2.4): https://gitlab.linphone.org/BC/public/external/openldap/-/commit/a4fef2181c… Here is the branch from the HEAD of your current master (one commit, parent 60b7dc731ce9f2424a4a56d78ae99270a3c6239c) https://gitlab.linphone.org/BC/public/external/openldap/-/tree/feature/host… Here is the branch from the HEAD of OPENLDAP_REL_ENG_2_4 (one commit, parent faf2c4e78641f69df3fdea5f97ddb058946f2051) https://gitlab.linphone.org/BC/public/external/openldap/-/tree/feature/host… I attached the diff on master Regards -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[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

[Issue 9513] New: Enhanced debug output
by openldap-its＠openldap.org 23 Apr '21

23 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=9513 Issue ID: 9513 Summary: Enhanced debug output Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- While debugging ITS#9479 I needed more information on which threads were doing what actions. Also, when looking for delays/hangs/race conditions, the 1-second granularity of the debug msg timestamp was inadequate. And also, some of the debug output for the Search operation was being done in separate Debug calls for a single line of output. This gets jumbled up pretty badly if other threads are printing output as well. New patch set will extend the debug timestamp to have fractional seconds too; it will use clock_gettime for nanosecond resolution if available, otherwise use gettimeofday for microsecond resolution. Also tweak the Search debug output to only use one Debug invocation per line of output. This is MR!279. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs