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 just aborting the connection). And rxgk is probably a higher priority for OpenAFS at the moment...
-Ben On Tue, Oct 09, 2018 at 10:46:34PM -0600, Kristen Webb wrote: > 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. > > On Tue, Oct 9, 2018 at 7:07 PM Benjamin Kaduk <ka...@mit.edu> wrote: > > > 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 > > > > > -- > 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
