> (I personally have no idea on the krb524d problems, unfortunately.)
I just produced a strace. I do not post it here, it's got 3111 syscalls
for a single call to kadm_flush() according to ltrace. But from small
portions it's clear that something wicked is happening:
hel:/# grep shutdown /tmp
Lars Hanke writes:
> LDAP is unlikely to authenticate to anything (except for replication
> cases).
Replication cases are a very common LDAP server installation, no?
Certainly they're far more common than KDCs that use LDAP, which are as
yet highly unusual.
> I made a little progress. The conne
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 resolv
Lars Hanke writes:
> I guess the first two entries are the reason, why the autostart
> fails. After a short look to /etc/rc3.d this is clear: S18krb5-kdc,
> S19slapd (same problems would arise with bind9 and LDAP backend). Is this
> something to report to the LDAP maintainers?
The problem is tha
Ah, forgot to add some logs:
/var/log/syslog | grep krb5 (for the time writing the bug report):
Jan 9 20:34:56 hel krb5kdc[354]: Unable to access Kerberos database -
while initializing database for realm MGR
Jan 9 20:34:56 hel krb5kdc[354]: Unable to access Kerberos database -
while initiali
5 matches
Mail list logo
