[OpenAFS] Re: aklog carps Couldn't determine realm of user

Ted Creedon tcreedon@easystreet.net
Fri, 23 Dec 2016 00:46:19 +0000

FILE:/tmp/krb5cc_0 not =3D /run/user/0/krb5cc/tkt  not=3D to krb5cc/primary

klist -A
Credentials cache: FILE:/tmp/krb5cc_0
        Principal: admin@CREEDON.BIZ
aklog carps about missing /run/user/0/krb5cc/tkt
its krb5cc/primary that exists

tree /run/user/0/
|-- KSMserver__0
|-- dconf
|   `-- user
|-- gvfs
|-- kdeinit5__0
|-- klauncherTJ3534.1.slave-socket
|-- krb5cc
|   `-- primary
|-- pulse
`-- systemd
    |-- notify
    `-- private

5 directories, 7 files

From: Benjamin Kaduk <kaduk@mit.edu>
Sent: Thursday, December 22, 2016 3:58:31 PM
To: Ted Creedon
Cc: openafs-info@openafs.org
Subject: Re: [OpenAFS] Re: aklog carps  Couldn't determine realm of user

On Thu, Dec 22, 2016 at 11:42:41PM +0000, Ted Creedon wrote:
> different outcome w/ 7.1.0 but no tokens from eiher afslog or aklog (stil=
l carps about
> /run/user/0/krb5cc/tkt", O_RDONLY) =3D -1 ENOENT)

Ah, this is a "fancy" default coming into play, no doubt.  /run/user may
be isolated for various users with filesystem namespaces to prevent
cross-user attacks (though I guess that may not be coming into play here).
I also recall issues where the /run/user/<uid>/krb5cc/ directory was
not created automatically, so check that it exists.

> ookpik:/data1/openafs-1.8.0pre1 # kinit -afslog admin
> admin@CREEDON.BIZ's Password:
> ookpik:/data1/openafs-1.8.0pre1 # klist -AT
> Credentials cache: FILE:/tmp/krb5cc_0
>         Principal: admin@CREEDON.BIZ
>   Issued                Expires               Principal
> Dec 22 15:33:01 2016  Jun 23 07:32:57 2017  krbtgt/CREEDON.BIZ@CREEDON.BI=
> Dec 22 15:33:01 2016  Jun 23 07:32:57 2017  afs/creedon.biz@CREEDON.BIZ

Okay, now the kerberos part is succeeding, so any issue here is on the AFS =

> Dec 22 15:33:01 201  Jun 23 07:32:57 201  Tokens for creedon.biz
> ##################
> aklog
> aklog: Couldn't determine realm of user:aklog: unknown RPC error (-176532=
8189)  while getting realm

This seems to suggest that aklog -noprdb might succeed.

> #####
> open("/run/user/0/krb5cc/tkt", O_RDONLY) =3D -1 ENOENT (No such file or d=

There are two ticket caches in play here, which can be confusing to both hu=
(i.e., me) and software.  Is KRB5CCNAME modified between any of the pasted =
you have given here?  Did you consciously try to set either /run/user/0/krb=
or FILE:/tmp/krb5cc_0?

Is aklog linked against a heimdal or MIT libkrb5?
Please provide any /etc/krb5.conf declarations relating to names of credent=

I don't think it's particularly helpful to be randomly trying different ver=
of the software; I would rather get good solid debugging output from a spec=
setup and understand what is failing, so that software changes can be targe=
instead of "shotgun style".