This one time, at band camp, Steinar H. Gunderson said: > On Thu, Aug 31, 2006 at 07:42:03PM -0600, Berg, Michael wrote: > > A low entropy pool may be a contributing factor, but something definitely > > changed between libnss-ldap 238 and 251. > > I guess this is the new reconnection logic introduced in 241. > > > With libnss-ldap 238-1.2 installed > > > > $ cat /proc/sys/kernel/random/entropy_avail; \ > > getent passwd user_in_ldap; \ > > cat /proc/sys/kernel/random/entropy_avail > > 3585 > > passwd entry here > > 129 > > Are you sure it's not falling back to non-TLS here? Or local files somehow? I > can't see a reason why it would fail any better than 251, given that a > failure is still a failure and the relevant change is what it does after the > fact...
strace'ing a login on a machine using ldaps showed the original connection
being closed, a new soket being created but not conencted, and then a
write on the unconnected descriptor, followed shortly by total failure.
[pid 16168] getsockname(11, <unfinished ...>
[pid 16168] <... getsockname resumed> {sa_family=AF_INET6,
sin6_port=htons(50617), inet_pton(AF_INET6,
"2001:610:1118:0:230:1bff:feba:218e", &sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, [28]) = 0
[pid 16168] getpeername(11, {sa_family=AF_INET6, sin6_port=htons(636),
inet_pton(AF_INET6, "2001:610:1118:0:210:5aff:fe64:a300", &sin6_addr),
sin6_flowinfo=0, sin6_scope_id=0}, [120259084316]) = 0
[pid 16168] fcntl(11, F_GETFD) = 0x1 (flags FD_CLOEXEC)
[pid 16168] dup(11) = 5
[pid 16168] fcntl(5, F_SETFD, FD_CLOEXEC) = 0
[pid 16168] socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6
[pid 16168] close(11) = 0
[pid 16168] fcntl(6, F_GETFD) = 0
[pid 16168] dup2(6, 11) = 11
[pid 16168] fcntl(11, F_SETFD, 0) = 0
[pid 16168] close(6) = 0
...
[pid 16168] write(11,
"\25\3\1\0\300|\21/\237$\226\3269\f\222\25\215\313\302\353"..., 197) = -1 EPIPE
(Broken pipe)
There is no connect() call in the elided bit.
tcpdump showed no traffic at all (not surprising, given that the socket
was unconnected), but it appears to be tls encrypted data in the output
above. The failure is the same for ipv4 connections (unsurprisingly
again - you still need connect no matter what address scheme you use).
I am assuming there's a bug somewhere in the reconnect logic, but I
haven't yet been able to spot it. Debugging nss functions is rather
painful :(
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : [EMAIL PROTECTED] |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
signature.asc
Description: Digital signature
