https://bugs.openldap.org/show_bug.cgi?id=9708
Issue ID: 9708
Summary: null (empty) attribute values of type Directory String
pass the dry-run validation
Product: OpenLDAP
Version: 2.5.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: mheyman(a)symas.com
Target Milestone: ---
On behalf of Aaron Bliss at Paychex
----
I'm pretty confident that I've identified a bug when running slapadd with the
dry-run switch. As a step of migrating a given replica set from oDSEE to
OpenLDAP, we of course make use of the dry-run switch after sanitizing a given
oDSEE export. However on a few migrations I've noticed that null (empty)
attribute values of type Directory String (which are illegal per the RFC) pass
the dry-run validation. This becomes really problematic because a subsequent
slapadd in which the quick switch is passed will load the invalid data into the
database. I understand that loading a given ldif using the quick switch
performs fewer consistency checks on the input data however with our largest
dataset's, it's not viable for us to migrate a given replica set from oDSEE to
OpenLDAP without using the quick switch (it would require an outage that's far
longer than we can allow for on the customer side of things).
It makes total sense for sure that OpenLDAP will not allow for null values for
this attribute type in keeping with the standard but unfortunately oDSEE allows
for it as such we have to account for it. Would it be possible to catch the
null attribute value scenario when performing a dry run and if so is there any
way this could be prioritized (doing so would be of tremendous help to us)? If
not then I'll have to write my own validation (not at all ideal) to check for
this scenario but for sure would be better if slapadd can catch this condition.
Thanks much as always.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6949
--- Comment #17 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
RE26:
• c23c6563
by Howard Chu at 2021-09-27T19:20:18+00:00
ITS#6949 honor specified loglevel, not just debuglevel
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6949
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|hyc(a)openldap.org |ondra(a)mistotebe.net
--- Comment #16 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Assigning to Ondrej for the load balancer portion
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6949
--- Comment #15 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• 77adb192
by Howard Chu at 2021-09-27T16:54:24+00:00
ITS#6949 honor specified loglevel, not just debuglevel
But skip calls to syslog() if logfile_only is set.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9709
Issue ID: 9709
Summary: Invalid link for Symas website
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The Symas website link in the powered by portion is invalid.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9705
Issue ID: 9705
Summary: synprov put add info into wrong cookie while
performing test059-consumer-config
Product: OpenLDAP
Version: 2.4.59
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: gil77for(a)gmail.com
Target Milestone: ---
There is an issue with syncrepl and syncprov working together in parallel. The
issue can be seen in provider LDAP server logs of test059-consumer-config. For
linux this problem does not cause the test to malfunction, but it may cause
replication to malfunction on other systems (or possibly on linux in a
different situation from the test). In case of OpenVMS we have this issue.
The problem is detected under the following circumstances, followed by a
step-by-step description of the actions in test 059 that lead to malfunction:
1. Adding replication configuration for the dn:
olcDatabase={1}ldif,cn=config
dn: olcDatabase={1}ldif,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: {0}rid=001 provider=ldap://localhost:9001/ binddn="cn=config"
bindmethod=simple credentials=******** searchbase="cn=schema,cn=config"
type=refreshAndPersist retry="3 5 300 5" timeout=3
suffixmassage="cn=schema,cn=config,cn=consumer"
this registers a syncInfo structure with the parameter rid=001 inside the
syncrepl engine. the corresponding syncCookie and cookieState are also created
inside this structure
2. adding includes by ldapadd to the configuration, this causes
{1}ldif,cn=config to be filled on the provider and register this adding in
rid=001 syncInfo cookies with sid=001:
include: file:///LDAP$SCHEMA:core.ldif
include: file:///LDAP$SCHEMA:cosine.ldif
include: file:///LDAP$SCHEMA:inetorgperson.ldif
include: file:///LDAP$SCHEMA:openldap.ldif
include: file:///LDAP$SCHEMA:nis.ldif
3. Adding replication configuration for the dn:
olcDatabase={1}mdb,cn=config,cn=consumer:
dn: olcDatabase={1}mdb,cn=config,cn=consumer
objectClass: olcDatabaseConfig
objectClass: olcmdbConfig
olcDatabase: {1}mdb
olcSuffix: dc=example,dc=com
olcDbDirectory: [.testdir.db_2_a]
olcRootDN: cn=Manager,dc=example,dc=com
olcRootPW: secret
olcSyncRepl: rid=002 provider=ldap://localhost:9001/
binddn="cn=Manager,dc=example,dc=com" bindmethod=simple
credentials=secret searchbase="dc=example,dc=com" type=refreshAndPersist
retry="3 5 300 5" timeout=3
olcUpdateRef: ldap://localhost:9001/
this registers new syncInfo structure with the parameter rid=002 inside the
syncrepl engine. Should also be added info into cookies of this structure but
this is the issue. The info about {1}mdb,cn=config,cn=consumer is added to the
cookie of structure with rid=001 (!!!). Thus the cookie about {1}ldif is
overrides by this new cookie data. It can be seen in provider server logs (was
run on linux):
……
61275c7d ldif_back_add: "olcDatabase={1}mdb,cn=config,cn=consumer"
61275c7d oc_check_required entry (olcDatabase={1}mdb,cn=config,cn=consumer),
objectClass "olcMdbConfig"
……
61275c7d slap_get_csn: conn=1007 op=3 generated new
csn=20210826091853.649104Z#000000#001#000000 manage=1
61275c7d slap_queue_csn: queueing 0x7fcdf4106bc0
20210826091853.649104Z#000000#001#000000
61275c7d ldif_write_entry: wrote entry
"olcDatabase={1}mdb,cn=config,cn=consumer"
61275c7d ldif_back_add: err: 0 text:
61275c7d send_ldap_result: conn=1007 op=3 p=3
61275c7d send_ldap_result: err=0 matched="" text=""
61275c7d conn=1007 op=3 syncprov_matchops: recording uuid for
dn=olcDatabase={1}mdb,cn=config,cn=consumer on opc=0x7fcdf4001608
……
61275c7d slap_graduate_commit_csn: removing 0x7fcdf4106bc0
20210826091853.649104Z#000000#001#000000
61275c7d conn=1004 op=1 syncprov_sendresp:
cookie=rid=001,sid=001,csn=20210826091853.649104Z#000000#001#000000
61275c7d conn=1004 op=1 syncprov_sendresp: sending LDAP_SYNC_ADD,
dn=olcDatabase={1}mdb,cn=config,cn=consumer
……
rid=002 should be there!
When running on linux, this does not cause a problem for the test, because
syncprov task works later than the ldif database replication on consumer by
syncrepl task. And the overlapped cookie entry does not matter anymore.
In our case (OpenVMS) the order of asynchronous tasks (syncrepl and syncprov)
is different and overwriting the cookie leads to loss of ldif database
replication and failure of the test. The consumer does not receive scheme data.
The differences in the order of tasks are caused by the features of pthreads
library implementation for the VMS. But it should not matter for LDAP
operation.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9703
Issue ID: 9703
Summary: init_config_ocs: register_oc failed
Product: OpenLDAP
Version: 2.5.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: goudal(a)enseirb.fr
Target Milestone: ---
Hello,
I just compiled openldap2.5.7 from source with the following command :
./configure '--enable-overlays' '--enable-crypt' '--with-tls'
'--enable-backends' '--with-cyrus-sasl' '--disable-ndb' '--enable-modules'
Distribution is Ubuntu20.04
When I start slapd it exits with the error
init_config_ocs: register_oc failed
With -d -1 flag I got the the following :
6149e48c.212556fe 0x7f20fc933740 wt_back_initialize: initialize WiredTiger
backend
6149e48c.21544f14 0x7f20fc933740 wt_back_initialize: WiredTiger 2.9.3: (June
26, 2017)
6149e48c.21558481 0x7f20fc933740 register_oc: objectclass "( OLcfgDbOc:9.1 NAME
'olcWtConfig' DESC 'Wt backend configuration' SUP olcDatabaseConfig MUST
olcDbDirectory MAY ( olcWtConfig $ olcDbIndex ) )": Inconsistent duplicate \
objectClass, 1.3.6.1.4.1.4203.1.12.2.4.2.9.1
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9690
Issue ID: 9690
Summary: 2.5.7: test suite is failing
Product: OpenLDAP
Version: 2.5.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: kloczko.tomasz(a)gmail.com
Target Milestone: ---
Created attachment 842
--> https://bugs.openldap.org/attachment.cgi?id=842&action=edit
Test suite log
Source code configured with below options:
%configure \
--disable-debug \
--disable-ndb \
--disable-slp \
--disable-sql \
--disable-wt \
--disable-static \
--enable-backends=mod \
--enable-bdb=yes \
--enable-cleartext \
--enable-crypt \
--enable-dynacl \
--enable-dynamic \
--enable-hdb \
--enable-lmpasswd \
--enable-mdb=yes \
--enable-modules \
--enable-monitor \
--enable-overlays=mod \
--enable-rewrite \
--enable-rlookups \
--enable-slapi \
--enable-spasswd \
--libexecdir=%{_libdir} \
--with-cyrus-sasl \
--with-gnu-ld \
--without-fetch \
--with-pic \
--with-threads \
%{nil}
Test suite log is in attachment
Please let me know if you need more details or want me to perform some
diasgnostics.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6097
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|2.6.1 |2.6.0
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6097
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|2.6.0 |2.6.1
--
You are receiving this mail because:
You are on the CC list for the issue.