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/