Thanks to Yves for writing docs on this upgrade, and to Jeremy for
pointing them out.
On 19 Jul 2007, at 00:04, Gianfranco Sciacca wrote:
> Hi Graeme,
>
> I have recently upgraded to r27 as well.
>
> On 18 Jul 2007, at 17:05, Graeme Stewart wrote:
>
>> I've been upgrading Glasgow to r27 (which is a significant amount
>> of hassle after laying low at r20 for so long) and I'm also
>> enabling the supernemo DNS style VO.
>>
>> First question, in the GROUP_ENABLE stanzas it states that every
>> FQAN _must_ be listed, so I need
>>
>> ATLAS_GROUP_ENABLE="atlas /VO=atlas/GROUP=/atlas/ROLE=lcgadmin /
>> VO=atlas/GROUP=/atlas/ROLE=production"
>
> I have settled for ATLAS_GROUP_ENABLE="atlas" and it seems to work
> fine.
Also I have checked at Edinburgh and it's fine for them. It seems
that this only adds new GIDs to the torque queue ACLs - as we are
staying with single sgm/prd accounts for now, this is not an issue.
(In fact configuring torque is something we do in cfengine space,
rather than through YAIM.)
>
>> Is this really true? The example files do not have this, which
>> makes me rather sceptical. I also recall ATLAS production being
>> messed up by FQAN views of queues, but perhaps that's been fixed.
>>
>> Secondly, the VO_VONAME_DEFAULT_SE and VO_VONAME_SW_DIR are
>> explicitly not defined for DNS style VOs, which seems a break with
>> tradition if nothing else. Is there a plan in this area? I can't
>> see why, e.g., VO_SUPERNEMO_VO_EU_EGEE_ORG_DEFAULT_SE would not work.
>
> I have configured this with the following lines in the vo.d/
> supernemo.vo.eu-egee.org file:
>
> SW_DIR=/path/to/software
> VO_DEFAULT_SE="$DPM_HOST"
>
> Note the "SW_DIR" in place of the "VO_SW_DIR", very confusing and
> definitely inconsistent. YAIM would abort with anything different
> from "SW_DIR".
Yes, I defined the variables as you did, however the configure_lcgenv
function contains the code snippet:
if [ x`eval echo ${VO} | egrep "\.|-"` == 'x' ] ; then
# Export only if VO name is not DNS style
echo "export VO_${VO}_DEFAULT_SE=$default_se" >> $
{LCG_ENV_LOC}/lcgenv.sh
fi
So I'd be surprised if the variables actually found their way into
lcgenv.{sh,csh} on your nodes.
A simple, and sensible patch, would be something like:
NORM_VO=$(echo $VO | tr -- '[:lower:].-' '[:upper:]__')
echo "export VO_${NORM_VO}_DEFAULT_SE=$default_se" >> ${LCG_ENV_LOC}/
lcgenv.sh
In fact I think I'll submit that in a ggus ticket...
(There's a rather convoluted mess of lower->UPPER and UPPER->lower in
config_lcgenv and util/vo_param...)
Upgrade should be done today.
Thanks again
Graeme
--
Dr Graeme Stewart - http://wiki.gridpp.ac.uk/wiki/User:Graeme_stewart
ScotGrid - http://www.scotgrid.ac.uk/ http://scotgrid.blogspot.com/
|