All,
I have a problem with a new OpenLDAP configuration that is likely my own doing, but I am unable to discern the cause.
Environment: Solaris 9, OpenLDAP 2.4.16, Berkeley DB 4.7.25
I installed the OpenLDAP software from the stable release at the openldap.org site. After some basic configuration and very basic tests, I did the "full" slapd.conf and DB_CONFIG configurations using various resources, including the Admin Guide and the FAQ-o-matic.
All seemed to be going well until I tried to add (ldapmodify -a w/ldif files) some new "person" entries based on data I want to migrate. The first one was OK, but subsequent ones never completed. When the problem occurs, there's no return from the ldapmodify command and likewise any "db_stat" commands that I attempt. When I look at the log (local4.debug) entries, the last entry is for the "ADD dn="uid=DCM...". The daemon is *not* looping, there's just never a response. [I need to break to get my prompt back.] When I attempt to stop the daemon, I get "waiting for 1 operations/tasks to finish" and I have to kill the daemon to get it to stop. When I restart, it goes through DB recovery and everything is as it was before the ldapmodify -a started.
A colleague suggested something that seems to be an indicator: - an add of "dn: uid=DCM11,ou=People,o=XXXX" works fine - an add of "dn: uid=DCM1123,ou=People,o=XXXX" works fine - an add of "dn: uid=DCM11234,ou=People,o=USNS" does *not* work So it seems that "uid" values with lengths over 7 characters fail. Yeah, this seems plenty odd to me, but I've created\tested\deleted DBs multiple times over and this still happens consistently.
I have tried multiple levels of "debug", down to "488" anyway, but still no message that seems like an error.
Not wanting to swamp anyone, here's some basic config extracts: ===DB_CONFIG=== set_cachesize 0 67108864 1 set_lg_bsize 2097152 set_lg_max 10485760 set_lg_regionmax 262144 ===
===slapd_t10.conf=== [obviously stripped] ... backend bdb database bdb suffix "o=XXXX" checkpoint 128 15 index objectClass eq index uid pres,eq [Have tried taking this out & re-creating - no difference] lastmod on monitoring on ... ===
Anyone have any ideas? I have spent many hours looking at this, but I'm willing to believe it's something simple I can't see.
Thanks in advance for you help. DCM
--On Wednesday, July 01, 2009 1:47 PM -0400 David.CTR.Muench@faa.gov wrote:
All,
I have a problem with a new OpenLDAP configuration that is likely my own doing, but I am unable to discern the cause.
Environment: Solaris 9, OpenLDAP 2.4.16, Berkeley DB 4.7.25
Did you fully patch BDB 4.7.25? You must have the patches to it from Oracle for it to work right.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
I had been using a pre-packaged version. It appears not to have been patched.
I went here (http://www.oracle.com/technology/software/products/berkeley-db/db/index.html) and downloaded the 4.7.25 distribution. I went here (ttp://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patch.4.7.25.html) and downloaded the 4 patches.
But, none of these patches completed "cleanly": -1 Hunk #1 failed at line 187. Hunk #3 failed at line 296. -2 Hunk #1 failed at line 1278. Hunk #2 failed at line 1470. -3 Hunk #1 failed at line 121. Hunk #2 failed at line 133. Hunk #3 failed at line 179. Hunk #4 failed at line 204. Hunk #5 failed at line 342. Hunk #8 failed at line 430. Hunk #9 failed at line 448. -4 Hunk #1 failed at line 33. Hunk #2 failed at line 55. Hunk #3 failed at line 181. Hunk #4 failed at line 286. Hunk #5 failed at line 398. Hunk #6 failed at line 1050. Hunk #7 failed at line 1093. Hunk #8 failed at line 1174.
Is 4.7.25 the wrong direction? Is there a "patched" version posted somewhere? (What's better?)
Thanks, DCM
Quanah Gibson-Mount quanah@zimbra.com 07/01/2009 02:07 PM
To David CTR Muench/AWA/CNTR/FAA@FAA, openldap-technical@openldap.org cc
Subject Re: Prb: UID Fields Over 7 Chars - add transaction hangs
--On Wednesday, July 01, 2009 1:47 PM -0400 David.CTR.Muench@faa.gov wrote:
All,
I have a problem with a new OpenLDAP configuration that is likely my own doing, but I am unable to discern the cause.
Environment: Solaris 9, OpenLDAP 2.4.16, Berkeley DB 4.7.25
Did you fully patch BDB 4.7.25? You must have the patches to it from Oracle for it to work right.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Wednesday, July 01, 2009 5:45 PM -0400 David.CTR.Muench@faa.gov wrote:
I had been using a pre-packaged version. It appears not to have been patched.
I went here (http://www.oracle.com/technology/software/products/berkeley-db/db/index. html) and downloaded the 4.7.25 distribution. I went here (ttp://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/pa tch.4.7.25.html) and downloaded the 4 patches.
But, none of these patches completed "cleanly":
That's because you're using the Solaris version of patch, most likely. There's some additional flags you have to use with it to make it behave sanely. I don't remember what they are.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Wednesday, July 01, 2009 5:45 PM -0400 David.CTR.Muench@faa.gov wrote:
I had been using a pre-packaged version. It appears not to have been patched.
I went here (http://www.oracle.com/technology/software/products/berkeley-db/db/index. html) and downloaded the 4.7.25 distribution. I went here (ttp://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/pa tch.4.7.25.html) and downloaded the 4 patches.
But, none of these patches completed "cleanly":
That's because you're using the Solaris version of patch, most likely. There's some additional flags you have to use with it to make it behave sanely. I don't remember what they are.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
Try dos2unix and then patch; or gpatch. At least, this was up on the mailing list ~1 month ago.
I hope it helps.
Regards, Zdenek
Follow-up...
Thanks to those who responded, especially Mr. Gibson-Mount and Mr. Styblik. Without your pointers, I would not have resolved it.
I needed to apply the patches to Berkeley DB 4.7.25. Specifically, I applied patches 1-3. Patch 4 would not apply; and, after seeing the "must have patches" e-mail trail from last December, I decided to try going without it.
I suggest a change to the Administrator's Guide, section D.1, "Dependency Versions", to strengthen the language from "...highly recommended to apply the patches...". Perhaps an asterisk'ed (*) entry on the line for (BDB) 4.7 to indicate that it's "mandatory" for that release. If there's a separate list I should address this to, please direct me.
Thanks again, Dave
Quanah Gibson-Mount quanah@zimbra.com 07/01/2009 02:07 PM
To David CTR Muench/AWA/CNTR/FAA@FAA, openldap-technical@openldap.org cc
Subject Re: Prb: UID Fields Over 7 Chars - add transaction hangs
--On Wednesday, July 01, 2009 1:47 PM -0400 David.CTR.Muench@faa.gov wrote:
All,
I have a problem with a new OpenLDAP configuration that is likely my own doing, but I am unable to discern the cause.
Environment: Solaris 9, OpenLDAP 2.4.16, Berkeley DB 4.7.25
Did you fully patch BDB 4.7.25? You must have the patches to it from Oracle for it to work right.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
David.CTR.Muench@faa.gov wrote:
Environment: Solaris 9, OpenLDAP 2.4.16, Berkeley DB 4.7.25
Did you apply the patches on the web page below when building Berkeley DB 4.7.25? You should.
http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patch...
All seemed to be going well until I tried to add (ldapmodify -a w/ldif files) some new "person" entries based on data I want to migrate.
Could you please provide the LDIF file you use? Or if that's confidential please try to generate some example data which illustrates the issue.
A colleague suggested something that seems to be an indicator:
- an add of "dn: uid=DCM11,ou=People,o=XXXX" works fine
- an add of "dn: uid=DCM1123,ou=People,o=XXXX" works fine
- an add of "dn: uid=DCM11234,ou=People,o=USNS" does *not* work
So it seems that "uid" values with lengths over 7 characters fail.
Very unlikely if only OpenLDAP server and clients are used. On Solaris systems it's always a good idea whether there's any library mix since the Sun LDAP libs are installed by default. Also check wheter you really use the ldapadd tool of your local OpenLDAP installation.
You could start slapd with parameter -d 65535 and watch what's written to the console.
Ciao, Michael.
David.CTR.Muench@faa.gov wrote:
A colleague suggested something that seems to be an indicator:
- an add of "dn: uid=DCM11,ou=People,o=XXXX" works fine
- an add of "dn: uid=DCM1123,ou=People,o=XXXX" works fine
- an add of "dn: uid=DCM11234,ou=People,o=USNS" does *not* work
So it seems that "uid" values with lengths over 7 characters fail. Yeah, this seems plenty odd to me, but I've created\tested\deleted DBs multiple times over and this still happens consistently.
Hello,
I don't know how to check-out version of dbd, but adding uid longer than 7 characters works for us. I've used inetOrgPerson (and adjecent). The only packages I've found are db44-4.4.20 and db42-4.2.52. OpenLDAP 2.4.16 at GNU/Linux.
So much for quick check-out.
Regards, Zdenek
openldap-technical@openldap.org
-
David.CTR.Muench＠faa.gov -
Michael Ströder -
Quanah Gibson-Mount -
Zdenek Styblik