Segmentation Faults for Ldap Accounts

View: New views
14 Messages — Rating Filter:   Alert me  

Segmentation Faults for Ldap Accounts

by Jim Summers :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello All,

I have encountered a problem that I think is related to nss_ldap or
pam_ldap.

I am using a fedora directory server for my authentication.  It is
authenticating for RHEL4 and 5 and Fedora 5,6,8 clients.

Everything is functioning as expected on all clients except for Fedora 8
clients.  The problem is related to two programs that my users run,
vmplayer and brightq printing system from codehost.com for canon printers.

On a Fedora 8 client anytime a user from the ldap attempts to run
vmplayer I start seeing entries in /var/log/messages about it trying to
pull something from the ldap or passwd and it loops until it is killed.
  The brightq software simply segfaults.  Using strace it appears to
trying to resolve gid or uid numbers.  Local accounts can run either
program with no problem.

On any of the older clients there is not any problems with either
program for ldap users.

So I feel that something new is in place for Fedora 8 and I have
overlooked what I need to configure or account for.  Selinux is turned
off on all of the clients.

Ideas/Suggestions?

I will get specific logfile entries when I get back onsite.

TIA
--
Jim Summers
Computer Science - University of Oklahoma


Re: Segmentation Faults for Ldap Accounts

by Buchan Milne-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Thu, 2008-04-10 at 08:55 -0500, Jim Summers wrote:

> Hello All,
>
> I have encountered a problem that I think is related to nss_ldap or
> pam_ldap.
>
> I am using a fedora directory server for my authentication.  It is
> authenticating for RHEL4 and 5 and Fedora 5,6,8 clients.
>
> Everything is functioning as expected on all clients except for Fedora 8
> clients.  The problem is related to two programs that my users run,
> vmplayer and brightq printing system from codehost.com for canon printers.
>
> On a Fedora 8 client anytime a user from the ldap attempts to run
> vmplayer I start seeing entries in /var/log/messages about it trying to
> pull something from the ldap or passwd and it loops until it is killed.
>   The brightq software simply segfaults.  Using strace it appears to
> trying to resolve gid or uid numbers.  Local accounts can run either
> program with no problem.
>
> On any of the older clients there is not any problems with either
> program for ldap users.
>
> So I feel that something new is in place for Fedora 8 and I have
> overlooked what I need to configure or account for.  Selinux is turned
> off on all of the clients.
>
> Ideas/Suggestions?


Is the client that exhibits this problem an x86_64 machine, running an
x86_64 OS ? Are all the problems experienced by 32-bit applications? If
so, you probably need to check if you have a 32bit nss_ldap
installed ...


Regards,
Buchan


Re: Segmentation Faults for Ldap Accounts

by Jim Summers :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



Buchan Milne wrote:

> On Thu, 2008-04-10 at 08:55 -0500, Jim Summers wrote:
>> Hello All,
>>
>> I have encountered a problem that I think is related to nss_ldap or
>> pam_ldap.
>>
>> I am using a fedora directory server for my authentication.  It is
>> authenticating for RHEL4 and 5 and Fedora 5,6,8 clients.
>>
>> Everything is functioning as expected on all clients except for Fedora 8
>> clients.  The problem is related to two programs that my users run,
>> vmplayer and brightq printing system from codehost.com for canon printers.
>>
>> On a Fedora 8 client anytime a user from the ldap attempts to run
>> vmplayer I start seeing entries in /var/log/messages about it trying to
>> pull something from the ldap or passwd and it loops until it is killed.
>>   The brightq software simply segfaults.  Using strace it appears to
>> trying to resolve gid or uid numbers.  Local accounts can run either
>> program with no problem.
>>
>> On any of the older clients there is not any problems with either
>> program for ldap users.
>>
>> So I feel that something new is in place for Fedora 8 and I have
>> overlooked what I need to configure or account for.  Selinux is turned
>> off on all of the clients.
>>
>> Ideas/Suggestions?
>
>
> Is the client that exhibits this problem an x86_64 machine, running an
> x86_64 OS ? Are all the problems experienced by 32-bit applications? If
> so, you probably need to check if you have a 32bit nss_ldap
> installed ...
Many Thanks.

The brightq software is 32bit and the machines I am testing it on are also
32bit.  I am a little stumped as to the problem.  I was going through the
access log on the directory server and it seems that the Fedora 8 is doing a
whole lot of queries with the uidNumber.  Whereas the FC6 machine I was
looking at seem to do more with the uid.  I wonder if there is something there
that is causing some confusion like trying to find a memberuid that is numeric
or something from the group container.

I also have some 64bit machines that definitely have the vmplayer problem.  I
checked those and yum says that nss_ldap.i386 and nss_ldap.x86_64 are
installed.  Is there possibly some compatibility packeages that are necessary?

I am stumped at this point, the OS commands like "id" all work fine,
authentication and stuff is fine.

Ideas / Suggestions?

Thanks again!


>
>
> Regards,
> Buchan

--
Jim Summers
School of Computer Science-University of Oklahoma
-------------------------------------------------

Debug Level

by Jim Summers :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Is there any way to increase the debug level in nss_ldap or pam_ldap so
that I can get more info on what may be going on?

Thanks

Jim Summers wrote:

>
>
> Buchan Milne wrote:
>> On Thu, 2008-04-10 at 08:55 -0500, Jim Summers wrote:
>>> Hello All,
>>>
>>> I have encountered a problem that I think is related to nss_ldap or
>>> pam_ldap.
>>>
>>> I am using a fedora directory server for my authentication.  It is
>>> authenticating for RHEL4 and 5 and Fedora 5,6,8 clients.
>>>
>>> Everything is functioning as expected on all clients except for
>>> Fedora 8 clients.  The problem is related to two programs that my
>>> users run, vmplayer and brightq printing system from codehost.com for
>>> canon printers.
>>>
>>> On a Fedora 8 client anytime a user from the ldap attempts to run
>>> vmplayer I start seeing entries in /var/log/messages about it trying
>>> to pull something from the ldap or passwd and it loops until it is
>>> killed.   The brightq software simply segfaults.  Using strace it
>>> appears to trying to resolve gid or uid numbers.  Local accounts can
>>> run either program with no problem.
>>>
>>> On any of the older clients there is not any problems with either
>>> program for ldap users.
>>>
>>> So I feel that something new is in place for Fedora 8 and I have
>>> overlooked what I need to configure or account for.  Selinux is
>>> turned off on all of the clients.
>>>
>>> Ideas/Suggestions?
>>
>>
>> Is the client that exhibits this problem an x86_64 machine, running an
>> x86_64 OS ? Are all the problems experienced by 32-bit applications? If
>> so, you probably need to check if you have a 32bit nss_ldap
>> installed ...
> Many Thanks.
>
> The brightq software is 32bit and the machines I am testing it on are
> also 32bit.  I am a little stumped as to the problem.  I was going
> through the access log on the directory server and it seems that the
> Fedora 8 is doing a whole lot of queries with the uidNumber.  Whereas
> the FC6 machine I was looking at seem to do more with the uid.  I wonder
> if there is something there that is causing some confusion like trying
> to find a memberuid that is numeric or something from the group container.
>
> I also have some 64bit machines that definitely have the vmplayer
> problem.  I checked those and yum says that nss_ldap.i386 and
> nss_ldap.x86_64 are installed.  Is there possibly some compatibility
> packeages that are necessary?
>
> I am stumped at this point, the OS commands like "id" all work fine,
> authentication and stuff is fine.
>
> Ideas / Suggestions?
>
> Thanks again!
>
>
>>
>>
>> Regards,
>> Buchan
>

--
Jim Summers
Computer Science - University of Oklahoma


Re: Segmentation Faults for Ldap Accounts

by Jim Summers :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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?

Thanks


Jim Summers wrote:

>
>
> Buchan Milne wrote:
>> On Thu, 2008-04-10 at 08:55 -0500, Jim Summers wrote:
>>> Hello All,
>>>
>>> I have encountered a problem that I think is related to nss_ldap or
>>> pam_ldap.
>>>
>>> I am using a fedora directory server for my authentication.  It is
>>> authenticating for RHEL4 and 5 and Fedora 5,6,8 clients.
>>>
>>> Everything is functioning as expected on all clients except for
>>> Fedora 8 clients.  The problem is related to two programs that my
>>> users run, vmplayer and brightq printing system from codehost.com for
>>> canon printers.
>>>
>>> On a Fedora 8 client anytime a user from the ldap attempts to run
>>> vmplayer I start seeing entries in /var/log/messages about it trying
>>> to pull something from the ldap or passwd and it loops until it is
>>> killed.   The brightq software simply segfaults.  Using strace it
>>> appears to trying to resolve gid or uid numbers.  Local accounts can
>>> run either program with no problem.
>>>
>>> On any of the older clients there is not any problems with either
>>> program for ldap users.
>>>
>>> So I feel that something new is in place for Fedora 8 and I have
>>> overlooked what I need to configure or account for.  Selinux is
>>> turned off on all of the clients.
>>>
>>> Ideas/Suggestions?
>>
>>
>> Is the client that exhibits this problem an x86_64 machine, running an
>> x86_64 OS ? Are all the problems experienced by 32-bit applications? If
>> so, you probably need to check if you have a 32bit nss_ldap
>> installed ...
> Many Thanks.
>
> The brightq software is 32bit and the machines I am testing it on are
> also 32bit.  I am a little stumped as to the problem.  I was going
> through the access log on the directory server and it seems that the
> Fedora 8 is doing a whole lot of queries with the uidNumber.  Whereas
> the FC6 machine I was looking at seem to do more with the uid.  I wonder
> if there is something there that is causing some confusion like trying
> to find a memberuid that is numeric or something from the group container.
>
> I also have some 64bit machines that definitely have the vmplayer
> problem.  I checked those and yum says that nss_ldap.i386 and
> nss_ldap.x86_64 are installed.  Is there possibly some compatibility
> packeages that are necessary?
>
> I am stumped at this point, the OS commands like "id" all work fine,
> authentication and stuff is fine.
>
> Ideas / Suggestions?
>
> Thanks again!
>
>
>>
>>
>> Regards,
>> Buchan
>

--
Jim Summers
Computer Science - University of Oklahoma


Re: Segmentation Faults for Ldap Accounts

by Andrew Morgan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

Re: Segmentation Faults for Ldap Accounts

by Buchan Milne-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Thursday 10 April 2008 23:51:58 Andrew Morgan wrote:

> 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.

Which could be avoided by using nscd ...

Regards,
Buchan

Re: Segmentation Faults for Ldap Accounts

by Jim Summers :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



Andrew Morgan wrote:

> 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.

Here is the output from ldd on the pjm ( brightq ) binary:

ldd pjm
         linux-gate.so.1 =>  (0x00110000)
         libutil.so.1 => /lib/libutil.so.1 (0x004be000)
         libnsl.so.1 => /lib/libnsl.so.1 (0x00a92000)
         libresolv.so.2 => /lib/libresolv.so.2 (0x00320000)
         libdl.so.2 => /lib/libdl.so.2 (0x00c90000)
         libXi.so.6 => /usr/lib/libXi.so.6 (0x00235000)
         libXext.so.6 => /usr/lib/libXext.so.6 (0x00136000)
         libX11.so.6 => /usr/lib/libX11.so.6 (0x00cd8000)
         libm.so.6 => /lib/libm.so.6 (0x00c65000)
         libc.so.6 => /lib/libc.so.6 (0x00b0a000)
         /lib/ld-linux.so.2 (0x00aeb000)
         libXau.so.6 => /usr/lib/libXau.so.6 (0x00cd3000)
         libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x00ccf000)
         libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00dd6000)
         libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00cc7000)

and from nss_ldap.so:

ldd libnss_ldap.so
         linux-gate.so.1 =>  (0x00110000)
         libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00167000)
         libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00180000)
         libssl.so.6 => /lib/libssl.so.6 (0x001ae000)
         libdl.so.2 => /lib/libdl.so.2 (0x001f3000)
         libnsl.so.1 => /lib/libnsl.so.1 (0x001f8000)
         libresolv.so.2 => /lib/libresolv.so.2 (0x00211000)
         libc.so.6 => /lib/libc.so.6 (0x00225000)
         libcrypt.so.1 => /lib/libcrypt.so.1 (0x0037e000)
         libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x003b0000)
         libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00443000)
         libcom_err.so.2 => /lib/libcom_err.so.2 (0x00469000)
         libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x0046c000)
         libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00475000)
         libcrypto.so.6 => /lib/libcrypto.so.6 (0x00478000)
         libz.so.1 => /lib/libz.so.1 (0x005ab000)
         /lib/ld-linux.so.2 (0x00aeb000)
         libselinux.so.1 => /lib/libselinux.so.1 (0x005be000)

Could it be that since pjm does not have any of the crypt, sasl, ssl stuff
compiled in, that it is getting something that is encrypted and can not handle
it correctly?  If so, how would this be remedied?

I think I am going to look and see if there are compat packages that may be
missing.

Ideas / Suggestions?

Thanks again

>
>     Andy

--
Jim Summers
School of Computer Science-University of Oklahoma
-------------------------------------------------

Re: Segmentation Faults for Ldap Accounts

by Andrew Morgan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Fri, 11 Apr 2008, Jim Summers wrote:

> Here is the output from ldd on the pjm ( brightq ) binary:
>
> ldd pjm
>        linux-gate.so.1 =>  (0x00110000)
>        libutil.so.1 => /lib/libutil.so.1 (0x004be000)
>        libnsl.so.1 => /lib/libnsl.so.1 (0x00a92000)
>        libresolv.so.2 => /lib/libresolv.so.2 (0x00320000)
>        libdl.so.2 => /lib/libdl.so.2 (0x00c90000)
>        libXi.so.6 => /usr/lib/libXi.so.6 (0x00235000)
>        libXext.so.6 => /usr/lib/libXext.so.6 (0x00136000)
>        libX11.so.6 => /usr/lib/libX11.so.6 (0x00cd8000)
>        libm.so.6 => /lib/libm.so.6 (0x00c65000)
>        libc.so.6 => /lib/libc.so.6 (0x00b0a000)
>        /lib/ld-linux.so.2 (0x00aeb000)
>        libXau.so.6 => /usr/lib/libXau.so.6 (0x00cd3000)
>        libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x00ccf000)
>        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00dd6000)
>        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00cc7000)
>
> and from nss_ldap.so:
>
> ldd libnss_ldap.so
>        linux-gate.so.1 =>  (0x00110000)
>        libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00167000)
>        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00180000)
>        libssl.so.6 => /lib/libssl.so.6 (0x001ae000)
>        libdl.so.2 => /lib/libdl.so.2 (0x001f3000)
>        libnsl.so.1 => /lib/libnsl.so.1 (0x001f8000)
>        libresolv.so.2 => /lib/libresolv.so.2 (0x00211000)
>        libc.so.6 => /lib/libc.so.6 (0x00225000)
>        libcrypt.so.1 => /lib/libcrypt.so.1 (0x0037e000)
>        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x003b0000)
>        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00443000)
>        libcom_err.so.2 => /lib/libcom_err.so.2 (0x00469000)
>        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x0046c000)
>        libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00475000)
>        libcrypto.so.6 => /lib/libcrypto.so.6 (0x00478000)
>        libz.so.1 => /lib/libz.so.1 (0x005ab000)
>        /lib/ld-linux.so.2 (0x00aeb000)
>        libselinux.so.1 => /lib/libselinux.so.1 (0x005be000)
>
> Could it be that since pjm does not have any of the crypt, sasl, ssl stuff
> compiled in, that it is getting something that is encrypted and can not
> handle it correctly?  If so, how would this be remedied?

Those look fine to me, unless pjm is dynamicly loading an SSL library.

> I think I am going to look and see if there are compat packages that may be
> missing.
>
> Ideas / Suggestions?

What about turning off SSL in nss-ldap temporarily?  That could narrow the
problem down.  Also, you could run strace on pjm and see which system call
actually segfaults it.

  Andy

Re: Segmentation Faults for Ldap Accounts

by Jim Summers :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



Andrew Morgan wrote:

> On Fri, 11 Apr 2008, Jim Summers wrote:
>
>> Here is the output from ldd on the pjm ( brightq ) binary:
>>
>> ldd pjm
>>        linux-gate.so.1 =>  (0x00110000)
>>        libutil.so.1 => /lib/libutil.so.1 (0x004be000)
>>        libnsl.so.1 => /lib/libnsl.so.1 (0x00a92000)
>>        libresolv.so.2 => /lib/libresolv.so.2 (0x00320000)
>>        libdl.so.2 => /lib/libdl.so.2 (0x00c90000)
>>        libXi.so.6 => /usr/lib/libXi.so.6 (0x00235000)
>>        libXext.so.6 => /usr/lib/libXext.so.6 (0x00136000)
>>        libX11.so.6 => /usr/lib/libX11.so.6 (0x00cd8000)
>>        libm.so.6 => /lib/libm.so.6 (0x00c65000)
>>        libc.so.6 => /lib/libc.so.6 (0x00b0a000)
>>        /lib/ld-linux.so.2 (0x00aeb000)
>>        libXau.so.6 => /usr/lib/libXau.so.6 (0x00cd3000)
>>        libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x00ccf000)
>>        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00dd6000)
>>        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00cc7000)
>>
>> and from nss_ldap.so:
>>
>> ldd libnss_ldap.so
>>        linux-gate.so.1 =>  (0x00110000)
>>        libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00167000)
>>        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00180000)
>>        libssl.so.6 => /lib/libssl.so.6 (0x001ae000)
>>        libdl.so.2 => /lib/libdl.so.2 (0x001f3000)
>>        libnsl.so.1 => /lib/libnsl.so.1 (0x001f8000)
>>        libresolv.so.2 => /lib/libresolv.so.2 (0x00211000)
>>        libc.so.6 => /lib/libc.so.6 (0x00225000)
>>        libcrypt.so.1 => /lib/libcrypt.so.1 (0x0037e000)
>>        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x003b0000)
>>        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00443000)
>>        libcom_err.so.2 => /lib/libcom_err.so.2 (0x00469000)
>>        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x0046c000)
>>        libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00475000)
>>        libcrypto.so.6 => /lib/libcrypto.so.6 (0x00478000)
>>        libz.so.1 => /lib/libz.so.1 (0x005ab000)
>>        /lib/ld-linux.so.2 (0x00aeb000)
>>        libselinux.so.1 => /lib/libselinux.so.1 (0x005be000)
>>
>> Could it be that since pjm does not have any of the crypt, sasl, ssl
>> stuff compiled in, that it is getting something that is encrypted and
>> can not handle it correctly?  If so, how would this be remedied?
>
> Those look fine to me, unless pjm is dynamicly loading an SSL library.
>
>> I think I am going to look and see if there are compat packages that
>> may be missing.
>>
>> Ideas / Suggestions?
>
> What about turning off SSL in nss-ldap temporarily?  That could narrow
> the problem down.  Also, you could run strace on pjm and see which
> system call actually segfaults it.

I turned off ssl and the pjm program worked.  Turned it back on and the
pjm segfaults.

Here is my ldap.conf, which is also the same as the one on the FC5 and
FC6 clients:

uri ldaps://server1 ldaps://server2
base dc=ou,dc=edu
binddn cn=bind0,ou=profile,dc=ou,dc=edu
bindpw ++++++++
port 636
#port 389
#idle_timelimit 3600
ssl on
tls_checkpeer no
pam_password crypt
pam_lookup_policy yes
#debug 1

I am not sure what to look for in my ssl/tls setup.  The whole thing is
running off of self-signed certificates.

Thanks again!


>
>     Andy

--
Jim Summers
Computer Science - University of Oklahoma


Re: Segmentation Faults for Ldap Accounts

by Andrew Morgan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Fri, 11 Apr 2008, Jim Summers wrote:

>> What about turning off SSL in nss-ldap temporarily?  That could narrow the
>> problem down.  Also, you could run strace on pjm and see which system call
>> actually segfaults it.
>
> I turned off ssl and the pjm program worked.  Turned it back on and the pjm
> segfaults.
>
> Here is my ldap.conf, which is also the same as the one on the FC5 and FC6
> clients:
>
> uri ldaps://server1 ldaps://server2
> base dc=ou,dc=edu
> binddn cn=bind0,ou=profile,dc=ou,dc=edu
> bindpw ++++++++
> port 636
> #port 389
> #idle_timelimit 3600
> ssl on
> tls_checkpeer no
> pam_password crypt
> pam_lookup_policy yes
> #debug 1
>
> I am not sure what to look for in my ssl/tls setup.  The whole thing is
> running off of self-signed certificates.

Can you run your pjm program under strace?  Something like:

   strace -ff -o /tmp/trace pjm <args>

I can help look at the trace files, if you don't know what to look for.

  Andy

Re: Segmentation Faults for Ldap Accounts

by Jim Summers :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



Andrew Morgan wrote:

> On Fri, 11 Apr 2008, Jim Summers wrote:
>
>>> What about turning off SSL in nss-ldap temporarily?  That could
>>> narrow the problem down.  Also, you could run strace on pjm and see
>>> which system call actually segfaults it.
>>
>> I turned off ssl and the pjm program worked.  Turned it back on and
>> the pjm segfaults.
>>
>> Here is my ldap.conf, which is also the same as the one on the FC5 and
>> FC6 clients:
>>
>> uri ldaps://server1 ldaps://server2
>> base dc=ou,dc=edu
>> binddn cn=bind0,ou=profile,dc=ou,dc=edu
>> bindpw ++++++++
>> port 636
>> #port 389
>> #idle_timelimit 3600
>> ssl on
>> tls_checkpeer no
>> pam_password crypt
>> pam_lookup_policy yes
>> #debug 1
>>
>> I am not sure what to look for in my ssl/tls setup.  The whole thing
>> is running off of self-signed certificates.
>
> Can you run your pjm program under strace?  Something like:
>
>   strace -ff -o /tmp/trace pjm <args>
>
> I can help look at the trace files, if you don't know what to look for.

Here is a snip from an strace of the fedora 8 machine where pjm fails:
===
fcntl64(4, F_GETFL)                     = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(4, F_SETFL, O_RDWR)             = 0
open("/usr/share/locale/locale.alias", O_RDONLY) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=2528, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x111000
read(5, "# Locale name alias data base.\n#"..., 4096) = 2528
read(5, "", 4096)                       = 0
close(5)                                = 0
munmap(0x111000, 4096)                  = 0
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No
such file or directory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
===

and then from the FC6 where pjm works:
===
fcntl64(4, F_GETFL)                     = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(4, F_SETFL, O_RDWR)             = 0
open("/usr/share/locale/locale.alias", O_RDONLY) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=2528, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x251000
read(5, "# Locale name alias data base.\n#"..., 4096) = 2528
read(5, "", 4096)                       = 0
close(5)                                = 0
munmap(0x251000, 4096)                  = 0
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No
such file or directory)
brk(0x9cd2000)                          = 0x9cd2000
time(NULL)                              = 1207971400
write(2, "TLS trace: SSL_connect:before/co"..., 53) = 53
time(NULL)                              = 1207971400
open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 5
fstat64(5, {st_mode=S_IFCHR|0444, st_rdev=makedev(1, 9), ...}) = 0
===

I agree with you it still is appearing to be something with TLS/ssl.  It is
just confusing me that the operating system itself authenticates and can
resolve uidNumbers and group info fine.

Let me know if you need the whole trace file and I can send that also.

Ideas / Suggestions?

Thanks again

>
>     Andy

--
Jim Summers
School of Computer Science-University of Oklahoma
-------------------------------------------------

Re: Segmentation Faults for Ldap Accounts

by Andrew Morgan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Mon, 14 Apr 2008, Jim Summers wrote:

> I agree with you it still is appearing to be something with TLS/ssl.  It is
> just confusing me that the operating system itself authenticates and can
> resolve uidNumbers and group info fine.
>
> Let me know if you need the whole trace file and I can send that also.

Sure, I'd like to look at both trace files in full.

  Andy

Re: Segmentation Faults for Ldap Accounts

by Jim Summers :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello All,

I wanted to close this thread.

It was recommended that I try the nscd.  Got that activated and now all
is well.

Many thanks to all!



Andrew Morgan wrote:

> On Mon, 14 Apr 2008, Jim Summers wrote:
>
>> I agree with you it still is appearing to be something with TLS/ssl.  
>> It is just confusing me that the operating system itself authenticates
>> and can resolve uidNumbers and group info fine.
>>
>> Let me know if you need the whole trace file and I can send that also.
>
> Sure, I'd like to look at both trace files in full.
>
>     Andy

--
Jim Summers
Computer Science - University of Oklahoma