LCMAPS is configured generally in the lcmaps.db file (by default located at '/opt/glite/etc/lcmaps/'. This file is used by the LCMAPS framework to specify:
For a more detailed explenation about using LCMAPS and it's policy file and the configuration of it you can take a look at the LCMAPS specific information pages.
To start at the top of the policy file we will see the initialization string of the LCMAPS modules, including the one for the Job Repository. Here are the initialisation options for the 'jobrep' module (note: jobrep is an alias for the module and it's parameter, this could be anything you like) :
Here is an example of a working initialisation string:
jobrep = "lcmaps_jobrep.mod" "-jr\_config /opt/glite/etc/lcmaps/jobrep\_config"
In the second section you'll see the policies defined. Here is an example of the policy section with one policy:
#My example1 example: vomsextract -> vomslocalgroup vomslocalgroup -> vomspoolaccount vomspoolaccount -> posixenf
Now I'll show you the same example only now it is extended with the Job Repository module:
#My example2 example: vomslocalgroup -> vomspoolaccount vomspoolaccount -> jobrep jobrep -> posixenf
As you can see, the 'jobrep' is to correspond with the Job Repository module and its initialisation string. The Job Repository will get all the information available on that point in time when it is called in the policy evaluation procedure. The Job Repository plugin will get information that has been gathered and stored into the framework that other plugins gathered for the enforcement fase. In this example I used a policy that will map a user according to his/hers VO(s). The Job Repository plugin will also work fine without the VO information in a user's certificate. Here is a example for policies that uses the basic mapping methods:
#My example3 example: localaccount -> jobrep | poolaccount poolaccount -> jobrep jobrep -> posixenf
Again the 'jobrep' will be called before the actual enforcement. When you have a site that want a more dynamic handling of the users in a fabric then LDAP with the VOMSPoolGroups module comes in handy. A policy for that would change into the following when you use 'jobrep':
#My example4 example: vomspoolgroup -> vomspoolaccount vomspoolaccount -> jobrep jobrep -> ldapenf ldapenf -> posixenf
A file called 'jobrep_config' with (usually) root.root read-only (0400) privileges. In the initialisation string of the LCMAPS Job Repository Plugin you ca n specify with -jobrep_config <path>" where this file is located. The file must have these strict perimissions because this is the safest place to store t he database, username and password combination. The system administrator has the freedom not to use the file as such, but we urge you to do so because every authorized Grid user can (in most cases) access the directory '/opt/glite/etc/lcmaps/'. The database can hold non-disclosure information about the users an d there jobs that are running and that have run on your farm.
All the needed 'Database connection parameters' can be located in the '-jr_config' file which are:
More detailed and needed configuration options will be shown in the ODBC specific odbc.ini file.
An ODBC initialization file will configure Data Source Names (DSNs) and link this name with a set of configuration parameters. Here is an example of such a file:
[ODBC Data Sources] jobrepository = mysql ODBC Driver [jobrepository] Driver=/usr/lib/libmyodbc3.so Port=3306
The 'ODBC Data Sources' is an reserved section title where all the DSNs are specified. As shown here the 'jobrepository' is the only DSN and has the identifiable specification to be an 'mysql ODBC Driver'. Below that line my jobrepository's set of parameters is given. In this example the set of values is at its minimum. Actually the port number used to connect to the server (localhost) is the default port and can be thrown out too. The share-object also known as the Driver needs to be specified. This is needed for the ODBC coupling to work and talk the correct dialect of database talk to the MySQL daemon.
Allowed other parameters are:
The ODBC initialization information can be stored in the default locations '/etc/odbc.ini' or in the private space of the user (or admin) ' /.odbc.ini'.
* = The database schema is database specific. At first only MySQL will be supported. Other backends can be produced.
The 'jobrep-admin' script will guide you to setup the schema in a new database or to remove it dropping the database. Do think twice before you click the removal will result into wiped database unrecoverable by common tools.
By default there is a grant made one additional users in the database. That account is used by the LCMAPS plugin to work with the database.
This has to be done manually because it contains the setting of the username and password for the LCMAPS module and you will have to fill in the password for the root database-user. The username and password for the LCMAPS module must be in sync with that of the 'jr_config' file.