DYNES-Deployments

[Jason Zurawski <>]

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 
> [mailto:]
>  
> 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 
>> [mailto:]
>> 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
>>>>>> **********************************