SG GLITE-3 Guide
From EGEE-see WIki
This guide summarizes installation and configuration instructions for both gLite-3.0 and gLite-3.1. It is based on the experiences gained by AEGIS01-PHY-SCL admins at the Scientific Computing Laboratory of the Institute of Physics in Belgrade, http://scl.phy.bg.ac.yu/
All files used in this guide can be found on http://glite.phy.bg.ac.yu/GLITE-3/
Real configuration files (passwords removed) for AEGIS01-PHY-SCL site can be found on http://glite.phy.bg.ac.yu/GLITE-3/AEGIS/
Specific instructions for installing glite-3.1 WNs on SL4.x can be found in the following SEE-GRID guides: for 32bit SL4 WN glite-3.1, and for 64 bit SL4 WN glite-3.1 64bit.
SEE-GRID customizations of yaim should be applied on all nodes of all SEE-GRID sites by installing always (use rpm -Uvh) the latest glite-yaim-seegrid RPM from: http://glite.phy.bg.ac.yu/GLITE-3/yaim/ Note that glite-yaim-seegrid-1.x RPMs are for the use with YAIM-3, while glite-yaim-seegrid-2.x RPMs are for the use with the latest YAIM-4. Due to restrictions of YAIM release process, note the following: the latest version of customization RPM can always be used on gLite-3.1 nodes, while depending on the availability of YAIM-4 for gLite-3.0 nodes, you may need to use previous version of glite-yaim-seegrid RPM. This is easily deduced: if the installation (-Uvh) fails using the latest RPM, try the previous one, dependencies take care that only the proper RPM can be installed.
Alternatively, customized SEE-GRID yaim source files can be found in http://glite.phy.bg.ac.yu/GLITE-3/yaim/glite-yaim-seegrid-x.y/ or as one .tgz file at http://glite.phy.bg.ac.yu/GLITE-3/yaim/glite-yaim-seegrid-x.y.tgz.
Do not forget to install glite-yaim-seegrid customization RPM (correct version depending on the yaim used)!
Links to the official installation and configuration guides for gLite-3.0 and gLite-3.1 can be found on http://glite.web.cern.ch/glite/documentation/default.asp
Suggested configuration of a SEE-GRID site comprises of one LCG-CE as a front-end to several WNs, one SE_dpm (SE_classic is deprecated - migrate to SE_dpm ASAP), and one MON node. Detailed instructions on SE_dpm configuration parameters are given in SEE-GRID template files available on the link given above, and real-world example of AEGIS01-PHY-SCL conf files can also be used as a reference.
Important changes from the previous version: YAIM's site-info.def variables CE_CPU_ARCHITECTURE is renamed to CE_OS_ARCH, and variable TORQUE_SERVER is renamed to BATCH_SERVER. Note also that the information system on SE_dpm is now using local bdii, and not globus-mds anymore. Take care to adjust BDII_DPM_URL in your site-info.def to be something like
BDII_DPM_URL="ldap://$DPM_HOST:2170/mds-vo-name=resource,o=grid"
Note also that you need to introduce SITE_BDII_HOST variable in site-info.def, which should be set to your site-BDII's FQDN.
If you are upgrading from glite-yaim-3.0.* to the current glite-yaim-3.1 or glite-yaim-4.0, please note that many things are different. The directory containing conf files should now also contain a new directory vo.d. This directory should contain one file per each VO supported (named after VO, lower case letters). In addition to this, conf files have different format and several new variables, so please consult carefully templates and AEGIS01-PHY-SCL conf files available on the links above. Please consult also the new yaim guide (depending on the version of yaim used, choose the appropriate one):
https://twiki.cern.ch/twiki/bin/view/LCG/YaimGuide311
https://twiki.cern.ch/twiki/bin/view/LCG/YaimGuide400
Special care should be devoted to the fact that now the users.conf file format has changed. This is caused by the fundamental change in the treatment of prd and sgm accounts (before, seegridprd and seegridsgm, usually mapped to the production and software grid manager roles in VOMS for each VO). Earlier there was just one prd and one sgm pool account per VO, and they belonged to the same group as all poll accounts for a certain VO. Now this is different: each VO now should have a small pool of prd and sgm accounts (say, 10 of each per VO; prdseegrid001, ..., prdseegrid010, sgmseegrid001, ..., sgmseegrid010), and the primary group of those accounts is not anymore the same as for plain VO pool accounts: there is a separate group for these two roles (e.g. prdseegrid and sgmseegrid), while the secondary group is equal to the usual group for pool accounts (e.g. seegrid). So, for example, prdseegrid001 user will belong to the GROUP prdseegrid (which was the name of the user before!), and its secondary group will be seegrid. This is all reflected in the new template conf files. Note that due to an issue with LCMAPS, you should not use for prd and sgm pool accounts usernames and group names based on VO name with suffixes prd and sgm (that way, .seegrid can be wrongly mapped to seegridprd001!). Instead, prd and sgm should be put as prefixes (like above), or some other notation should be used, so that prd/sgm username (without numerical part) are not extensions of VO pool account names (without numerical part), as explained above. New SEE-GRID template conf files and generate-pool-accounts-AEGIS script reflect this.
In order to avoid problems with the existing pool accounts, we suggest that you disable all queues, wait until all jobs queued at your site are finished, then on all your nodes remove all prd and sgm accounts from /etc/passwd, /etc/shadow, /etc/group, and /etc/gshadow, remove their home directories, and then to proceed with the installation and configuration phase on all nodes. In addition to this remove all prd and sgm related entries in /etc/grid-security/gridmapdir on CE, SE, RB and WMS.
Due to the bug described in GGUS ticket #21103, the cron job is created by YAIM on SE in /etc/cron.monthly (applies to SE_dpm as well as to the SE_classic, which is now deprecated). This cron job had a bug, described in the Savannah ticket #28459. This is fixed with the latest version of YAIM. Note however that, if you install DPM SE for the first time, this cron job must be executed by hand after installation to fix permission issues for the current month.
Note also that new yaim has better command line interface. You should add to your PATH the following: /opt/glite/yaim/bin. After that, you will be able to use the following syntax:
For installation:
yaim -i -s /path/to/site-info.def -m meta-package -m another-meta-package
where meta-package is lcg-CE_torque, or glite-WN, or glite-MON, or glite-SE_dpm_mysql, or glite-SE_dpm_disk etc., as specified in the new yaim guide.
For configuration:
yaim -c -s /path/to/site-info.def -n node-type -n another-node-type
where node-type is CE_torque, or WN_torque (for gLite-3.1 WNs on SL4 use the combination of WN and TORQUE_client), or MON, or SE_dpm_mysql, or SE_dpm_disk etc., as specified in the new yaim guide.
You can also execute some particular yaim functions without reconfiguring the whole node. The syntax is the following:
yaim -r -s /path/to/site-info.def -f yaim-function -f another-yaim-function -n node-type -n another-node-type
where node-type is as before, and yaim functions are named after files in /opt/glite/yaim/functions.
Note that SE and MON node cannot be collocated anymore, due to known problems with clashing ports. So, you need to take this into account when planning the upgrade.
0) SCL scripts for easier administration
A small set of scripts developed at AEGIS01-PHY-SCL, enabling
a) providing public/private key based ssh authentication among all nodes
b) scp of file from one node to all other nodes (or to all WNs, or to all nodes except for WNs)
c) execution of the issued command on all nodes (or on all WNs, or on all nodes except for WNs)
can be found on http://glite.phy.bg.ac.yu/GLITE-3/scl-scripts-0.2.tgz
Read README file for more details.
1) Backup
Please backup your site-info.def, wn-list.conf, users.conf, groups.conf files and your vo.d directory (this one is new as of yaim-3.0.1) if you are keeping them in /opt/glite/yaim/examples/ directory, since they can be replaced by yaim upgrade. Feel free to backup all other conf files you have customized. Just do not copy them afterwards over the upgraded ones, but do diff and change appropriate values, since even format can be different!
2) Scheduled downtime
Before starting the upgrade, you should declare downtime and disable all of your queues. To declare downtime, you should send an e-mail to see-grid-gim@see-grid.eu and enter appropriate information into the HGSM (SEE-GRID GOCDB), available on https://hgsm.grid.org.tr/
To disable the queues, execute as root on your CE:
qdisable seegrid dteam
Add here also other queues you may have configured. Your site will not accept any further jobs. However, you may have some running jobs. You should wait until all of them are executed, and only then start with the upgrade.
3) OS upgrade and configuration
You are encouraged to upgrade your OS as well to the latest version: on service nodes (CE, SE, MON) the recommended OS is SL 3.0.9, and on WNs the recommended version is SL 4.5. On service nodes, the preferred installation method is apt-get. If you are using it, you can upgrade your OS using the following procedure: change /etc/apt/sources.list.d/sl.list on all of your nodes so that it contains
rpm ftp://ftp.scientificlinux.org/linux/scientific/ 309/i386/apt-rpm os updates contrib
and remove repositories for previous SL versions. After that, execute
apt-get update
apt-get dist-upgrade
apt-get upgrade-kernel
If kernel is upgraded, the machine must be rebooted for changes to take effect.
For SL 4.x, simple 'yum upgrade' would do the trick if repositories are properly configured. Please consult the following SEE-GRID guides for installation of WNs on SL4.x: for 32bit SL4 WN glite-3.1, and for 64 bit SL4 WN glite-3.1 64bit..
Check if ntp is working on all nodes (chkconfig ntpd on). Example of configuration file /etc/ntp.conf can be found on http://glite.phy.bg.ac.yu/GLITE-3/ntp.conf
However, be sure to create /etc/ntp.drift and /etc/ntp.drift.TEMP files and to change their ownership to ntp.ntp on all nodes:
touch /etc/ntp.drift
touch /etc/ntp.drift.TEMP
chown ntp.ntp /etc/ntp.drift
chown ntp.ntp /etc/ntp.drift.TEMP
It is also suggested to shut down all services on each node that are not needed, and to remove them from the corresponding runlevel.
Command hostname should return FQDN on all nodes. Be sure that /etc/hosts contains
127.0.0.1 localhost.localdomain localhost
and IP number-FQDN pairs for all nodes (i.e. FQDN is not allowed to be associated with 127.0.0.1).
4) Filesystems
All WNs must have shared application software filesystem where VO SGMs (software grid managers) will install VO-specific software. Please take a look at http://wiki.egee-see.org/index.php/SEE-GRID_ESM_Software_Installation_Guide for more details, including the permissions of directories.
In all template files provided at http://glite.phy.bg.ac.yu/GLITE-3/ it is assumed that this directory is /opt/exp_soft, and that it is mounted through NFS from some NFS serves (can be SE) to CE and all WNs. Note that this has changed from the previous version of this guide! Relevant site-info.def variable is VO_SW_DIR.
The easiest way to accomplish that this shared directory is available on all WNs and on CE, is to allow export of VO_SW_DIR in /etc/exports on the machine exporting it, and to include it in /etc/fstab on all machines that will mount it. This is probably most simple way, since all VOs would eventually require this (even if they do not currently). Do not forget to ensure that relevant nfs services are started automatically on the exporting machine. Example line for /etc/exports on exporting machine, allowing for export of /opt/exp_soft to all machines on the network 147.91.84.*:
/opt/exp_soft 147.91.84.0/255.255.255.0(rw,sync,no_root_squash)
Example line for /etc/fstab on the machine that will mount /opt/exp_soft over nfs from nfs.phy.bg.ac.yu:
nfs.phy.bg.ac.yu:/opt/exp_soft /opt/exp_soft nfs hard,intr,nodev,nosuid,tcp,timeo=15 0 0
Be sure to create /opt/exp_soft on machine that will be mounting it!
The same procedure can be applied to /var/cache/apt/archives (if you want to avoid multiple downloads of update RPMs by apt-get), for /var/cache/yum (if you are using yum), and for /home (if you support MPI).
5) Latest YAIM installation
Download and install latest yaim version on all of your nodes. If you are using apt-get, the command is:
apt-get update; apt-get install glite-yaim
If you use yum:
yum install glite-yaim
You should also apply SEE-GRID customizations. AFTER installing the latest yaim on all nodes, install always (use rpm -Uvh) the latest glite-yaim-seegrid RPM from the following URL:
http://glite.phy.bg.ac.yu/GLITE-3/yaim/
Note that glite-yaim-seegrid-1.x RPMs are for the use with YAIM-3, while glite-yaim-seegrid-2.x RPMs are for the use with the latest YAIM-4.
Alternatively, customized SEE-GRID yaim source files can be found in http://glite.phy.bg.ac.yu/GLITE-3/yaim/glite-yaim-seegrid-x.y/ or as one .tgz file at http://glite.phy.bg.ac.yu/GLITE-3/yaim/glite-yaim-seegrid-x.y.tgz
The customizations provide GridICE agent configuration on WNs and other node types (node-info.def and configure_fmon_client), ntp monitoring by GridICE on all nodes (config_fmon_client), as well as prividing more meaningful information published by the information system using newly introduced variables (SITE_SUPPORT, SITE_SECURITY, PHYSICAL_CPUS, LOGICAL_CPUS) that need to be defined in site-info.def (already present in the SEE-GRID templates). Be aware that you need to install the above RPM on all of your nodes!
6) Preparation of configuration files
You need to prepare the following configuration files:
site-info.def
users.conf
wn-list.conf
groups.conf
directory vo.d with one file per VO
The first four conf files can be named any way you like. It is suggested to put them into selected directory (say, /root/yaim), and not to keep them in /opt/glite/yaim/examples (since it is world readable, e.g. through globus-job-run). The templates for all of these files can be found on http://glite.phy.bg.ac.yu/GLITE-3/
The newly introduced vo.d directory (as of yaim-3.0.1) should contain one file per supported VO with VO-specific definitions. The file for each VO should be named after VO (in lower case letters). Examples are given in http://glite.phy.bg.ac.yu/GLITE-3/vo.d/
The first conf file (site-info-SEEGRID.def is the name of the template) should be adjusted using the instructions and comments in it. It should contain proper paths to all other configuration files. Our production conf files can be found on http://glite.phy.bg.ac.yu/GLITE-3/AEGIS/
The second one (users-SEEGRID.def is the name of the template) can be created using the following script: http://glite.phy.bg.ac.yu/GLITE-3/generate-pool-accounts-AEGIS-v4
GLITE-3_0_2/GLITE-3_0_1 by default uses large number of pool accounts (200 per VO), as well as some additional poll accounts for software grid managers - sgm accounts, and for production - prd accounts. If you did not adjust the pool accounts earlier, or want to rearrange UIDs, the suggested solution is to remove all pool accounts and groups definitions from /etc/passwd, /etc/shadow, /etc/group, and /etc/gshadow, and to remove all of their home directories. All pool accounts information will be created and entered again by yaim. The above script (generate-pool-accounts-AEGIS-v4) can be used like this:
./generate-pool-accounts-AEGIS-v4 seegrid 20000 seegrid 2000 200 10 10 > users-SEEGRID.conf
./generate-pool-accounts-AEGIS-v4 dteam 21000 dteam 2100 200 10 10 >> users-SEEGRID.conf
Please note >> in the second line! This will generate definitions for pool accounts for seegrid in the UID range 20001-20200; 10 prdseegrid accounts will have UIDs 20801 to 20810, and 10 sgmseegrid accounts will have UIDs 20901 to 20910, while GID will be 2000 for plain VO pool accounts, 2080 for prd accounts, and 2090 for sgm accounts (and similar for dteam). Please ensure that UID and GID ranges used here are not already occupied! This is why removing all pool account users is suggested. Our production conf files can be found on http://glite.phy.bg.ac.yu/GLITE-3/AEGIS/
Third configuration file (wn-list-SEEGRID.def is the name of the template) is the same as before. Our production conf files can be found on http://glite.phy.bg.ac.yu/GLITE-3/AEGIS/
Fourth configuration file (groups-SEEGRID.def is the name of the template) is the new one. The template contains definitions for SEEGRID, DTEAM, AEGIS, and DTEAM VO. Remember that just the VOs mentioned in site-info.def variable VOS will be configured - no need to remove the definitions you will not use. More definitions (if needed) can be created by hand (mutatis mutandis, i.e. replacing what should be replaced). Our production conf files can be found on http://glite.phy.bg.ac.yu/GLITE-3/AEGIS/
In order to fully support publishing of the required data in your information system replace the file /opt/lcg/etc/GlueCluster.template on your CE with the following file:
http://glite.phy.bg.ac.yu/GLITE-3/GlueCluster.template
This introduces the attribute GlueHostArchitecturePlatformType to the Glue Schema. You need to define CE_OS_ARCH variable appropriately in your site-info.def file in order for this to work, and of course to use SEE-GRID customized yaim functions.
For sites supporting AEGIS VO
AEGIS (Academic and Educational Grid Initiative of Serbia) created its VO, and all Serbian sites should support it. In order to do so, you should enter aegis among your queues (variable VOS in site-info.def), and the following among VO specific definitions at the end of site-info.def:
AEGIS_GROUP_ENABLE="aegis /VO=aegis/GROUP=/aegis/ROLE=production /VO=aegis/GROUP=/aegis/ROLE=VO-Admin /VO=aegis/GROUP=/aegis/ROLE=sgmadmin"
In addition to this, please ensure that you have the following file in your vo.d directory:
http://glite.phy.bg.ac.yu/GLITE-3/AEGIS/vo.d/aegis
You should also have relevant section in your groups.conf and users.conf; those sections can be copied from our files on http://glite.phy.bg.ac.yu/GLITE-3/AEGIS/
The last is that you copy the following file to /etc/grid-security/vomsdir on all your nodes (VOMS host certificate):
http://glite.phy.bg.ac.yu/GLITE-3/AEGIS/voms.phy.bg.ac.yu.35
7) Installation of nodes
Note that this section only applies to gLite-3.0 nodes. Installation instructions for glite-3.1 WNs on SL4.x can be found in the following SEE-GRID SL4 WN glite-3.1 Guide.
In order to install gLite packages, it is necessary to execute the following command on all nodes (ensure that /opt/glite/yaim/bin is in your PATH):
yaim -i -s /path/to/site-info.def -m meta-package -m another-meta-package
where meta-package is lcg-CE_torque, or glite-WN, or glite-MON, or glite-SE_dpm_mysql, or glite-SE_dpm_disk etc., as specified in the new yaim guide (depending on the version used):
https://twiki.cern.ch/twiki/bin/view/LCG/YaimGuide311
https://twiki.cern.ch/twiki/bin/view/LCG/YaimGuide400
RPM dependencies problems with existing OS packages are to be resolved by removing unnecessary OS packages. Do not hesitate to perform install step several times, until you are sure that everything is properly installed. After the rpm installation is complete, make sure that there are no RPM dependency issues. If you encounter problems, submit a ticket in the SEE-GRID Helpdesk, or try asking for help from the see-grid-gim mailing list.
8) Configuration of nodes
There is no particular order in which nodes should be configured, but it is suggested first to upgrade CE (containing BDII_site), and then all other nodes. Of course, you should configure this node (and all other ones) using all of its types on YAIM command line at the same time, i.e.
yaim -c -s /path/to/site-info.def -n node-type -n another-node-type
where node-type is CE_torque, BDII_site, WN_torque (WN and TORQUE_client on gLite-3.1), MON, SE_dpm_mysql, SE_dpm_disk etc., as specified in the new yaim guide.
Please note that as of recently, BDII_site is necessary to be present when configuring CE if you want site BDII to be configured on it - otherwise, it won't be. This allows that you configure BDII_site on a separate node, if the load is too heavy on the CE.
After CE you should do configure all other nodes. Please, bear in mind that you need to use CE_torque and WN_torque (WN and TORQUE_client on gLite-3.1) node functions in order to include batch system components on CE and on WNs.
If you encounter java problems when configuring MON node, be sure to remove jpackage-utils package.
For sites supporting AEGIS VO
The following should be done on your UI, CE, SE, WMS, and RB.
After configuring the node, please verify that /opt/edg/etc/vomses/ and /opt/glite/etc/vomses/ (if exists) contain configuration file for AEGIS VO. If not, save the following file http://glite.phy.bg.ac.yu/GLITE-3/AEGIS/aegis-voms.phy.bg.ac.yu in /opt/edg/etc/vomses/ and /opt/glite/etc/vomses/ (if exists).
Save host certificate of AEGIS VOMS server to /etc/grid-security/vomsdir/. Host certificate is available on http://glite.phy.bg.ac.yu/GLITE-3/AEGIS/voms.phy.bg.ac.yu.35
9) Postconfiguration
New SEEGRID VOMS RPM should be installed on all nodes requiring it (UI, CE, SE, RB, WMS). You can find it here: http://glite.phy.bg.ac.yu/GLITE-3/seegrid-0.4-2.noarch.rpm
It is also advisable to fine-tune your queues, setting qmgr limits for each VO. Template script is available on http://glite.phy.bg.ac.yu/GLITE-3/tune-queues-SEEGRID while our production script is available on http://glite.phy.bg.ac.yu/GLITE-3/AEGIS/tune-queues-AEGIS
To fine-tune your WNs, adjust /var/spool/pbs/mom_priv/config file and restart pbs_mom on all WNs. Template file is available on http://glite.phy.bg.ac.yu/GLITE-3/mom_priv-config-SEEGRID while our production mom_priv/config file is available on http://glite.phy.bg.ac.yu/GLITE-3/AEGIS/mom_priv-config-AEGIS
Verify that /var/spool/maui/maui.cfg on your CE contains the following line
ADMIN3 edginfo rgma edguser tomcat4
Caveat: If using the gLite3.1 MON version the line should be
ADMIN3 edginfo rgma edguser tomcat
If not, add it and restart maui: /etc/init.d/maui restart
An example snipplet of maui.cfg that reserves one node for prdseegrid/dteam/ops SAM tests is
# use any working node SRCFG[monitoring] FLAGS=SPACEFLEX # reserve one cpu SRCFG[monitoring] TASKCOUNT=1 RESOURCES=PROCS:1 # reserve it forever SRCFG[monitoring] PERIOD=INFINITY # it can be used by seegrid ops user SRCFG[monitoring] GROUPLIST=prdseegrid # give it enough priority to run imediately GROUPWEIGHT 1 GROUPCFG[prdseegrid] PRIORITY=1000000 # or by egee dteam and ops queues SRCFG[monitoring] CLASSLIST=dteam,ops # give them enough priority to run imediately CLASSWEIGHT 1 CLASSCFG[ops] PRIORITY=1000000 CLASSCFG[dteam] PRIORITY=1000000
You should also configure SEE-GRID OPS role, according to the following SEE-GRID_VO_site_configuration Guide.
If yoy are deploying myproxy server (PX node type), please change in /etc/init.d/myproxy the line containing
VERBOSE=--verbose
to
VERBOSE=
and restart myproxy.
10) Custom improvements
Important improvement to /opt/globus/lib/perl/Globus/GRAM/JobManager.pm (that will reduce the load on the CE by invoking 'qstat' command instead of 'qstat -f' when querying for the status of jobs) can be obtained if you replace this file with the patched one:
http://glite.phy.bg.ac.yu/GLITE-3/AEGIS/JobManager.pm
Another improvement that is relevant for sites with homes on WNs shared over NFS:
If you want that jobs arriving at WNs are executed in a local scratch directory (not in pool accounts home directories), you need to change accordingly your job manager. This is specially important if homes are shared over NFS, which is the case for sites supporting MPI. However, those sites do not want that parallel jobs are placed into a scratch directory - they must be executed in shared homes. The following file provides this functionality:
http://glite.phy.bg.ac.yu/GLITE-3/AEGIS/pbs.pm
and it should be put into /opt/globus/lib/perl/Globus/GRAM/JobManager/ directory. Of course, this applies only if you are using pbs job manager. For lcgpbs job manager the changes that should be done are similar, but are not important so much since the homes are not shared, so anyhow the job will be executed from a local directory. In order to avoid that pbs.pm is overwritten during the next configuration, put the following file:
http://glite.phy.bg.ac.yu/GLITE-3/AEGIS/pbs.in
to the /opt/globus/setup/globus/ directory).
Of course, you will need to properly define scratch directory. The suggested is to create /scratch on all WNs and on CE (chmod a+rwx /scratch), and to set the following shell variables to /scratch: TMPDIR and EDG_WL_SCRATCH. They need to be undefined if a job is MPI. The convenient way to do this is to place the following files into /etc/profile.d on all of your WNs and on CE:
http://glite.phy.bg.ac.yu/GLITE-3/AEGIS/scl-wn.sh
http://glite.phy.bg.ac.yu/GLITE-3/AEGIS/scl-wn.csh
11) Testing
This should be it. Verify that all queues are correctly configured and enabled:
qmgr -c "print server"
You can enable or disable queues using qenable and qdisable comands.
Test if your site correctly publishes data using SEE-GRID GStat available on http://goc.grid.sinica.edu.tw/gstat/seegrid/
However, be patient - the status published on GStat page is about 15 minutes delayed, so any changes will not be reflected immediately. You can also query your site-BDII ane verify correctness of the data issuing the following command:
ldapsearch -x -H ldap://<CE FQDN>:2170 -b mds-vo-name=<SITE-NAME>,o=grid
where <CE FQDN> should be replaced by your CE hostname, and <SITE-NAME> with the appropriate name of your site enetered into the site-info.def and in SEE-GRID top-level BDIIs (example: AEGIS01-PHY-SCL for our site).
Verify that you CE and SE are visible by SEE-GRID BDII:
lcg-infosites --vo seegrid ce
lcg-infosites --vo seegrid se
You can also use WiatG tool for browsing BDII information.
Also, you can try to submit simple test jobs to your site and to retrieve the output.
If you encounter problems, submit a ticket in SEE-GRID Helpdesk, or contact see-grid-gim@see-grid.eu mailing list; other SEE-GRID GIMs will probably be able to help you.
