On Mon, Nov 23, 2009 at 11:18 PM, <[log in to unmask]> wrote:
> I know you asked about clusters and stuff but there is also a
> BDII sanity checker in s-2.sf.net for the storage testing. Mind you,
> it seems to report some errors which aren't, sort of. But it's
> pretty good. Let's cover that on Wed,
>
Hi Jens,
The se tests are in the same package.
$ rpm -ql gstat-validation | grep bin
/usr/bin/gstat-validate-ce
/usr/bin/gstat-validate-sanity-check
/usr/bin/gstat-validate-se
/usr/bin/gstat-validate-service
/usr/bin/gstat-validate-site
package available here:
http://www.sysadmin.hep.ac.uk/rpms/egee-SA1/centos5/
there is centos4 one as well which is currently up to date
but only as long as it is easy.
Bugs here please: https://savannah.cern.ch/projects/sa1tools/
Steve
> --jens
>
>
> -----Original Message-----
> From: Testbed Support for GridPP member institutes on behalf of Steve Traylen
> Sent: Mon 23/11/2009 19:20
> To: [log in to unmask]
> Subject: Re: Site Information Sanity Checking
>
> On Mon, Nov 23, 2009 at 8:14 PM, Matt Doidge <[log in to unmask]> wrote:
>> Heya all,
>>
>> If a site, by whatever mechanism or whatever reason, has a fiddle with their
>> information system how can you then check that the info you're pumping out
>> tmakes sense without waiting for gstat to refresh? Or to rephrase the
>> question, how can we duplicate gstat's giis sanity checking? Maybe some kind
>> of magical ldap query with some arcane parsing and grepping?
>
> ldap queries are all ways going to be the true test especially if you
> suspect a probe bug.
>
> All the gstat probes are just nagios probes that can be run from the
> command line client
> or rerun from the Oxford nagios via the web interface. You should have
> permission to
> do this for your site.
>
> If you install gstat-validate package from the sa1 repository you can
> just do things like.
>
> $ gstat-validate-ce -H prod-bdii.cern.ch -p 2170 -b
> 'Mds-vo-name=CERN-PROD,o=Grid'
>
> there are few other options , see -h for help.
>
> Steve
>
>>
>> The backstory of this query is that Lancaster spent a good chunk of Friday
>> with the "info" status in gstat as I tried to publish our new subcluster.
>> ldapsearch showed that we were pumping out stuff that looked right, but
>> gstat complained because the software version wasn't being published for the
>> cluster-it appeared to be being pushed out to the world, but not in the
>> right place in the publishing apparently. It being Friday we rolled back
>> rather then extensively debug, the fact that gstat with its hour-or-so
>> between refreshes was our main indicator of our state of play didn't help
>> matters. Before I have another go at it I'd like to be armed with a better
>> debugging tool.
>>
>> Thanks in advance,
>> Matt
>>
>
>
>
> --
> Steve Traylen
>
>
>
> --
> Scanned by iCritical.
>
>
--
Steve Traylen
|