(ITS#7799) Crash in servers/slapd/backover.c / Solaris
by marty＠maui.co.uk
Full_Name: Marty Lee
Version: 2.4.39
OS: Solaris 10 / 11
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.149.129.52)
With a global overlay set, slapd is crashing in servers/slapd/backover.c at line
703, with a SEGV.
Seems someone else has seen the same issue and put an asset in there:
(703) BackendDB *be = op->o_bd, db;
slap_callback cb = {NULL, over_back_response, NULL, NULL}, **sc;
int rc = SLAP_CB_CONTINUE;
/* FIXME: used to happen for instance during abandon
* when global overlays are used... */
assert( op->o_bd != NULL );
However, the assert is after the first use of op->o_bd, so slapd has already
crashed!
The overlay I was using globally was
overlay memberof
memberof-refint true
After reading the comment above the assert, I checked my config and I am indeed
using a global overlay. When I put it into each database block instead,
everything works ok. I guess there is a more fundamental issue with global
overlays and this assert isn't actually catching the error.
I can quickly replicate the problem, so if you need me to look at anything
specific, let me know.
Maybe I've missed something that says global overlays are bad; but if so, then
I'd expect slapd to complain about it in the messages....
9 years, 4 months
(ITS#7798) back-mdb can crash if slapadd runs with slapd
by hyc＠OpenLDAP.org
Full_Name: Howard Chu
Version: 2.4.39
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (178.197.231.190)
Submitted by: hyc
back-mdb is supposed to work for slapd/slapadd etc all running concurrently.
slapd can crash if slapadd runs and the newly added entries use attributes that
weren't in the database when slapd was started, because mdb_entry_decode()
doesn't check for attribute validity.
A fix is coming shortly.
9 years, 4 months
(ITS#7797) crash with slapo-collect with existing attribute
by danno＠umich.edu
Full_Name: Dan Pritts
Version: 2.4.39
OS: centos 6.x x64
URL: ftp://ftp.openldap.org/incoming/bugreport-danno-20140206.tgz
Submission from: (NULL) (141.211.81.142)
Hi,
I'm attempting to use slapo-collect. In actual use I want to combine it with
the translucent overlay, but for the purposes of debugging I am just using a bdb
with local info.
If the collective attribute is defined already in a dn, slapd crashes hard.
Even with "any" logging enabled, nothing useful appears to be logged.
I made some small hacks on the nis.schema and core.schema so that the attributes
I want to be "collectives" can be defined on the parent OU's. (homeDirectory,
loginShell,gecos)
I've uploaded the config file, an ldif i used to populate the db, session output
showing a successful search and a failed one, and the syslog from the deceased
slapd.
thanks
danno
9 years, 4 months
Re: (ITS#7786) Impossible to modify cn=config if olcDbDirectory doesn't exist
by pierangelo.masarati＠polimi.it
On 02/06/2014 11:25 PM, Howard Chu wrote:
> Howard Chu wrote:
>> pierangelo.masarati(a)polimi.it wrote:
>>> On 01/15/2014 09:59 AM, raphael.ouazana(a)linagora.com wrote:
>>>> Full_Name: Raphael Ouazana
>>>> Version: 2.4.38
>>>> OS: Linux
>>>> URL: ftp://ftp.openldap.org/incoming/
>>>> Submission from: (NULL) (88.173.78.196)
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I have an old configuration that I would like to export/reimport. The
>>>> olcDbDirectory item of this configuration contains a directory that
>>>> does not
>>>> longer exist.
>>>> It it then impossible to modify the parameter:
>>>> - I was told not to edit directly LDIF config files
>>>> - if i try a slapcat -n0 I get:
>>>> 52d64c91 olcDbDirectory: value #0: invalid path: No such file or
>>>> directory
>>>> 52d64c91 config error processing olcDatabase={2}hdb,cn=config:
>>>> olcDbDirectory:
>>>> value #0: invalid path: No such file or directory
>>>> slapcat: bad configuration directory!
>>>>
>>>> I think slapcat should always allow to export a configuration.
>>>
>>> I see the point; slapcat is failing because to export the configuration
>>> (c->op == SLAP_CONFIG_EMIT) it needs to read the configuration first,
>>> and it reads the whole config tree.
>>>
>>> Perhaps when slapcat of only the config database is requested, config
>>> parsing should skip other databases, or at least ignore errors, if
>>> possible.
>>
>> Agreed, we definitely need this.
>
> But it's not clear that it's entirely feasible without major
> structural changes to back-config. In particular, later config items
> may depend on earlier ones succeeding (e.g., loading a module or
> reading a schema definition). So we can't simply no-op everything
> while running slapcat, nor can we safely ignore all errors, because we
> must still be able to parse all of the underlying config LDIF and some
> of it will be unparseable without appropriate schema being loaded.
In the specific case, the fix is trivial: the user must create the
folder. In principle, when a "ignore non-blocking errors" flag is set,
parsing of olcDbDirectory should not cause a failure. Such flag would
only be set for, say, database entries that are not strictly required
for that slapcat (for any tool operation that does not need such
database, for example). However, in this specific case, the user could
simply find the directory name by manually inspecting the offending LDIF
file...
p.
--
Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano
9 years, 4 months
Re: (ITS#7786) Impossible to modify cn=config if olcDbDirectory doesn't exist
by hyc＠symas.com
Howard Chu wrote:
> pierangelo.masarati(a)polimi.it wrote:
>> On 01/15/2014 09:59 AM, raphael.ouazana(a)linagora.com wrote:
>>> Full_Name: Raphael Ouazana
>>> Version: 2.4.38
>>> OS: Linux
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (88.173.78.196)
>>>
>>>
>>> Hi,
>>>
>>> I have an old configuration that I would like to export/reimport. The
>>> olcDbDirectory item of this configuration contains a directory that does not
>>> longer exist.
>>> It it then impossible to modify the parameter:
>>> - I was told not to edit directly LDIF config files
>>> - if i try a slapcat -n0 I get:
>>> 52d64c91 olcDbDirectory: value #0: invalid path: No such file or directory
>>> 52d64c91 config error processing olcDatabase={2}hdb,cn=config: olcDbDirectory:
>>> value #0: invalid path: No such file or directory
>>> slapcat: bad configuration directory!
>>>
>>> I think slapcat should always allow to export a configuration.
>>
>> I see the point; slapcat is failing because to export the configuration
>> (c->op == SLAP_CONFIG_EMIT) it needs to read the configuration first,
>> and it reads the whole config tree.
>>
>> Perhaps when slapcat of only the config database is requested, config
>> parsing should skip other databases, or at least ignore errors, if possible.
>
> Agreed, we definitely need this.
But it's not clear that it's entirely feasible without major structural
changes to back-config. In particular, later config items may depend on
earlier ones succeeding (e.g., loading a module or reading a schema
definition). So we can't simply no-op everything while running slapcat, nor
can we safely ignore all errors, because we must still be able to parse all of
the underlying config LDIF and some of it will be unparseable without
appropriate schema being loaded.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 4 months
Re: (ITS#7796) LDAP_DEBUG_TRACE for "not indexed" log messages
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms030804020205040903090604
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I, Michael Str=F6der, hereby place the attached modifications to OpenLDAP=
Software (and only these modifications) into the public domain. Hence, th=
ese
modifications may be freely used and/or redistributed for any purpose wit=
h or
without attribution and/or other notice.
Resent as readable ASCII diff for ITS.
diff --git a/servers/slapd/back-bdb/filterindex.c
b/servers/slapd/back-bdb/filterindex.c
index 71e3ea4..bafef72 100644
--- a/servers/slapd/back-bdb/filterindex.c
+++ b/servers/slapd/back-bdb/filterindex.c
@@ -741,7 +741,7 @@ equality_candidates(
&db, &mask, &prefix );
if ( rc =3D=3D LDAP_INAPPROPRIATE_MATCHING ) {
- Debug( LDAP_DEBUG_ANY,
+ Debug( LDAP_DEBUG_TRACE,
"<=3D bdb_equality_candidates: (%s) not indexed\n",
ava->aa_desc->ad_cname.bv_val, 0, 0 );
return 0;
@@ -858,7 +858,7 @@ approx_candidates(
&db, &mask, &prefix );
if ( rc =3D=3D LDAP_INAPPROPRIATE_MATCHING ) {
- Debug( LDAP_DEBUG_ANY,
+ Debug( LDAP_DEBUG_TRACE,
"<=3D bdb_approx_candidates: (%s) not indexed\n",
ava->aa_desc->ad_cname.bv_val, 0, 0 );
return 0;
@@ -978,7 +978,7 @@ substring_candidates(
&db, &mask, &prefix );
if ( rc =3D=3D LDAP_INAPPROPRIATE_MATCHING ) {
- Debug( LDAP_DEBUG_ANY,
+ Debug( LDAP_DEBUG_TRACE,
"<=3D bdb_substring_candidates: (%s) not indexed\n",
sub->sa_desc->ad_cname.bv_val, 0, 0 );
return 0;
@@ -1095,7 +1095,7 @@ inequality_candidates(
&db, &mask, &prefix );
if ( rc =3D=3D LDAP_INAPPROPRIATE_MATCHING ) {
- Debug( LDAP_DEBUG_ANY,
+ Debug( LDAP_DEBUG_TRACE,
"<=3D bdb_inequality_candidates: (%s) not indexed\n",
ava->aa_desc->ad_cname.bv_val, 0, 0 );
return 0;
diff --git a/servers/slapd/back-mdb/filterindex.c
b/servers/slapd/back-mdb/filterindex.c
index 58c1cc8..20c58b7 100644
--- a/servers/slapd/back-mdb/filterindex.c
+++ b/servers/slapd/back-mdb/filterindex.c
@@ -709,7 +709,7 @@ equality_candidates(
&dbi, &mask, &prefix );
if ( rc =3D=3D LDAP_INAPPROPRIATE_MATCHING ) {
- Debug( LDAP_DEBUG_ANY,
+ Debug( LDAP_DEBUG_TRACE,
"<=3D mdb_equality_candidates: (%s) not indexed\n",
ava->aa_desc->ad_cname.bv_val, 0, 0 );
return 0;
@@ -825,7 +825,7 @@ approx_candidates(
&dbi, &mask, &prefix );
if ( rc =3D=3D LDAP_INAPPROPRIATE_MATCHING ) {
- Debug( LDAP_DEBUG_ANY,
+ Debug( LDAP_DEBUG_TRACE,
"<=3D mdb_approx_candidates: (%s) not indexed\n",
ava->aa_desc->ad_cname.bv_val, 0, 0 );
return 0;
@@ -944,7 +944,7 @@ substring_candidates(
&dbi, &mask, &prefix );
if ( rc =3D=3D LDAP_INAPPROPRIATE_MATCHING ) {
- Debug( LDAP_DEBUG_ANY,
+ Debug( LDAP_DEBUG_TRACE,
"<=3D mdb_substring_candidates: (%s) not indexed\n",
sub->sa_desc->ad_cname.bv_val, 0, 0 );
return 0;
@@ -1060,7 +1060,7 @@ inequality_candidates(
&dbi, &mask, &prefix );
if ( rc =3D=3D LDAP_INAPPROPRIATE_MATCHING ) {
- Debug( LDAP_DEBUG_ANY,
+ Debug( LDAP_DEBUG_TRACE,
"<=3D mdb_inequality_candidates: (%s) not indexed\n",
ava->aa_desc->ad_cname.bv_val, 0, 0 );
return 0;
--------------ms030804020205040903090604
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC
BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw
MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj
MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd
NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV
hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/
0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ
NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH
AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91
ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj
ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC
BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG
CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0
dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry
b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8
q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b
zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP
yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB
OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF
pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb
4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn
BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP
MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK
d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl
2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93
d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjA2MTg0MDE4WjAj
BgkqhkiG9w0BCQQxFgQUwLSiF3mKOJ8HENymkcl0lWAoDp8wbAYJKoZIhvcNAQkPMV8wXTAL
BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN
BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD
MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y
ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS
c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAgcpUZTuD+GEImrl5X5xOVLPuJcsHlLmr
JWLrnLpOWBCd+caLEZjPcHge/3qSJB3BABOMK5VMV80LfesV9kQiolB6T9nMCD3CuLgAJRHD
IgkZFb06osWxvzKbvvdWfs/7Z1X/pMGlpnSMGOePq5tYnaZXY5oUbElmkbna8mrclRM+TY4r
mb4kcEskqLFScpl558H5EN6RWHsOYT3qaiyhhrSRUFu9tiVgJ5JpiNgdvpTofQpNt2m/WjZO
SRGRfFxRysiEP8SaZ8+KzwxEj+Kr7/ZxE0L0VtElapE8YIRFxWQbNVYHyfyD1PbYy5LcczEK
lkY7VvNTUS2tiN8Vj9QXaAAAAAAAAA==
--------------ms030804020205040903090604--
9 years, 4 months
Re: (ITS#7796) LDAP_DEBUG_TRACE for "not indexed" log messages
by michael＠stroeder.com
----==67b6fd74c7313eed06f01db906d1b2a0
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit
I, Michael Ströder, hereby place the attached modifications to OpenLDAP
Software (and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.
----==67b6fd74c7313eed06f01db906d1b2a0
Content-Type: text/x-patch; name="openldap-master-its7796.patch"
Content-Disposition: attachment; filename="openldap-master-its7796.patch"
Content-Transfer-Encoding: base64
ZGlmZiAtLWdpdCBhL3NlcnZlcnMvc2xhcGQvYmFjay1iZGIvZmlsdGVyaW5kZXguYyBiL3NlcnZl
cnMvc2xhcGQvYmFjay1iZGIvZmlsdGVyaW5kZXguYwppbmRleCA3MWUzZWE0Li5iYWZlZjcyIDEw
MDY0NAotLS0gYS9zZXJ2ZXJzL3NsYXBkL2JhY2stYmRiL2ZpbHRlcmluZGV4LmMKKysrIGIvc2Vy
dmVycy9zbGFwZC9iYWNrLWJkYi9maWx0ZXJpbmRleC5jCkBAIC03NDEsNyArNzQxLDcgQEAgZXF1
YWxpdHlfY2FuZGlkYXRlcygKIAkJJmRiLCAmbWFzaywgJnByZWZpeCApOwogCiAJaWYgKCByYyA9
PSBMREFQX0lOQVBQUk9QUklBVEVfTUFUQ0hJTkcgKSB7Ci0JCURlYnVnKCBMREFQX0RFQlVHX0FO
WSwKKwkJRGVidWcoIExEQVBfREVCVUdfVFJBQ0UsCiAJCQkiPD0gYmRiX2VxdWFsaXR5X2NhbmRp
ZGF0ZXM6ICglcykgbm90IGluZGV4ZWRcbiIsIAogCQkJYXZhLT5hYV9kZXNjLT5hZF9jbmFtZS5i
dl92YWwsIDAsIDAgKTsKIAkJcmV0dXJuIDA7CkBAIC04NTgsNyArODU4LDcgQEAgYXBwcm94X2Nh
bmRpZGF0ZXMoCiAJCSZkYiwgJm1hc2ssICZwcmVmaXggKTsKIAogCWlmICggcmMgPT0gTERBUF9J
TkFQUFJPUFJJQVRFX01BVENISU5HICkgewotCQlEZWJ1ZyggTERBUF9ERUJVR19BTlksCisJCURl
YnVnKCBMREFQX0RFQlVHX1RSQUNFLAogCQkJIjw9IGJkYl9hcHByb3hfY2FuZGlkYXRlczogKCVz
KSBub3QgaW5kZXhlZFxuIiwKIAkJCWF2YS0+YWFfZGVzYy0+YWRfY25hbWUuYnZfdmFsLCAwLCAw
ICk7CiAJCXJldHVybiAwOwpAQCAtOTc4LDcgKzk3OCw3IEBAIHN1YnN0cmluZ19jYW5kaWRhdGVz
KAogCQkmZGIsICZtYXNrLCAmcHJlZml4ICk7CiAKIAlpZiAoIHJjID09IExEQVBfSU5BUFBST1BS
SUFURV9NQVRDSElORyApIHsKLQkJRGVidWcoIExEQVBfREVCVUdfQU5ZLAorCQlEZWJ1ZyggTERB
UF9ERUJVR19UUkFDRSwKIAkJCSI8PSBiZGJfc3Vic3RyaW5nX2NhbmRpZGF0ZXM6ICglcykgbm90
IGluZGV4ZWRcbiIsCiAJCQlzdWItPnNhX2Rlc2MtPmFkX2NuYW1lLmJ2X3ZhbCwgMCwgMCApOwog
CQlyZXR1cm4gMDsKQEAgLTEwOTUsNyArMTA5NSw3IEBAIGluZXF1YWxpdHlfY2FuZGlkYXRlcygK
IAkJJmRiLCAmbWFzaywgJnByZWZpeCApOwogCiAJaWYgKCByYyA9PSBMREFQX0lOQVBQUk9QUklB
VEVfTUFUQ0hJTkcgKSB7Ci0JCURlYnVnKCBMREFQX0RFQlVHX0FOWSwKKwkJRGVidWcoIExEQVBf
REVCVUdfVFJBQ0UsCiAJCQkiPD0gYmRiX2luZXF1YWxpdHlfY2FuZGlkYXRlczogKCVzKSBub3Qg
aW5kZXhlZFxuIiwgCiAJCQlhdmEtPmFhX2Rlc2MtPmFkX2NuYW1lLmJ2X3ZhbCwgMCwgMCApOwog
CQlyZXR1cm4gMDsKZGlmZiAtLWdpdCBhL3NlcnZlcnMvc2xhcGQvYmFjay1tZGIvZmlsdGVyaW5k
ZXguYyBiL3NlcnZlcnMvc2xhcGQvYmFjay1tZGIvZmlsdGVyaW5kZXguYwppbmRleCA1OGMxY2M4
Li4yMGM1OGI3IDEwMDY0NAotLS0gYS9zZXJ2ZXJzL3NsYXBkL2JhY2stbWRiL2ZpbHRlcmluZGV4
LmMKKysrIGIvc2VydmVycy9zbGFwZC9iYWNrLW1kYi9maWx0ZXJpbmRleC5jCkBAIC03MDksNyAr
NzA5LDcgQEAgZXF1YWxpdHlfY2FuZGlkYXRlcygKIAkJJmRiaSwgJm1hc2ssICZwcmVmaXggKTsK
IAogCWlmICggcmMgPT0gTERBUF9JTkFQUFJPUFJJQVRFX01BVENISU5HICkgewotCQlEZWJ1Zygg
TERBUF9ERUJVR19BTlksCisJCURlYnVnKCBMREFQX0RFQlVHX1RSQUNFLAogCQkJIjw9IG1kYl9l
cXVhbGl0eV9jYW5kaWRhdGVzOiAoJXMpIG5vdCBpbmRleGVkXG4iLCAKIAkJCWF2YS0+YWFfZGVz
Yy0+YWRfY25hbWUuYnZfdmFsLCAwLCAwICk7CiAJCXJldHVybiAwOwpAQCAtODI1LDcgKzgyNSw3
IEBAIGFwcHJveF9jYW5kaWRhdGVzKAogCQkmZGJpLCAmbWFzaywgJnByZWZpeCApOwogCiAJaWYg
KCByYyA9PSBMREFQX0lOQVBQUk9QUklBVEVfTUFUQ0hJTkcgKSB7Ci0JCURlYnVnKCBMREFQX0RF
QlVHX0FOWSwKKwkJRGVidWcoIExEQVBfREVCVUdfVFJBQ0UsCiAJCQkiPD0gbWRiX2FwcHJveF9j
YW5kaWRhdGVzOiAoJXMpIG5vdCBpbmRleGVkXG4iLAogCQkJYXZhLT5hYV9kZXNjLT5hZF9jbmFt
ZS5idl92YWwsIDAsIDAgKTsKIAkJcmV0dXJuIDA7CkBAIC05NDQsNyArOTQ0LDcgQEAgc3Vic3Ry
aW5nX2NhbmRpZGF0ZXMoCiAJCSZkYmksICZtYXNrLCAmcHJlZml4ICk7CiAKIAlpZiAoIHJjID09
IExEQVBfSU5BUFBST1BSSUFURV9NQVRDSElORyApIHsKLQkJRGVidWcoIExEQVBfREVCVUdfQU5Z
LAorCQlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwKIAkJCSI8PSBtZGJfc3Vic3RyaW5nX2NhbmRp
ZGF0ZXM6ICglcykgbm90IGluZGV4ZWRcbiIsCiAJCQlzdWItPnNhX2Rlc2MtPmFkX2NuYW1lLmJ2
X3ZhbCwgMCwgMCApOwogCQlyZXR1cm4gMDsKQEAgLTEwNjAsNyArMTA2MCw3IEBAIGluZXF1YWxp
dHlfY2FuZGlkYXRlcygKIAkJJmRiaSwgJm1hc2ssICZwcmVmaXggKTsKIAogCWlmICggcmMgPT0g
TERBUF9JTkFQUFJPUFJJQVRFX01BVENISU5HICkgewotCQlEZWJ1ZyggTERBUF9ERUJVR19BTlks
CisJCURlYnVnKCBMREFQX0RFQlVHX1RSQUNFLAogCQkJIjw9IG1kYl9pbmVxdWFsaXR5X2NhbmRp
ZGF0ZXM6ICglcykgbm90IGluZGV4ZWRcbiIsIAogCQkJYXZhLT5hYV9kZXNjLT5hZF9jbmFtZS5i
dl92YWwsIDAsIDAgKTsKIAkJcmV0dXJuIDA7Cg==
----==67b6fd74c7313eed06f01db906d1b2a0--
9 years, 4 months
(ITS#7796) LDAP_DEBUG_TRACE for "not indexed" log messages
by michael＠stroeder.com
Full_Name:
Version: HEAD and RE24
OS:
URL:
Submission from: (NULL) (212.227.35.93)
Especially when using set-based ACLs the amount of "not indexed" messages is
really annoying even when only "loglevel stats" is used.
Since those messages are useless even for beginners the log-level should be
changed to LDAP_DEBUG_TRACE instead of LDAP_DEBUG_ANY.
9 years, 4 months
