jasonmccampbell / spraycc Goto Github PK

Currently no attempt at security is made and the assumption is that we are all "one, big, happy LAN". LAN traffic is often not secure (NFS for example) so no attempt is planned in this regard. However, it is currently possible for someone to connect to a different user's SprayCC server to submit tasks or register as an executor by snooping the access code visible in the process table or job queue. This would allow an unprivileged user attack another user which seems an unnecessarily large gap.

One solution is to create a user-private file (~/.spraycc.private or similar) with a random cookie. When the executors and clients start they can read this private cookie and provide it to the server. A user would not be able to connect to someone else's server unless they have private read access, in which case there are probably much larger issues to worry about.

Compile times for a given command line or output target can be recorded into a simple DB. These data can be loaded on a subsequent run to prioritize the task queue to start the longest-running jobs first.

Is there a convenient way to describe commands? That is, specify how to identify any output files names which should be modified to write to a temporary location and sent back. One example is running unit test commands.

Another issue with this is how to send environment variables. If the server is started under a Makefile, the environment may already be setup. Does the client need to capture and transmit any environment info to send with the task?

Too much error handling is stubbed as panic! commands and it would be nice to get rid of the traceback reports now that it is stable.

Biggest issue: server leaves .spraycc-history file laying around when cancelled. If done in a subdirectory this can cause a run from the top-level to fail when clients start in the subdirectory and attempt to connect to the wrong server.

Second issue: ctrl-C of make terminates the clients, which disconnect from the server, but don't stop any of the jobs. If the server has 1k jobs, it will continue feeding the execs for no reason. If the server is terminated, see above.

Third issue: even if the server is terminated, the executors continue running the tasks to completion before exiting. This may or may not be a long time. This is because tasks are run synchronously instead of asynchronous so the disconnect goes unnoticed.

In general, should ctrl-c of one client cause that one task to be removed? Is it work the bookkeeping to do that? Or is the general case all clients are terminated, at which point the server can go into shutdown mode?