MWSG 8 Conclusions

Below are the conclusions from the 8th MWSG meetiing, held at CERN on March 7-8.

Ake Edlund
EGEE Sec Head


1) TONIC - Taskforce Organizing Nearterm Interoperation for Credentials

TONIC is a good idea, but  who will participate in it? Focus should on between EGEE and OSG for us (MWSG).

From GGF16: Charter for a TONIC group

Taskforce Organizing Nearterm Interoperation for Credentials

Community group formed to develop interoperation agreements to  
support various levels of interoperation between grids participating  
the the Grid Interoperation Now (GIN) activity. Create documents  
defining interoperation agreements for levels of interoperation. Act  
as an intermediate between the immediate needs of the production grid  
interoperation actions and the standards development process.
 
2) VO naming

The VO name is a string, used to represent the VO in all interactions
with grid software, such as in expressions of policy and access rights.

The VO name MUST be formatted as a subdomain name as specified in
RFC 1034 section 3.5. The VO Manager of a VO using a thus-formatted name
MUST be entitled to the use of this name, when interpreted as a name in the 
Internet Domain Name System.
This entitlement MUST stem either from a direct delegation of the 
corresponding name in the Domain Name System by an accredited registrar for
the next-higher level subdomain, or from a direct delegation of the
equivalent name in the Domain Name System by ICANN, or from the consent
of the administrative or operational contact of the next-higher equivalent
subdomain name for that VO name that itself is registered with such an
accredited registrar.

Considering that RFC1034 section 3.5 states that both upper case and lower
case letters are allowed, but no significance is to be attached to the case,
but that today the software handling VO names may still be case sensisitive,
all VO names MUST be entirely in lower case.

3) glexec on WN

The gLite software will support a deployment model where glexec is run on
worker nodes. Although technically possible today, enhancements towards
centralised policy coordination are needed for scalable deployment, that
and should be ready by July '06.
Glexec can then be deployed on the head node (as today), and on the worker
nodes. A "null" operational mode will be provided for glexec, so that is can
be run without setuid capability. In that case, running glexec will of
course not enable discrimination of the different users' actions.

Deployment of a setuid-capable glexec on the worker nodes is objected to by 
Ruth (from OSG) as it makes the setup unneccesarily complicated.
The conclusion was to get some more comments from the site
operations side. Ian Neilson sent a request for comments to some people in
SA1/3, but hadn't received any last time I talked to him.

In a future model, job requests can have to be signed - together with the
sandbox (in/out) - to give additional confirmation of the users intent to 
run a job.