How to renew coda tickets and tockens automatically?

[Karl-Philipp Richter]

Hi,
OpenAFS has the ability to renew kerberos tickets and get AFS tokens
automatically with the `krenew` command. Is there an equivalent in coda?
I didn't find anything on
[google](https://www.google.de/?gws_rd=ssl#q=coda+renew+token) and in
the `clog` manpage.

-Kalle

[u-x...@aetey.se]

Hello Karl-Philipp,

On Mon, Jul 11, 2016 at 11:13:55AM +0200, Karl-Philipp Richter wrote:
> Hi,
> OpenAFS has the ability to renew kerberos tickets and get AFS tokens
> automatically with the `krenew` command. Is there an equivalent in coda?

It is not an "ability of OpenAFS" but an ability of krenew,
to renew Kerberos tickets and run external commands when asked so.

You _can_ use "krenew" with Coda:

AKLOG=clog krenew -t ....

but then you need a Kerberos-capable Coda build (and realm), which
regrettably is not included in upstream.

When you do not need _all_ of the krenew functionality, here is
an example of a shell one-liner which acts similar to krenew
as a daemon: (doing nothing specific to either AFS or Coda)

while sleep 10000; do kinit -R; done

Together with a kerberos-aware clog:

while sleep 10000; do kinit -R [...]; clog [...]; done

Without Kerberos you have no use for krenew but still can do something
like

while sleep 30000; do clog xxx@yyyy </protected/file/with/a/pass; done

Here the pass file plays the same role as the Kerberos credentials cache
with krenew. The difference is that the pass does not expire while the
credentials cache is designed to. This nice property of Kerberos credentials
is also available to Coda when clog is built with Kerberos support but
this is not necessarily crucial for a particular deployment.

The differing sleep amounts above reflect the expected credentials
validity length, several hours for a Kerberos tgt, somewhat over 24
hours for Coda tokens. To protect oneself from possible temporary
reauthentication failures it is preferable to make more than one attempt
during the validity period.

(A different approach would be generation of Coda tokens with longer
validity. This relies on administrative rights on the Coda realm
and as such is much more intrusive.)

Does this address your needs?

Rune

[Karl-Philipp Richter]

Am 11.07.2016 um 13:05 schrieb u-x...@aetey.se:
> Without Kerberos you have no use for krenew but still can do something
> like
>
> while sleep 30000; do clog xxx@yyyy </protected/file/with/a/pass; done
>
> Here the pass file plays the same role as the Kerberos credentials cache
> with krenew. The difference is that the pass does not expire while the
> credentials cache is designed to. This nice property of Kerberos credentials
> is also available to Coda when clog is built with Kerberos support but
> this is not necessarily crucial for a particular deployment.

I'm using the upstream packages and want to stick with them. That seems
to be a good solution. Isn't it easier to run that in a cron job?

> Does this address your needs?

Perfectly. Thanks.

-Kalle

[u-x...@aetey.se]

On Mon, Jul 11, 2016 at 03:00:04PM +0200, Karl-Philipp Richter wrote:
> Am 11.07.2016 um 13:05 schrieb u-x...@aetey.se:
> > Without Kerberos you have no use for krenew but still can do something
> > like
> >
> > while sleep 30000; do clog xxx@yyyy </protected/file/with/a/pass; done

> That seems
> to be a good solution. Isn't it easier to run that in a cron job?

The code above merely corresponds to a certain usage case of krenew.

The choice of how to periodically run clog is of course up to you.
Different ways may better suit different scenarios.

Refreshing credentials of a user without any administrative rights over
the computer and possibly even without a right to run cron jobs is not
the same as e.g. allowing persistent service daemons access data on Coda.

Just in case, note that clog shall be run as the uid which is to have the
Coda credentials (in case you would like to put clog in root's crontab).

> > Does this address your needs?
> Perfectly. Thanks.

Glad to hear!

Regards,
Rune

[Jan Harkes]

On Mon, Jul 11, 2016 at 11:13:55AM +0200, Karl-Philipp Richter wrote:
> OpenAFS has the ability to renew kerberos tickets and get AFS tokens
> automatically with the `krenew` command. Is there an equivalent in coda?

AFS tokens are actually modified kerberos tickets and they use a
kerberos mechanism to delagate ticket signing through a TGT (ticket
granting ticket?) or a host token to make a fresh set of AFS tokens
without contacting the kerberos server.

Coda tokens are not related to Kerberos tickets and there is no chain of
intermediate signing tickets, only trusted servers (auth2 daemons) are
able to sign a fresh Coda token.

> I didn't find anything on
> [google](https://www.google.de/?gws_rd=ssl#q=coda+renew+token) and in
> the `clog` manpage.

It probably was mentioned in the mailinglist at some point, but on our
webserver I have a cron job to safely renew a Coda token for the apache
server.

The crontab entry is as follows,

55 */3 * * * root /root/bin/gettokens.sh

The gettokens.sh script contains,

#!/bin/sh

/usr/bin/clog -as www-data web...@coda.cs.cmu.edu < /etc/coda/auth/www-data

And the actual password is stored in '/etc/coda/auth/www-data' where the
/etc/coda/auth directory is only readable by root. This prevents the
'www-data' user from reading the password but he still gets a token that
is refreshed every 3 hours. When the server is rebooted, the same
gettokens.sh script is run from rc.local.

Jan