issue with k5start

[Benjamin Kaduk]

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 at 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 at REALM
> afs/cell at 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 <eagle at eyrie.org> wrote:
> 
> > Kristen Webb <kwebb at 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 (eagle at 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: kwebb at 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 at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos