Hi Patricia,
I think that YAIM has done a very good and standard configuration for
the geant4 VO.
As a rule (of thumb), the VO's (official) name, taken from the
VOS="atlas alice... geant4" line (inside the YAIM site definition file)
should appear everywhere:
.<vo name> in the grid-mapfile //For geant4, I got only
.geant ...
<vo name>sgm in the grid-mapfile //No geant4 sgm users yet, I
expect geant4sgm
<vo name>001 - <vo official name>050 for the range of mapped users
<vo name> for the group name
<vo name>sgm for the sgm user
<vo name> as a queue name
<vo name> as a storage directory name
<vo name> as a exp_soft directory name, etc.
I am looking for the first time into the way the certificates/users
mapping happens.
Since the grid-mapfile holds only the certificate signature it seems
impossible (for now) to make the same certificate belong to more than
one VO. Therefore we need different signatures ergo different
certificates for the same owner.
(A) It would be nice to have a way (maybe I am just not aware of it) of
using a unique certificate and just telling that for a certain
circumstance one would like to impersonate a VO membership of its
choosing (one has to be member of that VO too, so that it would work...)
In such a case, a site will look into the grid-mapfile for the
certificate signature on the same line with the requested VO mark
(.geant4, geant4sgm, .atlas, .alice, etc.).
Since entries into the grid-mapfile appear to come from different vomss
servers it would be ok to have more than one line for the same signature
and not necessarily the ideal situation where the same signature line
would hold all the allowed VO mappings.
(B) Now, since the membership is established by talking to the VO's
official vomss server, a site could decide to "remap" its local view of
user/group names to something (completely) (slightly) different and that
something should be exactly what is written into the VOS="atlas alice...
geant4" YAIM site definition line. Only the request should come with an
official VO name. And only the vomss URL should be real in the VO_<vo
name>_VOMS_SERVERS="..." YAIM site definition line. The site should keep
the translation table <vo official (supported) name>/<vo (local) name>
for all mapping checks.
(But I would go for official names only, without a translation table
mechanism.)
(A) would be good, in my opinion, to have anyway.
Regards,
Dan
P.S. If YAIM would be able to generate a geant4sgm mapping for the
geant4 VO I could forget about both (A) and (B) surely... :-)
Patricia Mendez Lorenzo wrote:
> In the meantime and in order to use this site for the geant4
> production, could it be possible a manual fix?
>
> Patricia
>
> El 07/12/2005, a las 6:44, Dan Schrager escribió:
>
>> I am a yaim "compliant" site.
>> yaim should maybe fix a small inconsistency: the "root" for all
>> names should be the vo's name as defined in the VOS="atlas ...
>> geant4" line.
>> anyway jobs do run well for geant4 here :-)
>>
>> Patricia Mendez Lorenzo wrote:
>>
>>> Hello Dan,
>>>
>>> The vo is called geant4 because geant4 is the name of the
>>> community and geant4 should not cause any problem
>>> in any configuration file. only geant has other meanings, so it is
>>> important to realize that we speak abuot geant4 and
>>> not about geant. It is not the 1st case with numbers inside the
>>> name of the VO, for example na48 is another example.
>>>
>>> The grid-mapfile can read .geant4. Actually in other sites .geant4
>>> appears inside the grid-mapfiles.
>>>
>>> at least what we realized at cern is the number of characters
>>> included in the pool accounts. i think 8 characters is the
>>> maximal. geant4001has 9.
>>>
>>> Patricia
>>>
>>> El 06/12/2005, a las 23:30, Dan Schrager escribió:
>>>
>>>> why don't you call the vo geant ?
>>>> why the grid-mapfile doesn't read .geant4 ?
>>>> who cares about the range of mapped users, 4001-4050 is as good
>>>> as 001-050 ?
>>>>
>>>> Patricia Mendez Lorenzo wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>>>
>>>>>> VOS="atlas alice lhcb cms dteam sixt zeus see geant4"
>>>>>>
>>>>>> VO_GEANT4_SW_DIR=$VO_SW_DIR/geant4
>>>>>> VO_GEANT4_DEFAULT_SE=$SE_HOST
>>>>>> VO_GEANT4_VOMS_SERVERS="vomss://lcg-voms.cern.ch:8443/voms/
>>>>>> geant4?/ geant4"
>>>>>> VO_GEANT4_STORAGE_DIR=$CE_CLOSE_SE1_ACCESS_POINT/geant4
>>>>>> VO_GEANT4_QUEUES="geant4"
>>>>>>
>>>>>> The mapped users I've defined are geant4001-geant4050 and
>>>>>> geant4sgm. The group is geant4.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This could couse a problems, because the accounts are seen going
>>>>> from 4001 to 4050 (the "4" is counted
>>>>> as part od the number account). So I would suggest to define the
>>>>> pool accounts from geant001 unti geant050 (without the
>>>>> number 4), the sgm account, the same: geantsgm. and yes, the
>>>>> name of the vo is geant4.
>>>>> I can check a submission to WEIZMANN with the geant4
>>>>> certificate. i let yoou know.
>>>>>
>>>>> Patricia
>>>>>
>>>>>
>>>>>> Could you please confirm that it is all right ?
>>>>>>
>>>>>> I have noticed however that in the /etc/grid-security/grid-
>>>>>> mapfile there are two new geant(4) users that are mapped to
>>>>>> .geant -- WITHOUT A 4--
>>>>>> Is this OK ?
>>>>>>
>>>>>> The 4 seems a problem for me. Is it ? Could any of the geant4
>>>>>> certificate holders submit a job to WEIZMANN-LCG2 and tell me
>>>>>> whether the results are OK ?
>>>>>>
>>>>>> Regards,
>>>>>> Dan
>>>>>>
>>>>>
>>>>> +++++++++++++++++++++++++++++++++++++++++++
>>>>> This Mail Was Scanned By Mail-seCure System
>>>>> at the Tel-Aviv University CC.
>>>>
>>>>
>>>>
>>>>
>>>
>>> +++++++++++++++++++++++++++++++++++++++++++
>>> This Mail Was Scanned By Mail-seCure System
>>> at the Tel-Aviv University CC.
>>
>>
>>
>
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
|