TWiki> EGEE Web>EGEEgLite>EGEEgLiteJobPriorities (revision 5)EditAttachPDF

Job Prioritization resources

About VOMS FQANs

Some facts good to be aware of:

  • The current format of the FQAN: /dteam/certification/Role=NULL
  • The first 'tag' of the group attribute is always the VO name. In the above example it is dteam.
  • A VOMS proxy can arrive with several FQANs , out of this the first one (the primary) FQAN could have special meaning.
  • It is not possible to have FQAN with no group membership, one always belongs to the 'base' group i.e. to the VO.
  • One always automatically become the member of all his/her group when creating a VOMS proxy.
  • It is not possible to ask for the exclusion of one or several group from the VOMS proxy.
  • One has to explicitly request the Role= attribute, requests without this will results Role=NULL
  • In one FQAN only one Role is allowed, however secondary FQANs could contain additional Roles.
  • As default, Roles are not inherited to subgroup. If one has /Role=production in let's say the /dteam group and at the same time (s)he is member also of the /dteam/certification group, (s)he cannot ask for a proxy having FQAN /dteam/certification/Role=production . The /Role=production has to be explicitly granted to her/him inside the subgroup , as well.

Interpretation of FQANs in LCMAPS

Versions

The glite-CE and lcg-CE are using different versions of LCMAPS.
  • The glite-CE (and all othe glite services) uses glite-security-lcmaps-1.3.6-1,
  • while lcg-CE uses edg-lcmaps_gcc3_2_2-0.0.30-1_sl3.

Matching mechanism

The matching procedure contains the following steps:

  • LCMAPS treats the first (primary) FQAN specially: it must match a rule in the gridmapfile and it determines the UID and the primary GID.
  • Subsequently all secondary FQANs are tried against the groupmapfile, to pick up as many secondary GIDs as possible.
  • For each secondary FQAN the scan is stopped after the first match.
  • It is not an error for some secondary FQAN not to match at all.

So, as far as job priorities are concerned, only the primary FQAN matters.

Interpretation of wildcard characters

In the glite version

In order to match the this FQAN

/atlas/Role=NULL/Capability=NULL

one can use wildcard characters in the following combinations. The followings will all match again the above 'target' FQAN. (Please note, that we just took the /Capability=NULL as an example, this attribute is deprecated!)

/atlas/*
/atlas/*/Role=NULL/Capability=NULL
/atlas/Role=*/Capability=NULL
/atlas/*=NULL/Capability=NULL
/atlas/Ro*/Capability=NULL
/atlas/Role/
/atlas/*=NULL/Capability=NULL
/atlas/*R*C* 

In the edg version

TO BE COMPLETED

Interpretation of FQANs in the Match-Maker

TO BE COMPLETED

Matching mechanism

TO BE COMPLETED

Interpretation of wildcard characters

Here are some example to demonstrate how the matching works:

  • Will match:
        "/cms/Higgs*"                 "/cms/Higgsino"
        "/cms/Higgs/*"                "/cms/Higgs/somesubgroup"
        "/cms/Higgs/some*/Role=some*" "/cms/Higgs/somesubgroup/Role=somerole"
       

  • Will NOT match:
         "/cms/Higgs"        "/cms/Higgsino"
         "/cms/Higgs/*"      "/cms/Higgs"
         "/cms/Higgs/some*"  "/cms/Higgs/somesubgroup/Role=somerole"
         

It means that the '*' character is interpreted separately inside the group and inside the role, since they are (should be) ortogonal to each other.

Interpretation of FQANs and mapping of users in DM

The DPM storage

DPM deals with 3 different mapping scenario:
  • Request arrive to namespace with voms-proxy
  • Request arrive to namespace with plain grid-proxy
  • Request arrive out of namespace

Depending on the above situation different mechanism used to find the user's mapping. Request is in namespace when file path starts with /dpm.

  1. Request arrive to namespace with voms-proxy
    • The certificate DN is matched against the virtual user database to determine the UID. If no matching found a new user is automatically created.
    • The certificate VOMS extensions are examined (all of them) and matched againts the virtual group database. Request will be granted with the matching group's membership, non matching FQANs will result automatic creation of new groups correspond to them. So there is no requirements that the primary FQAN must match.
  2. Request arrive to namespace with plain grid-proxy
    • The certificate DN is matched againts the virtual user database to determine the UID. If no matching found a new user is automatically created.
    • The certificate subject DN is matched against the /opt/lcg/etc/lcgdm-mapfile which assigns a VO name/membership to the request. Then the request will be granted with group membership corresponds to that VO (i.e. to that string) in the virtual group database. In this case no secondary groups are possible, parsing stops at the first matching entry of lcgdm-mapfile.
  3. Request arrive out of namespace
    • The /etc/grid-security/grid-mapfile is used to determine the matching. The first matching entry will be the request's UID and the unix secondary groups of this UID will be the request's groups. The request is then mapped to that unix account, that's why DPM still need pool account to be created.

DPM user mapping mechanism does not involve LCMAPs.

The Castor storage

In Castor there is no handling of VOMS FQANs and secondary groups, request are mapped to pool accounts per VO.

The dCache storage

In dCache there is no handling of VOMS FQANs and secondary groups, request are mapped to one account per VO.

The LFC service

LFC deals with 2 different mapping scenario:
  1. Requests arrives with voms-proxy
  2. Requests arrives with grid-proxy

Depending on the above situation different mechanism used to find the user's mapping. Request can arrive only to namespace i.e to /lfc.

  1. Requests arrives with voms-proxy
    • In this case LFC uses virtual group and user IDs and the mapping proceeds exactly in the same way as on case of DPM 1.)
  2. Requests arrives with grid-proxy
    • In this case LFC performs the same mapping procedure as in case of DPM 2.)

Since no request can arrive out of name space, no pool accounts are needed on LFC. LFC user mapping mechanism does not involve LCMAPs.

The FTS service

The FTS is not VOMS aware. Channel managers can be defined using their certificate subject DN.

Links

-- ClaudioGrandi - 26 Jun 2007

Edit | Attach | Watch | Print version | History: r14 | r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r5 - 2007-06-26 - GergelyDebreczeni
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EGEE All webs login

This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright & by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Ask a support question or Send feedback