[Issue 9305] New: ldap_connect_to_host: Return code from getaddrinfo() discarded, troubleshooting difficult
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9305
Issue ID: 9305
Summary: ldap_connect_to_host: Return code from getaddrinfo()
discarded, troubleshooting difficult
Product: OpenLDAP
Version: 2.4.46
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: minfrin(a)sharp.fm
Target Milestone: ---
When the ldap_connect_to_host() function sees a failure from getaddrinfo(), the
meaningless return code -1 is returned.
This makes troubleshooting difficult on a webserver, where the low level printf
debugging is not practical.
(gdb) step
ldap_connect_to_host (ld=ld@entry=0x7fffc4002e10, sb=0x7fffc400b240, proto=1,
srv=srv@entry=0x7fffc400b2f0, async=async@entry=0) at os-ip.c:543
543 {
(gdb) next
546 ber_socket_t s = AC_SOCKET_INVALID;
(gdb)
562 if ( srv->lud_host == NULL || *srv->lud_host == 0 ) {
(gdb)
568 port = srv->lud_port;
(gdb)
570 if( !port ) {
(gdb)
578 switch(proto) {
(gdb)
580 osip_debug( ld,
(gdb)
warning: Source file is more recent than executable.
71 return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
(gdb)
598 hints.ai_flags = AI_ADDRCONFIG;
(gdb)
601 hints.ai_socktype = socktype;
(gdb)
602 snprintf(serv, sizeof serv, "%d", port );
(gdb)
605 LDAP_MUTEX_LOCK(&ldap_int_resolv_mutex);
(gdb)
607 err = getaddrinfo( host, serv, &hints, &res );
(gdb)
609 LDAP_MUTEX_UNLOCK(&ldap_int_resolv_mutex);
(gdb)
611 if ( err != 0 ) {
(gdb)
612 osip_debug(ld, "ldap_connect_to_host: getaddrinfo
failed: %s\n",
(gdb) print host
$3 = <optimized out>
(gdb) print serv
$4 = "636\000\000\000"
(gdb) next
614 return -1;
(gdb)
The ldap_connect_to_host() function needs to return proper error codes.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 11 months
[Issue 9367] New: back-mdb: encryption support
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9367
Issue ID: 9367
Summary: back-mdb: encryption support
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Need to add encryption support to the back-mdb backend, depends on issue#9364
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 11 months
[Issue 9341] New: Delta-sync MPR needs to be stable regardless of ordering
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9341
Issue ID: 9341
Summary: Delta-sync MPR needs to be stable regardless of
ordering
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: replication
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If two or more updates are spread across several providers before they have a
chance to learn about the others, all replicas need to arrive at the same
content regardless of the order in which they arrive.
One example that is broken at the moment:
- (csn a) server 1 accepts a modify
- (csn b) server 2 accepts a delete on the same DN
- (csn c) server 2 accepts an add on that DN again
If a replica receives the actions in the order bca vs. abc, the content of the
entry will be different even though the final CSN set is the same -> they will
never converge. The ordering 'bac' also needs to result in eventual
convergence, even if it means a refresh or replication from either provider
stalling temporarily?
Merge request with this test case (so far):
https://git.openldap.org/openldap/openldap/-/merge_requests/145
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 11 months
[Bug 9243] New: back-perl configure should test linking with libperl
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9243
Bug ID: 9243
Summary: back-perl configure should test linking with libperl
Product: OpenLDAP
Version: 2.4.49
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
./configure --enable-perl && make
[...]
checking for perl... /usr/bin/perl
[...]
libtool: link: cc -g -O2 -o slapd main.o globals.o bconfig.o config.o daemon.o
connection.o search.o filter.o add.o cr.o attr.o entry.o backend.o backends.o
result.o operation.o dn.o compare.o modify.o delete.o modrdn.o ch_malloc.o
value.o ava.o bind.o unbind.o abandon.o filterentry.o phonetic.o acl.o
str2filter.o aclparse.o init.o user.o lock.o controls.o extended.o passwd.o
schema.o schema_check.o schema_init.o schema_prep.o schemaparse.o ad.o at.o
mr.o syntax.o oc.o saslauthz.o oidm.o starttls.o index.o sets.o referral.o
root_dse.o sasl.o module.o mra.o mods.o sl_malloc.o zn_malloc.o limits.o
operational.o matchedValues.o cancel.o syncrepl.o backglue.o backover.o
ctxcsn.o ldapsync.o frontend.o slapadd.o slapcat.o slapcommon.o slapdn.o
slapindex.o slappasswd.o slaptest.o slapauth.o slapacl.o component.o aci.o
txn.o slapschema.o slapmodify.o version.o -Wl,-E -fstack-protector-strong
-pthread libbackends.a liboverlays.a ../../libraries/liblunicode/liblunicode.a
../../libraries/librewrite/librewrite.a ../../libraries/liblutil/liblutil.a
../../libraries/libldap_r/.libs/libldap_r.a
/home/ryan/tmp/openldap/libraries/liblber/.libs/liblber.a
../../libraries/liblber/.libs/liblber.a -L/usr/local/lib
-L/usr/lib/x86_64-linux-gnu/perl/5.28/CORE -lperl -ldl -lm -lpthread -lcrypt
-lresolv -pthread
/usr/bin/ld: cannot find -lperl
collect2: error: ld returned 1 exit status
It should probably test compiling and linking a program with the detected
CPPFLAGS and LDFLAGS.
--
You are receiving this mail because:
You are on the CC list for the bug.
1 year, 11 months
[Bug 9224] New: Add support for PREPARE/2-phase commit
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9224
Bug ID: 9224
Summary: Add support for PREPARE/2-phase commit
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
In LMDB, add support for PREPARE/2-phase commits
--
You are receiving this mail because:
You are on the CC list for the bug.
1 year, 11 months
[Issue 9363] New: removing olcReadOnly on a DB does not set it to FALSE
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9363
Issue ID: 9363
Summary: removing olcReadOnly on a DB does not set it to FALSE
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: maxime.besson(a)worteks.com
Target Milestone: ---
Created attachment 771
--> https://bugs.openldap.org/attachment.cgi?id=771&action=edit
ldif config that reproduces the issue
I am running the following test:
* add olcReadOnly: TRUE on a MDB database in cn=config
* Try to write to the MDB database => fails with "unwilling to perform" as
expected
* remove the olcReadOnly attribute from the MDB database
* Try to write to the MDB database => still fails with the same error
* Restart slapd
* Try to write to the MDB database => OK
However the following test works as expected:
* add olcReadOnly: TRUE on a MDB database in cn=config
* Try to write to the MDB database => fails with "unwilling to perform" as
expected
* modify olcReadOnly to FALSE on the MDB database
* Try to write to the MDB database => OK
It seems a little counter intuitive to me that removing a setting does not
reset it to its default value. The fact that a slapd restart make writing
possible again in the first test described above makes it seem to the casual
user that olcReadOnly cannot be undone without a restart at all.
Tested in 2.4.53 and 2.4.44, config attached but it probably works with any
config (hdb, etc)
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 11 months
[Issue 9272] New: Invalid search results for subordinate/glued database
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9272
Issue ID: 9272
Summary: Invalid search results for subordinate/glued database
Product: OpenLDAP
Version: 2.4.47
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: grapvar(a)gmail.com
Target Milestone: ---
Here is a trivial test case. Look at the following bunch of glued
dit's/databases, declared in this order:
| suffix ou=a,ou=1,ou=T # subordinate; contains only one (top-level) entry
| suffix ou=2,ou=T # subordinate; contains only one (top-level) entry
| suffix ou=b,ou=1,ou=T # subordinate; contains only one (top-level) entry
| suffix ou=T # master database, has two entries, top-level
| ` ou=1 # ... and this child entry
let's query the united database:
| $ ldapsearch -b ou=1,ou=T -s sub '' nx
| dn: ou=1,ou=T
| dn: ou=a,ou=1,ou=T
| dn: ou=b,ou=1,ou=T
Nice! But wait, what if ...
| $ ldapsearch -b ou=1,ou=T -s sub -E\!pr=2/noprompt '' nx
| dn: ou=1,ou=T
| dn: ou=a,ou=1,ou=T
|
| # pagedresults: cookie=//////////8=
... BANG! ...
| Server is unwilling to perform (53)
The problem is the glue_op_search(), which has issues
* different parts of code make different assumptions about data structures
* different parts of code track state inconsistently
* code that looks like a highly probably dead code
I mean that likely possible to build another bug-triggering test cases, and
glue_op_search() needs not just a fix of the bug above, but intense cleaning
and structuring.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 11 months
[Bug 9219] New: Streamline tool API for 2.5
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9219
Bug ID: 9219
Summary: Streamline tool API for 2.5
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The current tool API is a mess and needs fixing for 2.5. This affects things
like slapacl (The fix for bug#7920 was a kludge to deal with this, needs
revisiting).
--
You are receiving this mail because:
You are on the CC list for the bug.
1 year, 11 months
[Issue 9295] New: ppolicy and replication: pwdLockedTime replication fails to replicate
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9295
Issue ID: 9295
Summary: ppolicy and replication: pwdLockedTime replication
fails to replicate
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If you have the following setup, a replica will hit an error during
replication.
a) ppolicy is configured on provider(s) and replicas. Replica has
schemachecking=on in its syncrepl configuration
b) account gets locked on the replica, so pwdAccountLockedTime is set on the
replica but not on the provider(s)
c) admin does a MOD/ADD op against a provider for the user entry to add a value
to pwdAccountLockedTime
dn: ...
changetype: modify
add: pwdAccountLockedTime
pwdAccountLockedTime: ...
d) provider accepts this modification.
e) replica rejects this modification because the resulting change means that
there would be two pwdAccountLockedTime values on the account in question
Generally I believe that in this scenario, the MOD/ADD on the provider should
be treated as a replace OP instead of an ADD op
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years