Issue 7545 - Problem with v2.4.30
Summary: Problem with v2.4.30
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: 2.4.30
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-19 19:37 UTC by carl.swenson@dia.mil
Modified: 2014-08-01 21:04 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description carl.swenson@dia.mil 2013-03-19 19:37:56 UTC
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

Comment 1 Quanah Gibson-Mount 2013-03-19 20:16:00 UTC
--On Tuesday, March 19, 2013 7:37 PM +0000 carl.swenson@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

Comment 2 Swenson_CNTR, Carl E. 2013-03-19 20:57:37 UTC
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@openldap.org
Subject: Re: (ITS#7545) Problem with v2.4.30

--On Tuesday, March 19, 2013 7:37 PM +0000 carl.swenson@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

Comment 3 Quanah Gibson-Mount 2013-03-20 18:20:27 UTC
--On Tuesday, March 19, 2013 8:57 PM +0000 "Swenson_CNTR, Carl E." 
<Carl.Swenson@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

Comment 4 Swenson_CNTR, Carl E. 2013-03-26 18:09:05 UTC
Quanah,

Fine, I get it, you hate Solaris, BDB, etc......  But this is what I have to work with, and I still have an issue that I have never heard of, nor do I know what to even look for.  Google searches turn up very little.

Is there an "OpenLDAP forum" where you can get help?  I have tried removing the package labeled SMCdb47, and loaded SMCdb.  The result is still the same.  I know you don't like BDB, (you didn't mention what you do prefer) but in any case we are approved to use OpenLDAP w/ BDB.  Normally we download all the supporting packages from sunfreeware.com, and if I remember correctly, it is defaulted to use BDB.

So I have to use:
Solaris 10
BDB 4.7.25.NC
OpenSSL 1.0.1c
OpenLDAP 2.4.30

What can I do.  I have configured hundreds of servers using these packages, and their predecessors.  We have never seen this behavior.


Carl


-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
Sent: Wednesday, March 20, 2013 2:20 PM
To: Swenson_CNTR, Carl E.; openldap-its@openldap.org
Subject: RE: (ITS#7545) Problem with v2.4.30

--On Tuesday, March 19, 2013 8:57 PM +0000 "Swenson_CNTR, Carl E."
<Carl.Swenson@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

Comment 5 Quanah Gibson-Mount 2013-03-26 18:30:17 UTC
--On Tuesday, March 26, 2013 6:09 PM +0000 "Swenson_CNTR, Carl E." 
<Carl.Swenson@dodiis.mil> wrote:

> Quanah,
>
> Fine, I get it, you hate Solaris, BDB, etc......  But this is what I have
> to work with, and I still have an issue that I have never heard of, nor
> do I know what to even look for.  Google searches turn up very little.
>
> Is there an "OpenLDAP forum" where you can get help?  I have tried
> removing the package labeled SMCdb47, and loaded SMCdb.  The result is
> still the same.  I know you don't like BDB, (you didn't mention what you
> do prefer) but in any case we are approved to use OpenLDAP w/ BDB.
> Normally we download all the supporting packages from sunfreeware.com,
> and if I remember correctly, it is defaulted to use BDB.

As I initially stated, there is nothing in your bug report to indicate a 
bug with OpenLDAP.  I would note that BDB 4.7.25 is ancient.  I would note 
that OpenLDAP 2.4.30 is fairly old.  Who knows how OpenLDAP or BDB was 
built with those packages you are using.  There certainly isn't enough 
detail in your report to really offer you any particular direction to 
pursue.  If it was *me*, I would build the latest OpenLDAP with a current 
version of BDB, where I could control the compile options and flags.

By the way, BDB support in OpenLDAP is essentially deprecated.  All ongoing 
development is with the new MDB backend.

--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

Comment 6 Howard Chu 2013-03-26 18:56:08 UTC
Carl.Swenson@dodiis.mil wrote:
> Quanah,
>
> Fine, I get it, you hate Solaris, BDB, etc...... But this is what I have
> to
work with, and I still have an issue that I have never heard of, nor do I know
what to even look for. Google searches turn up very little.
>
> Is there an "OpenLDAP forum" where you can get help? I have tried removing
the package labeled SMCdb47, and loaded SMCdb. The result is still the same. I
know you don't like BDB, (you didn't mention what you do prefer) but in any
case we are approved to use OpenLDAP w/ BDB. Normally we download all the
supporting packages from sunfreeware.com, and if I remember correctly, it is
defaulted to use BDB.
>
> So I have to use:
> Solaris 10
> BDB 4.7.25.NC
> OpenSSL 1.0.1c
> OpenLDAP 2.4.30
>
> What can I do. I have configured hundreds of servers using these packages,
and their predecessors. We have never seen this behavior.

Well... Oracle now owns your hardware manufacturer and the software in 
question. They'd be the obvious place to ask for help.

Frankly I'm surprised that a military site on a classified network is allowed 
to install freeware binaries from any internet site. You have no idea how 
those binaries were built, and certainly no recourse if they fail in any way 
or happen to have trojans/malware embedded within.

My first step would be to compile current source code. If the behavior still 
exists on current code, then start debugging/diagnosing. BDB 4.7.25 is quite 
old, as Quanah already pointed out. We've never seen any other cases reported 
like this, but it's always possible for a mixture of old binaries and new 
hardware to go bad. For all you know it's an instruction set incompatibility 
and recompiling BDB for your T4 will make it go away.

>
>
> Carl
>
>
> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
> Sent: Wednesday, March 20, 2013 2:20 PM
> To: Swenson_CNTR, Carl E.; openldap-its@openldap.org
> Subject: RE: (ITS#7545) Problem with v2.4.30
>
> --On Tuesday, March 19, 2013 8:57 PM +0000 "Swenson_CNTR, Carl E."
> <Carl.Swenson@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
>
>
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Comment 7 Swenson_CNTR, Carl E. 2013-03-26 19:45:39 UTC
All,

Thank you for the replies.  Yes, Oracle makes the hardware, but as you may have experienced when dealing with Oracle, if there is anything on the server that is not "Oracle", then the problem must be with that software.  (This is the response you will get from Oracle on just about anything).

We have many security layers, and an "isolated network" that has zero chance of getting to the internet / outside world that is of very little risk from malware.  It is true we have never had to compile the packages being used so the install defaults referred to BDB, and that is what we used.  I realize BDB 4.7.25.NC may not be the "bleeding edge" but it is the release referred to on sunfreeware.com (they have v2.4.32 packaged for download), and when you look on OpenLDAP's web site there are references to get the compiled packages from sunfreeware.com.  I see on Oracle's web site there is a v5.3 download that can try.

As far as "mdb" goes, we don't know what that is, and most references even in the v2.4.34 download talk about BDB.  The purpose we use OpenLDAP for is a very simple authentication with WebLogic.  Nothing heavy duty.

I agree there could be some "strangeness" when mixing these packages with a new T4, but it is still unknown.

Quanah,

"There certainly isn't enough detail in your report to really offer you any particular direction to pursue."

What is it that would be useful, if I can capture it, and "secure" transfer it then I will.  But I can't get most detail reports through security de-class scan to be able to post it.

Carl

===========




Well... Oracle now owns your hardware manufacturer and the software in question. They'd be the obvious place to ask for help.

Frankly I'm surprised that a military site on a classified network is allowed to install freeware binaries from any internet site. You have no idea how those binaries were built, and certainly no recourse if they fail in any way or happen to have trojans/malware embedded within.

My first step would be to compile current source code. If the behavior still exists on current code, then start debugging/diagnosing. BDB 4.7.25 is quite old, as Quanah already pointed out. We've never seen any other cases reported like this, but it's always possible for a mixture of old binaries and new hardware to go bad. For all you know it's an instruction set incompatibility and recompiling BDB for your T4 will make it go away.

>
>
> Carl
>
>
> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
> Sent: Wednesday, March 20, 2013 2:20 PM
> To: Swenson_CNTR, Carl E.; openldap-its@openldap.org
> Subject: RE: (ITS#7545) Problem with v2.4.30
>
> --On Tuesday, March 19, 2013 8:57 PM +0000 "Swenson_CNTR, Carl E."
> <Carl.Swenson@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
>
>
>


--
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Comment 8 Quanah Gibson-Mount 2013-03-26 20:13:10 UTC
--On Tuesday, March 26, 2013 7:45 PM +0000 "Swenson_CNTR, Carl E." 
<Carl.Swenson@dodiis.mil> wrote:

> All,
>
> Thank you for the replies.  Yes, Oracle makes the hardware, but as you
> may have experienced when dealing with Oracle, if there is anything on
> the server that is not "Oracle", then the problem must be with that
> software.  (This is the response you will get from Oracle on just about
> anything).

BDB is owned by Oracle, so they should be able to help you with it.  The 
creation of the BDB log files is *purely* a function internal to BDB.  The 
fact that they are exploding would be a function of BDB.  That is why I've 
repeatedly said there is no indication of an OpenLDAP bug here.  That is 
why Howard directed you to Oracle.  They are the ones who own BDB, they 
should be able to provide you insight into why it has broken on your new 
server.

BDB logs are created when changes are made to the database.  If you see 
your logs "exploding" without corresponding massive changes being made to 
the OpenLDAP server, then you are essentially ensured that the issue is 
with BDB.  I would also suggest you run the db_archive utility to see what 
log(s) it says can or can't be archived.  It is possible that BDB is 
holding open a write or read transaction for some reason (again, a BDB bug).

As for MDB, it is a new database written by Howard Chu, the primary 
OpenLDAP Developer.  You can read up on it at <http://symas.com/mdb/>.  It 
is significantly better than BDB in numerous ways.  I disagree with your 
assessment on the recent change log as well.  It is almost all entirely 
around mdb.

OpenLDAP 2.4.34 Release (2013/03/03)
	Fixed liblmdb mdb_env_open flag handling (ITS#7453)
	Fixed liblmdb mdb_midl_sort array optimization (ITS#7432)
	Fixed liblmdb freelist with large entries (ITS#7455)
	Fixed liblmdb to check for filled dirty page list (ITS#7491)
	Fixed liblmdb to validate data limits (ITS#7485)
	Fixed liblmdb mdb_update_key for large keys (ITS#7505)
	Fixed slapd-mdb to reopen attr DBs after env reopen (ITS#7416)
	Fixed slapd-mdb handling of missing entries (ITS#7483,7496)
	Fixed slapd-mdb environment flag setting (ITS#7452)
	Fixed slapd-mdb with sub db slapcat (ITS#7469)
	Fixed slapd-mdb to correctly work with toolthreads > 2 (ITS#7488,ITS#7527)
	Fixed slapd-mdb subtree search speed (ITS#7473)

I see zero changes in 2.4.34 related to BDB at all.

OpenLDAP 2.4.33 Release (2012/10/10)
	Fixed liblmdb POSIX semaphore cleanup on environment close (ITS#7364)
	Fixed liblmdb mdb_page_split (ITS#7385, ITS#7229)
	Fixed slapd-mdb slapadd -q -w double free (ITS#7356)
	Fixed slapd-mdb to close read txn in reindex commit (ITS#7386)

Again, no changes related to BDB.

The last release with any fixes specific to BDB was 2.4.32.

--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

Comment 9 Quanah Gibson-Mount 2014-05-13 11:17:01 UTC
changed notes
changed state Open to Closed
Comment 10 OpenLDAP project 2014-08-01 21:04:03 UTC
Not an OpenLDAP issue