On Thu, 31 Jul 2014, Marcus Crestani wrote:
When using aklog (OpenAFS-1.6.6) on OS X 10.9.4 without an AFS service principal in the ticket cache, e.g.# klist Credentials cache: API:F46BD8F1-7C3C-43F9-835B-9D9692183AC2 Principal: [email protected] Issued Expires Principal Jul 31 10:47:31 2014 Aug 1 11:47:31 2014 krbtgt/[email protected] aklog fails: # aklog -d Authenticating to cell informatik.uni-tuebingen.de (server afsdb1.informatik.uni-tuebingen.de). Trying to authenticate to user's realm INFORMATIK.UNI-TUEBINGEN.DE. Getting tickets: afs/[email protected] We've deduced that we need to authenticate to realm INFORMATIK.UNI-TUEBINGEN.DE. Getting tickets: afs/[email protected] Getting tickets: afs/[email protected] Getting tickets: [email protected] Kerberos error code returned by get_cred : -1765328324 aklog: Couldn't get informatik.uni-tuebingen.de AFS tickets: aklog: unknown RPC error (-1765328324) while getting AFS tickets
That is, of course, KRB5KRB_ERR_GENERIC, which is very ... generic.
According to aklog's debugging output above, aklog tries to obtain AFS service tickets from the KDC. But we do not see any connection attempt in our KDC's log file from aklog on OS X. (We do see that aklog successfully asks and receives tickets from the KDC on our Linux machines, for example.) When we already have an AFS service principal in the ticket cache, aklog works fine. Why does aklog on OS X not try to obtain tickets from the KDC? Is this a known issue? Or is this a problem in our setup?
I can't say that I have direct experience with this issue on OS X, but I will note that on my FreeBSD machines (which also use a Heimdal variant for krb5, thougha different version than OS X), libkrb5 is pretty insistent on using DNS queries to lookup which machine(s) are the KDC for the realm in question. In the case of my test cell of VMs on my laptop, there are no DNS entries for the names I have given them, so operations such as aklog just hang for several seconds and report failure.
I would suggest monitoring what DNS queries are being made; it may prove helpful.
-Ben _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
