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=9707
Issue ID: 9707
Summary: Documentation synchronisation ODSEE --> openldap
Product: OpenLDAP
Version: 2.5.4
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: laurent.revillion(a)icloud.com
Target Milestone: ---
There is no documentation about the synchronisation between ODSEE and Openldap
2.5.
Will there be one?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9538
Issue ID: 9538
Summary: Accesslog entryCSN ordering is not always monotonous
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
For delta-sync replication, we rely on CSN order being preserved at all times.
When logops includes anything more than "writes", we don't use li_op_rmutex to
maintain serialisation. A concurrent write and another operation (like bind)
can have the write have its csn assigned before the bind. But before the write
finishes on the main DB and is logged, the bind has already hit accesslog.
This entry out of order doesn't match the usual filter, so non-persist sessions
will not notice, however running persist sessions could get a new cookie sent,
depending on how things are ordered when they hit syncprov.
A sample:
---- 8< ----
Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 ADD
dn="uid=dm01-R1H2-41660,ou=People,dc=example,dc=com"
Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 syncprov_matchops:
recording uuid for dn=reqStart=20210426195604.000350Z,cn=accesslog on
opc=0x7d3d2800dc50
Apr 26 19:56:04 localhost slapd[43930]: slap_get_csn: conn=1003 op=42 generated
new csn=20210426195604.556053Z#000000#002#000000 manage=1
Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x7d3d38148f60
20210426195604.556053Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 BIND
dn="dc=example,dc=com" method=128
Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 BIND
dn="dc=example,dc=com" mech=SIMPLE bind_ssf=0 ssf=256
Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 RESULT tag=105 err=0
qtime=0.005874 etime=0.015182 text=
Apr 26 19:56:04 localhost slapd[43930]: slap_get_csn: conn=1005 op=1 generated
new csn=20210426195604.558683Z#000000#002#000000 manage=1
Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x561f09113f80
20210426195604.558683Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 syncprov_matchops:
recording uuid for dn=reqStart=20210426195604.000364Z,cn=accesslog on
opc=0x561f0900fcf0
Apr 26 19:56:04 localhost slapd[43930]: conn=1002 op=2 syncprov_qresp: set up a
new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: conn=1001 op=2 syncprov_qresp: set up a
new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: conn=1000 op=2 syncprov_qresp: set up a
new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing
0x561f09113f80 20210426195604.558683Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 RESULT tag=97 err=0
qtime=0.000020 etime=0.004297 text=
Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x7d3d38148250
20210426195604.556053Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing
0x7d3d38148250 20210426195604.556053Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing
0x7d3d38148f60 20210426195604.556053Z#000000#002#000000
---- 8< ----
Example entries in the order slapcat sees them:
---- 8< ----
dn: reqStart=20210426195604.000364Z,cn=accesslog
objectClass: auditBind
reqStart: 20210426195604.000364Z
reqEnd: 20210426195604.000365Z
reqType: bind
entryCSN: 20210426195604.558683Z#000000#002#000000
dn: reqStart=20210426195604.000351Z,cn=accesslog
objectClass: auditAdd
reqStart: 20210426195604.000351Z
reqEnd: 20210426195604.000366Z
reqType: add
entryCSN: 20210426195604.556053Z#000000#002#000000
---- 8< ----
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9576
Issue ID: 9576
Summary: Add ConfigTable link into ConfigArgs
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: enhancement
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Would make it possible to examine defaults if necessary.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9282
Issue ID: 9282
Summary: Syncrepl re-creates deleted entry
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Scenario:
2 node Multi-provider replication
Add database to provider A
ensure database replicates to provider B
Stop provider A
delete entry on provider B
Start provider A
Wait for provider B to reconnect to provider A
Deleted entry re-appears
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9732
Issue ID: 9732
Summary: OpenLDAP TLS ciphersuite and groups limit issue
Product: OpenLDAP
Version: 2.4.54
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: narayananballem(a)gmail.com
Target Milestone: ---
Hi Team,
Hope you can help with this issue.
I am trying to disable SSLV3 on OpenLDAP servers we are using OpenLDAP as a
proxy with upstream Active directory servers. we are using CA certs on this
openssl we would like to disable SSLV3
I added the below entry slapd.conf but when I tried to start slapd it's failing
to start
TLSCipherSuite HIGH:MEDIUM:!SSLv2:!SSLV3
errors as below
slapd[19899]: main: TLS init def ctx failed: -1
slapd[19899]: slapd stopped.
slapd[19899]: connections_destroy: nothing to destroy.
debug logs restart as below
TLS: could not set cipher list HIGH:MEDIUM:!SSLv2:!SSLV3.
617c64c1 main: TLS init def ctx failed: -1
617c64c1 slapd stopped.
Also, did anybody notice this issue?
I am facing the issue with a group display we have several users in group while
looking for groups in getent group we are seeing a few groups not sure if there
is any limit on group filed in Database
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9002
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=8226
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8226
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=9002
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9715
Issue ID: 9715
Summary: Consolidate code for loglevel/logfile for better
shared usage between slapd and lloadd
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
In a future release, consolidate logging code, loglevel bits to be better
shared between slapd and stand-alone lloadd.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9723
Issue ID: 9723
Summary: C_EOF not reset in mdb_cursor_get with MDB_FIRST_DUP
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: stephan.j.bircher(a)gmail.com
Target Milestone: ---
I'm on the master branch of lmdb.
Steps to reproduce
// search for an non-existent key
rc = mdb_cursor_get(cursor, &key, &val, MDB_SET_RANGE);
if (rc == MDB_NOTFOUND) {
// C_EOF is not set on the cursor flags
// go to the last.
// C_EOF remains set which is ok
mdb_cursor_get(mdbCursor, &key, &val, MDB_LAST);
// go to the first dup of the last
// C_EOF remains set which is NOT OK
mdb_cursor_get(mdbCursor, &key, &val, MDB_FIRST_DUP);
// return MDB_NOTFOUND in any case whether there are duplicates or not
// because C_EOF was not cleared
mdb_cursor_get(mdbCursor, &key, &val, MDB_NEXT_NODUP);
}
Possible fix:
case MDB_FIRST_DUP:
mfunc = mdb_cursor_first;
mmove:
if (data == NULL || !(mc->mc_flags & C_INITIALIZED)) {
rc = EINVAL;
break;
}
if (mc->mc_xcursor == NULL) {
rc = MDB_INCOMPATIBLE;
break;
}
if (mc->mc_ki[mc->mc_top] >= NUMKEYS(mc->mc_pg[mc->mc_top])) {
mc->mc_ki[mc->mc_top] = NUMKEYS(mc->mc_pg[mc->mc_top]);
rc = MDB_NOTFOUND;
break;
}
{
MDB_node *leaf = NODEPTR(mc->mc_pg[mc->mc_top],
mc->mc_ki[mc->mc_top]);
if (!F_ISSET(leaf->mn_flags, F_DUPDATA)) {
MDB_GET_KEY(leaf, key);
rc = mdb_node_read(mc, leaf, data);
break;
}
}
if (!(mc->mc_xcursor->mx_cursor.mc_flags & C_INITIALIZED)) {
rc = EINVAL;
break;
}
rc = mfunc(&mc->mc_xcursor->mx_cursor, data, NULL);
// FIX: clear C_EOF
if (rc == MDB_SUCCESS && mc->mc_flags & C_EOF && mfunc ==
mdb_cursor_first) {
mc->mc_flags ^= C_EOF;
}
break;
--
You are receiving this mail because:
You are on the CC list for the issue.