XSEDE Publication Initiative

The eXtreme Science and Engineering Discovery Environment (XSEDE) proposes the following program-wide Publication Initiative as a strategy to document and share XSEDE work experiences, innovative activities, lessons learned, and best practices. One of XSEDE’s goals is to “Sustain the Ecosystem,” measured by the following metric: number of staff publications which fulfills the subgoal of how to “Operate an innovative and virtual organization.” The metric also feeds upward into a Key Performance Indicator (KPI) for the entire project. Tracking the number of staff publications produced shows that XSEDE staff are involved in novel activities including those that achieve peer-reviewed publication. For PY7, the target metric will be 30 staff publications posted in the XSEDE User Portal for that Program Year. Historically, XSEDE has periodically emphasized staff entering previous and currently-published works with inconsistent diligence. In response to NSF encouragement, XSEDE will build on what we have been doing and what we have learned as a project and expand by identifying opportunities for both what content we would share with the community and the vehicles for doing so. In order to foster broad representation of XSEDE to the advanced computing community, XSEDE will build into the PY8 plan time for staff to write peer-reviewed papers, technical reports, white papers, and present from these publications derived from their work on XSEDE.Ope

XSEDE Enterprise Services

Through acceptance of the XSEDE Level 1 SP Security Agreement and other contracts, providers of XSEDE central services agree to follow this security baseline document approved by the XSEDE Security Working Group (XSWoG). Because of the natural trust relationships between major XSEDE resources and the interdependence of them, security vulnerabilities affect far more than a single service provider. Therefore, this document sets forth minimum, security standards for providers of central services whose compromise could have a direct impact upon XSEDE. The list of security controls comes both from inherited practices of TeraGrid and new findings in the XSEDE risk assessment.National Science Foundation ACI-1548562Ope

XSEDE Campus Bridging – Cluster software distribution strategy and tactics

This document is both a public document and an internal working document intended to define XSEDE strategies related to XSEDE’s cluster build software distribution project. This is part a strategy document, part tactical.XSEDE is supported by National Science Foundation Grant 1053575 (XSEDE: eXtreme Science and Engineering Discovery Environment)

Methods For Creating XSEDE Compatible Clusters

The Extreme Science and Engineering Discovery Environment has created a suite of software that is collectively known as the basic XSEDE-compatible cluster build. It has been distributed as a Rocks roll for some time. It is now available as individual RPM packages, so that it can be downloaded and installed in portions as appropriate on existing and working clusters. In this paper, we explain the concept of the XSEDE-compatible cluster and explain how to install individual components as RPMs through use of Puppet and the XSEDE compatible cluster YUM repository.This document was developed with support from National Science Foundation (NSF) grant OCI-1053575. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the NSF

What is campus bridging and what is XSEDE doing about it?

The term “campus bridging” was first used in the charge given to an NSF Advisory Committee for Cyberinfrastructure task force. That task force developed this description of campus bridging: “Campus bridging is the seamlessly integrated use of cyberinfrastructure operated by a scientist or engineer with other cyberinfrastructure on the scientist’s campus, at other campuses, and at the regional, national, and international levels as if they were proximate to the scientist, and when working within the context of a Virtual Organization (VO) make the ‘virtual’ aspect of the organization irrelevant (or helpful) to the work of the VO.” Campus bridging is more a viewpoint and a set of approaches to usability, software, and information concerns than a particular set of tools or software. We outline here several specific use cases that have been identified as priorities for XSEDE in the next four years. These priorities include documentation, deployment of software used entirely outside of XSEDE, and software that helps bridge from individual researcher to campus to XSEDE cyberinfrastructure. We also describe early pilot tests and means by which the user community may stay informed of campus bridging activities and participate in the implementation of Campus Bridging tools created by XSEDE. Metrics are still being developed, and will include (1) the number of campuses that adopt and use Campus Bridging tools developed by XSEDE and (2) the number of and extent to which XSEDE-developed Campus Bridging tools are adopted among other CI projects.The work described here was supported by National Science Foundation Award Nos. 0932251, 0503697, 1002526, 1059812, 1040777, 0723054, 0521433, and 0504075

XSEDE Service Provide Checklist (v 3.0)

The document describes the XSEDE Service Providers (SPs) checklist to be used for integration and/or deployment of a new resource in XSEDE, verify an existing resource at an SP site, to coordinate a campus cyberinfrastructure project, or for the exit of a resource from XSEDE.Ope

Evaluating Grid Portal Security

Abstract — Grid portals are an increasingly popular mechanism for creating customizable, Web-based interfaces to Grid services and resources. Due to the powerful, general-purpose nature of Grid technology, the security of any portal or entry point to such resources cannot be taken lightly. This is particularly true if the portal is running inside of a trusted perimeter, such as a Science Gateway running on an SDSC machine for access to the TeraGrid. To evaluate the current state of Grid portal security, we undertake a comparative analysis of the three most popular Grid portal frameworks that are being pursued as frontends to the TeraGrid: GridSphere, OGCE and Clarens. We explore general challenges that Grid portals face in the areas of authentication (including user identification), authorization, auditing (logging) and session management then contrast how the different Grid portal implementations address these challenges. We find that although most Grid portals address these security concerns to a certain extent, there is still room for improvement, particularly in the areas of secure default configurations and comprehensive logging and auditing support. We conclude with specific recommendations for designing, implementing and configuring secure Grid portals. I