token expiry 25 hours

[Roger Mason]

Hello,

I have set up a cluster of linux boxes that are coda clients.  The aim
is to share a filesystem in which calculations will be performed using
pbs scheduling.  Everything is fine when I remember to clog on all
the machines in the cluster.  However I am concerned about what will
happen when a token expires before a given client completes its task
and writes files.

Is there some way that I can make the token permanent, i.e. last until
I explicitly cunlog?  Failing that, is there some way that I can set
the expiry time?  I looked in the documentation but did not see a
mention of this.

Thanks,
Roger

[u+codalist-wk5r]

Hej Roger!

On Tue, Nov 25, 2008 at 11:51:15AM -0330, Roger Mason wrote:
> I have set up a cluster of linux boxes that are coda clients.  The aim
> is to share a filesystem in which calculations will be performed using
> pbs scheduling.  Everything is fine when I remember to clog on all

I am a bit curious, have you arranged the writes so that there are
no opportunity for conflicts? (are there suitable provisions in pbs?)

> the machines in the cluster.  However I am concerned about what will
> happen when a token expires before a given client completes its task
> and writes files.

You have to teach the uid running the jobs to regularly refetch
tokens. Like

while sleep 18000; do
  clog pbsrunner@... </protected/local/file/with/password
done

or let cron do that.

> Is there some way that I can make the token permanent, i.e. last until
> I explicitly cunlog?  Failing that, is there some way that I can set

Passwords are the "indefinitely valid" proof of identity.
One of the useful properties of tokens is that they expire
and as such are harder to steal for later use.
If you do not want any expiry, you can as well use the password.
Then can you explicitely "disable" the old password by changing it.

> the expiry time?  I looked in the documentation but did not see a
> mention of this.

There is a possibility to generate tokens with arbitrary validity
periods, but as much as I can see, your need is for "infinite" validity.

Given the realm secret, you can generate arbitrary tokens
with clog -method generate. I don't think though that you want to bother
generating long-lived tokens. It is much simpler to use passwords
and change them when desired.

Regards,
Rune

[Roger Mason]

Hello Rune,

u+codalist-wk5r@... writes:

> On Tue, Nov 25, 2008 at 11:51:15AM -0330, Roger Mason wrote:
>> I have set up a cluster of linux boxes that are coda clients.  The aim
>> is to share a filesystem in which calculations will be performed using
>> pbs scheduling.  Everything is fine when I remember to clog on all
>
> I am a bit curious, have you arranged the writes so that there are
> no opportunity for conflicts? (are there suitable provisions in pbs?)

For the jobs I'm planning to run at the moment the application (that I
wrote in C++) writes output files with names derived from an input
file that is unique for each job.  There _should_ be no possibility for
conflict.  In PBS (or, at least, the Torque implementation thereof)
sterr and stdout are redirected to files that are derived from the
name of the job-script file by which the job was submitted.  Those
files are made unique by appending the job ID number to the filename
and can, in any case, be named by the job-script (which is a bash
script).  Again, there _should_ be no possibility for conflict.
However, the proof of the pudding is in the eating!

>> the machines in the cluster.  However I am concerned about what will
>> happen when a token expires before a given client completes its task
>> and writes files.
>
> You have to teach the uid running the jobs to regularly refetch
> tokens. Like
>
> while sleep 18000; do
>   clog pbsrunner@... </protected/local/file/with/password
> done
>
> or let cron do that.
>

Thanks!  I had not tried the simple expedient of getting the password
from a file.  Doh!

>
> Passwords are the "indefinitely valid" proof of identity.
> One of the useful properties of tokens is that they expire
> and as such are harder to steal for later use.
> If you do not want any expiry, you can as well use the password.
> Then can you explicitely "disable" the old password by changing it.
>
>> the expiry time?  I looked in the documentation but did not see a
>> mention of this.
>
> There is a possibility to generate tokens with arbitrary validity
> periods, but as much as I can see, your need is for "infinite" validity.
>
> Given the realm secret, you can generate arbitrary tokens
> with clog -method generate. I don't think though that you want to bother
> generating long-lived tokens. It is much simpler to use passwords
> and change them when desired.

Yes.  It should be easy to set up a cron job on each machine that runs
once per day.

Thanks again,

Roger

[Roger Mason]

Hi Rune,

u+codalist-wk5r@... writes:

> You have to teach the uid running the jobs to regularly refetch
> tokens. Like
>
> while sleep 18000; do
>   clog pbsrunner@... </protected/local/file/with/password
> done
>
> or let cron do that.


I tried the cron method without success.  I have in a script something
like:

   clog pbsrunner@... </protected/local/file/with/password

When I execute the script from a the command line I get a token.
When the script is executed by cron nothing happens, even though the
system logs show that the cron job ran.

I know this has nothing to do with coda, but any ideas are welcome.

Cheers,
Roger

[u+codalist-wk5r]

Hi Roger,

On Wed, Nov 26, 2008 at 03:13:25PM -0330, Roger Mason wrote:
> I tried the cron method without success.  I have in a script something
> like:
>
>    clog pbsrunner@... </protected/local/file/with/password
>
> When I execute the script from a the command line I get a token.
> When the script is executed by cron nothing happens, even though the
> system logs show that the cron job ran.

Does cron run the command as the uid which is supposed to have the tokens?

Regards,
Rune