public:srmclientinstallation

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
public:srmclientinstallation [2015-02-20 15:22] – [FNAL/dCache client tools] Joern Kuensemoellerpublic:srmclientinstallation [2017-03-08 15:27] (current) – external edit 127.0.0.1
Line 39: Line 39:
 **Note** that the previouly provided ''proxy-init.sh'' script from [[http://code.google.com/p/jlite/|jLite]] is now discouraged because its encryption strength of 512 bit is not considered sufficient any more. SRM sites require a minimum strength of 1024 bit.  **Note** that the previouly provided ''proxy-init.sh'' script from [[http://code.google.com/p/jlite/|jLite]] is now discouraged because its encryption strength of 512 bit is not considered sufficient any more. SRM sites require a minimum strength of 1024 bit. 
  
-To allow usage of the LOFAR VO (Virtual Observatory), there are three additional steps to take:+To allow usage of the LOFAR VO (Virtual Organization), there are three additional steps to take:
  
   * Create a ''vomses'' file to allow ''voms-proxy-init'' to contact the relevant VOMS server   * Create a ''vomses'' file to allow ''voms-proxy-init'' to contact the relevant VOMS server
Line 72: Line 72:
 **NB If the client srm copy call returns timeout messages, the most likely cause is that a firewall is blocking outward connections. The following ports are typically needed by the srm client tools: 8443/8444, 2811, and any port in the gridftp port range (typically in the range 20000 - 25000). Note that these ports are configured on the server side so this list may not be complete for all situations. If at all possible, it is advisable to configure the firewall to allow all outward connections. The next best option is to allow all outward connections to the domains that provide LOFAR LTA services (currently grid.sara.nl, fz-juelich.de, and target.rug.nl)** **NB If the client srm copy call returns timeout messages, the most likely cause is that a firewall is blocking outward connections. The following ports are typically needed by the srm client tools: 8443/8444, 2811, and any port in the gridftp port range (typically in the range 20000 - 25000). Note that these ports are configured on the server side so this list may not be complete for all situations. If at all possible, it is advisable to configure the firewall to allow all outward connections. The next best option is to allow all outward connections to the domains that provide LOFAR LTA services (currently grid.sara.nl, fz-juelich.de, and target.rug.nl)**
  
-**NB2 If you want to enable 'active' transfers, firewalls should allow incoming access to the ports configured as the globus port range (look in client documentation for more details). This type of transfer can improve performance of a single transfer as it will use multiple parallel connections for retrieving a file. For the FNAL/dCache client, 'active' transfers are initiated if the ''-server_mode=passive'' setting is omitted. For the Berkely client, parallel transfers will be initiated when the ''-parallelism'' parameter is set to a value larger than 1. Since in most cases LOFAR datasets consist of a large number of files, a similar performance improvement can be achieved by splitting the set of files over multiple srm copy processes.** 
  
 ==== FNAL/dCache client tools ==== ==== FNAL/dCache client tools ====
Line 81: Line 80:
 </code> </code>
  
-If your firewall allows incoming connections to non-standard ports, you can try this command without the server_mode option which will enable utilization of multiple streams to increase performance.+If your firewall allows incoming connections to non-standard ports, you can try [[#active_gridftp|active gridftp]], which will enable utilization of multiple streams to increase performance.
  
 If you have the [[public:grid_srm_software_installation#globus_client_software|gridftp client software]] installed (requires installation with root privileges) and in your path, it provides superior performance as compared to the native JAVA gridftp client that is provided by srmcp. In order to utilize this, download {{:public:lta-url-copy.sh.gz|lta-url-copy.sh.gz}}, unzip it and use the command: If you have the [[public:grid_srm_software_installation#globus_client_software|gridftp client software]] installed (requires installation with root privileges) and in your path, it provides superior performance as compared to the native JAVA gridftp client that is provided by srmcp. In order to utilize this, download {{:public:lta-url-copy.sh.gz|lta-url-copy.sh.gz}}, unzip it and use the command:
Line 89: Line 88:
  
 **Note:** Usually, the url-copy script requires an absolute destination path. Make sure that you don't use the one from other sources, but the modified script from this page (named //lta-url-copy.sh//, now also included in the tarball below) to retrieve data with the //srm.txt// files from your notification mails.  **Note:** Usually, the url-copy script requires an absolute destination path. Make sure that you don't use the one from other sources, but the modified script from this page (named //lta-url-copy.sh//, now also included in the tarball below) to retrieve data with the //srm.txt// files from your notification mails. 
 +
 +
 +=== Active gridftp ===
 +
 +In the examples above, srmcp is run with the option -server_mode=passive, which limits the transfer to a single stream. If you want to enable 'active' transfers, your firewall has to allow **incoming** access to the ports configured as the globus port range (typically ports 20000-25000, also open 8443, 8444, 2811). 
 +The IP ranges for remote gridftp servers that need to be able to connect to your machine are:
 +
 +  * 145.100.32.0/22, i.e. 145.100.32.0 to 145.100.35.255, for SURFsara 
 +  * 134.94.32.0/22, i.e. 134.94.32.0 to 134.94.32.255, for FZJuelich. 
 +
 +Active gridftp can improve performance of a single transfer as it will use multiple parallel connections for retrieving a file. For the FNAL/dCache client, 'active' transfers are initiated if the ''-server_mode=passive'' setting is omitted. For the Berkely client, parallel transfers will be initiated when the ''-parallelism'' parameter is set to a value larger than 1. Since most cases LOFAR datasets consist of a large number of files, a similar performance improvement can be achieved by splitting the set of files over multiple srm copy processes. This is usually easier to set up than the firewall requirements. Note that e.g. the dCache client does not have a default setting for the gridftp port range. Further, srmcp ignores the GLOBUS_TCP_PORT_RANGE environment variable. You have to specify the port range (that you opened in your firewall) via the ''globus_tcp_prt_range'' option of srmcp, e.g.:
 +
 +
 +  srmcp -globus_tcp_port_range=20000,25000 srm://srm.grid.sara.nl/pnfs/grid.sara.nl/data/lofar/ops/fifotest/file1M file:///file1M 
 +
  
 ====== Prepackaged tarball ====== ====== Prepackaged tarball ======
Line 94: Line 108:
 We provide the {{lofar_grid_clients.tar.gz|Lofar Grid Clients}} tarball that comes prepackaged with the above (except your personal grid certificate of course) to allow easy access to the LOFAR VO. We provide the {{lofar_grid_clients.tar.gz|Lofar Grid Clients}} tarball that comes prepackaged with the above (except your personal grid certificate of course) to allow easy access to the LOFAR VO.
 Extract the tarball to a directory of your liking and source 'init.sh' if you use Java 7 (or newer) or source 'init_java6.sh' if you still use Java 6. This sets up the environment for you. Extract the tarball to a directory of your liking and source 'init.sh' if you use Java 7 (or newer) or source 'init_java6.sh' if you still use Java 6. This sets up the environment for you.
-You can ''voms-proxy-init'' for generating a proxy and ''voms-proxy-info'' for inspecting the generated proxy. +You can ''voms-proxy-init'' for generating a proxy and ''voms-proxy-info'' for inspecting the generated proxy. \\ 
 +It needs (semi-)regular updates of the certificates, with one of the supplied scripts.
  
 ===== Walkthrough ===== ===== Walkthrough =====
Line 106: Line 121:
   * Untar package in directory of your choosing:\\ <code>tar -xvzf lofar_grid_clients.tar.gz</code>   * Untar package in directory of your choosing:\\ <code>tar -xvzf lofar_grid_clients.tar.gz</code>
   * Determine your java version:\\ <code>java -version</code>   * Determine your java version:\\ <code>java -version</code>
-  * Source init.sh (Java 7) or init_java6 (Java 6) in lofar_grid/, e.g. :\\ <code>. lofar_grid/init.sh</code>+  * Source init.sh (Java 7 or 8) or init_java6 (Java 6) in lofar_grid/, e.g. :\\ <code>. lofar_grid/init.sh</code> 
 +  * Update the certificates with one of the provided scripts, e.g.: \\ <code>. update_certificates_eugridpma.sh</code>
   * Optional: Set proxy environment variable to custom location:\\ <code>export X509_USER_PROXY=<proxy_location></code>   * Optional: Set proxy environment variable to custom location:\\ <code>export X509_USER_PROXY=<proxy_location></code>
   * Generate a proxy:\\ <code>voms-proxy-init -voms lofar:/lofar/user</code>   * Generate a proxy:\\ <code>voms-proxy-init -voms lofar:/lofar/user</code>
-  * Test data retrieval:\\ <code>srmcp -server_mode=passive srm://srm.grid.sara.nl/pnfs/grid.sara.nl/data/lofar/ops/fifotest/file1M file:///file1M</code>+  * Test data retrieval:\\ <code>srmcp -server_mode=passive srm://srm.grid.sara.nl/pnfs/grid.sara.nl/data/lofar/ops/fifotest/file1M file://`pwd`/file1M</code>
   * Done!\\ // NB If you modified any default location by the ''export'' command, you have to put it in a shell start-up script like '.bashrc' to make your changes permanent, of course (with full paths where appropriate).//   * Done!\\ // NB If you modified any default location by the ''export'' command, you have to put it in a shell start-up script like '.bashrc' to make your changes permanent, of course (with full paths where appropriate).//
-  * If you get any errors related to CA certificates, retry after running one of the provided scripts to update your certificates, e.g.\\ <code>. update_certificates_eugridpma.sh</code>+  * If you get any errors <del>related to CA certificates</del>, retry after running one of the provided scripts to update your certificates, e.g.\\ <code>. update_certificates_eugridpma.sh</code>  The certificates change every now and then, and then you need to update them.
  
-**Note:** For (t)csh, use *.csh init scripts and 'setenv <key> <value>' instead of 'export <key>=<value>'+**Note:** For (t)csh, use *.csh init scripts and 'setenv <key> <value>' instead of 'export <key>=<value>'.
  
 ====== Troubleshoot ===== ====== Troubleshoot =====
  
-  * OpenJDK 7 seems not to be capable of dealing with the certificate, make sure to run Java provided by Oracle +  * There is a [[public:lta_faq|LTA FAQ page]] that should help with the common difficulties
-  * Error: //Unexpected reply: 426 Connection refused// +
-    * Make sure that you call srmcp with option //-server_mode=passive// +
-  * Error: //org.glite.voms.contact.VOMSException: AC validation failed!//  +
-    * Have you registered at the Lofar VO? --> https://voms.grid.sara.nl:8443/voms/lofar +
-    * You need to have the certificate installed in your browser for this ([[http://ca.dutchgrid.nl/info/browser]]) +
-  * Maybe your private key uses an unsupported algorithm. You might want to try the following command: +
-<code> +
-openssl rsa -des3 -in .globus/userkey.pem -out .globus/userkey.pem +
-</code> +
-  * Once in a while, you probably have to update your CA certificates (see [[#trusted_ca_certificates|trusted CA certificates]]+
-    * If this does not solve the issue, you should carefully check if there are multiple sets of certificates installed and which one is used by srm tools (check environment). If the certificate set in use was updated but is still broken, check for broken symlinks in the certificate directory (especially when using a Mac): +
- +
-Bob mentioned this at some point:  +
-    [The broken symlinks] are not symlinks anymore but just copies of the original +
-    files instead (though I don't see why this matters...). All the files, +
-    except for the .r0 ones, in the certificate directory that have a filename +
-    containing some hash value, should actually be symlinks to files having a +
-    regular name. +
- +
-Apparently, this is caused by some hack-happy developer at Apple. +
-Hanno: +
- +
-    When I tar a directory on my Mac it +
-    includes '._<somefilename>' entries that apparently are used by Mac OS +
-    to set file properties if this tarball is deployed on a Mac again. This +
-    appears to be particularly the case for symlinks and it looks like these +
-    mess up the certificate handling of the SRM clients on the lexar (maybe +
-    all linux systems?). +
- +
-You can check for outdated crls like this (copy-paste from Bob): +
- +
-    Regarding the CRLs / .r0 files: these all have a nextUpdate value, which +
-    basically is their expiration date. This date seems to vary a lot for all +
-    different certificate authorities: some are valid for only a couple of +
-    days, some for weeks, months or even a year. So how often you need to run +
-    the fetch-crl script mostly depends on the CA of both your own certificate +
-    and the certificate of the server(s) you are connecting to. For instance, +
-    my personal certificate is signed by TERENA eScience Personal CA; its CRL +
-    is only valid for a couple of days, after which all these tools start to +
-    complain about an expired CRL. +
-    You can check this yourself by finding the right .r0 file for your CA: they +
-    also have these hash value filenames, so you first have to find which +
-    <hash_value>.0 points to <your_CA>.pem. Then you can use the following +
-    command to find when the CRL was last updated and has to be updated next: +
-    openssl crl -noout -lastupdate -nextupdate -in 169d7f9c.r0 +
  • Last modified: 2015-02-20 15:22
  • by Joern Kuensemoeller