Show Children Hide Children

Main FTS Pages
FtsRelease22
Install
Configuration
Administration
Procedures
Operations
Development
Previous FTSes
FtsRelease21
FtsRelease21
All FTS Pages
FtsWikiPages
Last Page Update
GavinMcCance
2008-03-18

This procedure is obsolete. You should use the glite-sd2cache tool now - see FtsServicesXmlGliteSd2Cache.

Obsoleted by Gavin McCance, March 2008.

Information cache file

See also FtsTier0ProceduresServiceXml20 for a CERN specific routine.

The FTS requires certain static information from the EGEE.BDII:

  • The endpoints and GOCDB site names of storage elements
  • The endpoint of the MyProxy servers to use
    • For delegation renewal mode, this should be the MyProxy used by the WMS (authorized_renewer mode)
    • For legacy FTS mode, this should be the special MyProxy configured in authorized_retriever mode.

Although the FTA agent server itself has the capability to query the EGEE.BDII directly, the impact of this has not yet been investigated, so we still recommend the use of a static cache file for storing the information from EGEE.BDII. The will contain information about every SRM in EGEE.BDII.

We provide a tool to make the infomation cache snapshot from EGEE.BDII (attached below).

Running the script

The script is called make-services.sh

make-services.sh -h

The script does not need to be run with any options. In this case it will store all SRMs found in the top-level EGEE.BDII lcg-bdii.cern.ch, an entry for the default FTS MyProxy server myproxy-fts.cern.ch and a static service entry for the FTS web-service on the host you are running the script on.

It is recommended to run this script on your web-service node.

It will create a file /opt/glite/etc/services.xml that you should copy to all your FTA agent nodes and web-service nodes (in the same place).

You should do this BEFORE starting any of the FTA agents.

Add local definitions

It is possible to specify local definitions in order include information for services not listed in EGEE.BDII. In order to do that, you need to create a local services.xml like file (named e.g. services.local.xml) and invoke the make-services.sh script with the option --lclxml:

make-services.sh --lclxml services.local.xml

Please note that the local definitions have a higher priority of the ones retrieved from EGEE.BDII, so you can use this feature also to override misconfigured entries.

However, please do not use this feature on production systems, since it can be the source of many configuration issues

Keep old definitions

It is usually desireable to keep the definitions previously retrieved from EGEE.BDII in order to be resilient to intermittent problems with the sites' BDIIs. These definitions will be merged with the new (and the local) ones, but with a lower priority, so if the information in EGEE.BDII is updated, these changes will be reflected into the new services.xml file. In order to use this feature, you need to pass the existing, eventually backed up, services.xml file name with the option --oldxml:

make-services.sh --oldxml services.xml.bak

Verify the newly created file

In order to verify that th new file is correct, you can run the follwowing checks:

  • Check that the number of SRM entries is greater or equal to the ones in the former file.
grep "<type>SRM</type>" services.xml.new | wc -l
grep "<type>SRM</type>" services.xml.bak | wc -l 

  • Verify that the services.xml file is well formatted
export GLITE_SD_SERVICES_XML=services.xml.new
export GLITE_SD_PLUGIN=file
glite-sd-query -t SRM

Restart the agents afterwards

The agents cache the data from the services.xml in memory for 1 hour or so. You should therefore restart them to pick up the new definitions:

service transfer-agents restart

Be gentle

The script makes heavy queries to the EGEE.BDII, essentially sucking all information for all SRMs from it.

It is NOT recommended to run this script from cron.

You should rerun the script only if you see problems with a newly published or changed endpoint.

Pre-prepared file

A pre-prepared file was generated on 19 June 2007 from lcg-bdii.cern.ch and is attached below.

Note that at the very least you'll need to edit it to point to your own FTS web-service.

You should also rerun the make-services.sh script using this as the oldxml to ensure you get any new SRMs that have appeared since this was run.

CERN production

For the CERN production FTS, we usually run the following command line:

./make-services.sh --ftshost prod-fts-ws.cern.ch --serxml /root/services.xml --oldxml /root/services.xml.old --addvo ops --verbose

Please note that the prod-fts-ws.cern.ch in the alias used for the DNS load balanced WebServices nodes.

The full procedure is FtsTier0ProceduresServiceXml20.


Maintainer: GavinMcCance


  • make-services.sh: Script to generate services.xml cache file from BDII (remove duplicated VO entries)
  • services.xml: Initial services.xml script generated on 19 July 2007.

Topic attachments
I Attachment History Action Size Date Who Comment
Unix shell scriptsh make-services.sh r2 r1 manage 21.2 K 2007-07-19 - 11:42 GavinMcCance Script updated for FTS 2.0
XMLxml services.xml r1 manage 344.4 K 2007-07-19 - 11:57 GavinMcCance Initial services.xml file generated on 19 July 2007
Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r5 - 2008-03-18 - GavinMcCance
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback