Installing OSG Client

1 About This Document

hand This document is for grid users and system administrators. It covers the installation of the OSG Client Tools Package. This package is required on every host used by grid users to submit jobs, transfer data, or interact otherwise with the OSG. Note there is also a Worker Node Client that is not a valid substitute for this package. Likewise the OSG Client cannot replace the Worker Node Client in the batch jobs environment on Worker Node and Compute Element.

The OSG Cient Tools Package includes:

HELP NOTE
The osg_client use case is not really a well-defined use case any longer and is dropped from 3.3 series. But the different parts can still be obtained

HELP NOTE
This document does not cover the usage of the client tools. An introduction how to use the OSG can be found here. A more detailed description how to interact with a Compute Element is located here.

on on

2 Engineering Considerations

The OSG Client Tools Package is required on hosts used to submit jobs to the Open Science Grid. We recommend to install the OSG Client Tools on a dedicated job submission host for large scale job submissions to production resources on the OSG. We recommend to use a public IP address and a fully qualified domain name for shared job submission hosts.

3 Requirements

3.1 Host and OS

  • A host to install the OSG Client (pristine node). No grid host certificate is required.
  • OS is Red Hat Enterprise Linux 5, 6, 7, and variants (see details...)
  • Root access

3.2 Certificates

To test and use the installation a valid grid user certificate is required.

3.3 Networking

For more details on overall Firewall configuration, please see our Firewall documentation.

Service Name Protocol Port Number Inbound Outbound Comment
GRAM callback tcp GLOBUS_TCP_PORT_RANGE Y   contiguous range of ports
GRAM callback tcp GLOBUS_TCP_SOURCE_RANGE   Y contiguous range of ports
HTCondor port range tcp LOWPORT, HIGHPORT Y   contiguous range of ports

GRAM is not really a service on the client. It is the protocol used by the Globus clients. Anyway the clients still requires the port ranges to be open: job submission needs ports to reach the servers and to transfer back the output; file transfers need ports for control and data sessions.
HTCondor is in reality HTCondor-G the version configured to submit grid jobs.

You'll find more client specific details also in the Firewall section of this document.

3.4 Minimum Version

Starting on 11 February 2014, all OSG-issued Digicert certificates (host, service, and personal) use the SHA-2 algorithm. Some software in the Worker Node Client — notably dCache SRM client — must be on a recent version to support SHA-2 certificates. Please visit our SHA-2 compliance page for more information about minimum required versions of software components.

4 Contents of the OSG Client package

The OSG client may be updated from time to time. As of OSG 3.1.8 in September 2012, the OSG client contains:

  • Everything in the OSG worker node client
  • Bandwidth Test Controller (bwctl) client
  • GSI OpenSSH client
  • Globus GRAM clients (including globus-job-run)
  • Globus certificate utilities (including grid-proxy-init)
  • Network Diagnostic Tool (NDT)
  • Nmap (security scanner)
  • One-Way Ping (owamp) client)
  • lcg-info
  • lcg-infosites
  • osg-cert-scripts
  • osg-discovery
  • osg-system-profiler
  • osg-version

If you installed the osg-client-condor package, it will also install HTCondor.

If you like, you can see exactly what your version of the OSG client package installed:

[user@client ~]$ rpm -q --requires osg-client

More details on using RPM to see what was installed

5 Installation and Configuration Procedure

Install the Yum Repositories required by OSG

The OSG RPMs currently support Red Hat Enterprise Linux 5, 6, 7, and variants (see details...).

OSG RPMs are distributed via the OSG yum repositories. Some packages depend on packages distributed via the EPEL repositories. So both repositories must be enabled.

Install EPEL

  • Install the EPEL repository, if not already present. Note: This enables EPEL by default. Choose the right version to match your OS version.
    # EPEL 5 (For RHEL 5, CentOS 5, and SL 5) 
    [root@client ~]$ curl -O https://dl.fedoraproject.org/pub/epel/epel-release-latest-5.noarch.rpm
    [root@client ~]$ rpm -Uvh epel-release-latest-5.noarch.rpm
    # EPEL 6 (For RHEL 6, CentOS 6, and SL 6) 
    [root@client ~]$ rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
    # EPEL 7 (For RHEL 7, CentOS 7, and SL 7) 
    [root@client ~]$ rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
    WARNING: if you have your own mirror or configuration of the EPEL repository, you MUST verify that the OSG repository has a better yum priority than EPEL (details). Otherwise, you will have strange dependency resolution (depsolving) issues.

Install the Yum priorities package

For packages that exist in both OSG and EPEL repositories, it is important to prefer the OSG ones or else OSG software installs may fail. Installing the Yum priorities package enables the repository priority system to work.

  1. Choose the correct package name based on your operating system’s major version:

    • For EL 5 systems, use yum-priorities
    • For EL 6 and EL 7 systems, use yum-plugin-priorities
  2. Install the Yum priorities package:

    [root@client ~]$ yum install PACKAGE

    Replace PACKAGE with the package name from the previous step.

  3. Ensure that /etc/yum.conf has the following line in the [main] section (particularly when using ROCKS), thereby enabling Yum plugins, including the priorities one:

    plugins=1
    NOTE: If you do not have a required key you can force the installation using --nogpgcheck; e.g., yum install --nogpgcheck yum-priorities.

Install OSG Repositories

  1. If you are upgrading from OSG 3.1 (or 3.2) to OSG 3.2 (or 3.3), remove the old OSG repository definition files and clean the Yum cache:

    [root@client ~]$ yum clean all
    [root@client ~]$ rpm -e osg-release

    This step ensures that local changes to *.repo files will not block the installation of the new OSG repositories. After this step, *.repo files that have been changed will exist in /etc/yum.repos.d/ with the *.rpmsave extension. After installing the new OSG repositories (the next step) you may want to apply any changes made in the *.rpmsave files to the new *.repo files.

  2. Install the OSG repositories using one of the following methods depending on your EL version:

    1. For EL versions greater than EL5, install the files directly from repo.grid.iu.edu:

      [root@client ~]$ rpm -Uvh URL

      Where URL is one of the following:

      Series EL6 URL (for RHEL 6, CentOS 6, or SL 6) EL7 URL (for RHEL 7, CentOS 7, or SL 7)
      OSG 3.2 https://repo.grid.iu.edu/osg/3.2/osg-3.2-el6-release-latest.rpm N/A
      OSG 3.3 https://repo.grid.iu.edu/osg/3.3/osg-3.3-el6-release-latest.rpm https://repo.grid.iu.edu/osg/3.3/osg-3.3-el7-release-latest.rpm
    2. For EL5, download the repo file and install it using the following:

      [root@client ~]$ curl -O https://repo.grid.iu.edu/osg/3.2/osg-3.2-el5-release-latest.rpm
      [root@client ~]$ rpm -Uvh osg-3.2-el5-release-latest.rpm

For more details, please see our yum repository documentation.

Install the CA Certificates: A quick guide

You must perform one of the following yum commands below to select this host's CA certificates.

Set of CAs CA certs name Installation command (as root)
OSG osg-ca-certs yum install osg-ca-certs Recommended
IGTF igtf-ca-certs yum install igtf-ca-certs
None* empty-ca-certs yum install empty-ca-certs --enablerepo=osg-empty
Any** Any yum install osg-ca-scripts

* The empty-ca-certs RPM indicates you will be manually installing the CA certificates on the node.
** The osg-ca-scripts RPM provides a cron script that automatically downloads CA updates, and requires further configuration.

HELP NOTE
If you use options 1 or 2, then you will need to run "yum update" in order to get the latest version of CAs when they are released. With option 4 a cron service is provided which will always download the updated CA package for you.

HELP NOTE
If you use services like Apache's httpd you must restart them after each update of the CA certificates, otherwise they will continue to use the old version of the CA certificates.
For more details and options, please see our CA certificates documentation.

5.1 Install the Client

  1. Install the osg-client meta package, which will pull in all dependencies.
    [root@client ~]$ yum install osg-client   

The client requires no special configuration. To configure fetch-crl, e.g. to use a proxy, check the CRL documentation.

5.2 Install HTCondor-G

Optionally, you may want to install HTCondor-G, too. HTCondor-G is needed to submit jobs directly to the OSG sites. It is not needed for Glidein-based submission.

  1. Install the osg-client-condor meta package, which will pull in all dependencies.
    [root@client ~]$ yum install osg-client-condor   

6 Services

The client is a collection of client programs that do not require service startup or shutdown. The only services are osg-update-certs that keeps uptodate the CA certificates, fetch-crl that keeps uptodate the CRLs and the optional HTCondor-G, only if you installed it.

HELP NOTE
Avoid to interfere with the system HTCondor. The commands below may start/stop/... also a HTCondor installed outside of the client installation. Be aware of which one you are controlling.

6.1 Starting and Enabling Services

To start the services:
  1. You need to fetch the latest CA Certificate Revocation Lists (CRLs) and you should enable the fetch-crl service to keep the CRLs up to date:
    # For RHEL 5, CentOS 5, and SL5 
    [root@client ~]$ /usr/sbin/fetch-crl3   # This fetches the CRLs 
    [root@client ~]$ /sbin/service fetch-crl3-boot start
    [root@client ~]$ /sbin/service fetch-crl3-cron start
    # For RHEL 6, CentOS 6, and SL6, or OSG 3 _older_ than 3.1.15 
    [root@client ~]$ /usr/sbin/fetch-crl   # This fetches the CRLs 
    [root@client ~]$ /sbin/service fetch-crl-boot start
    [root@client ~]$ /sbin/service fetch-crl-cron start
    # For RHEL 7, CentOS 7, and SL7 
    [root@client ~]$ /usr/sbin/fetch-crl   # This fetches the CRLs 
    [root@client ~]$ systemctl start fetch-crl-boot
    [root@client ~]$ systemctl start fetch-crl-cron
    
    For more details and options, please see our CRL documentation.
  2. Optionally, to start HTCondor you can use the service command, e.g.:
    [root@client ~]$ /sbin/service condor start
    

You should also enable the appropriate services so that they are automatically started when your system is powered on:

  • To enable the fetch-crl service to keep the CRLs up to date after reboots:
    # For RHEL 5, CentOS 5, and SL5 
    [root@client ~]$ /sbin/chkconfig fetch-crl3-boot on
    [root@client ~]$ /sbin/chkconfig fetch-crl3-cron on
    # For RHEL 6, CentOS 6, and SL6, or OSG 3 _older_ than 3.1.15 
    [root@client ~]$ /sbin/chkconfig fetch-crl-boot on
    [root@client ~]$ /sbin/chkconfig fetch-crl-cron on
    # For RHEL 7, CentOS 7, and SL7 
    [root@client ~]$ systemctl enable fetch-crl-boot
    [root@client ~]$ systemctl enable fetch-crl-cron
    
  • Optionally, to enable HTCondor by default on the node:
    [root@client ~]$ /sbin/chkconfig condor on
    

6.2 Stopping and Disabling Services

To stop the services:
  1. To stop fetch-crl:
    # For RHEL 5, CentOS 5, and SL5 
    [root@client ~]$ /sbin/service fetch-crl3-boot stop
    [root@client ~]$ /sbin/service fetch-crl3-cron stop
    # For RHEL 6, CentOS 6, and SL6, or OSG 3 _older_ than 3.1.15 
    [root@client ~]$ /sbin/service fetch-crl-boot stop
    [root@client ~]$ /sbin/service fetch-crl-cron stop
    # For RHEL 7, CentOS 7, and SL7 
    [root@client ~]$ systemctl stop fetch-crl-boot
    [root@client ~]$ systemctl stop fetch-crl-cron
    
    For more details and options, please see our CRL documentation.
  2. Optionally, to stop HTCondor you can use:
    [root@client ~]$ /sbin/service condor stop
    

In addition, you can disable services by running the following commands. However, you don't need to do this normally.

  • To disable the fetch-crl service:
    # For RHEL 5, CentOS 5, and SL5 
    [root@client ~]$ /sbin/chkconfig fetch-crl3-boot off
    [root@client ~]$ /sbin/chkconfig fetch-crl3-cron off
    # For RHEL 6, CentOS 6, and SL6, or OSG 3 _older_ than 3.1.15 
    [root@client ~]$ /sbin/chkconfig fetch-crl-boot off
    [root@client ~]$ /sbin/chkconfig fetch-crl-cron off
    # For RHEL 7, CentOS 7, and SL7 
    [root@client ~]$ systemctl disable fetch-crl-boot
    [root@client ~]$ systemctl disable fetch-crl-cron
    
  • Optionally, to disable HTCondor:
    [root@client ~]$ /sbin/chkconfig condor off
    

7 Firewall Considerations

The Globus Toolkit and HTCondor require the client host to allow some inbound and outbound network connections to specific ports. This section describes what additional configuration steps have to be taken if the client host is located behind a firewall. For a more detailed description on firewalls consult this document.

The ranges that you choose below in the Globus and HTCondor configuration must be consistent with the firewall configuration. If the Globus and HTCondor ranges overlap there won't be port collisions but you will need a bigger range.

7.1 Public IP Address and DNS

If you use the the client host as HTCondor-G submit host for long running jobs, it needs to be reached by remote resources. The easier option is to use a public IP address and not be be located within a private network. For other options check below. To make sure that the client host uses a public IP address and is assigned a fully qualified domain name, use:

[user@client ~]$ hostname -f
client.opensciencegrid.org
[user@client ~]$ nslookup client.opensciencegrid.org
Server:		131.215.125.1
Address:	131.215.125.1#53

Name:           client.opensciencegrid.org
Address:        131.215.114.49

If the client host is not assigned a fully qualified domain name, you can assign the public IP address to the GLOBUS_HOSTNAME environment variable:

[root@client ~]$ cat << CFG >> /etc/profile.d/globus_hostname.sh
export GLOBUS_HOSTNAME=131.215.114.49
CFG
[root@client ~]$ cat << CFG >> /etc/profile.d/globus_hostname.csh
setenv GLOBUS_HOSTNAME 131.215.114.49
CFG

Make sure to re-login after you update /etc/profile.d so that the changes take effect.

7.2 Configuring the firewall and NAT

If the client host is on a private network with NAT or anyway behind a firewall, even a host firewall, the firewall and eventual NAT must be configured correctly.

Assuming you use iptables and chose the port range 20k-25k, you must

Insert the following rules

-A RH-Firewall-1-INPUT  -m state --state NEW -p tcp -m tcp --dport 20000:24999 -j ACCEPT
-A RH-Firewall-1-INPUT  -m state --state NEW -p udp -m udp --dport 20000:24999 -j ACCEPT
into /etc/sysconfig/iptables and
Restart iptables with
[root@client ~]$ service iptables restart

HELP NOTE
It is possible to use a client host that is located inside a private network using Network Address Translation. In this case the gatekeeper must be configured to forward incoming connections to the client host. The $GLOBUS_HOSTNAME environment variable must be set to the gatekeeper address. This procedure is currently not documented.

7.3 Globus Port Range

GRAM can be configured to only use a specified range of TCP ports on the client host for inbound ($GLOBUS_TCP_PORT_RANGE) and outbound ($GLOBUS_TCP_SOURCE_RANGE) connections. More information can be found in the Globus firewall HowTo.

[root@client ~]$ cat << CFG >> /etc/profile.d/globus_firewall.sh
export GLOBUS_TCP_PORT_RANGE=20000,24999
export GLOBUS_TCP_SOURCE_RANGE=20000,24999
CFG
[root@client ~]$ cat << CFG >> /etc/profile.d/globus_firewall.csh
setenv GLOBUS_TCP_PORT_RANGE 20000,24999
setenv GLOBUS_TCP_SOURCE_RANGE 20000,24999
CFG

Make sure to re-login after you update /etc/profile.d so that the changes take effect.

7.4 HTCondor Port Range

HTCondor-G requires a set of ports open in order to talk to OSG CEs. If you are running a restrictive firewall, you will need to open O(1k) ports in the firewall and tell HTCondor what port range you opened.

HTCondor will only use a specified range of TCP ports for inbound and outbound connections on the client host. This range requires both inbound and outbound connectivity (there are not 2 separate ranges like in the Globus configuration). You can select this range by defining LOWPORT and HIGHPORT in the configuration:

Create /etc/condor/config.d/10firewall_condor.config and add

LOWPORT=20000
HIGHPORT=24999
to the file and
Restart HTCondor with
[root@client ~]$ service condor restart

8 Test the Client

This document does not cover the usage of the client tools. An introduction how to use the OSG can be found here. A more detailed description how to interact with a Compute Element is located here.

To simply test the functionality of your installation:

9 Getting Help

To get assistance please use this Help Procedure.

10 References

The OSG Client includes also a set of tools that are part of the Internet2 Network Performance Toolkit

Client installation documents:

Some components of OSG Client:

11 Comments

Topic revision: r57 - 06 Dec 2016 - 18:12:42 - KyleGross
Hello, TWikiGuest!
Register

 
TWIKI.NET

TWiki | Report Bugs | Privacy Policy

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..