Changes between Version 4 and Version 5 of GeniRacks


Ignore:
Timestamp:
03/15/12 11:11:13 (7 years ago)
Author:
chaos@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GeniRacks

    v4 v5  
    6969   b. Support remote access to Admin and Operator accounts for local site admins and GENI operations staff with better than username/password control (e.g. remote terminal access with SSH key)
    7070   c. Implement functions needed for remotely-controlled power cycling the rack components, and ensure that rack components reboot automatically after a power failure or intentional power cycle.
    71    d. Implement functions needed to execute current Emergency Stop ( see http://groups.geni.net/geni#Documents ).  Rack teams are expected to implement changes to the GENI adopted Emergency Stop procedure and deploy them in racks no more than 3 months after they are approved at a GEC.
     71   d. Implement functions needed to execute current Emergency Stop ( see http://groups.geni.net/geni/wiki/GpoDoc ).  Rack teams are expected to implement changes to the GENI adopted Emergency Stop procedure and deploy them in racks no more than 3 months after they are approved at a GEC.
    7272   e. Provide remote ability to determine and change active IP addresses on all addressable rack resources (including VMs).
    7373   f. Provide remote ability to determine MAC addresses for all rack resources (including VMs).
     
    102102
    103103 1. Sites provide space, power (preferably with backup), and air conditioning, network connection for both layer2 (Ethernet VLAN) and layer3 data plane connections to GENI, and publicly routeable IP addresses for the rack (separate control and data plane ranges).  Addresses should be on an unrestricted network segment outside any site firewalls.  All addresses dedicated to the nodes should have registered DNS names and support both forward and reverse lookup.  Racks should not be subject to port filtering.  Rack teams must document their minimum requirements for all site-provided services (e.g. number of required IP addresses) and provide complete system installation documentation on a public website (e.g. the GENI wiki).
    104  2. Sites must operate racks according to the most recent version of the GENI Aggregate Provider's Agreement and the GENI Recommended Use Policy (see http://groups.geni.net/geni#Documents ).  Rack teams must implement functions that allow site and GENI operations staff to monitor all rack nodes for intrusion attempts and abnormal behavior to support execution of the GENI Recommended Use Policy.
     104 2. Sites must operate racks according to the most recent version of the GENI Aggregate Provider's Agreement and the GENI Recommended Use Policy (see http://groups.geni.net/geni/wiki/GpoDoc ).  Rack teams must implement functions that allow site and GENI operations staff to monitor all rack nodes for intrusion attempts and abnormal behavior to support execution of the GENI Recommended Use Policy.
    105105 3. Sites must provide at least two support contacts (preferably via a mailing list), who can respond to issues reported to GENI or proactively detected by monitoring.  These contacts will join the GENI response-team@geni.net mailing list.  Rack teams must implement functions that the site contacts can use to assist with incident response (e.g. site administrator accounts and tools).  In particular, rack teams must support functions needed to respond to Legal, Law Enforcement and Regulatory issues with the GENI LLR Representative (e.g. ability to identify rack users by email address).
    106106 4. Sites must inform GENI operations of actions they take on any open GENI issue report via the GMOC ticketing system.  Rack teams should not establish parallel reporting requirements, and should not change deployed systems without opening and maintaining GMOC tracking tickets.