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 kerberos server (thousands and thousands of backup jobs with say one kinit/day). When I use the -k ccache option it appears that each job simply overwrites the cchache file. Without out it, each job appears to keep it's own/private ccache data. I suppose this makes sense since k5start needs to know when to renew tickets/tokens based on when each job starts when run with the command option. 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? -- 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: [hidden email] 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 [hidden email] https://mailman.mit.edu/mailman/listinfo/kerberos |
Kristen Webb <[hidden email]> 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 ([hidden email]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/kerberos |
Thanks for the feedback, Russ
On Tue, Sep 25, 2018 at 3:11 PM Russ Allbery <[hidden email]> wrote: > Kristen Webb <[hidden email]> 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. > tickets when k5start wakes up. It looks like k5start always inits the CC on startup. > > > 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. 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. It seems that the only way around this is for each job to know when the shared TGT is really going to expire so it can plan/init accordingly at least the first aklog. I cannot seem to find an easy command line function for determining the remaining lifetime. The closest I have found is: kinit /ccache -s But by the time it tells you that the CC is expired it is already too late! In my current solution I am testing: 1. A cron job with kinit to check and the remaining lifetime on the TGT and renew if needed. (eventually replace with a k5start daemon) 2. Use the same code on each new vos job's watchdog to check the lifetime and kinit if necessary. This helps to ensure that the jobs sleep time for aklog will not cause the afs token to expire. 3. The watchdog process for the job then only runs aklog going forward. > > 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. > 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. > > -- > Russ Allbery ([hidden email]) <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: [hidden email] 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 [hidden email] https://mailman.mit.edu/mailman/listinfo/kerberos |
In reply to this post by Russ Allbery-2
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 <[hidden email]> wrote: > Kristen Webb <[hidden email]> 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 ([hidden email]) <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: [hidden email] 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 [hidden email] https://mailman.mit.edu/mailman/listinfo/kerberos |
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 <[hidden email]> wrote: > > > Kristen Webb <[hidden email]> 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 ([hidden email]) <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: [hidden email] > 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 [hidden email] > https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/kerberos |
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 <[hidden email]> 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 <[hidden email]> wrote: > > > > > Kristen Webb <[hidden email]> 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 ([hidden email]) < > 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: [hidden email] > > 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 [hidden email] > > 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: [hidden email] 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 [hidden email] https://mailman.mit.edu/mailman/listinfo/kerberos |
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 <[hidden email]> 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 <[hidden email]> wrote: > > > > > > > Kristen Webb <[hidden email]> 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 ([hidden email]) < > > 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: [hidden email] > > > 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 [hidden email] > > > 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: [hidden email] > 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 [hidden email] https://mailman.mit.edu/mailman/listinfo/kerberos |
In reply to this post by Kristen J. Webb
I saw your other follow-up, but just to close out a few things with this
thread.... Kristen Webb <[hidden email]> writes: > On Tue, Sep 25, 2018 at 3:11 PM Russ Allbery <[hidden email]> 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 ([hidden email]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/kerberos |
Free forum by Nabble | Edit this page |