https://bugs.openldap.org/show_bug.cgi?id=9472
Issue ID: 9472
Summary: Add datamorph overlay to core
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Symas will contribute its datamorph overlay to core
The datamorph overlay to slapd allows attributes with a few predefined values
to be saved more space-efficiently as well as signed or unsigned integer
attributes.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9473
Issue ID: 9473
Summary: Add variant overlay to core
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Symas will contribute its variant overlay to OpenLDAP core
The variant overlay to slapd allows attributes/values to be shared between
several entries. In some ways this is similar to slapo-collect with the
exception that the source and target attributes can be different.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10087
Issue ID: 10087
Summary: slapd crashes with core dump Assertion
`!LDAP_BACK_CONN_TAINTED( lc )
Product: OpenLDAP
Version: 2.5.15
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: rajko(a)albrecht.jetzt
Target Milestone: ---
The slapd daemon crashes every ten minutes with
slapd: ../../../../../servers/slapd/back-ldap/bind.c:181:
ldap_back_conn_delete: Assertion `!LDAP_BACK_CONN_TAINTED( lc )' failed.
Aborted (core dumped)
I searched around for multiple days but didn't find any solution to this
problem.
I have the same problem with 2.6.x versions.
It is configured to act as caching ldap, while multiple hundred systems contact
it.
The error message is completely useless for sysadmins because they don't
understand what this means for them (as said, asking search engines gives no
answers) nor I don't know if - and if so how - I can fix this with
configuration.
I don't see if this message is talking about the connection to the upstream
ldap server or if this is the connection from a client to the caching (and
crashing) daemon.
First setup was plain on a linux machine, now runnig inside docker environment
so the service is restarted after the crash. This is of course not a nice
solution.
And it looks like the same like #4390 which is marked as "not solved".
At least a description what this error messages means would be very helpful
incl. how a workaround could look like (increasing timeouts, increase/decrease
a socket pool or whatever).
Currently the slapd is nearly useless when using it as a caching ldap with high
load.
Any hints?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10096
Issue ID: 10096
Summary: SIGSEGV in try_read1msg() while using referrals with
AD
Product: OpenLDAP
Version: 2.6.2
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
The double free happens during a referral chasing with AD.
SSSD usage Background (But I think the issue can happen even without SSSD):
Referral chasing with AD and Kerberos based GSSAPI/GSS-SPNEGO authentication
will never work based in the fact that AD will return domain names instead of
the names of AD DC in the referral.
That with with 'id_provider = ad' (SSSD setting) there is 'ldap_referrals =
false' as default. For 'id_provider = ldap' we expect a generic LDAP server
(not AD) which returns proper referrals with fully-qualified hostname or where
is simple bind is used, either anonymous or with bind DN and password (which is
expected to be the same on all involved LDAP servers and which is not the case
with AD since the AD DC from a different domain won't know the given bind DN).
So the issue is an unusual one, but still, as it's a crash, I think it deserves
a look at.
The stack trace for the issue:
#0 __pthread_kill_implementation (threadid=<optimized out>,
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007f34182a15b3 in __pthread_kill_internal (signo=6, threadid=<optimized
out>) at pthread_kill.c:78
#2 0x00007f3418254d46 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#3 0x00007f34182287f3 in __GI_abort () at abort.c:79
#4 0x00007f3418229130 in __libc_message (fmt=<optimized out>,
fmt@entry=0x7f34183bb6bd "%s\n") at ../sysdeps/posix/libc_fatal.c:150
#5 0x00007f34182ab617 in malloc_printerr (str=str@entry=0x7f34183be2d0 "double
free or corruption (!prev)") at malloc.c:5515
#6 0x00007f34182ad30c in _int_free (av=0x7f34183fac80 <main_arena>,
p=0x560fc4b23130, have_lock=<optimized out>) at malloc.c:4458
#7 0x00007f34182af955 in __GI___libc_free (mem=<optimized out>) at
malloc.c:3258
#8 0x00007f34173b6f52 in try_read1msg (result=0x7ffea107bb88,
lc=0x560fc4ac20e0, all=0, msgid=-1, ld=0x560fc4a77450)
at
/usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:919
#9 wait4msg (result=0x7ffea107bb88, timeout=<optimized out>, all=0, msgid=-1,
ld=0x560fc4a77450)
at
/usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:369
#10 ldap_result (ld=0x560fc4a77450, msgid=msgid@entry=-1, all=all@entry=0,
timeout=timeout@entry=0x7ffea107bb90, result=result@entry=0x7ffea107bb88)
at
/usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:120
#11 0x00007f3415b6f7be in sdap_process_result (ev=0x560fc49e2420,
pvt=<optimized out>) at src/providers/ldap/sdap_async.c:233
#12 0x00007f3418433675 in tevent_common_invoke_fd_handler
(fde=fde@entry=0x560fc4b07ce0, flags=1, removed=removed@entry=0x0) at
../../tevent_fd.c:142
#13 0x00007f34184373cf in epoll_event_loop (tvalp=0x7ffea107bc30,
epoll_ev=0x560fc49e2700) at ../../tevent_epoll.c:737
#14 epoll_event_loop_once (ev=<optimized out>, location=<optimized out>) at
../../tevent_epoll.c:938
#15 0x00007f341842f6ab in std_event_loop_once (ev=0x560fc49e2420,
location=0x7f3418575f10 "src/util/server.c:787") at ../../tevent_standard.c:110
#16 0x00007f3418431b88 in _tevent_loop_once (ev=ev@entry=0x560fc49e2420,
location=location@entry=0x7f3418575f10 "src/util/server.c:787")
at ../../tevent.c:825
#17 0x00007f3418431c7b in tevent_common_loop_wait (ev=0x560fc49e2420,
location=0x7f3418575f10 "src/util/server.c:787") at ../../tevent.c:948
#18 0x00007f341842f71b in std_event_loop_wait (ev=0x560fc49e2420,
location=0x7f3418575f10 "src/util/server.c:787") at ../../tevent_standard.c:141
#19 0x00007f3418552237 in server_loop (main_ctx=0x560fc49e2790) at
src/util/server.c:787
#20 0x0000560fc371ebda in main (argc=8, argv=<optimized out>) at
src/providers/data_provider_be.c:811
(gdb) frame 11
#11 0x00007f3415b6f7be in sdap_process_result (ev=0x560fc49e2420,
pvt=<optimized out>) at src/providers/ldap/sdap_async.c:233
233 ret = ldap_result(sh->ldap, LDAP_RES_ANY, 0, &no_timeout, &msg);
(gdb) frame 10
#10 ldap_result (ld=0x560fc4a77450, msgid=msgid@entry=-1, all=all@entry=0,
timeout=timeout@entry=0x7ffea107bb90, result=result@entry=0x7ffea107bb88)
at
/usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:120
120 rc = wait4msg( ld, msgid, all, timeout, result );
(gdb) frame 9
#9 wait4msg (result=0x7ffea107bb88, timeout=<optimized out>, all=0, msgid=-1,
ld=0x560fc4a77450)
at
/usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:369
369 rc = try_read1msg( ld,
msgid, all, lc, result );
(gdb) frame 8
#8 0x00007f34173b6f52 in try_read1msg (result=0x7ffea107bb88,
lc=0x560fc4ac20e0, all=0, msgid=-1, ld=0x560fc4a77450)
at
/usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:919
919 ldap_return_request( ld, lr, 0 );
(gdb) frame 7
#7 0x00007f34182af955 in __GI___libc_free (mem=<optimized out>) at
malloc.c:3258
3258 _int_free (ar_ptr, p, 0);
(gdb) frame 6
#6 0x00007f34182ad30c in _int_free (av=0x7f34183fac80 <main_arena>,
p=0x560fc4b23130, have_lock=<optimized out>) at malloc.c:4458
4458 malloc_printerr ("double free or corruption (!prev)");
(gdb) frame 8
#8 0x00007f34173b6f52 in try_read1msg (result=0x7ffea107bb88,
lc=0x560fc4ac20e0, all=0, msgid=-1, ld=0x560fc4a77450)
at
/usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:919
919 ldap_return_request( ld, lr, 0 );
(gdb) list
914 }
915 }
916
917 if ( lr != NULL ) {
918 if ( lr != &dummy_lr ) {
919 ldap_return_request( ld, lr, 0 );
920 }
921 lr = NULL;
922 }
923
(gdb) p *ld
$6 = {ldc = 0x560fc4b01110, ld_errno = 10, ld_error = 0x0, ld_matched = 0x0,
ld_referrals = 0x0}
(gdb) p *lr
$8 = {lr_msgid = -995099056, lr_status = 22031, lr_refcnt = -995206016,
lr_outrefcnt = 22030, lr_abandoned = 0, lr_origid = 40, lr_parentcnt = 4,
lr_res_msgtype = 101, lr_res_errno = 0, lr_res_error = 0x0, lr_res_matched =
0x0, lr_ber = 0x0, lr_conn = 0x560fc4ac20e0, lr_dn = {bv_len = 20,
bv_val = 0x560fc4affe6b "\304\017V"}, lr_parent = 0x0, lr_child =
0x560fc4adb650, lr_refnext = 0x0, lr_prev = 0x0, lr_next = 0x90}
Thank you!
Simon
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10097
Issue ID: 10097
Summary: slapi didn't build on Windows
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Apparently no one has ever tried to use SLAPI on Windows, since it has been
broken ever since the initial commit in 2002.
Fixed now in master, in
3489931553a684ab388b29dde0b8b2cf6cf63e79 and
a7bd0416c80bcb954001c1b39512fb97f6c4b4ac
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10093
Issue ID: 10093
Summary: Unclear licenses in certain places
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: thegeorg(a)yandex-team.com
Target Milestone: ---
We use scancode-toolkit in order to perform automatic license analysis.
At the time, this toolkit reports certain places with unclear license status.
In particular, libraries/libldap/modrdn.c (lines 19 to 24) bear the following
notice:
```
/* Copyright 1999, Juan C. Gomez, All rights reserved.
* This software is not subject to any license of Silicon Graphics
* Inc. or Purdue University.
*
* Redistribution and use in source and binary forms are permitted
* without restriction or fee of any kind as long as this notice
* is preserved.
*/
```
While copyright notice is completely fine, the second part can not be
recognised as any SPDX acknowledged license.
Is it possible to unify the text across other parts of OpenLDAP?
--
You are receiving this mail because:
You are on the CC list for the issue.