gx-propagate - Propagate a grid-mapfile request to a cross-site database
gx-propagate -help
gx-propagate [options]
gx-propagate, part of the gx-map system, is an optional plug-in command invoked by the gx-check-requests command. Two versions are provided in the gx-map distribution: a TeraGrid-specific version that communicates with the TGCDB (TeraGrid Central DataBase), and a dummy test version that merely logs its arguments to gx-map-data/gx-propagate.log under the gx-map installation directory.
The TeraGrid-specific version of the gx-propagate command adds the specified information to the TGCDB. This information is then propagated across all TeraGrid sites, and the gx-request command is automatically invoked at the other sites so that the mapping will appear on all systems where the user has an account.
The same person may have different Unix user names at different sites. Conversely, the same Unix user name may be owned by different people at different site. The TGCDB is responsible both for passing the information from site to site and for resolving site-specific Unix user names.
The gx-propagate interface was designed with the TeraGrid in mind, but it's intended to be flexible enough so that it can be used for other similar systems. (It remains to be seen whether the interface will have to be redesigned for other systems.)
Option processing is done using the Perl Getopt::Long module.
Options may be specified with a single or double leading '-' character. Option names may be abbreviated to whatever is unique. Arguments may be separated either by a blank or by an '=' character. For example, ``-foobar 42'', ``--foobar=42'', and ``-foob 42'' would all be equivalent.
-source TGCDB
indicates that the mapping originated from the TeraGrid Central
DataBase; such mappings are not propagated (to avoid an infinite loop).
This is mandatory.
The tgcdb.db-config is considered to be ok if all fields are filled in and the file's permissions are set to either 600 (rw-------) or 400 (r--------). The values of the fields are not checked.
In the TeraGrid-specific version of gx-propagate, the -remove-dn and -remove-user requests are implemented by searching the existing requests.log file and individually removing each mapping that matches the specified criterion. If your grid-mapfile is generated from multiple sources, by using the the gx-gen-mapfile command's -merge-file or -requests-log option, then this search may not reflect all the information it should, and inconsistencies may result.
The TeraGrid-specific version of gx-propagate requires a small configuration file, which must be installed in the gx-map installation directory tree as etc/gx-map/tgcdb.conf. It must be owned by the owner of the gx-map installation (see GX_MAP_OWNER in the installation configuration file), and it must have its permissions set to either 600 or 400 (rw------- or r--------). See README.TeraGrid for details.
The -merge-file option of gx-gen-mapfile merges in a grid-mapfile generated by some other mechanism. Using this in conjunction with gx-propagate means that the information in the external grid-mapfile will not be considered when interacting with the database.
The -requests-log option of gx-gen-mapfile is part of an older and more limited mechanism for propagating information across systems within a single site. Using this option together with gx-propagate is not recommended.
gx-map(7), gx-request(1), gx-check-requests(8), gx-propagate(8), gx-gen-mapfile(8), gx-map-security(7), gx-db-request(8), gx-db-check-requests(8), gx-map-db-config(5)
Keith Thompson, San Diego Supercomputer Center, <kst@sdsc.edu>
See the file LICENSE in the gx-map distribution, installed in the etc/gx-map subdirectory.