Note: This version of the VDT (1.8.0) is no longer supported. Feel free to look through the documentation and install it, but we cannot guarantee support for it. The current stable release is 2.0.0.

GUMS

Enabling GUMS monitoring

Introduction

It is possible for the Generic Information Provideer to monitor your GUMS service and publish this information via BDII. In order for monitoring to work, you must do a few things to your GUMS setup. These directions were provided by Gabriele Garzoglio. We will try to automate them in a future version of the VDT.

Basics

We check the availability of GUMS by running a probe (Information Provider). The probe asks GUMS to perform an identity mapping. The output of the probe is used by the GIP to publish the status information via BDII. The identity of the probe is a generic string ("/GIP-GUMS-Probe-Identity"), which is pre-loaded in the GUMS database by following these instructions. These instructions also configure GUMS to map the identity of the probe to a non-existent pre-defined UID.

Define the probe identity mapping in your GUMS configuration

Add the following XML within your GUMS configuration, which is normally at $VDT_LOCATION/vdt-app-data/gums/config/gums.config . If your GUMS has <userGroups>, <accountMappers>, <groupToAccountMappings>, and <hostToGroupMappings> defined already, nest inside of them the <manualUserGroup>, <groupAccountMapper>, <groupToAccountMapping>, and <hostToGroupMapping> tags as shown below. Make sure that you write the appropriate wildcard in the <hostToGroupMapping> tag, in order to identify all the http service certificate domain names (DN) of the machines that will run the GIP probe. Note that you don't need to stop GUMS when editing its configuration.

<userGroups>
<manualUserGroup
name='gums-test'
access='write'
description=''
persistenceFactory='mysql'/>
</userGroups>

<accountMappers>
<groupAccountMapper
name='GumsTestUserMappingSuccessful'
description=''
accountName='GumsTestUserMappingSuccessful'/>
</accountMappers>

<groupToAccountMappings>
<groupToAccountMapping
name='gums-test'
description=''
accountingVoSubgroup=''
accountingVo=''
userGroups='gums-test'
accountMappers='GumsTestUserMappingSuccessful'/>
</groupToAccountMappings>

<hostToGroupMappings>
<hostToGroupMapping
groupToAccountMappings='gums-test'
description=''
cn='*/?*.my.site'/>
</hostToGroupMappings>

Add the identity of the probe to the GUMS database

• Setup your gums client environment (typically this means sourcing the VDT setup.sh or setup.csh).
• Execute the following command using the administrative user credentials. This makes the probe identity part of the gums-test group in the gums database

  root> $VDT_LOCATION/gums/scripts/gums manualGroupAdd gums-test "/GIP-GUMS-Probe-Identity"
  

Check that the test configuration is working.

• From the machine that runs the probe, login as the user that can read the http service certificate.
• Setup your gums client environment
• Define the environment variables X509_USER_CERT and X509_USER_KEY to point to the http certificate and key files. This gives your environment the same identity as the GIP probe.
For example for bash:

export X509_USER_CERT=/etc/grid-security/http/httpcert.pem
export X509_USER_KEY=/etc/grid-security/http/httpkey.pem

• Execute the following command, substituting the subject of the http service certificate DN appropriately

  $VDT_LOCATION/gums/scripts/gums-service mapUser -s "<http-DN>" "/GIP-GUMS-Probe-Identity"
  

  For example (with an http certificate copied from the host certificate):

  $VDT_LOCATION/gums/scripts/gums-service mapUser -s "/DC=org/DC=doegrids/OU=Services/CN=host/mymachine.my.site" "/GIP-GUMS-Probe-Identity"
  
  LocalId[userName: GumsTestUserMappingSuccessful]
  

  If you see the output LocalId[userName: GumsTestUserMappingSuccessful] the mapping works. If you see "null" something went wrong.