[Issue 9728] New: For lastbind-precision, note it is important in busy replicated environments
by openldap-its＠openldap.org
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.
5 months, 2 weeks
[Issue 9727] New: slapd-watcher fails to start if any slapd instance is down
by openldap-its＠openldap.org
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.
5 months, 2 weeks
[Issue 9733] New: ppolicy.c:66:2: error: unknown type name ‘lt_dlhandle’
by openldap-its＠openldap.org
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.
5 months, 2 weeks
[Issue 9718] New: test022 can fail on expiry
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9718
Issue ID: 9718
Summary: test022 can fail on expiry
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
>>>>> Starting test022-ppolicy for mdb...
running defines.sh
Starting slapd on TCP/IP port 9011...
Using ldapsearch to check that slapd is running...
Testing redundant ppolicy instance...
Using ldapadd to populate the database...
Testing account lockout...
Waiting 13 seconds for lockout to reset...
Testing password expiration
Waiting seconds for password to expire...
sleep: missing operand
Try 'sleep --help' for more information.
Password expiration test failed
>>>>> test022-ppolicy failed for mdb after 43 seconds
(exit 1)
The issue here is apparently that line 122-123 failed to populate the DELAY
variable.
121
122 DELAY=`$LDAPSEARCH -D "$MANAGERDN" -H $URI1 -w $PASSWD \
123 -b "$USER" -E accountUsability 1.1 | sed -n -e
's/.*expire=\(\d*\)/\1/p'`
124
125 echo "Testing password expiration"
126 echo "Waiting $DELAY seconds for password to expire..."
127 sleep $DELAY
128 sleep 1
--
You are receiving this mail because:
You are on the CC list for the issue.
5 months, 2 weeks
[Issue 9691] New: Allow syncrepl persist sessions against empty DBs
by openldap-its＠openldap.org
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.
5 months, 2 weeks
[Issue 9776] New: Deleting syncrepl config does not close the connection to the provider
by openldap-its＠openldap.org
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.
5 months, 2 weeks
[Issue 9772] New: replication of cn=config for olcDatabase={2}mdb,cn=config not working
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9772
Issue ID: 9772
Summary: replication of cn=config for
olcDatabase={2}mdb,cn=config not working
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: stefan(a)kania-online.de
Target Milestone: ---
My setup is a mmr for cn=config. The configuration of all servers is:
---------------
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcSyncRepl
olcSyncRepl: rid=1
provider=ldap://ldap01.example.net
binddn="cn=admin,cn=config"
bindmethod=simple
credentials=secret
searchbase="cn=config"
type=refreshAndPersist
retry="5 5 300 20"
timeout=1
starttls=yes
tls_reqcert=allow
olcSyncRepl: rid=2
provider=ldap://ldap02.example.net
binddn="cn=admin,cn=config"
bindmethod=simple
credentials=secret
searchbase="cn=config"
type=refreshAndPersist
retry="5 5 300 20"
timeout=1
starttls=yes
tls_reqcert=allow
olcSyncRepl: rid=3
provider=ldap://ldap03.example.net
binddn="cn=admin,cn=config"
bindmethod=simple
credentials=secret
searchbase="cn=config"
type=refreshAndPersist
retry="5 5 300 20"
timeout=1
starttls=yes
tls_reqcert=allow
olcSyncRepl: rid=4
provider=ldap://ldap04.example.net
binddn="cn=admin,cn=config"
bindmethod=simple
credentials=secret
searchbase="cn=config"
type=refreshAndPersist
retry="5 5 300 20"
timeout=1
starttls=yes
tls_reqcert=allow
-
add: olcMultiprovider
olcMultiprovider: TRUE
-------------
Replication is working for dn: olcDatabase={-1}frontend,cn=config
but not for the configuration of the main DB dn: olcDatabase={2}mdb,cn=config
When I do a change I got the following messages:
-----------------
messages on provider
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 fd=18 ACCEPT from
IP=192.168.56.46:57844 (IP=0.0.0.0:389)
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=0 STARTTLS
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=0 RESULT oid= err=0
qtime=0.000023 etime=0.000176 text=
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 fd=18 TLS established tls_ssf=256
ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=1 BIND dn="cn=admin,cn=config"
method=128
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=1 BIND dn="cn=admin,cn=config"
mech=SIMPLE bind_ssf=0 ssf=256
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=1 RESULT tag=97 err=0
qtime=0.000027 etime=0.020422 text=
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 SRCH base="cn=config"
scope=2 deref=0 filter="(objectClass=*)"
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 SRCH attr=* +
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 syncprov_op_search: got a
persistent search with a
cookie=rid=004,sid=002,csn=20211215092402.061636Z#000000#002#000000
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 syncprov_findbase: searching
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 syncprov_op_search:
registered persistent search
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 syncprov_op_search: consumer
cookie is missing a csn we track
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 syncprov_search_response:
cookie=rid=004,sid=004,csn=20211215092401.968707Z#000000#001#000000;20211215092402.061636Z#000000#002#000000;20211215092402.073013Z#000000#003#000000;20211215092402.084067Z#000000#004#000000
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 syncprov_sendinfo:
refreshPresent
cookie=rid=004,sid=004,csn=20211215092401.968707Z#000000#001#000000;20211215092402.061636Z#000000#002#000000;20211215092402.073013Z#000000#003#000000;20211215092402.084067Z#000000#004#000000
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=2 syncprov_search_response:
detaching op
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 op=3 UNBIND
Dez 15 10:37:56 ldap04 slapd[6319]: conn=1013 fd=18 closed
messages on consumer
Dez 15 10:37:56 ldap02 slapd[6271]: do_syncrep1: rid=004 starting refresh
(sending cookie=rid=004,sid=002,csn=20211215092402.061636Z#000000#002#000000)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN:
cn=config, UUID: 5d4870f0-f1d0-103b-92fc-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID
5d4870f0-f1d0-103b-92fc-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN
cn=config 20211215085439.318447Z#000000#004#000000
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 cn=config
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged,
ignored (cn=config)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN:
cn=module{0},cn=config, UUID: 5d487b22-f1d0-103b-92fe-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID
5d487b22-f1d0-103b-92fe-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN
cn=module{0},cn=config 20211215085432.145148Z#000000#000#000000
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
cn=module{0},cn=config
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged,
ignored (cn=module{0},cn=config)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN:
cn=schema,cn=config, UUID: 5d4877bc-f1d0-103b-92fd-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID
5d4877bc-f1d0-103b-92fd-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 cn=schema,cn=config
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_add
cn=schema,cn=config (0)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN:
cn={0}core,cn=schema,cn=config, UUID: 5d48abc4-f1d0-103b-92ff-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID
5d48abc4-f1d0-103b-92ff-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN
cn={0}core,cn=schema,cn=config 20211215085432.146392Z#000000#000#000000
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
cn={0}core,cn=schema,cn=config
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged,
ignored (cn={0}core,cn=schema,cn=config)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN:
cn={1}cosine,cn=schema,cn=config, UUID: 5d48c23a-f1d0-103b-9300-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID
5d48c23a-f1d0-103b-9300-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN
cn={1}cosine,cn=schema,cn=config 20211215085432.146967Z#000000#000#000000
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
cn={1}cosine,cn=schema,cn=config
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged,
ignored (cn={1}cosine,cn=schema,cn=config)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN:
cn={2}nis,cn=schema,cn=config, UUID: 5d48d1b2-f1d0-103b-9301-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID
5d48d1b2-f1d0-103b-9301-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN
cn={2}nis,cn=schema,cn=config 20211215085432.147363Z#000000#000#000000
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
cn={2}nis,cn=schema,cn=config
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged,
ignored (cn={2}nis,cn=schema,cn=config)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN:
cn={3}inetorgperson,cn=schema,cn=config, UUID:
5d48dbc6-f1d0-103b-9302-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID
5d48dbc6-f1d0-103b-9302-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN
cn={3}inetorgperson,cn=schema,cn=config
20211215085432.147621Z#000000#000#000000
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
cn={3}inetorgperson,cn=schema,cn=config
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged,
ignored (cn={3}inetorgperson,cn=schema,cn=config)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN:
cn={4}dyngroup,cn=schema,cn=config, UUID: 5d48e152-f1d0-103b-9303-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID
5d48e152-f1d0-103b-9303-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN
cn={4}dyngroup,cn=schema,cn=config 20211215085432.147763Z#000000#000#000000
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
cn={4}dyngroup,cn=schema,cn=config
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged,
ignored (cn={4}dyngroup,cn=schema,cn=config)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN:
cn={5}kerberos,cn=schema,cn=config, UUID: 5d48e79c-f1d0-103b-9304-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID
5d48e79c-f1d0-103b-9304-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN
cn={5}kerberos,cn=schema,cn=config 20211215085432.147924Z#000000#000#000000
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
cn={5}kerberos,cn=schema,cn=config
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged,
ignored (cn={5}kerberos,cn=schema,cn=config)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN:
olcDatabase={-1}frontend,cn=config, UUID: 5d48f458-f1d0-103b-9305-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID
5d48f458-f1d0-103b-9305-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN
olcDatabase={-1}frontend,cn=config 20211215085432.148251Z#000000#000#000000
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
olcDatabase={-1}frontend,cn=config
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged,
ignored (olcDatabase={-1}frontend,cn=config)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN:
olcDatabase={0}config,cn=config, UUID: 5d48f7aa-f1d0-103b-9306-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID
5d48f7aa-f1d0-103b-9306-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN
olcDatabase={0}config,cn=config 20211215092402.084067Z#000000#004#000000
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
olcDatabase={0}config,cn=config
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged,
ignored (olcDatabase={0}config,cn=config)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN:
olcOverlay={0}syncprov,olcDatabase={0}config,cn=config, UUID:
7c3fa65a-f1d4-103b-983d-81584f1425b7
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID
7c3fa65a-f1d4-103b-983d-81584f1425b7
Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN
olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
20211215092402.083542Z#000000#004#000000
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged,
ignored (olcOverlay={0}syncprov,olcDatabase={0}config,cn=config)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN:
olcDatabase={1}monitor,cn=config, UUID: 5d48fa48-f1d0-103b-9307-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID
5d48fa48-f1d0-103b-9307-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: dn_callback : entries have identical CSN
olcDatabase={1}monitor,cn=config 20211215085432.148402Z#000000#000#000000
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
olcDatabase={1}monitor,cn=config
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 entry unchanged,
ignored (olcDatabase={1}monitor,cn=config)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_message_to_entry: rid=004 DN:
olcDatabase={2}mdb,cn=config, UUID: 5d48fd0e-f1d0-103b-9308-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f0589699700
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 inserted UUID
5d48fd0e-f1d0-103b-9308-1b7679847168
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_search (0)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004
olcDatabase={2}mdb,cn=config
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_add
olcDatabase={2}mdb,cn=config (68)
Dez 15 10:37:56 ldap02 slapd[6271]: conn=-1 op=0 syncprov_matchops: recording
uuid for dn=olcDatabase={2}mdb,cn=config on opc=0x7ef1740062c0
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_null_callback : error code 0x35
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_modify
olcDatabase={2}mdb,cn=config (53)
Dez 15 10:37:56 ldap02 slapd[6271]: syncrepl_entry: rid=004 be_modify failed
(53)
Dez 15 10:37:56 ldap02 slapd[6271]: do_syncrepl: rid=004 rc 53 retrying (18
retries left)
-----------------
A change with ldapmodify is only changing the cn=config on the server I did the
ldapmodify. All other servers do not see anything, no message in the log.
All systems are Debian 11 with symas packages 2.6.0-5.
--
You are receiving this mail because:
You are on the CC list for the issue.
5 months, 2 weeks
[Issue 9761] New: Inserting olcSyncrepl into a given index inserts at the end
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9761
Issue ID: 9761
Summary: Inserting olcSyncrepl into a given index inserts at
the end
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: ---
olcSyncrepl is marked "X-ORDERED 'VALUES'" but add_syncrepl() always adds the
new value at the end of the list. This breaks value deletes.
--
You are receiving this mail because:
You are on the CC list for the issue.
5 months, 2 weeks
[Issue 9751] New: Delta-MPR resolution too eager to drop attribute deletes
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9751
Issue ID: 9751
Summary: Delta-MPR resolution too eager to drop attribute
deletes
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review, replication
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
syncrepl_resolve_cb will completely drop an attribute delete (or the delete
part of replace) if there's a "newer" (timestamp-wise) op touching the same
attribute.
This way servers processing the "out of order" write end up keeping values that
should have been removed (and have been on those that received it in the
natural order).
--
You are receiving this mail because:
You are on the CC list for the issue.
5 months, 2 weeks
[Issue 9779] New: dynlist Negation filter on memberOf attribute doesn't work
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9779
Issue ID: 9779
Summary: dynlist Negation filter on memberOf attribute doesn't
work
Product: OpenLDAP
Version: 2.5.5
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: mail(a)andrejro.de
Target Milestone: ---
Setup is according to documentation of slapo-dynlist to replace the old
memberOf overlay, which I only want to use for mapping static groupOfNames back
on memberOf= attributes of members.
dynlist-attrset groupOfNames labeledURI member+memberOf@groupOfNames
If I now have:
dn: cn=test,ou=Group,dc=example,dc=com
objectClass: groupOfNames
objectClass: top
cn: test
member: uid=test,ou=People,dc=example,dc=com
dn: uid=test,ou=People,dc=example,dc=com
objectClass: account
objectClass: top
cn: Test User
uid: test
dn: uid=test2,ou=People,dc=example,dc=com
objectClass: account
objectClass: top
cn: Test2 User
uid: test2
I expect for a search filter '(memberOf=cn=test,ou=Group,dc=example,dc=com)' to
return dn: "uid=test,ou=People,dc=example,dc=com" and for a search filter
'(!(memberOf=cn=test,ou=Group,dc=eample,dc=com)' to return dn:
"uid=test2,ou=People,dc=example,dc=com"
First operation with a positive search filter works, but I cannot get the
second case to work, even when requesting the memberOf attribute explictly as
return attribute.
--
You are receiving this mail because:
You are on the CC list for the issue.
5 months, 2 weeks