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.

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.

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.

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.

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:

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

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.

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.

Create a text file in the directory /etc/yum.repos.dwith the name “teradata-ttu.repo” containing the following text (depending on the TTU version used):

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.

Install a specific Teradata package using yum.

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

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):

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 “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:

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

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

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

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.

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

Digital signing of the repository.

Installing and Managing an HTTP server with Apache.

Installing and Managing an anonymous FTP server.

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:

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.

Network proxy information may need to be enabled or configured on this machine, or

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.

python-gpgme,

python-urlgrabber, 3.0.0, or greater,

python-sqlite2,

rpm-python, 4.4.2.2 or greater

yum-metadata-parser, 1.1.2 or greater, (use option --nodeps),

yum, version 3.2.20, or greater,

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.

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.xmlVER="1400" #Add this so we can create it with a version #

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.

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.

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.