Hi Mike, They call this "The Grid" :^)
But reality is that they don't even run as a generic user (Globus environment) - user accounts are still needed and jobs run in single user space (with accounts on each machine and each grid location too.) We had done this in past versions of PVM but was removed due to security concerns - as in - who just ran that xyz code and consumed machine resources. Causes accountability problems (not necessarily related to dollar accounting either...) stephen. Mike Mettke wrote: > > All, > > here's an idea I've been toying with: > > An OSCAR cluster in the end provides a service to a customer, such as > running parallel programs. Currently, we import for customer > authentication the associated /etc/passwd file and for customer data the > user filespace via nfs. This requires a lot of updating, and also, most > importantly, reflects the view that the customer network is homogenous > with OSCAR. > > Now, in my practical experience, I've rarely seen organizations which > have a single, fully homogenous network. For historical and political > reasons, I usually see 2 or 3 networks or clusters in a single > organization. Your mileage may vary, however. > > The expense associated with OSCAR cluster creates some pressure to make > the computing power associated with OSCAR available to multiple customer > clusters. Importing the user authentication data is usually difficult, > since the user ID space is non-orthogonal across multiple clusters. > Also, opening up the data space is difficult as well, since data on the > customer clusters is sometimes not well enough compartmentalized, > leading to the situation of access to all data or none at all. In the > end OSCAR shouldn't have to care about restrictions associated with each > customers data set, as long as all OSCAR jobs + date are > compartmentalized against each other. > > How about: > > 1. OSCAR runs all jobs anonymously, such as oscaruser ? > Maybe we can create and array of 10,000 oscarusers, like > oscaruser1....oscauser10000, and randomly pick one ID to execute under. > This would provide job-job data and user ID separation. > > 2. This does mean all necessary user data is copied for each job from > customer clusters into OSCAR. Associated results would have to be copied > back. PBS has some mechanism for this via the "stage file" option. > If that seems wasteful, nfs is in the end doing exactly the same, that > is, copying the necessary data from host A to host B. > > 3. The headnode would have to have some authentication mechanism, based > on host and/or domainnames and possibly users, such as > > *.domain1.com > *.domain2.com > hosta.domain3.com > hostb.domain4.com wilma > hostc.domain5.com fred > > What do you think ? > > just wondering, > Mike > > -- > Wireless Advanced Technologies Lab > Bell Labs - Lucent Technologies > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Oscar-users mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/oscar-users -- ------------------------------------------------------------------------ Stephen L. Scott, Ph.D. voice: 865-574-3144 Oak Ridge National Laboratory fax: 865-574-0680 P. O. Box 2008, Bldg. 6012, MS-6367 [EMAIL PROTECTED] Oak Ridge, TN 37831-6367 http://www.csm.ornl.gov/~sscott/ ------------------------------------------------------------------------ ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ Oscar-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oscar-users
