Hi, Thanks for your two exhaustive explanations. It's much clearer and i see the point now. Thank you very much:)
Cheers, Francois. Quoting Lee Liming <[EMAIL PROTECTED]>: > Charles's explanation is a very good one. One piece that may not > have been completely clear about it is that Globus is modular in > nature, and this means that we have intentionally avoided lumping a > whole bunch of separate tasks into a single piece of code. In this > case, the code in question is GRAM. The task that it performs is to > provide a remote interface to local resource management > capabilities. Those capabilities could be a local scheduler or > queueing system (if the target system uses those to implement a local > resource sharing policy), or it could be some kind of execution > environment (either direct execution via fork or managed execution > using a VM or sandboxing tool). > > We have intentionally avoiding "bundling" other capabilities into > GRAM. For example, GRAM does not provide a built-in mechanism for > implementing resource management policies, and it does not provide a > built-in mechanism for implementing sophisticated security schemes. > Instead, it provides a very simple default mechanism for each (the > fork jobmanager provides direct execution, the grid-mapfile provides > a simple mapping between a Grid ID and a local account) AND it > provides very nice interfaces that you can use to add your own--more > sophisticated--mechanisms for these tasks. > > The jobmanager interface allows you to plug-in your own execution > mechanism, whether that is a different scheduler or queuing system or > a different way to manage jobs (like a VM or a sandbox). Our > expectation is that if you need something other than the basic fork > mechanism or the predefined scheduler interfaces, you will seek out > (or develop) your own execution manager and integrate it with GRAM > via a jobmanager script. For example, there's quite a lot of > interest in the Globus community right now around exploring the use > of VM technology for job execution. (For example, see the Virtual > Workspace service - http://dev.globus.org/wiki/Incubator/ > Virtual_Workspaces.) Some of the production Grids in the science > community (OSG, TeraGrid) are also exploring more lightweight > sandboxing tools that do things like limit the memory usage of each > job or restrict access to file spaces on the system. > > The grid-mapfile mechanism is pretty simple. All it does is map a > Grid ID (certificate DN) to a local account so that jobs submitted > with a given Grid ID are executed using the corresponding local > account. But it can be combined with other tools to map individual > end user requests to a static or dynamic pool of shared accounts. > The authorization and authentication callout interfaces in WS GRAM > allow you to plug-in your own authorization & authentication > mechanisms to replace the simple grid-mapfile mechanism with more > sophisticated mechanisms. There's quite lot of activity in the > Globus community at present to integrate role-based authorization > with GRAM (see GridShib and VOMS). Combining a pool of shared > accounts with role-based authorization is a powerful model for > provisioning dynamic collaborations without creating individual > accounts for each member of the collaboration, while retaining the > ability to implement and enforce local policies. > > The bottom line is that WS GRAM "out of the box" is pretty simple > with respect to both execution management and authentication/ > authorization. But its modular design offers the interfaces > necessary to add other Globus or non-Globus tools to provide very > powerful capabilities. Given this flexibility, it's important for > you to decide how you *want* your system to work so that you can > decide which tools, if any, to add to the basic GRAM service to get > things to work exactly how you want. > > -- Lee > > > > > On Jun 15, 2007, at 8:40 AM, Charles Bacon wrote: > > > It comes down to trust, right? There are some questions to answer: > > > > 1) Do you know who bob is? > > 2) Do you trust bob? > > > > And for 2, what exactly do you trust bob to do? If you gave bob > > access to the globus user's account, would he do something he > > shouldn't do? This gets harder when you also want to add alice. > > Do you trust bob and alice to both use the account how they're > > supposed to, and not to interfere with each other? > > > > Many people find the answer to "do I trust bob to use a shared > > account" to be no. For this reason, most sites will only map bob's > > DN to an account that bob already owns. Other people decide that > > it's okay for bob not to have an account of his own, and there are > > various technical solutions to the problem. > > > > One solution to the problem is to create a pool of anonymous > > accounts, and map incoming DNs you trust to the random pool. > > Another solution might be to start each new job inside a virtual > > machine sandbox to isolate it from other users and the real system > > underneath. > > > > So the answer is that you can do with the tools whatever makes you > > comfortable as a system owner. :-) > > > > > > Charles > > > >
