Tivoli Configuration Manager

Tivoli Configuration Manager controls software distribution and asset management inventory in a multi-platform environment. It is designed for configuration, distribution, change, version, and asset management in a distributed computing environment. Working on top of Tivoli Management Framework, Tivoli Configuration Manager provides an integrated solution for managing complex distributed enterprise environments.

Using Tivoli Configuration Manager, you can:

• Package software elements ready for distribution and installation
• Use the integrated inventory database to determine targets for your software distribution
• Create a workflow for the installation process using the activity planner
• Submit and monitor the workflows across the enterprise
• Update the reference model to ensure continued compliance
• Manage your enterprise environment across firewalls without impacting your enterprise security
• Extend the scope of your managed network to include pervasive devices, such as personal digital assistants (PDAs) and intelligent phones
• Automatically distribute and manage security patches and software updates in a Tivoli environment. For more information about the patch management solution, see IBM Tivoli Configuration Manager: Patch Management Guide.

The Software Distribution component comprises the following main elements:

• Software package
• Source host
• Software Package Editor
• Pristine Tool
• Web Interface plug-in

Software package is defined as a file that contains a collection of objects and actions to be performed on a target machine. This file is prepared prior to distribution time. Actions in a software package fall into three separate categories:

Adding and removing objects: This category involves actions that add or remove something from the target system. Examples include adding and removing:

•  Files
• Services
• Registry keys
• Device objects

System actions: Several system actions are currently available for inclusion in software packages. These include:

• Checking for disk space
• Restarting the target system
•  Inventory signature

Program actions: This category includes the execution of a variety of types of programs. A user-defined program may be executed on a target as well as certain platform-specific executables such as:

•   InstallShield programs
•   Microsoft setup programs
•   IBM configuration, installation, and distribution (CID)
•   Solaris: Install Solaris package (Pkgadd and Patchadd)
•   Install AIX package (installp)
•   Install LINUX package (RPM) (RPM)

Software Package Editor

This is a Java-based graphical interface for creating and customizing software packages. Among capabilities:

• Create a new software package.
• Modify an existing software package to create a new one.
• Generate a software package automatically using differencing technologies (Autopack).
• Create a software package containing one of the following third-party native installation packages (
  • Microsoft Systems Management Server package definition file
  • Microsoft Software Installer file
  • AIX package
  • Solaris Operating Environment package
  • RPM package
  • InstallShield
  • Configuration, installation, and distribution programs

You also use the Software Package Editor to arrange actions contained in the software package in the order in which they are to be performed on the target system.

There are two versions of the Software Package Editor:

• Tivoli Software Distribution Endpoint Package Editor. This version is installed on endpoints on which software packages will be created and tested. All functionality is available with this version. A software package file can be saved into any of the three formats using this editor. This is also called the Java Endpoint Package Editor.
• Tivoli Software Distribution Package Editor This version is installed on managed nodes and is primarily used for editing existing software packages. Software package blocks cannot be created or edited with this version. In addition, some functionality is not available with the Software Package Editor installed on managed nodes. Certain tools to automate the creation of software packages (AutoPack) and to make using third-party software easier are not available with this editor.

There are three types of software package files:

• Software package block file (extension .spb). This is a zip file with all source files necessary for distribution included. Contains files and commands. Any zip software can be used to view its contents (for example, Winzip).
• Software package definition file (extension .spd)  A text file that describes a software package. Contains a list of actions to be executed on the target. Can be updated with a text editor in place of using the Software Package Editor.   Can be manipulated with scripts.
• Software package file (extension: .sp) Internal binary version of the software package. Files are collected from the source host at distribution.

The SP, SPB and SPD software package formats can be easily converted from one format to another

• wconvspo command enables you to convert SPBs to SPs and vice versa.
• The wimspo and wexpspo commands enable the conversion from SP to SPD and vice versa, and from SPD to SPB and vice versa.

Creating a software package in built format ensures that the data in the software package remain static between distributions at different times.

Versioning

You can define a software package as versionable and specify whether it is a refresh package or a patch.

Refreshes are not installed if a later version of the package is already installed. Patches are not installed unless the version to which the patch applies is already installed.

The default policy of Tivoli Software Distribution allows the following naming format for software packages:

• sp_name^version, for example office^1.0.0 or  notes^1.2a
• sp_name.version, for example:   office.1.0.0 or   notes.1.2a

Dependencies

With software and hardware dependencies, you ensure that the package is installed only if the necessary prerequisites are satisfied. You can define an expression that makes the installation or removal of a software package dependent on meeting hardware and software prerequisites.

Variables

Variables can be used to express any attribute value of type string contained in the software package, making a software package more generic for use on different target systems. For example, it is not necessary to create several software packages for different platforms. You can substitute the platform-specific information with variables and use the same software package for distribution to multi-platform networks.

Conditions

You set conditions on the actions contained in a software package or on the entire software package. Using conditions, you define the circumstances under which an action is executed. For example, you can specify which actions are to be executed on Windows NT with Service Pack 5 target systems and which are to be executed only on Windows NT with Service Pack 6 targets.

Valid operators are:

Disconnected command line

Before a software package is distributed, it should be tested. On preparation machines on which the Tivoli Software Distribution Java Endpoint Package Editor is installed, an administrator can use special disconnected commands to test any operation Tivoli Software Distribution would perform on an endpoint. The testing phase can also include testing in a practice TMR.

The Software Package Editor provides a set of disconnected commands (Figure 4-18) that can be used to test the software package on the preparation machine.

Autopack

Many actions can happen during the installation of an application. Registry keys may be added to a Windows system or a symbolic link might be added to a UNIX system. Determining what actions take place when an application is installed can be a difficult process. The autopack tool can automatically create a software package for any application installed on a Windows 98, Windows NT, OS/2 3.x, or UNIX platform.

Below is a summary of Autopack functions:

The software package profile is created within a profile manager. Profile managers act as containers for profiles and link the profiles to a set of resources called subscribers. Tivoli supports software packages only in the context of profile managers. Therefore, all tasks must be performed that involve setting up profiles in a profile manager. This step is not necessary if the software package was originally created or edited in the context of a Tivoli software package profile using the Software Package Editor on a managed node.

States of a software package profile

there are three states of a software package profile: Empty, built, and not-built. The figure also shows the corresponding icons that you will see in the Tivoli Desktop for each profile state type.

Note: When importing a software package file or software package definition file into a software package object, the administrator can choose to build the software package immediately or leave it not built. The advantages of creating a software package in the not-built format are:

You can revise the software package until the moment of distribution.

It occupies a smaller amount of disk space.

If you use the non-built format, you need to take into consideration that data may change on the source host, so subscribers may receive different data at a different time. Software packages should always be imported into the built state if you want to use the deporting functionality.

The delivery step is performed by MDist 2.

The Software Distribution process uses the Framework's MDist 2 service to deliver the files to the endpoint target:

These operations fully automate distributing, installing, and maintaining software, and are as follows: Install: The install operation performs the actions contained in the software package. The actions executed by the install operation depend on the nature of the action. For example, while the install operation of the Add file action copies a file to the target file system, the install operation of the remove registry key action removes a registry key from the target system Windows registry. Remove: The remove operation reverses object-related actions that add something. If a software package adds a file or registry key, the remove operation will remove that file or registry key. Conversely, if the software package has an action that removes a file, nothing will happen to replace that file during the remove operation. Actions to be performed during a remove action can be specified for program actions within the software package. Undo: Performing a remove operation does not necessarily return the system to its previous state. For this reason, an undo operation is recommended where system files are involved in distributions. Executing an install operation in undoable mode creates a backup of everything necessary to return the system back to its previous state. An undo operation cannot be executed for an installed software package if it was not installed in undoable mode in the first place. An administrator can determine if an installation was performed in undoable mode by checking the state of the software package on the target.     Note: The machine must have adequate space to create the backup; otherwise the installation will not occur.   Accept: The accept operation discards the resources needed to undo the previous operation (backup copy). The accept operation, which frees up system resources, should be performed only when you are certain that you will not need to undo the previous operation. After running an accept operation, the previous operation is no longer undoable. Commit: An install or remove operation can be submitted in transactional mode. In this case the operation is performed in two phases: The preparation phase and the commit phase. During the preparation phase, each action in the package prepares the conditions for the successful execution of the requested operation, which reduces the risk of failure during the commit phase. The commit operation causes all the updates established in the preparation phase to take effect. Verify: The verify operation verifies the consistency of the software package and the object on the target system. If the verify operation fails, the software package is placed in an error state. Load: The load operation loads the software packages on a repeater depot for subsequent distribution. This operation is valid for only built software packages.     Note: A depot is a directory on the repeater that enables you to temporarily or permanently store data segments associated with distributions on the repeater. Every distribution flowing through a repeater is stored at least temporarily in the depot. The location of the depot parent directory is set by the rpt_dir repeater parameter. Use wmdist to view and set the parent directory of the depot.

Data Moving The Data Moving Service is a service that was introduced in Software Distribution V4.1. The Data Moving Service enables the sending, retrieving, and deleting of files from target systems.     Note: The Data Moving Service is supported on endpoints and users, but is not supported on devices.   All data moving operations use the same software package object, DataMovingRequests.1. This object contains certain standard information to be used by all data moving operations, including logging options. If this object is not available, no data moving operation can be performed from the CLI or the Activity Planner. This object is normally created automatically, in the DataMovingProfile profile manager within the default policy region, when you install Software Distribution. However, you can create the object later by running the data moving command, wspmvdata. This command has two options: -A: This creates the DataMovingRequests.1 object in a profile manager that belongs to a region having SoftwarePackage as the managed resource. -p <profile manager>: This creates a DataMovingRequests.1 object in the specified profile manager. The Data Moving Service supports the following scenarios: Sending a file held in a central location to multiple destinations Retrieving a specific file from a series of locations and consolidating the retrieved files in a single, central location Deleting a specific file from a series of locations Moving a set of files from one endpoint to a number of endpoints So in essence, the following change management operations are available when you use the data moving functions of software distribution: Send, delete, and retrieve.

Old News ;-)

Installing TCM

This section provides information about the Tivoli^® Configuration Manager (TCM) 4.2.3 FP 1 installation.

Note: For detailed information about the Tivoli Configuration Manager (TCM) 4.2.3, see http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/topic/com.ibm.tivoli.itcm.doc/welcome.htm

To install TCM, follow the steps mentioned below:

1. 1. Install DB2^® v8.2 by executing the command ./db2setup. Select the DB2 Enterprise Edition setup and select default settings for all options. For the health monitor notification, you must select Defer this task until after installation is complete option. Click Finish to complete the setup.
   2. Add db2profilefile to the .bashrc file.
   3. Create the databases by executing the following commands, in the order mentioned: su - db2inst1, db2start, db2 create db planner, db2 create db ccm, db2 create db inv_db, and db2 create db mdist2.
2. From TCM CD1, run the command ./setup_linux_intel.bin. This commands prompts you with a GUI to choose the components to install.
   1. Clear the WebUI, Enterprise Directory, Pristine Manager, and Patch Management options.
   2. At the Repository Configuration screen, select Default tablespaces and run schema scripts.
   3. Specify your user name as db2inst1, and your password, in the screen that appears.
   4. A screen appears that prompts you to specify the RDBMS and RIM information for all the different databases, change RIM user name to db2inst1, and also set RIM password and the Database administrator password.
   5. In the screen that allows you to select product images management, select Query when needed.
   6. In the screen that allows you to select the items to be run, select Run All.
   7. Provide the location of TCM CD 2.
3. Setup the distribution status console database. To do so:
   1. Execute the commands db2 connect to mdist2, db2 -tvf /usr/local/Tivoli/bin/linux-ix86/TME/MDIST2/sql/mdist_db2_admin.sql, and db2 -tvf /usr/local/Tivoli/bin/linux-ix86/TME/MDIST2/sql/mdist_db2_schema.sql.
   2. As a root user, execute the command wcrtrim -v db2 -h <hostname> -d mdist2 -u db2inst1 -H /home/db2inst1/sqllib/ -s tcpip -I ~db2inst1/ -t db2inst1 mdist2
4. Navigate to Tivoli desktop (Desktop > Install > Install Patch), and browse to <FP_HOME>/cd/image/SWD directory and click Set Media and Close. Install the following components in the order listed:
   1. Software Distribution Software Package Editor, Version 4.2.3, FixPack 4.2.3-SWDJPS-FP01
   2. Activity Planner, Version 4.2.3, FixPack 4.2.3-APM-FP01
   3. Change Manager , Version 4.2.3, FixPack 4.2.3-CCM-FP01
   4. Resource Manager, Version 4.2.3, FixPack 4.2.3-TRMSRV-FP01
   5. Resource Manager Gateway, Version 4.2.3, FixPack 4.2.3-TRMGW-FP01
5. Navigate to Tivoli desktop (Desktop > Install > Install Patch), and browse to <FP_HOME>/cd/image/INVENTORY directory and click Set Media and Close. Install the following components in the order listed:
   1. Inventory, Version 4.2.3, FixPack 4.2.3-INV-FP01
   2. Inventory Gateway, Version 4.2.3, FixPack 4.2.3-INVGW-FP01
6. Register the endpoint from the Server. To do so:
   1. Execute the command winstlcf -j -n <ep hostname> -g <server_hostname> <ep hostname> ensuring that the host name is defined in the endpoint's /etc/hosts file.
   2. To check if endpoints registered properly, execute the command tivoli. In the Tivoli Desktop, double-click on EndpointManager, it displays the gateway list. Double-click on a gateway item to get the endpoint list and double-clicking on a endpoint displays its properties.
7. To setup the Tivoli Inventory, do the following:
   1. Execute the tivoli command. In the Tivoli Desktop, double-click <hostname>-region.
   2. Right-click on Inventory_default_PM and select Subscribers....
   3. Highlight the desired endpoint and ensure that it is in the current subscribers window. Click Set Subscribers & Close.
   4. Double-click Inventory_default_PM and highlight INVENTORY_SCAN and drag and drop into endpoint in the Subscribers: Window. Close the window.
   5. In the <hostname>-region double-click INVENTORY_QUERY. In the new INVENTORY_QUERY window, select a desired query icon, right click, and select Run Query.... This creates a new information window.
8. To setup TCM, edit the sped_mn.sh file available in /usr/local/Tivoli/bin/linux-ix86/speditor/classes/ directory, and add the following text in the first line: export tme_sped_dir=/usr/local/Tivoli/bin/linux-ix86/speditor/classes/.
9. To create a profile manager, do the following:
   1. Execute the tivoli command. In the Tivoli Desktop, double-click <hostname>-region and navigate to Create > Profile Manager.
   2. Add Name/Icon Label, check Dataless endpoint mode, and click Create & Close. Double-click the newly created Profile Manager icon.
   3. In the Profile Manager window, navigate to Edit > Profile Manager.... Check Dataless Endpoint Mode and click Change & Close....
   4. Navigate to Profile Manger > Subscribers... and add the desired endpoints to the current subscribers. Click Set Subscriptions & Close.

[Feb 1, 2008] IBM Redbooks Deploying Rational Applications with IBM Tivoli Configuration Manager

This IBM Redpaper provides an overview of the Rational product installation process, describes how to create IBM Tivoli Configuration Manager software packages for the Rational products, and demonstrates how these packages can be used to distribute Rational products to a large number of systems. The paper can be used as a reference document to enable clients to perform unattended installations of Rational products.

The installation process in this paper applies to a Microsoft Windows-based target environment.

Although some information about Tivoli Configuration Manager is provided, this paper assumes that readers are already familiar with the product.

Chapter 1. Introduction
Chapter 2. Preparing Rational products for Tivoli Configuration Manager
Chapter 3. Creation of packages to install Rational products
Chapter 4. Deployment of Rational packages
Appendix A. Tivoli Configuration Manager environment installation  

IBM Certified Deployment Professional - Tivoli Configuration Manager V4.2.2

Job Role Description / Target Audience

An IBM Certified Deployment Professional - Tivoli Configuration Manager V4.2.2 is a technical professional responsible for planning, installation, configuration, operations, administration, and maintenance of an IBM Tivoli Configuration Manager V4.2.2 solution. This individual will be expected to perform these tasks with limited assistance from peers, product documentation, or support resources.

To attain the IBM Certified Deployment Professional - Tivoli Configuration Manager V4.2.2 certification, candidates must pass 1 test.   Required Prerequisite(s)

• Create and review design documents
• Define the IBM Tivoli Configuration Manager V4.2.2 architecture and components
• Verify installation of the prerequisite applications – IBM DB2, WebSphere Application Server, IBM HTTP Server, enterprise directories (LDAP, Active Directory, IBM Tivoli Directory Server)
• Configure and administer IBM Tivoli Inventory, IBM Tivoli Software Distribution, Scalable Collection Service, Resource Manager, Activity Planner, Change Manager, Enterprise Directory Query Facility, Pristine Manager, and Web Gateway components
• Build, distribute, and manage Inventory and Software Distribution profiles
• Build and customize software packages using IBM Tivoli Configuration Manager V4.2.2 Software Package Editor
• Build and use reference models, activity plans, and device object packages
• Integrate IBM Tivoli Configuration Manager V4.2.2 with IBM Tivoli Enterprise Console events
• Configure the IBM Tivoli Configuration Manager V4.2.2 environment to send data to the IBM Tivoli Data Warehouse
• Enable logs and traces to perform problem determination

   Recommended Prerequisite(s)

• Working knowledge of shell and PERL programming
• Working knowledge in SQL programming
• Basic understanding of Java, JSP, XML
• Working knowledge of supported operating systems
• Basic understanding of network security concepts
• Working knowledge of firewall concepts, and implications of network traffic restrictions in DMZ environment.
• Basic install of IBM DB2, IBM Tivoli Directory Server, Websphere Application Server, IBM HTTP Server, and JRE
• Use enterprise directory management tools to configure LDAP servers such as IBM Tivoli Directory Server and Microsoft Active Directory
• Working knowledge of TCP/IP
• Use IBM DB2 Management tools such as the Command Center and Control Center
• Basic understanding of third party software installers (MSI, InstallShield, PDF, RPM, pkgadd, patchadd, installp, swinstall)
• Working knowledge of Microsoft Automatic Deployment Services (ADS)
• Working knowledge of Microsoft Remote Installation Services (RIS)

Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

---

Recommended Links

Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2, SG24-6691-00 Redbook, published 21 March 2005.

Configuration manager documentation

All About IBM Tivoli Configuration Manager Version 4.2

Using Tivoli Software Installation Service for Mass Installation
 

Last modified: March 15, 2008