openldap-bugs May 2021

openldap-bugs@openldap.org

1 participants
148 discussions

[Issue 9444] New: Feature Request: Textual error data is not sent through chaining overlay
by openldap-its＠openldap.org 24 Jun '21

24 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9444 Issue ID: 9444 Summary: Feature Request: Textual error data is not sent through chaining overlay Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: andrewlanecarr(a)gmail.com Target Milestone: --- When operating in a replicated environment we would like to see the text message accompany the error code propagated to the other nodes in the cluster. For Example: Master Log - master slapd[406]: conn=1160 op=3 MOD attr=userPassword master slapd[406]: conn=1160 op=3 RESULT tag=103 err=19 text=Password is not being changed from existing value Slave Log - slave slapd[31094]: conn=1000 op=18 MOD attr=userPassword slave slapd[31094]: conn=1000 op=18 RESULT tag=103 err=19 text= The text "Password is not being changed from existing value" is not copied in this process. This is using the following configuration: -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Bug 9243] New: back-perl configure should test linking with libperl
by openldap-its＠openldap.org 23 Jun '21

23 Jun '21

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 7

[Bug 9224] New: Add support for PREPARE/2-phase commit
by openldap-its＠openldap.org 23 Jun '21

23 Jun '21

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 2

[Issue 9363] New: removing olcReadOnly on a DB does not set it to FALSE
by openldap-its＠openldap.org 22 Jun '21

22 Jun '21

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.

2 9

[Issue 9512] New: Add ability to restrict by client ip address in ACLs
by openldap-its＠openldap.org 14 Jun '21

14 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9512 Issue ID: 9512 Summary: Add ability to restrict by client ip address in ACLs 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: --- Currently it is possible via ACLs to enforce restrictions based on which slapd host interface is connected to via the peername parameter. However, it's not possible to enforce ACL restrictions based on the IP address used by the client. This would be a useful feature when wanting to restrict certain DNs to only being able to have access if they connect from a certain IP or IP range. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9557] New: syncrepl refreshonly sometimes finishes too early
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9557 Issue ID: 9557 Summary: syncrepl refreshonly sometimes finishes too early Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: replication Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- In a delta-MMR test environment where conflicts are intentionally introduced, the fallback sessions sometimes cut off, not sending all entries they ought to. Instead LDAP_SUCCESS is sent with the snapshot cookie at some point. That cookie represents the correct contextCSN at the time of the search, so the missing changes are skipped over forever. As of now, the cause of the cutoff is under investigation. Currently, this was only run with 2.5 + persistent sessionlog enabled but there are indications this might not be limited to 2.5, tests with other versions/configs are pending. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9551] New: dnSubtreeMatch and others do not handle empty DN as asserted value
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9551 Issue ID: 9551 Summary: dnSubtreeMatch and others do not handle empty DN as asserted value Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- AFAIK '(reqDN:dnSubtreeMatch:=)' should be equivalent to 'reqDN=*', however it only seems to match the empty dn right now. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9537] New: slap_timestamp() can give a duplicated timestamp across restarts
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9537 Issue ID: 9537 Summary: slap_timestamp() can give a duplicated timestamp across restarts Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- On busy sites, when a slapd restart takes <1s, accesslog can fail to log changes with LDAP_ALREADY_EXISTS. This is because slap_timestamp() only logs timestamps with a 1s precision, disambiguating the rest with a counter that's forgotten across restarts. It is possible my analysis in ITS#9487 is partially invalidated because of this. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9526] New: slapadd -w crashes
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9526 Issue ID: 9526 Summary: slapadd -w crashes Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- Let slapd.conf is: > database mdb > suffix "o=Foo" > sync_use_subentry database is blank and we are adding this foo.ldif: > dn: o=FOO > objectClass:organization Let's load: > slapd -T add -v -l foo.ldif -w then on Solaris: > added: "o=FOO" (00000001) > Segmentation Fault (core dumped) ... on Linux: > added: "o=FOO" (00000001) > => mdb_next_id: get failed: Invalid argument (22) > => mdb_tool_next_id: next_id failed: Invalid argument (22) > => mdb_tool_entry_put: txn_aborted! Invalid argument (22) > slapadd: couldn't create context entry > Closing DB... This is because: * mdb_tool_next_id() takes dead global [tools.c`static MDB_cursor *mcp] for further operations * cursor is dead because mdb_tool_entry_put() didn't initialized it * mdb_tool_entry_put() didn't initialized cursor because it thinks it is initialized, because there is an active global [tools.c`MDB_txn *mdb_tool_txn] * transaction was initialized by mdb_tool_dn2id_get(), which doesn't care about cursors. Long story short: the global state in tools.c is not managed consistently and needs rethinking. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9552] New: slapo-accesslog should record new DN after rename
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9552 Issue ID: 9552 Summary: slapo-accesslog should record new DN after rename Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- To use accesslog as a sessionlog source, one needs to be able to resolve whether a modrdn moved an entry in/out of the search scope. Syncprov would either have to examine every modrdn request or, if accesslog were to log the final DN, it could check for entries which crossed the scope. A new attribute 'reqNewDN' should be tracked for modrdn ops. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

← Newer
1
...
5
6
7
8
9
10
11
...
15
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2021