Download GLITE 3.0 USER GUIDE

Warning: This mechaism for automatic upload of a specified output by using the OutputData is not longer
supported by the gLite WMS.
Example 7.7.4
(Selecting the file catalog to use for match making)
In order for the RB to select CEs that are close to the files required by a job (by the InputData attribute), it has
to locate the SEs where these files are stored. In order to do this, the RB uses the Data Location Interface service,
which in turn contacts some file catalog. Since it is possible that several different file catalogs exist on the Grid,
the user has the possibility to select which one he wants to talk to by using the JDL attribute DataCatalog. The
user will specify the attribute and the endpoint of the catalog as value, as in this example:
DataCatalog = "http://lfc-lhcb-ro.cern.ch:8085/";
If no value is specified, then the first catalog supporting the DLI interface that is found in the information
system is used (which should probably be the right choice for the normal user).
NOTE: Only catalogs that present a DLI interface can be talked to by the DLI service. Currently, the RLS
catalog does not provide such interface, and so in order to use this catalog, the RB is configured to interface directly
with it (without using the DLI). Thus, summarizing, the RB can be configured to either talk to the RLS catalog or
to use the DLI. In the second possibility, the user has the option to manually specify the endpoint of the catalog he
wants to use.
7.8.
ACCESSING
FILES ON G L ITE
7.8.1. VOMS interaction
While the WMS relies on the LCMAPS mechanism for getting local UID/GID on the user voms proxy presented
basis, the DMS implements the concept of Virtual Ids. They are site independant identifiers and do not require
any administrator action. A DN is mapped to a a virtual uid and a VOMS group or role to a virtual gid. They are
currently used by LFC and DPM. Only te virtual uid and the primary virtual gid (i.e. the ID mapped to the primary
group as intended in [chapter for VOMS]) are used to control access to the File Catalog entries or the file on the
Storage Elements.
Unless changed with chown the files are owned by the DN of the user who created the file; the group ownership
depends on the S ISGID value of the parent directory: if it is set, the file group ownership is the same as the parent
one, if not the primary group of the user is used.
The LCG Data Managements is also designed for supporting secondary groups. Secondary groups are useful
as explained by this example: Let’s suppose a given user dressing the “production” role needs to access some
collective files whose group ownership is “lhcb”. Let suppose these files are not world readable. In this case, if
secondary groups are not supported (and then the user is not seen from the ”lhcb” group), - unless not explicitely
set by an accessing ACLs giving “lhcb/Role=production” as supplementary group - the user cannot access these
files.
CERN-LCG-GDEIS-722398
Manuals Series
Page 121