CE LCG

Configuration file:

Specific variables are in:

• ''/opt/glite/yaim/examples/siteinfo/services/lcg-ce''
• ''/opt/glite/yaim/examples/siteinfo/services/glite-mpi''
• ''/opt/glite/yaim/examples/siteinfo/services/glite-mpi_ce''

Please copy and edit those files in your ''<confdir>/services'' directory (have a look to Yaim configuration files").

• gLite lcg-CE variables

Variable name	Type	Descpription <-- -->	>= ig-yaim version
''CE_RUNTIMEENV''	C	Add the following tags to runtime environment: * If your site belongs to INFN write ''<CITY>'' in capitals (ex. ''PADOVA'') otherwise ''<INSTITUTE>-<CITY>'' in capitals (ex. ''SNS-PISA'') * Write the average value of SpecInt2000 and SpecFloat2000 for your WNs; please note that now a '_' is used as separator in place of '=' (see at http://repo-pd.italiangrid.it/fileadmin/Certification/MetricHowTo.pdf): SI00MeanPerCPU_<your_value> SF00MeanPerCPU_<your_value>	>= 3.0.1-0

Specific variables are in:

• ''/opt/glite/yaim/examples/siteinfo/services/ig-grelc''

Please copy and edit that file in your ''<confdir>/services'' directory (have a look at Yaim configuration files").

For any details please refer to the GRELC Documentation

HLR

Configuration file:

Specific variables are in:

• ''/opt/glite/yaim/examples/siteinfo/services/ig-hlr''

Please copy and edit that file in your ''<confdir>/services'' directory (have a look at Yaim configuration files").

HYDRA

Configuration file:

Specific variables are in:

• ''/opt/glite/yaim/examples/siteinfo/services/ig-hydra_mysql''

Please copy and edit that file in your ''<confdir>/services'' directory (have a look at Yaim configuration files").

• gLite HYDRA variables

Example 1: Three instances on the same server

HYDRA_INSTANCES="1 2 3"

HYDRA_DBNAME_1=hydra_db_1
HYDRA_DBUSER_1=hydra1
HYDRA_DBPASSWORD_1=xxxx
HYDRA_CREATE_1=/enmr.eu/Role=NULL/Capability=NULL
HYDRA_ADMIN_1=/enmr.eu/Role=admin

HYDRA_DBNAME_2=hydra_db_2
HYDRA_DBUSER_2=hydra2
HYDRA_DBPASSWORD_2=xxxx
HYDRA_CREATE_2=/enmr.eu/Role=NULL/Capability=NULL
HYDRA_ADMIN_2=/enmr.eu/Role=admin

HYDRA_DBNAME_3=hydra_db_3
HYDRA_DBUSER_3=hydra3
HYDRA_DBPASSWORD_3=xxxx
HYDRA_CREATE_3=/enmr.eu/Role=NULL/Capability=NULL
HYDRA_ADMIN_3=/enmr.eu/Role=admin

Example 2: Single instance on a server, into a system of three separated HYDRA servers

HYDRA_INSTANCES="1"

HYDRA_DBNAME_1=hydra_db_1
HYDRA_DBUSER_1=hydra1
HYDRA_DBPASSWORD_1=xxxx
HYDRA_CREATE_1=/enmr.eu/Role=NULL/Capability=NULL
HYDRA_ADMIN_1=/enmr.eu/Role=admin

HYDRA_PEERS="2 3"

HYDRA_CREATE_2=/enmr.eu/Role=NULL/Capability=NULL
HYDRA_ID_2=1
HYDRA_HOST_2=hydra.host.fqn

HYDRA_CREATE_3=/enmr.eu/Role=NULL/Capability=NULL
HYDRA_ID_3=1
HYDRA_HOST_3=hydra.host.fqn2

The section "HYDRA_PEERS" contains the information about the servers installed on remote machines, that have to work with the server you're installing. Please note that HYDRA_ID is the remote hydra server "instance id" specified into its site-info configuration file. If you have only one installation for every single machine, most probably the HYDRA_IDs are all "=1". Ask remote servers' site admins.

After the Hydra installation and configuration, you'll be able to get service information by a LDAP query vs. <hydra_hostname>:2170. So you'll need to register it into your site-BDII. All the Hydra services must be found into a top-BDII to work together.

LFC

• gLite LFC variables

MyProxy

• gLite MyProxy variables

SE dCache

Configuration file:

Specific variables are in:

• ''/opt/glite/yaim/examples/siteinfo/services/glite-dcache''

Please copy and edit that file in your ''<confdir>/services'' directory (have a look at Yaim configuration files").

• gLite SE dCache variables

Please pay attention on the configuration of a dCache node - follow the instructions present at:

• Notes_on_configuring_the_dCache
• dCacheConfigure.sh
• Advanced Site-Info.Def For Yaim

SE DPM

Configuration file:

Specific variables are in (copy only the one you need):

• ''/opt/glite/yaim/examples/siteinfo/services/glite-se_dpm_disk''
• ''/opt/glite/yaim/examples/siteinfo/services/glite-se_dpm_mysql''
• ''/opt/glite/yaim/examples/siteinfo/services/glite-se_dpm_oracle''

Please copy and edit that file in your ''<confdir>/services'' directory (have a look at Yaim configuration files").

• gLite SE DPM variables

SE StoRM Backend

Configuration file:

Specific variables are in:

• ''/opt/glite/yaim/examples/siteinfo/services/ig-se_storm_backend''

Please copy and edit that file in your ''<confdir>/services'' directory (have a look at Yaim configuration files").

STORM_CKSUM_SERVICE_LIST="host1,status_port1,service_port1 host2,status_port2,service_port2"

STORM_GRIDFTP_POOL_LIST="host1,weight1 host2,weight2 host3,weight3"

Then, for each ''<SA>'' "Storage Area" listed in ''STORM_STORAGEAREA_LIST'' variable you have to edit the following compulsory variables:

NOTE:

''<SA>'' has to be written in capital letters as in the other ''<site-info.def>'' variables otherwise default values will be used!
ATTENTION: for the DNS-like names (using special characters as "." (dot), "-" (minus)) you have to remove the ".". "-": e.g. for ''STORM_STORAGEAREA_LIST="enmr.eu"'' ''<SA>'' should be ''ENMREU'' like:

STORM_ENMREU_VONAME=enmr.eu

and eventually the following optional variables:

groupname1:permissions1 [groupname2:permissions2 [...]]

SE StoRM Frontend

Configuration file:

Specific variables are in:

• ''/opt/glite/yaim/examples/siteinfo/services/ig-se_storm_frontend''

Please copy and edit that file in your ''/services'' directory (have a look at Yaim configuration files").

VOBOX

Configuration file:

Specific variables are in:

• ''/opt/glite/yaim/examples/siteinfo/services/glite-vobox''

Please copy and edit those files in your ''<confdir>/services'' directory (have a look at Yaim configuration files").

• gLite VOBOX variables

WMS

Configuration file:

Specific variables are in:

• ''/opt/glite/yaim/examples/siteinfo/services/glite-wms''

Please copy and edit those files in your ''<confdir>/services'' directory (have a look at Yaim configuration files").

• gLite WMS variables

WN

Configuration file:

Specific variables are in:

• ''/opt/glite/yaim/examples/siteinfo/services/glite-mpi''
• ''/opt/glite/yaim/examples/siteinfo/services/glite-mpi_wn''

Please copy and edit those files in your '<confdir>/services'' directory (have a look at Yaim configuration files").

• gLite WN variables

IGI YAIM configuration files

Amga

• gLite AMGA variables

CREAM CE

Configuration file:

Specific variables are in:

• ''/opt/glite/yaim/examples/siteinfo/services/glite-creamce''

Please copy and edit that file in your ''/services'' directory (have a look to Yaim configuration files").

• gLite CREAM variables

FTS

• gLite FTS variables

GRELC

For any details refer to GRELC Documentation

LB

• gLite LB variables

IGI Installation and Configuration Guide for gLite 3.2 SL5 x86_64

• IGI Node Traker

INFNGRID Installation and Configuration Guide for gLite 3.2 SL5 x86_64

This document is a complete guide for the installation and the configuration of INFNGRID profiles aligned with gLite middleware version 3.2 on SL5 (or RHEL5 clones) for x86_64 architecture (no i386 profiles have been deployed up to now).

Currently only few profiles have been ported to SL5 x86_64 and integrated in INFNGRID release. At the following link you can find the current status of gLite and INFNGRID porting:

• gLite Node Tracker
• INFNGRID Node Traker

If you find errors in this document please open a ticket to the "Release & Documentation" group using the INFNGRID trouble ticketing system.

Released profiles:

IMPORTANT NOTE: Please be aware that the profile ig_GRIDFTP is obsoleted by the ig_SE_storm_gridftp, and an updgrade is not possible, only fresh installations of the ig_SE_storm_gridftp

Here below an updated lists of currently deployed profiles with related metapackage and nodetype names:

Please keep in mind the difference between the following three concepts because of their different scopes and uses:

• profile => we use this word to //generically// call a service
• metapackage => we use this word during //installation// phase
• nodetype => we use this word during //configuration// phase

Documentation references:

Please also refer to these gLite official guides:

• Generic Installation and Configuration Guide for gLite 3.2
• YAIM 4 Guide for Sysadmins
• YAIM Configuration Variables
• YAIM 4 Known Issues

exclude=c-ares

Special cases

CE and Batch Server configuration (access to log files)

It doesn't matter what kind of deployment you have, batch-system master on a different machine than the CE (CREAM, TORQUE or LSF) or on the same one, you have to be sure that you provide access to the batch system log files: You must set up a mechanism to ''transfer'' accounting logs to the CE:

• through NFS (don't forget to set $BATCH_LOG_DIR and $DGAS_ACCT_DIR in <your-site-info.def> configuration file)
• through a daily cron job to the directory defined in $BATCH_LOG_DIR and $DGAS_ACCT_DIR in <your-site-info.def> configuration file

CREAM_torque (multiple CEs and single Batch Server)

This configuration requires particular attention both during the metapackage installation and during the nodetype configuration.

Install the first CE (that will act also as Batch Server) following the usual procedure:

yum install ig_CREAM_torque

Install the other secondary CEs without batch server software as follows:

yum install ig_CREAM glite-TORQUE_utils

Standalone TORQUE_server

You should use the following .repo files, glite-torque_server.repo & glite-torque_utils.repo

yum install glite-TORQUE_server glite-TORQUE_utils

for the CEs (creamCEs), add the glite-torque_utils.repo file and:

yum install ig_CREAM glite-TORQUE_utils

Please pay attention also to the configuration for this special case

Batch system installation (only for WN)

LSF server/client installation must be done *manually*, whereas Torque server/client installation is included in the metapackage.

Whole site: How to enable a VO

extra_configuration

Default files

Variables that contain a meaningful default value are distributed under ''/opt/glite/yaim/defaults/'' directory and that don't need to be changed unless you are an advanced user and you know what you are doing. The files are:

• ''ig-site-info.pre'';
• ''ig-site-info.post'';
• ''<node-type>.pre'', ''glite-<node-type>.pre'', ''ig-<node-type>.pre'';
• ''<node-type>.post'', ''glite-<node-type>.post'', ''ig-<node-type>.post''.

In case you really need to change these variables, you don't need to modify the value in these files if you don't want to edit them. You can just add the same variable in site-info.def since this will overwrite the variables declared in these files. See the configuration flow in YAIM in the next section.

Configuration flow

This is the order in which the different configuration files are sourced (''<confdir>'' refers to the path of the configuration folder which is the path of ''<your-site-info.def>''):

1. defaults ''.pre'' files in ''/opt/glite/yaim/defaults/'';
2. ''<confdir>/<your-site-info.def>'';
3. service-specific files in ''<confdir>/services/'';
4. defaults ''.post'' files in ''/opt/glite/yaim/defaults/'';
5. node-specific files in ''<confdir>/nodes/'';
6. VO-specific files in ''<confdir>/vo.d/'';
7. function files in ''/opt/glite/yaim/node-info.d/'';
8. VO-specific group settings in ''<confdir>/group.d/*''.

Configuration variabiles

General

In the documentation you could find all the INFNGRID variables and some important gLite variables that can be configured in ''<your-site-info.def>'' are listed in alphabetically sorting (links to gLite variables are also listed):

• C = compulsory, if you are going to configure that type of node;
• O = optional.

For the other gLite variables please consider the official "site-info.def" information at "YAIM 4 guide for sysadmins".

Generic

• gLite site-info.def variables
• gLite VO-related variables
• gLite site-info.pre variables
• gLite site-info.post variables

# lsb_release -i | cut -f2 ScientificSL More details here: "| How to publish the OS name". | 3.0.1-0 |

''CE_OS_ARCH''	C	OS architecture. Set using the output of the following command run on your WNs: # uname -m i686 More details here: "[[http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_my_machine_architecture	How to publish my machine architecture]]".	3.0.1-0
''CE_OS_RELEASE''	C	OS release. Set using the output of the following command run on your WNs: # lsb_release -r | cut -f2 4.5 More details here: "How to publish the OS name".	3.0.1-0
''CE_OS_VERSION''	C	OS version. Set using the output of the following command run on your WNs: # lsb_release -c | cut -f2 Beryllium More details here: "How to publish the OS name".	3.0.1-0
''CE_PHYSCPU''	C	Total number of physical CPUs in the system (i.e. number of sockets). ATTENTION: if you have more than one CE and shared WNs set this variable to "0". More details here: "GIISQuery_Usage".	4.0.3-0
''HOST_SW_DIR''	O	Host exporting the directory for SGM (usually a CE or a SE).	3.0.1-0
''INT_NET''	O	If PRIVATE_NETWORK=true, uncomment and write your internal network.	3.0.1-0
''INT_HOST_SW_DIR''	O	If PRIVATE_NETWORK=true, uncomment and write the internal hostname of the host exporting the directory used to install the application software.	3.0.1-0
''MY_INT_DOMAIN''	O	If PRIVATE_NETWORK=true, uncomment and write the internal domain name	3.0.1-0
''NTP_HOSTS_IP''	C	Space separated list of the IP addresses of the NTP servers (preferably set a local ntp server and a public one, ex. pool.ntp.org).	3.0.1-0
''PRIVATE_NETWORK''	O	Set PRIVATE_NETWORK=true to use WN on private network.	3.0.1-0

Batch server

Variable name	Type	*Descpription	>= ig-yaim version
''BATCH_LOG_DIR''	C	Path for the batch-system log files: "/var/torque" (for torque); "/lsf_install_path/work/cluster_name/logdir" (for LSF). In case of separate batch-master (not on the same machine as the CE) PLEASE make sure that this directories are READABLE from the CEs	3.0.1-0
''BATCH_CONF_DIR''	C	Only for LSF. Set path where ''lsf.conf'' file is located.	3.0.1-0

BDII Site

Specific variables are in the configuration file: * ''/opt/glite/yaim/examples/siteinfo/services/glite-bdii_site''

Please copy and edit that file in your ''<confdir>/services'' directory (have a look to Yaim configuration files").

* gLite BDII Site variables

Variable name	Type	Descpription	>= ig-yaim version
''BDII__URL''	C	If you are configuring a 3.1 node change the port to ''2170'' and ''mds-vo-name'' to ''resource''. For example: BDII_CE_URL="ldap://$CE_HOST:2170/mds-vo-name=resource,o=grid"	3.0.1-0
''CLOSE_SE_HOST''	C	Set the close SE for the site. It is chosen between one of the site SEs.	>= 4.0.3-0
''SITE_BDII_HOST''	C	Host name of site BDII	>= 3.0.1-0
''SITE_DESC''	C	A long format name for your site	>= 4.0.4-0
''SITE_SECURITY_EMAIL''	C	Contact email for security	>= 4.0.4-0
''SITE_OTHER_GRID''	C	Grid to which your site belongs to, i.e. WLG or EGEE. Use: SITE_OTHER_GRID="EGEE"	4.0.4-0
''SITE_OTHER_EGEE_ROC''	C	Agree within your ROC what the field should be. USE: SITE_OTHER_EGI_ROC="Italy"	4.0.4-0

BDII Top

* gLite BDII Top variables

By default, a BDII_top is configured to contact the GOC_DB. If you want to modify this behaviour, after the configuration you have to edit the /etc/glite/glite-info-update-endpoints.conf file using the following settings:

[configuration]
EGI = FALSE
OSG = FALSE
manual = True
manual_file = /opt/glite/yaim/config/>file_containing_your_sites.conf>
output_file = /opt/glite/etc/gip/top-urls.conf
cache_dir = /var/cache/glite/glite-info-update-endpoints 

The file containing the list of sites "known" to the BDII_top is updated every hour by the cron-job /etc/cron.hourly/glite-info-update-endpoints.

DGAS services on CE ( CE CREAM )

Variable name	Type	Descpription	>= ig-yaim version
''DGAS_ACCT_DIR''	C	Path for the batch-system log files. - for torque/pbs: DGAS_ACCT_DIR=/var/torque/server_priv/accounting - for LSF: DGAS_ACCT_DIR=lsf_install_path/work/cluster_name/logdir	4.0.8-3
''DGAS_IGNORE_JOBS_LOGGED_BEFORE''	O	Bound date on jobs backward processing. The backward processing doesn't consider jobs prior to that date. Use the format as in this example: DGAS_IGNORE_JOBS_LOGGED_BEFORE="2007-01-01" Default value: ''2008-01-01''	4.0.2-9
''DGAS_JOBS_TO_PROCESS''	O	Specify the type of job which the CE has to process. ATTENTION: set "all" on "the main CE" of the site (the one with the best hardware), "grid" on the others. Default value: ''all''	4.0.2-9
''DGAS_HLR_RESOURCE''	C	Reference Resource HLR hostname. There is no need to specify the port as in the previous yaim versions (default value "''56568''" will be set by yaim).	4.0.2-9
''DGAS_USE_CE_HOSTNAME''	O	Only for LSF. Main CE of the site. ATTENTION: set this variable only in the case of site with a single LSF Batch Master (no need to set this variable in the Torque case) in which there are more than one CEs or local submission hosts (i.e. host from which you may submit jobs directly to the batch system.). In this case, ''DGAS_USE_CE_HOSTNAME'' parameter must be set to the same value for all hosts sharing the "lrms" and this value can be arbitrary chosen among these submitting hostnames (you may choose the best one). Otherwise leave it commented. For example: DGAS_USE_CE_HOSTNAME="my-ce.my-domain"	4.0.2-9
''DGAS_MAIN_POLL_INTERVAL''	O	UR Box parse interval, that is if all jobs have been processed: seconds to wait before looking for new jobs in UR Box. default value "5"	4.0.11-4
''DGAS_JOB_PER_TIME_INTERVAL''	O	Number of jobs to process at each processing step (several steps per mainPollInterval, depending on the number of jobs found in chocolateBox). default value "40"	4.0.11-4
''DGAS_TIME_INTERVAL''	O	Time in seconds to sleep after each processing step (if there are still jobs to process, otherwise start a new mainPollInterval). default value "3"	4.0.11-4
''DGAS_QUEUE_POLL_INTERVAL''	O	Garbage clean-up interval in seconds. default value "2"	4.0.11-4
''DGAS_SYSTEM_LOG_LEVEL''	O	The "systemLogLevel" parameter defines the log verbosity from 0(no logging) to 9(maximum Verbosity) default value "7"	4.0.11-4

GLEXEC_wn

* gLite GLEXEC variables

Functional Description:

* The gLExec system, used in combination with the LCAS site-local authorization system and the LCMAPS local credential mapping service, provides an integrated solution for site access control to grid resources. With the introduction of gLExec, the submission model can be extended from the traditional gatekeeper models, where authorization and credential mapping only take place at the site’s ‘edge’. Retaining consistency in access control, gLExec allows a larger variety of job submission and management scenarios that include per-VO schedulers on the site and the late binding of workload to job slots in a scenario where gLExec in invoked by pilot jobs on the worker node. But it is also the mapping ingredient of a new generation of resource access services, like CREAM.

More details here.

UI

* gLite UI variables

Configuration files

INFNGRID YAIM configuration files

Additional files

Configuration files

INFNGRID YAIM configuration files

Additional files

Configuration files

<-- including doc:guides:yaim-configuration-files // /var/lib/gforge/chroot/home/groups/igrelease/htdocs/data/pages/doc/guides/yaim-configuration-files.txt -->

INFNGRID YAIM configuration files

YAIM configuration files should be stored in a directory structure. All the involved files HAVE to be under the same folder <confdir>, in a safe place, which is not world readable. This directory should contain:

vimdiff /opt/glite/yaim/examples/siteinfo/ig-site-info.def <confdir>/<your-site-info.def>

Additional files

Furthermore the configuration folder can contain:

# cat vo.d/lights.infn.it
SW_DIR=$VO_SW_DIR/lights
DEFAULT_SE=$SE_HOST
VOMS_SERVERS="vomss://voms2.cnaf.infn.it:8443/voms/lights.infn.it?/lights.infn.it"
VOMSES="lights.infn.it voms2.cnaf.infn.it 15013 /C=IT/O=INFN/OU=Host/L=CNAF/CN=voms2.cnaf.infn.it lights.infn.it"

The optional folders are created to allow system administrators to organise their configurations in a more structured way.”

IMPORTANT NOTE:
If your site has the intention to support more VOs than the default ones, you should have a look at ”Whole site: How to enable a VO”, specially for the enmr.eu VO, once the configuration finished you should follow ”extra_configuration”.

IGI (based on gLite 3.2 release) Installation and Configuration

Installation

OS installation

Install SL5 using SL5.X repository (CERN mirror) or one of the supported OS (RHEL5 clones).

You may find information on official repositories at Repositories for APT and YUM
If you want to set up a local installation server please refer to Mrepo Quick Guide

NOTE: Please check if NTP , cron and logrotate are installed, otherwise install them!

Check the FQDN hostname

Ensure that the hostnames of your machines are correctly set. Run the command:

 hostname -f

It should print the fully qualified domain name (e.g. prod-ce.mydomain.it). Correct your network configuration if it prints only the hostname without the domain. If you are installing WN on private network the command must return the external FQDN for the CE and the SE (e.g. prod-ce.mydomain.it) and the internal FQDN for the WNs (e.g. node001.myintdomain).

Repository Settings

To have more details to the repository have a look to the this link Repository Specifications

With standard installation of SL5 it's possible that you have the EPEL repository enabled. Please disable it:

# mv /etc/yum.repos.d/epel.repo /etc/yum.repos.d/epel.repo.disabled

otherwise you'll get the following error:

Missing Dependency: libcares.so.0()(64bit) is needed by package glite-security-gss-2.0.0-3.sl5.x86_64 (glite-generic_sl5_x86_64_release)

because of the presence of newer version of c-ares (1.4.0-1.el5). The middleware needs the 1.3.0-4.sl5 !

Remeber to enabled the dag.repo :

With standard installation of SL5 it's possible that you have the DAG repository. Please check if it is enabled, if no please enabled it:

cat /etc/yum.repos.d/dag.repo

.... enabled=1 ....

Common repositories

Each profile needs a set of common repositories:

Common repositories *x86_64*
dag.repo
ig.repo
egi-trustanchors.repo

In order to have a working IGI service you have to download also the gLite repo files. In the table bellow you'll find the match from metapackages to profiles.

Profile-specific repositories

Furthermore each profile needs a set of repositories that contain the profile-related middleware. Look at the table below to know what specific repositories your profile needs:

Metapackages	Profile-specific repositories *x86_64*
ig_ARGUS	glite-argus.repo
ig_BDII_top	glite-bdii_top.repo
ig_BDII_site	glite-bdii_site.repo
ig_CREAM ig_CREAM_LSF	glite-cream.repo
ig_CREAM_torque	glite-cream_torque.repo
ig_FTA_oracle	glite-fta_oracle.repo
ig_FTM	glite-ftm.repo
ig_FTS_oracle	glite-fts_oracle.repo
ig_GLEXEC_wn	glite-glexec.repo
ig_HLR	glite-generic.repo
ig_LB	glite-lb.repo
ig_LFC_mysql	glite-lfc_mysql.repo
ig_SE_dpm_mysql	glite-se_dpm_mysql.repo
ig_SE_dcache_info	glite-se_dcache_info.repo
ig_SE_dcache_nameserver_chimera	glite-se_dcache_nameserver.repo
ig_SE_dcache_pool	glite-se_dcache_pool.repo
ig_SE_dcache_srm	glite-se_dcache_srm.repo
ig_SE_storm_backend ig_SE_storm_frontend ig_SE_storm_checksum	ig-storm.repo
ig_SE_storm_gridftp	ig-storm_gridftp.repo
ig_UI ig_UI_noafs	glite-ui.repo
ig_VOBOX	glite-vobox.repo
ig_VOMS_mysql	glite-voms_mysql.repo
ig_VOMS_oracle	glite-voms_oracle.repo
ig_WN, ig_WN_noafs ig_WN_LSF, ig_WN_LSF_noafs	glite-wn.repo
ig_WN_torque, ig_WN_torque_noafs	glite-wn_torque.repo

Then update your host:

yum clean all

CAa installation:

Install CAs on ALL profiles:

yum install ca-policy-egi-core

Metapackage installation

Please consider that x86_64 WN profiles has to be installed using the “groupinstall” yum command as follows:

 yum groupinstall <WN_profile>  

where <WN_profile> could be one of: ig_WN, ig_WN_noafs, ig_WN_torque, ig_WN_torque_noafs, ig_WN_LSF, ig_WN_LSF_noafs or

 yum groupinstall <UI_profile>  

where <UI_profile> could be one of: ig_UI, ig_UI_noafs

If you are installing any othere profiles use:

 yum install <metapackage> 

Where <metapackage> is one of those reported on the table above ( Metapackages column).

Configuration

-- CristinaAiftimiei - 2011-11-10