[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
[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
[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
[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
[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, 1 month
[Issue 9534] New: Persistent test043 failures
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9534
Issue ID: 9534
Summary: Persistent test043 failures
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: ---
In testing current RE25 as of 4/23/2021
(73b2769d05529a7d474661023f2c4f3a931417b2)
test043 is sporadically failing. Examining the testrun log, it appears
replication never even initiated.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 2 months
[Issue 9468] New: slapd-ldap does anonymous bind even if rebind-as-user is set
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9468
Issue ID: 9468
Summary: slapd-ldap does anonymous bind even if rebind-as-user
is set
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: tero.saarni(a)est.tech
Target Milestone: ---
When back-ldap retries bind operation after connection retry, it will do it as
anonymous even if rebind-as-user is set to yes.
Expected behavior is that (re)bind is done with user's credentials from the
initial bind operation.
I observed following (Warning: I might have understood details of the code
incorrectly):
When rebind-as-user is set and bind operation from client is processed, proxy
will copy the credentials to ldapconn_t representing the remote LDAP
connection. When remote LDAP connection is closed (e.g. by the proxy itself due
to timeout), the bind credentials information is lost when freeing the old
ldapconn_t. At this point, client still holds the connection to proxy and is
unaware of the remote connection being lost. Proxy then re-establishes the
connection and "synthetically" generates new bind itself, but since it does not
have the credentials stored in memory anymore, it sends anonymous bind on
behalf of the client.
As a side effect, slapd currently crashes if remote server does not allow
anonymous bind and responds with InvalidCredentials instead. The crash is due
to assert(), which is handled in separate issue
https://bugs.openldap.org/show_bug.cgi?id=9288
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 2 months
[Issue 9385] New: Opening an env with MDB_NOSUBDIR with no existing file returns error
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9385
Issue ID: 9385
Summary: Opening an env with MDB_NOSUBDIR with no existing file
returns error
Product: LMDB
Version: unspecified
Hardware: All
OS: Mac OS
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: kriszyp(a)gmail.com
Target Milestone: ---
Created attachment 776
--> https://bugs.openldap.org/attachment.cgi?id=776&action=edit
A fix to tolerate stat call on non-existing file
Calling mdb_env_open with a file path to a file that doesn't exist yet, with
MDB_NOSUBDIR on a non-Windows OS will return an error indicating that the file
doesn't exist. This is supposed to create a new file, and works properly on the
mdb.master branch, and still functions properly on Windows. The error is due to
the stat() call in mdb_env_open prior to the file existing.
I attached a patch that tolerates the absence of the file before checking if
the file is on a block device. I am not sure if this is the appropriate fix, or
if would be better to move this check later in mdb_env_open after the file is
created, or alternately, determining the parent directory and calling stat on
that.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 4 months
[Issue 9403] New: add option to completely disable syslog logging
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9403
Issue ID: 9403
Summary: add option to completely disable syslog logging
Product: OpenLDAP
Version: 2.4.45
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: cvuillemez(a)yahoo.fr
Target Milestone: ---
For auditing purpose, I need to enable "stats" loglevel.
So on heavy load, slapd send lots of events to local syslog socket /dev/log,
when compiled with LDAP_SYSLOG (on Debian / Ubuntu).
It worked fine on old systems with a simple syslog service.
But when upgrading on system with journald+syslog, CPU "overhead" becomes
totally crazy.
It would be great to have an option at run time to completely disable syslog
logging, or/and use a cutom socket, e.g. /run/systemd/journal/syslog to bypass
journald service.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 4 months
[Issue 9497] New: back-ldif: test022-ppolicy failure
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9497
Issue ID: 9497
Summary: back-ldif: test022-ppolicy failure
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hamano(a)osstech.co.jp
Target Milestone: ---
The test022-ppolicy with back-ldif fail for two issue.
1. too short pwdMaxAge
~~~
$ ./run -b ldif test022-ppolicy
(snip)
Testing password expiration
Waiting seconds for password to expire...
sleep: missing operand
Try 'sleep --help' for more information.
Password expiration test failed
~~~
The script tries test for lockout and then a test for password expiration.
It will fail if the password has expired(pwdMaxAge: 30) by the time it starts
the password expiration test.
This is a timing issue and not directly caused by back-ldif.
However, the issue is reproduced only with back-ldif in my environment.
This test passed in my environment by extending pwdMaxAge by 5 seconds, but
there may be a better way.
2. duplicate ldap control response
~~~
Reconfiguring policy to remove grace logins...
Clearing forced reset...
expr: syntax error: unexpected argument '15'
Testing password expiration
Waiting seconds for password to expire...
sleep: missing operand
Try 'sleep --help' for more information.
~~~
This is back-ldif issue.
back-ldif responds duplicate ldap control response.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 6 months