Hi Vincenzo,
Whether the documentation clearly states something or not may not matter
much in the wider world.
A great deal of existing software (all of the OSG auth infrastructure,
for example) assumes that the first FQAN in a VOMS proxy is the special
one that was specifically requested. And a great many users and their
custom-written client software uses voms-proxy-init without --order, and
these applications will break if VOMS servers no longer place the
explicitly requested FQAN first.
I'd say in this case the specification has been superceded by reality,
and "explicity-requested-first" is the de facto standard.
Why can't --order simply be set as the default? This is a very big issue
that shut down ATLAS production for ~1/2 day a few weeks ago.
Cheers,
--john
Vincenzo Ciaschini wrote:
> Christian Neissner wrote:
>> Hi Maarten,
>>
>> That bug seems to be the point because it works well if I request a
>> dteam proxy with group attributes. I guess the best solution will be a
>> rollback. Thanks.
> Actually, Christian, this is not a bug. The documentation clearly
> states that the order of the FQANs in the certificate is undefined and
> should not be relied upon. If you wish a specific order then you *must*
> use the --order option to voms-proxy-init.
>
> This behavior has changed for the version now under certification, but
> what the voms-proxy-init you are using does is correct.
>
> Ciao,
> Vincenzo
>
>>
>> Christian.
>>
>> [log in to unmask] wrote:
>>> Hi Christian,
>>>
>>>
>>>> Recently I installed a VOMS server (glite-VOMS_mysql-3.1.11-0) for a
>>>> regional VO. I am also aware of bug #37372 and deployed the
>>>> workaround. For testing I enabled a VO with two different groups,
>>>> but creating a proxy from a UI the group request is ignored. I
>>>> always get all attributes in the same order:
>>>>
>>>
>>> https://savannah.cern.ch/bugs/?38506
>>>
>>> Users would need to specify the order with the "-order" option.
>>>
>>> Furthermore, note that the version you installed will not work for:
>>>
>>> 1. WMS proxy renewal;
>>> 2. dCache.
>>>
>>> A new version has been prepared for certification:
>>>
>>> https://savannah.cern.ch/patch/?2061
>>>
>>> It may still be a few weeks before it gets released to production.
>>>
>>>
--
John R. Hover
RHIC/ATLAS Computing Facility, Bldg. 510M
Physics Department
Brookhaven National Laboratory
Upton, NY 11973
email: [log in to unmask]
tel: 631-344-5828
|