Hi Kenneth,
1) Get the system installed on 5 linux boxes (total including any servers). Make sure we understand how it all works. Look for security problems. Look for things that will cause administrative headaches for people that are not us.
I don't foresee much trouble in this configuration. Could you give more details as to your administrative requirements?
a) Our code should not be able to have an impact on the running node at all. No connections out, no connections in, no evironment, no disk (maybe some for storing temp files, to be erased when we leave). Basically it should be like running an applet.
The node security model is similar to that of an Applet, with a few signifcant differences.
Some permissions have to be granted for the node to function properly:
- socket connections to the server (such as defined in the node configuration, for single host and single port at a time)
- classloader creation so that your client code can be loaded
- reading some system properties (JPPF and Log4j config)
- thread modification for the node's execution engine
These permissions are the only ones granted by default, since they are vital to the node.
You can grant additional permissions in the node's security policy file, for instance to allow writing/reading/deleting files in a user-specific temp directory only.
Deletion of temporary files on task exit will require some constraints on the code to create them. We can provide an API to make it easier for you, but there will be at least one API call involved as a first step to using the file.
b) Our system should not allow an intruder to run arbitrary code on the grid (servers or nodes). It doesn't really matter how this is handled. If it can be handled by saying that only someone with an account on the server can run something on the node, this level of security would be fine.
This is currently missing in JPPF, and our main focus as well. It is likely that no major feature will be added to the framework before we come up with a reliable security model, including user authentication and management, and permission management at the server level (i.e. can this user submit tasks to this server, etc.)
c) Since these computers are shared among students we can't by tying them up all the time with crashes or denying them access in any other way. We also aren't able to go and muck about in these systems without interference by people whose time we shouldn't waste.
That's a reasonable assumption. I believe the combination of screensaver-based node and node auto-update gives a good start at it - provided we deliver an X / Mac version of the screensaver, of course
3) Lastly we might like to deploy a later version of the product campus wide. Everything I posted above is still important, but security becomes a much more complex issue due to the number of possible users. In addition, the ability to administrate the grid becomes much more important.
It is important for us to know more about your requirements for nodes management. The reason is that our ambition is make JPPF scalable to a very large number of nodes (thousands, millions of nodes). While this emphasizes the necessity of a bullet-proof security model, it also raises questions as to the feasibility of atomic node management. I'd love to hear your feedback on this.
So, to conclude: yes JPPF is ready for 1), and we are ready to support you if you decide to go ahead with this effort.
For 2) and 3), we cannot commit to a delivery date, given the structure of the team and of the project. We are all software development professionals, but JPPF is not our day job - even though it is my dream that it will be one day.
However, we are commited to support our users, and that includes having you help us steer the project vision in the right direction, just as you are doing in this post.
Sincerely,
-Laurent
