Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
public:srmclientinstallation [2015-02-20 15:21] – [FNAL/dCache client tools] Joern Kuensemoeller | public:srmclientinstallation [2017-03-08 15:27] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 39: | Line 39: | ||
**Note** that the previouly provided '' | **Note** that the previouly provided '' | ||
- | To allow usage of the LOFAR VO (Virtual | + | To allow usage of the LOFAR VO (Virtual |
* Create a '' | * Create a '' | ||
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, | **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, | ||
- | **NB2 If you want to enable ' | ||
==== FNAL/dCache client tools ==== | ==== FNAL/dCache client tools ==== | ||
Line 81: | Line 80: | ||
</ | </ | ||
- | If your firewall allows incoming connections to non-standard ports, you can try this command without the server_mode option | + | If your firewall allows incoming connections to non-standard ports, you can try [[# |
If you have the [[public: | If you have the [[public: | ||
Line 88: | Line 87: | ||
</ | </ | ||
- | **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 / | + | **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 |
+ | |||
+ | |||
+ | === Active gridftp === | ||
+ | |||
+ | In the examples above, srmcp is run with the option -server_mode=passive, | ||
+ | The IP ranges for remote gridftp servers that need to be able to connect to your machine are: | ||
+ | |||
+ | * 145.100.32.0/ | ||
+ | * 134.94.32.0/ | ||
+ | |||
+ | 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, ' | ||
+ | |||
+ | |||
+ | srmcp -globus_tcp_port_range=20000, | ||
====== 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 ' | Extract the tarball to a directory of your liking and source ' | ||
- | You can '' | + | You can '' |
+ | It needs (semi-)regular updates of the certificates, | ||
===== Walkthrough ===== | ===== Walkthrough ===== | ||
Line 106: | Line 121: | ||
* Untar package in directory of your choosing:\\ < | * Untar package in directory of your choosing:\\ < | ||
* Determine your java version:\\ < | * Determine your java version:\\ < | ||
- | * Source init.sh (Java 7) or init_java6 (Java 6) in lofar_grid/, | + | * Source init.sh (Java 7 or 8) or init_java6 (Java 6) in lofar_grid/, |
+ | * Update the certificates with one of the provided scripts, e.g.: \\ < | ||
* Optional: Set proxy environment variable to custom location:\\ < | * Optional: Set proxy environment variable to custom location:\\ < | ||
* Generate a proxy:\\ < | * Generate a proxy:\\ < | ||
- | * Test data retrieval: | + | * Test data retrieval: |
* Done!\\ // NB If you modified any default location by the '' | * Done!\\ // NB If you modified any default location by the '' | ||
- | * If you get any errors related to CA certificates, | + | * If you get any errors |
- | **Note:** For (t)csh, use *.csh init scripts and ' | + | **Note:** For (t)csh, use *.csh init scripts and ' |
====== Troubleshoot ===== | ====== Troubleshoot ===== | ||
- | * OpenJDK 7 seems not to be capable of dealing with the certificate, | + | * There is a [[public:lta_faq|LTA FAQ page]] that should |
- | * Error: // | + | |
- | * Make sure that you call srmcp with option // | + | |
- | * Error: // | + | |
- | * Have you registered at the Lofar VO? --> https:// | + | |
- | * You need to have the certificate installed in your browser for this ([[http:// | + | |
- | * Maybe your private key uses an unsupported algorithm. You might want to try the following command: | + | |
- | < | + | |
- | openssl rsa -des3 -in .globus/ | + | |
- | </ | + | |
- | * Once in a while, you probably have to update your CA certificates (see [[# | + | |
- | * 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 | + | |
- | containing some hash value, | + | |
- | regular name. | + | |
- | + | ||
- | Apparently, this is caused by some hack-happy developer at Apple. | + | |
- | Hanno: | + | |
- | + | ||
- | When I tar a directory on my Mac it | + | |
- | includes ' | + | |
- | to set file properties if this tarball is deployed on a Mac again. This | + | |
- | appears to be particularly | + | |
- | 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: | + | |
- | 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 | + | |
- | < | + | |
- | command to find when the CRL was last updated and has to be updated next: | + | |
- | openssl crl -noout -lastupdate -nextupdate -in 169d7f9c.r0 | + |