Configuration

LCMAPS

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:

• The physical location on the disk of each modules (aka the plugins)
• Which initialization string must be used for each module
• The policies that are composed modules executed as a state machine. The outcome of each module (true or false) will decide which module to execute next. This means they can either return true or false which will create a controlflow through the policies.

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"

The policies

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

The 'jobrep_config' file

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:

• username=<db username>
• password=<db password>
• database=<db database name>

More detailed and needed configuration options will be shown in the ODBC specific odbc.ini file.

The odbc.ini file(s)

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:

• server=<host with the database other then localhost>
• username=<db username>
• password=<db password>
• database=<db name used for the Job Repository>
• and others which could even be specific per database type and version

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

The Job Repository LCMAPS plugin rpm comes with four scripts. Only the 'jobrep-admin' script needs execution. The others are seperate SQL scripts to create the database. They are located in the (standard) location '/opt/glite/sbin/'. The scripts* are:

• jobrep-admin, Script to install or remove a Job Repository database through the provided SQL scripts.
• jobrep-create-basic.sql, SQL script to install the default Job Repository DB schema. The schema supports more than one type of service to hold relational information from.
• jobrep-create-CE.sql, SQL script to install the Compute Element specific tables needed to store relevant relational information about the CE activities.
• jobrep-drop-total-database.sql, SQL script to remove a Job Repository database completely.

* = 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.