* Gasper Zejn ([EMAIL PROTECTED]) wrote:
> [pid 5186] connect(7, {sa_family=AF_INET,
> sin_port=htons(389), sin_addr=inet_addr("10.10.7.99")}, 16)
> = -1 ENETUNREACH (Network is unreachable)
>
> clearly means network is not setup properly to be able to
> reach LDAP server, since there's no matching route.
>
> The 'getent passwd' command also blocks, while waiting for
> response from unavailable LDAP server. The old libnss-ldap
> returned immediately.
>
> That's why I think this is a bug in libnss-ldap, not in udev.
The problem is that the LDAP library doesn't come back with "Network is
unreachable", it comes back with "LDAP_UNAVAILABLE" or
"LDAP_SERVER_DOWN", in either case it might be a transient error (LDAP
server is being restarted, temporary network hiccup, etc) and you
wouldn't want to fail right away for that (if you do, configure
libnss-ldap to have 'bind_policy soft').
I've been looking into a way for libnss-ldap to be able to tell if the
error was 'network unreachable' but it's not as easy as one might hope.
Additionally, when the local server *is* the LDAP server in question
you're not going to get a 'network unreachable' but rather a 'port
closed' or similar error and I'm not sure how you'd differentiate that
from someone restarting the server and it being down for a second.
I'm starting to think it might make sense to essentially check for
'boot-still-in-progress' and just fail requests until the system is
fully booted to a point where most daemons have been started (in case
the LDAP server is the local slapd) and networking should be available
(if it's going to end up being available at all). This would
essentially *force* anything during boot to be available via files, but
I don't really think that's unreasonable.
Thoughts?
Thanks,
Stephen
signature.asc
Description: Digital signature
