File Transfer Service

Functional description

The FTS is made of 4 separate components, (FTS web service, FTS channel agents, FTS VO agents and FTS Monitor) that can run on the same machine or on separate machines.The FTS web service component allows users to submit FTS jobs and query their status, and to administrate the channels. It is the only component that users interact with.

FTS channel agents are are daemons that control a specific channel. Each network channel, e.g CERN-RAL has a distinct daemon running transfers for it. The daemon is responsible for starting and controlling transfers on the associated network link.

FTS VO agents are responsible for VO-specific parts of the transfer (e.g. updating the replica catalog for a given VO or applying VO-specific retry policies in case of failed transfers). Each VO has a distinct VO agent daemon running for it. Channels and VO agents are usually know as FTA.

FTS Monitor (FTM) provides GridView monitoring feed into the WLCG monitoring system and a couple of modules for basic monitoring.

Daemons running

  • tomcat as container for FTS web services.
  • One daemon for each channel (glite-transfer-channel-agent-<channel-type>-<channel-name>) running as user edguser:edguser.
  • One daemon for each VO (glite-transfer-vo-agent-<VO-name>) .running as user edguser:edguser.
  • FTM (to do).

Init scripts and options (start|stop|restart|...)

  • /etc/rc.d/init.d/tomcat5 (start|stop|restart|status) to control the tomcat server.
  • service transfer-agents (start|stop|restart|...) is used to control the agents.

Configuration files location with example or template

Logfile locations (and management) and other useful

Log Files.

  • Syslog available: no, expected to be included in FTS2.2 currently in certification.

Open ports

  • 8443 for the web services.
  • 2170 For the information system.

Possible unit test of the service

FTS tests.

Where is service state held (and can it be rebuilt)

An Oracle DB is used to store the service states.

Cron jobs

  • /etc/cron.daily/glite-sd2cache-cron

Security information

Access control Mechanism description (authentication & authorization)

Usage of
  • /opt/glite/etc/glite-data-transfer-submit-mapfile
  • /opt/glite/etc/glite-data-transfer-manager-mapfile
  • /opt/glite/etc/submit-mapfile-local

How to block/ban a user

Add the DN to the file /opt/glite/etc/glite-data-transfer-veto-mapfile, following the format:

"the dn" null

I.e. the DN in quotes followed by the "null" word. Actually, the word can be anything, and is ignored. It may look weird, the background is that we follow the gridmap format and use the same parser for each files, and in case of veto, the VO part has no relevance.

Network Usage

A source for the network usage is:
Ganglia graphs

Firewall configuration

  • Incoming connections from world: 8443
  • Outgoing connection to corresponding MyProxy server
  • Connection between Frontends and database backends

Security recommendations

Keep the number of channel managers low and up to date

Security incompatibilities

(left free by now)

List of externals (packages are NOT maintained by Red Hat or by gLite)

Oracle InstantClient

Other security relevant comments

Possible sources of information:

Utility scripts

Nothing reported.

Location of reference documentation for users

Location of reference documentation for administrators

Edit | Attach | Watch | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r16 - 2010-06-18 - unknown
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EGEE All webs login

This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright & by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Ask a support question or Send feedback