https://bugs.openldap.org/show_bug.cgi?id=9186
Bug ID: 9186
Summary: RFE: More metrics in cn=monitor
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Currently I'm grepping metrics from syslog with mtail:
https://gitlab.com/ae-dir/ansible-ae-dir-server/-/blob/master/templates/mta…
With a new binary logging this is not possible anymore.
Thus it would be nice if cn=monitor provides more metrics.
1. Overall connection count per listener starting at 0 when started. This would
be a simple counter added to:
entries cn=Listener 0,cn=Listeners,cn=Monitor
2. Counter for the various "deferring" messages separated by the reason for
deferring.
3. Counters for all possible result codes. In my mtail program I also label it
with the result type.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9284
Issue ID: 9284
Summary: Need man page for vc contrib overlay
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The verified credentials overlay in contrib is missing a man page describing
its purpose
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9495
Issue ID: 9495
Summary: authz-regexp using dn: instead of a URI mangles
characters with HTML excapes
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: kop(a)karlpinc.com
Target Milestone: ---
Trying to use an authz-regexp that maps directly to dn-s by using "dn:..."
instead of a URI results in the authz id having some characters "html escaped".
As a result the authorized entity cannot be found.
E.g. a "-U cn=Barbara Jensen,ou=Information Technology Division"
with
olcAuthzRegexp: "^uid=([^,]+),.*" "dn:$1,ou=people,dc=example,dc=com"
fails. Debug logs show that the equal and the comma character return from
ldap_bv2dn() in escaped forms, that are then substituted into the target dn and
result in a dn that does not exist in the DIT.
6046d7cd SASL Canonicalize [conn=1113]: authcid="cn=Barbara
Jensen,ou=Informatio
n Technology Division"
6046d7cd slap_sasl_getdn: conn 1113 id=cn=Barbara Jensen,ou=Information
Technolo
gy Division [len=52]
=> ldap_dn2bv(16)
<= ldap_dn2bv(uid=cn\3DBarbara Jensen\2Cou\3DInformation Technology
Division,cn=PLAIN,cn=auth)=0
6046d7cd slap_sasl_getdn: u:id converted to uid=cn\3DBarbara
Jensen\2Cou\3DInformation Technology Division,cn=PLAIN,cn=auth
...
6046d7cd send_ldap_result: err=49 matched="" text="SASL(-13): user not found:
Password verification failed"
I suspect that when the "dn:..." form is used with authz-regexp the supplied
authzid should _not_ have it's characters canonicalized because they will not
be substituted into a URI. If so, this would be a bug. If not, there should
be documentation on the restrictions on what characters can be used in authzid
when the "dn:..." form is used.
Tested against HEAD of master, although the version in the bug report is 2.5.
See also Bug# 6912.
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
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.
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.
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.
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.
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.