kerberos & cron - specifically nfsv4 w/sec=krb5p

Frank Cusack frank at linetwo.net
Tue Sep 18 16:20:22 EDT 2012


On Tue, Sep 18, 2012 at 12:43 PM, Matt Garman <matthew.garman at gmail.com>wrote:

> Isn't the above path stuff kind of pointless anyway, since I can use
> -k -t <file> with kinit at the user level?  Which I have to do anyway,
> from within cron?
>

yeah, whoops.  I was thinking keytab but actually rpc.gssd wants a
credential cache.

One thing that can happen is if the rpc.gssd credential path is the same as
the system credential path, and you have session-based credentials for
sshd, then when you logout of sshd your ccache gets removed.  Then later on
(cron) when rpc.gssd needs them again, it can't find them.

Since you are initializing the ccache in the crontab itself, first of all
make sure your kinit command is placing the ccache in the correct (for
gssd) location.  If that's fine (log the output of klist somewhere to be
sure) then you are going to have to debug gssd.  You can run it in the
foreground in another window and see why it is failing.  Sounds like this
happens quickly so you'll be able to iterate quickly.  You can set your
ticket lifetime down to 1 minute to make it go faster.

You won't be able to debug correctly if your interactive (for debug) login
requires krb5 NFS, because there is only a single NFS auth token per user
per server.  That is, the krb5 creds are not per-session.  So your
interactive session, which works, will mask the cron problems.  You'll need
to run gssd as root anyway so login directly as root (not user login then
su/sudo) to avoid this problem.

These problems are usually due to gssd on the client side, so you should be
positive that is working before going on to more exotic stuff like idmapd.


More information about the Kerberos mailing list