Myproxy Configuration and Issues in SC3


This document tries to cover the problems seen so far in SC3 with myproxy usage. It describes the long-term solution that will be implemented, and also describes a short-term solution for immediate use within SC3.

FTS usage of Myproxy

Currently all FTS transfers are done using the user proxy. As opposed to the Resource Broker which can delegate the user proxy at time of job submission, the FTS relies on being able to get a proxy from a myproxy server. Currently each FTS server hard-configures the myproxy server it will use for getting proxies to do the transfers. This leads to a set of issues:

  • The client needs to know what myproxy server a particular FTS has been configured to use. This is currently not published anyway automatically.

  • For a multi-hop transfer, which will be controlled by an experiment framework, if the two channels are on different FTS servers which have different default myproxy servers, then the user will need to be submitted twice.

  • The client must use the myproxy server specified by the FTS - it would be better if the user specified a proxy store that they trusted, and then allowed the FTS to retrieve from it.

  • Problems have been seen with Myproxy when trying to use renewable proxies without passwords (as needed by the RB) and retrievable proxies with passwords (as needed by the FTS) on the same MyProxy server.

Solution to the problems

The clean solution to the problems above is to
  1. Allow the client to specify the myproxy server on which it has stored a proxy when submitting a job. This can introduce a failure where the client has now put the proxy into a myproxy server that doesn't allow the given FTS server to retrieve from it.
  2. Publish into the BDII for each FTS server what myproxy server will be used by default if none are specified by the client.
  3. Allow the client to use a delegated proxy, so myproxy is not required. This does mean that if the transfer does not happen before the proxy expires, the transfer will fail (as curently would happen for a job where there is no proxy in myproxy).

All of these solutions require code changes in the FTS clients and servers, so will take time to roll out. The issue is covered in JRA1 Savannah Bug#10633

Package revisions which have the appropriate fixes


Short-term "fix"

The short-term fix is to create another FTS server at CERN which will allow all SC3 FTS servers to retrieve from it. The hostname is Currently the allowed hosts are (taken from allowed hosts at as default)


We can add whatever sites are needed, please let us know at

Interaction with VOBOX and Resource Broker myproxy servers

With the current myproxy server, it is not possible to store a renewable and a retrievable proxy for the same user on a single server. Since the FTS requires a retrievable proxy, and the RB/VOBOX a renewable proxy, you need different myproxy servers (e.g. If a user needs to use both a VOBOX (or a RB: RB=VOBOX in terms of proxy renewal) and FTS the user has to register 2 proxies in 2 different myproxy servers:

  1. One proxy in without a password (-n option of myproxy-init), and use this for the VOBOX (and RB). All VOBOXES point by default to
  2. One proxy in with a password and use this for FTS transfers.

-- JamesCasey - 26 Sep 2005

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r5 - 2006-11-28 - LaurenceField
    • 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-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback