requate(a)univention.de wrote:
> Full_Name: Arvid Requate
> Version: 2.4.35
> OS: Debian / UCS
> URL: http://apt.univention.de/download/temp/openldap/
> Submission from: (NULL) (82.198.197.8)
>
>
> After adjusting a matching rule of an attribute ldapsearch for existing
> attribute values returns unexpected results.
Making such changes requires the DB to be reloaded. This is not a bug, closing
this ITS.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Full_Name: Arvid Requate
Version: 2.4.35
OS: Debian / UCS
URL: http://apt.univention.de/download/temp/openldap/
Submission from: (NULL) (82.198.197.8)
After adjusting a matching rule of an attribute ldapsearch for existing
attribute values returns unexpected results. As an example the log file and the
script provided in the URL show what happened:
A) Start with the normal inetorgperson.schema.
1. create a inetOrgPerson object with and uppercase string in "carLicense"
2. search for the attributes in with different filters (normal and extensive
matching)
3. change the EQUALITY matching rule for that attribute from caseIgnoreMatch to
caseExactMatch (either in slapd.conf and restart or in cn=config without
restart).
4. search again.
Expected result A.1: the normal search for the uppercase value should return the
value
The log file shows: the search for the uppercase value returns no result
Expected result A.2: the normal search for the lowercase value should return no
result
The log file shows: the search for the lowercase value returns a result
The same holds for the extensible :caseExactMatch: search.
B) The second, morempreressive, inverse test shows that this behaviour depends
on the matching rule that was in place at the time the obejct gets created:
Starting now with a caseExactMatch EQUALITY matching rule for "carLicense" I
repeat the test above:
1. create a inetOrgPerson object with and uppercase string in "carLicense"
2. search for the attributes in with different filters (normal and extensive
matching)
3. change the EQUALITY matching rule for that attribute from caseExactMatch to
caseIgnoreMatch (either in slapd.conf and restart or in cn=config without
restart).
4. search again.
Expected result B.1: the normal search for the uppercase value should return the
value
The log file shows: the search for the uppercase value returns no result
Expected result B.2: the normal search for the lowercase value should return the
value
The log file shows: the search for the lowercase value returns no result
Expected result B.3: the :caseIgnoreMatch: extensible filter should find the
value
The log file shows: the search for the lowerca v value returns no result
The provided shell script works by changing the schema directly via cn=config,
but the same results can be found when using static configuration+schema files
and restarting slapd after each schema modification.
No index was configured for the "carLicense" attribute and a bdb backend was
used. See the cn=config.ldif provided.
ryan(a)nardis.ca wrote:
> On 08/09/14 01:30 PM, quanah(a)zimbra.com wrote:
>> Schema filenames should only be alphanumeric. Noted to update the
>> documentation with this restriction.
>
> OK, noted. Even so, please consider a change along the lines of
> <http://paste.debian.net/119969/>, just to avoid crashing on an
> inappropriate filename.
Patched in master, thanks.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
On 08/09/14 01:30 PM, quanah(a)zimbra.com wrote:
> Schema filenames should only be alphanumeric. Noted to update the
> documentation with this restriction.
OK, noted. Even so, please consider a change along the lines of
<http://paste.debian.net/119969/>, just to avoid crashing on an
inappropriate filename.
--On Monday, September 08, 2014 7:03 PM +0000 ryan(a)nardis.ca wrote:
> Full_Name: Ryan Tandy
> Version: master, RE24
> OS: Debian
> URL:
> Submission from: (NULL) (24.68.121.206)
>
>
> Hi,
>
> Debian bug report:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603544
Schema filenames should only be alphanumeric. Noted to update the
documentation with this restriction.
--Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
Full_Name: Ryan Tandy
Version: master, RE24
OS: Debian
URL:
Submission from: (NULL) (24.68.121.206)
Hi,
Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603544
Steps to reproduce:
ln -s /usr/local/etc/openldap/schema/core.schema core+test.schema
echo 'include ./core+test.schema' > slapd.confA0Amkdir slapd.d
slaptest -f slapd.conf -F slapd.d
Before commit d1b38bd ("ITS#6967 normalize schema RDN"), this fails with:
config_build_entry: build "cn={0}core+test" failed: "(null)"
backend_startup_one (type=config, suffix="cn=config"): bi_db_open failed! (-1)
but slapd still works if running with slapd.conf only (-F omitted).
After that commit, slaptest and slapd both crash shortly after rdnNormalize at
bconfig.c:6841. rdnNormalize() fails because the constructed DN is not valid,
but its return value is not checked.
It would be really nice if it would automatically escape or replace
inappropriate characters in the filename, but I'll understand if that's asking
too much. :)
(Alternatively, if there are restrictions on what is considered a valid schema
filename, please document them.)
varkoly(a)suse.com wrote:
> Full_Name: Peter Varkoly
> Version: 2.4.26, 2.4.39
> OS: SUSE Enterprise Server
> URL: ftp://ftp.suse.com/pub/people/varkoly
> Submission from: (NULL) (2620:113:80c0:5::2222)
>
>
> Enabling both the "memberof" and "accesslog" overlays in openldap causes
> accesslog to only log "reads" and "session" operations when logops is set to
> all (olcAccessLogOps = all).
>
> Disabling the "memberof" overlay results in "writes", "reads" and "session"
> operations to be logged.
>
> Setting "olcAccessLogOps = writes" in conjunction with the "memberof" overlay
> results in "writes" operations to be logged.
Fixed now in git master.
>
> Expected result is that when "olcAccessLogOps = all" is set for the "accesslog"
> overlay together with the "memberof" overlay, that all operations (add, modify,
> delete, modrdn, search, bind, unbind, abandon, compare) are logged to
> cn=accesslog.
>
> The order of activating the overlays is irrelevant. We have tested it by
> activating first memberof and accesslog too.
>
> We are using the config-backend.
>
> The configuration will be available soon under the provided URL.
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
varkoly(a)suse.com wrote:
> Full_Name: Peter Varkoly
> Version: 2.4.26, 2.4.39
> OS: SUSE Enterprise Server
> URL: ftp://ftp.suse.com/pub/people/varkoly
> Submission from: (NULL) (2620:113:80c0:5::2222)
>
> We are using the config-backend.
>
> The configuration will be available soon under the provided URL.
The config DB is a slapd backend like any other. The proper way to export any
slapd backend is using slapcat, as plainly documented already. A tar (or any
other type of) archive of the raw slapd backend files is nonportable.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/