Cron
From UGCS
(Difference between revisions)
(Removed old content for dead project; adding stuff for my CS11 project) |
|||
| (3 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 | + | 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 | ||
| − | == | + | 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 |
| − | * The | + | * Change to that user's home dir and UID/GID |
| − | * The remctl script | + | * Create a tempfile with the keytab we were given and get kerberos stuff for it |
| − | * If | + | * 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. | ||
[[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.
