https://bugs.openldap.org/show_bug.cgi?id=9946
Issue ID: 9946
Summary: TLS: could not load verify locations
Product: OpenLDAP
Version: unspecified
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hrishikesh.durg(a)gmail.com
Target Milestone: ---
Hi,
Am seeing below errors on one of ldap proxy server --ANy clue how to fix it ?
===============
635a3252 openotp_parse_conf: global: server_url =
https://iad37-c-sec-afe-01.us6.oraclecloud.com:443/openotp/,https://ch3-c-s…
635a3252 openotp_parse_conf: global: soap_timeout = 10
635a3252 openotp_parse_conf: global: user_settings = ChallengeMode=No
635a3252 openotp_parse_conf: global: uid_attribute = uid, cn
635a3252 openotp_parse_conf: global: client_id = LDAP
635a3252 openotp_parse_conf: global: default_domain = oraclecloud
635a3252 openotp_parse_conf: global: server_policy = 1
635a3252 openotp_parse_conf: global: status_cache = 10
635a3252 openotp_parse_conf: global: nolock_usernames =
ldapro-oci-sharedservices,ldapro-saas,ldapro-sbs
635a3252 openotp_parse_conf: global: denied_usernames = (none)
635a3252 openotp_init: Initializing libopenotp
TLS: could not load verify locations (file:`/opt/ldproxy/conf/ca.crt',dir:`').
TLS: error:02001002:system library:fopen:No such file or directory
bss_file.c:175
TLS: error:2006D080:BIO routines:BIO_new_file:no such file bss_file.c:182
TLS: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system
lib by_file.c:253
635a3252 main: TLS init def ctx failed: -1
635a3252 slapd stopped.
635a3252 connections_destroy: nothing to destroy.
===========
Not seeing anything when checked on location specified from logs :
[root@ldap-proxy-01 certs]# ls -l /opt/ldproxy
total 0
drwxr-xr-x. 2 root root 48 Nov 4 08:27 logs
[root@ldap-proxy-01 certs]#
==============
ldap.conf file looks as below :
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
TLS_CACERTDIR /etc/openldap/certs
# Turning this off breaks GSSAPI used with krb5 when rdns = false
SASL_NOCANON on
Any help /clue is much appreciated
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9945
Issue ID: 9945
Summary: Unable to import initial configuration (cn=config)
Product: OpenLDAP
Version: 2.5.13
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: annamariet(a)crimsonlogic.com
Target Milestone: ---
Created attachment 927
--> https://bugs.openldap.org/attachment.cgi?id=927&action=edit
slapd.ldif
I was able to install openldap 2.5.13 successfully but I was getting error
below whenever I will import the initial configuration using this command:
/usr/local/sbin/slapadd -n 0 -F /usr/local/etc/slapd.d -l
/usr/local/etc/openldap/slapd.ldif
Error:
str2entry: entry -1 has multiple DNs "cn=config" and "cn=module,cn=config"
slapadd: could not parse entry (line=1)
Closing DB...
In my slapd.ldif file, both DNs are enabled. Only this cn=module is throwing
error while other dn e.g. dn: cn=schema,cn=config are accepted. Am I missing
some packages or RPMs?
dn: cn=config
objectClass: olcGlobal
cn: config
.
.
.
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulepath: /usr/local/libexec/openldap
olcModuleload: back_mdb.la
olcModuleload: back_ldap.la
olcModuleload: back_passwd.la
olcModuleload: back_shell.la
.
.
.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9045
--- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Removed from RE25 as it is missing the requisite libldap functionality to fix
the issue there.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9045
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|2.5.14 |2.6.4
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9045
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |TEST
Status|CONFIRMED |RESOLVED
--- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
head:
• a6f3106a
by OndÅ™ej KuznÃk at 2022-10-31T18:16:42+00:00
ITS#9045 Do not share cn=config entries with outside code
RE26:
• 99a7c141
by OndÅ™ej KuznÃk at 2022-11-01T17:05:36+00:00
ITS#9045 Do not share cn=config entries with outside code
RE25:
• ce7a7997
by OndÅ™ej KuznÃk at 2022-11-01T17:07:15+00:00
ITS#9045 Do not share cn=config entries with outside code
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9045
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |2.5.14
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9938
Issue ID: 9938
Summary: Deprecate STARTTLS, recommend LDAPS
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: martin.von.wittich(a)iserv.eu
Target Milestone: ---
This has been discussed on the mailing list before, but unfortunately it seems
to have gotten lost in the shuffle:
https://www.openldap.org/lists/openldap-technical/201802/msg00004.html
> To me this rationale for SMTP submission with implicit TLS seems also
> applicable to LDAPS vs. StartTLS:
>
> https://tools.ietf.org/html/rfc8314#appendix-A
>
> So LDAPS should not be considered deprecated. Rather it should be
> recommended and the _optional_ use of StartTLS should be strongly
> discouraged.
Currently, https://www.openldap.org/faq/data/cache/605.html (Start TLS v.
ldaps://) still recommends STARTTLS over LDAPS. This unfortunately leads LDAP
client implementers to create clients that only support STARTTLS, e.g. here:
https://github.com/odoo/odoo/issues/9772#issuecomment-159943316
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9943
Issue ID: 9943
Summary: pw-radius
Product: OpenLDAP
Version: 2.4.57
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: earyutin(a)gmail.com
Target Milestone: ---
Good evening, dear developers!
I'm using Debian 11
Faced with the problem of compiling the module for authorization through
FreeRadius, users connecting to OpenLDAP.
There is little information on the net, but I managed to find the following:
https://github.com/openldap/openldap/blob/master/contrib/slapd-modules/pass…
moduleload pw-radius.so
gcc -shared -I../../../include -Wall -g -o pw-radius.so radius.c -lradius
Installed:
apt install slapd ldap-utils
Version:
slapd -V
@(#) $OpenLDAP: slapd 2.4.57+dfsg-3+deb11u1
gcc -shared -I /usr/lib/ldap/ -Wall -g -o pw-radius.so radius.c -lradius
gcc: error: radius.c: No such file or directory
1. Download "openldap-2.5.13.tgz"
2. tar -zxvf openldap-2.5.13.tgz
3. find /root/openldap-2.5.13/ -name "radius.c"
/root/openldap-2.5.13/contrib/slapd-modules/passwd/radius.c
4. cd /root/openldap-2.5.13/contrib/slapd-modules/passwd/
5. gcc -shared -I ../../../include -Wall -g -o pw-radius.so radius.c -lradius"
Errors appear
5.1. radius.c:16:10: fatal error: portable.h: No such file or directory
16 | #include "portable.h"
5.2. find /root/openldap-2.5.13/ -name "portable.*"
/root/openldap-2.5.13/include/portable.hin
5.3. cp /root/openldap-2.5.13/include/portable.hin
/root/openldap-2.5.13/include/portable.h
5.4. gcc -shared -I ../../../include -Wall -g -o pw-radius.so radius.c
-lradius"
5.5. In file included from radius.c:16:
../../../include/portable.h:1188:10: fatal error: ldap_features.h: No such file
or directory
1188 | #include "ldap_features.h"
5.6. find /root/openldap-2.5.13/ -name "ldap_features.*"
/root/openldap-2.5.13/include/ldap_features.hin
cp /root/openldap-2.5.13/include/ldap_features.hin
/root/openldap-2.5.13/include/ldap_features.h
...
After changing the names of all bad files, a bunch of errors come out:
gcc -shared -I ../../../include -Wall -g -o pw-radius.so radius.c -lradius
In file included from ../../../include/lber.h:29,
from radius.c:20:
../../../include/lber_types.h:42:9: error: unknown type name ‘LBER_INT_T’
42 | typedef LBER_INT_T ber_int_t;
| ^~~~~~~~~~
../../../include/lber_types.h:45:27: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘ber_sint_t’
45 | typedef signed LBER_INT_T ber_sint_t;
| ^~~~~~~~~~
../../../include/lber_types.h:46:29: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘ber_uint_t’
46 | typedef unsigned LBER_INT_T ber_uint_t;
| ^~~~~~~~~~
../../../include/lber_types.h:49:29: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘ber_tag_t’
49 | typedef unsigned LBER_TAG_T ber_tag_t;
| ^~~~~~~~~
../../../include/lber_types.h:52:9: error: unknown type name ‘LBER_SOCKET_T’
52 | typedef LBER_SOCKET_T ber_socket_t;
| ^~~~~~~~~~~~~
../../../include/lber_types.h:55:29: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘ber_len_t’
55 | typedef unsigned LBER_LEN_T ber_len_t;
| ^~~~~~~~~
../../../include/lber_types.h:58:27: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘ber_slen_t’
58 | typedef signed LBER_LEN_T ber_slen_t;
| ^~~~~~~~~~
In file included from ../../../include/portable.hin:1187,
from radius.c:16:
../../../include/lber.h:121:42: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
121 | typedef void* (BER_MEMALLOC_FN) LDAP_P(( ber_len_t size, void *ctx ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:122:43: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
122 | typedef void* (BER_MEMCALLOC_FN) LDAP_P(( ber_len_t n, ber_len_t size,
void *ctx ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:122:56: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
122 | typedef void* (BER_MEMCALLOC_FN) LDAP_P(( ber_len_t n, ber_len_t size,
void *ctx ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:123:53: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
123 | typedef void* (BER_MEMREALLOC_FN) LDAP_P(( void *p, ber_len_t size,
void *ctx ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
In file included from radius.c:20:
../../../include/lber.h:127:2: error: unknown type name ‘BER_MEMALLOC_FN’
127 | BER_MEMALLOC_FN *bmf_malloc;
| ^~~~~~~~~~~~~~~
../../../include/lber.h:128:2: error: unknown type name ‘BER_MEMCALLOC_FN’
128 | BER_MEMCALLOC_FN *bmf_calloc;
| ^~~~~~~~~~~~~~~~
../../../include/lber.h:129:2: error: unknown type name ‘BER_MEMREALLOC_FN’
129 | BER_MEMREALLOC_FN *bmf_realloc;
| ^~~~~~~~~~~~~~~~~
../../../include/lber.h:191:2: error: expected specifier-qualifier-list before
‘ber_slen_t’
191 | ber_slen_t (*sbi_read)( Sockbuf_IO_Desc *sbiod, void *buf,
| ^~~~~~~~~~
../../../include/lber.h:213:2: error: unknown type name ‘ber_len_t’
213 | ber_len_t bv_len;
| ^~~~~~~~~
In file included from ../../../include/portable.hin:1187,
from radius.c:16:
../../../include/lber.h:230:25: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
230 | LDAP_CONST char *data, ber_len_t len ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:244:9: error: unknown type name ‘ber_tag_t’
244 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:248:9: error: unknown type name ‘ber_tag_t’
248 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:251:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
251 | ber_len_t *len ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:253:9: error: unknown type name ‘ber_tag_t’
253 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:256:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
256 | ber_len_t *len ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:258:9: error: unknown type name ‘ber_tag_t’
258 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:263:9: error: unknown type name ‘ber_tag_t’
263 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:268:9: error: unknown type name ‘ber_tag_t’
268 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:273:9: error: unknown type name ‘ber_tag_t’
273 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:278:9: error: unknown type name ‘ber_tag_t’
278 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:288:9: error: unknown type name ‘ber_tag_t’
288 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:292:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
292 | ber_len_t *len ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:301:9: error: unknown type name ‘ber_tag_t’
301 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:307:9: error: unknown type name ‘ber_tag_t’
307 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:312:9: error: unknown type name ‘ber_tag_t’
312 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:317:9: error: unknown type name ‘ber_tag_t’
317 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:321:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
321 | ber_len_t *len ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:323:9: error: unknown type name ‘ber_tag_t’
323 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:327:9: error: unknown type name ‘ber_tag_t’
327 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:332:9: error: unknown type name ‘ber_tag_t’
332 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:335:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
335 | ber_len_t *len,
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:338:9: error: unknown type name ‘ber_tag_t’
338 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:341:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
341 | ber_len_t *len,
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:344:9: error: unknown type name ‘ber_tag_t’
344 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:371:2: error: unknown type name ‘ber_tag_t’; did you
mean ‘ber_int_t’?
371 | ber_tag_t tag ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:377:2: error: unknown type name ‘ber_tag_t’; did you
mean ‘ber_int_t’?
377 | ber_tag_t tag ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:383:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
383 | ber_len_t len,
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:384:2: error: unknown type name ‘ber_tag_t’; did you
mean ‘ber_int_t’?
384 | ber_tag_t tag ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:390:2: error: unknown type name ‘ber_tag_t’; did you
mean ‘ber_int_t’?
390 | ber_tag_t tag ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:396:2: error: unknown type name ‘ber_tag_t’; did you
mean ‘ber_int_t’?
396 | ber_tag_t tag ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:402:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
402 | ber_len_t bitlen,
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:403:2: error: unknown type name ‘ber_tag_t’; did you
mean ‘ber_int_t’?
403 | ber_tag_t tag ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:408:2: error: unknown type name ‘ber_tag_t’; did you
mean ‘ber_int_t’?
408 | ber_tag_t tag ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:414:2: error: unknown type name ‘ber_tag_t’; did you
mean ‘ber_int_t’?
414 | ber_tag_t tag ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:419:2: error: unknown type name ‘ber_tag_t’; did you
mean ‘ber_int_t’?
419 | ber_tag_t tag ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:424:2: error: unknown type name ‘ber_tag_t’; did you
mean ‘ber_int_t’?
424 | ber_tag_t tag ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:445:9: error: unknown type name ‘ber_slen_t’
445 | LBER_F( ber_slen_t )
| ^~~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:448:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
448 | ber_len_t len ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:450:9: error: unknown type name ‘ber_slen_t’
450 | LBER_F( ber_slen_t )
| ^~~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:454:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
454 | ber_len_t len ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:456:9: error: unknown type name ‘ber_slen_t’
456 | LBER_F( ber_slen_t )
| ^~~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:460:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
460 | ber_len_t len,
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:501:9: error: unknown type name ‘ber_tag_t’
501 | LBER_F( ber_tag_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:504:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
504 | ber_len_t *len,
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:600:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
600 | ber_len_t s ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:605:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
605 | ber_len_t s ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:609:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
609 | ber_len_t n,
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:610:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
610 | ber_len_t s ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:643:21: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
643 | LDAP_CONST char *, ber_len_t len, int duplicate, struct berval *bv));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:647:21: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
647 | LDAP_CONST char *, ber_len_t len, int duplicate, struct berval *bv));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:656:9: error: unknown type name ‘ber_len_t’
656 | LBER_F( ber_len_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber.h:658:22: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
658 | LDAP_CONST char *s, ber_len_t len ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber.h:662:22: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
662 | LDAP_CONST char *s, ber_len_t l ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
In file included from radius.c:21:
../../../include/lber_pvt.h:45:2: error: unknown type name ‘ber_len_t’
45 | ber_len_t buf_size;
| ^~~~~~~~~
../../../include/lber_pvt.h:46:2: error: unknown type name ‘ber_len_t’
46 | ber_len_t buf_ptr;
| ^~~~~~~~~
../../../include/lber_pvt.h:47:2: error: unknown type name ‘ber_len_t’
47 | ber_len_t buf_end;
| ^~~~~~~~~
In file included from ../../../include/portable.hin:1187,
from radius.c:16:
../../../include/lber_pvt.h:66:9: error: unknown type name ‘ber_slen_t’
66 | LBER_F( ber_slen_t )
| ^~~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber_pvt.h:76:51: error: unknown type name ‘ber_len_t’; did
you mean ‘ber_int_t’?
76 | ber_pvt_sb_grow_buffer LDAP_P(( Sockbuf_Buf *buf, ber_len_t minsize ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber_pvt.h:78:9: error: unknown type name ‘ber_len_t’
78 | LBER_F( ber_len_t )
| ^~~~~~~~~
../../../include/ldap_cdefs.h:136:31: note: in definition of macro ‘LBER_F’
136 | # define LBER_F(type) extern type
| ^~~~
../../../include/lber_pvt.h:79:59: error: unknown type name ‘ber_len_t’; did
you mean ‘ber_int_t’?
79 | ber_pvt_sb_copy_out LDAP_P(( Sockbuf_Buf *sbb, char *buf, ber_len_t len
));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber_pvt.h:89:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
89 | ber_len_t s, void *ctx));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber_pvt.h:94:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
94 | ber_len_t s, void *ctx ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber_pvt.h:98:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
98 | ber_len_t n,
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber_pvt.h:99:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
99 | ber_len_t s, void *ctx ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber_pvt.h:128:21: error: unknown type name ‘ber_len_t’; did
you mean ‘ber_int_t’?
128 | LDAP_CONST char *, ber_len_t len, int dup, struct berval *bv, void
*ctx));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lber_pvt.h:132:21: error: unknown type name ‘ber_len_t’; did
you mean ‘ber_int_t’?
132 | LDAP_CONST char *, ber_len_t len, int dup, struct berval *bv, void
*ctx));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
In file included from ../../../include/lutil.h:21,
from radius.c:22:
../../../include/ac/socket.h:233:46: error: unknown type name ‘uid_t’
233 | LDAP_LUTIL_F( int ) lutil_getpeereid( int s, uid_t *, gid_t * );
| ^~~~~
../../../include/ac/socket.h:233:55: error: unknown type name ‘gid_t’
233 | LDAP_LUTIL_F( int ) lutil_getpeereid( int s, uid_t *, gid_t * );
| ^~~~~
../../../include/ac/socket.h:238:18: error: field ‘sa_addr’ has incomplete type
238 | struct sockaddr sa_addr;
| ^~~~~~~
../../../include/ac/socket.h:239:21: error: field ‘sa_in_addr’ has incomplete
type
239 | struct sockaddr_in sa_in_addr;
| ^~~~~~~~~~
In file included from ../../../include/portable.hin:1187,
from radius.c:16:
../../../include/lutil.h:68:2: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
68 | ber_len_t nbytes ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
../../../include/lutil.h:137:51: error: unknown type name ‘ber_len_t’; did you
mean ‘ber_int_t’?
137 | lutil_passwd_generate LDAP_P(( struct berval *pw, ber_len_t ));
| ^~~~~~~~~
../../../include/ldap_cdefs.h:32:25: note: in definition of macro ‘LDAP_P’
32 | # define LDAP_P(protos) protos
| ^~~~~~
radius.c:27:10: fatal error: radlib.h: No such file or directory
27 | #include <radlib.h>
Help me please.
Thank you !
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=5693
--- Comment #5 from salleman(a)math.u-bordeaux.fr ---
Hi,
I have a similar issue with search on translucent overlay :
I override ObjectClass with posixAccount.
I set translucent with :
olcTranslucentLocal: uidNumber
olcTranslucentLocal: gidNumber
olcTranslucentLocal: homeDirectory
olcTranslucentLocal: loginShell
olcTranslucentLocal: mailAlternateAddress
olcTranslucentLocal: memberUid
olcTranslucentLocal: objectClass
It works except when I search with filter like this :
"(&(loginShell=/bin/bash)(sn=Smith))". On the remote backend, the search is :
SRCH base="uid=dupont,ou=people,dc=u-bordeaux,dc=fr" scope=0 deref=0
filter="(objectClass=*)
SEARCH RESULT tag=101 err=0 qtime=0.000013 etime=0.000146 nentries=1 text="
which is a entry contains loginShell=/bin/bash.
It seems that when a composed filter with local and remote attributes returns
many results from local (loginShell), the search on remote would apply for each
dn founds but translucent fails on the first (because second part of filter is
not verified (sn=Smith)).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9045
OndÅ™ej KuznÃk <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|VERIFIED |CONFIRMED
Ever confirmed|0 |1
Resolution|WORKSFORME |---
--- Comment #3 from OndÅ™ej KuznÃk <ondra(a)mistotebe.net> ---
Got another one, in do_syncrep1, attached. I gather it's because syncrepl got
it through entry_get() while there is a modify request on cn=config that freed
it in the meantime.
Sounds like ldap_pvt_thread_rdwr_rlock( &cfb->cb_rwlock ) in
config_back_entry_get (and the reverse in config_entry_release()) might do the
trick, except that anyone getting that entry needs to release it before they
yield processing - as bconfig might decide it wants to pause and wlock. Or we
just entry_dup it unconditionally which means we never interfere with anyone
else.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9939
Issue ID: 9939
Summary: datamorph test fails
Product: OpenLDAP
Version: 2.6.3
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: patrick+openldap.org(a)laimbock.com
Target Milestone: ---
[snip]
+ for MOD in datamorph ppm variant
+ pushd contrib/slapd-modules/datamorph
~/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph
~/build/BUILD/openldap-2.6.3
+ /usr/bin/make -O -j1 V=1 VERBOSE=1 test
ln -s /builddir/build/BUILD/openldap-2.6.3/clients clients
ln -s /builddir/build/BUILD/openldap-2.6.3/servers servers
ln -s /builddir/build/BUILD/openldap-2.6.3/tests/progs tests/progs
cd tests; \
SRCDIR=/builddir/build/BUILD/openldap-2.6.3 \
LDAP_BUILD=/builddir/build/BUILD/openldap-2.6.3 \
TOPDIR=/builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph \
LIBTOOL=/builddir/build/BUILD/openldap-2.6.3/libtool \
/builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph/tests/run
all
Running
/builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph/tests/scripts/all
for mdb...
>>>>> Executing all LDAP tests for mdb
>>>>> Starting test001-config for mdb...
running defines.sh
/builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph/tests/scripts/common.sh:
line 26: /servers/slapd/slapd: No such file or directory
/builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph/tests/scripts/common.sh:
line 28: /servers/slapd/slapd: No such file or directory
Starting slapd on TCP/IP port 9011 for configuration...
Waiting 7 seconds for slapd to start...
Waiting 7 seconds for slapd to start...
Waiting 7 seconds for slapd to start...
Waiting 7 seconds for slapd to start...
Waiting 7 seconds for slapd to start...
Waiting 7 seconds for slapd to start...
Failed testing for module load entry
>>>>> test001-config failed for mdb
(exit 127)
make: *** [tests/Rules.mk:12: test] Error 127
This test also fails on the latest 2.6 branch.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8610
--- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
The FAQ is historic, 99% of what's in it is incorrect.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9933
Issue ID: 9933
Summary: pamcompany
Product: JLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: JDBC
Assignee: bugs(a)openldap.org
Reporter: packersnmoversservices(a)gmail.com
Target Milestone: ---
A trustworthy and expert moving business in Bangalore's Hebbal is PAM
Bangalore. This business is regarded as one of the top packers and movers
hebbal service providers because of its reputation for offering high-quality
moving and shifting services at reasonable pricing. Relocators who require
storage or house transferring services in Bangalore seek them. A firm with a
team of professional packers and movers offers a hassle-free, damage-free, and
stress-free move at a reasonable cost.
https://www.packersmoversinbangalore.co.in/packers-and-movers-in-hebbal/
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9927
Issue ID: 9927
Summary: mdb/0.9 update makes strange problems
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
Created attachment 919
--> https://bugs.openldap.org/attachment.cgi?id=919&action=edit
strace outfput of failed start
I changed on the 2.6 branch at this
commit 18f6cc1609fe80ae30702f68875a6fc793e29ffd (origin/OPENLDAP_REL_ENG_2_6,
OPENLDAP_REL_ENG_2_6)
Merge: 8b4c915a6 d87d682b6
Author: Quanah Gibson-Mount <quanah(a)openldap.org>
Date: Tue Oct 4 14:29:39 2022 +0000
Merge remote-tracking branch 'origin/mdb.RE/0.9' into OPENLDAP_REL_ENG_2_6
and things stopped working: after several times restarting slapd refused to
start.
Then I went back to commit:
commit 8b4c915a655373973a834719f942bcdc09a7b516 (HEAD)
Author: Quanah Gibson-Mount <quanah(a)openldap.org>
Date: Mon Oct 3 20:26:19 2022 +0000
ITS#9915
and things worked again. I changed back to commit 18f6cc1609fe8, and slapd
does run properly.
Of course, I assume the LMDB database format has not changed and I have not
done export to LDIF and then import from LDIF to LMDB.
I have disabled syslog and debugging:
$ ./configure --disable-ipv6 --enable-spasswd --disable-static --disable-syslog
--disable-debug --enable-sssvlv --disable-relay
The file FAILED.txt, produced on dysfunctional slapd by executing
# strace /usr/local/libexec/slapd -d0 -u openldap -r /home/openldap -F
/etc/openldap/ -h'ldap://ldap.aegee.org/ldaps://ldap.aegee.org
ldapi://%%2Fvar%%2Frun%%2Fldapi' > FAILED.txt
is attached.
This is very similar to https://bugs.openldap.org/show_bug.cgi?id=9879 :
upgrading to the newest version fails. Using a slightly older version than the
tip of the tree does not fail any more. Then upgrading to the newest version
does work.
Note that yesterday, or two-three days ago I also upgraded to the newest tip of
git and things worked, but I cannot say which commit was this.
# journalctl --unit openldap
Oct 04 08:04:31 mail systemd[1]: Stopping OpenLDAP...
Oct 04 08:04:33 mail systemd[1]: openldap.service: Deactivated successfully.
Oct 04 08:04:33 mail systemd[1]: Stopped OpenLDAP.
Oct 04 08:04:33 mail systemd[1]: openldap.service: Consumed 50.080s CPU time.
Oct 04 08:04:33 mail systemd[1]: Starting OpenLDAP...
Oct 04 08:04:36 mail systemd[1]: Started OpenLDAP.
Oct 04 08:10:33 mail systemd[1]: Stopping OpenLDAP...
Oct 04 08:10:34 mail systemd[1]: openldap.service: Deactivated successfully.
Oct 04 08:10:34 mail systemd[1]: Stopped OpenLDAP.
Oct 04 08:10:37 mail systemd[1]: Starting OpenLDAP...
Oct 04 08:10:37 mail systemd[1]: Started OpenLDAP.
Oct 05 07:33:36 mail systemd[1]: Stopping OpenLDAP...
Oct 05 07:33:37 mail systemd[1]: openldap.service: Failed with result
'resources'.
Oct 05 07:33:37 mail systemd[1]: Stopped OpenLDAP.
Oct 05 07:33:37 mail systemd[1]: openldap.service: Consumed 7.453s CPU time.
Oct 05 07:33:37 mail systemd[1]: Starting OpenLDAP...
Oct 05 07:33:38 mail systemd[1]: openldap.service: Main process exited,
code=exited, status=255/EXCEPTION
Oct 05 07:33:38 mail systemd[1]: openldap.service: Failed with result
'exit-code'.
Oct 05 07:33:38 mail systemd[1]: Failed to start OpenLDAP.
Oct 05 07:33:43 mail systemd[1]: Starting OpenLDAP...
Oct 05 07:33:43 mail systemd[1]: openldap.service: Main process exited,
code=exited, status=255/EXCEPTION
Oct 05 07:33:43 mail systemd[1]: openldap.service: Failed with result
'exit-code'.
Oct 05 07:33:43 mail systemd[1]: Failed to start OpenLDAP.
Oct 05 07:38:22 mail systemd[1]: Starting OpenLDAP...
so it worked likely without problems on the most current 2.6 commit at Oct 04
08:04:33 UTC.
Note that the failing slapd does terminate before reading the configuration
files with
newfstatat(AT_FDCWD, "/etc/openldap/", {st_mode=S_IFDIR|0755, st_size=4096,
...}, 0) = 0
newfstatat(AT_FDCWD, "/etc/openldap/", {st_mode=S_IFDIR|0755, st_size=4096,
...}, 0) = 0
mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f03c36d1000
openat(AT_FDCWD, "/etc/openldap//cn=config.ldif", O_RDONLY) = 9
newfstatat(9, "", {st_mode=S_IFREG|0600, st_size=817, ...}, AT_EMPTY_PATH) = 0
so it shall be irrelevant how MDB handles the data.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9932
Issue ID: 9932
Summary: Sync failing between two LDAP servers
Product: OpenLDAP
Version: 2.4.58
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: shikhar81(a)gmail.com
Target Milestone: ---
Hi Team,
We have noticed a sync issue in our environment.
We have two production servers namely A and B and two DR servers namely C and
D.
A and B are in bi-directional sync
A and C are in bi-directional sync
B and D are in bi-directional sync
Since the last few days the sync between A and C and B and D has broken and we
are unable to see any concrete error in logs
Just to add here that server A and server B are in the same subnet and server C
& server D are in a different subnet. However, this setup has been working fine
since the last many years with no issues at all.
Since the last few days the connection has broken as mentioned earlier.
Now we also tried to initiate a sync between C and D (DR servers) which are in
the same subnet. But still it is not syncing and we get a "no connection" error
message in the logs after trying for 2-3 hrs.
Can you please suggest what can be done here.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9928
Issue ID: 9928
Summary: ldap_search_ext_s always hangs on 2.6.3
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: filipe.custodio(a)gmail.com
Target Milestone: ---
Created attachment 920
--> https://bugs.openldap.org/attachment.cgi?id=920&action=edit
Minimal AD query that consistently hangs on ldap_search_ext_s call
Dear Experts,
When using ldap_search_ext_s() from libldap v2.6.3 to do a simple search on our
production Windows Domain Controller, the client consistently hangs forever.
Using ldap_search_ext() & ldap_result() also hangs after delivering the first
information item. It seems the client is left waiting, not realising no more
results are coming from the server.
Using the development image from Oct. 9 2022, the ldap_search_ext_s() call
works, although it gives an "Operations Error".
Shall I deploy the new libldap from the development branch in our production
environment to solve this problem or is there another way around the issue?
Best regards,
Filipe Custódio
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9919
Issue ID: 9919
Summary: The use of a separate section for cold code can cause
linking issues on macOS
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: mh-bcrayqnc(a)glandium.org
Target Milestone: ---
See e.g. https://github.com/llvm/llvm-project/issues/52767
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9365
Issue ID: 9365
Summary: Mem leaks with Æ-DIR providers
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Created attachment 772
--> https://bugs.openldap.org/attachment.cgi?id=772&action=edit
valgrind output on openSUSE Tumbleweed x86_64
An Æ-DIR installation with self-compiled OpenLDAP 2.4.53 on Debian (now
buster) has memory leak issues on the Æ-DIR providers. The read-only
consumers do not have this issue. The provider config is more complex
with more overlays and more ACLs.
In this production deployment slapd is automatically restarted (by monit) when
memory consumption reaches 80%. Thus monitoring clearly shows a frequent saw
tooth pattern.
I've also tested on openSUSE Tumbleweed x86_64 with a RE24 build [1] by running
slapd under control of valgrind for a couple of minutes continously sending
simple bind operations (additional to the monitoring and other back-ground jobs
running).
Find valgrind output of my first attempt attached.
Does that make sense at all?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9923
Issue ID: 9923
Summary: extensible match ignored
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: francois(a)rcdevs.com
Target Milestone: ---
Hi,
I'm trying to use a matching rule with slapd as a proxy in front of Active
Directory with back-ldap
The request is something similar to
'(memberOf:1.2.840.113556.1.4.1941:=cn=gp1,o=Root)'
It works if I use it directly on AD.
Unfortunately, the request is ignored by slapd and not forwarded, I receive a
"success" but the result is empty.
The request is forwarded if I use something like this:
'(memberOf=cn=gp1,o=Root)'
Could it be possible to forward the request to the backend? slapd doesn't need
to understand the meaning of the OID.
slapd with matching rule:
[2022-09-28 11:07:39] begin get_filter
[2022-09-28 11:07:39] EXTENSIBLE
[2022-09-28 11:07:39] daemon: activity on 1 descriptor
[2022-09-28 11:07:39] end get_filter 0
[2022-09-28 11:07:39] filter: (?=undefined)
[2022-09-28 11:07:39] attrs: dn
[2022-09-28 11:07:39] conn=1000 op=1 SRCH base="o=root" scope=2 deref=0
filter="(?=undefined)"
slapd without matching rule:
[2022-09-28 11:07:47] begin get_filter
[2022-09-28 11:07:47] EQUALITY
[2022-09-28 11:07:47] get_ava: unknown attributeType memberOf
[2022-09-28 11:07:47]
[2022-09-28 11:07:47] end get_filter 0
[2022-09-28 11:07:47] daemon: epoll: listen=7 active_threads=0 tvp=NULL
[2022-09-28 11:07:47] daemon: epoll: listen=8 active_threads=0 tvp=NULL
[2022-09-28 11:07:47] filter: (?memberOf=cn=gp1,o=Root)
[2022-09-28 11:07:47] attrs: dn
[2022-09-28 11:07:47] conn=1001 op=1 SRCH base="o=root" scope=2 deref=0
filter="(?memberOf=cn=gp1,o=Root)"
searchrequest dump:
0000 30 56 02 01 02 63 51 04 06 6f 3d 72 6f 6f 74 0a 0V...cQ..o=root.
0010 01 02 0a 01 00 02 01 00 02 01 00 01 01 00 a9 32 ...............2
0020 81 17 31 2e 32 2e 38 34 30 2e 31 31 33 35 35 36 ..1.2.840.113556
0030 2e 31 2e 34 2e 31 39 34 31 82 08 6d 65 6d 62 65 .1.4.1941..membe
0040 72 4f 66 83 0d 63 6e 3d 67 70 31 2c 6f 3d 52 6f rOf..cn=gp1,o=Ro
0050 6f 74 30 04 04 02 64 6e ot0...dn
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9878
Issue ID: 9878
Summary: test043 failures in 2.5/2.6
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
With test043 update for ITS#9823, we manage to introduce a scenario where the
server is completely idle except for a runqueue change.
This is partly identical with ITS#9642 and a similar approach would work.
Except that changes our module facing ABI so might not be something we can
backport. For the streams we can't, we might have to change the test to make
the server not idle.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9922
Issue ID: 9922
Summary: Uninitialized value reading in
clients/tools/common.c:tool_bind()
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
One possible flow in
https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/comm…
is:
int err;
if ( result ) {
rc = ldap_parse_result( ld, result, &err, &matched, &info, &refs, &ctrls, 1
);
if ( rc != LDAP_SUCCESS ) {
tool_perror( "ldap_bind parse result", rc, NULL, matched, info, refs );
tool_exit( ld, LDAP_LOCAL_ERROR );
}
}
if ( err != LDAP_SUCCESS …
When result is NULL, err is not initialized, and the last line reads
uninitialized value.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9030
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |0.9.30
--- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
RE0.9:
• 4bb20ed0
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9030
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from Howard Chu <hyc(a)openldap.org> ---
patched in mdb.master ; mdb.master3 ; mdb.RE/0.9
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9918
Issue ID: 9918
Summary: Can't log on git.openldap.org
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: mh-bcrayqnc(a)glandium.org
Target Milestone: ---
Followup for https://github.com/LMDB/lmdb/pull/23#issuecomment-1254532527.
I created the account in February, apparently, with login glandium, but I'm not
sure what email. Presumably the one from this bugzilla account.
--
You are receiving this mail because:
You are on the CC list for the issue.