DYNES-Deployments

["Newsome, Shannon" <>]

Good Afternoon Gentlemen;

I just wanted to check in and see if anything was required of me at this time?

__________________
Shannon T. Newsome, MSM, EIEIO
(806)742-8000


-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Jason Zurawski
Sent: Friday, June 15, 2012 3:27 PM
To: 

Subject: [dynes-deployments] DYNES Account Policies

All;

As one of the first orders of business for the site contact list, we wanted 
to discuss some thoughts the PIs of the DYNES project had regarding account 
management and use of the instrument:

  - Each of the sites have root access to the machines and switches at your 
own site (SSH not enabled) as well as a local 'admin' account (SSH
enabled) to perform management activities.

  - The PIs/staff maintain a 'DYNES' account for access to ensure that the 
distributed instrument is running.

  - The PIs/staff also have rudimentary NAGIOS/Syslog/Rancid monitoring 
running to ensure the overall health of the system.

With regards to the latter two items, we want to re-emphasize that the 
equipment is under your own local control and management.  Since this has 
been integrated into your environments, its up to the end site to set local 
policy as well as maintain local monitoring.  This will help come August 2013 
when our funding ends, and the destiny of this as a Layer 2 solution becomes 
a community effort.  If you have not done so, please consider using 
enterprise monitoring techniques for the equipment.  If you need help, send 
questions to the list and we (and
others!) will offer suggestions.

Lastly, we have recently had a couple of questions from researchers who want 
to use the DYNES testbed for projects.  The question basically comes down to 
an issue of access control.  If a researcher is at Site A (and has a deployed 
DYNES instance) they may want to install some new software (or run a test 
using existing software) at DYNES sites B, C, and D.  The DYNES project 
currently does not have a way to install a single user account on the entire 
enterprise at once, and there are two reasons for this:

  1) We are not running a distributed computing infrastructure (e.g. 
emulab or planetlab), we are running a distributed network instrument. 
We also don't have the tools or manpower to manage accounts for all sites.

  2) We want to facilitate the idea of local control and operation given this 
is a short term project, therefore we do not want to step on the toes of the 
local administrators.

The PIs want to encourage innovation as much as possible.  If you have a 
project (or know of others that are not on this list) that would benefit from 
research on the instrument, we want to see that become a reality. 
We can work with researchers and sites to find the best way to do this. 
  To address this, we propose the following:

  a) We strongly encourage researchers to develop software that can be 
distributed to all sites easily.  We package things in RPM format for CentOS 
5 and 6 (i386 and x86_64 architectures).  If there is a piece of software 
that needs to be distributed, we can work with you to get it out to all sites 
by placing it in our repository after it has been tested.  This way, and end 
site can opt in, and choose to install it via the YUM system

  b) If you desire an account on other sites, this is the forum to ask. 
  Send an email explaining what you want to do, where you want to test 
from/to.  We strongly encourage site administrators to allow researchers a 
remote account, *only* if your local security policies allow it.  The 
accounts should be granted on the data movement server (ideally), unless the 
researcher needs access to the OSCARS server for a specific purpose. 
  SSH public key management is probably the best way to manage access.

These are not set in stone, so please debate this as necessary.  We want to 
be open, but safe in the policies.  As always, please send comments/questions 
on this or other matters.

Thanks;

-jason