This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2UKFBXSMIUKGELBPOGMTD
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Oops forgot the db in the second entry
it should of course be
# pcache overlay
dn: olcOverlay=3D{0}pcache,olcDatabase=3D{2}ldap,cn=3Dconfig
=2E..
This is also reflected in the following patch
---
doc/guide/admin/overlays.sdf | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/guide/admin/overlays.sdf b/doc/guide/admin/overlays.sdf
index a8ceede..8e2c81e 100644
--- a/doc/guide/admin/overlays.sdf
+++ b/doc/guide/admin/overlays.sdf
@@ -791,7 +791,7 @@ The same example as a LDIF file for back-config for
a caching server
which proxies for the {{EX:"dc=3Dexample,dc=3Dcom"}} subtree held
at server {{EX:ldap.example.com}}.
-> dn: olcDatabase=3D{2}ldap
+> dn: olcDatabase=3D{2}ldap,cn=3Dconfig
> objectClass: olcDatabaseConfig
> objectClass: olcLDAPConfig
> olcDatabase: {2}ldap
@@ -799,7 +799,7 @@ at server {{EX:ldap.example.com}}.
> olcRootDN: dc=3Dexample,dc=3Dcom
> olcDbURI: "ldap://ldap.example.com"
>
-> dn: olcOverlay=3D{0}pcache
+> dn: olcOverlay=3D{0}pcache,olcDatabase=3D{2}ldap,cn=3Dconfig
> objectClass: olcOverlayConfig
> objectClass: olcPcacheConfig
> olcOverlay: {0}pcache
@@ -809,7 +809,7 @@ at server {{EX:ldap.example.com}}.
> olcPcacheTemplate: "(&(sn=3D)(givenName=3D))" 0 3600 0 0 0
> olcPcacheTemplate: "(&(departmentNumber=3D)(secretary=3D))" 0 3600
>
-> dn: olcDatabase=3D{0}hdb
+> dn:
olcDatabase=3D{0}hdb,olcOverlay=3D{0}pcache,olcDatabase=3D{2}ldap,cn=3Dco=
nfig
> objectClass: olcHdbConfig
> objectClass: olcPcacheDatabase
> olcDatabase: {0}hdb
--=20
1.7.10.4
The attached patch file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following
patch(es) were developed by Bernd May bernd(a)net.t-labs.tu-berlin.de. I
have not assigned rights and/or interest in this work to any party.
I, Bernd May, hereby place the following 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.
--=20
Technische Universit=E4t Berlin - FGINET
Bernd May
System Administration
An-Institut Deutsche Telekom Laboratories
Sekr. TEL 16
Ernst-Reuter-Platz 7
10587 BERLIN
GERMANY
Mobile: 0160/90257737
E-Mail: bernd(a)net.t-labs.tu-berlin.de (T-Labs work)
WWW: net.t-labs.tu-berlin.de
------enig2UKFBXSMIUKGELBPOGMTD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBCAAGBQJRSgl/AAoJEH7/++7GEirBB/MP/RTuLNh7okStVOm6MttcIWtl
Zb9LokAFUne74hRr+filAGEP+7UTWgChxaxnTUX48C0m3/7teHYzZ8ARXXP2R0JF
zLVcuexjJ4Kqb8NFflxOxarP3ycNTCUtwHwUM9/6B4okRu3KtqoLIOiCU78QC2yk
vFuA6AA3kiIDswvqxNuCJw+wvNzVLZSdlGFLS2839wQPFpijwSC09OKEMjVwA6bZ
bAKgwqLRqgVOUjODYvmrq+XvQcyv/PienCbEMu6rPB3mRiOAq795TcrnDfiEM8f5
ClAcEXi31Qb3OTKBfOfFHIWxX/dE6DMKJn/kJturAoram1zQOS5DZyjqspaUHiY6
i3XB3LPRZh6TcLQs3/sDzsBB+sGXJMG/z6JVrpdxr8J6Wr7haI3auT6nLE3NDZjX
oidet1D8uy2HPQxT3L3FQfjBBpl23h1lSC4UQdNAbztqR5+ATpzkjJNp5AODl+DT
9rSPo1PRsIlL54L+pLcV2jzMJItm5bZ0DVYLXliJuCG2L7KuvSLkj86giQy/1JXL
BRiBRS5X49RNrlkZmDLXnqfBOcOFeJZ+N8YywJ44T/HeDyYKvGwgiCs9bN50PY8U
VSpmhw2pNJCnN1yfaI8UrK9hSHtLAfUBu0Gyf8P6G5qZk/XAvX8kYHVN0NuHtjkr
0cqgfDAbtyw3A6/Jn2P4
=SkKF
-----END PGP SIGNATURE-----
------enig2UKFBXSMIUKGELBPOGMTD--
--On Tuesday, March 19, 2013 8:57 PM +0000 "Swenson_CNTR, Carl E."
<Carl.Swenson(a)dodiis.mil> wrote:
> Quanah,
>
> Thank you for the reply.
>
> I double checked my versions on some of my systems just to be sure. One
> inconsistency I noticed was in the name of the DB package Possibly
> downloaded at 2 different times from sunfreeware.com.
>
> Example -
> Sun Enterprise SPARC T5220 (everything works on this system)
> pkginfo -l SMColdap - version 2.4.30
> pkginfo -l SMCossl - version 1.0.1c
> pkginfo -l SMCdb - version 4.7.25.NC
>
> Sun Enterprise SPARC T4-1 (the logs go crazy on this system)
> pkginfo -l SMColdap - version 2.4.30
> pkginfo -l SMCossl - version 1.0.1c
> pkginfo -l SMCdb47 - version 4.7.25.NC
>
> IDK how this would affect the system, but based on your suggestion there
> is some difference in the package as the "pkginst" name on one system is
> SMCdb, and SMCdb47 on the other while the version is exactly the same.
I have no idea. I abandoned Slowaris years ago... I abandoned using BDB
with OpenLDAP last year. However, no one has reported any issues like
this. It really appears to be a bug in BDB rather than OpenLDAP however.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
Full_Name: Bernd May
Version: 2.4
OS: GNU/Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (130.149.236.151)
The OpenLDAP 2.4 Administrator's Guide has an example configuration for the
ProxyCache overlay for the cn=config slapd backend in chapter 12.9.2.5. This
example is ambigious in providing guidance about the fact that the pcache
overlay requires a separate database to store its cached entries in.
In fact the example makes it look like the ldap database to be cached for, the
pcache overlay and the pcache database are totally individual entries below
cn=config. This is not the case and the example should be edited to reflect the
hierachy of those three entries, e.g.
# database to be cached for
dn: olcDatabase={2}ldap,cn=config
...
# pcache overlay
dn: olcOverlay={0}pcache,cn=config
...
# dn: olcDatabase={0}hdb,olcOverlay={0}pcache,cn=config
...
also indexing for the pcacheQueryid (as per the slapo-pcache manpage) might be
useful to include in the example, e.g.
olcDbIndex: pcacheQueryID eq
hth
Quanah,
Thank you for the reply.
I double checked my versions on some of my systems just to be sure. One inconsistency I noticed was in the name of the DB package Possibly downloaded at 2 different times from sunfreeware.com.
Example -
Sun Enterprise SPARC T5220 (everything works on this system)
pkginfo -l SMColdap - version 2.4.30
pkginfo -l SMCossl - version 1.0.1c
pkginfo -l SMCdb - version 4.7.25.NC
Sun Enterprise SPARC T4-1 (the logs go crazy on this system)
pkginfo -l SMColdap - version 2.4.30
pkginfo -l SMCossl - version 1.0.1c
pkginfo -l SMCdb47 - version 4.7.25.NC
IDK how this would affect the system, but based on your suggestion there is some difference in the package as the "pkginst" name on one system is SMCdb, and SMCdb47 on the other while the version is exactly the same.
Has anyone reported this before?
Any help would be greatly appreciated.
Thank you
Carl
-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
Sent: Tuesday, March 19, 2013 4:16 PM
To: Swenson_CNTR, Carl E.; openldap-its(a)openldap.org
Subject: Re: (ITS#7545) Problem with v2.4.30
--On Tuesday, March 19, 2013 7:37 PM +0000 carl.swenson(a)dia.mil wrote:
> Full_Name: C. Swenson
> Version: 2.4.30
> OS: Solaris 10
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (214.3.138.234)
Sounds like a bug in BDB to me, rather than openldap.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
--On Tuesday, March 19, 2013 7:37 PM +0000 carl.swenson(a)dia.mil wrote:
> Full_Name: C. Swenson
> Version: 2.4.30
> OS: Solaris 10
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (214.3.138.234)
Sounds like a bug in BDB to me, rather than openldap.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
Full_Name: C. Swenson
Version: 2.4.30
OS: Solaris 10
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (214.3.138.234)
All,
We have used OpenLDAP for years, and currently using v2.4.30 on several systems.
IDK if this is a bug on a specific platform, but there does not seem to be any
other logical explanation.
Sun Enterprise SPARC T4-1
Solaris 10 update10 8/11
Patch level 147440-27
OpenLDAP v2.4.30
data: /ldap/openLdapData/
logs: /ldap/openLdapLogs/
I have never seen an issue like this one. I have rebuilt and populated LDAP
several times, and every time after a few days the number of 50mb logs in the
logs directory "explodes". It will grow to the maximum size of the file system
until ldap crashes. We have added: set_flags DB_LOG_AUTOREMOVE to the DB_CONFIG
file, but this does not seem to do anything.
This new model Sun server (T4-1) is the only one that this has happened on, and
extensive searches turn up nothing but the autoremove suggestion.
This system is on an isolated classified network and I can not upload any log
files. Can someone tell us what kind of bug this is?
Carl
Full_Name: Hallvard B Furuseth
Version: 2.4.34
OS:
URL:
Submission from: (NULL) (193.157.249.58)
Submitted by: hallvard
I can't see that lmdb.h explains how long MDB_val data returned
to the API remains valid: I know the data cannot be used after
aborting/committing the txn. How about data in a dirty page -
can future update operations in the same txn invalidate it?
On 03/18/2013 07:48 PM, Howard Chu wrote:
> m.gr(a)gmx.de wrote:
>> Full_Name: Matthias Grau
>> Version: 2.4.34
>> OS: debian 6.7.0 x64
>> URL: ftp://ftp.openldap.org/incoming/matthias.grau.130318.bz2
>> Submission from: (NULL) (94.217.193.246)
>>
>>
>> slapd can cause a segfault when sorting values in modify operation.
>> Under rare circumstances modify.c:802: jstack += 2; can reach a value
>> of greater
>> 63 which leads to an overwritten pointer for AttributeDescription.
>
> Thanks for the report.
>
>> Changing the size of istack from sizeof(int) * 16 to sizeof(int)*16 +
>> 1 solves
>> the segfault. But I don't think that's the correct solution.
>> As shown here:
>> http://theory.stanford.edu/~amitp/rants/c++-vs-c/test5.cc
>> there should be a condition to break if jstack reaches the size of of
>> istack.
>
> No. In a correct implementation, jstack can never exceed the size of
> istack.
> This was fixed in similar/identical code elsewhere, e.g. commit
> bb36bdcd1c22d1fbc6575452ef5c9112715ab083 and
> e1559100eb8e9a664cd68915e5acbf8caa334fa1 but for some reason we missed
> these other instances.
>
> Fixed now in git master.
Thanks for your fast solution.
Problem is solved in git master.