On Mon, Jul 03, 2006 at 11:55:47AM -0400, Stephen Frost wrote:
> * Vedran Fura? ([EMAIL PROTECTED]) wrote:
> > Stephen Frost wrote:
> > > What do your configs look like,
>
> What are the permissions on your libnss-ldap.conf?
-rw-r--r-- 1 root root 1225 Jul 3 18:07 /etc/libnss-ldap.conf
As downgrading the package helps i doubt it's a configuration problem.
> More would be nice... I'm really curious where the original file
> descriptor '7' is coming from... Based on the getpeername() call it
> *looks* like that should be an existing connection to the LDAP server,
> which is then closed (perhaps because it doesn't think that connection
> is to the right server, or something...).
Enabling debug in my libnss-ldap reveals the following:
ldap_create
ldap_url_parse_ext(ldaps://apollo.ipv4.spacelabs.nl)
ldap_create
ldap_url_parse_ext(ldaps://apollo.ipv4.spacelabs.nl)
ldap_simple_bind
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection
ldap_int_open_connection
ldap_connect_to_host: TCP apollo.ipv4.spacelabs.nl:636
ldap_new_socket: 11
ldap_prepare_socket: 11
ldap_connect_to_host: Trying 192.87.65.33:636
ldap_connect_timeout: fd: 11 tm: 30 async: 0
ldap_ndelay_on: 11
ldap_is_sock_ready: 11
ldap_ndelay_off: 11
ldap_int_sasl_open: host=apollo.ipv4.spacelabs.nl
tls_write: want=73, written=73
0000: 16 03 01 00 44 01 00 00 40 03 01 44 a9 40 ca 60 [EMAIL
PROTECTED]@Ê`
<lots of tls_ and ber_ stuff>
ber_scanf fmt ([v]) ber:
ber_dump: buf=0x005e7850 ptr=0x005e78d6 end=0x005e796b len=149
0000: 31 0a 04 08 2f 62 69 6e 2f 7a 73 68 30 0e 04 02 1.../bin/zsh0...
0010: 63 6e 31 08 04 06 73 6a 6f 65 72 64 30 1b 04 05 cn1...sjoerd0...
0020: 67 65 63 6f 73 31 12 04 10 53 6a 6f 65 72 64 20 gecos1...Sjoerd
0030: 53 69 6d 6f 6e 73 2c 2c 2c 30 13 04 09 67 69 64 Simons,,,0...gid
0040: 4e 75 6d 62 65 72 31 06 04 04 32 30 30 31 30 0f Number1...20010.
0050: 04 03 75 69 64 31 08 04 06 73 6a 6f 65 72 64 30 ..uid1...sjoerd0
0060: 1f 04 0d 68 6f 6d 65 44 69 72 65 63 74 6f 72 79 ...homeDirectory
0070: 31 0e 04 0c 2f 68 6f 6d 65 2f 73 6a 6f 65 72 64 1.../home/sjoerd
0080: 30 13 04 09 75 69 64 4e 75 6d 62 65 72 31 06 04 0...uidNumber1..
0090: 04 32 30 30 31 .2001
ldap_msgfree
ldap_free_connection
ldap_free_connection: actually freed
ldap_free_connection
ldap_free_connection: actually freed
/home/sjoerd/.zshrc:26: parse error: condition expected: =
ldap_free_connection
ldap_free_connection: actually freed
ldap_free_connection
ldap_free_connection: actually freed
/home/sjoerd/.zshrc:65: parse error: condition expected: =
ldap_free_connection
ldap_free_connection: actually freed
ldap_free_connection
ldap_free_connection: actually freed
/home/sjoerd/.zlogin:8: parse error: condition expected: =
After that each commands just outputs:
$ /bin/echo a
ldap_free_connection
ldap_free_connection: actually freed
If you want more specific data let me know.. stracing something in that shell
later on shows that the getpeername and getsockname are done on fd 11, which
was allocated by libnss-ldap (as can be seen in the trace above).
> Does your URI in your libnss-ldap.conf resolve to multiple different IP
> addresses? What if you used multiple URIs which resolve to only a
> single address?
That was the case, but i've changed that to just one specific host and it
reveals no changes in behaviour.
Sjoerd
--
If the facts don't fit the theory, change the facts.
-- Albert Einstein
