Cron

From UGCS
(Difference between revisions)
Jump to: navigation, search
(Removed old content for dead project; adding stuff for my CS11 project)
Line 1: Line 1:
−
Getting cron services available to users is a work in progress.  Presently, cron is being architected with two sides:
+
Getting cron services available to users is a work in progress.  Presently, cron is being architected with a central server that calls a [[Remctl]] script on shellservers which takes care of running the user's cron program.
  
 +
==Daemon==
 +
* Figures out which jobs need to be run
 +
* Gets a new keytab for username/cron
 +
* Sends the job id as well as keytab to a remctl script via command-line arguments
  
−
==Permission details==
+
==Client-side portion==
−
The tricky part of cron on UGCS is to make some way so the daemon can get tokens for the user.  Currently, the procedure looks like this:
+
* Figure out which user we are trying to be and which job we are running
−
* The daemon runs with kerberos tokens for ugcs_cron on the server.  It uses a remctl to "call" the appropriate line of the user's crontab
+
* Change to that user's home dir and UID/GID
−
* The remctl, as one of its arguments, is given the user's /cron keytab.  The remctl script decodes this, puts it in a temp file, and calls kinit
+
* Create a tempfile with the keytab we were given and get kerberos stuff for it
−
* The remctl then calls "ksu user -e cron_command"
+
* Run the user's job
−
* The remctl script also watches to make sure the command doesn't go on for too long
+
* If the user's job takes more than the time before it would get run again, kill it
−
* If necessarily, the remctl script
+
* Send the output to the user
  
 
[[Category:Sysadmin_Documentation]]
 
[[Category:Sysadmin_Documentation]]

Revision as of 07:27, 19 January 2010

Getting cron services available to users is a work in progress. Presently, cron is being architected with a central server that calls a Remctl script on shellservers which takes care of running the user's cron program.

Daemon

  • Figures out which jobs need to be run
  • Gets a new keytab for username/cron
  • Sends the job id as well as keytab to a remctl script via command-line arguments

Client-side portion

  • Figure out which user we are trying to be and which job we are running
  • Change to that user's home dir and UID/GID
  • Create a tempfile with the keytab we were given and get kerberos stuff for it
  • Run the user's job
  • If the user's job takes more than the time before it would get run again, kill it
  • Send the output to the user
Retrieved from "http://www.ugcs.caltech.edu/wiki/Cron"
Personal tools