issue with k5start

Wed Oct 10 00:46:34 EDT 2018

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