issue with k5start

[Russ Allbery]

I saw your other follow-up, but just to close out a few things with this
thread....

Kristen Webb <kwebb at teradactyl.com> writes:
> On Tue, Sep 25, 2018 at 3:11 PM Russ Allbery <eagle at eyrie.org> wrote:

>> It should only do this if the ticket is going to expire sooner than two
>> minutes before the next wake-up period, though, I think?  I would have
>> expected this to work with all jobs sharing the same cache file, as
>> long as they're at least a little staggered.  That said, I don't think
>> I've really tested for this sort of parallelism, and it's entirely
>> possible that the separate k5start processes don't manage coordination
>> between each other on the same ticket cache properly.

> The only control I can find for the CC is the -a flag, which always
> renews tickets when k5start wakes up.  It looks like k5start always
> inits the CC on startup.

Oh, yes.  That's true.

> This works for most cases.  However, when a new job starts near the time
> a TGT is ready to be renewed, it's afs token lifetime can be quite short
> and can expire before a planned re-aklog within that PAG.

Yes, you have to arrange the timings such that the minimum remaining
lifetime of the TGT is always above the minimum length of a token that you
need.  This should be possible with the right set of flags, but it won't
avoid the initialization of the cache on startup.

> This is similar to what I am trying to do manually.  It would appear
> that k5start might be capable of doing this, and I would be interested
> in trying to help implement this feature.

I've added this to TODO, for the record, although I haven't had much time
to work on kstart in the last few years.

 * Add a mode of operation that only runs the aklog program and doesn't
   attempt to refresh the ticket cache unless it's about to expire.  This
   would allow multiple k5start daemons to use the same ticket cache
   without putting a lot of load on the Kerberos KDC for constant renewals
   from each daemon.

-- 
Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>