On Fri, Aug 31, 2012 at 12:27 PM, Russ Allbery <[email protected]> wrote: > > > Yup, that's what we do here for cron jobs (primarily for web applications, > not for compute tasks). We have a cron service that creates a /cron > principal for the user and runs jobs with tickets and tokens for that > principal. The user can then add ACLs in AFS on appropriate directories.
Ok, I have a better idea of the problem... Perhaps this can help with the suggested solution? We have a cron server that runs two jobs with a certain account. I have discovered its name and its password and have successfully become that account with "klog" in a pagsh. The account has cell tokens. All that job #1 does is check membership of certain pts groups in our cell. It stores this in a database. The other job, #2 - either uses pts adduser or pts removeuser to modify certain pts groups to control access when new lockers are created by other scripts programatically. As far as the other scripts... The process is started from a web form, and then at the step when volumes are needing to be created, scripts are run by administrators with cell admin tokens after an initial sanity check. The cron job needs to modify pts groups because students/accounts can add/drop classes and some already created volumes in the path to the final destination volume will need to have their access controls modified. So we use pts groups for that. This was set up by folks who don't work here anymore, hence using "reauth." The cron servers are on Solaris 8 and RHEL 4 so they must die and be RHEL 6 servers. :) So will I still need to create a keytab for this account? Is there a good faq on how to do that step if I know the account name and password? Thanks so much!
