Re: [nssldap] Segmentation Faults for Ldap Accounts

[Andrew Morgan <morgan [at] orst.edu>]

On Thu, 10 Apr 2008, Jim Summers wrote:

> I found the debug parameter in ldap.conf and set it to 1.  Now when I run 
> commands I can see what is happening.  The interesting part is that if I run 
> an 'id' command the output from both machines mathces.  But if I run the 
> brightq program I see different debug. For example:
> Here is the debug from the Fedora 8 running the codehost-config command:
> ===========
> ldap_create
> ldap_url_parse_ext(ldaps://ldap1)
> ldap_create
> ldap_url_parse_ext(ldaps://ldap1)
> ldap_simple_bind
> ldap_sasl_bind
> ldap_send_initial_request
> ldap_new_connection 1 1 0
> ldap_int_open_connection
> ldap_connect_to_host: TCP ldap1:636
> ldap_new_socket: 4
> ldap_prepare_socket: 4
> ldap_connect_to_host: Trying 192.10.10.13:636
> ldap_connect_timeout: fd: 4 tm: 30 async: 0
> ldap_ndelay_on: 4
> ldap_is_sock_ready: 4
> ldap_ndelay_off: 4
> ===========
> and at this point the segfault happens.
>
> Here it is from the FC6 and the command works:
>
> ldap_createldap_url_parse_ext(ldaps://ldap1)
> ldap_create
> ldap_url_parse_ext(ldaps://ldap1)
> ldap_simple_bind
> ldap_sasl_bind
> ldap_send_initial_request
> ldap_new_connection 1 1 0
> ldap_int_open_connection
> ldap_connect_to_host: TCP ldap1:636
> ldap_new_socket: 4
> ldap_prepare_socket: 4
> ldap_connect_to_host: Trying 192.10.10.13:636
> ldap_connect_timeout: fd: 4 tm: 30 async: 0
> ldap_ndelay_on: 4
> ldap_is_sock_ready: 4
> ldap_ndelay_off: 4
> TLS trace: SSL_connect:before/connect initialization
> TLS trace: SSL_connect:SSLv2/v3 write client hello A
> TLS trace: SSL_connect:SSLv3 read server hello A
> TLS certificate verification: depth: 1, err: 19, subject: /CN=CAcert, issuer: 
> /CN=CAcert
> TLS certificate verification: Error, self signed certificate in certificate 
> chain
> TLS trace: SSL_connect:SSLv3 read server certificate A
> TLS trace: SSL_connect:SSLv3 read server done A
> TLS trace: SSL_connect:SSLv3 write client key exchange A
> TLS trace: SSL_connect:SSLv3 write change cipher spec A
> TLS trace: SSL_connect:SSLv3 write finished A
> TLS trace: SSL_connect:SSLv3 flush data
> TLS trace: SSL_connect:SSLv3 read finished A
> ldap_open_defconn: successful
> ldap_send_server_request
> .....
>
> The output from the id commands on either system matches.
>
> Any ideas or suggestions?

Use the ldd command on your brightq binary and on your libnss_ldap.so 
library.  See if they are referencing different versions of the SSL 
libraries.  This smells like a library mismatch problem to me.

        Andy