John, I have attached what I use for testing upgrades of the CIP (or
rather the BDII which sits in front of the CIP.)
Basically, you do
ldapsearch -x -LLL -H ldap://${OLDBDIIHOST}:2170/ -b ... \
>oldbdii.tmp
into a file, for each of the BDIIs.
Then
ldifsort.pl -k dn oldbdii.tmp >oldbdii.ldif
and similarly s/old/new/, mutatis mutandis.
Finally
ldifdiff.pl -k dn newbdii.ldif oldbdii.ldif
This'll give you the delta (in LDAP change format), to go from the old
and the new. Note that it doesn't then tell you what the _old_ value
was. Also it assumes relatively consistent naming of things (ie DNs).
Sometimes I have masked out numbers (dynamic stuff) by sed'ing numbers
into XXXXXX or something, because numbers generally change from one
snapshot to the next - of course numbers, too, need checking...
Also, don't forget the Flavian test (somewhat customised by me) - you
fail this at your peril (as I know only too well).
#!/bin/ksh
for VO in atlas cms lhcb dteam alice minos mice hone ilc t2k superb na62
snoplus
do echo "***${VO}***"
ldapsearch -LLL -x -H ldap://srmbdii02.gridpp.rl.ac.uk:2170/ -b o=grid \
"(|(&(GlueChunkKey=GlueSEUniqueID=srm-${VO}.gridpp.rl.ac.uk)(|(GlueSAAccessControlBaseRule=ops)(GlueSAAccessControlBaseRule=VO:ops)))(&(GlueChunkKey=GlueSEUniqueID=srm-${VO}.gridpp.rl.ac.uk)(|(GlueVOInfoAccessControlBaseRule=ops)(GlueVOInfoAccessControlBaseRule=VO:ops)))(&(GlueServiceUniqueID=*://srm-${VO}.gridpp.rl.ac.uk*)(GlueServiceVersion=2.*)(GlueServiceType=srm*)))"
\
GlueServiceEndpoint GlueSAPath GlueVOInfoPath
done
Note that the loop isn't really once per VO, it's one per SRM endpoint
(or actually GlueSEUniqueID, but they are required to be SRM endpoint
hostnames).
Learn to identify healthy output - there should be three, four with a
space token for the VO. As a rule.
Enjoy
--jens
On 06/09/2012 15:09, Chris Brew wrote:
> Hi John,
>
> You're probably a bit beyond this point but I'm still proud of the script-fu
> that generated this for comparing the output of two site bdiis:
>
> comm -3 <(ldapsearch -x -H ldap://<OLD_BDII_NAME>:2170 -b
> mds-vo-name=<SITE_NAME>,o=grid | sed -ne '1{h;n;};/^ /!{x;p;};/^ /{H;g;s/\n
> //;h;};${g;s/\n //;p;}' | grep '^dn: ' | sort) <(ldapsearch -x -H
> ldap://<NEW_BDII_NAME>:2170 -b mds-vo-name=<SITE_NAME>,o=grid | sed -ne
> '1{h;n;};/^ /!{x;p;};/^ /{H;g;s/\n //;h;};${g;s/\n //;p;}' | grep '^dn: ' |
> sort)
>
> Yours,
> Chris (who says it's only perl that looks like line noise) Brew.
>
>> -----Original Message-----
>> From: Testbed Support for GridPP member institutes [mailto:TB-
>> [log in to unmask]] On Behalf Of John Hill
>> Sent: 06 September 2012 15:01
>> To: [log in to unmask]
>> Subject: Site BDII move
>>
>> This morning I started the move to a new Site BDII at Cambridge (SL6,
>> EMI-2). MyEGI and NAGIOS have both noticed the change of machine, but
>> GSTAT hasn't as yet. Is this just a matter of being patient? Is there
>> anywhere else I should be checking to ensure that the new Site BDII is
>> recognised and working correctly before I shut down the old one?
>> Thanks,
>> John
--
Scanned by iCritical.
