https://bugs.openldap.org/show_bug.cgi?id=9932
Issue ID: 9932
Summary: Sync failing between two LDAP servers
Product: OpenLDAP
Version: 2.4.58
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: shikhar81(a)gmail.com
Target Milestone: ---
Hi Team,
We have noticed a sync issue in our environment.
We have two production servers namely A and B and two DR servers namely C and
D.
A and B are in bi-directional sync
A and C are in bi-directional sync
B and D are in bi-directional sync
Since the last few days the sync between A and C and B and D has broken and we
are unable to see any concrete error in logs
Just to add here that server A and server B are in the same subnet and server C
& server D are in a different subnet. However, this setup has been working fine
since the last many years with no issues at all.
Since the last few days the connection has broken as mentioned earlier.
Now we also tried to initiate a sync between C and D (DR servers) which are in
the same subnet. But still it is not syncing and we get a "no connection" error
message in the logs after trying for 2-3 hrs.
Can you please suggest what can be done here.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9928
Issue ID: 9928
Summary: ldap_search_ext_s always hangs on 2.6.3
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: filipe.custodio(a)gmail.com
Target Milestone: ---
Created attachment 920
--> https://bugs.openldap.org/attachment.cgi?id=920&action=edit
Minimal AD query that consistently hangs on ldap_search_ext_s call
Dear Experts,
When using ldap_search_ext_s() from libldap v2.6.3 to do a simple search on our
production Windows Domain Controller, the client consistently hangs forever.
Using ldap_search_ext() & ldap_result() also hangs after delivering the first
information item. It seems the client is left waiting, not realising no more
results are coming from the server.
Using the development image from Oct. 9 2022, the ldap_search_ext_s() call
works, although it gives an "Operations Error".
Shall I deploy the new libldap from the development branch in our production
environment to solve this problem or is there another way around the issue?
Best regards,
Filipe Custódio
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9919
Issue ID: 9919
Summary: The use of a separate section for cold code can cause
linking issues on macOS
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: mh-bcrayqnc(a)glandium.org
Target Milestone: ---
See e.g. https://github.com/llvm/llvm-project/issues/52767
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9365
Issue ID: 9365
Summary: Mem leaks with Æ-DIR providers
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Created attachment 772
--> https://bugs.openldap.org/attachment.cgi?id=772&action=edit
valgrind output on openSUSE Tumbleweed x86_64
An Æ-DIR installation with self-compiled OpenLDAP 2.4.53 on Debian (now
buster) has memory leak issues on the Æ-DIR providers. The read-only
consumers do not have this issue. The provider config is more complex
with more overlays and more ACLs.
In this production deployment slapd is automatically restarted (by monit) when
memory consumption reaches 80%. Thus monitoring clearly shows a frequent saw
tooth pattern.
I've also tested on openSUSE Tumbleweed x86_64 with a RE24 build [1] by running
slapd under control of valgrind for a couple of minutes continously sending
simple bind operations (additional to the monitoring and other back-ground jobs
running).
Find valgrind output of my first attempt attached.
Does that make sense at all?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9923
Issue ID: 9923
Summary: extensible match ignored
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: francois(a)rcdevs.com
Target Milestone: ---
Hi,
I'm trying to use a matching rule with slapd as a proxy in front of Active
Directory with back-ldap
The request is something similar to
'(memberOf:1.2.840.113556.1.4.1941:=cn=gp1,o=Root)'
It works if I use it directly on AD.
Unfortunately, the request is ignored by slapd and not forwarded, I receive a
"success" but the result is empty.
The request is forwarded if I use something like this:
'(memberOf=cn=gp1,o=Root)'
Could it be possible to forward the request to the backend? slapd doesn't need
to understand the meaning of the OID.
slapd with matching rule:
[2022-09-28 11:07:39] begin get_filter
[2022-09-28 11:07:39] EXTENSIBLE
[2022-09-28 11:07:39] daemon: activity on 1 descriptor
[2022-09-28 11:07:39] end get_filter 0
[2022-09-28 11:07:39] filter: (?=undefined)
[2022-09-28 11:07:39] attrs: dn
[2022-09-28 11:07:39] conn=1000 op=1 SRCH base="o=root" scope=2 deref=0
filter="(?=undefined)"
slapd without matching rule:
[2022-09-28 11:07:47] begin get_filter
[2022-09-28 11:07:47] EQUALITY
[2022-09-28 11:07:47] get_ava: unknown attributeType memberOf
[2022-09-28 11:07:47]
[2022-09-28 11:07:47] end get_filter 0
[2022-09-28 11:07:47] daemon: epoll: listen=7 active_threads=0 tvp=NULL
[2022-09-28 11:07:47] daemon: epoll: listen=8 active_threads=0 tvp=NULL
[2022-09-28 11:07:47] filter: (?memberOf=cn=gp1,o=Root)
[2022-09-28 11:07:47] attrs: dn
[2022-09-28 11:07:47] conn=1001 op=1 SRCH base="o=root" scope=2 deref=0
filter="(?memberOf=cn=gp1,o=Root)"
searchrequest dump:
0000 30 56 02 01 02 63 51 04 06 6f 3d 72 6f 6f 74 0a 0V...cQ..o=root.
0010 01 02 0a 01 00 02 01 00 02 01 00 01 01 00 a9 32 ...............2
0020 81 17 31 2e 32 2e 38 34 30 2e 31 31 33 35 35 36 ..1.2.840.113556
0030 2e 31 2e 34 2e 31 39 34 31 82 08 6d 65 6d 62 65 .1.4.1941..membe
0040 72 4f 66 83 0d 63 6e 3d 67 70 31 2c 6f 3d 52 6f rOf..cn=gp1,o=Ro
0050 6f 74 30 04 04 02 64 6e ot0...dn
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9878
Issue ID: 9878
Summary: test043 failures in 2.5/2.6
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
With test043 update for ITS#9823, we manage to introduce a scenario where the
server is completely idle except for a runqueue change.
This is partly identical with ITS#9642 and a similar approach would work.
Except that changes our module facing ABI so might not be something we can
backport. For the streams we can't, we might have to change the test to make
the server not idle.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9922
Issue ID: 9922
Summary: Uninitialized value reading in
clients/tools/common.c:tool_bind()
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
One possible flow in
https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/comm…
is:
int err;
if ( result ) {
rc = ldap_parse_result( ld, result, &err, &matched, &info, &refs, &ctrls, 1
);
if ( rc != LDAP_SUCCESS ) {
tool_perror( "ldap_bind parse result", rc, NULL, matched, info, refs );
tool_exit( ld, LDAP_LOCAL_ERROR );
}
}
if ( err != LDAP_SUCCESS …
When result is NULL, err is not initialized, and the last line reads
uninitialized value.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9030
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |0.9.30
--- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
RE0.9:
• 4bb20ed0
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9030
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from Howard Chu <hyc(a)openldap.org> ---
patched in mdb.master ; mdb.master3 ; mdb.RE/0.9
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9918
Issue ID: 9918
Summary: Can't log on git.openldap.org
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: mh-bcrayqnc(a)glandium.org
Target Milestone: ---
Followup for https://github.com/LMDB/lmdb/pull/23#issuecomment-1254532527.
I created the account in February, apparently, with login glandium, but I'm not
sure what email. Presumably the one from this bugzilla account.
--
You are receiving this mail because:
You are on the CC list for the issue.