[Issue 9524] New: Removing last entry in database triggers MDB_PROBLEM
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9524
Issue ID: 9524
Summary: Removing last entry in database triggers MDB_PROBLEM
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: kriszyp(a)gmail.com
Target Milestone: ---
With a fresh database, if you have have an open read transaction, and you
create a new entry in a write transaction and commit it, and then create a new
transaction and delete that entry, when you commit, it will return an
MDB_PROBLEM from approximately line 4408 from the mt_loose_count/dirty_list
check. This seems to occur on mdb.master3, but not mdb.master. Here is a
minimal example/test-case of how to reproduce:
MDB_env* env;
mdb_env_create(&env);
int rc, flags = 0;
mdb_env_open(env, "test", flags, 0664);
MDB_txn* readonly_txn;
mdb_txn_begin(env, nullptr, MDB_RDONLY, &readonly_txn);
MDB_txn* txn;
MDB_dbi dbi;
mdb_txn_begin(env, nullptr, 0, &txn);
mdb_dbi_open(txn, nullptr, MDB_CREATE, &dbi);
MDB_val val;
val.mv_data = (void*) "test";
val.mv_size = 4;
mdb_put(txn, dbi, &val, &val, 0);
mdb_txn_commit(txn);
mdb_txn_begin(env, nullptr, 0, &txn);
mdb_del(txn, dbi, &val, nullptr);
rc = mdb_txn_commit(txn); // this returns MDB_PROBLEM
(let me know if this should be submitted differently)
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 2 months
[Issue 9339] New: Add syncrepl status in cn=monitor
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9339
Issue ID: 9339
Summary: Add syncrepl status in cn=monitor
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Patch coming to expose some consumer state in cn=monitor
Sample entry:
# Consumer 001, database 2, databases, monitor
dn: cn=Consumer 001,cn=database 2,cn=databases,cn=monitor
objectClass: olmSyncReplInstance
structuralObjectClass: olmSyncReplInstance
cn: Consumer 001
creatorsName:
modifiersName:
createTimestamp: 20200906160447Z
modifyTimestamp: 20200906160447Z
olmSRProviderURIList: ldap://localhost:9011/
olmSRIsConnected: TRUE
olmSRSyncPhase: Persist
olmSRLastConnect: 20200906160448Z
olmSRLastContact: 20200906160453Z
olmSRLastCookieRcvd: rid=001,sid=001,csn=20200906160453.039573Z#000000#001#000
000
olmSRLastCookieSent: rid=001,sid=002,csn=20200906160447.723677Z#000000#001#000
000
entryDN: cn=Consumer 001,cn=database 2,cn=databases,cn=monitor
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 2 months
[Issue 9853] New: lastbind-precision conversion fails from slapd.conf to cn=config
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9853
Issue ID: 9853
Summary: lastbind-precision conversion fails from slapd.conf to
cn=config
Product: OpenLDAP
Version: 2.6.2
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
When converting a slapd.conf file to cn=config, the "lastbind-precision" value
is not preserved.
slapd.conf:
lastbind-precision 300
cn=config value:
olcLastBindPrecision: 0
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 2 months
[Issue 9437] New: Add OTP module to core
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9437
Issue ID: 9437
Summary: Add OTP module 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 OTP module for OpenLDAP 2.5 as a core overlay
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 2 months
[Issue 9817] New: rwm overlay : Issue with DN containing special characters
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9817
Issue ID: 9817
Summary: rwm overlay : Issue with DN containing special
characters
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: thierry.pubellier(a)paris.fr
Target Milestone: ---
Hi,
I'm using rwn to select the database useg for bind operations based on the
result of a rewriteMap requets.
Sample configuration in global section :
#Rewrite Map to request a remote server
rwm-rewriteMap ldap checkEntry
"ldap://10.1.2.3/ou=users,dc=paris,dc=local?dn?sub"
binddn="cn=myuser,ou=users,dc=paris,dc=local" credentials="XXX"
# Backing up original DN
rwm-rewriteRule ".+" "${&binddn($0)}$0" ":"
# Contructing LDAP Filter for remote search. Combined with a rewrite Map,
the requested DN is returned if there is a match.
rwm-rewriteRule ".+" "(&(!(description=TEST))(distinguishedName=$0))"
":"
# If filter matches, end of rewriting. Going to 'dc=paris,dc=local'
database
rwm-rewriteRule ".+" "${checkIfPasswordExpiredDN($0)}" ":@I"
# Otherwise, restoring the original DN.
rwm-rewriteRule ".+" "${*binddn}" ":"
# And final DN massaging from "dc=paris,dc=local" to "dc=paris,dc=local2"
database
rwm-rewriteRule "(.+,)?ou=users,dc=paris,dc=local$"
"$1ou=users,dc=paris,dc=local2" ":@"
Everything goes fine until I use DN with special characters, like ',' or '['.
For example : 'cn=Pubellier\, Thierry (TEST),ou=users,dc=paris,dc=local'
In this case, the rwm-rewriteRule contructs a LDAP filter with incorrect
syntax, as special caracters are not being escaped.
I have to use some ugly tricks to escape these caracters, as shown below :
#Rewrite Map to request a remote server
rwm-rewriteMap ldap checkEntry
"ldap://10.1.2.3/ou=users,dc=paris,dc=local?dn?sub"
binddn="cn=myuser,ou=users,dc=paris,dc=local" credentials="XXX"
# Backing up original DN
rwm-rewriteRule ".+" "${&binddn($0)}$0" ":"
# Rewriting for ','
rwm-rewriteRule "(.+).\2C(.+)" "$1\\,$2"
# Adding a special '#' (asserting it in none of my DNs) suffix for special
characters, in order to escape them without looping forever
rwm-rewriteRule "(.*)([)*(\\])([^#].*|$)" "$1$2#$3"
# Escaping of special characters with dedicated '#' suffix, avoiding
infinite loops
rwm-rewriteRule "(.*)([)*(\\])#(.*)" "$1\\$2$3"
# Contructing LDAP Filter for remote search. Combined with a rewrite Map,
the requested DN is returned if there is a match.
rwm-rewriteRule ".+" "(&(!(description=TEST))(distinguishedName=$0))"
":"
# If filter matches, end of rewriting. Going to 'dc=paris,dc=local'
database
rwm-rewriteRule ".+" "${checkIfPasswordExpiredDN($0)}" ":@I"
# Otherwise, restoring the original DN.
rwm-rewriteRule ".+" "${*binddn}" ":"
# And final DN massaging from "dc=paris,dc=local" to "dc=paris,dc=local2"
database
rwm-rewriteRule "(.+,)?ou=users,dc=paris,dc=local$"
"$1ou=users,dc=paris,dc=local2" ":@"
Could there be a way to integrate the ldap escape mechanism when making an
variable assignment (like using a '#' character in place of the usual '&') ?
Thanks by advance,
Best regards,
Thierry
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 2 months
[Issue 9438] New: Add remoteauth overlay to core
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9438
Issue ID: 9438
Summary: Add remoteauth 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 remoteauth overlay for OpenLDAP 2.5 as a core overlay
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 2 months
[Issue 9358] New: back-mdb may return accesslog entries out of order
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9358
Issue ID: 9358
Summary: back-mdb may return accesslog entries out of order
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
back-mdb will usually return search entries in entryID order, but may do a dn
traversal instead if the count of children is smaller than the count of search
filter candidates. The RDNs are sorted in length order, not lexical order. For
accesslog, all RDNs are of equal length but if they have trailing zeroes, the
generalizedTime normalizer truncates them. Changing their lengths causes
accesslog's timestamp-based RDNs to sort in the wrong order.
The least intrusive fix is to override the syntax/normalizer for reqStart and
reqEnd attributes to not truncate trailing zeroes.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 3 months
[Issue 9516] New: Argon2 configuration parameters with slappasswd
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9516
Issue ID: 9516
Summary: Argon2 configuration parameters with slappasswd
Product: OpenLDAP
Version: 2.4.58
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: gilbert.kowarzyk(a)servicenow.com
Target Milestone: ---
It is currently possible to generate an Argon2 hash using slappasswd as
follows:
slappasswd -h {ARGON2} -o module-load=pw-argon2
However, I believe that it is currently not possible to provide Argon2
configuration values for parameters "m", "t", and "p" when using slappasswd.
If it is currently possible to provide these config parameters when using
slappasswd, please add documentation for how to do so.
Thanks in advance!
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 3 months
[Issue 9596] New: Python test suite
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9596
Issue ID: 9596
Summary: Python test suite
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
The bash test suite is extremely limited, hard to write for and slow. We can't
lose it as it is also portable, but something should be introduced for
developers/CI on more modern systems and increase coverage.
A Python 3 seed for one is in development in MR!347.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 3 months
[Issue 9873] New: idle timeout by backends close connections
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9873
Issue ID: 9873
Summary: idle timeout by backends close connections
Product: OpenLDAP
Version: 2.6.2
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ettorevi(a)gmail.com
Target Milestone: ---
Hi,
making searches through lloadd to a bunch of backends returns weird results
Sometimes I get:
| ldap_bind: Other (e.g., implementation specific) error (80)
| additional info: connection to the remote server has been severed
Others
ldap_result: Can't contact LDAP server (-1)
due to an idle_timeout from the backend in the middle of the search, in a non
deterministic way.
If I search directly on the backends everything works
ldapsearch -x -Hldaps://lloadd.server 'objectClass=*' -w pwd
[...]
# numResponses: 9620
# numEntries: 9620
ldap_result: Can't contact LDAP server (-1)
lloadd compiled standalone from 2.6.2 with:
--enable-balancer=yes --enable-syslog --enable-debug --enable-slapd=no
Backends are older, 2.4.49+dfsg-2ubuntu1.9 from Ubuntu 20.04
Any hints?
Thank you
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 4 months