[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Openlap and BDB updates: update question



> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Ace Suares

> With all due respect, to me it sounds like someone who used
> 4.1.x was used to
> this:
>
> ldd `which slapd`
>         libldap_r.so.2 => /usr/lib/libldap_r.so.2 (0x40018000)
>         liblber.so.2 => /usr/lib/liblber.so.2 (0x40049000)
>         libdb-4.1.so => /usr/lib/libdb-4.1.so (0x40056000)
>         libiodbc.so.2 => /usr/lib/libiodbc.so.2 (0x40104000)
>         libslp.so.1 => /usr/lib/libslp.so.1 (0x4011e000)
>         libm.so.6 => /lib/libm.so.6 (0x4012a000)
>         libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x4014b000)
>         libgnutls.so.7 => /usr/lib/libgnutls.so.7 (0x4015d000)
>         libtasn1.so.0 => /usr/lib/libtasn1.so.0 (0x40193000)
>         libgcrypt.so.1 => /usr/lib/libgcrypt.so.1 (0x401a1000)
>         libnsl.so.1 => /lib/libnsl.so.1 (0x401de000)
>         libz.so.1 => /usr/lib/libz.so.1 (0x401f2000)
>         libcrypt.so.1 => /lib/libcrypt.so.1 (0x40200000)
>         libresolv.so.2 => /lib/libresolv.so.2 (0x4022d000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x4023d000)
>         libltdl.so.3 => /usr/lib/libltdl.so.3 (0x40251000)
>         libdl.so.2 => /lib/libdl.so.2 (0x40258000)
>         libwrap.so.0 => /lib/libwrap.so.0 (0x4025b000)
>         libc.so.6 => /lib/libc.so.6 (0x40264000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

> and is now, since 4.2.x, suddenly experiencing this:
>
> # ldd `which slapd`
>         libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x40029000)
>         libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x40059000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x40130000)
>         libc.so.6 => /lib/libc.so.6 (0x40180000)
>         libdl.so.2 => /lib/libdl.so.2 (0x402b3000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>
> Somehow, there has been a large change in how slapd is
> compiled with 4.1.x or 4.2.x

Something on your build environment has changed between your two builds. This
is has nothing to do with anything under our control; the OpenLDAP build
procedures in 2.1 and 2.2 are mostly unchanged and on a frozen build system,
produce nearly identical results:
~/r21obj/servers/slapd> ls -l slapd
-rwxr-xr-x   1 hyc      users     7750827 Jan 26 02:15 slapd
~/r21obj/servers/slapd> ldd slapd
        libdb-4.2.so => /usr/local/lib/libdb-4.2.so (0x40017000)
        libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x40105000)
        libssl.so.0.9.7 => /usr/local/lib/libssl.so.0.9.7 (0x40119000)
        libcrypto.so.0.9.7 => /usr/local/lib/libcrypto.so.0.9.7 (0x401e7000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x402e0000)
        libdl.so.2 => /lib/libdl.so.2 (0x402f2000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x402f5000)
        libc.so.6 => /lib/libc.so.6 (0x40347000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
~/r22obj/servers/slapd> ls -l slapd
-rwxr-xr-x   1 hyc      users    10857902 Jan 27 18:30 slapd
~/r22obj/servers/slapd> ldd slapd
        libdb-4.2.so => /usr/local/lib/libdb-4.2.so (0x40017000)
        libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x40105000)
        libssl.so.0.9.7 => /usr/local/lib/libssl.so.0.9.7 (0x40119000)
        libcrypto.so.0.9.7 => /usr/local/lib/libcrypto.so.0.9.7 (0x401e7000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x402e0000)
        libdl.so.2 => /lib/libdl.so.2 (0x402f2000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x402f5000)
        libc.so.6 => /lib/libc.so.6 (0x40347000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

As Kurt already tried to point out on a previous posting to this list, if you
want to make effective use of the software and the resources available to
you, you have to pay attention to where the boundaries lie. If you have a
problem with any piece of code that is not part of the OpenLDAP source
distribution, then it's not under our control. Go to the people who actually
are responsible for that chunk of software. If something changes in Cyrus
SASL, it's the responsibility of the Cyrus team to publicize that change.
Likewise for Sleepycat and Berkeley DB. When you raise Cyrus / BDB / whatever
issues here, that only fragments the discussion and reduces the value of both
the Cyrus / BDB / etc. support forum along with this forum, because it makes
the real answers harder to find. When people understand that all of their
Cyrus answers will always be in the Cyrus forums, not scattered willy-nilly
across eighteen different other forums, they'll have a better chance of
actually finding their answer and solving their problem.

When you allow a forum to get diluted with peripheral topics all you do is
decrease its value for everyone, not just the OpenLDAP users, but also the
Cyrus users, the BDB users, the OpenSSL users, etc.

When you see a "sudden" change in the code characteristics, you have to take
into account all the other possible changes that have occurred between your
"point A" and "point B" and these are things that you as a system
administrator are personally responsible for. It's not our job to tell you or
keep track for you "oh by the way, make sure the file permissions allow the
program to execute" or "oh make sure you have enough disk space and memory"
or "make sure your kernel has the latest patch" - these issues are implicit
in software/system management and are for you to take care of yourself.

  -- Howard Chu
  OpenLDAP Core Team