Implement community accounts under a UNIX system, allowing for a wide variety of configurable options. The following options should be implemented:

• "chroot" jailing
• automated generation of temporary accounts
• job launching via both ssh and GRAM
• job management control

Include utilities for automated account creation, account configuration, and general feature management under a standard UNIX environment.

Include an outline detailing estimated resource requirements (such as quota and special server needs.)

In collaboration with the NCSA Allocations group and the NCSA Information Resources Group (IRG), design and implement an NCSA-specific solution to community account allocation. This design will include all database schemas that need to be implemented to manage a community account on the resource level and should be more broadly applicable as a guidelines document for other resource sites.

Implement a general solution to community mass storage needs. This solution may require the installation/implementation of a dedicated server on the mass storage machines, or may ride on top of some other common server.

The primary requirement of this implementation is that end users are allowed to directly access their own files, but not those of any other user.

A secondary goal will a more sophisticated permission system, whereby a user can grant access to specific other users or entire research groups. It should be possible to grant a variety of access levels, ranging from read-only to full control.

This stage will be designed in consultation with the NCSA Storage Enabling Technologies (SET) group, and initially implemented on the NCSA Mass Storage System (MSS).

Implement a means of auditing resource usage. This auditing should occur at the following levels:

• user
• research group
• job
• file access
• resource usage

Auditing information should be available as appropriate. Users should have access to their own auditing information; group PIs should have access to auditing information for their entire group; resource administrators should have access to auditing information relating to their resource and any jobs run on it; et cetera.

Job-level auditing may need to be implemented based on the job management system in place, so a general solution may not be available, but a general approach to solving the job-level auditing problem should still be developed.

Database schemas for storing this auditing information will be developed in consultation with the NCSA Information Resources Group (IRG).

Design a database schema for storing all information relevant to a community account implementation. This database will hold information relating to users (both end users and administrators), research groups (consisting of a set of users and a coordinator / PI), resources (both hardware and software), and individual community accounts. It will also store: auditing data, all certificates, and files manifests for both computation and mass storage resources. It must be a relational SQL database that can be implemented on any common SQL-driven database platform. Design of this database schema will be done in consultation with the NCSA Information Resources Group (IRG).

Create an API to aid in developing gateway sever solutions that access our community account framework. This API should be useful for groups aiming to develop computational communities consisting of community accounts on several resources.

Functions will be included to:

• launch and control jobs under community accounts
• manage access to files stored in a community account, both access via a proxy or direct end user access to files
• fully utilize a database conforming to the schema developed during stage #5
• manage and retrieve auditing information