Hello Rune,

u+codalist-wk5r_at_chalmers.se 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_at_rogers.coda.realm </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