issue with k5start

Thu Oct 11 15:59:30 EDT 2018

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 <kaduk at 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 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
> >
> 
> 
> -- 
> 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