- General information
- Data readiness
- Grid and Cloud
- Articles and publications
- Cloud computing
- Data Management
- Documentation
- Getting site information from VORS
- Globus 1.1.x
- Globus Toolkit Error FAQ
- Intro to FermiGrid site for STAR users
- Introduction to voms proxies for grid cert users
- Job Managers
- Modifying Virtual Machine Images and Deploying Them
- Rudiments of grid map files on gatekeepers
- Running Magellan Cloud at NERSC, Run 11
- SRM instructions for bulk file transfer to PDSF
- Scalability Issue Troubleshooting at EC
- Specification for a Grid efficiency framework
- Starting up a Globus Virtual Workspace with STAR’s image.
- Troubleshooting gsiftp at STAR-BNL
- Using the GridCat Python client at BNL
- Grid Infrastructure
- Grid Production
- Monitoring
- MySQL project activities
- Infrastructure
- Machine Learning
- Offline Software
- Production
- S&C internal group meetings
- Test tree
Rudiments of grid map files on gatekeepers
Updated on Fri, 2007-01-12 14:54. Originally created by wbetts on 2006-12-19 21:34.
Under:
This is intended as a practical introduction to mapfiles for admins of new sites to help get the *basics* working and avoid some common problems with grid user management and accounting.
It should be stressed that manually maintaining mapfiles is the most primitive user management technique. It is not scalable and it has been nearly obsoleted by two factors:
1. There are automated tools for maintaining mapfiles (GUMS with VOMS in the background, for instance, but that's not covered here).
2. Furthermore, VOMS proxies are replacing grid certificate proxies, and the authentication mechanism no longer relies on static grid mapfiles, but instead can dynamically authenticate against GUMS or VOMS servers directly for each submitted job.
But let's ignore all that and proceed with good old-fashioned hand edits of two critical files on your gatekeeper:
/etc/grid-security/grid-mapfile
and
$VDT_LOCATION/monitoring/grid3-user-vo-map.txt
(the location of the grid-mapfile in /etc/grid-security is not universal, but that's the default location)
In the grid-mapfile, you'll want entries like the following, in which user DNs are mapped to specific user accounts. You can see from this example that multiple DNs can map to one user account (rgrid000 in this case):
#---- members of vo: star ----#
"/DC=org/DC=doegrids/OU=People/CN=Valeri Fine 224072" fine
"/DC=org/DC=doegrids/OU=People/CN=Wayne Betts 602856" wbetts
#---- members of vo: mis ----#
"/DC=org/DC=doegrids/OU=People/CN=John Rosheck (GridScan) 474533" rgrid000
"/DC=org/DC=doegrids/OU=People/CN=John Rosheck (GridCat) 776427" rgrid000
(The lines starting with '#' are comments and are ignored.)
You see that if you want to support the STAR VO, then you will need to include the DN for every STAR user with a grid cert (though as of this writing, it is only a few dozen, and only a few of them are actively submitting any jobs. Those two above are just a sampling.) You can support multiple VOs if you wish, as we see with the MIS VO. But MIS is a special VO -- it is a core grid infrustructure VO, and the DNs shown here are special testing accounts that you'll probably want to include so that you appear healthy in various monitoring tools.
In the grid3-user-vo-map.txt file, things are only slightly more complicated, and could look like this:
#User-VO map
# #comment line, format of each regular line line: account VO
# Next 2 lines with VO names, same order, all lowercase, with case (lines starting with #voi, #VOc)
#voi mis star
#VOc MIS STAR
#---- accounts for vo: star ----#
fine star
wbetts star
#---- accounts for vo: mis ----#
rgrid000 mis
(Here one must be careful -- the '#' symbol denotes comments, but the two lines starting with #voi and #VOc are actually read by VORS (this needs to be fleshed out), so keep them updated with your site's actual supported VOs.)
In this example, we see that users 'fine' and 'wbetts' are mapped to the star VO, while 'rgrid000' is mapped to the mis VO.
Maintaining this user-to-VO map is not critical to running jobs at your site, but it does have important functions:
1. MonAlisa uses this file in its accounting and monitoring (such as VO jobs per site)
2. VORS advertises the supported VOs at each site based on this file, and users use VORS to locate sites that claim to support their VO... thus if you claim to support a VO that you don't actually support, then sooner or later someone from that VO will submit jobs to your site, which will fail and then THEY WILL REPORT YOU TO THE GOC!
(Don't worry, there's no great penalty, just the shame of having to respond to the GOC ticket. Note that updates to this file can take several hours to be noticed by VORS.)
If you aren't familiar with VORS or MonAlisa, then hop to it. You can find links to both of them here:
http://www.opensciencegrid.org/?pid=1000098
It should be stressed that manually maintaining mapfiles is the most primitive user management technique. It is not scalable and it has been nearly obsoleted by two factors:
1. There are automated tools for maintaining mapfiles (GUMS with VOMS in the background, for instance, but that's not covered here).
2. Furthermore, VOMS proxies are replacing grid certificate proxies, and the authentication mechanism no longer relies on static grid mapfiles, but instead can dynamically authenticate against GUMS or VOMS servers directly for each submitted job.
But let's ignore all that and proceed with good old-fashioned hand edits of two critical files on your gatekeeper:
/etc/grid-security/grid-mapfile
and
$VDT_LOCATION/monitoring/grid3-user-vo-map.txt
(the location of the grid-mapfile in /etc/grid-security is not universal, but that's the default location)
In the grid-mapfile, you'll want entries like the following, in which user DNs are mapped to specific user accounts. You can see from this example that multiple DNs can map to one user account (rgrid000 in this case):
#---- members of vo: star ----#
"/DC=org/DC=doegrids/OU=People/CN=Valeri Fine 224072" fine
"/DC=org/DC=doegrids/OU=People/CN=Wayne Betts 602856" wbetts
#---- members of vo: mis ----#
"/DC=org/DC=doegrids/OU=People/CN=John Rosheck (GridScan) 474533" rgrid000
"/DC=org/DC=doegrids/OU=People/CN=John Rosheck (GridCat) 776427" rgrid000
(The lines starting with '#' are comments and are ignored.)
You see that if you want to support the STAR VO, then you will need to include the DN for every STAR user with a grid cert (though as of this writing, it is only a few dozen, and only a few of them are actively submitting any jobs. Those two above are just a sampling.) You can support multiple VOs if you wish, as we see with the MIS VO. But MIS is a special VO -- it is a core grid infrustructure VO, and the DNs shown here are special testing accounts that you'll probably want to include so that you appear healthy in various monitoring tools.
In the grid3-user-vo-map.txt file, things are only slightly more complicated, and could look like this:
#User-VO map
# #comment line, format of each regular line line: account VO
# Next 2 lines with VO names, same order, all lowercase, with case (lines starting with #voi, #VOc)
#voi mis star
#VOc MIS STAR
#---- accounts for vo: star ----#
fine star
wbetts star
#---- accounts for vo: mis ----#
rgrid000 mis
(Here one must be careful -- the '#' symbol denotes comments, but the two lines starting with #voi and #VOc are actually read by VORS (this needs to be fleshed out), so keep them updated with your site's actual supported VOs.)
In this example, we see that users 'fine' and 'wbetts' are mapped to the star VO, while 'rgrid000' is mapped to the mis VO.
Maintaining this user-to-VO map is not critical to running jobs at your site, but it does have important functions:
1. MonAlisa uses this file in its accounting and monitoring (such as VO jobs per site)
2. VORS advertises the supported VOs at each site based on this file, and users use VORS to locate sites that claim to support their VO... thus if you claim to support a VO that you don't actually support, then sooner or later someone from that VO will submit jobs to your site, which will fail and then THEY WILL REPORT YOU TO THE GOC!
(Don't worry, there's no great penalty, just the shame of having to respond to the GOC ticket. Note that updates to this file can take several hours to be noticed by VORS.)
If you aren't familiar with VORS or MonAlisa, then hop to it. You can find links to both of them here:
http://www.opensciencegrid.org/?pid=1000098
»
- Printer-friendly version
- Login or register to post comments