[OpenAFS] OpenAFS implementation questions.

Christopher D. Clausen cclausen@acm.org
Fri, 26 May 2006 15:55:41 -0500

There are per-IP ACLs.  While not the best solution, it might work if 
you have a limited set of users who are generally trusted enough not to 
mess with other peoples stuff.



Derek Atkins <warlord@MIT.EDU> wrote:
> Well, you should be able to get tickets/tokens through ssh, either
> via kerberos ticket passing or typing in a password.  In those cases
> your users can still run re-auth.
> However for batch processes, well, there's just not much you can do.
> -derek
> Brady Catherman <bradyc@uidaho.edu> writes:
>> Thanks for the quick reply! =)
>> These users are coming in through SSh and often launching jobs that
>> run in the background. there really isn't room for running reauth and
>> such =/
>> Plus the hope is to put this on the cluster where jobs sit queued for
>> ages before running. The user would have no ability to authenticate
>> later.
>> Hope this clarifies things a bit.
>> On May 25, 2006, at 12:32 PM, Derek Atkins wrote:
>>> Have your users run reauth?  That will automatically get them new
>>> tickets and tokens..  Or tie into the screensaver!
>>> -derek
>>> Quoting Brady Catherman <bradyc@uidaho.edu>:
>>>> I am currently considering moving our environment to OpenAFS but
>>>> before I can switch I need to make sure a few things are going to
>>>> keep working..
>>>> We have users that use or systems for months on end without
>>>> logging  off and I am concerned that the kerberos ticket they are
>>>> being issued  will expire. Having them log back into kerberos/
>>>> openafs isn't really  a good option for us (I am having a hard
>>>> enough time selling even the  basic conversion, let alone anything
>>>> that requires user action!)
>>>> Is there an easy way around this with OpenAFS? I have tried
>>>> setting  the length of our kerberos tickets higher but the most it
>>>> will give  me is 7 days. Is there another way to do this?