DYNES-Deployments

[Malathi Veeraraghavan <>]

Thanks Alan for volunteering to set up a DYNES VO.
Will this allow us to have root access?

We are developing transport protocols to run over virtual circuits, and often need
to execute privileged-user commands.

At UVA, we are not familiar with OSG tools, but can learn. The only concern is the root access.

We have been using U. Utah's Emulab. Their sharing method allows users to
make reservations and obtain complete access to the PCs. Their Web site notes:
"An emulated experiment allows you to specify an arbitrary network topology, giving you a controllable, predictable, and repeatable environment, including PC nodes on which you have full "root" access, running an operating system of your choice."

They developed the ProtoGENI software for the GENI project and I hear a number of other facilities
are using this software.  Can we use this for DYNES?

Thanks
MV


   

On 9/4/2012 10:10 AM, Jason Zurawski wrote:

Hey Alan;

That would be outstanding.  

Not everyone may be familiar (including me) with some of the acronyms you through out below.  I think there is a mix of those that understand OSG from the ATLAS/CMS communities, but an equal if not greater amount of networking people who don't support that on a day to day basis.  Any pointers you can throw out would be helpful to bring everyone up to speed.  

Thanks;

-jason

On Sep 4, 2012, at 10:06 AM, "Ross, Justin"  wrote:

I am definitely in favor.

-----Original Message-----
From: Sill, Alan [] 
Sent: Tuesday, September 04, 2012 9:05 AM
To: Ross, Justin
Cc: Jason Zurawski; ; ; ; Meikle, R. Bruce; Malathi Veeraraghavan; Dillaway, Wilson; Eric Boyd; Shawn McKee; Harvey Newman; Sheldon, Paul D
Subject: Re: [dynes-deployments] Request for login access on your DYNES end hosts

Thanks, all. 

I am willing to run a VOMS server for DYNES so that we can leverage the OSG tools. Among us, it sounds like there is adequate expertise in running the local authorization tools such as GUMS that we can set things up and help those who need such local expertise. 

We can leverage InCommon identity management through COLogon service:

https://cilogon.org/

Those who are at institutions at an InCommon Silver level or higher can get OSG-compatible certificates directly. Those with InCommon at institutions that are not at this level can still get certificates through the Basic service that will work the same, but that might require additional setup at each site for us to add this to the trusted CA providers and verification through VOMS. 

(With a little work, we can even hide this stuff through a portal via the CILogon tools.)

So are people OK with the idea of setting up a DYNES VO?

Alan


On Sep 4, 2012, at 8:40 AM, "Ross, Justin"  wrote:

Jason,

Thanks for all of the info listed.  

I don't think any of us are expecting or asking Internet2 or DYNES to provide us with central accounts or account management.  I think that there are a few of us that would be interested in using OSG and their existing infrastructure to allow for central account management.  I don't think this will impact DYNES at all, but will allow us an easy way to deal with accounts.  

Thanks,
Justin

-----Original Message-----
From: Jason Zurawski []
Sent: Tuesday, September 04, 2012 8:15 AM
To: ; Ross, Justin; Alan Sill; 
; ; 
Meikle, R. Bruce; Malathi Veeraraghavan; Dillaway, Wilson
Cc: Eric Boyd; Shawn McKee; Harvey Newman; Sheldon, Paul D
Subject: Re: [dynes-deployments] Request for login access on your 
DYNES end hosts

Hi All;

To address some of the discussion from this past weekend, please start by first referring to the information on this matter sent in June (this content was used to make the FAQ item that Malathi originally noted):


https://lists.internet2.edu/sympa/arc/dynes-deployments/2012-06/msg000
01.html

To paraphrase: 

1) After a site is commissioned, 'DYNES' maintains accounts to prevent catastrophic failure, but will not be operating any aspect of a local site on a day to day basis.  Resources were not provisioned in the grant for a central authority to maintain equipment on a site by site basis, and there are no plans to change this.  The Internet2 ION service itself, the resource everyone is connected to on a national basis, is maintained by a 24/7/365 NOC and will remain as such.  

2) Local staff are responsible for the operation, maintenance, and access control to the local pieces (e.g. data movement server, controller pc, and local switch under dynamic control) of the distributed facility.  'DYNES' can help, but the cutoff is firmly set at Aug 2013.  Steps must be taken now to prepare for this, including setting up monitoring and familiarization with the software stack in use (e.g. the Linux operating system, FDT data movement application, and OSCARS control software).   

3) There is not a universal access layer similar to other distributed computing projects (e.g. GENI or OSG).  This is due to the lack of staff to manage it now, and in the future.  

4) Local security policies trump all others that we may ask to be put in place, and will naturally differ from facility to facility.  TTU may have stronger requirements on visiting users than UDel.  In either case - a closed research environment is not useful.  While we do not provide a turn key solution to enable local (or remote) users, solutions exist and must be implemented on a local basis.  We envision site level policies will:

a) makes sense from a security point of view

b) are technically possible to install and maintain

c) are not overly prohibitive to potential users

d) encourage innovation on the NSF investment

To answer specific items from below:

Wilson - DYNES is not directly affiliated with InCommon other than by 
the intersection of schools that are in both.  We do not have a way to 
leverage InCommon federated identity due to the aforementioned 
discussion of available resources and project scope.  A listing of 
InCommon schools is available here: 
http://www.incommonfederation.org/participants/ and a list of DYNES 
participants (and others affiliated through the dynamic circuit 
topology) is available here: 
http://www.internet2.edu/ion/images/20111208-DYNES.png

Justin/Bruce: Local accounts are our recommendation based on the above discussion, and we cannot offer alternatives.  However, this will not stop the DYNES community from implementing a federated login method if there are volunteers to provide instructions, and maintain the core functionality as a service.  

Alan: I apologize that the server did not have the storage configured.  If you run into problems doing this on your own, please let me know.  We will verify all other FDT servers to be sure there are not others left in this state.  

The PIs have been CCed on this mail, and would be happy to address any additional concerns from the community going forward.  

Thanks;

-jason

On Sep 2, 2012, at 4:39 PM, Wilson Dillaway  wrote:

Jason,
  How closely does the DYNES membership map to InCommon membership?

             Wilson


On 9/2/2012 4:30 PM, Ross, Justin wrote:

I personally will second Alan's comments and the desire not to maintain a bunch of local accounts.

Justin

On Sep 2, 2012, at 3:24 PM, "Sill, Alan"  wrote:

Hi Malathi,

We are still configuring our DYNES FDT node, which arrived (after release from our local network group) configured with the DYNES adn FDT software, but without its storage configured or any interfaces to account mapping for setting up transfers.

The use case for having a local account on each machine is not clear.  Perhaps it would help if your were to describe a set of operations that you would like to try.  Our university policies do not allow us to provide direct access to anyone except identified guest researchers, but we do have a setup in place that allows mapping of members of grid VOs to local accounts for job execution.  We can also support GSI-secured SSH logins to local non-privileged user accounts through GSI-OpenSSH for OSG and other grid VO members.  (University of Virginia is, for example, a member of the SURAgrid VO, which would provide a mechanism in your case if the VO approves.)  To do this, we would have to install grid client access and the account would have to be able to carry out its needed functions through non-privileged access.

Would this be OK?

Alan Sill
Texas Tech University

On Sep 2, 2012, at 11:19 AM, Malathi Veeraraghavan wrote:

Dear fellow DYNES participants,

We would like to start testing our software between multiple DYNES 
hosts and test the use of dynamic circuits. Since accounts are 
under local site control, we are writing to you all to request access.
Please see the answer to Q13 of the FAQ site that Jason Zurawski created:
http://www.internet2.edu/ion/faq.html

We will reciprocate by offering login access on our DYNES endpoint. 
We look forward to your responses.

Thanks
MV

--
**********************************
Malathi Veeraraghavan
Professor, Charles L. Brown Dept. of Elec. & Comp. Engineering 
University of Virginia
1-434-982-2208
1-203-904-3724 (cell)
http://www.ece.virginia.edu/mv
**********************************

-- 
**********************************
Malathi Veeraraghavan
Professor, Charles L. Brown Dept. of Elec. & Comp. Engineering
University of Virginia
1-434-982-2208
1-203-904-3724 (cell)
http://www.ece.virginia.edu/mv
**********************************