Oct 15, 2012, 6:23:03 AM10/15/12
From time to time we get user questions that essentially sum up to supporting user services running inside MiG. Typically job control tasks that users would be able to manually trigger through a browser (submit, cancel, freeze/thaw, live I/O) but triggered even after the user has gone offline. Sometimes the task even includes logic to submit additional jobs based on results of the previous jobs.
There's an inherent security issue with allowing arbitrary user supplied code to run on the MiG servers, so we cannot just let users start their own apps on a server.
Until now we have worked around the problem by implementing such repeated tasks/services as
2) client apps where the user develops a baby-sitter app that uses the user certificate to manage actions
Neither are perfect because (1) removes a lot of the automation and (2) requires the user certificate to be accessible somewhere on an always-on machine. We haven't found a way to cache the key/certificate passphrase from python so in (2) the key may even have to be stored in unencrypted form!
I talked about it with Simon again now in relation to a build-bot system where we want repeated build and testing of our own projects.
We could of course make our own trusted ad-hoc solution but perhaps we should see it as an opportunity to solve the general problem instead.
The old user defined scheduling project is one approach but it does not include a proper virtualization/sandboxing solution for restricting the scheduling code to avoid illegal access or local DoS on the servers.
Explicit job dependencies or job control from inside running jobs might be a safer solution, but it would require some design and implementation effort and scheduling tasks to run at particular times would still be cumbersome.
We also talked about adding a cron job like feature to MiG so that users can save something like a crontab of actions and having a daemon on the server run them later on behalf of the user.
The actions should be strictly limited to things the user would otherwise be able to perform interactively and the daemon should pick up the crontab entries and schedule them just like the system cron daemon.
If this user crontab is only accessible through the ordinary https+cert interface the actions would be completely traceable and authorized by the user even when running later.
AFAICT the cron idea (maybe in combination with job dependencies) would work for the build-bot case, but it may not be the best fit for general services?
Ideas and comments are very welcome!