El 06/15/2011 11:05 AM, Cristina Aiftimiei escribió:
> Hi Antonio,
>
> Antonio Delgado Peris wrote:
>> Thanks Maarten,
>>
>>>> We've playing around with glexec+Argus (EMI-I release) some more and
>>> Note: EMI-1 release, which is not yet recommended.
>>
>> I know that... now. But we installed it before we actually knew it
>> was not recommended. And, since it is a new service, we thought it
>> wouldn't be so different from gLite release... If it is and somebody
>> knows, please tell us and we'll consider to go to gLite. If that's
>> the case, sorry for complaining about this version (though it's a
>> nice test of EMI, isn't it? :-)).
>>
> a very good test, thank you for this.
> One more question to clarify a little, for me. Did you used/use ARGUS
> "glite"-version, and did not encounter this problems?
> If yes, at least for me is a little strange as "glite" and "emi"
> versions have the same developers.
Nop. I was just replying to Maarten's comment. We never used glite
release. My point was precisely that, being a new service, we thought
both releases would behave the same, and thus we didn't unistall EMI and
we didn't move to glite.
Antonio
>
> Thank you very much,
> Cristina
>
>> Certainly, we have not replaced any existing gLite service with those
>> of EMI.
>>
>> As for the rest, I opened three tickets. Only set the one related to
>> links time as urgent.
>>
>> https://ggus.org/ws/ticket_info.php?ticket=71547
>> https://ggus.org/ws/ticket_info.php?ticket=71548
>> https://ggus.org/ws/ticket_info.php?ticket=71550
>>
>> Cheers,
>> Antonio
>>
>>
>>
>>>> found some inconsistencies between the way CEs and Argus create
>>>> entries
>>>> in the gridmapdir (which is nfs-shared between them). I'm not sure if
>>>> there's a proper list to report these, but if experts could comment,
>>>> we'd be grateful.
>>>>
>>>> So, I have been mapped by both Argus and CE using my CMS proxy with
>>>> "/cmses" group as primary or secondary fqan, as a result there are
>>>> four
>>>> different mappings (first two are from Argus and second two from CE),
>>>> where there should be just two:
>>>>
>>>> [root@gaergus ~]# lt /etc/grid-security/gridmapdir/| grep delgad
>>>> -rw-r--r-- 2 root root 0 Feb 11 2010
>>>> %2fdc%3des%2fdc%3dirisgrid%2fo%3dciemat%2fcn%3dantonio-delgado-peris:cmses:cms
>>>>
>>>>
>>>> -rw-r--r-- 2 root root 0 Sep 7 2010
>>>> %2fdc%3des%2fdc%3dirisgrid%2fo%3dciemat%2fcn%3dantonio-delgado-peris:cms:cmses
>>>>
>>>>
>>>> -rw-r--r-- 2 root root 0 Jun 13 17:03
>>>> %2fdc%3des%2fdc%3dirisgrid%2fo%3dciemat%2fcn%3dantonio%2ddelgado%2dperis:cms
>>>>
>>>>
>>>> -rw-r--r-- 2 root root 0 Jun 14 16:44
>>>> %2fdc%3des%2fdc%3dirisgrid%2fo%3dciemat%2fcn%3dantonio%2ddelgado%2dperis:cmses
>>>>
>>>>
>>>>
>>>> So, the differences I see are:
>>>> 1) CE converts '-' char to '%2d', while Argus doesn't.
>>>> 2) CE appends the primary role/group to the end of DN, while
>>>> Argus
>>>> appends all role/groups in order
>>> The CE also can do that, it depends on the LCMAPS plugin configuration:
>>> the "-do_not_use_secondary_gids" option would have to be removed
>>> (we actually did so at CERN). The Argus way is more expensive in the
>>> number of pool accounts, so we may want to get the default behavior of
>>> Argus changed. Please open a GGUS ticket...
>>>
>>>> 3) CE uptimes modification time of the link, while Argus doesn't
>>> Points 1 and 2 are annoying, but not critical, whereas point 3 _is_
>>> critical! Please open a GGUS ticket!
>>>
>>> I presume Argus mounts the gridmapdir with sensible caching options?!
>>>
>>>> (1) and (2) result in double mapping for each role/group combination I
>>>> use, this means that I can be mapped to different uids when I
>>>> should be
>>>> mapped to the same one. It also means that our site may run out of
>>>> accounts twice as fast.
>>> The issue only causes more accounts to be used; there is no "strong"
>>> need for Argus and the CE to map the proxy the same way.
>>>
>>>> (3) means (AFAICT) that the cron to expire grid mappings may remove
>>>> mappings that are new believing they are old.
>>> Yes, that is the killer here.
>>
>
>
|