Note: This version of the VDT (1.5.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 MDS or CEMon. 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. 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 the ldap service certificate of the host where it runs. The following instruction configure GUMS to map the identity of the probe to a non-existent pre-defined UID.

Add gums-test group to your GUMS configuration

Add the following XML within your GUMS configuration, which is normally at $VDT_LOCATION/gums-service/var/war/WEB-INF/classes/gums.config. If your GUMS has <groupMappings> and <hostGroups> defined already, add the <groupMapping> and <hostGroup> tags below within your <groupMappings> and <hostGroups> tags. Make sure that you write the domain name of the probe in the <hostGroups> tag. Note that you don't need to stop GUMS when editing its configuration.

<groupMappings>
  <groupMapping name='gums-test'>
    <userGroup className='gov.bnl.gums.ManualUserGroup'
               persistenceFactory='mysql'
               name='gums-test'/>
    <accountMapping className='gov.bnl.gums.GroupAccountMapper'
                    groupName='GumsTestUserMappingSuccessful' />
  </groupMapping>
</groupMappings>
<hostGroups>
  <hostGroup className='gov.bnl.gums.CertificateHostGroup'
             cn='ldap/*.my.site'
             groups='gums-test' />
</hostGroups>

Map the test UID to the identity of the probe

• 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. Make sure you substitute the identity of the probe as the last parameter i.e. the subject of the ldap service certificate on the computer running the generic information provider.

  root> gums manualGroup-add mysql gums-test 
  Example:
  root> gums manualGroup-add mysql gums-test "/DC=org/DC=doegrids/OU=Services/CN=ldap/mymachine.fnal.gov"
  

Check that the test configuration is working.

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

  export X509_USER_CERT=/etc/grid-security/ldap/ldapcert.pem
  export X509_USER_KEY=/etc/grid-security/ldap/ldapkey.pem
  

• Execute the following command, substituting the subject of the ldap servce certificate appropriately:

  > gums-service mapUser -s  

  For example:

  > gums-service mapUser \ 
    -s "/DC=org/DC=doegrids/OU=Services/CN=ldap/mymachine.fnal.gov" \ 
    "/DC=org/DC=doegrids/OU=Services/CN=ldap/mymachine.fnal.gov"
  
  LocalId[userName: GumsTestUserMappingSuccessful]
  

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