DYNES-Deployments

[Jason Zurawski <>]

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