About 3 months ago, there was a notification of a change to the LHCb VO
ID Card. At the time I couldn't understand whether I needed to do
anything, and I've had no issues on the old gLite 3.2 CREAM CE. However,
I wonder whether these null GLUE2PolicyRule entries are because I have
explicit "Role=" entries for LHCb in the GROUP_ENABLE variables in
site-info.def? What do other LHCb sites have?
John
On 22/10/2012 14:49, John Hill wrote:
> I should wait - I suspect that I'm doing something incorrect elsewhere
> to cause this, as only LHCb is affected.
>
> John
>
> On 22/10/2012 14:46, Stephen Jones wrote:
>> Ah... that's another variation.
>>
>> That script only deals with a case where ALL GLUE2PolicyRule entries
>> are missing. It was easier to program for that case. If
>> only some are missing, then a bit more logic is needed. I can fix it,
>> else you'll have to roll your own. Let me know.
>>
>> Steve
>>
>>
>> On 10/22/2012 02:37 PM, John Hill wrote:
>>> Hi Stephen and Daniela,
>>> Thanks, it is this known issue (and clearly not fixed in 1.14.1).
>>> There are a couple of GLUE2PolicyRule entries with the VO missing. I
>>> think I vaguely noticed this particular list of known issues at some
>>> stage - unfortunately I also found another Known Issues page which
>>> does indeed state that the problem is fixed in Update 3 and so I wiped
>>> the information from my short term memory :-(
>>>
>>> John
>>>
>>> On 22/10/2012 14:28, Stephen Jones wrote:
>>>> On 10/22/2012 02:23 PM, John Hill wrote:
>>>>> I've nearly (I hope!) set up a EMI-2 CREAM CE ready for production.
>>>>> However, I am getting messages like:
>>>>>
>>>>> Oct 22 14:19:38 vserv11 No GLUE2PolicyRule specified for
>>>>> GLUE2ShareID=long_lhcb_vserv11.hep.phy.cam.ac.uk_ComputingElement,GLUE2ServiceID=vserv11.hep.phy.cam.ac.uk_ComputingElement,GLUE2GroupID=resource,o=glue
>>>>>
>>>>>
>>>>>
>>>>> Oct 22 14:19:38 vserv11 Exiting without output, GIP will use static
>>>>> values
>>>>>
>>>>> every 2 minutes. What have I done wrong?
>>>>>
>>>>> John
>>>>
>>>> Hi John,
>>>>
>>>> Please run this command on your CE system:
>>>>
>>>> # grep GLUE2PolicyRule /var/lib/bdii/gip/ldif/ComputingShare.ldif
>>>>
>>>> And see if it gives values like this "GLUE2PolicyRule: VO:atlas" or if
>>>> it gives values like this "GLUE2PolicyRule", i.e. with the VO: missing.
>>>> If it's the latter, you have a problem with GLUE2PolicyRule, that
>>>> can be
>>>> solved with a post yaim script (see below). If it's not that, then it's
>>>> something else!!!
>>>>
>>>> More: Also check this:
>>>> www.eu-emi.eu/emi-2-matterhorn-products/-/asset_publisher/B4Rk/content/cream-2/
>>>>
>>>>
>>>>
>>>>
>>>> More: update 3 is supposed is supposed to fix this, i.e. 1.14.1
>>>>
>>>> Cheers,
>>>>
>>>>
>>>> Steve
>>>>
>>>> :-------------
>>>>
>>>> #!/usr/bin/perl
>>>> use strict;
>>>>
>>>> die ("Please give a file name\n") unless(($#ARGV == 0) && (-f
>>>> $ARGV[0]));
>>>>
>>>> open(LDIF," $ARGV[0]") or die("Failed to read $ARGV[0]");
>>>> my @lines;
>>>> while(<LDIF>) {
>>>> push(@lines,$_);
>>>> }
>>>> close(LDIF);
>>>>
>>>> my @vos;
>>>> my $count = 0;
>>>> foreach my $l (@lines) {
>>>> if ($l =~ /GLUE2PolicyRule:/) {
>>>> if ($l =~ /VO:/) {
>>>> print("File already processed.\n"); exit(0);
>>>> }
>>>> $count++;
>>>> }
>>>> if ($l =~ /GLUE2PolicyUserDomainForeignKey:(.*)/) {
>>>> my $vo = $1; $vo =~ s/ //g;
>>>> push(@vos,$vo);
>>>> }
>>>> }
>>>>
>>>> die ("Something odd about that file: $ARGV[0]\n") unless ($count ==
>>>> $#vos+1);
>>>>
>>>> foreach my $l (@lines) {
>>>> if ($l =~ /GLUE2PolicyRule:/) {
>>>> chomp($l); $l =~ s/\s$//;
>>>> $l = $l . ' VO:' . shift(@vos) . "\n";
>>>> }
>>>> }
>>>>
>>>> open(LDIF,">$ARGV[0]") or die("Failed to write $ARGV[0]");
>>>> foreach my $l (@lines) {
>>>> print LDIF $l;
>>>> }
>>>> close(LDIF);
>>>>
>>>>
>>>> Steve
>>>>
>>>>
>>
>>
|