Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Tivoli Configuration Manager

News Tivoli Recommended Links wspmvdata Unix Configuration Management Tools Software Distribution
TMF TEC TWC Netview IBM humor Etc

The whole point of any configuration management tool is to make restoring a point in time, merging between them, and branching off experiments from the trunk as easy, reliable, and cheap as possible.

Tivoli Configuration Manager is IBM product that can help in software distribution and asset management inventory in a multi-platform environment. It is working via Tivoli endpoint (so delivery is not affected by firewalls) so it is an attractive addition to Tivoli, although in best IBM tradition it duplicates and obscure Tivoli Framework functionality (for poorly commercial reasons IBM wanted to change additional money for the functionality that in rudimentary way was provided by Tivoli framework and should be generally be a part of Tivoli framework).

General architecture of TCM is similar to classic Tivoli component and along with GUI tools there are command line tools that can be used in scripting.  Some architectural decisions are very questionable and some are inexcusable for the company like IBM.  The tool is difficult to learn, difficult to use and  have some obscure limitations (delivery of large files is not reliable).

Typical usage of TCM in many organization is duplicating functionality of ssh with a more expensive tool.

Among features that TCM supports:

The Software Distribution component comprises the following main elements:

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:

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

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:

Software Package Editor

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

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:

There are three types of software package files:

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

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:

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

 A tool to automate the creation of software packages.   Detects file and system changes made by the installation of an application   Can be accessed from the Software Package Editor on an endpoint or command line   Is not accessible from the Software Package Editor on a managed node Software package profile

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:

1. An administrator submits a request to the Tivoli management region server from the Tivoli Desktop.
2. The Tivoli management region server routes the request to the appropriate source host.
3. The source host begins the distribution process.
4. The source host returns a distribution identification number to the Tivoli management region server.
5. The Tivoli management region forwards the distribution identification number back to the administrator's Tivoli desktop.
6. Files are distributed down to the endpoints.

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.

NEWS CONTENTS

Old News ;-)

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

Recommended Prerequisite(s)

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. 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.
  1. 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.
  2. 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
  3. 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
  4. 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
  5. 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.
  6. 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.
  7. 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/.
  8. 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.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

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



Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019