Using YUM to manage Teradata Client Software.

Tools
Tools covers the tools and utilities you use to work with Teradata and its supporting ecosystem. You'll find information on everything from the Teradata Eclipse plug-in to load/extract tools.

Using YUM to manage Teradata Client Software.

“Yum” is a package-management utility for RPM-compatible Linux operating systems that can be utilized by the Teradata Client packaging to allow an administrator to manage a repository of packages for network installation and software distribution.  “YUM” stands for “Yellowdog Updater, Modified” and is an open-source, command-line product included with RedHat Enterprise Linux, and Fedora Linux.    This document will explain how to set up a simple Yum repository with the Linux Teradata Client packages, and how to use the resulting repositories to install packages across the network.

Synopsis

To utilize Yum within a single environment, two things must be set up:  1: a server capable of storing the Teradata Client Utility Linux packages (.rpm files), and 2: a client machine with a Yum repository file added, or to specify the URL or file location of the server from which to download the packages.

The server can share the package directories in several ways: via an NFS mount, an FTP link, or with an HTTP server. Administrators may prefer the HTTP server for ease of use, as only a read-only method is needed; setting up an NFS mount can be challenging, as well as an FTP server, depending on the environment. 

The client machine(s) then need to have a single text file added to /etc/yum.repos.d, containing a “baseurl” or path to the server or directory location where the packages reside.  Executing the command “yum install <packagename>” as root on the server will then install the package, including all of the dependencies.  On some servers, if a Teradata Client utility is executed that is not installed, the system will offer to install the program from the repository. SUSE and Fedora do have a GUI package manager that will accept a URL to the path, and do not need to have the .repo file created.  This is covered later in the document.

Server Setup

Setup a Linux Server from which to share the packages.

  1. For the HTTP service, install the Apache web server (2.2 or higher suggested) on the server.  If Yum is available on the server, and the machine has internet access, the command “yum install httpd” should install Apache.  If not, the Apache web server can be found here: http://httpd.apache.org/ .  Directions on how to install and manage Apache are not a topic of this document.
  2. Verify that the web server is active by entering the IP address of the server into a web browser: http://153.64.135.91 for example.  A screen should show on the browser indicating that the web server is installed and running.  Note: Linux isn’t necessary for the web server; however, Step #4 requires Yum/Linux to create the repository information.  This can be created in a separate location and copied with the package files and directories.
  3. Create a directory on the server, and copy the Linux packages from the TTU media to that directory.   The location doesn’t matter, as long as it is readable and writeable by root.

    Example: For the TTU 14.00 Foundation media, i386/x8664 packages, from the root directory of the media :

    # cp –R Linux/i386-x8664 /home/<destinationdir>

    For the TTU 13.10 and earlier media:

    # cp –R Linux /home/<destinationdir> 

    TTU 13.10 and 13.0 media contain both i386 and s390x packages.  To prevent confusion with the packages for i386, remove the s390x rpm files with the following command in the /home/<destinationdir> directory.

    # find . -type f -name "*s390*.rpm" -exec rm -f {} \;

    To remove i386 files (if an s390x repository is desired) run the command twice, replacing “s390” with “i386” and “noarch” instead in the above command.

    If copying from TTU1400 media, the destination directory will contain a directory called “i386-x8664”.   This directory will contain product directories with a single RPM file for each product in each directory.

    # ls -l
    drwxr-xr-x. 2 root root 4096 May 17 17:23 bteq
    drwxr-xr-x. 2 root root 4096 May 17 17:23 cliv2
    drwxr-xr-x. 2 root root 4096 May 17 17:23 fastexp

    drwxr-xr-x. 2 root root 4096 May 17 17:23 TeraGSS
    drwxr-xr-x. 2 root root 4096 May 17 17:23 tpump

    # ls -l bteq
    -rwxr-xr-x. 1 root root 180258 May 17 17:23 bteq-14.00.00.00-1.i386.rpm

  4. Execute the “createrepo” command to create the Yum repository files.   In the directory containing the product subdirectories, execute the following command, with the following parameters: “.” specifies the current directory, and “-v” stands for “verbose”.   The output should be similar:
    # createrepo . –v 

    1/14 - tdicu/tdicu-14.00.00.00-1.noarch.rpm
    2/14 - fastexp/fastexp-14.00.00.00-1.i386.rpm

    13/14 - piom/piom-14.00.00.00-1.noarch.rpm
    14/14 - npaxsmod/npaxsmod-14.00.00.00-1.i386.rpm

    Saving Primary metadata
    Saving file lists metadata
    Saving other metadata

    The output shows the packaging files that are included in the repository files, and creates a directory “repodata” containing 4 files:

    # ls -l repodata

    total 24
    -rw-r--r--. 1 root root 3886 May 18 16:22 primary.xml.gz
    -rw-r--r--. 1 root root 3811 May 18 16:22 filelists.xml.gz
    -rw-r--r--. 1 root root 941 May 18 16:22 other.xml.gz
    -rw-r--r--. 1 root root 1357 May 18 16:22 repomd.xml

    These files are extremely small, and three of the files are usually compressed.

    # createrepo . –v 

    1/14 - tdicu/tdicu-14.00.00.00-1.noarch.rpm
    2/14 - fastexp/fastexp-14.00.00.00-1.i386.rpm

    13/14 - piom/piom-14.00.00.00-1.noarch.rpm
    14/14 - npaxsmod/npaxsmod-14.00.00.00-1.i386.rpm

    Saving Primary metadata
    Saving file lists metadata
    Saving other metadata

    The output shows the packaging files that are included in the repository files, and creates a directory “repodata” containing 4 files:

    # ls -l repodata

    total 24
    -rw-r--r--. 1 root root 3886 May 18 16:22 primary.xml.gz
    -rw-r--r--. 1 root root 3811 May 18 16:22 filelists.xml.gz
    -rw-r--r--. 1 root root 941 May 18 16:22 other.xml.gz
    -rw-r--r--. 1 root root 1357 May 18 16:22 repomd.xml

    These files are extremely small, and three of the files are usually compressed.

  5. Soft link this directory to the directory to be shared by the Apache web server, or copy the directory to this location. The Apache web server, by default, serves the pages located in /var/www/html.  Create a softlink in this directory that points to the directory containing the package files.  The package files can be copied to /var/www/html, but if the disk volume on /var gets full, it may be better to locate the package files elsewhere.  Create a directory in /var/www/html, and create a softlink in that directory that point to the location where the packages are.  This creates a softlink to a directory that is shared as “teradata/i386” on the web server.

    # mkdir –p /var/www/html/teradata
    # ln –s /home/<destinationdir>/Linux/i386-x8664 /var/www/html/teradata/

  6.  Verify the directory by entering the IP address of the machine into a local web browser (Microsoft Internet Explorer®, FireFox or Chrome, etc.):

    http://153.64.135.91/teradata/i386

    The directory should display on a browser similar to the following illustration.

    Verify that the “repodata” subdirectory exists in the list, contains the four .xml/.xml.gz files, and is accessible, as well as the other Teradata packages in each products subdirectory.  If the path to the subdirectory isn’t available from a web browser, in this case http://153.64.135.91/teradata/i386, Yum will be unable to install the packages on the client machine.

Client Side

To enable a client to connect to the Teradata repository using Yum, the following steps must be taken.

  1. Create a text file in the directory /etc/yum.repos.d with the nameteradata-ttu.repocontaining the following text (depending on the TTU version used):
    [teradata-ttu]
    name=Teradata TTU
    baseurl=http://153.64.135.91/teradata/client/1400/i386
    enabled=1
    gpgcheck=0
    • The name of the file isn’t important, as long as the file ends in “.repo”.   It should be descriptive of what the repository contains, however.
    • The “baseurl” should be the URL that contains the directory “repodata” as well as the package subdirectories.  
    • If the baseurl is a directory located on an NFS mount, or a local directory, the following can be used: “baseurl=file:///home/<destinationdir>/” (Use three (3) /’s after “file:”).  An FTP server can also be used; “baseurl=ftp://153.64.135.91/pub/Server”, if an anonymous FTP server is installed at that location.
    • The line “enabled” allows this repository to be enabled or disabled.  It can easily be disabled by setting this value to “0” without removing the repository file.
    • Yum can validate the digital signature (GPG) information of a .repo file, if it is setup on the server.  For now leave “gpgcheck=0” to disable this check.
  2. Install a specific Teradata package using yum.

    Test installing a Teradata Client package with the following command.  The output should be similar:

# yum install fastld

Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package fastld.i386 0:14.00.00.00-1 set to be installed
--> Processing Dependency: libtdusr.so for package: fastld-14.00.00.00-1.i386
--> Processing Dependency: libpm.so for package: fastld-14.00.00.00-1.i386
--> Processing Dependency: libcliv2.so for package: fastld-14.00.00.00-1.i386
--> Running transaction check
---> Package cliv2.noarch 0:14.00.00.00-1 set to be installed
--> Processing Dependency: tdicu for package: cliv2-14.00.00.00-1.noarch
--> Processing Dependency: TeraGSS_redhatlinux-i386 for package: cliv2-14.00.00.00-1.noarch
---> Package piom.noarch 0:14.00.00.00-1 set to be installed
--> Running transaction check
---> Package TeraGSS_redhatlinux-i386.i386 0:14.00.00.00-1 set to be installed
---> Package tdicu.noarch 0:14.00.00.00-1 set to be installed
--> Finished Dependency Resolution

Dependencies Resolved

===============================================================================
Package Arch Version Repository Size
===============================================================================
Installing:
fastld i386 14.00.00.00-1 teradata-ttu 126 k
Installing for dependencies:
TeraGSS_redhatlinux-i386 i386 14.00.00.00-1 teradata-ttu 7.6 M
cliv2 noarch 14.00.00.00-1 teradata-ttu 394 k
piom noarch 14.00.00.00-1 teradata-ttu 145 k
tdicu noarch 14.00.00.00-1 teradata-ttu 8.6 M

Transaction Summary
===============================================================================
Install 5 Package(s)

Total download size: 17 M
Installed size: 49 M
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 17 M
(1/5): TeraGSS_redhatlinux-i386-14.00.00.00-1.i386.rpm | 7.6 MB 00:04
(2/5): cliv2-14.00.00.00-1.noarch.rpm | 394 kB 00:00
(3/5): fastld-14.00.00.00-1.i386.rpm | 126 kB 00:00
(4/5): piom-14.00.00.00-1.noarch.rpm | 145 kB 00:00
(5/5): tdicu-14.00.00.00-1.noarch.rpm | 8.6 MB 00:05
-------------------------------------------------------------------------------
Total 1.4 MB/s | 17 MB 00:11
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Warning: RPMDB altered outside of yum.
Installing : TeraGSS_redhatlinux-i386-14.00.00.00-1.i386 1/5
Installing : tdicu-14.00.00.00-1.noarch 2/5
Adding TD_ICU_DATA environment variable to /etc/profile file.
Adding TD_ICU_DATA environment variable to /etc/csh.login file.
Installing : cliv2-14.00.00.00-1.noarch 3/5
Adding cliv2 COPLIB environment variable to /etc/profile file.
Adding cliv2 COPERR environment variable to /etc/profile file.
Adding tdmst entry to /etc/services file.
Installing : piom-14.00.00.00-1.noarch 4/5
Installing : fastld-14.00.00.00-1.i386 5/5

Installed:
fastld.i386 0:14.00.00.00-1

Dependency Installed:
TeraGSS_redhatlinux-i386.i386 0:14.00.00.00-1 cliv2.noarch 0:14.00.00.00-1
piom.noarch 0:14.00.00.00-1 tdicu.noarch 0:14.00.00.00-1

Complete!

The FastLoad utility is now installed on this system, as well as the products that FastLoad depends on (TeraGSS, TDICU, CLIv2 and PIOM).  If a product that isn’t currently installed is attempted to be executed as root, the product may automatically be installed (depending on the setup or distribution):

# mload
bash: mload: command not found...
Install package 'mload' to provide command 'mload'? [N/y] y
* Running..
* Resolving dependencies..
The following packages have to be installed:
tdicu-14.00.00.00-1.noarch Shared common components for Internationalization for Teradata
cliv2-14.00.00.00-1.noarch Teradata CLIV2 Library
piom-14.00.00.00-1.noarch Teradata Data Connector Access Module API
TeraGSS_redhatlinux-i386-14.00.00.00-1.i386 Teradata GSS client package
Proceed with changes? [N/y] y
* Waiting in queue..
* Resolving dependencies..
* Downloading packages..
* Testing changes..
* Installing packages..
* Scanning applications..
* Getting information..
========================================================================
= =
= MultiLoad Utility Release MLOD.14.00.00.000 =
= Platform LINUX =
= =
========================================================================
= =
= Copyright 1990-2011 Teradata Corporation. ALL RIGHTS RESERVED. =
= =
========================================================================

Yum can also be used to check what packages are available on the repository, and show which packages are installed:

# yum list | grep teradata-ttu
TeraGSS_redhatlinux-i386.i386 14.00.00.00-1 @teradata-ttu
cliv2.noarch 14.00.00.00-1 @teradata-ttu
mload.i386 14.00.00.00-1 @teradata-ttu
piom.noarch 14.00.00.00-1 @teradata-ttu
tdicu.noarch 14.00.00.00-1 @teradata-ttu
bteq.i386 14.00.00.00-1 teradata-ttu
fastexp.i386 14.00.00.00-1 teradata-ttu
fastld.i386 14.00.00.00-1 teradata-ttu
mqaxsmod.i386 14.00.00.00-1 teradata-ttu
npaxsmod.i386 14.00.00.00-1 teradata-ttu
sqlpp.noarch 14.00.00.00-1 teradata-ttu
tdodbc.noarch 14.00.00.00-1 teradata-ttu
tpump.i386 14.00.00.00-1 teradata-ttu

The @ sign in front of “teradata-ttu” signifies that the package is installed on this system.  If the parameter to “list” is a package name, it will display that single package.

The dependencies of a package can be displayed with the following command:

# yum deplist cliv2

Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
Finding dependencies:
package: cliv2.noarch 14.00.00.00-1
dependency: tdicu
provider: tdicu.noarch 14.00.00.00-1
dependency: /bin/sh
provider: bash.i686 4.1.7-3.fc14
dependency: TeraGSS_redhatlinux-i386
provider: TeraGSS_redhatlinux-i386.i386 14.00.00.00-1

Advanced Topics

Groups

A group file can be created on the server machine, before creating the “repodata” information that will combine all of the packages into a single group for ease of install.  To do this, the file “comps.xml” must be created in the directory containing the package subdirectories before executing “createrepo”.  This can enable an administrator to execute a single yum command which will install all of the packages defined in a group rather then requiring the installation of each package individually.

The comps.xml file should look similar to the following:

<group>
<id>teradata-1400</id>
<name>Teradata Client TTU 1400</name>
<default>true</default>
<uservisible>true</uservisible>

<description>This is a TTU 1400 group.</description>
<packagelist>
<packagereq type="optional">bteq</packagereq>
<packagereq type="mandatory">cliv2</packagereq>
<packagereq type="optional">fastexp</packagereq>
<packagereq type="optional">fastld</packagereq>
<packagereq type="optional">mload</packagereq>
<packagereq type="optional">npaxsmod</packagereq>
<packagereq type="default">piom</packagereq>
<packagereq type="optional">sqlpp</packagereq>
<packagereq type="mandatory">tdicu</packagereq>
<packagereq type="optional">tdodbc</packagereq>
<packagereq type="mandatory">TeraGSS</packagereq>
<packagereq type="optional">tpump</packagereq>
</packagelist>
</group>
  • The “id” value is the name of the group that will be used by yum as the groupname.  In this case we’re going to use packages from TTU 14.00, and we’ll call it “teradata-1400”.
  • The text in “name” is what will display when yum displays the information about the group on the client machine.
  • The package list should contain the name of the packages in the directory; TeraGSS, tdicu, cliv2, etc.  There are three types of “packagereq” values:
    1. mandatory”: These packages will be installed if any packages of the group are to be installed.  Use for dependencies such as TeraGSS, tdicu, cliv2, piom, or tptbase  packages.
    2. default”: These packages can be unselected and not installed during the install process, but are installed by default. In this case “piom” which is used by BTEQ.
    3. optional”: These packages are not installed by default, but will show up in the yum or package details screen.

The appendix has a simple script that will create a comps.xml file when executed in the directory containing the package directories.  The packages that are not dependent products (bteq, sqlpp, tpump, etc.) can be set as “default” or “optional” before executing the “createrepo” command. When set to “default” they will be installed by default when installing the full group.

After creating/modifying comps.xml, execute the createrepo script as follows:

# createrepo . –v –g comps.xml

This will create the repodata subdirectory (if it doesn’t exist), which will contain the group files “comps.xml” as well as “comps.xml.gz”.

On the client side  the group install can be executed with Yum.  In the following example, the package group is called “teradata-1400” from the comps.xml file above.

# yum groupinfo teradata-1400
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
Setting up Group Process

Group: Teradata Client TTU 1400
Description: This is a TTU 1400 group.
Mandatory Packages:
TeraGSS
cliv2
tdicu
Default Packages:
piom
Optional Packages:
bteq
fastexp
fastld
mload
npaxsmod
sqlpp
tdodbc
tpump

If certain packages should always be installed, but are not dependencies, set those as “default” in the comps.xml file.  The dependency packages (TeraGSS, tdicu, cliv2) should always be mandatory, though they will be installed if a product dependent on them is installed.

# yum groupinstall teradata-1400
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
fedora/primary_db | 11 MB 00:25
teradata-ttu 15/15
Setting up Group Process
Resolving Dependencies
--> Running transaction check
---> Package cliv2.noarch 0:14.00.00.00-1 set to be installed
---> Package piom.noarch 0:14.00.00.00-1 set to be installed
---> Package tdicu.noarch 0:14.00.00.00-1 set to be installed
--> Finished Dependency Resolution

Dependencies Resolved

=========================================================================================
Package Arch Version Repository Size
=========================================================================================
Installing:
cliv2 noarch 14.00.00.00-1 teradata-1400 405 k
piom noarch 14.00.00.00-1 teradata-1400 69 k
tdicu noarch 14.00.00.00-1 teradata-1400 7.5 M

Transaction Summary
=========================================================================================
Install 3 Package(s)

Total download size: 7.9 M
Installed size: 22 M
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 7.9 M
(1/3): cliv2-14.00.00.02-1.noarch.rpm | 405 kB 00:00
(2/3): piom-14.00.00.02-1.noarch.rpm | 69 kB 00:00
(3/3): tdicu-14.00.00.02-1.noarch.rpm | 7.5 MB 00:05
-----------------------------------------------------------------------------------------
Total 1.3 MB/s | 7.9 MB 00:06
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : tdicu-14.00.00.00-1.noarch 1/3
Adding TD_ICU_DATA environment variable to /etc/profile file.
Adding TD_ICU_DATA environment variable to /etc/csh.login file.
Installing : cliv2-14.00.00.00-1.noarch 2/3
Adding cliv2 COPLIB environment variable to /etc/profile file.
Adding cliv2 COPERR environment variable to /etc/profile file.
Adding tdmst entry to /etc/services file.
Installing : piom-14.00.00.00-1.noarch 3/3

Installed:
cliv2.noarch 0:14.00.00.00-1 piom.noarch 0:14.00.00.00-1
tdicu.noarch 0:14.00.00.00-1

Complete!

The packages can also all be removed as a group as follows:

# yum groupremove teradata-1400
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
Setting up Group Process
Resolving Dependencies
--> Running transaction check
---> Package cliv2.noarch 0:14.00.00.00-1 set to be erased
---> Package piom.noarch 0:14.00.00.00-1 set to be erased
---> Package tdicu.noarch 0:14.00.00.00-1 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

=========================================================================================
Package Arch Version Repository Size
=========================================================================================
Removing:
cliv2 noarch 14.00.00.00-1 @teradata-1400 1.2 M
piom noarch 14.00.00.00-1 @teradata-1400 199 k
tdicu noarch 14.00.00.00-1 @teradata-1400 21 M

Transaction Summary
=========================================================================================
Remove 3 Package(s)

Installed size: 22 M
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Erasing : cliv2-14.00.00.00-1.noarch 1/3
Erasing : tdicu-14.00.00.00-1.noarch 2/3
Executing post-uninstall script../...
Removing COPLIB/COPERR from /etc/profile if cliv2.
Removing CLI tdmst entry from /etc/services
Erasing : piom-14.00.00.00-1.noarch 3/3

Removed:
cliv2.noarch 0:14.00.00.00-1 piom.noarch 0:14.00.00.00-1
tdicu.noarch 0:14.00.00.00-1

Complete!

Updating Packages

Packages can be updated when a new package is available.  Place the updated package into the same directory as the previous version; execute createrepo on the server system to recreate the repository information, and execute “yum update” on the client system.    To ensure that the updates are found, execute “yum clean metadata” before “yum check update”  to clear the cache on the client system.

To update a single package use the command “yum update <package>” where <package> is the name of a package.  To update a group use the command “yum groupudate <groupid>” where the groupid is the ID of  a group used in comps.xml such as “teradata-1400”.  Recreate the comps.xml file if necessary.

Additional Advanced Topics not Covered

  1. Digital signing of the repository.
  2. Installing and Managing an HTTP server with Apache.
  3. Installing and Managing an anonymous FTP server.
  4. Managing an NFS mount.

Tips

  • If a repository has been updated, but a client machine is not seeing the changes to the repodata information, the yum cache can be cleared by executing “yum clean all”.
  • If executing yum within the Teradata Network environment or within some corporate internet firewalls, and the installer is unable to find the addresses of system mirrors to update packages, several things can be done to remedy this situation:
    1. Log into the corporate internet with Firefox on the client machine so that the machine is allowed access to the internet.  This may allow the proxy to allow that machine to connect to the internet.
    2. Network proxy information may need to be enabled or configured on this machine, or
    3. Modify the .repo files in /etc/yum.repos.d to set “enabled=0” for all files that access the internet.  This will disallow library dependency updating, as well as automatic updating of the client system, but will allow Yum to update just the Teradata package files.  This can be useful within a corporate network if external internet access is blocked. 
  • Keep Teradata TTU products, and major upgrades, in directories with the same major TTU version numbers.  TTU 13.00, TTU 13.10, and TTU 14.00 packages should be located with the same sets of packages in the server directories. 
  • A customer could maintain an internal repository of TTU .rpm package files, and update with efix packages as needed.  A check of the repository for update packages can be made on the client system (cron), and updates could automatically be provided as needed.  A Professional Services Consultant could also setup a single repository to manage software installs across hundreds of Linux clients, updating clients with specific versions of software packages on production machines, while allowing fresh updates only to machines that are test machines.
  • If attempting to use Yum with older versions of Fedora (8, 9), an error message may display for “primary.xml.gz”, “Error -3: Error checksum”.  This occurs because the version of Python needs to be updated on the client system.  See the following link for more info: http://skvidal.wordpress.com/2009/02/19/yum-createrepo-hashlib-rhel5centos5-and-sha256sums/.  Updating the version of Yum to 3.2.20 may also resolve these issues.  It is recommended not to use versions of Linux that are outdated or unsupported.
  • The versions of the packages displayed are for demonstration purposes only, and may show version numbers that aren’t currently available as customer versions of those packages.  Actual version numbers may vary.

Installing using YaST on SUSE

Using YaST on SUSE simplifies package installation as demonstrated in the following screen captures. The RedHat/Fedora GUI functions similarly in the “Software Updater” or “PackageKit”, see “Add/Remove Software”.

1:  First execute YaST on the client system.  Root access will be needed:

2: Select “Software” under “Groups” to display the Software icons (shown on the right).

3: Select “Software Repositories” and click the “Add” button in the bottom left:

4: Select the “Media Type”, in this case HTTP, and click “Next”.

5: Enter a Repository Name, the URL/Path and click Next. (In this example a local server "linux-cmi" is being used.)

6: Find the newly created Repository in the Repository list, ensure that it is “Enabled”, and click “OK”.

7: YaST will refresh the repository database, and may display a warning message that the repository isn’t signed.  If this is a newly created repository, just click “Yes” to use it.

8: In the YaST control panel select “Software Management” (see Step #2). In the Find field, type “teradata”.  A list of the available Teradata Client packages and dependencies will display.  Select the desired packages to install and click “Apply”.

9: A summary of the packages to be installed will be displayed. Click “Apply” to install.

10: The packages will install. When the installation finishes, the products will then be available in a Terminal window.

Required Packages for Yum:

The following packages are required if installing Yum on a system without Yum currently installed.

  1. python-gpgme,
  2. python-urlgrabber, 3.0.0, or greater,
  3. python-sqlite2,
  4. rpm-python, 4.4.2.2 or greater
  5. yum-metadata-parser, 1.1.2 or greater, (use option --nodeps),
  6. yum,  version 3.2.20, or greater,
  7. createrepo, version 0.4.9, or greater, for creating the repository.  (server only)

Required Linux OS and Version

Linux RedHat Enterprise Linux/CentOS – version 5, 6

Fedora Linux – versions 8-14.  Use Yum, or the GUI Software administration interface. If using versions prior to 10, be sure and update the system files so that python and other dependency applications will have the latest version for that distribution.  It isn't recommended to use Linux distributions that are no longer supported.

SUSE Linux/openSUSE– versions 10.0-11.4.  Install packages from the Yum repository using YaST rather than installing Yum.  Add the URL for the repository to the Software Repository list, and use the GUI program to select and Teradata Client packages.  Allow the system to update dependencies.

Ubuntu, Debian – These distributions are not currently supported platforms for Teradata Client products, and may not install .rpm package files.

FAQs

Q: Can I use Yum repositories to distribute other software other than TTU Client products?

A: Certainly! It's recommended though, that for typical Linux system software or for software already distributed through a distribution mirror archive to allow the system to find packages and install from there.  If a Linux client is within a firewall, however, and doesn't have access to an official mirror a repository can be set up to allow updates or installs for specific packages. 

Q: Can I use Yum repositories to distribute or patch Teradata DBS packages?

A: Yum repositories could be used to distribute any RPM packages. However, the Teradata Database packages may have specific versions of packages that are intended to be installed together, or depend on specific versions.  A Teradata Professional Services consultant would be better qualified to set up a Yum repository for DBS packages.  It is recommended to leave those packages to Teradata administrators rather than trying to "roll your own".  In the future the DBS may support Yum repositories, but until that point it's better to use it for TTU Client products only.

Q: Is it really as simple as it looks?

A: Yes, it is!  Once a repository is set up, for the GUI installers providing a URL to the path of the repository is all it takes.  See the section above on installing with YaST.

Q: Can I install directly from a TTU Client media DVD using a GUI installer?

A: When installing with the TTU Client media there are scripts that handle installation when executed by "setup.bat".  These are text based scripts, and handle installing prerequesite packages.  Currently there is not a Yum repository on the CD/DVD media for the Linux packages.  That could change in the future, but for now when installing from the TTU Client Media it's recommended to use the "setup.bat" script to install.

Q: Can a Yum repository be set up to distribute the Teradata Client Software rather than distributing media such as DVDs?

A: Technically that is possible, and is currently being investigated.  The are different legal requirements for the distribution of software from the Teradata Patch Server that could be resolved in the future.  For now, it is recommended to only create internal repositories from TTU Client media. 

Q: Will a Yum repository be set up on the Teradata Patch server to distribute efixes?

A: It's possible, and is also being investigated.  For now, a Yum repository can be used to distribute efixes and patches internal to a single customer or within a customer network.

Links

Usage for yum:

http://linux.die.net/man/8/yum

http://prefetch.net/articles/yum.html

http://man.cx/yum(8)

Usage for createrepo:

http://linux.die.net/man/8/createrepo

http://yum.baseurl.org/wiki/RepoCreate

http://createrepo.baseurl.org/

Usage for yum.conf:   

http://linux.die.net/man/5/yum.conf

http://man.cx/yum(5)

Usage for comps.xml file:                 

http://www-oss.fnal.gov/projects/fermilinux/common/comps.xml.html,                

http://www-oss.fnal.gov/projects/fermilinux/common/anaconda.comps.html,

http://ramblings.narrabilis.com/wp/creating-a-yum-repository-repo-and-creating-a-yum-group-to-instal...

Additional Yum info: 

http://yum.baseurl.org/wiki/Faq              

Using PackageKit GUI on Fedora to install

http://docs.fedoraproject.org/en-US/Fedora/14/html/Amateur_Radio_Guide/appe-Installing_Software.html

Appendix

1: comps.sh

This script creates a comps.xml file, looping through the Teradata Client package directories adding each name to the group file.  If it is desired that certain packages always be installed, add them to the same line as “piom” to install as “default”.

#!/bin/sh

OUT=comps.xml
VER="1400" #Add this so we can create it with a version #

if [ -f "$OUT" ]; then
echo "File $OUT exists. Please remove."
exit 1
fi

echo "<group>" >> $OUT
echo " <id>teradata-$VER</id>" >> $OUT
echo " <name>Teradata Client TTU $VER</name>" >> $OUT
echo " <default>true</default>" >> $OUT
echo " <uservisible>true</uservisible>" >> $OUT
echo " " >> $OUT
echo " <description>This is a TTU $VER group.</description>" >> $OUT
echo " <packagelist>" >> $OUT
for DIRNAME in *
do
if [ -d "$DIRNAME" ]; then
case $DIRNAME in
TeraGSS | tdicu | cliv2)
echo " <packagereq type=\"mandatory\">$DIRNAME</packagereq>" >> $OUT
echo "Package: $DIRNAME - mandatory"
;;
piom)
echo " <packagereq type=\"default\">$DIRNAME</packagereq>" >> $OUT
echo "Package: $DIRNAME - default"
;;
repodata)
#Do nothing for this directory as it doesn't contain packages
;;
*)
echo " <packagereq type=\"optional\">$DIRNAME</packagereq>" >> $OUT
echo "Package: $DIRNAME - optional"
;;
esac
fi
done
echo " </packagelist>" >> $OUT
echo "</group>" >> $OUT
5 REPLIES
Enthusiast

Re: Using YUM to manage Teradata Client Software.

Hi Patrick,

I am Abbas and i am Teradata Developer,in my organization we running thru Mainframes,
can you tell me how to configure TERADATA in SUSE or RED HAT linux. i know how to configure in win-xp and i given the post in this site.

So iam requesting that i need to install teradata on linux please give me some screen shots step by step.

and please do the needfull to me.

Thanks and Regards,
Abbas

pabbaskhan@gmail.com

Re: Using YUM to manage Teradata Client Software.

Abbas, the scope of this document is setting up a package repository for Linux, to allow remote installation and patch updates not basic installing of Teradata (Client or DBS) on Linux.

Please look at this URL for the Teradata Tools and Utilities Installation Guides: www.info.teradata.com/templates/eSrchResults.cfm?txtttlkywrd=Teradata Tools and Utilities Installation&txtrelno=&todt=&srtord=Asc&txtpid=&rdsort=Title&prodline=all&frmdt= and find the version of the installation guide that matches the version you are installing.

I hope this helps!
Enthusiast

Re: Using YUM to manage Teradata Client Software.

Thanks patrick and happy new year.

Re: Using YUM to manage Teradata Client Software.

Patrick,

 We tried installing TTU through "YUM" using the steps described above. We are running into an issue with the libraries for Teradata websphere access module.

yum groupinstall teradata-1400

Loaded plugins: product-id, rhnplugin

This system is receiving updates from RHN Classic or RHN Satellite.

Setting up Group Process

Resolving Dependencies

--> Running transaction check

---> Package bteq.i386 0:14.00.00.02-1 will be installed

---> Package cliv2.noarch 0:14.00.00.07-1 will be installed

--> Processing Dependency: TeraGSS_linux_x64 for package: cliv2-14.00.00.07-1.noarch

---> Package fastexp.i386 0:14.00.00.03-1 will be installed

---> Package fastld.i386 0:14.00.00.03-1 will be installed

---> Package jmsaxsmod.i386 0:14.00.00.03-1 will be installed

---> Package mload.i386 0:14.00.00.10-1 will be installed

---> Package mqaxsmod.i386 0:14.00.00.00-1 will be installed

--> Processing Dependency: libmqmcs.so for package: mqaxsmod-14.00.00.00-1.i386

--> Processing Dependency: libmqm.so for package: mqaxsmod-14.00.00.00-1.i386

--> Processing Dependency: libmqic.so for package: mqaxsmod-14.00.00.00-1.i386

---> Package piom.noarch 0:14.00.00.04-1 will be installed

---> Package sqlpp.noarch 0:14.00.00.04-1 will be installed

---> Package tdicu.noarch 0:14.00.00.00-1 will be installed

---> Package tdodbc.noarch 0:14.00.00.04-1 will be installed

---> Package tpump.i386 0:14.00.00.07-1 will be installed

--> Running transaction check

---> Package TeraGSS_linux_x64.noarch 0:14.00.03.02-1 will be installed

---> Package mqaxsmod.i386 0:14.00.00.00-1 will be installed

--> Processing Dependency: libmqmcs.so for package: mqaxsmod-14.00.00.00-1.i386

--> Processing Dependency: libmqm.so for package: mqaxsmod-14.00.00.00-1.i386

--> Processing Dependency: libmqic.so for package: mqaxsmod-14.00.00.00-1.i386

--> Finished Dependency Resolution

Error: Package: mqaxsmod-14.00.00.00-1.i386 (teradata-ttu)

           Requires: libmqm.so

Error: Package: mqaxsmod-14.00.00.00-1.i386 (teradata-ttu)

           Requires: libmqic.so

Error: Package: mqaxsmod-14.00.00.00-1.i386 (teradata-ttu)

           Requires: libmqmcs.so

You could try using --skip-broken to work around the problem

You could try running: rpm -Va --nofiles --nodigestyum groupinstall teradata-1400

Loaded plugins: product-id, rhnplugin

This system is receiving updates from RHN Classic or RHN Satellite.

Setting up Group Process

Resolving Dependencies

--> Running transaction check

---> Package bteq.i386 0:14.00.00.02-1 will be installed

---> Package cliv2.noarch 0:14.00.00.07-1 will be installed

--> Processing Dependency: TeraGSS_linux_x64 for package: cliv2-14.00.00.07-1.noarch

---> Package fastexp.i386 0:14.00.00.03-1 will be installed

---> Package fastld.i386 0:14.00.00.03-1 will be installed

---> Package jmsaxsmod.i386 0:14.00.00.03-1 will be installed

---> Package mload.i386 0:14.00.00.10-1 will be installed

---> Package mqaxsmod.i386 0:14.00.00.00-1 will be installed

--> Processing Dependency: libmqmcs.so for package: mqaxsmod-14.00.00.00-1.i386

--> Processing Dependency: libmqm.so for package: mqaxsmod-14.00.00.00-1.i386

--> Processing Dependency: libmqic.so for package: mqaxsmod-14.00.00.00-1.i386

---> Package piom.noarch 0:14.00.00.04-1 will be installed

---> Package sqlpp.noarch 0:14.00.00.04-1 will be installed

---> Package tdicu.noarch 0:14.00.00.00-1 will be installed

---> Package tdodbc.noarch 0:14.00.00.04-1 will be installed

---> Package tpump.i386 0:14.00.00.07-1 will be installed

--> Running transaction check

---> Package TeraGSS_linux_x64.noarch 0:14.00.03.02-1 will be installed

---> Package mqaxsmod.i386 0:14.00.00.00-1 will be installed

--> Processing Dependency: libmqmcs.so for package: mqaxsmod-14.00.00.00-1.i386

--> Processing Dependency: libmqm.so for package: mqaxsmod-14.00.00.00-1.i386

--> Processing Dependency: libmqic.so for package: mqaxsmod-14.00.00.00-1.i386

--> Finished Dependency Resolution

Error: Package: mqaxsmod-14.00.00.00-1.i386 (teradata-ttu)

           Requires: libmqm.so

Error: Package: mqaxsmod-14.00.00.00-1.i386 (teradata-ttu)

           Requires: libmqic.so

Error: Package: mqaxsmod-14.00.00.00-1.i386 (teradata-ttu)

           Requires: libmqmcs.so

You could try using --skip-broken to work around the problem

You could try running: rpm -Va --nofiles --nodigest

However,  we are able to install all tools manually including Teradata websphere access module  using the TTU package (used for creating repo files) 

Re: Using YUM to manage Teradata Client Software.

Thank you for your input! Yes, for the MQ Access Module, the third party libraries have to be installed or made available. I believe that if they are added to the same repository that Yum will pick up those .rpm files as well.  You may need to add them to the repository list.  Please let me know if this method is useful, and how it is used. For example, for massive deployment, keeping systems up to date, or just for an easier installation method.   It's sort of a thing that was added as a way, in Linux, to make installs easier, but I haven't heard of many customers using this method yet.

- Patrick Palmer