The problem is that this is a catch-22.
KDC first. There's no good ordering that works for all cases.
Well, probably not for all cases, but we might do better as we do now:
Kerberos is unlikely to retrieve any authentication info from any other
database. It may require DNS - e.g. to resolve the LDAP host.
Bind will have a hard time using LDAP as backend while using Kerberos
for the bind, since it would not have the KDC text entries, before it is up.
LDAP is unlikely to authenticate to anything (except for replication
cases). Hostnames required at start-up refer to itself and can therefore
be considered to exist in /etc/hosts.
So LDAP, BIND, Kerberos should catch most setups. But of course the
world is larger than that. :)
What probably should happen is that krb5kdc should keep retrying the LDAP
server for a while rather than giving up and exiting.
Yes, that would be a fix ...
(I personally have no idea on the krb524d problems, unfortunately.)
I made a little progress. The connections are created in
kadm5_flush(handle) at line 253 in krb524d.c. For some reason gdb does
not follow that call (built with export
DEB_BUILD_OPTIONS=debug,noopt,nostrip) - hmm, according to readelf the
library has no debugging symbols. Seems like debian/rules does not heed
debug,nostrip for the libs.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
