MDS 2.2 New Features
The MDS 2.2 release includes significant fixes and enhancements that make for a considerably more robust MDS with expanded capabilities for dealing with problematic installations.
MDS 2.2 contains the following new and enhanced features:
- Expanded debugging capabilities
- GIIS registration status checking
- Improved diagnostics and logging
- MDS system configuration information provider
- GridFTP logfile information provider
- Mutual authentication in a GIIS hierarchy
- Newer version of OpenLDAP
- New core information providers
- New start and stop commands
- New location for LDAP server certificate and key
- New command syntax to request LDAP server certificate
- Adjusted default timings for GRIS providers
Expanded Debugging Capabilities
MDS 2.2 provides capabilities for checking servers registered to a GIIS, writing OpenLDAP and GIIS/GRIS back end messages to a log file, viewing the MDS system configuration via an expanded grid-info-mds-core information provider, and displaying GridFTP performance information.
GIIS Registration Status Checking
GIIS registration status can now be checked with a new option on the grid-info-search command, giisregistrationstatus.
The status of servers that are registered to a GIIS or from which a GIIS is getting data can be checked by this command option. If several servers are registered to a GIIS and it appears that not all of them are sending data, grid-info-search with the giisregistrationstatus option can be used to check the status of those servers.
For example, the following command:
grid-info-search -x -b "mds-vo-name=site,o=grid" -s base giisregistrationstatus
displays the status of the default server (as defined in the grid-info.conf file) and a server registered to it.
The command output displays registration objects that include the status type: valid, invalid, or purged. These status types are derived from the validfrom:, validto:, and keepto: parameters, which are generated from the ttl: parameter in the grid-info-resource-register.conf file.
The validfrom:, validto:, and keepto: parameters represent the timeframe during which one server keeps registration messages sent from another server. This timeframe can be illustrated as follows:
validfrom: validto:
keepto:
¯
¯
¯
time=| VALID |
INVALID | PURGED
|
GIIS registration status checking is described in more detail in MDS 2.2: Creating a Hierarchical GIIS and in the MDS 2.2 User’s Guide.
Improved Diagnostics and Logging
MDS 2.2 uses the Unix syslog daemon, configured in /etc/syslog.conf, to log OpenLDAP messages and GIIS/GRIS back end messages.
You put an entry like:
local4.* local-log-file
in the /etc/syslog.conf file. Once you’ve done this, you’ll need to restart your syslog daemon, which is operating system dependent.
The syslog restart command publishes messages into the log file name indicated by the local4.* entry in the syslog.conf file.
The logged messages show slapd server messages for items such as machine registration status, success or failure of a search, and slapd operational status.
Refer to the MDS 2.2 User’s Guide (the Diagnostics and Logging section of Chapter 3, Using MDS) for more information on the use of syslog.conf and examples of log file output.
MDS System Configuration Information Provider
There is a new MDS system configuration provider, grid-info-mds-core. The system configuration provider generates deployment information such as the service path, process ID of the current slapd instance, e-mail address of the administrator, any administrative comments, and LDAP suffixes used by the service. This type of information is helpful for MDS installation debugging.
The MDS system information provider output can be retrieved by using grid-info-search to query all objects on a host.
The system information provider uses the administrator’s e-mail address from the grid-info.conf file and the administrative comments from the grid-info-deployment-comments.conf file.
Refer to the MDS 2.2 User’s Guide (the Diagnostics and Logging section of Chapter 3, Using MDS) for an example of MDS system configuration file output. See MDS 2.2 Configuration Files for more details on and examples of grid-info.conf and grid-info-deployment-comments.conf.
GridFTP Logfile Information Provider
The GridFTP logfile information provider (gridftp-perf-info) takes performance information from GridFTP and publishes it into MDS.
For MDS 2.2, there is an entry in the grid-info-resource-ldif.conf file for the GridFTP logfile provider, which can generate GridFTP performance information on a daily basis. This entry is disabled by default, as all of its lines are comments.
To use the GridFTP logfile provider, edit its grid-info-resource-ldif.conf entry to remove the comment hash marks. Then edit the gridftp-resource.conf file (in $GLOBUS_LOCATION/etc) to configure it to your GridFTP environment and information reporting requirements, in terms of host name, URL, and logfile location. You can then use the grid-info-search command to retrieve your GridFTP performance information.
Refer to MDS 2.2 Configuration Files for more details on and examples of grid-info-resource-ldif.conf and gridftp-resource.conf. See www.globus.org/toolkit/data/gridftp/ for more information on GridFTP.
Mutual Authentication in a GIIS Hierarchy
MDS 2.2 provides mutual authentication between GIIS and GRIS servers as well as between GIIS servers in a hierarchy. This feature is intended to keep rogue servers from affecting a GIIS hierarchy. Mutual authentication is performed on outbound channels, as in a server registering to the one above it in a hierarchy.
Mutual authentication is enabled via a new parameter, bindmethod, in the grid-info-resource-register.conf file. This parameter specifies the binding method from the upper-level GIIS as one of the following:
- AUTHC-ONLY: Bind only with GSI authentication.
- AUTHC-FIRST: Try authentication first; if that doesn’t work, use anonymous binding. Authentication is tried first with every registration attempt.
- ANONYM-ONLY: Use anonymous binding only. This is the default.
Note that the bindmethod parameter is required in the grid-info-resource-register.conf file. Without this parameter in the file, registration will not work.
Mutual authentication works only for servers in an MDS 2.2 environment. That is, there cannot be mutual authentication between MDS 2.1 and 2.2 resources.
A related policy statement may be included in the grid-info-site-policy.conf file to restrict mutual authentication to a particular host or hosts and to a specific port on a host or hosts. In addition to the host/port information, the policy statement in this file would appear as:
policydata: (Mds-Bind-Method-servers=bindmethod)
where bindmethod is one of the three binding methods above. The binding method in grid-info-site-policy.conf should match that in grid-info-resource-register.conf.
A new file, grid-info-server-env.conf, sets up the X509* and other environment variables for use in mutual authentication.
Refer to MDS 2.2 Configuration Files for description and examples of these configuration files. Refer to MDS 2.2: Creating a Hierarchical GIIS for additional details related to mutual authentication and the use of policy statements.
Change in OpenLDAP Version
MDS 2.2 ships with OpenLDAP Version 2.0.22, an upgraded release.
See www.openldap.org for the details of OpenLDAP 2.0.22 and other OpenLDAP releases.
New Core Information Providers
In addition to the MDS system configuration and GridFTP logfile information providers described above, MDS 2.2 includes new core GRIS information providers for the Tru64 and AIX operating systems.
Each external provider tool generates output representing MDS data objects. Output data is in LDIF format and must match the schema distributed with the providers. Details of the default MDS GRIS provider schema are documented separately in MDS 2.2 Schemas.
All core providers are described in detail in MDS 2.2 Core GRIS Providers.
New Start and Stop Commands
For MDS 2.2, the SXXgris start and SXXgris stop commands have been renamed to globus-mds start and globus-mds stop, respectively. However, for backward compatibility, SXXgris start and SXXgris stop will continue to work in MDS 2.2.
This name change reflects current Globus Toolkit standards. The globus-mds commands are called via a symbolic link to the existing SXXgris commands.
New Location for LDAP Server Certificate and Key
To create a standard way of naming directories for multiple services in the Globus Toolkit (“ldap” certificates for MDS, “cvs” certificates for gridcvs, etc.), the default locations of the LDAP server certificate and key files are changed for MDS 2.2.
A new configuration file, grid-info-server-env.conf, now sets all of the environment variables for the MDS installation, replacing what was formerly done by the grid-info-slapd script.
The server certificate and key are set by default in $GLOBUS_LOCATION/etc/grid-info-server-env.conf to $GLOBUS_LOCATION/etc/grid-security/ldap/ldapcert.pem and ldapkey.pem. If MDS cannot read these files for some reason, it will try instead $GLOBUS_LOCATION/etc/ldap/ldapcert.pem and ldapkey.pem. (You’ll need to put the files in that directory if it is to be used.)
When you start MDS with the globus-mds start command, the command calls the grid-info-slapd script, which calls grid-info-server-env.conf to set up the MDS environment variables such as those for the server certificate and key. This grid-info-slapd script then calls the slapd server, which reads the grid-info-slapd.conf file and determines all the other configuration files to read. Refer to MDS 2.2 Configuration Files for more details.
New Command Syntax to Request LDAP Server Certificate
For MDS 2.2, the grid-cert-request command has new syntax for obtaining the LDAP server certificate required by MDS, as follows:
grid-cert-request -service ldap -host [my.host.fqdn]
where my.host.fqdn is the fully qualified domain name of the host that will run the LDAP server. As mentioned above, the server certificate and key are placed by default (assuming you are running as root) in GLOBUS_LOCATION/etc/grid-security/ldap.
Refer to the MDS 2.2 User’s Guide (the MDS Security Setup Procedures section of Chapter 5, MDS Security Configuration) for more details on the use of grid-cert-request and an example of command output for obtaining an LDAP server certificate.
Adjusted Default Timings for GRIS Providers
For MDS 2.2, default values for timing parameters in the grid-info-resource-ldif.conf configuration file have been adjusted to maximize caching capabilities for effective return of the data requested by the grid-info-search command.
Each information provider specified in the grid-info-resource-ldif.conf has three timing parameters associated with it: -validto-secs, -keepto-secs, and cachetime. These providers and their new default timing parameter values (all in seconds) are as follows:
Provider -validto-secs -keepto-secs cachetime
Memory 3600
240800 1800
File systems 3600 21600 1800
Network 21600 21600
10800
CPU availability 60 240800 30
OS 21600 240800 10800
Host merged 3600 240800 1800
For more information on timing parameters, refer to MDS 2.2: Creating a Hierarchical GIIS and MDS 2.2 Configuration Files.