Hi Matt, Thanks a lot for the feedback...
> for eg: if a GThread is fully sandboxed, and has only 'Internet' > permissions, it will not be able to do much more than just use CPU. My > idea is to give it some more permissions, such as ability to write to > its working directory on disk. Other than that, nothing else may be > allowed. We could then add policies to allow for execution of 'unsafe' > threads, such as those that spawn off a Process, (including the GJob), > IF and only if, it is in the GAC / is digitally signed or something. > > > Just my $0.02 about this... > > I would stay away from relying on if the code is in the GAC or > not.....this makes a pretty big deployment headache. > Part of why Alchemi is so flexible is that no DLLs or EXEs need to be > deployed to the Executor computer -- everything is serialized with the > thread. I've been doing some pretty heavy development in the last > week or so by adding Alchemi support to my C# wrapper library, and > have changed the code executing in the DLL so much that I don't think > I've used the same DLL version twice. If I had to deploy a new > version of my DLL to the GAC of every machine in the Alchemi grid > after each build, that would be a nightmare. > Yes, I agree it is a big headache during development. But I was referring to the configuration settings for a stable, production environment, when it might make more sense to have a higher level of security. In any case, the GAC requirement , if implemented at all, would only be required for certain GThreads which need more permissions than that offered by the proposed default sandbox. (Or perhaps, we could relax the security in the default sandbox itself.). Not every GThread would need that, and we could enforce better security with this. And during development we could always turn off the security policy, so that we can avoid GAC installation even for security critical GThreads. > Part of what helps my C# wrapper library is that there are actually 2 > FORTRAN exes that need to be run, one before the other. Possibly > extending the GJob to allow an arbitrary number of command executions > would prove useful. For example, my process flow has to be > > input1.txt -> Preprocessor.exe -> data1.txt, data2.txt > data1.txt, data2.txt -> Simulator.exe -> output1.txt, output2.txt, > output3.txt > > There would be a pretty hefty waste if that were required to be split > into 2 GJobs, because then data1.txt and data2.txt (can be pretty > large files) would need to be transferred back to the manager and then > back to an executor again. > Yes, I think this is one of the scenarios where the current GJob falls short. I am not sure, if it is a good idea to try and support all sorts of things inside a GJob. I will wait for other's opinions too. Meanwhile, I think what you are doing looks like the best solution at present - (i.e wrap the Fortran program(s) with a C# dll, fork it off in whatever way needed, and read/write inputs/outputs in memory and dump to disk only when needed.). In fact, we use a similar approach in the Alchemi-Renderer example, that renders parts of an image using POV-Ray (which is pre-installed on the Executors). Cheers Krishna. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ alchemi-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/alchemi-users
