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