Cron

From UGCS
(Difference between revisions)
Jump to: navigation, search
(7/10 update)
 
(4 intermediate revisions by one user not shown)
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.
−
* Users update their crontabs using a modified crontab program in their path which notifies a central server on updates.  The central server (currently hephaestus for testing) parses their file and stores well-formatted commands into our database (currently MySQL).
+
−
* The central cron server runs its own (real) cron command every minute to check the database for commands to run.  It then uses a keytab to load username_cron principals (currently only ckennelly_cron exists), logs into a shellserver, and runs the command.
+
  
−
== Parsing ==
+
==Daemon==
−
The modified crontab program lives at ~ckennelly/cron/crontab.  It stores the user's crontab at ~/.cron/crontab.  When the directory is created, crontab gives the _cron principal read permission on the directory's ACL.
+
* 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
  
−
It fires a notification to hephaestus via remctl to parse the crontab.  It loads up its keytab using a bash-based wrapper (/usr/local/lib/remctl/cron/cronparser_wrapper) and then fires the python-based parser (/usr/local/lib/remctl/cron/cronparser). 
+
The daemon is run on dionysus- see the source in /afs/.ugcs/ugcs-admin/source for source and debian packages. (multiplecron-server)
  
−
The parser has some features, but is still lacking in others:
+
==Client-side portion==
−
* More testing!
+
* Figure out which user we are trying to be and which job we are running
−
* Comma-separated lists (ranges work, along with non-default increments)
+
* Change to that user's home dir and UID/GID
−
* Comma-separated lists with ranges
+
* Create a tempfile with the keytab we were given and get kerberos stuff for it
−
* Shortcuts (like @hourly)
+
* Run the user's job
−
* Three-letter names for months and days of week
+
* If the user's job takes more than the time before it would get run again, kill it
−
* Standard environment variables (like the real crontab specification), SHELL and MAILTO.  Additionally, I haven't checked support for HOME at runtime.
+
* Send the output to the user
−
* Support UGCS-specific environment variables in the crontab.  Alex suggested having RUNAT so a user could specify a specific shellserver to run the command at.
+
  
−
== Execution ==
+
The client code is in /afs/.ugcs/ugcs-admin/source, and is built into the debian package multiplecron-client
−
A development version is configured on hephaestus (see: /usr/local/lib/cron/cronmanager) to run every minute via cron.  Based on results from my own crontab setup, it seems to be working. 
+
  
−
The manager still needs:
+
==Nagios tests==
−
* More testing!
+
* Makes sure the cron daemon is running and running under its k5start process
−
* A threaded producer-consumer style queue to avoid forking too many processes.
+
* The test user ("test") runs a cron job every 5 minutes that touches a file in its home dir.  Nagios checks the file age of this time to make sure it is getting its mtime updated regularly.
−
* Error handling (errors are currently dropped on the floor)
+
==Security==
−
 
+
* User security is maintained because a new keytab is generated each time.  This prevents an old keytab from being stolen and re-used.
−
== Installation ==
+
* The remctl script has a number of security checks to prevent unauthorized users from using it.
−
 
+
* If a shellserver gets rooted, then they will be able to steal the user/cron keytab and modify a user's files. This could be mitigated by running cron jobs only on non-login machines... which defeats the point of this system to some extent.
−
Hephaestus required:
+
−
* sqlobject for python
+
−
* mysqldb for python (python-mysqldb)
+
−
 
+
−
My (ckennelly) user account required:
+
−
* ~/.k5login to be created with my full principal as well as my cron principal.
+
  
 
[[Category:Sysadmin_Documentation]]
 
[[Category:Sysadmin_Documentation]]

Latest revision as of 21:42, 20 March 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.

Contents

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

The daemon is run on dionysus- see the source in /afs/.ugcs/ugcs-admin/source for source and debian packages. (multiplecron-server)

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

The client code is in /afs/.ugcs/ugcs-admin/source, and is built into the debian package multiplecron-client

Nagios tests

  • Makes sure the cron daemon is running and running under its k5start process
  • The test user ("test") runs a cron job every 5 minutes that touches a file in its home dir. Nagios checks the file age of this time to make sure it is getting its mtime updated regularly.

Security

  • User security is maintained because a new keytab is generated each time. This prevents an old keytab from being stolen and re-used.
  • The remctl script has a number of security checks to prevent unauthorized users from using it.
  • If a shellserver gets rooted, then they will be able to steal the user/cron keytab and modify a user's files. This could be mitigated by running cron jobs only on non-login machines... which defeats the point of this system to some extent.
Retrieved from "http://www.ugcs.caltech.edu/wiki/Cron"
Personal tools