[35722] in Kerberos
Re: k5start -K and ticket renewals
daemon@ATHENA.MIT.EDU (Russ Allbery)
Thu Jan 30 00:18:31 2014
From: Russ Allbery <eagle@eyrie.org>
To: kerberos@mit.edu
In-Reply-To: <6F5E7E7B63E8FD478D35456B2BBFB70A132835B6@NLDNC101PEX1.ubsw.net>
(moritz willers's message of "Tue, 28 Jan 2014 11:10:45 -0000")
Date: Wed, 29 Jan 2014 21:18:18 -0800
Message-ID: <87ha8mqc85.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
<moritz.willers@ubs.com> writes:
> I like this much better than -K implying to constantly fetch new
> tickets. On one host it may be ok to change the -K behaviour; but if you
> are running k5start on thousands or ten thousands of hosts, the
> multiplying factor cannot be neglected. It may also be very intentional
> to only refresh the ticket once a day but check regularly that it didn't
> get lost by accident.
Okay, I think I'm hearing enough opposition to the plan to just change -K
that I'm going to go with the previous plan of adding a new -a option that
says to renew the ticket each time it wakes up. I'm also going to support
using -H with -K, where -H is the minimum ticket lifetime and the renewal
decision will be based on maintaining at least that minimum ticket
lifetime.
> If the behaviour is changing and k5start refresh the ticket more
> regularly, then the updating of the CC must always be atomic. If I
> remember correctly, this is right now only the case if -o, -g or -m are
> specified.
I think this is true regardless, and I'm tentatively planning on changing
k5start to always obtain tickets in a new ticket cache file and then
rename it over top of the existing ticket cache in the next release.
--
Russ Allbery (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
