[OpenAFS] tokens for long processes
Nathan Ward
nward@esphion.com
Wed, 05 Mar 2003 10:50:30 +1300
As I use Kerberos 5, I am able to store the key for my 'task user' in a
keytab and then call kinit with that keytab and then aklog.
This is an ok solution and while the system could be hacked and that
keytab stolen, the security is better than IP address.
Nathan Ward
t System Administrator
c Esphion ltd.
l Albany, NZ
p +64 9 4144742
e nward@esphion.com
Michael Donaghy wrote:
>On Sun, Feb 12, 2034 at 09:25:26PM +1300, Matthew Cocker wrote:
>
>
>>From: "Matthew Cocker" <matt@cs.auckland.ac.nz>
>>To: <openafs-info@openafs.org>
>>Subject: [OpenAFS] tokens for long processes
>>
>>Hi
>>
>>As I have mentioned in the list recently we are moving OpenAFS into full
>>production in our department. Unfortunately we still have loads of issues to
>>sort out, including how to keep long running processes that write to a users
>>home directory in AFS space happy. We are running a MIT Krb5/Openafs cell
>>with the max ticket life set to 10 hrs (I can't seem to make it any longer
>>than that so is that the maximum allowed by MIT krb5?). Unfortuantely we
>>routinely have users with processes which run for months. What methods have
>>others afs cells used to keep such processes happy. We have considered
>>writing a script that gets called by cron maybe using a keytab file, or
>>maybe just do a ticket renewal then rerun aklog. Is there a better way? I
>>have seen lots written about reauth, is that a solution?
>>
>>Likewise has anyone found a solution for windows desktops that need long
>>term access to a home directory in afs? Has anyone written a screen saver
>>for windows that when unlocked renews afs tokens?
>>
>>Thanks in advance for any help
>>
>>Cheers
>>
>>Matthew Cocker,
>>Computer Science Department
>>The University of Auckland
>>
>>
>
>Matthew,
>
>I'm not sure what the large sites do, but one option you would have
>would be to create an AFS account for an IP address, and give that
>address read/write access on the necessary directories. Granted, this
>makes assumptions about physical system security & network configurations
>that guard strongly against IP spoofing.
>
>Michael
>_______________________________________________
>OpenAFS-info mailing list
>OpenAFS-info@openafs.org
>https://lists.openafs.org/mailman/listinfo/openafs-info
>
>
>
>