Обсуждение: Help compiling --with-ldap on Solaris 11 Express?
TL; DR version: I'm trying to compile 9.0.4 on Solaris 11 Express and having problems with LDAP support; I finally got it to compile and install but when I try to authenticate via LDAP I get "Assertion failed: LBER_VALID( ber ), file sasl.c, line 103, function ldap_sasl_bind" and it kills the process. More detailed version: I started with a clean install of Solaris Express 11 on a VMWare ESXi VM, single processor/2GB RAM. I installed from packages gcc-3, library/openldap and system/library/math/header-math. I downloaded the source tarball, uncompressed it and tried to configure: ./configure \ --enable-nls \ --with-python \ --with-openssl \ --with-libxml \ --enable-thread-safety \ --enable-dtrace \ --with-ldap \ --with-libs=/usr/lib \ --with-includes=/usr/include/openldap Configure failed with an error "checking for ldap_simple_bind in -lldap_r... no configure: error: library 'ldap_r' is required for LDAP" It looked to me that it wasn't finding /usr/lib/libldap_r-2.4.so I added a symlink pointing libldap_r.so to libldap_r-2.4.so -- after that configure worked but make failed: Undefined first referenced symbol in file ldap_start_tls_s libpq/auth.o So I tried setting LDFLAGS in the configure and make commands: LDFLAGS="-lldap_r" ./configure LDFLAGS="-lldap_r" gmake That worked okay, as did "gmake install" -- I could initdb successfully and connect locally with psql. But when I try to connect using LDAP auth it pukes: Assertion failed: LBER_VALID( ber ), file sasl.c, line 103, function ldap_sasl_bind LOG: server process (PID 26751) was terminated by signal 6 LOG: terminating any other active server processes WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. LOG: all server processes terminated; reinitializing LOG: database system was interrupted; last known up at 2011-07-01 01:54:39 CDT LOG: database system was not properly shut down; automatic recovery in progress LOG: consistent recovery state reached at 0/2501DBB4 LOG: record with zero length at 0/2501DBB4 LOG: redo is not required LOG: autovacuum launcher started LOG: database system is ready to accept connections Any pointers would be appreciated; I'm far from an expert on either Solaris or PostgreSQL, so it's very possible that I'm making one or more elementary mistakes. -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com "...Life is not a journey to the grave with the intention of arriving safely in one pretty and well-preserved piece, but to slide across the finish line broadside, thoroughly used up, worn out, leaking oil, and shouting GERONIMO!!!" -- Bill McKenna
Looking in openldap-2.4.10/libraries/liblber/lber-int.h:94 i see : #define LBER_VALID(ber) ((ber)->ber_valid==LBER_VALID_BERELEMENT) the assertion fails for some reason. Could you make a proper reinstallation of the openldap related packages (openldap-client and possibly -devel), remove the manual symbolic link, and try to ./configure again? You might change the --with-libs or --with-include part to match wherever your ldap client installation is located. Also, for the moment, drop the rest of --with- arguments, until you have a working postgresql with ldap, and you'll go gradually from there. Unfortunately i do not have a Solaris system to test. Στις Friday 01 July 2011 10:23:53 ο/η Dave Pooser έγραψε: > TL; DR version: I'm trying to compile 9.0.4 on Solaris 11 Express and > having problems with LDAP support; I finally got it to compile and install > but when I try to authenticate via LDAP I get "Assertion failed: > LBER_VALID( ber ), file sasl.c, line 103, function ldap_sasl_bind" and it > kills the process. > > More detailed version: > > I started with a clean install of Solaris Express 11 on a VMWare ESXi VM, > single processor/2GB RAM. > I installed from packages gcc-3, library/openldap and > system/library/math/header-math. > I downloaded the source tarball, uncompressed it and tried to configure: > ./configure \ > --enable-nls \ > --with-python \ > --with-openssl \ > --with-libxml \ > --enable-thread-safety \ > --enable-dtrace \ > --with-ldap \ > --with-libs=/usr/lib \ > --with-includes=/usr/include/openldap > > > Configure failed with an error > "checking for ldap_simple_bind in -lldap_r... no > configure: error: library 'ldap_r' is required for LDAP" > > It looked to me that it wasn't finding /usr/lib/libldap_r-2.4.so I added a > symlink pointing libldap_r.so to libldap_r-2.4.so -- after that configure > worked but make failed: > Undefined first referenced > symbol in file > ldap_start_tls_s libpq/auth.o > > So I tried setting LDFLAGS in the configure and make commands: > > LDFLAGS="-lldap_r" ./configure > LDFLAGS="-lldap_r" gmake > > That worked okay, as did "gmake install" -- I could initdb successfully > and connect locally with psql. But when I try to connect using LDAP auth > it pukes: > Assertion failed: LBER_VALID( ber ), file sasl.c, line 103, function > ldap_sasl_bind > LOG: server process (PID 26751) was terminated by signal 6 > LOG: terminating any other active server processes > WARNING: terminating connection because of crash of another server process > DETAIL: The postmaster has commanded this server process to roll back the > current transaction and exit, because another server process exited > abnormally and possibly corrupted shared memory. > HINT: In a moment you should be able to reconnect to the database and > repeat your command. > LOG: all server processes terminated; reinitializing > LOG: database system was interrupted; last known up at 2011-07-01 > 01:54:39 CDT > LOG: database system was not properly shut down; automatic recovery in > progress > LOG: consistent recovery state reached at 0/2501DBB4 > LOG: record with zero length at 0/2501DBB4 > LOG: redo is not required > LOG: autovacuum launcher started > LOG: database system is ready to accept connections > > Any pointers would be appreciated; I'm far from an expert on either > Solaris or PostgreSQL, so it's very possible that I'm making one or more > elementary mistakes. > > -- > Dave Pooser > Cat-Herder-in-Chief, Pooserville.com > "...Life is not a journey to the grave with the intention of arriving > safely in one pretty and well-preserved piece, but to slide across the > finish line broadside, thoroughly used up, worn out, leaking oil, and > shouting GERONIMO!!!" -- Bill McKenna > > > -- Achilleas Mantzios
On 7/1/11 9:21 AM, "Achilleas Mantzios" <achill@matrix.gatewaynet.com> wrote: >Looking in openldap-2.4.10/libraries/liblber/lber-int.h:94 i see : >#define LBER_VALID(ber) ((ber)->ber_valid==LBER_VALID_BERELEMENT) >the assertion fails for some reason. > >Could you make a proper reinstallation of the openldap related packages >(openldap-client and possibly -devel), >remove the manual symbolic link, and try to ./configure again? OK, this is Solaris so there isn't an openldap-client or openldap-devel; there's only SUNWopenldap, which I installed. >You might change the --with-libs or --with-include part to match wherever >your ldap client installation is located. OK. >Also, for the moment, drop the rest of --with- arguments, until you have >a working postgresql with ldap, >and you'll go gradually from there. Well, dropping the rest of --with- arguments leaves me with: ./configure \ --with-ldap \ --with-libs=/usr/lib/amd64 \ --with-libs=/usr/sfw/lib/amd64 \ --with-includes=/usr/include/openldap Which just gives a config error: checking for ldap_simple_bind in -lldap_r... no configure: error: library 'ldap_r' is required for LDAP >Unfortunately i do not have a Solaris system to test. I'm pretty sure this is a Solaris-specific set of problems, starting with the fact that instead of libldap_r.so it's got libldap_r-2.4.so and the configure script can't sort that out even though nm shows that ldap_r-2.4.so does in fact have the function it's griping about (ldap_simple_bind) in both the 32-bit and 64-bit versions. -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com "...Life is not a journey to the grave with the intention of arriving safely in one pretty and well-preserved piece, but to slide across the finish line broadside, thoroughly used up, worn out, leaking oil, and shouting GERONIMO!!!" -- Bill McKenna
Dave Pooser <dave-pg@pooserville.com> writes: > OK, this is Solaris so there isn't an openldap-client or openldap-devel; > there's only SUNWopenldap, which I installed. Hmmm .... > I'm pretty sure this is a Solaris-specific set of problems, starting with > the fact that instead of libldap_r.so it's got libldap_r-2.4.so and the > configure script can't sort that out even though nm shows that > ldap_r-2.4.so does in fact have the function it's griping about > (ldap_simple_bind) in both the 32-bit and 64-bit versions. The Oracle documentation avers that "-lldap" ought to be sufficient; see for example ldap_simple_bind page in http://download.oracle.com/docs/cd/E19963-01/pdf/821-1466.pdf and even without that evidence it's hard to believe that they'd expect calling applications to hardwire a library version number into their build scripts. So I'm pretty sure that there *should* be a libldap_r.so someplace. You could possibly try symlinking that to the version-numbered library. If all else fails you could --disable-thread-safety. regards, tom lane
On 7/2/11 7:16 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: >> I'm pretty sure this is a Solaris-specific set of problems, starting >>with >> the fact that instead of libldap_r.so it's got libldap_r-2.4.so and the >> configure script can't sort that out even though nm shows that >> ldap_r-2.4.so does in fact have the function it's griping about >> (ldap_simple_bind) in both the 32-bit and 64-bit versions. > >The Oracle documentation avers that "-lldap" ought to be sufficient; >see for example ldap_simple_bind page in >http://download.oracle.com/docs/cd/E19963-01/pdf/821-1466.pdf >and even without that evidence it's hard to believe that they'd expect >calling applications to hardwire a library version number into their >build scripts. They don't; they cheat and symlink: root@testdb:/home/locadmin/postgresql-9.0.4# ls -l /usr/lib/libldap.so lrwxrwxrwx 1 root root 12 Jul 2 14:48 /usr/lib/libldap.so -> libldap.so.5 But there's no such libldap_r.so symlink created by default. >So I'm pretty sure that there *should* be a libldap_r.so someplace. >You could possibly try symlinking that to the version-numbered library. Yep, and I did that to get past the configure problems, which allows me to encounter a whole new problem in make :^) >If all else fails you could --disable-thread-safety. Is that safe to do on a server with a few dozen concurrent users? -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com "...Life is not a journey to the grave with the intention of arriving safely in one pretty and well-preserved piece, but to slide across the finish line broadside, thoroughly used up, worn out, leaking oil, and shouting GERONIMO!!!" -- Bill McKenna
Dave Pooser <dave-pg@pooserville.com> writes: > On 7/2/11 7:16 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: >> The Oracle documentation avers that "-lldap" ought to be sufficient; >> see for example ldap_simple_bind page in >> http://download.oracle.com/docs/cd/E19963-01/pdf/821-1466.pdf >> and even without that evidence it's hard to believe that they'd expect >> calling applications to hardwire a library version number into their >> build scripts. > They don't; they cheat and symlink: > root@testdb:/home/locadmin/postgresql-9.0.4# ls -l /usr/lib/libldap.so > lrwxrwxrwx 1 root root 12 Jul 2 14:48 /usr/lib/libldap.so > -> libldap.so.5 That's not a cheat; that's exactly the way everybody else does it. That's how you get from a non-versioned library "-l" switch in a makefile to a version-numbered reference in the resulting executable. (The linker is supposed to dereference the symlink at link time.) > But there's no such libldap_r.so symlink created by default. Then you've got a broken package. Make the symlink by hand, and file a bug report with Oracle. >> If all else fails you could --disable-thread-safety. > Is that safe to do on a server with a few dozen concurrent users? The server doesn't care about this. It's only an issue for putting libpq into multithreaded application programs. regards, tom lane
>>
>>So I'm pretty sure that there *should* be a libldap_r.so someplace.
>>You could possibly try symlinking that to the version-numbered library.
>
>Yep, and I did that to get past the configure problems, which allows me
>to
>encounter a whole new problem in make :^)
That problem is that when I run gmake it eventually errors out with:
Undefined first referenced
symbol in file
ldap_start_tls_s libpq/auth.o
ld: fatal: symbol referencing errors. No output written to postgres
Needless to say, checking with nm confirms that ldap_start_tls_s is
present in libldap_r.so -- so I try forcing the issue:
root@testdb:/home/locadmin/postgresql-9.0.4#LIBS="-lldap_r" gmake
At this point 'gmake' works, as does 'gmake install' and when I check with
ldd things appear to be linked properly:
root@testdb:/home/locadmin/postgresql-9.0.4# ldd
/usr/local/pgsql/bin/postmaster
libnsl.so.1 => /lib/libnsl.so.1
libsocket.so.1 => /lib/libsocket.so.1
libm.so.2 => /lib/libm.so.2
libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2
libldap.so.5 => /usr/lib/libldap.so.5
libc.so.1 => /lib/libc.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libumem.so.1 => /lib/libumem.so.1
liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2
libresolv.so.2 => /lib/libresolv.so.2
libgen.so.1 => /lib/libgen.so.1
libnet.so => /usr/lib/libnet.so
libsasl.so.1 => /usr/lib/libsasl.so.1
libssl.so.0.9.8 => /lib/libssl.so.0.9.8
libcrypto.so.0.9.8 => /lib/libcrypto.so.0.9.8
libnspr4.so => /usr/lib/mps/libnspr4.so
libplc4.so => /usr/lib/mps/libplc4.so
libnss3.so => /usr/lib/mps/libnss3.so
libssl3.so => /usr/lib/mps/libssl3.so
libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1
libpthread.so.1 => /lib/libpthread.so.1
librt.so.1 => /lib/librt.so.1
libdl.so.1 => /lib/libdl.so.1
libnssutil3.so => /usr/lib/mps/libnssutil3.so
libplds4.so => /usr/lib/mps/libplds4.so
libthread.so.1 => /lib/libthread.so.1
root@testdb:/home/locadmin/postgresql-9.0.4# ldd
/usr/local/pgsql/bin/postgres
libnsl.so.1 => /lib/libnsl.so.1
libsocket.so.1 => /lib/libsocket.so.1
libm.so.2 => /lib/libm.so.2
libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2
libldap.so.5 => /usr/lib/libldap.so.5
libc.so.1 => /lib/libc.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libumem.so.1 => /lib/libumem.so.1
liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2
libresolv.so.2 => /lib/libresolv.so.2
libgen.so.1 => /lib/libgen.so.1
libnet.so => /usr/lib/libnet.so
libsasl.so.1 => /usr/lib/libsasl.so.1
libssl.so.0.9.8 => /lib/libssl.so.0.9.8
libcrypto.so.0.9.8 => /lib/libcrypto.so.0.9.8
libnspr4.so => /usr/lib/mps/libnspr4.so
libplc4.so => /usr/lib/mps/libplc4.so
libnss3.so => /usr/lib/mps/libnss3.so
libssl3.so => /usr/lib/mps/libssl3.so
libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1
libpthread.so.1 => /lib/libpthread.so.1
librt.so.1 => /lib/librt.so.1
libdl.so.1 => /lib/libdl.so.1
libnssutil3.so => /usr/lib/mps/libnssutil3.so
libplds4.so => /usr/lib/mps/libplds4.so
libthread.so.1 => /lib/libthread.so.1
So I set up my postgresql.conf to allow remote connections and my
pg_hba.conf to use LDAP authentication; I load my data; I try to connect
using LDAP--
And authentication fails, and I see in the log:
Assertion failed: LBER_VALID( ber ), file sasl.c, line 103, function
ldap_sasl_bind
LOG: server process (PID 7675) was terminated by signal 6
LOG: terminating any other active server processes
WARNING: terminating connection because of crash of another server process
Of course the function is also present in that @#$%^& libldap_r:
root@testdb:/home/locadmin# nm /usr/lib/libldap_r.so | grep
"ldap_sasl_bind"
[1385] | 104232| 760|FUNC |GLOB |0 |12 |ldap_sasl_bind
[1309] | 104992| 327|FUNC |GLOB |0 |12 |ldap_sasl_bind_s
It seems there's some magic incantation to REALLY bind that I'm just not
seeing here. Any help gratefully accepted.
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
"...Life is not a journey to the grave with the intention of arriving
safely in one pretty and well-preserved piece, but to slide across the
finish line broadside, thoroughly used up, worn out, leaking oil, and
shouting GERONIMO!!!" -- Bill McKenna
Dave Pooser <dave-pg@pooserville.com> writes:
> It seems there's some magic incantation to REALLY bind that I'm just not
> seeing here. Any help gratefully accepted.
Well, I don't know anything about Solaris either, but this bit looks
suspicious:
> root@testdb:/home/locadmin/postgresql-9.0.4# ldd
> /usr/local/pgsql/bin/postgres
> ...
> libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2
> libldap.so.5 => /usr/lib/libldap.so.5
> ...
I gather from a bit of googling that the internal data structures are
different between libldap and libldap_r, which means you really really
don't want both versions getting bound into one executable.
Most likely what is happening is that one of the other libraries called
by the postmaster is pulling in libldap_r --- a bit of research with ldd
should confirm or deny that. If so, you could probably fix things by
hacking LDAP_LIBS_BE in the configured src/Makefile.global to pull
in libldap_r not libldap. If you've got different libraries calling both
versions, then some library recompilation is going to be needed :-(
regards, tom lane
On 7/2/11 8:50 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: >Most likely what is happening is that one of the other libraries called >by the postmaster is pulling in libldap_r --- a bit of research with ldd >should confirm or deny that. If so, you could probably fix things by >hacking LDAP_LIBS_BE in the configured src/Makefile.global to pull >in libldap_r not libldap. That worked perfectly-- thanks so much for your help! Do you think this is a Solaris bug, or a Postgres bug, or is this a "works as designed but sysadmin is an idiot" situation? If it's the first, I might as well file a bug with Oracle, not that I expect them to be in any hurry to improve compatibility with a rival DB. -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com "...Life is not a journey to the grave with the intention of arriving safely in one pretty and well-preserved piece, but to slide across the finish line broadside, thoroughly used up, worn out, leaking oil, and shouting GERONIMO!!!" -- Bill McKenna
Dave Pooser <dave-pg@pooserville.com> writes:
> On 7/2/11 8:50 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>> Most likely what is happening is that one of the other libraries called
>> by the postmaster is pulling in libldap_r --- a bit of research with ldd
>> should confirm or deny that. If so, you could probably fix things by
>> hacking LDAP_LIBS_BE in the configured src/Makefile.global to pull
>> in libldap_r not libldap.
> That worked perfectly-- thanks so much for your help!
> Do you think this is a Solaris bug, or a Postgres bug, or is this a "works
> as designed but sysadmin is an idiot" situation? If it's the first, I
> might as well file a bug with Oracle, not that I expect them to be in any
> hurry to improve compatibility with a rival DB.
Hard to tell. If we'd seen more cases like this, I'd be wondering how
to teach configure to look to see which version of libldap was in use by
other libraries the postmaster needs. But this is the first such report
that I can recall, so I'm inclined to think it might be a misconfigured
library. (On my Linux box, for example, a fully-featured postmaster
links only to libldap not libldap_r, which is the behavior we were
expecting.)
Did you identify what it was that was linked to libldap_r?
regards, tom lane
On 7/3/11 10:33 AM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: >Did you identify what it was that was linked to libldap_r? Not yet; it was 4AM at that point here in Dallas and I'd been beating my head against it off and on since 11AM. So I was too brain-fried to figure out how to identify the library and too exhausted to put in the Google-time looking for a step-by-step guide. Maybe this evening, unless you can hit me with a step-by-step off the top of your head. -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com "...Life is not a journey to the grave with the intention of arriving safely in one pretty and well-preserved piece, but to slide across the finish line broadside, thoroughly used up, worn out, leaking oil, and shouting GERONIMO!!!" -- Bill McKenna
Dave Pooser <dave-pg@pooserville.com> writes:
> On 7/3/11 10:33 AM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>> Did you identify what it was that was linked to libldap_r?
> Not yet; it was 4AM at that point here in Dallas and I'd been beating my
> head against it off and on since 11AM. So I was too brain-fried to figure
> out how to identify the library and too exhausted to put in the
> Google-time looking for a step-by-step guide. Maybe this evening, unless
> you can hit me with a step-by-step off the top of your head.
ldd each of the libraries that postmaster depends on, to see what each
one depends on itself.
regards, tom lane