I saw your other follow-up, but just to close out a few things with this
thread
Kristen Webb writes:
> On Tue, Sep 25, 2018 at 3:11 PM Russ Allbery 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?
Ah, I see.
The needed changes would seem to be in the OpenAFS client software,
to have the logic to update to using a new token (if available) when
the current one is close to expiry, and in the AFS server software to
issue a fresh challenge when the client's credential is expiring
(instead of jus
Hi Ben,
Thank you for the comment. We have always used -localauth on the backup
server with cell keys,
and even multiple cell keys for multiple cells to do just that. We are
migrating to
kerberos principals so that the cell keys are not required on our backup
servers.
Mostly for security reasons.
Hi Kristen,
I think I missed some of the thread, but I'll note that the token used by
'vos dump -localauth' never expires.
-Ben
On Mon, Oct 08, 2018 at 02:15:11PM -0600, Kristen Webb wrote:
> Hi Everyone,
>
> Thank you all for the online and offline responses. Unfortunately, as I
> have learne
Hi Everyone,
Thank you all for the online and offline responses. Unfortunately, as I
have learned,
k5start or any other mechanism will not keep a vos dump moving beyond the
inital
lifetime grated to the token controlled by the kerberos configuration. So,
for example,
if I want a 1 week lifetime
Thanks for the feedback, Russ
On Tue, Sep 25, 2018 at 3:11 PM Russ Allbery wrote:
> Kristen Webb writes:
>
> > When I use the -k ccache option it appears that each job simply
> > overwrites the cchache file.
>
> It should only do this if the ticket is going to expire sooner than two
> minutes be
Kristen Webb writes:
> When I use the -k ccache option it appears that each job simply
> overwrites the cchache file.
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
I am trying to add k5start to a custom vos routine to automate dump/restore.
My current solution is a traditional klist/kinit/aklog, but has a problem
with the
tokens timing out before a large (multi-day) job can complete.
I want to use a shared credential cache to reduce the traffic to the
kerbe
