https://bugs.openldap.org/show_bug.cgi?id=9000
--- Comment #7 from sebastien.chaumat(a)qspin.be ---
This bug is still present in 2.4.49 (ubuntu).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8375
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|2.6.2 |2.7.0
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8255
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9792
Issue ID: 9792
Summary: During replication, slapd tries to modify
hasSubordinates (and fails)
Product: OpenLDAP
Version: 2.5.9
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: christophe(a)armaghast.eu
Target Milestone: ---
During relication, this strange error occurs:
Jan 25 14:46:42 annu slapd[471040]: conn=1001 op=2796 MOD attr=userPassword
pwdChangedTime pwdHistory entryCSN modifiersName modifyTimestamp
hasSubordinates
Jan 25 14:46:42 annu slapd[471040]: conn=1001 op=2796 RESULT tag=103 err=16
qtime=0.000030 etime=0.000462 text=modify/delete: hasSubordinates: no such
attribute
Why does slapd try to modify this (virtual) attribute ?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9350
Issue ID: 9350
Summary: Expand test suite for null base
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Currently we have no tests that use the empty suffix (null base).
This is an entirely valid configuration setup, and there are unique challenges
and bugs that crop up with this usage.
We need to ensure we're covering this use case, particularly with syncrepl and
delta-syncrepl configurations.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8255
OndÅ™ej KuznÃk <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |IN_PROGRESS
Ever confirmed|0 |1
--- Comment #10 from OndÅ™ej KuznÃk <ondra(a)mistotebe.net> ---
https://git.openldap.org/openldap/openldap/-/merge_requests/487 for the
clarification.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8255
--- Comment #9 from OndÅ™ej KuznÃk <ondra(a)mistotebe.net> ---
(In reply to OndÅ™ej KuznÃk from comment #8)
> and probably need to stop referencing the slapd-shell manpage too.
Ah, we already did that, forgot I was reading the installed, not the local
manpage.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8255
OndÅ™ej KuznÃk <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|backends |documentation
--- Comment #8 from OndÅ™ej KuznÃk <ondra(a)mistotebe.net> ---
(In reply to Howard Chu from comment #7)
> (In reply to OndÅ™ej KuznÃk from comment #6)
>> str2result() doesn't expect "msgid:" to be passed in the response, even
>> though that's part of the protocol as documented.
>
> Incorrect. The docs clearly show msgid: is not part of the response message.
True, I misread the manpage because there is little structure in there to
support quick reference.
I think we should put the "sockresp result" string in the relevant paragraph
and probably need to stop referencing the slapd-shell manpage too.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8255
--- Comment #7 from Howard Chu <hyc(a)openldap.org> ---
(In reply to OndÅ™ej KuznÃk from comment #6)
> str2result() doesn't expect "msgid:" to be passed in the response, even
> though that's part of the protocol as documented.
Incorrect. The docs clearly show msgid: is not part of the response message.
>>>>
The commands - except unbind - should output:
RESULT
code: <integer>
matched: <matched DN>
info: <text>
where only RESULT is mandatory, and then close the socket.
<<<<
The msgid: is only included in messages from back-sock to the external program.
There is no bug in back-sock or in its documentation.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8255
--- Comment #6 from OndÅ™ej KuznÃk <ondra(a)mistotebe.net> ---
str2result() doesn't expect "msgid:" to be passed in the response, even though
that's part of the protocol as documented. Now that back-sock is its only user,
it should just be added.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9793
Issue ID: 9793
Summary: Question regarding password dictionary rules for when
a user changes their password.
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: alan_andrea(a)yahoo.com
Target Milestone: ---
I have a question regarding password rules that are enforced when a user
changes their password. We have a need to implement a dictionary rule whereby
words and phrases in a dictionary are not allowed in a users password. I am
not able to see currently where such functionality exists in OpenLDAP and am
wondering if there are any extensions to OPenLDAP that were developed to
support this or if it would be required to write code to support this feature.
If you can please give me some guidelines here, that would be really great !
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9742
Issue ID: 9742
Summary: syncprov-nopresent is harmful
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If setting up a new delta-MPR environment such that:
- server A has been slapadd-ed the seed data
- accesslog is set to "logops all"
There is a sequence of events where servers are started and replicate from each
other before they get a chance to talk to A, they will each generate a CSN and
replicate it. Once they start talking to A, it will see that it has a CSN (its
own) that none of them have sent and "syncprov-nopresent" makes it just go
ahead where the only sane outcome is to send SYNC_REFRESH_REQUIRED.
Am I missing a usecase for this or should it just have been this way all along?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9750
Issue ID: 9750
Summary: global vs. frontend config in slapd.conf - misleading
warning message
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Since the fix for ITS#9575 there is this misleading message even when invoking
slapcat:
/opt/openldap-ms/etc/openldap/slapd.conf: line 126: setting password scheme in
the global entry is deprecated. The server may refuse to start if it is
provided by a loadable module, please move it to the frontend database instead
There is currently no way to rearrange something in slapd.conf to make this
confusing message go away.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9738
Issue ID: 9738
Summary: entry_schema_check: Assertion `a->a_vals[0].bv_val !=
NULL' failed.
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
slapd 2.6.0 exits when an LDAP client sends an add operation with invalid data:
2021-11-04T22:07:36.790594+01:00 itn-dir-1 slapd[32415]: 61844b98.2ef8df5c
0x7fe42d9a6700 Entry (mail=michael(a)stroeder.com,ou=ext,ou=metadir,o=itn):
object class 'itnmetaPerson' requires attribute 'displayName'
2021-11-04T22:07:36.790694+01:00 itn-dir-1 slapd[32415]: slapd:
schema_check.c:89: entry_schema_check: Assertion `a->a_vals[0].bv_val != NULL'
failed.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9730
Issue ID: 9730
Summary: logfile-rotate directive fails in 2.6.0
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: david.coutadeur(a)gmail.com
Target Milestone: ---
Hello,
When setting the logfile-rotate, I get:
617bc9ae.1b73de17 0x7f44f87c9740 /usr/local/openldap/etc/openldap/slapd.conf:
line 12 (logfile-rotate 10 100 24)
617bc9ae.1b759154 0x7f44f87c9740 /usr/local/openldap/etc/openldap/slapd.conf:
line 12: <logfile-rotate> handler exited with 16384!
My configuration file is below. I am using the 2.6.0 release.
The strange part is that the same configuration converted into cn=config seems
to work well.
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/openldap/etc/openldap/schema/core.schema
include /usr/local/openldap/etc/openldap/schema/cosine.schema
include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema
include /usr/local/openldap/etc/openldap/schema/dyngroup.schema
logfile-rotate 10 100 24
logfile /var/log/slapd-ltb/slapd.log
logLevel 256
sasl-host ldap.my-domain.com
pidfile /usr/local/openldap/var/run/slapd.pid
argsfile /usr/local/openldap/var/run/slapd.args
# Load dynamic backend modules:
# moduleload back_ldap.la
modulepath /usr/local/openldap/libexec/openldap
moduleload argon2.la
moduleload back_mdb.la
moduleload dynlist.la
moduleload memberof.la
moduleload ppolicy.la
moduleload syncprov.la
moduleload unique.la
access to dn.base="" by * read
access to dn.base="cn=subschema" by * read
#######################################################################
# config database definitions
#######################################################################
database config
rootdn cn=config
rootpw secret
access to attrs="userPassword"
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth =wdx
by * auth
access to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage
#######################################################################
# MDB database definitions
#######################################################################
database mdb
maxsize 4294967296
suffix dc=my-domain,dc=com
rootdn cn=Manager,dc=my-domain,dc=com
rootpw secret
directory /usr/local/openldap/var/openldap-data
index objectClass eq
index cn eq,sub
index uid pres,eq
index givenName pres,eq,sub
index l pres,eq
index employeeType pres,eq
index mail pres,eq,sub
index sn pres,eq,sub
limits group="cn=admin,ou=groups,dc=my-domain,dc=com" size=unlimited
time=unlimited
access to attrs="userPassword"
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth =wdx
by group.exact="cn=admin,ou=groups,dc=my-domain,dc=com" =wdx
by self =wdx
by * auth
access to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage
by group.exact="cn=admin,ou=groups,dc=my-domain,dc=com" write
by users read
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9725
Issue ID: 9725
Summary: attribute olcLastBindPrecision redefined in
slapo-lastbind
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
An attribute type description for 'olcLastBindPrecision' is present in
servers/slapd/bconfig.c and contrib/slapd-modules/lastbind/lastbind.c.
Thus the migration of deployments using slapo-lastbind is not as smooth as it
should be. With release 2.6.0 one is forced to disable slapo-lastbind.
Removing the attribute type description for 'olcLastBindPrecision' from
contrib/slapd-modules/lastbind/lastbind.c should work.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9647
Issue ID: 9647
Summary: Glue entry creation doesn't replicate properly
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
In plain syncrepl, when an entry is turned into glue (to remove it when it
still has children), it won't replicate correctly to its consumers - a
NEW_COOKIE intermediate message is sent instead.
Scenario:
- 4 servers (A, B, C, D) and a tree with two entries - cn=parent,cn=suffix and
its parent, the database suffix
- D replicates from C, C replicates from A and B, no other links set up for
this
Now:
1. add an entry "cn=child,cn=parent,cn=suffix" on A
2. remove "cn=parent,cn=suffix" from B
As things settle, cn=parent,cn=suffix is retained on D while being deleted from
C.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9758
Issue ID: 9758
Summary: slapd-sock cn=config issues
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
This module has multiple issues with cn=config processing:
- empty/missing sockdnpat can trigger an assert
- adding multiple olcDbSocketExtensions/olcOvSocketOps/olcOvSocketResps does
not work as expected, deletes are also broken
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9740
Issue ID: 9740
Summary: olcPPolicyCheckModule not working in 2.6.0
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: david.coutadeur(a)gmail.com
Target Milestone: ---
Following: https://bugs.openldap.org/show_bug.cgi?id=9666, we must now use the
olcPPolicyCheckModule directive in the overlay configuration, instead of the
pwdCheckModule in the password policy.
I have 3 remarks:
1/ it's a pity we can't define the chosen module in the corresponding ppolicy.
It prevents having multiple extension to password policies (one for each
policy)
2/ it does not seem to work. (ie the extended module is not launched). See
below for my config and data.
3/ the slapo-ppolicy is quite unclear about the configuration. For example, I
can read:
( 1.3.6.1.4.1.4754.2.99.1
NAME 'pwdPolicyChecker'
AUXILIARY
SUP top
MAY ( pwdCheckModule $ pwdCheckModuleArg $ pwdUseCheckModule ) )
Does pwdCheckModule and pwdUseCheckModule still have sense?
Here is my configuration:
dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {0}ppolicy
olcPPolicyDefault: cn=default,ou=ppolicies,dc=my-domain,dc=com
olcPPolicyHashCleartext: TRUE
olcPPolicyUseLockout: FALSE
olcPPolicyForwardUpdates: FALSE
olcPPolicyDisableWrite: FALSE
olcPPolicySendNetscapeControls: FALSE
olcPPolicyCheckModule: /usr/local/openldap/libexec/openldap/ppm.so
Here are my data:
dn: cn=default,ou=ppolicies,dc=my-domain,dc=com
objectClass: pwdPolicy
objectClass: pwdPolicyChecker
objectClass: organizationalRole
cn: default
pwdAttribute: userPassword
pwdCheckQuality: 2
pwdMaxAge: 7776000
pwdInHistory: 5
pwdLockout: TRUE
pwdMaxFailure: 5
pwdFailureCountInterval: 86400
pwdMinLength: 8
pwdMaxLength: 30
pwdExpireWarning: 432000
pwdMustChange: TRUE
pwdAllowUserChange: TRUE
pwdMaxIdle: 31536000
pwdCheckModuleArg:
bWluUXVhbGl0eSAzCmNoZWNrUkROIDAKZm9yYmlkZGVuQ2hhcnMKbWF4Q29uc2VjdXRpdmVQZXJDbGFzcyAwCnVzZUNyYWNrbGliIDAKY3JhY2tsaWJEaWN0IC92YXIvY2FjaGUvY3JhY2tsaWIvY3JhY2tsaWJfZGljdApjbGFzcy11cHBlckNhc2UgQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVogMCAxCmNsYXNzLWxvd2VyQ2FzZSBhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5eiAwIDEKY2xhc3MtZGlnaXQgMDEyMzQ1Njc4OSAwIDEKY2xhc3Mtc3BlY2lhbCA8Piw/Oy46LyHCp8O5JSrCtV7CqCTCo8KyJsOpfiIjJ3soWy18w6hgX1zDp17DoEApXcKwPX0rIDAgMQ==
dn: uid=jack.oneill,ou=people,dc=my-domain,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: Jack O Neill
givenName: Jack
mail: jack.oneill(a)my-example.com
sn: O Neill
uid: jack.oneill
userPassword:
{ARGON2}$argon2id$v=19$m=65536,t=2,p=1$LiSaGIqce9o2C6T8d2BOfg$BpPpokTfKY9/X7/jkvG1SXBcsNnm95UbTGSstc2aHKk
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9743
Issue ID: 9743
Summary: LDAP_OPT_SOCKET_BIND_ADDRESSES - sin_port is not
initialized
Product: OpenLDAP
Version: 2.5.6
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: dg0319q(a)gmail.com
Target Milestone: ---
When LDAP_OPT_SOCKET_BIND_ADDRESSES is set, and ldap_search_s is being called,
valgrind detects uninitialised value (ip4addr.sin_port).
Valgrind log:
=52721== Syscall param socketcall.bind(my_addr.sin_port) points to
uninitialised byte(s)
==52721== at 0x54C7F2B: bind (syscall-template.S:120)
==52721== by 0x52434A5: ldap_connect_to_host (in
/usr/lib/x86_64-linux-gnu/libldap-2.5.so.0.1.1)
==52721== by 0x52352CD: ldap_int_open_connection (in
/usr/lib/x86_64-linux-gnu/libldap-2.5.so.0.1.1)
==52721== by 0x524875B: ldap_new_connection (in
/usr/lib/x86_64-linux-gnu/libldap-2.5.so.0.1.1)
==52721== by 0x523494D: ldap_open_defconn (in
/usr/lib/x86_64-linux-gnu/libldap-2.5.so.0.1.1)
==52721== by 0x52493F7: ldap_send_initial_request (in
/usr/lib/x86_64-linux-gnu/libldap-2.5.so.0.1.1)
==52721== by 0x52387E7: ldap_search (in
/usr/lib/x86_64-linux-gnu/libldap-2.5.so.0.1.1)
==52721== by 0x52388AD: ldap_search_s (in
/usr/lib/x86_64-linux-gnu/libldap-2.5.so.0.1.1)
==52721== by 0x28565F: check_ldap (simple.c:83)
==52721== Address 0x1ffeff6122 is on thread 1's stack
==52721== in frame #1, created by ldap_connect_to_host (???:)
==52721== Uninitialised value was created by a stack allocation
==52721== at 0x5242DE0: ldap_connect_to_host (in
/usr/lib/x86_64-linux-gnu/libldap-2.5.so.0.1.1)
Looks like, the ip4addr.sin_port should be set to 0 in ldap_connect_to_host. It
works, but it looks like it is a bug, and may fail under other circumstances.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9728
Issue ID: 9728
Summary: For lastbind-precision, note it is important in busy
replicated environments
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
It would be good to note in the slapd.conf(5)/slapd-config(5) man pages that
the lastbind-precision setting can be very important to set in busy, replicated
environments.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9727
Issue ID: 9727
Summary: slapd-watcher fails to start if any slapd instance is
down
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: gnoe(a)symas.com
Target Milestone: ---
When starting slapd-watcher and slapd isn't running on one of the monitored
servers, slapd-watcher fails to start:
Example w/host2 slapd not running:
[user@host]# slapd-watcher -xD dc=example,dc=com -w secret -b
dc=example,dc=com -s 1,2 ldap://host1/ ldap://host2/
slapd-watcher PID=11892: ldap_sasl_bind_s: Can't contact LDAP server (-1)
I would expect that slapd-watcher would start up completely and indicate the
host was down, like in the case where a host goes down while slapd-watcher is
running. This would allow slapd-watcher to start when one or more replication
node is down for maintenance.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9733
Issue ID: 9733
Summary: ppolicy.c:66:2: error: unknown type name ‘lt_dlhandle’
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: smillerdev(a)me.com
Target Milestone: ---
On both Linux and macOS in Homebrew, there is a failure trying to compile
OpenLDAP 2.6.0:
/bin/sh ../../../libtool --tag=disable-shared --mode=compile gcc-5 -g -O2
-I../../../include -I../../../include -I.. -I./.. -I./../slapi -c log.c
ppolicy.c:66:2: error: unknown type name ‘lt_dlhandle’
lt_dlhandle pwdCheckHandle; /* handle from lt_dlopen */
^
on macOS there is also an additional errror:
ppolicy.c:458:4: error: initializer element is not a compile-time constant
(void *)offsetof(pp_info,hash_passwords),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
See https://github.com/Homebrew/homebrew-core/pull/88036 for the full output
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9691
Issue ID: 9691
Summary: Allow syncrepl persist sessions against empty DBs
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review, replication
Severity: enhancement
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
One way to set up an environment is to start with a completely empty DB,
configure all nodes and replication paths and then populate them.
Right now, the syncrepl sessions get rejected with a 32 NO_SUCH_OBJECT,
triggering the retry cascade. Both the consumer and provider have an empty
cookie, so they are in sync and we could actually transition to a persist phase
and let the session proceed.
This way the environment would start replicating almost immediately after first
entries are added. Mind that ITS#9584 still pushes concurrent refreshes into
the retry logic adding a short delay before *all* configured links are set up.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9776
Issue ID: 9776
Summary: Deleting syncrepl config does not close the connection
to the provider
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: tero.saarni(a)est.tech
Target Milestone: ---
I have set up replication between two slapd instances and it works OK.
When I remove olcSyncRepl from the consumer, it seems that the connection to
provider is never closed. I have observed this with lsof -p $(pidof slapd).
When using Monitor it can be also observed (from
cn=Tasklist,cn=Threads,cn=Monitor) that the do_syncrepl task is not removed
when deleting olcSyncRepl.
If repeatedly deleting and adding olcSyncRepl it can be observed that the
number of connections and tasks increases continuously. At some point, around
adding/deleting 1000 times, the modify operation will fail:
ldap_modify: Other (e.g., implementation specific) error (80)
slapd logs have error
61d574b9.1ff5d9a7 0x7fcfddfdc700 ldif_read_file: Too many open files for
"/home/tsaarni/work/openldap/tests/testrun/slapd.1.d/cn=config/olcDatabase={1}mdb.ldif"
61d574b9.1ff64149 0x7fcfddfdc700 send_ldap_result: conn=3034 op=1 p=3
61d574b9.1ff679b8 0x7fcfddfdc700 send_ldap_result: err=80 matched=""
text="internal error (cannot read some entry file)"
61d574b9.1ff70008 0x7fcfddfdc700 send_ldap_result: conn=3034 op=1 p=3
Number of established connections to provider 1011
$ lsof -p 4101355 | grep "localhost:9012 (ESTABLISHED)" | wc -l
1011
Number of do_syncrepl tasks is also 1011
$ ldapsearch -LLL -x -D cn=config -wsecret -b cn=Tasklist,cn=Threads,cn=Monitor
-H ldap://localhost:9011/ monitoredInfo
...
monitoredInfo: {1008}do_syncrepl(rid=002)
monitoredInfo: {1009}do_syncrepl(rid=002)
monitoredInfo: {1010}do_syncrepl(rid=002)
Maximum number of file handles for the process was 1024.
I'm using openldap master branch.
I have a test case for reproducing the problem, which I will add to this issue.
--
You are receiving this mail because:
You are on the CC list for the issue.