[Bug 9197] New: slapd-ldap/slapo-chain hits error 80 after idletimeout
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9197
Bug ID: 9197
Summary: slapd-ldap/slapo-chain hits error 80 after idletimeout
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
From a customer:
In order to communicate via the LB managed writable ldap, we have to ensure
that an idle connection is periodically refreshed. If we do not, the LB will
silently drop the connection after 5 minutes.
Therefore to combat that I set an olcIdleTimeout on the writable server so that
the chain cached connections will be removed before the LB timeout hits.
However the slapo-ldap client goes into CLOSE_WAIT state, which causes
subsequent ldapmodify updates being brokered by the read only instance to fail
with err=80. There appear to be a few bugs filed on this in the past against
slapd-ldap, but it's not clear if we may be hitting the same issue, or if this
is a new one.
I've also connected the read only instances directly to the writable ldap
instances and the CLOSE_WAIT issue persists, so I don't believe the CLOSE_WAIT
issue is caused by the LB
These were the other threads I found as I started looking for this problem,
these are using the ldap-proxy though I think:
https://www.openldap.org/lists/openldap-technical/201301/msg00323.html
http://www.openldap.org/lists/openldap-software/201004/msg00060.html
https://www.openldap.org/lists/openldap-bugs/200412/msg00029.html
The LB we have seems to be set to forget connections that last over 5 min per
the setting, so the 240:10:30 seemed like it should have worked and I just
thought it wasn't working because in the man page the text "Only some systems
support the customization of these values" is present. however after setting
keepalive to 60:10:30 did I maintain a stable connection, so there may be other
network settings at play I'm not aware of.
--
You are receiving this mail because:
You are on the CC list for the bug.
1 month, 2 weeks
[Bug 9186] New: RFE: More metrics in cn=monitor
by openldap-its＠openldap.org
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/m...
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.
1 month, 2 weeks
[Bug 9194] New: slapd-ndb: Remove backend for the 2.5 release
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9194
Bug ID: 9194
Summary: slapd-ndb: Remove backend for the 2.5 release
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Remove the slapd-ndb backend for the 2.5 release, as it was never finished and
development on it has ceased.
--
You are receiving this mail because:
You are on the CC list for the bug.
1 month, 2 weeks
[Bug 9191] New: libraries\liblutil\meter.c have a bad function lutil_meter_update, maybe divide 0
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9191
Bug ID: 9191
Summary: libraries\liblutil\meter.c have a bad function
lutil_meter_update, maybe divide 0
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: digpython(a)163.com
Target Milestone: ---
int
lutil_meter_update (
lutil_meter_t *meter,
size_t position,
int force)
{
static const double display_rate = 0.5;
double frac, cycle_length, speed, now;
time_t remaining_time, elapsed;
int rc;
assert( meter != NULL );
lutil_get_now( &now );
if ( !force && now - meter->last_update < display_rate ) return 0;
frac = ((double)position) / ((double) meter->goal_value);
elapsed = now - meter->start_time;
if (frac <= 0.0) return 0;
if (frac >= 1.0) {
rc = meter->display->display_update(
&meter->display_data,
1.0,
0,
(time_t) elapsed,
((double)position) / elapsed);
} else {
...
}
--
You are receiving this mail because:
You are on the CC list for the bug.
1 month, 2 weeks
[Bug 9189] New: Add GSSAPI channel-bindings support
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9189
Bug ID: 9189
Summary: Add GSSAPI channel-bindings support
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: iboukris(a)gmail.com
Target Milestone: ---
Recently MS has announce they plan to enforce channel-bindings for LDAP over
TLS (ADV190023).
To support it on client side, we need to pass "tls-endpoint" bindings (RFC
5929) to the SASL plugin, and make use of that in GSSAPI.
See also:
https://github.com/cyrusimap/cyrus-sasl/pull/601
--
You are receiving this mail because:
You are on the CC list for the bug.
1 month, 2 weeks
[Bug 9185] New: glue entry
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9185
Bug ID: 9185
Summary: glue entry
Product: OpenLDAP
Version: 2.4.48
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: gnoe(a)symas.com
Target Milestone: ---
--
You are receiving this mail because:
You are watching someone on the CC list of the bug.
2 months, 1 week
[Bug 9188] New: Expose transaction mt_flags?
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9188
Bug ID: 9188
Summary: Expose transaction mt_flags?
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: code(a)doriantaylor.com
Target Milestone: ---
Created attachment 631
--> https://bugs.openldap.org/attachment.cgi?id=631&action=edit
patch in mdb_txn_flags
I have taken over maintenance of the Ruby bindings to LMDB
(https://github.com/doriantaylor/lmdb/tree/reconcile-2.7) and am currently
fleshing out the transaction code. What I am finding is something of a leaky
abstraction: in the current configuration it is essentially too easy to write
Ruby code that messes up the internal transaction bookkeeping of the binding.
I am still trying to get my bearings on both the binding and the LMDB library
itself, but it seems it would be generally useful if it was possible to
determine whether a given transaction was read-only, so for example to prevent
one from opening a read-write transaction beneath a read-only one.
As such, I propose the enclosed patch that adds an `mdb_txn_flags` function,
which returns the `mt_flags` field. This would enable downstream developers to
tell if a given transaction was, among other things, read-only, and behave
accordingly.
--
You are receiving this mail because:
You are on the CC list for the bug.
7 months, 3 weeks
[Bug 9196] New: Problem using ldapsearch across forests with trust
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9196
Bug ID: 9196
Summary: Problem using ldapsearch across forests with trust
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: kleber.s.carvalho(a)avanade.com
Target Milestone: ---
Created attachment 695
--> https://bugs.openldap.org/attachment.cgi?id=695&action=edit
Problem using ldapsearch across forests with trust
Hello,
We are in a project where the client has an application developed in Java that
has a library developed by the client himself that uses the openldap tool to
authenticate users that exist in the minca.com domain. However, this company is
undergoing a drastic business change and this minca.com domain that belongs
only in one forest must have a one-way trust relationship with another forest
called klabs.com and its respective domains children (subtree), the general
drawing can be checked in the file 1_forest_trust.pdf.
The trust relationship between the two forests was successfully carried out as
can be seen in the files 2_trust_minca.JPG and 3_trust_klabs.JPG
A user named minca was created in the minca.com domain, that is,
minca(a)minca.com according to files 4_mincauser_1.JPG and 4_mincauser_2.JPG (to
observe the SID). Meanwhile, in the domain child.klabs.com, the group
CHILDADMINS was created and the user minca from the forest minca.com was
successfully added according to file 5_childadminsgroup.JPG.
First, we performed a valid test by performing authentication and a simple
query directly to the minca.com domain, with the command:
ldapsearch -H 'LDAP: //minca.com: 3268' -D 'cn = Administrator, cn = users, dc
= minca, dc = with' -w Avanade @ 2020! -b 'cn = users, dc = minca, dc = com'
According to the 6_openldap_direct_sucess.JPG file, it is possible to observe
that the result became what was expected.
However, when performing this procedure and authenticating the user
minca(a)minca.com in the child.klabs.com domain using the ldapsearch tool, the
result was an error according to file 7_openldaperror_indirectaccess.JPG
stating invalid credentials
In addition, searching the internet, we verified that the LDAP call should be
LDAP: //child.klabs.com/dc=minca,dc=com, however, ldapsearch returned PARSE
LDAP URI (s) error, as per file 8_openldaperror_parse.JPG.
However, a .net application was created to perform this same function and it
worked, as per file 9_dotNetApp_success.JPG
After that, we tried to understand if the openldap tool would be able to
perform the same action on the same tree (subtree) and we obtained the expected
success result according to the file 10_openldap_subtree_success.JPG
So, we tried to list the members of the CHILDADMINS group that are in the
child.klabs.com domain and have as a member a user from the minca.com forest,
using the command:
ldapsearch -H 'LDAP: //child.klabs.com: 3268' -D 'cn = Administrator, cn =
users, dc = child, dc = klabs, dc = with' -w Avanade @ 2020! -b 'cn =
CHILDADMINS, cn = users, dc = child, dc = klabs, dc = com'
and it was observed that openldap I find the user in question bringing his SID
according to the figure 11_openldap_GroupMemberOf_SSID.JPG and, afterwards with
a treatment in the openldap tool itself through the command:
ldapsearch -H 'LDAP: //child.klabs.com: 3268' -D 'cn = Administrator, cn =
users, dc = child, dc = klabs, dc = with' -w Avanade @ 2020! -b "cn =
ForeignSecurityPrincipals, dc = child, dc = klabs, dc = com" "CN =
S-1-5-21-1644185942-511557352-3723172775-1107" msDS-PrincipalName
We managed to get the PrincipalName property of the user the figure
12_openldap_SSID_to_PrincipalName.JPG
Finally, the conclusion we are reaching is that the openldap tool does not work
directly between forests, but only on the same tree. We would like to know if
this understanding is correct or if this is really a bug in the tool.
Well, I tried to detail the situation as much as possible, please help us
understand this.
Thank you very much for your attention.
--
You are receiving this mail because:
You are on the CC list for the bug.
8 months