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 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 for very long running jobs as tibs@REALM I need > to set: > > 1. In kdc.conf or equivalent: > > max_life = 168h 0m 0s > > 2. Set all the appropriate max lifetimes in the KDB (modprinc -maxlife > 168hours) > > krbtgt/REALM > backup_admin@REALM > afs/cell@REALM > > Then kinit/aklog is sufficient, k5start is nice for dealing with CCACHE > names, but will > not keep things running any longer. Someone mentioned GSSproxy. I have > not had > time to look at this closer, but I suspect it may not help with the vos > command in particular. > > Kris > > > On Tue, Sep 25, 2018 at 3:11 PM Russ Allbery <ea...@eyrie.org> wrote: > > > Kristen Webb <kw...@teradactyl.com> 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 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. > > > > > Is there a way to use k5start to achieve what I am after > > > - shared ccache for many jobs to keep kerberos server traffic down > > > - allow long running jobs to continue beyond their initial aklog > > > renewal date > > > > > If I ran k5start as a daemon and managed periodic aklog's within my > > > application, would that work? > > > > Yes, that's what I was going to suggest. If each application is running > > in a separate PAG, each application needs to run aklog periodically > > independently of the others. If you also want to share a single ticket > > cache among the applications, you probably want to split those two > > operations. > > > > Unfortunately, k5start doesn't currently have a mode of operation in which > > it only runs the aklog command but doesn't try to renew tickets if they > > aren't about to expire. > > > > -- > > Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> > > > > > -- > This message is NOT encrypted > -------------------------------- > Mr. Kristen J. Webb > Chief Technology Officer > Teradactyl LLC. > 2450 Baylor Dr. S.E. > Albuquerque, New Mexico 87106 > Phone: 1-505-338-6000 > Email: kw...@teradactyl.com > Web: http://www.teradactyl.com > > > > Providers of Scalable Backup Solutions > for Unique Data Environments > > -------------------------------- > NOTICE TO RECIPIENTS: Any information contained in or attached to this > message is intended solely for the use of the intended recipient(s). If > you are not the intended recipient of this transmittal, you are hereby > notified that you received this transmittal in error, and we request > that you please delete and destroy all copies and attachments in your > possession, notify the sender that you have received this communication > in error, and note that any review or dissemination of, or the taking of > any action in reliance on, this communication is expressly prohibited. > > > Regular internet e-mail transmission cannot be guaranteed to be secure > or error-free. Therefore, we do not represent that this information is > complete or accurate, and it should not be relied upon as such. If you > prefer to communicate with Teradactyl LLC. using secure (i.e., encrypted > and/or digitally signed) e-mail transmission, please notify the sender. > Otherwise, you will be deemed to have consented to communicate with > Teradactyl via regular internet e-mail transmission. Please note that > Teradactyl reserves the right to intercept, monitor, and retain all > e-mail messages (including secure e-mail messages) sent to or from its > systems as permitted by applicable law > ________________________________________________ > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
