GENESIS II DISTRIBUTION

Main.GenesisIIDistribution History

Hide minor edits - Show changes to output

December 08, 2011, at 03:18 PM by 128.143.136.101 -
Changed line 72 from:
%rfloat% http://genesis2.virginia.edu/wiki/uploads/Main/gffs.jpeg
to:
%rfloat% http://genesis2.virginia.edu/wiki/uploads/Main/gendistribution.jpeg
December 08, 2011, at 03:14 PM by 128.143.136.101 -
Changed line 72 from:
<center>[[Image:Export-concept.jpg]]</center>
to:
%rfloat% http://genesis2.virginia.edu/wiki/uploads/Main/gffs.jpeg
December 08, 2011, at 03:13 PM by 128.143.136.101 -
Changed lines 42-45 from:
||Grid Shell ||The Grid Shell is a command-line tool that provides a text-based interface to the Grid RNS namespace, similar to most Unix and Windows command shells.The Grid Shell is invoked by invoking the Genesis II “grid” script from a Windows or Linux command shell. The Grid Shell persists a “session” of grid credentials and the “present working directory” in the Grid RNS namespace, and supports a number of familiar commands such as ls, cd, mkdir, cp, login, run, qsub, and a simple scripting language. ||
||Local FTP ||Genesis II distributions can operate a simple, easy-to-use FTP daemon from which local FTP clients (e.g., Windows Explorer) can access the Grid namespace and file-like data resources. The Genesis II FTP daemon serves as a proxy between local FTP clients and the Grid. The security concerns of FTP are addressed by the restriction that FTP access is only granted to local programs. ||
||Windows Installable Filesystem (IFS) ||The Genesis II Installable File System for Windows XP allows users to map the Grid RNS namespace as a Network Drive (e.g., the G: drive). Users already familiar with the traditional File Explorer interface provided in Windows XP will have little trouble adjusting to the IFS. When mounted as an IFS filesystem, Windows programs can transparently create, delete, read, and write Grid files and directories. The IFS also provides a convenient interface for copying Grid data to/from the local filesystem. ||
||OGRSH Linux I/O Shim ||OGRSH is a Linux “library shim” that traps library calls made by existing applications and redirects them to the Genesis II Grid. Native programs and applications (e.g., bash, cp, ls, etc.) can transparently interface with remote Grid resources when run “on top of” OGRSH. ||
to:
||'''Grid Shell''' ||The Grid Shell is a command-line tool that provides a text-based interface to the Grid RNS namespace, similar to most Unix and Windows command shells.The Grid Shell is invoked by invoking the Genesis II “grid” script from a Windows or Linux command shell. The Grid Shell persists a “session” of grid credentials and the “present working directory” in the Grid RNS namespace, and supports a number of familiar commands such as ls, cd, mkdir, cp, login, run, qsub, and a simple scripting language. ||
||'''Local FTP''' ||Genesis II distributions can operate a simple, easy-to-use FTP daemon from which local FTP clients (e.g., Windows Explorer) can access the Grid namespace and file-like data resources. The Genesis II FTP daemon serves as a proxy between local FTP clients and the Grid. The security concerns of FTP are addressed by the restriction that FTP access is only granted to local programs. ||
||'''Windows Installable Filesystem (IFS)''' ||The Genesis II Installable File System for Windows XP allows users to map the Grid RNS namespace as a Network Drive (e.g., the G: drive). Users already familiar with the traditional File Explorer interface provided in Windows XP will have little trouble adjusting to the IFS. When mounted as an IFS filesystem, Windows programs can transparently create, delete, read, and write Grid files and directories. The IFS also provides a convenient interface for copying Grid data to/from the local filesystem. ||
||'''OGRSH Linux I/O Shim''' ||OGRSH is a Linux “library shim” that traps library calls made by existing applications and redirects them to the Genesis II Grid. Native programs and applications (e.g., bash, cp, ls, etc.) can transparently interface with remote Grid resources when run “on top of” OGRSH. ||
December 08, 2011, at 03:12 PM by 128.143.136.101 -
Changed line 66 from:
By operating a Genesis II Container, you can allow Grid resources (e.g., job Queues, RNS and ByteIO resources, IDP resources, etc.) to be hosted by your container. The ability to create such resources is dependent on the [[Genesis Security Overview | Genesis Security access-control]] policies that you configure, of course. For example, you can use the mkdir Grid Shell tool to place a new subdirectory on a particular Genesis II Container. Any RNS and ByteIO resources created within that subdirectory will also be located within your Genesis II Container.
to:
By operating a Genesis II Container, you can allow Grid resources (e.g., job Queues, RNS and ByteIO resources, IDP resources, etc.) to be hosted by your container. The ability to create such resources is dependent on the [[Genesis Security Overview | Genesis Security access-control ]] policies that you configure, of course. For example, you can use the mkdir Grid Shell tool to place a new subdirectory on a particular Genesis II Container. Any RNS and ByteIO resources created within that subdirectory will also be located within your Genesis II Container.
December 08, 2011, at 03:11 PM by 128.143.136.101 -
Changed line 59 from:
More information regarding the deployment and execution of jobs can be found in the [[Genesis II FAQ]].
to:
More information regarding the deployment and execution of jobs can be found in the [[FAQ |Genesis II FAQ]].
December 08, 2011, at 03:10 PM by 128.143.136.101 -
Changed line 66 from:
By operating a Genesis II Container, you can allow Grid resources (e.g., job Queues, RNS and ByteIO resources, IDP resources, etc.) to be hosted by your container. The ability to create such resources is dependent on the [[Genesis_II_Security_Overview#Access Control|access-control]] policies that you configure, of course. For example, you can use the mkdir Grid Shell tool to place a new subdirectory on a particular Genesis II Container. Any RNS and ByteIO resources created within that subdirectory will also be located within your Genesis II Container.
to:
By operating a Genesis II Container, you can allow Grid resources (e.g., job Queues, RNS and ByteIO resources, IDP resources, etc.) to be hosted by your container. The ability to create such resources is dependent on the [[Genesis Security Overview | Genesis Security access-control]] policies that you configure, of course. For example, you can use the mkdir Grid Shell tool to place a new subdirectory on a particular Genesis II Container. Any RNS and ByteIO resources created within that subdirectory will also be located within your Genesis II Container.
December 08, 2011, at 03:09 PM by 128.143.136.101 -
Changed lines 53-54 from:
*The Grid Shell’s [[run]] command. The primary arguments of the run command are the location of a JSDL document and the RNS path to a BES resource.
*The Grid Shell’s [[qsub]] command. The primary arguments of the qsub command are the location of a JSDL document and the RNS path to a Queue resource.
to:
*The Grid Shell’s run command. The primary arguments of the run command are the location of a JSDL document and the RNS path to a BES resource.
*The Grid Shell’s qsub command. The primary arguments of the qsub command are the location of a JSDL document and the RNS path to a Queue resource.
Changed line 57 from:
Because BES and Queue resources implement the RNS directory interface, their contents can also be “listed” using any of the namespace-browsing interfaces from the previous sections. In their case, the semantics of a directory-listing request are to return the job activities currently managed by that BES/Queue resource. The Genesis II Queue resources also can be manipulated using a variety of command line tools (e.g., [[qstat]], [[qlist]], [[qkill]], [[qcomplete]], etc.).
to:
Because BES and Queue resources implement the RNS directory interface, their contents can also be “listed” using any of the namespace-browsing interfaces from the previous sections. In their case, the semantics of a directory-listing request are to return the job activities currently managed by that BES/Queue resource. The Genesis II Queue resources also can be manipulated using a variety of command line tools (e.g., qstat, qlist, qkill, qcomplete, etc.).
December 08, 2011, at 03:07 PM by 128.143.136.101 -
Changed line 66 from:
By operating a Genesis II Container, you can allow Grid resources (e.g., job Queues, RNS and ByteIO resources, IDP resources, etc.) to be hosted by your container. The ability to create such resources is dependent on the [[Genesis_II_Security_Overview#Access Control|access-control]] policies that you configure, of course. For example, you can use the [[mkdir]] Grid Shell tool to place a new subdirectory on a particular Genesis II Container. Any RNS and ByteIO resources created within that subdirectory will also be located within your Genesis II Container.
to:
By operating a Genesis II Container, you can allow Grid resources (e.g., job Queues, RNS and ByteIO resources, IDP resources, etc.) to be hosted by your container. The ability to create such resources is dependent on the [[Genesis_II_Security_Overview#Access Control|access-control]] policies that you configure, of course. For example, you can use the mkdir Grid Shell tool to place a new subdirectory on a particular Genesis II Container. Any RNS and ByteIO resources created within that subdirectory will also be located within your Genesis II Container.
December 08, 2011, at 03:06 PM by 128.143.136.101 -
Changed lines 49-50 from:
====Access to Computing Resources====
Applications can be executed on remote computing hardware using Basic Execution Service (BES) Grid resources. [http://www.ogf.org/gf/group_info/view.php?group=ogsa-bes-wg BES] is a standard Web Services interface for creating and managing jobs. To run a job on a BES resource, you need a [http://www.ogf.org/gf/group_info/view.php?group=jsdl-wg JSDL] (XML) document that describes your application in terms of where to obtain the program executable and input data sources, and where to place any results. Genesis II Grids may also contain Queue resources that can be used to throttle and schedule jobs on multiple BES resources.
to:
!!!Access to Computing Resources
Applications can be executed on remote computing hardware using Basic Execution Service (BES) Grid resources. [[http://www.ogf.org/gf/group_info/view.php?group=ogsa-bes-wg |BES]] is a standard Web Services interface for creating and managing jobs. To run a job on a BES resource, you need a [[http://www.ogf.org/gf/group_info/view.php?group=jsdl-wg |JSDL]] (XML) document that describes your application in terms of where to obtain the program executable and input data sources, and where to place any results. Genesis II Grids may also contain Queue resources that can be used to throttle and schedule jobs on multiple BES resources.
December 08, 2011, at 03:05 PM by 128.143.136.101 -
Changed line 68 from:
====Hosting and Sharing Data====
to:
!!!Hosting and Sharing Data
Changed line 79 from:
====Hosting Computing Resources====
to:
!!!Hosting Computing Resources
December 08, 2011, at 03:04 PM by 128.143.136.101 -
Changed line 62 from:
==Server Role==
to:
!Server Role
Changed line 65 from:
====Hosting arbitrary Grid Resources====
to:
!!!Hosting arbitrary Grid Resources
December 08, 2011, at 03:03 PM by 128.143.136.101 -
Changed line 16 from:
!!Background
to:
!Background
Changed line 36 from:
!!Client Role
to:
!Client Role
December 08, 2011, at 03:02 PM by 128.143.136.101 -
Changed line 2 from:
!!Introduction
to:
!Introduction
December 08, 2011, at 03:02 PM by 128.143.136.101 -
Changed line 42 from:
||Grid Shell ||The Grid Shell is a command-line tool that provides a text-based interface to the Grid RNS namespace, similar to most Unix and Windows command shells.The Grid Shell is invoked by invoking the Genesis II “grid” script from a Windows or Linux command shell. The Grid Shell persists a “session” of grid credentials and the “present working directory” in the Grid RNS namespace, and supports a number of familiar commands such as [[ls]], [[cd]], [[mkdir]], [[cp]], [[login]], [[run]], [[qsub]], and a simple scripting language. ||
to:
||Grid Shell ||The Grid Shell is a command-line tool that provides a text-based interface to the Grid RNS namespace, similar to most Unix and Windows command shells.The Grid Shell is invoked by invoking the Genesis II “grid” script from a Windows or Linux command shell. The Grid Shell persists a “session” of grid credentials and the “present working directory” in the Grid RNS namespace, and supports a number of familiar commands such as ls, cd, mkdir, cp, login, run, qsub, and a simple scripting language. ||
December 08, 2011, at 03:00 PM by 128.143.136.101 -
Changed line 44 from:
||Windows Installable Filesystem (IFS) ||
to:
||Windows Installable Filesystem (IFS) ||The Genesis II Installable File System for Windows XP allows users to map the Grid RNS namespace as a Network Drive (e.g., the G: drive). Users already familiar with the traditional File Explorer interface provided in Windows XP will have little trouble adjusting to the IFS. When mounted as an IFS filesystem, Windows programs can transparently create, delete, read, and write Grid files and directories. The IFS also provides a convenient interface for copying Grid data to/from the local filesystem. ||
December 08, 2011, at 02:59 PM by 128.143.136.101 -
Changed lines 42-43 from:
||Grid Shell ||The Grid Shell is a command-line tool that provides a text-based interface to the Grid RNS namespace, similar to most Unix and Windows command shells.
The Grid Shell is invoked by invoking the Genesis II “grid” script from a Windows or Linux command shell. The Grid Shell persists a “session” of grid credentials and the “present working directory” in the Grid RNS namespace, and supports a number of familiar commands such as [[ls]], [[cd]], [[mkdir]], [[cp]], [[login]], [[run]], [[qsub]], and a simple scripting language. ||
to:
||Grid Shell ||The Grid Shell is a command-line tool that provides a text-based interface to the Grid RNS namespace, similar to most Unix and Windows command shells.The Grid Shell is invoked by invoking the Genesis II “grid” script from a Windows or Linux command shell. The Grid Shell persists a “session” of grid credentials and the “present working directory” in the Grid RNS namespace, and supports a number of familiar commands such as [[ls]], [[cd]], [[mkdir]], [[cp]], [[login]], [[run]], [[qsub]], and a simple scripting language. ||
Changed line 44 from:
||Windows Installable Filesystem (IFS) || ||
to:
||Windows Installable Filesystem (IFS) ||
December 08, 2011, at 02:58 PM by 128.143.136.101 -
December 08, 2011, at 02:58 PM by 128.143.136.101 -
Changed lines 42-43 from:
||Grid Shell ||The Grid Shell is a command-line tool that provides a text-based interface to the Grid RNS namespace, similar to most Unix and Windows command shells.
to:
||Grid Shell ||The Grid Shell is a command-line tool that provides a text-based interface to the Grid RNS namespace, similar to most Unix and Windows command shells.
Changed lines 46-66 from:
||OGRSH

{| class="wikitable"
|width=20% bgcolor=E6E6FA valign="top"|
=====[[Genesis_II_Commands|Grid Shell]]=====
|

=====[[Ftpd|Local FTP]]=====
|
Genesis II distributions can operate a simple, easy-to-use FTP daemon from which local FTP clients (e.g., Windows Explorer) can access the Grid namespace and file-like data resources
. The Genesis II FTP daemon serves as a proxy between local FTP clients and the Grid. The security concerns of FTP are addressed by the restriction that FTP access is only granted to local programs.
|-
|bgcolor=E6E6FA valign="top"|
=====[[The Installable File System for Windows XP|Windows Installable Filesystem (IFS)]]=====
|
The Genesis II Installable File System for Windows XP allows users to map the Grid RNS namespace as a Network Drive (e.g., the G: drive). Users already familiar with the traditional File Explorer interface provided in Windows XP will have little trouble adjusting to the IFS. When mounted as an IFS filesystem, Windows programs can transparently create, delete, read, and write Grid files and directories. The IFS also provides a convenient interface for copying Grid data to/from the local filesystem.
|-
|bgcolor=E6E6FA valign="top"|
=====[[OGRSH|OGRSH (Linux I/O Shim)]]=====
|
OGRSH is a Linux “library shim” that traps library calls made by existing applications and redirects them to the Genesis II Grid. Native programs and applications (e.g., bash, cp, ls, etc.) can transparently interface with remote Grid resources when run “on top of” OGRSH.
|}
to:
||OGRSH Linux I/O Shim ||OGRSH is a Linux “library shim” that traps library calls made by existing applications and redirects them to the Genesis II Grid. Native programs and applications (e.g., bash, cp, ls, etc.) can transparently interface with remote Grid resources when run “on top of” OGRSH. ||
December 08, 2011, at 02:56 PM by 128.143.136.101 -
Changed lines 41-48 from:
to:
||border=1 width=80%
||Grid Shell ||The Grid Shell is a command-line tool that provides a text-based interface to the Grid RNS namespace, similar to most Unix and Windows command shells.

The Grid Shell is invoked by invoking the Genesis II “grid” script from a Windows or Linux command shell. The Grid Shell persists a “session” of grid credentials and the “present working directory” in the Grid RNS namespace, and supports a number of familiar commands such as [[ls]], [[cd]], [[mkdir]], [[cp]], [[login]], [[run]], [[qsub]], and a simple scripting language. ||
||Local FTP ||Genesis II distributions can operate a simple, easy-to-use FTP daemon from which local FTP clients (e.g., Windows Explorer) can access the Grid namespace and file-like data resources. The Genesis II FTP daemon serves as a proxy between local FTP clients and the Grid. The security concerns of FTP are addressed by the restriction that FTP access is only granted to local programs. ||
||Windows Installable Filesystem (IFS) || ||
||OGRSH
Changed lines 53-57 from:
The Grid Shell is a command-line tool that provides a text-based interface to the Grid RNS namespace, similar to most Unix and Windows command shells.

The Grid Shell is invoked by invoking the Genesis II “grid” script from a Windows or Linux command shell. The Grid Shell persists a “session” of grid credentials and the “present working directory” in the Grid RNS namespace, and supports a number of familiar commands such as [[ls]], [[cd]], [[mkdir]], [[cp]], [[login]], [[run]], [[qsub]], and a simple scripting language.
|-
|bgcolor=E6E6FA valign="top"|
to:
December 08, 2011, at 02:52 PM by 128.143.136.101 -
Changed line 39 from:
'''Access to Data Resources'''
to:
!!!Access to Data Resources
December 08, 2011, at 02:50 PM by 128.143.136.101 -
Changed line 40 from:
Genesis II uses the [https://forge.gridforum.org/sf/go/doc8272?nav=1 RNS] and [http://www.ogf.org/gf/group_info/view.php?group=byteio-wg ByteIO] standards to provide familiar directory and file interfaces for datagrid resources. Genesis II provides four primary interfaces for creating, browsing, and accessing remote Grid data:
to:
Genesis II uses the [[https://forge.gridforum.org/sf/go/doc8272?nav=1 |RNS]] and [[http://www.ogf.org/gf/group_info/view.php?group=byteio-wg |ByteIO]] standards to provide familiar directory and file interfaces for datagrid resources. Genesis II provides four primary interfaces for creating, browsing, and accessing remote Grid data:
December 08, 2011, at 02:49 PM by 128.143.136.101 -
Changed line 31 from:
[https://forge.gridforum.org/sf/go/doc8272?nav=1 RNS] stands for the “Resource Namespace Service” specification. RNS is a standard way of building directory structures in Web Services. An RNS namespace allows us to hierarchically organize Grid resources using familiar path strings, such as /home/grimshaw/myfile.
to:
[[https://forge.gridforum.org/sf/go/doc8272?nav=1 |RNS]] stands for the “Resource Namespace Service” specification. RNS is a standard way of building directory structures in Web Services. An RNS namespace allows us to hierarchically organize Grid resources using familiar path strings, such as /home/grimshaw/myfile.
December 08, 2011, at 02:48 PM by 128.143.136.101 -
Changed line 36 from:
==Client Role==
to:
!!Client Role
December 08, 2011, at 02:47 PM by 128.143.136.101 -
Changed line 24 from:
'''NAT'''
to:
!!!NAT
Changed line 27 from:
'''Firewall'''
to:
!!!Firewall
Changed line 30 from:
'''RNS Namespace'''
to:
!!!RNS Namespace
December 08, 2011, at 02:32 PM by 128.143.136.101 -
Changed line 20 from:
Genesis II is architected upon the [[http://en.wikipedia.org/wiki/Web_service |Web Services]] paradigm. Interaction with Grid resources is achieved by communicating [http://en.wikipedia.org/wiki/XML XML] messages in accordance with the [[http://www.w3.org/TR/soap |SOAP]] protocol over an HTTP or HTTPS network transport.
to:
Genesis II is architected upon the [[http://en.wikipedia.org/wiki/Web_service |Web Services]] paradigm. Interaction with Grid resources is achieved by communicating [[http://en.wikipedia.org/wiki/XML |XML]] messages in accordance with the [[http://www.w3.org/TR/soap |SOAP]] protocol over an HTTP or HTTPS network transport.
December 08, 2011, at 02:32 PM by 128.143.136.101 -
Changed line 6 from:
||border=1 width=90%
to:
||border=1 width=80%
December 08, 2011, at 02:31 PM by 128.143.136.101 -
Changed line 6 from:
||border=1 width=75%
to:
||border=1 width=90%
December 08, 2011, at 02:31 PM by 128.143.136.101 -
Changed line 6 from:
||border=1 width=80%
to:
||border=1 width=75%
December 08, 2011, at 02:30 PM by 128.143.136.101 -
Changed line 20 from:
Genesis II is architected upon the [http://en.wikipedia.org/wiki/Web_service Web Services] paradigm. Interaction with Grid resources is achieved by communicating [http://en.wikipedia.org/wiki/XML XML] messages in accordance with the [http://www.w3.org/TR/soap SOAP] protocol over an HTTP or HTTPS network transport.
to:
Genesis II is architected upon the [[http://en.wikipedia.org/wiki/Web_service |Web Services]] paradigm. Interaction with Grid resources is achieved by communicating [http://en.wikipedia.org/wiki/XML XML] messages in accordance with the [[http://www.w3.org/TR/soap |SOAP]] protocol over an HTTP or HTTPS network transport.
December 08, 2011, at 02:29 PM by 128.143.136.101 -
Deleted lines 9-26:

{| class="wikitable"
|-
!width=100pt|Role
! Activities
|-
|style="text-align:center"|
''[[#Client Role|Client]]''
|
*Access remote data as a client.
*Access remote compute resources (i.e., run jobs).
|-
|style="text-align:center"|
''[[#Server Role|Server]]''
|
*Host and share (publish) data into the Grid.
*Serve as a [http://www.ogf.org/gf/group_info/view.php?group=ogsa-bes-wg BES] job hosting endpoint (i.e., run other peoples jobs on your machine).
|}
December 08, 2011, at 02:29 PM by 128.143.136.101 -
Changed lines 8-9 from:
|| ''' Client''' ||Access remote data as a client. Access remote compute resources (i.e., run jobs).||
|| ''' Server''' ||Host and share (publish) data into the Grid. Serve as a [http://www.ogf.org/gf/group_info/view.php?group=ogsa-bes-wg BES] job hosting endpoint (i.e., run other peoples jobs on your machine). ||
to:
|| ''' Client''' ||Access remote data as a client. Access remote compute resources (i.e., run jobs).||
|| ''' Server''' ||Host and share (publish) data into the Grid. Serve as a [[http://www.ogf.org/gf/group_info/view.php?group=ogsa-bes-wg |BES]
] job hosting endpoint (i.e., run other peoples jobs on your machine). ||
December 08, 2011, at 02:28 PM by 128.143.136.101 -
Changed lines 8-10 from:
|| ''' Client''' ||* Access remote data as a client.
* Access remote compute resources (i.e., run jobs).||
|| ''' Server''' || ||
to:
|| ''' Client''' ||Access remote data as a client. Access remote compute resources (i.e., run jobs).||
|| ''' Server'''
||Host and share (publish) data into the Grid. Serve as a [http://www.ogf.org/gf/group_info/view.php?group=ogsa-bes-wg BES] job hosting endpoint (i.e., run other peoples jobs on your machine). ||
December 08, 2011, at 02:26 PM by 128.143.136.101 -
Changed lines 8-9 from:
|| ''' Client''' ||* Access remote data as a client.* Access remote compute resources (i.e., run jobs).||
to:
|| ''' Client''' ||* Access remote data as a client.
* Access remote compute resources (i.e., run jobs).||
December 08, 2011, at 02:26 PM by 128.143.136.101 -
Changed lines 8-11 from:
|| ''' Client''' ||
* Access remote data as a client.

* Access remote compute resources (i.e., run jobs). ||
to:
|| ''' Client''' ||* Access remote data as a client.* Access remote compute resources (i.e., run jobs).||
December 08, 2011, at 02:25 PM by 128.143.136.101 -
Changed lines 8-9 from:
|| ''' Client''' ||*Access remote data as a client.
*Access remote compute resources (i.e., run jobs). ||
to:
|| ''' Client''' ||
* Access remote data as a client.

* Access remote compute resources (i.e., run jobs). ||
December 08, 2011, at 02:24 PM by 128.143.136.101 -
Changed lines 8-9 from:
|| ''' Client''' || ||
to:
|| ''' Client''' ||*Access remote data as a client.
*Access remote compute resources (i.e., run jobs).
||
December 08, 2011, at 02:24 PM by 128.143.136.101 -
Changed line 7 from:
||%center%!Role ||!Activities ||
to:
||!Role ||!Activities ||
December 08, 2011, at 02:24 PM by 128.143.136.101 -
December 08, 2011, at 02:23 PM by 128.143.136.101 -
Changed line 7 from:
||!Role ||!Activities ||
to:
||%center%!Role ||!Activities ||
December 08, 2011, at 02:23 PM by 128.143.136.101 -
Changed lines 8-9 from:
|| ''' Client''''' || ||
|| ''' Server''''' || ||
to:
|| ''' Client''' || ||
|| ''' Server''' || ||
December 08, 2011, at 02:22 PM by 128.143.136.101 -
Changed lines 8-9 from:
|| ''' Client'''''Emphasized'' || ||
|| ''' Server'''''Emphasized'' || ||
to:
|| ''' Client''''' || ||
|| ''' Server''''' || ||
December 08, 2011, at 02:22 PM by 128.143.136.101 -
Changed lines 7-9 from:
||!Role ||!Activities ||!Hdr ||
|| || || ||
|| || || ||
to:
||!Role ||!Activities ||
|| ''' Client'''''Emphasized'' || ||
|| ''' Server'''''Emphasized'' || ||
December 08, 2011, at 02:21 PM by 128.143.136.101 -
Added lines 6-9:
||border=1 width=80%
||!Role ||!Activities ||!Hdr ||
|| || || ||
|| || || ||
December 08, 2011, at 02:20 PM by 128.143.136.101 -
Changed line 2 from:
==Introduction==
to:
!!Introduction
Changed line 30 from:
==Background==
to:
!!Background
Changed line 33 from:
====Web Services====
to:
!!!Web Services
Changed line 38 from:
====NAT====
to:
'''NAT'''
Changed line 41 from:
====Firewall====
to:
'''Firewall'''
Changed line 44 from:
====RNS Namespace====
to:
'''RNS Namespace'''
Changed line 53 from:
====Access to Data Resources====
to:
'''Access to Data Resources'''
December 08, 2011, at 02:15 PM by 128.143.136.101 -
Changed lines 1-111 from:
(:Title GENESIS II DISTRIBUTION:)
to:
(:Title GENESIS II DISTRIBUTION:)
==Introduction==
The Genesis II distribution provides a rich set of features, tools, interfaces, and services for participating in a Grid. Before you install and configure your Genesis II distribution, you should consider the features afforded by the Genesis II distribution and the activities you wish to perform. The choices between the various activities will impact both the configuration work and security implications for your distribution. This primer is intended to provide informative background information to help in the setup, configuration, and usage of your Genesis II distribution. Links to more-detailed information on various topics/features are provided.

There are four basic activities that a computer may perform in a Genesis II Grid:

{| class="wikitable"
|-
!width=100pt|Role
! Activities
|-
|style="text-align:center"|
''[[#Client Role|Client]]''
|
*Access remote data as a client.
*Access remote compute resources (i.e., run jobs).
|-
|style="text-align:center"|
''[[#Server Role|Server]]''
|
*Host and share (publish) data into the Grid.
*Serve as a [http://www.ogf.org/gf/group_info/view.php?group=ogsa-bes-wg BES] job hosting endpoint (i.e., run other peoples jobs on your machine).
|}

Genesis II participants performing the first two activities are considered as having ''client'' roles because they do not expose data or computing resources into the Grid. Participants exposing data and computing resources are characterized as having ''server'' roles.

The ''client'' and ''server'' roles are not mutually exclusive for a given Genesis II distribution. For example, you may choose to access remote compute and data resources and share some of your data, but not allow others to use your computing resources. However, the configuration options and requirements will likely be influenced by the role(s) you intend your distribution to perform.


==Background==
In this section we present some general information about the Genesis II distribution and the technologies that affect its usage.

====Web Services====
Genesis II is architected upon the [http://en.wikipedia.org/wiki/Web_service Web Services] paradigm. Interaction with Grid resources is achieved by communicating [http://en.wikipedia.org/wiki/XML XML] messages in accordance with the [http://www.w3.org/TR/soap SOAP] protocol over an HTTP or HTTPS network transport.

The distinction between ''client'' and ''server'' roles is largely an artifact of the Web Services paradigm. Grid resources are exposed via Web Service operations, and must be hosted within a lightweight “web application container” (Genesis II Container) that listens for incoming HTTP/HTTPS connections and manages a stateful database. Therefore if you would like to use your Genesis II distribution to provision computing or data resources within the Grid, your distribution must operate a Genesis II Container that serves incoming Web service requests for your resources. If you choose to operate a Genesis II Container, you may be subject to additional networking requirements. (See the NAT and Firewall topics below). On the other hand, if you only wish to access remote computing and data resources, operating a Genesis II Container is not necessary.

====NAT====
NAT stands for “Network Address Translation”. A NAT sits between one or more hosts and the internet. NAT’s are typically used to multiplex multiple hosts or devices to a single IP address. Most home networks in the U.S. are behind a NAT. If your machine is behind a NAT it means that it does not have a globally addressable IP address. In other words, other machines cannot initiate a conversation with your machine. You can tell if you are behind a NAT using the program ipconfig in Windows. If your address starts with a 10 or 192, e.g., 192.168.1.1, you are behind a NAT. Most home networks are behind a NAT. Note: without special effort you cannot operate a Genesis II Container behind a NAT: your distribution can perform client activities, but not server activities.

====Firewall====
A firewall is a hardware or software component that filters incoming network packets. If you are behind a firewall you will need to have your firewall administrator open port XXX to your machine if you wish to be a Genesis II Container. In order to open the Windows firewall on Windows machines you must have administrator privileges on a Windows machine to run a Genesis II Container. Note that NATs and firewalls do not usually affect the ability to be a Genesis II client.

====RNS Namespace====
[https://forge.gridforum.org/sf/go/doc8272?nav=1 RNS] stands for the “Resource Namespace Service” specification. RNS is a standard way of building directory structures in Web Services. An RNS namespace allows us to hierarchically organize Grid resources using familiar path strings, such as /home/grimshaw/myfile.

When you “connect” to a Grid, you are effectively telling your Genesis II distribution the location and identity of the “root” RNS directory.


==Client Role==
The Genesis II distribution provides a variety of tools and interfaces for accessing remote data and computing resources in the Grid from the client host. In this section, we address the activities of (a) accessing filesystem-like data and (b) running and managing remote computing jobs.

====Access to Data Resources====
Genesis II uses the [https://forge.gridforum.org/sf/go/doc8272?nav=1 RNS] and [http://www.ogf.org/gf/group_info/view.php?group=byteio-wg ByteIO] standards to provide familiar directory and file interfaces for datagrid resources. Genesis II provides four primary interfaces for creating, browsing, and accessing remote Grid data:

{| class="wikitable"
|width=20% bgcolor=E6E6FA valign="top"|
=====[[Genesis_II_Commands|Grid Shell]]=====
|
The Grid Shell is a command-line tool that provides a text-based interface to the Grid RNS namespace, similar to most Unix and Windows command shells.

The Grid Shell is invoked by invoking the Genesis II “grid” script from a Windows or Linux command shell. The Grid Shell persists a “session” of grid credentials and the “present working directory” in the Grid RNS namespace, and supports a number of familiar commands such as [[ls]], [[cd]], [[mkdir]], [[cp]], [[login]], [[run]], [[qsub]], and a simple scripting language.
|-
|bgcolor=E6E6FA valign="top"|
=====[[Ftpd|Local FTP]]=====
|
Genesis II distributions can operate a simple, easy-to-use FTP daemon from which local FTP clients (e.g., Windows Explorer) can access the Grid namespace and file-like data resources. The Genesis II FTP daemon serves as a proxy between local FTP clients and the Grid. The security concerns of FTP are addressed by the restriction that FTP access is only granted to local programs.
|-
|bgcolor=E6E6FA valign="top"|
=====[[The Installable File System for Windows XP|Windows Installable Filesystem (IFS)]]=====
|
The Genesis II Installable File System for Windows XP allows users to map the Grid RNS namespace as a Network Drive (e.g., the G: drive). Users already familiar with the traditional File Explorer interface provided in Windows XP will have little trouble adjusting to the IFS. When mounted as an IFS filesystem, Windows programs can transparently create, delete, read, and write Grid files and directories. The IFS also provides a convenient interface for copying Grid data to/from the local filesystem.
|-
|bgcolor=E6E6FA valign="top"|
=====[[OGRSH|OGRSH (Linux I/O Shim)]]=====
|
OGRSH is a Linux “library shim” that traps library calls made by existing applications and redirects them to the Genesis II Grid. Native programs and applications (e.g., bash, cp, ls, etc.) can transparently interface with remote Grid resources when run “on top of” OGRSH.
|}

====Access to Computing Resources====
Applications can be executed on remote computing hardware using Basic Execution Service (BES) Grid resources. [http://www.ogf.org/gf/group_info/view.php?group=ogsa-bes-wg BES] is a standard Web Services interface for creating and managing jobs. To run a job on a BES resource, you need a [http://www.ogf.org/gf/group_info/view.php?group=jsdl-wg JSDL] (XML) document that describes your application in terms of where to obtain the program executable and input data sources, and where to place any results. Genesis II Grids may also contain Queue resources that can be used to throttle and schedule jobs on multiple BES resources.

BES and Queue resources are typically linked into the Grid’s RNS namespace. Users can run jobs on a specific BES/Queue resources using one of several interfaces:
*The Grid Shell’s [[run]] command. The primary arguments of the run command are the location of a JSDL document and the RNS path to a BES resource.
*The Grid Shell’s [[qsub]] command. The primary arguments of the qsub command are the location of a JSDL document and the RNS path to a Queue resource.
*By “copying” a JSDL file “into” a Genesis II BES or Queue resource. What does this mean? Our Genesis II BES and Queue resources also implement the RNS directory interface, yet overload the normal file-creation semantics such that when a JSDL file is “copied into” a BES/Queue resource, the implication is that the job is to be submitted to that resource. Thus jobs can be started on Grid resources by simply using any one of “data access” interfaces from the previous section. For example, one can use the IFS interface to “drag-and-drop” JSDL files into BES resources.

Because BES and Queue resources implement the RNS directory interface, their contents can also be “listed” using any of the namespace-browsing interfaces from the previous sections. In their case, the semantics of a directory-listing request are to return the job activities currently managed by that BES/Queue resource. The Genesis II Queue resources also can be manipulated using a variety of command line tools (e.g., [[qstat]], [[qlist]], [[qkill]], [[qcomplete]], etc.).

More information regarding the deployment and execution of jobs can be found in the [[Genesis II FAQ]].


==Server Role==
When hosting data or computing resources, a distribution must operate a Genesis II Container. The Genesis II Container is a lightweight web application container that responds to Web Services messages on incoming HTTP/HTTPS connections.

====Hosting arbitrary Grid Resources====
By operating a Genesis II Container, you can allow Grid resources (e.g., job Queues, RNS and ByteIO resources, IDP resources, etc.) to be hosted by your container. The ability to create such resources is dependent on the [[Genesis_II_Security_Overview#Access Control|access-control]] policies that you configure, of course. For example, you can use the [[mkdir]] Grid Shell tool to place a new subdirectory on a particular Genesis II Container. Any RNS and ByteIO resources created within that subdirectory will also be located within your Genesis II Container.

====Hosting and Sharing Data====
In many cases, the file and directory data that you wish to share already exists on a local filesystem. In this case, it is much more efficient to “share” the data directly into the Grid, as shown below.


<center>[[Image:Export-concept.jpg]]</center>


What does it mean to “share” or “export” data? The basic idea is really simple. Suppose you have a directory (also called a “folder” in Windows) on your hard drive that you want to share with a friend or colleague. You can use the Genesis II [[export]] Grid Shell command. Invoked without any command-line options, the export command starts up a simple GUI (which requires X-windows Linux environments). The GUI allows you to specify a local directory path that you want to export, and the directory path where you want to place it in the global RNS name space. The process is similar to mapping/mounting a drive, except that you are mounting a portion of your local filesystem into the Grid namespace.

Once exported, the directory and its contents can be manipulated both via local users and via Grid users (see Section 3). Updates made by local users are visible by remote users, and vice versa. Access by remote users is governed by [[Genesis_II_Security_Overview#Access Control|access-control]] mechanisms. The [[Genesis_II_Security_Overview#User-Principal Identities|identity(ies)]] carried by the user-principal who performed the export are given initial, exclusive grid access to the exported resources. After performing an export, you will typically modify the access-control policies for the newly-exported resources to specify which users and groups can read, write, and execute (i.e., make subdirectories) these exported resources.

====Hosting Computing Resources====
By default, a BES resource is also started within a Genesis II Container. Those users who do not wish to allow jobs to be run on their machine need not worry: the BES resource is inert by default. Access control to BES resource is set to the user who executed the installation, and may be extended to other users (or services, such as Queues). If such access is not extended, no jobs may be scheduled on it.
December 08, 2011, at 02:14 PM by 128.143.136.101 -
Changed line 1 from:
(Title:GENESIS II DISTRIBUTION:)
to:
(:Title GENESIS II DISTRIBUTION:)
December 08, 2011, at 02:14 PM by 128.143.136.101 -
Changed line 1 from:
(:GENESIS II DISTRIBUTION:)
to:
(Title:GENESIS II DISTRIBUTION:)
December 08, 2011, at 02:13 PM by 128.143.136.101 -
Added line 1:
(:GENESIS II DISTRIBUTION:)