Download Implementing a Tivoli Solution for Central Management of Large Distributed Environments Front cover

Front cover
Implementing a Tivoli Solution
for Central Management of
Large Distributed Environments
Remotely manage thousands of
distributed outlets
Architect and design for large
scale enterprises
Learn step-by-step Linux
installation
Morten Moeller
Robert Haynes
Paul Jacobs
Fabrizio Salustri
ibm.com/redbooks
International Technical Support Organization
Implementing a Tivoli Solution for Central
Management of Large Distributed Environments
June 2005
SG24-6468-00
Note: Before using this information and the product it supports, read the information in
“Notices” on page xvii.
First Edition (June 2005)
This edition applies to the Tivoli Management Environment software products Version 3.x,
4.x and 5.x.
© Copyright International Business Machines Corporation 2005. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii
Part 1. The outlet environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 1. The challenges of managing an outlet environment . . . . . . . . . 3
1.1 Complex application infrastructures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Managing outlet application systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Service Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.2 Service Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 The outlet application infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.1 Basic products used to facilitate outlet applications . . . . . . . . . . . . . 15
1.3.2 Managing outlet applications using Tivoli . . . . . . . . . . . . . . . . . . . . . 18
1.4 Tivoli product structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.5 Managing outlet applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.6 Meeting future challenges today . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Chapter 2. The Outlet Solution overview . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1 Introducing Outlet Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.1 The Outlet Inc. environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.2 Outlet Solution features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.3 Current IT infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.1.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2 The Outlet Systems Management Solution. . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.1 Outlet Systems Management Solution requirements . . . . . . . . . . . . 34
2.2.2 Outlet Systems Management Solution capabilities . . . . . . . . . . . . . . 36
Chapter 3. The Outlet Systems Management Solution Architecture . . . . 37
3.1 Outlet Inc. requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
© Copyright IBM Corp. 2005. All rights reserved.
iii
3.2 Physical architecture for Outlet Inc.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.1 Tivoli Command Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.2 TMR connections within Outlet Inc.. . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.3 Tivoli gateway architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3 Logical Tivoli architecture for Outlet Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3.1 Administering the Tivoli Management Environment . . . . . . . . . . . . . 53
3.3.2 Tivoli naming conventions for Outlet Inc. . . . . . . . . . . . . . . . . . . . . . 60
3.4 Setup and configuration planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4.1 Suggested Tivoli hardware requirements . . . . . . . . . . . . . . . . . . . . . 62
3.4.2 Tivoli repeater architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4.3 Optimizing slow links connections. . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.4.4 Managing endpoint behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.4.5 Managing the TME Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.4.6 Tivoli and RDBMS Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.5 Network communications and considerations . . . . . . . . . . . . . . . . . . . . . . 83
3.5.1 TCP/IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.6 Configuration management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.6.1 Tivoli Configuration Manager: Inventory . . . . . . . . . . . . . . . . . . . . . . 87
3.7 Release management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.7.1 Software Distribution in Outlet Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.7.2 Integrating Tivoli Software Distribution with the TEC . . . . . . . . . . . 102
3.7.3 Integrating Tivoli Software Distribution with Inventory . . . . . . . . . . 102
3.8 Availability and Capacity Management . . . . . . . . . . . . . . . . . . . . . . . . . . 103
3.8.1 IBM Tivoli Monitoring architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.8.2 ITM for Databases: DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
3.8.3 ITM for Web Infrastructure: WebSphere Application Server . . . . . . 115
3.8.4 IBM Tivoli Monitoring for Transaction Performance . . . . . . . . . . . . 117
3.9 Event management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Part 2. Management solution implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Chapter 4. Installing the Tivoli Infrastructure . . . . . . . . . . . . . . . . . . . . . . 129
4.1 The Outlet Systems Management Solution. . . . . . . . . . . . . . . . . . . . . . . 130
4.1.1 Management environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.1.2 Functional component locations . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.2 Installation planning and preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4.2.1 Create naming standards for all Tivoli related objects . . . . . . . . . . 141
4.2.2 Operating platform preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
4.2.3 Enabling SMB server on the srchost server . . . . . . . . . . . . . . . . . . 144
4.2.4 Establishing a code library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
4.3 Installation and configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.3.1 Establishing an installation roadmap. . . . . . . . . . . . . . . . . . . . . . . . 147
4.3.2 Installing a working database environment . . . . . . . . . . . . . . . . . . . 149
iv
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
4.3.3 Establishing the TME infrastructure . . . . . . . . . . . . . . . . . . . . . . . . 155
4.3.4 Tivoli Enterprise Console v3.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
4.3.5 Installing Tivoli Configuration Manager . . . . . . . . . . . . . . . . . . . . . . 187
4.3.6 IBM Tivoli Monitoring installation. . . . . . . . . . . . . . . . . . . . . . . . . . . 197
4.3.7 IBM Tivoli Manager Web Health Console . . . . . . . . . . . . . . . . . . . . 201
4.3.8 IBM Tivoli Monitoring for Web Infrastructure . . . . . . . . . . . . . . . . . . 209
4.3.9 IBM Tivoli Monitoring for databases . . . . . . . . . . . . . . . . . . . . . . . . 213
4.3.10 TMTP Management Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
4.4 Postinstallation configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
4.4.1 Framework customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
4.4.2 Enabling MDIST2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
4.4.3 Enabling Tivoli End-User Web Interfaces . . . . . . . . . . . . . . . . . . . . 232
4.4.4 Configuring the Tivoli Enterprise Console . . . . . . . . . . . . . . . . . . . . 234
4.4.5 Customizing the Inventory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
4.4.6 Configuring Software Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 245
4.4.7 Enabling the Activity Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
4.4.8 Enabling Change Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
4.4.9 IBM Tivoli Monitoring configuration . . . . . . . . . . . . . . . . . . . . . . . . . 255
4.4.10 IBM Tivoli Monitoring for Web Infrastructure . . . . . . . . . . . . . . . . . 259
4.4.11 IBM Tivoli Monitoring for Databases . . . . . . . . . . . . . . . . . . . . . . . 262
4.4.12 IBM Tivoli Monitoring for Transaction Performance . . . . . . . . . . . 266
Chapter 5. Creating profiles, packages, and tasks . . . . . . . . . . . . . . . . . 271
5.1 Defining the logical structure of the environment . . . . . . . . . . . . . . . . . . 272
5.2 Deploying management endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
5.3 Creating monitoring profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
5.3.1 Inventory scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
5.3.2 Hardware scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
5.3.3 System software scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
5.3.4 Custom scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
5.3.5 Defining OS and HW Monitoring Profiles . . . . . . . . . . . . . . . . . . . . 279
5.3.6 Defining TEC profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
5.3.7 Building the software package for deploying DB2 Server . . . . . . . . 291
5.3.8 Creating a DB2 instance for the Outlet Solution . . . . . . . . . . . . . . . 294
5.3.9 Defining DB2 monitoring objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
5.3.10 Creating the db2ecc user ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
5.3.11 Creating profiles for Tivoli Monitoring for Databases . . . . . . . . . . 298
5.3.12 Deploying WebSphere Application Server . . . . . . . . . . . . . . . . . . 303
5.3.13 Enabling WebSphere Application Server monitoring . . . . . . . . . . 311
5.3.14 Creating a software package for TimeCard Store Server . . . . . . . 317
5.3.15 Installing the TMTP Management Agent . . . . . . . . . . . . . . . . . . . . 318
5.3.16 Configuring TMTP to monitor WebSphere . . . . . . . . . . . . . . . . . . 320
Contents
v
Part 3. Putting the solution to use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Chapter 6. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
6.1 Automating deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
6.2 Automating tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
6.3 Creating the deployment activity plan . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
6.3.1 Building the reference model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
6.3.2 Completing the activity plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
6.4 Defining the logical structure of the
Outlet Inc. environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
6.5 Creating endpoint policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
6.5.1 Allow_login policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
6.5.2 Select_gateway policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
6.5.3 Login policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
6.5.4 After_login policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
6.6 Installing endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Part 4. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Appendix A. Configuration files and scripts . . . . . . . . . . . . . . . . . . . . . . 349
A.1 Additional material contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
A.2 TMR setup and maintenance-related files . . . . . . . . . . . . . . . . . . . . . . . 351
A.2.1 create_logical_structure.sh. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
A.2.2 Store lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
A.2.3 load_tasks.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
A.2.4 update_resources.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
A.3 Policies and related tasks and scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . 357
A.3.1 put.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
A.3.2 get.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
A.3.3 allow_policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
A.3.4 select_policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
A.3.5 gateway.lst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
A.3.6 login_policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
A.3.7 after_policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
A.3.8 sub_ep.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
A.3.9 ep_login_notif.sh. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
A.3.10 run_ep_customization_task.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
A.4 DB2 monitoring deployment-related scripts . . . . . . . . . . . . . . . . . . . . . . 371
A.4.1 create_db2_instance_objects.sh . . . . . . . . . . . . . . . . . . . . . . . . . . 371
A.4.2 create_db2_database_objects.sh. . . . . . . . . . . . . . . . . . . . . . . . . . 372
A.4.3 itm_db2_instance_rm_distrib.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
A.4.4 itm_db2_database_rm_distrib.sh . . . . . . . . . . . . . . . . . . . . . . . . . . 374
A.5 WebSphere Application Server monitoring
deployment files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
vi
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
A.5.1 create_app_server.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
A.5.2 itm_was_rm_distrib.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
A.5.3 was_configure_tec_adapter.sh. . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
A.5.4 was_start_tec_adapter.sh. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
A.5.5 was_stop_tec_adapter.sh. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
A.6 TMTP monitoring deployment scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
A.6.1 addtoagentgroup.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
A.6.2 deployj2ee.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
A.7 Software Packages and related files. . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
A.7.1 Common scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
A.7.2 IBM HTTP Server v2.0.47. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
A.7.3 WebSphere Message Queuing Server v5.3 . . . . . . . . . . . . . . . . . . 395
A.7.4 WebSphere Message Queuing Server v5.3 Fixpack 8. . . . . . . . . . 408
A.7.5 WebSphere Application Server v5.1 . . . . . . . . . . . . . . . . . . . . . . . . 417
A.7.6 WebSphere Application Server v5.1 Fixpack 1 . . . . . . . . . . . . . . . 464
A.7.7 DB2 Server v8.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
A.7.8 TMTP Agent v5.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
A.7.9 WebSphere Caching Proxy v5.1. . . . . . . . . . . . . . . . . . . . . . . . . . . 503
A.7.10 WebSphere Caching Proxy v5.1 Fixpack 1 . . . . . . . . . . . . . . . . . 592
A.7.11 TimeCard v5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
A.8 APM related scripts and files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
A.8.1 ep_customization.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
A.8.2 Production_Outlet_Plan_v1.0.xml . . . . . . . . . . . . . . . . . . . . . . . . . 629
Appendix B. Obtaining the installation images . . . . . . . . . . . . . . . . . . . . 645
IBM Business Partners. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
Appendix C. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
System requirements for downloading the Web material . . . . . . . . . . . . . 656
How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Product Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670
IBM Tivoli Management Framework v4.1.1. . . . . . . . . . . . . . . . . . . . . . . . 670
IBM Enterprise Console v3.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670
IBM Tivoli Configuration Manager v4.2.1 . . . . . . . . . . . . . . . . . . . . . . . . . 670
IBM Tivoli Monitoring v5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
Contents
vii
IBM Tivoli Monitoring for Databases v5.1.2 . . . . . . . . . . . . . . . . . . . . . . . 671
IBM Tivoli Monitoring for Web Infrastructure v5.1.2 . . . . . . . . . . . . . . . . . 671
IBM Tivoli Monitoring for Transaction Performance v5.3 . . . . . . . . . . . . . 672
Online Information Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
Online manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
viii
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figures
1-1
1-2
1-3
1-4
1-5
1-6
1-7
1-8
1-9
1-10
1-11
1-12
2-1
3-1
3-2
3-3
3-4
3-5
3-6
3-7
3-8
3-9
3-10
3-11
3-12
3-13
3-14
3-15
3-16
3-17
3-18
3-19
3-20
3-21
3-22
3-23
4-1
4-2
Growing infrastructure complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Layers of service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
The ITIL Service Management disciplines . . . . . . . . . . . . . . . . . . . . . . . . 9
Key relationships between Service Management disciplines . . . . . . . . 12
A typical outlet application infrastructure . . . . . . . . . . . . . . . . . . . . . . . . 13
Outlet Solution specific service layers . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Logical view of an outlet solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Typical Tivoli-managed outlet application infrastructure . . . . . . . . . . . . 19
The On Demand Operating Environment . . . . . . . . . . . . . . . . . . . . . . . 20
IBM Automation Blueprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Tivoli’s availability product structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Typical outlet solution infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Outlet Inc. network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Outlet Inc. Geographical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Centralized management method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Outlet Systems Management Solution overview . . . . . . . . . . . . . . . . . . 43
Logical Configuration of TMR Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Logical Configuration of TMR Spokes . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Sample profile manager hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Tivoli Desktops logical configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
MDist2 GUI Node Table dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Initial endpoint login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Normal Endpoint login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Tivoli Protocol Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Logical Architecture for Outlet Inc. Inventory Management . . . . . . . . . . 92
Software Distribution architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Software package distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
IBM Tivoli Monitoring High-level overview . . . . . . . . . . . . . . . . . . . . . . 104
Sampling of volatile metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Heartbeat endpoint registration data flow . . . . . . . . . . . . . . . . . . . . . . 110
Heartbeat monitoring data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Endpoint cache retrieval data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
High-level data flow of the Web Health Console . . . . . . . . . . . . . . . . . 113
TMTP architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Event Management architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Event management flow with Tivoli Enterprise Console . . . . . . . . . . . 125
Outlet Systems Management Solution architecture . . . . . . . . . . . . . . . 130
Install Tivoli Server: Specify Directory Locations . . . . . . . . . . . . . . . . . 158
© Copyright IBM Corp. 2005. All rights reserved.
ix
4-3
4-4
4-5
4-6
4-7
4-8
4-9
4-10
4-11
4-12
4-13
4-14
4-15
4-16
4-17
4-18
4-19
4-20
4-21
4-22
5-1
5-2
5-3
6-1
6-2
B-1
x
Install Tivoli Server: server and region names . . . . . . . . . . . . . . . . . . . 159
TM Install: completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Tivoli Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Create a new Policy Region. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Set managed resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Client Install: main window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Client Install: Add Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Client Install: Set Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Client Install: return to beginning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Client Install confirmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Policy Region: ManagedNodes-region . . . . . . . . . . . . . . . . . . . . . . . . 170
About Tivoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Installed Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Installed Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Edit TMR Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Administrator Info Changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
TEC Console login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Activity Plan Editor launch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Change Manager launch dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
TMTP: Web Health Console Integration . . . . . . . . . . . . . . . . . . . . . . . 270
Resource monitor status for endpoint dev01-ep . . . . . . . . . . . . . . . . . 290
Transactions discovered by discovery policy . . . . . . . . . . . . . . . . . . . . 326
Create J2EE Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
The automated deployment process . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Activity flow for Outlet Server deployment . . . . . . . . . . . . . . . . . . . . . . 337
Searching for Software Downloads . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Tables
2-1
3-1
3-2
3-3
3-4
3-5
3-6
3-7
3-8
3-9
3-10
4-1
4-2
4-3
4-4
4-5
4-6
4-7
4-8
4-9
4-10
4-11
4-12
4-13
4-14
4-15
4-16
4-17
4-18
4-19
4-20
4-21
4-22
4-23
4-24
4-25
6-1
6-2
Network speed comparison for software distribution . . . . . . . . . . . . . . 32
Suggested naming conventions for Tivoli objects . . . . . . . . . . . . . . . . . 61
Hardware requirements for TMR Servers and managed nodes . . . . . . 63
Hardware requirements for gateways . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Hardware requirements for endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Recommended MDist1 repeater settings. . . . . . . . . . . . . . . . . . . . . . . . 68
Recommended MDist2 repeater settings . . . . . . . . . . . . . . . . . . . . . . . 71
Endpoint Login Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Standard TCP/IP ports used by Tivoli . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Suggested wcollect settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Tables for storing Software Distribution status . . . . . . . . . . . . . . . . . . 103
The database environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Transaction performance monitoring environments. . . . . . . . . . . . . . . 134
The Hub TMR environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
The Spoke TMR environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
The PoC Regional environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
The Outlet environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Functional component location details for non-TMF systems . . . . . . . 138
Hub TMR functional component location details . . . . . . . . . . . . . . . . . 138
Sopke TMR functional component location details . . . . . . . . . . . . . . . 139
Naming standards for the Outlet Systems Management Solution . . . . 141
DB2 Instance and Database Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
hubtmr TMR Server installation parameters . . . . . . . . . . . . . . . . . . . . 157
Tivoli Management Framework installation roadmap . . . . . . . . . . . . . 172
TEC product and path installation roadmap. . . . . . . . . . . . . . . . . . . . . 182
TCM product and patch installation roadmap . . . . . . . . . . . . . . . . . . . 188
IBM Tivoli Monitoring product and patch installation roadmap . . . . . . 198
Web Health Console installation roadmap: GA version . . . . . . . . . . . . 203
Web Health Console installation roadmap - LA version. . . . . . . . . . . . 203
TMTP product and patch installation roadmap . . . . . . . . . . . . . . . . . . 218
Options for configCLI.sh script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Parameters for the mdist2 RIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Parameters for the tec RIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Parameters for the invdh_1 and inv_query RIMs. . . . . . . . . . . . . . . . . 239
Parameters for the planner RIM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Parameters for the ccm RIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Profile distribution scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Production tasks and related scripts . . . . . . . . . . . . . . . . . . . . . . . . . . 335
© Copyright IBM Corp. 2005. All rights reserved.
xi
6-3
B-1
xii
APM plan activities and conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Installation image download reference . . . . . . . . . . . . . . . . . . . . . . . . 647
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Examples
3-1
3-2
3-3
4-1
4-2
4-3
4-4
4-5
4-6
4-7
4-8
4-9
4-10
4-11
4-12
4-13
4-14
4-15
4-16
4-17
4-18
4-19
4-20
4-21
4-22
4-23
4-24
4-25
4-26
4-27
4-28
4-29
4-30
4-31
5-1
5-2
5-3
5-4
Gateway selection configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Changing collector starts and stops . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Signature file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Append file/etc/samba/smb.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Library structure code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Database created. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Cataloging hubtmr system databases . . . . . . . . . . . . . . . . . . . . . . . . . 154
Verifying databases for the hubtmr system . . . . . . . . . . . . . . . . . . . . . 155
Installing the Hub TMR Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
List of installed Tivoli components generated by wlsinst . . . . . . . . . . . 162
Managed node list produced by odadmin odlist. . . . . . . . . . . . . . . . . . 170
Installed Tivoli Components and patches . . . . . . . . . . . . . . . . . . . . . . 179
TEC component installation verification on Hub TMR . . . . . . . . . . . . . 185
TEC component verification on spokeTMR . . . . . . . . . . . . . . . . . . . . . 186
TCM Components installed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
ITM Components installed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
WebSphere Application Server tracing and logging location . . . . . . . . 207
Verifying TMTP CLI installation and configuration . . . . . . . . . . . . . . . . 222
oserv configuration information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
From the hubtmr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
From the spoketmr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Using the wlsconn command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Old https-port file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Revised http-port file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Verifying inventory profile distribution using wmdist command . . . . . . 244
wmdist -l sample output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Command line invocation of Inventory queries - sample output . . . . . 244
tecad_sd.conf sample file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Notifications to the TEC server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Querying the status of heartbeating . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
ITM for WI Configure_Event_Server task invocation . . . . . . . . . . . . . 260
TEC reception log output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
TMTP configuration of TEC Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
TMTP event processing verification . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Creating profile managers with crtprfmgr . . . . . . . . . . . . . . . . . . . . . . . 272
Issuing wcrtprfmgr from the spoketmr system . . . . . . . . . . . . . . . . . . . 272
Subscribing the spoketmr and hubtmr profile managers . . . . . . . . . . . 273
Verifying endpoint availability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
© Copyright IBM Corp. 2005. All rights reserved.
xiii
5-5
5-6
5-7
5-8
5-9
5-10
5-11
5-12
5-13
5-14
5-15
5-16
5-17
5-18
5-19
5-20
5-21
5-22
5-23
5-24
5-25
5-26
5-27
5-28
6-1
6-2
6-3
6-4
6-5
A-1
A-2
A-3
A-4
A-5
A-6
A-7
A-8
A-9
A-10
A-11
A-12
A-13
A-14
xiv
Creating inventory hardware scanning profile . . . . . . . . . . . . . . . . . . . 275
distributing an InventoryConfig profile . . . . . . . . . . . . . . . . . . . . . . . . . 275
Using wmdist to determine the status of a distribution. . . . . . . . . . . . . 275
Viewing scan results through wqueryinv . . . . . . . . . . . . . . . . . . . . . . . 275
Creating profiles for software scanning . . . . . . . . . . . . . . . . . . . . . . . . 276
Operating System information from Inventory . . . . . . . . . . . . . . . . . . . 277
Creating custom profiles for software scanning . . . . . . . . . . . . . . . . . . 277
Signature scanning of pristine system . . . . . . . . . . . . . . . . . . . . . . . . . 278
Inventory scan events forwarded to TEC . . . . . . . . . . . . . . . . . . . . . . . 279
Linking Jre using the DMLinkJre task . . . . . . . . . . . . . . . . . . . . . . . . . 280
Creating a Tmw2kProfile from the commandline . . . . . . . . . . . . . . . . . 281
hubtmr-region_MASTER_ITM_linux-ix86 monitoring profile details . . 282
Monitoring engine listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Defining the ACP profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
DB2 Instance object creation verification with wlookup . . . . . . . . . . . . 296
Default DB2-instances monitoring profile. . . . . . . . . . . . . . . . . . . . . . . 299
Active DB2 Instance monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Default DB2-databases monitoring profile . . . . . . . . . . . . . . . . . . . . . . 300
Output from wdmlseng on database server endpoint . . . . . . . . . . . . . 303
Discover WebSphere Resources task invocation . . . . . . . . . . . . . . . . 313
ISWApplicationServer objects and the default profile managers . . . . . 315
wdmlseng - <ep_name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Sample TMTP object names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Deploying the J2EE component. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Creating the Policy Region structure . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Distributing profiles to regions and stores . . . . . . . . . . . . . . . . . . . . . . 341
Logical subscription hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Creating profile managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Subscribing spoketmr profile managers to hubtmr profile managers. . 342
Links to /mnt directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
create_logical_structure.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
general_stores.lst. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
maine_stores.lst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
ohio_stores.lst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
load_tasks.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
update_resources.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
put.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
get.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
allow_policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
select_policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
gateway.lst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
login_policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
after_policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
A-15
A-16
A-17
A-18
A-19
A-20
A-21
A-22
A-23
A-24
A-25
A-26
A-27
A-28
A-29
A-30
A-31
A-32
A-33
A-34
A-35
A-36
A-37
A-38
A-39
A-40
A-41
A-42
A-43
A-44
A-45
A-46
A-47
A-48
A-49
A-50
A-51
A-52
A-53
A-54
A-55
A-56
A-57
sub_ep.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
ep_login_notif.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
run_ep_customization_task.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
create_db2_instance_objects.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
create_db2_database_objects.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
itm_db2_instance_rm_distrib.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
iitm_db2_database_rm_distrib.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
create_app_server.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
itm_was_rm_distrib.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
was_configure_tec_adapter.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
was_start_tec_adapter.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
was_stop_tec_adapter.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
addtoagentgroup.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
deployj2ee.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
do_it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
java141_it. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Software package for IBM HTTP Server v2 installation . . . . . . . . . . . . 383
Response file for IHS 2.0.47 installation . . . . . . . . . . . . . . . . . . . . . . . 392
IHS 2.0.47 installation script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
IHS 2.0.47 uninstallation script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
mq_server.5.3.0.spd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Script for creating user and group for WebSphere MQ . . . . . . . . . . . . 405
WebSphere MQ Server installation script . . . . . . . . . . . . . . . . . . . . . . 405
Script for uninstallation of WebSphere MQ server . . . . . . . . . . . . . . . . 407
Software Package mq_server.5.3.0_fp8.spd . . . . . . . . . . . . . . . . . . . . 408
mq_server_538_install.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
mq_server_538_uninstall.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Software package for WAS 5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Response file for WAS 5.1 installation . . . . . . . . . . . . . . . . . . . . . . . . . 438
Script for installation of WAS 5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
mod_was_server_JVM_process.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
mod_was_pmirm_settings.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Enable WAS security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
WebSphere Application Server security enablement control . . . . . . . . 462
WebSphere Application Server 5.1 uninstallation . . . . . . . . . . . . . . . . 463
Software package definition for was_server.5.1.0_fp1 . . . . . . . . . . . . 464
was_appserver_510_fp1 installation script . . . . . . . . . . . . . . . . . . . . . 476
Software package definition for db2_server.8.2.0.spd . . . . . . . . . . . . . 477
Response file for DB2 Server v8.2 installation. . . . . . . . . . . . . . . . . . . 487
db2_server_820_addusers.sh script to create db2 users . . . . . . . . . . 488
db2_server_820_remusers.sh to remove db2 users . . . . . . . . . . . . . . 489
Software Package for TMTP Agent deployment . . . . . . . . . . . . . . . . . 494
Responsefile for TMTP Agent deployment . . . . . . . . . . . . . . . . . . . . . 502
Examples
xv
A-58
A-59
A-60
A-61
A-62
A-63
A-64
A-65
A-66
A-67
A-68
A-69
xvi
Software package for Caching Proxy deployment . . . . . . . . . . . . . . . . 503
ibmproxy.conf for Outlet Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Installation script for WebSphere Caching Proxy. . . . . . . . . . . . . . . . . 591
Script to stop the WebSphere Caching Proxy . . . . . . . . . . . . . . . . . . . 592
Caching proxy fixpack 1 spd file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Software package for TimeCard installation and removal . . . . . . . . . . 603
Timecard installation and setup script . . . . . . . . . . . . . . . . . . . . . . . . . 613
db2_store_cfg.sh script to create store databases . . . . . . . . . . . . . . . 615
Store database table definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
TimeCard application installation script . . . . . . . . . . . . . . . . . . . . . . . . 618
ep_customization.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
Production_Outlet_Plan_v1.0.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such provisions
are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES
THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
© Copyright IBM Corp. 2005. All rights reserved.
xvii
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
1-2-3®
AIX®
Approach®
AS/400®
BookMaster®
CICS®
Database 2™
DB2 Universal Database™
DB2®
Domino®
e(logo)server®
Eserver®
Eserver®
Eserver®
eServer™
ETE™
ibm.com®
IBM®
Illustra™
IMS™
Lotus®
MQSeries®
Notes®
OS/2®
PartnerWorld®
Perform™
RAA®
RACF®
Rational®
Redbooks (logo)™
Redbooks (logo)
™
Redbooks™
SLC™
Tivoli Enterprise Console®
Tivoli Enterprise™
Tivoli Management
Environment®
Tivoli®
TME®
WebSphere®
The following terms are trademarks of other companies:
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel
SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its
subsidiaries in the United States and other countries.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
xviii
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Preface
This IBM Redbook will help you design, install, tailor and configure a Tivoli®
solution for managing a large Linux® IT infrastructure supporting highly
distributed business models such as branch banking or retail outlets.
The primary purpose of this book to provide an easy-to-follow. step-by-step guide
for using the following Tivoli systems management products:
򐂰 IBM Tivoli Management Framework v4.1.1
򐂰 IBM Tivoli Configuration Manager v4.2 (Inventory, Software Distribution,
Activity Planner, Change Manager)
򐂰 IBM Tivoli Enterprise™ Console® v3.9
򐂰 IBM Tivoli Monitoring v5.1.2
򐂰 IBM Tivoli Monitoring for Web Infrastructure: WebSphere® Application Server
v5.1.2
򐂰 IBM Tivoli Monitoring for Databases: DB2® v5.1
򐂰 IBM Tivoli Monitoring for Transaction Performance v5.3
In addition to these core components, particular implementations can be
extended using a variety of Tivoli solutions. To name a few:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
IBM Tivoli Data Warehouse for historical reporting
IBM Tivoli Service Level Advisor for service level management
IBM Tivoli Remote Control
IBM Tivoli Business Systems Manager for business related surveillance
IBM Tivoli Data Exchange for data synchronization
... and many more
You will also read about industry-specific solutions such as:
򐂰 IBM Tivoli Configuration Manager for ATMs
򐂰 IBM Tivoli Point-of-Sale Manager
For more information of any of these products, refer to the following Web site:
http://www.ibm.com/software/sw-atoz/indexT.html
The information in this book is intended for IT professionals with conceptual
knowledge of the Tivoli product set and who will be responsible for, or take part
in, deploying or maintaining a Tivoli systems management solution. Throughout
this redbook we provide references to relevant product documentation. While
reading this book, you might want to visit our main Tivoli InfoCenter Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
© Copyright IBM Corp. 2005. All rights reserved.
xix
The information in this book was developed around an example implementation
of a management solution for centralized distribution and management of most
hardware and software resources. We also discuss the provisioning of a sample
WebSphere based application using a DB2 database in a fictitious, Linux-based
retail environment.
The information in this book is structured this way:
򐂰 Part 1, “The outlet environment” on page 1
This introductory part discusses the management challenges surrounding a
highly distributed environment - including a high-level overview of the related
ITTIL processes, THis is followed by a description of how selected Tivoli
products will help overcome the challenges, and ends with a conceptual
architecture for the Outlet Systems Management Solution.
– The challenges of managing an outlet environment
– The Outlet Solution overview
– The Outlet Systems Management Solution Architecture
򐂰 Part 2, “Management solution implementation” on page 127
This main part of the book provides detailed step-by-step instructions on how
to install and configure the various Tivoli components along with related
middleware such as DB2 databases and WebSphere Application Servers.
The information is divided into an installation and a setup and customizing
section.
– Installing the Tivoli Infrastructure
– Creating profiles, packages, and tasks
򐂰 Part 3, “Putting the solution to use” on page 329
In this final section, we demonstrate how to perform the actual rollout of the
solution, focusing on automating the deployment. In addition, we provide a
brief discussion on the activities involved with the on-going maintenance of
the environment.
Throughout this book examples are provided. Source code for these is available
in Appendix A, “Configuration files and scripts” on page 349. For instructions on
how to download a machine-readable copy, see the instructions provided in
Appendix C, “Additional material” on page 655.
The team that wrote this redbook
This redbook was produced by a team of specialists from around the world
working at the International Technical Support Organization, Austin Center.
xx
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Morten Moeller is a Project Leader at the International Technical Support
Organization (ITSO), Austin Center. He applies his extensive field experience as
an IBM Certified IT Specialist to his work at the ITSO where he writes extensively
on all areas of Systems Management. Before joining the ITSO, Morten worked in
the Professional Services Organization of IBM Denmark as a Distributed
Systems Management Specialist where he was involved in numerous projects
designing and implementing systems management solutions for major
customers of IBM Denmark.
Robert Haynes is a Technical Lead in Toronto, Canada. He has 17 years of
experience in Application Development, and has been with IBM Global Services
for the past seven years. He holds a degree in Computer Science from the
University of the West Indies and an MBA from Wilfrid Laurier University,
Waterloo, Canada. He is an IBM Certified Application Developer for DB2 v7 and
8, a Certified PL/SQL Developer for Oracle 9i and a Principal CLP in Lotus®
Notes.
Paul Jacobs is a Technical Services Professional in Toronto, Canada. He
graduated Wildrid Laurier University, Waterloo, Canada with a degree in
economics and joined IBM shortly after graduating. Paul has been with IBM
Global Services for the past six years, specializing in Systems Management.
Fabrizio Salustri is an IT Support Specialist working for the EMEA South
Region within the IBM Global Services. He has been working for IBM since 1996,
and has extensive experience with Tivoli Products. Throughout his career,
Fabrizio has been involved in several projects implementing Tivoli solutions for
important clients of IBM Italy. Before joining the Tivoli Support, he worked as
Certified AIX® System Administrator in AIX Technical Support.
Thanks to the following people for their contributions to this project:
Bryan Chagoly
IBM Tivoli
Austin, Texas
The Editing Team
ITSO
Austin Center, Texas
Ashwin Manekar, Mark Wainwright
IBM SystemHouse
Raleigh, North Carolina
Preface
xxi
Become a published author
Join us for a two- to six-week residency program! Help write an IBM Redbook
dealing with specific products or solutions, while getting hands-on experience
with leading-edge technologies. You'll team with IBM technical professionals,
Business Partners and/or customers.
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you'll develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our Redbooks™ to be as helpful as possible. Send us your comments
about this or other Redbooks in one of the following ways:
򐂰 Use the online Contact us review redbook form found at:
ibm.com/redbooks
򐂰 Send your comments in an email to:
[email protected]
򐂰 Mail your comments to:
IBM® Corporation, International Technical Support Organization
Dept. JN9B Building 003 Internal Zip 2834
11400 Burnet Road
Austin, Texas 78758-3493
xxii
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Part 1
Part
1
The outlet
environment
In this section, we introduce and discuss the challenges of providing IT-based
solutions to large numbers of branches, retail outlets, and so forth.
For completeness, the information in this section will encompass some solutions.
However, the main focus will be on specific challenges of managing an
infrastructure of detached, highly distributed components. Here, the term
detached means that the distributed components are connected to the enterprise
network by low-cost, low speed, and low-reliability network connections, which is
the typical situation found in most outlet implementations today.
The main topics covered in this section are:
򐂰 Chapter 1, “The challenges of managing an outlet environment” on page 3
򐂰 Chapter 2, “The Outlet Solution overview” on page 29
򐂰 Chapter 3, “The Outlet Systems Management Solution Architecture” on
page 37
© Copyright IBM Corp. 2005. All rights reserved.
1
2
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
1
Chapter 1.
The challenges of managing
an outlet environment
Many large organizations within the retail and banking industries are looking for
ways to centralize and automate certain aspects of their IT processes. The goal
is to handle the vast majority of all IT administrative tasks from the enterprise
headquarters and to minimize the need for IT staff at each outlet or remote
location. The outlet could be a retail store or branch bank. This will free up the
outlet staff to focus on improving sales, and the customer experience. In addition,
centralizing IT might, in many instances, lead to better alignment between
business objectives and IT priorities, and will help the IT organizations to react
faster to the ever-changing business environment.
In this chapter, we discuss the challenges of designing and centrally managing
the IT requirements of hundreds or possibly thousands of remote locations and
their existing and emerging business requirements.
© Copyright IBM Corp. 2005. All rights reserved.
3
1.1 Complex application infrastructures
The complex infrastructure needed to facilitate modern, distributed retail and
banking solutions has been dictated mostly by requirements for standardization
of client run-time environments. In addition, application run-time technologies
play a major role, because they must ensure platform independence and
seamless integration to the back-end systems, as depicted in Figure 1-1.
Furthermore, making the applications accessible from any device type, from
anywhere in the world by any person on the planet raises some security issues
(authentication, authorization, and integrity) that need addressing.
Enterprise Network
Internet
Central Site
Browser
Web
Server
Appl.
Server
e-business
Browser
POS
Browser
e-business
Web
Server
with Legacy Systems
Appl.
Server
Browser
Business Systems
Databases
Server
Business Systems
Applications
Personal Computer
Business Systems
Front End
Client-Server
Personal
Computer
GUI Front-End
Terminal
Processing
"Dumb" Terminal
Figure 1-1 Growing infrastructure complexity
Because of the central role that the Web, application, and database servers,
commonly referred to as resource servers, play within a business and the fact
that they are supported and typically deployed across a variety of platforms
4
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
throughout the enterprise, there are several major challenges to managing an
outlet infrastructure, including:
򐂰 Managing resource servers on multiple platforms in a consistent manner from
a central location
򐂰 Defining and maintaining the outlet infrastructure from one central location
򐂰 Monitoring resources (systems, sites, networks, applications, and databases)
to know when problems have occurred or are about to occur
򐂰 Taking corrective action when a problem is detected, independent of the
platform
򐂰 Gathering data across all outlet environments to analyze events, messages,
and metrics
The degree of complexity of the outlet infrastructure system management is
directly proportional to the size of the infrastructure being managed. In its
simplest form, an outlet infrastructure is comprised of a central set of resources
combined with a single Web server and its resources in each outlet. However,
the complexity of this simple outlet solution in most country-wide
implementations, no-matter which country, can require managing hundreds or
even thousands of resource servers throughout the enterprise.
To add to the complexity, the outlet infrastructure can span many platforms with
different network protocols, hardware, operating systems, and applications. Each
platform possesses its unique and specific systems management needs and
requirements, not to mention varying levels of support for the administrative tools
and interfaces.
Every component in the outlet infrastructure is a potential bottleneck, or even
single point of failure. Each and every one provides specialized services needed
to facilitate the outlet application system. We use the term application systems
deliberately to emphasize the idea that no single component by itself provides a
total solution.
The outlet application is pieced together by a combination of standard
off-the-shelf components and in-house-developed components. The standard
components usually provide general services, such as session control,
authentication and access control, messaging, and database access. The
in-house components add the application logic needed to glue all the different
bits and pieces together to perform specific functions for a particular application
system. On an enterprise level, chances are that many of the custom
components might be promoted to standard status to ensure that specific
company standards or policies are enforced.
Chapter 1. The challenges of managing an outlet environment
5
At first glance, breaking up the outlet application into many specialized services
might be regarded as counterproductive and very expensive. However,
specialization enables sharing of common components (such as Web,
application, security, and database servers) between more outlet application
systems. Specialization is also key to ensuring availability and performance of
the application system as a whole by allowing for duplication and distribution of
selected components. These specialized components can then meet specific
resource requirements or increase the performance of the application systems
as a whole. In addition, this itemizing of the total solution allows for almost
seamless adoption of new technologies for selected areas without the need to
change the total system.
Whether the components in the outlet system are commercial, standard, or
application-specific, each of them will most likely require other general services,
such as communication facilities, storage space, and processing power. The
computers on which they run need electrical power, shelter from the weather,
access security, and perhaps even cooling.
As it turns out, the outlet application relies on several layers of services that can
be provided in-house or by external companies. This is illustrated in Figure 1-2.
Figure 1-2 Layers of service
As a matter of fact, it is not exactly the outlet application that relies on the
services depicted above. The truth is that individual components such as Web
servers, database servers, application servers, lines, routers, hubs, and switches
each rely on underlying services provided by some other component. You can
break this down even further, but that is beyond this discussion. The point is that
the outlet solution is exactly as solid, robust, and stable as the weakest link of the
chain of services that make up the entire solution. The bottom-line results of an
enterprise can be affected drastically by the quality of its outlet solutions.
There are a number of technologies available to allow for continuing, centralized
monitoring and surveillance of the outlet solution components. These
6
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
technologies help manage the IT resources. Some of these technologies can
even be applied to manage the non-IT resources such as power, cooling, and
access control.
However, each layer in any component is specialized and requires different types
of management. In addition, from an IT-management point of view, the top layer
of any component is the most interesting, because it is the layer that provides a
unique service required by a particular component. For a Web server, the top
layer is the HTTP server itself. This is the mission-critical layer, even though it
still needs networking, an operating system, hardware, and power to operate. On
the other hand, for an outlet application server, the mission-critical layer is the
application transactions, which rely on other components implemented on the
server, such as the application server, database client, operating system, power,
and networking. These are considered secondary in this case. This said, all the
underlying services are needed and must operate flawlessly in order for the top
layer to provide its services. It is much like driving a car. You monitor the
speedometer regularly to avoid penalties for violating changing speed limits, but
you check the fuel indicator only from time to time or when the indicator alerts
you to perform preventive maintenance by filling up the tank.
1.2 Managing outlet application systems
Specialized functions require specialized management, and general functions
require general management. Therefore, it is obvious that the management of
the operating system, hardware layer, and networking layer be general because
they are used by most of the outlet infrastructure components. On the other
hand, a management tool for Web application servers might not be very
well-suited for managing the database server.
Up till now, the term managing has been widely used, but not yet explained.
Control over and management of the computer system and its vital components
are critical to the continuing operation of the system and therefore the timely
availability of the services and functions provided by the system. This includes:
򐂰 Controlling both physical and logical access to the system to prevent
unauthorized modifications to the core components
򐂰 Monitoring the availability of the systems as a whole, as well as the
performance and capacity usage of the individual resources, such as disk
space, networking equipment, memory, and processor usage
Of course, these control and monitoring activities have to be performed
cost-effectively, so the cost of controlling any resource does not become higher
than the cost of the resource itself. It does not make much business sense to
spend $1000 to manage a $200 hard disk, unless the data on that hard disk
Chapter 1. The challenges of managing an outlet environment
7
represents real value to the business in excess of $1000, or a disk outage due to
unavailable capacity or component failure represents a potential loss in excess
of $1000. Planning for recovery of the systems in the event of a disaster also
needs to be addressed. Being without computer systems for days or weeks has
a huge impact on your enterprise’s ability to conduct business.
There still is one important aspect to be covered for successfully managing and
controlling computer systems. We have mentioned various hardware and
software components that collectively provide a service, but which components
are part of the IT infrastructure, where are they, and how do they relate to one
another? A prerequisite for successful management is the detailed knowledge of
which components to manage, how the components interrelate, and how these
components can be manipulated in order to control their behavior.
In addition, now that IT has become an integral part of doing business, it is
equally important to know which commitments we have made with respect to
availability and performance of the outlet solutions, and what commitments our
subcontractors have made to us. For planning and prioritization purposes, it is
vital to combine our knowledge about the components in the infrastructure with
the commitments we have made to assess and manage the impact of
component malfunction or resource shortage. In short, in a modern outlet
environment, one of the most important management tasks is to control and
manage the service catalogue in which all the provisioned services are defined
and described, and the Service Level Agreements in which the commitments of
the IT department are all listed and explained in detail.
For this discussion, we turn to the widely recognized Information Technology
Infrastructure Library (ITIL). The ITIL was developed by the British Government’s
Central Computer and Telecommunications Agency (CCTA), but has over the
past decade or more gained acceptance in the private sector.
One of the reasons behind this acceptance is that most IT organizations, met
with requirements to promise or even guarantee performance and availability,
agree that there is no point in agreeing to deliver a service at a specific level if the
basic tools and processes needed to deploy, manage, monitor, correct, and
report the achieved service level have not been established. ITIL groups all of
these activities into two major areas, Service Delivery and Service Support, as
shown in Figure 1-3 on page 9.
8
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figure 1-3 The ITIL Service Management disciplines
1.2.1 Service Delivery
The primary objectives of the Service Delivery discipline are proactive and
consist primarily of planning and ensuring that the service is delivered according
to the Service Level Agreement. The processes required for this to happen are
described in the following sections.
Service Level Management
Service Level Management involves managing customer expectations and
negotiating Service Level Agreements. This involves identifying customer
requirements and determining how these can best be met within the
agreed-upon budget, as well as working together with all IT disciplines and
departments to plan and ensure delivery of services. This involves setting
measurable performance targets, monitoring performance, and taking action
when targets are not met.
Financial Management
Financial Management consists of registering and maintaining cost accounts
about the use of IT services and delivering cost statistics and reports to Service
Level Management to help them obtain the correct balance between service cost
and delivery. It also means assisting in pricing the services in the service catalog
and SLAs.
Chapter 1. The challenges of managing an outlet environment
9
IT Services Continuity Management
IT Services Continuity Management develops and ensures the continuing
delivery of minimum outage of the service by reducing the impact of disasters,
emergencies, and major incidents. This work is done in close collaboration with
the company’s business continuity management, which is responsible for
protecting all aspects of the company’s business, including IT.
Capacity Management
Capacity Management plans and ensures that adequate capacity with the
expected performance characteristics is available to support the service delivery.
It also delivers capacity usage, performance, and workload management
statistics (as well as trend analysis) to Service Level Management.
Availability Management
Availability Management means planning and ensuring the overall availability of
the services and providing management information in the form of availability
statistics, including security violations, to Service Level Management.
This discipline also includes negotiating underpinning contracts with external
suppliers as well as the definition of maintenance windows and recovery times.
1.2.2 Service Support
The disciplines in the Service Support group are concerned with implementing
the plans and providing management information about the levels of service to
be achieved.
Configuration Management
Configuration Management is responsible for registering all components in the IT
service, including customers, contracts, SLAs, hardware and software
components, and maintaining a repository of configured attributes and
relationships between the components.
Service Desk
The Service Desk is the main point of contact for users of the service. When
users report problems, incident records are generated by Service Desk. The
Service Desk also provides statistics to Service Level Management,
demonstrating the service levels achieved.
Incident Management
Incident Management registers incidents, generated from Service Desk or
automatically by the other processes. It also allocates severity, initiates known
10
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
solution tasks, and coordinates the efforts of support teams to ensure timely and
accurate problem resolution.
Escalation times are noted in the SLA and are agreed upon between the
customer and the IT department.
Problem Management
Problem Management implements and uses procedures to perform problem
diagnosis, identify solutions, and correct problems. It also registers solutions in
the configuration repository.
Escalation times should be agreed upon internally with Service Level
Management during the SLA negotiation. It also provides problem resolution
statistics to support Service Level Management.
Change Management
Change Management plans and ensures that the impact of a change to any
component of a service is well known and that the implications regarding service
level achievements are minimized. This includes changes to the SLA documents
and the Service Catalog as well as organizational changes and changes to
hardware and software components.
Release Management
Release Management manages the master software repository, reference
models and so forth. Release Management act, in effect, as the work horse for
Change Management by orchestrating and deploying approved changes, and
provides management reports regarding deployment.
The key relationships between these disciplines are shown in Figure 1-4 on
page 12.
Chapter 1. The challenges of managing an outlet environment
11
Figure 1-4 Key relationships between Service Management disciplines
For the remainder of this discussion, we limit our discussion to Capacity,
Availability, and Release management of the outlet environment. Contrary to the
other disciplines that are common services provided by the IT organization, the
outlet solutions provide special challenges to management, due to their high
visibility and importance to the bottom line business results, their level of
distribution, and the special security issues that characterize the Internet.
To learn more about ITIL, visit these Web sites:
򐂰 The UK’s Office of Government Commerce
http://www.ogc.gov.uk
򐂰 The IT Service Management Forum
http://www.itSMF.com
12
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
1.3 The outlet application infrastructure
In a typical outlet environment, the application infrastructure consists of three
separate, central tiers. As Figure 1-5 shows, the communication between these
tiers is restricted. These tiers form the back-end of the application solution and
normally host the applications accessible from the Internet.
In the distributed outlet environment, the outlets are connected through secure
connections (the enterprise network), and local servers that provide distributed
functions located throughout the regional offices and outlets.
Enterprise network
Outlet
Outlet
Outlet
Internet
Region
Firewall
Firewall
Authentication
Access control
Intrusion detection
Demilitarized
Zone
Firewall
Application hosting/serving (W eb and application servers)
Load balancing
Distributed resource servers (MQ, database, and so on)
Gateways to back-end or external resources (MQ, database, etc.)
Application
Tier
Firewall
Back-end and legacy recources (databases, transactions, etc.)
Infrastructural resource servers (MQ, database, and so on)
Gateways to external resources
Back-end
Firewall
Internal
Custom er
Segm ent
Internal
Custom er
Segm ent
Company intranet
Resource sharing...
Figure 1-5 A typical outlet application infrastructure
The tiers can be described this way:
򐂰 Regions or outlets are the remote host secure systems that host the
application locally to provide 24x7 access in the outlet. The application users
are restricted to being physically present in the location using hand-held
devices, Point of Service (PoS) systems, PCs or self-service systems such as
kiosks, ATMs, scanners, and so forth.
򐂰 The Demilitarized Zone (DMZ) is the tier accessible by all external and
remote, internal users of the applications. This tier functions as the
gatekeeper to the entire system. Functions such as access control and
Chapter 1. The challenges of managing an outlet environment
13
intrusion detection are enforced here. The only other part of the intracompany
network that the DMZ can communicate with is the application tier.
򐂰 The Application Tier is usually implemented as a dedicated part of the
network where the application servers reside. End-user requests are routed
from the DMZ to the specific servers in this tier, where they are serviced.
When the applications need to use resources from company-wide databases,
for example, these are requested from the back-end tier, where all the
secured company IT assets reside. As was the case for communication
between the DMZ and the Application Tier, the communication between the
Application Tier and the back-end systems is established through firewalls
using well-known connection ports. This helps ensure that only known
transactions from known machines outside the network can communicate
with the company databases or existing transaction systems such as CICS®
or IMS™. Apart from specific application servers, the Application Tier also
hosts load-balancing devices and other infrastructural components, such as
MQ Servers, needed to implement a given application architecture.
򐂰 The Back-end Tier is where all the vital company resources and IT assets
reside. External access to these resources is only possible through the DMZ
and the Application Tier.
This model architecture is a proven way to provide secure, scalable,
high-availability access to company data with a minimum of exposure to security
violations. However, components such as application servers and infrastructural
resources vary depending upon the nature of the applications, company policies,
the requirements to availability and performance, and the capabilities of the
technologies used.
If you are in the outlet hosting area, or you have to support multiple lines of
business that require strict separation, the conceptual architecture shown in
Figure 1-5 on page 13 can be even more complicated. In these situations, one
or more of the tiers might have to be duplicated to provide the required
separation. In addition, the back-end tier might even be established remotely,
relative to the Application Tier. This is very common when the outlet application
hosting is outsourced to an external vendor, such as IBM Global Services.
To help design the most appropriate architecture for a specific set of e-business
applications, IBM has published a set of e-business patterns that be used to
speed up the process of developing outlet applications and deploying the
infrastructure to host them.
The concept behind these e-business patterns is to reuse tested and proven
architectures with as little modification as possible. IBM has gathered
experiences from more than 20,000 engagements, compiled these into a set of
guidelines, and associated them with links. A solution architect can start with a
14
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
problem and a vision for the solution and then find a pattern that fits that vision.
Then, by drilling down using the patterns process, the architect can further define
the additional functional pieces that the application will need to succeed. Finally,
the architect can build the application using coding techniques outlined in the
associated guidelines.
For more information regarding e-business patterns, refer to the IBM Redbook
Patterns: Service-Oriented Architecture and Web Services, SG24-6303-00, and
related redbooks available for download at IBM Redbooks Web site:
http://www.redbooks.ibm.com
1.3.1 Basic products used to facilitate outlet applications
So far, we have concluded that when building an outlet solution we want to:
򐂰 Provide the user access to the applications and information using a variety of
devices: hand-helds, scanners, kiosks, PCs, and PoS along with an
easy-to-use interface that fulfills the needs of the user and has a common
look-and-feel to it.
򐂰 Use as many standard components as possible to keep costs down and be
able to interchange them seamlessly.
򐂰 Be reliable and available at all times with a minimum of maintenance.
򐂰 Build in unique features or differentiators that make the user choose our
product over those of the competitors.
No matter whether the outlet solution is the front end of an existing system or a
new application developed using modern, state-of-the-art development tools, it
must be characterized by three specific layers of services that work together to
provide the unique functionality necessary to allow the applications to be used in
an Internet environment, as shown in Figure 1-6.
S
o
lu
tio
nS
e
rv
e
r
P
re
s
e
n
ta
tio
n
C
lie
n
tO
p
e
ra
tin
gS
e
rv
ic
e
s
N
e
tw
o
rk
in
g
S
e
rv
ic
e
s
In
te
rn
e
tP
ro
to
c
o
l
T
ra
n
s
fo
rm
a
tio
n
S
e
rv
e
rO
p
e
ra
tin
gS
e
rv
ic
e
s
E
n
v
iro
n
m
e
n
ta
lS
e
rv
ic
e
s
Figure 1-6 Outlet Solution specific service layers
Chapter 1. The challenges of managing an outlet environment
15
The Presentation layer must be a commonly available tool installed on all the
machines of the users of the outlet solution. It should support modern
development technologies such as XML, JavaScript, and HTML pages. User
access is commonly implemented through a browser interface.
The standard communication protocols which provide connectivity to the Internet
are TCP/IP, HTTP, and HTTPS. These protocols must be supported by both
client and server machines.
The Transformation services are responsible for receiving client requests and
transforming them into business transactions that, in turn, are processed by the
Solution Server. In addition, it is the responsibility of the Transformation service
to receive results from the solution server and convey them back to the client in a
format that can be handled by the browser. In outlet solutions that do not interact
with existing systems, the transformation and solution server services be
implemented in the same application, but most likely they are split into two or
more dedicated services.
This is a very simple representation of the functions that take place in the
Transformation service. Among other functions that must be performed are
identification, authentication and authorization control, load balancing, and
transaction control. Dedicated servers for each of these functions are usually
implemented to provide a robust and scalable outlet environment. In addition,
some of these are placed in a dedicated network segment, the DMZ. From the
point of view of the outlet owner, the DMZ is fully controlled; client requests are
received by well-known, secure systems and passed on to the enterprise
network, the intranet. This architecture increases security by avoiding
transactions from unknown machines wanting to reach the enterprise network,
and minimizing the exposure of enterprise data to the risk of hacking.
To facilitate secure communication between the DMZ and the intranet, a set of
Web servers is usually implemented, and identification, authentication, and
authorization are typically handled by an LDAP Server.
The infrastructure depicted in Figure 1-7 contains all components required to
implement a secure outlet solution, allowing anyone from anywhere to access
and do business with the enterprise.
16
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Browser
Device
Firew all
Web Server
(Load Balancer)
Firew all
Web
Server
LDAP
Server
Browser
Device
Kiosk/ATM
Firew all
Application
Server
Firew all
Databases
Business
Logic
Figure 1-7 Logical view of an outlet solution
For more information about outlet architectures, please refer to the redbook
Patterns for e-business: User to Business Patterns for Topology 1 and 2 Using
WebSphere Advanced Edition, SG24-5864. Search for it at the IBM Redbooks
Web site:
http://www.redbooks.ibm.com.
Tivoli and IBM provide some of the most widely used products to implement the
e-business infrastructure. These are:
򐂰 IBM HTTP Server provides communication and transaction control.
򐂰 Tivoli Access Manager provides identification, authentication, and
authorization.
򐂰 IBM WebSphere Application Server provides Web application hosting,
responsible for the transformation services.
򐂰 IBM WebSphere Edge Server provides Web application firewalling, load
balancing, Web hosting, and is responsible for the transformation services.
Chapter 1. The challenges of managing an outlet environment
17
1.3.2 Managing outlet applications using Tivoli
Even though the e-business patterns help with designing outlet applications by
breaking them down into functional units that can be implemented in different
tiers of the architecture using different hard- and software technologies, the
patterns provide only limited assistance in managing these applications.
Fortunately, this gap is filled by solutions from Tivoli Systems.
When you design the systems management infrastructure needed to manage the
outlet applications, keep in mind that the determining factor for the application
architecture is the nature of the application itself. This determines the application
infrastructure and the technologies you use. However, it does not do any harm if
a solution architect consults with systems management specialists while
designing the application.
The systems management solution has to play more or less by the rules set up
by the application. Ideally, it manages the various application resources without
any impact on the outlet application, while observing company policies on
networking use, security, and so forth.
Management of outlet applications is, therefore, best achieved by establishing
yet another networking tier, parallel to the application tier, in which all systems
management components can be hosted without influencing the applications.
Naturally, because the management applications have to communicate with the
managed resources, the two meet in the network and on the machines hosting
the various outlet application resources.
Using the Tivoli product set, it is recommended that you establish all the central
components in the management tier and have a few proxies and agents present
in the DMZ and application tiers, as shown in Figure 1-8 on page 19.
18
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Enterprise network
Outlet
Outlet
Outlet
Internet
Region
Firewall
Firewall
Distributed Sys. Mgmt. Agents
Tivoli Gateway
Tivoli Endpoint
ITM Monitoring Engine
Distributed Sys. Mgmt. Agents
Tivoli Gateway
Tivoli Endpoint
ITM Monitoring Engine
Demilitarized
Zone
Firewall
Distributed Sys. Mgmt. Agents
Tivoli Gateway
Tivoli Endpoint
ITM Monitoring Engine
Application
Tier
Mangement
Tier
Firewall
Distributed Sys. Mgmt. Agents
Tivoli Gateway
Tivoli Endpoint
ITM Monitoring Engine
Central Sys. Mgmt. Resources
Tivoli TMR
TEC Server
TBSM Server
Tivoli Data Warehouse Server
Back-End
Firewall
Internal
Customer
Segment
Internal
Customer
Segment
Distributed Sys. Mgmt. Agents
Tivoli Gateway
Tivoli Endpoint
ITM Monitoring Engine
Figure 1-8 Typical Tivoli-managed outlet application infrastructure
Implementing the management infrastructure in this fashion, there is minimal
interference between the application and the management systems. The access
to and from the various network segments is manageable, because the
communication flows between a limited number of nodes using well-known
communication ports.
IBM Tivoli management products have been developed with the total
environment in mind. The IBM Tivoli Monitoring product provides the basis for
proactive monitoring, analysis, and automated problem resolution.
1.4 Tivoli product structure
In this section, we discuss how Tivoli solutions provide comprehensive systems
management for the outlet enterprise and how the IBM Tivoli Monitoring for
Transaction Performance product fits into the overall architecture.
In the hectic On Demand Business environments of today, responsiveness,
focus, resilience, variability, and flexibility are key to conducting business
successfully. Most business processes rely heavily on IT systems, so it is fair to
say that the IT systems have to possess the same set of attributes in order to be
Chapter 1. The challenges of managing an outlet environment
19
able to keep up with the speed of business. To provide an open framework for
the On Demand Business IT infrastructure, IBM has published the On Demand
Blueprint, which defines an On Demand Operating Environment with three major
properties (Figure 1-9):
򐂰 Integration is the efficient and flexible combination of resources including
people, processes, and information, to optimize resources across and beyond
the enterprise.
򐂰 Automation is the capability to dynamically deploy, monitor, manage, and
protect an IT infrastructure to meet business needs with little or no human
intervention.
򐂰 Virtualization means presenting computer resources in ways that allow users
and applications to get value out of them easily, rather than presenting them
in ways dictated by the implementation, geographical location, or physical
packaging.
Integration
Integration
Automation
Automation
Virtulization
Virtulization
On Demand Operating Environment
Figure 1-9 The On Demand Operating Environment
The key motivators for taking steps to align the IT infrastructure with the ideas of
the On Demand Operating Environment are:
򐂰 Align the IT processes with business priorities
Allow your business to dictate how IT operates, and eliminate constraints that
prohibit the effectiveness of your business.
򐂰 Enable business flexibility and responsiveness
Speed is one of the critical determinants of competitive success. IT processes
that are too slow to keep up with the business climate cripples corporate
goals and objectives. Rapid response and nimbleness mean that IT becomes
an enabler of business advantage versus a hindrance.
20
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
򐂰 Reduce cost
By increasing the automation in your environment, immediate benefits can be
realized from lower administrative costs and less reliance on human
operators.
򐂰 Improved asset utilization
Use resources more intelligently. Deploy resources on an as-needed,
just-in-time basis, versus a costly and inefficient just-in-case basis.
򐂰 Address new business opportunities
Automation removes lack of speed and human error from the cost equation.
New opportunities to serve customers or offer better services will not be
hampered by the inability to mobilize resources in time.
In the On Demand Operating Environment, IBM Tivoli Monitoring for Transaction
Performance plays an important role in the automation area. By providing
functions to determine how well the users of the business transactions, the J2EE
based ones in particular, are served, IBM Tivoli Monitoring for Transaction
Performance supports the process of provisioning adequate capacity to meet
Service Level Objectives, and helps automate problem determination and
resolution.
For more information about the IBM On Demand Operation Environment, please
refer to the redbook On demand Operating Environment: Managing the
Infrastructure, SG24-6634-00.
As part of the On Demand Blueprint, IBM provides specific Blueprints for each of
the three major properties. The IBM Automation Blueprint depicted in Figure 1-10
on page 22 defines the various components needed to provide automation
services for the On Demand Operation Environment.
Chapter 1. The challenges of managing an outlet environment
21
Business Services Management
Policy-based Orchestration
Availability
Security
Optimization
Provisioning
Virtualization
Figure 1-10 IBM Automation Blueprint
The IBM Automation Blueprint defines groups of common services and
infrastructure that provide consistency across management applications, as well
as enabling integration.
Within the Tivoli product family, there are specific solutions that target the same
five primary disciplines of systems management:
򐂰
򐂰
򐂰
򐂰
򐂰
Availability
Security
Optimization
Provisioning
Policy-based Orchestration
Products within each of these areas have been made available over the years
and, because they are continually enhanced, have become accepted solutions in
enterprises around the world. With these core capabilities in place, IBM has been
able to focus on building applications that take advantage of these solution-silos
to provide true business systems management solutions.
As already described, a typical outlet application depends not only on hardware
and networking, but also on software ranging from the operating system to
middleware such as databases, Web servers, and messaging systems, to the
applications themselves. A suite of solutions such as the IBM Tivoli Monitoring
for... products, enables an IT department to provide consistent availability
management of the entire business system from a central site and using an
integrated set of tools. By using an end-to-end set of solutions built on a common
foundation, enterprises can manage the ever-increasing complexity of their IT
infrastructure with reduced staff and increased efficiency.
22
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Within the availability group in Figure 1-10 on page 22, two specific functional
areas are used to organize and coordinate the functions provided by Tivoli
products. These areas are shown in Figure 1-11.
R apid tim e to valu e
Event Correlation and Automation
C ross-system & dom ain root cause analysis
O pen architecture
M ay be deployed independently
O ut-of-box best practices
E ase of use
Monitor Systems and Applications
D iscover, collect m etrics, probe (e.g. user experience),
perform local analysis, filter, concentrate,
determ ine root cause, take autom ated action
S uperior value with a fully
integrated solution
Q uality
P rocesses, roles, and m etrics
R apid problem response
Figure 1-11 Tivoli’s availability product structure
The lowest level consists of the monitoring products and technologies, such as
IBM Tivoli Monitoring and its resource models. At this layer, Tivoli applications
monitor the hardware and software, then provide automated corrective actions
whenever possible.
At the next level is event correlation and automation. As problems occur that
cannot be resolved at the monitoring level, event notifications are generated and
sent to a correlation engine, such as Tivoli Enterprise Console. The correlation
engine at this point can analyze problem notifications, or events, coming from
multiple components and either automate corrective actions or provide the
necessary information to operators who can initiate corrective actions.
Both tiers provide input to the Business Information Services category of the
Blueprint. From a business point-of-view, it is important to know that a
component or related set of application systems has failed as reported by the
monitors in the first layer. Likewise, in the second layer, it is valuable to
understand how a single failure can cause problems in related components. For
example, a router being down could cause database clients to generate errors if
they cannot access the database server. The integration to Business Information
Services is a very important aspect, because it provides an insight into how a
component failure can affect the business as a whole. When the router failure
above occurs, it is important to understand exactly what line of business
applications are affected and how to reduce the impact of that failure on the
business.
Chapter 1. The challenges of managing an outlet environment
23
1.5 Managing outlet applications
As we have seen, providing the services of outlet application systems requires
that basic services such as communications, messaging, database, and
application hosting are functional and well-behaved. This should be ensured by
careful management of the infrastructural components using Tivoli tools to
facilitate monitoring, event forwarding, automation, console services, and
business impact visualization.
However, ensuring the availability and performance of the application
infrastructure is not always enough. Web-based applications are implemented in
order to attract business from customers and business partners whom we might
or might not know. Depending on the nature of the data provided by the
application, company policies for security and access control, as well as access
to and use of specific applications, can be restricted to users whose identity can
be authenticated, for example when using an ATM machine. For other types of
users such as supermarket shoppers and kiosk users, there are no requirements
to authenticate to access the application.
In either case, the goal of the application is to provide useful information or
services to the user and, hopefully, attract the user to return later. The service
provided to the user, in terms of functionality, ease of use, and responsiveness of
the application, is critical to the user’s perception of the application’s usefulness. If
the user finds the application useful, there is a fair chance that the user will return
to conduct more business with the application owner.
The usefulness of an application is a very subjective measure, but it seems fair to
assume that an individual’s perception of an application’s usefulness involves, at
the very least:
򐂰
򐂰
򐂰
򐂰
򐂰
Relevance to current needs
Easy-to-understand organization and navigation
Logical flow and guidance
Integrity of the information (is it trustworthy?)
Responsiveness of the application
Naturally, the application owner can influence all of these parameters. The owner
can modify the design, validate the data, and so forth. However, network or
database latency and the capabilities of the user’s system are critical factors that
affect the time it takes for the user to receive a response from the application. To
avoid this becoming an issue that scares users away from the application, the
application provider can:
򐂰 Set the user’s expectations by providing sufficient information up front.
򐂰 Make sure that the back-end transaction performance is as fast as possible,
at a proven, acceptable level.
24
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Neither of these will guarantee that users will return to the application, but
monitoring and measuring the total response time and breaking it down into the
various components will give the application owner an indication of where a
delay, or bottleneck, might be.
To provide consistently good response times from the backend systems, the
application provider can also establish a monitoring system that generates
reference transactions on a scheduled basis. This will give early indications
about availability and impending capacity problems.
The need for real-time monitoring and gathering of reference and historical data,
among others, are addressed by IBM Tivoli Monitoring for Transaction
Performance. By providing the tools necessary for understanding the
relationships between the various components that make up the total response
time of an application, including breakdown of the backend service times into
service times for each sub transaction.
1.6 Meeting future challenges today
To help meet the challenges of staying productive and competitive, it seems
obvious that more and more IT-based solutions will be made available to the
users in the outlets, meaning for instance, retail stores or branch banks and
ATMs. For competitive and operational reasons, it is very likely that these
applications will have to be available on a 24x7 basis. This implies that
application hosting is required to be local to the outlets, partly to provide fast
response times to the local users, and partly because of the tremendous costs of
establishing application and networking infrastructures with the required
bandwidth and a 99.999% availability.
A likely generic solution infrastructure looks like the one depicted in Figure 1-12,
supporting either two or three-tier implementations.
Chapter 1. The challenges of managing an outlet environment
25
Figure 1-12 Typical outlet solution infrastructure
Whether or not regional gateways are implemented as suggested in Figure 1-12
is a matter of application design and functionality, combined with the need to limit
costs and avoid introducing bottlenecks.
Today, in the highly competitive marketplace where every dime matters, outlets
are traditionally connected to the enterprise systems through low-cost,
low-bandwidth lines to save costs. This allows the outlet businesses to exchange
data with the outlets outside of peek hours, thus keeping costs for networking to
a minimum. Over time it is more than likely, that the distributed solutions will be
tightly integrated on a real-time level with the back-end enterprise systems, which
typically will require establishing more advanced networking solutions than the
ones typically implemented today.
The generic outlet solution presented in this publication assumes that the retail
organization or branch bank has a server in each outlet and a low bandwidth
network connection between the outlet and the enterprise or regional office. More
details regarding the sample outlet solution are provided in Chapter 2, “The
Outlet Solution overview” on page 29.
26
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
No-matter the actual solution, implementing detached, distributed solutions
introduces a number of specific challenges related to application architecture,
data exchange, and, in particular, solution, infrastructure and platform
management.
To improve solution management, the successful solution would:
򐂰 Support the remote install and uninstall of applications over low bandwidth.
򐂰 Support the seamless upgrade of software across 1000s of outlets by
supporting a staged rollout.
򐂰 Support a standard set of software and remote systems management.
򐂰 Support remote problem determination from the enterprise for a wide variety
of applications running at 1000s of branches and retail outlets.
򐂰 Limit the need for IT skill in the outlet.
To ensure data currency and integrity, the successful solution would:
򐂰 Provide reliable, priority-based, schedule-driven data synchronization
supporting multiple data types and product independent APIs.
򐂰 Support push and pull data transmission and synchronization.
򐂰 Achieve maximum efficiency on data replication.
򐂰 Support the hosting of applications at the outlet due to the typically low
bandwidths between the enterprise and the outlet, but tightly integrate these
technologies to the enterprise.
To support user management, the successful solution would:
򐂰 Permit user registry management to be done either centrally or from the
outlets.
To ensure platform consistency, the successful solution would:
򐂰 Be delivered as an out-of-the-box solution which supports a heterogeneous
development environment.
򐂰 Support device-independent applications so that separate applications do not
need to be written for each device type.
Chapter 1. The challenges of managing an outlet environment
27
28
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
2
Chapter 2.
The Outlet Solution
overview
This chapter provides a high-level view of the capabilities, interfaces and the
requirements for the Outlet Solution and the related Outlet Systems
Management Solution.
© Copyright IBM Corp. 2005. All rights reserved.
29
2.1 Introducing Outlet Inc.
The following introduces a fictitious enterprise, Outlet Inc., which we use as the
target organization and for which we architect, design and implement a systems
management solution.
Outlet Inc. is a major retailer in the geography in which it is located.
2.1.1 The Outlet Inc. environment
Outlet Inc. maintains approximately 1400 outlets scattered throughout its
geography. The outlets vary in size; several outlets are considered primary,
serving as network hubs for multiple suboutlets. These hubs are referred to as
regional outlets.
The number of regional outlets account for about 30%, and the suboutlets for
roughly 70% of the total number of outlets.
Each regional outlet is directly connected through a high-speed connection to the
enterprise technology center.
The suboutlets are connected to the enterprise through a dial-up, slow VPN
connection through the regional outlets.
Outlet server and client systems are moving to a Linux platform, which is the new
platform for the Outlet Solution. Outlet Inc. needs a solution to manage the
distributed environment and the new business application.
All regional and suboutlets will be equipped with a United Linux server. This
server will be exploited by the Tivoli Management Framework.
Network configuration
The Outlet Inc. regional outlets are connected to the primary enterprise
technology center through a 64-kbps frame relay backbone network as depicted
in Figure 2-1.
30
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figure 2-1 Outlet Inc. network topology
The suboutlets are currently connected to the regional ones with 19.2 Kbps
leased lines. Outlet Inc. is working to improve the network capacity. In the near
future, the 19.2-Kbps lines should be upgraded to 64 Kbps, and our project relies
on these changes. In addition, Outlet Inc. might create connections among the
regional outlets.
The speed upgrade of the leased lines is planned in order to improve the
performance throughout the network, especially for software distribution. For
example, assume that Outlet Inc. needs to distribute a 5-MB application to 200
outlets, setting 50 to the maximum number of targets per distribution and
allowing the distribution to consume no more than 70% of the maximum
bandwidth) Table 2-1 on page 32 shows the result using either a 64 Kbps or 19.2
Kbps:
Chapter 2. The Outlet Solution overview
31
Table 2-1 Network speed comparison for software distribution
Distribution properties
19.2 Kbps
64 Kbps
Size of application
5 MB
Maximum bandwidth allowed
70%
Maximum number of targets per distribution
50
Number of total target
200
Distribution completion time for 100% of targets
208 Minutes
62 Minutes
DHCP
Outlet Inc. uses Dynamic Host Configuration Protocol (DHCP). DHCP provides a
way to dynamically lease, on a temporary basis, an IP address to requesting
systems. DHCP is now a very widely used protocol system for most of their
distributed environment.
The DHCP server supporting the systems in any outlet is the main outlet server.
The outlet servers themselves have static IP addresses.
DNS
In Outlet Inc., an internal network guarantees the IP-level connectivity for all the
systems through a LAN/WAN link structure, and through a private addressing
using a 10-class network.
Different DNS domain servers take care of management of the associations
between hostnames and IP address.
Outlets
Outlets will be equipped with one or more Linux server systems and a varying
number of Linux client systems, up to 150 to 200 clients in the regional outlets,
10 to 15 clients on the average for each outlet.
2.1.2 Outlet Solution features
Besides the Solution Management capabilities of the Outlet Solution, the
following features are being implemented through features of the middleware
(DB2, WebSphere) components supporting the Outlet Solution.
Data synchronization
Data synchronization between the outlet and the enterprise needs to be reliable
over a very low bandwidth. Data synchronization should be schedule driven and
exception management capabilities provided. Synchronization needs to be
32
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
supported from the enterprise to the outlet and from the outlet to the enterprise.
The solution must support various data types and use product-independent APIs.
User management
The enterprise and the outlet need to be able to control access to their systems.
An employee with a valid ID and password will be granted access while all
unauthorized users will be denied access.
Application services
The solution needs to support an infrastructure that enables the organization to
easily create, run, and maintain applications to improve the customer experience.
2.1.3 Current IT infrastructure
The IT infrastructure for the enterprise-outlet organization has the following
characteristics:
򐂰 Servers in the enterprise and in the outlet
򐂰 And outlet server, both hardware and software, is installed an configured from
the enterprise and shipped to the outlet for setup by a technician
򐂰 Poor connectivity between the outlet and the enterprise, the characteristics of
which are low bandwidth, low reliability, uncertain latency.
򐂰 Inconsistent levels of technology across the outlets
򐂰 Loosely integrated applications in a heterogeneous environment
򐂰 Numerous devices with device dependent applications
򐂰 Legacy device support
򐂰 Web applications
򐂰 Database management systems
2.1.4 Constraints
Like most retailers, Outlet Inc. expects the solution to be supported on both the
Windows® and Linux operating systems.
Retail POS systems need to be run from the outlet because that is the only way
to guarantee the required 99.999% availability. Today, POS cannot be run from
the enterprise. POS systems need to be hosted locally and integrated with the
enterprise.
Chapter 2. The Outlet Solution overview
33
The Outlet Solution footprint will need to be reasonable given the cost of
hardware installation across 1000s of outlets and the need to support remote
install across low bandwidths.
The Outlet Solution will likely be constrained by the need to phase the rollout due
to its sheer magnitude, meaning the number of applications in the solution,
number of outlets, number of supported devices, and so forth.
2.2 The Outlet Systems Management Solution
Based on the requirements for operational robustness of the Outlet Solution, the
Outlet Systems Management Solution must be designed to meet the specific
requirements and include the capabilities described in the following sections.
2.2.1 Outlet Systems Management Solution requirements
To manage the environment, including middleware infrastructures, in which the
Outlet Solution is implemented, a dedicated Outlet Systems Management
Solution will be established. This must support, at a minimum, the core functional
requirements:
򐂰
򐂰
򐂰
򐂰
򐂰
Automated installation and customization
Remote debugging
Interim fix
Monitoring
Disconnected operations
Automated installation and customization
A new application has been developed for the outlets. The application has been
through extensive user testing and feedback and has been approved for general
deployment. A six-week launch window has been agreed to by the organization.
The IT Administrator creates a change request and attaches it with relevant
information such as the launch window information, impact of the change, and a
change package which includes the application, prerequisites information,
information regarding installation, configuration, validation, recovery information,
and so on, to be deployed to each outlet.
The Outlet Systems Management Solution must be able to manage automated
installation and configuration of all application and middleware components to
the outlets, if possible without the outlets incurring any downtime.
The installation and customization process must include prerequisite checking of
the required hardware and software. If the software stack is not at the required
level, the system obtains the required levels of the underlying software before
34
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
initiating install of the new application. If a hardware upgrade is required, then the
install is put on hold until the required hardware upgrade takes place. Once the
application is installed, an install and configuration check is executed and the
Enterprise is notified of the successful deployment.
Interim fix
Similar to a new application deployment, an interim fix is rolled out to the outlets.
But instead of a mass upgrade, the decision has been made to apply the
upgrade region by region.
Again, a pre-installation check of the software stack and hardware is performed.
If the hardware is deemed to be below standards, a call is automatically placed to
service personnel to upgrade the machine. Once the hardware and software
prerequisites are passed, the interim fix is applied and a postinstall check can be
executed. A notification of success or failure is sent back to the enterprise.
Monitoring
The Outlet Systems Management Solution will allow the enterprise to continually
monitor the health of the outlet systems and their associated applications.
Throughout the normal business hours, metrics regarding the responsiveness of
the key application transactions, and status of registered applications and
middleware components is checked to ensure that they are within predefined
limits. This information indicates that they are operational, available and
performing according to predefined thresholds. If an application or the outlet is
unable to respond, the enterprise is informed of the outage and an investigation
is performed by the IT Administrator.
Remote debugging
The gift registry application is not able to update the gift list with the latest
purchase information. Using available knowledge and tools, the application tries
to recover from the situation itself. Once it has exhausted all possibilities, an alert
is sent to the enterprise to help resolve the problem. The IT Administrator
receives the alert and proceeds to investigate. Using available tooling, the IT
Administrator tries to search the knowledge base for a known recovery action.
Once the knowledge base has been exhausted, the IT Administrator starts a
manual investigation into the problem. By examining additional logs and making
some correlations against these logs, the IT Administrator is able to identify and
resolve the problem with the gift registry application.
Disconnected operations
Network connection to the enterprise is interrupted during a lightening storm.
During this period, the outlet personnel and customers are not aware of any
service degradation, that is, this recovery action occurs in the background. The
Chapter 2. The Outlet Solution overview
35
users at the outlet are not aware of the disruption and are unaware of the
recovery activities that are taking place.
2.2.2 Outlet Systems Management Solution capabilities
Based on the requirements, the following basic capabilities must be included in
the Outlet Systems Management Solution.
Inventorying
The Outlet Systems Management Solution must facilitate gathering and storing
of configuration information across thousands of outlets and hundreds of
thousands of devices. This information should be presented in a consistent
manner.
Remote installation
Remote installation must be supported across all middleware components and
applications. Support for phased rollout should be provided and the footprint
minimized.
Monitoring
The Outlet Systems Management Solution must enable the customer to monitor
application, middleware, operation system and hardware metrics across
thousands of outlets and hundreds of thousands of devices. This information
should be presented in a consistent manner.
Event handling
Centralized, correlated event handling with automated recovery facilities must be
facilitated across all middleware components and applications to allow for
automated problem determination and recovery.
Remote problem determination
Remote, end-to-end, problem determination must be supported across all
middleware components and applications.
Remote upgrade
Remote upgrades must be supported across all middleware components and
applications. This requires production level support of the previous version during
the phased rollout across outlets.
Remote uninstall
Remote uninstall capabilities must be provided and phased scheduling across
outlets supported.
36
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
3
Chapter 3.
The Outlet Systems
Management Solution
Architecture
In this chapter, we discuss the architecture of the systems management solution
for Outlet Inc. Refer to 2.2, “The Outlet Systems Management Solution” on
page 34 for a description of the functional requirements.
The architecture addresses only the challenges and needs for managing the IT
infrastructure and applications, not specific details about applications, user
administration, database management, infrastructure components such as
network or security.
The architecture focuses on issues common to IT infrastructures in retail and
outlet banking environments. The main components used to establish the core
management functions are:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
Tivoli Management Framework
Tivoli Configuration Manager
Tivoli Enterprise Console
Tivoli Monitoring
Tivoli Monitoring for Web Infrastructure
Tivoli Monitoring for Databases
Tivoli Monitoring for Transaction Performance
© Copyright IBM Corp. 2005. All rights reserved.
37
3.1 Outlet Inc. requirements
The intent of Outlet Inc., is to implement a centralized systems management
solution that unifies all the tools and instruments used in the central technology
center. This solution also needs to allow the operators to work with the same
modalities independent of the platforms, without the needing to know specific
operating systems controls and commands.
That solution has to allow for the management of all the Outlet Inc. distributed
systems to be managed in the same way. In this first phase, however, the focus
is on the establishment of the Linux Outlet Solution server systems.
Another requirement is the independence of the solution from the hardware and
operating systems platforms on the target systems. This independence enables
Outlet Inc. to introduce a unique instrument of management, and to enlarge the
usage in the future to other departments, even data processing solutions in
heterogeneous environments such as Microsoft® Windows 2000, Microsoft
Windows NT® and Unix.
The definition of new hardware platforms and the renewal of software throughout
the organization introduces new management challenges compared to the
previous hostcentric perspective. In particular, the control and management of a
large distributed environment.
Based on Outlet Inc. requirements described in 2.2, “The Outlet Systems
Management Solution” on page 34 and the selected Tivoli products, the following
main areas will be addressed by the Outlet Systems Management Solution:
򐂰 Software Distribution
– Distribution and installation of software updates concerning data,
applications and systems throughout the Outlet Inc. infrastructure
– Distribution of homegrown software packages and prepackaged software
based on standard installation tools provided by the operating platform
– Possibility of installing software for 300 outlets in parallel
– Synchronous activation of the distributed packages on every outlet
– Ability to define after and before (install, undo, remove, commit…)
procedures
– Possibility of specifying installation prerequisites
– Management of distribution queues, automatic checkpoint and restart
– Locked file management
– Inventory integration, queries on inventory database conditioned
distributions
38
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
– Distribution on system groups, through a good balance of the distribution
weight (distribution parameter configuration)
– Distinction between software installation and activation phases
– Possibility to verify the status of distribution progress, in terms of systems
updates and distribution results
– Possibility to create packages to be distributed, moving from a client
image, taking a picture of its software status before and after a manual
installation, analyzing the differences
– Software products installation using response files (silent installation)
– Distribution of composite packages to targets including conditional
processing
– Definition of reference models to fix hardware and software states
conditions to be met on group of targets
– Versioning check on software packages defined as versionable, applicable
to products and patches
– Using an execution window to limit the planned action between specific
start and stop dates
– Possibility of retrieving a software package from a CD-ROM or a file server
rather than the source host
– Integration with inventory repository data relative to the status of software
package distributions; synchronization of software package status of
endpoints with the repository catalog
򐂰 Centralized hardware and software Inventory
– Analysis of hardware and software configurations of outlet systems
– Possibility of personalizing the inventory for the management of
nonstandard software
– Queries usage as input of software distribution process
– Integration with the software distribution activity
– Possibility of scheduling hardware and software scanning
– Complex and predefined queries
– Possibility of maintaining an historical record of the information collected
and analyzing that data in a report
򐂰 Alarms and thresholds management
– Focal point of correlation of data collected by setting monitor on distributed
resources and alarms
Chapter 3. The Outlet Systems Management Solution Architecture
39
– Alarms management of system resources including disk space, CPU
usage, memory availability, and critical processes
– Possibility of intercepting application alarms, in case the application is able
to write in a system log file
– Collection of application and system alerts in a distributed environment
database belonging to the event management focal points
– Ability to manage data collected in the database and to produce reports
– Correlation of collected information, and historical analysis
– Alarms filtering at remote site
– Possibility of automatic actions setting and activating, both on center and
on remote site
򐂰 Support staff capabilities
–
–
–
–
Access to the Tivoli Console
Access to the Health Console
Access to the MDist2 Console
Access to the Tivoli functionality according to each user’s roles and
responsibilities.
3.2 Physical architecture for Outlet Inc.
In accordance with the requirements defined in the previous section, Outlet Inc.
will adopt a centralized support infrastructure. As shown in Figure 3-1. All outlets
will be managed from the central technology center.
40
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figure 3-1 Outlet Inc. Geographical Architecture
The centralized management model will incorporate a centrally structured
support organization, where help desk, network, administration and general IT
staff will be combined into a single unit, based in a central location.
Chapter 3. The Outlet Systems Management Solution Architecture
41
Figure 3-2 Centralized management method
All operations, from distribution of software packages to inventory scanning of
systems, can be performed from this single focal point.
In order to satisfy Outlet Inc. requirements and the centralized management
model, a Tivoli command center will be established within Outlet Inc.
3.2.1 Tivoli Command Center
The Command Center is based on the standard Tivoli three-tier architecture with
two levels of TMRs, Hub and Spoke TMRs, as shown in Figure 3-3 on page 43.
For more details on the three-tier Tivoli architecture, refer to the Tivoli Planning
for Deployment Guide, available online at the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
From the welcome page, navigate to Management Framework →Planning for
Deployment Guide →Components of the basic Tivoli architecture.
This architecture allows for a good performance level of control and
management activities, while assuring the scalability of the Center in the event of
growing of management needs, for example, future expansion of the number
managed outlets.
42
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
In fact, every second-level Spoke (TMR) system is a dedicated Tivoli
Management Region that has management responsibility for a specific subset of
distributed outlets.
Figure 3-3 Outlet Systems Management Solution overview
Upstream, second-level TMRs or Spokes will be interconnected to the first-level
TMR (Hub) in order for the HubTMR to become a unique center capable of
controlling and monitoring all the distributed outlets.
Downstream, the Spoke TMRs are connected to a Tivoli Gateway implemented
on a managed node in each of the regions and outlets. The gateways are
responsible for passing requests and responses back and forth between the
endpoints, systems that are the objects of our management actions, and the
TMR servers. Gateways can be arranged in multi-level hierachies, allowing a
regional gateway to support multiple outlet gateways.
Placing a gateway in each region and outlet helps minimize WAN dependency
and capacity by:
򐂰 Allowing for selective bandwidth configuration.
򐂰 Minimizing the need to communicate with central components.
򐂰 Preloading software images to remote depots during offpeak hours
Chapter 3. The Outlet Systems Management Solution Architecture
43
򐂰
򐂰
򐂰
򐂰
Installing software from local sources
Allowing for detached (without connection to the TMR) software installation
Uploading of inventory scan data during offpeak hours
Consolidating events and issuing corrective actions locally before forwarding
them to the central event manager.
However, we want to emphasize that any systems management solution in which
monitoring of remote components requires a robust networking infrastructure
which will support timely transmission of events, commands, and data.
The architecture will be based on the following Tivoli products:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
Tivoli Framework v4.1.1
IBM Tivoli Configuration Manager v4.2
Tivoli Enterprise Console v3.9
IBM Tivoli Monitoring v5.1.2
IBM Tivoli Monitoring for Web Infrastructure: WAS v5.1.2
IBM Tivoli Monitoring for Databases: DB2 v5.1.0
IBM Tivoli Monitoring for Transaction Performance v5.3
It is recommend that all the patches that apply to this environment be installed.
For a complete list of patches to be installed, please refer to the product Release
Notes and to Tivoli support Web site:
http://www.tivoli.com/support/patches
Figure 3-3 on page 43 shows the final configuration for the HubTMR production
environment.
Note: The final number of Spoke TMRs increase accordingly with the
increasing number of outlets to be managed.
Core components of the Tivoli Command Center
The key components of the Tivoli Management Environment® framework are:
򐂰 Tivoli Management Region Server
– HUB TMR
– Spoke TMRs
򐂰 Tivoli managed node
򐂰 Tivoli gateway
򐂰 Tivoli endpoint
򐂰 Source host
򐂰 TEC server
򐂰 RDBMS server
򐂰 Console server
򐂰 TMTP server
44
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Tivoli Management Region Server
The Tivoli Management Region Server (TMR) server is the heart of the Tivoli
Management Environment within Outlet Inc. All managed resources in Outlet Inc.
must be assigned to a TMR server. All of the desired Tivoli management
applications must be installed on the TMR servers. Some products can also
include binaries that must be installed on the Tivoli Gateways as well. The TMR
serves as the central workhorse within the systems management solution that
allows all of the various applications and components to communicate and
interoperate.
All TMRs will be able to perform administration such as definition of managed
resources, managing distribution of monitoring profiles, handling event traffic,
enterprise wide software distribution, etc.
To support Outlet Inc. with the services and applications necessary for enterprise
management, there will be two particular levels of Tivoli Management Regions.
To facilitate easy grouping for these management levels, the solution will be
based upon the Hub-Spoke model. This will involve the creation of a top level
management area that is known as the Hub TMR. Once this has been
established, sub-ordinate management levels known as Spoke TMRs can then
be created to support specific parts of the distributed outlet infrastructure.
The primary role of the Hub TMR server is to facilitate a centralized management
server in its own dedicated TMR. The Hub TMR server directly manages a
limited number of resources so that it can be dedicated primarily to the support of
administrators accessing the management functions in the TME®. In addition, it
is the focal point for enterprise wide activities such as configuration and
distribution of monitoring profiles to any server in the environment. The Hub TMR
server forms the central administration point from which all management
functions are performed within a TME. Administrator’s Desktop and TEC
consoles are defined and configured in this TMR. The central event management
server, the TEC server, is implemented on a dedicated managed node contained
within the Hub TMR.
The Spoke TMRs provide the direct control function to all managed resources in
a specific subset of the Tivoli Management Environment. Generally, Spoke TMRs
are not used as entry points for administrators. For ease of maintenance. the
Spoke TMRs should be placed in the same location as the Hub TMR.
Even if there is no limit on the number of managed nodes that can be defined in
a single TMR, it is not recommended to use a large number of managed nodes.
Experience has shown that 150 managed nodes is the maximum number to use
with Spoke TMRs. In this context, each outlet will have a managed node
installed. Keeping this advice in mind, a region should not span more than 150
outlets. This implies that eight to ten SpokeTMR environments will be required to
Chapter 3. The Outlet Systems Management Solution Architecture
45
manage 1000 outlets. If the company outgrows that number, Outlet Inc. can
guarantee the scalability by increasing the number Spoke TMRs.
Tivoli managed node
A managed node is a dedicated system with a supporting role in the TMR.
Managed nodes are used to host special functions such as repeater, gateway,
TEC Server, or the software library, on dedicated systems in order to distribute
the TMR workload among several systems. One managed node can assume
several functions. The main considerations for using managed nodes are
capacity and performance issues.
Tivoli gateway
One gateway must be established in every region and every outlet. The gateway
is a managed node configured to accept communication requests from the
managed systems, endpoints, and forward requests and responses to the TMR.
In addition, all gateways will be configured as both repeaters and collectors in
order to allow us to control and optimize the management traffic (MDist and
MCollect) to and from the TMR servers.
Tivoli endpoint
The endpoint enables a distributed system in a region or an outlet to be managed
from a central site. Endpoints are installed on every system of the outlet
infrastructure that will be managed from the central location, and will connect to
the local gateway.
To facilitate management of the Tivoli Management Infrastructure itself, all
servers related to all TMRs will have endpoints installed, even if they also
assume the role of a managed node.
Source host
The Source host is a dedicated managed node in the Hub TMR used to store all
the software packages and code libraries to be distributed to the outlets with the
Software Distribution component of Tivoli Configuration Manager. For
performance and capacity reasons, the source host should be implemented on a
dedicated managed node.
TEC server
The Tivoli Enterprise Console (TEC) server is used for reception and handling of
all events in the outlet infrastructure. The TEC server will receive events from
most of the Tivoli components that will be installed. However, IBM Tivoli
Monitoring and related components will be the main contributor. Once these
events have been received, they can be collected, correlated and can have rules
applied to them to allow for automation. This automation can be as simple as
46
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
removing duplicate events or running elaborate diagnosis programs, should the
same event occur multiple times within a given time period.
RDBMS server
The database server is used to host all the databases used by the Tivoli
infrastructure to keep track of various configuration and status information.
Because the Tivoli Framework allows these databases to exist outside the TME
itself, there is no requirement for establishing the database server as a managed
node. However, you should install an endpoint to allow for monitoring of the
system.
Console server
This server is used to facilitate the WebSphere Application Server based
consoles in the Tivoli environment. Similar to the rdbms server, the console
server does not have to be implemented on a managed node. In the Outlet
Systems Management Solution, the main function of the console server is to host
the ITM Web Health Console.
TMTP server
The TMTP server is a dedicated server system that performs all the
management, control, and coordination functions for monitoring application
availability and transaction performance. Because the Tivoli Monitoring for
Transaction Performance architecture is detached from the TME, this server
does not need to be implemented on a managed node.
Refer to 3.4.1, “Suggested Tivoli hardware requirements” on page 62 and 4.1,
“The Outlet Systems Management Solution” on page 130 for detailed information
about hardware and software configurations, as well as functional placement
used in the Outlet Systems Management Solution.
3.2.2 TMR connections within Outlet Inc.
In the Outlet Systems Management Solution, the management functions will be
performed at the Hub TMR level.
By creating the TMR connection between each of the Spoke TMRs and the
controlling Hub TMR, most resources can be shared securely and efficiently.
Once the Hub TMR is aware of the resources contained within a Spoke TMR it
can treat these as though they are part of its own Tivoli Management
Environment, thus enabling normal management functions such as software
distributions, inventory scans, and so on to be performed.
Chapter 3. The Outlet Systems Management Solution Architecture
47
To make the HubTMR aware of the resources within the Spoke TMRs, each
Spoke TMR will have a simple encryption level, two-way connection to the Hub
TMR.
These are the resources that will be exchanged between TMRs:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
Administrator
Endpoint
Endpoint Manager
Gateway
Managed Node
Policy Region
Profile Manager
Repeater
Top Level Policy Region
This list is subject to change as additional products are installed and more
resources are included along with these products.
Connecting TMRs implies an initial exchange and periodic update of resources
contained in the TMRs. The update process, initiated through the wupdate
command or Desktop is a pull operation. The TMR server that needs to be
updated requests the information and modifies its local name registry. When a
new resource is created in a local database, it is not automatically pushed to
other interconnected TMRs. Therefore, it is important to update the resources on
a regular basis.
The frequency should be set according to the stability, or frequency of updates,
of the Tivoli environment. If the environment is stable, then updating the
resources once a day might be sufficient.
Updating the resources from different TMRs at the same time is not
recommended. Therefore, the operation should be serialized across the TMRs.
For more information about TMR connections, refer to the Tivoli Planning for
Deployment Guide which is available online at the Tivoli Information Center Web
site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
From the welcome page, navigate to Management Framework → Planning for
Deployment Guide.
3.2.3 Tivoli gateway architecture
Within the Outlet Inc. Tivoli environment there will be thousands of endpoints
located throughout the geographies in which Outlet Inc. is represented. Each of
48
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
these endpoints will require some element of management, whether receiving
software distributions or being controlled as part of problem determination or
proactive monitoring. With these criteria, we can introduce the concept of
gateways into discussion. Gateways assume some of the function of a TMR
server.
By delegating a share of the management processes to gateways, the TMR
servers are freed to service other managed resources. The endpoint gateways in
Outlet Inc. will perform all communications with assigned endpoints without
requiring additional communications with the TMR server. The gateway invokes
endpoint methods on the endpoints or runs gateway methods for the endpoint.
The Tivoli Gateway functionality can be installed onto any system that meets the
basic criteria for a Tivoli managed node. Installing Tivoli Gateway onto existing
systems is both cost-effective and time saving, although some problems could
arise with badly installed systems or in managing a system that already has other
functionality. Therefore, it is necessary to be careful of the load implications on
an existing system.
Gateway positioning within Outlet Inc.
Outlet Inc. should install a Tivoli Gateway in each outlet, more specifically on
each outlet’s application servers. Outlet Inc. will implement these servers to
support and deploy the solution with the appropriate hardware and software
configuration.
The gateways within Outlet Inc. will be positioned by applying a specific set of
rules. These rules help to determine the best strategic positions for the gateways
to best use the network, locations, and Outlet Inc. infrastructure:
򐂰 The number of endpoints supported by a gateway within Outlet Inc. will be up
to 500.
򐂰 Suboutlets must have the same management functionalities as the primary or
regional outlets.
򐂰 The gateway will be mapped to the outlet application server. In large outlets,
of more than 80 clients, Outlet Inc. should consider implementing a dedicated
gateway to improve performances at application and management levels.
3.3 Logical Tivoli architecture for Outlet Inc.
This section describes the logical architecture of the Tivoli solution in Outlet Inc.
Figure 3-4 on page 50 and Figure 3-5 on page 51 show the logical configuration
of TMR Hub and TMR Spoke regions.
Chapter 3. The Outlet Systems Management Solution Architecture
49
Policy regions for Hub and Spoke TMRs are shown. For each application, there
is a Policy Region in the TMR Hub Region and only the Inventory Profiles belong
to both the Hub and Spoke TMRs.
Figure 3-4 Logical Configuration of TMR Hub
50
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figure 3-5 Logical Configuration of TMR Spokes
The Spoke TMRs’ policy regions and profile managers, containing subscribers
and Inventory profiles, will be exchanged with the Hub TMR.
A subscription policy region should be defined for each Spoke TMR.
The application policy regions and profile manager hierarchy should be created
in the Hub TMR. The subscriber to the application profile managers is the profile
manager in the subscriber policy region defined in the Spoke TMRs. This allows
the Hub TMR to be the central point of operations for application functions.
Access to the policy regions and resources will be given to the Tivoli
Administrators, according to their roles.
The Hub TMR will contain the following policy regions and collections:
򐂰 Default Hub TMR Policy Region
򐂰 Application policy region:
– Inventory policy region:
• Query Library
– Software distribution policy region:
• Software packages
– Monitoring policy region:
• Monitoring profiles
򐂰 Spoke TMRs’ Collection:
Chapter 3. The Outlet Systems Management Solution Architecture
51
–
–
–
–
Spoke1 Policy Region
Spoke2 Policy Region
Spoke3 Policy Region
SpokeN Policy Region
•
Profile managers for subscribers, including servers, workstations, and
groups of subscribers1
•
Inventory Policy Subregion including inventory profile manager and
profiles for hardware and software scan
Experience has shown that it is a good approach not to have more than 500
subscribers in a single profile manager, especially for organizational and control
issues.
For performance reasons, a good practice is to distribute inventory profiles from
the profile manager of the Spoke TMRs. In this way, the RIM object of each
Spoke TMR can access the RDBMS in parallel. In addition, this would avoid
having the RIM object in the Hub TMR perform all the database updates and,
possibly, become a bottleneck.
For each Spoke TMR, we will create a hierarchy of profile managers for
subscribers, as shown in Figure 3-6.
The profile managers will be populated during endpoint registration.
Figure 3-6 Sample profile manager hierarchy
1
Several profile managers of subscribers will be defined in order to reflect the logical criteria of
grouping the machines (machine names which begin with the same two characters, managed nodes,
endpoints, and so forth).
52
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
The purposes of the profile managers shown in Figure 3-6 are:
򐂰 subs_<Group n>_<SpokeTMR>_pm contains all resources (managed nodes and
endpoints) divided in groups of about 50 outlets each.
򐂰 subs_<Server n>_<SpokeTMR>_pm contains all the managed nodes.
򐂰 subs_<Endpoints n>_SpokeTMR>_pm contains all the endpoints.
When, for example, a monitoring profile needs to be distributed to all servers
belonging to <SpokeTMR>, you can subscribe the subs_<Server
n>_<SpokeTMR>_pm profile managers to the profile.
When any profile is distributed, all targets that are subscribed to them receive the
profile.
All profile distributions should be performed through the profile manager
hierarchy to achieve better performance and scalability.
3.3.1 Administering the Tivoli Management Environment
A Tivoli administrator is a person with a network user account assigned to
manage one or more policy regions in the Tivoli environment. Tivoli
administrators can perform system management tasks and manage policy
regions in one or more networks. You can delegate system management tasks to
administrators by:
򐂰
򐂰
򐂰
򐂰
Assigning authorization roles
Copying policy regions between Desktops
Moving policy regions onto an administrator’s Desktop
Moving or copying system resources between policy regions
An account for the initial Tivoli administrator, or root administrator, is created
during the installation of the Tivoli Framework. The installation program also
creates a new root administrator when you install each subsequent TMR. The
root administrator has root authority on UNIX® machines and administrator
privileges on Windows machines. After the Framework is installed, the root
administrator can create other Tivoli administrators and grant them authorization
roles in policy regions. Based on these roles, administrators can perform
assigned system management tasks without being root administrators or
requiring access to the superuser UNIX password or the Windows administrator
password.
This ability to compartmentalize delegated authority gives senior administrative
personnel complete control over who can perform specified operations on
different sets of resources. The root administrator can also grant root authority to
subordinate Tivoli administrators. TMRs can have multiple root administrators.
Chapter 3. The Outlet Systems Management Solution Architecture
53
See the wauthadmin command in the Tivoli Framework Reference Manual for
information about changing and displaying root administrators.
Each administrator has his or her own Tivoli Desktop. When the administrator
logs in to Tivoli, the Desktop associated with that login is displayed. The Desktop
displays the policy regions and resources that the administrator can manage and
the Bulletin Board icon from which the administrator can read messages. The
Desktop can also include the Administrator collection icon and the Tivoli
Scheduler.
Authorization roles
After the Framework is installed, the root administrator can add other Tivoli
administrators. When you create an administrator, you select which policy
regions and other resources the administrator will manage and what
authorization roles the administrator will have for each resource. The
authorization role an administrator has for a resource determines what
management tasks an administrator can perform on the resource. Authorization
roles provide a set of privileges to Tivoli resources, or objects.
Authorization roles are mutually exclusive, not hierarchical. Each role provides its
own set of privileges, but a role does not provide the privileges of any other role.
For example, some tasks require the administrator authorization role. An
administrator with the super role is not able to perform these tasks unless the
administrator also has the admin role.
An administrator with super or senior roles in the Administrator collection can
create other administrators and assign them authorization roles.
Examples of Tivoli Administrators
The following sections show some examples of Tivoli administrators that could
be created in our Outlet Inc. environment.
Tivoli TMR Administrator
Created with a name of TMR_Admin, this administrator has the role of ultimate
manager of the Tivoli environment. This role has all the privileges needed to
perform any function within Tivoli and, by extension, on all managed systems.
Care should be taken that only a very limited number of users are given this level
of access, and that these users are knowledgeable in the use of Tivoli. This role
is very powerful and much damage can be done in very little time. At least one
user and one backup user should be assigned this role.
The TMR Administrator will be assigned all roles on a TMR-wide basis:
54
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
Super
Senior
Admin
User
Install_client, install_product
Backup
Restore
Because these roles will be inherited by all resources within the TMR, this
administrator has unlimited access. The TMR Administrator is assigned to all
notice groups.
Note: Tivoli authenticates its users based on their ID and the machine from
which they log in, then permits access on this basis. It is possible for a UNIX
administrator to su to a User ID that has Senior Tivoli privileges and gain
access to Tivoli. It is recommended that Outlet Inc. limit root access to the
TMR Server to a select group of users. An equally effective approach would
be to limit root access on the TMR server and only allow login IDs for Tivoli
super administrators to this server. The super ID could then be mapped to
USER ID@TMR server and permit each Senior Tivoli Administrator his or her
own ID.
Tivoli resource administrators
The resource administrators performs system management functions within the
Tivoli Management Environment. This administrator role will be allowed to:
򐂰
򐂰
򐂰
򐂰
򐂰
Manage specific policy regions
Add managed nodes
Develop and schedule tasks
Create and distribute profiles
Manage notices
Tivoli resource administrators are excluded from tasks that modify the TMR, such
as installing Tivoli products, and patches to the Tivoli software or other TMR
specific maintenance.
Tivoli user administrators
The User_Admin role provides limited read-only access within the TMR. This
administrator should only be allowed to browse information and is not intended,
despite the name, to perform any administrative functions for users.
Access and authority is limited to those areas needed to perform only those job
functions within Tivoli. Primarily, User_Admin access will be limited to being able
to display the TEC console, Mdist console, and read notices.
Chapter 3. The Outlet Systems Management Solution Architecture
55
Roles
As additional subprojects are implemented within the Outlet Inc. environment,
additional groups will require controlled access to Tivoli. Therefore, additional
roles might have to be developed, and existing roles might have to be modified to
include the additional needed functions. As new roles are defined, or old ones
are modified, this should be documented. Care needs to be taken that all existing
administrators are modified to match the newer definitions. As a
recommendation, it is easiest to develop all roles using scripts that can be
modified, then reexecuted to develop new administrators.
General guidelines for roles
򐂰 All roles map across TMRs, except for the super which maps to user.
򐂰 Authorization roles are mutually exclusive and not hierarchical. For example,
you do not inherit user authorization from super. You must be assigned both.
򐂰 Authorization roles are inherited from TMR to policy region, from parent policy
region to subordinate policy region, and from policy region to objects
contained within a resource. Authorization roles provide a set of privileges to
the TME resources or objects contained in the resource.
򐂰 An administration role applies to all objects contained in a resource.
򐂰 Administrators can only assign roles that are equal or subordinate to the ones
they possess.
򐂰 TEC event groups are assigned roles on a console (user) by console basis.
To acknowledge or close an event, the user and admin roles must be
assigned to the event group.
򐂰 Keep models as high-level as possible and still maintain the needed
restrictions and safeguards. For example, if you can assign a user at the TMR
level, assign at this level and not below.
򐂰 Create typical administrators and replicate from there.
򐂰 When modifications have to be made, make them to the model and
regenerate the users from there.
򐂰 Develop scripts to generate the model administrators and then reuse them to
create the individual administrators.
General administrator recommendations
For an organization which has a large number of multidisciplined administrators
and heterogeneous system resources such as Outlet Inc., the roles assigned to
each administrator must be clearly defined in accordance with the job
responsibility of the specific administrator and the administrative policies of the
organization. In line with the these policies, the roles assigned to administrators
must allow them access to the resources for performing their normal
56
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
administrative tasks, but restrict them from gaining access to resources for which
they should not have access.
To match the administrators’ roles to their administrative needs, it is important to
understand the tasks and resources that administrators will need to manage.
From these, we will determine the roles that specific administrators should be
assigned.
In an organization like Outlet Inc. it is more than likely that there will be a large
number of local administrators and, accordingly, a large number of Tivoli
administrators.
This number affects the performance of the TMR server because an object is
generated within the Tivoli database each time an administrator is created.
Where an operation requires cross-referencing of database objects against each
administrator in the TMR, depending on the processing power of the TMR server,
these Tivoli operations would require a longer period of time to execute. Thus,
even if the system hosting the TMR server in Outlet Inc. seems to have a good
processing power, you should be careful defining a large number of Tivoli
administrators. A large number of concurrent Tivoli Administrators with Tivoli
Desktops open will cause a large amount of daemons or processes, to be
spawned, therefore the performance could decrease.
Avoid using default root user
A default root user should be created for each TMR server that is installed. This
default root user will have full access to all resources within the TMR. It would
have super, senior, admin, user, install_client, and install_product TMR roles.
As a precaution, this default administrator account should not be used to perform
any day-to-day operations in a TMR. The primary reasons for this are:
򐂰 There is no way of keeping an audit on who had been performing operations
using this administrator account.
򐂰 This account has full access on all resources within a TMR. Some tasks that
have to be performed using this administrator are not reversible. They also
cannot be undone by another user.
Single administrator for multiple users
It is possible to create single administrator for multiple users performing similar
jobs; for example, release management support personnel whose job function
might entail distributing software to remote servers. In this case they would
require similar authority on resources.
Using the Set Login → Add Login Name function of Tivoli administrator, multiple
users can log on as the same administrator and use its desktop to perform their
Chapter 3. The Outlet Systems Management Solution Architecture
57
administrative tasks. When a user needs to be added or removed from specific
job roles, simply add or remove entries to the Current login names,
Administrator →Edit Logins, list for the specific Tivoli administrator.
Having multiple users assigned to one administrator does have its drawbacks.
First, only one TEC console can be opened for a single administrator and its
Desktop, which means only one user, can have the TEC console opened at a
time. Second, the subscription notices will be shared also. This means if the user
has closed a notice after it has been read, other users will not be able to read the
same notice.
Therefore, the decision on whether to use one user for one administrator or
multiple users for one administrator depends on the needs and requirements for
users of the same group.
The following questions can help you understand whether to use multiple users
for one administrator or have one use for each administrator:
򐂰 Do users need to read notices from the Tivoli Desktops?
򐂰 If users will be reading notices from the Tivoli Desktop, are missed notices an
issue for the user?
򐂰 Do users’ job descriptions require them to monitor events through the TEC
console?
򐂰 If users are monitoring events through the TEC console, do these users all
have to have the TEC console opened on their workstation?
If the answer to all of the questions above is no, then multiple users for one
administrator be used. However, if the answer to any of these questions is yes,
then one user for each administrator should be used.
Tivoli Dsktop considerations
Usage level of the administrator desktop should be carefully considered in large
environments where a large number of administrators are expected to use Tivoli.
For every open window in the Tivoli Desktop, the TMR opens a new network
thread (TCP/IP connection). The use of the navigator is recommended: navigator
reduces the number of open windows.
An example of network traffic generated by the Tivoli Desktop is 595 KB as a
result of opening a Desktop and three policy regions, one of which contains 1000
objects.
Tests performed in a laboratory environment and IBM client experiences suggest
starting with no more than 30 concurrent active Desktops, regardless of how the
Desktops are to be used: TEC consoles, remote control, and so forth.
58
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Particularly for the TEC consoles, the above consideration is affected by the
following factors we have not yet examined:
򐂰 Number of events received per second
򐂰 Number of events maintained in the database
򐂰 Number of event groups and filters configured
Outlet Inc. scenario
Outlet Inc. will have various classes of operators who will require access to the
Tivoli environment. Operators will have access through the Tivoli Desktop. Some
of the typical operators requiring access are:
򐂰
򐂰
򐂰
򐂰
򐂰
Help desk operators (first degree support level)
Software distribution administrators
Technical support”
Linux support
Outlet Solution administrators
For each of those administrators, two specific Linux users are defined on TMRs.
Outlet Solution administrators are the only ones whose logins, the Linux user and
password, are defined in the spokeTMR. All other users are defined on HubTMR
only, and in the current login name on Tivoli administrator definition. The
HubTMR managed node is specified (LoginName@HubTMR).
Example scenario
The following figure shows a hypothetical organization of Tivoli Desktops
mapped to Outlet Inc. requirements:
Chapter 3. The Outlet Systems Management Solution Architecture
59
Figure 3-7 Tivoli Desktops logical configuration
In each of the four groups in Figure 3-7, the users in each group perform similar
jobs. We can set up multiple users for one administrator, ensuring that all users
within a group log in to the same Tivoli Desktop with the same Tivoli
administrator.
It is recommended that you have a low number of TEC consoles opened
simultaneously because there is a high rate of information exchange between
the Event Console, the Event Server, and the database.
3.3.2 Tivoli naming conventions for Outlet Inc.
The Tivoli Management Environment is based on an object-orientated data
model. As such, each instance of an object in a TMR must be uniquely
identifiable. Past experience has shown us that it is useful when examining
traces or log files to immediately be able to determine what type of object is
being examined.
60
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Within Outlet Inc., there will be many Tivoli products being implemented in many
parallel projects. This means producing a unique, accurate, flexible and
meaningful naming convention is critical.
This section provides a categorization of all resources that will be implemented
within the Outlet Inc. environment.
Table 3-1 is an easy reference table for all object types and naming conventions:
Table 3-1 Suggested naming conventions for Tivoli objects
Resources
Name Conventions
Policy Region
name_TMR_pr
Profile Managers
type_name_TMR_pm
Profile Manager Subscribers
subs_name_TMR_pm
Dataless Profile Manager
Subscribers
subs_name_TMR_pm
Profiles
type_name_TMR_prf
Gateways
gw_hostname (S0nnnntt)
Managed Nodes
hostname (S0nnnntt)
Endpoints
hostname (W0nnnntt)
Task Library’s
name_TMR_tl
Tasks
name_TMR_tsk
TEC Console
name_tec
TEC Event Server
EventServer (Default for TMR)
File Packages
swd_name_TMR_fp
Administrators
name_TMR_adm
Jobs
name_TMR_job
Indicator Collections
name_TMR_ic
Collections
name_TMR_col
Type can be one of the following:
򐂰 swd: software distribution
򐂰 inv: inventory
򐂰 dm: monitoring
Chapter 3. The Outlet Systems Management Solution Architecture
61
򐂰 subs: list of subscribers
򐂰 name: name of the TMR, such as Hub or Spoke TMRs, for example:
– hub
– spoke1
– spoke2
– spoke10
3.4 Setup and configuration planning
The purpose of this section is to provide comprehensive and detailed set-up and
configuration planning information about hardware and software, the behavior
and management of endpoints within the environment, and optimized distribution
of data and packages.
With this information, you can get a clear understanding of how the critical
systems are configured and how the environment will operate and need to be set
up for optimal performance and stability.
3.4.1 Suggested Tivoli hardware requirements
The following hardware requirements are for the gateway and endpoint systems
in the Outlet Systems Management Solution. Remember that the Tivoli Gateway
component will be installed and configured on a dedicated server in every outlet,
while the endpoint component will be installed on all servers in the Remote Store
infrastructure that will be managed.
The Tivoli Gateway must be installed on a managed node. The managed node
can be considered a distributed server, taking on the responsibilities of the TMR
server. In the case of the gateway, the scope of responsibilities relates to
communicating with the local endpoints.
In the following sections we highlight both Tivoli Release Notes and suggested
requirements, based on experiences from other large customers similar to Outlet
Inc. In both cases, these requirements only refer to the Tivoli applications; they
do not include other considerations about concurrent applications executing on
the same systems.
TMR Server and managed nodes hardware requirements
Table 3-3 outlines the hardware requirements for the central Tivoli systems TMR
Servers and Managed Nodes.
62
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Table 3-2 Hardware requirements for TMR Servers and managed nodes
Environment
Release Notes
Suggested Values
TMR Servers
Pentium® Processor
Pentium III Processor
256-512 MB RAM
512 MB RAM
200 MB Hard Disk available
(without depot)
300MB Hard Disk available
Pentium Processor
Pentium III Processor
256-512 MB RAM or more
512 MB RAM
200 MB Hard Disk available
(without depot)
512 - 2 GB Hard Disk or more
available (with depot)
Managed nodes
Note: Tivoli can take full advantage of multiprocessor machines. The code
can run effectively in parallel.
In Outlet Inc. environment, the central managed nodes assume different roles,
and, thus, the hardware requirements will vary. The suggested configurations
apply to the common TMR Server and managed node, with the note that
systems that take active part in the software distribution process, the source host
and active repeaters, need extra disk space for holding software packages as
they are moved to the endpoints.
For specific details on requirements for supporting servers such as console and
rdbma servers, consult the release nodes for the specific components.
Gateway hardware requirements
Table 3-3 outlines the hardware requirements for the Tivoli Gateways.
Table 3-3 Hardware requirements for gateways
Environment
Release Notes
Suggested Values
Small / Medium
Outlet (up to 80
Clients)
Pentium Processor
Pentium III Processor
64 MB RAM
128 MB RAM
200 MB Hard Disk available
(without depot)
1 GB Hard Disk available (with
depot)
Chapter 3. The Outlet Systems Management Solution Architecture
63
Environment
Release Notes
Suggested Values
Regions and Large
Outlet (more than
80 Clients)
Pentium Processor
Pentium III Processor
64 MB RAM or more
256 MB RAM
200 MB Hard Disk available
(without depot)
1,5 GB Hard Disk or more
available (with depot)
In Outlet Inc. environment, Application Server and Management Server
(gateway) are both on the same system. In large outlets, we suggest taking into
consideration, the possibility of having a dedicated gateway to decrease the
processor and network workload.
Endpoint hardware requirements
Table 3-4 outlines the hardware requirements for the Tivoli endpoints.
Table 3-4 Hardware requirements for endpoint
Small / Medium /
Large Outlet
Release Notes
Suggested Values
Pentium Processor
Pentium III Processor
32 MB RAM
32 MB RAM or more
30 MB Hard Disk available
(cache included)
30 MB Hard Disk available or
more (cache included)
Note: RAM value is considered as an absolute value, not a sum of the values.
3.4.2 Tivoli repeater architecture
Tivoli provides the Multiplexed Distribution (MDist) service to enable
synchronous distributions of large amounts of data to multiple enterprise targets.
The MDist service is used by a number of Tivoli profile-based applications, such
as Tivoli Software Distribution, to maximize data throughput across large,
complex networks. During a profile distribution to multiple targets, MDist sets up
a distribution tree of communication channels from the source host to repeaters
to targets. MDist limits its own use of the network, as configured through repeater
parameters, to help prevent intense network activity that can stress network
bandwidth for periods of time.
The following section covers the proposed architecture, tuning parameters and
configuration for repeaters within the Outlet Inc. Tivoli Management
Environment.
64
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
By default, the TMR server acts as the repeater distribution server for all targets
in the TMR.
Within the HubTMR there will also be a software repository used to store all
applications ready for distribution, which will also be a source for MDist
distributions.
It is proposed that within the Outlet Inc. environment, both Hub and Spoke TMRs
will be defined as repeaters. Every Spoke TMR will be configured to distribute
packages to 40 outlets in parallel. The gateway at the outlet level, both in primary
regions and subsequent outlets, will themselves be configured as a repeaters for
the endpoint below them.
It is important to read and understand the gateway architecture and MDist
principles, before reading the rest of the MDist architecture section.
Repeater guidelines
Whether your repeater sites are gateways or managed nodes, knowledge of the
organization’s underlying network topology and network performance
characteristics is required for proper configuration of repeater sites.
The following selection guidelines apply to most environments:
򐂰 If you have a slow network link, such as over subnets, install a repeater site
on each side of the connection.
򐂰 If a machine is often a source client for software distribution, make it a
repeater to enhance performance.
򐂰 If a repeater range contains too many clients in multiple subnets, you can
improve performance by adding a repeater to each subnet.
򐂰 Do not use an unreliable client as a repeater site.
These guidelines can be applied in the future when selecting where repeater
sites in Outlet Inc. should be positioned.
Each repeater can be configured and tuned to match these guidelines using the
wrpt command from a command line. The next section describes the parameters
and gives a brief explanation and their use in the Tivoli management
Environment.
Repeater parameters and settings
The Tivoli Management Framework provides essentially two implementations of
Multiplexed Distributions, MDist. These are often referred to as MDist1 and
MDist2, where MDist2 provides better efficiency and throughput and more
detailed tuning options. As such, MDist2 is the extended version of MDist1.
Chapter 3. The Outlet Systems Management Solution Architecture
65
For both implementations of MDist, the wrpt command is used to configure and
tune the repeater setup. MDist2 extensions are controlled via the wmdist
command.
MDist1
Following are the repeater parameters for MDist1.
򐂰 Network Load (net_load)
The net_load parameter sets the ceiling in the network load in kilobits per
second (kbps/sec), that each transfer can add to the repeater site’s network.
If you set this parameter to 50, each transfer will limit itself to writing no more
than 50 Kb in a one second period. There is no connection between
independent transfers. As a result, if four transfers are started by four different
applications at the same time, the total network load could be four times the
set value.
Conversely, if the repeater site has two network interfaces, the load
contributed to each network could be half the given value.
You can specify a negative value for net_load to enable this parameter for
each target system, rather than for the entire distribution. For example, if you
set net_load to -25, data transfers to each target are limited to writing no more
than 25 Kb/sec.
򐂰 Network Spacing (net_spacing)
The net_spacing parameter, expressed in milliseconds, specifies a delay to
insert between each write to the network. For most networks, this value
should be zero, indicating no delay. If network monitoring shows that MDist
transfers are causing abnormally high collision rates, then the network
spacing parameter can be used to more evenly space when the writes occur.
Under default settings, using the wrpt -t command to list repeater settings
does not show a value for the net_spacing parameter. A value for
net_spacing is only displayed if you change its default configuration for a
repeater.
򐂰 High-level TCP Time-out (stat_intv)
The stat_intv parameter specifies the time-out value for managed nodes and
endpoints, after which a blocked connection will be considered dead. Some
systems with unreliable networks experience bottlenecks that go undetected
by the operating system TCP/IP stack. The high-level TCP time-out forces a
time-out error on these connections so that the distribution can proceed.
򐂰 Maximum Simultaneous Connections (max_conn)
The max_conn parameter sets the maximum number of TCP connections
that can be open at the same time. Theoretically, a repeater can distribute in
parallel to any number of target nodes. This parameter sets a limit on the
66
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
maximum number of connections; therefore, the repeater can distribute in
parallel to subsets of the clients in its range. This prevents the network
connections from exhausting system limits.
If the number of clients in the range is three times the setting of the maximum
connections, then there will be three blocks of parallel transfers, each of
maximum connections. If the number of target clients is greater than the
number of maximum connections, then the repeater must store all of the data
so that it can be sent to the remaining targets after the initial set completes.
The repeater stores the data in memory, up to the value specified for the
mem_max parameter. If the data exceeds mem_max, then the repeater
stores the remainder on disk, up to the value specified for the disk_max
parameter. This means that
if mem_max plus disk_max is not large enough to hold the largest possible
distribution, then you need to configure additional repeater managers.
򐂰 Maximum Memory (mem_max) and Maximum Disk (disk_max)
The mem_max and disk_max parameters specify values for maximum
amounts of memory and disk space system resources that can be allotted to
a repeater during distribution. If target clients accept data at the same rate
that the repeater sends data, the repeater consumes very little memory. If the
repeater has one slow target, the repeater attempts to keep the data flowing
to the fast targets. To service both slow and fast targets, the repeater must
temporarily save data for the slow targets.
The repeater first consumes up to the maximum amount of memory. When
the maximum amount memory has been used, the repeater starts paging
data to disk. The repeater will consume up to the maximum disk space
specified in disk_max. When both the memory and disk limits are reached,
the repeater stops receiving data. The stop appears as a slow target to the
parent repeater.
Stops can ripple all the way up the distribution hierarchy to the source, which
then must wait.
We suggest setting the sum of these parameters at least equal to the
maximum size of the package to distribute on every repeater interested in a
distribution of that packages, that is HUB TMR, Spoke TMR, outlet gateway.
򐂰 Paging Space, Disk Usage Rate, and Disk Delays
The disk_dir, disk_hiwat, and disk_time parameters specify additional
parameters about temporary paging space, speed with which disk space is
consumed, and time delays between disk allocations. When a repeater
exhausts the maximum memory allocated and starts paging to disk, it slows
down when it crosses the high-water disk level. Above this threshold, it will
only consume pages of disk space at a specified interval. The paging file is
created in an indicated directory.
Chapter 3. The Outlet Systems Management Solution Architecture
67
Table 3-5 outlines the recommended MDist1 values for the various repeater
parameters for the different types of repeaters in the Outlet environment:
Table 3-5 Recommended MDist1 repeater settings
Settings
Parameter
HubTMR
SpokeTMR
Gateway
net_load
Default
-5 KB/s
500 KB/s
net_spacing
Default
Default
Default
stat_intv
Default
Default
Default
max_conn
40
40
20
mem_max
50000
50000
50000
disk_max
100000
100000
100000
disk_dir
/Hostname/disk_dir
/Hostname/disk_dir
/Hostname/disk_dir
disk_hiwait
80000
80000
80000
disk_time
Default
Default
Default
MDist2
Tivoli Framework 3.7 introduces the MDist2, an evolution of MDist1 that remains
unchanged. MDist2 enables control of the total amount of resources used by a
repeater. This makes distributing data fast and efficient, improving performance
and throughput. This section describes how to configure repeater parameters for
MDist2.
You can set the network load, target network load, number of priority
connections, packet size, debug level, maximum memory, and maximum disk
space. You also can set intervals for how often the database is updated and the
frequency and length of time that a repeater retries unavailable or interrupted
targets.
MDist1 and MDist2 share the same repeater hierarchy but have separate
repeater configuration settings:
򐂰 MDist1 parameters are normally for distribution.
򐂰 MDist2 parameters are normally for the repeater. These parameters allows
control of total resources during simultaneous distributions
Repeater settings are set with the wmdist command:
wmdist –s repeater_name [key=value]
68
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Following are the main repeater parameters for MDist2.
򐂰 Network Load and Target Network Load (net_load)
Use the net_load parameter to specify the maximum amount of network
bandwidth that a repeater is allowed to allocate. This value is shared among
all active connections. For example, if there are 10 open connections, with
net_load=500 (default value), each connection receives 50 KBps. MDist2 can
use these 10 open connections for one or more distributions.
The target_netload parameter, used in conjunction with net_load, allows you
to specify the maximum amount of network bandwidth that a repeater can
send to an individual target. For example, suppose net_load is 500 KBps and
target_netload is 100 KBps (default value). If there is only one connection, the
target_netload value takes effect and limits the connection to 100 KBps.
However, if there are 10 connections, the net_load value takes precedence
and limits each connection to 50 KBps. Because 50KBps is less than the
target_netload of 100KBps, this value also satisfies the 100 KBps value for
target_netload.
Both net_load and target_netload can be active at the same time. This is
different from the MDist service’s negative net_load value, which offers no
control on the total bandwidth.
򐂰 Time-out Values (send_timeout)
Use the send_timeout parameter to set the time-out between network writes.
That is, a target is allowed b seconds to receive a packet in the network. If a
timeout occurs, the distribution remains in the repeater queue and attempts to
resend the distribution as set by conn_retry_interval. The default value is 300
seconds. This parameter replaces the gateway session_timeout parameter
used by MDist.
In comparison, the execute_timeout parameter is the time-out between when
all the data is sent and the method returns. For example, applications can run
scripts after receiving data, but before returning results to the repeater. The
default value is 600 seconds. This parameter replaces the final_timeout
parameter used by MDist.
򐂰 Maximum Priority Connections
Use the max_sessions_high, max_sessions_medium, and
max_sessions_low parameters to control the number of connections that the
repeater can open for each priority (high, medium, or low). If no connections
are available for a given priority, the repeater tries to borrow a connection
from a lower priority. For example, if max_session_high=3 and all three
high-priority connections are in use, the repeater will try to use an available
lower-priority connection.
The sum of high, medium, and low connections is the total number of
available connections.
Chapter 3. The Outlet Systems Management Solution Architecture
69
Repeater queues operate on a first in, first out (FIFO) basis. A repeater
assigns a distribution to its queue based on which distribution arrives first, not
when the distribution was submitted. For example, suppose that a medium
priority distribution is using all the medium and low priority connections. If a
high priority distribution arrives, and all high priority connections are in use,
the repeater can use lower-priority connections for this distribution as soon as
a medium or low priority connection finishes. The original medium priority
distribution is blocked until the high priority distribution has finished using the
medium and low priority connections.
These parameters replace the wrpt max_conn command used by MDist.
򐂰 Maximum Memory (mem_max) and Disk Space (disk_max)
Use the disk_max and mem_max parameters to specify the amount of
memory and disk space allocated to the repeater depot. These values are
shared among distributions, unlike the MDist wrpt keyword parameters,
which are targeted per distribution. The default size for disk_max is 500 MB.
This is the total size of the depot. The depot contains both permanent and
temporary distributions. All simultaneous distributions must fit within the depot
space.
If the disk_max value equals zero, no limit is enforced. The depot cannot
exceed the size of the disk. Every distribution flowing through a repeater is
stored at least temporarily in the depot. The depot must be large enough to
hold the largest distribution that you expect to distribute.
The mem_max parameter specifies the amount of memory used to buffer
data being sent to targets. This improves performance by reducing the
number of disk accesses to the depot. The memory is shared among all
active distributions. The default size for mem_max is 64 MB. This is a
memory cache used for all active distributions.
These parameters replace the wrpt mem_max and wrpt disk_max commands
used by MDist.
򐂰 Status Notification Interval (notify_interval)
Use the notify_interval parameter to specify the frequency in minutes a
repeater reports status. As targets finish, their results are buffered by the
repeater. When the length of time set by notify_interval has elapsed or all the
targets of this distribution have finished, the results are sent to the application
using MDist2. In turn, the application notifies the distribution manager to
update the database. The notify_interval parameter default value is 30,
meaning that each repeater sends status every 30 minutes. Status
information is sent to the database infrequently to cut down on network traffic
and overhead on the TMR server.
򐂰 Connection Retry Interval (conn-retry)
70
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
The conn_retry_interval parameter sets the frequency in seconds that a
repeater retries unavailable or interrupted targets. The default value is 900
seconds. Between a gateway and its endpoints, the retry mechanism is to
retry the number of seconds set by conn_retry_interval up to the number of
seconds set by retry ep_cutoff. Between repeaters, the retry mechanism is to
retry the number of seconds set by conn_retry_interval until the distribution’s
deadline is reached. Because repeaters do not log in to each other, MDist2
performs an explicit retry to know when an unreachable repeater becomes
available.
򐂰 Retry Endpoint Cutoff Interval (retry_ep_cutoff)
Use the retry_ep_cutoff parameter to specify the time in seconds that you
want the repeater to continue retrying an unavailable or interrupted endpoint.
A repeater retries unavailable or interrupted targets until the distribution’s
deadline is reached. For example, the repeater only knows if a endpoint is
unavailable when it tries to contact the target (when a connection becomes
available). This information is sent to the distribution manager only after the
length of time set by notify_interval.
If an endpoint is down, the repeater skips the endpoint, leaves the information
in its queue, and waits for the target to log in. The repeater also retries the
target the number of seconds set by conn_retry_interval (default value is 900
seconds) up to the number of seconds set by retry_ep_cutoff (default value is
7200 seconds).
After the number of seconds set by retry_ep_cutoff is reached, the item
remains in the queue until the distribution deadline, waiting for the endpoint to
log in.
򐂰 Packet Size (packet_size)
Use the packet_size parameter to specify the number of bytes written to the
network during each send packets packet size determines how many bytes
will be written to the network before the repeater pauses to enforce bandwidth
control. For very slow networks, it is useful to lower the packet size to prevent
flooding the network for long periods of time.
Table 3-6 on page 71 outlines the recommended values for the various MDist2
repeater parameters for the different kinds of repeaters in the Outlet Systems
Management Solution.
Table 3-6 Recommended MDist2 repeater settings
Settings
Parameter
rpt_dir
HubTMR
SpokeTMR
Gateway(s)
/opt/tivoli/rpt_dir
/opt/tivoli/rpt_dir
/opt/tivoli/rpt_dir
Chapter 3. The Outlet Systems Management Solution Architecture
71
Settings
Parameter
HubTMR
SpokeTMR
Gateway(s)
permanent_storage
FALSE
FALSE
TRUE.
disk_max
500 MB
500 MB
1 GB
max_sessions_high
5
10
5
max_sessions_medium
10
20
10
40 (Default)
10
5
mem_max
64 MB
64 MB
64 MB
send_timeout
300 s
300 s
300 s
execute_timeout
600 s
600 s
600 s
notify_interval
default
15 min
10
conn_retry_interval
1800
900
900
retry_ep_cutoff
7200
7200
7200
500 KB/s
500 KB/s
500 KB/s
Default = 0
5 KB/s
0 (Default)
packet_size
16
16
16
debug_level
3
3
3
max_sessions_low
net_load
target_net_load
MDist2 provides a console that allows controlling the distributions. An example
showing the Node Table is depicted in Figure 3-8.
72
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figure 3-8 MDist2 GUI Node Table dialog
MDist2 console can be installed on a TMR Server or a Managed node.
Following are some examples showing how to control the MDist2 distributions
from the commandline:
򐂰 List distributions:
wmdist –l [-I dist_id] [-a] [-v]
-I:
-a:
-v:
Specific distribution ID
Show only active distributions
Verbose output
򐂰 List endpoint status:
wmdist –e dist_id [-t endpoint_id] [state…]
-t:
Status for specific endpoint
state…:
Filter with specified states
򐂰 Remove status from database:
wmdist –d dist_id [-f]
Chapter 3. The Outlet Systems Management Solution Architecture
73
-f:
Force deletion without confirmation prompt
򐂰 Cancel Distributions:
wmdist –c dist_id [endpoint…]
򐂰 Pause Distributions:
wmdist –p dist_id [endpoint…]
򐂰 Resume Distributions:
wmdist –r dist_id [endpoint…]
Following are a few examples on how to control and manage the repeater
depots:
򐂰 List segments:
wdepot repeater_name list [id^version]
򐂰 Add segments:
wdepot repeater_name add id^version [source_host:]file
򐂰 Delete segments:
wdepot repeater_name delete id^version
򐂰 Delete all segments not currently in use:
wdepot repeater_name purge
3.4.3 Optimizing slow links connections
To optimize the use of geographical slow links such as 64 kbps, configure the
Spoke TMRs dispatcher, modify the environment variable SLOW_LINK,
assigning it the TRUE value.
1. To do that, run following command:
odadmin environ get > /tmp/odadmin.env
2. Then, edit file /tmp/odadmin.env and add following line:
SLOW_LINK=TRUE
3. Save file /tmp/odadmin.env and run following command:
odadmin environ set < /tmp/odadmin.env
4. To finish, run odadmin reexec on the TMR dispatcher.
This parameter is only available for MDist1 services.
74
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
3.4.4 Managing endpoint behavior
As discussed in “Tivoli gateway architecture” on page 48, the endpoint gateways
play an important part in the deployment and management of Tivoli endpoints.
Within the Outlet Systems Management Solution these gateways will perform all
communications with its assigned endpoints without requiring additional
communications with the TMR server.
The gateway invokes endpoint methods on the endpoints or runs gateway
methods for the endpoint.
Although it is a great advantage that a single gateway can manage hundreds
even thousands of endpoints, it can also bring along its own set of pitfalls which
must be carefully avoided in large scale installations such as in Outlet Inc. The
endpoints behavior, logging in, restarting, broadcasting, and so on must all be
carefully controlled to achieve an efficient and self-supporting endpoint
environment.
This section describes the principles and the procedures for endpoint to gateway
logins. This discussion is followed up in “Endpoint login policies” on page 77, in
which the architecture for endpoint login in the Outlet Systems Management
Solution is described.
Endpoint login scenarios
Here we outline the following examples of endpoint logins that will be applied to
the Outlet Systems Management Solution:
򐂰 Initial login with select_gateway_policy (a script that provides the Endpoint
Manager with a ordered list of gateways
򐂰 Subsequent or normal logins (applied to Outlet Inc.)
Initial Endpoint Login with select_gateway_policy defined
Figure 3-9 on page 76 illustrates the endpoint’s initial login process, where a
select_gateway_policy script has been defined. This scenario can be common in
large, multi-site enterprises like the Outlet Inc. environment where thousands of
endpoints are logging in to multiple TMRs.
Chapter 3. The Outlet Systems Management Solution Architecture
75
TMR Server
Endpoint Manager
2
3
Intercepting
Gateway
1 3 4
Endpoint
requesting login
Figure 3-9 Initial endpoint login
The process that takes place during initial login is:
1. The endpoint attempts to perform the initial login to the assigned gateway
(also known as the intercepting gateway) specified first by the -g option in the
installation procedure.
2. The gateway forwards the login request to the Endpoint Manager at the TMR
Server.
3. The Endpoint Manager refers to the select_gateway_policy defined in the
TMR, gets the candidate gateway for the endpoint, and sends the new login
information to the gateway. The gateway relays the information to the
endpoint.
4. The endpoint logs in to its assigned gateway
Subsequent or normal logins
Figure 3-10 on page 77 illustrates the flow of data for logins after the initial login.
A normal login usually occurs after the endpoint has already been established as
a member of the TMR.
76
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
TMR Server
Endpoint Manager
Assigned
Gateway
1
Endpoint
requesting login
Figure 3-10 Normal Endpoint login
The endpoint logs into the assigned gateway. The endpoint is immediately
established as a communicating member of the Tivoli network.
Endpoint login policies
In the previous sections the select_gateway_policy was mentioned. This is one
of four endpoint related policy scripts that can be defined in a TMR. Table 3-7
shows the login policies valid for endpoints, and their time of execution.
Table 3-7 Endpoint Login Policies
Policy Name
Origin
Execution Time
allow_install_policy
Executed by the
Endpoint Manager.
Executed when the endpoint
installation begins.
select_gateway_policy
Executed by the
Endpoint Manager.
Executed each time an endpoint
needs to be assigned to a gateway.
after_install_policy
Executed by the
Endpoint Manager.
Executed directly following the
endpoint’s installation and initial log
in.
login_policy
Executed by the
gateway.
Executed each time the endpoint
logs in.
Chapter 3. The Outlet Systems Management Solution Architecture
77
allow_install_policy
This policy controls which endpoints are allowed to log in to the TMR. You might,
for example, want to prevent endpoints from subnet 26 to login to a specific TMR,
in which case you would establish an allow_install policy to reject login requests
from these endpoints. The default behavior of this policy allows endpoints to
login unconditionally. You can also use this policy to perform any pre-login
actions you might need.
The TMR Endpoint Manager executes the allow_install_policy as soon as it
receives an endpoint’s login packet from an intercepting gateway. If the policy
exits with a non-zero value, the login process is terminated immediately. If the
policy exits with a zero value, the login process continues.
At Outlet Inc. the allow_install_policy will accept only logins from supported IP
subnets that are specified in the Endpoint Manager configuration file.
This policy will detect duplicate labels, and will reject the endpoint login if the
label already exists in the Endpoint Manager database.
An example of allow_install_policy is provided in A.3.3, “allow_policy” on
page 358.
select_gateway_policy
Executed by the Endpoint Manager, this policy provides an ordered list of
gateways that should be assigned to an endpoint. The select_gateway_policy is
run each time an endpoints initial login packet is forwarded to the Endpoint
Manager, on migratory login or when an endpoint has become isolated (cannot
locate any gateway to which to log in). The policy overrides the Endpoint
Manager’s default selection process and is recommended for TMRs with multiple
gateways. On initial login, the policy provides a list of primary and alternate
gateways for the endpoint to contact. This list is sent to the endpoint with the
initial login assignment information.
The Endpoint Manager tries to contact each gateway in the order listed in the
policy script. The first gateway contacted is the gateway to which the endpoint is
assigned. The intercepting gateway is also added to the end of the
select_gateway_policy list to ensure that the endpoint has at least one definite
contact. If the gateways listed in the script cannot be contacted, the Endpoint
Manager assigns the intercepting gateway to the endpoint.
Within the Outlet Systems Management Solution the gateways will be selected
based on the entry in a configuration file containing the match between the IP
address and the gateway; for example:
78
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Example 3-1 Gateway selection configuration file
10.248.32.* gateway1
10.248.32.* gateway2
10.248.26.[25-45] gateway3
An example of select_gateway_policy is provided in A.3.4, “select_policy” on
page 361.
after_install_policy
The Endpoint Manager executes the after_install_policy after the endpoint has
successfully been created. For example, this script can be used to subscribe
endpoints to profile managers. Because the script runs before the endpoint’s first
normal login, you cannot use it to run downcalls, commands that communicate
with the endpoint itself. The policy is run after the initial login only; it will not be
run on subsequent logins of an endpoint.
An example of after_install_policy is provided in A.3.7, “after_policy” on
page 365. This example uses the after_login policy to subscribe endpoints to the
correct profile managers and submit an APM plan which includes software
distributions and inventory scans against the newly created endpoint.
login_policy
This policy is executed by the gateway and performs any action you need each
time an endpoint logs in to its gateway. For example, this script can be helpful
when configured for automatic upgrade of the endpoint software, or inventory
scan. If the login_policy exits with a non-zero value, the endpoint login will not
fail.
Note: The same login_policy script should be run on all of the gateways in a
TMR.
An example of login_policy is provided in A.3.6, “login_policy” on page 364.
Endpoint login parameters
When an endpoint logs into a gateway there are several parameters passed to
any policy that is run. These parameters are:
$1
$2
$3
$4
$5
$6
The label of the endpoint machine
The object reference of the endpoint machine
The architecture type of the endpoint machine
The object reference of the gateway that the endpoint logged into
The IP address of the endpoint logging in
region
Chapter 3. The Outlet Systems Management Solution Architecture
79
$7
$8
dispatcher
version
All these values can be used by the currently running policy script.
Outlet Inc. endpoint policy and gateway solution
Within the Outlet Systems Management Solution Tivoli implementation there will
be very specific gateway and endpoint policies in place. This solution is not
designed automatically to allow the migration of endpoints between gateways.
The reason or this is the Outlet Solution needs to maintain a consistent
distribution list for software distribution, even if it will be manually possible to
migrate the endpoints.
On Hub and Spoke TMRs the select_gateway_policy, executed by the Endpoint
Manager, will always return only the gateway of the outlet to which the endpoints
belong. The following guidelines are recommended with the
select_gateway_policy:
򐂰 Defining the subnet masks specific to an outlet is recommended in order to
assign the endpoints to the correct gateway, or outlet server.
򐂰 Avoiding the use of w* (Tivoli) commands inside the policies is recommended.
If needed, launch a new script immediately before the policy scripts
terminates.
򐂰 Creating gateways on the TMR servers is not recommended in order to avoid
incorrect assignment of the endpoints to these servers - or protect these
gateways with rigid allow_login_policy scripts.
3.4.5 Managing the TME Infrastructure
As with many other business-critical applications, Tivoli components require
regular maintenance and checks to be performed. This is mainly for the following
two reasons:
򐂰 To check data integrity
򐂰 To ensure safe and stable operation by creating restorable backups
The next two sections explain the importance of regular backups and checking
and repairing the Tivoli object database.
Backups
The Tivoli Management Environment is an extremely volatile environment, with a
great number of changes, additions and removals occurring almost every day.
With this in mind, Tivoli provides a feature to backup the databases used by each
Tivoli managed node. This includes the TMR Servers, gateways and other
80
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
managed nodes. This backup can be scheduled to match the frequency of
changes within the environment.
Before and after each application installation, it is a good practice to back up your
current Tivoli Management Environment database. This will make it easy to go
back to the previous database if you encounter a problem while installing a
particular application.
Placing the Tivoli object database backups under control of Tivoli Storage
Manager is highly recommended for safe archiving and restoration.
Checking and repairing Tivoli database integrity
As already mentioned, the Tivoli Management database and its integrity is critical
to the operation of the Tivoli Management Environment. Because of this,
checking and repairing the database is of great importance.
By maintaining an error free database, the environment will operate smoothly
and efficiently. The database should be checked on a regular basis. This task
can also be scheduled.
Note: To perform a database check, use the command wchkdb –u to perform a
local database check, or wchkdb –ux to check all remote databases.
Scheduling within the Tivoli Management Environment
With all the tasks and operational areas that can be run within the Tivoli
environment. it is important for Outlet Inc. to automate and schedule these. The
Tivoli Framework scheduler maintains a record of all scheduled jobs. This record
tracks scheduled system management tasks over long periods of time as jobs
are run, completed, removed from the scheduler queue. Jobs with a repeating
schedule are deleted when the repeat cycle is completed.
However, problems can occur when an administrator who has scheduled a
repeating job leaves the company or moves to another position. In such cases,
the person is removed as a valid Tivoli administrator, but the scheduler still
contains jobs to run in the future with the credentials of the former Tivoli
administrator.
For example, suppose an administrator has a nightly job scheduled to clean out
the print queue and ensure that the print service is still active. After the Tivoli
administrator role representing the person who left the company is deleted, this
job will fail the next time the scheduler run it because the administrator role who
created the job is no longer valid. In such situations, remove the job. If you still
need the job performed, reschedule it under a different, active administrator.
Chapter 3. The Outlet Systems Management Solution Architecture
81
3.4.6 Tivoli and RDBMS Integration
All Tivoli Enterprise applications produce or receive data for manipulation,
information and administration. Many of these Tivoli applications rely on the
support of an external relational database management system (RDBMS) to
store the large amount of data that can be received. The RDBMS Interface
Module (RIM) component of the Tivoli Framework is used to access these
databases.
Interfacing to the RDBMS using RIM
The RDBMS Interface Module (RIM) provides a common interface that Tivoli
applications can use to store and retrieve information from a number of relational
databases. By using the RIM interface, a Tivoli Enterprise application can access
any supported database in a common manner, independent of the database.
Storing information in an external database enables an application to take
advantage of the power of relational database technology, such as SQL queries,
to store and retrieve information.
Within the implementation of the Outlet Systems Management Solution, there
are some specific applications that uses RIM.
򐂰
򐂰
򐂰
򐂰
Tivoli Framework MDist2 Service
Tivoli Enterprise Console (TEC)
Tivoli Configuration Manager - Software Distribution
Tivoli Configuration Manager - Inventory
The RIM acts as a processing agent for Tivoli related data, which upon reception
by RIM, is processed and converted into SQL based queries and instructions.
These SQL based queries and instructions enable the RDBMS to be populated
with the required information.
The Tivoli Scalable Collection Service (SCS), previously known as MCollect,
performs asynchronous data collection from the endpoints. From these
endpoints, one or more RIM objects can be created. You can configure multiple
RIM objects to write Inventory data in parallel to the configuration repository.
Currently, SCS is only used by the Inventory component of Tivoli Configuration
Manager, to facilitate upload of HW and SW scan data from a large number of
endpoints without overloading network connections or databases. Refer to
“Scalable Collection Service” on page 89 for further details regarding the inner
workings and configuration of SCS.
RDBMS Configuration in Outlet Inc.
The Tivoli environment requires that an RDBMS system be used to provide
permanent storage capabilities for various types of data that can be accessed
from, or interact with, external sources.
82
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
An important part of data storage and connection between Tivoli and an RDBMS
is the database systems themselves. In the Outlet Systems Management
Solution, the database system is intended to be on an external server, one that
only has the Tivoli endpoint installed, that will contain a RDBMS. This system will
be responsible for storage of:
򐂰 MDist2 distribution status and historical information
򐂰 Events received by the Tivoli Enterprise Console, including event adapters,
distributed monitoring, and software distribution, among many other event
sources
򐂰 Inventory configuration data
򐂰 Software package distribution, status information, and activity plans
The chosen vendor for the RDBMS system in the Outlet Systems Management
Solution is IBM DB2.
3.5 Network communications and considerations
Tivoli’s distributed architecture is designed to work across a wide variety of
systems throughout the Outlet Inc. network topology. The minimum requirement
for communication protocol support is bidirectional, full-time, interactive TCP/IP
connections.
3.5.1 TCP/IP
The Tivoli Management Environment contains several key systems, which when
installed and configured, make up the Outlet Systems Management Solution.
Within this Framework, there are communication methods and procedures used
to enable the transfer of methods, command, tasks, object references, and
object calls.
Figure 3-11 on page 84 shows the typical communication paths within a TMR. It
shows that communication between managed nodes, systems running the Tivoli
Object Request Server OSERV, communicate over TCP and, preferably, static IP
addresses. The figure also shows how the communications between the Tivoli
Gateways are performed over TCP using static or DHCP assigned addresses.
Chapter 3. The Outlet Systems Management Solution Architecture
83
Figure 3-11 Tivoli Protocol Communication
It is not necessary for an endpoint to be able to communicate with the TMR
server, because all communication to the endpoints are provided through the
hosting gateways.
TCP/IP Ports
In order to facilitate the correlation between the clients and servers, TCP/IP uses
a concept called port. All TCP/IP connections are attached at each end by one of
these ports.
The port numbers between 0 and 1023, known as trusted ports, are reserved for
standard services such as ftp, rexec and telnet. These trusted ports are attached
to the server side of the application. At the client side, when an application wants
to open a connection, it normally asks the operating system for a non-reversible
port, one with a number ranging from 1024 to 65535.
In Tivoli, the client/server communication is implemented by the oserv process.
The process runs on the TMR server and on each managed node, providing a
common framework communication across all platforms on which the Tivoli
environment works.
84
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
TMR-to-Managed Node communication
The basic communication between a TMR server and its managed nodes is
managed by a mechanism called Inter-ORB communication. The mechanism,
also known as Interdispatcher communication, is the basic interaction between
different oservs.
The oserv that initiates the connection is considered the client, while the oserv,
which accepts the request is considered the server. The oserv object dispatcher
port is 94, the listening port. The client port, also known as the ephemeral port, is
assigned by the operating system or selected automatically from a predefined
port range.
When the oserv needs to initiate a data transfer greater than 16 KB, the
mechanism used is called Inter-object Messaging (IOM). Both, client and server
sides of an IOM channel are connected using ephemeral ports, ports numbered
above 1023, and they are assigned by the operating system or selected
automatically from a predefined port range.
The option set_port_range of the odadmin command can be used to specify and
limit the port range used. This option is especially helpful for firewall
administrators who need to limit the port range availability. A sufficiently large
port range must be specified, so that ports can always be assigned as needed.
An example of the command to specify and limit the port range availability
follows:
odadmin set_port_range 5000-6000
Managed Node-to-Managed Node communication
The communication between managed nodes is implemented the same way as
the TMR server to managed-node communication.
TMR-to-TMR communication
The communication between TMR servers is implemented by a mechanism
called Inter-TMR communication that, from the network communication
perspective, follows the exact same pattern as the Inter-ORB communication.
Endpoint-to-Gateway communication
The endpoint-to-gateway communication is between the gateway daemons
running on the gateway, with the Tivoli Management Agent (TMA) installed on
endpoints.
When a gateway needs to invoke a method to be executed on an endpoint, the
gateway initiates a communication called a downcall. A downcall can be
originated also from any managed node or the TMR server.
Chapter 3. The Outlet Systems Management Solution Architecture
85
When an endpoint needs to invoke a method to be executed on the associated
gateway, it initiates a communication called an upcall.
The default configuration of the listening port for gateways is 9494, and for
endpoints, is 9495.
Communication during Installation
During the installation process, access from the TMR to a system on which a
managed node is being installed, uses rexec, rsh or ssh services. The Outlet
Systems Management Solution will use ssh. The TCP port number used by
rexec, rsh, and ssh are 512, 514, and 22 respectively.
Table 3-8 summarize the use of TCP/IP ports used in Tivoli environment:
Table 3-8 Standard TCP/IP ports used by Tivoli
Connection
86
Type
Server
Listening
Port
Client
Listening
Port
TMR - Managed Node – TMR
Inter-ORB
94
Range
TMR – Managed Node – TMR
IOM
Range
Range
Gateway – TEC
Inter-ORB
94
Range
Managed Node – Managed Node
Inter-ORB
94
Range
Managed Node – Managed Node
IOM
Range
Range
TMR – TMR
Inter-ORB
94
Range
Endpoint to Gateway
Initial login
broadcast
9494 –
gateway
OS choice
Endpoint to Gateway
Normal login
broadcast
9494 –
gateway
OS choice
Endpoint to Gateway
Method upcall
9494 –
gateway
OS choice
Gateway to Endpoint
Method
downcall
9495 –
endpoint
Range
TMR – Managed Node
rexec for
installation
512
OS choice
TMR – Managed Node
rsh for
installation
514
OS choice
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Connection
Type
TMR – Managed Node
ssh for
installation
Server
Listening
Port
22
Client
Listening
Port
OS choice
DNS
The Tivoli service, or daemon, that runs on each client and on the server within
Outlet Inc. must be able to map a machine’s IP address to a host name during
the initial connection between services. This technique is sometimes known as
reverse mapping. Mapping between IP addresses and host names or host
names and IP addresses can be done using one of the three following sources of
data:
򐂰 /etc/hosts file
򐂰 NIS
򐂰 DNS
With the first two data sources, both forward and reverse mapping information is
available. You must have reverse mapping from TMR server to client and from
client to TMR server. If you are using DNS and do not provide the IP address to
host name mapping, the Tivoli client installation will fail.
The DNS server is the outlet server.
3.6 Configuration management
This section describes how, when using the described products, you can gain the
ability to track physical assets, implement desired state management, and
control asset investment across large enterprises, enhancing business
competitiveness.
3.6.1 Tivoli Configuration Manager: Inventory
The Inventory component of Tivoli Configuration Manager, referred to here as
Tivoli Inventory, will provide Outlet Inc. with enterprise system configuration
information. By using the capabilities of Tivoli Inventory, Outlet Inc. will be able to
scan automatically for and collect hardware and software configuration
information from distributed systems.
Tivoli Inventory is tightly integrated with Tivoli Software Distribution. An example
of this would be an administrator preparing to distribute a software upgrade to
Chapter 3. The Outlet Systems Management Solution Architecture
87
automatically generate a list of systems for Outlet Inc. that meet the new
version's hardware prerequisites.
Tivoli Inventory deployment in Outlet Inc.
A basic purpose of deploying a systems management solution for Outlet Inc. will
be gathering systems configuration data. By gathering this data, Outlet Inc. will
gain an understanding of what is present in their environment, and use this
information as a source for file distributions, asset tracking, service desk analysis
and many other activities. This section describes the Tivoli Inventory solution
intended for Outlet Inc. The solution will provide the ability for the rapid scanning
and collection of both hardware and software information from designated
endpoint targets within the Outlet Inc. Tivoli Management Environment. The first
section will explain how the Inventory architecture principle will operate on an
overall basis.
Within the Outlet Systems Management Solution there will be a standardized
build of server systems which will dictate what software is installed into set local
directory’s, as an example these be:
򐂰 /opt/outlet/StoreApp
򐂰 /opt/IBMIHS/htdocs/en_US
Because these directories are set paths into which applications are and will be
installed, it is only necessary to scan these areas for software. If it is decided that
other paths need to be scanned, then separate inventory profiles can be created
for different machine configurations. This will enable several profiles to be used
when scanning different paths, depending on the classification of the systems
that require scanning.
Specifying the paths to scan for files is recommended in order to avoid a scan of
the entire disk and to reduce the amount of data.
The inventory profile describes the scanning operation: hardware and software,
selected paths and directories. This profile will be created in a policy region of the
Hub TMR. This profile will be cloned to profile managers in each of the Spoke
TMRs. All the target systems are grouped in profile managers of subscribers
located in the Spoke TMRs.
Each Spoke TMR will have a cloned copy of the same inventory profile residing
in the Inventory policy region.
With this setup, the profile distribution can be performed from either the Hub or
the Spoke TMRs. However, using the Inventory profile from the Spoke TMRs will
optimize performance because the RDBMS can be accessed in parallel through
the RIMs defined in each Spoke TMR, instead of using the HubTMR’s RIM.
88
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
In the Outlet Systems Management Solution, the inventory solution will require
that the endpoint data within the Inventory repository is kept up to date. Defining
a scheduled time span with which to scan the endpoints will do this. This time
span should not be to frequent, but often enough to keep Inventory data accurate
enough for use by support staff and administrators.
The software scans should be performed on a more frequent basis than
hardware scans. This allows for installations of software to be picked up on a
regular basis. Hardware scans are not required as frequently because that
information should not change as often. Keep in mind that these scanning
intervals can be changed at any time, to account for changes in business
requirements. Specified Tivoli administrators can also run the scans manually. All
the information retrieved from these scheduled or manual scans will be stored in
the RDBMS.
Under all circumstances, any centrally initiated change to any system should be
followed by a relevant scan to update the Inventory information. This might also
help verily the correct implementation of the change.
Inventory profile distribution
In Outlet Inc. it is assumed that all the outlet servers are never switched off. A
switched off machine has to be considered an exceptional event.
The general rule-of-thumb is to distribute Inventory scanning profiles on a regular
basis. For workstations and other systems that are used by individuals on a
regular basis, the recommendation is to perform a hardware scan every week to
10 days, and a software scan every one or two days. For servers and service
systems that are under strict, central change control and are physically
protected, scans should be performed after each application of any change to the
system. In addition, periodic scanning for hardware and software should be
performed once a month, or by a frequency determined by company policies. For
workstations and servers, scan status information should be logged to the
standard output file.
Applying these scanning policies will remove the need for a preliminary check of
the active systems prior to implementing a change application.
Performing the Inventory profile distribution with a command line, is the
recommended method, redirecting the command output to a file. This file can be
used to verify which systems have not been discovered by Tivoli Inventory such
as a switched off or unreachable machine. Optionally, the scans can be
scheduled to run automatically using a Tivoli job.
Scalable Collection Service
Tivoli environment In Outlet Inc. will use SCS service for Inventory collections.
Chapter 3. The Outlet Systems Management Solution Architecture
89
With SCS, Outlet Inc. will have the possibility of controlling how much data is
collected in the network as well as when the data is collected. In addition, the
internal workings of SCS allows for highly efficient scanning and storing of vast
amounts of data.
SCS include the following components:
򐂰 Repeater sites organized into a repeater hierarchy
Repeater hierarchies are systems that use the multiplexed distribution (Mdist)
service. Mdist parameters control the way that information is distributed
throughout a Tivoli environment. A repeater hierarchy is the order in which
information flows from one repeater to the next, and then to the endpoints that
are targets of the distributed data. The SCS uses a collector hierarchy that
mirrors the Mdist repeater hierarchy. SCS sends data upstream through this
hierarchy, in the opposite direction of Mdist distributions.
򐂰 Collectors
Collectors are repeater sites on which SCS has been installed. Specifically, a
collector is a SCS daemon process on either a managed node or gateway
that stores and then forwards data to other collectors or to the Inventory
receiver. A managed node is a collector if SCS has been installed on the node
which is part of the SCS collection hierarchy.
In Outlet Inc. all the managed node gateways will be Collectors, with SCS
installed.
Collectors are composed of the following components:
– The depot persistently stores data collected from endpoints or other
collectors. The depot also sends data to other collectors that request it.
– The queues hold the CTOCs (Collection Table of Contents). The input
queue controls the order in which CTOC is processed for collection. The
output queue controls the order of the CTOCs as they are sent out from
the collector. The completed, deferred, and error queues hold CTOCs for
completed and deferred data collection and error conditions, respectively.
– A multithreaded scheduler daemon processes input and output queues
and controls data flow through the collector depot.
򐂰 Collection manager
Maintains the collector hierarchy based on repeater hierarchy information
obtained from the Mdist repeater manager.
򐂰 Inventory receiver
This Tivoli Inventory object receives data from collectors and sends the data
to one or more RDBMS RIM objects. The Inventory receiver can be
90
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
considered the final collector in an Inventory solution. Like collectors, the
Inventory receiver has a depot and queues. However, the Inventory receiver
uncompresses and decodes the data and sends it to the RIM rather than
requesting collection from an upstream collector.
In Outlet Inc., the HUB and Spoke TMRs will be defined as Inventory
Receivers.
򐂰 The status collector
This component collects, stores, and distributes status information for each
scan endpoint. You can configure the status collector to keep lists of
completed scans, successful scans, failed scans, and error messages. The
status collector maintains this information throughout a scan, so scan status
information is available during the scan.
򐂰 The Inventory configuration repository
This repository stores the data collected by Inventory in a relational database
management system (RDBMS).
򐂰 RIM objects In addition to the existing Inventory RIM object
These other RIM objects connect Inventory to the RDBMS for access to the
Inventory configuration repository. Multiple RIM objects can be configured for
writing SCS data in parallel to the configuration repository.
In Outlet Inc., each TMR (Hub and Spoke) will have a RIM object. At a Spoke
Level, it will define three additional RIM objects: inventory1, inventory2,
inventory3.
Figure 3-12 on page 92 shows the architecture for Inventory management.
Chapter 3. The Outlet Systems Management Solution Architecture
91
Figure 3-12 Logical Architecture for Outlet Inc. Inventory Management
When an Inventory profile is created in the Hub TMR server and distributed to the
endpoints defined as subscribers in the Spoke TMR profile manager, all the
inventory traffic will pass through the HubTMR’s RIM host. This will limit
performance by bypassing the RIM hosts that can be defined in the Spoke
TMRs.
For performance reasons, it is better to create Inventory profiles in the Spoke
TMR. The preferred method is to create a main Inventory profile in the HubTMR
and clone it to each of the Spoke TMRs. Using this method, instead of
distributing the profile from the HubTMR to subscribing profiles in the Spoke
TMRs, will ensure both consistency and performance. In this situation, the Spoke
TMR is the Inventory receiver.
Data collection using Inventory and SCS occurs in three major phases:
1. In the first phase, distribute an Inventory profile that has been enabled for
SCS to the endpoints. As each scan completes on each endpoint, Inventory
generates a compressed and encoded RIM data file. The endpoint sends a
CTOC, which contains information about the RIM data file, to the collector on
the gateway that manages the endpoint. The collector daemon queues the
92
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
CTOC for processing. The scan on the endpoint then completes. After the
scan completes on all endpoints, the Inventory profile distribution is finished.
2. In the second phase, SCS moves data from each endpoint to a depot in the
gateway collector that controls the endpoint. While the data transfers from the
endpoint to the depot, the CTOC for that data remains in the input queue of
the collector. When the collector has collected all the data, the CTOC moves
to the output queue. The collector then notifies the next collector in the
hierarchy that the data is ready to be collected. The upstream collector places
the CTOC in its input queue, and then collects the data from the downstream
collector. When the data is completely transferred to the upstream collector,
the downstream collector discards the CTOC in its output queue and data in
its depot.
3. In the third phase, the Inventory receiver sends the collected data to any
available RIM object configured to work with it. From the RIM object, the
collected data is sent to the Inventory configuration repository. The Inventory
receiver sends the completion status of each scanned end-point, as well as
any error information, to the status collector. The status collector changes the
status for each endpoint from pending to successful or failed.
Features of SCS
The following SCS features illustrate the advantages of asynchronous data
collection:
򐂰 Asynchronous data collection and backend processing lead to better
distribution of processing load across more nodes in the TMR, as well as
better use of the network. SCS stages the data at different collectors in the
network as it flows to the RIM, and allows control over the data flow between
successive collectors in the hierarchy.
򐂰 SCS returns scan data as the scan of each endpoint completes. This feature
reduces RIM overload at the end of a distribution.
򐂰 After data has been collected from an endpoint, that endpoint can be
disconnected without affecting the SCS service.
򐂰 The Inventory receiver can write data in parallel to multiple RIM objects.
Multiple RIM objects improve throughput by allowing data for multiple targets
to be written in parallel to the RDBMS.
򐂰 With the Tivoli scheduler, scans can be scheduled to collect data at times
when network traffic is at a minimum.
򐂰 Collectors along the route store collected data in depots. If a failure occurs,
the collector can resend the data when it is back online rather than scanning
all the endpoints again.
򐂰 With SCS, an Inventory profile distribution completes when all endpoints have
been scanned rather than when scan data reaches the configuration
Chapter 3. The Outlet Systems Management Solution Architecture
93
repository. Therefore, in most cases the profile distribution completes (and
users regain access to the graphical user interface or command line
interface) more quickly.
Network Data Flow
SCS provides features to control the flow of SCS data across the network. These
features are helpful if we have slow network links or if we want to specify when
SCS data crosses your network.
SCS provides the following mechanisms to control data flow:
򐂰 Offlinks
Offlinks are the main mechanism which regulate SCS traffic across your
network. You can use offlinks to enable and disable SCS traffic between
collectors at specified times. To use offlinks, install a collector on either side of
the network that requires flow control, then schedule offlinks using the Tivoli
scheduler.
򐂰 Transmission chunk size
Use the wcollect –c option to configure the size of transmission chunks. With
this option, you have control over the size of the SCS data packet that
crosses the inter-object message (IOM) connection. The default transmission
chunk size is 1 MB. If you choose a smaller chunk size, the application data is
sent in smaller fragments. Decreasing transmission chunk size might be
beneficial for slow links because the link is not congested with large block
transmissions of SCS data. You configure transmission chunk size on the
downstream collector.
Note: Offlinks and transmission chunks affect data transmission between
collector nodes, or between a collector and the Inventory receiver. These
mechanisms do not affect transmissions between an endpoint and the
gateway collector.
򐂰 Input Threads
Collectors use input threads to open an IOM session for retrieving data from a
downstream node. The maximum number of input threads for a collector can
be controlled using the wcollect –t command. Increase the maximum
number of input threads to allow more concurrent SCS IOM sessions, or
decrease the number to reduce SCS IOM traffic coming into the collector.
94
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Note: By configuring a collector’s input threads, you can reduce the
gateway load by limiting the number of simultaneously active SCS
sessions to endpoints from that gateway. This also helps reduce SCS
network traffic coming into the gateway.
Table 3-9 shows the principal parameters for thee collector, using the wcollect
command. Refer to the Tivoli Configuration Manager: User’s Guide for Inventory
which is available online at the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
From the welcome page, navigate to Configuration Manager → User’s Guide
for Inventory → Inventory and SCS Features:
Table 3-9 Suggested wcollect settings
Parameter
Settings
depot_size
50 MB
depot_chunk_size
256 KB
max_input_threads
5
max_input_retries
10
max_output_threads
5
Scheduling offlinks
For offlinks settings, you can decide to collect data from Outlet Inc. downstream
gateway collectors for a fixed window in time during the night, such as two or
three hours per night, without affecting business hours. The following steps are
an overview of the procedure to schedule collections:
1. Create a task that turns off links to a collector, then halts and restarts the
collector so the changes take effect, as in Example 3-2:
Example 3-2 Changing collector starts and stops
wcollect -x offlinks_range_to_prohibit_collection collector
wcollect -h immediate
wcollect -s
where:
offlinks_range_to_prohibit_collection:Specifies the object dispatcher IDs
of the collectors for which links to the
specified collector must be turned off.
collectorSpecifies the collector to which links must be turned off.
Chapter 3. The Outlet Systems Management Solution Architecture
95
To get the object dispatcher ID of a collector, use the odadmin command and
odlist option.
You can list the object dispatcher IDs, separated by commas, as shown in the
following example:
wcollect -x "4,5,6,7" collector
Alternatively, you can use a dash to indicate a range of object dispatcher IDs:
wcollect -x "4-7" collector
You must enclose the range of offlinks in double quotation marks ("").
2. Create a task that turns on the links to all systems for which links were
previously turned off, then halts and restarts the collector so the changes take
effect:
wcollect -x "" collector
wcollect -h immediate
wcollect –s
3. Repeat steps 1 and 2 on each collector for which you want to schedule
collections:
4. Create jobs to run these tasks.
5. Use the Tivoli scheduler to control when and how often to run these jobs.
Collectors can also be controlled by creating a job that starts and stops collectors
using the wcollect –s and –h options. Alternatively, you can schedule a job that
shuts down a collector’s output or input queue by setting the wcollect –o or –t
options for that collector to 0.
Note: When a collector is reconfigured, the changes do not take effect until
the collector is restarted.
Database size
For the initial scan of an Outlet Solution Server, the rule of thumb is to consider
one MB of data per system. For subsequent scans, the amount of data is minor.
To calculate the size of the Inventory database, we should consider the bigger
amount of data per machine (1 MB x 1.000 = 1GB).
Signature files
Example 3-3 is an example of a signature file.
Example 3-3 Signature file
<I>,AcroRd32.exe,2316288,Adobe Acrobat Reader,4.0
<I>,ARUSER.EXE,2908320,Action Request System,4.02
96
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
<I>,builder,2713148,TME10 TEC Rule Builder (AIX 4.x),3.1
<I>,builder.exe,1865216,TME10 T/EC Rule Builder (WinNT),3.1
<I>,CAFE.EXE,95276,Symantec Cafe,7.50b56
<I>,CCDIST.EXE,123904,Microsoft Plus! For Windows 95,4.70
<I>,CCDIST35.EXE,107008,Microsoft Plus! For Windows 95,4.70
<I>,EXPLORER.EXE,204288,Microsoft Windows Internet Explorer,4.00.950
<I>,explorer.exe,234256,Microsoft Explorer,4.00
<I>,explorer.exe,239888,Microsoft Explorer,5.00
Tailor the signature file to indicate only the signatures for applications that need
to be discovered.
Use the wfilesig command to add or delete software signatures.
3.7 Release management
The Software Distribution component of Tivoli Configuration Manager, referred to
in the rest of this book as Tivoli Software Distribution, is a core element of the
entire Outlet Systems Management Solution. Tivoli Software Distribution is the
main component which will support Outlet Inc. IT department’s release
management processes.
To better understand the software distribution process, these are some of the
main elements:
򐂰 Distribution Manager is installed on the TMR Server that also acts as the
Software Distribution Server. The Distribution Manager monitors and controls
distributions and update the status in the database (RDBMS). There is one
distribution manager for each TMR, which keeps track of all the distributions
started in it. In the case of interconnected TMRs, you have more than one
distribution manager but all share one single database.
򐂰 The Software Package (SP) contains the complete definition, including related
actions to be performed on the target system, of what is to be distributed. You
can create a SP using a GUI or text file editor. In case of the latter, a Software
Package Definition (SPD) is created. Files to be distributed are stored on the
Source Host system.
򐂰 A Software Package Block (SPB) bundles all the resources necessary to
execute the actions in the software package into a standard zipped format. At
distribution, the resources do not need to be collected from the source host;
they are already contained in the SPB, which must reside on the source host.
When SPB is distributed to an endpoint, it is not stored on the endpoint, but is
unzipped in the target directory. By unpacking the zipped file immediately,
Chapter 3. The Outlet Systems Management Solution Architecture
97
there is no need for additional disk space on the endpoint for the .spb file. A
software package block is created from a SP or a SPD through the build
function, available from the Tivoli Desktop or by using the wconvspo
command.
򐂰 Source Host is the managed node that stores data to be distributed with a
software package (SP). If an SPB is used, the source host contains all the
resources, including files, to be distributed.
򐂰 Gateway Repeater as depot is the intermediate distribution point; it can be
configured to be a depot of the software to be distributed, temporary or
permanent. Guarantee a certain amount of free disk space to store data. This
functionality is provided by MDist2 functionality, and allows for predistributing
software packages to the local endpoint gateways that are the targets of the
software distribution.
Figure 3-13 depicts the architecture for software distribution:
Figure 3-13 Software Distribution architecture
The fact that gateways can be defined as hosting depots means you can reduce
network traffic for frequently distributed data, or use it for mass distributions to a
single location.
Among the other interesting features introduced with MDist2, there are the
following aspects:
98
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
򐂰 Asynchronous delivery, or the possibility of checking and transmitting the
status of a single distribution, without waiting for the completion of all targets
򐂰 File caching locally on the repeater, to avoid the complete restart of the
distribution process after network errors
򐂰 Checkpoint and restart from where an interruption occurred
򐂰 Distribution control with GUI
򐂰 Distribution queues with three different types of priority
Tivoli Software Distribution also includes Activity Planner (AP) and the Change
Manager (CCM).
With the Activity Planner, Software Distribution users can plan correlated
activities such as software package distribution operations and Framework tasks
for a group of targets and monitor the status of the submitted plans.
With the Change Manager, Software Distribution users can prepare reference
models containing specific hardware inventory and software distribution
conditions to be met on specific groups of targets. If some of those conditions are
not met, an APM plan is automatically generated to update the subscribers to the
desired state.
3.7.1 Software Distribution in Outlet Inc.
Outlet Inc. will use the functions in Software Distribution to endpoint systems
running on the Linux platform.
The following guidelines apply to creating and maintaining the software
packages to be distributed:
򐂰 Every distribution involves a set of preinstallation and postinstallation
procedures, containing change management commands such as install,
commit, undo, remove, rollback, restart, and so on.
򐂰 The application size is a critical factor when you configure disk space on
remote depots that will store the packages.
򐂰 Installation and activation phases of distributed software should be
distinguished.
This will allow Outlet Inc. to preinstall new versions of components to all the
servers in the infrastructure well in advance of cutover. This activity is usually
time consuming, can involve distributing large software package blocks, and,
optionally, one or more restarts of the target systems.
Chapter 3. The Outlet Systems Management Solution Architecture
99
At cutover time, the new versions of the components can be activated
simultaneously on all servers in the infrastructure with a minimum of effort
and interruption of service, if any.
It should be noted, however, that the use of predistribution and activation is
dictated by the capabilities of the components that you are installing.
Thorough testing is recommended.
򐂰 Locked files must be managed by software distribution. Tivoli Configuration
Manager has build-in support for detecting locked files, files that are in use at
the time of installation, and replacing these with the new version at the next
restart of the system. Software packages can even be defined to
automatically restart the target system if locked files are discovered.
All Outlet Inc. outlets will be interested in the Software Distribution process. Due
to the network links, it will be crucial to find a solution that better exploits the
Tivoli three-tier architecture and the functionalities of MDist repeater in
geographical network. We recommend the following:
򐂰 The Software Distribution objects will be Software Package Blocks (SPB).
򐂰 The distribution will be done overnight, using a five to six-hour distribution
window.
򐂰 Every gateway in the outlets will be a repeater, and configured to host a depot
used by Software Distribution.
򐂰 Based on the network configuration and the needs of Outlet Inc., the parallel
distribution will be set to 300 outlets.
Figure 3-14 on page 101 depicts the typical software distribution process:
100
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figure 3-14 Software package distribution
The main steps of the process are:
1. The preparation of the SPB will be performed at the preparation site.
2. The SPB is loaded to the Source Host.
3. The SPB will be sent to gateways depots.
4. The SPB will be installed in the transactional area in order to handle locked
files, or to preinstall in order to activate the new application versions at a later
point.
5. The SPB will be activated, committed.
Note: Due to the nature of certain, basic packages, such as core middleware
components, it does not make sense to install these as undoable, because
these components will be installed when systems are out-of-service.
Chapter 3. The Outlet Systems Management Solution Architecture
101
To properly design a software distribution scenario, target systems should be
organized in groups that will be populated automatically, or as a result of specific
queries to the inventory database.
Each group is then configured as a subscriber of a software distribution profile,
the software package object. Profiles are grouped with their subscribers in profile
managers, which are finally collected in policy regions.
The Software Distribution operator can perform install, commit, and undo
operations.
3.7.2 Integrating Tivoli Software Distribution with the TEC
Tivoli Software Distribution TEC integration enables Software Distribution to
send events to the Tivoli Enterprise Console’s event server when a Software
Distribution operation is performed.
Software Distribution automatically generates events based on its operations
(successful or failed distributions, commit operations, or removals) and sends
these events to the TEC event server. This provides a means for centrally
collecting Software Distribution events and triggering actions that can be treated
in the same fashion as events from other sources or even be correlated with
other events.
In the Outlet Systems Management Solution several event classes for Software
Distribution will be used. Below is a list of the high-level event classes that will be
processed by the Tivoli Enterprise Console in Outlet Inc.
򐂰 Distribution Started (Distributed, Remove, Commit, and so forth)
򐂰 Distributed Completed
򐂰 Distribution Errors
3.7.3 Integrating Tivoli Software Distribution with Inventory
Tivoli Software Distribution maintains a database that automatically updates the
Tivoli Inventory configuration repository with information about Software
Packages, AutoPacks and Software Package Blocks. The information allows
administrators to view what has been installed, removed or distributed to Tivoli
clients within the environment.
Integration with Tivoli Inventory will provide Outlet Inc. with a facility to create
custom queries, and to obtain information about successful or unsuccessful
distributions.
When the Software Distribution product is installed, a script is executed to create
a unique SWDIST_QUERIES query library and related views and tables.
102
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Table 3-10 describes the tables that are created within the configuration
repository for use by Software Distribution.
Table 3-10 Tables for storing Software Distribution status
Tables
Description
INSTALLED_SW_COMPONENT
Stores information about the status of software
distribution operations, specifically about the
machine on which an operation was performed.
This can include such things as, software
package distribution, installation or removals,
the time at which an operation occurred, the
name of the profile that was distributed or
removed, and the result of the operation.
SOFTWARE_COMPONENT
Stores information about software names and
versions that have been distributed or
removed, then links this information to profile
identifications. SOFTWARE_COMPONENT
Stores information about software package
identification and relates this information to a
file package, Auto Pack, or software package
block and the source host.
SD_CM_STATUS
Stores information about the names and
versions of software packages, the time the last
successful action or operation was performed
on a software package, and the status of a
software package on a particular machine.
Before Software distribution can update the database with information, an
inventory scan must be completed for all intended Outlet Inc. target endpoints.
Once information regarding distribution of software is populated into the Software
Distribution database, this can then be queried in the normal way using the Tivoli
querying facility. Outlet Inc. will be using this information to retrieve specific
information regarding successful and failed distributions and which endpoints to
which they relate.
3.8 Availability and Capacity Management
In the Outlet Systems Management Solution a number of products will be used
for monitoring availability and performance of the resources hosted by the outlet
servers. In essence, two distinctly different implementations will be put in place,
one for hardware, the operating system, and middleware monitoring, as well as
another for application monitoring.
Chapter 3. The Outlet Systems Management Solution Architecture
103
The products used for hardware, operating system and middleware are:
򐂰 IBM Tivoli Monitoring
򐂰 IBM Tivoli Monitoring for Databases
򐂰 IBM Monitoring for Web Infrastructure
For application monitoring we will use:
򐂰 IBM Tivoli Monitoring for Transaction Performance
The following sections provide high-level descriptions of the architecture and
main components of the tools used for capacity and availability management in
the Outlet Systems Management Solution.
3.8.1 IBM Tivoli Monitoring architecture
Figure 3-15 presents a high-level overview of the interaction between main
components of IBM Tivoli Monitoring 5.1.
Figure 3-15 IBM Tivoli Monitoring High-level overview
The IBM Tivoli Monitoring 5.1 profile contains, among other information, a
resource model. The resource model is a collection of monitors that correlate
among themselves before attempting to perform a corrective action or sending
notification to the central event manager. The IBM Tivoli Monitoring 5.1 profile is
distributed to the endpoints to monitor one or more resources. Examples of
typical resources are: hard disk space, paging space, and process and service.
104
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Based on configuration settings in the IBM Tivoli Monitoring 5.1 profile, the
engine runs on the endpoint and performs the necessary monitoring on the
resources that are specified in the distributed resource models. The Web Health
Console obtains logged data from selected endpoints and displays the health of
the endpoints.
The following sections describe CIM architecture and the three key components
of IBM Tivoli Monitoring 5.1, which are:
򐂰
򐂰
򐂰
Profile
Resource models
Engine
The Common Information Model
The Common Information Model (CIM) is part of the industry-wide initiative called
Distributed Management Task Force (DMTF). DMTF provides a common model
for the management of environments across multiple vendor-specific products.
The ultimate goal of CIM compliance is to build applications that can extract and
use management data from products released by different vendors, hardware or
software. IBM Tivoli Monitoring 5.1 is CIM-compliant and hence can collect,
store, and analyze management data from other CIM-compliant products. The
definite advantage of using CIM-based resource monitoring is that, when newer
versions of the product whose resources are already being monitored are
released, the monitor is not required to know the implementation details of the
system, but only interacts with it through an already accepted management
interface, the CIM Schema.
In UNIX systems, a CIM-compliant instrumentation called TouchPoint is
embedded in the IBM Tivoli Monitoring 5.1 engine to facilitate the retrieval of
management data. On Windows 2000 systems, the CIM-compliant Microsoft
implementation called Windows Management Instrumentation (WMI) is already
installed as part of the operating system. For a detailed discussion of CIM, refer
to the DMTF Web site:
http://dmtf.org
The IBM Tivoli Monitoring 5.1 engine
To configure the various components of the IBM Tivoli Monitoring 5.1 profile, it is
important to have a basic understanding of the internal workings of the IBM Tivoli
Monitoring 5.1 engine and how the different components interact with each other.
Understanding the internals will also make it easier to understand the impact of
changing the out-of-the-box parameters of the IBM Tivoli Monitoring 5.1 profile.
The following sections briefly describe the six main components that make up the
IBM Tivoli Monitoring 5.1 engine:
Chapter 3. The Outlet Systems Management Solution Architecture
105
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
Analyzer
Event aggregator
Event correlator
Action manager
Logger
Scheduler
Analyzer
The analyzer component receives the resource model from the IBM Tivoli
Monitoring 5.1 engine and executes the monitoring best practices contained in
the reference part of the model. The reference models gets, through the WMI or
Touchpoint, the performance and availability data of all physical and logical
resource instances. The analyzer collects and analyzes the performance data to
verify the service level of the endpoint with a determined class of service. The
best practices or knowledge paths are coded in Visual Basic (VB) on Windows
and JavaScript on UNIX. JavaScript is also be available on the Windows
platform. The VB or JavaScripts are executed during every cycle. If a threshold is
exceeded, the analyzer sends an indication to the event aggregator.
In a simple case, we would compare one threshold, resource model property, to
one resource property, the real world, to trigger indications. However, in most
cases, you would have to look at any number of thresholds and compare them to
the resource property values to find the root cause of a problem.
Event aggregator
When a service level is exceeded at a determined time, it does not always
represent a problem, but its persistence can represent a real problem. The event
aggregator measures the persistence of the indications generated by the
analyzer. The event aggregator collects all indications coming from all decision
trees currently running, and consolidates them based on the aggregation rules
configured in the profile. The aggregation rules are controlled by the occurrences
and holes that are configured in the IBM Tivoli Monitoring 5.1 profile.
An occurrence refers to a cycle during which an indication occurs for a given
resource model, an above threshold cycle. A hole refers to a cycle during which
an indication does not occur, a below threshold cycle.
If the persistence of an indication meets the configured number of occurrences,
an event is generated and sent to the event correlator. If the profile is configured
to send events to Tivoli Enterprise Console for a particular indication, then the
event aggregator is responsible for sending the event to Tivoli Enterprise
Console. However, all events generated by the event aggregator are sent to the
event correlator, irrespective of whether it is configured to send events to Tivoli
Enterprise Console.
106
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
For example, assume that there is a resource property that changes its value
rapidly. The decision tree would be visited every cycle. As part of this, the value
of the resource property is retrieved. In Figure 3-16, the vertical dashed lines
represent the moments of the queries. The point at which the dotted lines meet
the graph are values that are the results of the inquiries. The one horizontal
dashed line represents the threshold. Values above that line are considered
potential problems and will trigger an indication.
Every time the values of the resource properties exceed the thresholds, the
resource model will generate an indication. If the value of the resource property
drops below the threshold for a particular cycle, then no indication is generated
and the event aggregator counts the nonoccurrence of an indication as a hole.
So, if we define an event as four occurrences and one hole when we configure
our profile, then based on the indications generated in Figure 3-16, the event will
be generated when the fourth indication occurs. If we had two consecutive holes,
then the occurrence count would be reset to zero and a clearing event would be
sent, if we configured the profile to send a clearing event.
Tip: The concept of holes can be a bit confusing if you do not realize that the
number of holes specified in your profile represent the acceptable number of
consecutive holes, not the accumulated number of holes over a sliding window
of time.
Figure 3-16 Sampling of volatile metric
Chapter 3. The Outlet Systems Management Solution Architecture
107
Event correlator
The event correlator is responsible for consolidating and correlating the events
generated by the event aggregator between different resource models. It
receives all events from the event aggregator irrespective of whether the event
aggregator has been configured to send events to Tivoli Enterprise Console or
not. It uses a set of static rules to correlate between the different resource
models. This static correlation between resource models is only available for the
Windows resource models.
Action manager
This component is responsible for executing corrective actions consisting of
tasks and built-in actions when a resource model detects a problem. It executes
the actions that the user has associated to a particular indication. There are a
number of ways that the action manager executes the actions. Built-in actions
are implemented as methods of resource models and they are executed through
the WMI. Tivoli tasks are the classic Tivoli tasks that the user can associate with
a particular indication through the IBM Tivoli Monitoring 5.1 profile GUI. The
action manager also generates an ActionResult or a TaskResult indication that is
received by the Tivoli Enterprise Console adapter and then forwarded to the
Tivoli Enterprise Console server.
Logger
The logger is responsible for collecting performance and availability data on the
endpoints and storing these locally. The logger handles multiple resource models
distributed to an endpoint. It also handles the way data is collected: aggregated
data (minimum, maximum, or average values) or raw data. The logger is also
responsible for clearing the oldest records in the database. Nightly, around
midnight, a data purging process is executed, which removes all data more than
24 hours old. You can only view 24 hours of data; however, there are times when
this database has almost 48 hours of data, just prior to the midnight purge. By
default, logging is turned off. The data can also be consolidated to a central
RDBMS for trend analysis and reporting.
On the UNIX platforms, IBM Tivoli Monitoring 5.1 uses an open-source database
from Quadcap Software. Quadcap is a pure Java™ RDBMS designed to be
embedded into applications. For more information and documentation about the
Quadcap database, visit their Web site:
http://www.quadcap.com/home.html
Scheduler
IBM Tivoli Monitoring 5.1 contains a scheduling feature that allows you to
determine:
108
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
򐂰 A period within which monitoring should take place
򐂰 Specific scheduling rules
The monitoring period is determined by defining a from and a to date. With the
scheduling rules, you define time periods on specific weekdays during which
monitoring will take place. Any number of rules can be defined, letting you set up
a profile which covers the periods important to you. The scheduled times are
always interpreted as local times. With this ability, you can set up a single rule
that will monitor the same local time period in different time zones. For example,
if your region covers several time zones but you wish to monitor morning
activities in each time zone, create a single rule defining the monitoring period as
between 08:00 and 13:00. We will monitor the same relative period across time
zones. You should note also that all times of events or activities reported from
endpoints or gateways are also logged in the local time of the system from where
they originated.
Thresholds and indications
Indications are sent to signal the occurrence of a situation that might be a
problem. This assessment is based on a number of thresholds configured by an
experienced user. But an indication usually does not depend on only one
threshold value, and the same threshold can be applied to different resource
properties. When you want to adjust the models, it is necessary to understand
the dependencies, and when events are generated, it will be useful to know what
resource properties triggered it.
Resource models
The resource model contains the program scheme necessary to determine what
data is to be accessed from an endpoint at runtime and how this data is to be
handled. In other words, the resource model is equivalent to an implementation
of monitors from previous editions of Tivoli Distributed Monitoring, albeit, using
the object-oriented modeling approach and integration with CIM. Each resource
model obtains resource data from the endpoint to which it is distributed, performs
root cause analysis using a built-in algorithm, and reacts accordingly in the form
of built-in actions or user-defined tasks.
When an IBM Tivoli Monitoring 5.1 profile containing a resource model is
distributed to the endpoint, the following actions take place:
1. Resource model files are unzipped from the resource model specific zip file.
2. MOF files specific to the resource model are complied.
3. All components of the IBM Tivoli Monitoring 5.1 engine (logger, analyzer,
action manager, event aggregator, and event correlator) are created, loaded
in memory, and started.
Chapter 3. The Outlet Systems Management Solution Architecture
109
Heartbeat monitor
The heartbeat function is enabled on the managed node or gateway of the
endpoints that you want to monitor. The heartbeat monitoring engine has the
ability to forward events to the Tivoli Enterprise Console, Tivoli Business
Systems Manager, and send notices to the Tivoli notice groups. There are three
activities that make up the heartbeat function:
򐂰 Endpoint registration
򐂰 Heartbeat monitoring
򐂰 Viewing endpoint cache
Endpoint registration
When an IBM Tivoli Monitoring 5.1 profile is pushed to an endpoint for the first
time or the IBM Tivoli Monitoring 5.1 engine is restarted on an endpoint, the
information in the endpoint cache is updated when the gateway receives a
message from the endpoint informing the gateway that its IBM Tivoli Monitoring
5.1 engine has been started. Figure 3-17 illustrates the flow of data.
Figure 3-17 Heartbeat endpoint registration data flow
Once the profile has been distributed to the endpoint or the IBM Tivoli Monitoring
5.1 engine has been restarted on the endpoint, it sends an upcall, a method
called register_endpoint, to the gateway, which then registers the endpoint in the
endpoint cache. Additionally, while the engine is active, it sends this
register_endpoint upcall to its gateway every 18 minutes. This behavior is in
place to help track endpoint migration between gateways.
110
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Also note that this upcall occurs regardless of whether the heartbeat is turned on
or turned off.
Heartbeat monitoring
The heartbeat status check of endpoints is initiated from the gateway. Because
of this, the granularity of control is at the gateway level. Either all registered
endpoints on a given gateway are eligible for a heartbeat (the heartbeat is turned
on for that gateway) or none of them are (the heartbeat is turned off on the
gateway). Figure 3-18 shows the flow of data during the heartbeat monitoring
process.
Figure 3-18 Heartbeat monitoring data flow
The gateway issues periodic heartbeat requests, downcalls, to all attached
endpoints. The returned data is stored in the endpoint cache and events are sent
to the configured event targets.
Viewing the endpoint cache
When the heartbeat monitor detects problems with the resource model, IBM
Tivoli Monitoring 5.1 engine, or endpoint, it will send events to Tivoli Enterprise
Console, Tivoli Business Systems Manager, or the Tivoli notice groups. In
addition, the heartbeat information in the endpoint cache can also be viewed
using the wdmmngcache command. Figure 3-19 on page 112 shows the flow of
data when the command is invoked.
Chapter 3. The Outlet Systems Management Solution Architecture
111
Figure 3-19 Endpoint cache retrieval data flow
Web Health Console
The Web Health Console (WHC) is a Web-based GUI that displays the state
information about the deployed resource models and aggregated health
information about endpoints. You can use the Web Health Console to monitor
real-time data or historical data. The distributed profile must be configured to
collect historical data for that data to be accessible by the Web Health Console.
The Web Health Console follows a Model-View_controller architecture for
retrieving and showing performance data. Each request is executed in a different
thread. The exchange of information among the main objects inside the Web
Health Console is realized through an event-driven architecture. The real-time or
historical data is retrieved using XML. The console displays activity of the
analyzer and aggregator components of the new agent technology.
The console operates independently of the TME environment, but is still
validated and authenticated through the TME. You do not need to have an
endpoint on the machine from which you run the Web Health Console. When you
start the Web Health Console, you are prompted to log in to the Tivoli
Management Region server or managed node using a valid Tivoli user ID.
The Web Health Console feature has been available since Tivoli Distributed
Monitoring for Windows 3.7, when it was developed as a stand-alone Java
112
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Client. The Java Health Console for Tivoli Distributed Monitoring (Advanced
Edition) 4.1 works with IBM Tivoli Monitoring 5.1.
In IBM Tivoli Monitoring 5.1, the Health Console is now Web-based only, and
uses the following components, installed automatically with the Health Console.
For further installation information about these components, see 4.5, “Installing
Web Health Console” on page 105:
򐂰
򐂰
WebSphere Application Server, Advanced Edition Single Server 4.0.2
IBM HTTP Server
Web Health Console components
The Web Health Console consists of the following components:
򐂰
򐂰
򐂰
Client browser console interface
WebSphere Web Health Console component
IBM Tivoli Monitoring TMR monitoring components
The high-level data flow of the Web Health Console is shown in Figure 3-20.
Figure 3-20 High-level data flow of the Web Health Console
The Web Health Console has the following features:
򐂰
Very easy startup for end users
– Simple, single Web site access
– No installation for individual users, no space needed
– A lower powered, end-user machine used for the Web Health Console
– Low data transfer
Only absolutely necessary data is transferred to the Web Health Console
browser. The Web Health Console server offloads a significant amount of
data processing.
Chapter 3. The Outlet Systems Management Solution Architecture
113
򐂰
Single-point upgrade
– Upgrades are made only at the Web Health Console server.
򐂰 Standard IBM Web technology
– The WebSphere Application Server is the underlying application
technology.
– With it, you can perform remote Web-based management of the Web
Health Console server.
ITM in the Outlet Systems Management Solution
In the Outlet Systems Management Solution implementation IBM Tivoli
Monitoring will be used to monitor basic hardware, and operating system
resources, based on the best practice resource models provided with the
product. Initially the following resources will be monitored:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
CPU
Process
Memory
PhysicalDisk
FileSystem
NetworkInterface
Security
As a starting point, default values will be used for all resource models, and event
forwarding to Tivoli Enterprise Console will be enabled.
In addition to the resource monitoring, availability monitoring will be enabled in
the Outlet Systems Management Solution using the heartbeat monitor. Online
surveillance will be enabled for the operators at Outlet Inc. through the
implementation of the Web Health Console.
A further analysis of the needs for monitoring and adjustment of selection of
resources (thresholds, holes and corrective actions) to monitor and the
customize has to be performed before specific recommendations can be made.
3.8.2 ITM for Databases: DB2
IBM Tivoli Monitoring for Databases is a collection of ITM resource models and
related tasks that provides best practices for database management.
They help to ensure the availability and performance of critical applications in an
integrated e-business environment. Its capabilities include:
򐂰 Auto-discovery of the resources to be monitored
򐂰 Problem identification, notification, and correction
114
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
򐂰 Automated best practices for management and operations
򐂰 Historical reporting through a centralized data warehouse
In addition to providing extensive resource models and tasks for various
database actions such as stop, start, reorg, and so forth, ITM for Databases
provides the operators with access to database actions from the Tivoli Desktop
as well as the commandline.
From an architectural point of view, ITM for Databases uses the familiar three-tier
architecture: TMR Server, Gateway, Endpoint. However, because any one
database server can host several, distinct database instances, the normal
endpoint executing on the outlet servers cannot be used directly. Before
downcalls reach the endpoint on the database system, the commands need to
be wrapped into the proper scope, that of a particular instance.
Therefore, when you define database server systems to the Tivoli infrastructure
or elect to discover them automatically, proxy endpoints that are responsible for
defining the proper scope for each database instance are created at the gateway.
The type of proxy endpoints used in the Outlet Systems Management Solution
are DB2InstanceManager, and DB2DatabaseManager. Endpoints of this type
should always be used as the target of the operation when distributing monitoring
profiles containing DB2 resource models.
ITM for DB2 in the Outlet Systems Management Solution
As for monitoring the basic system resources, management of DB2 servers,
instances and databases in the Outlet Systems Management Solution will be
baed on the standard resource models provided with IBM Tivoli Monitoring for
Databases:DB2.
As a starting point the following resources will be monitored:
򐂰 Instances resources
– Instance Status
򐂰 Database resources
– Database Status
– Table Activity
3.8.3 ITM for Web Infrastructure: WebSphere Application Server
IBM Tivoli Monitoring for Web Infrastructure: Monitoring for WebSphere
Application Server provides the ability to register a application servers and to
collect their configurations in order to manage them. Once registered, resource
models and management functions can be used to:
Chapter 3. The Outlet Systems Management Solution Architecture
115
򐂰 Start, stop, restart, and retrieve the status of your servers, and retrieve the
status of the related virtual hosts and applications.
򐂰 Monitor key performance and availability of virtual hosts and applications run
by each server.
򐂰 Forward Tivoli Monitoring for Web Infrastructure PAC events to the IBM Tivoli
Enterprise Console.
򐂰 Forward Tivoli Monitoring for Web Infrastructure PAC events to Tivoli
Business Systems Manager.
򐂰 Store historical data on Tivoli Enterprise Data Warehouse.
Tivoli Monitoring for Web Infrastructure components provide resource models, or
groups of monitors, that periodically check the status of your application server
components, the application server and its virtual hosts. The status can be either
active, operational, or inactive, nonoperational. You can customize the resource
models to meet your local requirements.
The resource models enable measuring and reporting of the availability and
performance of the virtual hosts run by application server resources, to identify
bottlenecks and potential problems in the Outlet Inc. Web infrastructure. For
example, you can measure:
򐂰 Traffic
򐂰 Access
򐂰 Error conditions
For WebSphere Application Server, some of the available key performance
metrics are:
򐂰
򐂰
򐂰
򐂰
Enterprise JavaBean (EJB) performance
Database connection pool performance
JVM Runtime Performance
Servlets/JSP Performance
IBM Tivoli Monitoring for Web Infrastructure event rules manage the information
presented on your event console. These rules remove duplicate and harmless
events and correlate events to close events that are no longer relevant. IBM
Tivoli Monitoring for Web Infrastructure event reporting functions support
standard Tivoli event filtering, which you can use to reduce the number of events
sent to your events server, in addition to forwarding events to Tivoli Enterprise
Console.
Outlet Systems Management Solution
IBM Tivoli for Web Infrastructure in the Outlet Systems Management Solution will
be used only to monitor and manage the WebSphere Application Server
116
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
instances on the outlet servers, and is similar to DB2. The endpoint type related
to ITM for WebSphere Application Server is IWebSphere Application Server.
As for monitoring the basic system resources, management of WebSphere
Application Servers, and their logical application servers in the Outlet Systems
Management Solution will be based on the standard resource models provided
with IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application Server.
As a starting point, we will monitor the following resources:
򐂰 WebSphere Application Servers
–
–
–
–
–
ApplicationServerStatus
DBPools
JVMRuntime
ThreadPool
Transactions
3.8.4 IBM Tivoli Monitoring for Transaction Performance
IBM Tivoli Monitoring for Transaction Performance provides functions to monitor
outlet transaction performance in a variety of situations. Focusing on outlet
transactions, it should come as no surprise that the product provides functions
for transaction performance measurement for various Web-based transactions
originating from external systems, systems on the Internet and not managed by
the organization, that provide the outlet transactions or applications that are the
target of the performance measurement. These transactions are referred to in
the following pages as Web transactions, and they are implemented by the Web
Transaction Performance component of IBM Tivoli Monitoring for Transaction
Performance.
Web transaction monitoring
In general, the nature of Web transaction performance measurement is random
and generic. There is no way of planning the execution of transactions or the
origin of the transaction initiation, unless other measures have been taken to
record these measurements. When the data from the transaction performance
measurements are being aggregated, they provide information about the random
transaction invocation, without affinity for location, geography, workstation
hardware, browser version, or other parameters that can affect the experience of
the end user. All of these parameters are out of the application provider’s control.
Naturally, both the data gathering and reporting can be set up to handle only
transaction performance measurements from machines that have specific
network addresses, for example, thus limiting the scope of the monitoring to
well-known machines. However, the transactions are executed, the sequence is
still random and unplanned.
Chapter 3. The Outlet Systems Management Solution Architecture
117
The monitoring infrastructure used to capture performance metrics of the
average transaction can also be used to measure transaction performance for
specific, preplanned transactions initiated from well-known systems accessing
the outlet applications through the Internet or intranet. To facilitate these kinds of
controlled measurements, certain programs must be installed on the systems
initiating the transactions, and they will have to be controlled by the organization
that wants the measurements. From a transaction monitoring point of view, there
are no differences between monitoring random or controlled transactions; the
same data can be gathered to the same level of granularity. The big difference is
that the monitoring organization knows that the transaction is being executed, as
well as the specifics of the initiating systems.
The main functions provided by IBM Tivoli Monitoring for Transaction
Performance: Web Transaction Performance are:
򐂰 For both unknown and well-known systems:
– Real-time transaction performance monitoring
– Transaction topology breakdown
– Automatic problem identification and baselining
򐂰 For well-known systems with specific programs installed:
– Transaction simulation based on recording and playback
TMTP Architecture
The basic architecture is shown in Figure 3-21 on page 119 and elaborated on in
further sections.
118
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figure 3-21 TMTP architecture
IBM Tivoli Monitoring for Transaction Performance (TMTP) establishes a
comprehensive transaction decomposition environment that allows users to
visualize the path of problem transactions, isolate problems at their source,
launch the IBM Tivoli Monitoring Web Health Console to repair the problem, and
restore good response time.
TMTP provides the following broad areas of functionality:
򐂰 Transaction definition
The definition of a transaction is governed by the point at which it first comes
in contact with the instrumentation available within this product. This can be
considered the edge definition, where each transaction, upon encountering
the edge of the instrumentation available, will be defined through policies that
define each transactions uniqueness specific to the edge it encountered.
򐂰 Distributed transaction monitoring
Once a transaction has been defined at its edge, there is a need for
customers to define the policy that will be used in monitoring this transaction.
This policy should control the monitoring of the transaction across all of the
systems where it executes. To that end, monitoring policies are generic in
nature and can be associated with any group of transactions.
Chapter 3. The Outlet Systems Management Solution Architecture
119
򐂰 Cross system correlation
One of the largest challenges in providing distributed transaction performance
monitoring is the correlation of subtransaction data across a range of systems
for a specified transaction. To that end, TMTP uses an ARM correlator in
order to correlate parent and child transactions.
The components of TMTP share a common infrastructure based on the IBM
WebSphere Application Server.
The first major component is the central Management Server and its database.
The Management Server governs all activities in the transaction monitoring
environment and controls the repository in which all objects and data related to
Web Transaction Performance activity and use are stored.
The other major component is the Management Agent. The Management Agent
provides the underlying communications mechanism and can have additional
functionality implemented on to it.
The following four broad functions can be implemented on a Management Agent:
򐂰 Discovery enables automatic identification of incoming Web transactions that
need to be monitored.
򐂰 Listening provides two components that can listen to real end-user
transactions being performed against the Web servers. These components,
also called listeners, are the Quality of Service and J2EE monitoring
components.
򐂰 Playback provides two components that can robotically playback or execute
transactions that have been recorded earlier in order to simulate user activity.
These components are the Synthetic Transaction Investigator and Rational®
Robot/Generic Windows components.
򐂰 Store and Forward can be implemented on one or more agents in your
environment to handle firewall situations.
Whenever a management agent discovers that thresholds are being violated, an
event is sent to the TMTP Management Server, which forwards the event
information to TEC, if configured to perform that task. Naturally, the TMTP
Agents support local event responses as well as the forwarding of clearing
events when the condition raising the event has been resolved.
TMTP in the Outlet Systems Management Solution
.In the Outlet Systems Management Solution, a central TMTP Management
Service will be established. The control database will be hosted at the central
rdbms system, just like all other databases in the Outlet Systems Management
120
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Solution.Naturally, the server will be configured to forward all events to the TEC
server, and to integrate to the Web Health Console.
To facilitate monitoring of the Outlet Solution, TMTP Management Agents will be
installed to all the outlet servers with the intent to deploy a J2EE policy to monitor
transaction performance of the TimeCard application of the Outlet Solution.
As a starting point, the J2EE Monitoring Policy will monitor all transactions routed
to http://localhost:9080/TimeCard/*, and events will be generated for all
sub-transactions longer than one second.
3.9 Event management
The main objective of event management is to improve the service to customers
by collecting and analyzing meaningful events from the resources in the Outlet
Solution, in order to identify and to resolve, in proactive way if at all possible,
situations or incidents that could generate problems.
The event management architecture in the Outlet Systems Management
Solution is based on two fundamental elements, the monitoring agents and the
event server. The primary responsibility of the monitoring agents is to identify
suspicious situations, collect information about those situations, then send this
information to the interested sources. The event server represents the points of
collection, correlation and processing of the events.
Thanks to the monitoring agents, the ITM monitoring engine, TMTP agents, the
TEC login adapter, Inventory, SWD and more, installed on the servers in the
Outlet Solution, it is possible to:
򐂰 Obtain and anticipate identification of error conditions
򐂰 Store the alarms in an event database for analysis and further statistics
򐂰 Generate the automatic opening of problems
The information associated with each event must be defined initially and be
revisited on periodic base. Initially, the list of agents that can generate events
must also be identified and analyzed.
The monitoring agents capture an initial set of information and use this
information to identify the type of event. Once the event has been identified, the
agent can collect further information that is unique to the specific type of event.
Most agents have the ability to initiate an automatic action of recovery, if
necessary, which attempts to correct the problem locally as soon as possible.
Subsequently, the event is forwarded to the Event Manager (TEC Server).
Chapter 3. The Outlet Systems Management Solution Architecture
121
To limit the costs of processing the events, rules that filter out repeating events
can be established at the event-server level. The rules determine if an event is
serious enough to need a processing, or if duplicate events can be eliminated. In
a dynamic environment such as the one at Outlet Inc., these rules are not static,
and must be reviewed periodically for possible revision to provide the most
efficient event handling. All the information for the type of defined event is
formatted and collected for transmission to the event manager responsible for
the ulterior necessary processes.
Once a monitoring agent event is received, the event manager forwards the
event correctly and verifies that the event-sending agent is recognized and
authorized. The event manager correlates the received events, retaining the
history of the last events to determine if there is a pattern to aid in deciding the
type of action to perform. Based on the analysis, the event manager can take
one or more actions. The recovery can be executed on the server site or on the
agent site proactively to prevent problems to the end users of the resource in
question.
Once the event has been analyzed, it must be closed. Independently from the
various adopted ways, the operation of closing of an event represents the formal
fact that the action (manual or automatic) associated with the event has
completed. Rules of correlation between events can exist for which the closing of
an event implies the closing of other events.
Architecture and implementation
The central Tivoli Enterprise Console (TEC) Server receives events from all the
distributed systems in the Outlet Systems Management Solution and manages
them at the middle level.
Every event generated from any monitoring agent is forwarded to the TEC
Server. The TEC server, in turn, is responsible for the analysis and correlation of
the collected events.
The TEC is the focal point for event management in the Outlet Systems
Management Solution. As such, the TEC Server is responsible for receiving and
processing alarms and events originating any type of resource in the Outlet Inc.
information system, including Tivoli solutions, applications, infrastructural
components and more. Once the management rules have been established,
TEC will be able to help manage components automatically in real time, by
receiving and correlating events and, optionally, issuing commands or executing
Tivoli tasks to facilitate corrective actions.
Figure 3-22 on page 123 provides a general depiction of the event management
architecture to be adopted by Outlet Inc.
122
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figure 3-22 Event Management architecture
Tivoli Enterprise Console
The Tivoli Enterprise Console (TEC) will provide Outlet Inc. with a centralized
point of control, enabling the IT staff to control the Outlet Solution across all
systems. The TEC will act as a central collection point for alarms and events
received from the other Tivoli applications and will help ensure the identification
of impending problems.
The TEC processes thousands of events and alarms daily from network devices,
hardware systems, relational database management systems, Web servers,
applications and Tivoli partner and client applications.
In the Outlet Systems Management Solution the TEC Server will be implemented
in the Hub TMR and support the entire organization. Events will be stored in the
RDBMS located alongside the TEC server.
The implementation of Tivoli Enterprise Console will provide Outlet Inc. with a
complete mission-control view of the health of the entire distributed environment
from a single screen on a desktop. It will also provide specialized views of events
Chapter 3. The Outlet Systems Management Solution Architecture
123
to different administrators, displaying only events relative to their responsibilities,
thereby optimizing staff resources.
TEC Components are:
򐂰 Events are the central units of information within TEC. An event describes any
significant change in the state of a resource, which has been detected by
event adapters and monitoring agents. The content of an event are
name/value pairs, which are referred to as attributes.
򐂰 Event adapters are processes which typically reside on the same host as a
managed resource. When an adapter receives information from its source,
the adapter formats the information and forwards it to the event server.
򐂰 The event server is the central servers that receives and processes all events.
The event server evaluates these events against a set of rules to determine if
it can respond to or modify the event automatically.
򐂰 The Event Console provides a graphical interfaces for event display.
򐂰 The TEC Gateway is a process that runs on a gateway. Tivoli adapters send
their events to a TEC gateway, which forwards them to the TEC server
specified in the adapter’s configuration file. TEC gateways can be configured
with a configuration file distributed with an Adapter Configuration Profile
(ACP) using the Adapter Configuration Facility (ACF).
򐂰 RDBMS is a relational database management system that stores events on
behalf of the TEC. Two TEC event server components, the reception log and
event repository, are RDBMS tables accessed through the RIM.
򐂰 Event sources are where the events are generated.
Figure 3-23 on page 125 shows the typical event flow.
124
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figure 3-23 Event management flow with Tivoli Enterprise Console
The TEC server reception engine receives events, optionally logs them, parses
them against known BAROC class definitions, and then forwards the parsed
events to the rules engine.
To optimize the reception engine, make sure the reception buffer is large enough
to prevent overflow. The default is 500 events.
A healthy and well-configured TEC Server can support a sustained rate of event
processing of about 10 events per second, or 36 000 events per hour. This
processing is highly dependent on the complexity and structure of the event rule
base. Obviously, the more complex the rule base, the more processing and
input/output (I/O) overhead is required. Depending on the number of event
sources, this might or might not be a reasonable number of events to expect.
The requirements for database storage are directly proportional to the number of
events. Events can be different sizes. For example, assume that the event size
ranges from 1k to 5k bytes with the average event requiring approximately 2 KB.
A database of 100 MB will allow for storing 20 000 to 10 0000 events. In most
cases, 200 MB of RDBMS space is sufficient. However, allocating an additional
ten percent for temporary space is recommended.
To keep the active TEC database as small and responsive as possible, it should
also be carefully considered which events are being sent and how they are
Chapter 3. The Outlet Systems Management Solution Architecture
125
filtered, the closer to the source the better. In addition, a procedure to manage
the database size to avoid if from filling up should be defined.
TEC Server and TEC Console configuration
Every TEC Server can manage approximately 30 TEC Consoles, and every
console can be personalized with a specific view of the events according to the
needs of the users. Each TEC Console can be accessed from different
workstations, but it is not possible to have more than one active instance of the
same console at the same time.
TEC in the Outlet Systems Management Solution
In the architecture for Outlet Inc. only one TEC Server and one TEC Console will
be implemented. In addition as part of the initial phase only standard, default
event-processing rules will be defined.
The scope of the initial deployment of the Outlet Solution does not allow for
defining specific rules for event filtering, correlation and processing customized
for Outlet Inc. However, this task should be performed once the analysis of event
sources and the volume has been conducted.
126
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Part 2
Part
2
Management
solution
implementation
Now, that the basic architecture for the Outlet Systems Management Solution
has been established, it’s time to start implementation.
This section provides step-by-step instructions on how to install and customize
the various Tivoli components in order to implement the Outlet Systems
Management Solution.
The information in this section is presented according to the logical flow of tasks:
򐂰 Chapter 4, “Installing the Tivoli Infrastructure” on page 129
򐂰 Chapter 5, “Creating profiles, packages, and tasks” on page 271
© Copyright IBM Corp. 2005. All rights reserved.
127
128
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
4
Chapter 4.
Installing the Tivoli
Infrastructure
We have designed and architected the Tivoli Management infrastructure. Now, it
is time to install and deploy it. There are a few general prerequisites that need to
be established and verified to eliminate installation problems. While the most
general prerequisites are described in 4.2, “Installation planning and preparation”
on page 140, they are not intended to be all-encompassing. Issues such as
network issues apply to a particular environment, and can impact the success of
the installation.
This chapter discusses the steps needed to install, configure, and verify that the
Outlet Systems Management Solution environment functions correctly. The
following topics are included:
򐂰 4.1, “The Outlet Systems Management Solution” on page 130, including the
Proof-of-Concept environment, and placement of the Tivoli components.
򐂰 4.2, “Installation planning and preparation” on page 140 describes
preinstallation activities.
򐂰 4.3, “Installation and configuration” on page 147, easy-to-use step-by-step
instructions on installing the various Tivoli product components
򐂰 4.4, “Postinstallation configuration” on page 223, initial configuration of the
Tivoli environment: defining policies to enforce naming standards, subscribing
endpoints, controlling bandwidth usage, correlating events and so on.
© Copyright IBM Corp. 2005. All rights reserved.
129
4.1 The Outlet Systems Management Solution
Based on the overall discussion provided in Chapter 3., “The Outlet Systems
Management Solution Architecture” on page 37, a Proof-of-Concept architecture
for the Outlet Systems Management Solution is presented in Figure 4-1.
Figure 4-1 Outlet Systems Management Solution architecture
130
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
While developing this Proof-of-Concept architecture our target enterprise, Outlet
Inc., was envisioned as a huge, continent or country-wide retailer or financial
institution, with multiple brands and lines of business (LOB). We assumed that
the enterprise has a four-tier geographical structure including the following:
򐂰
򐂰
򐂰
򐂰
Enterprise main office
Multiple regional and country offices connected to the head office
Multiple local and state-wide offices connected to the regional offices
Multiple outlets connected to the local and state-wide offices
As you can see in Figure 4-1 on page 130, the Outlet Systems Management
Solution architecture follows the traditional Hub-Spoke architecture with
distributed managed nodes and gateways to allow for the lowest possible
bandwidth usage. In addition to the Tivoli Management Environment (TME)
management solution, the architecture includes an environment for database
support for all components as well as an environment for transaction monitoring.
It should be noted that the proposed architecture does not include two major
functional components which should be included to make the solution
production-ready. These two components are:
򐂰 Developing the TMR, TEC, and DB environments
򐂰 Staging the TMR, TEC, and DB environments
From a production point of view, these two environments will be required to
develop and test new Tivoli objects such as software packages, resource models
for monitoring, scanning profiles, event rules and so on, and to ensure that they
will operate flawlessly in the production environment. Development and staging
environments are, however, expected to be copies of the production
environment, so the following information about how to establish the productions
environment can easily be applied when implementing the development and
staging environments.
Design and development of procedures for testing, approving, and transferring
objects from the Development and Staging environments into the production
environment are so closely related to the Change Management philosophy of
each organization that they will not be addressed in the following.
4.1.1 Management environments
The TME architecture for the Outlet Systems Management Solution be divided
into four functionally different Tivoli Management Environment (TME) based
types of environments supported by two non-TME based environments.
However, the non-TME based environments will be monitored and managed
from the main Hub TMR environment:
Chapter 4. Installing the Tivoli Infrastructure
131
򐂰 non-TME environments
– ”The database environment”
– ”The transaction performance management environment”
򐂰 TME environments
– The Hub TMR environment
– Multiple Spoke TMR Environments
– Multiple Regional Environments
– Multiple Outlet Environments
For all four environments, the following technical and logistical prerequisites are
assumed to have been implemented prior to establishing the Outlet Systems
Management Solution:
򐂰 The operating platform for all systems is UnitedLinux 1.0 SP3.
򐂰 Every system involved in the systems management solution must satisfy the
Tivoli products hardware and software requirements, as described 3.4.1,
“Suggested Tivoli hardware requirements” on page 62.
򐂰 Every system involved in the systems management solution (TMRs,
managed node, and endpoints) must be connected to the TCP/IP Network.
򐂰 All systems will have domain Name Server (DNS) availability to perform IP
address resolution, including reverse mapping.
򐂰 WAN and LAN connections must be active and tested, and Outlet Inc.’s staff
will have to ensure a permanent effectiveness of the same.
In the following sections, we give brief descriptions of each of the functional
environments, and describe the roles and responsibilities of each systems in the
architecture.
The database environment
The purpose of the database environment is to provide RDBMS support for the
various solution components to store persistent data for specific management
tasks.
The final design of the database environment will be determined by a multitude
of factors that relate directly to client practices and policies as well as the
anticipated load on the systems. In a real implementation, the customer’s
database administrator (DBA) would be consulted for advice on how to configure
and manage the production RDBMS environment.
In the Outlet Systems Management Solution, we have decided to establish
RDBMS support for all systems management components in a single, dedicated
DB2 server named rdbms and provide access to this server through DB2 Client
code installed where necessary.
132
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
From a strictly functional perspective and without taking performance into
account, the DB2 Client code will have to be installed on all TME Servers owning
RIM objects as well as the TMTP Server. In our design, most RIM objects are
owned by The Hub TMR Server, some are replicated on the Spoke TMR servers,
and the TEC Server owns a single RIM. These systems will be the only TME
Servers that requires installation of the DB2 Client.
Table 4-1 details the systems involved in the database environment and their
functional roles.
Table 4-1 The database environment
System
Main
Software
Components
RDBMS Server
DB2 Server
Provide persistent storage in an RDBMS for
all systems management components in
the Outlet Systems Management Solution
DB2 Client
Establish access to the persistent RDBMS
based storage provided by the RDBMS
Server
Functional role
Hub TMR Server
Spoke TMR servers
TEC Server
TMTP Server
The transaction performance management environment
The purpose of the transaction performance management environment is to
provide capabilities to monitor business transactions as they are executed in any
Web server in the infrastructure.
As already discussed in Chapter 1, “The challenges of managing an outlet
environment” on page 3, the availability and performance of business
transactions should be the primary indicator of the overall health of the
infrastructure.
The transaction monitoring environment on the Outlet Systems Management
Solution is established by a dedicated server, tmtpsrv, hosting the Tivoli
Monitoring for Transaction Performance Server. Agents will be installed on each
of the systems hosting the WebSphere Application Server in the Outlets. The
central database environment provides persistent storage facilities to the TMTP
Server, and in case of threshold violations, events are sent to the Tivoli
Enterprise Console Server for processing.
Chapter 4. Installing the Tivoli Infrastructure
133
This implementation provides for basic monitoring capabilities of real-time,
back-end application transaction response times for applications hosted in the
WebSphere environment.
Table 4-2 displays the systems that are part of the transaction performance
environment and their functional roles.
Table 4-2 Transaction performance monitoring environments
System
Main Software Components
Functional role
TMTP
Server
Tivoli Monitoring for Transaction
Performance Server
Provide central functions to manage the
transaction performance management
ClientXX
Tivoli Monitoring for Transaction
Performance J2EE Agent
Target of management/monitoring
The transaction monitoring solution can be extended by deploying a number of
Windows based systems that automatically execute prerecorded transactions
that run on a schedule. This will provide additional transaction availability
monitoring capabilities, however, this is not considered part of the Outlet
Systems Management Solution. Refer to the Tivoli Monitoring for Transaction
Monitoring User’s Guide for more information.
The Hub TMR environment
The intended use of the Hub TMR environment is to provide the central,
enterprise wide functions and facilities to be used by all of the Spoke TMR
environments. As such, the Hub TMR environment becomes the focal point for
managing the remote store infrastructure.
All master objects, including software packages, resource models, scanning
profiles, profile managers, and so on are owned by, and maintained from the Hub
TMR environment. All systems in the Hub TMR environment rely on the RDBMS
environment for persistent data storage.
Besides providing the main Tivoli Management Framework (TMF) functions for
managing authorizations, enforcing policies, and distributing profiles etc. the Hub
TMR environment includes dedicated systems for event handling and
correlation, software distribution and inventorying, as well as console operations.
In the design of the Outlet Systems Management Solution architecture, it was
decided to use dedicated systems for these functions for the following reasons:
򐂰 Performance
The TEC Server, used for event management, quickly becomes a bottleneck,
unless placed on a dedicated system. The same is true for the primary
system responsible for importing inventory scans into the RDBMS.
134
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
򐂰 Capacity
The storage requirements for hosting the master code repository at the
srchost can become relatively significant, and justifies a dedicated system.
򐂰 Reuse
The Web-based consoles used in the Tivoli environment can be implemented
on existing systems running WebSphere Application Server.
Table 4-3 displays the systems that are part of the Hub TMR environment and
their functional roles.
Table 4-3 The Hub TMR environment
System
Main
Software
Components
Functional role
Hub TMR
Server
Tivoli
Management
Framework
Establish central focal-point for monitoring and
management of the Remote Store infrastructure.
Event
Server
Tivoli
Enterprise
Console
Provide event management capabilities for the entire
Remote Store infrastructure
Source
Host
Tivoli
Configuration
Manager
Provide central functions for configuration and release
management processes that apply to the entire
Remote Store infrastructure.
Console
Server
Tivoli Web
based
Consoles
Provide access to centrally located Web-based
consoles to be used for monitoring and managing the
Remote Store infrastructure by local and remote
operators and administrators.
The Spoke TMR Environment
The main role of the Spoke TMR environment is to act as a proxy for the Hub
TMR environment, by implementing functions taking ownership of a subset of the
managed resources (TME endpoints) on behalf of the Hub TMR Server.
As the number of managed systems (TME endpoints) in the remote store
infrastructure increases, and the organizational responsibilities become more
and more dispersed, more Spoke TMR environments can be added to help
reduce the load on the Hub TMR Server and allow for easy distribution of
management functionality and authorizations.
Through an automated process, the Hub and Spoke TMR Servers exchange
information about all the management objects in the TME environment, thus
allowing the Spoke TMR Server to forward events, status information, inventory
Chapter 4. Installing the Tivoli Infrastructure
135
scans and so forth to the components owned by the Hub TMR environment.
They also enable the components in the Hub TMR environment to issue
management actions against the managed objects (TME endpoints, and so on)
owned by the Spoke TMR environment. In addition, management actions against
managed resources owned by a particular Spoke TMR Server can be executed
from the Spoke TMR Server itself, thus allowing for distributing management
authority for a subset of the remote store infrastructure.
In the Outlet Systems Management Solution, we only use one Spoke TMR
environment to demonstrate the use of spoke TMR systems and keep the
complexity at a minimum.
Table 4-4 shows the systems that are part of the SpokeTMR environment and
their functional roles.
Table 4-4 The Spoke TMR environments
System
Main
Software
Components
Spoke
TMR
Server
Tivoli
Management
Framework
Functional role
Provide proxy focal-point for endpoint interactions for a
subset of the Remote Store infrastructure.
The regional environments
In the Outlet Systems Management Solution architecture we assumed that a fast
network connection exists between the central site and a limited number of
distributed regional offices. The fast connection allows for optimizing the
distribution of management objects, primarily software packages, by establishing
remote depots that always contain copies of the most used distributions. The
depot is self-maintained, based on a size limit and a least-recently-used
algorithm, but packages can be preloaded to depots prior to distribution to the
endpoints.
Another use of the managed node in the regional environment is to take
responsibility for hosting the definitions of managed resources (TME endpoints)
for a particular region. By defining the Regional Server as the primary gateway,
and the Spoke TMR Server as the backup Gateway, fault tolerance is build into
the Outlet Systems Management Solution to help avoid single-points-of-failure of
the management solution.
Table 4-5 on page 137 displays the systems that are part of the Regional
environment and their functional roles.
136
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Table 4-5 The PoC Regional environments
System
Regional
Server
Main
Software
Components
Tivoli
Management
Framework
Functional role
Provide Gateway and remote depot functionality to
provide fault-tolerance and limit bandwidth usage
The Outlet environments
In the Outlet Systems Management Solution architecture the Outlet and Regional
environments share similar responsibilities. None of them are required, although
they are highly recommended, to allow for timely installation of software
packages in a low-bandwidth environment. By establishing a managed node and
a depot as close to the target systems as possible, meaning in the store or at a
subregional office, we can move copies of the profiles and installation images
within close proximity of the targets in advance, using a predetermined fraction of
the available bandwidth during working hours, and enable fast profile deployment
and detached software installations. The term detached software installation is
used to denote scheduled software installation can be invoked at a time when
the TMR server (the network connection) is not available to the managed
resource (the TME endpoint).
Table 4-6 displays the systems that are part of the Outlet environment and their
functional roles.
Table 4-6 The Outlet environments
System
Main Software Components
Functional role
Outlet
Server
Tivoli Management Framework
Provide Gateway and remote depot
functionality to provide fault tolerance
and limit bandwidth usage
ClientXX
WebSphere Application Server,
DB2 Server, and Tivoli
Management Agents
Target of management/monitoring
4.1.2 Functional component locations
Based on the solution component selection, the location of various components
in environment are detailed in the following tables:
Non-TMR servers:
The hubtmr environment:
The spoketmr environment:
Table 4-7 on page 138
Table 4-8 on page 138
Table 4-9 on page 139
Chapter 4. Installing the Tivoli Infrastructure
137
Non-TME related components
Table 4-7 details the location of functional components for the non-TME based
systems.
Table 4-7 Functional component location details for non-TMF systems
Role
IP address
Hostname
Software Components
Database
Server
10.1.1.3
rdbms.demo.tivoli.com
UnitedLinux 1.0 SP3
DB2 UDB 8.2
TMTP
Server
10.2.1.1
tmtpsrv.demo.tivoli.com
UnitedLinux 1.0 SP3
WAS 5.1 Server
DB2 8.2 Client
TMTP V5.2 Server
Hub TMR components
Table 4-8 details the location of functional components in the Hub TMR
environment.
Table 4-8 Hub TMR functional component location details
138
Role
IP address
Hostname
Software Components
Hub TMR
Server
10.1.1.1
hubtmr.demo.tivoli.com
UnitedLinux 1.0 SP3
DB2 Client v8.2
TMF 4.1.1
JRE130
JRIM411
JavaHelp
JCF411
mdist2gui
TEC39JRE
TEC_UI_SRVR
TECJCONSOLE
ACF
JCF41
InventoryServer
InventoryGateway
swdis
swdisgw
swdisjps
apm
ccm
TMNT_3.6.2
ITMCmptSvcs
ITMWAS
DB2ECC_V2R2
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Role
IP address
Hostname
Software Components
Event
Server
10.1.1.2
tec.demo.tivoli.com
UnitedLinux 1.0 SP3
DB2 Client v8.2
TMF 4.1.1
JRE130
JCF411
TEC39JRE
TEC_SERVER
TECJCONSOLE
Source
Host
Server
10.1.1.4
srchost.demo.tivoli.com
UnitedLinux 1.0 SP3
TMF 4.1.1
JRE130
JCF411
swdis
Console
Server
10.1.1.5
console.demo.tivoli.com
UnitedLinux 1.0 SP3
TME Web Health Console
Spoke TMR components
Table 4-9 details the location of functional components in the Spoke TMR
environments.
Table 4-9 Sopke TMR functional component location details
Role
IP address
Hostname
Software Components
Spoke
TMR
Server
10.1.1.6
spoketmr.demo.tivoli.com
UnitedLinux 1.0 SP3
DB2 Client v8.2
TMF 4.1.1
JRE130
JCF411
JRIM41
TEC39JRE
ACF
JCF41
InventoryServer
InventoryGateway
swdisgw
swdisjps
apm
TMNT_3.6.2
ITMCmptSvcs
ITMWAS
DB2ECC_V2R2
Chapter 4. Installing the Tivoli Infrastructure
139
Role
IP address
Hostname
Software Components
Region
Server
10.2.0.10
region01.demo.tivoli.com
UnitedLinux 1.0 SP3
TMF 4.1.1
JRE130
JCF411
TEC39JRE
ACF
InventoryGateway
swdisgw
TMNT_3.6.2
ITMCmptSvcs
ITMWAS
DB2ECC_V2R2
Outlet
Server
10.2.1.10
outlet01.demo.tivoli.com
UnitedLinux 1.0 SP3
TMF 4.1.1
JRE130
JCF411
TEC39JRE
ACF
InventoryGateway
swdisgw
TMNT_3.6.2
ITMCmptSvcs
ITMWAS
DB2ECC_V2R2
Client0x
10.2.1.x
client02.demo.tivoli.com
UnitedLinux 1.0 SP3
WAS 5.1 Server
DB2 Server 8.2
TMTP 5.3 MA
4.2 Installation planning and preparation
Besides architecting and designing the systems management solution, a few
prerequisites have to be verified prior to installing the Tivoli infrastructure. The
main items which need to be in place are:
򐂰
򐂰
򐂰
򐂰
”Create naming standards for all Tivoli related objects”
”Operating platform preparation”1
”Enabling SMB server on the srchost server”
”Establishing a code library”
This is required for all systems participating in the Outlet Systems
Management Solution environment.
1
140
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
4.2.1 Create naming standards for all Tivoli related objects
Table 4-10 outlines the naming standards that will be applied to the Tivoli objects
in the Outlet Systems Management Solution environment.
Table 4-10 Naming standards for the Outlet Systems Management Solution
object type
example
description
TMR Servers
<hostname>
descriptive name
Managed nodes
<hostname>
descriptive name
Gateways
<hostname>-gw
Endpoints
<hostname>-ep
Policy regions
descriptive name
Names are enforced by Tivoli products
creating the policy regions.
<TMR>_region_<
REGION>_PR
for profiles
<TMR>_region_<
REGION>_EP
for endpoints
<Policy-Region>_
PM_<type>
where type denotes the type of profiles
hosted:
INV
ITM
SWD
TEC
<Policy-Region>_
PMS_<opsys>
where opsys denotes the operating
system of the endpoints subscribed
Profile Managers
Profiles
No specific standards will be applied
Task Libraries
No specific standards will be applied
Tasks
No specific standards will be applied
Query Libraries
No specific standards will be applied
Queries
No specific standards will be applied
InventoryConfig
<rPolicy-Region>_
INV_HW
Hardware scanning
<rPolicy-Region>_
INV_SW
Software scanning
<rPolicy-Region>_
INV_CUSTOM
Customized functionality
Chapter 4. Installing the Tivoli Infrastructure
141
object type
example
SoftwarePackace
<product_name>^
<version>
description
Tmw2kProfiles
ACF Profiles
not used
RIMs
Names are enforced by Tivoli products
using the various RIM objects.
APM plans
No specific standards will be applied
4.2.2 Operating platform preparation
Important: The following activities have to be performed for all systems that
will be part of the Outlet Systems Management Solution.
Prior to performing the initial operating system customization, you should
carefully review the setup with your local security administration. The
proposed customization has been designed for convenience in setting up the
proof-of-concept environment, and allow access to facilities that your local
policies do not allow.
The minimum requirements will be for a central user to perform remote login.
In a production environment, we recommend using ssh wherever possible.
To set up the basic functionality that will allow the user root to perform the
required actions on our UnitedLinux systems, you should consider performing
these steps:
1. Allow root to login to the system.
In the file /etc/pam.d/login, comment out the line:
auth required pam_securetty=so
2. Allow remote logins to the system.
In the file /etc/pam.d/rlogin, comment out the line:
auth required pam_securetty=so
3. Enable the user root to open a telnet session. In the file /etc/securetty add
one line for each session you will allow. To allow three simultaneous root
sessions, you need three similar lines:
142
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
pts/0
pts/1
pts/2
4. Enable ftp. This procedure enables the local users, including the root user, to
open ftp sessions and write in the local file system:
a. In the file /etc/vsftpd.conf file, uncomment the following two lines by
removing the preceding hash (#) character:
local_enable=yes
write_enable=yes
b. Allow the user root to open an ftp session. In the file /etc/ftpusers file,
comment out the line that specifies root.
# root
c. Allow anonymous ftp logins to the system. In the file /etc/pam.d/vsftpd,
comment out the line:
auth sufficient pam_ftp=so
5. Enable the ftp server to be started by the inetd daemon. In the file
/etc/inetd.conf uncomment the line:
vsftpd
Issue the rcinetd restart command to activate the change.
6. Enable automatic start of the inetd daemon on system restart. From the
directory /etc/rd.d/rc3.d, create two symbolic links, K19inetd and S04inetd,
both pointing to the inetd directory.
cd /etc/rc.d/rc3.d
ln -s ../inetd K19inetd
ln -s ../inetd S04inetd
7. Restart your system.
Preparing the Tivoli environment
The following applies only to systems which assume the role of Tivoli Server or
managed node.
Before you can use the Tivoli Desktop or commands, you must set up the Tivoli
environment variables. You can manually run one of the scripts provided by Tivoli
Management Framework, or modify the /etc/profile.local file in the UnitedLinux
operating systems. This file can change based upon the UNIX OS you are using.
if [ -f /etc/Tivoli/setup_env.sh ]; then
. /etc/Tivoli/setup_env.sh
fi
Chapter 4. Installing the Tivoli Infrastructure
143
4.2.3 Enabling SMB server on the srchost server
Prior to establishing the code library, enable either the NFS or the SMB server
components on the srchost system. Either of these servers will enable access to
the srchost file systems from other systems, thereby allowing for software
installations using the images that reside on the srchost system. Because the
SMB server, also known as the samba server, component will allow access from
Windows systems, we will use that in the Outlet Systems Management Solution.
Complete the following steps to enable and configure the samba server on the
srchost system:
1. Logon to the srchost system as root.
2. Verify that the directory /img has been created.
3. Create the credentials for the user root.
smbpasswd -a root <password>
4. Edit the file /etc/samba/smb.conf. Append the lines in Example 4-1 to the file:
Example 4-1 Append file/etc/samba/smb.conf
[image]
comment = code images
path = /img
browsable = Yes
printable = No
read only = No
create mask = 0775
directory mask = 775
5. Stop the samba server using the command: rcsmb stop.
6. Allow the samba server to be started by at boot time, by appending the
following lines to the file /etc/inetd.conf:
netbios-ns dgram udp wait
root /usr/sbin/nmbd nmbd
netbios-ssn stream tcp nowait root /usr/sbin/smbd smbd
7. Start the samba server manually, using the command: rcsmb start or restart
the inetd service with the rcinetd restart command.
8. Now, from other systems in the infrastructure that have an smb client
installed, typically UnitedLinux or Windows based systems, you can access
the /img file system on the srchost using the following command:
smbmount //srchost/image <mount-point> -o username=root,password=<password>
144
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
4.2.4 Establishing a code library
Prior to installation, it is a good practice to create a library of all the installation
images to be used. This will help ease the installation process and ensure that
the same level of code is used throughout. In addition, a central code library will
help ensure that local modifications, if any, are applied to all systems involved.
The natural location of the code library is the Source Host system.
The library structure in Example 4-2 allows for differentiating installation images
between versions and platforms for the same components. The proposed
structure will also allow for differentiating the file read-write authorities to facilitate
central logging and response file generation.
Example 4-2 Library structure code
<img_dir>/code/<vendor>/<product>/<version.release.level>/[all | <component> |
<patchID>]/<platform>
<img_dir>/spb/<vendor>/<product>/<version.release.level>/[all | <component> |
<patchID>]/<platform>
<img_dir>/tools/<vendor>/<product>/<version.release.level>/[all | <component> |
<patchID>]/<platform>
<img_dir>/rsp/<vendor>/<product>/<version.release.level>/[ all | <component> |
<patchID> ]/<platform>/[ template | <hostname> ]
<img_dir>/logs/<vendor>/<product>/<version.release.level>/[ all | <component> |
<patchid>]/<hostname>
where:
<platform> be one of: generic, aix, hpux, solaris, linux-i386, linux-s390,
win-ix86 etc.
In the proposed library structure, the intended use of the various high-level
directories are:
򐂰 code
This structure contains installation files for the various products. The
installation image for IBM WebSphere Application Server for Linux on Intel®
is in the directory:
/img/code/websphere/was/510/server/Linux-IX86
FixPack1 would be found in:
/img/code/websphere/was/510/FixPack1/generic
Chapter 4. Installing the Tivoli Infrastructure
145
The systems administrators have to be able to modify the content of this
directory structure. All potential users of installation images should have
read-execute (755) access to all the files.
The use of the code directory will, under normal conditions, be restricted to
developing and testing new software packages. In the Outlet Systems
Management Solution, we assumed that the installation images will be built
into software package blocks, which in turn will be distributed as a
self-contained installation package to the target systems.
򐂰 spb
This directory will contain the production-ready software packages that will be
distributed to the target systems. During the software package build process,
the installation images from the code directory will be imbedded into the
software package blocks, which then will be stored in the spb path.
򐂰 tools
This directory is the location where locally developed installation scripts and
helper files are stored. To be able to differentiate between versions and
components the same structure as used for installation images is used, and
the file permissions should be the same (755).
If you develop a script to install a Tivoli managed node using default
installation parameters, the location would be:
/img/tools/tivoli/TMF/411/MN/Linux-IX86/instMN.sh
򐂰 rsp
Most installation procedures today allow for providing basic information to be
used during installation of a product in a separate response file, which can be
prepared in advance. This allows the installation to be performed unattended
and automatically, without requiring an operator to provide installation specific
details at install time. The rsp directory is intended to contain host-specific
response files for installing products and components. These response files
will usually be generated as part of the installation procedure based on
templates prepared by the system administrator.
The location of the response file for installing IBM DB2 UDB Server v8.2
Enterprise Edition on a system named db2srv would be:
/img/rsp/db2/udb-ee/820/server/Linux-IX86/db2_server_820.rsp
򐂰 logs
To keep logs available for review or auditing, it is a good practice to establish
a log directory structure. All logs from installation activities are held here. To
allow the user IDs used to perform installations to create and modify the log
files, these should have read-write access to this directory structure.
146
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Naturally, administrators need to be able to maintain the space, so they also
need read-write permissions as a minimum. The recommended permissions
are 766.
The location of the log files from the installation of IBM Tivoli Monitoring for
Transaction Performance v5.3 Server on a host named tmtpsrv might be
found in:
/img/log/tivoli/TMTP/530/server/generic/install.log
Note that the recommendation is to establish a common root, or base directory,
for all the above directories. In the above examples, this root directory is known
as /img. Establishing a root base directory will allow for easy control of and
access to the central code library from remote machines using nfs- or smbmount.
4.3 Installation and configuration
This section details the steps to be performed to install and configure the
necessary components in the environment as described in “Establishing an
installation roadmap” on page 147.
4.3.1 Establishing an installation roadmap
Once the prerequisites have been verified, the installation activities need to be
sequenced in a way which will allow for a smooth installation path. Most of the
Tivoli components that need to be installed have inherent relationships which
require the installation activities to be serialized accordingly.
The following list outlines the main activities for establishing the systems
management framework according to the architecture described in Chapter 3,
“The Outlet Systems Management Solution Architecture” on page 37. This
method will allow for central execution and control of management activities
related to configuration-, release-, change-, availability-, performance- and
incident management of the outlet environments.
This list is the installation roadmap, the order in which you install and configure
the components. Each activity links to sections with further detail.
1. 4.3.2, “Installing a working database environment” on page 149.
a.
b.
c.
d.
e.
f.
“Prepare for DB2 installation” on page 149
“Install and configure DB2 Server” on page 150
“Creating DB2 instances and databases” on page 150
“Verifying DB2 Server Installation” on page 151
“Installing DB2 Client” on page 152
“Verifying DB2 client operation” on page 154
Chapter 4. Installing the Tivoli Infrastructure
147
2. 4.3.3, “Establishing the TME infrastructure” on page 155.
a.
b.
c.
d.
“Installing and configuring the Hub TMR Server” on page 156
“Installing and configuring Hub TMR managed nodes” on page 162
“Installing and configuring the Spoke TMR server” on page 170
“Installing and configuring Spoke managed nodes” on page 171
3. Install and configure TME-based products.
a.
b.
c.
d.
e.
f.
g.
“Install and configure TMF 4.1.1 Components and Patches” on page 171
4.3.4, “Tivoli Enterprise Console v3.9” on page 181
4.3.5, “Installing Tivoli Configuration Manager” on page 187
4.3.6, “IBM Tivoli Monitoring installation” on page 197
4.3.8, “IBM Tivoli Monitoring for Web Infrastructure” on page 209
“Installing WebSphere Application Server v5.1 installation” on page 204
4.3.9, “IBM Tivoli Monitoring for databases” on page 213
4. Install and configure non-TME products.
a. 4.3.10, “TMTP Management Server” on page 216
5. 4.4, “Postinstallation configuration” on page 223
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
m.
n.
4.4.1, “Framework customization” on page 223
“Connect TMRs and define resource exchange interval” on page 226
“Setup gateways and repeaters” on page 228
4.4.2, “Enabling MDIST2” on page 230
4.4.4, “Configuring the Tivoli Enterprise Console” on page 234
4.4.5, “Customizing the Inventory” on page 238
4.4.6, “Configuring Software Distribution” on page 245
4.4.7, “Enabling the Activity Planner” on page 247
4.4.8, “Enabling Change Manager” on page 252
4.4.10, “IBM Tivoli Monitoring for Web Infrastructure” on page 259
4.4.11, “IBM Tivoli Monitoring for Databases” on page 262
4.4.3, “Enabling Tivoli End-User Web Interfaces” on page 232
4.4.9, “IBM Tivoli Monitoring configuration” on page 255
4.4.12, “IBM Tivoli Monitoring for Transaction Performance” on page 266
Naturally, each of these installation activities in the roadmap include multiple
subtasks, some of which cannot be performed until related components have
been implemented.
Sections 4.3.2, “Installing a working database environment” on page 149 through
4.4, “Postinstallation configuration” on page 223 describe the main installation
and configuration tasks in this roadmap. These tasks establish the core
functionality for each component or component group, and the subtasks related
to basic cross-component configuration. They are necessary to meet security
and organizational requirements, and are required to enable certain functions in
to the proposed architecture.
148
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
These functions will be explained and described in 4.4, “Postinstallation
configuration” on page 223.
In summary, the steps required to build the Outlet Systems Management
Solution include:
–
–
–
–
–
–
–
–
–
–
–
–
“Installing a working database environment” on page 149
“Installing and configuring the Hub TMR Server” on page 156
“Installing and configuring Hub TMR managed nodes” on page 162
“Installing and configuring the Spoke TMR server” on page 170
“Installing and configuring Spoke managed nodes” on page 171
“Install and configure TMF 4.1.1 Components and Patches” on page 171
4.3.5, “Installing Tivoli Configuration Manager” on page 187
4.3.4, “Tivoli Enterprise Console v3.9” on page 181
4.3.6, “IBM Tivoli Monitoring installation” on page 197
4.3.8, “IBM Tivoli Monitoring for Web Infrastructure” on page 209
4.3.9, “IBM Tivoli Monitoring for databases” on page 213
4.3.10, “TMTP Management Server” on page 216
4.3.2 Installing a working database environment
The first step in the installation roadmap is to install and configure the database
environment. The database environment consists of a DB2 UDB Enterprise
Edition Server v8.2 on the rdbsm system, and DB2 Clients v8.2 on the hubtmr,
tec, and tmtpsrv systems.
In the Outlet Systems Management Solution, the DB2 server will provide
database services to the entire Tivoli environment end. In addition, the DB2
server will contain a Tivoli endpoint in order to facilitate monitoring of the
databases using Tivoli Monitoring for DB2.
To begin, setup a DB2 database server on the rdbms machine. This includes the
installation and configuration of DB2.
Prepare for DB2 installation
To install the DB2 software, perform the following steps:
1. Download DB2 Universal Database™ Enterprise Server Edition v8.2 for Linux
and unpack the installation image to the code directory on the srchost system.
The suggested location is:
<img_dir>/code/db2/udb-ee/820/server/all/Linux-IX86
2. Make the installation image accessible from the rdbms system using NFS or
SMB mount:
smbmount //srchost/img /mnt -o username=root,password=<password>
Chapter 4. Installing the Tivoli Infrastructure
149
Install and configure DB2 Server
For documentation on DB2 server installation, refer to the DB2 Information
Center Web site:
http://publib.boulder.ibm.com/infocenter/db2help/index.jsp
Navigate to Installing → DB2 Universal Database for Linux, UNIX, and
Windows → DB2 Servers → DB2 UDB Enterprise Server Edition
(non-partitioned) → Linux → Starting the DB2 Setup wizard.
For documentation on system requirements, refer to the DB2 Information Center
Web site and navigate to Installing → DB2 Universal Database for Linux,
UNIX, and Windows → DB2 Servers → DB2 UDB Enterprise Server Edition
(non-partitioned) → Linux → Installation requirements.
1. Start the Installation Wizard and follow the instructions in the DB2 Information
Center.
1. The DB2 initial installation asks you whether or not to create an instance or
administration server. Choose yes for both of these. It then prompts you for
information to set up an instance, an administration server, and a fenced user
ID. (user name, password, home directory, and so forth) These fields are
straightforward, but must be filled out for the DB2 environment to be set up
fully.
Creating DB2 instances and databases
The Tivoli infrastructure requires several databases to support its operation.
Table 4-11 outlines the required and recommended setup of database instances
and databases.
Table 4-11 DB2 Instance and Database Matrix
Tivoli Component
Instance
Name /
Owner
TCP
port
Database
Name
related
RIM
Tivoli Inventory
db2inv
60004
inv_db
invdh_1
inv_query
MDIST2
db2mdist
60008
mdist_db
mdist2
swd_db
n/a
apm_db
planner
ccm_db
ccm
TCM - Software Distribution
TCM - Activity Planner
db2swd
60012
TCM - Change Manager
150
Tivoli Enterprise Console
db2tec
60016
tec_db
tec
TMTP
db2tmtp
60020
tmtp_db
n/a
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Creating DB2 instances
Create the required database instances using the following commands. The
database instances must be created while logged in as root.
1. Create the instance user/
useradd -g db2grp1 -s /bin/bash -m -d /home/<instance_name> <instance_name>
-p <password>
2. Create the DB2 instance.
/opt/IBM/db2/V8.1/instance/db2icrt -a server -p <port_number> -u db2fenc1
-s ese <instance_name>
Note: We assumed that the fenced user to be used by the instance
(db2fenc1) and the instance group (db2grp1) has been created prior to
creating this instance. If a default instance was created during DB2 Server
installation, these prerequisites will have been defined.
3. Repeat the above commands to create each of the required instances.
Tip: Specifying the port number while creating the instance will prevent
DB2 connectivity problems later. Each instance will reserve four ports. On
United Enterprise Linux, the DB2 ports typically start at 60000 and
increment up by one. For example:
db2icrt -a server -p 60004 -f db2fenc1 db2inv
This command adds the following four lines to the /etc/services file:
DB2_db2inv
DB2_db2inv_1
DB2_db2inv_2
DB2_db2inv_END
60004/tcp
60005/tcp
60006/tcp
60007/tcp
Creating the databases
To create the databases, perform the following steps:
1. Create the required databases using the following commands. Each DB2
database must be created while logged in as the instance owner.
su - <instance_name>
db2 create database <database_name>
2. Repeat these commands to create each of the required databases.
Verifying DB2 Server Installation
The verify the server installation, perform the following steps:
Chapter 4. Installing the Tivoli Infrastructure
151
1. While you are logged in as root and from the command line on the rdbms
server, use the following commands to verify that the database has been
created:
su - <instance_owner>
db2 list database directory
You should see the database for this instance listed, similar to the results in
Example 4-3:
Example 4-3 Database created
Database aliasINV_DB
Database name INV_DB
Local database directory/home/db2inst1
Database release levela.00
Comment
Directory entry typeIndirect
Catalog database partition number0
2. Repeat this procedure for all instances.
Installing DB2 Client
Preparing the DB2 clients on the hubtmr and tec systems require completion of
the following steps on both systems:
1.
2.
3.
4.
”DB2 client installation”
”Establishing a connection to the DB2 Server Instances”
”Cataloging databases”
”Verifying DB2 client operation”
DB2 client installation
To install the DB2 client on the hubtmr, spoketmr, tec, and tmtpsrv systems,
make the installation image available to each system using smbmount as shown
in “Prepare for DB2 installation” on page 149), start the Installation Wizard and
follow the instructions listed in the DB2 Information Center.
For documentation on DB2 client installation, refer to the DB2 Information Center
Web site:
http://publib.boulder.ibm.com/infocenter/db2help/index.jsp
Navigate to Installing → DB2 Universal Database for Linux, UNIX, and
Windows → DB2 clients → UNIX.
For documentation on system requirements, from the same Web site navigate to
Installing → DB2 Universal Database for Linux, UNIX, and Windows → DB2
clients → UNIX → Linux → Installation requirements.
152
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Start the Installation Wizard and follow the instructions listed in the DB2
Information Center.
Establishing a connection to the DB2 Server Instances
Once the DB2 client has been installed, the clients needs to catalog the DB2
Server instances which host the databases accessed from the client systems.
In the Outlet Systems Management Solution, the tec system only uses the
tec_db database hosted by the db2tec instance, the tmtpsrv system uses the
tmtp_db database hosted by the db2tmtp instance, and the hubtmr system
requires access to all the remaining databases and instances. Refer to
Table 4-11 on page 150 for detailed information.
򐂰 To make an instance known to a client, issue the db2 catalog tcpip node
command from the db2inst1 user, created on the client system during DB2
client installation.
򐂰 When logged in as root, issue the following commands:
su - db2inst1
db2 catalog tcpip node <instancename> remote rdbms server <portnumber>
where instancename and portnumber refers to the instance specific
information found in Table 4-11 on page 150.
򐂰 To catalog the db2tec instance on the tec system, the command would be:
db2 catalog tcpip node db2tec remote rdbms server 60016
򐂰 To catalog the db2tmtp instance on the tmtpsrv system, the command is:
db2 catalog tcpip node db2tmtp remote rdbms server 60020
򐂰 The commands to catalog the remaining instances at the hubtmr are:
Chapter 4. Installing the Tivoli Infrastructure
153
db2 catalog tcpip node db2inv remote rdbms server 60004
db2 catalog tcpip node db2mdist remote rdbms server 60008
db2 catalog tcpip node db2swd remote rdbms server 60012
Cataloging databases
Similar to cataloging the DB2 instances, each database accessed from a client
has to be cataloged. The process is similar to cataloging instances, however the
command to use is db2 catalog database, which has to be invoked from the
db2inst1 user.
1. While logged in as root, issue the following commands to catalog a database:
su - db2inst1
db2 catalog database <dbname> as <dbname> at node <instancename>
authentication server
dbname and instancename refer to the database specific information found in
Table 4-11 on page 150.
2. To catalog the tec_db database from the tec system, the command is:
db2 catalog database tec_db as tec_db at node db2tec authentication server
3. To catalog the tmtp_db database from the tmtpsrv system, the command is:
db2 catalog database tmtp_db as tmtp_db at node db2tmtp authentication
server
4. To catalog the required databases at the hubtmr system, the commands are
as in Example 4-4:
Example 4-4 Cataloging hubtmr system databases
db2 catalog database inv_db as inv_db at node db2inv authentication server
db2 catalog database mdist_db as mdist_db at node db2mdist authentication
server
db2 catalog database swd_db as swd_db at node db2swd authentication server
db2 catalog database apm_db as apm_db at node db2swd authentication server
db2 catalog database ccm_db as ccm_db at node db2swd authentication server
Verifying DB2 client operation
To verify the DB2 Client installation and configuration we need to establish a
connection to the newly defined databases. Since no database tables have been
created at this point, the verification cannot select actual data.
1. To connect to a database, issue the db2 connect command from the db2inst1
user.
154
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
2. While logged in as root, issue the following commands:
su - db2inst1
db2 connect to database <dbname> user <instancename> using <password>
dbname and instancename refer to the database specific information found in
Table 4-11 on page 150. password is the password assigned to the instance
user on the rdbms server.
3. To verify the connection from the tec system to the tec_db database, issue
the following command:
db2 connect to tec_db user db2tec using <password>
4. To verify the connection from the tmtpsrv system to the tmtp_db database,
issue the following command:
db2 connect to tmtp_db user db2tmtp using <password>
5. To verify database access for the hubtmr system, try the following commands,
as in Example 4-5:
Example 4-5 Verifying databases for the hubtmr system
db2 connect to mdist_db user db2mdist using <password>
db2 connect to inv_db user db2inv using <password>
db2 connect to swd_db user db2swd using <password>
db2 connect to apm_db user db2swd using <password>
db2 connect to ccm_db user db2swd using <password>
4.3.3 Establishing the TME infrastructure
Establishing the Tivoli Management Environment infrastructure is the second
major activity in the installation roadmap.
Establishing the TME Infrastructure consists of several steps. These steps are
covered in the following sections and include:
1.
2.
3.
4.
5.
6.
“Preparing the Tivoli Framework installation media” on page 156
“Installing and configuring the Hub TMR Server” on page 156
“Installing and configuring Hub TMR managed nodes” on page 162
“Installing and configuring the Spoke TMR server” on page 170
“Installing and configuring Spoke managed nodes” on page 171
“Install and configure TMF 4.1.1 Components and Patches” on page 171
The reason for installing and configuring the Tivoli Framework components until
after establishing the TMR Server environments is that these activities have to be
Chapter 4. Installing the Tivoli Infrastructure
155
performed on all of the TMR Servers and managed nodes. The Tivoli Framework
provides functions to perform installation on multiple systems at the same time.
For reference information and more detailed descriptions of the various steps
performed in the following sections, refer to the Tivoli Management Framework
Enterprise Installation Guide v4.1.1, GC32-0804-01, which is available online at
the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
For details on functional roles of each of the systems involved, refer to Table 4-8
on page 138.
Preparing the Tivoli Framework installation media
Prior to installation of the Tivoli Framework, make sure that the installation media
have been copied to the <img_dir>/code/tivoli/TMF/411/all/generic
directory on the srchost system, and that the /img directory on the srchost
system has been mounted as /mnt on the local system using smbmount:
smbmount //srchost/img /mnt -o username=root,password=<password>
To determine which installation images you need, and from where they can be
downloaded, refer to Table B-1 on page 647.
Installing and configuring the Hub TMR Server
The first step is to install and configure the TMR Server, sometimes referred to
simply as the Tivoli Server, on the hubtmr system. The steps involved are:
1. ”Installing the Hub TMR Server”
2. “Verifying the Hub TMR installation” on page 161
Installing the Hub TMR Server
Install the TMR server on machine hubtmr and configure it by following the
instructions in the Tivoli Management Framework Enterprise Installation Guide,
in the section entitled “Installing on a UNIX operating system.”
In the Tivoli Information Center, this publication is available by selecting
Management Framework → Enterprise Installation Guide → Installing a
Tivoli Server → Overview of Installing a UNIX Tivoli Server.
1. Run the following commands in Example 4-6 on hubtmr to install and
configure the Hub TMR Server.
Example 4-6 Installing the Hub TMR Server
mkdir -p /usr/local/Tivoli/install_dir
DOGUI=no
export DOGUI
156
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
cd /usr/local/Tivoli/install_dir
<path>/WPREINST.SH
The line <path> WPREINST.SH points to the directory containing the file
WPREINST.SH, for example /mnt/code/tivoli/TMF/411/all/generic.
2. Now, you can install the TMR Server directly from a command line or use the
GUI installation method provided by Tivoli. In either case, use the values for
the installation parameters shown in Table 4-12 on page 157.
Table 4-12 hubtmr TMR Server installation parameters
Parameter
value
Encryption level set to
DES
Region Name
hubtmr-region
Server Name
hubtmr
Use the default directory structure as
suggested by the installation.
Allow the installation to create missing
directories
checked
3. To start the command line installation use the following command:
./wserver -c /<path> -a hubtmr -d @EL@=DES AutoStart=1 CreatePaths=1
RN=hubtmr-region
<path> points to the installation directory, for example
/mnt/code/tivoli/TMF/411/all/generic.
The command displays a list of actions that will take place during the
installation and issues a confirmation prompt. To continue the installation
process, type y then press the Enter key. Status information displays on your
terminal as the installation proceeds.
Alternatively, use this command to initiate the GUI installer:
./wserver -c /mnt/code/tivoli/TMF/411/all/generic/CD1
You will be presented the Install Tivoli Server dialog box as depicted in
Figure 4-2 on page 158.
Chapter 4. Installing the Tivoli Infrastructure
157
Figure 4-2 Install Tivoli Server: Specify Directory Locations
4. In this dialog box, do the following:
a. Accept the default values, and enable or check the first of the Server
install options: When installing create ‘Specified Directories’ if
missing.
b. Click Set to continue.
The dialog shown in Figure 4-3 on page 159 continues the installation.
158
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figure 4-3 Install Tivoli Server: server and region names
Do the following:
5. Leave the Licence Key field blank. Since version 4.1, it is no longer needed.
6. Select DES as the Encryption Level.
7. Enter the TMR Server Name. For the hubtmr system in the Outlet Systems
Management Solution the TMR Server Name is hubtmr.
8. Note that the Region Name has been pre-filled by the installation program.
9. Click Install to proceed.
10.You are presented a confirmation dialog box. Verify that all the parameters
are correct, and click Continue Install.
The installation will start. During the installation, if your DISPLAY environment
variable is set, the Tivoli Desktop will open. Note that the installation is not
complete until you see the dialog box shown in Figure 4-4 on page 160.
Important: Do not use the Tivoli Desktop until the installation is complete.
During installation you might receive a message stating /etc/init.d/xinetd: No
such file or directory. This message is generated if the xinetd rpm is not
installed, however this is not a problem because it is not required by Tivoli.
Chapter 4. Installing the Tivoli Infrastructure
159
Figure 4-4 TM Install: completion
11.Now you can use the Tivoli Desktop depicted in Figure 4-5 on page 161.
160
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figure 4-5 Tivoli Desktop
12.Close the Tivoli Desktop by selecting Desktop → Exit.
Verifying the Hub TMR installation
To verify the Hub TMR installation, start the Tivoli Desktop, invoke a Tivoli
command, or do both. The Tivoli Desktop start procedure described in this
section will start the Tivoli Desktop on your local system, and the Tivoli command
procedure will list the installed Tivoli components. Successful execution of either
or both procedures indicate that the TMR Server installation was successful.
1. For both verification procedures, initialize the Tivoli environment by sourcing
the file /etc/Tivoli/setup_env.sh :
. /etc/Tivoli/setup_env.sh
This will define the Tivoli environment variables for the current shell. However,
if you completed the procedure described in “Preparing the Tivoli
environment” on page 143, you will not have to setup the Tivoli environment
every time a new shell is started.
Chapter 4. Installing the Tivoli Infrastructure
161
2. Start the Tivoli Desktop. This verification process starts the Tivoli Desktop
from a shell.
If the DISPLAY environment variable is not set, you can start the Tivoli
Desktop by performing the following steps:
a. Set your DISPLAY environment variable to point to the IP address of your
local system, and export the variable. For examples:
DISPLAY=9.35.29.35:0:0
export DISPLAY
b. Initialize the Tivoli environment variables by sourcing the setup_env.sh
script:
. /etc/Tivoli/setup_env.sh
c. Start the Tivoli Desktop by issuing the tivoli command:
The Tivoli Desktop will now be started, indicating that your TMR server is
operational.
3. Invoke a Tivoli command.
Use the following command to execute a Tivoli command to verify the
installation of Tivoli Server on hubtmr.
wlsinst -a
You will get an output similar to what is shown in Example 4-7 indicating that
the only the Tivoli Management Framework has been installed.
Example 4-7 List of installed Tivoli components generated by wlsinst
hubtmr:/ # wlsinst -a
*--------------------------------------------------------------------*
Product List
*--------------------------------------------------------------------*
Tivoli Management Framework 4.1.1
Installing and configuring Hub TMR managed nodes
As indicated in Table 4-8 on page 138, we need to install managed nodes on the
srchost, and tec systems in the central Hub TMR environment, because each of
these servers will assume active roles in the Outlet Systems Management
Solution.
Prior to installing the managed nodes, defining a new policy region in which they
will reside is recommended.
The activities to install managed nodes for the Hub TMR environment include:
162
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
1.“Creating the ManagedNodes-region policy region” on page 163
2. “Installing managed nodes” on page 164
3. “Verifying the managed node installation” on page 170
Creating the ManagedNodes-region policy region
Creation of policy regions is performed from the TMR Server, the hubtmr system
in our example. Either the Tivoli Desktop or command line can be used:
1. Using Tivoli Desktop, perform the following steps:
a. Create a new policy region on the TMR Server. In this case, the hubtmr
system. Select the menu option Create → Region.
b. Enter ManagedNodes-region as the region name in the Create Policy
Region dialog box, as shown in Figure 4-6.
Figure 4-6 Create a new Policy Region
c. Click Create & Close to complete the creation.
2. Allow resources of the type managed node to be defined in the newly created
policy region:
a. Double-click the new ManagedNodes-region policy region icon.
b. Select the menu option Properties → Managed Resources. This will
open the Set Managed Resources dialog box shown in Figure 4-7 on
page 164.
Chapter 4. Installing the Tivoli Infrastructure
163
Figure 4-7 Set managed resources
c. Select Managed Node from the Available Resources group and click the
left-arrow icon to bring it to the Current Resources: column.
d. Click Set & Close.
3. Using the command line:
Issue the following command in a shell in which the Tivoli environment has
been sourced:
wcrtpr -a Root_hubtmr-region -m ManagedNode ManagedNodes-Region
Installing managed nodes
Installation of managed nodes is performed from the TMR Server, the hubtmr
system in our case, and requires that the root user from the hubtmr system can
authenticate remotely with the target systems. See step 2 on page 142 for
details.
For the Outlet Systems Management Solution Hub TMR environment we install
managed nodes on the tec and srchost systems. Either the Tivoli Desktop or
command line can be used to initiate the installation, and it is required that the
installation image is accessible from the hubtmr system.
1. Using Tivoli Desktop, select the menu option Create → Managed Node. The
Client Install dialog box depicted in Figure 4-8 on page 165 will be displayed.
164
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figure 4-8 Client Install: main window
2. Supply the following parameters:
– TMR Installation Password
Leave this field blank if you did not specify a password during the TMR
server installation.
– Check Use SSH
– Default Access Method
Click Account, use root and the proper password.
– Click Add Clients. The Add Client dialog box, as shown in Figure 4-9 on
page 166 is displayed.
Chapter 4. Installing the Tivoli Infrastructure
165
Figure 4-9 Client Install: Add Clients
3. Enter the name of the desired client system, and select the access method. In
our case, we want to add two new systems. Do the following:
a.
b.
c.
d.
e.
Enter srchost in the Add Client field.
Check Use Default Access Method.
Click Add.
Enter tec in the Add Client field.
Click Add & Close.
This will bring you back to the main Client Install dialog box shown in
Figure 4-8 on page 165. Now the client names appear in the lower part of the
dialog box.
4. Click Select Media to inform the Tivoli installer about where to find the
installation images. The File Browser dialog box shown in Figure 4-10 on
page 167 will be displayed.
166
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figure 4-10 Client Install: Set Path
5. Select the directory in which the Framework installation images can be found,
for example /mnt/code/tivoli/TMF/411/all/generic/CD1.
6. Click Set Media & Close. You are once again returned to the Client Install
dialog box, shown in Figure 4-11 on page 168.
Chapter 4. Installing the Tivoli Infrastructure
167
Figure 4-11 Client Install: return to beginning
7. Click Install to start the installation.
The selected client systems will be contacted by the TMR server and the
Client Install Confirmation dialog box in Figure 4-12 on page 169 will appear.
168
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figure 4-12 Client Install confirmation
8. Click Continue Install when you have checked for errors.
At the end of the client installation, both clients should be included in
ManagedNodes-region, as shown in Figure 4-13 on page 170.
Chapter 4. Installing the Tivoli Infrastructure
169
Figure 4-13 Policy Region: ManagedNodes-region
9. Install the tec and srchost managed nodes from the command line:
Run this command to create the following tec and srchost managed nodes:
wclient -c <path> -d -p ManagedNodes-region -U root -y @AutoStart@=1
srchost tec
<path> points to the location of the installation media relative to the hubtmr
system, for example: /mnt/code/tivoli/TMF/411/generic/CD1.
Verifying the managed node installation
From the hubtmr system, issue the odadmin odlist command, and verify that
the newly installed managed nodes show up in the dispatcher list, as shown in
Example 4-8:
Example 4-8 Managed node list produced by odadmin odlist
hubtmr:/ # odadmin odlist
Region
Disp Flags
1393424439
1
ct2
ct3
ct-
Port
94
94
94
IPaddr
10.1.1.1
10.1.1.2
10.1.1.4
Hostname(s)
hubtmr.demo.tivoli.com,hubtmr
tec.demo.tivoli.com,tec
srchost.demo.tivoli.com,srchost
Note: Notice the c in the flags column, indicating that the systems are
connected.
Installing and configuring the Spoke TMR server
Installation and configuration of the Spoke TMR systems in the Outlet Systems
Management Solution is similar to installation of the Hub TMR environment, as
described in previous sections.
170
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
For an overview of the functional roles of the systems in the Spoke TMR
environment, refer to Table 4-4 on page 136 and the Regional and Outlet
environments related to the Spoke TMR. see Table 4-5 on page 137 and
Table 4-6 on page 137.
To summarize, the Spoke TMR environment consists of the Spoke TMR Server
(spoketmr), and two managed nodes, a regional gateway and repeater
(region01) and an outlet gateway and repeater (outlet01).
Install the TMR server on spoketmr, and configure it similar to “Installing and
configuring the Hub TMR Server” on page 156.
Installing and configuring Spoke managed nodes
Set up spoke managed nodes for the Outlet Systems Management Solution
environment. This includes installation and configuration of both the region01
and outlet01 managed nodes.
The installation and configuration steps are similar to the “Installing and
configuring Hub TMR managed nodes” on page 162, but instead of tec and
srchost system names, use region01 and outlet01 as the clients in the
ManagedNodes-region.
At the end of the client installation, both clients region01 and outlet01 should be
members of the ManagedNodes-region in the spoke TMR environment.
Install and configure TMF 4.1.1 Components and Patches
This section discusses the installation of additional Tivoli Management
Framework 4.1.1 components and patches on TMR servers and managed
nodes. The preparation steps include the following:
1. ”Preparing installation media for TEC”
2. “Determining TEC Component locations” on page 182
TMF 4.1.1 Component installation media preparation
Obtain the installation images for the following components, and unpack them to
the proper location on the srchost server in the <img_dir>/code directory
structure:
򐂰 Tivoli Management Framework v4.1.1 2 of 2
<img_dir>/code/tivoli/TMF/411/all/generic/CD2
򐂰 Tivoli Management Framework v4.1.1 2 of 2
<img_dir>/code/tivoli/TMF/411/all/generic/CD2
򐂰 Tivoli Framework Patch 4.1.1-LCF-0008 (build 08/12)
Chapter 4. Installing the Tivoli Infrastructure
171
<img_dir>/code/tivoli/TMF/411/LCF0008/generic
򐂰 Tivoli Framework Patch 4.1.1-TMF-0011 (build 05/06)
<img_dir>/code/tivoli/TMF/411/TMF0011/generic
򐂰 Tivoli Framework Patch 4.1.1-TMF-0021 (build 09/20)
<img_dir>/code/tivoli/TMF/411/all/generic/TMF0021
򐂰 Tivoli Java Client Framework 4.1.1 Patch JCF411-0001
<img_dir>/code/tivoli/TMF/411/JCF0001/generic
To determine which installation images you need, and from where they can be
downloaded, refer to Table B-1 on page 647.
Note: This list of patches were those that applied to the Outlet Systems
Management Solution environment at the time we wrote this book. For the
latest information, visit the Tivoli support site when you plan to setup your own
environment.
The installation of components and patches will be initiated from the TMR
Servers, hubtmr and spoketmr. Prior to starting the installation, you should make
sure that these two systems can access the installation images. Use the
smbmount command to map the /img directory on the srchost system to the /mnt
directory on each of the TMR servers:
smbmount //srchost/img /mnt -o username=root.password=<password>
Determining TMF component locations
Table 4-13 on page 172 outlines which components and patches need to be
installed on which systems.
Table 4-13 Tivoli Management Framework installation roadmap
172
x
x
Tivoli Java RDBMS Interface Module
(JRIM) 4.1.1
x
JavaHelp 1.0 for Tivoli
x
Tivoli Java Client Framework 4.1.1
x
outlet01
srchost
x
region01
tec
Java 1.3 for Tivoli
spoketmr
component/patch
hubtmr
system
x
x
x
x
x
x
x
x
x
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
srchost
spoketmr
region01
outlet01
Distribution Status Console, Version
4.1.1
x
Tivoli Management Framework SSLB
Version 1.1
x
x
x
x
x
x
Tivoli Framework Patch
4.1.1-LCF-0008 (build 08/12)
x
x
x
x
x
x
Tivoli Framework Patch
4.1.1-TMF-0011 (build 05/06)
x
Tivoli Framework Patch
4.1.1-TMF-0021 (build 09/20)
x
x
x
x
x
x
Tivoli Java Client Framework 4.1.1
Patch JCF411-0001
x
x
x
x
x
x
Tivoli MDist 2 Graphical User Interface
4.1.1 002 Patch a
x
hubtmr
tec
system
component/patch
x
a. This patch is delivered as part of the Tivoli Framework Patch 4.1.1-TMF-0011
Installing TMF components and patches
As usual, Framework components and patches can be installed using either the
Tivoli Desktop or a command line.
In the this section, we show the command line-based installation, from which you
can extract the information you need to perform the installation using the Tivoli
Desktop installation GUI.
For information about how to navigate the Tivoli Desktop installation GUI, refer to
the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Management Framework →Enterprise Installation
Guide →Installing Tivoli Products and Patches.
The following instructions are two-tiered. The first set of instructions show how to
install the components on the hubtmr and related systems. The second set of
instructions shows the command for installing the same components on the
spoketmr and related systems.
Chapter 4. Installing the Tivoli Infrastructure
173
From the command line, the following commands install Tivoli Management
Framework components and patches:
򐂰 Java 1.3 for Tivoli
a. Run this command from hubtmr to install Java 1.3 for Tivoli on hubtmr, tec,
and srchost systems.
winstall –c /mnt/code/tivoli/TMF/411/all/generic/CD2/JAVA –i JRE130 –y
@CreatePaths@=1 hubtmr tec srchost
b. Run this command from spoketmr to install Java 1.3 for Tivoli on spoketmr,
region01, and outlet01 from your specific product path
winstall –c /mnt/code/tivoli/TMF/411/all/generic/CD2/JAVA –i JRE130 –y
@CreatePaths@=1 spoketmr region01 outlet01
򐂰 Tivoli Java RDBMS Interface Module (JRIM) 4.1.1
a. Run this command from hubtmr to install Tivoli Java RDBMS Interface
Module (JRIM) 4.1.1 on the hubtmr system:
winstall –c /mnt/code/tivoli/TMF/411/all/generic/CD2/JAVA –i JRIM411 –y
@CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install Tivoli Java RDBMS Interface
Module (JRIM) 4.1.1 on the spoketmr system:
winstall –c /mnt/code/tivoli/TMF/411/all/generic/CD2/JAVA –i JRIM411 –y
@CreatePaths@=1 spoketmr
򐂰 JavaHelp 1.0 for Tivoli
a. Run this command from hubtmr to install JavaHelp 1.0 for Tivoli on the
hubtmr system:
winstall –c /mnt/code/tivoli/TMF/411/all/generic/CD2/JAVA –i JHELP41 –y
@CreatePaths@=1 hubtmr
򐂰 Tivoli Java Client Framework 4.1.1
a. Run this command from hubtmr to install Tivoli Java Client Framework
4.1.1 on the hubtmr, tec and srchost systems:
winstall –c /mnt/code/tivoli/TMF/411/all/generic/CD2/JAVA –i JCF411 –y
@CreatePaths@=1 hubtmr tec srchost
b. Run this command from spoketmr to install Tivoli Java Client Framework
4.1.1 on the spoketmr, region01 and outlet01 systems:
winstall –c /mnt/code/tivoli/TMF/411/all/generic/CD2/JAVA –i JCF411 –y
@CreatePaths@=1 spoketmr region01 outlet01
򐂰 Distribution Status Console, Version 4.1.1
a. Run this command from hubtmr to install Distribution Status Console,
Version 4.1.1 on the hubtmr system:
174
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
winstall –c /mnt/code/tivoli/TMF/411/all/generic/CD2/JAVA –i MDIST2GU –y
@CreatePaths@=1 hubtmr
򐂰 Tivoli Management Framework SSLB Version 1.1
a. Run this command from hubtmr to install Tivoli Management Framework
SSLB Version 1.1 on the hubtmr, tec and srchost systems:
winstall –c /mnt/code/tivoli/TMF/411/all/generic/CD2/SSL –i SSLB –y
@CreatePaths@=1 hubtmr tec srchost
b. Run this command from spoketmr to install Tivoli Management Framework
SSLB Version 1.1 on the spoketmr, region01, and outlet01 systems:
winstall –c /mnt/code/tivoli/TMF/411/all/generic/CD2/SSL –i SSLB –y
@CreatePaths@=1 spoketmr region01 outlet01
򐂰 Tivoli Framework Patch 4.1.1-LCF-0008
a. Run this command from hubtmr to install Tivoli Framework Patch
4.1.1-LCF-0008 on the hubtmr, tec, and srchost systems:
wpatch –c /mnt/code/tivoli/TMF/411/LCF0008/generic –i 411LCF08 –y
@CreatePaths@=1 hubtmr tec srchost
b. Run this command from spoketmr to install Tivoli Framework Patch
4.1.1-LCF-0008 on the spoketmr, region01, and outlet01 systems:
wpatch –c /mnt/code/tivoli/TMF/411/LCF0008/generic –i 411LCF08 –y
@CreatePaths@=1 spoketmr region01 outlet01
򐂰 Tivoli Framework Patch 4.1.1-TMF-0011
a. Run this command from hubtmr to install Tivoli Framework Patch
4.1.1-TMF-0011 on the hubtmr system:
wpatch –c /mnt/code/tivoli/TMF/411/TMF0011/generic –i 411TMF11 –y
@CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install Tivoli Framework Patch
4.1.1-TMF-0011 on the spoketmr system:
wpatch –c /mnt/code/tivoli/TMF/411/TMF0011/generic –i 411TMF11 –y
@CreatePaths@=1 spoketmr
򐂰 Tivoli Framework Patch 4.1.1-TMF-0021
a. Run this command from hubtmr to install Tivoli Framework Patch
4.1.1-TMF-0021 on the hubtmr, tec, and srchost systems:
wpatch –c /mnt/code/tivoli/TMF/411/TMF0021/generic –i 411TMF21 –y
@CreatePaths@=1 hubtmr tec srchost
b. Run this command from spoketmr to install Tivoli Framework Patch
4.1.1-TMF-0021 on the spoketmr, region01, and outlet01 systems:
wpatch –c /mnt/code/tivoli/TMF/411/TMF0021/generic –i 411TMF21 –y
@CreatePaths@=1 spoketmr region01 outlet01
Chapter 4. Installing the Tivoli Infrastructure
175
򐂰 Tivoli Java Client Framework 4.1.1 Patch JCF411-0001
a. Run this command from hubtmr to install Tivoli Java Client Framework
4.1.1 Patch JCF411-0001 on the hubtmr, tec, and srchost systems:
wpatch –c /mnt/code/tivoli/TMF/411/JCF0001/generic –i JCF411 –y
@CreatePaths@=1 hubtmr tec srchost
b. Run this command from spoketmr to install Tivoli Java Client Framework
4.1.1 Patch JCF411-0001 on the spoketmr, region01, and outlet01
systems:
wpatch –c /mnt/code/tivoli/TMF/411/JCF0001/generic –i JCF411 –y
@CreatePaths@=1 spoketmr region01 outlet01
򐂰 Tivoli MDist 2 Graphical User Interface 4.1.1 002 Patch
a. Run this command from hubtmr to install Tivoli MDist 2 Graphical User
Interface 4.1.1 002 Patch on the hubtmr system:
wpatch –c /mnt/code/tivoli/TMF/411/TMF0011/generic/411MD202 –i 411MD202
–y @CreatePaths@=1 hubtmr
Verifying Framework component installation
To verify the installation of all the components and patches, check the
information in the Tivoli catalog for all installed components and patches. We
start with the instructions for using the Tivoli Desktop. The instructions for using
the command line start with step a on page 179.
򐂰 Using Tivoli Desktop
a. From the Tivoli Desktop, navigate to Desktop → About, which will
display the About Tivoli dialog box shown in Figure 4-14 on page 177.
176
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figure 4-14 About Tivoli
b. Press the Installed Products button to get the detailed list of installed
components, as in Figure 4-15 on page 178.
Chapter 4. Installing the Tivoli Infrastructure
177
Figure 4-15 Installed Products
c. For each component, highlight it and press the Patches button to view the
patches that have been applied to that specific component. Figure 4-16 on
page 179 shows the patches installed for Tivoli Management Framework.
178
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figure 4-16 Installed Patches
d. Use the Close button on all the previous windows to return to the Tivoli
Desktop.
򐂰 Using the command line
a. Use the wlsinst -ah command from the hubtmr system to obtain a list of
all the installed components and patches in the TMR. Check the output,
which should be similar to the list shown in Example 4-9.
Example 4-9 Installed Tivoli Components and patches
hubtmr:/mnt/code/tivoli # wlsinst -ah
*---------------------------------------------------------------------------*
Product List
*---------------------------------------------------------------------------*
Tivoli Management Framework 4.1.1
hubtmr
linux-ix86
srchost
linux-ix86
tec
linux-ix86
Tivoli Java Client Framework 4.1
hubtmr
linux-ix86
Tivoli Java Client Framework 4.1.1
hubtmr
linux-ix86
srchost
linux-ix86
tec
linux-ix86
Java 1.3 for Tivoli
Chapter 4. Installing the Tivoli Infrastructure
179
hubtmr
srchost
tec
linux-ix86
linux-ix86
linux-ix86
Tivoli Java RDBMS Interface Module (JRIM) 4.1
hubtmr
linux-ix86
Tivoli Java RDBMS Interface Module (JRIM) 4.1.1
hubtmr
linux-ix86
JavaHelp 1.0 for Tivoli
hubtmr
linux-ix86
Tivoli Management Framework SSLB Version 1.1
hubtmr
linux-ix86
srchost
linux-ix86
tec
linux-ix86
Distribution Status Console, Version 4.1.1
hubtmr
linux-ix86
*----------------------------------------------------------------------------*
Patch List
*----------------------------------------------------------------------------*
Tivoli Framework Patch 4.1.1-LCF-0008
hubtmr
linux-ix86
srchost
linux-ix86
tec
linux-ix86
(build 08/12)
Tivoli Framework Patch 4.1.1-TMF-0011
hubtmr
linux-ix86
(build 05/06)
Tivoli Framework Patch 4.1.1-TMF-0021
hubtmr
linux-ix86
srchost
linux-ix86
tec
linux-ix86
(build 09/20)
Tivoli Java Client Framework 4.1.1 Patch JCF411-0001
hubtmr
linux-ix86
srchost
linux-ix86
tec
linux-ix86
Tivoli MDist 2 Graphical User Interface 4.1.1 002 Patch
hubtmr
linux-ix86
180
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
b. To verify the installations in the spoke TMR environment, issue the
wlsinst -ah command from the spoketmr system.
At this point, all the TMR Servers and managed nodes are ready for receiving the
specialized components they need to fulfill their roles within the Outlet Systems
Management Solution.
Before you start using the newly installed Tivoli Framework functions, you should
complete the post-installation configuration steps described in 4.4.1, “Framework
customization” on page 223.
4.3.4 Tivoli Enterprise Console v3.9
The role of the Tivoli Enterprise Console (TEC) Server is to receive and process
all events generated from all systems in the Outlet Systems Management
Solution infrastructure.
Preparing for TEC installation
The preparation steps for installing the IBM Tivoli Enterprise Console v3.9
product, include the following:
1. ”Preparing installation media for TEC”
2. “Determining TEC Component locations” on page 182.
Preparing installation media for TEC
To prepare the media, complete these tasks:
1. Obtain the installation images for the following components, and unpack them
to the proper location on the srchost server in the <img_dir>/code directory
structure:
– IBM Tivoli Enterprise Console (TME New Installations) V3.9 Multi Int
English
<img_dir>/code/tivoli/TEC/3.9.0/all/generic/NewInstall
– IBM Tivoli Enterprise Console Version 3.9.0 LA Interim Fix 03
<img_dir>/code/tivoli/TEC/3.9.0/TEC-0003LA/generic/Wizard
– IBM Tivoli Enterprise Console Version 3.9.0 Fix Pack 2
<img_dir>/code/tivoli/TEC/3.9.0_fp02/all/generic
To determine which installation images you need, and from where they can be
downloaded, refer to Table B-1 on page 647.
2. Make the installation image accessible from the tec system using NFS or
SMB mount:
smbmount //srchost/img /mnt -o username=root,password=<password>
Chapter 4. Installing the Tivoli Infrastructure
181
Determining TEC Component locations
Table 4-14 outlines which TEC components to install where, in accordance with
the functional roles of the systems described in 4.1.1, “Management
environments” on page 131.
Table 4-14 TEC product and path installation roadmap
IBM Tivoli Enterprise Console Server 3.9
outlet01
x
region01
x
spoketmr
tec
IBM Tivoli Enterprise Console JRE 3.9
srchost
components
hubtmr
servers
x
x
x
x
x
x
x
x
x
x
x
x
x
IBM Tivoli Enterprise Console User Interface
Server 3.9
x
IBM Tivoli Enterprise Console Console 3.9
x
IBM Tivoli Enterprise Console Adapter
Configuration Facility 3.9
x
IBM Tivoli Enterprise Console JRE Fix Pack 2
x
IBM Tivoli Enterprise Console Server Fix Pack 2
x
x
IBM Tivoli Enterprise Console User Interface
Server Fix Pack 2
x
IBM Tivoli Enterprise Console Console Fix Pack 2
x
IBM Tivoli Enterprise Console Adapter
Configuration Facility Fix Pack 2
x
Note: The Tivoli Enterprise Console JRE is an installable component and is a
requirement for the event server, the UI server, the event console, and the
Adapter Configuration Facility. This component makes the Java Runtime
environment available for use. As appropriate, the installation wizard installs
and uninstalls the Tivoli Enterprise Console JRE automatically. However, if
you are using the Tivoli Management Framework tools, you must perform
these operations manually.
Installing the TEC
The TEC components can be installed either through the Installation Wizard,
through the Tivoli Desktop, or from the command line.
182
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
In this section we show the command line-based installation, from which you can
extract the information needed to perform the installation using the Tivoli Desktop
installation GUI. For information about how to navigate the Tivoli Desktop
installation GUI, please refer to the IBM Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Management Framework →Enterprise Installation
Guide →Installing Tivoli Products and Patches.
For information about how to install Tivoli Enterprise Console components using
the Installation Wizard, refer to Enterprise Console →Installation Guide →
Installing, upgrading, and uninstalling using the Installation
Wizard →Using the Installation Wizard in the IBM Tivoli Information Center.
Important: You should be aware that the Installation Wizard performs both
initial installation and customization steps, so if you use the Installation
Wizard, some of the steps described in 4.4.4, “Configuring the Tivoli
Enterprise Console” on page 234 are obsolete.
To install the products and patches for the Tivoli Enterprise Console you should
perform the following steps:
򐂰 IBM Tivoli Enterprise Console JRE 3.9
a. Run this command from hubtmr to install IBM Tivoli Enterprise Console
JRE 3.9 on the hubtmr and tec systems:
winstall –c /mnt/code/tivoli/TEC/3.9.0/all/generic/NewInstall/cdrom –i
TECJRE –y @CreatePaths@=1 hubtmr tec
b. Run this command from spoketmr to install IBM Tivoli Enterprise Console
JRE 3.9 on the spoketmr, region01 and outlet01 systems:
winstall –c /mnt/code/tivoli/TEC/3.9.0/all/generic/NewInstall/cdrom –i
TECJRE –y @CreatePaths@=1 spoketmr region01 outlet01
򐂰 IBM Tivoli Enterprise Console Server 3.9
a. Run this command from hubtmr to install IBM Tivoli Enterprise Console
Server 3.9 on the tec system:
winstall –c /mnt/code/tivoli/TEC/3.9.0/all/generic/NewInstall/cdrom –i
SERVER –y @CreatePaths@=1 hubtmr tec
򐂰 IBM Tivoli Enterprise Console User Interface Server 3.9
a. Run this command from hubtmr to install IBM Tivoli Enterprise Console
User Interface Server 3.9 on the hubtmr system:
winstall –c /mnt/code/tivoli/TEC/3.9.0/all/generic/NewInstall/cdrom –i
UI_SRVR –y @CreatePaths@=1 hubtmr
Chapter 4. Installing the Tivoli Infrastructure
183
򐂰 IBM Tivoli Enterprise Console Console 3.9
a. Run this command from hubtmr to install IBM Tivoli Enterprise Console
Console 3.9 on the hubtmr system:
winstall –c /mnt/code/tivoli/TEC/3.9.0/all/generic/NewInstall/cdrom –i
CONSOLE –y @CreatePaths@=1 hubtmr
򐂰 IBM Tivoli Enterprise Console Adapter Configuration Facility 3.9
a. Run this command from hubtmr to install IBM Tivoli Enterprise Console
Adapter Configuration Facility 3.9 on the hubtmr system:
winstall –c /mnt/code/tivoli/TEC/3.9.0/all/generic/NewInstall/cdrom –i
ACF –y @CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install IBM Tivoli Enterprise Console
Adapter Configuration Facility 3.9 on the spoketmr, region01 and outlet01
systems:
winstall –c /mnt/code/tivoli/TEC/3.9.0/all/generic/NewInstall/cdrom –i
ACF –y @CreatePaths@=1 spoketmr region01 outlet01
– 3.9.0 Tivoli Enterprise Console JRE Fix Pack 2
a. Run this command from hubtmr to install 3.9.0 Tivoli Enterprise Console
JRE Fix Pack 2 on the hubtmr and tec systems:
wpatch –c <img_dir>/code/tivoli/TEC/3.9.0_fp02/alll/generic/TME –i
390JREFP –y @CreatePaths@=1 hubtmr tec
b. Run this command from spoketmr to install 3.9.0 Tivoli Enterprise Console
JRE Fix Pack 2 on the spoketmr, region01 and outlet01 systems:
wpatch –c <img_dir>/code/tivoli/TEC/3.9.0_fp02/all/generic/TME –i
390JREFP –y @CreatePaths@=1 spoketmr region01 outlet01
򐂰 3.9.0 Tivoli Enterprise Console Server Fix Pack 2
a. Run this command from hubtmr to install 3.9.0 Tivoli Enterprise Console
Server Fix Pack 2 on the tec system:
wpatch –c <img_dir>/code/tivoli/TEC/3.9.0_fp02/all/generic/TME –i
390SVRFP –y @CreatePaths@=1 tec
򐂰 3.9.0 Tivoli Enterprise Console User Interface Server Fix Pack 2
a. Run this command from hubtmr to install 3.9.0 Tivoli Enterprise Console
User Interface Server Fix Pack 2 on the hubtmr system:
wpatch –c <img_dir>/code/tivoli/TEC/3.9.0_fp02/all/generic/TME –i
390UISFP –y @CreatePaths@=1 hubtmr
򐂰 3.9.0 Tivoli Enterprise Console Console Fix Pack 2
a. Run this command from hubtmr to install 3.9.0 Tivoli Enterprise Console
Console Fix Pack 2 on the hubtmr system:
184
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
wpatch –c <img_dir>/code/tivoli/TEC/3.9.0_fp02/all/generic/TME –i
390CONFP –y @CreatePaths@=1 hubtmr
򐂰 3.9.0 Tivoli Enterprise Console ACF Fix Pack 2
a. Run this command from hubtmr to install 3.9.0 Tivoli Enterprise Console
ACF Fix Pack 2 on the hubtmr system:
wpatch –c <img_dir>/code/tivoli/TEC/3.9.0_fp02/all/generic/TME –i
390ACFFP –y @CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install 3.9.0 Tivoli Enterprise Console
ACF Fix Pack 2 on the spoketmr, region01 and outlet01 systems:
wpatch –c <img_dir>/code/tivoli/TEC/3.9.0_fp02/all/generic/TME –i
390ACFFP –y @CreatePaths@=1 spoketmr region01 outlet01
Verifying the TEC installation
Because the TEC components have not been customized yet, and therefore are
not operational, our installation verification will be limited to looking into the Tivoli
Registry to verify that the components have been registered correctly.
The verification can be performed from the Tivoli Desktop, similar to the
procedure described in “Verifying Framework component installation” on
page 176, or using the command line, as described in the following:
To verify the installation of the TEC components in each individual TMR
environment, use the wlsinst -h -s<component>. Example 4-10 shows the
verification steps performed in the Outlet Systems Management Solution Hub
TMR environment.
Example 4-10 TEC component installation verification on Hub TMR
wlsinst -h -s”IBM Tivoli Enterprise Console JRE 3.9”
IBM Tivoli Enterprise Console JRE 3.9
hubtmr
linux-ix86
tec
linux-ix86
wlsinst -h -s”IBM Tivoli Enterprise Console Console 3.9”
IBM Tivoli Enterprise Console Console 3.9
hubtmr
linux-ix86
wlsinst -h -s”IBM Tivoli Enterprise Console Server 3.9”
IBM Tivoli Enterprise Console Server 3.9
tec
linux-ix86
wlsinst -h -s”IBM Tivoli Enterprise Console User Interface Server 3.9”
IBM Tivoli Enterprise Console User Interface Server 3.9
hubtmr
linux-ix86
Chapter 4. Installing the Tivoli Infrastructure
185
wlsinst -h -s”IBM Tivoli Enterprise Console Adapter Configuration Facility 3.9”
IBM Tivoli Enterprise Console Adapter Configuration Facility 3.9
hubtmr
linux-ix86
wlsinst -h -s”3.9.0 Tivoli Enterprise Console JRE Fix Pack 2”
3.9.0 Tivoli Enterprise Console JRE Fix Pack 2
hubtmr
linux-ix86
tec
linux-ix86
wlsinst -h -s”3.9.0 Tivoli Enterprise Console Console Fix Pack 2”
3.9.0 Tivoli Enterprise Console Console Fix Pack 2
hubtmr
linux-ix86
wlsinst -h -s”3.9.0 Tivoli Enterprise Console Server Fix Pack 2”
3.9.0 Tivoli Enterprise Console Server Fix Pack 2
tec
linux-ix86
wlsinst -h -s”3.9.0 Tivoli Enterprise Console ACF Fix Pack 2”
3.9.0 Tivoli Enterprise Console ACF Fix Pack 2
hubtmr
linux-ix86
wlsinst -h -s”3.9.0 Tivoli Enterprise Console User Interface Server Fix Pack 2”
3.9.0 Tivoli Enterprise Console User Interface Server Fix Pack 2
hubtmr
linux-ix86
Similarly, Example 4-11 shows the verification steps performed in the Outlet
Systems Management Solution Spoke TMR environment.
Example 4-11 TEC component verification on spokeTMR
wlsinst -h -s”IBM Tivoli Enterprise Console JRE 3.9”
IBM Tivoli Enterprise Console JRE 3.9
outlet01
linux-ix86
region01
linux-ix86
spoketmr
linux-ix86
wlsinst -h -s”IBM Tivoli Enterprise Console Adapter Configuration Facility 3.9”
IBM Tivoli Enterprise Console Adapter Configuration Facility 3.9
outlet01
linux-ix86
region01
linux-ix86
spoketmr
linux-ix86
wlsinst -h -s”3.9.0 Tivoli Enterprise Console JRE Fix Pack 2”
3.9.0 Tivoli Enterprise Console JRE Fix Pack 2
outlet01
linux-ix86
region01
linux-ix86
spoketmr
linux-ix86
wlsinst -h -s”3.9.0 Tivoli Enterprise Console ACF Fix Pack 2”
186
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
3.9.0 Tivoli Enterprise Console ACF Fix Pack 2
outlet01
linux-ix86
region01
linux-ix86
spoketmr
linux-ix86
Note: To verify installation, you might find it easier to use the general
command wlsinst -ah to list all products and patches on all systems in each
TMR. However, doing this will result in much more output, through which you
will need to scan.
Before you start using the newly installed Tivoli Enterprise Console functions,
you should complete the post-installation configuration steps described in 4.4.4,
“Configuring the Tivoli Enterprise Console” on page 234.
4.3.5 Installing Tivoli Configuration Manager
This section details the installation of the Inventory, Software Distribution, Activity
Planner, and Change Manager components of the Tivoli Configuration Manager
v4.2.1 product.
Preparing for TCM installation
The preparation steps for installing the IBM Tivoli Configuration Manager v4.2.1
product, include the following:
1. ”Preparing installation media for TCM”
2. “Determining TCM Component locations” on page 188
Preparing installation media for TCM
Obtain the installation images for the following components, and unpack them to
the proper location on the srchost server in the <img_dir>/code directory
structure:
򐂰 Tivoli Management Framework v4.1.1 Compatibility
<img_dir>/code/tivoli/TMF/411/all/generic/Compatibility
򐂰 IBM Tivoli Configuration Manager Installation v4.2.1, Multiplatform, Brazilian
Portuguese, French, German, International English, Italian, Japanese,
Korean, Simplified Chinese, Spanish
<img_dir>/code/tivoli/TCM/421/all/generic/cd5
򐂰 IBM Tivoli Configuration Manager v4.2.1, Multiplatform, Brazilian Portuguese,
French, German, International English, Italian, Japanese, Korean, Simplified
Chinese, Spanish
<img_dir>/code/tivoli/TCM/421/all/generic/cd1
Chapter 4. Installing the Tivoli Infrastructure
187
򐂰 IBM Tivoli Configuration Manager Web Gateway v4.2.1, Multiplatform,
Brazilian Portuguese, French, German, International English, Italian,
Japanese, Korean, Simplified Chinese, Spanish
<img_dir>/code/tivoli/TCM/421/all/generic/cd4
򐂰 IBM Tivoli Configuration Manager Windows v4.2.1, Brazilian Portuguese,
French, German, International English, Italian, Japanese, Korean, Simplified
Chinese, Spanish
<img_dir>/code/tivoli/TCM/421/all/generic/Windows
򐂰 IBM Tivoli Configuration Manager Documentation v4.2.1, International
English,
<img_dir>/code/tivoli/TCM/421/all/generic/documentation
򐂰 IBM Tivoli Configuration Manager, Version 4.2.1,Fix Pack 4.2.1-TCM-FP01
(U498122)
<img_dir>/code/tivoli/TCM/421_fp01/all/generic
To determine which installation images you need, and from where they can be
downloaded, refer to Table B-1 on page 647.
Make the installation image accessible from the rdbms system using NFS or
SMB mount:
smbmount //srchost/img /mnt -o username=root,password=<password>
Determining TCM Component locations
Table 4-15 outlines which TCM related components to install where, in
accordance with the functional roles of the systems described in “Management
environments” on page 131.
Table 4-15 TCM product and patch installation roadmap
188
spoketmr
region01
outlet01
srchost
tec
servers
hubtmr
components
x
x
x
x
x
Tivoli Scalable Collection Service
4.1.1
x
Tivoli Java Client Framework 4.1a
x
x
Tivoli Inventory Server 4.2.1
x
x
Tivoli Inventory Gateway 4.2.1
x
x
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
x
x
TIvoli Software Distribution Gateway
4.2.1
x
x
Tivoli Software Distribution Software
Package Editor 4.2.1
x
x
Tivoli Java RDBMS Interface Module
(JRIM) 4.1b
x
Activity Planner, Version 4.2.1
x
Change Manager, Version 4.2.1
x
Tivoli Scalable Collection Service
4.1.1 Fix Pack 4.1.1-CLL-FP01
x
x
Tivoli Inventory Server 4.2.1 Fix Pack
4.2.1-INV-FP01
x
x
Tivoli Inventory Gateway 4.2.1 Fix
Pack 4.2.1-INVGW-FP01
x
x
Tivoli Inventory Server 4.2.1 Interim
Fix 4.2.1-INV-0006
x
x
Tivoli Inventory Gateway 4.2.1
Interim Fix 4.2.1-INV-0006
x
x
Tivoli Software Distribution 4.2.1 Fix
Pack 4.2.1-SWDSRV-FP01
x
TIvoli Software Distribution Gateway
4.2.1 Fix Pack 4.2.1-SWDGW-FP01
x
x
Tivoli Software Distribution Software
Package Editor 4.2.1 Fix Pack
4.2.1-SWDJSP-FP01
x
x
Activity Planner Fix Pack
4.2.1-APM-FP01
x
Change Manager Fix Pack
4.2.1-CCM-FP01
x
x
outlet01
spoketmr
x
Tivoli Software Distribution 4.2.1
region01
srchost
tec
servers
hubtmr
components
x
x
x
x
x
x
x
x
x
x
x
Chapter 4. Installing the Tivoli Infrastructure
189
a. Will be found in the Compatibility folder in the TMF installation path
b. Tivoli Java RDBMS Interface Module (JRIM) 4.1 is a prerequisite for Activity
Planner
Installing the TCM components
The Tivoli Configuration Manager components can be installed either through the
Installation Wizard, through the Tivoli Desktop, or through command line
commands.
In the following we show the command line based installation, from which you
will be able to deduct the information needed to perform the installation using the
Tivoli Desktop installation GUI. For information about how to navigate the Tivoli
Desktop installation GUI, please refer to the IBM Tivoli Information Center Web
site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Management Framework →Enterprise Installation
Guide →Installing Tivoli Products and Patches.
For information about how to install Tivoli Configuration Manager components
using the Installation Wizard, refer to Configuration Manager →Installation
Guide → Component Installation Prerequisites →IBM Tivoli Configuration
Manager InstallShield Wizard in the IBM Tivoli Information Center.
Important: You should be aware that the Installation Wizard performs both
initial installation and customization steps, so if this installation method is
used, some of the steps described in 4.4.5, “Customizing the Inventory” on
page 238 and related sections be obsolete.
To install the products and patches for the Tivoli Configuration Manager through
the command line interface you should perform the following steps:
򐂰 Tivoli Java Client Framework 4.1
a. Run this command from hubtmr to install Tivoli Java Client Framework 4.1
on the hubtmr system:
winstall –c /mnt/code/tivoli/TMF/411/all/generic/Compatibility –i JCF41
–y @CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install Tivoli Java Client Framework
4.1 on spoketmr from your specific product path
winstall –c /mnt/code/tivoli/TMF/411/all/generic/Compatibility –i JCF41
–y @CreatePaths@=1 spoketmr
򐂰 Tivoli Java RDBMS Interface Module (JRIM) 4.1
190
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
a. Run this command from hubtmr to install Tivoli Java RDBMS Interface
Module (JRIM) 4.1 on the hubtmr system:
winstall –c /mnt/code/tivoli/TMF/411/all/generic/Compatibility –i JRIM
–y @CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install Tivoli Java RDBMS Interface
Module (JRIM) 4.1 on the spoketmr system:
winstall –c /mnt/code/tivoli/TMF/411/all/generic/Compatibility –i JRIM
–y @CreatePaths@=1 spoketmr
򐂰 Scalable Collection Service, Version 4.1.1
a. Run this command from hubtmr to install Scalable Collection Service,
Version 4.1.1 on the hubtmr system:
wpatch –c /mnt/code/tivoli/TCM/421/all/generic/cd1/MCOLLECT –i MCOLLECT
–y @CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install Scalable Collection Service,
Version 4.1.1 on the spoketmr, region01 and outlet01 systems:
wpatch –c /mnt/code/tivoli/TCM/421/all/generic/cd1/MCOLLECT –i MCOLLECT
–y @CreatePaths@=1 spoketmr region01 outlet01
Note: The installation of the first component, Scalable Collection
Service, Version 4.1.1, is a required patch install to enable the Inventory
installation.
򐂰 Inventory, Version 4.2.1
c. Run this command from hubtmr to install Inventory, Version 4.2.1 on the
hubtmr system:
winstall –c /mnt/code/tivoli/TCM/421/all/generic/cd1/INVENTORY –i
421_INV –y @CreatePaths@=1 hubtmr
d. Run this command from spoketmr to install Inventory, Version 4.2.1 on the
spoketmr system:
winstall –c /mnt/code/tivoli/TCM/421/all/generic/cd1/INVENTORY –i
421_INV –y @CreatePaths@=1 spoketmr
򐂰 Inventory Gateway, Version 4.2.1
a. Run this command from hubtmr to install Inventory Gateway, Version 4.2.1
on the hubtmr:
winstall –c /mnt/code/tivoli/TCM/421/all/generic/cd1/INVENTORY –i
421_GW_F –y @CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install Inventory Gateway, Version
4.2.1 on the spoketmr, region01 and outlet01 systems:
Chapter 4. Installing the Tivoli Infrastructure
191
winstall –c /mnt/code/tivoli/TCM/421/all/generic/cd1/INVENTORY –i
421_GW_F –y @CreatePaths@=1 spoketmr region01 outlet01
򐂰 Software Distribution, Version 4.2.1
a. Run this command from hubtmr to install Software Distribution, Version
4.2.1 on the hubtmr and srchost systems:
winstall –c /mnt/code/tivoli/TCM/421/all/generic/cd1/SWD –i SWDIS –y
@CreatePaths@=1 hubtmr srchost
b. Run this command from spoketmr to install Software Distribution, Version
4.2.1 on the spoketmr system:
winstall –c /mnt/code/tivoli/TCM/421/all/generic/cd1/SWD –i SWDIS –y
@CreatePaths@=1 spoketmr
򐂰 Software Distribution Gateway, Version 4.2.1
a. Run this command from hubtmr to install Software Distribution Gateway,
Version 4.2.1 on the hubtmr system:
winstall –c <img_dir>/code/tivoli/TCM/421/all/generic/cd1/SWD –i SWDISGW
–y @CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install Software Distribution Gateway,
Version 4.2.1 on the spoketmr, region01 and outlet01 systems:
winstall –c /mnt/code/tivoli/TCM/421/all/generic/cd1/SWD –i SWDISGW –y
@CreatePaths@=1 spoketmr region01 outlet01
򐂰 Software Distribution Software Package Editor, Version 4.2.1
a. Run this command from hubtmr to install Software Distribution Software
Package Editor, Version 4.2.1 on the hubtmr and srchost systems:
winstall –c /mnt/code/tivoli/TCM/421/all/generic/cd1/SWD –i SWDISJPS –y
@CreatePaths@=1 hubtmr srchost
򐂰 Activity Planner, Version 4.2.1
a. Run this command from hubtmr to install Activity Planner, Version 4.2.1 on
the hubtmr system:
winstall –c /mnt/code/tivoli/TCM/421/all/generic/cd1/SWD –i APM –y
@CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install Activity Planner, Version 4.2.1
on the spoketmr system:
winstall –c /mnt/code/tivoli/TCM/421/all/generic/cd1/SWD –i APM –y
@CreatePaths@=1 spoketmr
򐂰 Change Manager, Version 4.2.1
a. Run this command from hubtmr to install Change Manager, Version 4.2.1
on hubtmr system:
192
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
winstall –c /mnt/code/tivoli/TCM/421/all/generic/cd1/SWD –i CCM –y
@CreatePaths@=1 hubtmr
򐂰 Scalable Collection Service 4.1.1, Fixpack 4.1.1-CLL-FP01
a. Run this command from hubtmr to install Scalable Collection Service
4.1.1, Fixpack 4.1.1-CLL-FP01 on the hubtmr system:
wpatch –c /mnt/code/tivoli/TCM/411/CCLFP01/generic –i 411CLLFP –y
@CreatePaths@=1 hubtmr tec srchost
b. Run this command from spoketmr to install Scalable Collection Service
4.1.1, Fixpack 4.1.1-CLL-FP01 on the spoketmr, region01, and outlet01
systems:
wpatch –c /mnt/code/tivoli/TCM/411/CCLFP01/generic –i 411CLLFP –y
@CreatePaths@=1 spoketmr region01 outlet01
򐂰 Inventory, Version 4.2.1, Fix Pack 4.2.1-INV-FP01
a. Run this command from hubtmr to install Inventory, Version 4.2.1, Fix
Pack 4.2.1-INV-FP01 (U498122 - 2004/06) on the hubtmr system:
wpatch –c /mnt/code/tivoli/TCM/421_fp01/all/generic/cd1/images/INV –i
421INVFP –y @CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install Inventory, Version 4.2.1, Fix
Pack 4.2.1-INV-FP01 (U498122 - 2004/06) on the spoketmr system:
wpatch –c /mnt/code/tivoli/TCM/421_fp01/all/generic/cd1/images/INV –i
421INVFP –y @CreatePaths@=1 spoketmr
򐂰 Inventory Gateway, Version 4.2.1, Fix Pack 4.2.1-INVGW-FP01
a. Run this command from hubtmr to install Inventory Gateway, Version
4.2.1, Fix Pack 4.2.1-INVGW-FP01 (U498122 - 2004/06) on the hubtmr
from your specific patch path
wpatch –c /mnt/code/tivoli/TCM/421_fp01/all/generic/cd1/images/INV –i
421LCFFP –y @CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install Inventory Gateway, Version
4.2.1, Fix Pack 4.2.1-INVGW-FP01 (U498122 - 2004/06) on the spoketmr,
region01 and outlet01 system:
wpatch –c /mnt/code/tivoli/TCM/421_fp01/all/generic/cd1/images/INV –i
421LCFFP –y @CreatePaths@=1 spoketmr region01 outlet01
򐂰 Inventory, Version 4.2.1, Interim Fix 4.2.1-INV-0006
a. Run this command from hubtmr to install Inventory, Version 4.2.1, Interim
Fix 4.2.1-INV-0006 on the hubtmr system:
wpatch –c /mnt/code/tivoli/TCM/421/INV0006/generic –i 421INV06 –y
@CreatePaths@=1 hubtmr
Chapter 4. Installing the Tivoli Infrastructure
193
b. Run this command from spoketmr to install Inventory, Version 4.2.1,
Interim Fix 4.2.1-INV-0006 on the spoketmr system:
wpatch –c /mnt/code/tivoli/TCM/421/INV0006/generic –i 421INV06 –y
@CreatePaths@=1 spoketmr
򐂰 Inventory Gateway, Version 4.2.1, Interim Fix 4.2.1-INVGW-0006
a. Run this command from hubtmr to install Inventory Gateway, Version
4.2.1, Interim Fix 4.2.1-INVGW-0006 on the hubtmr system:
wpatch –c /mnt/code/tivoli/TCM/421/INV0006/generic –i 421LCF06 –y
@CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install Inventory Gateway, Version
4.2.1, Interim Fix 4.2.1-INVGW-0006 on the spoketmr, region01, and
outlet01 systems:
wpatch –c /mnt/code/tivoli/TCM/421/INV0006/generic –i 421LCF06 –y
@CreatePaths@=1 spoketmr region01 outlet01
򐂰 Software Distribution, Version 4.2.1, Fix Pack 4.2.1-SWDSRV-FP01
a. Run this command from hubtmr to install Software Distribution, Version
4.2.1, Fix Pack 4.2.1-SWDSRV-FP01 (U498122 - 2004/06) on the hubtmr
and srchost systems:
wpatch –c /mnt/code/tivoli/TCM/421_fp01/all/generic/cd1/images/SWD –i
SWDFP1 –y @CreatePaths@=1 hubtmr srchost
򐂰 Software Distribution Gateway, Version 4.2.1, Fix Pack 4.2.1-SWDGW-FP01
a. Run this command from hubtmr to install Software Distribution Gateway,
Version 4.2.1, Fix Pack 4.2.1-SWDGW-FP01 (U498122 - 2004/06) on the
hubtmr system:
wpatch –c /mnt/code/tivoli/TCM/421_fp01/all/generic/cd1/images/SWD –i
SDGWFP1 –y @CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install Software Distribution Gateway,
Version 4.2.1, Fix Pack 4.2.1-SWDGW-FP01 (U498122 - 2004/06) on the
spoketmr, region01, and outlet01 systems:
wpatch –c /mnt/code/tivoli/TCM/421_fp01/all/generic/cd1/images/SWD –i
SDGWFP1 –y @CreatePaths@=1 spoketmr region01 outlet01
򐂰 Software Distribution Software Package Editor, Version 4.2.1, Fix Pack
4.2.1-SWDJPS-FP01
a. Run this command from hubtmr to install Software Distribution Software
Package Editor, Version 4.2.1, Fix Pack 4.2.1-SWDJPS-FP01 (U498122 2004/06) on the hubtmr and srchost systems:
wpatch –c /mnt/code/tivoli/TCM/421_fp01/all/generic/cd1/images/SWD –i
SDJPFP1 –y @CreatePaths@=1 hubtmr srchost
194
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
򐂰 Activity Planner, Version 4.2.1, Fix Pack 4.2.1-APM-FP01
a. Run this command from hubtmr to install Activity Planner, Version 4.2.1,
Fix Pack 4.2.1-APM-FP01 (U498122 - 2004/06 on the hubtmr system:
wpatch –c /mnt/code/tivoli/TCM/421_fp01/all/generic/cd1/images/SWD –i
APMFP1 –y @CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install Activity Planner, Version 4.2.1,
Fix Pack 4.2.1-APM-FP01 (U498122 - 2004/06 on the spoketmr system:
wpatch –c /mnt/code/tivoli/TCM/421_fp01/all/generic/cd1/images/SWD –i
APMFP1 –y @CreatePaths@=1 spoketmr
򐂰 Change Manager, Version 4.2.1, Fix Pack 4.2.1-CCM-FP01
a. Run this command from hubtmr to install Change Manager, Version 4.2.1,
Fix Pack 4.2.1-CCM-FP01 (U498122 - 2004/06) on the hubtmr system:
b. wpatch –c /mnt/code/tivoli/TCM/421_fp01/all/generic/cd1/images/SWD –i
CCMFP1 –y @CreatePaths@=1 hubtmr
Verifying the TCM component installation
As was the case for the TEC components, the TCM environment has not yet
been customized, and is therefore not operational at this point, The installation
verification will be limited to looking into the Tivoli Registry to verify that the
components have been registered correctly.
The verification can be performed from the Tivoli Desktop, similar to the
procedure described in “Verifying Framework component installation” on
page 176, or using the command line, as described in the following:
To verify the installation of the TCM components in each individual TMR
environment, use the wlsinst -ah. Example 4-12 shows the verification
information related to the TCM components installed in the Outlet Systems
Management Solution Hub TMR environment.
Example 4-12 TCM Components installed
hubtmr:~ # wlsinst -ah | more
*-----------------------------------------------------------------------------*
Product List
*-----------------------------------------------------------------------------*
Inventory Gateway, Version 4.2.1
hubtmr
linux-ix86
Inventory, Version 4.2.1
hubtmr
linux-ix86
Chapter 4. Installing the Tivoli Infrastructure
195
Tivoli Java RDBMS Interface Module (JRIM) 4.1
hubtmr
linux-ix86
Tivoli Java RDBMS Interface Module (JRIM) 4.1.1
hubtmr
linux-ix86
Activity Planner, Version 4.2.1
hubtmr
linux-ix86
Change Manager, Version 4.2.1
hubtmr
linux-ix86
Software Distribution , Version 4.2.1
hubtmr
linux-ix86
srchost
linux-ix86
Software Distribution Gateway, Version 4.2.1
hubtmr
linux-ix86
Software Distribution Software Package Editor, Version 4.2.1
hubtmr
linux-ix86
srchost
linux-ix86
*-----------------------------------------------------------------------------*
Patch List
*-----------------------------------------------------------------------------*
Activity Planner, Version 4.2.1, Fix Pack 4.2.1-APM-FP01 (U498122 - 2004/06)
hubtmr
linux-ix86
Change Manager, Version 4.2.1, Fix Pack 4.2.1-CCM-FP01 (U498122 - 2004/06)
hubtmr
linux-ix86
Inventory, Version 4.2.1, Interim Fix 4.2.1-INV-0006
hubtmr
linux-ix86
Inventory, Version 4.2.1, Fix Pack 4.2.1-INV-FP01 (U498122 - 2004/06)
hubtmr
linux-ix86
Inventory Gateway, Version 4.2.1, Interim Fix 4.2.1-INVGW-0006
hubtmr
linux-ix86
Inventory Gateway, Version 4.2.1, Fix Pack 4.2.1-INVGW-FP01 (U498122 - 2004/06)
hubtmr
linux-ix86
Software Distribution Gateway, Version 4.2.1, Fix Pack 4.2.1-SWDGW-FP01
(U498122 - 2004/06)
hubtmr
linux-ix86
196
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Software Distribution Software Package Editor, Version 4.2.1, Fix Pack
4.2.1-SWDJPS-FP01 (U498122 - 2004/06)
hubtmr
linux-ix86
Software Distribution, Version 4.2.1, Fix Pack 4.2.1-SWDSRV-FP01 (U498122 2004/06)
hubtmr
linux-ix86
srchost
linux-ix86
Scalable Collection Service, Version 4.1.1
hubtmr
linux-ix86
1. To verify the TCM component installation in the spoke TMR environment,
issue the wlsinst -ah command from the spoketmr.
2. Before you start using the newly installed Tivoli Configuration Manager
functions, complete the post-installation configuration steps described in
4.4.5, “Customizing the Inventory” on page 238 through 4.4.8, “Enabling
Change Manager” on page 252.
4.3.6 IBM Tivoli Monitoring installation
This procedure describes how to install IBM Tivoli Monitoring v5.1.2 in the Data
Center to enable the monitoring of resources in the Outlet Systems Management
Solution environment. The Web Health Console Installation is also included in
this step.
Preparing for the ITM Installation
The preparation steps for installing the IBM Tivoli Monitoring v5.1.2 product,
include the following:
1. ”Preparing installation media for ITM”
2. “Determining ITM Component locations” on page 198.
Preparing installation media for ITM
Obtain the installation images for the following components, and unpack them to
the proper location on the srchost server in the <img_dir>/code directory
structure:
򐂰 Tivoli Management Framework v4.1.1 Compatibility
򐂰 Tivoli Monitoring Install V5.1.2 Multi Int Engl Braz Port French Italian German
Spanish Japanese Korean Simp Chin Trad Chin
<img_dir>/code/tivoli/ITM/512/all/generic
Chapter 4. Installing the Tivoli Infrastructure
197
򐂰 Tivoli Monitoring V5.1.2 Multi Int English
<img_dir>/code/tivoli/ITM/512/all/generic
򐂰 Tivoli Monitoring Tools V5.1.2 Multi Int English Braz Port French Italian
German Spanish Japanese Korean Simp Chin Trad Chin
<img_dir>/code/tivoli/ITM/512/tools/generic
򐂰 Tivoli Monitoring Web Health Console V5.1.2 Fixpack 6 Multi Int Engl Braz
Port French Italian German Spanish Japanese Korean Simp Chin Trad Chin
<img_dir>/code/tivoli/ITM/512/WHCFP06/generic
򐂰 Obtain Web Health Console for WebSphere 5.1 from your local Tivoli Support
organization
򐂰 Fix Pack (5.1.2-ITM-FP02) for IBM Tivoli Monitoring 5.1.2
<img_dir>/code/tivoli/ITM/512_fp02/all/generic
򐂰 IBM Tivoli Monitoring Component Services 5.1.1 Fix Pack 2
<img_dir>/code/tivoli/ITM/511/ICSFP02/generic
To determine which installation images you need, and from where they can be
downloaded, refer to Table B-1 on page 647.
Make the installation image accessible from the rdbms system using NFS or
SMB mount:
smbmount //srchost/img /mnt -o username=root,password=<password>
Determining ITM Component locations
Table 4-16 outlines which ITM related components to install where, in
accordance with the functional roles of the systems described in 4.1.1,
“Management environments” on page 131.
Table 4-16 IBM Tivoli Monitoring product and patch installation roadmap
198
outlet01
console
region01
IBM Tivoli Monitoring Web Health
Console 5.1.1a
IBM Tivoli Monitoring Component
Services 5.1.1b
srchost
x
spoketmr
IBM Tivoli Monitoring 5.1.2
tec
servers
hubtmr
components
x
x
x
x
x
x
x
x
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
outlet01
x
x
IBM Tivoli Monitoring for Database
5.1.1 - DB2 Component Software
5.1.0
x
x
x
x
IBM Tivoli Monitoring 5.1.2 Fix Pack 2
x
x
x
x
IBM Tivoli Monitoring Web Health
Console 5.1.1 Fix Pack 6
console
x
srchost
x
tec
IBM Tivoli Monitoring for Web
Infrastructure 5.1.2 - WAS
hubtmr
region01
servers
spoketmr
components
x
IBM Tivoli Monitoring Component
Services 5.1.1 Fix Pack 2
x
x
x
x
IBM Tivoli Monitoring for Web
Infrastructure 5.1.2 - WAS Fix Pack 2
x
x
x
x
IBM Tivoli Monitoring for Database
5.1.1 - DB2 Component Software
5.1.0 Fix Pack 5
x
x
x
x
a. Uses the installation wizard. See the IBM Tivoli Monitoring Users Guide for
more information
b. ITMCS511 is a patch install
Installing the IBM Tivoli Monitoring components
The IBM Tivoli Monitoring components can be installed either through the
Installation Wizard, through the Tivoli Desktop, or through command line
commands.
In the following we show the command line based installation, from which you
will be able to deduct the information needed to perform the installation using the
Tivoli Desktop installation GUI. For information about how to navigate the Tivoli
Desktop installation GUI, refer to the IBM Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Management Framework →Enterprise Installation
Guide →Installing Tivoli Products and Patches.
Chapter 4. Installing the Tivoli Infrastructure
199
For information about how to install IBM Tivoli Monitoring components using the
Installation Wizard, refer to the manual IBM Tivoli Monitoring User's Guide,
Version 5.1.2, SH19-4569-03.
Important: You should be aware that the Installation Wizard performs both
initial installation and customization steps, so if this installation method is
used, some of the steps described in 4.4.9, “IBM Tivoli Monitoring
configuration” on page 255 and related sections can be obsolete.
To install the products and patches for IBM Tivoli Monitoring through the
command line interface, perform the following steps:
򐂰 IBM Tivoli Monitoring, Version 5.1.2
a. Run this command from hubtmr to install IBM Tivoli Monitoring, Version
5.1.2 on the hubtmr system:
winstall –c /mnt/code/tivoli/ITM/512/all/generic/ITM –i DM512 –y
@CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install IBM Tivoli Monitoring, Version
5.1.2 on the spoketmr, region01 and outlet01 systems:
winstall –c /mnt/code/tivoli/ITM/512/all/generic/ITM –i DM512 –y
@CreatePaths@=1 spoketmr region01 outlet01
򐂰 IBM Tivoli Monitoring, Version 5.1.2 - Fix Pack 2
a. Run this command from hubtmr to install IBM Tivoli Monitoring, Version
5.1.2 - Fix Pack 2 on the hubtmr system:
wpatch –c /mnt/code/tivoli/ITM/512/ITMFP02/generic/cdrom –i 512ITM02 –y
@CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install IBM Tivoli Monitoring, Version
5.1.2 - Fix Pack 2 on the spoketmr, region01 and outlet01 systems:
wpatch –c /mnt/code/tivoli/ITM/512/ITMFP02/generic/cdrom –i 512ITM02 –y
@CreatePaths@=1 spoketmr region01 outlet01
Verifying IBM Tivoli Monitoring installation
As was the case for other Tivoli components, the ITM environment has not yet
been customized, and are therefore not operational at this point, The installation
verification will be limited to looking into the Tivoli Registry to verify that the
components has been registered correctly.
The verification can be performed from the Tivoli Desktop, similar to the
procedure described in “Verifying Framework component installation” on
page 176, or using the command line, as in Example 4-13 on page 201.
200
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
To verify the installation of the TCM components in each individual TMR
environment, use the wlsinst -a -s<Component>. Example 4-13 shows the
verification information related to the TCM components installed in the Outlet
Systems Management Solution Hub TMR environment.
Example 4-13 ITM Components installed
hubtmr:~ # wlsinst -h -s"IBM Tivoli Monitoring, Version 5.1.2"
IBM Tivoli Monitoring, Version 5.1.2
hubtmr
linux-ix86
hubtmr:~ # wlsinst -h -s"IBM Tivoli Monitoring, Version 5.1.2 - fix pack 2"
IBM Tivoli Monitoring, Version 5.1.2 - fix pack 2
hubtmr
linux-ix86
To verify the ITM component installation in the spoke TMR environment, issue
the wlsinst -ah or wlsinst -h -s<Component> command from the spoketmr.
Before you start using the newly installed Tivoli Configuration Manager functions,
complete the post-installation configuration steps described in 4.4.5,
“Customizing the Inventory” on page 238 through 4.4.9, “IBM Tivoli Monitoring
configuration” on page 255.
4.3.7 IBM Tivoli Manager Web Health Console
This procedure describes how to install IBM Tivoli Monitoring v5.1.2 Web Health
Console (WHC) to enable the surveillance of resources in the Outlet Systems
Management Solution environment.
The preparation steps for installing the IBM Tivoli Monitoring v5.1.2 product,
include the following:
1. “Preparing the installation media for WHC” on page 202
2. “Determining WHC Component locations” on page 202
Before embarking on this task, you should determine if you wish to install the
generally available Web Health Console version v5.1.1, which requires
WebSphere Application Server v4, or the updated Web Health Console v5.1 for
WebSphere Application Server v5.1, an update that is available from Tivoli
Support.
Please note, that during installation of the generally available WHC, WebSphere
Application Server v4 is installed under the covers. For the updated version, you
are required to install WebSphere Application Server v5.1 manually.
Chapter 4. Installing the Tivoli Infrastructure
201
Preparing the installation media for WHC
Obtain the installation images for the following components, and unpack them to
the proper location on the srchost server in the <img_dir>/code directory
structure:
򐂰 IBM Tivoli Monitoring Web Health Console V5.1.1 for Windows, Linux Braz
Port, French, Italian, German, Spanish, Japanese, Korean, Simp Chin, Trad
Chin, Int English
<img_dir>/code/tivoli/ITM/511/WHC/generic
򐂰 Tivoli Monitoring Web Health Console V5.1.2 Fixpack 6 Multi Int Engl Braz
Port French Italian German Spanish Japanese Korean Simp Chin Trad Chin
<img_dir>/code/tivoli/ITM/512/WHCFP06/generic
If you plan to install the Web Health Console on top of an existing WebSphere
Application Server v5.1 you should obtain the images for Web Health Console for
WebSphere 5.1 from your local Tivoli Support organization. In addition, you
should obtain the installation images for WebSphere Application Server v5.1.
򐂰 WebSphere Application Server v5.1 for Linux, (Brazilian Portuguese, French,
German, Italian, Japanese, Korean, Spanish, US English)
<img_dir>/code/websphere/was/510/server/Linux-IX86
򐂰 WebSphere Application Server V5.1.1 for Linux, Fixpack 1, English, Brazilian
Portuguese, French, German, Italian, Spanish, Japanese, Korean, Simplified
Chinese, Traditional Chinese
<img_dir>/code/websphere/was/510_fp1/appserver/Linux-IX86
To determine which installation images you need, and from where they can be
downloaded, refer to Table B-1 on page 647.
Make the installation image accessible from the rdbms system using NFS or
SMB mount:
smbmount //srchost/img /mnt -o username=root,password=<password>
Determining WHC Component locations
Table 4-17 on page 203 outlines which GA version WHC components to install
where, in accordance with the functional roles of the systems described in 4.1.1,
“Management environments” on page 131. Refer to Table 4-18 on page 203 for
information regarding components to install for the Limited Availability version of
WHC that will install on WebSphere Application Server v5.1.
202
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Table 4-17 Web Health Console installation roadmap: GA version
outlet01
outlet01
x
region01
IBM Tivoli Monitoring Web Health
Console 5.1.1 Fix Pack 6
region01
x
spoketmr
IBM Tivoli Monitoring Web Health
Console 5.1.1
spoketmr
console
srchost
tec
servers
hubtmr
components
x
x
x
Table 4-18 Web Health Console installation roadmap - LA version
console
srchost
tec
servers
hubtmr
components
IBM Tivoli Monitoring Web Health
Console LA Version for WAS 5.1 a
x
WebSphere Application Server v5.1
(x)
WebSphere Application Server V5.1.1
for Linux, Fixpack 1
(x)
a. Obtain the WHC LA version for WAS 5.1 from Tivoli Support
Installing WHC components
The following contains information about installing both the General Availability
version 5.1.1 of Web Health Console and the Limited Availability WHC for
WebSphere Application Server 5.1.
Installing WHC 5.1.1 GA
The IBM Tivoli Monitoring Web Health Console GA Version components are to
be installed through the Installation Wizard provided with the product. During
installation, a copy of WebSphere Application Server v4.01 Express will be
installed.
To install IBM Tivoli Monitoring Web Health Console 5.1.1, run the following
setup executable from the console system to launch the installation wizard and
follow the instructions in the wizard panels:
<img_dir>/code/tivoli/ITM/511/WHC/generic/setuplinux.bin
Chapter 4. Installing the Tivoli Infrastructure
203
Refer to the manual IBM Tivoli Monitoring User's Guide, Version 5.1.2,
SH19-4569-03 for additional information.
To apply ITM Web Health Console - FixPack 6, run the following command from
the console system to install on console
<img_dir>/code/tivoli/ITM/512/WHCFP06/generic/ITMWHS/disk1/5.1.1-WHC-FixPack6_l
in.bin
Installing WHC LA for WebSphere Application Server 5.1
Installation of the WHC for WebSphere Application Server 5.1 requires that the
WebSphere Application Server be installed prior to installation of the Web Health
Console.
Installing WebSphere Application Server v5.1 installation
Prior to installing the LA Version of the Tivoli Web Health Console for WAS 5.1
you have to install the WebSphere Application Server v5.1 on the console
system.
To install WebSphere Application Server 5.1 on the console system, open a
command shell from the desktop, and perform the following steps:
1. Ensure that the DISPLAY variable has been set.
export DISPLAY=<local ip-address>
<local ip-address> is the local address of the system, for example 10.1.2.3.
2. Add mqm and mqmbrkrs groups:
groupadd mqmbrkrs
groupadd mqm
3. Add the new user id mqm:
useradd -s /bin/bash -g mqm -m -d /home/mqm mqm
4. Add root to mqm and mqbrkrs groups:
usermod -G mqm,mqmbrkrs root
204
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Attention: Be aware of logging in appropriately to pick up secondary user
groups for root.
When the root user on all platforms, except Windows platforms, does not
belong to the mqbrkrs and mqm user groups, errors occur when installing
the embedded messaging feature.
On many systems, such as UnitedLinux, if you telnet and issue the id
command or the groups command, you cannot see the groups mqm or
mqbrkrs even though root can be assigned to them. Solve this problem in
one of two ways:
1. Use the ssh command to log into the server.
2. Issue the ‘su -’ command.
After using one of the methods above, verify the required groups with the
‘id’ command or the ‘groups’ command.
# id
uid=0(root) gid=0(root) groups=0(root)
# su # id
uid=0(root) gid=0(root)
groups=0(root),64(pkcs11),101(mqm),102(mqbrkrs)
3. Start the installation.
<img_dir>/code/WebSphere/was/510/appserver/Linux-IX86/install
4. Follow the prompts until installation is complete.
For additional information, refer to the IBM WebSphere Information Center Web
site:
http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp
Navigate to WebSphere Application Server, Version 5.1.x →Installing.
To install the products and patches for IBM Tivoli Monitoring through the
command line interface, you should perform the following steps:
– IBM Tivoli Monitoring, Version 5.1.2
WHC LA for WebSphere Application Server 5.1 installation
The IBM Tivoli Monitoring (ITM) Web Health Console (WHC) 5.1.1 was not
originally developed to be used with WebSphere Application Server v5. However,
these instructions walk you through exactly what is necessary to manually install
the application.
Chapter 4. Installing the Tivoli Infrastructure
205
Note: Even though you are installing this software manually, please obtain the
ITM WHC 5.1.1 installation CDs or downloads, as well as ITM WHC 5.1.1
Fixpack 6 or 7. These CDs or downloads have information that might be
needed later. The ITM WHC 5.1.1 documentation, release notes, and so forth,
should all still closely apply.
To manually set up Web Health Console on an existing WebSphere Application
Server v5.1 perform the following steps:
1. Install in a single server WebSphere 5 environment.
a. Open a Web browser to load the WebSphere Application Server
Administration Console at the following URL:
http://machinename:9090/admin
Log in using any username, or leave the username blank.
b. From the WebSphere Administration Console, install dm.ear. Accept all
defaults for installation, and save the WebSphere Application Server
master configuration after the install is complete.
i. Navigate though Node →Applications →Enterprise Applications.
ii. Click the install button and give the path to the dm.ear file from the
patch bundle.
iii. Accept all defaults; do not check anything; and click Finish.
iv. Select Save at the top of the page.
v. Click the Save button.
c. In the WebSphere Administration Console, set the classloader policy for
dm.war and DM Web Health Console.ear to PARENT_LAST as follows:
i. Navigate to Node →Applications →Enterprise Applications →DM
Web Health Console.
ii. Change classloader mode to PARENT_LAST and click OK.
iii. Select the link Save at the top of the page.
iv. Click the Save button.
v. Navigate to Node →Applications →Enterprise Applications →DM
Web Health Console →Web Modules →dm.war.
vi. Change classloader mode to PARENT_LAST and click OK.
vii. Select Save at the top of the page.
viii.Click the Save button.
2. Modify the tracing and logging location.
206
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
The WHC installation modifies a file to point to the correct location to put the
WHC log files. This log file entry is modified because the installer does not
know until install time under which drive to put the files, or whether it is a
UNIX drive or a Windows drive. As a result, you need to manually modify this
file to point to the proper location for log file output.
a. On each server in the cluster (or the single machine), edit the file
dm.war/WEB-INF/classes/PDLog.properties
Set file.fileDir for the appropriate platform in the Define FileHandlers
section, as shown in Example 4-14.
Example 4-14 WebSphere Application Server tracing and logging location
#----------------------------------------------------------------------# Define FileHandlers
#----------------------------------------------------------------------file.fileDir=/opt/Tivoli/AMW/logs/
(use whatever drive you like, but try and keep the path the same)
b. Restart the WebSphere Application Server
i. Stop the WebSphere server using the following command:
WHC_INSTALL_DIR/bin/stopServer.sh <serverName>
ii. Start the WebSphere server using the following command:
WHC_INSTALL_DIR/bin/startServer.sh <serverName>
3. SSL Considerations (Optional if you use SSL)
There are two SSL connections in use with the ITM WHC. The first is from the
browser to the ITM WHC server. The second is to the ITM WHC server to the
ITM TME server. The first SSL connection works exactly as it is described in
the ITM WHC documentation. The second SSL connection works with the
instructions found in the included SSL document.
4. UNIX Graphing Display
The original WebSphere Application Server 4 WHC had a headless issue,
where if no X Windowing server is loaded on the UNIX machine when the
WHC WebSphere Application Server was started, graphs would not display
properly. This problem only happened on UNIX machines and only when the
graphics server was not started first.
The included document called ITM511_release_notes.rtf describes this issue
in detail and how to solve it. The details are on page 8, item #2.
5. External WHC Launch
The WHC Fixpack 5 added a feature to externally launch the WHC using a
URL. When enough information is passed to it in the form of URL arguments,
Chapter 4. Installing the Tivoli Infrastructure
207
the WHC will automatically log in the user and display endpoint information.
This is not a required piece of the WHC. In fact, only one Tivoli application
(Tivoli Management for Transaction Performance, TMTP) uses it to launch
the WHC, so you can skip this step easily if you are not interested.
Steps to install the LaunchITM application:
a. Open a Web browser to the load the WebSphere Application Server
Administration Console at the following URL:
http://machinename:9090/admin
Log in using any username, or leave the username blank.
iii. From the Administrative Console, install LaunchITM.ear. Accept all
defaults for installation. Save WAS master configuration after the install
is complete.
iv. Navigate through Node Æ Applications Æ Enterprise Applications
and click the install button. Provide the path to the LaunchITM.ear
from the patch bundle.
v. Accept all defaults. Do not check anything. Click Finish.
vi. Select the link Save at the top of the page.
vii. Click the Save button.
b. On each server in the cluster (or single machine), edit the file ITM
Launcher.ear\LaunchITM.war\jsp\LaunchWHC.jsp
viii.Search for “String serverName = scheme + "://" + serverHostname;”
ix. Add the port to the serverName, so the string is replaced as follows:
String serverName = scheme + "://" + serverHostname + ì:port;
The port is 9080.
c. Follow Step 2b on page 207 to restart the WebSphere Application Server.
Now the ITM Web Health Console can be launched from the TMTP user
interface. In TMTP, the launch can be configured in the Web Health Console
setting on TMTP user interface. The user is requested to enter the Web Health
Server name in the following format:
http://host_computer_name(:port)
host_computer_name is the fully qualified host name for the computer that hosts
the WHC, and port is the WebSphere Application Server internal HTTP transport
port. The default port is 9080.
Other information required to be set are the TME host name, TME username and
TME password. For further instructions to launch from TMTP, refer to the TMTP
Users Guide.
208
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Verifying WHC installation
Opening the Web Health Console will verify the installation. This is accomplished
through a Web Browser
1. Connect to WHC.
– WHC on WebSphere Application Server v4
Connection to the original WebSphere Application Server v4 WHC server
from a Web browser was usually to the URL:
http://machine_name/itmwhc
This is only valid if it is installed on the default port 80. If WebSphere
Application Server is installed on a different port, you would have needed
to include that in the URL address:
http://machine_name:port/itmwhc
– WHC on WebSphere Application Server 5
The WebSphere Application Server 5 version of the Web Health Console
needs to connect to dmwhc, rather than itmwhc. Also, in WebSphere
Application Server 5 installation, the internal HTTP transport port is
configured by default to use port 9080. Thus, by default you would need to
use port 9080 to connect.
http://machine_name:9080/dmwhc
If you have manually changed the port to something other than 9080, you
will need to change that.
If you have turned on SSL security, it should be:
https://machine_name:SSL_PORT/dmwhc
2. Supply the following:
User:
Tivoli user ID
Password:
Password associated with the Tivoli User ID
Host:
The name of the managed node to which you want to
connect. In the Outlet Systems Management Solution
the hubtmr system is a good choice.
3. Click OK to connect to the Web Health Console.
4.3.8 IBM Tivoli Monitoring for Web Infrastructure
This section demonstrates how to install IBM Tivoli Monitoring for Web
Infrastructure v5.1.2 in order to enable the monitoring of WebSphere Application
Server v5.x resources in the Outlet Systems Management Solution.
Chapter 4. Installing the Tivoli Infrastructure
209
For detailed information about IBM Tivoli Monitoring for Web Infrastructure
related topics, refer to the information available at the IBM Tivoli Information
Center:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Monitoring for Web Infrastructure.
Preparing for the installation
The preparation steps for installing the IBM Tivoli Monitoring for Web
Infrastructure v5.1.2 and the related WebSphere Application Server feature
include the following:
1. ”Preparing the media for IBM Tivoli Monitoring”
2. “Determining component locations” on page 211
Preparing the media for IBM Tivoli Monitoring
Obtain the installation images for the following components, and unpack them to
the proper location on the srchost server in the <img_dir>/code directory
structure:
򐂰 Tivoli Monitoring for Web Infrastructure
Install V5.1.2 AIX HP-UX Linux Solaris Win2000 WinNT WinXP Int Engl Braz
Port French Italian German Spanish Japan Korea Simp Chin Trad Chin
<img_dir>/code/tivoli/ITMWI/512/all/generic
򐂰 Tivoli Monitoring for Web Infrastructure
Install 2 V5.1.2 AIX HP-UX Linux Solaris Win2000 WinNT WinXP Int Engl
Braz Port French Italian German Spanish Japan Korea Simp Chin Trad Chin
<img_dir>/code/tivoli/ITMWI/512/all/generic
򐂰 Tivoli Monitoring for Web Infrastructure
Install 3 V5.1.2 AIX HP-UX Linux Solaris Win2000 WinNT WinXP Int Engl
Braz Port French Italian German Spanish Japan Korea Simp Chin Trad Chin
<img_dir>/code/tivoli/ITMWI/512/all/generic
򐂰 Tivoli Monitoring for Web Infrastructure
WebSphere Application Server Component Software V5.1.2 AIX HP-UX
Linus Solaris Win2000 WinNT WinXP Int Engl
<img_dir>/code/tivoli/ITMWI/512/WAS/generic
򐂰 Tivoli Monitoring for Web Infrastructure
Documentation V5.1.2 AIX HP-UX Linus Solaris Win2000 WinNT WinXP Int
Engl
<img_dir>/code/tivoli/ITMWI/512/all/generic/documentation
210
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
򐂰 5.1.2-WAS-FP02 Tivoli Monitoring for Web Infrastructure: WebSphere
Application
<img_dir>/code/tivoli/ITMWI/512_fp02/all/generic
In addition you, will need the images for ITM Component Services which were
downloaded during the preparation for ITM installation as described in “Preparing
installation media for ITM” on page 197.
To determine which installation images you need, and from where they can be
downloaded, please refer to Table B-1 on page 647.
Make the installation image accessible from the rdbms system using NFS or
SMB mount:
smbmount //srchost/img /mnt -o username=root,password=<password>
Determining component locations
Table 4-16 on page 198 outlines which ITM for Web Infrastructure components to
install where, in accordance with the functional roles of the systems described in
4.1.1, “Management environments” on page 131.
The summarized version of the information from Table 4-16 on page 198 is that
the ITM for WI components must be installed on all TMR Servers and Tivoli
Gateways in the Outlet Systems Management Solution infrastructure. This boils in our environment - down to the following systems: hubtmr, spoketmr, regionXX,
and outletXX.
Installing IBM Tivoli Monitoring for WI
The IBM Tivoli Monitoring for Web Infrastructure components can be installed
either through Tivoli Desktop, or through command line commands.
In this section we show the command line-based installation, from which you will
be able to deduct the information needed to perform the installation using the
Tivoli Desktop installation GUI. For information about how to navigate the Tivoli
Desktop installation GUI, please refer to the IBM Tivoli Information Center Web
site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Management Framework →Enterprise Installation
Guide →Installing Tivoli Products and Patches.
For specific information about how to install IBM Tivoli Monitoring for Web
Infrastructure components, refer to the information available at the IBM Tivoli
Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Chapter 4. Installing the Tivoli Infrastructure
211
Navigate to Monitoring for Web Infrastructure →Installation and Setup
Guide →Installing or upgrading the product manually in an existing Tivoli
environment.
To install the products and patches for IBM Tivoli Monitoring for Web
Infrastructure through the command line interface you should perform the
following steps:
򐂰 IBM Tivoli Monitoring Component Services, Version 5.1.1
a. Run this command from hubtmr to install IBM Tivoli Monitoring Component
Services, Version 5.1.1 on the hubtmr system:
wpatch –c <img_dir>/code/tivoli/ITM/511/all/generic/ITMCS –i ITMCS511 –y
@CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install IBM Tivoli Monitoring
Component Services, Version 5.1.1 on the spoketmr, region01 and
outlet01 systems:
wpatch –c <img_dir>/code/tivoli/ITM/511/all/generic/ITMCS –i ITMCS511 –y
@CreatePaths@=1 spoketmr region01 outlet01
򐂰 IBM Tivoli Monitoring for Web Infrastructure: WAS 5.1.2
a. Run this command from hubtmr to install IBM Tivoli Monitoring for Web
Infrastructure - WebSphere Application Server 5.1.2 on hubtmr from your
specific product path:
winstall –c <img_dir>/code/tivoli/ITMWI/512/all/generic/PRODUCT –i
ITMWAS –y @CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install IBM Tivoli Monitoring for Web
Infrastructure - WebSphere Application Server 5.1.2 on spoketmr,
region01 and outlet01 from your specific product path
winstall –c <img_dir>/code/tivoli/ITMWI/512/all/generic/PRODUCT –i
ITMWAS –y @CreatePaths@=1 spoketmr region01 outlet01
򐂰 IBM Tivoli Monitoring for Web Infrastructure:WAS 5.1.2 FP02
a. Run this command from hubtmr to install IBM Tivoli Monitoring for Web
Infrastructure 5.1.2 - WebSphere Application Server - Fix Pack 02 on
hubtmr from your specific product path
wpatch –c <img_dir>/code/tivoli/ITMWI/512_fp02/all/generic –i 512WAS02
–y @CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install IBM Tivoli Monitoring for Web
Infrastructure 5.1.2 - WebSphere Application Server - Fix Pack 02 on
spoketmr, region01 and outlet01 from your specific product path
wpatch –c <img_dir>/code/tivoli/ITMWI/512_fp02/all/generic –i 512WAS02
–y @CreatePaths@=1 spoketmr region01 outlet01
212
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Verifying IBM Tivoli Monitoring for WI installation
Verification steps can be found at the IBM Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Monitoring for Web Infrastructure →Installation and Setup
Guide →Completing the installation of the product →Verifying the
installation of the product.
In addition to the verifications steps described in the Information Center, you can
check for the existence of a new policy region by the name Monitoring for
WebSphere Application Server. You can also use the wlookup command to verify
the installation of Tivoli Monitoring for Web Infrastructure.
4.3.9 IBM Tivoli Monitoring for databases
This section demonstrates how to install IBM Tivoli Monitoring for Databases
v5.1.1 in order to enable the monitoring of DB2 Server v8 resources in the Outlet
Systems Management Solution.
For detailed information about IBM Tivoli Monitoring for Web Infrastructure, refer
to the information available at the IBM Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Monitoring for Databases.
Preparing for installation
The preparation steps for installing the IBM Tivoli Monitoring for Databases
v5.1.1 product and the related WebSphere Application Server feature include the
following:
1. ”Preparing installation media: DB2”
2. “IBM Tivoli Monitoring for Databases:DB2 component locations” on page 214
Preparing installation media: DB2
Obtain the installation images for the following components, and unpack them to
the proper location on the srchost server in the <img_dir>/code directory
structure:
򐂰 Tivoli Monitoring for Databases
Install V5.1.1 AIX HP-UX Linux Solaris Win2000 WinNT WinXP Int Engl Braz
Port French Italian German Spanish Japan Korea Simp Chin Trad Chin
<img_dir>/code/tivoli/ITMDB/511/all/generic
򐂰 Tivoli Monitoring for Databases
Chapter 4. Installing the Tivoli Infrastructure
213
Install 2 V5.1.1 AIX HP-UX Linux Solaris Win2000 WinNT WinXP Int Engl
Braz Port French Italian German Spanish Japan Korea Simp Chin Trad Chin
<img_dir>/code/tivoli/ITMDB/511/all/generic
򐂰 Tivoli Monitoring for Databases: Documentation V5.1.1 AIX HP-UX Linux
Solaris Win2000 WinNT WinXP Int Engl
<img_dir>/code/tivoli/ITMDB/511/all/generic
򐂰 Tivoli Monitoring for Databases: DB2 Component Software V5.1 AIX HP-UX
Linux Solaris Win2000 WinNT WinXP Int Engl
<img_dir>/code/tivoli/ITMDB/510/all/generic
򐂰 IBM Tivoli Monitoring for Databases 5.1.0 - DB2 Component Software 5.1.0
Fix Pack 5
<img_dir>/code/tivoli/ITMDB/510_fp05/all/generic
In addition, you will need the images for ITM Component Services which were
downloaded during the preparation for ITM installation as described in “Preparing
installation media for ITM” on page 197.
To determine which installation images you need, and from where they can be
downloaded, refer to Table B-1 on page 647.
Make the installation image accessible from the rdbms system using NFS or
SMB mount:
smbmount //srchost/img /mnt -o username=root,password=<password>
IBM Tivoli Monitoring for Databases:DB2 component locations
Table 4-16 on page 198 outlines which ITM for Databases related components to
install where, in accordance with the functional roles of the systems described in
4.1.1, “Management environments” on page 131.
The summarized version of the information from Table 4-16 on page 198 is, that
the ITM for Databases components must be installed on all TMR Servers and
Tivoli Gateways in the Outlet Systems Management Solution infrastructure. This
boils in our environment down to the following systems: hubtmr, spoketmr,
regionXX, and outletXX.
ITM for DB:DB2 Component installation and configuration
The IBM Tivoli Monitoring for Databases components be installed either through
Tivoli Desktop, or through command line commands.
In the following we show the command line based installation, from which you
will be able to deduct the information needed to perform the installation using the
Tivoli Desktop installation GUI. For information about how to navigate the Tivoli
214
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Desktop installation GUI, please refer to the IBM Tivoli Information Center at
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp and navigate to
Management Framework →Enterprise Installation Guide →Installing Tivoli
Products and Patches.
For specific information about how to install IBM Tivoli Monitoring for Databases
components please refer to the information available at the IBM Tivoli
Information Center at
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp and navigate to
Monitoring for Databases →Installation and Setup Guide →Installing or
upgrading the product manually in an existing Tivoli environment.
To install the products and patches for IBM Tivoli Monitoring for Databases
through the command line interface, perform the following steps:
򐂰 IBM Tivoli Monitoring Component Services, Version 5.1.1
a. If this step was not performed previously run the following command from
hubtmr to install IBM Tivoli Monitoring Component Services, Version 5.1.1
on the hubtmr system:
wpatch –c <img_dir>/code/tivoli/ITM/511/all/generic/ITMCS –i ITMCS511 –y
@CreatePaths@=1 hubtmr
b. If this step was not performed previously run this command from spoketmr
to install IBM Tivoli Monitoring Component Services, Version 5.1.1 on the
spoketmr, region01 and outlet01 systems:
wpatch –c <img_dir>/code/tivoli/ITM/511/all/generic/ITMCS –i ITMCS511 –y
@CreatePaths@=1 spoketmr region01 outlet01
򐂰 IBM Tivoli Monitoring for Databases 5.1.0 - DB2
a. Run this command from hubtmr to install IBM Tivoli Monitoring for
Databases, Version 5.1.0 - DB2 on hubtmr from your specific product path
winstall –c <img_dir>/code/tivoli/ITMDB/510/all/generic/PRODUCT –i
DB2ECC22 –y @CreatePaths@=1 hubtmr
b. Run this command from spoketmr to install IBM Tivoli Monitoring for
Databases, Version 5.1.0 - DB2 on spoketmr, region01 and outlet01 from
your specific product path
winstall –c <img_dir>/code/tivoli/ITMDB/510/all/generic/PRODUCT –i
DB2ECC22 –y @CreatePaths@=1 spoketmr region01 outlet01
򐂰 IBM Tivoli Monitoring for Databases 5.1.0 - DB2 FP05
a. Run this command from hubtmr to install IBM Tivoli Monitoring for
Databases - DB2, Version 5.1.0 - Fix Pack 05 on hubtmr:
wpatch –c <img_dir>/code/tivoli/ITMDB/510_fp05/all/generic –i DB2ECC22
–y @CreatePaths@=1 hubtmr
Chapter 4. Installing the Tivoli Infrastructure
215
b. Run this command from spoketmr to install IBM Tivoli Monitoring for
Databases - DB2, Version 5.1.0 - Fix Pack 05 on spoketmr, region01 and
outlet01 from your specific product path
wpatch –c <img_dir>/code/tivoli/ITMDB/510_fp05/all/generic –i DB2ECC22
–y @CreatePaths@=1 spoketmr region01 outlet01
Verifying the IBM Tivoli Manager for DB installation
Verification steps can be found at the IBM Tivoli Information Center at
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp and navigate to
Monitoring for Databases →Installation and Setup Guide →Completing the
installation of the product →Verifying the installation of the product
In addition to the verifications steps described in the Information Center, you can
check for the existence of a new policy region by the name Monitoring for
Databases. As described in the previous section, you can also use the wlookup
command to verify the installation of Tivoli Monitoring for Databases.
4.3.10 TMTP Management Server
This section details the installation of the Transaction Monitoring components of
the Outlet Systems Management Solution.
Preparing the TMTP installation
The Tivoli Monitoring for Transaction Performance (TMTP) components can be
installed either through the Installation Wizard, or through command line
commands.
In this section, we show the command line based installation, from which you will
be able to deduct the information needed to perform the installation using the
Installation Wizard. For information about how to navigate the Wizard installation
GUI, Please refer to the IBM Tivoli Information Center at
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp and navigate
to Monitoring for Transaction Performance → Installation and
Configuration Guide → Installing a management server → Typical
installation: management server.
For the Outlet Systems Management Solution it was chosen to use the Custom
installation, requiring you to manually provide the following prerequisite
components:
򐂰 A working WebSphere Application Server v5.1 - or later - to host the TMTP
Management Server application on the tmtpsrv system.
򐂰 An empty DB2 database to be use as a permanent data store for TMTP
216
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
In addition to providing these prerequisite components, the installation media
needs to be acquired, so, in summary, the preparation steps for installing the IBM
Tivoli Monitoring for Transaction Performance v5.3 product, include the following:
1. ”Preparing installation media for TMTP”
2. “Determining TMTP Component locations” on page 218
3. “Establishing the TMTP WebSphere Application Server platform” on page 218
4. “Creating the TMTP DB2 database” on page 218
Preparing installation media for TMTP
Obtain the installation images for the following components, and unpack them to
the proper location on the srchost server in the <img_dir>/code directory
structure:
򐂰 IBM Tivoli Monitoring for Transaction Performance, Version 5.3.0: Web
Transaction Performance Component Software Management Server (1 of 2)
<img_dir>/code/tivoli/TMTP/530/server/generic
򐂰 IBM Tivoli Monitoring for Transaction Performance, Version 5.3.0: Web
Transaction Performance Component Software Management Server (2 of 2)
<img_dir>/code/tivoli/TMTP/530/server/generic
򐂰 IBM Tivoli Monitoring for Transaction Performance, Version 5.3.0: Web
Transaction Performance Component Software Management Agent, Store
and Forward
<img_dir>/code/tivoli/TMTP/530/agents/generic
򐂰 IBM Tivoli Monitoring for Transaction Performance, Version 5.3.0: Rational
Robot, Warehouse Enablement Pack, Tivoli Intelligent Orchestrator, TMTP
5.1 to TMTP 5.3 Upgrade
<img_dir>/code/tivoli/TMTP/530/components/generic
򐂰 IBM Tivoli Monitoring for Transaction Performance, Version 5.3.0:
Documentation CD (English only) UNIX
<img_dir>/code/tivoli/TMTP/530/all/unix/documentation
To determine which installation images you need, and from where they can be
downloaded, refer to Table B-1 on page 647.
Make the installation image accessible from the tmtpsrv system using NFS or
SMB mount:
smbmount //srchost/img /mnt -o username=root,password=<password>
Chapter 4. Installing the Tivoli Infrastructure
217
Determining TMTP Component locations
Table 4-19 outlines which TMTP related components to install where, in
accordance with the functional roles of the systems described in “Management
environments” on page 131.
Table 4-19 TMTP product and patch installation roadmap
Tivoli Monitoring for Transaction Performance v5.3:
Management Server
Tivoli Monitoring for Transaction Performance v5.3:
Command Line Interface
outlet01
region01
spoketmr
tmtpsrv
srchost
tec
servers
hubtmr
components
x
x
Tivoli Monitoring for Transaction Performance v5.3:
Web Transaction Monitoring Management Agent
x
Establishing the TMTP WebSphere Application Server platform
A working WebSphere Application Server environment is required for custom
installation of the TMTP Management Server. For a description of how to install
the WebSphere Application Server v5 on the tmtpsrv system, refer to “Installing
WebSphere Application Server v5.1 installation” on page 204.
Creating the TMTP DB2 database
Prior to TMTP Management Server custom installation, the database to be used
must exist and be totally empty. In addition, the database must be accessible
from the tmtpsrv system, , at a minimum requiring us to install the DB2 Client
component on the tmtpsrv system. Both of these activities have been generally
described in the previous sections. Refer to “Creating DB2 instances and
databases” on page 150 and “DB2 client installation” on page 152.
Regarding the creation of the database for TMTP, refer to the IBM Tivoli
Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Monitoring for Transaction Performance → Installation and
Configuration Guide → Preparing an existing database for configuration
with the management server → Preparing an existing DB2 database for the
specific procedures and parameters to be used when defining the DB2 database.
218
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Important: Ensure the tmtp database is empty, including default tablespaces
such as the systoolspace. Failing to do this can result in an error similar to The
selected database is not empty, delete any tables or tablespaces...
Installing the TMTP Management Server
Prior to initiating the TMTP Management Server, you might want to review the
information available at the IBM Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Monitoring for Transaction Performance → Installation and
Configuration Guide → Installing a management server → Custom
installation: management server.
This section demonstrate the steps we performed to install the TMTP
Management Server in the Outlet Systems Management Solution environment
on the tmtpsrv system:
1. To install TMTP Server, execute the following command from the installation
media downloaded to the <img_dir>/code/tivoli/TMTP/530/server/generic
directory:
setup_MS_lin.bin -W tempBrowsePanel.active=true
You will now be guided through a series of dialog boxes in which you can
specify the required parameters for the initial configuration of the TMTP
Management Server.
a. Ensure that the Perform Embedded Installation Using CD-ROMS
check-box is not checked.
b. Click I accept the terms in the license agreement.
c. Change the Directory Name to: /opt/IBM/tivoli/MS.
d. Configure SSL communication.
Temporary SSL keys are provided with the TMTP installation image.
Follow the instructions in the TMTP Installation Guide (available at the
InfoCenter) to replace these keys with permanent ones. If you would
prefer to use the provided keys, use the following information to complete
the setup dialog:
Key File Password
Trust File Password
changeit
changeit
e. Accept the defaults, and click Install.
2. Wait until the installation process has completed.
3. Restart server1 the WebSphere Application Server.
Chapter 4. Installing the Tivoli Infrastructure
219
Verifying the TMTP Server installation
To verify the installation of the TMTP Server, make sure that the WebSphere
Application Server named server1 has been started, and open the TMTP
Console in your browser, using one of the following URLs:
non-SSL:
SSL:
http://tmtpsrv:9080/tmtpUI
https://tmtpsrv:9445/tmtpUI
The TMTP log on page should be displayed. You can login with the user ID and
password used during the installation. For the Outlet Systems Management
Solution, we used the user root.
Note: The TMTP Server installation enables Global Security for the
WebSphere server, if it was not previously enabled. This will require you to
logon with a valid user ID and password to access the WebSphere Application
Server Administrative Console, for example the user root.
Setting up the TMTP command line interface
TMTP provides a command line interface that is very useful in automating the
setup. The command line interface is provided with the installation media, under
the tio directory because it is truly a component that has been developed to allow
for automated provisioning of TMTP Management Agents through Tivoli
Intelligent Orchestrator.
Preparing
The TMTP Command Line Interface code is delivered as part of the TMTP v5.3
installation images, and can be found on the CD-ROM named IBM Tivoli
Monitoring for Transaction Performance, Version 5.3.0: Rational Robot,
Warehouse Enablement Pack, Tivoli Intelligent Orchestrator, TMTP 5.1 to TMTP
5.3 Upgrade. The image was downloaded to the
<img_dir>/code/tivoli/TMTP/530/components/generic directory as part of the
TMTP Management Server installation preparation.
Determining TMTP CLI locations
Table 4-19 on page 218 outlines which TMTP components to install where, in
accordance with the functional roles of the systems described in 4.1.1,
“Management environments” on page 131. The table shows that the TMTP
Command Line interface will be installed on the hubtmr system, because it is
from this system, we will issue configuration and operation commands to the
TMTP Server through scripts or Tivoli tasks.
Installing and configuring
The following steps outline the procedure to install and configure the TMTP CLI:
220
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
1. Copy ITMTP_MA.tcdriver from the tio directory of the installation media to
/opt/IBM/tivoli/tmtp_cli on the hubtmr system. Create the directory, if it does
not already exist.
2. Unpack ITMTP_MA.tcdriver using the jar command as shown:
jar xvf ITMTP_MA.tcdriver
3. Configure the TMTP Command Line Interface options using the configCLI.sh
script:
/opt/IBM/tivoli/tmtp_cli/scripts/configCLI.sh MSServer MSUserName
MSPassword MSPort SSLEnabled PropertiesFileName CLIKeyFile
CLIKeyFilePassword
The descriptions in Table 4-20 are of the options you must pass to the
configCLI.sh script.
Table 4-20 Options for configCLI.sh script
Option
Definition
MSServer
The fully qualified host name of the management server,
for example: ims.ibm.com
MSUser
A valid administrator username for the management
server, for example:root
MSUserPassword
The password for the administrator username, for
example:smartway
MSPortWithAuth
The secure management server communication port for
example:9446
MSPortWithoutAuth
The nonsecure management server communication port,
for example: 9082
MSSSLEnabled
A flag indicating whether security is enabled, for
example: true
PropertiesFileName
The name of the properties file to be created, for
example: tmtpcli
CLIKeyFile
The path to the CLI key fileto be used, for example:
/home/thinkcontrol/repository/ tivoli/ITMTP/
cli/config/agent.jks
CLIKeyFilePassword
The CLI key file password, for example: changeit
Chapter 4. Installing the Tivoli Infrastructure
221
Note: The TMTP CLI require Java 1.4.1 or later. The default java version
used by UnitedLinux v1.0 is 1.3.1. If necessary, you can modify the
tmtpcli.sh script (/opt/IBM/tivoli/tmtp_cli/cli) to point to the correct java
version as follows:
򐂰 Modify the section of the script by commenting out the “look for java...”
section and specifying the value:
# look for java (borrowed from ant)
#if [ -z "$JAVACMD" ] ; then
# if [ -n "$JAVA_HOME" ] ; then
# if [ -x "$JAVA_HOME/jre/sh/java" ] ; then
# IBM's JDK on AIX uses strange locations for the executables
# JAVACMD=$JAVA_HOME/jre/sh/java
# else
# JAVACMD=$JAVA_HOME/bin/java
# fi
# else
# JAVACMD=java
# fi
#fi
JAVACMD=/opt/IBMJava2-141/bin/java
In the Outlet Systems Management Solution we used the following TMTP CLI
configuration:
/opt/IBM/tivoli/tmtp_cli/scripts/configCLI.sh 9.3.5.206 root smartway 9446
true tmtpcli /opt/IBM/tivoli/tmtp_cli/cli/config/agent.jks changeit
Verifying TMTP CLI installation and configuration
To verify that the TMTP CLI has been installed and configured properly, run the
following command from the hubtmr system:
/opt/IBM/tivoli/tmtp_cli/cli/tmtpcli.sh -VerifyManagementServer -Console
Tip: The '-Console' option instructs the script to display the results on the
screen instead of only in the log file (/var/ibm/tivoli/common/BWM/logs)
Make sure that the last line of the output contains the word Success, as shown in
Example 4-15:
Example 4-15 Verifying TMTP CLI installation and configuration
/opt/IBM/tivoli/tmtp_cli/cli/tmtpcli.sh -VerifyManagementServer -Console
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1) Classic VM
(build 1.4.1, J2RE 1.4.1 IBM build cxia321411-20040301 (JIT enabled: jitc))
222
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Command = VerifyManagementServer
Retrieving document at '/opt/IBM/tivoli/tmtp_cli/cli/wsdl//PolicyManager.wsdl'.
Retrieving document at '/opt/IBM/tivoli/tmtp_cli/cli/wsdl//CLI.wsdl'.
Nov 24, 2004 4:41:36 PM org.apache.wsif.logging.MessageLogger logIt
WARNING: WSIF0006W: Multiple WSIFProvider found supporting the same namespace
URI 'http://schemas.xmlsoap.org/wsdl/soap/'. Found
('org.apache.wsif.providers.soap.apacheaxis.WSIFDynamicProvider_ApacheAxis,
org.apache.wsif.providers.soap.apachesoap.WSIFDynamicProvider_ApacheSOAP')
Nov 24, 2004 4:41:36 PM org.apache.wsif.logging.MessageLogger logIt
INFO: WSIF0007I: Using WSIFProvider
'org.apache.wsif.providers.soap.apacheaxis.WSIFDynamicProvider_ApacheAxis' for
namespaceURI 'http://schemas.xmlsoap.org/wsdl/soap/'
Status = BWMCR1300I Success
Note: As shown in Example 4-15 you can receive a warning indicating that
multiple namespace providers exist. This message can be ignored.
4.4 Postinstallation configuration
This section describes the postinstallation configuration for each product needed
to customize the systems management tools to the Outlet Systems Management
Solution.
4.4.1 Framework customization
Initial postinstallation customization of the Tivoli Framework involves the
following steps:
1. ”Setup administrator roles”
2. “Setup and configure SSL communication” on page 225
3. “Connect TMRs and define resource exchange interval” on page 226
Setup administrator roles
Most TMF-based products create specific administrative roles during installation.
These roles will normally be required to have been assigned to an administrator
for that administrator to perform specific, product related operations. Therefore,
you should remember to check them after the installation, and associate them to
the Tivoli Administrators according to your policies.
To verify the available roles you can run the wgetadmin command line or use the
graphical function that you can access right clicking on the Administrator icon,
and selecting the scroll down menu item Edit TMR Roles. The dialog shown in
Figure 4-17 on page 224 will be displayed:
Chapter 4. Installing the Tivoli Infrastructure
223
Figure 4-17 Edit TMR Roles
Select the roles you want to associate to the particular administrator in the
Available Roles columns, and move them to the Current Roles column using the
left arrow button located between the two columns.
When you click Change and Close to save the modifications, the confirmation
dialog shown in Figure 4-18 will appear.
Figure 4-18 Administrator Info Changed
224
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
You can simply dismiss this dialog, but remember that the modification made will
not be active until the next login for the administrator in question.
Setup and configure SSL communication
To allow for secure communication between managing systems (managed
nodes) in the Outlet Systems Management Solution, we have to install and
enable Secure Socket Layer (SSL) communications. This requires setup and
configuration of SSL on all the managed nodes in the hub and spoke TMRs.
On all nonLinux managed nodes you must install the SSL-A package to enable
SSL connections. On Linux managed nodes, SSL is enabled by default. You only
need to install the SSL-B package for management of security keys. If the SSL-A
package is not installed on a managed node, the managed node can only accept
non-SSL connections from clients. For detailed information about how to enable
SSL in your Tivoli environment, refer to the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Management Framework → Enterprise Installation Guide →
Installing Tivoli Products and Patches → Installing MDist 2 Components →
Installing Secure Sockets Layer
After installation and restarting of all systems, set the network security level on
each managed node on which you want to enable SSL communications. This
setting determines how the managed node logs in to the server. Use the odadmin
command from each of the TMR Servers to achieve this.
odadmin set_network_security SSL all
Specify the cipher list on each managed node to dictate the strength of the
encryption used by SSL.
odadmin set_ssl_ciphers “05040A030609” all
Note: Restart the managed node for the changes to take effect. For more
information about the odadmin and oserv commands, refer to the Tivoli
Management Framework Reference Manual.
To restart the nodes, run these commands on the TMR server:
1. odadmin shutdown clients
2. odadmin reexec 1
3. odadmin start clients
You can run the odadmin odinfo command to verify that the settings have taken
effect. The output will be similar to the outpun in Example 4-16 on page 226.
Chapter 4. Installing the Tivoli Infrastructure
225
Example 4-16 oserv configuration information
hubtmr:/ # odadmin odinfo 1
Tivoli Management Framework (tmpbuild) #1 Sun Sep 19 17:27:56 CDT 2004
(c) Copyright IBM Corp. 1990, 2004. All Rights Reserved.
Region = 1393424439
Dispatcher = 1
Interpreter type = linux-ix86
Database directory = /var/spool/Tivoli/hubtmr.db
Install directory = /usr/local/Tivoli/bin
Inter-dispatcher encryption level = DES
Kerberos in use = FALSE
Remote client login allowed = TRUE
Install library path =
/usr/local/Tivoli/lib/linux-ix86:/usr/local/Tivoli/install-dir/iblib/linux-ix86
:/usr/lib:/usr/ucb
lib
Force socket bind to a single address = FALSE
Perform local hostname lookup for IOM connections = FALSE
Use Single Port BDT = FALSE
Use communication channel check = FALSE
Communication check timeout = default (180 secs)
Communication check response timeout = default (180 secs)
Oserv connection validation timeout = 300
Port range = (not restricted)
Single Port BDT service port number = default (9401)
Network Security = SSL
SSL Ciphers = 05040A030609
ALLOW_NAT = FALSE
State flags in use = TRUE
State checking in use = TRUE
State checking every 180 seconds
Dynamic IP addressing allowed = FALSE
Transaction manager will retry messages 4 times.
Connect TMRs and define resource exchange interval
In the Tivoli Management Framework, each Tivoli Management Region (TMR)
operates independently, managing only the resources that have been defined to
it. However, it is also possible to connect TMRs to allow for cross-TMR actions,
an activity that is necessary in the Outlet Systems Management Solution to allow
centrally managed resources such as software packages and resource models
to be distributed to the managed systems in the outlets.
To connect the hub and spoke TMRs, use either the graphical functions
available, as described in the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
226
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Navigate to Management Framework → User’s Guide → Tivoli regions and
interregion connections → Making a secure region connection → Desktop.
As an alternative, you use the wconnect command to achieve this from the
command line, as outlined in the following steps:
1. Lookup the TMR numbers using the odadmin odlist command from the
humbtmr (Example 4-17) and from the spoketmr (Example 4-18).
Example 4-17 From the hubtmr
hubtmr:~ # odadmin odlist
Region
Disp Flags Port IPaddr
Hostname(s)
1393424439
1
ct94
10.1.1.1 hubtmr.demo.tivoli.com,hubtmr
2
ct94
10.1.1.2 tec.demo.tivoli.com,tec
9.3.5.214 9.3.5.214
3
ct94
10.1.1.4 srchost.demo.tivoli.com,srchost
Example 4-18 From the spoketmr
Region
1282790711
Disp
1
Flags Port IPaddr
ct94
10.1.1.6
2
ct-
94
3
ct-
94
Hostname(s)
spoketmr.demo.tivoli.com,spoketmr
9.3.5.236 9.3.5.236
10.2.0.10 region01.demo.tivoli.com,region01
9.3.5.242 9.3.5.242
10.2.1.10 outlet01.demo.tivoli.com,outlet01
9.3.5.211 9.3.5.211
2. To enable the connection between the TMRs, you have to run the wconnect
command from both sides of the secure connection:
hubtmr: wconnect -s spoketmr 1282790711
spoketmr: wconnect -s hubtmr 1393424439
3. Once the TMRs have been connected, you should exchange information
about the resources between them. Use the wupdate command from each
TMR as shown:
hubtmr: wupdate -r All spoketmr-region
spoketmr:> wupdate -r All hubtmr-region
4. Finally, you can use the wlsconn command to verify your settings as in
Example 4-19.
Example 4-19 Using the wlsconn command
spoketmr:~ # wlsconn hubtmr-region
Name:
hubtmr-region
Server: hubtmr.demo.tivoli.com
Region: 1393424439
Chapter 4. Installing the Tivoli Infrastructure
227
Mode: two_way
Port: 94
Resource Name
------------ManagedNode
Repeater
Gateway
Endpoint
EventServer
TaskLibrary
Tmw2kProfile
Last Exchange
------------Fri Oct 29 11:01:56
Tue Nov 9 15:48:36
Tue Nov 9 15:46:47 2004
Thu Dec 9 01:28:24
Fri Oct 29 14:05:19
Tue Nov 16 09:19:46
Fri Nov 19 10:47:36
2004
2004
2004
2004
2004
2004
5. Once the connection has been established, you want to create a task to
automatically exchange resources at specific intervals.
Setup gateways and repeaters
Each managed node or TMR server in the Tivoli Management Environment
assume the role of a repeater and a gateway. By default, gateways are
automatically configured as repeaters for their client endpoints.
Gateways
The gateway functionality allows the managed node to serve as a gateway for
endpoints, thus allowing endpoint logins and assuming responsibility for passing
packets back and forth between endpoints and the management server systems.
In the Outlet Systems Management Solution, all managed nodes in the spoke
TMRs will be defined as gateways, in order for them to accept logins from local
endpoints.
The gateway is defined with default configuration on a managed node using the
wgateway command:
wgateway -h <managed node>
If special configuration is needed, for example to allow communications to pass
firewalls, use the wgateway command to set specific configuration options for the
gateways. For more details on gateway configuration, refer to the Tivoli
Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Management Framework → Planning for Deployment Guide →
Endpoints and gateways.
In the Outlet Systems Management Solution, gateways will be established on all
TMR Servers and all managed nodes belonging to spoke TMRs with names
228
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
equal to the managed node itself with the string -gw appended. We used the
following commands:
wcrtgate -h hubtmr -n hubtmr-gw
wcrtgate -h spoketmr -n spoketmr-gw
wcrtgate -h <outlet_server_name> -n <outlet_server_name>-gw
Having been assigned the gateway functionality, it is important to define login
policies to help control which endpoints will be allowed to connect to the gateway.
See 6.5, “Creating endpoint policies” on page 343 for more details.
Repeaters
The repeater functionality allows the managed node to act as a fan-out node for
mdist distributions, typically software distributions, setting aside a number of
system resources such as disk space, bandwidth, and so on to be used
specifically for handling distributions. In the outlet environment, this ensures that
a software package to be distributed to servers in the same region only travels
across the network path between the central management location and the
region once, and then is distributed to the individual stores.
The storage set aside for a repeater is also known as a software distribution
depot, in which software packages can be preloaded. This enables Outlet Inc. to
use network bandwidth at offpeak hours to distribute large software packages to
the remote sites ahead of time for use.
The optimal repeater configuration depends on a number of factors ranging from
available bandwidth on both sides of the repeater, other network usage, number
of downstream systems, available resources at the repeater system, business
policies and so on. Refer to “Repeater guidelines” on page 65 for a more detailed
discussion.
By default, any TMR server is a repeater, and it is assigned the special WAN role
that ensures that any distribution to a different subnet will pass through this
repeater.
Gateways will, by default, become repeaters for all endpoints connected to the
endpoint.
In the Outlet Systems Management Solution we specifically defined a repeater
on the srchost system, since all other required repeaters were installed by
default. To create a repeater, use the wrpt command:
wrpt -n <server_name>
Because all additional servers in the Outlet infrastructure will become gateways
by default, the repeaters will be created automatically. However, adjusting
repeater configuration parameters might be needed.
Chapter 4. Installing the Tivoli Infrastructure
229
Among other, these can include network usage, disk usage and other
capacity-related parameters. The most of these are described in “Repeater
parameters and settings” on page 65.
To enable multicast distributions in Outlet Systems Management Solution, the
following command is issued from the hubtmr against all managed nodes that
have the gateway enabled:
wmdist -s <managed node> -C noprompt endpoint_multicast=TRUE
gateway_multicast=TRUE
For the srchost system, which does not host a gateway, we used:
wmdist -s <managed node> -C noprompt gateway_multicast=TRUE
4.4.2 Enabling MDIST2
Enablement of MDist 2, which is heavily used by Tivoli Configuration Manager
components, requires the completion of the following activities:
1.
2.
3.
4.
5.
”Creating the mdist_db database”
”Cataloging the mdist_db database”
“Running the MDIST admin and schema scripts” on page 231
“Creating the mdist2 RIM object” on page 231
“Verifying MDist2 operation” on page 232
More details regarding the activities involved in configuring Mdist 2 are available
in the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Management Framework → Enterprise Installation Guide →
Installing Tivoli Products and Patches → Installing MDist 2 Components.
Creating the mdist_db database
Use the DB2 command create database mdist_db from the desired instance
user to create the database for the MDist 2 subsystem. This step has probably
already been performed as part of the database installation and configuration
described in “Creating DB2 instances and databases” on page 150.
Cataloging the mdist_db database
From the hubtmr system, issue the following commands to catalog the mdist_db
database residing on the rdbms system:
1. Access the db2 client:
su - db2inst1
230
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
2. Define the instance on the rdbms system hosting the mdist_db database:
catalog tcpip node db2mdist remote rdbms.demo.tivoli.com server 60008
Note: The instance name db2mdist and related port number 60008 was
determined when creating the database instances as described in
“Creating DB2 instances and databases” on page 150
3. Catalog the mdist_db database to make it accessible from the hubtmr
system:
catalog database mdist_db as mdist_db at node db2mdist authentication
server
The mdist_db database should now be accessible from the hubtmr system.
Running the MDIST admin and schema scripts
The Distribution Status Console will be used both by Inventory and Software
Distribution. To complete its configuration, you must run the admin and schema
scripts provided by the installation. These scripts are located in the
$BINDIR/TME/MDIST2/sql directory.
Remember, these are sample scripts that must be customized by your DBA
before you execute them on the rdbms machine.
For DB2 these scripts are called:
mdist_db2_admin.sql
mdist_db2_schema.sql
Creating the mdist2 RIM object
Once the database and the tables are created, you must create a RIM object
called mdist2, which the MDist 2 subsystem will use to store distribution requests
and status information permanently.
We used the parameters in Table 4-21:
Table 4-21 Parameters for the mdist2 RIM
Parameter
value
Database Vendor:
DB2
RIM Host
hubtmr
Database Home:
/opt/IBM/db2/V8.1
Database Name:
mdist_db
Chapter 4. Installing the Tivoli Infrastructure
231
Parameter
value
Database User ID:
db2mdist
Database Password:
********
Verify Password:
********
Server ID:
tcpip
Instance Home (for DB2 only):
~db2inst1
Instance Name (for DB2 only):
db2inst1
Verifying MDist2 operation
To verify the operation of the MDist 2 subsystem, open the Distribution Status
Console from the Tivoli Desktop, or use the wmdist -l command as described in
“Verifying Inventory operation” on page 243.
4.4.3 Enabling Tivoli End-User Web Interfaces
Tivoli Management Framework provides access to Web-enabled Tivoli
Enterprise Applications from a browser. To install the Tivoli Web Interfaces for
WebSphere Application Server on the console server, follow the instructions on
the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Management Framework → Enterprise Installation Guide →
Enabling TIvoli Web Interfaces → Installing Web access for WebSphere
Application Server, Version 5.
Important: The default port used by WebSphere 5 for SSL is 9443. As a
result, you must modify the TivoliFRW.war file with this port (instead of port
443) as described in step 10 of the Installation Guide instructions.
It is important to know these instructions reference a tool named assembly.sh.
This tool has been replaced with the WebSphere Application Server Toolkit as
of Version 5.1+.
Instructions for modifying the TivoliFRW.war file are included here for your
reference.
To modify the TivoliFRW.war file, perform the following steps. If you want to
modify the file using a text editor, use the information immediately following these
steps.
232
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
1. Install the WebSphere Application Server Toolkit (ASTK) on the console
server and start it. This tool is stored on the on the WebSphere Application
Server CDs.
2. Click File → Import.
3. Select WAR file and click Next.
4. Enter the full path to the WAR file, for example:
/opt/IBM/WebSphere/AppServer/installableApps/TivoliFRW.war)
5. Click New for project name.
6. Enter TivoliFRW as the Project Name, accept the default Project Location and
select Finish.
7. Click Finish to import the war file.
8. Click the + beside TivoliFRW to expand it.
9. Expand WebContent.
10.Expand WEB-INF.
11.Open web.xml by double-clicking it or right-clicking and selecting open.
12.Click https-port under Context Parameters.
13.Change the Value under Details to 9443 (from 443.)
14.Click the X beside Web Deployment Descriptor to close the web.xml file.
15.Click Yes to save the changes.
16.Right-click TivoliFRW and Export.
17.Select WAR File and click Next.
18.Leave the Web Project as TivoliFRW.
19.In the Destination field, enter: /<was_home/installableApps/TivoliFRW.war
Alternatively, you can edit the https-port file from a text editor, after you have
installed the TivoliFRW.war application in WebSphere. The information is found
in the web.xml file in the
/opt/IBM/WebSphere/AppServer/installedApps/console/TivoliFRW_war.ear/TivoliFRW.
war/WEB-INF directory.
1. Change the following section from Example 4-20 to Example 4-21 on
page 234.
Example 4-20 Old https-port file
<context-param id="ContextParam_1100051871242">
<param-name>https-port</param-name>
<param-value>443</param-value>
Chapter 4. Installing the Tivoli Infrastructure
233
<description>Identifies port number used by HTTPS.</description>
</context-param>
Example 4-21 Revised http-port file
<context-param id="ContextParam_1100051871242">
<param-name>https-port</param-name>
<param-value>9443</param-value>
<description>Identifies port number used by HTTPS.</description>
</context-param>
To verify your setup, make sure that the WebSphere Application Server on the
console systems has been started, and direct your Web browser to the following
url:
https://<concole system>:9443/TivoliFRW/webapp.
4.4.4 Configuring the Tivoli Enterprise Console
Customizing the Tivoli Enterprise Console after initial installation requires the
completing the following activities:
1.
2.
3.
4.
5.
6.
7.
”Creating the database for TEC”
“Cataloging the tec_db database” on page 235
“Creating the tec RIM object” on page 235
“Executing the TEC admin and schema scripts” on page 236
“Assigning TEC Roles to the Administrator” on page 236
“Configuring the TEC Console” on page 237
“Verifying TEC operation” on page 238
More details regarding the activities involved in configuring TEC are available on
the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Enterprise Console → Installation Guide → Configuring the
event database.
In addition to these steps, maintaining event class definitions and rulebases is an
on-going activity.
Creating the database for TEC
Use the DB2 command create database tec_db from the desired instance user
to create the database for the Tivoli Enterprise Console. This step has probably
already been performed as part of the database installation and configuration
described in “Creating DB2 instances and databases” on page 150.
234
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Cataloging the tec_db database
From the tec system, issue the following commands to catalog the tec_db
database residing on the rdbms system.
1. Access the db2 client:
su - db2inst1
2. Define the instance on the rdbms system hosting the tec_db database:
catalog tcpip node db2tec remote rdbms.demo.tivoli.com server 60016
Note: The instance name db2tec and related port number 60016 was
determined when creating the database instances as described in
“Creating DB2 instances and databases” on page 150
3. Catalog the tec_db database to make it accessible from the tec system:
catalog database tec_db as tec_db at node db2tec authentication server
The tec_db database should now be accessible from the TEC TMR system.
Creating the tec RIM object
During the Desktop installation you were prompted to supply parameters for
configuration of the tec RIM object. We used these parameters in Table 4-22 to
configure the tec RIM object.
Table 4-22 Parameters for the tec RIM
Attribute
value
Database Vendor
DB2
Database Home
/opt/IBM/db2/V8.1
Database Name
tec_db
Database User ID
db2tec
Database Password
********
Verify Password
********
RIM host
tec
Server ID
tcpip
Instance Home (for DB2 only)
~db2inst1
Instance Name (for DB2 only)
db2inst1
Chapter 4. Installing the Tivoli Infrastructure
235
If the tec RIM object was not created during installation, for example because the
installation was run from a command line or the configuration information
provided was wrong, the RIM can be created manually. The scripts to create the
database remove any existing RIM definition named tec and recreate it based on
the information entered when prompted.
Once both the tec_db DB2 database and the tec RIM have been created, test the
validity of the tec RIM object using the wrimtest -l tec command.
Executing the TEC admin and schema scripts
The execution of admin and schema scripts is a required step that creates the
database structure to store TEC events in your RDBMS machine.
You must use the installation Wizard to create your scripts. However when using
the Wizard, it is up to you wether to generate and execute or generate only. In
our environment, we executed the Installation Wizard on the tecserver system,
then elected generate only. After that step, we moved the scripts to the rdbms
server machine for the execution.
1. To start the Installation Wizard, use the script called tec_install.sh from the
Installation Assistant CR-ROM. For more details, refer to the information in
the Tivoli Information Center Web site noted on page 234.
Important: During our installation, we identified a problem with TEC 3.9.0
installation on a 4.1.1 Framework. The Installation Assistant provided with
the original CD-ROM is not able to recognize Framework 4.1.1. To solve
this problem, make sure you have the new Installation Assistant code
provided with LA Interim Fix 3.9.0-TEC-0003LA.
Contact client support to get the above limited availability (LA) code.
2. Once the tec_admin and tec_schema scripts have been generated and
moved to the rdbms system, execute them to create the database objects
required by TEC. Remember to login as the DB2 instance user (db2tec in our
case) assigned to the tec database before executing the scripts.
Assigning TEC Roles to the Administrator
To allow the default administrator to use and operate TEC, you have to assign
the required TEC roles to the administrator. The following outlines the steps
required to achieve this, and detailed descriptions regarding this activity are
available in the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
236
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Navigate to Enterprise Console → Installation Guide → Installing,
upgrading, and uninstalling using the Tivoli Management Framework
tools → Postinstallation tasks
1. To assign TEC roles to the administrator, start the Tivoli Desktop and
double-click the Administrators icon.
2. Right-click the icon representing the Administrator you want to which you
want to assign TEC Roles (Root_hubtmr-region in our case) and select Edit
TMR Roles.
3. Verify that the following roles are listed under Current Roles:
–
–
–
–
user
RIM_view
RIM_update
senior
Configuring the TEC Console
You can start the TEC Console from any system on which it has been installed.
In our case, you have either the tec or hubtmr systems.
1. To start the TEC Console, execute the tec_console executable found in the
$BINDIR/bin directory. You will be presented with the login dialog shown in
Figure 4-19:
Figure 4-19 TEC Console login
2. Once the console opens, you must follow the instructions in the Tivoli
Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Enterprise Console → User’s Guide → Configuring the Tivoli
Enterprise Console product → Creating an event Console to customize
the console to your particular needs.
Chapter 4. Installing the Tivoli Infrastructure
237
Verifying TEC operation
You can run a simple command from the TEC server machine to test the event
processing:
wpostemsg -m TEST_MESSAGE -r WARNING EVENT EVENT
The event will be shown in the TEC Console as soon as it is processed.
4.4.5 Customizing the Inventory
Customizing the Inventory component of Tivoli Configuration Manager after initial
installation requires the completion of the following activities:
1.
2.
3.
4.
5.
6.
7.
8.
9.
”Assigning Inventory Roles to the Administrator”
“Creating the inv_db database” on page 238
“Cataloging the inv_db database” on page 239
“Creating invdh_1 and inventory RIM objects” on page 239
“Executing the Inventory admin and schema scripts” on page 241
“Creating Inventory query libraries” on page 241
“Loading signatures file for software scan” on page 242 (optional)
“Enable Inventory integration to TEC” on page 242
“Verifying Inventory operation” on page 243
More details regarding the activities involved in configuring the Inventory
database are available in the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Configuration Manager → Planning and Installation Guide →
Working With Repositories and Queries.
Assigning Inventory Roles to the Administrator
Follow these steps to assign Inventory roles to an administrator:
1. From Tivoli Desktop, double-click the Administrators icon.
2. Right-click the Root_hubtmr-region icon and select Edit TMR Roles.
3. Verify that the following roles are listed under Current Roles:
– Inventory_edit
– Inventory_end_user
– Inventory_scan
– Inventory_view
1. Select Change & Close.
Creating the inv_db database
Use the DB2 command create database inv_db from the desired instance user
at the rdbms server in order to create the database for Inventory. This step has
238
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
probably already been performed as part of the database installation and
configuration described in “Creating DB2 instances and databases” on page 150.
Cataloging the inv_db database
From the hubtmr system, issue the following commands to catalog the inv_db
database residing on the rdbms system.
1. Access the db2 client:
su - db2inst1
2. Define the instance on the rdbms system hosting the inv_db database:
catalog tcpip node db2inv remote rdbms.demo.tivoli.com server 60004
Note: The instance name db2inv and related port number 60004 was
determined when creating the database instances as described in
“Creating DB2 instances and databases” on page 150
3. Catalog the inventory database to make it accessible from the hubtmr
system:
catalog database inv_db as inv_db at node db2inv authentication server
The inv_db database should now be accessible from the hubtmr system.
Creating invdh_1 and inventory RIM objects
For performance reasons, Inventory can use multiple RIM objects for handling
scanned hardware and software data. The minimal configuration requires two
RIM objects, one for reading and one writing, both pointing to the same DB2
database. During the Desktop installation, you were prompted to supply
parameters for configuration of the two RIM objects. We used the parameters
shown in Table 4-23 to configure both Inventory RIM objects.
Table 4-23 Parameters for the invdh_1 and inv_query RIMs
Parameter
value
Data Handler Host
hubtmr
MDist 2 Callback Host
hubtmr
Database Vendor
DB2
RIM Host
hubtmr
Database ID
inv_db
Database Home
/opt/IBM/db2/V8.1
Server ID
tcpip
Chapter 4. Installing the Tivoli Infrastructure
239
Parameter
value
User Name
db2inv
Instance Home (for DB2 only)
~db2inst1
Instance Name (for DB2 only)
db2inst1
Note: Be aware of the following information when working with RIM objects.
򐂰 The documentation states that RIM hosts should have been created
automatically during installation of the Inventory component. We have
observed inconsistent results in the creation of RIM hosts. Below are
instructions for adding and testing each RIM object that are required for
Inventory to function properly.
򐂰 The wrimtest command will fail if the default password for the RIM object
is different from the password set manually when creating User IDs. The
Tivoli Configuration Manager Planning and Installation Guide Chapter 3,
Page 25 lists the default passwords. The wsetrimpw command is described
in the Tivoli Management Framework Reference Manual. If a RIM object
was created by Tivoli, use the command wsetrimpw as follows to set the
password for the RIM object to the desired value.
wsetrimpw inv_query tivoli ABCDEF
In this case, the RIM object that is modified is inv_query, and the password
is changed from tivoli to ABCDEF, which is the password for the user invtiv,
the default user of the inv_query RIM object.
To verify the RIM objects for Inventory, run these commands on the TMR server
(hubtmr).
1. Test the RIM object invdh_1 to see if it was already created. After running this
command, you should see information about the RIM host on the screen with
no errors: User name, database name home directory, and so forth.
wrimtest –l invdh_1
a. If the RIM object has not been created, create RIM object invdh_1 using
the wcrtrim command as shown:
wcrtrim -v DB2 –h rdbms -d inv_db -u invtiv –H /usr/opt/db2_08_01/ -s
tcpip -I /home/db2inst1 -t db2inst1 invdh_1
RDBMS password: ******** (the password for invtiv)
b. After creation, verify that the RIM object was created successfully by once
again running wrimtest.
wrimtest –l invdh_1
240
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
2. Test the RIM object inv_query to see if it was already created or not. After
running this command, you should see information about the RIM host on the
screen with no errors: user name, database name home directory, and so on.
wrimtest –l inv_query
a. If it was not created, create the RIM object inv_query.
wcrtrim -v DB2 -h rdbms -d inv_db -u invtiv –H /usr/opt/db2_08_01/ -s
tcpip -I /home/db2inst1 -t db2inst1 inv_query
RDBMS password: ******** (the password for invtiv)
b. After creation, verify that the RIM object was created successfully by once
again running wrimtest.
wrimtest –l inv_query
3. Create the two RIM objects on the spoketmr system using the wcrtrim
commands shown in step 1 and step 2. This will provide access to the
inventory database directly from the spoketmr system, instead of directing all
database requests through the hubtmr.
Executing the Inventory admin and schema scripts
To define the various database objects needed by Configuration Managers
Inventory components, two scripts, an admin and a schema script, which set up
the required database objects. These scripts are located in:
$BINDIR/../generic/inv/SCRIPTS/RDBMS
Remember, these are sample scripts that must be customized by your DBA
before you execute them on the rdbms machine.
For DB2 these scripts are called:
inv_db2_admin.sql
inv_db2_schema.sql
Note: These scripts attempt to drop database objects such as tables before
they create them. Thus, for these commands you will see errors stating the
specified tables do not exist. These are normal and are not problems with the
script.
Creating Inventory query libraries
From the hubtmr system and logged in as root, execute the inventory_query and
subscription_query scripts respectively to create the query libraries used by
Inventory.
$BINDIR/../generic/inv/SCRIPTS/QUERIES/inventory_query.sh hubtmr-region
$BINDIR/../generic/inv/SCRIPTS/QUERIES/subscription_query.sh hubtmr-region
Chapter 4. Installing the Tivoli Infrastructure
241
During task execution, you will see scrolling text indicating that the queries are
being created.
Loading signatures file for software scan
A signature is the set of properties - such as the name, date, and size of one or
more files - that uniquely identifies a specific software application. Tivoli
Inventory provides a default set of signatures that can be used to collect
information about the software installed on the managed systems in the Outlet
Systems Management Solution. These default signatures are stored in the
SWSIGS.INI file in the $BINDIR/../generic/inv/SIGNATURES directory. To use
these signatures, you must import them into the inventory databases using the
winvsig command as shown in the following example:
winvsig -a -f $BINDIR/../generic/inv/SIGNATURES/SWSIGS.INI
This command installs the signatures in the configuration repository in the
SWARE_SIG table. You can edit the signatures provided with Inventory, delete
them, or you can add your own signatures. For example, you can add a signature
that is not currently provided with Inventory or for an application that was
developed in-house. Inventory uses signatures to determine which software
applications are installed on the machines you scan.
For further details about the use of signatures please refer to the Tivoli
Information Center at
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp and navigate
to Configuration Manager → User’s Guide for Inventory → Collecting
custom information with Inventory → Using Signatures.
Enable Inventory integration to TEC
If you want to send Inventory events to one or more Tivoli Enterprise Console
servers, you must import the BAROC files into Tivoli Enterprise Console.
Inventory attempts to send events to the Tivoli Enterprise Console servers in the
order that they are specified.
To import the Inventory BAROC files into Tivoli Enterprise Console, you must
perform the following steps:
1. Create a new rule base. Give it a descriptive name, Inventory, for example.
2. Copy the default classes from the Tivoli Enterprise Console rules base to the
new rule base named Inventory.
3. Import the Inventory BAROC file tecad_inv.baroc from the
$BINDIR/TME/INVENTORY directory.
4. Compile the Inventory rule base.
5. Load the Inventory rule base into the Tivoli Enterprise Console server.
242
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
6. Stop the Tivoli Enterprise Console server.
7. Restart the Tivoli Enterprise Console server.
For details about this procedure, see the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Enterprise Console → User’s Guide → Configuring the Tivoli
Enterprise Console product → Configuring the event server → Managing
rule bases.
If your environment is complex and contains multiple Tivoli Management Regions
or Tivoli Enterprise Console servers such as the Outlet Systems Management
Solution environment, the Inventory instances in each spoke TMR need to know
the location of the TEC server.
Perform the following steps from the spoketmr system:
1. Make the EventServer class visible from Inventory by running the following
command before connecting the two Tivoli regions:
wregister -i -r EventServer
wupdate -r EventServer hubtmr-region
2. This is an optional step. If more than one EventServer is present in the
environment, create the file $DBDIR/tecad_inv.conf on the inventory server.
This file should contain the following line:
ServerLocation=EventServer#server-region
server-region is the event server to which the events must be sent.
3. Run the wsetinvglobal -l <options> -t <options>
@InventoryConfig:<profile_name> command to verify your configuration.
Consult the User’s Guide for Inventory for details on the wsetinvglobal
command.
Verifying Inventory operation
To verify your inventory setup, you can create an InventoryConfig profile,
customize your hardware and software scan settings for PC or UNIX, then
distribute them to an endpoint. To get further details on how to setup an
InventoryConfig profile, you can refer to the section Creating an Inventory Profile
in Tivoli Configuration Manager - User’s Guide for Inventory.
Once you distribute an InventoryConfig profile, a mdist2 operation will take place
first to associate a distribution ID to the distribution.
1. From the hubtmr, run the wmdist -la command to get status of a scan. Pay
particular attention to the time the scan has been running. In our environment,
our scan for this profile took less then one minute to complete. If the scan is
Chapter 4. Installing the Tivoli Infrastructure
243
sitting at 0% completed for a time much longer then this, something might be
wrong and need to be analyzed.
The output will be similar to Example 4-22.
Example 4-22 Verifying inventory profile distribution using wmdist command
wmdist -la
Name Distribution ID Targets Completed Successful Failed
InventoryScan 1600263082.1 1 1(0%) 1(0%) 0( 0%)
HardwareScan 1600263082.2 1 1(0%) 1(0%) 0( 0%)
2. If the distribution is not shown in the above output, re-execute the wmdist with
only the -l option. You will get an output similar to Example 4-23.
Example 4-23 wmdist -l sample output
wmdist -l|tail -10
Name Distribution ID Targets Completed Successful Failed
InventoryScan 1600263082.1 1 1(100%) 1(100%) 0( 0%)
HardwareScan 1600263082.2 1 1(100%) 1(100%) 0( 0%)
3. If the distribution is completed on your target, the inventory data collection
could still be running. To check the status of the scan operation, you can use
the wgetscanstat command as shown:
wgetscanstat -a -p -f
4. When you get the output message No scans using the Inventory status
collector are in progress. you can use either wqueryinv <EP_name> or
wqueryinv -s <EP_name> based on whether you want a hardware or software
scan. You will get an output similar to Example 4-24.
Example 4-24 Command line invocation of Inventory queries - sample output
hubtmr:/etc # wqueryinv hubtmr-2nd-ep
Query Name: INVENTORY_HWARE
TME_OBJECT_LABEL,TME_OBJECT_ID,COMPUTER_SYS_ID,COMPUTER_SCANTIME,COMPUTER_MODEL
,COMPUTER_ALIAS,SYS_SER_NUM,OS_NAME,OS_TY
PE,PROCESSOR_MODEL,PROCESSOR_SPEED,PHYSICAL_TOTAL_KB,PHYSICAL_FREE_KB,TOTAL_PAG
ES,FREE_PAGES,PAGE_SIZE,VIRT_TOTAL_KB,VIR
T_FREE_KB
hubtmr-2nd-ep,1393424439.6.522+#TMF_Endpoint::Endpoint#,9A7FDB68-1DD1-11B2-8381
-8705A1D7E615,2004-11-01 13:21:17.000000,
VMware, Inc. VMware Virtual Platform,hubtmr,VMware-56 4d 1a ce 20 a4 1f
76-6,UnitedLinux 1.0 (i586) VERSION = 1.0 PATCHL
EVEL = 3 ,LINUX,Pentium 4,3000,514804,196352,125,47,4096,1036152,1034848
244
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
4.4.6 Configuring Software Distribution
After installation, the Software Distribution component of Tivoli Configuration
Manager is ready for use. However, some additional configuration steps are
required to facilitate integration between Software Distribution and related Tivoli
components, such as Inventory and TEC. These activities are
򐂰 ”Enabling SWD-Inventory integration”
򐂰 ”Enabling SWD and TEC Integration”
Because Software Distribution relies on the basic administrator roles (super,
admin, senior, and user) of the Tivoli management Framework, there is no need
to define specific roles for Software Distribution.
Enabling SWD-Inventory integration
Tivoli Software Distribution provides facilitates to automatically define software
signatures for Inventory based on definitions in software packages. The
signatures will be defined at the time of import of software packages, an only if
the software package specifically defines one or more files to be used as
signatures. By default, this feature is disabled.
In order to enable this automatic software signature definition issue the wswdinv
-y command on each managed node from which you will import software
packages.
In our case, software package import is only allowed from the managed node
srchost, so the command only needs to be executed there.
Enabling SWD and TEC Integration
Just like the Inventory component, Software Distribution (SWD) can send events
to the Tivoli Enterprise Console whenever specific Software Distribution actions
occur. Perform the following steps to facilitate the integration between SWD and
TEC:
1. Ensure the integration is enabled. The integration is enabled by default,
otherwise, use the wswdmgr command to enable the integration, as show in
step 2 on page 246.
2. Register the Software Distribution event classes on the Tivoli Enterprise
Console server.
3. Configure the event server, if necessary.
4. Create the Software Distribution Console.
Chapter 4. Installing the Tivoli Infrastructure
245
For more information about integrating SWD and TEC, refer to the Tivoli
Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Configuration Manager → User’s Guide for Software
Distribution → Integrating the Tivoli Enterprise Console.
The following procedure demonstrates the steps required to enable SWD to send
events to the TEC server in the Outlet Systems Management Solution.
1. Before connecting the Tivoli management regions, run the wregister
command to register the resource for the event server (EventServer) on all
the Software Distribution servers from which you want events sent and where
you want the EventServer class visible. Use the following command:
wregister -i -r EventServer
2. After you have installed Software Distribution, the Tivoli Enterprise Console
integration is enabled by default. If it is not enabled, use the wswdmgr
command to set the value of the is_swd_tec_enabled key to true. To display
the current setting, use the wswdmgr -s command on the Software
Distribution server as follows:
wswdmgr -s is_swd_tec_enabled=true
3. Software Distribution event classes are defined in the tecad_sdnew.baroc file,
located in the $BINDIR/TME/SWDIS/SPO directory on the Software Distribution
server.
To set a rule base to manage events and to install the Software Distribution
event classes on the event server, the swdistecsrvr_inst.sh script file is
provided and is located in the $BINDIR/TME/SWDIS/SCRIPTS directory.
Copy the following files from the Software Distribution server to a temporary
directory (for this example, /tmp) on the tec system:
$BINDIR/TME/SWDIS/SCRIPT/swdistecsrvr_inst.sh
$BINDIR/TME/SWDIS/SPO/tecad_sdnew.baroc
4. Run the swdistecsrvr_inst.sh script as follows, specifying the path (/tmp) of
the tecad_sdnew.baroc file using the -w option:
sh /tmp/swdistecsrvr_inst.sh -b <your_rule> -s aix270 -u root -p
<your_password> -t <your_console> -w /tmp/tecad_sdnew.baroc
246
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Note: If you are running this script in a Linux environment, you might need
to change the value of a variable inside the script to avoid an error such as
the following:
ECO2045W: "Tec_Console" is not a valid console.
This error is caused by the wrong case of a variable set inside the script.
The case must be changed to match the following:
TECCONSOLE=”tec_console”
5. Specify the event server where Software Distribution events should be sent.
The event server is specified by defining the SeverLocation key in the
tecad_sd.conf file located in the following path:
$BINDIR/TME/SWDIS/SPO/tecad_sd.conf
A sample file is shown in Example 4-25.
Example 4-25 tecad_sd.conf sample file
#######################################################
#
# Configuration file for Software Distribution 4.x
#
#######################################################
#
# Put the event server location here
ServerLocation=@EventServer
ConnectionMode=connection_oriented
RetryInterval=1
NO_UTF8_CONVERSION=NO
ServerPort=0
6. Complete the process by creating the Software Distribution console, as
described in the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Configuration Manager → User’s Guide for Software
Distribution → Integrating the Tivoli Enterprise Console → Creating the
Software Distribution Console.
4.4.7 Enabling the Activity Planner
Enabling the Activity Planner requires the completion of the following activities:
1. “Assigning APM roles to administrators” on page 248
2. “Creating the apm_db database” on page 248
Chapter 4. Installing the Tivoli Infrastructure
247
3.
4.
5.
6.
7.
8.
“Cataloging the apm_db database” on page 248
“Running the database admin and schema scripts for APM” on page 249
“Defining the planner RIM object” on page 249
“Registering plug-ins to APM” on page 251
“Managing Linux versions” on page 251
“Verifying Activity Planner operations” on page 251
Detailed information about enabling APM can be located in the Tivoli Information
Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Configuration Manager → User’s Guide for Deployment
Services.
Assigning APM roles to administrators
Use the following procedure to verify and assign APM roles to the Tivoli
administrator named Root_hubtmr-region:
1. From the Tivoli Desktop, double-click the Administrators icon.
2. Right-click the Root_hubtmr-region icon and select Edit TMR Roles.
3. Verify that the following roles are listed under Current Roles.
–
–
–
–
APM_Admin
APM_Edit
APM_Manage
APM_View
4. Select Change & Close.
Creating the apm_db database
Use the DB2 command create database apm_db from the desired instance user
to create the database for the Activity Planner. This step has probably already
been performed as part of the database installation and configuration described
in “Creating DB2 instances and databases” on page 150.
Cataloging the apm_db database
From the hubtmr system, issue the following commands to catalog the apm_db
database residing on the rdbms system.
1. Access the db2 client:
su - db2inst1
2. Define the instance on the rdbms system hosting the apm_db database:
catalog tcpip node db2swd remote rdbms.demo.tivoli.com server 60012
248
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Note: The instance name db2swd and related port number 60012 was
determined when creating the database instances as described in
“Creating DB2 instances and databases” on page 150.
Because the database instance named db2swd hosts multiple databases for
the Tivoli Configuration Manager components, chances are that the node
db2swd might have already been cataloged with the db2 client running at the
hubtmr system. Optionally, use the command db2 list node directory to
verify the existence of the catalog entry.
3. Catalog the apm_db database to make it accessible from the hubtmr system:
catalog database apm_db as apm_db at node db2swd authentication server
The apm_db database should now be accessible from the hubtmr system.
Running the database admin and schema scripts for APM
Once the apm_db database has been created, you can run the scripts to create
the database objects in the newly created database. These scripts are located in
$BINDIR/TME/APM/SCRIPTS/. Remember, these are sample scripts that must
be customized by your DBA before you execute them on the rdbms machine.
For DB2, the database object creation scripts are called:
plans_db2_admin.sql
plans_db2_schema.sql
Note: These scripts attempt to drop database objects such as tables before
they create them. As a result, for these commands you will see errors stating
the specified tables do not exist. These error messages are normal and are
not problems with the script.
Defining the planner RIM object
Based on the way you installed the APM component, you might be prompted to
provide information that will be used by the installation process to create the RIM
object for the Activity Planner by the name of planner.
We used the parameters shown in Table 4-24 to configure the planner RIM:
Table 4-24 Parameters for the planner RIM
Parameter
value
Database Vendor
DB2
RIM Host
hubtmr
Chapter 4. Installing the Tivoli Infrastructure
249
Parameter
value
Database ID
apm_db
Server ID
tcpip
DB_UserName
db2swd
APM_UserName
tivapm
APM_Password
********
Database Home
/opt/IBM/db2/V8.1
Instance Name (DB2 only)
db2inst1
Instance Home (DB2 only)
~db2inst1
During the installation of the Activity Planner server component, if it does not
already exist, a new user called tivapm is created on the operating system. This
user does not have any particular privileges, but it is necessary to create a
dedicated Tivoli administrator for that login. As a consequence, on the Tivoli
Desktop, a new administrator called swd_admin_region-name_region is created
and associated with this user. The Activity Planner engine requires the creation
of such a user and of the new administrator. When the engine performs
operations, it must authenticate itself with the Tivoli Management Framework,
and it uses this Administrator to do that.
The management of the password of this new user is very important. The Activity
Planner engine maintains an encrypted copy of this password internally. The
password maintained by the engine must always be synchronized with the
password of the operating system user. If the password of the user is changed on
the operating system, the password maintained by the engine must be changed
accordingly using the wsetapmpw command.
Note: Remember that the default password for planner RIM is planner. To
get the RIM working, change the password using the wsetrimpw command as
shown:
wsetrimpw planner planner <new pass>
1. If the planner RIM object was not created during installation, use the wcrtrim
command to create it.
2. Once the planner RIM object and the database to which it refers have been
created with the schema scripts, verify the connection using the wrimtest -l
planner command.
250
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Registering plug-ins to APM
The Activity Planner needs the inventory scan, Software Distribution, and task
library plug-ins registered in order to use those components. The scripts that can
be used to register the plug-ins to the Activity Planner are located in the
$BINDIR/TME/APM/SCRIPTS/ Tivoli directory, and are called:
reg_swd_plugin.sh
reg_inv_plugin.sh
reg_tl_plugin.sh
Software Distribution plug-in
Inventory Scan plug-in
Task Libraty plug-in
On the hubtmr system, execute each of these scripts to register the plug-ins.
To verify that the plug-ins have been registered, you can run this command:
wapmplugin -l
Managing Linux versions
Depending on the version of Linux you have installed, the Activity Planner engine
might not start. In this case, you must define the APM_KERNEL_LINUX and
APM_THREADS_FLAG variables to the Tivoli environment.
APM_KERNEL_LINUX
The default value for Linux kernel is 2.2.5. If you are using UnitedLinux with
Kernel Version 2.4.19, add the following variable to the Tivoli environment using
the odadmin environ set command:
APM_KERNEL_LINUX=2.4.19
APM_THREADS_FLAG
If you are using Linux Advanced Server set the LD_ASSUME_KERNEL variable
in the .profile file for the root user to 2.2.5. If the APM engine still does not start,
add the following variable to the Tivoli environment using the odadmin environ
set command:
APM_THREADS_FLAG=native
Verifying Activity Planner operations
The APM installation creates a Tivoli Administrator that is used for APM
operations. This Administrator is called swd_admin_tmrserver-region and user
tivapm is added as login name. In addition, all the APM and RIM Roles added by
the installation by default.
To verify your APM installation, run the Activity Plan Monitor or Activity Plan
Editor GUI from the Tivoli Desktop. A login dialog box similar to the one shown in
Figure 4-20 on page 252 will be displayed:
Chapter 4. Installing the Tivoli Infrastructure
251
.
Figure 4-20 Activity Plan Editor launch
The default user is tivapm and the password was defined during the APM
installation. Press OK to start the Activity Plan Editor desktop.
4.4.8 Enabling Change Manager
Enabling the Change Manager requires the completion of the following activities:
1.
2.
3.
4.
5.
6.
”Assigning CCM Roles to the Administrator”
“Creating the ccm_db database” on page 253
“Cataloging the ccm_db database” on page 253
“Running the database admin and schema scripts for CCM” on page 253
“Defining the CCM RIM object” on page 254
“Registering plug-ins to CCM” on page 255
Detailed information about enabling APM can be located in the Tivoli Information
Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Configuration Manager → User’s Guide for Deployment
Services.
Assigning CCM Roles to the Administrator
Use the following procedure to verify and assign CCM roles to the Tivoli
administrator named Root_hubtmr-region:
1. From the Tivoli Desktop, double-click the Administrators icon
2. Right-click the Root_hubtmr-region icon and select Edit TMR Roles.
3. Verify that the following roles are listed under Current Roles:
–
–
–
–
–
252
CCM_Admin
CCM_Edit
CCM_Manage
CCM_View
RIM_update
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
– RIM_view
– user
4. Select Change & Close.
Creating the ccm_db database
Use the DB2 command create database ccm_db from the desired instance user
to create the database for the Change Manager. This step has probably already
been performed as part of the database installation and configuration described
in “Creating DB2 instances and databases” on page 150.
Cataloging the ccm_db database
From the hubtmr system, issue the following commands to catalog the ccm_db
database residing on the rdbms system.
1. Access the db2 client:
su - db2inst1
2. Define the instance on the rdbms system hosting the ccm_db database:
catalog tcpip node db2swd remote rdbms.demo.tivoli.com server 60012
Note: The instance name db2swd and related port number 60012 were
determined when creating the database instances as described in
“Creating DB2 instances and databases” on page 150
Because the database instance named db2swd hosts multiple databases
used by Tivoli Configuration Manager components, chances are that the node
db2swd might have already been cataloged with the db2 client running at the
hubtmr system. Optionally, you can use the db2 list node directory
command to verify the existence of the catalog entry.
3. Catalog the ccm_db database to make it accessible from the hubtmr system:
catalog database ccm_db as ccm_db at node db2swd authentication server
The ccm_db database should now be accessible from the hubtmr system.
Running the database admin and schema scripts for CCM
Once the CCM database has been created you can run the scripts to create the
database objects needed to store CCM data. These scripts are located in the
$BINDIR/TME/CCM/SCRIPTS/ directory.
Remember, these are sample scripts that must be customized by your DBA
before their execution on the rdbms machine.
Chapter 4. Installing the Tivoli Infrastructure
253
For DB2, the database object creation scripts are called:
ccm_db2_admin.sql
ccm_db2_schema.sql
Note: These scripts attempt to drop database objects such as tables before
they create them. Thus, for these commands you will see errors stating the
specified tables do not exist. These are normal and are not problems with the
scripts.
Defining the CCM RIM object
Based on the way you installed the CCM component, you might be asked to
provide parameters to be used by the installation process to create the CCM RIM
object, which is used by the Change Manager to store information.
We used these parameters in Table 4-25 to configure the RIM:
Table 4-25 Parameters for the ccm RIM
Parameter
value
Database Vendor
DB2
RIM Host
hubtmr
Database ID
ccm_db
Server ID
tcpip
DB_UserName
db2swd
Database Home
/opt/IBM/db2/V8.1
Instance Name (DB2 only):
db2inst1
Instance Home (DB2 only)
~db2inst1
If the CCM RIM object was not created during installation, use the wcrtrim
command to create it.
Once the CCM RIM object and the database to which it refers have been created
using the schema scripts, verify the connection with the wrimtest -l ccm
command.
Note: Remember that the default password for CCM RIM is tivoli. To get the
RIM working, you need to change the password using the wsetrimpw
command as shown below:
wsetrimpw ccm tivoli <new pass>
254
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Registering plug-ins to CCM
The Change Manager needs the inventory scan and Software Distribution
plug-ins registered in order to use those components. The scripts that can be
used to register the plug-ins to the Change Manager are located in the directory:
/usr/local/Tivoli/bin/aix4-r1/TME/CCM/SCRIPTS/, and are called:
reg_swd_plugin.sh
reg_invscan_plugin.sh
Software Distribution plug-in
Inventory Scan plug-in
1. Execute each of these scripts to register the plug-ins.
2. To verify that the plug-ins have been registered, run the wccmplugin -l
command.
Verifying the Change Manager operation
To verify your CCM installation, run the Change Manager GUI from the Tivoli
Desktop. A login dialog box similar to the one shown in Figure 4-21 will be
displayed:
.
Figure 4-21 Change Manager launch dialog
The default user is root and the password is the one defined for the root user.
Press OK to display the Change Manager Desktop.
4.4.9 IBM Tivoli Monitoring configuration
To set up and configure IBM Tivoli Monitoring for use in the Outlet Systems
Management Solution environment, the following steps must be completed:
1. “Assigning ITM Administrator Roles” on page 256
2. “IBM Tivoli Monitoring event and heartbeat message reception” on page 256
3. “Enabling endpoint heartbeating” on page 258
Chapter 4. Installing the Tivoli Infrastructure
255
Assigning ITM Administrator Roles
Before using IBM Tivoli Monitoring it is necessary to assign the proper roles to
the Tivoli Administrator. This has to be performed on the TMR server in each
TMR - the hubtmr and spoketmr systems in out setup.
From the Tivoli Desktop:
1. Double-click the Administrators icon
2. Right-click the Root_hubtmr-region icon and select Edit TMR Roles.
3. Make sure that the following roles are listed under Current Roles:
– itm_whc_user
– itm_tasks
4. Select Change & Close.
IBM Tivoli Monitoring event and heartbeat message reception
To enable forwarding of Tivoli Monitoring events on a Tivoli Enterprise Console
(TEC), you need to import the Tivoli Monitoring BAROC files into the rule base
used by the Tivoli Enterprise Console server.
Even though scripts (dmae_tec_inst.sh) and tasks
(DMCreateRuleAndLoadBaroc) are provided to accomplish this task, the files
required for successful completion are not available at the TEC Server machine
because ITM has not been installed there. Since the ITM class and rule-set files
are located only on the systems where ITM was installed (hubtmr and spoketmr)
the files needs to copied to the TEC system for processing, so for the Outlet
Systems Management Solution the tasks and scripts provided with the ITM
product will not work.
To enable ITM event and heartbeat message reception in TEC, perform the steps
outlined in this section. For full information about performing each step of the
procedure, refer to the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Enterprise Console → User’s Guide → Configuring the Tivoli
Enterprise Console product → Configuring the event server → Managing
rule bases.
To enable monitoring and message reception, perform the following steps:
1. Select an existing rule base or create a new rule base to contain the Tivoli
Monitoring BAROC files.
2. Copy all the *.baroc and *.rls files from the $BINDIR/TMNT_TEC directory at
the hubtmr or spoketmr server to the rule base directory on the tec system
identified in the previous step.
256
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
3. Import the required BAROC files from the rule base directory into the rule
base. It is important that you import the files in the following order:
a. The Tmw2k.baroc file
b. BAROC files for all the resource models for which events you want to send
to TEC
For the Outlet Systems Management Solution we imported the following
ITM specific BAROC files:
•
•
•
•
•
•
•
•
•
DMXPhysicalDisk.baroc
DMXCpu.baroc
DMXFile.baroc
DMXFileSystem.baroc
DMXMemory.baroc
DMXNetworkInterface.baroc
DMXNetworkRPCNFS.baroc
DMXProcess.baroc
DMXSecurity.baroc
c. The hb_events.baroc file to enable heartbeat messages
4. Import the required heartbeat rules file into the rule base to enable the
support of heartbeat messages. The file is called hb_events.rls. For more
information about the rules contained in this file, see “Understanding the Tivoli
Enterprise Console rules” in the IBM Tivoli Monitoring User’s Guide 5.1.2.
5. Import the required clearing event rules file into the rule base to enable
clearing events to close the error events to which they relate. The file is called
dmae_events.rls. For more information about the rules contained in this file,
see “Understanding the Tivoli Enterprise Console rules” in the IBM Tivoli
Monitoring User’s Guide 5.1.2.
6. Compile and load the rule base.
7. Stop and restart the Tivoli Enterprise Console server.
The TEC server is now ready to receive Tivoli Monitoring events from the
monitoring sources, the corresponding BAROC files of which you have imported
into the active rule base. To see the events sent by Tivoli Monitoring from the
Tivoli Enterprise Console main dialog box, click the All icon.
Note: The BAROC available with this version of Tivoli Monitoring can also be
used with Tivoli Distributed Monitoring (Advanced Edition) 4.1 or with Tivoli
Distributed Monitoring for Windows 3.7 Patch 3.
Chapter 4. Installing the Tivoli Infrastructure
257
Enabling endpoint heartbeating
Heartbeats for endpoints are controlled by the gateways serving each endpoint.
Therefore this function is controlled on a managed-node level. The command
used to control heartbeating is wdmheartbeat. Refer to IBM Tivoli Monitoring
User’s Guide 5.1.2 for details on the syntax.
1. Before defining the heartbeat frequency, we need to configure the heartbeat
engine on all gateways, and because new configurations require restart of the
heartbeat engine, we start by stopping the heartbeat engine on all gateways.
wdmmn -stop -m all -h
2. Next we want notifications and events to be sent to the TEC server in the
event the heartbeat function discovers that an endpoint is down, and we want
the heartbeat engine to start automatically if it goes down. These additional
configuration items in Example 4-26 are set using the wdmconfig command.
Example 4-26 Notifications to the TEC server
wdmconfig
wdmconfig
wdmconfig
wdmconfig
-m
-m
-m
-m
all
all
all
all
-D
-D
-D
-D
heartbeat.send_events_to_notice=true
heartbeat.send_events_to_tec=true
heartbeat.tec_server=EventServer
heartbeat.reboot_engine_if_down=true
3. FInally, we are ready to enable heartbeating in the Outlet Systems
Management Solution. We enable heartbeating every 60 seconds for all
endpoints controlled by all gateways in each TMR by issuing the following
command in from both the hubtmr and the spoketmr systems:
wdmheartbeat -m all -s 60
Note that all heartbeat enablement commands should be issued from both
the hubtmr and the spoke tmr systems.
4. Use the wdmheartbeat -m all -q command to verify the status of the
heartbeat function. The output shown in Example 4-27 shows the heartbeat
status from spoketmr.
Example 4-27 Querying the status of heartbeating
spoketmr:/usr/local/Tivoli/bin/linux-ix86 # wdmheartbeat -m all -q
Processing ManagedNode spoketmr...
HeartBeat processor status: STARTED, frequency: 60 (secs).
Processing ManagedNode region01...
HeartBeat processor status: STARTED, frequency: 60 (secs).
Processing ManagedNode outlet01...
HeartBeat processor status: STARTED, frequency: 120 (secs).
Processing ManagedNode hubtmr...
HeartBeat processor status: STARTED, frequency: 60 (secs).
258
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
4.4.10 IBM Tivoli Monitoring for Web Infrastructure
Enabling the monitoring of WebSphere servers through IBM Tivoli Monitoring for
Web Infrastructure (WI) requires a few post-installation steps before it can be
used. These are;
1. ”Assigning IBM Tivoli Monitoring for WI Roles to the Administrator”
2. “Defining IBM Tivoli Monitoring for WI events and rules to TEC” on page 259
3. “Updating Web Health Console files for IBM Tivoli Monitoring for WI” on
page 262
Detailed information about enabling IBM Tivoli Monitoring for Web Infrastructure
can be located in the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Monitoring for Web Infrastructure → Installation and Setup
Guide.
Assigning IBM Tivoli Monitoring for WI Roles to the
Administrator
Before monitoring WebSphere Application Server, it is necessary to assign the
proper roles to the Tivoli Administrator. For additional information, refer to the
instructions in the IBM Tivoli Monitoring for Web Infrastructure: WebSphere
Application Server User’s Guide under the section titled “Setting authorization
roles.”
From the Tivoli Desktop, perform the following steps:
1. Double-click the Administrators icon.
2. Right-click the Root_hubtmr-region icon and select Edit TMR Roles.
3. Verify that the following roles are listed under Current Roles:
– websphereappsvr_super
– websphereappsvr_admin
– websphereappsvr_user
4. Select Change & Close.
Defining IBM Tivoli Monitoring for WI events and rules to TEC
To set up your Tivoli Enterprise Console event server to process IBM WebSphere
Application Server events, you need to copy the BAROC and rule set files to the
TEC Server machine, import the appropriate TEC class and rule set files into a
TEC rule base, compile and load the rule base and restart the TEC Server.
Chapter 4. Installing the Tivoli Infrastructure
259
The classes required to be copied to the tec system, and imported into the
rulebase are:
򐂰
򐂰
򐂰
򐂰
򐂰
WebSphere_MQ_Channel.baroc
WebSphere_MQ_QueueManager.baroc
WebSphere_MQ_Queue.baroc
itmwas_events.baroc
itmwas_dm_events.baroc
And the following rule sets are also required:
򐂰 itmwas_events.rls
򐂰 itmwas_monitors.rls
Detailed information about the classes and rule sets are available in the Tivoli
Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Monitoring for Web Infrastructure → Reference Guide.
All of these steps have been performed already. See “IBM Tivoli Monitoring event
and heartbeat message reception” on page 256, but IBM Tivoli Monitoring for
Web Infrastructure provides a task that automates the process. The name of the
task is Configure_Event_Server, and it can be found in the WebSphere Event
Tasks task library.
The task can be invoked from the Tivoli Desktop through the WebSphere Event
Tasks task library, found in the Monitoring for WebSphere Application Server
policy region. The task can also be executed from the command line, as shown
in the Example 4-28, where we are extending the rule base that was build for
ITM, as described in “IBM Tivoli Monitoring event and heartbeat message
reception” on page 256.
Example 4-28 ITM for WI Configure_Event_Server task invocation
hubtmr:/ # wruntask -t Configure_Event_Server -l "WebSphere Event Tasks" -h tec
-m 300 -o 15 -a UPDATE -a Production -a "" -a "" -a RESTART
############################################################################
Task Name:
Configure_Event_Server
Task Endpoint: tec (ManagedNode)
Return Code:
0
------Standard Output-----IZY9035I Configuring the event server.
IZY9001I The Configure Event Server task is preparing the rule base.
IZY9010I Rule base Production was compiled successfully.
IZY9047I Importing classes.
260
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
IZY9008I IBM Tivoli Monitoring classes are already installed.
IZY9016I Imported classes in file itmwas_events.baroc into rule base
Production.
IZY9016I Imported classes in file itmwas_dm_events.baroc into rule base
Production.
IZY9026I
IZY9018I
IZY9043I
IZY9018I
IZY9043I
Importing rules.
Replacing rules in file itmwas_events.rls in rule base Production.
Imported rules in file itmwas_events.rls into rule base Production.
Replacing rules in file itmwas_monitors.rls in rule base Production.
Imported rules in file itmwas_monitors.rls into rule base Production.
IZY9010I Rule base Production was compiled successfully.
IZY9027I Installing event sources.
IZY9021I Event source WAS already exists.
IZY9021I Event source TMNT already exists.
IZY9029I Activating the rule base.
IZY9024I Rule base Production was loaded.
IZY9030I The event server was stopped.
The Tivoli Enterprise Console Server is initializing...
The Tivoli Enterprise Console Server is running.
IZY9031I Event server started.
IZY9039I The Configure Event Server task completed successfully.
------Standard Error Output-----############################################################################
As shown, the task requires four parameters, which are all described in the Tivoli
Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Monitoring for Web Infrastructure → Reference Guide → IBM
WebSphere Application Server tasks → Configure_Event_Server.
Note: We specified a task execution time-out value of 300 seconds to allow
enough time for the rule base changes to complete. The default task
execution time-out value is 60 seconds, which is insufficient for this task.
Chapter 4. Installing the Tivoli Infrastructure
261
Updating Web Health Console files for
IBM Tivoli Monitoring for WI
This procedure describes how to update the class files for the Web Health
Console to support IBM Tivoli Monitoring for Web Infrastructure. The class files
specify the standard text that the console displays. Whenever you add or
upgrade components for your installation of IBM Tivoli Monitoring for Web
Infrastructure, you must perform this procedure.
1. Copy the contents of the HCONSOLE directory of catalog files from the IBM
Tivoli Monitoring for Web Infrastructure, Version 5.1.2, Component Software
CD to the Web Health Console resources directory, which can be found in the
<WASHOME>/installedApps/dm.ear/dm.war/WEB-INF/classes/com/tivoli/DmF
orNt/resources on the system hosting the Web Health Console, the console
system for the Outlet Systems Management Solution.
4.4.11 IBM Tivoli Monitoring for Databases
Enabling the monitoring of DB2 Servers through IBM Tivoli Monitoring for
Databases requires a few post-installation steps before it can be used. These
are;
1. ”Assigning IBM Tivoli Monitoring for DB2 Roles to the Administrator”
2. ”Defining IBM Tivoli Monitoring for DB2 events and rules to TEC”
3. ”Updating Web Health Console files for IBM Tivoli Monitoring for DB2”
4. ”Link the Monitoring for DB2 policy region on root Desktop”
each of which are described in detail in the following.
Detailed information about enabling ITM for WI can be located in the Tivoli
Information Center at
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp and navigate
to Monitoring for Databases → Installation and Setup Guide
Assigning IBM Tivoli Monitoring for DB2 Roles to the
Administrator
Before monitoring DB2, it is necessary to give the administrators the proper
roles. From the Tivoli Desktop, perform the following steps:
1. Double-click the Administrators icon/
2. Right-click the Root_hubtmr-region icon and select Edit TMR Roles.
262
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
3. Verify that the following roles are listed under Current Roles:
– db2_user
– db2_dba
4. Select Change & Close.
Link the Monitoring for DB2 policy region on root Desktop
The installation creates a new policy region called Monitoring for DB2, which by
default is not visible on the Tivoli Desktop. You can link it to the root
Administrator’s Desktop to store similar managed resources to share one or
more common policies. To set up the link, run the following command:
wln @PolicyRegion:"Monitoring for DB2#hubtmr-region"
/Administrators/Root_hubtmr-region
Note: If you have interconnected TMRs, you must use the above command to
reference the Monitoring for DB2 policy region instead of referencing the
object with the database format /Regions/”Monitoring for DB2.
In that case, you will get an error messages similar to the following:
FRWAE0134E Object label Monitoring for DB2 is ambiguous.
are:
1393424439.1.1211#TMF_PolicyRegion::GUI#
1282790711.1.1084#TMF_PolicyRegion::GUI#
Matching objects
For the Outlet Systems Management Solution, we also created a subregion
called DB2 Database Servers within the Monitoring for DB2 policy region to
contain all of the DB2 related objects.
Defining IBM Tivoli Monitoring for DB2 events and
rules to TEC
This section provides information about setting up the Tivoli Enterprise Console
(TEC) for use with the IBM Tivoli Monitoring for Databases: DB2.
To set up your Tivoli Enterprise Console event server to process events related
to DB2 Servers generated by ITM for DB, you need to copy the necessary
BAROC and rule set files to the TEC Server machine, import the appropriate
TEC class and rule set files into a TEC rule base, compile and load the rule base
and restart the TEC Server.
The classes required to be copied to the tec system, and imported into the
rulebase are:
򐂰 DB2_Event.baroc
򐂰 DB2Agents.baroc
Chapter 4. Installing the Tivoli Infrastructure
263
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
DB2HostThroughput.baroc
DB2CpuUtilization.baroc
DB2DatabaseStatus.baroc
DB2InstanceStatus.baroc
DB2ApplyReplication.baroc
DB2BufferPool.baroc
DB2BufferPoolExtStorage.baroc
DB2CatalogCache.baroc
DB2Cursor.baroc
DB2DirectIO.baroc
DB2FCMActivity.baroc
DB2LockWaits.baroc
DB2Locks.baroc
DB2Logging.baroc
DB2PackageCache.baroc
DB2ReplicationCapture.baroc
DB2SAPTablespaceUsageStatus.baroc
DB2SQLStatementActivity.baroc
DB2Sorts.baroc
DB2TableActivity.baroc
DB2TableApplyReplication.baroc
No rule sets are used.
For a listing of event classes and events, see the Tivoli Information Center Web
site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Monitoring for Databases → Reference Guide.
All of these steps haves been performed previously. See “IBM Tivoli Monitoring
event and heartbeat message reception” on page 256. However, IBM Tivoli
Monitoring or Databases provides a task that automates the process. The name
of the task is ECC_Configure_TEC_Classes, and it can be found in the
DB2ManagerAdminTasks task library.
You can invoke the task two ways:
򐂰 From the Tivoli Desktop through the DB2ManagerAdminTasks task library,
found in the Monitoring for DB2 policy region
264
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
򐂰 From the command line (shown in this section.)
Note: The ECC_Configure_TEC_Classes task must be run from a managed
node at which IBM Tivoli Monitoring for Databases has been installed. The
target of the execution (the -h parameter) must point to the TEC server
machine (tecm in our case), and can only be used if you are going to create a
new Rule Base. It cannot be used to modify your production Rule Base.
1. For the Outlet Systems Management Solution we executed the task:
wruntask -t ECC_Configure_TEC_Classes -l DB2ManagerAdminTasks -h tec -a
"ITMfDB2" -a "Production" -a DB2 -a N -m 600
We specified a task execution time-out value of 600 seconds to allow enough
time for the rule base changes to complete. The default task execution
time-out value is 60 seconds, which is insufficient for this task.
The task requires four parameters, which are all described in the Tivoli
Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Monitoring for Databases → Reference Guide → DB2
Manager Admin Tasks → ECC_Configure_TEC_Classes.
Note: During task execution you might receive one or more of the error
messages below:
򐂰 ECO3042E Can not import
hubtmr:/usr/local/Tivoli/bin/generic/ITM/DB2/TECClasses/DB2_Event.b
aroc to rule base:
򐂰 Error::ECO:0001:0196 The class file named DB2_Event.baroc is
already defined in the specified rule base.
These messages only advise you that the specified baroc file has already
been imported into the Rule Base.
2. To verify that the classes have been successfully loaded, you can execute
this sample command:
wpostemsg -m "Testing ITM for Databases: DB2 Component Software baroc
files" -r FATAL DB2_High_TimePerStatement DB2_Event
The output of the wtdumprl should list the event as PROCESSED, as in
Example 4-29.
Chapter 4. Installing the Tivoli Infrastructure
265
Example 4-29 TEC reception log output
1~685~65537~1100683885(Nov 17 03:31:25 2004)
### EVENT ###
DB2_High_TimePerStatement;source=DB2_Event;severity=FATAL;msg=Testing ITM for
Databases: DB2 Component Software baroc files;origin=10.1.1.2;END
### END EVENT ###
PROCESSED
Updating Web Health Console files for IBM Tivoli Monitoring
for DB2
This procedure describes how to update the class files for the Web Health
Console to support IBM Tivoli Monitoring for Databases. The class files specify
the standard text that the console displays. Whenever you add or upgrade
components for your installation of IBM Tivoli Monitoring for Databases you must
perform this procedure.
1. Copy the contents of the HCONSOLE directory of catalog files from the IBM
Tivoli Monitoring for Databases, Version 5.1.0: DB2, Component Software CD
to the Web Health Console resources directory, which can be found in the
<WASHOME>/installedApps/dm.ear/dm.war/WEB-INF/classes/com/tivoli/DmF
orNt/resources on the system hosting the Web Health Console, the console
system for the Outlet Systems Management Solution.
4.4.12 IBM Tivoli Monitoring for Transaction Performance
Enabling the monitoring of transactions through IBM Tivoli Monitoring for
Transaction Performance (TMTP) requires a few postinstallation steps before it
can be used. These are;
1. ”Configuring TEC to work with TMTP”
2. “Integrating the Web Health Console” on page 269
Detailed information about enabling Tivoli Monitoring for Transaction
Performance can be located in the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Monitoring for Transaction Performance → Installation and
Configuration Guide and Monitoring for Transaction Performance →
Problem Determination Guide.
Configuring TEC to work with TMTP
For Tivoli Enterprise Console to receive events from IBM TMTP, verify that the
TransPerf.baroc file has been loaded into the active rule base and the TEC
266
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
server has been restarted. The TransPerf.baroc file is located in the
<MS_insatll>/config/tec directory on the TMTP server machine. See the
instructions provided in “IBM Tivoli Monitoring event and heartbeat message
reception” on page 256 for details on how to import a new BAROC file into a rule
base.
Use the following steps to configure Tivoli Enterprise Console:
1. Perform the following steps on the management server, the tmtpsrv system in
our case, to configure it to work with Tivoli Enterprise Console:
a. Edit the eif.conf file, located in the <MS_install>/config directory.
b. Define the Tivoli Enterprise Console event server by setting the
ServerLocation property to the fully qualified host name of the TEC server.
c. If the event server is located on a UNIX computer, set ServerPort=0. The
default value is 5529, which is valid for Microsoft Windows.
The two affected sections of the eif.conf file used in the Outlet Systems
Management Solution as shown in Example 4-30.
Example 4-30 TMTP configuration of TEC Server
###############################################################################
#ServerLocation=host
#
#Specifies the name of the host on which the event server is installed. The
#value of this field must be one of the formats shown in Table below, depending on
#whether the adapter is a TME adapter or a non-TME adapter, and whether the event
#server is part of an interconnected Tivoli management region:
#
#Adapter Type
Format
#---------------------------------------------------#TME
@EventServer
#
#TME in an interconnected
#Tivoli management region
@EventServer#region_name
#
#non-TME
host_name or IP_address.
#
#
#The ServerLocation keyword is optional and not used when the TransportList keyword
#is specified.
#
#Note:
#
The ServerLocation keyword defines the path and name of the file for logging
#events, instead of the event server, when used with the TestMode keyword.
###############################################################################
#
# NOTE: SET THE VALUE BELOW AS SHOWN IN THIS EXAMPLE TO CONFIGURE TEC EVENTS
#
# Example: ServerLocation=marx.tivlab.austin.ibm.com
#
Chapter 4. Installing the Tivoli Infrastructure
267
ServerLocation=tec.demo.tivoli.com
###############################################################################
#ServerPort=number
#
#Specifies the port number on a non-TME adapter only on which the event server
#listens for events. Set this keyword value to zero (0), the default value,
#unless the portmapper is not available on the event server, which is the case
#if the event server is running on Microsoft Windows or the event server is a
#Tivoli Availability Intermediate Manager (see the following note). If the port
#number is specified as zero (0) or it is not specified, the port number is
#retrieved using the portmapper.
#
#The ServerPort keyword is optional and not used when the TransportList keyword
#is specified.
###############################################################################
#ServerPort=5529
#commented by Fabrizio. Must be set to 0 if the TEC server runs on Linux
ServerPort=0
d. Shut down and restart the management server.
2. Run the following command on the Tivoli Enterprise Console event server to
add IBM Tivoli Monitoring for Transaction Performance to the Tivoli object
database that event consoles use to create event filters:
wcrtsrc -l TMTP TMTP
3. To verify that the setup is complete you can run the following sample
command:
wpostemsg -m Test -r FATAL TMTP-MS-Event TMTP-Event
Running wtdumprl from the TEC server machine, you should see an output
similar to Example 4-31.
Example 4-31 TMTP event processing verification
1~94~65537~1100112031(Nov 10 12:40:31 2004)
### EVENT ###
TMTP-MS-Event;source=TMTP-Event;severity=FATAL;msg=Test;origin=10.1.1.2;END
### END EVENT ###
PROCESSED
For further instructions to set up the connections between TEC and TMTP, refer
to in the Tivoli Information Center Web site
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Monitoring for Transaction Performance → Administrator’s
Guide → Configuring communications in the monitoring environment →
Configuring Tivoli Enterprise Console to work with IBM Tivoli Monitoring
for Transaction Performance.
268
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Integrating the Web Health Console
The Web Health Console Fixpack 5 added a feature to externally launch the
WHC using a URL. When enough information is passed to it in the form of URL
arguments, the WHC will automatically log in the user and display endpoint
information. This is not a required piece of the WHC, and in fact, only one Tivoli
application, TMTP, uses it to launch the WHC, so you can easily skip this step if
you are not interested.
To install the Launch ITM application, perform the following steps:
1. Open a Web browser to load the WebSphere Application Server
Administrative Console using this URL:
http://console:9090/admin
2. In the WebSphere Application Server Administrative Console, install
LaunchITM.ear. Accept all defaults for installation. Save the WebSphere
Application Server master configuration after the install is complete.
a. Click Applications → Enterprise Applications.
b. Click the install button and give the path to the LaunchITM.ear from the
patch bundle.
c. Accept all defaults (do not check anything) and click Finish.
d. Select the link Save at the top of the page.
e. Click the Save button.
f. Exit from the WebSphere Application Server Administrative Console.
3. Edit the file /opt/IBM/WebSphere/AppServer/installedApps/console/ITM
Launcher.ear/LaunchITM.war/jsp/LaunchWHC.jsp
a. Find the line containing the following:
String serverName = scheme + "://" + serverHostname;
b. Add the port to the serverName, so the string is replaced exactly as
follows:
String serverName = scheme + “://” + serverHostname + “:9080”;
4. Restart the WebSphere Application Server.
5. Launch the TMTP Administrative Console from your browser:
https://tmtpsrv:9445/tmtpUI/
6. Click System Administration → Configure User Settings.
7. Enter the requested information similar to what is shown in Figure 4-22 on
page 270:
Chapter 4. Installing the Tivoli Infrastructure
269
Figure 4-22 TMTP: Web Health Console Integration
For further instructions to launch the Web Health Console from TMTP, refer to
the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Monitoring for Transaction Performance → User’s Guide and
Monitoring for Transaction Performance → Problem Determination Guide.
270
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
5
Chapter 5.
Creating profiles, packages,
and tasks
For the Outlet Systems Management Solution, we assumed that all the deployed
systems will be delivered with the correct level of operating system installed and
configured to connect to the network without intervention. Once active, it is the
task of the deployment team to install the required software components to
support the role of a system, and facilitate monitoring to help ensure smooth
operation.
This chapter discusses the definition of the Tivoli objects, profiles, packages and
tasks that will be necessary to create to fulfill this mission.
The common goal for the activities described in this chapter is to enable
automatic deployment through the use of an Analysis Point Monitoring (APM)
plan, which will be deployed automatically when new endpoints are discovered.
For each major, managed component, the logical flow of activities is:
1. Core component customization
2. Monitoring policy definition and profile creation
3. Discovery (if applicable)
However, before embarking on these tasks, we need to define the overall profile
manager structure to which the managed systems will subscribe.
© Copyright IBM Corp. 2005. All rights reserved.
271
5.1 Defining the logical structure of the environment
As described in 3.3, “Logical Tivoli architecture for Outlet Inc.” on page 49, the
managed systems will be subscribed to profile managers organized in
hierarchies. These hierarchies will allow us to target all systems with similar
attributes (location, architecture, applications) in a single operation.
All master profiles are kept in the hubtmr environment to which profile managers
at the spoke TMRs will be subscribed. To allow for easy assignment of
authorizations to manipulate the objects, each type of profile is kept in a separate
profile manager. The profile managers we need at the hubtmr are all stored in the
hubtmr-region. The ones we will need for the Outlet Systems Management
Solution are:
hubtmr-region_MASTER_PM_INV
hubtmr-region_MASTER_PM_TEC
hubtmr-region_MASTER_PM_ITM
hubtmr-region_MASTER_PM_SWD
To be used for Inventory profiles
To be used for ACP profiles
To be used for Monitoring profiles
To be used for software packages
We will need a dataless profile manager to which the endpoints to be managed
will be subscribed. In the Outlet Systems Management Solution, we create the
hubtmr-region_MASTER_PMS_linux-ix86 profile manager for this purpose.
1. Create the profile managers from the hubtmr system using the wcrtprfmgr
command as demonstrated in Example 5-1.
Example 5-1 Creating profile managers with crtprfmgr
wcrtprfmgr hubtmr-region hubtmr-region_MASTER_PM_INV
wcrtprfmgr hubtmr-region hubtmr-region_MASTER_PM_ITM
wcrtprfmgr hubtmr-region hubtmr-region_MASTER_PM_SWD
wcrtprfmgr hubtmr-region hubtmr-region_MASTER_PM_TEC
wcrtprfmgr hubtmr-region hubtmr-region_MASTER_PMS_linux-ix86
wsetpm -d @ProfileManager:hubtmr-region_MASTER_PMS_linux-ix86
2. Create the main hierarchy at the spoke TMRs and subscribe the new profile
managers to the one on the hubtmr. From the spoketmr system, issue the
following commands, as in Example 5-2.
Example 5-2 Issuing wcrtprfmgr from the spoketmr system
wcrtprfmgr spoketmr-region spoketmr-region_MASTER_PM_INV
wcrtprfmgr spoketmr-region spoketmr-region_MASTER_PM_ITM
wcrtprfmgr spoketmr-region spoketmr-region_MASTER_PM_SWD
wcrtprfmgr spoketmr-region spoketmr-region_MASTER_PM_TEC
wcrtprfmgr spoketmr-region spoketmr-region_MASTER_PMS_linux-ix86
wsetpm -d @ProfileManager:spoketmr-region_MASTER_PMS_linux-ix86
272
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
3. After exchanging resources between the TMR environments using the
wupdate -r ProfileManager spoketmr-region command, you can subscribe
the spoketmr profile managers to the hubtmr profile managers as in
Example 5-3:
Example 5-3 Subscribing the spoketmr and hubtmr profile managers
wsub @ProfileManager:hubtmr-region_MASTER_PM_INV
@ProfileManager:spoketmr-region_MASTER_PM_INV
wsub @ProfileManager:hubtmr-region_MASTER_PM_ITM
@ProfileManager:spoketmr-region_MASTER_PM_ITM
wsub @ProfileManager:hubtmr-region_MASTER_PM_SWD
@ProfileManager:spoketmr-region_MASTER_PM_SWD
wsub @ProfileManager:hubtmr-region_MASTER_PM_TEC
@ProfileManager:spoketmr-region_MASTER_PM_TEC
5.2 Deploying management endpoints
To test the monitoring profiles and software packages we will create, we have to
have at least one test system defined as an endpoint. In this section, we
introduce a new system, dev01, which will be the target of the management
operations while we develop and test profiles.
In addition, a new policy region for holding only endpoint definitions is created as
a subregion of the main hubtmr-region.
wcrtpr -s /Regions/hubtmr-region -m Endpoint hubtmr-region_EP
1. To manage the dev01 system, the Tivoli Management Agent, known as the
endpoint, needs to be installed. This action is performed from the hubtmr
system itself using the winstlcf command as shown:
winstlcf -j -g hubtmr:9494 -l 9495 -n dev01-ep -r hubtmr-region_EP -Y
‘dev01 root <password>’
The wlcfinst command installs a TMA on the dev01 system and assigns the
gateway on the hubtmr system as the default gateway for the new endpoint
labeled dev01-ep. Authentication is gained through ssh (the -j parameter)
using the root user and the valid password for that user. Finally, upon
installation, the new endpoint is defined to the Tivoli environment in the
hubtmr-region_EP policy region.
2. To verify that the endpoint has been defined, use the wep <ep_label> status
command, and verify that the returned message indicates that the endpoint is
alive - as shown in Example 5-4:
Chapter 5. Creating profiles, packages, and tasks
273
Example 5-4 Verifying endpoint availability
hubtmr:/ # wep dev01-ep status
dev01-ep is alive.
3. Finally the new endpoint , dev01-ep, needs to be subscribed to the
hubtmr-region_PMS-linux-ix86 profile manager, which in turn is subscribed to
all the resource specific profile managers hosting the monitoring profiles:
wsub @ProfileManager:hubtmr-region_MASTER_PMS_linux-ix86 @Endpoint:dev01-ep
5.3 Creating monitoring profiles
Now that the logical structure has been established, and a test system is
available, we can define the profiles used to monitor the systems. For the Outlet
Systems Management Solution we define profiles for:
򐂰
򐂰
򐂰
򐂰
򐂰
Inventory scanning
System Resource Monitoring
Event forwarding
WebSphere Monitoring
Database Monitoring
5.3.1 Inventory scanning
In the Outlet Systems Management Solution, we operate with separate
InventoryConfig profiles for hardware, and software scanning, and will also
create a CUSTOM profile that can be used for implementation specific purposes.
The steps required to create these profiles are:
1.
2.
3.
4.
5.
Create and InventoryConfig profile using the wcrtprf command.
Set event and distribution options using use wsetglobalinv command.
Set hardware scan options using the wsetinvunixhw command.
Set software scan options using the wsetinvunixsw command.
Optionally use the wsetinvunixfiles command to add/modify scanning
behavior.
5.3.2 Hardware scanning
Use the following steps to create a profile for HW scanning.
1. To create an InventoryConfig profile for scanning hardware of the endpoints in
the Outlet Systems Management Solution, use the commands shown in
Example 5-5 on page 275.
274
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Example 5-5 Creating inventory hardware scanning profile
export profname=hubtmr-region_MASTER_INV_HW
export prof=@InventoryConfig:$profname
wcrtprf @ProfileManager:hubtmr-region_MASTER_PM_INV InventoryConfig $profname
wsetinvglobal -l TEC -u REPLACE $prof
wsetinvunixhw -t Y -u Y $prof
wsetinvunixsw -p NO $prof
wsetinvpchw -t N -u N $prof
wsetinvpcsw -r NO $prof
2. The above example uses default values for the hardware scan. you might
want to apply specific customization through the wsetinvunix command in
order to speed up processing or add additional information of your choice.
3. To test the newly created InvontoryConfig profile, use the wdistinv command
and record the distribution ID. In Example 5-6 the distribution id is 389.
Example 5-6 distributing an InventoryConfig profile
wdistinv @InventoryConfig:hubtmr-region_MASTER_INV_HW @Endpoint:dev01-ep
Distribution ID: 1393424439.389
Scan ID: 62
4. Now use the wmdist command to determine if the scan has completed, as in
Example 5-7.
Example 5-7 Using wmdist to determine the status of a distribution
hubtmr:/ # wmdist -l -i 389
Name
Distribution ID Targets Completed Successful Failed
hubtmr-region_MASTER_INV_HW 1393424439.389 1
1(100%)
1(100%)
0( 0%)
5. Finally, to see the results of the scan, use the wqueryinv command as shown
in Example 5-8:
Example 5-8 Viewing scan results through wqueryinv
hubtmr:/ # wqueryinv -d "
" dev01-ep
Query Name: INVENTORY_HWARE
TME_OBJECT_LABEL
TME_OBJECT_ID
COMPUTER_SYS_ID
COMPUTER_SCANTIME
COMPUTER_MODEL
COMPUTER_ALIAS
SYS_SER_NUM
OS_NAME
OS_TYPE
Chapter 5. Creating profiles, packages, and tasks
275
PROCESSOR_MODEL
PROCESSOR_SPEED
PHYSICAL_TOTAL_KB
PHYSICAL_FREE_KB
TOTAL_PAGES
FREE_PAGES
PAGE_SIZE
VIRT_TOTAL_KB
VIRT_FREE_KB
dev01-ep
1393424439.29.522+#TMF_Endpoint::Endpoint#
D54DE1FC-1DD1-11B2-A431-F38473C2E1D8
2005-02-07 15:42:33.000000
VMware, Inc. VMware Virtual Platform
dev01
VMware-56 4d 66 f3 c9 b7 c7 25-5
UnitedLinux 1.0 (i586) VERSION = 1.0 PATCHLEVEL = 3
LINUX
Pentium 4
3000
514804
156492
125
38
4096
1036152
1036152
5.3.3 System software scan
To create the software scan profile, perform the following tasks:
1. Similar to creating InventoryConfig profiles for hardware scanning, create the
profile for scanning for default software using the commands shown in
Example 5-9.
Example 5-9 Creating profiles for software scanning
export profname=hubtmr-region_MASTER_INV_SW
export prof=@InventoryConfig:$profname
wcrtprf @ProfileManager:hubtmr-region_MASTER_PM_INV InventoryConfig $profname
wsetinvglobal -l TEC -u REPLACE $prof
wsetinvunixhw -t N -u N $prof
wsetinvunixsw -p BOTH $prof
2. To see the results of the scan, use the wqueryinv command as shown in
Example 5-10:
276
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Example 5-10 Operating System information from Inventory
hubtmr:/ # wqueryinv -d "
Query Name: OS_QUERY
" -q @OS_QUERY dev01-ep
TME_OBJECT_LABEL
TME_OBJECT_ID
COMPUTER_SYS_ID
OS_NAME
OS_TYPE
OS_MAJOR_VERS
OS_MINOR_VERS
OS_SUB_VERS
OS_INST_DATE
dev01-ep
1393424439.29.522+#TMF_Endpoint::Endpoint#
D54DE1FC-1DD1-11B2-A431-F38473C2E1D8
UnitedLinux 1.0 (i586) VERSION = 1.0 PATCHLEVEL = 3
LINUX
2
4
21-251-default
5.3.4 Custom scan
If you want to create a custom scan profile, it is similar to creating
InventoryConfig profiles for hardware and software scanning.
1. Create the profile for custom scanning using the commands shown in
Example 5-11.
Example 5-11 Creating custom profiles for software scanning
export profname=hubtmr-region_MASTER_INV_CUSTOM
export prof=@InventoryConfig:$profname
wcrtprf @ProfileManager:hubtmr-region_MASTER_PM_INV InventoryConfig $profname
wsetinvglobal -l TEC -u REPLACE $prof
wsetinvunixhw -t N -u N $prof
wsetinvunixsw -s BOTH -p NO -x N $prof
wsetinvunixfiles -e -t EXCLUDE -d +"*/tmp" $prof
2. When scanning for signatures, remember to load the default signatures as
described in “Loading signatures file for software scan” on page 242.
Optionally, add your own using the winvsig -a command.
Example 5-12 on page 278 shows the standard output, slightly reformatted,
from a software signature scan performed on a pristine UnitedLinux system.
Chapter 5. Creating profiles, packages, and tasks
277
Example 5-12 Signature scanning of pristine system
hubtmr:/ # wqueryinv -s dev01-ep
Query Name: INVENTORY_SWARE
TME_OBJECT_LABEL
TME_OBJECT_ID
COMPUTER_SYS_ID
SWARE_DESC
SWARE_VERS
SWARE_NAME
SWARE_SIZE
RECORD_TIME
dev01-ep
1393424439.29.522+#TMF_Endpoint::Endpoint#
D54DE1FC-1DD1-11B2-A431-F38473C2E1D8
Java Support
5.2.0.2
profdb
612
2005-02-07 21:10:31.173377
dev01-ep
1393424439.29.522+#TMF_Endpoint::Endpoint#
D54DE1FC-1DD1-11B2-A431-F38473C2E1D8
VERITAS Perl for VRTSvcs
1.1.1
extralibs.ld
1
2005-02-07 21:10:31.175888
dev01-ep
1393424439.29.522+#TMF_Endpoint::Endpoint#
D54DE1FC-1DD1-11B2-A431-F38473C2E1D8
OrbixOTM
1.0c
README
784
2005-02-07 21:10:31.183458
dev01-ep
1393424439.29.522+#TMF_Endpoint::Endpoint#
D54DE1FC-1DD1-11B2-A431-F38473C2E1D8
HP OpenView OmniBack II Cell Server
A.03.10
README
2962
2005-02-07 21:10:31.184393
dev01-ep
1393424439.29.522+#TMF_Endpoint::Endpoint#
D54DE1FC-1DD1-11B2-A431-F38473C2E1D8
OrbixOTM
1.0c
278
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
README
1143
2005-02-07 21:10:31.185708
dev01-ep
1393424439.29.522+#TMF_Endpoint::Endpoint#
D54DE1FC-1DD1-11B2-A431-F38473C2E1D8
Network Computing System 1.5.1
4.3.3.0
VERSION
21
2005-02-07 21:10:31.193596
3. To verify that the expected events have been send to TEC, go to the tec
system, and issue the wtdumprl command. At the bottom of the list, you will
see messages similar to Example 5-13.
Example 5-13 Inventory scan events forwarded to TEC
1~1443~65537~1107833205(Feb 07 21:26:45 2005)
### EVENT ###
Inv_Dist_Start;scan_id=69;ip_name="hubtmr-region_MASTER_INV_CUSTOM";dist_start_
time="Mon Feb 7 20:27:14 2005";num_targets=1;END
### END EVENT ###
PROCESSED
1~1444~65537~1107833321(Feb 07 21:28:41 2005)
### EVENT ###
Inv_Dist_Complete;scan_id=69;ip_name="hubtmr-region_MASTER_INV_CUSTOM";dist_ela
psed_time="0 Days 0 Hours 1 Minutes 55
Seconds";number_success=1;number_failed=0;END
### END EVENT ###
PROCESSED
Notice that the scan_id which is reported by the wdistinv command also
appears in the event information.
5.3.5 Defining OS and HW Monitoring Profiles
Monitoring the use and performance of operating system (OS) and hardware
resources on the endpoints require setting up one or more IBM Tivoli Monitoring
profiles, also known as Tmw2kProfiles.
The executables that implement the OS and HW monitoring capabilities are
based on Java. Before distributing any Tmw2kProfile, each endpoint needs to
have the proper level of the Java Runtime Environment (JRE) linked to the
endpoint itself. How to do this is discussed in “Linking endpoints to a JRE” on
page 280.
Chapter 5. Creating profiles, packages, and tasks
279
Next we define the specific monitors that collectively implement the monitoring
policies of Outlet Systems Management Solution. This is discussed in “Creating
a profile for monitoring system resources” on page 281. Finally, when the
prerequisites are in place, we can implement the monitoring policies by
distributing the Tmw2kProfile to the endpoints to which it applies. as shown in
“Distributing the monitoring profile” on page 288.
Linking endpoints to a JRE
Various components of IBM Tivoli Monitoring require Java Runtime Environment
(JRE), Version 1.3.x. For the Outlet Systems Management Solution, this JRE is
installed by default on all the systems that will be introduced into the environment
in the /usr/lib/java directory.
Because the correct JRE is already installed, we need to link the JRE to the IBM
Tivoli Monitoring engine at each endpoint using the DMLinkJre task from the IBM
Tivoli Monitoring Tasks task library. We can assume that all the instances have
JRE installed in the same location, therefore we can use a general command:
wruntask -t DMLinkJre -l "IBM Tivoli Monitoring Tasks" -h srchost-ep -a
"/usr/lib/java" -m 120
Your output from this task will be similar to what is shown in Example 5-14:
Example 5-14 Linking Jre using the DMLinkJre task
hubtmr:/ # wruntask -t DMLinkJre -l "IBM Tivoli Monitoring Tasks" -h dev01-ep
-a "/usr/lib/java" -m 120
############################################################################
Task Name:
DMLinkJre
Task Endpoint: dev01-ep (Endpoint)
Return Code:
0
------Standard Output-----****************************************************************
java version "1.3.1_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_04-b02)
Java HotSpot(TM) Client VM (build 1.3.1_04-b02, mixed mode)
****************************************************************
JRE is correctly installed.
JRE is a suitable version.
The JRE has been successfully linked.
------Standard Error Output-----Warning: Uncertified JRE build version
############################################################################
As an alternative. especially if JRE has not been installed, you can use the
wdmdistrib –J command. For information about this command, see the Tivoli
Management Framework Reference Manual.
280
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
For additional information, refer to “Linking to an existing Java Runtime
Environment” in IBM Tivoli Monitoring for Web Infrastructure - Installation and
Setup Guide Version 5.1.2, SH19-4569-03.
Creating a profile for monitoring system resources
Now that the prerequisites for the IBM Tivoli Monitoring engine has been
established on out test endpoint, we have to define which resources to monitor,
and how to monitor them. In the Outlet Systems Management Solution we will
use the best practices provided as defaults for the following resource types:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
CPU
FileSystem
Memory
NetworkInterface
PhysicalDisk
Process
Security
1. To create a Tmw2kProfile to monitor these resources, use the GUI or
commands from the command line, similar to the ones shown in
Example 5-15.
Example 5-15 Creating a Tmw2kProfile from the commandline
export profname=hubtmr-region_MASTER_ITM_linux-ix86
export prof=@Tmw2kProfile:$profname
wcrtprf @ProfileManager:hubtmr-region_MASTER_PM_ITM Tmw2kProfile $profname
wdmeditprf -P $profname -add DMXCpu
wdmeditprf -P $profname -add DMXFileSystem -AddPar
FileSystemsToMonitorDiffThres '/dev/sda2 | - | 85 | 1000 | - | 15'
wdmeditprf -P $profname -add DMXMemory
wdmeditprf -P $profname -add DMXNetworkInterface
wdmeditprf -P $profname -add DMXPhysicalDisk
wdmeditprf -P $profname -add DMXProcess
wdmeditprf -P $profname -add DMXSecurity
wdmeditprf -P $profname -Tec broadcast -S EventServer#hubtmr-region -TBSM no
# Set default push parameters for Tmw2kProfile to all levels
TMW2KOID=`wlookup -or Tmw2kProfile $profname`
idlcall $TMW2KOID _set_default_push_params '{ force_all FALSE }'
In Example 5-15, we used defaults for all the added resource models except
the DMXFileSystem. For this resource model, we added a special threshold
for the /dev/sda2 file system, allowing this file system to become 85% used
instead of the default 80%. In addition, we monitored for the existence of
1000kB or more than 15% free space.
Chapter 5. Creating profiles, packages, and tasks
281
The last wdmeditprf line in Example 5-15 is used to tell the monitoring profile
which types of events to generate, and where to send them. In this case we
forward events to the TEC server at in the hubtmr-region. Event forwarding to
TBSM is disabled.
Finally, in the last two lines shown in Example 5-15 on page 281 we set the
distribution defaults for the profile to automatically send the profile to all levels
of subscribers and overwrite any local modifications at any subscriber level.
2. To verify the settings in the newly created monitoring profile, you can use the
wdmeditprf -P <profilename> -list and wdmeditprf -P <profilename>
-print <resourcemodel> <property> commands. These were used to create
the listing presented in Example 5-16.
Example 5-16 hubtmr-region_MASTER_ITM_linux-ix86 monitoring profile details
Resource Model
Enable
DMXCpu
DMXFileSystem
DMXMemory
DMXNetworkInterface
DMXPhysicalDisk
DMXProcess
DMXSecurity
YES
YES
YES
YES
YES
YES
YES
DMXCpu
Cycle Time (sec):60
Tasks:
Low_IdleCPUUsage
High_SysCPUUsage
Data Logging Settings:
Enable
Aggregate Data
Aggregation Period
Minimum
Maximum
Average
Historical Period
NO
YES
15
NO
NO
YES
720
Parameters:
None
Schedule:
Scheduled Always
282
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Schedule Rules :
None
Thresholds:
Threshold Name
IdleCPUTimeThr
SysCPUTimeThr
Send TEC Settings
Send TEC Events
Mode:
Event Server(s)
Send TBSM:134897824
Threshold Value%
10.000000
%
80.000000
%
YES
BroadCast
EventServer#hubtmr-region
DMXFileSystem
Cycle Time (sec):120
Tasks:
LowKAvail
LowPercSpcAvail
FragmentedFileSystem
LowPercInodesAvail
Data Logging Settings:
Enable
Aggregate Data
Aggregation Period
Minimum
Maximum
Average
Historical Period
NO
YES
15
NO
NO
YES
720
Parameters:
IgnoredFileSystems:None
FileSystemsToMonitorDiffThres:/dev/sda2 | - | 85 | 1000 | - | 15
Schedule:
Scheduled Always
Schedule Rules :
None
Thresholds:
Threshold Name
PrcUsedInodes
PrcAvailKspace
Threshold Value%
80.000000
%
15.000000
%
Chapter 5. Creating profiles, packages, and tasks
283
PrcUsedKspace
AvailableSpace
PrcAvailInodes
Send TEC Settings
Send TEC Events
Mode:
Event Server(s)
Send TBSM:134897824
85.000000
7000.000000
20.000000
%
%
%
YES
BroadCast
EventServer#hubtmr-region
DMXMemory
Cycle Time (sec):60
Tasks:
LowStorage
Thrashing
LowSwap
Data Logging Settings:
Enable
Aggregate Data
Aggregation Period
Minimum
Maximum
Average
Historical Period
NO
YES
15
NO
NO
YES
720
Parameters:
None
Schedule:
Scheduled Always
Schedule Rules :
None
Thresholds:
Threshold Name
AvailVirtualStorage
SwapSpacePrc
PageOutRate
PageInRate
Send TEC Settings
Send TEC Events
Mode:
Event Server(s)
Send TBSM:134897824
284
Threshold Value%
40.000000
%
30.000000
%
400.000000
%
400.000000
%
YES
BroadCast
EventServer#hubtmr-region
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
DMXNetworkInterface
Cycle Time (sec):150
Tasks:
HighOutErrorPacks
HighInputErrPacks
InterfaceNotEnabled
HighPacktsCollision
InterfaceNotOperat
IntStatUnknown
Data Logging Settings:
Enable
Aggregate Data
Aggregation Period
Minimum
Maximum
Average
Historical Period
NO
YES
15
NO
NO
YES
720
Parameters:
communityName:public
Schedule:
Scheduled Always
Schedule Rules :
None
Thresholds:
Threshold Name
PercPacketCollisionThr
PercOutPacketErrThr
PercInPacketErrThr
Send TEC Settings
Send TEC Events
Mode:
Event Server(s)
Send TBSM:134897824
Threshold Value%
10.000000
%
10.000000
%
20.000000
%
YES
BroadCast
EventServer#hubtmr-region
DMXPhysicalDisk
Cycle Time (sec):120
Tasks:
HighPhysicalDiskReadBytes
Chapter 5. Creating profiles, packages, and tasks
285
HighPhysicalDiskWriteBytes
HighPhysicalPercentDiskTime
HighPhysicalDiskXferRate
Data Logging Settings:
Enable
Aggregate Data
Aggregation Period
Minimum
Maximum
Average
Historical Period
NO
YES
15
NO
NO
YES
720
Parameters:
None
Schedule:
Scheduled Always
Schedule Rules :
None
Thresholds:
Threshold Name
HighDiskBytes
HighPercentUsage
Send TEC Settings
Send TEC Events
Mode:
Event Server(s)
Send TBSM:134897824
Threshold Value%
1572864.000000 %
90.000000
%
YES
BroadCast
EventServer#hubtmr-region
DMXProcess
Cycle Time (sec):60
Tasks:
ProcessKilledOrNotExisting
ProcessHighCPU
ProcessStopped
HighZombieProcesses
Data Logging Settings:
Enable
Aggregate Data
Aggregation Period
Minimum
Maximum
286
NO
YES
15
NO
NO
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Average
Historical Period
YES
720
Parameters:
processes:basename=lcfd
basename=syslogd
Schedule:
Scheduled Always
Schedule Rules :
None
Thresholds:
Threshold Name
HighZombieProcess
HighCPUUsed
Send TEC Settings
Send TEC Events
Mode:
Event Server(s)
Send TBSM:134897824
Threshold Value%
20.000000
%
60.000000
%
YES
BroadCast
EventServer#hubtmr-region
DMXSecurity
Cycle Time (sec):120
Tasks:
IllegalOwner
DuplicatedAccount
WrongMode
HighLoggingNumber
SuspectSuperGroup
NotRegularRootAccount
FileNotExisting
PasswdNull
SuspectSuperUser
IllegalGroup
Data Logging Settings:
Enable
Aggregate Data
Aggregation Period
Minimum
Maximum
Average
Historical Period
NO
YES
15
NO
NO
YES
720
Chapter 5. Creating profiles, packages, and tasks
287
Parameters:
AlternativeOwners:root
Superusers:root
AlternativeGroups:sys
security
Users: root | 10
FilesList:/etc/passwd | -rw-r--r-- | root | root
/etc/group | -rw-r--r-- | root | root
Supergroups:root
Schedule:
Scheduled Always
Schedule Rules :
None
Thresholds:
None
Send TEC Settings
Send TEC Events
Mode:
Event Server(s)
Send TBSM:134897824
YES
BroadCast
EventServer#hubtmr-region
Distributing the monitoring profile
To use the hubtmr-region_MASTER_ITM_linux-ix86 profile, we need to
subscribe the dev01-ep endpoint, or rather the profile manager
hubtmr-region_MASTER_PMS_linix-ix86 to which the endpoint subscribes, to
the hubtmr-region_MASTER_PM_ITM profile manager.
1. Use the wsub command as shown:
wsub @ProfileManager:hubtmr-region_MASTER_PM_ITM
@ProfileManager:hubtmr-region_MASTER_PMS_linux-ix86
2. Now we can distribute the profile:
wdmdistrib -p hubtmr-region_MASTER_ITM_linux-ix86 dev01-ep
3. To verify that the monitors are executing, choose one of two methods:
a. Use the wdmlseng command to generate output similar to what is shown in
Example 5-17.
Example 5-17 Monitoring engine listing
hubtmr:/ # wdmlseng -e dev01-ep -verbose
Forwarding the request to the endpoint:
288
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
dev01-ep
1393424439.29.522+#TMF_Endpoint::Endpoint#
The following profiles are running:
hubtmr-region_MASTER_ITM_linux-ix86#hubtmr-region
DMXCpu: Running
High_SysCPUUsage 100 %
Low_IdleCPUUsage 100 %
DMXFileSystem: Running
LowPercInodesAvail 100 %
LowPercSpcAvail 100 %
FragmentedFileSystem 100 %
LowKAvail 100 %
DMXMemory: Running
LowStorage 100 %
Thrashing 100 %
LowSwap 100 %
DMXNetworkInterface: Running
HighPacktsCollision 100 %
HighOutErrorPacks 100 %
HighInputErrPacks 100 %
InterfaceNotEnabled 100 %
InterfaceNotOperat 100 %
IntStatUnknown 100 %
DMXSecurity: Running
NotRegularRootAccount 100 %
PasswdNull 100 %
IllegalGroup 100 %
DuplicatedAccount 100 %
SuspectSuperUser 100 %
IllegalOwner 100 %
SuspectSuperGroup 100 %
HighLoggingNumber 100 %
FileNotExisting 100 %
WrongMode 100 %
DMXPhysicalDisk: Running
HighPhysicalPercentDiskTime 100 %
HighPhysicalDiskXferRate 100 %
HighPhysicalDiskWriteBytes 100 %
HighPhysicalDiskReadBytes 100 %
DMXProcess: Running
HighZombieProcesses 100 %
ProcessHighCPU 100 %
ProcessKilledOrNotExisting 100 %
ProcessStopped 100 %
Chapter 5. Creating profiles, packages, and tasks
289
b. Another way of verifying that the expected resource models are running is
to open the Web Health Console (http://console:9080/dmwhc). Look at
the details page for the dev01-ep endpoint, as in Figure 5-1.
Figure 5-1 Resource monitor status for endpoint dev01-ep
5.3.6 Defining TEC profiles
In order to deploy the TEC Logfile Adapter used by IBM Tivoli Monitoring for Web
Infrastructure, we need to define an Adapter Configuration Profile (ACP) to be
distributed to our endpoints.
Because we are not applying any customization to monitor specific logfiles at this
point, we will use the defaults as defined in the tecad_logfile_linux-ix86
configuration file delivered with the product. For more information about the
Adapter Configuration Profiles, refer to the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Enterprise Console → Adapters Guide.
Defining the ACP
For the Outlet Systems Management Solution, the ACP profile resides in the
hubtmr-region_MASTER_PM_TEC profile manager, and we named it
hubtmr-region_MASTER_ACP_linux-ix86. While you can use the GUI to create
290
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
the profile, we used commands to achieve the same goal, as shown in
Example 5-18.
Example 5-18 Defining the ACP profile
wcrtprf @ProfileManager:hubtmr-region_MASTER_PM_TEC ACP
hubtmr-region_MASTER_ACP_linux-ix86
# Add a logfile record
waddac tecad_logfile_linux-ix86 hubtmr-region_MASTER_ACP_linux-ix86
# Set default push parameters for ACP Profile to all levels
ACPOID=`wlookup -or ACP hubtmr-region_MASTER_ACP_linux-ix86`
idlcall $ACPOID _set_default_push_params '{ force_all FALSE }'
Distributing the ACP
To apply a monitoring policy to an endpoint, we have to subscribe the endpoint,
or the profile manager to which it subscribes, to the profile manager hosting the
profile.
1. Because the test system (dev01-ep) has already been subscribed to the
hubtmr-region_MASTER_PMS_linux-ix86 profile manager, we settle for
subscribing this profile manager to the hubtmr-region_MASTER_PM_TEC
profile manager hosting our ACP profile:
wsub @ProfileManager:hubtmr-region_MASTER_PM_TEC
@ProfileManager:hubtmr-region_MASTER_PMS_linux-ix86
2. And now we can distribute the ACP profile.
wdistrib -m @ACP:hubtmr-region_MASTER_ACP_linux-ix86 @Endpoint:dev01-ep
5.3.7 Building the software package for deploying DB2 Server
At this point we have established the dev01 test system, which is monitoring by
the basic operating system and hardware resources are being monitored, and
which availability is managed through the heartbeat function. It is now time to
apply components that will enable this system to perform some useful work - in
terms of hosting databases and applications.
The outlet servers in the Outlet Solution will host a WebSphere Application
Server based application that requires access to a local DB2 database, so we
have to develop a software package to install and customize the DB2 Server and
related components from a central site. Because all the prerequisite components
for installing DB2 is provided by the operating system, the only package to be
developed is for IBM DB2 UDB Server v8.2
In this section, we have assumed that you have downloaded all the software
images in the proper structure on the srchost system. Refer to Appendix B.,
Chapter 5. Creating profiles, packages, and tasks
291
“Obtaining the installation images” on page 645 for details on how and where to
get your copy.
In addition, all the software definitions, response files, scripts and so forth, are
available online. Refer to Appendix C, “Additional material” on page 655 for
details on how to get your machine-readable copies. For reference, we have also
included the files that makes up the software package for DB2 in A.7.7, “DB2
Server v8.2” on page 476 where you can find more details and descriptions of
the DB2 Server software package.
Before defining software packages, we need to make sure that the endpoints on
which we intent to install software components are subscribed to the
hubtmr-region_MASTER_PM_SWD profile manager. As previously shown, the
wsub command does the trick, and since we are still in testing mode, the only
profile manager that needs to be subscribed is
hubtmr-region_MASTER_PMS_linux-ix86.
wsub @ProfileManager:hubtmr-region_MASTER_PM_SWD
@ProfileManager:hubtmr-region_MASTER_PMS_linux-ix86
If you plan to use the software package definitions provided with this book, you
should perform the following setup steps:
1. Define your base directory for software distributions and scripts. We used the
following:
base directory
code directory
response file directory
log directory
tools and scripts
software packages
/mnt
/mnt/code
/mnt/rsp
/mnt/logs
/mnt/tools
/mnt/spd
2. Copy the do_it and java141_it scripts from the online material (see
Appendix C., “Additional material” on page 655) to your
<img_dir>/tools/common/UNIX directory. These two scripts are used by most
software packages.
The do_it script provides consistent logging of scripts and executables
launched from the software package, and java141_it is used to invoke
installation procedures which requires a Java2 environment. Note that we
have assumed that the package IBMJava2-141.rpm has been installed on all
target systems during basic operating system installation.
Listings of do_it and java141_it are available in the section “do_it” on
page 382 and “java141_it” on page 382 respectively.
292
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
IBM DB2 UDB Server v8.2
The first software component we install is IBM DB2 Server v8.2. To set up the
software package for installation and removal of the DB2 Server for Linux,
perform the following steps:
1. Download the installation archive C58S8ML-db2udbes82.tar to the
<img_dir>/code/db2/udb-ee/820/server/Linux-IX86 directory on the
srchost system.
2. Unpack the installation archive using
<img_dir>/code/db2/udb-ee/820/server/Linux-IX86 as the parent directory.
3. Copy the db2_install and db2_uninstall scripts from the
<img_dir>/code/db2/udb-ee/820/server/Linux-IX86/db2/linux directory to
the <img_dir>/tools/db2/udb-ee/820/server/Linux-IX86 directory.
4. Copy the custom scripts for installation and uninstallation:
– db2_server_820_addusers.sh
– db2_server_820_remusers.sh
Paste them to the <img_dir>/tools/db2/udb-ee/820/server/Linux-IX86
directory.
5. The scripts have been designed to create the required group and user to
enable monitoring. Review and modify the db2_server_820_addusers.sh and
db2_server_820_remusers.sh scripts to suit your requirements.
6. Copy or create the response file db2_server_820.rsp to your image server in
the <img_dir>/rsp/db2/udb-ee/820/server/Linux-IX86 directory.
Note: The response file used will not create a default instance in the newly
installed DB2 server.
Review the response file and adjust it to the particulars of your environment.
7. Copy or create the software package description file db2_server.8.2.0.spd to
your image server in the <img_dir>/spd/db2/udb-ee/820/server/Linux-IX86
directory.
8. Build and test the software package db2_server_820:
wimpspo -c hubtmr-region_MASTER_PM_SWD -f
@ManagedNode:<srchost>:<img_dir>/spd/db2/udb-ee/820/server/Linux-IX86/db2_s
erver.8.2.0.spd db2_server^8.2.0
9. Convert the software package to a software package block:
wconvspo -t build -o -p <img_dir>/code/tivoli/SPB/db2_server.8.2.0.spb
db2_server^8.2.0
10.Distribute the software package:
Chapter 5. Creating profiles, packages, and tasks
293
winstsp -f @SoftwarePackage:db2_server^8.2.0 @Endpoint:dev01-ep
To check the status of the distribution, you can use wmdist -e
<distributionId> to see how the package is transferred from the srchost to
the target.
11.Check the result of the distribution by looking in the logfile in
<img_dir>/logs/db2_server_820.log.
For listings of all the files used, except the installation image, refer to A.7.7, “DB2
Server v8.2” on page 476.
5.3.8 Creating a DB2 instance for the Outlet Solution
To facilitate a permanent data store for the Outlet Solution in the newly installed
DB2 system, we need to create an instance, a database, and the tables used by
the application.
For the Outlet Solution TimeCard application the database instance, the
databases, and tables needed to support the application should be created
ideally as part of the application deployment itself. However, the script used
within the software package for database manipulation can be invoked manually.
For testing purposes, use the script shown in “db2_store_cfg.sh” on page 615
along with the related file “Table.ddl” on page 618 to create a database instance
named db2inst1 on the dev01 system. This will allow us to develop and test
monitoring profiles for DB2.
5.3.9 Defining DB2 monitoring objects
This section outlines the tasks involved in defining the proxy-endpoint objects for
DB2 Instances and Databases.
Creating Tivoli DB2 objects
IBM Tivoli Monitoring for DB2 operates with two distinct types of objects, a
DB2InstanceManager object and a DB2DatabaseManager object. These are
both proxy-endpoints used to set the correct scope of operation for the
management operations.
Both object types will be created ultimately on the gateway supporting the
endpoint at which the database resides.
Important: Remember when subscribing endpoints to profile managers
containing profiles that includes DB2 resource models, the subscribers have
to be of the type DB2InstanceManager or DB2DatabaseManager.
294
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Both DB2 InstanceManager and DatabaseManager objects can be created
manually or through a discovery process. If you use the discovery method, the
databases and instances have to exist first. This is not the case if the manual
commandline method is used.
In the following sections, we present a few examples of manually defining DB2
objects for the store database in the db2inst1 instance on the dev01 system.
However, before we reach that point, we need to discuss the discovery process.
The DB2 Discovery object
You can use the DB2Discovery object to create automatically multiple
DB2InstanceManager objects. This enables administrators to create DB2
instances for all DB2 servers simultaneously.
Discovery searches specified endpoints for DB2 instances that are not already
managed. When an instance is encountered, the DB2 discovery process
automatically creates a DB2InstanceManager object. The DB2 discovery
process runs from within the policy region where the instance objects are added.
A default DB2Discovery object is automatically stored in the
DB2Manager-DefaultPolicyRegion upon installation of the IBM Tivoli Monitoring
for Databases:DB2 product. Therefore, the DB2Discovery object must be
created in the specific policy region where servers are to be discovered.
Note: To delete a DB2Discovery object, you must unsubscribe it from all
profile managers.
Creating DB2 instance objects manually
A DB2InstanceManager object is an instantiation of a specialized Tivoli object
representing a partitioned or non-partitioned database server. This section
describes how to create an instance of a DB2 database server object (DB2
Server object) on the Tivoli Desktop so that administrators can monitor server
activity and simplify redundant tasks.
Note: If you delete and then recreate a DB2 instance, you must delete and
recreate the corresponding DB2InstanceManager from the IBM Tivoli
Monitoring for Databases: DB2 product. If you delete a DB2InstanceManager
object, you must also unsubscribe the object from all profile managers to
which it is subscribed. In addition, when you delete a DB2InstanceManager
object, you also delete any child objects associated with the object.
DB2InstanceManager objects can be created manually, as shown in A.4.1,
“create_db2_instance_objects.sh” on page 371, or using the DB2Discovery
Chapter 5. Creating profiles, packages, and tasks
295
object which was created in the DB2 Servers policy region on the Tivoli Desktop
during installation. Refer to the redbook IBM Tivoli Monitoring for Databases:DB2
User’s Guide version 5.1.0, SC23-4726-00 for further details on using the
DB2Discovery object.
1. For creation of the DB2InstanceManager object representing the db2inst1
instance created on the dev01 system in the DB2 Database Servers policy
region, we used the following command:
wcdb2inst -l db2inst1@dev01 -e dev01-ep -i db2inst1 -p “DB2 Database
Servers#hubtmr-region”
2. Upon successful creation, we subscribe the newly created
DB2InstanceManager to the profile manager that will be the target of task
executions and monitoring profile distributions:
wsub @ProfileManager:DB2Manager-Instances#hubtmr-region
@DB2InstanceManager:db2inst1@dev01-ep
After the DB2 instance objects have been created, the DB2InstanceManager
icons should be displayed in the DB2 Database Servers policy region.
Verifying DB2InstanceManager objects
To verify the creation of the DB2InstanceManager object using the command
line, use the well-known wlookup command as in Example 5-19.
Example 5-19 DB2 Instance object creation verification with wlookup
hubtmr:~ # wlookup -ar DB2InstanceManager
db2inv@rdbms-ep
1393424439.1.1683#DB2InstanceManager#
db2mdist@rdbms-ep
1393424439.1.1685#DB2InstanceManager#
db2inst1@dev01-ep
1393424439.1.1898#DB2InstanceManager#
db2swd@rdbms-ep
1393424439.1.1684#DB2InstanceManager#
db2tec@rdbms-ep
1393424439.1.1682#DB2InstanceManager#
db2tmtp@rdbms-ep
1393424439.1.1686#DB2InstanceManager#
Creating DB2 database objects manually
This section describes how to create a DB2DatabaseManager object to allow
administrators to manage and run tasks on the DB2 databases from the Tivoli
Desktop.
To access and manage a DB2 database from the Tivoli Desktop, you must create
a DB2DatabaseManager object.
The DB2DatabaseManager object must be installed on a system for which an
DB2InstanceManager object has already been defined. When you create the
DB2DatabaseManager object, it becomes a database endpoint in the policy
296
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
region. Subscribe the endpoint to profiles in profile managers in the same way as
any other managed resource.
DB2DatabaseManager objects can be created manually, as exemplified in A.4.2,
“create_db2_database_objects.sh” on page 372, or with the GUI.
1. For the store database in the db2inst1 instance on dev01-ep, we used the
following command to create the database object in the Tivoli environment:
wcdb2dbs -l “store@db2inst1@dev01-ep” -i “db2inst1@dev01-ep” -d STORE -p
“DB2 Database Servers#hubtmr-region”
2. We subscribed the database to the profile manager DB2Manager-Databases:
wsub @ProfileManager:DB2Manager-Databases#hubtmr-region
@DB2DatabaseManager:store@db2inst1@dev01-ep
Verifying the DB2DatabaseManager object
After the DB2DatabaseManager object has been created, the
DB2DatabaseManager icons should be displayed in the DB2 Database Servers
Policy Region, and as subscribers in the DB2Manager-Databases profile
manager. You can also verify the creation using the wlookup -ar
DB2DatabaseManager command.
5.3.10 Creating the db2ecc user ID
As already mentioned, the db2ecc user ID must be created on each endpoint in
the Tivoli management region where DB2 resources will be managed and
monitored.
The db2ecc user ID needs to be in the primary operating system group defined
for the DB2InstanceManager as the SYSADM for each instance to be managed.
Tip: The current setting of the SYSADM DB2InstanceManager configuration
file can be checked from the command line by running the following
command:
db2 get dbm config
You will find a line in the output similar to this:
SYSADM group name
(SYSADM_GROUP) = DB2GRP1
The db2ecc user is created automatically during installation of the
db2_server^8.2.0 software package.
Chapter 5. Creating profiles, packages, and tasks
297
5.3.11 Creating profiles for Tivoli Monitoring for Databases
As part of the IBM Tivoli Monitoring for Databases:DB2 installation, a top-level
policy region called Monitoring for DB2 is created and linked to the root desktop.
It contains a number of resources that can be used to administer DB2 resources,
including another policy region, Db2 Database Servers, to provide a placeholder
for your database objects.
Once the DB2 objects DB2InstanceManager and DB2DatabaseManager have
been created, you must subscribe them to the proper profile managers to be able
to distribute profiles containing specific DB2 resource models to the two types of
DB2 objects.
You might want to create new profile managers to differentiate the
DB2InstanceManager objects and the DB2DatabaseManager objects within the
DB2 Database Servers policy region. Inside these, you can create one or more
Tmw2kProfiles, add the desired resource models, and distribute them to the DB2
objects.
In the Outlet Systems Management Solution, we chose to use the profile
managers DB2Managers-Instances and DB2Managers-Databases provided
during installation.
Monitoring profiles for DB2 monitoring are normal Tmw2kProfiles, and they are
manipulated accordingly. However, because different, logical endpoints are
considered the targets of the distributions, you should avoid mixing resource
models with different scopes in the same monitoring profile.
Note: Remember that the subscribers for DB2 profile managers must be DB2
objects and not endpoints. For example, if you create a Tmw2kProfile
containing resource models for database activities, the subscribers must be
DB2DatabaseManager objects.
Instance monitoring profiles
In the Outlet Systems Management Solution we chose, as a starting point, to use
the standard monitoring profile for DB2 Instances. The name of the default profile
provided with the ITM for DB2 installation, named DB2_instances, resides in the
DB2Managers-Instances profile manager.
1. Example 5-20 on page 299 shows the default content of the DB2_instances
profile. The information was generated using a combination of wdmeditprf
commands.
298
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Example 5-20 Default DB2-instances monitoring profile
Resource Model
DB2InstanceStatus
Enable
YES
DB2InstanceStatus
Parameters:
LoggedMetrics_Conn:
LoggedMetrics_Status:
numPctConnectionsExecuting
strCounterResetTimestamp
numdb2Status
Cycle Time (sec): 1800
Schedule:
Scheduled Always
Schedule Rules :
None
Thresholds:
Threshold Name
High_PctConnectionsExecuting
Threshold
75.000000
Value%
%
Indications :
Indications
Occurrences Holes SendTEC Send TBSM Severity Clearing
DB2_Down_Status
1
0
YES
YES
CRITICAL
YES
DB2_High_PctConnectionsExecuting
3
2
NO
NO
WARNING
NO
Tasks:
DB2_Down_Status
DB2_High_PctConnectionsExecuting
Data Logging Settings:
Enable
Aggregate Data
Aggregation Period
Minimum
Maximum
Average
Historical Period
Send TEC Settings
Send TEC Events
Mode:
Event Server(s)
NO
NO
15
NO
NO
YES
720
YES
BroadCast
EventServer#hubtmr-region
2. To distribute the DB2_instances profile to the db2inst1@dev01-ep
DB2InstanceManager endpoint, we used the following command:
Chapter 5. Creating profiles, packages, and tasks
299
wdmdistrib -p DB2_instances#hubtmr-region -M over_all_no_merge
@DB2InstanceManager:db2inst1@dev01-ep
Example 5-21 shows how the wdmlseng command was used to verify the
status of the monitoring.
Example 5-21 Active DB2 Instance monitors
hubtmr:~ # wdmlseng -e dev01-ep
Forwarding the request to the endpoint:
dev01-ep 1393424439.29.522+#TMF_Endpoint::Endpoint#
The following profiles are running:
hubtmr-region_MASTER_ITM_linux-ix86#hubtmr-region
DMXCpu: Running
DMXFileSystem: Running
DMXMemory: Running
DMXNetworkInterface: Running
DMXSecurity: Running
DMXPhysicalDisk: Running
DMXProcess: Running
[email protected]_instances.dup@DB2Manager-Instance#hubtmr-region
DB2InstanceStatus: Running
Database monitoring profiles
Similar to the instance monitoring, specific monitoring policies can be set up in
customized profiles for monitoring databases and database activity.
In the Outlet Systems Management Solution we used the default
DB2_databases profile found in the DB2Manager-Databases profile manager.
The content of the default profile is shown in Example 5-22.
Example 5-22 Default DB2-databases monitoring profile
Resource Model
DB2DatabaseStatus
DB2TableActivity
Enable
YES
YES
DB2DatabaseStatus
Parameters:
LoggedMetrics_DMS:
SMS_TbspNames_List:
LoggedMetrics_App:
TbspNames_List:
300
numPctSpaceUsedDMS
*
numPctConnectionsUsed
*
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
DMS_TbspNames_List:
LoggedMetrics_Status:
LoggedMetrics_Config:
LoggedMetrics_Tbsp:
LoggedMetrics_Gateway:
Cycle Time (sec):
600
Schedule:
Scheduled Always
Schedule Rules :
None
*
strLastBackupTimestamp
strRestorePending
numTableSpaceStatus
numCurrentConnections
numMostRecentConnectResponseTime
numConnectionErrors
numConnWaitingForHostCurrent
Thresholds:
Threshold Name
Old_LastBackupTimestamp
High_PctConnectionsUsed
High_ConnectionErrors
High_CurrentConnections
High_SpaceUsedDMSTablespace
High_SpaceUsedSMSTablespace
High_MostRecentConnectResponse
High_ConnWaitingForHost
Threshold
Value%
2.000000
%
80.000000
%
100.000000
%
50.000000
%
85.000000
%
50000000.000000%
5.000000
%
30.000000
%
Indications :
Indication
Occurrences Holes Send TEC Send TBSM Severity Clearing
DB2_High_CurrentConnections 3 2
NO
NO
WARNING
NO
DB2_High_SpaceUsedDMSTablespace
1 0 NO NO
CRITICAL YES
DB2_High_SpaceUsedSMSTablespace 1 0 NO NO CRITICAL YES
DB2_True_RestorePending 1 0 YES YES CRITICAL YES
DB2_High_ConnectionErrors 1 0 YES YES WARNING YES
DB2_High_MostRecentConnectResponse
3 2
YES YES
WARNING NO
DB2_High_ConnWaitingForHost
3 2 YES YES WARNING NO
DB2_Old_LastBackupTimestamp 2 0 NO NO CRITICAL NO
DB2_High_PctConnectionsUsed 3 1 YES YES WARNING YES
DB2_False_TablespaceNormalStatus 2 1 YES YES WARNING NO
Tasks:
DB2_High_CurrentConnections
DB2_High_SpaceUsedDMSTablespace
DB2_High_SpaceUsedSMSTablespace
DB2_True_RestorePending
DB2_High_ConnectionErrors
DB2_High_MostRecentConnectResponse
DB2_High_ConnWaitingForHost
DB2_Old_LastBackupTimestamp
Chapter 5. Creating profiles, packages, and tasks
301
DB2_High_PctConnectionsUsed
DB2_False_TablespaceNormalStatus
Data Logging Settings:
Enable
Aggregate Data
Aggregation Period
Minimum
Maximum
Average
Historical Period
NO
NO
15
NO
NO
YES
720
Send TEC Settings
Send TEC Events
Mode:
Event Server(s)
YES
BroadCast
EventServer#hubtmr-region
DB2TableActivity
Parameters:
TableNames_List:
LoggedMetrics:
NULL
numRowsReadRate
numRowsWrittenRate
*
SchemaNames_List:
Cycle Time (sec):
Schedule:
Scheduled Always
Schedule Rules :
1800
None
Thresholds:
None
Indications :
None
Tasks:
None
Data Logging Settings:
Enable
Aggregate Data
Aggregation Period
Minimum
Maximum
Average
Historical Period
302
NO
NO
15
NO
NO
YES
720
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Send TEC Settings
Send TEC Events
Mode:
Event Server(s)
YES
BroadCast
EventServer#hubtmr-region
To distribute the DB2_databasess profile to the store@db2inst1@dev01-ep
DB2DatabaseManager endpoint to start monitoring database availability and
performance, we used the following command:
wdmdistrib -p DB2_databases#hubtmr-region -M over_all_no_merge
@DB2DatabaseManager:store@db2inst1@dev01-ep
Example 5-21 shows how the wdmlseng command was used to verify the status
of the monitoring.
Example 5-23 Output from wdmlseng on database server endpoint
hubtmr:~ # wdmlseng -e dev01-ep
Forwarding the request to the endpoint:
dev01-ep 1393424439.29.522+#TMF_Endpoint::Endpoint#
The following profiles are running:
hubtmr-region_MASTER_ITM_linux-ix86#hubtmr-region
DMXCpu: Running
DMXFileSystem: Running
DMXMemory: Running
DMXNetworkInterface: Running
DMXSecurity: Running
DMXPhysicalDisk: Running
DMXProcess: Error
store@[email protected]_databases.dup@DB2Manager-Database#hubtmr-region
DB2TableActivity: Running
DB2DatabaseStatus: Running
[email protected]_instances.dup@DB2Manager-Instance#hubtmr-region
DB2InstanceStatus: Running
5.3.12 Deploying WebSphere Application Server
In the Outlet Systems Management Solution the systems in the outlets will host a
WebSphere application. For convenience, we will develop software packages to
install and customize WebSphere Application Server and related components
from a central site. The installation of WebSphere Application Server requires the
correct level of WebSphere Message Queuing, with the correct fixpacks
installed, and an existing IBM HTTP Server v2, - all of which we will install as a
Chapter 5. Creating profiles, packages, and tasks
303
separate packages. The software packages needed for deploying WebSphere
Application Server are:
򐂰
򐂰
򐂰
򐂰
򐂰
IBM HTTP Server v2.0.47
WebSphere Message Queuing Server V5.3
WebSphere Message Queuing Server V5.3 Fixpack 8
WebSphere Application Server v5.1
WebSphere Caching Proxy v5.1 Fixpack 1
In the following sections, it is assumed that all the software images have been
downloaded in the proper structure on the srchost system.
Refer to Appendix B, “Obtaining the installation images” on page 645 for details
on how and where to get your copy. In addition, all the software package
definitions, response files, scripts and so on are available online. Refer to
Appendix C, “Additional material” on page 655 for details on how to get your
machine-readable copies. For reference, we have also included all of these files
in Appendix A, “Configuration files and scripts” on page 349 where you can find
more details and descriptions of each software packages.
Before defining software packages, we need to make sure that the endpoints on
which we want to install software components are subscribed to the
hubtmr-region_MASTER_PM_SWD profile manager. As previously shown, the
wsub command does the trick. Because we are still in testing mode, the only
profile manager that needs to be subscribed is
hubtmr-region_MASTER_PMS_linux-ix86.
wsub @ProfileManager:hubtmr-region_MASTER_PM_SWD
@ProfileManager:hubtmr-region_MASTER_PMS_linux-ix86
If you plan to use the software package definitions provided with this book, you
should perform the following setup steps:
1. Define your base directory for software distributions and scripts. We used the
following directories:
base directory
code directory
response file directory
log directory
tools and scripts
software packages
/mnt
/mnt/code
/mnt/rsp
/mnt/logs
/mnt/tools
/mnt/spd
2. Copy the do_it and java141_it scripts from the online material (see
Appendix C, “Additional material” on page 655) to your
<img_dir>/tools/common/UNIX directory. These two scripts are used by most
software packages. the do_it script provides consistent logging of scripts and
executables launched from the software package. The java141_it is used to
304
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
invoke installation procedures such as the one for IBM HTTP Server which
requires a Java2 environment. Note that we have assumed that the package
IBMJava2-141.rpm has been installed on all target systems.
Listings of do_it and java141_it are available at “do_it” on page 382 and
“java141_it” on page 382 respectively.
IBM HTTP Server v2.0.47
The first software component we install is IBM HTTP Server v2.0.47. Because
we will not use the IBM HTTP Server v1.3 provided with WebSphere, the correct
level of the HTTP Server must be installed in order for the WebSphere
Application Server installation program to successfully generate the HTTP
plug-in.
To set up the software package for installation and removal of IBM HTTP Server
v2.0.47 for Linux, we performed the following steps:
1. Copy or create the software package description file ihs_server.2.0.47.spd
to your image server in the <img_dir>/spd/ibm/ihs/2047/all/Linux-IX86
directory.
2. Download the installation archive HTTPServer.linux.2047.tar to the
<img_dir>/code/ibm/ihs/2047/all/Linux-IX86 directory on the srchost
system.
3. Copy the custom scripts for installation and uninstallation:
– ihs_2047_linuxi386_install.sh
– ihs_2047_linuxi386_uninstall.sh
Paste them to the <img_dir>/tools/ibm/ihs/2047/all/Linux-IX86 directory.
4. Copy the ihs_server_2047.rsp response file to your image server in the
<img_dir>/rsp/ibm/ihs/2047/all/Linux-IX86 directory.
5. Build and test the software package ihs_server.2.0.47.
wimpspo -c hubtmr-region_MASTER_PM_SWD -f
@ManagedNode:<srchost>:<img_dir>/spd/ibm/ihs/2047/all/Linux-IX86/ihs_server
.2.0.47.spd ihs_server^2.0.27
6. Convert the software package to a software package block:
wconvspo -t build -o -p <img_dir>/code/tivoli/SPB/ihs_server.2.0.47.spb
ihs_server^2.0.47
7. Distribute the software package:
winstsp -f @SoftwarePackage:ihs_server^2.0.47 @Endpoint:dev01-ep
To check the status of the distribution, you use the wmdist -e
<distributionId> to see how the package is being transferred from the
srchost to the target.
Chapter 5. Creating profiles, packages, and tasks
305
8. Check the logfile in <img_dir>/logs/ihs_server_2047.log
For listings of all the files used, except the installation image, refer to A.7.2, “IBM
HTTP Server v2.0.47” on page 383.
WebSphere Message Queuing Server V5.3
Next, we install another prerequisite for WebSphere Application Server:
WebSphere Message Queuing Server v5.3. Even though the WebSphere
Application Server v5.1 installation includes the MQ component. Maintenance
and updates are made easier by installing this component as a standalone
product.
To use the software package for WebSphere Message Queuing v5.3 that we
used, perform the following steps:
1. Copy or create the software package description file mq_server.5.3.0.spd to
your image server in the
<img_dir>/spd/websphere/mq/530/server/Linux-IX86 directory.
2. Download the compressed installation image and place it in the
<img_dir>/code/websphere/mq/530/server/Linux-IX86 directory on the
srchost system with a name of C48UBML_WASMQ-Linux-5.3.0.2.tar.gz.
3. Copy the custom scripts for installation and uninstallation:
– mq_users.sh
– mq_server_53_install.sh
– mq_server_53_uninstall.sh
Paste them to the <img_dir>/tools/websphere/mq/530/server/Linux-IX86
directory.
The mq_users.sh script is used to create the required user and group on the
local system prior to installing WebSphere Message Queuing Server.
4. Build and test the software package mq_server^5.3.0
wimpspo -c hubtmr-region_MASTER_PM_SWD -f
@ManagedNode:<srchost>:<img_dir>/spd/websphere/mq/530/server/Linux-IX86/mq_
server.5.3.2.spd mq_server^5.3.0
5. Convert the software package to a software package block:
wconvspo -t build -o -p <img_dir>/code/tivoli/SPB/mq_server.5.3.0.spb
mq_server^5.3.0
6. Distribute the software package:
winstsp -f @SoftwarePackage:mq_server^5.3.0 @Endpoint:dev01-ep
To check the status of the distribution, you can use the wmdist -l -i
<distribution id> to see the status of the software package distribution.
306
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
7. Check the logfile in <img_dir>/logs/mq_server_530.log
For listings of all the files used, except the installation image, refer to A.7.3,
“WebSphere Message Queuing Server v5.3” on page 395.
WebSphere Message Queuing Server V5.3 Fixpack 8
To apply the latest necessary fixes to the WebSphere Message Queuing Server,
we also have to install Fixpack 8. A special software package has been
developed for this purpose.
To use the software package for WebSphere Message Queuing v5.3 fixpack 8,
perform the following steps:
1. Copy or create the software package description file
mq_server.5.3.0_fp8.spd to your image server in the
<img_dir>/spd/websphere/mq/530_fp6/server/Linux-IX86 directory.
2. Download the compressed installation image and place it in the
<img_dir>/code/websphere/mq/530_fp8/server/Linux-IX86 directory on the
srchost system with a name of WASMQ-CDS8-Linux-U497537.gskit.tar.gz.
3. Copy the custom scripts for installation and uninstallation:
– mq_server_538_install.sh
– mq_server_538_uninstall.sh
Paste them to <img_dir>/tools/websphere/mq/530_fp8/server/Linux-IX86.
4. Build and test the software package mq_server^5.3.0.
wimpspo -c hubtmr-region_MASTER_PM_SWD -f
@ManagedNode:<srchost>:<img_dir>/spd/websphere/mq/532/server/Linux-IX86/mq_
server.5.3.0_fp8.spd mq_server^5.3.0_fp8
5. Convert the software package to a software package block:
wconvspo -t build -o -p <img_dir>/code/tivoli/SPB/mq_server.5.3.0_fp8.spb
mq_server^5.3.0_fp8
6. Distribute the software package:
winstsp -f @SoftwarePackage:mq_server^5.3.0_fp8 @Endpoint:dev01-ep
To check the status of the distribution, you can use wmdist -l -i
<distribution id> to see the status of the software package distribution.
7. Check the logfile in <img_dir>/logs/mq_server_530_fp8.log.
For listings of all the files used, except the installation image, refer to A.7.4,
“WebSphere Message Queuing Server v5.3 Fixpack 8” on page 408.
Chapter 5. Creating profiles, packages, and tasks
307
WebSphere Application Server v5.1
Now we are finally ready to install WebSphere Application Server. The
prerequisite components are available, but in addition to the basic installation of
WebSphere Application Server, we have to apply customization to enable
performance metric monitoring. This will enable resource models for WebSphere
Application Server to receive data.
To use the software package for WebSphere Application Server v5.1 that we
used, you should perform the following steps:
1. Copy or create the software package description file was_server.5.1.0.spd
to your image server in the
<img_dir>/spd/websphere/was/510/appserver/Linux-IX86 directory.
2. Download the WebSphere Application Server v5.1 installation image for Linux
and place it in the
<img_dir>/code/websphere/was/510/appserver/Linux-IX86 directory on the
srchost system with a name of C53IPML-WAS-510-LinuxIX86.tar.
3. Copy the was_appserver_510.rsp response file to your image server in the
<img_dir>/rsp/websphere/was/510/appserver/Linux-IX86 directory.
4. Copy the custom scripts for installation and uninstallation:
–
–
–
–
was_appserver_510_install.sh
mod_was_server_JVM_process.sh
mod_was_pmirm_settings.sh
was_appserver_510_uninstall.sh
Past them to the
<img_dir>/tools/websphere/was/510/appserver/Linux-IX86 directory.
The mod_was...sh scripts are used to update the WebSphere APplication
Server configuration to enable monitoring by IBM Tivoli Monitoring for Web
Infrastructure. See “Preparing WebSphere Application Server for monitoring”
on page 312 for more details on the specifics of these settings.
5. Build and test the software package was_appserver^5.1.0.
wimpspo -c hubtmr-region_MASTER_PM_SWD -f
@ManagedNode:<srchost>:<img_dir>/spd/websphere/was/510/appserver/Linux-IX86
/was_server.5.1.0.spd was_appserver^5.1.0
6. Convert the software package to a software package block:
wconvspo -t build -o -p <img_dir>/code/tivoli/SPB/was_server.5.1.0.spb
was_appserver^5.1.0
7. Distribute the software package:
winstsp -f @SoftwarePackage:was_appserver^5.1.0 @Endpoint:dev01-ep
308
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
To check the status of the distribution, you can use the wmdist -l -i
<distribution id> to see the status of the software package distribution.
8. Check the logfile in <img_dir>/logs/was_appserver_510.log.
For listings of all the files used, except the installation image, please refer to
A.7.5, “WebSphere Application Server v5.1” on page 417.
WebSphere Application Server v5.1 Fixpack 1
The final software package that needs to be installed on our test system is the
WebSphere Application Server v5.1 fixpack1. Creation of the package follows
the normal procedure:
1. Copy or create the software package description file
was_server.5.1.0_fp1.spd to your image server in the
<img_dir>/spd/websphere/was/510_fp1/appserver/Linux-IX86 directory.
2. Download the compressed WebSphere Application Server v5.1 Fixpack 1
installation image for Linux and place it in the
<img_dir>/code/websphere/was/510_fp1/appserver/Linux-IX86 directory on
the srchost system with a name of was51_fp1_linux.tar.gz.
3. Build and test the software package was_appserver^5.1.0_fp1:
wimpspo -c hubtmr-region_MASTER_PM_SWD -f
@ManagedNode:<srchost>:<img_dir>/spd/websphere/was/510_fp1/appserver/LinuxIX86/was_server.5.1.0_fp1.spd was_appserver^5.1.0_fp1
4. Convert the software package to a software package block:
wconvspo -t build -o -p <img_dir>/code/tivoli/SPB/was_server.5.1.0_fp1.spb
was_appserver^5.1.0_fp1
5. Distribute the software package:
winstsp -f @SoftwarePackage:was_appserver^5.1.0_fp1 @Endpoint:dev01-ep
To check the status of the distribution, you can use the wmdist -l -i
<distribution id> to see the status of the software package distribution.
6. Check the logfile in <img_dir>/logs/was_appserver_510_fp1.log.
For listings of all the files used, except the installation image, refer to A.7.6,
“WebSphere Application Server v5.1 Fixpack 1” on page 464.
WebSphere Caching Proxy v5.1
Now it’s time to install WebSphere Caching Proxy v5.1. The prerequisite
components are available, customization will be applied in the ibmproxy.conf file.
To use the software package that we used for WebSphere Caching Proxy v5.1,
perform the following steps:
Chapter 5. Creating profiles, packages, and tasks
309
1. Copy or create the software package description file
was_cachingproxy.5.1.0.spd to your image server in the
<img_dir>/spd/websphere/edge/510/cachingproxy/Linux-IX86 directory.
2. Download the WebSphere caching Proxy v5.1 installation image for Linux
and place it in the
<img_dir>/code/websphere/was/510/appserver/Linux-IX86 directory on the
srchost system with a name of EdgeComponents51-Linux.tar.
3. Copy the ibmproxy.conf configuration file to your image server in the
<img_dir>/rsp/websphere/edge/510/cachingproxy/Linux-IX86 directory.
4. Copy the custom scripts for installation and uninstallation:
– wses_51_cachingproxy_install.sh
– wses_51_cachingproxy_uninstall.sh
Paste them to the
<img_dir>/tools/websphere/edge/510/cachingproxy/Linux-IX86 directory.
5. Build and test the software package was_appserver^5.1.0:
wimpspo -c hubtmr-region_MASTER_PM_SWD -f
@ManagedNode:<srchost>:<img_dir>/spd/websphere/edge/510/cachingproxy/LinuxIX86/wses_cachingproxy.5.1.0.spd wses_cachingproxy^5.1.0
6. Convert the software package to a software package block:
wconvspo -t build -o -p
<img_dir>/code/tivoli/SPB/wses_cachingproxy.5.1.0.spb
wses_cachingproxy^5.1.0
7. Distribute the software package:
winstsp -f @SoftwarePackage:wses_cachingproxy^5.1.0 @Endpoint:dev01-ep
To check the status of the distribution, you use the wmdist -l -i
<distribution id> to see the status of the software package distribution.
8. Check the logfile in <img_dir>/logs/wses_cachingproxy_510.log
For listings of all the files used, except the installation image, please refer to
A.7.9, “WebSphere Caching Proxy v5.1” on page 503.
WebSphere Caching Proxy v5.1 Fixpack 1
The final software package that needs to be installed on our test system is the
WebSphere Caching Proxy v5.1 fixpack1. Creation of the package follows the
normal procedure:
1. Copy or create the software package description file
wses_cachingproxy.5.1.0_fp1.spd to your image server in the
<img_dir>/spd/websphere/edge/510_fp1/cachingproxy/Linux-IX86
directory.
310
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
2. Download the compressed WebSphere Caching Proxy v5.1 Fixpack 1
installation image for Linux and place it in the
<img_dir>/code/websphere/edge/510_fp1/cachingproxy/Linux-IX86
directory on the srchost system with a name of
EdgeCachingProxy511-Linux.tar.
3. Build and test the software package wses_cachingproxy^5.1.0_fp1:
wimpspo -c hubtmr-region_MASTER_PM_SWD -f
@ManagedNode:<srchost>:<img_dir>/spd/websphere/edge/510_fp1/cachingproxy/Li
nux-IX86/wses_cachingproxy.5.1.0_fp1.spd wses_cachingproxy^5.1.0_fp1
4. Convert the software package to a software package block:
wconvspo -t build -o -p
<img_dir>/code/tivoli/SPB/wses_cachingproxy.5.1.0_fp1.spb
wses_cachingproxy^5.1.0_fp1
5. Distribute the software package:
winstsp -f @SoftwarePackage:wses_cachingproxy^5.1.0_fp1 @Endpoint:dev01-ep
To check the status of the distribution, you use the wmdist -l -i
<distribution id> to see the status of the software package distribution.
6. Check the logfile in <img_dir>/logs/wses_cachingproxy_510_fp1.log.
For listings of all the files used - except the installation image - please refer to
A.7.10, “WebSphere Caching Proxy v5.1 Fixpack 1” on page 592.
5.3.13 Enabling WebSphere Application Server monitoring
Now that the WebSphere Application Server as well as the basic monitoring
engine has been established on the endpoint, it is time to discuss how we
monitor the WebSphere Application Server and related resources.
Because one WebSphere Application Server can host multiple logical application
server instances, we need to create unique instances of the
IWSApplicationServer object, which will be hosted on the gateway supporting the
WebSphere Application Server system. When distributing monitoring profiles, it
is important to use the IWSApplicationServer object as the target for the
distribution rather than the normal endpoint representing the system.
The steps necessary to facilitate monitoring of WebSphere Application Server
resources are:
1.
2.
3.
4.
“Preparing WebSphere Application Server for monitoring” on page 312
“Creating WebSphere Application Server Objects” on page 313
“Configuring the Tivoli Enterprise Adapter for local systems” on page 315
“Distributing Profiles” on page 315
Chapter 5. Creating profiles, packages, and tasks
311
Preparing WebSphere Application Server for monitoring
To allow the WebSphere resource models to receive performance and availability
metrics from the WebSphere Application server, the WebSphere Application
Server needs to be configured to gather and report these metrics.
Note: Observe, that this step has been incorporated in the
was_appserver^5.1.0 software package, using the scripted method described
in step 1 on page 313.
If performed manually, the following steps must be completed to configure the
local endpoints to support IBM Tivoli Monitoring for Web Infrastructure:
WebSphere Application Server:
1. Start the WebSphere Administrative Console in your browser. Use the
following url: http://localhost:9090/admin.
2. Expand Servers in the hierarchical tree in the left pane of the IBM
WebSphere Administrators console.
3. Click Application Servers.
4. Select the Application Server: server1.
5. Click Process Definition.
6. Click Java Virtual Machine.
7. Enter -XrunpmiJvmpiProfiler in the Generic JVM arguments field.
8. Click Apply.
9. Click OK.
10.Go back to the Configuration tab for the Application Server.
11.Click Performance Monitoring Service.
12.Select the Custom radio button in the Initial Specification level section.
13.Find jvmRuntimeModule in the list box and change it to jvmRuntimeModule=X.
14.Click Apply.
15.Click OK.
16.Expand the Troubleshooting section in the hierarchical navigation tree in the
pane to the left.
17.Click PMI Request Metrics.
18.Click the check box beside Enable in the Request Metrics field.
19.Click Save in the message at the top above General Properties.
20.Click Save in the Save to Master Configuration pane.
312
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
To apply the modifications to the WebSphere Application Server configuration
automatically, complete the following steps.
1. Run the mod_was_server_JVM_process.sh script (described in
“mod_was_server_JVM_process.sh” on page 458) to configure performance
metrics reporting.
A machine-readable version of this script can be obtained from the online
material accompanying this book. Refer to Appendix C, “Additional material”
on page 655 for details on how to obtain your copy.
2. Execute the mod_was_pmirm_settings.sh script shown in
“mod_was_pmirm_settings.sh” on page 459 to enable PMI reporting for your
WebSphere Application Server.
Note: No matter which way, manual or automated, the performance metrics
reporting has been enabled, the changes do not take effect until you restart
the application server. Start the application server, or restart it if it is currently
running.
Creating WebSphere Application Server Objects
The WebSphere Application Server object can be created in one of three ways:
򐂰 From the command line using the wwebsphere –CreateAppServer to creates
an IWSApplicationServer (IBM WebSphere Application Server Version 5 only)
object.
򐂰 Using the Tivoli Framework GUI
򐂰 Using the Discover_WebSphere_Resources task located in the WebSphere
Application Server Utility Tasks task library
Ultimately, any way will issue wwebsphere commands behind the scenes.
To create the IWSApplicationServer object for the logical server server1 hosted
by the WebSphere Application Server installed on the dev01 system, we used
the task invocation parameters shown in Example 5-24.
Example 5-24 Discover WebSphere Resources task invocation
hubtmr:/ # wruntask -t Discover_WebSphere_Resources -l "WebSphere Application
Server Utility Tasks" -h @ManagedNode:hubtmr -a “WebSphere Appliaction Servers”
-a /opt/IBM/WebSphere/AppServer -a dev01-ep -m 300 -o15
############################################################################
Task Name:
Discover_WebSphere_Resources
Task Endpoint: hubtmr (ManagedNode)
Return Code:
0
------Standard Output-----############################################################################
Chapter 5. Creating profiles, packages, and tasks
313
Return Code:
0
IZY1137I Creating policy region WebSphere Application Servers
IZY1138I The policy region already exists. No need to create it.
############################################################################
IZY1144I Discovering endpoint dev01-ep
############################################################################
Task Name:
Discover_endpoint
Task Endpoint: dev01-ep (Endpoint)
Return Code:
0
------Standard Output-----IZY1148I Creating application server AppSvr@dev01@dev01@server1
IZY1149I Adding AppSvr@dev01@dev01@server1 to IBM Tivoli Monitoring for Web
Infrastructure: WebSphere Application Servers application servers subscriber
list
IZY1150I Adding AppSvr@dev01@dev01@server1 to IBM Tivoli Monitoring for Web
Infrastructure: WebSphere Application Servers Application Servers With Servlets
subscriber list
IZY1002I Task complete
------Standard Error Output-----############################################################################
IZY1002I Task complete
------Standard Error Output-----############################################################################
For more details on the parameters for the Discover_WebSphere_Resources
task, visit the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Monitoring for Web Infrastructure → Reference Guide →
WebSphere Application Server Utility Tasks →
Discover_WebSphere_Resources.
The discovery task requires the WebSphere Application Server to be active. If
this causes a problem, as an alternative, you can create the
IWSApplicationServer object directly using the wwebsphere -CreateAppServer as
shown in A.5.1, “create_app_server.sh” on page 376.
Whether you create the IWSApplicationServer object manually or by using the
create_app_server.sh script, you might want to subscribe it to the default profile
managers used by the Discover WebSphere Resources task. The commands in
Example 5-25 on page 315 will complete this:
314
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Example 5-25 ISWApplicationServer objects and the default profile managers
wsub “@ProfileManager:WebSphere Application Servers#hubtmr-region”
@IWSApplicationServer:AppSvr@dev01@dev01@server1
wsub “@ProfileManager:WebSphere Application Servers With
Servlets#hubtmr-region” @IWSApplicationServer:AppSvr@dev01@dev01@server1
Configuring the Tivoli Enterprise Adapter for local systems
The Tivoli Enterprise Console adapter is used to ensure that general WebSphere
Application Server messages of types FATAL, ERROR, AUDIT, WARNING, and
TERMINATE are forwarded to the Tivoli Enterprise Console. The Tivoli
Enterprise Console adapter is also self-reporting; you can see the adapter status
events in your console.
We used the sample script, was_configure_tec_adapter.sh, shown in A.5.3,
“was_configure_tec_adapter.sh” on page 378 to install and configure the WAS
TEC Adapter using the Configure_WebSphere_TEC_Adapter task from the
WebSphere Event Tasks task library.
For more details on the parameters for the Configure_WebSphere_TEC_Adapter
task, visit the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Monitoring for Web Infrastructure → Reference Guide →
WebSphere Application Server Utility Tasks →
Configure_WebSphere_TEC_Adapter.
After configuring the TEC Adapter, it must be stopped and restarted. Sample
tasks, Stop_WebSphere_TEC_Adapter and Start_WebSphere_TEC_Adapter,
this are provided in the WebSphere Event Tasks task library. The sample scripts
was_start_tec_adapter.sh and was_stop_tec_adapter.sh are shown in A.5.4,
“was_start_tec_adapter.sh” on page 379. A.5.5, “was_stop_tec_adapter.sh” on
page 379 shows how to invoke these tasks automatically.
Distributing Profiles
As part of the IBM Tivoli Monitoring for Web Infrastructure: WebSphere
Application Server installation, a top-level policy region called Monitoring for
WebSphere Application Server is created and linked to the root desktop. It
contains a number of resources that can be used to administer WebSphere
resources.
Once the WebSphere Application Server IWSApplicationServer objects have
been created, you must distribute one or more profiles containing specific
WebSphere resource models to the IWSApplicationServer object.
Chapter 5. Creating profiles, packages, and tasks
315
Use the standard wdmdistrib command, but remember to specify the
IWSApplicationServer object as the target of the distribution.
To distribute the WebSphere Application Servers Profile provided with the IBM
Tivoli Monitoring for WI installation to the dev01 system, we used the following
command:
wdmdistrib -p "WebSphere Application Servers Profile#hubtmr-region"
-M over_all_no_merge @IWSApplicationServer:AppSvr@dev01@dev01@server1
Attention: If you distribute a Tmw2kProfile containing WebSphere Resource
Models to the wrong subscriber, such as a normal endpoint instead of an
IWSApplicationServer object, you will receive the following error message
when running wdmlseng -e EP_NAME:
WebSphereAS_Transactions_10: Unable to start (150)
To correct this problem, you must remove the profile from the endpoint using
the wdmeng command, then redistribute the profile to the correct targets.
If you failed to enable PMI Metrics gathering on the WebSphere Application
Server, you will receive the following error status when running the wdmlseng -e
<ep_name> command:
Example 5-26 wdmlseng - <ep_name>
WebSphereAS_Transactions_10: Failing (54)
WebSphereAS_JVMRuntime_10: Failing (54)
WebSphereAS_ApplicationServerStatus_10: Running
WebSphereAS_DBPools_10: Failing (54)
WebSphereAS_ThreadPool_10: Failing (54)
Refer to “Preparing WebSphere Application Server for monitoring” on page 312
for instructions on how to complete this task.
If the PMI Metrics gathering is configured correctly and you still encounter
problems, some of the attributes of the IWSApplicationServer object might be
incorrect, especially if you created the IWSApplicationServer object manually.
To recover, perform the following steps:
1. Remove the profile (wdmeng -e <endpoint> -p <profile> -delete).
2. Stop the engine (wdmcmd -stop -e <endpoint>).
3. Update/verify the IWSApplicationServer object attributes using this script:
$BINDIR/../generic_unix/TME/WSAPPSVR/tasks/itmwas_set_object_props.sh
316
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
4. Restart the engine (wdmcmd -restart -e <endpoint>).
5. Redistribute the profile (wdistrib -l over_all <profile>
<IWSApplicationServer object>).
5.3.14 Creating a software package for TimeCard Store Server
Now, we are ready to install the TimeCard application on the sample store server
system. Installation will allow us to test it and to create and develop packages for
transaction monitor deployment.
The application is a WebSphere application that uses its own, local database.
This database, as well as the instance that hosts it, will be created and
distributed as part of the package mentioned in 5.3.8, “Creating a DB2 instance
for the Outlet Solution” on page 294,
In addition to the jar file that contains the application code, a properties file also
has to be distributed to the target system.
To set up the software package for installation and removal of the TimeCard
application, copy files from the online material accompanying this book (see
Appendix C, “Additional material” on page 655) using the following steps:
1. Copy the installation files and directories from the
/mnt/code/outlet/TimeCard/510/all/generic directory to the
<img_dir>/code/outlet/TimeCard/510/all/generic directory on the srchost
system.
2. Copy the custom scripts for installation and uninstallation from the
/mnt/tools/outlet/TimeCard/510/all/generic directory to the
<img_dir>/tools/outlet/TimeCard/510/all/generic directory on the srchost
system.
3. Review and customize the scripts to suit your environment. The files are:
–
–
–
–
timecard_install.sh
db2_store_cfg.sh
Table.ddl
timecard_install.jacl
4. Copy or create the software package description file timecard.5.1.0.spd to
your image server in the <img_dir>/spd/outlet/TimeCard/510/all/generic
directory. The spd file we used can be found in
/mnt/spd/outlet/TimeCard/510/all/generic.
5. Build and test the software package timecard^5.1.0:
wimpspo -c hubtmr-region_MASTER_PM_SWD -f
@ManagedNode:<srchost>:<img_dir>/spd/outlet/TimeCard/510/all/generic/timeca
rd.5.1.0.spd timecard^5.1.0
Chapter 5. Creating profiles, packages, and tasks
317
6. Convert the software package to a software package block:
wconvspo -t build -o -p <img_dir>/code/tivoli/SPB/timecard.5.1.0.spb
timecard^5.1.0
7. Distribute the software package:
winstsp -f @SoftwarePackage:timecard^5.1.0 @Endpoint:dev01-ep
8. To check the status of the package distribution, you can use the wmdist -l -i
<distribution id> command.
5.3.15 Installing the TMTP Management Agent
It is recommended that the TMTP Management Agent be installed using a silent
installation. This will allow the deployment of large numbers of Management
Agents with minimal manual effort. The agent could also be deployed using the
manual installation method described in the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Monitoring for Transaction Performance → Installation and
Configuration Guide → Installing a management agent → Installing a
management agent.
Determining TMTP Management Agent locations
Table 4-19 on page 218 outlines which TMTP-related components to install and
where, in accordance with the functional roles of the systems described in
“Management environments” on page 131. The table shows that TMTP
management agents will be installed on the outletXX systems, the targets of the
monitoring. Naturally, the management agent code can also be installed on other
WebSphere Application Server systems, such as the Web Health Console, in the
event you want to monitor the transactions on this server.
Silent installation
To perform a silent installation of the TMTP Management Agent, edit the
provided response file MA.opt with the required settings for your environment
and run the following command from the directory containing the Agent
installation code:
./setup_MA_lin.bin -silent -is:javaconsole -is:silent -options path/MA.opt
A sample response file is provided in “MA.rsp” on page 502. Notice that a few of
the parameters have been commented out because they apply only to Windows
management agents.
318
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Note: You should be aware of the fact that during installation of the TMTP
Management Agent, the Agent attempts to register with the TMTP Server. If
the TMTP Server is not available, the Management Agent installation will fail.
To build your own software package for deployment of TMTP Agents in the
Outlet infrastructure, perform the following steps:
1. Download the TMTP v5.3 installation images, and copy the contents of the
Agents subdirectory of the CD image named IBM Tivoli Monitoring for
Transaction Performance, Version 5.3.0: Web Transaction Performance
Component Software Management Agent, Store and Forward installation
archive to the <img_dir>/code/tivoli/TMTP/530/agents/generic directory on
the srchost system, Refer to Appendix B, “Obtaining the installation images”
on page 645 for advice on how to obtain a copy of the TMTP v3 installation
images.
2. Create a response file for Agent installation, or copy the one provided in
/mnt/rsp/tivoli/TMTP/530/agents/generic/MA.rsp in the online material
accompanying this book. The location of the responsefile on your image
server (srchost) should be
<img_dir>/rsp/tivoli/TMTP/530/agents/generic/MA.rsp.
Review the response file and adjust to the particulars of your environment.
3. Copy or create the software package description file tmtp_agent.5.3.0.spd to
your image server in the <img_dir>/spd/tivoli/TMTP/530/agents/generic
directory.
4. Build and test the software package tmtp_agent_530:
wimpspo -c hubtmr-region_MASTER_PM_SWD -f
@ManagedNode:<srchost>:<img_dir>/spd/tivoli/TMTP/530/agents/generic/tmtp_ag
ent.5.3.0.spd tmtp_agent^5.3.0
5. Convert the software package to a software package block:
wconvspo -t build -o -p <img_dir>/code/tivoli/SPB/tmtp_agent.5.3.0.spb
tmtp_agent^5.3.0
6. Distribute the software package:
winstsp -f @SoftwarePackage:tmtp_agent^5.3.0 @Endpoint:dev01-ep
To check the status of the distribution, you can use the wmdist -e
<distributionId> to see how the package is transferred from the srchost to
the target.
7. Check the result of the distribution by looking in the logfile in
<img_dir>/logs/tmtp_agent_530.log.
Chapter 5. Creating profiles, packages, and tasks
319
For listings of all the files used, except the installation image, refer to A.7.8,
“TMTP Agent v5.3” on page 494.
Verifying the installation
To verify the installation and operation of the newly installed TMTP Management
Agent, perform the following steps:
1. Open the TMTP Console at https://tmtpsrv:9445/tmtpUI/.
2. Navigate to System Administration → Work with Agents and verify that the
newly installed management agents is online.
5.3.16 Configuring TMTP to monitor WebSphere
After the TMTP Management Agents have been deployed, it is necessary to
perform a number of configuration steps to enable the performance monitoring.
Many of these configuration steps can be performed from both the TMTP
Administrative Console, and the Command Line Interface. The CLI is very useful
for creating scripts to automatically configure new Management Agents as they
are deployed.
Where relevant in this section, we will show examples based on the TMTP CLI
installation on the hubtmr system, described in “Setting up the TMTP command
line interface” on page 220. Currently, the tmtpcli does not support a command
line interface for all operations. The location of the tmtpcli executable on the
hubtmr system is /opt/IBM/tivoli/tmtp_cli/cli/tmtpcli.sh.
Remember, that TMTP is not a TMF component, and that has its own
infrastructure. To facilitate transaction monitoring in the Outlet Systems
Management Solution it is necessary to create some basic objects, simmilar to
endpoints, profile managers, and monitoring profiles. To set up basic transaction
monitoring of the Outlet Solution, following tasks must be performed:
1.
2.
3.
4.
5.
6.
7.
“Deploying the J2EE component to the agent” on page 321
“Creating an Agent Group” on page 322
“Add agents to the Agent Group” on page 323
“Creating Schedules” on page 323
“Creating a policy group” on page 324
“Creating and deploying a discovery policy” on page 324
“Creating and deploying a listening policy” on page 325
All of these steps, except for steps 1 and 3, must be performed only once. In the
Outlet Systems Management Solution we will deploy the J2EE component to add
agents to agent groups upon successful installation of the TMTP Agent on each
outlet server. However, these steps are included here to allow for a smooth flow
of the description of the customization process.
320
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Before starting defining the basic TMTP objects, it is recommended that you
develop a naming standard for all TMTP objects. This allows for clear and easy
identification of a particular object’s scope and purpose. We suggest the
following:
<organization name>_<application name> | <short_description>_[<subtype of
object>]_<type of object>
Some sample object names are shown in Example 5-27.
Example 5-27 Sample TMTP object names
Outlet_TimeCard_J2EE_Discovery
Outlet_Always_J2EE_Schedule
Outlet_All-Outlet-Servers_Agent_Group
Outlet_TimeCard_J2EE-Servelet_Listening
Outlet_TimeCard_J2EE-EJB_Listening
Outlet_TimeCard_J2EE_PolicyGrup
In general, the names you use should be as self-explanatory as possible.
Deploying the J2EE component to the agent
TMTP allows you to deploy different monitoring components to endpoints to
facilitate speciailzed transaction monitoring. One of these components that
enables an agent to monitor transactions in WebSphere Applications is the J2EE
component. Before being able to activate monitoring, this component has to be
deployed to the TMTP Agent.
Note: In the production environment, this activity will be carried out
immediately after the successful installation of the TMTP Agent on the OutLet
servers.
The following steps describe how to deploy the J2EE Monitoring component,
either from the TiMTP Console or with the TMTP CLI:
򐂰 TMTP Administrative Console
a. Click System Administration → Work with Agents
b. Select the Agent to which the J2EE listenet is to be distributed to.
c. Select Deploy J2EE from the drop down list and click Go
򐂰 Command Line
– If WebSphere Security at the endpoint is not enabled
./tmtpcli.sh -DeployJ2ee -AgentName agentname -ServerType WebSphere
-Version 5.0 -ServerHome washome -ServerName websphere_appservername
-NodeName websphere_nodename -AutoRestart -Console
Chapter 5. Creating profiles, packages, and tasks
321
– If WebSphere Security is enabled
./tmtpcli.sh -DeployJ2ee -AgentName agentname -ServerType WebSphere
-Version 5.0 -ServerHome washome -ServerName websphere_appservername
-NodeName websphere_nodename -AutoRestart -IsSecure -AdminUserName
adminusername -AdminPassword adminpassword -Console
To deploy the J2EE component to the dev01.demo.tivoli.com TMTP agent
on the dev01 system, using a secure WebSphere Application Server, we
used the following command in Example 5-28:
Example 5-28 Deploying the J2EE component
./tmtpcli.sh -DeployJ2ee \
-AgentName dev01.demo.tivoli.com \
-ServerType WebSphere \
-Version 5.0 \
-ServerHome /opt/IBM/WebSphere/AppServer \
-ServerName server1 \
-NodeName dev01 \
-AutoRestart \
-IsSecure \
-AdminUserName root \
-AdminPassword smartway \
-Console
Creating an Agent Group
Agent groups are used to group agents into one logical group to which the
sample monitoring policies apply. This is very similar to the profile manager and
subscription schema of the Tivoli Framework.
Perform the following actions to create an agent group for the Outlet Servers
running the TimeCard application:
򐂰 From the TMTP Console:
a.
b.
c.
d.
Click Configuration → Work with Agent Groups → Create New
Enter a name and description for the new group.
Optional: You select the agents to subscribe to this group
Click Finish
򐂰 Using the TMTP Command Line Interface:
a. Use the tmtpcli -CreateAgentGroup command from the command line at
the hubtmr system to create a new agent group:
./tmtpcli.sh -CreateAgentGroup groupname -Agents
To create an agent group for the Outlet Systems Management Solution we
used the following command:
322
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
./tmtpcli.sh -CreateAgentGroup Outlet_TimeCard_Servers_AgentGroup
-Agents -Console
Note: The -Console option instructs the TMTP command line interface
to display the output on the console, in addition to storing it in the
default log.
Add agents to the Agent Group
For the purpose of discussing the TMTP customization process, we add the
dev01.demo.tivoli.com agent to the agent group at this point. In the Outlet
Solution production environment, this will be performed automatically upon
successful installation of the TMTP Agent on each Outlet Server.
The Agents can be added either through the Tivoli Console, or with the TMTP
command line interface:
򐂰 TMTP Console
a.
b.
c.
d.
Click Configuration → Work with Agent Groups
Select the agent group
Select Edit from the drop down list and click Go
Select the agents that should be members of this group and click Finish
򐂰 Command Line
a. Use the tmtpcli -AddToAgentGroup command from the command line of
the hubtmr system to add an agent to an agent group:
./tmtpcli.sh -AddToAgentGroup groupname -Agents agent1 agent2...agentn
-Console.
To add a new agent in the Outlet Systems Management Solution, we used
the following command:
./tmtpcli.sh -AddToAgentGroup Outlet_TimeCard_Servers_AgentGroup -Agents
dev01.demo.tivoli.com -Console
Creating Schedules
Schedules are used to determine when monitoring should be active, and, for
playback schedules especially, when to execute a simulated interaction with a
site.
To create schedules for the Outlet Solution, perform the following tasks:
1. Create a Schedule for the J2EE Policies.
a. Select Work with Schedules → Discovery or Listening from the drop
down list and click Create New.
Chapter 5. Creating profiles, packages, and tasks
323
b. Enter a name for the schedule, for example:
Outlet_Always_J2EE_Schedule
c. Accept the remaining defaults for start, stop and duration, and click OK.
Creating a policy group
Just as agent groups are used to group similar agents, policy groups are used to
group related policies that will be applied to agent groups simultaneously.
Follow these steps to create a policy group for the Outlet Solution:
1. Select Work with Policy Groups.
2. Click the Create New button.
3. Enter a name for the new policy group, for example:
Outlet_TimeCard_All_PolicyGroup
4. Select OK.
Creating policies
Now, all the basic constructs needed for creating and deploying policies are in
place.
J2EE monitoring policies, also known as listening policies, cannot be defined
until the basic transactions have been discovered. Therefore, to facilitate
monitoring of the J2EE TimeCard application, we need first to create a discovery
policy. After successful discovery, we can create the listening policy for the
specific transaction pattern.
The discovery process only has to be executed once for each specific
transaction. UIn the Outlet Solution case, we only have to perform one discovery
before deploying the listening policy to all the application servers in the Outlet
Solution.
Creating and deploying a discovery policy
This section outlines the steps required to create a discovery policy for the
TimeCard application.
To create a J2EE Servlet discovery policy, perform the following steps:
1. Select Work with Discovery Policies → J2EE Servlet from the drop down
list and click Create New
2. Supply the following values:
URI Filter
User Name
324
.*TimeCardWebProject/servlet/TimeCardServlet.*
.*
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Sample Rate
100 percent
Click Next.
Note: The parameters supplied are matched by a regular expression,
so the .* notations allows any number of characters before and after
the string specified. For the User Name field, we will discover
transaction from all users.
3. Choose the Outlet_TimeCard_Always_Schedule schedule created
previously and click Next.
4. Select the appropriate agent group , for example
Outlet_TimeCard_Servers_AgentGroup - and click Next.
5. Enter a name for this J2EE Servlet discovery policy, for example
Outlet_TimeCard_J2EEServlet_Discover.
6. Click Finish.
Creating and deploying a listening policy
To create a new listening policy, the discovery policy you created in the previous
section must have first discovered some transactions. To generate traffic to be
discovered, direct your browser to the newly installed TimeCard application.
Because the discovery policy has been defined in such a way that only URL
requests that include the string TimeCardWebProject/servlet/TimeCardServlet
will be discovered, you will need to access, for example:
http://dev01:9080/TimeCardWebProject/servlet/TimeCardServlet.
Wait approximately 15 minutes. The transaction history will have been uploaded
to the TMTP Server, and you can continue.
Meanwhile you might visit the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Monitoring for Transaction Performance → Administrator’s
Guide → →Monitoring transactions with discovery and listening policies to
obtain detailed information about listening policy creation.
The next step is to define the listening policy for the TimeCard application by
using the discovered transactions.
1. Click Work with Discovery Policies.
2. Select the applicable discover policy from the list on the right for example
Outlet_TimeCard_J2EEServlet_Discover.
Chapter 5. Creating profiles, packages, and tasks
325
3. Select View Discovered Transactions from the list and click Go.
You can see a list of discovered transactions similar to that in Figure 5-2.
Figure 5-2 Transactions discovered by discovery policy
4. Select the transaction for which you would like to create a listening policy.
Choose Create Listening Policy From from the list, and click Go.
5. Enter 20 in the Sample Rate field.
6. Select Aggregate and Instance.
7. Click Next.
8. Select Performance from the list, and click the Create button.
9. Enter the desired threshold data and select TEC in both Event Response
boxes, as shown in Figure 5-3 on page 327. Click Apply.
326
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Figure 5-3 Create J2EE Threshold
10.Click Configure J2EE Settings on the left side.
11.Click the check box beside the newly created J2EE threshold.
12.Under Advanced Listening Settings, select Low from the list beside
Choose Default Configuration.
Tip: Under normal circumstances, specify a Low configuration. Only when
you want to diagnose a performance problem should you increase the
configuration to Medium or High.
13.Click the Enable Intelligent Event Generation check box.
14.Enter 1 in the Time interval field.
15.Enter 1 in the Percentage Failed field.
16.Click Next.
17.Do not enter anything on the Configure ARM Settings screen, and click Next.
Chapter 5. Creating profiles, packages, and tasks
327
18.Choose the Outlet_TimeCard_Always_Schedule listening policy schedule,
created in “Creating Schedules” on page 323.
a. Select the Outlet_TimeCard_Servers_AgentGroup agent group, and
click Next.
b. Select the Outlet_TimeCard_All_PolicyGroup and click Next
c. Enter a name and description for this listening policy, for example:
d. Outlet_TimeCard_J2EE_Listen
e. Click Finish.
The listening profile will now be distributed to all the agents in the agent group,
and the transaction monitoring setup is complete.
328
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Part 3
Part
3
Putting the
solution to use
Until this point we have focused on installing and configuring the central
components of the Outlet Systems Management Solution that will enable Outlet
Inc. to manage their huge, widely distributed infrastructure.
In this section, we look closer at how the Outlet Systems Management Solution
benefits Outlet, Inc. The main topic is:
򐂰 Chapter 6, “Deployment” on page 331
© Copyright IBM Corp. 2005. All rights reserved.
329
330
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
6
Chapter 6.
Deployment
A few final tasks must be performed to allow for fully automated deployment of
software and monitoring profiles to the Outlet Servers. These tasks are:
1.
2.
3.
4.
5.
6.2, “Automating tasks” on page 333
6.3, “Creating the deployment activity plan” on page 335
6.4, “Defining the logical structure of the Outlet Inc. environment” on page 340
6.5, “Creating endpoint policies” on page 343
6.6, “Installing endpoints” on page 345
© Copyright IBM Corp. 2005. All rights reserved.
331
6.1 Automating deployment
The process that facilitates automatic deployment of software packages and
monitoring profiles is based on the endpoint policy support in the Tivoli
Management Framework. This allows for executing specialized scripts when the
endpoints log in, and provides support for handling the first login (initial login) as
a special case. Outlet Systems Management Solution will use those capabilities,
as shown in Figure 6-1.
Figure 6-1 The automated deployment process
The outline of the process is:
1. An endpoint is installed on the outlet server, and attempts login to the hubtmr
system (specified during installation).
2. The allow_login policy script is executed at the hubtmr, and uses the
<store>.lst files and the gateway.lst file to verify the eligibility of the endpoint
to log in.
3. The select_gateway policy script takes control, still at the hubtmr, in order to
identify the primary gateway for the endpoint. The gateway.lst file controls
this, and at the end, both the endpoint and the gateway are notified. The
endpoint logs off from the hubtmr.
332
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
4. The endpoint now attempts to log on to the assigned gateway, and the
login_policy script is executed.
5. The gateway realizes that this is the first successful login, and activates the
after_login policy script, which in the Outlet Systems Management Solution is
responsible for:
a.
b.
c.
d.
Subscribing the endpoint to the correct profile managers
Distributing hardware and software inventory scans
Distributing the basic operating system and hardware monitoring profile
Submitting an activity plan against the endpoint
6. The apm plan executes and installs software and monitoring capabilities on
the endpoint.
To implement this setup, all we need are , in addition to the bits and pieces
developed in Chapter 5, “Creating profiles, packages, and tasks” on page 271,
procedures/scripts for:
1.
2.
3.
4.
5.
6.
6.2, “Automating tasks”
6.3, “Creating the deployment activity plan” on page 335
6.4, “Defining the logical structure of the Outlet Inc. environment” on page 340
6.6, “Installing endpoints” on page 345
Apm plan invocation
6.5, “Creating endpoint policies” on page 343
6.2 Automating tasks
In the Outlet Systems Management Solution, we want to automate the manual
procedures related to distributing profiles to subscribing endpoints and described
in 5.3, “Creating monitoring profiles” on page 274.
Naturally, they could all be scripted and put into a huge script that could be
referenced from the after_login policy script. We chose another approach, by
imbedding the profile distributions in the APM plan to allow for flow-control, and
only distribute profiles for monitoring if the monitored component is installed
successfully. Because the activity plan can reference software packages as well
as tasks, all the monitoring profile distribution functions needed must be scripted,
then the scripts must be related to tasks.
For the Outlet Systems Management Solution the profile distribution scripts in
Table 6-1 on page 334 have been created:
Chapter 6. Deployment
333
Table 6-1 Profile distribution scripts
Script
Purpose
ep_customization.sh
Submits the APM plan against a specific
endpoint, for details, refer to A.8.1,
“ep_customization.sh” on page 628.
create_DB2_instance_objects
Creates a DB2 Instance object, code is
available in A.4.1,
“create_db2_instance_objects.sh” on
page 371.
itm_DB2_instance_rm_distrib
Distributes DB2 Instance-related
resource models, for details see A.4.3,
“itm_db2_instance_rm_distrib.sh” on
page 373.
create_DB2_database_objects
Creates a DB2 Database object, see
A.4.2, “create_db2_database_objects.sh”
on page 372 for details.
itm_DB2_database_rm_distrib
Distributes DB2 Database related
resource models, for details, see A.4.4,
“itm_db2_database_rm_distrib.sh” on
page 374.
itm_WAS_rm_distrib
Distributes WebSphere Application
Server related resource models, source
code is available in A.5.2,
“itm_was_rm_distrib.sh” on page 377.
Because it is efficient to automate the exchange of object definitions between the
hub- and spoke TMRs, the script update_TMR_Resources has been developed
as well. For details, refer to A.2.4, “update_resources.sh” on page 357.
To define the scripts as tasks in the TME environment, we created a task library
named Production_TL using the wcrttlib command. In the Outlet Systems
Management Solution, we created it in the hubtmr-region Policy Region using
the following command:
wcrttlib Production_TL huntmr-region
To create tasks within the task library, use the wsettask command. To ease the
job of creating all the required tasks, we developed and used the script described
in A.2.3, “load_tasks.sh” on page 356. Table 6-2 on page 335 outlines the tasks
created and their related scripts.
334
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Table 6-2 Production tasks and related scripts
Task
Script
ep_customization
ep_customization.sh
create_DB2_instance_objects
create_db2_instance_objects.sh
itm_DB2_instance_rm_distrib
itm_db2_instance_rm_distrib.sh
create_DB2_database_objects
create_db2_database_objects.sh
itm_DB2_database_rm_distrib
itm_db2_database_rm_distrib.sh
itm_WAS_rm_distrib
WAS/itm_was_rm_distrib.sh
update_TMR_Resources
update_resources.sh
update_Resources_from_SPOKE
update_resources.sh
Note: In a production environment, the update_TMR... tasks should be
scheduled to run periodically through the definition of a Tivoli job. Refer to the
wcrtjob and wschedjob commands for details on how to script the creation of
jobs.
6.3 Creating the deployment activity plan
At this point, our dev01 test system has all the software components required for
the Outlet Servers, and will now serve as our reference system.
The deployment plan that has to be build to distribute software packages and
monitoring profiles to the endpoints in the Outlet Systems Management Solution,
must reference both the software packages developed in Chapter 5., “Creating
profiles, packages, and tasks” on page 271 and the tasks for automated profile
distribution described in 6.2, “Automating tasks” on page 333.
6.3.1 Building the reference model
To create a basic plan, we start by creating a reference model that includes all
the software packages distributed to the dev01 system. The purpose of building
the reference model with Change Manager is to use this as the starting point for
building the final activity plan that eventually will be distributed to all new
endpoints from the after_install endpoint policy.
Unfortunately, Change Manager does not allow for command line-based
manipulation for all the functions available. As a result, to create a reference
Chapter 6. Deployment
335
model based on the dev01 system, we have to open the CCM GUI (using the
wccmguicommand from the hubtmr system) and create a new reference model
from there. The steps to do this are:
1. Start the CCM GUI from the hubtmr. Invoke the wccmgui command from a
command line.
2. Log in to CCM. Use the user ID root and the normal password.
3. Create a new reference model from a target. From the toolbar select File →
Create reference model from target.
4. Select the endpoint to be the source of the operation.
a.
b.
c.
d.
Set the Target Type to Endpoint.
Specify the name of the target. We used dev01-ep.
Check the Software box.
Press OK.
Now the dev01-ep system is being inspected, and the reference model is
build. At this point you can modify the model to fit your exact needs. Because
the dev01-ep system has the exact set of software components we need for
the Outlet Systems Management Solution, we did not make any
modifications.
5. To name the reference model, select Edit → Properties, and provide your
own name for the reference model. We used Outlet_RefModel_v1.
6. Before we can build the activity plan that will implement the reference model,
one or more targets must be applied. From the toolbar select Edit →
Subscribers → Add → Static subscriber. Specify the endpoints you want to
use. Because this plan is never executed against the selected endpoint, we
used srchost-ep.
7. Save the resulting reference model by selecting File → Export and provide a
name of the *.xml file to hold the exported version of the reference model.
8. Finally, we are ready to build an activity plan based on the newly generated
Reference Model. Select Activities → Submit, and provide a name for the
activity plan to be created. Do not check the Full synchronization check box,
but continue immediately by pressing OK.
9. When the activity plan dialog box is shown, select Import activity plan and
press OK.
10.Select File →Exit to close the CCM GUI.
More details regarding the use of the Change Manager are available at the Tivoli
Information Center Web site:
336
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Configuration Manager → User’s Guide for Deployment
Services → Using Change Manager.
6.3.2 Completing the activity plan
Having built the basic activity plan for all software to be distributed, we are ready
to assign conditions, targets and add additional activities to deploy monitoring
profiles as part of the plan.
The logical flow we want to implement in the activity plan is depicted in
Figure 6-2.
Figure 6-2 Activity flow for Outlet Server deployment
1. Like CCM, the Activity Planner component of Tivoli Configuration Manager
does not allow for all functions to be issued from the command line, so we
have to start the GUI in edit mode, using the wapmgui ed command from the
hubtmr system.
Chapter 6. Deployment
337
2. The logon process is similar to that of CCM, but the user ID to be specified
must be the tivapm user, was created during installation and described in
4.4.7, “Enabling the Activity Planner” on page 247.
3. To start working with the activity plan created from CCM, select File → Open
and select the recently imported plan.
The basic activity plan generated by CCM contains neither relationships nor
additional task activities, so we have to add these. For details on how to perform
this job, refer to the Tivoli Information Center Web site:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp
Navigate to Configuration Manager → User’s Guide for Deployment
Services → Using Activity Planner.
To customize the activity plan to meet the needs of the Outlet Systems
Management Solution the following tasks must be completed:
1. “Defining targets” on page 338
2. “Adding task activities” on page 338
3. “Setting conditions” on page 339
Defining targets
To ensure that the software package activities currently in the activity plan will be
issued against the correct target systems, set the target property of each activity
to $(TARGET_LIST). The TARGET_LIST variable is build on-the-fly when the plan is
submitted, thus guaranteeing that the activities will be issued against the correct
target, and not the srchost-ep we used to generate the plan.
Adding task activities
To include object discovery and monitoring profile distributions, we added the
following task activities, all referring the tasks we created in 6.2, “Automating
tasks” on page 333:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
Discover_WebSphere_Resources
ITM_WAS_AppSvr_RM_Distribution
Create_DB2_Instance_Objects
ITM_DB2_Database_RM_Distribution
Create_DB2_Database_Objects
ITM_DB2_Instance_RM_Distribution
The tasks all require different input parameters. Make sure that the correct
parameters are set up in the activity properties dialog.
338
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Tip: A variable such as $(EP) can be used to add the endpoint label
dynamically. The variable then has to be passed to the activity plan when
submitted. For example:
wsubpln -t $ep_label -f $plan_name -o -VEP=$ep_label -VMN=$TMR_NAME
Finally, to ensure that the task activities will be issued against the correct target,
set the targets of all the task activities to $(MN), at execution time it will be
translated to the value of the variable passed to the plan. Remember that the
tasks manipulate Tivoli objects and must be executed on the a managed node
Setting conditions
To ensure that the activities are performed in accordance with our planned
expectations, depicted in Figure 6-2 on page 337, we have to add conditions to
each activity.
To set conditions for an activity using the APM GUI, right-click the activity, and
select Conditions. A conditions property dialog is displayed, in which you can
define the desired conditions for the activity to be started. Table 6-3 outlines the
conditions we defined for the APM plan for deploying the Outlet Servers.
Table 6-3 APM plan activities and conditions
Activity
Condition
ihs_server^2.0.47#hubtmr-region[0]
ST(db2udb_server^8.2.0#hubtmr-region[0])
mq_server^5.3.0#hubtmr-region[0]
ST(ihs_server^2.0.47#hubtmr-region[0])
mq_server^5.3.0.fp8#hubtmr-region[0]
ST(mq_server^5.3.0#hubtmr-region[0])
was_appserver^5.1.0#hubtmr-region[0]
ST(mq_server^5.3.0_fp8#hubtmr-region[0])
was_appserver^5.1.0_fp1#hubtmr-region[0]
ST(was_appserver^5.1.0#hubtmr-region[0])
db2udb_server^8.2.0#hubtmr-region[0]
timecard^5.1.0#hubtmr-region[0]
ST(was_appserver^5.1.0_fp1#hubtmr-region[0])
AND ST(]db2udb_server^8.2.0#hubtmr-region[0])
wses_cachingproxy^5.1.0#hubtmr-region[0]
wses_cachingproxy^5.1.0_fp1#hubtmr-regio
n[0]
ST(wses_cachingproxy^5.1.0#hubtmr-region[0])
tmtp_agent^5.3.0#hubtmr-region[0]
Discover_WebSphere_Resources
SA(was_appserver^5.1.0_fp1#hubtmr-region[0])
Chapter 6. Deployment
339
Activity
Condition
ITM_WAS_AppSvr_RM_Distribution
SA(Discover_WebSphere_Resources)
Create_DB2_Instance_Objects
SA(timecard^5.1.0#hubtmr-region[0])
ITM_DB2_Database_RM_Distribution
SA(Create_DB2_Instance_Objects)
Create_DB2_Database_Objects
SA(Create_DB2_Instance_Objects)
ITM_DB2_Instance_RM_Distribution
SA(Create_DB2_Database_Objects)
If you want to work with the activity plan we created for the Outlet Systems
Management Solution, use File → Import, and select the file
Production_Outlet_Plan_v1.0.xml provided in the online material. A listing of
this file is available in A.8.2, “Production_Outlet_Plan_v1.0.xml” on page 629. As
an alternative to the GUI-based import operation, you can use the command line
option:
wimpln -e -f <xml file>
6.4 Defining the logical structure of the
Outlet Inc. environment
As we described in 3.3, “Logical Tivoli architecture for Outlet Inc.” on page 49, the
managed systems will be subscribed to profile managers that are organized in
hierarchies that allows targeting all systems with similar attributes usch as
location, architecture, applications in a single operation.
In addition, as we described in “Defining the logical structure of the environment”
on page 272, all master profiles are kept in the hubtmr environment to which
profile managers at the spoke TMRs will be subscribed. To allow for easy
assignment of authorities to manipulate the objects, each type of profile is kept in
a separate profile manager. Refer to “Defining the logical structure of the
environment” on page 272 for details about the master profile managers residing
in the hub- and spoketmr environments.
To provide a logical hierarchy in which to subscribe the outlet endpoints, it is
obvious that some kind of structure be established. This structure must allow for
targeting any operation - profile distribution, software update etc. - to groups of
identical servers throughout the Outlet Inc. environment.
To allow for this the following Policy Region structure should be created, as in
Example 6-1 on page 341.
340
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Example 6-1 Creating the Policy Region structure
<<REGION>
<TMR>-region_<REGION>_EP
<TMR>-region_<REGION>_PR
<TMR>-region_<REGION>_<STORE>_PR- one for each store
:At both the region and the store level, we will need profile managers to hold the
various profiles to be distributed with subscriptions to the similar profile manager
on the higher level, as in Figure 6-2.
Example 6-2 Distributing profiles to regions and stores
<[region
<[region
<[region
<[region
<[region
|
|
|
|
|
store]_policy_region_name>_PMS_linux-ix86
store]_policy_region_name>_PM_INV
store]_policy_region_name>_PM_TEC
store]_policy_region_name>_PM_ITM
store]_policy_region_name>_PM_SWD
In Example 6-2, <store_policy_region_name>_PMS_linux-ix86 is used to
subscribe endpoints. This profile manager subscribes, in turn, to all the other
store-level profile managers such as <store_policy_region_name>_INV.
To allow for central distribution of profiles, the profile managers will be arranged
in resource specific hierarchies, as shown in Example 6-3.
Example 6-3 Logical subscription hierarchy
hubtmr_region_MASTER_PM_INV
|
|
V
spoketmr_region_MASTER_PM_INV
|
V
spoketmr_region_<REGION>_PM_INV
|
V
spoketmr_region_<REGION>_<STORE>_PM_INV
|
|
V
spoketmr_region_<REGION>_<STORE>_PMS_linux-ix86
|
V
endpoints
Chapter 6. Deployment
341
Before creating the objects related to regions and stores, the TMR server to
which the region will belong must be prepared. This involves creating the
top-level, object-specific profile managers within the spoke TMR and subscribe
these to the hubtmr profile managers created in 5.1, “Defining the logical
structure of the environment” on page 272.
1. For each spoke TMR, issue the following commands in Example 6-4 to create
the profile managers:
Example 6-4 Creating profile managers
wcrtprfmgr <spoketmr>-region <spoketmr>-region_MASTER_PM_INV
wcrtprfmgr <spoketmr>-region <spoketmr>-region_MASTER_PM_ITM
wcrtprfmgr <spoketmr>-region <spoketmr>-region_MASTER_PM_SWD
wcrtprfmgr <spoketmr>-region <spoketmr>-region_MASTER_PM_TEC
wcrtprfmgr <spoketmr>-region <spoketmr>-region_MASTER_PMS_linux-ix86
wsetpm -d @ProfileManager:spoketmr-region_MASTER_PMS_linux-ix86
2. After having exchanged resources between the TMR environments using the
wupdate -r ProfileManager <spoketmr>-region command, you can
subscribe the spoketmr profile managers to the hubtmr profile managers, as
in Example 6-5.
Example 6-5 Subscribing spoketmr profile managers to hubtmr profile managers
wsub @ProfileManager:hubtmr-region_MASTER_PM_INV
@ProfileManager:<spoketmr>-region_MASTER_PM_INV
wsub @ProfileManager:hubtmr-region_MASTER_PM_ITM
@ProfileManager:<spoketmr>-region_MASTER_PM_ITM
wsub @ProfileManager:hubtmr-region_MASTER_PM_SWD
@ProfileManager:<spoketmr>-region_MASTER_PM_SWD
wsub @ProfileManager:hubtmr-region_MASTER_PM_TEC
@ProfileManager:<spoketmr>-region_MASTER_PM_TEC
Having established the top-level TMR objects, we are ready to create the region
and store-related objects. You can create the subscription hierarchy for each
store in every region manually using the wcrtpr, wcrtpm, and wsub commands.
However creating this structure manually for each individual store would be error
prone and cumbersome; it needs to be scripted. A sample script to create the
structure for a region and its related stores is provided in A.2.1,
“create_logical_structure.sh” on page 351.
This script uses a plain input file, containing a single store name on each line as
input. Observe, that the store files are used as well by the allow_login policy (see
“Allow_login policy” on page 344) so they should not be deleted after use. New
342
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
stores can be added to a region by simply adding a new line to the file. Examples
of store lists can be found in Appendix A.2.2, “Store lists” on page 355.
To create the structure for the NORTH region, which includes the stores N1, N2,
and N3, simple create a file named NORTH.lst, with the following content:
N1
N2
N3
Invoke the create_logical_structure.sh script, from the TMR server that the
region will belong, with the following parameters:
./create_locical_structure.sh NORTH linux-ix86 /tmp/NORTH.lst
Note: The file containing the list of stores must be available to both the hub
TMR Server and the Spoke TMR server to which the region belongs.
Therefore you should save it in a shared file system that can be accessed
from both systems.
6.5 Creating endpoint policies
The login policies are defined in the TMR Environment and are, among other
purposes, used to apply automatically controls and customization related to
endpoint systems during the login process when an endpoint connects to the
Tivoli Management Environment. When implementing the login policies, the
Tivoli Frameworks differentiates between the initial (first time) login of previously
unknown endpoints and subsequent logins - when the endpoint system is known
to the TMR.
All in all, there are four types of login policies:
allow_login
Verifies if an unknown endpoint is allowed to log in to the
TMR.
select_gateway
Helps control the gateway to login to for each new
endpoint.
login
Applies checks and automated functions such as
subscriptions once an endpoint logs in.
after_login
Applies checks and automated functions after an endpoint
has performed the first, successful log in.
The login policies must be maintained in both the hubtmr and all spoketmr
environments. In order to facilitate this, it is good practice to place the policy
scripts in a shared file system accessible from all the TMR servers. However,
Chapter 6. Deployment
343
while this will help the versioning control across TMRs, it does not automatically
ensure that the same policies are active on all TMRs at any one point in time.
The policy scripts need to be imported into each TMR by means of the wputeppol
command.
Naturally this task can be scripted to achieve the desired level of automation. In
A.3.1, “put.sh” on page 357 and A.3.2, “get.sh” on page 358 you will find sample
scripts used to import and export endpoint policies.
6.5.1 Allow_login policy
In the Outlet Systems Management Solution it we decided to let the hub TMR act
as an intercepting gateway for all endpoints. As a result, the hub TMR is
responsible for collecting all the initial login requests, and satisfying those
coming from endpoints that will be part of its own region or redirecting them to
the proper spoke TMR.
The allow_login policy is used to accomplish the first initial step, verifying
whether or not an endpoint is eligible for logging in. In the sample allow_login
policy provided with this book, this determination is performed by checking if the
store component of the endpoint label is present in the store_lists files and the
gateway.list file.
For the Outlet Systems Management Solution, the allow_login policy has been
configured to determine if the endpoint connecting to the TMR server was
allowed to log in. The store_lists files are consulted in order to verify the
relationship based on the endpoint’s label.
Once verified, a final check is performed by verifying that the first three
characters of the endpoint label are assigned to a gateway in the gateway.lst file,
used to control the assignment of gateways to specific regions and stores.
The allow_login policy script is shown in A.3.3, “allow_policy” on page 358. The
control files are provided in A.2.2, “Store lists” on page 355 and A.3.5,
“gateway.lst” on page 364.
6.5.2 Select_gateway policy
When the EP passes the allow login policy, the select gateway policy runs. The
gateway.lst file is consulted again to identify a gateway for the endpoint and
return the proper Tivoli object ID. The result of the assignment is redirected on a
log file.
For a listing of the select_gateway policy developed for the Outlet Systems
Management Solution, refer to A.3.4, “select_policy” on page 361.
344
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
6.5.3 Login policy
The login policy developed for the Outlet Systems Management Solution, shown
A.3.6, “login_policy” on page 364, only logs the endpoint label on a file in order to
track that the endpoint passes this script when logging in.
6.5.4 After_login policy
The after login policy script is executed once after an initial login process. For the
Outlet Systems Management Solution, this policy handles subscriptions, profile
distributions, and installation of software packages to new endpoints.
In summary, the after_login policy developed for the Outlet Systems
Management Solution performs the following:
1. Subscribing the endpoint to the correct profile managers using the sub_ep.sh
script.
2. Distributing hardware and software Inventory scanning profiles as well as the
basic (OS and HW) ITM monitoring profile through execution of the
ep_login_notif.sh script
3. Executing the run_ep_customization_task.sh script to execute the
ep_customization task in order to submit the activity plan to install software,
discover and create WAS and DB2 monitoring objects, and distribute
remaining monitoring profiles.
Note: The reason for implementing the ep_customization as a task is to
provide asynchronous execution of the majority of the deployment
operations. This will offload the TMR Server and allow it to process logins
from other endpoints.
A complete listing of the after_login policy and related scripts are available in
A.3.7, “after_policy” on page 365 ff.
6.6 Installing endpoints
To be able to manage the servers in the Outlet Solution, the Tivoli Management
Agent, otherwise known as the endpoint, needs to be installed on all systems.
The existence of the endpoint on an Outlet server is the bootstrap for enabling
the entire installation and management process.
Chapter 6. Deployment
345
To facilitate automation, it is necessary to define and enforce a strict naming
standard for the endpoints. The naming standard chosen for endpoint labels for
the Outlet Systems Management Solution is:
<client>_<region>_<store>-ep
This will enable the policy scripts to subscribe the endpoints to the correct profile
managers based on several factors, but primarily the geographical hierarchy.
Note: Based on the needs of the organization, naming standards and
requirements for subscription policies should be considered carefully before
setting up a production environment.
For Unix based systems, the endpoint installation is always initiated from the
command line of the TMR Server using some sort of remote access mechanism:
- rexec, ssh, and so forth. In this section, we assumed that UnitedLinux has been
installed on the Outlet Serves and that ssh has been enabled in accordance with
the description in 4.2.2, “Operating platform preparation” on page 142.
The command used to install an endpoint is winstlcf and for ssh the parameters
are as shown:
winstlcf -j -g <hubtmr>:9494 -l 9495 -n <hostname>_<region>_<store>-ep -r
<tmr>-<region>-<store>_EP -Y ‘<hostname> root <password>’
The winstlcf command shown, will install the endpoint on the target system and
assigns the hubtmr system as the intercepting gateway for the initial login.
Authentication to execute commands on the target system initiated from the hub
TMR is gained through ssh (the -j parameter) using the root user and the valid
password for that user.
To provide ease-of-use and consistency, the winstlcf command should be
scripted in any production environment, and further, perhaps would be build into
a Tivoli task. However, this will not change the fact that endpoint installation is a
manual process that must be executed by the Tivoli Administrators whenever a
new system is going to be included in the environment.
Once the endpoint is installed, it will attempt to login though the intercepting
gateway specified on the winstlcf command. At that point, the endpoint policy
scripts take control.
346
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Part 4
Part
4
Appendixes
These appendixes cover the following topics:
򐂰 Appendix A, “Configuration files and scripts” on page 349
򐂰 Appendix B, “Obtaining the installation images” on page 645
򐂰 Appendix C, “Additional material” on page 655
© Copyright IBM Corp. 2005. All rights reserved.
347
348
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
A
Appendix A.
Configuration files and
scripts
All files referenced in this Appendix are available online for download. See
Appendix C, “Additional material” on page 655 for details on how to obtain your
copy.
© Copyright IBM Corp. 2005. All rights reserved.
349
A.1 Additional material contents
The additional material is a zipped file that, when unpacked, will provide the all
the files described here. The files are organized in the following directory
structure:
򐂰 <unpack_dir>/code
Parent directory for installable code, put your downloaded images in this
directory
򐂰 <unpack_dir>/code/tivoli/scripts
Scripts developed specifically for the Outlet Systems Management Solution
򐂰 <unpack_dir>/rsp
Parent directory for response files
򐂰 <unpack_dir>/spd/
Parent directory for software package software package definition files
򐂰 <unpack_dir>/tools
Parent directory for Outlet Systems Management Solution specific scripts and
control files used by software packages
Once you have downloaded the file, unpack the online material to a directory of
your choice using gunzip. Upon unpacking, you should create a series of
symbolic links that reference the unpack directory to the /mnt directory, as in
Example A-1.
Example: A-1 Links to /mnt directory
if
ln
ln
ln
ln
[ ! -d /mnt ]; then mkdir /mnt; fi
-s /<unpack_dir>/code /mnt/code
-s /<unpack_dir>/rsp /mnt/rsp
-s /<unpack_dir>/spd /mnt/spd
-s /<unpack_dir>/tools /mnt/tools
Important: When unpacking the online material using Windows tools, you
should configure them to avoid automatic CRLF conversion. Failure to do this
will make the files unreadable from a unix system after they have been sent
through binary ftp.
350
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
A.2 TMR setup and maintenance-related files
These files are used to perform initial setup of the TMR environment to facilitate
automated distribution of software and monitoring profiles to new endpoints. The
endpoint policies described in A.3, “Policies and related tasks and scripts” on
page 357 rely on the successful execution of the scripts in this section.
In the unpacked online material, all of these files can be found in the
/mnt/core/tivoli/scripts directory.
A.2.1 create_logical_structure.sh
This script in Example A-2is used to create the logical structure of policy regions
and profile managers for the Outlet Systems Management Solution.
Example: A-2 create_logical_structure.sh
#!/bin/sh
#set -x
#########################################################################
#
# Date: November 2004
#-----------------------------------------------------------------------# DISCLAIMER: This script is provided AS IS
#
No official support will be provided from IBM support
#-----------------------------------------------------------------------# USAGE: ./create_logical_structure.sh GEO INTERP STORE_LIST_FILE
# Example: ./create_logical_structure.sh REGION01 linux-ix86
/tmp/REGION01_STORES.lst”
#
# GEO = The geographical region to be created (e.g. CENTRAL)
# INTERP = The interpreter type for default ITM, SWD and Inventory
#
profiles to create.
# STORE_LIST = Full path to a file containing a list of stores to create.
#
This file should contain a list of stores, one on each
#
line. Lines beginning with a # will be ignored.
#
These files will also be used by the login policies
#
to identify the appropriate gateway for each endpoint.
#
Please DO NOT DELETE these files after running the script.
#
To add additional stores, add the new store to the existing
#
file for that region and comment out the stores that were
#
created previously.
#
#
#########################################################################
GEO=$1
INTERP=$2
Appendix A. Configuration files and scripts
351
STORE_LIST=$3
# Check for the correct command line options
if [ $# -ne 3 ]; then
echo “ “
echo “This script will read an input file containing a list of stores”
echo “and create the logical policy region and profile structures”
echo “ “
echo “Usage: ./create_logical_structure.sh GEO INTERP STORE_LIST_FILE”
echo “Example: ./create_logical_structure.sh REGION01 linux-ix86
/tmp/REGION01_STORES.lst”
echo “ “
exit 1
fi
# Check for the store list file specified by the user
if [ ! -f “$STORE_LIST” ]; then
echo “ “
echo “Unable to locate specified input file: $STORE_LIST, aborting.”
echo “Please specify a valid file name including the full path.”
echo “e.g. /tmp/store_file.lst”
echo “ “
exit 2
fi
#-----------------------------------------------------------------------# Setup Tivoli Environment
#-----------------------------------------------------------------------echo “Setting Tivoli Environment”
. /etc/Tivoli/setup’_’env.sh > /dev/null
#-----------------------------------------------------------------------# Setup Script Variables
#-----------------------------------------------------------------------echo “ “
echo “*************************************************”
echo “
You may wish to run a database
“
echo “
backup before running this script.
“
echo “*************************************************”
echo “ “
echo “Do you wish to create the Policy Region, Profile Manager, Query Library
and Task Library structures? (y/n) (Default ‘n’):”
read FRW
DESTID=‘wlookup -ar ManagedNode |grep \.348 |grep -v $TMR |awk ‘{print $2}’‘
SRCID=‘wlookup ServerManagedNode‘
352
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
ADMIN=‘wls -l /Administrators |grep $TMR|grep Root’_’|awk ‘{print $2}’‘
TMRPR=‘echo $ADMIN|cut -d ‘’_’’ -f2‘
#-----------------------------------------------------------------------# Creating Policy Regions, Profile Managers and Profiles
#-----------------------------------------------------------------------#if [ $FRW = “y” ]; then
if [ “${FRW:-n}” = “y” ]; then
echo “*************************************************”
echo “
Creating Policy Region structure
“
echo “*************************************************”
wlookup -ar PolicyRegion|grep “$TMRPR” > /dev/null
RC=$?
if [ $RC -ne 0 ]; then
wcrtpr -a $ADMIN $TMRPR
else
echo “Policy Region $TMRPR exists, don’t need to create it”
fi
wlookup -ar PolicyRegion|grep $TMRPR’_’EP > /dev/null
RC=$?
if [ $RC -ne 0 ]; then
wcrtpr -s /Regions/$TMRPR -m Endpoint $TMRPR’_’EP
else
echo “Policy Region $TMRPR_EP exists, don’t need to create it”
fi
# Create the Main PolicyRegion per each GEO
wcrtpr -s /Regions/$TMRPR $GEO
# Create a PolicyRegion for Endpoints for each GEO
wcrtpr -s /Regions/$TMRPR/$GEO -m Endpoint $TMRPR’_’$GEO’_’EP
# Create a PolicyRegion for Profiles for each GEO
wcrtpr -s /Regions/$TMRPR/$GEO $TMRPR’_’$GEO’_’PR
#From this point forward, cycle through the list of stores and create the
objects
echo “*************************************************”
echo “ Link Monitoring for DB2 PR to $ADMIN Desktop “
echo “*************************************************”
Appendix A. Configuration files and scripts
353
wln /Library/PolicyRegion/”Monitoring for DB2” /Administrators/$ADMIN
wcrtpr -s /Regions/”Monitoring for DB2” “DB2 Database Servers”
echo
echo
echo
echo
“*************************************************************”
“ Cycling through $STORE_LIST and creating associated objects “
“*************************************************************”
“ “
# Check the STORE_LIST file for data and abort if empty
LINE_COUNT=‘wc -l $STORE_LIST | cut -c1-8‘
if [ $LINE_COUNT = 0 ]; then
echo “Input file $STORE_LIST is empty.”
echo “Exiting...”
exit 3
fi
grep “^[^#]” $STORE_LIST | {
while read STORE; do
echo “Creating objects for $GEO’_’$STORE’_’$INTERP”
wcrtpr -s @PolicyRegion:$TMRPR’_’$GEO’_’PR -m ACP -m InventoryConfig -m
ProfileManager -m QueryLibrary -m SoftwarePackage -m TaskLibrary -m
Tmw2kProfile $TMRPR’_’$GEO’_’$STORE’_’PR
echo “*************************************************”
echo “
Creating Profile Managers
“
echo “*************************************************”
wcrtprfmgr @$TMRPR’_’$GEO’_’$STORE’_’PR
$TMRPR’_’$GEO’_’$STORE’_’PMS’_’$INTERP
wsetpm -d @ProfileManager:$TMRPR’_’$GEO’_’$STORE’_’PMS’_’$INTERP
wcrtprfmgr @$TMRPR’_’$GEO’_’$STORE’_’PR $TMRPR’_’$GEO’_’$STORE’_’PM’_’INV
wcrtprfmgr @$TMRPR’_’$GEO’_’$STORE’_’PR $TMRPR’_’$GEO’_’$STORE’_’PM’_’TEC
wcrtprfmgr @$TMRPR’_’$GEO’_’$STORE’_’PR $TMRPR’_’$GEO’_’$STORE’_’PM’_’ITM
wcrtprfmgr @$TMRPR’_’$GEO’_’$STORE’_’PR $TMRPR’_’$GEO’_’$STORE’_’PM’_’SWD
echo “*************************************************”
echo “
Creating Task Library
“
echo “*************************************************”
wcrttlib $TMRPR’_’$GEO’_’$STORE’_’TL $TMRPR’_’$GEO’_’$STORE’_’PR
echo “*************************************************”
echo “
Creating Query Library
“
echo “*************************************************”
wcrtqlib $TMRPR’_’$GEO’_’$STORE’_’PR $TMRPR’_’$GEO’_’$STORE’_’QL
354
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#-----------------------------------------------------------------------# Subscriptions to PMS...
#-----------------------------------------------------------------------echo “*************************************************”
echo “
Subscribing PMS to Profile Managers
“
echo “*************************************************”
wsub @ProfileManager:$TMRPR’_’$GEO’_’$STORE’_’PM’_’INV
@ProfileManager:$TMRPR’_’$GEO’_’$STORE’_’PMS’_’$INTERP
wsub @ProfileManager:$TMRPR’_’$GEO’_’$STORE’_’PM’_’TEC
@ProfileManager:$TMRPR’_’$GEO’_’$STORE’_’PMS’_’$INTERP
wsub @ProfileManager:$TMRPR’_’$GEO’_’$STORE’_’PM’_’ITM
@ProfileManager:$TMRPR’_’$GEO’_’$STORE’_’PMS’_’$INTERP
wsub @ProfileManager:$TMRPR’_’$GEO’_’$STORE’_’PM’_’SWD
@ProfileManager:$TMRPR’_’$GEO’_’$STORE’_’PMS’_’$INTERP
done
}
else
echo “Exiting...”
fi
exit 0
A.2.2 Store lists
The sample store list files in the /mnt/code/tivoli/scripts/store_lists directory
control the creation of profile managers and policy regions that represent the
physical infrastructure of Outlet Inc. in the Outlet Systems Management Solution.
Each file represents the stores within a region.
In addition, these files are also used by the endpoint policies to determine if the
endpoint should be allowed to login and identify the appropriate gateway.
Do not delete the store list files after creating the logical structures. To add more
stores in the same region, simply add the store to the store list file for that region,
and comment out the stores that have already been created (using a #).
Example A-3, Example A-4 on page 356, and Example A-5 on page 356 are
examples of store list files.
general_stores.lst
Example: A-3 general_stores.lst
STORE
Appendix A. Configuration files and scripts
355
maine_stores.lst
Example: A-4 maine_stores.lst
2531
ohio_stores.lst
Example: A-5 ohio_stores.lst
0000
0001
A.2.3 load_tasks.sh
This script in Example A-6 is used to create and populate the Production_TL task
library, used primarily to deploy monitoring profiles to new endpoints. The tasks
created within the Production_TL tasklibrary references scripts that are
described in the subsequent sections.
Example: A-6 load_tasks.sh
wsettask -t Update_TMR_Resources -l Production_TL -i linux-ix86 hubtmr
/mnt/code/tivoli/scripts/update_resources.sh
wsettask -t Update_Resources_from_SPOKE -l Production_TL -i linux-ix86
/mnt/code/tivoli/scripts/update_resources.sh
wsettask -t ep_customization -l Production_TL -i linux-ix86 hubtmr
/mnt/code/tivoli/scripts/apps/APM/ep_customization.sh
wsettask -t itm_WAS_rm_distrib -l Production_TL -i linux-ix86 hubtmr
/mnt/code/tivoli/scripts/apps/WAS/itm_was_rm_distrib.sh
wsettask -t Create_DB2_instance_objects -l Production_TL -i linux-ix86
/mnt/code/tivoli/scripts/apps/DB2/create_db2_instance_objects.sh
wsettask -t Create_DB2_database_objects -l Production_TL -i linux-ix86
/mnt/code/tivoli/scripts/apps/DB2/create_db2_database_objects.sh
wsettask -t itm_DB2_database_rm_distrib -l Production_TL -i linux-ix86
/mnt/code/tivoli/scripts/apps/DB2/itm_db2_database_rm_distrib.sh
wsettask -t itm_DB2_instance_rm_distrib -l Production_TL -i linux-ix86
/mnt/code/tivoli/scripts/apps/DB2/itm_db2_instance_rm_distrib.sh
hubtmr
hubtmr
hubtmr
hubtmr
hubtmr
The load_tasks creates the following tasks to be referenced from the endpoint
policies:
356
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
A.2.4 update_resources.sh
This script in Example A-7 is used to update resources between TMRs, and is
referenced from the Update_Resources task in the Production_TL Task Library.
It is suggested to schedule this script to execute automatically on all spoke
TMRs, for example every 120 minutes, to automatically inform the hubtmr about
changes to the infrastructure,
Example: A-7 update_resources.sh
#!/bin/sh
wupdate -r All All
A.3 Policies and related tasks and scripts
The files in this section implement the automated deployment of software
packages and monitoring profiles to new Outlet Servers upon the initial login,
using the capabilities of the endpoint policies in the Tivoli Management
Framework.
The scripts and supporting files that implement the endpoint policies can be
found in the /mnt/code/tivoli/scripts/policies directory after unpacking the
online material.
As a prerequisite for using these scripts, the logical structure and the
Production_TL task library must have been created, using the files provided in
A.2, “TMR setup and maintenance-related files” on page 351.
A.3.1 put.sh
Example A-8 is a support script used to easily load the endpoint policies into the
TMR.
Example: A-8 put.sh
echo “Installing allow policy...”
wputeppol allow < allow_policy
echo “Installing login policy...”
wputeppol login < login_policy
echo “Installing login policy...”
wputeppol after < after_policy
echo “Installing select policy...”
wputeppol select < select_policy
echo “Updating epmgr...”
Appendix A. Configuration files and scripts
357
wepmgr update
echo “Done!”
A.3.2 get.sh
Example A-9 is a support script used to easily unload the endpoint policies from
a TMR.
Example: A-9 get.sh
wgeteppol
wgeteppol
wgeteppol
wgeteppol
allow > allow_policy_tmr
login > login_policy_tmr
after > after_policy_tmr
select > select_policy_tmr
A.3.3 allow_policy
This script in Example A-10 implements the allow_login endpoint policy used to
verify if a new endpoint is authorized to connect to the TMR. This implementation
of the allow_login policy only allows endpoints to proceed with the login process
if their host name is matched in the gateway.lst file. See A.3.5, “gateway.lst” on
page 364. In addition, the stores.lst (see , “general_stores.lst” on page 355 file is
consulted to determine the correct gateway.
Example: A-10 allow_policy
#!/bin/sh
# ------------------------------------------------------------------------#
# Descrizione: Allow policy
# 1) Verifica che non esista un Endpoint duplicato:
#
- duplicato ---> exit 6
#
2) Consente il login dell’Endpoint solo se esiste il SUO gateway di
filiale
#
# Input: necessita del file “/Tivoli_$HOST/comune/gateway.lst” il quale
#
contiente la lista di tutti i gateway del local TMR
#
# Exit: exit 0 = gateway trovato
#
exit 6 = gateway non trovato oppure endpoint duplicato
#
# Versione 1.0 09/12/2002 by Fabrizio Salustri, Giuseppe Grammatico, Enzo
Randazzo
# ------------------------------------------------------------------------#
# Please do not remove the below Tivoli comments
358
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
# --- Start of Tivoli comments --#
# The following are the command line arguments passed to this script
# from the Endpoint Manager.
#
# $1 - The label of the endpoint machine
# $2 - The object reference of the endpoint machine
# $3 - The architecture type of the endpoint machine
# $4 - The object reference of the gateway that the endpoint logged into
# $5 - The ip address of the endpoint logging in.
# $6 - region
# $7 - dispatcher
# $8 - version
# $9 - The inventory id of the endpoint logging in.
#
# The following command line argument will be passed to this script
# from the Endpoint Manager, when compiled with the MULTIPROTO flag turned on
#
# $10 - The protocol of the endpoint logging in.
#
TCPIP
-> TCP/IP
#
IPX
-> IPX/SPX
#
# The normal exit code of 0 from the allow_install_policy will allow the
# endpoint’s initial login to proceed. (If the label of this endpoint is
# in use, though, this login won’t complete.)
#
# An exit code of 10 also will allow this login to proceed and, if this
# endpoint’s label matches the label of an existing endpoint, a unique label
# will be created for this endpoint.
#
# An exit code of 6 will cause this login to be ignored.
#
# Exiting the allow_install_policy with any other non-zero exit status will
# stop this endpoint’s initial (or orphaned) login.
#
# The environment variable LCF_LOGIN_STATUS is also set by the epmgr.
# A value of 2 indicates the endpoint is isolated. That is, it was unable
# to contact its assigned gateway. Isolated endpoints are automatically
# migrated to another gateway unless the select_gateway_policy terminates
# with a non-zero exit status. Other LCF_LOGIN_STATUS values are:
# 0 Initial login
(allow_install_policy, select_gateway_policy,
after_install_policy)
# 2 Isolated login (select_gateway_policy)
# 3 Migratory login (select_gateway_policy)
# 7 Orphaned login (allow_install_policy, select_gateway_policy,
after_install_policy)
#
# The allow_install_policy will have these environment variables set if
# there is already an existing endpoint with the same label as the endpoint
Appendix A. Configuration files and scripts
359
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
which is attempting to login:
LCF_DUPL_OBJECT
object id of existing endpoint
LCF_DUPL_ADDRESS network address of existing endpoint
LCF_DUPL_LOGIN
timestamp of existing endpoint’s first normal login
LCF_DUPL_GATEWAY object id of existing endpoint’s gateway
LCF_DUPL_INV_ID
inventory id of existing endpoint
LCF_DUPL_INTERP
interp (architecture type) of existing endpoint
The initial login will fail for an endpoint whose label matches the label
of an existing endpoint, unless allow_install_policy is exited with code 10.
Also note that during the execution of allow_install and select_gateway
policy scripts, the endpoint does not yet formally exist. For this reason,
the endpoint object reference will have a value of OBJECT_NIL and the
object dispatcher number will be 0. The endpoint label will have the value
suggested by the endpoint (or the user value lcfd -n) but is not guaranteed
to become the final endpoint label. It will become the final endpoint label
if this value is not already taken by another endpoint.
--- End of Tivoli comments ---
ep_label=$1
POL_DIR=”/mnt/code/tivoli/scripts/policies”
LISTGW=”$POL_DIR/gateway.lst”
LOG_FILE=”$DBDIR/../policies/logs/allow_install.log”
STORE_FILE_DIR=”$POL_DIR/../store_lists”
#
# check if Enpoint already exists
#
- if exist then Exit_code 6 + log
#
if [ “$LCF_DUPL_OBJECT” != ““ ]
then
data=‘date +”%d/%m/%Y %H:%M:%S”‘
echo “$data Endpoint: $ep_label already exists. Exit_Code 6”
>>$LOG_FILE
echo “$data Additional Information follows:” >>$LOG_FILE
echo “$data LCF_DUPL_OBJECT: $LCF_DUPL_OBJECT” >>$LOG_FILE
echo “$data LCF_DUPL_ADDRESS: $LCF_DUPL_ADDRESS” >>$LOG_FILE
echo “$data LCF_DUPL_LOGIN: $LCF_DUPL_LOGIN” >>$LOG_FILE
echo “$data LCF_DUPL_GATEWAY: $LCF_DUPL_GATEWAY” >>$LOG_FILE
echo “$data LCF_DUPL_INV_ID: $LCF_DUPL_INV_ID \n” >>$LOG_FILE
fi
#
# extract the EP_ID based on the hostname
#
EP_ID=‘echo $ep_label | cut -c 1-3‘
STORE=‘echo $ep_label | cut -d “_” -f3 | cut -d “-” -f1‘
360
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
# Find the store in the store list files to ensure the provided region and
store are valid and
# search the gateway.lst for the assigned gateway
#
grep $STORE $STORE_FILE_DIR/*.lst
if [ $? -eq 0 ] ; then
echo “Login allowed for $ep_label” >>$LOG_FILE
else
GATEWAY=$(grep $EP_ID $LISTGW )
if [ $? -gt 0 ]; then
date=‘date “+%d/%m/%Y %H:%M:%S”‘
echo $date “Endpoint does not follow naming convention and was not
found in $LISTGW. Login not allowed for $ep_label.” >>$LOG_FILE
exit 1
else
echo “Endpoint does not follow naming convention, but found in $LISTGW.
Login allowed for $ep_label.” >>$LOG_FILE
fi
fi
A.3.4 select_policy
Example A-11 implements the select_gateway endpoint policy, and is used to
determine which gateway to assign to and endpoint. The gateway.lst file (see
A.3.5, “gateway.lst” on page 364) holds the control information needed to assign
the correct gateway.
Example: A-11 select_policy
#!/bin/sh
#
# Select login policy
#
# Ricerca l’id della filiale nel file LISTAGW, creato con il comando “wlookup
-ar Gateway”
# - trovato: l’endpoint viene attestato a questo gateway
# - non trovato: login rifiutata
#
# Versione 1.0 09/12/2002 by Fabrizio Salustri, Giuseppe Grammatico, Enzo
Randazzo
# ------------------------------------------------------------------------# Please do not remove the below Tivoli comments
# --- Start of Tivoli comments --#
Appendix A. Configuration files and scripts
361
# The following are the command line arguments passed to this script
# from the Endpoint Manager.
#
# $1 - The label of the endpoint machine
# $2 - The object reference of the endpoint machine
# $3 - The architecture type of the endpoint machine
# $4 - The object reference of the gateway that the endpoint logged into
# $5 - The ip/ipx address of the endpoint logging in (refer to parameter
#
$10 to determine the protocol of the endpoint).
# $6 - region
# $7 - dispatcher
# $8 - version
# $9 - The inventory id of the endpoint logging in.
#
# The following command line argument will be passed to this script
# from the Endpoint Manager, when compiled with the MULTIPROTO flag turned on
#
# $10 - The protocol of the endpoint logging in.
#
TCPIP
-> TCP/IP
#
IPX
-> IPX/SPX
#
# The environment variable LCF_LOGIN_STATUS is also set by the epmgr.
# A value of 2 indicates the endpoint is isolated. That is, it was unable
# to contact its assigned gateway. Isolated endpoints are automatically
# migrated to another gateway unless the select_gateway_policy terminates
# with a non-zero exit status. Other LCF_LOGIN_STATUS values are:
# 0 Initial login
(allow_install_policy, select_gateway_policy,
after_install_policy)
# 2 Isolated login (select_gateway_policy)
# 3 Migratory login (select_gateway_policy)
# 7 Orphaned login (allow_install_policy, select_gateway_policy,
after_install_policy)
#
# Also note that during the execution of allow_install and select_gateway
# policy scripts, the endpoint does not yet formally exist. For this reason,
# the endpoint object reference will have a value of OBJECT_NIL and the
# object dispatcher number will be 0. The endpoint label will have the value
# suggested by the endpoint (or the user value lcfd -n) but is not guaranteed
# to become the final endpoint label. It will become the final endpoint label
# if this value is not already taken by another endpoint.
# --- End of Tivoli comments --ep_label=$1
POL_DIR=”/mnt/code/tivoli/scripts/policies”
LISTGW=”$POL_DIR/gateway.lst”
LOG_FILE=”$DBDIR/../policies/logs/select_gateway.log”
STORE_FILE_DIR=”$POL_DIR/../store_lists”
362
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#You must change the store_file_dir to point to the directory containing your
store files
#
# Select the first three characters of the endpoint label to identify the type
of endpoint
#
EP_ID=‘echo $ep_label | cut -c 1-3‘
REGION=‘echo $ep_label | cut -d “_” -f2‘
STORE=‘echo $ep_label | cut -d “_” -f3 | cut -d “-” -f1‘
#
# Find the store in the store list files to ensure the provided region and
store are valid and
# search the gateway.lst for the assigned gateway
#
grep $STORE $STORE_FILE_DIR/*.lst
if [ $? -eq 0 ] ; then
GATEWAY=$(grep $STORE $LISTGW)
if [ $? -eq 0 ]; then
GATEWAY_OID=$(echo $GATEWAY | cut -d’#’ -f1 | awk ‘{print $2}’)
GATEWAY_NAME=$(echo $GATEWAY | awk ‘{print $1}’)
echo “Gateway for $ep_label is $GATEWAY_NAME” >>$LOG_FILE
else
echo $date “Gateway not found for Endpoint $ep_label” >>$LOG_FILE
exit 6
fi
else
GATEWAY=$(grep $EP_ID $LISTGW)
if [ $? -eq 0 ]; then
GATEWAY_OID=$(echo $GATEWAY | cut -d’#’ -f1 | awk ‘{print $2}’)
GATEWAY_NAME=$(echo $GATEWAY | awk ‘{print $1}’)
echo “Endpoint does not follow naming convention, but found in
$LISTGW” >>$LOG_FILE
echo “Gateway for $ep_label is $GATEWAY_NAME” >>$LOG_FILE
else
date=‘date “+%d/%m/%Y %H:%M:%S”‘
echo $date “Gateway not found for Endpoint $ep_label”
>>$LOG_FILE
exit 7
fi
fi
echo $GATEWAY_OID
Appendix A. Configuration files and scripts
363
A.3.5 gateway.lst
This file in Example A-12 is used to correlate stores and regions and their related
gateways.
Example: A-12 gateway.lst
## TMR Gateways
hubtmr-gw1393424439.1.594#TMF_Gateway::Gateway#tecsrcrdbspom084fabmmmmmwconmjn
kcb ibm
spoketmr-gw1282790711.1.1146#TMF_Gateway::Gateway# tmtreg
## Regional Gateways
#TEXAS01-gw$TMR.x.xx#TMF_Gateway::Gateway#
#OHIO01-gw$TMR.x.xx#TMF_Gateway::Gateway#
region01-gw1282790711.2.23#TMF_Gateway::Gateway#stadev
## Store Gateways
#TEXAS_1234-gw$TMR.x.xx#TMF_Gateway::Gateway#
#OHIO_4321-gw$TMR.x.xx#TMF_Gateway::Gateway#
region_store-gw1282790711.3.23#TMF_Gateway::Gateway# STORE
## Assumptions:
##
## 1 - Endpoint labels must be set at machine installation time to the
following format: <hostname>_<region>_<store>-ep
## 2 - Each store has a unique number (e.g. 1234 does not appear in other
regions)
A.3.6 login_policy
This endpoint policy in Example A-13 is used for all endpoint logins, apart from
the initial login performed for new endpoints. The following implementation only
logs the login, but customized proceeding can be applied.
Example: A-13 login_policy
#!/bin/sh
# ------------------------------------------------------------------------# Descrizione: Login script
# - sul gateway nella directory $LOG_FILE viene creato un file
#
$ep_label. La data/time di ultima modifica e’ usata per capire
364
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
quando l’endpoint ha effettuato l’ultimo normal login
#
# Versione 1.0 09/12/2002 by Fabrizio Salustri, Giuseppe Grammatico, Enzo
Randazzo
# ------------------------------------------------------------------------#
# Please do not remove the below Tivoli comments
# --- Start of Tivoli comments --#
# The following are the command line arguments passed to this script
# from the Gateway.
#
# $1 - The label of the endpoint machine
# $2 - The object reference of the endpoint machine
# $3 - The architecture type of the endpoint machine
# $4 - The object reference of the gateway that the endpoint logged into
# $5 - The ip/ipx address of the endpoint logging in (refer to parameter
#
$9 to determine the protocol of the endpoint).
# $6 - region
# $7 - dispatcher
# $8 - version
#
# The following command line argument will be passed to this script
# from the Endpoint Manager, after the MULTIPROTO flag will be turned on
#
# $9 - The protocol of the endpoint logging in.
#
TCPIP
-> TCP/IP
#
IPX
-> IPX/SPX
#
# --- End of Tivoli comments --ep_label=$1
LOG_FILE=”$DBDIR/../policies/logs/login_policy”
touch “$LOG_FILE/$ep_label”
exit 0
A.3.7 after_policy
This implementation of the after_login endpolicy in Example A-14 on page 366 is
used to perform initial configuration, including subscribing the endpoint to the
profile managers in the logical structure, submitting an initial inventory scan, and
finally starting a task that activates the APM plan for the particular endpoint.
Appendix A. Configuration files and scripts
365
Example: A-14 after_policy
#!/bin/sh
# Please do not remove the below Tivoli comments
# --- Start of Tivoli comments --#
# The following are the command line arguments passed to this script
# from the Endpoint Manager.
#
# $1 - The label of the endpoint machine
# $2 - The object reference of the endpoint machine
# $3 - The architecture type of the endpoint machine
# $4 - The object reference of the gateway that the endpoint logged into
# $5 - The ip/ipx address of the endpoint logging in (refer to parameter
#
$10 to determine the protocol of the endpoint).
# $6 - region
# $7 - dispatcher
# $8 - version
# $9 - The unique id (inventory id) of the endpoint logging in.
# $10 - The protocol of the endpoint logging in.
#
TCPIP
-> TCP/IP
#
IPX
-> IPX/SPX
#
# The environment variable LCF_LOGIN_STATUS is also set by the epmgr.
# A value of 2 indicates the endpoint is isolated. That is, it was unable
# to contact its assigned gateway. Isolated endpoints are automatically
# migrated to another gateway unless the select_gateway_policy terminates
# with a non-zero exit status. Other LCF_LOGIN_STATUS values are:
# 0 Initial login
(allow_install_policy, select_gateway_policy,
after_install_policy)
# 2 Isolated login (select_gateway_policy)
# 3 Migratory login (select_gateway_policy)
# 7 Orphaned login (allow_install_policy, select_gateway_policy,
after_install_policy)
#
# Also note that during the execution of allow_install and select_gateway
# policy scripts, the endpoint does not yet formally exist. For this reason,
# the endpoint object reference will have a value of OBJECT_NIL and the
# object dispatcher number will be 0. The endpoint label will have the value
# suggested by the endpoint (or the user value lcfd -n) but is not guaranteed
# to become the final endpoint label. It will become the final endpoint label
# if this value is not already taken by another endpoint.
# --- End of Tivoli comments --ep_label=$1
INTERP=$3
POL_DIR=”/mnt/code/tivoli/scripts/policies”
SCRIPTS_LOC=”/mnt/code/tivoli/scripts”
LOG_FILE=”$DBDIR/../policies/logs/after_login_policy.log”
366
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
echo “Checking INTERP” >> $LOG_FILE
echo $INTERP >> LOG_FILE
echo “Calling sub_ep.sh script” >> $LOG_FILE
$POL_DIR/sub_ep.sh $ep_label $LOG_FILE
echo “Calling ep_login_notif.sh script” >> $LOG_FILE
$POL_DIR/ep_login_notif.sh $ep_label $INTERP
#echo “Calling ep_customization.sh script” >> $LOG_FILE
#$SCRIPTS_LOC/apps/APM/ep_customization.sh $ep_label
echo “Calling ep_customization task” >> $LOG_FILE
$POL_DIR/run_ep_customization_task.sh $ep_label >> $LOG_FILE
echo “After script execution completed... Exiting” >> $LOG_FILE
exit 0
A.3.8 sub_ep.sh
This script in Example A-15 is called from the after_login policy to perform initial
subscription of new endpoints.
Example: A-15 sub_ep.sh
#!/bin/sh
ep_label=$1
LOG_FILE=$2
REGION=‘echo $ep_label | cut -d “_” -f2‘
STORE=‘echo $ep_label | cut -d “_” -f3 | cut -d “-” -f1‘
policy_region=$(wlookup -ar PolicyRegion|grep $REGION’_’EP|awk ‘{print $1}’)
profile_manager=$(wlookup -ar ProfileManager|grep $STORE’_’PMS|awk ‘{print
$1}’)
wupdate -r Endpoint All
# Link the endpoint to the appropriate policy region
wln @Endpoint:$ep_label @PolicyRegion:$policy_region
if [ $? -eq 0 ]; then
echo “Endpoint $ep_label linked to Policy Region $policy_region
successfully.” >> $LOG_FILE
wpostemsg -m “Endpoint $ep_label completed initial login and successfully
linked to Policy Region $policy_region.” -r HARMLESS EVENT EVENT
else
echo “Endpoint $ep_label failed to link to Policy Region $policy_region.”
>> $LOG_FILE
Appendix A. Configuration files and scripts
367
exit 5
fi
# Subscribe the endpoint to the appropriate profile manager
wsub -r @$profile_manager @Endpoint:$ep_label
if [ $? -eq 0 ]; then
echo “Endpoint $ep_label subscribed to Profile Manager $profile_manager
successfully.” >> $LOG_FILE
else
echo “Endpoint $ep_label failed to subscribe to Profile Manager
$profile_manager.” >> $LOG_FILE
echo “Either the profile manager or the endpoint is unreachable.” >>
$LOG_FILE
exit 6
fi
A.3.9 ep_login_notif.sh
This script in Example A-16 is used by the after_login policy to initiate an initial
inventory scan of new endpoints.
Example: A-16 ep_login_notif.sh
#!/bin/sh
set -x
ep_label=$1
INTERP=$2
POL_DIR=”/mnt/code/tivoli/scripts/policies”
JRE_DIR=”$POL_DIR/../../ITM/5.1.2/base/generic/Tools/JRE”
LOG_FILE=”$DBDIR/../policies/logs/wdistinv.log”
REGION=‘echo $ep_label | cut -d “_” -f2‘
STORE=‘echo $ep_label | cut -d “_” -f3 | cut -d “-” -f1‘
policy_region=$(wlookup -ar PolicyRegion|grep $REGION’_’EP|awk ‘{print $1}’)
TMR_NAME=$(idlattr -tgv ‘wlookup ServerManagedNode‘ label string |sed -e
“s/\”//g”)
# Check if the EP is running...
echo “Sleeping for 5 minutes waiting for the EP to complete the first normal
login, please wait...” >> $LOG_FILE
sleep 300
echo “Sleep complete!” >> $LOG_FILE
echo “Entering in Inventory section...” >> $LOG_FILE
wupdate -r Endpoint All >> $LOG_FILE
echo “wupdate complete!” >> $LOG_FILE
echo “Checking if the EP is alive...” >> $LOG_FILE
wep $ep_label status >> $LOG_FILE
368
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
RC=$?
if [ $RC -eq 0 ] ; then
# Distribute the Hardware inventory profile
echo “$ep_label” >> $LOG_FILE
wdistinv @InventoryConfig:HW @Endpoint:$ep_label >> $LOG_FILE
EC=$?
if [ $EC -eq 0 ] ; then
wpostemsg -m “Endpoint $ep_label started HW scan” -r HARMLESS EVENT
EVENT
else
inventory_config=$(wlookup -ar InventoryConfig|grep “HW”|grep $TMR|grep
$TMR_NAME|awk ‘{print $1}’)
wdistinv @InventoryConfig:$inventory_config @Endpoint:$ep_label >>
$LOG_FILE
RC=$?
if [ $RC -eq 0 ] ; then
wpostemsg -m “Endpoint $ep_label started HW scan” -r HARMLESS EVENT
EVENT
else
echo “Failed to submit the HW inventory scan.” >> $LOG_FILE
exit 1
fi
fi
# Distribute the Software inventory profile
echo “$ep_label” >> $LOG_FILE
wdistinv @InventoryConfig:SW @Endpoint:$ep_label >> $LOG_FILE
EC=$?
if [ $EC -eq 0 ] ; then
wpostemsg -m “Endpoint $ep_label started SW scan” -r HARMLESS EVENT
EVENT
else
inventory_config=$(wlookup -ar InventoryConfig|grep “SW”|grep $TMR|grep
$TMR_NAME|awk ‘{print $1}’)
wdistinv @InventoryConfig:$inventory_config @Endpoint:$ep_label >>
$LOG_FILE
RC=$?
if [ $RC -eq 0 ] ; then
wpostemsg -m “Endpoint $ep_label started SW scan” -r HARMLESS EVENT
EVENT
else
echo “Failed to submit the SW inventory scan.” >> $LOG_FILE
exit 2
fi
fi
else
Appendix A. Configuration files and scripts
369
wpostemsg -m “Endpoint $ep_label completed initial login to its gateway but
it is not running, Inventory HW and SW distributions not started” -r CRITICAL
EVENT EVENT
exit 3
fi
echo “Sleeping 5 minutes waiting for inventory scans to complete” >> $LOG_FILE
sleep 300
echo “Spleep complete!” >> $LOG_FILE
# Check if the EP is running...
echo “Entering in ITM section...” >> $LOG_FILE
wep $ep_label status >> $LOG_FILE
RC=$?
if [ $RC -eq 0 ] ; then
# Distribute the base ITM profile including the JRE
ITM_PRF_NAME=‘wlookup -ar Tmw2kProfile |grep $STORE | grep $INTERP| awk
‘{print $1}’‘
wdmdistrib -p $ITM_PRF_NAME -J $JRE_DIR -l -e -w -i @Endpoint:$ep_label >>
$LOG_FILE
RC=$?
if [ $RC -eq 0 ] ; then
wpostemsg -m “Endpoint $ep_label started ITM Profile distribution named
$ITM_PRF_NAME” -r HARMLESS EVENT EVENT
else
echo “ITM Profile Distribution named $ITM_PRF_NAME failed for endpoint
$ep_label” >> $LOG_FILE
exit 4
fi
else
wpostemsg -m “Endpoint $ep_label completed initial login to its gateway but
it is not running, ITM profile distribution not started” -r CRITICAL EVENT
EVENT
exit 5
fi
A.3.10 run_ep_customization_task.sh
This script in Example A-17 on page 371 is called from the after_login policy in
order to start and asynchronous task that deploys the APM plan, which is
responsible for software installation and profile deployment), for the new
endpoint.
370
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Example: A-17 run_ep_customization_task.sh
#!/bin/sh
ep_label=$1
LOG_FILE=/tmp/ep_customization_task.out
wruntask -t ep_customization -l Production_TL -h @ManagedNode:hubtmr -a
$ep_label -m 600 >> $LOG_FILE
A.4 DB2 monitoring deployment-related scripts
These files are used to automate the creation and deployment of DB2-related
monitoring resources. All the files can be found in the
/mnt/tivoli/scripts/apps/DB2 directory. They are all referenced from the script
used to create the Production_TL task library described in A.2.3, “load_tasks.sh”
on page 356.
A.4.1 create_db2_instance_objects.sh
This script in Example A-18 creates DB2InstanceManager objects related to a
new endpoint.
In the APM plan for deployment, a task using this script is executed immediately
after installation of the DB2 Server software package.
Example: A-18 create_db2_instance_objects.sh
#!/bin/sh
# This script creates an IBM for Databases for DB2 database resource.
# We started from these assumptions:
#
# instance name is the default one installed with DB2, “db2inst1”
# We created the “DB2 Database Servers” Policy Region on both the TMR hub and
the TMR spoke(s)
ep_label=$1
SCRIPTS_LOC=”/mnt/code/tivoli/scripts”
LOG_FILE=”$SCRIPTS_LOC/apps/DB2/logs/create_db2_instance_objects.log”
wcdb2inst -l “db2inst1@$ep_label” \
-e $ep_label \
-i db2inst1 \
-p “DB2 Database Servers” >> $LOG_FILE
Appendix A. Configuration files and scripts
371
EC=$?
if [ $EC -eq 0 ] ; then
echo “Instance object for EP $ep_label succesfully created” >> $LOG_FILE
else
TMR_NAME=$(idlattr -tgv ‘wlookup ServerManagedNode‘ label string |sed -e
“s/\”//g”)
policy_region=‘wlookup -ar PolicyRegion |grep $TMR|grep $TMR_NAME| grep
“DB2 Database Servers”| awk ‘{print $1 “ “ $2 “ “ $3}’‘
wcdb2inst -l “db2inst1@$ep_label” \
-e $ep_label \
-i db2inst1 \
-p “$policy_region” >> $LOG_FILE
RC=$?
if [ $RC -eq 0 ]; then
echo “Instance object for EP $ep_label succesfully created” >>
$LOG_FILE
else
echo “Failed to create Instance object for EP $ep_label” >> $LOG_FILE
exit 1
fi
fi
A.4.2 create_db2_database_objects.sh
This script in Example A-19 creates DB2DatabaseManager objects related to a
new endpoint.
In the APM plan for deployment, a task using this script is executed immediately
after installation of the DB2 Server software package.
Example: A-19 create_db2_database_objects.sh
#!/bin/sh
# This script creates an IBM for Databases for DB2 database resource.
# We started from these assumptions:
#
# instance name is the default one installed with DB2, “db2inst1”
# database name is “STORE”, and each machine that will be installed as EP must
have this DB created under the “db2inst1” instance. The STORE database is used
by
# the TimeCard pllication
# We created the “DB2 Database Servers” Policy Region on both the TMR hub and
the TMR spoke(s)
ep_label=$1
ep=$(echo $ep_label|cut -d “-” -f1)
SCRIPTS_LOC=”/mnt/code/tivoli/scripts”
372
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
LOG_FILE=”$SCRIPTS_LOC/apps/DB2/logs/create_db2_database_objects.log”
TMR_NAME=$(idlattr -tgv ‘wlookup ServerManagedNode‘ label string |sed -e
“s/\”//g”)
wcdb2dbs -l “store@db2inst1@$ep” \
-i “db2inst1@$ep_label” \
-d STORE \
-p “DB2 Database Servers” >> $LOG_FILE
EC=$?
if [ $EC -eq 0 ] ; then
echo “DB object for EP $ep_label succesfully created” >> $LOG_FILE
else
PR=$(wlookup -ar PolicyRegion|grep “DB2 Database
Servers#$TMR_NAME-region”|grep $TMR|grep $TMR_NAME|awk ‘{print $1 “ “ $2 “ “
$3}’)
wcdb2dbs -l “store@db2inst1@$ep” \
-i “db2inst1@$ep_label” \
-d STORE \
-p “$PR” >> $LOG_FILE
RC=$?
if [ $RC -eq 0 ]; then
echo “DB object for EP $ep_label succesfully created” >> $LOG_FILE
else
echo “Failed to create DB object for EP $ep_label” >> $LOG_FILE
exit 1
fi
fi
A.4.3 itm_db2_instance_rm_distrib.sh
This script in Example A-20 is used to distribute db2 instance related monitoring
profiles the newly created endpoints.
In the APM plan for deployment, a task using this script is executed immediately
after installation of the DB2 Server software package.
Example: A-20 itm_db2_instance_rm_distrib.sh
#!/bin/sh
# This script is used by a Tivoli Task to distribute the ITM for Databases for
DB2 Resource Model(s) to the InstanceManager resource discovered on an EP
# We created and customized a Tmw2kProfile to include specific RMs.
# Before the ITM RM distribution, the scripts subscribe the InstanceManager
Resource to the ProfileManager containing the Tmw2kProfile to distribute
#
Appendix A. Configuration files and scripts
373
# We hard coaded the Profile Manager name to “DB2Manager-Instances”
ep_label=$1
ep=$(echo $ep_label | cut -d “-” -f1)
SCRIPTS_LOC=”/mnt/code/tivoli/scripts”
LOG_FILE=”$SCRIPTS_LOC/apps/DB2/logs/itm_db2_instance_rm_distrib.log”
# Setting variables for instance object(s)
INST_PM=”DB2Manager-Instances”
INST_RM=”DB2_instances”
INST_SUB=$(wlookup -ar DB2InstanceManager|grep db2inst1|grep $ep_label|awk
‘{print $1}’)
# Subscribing DB2 resources to its ProfileManagers
wsub -r @ProfileManager:$INST_PM @DB2InstanceManager:$INST_SUB
EC=$?
if [ $EC -eq 0 ] ; then
echo “Instance object for EP $ep_label succesfully subscried to $INST_PM”
else
TMR_NAME=$(idlattr -tgv ‘wlookup ServerManagedNode‘ label string |sed -e
“s/\”//g”)
prof_mgr=‘wlookup -ar ProfileManager |grep $TMR|grep $TMR_NAME| grep
“DB2Manager-Instances”| awk ‘{print $1}’‘
wsub -r @ProfileManager:$prof_mgr @DB2InstanceManager:$INST_SUB
RC=$?
if [ $RC -eq 0 ]; then
echo “Instance object for EP $ep_label succesfully subscribed
to $prof_mgr” >> $LOG_FILE
else
echo “Failed to subscribe Instance object to $prof_mgr for EP $ep_label”
>> $LOG_FILE
exit 1
fi
fi
# Distributing ITM DB2 RMs to the specified resources
wdmdistrib -p $INST_RM -e -w -i @DB2InstanceManager:$INST_SUB >> $LOG_FILE
A.4.4 itm_db2_database_rm_distrib.sh
This script in Example A-21 distributes monitoring profiles for DB2 databases to
newly created endpoints.
374
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
In the APM plan for deployment, a task using this script is executed immediately
after installation of the DB2 Server software package.
Example: A-21 iitm_db2_database_rm_distrib.sh
#!/bin/sh
# This script is used by a Tivoli Task to distribute the ITM for Databases for
DB2 Resource Model(s) to the InstanceManager resource discovered on an EP
# We created and customized a Tmw2kProfile to include specific RMs.
# Before the ITM RM distribution, the scripts subscribe the InstanceManager
Resource to the ProfileManager containing the Tmw2kProfile to distribute
#
# We hard coaded the Profile Manager name to “DB2Manager-Instances”
ep_label=$1
ep=$(echo $ep_label | cut -d “-” -f1)
SCRIPTS_LOC=”/mnt/code/tivoli/scripts”
LOG_FILE=”$SCRIPTS_LOC/apps/DB2/logs/itm_db2_instance_rm_distrib.log”
# Setting variables for instance object(s)
INST_PM=”DB2Manager-Instances”
INST_RM=”DB2_instances”
INST_SUB=$(wlookup -ar DB2InstanceManager|grep db2inst1|grep $ep_label|awk
‘{print $1}’)
# Subscribing DB2 resources to its ProfileManagers
wsub -r @ProfileManager:$INST_PM @DB2InstanceManager:$INST_SUB
EC=$?
if [ $EC -eq 0 ] ; then
echo “Instance object for EP $ep_label succesfully subscried to $INST_PM”
else
TMR_NAME=$(idlattr -tgv ‘wlookup ServerManagedNode‘ label string |sed -e
“s/\”//g”)
prof_mgr=‘wlookup -ar ProfileManager |grep $TMR|grep $TMR_NAME| grep
“DB2Manager-Instances”| awk ‘{print $1}’‘
wsub -r @ProfileManager:$prof_mgr @DB2InstanceManager:$INST_SUB
RC=$?
if [ $RC -eq 0 ]; then
echo “Instance object for EP $ep_label succesfully subscribed
to $prof_mgr” >> $LOG_FILE
else
echo “Failed to subscribe Instance object to $prof_mgr for EP $ep_label”
>> $LOG_FILE
exit 1
fi
fi
Appendix A. Configuration files and scripts
375
# Distributing ITM DB2 RMs to the specified resources
wdmdistrib -p $INST_RM -e -w -i @DB2InstanceManager:$INST_SUB >> $LOG_FILE
A.5 WebSphere Application Server monitoring
deployment files
The files described in this section are used to automate the creation and
deployment of WebSphere Application Server monitoring resources. All the files
can be found in the /mnt/tivoli/scripts/apps/WAS directory.
The scripts described in the following sections are all referenced from the script
used to create the Production_TL task library described in A.2.3, “load_tasks.sh”
on page 356.
A.5.1 create_app_server.sh
This script in Example A-22 creates IWSApplicationServer objects related to a
new endpoint.
In the APM plan for deployment, a task using this script is executed immediately
after installation of the WebSphere Application Server software package.
Example: A-22 create_app_server.sh
#!/bin/sh
#
# Usage: ./create_app_server.sh <serverName> <cellName> <nodeName> <hostname>
<ep_label>
if [ $# -ne 5 ] ; then
echo “Usage: ./create_app_server.sh <serverName> <cellName> <nodeName>
<hostname> <ep_label>”
exit 1
fi
SERVER=$1
CELL=$2
NODE=$3
HOSTNAME=$4
EP_LABEL=$5
wwebsphere -CreateAppServer \
376
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
-serverName $SERVER \
-cellName $CELL \
-nodeName $NODE \
-version 5.1 \
-rootDirectory /opt/IBM/WebSphere/AppServer \
-hostname $HOSTNAME \
-endpoint $EP_LABEL \
-policyRegion “WebSphere Application Servers”
A.5.2 itm_was_rm_distrib.sh
This script in Example A-23 is used to distribute WebSphere Application Server
monitoring profiles the newly created endpoints.
In the APM plan for deployment, a task using this script is executed immediately
after installation of the WebSphere Application Server software package.
Example: A-23 itm_was_rm_distrib.sh
#!/bin/sh
# This script is used by a Tivoli Task to distribute the ITM for
WebInfrastructure WAS Resource Model(s) to the IWSApplicationServer resource
discovered on an EP
# We created and customized a Tmw2kProfile to include specific RMs.
# Before the ITM RM distribution, the scripts subscribe the
IWSApplicationServer resource to the ProfileManager containing the Tmw2kProfile
to distribute
#
# We used the default Profile Manager created during the product installtion,
called “WebSphere Application Servers”
ep_label=$1
ep=$(echo $ep_label | cut -d “-” -f1)
SCRIPTS_LOC=”/mnt/code/tivoli/scripts”
LOG_FILE=”$SCRIPTS_LOC/apps/WAS/logs/was_rm_distrib.log”
TMR_NAME=$(idlattr -tgv ‘wlookup ServerManagedNode‘ label string |sed -e
“s/\”//g”)
# Setting variable for AppServer objects
WAS_PM=$(wlookup -ar ProfileManager|grep “WebSphere Application
Servers#$TMR_NAME-region”|grep $TMR|grep $TMR_NAME|awk ‘{print $1 “ “ $2 “ “
$3}’)
WAS_RM=$(wlookup -ar Tmw2kProfile|grep “WebSphere Application Servers
Profile”|grep $TMR|grep $TMR_NAME|awk ‘{print $1 “ “ $2 “ “ $3 “ “ $4}’)
Appendix A. Configuration files and scripts
377
WAS_SUB=$(wlookup -ar IWSApplicationServer|grep $ep|grep AppSvr|awk ‘{print
$1}’)
# Subscribing AppServer resource to its ProfileManagers
wsub -r @ProfileManager:”$WAS_PM” @IWSApplicationServer:$WAS_SUB
RC=$?
if [ $RC -eq 0 ] ; then
echo “$WAS_SUB subscribed to Profile Manager $WAS_PM”
else
WAS_PM=”WebSphere Application Servers”
WAS_RM=”WebSphere Application Servers Profile”
wsub -r @ProfileManager:”$WAS_PM” @IWSApplicationServer:$WAS_SUB
echo “$WAS_SUB subscribed to Profile Manager $WAS_PM”
fi
# Distributing ITM WAS RM to the specified resource
wdmdistrib -p “$WAS_RM” -e -w -i @IWSApplicationServer:$WAS_SUB >> $LOG_FILE
A.5.3 was_configure_tec_adapter.sh
This script in Example A-24 is used to configure the TEC adapter executing on
an IWSApplicationServer object in the Outlet Systems Management Solution.
Example: A-24 was_configure_tec_adapter.sh
#!/bin/sh
# Usage: ./was_configure_tec_adapter.sh IWSApplicationServer
if [ $# -ne 1 ] ; then
echo “Usage: ./was_configure_tec_adapter.sh IWSApplicationServer”
echo “Example: ./was_configure_tec_adapter.sh
AppSvr@<nodeName>@<cellName>@<serverName>”
exit 1
fi
SERVER=$1
wruntask -t Configure_WebSphere_TEC_Adapter \
-l “WebSphere Event Tasks” \
-h @IWSApplicationServer:$SERVER \
-a ““ -a EventServer \
-a Y \
-a Y \
-a Y \
-a N \
378
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
-a N\
-m 300
A.5.4 was_start_tec_adapter.sh
This script in Example A-25 is used to start the TEC adapter executing on an
IWSApplicationServer object.
Example: A-25 was_start_tec_adapter.sh
#!/bin/sh
# Usage: ./was_start_tec_adapter.sh IWSApplicationServer
if [ $# -ne 1 ] ; then
echo “Usage: ./was_start_tec_adapter.sh IWSApplicationServer”
echo “Example: ./was_start_tec_adapter.sh
AppSvr@<nodeName>@<cellName>@<serverName>”
exit 1
fi
SERVER=$1
wruntask -t Start_WebSphere_TEC_Adapter \
-l “WebSphere Event Tasks” \
-h @IWSApplicationServer:$SERVER \
-m 300
A.5.5 was_stop_tec_adapter.sh
This script Example A-26 is used to stop the TEC adapter executing on an
IWSApplicationServer object.
Example: A-26 was_stop_tec_adapter.sh
#!/bin/sh
# Usage: ./was_stop_tec_adapter.sh IWSApplicationServer
if [ $# -ne 1 ] ; then
echo “Usage: ./was_stop_tec_adapter.sh IWSApplicationServer”
echo “Example: ./was_stop_tec_adapter.sh
AppSvr@<nodeName>@<cellName>@<serverName>”
exit 1
fi
SERVER=$1
Appendix A. Configuration files and scripts
379
wruntask -t Stop_WebSphere_TEC_Adapter \
-l “WebSphere Event Tasks” \
-h @IWSApplicationServer:$SERVER \
-m 300
A.6 TMTP monitoring deployment scripts
The files described in this section are used to automate the creation and
deployment of TMTP related monitoring resources. All the files can be found in
the /mnt/tivoli/scripts/apps/DB2 directory. They are all referenced from the
script used to create the Production_TL task library described in A.2.3,
“load_tasks.sh” on page 356.
A.6.1 addtoagentgroup.sh
The following script in Example A-27 is used to add a new tmtp agent to an
existing agent group. This script must be executed at a system where the tmtp
command line interface has been installed. In the Outlet Systems Management
Solution the hubtmr system is used.
In the APM plan for deployment, a task using this script is executed immediately
after installation of the TMTP Agent software package.
Example: A-27 addtoagentgroup.sh
#Usage: ./addtoagentgroup <agentGroup> <agentName>
GROUPNAME=$1
AGENTNAME=$2
./tmtpcli.sh -AddToAgentGroup $GROUPNAME -Agents $AGENTNAME -Console
A.6.2 deployj2ee.sh
The following script in Example A-28 is used to deploy the J2EE monitoring
component to a TMTP Agent. This script must be executed at a system where
the tmtp command line interface has been installed. In the Outlet Systems
Management Solution the hubtmr system is used.
In the APM plan for deployment, a task using this script is executed immediately
after installation of the TMTP Agent software package.
Example: A-28 deployj2ee.sh
#user ./deployj2ee.sh <agentName> <WASHome> <ServerName> <nodeName>
<security_enabled>
380
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
AGENTNAME=$1
WASHOME=$2
SERVERNAME=$3
NODENAME=$4
SECURITY=$5
if [ $SECURITY -ne “TRUE” ]; then
./tmtpcli.sh -DeployJ2ee -AgentName $AGENTNAME -ServerType WebSphere
-Version 5.0 -ServerHome $WASHOME -ServerName $SERVERNAME -NodeName $NODENAME
-AutoRestart -Console
else
./tmtpcli.sh -DeployJ2ee -AgentName $AGENTNAME -ServerType WebSphere
-Version 5.0 -ServerHome $WASHOME -ServerName $SERVERNAME -NodeName $NODENAME
-AutoRestart -IsSecure -AdminUserName $ADMINUSERNAME -AdminPassword
$ADMINPASSWORD -Console
fi
A.7 Software Packages and related files
The following files constitute everything needed, except for code images, to
implement software packages that deploy and remove the components used in
the Outlet Systems Management Solution.
In the unpacked online material, the files can be found in the following
directories:
򐂰 Software Packages
/mnt/spd<vendor>/<product>/,version>/<component>/<platform>
򐂰 Response files
/mnt/rsp/<vendor>/<product>/,version>/<component>/<platform>
򐂰 Scripts and related files
/mnt/tools<vendor>/<product>/,version>/<component>/<platform>
A.7.1 Common scripts
These common scripts are used by the software packages to setup specific
environments.
In the online material, all these files are located in the following path relative to
the parent directory of the type of file: /common/UNIX.
Appendix A. Configuration files and scripts
381
do_it
This script in Example A-30 is used to invoke any executable that is started by a
software package. This allows for control of the logging, and easier debugging.
Example: A-29 do_it
#!/bin/sh
doit () {
echo “Executing command: “ $@
$@
rc=$?
echo “-- result was: “$rc
return $rc;
}
echo $0 “received parms:” $@
## do the install
doit $@
exit $?
java141_it
Example A-30 is used to setup a JRE 1.4.1 environment for installation
procedures that require Java2.
Example: A-30 java141_it
#!/bin/sh
doit () {
echo “Executing command: “ $@
$@
rc=$?
echo “-- result was: “$rc
return $rc;
}
## parm 1 is the fully qualified
(/opt/IBMJava2-141)
## parm 2 is the fully qualified
(/swdist/ihs_2047/IHS-2.0.47.1)
## parm 3 is the fully qualified
(/swdist/ihs_2047/ihs_2047.rsp))
## parm 4 is the installation path
382
path to Java 1.4 home directory
path to the setup.jar
path to the response file
(/opt/IBMIHS)
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
echo $0 “received parms:” $@
javahome=$1
javaroot=$javahome
javabin=$javahome/bin
export JAVA_HOME=$javahome
export JAVA_ROOT=$javaroot
export JAVA_BINDIR=$javabin
export PATH=$JAVA_HOME:$JAVA_BINDIR:$PATH
shift
## do the install
# doit “$JAVA_BINDIR/java -jar $2/setup.jar -silent -options $3”
doit “$JAVA_BINDIR/java “ $@
exit $?
A.7.2 IBM HTTP Server v2.0.47
The following files are used to create the software package for IBM HTTP Server
v2.0.47.
In the online material, all these files are located in the following path relative to
the parent directory of the type of file: /ibm/ihs/2047/all/Linux-IX86.
ihs_server.2.0.47.spd
Example A-31 is the software package definition for IBM HTTP Server v2.0.47.
Example: A-31 Software package for IBM HTTP Server v2 installation
“TIVOLI Software Package v4.2 - SPDF”
package
name = t_ihs_server
title = “IBM HTTP Server v2.0.47 for Linux”
version = 2.0.47
web_view_mode = hidden
undoable = o
committable = o
history_reset = y
save_default_variables = n
creation_time = “2004-11-18 22:56:18”
last_modification_time = “2004-11-18 23:04:20”
Appendix A. Configuration files and scripts
383
default_variables
work_dir = $(root_dir)/$(prod_name)
prod_name = ihs_2047
log_dir = $(root_dir)/log/$(prod_name)
img_dir = $(work_dir)/IHS-2.0.47.1
bin_dir = $(root_dir)/bin/$(os_family)
java_home = /opt/IBMJava2-141
test = false
root_dir = /swdist
inst_dir = /opt/IBMIHS
home_path = /mnt
prod_path = ibm/ihs/2047/all/$(os_name)-$(os_architecture)
src_base = $(home_path)/code
rsp_base
= $(home_path)/rsp
tool_base = $(home_path)/tools
tools_dir = $(tool_base)/$(prod_path)
svrlog_dir= $(home_path)/logs/$(prod_path)
end
log_object_list
location = $(log_dir)
unix_user_id = 0
unix_group_id = 0
unix_attributes = rwx,rx,
end
source_host_name = srchost
move_removing_host = y
no_check_source_host = y
lenient_distribution = y
default_operation = install
server_mode = all
operation_mode = preferably_not_transactional,preferably_undoable,force
log_path = /mnt/logs/ihs_server_2.0.47.log
post_notice = y
before_as_uid = 0
skip_non_zero = n
after_as_uid = 0
no_chk_on_rm = y
log_host_name = srchost
versioning_type = none
package_type = refresh
stop_on_failure = y
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
384
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
replace_if_newer = n
remove_if_modified = n
location = $(tool_base)
name = common
translate = n
destination = $(root_dir)/bin
descend_dirs = y
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
generic_container
caption = “on install”
stop_on_failure = y
condition = “$(operation_name)
== install”
check_disk_space
volume = /,500M
end
add_directory
stop_on_failure = y
add = y
replace_if_existing = n
replace_if_newer = n
remove_if_modified = n
location = $(rsp_base)
name = $(prod_path)
translate = n
destination = $(root_dir)/$(prod_name)
descend_dirs = n
remove_empty_dirs = n
Appendix A. Configuration files and scripts
385
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
add_file
replace_if_existing = y
replace_if_newer = y
remove_if_modified = n
name = ihs_server_2047.rsp
translate = n
destination = $(prod_name).rsp
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
end
execute_user_program
caption = unpack
condition = “$(test)
386
== false OR $(test)
== first”
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/tar -xvf $(work_dir)/$(prod_name).tar -C
$(work_dir)”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_unpack.out
error_file = $(log_dir)/$(prod_name)_unpack.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
corequisite_files
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = $(src_base)/$(prod_path)/HTTPServer.linux.2047.tar
translate = n
destination = $(work_dir)/$(prod_name).tar
compression_method = stored
rename_if_locked = n
end
end
end
end
Appendix A. Configuration files and scripts
387
execute_user_program
caption = “Silent Install”
transactional = n
during_install
path = $(bin_dir)/java141_it
arguments = “$(java_home) -jar $(img_dir)/setup.jar -silent
-options $(work_dir)/$(prod_name).rsp”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_install.out
error_file = $(log_dir)/$(prod_name)_install.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = n
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
execute_user_program
caption = “remove inst-directories”
condition = “NOT ( $(test) == true OR $(test) == first)”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “rm -r $(img_dir)”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
388
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
output_file = $(log_dir)/$(prod_name)_cleanup.out
error_file = $(log_dir)/$(prod_name)_cleanup.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
execute_user_program
caption = “Start server”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “$(inst_dir)/bin/apachectl start”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_start.out
error_file = $(log_dir)/$(prod_name)_start.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
Appendix A. Configuration files and scripts
389
end
end
end
generic_container
caption = “on remove”
stop_on_failure = y
condition = “$(operation_name)
== remove”
execute_user_program
caption = “stop server”
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = “$(inst_dir)/bin/apachectl stop”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_stop.out
error_file = $(log_dir)/$(prod_name)_stop.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
execute_user_program
caption = “silent remove”
390
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
transactional = n
during_remove
path = $(bin_dir)/java141_it
arguments = “$(java_home) -jar $(inst_dir)/_uninst/uninstall.jar
-silent”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_uninstall.out
error_file = $(log_dir)/$(prod_name)_uninstall.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
execute_user_program
caption = “remove directories”
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = “rm -r $(inst_dir)”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_remove.out
error_file = $(log_dir)/$(prod_name)_remove.err
output_file_append = n
Appendix A. Configuration files and scripts
391
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
end
end
ihs_server_2047.rsp
Example A-32 is the response file controlling the customization of IBM HTTP
Server v2.0.47.
Example: A-32 Response file for IHS 2.0.47 installation
###############################################################################
#####
# Response file for IHS installation on UNIX platforms.
#
# selectLocale.lang - {en,fr,de,it,ja,ko,pt_BR,zh,es, or zh_TW}
# ihs.installLocation - The install location for IHS
#
doc.active - IHS Documentation (defaults to true)
#
security.active - IHS SSL Security (defaults to true)
#
###############################################################################
#####
-W selectLocale.lang=en
-P ihs.installLocation=/opt/IBMIHS
#-P doc.active=false
#-P security.active=false
392
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
ihs_2047_linuxi386_install.sh
Example A-33 on page 393 is the script for installing IBM HTTP Server v2.0.47
Example: A-33 IHS 2.0.47 installation script
#!/bin/sh
doit () {
echo “Executing command: “ $1 $cmd
$1
rc=$?
echo “-- result was: “$rc
return $rc;
}
## parm 1 is the fully qualified
(/opt/IBMJava2-141)
## parm 2 is the fully qualified
(/swdist/ihs_2047/IHS-2.0.47.1)
## parm 3 is the fully qualified
(/swdist/ihs_2047/ihs_2047.rsp))
## parm 4 is the installation path
path to Java 1.4 home directory
path to the setup.jar
path to the response file
(/opt/IBMIHS)
echo $0 “received parms:” $@
javahome=$1
javaroot=$javahome
javabin=$javahome/bin
export JAVA_HOME=$javahome
export JAVA_ROOT=$javaroot
export JAVA_BINDIR=$javabin
export PATH=$JAVA_HOME:$JAVA_BINDIR:$PATH
## do the install
doit “$JAVA_BINDIR/java -jar $2/setup.jar -silent -options $3”
## start the apache server
doit “$4/bin/apachectl start”
## remove image directory
doit “rm -r $2”
exit $?
Appendix A. Configuration files and scripts
393
ihs_2047_linuxi386_uninstall.sh
Example A-34 on page 394 uninstalls IBM HTTP Server v2.0.47.
Example: A-34 IHS 2.0.47 uninstallation script
#!/bin/sh
doit () {
echo “Executing command: “ $1
$1
rc=$?
echo “-- result was: “ $rc;
}
## parm 1 is the fully qualified path to Java 1.4 home directory
(/opt/IBMJava2-141)
## parm 2 is the fully qualified path to the setup.jar
(/swdist/ihs_2047/IHS-2.0.47.1)
## parm 3 is the fully qualified path to the response file
(/swdist/ihs_2047/ihs_2047.rsp))
## parm 4 is the installation directory (/opt/IBMIHS)
echo $0 “ received parms: “
$@
javahome=$1
javaroot=$javahome
javabin=$javahome/bin
export JAVA_HOME=$javahome
export JAVA_ROOT=$javaroot
export JAVA_BINDIR=$javabin
export PATH=$JAVA_HOME:$JAVA_BINDIR:$PATH
## stop the apache server
doit “$4/bin/apachectl stop”
## uninstall
doit “$JAVA_BINDIR/java -jar $4/_uninst/uninstall.jar -silent”
## remove filesystems
doit “rm -r $4”
exit $?
394
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
A.7.3 WebSphere Message Queuing Server v5.3
The following files are used to install and configure WebSphere Message
Queuing Server v5.3 and related fixpacks.
In the online material, all these files are located in the following path relative to
the parent directory of the type of file: /websphere/mq/530/server/Linux-IX86.
mq_server.5.3.0.spd
Example A-35 is the software package for installation of WebSphere Message
Queuing Server v5.3. Besides installing the product, the software package also
configures the required users and groups.
Example: A-35 mq_server.5.3.0.spd
“TIVOLI Software Package v4.2.1 - SPDF”
package
name = t_mq_server
title = “MQServer V5.3”
version = 5.3.0
web_view_mode = hidden
undoable = o
committable = o
history_reset = n
save_default_variables = n
creation_time = “2004-12-02 17:03:20”
last_modification_time = “2004-12-02 17:03:20”
default_variables
prod_name = mq_server_530
work_dir = $(root_dir)/$(prod_name)
log_dir = $(root_dir)/log/$(prod_name)
img_dir = $(work_dir)/image
bin_dir = $(root_dir)/bin/$(os_family)
gz_file = C48UBML_WASMQ-Linux-5.3.0.2.tar.gz
tar_file = MQ53Server_LinuxIntel.tar
root_dir = /swdist
home_path = /mnt
prod_path = websphere/mq/530/server/$(os_name)-$(os_architecture)
src_dir = $(home_path)/code/$(prod_path)
rsp_dir
= $(home_path)/rsp/$(prod_path)
tool_base = $(home_path)/tools
tools_dir = $(tool_base)/$(prod_path)
unpack = yes
cleanup = yes
end
Appendix A. Configuration files and scripts
395
log_object_list
location = $(log_dir)
unix_user_id = 0
unix_group_id = 0
unix_attributes = rwx,rx,
end
source_host_name = srchost
move_removing_host = y
no_check_source_host = y
lenient_distribution = n
default_operation = install
server_mode = all
operation_mode = not_transactional
log_path = /mnt/logs/mq_server_530.log
post_notice = y
before_as_uid = 0
skip_non_zero = n
after_as_uid = 0
no_chk_on_rm = y
log_host_name = srchost
versioning_type = none
package_type = refresh
sharing_control = none
stop_on_failure = y
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(tool_base)
name = common
translate = n
destination = $(root_dir)/bin
descend_dirs = y
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
396
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
generic_container
caption = “on install”
stop_on_failure = y
condition = “$(operation_name)
== install”
check_disk_space
volume = /,250M
end
execute_user_program
caption = “Create mqm IDs”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = $(work_dir)/mqusers.sh
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_users.out
error_file = $(log_dir)/$(prod_name)_users.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
corequisite_files
Appendix A. Configuration files and scripts
397
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = $(tools_dir)/mqusers.sh
translate = n
destination = $(work_dir)/mqusers.sh
compression_method = stored
rename_if_locked = n
end
end
end
end
execute_user_program
caption = uncompress
condition = “$(unpack) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/gunzip -dcfv $(work_dir)/$(prod_name).tar.gz”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_uncompress.out
error_file = $(log_dir)/$(prod_name)_uncompress.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
398
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
corequisite_files
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = $(src_dir)/$(gz_file)
translate = n
destination = $(work_dir)/$(prod_name).tar.gz
compression_method = stored
rename_if_locked = n
end
end
end
end
execute_user_program
caption = uncompress
condition = “$(unpack) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/tar -xvf $(work_dir)/$(prod_name).tar”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_unpack1.out
error_file = $(log_dir)/$(prod_name)_unpack1.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
Appendix A. Configuration files and scripts
399
failure = 1,65535
end
end
end
add_directory
stop_on_failure = n
condition = “$(unpack) == yes”
add = y
replace_if_existing = n
replace_if_newer = n
remove_if_modified = n
location = $(tool_base)
name = $(prod_path)
translate = n
destination = $(work_dir)/image
descend_dirs = n
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
execute_user_program
caption = unpack
condition = “$(unpack) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/tar -C $(img_dir) -xvf $(work_dir)/$(tar_file)”
inhibit_parsing = n
400
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
working_dir = $(img_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_unpack2.out
error_file = $(log_dir)/$(prod_name)_unpack2.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
execute_user_program
caption = “Accept MQ License”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “$(img_dir)/mqlicense.sh -accept”
inhibit_parsing = n
working_dir = $(img_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_license.out
error_file = $(log_dir)/$(prod_name)_license.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
Appendix A. Configuration files and scripts
401
exit_codes
success = 0,9
success = 10,65535
end
end
end
install_rpm_package
caption = “MQServer V5”
rpm_options = -vv
rpm_install_type = install
rpm_install_force = n
rpm_install_nodeps = n
rpm_remove_nodeps = n
rpm_report_log = y
rpm_file
image_dir = $(img_dir)
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = MQSeriesSDK-5.3.0-2
rpm_package_file = MQSeriesSDK-5.3.0-2.i386.rpm
end
rpm_file
image_dir = $(img_dir)
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = MQSeriesRuntime-5.3.0-2
rpm_package_file = MQSeriesRuntime-5.3.0-2.i386.rpm
end
rpm_file
image_dir = $(img_dir)
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = MQSeriesServer-5.3.0-2
rpm_package_file = MQSeriesServer-5.3.0-2.i386.rpm
end
402
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
rpm_file
image_dir = $(img_dir)
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = MQSeriesSamples-5.3.0-2
rpm_package_file = MQSeriesSamples-5.3.0-2.i386.rpm
end
rpm_file
image_dir = $(img_dir)
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = MQSeriesJava-5.3.0-2
rpm_package_file = MQSeriesJava-5.3.0-2.i386.rpm
end
end
execute_user_program
caption = “Set purchased license units”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/opt/mqm/bin/setmqcap 4”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_purchase.out
error_file = $(log_dir)/$(prod_name)_purchase.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
Appendix A. Configuration files and scripts
403
failure = 1,65535
end
end
end
execute_user_program
caption = cleanup
condition = “$(cleanup) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/rm -r $(work_dir)”
inhibit_parsing = n
working_dir = $(root_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_cleanup.out
error_file = $(log_dir)/$(prod_name)_cleanup.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
end
end
404
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
mq_users.sh
Example A-36 is the script for creating users and groups required by WebSphere
Message Queuing Server v5.3.
Example: A-36 Script for creating user and group for WebSphere MQ
#!/bin/sh
#
# create group and user for mq
#
groupadd mqm
useradd -g mqm -m -d /home/mqm mqm
exit 0
mq_server_53_install.sh
Example A-37 is the installation procedure for WebSphere Message Queuing
Server v5.3.
Example: A-37 WebSphere MQ Server installation script
#!/bin/sh
doit () {
echo “
about to execute: “ $1
$1
rc=$?
echo “
result was: “$rc
return $rc
}
imgdir=$1
instdir=$2
## validate
if [ ! ${imgdir} ]; then
echo “ image directory NOT specified”
exit 4
else
if [ ! -d ${imgdir} ]; then
echo “ image directory \”${imgdir}\” does not exist”
exit 4
else
echo “ using image directory \”${imgdir}\””
fi
fi
Appendix A. Configuration files and scripts
405
if [ !
echo
exit
else
echo
fi
${instdir} ]; then
“ installation directory NOT specified”
4
“ using installation directory \”${instdir}\””
#
# create group and user for mq
mqusr=”mqm”
mqgrp=”mqm”
#
if [ x‘grep ${mqgrp}: /etc/group‘ = x ]; then
echo “ creating group: \”${mqgrp}\””
doit “groupadd ${mqgrp}”
fi
# add mquser
if [ x‘grep ${mqusr}: /etc/passwd‘ = x ]; then
echo “ adding user: \”${mquser}\””
doit “useradd -g ${mqgrp} -m -d /home/${mquser} ${mqusr}”
fi
# accept licenses
echo “ accepting license”
doit “$imgdir/mqlicense.sh -accept”
### install rpm packages
echo “ installing RPM packages”
cmd=”/bin/rpm -ivh --force”
doit “ ${cmd}
${imgdir}/MQSeriesSDK-5.3.0-2.i386.rpm
${imgdir}/MQSeriesRuntime-5.3.0-2.i386.rpm
${imgdir}/MQSeriesServer-5.3.0-2.i386.rpm
${imgdir}/MQSeriesSamples-5.3.0-2.i386.rpm
${imgdir}/MQSeriesJava-5.3.0-2.i386.rpm
${imgdir}/MQSeriesMan-5.3.0-2.i386.rpm
“
### set installed purchased licenses
echo “ setting purchased licenses to: \”4\””
doit “${instdir}/bin/setmqcap 4”
exit 0
406
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
mq_server_53_uninstall.sh
Example A-38 is the uninstallation procedure for WebSphere Message Queuing
Server v5.3.
Example: A-38 Script for uninstallation of WebSphere MQ server
#!/bin/sh
doit () {
echo “
about to execute: “ $1
$1
rc=$?
echo “
-- result was: “$rc
return $rc
}
imgdir=$2
instdir=$1
## validate
if [ ! ${instdir} ]; then
echo “ installation directory NOT specified”
exit 4
else
if [ ! -d ${instdir} ]; then
echo “ installation directory \”${instdir}\” does not exist”
exit 4
else
echo “ using installation directory \”${instdir}\””
fi
fi
#
#
# remove group and user for mq
mqusr=”mqm”
mqgrp=”mqm”
# delete user
if [ x‘grep ${mqusr}: /etc/passwd‘ = x ]; then
echo “ removing user \”${mqusr}\””
doit “userdel -r ${mqusr}”
fi
# delete group
Appendix A. Configuration files and scripts
407
if [ x‘grep ${mqgrp}: /etc/group‘ != x ]; then
echo “ removing group \”${mqgrp}\””
doit “groupdel ${mqgrp}”
fi
### remove rpm packages
echo “ removing rpm packages”
cmd=”/bin/rpm -evv “
doit “${cmd}
${imgdir}MQSeriesSDK-5.3.0-2.i386.rpm
${imgdir}MQSeriesRuntime-5.3.0-2.i386.rpm
${imgdir}MQSeriesServer-5.3.0-2.i386.rpm
${imgdir}MQSeriesSamples-5.3.0-2.i386.rpm
${imgdir}MQSeriesJava-5.3.0-2.i386.rpm
${imgdir}MQSeriesMan-5.3.0-2.i386.rpm
“
### remove install directory
if [ -d ${instdir} ]; then
echo “ removing installation directory \”${instdir}\””
doit “/bin/rm -r ${instdir}”
fi
if [ -d /var/mqm ]; then
echo “ removing installation directory \”/var/mqm\””
doit “/bin/rm -r /var/mqm”
fi
exit 0
A.7.4 WebSphere Message Queuing Server v5.3 Fixpack 8
To install Fixpack 8 for WebSphere Message Queuing Server v5.3, the files in
this section are provided.
In the online material, all these files are located in the following path relative to
the parent directory of the type of file:
/websphere/mq/530_fp8/server/Linux-IX86.
mq_server.5.3.0_fp8.spd
Example A-39 is the software package for installing and removing Fixpack 8 for
WebSphere Message Queuing Server v5.3.
Example: A-39 Software Package mq_server.5.3.0_fp8.spd
“TIVOLI Software Package v4.2.1 - SPDF”
408
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
package
name = t_mq_server
title = “MQServer V5.3 fixpack 8”
version = 5.3.0_fp8
web_view_mode = hidden
undoable = o
committable = o
history_reset = n
save_default_variables = n
creation_time = “2004-11-24 01:10:26”
last_modification_time = “2004-11-24 01:10:26”
default_variables
prod_name = mq_server_530_fp08
work_dir = $(root_dir)/$(prod_name)
log_dir = $(root_dir)/log/$(prod_name)
img_dir = $(work_dir)/image
bin_dir = $(root_dir)/bin/$(os_family)
tar_file = U497537.gskit.tar
gz_file = WASMQ-CDS8-Linux-U497537.gskit.tar.gz
root_dir = /swdist
home_path = /mnt
prod_path =
websphere/mq/530_fp8/server/$(os_name)-$(os_architecture)
src_dir = $(home_path)/code/$(prod_path)
rsp_dir
= $(home_path)/rsp/$(prod_path)
tool_base = $(home_path)/tools
tools_dir = $(tool_base)/$(prod_path)
unpack = yes
cleanup = yes
end
log_object_list
location = $(log_dir)
unix_user_id = 0
unix_group_id = 0
unix_attributes = rwx,rx,
end
source_host_name = srchost
move_removing_host = y
no_check_source_host = y
lenient_distribution = n
default_operation = install
server_mode = all
operation_mode = not_transactional
log_path = /mnt/logs/mq_server_530_fp08.log
post_notice = y
Appendix A. Configuration files and scripts
409
before_as_uid = 0
skip_non_zero = n
after_as_uid = 0
no_chk_on_rm = y
log_host_name = srchost
versioning_type = none
package_type = patch
sharing_control = none
stop_on_failure = y
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(tool_base)
name = common
translate = n
destination = $(root_dir)/bin
descend_dirs = y
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
generic_container
caption = “on install”
stop_on_failure = y
condition = “$(operation_name)
== install”
check_disk_space
volume = /,250M
end
410
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
execute_user_program
caption = uncompress
condition = “$(unpack) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/gunzip -dvf $(work_dir)/$(prod_name).tar.gz”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_uncompress.out
error_file = $(log_dir)/$(prod_name)_uncompress.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
corequisite_files
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = $(src_dir)/$(gz_file)
translate = n
destination = $(work_dir)/$(prod_name).tar.gz
compression_method = stored
rename_if_locked = n
end
end
end
Appendix A. Configuration files and scripts
411
end
add_directory
stop_on_failure = n
condition = “$(unpack) == yes”
add = y
replace_if_existing = n
replace_if_newer = n
remove_if_modified = n
location = $(tool_base)
name = $(prod_path)
translate = n
destination = $(work_dir)/image
descend_dirs = n
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
execute_user_program
caption = unpack
condition = “$(unpack) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/tar -C $(img_dir) -xvf
$(work_dir)/$(prod_name).tar”
inhibit_parsing = n
working_dir = $(img_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
412
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
output_file = $(log_dir)/$(prod_name)_unpack.out
error_file = $(log_dir)/$(prod_name)_unpack.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
install_rpm_package
caption = “MQServer V5”
rpm_options = -vv
rpm_install_type = install
rpm_install_force = n
rpm_install_nodeps = n
rpm_remove_nodeps = n
rpm_report_log = y
rpm_file
image_dir = $(img_dir)
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = MQSeriesSDK-U497537-5.3.0-8
rpm_package_file = MQSeriesSDK-U497537-5.3.0-8.i386.rpm
end
rpm_file
image_dir = $(img_dir)
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = MQSeriesRuntime-U497537-5.3.0-8
rpm_package_file = MQSeriesRuntime-U497537-5.3.0-8.i386.rpm
end
Appendix A. Configuration files and scripts
413
rpm_file
image_dir = $(img_dir)
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = MQSeriesServer-U497537-5.3.0-8
rpm_package_file = MQSeriesServer-U497537-5.3.0-8.i386.rpm
end
rpm_file
image_dir = $(img_dir)
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = MQSeriesSamples-U497537-5.3.0-8
rpm_package_file = MQSeriesSamples-U497537-5.3.0-8.i386.rpm
end
rpm_file
image_dir = $(img_dir)
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = MQSeriesJava-U497537-5.3.0-8
rpm_package_file = MQSeriesJava-U497537-5.3.0-8.i386.rpm
end
end
execute_user_program
caption = cleanup
condition = “$(cleanup) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/rm -r $(work_dir)”
inhibit_parsing = n
working_dir = $(root_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_cleanup.out
error_file = $(log_dir)/$(prod_name)_cleanup.err
414
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
end
end
mq_server_538_install.sh
Example A-40 is the installation script for installing WebSphere Message
Queuing Server v5.3 Fixpack 8.
Example: A-40 mq_server_538_install.sh
#!/bin/sh
doit () {
echo “
about to execute: “ $1
$1
rc=$?
echo “
-- result was: “$rc
return $rc
}
imgdir=$1
## validate
if [ ! ${imgdir} ]; then
echo “ image directory NOT specified”
exit 4
else
Appendix A. Configuration files and scripts
415
if [ !
echo
exit
else
echo
fi
-d ${imgdir} ]; then
“ image directory \”${imgdir}\” does not exist”
4
“
using image directory \”${imgdir}\””
fi
### install rpm packages
echo “installing rpm packages”
cmd=”/bin/rpm -ivh “
doit “ ${cmd}
${imgdir}/MQSeriesSDK-U497537-5.3.0-8.i386.rpm
${imgdir}/MQSeriesRuntime-U497537-5.3.0-8.i386.rpm
${imgdir}/MQSeriesServer-U497537-5.3.0-8.i386.rpm
${imgdir}/MQSeriesSamples-U497537-5.3.0-8.i386.rpm
${imgdir}/MQSeriesJava-U497537-5.3.0-8.i386.rpm
${imgdir}/MQSeriesMan-U497537-5.3.0-8.i386.rpm
“
exit 0
mq_server_538_uninstall.sh
Example A-41 is the script for removing WebSphere Message Queuing Server
v5.3 Fixpack 8.
Example: A-41 mq_server_538_uninstall.sh
#!/bin/sh
doit () {
echo “
about to execute: “ $1
$1
rc=$?
echo “
--result was: “$rc
return $rc
}
### install rpm packages
echo “removing rpm packages”
cmd=”/bin/rpm -evv “
doit “ ${cmd}
${imgdir}MQSeriesSDK-U497537-5.3.0-8.i386.rpm
${imgdir}MQSeriesRuntime-U497537-5.3.0-8.i386.rpm
${imgdir}MQSeriesServer-U497537-5.3.0-8.i386.rpm
416
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
${imgdir}MQSeriesSamples-U497537-5.3.0-8.i386.rpm
${imgdir}MQSeriesJava-U497537-5.3.0-8.i386.rpm
${imgdir}MQSeriesMan-U497537-5.3.0-8.i386.rpm
“
exit 0
A.7.5 WebSphere Application Server v5.1
The files in this section are used to define and build a software package capable
of installing and uninstalling WebSphere APplication Server v5.1, including basic
configuration of performance metrics settings and security.
In the online material, all these files are located in the following path relative to
the parent directory of the type of file:
/websphere/was/510/appserver/Linux-IX86.
was_appserver.5.1.0.spd
Example A-42 is the software package definition for the WebSphere Application
Server 5.1 package.
Example: A-42 Software package for WAS 5.1
“TIVOLI Software Package v4.2.1 - SPDF”
package
name = was_appserver
title = “WebSphere Application Server Enterprise Edition v5.1”
version = 5.1.0
web_view_mode = hidden
undoable = n
committable = o
history_reset = y
save_default_variables = n
creation_time = “2004-12-02 19:11:03”
last_modification_time = “2004-12-02 19:11:03”
default_variables
wasuser = root
waspassword = smartway
wasserver = server1
inst_ems = no
work_dir = $(root_dir)/$(prod_name)
prod_name = was_appserver_510
log_dir = $(root_dir)/log/$(prod_name)
img_base = $(work_dir)/image
Appendix A. Configuration files and scripts
417
img_dir = $(img_base)/linuxi386
bin_dir = $(root_dir)/bin/$(os_family)
root_dir = /swdist
inst_dir = /opt/IBM/WebSphere/AppServer
tar_file = C53IPML-WAS-510-LinuxIX86.tar
rsp_file = was_appserver_510.rsp
home_path = /mnt
prod_path =
websphere/was/510/appserver/$(os_name)-$(os_architecture)
src_base = $(home_path)/code
src_dir
= $(src_base)/$(prod_path)
rsp_base = $(home_path)/rsp
tool_base = $(home_path)/tools
tools_dir = $(tool_base)/$(prod_path)
unpack = yes
cleanup = yes
enable_pmi = yes
enable_security = yes
end
log_object_list
location = $(log_dir)
unix_user_id = 0
unix_group_id = 0
unix_attributes = rwx,rx,
end
source_host_name = srchost
move_removing_host = y
no_check_source_host = y
lenient_distribution = y
default_operation = install
server_mode = all
operation_mode = not_transactional,force
log_path = /mnt/logs/was_appserver_510.log
post_notice = y
before_as_uid = 0
skip_non_zero = n
after_as_uid = 0
no_chk_on_rm = y
log_host_name = srchost
versioning_type = none
package_type = refresh
sharing_control = none
stop_on_failure = y
add_directory
418
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(tool_base)
name = common
translate = n
destination = $(root_dir)/bin
descend_dirs = y
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(src_base)
name = $(prod_path)
translate = n
destination = $(root_dir)/$(prod_name)
descend_dirs = n
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
Appendix A. Configuration files and scripts
419
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
generic_container
caption = “on install”
stop_on_failure = y
condition = “$(operation_name)
== install”
check_disk_space
volume = /,1500M
end
add_directory
stop_on_failure = n
condition = “$(unpack) == yes”
add = y
replace_if_existing = n
replace_if_newer = n
remove_if_modified = n
location = $(tool_base)
name = $(prod_path)
translate = n
destination = $(img_base)
descend_dirs = n
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
420
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
end
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(tool_base)
name = $(prod_path)
translate = n
destination = $(root_dir)/$(prod_name)
descend_dirs = n
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = was_appserver_510_install.sh
translate = n
destination = $(prod_name)_install.sh
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
Appendix A. Configuration files and scripts
421
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = mod_was_server_JVM_process.sh
translate = n
destination = mod_was_server_JVM_process.sh
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = mod_was_pmirm_settings.sh
translate = n
destination = mod_was_pmirm_settings.sh
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
422
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = enable_was_security.sh
translate = n
destination = enable_was_security.sh
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = enable_was_security.jacl
translate = n
destination = enable_was_security.jacl
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
Appendix A. Configuration files and scripts
423
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
end
execute_user_program
caption = “create users and groups”
condition = “$(inst_ems) == yes”
transactional = y
during_install
path = $(bin_dir)/do_it
arguments = $(work_dir)/$(prod_name)_install.sh
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_prepare.out
error_file = $(log_dir)/$(prod_name)_prepare.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = y
retry = 1
exit_codes
success = 9,9
success_reboot_now = 0,0
warning = 1,8
failure = 10,65535
424
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
end
end
end
execute_user_program
caption = unpack
condition = “$(unpack) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/tar -xvf $(work_dir)/$(prod_name).tar -C
$(img_base)”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_unpack.out
error_file = $(log_dir)/$(prod_name)_unpack.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
corequisite_files
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = $(src_dir)/$(tar_file)
translate = n
destination = $(work_dir)/$(prod_name).tar
compression_method = stored
Appendix A. Configuration files and scripts
425
rename_if_locked = n
end
end
end
end
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(rsp_base)
name = $(prod_path)
translate = n
destination = $(root_dir)/$(prod_name)
descend_dirs = n
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = $(rsp_file)
translate = n
destination = $(prod_name).rsp
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
426
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
end
execute_user_program
caption = “Silent Install”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “$(img_dir)/install -options
$(work_dir)/$(prod_name).rsp”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_install.out
error_file = $(log_dir)/$(prod_name)_install.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,1
failure = 2,65535
end
Appendix A. Configuration files and scripts
427
end
end
execute_user_program
caption = “jvm process settings”
condition = “$(enable_pmi) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “$(work_dir)/mod_was_server_JVM_process.sh
$(inst_dir)/config/cells/$(computer_name)/nodes/$(computer_name)/servers/$(wass
erver)/server.xml”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_install_jvm_settings.out
error_file = $(log_dir)/$(prod_name)_install_jvm_settings.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,1
failure = 2,65535
end
end
end
execute_user_program
caption = “pmirm settings”
condition = “$(enable_pmi) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
428
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
arguments = “$(work_dir)/mod_was_pmirm_settings.sh
$(inst_dir)/config/cells/$(computer_name)/pmirm.xml”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_install_pmirm_settings.out
error_file = $(log_dir)/$(prod_name)_install_pmirm_settings.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,1
failure = 2,65535
end
end
end
execute_user_program
caption = “enable security”
condition = “$(enable_security) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “$(work_dir)/enable_was_security.sh
$(work_dir)/enable_was_security.jacl”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_install_pmirm_settings.out
error_file = $(log_dir)/$(prod_name)_install_pmirm_settings.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
Appendix A. Configuration files and scripts
429
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,1
failure = 2,65535
end
end
end
execute_user_program
caption = cleanup
condition = “$(cleanup) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/rm -r $(img_dir)”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_cleanup.out
error_file = $(log_dir)/$(prod_name)_cleanup.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,127
failure = 128,65535
end
end
end
430
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
execute_user_program
caption = “Start server”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “$(inst_dir)/bin/startServer.sh $(wasserver) -user
$(wasuser) -password $(waspassword)”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_startserver.out
error_file = $(log_dir)/$(prod_name)_startserver.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success
warning
success
failure
end
=
=
=
=
0,0
1,110
111,111
1,65535
end
end
end
generic_container
caption = “on remove”
stop_on_failure = y
condition = “$(operation_name)
== remove”
execute_user_program
caption = “stop server”
transactional = n
Appendix A. Configuration files and scripts
431
during_remove
path = $(bin_dir)/do_it
arguments = “$(inst_dir)/bin/stopServer.sh $(wasserver) -user
$(wasuser) -password $(waspassword)”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_stopserver.out
error_file = $(log_dir)/$(prod_name)_stopserver.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,246
failure = 247,65535
end
end
end
execute_user_program
caption = “silent remove”
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = “$(inst_dir)/_uninst/uninstall -silent”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_uninstall.out
error_file = $(log_dir)/$(prod_name)_uninstall.err
output_file_append = n
error_file_append = n
432
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,7
failure = 8,65535
end
end
end
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(tool_base)
name = $(prod_path)
translate = n
destination = $(root_dir)/$(prod_name)
descend_dirs = n
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
add_file
replace_if_existing = y
replace_if_newer = n
Appendix A. Configuration files and scripts
433
remove_if_modified = n
name = was_appserver_510_uninstall.sh
translate = n
destination = $(prod_name)_uninstall.sh
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_attributes = rwx,rx,rx
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
end
execute_user_program
caption = “remove groups and users”
condition = “$(inst_ems) == yes”
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = $(work_dir)/$(prod_name)_uninstall.sh
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_remove_users.out
error_file = $(log_dir)/$(prod_name)_remove_users.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
434
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
retry = 1
exit_codes
success = 0,0
success = 1,65535
end
end
end
execute_user_program
caption = “remove inst_dir”
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = “/bin/rm -r $(inst_dir)”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_remove.out
error_file = $(log_dir)/$(prod_name)_remove.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,127
success = 128,65535
end
end
end
execute_user_program
caption = “remove mqm_dir”
condition = “$(inst_ems) == yes”
Appendix A. Configuration files and scripts
435
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = “/bin/rm -r /var/mqm”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_remove_mqm.out
error_file = $(log_dir)/$(prod_name)_remove_mqm.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
success = 1,65535
end
end
end
execute_user_program
caption = “remove wemps_dir”
condition = “$(inst_ems) == yes”
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = “/bin/rm -r /var/wemps”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_remove_wemps.out
error_file = $(log_dir)/$(prod_name)_remove_wemps.err
output_file_append = n
436
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
success = 1,65535
end
end
end
execute_user_program
caption = “remove work_dir”
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = “/bin/rm -r $(work_dir)”
inhibit_parsing = n
working_dir = $(root_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_remove_workdir.out
error_file = $(log_dir)/$(prod_name)_remove_workdir.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
success = 1,65535
end
end
end
Appendix A. Configuration files and scripts
437
end
end
was_appserver_510.rsp
Example A-43 is the response file controlling the installation and basic
customization of WebSphere Application Server 5.1.
Example: A-43 Response file for WAS 5.1 installation
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
*******************************************
#
#
#
#
*******************************************
This value is required.
PLEASE DO NOT REMOVE THIS VALUE.
*******************************************
Response file for WebSphere Application Server 5.1 Install
Please follow the comments to use the response file and
understand the various options. You must carefully complete
or change the various values. If the values are not completed
properly, the install may be unsuccessful.
NOTE: This file is for silent install only.
IMPORTANT: ALL VALUES MUST BE ENCLOSED IN DOUBLE QUOTES ( ““ ).
*******************************************
-W setupTypes.selectedSetupTypeId=”custom”
#
#
#
#
*******************************************
Below is the beginning of the response file that needs to be
filled in by the user.
*******************************************
#
#
#
#
*******************************************
The below value specifies silent install. This value
indicates that the install will be silent.
*******************************************
-silent
438
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
#
#
#
#
#
#
#
*******************************************
WebSphere Application Server Install Location
Please specify the destination directory for the WebSphere Application
Server installation. You will need to change this for UNIX
platforms. As an example for AIX, the value may be
“/usr/WebSphere/AppServer”
*******************************************
-P wasBean.installLocation=”$(inst_dir)”
#
#
#
#
#
#
#
#
#
#
*******************************************
IBM HTTP Server Install Location
Please specify the destination directory for the IBM HTTP Server
installation. This value will need to be completed if you
choose to install IBM HTTP Server. If you choose to not install IBM
HTTP Server, then this value is not required. You will need to change
the default value below for UNIX platforms. As an example for AIX, the
value may be “/usr/IBMHTTPServer”
*******************************************
-P ihsFeatureBean.installLocation=”/opt/IBMIHS”
#
#
#
#
#
#
#
#
*******************************************
Below are the features that you may choose to install.
Set the following values to “true” or “false,” depending upon whether
you want to install the following features or not.
NOTE: The default settings for features in this response file
detail the defaults for a typical installation.
*******************************************
# *******************************************
# Install Server
# *******************************************
-P serverBean.active=”true”
# *******************************************
#
# Begin Features for Administration
#
Appendix A. Configuration files and scripts
439
# *******************************************
# *********
# Install Administration
# *********
-P adminBean.active=”true”
#
#
#
#
#
*********
The next 2 features are part of Administration. In order for any of these
features to be installed, the property to install Administration denoted
above must be set to “true.”
*********
# *********
# Install Admin Scripting
# *********
-P adminScriptingFeatureBean.active=”true”
# *********
# Install Administrative Console
# *********
-P adminConsoleFeatureBean.active=”true”
# *******************************************
#
# End Features for Administration
#
# *******************************************
# *******************************************
#
# Begin Features for Application Assembly and Deployment Tools
#
# *******************************************
# *********
# Install Application Assembly and Deployment Tools
# *********
-P applicationAndAssemblyToolsBean.active=”true”
#
#
#
#
440
*********
The next 3 features are part of Application Assembly and Deployment
Tools. In order for any of these features to be installed,
the property to install Application And Assembly Tools denoted
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
# above must be set to “true.”
# *********
# *********
# Install Deploy Tool
# *********
-P deployToolBean.active=”true”
# *********
# Install Ant Utilities
# *********
-P antUtilityBean.active=”true”
# *******************************************
#
# End Features for Application Assembly and Deployment Tools
#
# *******************************************
# *******************************************
#
# Begin Features for Embedded Messaging
#
# *******************************************
# *********
# Install Embedded Messaging
# *********
-P mqSeriesBean.active=”false”
#
#
#
#
#
#
#
#
#
*********
The next three features are for Embedded Messaging. In order to install
any of the following three subfeatures, the property to install Embedded
Messaging denoted above must be set to “true.”
IMPORTANT NOTE: If you do not want to install Embedded Messaging, please
ensure all of the following options are set to “false” as well as the above
option.
*********
# *********
# Install Embedded Messaging Server and Client
#
# You may only install the Embedded Messaging Server and Client or the Embedded
Appendix A. Configuration files and scripts
441
# Messaging client below. If you set the Server and Client to “true,” please
# ensure that the Client only option below is set to “false.” The same applies
# if you set the Client only option to “true,” please ensure the server and
client
# option is set to “false.”
# *********
-P mqSeriesServerBean.active=”false”
#
#
#
#
#
#
#
#
*********
Embedded Messaging Server and Client install location
If you choose to install Embedded Messaging Server and Client above, please
specify an install location below for Windows platforms only.
The directory may not be configured by the user for UNIX platforms
as it is predetermined.
*********
-P mqSeriesServerBean.installLocation=”/opt/IBM/WebSphereMQ”
# *********
# Install Embedded Messaging Client only
# *********
-P mqSeriesClientBean.active=”false”
#
#
#
#
#
#
#
#
*********
Embedded Messaging Client Only install location
If you choose to install Embedded Messaging Client only above, please
specify an install location below for Windows platforms only.
The directory may not be configured by the user for UNIX platforms
as it is predetermined.
*********
-P mqSeriesClientBean.installLocation=”/opt/IBM/WebSphereMQ”
# *********
# Install Message-driven beans Samples
# *********
-P mqSeriesSamplesBean.active=”false”
# *******************************************
#
# End Features for Embedded Messaging
#
# *******************************************
442
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
# *******************************************
# Install IHS WebServer 1.3.28
# *******************************************
-P ihsFeatureBean.active=”false”
# *******************************************
#
# Begin Features for Web Server Plugins
#
# *******************************************
# *********
# Install Web Server Plugins
# *********
-P pluginBean.active=”true”
#
#
#
#
#
#
*********
The next 5 features are part of Web Server Plugins.
In order for any of these features to be installed,
the property to install Web Server Plugins denoted
above must be set to “true.”
*********
# *********
# Install IBM HTTP Server v1.3 Plugin
# *********
-P ihsPluginBean.active=”false”
# *********
# Install IBM HTTP Server v2.0 Plugin
# *********
-P ihs20PluginBean.active=”true”
# *********
# Install Apache Web Server v1.3 Plugin
# *********
-P apachePluginBean.active=”false”
# *********
# Install Apache Web Server v2.0 Plugin
# *********
Appendix A. Configuration files and scripts
443
-P apache20PluginBean.active=”false”
# *********
# Install Microsoft Internet Information Services (IIS) Plugin
# *********
-P iisPluginBean.active=”false”
# *********
# Install iPlanet Web Server Plugin
# *********
-P iplanet60PluginBean.active=”false”
# *********
# Install Domino Web Server Plugin
# *********
-P dominoPluginBean.active=”false”
# *******************************************
#
# End Features for Web Server Plugins
#
# *******************************************
# *******************************************
# Install Samples
# *******************************************
-P samplesBean.active=”false”
# *******************************************
#
# Begin Features for Performance and Analysis Tools
#
# *******************************************
# *********
# Install Performance And Analysis Tools
# *********
-P performanceAndAnalysisToolsBean.active=”true”
# *********
# The next 3 features are part of Performance And Analysis
# Tools. In order for any of these features to be installed,
444
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
# the property to install Performance And Analysis Tools denoted
# above must be set to “true.”
# *********
# *********
# Install Tivoli Performance Viewer
# *********
-P tivoliPerfBean.active=”true”
# *********
# Install Dynamic Cache Monitor
# *********
-P DCMBean.active=”true”
# *********
# Install Performance Servlet
# *********
-P performanceServletBean.active=”true”
# *********
# Install Log Analyzer
# *********
-P logAnalyzerBean.active=”true”
# *******************************************
#
# End Features for Performance and Analysis Tools
#
# *******************************************
# *******************************************
# Install Javadocs
# *******************************************
-P javadocBean.active=”false”
#
#
#
#
#
#
*******************************************
Please enter a node name and hostname for this installation.
The node name is used for administration, and must be unique
within its group of nodes (cell). The hostname is the DNS name
or IP address for this computer. You must replace the
“DefaultNode” with the node name that you want the default node
Appendix A. Configuration files and scripts
445
# to be and “127.0.0.1” to a resolveable hostname or IP address
# for your machine.
#
#
#
#
#
Warning:
1. If you are migrating now or plan to do so after
installation, enter the same node name as the previous version.
2. If you are performing coexistence, enter a unique node name.
*******************************************
-W nodeNameBean.nodeName=”$(hostname)”
-W nodeNameBean.hostName=”$(hostname)”
#
#
#
#
#
#
#
#
*******************************************
Begin Installing Services
The following are to install Services for IHS and Websphere
Application Server on Windows. Using Services, you can start and
stop services, and configure startup and recovery actions.
You can ignore these or comment them out for other Operating Systems.
*******************************************
-W serviceSettingsWizardBean.active=”true”
#
#
#
#
#
#
*********
The next 2 options are part of Installing Services.
In order for any of these to be set to “true,”
the property to install Services denoted above must be set
to “true.”
*********
# *********
# Install the IHS service
# *********
-W serviceSettingsWizardBean.ihsChoice=”false”
# *********
# Install the WebSphere Application Server service
# *********
-W serviceSettingsWizardBean.wasChoice=”true”
#
#
#
#
#
#
446
*********
If you chose to install a service above, then you must
specify the User Name and Password which are required to
install the Services. The current user must be admin or must
have admin authority to install a Service. Also the username
which is given here must have “Log On as a Service “ authority
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
# for the service to run properly.
# *********
# *********
# Replace YOUR_USER_NAME with your username.
# *********
-W serviceSettingsWizardBean.userName=”$(wasuser)”
# *********
# Replace YOUR_PASSWORD with your valid password.
# *********
-W serviceSettingsWizardBean.password=”$(waspassword)”
# *******************************************
#
# End Installing Services
#
# *******************************************
#
#
#
#
#
#
-P
-P
-P
-P
-P
-P
-P
-P
*******************************************
Set any or all of the following to false if the launcher
icon is not to be installed. These settings will only affect
an install in which the corresponding product component
is also selected for install.
*******************************************
StartServerIconBean.active=”true”
StopServerIconBean.active=”true”
AdminConsolIconBean.active=”true”
SamplesGalleryIconBean.active=”false”
TivoliPerfIconBean.active=”true”
infoCenterIconBean.active=”true”
firstStepsIconBean.active=”false”
logAnalyzerIconBean.active=”true”
# *******************************************
# Change the path to the prerequisite checker configuration
# file only if a new file has been provided. This can be a
# relative path or an absolute path. Make sure both the
# prereqChecker.xml and prereqChecker.dtd files are present at the provided
path.
# *******************************************
-W osLevelCheckActionBean.configFilePath=”waspc/prereqChecker.xml”
Appendix A. Configuration files and scripts
447
#
#
#
#
#
#
#
#
#
#
*******************************************
Begin Plugin Config File Location
If you chose to install plugins above, then you will
need to specify the fully qualified path, including
the config file name, for the plugins you selected. If you want to
install the plugin, you must specify this path, otherwise the
installer will fail to install the plugins properly. Also, the
value must be included in double quotes.
*******************************************
# *********
# IBM HTTP Server Plugin v1.3 Config File Location
# *********
-W defaultIHSConfigFileLocationBean.value=
# *********
# IBM HTTP Server Plugin v2.0Config File Location
# *********
-W defaultIHS20ConfigFileLocationBean.value=”/opt/IBMIHS/conf/httpd.conf”
# *********
# Apache Web Server v1.3 Config File Location
# *********
-W defaultApacheConfigFileLocationBean.value=
# *********
# Apache Web Server v2.0 Config File Location
# *********
-W defaultApache20ConfigFileLocationBean.value=
# *********
# iPlanet Web Server Config File Location
# *********
-W defaultIPlanetConfigFileLocationBean.value=
#
#
#
#
#
#
#
448
*********
Begin Domino Web Server Plugin Config File Locations
The Notes.jar and names.nsf locations are required
for the Domino Plugin. Please be sure to enter values in
double quotes for both of these files.
*********
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
# *********
# Domino Notes.jar File Location
# *********
-W dominoPanelBean.notesJarFile=
# *********
# Domino names.nsf File Location
# *********
-W dominoPanelBean.namesFile=
# *********
# End Domino Web Server Plugin Config File Locations
# *********
# *******************************************
#
# End Plugin Config File Location
#
# *******************************************
#
#
#
#
#
#
#
*******************************************
Product Registration Tool
To launch the Product Registration Tool, please
change the value to “true.” This is only for
GUI install.
*******************************************
-W launchPRTBean.active=”false”
#
#
#
#
#
#
*******************************************
Install Default App
Please specify if you would like to install the
Default App by setting the value to “true” or “false.”
*******************************************
-W installSampleAppSequenceBean.active=”false”
#
#
#
#
#
*******************************************
First Steps
If you would the First Steps to display at the end
of the installation, please change the value to “true.”
Appendix A. Configuration files and scripts
449
# *******************************************
-W firstStepsSequenceBean.active=”false”
#
#
#
#
#
#
*******************************************
Installation Verification Tool (IVT)
Please specify if you would like to run the Installation
Verification Tool by setting the value to “true” or “false.”
*******************************************
-W installIVTAppSequenceBean.active=”true”
#
#
#
#
#
#
#
#
#
***********************************************************
**
Support for Silent Coexistence
**
** NOTE:
** 1. You must uncomment and modify the properties in
** this section for silent coexistence to work properly.
** 2. You can not perform migration and coexistence at
** the same time.
***********************************************************
# ***********************************************************
# Tell the installer that you want to perform coexistence
# ***********************************************************
#-W coexistenceOptionsBean.doCoexistence=”true”
#
#
#
#
***********************************************************
Set this property if you want to modify the default IHS
and IHS Admin ports
***********************************************************
#-W coexistencePanelBean.useIhs=”true”
# ***********************************************************
# The new value for the Bootstrap Port
# ***********************************************************
#-W coexistencePanelBean.bootstrapPort=”2810”
#
#
#
#
#
450
***********************************************************
The new values for the IHS and IHS Admin ports
NOTE: These values are only used if
coexistencePanelBean.useIhs is set to “true”
***********************************************************
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#-W coexistencePanelBean.ihsPort=”81”
#-W coexistencePanelBean.ihsAdminPort=”8009”
# ***********************************************************
# The new values for the HTTP and HTTPs transports.
# ***********************************************************
#-W coexistencePanelBean.httpTransportPort=”9086”
#-W coexistencePanelBean.httpsTransportPort=”9044”
#
#
#
#
***********************************************************
Thew new values for the admin console an secure admin
console ports.
***********************************************************
#-W coexistencePanelBean.adminConsolePort=”9091”
#-W coexistencePanelBean.secureAdminConsolePort=”9444”
#
#
#
#
#
***********************************************************
The new values for the csivServerAuthListener and
the csivMultiAuthListener ports.
NOTE: You can usually leave these set to 0
***********************************************************
#-W coexistencePanelBean.csivServerAuthListenerAddr=”0”
#-W coexistencePanelBean.csivMultiAuthListenerAddr=”0”
# ***********************************************************
# The new value for the sasSSLServerAuth port.
# ***********************************************************
#-W coexistencePanelBean.sasSSLServerAuthAddr=”0”
#
#
#
#
***********************************************************
The new values for the JMS Server Direct Address,
JMS Server Security, and JMS Server QueuedAddress ports
***********************************************************
#-W coexistencePanelBean.jmsServerDirectAddress=”5569”
#-W coexistencePanelBean.jmsServerSecurityPort=”5567”
#-W coexistencePanelBean.jmsServerQueuedAddress=”5568”
# ***********************************************************
# The new value for the soap connector address port
# ***********************************************************
#-W coexistencePanelBean.soapConnectorAddress=”8881”
Appendix A. Configuration files and scripts
451
#
#
#
#
#
#
#
#
#
#
***********************************************************
**
Support for Silent Migration
**
** NOTE:
** 1. You must uncomment and modify EVERY property
** in this section for silent migration to work properly.
** 2. You can not perform migration and coexistence at
** the same time.
**
***********************************************************
#
#
#
#
#
***********************************************************
The installer must be informed that you wish to operate on
a previous version, so you must tell it that one is present
by uncommenting the next line.
***********************************************************
# -W previousVersionDetectedBean.previousVersionDetected=”true”
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
***********************************************************
Direct the installer to operate on a specific previous version by
uncommenting the next line and entering one of these values:
Value
*****
AE
advanced
AEs
standard
Edition
*******
WAS Advanced Edition (V3.x, V4.0.x)
AE
WAS Advanced Single Server Edition (V4.0.x)
WAS Standard Edition (V3.x)
Note:
For migration from WAS V5.0.x, this field is not used. So simply
set previousVersionPanelBean.selectedVersionEdition to “<NONE>”.
************************************************************
# -W previousVersionPanelBean.selectedVersionEdition=”AEs”
# ************************************************************
# Specify the location where the previous version is installed.
# ************************************************************
# -W
previousVersionPanelBean.selectedVersionInstallLocation=”/opt/IBM/WebSphere/App
Server”
# ************************************************************
# Specify the path to the configuration file for the
# previous version. Configuration filenames are:
#
452
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
#
#
#
#
#
#
#
#
#
#
Value
*****
admin.config
admin.config
server-cfg
server-cfg
previousVersionPanelBean.selectedVersionEdition
***********************************************
AE
advanced
AEs
standard
Note:
For migration from WAS V5.0.x, this field is not used. So simply
set previousVersionPanelBean.selectedVersionConfigFile to “<NONE>”.
************************************************************
# -W
previousVersionPanelBean.selectedVersionConfigFile=”/opt/IBM/WebSphere/AppServe
r/config/server-cfg.xml”
# ************************************************************
# Specify the version number of the previous version:
5.0.2,5.0.1,5.0.0,4.0,4.0.1,3.5, etc...
# ************************************************************
# -W previousVersionPanelBean.previousVersionSelected=”4.0”
#
#
#
#
************************************************************
Uncomment the below line to indicate that you wish to
migrate the previous version.
************************************************************
# -W previousVersionPanelBean.migrationSelected=”true”
#
#
#
#
************************************************************
Specify the directory where migration will backup
information about the previous version.
************************************************************
# -W migrationInformationPanelBean.migrationBackupDir=”/tmp/migrationbackup”
# ************************************************************
# Specify the directory where migration logs will be stored.
# ************************************************************
# -W migrationInformationPanelBean.migrationLogfileDir=”/tmp/migrationlogs”
was_appserver_510_install.sh
Example A-44 on page 454 is the installation script for WebSphere Application
Server 5.1.
Appendix A. Configuration files and scripts
453
Example: A-44 Script for installation of WAS 5.1
#!/bin/sh
## this is a basic script to create users nd groups required for
## succesful installation of WebSphere APplication Server v5.1 on Linux
##
##
## To make this script ready for production, review paths, user and group
names
## and add logging....
doit () {
echo “Executing command: “ $1
$1
rc=$?
echo “-- result was: “ $rc
return $rc;
}
build_group_list ()
{
action=$1
grp_list=$2
case $action in
add)
new_group_list=$grp
;;
remove)
new_group_list=””
;;
esac
##
##
##echo $grp_list | tr “ “ “\n” | while read GROUP;
##do
for GROUP in $grp_list;
do
##echo “read group $GROUP”
case $action in
add)
if [ x$GROUP = x$grp ]; then
# return, already there
echo “Returning - user $usr already member of group $grp”
new_group_list=””
return 4
454
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
fi
new_group_list=$new_group_list,$GROUP
;;
remove)
if [ x$GROUP != x$grp ]; then
if [ x$new_groups = x ]; then
new_group_list=$GROUP
else
new_group_list=$new_group_list,$GROUP
fi
##else
##echo “ommiting group ‘$grp’ target to be removed”
fi
esac
##echo “Working group list is:” $new_group_list
done
##echo “New group list:” $new_group_list
return 0
}
user_mod () {
##
##
##
##echo “Received: “$@
usrfile=/etc/passwd
grpfile=/etc/group
action=$1
usr=$2
grp=$3
##echo “inspecting groups for ${action}’ing ‘$usr’ to/from ‘$grp’”
## get current secondary groups
a=‘grep $usr:x: $usrfile | awk -F: ‘{ print $1 }’‘
if [ x$a = x ]; then
echo “User ‘$usr’ does not exist”
return 4
fi
a=‘grep $grp:x: $grpfile | awk -F: ‘{ print $1 }’‘
if [ x$a = x ]; then
echo “Group ‘$grp’ does not exist”
return 4
fi
Appendix A. Configuration files and scripts
455
a=‘grep :$usr $grpfile | awk
b=‘grep ,$usr $grpfile | awk
old_group_list=‘echo $a $b |
##echo “current group list:”
tst=‘echo $old_groups | tr “
-F: ‘{ print $1 }’‘
-F: ‘{ print $1 }’‘
tr “\n” “ “‘
$old_group_list
“ “\n” | grep $grp‘
case $action in
add)
# return if currently a member
if [ x$tst = x$grp ]; then
echo “‘$usr’ is already a member of ‘$grp’”
return 0
fi
;;
remove)
# return if currently not a member
if [ x$tst = x ]; then
echo “‘$usr’ is NOT a member of ‘$grp’”
return 0
fi
;;
esac
build_group_list “$action” “$old_group_list”
rc=$?
if [ $rc = 0 ]; then
cmd=”usermod -G $new_group_list $usr”
## echo “About to execute: “$cmd
doit “$cmd”
rc=$?
fi
return $rc
}
usr_mod_group () {
func=$1
grp=$2
usr=$3
grpfile=/etc/group
cp $grpfile $grpfile-backup
sedfile=sed.tmp
tmpfile=tmp.tmp
newfile=new.tmp
old=‘grep $grp:x: $grpfile‘
# is group already defined
if [ $old == ““ ]; then
456
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
return 0
fi
# is user a member of group
tst=‘echo $old | grep $usr‘
unset new
case $func in
remove)
if [ x$tst != x ]; then
new=‘echo $old | awk -F”$usr” ‘{print $1 $2’}‘
fi
;;
add)
if [ x$tst = x ]; then
new=$old,$usr
fi
;;
esac
if [ x$new != x ]; then
echo “/$old/ c $new” > $sedfile
sed -f $sedfile $grpfile > $tmpfile
sed -e ‘s/,,/,/g’ $tmpfile > $newfile
sed -e ‘s/:,/:/g’ $newfile > $grpfile
rm $newfile
rm $tmpfile
rm $sedfile
fi
return $?
}
set_rc () {
if [ $1 -gt $2 ]; then
return $1
fi
return $2
}
echo $0 “ received parms: “ $@
mqmgrp=mqm
brkgrp=mqbrkrs
old_rc=0
## add group mqm
doit “groupadd $mqmgrp”
Appendix A. Configuration files and scripts
457
set_rc $? $old_rc
old_rc=$?
## add group mqbrkrs
doit “groupadd $brkgrp”
set_rc $? $old_rc
old_rc=$?
##add user mqm and make member of both groups
doit “useradd -g $mqmgrp -G $brkgrp -m mqm”
set_rc $? $old_rc
old_rc=$?
## add root to mqm group
user_mod “add” “root” $mqmgrp
set_rc $? $old_rc
old_rc=$?
user_mod “add” “root” $brkgrp
set_rc $? $old_rc
old_rc=$?
exit $old_rc
mod_was_server_JVM_process.sh
Example A-45 sets up customization to enable monitoring of JVM processes.
Example: A-45 mod_was_server_JVM_process.sh
#!/bin/sh
ifile=$1
tfile=”l”
bfile=$ifile.bkp
## create backup
cp $ifile $bfile
## find line with string ‘<services xmi:type=”pmiservice:PMIService”’ and set
line numbers
target=‘sed -n -e ‘/<services xmi:type=”pmiservice:PMIService”/ =’ $ifile ‘
prev=$[${target}-1]
next=$[${target}+1]
## write sed edit commands to temp file
echo “1,$prev {“ > $tfile
458
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
echo “p” >> $tfile
echo “}” >> $tfile
echo “$target {“ >> $tfile
echo “i\<services xmi:type=\”pmiservice:PMIService\” xmi:id=\”PMIService_1\”
enable=\”false\”
initialSpecLevel=\”beanModule=N:cacheModule=N:connectionPoolModule=N:j2cModule=
N:jvmRuntimeModule=X:orbPerfModule=N:servletSessionsModule=N:systemModule=N:thr
eadPoolModule=N:transactionModule=N:webAppModule=N:webServicesModule=N:wlmModul
e=N:wsgwModule=N\”/>” >> $tfile
echo “}” >> $tfile
echo “$next,$ {“ >> $tfile
echo “p” >> $tfile
echo “}” >> $tfile
## replace content of ifile
sed -n -f $tfile $bfile > $ifile
## find line with string ‘<jvmEntries xmi:id=”’ and set line numbers
target=‘sed -n -e ‘/<jvmEntries xmi:id=”/ =’ $ifile ‘
prev=$[${target}-1]
next=$[${target}+1]
## write sed edit commands to temp file
echo “1,$prev {“ > $tfile
echo “p” >> $tfile
echo “}” >> $tfile
echo “$target {“ >> $tfile
echo “i\<jvmEntries xmi:id=\”JavaVirtualMachine_1\” verboseModeClass=\”false\”
verboseModeGarbageCollection=\”false\” verboseModeJNI=\”false\”
initialHeapSize=\”0\” maximumHeapSize=\”0\” runHProf=\”false\”
debugMode=\”false\” debugArgs=\”-Djava.compiler=NONE -Xdebug -Xnoagent
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=7777\”
genericJvmArguments=\”-XrunpmiJvmpiProfiler\” disableJIT=\”false\”>” >> $tfile
echo “}” >> $tfile
echo “$next,$ {“ >> $tfile
echo “p” >> $tfile
echo “}” >> $tfile
## replace content of ifile
sed -n -f $tfile $bfile > $ifile
## cleanup
rm $tfile
mod_was_pmirm_settings.sh
Example A-46 on page 460 is the script for enabling PMI data gathering in
WebSphere Application Server 5.1.
Appendix A. Configuration files and scripts
459
Example: A-46 mod_was_pmirm_settings.sh
#!/bin/sh
ifile=$1
tfile=”l”
bfile=$ifile.bkp
## create backup
cp $ifile $bfile
## find line with string ‘<pmirm:’ and set line numbers
target=‘sed -n -e ‘/<pmirm:/ =’ $ifile ‘
prev=$[${target}-1]
next=$[${target}+1]
## write sed edit commands to temp file
echo “1,$prev {“ > $tfile
echo “p” >> $tfile
echo “}” >> $tfile
echo “$target {“ >> $tfile
echo “i\<pmirm:PMIRequestMetrics xmi:version=\”2.0\”
xmlns:xmi=\”http://www.omg.org/XMI\”
xmlns:pmirm=\”http://www.ibm.com/websphere/appserver/schemas/5.0/pmirm.xmi\”
xmi:id=\”PMIRequestMetrics_1\” enable=\”true\” enableARM=\”false\”
traceLevel=\”HOPS\”>/ “ >> $tfile
echo “}” >> $tfile
echo “$next,$ {“ >> $tfile
echo “p” >> $tfile
echo “}” >> $tfile
## replace content of ifile
sed -n -f $tfile $bfile > $ifile
## cleanup
rm $tfile
enable_was_security.sh
Example A-47 on page 461 is the script for enabling security in WebSphere
Application Server 5.1.
460
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Example: A-47 Enable WAS security
#!/bin/sh
jaclfile=$1
if [ ! -r $jaclfile ]; then
echo “File \”${jaclfile}\” does not exist”
exit 256
fi
was_home=/opt/IBM/WebSphere/AppServer
hostname=‘hostname‘
servername=$(wasserver)
wasuser=$(wasuser)
waspassword=$(waspassword)
curdir=‘pwd‘
wsadmin=”${was_home}/bin/wsadmin.sh -conntype SOAP -host localhost -port 8880
-username ${wasuser} -password ${waspassword} -f ${jaclfile}”
doit () {
echo “Executing command: “ $1
$1
rc=$?
echo “-- result was: “ $rc
return $rc;
}
#install websphere application
doit “${was_home}/bin/setupCmdLine.sh “
doit “${was_home}/bin/startServer.sh ${servername} -user ${wasuser} -password
${waspassword}”
doit “${wsadmin}”
doit “${was_home}/bin/GenPluginCfg.sh -node.name ${hostname}”
doit “${was_home}/bin/stopServer.sh ${servername} -user ${wasuser} -password
${waspassword}”
doit “${was_home}/bin/startServer.sh ${servername} -user ${wasuser} -password
${waspassword}”
exit 0
enable_was_security.jacl
Example A-48 on page 462 is the Jacl control file for WebSphere Application
Server security enablement.
Appendix A. Configuration files and scripts
461
Example: A-48 WebSphere Application Server security enablement control
# Usage: wsadmin -connType SOAP -host <HOSTNAME> -port 8880 -user wasuser
-password clemson -f installApp.jacl
# Configure Authentication Alias
# Configure JDBC Data Source and J2C Authentication Alias
# Install TimeCardEARProject application
# Authentication Alias Configuration
set wasserver “$(wasserver)”
set wasuser “$(wasuser)”
set waspassword “$(waspassword)”
puts “ “
puts “ “
puts “LocalOSUserRegistry REGISTRY Configuration”
### Set active user registry to Local OS registry
set regName “LocalOS”
set security_item [$AdminConfig list Security]
### List all the user registries defined
set user_regs [$AdminConfig list UserRegistry]
### Find the one that starts with the name we set at the beginning of the
script
foreach user_reg $user_regs { if {[regexp $regName $user_reg]} { set
new_user_reg $user_reg; break }}
set attrs6 [subst {{activeUserRegistry $new_user_reg} {enabled true}
{enforceJava2Security true}}]
## Modify the user registry attribute for the security object
$AdminConfig modify $security_item $attrs6
puts “ “
puts “ “
puts “Set the properties for Custom User Registry”
## Set the properties for Custom User Registry
#set curClassName “com.ibm.websphere.security.FileRegistrySample”
set serverId $wasuser
set serverPassword $waspassword
##set properties [list [list [list name “usersFile”] [list value
“${was_home}/properties/users.prop”]] [list [list name “groupsFile”] [list
value “${was_home}/properties/groups.prop”]]]
##set attrs7 [subst {{customRegistryClassName $curClassName} {serverId
$serverId} {serverPassword $serverPassword} {properties [list $properties]}}]
set attrs7 [subst {{serverId $wasuser} {serverPassword $waspassword}}]
$AdminConfig modify $new_user_reg $attrs7
462
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
$AdminConfig save
exit
was_appserver_510_uninstall.sh
Example A-49 is the script to use for uninstalling WebSphere Application Server
5.1
Example: A-49 WebSphere Application Server 5.1 uninstallation
#!/bin/sh
## this is a basic script to remove a DB2 UDB Server
## and perform the appropiate cleanup functions:
##
## To make this script ready for production, review paths, user and group
names
## and add logging....
doit () {
echo “Executing command: “ $1
$1
rc=$?
echo “-- result was: “ $rc
return $rc;
}
usr_mod_group () {
func=$1
grp=$2
usr=$3
grpfile=/etc/group
cp $grpfile $grpfile-backup
sedfile=sed.tmp
tmpfile=tmp.tmp
newfile=new.tmp
old=‘grep $grp:x: $grpfile‘
if [ $old == ““ ]; then
return 0
fi
case $func in
remove)
new=‘echo $old | awk -F”$usr” ‘{print $1 $2’}‘
;;
add)
Appendix A. Configuration files and scripts
463
new=$old,$usr
;;
esac
echo “/$old/ c $new” > $sedfile
sed -f $sedfile $grpfile > $tmpfile
sed -e ‘s/,,/,/g’ $tmpfile > $newfile
sed -e ‘s/:,/:/g’ $newfile > $grpfile
rm $newfile
rm $tmpfile
rm $sedfile
return $?
}
echo $0 “ received parms: “ $@
doit “userdel -r mqm”
doit “groupdel mqbrkrs”
doit “groupdel mqm”
exit 0
A.7.6 WebSphere Application Server v5.1 Fixpack 1
The files in this section define and build a software package capable of installing
and uninstalling WebSphere Application Server v5.1 fixpack 1.
In the online material, all these files are located in the following path relative to
the parent directory of the type of file:
/websphere/was/510_fp1/appserver/Linux-IX86.
was_appserver.5.1.0_fp1.spd
Example A-50 is the software package definition file.
Example: A-50 Software package definition for was_server.5.1.0_fp1
“TIVOLI Software Package v4.2.1 - SPDF”
package
name = was_appserver
title = “WebSphere Application Server Enterprise Edition v5.1 fixpack 1”
version = 5.1.0_fp1
web_view_mode = hidden
undoable = o
committable = o
history_reset = y
464
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
save_default_variables = n
creation_time = “2004-11-25 02:56:40”
last_modification_time = “2004-11-25 02:56:40”
default_variables
wasuser = root
waspassword = smartway
wasserver = server1
work_dir = $(root_dir)/$(prod_name)
prod_name = was_appserver_510_fp1
log_dir = $(root_dir)/log/$(prod_name)
img_dir = $(work_dir)/image
bin_dir = $(root_dir)/bin/$(os_family)
root_dir = /swdist
was_dir = /opt/IBM/WebSphere/AppServer
inst_dir = /opt/IBM/WebSphere/AppServer
gz_file = was51_fp1_linux.tar.gz
tar_file = C53IPML-WAS-510-LinuxIX86.tar
home_path = /mnt
prod_path =
websphere/was/510_fp1/appserver/$(os_name)-$(os_architecture)
src_base = $(home_path)/code
src_dir
= $(src_base)/$(prod_path)
tool_base = $(home_path)/tools
tools_dir = $(tool_base)/$(prod_path)
unpack = yes
cleanup = yes
end
log_object_list
location = $(log_dir)
unix_user_id = 0
unix_group_id = 0
unix_attributes = rwx,rx,
end
source_host_name = srchost
move_removing_host = y
no_check_source_host = y
lenient_distribution = y
default_operation = install
server_mode = all
operation_mode = preferably_not_transactional,preferably_undoable,force
log_path = /mnt/logs/was_appserver_510_fp1.log
post_notice = y
before_as_uid = 0
skip_non_zero = n
Appendix A. Configuration files and scripts
465
after_as_uid = 0
no_chk_on_rm = y
log_host_name = srchost
versioning_type = none
package_type = patch
sharing_control = none
stop_on_failure = y
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(tool_base)
name = common
translate = n
destination = $(root_dir)/bin
descend_dirs = y
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(src_base)
name = $(prod_path)
translate = n
destination = $(root_dir)/$(prod_name)
466
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
descend_dirs = n
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
generic_container
caption = “on install”
stop_on_failure = y
condition = “$(operation_name)
== install “
check_disk_space
volume = /,500M
end
execute_user_program
caption = uncompress
condition = “$(unpack) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/gunzip -dvf $(work_dir)/$(prod_name).tar.gz”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_uncompress.out
error_file = $(log_dir)/$(prod_name)_uncompress.err
output_file_append = n
error_file_append = n
Appendix A. Configuration files and scripts
467
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
corequisite_files
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = $(src_dir)/$(gz_file)
translate = n
destination = $(work_dir)/$(prod_name).tar.gz
compression_method = stored
rename_if_locked = n
end
end
end
end
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(src_base)
name = $(prod_path)
translate = n
destination = $(img_dir)
descend_dirs = n
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
468
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
execute_user_program
caption = unpack
condition = “$(unpack) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/tar -C $(img_dir) -xvf
$(work_dir)/$(prod_name).tar”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_unpack.out
error_file = $(log_dir)/$(prod_name)_unpack.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
Appendix A. Configuration files and scripts
469
execute_user_program
caption = “stop server”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “$(was_dir)/bin/stopServer.sh $(wasserver) -user
$(wasuser) -password $(waspassword)”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_stopserver.out
error_file = $(log_dir)/$(prod_name)_stopserver.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success
success
success
failure
end
=
=
=
=
0,0
246,246
247,247
1,245
end
end
execute_user_program
caption = “Silent Install”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “$(work_dir)/$(prod_name)_install.sh install
$(was_dir) $(img_dir)”
inhibit_parsing = n
working_dir = $(work_dir)
470
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_install.out
error_file = $(log_dir)/$(prod_name)_install.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
corequisite_files
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = $(tools_dir)/was_appserver_510_fp1_install.sh
translate = n
destination = $(work_dir)/$(prod_name)_install.sh
compression_method = stored
rename_if_locked = n
end
end
end
end
execute_user_program
caption = “Start server”
transactional = n
during_install
path = $(bin_dir)/do_it
Appendix A. Configuration files and scripts
471
arguments = “$(was_dir)/bin/startServer.sh $(wasserver) -user
$(wasuser) -password $(waspassword)”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_startserver.out
error_file = $(log_dir)/$(prod_name)_startserver.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
execute_user_program
caption = cleanup
condition = “$(cleanup) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/rm -r $(work_dir)”
inhibit_parsing = n
working_dir = $(root_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_cleanup.out
error_file = $(log_dir)/$(prod_name)_cleanup.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
472
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,127
failure = 0,65535
end
end
end
end
generic_container
caption = “on remove”
stop_on_failure = y
condition = “$(operation_name)
== remove”
execute_user_program
caption = “stop server”
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = “$(was_dir)/bin/stopServer.sh $(wasserver) -user
$(wasuser) -password $(waspassword)”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_stopserver.out
error_file = $(log_dir)/$(prod_name)_stopserver.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
Appendix A. Configuration files and scripts
473
success
success
success
failure
=
=
=
=
0,0
246,246
247,247
1,245
end
end
end
execute_user_program
caption = “Silent Install and uninstall”
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = “$(work_dir)/$(prod_name)_install.sh install
$(was_dir) $(img_dir)”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_uninstall.out
error_file = $(log_dir)/$(prod_name)_uninstall.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
corequisite_files
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = $(tools_dir)/was_appserver_510_fp1_install.sh
translate = n
474
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
destination = $(work_dir)/$(prod_name)_install.sh
compression_method = stored
rename_if_locked = n
end
end
end
end
execute_user_program
caption = “Start server”
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = “$(was_dir)/bin/startServer.sh $(wasserver) -user
$(wasuser) -password $(waspassword)”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_startserver.out
error_file = $(log_dir)/$(prod_name)_startserver.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
end
end
Appendix A. Configuration files and scripts
475
was_appserver_510_fp1_install.sh
Example A-51 is the install script.
Example: A-51 was_appserver_510_fp1 installation script
#!/bin/sh
function=$1
if [ x${function} = x ]; then
echo “you have to specify function: ‘install’ or ‘uninstall’ “
exit 4
fi
WAS_HOME=$2
if [ x${WAS_HOME} = x ]; then
echo “you have to specify the WAS install directory (
/opt/WebSphere/AppServer )”
exit 4
fi
IMG_DIR=$3
if [ x${IMG_DIR} = x ]; then
echo “you have to proide the path to the directory holding the
updateSilent.sh script”
exit 4
fi
. ${WAS_HOME}/bin/setupCmdLine.sh
${IMG_DIR}/updateSilent.sh \
-installDir “${WAS_HOME}” \
-fixpack \
-fixpackDir “${IMG_DIR}/fixpacks” \
-${function} \
-fixPackID was51_fp1_linux
\
-skipIHS
\
-skipMQ
exit $?
A.7.7 DB2 Server v8.2
The following files in this section are used to define and build a software package
which installs and uninstalls IBM DB2 UDB Server v8.2 Enterprise Edition.
In the online material, all these files are located in the following path relative to
the parent directory of the type of file: /db2/udb-ee/820/server/Linux-IX86.
476
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
db2_server.8.2.0.spd
Example A-52 is the software package for DB2 Server installation.
Example: A-52 Software package definition for db2_server.8.2.0.spd
“TIVOLI Software Package v4.2.1 - SPDF”
package
name = t_db2_server
title = “DB2 Universal Database Server Enterprise Edition v8.2”
version = 8.2.0
web_view_mode = hidden
undoable = n
committable = n
history_reset = n
save_default_variables = n
creation_time = “2004-11-30 18:07:20”
last_modification_time = “2004-11-30 19:15:03”
default_variables
work_dir = $(root_dir)/$(prod_name)
prod_name = db2_server_820
log_dir
= $(root_dir)/log/$(prod_name)
img_dir
= $(work_dir)/image/009_ESE_LNX_32_NLV
bin_dir
= $(root_dir)/bin/$(os_family)
root_dir = /swdist
inst_dir = /opt/IBM/db2/V8.1
tar_file = C58S8ML-db2udbes82.tar
rsp_file = db2_server_820.rsp
home_path = /mnt
prod_path = db2/udb-ee/820/server/$(os_name)-$(os_architecture)
src_base = $(home_path)/code
src_dir
= $(src_base)/$(prod_path)
rsp_base = $(home_path)/rsp
rsp_dir
= $(rsp_base)/$(prod_path)
tool_base = $(home_path)/tools
tools_dir = $(tool_base)/$(prod_path)
unpack
= yes
cleanup
= yes
end
log_object_list
location = $(log_dir)
unix_user_id = 0
unix_group_id = 0
unix_attributes = rwx,rx,rx
end
Appendix A. Configuration files and scripts
477
source_host_name = srchost
move_removing_host = y
no_check_source_host = y
lenient_distribution = n
default_operation = install
server_mode = all,force
operation_mode = not_transactional
log_path = /mnt/logs/db2_server_820.log
post_notice = y
before_as_uid = 0
skip_non_zero = n
after_as_uid = 0
no_chk_on_rm = y
log_host_name = srchost
versioning_type = swd
package_type = refresh
sharing_control = none
stop_on_failure = y
add_directory
stop_on_failure = y
add = y
replace_if_existing = n
replace_if_newer = n
remove_if_modified = n
location = $(tool_base)
name = common
translate = n
destination = $(root_dir)/bin
descend_dirs = y
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_owner = root
unix_group = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
478
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
add_directory
stop_on_failure = y
add = y
replace_if_existing = n
replace_if_newer = n
remove_if_modified = n
location = $(src_base)
name = $(prod_path)
translate = n
destination = $(work_dir)
descend_dirs = n
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_owner = root
unix_group = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
generic_container
caption = “on install”
stop_on_failure = y
condition = “$(operation_name)
#
#
#
#
== install”
generic_container
caption = “on unpack”
stop_on_failure = y
condition = “$(unpack) == yes”
add_directory
stop_on_failure = n
add = y
replace_if_existing = n
replace_if_newer = n
remove_if_modified = n
Appendix A. Configuration files and scripts
479
location = $(src_base)
name = $(prod_path)
translate = n
destination = $(work_dir)/image
descend_dirs = n
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
execute_user_program
caption = unpack
condition = “$(unpack) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/tar -C $(work_dir)/image -xvf
$(work_dir)/$(prod_name).tar”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_unpack.out
error_file = $(log_dir)/$(prod_name)_unpack.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
480
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
exit_codes
success = 0,0
failure = 1,65535
end
corequisite_files
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = $(src_dir)/$(tar_file)
translate = n
destination = $(work_dir)/$(prod_name).tar
compression_method = stored
rename_if_locked = n
end
end
end
end
#
end
add_directory
stop_on_failure = y
add = y
replace_if_existing = n
replace_if_newer = n
remove_if_modified = n
location = $(rsp_base)
name = $(prod_path)
translate = n
destination = $(work_dir)
descend_dirs = n
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
Appendix A. Configuration files and scripts
481
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = y
is_signature = n
compression_method = stored
rename_if_locked = n
add_file
replace_if_existing = n
replace_if_newer = n
remove_if_modified = n
name = db2_server_820.rsp
translate = n
destination = $(prod_name).rsp
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = y
is_signature = n
compression_method = stored
rename_if_locked = n
end
end
execute_user_program
caption = “Install”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “$(img_dir)/db2setup -r $(work_dir)/$(prod_name).rsp
-l $(log_dir)/$(prod_name)_db2inst.log”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
482
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_install.out
error_file = $(log_dir)/$(prod_name)_install.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
execute_user_program
caption = “Update DB2 License”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “$(inst_dir)/adm/db2licm -a
$(img_dir)/db2/license/db2ese.lic”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_update_license.out
error_file = $(log_dir)/$(prod_name)_update_license.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
Appendix A. Configuration files and scripts
483
exit_codes
success = 0,0
failure = 1,65535
end
end
end
execute_user_program
caption = “create monitoring user db2ecc”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = $(work_dir)/$(prod_name)_addusers.sh
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_addusers.out
error_file = $(log_dir)/$(prod_name)_addusers.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
corequisite_files
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = $(tools_dir)/db2_server_820_addusers.sh
translate = n
destination = $(work_dir)/$(prod_name)_addusers.sh
484
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
compression_method = stored
rename_if_locked = n
end
end
end
end
execute_user_program
caption = “cleanup image directory”
condition = “$(cleanup) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/rm -r $(img_dir)”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_cleanup.out
error_file = $(log_dir)/$(prod_name)_cleanup.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
end
generic_container
caption = “on remove”
Appendix A. Configuration files and scripts
485
stop_on_failure = y
condition = “$(operation_name)
== remove”
execute_user_program
caption = “DB2 remove”
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = $(work_dir)/$(prod_name)_remusers.sh
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_remove.out
error_file = $(log_dir)/$(prod_name)_remove.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
corequisite_files
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = $(tools_dir)/db2_deinstall
translate = n
destination = $(work_dir)/db2_deinstall
compression_method = stored
rename_if_locked = n
end
add_file
replace_if_existing = y
486
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
replace_if_newer = n
remove_if_modified = n
name = $(tools_dir)/db2_server_820_remusers.sh
translate = n
destination = $(work_dir)/$(prod_name)_remusers.sh
compression_method = stored
rename_if_locked = n
end
end
end
end
end
end
db2_server_820.rsp
Example A-53 is the response file used to control the installation of DB2 Server
v8.2.
Example: A-53 Response file for DB2 Server v8.2 installation
*----------------------------------------------------* Generated response file used by the DB2 Setup wizard
* generation time: 11/13/04 1:43 PM
*----------------------------------------------------* Product Installation
LIC_AGREEMENT
= ACCEPT
PROD
= ENTERPRISE_SERVER_EDITION
INSTALL_TYPE
= CUSTOM
COMP
= SQL_PROCEDURES
COMP
= DB2_CONTROL_CENTER
COMP
= CONFIGURATION_ASSISTANT
COMP
= DB2_ENGINE
COMP
= CONNECT
COMP
= DB2_SAMPLE_DATABASE_SOURCE
COMP
= CLIENT_APPLICATION_ENABLER
COMP
= JAVA_SUPPORT
COMP
= REPLICATION
COMP
= COMMUNICATION_SUPPORT_TCPIP
*----------------------------------------------* Das properties
*----------------------------------------------DAS_CONTACT_LIST
= LOCAL
* DAS user
DAS_USERNAME
= dasusr1
DAS_GROUP_NAME
= dasadm1
Appendix A. Configuration files and scripts
487
DAS_HOME_DIRECTORY
= /home/dasusr1
DAS_PASSWORD
= 245255345290348217331337
ENCRYPTED
= DAS_PASSWORD
* ---------------------------------------------* Instance properties
* ---------------------------------------------INSTANCE
= inst1
inst1.TYPE
= ese
inst1.WORDWIDTH
= 32
* Instance-owning user
inst1.NAME
= db2inst1
inst1.GROUP_NAME
= db2grp1
inst1.HOME_DIRECTORY
= /home/db2inst1
inst1.PASSWORD
= 245255345290348217331337
ENCRYPTED
= inst1.PASSWORD
inst1.AUTOSTART
= YES
inst1.AUTHENTICATION
= SERVER
inst1.SVCENAME
= db2c_db2inst1
inst1.PORT_NUMBER
= 50001
inst1.FCM_PORT_NUMBER
= 60000
inst1.MAX_LOGICAL_NODES
= 4
* Fenced user
inst1.FENCED_USERNAME
= db2fenc1
inst1.FENCED_GROUP_NAME
= db2fgrp1
inst1.FENCED_HOME_DIRECTORY
= /home/db2fenc1
inst1.FENCED_PASSWORD
= 245255345290348217331337
ENCRYPTED
= inst1.FENCED_PASSWORD
*----------------------------------------------* Installed Languages
*----------------------------------------------LANG
= EN
db2_server_820_addusers.sh
Example A-54 is the script used to create system groups and users required by
the DB2 Server installation.
Example: A-54 db2_server_820_addusers.sh script to create db2 users
#!/bin/sh
##
##
##
##
##
this is a basic that adds the db2ecc user to system
where DB2 Server has been installed.
the db2ecc user is required for Tivoli Monitoring for Databases
doit () {
echo “Executing command: “ $1
488
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
$1
rc=$?
echo “-- result was: “ $rc
return $rc;
}
db2grp=db2grp1
password=smartway
## define group
echo “ ensuring existance of db2 user group”
doit “groupadd $db2grp”
## define user db2ecc
echo “ creating monitoring user”
doit “useradd -g $db2grp -m db2ecc -p $password”
exit 0
db2_server_820_remusers.sh
Example A-55 is the script for removing all system user and group definitions
prior to removing DB2 Server.
Example: A-55 db2_server_820_remusers.sh to remove db2 users
#!/bin/sh
## this is a basic script to remove a DB2 UDB Server
## and perform the appropiate cleanup functions:
##
## Functions performed:
##
## - Add root to db2admin and db2users group to allow root to perform admin
functions
##
note: existing additional group relationships for root will be
overwritten
##
## - for each instance: db2stop force, drop instance, delete instance user
##
## - delete default fence user and group (db2fenc1:db2fgrp1)
##
## - stop db2admin server
## - delete default db2admin user and group (dasusr1:dasadm1)
##
## - uninstall db2 rpm packages
##
## - remove default installation file system (/opt/IBM/db2)
##
Appendix A. Configuration files and scripts
489
##
##
## To make this script ready for production, review paths, user and group
names
## and add logging....
doit () {
echo “Executing command: “ $1
$1
rc=$?
echo “-- result was: “ $rc
return $rc;
}
build_group_list ()
{
action=$1
grp_list=$2
case $action in
add)
new_group_list=$grp
;;
remove)
new_group_list=””
;;
esac
##
##
##echo $grp_list | tr “ “ “\n” | while read GROUP;
##do
for GROUP in $grp_list;
do
##echo “read group $GROUP”
case $action in
add)
if [ x$GROUP = x$grp ]; then
# return, already there
echo “Returning - user $usr already member of group $grp”
new_group_list=””
return 4
fi
new_group_list=$new_group_list,$GROUP
;;
remove)
if [ x$GROUP != x$grp ]; then
490
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
if [ x$new_groups = x ]; then
new_group_list=$GROUP
else
new_group_list=$new_group_list,$GROUP
fi
##else
##echo “ommiting group ‘$grp’ target to be removed”
fi
esac
##echo “Working group list is:” $new_group_list
done
##echo “New group list:” $new_group_list
return 0
}
user_mod () {
##
##
##
##echo “Received: “$@
usrfile=/etc/passwd
grpfile=/etc/group
action=$1
usr=$2
grp=$3
##echo “inspecting groups for ${action}’ing ‘$usr’ to/from ‘$grp’”
## get current secondary groups
a=‘grep $usr:x: $usrfile | awk -F: ‘{ print $1 }’‘
if [ x$a = x ]; then
echo “User ‘$usr’ does not exist”
return 4
fi
a=‘grep $grp:x: $grpfile | awk -F: ‘{ print $1 }’‘
if [ x$a = x ]; then
echo “Group ‘$grp’ does not exist”
return 4
fi
a=‘grep :$usr $grpfile | awk -F: ‘{ print $1 }’‘
b=‘grep ,$usr $grpfile | awk -F: ‘{ print $1 }’‘
Appendix A. Configuration files and scripts
491
old_group_list=‘echo $a $b | tr “\n” “ “‘
##echo “current group list:” $old_group_list
tst=‘echo $old_groups | tr “ “ “\n” | grep $grp‘
case $action in
add)
# return if currently a member
if [ x$tst = x$grp ]; then
echo “‘$usr’ is already a member of ‘$grp’”
return 0
fi
;;
remove)
# return if currently not a member
if [ x$tst = x ]; then
echo “‘$usr’ is NOT a member of ‘$grp’”
return 0
fi
;;
esac
build_group_list “$action” “$old_group_list”
rc=$?
if [ $rc = 0 ]; then
cmd=”usermod -G $new_group_list $usr”
## echo “About to execute: “$cmd
doit “$cmd”
rc=$?
fi
return $rc
}
echo $0 “ received parms: “ $@
db2root=/opt/IBM/db2
db2path=$db2root/V8.1
db2ipath=$db2path/instance
fncusr=db2fenc1
admusr=dasusr1
eccusr=db2ecc
db2grp=db2grp1
fncgrp=db2fgrp1
admgrp=dasadm1
## allow root to issue db2 commands
if [ x‘grep ${db2grp}: /etc/group‘ != x ]; then
492
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
echo “allow root to perform db2 functions”
##doit “usermod -G $db2grp,$admgrp root”
##user_mod_group “add” $db2grp “root”
user_mod “add” “root” $db2grp
fi
if [ x‘grep ${admgrp}: /etc/group‘ != x ]; then
echo “allow root to perform db2 admin functions”
user_mod “add” “root” $admgrp
fi
## stop and delete all instances and instance users
if [ -f $db2ipath/db2ilist ]; then
instances=‘$db2ipath/db2ilist‘
for i in $instances ; do
if [ x‘grep ${i}: /etc/passwd‘ != x ]; then
echo “removing instance $i - including instance user”
. /home/$i/.profile
doit “db2stop force”
doit “$db2ipath/db2idrop $i”
doit “userdel -r $i”
fi
done
fi
## delete fence user
if [ x‘grep ${fncusr}: /etc/passwd‘ != x ]; then
echo “deleting fence user”
doit “userdel -r $fncusr”
fi
## delete monitoring user
if [ x‘grep ${eccusr}: /etc/passwd‘ != x ]; then
echo “deleting monitoring user”
doit “userdel -r $eccusr”
fi
## delete user groups
echo “delete db2 instance groups”
if [ x‘grep ${db2grp}: /etc/group‘ != x ]; then
doit “groupdel $db2grp”
fi
if [ x‘grep ${fncgrp}: /etc/group‘ != x ]; then
doit “groupdel $fncgrp”
fi
## stop and delete the admin server
echo “ stop and delete admin server”
if [ x‘grep ${admusr}: /etc/passwd‘ != x ]; then
Appendix A. Configuration files and scripts
493
. /home/dasusr1/.profile
doit “db2admin stop”
doit “$db2ipath/dasdrop”
doit “userdel -r $admusr”
fi
## delete admin group
echo “deleting admin group”
if [ x‘grep ${admgrp}: /etc/group‘ != x ]; then
doit “groupdel $admgrp”
fi
## uninstall product rpm’s
echo “removing rpms”
doit “./db2_deinstall”
## remove file system
echo “removing filesystem”
doit “rm -r $db2root”
##usr_mod “remove” “root”
$db2grp
exit 0
A.7.8 TMTP Agent v5.3
The following files in this section are define and build a software package
capable of installing and uninstalling TMTP Monitoring Agent v5.3.
In the online material, all these files are located in the following path relative to
the parent directory of the type of file: /tivoli/TMTP/530/agents/generic.
tmtp_agent.5.3.0.spd
Example A-56 is the software package definition for TMTP Monitoring Agent
v5.3.
Example: A-56 Software Package for TMTP Agent deployment
“TIVOLI Software Package v4.2.1 - SPDF”
package
name = t_tmtp_agent
title = “TMTP Management Agent v5.3”
version = 5.3.0
web_view_mode = hidden
undoable = n
494
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
committable = o
history_reset = y
save_default_variables = n
creation_time = “2004-12-02 19:11:03”
last_modification_time = “2004-12-02 19:11:03”
default_variables
inst_ems = no
work_dir = $(root_dir)/$(prod_name)
prod_name = tmtp_agent_530
log_dir = $(root_dir)/log/$(prod_name)
img_dir = $(work_dir)/image
bin_dir = $(root_dir)/bin/$(os_family)
root_dir = /swdist
inst_dir = /opt/IBM/Tivoli/MA
rsp_file = MA.rsp
home_path = /mnt
prod_path = tivoli/tmtp/530/agents/generic
src_base = $(home_path)/code
src_dir
= $(src_base)/$(prod_path)
rsp_base = $(home_path)/rsp
tool_base = $(home_path)/tools
tools_dir = $(tool_base)/$(prod_path)
unpack = yes
cleanup = yes
end
log_object_list
location = $(log_dir)
unix_user_id = 0
unix_group_id = 0
unix_attributes = rwx,rx,
end
source_host_name = srchost
move_removing_host = y
no_check_source_host = y
lenient_distribution = y
default_operation = install
server_mode = all
operation_mode = not_transactional,force
log_path = /mnt/logs/tmtp_agent_530.log
post_notice = y
before_as_uid = 0
skip_non_zero = n
after_as_uid = 0
no_chk_on_rm = y
Appendix A. Configuration files and scripts
495
log_host_name = srchost
versioning_type = swd
package_type = refresh
sharing_control = none
stop_on_failure = y
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(tool_base)
name = common
translate = n
destination = $(root_dir)/bin
descend_dirs = y
remove_empty_dirs = n
is_shared = y
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(src_base)
name = $(prod_path)
translate = n
destination = $(root_dir)/$(prod_name)
descend_dirs = n
496
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
generic_container
caption = “on install”
stop_on_failure = y
condition = “$(operation_name)
== install”
check_disk_space
volume = /,1500M
end
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(src_dir)
name = MA
translate = n
destination = $(img_dir)
descend_dirs = y
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = n
Appendix A. Configuration files and scripts
497
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(rsp_base)
name = $(prod_path)
translate = n
destination = $(work_dir)
descend_dirs = n
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
498
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
name = $(rsp_file)
translate = n
destination = $(prod_name).rsp
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
end
execute_user_program
caption = install
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “$(img_dir)/setup_MA_lin.bin -is:silent -is:log
$(log_dir)/$(prod_name)_product_install.log -silent -options
$(work_dir)/$(prod_name).rsp”
inhibit_parsing = n
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_install.out
error_file = $(log_dir)/$(prod_name)_install.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = n
reporting_stderr_on_server = n
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
Appendix A. Configuration files and scripts
499
exit_codes
success = 0,0
failure = 1,65535
end
end
end
execute_user_program
caption = cleanup
condition = “$(cleanup) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “rm -r $(img_dir)”
inhibit_parsing = n
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_install_cleanup.out
error_file = $(log_dir)/$(prod_name)_install_cleanup.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = n
reporting_stderr_on_server = n
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
end
generic_container
caption = “on remove”
500
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
stop_on_failure = y
condition = “$(operation_name)
== remove”
execute_user_program
caption = remove
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = “$(inst_dir)/_uninst53/uninstall.bin -is:silent
-is:log $(log_dir)/$(prod_name)_product_remove.log -silent”
inhibit_parsing = n
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_remove.out
error_file = $(log_dir)/$(prod_name)_remove.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = n
reporting_stderr_on_server = n
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
execute_user_program
caption = cleanup
condition = “$(cleanup) == yes”
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = “rm -r $(work_dir)”
inhibit_parsing = n
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
Appendix A. Configuration files and scripts
501
output_file = $(log_dir)/$(prod_name)_remove_cleanup.out
error_file = $(log_dir)/$(prod_name)_remove_cleanup.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = n
reporting_stderr_on_server = n
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
end
end
MA.rsp
Example A-57 is the response file controlling the installation of the TMTP
Monitoring Agent v5.3.
Example: A-57 Responsefile for TMTP Agent deployment
-W msConnection.hostName=”tmtpsrv”
-W msConnection.userName=”root”
-W msConnection.password=”smartway”
-W msConnection.sslValue=”true”
-W msConnection.copyKeyFile=”true”
-W msConnection.protocol=”https”
-W msConnection.portNumber=”9446”
-W msConnection.epKeyStore=”$(img_dir)/keyfiles/agent.jks”
-W msConnection.epKeyPass=”changeit”
-W msConnection.maPort=”1976”
#-W serviceUser.user=”TMTPAgent”
#-W serviceUser.password=”tivoli”
-W logSettings.logLevel=”ALL”
-W logSettings.consoleOut=”false”
-W uninstall_reboot.rebootSelected=”true”
#-P ma.installLocation=”C:/Program Files/Tivoli/MA”
-P ma.installLocation=”$(inst_dir)”
### -P ma.installLocation=”/opt/IBM/Tivoli/MA”
502
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
A.7.9 WebSphere Caching Proxy v5.1
The following files in this section are used to define and build a software package
capable of installing and uninstalling WebSphere Caching Proxy v5.1.
In the online material, all these files are located in the following path relative to
the parent directory of the type of file:
/websphere/edge/510/cachingproxy/Linux-IX86.
wses_cachingproxy.5.1.0.spd
Example A-58 is the software package definition file for installing WebSphere
Caching Proxy v5.1.
Example: A-58 Software package for Caching Proxy deployment
“TIVOLI Software Package v4.2.1 - SPDF”
package
name = t_wses_cackingproxy
title = “WAS Caching Proxy V5.1.0”
version = 5.1.0
web_view_mode = hidden
undoable = n
committable = n
history_reset = n
save_default_variables = n
creation_time = “2004-11-29 18:06:10”
last_modification_time = “2004-11-29 18:06:10”
default_variables
root_dir = /swdist
prod_name = wses_cachingproxy_510
work_dir = $(root_dir)/$(prod_name)
log_dir = $(root_dir)/log/$(prod_name)
img_dir = $(work_dir)/image
bin_dir = $(root_dir)/bin/$(os_family)
inst_dir = /opt/ibm/edge
tar_file = EdgeComponents51-Linux.tar
home_path = /mnt
prod_path =
websphere/edge/510/cachingproxy/$(os_name)-$(os_architecture)
src_base = $(home_path)/code
src_dir = $(src_base)/$(prod_path)
rsp_base = $(home_path)/rsp
tool_base = $(home_path)/tools
tools_dir = $(tool_base)/$(prod_path)
Appendix A. Configuration files and scripts
503
unpack = yes
cleanup = yes
user = root
password = smartway
conf_dir = /opt/ibm/edge/cp/etc/en_US
LoadURL = RS-AppServer.demo.tivoli.com
end
log_object_list
location = $(log_dir)
unix_user_id = 0
unix_group_id = 0
unix_attributes = rwx,rx,
end
source_host_name = srchost
move_removing_host = y
no_check_source_host = y
lenient_distribution = n
default_operation = install
server_mode = all
operation_mode = not_transactional
log_path = /mnt/logs/wses_cachingproxy_510.log
post_notice = y
before_as_uid = 0
skip_non_zero = n
after_as_uid = 0
no_chk_on_rm = y
log_host_name = srchost
versioning_type = swd
package_type = refresh
sharing_control = none
stop_on_failure = y
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(tool_base)
name = common
translate = n
destination = $(root_dir)/bin
descend_dirs = y
504
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
generic_container
caption = “on install - unpack”
stop_on_failure = y
condition = “$(operation_name) == install”
check_disk_space
volume = /,250M
end
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(rsp_base)
name = $(prod_path)
translate = n
destination = $(root_dir)/$(prod_name)
descend_dirs = n
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
Appendix A. Configuration files and scripts
505
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
add_file
replace_if_existing = y
replace_if_newer = y
remove_if_modified = n
name = ibmproxy.conf
translate = n
destination = $(prod_name).conf
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
end
add_directory
stop_on_failure = y
condition = “$(unpack) == yes”
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(src_base)
name = $(prod_path)
translate = n
destination = $(img_dir)
descend_dirs = n
506
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
execute_user_program
caption = unpack
condition = “$(unpack) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/tar -C $(img_dir) -xvf
$(work_dir)/$(prod_name).tar”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_unpack.out
error_file = $(log_dir)/$(prod_name)_unpack.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
Appendix A. Configuration files and scripts
507
corequisite_files
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = $(src_dir)/$(tar_file)
translate = n
destination = $(work_dir)/$(prod_name).tar
compression_method = stored
rename_if_locked = n
end
end
end
end
end
generic_container
caption = “on remove - stop”
stop_on_failure = y
condition = “$(operation_name)
== remove”
execute_user_program
caption = “stop server”
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = “$(work_dir)/$(prod_name)_remove.sh”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_remove.out
error_file = $(log_dir)/$(prod_name)_remove.err
output_file_append = y
error_file_append = y
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
508
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
corequisite_files
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = $(tools_dir)/wses_cachingproxy_510_remove.sh
translate = n
destination = $(work_dir)/$(prod_name)_remove.sh
compression_method = stored
rename_if_locked = n
end
end
end
end
end
install_rpm_package
caption = “WAS Caching Proxy”
rpm_options = -vv
rpm_install_type = install
rpm_install_force = n
rpm_install_nodeps = y
rpm_remove_nodeps = y
rpm_report_log = y
rpm_file
image_dir = $(img_dir)/admin
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = WSES_Admin_Runtime-5.1.0-0
rpm_package_file = WSES_Admin_Runtime-5.1.0-0.i686.rpm
end
Appendix A. Configuration files and scripts
509
rpm_file
image_dir = $(img_dir)/cp
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = WSES_CachingProxy_msg_en_US-5.1.0-0
rpm_package_file = WSES_CachingProxy_msg_en_US-5.1.0-0.i686.rpm
end
rpm_file
image_dir = $(img_dir)/icu
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = WSES_ICU_Runtime-5.1.0-0
rpm_package_file = WSES_ICU_Runtime-5.1.0-0.i686.rpm
end
rpm_file
image_dir = $(img_dir)/cp
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = WSES_CachingProxy-5.1.0-0
rpm_package_file = WSES_CachingProxy-5.1.0-0.i686.rpm
end
rpm_file
image_dir = $(img_dir)/doc
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = WSES_Doc_en_US-5.1.0-0
rpm_package_file = WSES_Doc_en_US-5.1.0-0.i686.rpm
end
end
generic_container
caption = “on install - after rpm install”
stop_on_failure = y
condition = “$(operation_name) == install”
510
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
execute_user_program
caption = “configure proxy server”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “$(work_dir)/$(prod_name)_setup.sh $(user) $(password)
$(work_dir)/$(prod_name).conf $(conf_dir)”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_setup.out
error_file = $(log_dir)/$(prod_name)_setup.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
corequisite_files
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = $(tools_dir)/wses_cachingproxy_510_setup.sh
translate = n
destination = $(work_dir)/$(prod_name)_setup.sh
compression_method = stored
rename_if_locked = n
end
end
end
end
Appendix A. Configuration files and scripts
511
execute_user_program
caption = cleanup
condition = “$(cleanup) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/rm -r $(work_dir)”
inhibit_parsing = n
working_dir = $(root_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_cleanup.out
error_file = $(log_dir)/$(prod_name)_cleanup.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
end
generic_container
caption = “on remove”
stop_on_failure = y
condition = “$(operation_name)
== remove”
execute_user_program
caption = cleanup
condition = “$(cleanup) == yes”
transactional = n
during_remove
512
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
path = $(bin_dir)/do_it
arguments = “$(work_dir)/$(prod_name)_remove.sh”
arguments = “/bin/rm -r $(inst_dir)”
inhibit_parsing = n
working_dir = $(root_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_remove.out
error_file = $(log_dir)/$(prod_name)_remove.err
output_file_append = y
error_file_append = y
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
#
exit_codes
success = 0,0
failure = 1,65535
end
end
end
end
end
ibmproxy.conf
Example A-59 is used to provide basic customization of the WebSphere Caching
Proxy. From the software package, it is referenced as a response file.
Example: A-59 ibmproxy.conf for Outlet Inc.
#
#
#
#
#
#
#
#
#
#
(C) COPYRIGHT International Business Machines Corp. 1997, 2000, 2001
All Rights Reserved
Licensed Materials - Property of IBM
US Government Users Restricted Rights - Use, duplication or
disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
===================================================================== #
This is the default configuration file for the
Appendix A. Configuration files and scripts
513
#
IBM WebSphere Edge Server Web Traffic Express
#
proxy server.
#
#
TABLE OF CONTENTS
#
=================
#
- Basic directives
#
- Process control
#
- Logging directives
#
* log file directives
#
* log archive directives
#
* log filtering directives
#
- Method directives
#
- Content presentation directives
#
* Welcome pages directives
#
* Directory browsing directives
#
* CGI program directives
#
* Content type directives
#
- Error Message directives
#
- API directives
#
- User authentication and document protection
#
- Mapping rules
#
- Performance directives
#
- Timeout directives
#
- Proxy directives
#
- Proxy caching directives
#
- Proxy cache garbage collection directives
#
- Advanced proxy and caching directives
#
- Remote Cache Access (RCA) directives
#
- SNMP directives
#
- Icon directives
#
- Cache agent directives
#
- PICS Filtering directives
#
- Miscellaneous directive
#
- System Plug-in directives
#
# ===================================================================== #
# ===================================================================== #
#
#
Basic directives
#
# ===================================================================== #
#
#
#
514
ServerRoot directive:
Set this to point to the directory where you unpacked this
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
distribution, or wherever you want ibmproxy to have its “home”.
#
#
Default: /opt/ibm/edge/cp/server_root
#
Syntax:
ServerRoot
<path>
ServerRoot /opt/ibm/edge/cp/server_root
#
HeaderServerName directive:
#
#
This directive allows the administrator to modify the name of the
#
proxy server contained within the http header.
#
#
The default server name is IBM-PROXY-WTE-US/VersionNumber.
#
#
Syntax:
HeaderServerName
<headerservername>
#
# HeaderServerName <none>
#
#
#
#
#
#
#
#
#
Hostname directive:
Specify the fully qualified hostname, including the domain. You can
use an alias (if you have one set up) instead of the machine’s real
host name so that clients will not be able to see the real host name.
Default:
Syntax:
<host name default defined in DNS>
Hostname
<fully qualified host name>
#
BindSpecific directive:
#
#
Allows a multi-homed system to run a different server on
#
each IP address.
#
#
Default: off
#
Syntax:
BindSpecific <on | off>
BindSpecific off
#
Port directive:
#
#
Port used by the server.
#
NOTE: If the server is not started by root, you must use a port
#
above 1024; good choices are 8000, 8001, 8080.
#
#
Default: 80
#
Syntax:
Port <num>
Port 8080
Appendix A. Configuration files and scripts
515
#
AdminPort directive:
#
#
This port may be used by the administrator for access to the
#
server status pages or configuration forms. Requests to this
#
port will not be queued with all other incoming requests on the
#
standard port(s) defined with the Port directive. However, they
#
will go through the normal access control and request-mapping
#
rules (Pass, Exec, Protect, etc).
#
#
The administration port must not be the same as the standard
#
port(s) defined with the Port directive.
#
#
Default: 8008
#
Syntax:
AdminPort <num>
AdminPort
8008
# ===================================================================== #
#
#
Process control directives
#
# ===================================================================== #
516
#
#
#
#
#
#
#
#
UserId
UserId directive:
#
#
#
#
#
#
#
#
GroupId
GroupId directive:
#
#
#
#
#
NoBG directive:
Specify the user name/number to which the server changes
before accessing files, if the server was started as root.
Default:
Syntax:
nobody
UserId <user name/number>
nobody
Specify the group name/number the server changes to
before accessing files, if the server was started as root.
Default:
Syntax:
nobody
nobody
nogroup (for the SuSE Linux distribution)
GroupId <group name/number>
Normally, when the server is started, the process forks to go
into the background, and the first process exits. If you turn on
NoBG, the main process will not go to the background. If you’re
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
#
#
#
#
NoBG off
using init to start the server, it may be useful to set this
to ON (and then init can respawn the server if it fails).
#
#
#
#
#
#
#
#
#
#
#
#
PidFile directive:
Default:
Syntax:
off
NoBG <on | off>
When the server process starts, it will record its process id
(“pid”) in a file, for use by the “ibmproxy -restart” command. This
directive specifies the location for that file. If you are
running multiple instances of the server on a single system, each
should have its own PidFile.
Default:
Syntax:
<server-root>/ibmproxy-pid
If no ServerRoot directive is given, then the default for
the PidFile is /tmp/ibmproxy-pid
PidFile <path-to-pid-file-into>
# ===================================================================== #
#
#
Logging directives
#
# ===================================================================== #
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
==============================
*** log file directives ***
==============================
If you want logging, specify locations for your logs:
AccessLog
ProxyAccessLog
CacheAccessLog
ErrorLog
EventLog
-
used
used
used
used
used
for
for
for
for
for
logging
logging
logging
logging
logging
local document requests
proxy requests
hits on proxy cache
any errors
initialization events
NOTE: To enable logging of requests to the proxy cache, the
following must be defined:
Caching MUST be turned ON (default is OFF)
CacheAccessLog MUST be defined
Defaults:
AccessLog
/opt/ibm/edge/cp/server_root/logs/local
ProxyAccessLog /opt/ibm/edge/cp/server_root/logs/proxy
Appendix A. Configuration files and scripts
517
#
#
#
#
Syntax:
CacheAccessLog /opt/ibm/edge/cp/server_root/logs/cache
ErrorLog
/opt/ibm/edge/cp/server_root/logs/error
EventLog
/opt/ibm/edge/cp/server_root/logs/event
<directive> <fullpath-filename>
CacheAccessLog
ProxyAccessLog
AccessLog
ErrorLog
EventLog
/opt/ibm/edge/cp/server_root/logs/cache
/opt/ibm/edge/cp/server_root/logs/proxy
/opt/ibm/edge/cp/server_root/logs/local
/opt/ibm/edge/cp/server_root/logs/error
/opt/ibm/edge/cp/server_root/logs/event
# LogFileFormat:
#
# Specify the format of the access log files.
# By default, logs are displayed in the NCSA Common Log Format.
# Specify “combined” to get the NCSA Combined Log Format instead.
# Entries in the combined format are the same as those in the
# common format with the addition of fields for the referring URL,
# User Agent, and Cookie (if present in the request). Certain site
# analysis tools, such as IBM’s Site Analyzer, require proxy logs
# to be in Combined format.
#
# Default: common
# Syntax: LogFileFormat <common | combined>
#
# LogFileFormat common
#
LogToSyslog directive:
#
#
In addition to logging access request information to the server logs,
#
you can send log entries to the UNIX syslog daemon.
#
#
Default: off
#
Syntax:
LogToSyslog <on | off>
#
LogToSyslog off
#
#
#
#
#
#
#
#
#
#
#
518
NoLog directive:
Suppress access log entries for host matching a given IP address
or hostname. Wild cards “*” may be used. This directive may be used
multiple times within the configuration file.
Default:
Syntax:
<none>
NoLog <hostnames and IP addresses>
NOTE: DNS-Lookup may need to be turned ON.
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
#
#
#
Example:
NoLog
128.141.*.*
NoLog
*.location.company.com
Nolog
*.*.*.com
#
LogVirtualHostName directive:
#
#
Log virtual host name into log files. The virtual host name will be
#
merged into URL or place at the beginning of each record. For the
#
record of HTTP 1.0 request without HOST header, the IP address of the
#
server will be recorded into log file.
#
#
Default: <none>
#
Syntax:
LogVirtualHostName < none | merged | beginning >
#
#
NOTE: DNS-Lookup may need to be turned ON.
#
# Example:
# LogVirtualHostName merged
# LogVirtualHostName beginning
# MaxLogFileSize directive:
#
# MaxLogFileSize specifies the maximum size for each log file. When
# a log file exceeds the specified size, it is closed, and a new file
# is opened for writing. A version number is appended to logfile names
# to distinguish log files of the same type created on the same day.
# The unit specified can be B (bytes), K (kilobytes), M (megabytes),
# or G (gigabytes).
#
# NOTE: Recommended size should be no more than one fourth of swap
# space.
#
# Default: <none>
# Syntax:
MaxLogFileSize <size> B | K | M | G
#
# Example:
# MaxLogFileSize 100 M
#
#
#
==============================
*** log archive directives ***
==============================
# LogArchive directive
#
Appendix A. Configuration files and scripts
519
#
Specify the type of archive processing to use.
#
#
Default: Purge
#
Syntax:
LogArchive <Compress | Purge | none>
#
LogArchive Purge
# Compress directives
#
#
If you specified “Compress” for LogArchive, specify:
#
- the age at which the log files should be compressed
#
- the age at which the log files should be deleted
#
- the compress command you want executed against the
#
log archive files
#
#
Default: 0
#
Syntax:
CompressAge <num>
#
Syntax:
CompressDeleteAge <num>
#
#
Default: <none>
#
Syntax:
CompressCommand <commpress-command>
#
CompressAge
1
CompressDeleteAge 7
# CompressCommand tar -cf /logarchs/log%%DATE%%.tar %%LOGFILES%% ; gzip
/logarchs/log%%DATE%%.tar
# CompressCommand tar -cf /logarchs/log%%DATE%%.tar %%LOGFILES%% ; compress
/logarchs/log%%DATE%%.tar
# CompressCommand zip -q /logarchs/log%%DATE%%.tar %%LOGFILES%%
# Purge directives
#
#
If you specified “Purge” for LogArchive,
#
specify the age and size (in Megabytes) limits
#
at which time the files should be purged.
#
#
Syntax:
PurgeAge <num>
#
Default: PurgeAge 7
#
Syntax:
PurgeSize <num>
#
Default: PurgeSize 0
#
PurgeAge
7
PurgeSize 0
#
#
520
====================================
*** log filtering directives ***
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
====================================
# AccessLogExcludeUserAgent directive
#
# A filter to exclude request URLs from user-agents that match a
# given template.
#
#
Default: Requests from Network Dispatcher’s HTTP and WTE advisors
#
will not be logged
#
Syntax: AccessLogExcludeUserAgent <User-Agent template>
#
AccessLogExcludeUserAgent IBM_Network_Dispatcher_HTTP_Advisor
AccessLogExcludeUserAgent IBM_Network_Dispatcher_WTE_Advisor
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
AccessLogExcludeURL, AccessLogExcludeMethod,
AccessLogExcludeReturnCode and AccessLogExcludeMimeType directive:
Access log entries may be filtered to exclude requests by:
* requests matching a given URL template
* requests of a given method
* requests with a given return code range (200s, 300s, 400s, 500s)
* requests for files of a given mime type
Default:
Syntax:
<none>
AccessLogExcludeURL
<URL template>
AccessLogExcludeMethod <GET | PUT | POST | DELETE>
AccessLogExcludeReturnCode <200 | 300 | 400 | 500>
AccessLogExcludeMimeType <text/html | text/plain |
text/other | image/gif |
image/jpeg | image/(other) |
application/* |
audio/* | video/* |
(other)/(other)>
Example:
AccessLogExcludeURL *.gif
AccessLogExcludeURL /Freebies/*
AccessLogExcludeMethod PUT
AccessLogExcludeMethod POST
AccessLogExcludeReturnCode 300
AccessLogExcludeReturnCode 400
AccessLogExcludeMimeType text/html
AccessLogExcludeMimeType text/plain
# ===================================================================== #
#
#
Method directives
Appendix A. Configuration files and scripts
521
#
# ===================================================================== #
#
#
HTTP Methods that you do or don’t want your server to accept.
#
#
NOTE: Please reference online documentation/help to specify or
#
create other methods.
#
#
Default: Enable
GET
#
Enable
HEAD
#
Enable
POST
#
Enable
TRACE
#
Enable
OPTIONS
#
Enable
CONNECT
#
Disable
PUT
#
Disable
DELETE
#
Syntax:
Enable <method>
#
Disable <method>
#
Enable
GET
Enable
HEAD
Enable
POST
Enable
TRACE
Enable
OPTIONS
Enable
CONNECT
Disable
Disable
PUT
DELETE
# ===================================================================== #
#
#
Content presentation directives
#
# ===================================================================== #
#
#
#
#
#
#
#
#
#
#
#
522
==============================
*** Welcome pages ***
==============================
Welcome directive:
Specifies the default file name to use when only a directory name is
specified in the URL. Many Welcome directives may be defined, with the
one defined earliest having precedence.
Multi-homed servers can use the IP-address_template parameter to
specify an address template which restricts the server to displaying
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
a specific welcome page based on which address template matches.
#
#
NOTE: the address of the servers network connection is compared
#
to the template, not the address of the requesting client.
#
#
Defaults: Welcome.html, welcome.html, index.html, Frntpage.html
#
Syntax:
Welcome file-name [IP-address-template]
#
# Example:
# Welcome letsgo.html
# Welcome CustomerA.html 9.67.106.79
Welcome
Welcome.html
Welcome
welcome.html
Welcome
index.html
Welcome
Frntpage.html
#
#
#
=====================================
*** Directory browsing directives ***
=====================================
#
These directives control directory listings as follows:
#
* Enable/disable or selective directory browsing
#
* Configure/disable readme feature for directory browsing
#
* Control the appearance of the directory listing
#
* Define the maximum width of the description text
#
* Define the maximum & minimum width of the filename field
#
#
Default: DirShowIcons
on
#
DirShowDate
on
#
DirShowSize
on
#
DirShowDescription on
#
DirShowCase
on
#
DirShowHidden
on
#
DirShowBytes
off
#
Syntax:
<directive> <on | off>
#
#
Default: DirShowMaxDescrLength 25
#
DirShowMaxLength
25
#
DirShowMinLength
15
#
Syntax:
<directive> <num>
DirShowIcons
on
DirShowDate
on
DirShowSize
on
DirShowDescription
on
DirShowCase
on
DirShowHidden
on
DirShowBytes
off
DirShowMaxDescrLength 25
Appendix A. Configuration files and scripts
523
DirShowMaxLength
DirShowMinLength
25
15
#
FTPDirInfo directive:
#
#
FTP servers may generate a welcome or description message for
#
a directory. This can optionally be displayed as part of FTP
#
directory listings; in addition, you can control where it will
#
be displayed. The following options are available:
#
#
FTPDirInfo top display welcome message at the top of the page,
#
before the listing of files in the directory.
#
FTPDirInfo bottom - display welcome message at the bottom of the page,
#
after the listing of files in the directory.
#
FTPDirInfo off
- do not display the welcome message from the
#
FTP server.
#
#
Note that this directive gives no control over the content of the
#
message itself; that message will be generated by the FTP server
#
being contacted.
#
#
Default:
FTPDirInfo top
#
Syntax:
FTPDirInfo <top | bottom | off>
#
# Example: don’t display welcome messages from FTP servers
# FTPDirInfo off
FTPDirInfo top
#
DirBackgroundImage directive:
#
#
This directive allows applying a background image to directory
#
listings generated by the proxy. Directory listings are generated
#
when browsing FTP sites through the proxy.
#
#
The background image should be given as an absolute path. If the
#
image is located at another server, the background image must
#
be specified as a full URL.
#
#
If no background image is specified, a plain white background will
#
be used.
#
#
Default:
no background image specified
#
Syntax:
DirBackgroundImage /some/image.jpg
#
# Example: use /images/corplogo.png as background graphic
# DirBackgroundImage /images/corplogo.png
#
524
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
# Example: use /graphics/embossed.gif on Web server www.somehost.com as
# background graphic
# DirBackgroundImage http://www.somehost.com/graphics/embossed.gif
#
#
#
=====================================
*** CGI program directives ***
=====================================
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
InheritEnv and DisInheritEnv directives:
Default: <none>
Syntax:
InheritEnv
<variable>
Syntax:
DisInheritEnv <variable>
Example:
InheritEnv PATH
InheritEnv LANG=ENUS
DisInheritEnv PATH
DisInheritEnv LANG
#
#
#
=====================================
*** Content type directives ***
=====================================
InheritEnv
- Specify which environment variables are
inherited by CGI programs.
DisInheritEnv - Specify which environment variables are
disinherited by CGI programs.
By default (if neither statement is used), all environment
variables are inherited by CGI programs. If you include any
InheritEnv directive, only those environment variables
specified on InheritEnv directives will be inherited. To
exclude individual environment variables from being inherited,
use the DisInheritEnv directive.
#
#
#
#
#
##
#
#
NOTE: Refer to the WTE Programming Guide for a list
of the CGI-specific environment variables.
imbeds directive:
Controls Server Side Include processing for output that has
Content-type: text/x-ssi-html.
Default:
Syntax:
off SSIOnly
imbeds <on | off | files | cgi | noexec> <html | SSIOnly>
Appendix A. Configuration files and scripts
525
#
#
#
#
#
#
#
#
#
imbeds on SSIOnly
parm1: on
off
files
cgi
noexec
process files, CGIs and SSI
never use SSI
process files and SSI #exec
process CGIs and SSI #exec
process files, CGIs but not
#exec CGI
parm2: html
SSIOnly
also process Content-type: text/html
process Content-type: text/x-ssi-html only
CGI
CGI
SSI #exec CGI
#
SuffixCaseSense directive:
#
#
Specify whether case sensitivity for suffixes is on or off.
#
#
Default: off
#
Syntax:
SuffixCaseSense <on | off>
#
#
NOTE: This directive should be placed BEFORE any AddType or
#
AddEncoding directives.
#
SuffixCaseSense
off
#
AcceptAnything directive:
#
#
If this is set to ON, documents will be served to the client even
#
if the MIME type of the document does not match an Accept:
#
header sent by the client. If this is OFF, documents with a MIME type
#
which the client doesn’t not state that they understand will cause
#
the client to see an error page instead.
#
#
Default: ON
#
Syntax:
AcceptAnything <on | off>
#
#
AcceptAnything
on
#
#
#
#
#
#
#
#
AddType directive:
Map a suffix to the content-type of a file.
Defaults:
Syntax:
see list below
Addtype <.suffix><representation><encoding><quality>
where <quality> is optional
# Application-specific types
526
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
AddType .bcpio
application/x-bcpio
CPIO
AddType .cpio
application/x-cpio
AddType .gtar
application/x-gtar
AddType .bin
application/octet-stream
Uninterpreted binary
AddType .class
application/octet-stream
or application
AddType .dms
application/octet-stream
AddType .exe
application/octet-stream
MSDOS/OS2/WIN executables
AddType .dll
application/octet-stream
executables
AddType .lha
application/octet-stream
AddType .lzh
application/octet-stream
data
AddType .oda
application/oda
AddType .pdf
application/pdf
AddType .ai
application/postscript
Illustrator
AddType .PS
application/postscript
AddType .eps
application/postscript
AddType .ps
application/postscript
AddType .rtf
application/rtf
AddType .sit
application/stuffit
compressor
AddType .csh
application/x-csh
script
AddType .dvi
application/x-dvi
AddType .hdf
application/x-hdf
data file
AddType .latex
application/x-latex
AddType .nc
application/x-netcdf
netCDF data
AddType .cdf
application/x-netcdf
AddType .js
application/x-javascript
AddType .sh
application/x-sh
AddType .shar
application/x-shar
archive
AddType .sv4cpio application/x-sv4cpio
AddType .sv4crc
application/x-sv4crc
with CRC
AddType .tcl
application/x-tcl
AddType .tex
application/x-tex
AddType .texi
application/x-texinfo
AddType .texinfo application/x-texinfo
AddType .t
application/x-troff
AddType .roff
application/x-troff
AddType .tr
application/x-troff
binary
1.0 # Old binary
binary
binary
binary
1.0 # POSIX CPIO
1.0 # Gnu tar
1.0 #
binary
1.0 # Java applet
binary
binary
1.0 #
0.8 #
binary
0.8 # OS2/WIN
binary
binary
0.8 # LHArc
0.8 # Compressed
binary
binary
8bit
1.0
1.0
0.5 # Adobe
8bit
8bit
8bit
7bit
binary
0.8 # PostScript
0.8
0.8
1.0 # RTF
1.0 # Mac StuffIt
7bit
0.5 # C-shell
binary
binary
1.0 # TeX DVI
1.0 # NCSA HDF
8bit
binary
1.0 # LaTeX source
1.0 # Unidata
binary
binary
7bit
8bit
1.0
1.0 # Java script
0.5 # Shell-script
1.0 # Shell
binary
binary
1.0 # SVR4 CPIO
1.0 # SVR4 CPIO
7bit
8bit
7bit
7bit
7bit
7bit
7bit
0.5
1.0
1.0
1.0
0.5
0.5
0.5
# TCL-script
# TeX source
# Texinfo
# Troff
Appendix A. Configuration files and scripts
527
AddType .man
application/x-troff-man
7bit
0.5 # Troff with
man macros
AddType .me
application/x-troff-me
7bit
0.5 # Troff with
me macros
AddType .ms
application/x-troff-ms
7bit
0.5 # Troff with
ms macros
AddType .src
application/x-wais-source
7bit
1.0 # WAIS source
AddType .prs
application/x-freelance
binary 1.0 # Lotus
Freelance
AddType .pre
application/vnd.lotus-freelance binary 1.0 # Lotus
Freelance
AddType .prz
application/vnd.lotus-freelance binary 1.0 # Lotus
Freelance
AddType .lwp
application/vnd.lotus-wordpro
binary 1.0 # Lotus Word
Pro
AddType .sam
application/vnd.lotus-wordpro
binary 1.0 # Lotus Word
Pro
AddType .apr
application/vnd.lotus-approach
binary 1.0 # Lotus
Approach
AddType .vew
application/vnd.lotus-approach
binary 1.0 # Lotus
Approach
AddType .123
application/vnd.lotus-1-2-3
binary 1.0 # Lotus 1-2-3
AddType .wk1
application/vnd.lotus-1-2-3
binary 1.0 # Lotus 1-2-3
AddType .wk3
application/vnd.lotus-1-2-3
binary 1.0 # Lotus 1-2-3
AddType .wk4
application/vnd.lotus-1-2-3
binary 1.0 # Lotus 1-2-3
AddType .org
application/vnd.lotus-organizer binary 1.0 # Lotus
Organizer
AddType .or2
application/vnd.lotus-organizer binary 1.0 # Lotus
Organizer
AddType .or3
application/vnd.lotus-organizer binary 1.0 # Lotus
Organizer
AddType .scm
application/vnd.lotus-screencam binary 1.0 # Lotus
Screencam
AddType .ppt
application/vnd.microsoft-powerpoint binary 1.0 # MS
PowerPoint
AddType .pac
application/x-ns-proxy-autoconfig binary 1.0 # Netscape
proxy Autoconfig files
AddType .hqx
application/mac-binhex40
binary 1.0 # Macintosh
BinHex format
AddType .bsh
application/x-sh
7bit
0.5 # Bourne shell
script
AddType .ksh
application/x-ksh
7bit
0.5 # K-shell
script
AddType .pcl
application/x-pcl
7bit
0.5 #
AddType .wk1
application/x-123
binary 1.0 #
# Audio files
AddType .snd
AddType .au
528
audio/basic
audio/basic
binary
binary
1.0 # Audio
1.0
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
AddType .mid
AddType .midi
AddType .kar
AddType .mpga
AddType .mp2
AddType .mp3
AddType .aiff
AddType .aifc
AddType .aif
AddType .ra
AddType .ram
AddType .rpm
AddType .wav
WAVE format
audio/midi
audio/midi
audio/midi
audio/mpeg
audio/mpeg
audio/mpeg
audio/x-aiff
audio/x-aiff
audio/x-aiff
audio/x-realaudio
audio/x-pn-realaudio
audio/x-pn-realaudio-plugin
audio/x-wav
binary
binary
binary
binary
binary
binary
binary
binary
binary
binary
binary
binary
binary
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0 # Windows+
AddType
AddType
chemical/x-pdb
chemical/x-pdb
binary
binary
0.8
0.8
binary
1.0 # OS/2 bitmap
binary
binary
binary
1.0
1.0 # GIF
1.0 # Image
binary
binary
binary
binary
binary
binary
binary
1.0 # JPEG
1.0
1.0
1.0
1.0
1.0
1.0 # Portable
binary
binary
binary
1.0 # TIFF
1.0
1.0 # PBM Anymap
binary
1.0 # PBM Bitmap
binary
1.0 # PBM Graymap
binary
1.0 # PBM Pixmap
binary
binary
binary
1.0
1.0 # X bitmap
1.0 # X pixmap
binary
1.0 # X window
.pdb
.xyz
# Graphic (image) types
AddType .bmp
image/bmp
format
AddType .ras
image/x-cmu-raster
AddType .gif
image/gif
AddType .ief
image/ief
Exchange fmt
AddType .jpg
image/jpeg
AddType .JPG
image/jpeg
AddType .JPE
image/jpeg
AddType .jpe
image/jpeg
AddType .JPEG
image/jpeg
AddType .jpeg
image/jpeg
AddType .png
image/png
Network Graphics
AddType .tif
image/tiff
AddType .tiff
image/tiff
AddType .pnm
image/x-portable-anymap
format
AddType .pbm
image/x-portable-bitmap
format
AddType .pgm
image/x-portable-graymap
format
AddType .ppm
image/x-portable-pixmap
format
AddType .rgb
image/x-rgb
AddType .xbm
image/x-xbitmap
AddType .xpm
image/x-xpixmap
format
AddType .xwd
image/x-xwindowdump
dump (xwd)
Appendix A. Configuration files and scripts
529
# “Multipart” (containers)
AddType .tar
multipart/x-tar
tar
AddType .ustar
multipart/x-ustar
AddType .zip
multipart/x-zip
# Text file types
AddType .css
text/css
Cascading Style Sheets
AddType .html
text/html
AddType .htm
text/html
AddType .c
text/plain
AddType .h
text/plain
AddType .C
text/plain
AddType .cc
text/plain
AddType .hh
text/plain
AddType .java
text/plain
AddType .m
text/plain
source
AddType .f90
text/plain
source
AddType .txt
text/plain
AddType .cxx
text/plain
AddType .for
text/plain
AddType .mar
text/plain
AddType .log
text/plain
AddType .com
text/plain
AddType .sdml
text/plain
AddType .list
text/plain
AddType .lst
text/plain
AddType .def
text/plain
files
AddType .conf
text/plain
files
AddType .
text/plain
no extension
AddType .rtx
text/richtext
Richtext format
AddType .tsv
text/tab-separated-values
Tab-separated values
AddType .etx
text/x-setext
Enchanced Txt
AddType .asm
text/x-asm
AddType .sgm
text/x-sgml
AddType .sgml
text/x-sgml
AddType .htmls
text/x-ssi-html
includes
530
binary
1.0 # 4.
binary
binary
1.0 # POSIX tar
1.0 # PKZIP
8bit
1.0 # W3C
8bit
8bit
7bit
7bit
7bit
7bit
7bit
7bit
7bit
1.0
1.0
0.5
0.5
0.5
0.5
0.5
0.5
0.5
7bit
0.5 # Fortran 90
7bit
7bit
7bit
7bit
7bit
7bit
7bit
7bit
7bit
7bit
0.5
0.5
0.5
0.5
0.5
0.5
0.5
0.5
0.5
0.5
7bit
0.5 # definition
7bit
0.5 # files with
7bit
1.0 # MIME
7bit
1.0 #
7bit
0.9 # Struct
7bit
8bit
8bit
8bit
1.0
1.0
1.0
1.0
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
3BSD
HTML
HTML on PCs
C source
C headers
C++ source
C++ source
C++ headers
Java source
Objective-C
Plain text
C++
Fortran
MACRO
logfiles
scripts
SDML
listfiles
listfiles
definition
ASM source
SGML source
SGML source
Server-side
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
AddType .shtml
includes
AddType .uil
AddType .uu
# Video formats
AddType .mpg
AddType .mpe
AddType .mpeg
AddType .qt
AddType .mov
AddType .avi
Windows
AddType .movie
movieplayer
AddType .mjpg
text/x-ssi-html
8bit
1.0 # Server-side
text/x-uil
text/x-uuencode
8bit
8bit
1.0 #
1.0 #
video/mpeg
video/mpeg
video/mpeg
video/quicktime
video/quicktime
video/x-msvideo
binary 1.0
binary 1.0
binary 1.0
binary 1.0 # QuickTime
binary 1.0
binary 1.0 # MS Video for
video/x-sgi-movie
binary
1.0 # SGI
video/x-motion-jpeg
binary
1.0 #
binary
1.0 # Internal --
binary
binary
1.0
1.0 # VRML
binary
binary
0.1 # Try to guess
0.1 # Try to guess
# “WWW” - internal - types
AddType .mime
www/mime
MIME is not recursive
# Extension types
AddType .ice
AddType .wrl
x-conference/x-cooltalk
x-world/x-vrml
# When all else fails...
AddType *.*
application/octet-stream
AddType *
application/octet-stream
#
AddEncoding directive:
#
#
Map a suffix to a MIME content encoding.
#
These are usually extra suffixes that modify the base file.
#
#
Defaults: <none>
#
Syntax:
AddEncoding <.suffix><encoding>
AddEncoding
.Z
x-compress
1.0
# Compressed data
AddEncoding
.gz
x-gzip
1.0
# Compressed data
# ===================================================================== #
#
#
Error Message directives
#
# ===================================================================== #
Appendix A. Configuration files and scripts
531
#
ErrorPage directive:
#
#
Specifies the html file name to be returned by the server to the
#
client when a specific error occurs.
#
#
NOTE: Please see online documentation for a list of keywords.
#
#
Default: <none>
#
Syntax:
ErrorPage <keyword> </path/filename.html>
#
# Example:
# ErrorPage scriptstart /errorpages/scriptstart.html
#
ErrorPage badrange
/errorpages/badrange.htmls
ErrorPage badredirect
/errorpages/badredirect.htmls
ErrorPage badrequest
/errorpages/badrequest.htmls
ErrorPage badscript
/errorpages/badscript.htmls
ErrorPage baduser
/errorpages/baduser.htmls
ErrorPage blocked
/errorpages/blocked.htmls
ErrorPage byrule
/errorpages/byrule.htmls
ErrorPage cacheexp
/errorpages/cacheexp.htmls
ErrorPage cachenoconn
/errorpages/cachenoconn.htmls
ErrorPage cachenotopened
/errorpages/cachenotopened.htmls
ErrorPage cacheonly
/errorpages/cacheonly.htmls
ErrorPage connectfail
/errorpages/connectfail.htmls
ErrorPage deletefailed
/errorpages/deletefailed.htmls
ErrorPage dirbrowse
/errorpages/dirbrowse.htmls
ErrorPage dirnobrowse
/errorpages/dirnobrowse.htmls
ErrorPage dotdot
/errorpages/dotdot.htmls
ErrorPage expectfailed
/errorpages/expectfailed.htmls
ErrorPage ftpanonloginrej
/errorpages/ftpanonloginrej.htmls
ErrorPage ftpauth
/errorpages/ftpauth.htmls
ErrorPage ftpbad220
/errorpages/ftpbad220.htmls
ErrorPage ftphpanonloginrej
/errorpages/ftphpanonloginrej.htmls
ErrorPage ftphpbad220
/errorpages/ftphpbad220.htmls
ErrorPage ftphploginrej
/errorpages/ftphploginrej.htmls
ErrorPage ftphpnoconnect
/errorpages/ftphpnoconnect.htmls
ErrorPage ftphpnoresponse
/errorpages/ftphpnoresponse.htmls
ErrorPage ftphpnosocket
/errorpages/ftphpnosocket.htmls
ErrorPage ftphpunreshost
/errorpages/ftphpunreshost.htmls
ErrorPage ftploginrej
/errorpages/ftploginrej.htmls
ErrorPage ftploginreq
/errorpages/ftploginreq.htmls
ErrorPage ftpnoconnect
/errorpages/ftpnoconnect.htmls
ErrorPage ftpnodata
/errorpages/ftpnodata.htmls
ErrorPage ftpnoresponse
/errorpages/ftpnoresponse.htmls
ErrorPage ftpnosocket
/errorpages/ftpnosocket.htmls
ErrorPage ftpunrechost
/errorpages/ftpunrechost.htmls
ErrorPage ftpunreshost
/errorpages/ftpunreshost.htmls
532
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
ErrorPage
hpforbidden
httpnodata
httpnoforward
httpnosend
httpunreshost
ipmask
ipmaskproxy
methoddisabled
multifail
noaccess
noacl
nocachenoconn
noentry
noformat
nohostheader
noopen
nopartner
norep
notallowed
notauthorized
notfound
notmember
olproxnocontact
openfailed
originbadresp
preconfail
proxybadurl
proxyfail
proxynotauth
proxynotmember
putfailed
rchunkerror
rchunkmemory
scriptinterr
scriptio
scriptnocomm
scriptnotfound
scriptnovari
scriptstart
servermaperror
setuperror
throttled
unknownmethod
outputtimeout
/errorpages/hpforbidden.htmls
/errorpages/httpnodata.htmls
/errorpages/httpnoforward.htmls
/errorpages/httpnosend.htmls
/errorpages/httpunreshost.htmls
/errorpages/ipmask.htmls
/errorpages/ipmaskproxy.htmls
/errorpages/methoddisabled.htmls
/errorpages/multifail.htmls
/errorpages/noaccess.htmls
/errorpages/noacl.htmls
/errorpages/nocachenoconn.htmls
/errorpages/noentry.htmls
/errorpages/noformat.htmls
/errorpages/nohostheader.htmls
/errorpages/noopen.htmls
/errorpages/nopartner.htmls
/errorpages/norep.htmls
/errorpages/notallowed.htmls
/errorpages/notauthorized.htmls
/errorpages/notfound.htmls
/errorpages/notmember.htmls
/errorpages/olproxnocontact.htmls
/errorpages/openfailed.htmls
/errorpages/originbadresp.htmls
/errorpages/preconfail.htmls
/errorpages/proxybadurl.htmls
/errorpages/proxyfail.htmls
/errorpages/proxynotauth.htmls
/errorpages/proxynotmember.htmls
/errorpages/putfailed.htmls
/errorpages/rchunkerror.htmls
/errorpages/rchunkmemory.htmls
/errorpages/scriptinterr.htmls
/errorpages/scriptio.htmls
/errorpages/scriptnocomm.htmls
/errorpages/scriptnotfound.htmls
/errorpages/scriptnovari.htmls
/errorpages/scriptstart.htmls
/errorpages/servermaperror.htmls
/errorpages/setuperror.htmls
/errorpages/throttled.htmls
/errorpages/unknownmethod.htmls
/errorpages/outputtimeout.htmls
# ===================================================================== #
#
Appendix A. Configuration files and scripts
533
#
API directives:
#
# ===================================================================== #
# API directives enabling plug-ins distributed with this product should appear
# before any user-defined plug-ins. Add user-defined plug-ins only to the end
# of this section (see Placeholder comment below).
#
ServerInit directive:
#
#
Specify a customized application function you want the server
#
to call during the server’s initialization routines. This code
#
will be executed before any client requests are read.
#
#
Default: <none>
#
Syntax:
ServerInit </path/file:function_name>
#
# Example:
# ServerInit /opt/ibm/edge/cp/samples/libsample_plugin.so:svr_init
#
PreExit directive:
#
#
Specify a customized application function you want the server to
#
call during the User PreExit step. This code will be executed after
#
a client request has been read but before any other processing
#
occurs. You can call the goserve module during this step.
#
#
Default: <none>
#
Syntax:
PreExit </path/file:function_name>
#
# Example:
# PreExit /opt/ibm/edge/cp/samples/libsample_plugin.so:pre_exit
#
Authentication directive:
#
#
Specify a customized application function you want the server to
#
call during the Authentication step. This code will be executed based
#
on the authentication scheme. Currently, only Basic authentication
#
is supported.
#
#
Default: <none>
#
Syntax:
Authentication <type> </path/file:function_name>
#
# Example:
534
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
# Authentication BASIC
/opt/ibm/edge/cp/samples/libsample_plugin.so:basic_authen
#
NameTrans directive:
#
#
Specify a customized application function you want the server
#
to call during the Name Translation step. This code would supply
#
the mechanism for translating the virtual path in the request to
#
the physical path on the server, mapping URLs to specific objects.
#
#
Default: <none>
#
Syntax:
NameTrans </URL> </path/file:function_name>
<IP_address_template>
#
# Example:
# NameTrans /index.html /opt/ibm/edge/cp/samples/libsample_plugin.so:trans_url
#
Authorization directive:
#
#
Specify a customized application function you want the server
#
to call during the Authorization step. This code would verify
#
that the requested object can be served to the client.
#
#
Default: <none>
#
Syntax:
Authorization </URL> </path/file:function_name>
#
# Example:
# Authorization /index.html
/opt/ibm/edge/cp/samples/libsample_plugin.so:auth_url
#
ObjectType directive:
#
#
Specify a customized application function you want the server
#
to call during the Object Type step. This code would locate the
#
requested object in the file system and identify its MIME type.
#
#
Default: <none>
#
Syntax:
ObjectType </URL> </path/file:function_name>
#
# Example:
# ObjectType /index.html /opt/ibm/edge/cp/samples/libsample_plugin.so:obj_type
#
#
#
PostAuth directive:
Specify a customized application function you want the server to
Appendix A. Configuration files and scripts
535
#
call during the User PostAuth step. This code will be executed after
#
authorization/authentication and objecttype(if any) steps.
#
#
Default: <none>
#
Syntax:
PostAuth </path/file:function_name>
#
# Example:
# PostAuth /opt/ibm/edge/cp/samples/libsample_plugin.so:post_auth
#
Service directive:
#
#
Specify a customized application function you want the server
#
to call during the Service step. This code would service the client
#
request. For example, it sends the file or runs the CGI program.
#
#
Default: <none>
#
Syntax:
Service </URL> </path/file:function_name>
<IP_address_template>
#
# Example:
# Service /index.html
/opt/ibm/edge/cp/samples/libsample_plugin.so:serve_req
#
Transmogrifier directive:
#
#
Specify a customized application function you want the server
#
to call during the Transmogrifier step. This code would provide four
#
application functions: an open function, a write function, a close
#
function, and an error function.
#
#
Default: <none>
#
Syntax:
Transmogrifier
</path/file:open_function_name:write_function_name:close_function_name:error_fu
nction_name>
#
# Example:
# Transmogrifier
/opt/ibm/edge/cp/samples/libsample_plugin.so:my_open:my_write:my_close:my_error
#
#
#
proxy
#
message
#
data has
536
TransmogrifiedWarning directive:
When a customized application function is specified that you want the
to call during the Transmogrifier step, WTE will send a warning
(e.g. “Warning: 214 hostname”) to the client informing it that the
been
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
transmogrified. In some cases, a browser that receives this message
will fail
#
with an ‘unknown error’ message. This Directive allows the
administrator to
#
disable the warning message sent from the proxy.
#
#
Default: <YES>
#
#
Syntax:
transmogrifiedwarning <YES | NO>
#
Log directive:
#
#
Specify a customized application function you want the server
#
to call during the Log step. This code would supply logging and
#
other processing you want performed after the connection has
#
been closed.
#
#
Default: <none>
#
Syntax:
Log </URL> </path/file:function_name>
#
# Example:
# Log /index.html /opt/ibm/edge/cp/samples/libsample_plugin.so:log_url
#
Error directive:
#
#
Specify a customized application function you want the server
#
to call during the Error step. This code would execute only when
#
an error is encountered to provide customized error routines.
#
#
Default: <none>
#
Syntax:
Error </URL> </path/file:function_name>
#
# Example:
# Error /index.html /opt/ibm/edge/cp/samples/libsample_plugin.so:error_rtns
#
PostExit directive:
#
#
Specify a customized application function you want the server
#
to call during the Post-exit step. This code will be executed
#
regardless of the return codes from previous steps. It allows
#
you to clean up any resources allocated to process the request.
#
#
Default: <none>
#
Syntax:
PostExit </path/file:function_name>
#
# Example:
Appendix A. Configuration files and scripts
537
# PostExit /opt/ibm/edge/cp/samples/libsample_plugin.so:post_exit
#
ServerTerm directive:
#
#
Specify a customized application function you want the server
#
to call during the Server Termination step. This code would
#
execute when an orderly shutdown occurs and allows you to
#
release resources allocated by a PreExit application function.
#
#
Default: <none>
#
Syntax:
ServerTerm </path/file:function_name>
#
# Example:
# ServerTerm /opt/ibm/edge/cp/samples/libsample_plugin.so:shut_down
#
#
#
#
#
#
#
Midnight
Midnight directive:
Specify a customized application function you want the server
to call at midnight.
Default: Midnight /usr/lib/archive.so:begin
Syntax:
Midnight </path/file:function_name>
/usr/lib/archive.so:begin
#
# Following are directives used for Transaction Quality of Service
#
# For ServerInit there are three parameters:
#
debug
- Which should be set only when asked by IBM Service
#
This issues many debug information lines of output
#
useqoscookies - Specify this if cookies should be sent from
#
the proxy to the backend server and from the
#
proxy back to the client.
#
eventlog
- Specify this if classification events should be
#
written to the EventLog file. This is helpful
#
for verifying classification results.
#
#
# Note: TQoS debug info goes into TraceLog file
#
TQoS classfication info goes into EventLog file
#
TQoS error info goes into ErrorLog file
#==========================================================================
#
# QualityofService
on
# ServerInit
/opt/ibm/edge/tqos/lib/libtqosplugin.so:tqos_server_init useqoscookies,eventlog
# PostAuth
/opt/ibm/edge/tqos/lib/libtqosplugin.so:tqos_postaut
538
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
# Transmogrifier
/opt/ibm/edge/tqos/lib/libtqosplugin.so:tqos_topen:tqos_twrite:tqos_tclose:tqos
_terror
# ServerTerm
/opt/ibm/edge/tqos/lib/libtqosplugin.so:tqos_server_term
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
The following directives are used by the Content Distribution Framework.
CdfAware
This directive is used to mark this WTE instance as being part of a
Content Distribution Framework
CdfRestartFile
WTE maintains a mapping table that associates a requested URL to its filename
on the webserver. This file is used for persistent storage of this table
so as to preserve its contents during restarts
ServerInit
This directive is required to load the Content Distribution Agent which is
distributed as a plugin
=============================================================
CdfAwareyes
CdfRestartFile/opt/ibm/edge/cdist/data/cdfRestartFile
# ServerInit/opt/ibm/edge/cdist/lib/libcpagent.so:cdca_Start
#
#
#
#
#
#
Following are examples of the API directives required by the
plug-ins distributed with this product. Uncomment (and edit,
if necessary) these directives to include support for each
desired plug-in.
These plug-in API directives should be included in this order.
Plug-ins may not work correctly together if reordered.
# ===== ICP Plug-in =====
# Uncomment ServerInit to enable an ICP server. Uncomment PreExit to enable an
ICP client.
# ServerInit /opt/ibm/edge/cp/lib/plugins/icp/libicp_plugin.so:icpServer
# PreExit /opt/ibm/edge/cp/lib/plugins/icp/libicp_plugin.so:icpClient
Appendix A. Configuration files and scripts
539
#
#
#
#
#
===== CBR Plug-in =====
ServerInit /opt/ibm/edge/lb/servers/lib/libndcbr.so:ndServerInit
PostAuth /opt/ibm/edge/lb/servers/lib/libndcbr.so:ndPostAuth
PostExit /opt/ibm/edge/lb/servers/lib/libndcbr.so:ndPostExit
ServerTerm /opt/ibm/edge/lb/servers/lib/libndcbr.so:ndServerTerm
# ===== LDAP Plug-in =====
# ServerInit /opt/ibm/edge/cp/lib/plugins/pac/libpacwte.so:pacwte_auth_init
/etc/paccp.conf
# Authorization http://protectarea
/opt/ibm/edge/cp/lib/plugins/pac/libpacwte.so:pacwte_auth_policy
# ServerTerm /opt/ibm/edge/cp/lib/plugins/pac/libpacwte.so:pacwte_shutdown
# ===== JSP Plug-in =====
# Service /WES_External_Adapter
/opt/ibm/edge/cp/lib/plugins/dynacache/libdyna_plugin.so:exec_dynacmd
# ===== Application Router Plug-in =====
# ServerInit
/opt/ibm/edge/cp/lib/plugins/approuter/libapprouter.so:approuter_init
# PostAuth
/opt/ibm/edge/cp/lib/plugins/approuter/libapprouter.so:approuter_offload
# ServerTerm
/opt/ibm/edge/cp/lib/plugins/approuter/libapprouter.so:approuter_term
# The following directive allows automatic disabling of the edge application
# offload on exception conditions.
# Log *
/opt/ibm/edge/cp/lib/plugins/approuter/libapprouter.so:approuter_failover
# ===== Junction URL Rewrite Plug-in =====
# ServerInit /opt/ibm/edge/cp/lib/plugins/mod_rewrite/libmod_rw.so:modrw_init
# Transmogrifier
/opt/ibm/edge/cp/lib/plugins/mod_rewrite/libmod_rw.so:modrw_open:modrw_write:mo
drw_close:modrw_error
# ===== Placeholder - add new user-defined plug-ins here =====
# ===================================================================== #
#
#
User authentication and document protection
#
# ===================================================================== #
#
#
540
Within the configuration file, three directives define file
access protection: Protect, DefProt, and Protection.
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
A Protection setup contains subdirectives that define how a set
of resources is to be protected. The protection setup is used on
a DefProt or Protect directive. The subdirectives can be coded
* on a preceding Protection directive
* in-line on the DefProt or Protect directive
* in a separate protection file
The Protect and DefProt directives define the association of a
Protection setup with a set of resources to be protected.
* The DefProt statement associates a Protection setup with a URL
template but does not activate protection.
* The Protect statement associates a Protection setup with a URL
template and activates the protection.
If your server has multiple network connections, you can optionally
specify an address template on either the DefProt or Protect directive
to restrict the server to using the directive only for requests that
come to the server on a connection with an address matching the
template.
NOTE: The address of the server’s network connection is compared to
the template, NOT the address of the requesting client.
You can specify a complete IP address (for example, FOR 9.67.106.79),
or you can use a wildcard(*) character and specify a template
(for example, FOR 9.83.*).
Protection directive:
Default: <none>
Syntax: Protection setup-name { directives }
Within the braces, any combination of twelve (12) possible
protection subdirectives can be defined:
UserID, GroupID, ServerID, AuthType,
GetMask, PutMask, PostMask, DeleteMask, Mask,
PasswdFile, GroupFile
Protect directive:
Default: <none>
Syntax for a Protect directive pointing to a Protection directive:
Protect request-template setup-name [FOR IP-address-label]
Syntax for a Protect directive with protection settings defined
inline:
Appendix A. Configuration files and scripts
541
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
542
Protect request-template [IP-address-label] {
protection setting
protection setting
.
.
.
}
Example:
Protect /secret/*
Protect /secret/*
CustomerA-PROT
{
ServerID
ServerName
AuthType
Basic
PasswdFile /docs/www/restricted.pwd
GroupFile /docs/www/restricted.grp
GetMask authors
}
Protect /secret/* CustomerA-PROT FOR 9.67.106.79
Protect /secret/* 9.83.* {
ServerID
ServerName
AuthType
Basic
PasswdFile /docs/www/restricted.pwd
GroupFile /docs/www/restricted.grp
GetMask
authors
}
DefProt directive:
Syntax for a DefProt directive pointing to a Protection directive:
DefProt request-template setup-name [FOR IP-address-label]
Syntax for a DefProt directive with protection settings defined
inline:
DefProt request-template [IP-address-label] {
protection setting
protection setting
.
.
.
}
Example:
DefProt /secret/*
DefProt /secret/*
CustomerA-PROT
{
ServerID
ServerName
AuthType
Basic
PasswdFile /docs/www/restricted.pwd
GroupFile /docs/www/restricted.grp
GetMask
authors
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
}
# DefProt /secret/* CustomerA-PROT FOR 9.67.106.79
# DefProt /secret/* 9.83.* {
#
ServerID
ServerName
#
AuthType
Basic
#
PasswdFile /docs/www/restricted.pwd
#
GroupFile /docs/www/restricted.grp
#
GetMask
authors
#
}
#
#
#
Example DefProt and Protect and Protection directives:
#
#
Protection setup by usernames; specify groups in the group
#
file, if you need groups; create and maintain password files
#
with the htadm program.
#
# Protection PROT-SETUP-USERS {
#
ServerId
YourServersFancyName
#
AuthType
Basic
#
PasswdFile
/where/ever/passwd
#
GroupFile
/where/ever/group
#
GET-Mask
user, user, group, group, user
# }
#
#
#
Protection setup by hosts; you can use both domain name
#
templates and IP number templates
#
# Protection PROT-SETUP-HOSTS {
#
ServerId
YourServersFancyName
#
AuthType
Basic
#
PasswdFile
/where/ever/passwd
#
GroupFile
/where/ever/group
#
GET-Mask
@(*.cern.ch, 128.141.*.*, *.ncsa.uiuc.edu)
# }
# DefProt /very/secret/URL/*
# Protect /very/secret/URL/*
PROT-SETUP-USERS
# Protect /another/secret/URL/* PROT-SETUP-HOSTS
#
Protection PROT-ADMIN {
ServerId
Private_Authorization
AuthType
Basic
GetMask
All@(*)
PutMask
All@(*)
PostMask
All@(*)
Mask
All@(*)
PasswdFile
/opt/ibm/edge/cp/server_root/protect/webadmin.passwd
}
Appendix A. Configuration files and scripts
543
Protect /admin-bin/* PROT-ADMIN
Protect /reports/*
PROT-ADMIN
Protect /Usage*
PROT-ADMIN
Service /ndadvisor
Service /Usage*
Service /admin-bin/trace*
INTERNAL:NDAdvisor
INTERNAL:UsageFn
INTERNAL:TraceFn
# ===================================================================== #
#
#
Significant URL Terminator directive
#
# ===================================================================== #
#
#
#
#
The SignificantUrlTerminator is useful for increasing the cache hit
rate when you know that all URLs with the same significant part will
return the same response from the server regardless of the value
following the significant part.
# This directive sets a terminating pattern for URL requests. Only the
# part of the URL before the terminator is evaluated to determine whether
# the response is cached.
# You can have multiple entries for this directive.
#
#
#
#
#
#
#
Default: <none>
Syntax: SignificantUrlTerminator <pattern>
#
#
#
#
#
#
http://www.abc.com/cgi.asp?id=0044&.x=045;y=003
Example:
SignificantUrlTerminator&.
SignificantUrlTerminator^^^^^
If the response to the URL is the same regardless of the values of x
and y, you can set SignificantUrlTerminator to &. to tell the proxy to
consider only the value up to &. (i.e., http://www.abc.com/cgi.asp?id=0044)
#
===============================================================================
================
544
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
#
URL Rewriting rules and directives
#
#
===============================================================================
================
#
#
ReversePass rule:
#
Usage similar to that of Proxy rule. This rule is used to match
#
redirected URLs (301) so that they are rewritten to point to the
#
proxy.
#
Default : none
#
Syntax:
ReversePass <from URL> <to URL>
#
JunctionRewrite directive:
#
A Junction is defined as proxy rule (see next section) that maps a
#
virtual URL directory to the document root of a Origin Server.
#
The JunctionRewrite directive controls the ability of proxy to rewrite
#
responses from such origin servers so that they preserve the virtual
#
url space of the web site.
#
Junctions are defined by the proxy rule mapping. (Mapping rules
section)
#
This directive works in conjunction with the enabling of the Junction
#
rewriting plugin (which appears in System Plugins section).
#
Valid junctions appear as
#
Proxy
/shop/*
http://shopserver.acme.com/*
#
Proxy
/auth/*
http://authserver.acme.com/*
#
Proxy
/market/partners/*
http://b2bserver.acme.com/*
#
Valid junctions that have no effect on rewriting are
#
Proxy
/*
http://defaultserver.acme.com/*
#
Invalid junctions are
#
Proxy
/images/*.gif
http://imageserver.acme.com/images/gifs/*.gif
#
Proxy
/cgi-bin/*
http://cgiserver.acme.com/cgi/perl/*
#
#
Default: off
#
Syntax: JunctionRewrite <on | off>
#
# ===================================================================== #
#
#
Mapping rules
#
# ===================================================================== #
#
#
#
The Pass, Fail, Exec, Map, Redirect, Proxy and ProxyWAS rules are
used for mapping a request URL to another URL or a physical file.
Appendix A. Configuration files and scripts
545
#
The rules specify templates and a file directory or new URL to replace
#
the template in the request. If a request comes in and the URL of the
#
request matches one of the mapping rules, the rule is applied.
Asterisks
#
are used as wild cards and must appear in both the request template
and
#
the replacement template. The Fail rule does not have a replacement
template.
#
#
The Pass, Fail, and Exec rules are used for mapping from a request URL
#
to a physical file. The Map rule is used for mapping from one url to
#
another. The Proxy rule is used for mapping from a request URL to a
URL
#
which will be passed on to another server and requires a full URL in
the
#
replacement template. Redirect will direct the client to pass the
request
#
on to another server and requires a full URL in the replacement
template.
#
#
The ProxyWAS rule is almost identical to a Proxy rule and is used as an
#
indication to the Caching Proxy that the origin server being proxied is a
#
WebSphere Application Server 4.0 machine. This allows Proxies that
#
have a security proxy function to relay security information to the origin
#
server for use by J2EE applications. This rule is intended for use in a
#
reverse proxy or security proxy deployment.
#
#
The rules are applied in the order they appear in the configuration
file
#
until a request template has been matched or until there are no more
rules
#
to apply. The Map rule will modify the request as defined by the
replacement
#
template and then will continue processing the remaining rules against
the
#
mapped request. All other rules will stop applying rules once one of
the
#
rules has been matched.
#
#
If your server has multiple network connections or you want to
differentiate
#
traffic coming in on different ports, you can optionally specify an
#
address/port template to restrict the server to using the directive
only
#
for requests that come to the server on a connection with an
address/port
#
matching the template.
#
#
NOTE: the address/port of the server’s network connection is compared
546
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
to the template, not the address of the requesting client.
You can specify a complete IP address (for example, 9.67.106.79) or a
a specific port (for example, :443) or a IP address:port template (for
example 128.22.49.5:80).
Default:
Syntax:
<none>
rule request-template result [IP-address-template]
Example:
Exec
/cgi-bin/*
/CGI-BIN/CustomerA/* 9.67.109.79
Map
/data/*
/www/data/*
Map
/mess/*
/www/junk/*
Map
/books/stuff/*
/www/docs/*
Fail
/bogus/*
9.67.105.79
Fail
/ddd/eee/*
Redirect
/old/server/*
http://new.server.loc/newpath/*
Proxy
/hosta/*
http://hosta/*
ProxyWAS/hostwas/*http://hostwas/*
Proxy /hostb/*http://hostb/* 128.22.49.5:80
Pass
/buck/*
/diskx/bin/*
#
Scripts; URLs starting with /cgi-bin/ will be understood as
#
script calls in the directory /opt/ibm/edge/cp/server_root/cgi-bin/
#
#
URLs starting with /admin-bin/ will be understood as
#
script calls in the directory /opt/ibm/edge/cp/server_root/admin-bin/
#
Proxy /* http://console.demo.tivoli.com/* :8080
Pass
/admin-bin/webexec/*.style
/opt/ibm/edge/cp/server_root/admin-bin/webexec/*.style
#
#
If you are using an EUC codepage for display, use the *.euc.NLS and
*.euc.props files.
#
#Pass
/admin-bin/webexec/wteClient.NLS
/opt/ibm/edge/cp/server_root/admin-bin/webexec/en_US/wteClient.euc.NLS
#Pass
/admin-bin/webexec/wteClient.props
/opt/ibm/edge/cp/server_root/admin-bin/webexec/en_US/wteClient.euc.props
Pass
/admin-bin/webexec/wteClient.NLS
/opt/ibm/edge/cp/server_root/admin-bin/webexec/en_US/wteClient.NLS
Pass
/admin-bin/webexec/wteClient.props
/opt/ibm/edge/cp/server_root/admin-bin/webexec/en_US/wteClient.props
Pass
/admin-bin/webexec/*.NLS
/opt/ibm/edge/cp/server_root/admin-bin/webexec/en_US/*.NLS
Appendix A. Configuration files and scripts
547
Pass
/admin-bin/webexec/*.props
/opt/ibm/edge/cp/server_root/admin-bin/webexec/en_US/*.props
Pass
/admin-bin/webexec/*.class
/opt/ibm/edge/cp/server_root/admin-bin/webexec/*.class
Pass
/admin-bin/webexec/*.gif
/opt/ibm/edge/cp/server_root/admin-bin/webexec/*.gif
Pass
/admin-bin/webexec/*.jar
/opt/ibm/edge/cp/server_root/admin-bin/webexec/*.jar
Pass
/admin-bin/webexec/*.html
/opt/ibm/edge/cp/server_root/admin-bin/webexec/en_US/*.html
Pass
/Docs/arrow*.gif
/opt/ibm/edge/cp/server_root/Docs/arrow*.gif
Pass
/Docs/top.gif /opt/ibm/edge/cp/server_root/Docs/top.gif
Pass
/Docs/up-arrow.gif
/opt/ibm/edge/cp/server_root/Docs/up-arrow.gif
Pass
/Docs/NavBar.*
/opt/ibm/edge/cp/server_root/Docs/NavBar.*
Pass
/Docs/JohnNav.class
/opt/ibm/edge/cp/server_root/Docs/JohnNav.class
Pass
/Docs/JohnNode.class
/opt/ibm/edge/cp/server_root/Docs/JohnNode.class
Pass
/Docs/htmldocs/*
/opt/ibm/edge/doc/en_US/*
#Pass
/admin-bin/webexec/images/*
/opt/ibm/edge/cp/server_root/admin-bin/webexec/images*
Pass
/admin-bin/webexec/*
/opt/ibm/edge/cp/server_root/admin-bin/webexec/en_US/*
Exec
/cgi-bin/*
/opt/ibm/edge/cp/server_root/cgi-bin/*
Exec
/Docs/cgi-bin/*
/opt/ibm/edge/cp/server_root/cgi-bin/*
Exec
/admin-bin/*
/opt/ibm/edge/cp/server_root/admin-bin/*
Exec
/Docs/admin-bin/*
/opt/ibm/edge/cp/server_root/admin-bin/en_US/*
#
#
URL translation rules; If your documents are under
#
/opt/ibm/edge/cp/server_root/pub/en_US then this single rule does the
job:
#
Pass
/cpicons/statusSB.gif
/opt/ibm/edge/cp/server_root/cpicons/en_US/statusSB.gif
Pass
/cpicons/*
/opt/ibm/edge/cp/server_root/cpicons/*
Pass
/Admin/home.gif
/opt/ibm/edge/cp/server_root/Admin/home.gif
Pass
/Admin/help.gif
/opt/ibm/edge/cp/server_root/Admin/help.gif
Pass
/Admin/helpicon.gif
/opt/ibm/edge/cp/server_root/Admin/helpicon.gif
548
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Pass
/Admin/restarticon.gif
/opt/ibm/edge/cp/server_root/Admin/restarticon.gif
Pass
/Admin/*
/opt/ibm/edge/cp/server_root/Admin/en_US/*
Pass
/Docs/*
/opt/ibm/edge/cp/server_root/Docs/en_US/*
Pass
/wsApplet/*
/opt/ibm/edge/cp/server_root/Applets/*
Pass
/errorpages/*
/opt/ibm/edge/cp/server_root/pub/en_US/errorpages/*
Pass
/pac/*
/opt/ibm/edge/cp/server_root/pub/pacfiles/*
Pass
/pacfiles/*
/opt/ibm/edge/cp/server_root/pub/pacfiles/*
# *** START NEW MAPPING RULES SECTION ***
# *** END NEW MAPPING RULES SECTION ***
Pass
/*
/opt/ibm/edge/cp/server_root/pub/en_US/*
# ===================================================================== #
#
#
Performance directives
#
# ===================================================================== #
#
MaxActiveThreads directive:
#
#
Defines the number of threads in system thread pool.
#
#
Default: 100
#
Syntax:
MaxActiveThreads <num>
MaxActiveThreads 100
# ConnThreads directive
#
# Defines the number of connection threads to be used for connection
management
#
# Default
5
# Syntax:
ConnThreads <num>
#
MaxPersistRequest directive:
#
#
Maximum number of request to receive on a persistent connection.
#
#
Default: 5
#
Syntax:
MaxPersistRequest <num>
MaxPersistRequest 5
Appendix A. Configuration files and scripts
549
#
DNS-Lookup directive:
#
#
Instruct the server to look up hostnames of clients by
#
setting DNS-Lookup to “on”.
#
NOTE: Turning DNS-Lookup “on” decreases server performance.
#
#
Default: off
#
Syntax:
DNS-Lookup <on | off>
DNS-Lookup
off
#
PureProxy
#
#
Specifies
#
#
Default:
#
Syntax:
PureProxy on
directive:
if the server is to be run purely as a proxy server.
on
PureProxy <on | off>
#
MaxContentLengthBuffer directive:
#
#
The server normally gives a content-length header line for every
#
document it returns. For dynamically generated documents, the server
#
must buffer the document to compute the content length. This directive
#
can be used to set the size of this buffer. If it is exceeded the
#
document will be returned without a content-length header field (and
#
the connection will be forced closed: persistent connections cannot
#
be used unless the response has a content length).
#
#
Default: 100 K
#
Syntax: MaxContentLengthBuffer <size> <K|M>
#
(Only one keyword/value pair allowed.)
#
MaxContentLengthBuffer
1 M
#
#
#
#
#
#
#
#
#
#
#
550
ProxyPersistence directive:
Allows persistent connections, which will significantly reduce
latency for users and reduce CPU load on the proxy server.
NOTE: Supporting persistent connections requires more threads,
and thus more memory, on the proxy server. In addition,
if you have a multi-level proxy server setup, and you
have any old (HTTP/1.0) proxies in the network, then you
MUST NOT use persistent connections at the proxy.
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
Default: on
#
Syntax:
ProxyPersistence <on | off>
ProxyPersistence on
# ServerConnPool directive:
#
# Allows the proxy to pool together its outgoing connections to origin
# servers. This directive will enhance performance and take
# better advantage of origin servers that allow persistent connections.
# Also, you may specifiy how long to keep an unused connection around
# via the ServerConnTimeout directive.
#
# NOTE: This is best in a controlled environment and could cause a
#
worse performance in a forward proxy situation or one where
#
the origin servers are not HTTP 1.1 compliant.
#
# Default: off
# Syntax:
ServerConnPool <on | off>
ServerConnPool off
# MaxSocketPerServer directive:
#
# This sets the maximum number of open IDLE sockets to maintain to any
# one origin server.
# This is only used if the ServerConnPool is set on.
#
# Default: 5
# Syntax: MaxSocketPerServer <num>
MaxSocketPerServer 5
# ServerConnTimeout directive:
#
# This is set to limit the time to keep an unused connection to a server.
# This is only used if the ServerConnPool directive is set on.
#
# Default: 10 seconds
# Syntax: ServerConnTimeout <time value>
ServerConnTimeout
10 seconds
#
#
#
#
#
#
#
#
#
ServerConnGCRun directive:
This sets the interval at which the garbage collection thread will
check for connections to the server that have timed out (set with the
ServerConnTimeout directive.
This is only used if the ServerConnPool directive is set on.
Default: 2 minutes
Syntax: ServerConnGCRun <time value>
Appendix A. Configuration files and scripts
551
ServerConnGCRun 2 minutes
# ===================================================================== #
#
#
Timeout directives
#
# ===================================================================== #
#
Use these directives to:
#
* limit the time to wait for the client to send a request
#
after connecting to the server before cancelling the connection.
#
* limit the time allowed without network activity before
#
cancelling the connection.
#
* limit the time to allow for sending output to the client.
#
* limit the time to allow for CGI programs to finish.
#
(If the program does not finish within allotted time, the server
#
will kill the CGI program.)
#
* limit the time to wait for the client to send a request
#
after establishing a persistent connection to the server
#
before cancelling the connection.
#
#
Default: InputTimeout
2 minutes
#
Default: ReadTimeout
5 minutes
#
Default: OutputTimeout
12 hours
#
Default: ScriptTimeout
5 minutes
#
Default: PersistTimeout
4 seconds
#
#
Syntax:
<directive>
<time-spec>
#
InputTimeout
2 minutes
ReadTimeout
5 minutes
OutputTimeout
12 hours
ScriptTimeout
5 minutes
PersistTimeout
4 seconds
# ===================================================================== #
#
#
Proxy directives
#
# ===================================================================== #
#
#
552
Proxy server protection and caching directives
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
Proxy protections; if you want only certain domains to
#
use your proxy, uncomment these lines and specify the Mask
#
with hostname templates or IP number templates:
#
# Protection PROXY-PROT {
#
ServerId
YourProxyName
#
Mask
@(*.cern.ch, 128.141.*.*, *.ncsa.uiuc.edu)
# }
# Protect * PROXY-PROT
#
# Protect
# Protect
# Protect
#
#
Proxy
http:*
ftp:*
gopher:*
PROXY-PROT
PROXY-PROT
PROXY-PROT
Specify the protocols that this proxy server will forward:
http:*
#
Forward Proxy-Authorization header directive:
#
#
Enabling this directive leads WTE to forward Proxy-Authorization
#
header. It can be used when WTE is part of a proxy hierarchy
#
and needs to forward a user’s proxy credentials to an
#
upstream proxy.
#
#
Defaults: off
#
Syntax:
ForwardProxyAuthHeader <on | off>
ForwardProxyAuthHeader off
#
SSLTunneling directive:
#
#
Enable SSL Tunneling to any port. You must also make sure that
#
the CONNECT method is enabled; use the directive “Enable” to
#
do this.
#
#
Default: on
#
Syntax: SSLTunneling <on | off>
SSLTunneling
off
#
#
#
#
#
#
#
Proxy-to-Proxy directives:
Also known as Proxy Chaining
ftp_proxy directive:
Use this directive to specify the name of another proxy web server
this server should contact for FTP requests rather than contacting
Appendix A. Configuration files and scripts
553
#
the FTP Server named in the request URL directly.
#
#
Specify the optional domain specification value as a string of domain
#
names or domain name templates. Separate each entry in the string with
a comma.
#
Do NOT put any spaces in the string. You CANNOT use the wildcard
character (*).
#
You CAN specify a template by including only the last part of a domain
#
name.
#
#
Default: <none>
#
Syntax: ftp_proxy <outer_proxy_server_URL> <optional domain
specification>
#
# Example:
# ftp_proxy
http://outer.proxy.name/
#
gopher_proxy directive:
#
#
Use this directive to specify the name of another proxy web server
#
this server should contact for Gopher requests rather than contacting
#
the Gopher Server named in the request URL directly.
#
#
Specify the optional domain specification value as a string of domain
#
names or domain name templates. Separate each entry in the string with
a comma.
#
Do NOT put any spaces in the string. You CANNOT use the wildcard
character (*).
#
You CAN specify a template by including only the last part of a domain
#
name.
#
#
Default: <none>
#
Syntax: gopher_proxy <outer_proxy_server_URL> <optional domain
specification>
#
# Example:
# gopher_proxy http://outer.proxy.name/
#
#
#
#
#
#
#
#
a comma.
554
http_proxy directive:
Use this directive to specify the name of another proxy web server
this server should contact for HTTP requests rather than contacting
the HTTP Server named in the request URL directly.
Specify the optional domain specification value as a string of domain
names or domain name templates. Separate each entry in the string with
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
Do NOT put any spaces in the string. You CANNOT use the wildcard
character (*).
#
You CAN specify a template by including only the last part of a domain
#
name.
#
#
Default: <none>
#
Syntax: http_proxy <outer_proxy_server_URL> <optional domain
specification>
#
# Example:
# http_proxy
http://outer.proxy.name/
#
no_proxy directive:
#
#
Specify the domains to which the server should directly connect.
#
This is ONLY used when doing proxy chaining (i.e., when an
#
http_proxy, ftp_proxy, and/or gopher_proxy is defined). This
#
directive does NOT apply when the proxy goes through a SOCKS server;
#
use socks.conf for that purpose. Also, if you are using neither
#
proxy chaining nor SOCKS, then this directive is not needed.
#
#
Specify the value as a string of domain names or domain name
#
templates. Separate each entry in the string with a comma.
#
#
Do NOT put any spaces in the string.
#
You CANNOT use the wildcard character (*).
#
You CAN specify a template by including only the last part of a domain
#
name.
#
#
Default: <none>
#
Syntax:
no_proxy <non-proxy domain specification>
#
# Example:
# no_proxy
www.someco.com,.raleigh.ibm.com,.some.host.org:8080
#
#
#
#
#
#
#
#
#
#
#
#
SendRevProxyName directive:
In a reverse proxy scenario, WTE normally sends the destination
origin server name in the HOST header of the request to the origin
server. If this directive is set to yes, WTE will instead send
the WTE host name in the HOST header of the request to the origin
server. This allows the origin server to use the WTE host name in
redirects sent back. Therefore, subsequent requests to redirected
locations will go through WTE.
Default:
Syntax:
no
SendRevProxyName <yes | no>
Appendix A. Configuration files and scripts
555
#
# Example:
# SendRevProxyName
yes
# ===================================================================== #
#
#
Proxy caching directives
#
# ===================================================================== #
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Caching directive:
Turn on proxy caching here. To enable proxy caching, you must:
1) set the Caching directive to ON, and
2) specify at least one CacheDev (raw partition), or
specify CacheMemory (if no CacheDev, then memory cache is used)
There are two different types of caches:
- memory cache - fastest, but limited by amount of RAM
- raw disk cache - fast, only limited by disk space
For raw disk caches, the htcformat utility must be used
to set up the devices. The CacheDev and BlockSize directives
need to be specified. Multiple CacheDev directives can be
specified, and the total space from those devices will be used as a
single cache. For disk (rather than memory) caches, the CacheMemory
directive can still be used to tell the proxy how much memory it
can use to efficiently manage the disk cache. CacheMemory should
be set to at least 1% of the total size of the disk cache.
For a memory cache, simply specify the CacheMemory directive for the
desired cache size, and do not specify any CacheDev directives.
The minimum cache size allowed is 64 M, which can be either 64 M
of a memory cache, or multiple cache devices that add up to 64 M.
Default:
Syntax:
ON
Caching <ON | on | OFF | off>
Caching ON
#
#
#
#
#
556
CacheDev directive:
Specify the cache device(s) to be used for the cache. The minimum
size for the sum of all cache devices is 64 M.
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
#
#
#
#
Default:
Syntax:
Examples:
none
CacheDev <raw disk partition>
CacheDev /dev/raw/raw1 (For Red Hat)
CacheDev /dev/raw1 (For SuSE)
#CacheDev /dev/raw/raw1
CacheDev
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
CacheMemory directive:
Specify the amount of RAM associated with the cache. See the
explanations in the Caching section above for more information
about the use of this directive. If the proxy needs more memory
than is specified for this directive, it will use what it needs
and send a warning message indicating this to the EventLog when
the proxy starts up and initializes the cache. There is more
memory overhead per cache device, so memory utilization is more
efficient for fewer cache devices. As a guideline, memory
utilization is also better for larger caches (1 G and up) than
for smaller caches. With a cache device over 1 G in size, the
amount of memory used will be approximately 1% of the total cache
size. Each cache device uses a minimum of about 8.5 M of memory.
The unit specified can be B (bytes), K (kilobytes), M (megabytes),
or G (gigabytes). If you do not specify a unit, it assumes M.
Minimum for a memory cache: 64 M
Maximum for a memory cache: 1200 M
Minimum for a non-memory cache: 1 K
Default: there is no default value, this must be specified
Syntax:
CacheMemory <size> B | K | M | G
CacheMemory
#
#
#
#
#
#
#
#
/dev/raw/raw1
64 M
BlockSize directive:
Specify the size (in bytes) of the blocks within the cache.
The same BlockSize value will be used for all devices specified
via the CacheDev directives.
Default:
Syntax:
8192 (the only supported BlockSize is 8192 bytes)
BlockSize <size>
#BlockSize 8192
Appendix A. Configuration files and scripts
557
#
CacheDefaultExpiry directive:
#
#
Specify the expiry date for files which do not include an explicit
#
expiry date and do not have a last-modified date that would allow us
#
to compute an expiry based on the CacheLastModifiedFactor. This is
#
most useful for protocols that do not have any way to transmit this
#
information, such as FTP or Gopher.
#
#
NOTE: The default expiration for HTTP is 0. HTTP should be kept at 0
#
because many script programs don’t give an expiration date, yet
#
their output expires immediately. A value other than zero may
#
cause problems.
#
#
Defaults: http:*
0 days
#
ftp:*
1 day
#
gopher:* 2 days
#
Syntax:
CacheDefaultExpiry <URL pattern> <time period>
#
# Example: set default expiration for all FTP files to 14 days
# CacheDefaultExpiry ftp:*
1 fortnight
CacheDefaultExpiry
CacheDefaultExpiry
CacheDefaultExpiry
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
558
http:*
ftp:* 1
gopher:*
0 days
days
2 days
CacheRefreshInterval directive:
This directive specifies when to revalidate - check with the
origin to see if they’ve changed - documents. The difference
between this directive and CacheClean (below) is that CacheClean
will cause documents to be removed from the cache after a
given period of time, while CacheRefreshInterval will just
force the proxy to revalidate them before using them.
Defaults:
Syntax:
2 weeks for all documents
CacheRefreshInterval <URL pattern> <time period>
- This form specifies the refresh interval for
and URLs matching <URL pattern>
CacheRefreshInterval pattern> <time period>
- This specifies the refresh interval for any
documents NOT matching a <URL pattern> in
another CacheRefreshInterval directive - in
other words, the default refresh interval.
Example: refresh all .gif images after 8 hours, and all other documents
after a week.
CacheRefreshInterval *.gif 8 hours
CacheRefreshInterval 1 week
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
CacheRefreshInterval 2 weeks
#
#
#
#
#
#
#
#
#
#
CacheUnused directive:
Specify how long the proxy cache should keep files which have not
been used (requested by a client). Unused files which have been in
the cache longer than this will be removed during garbage collection.
Default:
Syntax:
CacheUnused
CacheUnused
CacheUnused
#
#
#
#
#
#
#
#
#
2 days for
3 days for
12 hours for
CacheUnused
http:* 2 days
ftp:* 3 days
gopher:* 12 hours
CacheExpiryCheck directive:
Normally, a caching proxy will check that the files in its cache
have not expired. In special circumstances (such as a network outage)
you may want to disable this check; the proxy will then serve files
from its cache even if they’re out of date.
Default: on
Syntax: CacheExpiryCheck <on | off>
CacheExpiryCheck
#
#
#
#
#
#
#
#
#
#
off
CacheNoConnect directive:
In normal situations, the proxy server will contact the content
server to fetch pages. However, in special situations (such as
a demonstration at a trade show), you may not want the proxy server
to try to contact the origin server. Setting CacheNoConnect “on”
prevents the proxy from contacting the origin server.
Default: off
Syntax: CacheNoConnect <on | off>
CacheNoConnect
#
#
http:*
ftp:*
gopher:*
<URL pattern> <time period>
on
CacheTimeMargin directive:
Appendix A. Configuration files and scripts
559
#
#
#
#
#
#
#
The proxy server will not cache documents which are due to expire
‘soon’. This directive defines what ‘soon’ is. In other words, a
document’s expiry date must be further in the future than the
CacheTimeMargin when WTE receives it in order for it to be cached.
Default: 10 minutes
Syntax: CacheTimeMargin <time period>
CacheTimeMargin
10
#
CacheLastModifiedFactor directive:
#
#
Use this directive to have the server set expirations for files which
#
have a Last-Modified date, but no Expires date. The server uses the
#
Last-Modified date to determine how long it has been since the file
#
was modified, then multiplies that time by the fraction specified by
#
the value on this directive to determine the proportion of a file’s
#
age (LastModified) to be used as the expiry time. The assumption
#
is that files that have changed recently are probably changing
#
frequently, while files that have not been modified in some time have
#
stablizied and do not need to be refreshed as frequently.
#
#
The higher this value is set, the longer these files will reside in
#
the cache without being checked for freshness. Setting this value too
#
high may cause stale (out-of-date) files to be served from cache.
#
#
For example, if a file was last modified 1 month ago and
#
CacheLastModifiedFactor was set to 0.5, the file would expire in
#
approximately 15 days (half a month). If the file was changed 4 days
#
ago, and CacheLastModifiedFactor was set to 0.25, the file would
#
expire in 1 day.
#
#
If a CacheLastModifiedFactor of -1 is specified, the file
#
last-modified date will not be used to calculate the file expiry time.
#
This setting is not suggested for normal operation, as it will result
#
in very few files being cached.
#
#
Default: Numerous factors, based on file extensions. The defaults
#
reflect the fact that certain types of files - like
#
graphics - tend to have longer lifetimes.
#
Syntax: CacheLastModifiedFactor <URL pattern> <fraction>
#
# Example:
# CacheLastModifiedFactor http://* 0.14
# CacheLastModifiedFactor ftp://* 0.25
CacheLastModifiedFactor http://*/ 0.10
CacheLastModifiedFactor http://*.htm* 0.20
560
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
CacheLastModifiedFactor
CacheLastModifiedFactor
CacheLastModifiedFactor
CacheLastModifiedFactor
http://*.gif 1.00
http://*.jpg 1.00
http://*.jpeg 1.00
http://*.png 1.00
CacheLastModifiedFactor http://*.tar 1.00
CacheLastModifiedFactor http://*.zip 1.00
CacheLastModifiedFactor http:* 0.15
CacheLastModifiedFactor ftp:* 0.50
CacheLastModifiedFactor
* 0.10
#
CacheMaxExpiry directive:
#
#
Specify the maximum lifetime allowed for objects matching a given
#
request template. An object may still be kept longer than its
#
maximum lifetime, but it must be revalidated with the origin
#
server when its lifetime has been reached. A maximum lifetime
#
of 0 is interpreted as no maximum - the lifetime will not have
#
an upper limit.
#
#
Note that it doesn’t make much sense to set this higher than
#
CacheClean, as CacheClean specifies the maximum time an object can
#
remain in the cache before it is deleted.
#
#
Default: 1 month for all objects
#
Syntax: CacheMaxExpiry <URL request template> <time spec>
#
# Example: .gif files may not have a lifetime longer than 2 weeks.
# CacheMaxExpiry http://*.gif 2 weeks
CacheMaxExpiry 1 month
#
CacheClean directive:
#
#
Specify how long you want the server to keep cached files with URLs
#
matching a given request template. The server deletes cached files
#
whose URLs match a given request template after they have been cached
#
for the specified time, regardless of their expiration date.
#
#
Default: 1 month for all objects
#
Syntax: CacheClean <URL request template> <time spec>
# Example:
# CacheClean http:* 2 weeks
CacheClean 1 month
Appendix A. Configuration files and scripts
561
#
CacheFileSizeLimit directive:
#
#
CacheFileSizeLimit specifies the maximum size for any file that will
#
be cached. The value can be specified in bytes (B), kilobytes (K),
#
megabytes (M), or gigabytes (G).
#
#
Note that in previous releases, this directive was called
#
CacheLimit_2. The syntax of the directive remains unchanged.
#
#
Default: CacheFileSizeLimit 4000 K
#
Syntax:
CacheFileSizeLimit <bytes> <B|K|M|G>
#
# Example: Don’t cache any files larger than 512 K.
# CacheFileSizeLimit 512 K
CacheFileSizeLimit 4000 K
#
CacheOnly and NoCaching directives:
#
#
The server allows control over the files to be cached in two ways.
#
#
CacheOnly - specifies a set of URLs which will be considered for
#
caching (URLs not in that list will never be cached)
#
NoCaching - specifies a set of URLs which must never be cached,
#
(all other URLs are candidates for caching)
#
#
Default: <none> (for both CacheOnly and NoCaching)
#
Syntax:
CacheOnly <URL pattern>
#
NoCaching <URL pattern>
#
# Example:
# CacheOnly http://www.ibm.com/*
# NoCaching http://never.cache.me.net/*
#
#
#
#
#
#
#
#
#
#
#
#
562
ContinueCaching directive:
Specifies the point at which a file being received from a content
server will continue to be received from the content server and
stored in the cache even if the connection to the client which
requested the file has been terminated. The value specified
represents a percentage of the size of the file being transferred.
If less than this percentage of the file has been transferred from
the content server at the time the client connection is terminated,
file transfer from the content server will be terminated and the cache
file containing the partial file will be removed from the cache.
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
Default: 75
#
#
Syntax:
ContinueCaching <percent of file already transferred>
#
# Example:
# ContinueCaching 75
#
CacheMontool directive:
#
#
CacheMontool is an ON/OFF flag for enabling a cache monitoring
#
utility which monitors the proxy cache. It gives the information
#
as to how full is the cache (either memory or cachedevices) and
#
whether its getting written, garbage collected or compacted.
#
#
Default: off
#
#
Syntax: CacheMontool <on | off>
#
# Example:
CacheMontool on
#
IMSToServer directive:
#
#
IMSToServer is a directive that turns on the feature of sending
#
If-Modified-Since requests to the origin server instead of
#
reloading the data. This can enhance bandwidth utilization
#
and overall cache performance if data is often expiring without
#
actually changing.
#
#
Default: on
#
#
Syntax: IMSToServer <on | off>
#
# Example:
# IMSToServer off
#
#
#
#
#
#
#
#
#
#
OutgoingConnMgmt directive:
OutgoingConnMgmt is a directive that turns on the server side
connection management feature. This specifies whether or not
a worker thread should wait for the server to respond before
continuing to another task. Turning this on will enhance
performance when accessing slow backend servers.
Default: off
Appendix A. Configuration files and scripts
563
#
Syntax: OutgoingConnMgmt <on | off>
#
# Example:
# OutgoingConnMgmt on
# ===================================================================== #
#
#
Proxy cache garbage collection directives
#
# ===================================================================== #
#
#
#
#
#
#
#
#
#
#
Gc
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
564
Gc (Garbage Collection) directive:
In order for a caching proxy server to function efficiently, it
needs to sweep through the cache and remove out-of-date files on a
regular basis. This is called ‘garbage collection’. It should only
be turned “off” in special circumstances, such as during an extended
network outage.
Default:
Syntax:
off
on
Gc <on | off>
GcperDevice directive:
GcperDevice directive is an ON/OFF flag which turns on garbage
collection per device basis and NOT complete system basis. Hence
the garbage collection of any cache device starts as soon as the
cache device is full irrespective of whether the GcHighWater mark
has been reached.
Default: off
Syntax: GcperDevice <on | off>
CacheAlgorithm directive:
Specifies which cache algorithm the server will use. Choices
include: bandwidth, responsetime, and blend. Specifying
bandwidth will rate cache files to minimize network bandwidth.
Choosing responsetime will rank cached files to minimize response
time. The blend option will do a combination of the two.
Default:
Syntax:
bandwidth
CacheAlgorithm <string>
where string is “bandwidth” | “responsetime” | “blend”
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
CacheAlgorithm bandwidth
#
GcHighWater directive:
#
#
When the cache fills up to the high-water mark, garbage collection
#
will begin. The high-water mark is specified as a percentage of the
#
total cache capacity. Garbage collection will continue until the
#
low-water mark has been reached - see GcLowWater to set this.
#
The high-water mark must not be set above 95%, and normally should
#
not be set below 50%.
#
#
Default: 90 (percent)
#
Syntax:
GcHighWater <percentage>
#
# Example: Start garbage collection when cache utilization reaches 85%
# GcHighWater 85
GcHighWater 90
#
GcLowWater directive:
#
#
Once cache garbage collection has begun, it will continue until
#
cache utilization reaches the low-water mark. The low-water mark is
#
specified as a percentage of the total cache capacity. The low-water
#
mark must be below the high-water mark; see the GcHighWater directive
#
for setting the high-water mark.
#
#
Default: 60 (percent)
#
Syntax:
GcLowWater <percentage>
#
# Example: End garbage collection when the cache reaches 75% full.
# GcLowWater 75
GcLowWater 60
# ===================================================================== #
#
#
Advanced proxy and caching directives
#
# ===================================================================== #
#
#
#
#
#
#
#
ProxyIgnoreNoCache directive:
Allows the proxy server to ignore the “Pragma: no-cache” header
(usually sent by browsers when the user hits the “Reload” button)
and serve the content from cache (if available) in defiance of
the client’s request.
Appendix A. Configuration files and scripts
565
#
NOTE: This should ONLY be used in unusual circumstances.
#
#
Default: off
#
Syntax:
ProxyIgnoreNoCache <on | off>
ProxyIgnoreNoCache
on
#
AggressiveCaching directive:
#
#
Allows the proxy server to cache responses which might not
#
ordinarily be cached, for example responses which contain
#
the “cache-control: no-cache” header.
#
#
Default: <none>
#
Syntax: AggressiveCaching <URL pattern>
# Example:
# AggressiveCaching http://www.hosta.com/*
#
ProxySendClientAddress directive:
#
#
Instructs the proxy to forward an HTTP header containing the
#
client’s IP address. If ProxySendClientAddress is not defined,
#
client IP addresses are NOT forwarded.
#
#
Default: <none>
#
Syntax:
ProxySendClientAddress <HTTP header name>
#
#
NOTE: The Remote Configuration forms only support 2 options:
#
(1) client IP addresses NOT forwarded
#
ProxySendClientAddress directive is removed
#
(2) client IP addresses ARE forwarded with Client-IP: header
#
ProxySendClientAddress Client-IP:
#
# Example:
# ProxySendClientAddress Client-IP:
#
#
#
#
web.
#
#
#
#
#
#
566
ProxyUserAgent directive:
Substitute a different User-agent string for the one that the client
sends. This helps make the clients more anonymous when surfing the
User-agent strings may include spaces.
NOTE: Some Web sites automatically generate different pages
for certain Web browsers (by looking at the User-Agent header),
so if you mask the identity of the browser, you won’t be able
to see the pages that are customized for certain browsers.
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
#
Default: <none>
#
Syntax:
ProxyUserAgent <string> (in the form “ProductName/Version”)
#
# Example:
# ProxyUserAgent Mozilla/4.0 (emulation; Javelin/2.0)
#
ProxyFrom directive:
#
#
Specifies the “From:” header to send on all requests that
#
go through this proxy.
#
#
NOTE: Replaces the “From:” header sent by the client
#
#
Default: <none>
#
Syntax:
ProxyFrom <string>
#
# Example:
# ProxyFrom [email protected]
#
NoProxyHeader directive:
#
#
Allows the proxy to block certain headers that clients send.
#
#
NOTE: Any HTTP header (even required headers) can be blocked
#
with this directive, so extreme care should be used.
#
#
Default: <none>
#
Syntax:
NoProxyHeader <header>
#
# Example:
# NoProxyHeader Referer:
#
#
#
#
#
#
#
#
#
#
#
#
#
ProxyVia directive:
Controls the use of HTTP Via header.
NOTE: There are 4 possible values for this directive.
Full: WTE will add a Via header into the request or
reply. If there is a Via header already in the
stream, it will add host infomation at the end
of the line.
Set:
The Via header will be set to host information.
If there is a via header already in the stream,
it will remove this header from stream.
Pass: No action involved, pass through.
Appendix A. Configuration files and scripts
567
#
#
#
#
Block: No Via header forward, including WTE’s.
Default: <Full>
Syntax: ProxyVia <Full|Set|Pass|Block>
#
CacheMinHold directive:
#
#
Overrides the “Expires” tag on documents from certain sites.
#
These sites routinely force documents to expire immediately
#
even when they have a longer lifetime.
#
#
Default: <none>
#
Syntax:
CacheMinHold <URL pattern> <time spec>
#
# Example:
# CacheMinHold http://www.cachebusters.com/* 1 hour
#
CacheLocalDomain directive:
#
#
Allows local domain sites to be cached, when set “on”.
#
#
NOTE: Assumes hostnames without a domain name are local.
#
#
Default: on
#
Syntax:
CacheLocalDomain <on | off>
CacheLocalDomain on
#
appendCRLFtoPost directive:
#
#
Some Origin servers require a Carriage Return and Line Feed to
#
be appended at the end of the content body on a POST request.
#
Use the appendCRLFtoPost directive to specify sites which should
#
have the CRLF appended at the end of the content body when sending
#
a POST request to the site.
#
#
Default: <none>
#
Syntax:
appendCRLFtoPost <URL pattern>
#
# Example:
# appendCRLFtoPost
http://www.hosta.com/*
#
#
#
#
568
SendHTTP10outbound directive:
Specifies the HTTP version to be used on requests sent outbound
to the origin server or to the next proxy in a chain of proxies.
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
SendHTTP10outbound should only be used if the origin server
#
or next downstream proxy have known problems handling HTTP/1.1
requests.
#
#
Default: <none>
#
Syntax:
SendHTTP10outbound <URL pattern>
#
#SendHTTP10outbound http://www.hosta.com/*
SendHTTP10Outbound http://*.mail.yahoo.com/*
#
CacheQueries directive:
#
#
Specifies whether or not responses to queries should be cached.
#
If ALWAYS is specified, responses to queries will be cached as
#
long as the response is otherwise cacheable.
#
If PUBLIC is specified, responses to queries will be cached if
#
the response is marked as “public” by containing a
#
“cache-control: public header, or if the response contains
#
cache-control headers which will force re-validation on every request,
and the
#
response is otherwise cacheable.
#
#
Default: <none>
#
Syntax: CacheQueries <ALWAYS | PUBLIC> <URL Pattern>
#
# Example:
# CacheQueries ALWAYS http://www.hosta.com/*
# CacheQueries PUBLIC http://www.hostb.com/*
#
CacheByIncomingUrl directive:
#
#
Specifies whether to use the incoming URL or the outgoing URL as
#
the basis for generating cache file names.
#
If ON is specified, the incoming URL will be used to generate the
#
cache file name. If OFF is specified, All applicable Name Translation
#
plug-ins and Map and Proxy rules will be applied to the incoming URL
and
#
the resulting URL will be used to generate the cache name.
#
#
Default: OFF
#
Syntax: CacheByIncomingUrl <on | off>
CacheByIncomingUrl off
#
#
#
ExternalCacheManager directive:
Specifies the ExternalCacheManager id to be used determine the
Appendix A. Configuration files and scripts
569
# cacheablity of dynamic resources. Such resources will receive
# explicit invalidations from the aforementioned cache manager.
# The directive also allows for specification of a default expiry
# time to be used in case an invalidation is not received.
#
# Default: <none>
# Synatax: ExternalCacheManager <External Manager ID> <time spec>
# Example:
# ExternalCacheManager ACME-APPSERV-1 20 minutes
# ExternalCacheManager ACME-APPSERV-2 10 minutes
# ===================================================================== #
#
#
RCA (Remote Cache Access) directives
#
# ===================================================================== #
#
#
#
#
#
#
Version
Version directive:
Specify the protocol name and version.
Default: <RCA/1.0>
Syntax:
Version <protocol/major.minor>
RCA/1.0
#
ArrayName directive:
#
#
Specify the name of this array.
#
#
NOTE: This is an administrative aid.
#
Spaces are not allowed in the array name.
#
This directive is required.
#
#
Default: <none>
#
Syntax:
ArrayName <array name>
# Example:
# ArrayName mastiff
#
#
#
#
#
in
#
the
570
SymmetricConfig
Specified if the members of this array are in a symmetric configuration
NOTE: Turning this directive on allows for some optimizations that result
Network traffic between RCA nodes. This feature should not be used when
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
#
#
#
members of the array are dissimilar with regards to configuration.
Default:
Syntax:
Off
SymmetricConfig ( On | Off )
#
RcaThreads directive:
#
#
Specify the number of threads working on the RCA port
#
#
NOTE: This number must be less than the MaxActiveThreads. RCA threads
will
#
only work on the RCA port. The number of RCA threads is based on
the
#
ArraySize and MaxActiveThreads numbers. If not defined, the
default
#
value will be used.
#
#
Default: MaxActiveThreads * (ArraySize - 1) / (2 * ArraySize - 1)
#
Syntax: RcaThreads <num>
# RcaThreads 50
#
Member directive:
#
#
Specify a member this array.
#
#
Default: <none>
#
Syntax:
Member Name { subdirectives }
#
#
Name
required; the hostname this member is known to
#
clients by
#
#
subdirectives are one of:
#
RCAAddr
required; IP address or hostname for RCA
#
communication
#
RCAPort
required; port for RCA communication
#
Timeout
( milliseconds )
#
optional; how long to wait for this member
#
before deciding rigor mortis has occured;
#
must be positive; default is 1000 ms
#
BindSpecific ( On | Off )
#
optional; allows communications to occur on a
#
private subnet, providing a measure of
security;
#
default is ON
#
ReuseAddr
( On | Off )
#
optional; allows faster rejoining of the array;
#
“on” would allow other processes to steal the
#
port, causing undefined behaviour;
Appendix A. Configuration files and scripts
571
#
default is OFF
#
# Example:
# Member bittersweet.chocolate.ibm.com {
#
RCAAddr
127.0.0.1
#
RCAPort
6294
#
Timeout
1000 milliseconds
#
BindSpecific On
#
ReuseAddr
Off
# }
# ===================================================================== #
#
#
SNMP directives
#
# ===================================================================== #
#
#
#
#
#
#
SNMP
SNMP directive:
Set SNMP communication on or off.
Default:
Syntax:
off
off
SNMP <on | off>
#
SNMPCommunity directive:
#
#
The community name which is used by the server to communicate
#
with the SNMP agent.
#
#
Default: public
#
Syntax:
SNMPCommunity <public | community name>
SNMPCommunity public
#
WebMasterEMail directive:
#
#
The E-mail address of the person who should get communications
#
about this server
#
#
Default: webmaster
#
Syntax:
WebMasterEMail [email protected]
WebMasterEMail webmaster
572
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
# ===================================================================== #
#
#
Icon directives
#
# ===================================================================== #
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
AddIcon, AddDirIcon, AddBlankIcon, AddUnknownIcon and AddParentIcon
directives:
AddIcon
- Bind icon URL to a MIME content-type or
content-encoding.
AddDirIcon
- Specify directory icon URL for directory listing
AddBlankIcon - Specify blank icon URL for directory listing
AddParentIcon - Specify parent directory icon URL for directory
listing
AddUnknownIcon - Specify unknown icon URL for directory listing
Default:
Syntax:
Syntax:
Syntax:
Syntax:
Syntax:
<default set of icons shown below>
AddIcon
<icon URL> <ALT text> <MIME-type template>
AddDirIcon
<icon URL> <ALT text>
AddBlankIcon <icon URL> <ALT text>
AddParentIcon <icon URL> <ALT text>
AddUnknownIcon <icon URL> <ALT text>
If the <icon URL> does not include a path, the server will prepend
the directory /cpicons/ to the icon filename. Note that the icon URL
is a virtual path; it will be sent through the mapping rules
(Map, Pass, etc) to find the real path in the filesystem.
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
app-123.gif
app-compress.gif
app-compress.gif
app-fl.gif
app-pcl.gif
app-pdf.gif
app-ps.gif
app-shar.gif
app-bsh.gif
app-csh.gif
app-ksh.gif
123
Z
gz
FL
PCL
PDF
PS
shar
sh
csh
ksh
application/x-123
x-compress
x-gzip
application/x-freelance
application/x-pcl
application/pdf
application/postscript
application/x-shar
application/x-bsh
application/x-csh
application/x-ksh
AddIcon
AddIcon
AddIcon
mp-tar.gif
mp-tar.gif
mp-zip.gif
tar
tar
zip
multipart/x-tar
multipart/x-ustar
multipart/x-zip
AddIcon
AddIcon
audio.gif
audio.gif
au
aiff
audio/basic
audio/x-aiff
Appendix A. Configuration files and scripts
573
AddIcon
AddIcon
audio.gif
audio.gif
wav
audio
audio/x-wav
audio/*
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
image-gif.gif
image-jpeg.gif
image-pixmap.gif
image-tif.gif
image.gif
GIF
JPEG
pixmap
TIFF
img
image/gif
image/jpeg
image/x-xpixmap
image/tiff
image/*
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
text-assem.gif
text-c.gif
text-html.gif
text-html.gif
text-uu.gif
text.gif
asm
c
HTML
HTML
UU
text
text/x-asm
text/x-c
text/html
text/x-ssi-html
text/x-uuencode
text/*
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
video-avi.gif
video-avi.gif
video-jpeg.gif
video-mpeg.gif
video.gif
avi
qt
mjpg
mpeg
video
video/x-msvideo
video/quicktime
video/x-motion-jpeg
video/mpeg
video/*
AddIcon
AddIcon
binary.gif
binary.gif
bin
bin
application/octet-stream
binary
AddBlankIcon
AddParentIcon
AddDirIcon
AddUnknownIcon
blank.gif
dir-up.gif
dir.gif
unknown.gif
UP
DIR
???
# ===================================================================== #
#
#
Cache agent directives
#
# ===================================================================== #
#
#
#
#
#
#
also
#
#
#
574
UpdateProxy directive:
Specify which proxy server the cache agent should update.
NOTE: This directive is required for the cache agent to function on
on AIX, Solaris, Linux and Windows systems. This directive is
required when the cache agent needs to update a proxy server
other than the local proxy server on which it is running.
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
Default: <host on which the cache agent is running>
#
Syntax:
UpdateProxy <fully qualified host name of the proxy server>
# Example:
# UpdateProxy www.ibm.com
#
LoadURL directive:
#
#
Specify URLs to be loaded into the cache.
#
#
NOTE: These URLs are placed at the top of the cache agent’s queue.
#
#
Default: <none>
#
Syntax:
LoadURL <URL to load>
# Example:
# LoadURL http://www.ibm.com/
#
LoadTopCached directive:
#
#
Specify that the cache agent should load the specified number of
#
most popular URLs to the cache.
#
#
NOTE: These URLs are queued below the URLs loaded by the
#
LoadURL directive
#
#
Default: 100
#
Syntax:
LoadTopCached <num to load>
#
#
NOTE: In order to use this directive, the server configuration
#
file MUST specify Caching “on” and have a valid values
#
for the cache location and size
#
LoadTopCached 100
#
IgnoreURL directive:
#
#
Specify URLs that are NOT to be retrieved by the cache agent.
#
This directive applies only to delving performed by the cache
#
agent. If you wish for the proxy server not to cache certain
#
URLs, then see the NoCache directive.
#
This directive may be specified multiple times.
#
#
NOTE: Wild cards “*” may be used.
#
#
Default: */cgi-bin/*
(Ignore URLs containing /cgi-bin/)
#
Syntax:
IgnoreURL <URL to ignore>
# Example:
Appendix A. Configuration files and scripts
575
# IgnoreURL http://www.yahoo.com/*
# IgnoreURL http://www.yahoo.com/*.html
#
LoadURL
http://RS-AppServer.demo.tivoli.com/
IgnoreURL */cgi-bin/*
#
DelveInto directive:
#
#
Specify whether or not the cache agent should load pages
#
linked off of cached URLs.
#
#
Default: always
#
Syntax:
DelveInto <always | never | admin | topn>
#
#
always - the cache agent will parse the HTML of cached
#
URLs and retrieve linked pages.
#
never - the cache agent will not parse the HTML of
#
cached URLs.
#
admin - the cache agent will only parse HTML documents that
#
originated from one of the LoadURL directives.
#
topn
- the cache agent will only parse HTML documents that
#
were chosen from the server’s cache.
DelveInto always
#
DelveDepth directive:
#
#
Specify the number of link levels to follow when searching
#
for pages to load into the cache.
#
#
NOTE: Applicable when DelveInto “always” is specified.
#
#
Default: 1
#
Syntax:
DelveDepth <num>
DelveDepth 2
#
DelveAcrossHosts directive:
#
#
Specify whether the cache agent will only retrieve pages
#
found on this server, or if the cache agent will retrieve
#
pages from other hosts.
#
#
NOTE: Applicable when DelveInto “never” is NOT specified.
#
#
Default: off
#
Syntax:
DelveAcrossHosts <on | off>
DelveAcrossHosts off
576
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
DelayPeriod directive:
#
#
Specify whether the cache agent should wait between sending
#
requests to destination servers.
#
#
Default: on
#
Syntax:
DelayPeriod <on | off>
#
#
on - reduces the load on the proxy machine and your
#
network link, as well as being kinder to the
#
destination servers.
#
off - allows the cache agent to run at maximum speed.
#
#
NOTE: When DelayPeriod off, certain sites will be
#
accessed very often in rapid succession.
DelayPeriod on
#
#
LoadInlineImages directive:
#
#
Indicate whether inline images should be retrieved by the
#
cache agent.
#
#
Default: on
#
Syntax:
LoadInlineImages <on | off>
LoadInlineImages on
#
NumClients directive:
#
#
Specify the number of worker threads to use to request pages.
#
#
NOTE: Increase this number for a fast machine and a fast
#
Internet link. Use a smaller number for a slow
#
machine or a slow Internet link.
#
#
Default: 4
#
Syntax:
NumClients <num> (maximum of 100)
NumClients 4
#
#
#
#
#
MaxQueueDepth directive:
Specify the maximum depth of the cache agent’s queue of
outstanding page retrieval requests. Specifying a larger
number creates a larger queue.
Appendix A. Configuration files and scripts
577
#
#
NOTE: Only applicable when DelveInto “always” is specified,
#
otherwise, MaxQueueDepth will be set equal to the
#
value specified on the MaxUrls directive.
#
#
Default: 250
#
Syntax:
MaxQueueDepth <num of queue entries>
# Example:
# MaxQueueDepth 500
MaxQueueDepth 250
#
MaxUrls directive:
#
#
Specify the maximum number of URLs the cache agent will
#
request during a particular run.
#
#
Default: 2000
#
Syntax:
MaxUrls <num>
MaxUrls 2000
#
MaxRuntime directive:
#
#
Specify the maximum amount of time that the cache agent
#
will continue requesting URLs.
#
#
NOTE: A value of 0 means “no limit” - the request runs
#
until completion.
#
#
Default: 2 hours
#
Syntax:
MaxRuntime 0 | [<num> hours [<num> minutes]]
# Example:
# MaxRuntime 4 hours
# MaxRuntime 4 hours 10 minutes
MaxRuntime 2 hours
#
AutoCacheRefresh directive:
#
#
Specify whether or not cache content will be refreshed
#
automatically. If this is set to OFF, the cache agent
#
will not be invoked (and all its settings will be ignored).
#
#
Default: on
#
Syntax:
AutoCacheRefresh <on | off>
AutoCacheRefresh on
578
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
CacheRefreshTime directive:
#
#
Specify when the cache agent should be started.
#
#
Default: 3:00 AM
#
Syntax:
CacheRefreshTime <HH:MM>
#
# Example: Begin cache refresh at 3:50 AM
# CacheRefreshTime 03:50
CacheRefreshTime
3:00
#
CacheReloadInterval directive:
#
#
Specify the time interval for the cache agent to start at.
#
This should be used instead of CacheRefreshTime.
#
#
Default: off
#
Syntax:
CacheReloadInterval <time-spec>
#
# Example: Begin reloading the cache every 30 seconds
# CacheReloadInterval 30 seconds
# ===================================================================== #
#
#
PICS Filtering directives
#
# ===================================================================== #
#
PICS Filtering using PICSRules
#
#
For a complete specification of PICSRules, see the URL
#
http://www.w3.org/PICS/PICS-FAQ-980126.html.
#
#
Default: “See Example below”
#
Syntax:
DefinePicsRule “filterName” {
#
(PicsRule-1.0
#
(
#
...subdirectives...(not required)
#
serviceinfo (name “serviceURL”
#
shortname “shortName”
#
bureau “bureauURL”
#
ratfile “ratFile”
#
available-with-content
“NO”
#
)
#
passURL ()
#
failURL ()
#
)
Appendix A. Configuration files and scripts
579
#
)
#
}
#
#
NOTE: Be sure to specify only one rule per DefinePicsRule {...}
#
Each rule should begin with a DefinePicsRule “filterName” {
#
and end with a closing “}”.
#
# Example:
#DefinePicsRule “RSAC Example” {
#
(PicsRule-1.0
#
(
#
serviceinfo (
#
name “http://www.rsac.org/ratingsv01.html”
#
shortname “RSAC”
#
available-with-content “YES”
#
)
#
name
(
#
rulename “RSAC Example”
#
description “Example rule using the RSAC system to
block naughty pictures.”
#
)
#
passURL
(“http://www.ibm.com/*”)
#
optextension (extension-name
“http://www1.raleigh.ibm.com/pics/PICSRules_1.0.html”)
#
ibm-javelin-extensions (
#
active “no”
#
)
#
Filter ( Pass ‘((RSAC.v < 3) && (RSAC.s < 3) && (RSAC.n < 3) &&
(RSAC.l < 3))’ )
#
)
#
)
#}
#
HTTPSCheckRoot directive:
#
#
Whether or not to check the unsecure homepage for self-labels and
#
apply them to a secure request for the same host.
#
#
Default: on
#
Syntax:
HTTPSCheckRoot <on | off>
HTTPSCheckRoot on
# ===================================================================== #
#
#
SSL Directives
#
580
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
# ===================================================================== #
#
SSLEnabled directive:
#
#
Specifies to listen on Port 443 for secure requests.
#
#
Default: OFF
#
Syntax:
SSLEnable <ON | on | OFF | off>
SSLEnable OFF
#
#
#
#
#
#
SSLOnly directive:
Only have ssl port listening no other listening port
Default: OFF
Syntax: SSLOnly [ON, OFF]
#
SSLCaching directive:
#
#
In a reverse proxy scenario, attempt to cache content on
#
a secure request. Caching must be enabled for this
#
directive to be effective.
#
#
Default: off
#
Syntax:
SSLCaching <on | off>
SSLCaching off
#
SSL Version specification:
#
#
Specifies the SSL Version to use - Either SSLV3 or SSLV2.
#
Syntax: SSLVersion <SSLV2> | <SSLV3> | <ALL>
#
Default: <ALL>
#
SSLVersion
SSLV3
#
SSLV3Timeout:
#
#
The time in seconds allowed before an SSL V3 session will expire.
#
#
Default: 1000
#
Valid range: 1 - 86400 seconds (1 day)
#
Syntax:
SSLV3Timeout <seconds>
SSLV3Timeout 1000
#
#
#
#
SSLV2Timeout:
The time in seconds allowed before an SSL V2 session will expire.
Appendix A. Configuration files and scripts
581
#
Default: 50
#
Valid range: 1 - 100 seconds
#
Syntax:
SSLV2Timeout <seconds>
#SSLV2Timeout 50
#
#
#
#
#
#
TLSV1Enable
set the TLSV1 protocol on and off
Default: OFF
Syntax: TLSV1Enable [ON|OFF]
#
KeyRing directive:
#
#
Specifies the file path to the Key Ring Database the server will
#
use for SSL requests. Key Ring Files are generated via the
#
IKeyman utility.
#
#
Default: none
#
Syntax:
KeyRing <filename>
#
# Example:
# KeyRing /etc/key.kdb
#
KeyRingStash directive:
#
#
Specifies the file path to the Key Ring Database’s password file.
#
The password file is generated via the IKeyman utility when building
#
a Key Ring Database File.
#
#
Default: none
#
Syntax:
KeyRingStash <filename>
#
# Example:
# KeyRingStash /etc/key.sth
#
SSL V3 Cipherspecs:
#
The Cipherspecs allowed for SSL V3
#
# Syntax:
#
V3CipherSpecs <cipherspec string>
#
Default: US: “0A09060564620403020100” Export: “0906646203020100”
#
#V3CipherSpecs 0A0605
#
#
582
SSL V2 Cipherspecs:
The Cipherspecs allowed for SSL V2
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
# Syntax:
#
V2CipherSpecs <cipherspec string>
#
Default: US: “137624” Export: “246”
#
#V2CipherSpecs
176
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
SSLCertificate:
Use this directive to specify key labels to allow the proxy to
determine which certificate to send to the client when WTE is acting
as a single reverse proxy for multiple domains that are offering their
own SSL certificates.
Syntax:
SSLCertificate Domain/serverIP CertLabel ClientAuth
ClientAuth: [NoClientAuth, ClientAuthRequired, NULL]
Examples:
SSLCertificate myHostname SSCertLabel1 ClientAuthRequired
SSLCertificate 0.0.0.0 SSCert1 NoClientAuth
Default:
No default, customer must define SSLCertificate before using SSL
# SSLCryptoCard
# Use this directive if there is a cryptographic card installed.
#
# Syntax:
# SSLCryptoCard CardName ON/OFF
# where CardName: rainbowcs, nciphernfast
#
# default:
# no need to define this directive if there is no cryptographic hardware
installed
#
#
#
#
#
#
#
#
#
#
#
ForwardSSLPort directive:
Once this directive is specified(non zero), a new thread will
be created to listen on this port. All the http proxy requests
sent to this port will be changed to secure requests
Note: You must enable SSL support to use this directive.
Default: 0
Syntax: ForwardSSLPort
8888
SSLCRLLDAPServer directive:
Appendix A. Configuration files and scripts
583
#
#
#
#
#
#
#
#
#
#
#
Specifies one or more LDAP servers to use for checking for revoked
certificates in the LDAP Certificate Revocation List (CRL). For
each server, specify the LDAP server name, its corresponding port,
user (distinguished name) and password. You can specify up to 10
LDAP servers; additional ones will be ignored. The order of the
directives determines the order in which the LDAP server’s CRL is
checked.
#
#
#
#
#
#
#
Default: <none>
Syntax: SSLCRLLDAPServer <ldap server> <port> <DNuser> <passwd>
If this directive is not set, there is no CRL check on certificates.
If it is set, but not correctly set or the server is down, the CRL
checking will assume fail and the SSL handshake will fail.
Example:
SSLCRLLDAPServer ldap1.acme.com 389 cn=root,o=Acme,c=US password1
SSLCRLLDAPServer ldap2.acme.com 389 cn=admin password2
# ===================================================================== #
#
#
Miscellaneous directives
#
# ===================================================================== #
#
ConfigFile directive:
#
#
Specifies the name of an additional configuration file. Directives
#
found in the specified configuration file will be processed after
#
processing the current configuration file.
#
#
For backwards compatability, the directive ‘RCAConfigFile’ is
#
supported as an alias for ConfigFile.
#
#
Default: none
#
Syntax:
ConfigFile <filename>
#
# Example:
# ConfigFile /etc/rca.conf
#
#
584
FTPUrlPath directive:
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
Specifies whether FTP url paths should be treated as absolute
#
paths (specified in relation to the root directory) or as
#
relative paths (specified in relation to the home directory)
#
#
Default: absolute
#
#
Syntax: FTPUrlPath <absolute | relative>
#
# Example:
# FTPUrlPath absolute
#
flexibleSocks directive:
#
#
Whether or not to use a socks conifiguration file to specify
#
hosts for direct connections or connections to a socks server.
#
#
Default: on
#
Syntax:
flexibleSocks <on | off>
flexibleSocks on
# TimeStamp directive:
#
# Enabling this directive will cause WTE to send timestamp information via
# response header. With this directive set to request, WTE will generate
# timestamp header only if timestamp (TS-) header is present in the request.
#
# The timestamp header records the request receipt time in microsecond since
# the midnight 1/1/70 CUT epoch, and the time elapsed in microsecond when
# WTE is about to send response back to client,
#
# Default: request
# Syntax: TimeStamp <enable | request | disable>
TimeStamp request
#
#
#
#
#
#
#
#
#
#
TimeStampId directive:
Provides an identity for timestamp header. By default, machine’s
hostname defined in DNS or as Hostname directive will be used. For
example, if TimeStampId is set as “test_proxy_host”, WTE will generate
a “TS-WTE-test_proxy_host:” response header.
Default: <none>
Syntax: TimeStampId <EntityId>
TransparentProxy directive:
Appendix A. Configuration files and scripts
585
#
#
Specifies if the server is to be run as a transparent proxy server.
#
#
Default: off
#
Syntax:
TransparentProxy <on | off>
TransparentProxy off
#
ListenBacklog directive:
#
#
Specifies the size of the listen backlog to use for the socket
#
the proxy server listens with.
#
#
Default: 128
#
Syntax:
ListenBacklog <value>
ListenBacklog 128
#
PacFilePath directive:
#
#
Specifies the directory containing the PAC files
#
generated using the remote config PAC file form.
#
This can be accessed at http://proxy/pac/*.
#
#
Default: /opt/ibm/edge/cp/server_root/pub/pacfiles
#
Syntax:
PacFilePath <filepath>
PacFilePath /opt/ibm/edge/cp/server_root/pub/pacfiles
#==================================================================
#
# System Plug-ins
# This section of the configuration file contains directives
# for plug-ins provided as part of the WTE distribution.
#
#==================================================================
#
# ICP Plug-in directives:
#
<ModuleBegin>ICP
#
#
#
#
#
586
ICP_Address directive
The IP address to use for sending and receiving ICP queries.
If this address is not specified, the default is to accept and send
ICP queries on any interface.
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
#
#
Syntax: ICP_Address <IP address>
# ICP_Port directive
#
# The port number on which the ICP Server listens for ICP queries.
#
# Syntax: ICP_Port <port number>
#
ICP_Port3128
# ICP_Timeout directive
#
# The maximum time in milliseconds to wait for responses to ICP queries
# If this is not specified a default timeout of 2000 milliseconds is used
#
# Syntax: ICP_Timeout <timeout in milliseconds>
#
ICP_Timeout2000
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
ICP_MaxThreads directive
This specifies the number of threads to spawn that listen for ICP
queries. The default is 5. (Note: On RedHat Linux 6.2 and lower,
this number must be low because the maximum number of threads that
can be created per process is small. Specifying a large number of
threads for ICP use might limit the number of threads available for
use in servicing requests.
Syntax: ICP_MaxThreads <number of threads>
Example:
ICP_MaxThreads5
ICP_Peer directive
This directive is used to specify an ICP peer. There should be one line
for each peer. When a new peer is added to the ICP cluster, a new
ICP_Peer line must be added to the configuration file of all peers.
The current host can be included in the peer list and will be ignored
by ICP at initialization. This feature makes it possible to use one
configuration file repeatedly in all peers, without having to edit the
file for each host to remove its definition.
Syntax: ICP_Peer
<hostname> <http_port> <icp_port>
<hostname>the name of the peer
<http_port>its proxy port
Appendix A. Configuration files and scripts
587
#
#
#
#
#
#
#
<icp_port>its icp server port
Example:
The following line adds the host example.transarc.ibm.com whose proxy
port is 80 and ICP port 3128, as a peer
ICP_Peerexample.transarc.ibm.com
803128
<ModuleEnd>
##
## Application Service at the Edge: Application router directives
## Use these directives to configure the behavior of an Edge Application.
##
<ModuleBegin> ApplicationProxy
# ApprouterAdminPort directive
#
# This is the port at which the Application router listens for
# Admin requests from the Edge Admin Server.
#
# Default: 6060
# Syntax: AppRouterAdminPort <Admin Port>
#
AppRouterAdminPort 6060
# AppRouterLocalWASPort directive
#
# This is the port at which the WebSphere Application server
# listens for applicationrequests.
#
# Default: 9080
# Syntax: AppRouterLocalWASPort <WAS Port>
AppRouterLocalWASPort 9080
# ApprouterRetryInterval directive
#
# This directive specifies the length of time after the application
# router disables local application execution due to an exception
# condition, following which the application router will try to
# reroute requests for local execution.
#
# Default: 3600 seconds.
# Syntax: ApprouterRetryInterval <seconds>
AppRouterRetryInterval 3600
#
588
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
<Application> { directive
This directive is used to indicate the beginning of an Edge
application configuration section. There should be a corresponding
‘}’ to terminate the section.
Example:
<Application> {
EarName /installedApps/app1.ear
DistributionType Preloaded
Enable yes
Context-root /servlet/
Context-root /otherservlets/
NonEdgableURI /otherservlets/notedgable
HTTPFailOverStatusCodes 500
}
##
## The following describe the directives that are valid within an
## Application section.
##
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
EarName directive
This directive is used to indicate the name of an application archive.
For applications that are preloaded or manually installed on the
machine this must be a full path name to the archive.
Default : none
Syntax : EarName <Name of Ear>
Examples:
EarName /usr/WebSphere/AppServer/installedApps/sampleApp.ear
DistributionType directive
This directive is used to indicate the type of distribution in place
of the application. The two supported distribution types are through
Content Distribution or manual installation.
Default : none
Syntax : DistributionType CDSManaged | PreLoaded
Example:
DistributionType PreLoaded
Appendix A. Configuration files and scripts
589
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
590
Enable directive
This directive allows the admin to temporarily enable or disable routing
requests that are meant for this particular application.
Default : no
Syntax : Enable yes|no
Example:
Enable no
Context-root directive
This directive allows the admin to specify the path prefixes of request
URIs that need to match in order for the request to be routed to this
application.
Default: none
Syntax: Context-root <URI - prefix>
Type : Multiple
Example:
Context-root /servlet
Context-root /jsp
NonEdgableURI directive
This directive allows the admin to route requests that match one of the
context root prefixes but is also matched by this directive to the origin
server. This can be used to define rules to defer execution of the
application to the origin server.
Default : none
Syntax: NonEdgableURI <URI>
Type : Multiple
Example :
NonEdgableURI /servlet/notedgableServlet1
NonEdbableURI /jsp/notedgable.jsp
HTTPFailoverStatusCodes directive
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#
#
#
#
#
#
#
#
#
#
#
This directive allows the application execution at this node to be
temporarily disabled for subsequent requests if a response failed
with a specific status code.
Default: none
Syntax: HTTPFailoverStatusCodes <HTTP status codes separated by ‘,’>
Example:
HTTPFailoverStatusCodes 400,500
##
## It is possible to define multiple Application sections as follows.
##
# <Application> {
# EarName /installedApps/app1.ear
# DistributionType Preloaded
# Enable yes
# Context-root /servlet/
# Context-root /otherservlets/
# NonEdgableURI /otherservlets/notedgable
# HTTPFailOverStatusCodes 500
# }
#
# <Application> {
# EarName app2.ear
# DistributionType CDSManaged
# Enable no
# Context-root /jsp/
# Context-root /otherjsps/
# NonEdgableURI /otherjsp/notedgable.jsp
# HTTPFailOverStatusCodes 500
# }
#
#
<ModuleEnd>
wses_51_cachingproxy_install.sh
Example A-60 is the WebSphere Caching Proxy installation script.
Example: A-60 Installation script for WebSphere Caching Proxy
#!/bin/sh
Appendix A. Configuration files and scripts
591
# Arguments (positioonal)
# 1: new user name ( root)
# 2: new user password ( smartway )
# 3: fully qualified file name to be used as proxy configuration (
/swdist/wses/new_ibmproxy.conf )
# 4: path of configuration file target location ( /opt/ibm/edge/cp/etc/en_US )
cp_home=/opt/ibm/edge/cp
# add userid
htadm -adduser $cp_home/server_root/protect/webadmin.passwd $1 $2
$1
# stop the server
/etc/init.d/ibmproxy stop
# copy new config file
cp $3 $4/ibmproxy.conf
# start the server
/etc/init.d/ibmproxy start
exit 0
wses_51_cachingproxy_uninstall.sh
Example A-61 is helpful when uninstalling the WebSphere Caching Proxy.
Example: A-61 Script to stop the WebSphere Caching Proxy
#!/bin/sh
/etc/init.d/ibmproxy stop
exit 0
A.7.10 WebSphere Caching Proxy v5.1 Fixpack 1
The following files in this section are used to define and build a software package
capable of installing and uninstalling WebSphere Caching Proxy v5.1 fixpack 1
592
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
In the online material, all these files are located in the following path relative to
the parent directory of the type of file:
/websphere/edge/510_fp1/cachingproxy/Linux-IX86.
was_cachingproxy.5.1.0_fp1.spd
Example A-62 is the software package definition file.
Example: A-62 Caching proxy fixpack 1 spd file
“TIVOLI Software Package v4.2.1 - SPDF”
package
name = t_wses_cachingproxy
title = “WAS Caching Proxy V5.1.1”
version = 5.1.0_fp1
web_view_mode = hidden
undoable = n
committable = n
history_reset = n
save_default_variables = n
creation_time = “2004-11-29 19:11:22”
last_modification_time = “2004-11-29 19:11:22”
default_variables
prod_name = wses_cachingproxy_510_fp1
inst_dir = /opt/ibm/edge
work_dir = $(root_dir)/$(prod_name)
log_dir = $(root_dir)/log/$(prod_name)
img_dir = $(work_dir)/image
bin_dir = $(root_dir)/bin/$(os_family)
root_dir = /swdist
tar_file = EdgeCachingProxy511-Linux.tar
home_path = /mnt
prod_path =
websphere/edge/510_fp1/cachingproxy/$(os_name)-$(os_architecture)
src_base = $(home_path)/code
src_dir = $(src_base)/$(prod_path)
rsp_base = $(home_path)/rsp
tool_base = $(home_path)/tools
tools_dir = $(tool_base)/$(prod_path)
unpack = yes
cleanup = yes
end
log_object_list
location = $(log_dir)
Appendix A. Configuration files and scripts
593
unix_user_id = 0
unix_group_id = 0
unix_attributes = rwx,rx,
end
source_host_name = srchost
move_removing_host = y
no_check_source_host = y
lenient_distribution = n
default_operation = install
server_mode = all
operation_mode = not_transactional
log_path = /mnt/logs/wses_cachingproxy_510_fp1.log
post_notice = y
before_as_uid = 0
skip_non_zero = n
after_as_uid = 0
no_chk_on_rm = y
log_host_name = srchost
versioning_type = swd
package_type = patch
sharing_control = none
stop_on_failure = y
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(tool_base)
name = common
translate = n
destination = $(root_dir)/bin
descend_dirs = y
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
594
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
compression_method = stored
rename_if_locked = n
end
add_directory
stop_on_failure = n
condition = “$(unpack) == yes”
add = y
replace_if_existing = n
replace_if_newer = n
remove_if_modified = n
location = $(src_base)
name = $(prod_path)
translate = n
destination = $(root_dir)/$(prod_name)
descend_dirs = n
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
generic_container
caption = “on install”
stop_on_failure = y
condition = “$(operation_name)
== install”
check_disk_space
volume = /,250M
end
add_directory
stop_on_failure = n
condition = “$(unpack) == yes”
Appendix A. Configuration files and scripts
595
add = y
replace_if_existing = n
replace_if_newer = n
remove_if_modified = n
location = $(src_base)
name = $(prod_path)
translate = n
destination = $(work_dir)/image
descend_dirs = n
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
execute_user_program
caption = unpack
condition = “$(unpack) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/bin/tar -C $(img_dir) -xvf
$(work_dir)/$(prod_name).tar”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_unpack.out
error_file = $(log_dir)/$(prod_name)_unpack.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
596
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
corequisite_files
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = $(src_dir)/$(tar_file)
translate = n
destination = $(work_dir)/$(prod_name).tar
compression_method = stored
rename_if_locked = n
end
end
end
end
end
execute_user_program
caption = “stop server”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/etc/init.d/ibmproxy stop”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_install_stopServer.out
error_file = $(log_dir)/$(prod_name)_install_stopServer.err
output_file_append = n
Appendix A. Configuration files and scripts
597
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
success = 1,65535
end
end
during_remove
path = $(bin_dir)/do_it
arguments = “/bin/rm -r $(work_dir)”
inhibit_parsing = n
working_dir = $(root_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_remove_cleanup.out
error_file = $(log_dir)/$(prod_name)_remove_cleanup.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,255
success = 256,65535
end
end
end
install_rpm_package
caption = “WAS Caching Proxy”
rpm_options = -vv
598
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
rpm_install_type = install
rpm_install_force = y
rpm_install_nodeps = n
rpm_remove_nodeps = n
rpm_report_log = y
rpm_file
image_dir = $(img_dir)/admin
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = WSES_Admin_Runtime-5.1.1-0
rpm_package_file = WSES_Admin_Runtime-5.1.1-0.i686.rpm
end
rpm_file
image_dir = $(img_dir)/cp
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = WSES_CachingProxy_msg_en_US-5.1.1-0
rpm_package_file = WSES_CachingProxy_msg_en_US-5.1.1-0.i686.rpm
end
rpm_file
image_dir = $(img_dir)/icu
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = WSES_ICU_Runtime-5.1.1-0
rpm_package_file = WSES_ICU_Runtime-5.1.1-0.i686.rpm
end
rpm_file
image_dir = $(img_dir)/cp
is_image_remote = y
keep_images = n
compression_method = stored
rpm_package_name = WSES_CachingProxy-5.1.1-0
rpm_package_file = WSES_CachingProxy-5.1.1-0.i686.rpm
end
rpm_file
image_dir = $(img_dir)/doc
is_image_remote = y
Appendix A. Configuration files and scripts
599
keep_images = n
compression_method = stored
rpm_package_name = WSES_Doc_en_US-5.1.1-0
rpm_package_file = WSES_Doc_en_US-5.1.1-0.i686.rpm
end
end
execute_user_program
caption = “start server”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “/etc/init.d/ibmproxy start”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_install_startServer.out
error_file = $(log_dir)/$(prod_name)_install_startServer.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
success = 1,65535
end
end
end
execute_user_program
caption = cleanup
condition = “$(cleanup) == yes”
transactional = n
during_install
600
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
path = $(bin_dir)/do_it
arguments = “/bin/rm -r $(work_dir)”
inhibit_parsing = n
working_dir = $(root_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_install_cleanup.out
error_file = $(log_dir)/$(prod_name)_install_cleanup.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,255
failure = 256,65535
end
end
during_remove
path = $(bin_dir)/do_it
arguments = “/bin/rm -r $(inst_dir)”
inhibit_parsing = n
working_dir = $(root_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file =
$(log_dir)/$(prod_name)_remove_instdir.out
error_file = $(log_dir)/$(prod_name)_remove_intdir.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
Appendix A. Configuration files and scripts
601
success = 0,0
failure = 1,65535
end
end
end
execute_user_program
caption = cleanup
condition = “$(cleanup) == yes”
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = “/etc/init.d/ibmproxy stop”
inhibit_parsing = n
working_dir = $(root_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file =
$(log_dir)/$(prod_name)_remove_stopServer.out
error_file = $(log_dir)/$(prod_name)_remove_stopServer.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
end
602
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
A.7.11 TimeCard v5.1
The following files in this section are used to define and build a software package
capable of installing and uninstalling the TimeCard application used in the Outlet
Solution.
In the online material, all these files are located in the following path relative to
the parent directory of the type of file: /outlet/TimeCard/510/all/generic.
timecard_510.spd
Example A-63 shows the software package used to install the TimeCard
WebSphere application.
Example: A-63 Software package for TimeCard installation and removal
“TIVOLI Software Package v4.2 - SPDF”
package
name = t_TimeCard
title = “TimeCard Store Application v5.1”
version = 5.1.0
web_view_mode = hidden
undoable = n
committable = o
history_reset = y
save_default_variables = n
creation_time = “2005-02-28 21:14:04”
last_modification_time = “2005-03-01 13:15:29”
default_variables
was_home = /opt/IBM/WebSphere/AppServer
db2_home = /opt/IBM/db2/V8.1
wasuser = root
waspassword = smartway
wasserver = server1
TimeCardDB = STORE
TimeCardInstance = db2inst1
img_base = $(work_dir)/image
root_dir = /swdist
home_path = /mnt
work_dir = $(root_dir)/$(prod_name)
src_dir = $(src_base)/$(prod_path)
prod_name = timecard_510
inst_dir = /opt/IBM/WebSphere/AppServer
tools_dir = $(tool_base)/$(prod_path)
bin_dir = $(root_dir)/bin/$(os_family)
Appendix A. Configuration files and scripts
603
log_dir = $(root_dir)/log/$(prod_name)
tool_base = $(home_path)/tools
prod_path = outlet/TimeCard/510/all/generic
src_base = $(home_path)/code
cleanup = yes
end
log_object_list
location = $(log_dir)
unix_user_id = 0
unix_group_id = 0
unix_attributes = rwx,rx,
end
source_host_name = srchost
move_removing_host = y
no_check_source_host = y
lenient_distribution = y
default_operation = install
server_mode = all
operation_mode = not_transactional,force
log_path = /mnt/logs/timecard_510.log
post_notice = y
before_as_uid = 0
skip_non_zero = n
after_as_uid = 0
no_chk_on_rm = y
log_host_name = srchost
versioning_type = none
package_type = refresh
stop_on_failure = y
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(tool_base)
name = common
translate = n
destination = $(root_dir)/bin
descend_dirs = y
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = y
604
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
unix_attributes = rwx,rx,rx
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(src_base)
name = $(prod_path)
translate = n
destination = $(root_dir)/$(prod_name)
descend_dirs = n
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_attributes = rwx,rx,rx
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
Appendix A. Configuration files and scripts
605
add_directory
stop_on_failure = y
add = y
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
location = $(tool_base)
name = $(prod_path)
translate = n
destination = $(root_dir)/$(prod_name)
descend_dirs = n
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = timecard_install.sh
translate = n
destination = $(prod_name)_install.sh
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
606
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = db2_store_cfg.sh
translate = n
destination = db2_store_cfg.sh
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,rx
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = Table.ddl
translate = n
destination = Table.ddl
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,rx
unix_owner = root
unix_user_id = 0
Appendix A. Configuration files and scripts
607
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
add_file
replace_if_existing = y
replace_if_newer = n
remove_if_modified = n
name = timecard_install.jacl
translate = n
destination = timecard_install.jacl
remove_empty_dirs = y
is_shared = n
remove_extraneous = n
substitute_variables = y
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
end
generic_container
caption = “on install”
stop_on_failure = y
condition = “$(operation_name)
== install”
check_disk_space
608
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
volume = /,500M
end
add_directory
stop_on_failure = n
add = y
replace_if_existing = n
replace_if_newer = n
remove_if_modified = n
location = $(src_base)
name = $(prod_path)/installableApps
translate = n
destination = $(inst_dir)/installableApps
descend_dirs = y
remove_empty_dirs = n
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
add_directory
stop_on_failure = n
add = y
replace_if_existing = n
replace_if_newer = n
remove_if_modified = n
location = $(src_base)
name = $(prod_path)/properties
translate = n
destination = $(inst_dir)/properties
descend_dirs = y
remove_empty_dirs = n
Appendix A. Configuration files and scripts
609
is_shared = n
remove_extraneous = n
substitute_variables = n
unix_attributes = rwx,rx,
unix_owner = root
unix_user_id = 0
unix_group_id = 0
create_dirs = y
remote = n
compute_crc = n
verify_crc = n
delta_compressible = d
temporary = n
is_signature = n
compression_method = stored
rename_if_locked = n
end
execute_user_program
caption = “Install TimeCard”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “$(work_dir)/$(prod_name)_install.sh install”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_install.out
error_file = $(log_dir)/$(prod_name)_install.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = y
retry = 1
exit_codes
success = 0,0
warning = 1,9
failure = 10,65535
end
610
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
end
end
execute_user_program
caption = cleanup
condition = “$(cleanup) == yes”
transactional = n
during_install
path = $(bin_dir)/do_it
arguments = “rm -r $(work_dir)”
inhibit_parsing = n
working_dir = $(root_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_cleanup.out
error_file = $(log_dir)/$(prod_name)_cleanup.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
failure = 1,65535
end
end
end
end
generic_container
caption = “on remove”
stop_on_failure = y
condition = “$(operation_name)
== remove”
execute_user_program
Appendix A. Configuration files and scripts
611
caption = “remove”
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = “$(work_dir)/$(prod_name)_install.sh uninstall”
inhibit_parsing = n
working_dir = $(work_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_uninstall.out
error_file = $(log_dir)/$(prod_name)_uninstall.err
output_file_append = n
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,1
failure = 2,65535
end
end
end
execute_user_program
caption = “remove work_dir”
transactional = n
during_remove
path = $(bin_dir)/do_it
arguments = “/bin/rm -r $(work_dir)”
inhibit_parsing = n
working_dir = $(root_dir)
timeout = -1
unix_user_id = 0
unix_group_id = 0
user_input_required = n
output_file = $(log_dir)/$(prod_name)_remove_workdir.out
error_file = $(log_dir)/$(prod_name)_remove_workdir.err
output_file_append = n
612
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
error_file_append = n
reporting_stdout_on_server = y
reporting_stderr_on_server = y
max_stdout_size = 10000
max_stderr_size = 10000
bootable = n
retry = 1
exit_codes
success = 0,0
success = 1,65535
end
end
end
end
end
timecard_install.sh
Example A-64 is the script that controls the TimeCard installation.
Example: A-64 Timecard installation and setup script
#!/bin/sh
function=$1
was_home=$(was_home)
hostname=‘hostname‘
servername=$(wasserver)
wasuser=$(wasuser)
waspassword=$(waspassword)
curdir=‘pwd‘
db2_home=$(db2_home)
jaclfile=./timecard_install.jacl
wsadmin=”${was_home}/bin/wsadmin.sh -conntype SOAP -host localhost -port 8880
-username ${wasuser} -password ${waspassword} -f ${jaclfile}”
curdir=‘pwd‘
doit () {
echo “Executing command: “ $1
$1
Appendix A. Configuration files and scripts
613
rc=$?
echo “-- result was: “ $rc
return $rc;
}
restart () {
doit “${was_home}/bin/stopServer.sh ${servername} -user ${wasuser} -password
${waspassword}”
doit “${was_home}/bin/startServer.sh ${servername} -user ${wasuser} -password
${waspassword}”
}
setup () {
doit “${was_home}/bin/setupCmdLine.sh “
doit “${was_home}/bin/startServer.sh ${servername} -user ${wasuser} -password
${waspassword}”
doit “${wsadmin} create”
doit “${wsadmin} install”
doit “${wsadmin} start”
doit “${was_home}/bin/GenPluginCfg.sh -node.name ${hostname}”
doit “export LIBPATH=${db2_home}/lib:${db2_home}/java”
restart
}
case $function in
install)
# create database and more
doit “./db2_store_cfg.sh install”
#install websphere application
setup
;;
setup)
#install websphere application
setup
#doit “${was_home}/bin/setupCmdLine.sh “
#doit “${was_home}/bin/startServer.sh ${servername} -user ${wasuser}
-password ${waspassword}”
#doit “${wsadmin} create”
#doit “${wsadmin} install”
#doit “${wsadmin} start”
#doit “${was_home}/bin/GenPluginCfg.sh -node.name ${hostname}”
;;
uninstall)
614
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
#remove websphere application
doit “${was_home}/bin/setupCmdLine.sh “
doit “${wsadmin} stop”
doit “${wsadmin} uninstall”
doit “${wsadmin} remove”
doit “${was_home}/bin/GenPluginCfg.sh -node.name ${hostname}”
restart
# remove database and more
doit “./db2_store_cfg.sh uninstall”
;;
remove)
#remove websphere application
doit “${was_home}/bin/setupCmdLine.sh “
doit “${wsadmin} stop”
doit “${wsadmin} uninstall”
doit “${wsadmin} remove”
doit “${was_home}/bin/GenPluginCfg.sh -node.name ${hostname}”
# remove database and more
#doit “./db2_store_cfg.sh uninstall”
;;
*)
echo “Illegal function ${function} “
;;
esac
exit 0
db2_store_cfg.sh
Example A-65 is the script used to create the STORE database for the TimeCard
application.
Example: A-65 db2_store_cfg.sh script to create store databases
#!/bin/sh
function=$1
Appendix A. Configuration files and scripts
615
doit () {
echo “Executing command: “ $1
$1
rc=$?
echo “-- result was: “ $rc
return $rc;
}
db2_home=”$(db2_home)”
db2grp=”db2grp1”
db2instance=”$(TimeCardInstance)”
db2database=”$(TimeCardDB)”
password=”$(waspassword)”
curdir=‘pwd‘
myself=${curdir}/db2_store_cfg.sh
file=”${curdir}/Table.ddl”
case $function in
create_database)
file=$2
doit “db2start”
doit “db2 drop db ${db2database}”
doit “db2 create db ${db2database}”
doit “db2 connect to ${db2database}”
doit “db2 grant connect on database to user appuser”
doit “db2 -tvf $file”
doit “db2 drop alias appuser.timecardentity”
doit “db2 create alias appuser.timecardentity for timecardentity”
doit “db2 grant select,insert,update,delete on timecardentity to user
appuser”
;;
stop_database)
doit “db2stop -force”
;;
install)
## define group
echo “ ensuring existance of db2 user group”
doit “groupadd $db2grp”
616
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
## define user db2store
echo “ creating instance user”
doit “useradd -g $db2grp -G root -m -p $password $db2instance”
## create db2store instance
instance_list=‘${db2_home}/instance/db2iset -l‘
create_instance=true
for instance in $instance_list;
do
if [ $instance = $db2instance ]; then
create_instance=false
break
fi
done
if [ $create_instance = “true” ]; then
doit “${db2_home}/instance/db2icrt -a SERVER -p 50001 -s ese -u db2fenc1
$db2instance”
su - $db2instance -c “$myself create_database $file”
else
echo “Instance $db2instance already exists”
fi
;;
uninstall)
## drop db2store instance
instance_list=‘${db2_home}/instance/db2iset -l‘
drop_instance=false
for instance in $instance_list;
do
if [ $instance = $db2instance ]; then
drop_instance=true
break
fi
done
if [ $drop_instance = “true” ]; then
## stop the database
su - $db2instance -c “$myself stop_database $file”
doit “${db2_home}/instance/db2idrop $db2instance”
else
Appendix A. Configuration files and scripts
617
echo “Instance $db2instance does not exist”
fi
doit “userdel -r $db2instance”
;;
*)
echo “Illegal function: $function”
esac
exit 0
Table.ddl
Example A-66 shows the DB2 data definitions used to create the database
objects for the TimeCard application.
Example: A-66 Store database table definitions
-- Generated by Relational Schema Center on Fri Jan 30 17:03:38 EST 2004
DROP TABLE TIMECARDENTITY;
CREATE TABLE TIMECARDENTITY
(USERID VARCHAR(250) NOT NULL,
JOBDATE DATE NOT NULL,
INTIME TIME,
OUTTIME TIME);
ALTER TABLE TIMECARDENTITY
ADD CONSTRAINT PK_TIMECARDENTITY PRIMARY KEY (USERID, JOBDATE);
timecard_install.jacl
Example A-67 is the control file for installing the TimeCard J2EE application.
Example: A-67 TimeCard application installation script
# Usage: wsadmin -connType SOAP -host <HOSTNAME> -port 8880 -user wasuser
-password clemson -f installApp.jacl
# Configure Authentication Alias
# Configure JDBC Data Source and J2C Authentication Alias
# Install TimeCardEARProject application
618
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
# Authentication Alias Configuration
puts “received command: $argv”
set function $argv
#set function “create”
#set function “install”
#set function “start”
#set function “stop”
#set function “uninstall”
#set function “remove”
# <---------------set dbuser “$(wasuser)”
set dbpassword “$(waspassword)”
set wasuser “$(wasuser)”
set wasuserpw “$(waspassword)”
set db2_home “$(db2_home)”
set was_home “$(was_home)”
set driverClassPath “$(db2_home)/java/db2java.zip”
set serverName “$(wasserver)”
# <----------------set
set
set
set
aliasName “TimeCardAlias”
dsName “TimeCardDataSource”
applName “TimeCardEARProject”
databaseName1 “$(TimeCardDB)”
puts “ Getting ready to $function $applName”
set desc_attr [list description “Time Card Application Alias”]
set
set
set
set
set
set
cellName [$AdminControl getCell]
nodeName [$AdminControl getNode]
secId [$AdminConfig getid /Cell:$cellName/Security:/]
alias_attr [list alias $aliasName]
userid_attr [list userId $dbuser]
password_attr [list password $dbpassword]
set cellId [$AdminConfig getid /Cell:$cellName/]
set nodeId [$AdminConfig getid /Cell:$cellName/Node:$nodeName/]
set serverId [$AdminConfig getid /Node:$nodeName/Server:$serverName]
Appendix A. Configuration files and scripts
619
set cfName ${dsName}_CF
set mappingConfigAlias “DefaultPrincipalMapping”
set dsDescription “DataSource for Time Card application”
set applearname “${applName}.ear”
set jndiName “jdbc/TimeCardDataSource”
set statementCacheSize 10
set datasourceHelperClassname com.ibm.websphere.rsadapter.DB2DataStoreHelper
set rsadapterID [$AdminConfig list J2CResourceAdapter $serverId]
##set providerName “DB2 JDBC Provider (XA)”
##set implementationClassName “COM.ibm.db2.jdbc.DB2XADataSource”
set providerName “DB2 JDBC Provider”
##set implementationClassName “COM.ibm.db2.jdbc.DB2DataSource”
set implementationClassName “COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource”
set providerDescription $providerName
set datasourceHelperClassname “com.ibm.websphere.rsadapter.DB2DataStoreHelper”
set authAliasName “StoreDataSourceAuthData”
set scope $serverId
########################################################
if { ${function} == “create” } {
# ----------------#
# Create the TradeDataSource Authentication Alias
#
puts “ “
puts “ “
puts “...Creating JAAS AuthData $authAliasName”
set attrs [subst {(cells/${cellName}:security.xml)} ]
set attrs0 [subst {{alias $authAliasName} {$userid_attr} {$password_attr}}]
foreach authEntry [$AdminConfig list JAASAuthData] {
foreach aliasEntry [$AdminConfig showall $authEntry] {
if { [lsearch -regexp $aliasEntry $authAliasName] >= 0 } {
puts “$authAliasName already exists”
set authDataAlias $authEntry
break
}
}
}
if { ![info exists authDataAlias] } {
# Always create AuthData at cell level
set authDataAlias [$AdminConfig create JAASAuthData $attrs $attrs0 ]
}
620
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
puts “authDataAlias: $authDataAlias”
# ----------------puts “ “
puts “ “
puts “Creating JDBCProvider in scope $scope”
set attrs1 [subst {{classpath “$driverClassPath”} {implementationClassName
$implementationClassName} {name \”$providerName\”} {description
“$providerDescription”}}]
foreach providerEntry [$AdminConfig list JDBCProvider $scope] {
if { [string first $providerName $providerEntry] >= 0 } {
puts “$providerName already exists for $scope”
set provider $providerEntry
break
}
}
# If JDBC provider does not yet exist, create a new one
if { ![info exists provider] } {
set provider [$AdminConfig create JDBCProvider $scope $attrs1]
}
##puts “$AdminConfig getid
/Cell:$cellName/Node:$nodeName/Server:$serverName/JDBCProvider:$providerName/”
##set provider [$AdminConfig getid
/Cell:$cellName/Node:$nodeName/Server:$serverName/JDBCProvider:$providerName/]
puts “provider: $provider”
# ----------------puts “ “
puts “ “
puts “...Creating Datasource $provider”
set attrs2 [subst {{name “$dsName”} {description “$dsDescription”} {jndiName
$jndiName} {statementCacheSize $statementCacheSize} {datasourceHelperClassname
$datasourceHelperClassname} {relationalResourceAdapter $rsadapterID}
{authMechanismPreference “BASIC_PASSWORD”} {authDataAlias “TimeCardAlias”}}]
foreach dsEntry [$AdminConfig list DataSource $scope] {
if { [string first $dsName $dsEntry] >= 0 } {
puts “DataSource $dsName already exists”
set DoNoCreateDatasource “true”
set datasource $dsEntry
break
}
}
Appendix A. Configuration files and scripts
621
#
# If DataSource does not yet exist, create a new one
#
if { ![info exists datasource] } {
set datasource [$AdminConfig create DataSource $provider $attrs2]
}
puts “datasource: $datasource”
# ----------------if { ![info exists DoNoCreateDatasource] } {
puts “ “
puts “ “
puts “...Creating J2EEResourcePropertySet for $datasource”
set propSet1 [$AdminConfig create J2EEResourcePropertySet $datasource {}]
puts “propSet1: $propSet1”
#-----------------puts “ “
puts “ “
puts “...Creating J2EEResourceProperty for $propSet1”
set attrs3 [subst {{name databaseName} {type java.lang.String} {value
“$databaseName1”}}]
set j2eeprop1 [$AdminConfig create J2EEResourceProperty $propSet1 $attrs3]
puts “j2eeprop1: $j2eeprop1”
#------------------puts “ “
puts “ “
puts “...Creating ConnectionPool for $datasource”
set connectionPool1 [$AdminConfig create ConnectionPool $datasource
{{connectionTimeout 1000} {maxConnections 30} {minConnections 1} {agedTimeout
1000} {reapTime 2000} {unusedTimeout 3000}}]
puts “connectionPool1 = $connectionPool1”
#------------------puts “ “
puts “ “
puts “...Creating $mappingConfigAlias on $datasource”
set map1 [$AdminConfig create MappingModule $datasource {{mappingConfigAlias
$mappingConfigAlias} {authDataAlias {}}}]
puts “map1: $map1”
}
#------------------puts “ “
puts “ “
622
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
puts “...Creating ConnectionFactory”
foreach cfEntry [$AdminConfig list CMPConnectorFactory $rsadapterID] {
if { [string first $cfName $cfEntry] >= 0 } {
puts “Connection factory $cfName already exists for $rsadapterID”
set cf1 $cfEntry
break
}
}
# If ConnectionFactory does not yet exist, create a new one
if { ![info exists cf1] } {
puts “Creating ConnectionFactory $cfName on $rsadapterID”
set attrs4 [subst {{name $cfName} {authMechanismPreference BASIC_PASSWORD}
{cmpDatasource $datasource} {authDataAlias “$aliasName”}}]
set cf1 [$AdminConfig create CMPConnectorFactory $rsadapterID $attrs4]
}
puts “connectionFactory1: $cf1”
puts “ “
puts “Saving configuration..”
$AdminConfig save
#>>>>>>>>>>>>>>>>>>>>>>>>>>>>> SECUTIRY AND MORE
puts “ “
puts “ “
puts “Seting JVM Arguments”
# Set JVM Arguments (Server1->ProcessDefinition->JVM->Generic JVM Arguments).
# Create java properties: qMgr & queue.
set jvm [$AdminConfig list JavaVirtualMachine]
set qMgr “QMGR.STORE.1”
set queue “TIMECARD.QUEUE”
set jvmarg “-Dstore.queue.manager=$qMgr -Dstore.queue=$queue”
set attrs5 [subst {{genericJvmArguments [list $jvmarg]}}]
$AdminConfig modify $jvm $attrs5
######$AdminConfig save
puts “ “
puts “ “
puts “CUSTOM USER REGISTRY Configuration”
# CUSTOM USER REGISTRY Configuration
Appendix A. Configuration files and scripts
623
# Set active user registry to Custom User registry
set user_regName “Custom”
set security_item [$AdminConfig list Security]
# List all the user registries defined
set user_regs [$AdminConfig list UserRegistry]
# Find the one that starts with the name we set at the beginning of the script
foreach user_reg $user_regs { if {[regexp $user_regName $user_reg]} { set
new_user_reg $user_reg; break }}
set attrs6 [subst {{activeUserRegistry $new_user_reg} {enabled true}
{enforceJava2Security false}}]
# Modify the user registry attribute for the security object
$AdminConfig modify $security_item $attrs6
#################$AdminConfig save
puts “ “
puts “ “
puts “Set the properties for Custom User Registry”
# Set the properties for Custom User Registry
set curClassName “com.ibm.websphere.security.FileRegistrySample”
set serverId $wasuser
set serverPassword $wasuserpw
set properties [list [list [list name “usersFile”] [list value
“${was_home}/properties/users.prop”]] [list [list name “groupsFile”] [list
value “${was_home}/properties/groups.prop”]]]
set attrs7 [subst {{customRegistryClassName $curClassName} {serverId $serverId}
{serverPassword $serverPassword} {properties [list $properties]}}]
$AdminConfig modify $new_user_reg $attrs7
###############$AdminConfig save
$AdminConfig save
}
########################################################
if { ${function} == “install” } {
#-------------puts “ “
puts “ “
puts “Installing TimeCardEARProject application”
foreach applEntry [$AdminApp list] {
if { [string first $applName $applEntry] >= 0 } {
puts “Application $applName has already been installed”
set appl1 $applEntry
624
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
break
}
}
# If Application has not been installed, install it
if { ![info exists appl1] } {
$AdminApp install ${was_home}/installableApps/${applearname}
}
}
########################################################
if { ${function} == “start” } {
#---------------#puts “ “
#puts “ “
#puts “Starting TimeCardEARProject application”
#
set appMgr [$AdminControl queryNames
cell=$cellName,node=$nodeName,type=ApplicationManager,process=server1,*]
$AdminControl invoke $appMgr startApplication ${applName}
}
########################################################
if { ${function} == “stop” } {
#puts “ “
#puts “ “
#puts “Stopping $applName application”
#
set appMgr [$AdminControl queryNames
cell=$cellName,node=$nodeName,type=ApplicationManager,process=server1,*]
$AdminControl invoke $appMgr stopApplication ${applName}
}
Appendix A. Configuration files and scripts
625
########################################################
if { ${function} == “uninstall” } {
#-----------------puts “ “
puts “ “
puts “Uninstalling TimeCardEARProject application”
foreach applEntry [$AdminApp list] {
if { [string first $applName $applEntry] >= 0 } {
set appl1 [$AdminApp uninstall ${applName}]
break
}
}
# If Application has not been installed, don’t remove it
if { ![info exists appl1] } {
puts “Application $applName was not installed”
}
}
########################################################
if { ${function} == “remove” } {
#---------------puts “ “
puts “ “
puts “replacing CustomUserRegistry REGISTRY Configuration with
LocalOSUserRegistry”
### Set active user registry to Local OS registry
set regName “LocalOS”
set security_item [$AdminConfig list Security]
### List all the user registries defined
set user_regs [$AdminConfig list UserRegistry]
### Find the one that starts with the name we set at the beginning of the
script
foreach user_reg $user_regs { if {[regexp $regName $user_reg]} { set
new_user_reg $user_reg; break }}
set attrs6 [subst {{activeUserRegistry $new_user_reg} {enabled true}
{enforceJava2Security true}}]
## Modify the user registry attribute for the security object
626
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
$AdminConfig modify $security_item $attrs6
puts “ “
puts “ “
puts “Setring properties for LocalOSUserRegistry”
## Set the properties for Local User Registry
#set curClassName “com.ibm.websphere.security.FileRegistrySample”
set serverId $wasuser
set serverPassword $waspassword
##set properties [list [list [list name “usersFile”] [list value
“${was_home}/properties/users.prop”]] [list [list name “groupsFile”] [list
value “${was_home}/properties/groups.prop”]]]
##set attrs7 [subst {{customRegistryClassName $curClassName} {serverId
$serverId} {serverPassword $serverPassword} {properties [list $properties]}}]
set attrs7 [subst {{serverId $wasuser} {serverPassword $waspassword}}]
$AdminConfig modify $new_user_reg $attrs7
puts “ “
puts “ “
puts “...removing connection factory”
foreach cfEntry [$AdminConfig list CMPConnectorFactory $rsadapterID] {
if { [string first $cfName $cfEntry] >= 0 } {
puts “removing Connection factory $cfName for $rsadapterID”
$AdminConfig remove $cfEntry
break
}
}
# ----------------puts “ “
puts “ “
puts “...removing Datasource $dsName”
foreach dsEntry [$AdminConfig list DataSource $scope] {
if { [string first $dsName $dsEntry] >= 0 } {
puts “removing DataSource $dsName from $scope”
$AdminConfig remove $dsEntry
break
}
}
# ----------------puts “ “
puts “ “
puts “...removing JDBCProvider in scope $scope”
Appendix A. Configuration files and scripts
627
foreach providerEntry [$AdminConfig list JDBCProvider $scope] {
if { [string first $providerName $providerEntry] >= 0 } {
puts “$providerEntry is being removed from $scope”
$AdminConfig remove $providerEntry
break
}
}
# ----------------foreach authEntry [$AdminConfig list JAASAuthData] {
foreach aliasEntry [$AdminConfig showall $authEntry] {
if { [lsearch -regexp $aliasEntry $authAliasName] >= 0 } {
puts “$authAliasName is being removed”
$AdminConfig remove $authEntry
break
}
}
}
}
$AdminConfig save
exit
A.8 APM related scripts and files
This section shows the APM scripts and files.
A.8.1 ep_customization.sh
Example A-68 on page 628 shows the script for submitting the APM plan to
customize endpoints.
Example: A-68 ep_customization.sh
#!/bin/sh
set -x
ep_label=$1
TMR_NUMBER=$(wep $ep_label get object|cut -d “.” -f1)
TMR_NAME=$(wlookup -ar ManagedNode|grep $TMR_NUMBER.1. | awk ‘{print $1}’)
628
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
STORE=‘echo $ep_label | cut -d “_” -f3 | cut -d “-” -f1‘
SCRIPTS_LOC=”/mnt/code/tivoli/scripts”
#plan_name=”$SCRIPTS_LOC/apps/APM/new.xml”
plan_name=”$SCRIPTS_LOC/apps/APM/Production_Outlet_Plan_v1.0.xml”
#plan_name=”$SCRIPTS_LOC/apps/APM/test/test1.xml”
LOG_FILE=”$SCRIPTS_LOC/apps/APM/logs/apm_plan.log”
# Submitting plan for the EP
wsubpln -t $ep_label \
-f $plan_name \
-o \
-VEP=$ep_label \
-VMN=$TMR_NAME
RC=$?
if [ $RC -eq 0 ]; then
echo “Activity Plan named $plan_name succesfully submitted” >> $LOG_FILE
else
echo “Failed to submit Activity Plan named $plan_name” >> $LOG_FILE
fi
A.8.2 Production_Outlet_Plan_v1.0.xml
Example A-69 shows the exported version of the APM plan used to control the
endpoint customization.
Example: A-69 Production_Outlet_Plan_v1.0.xml
<?xml version=”1.0”?>
<!DOCTYPE activity_plan SYSTEM “apm_plan.dtd”>
<activity_plan>
<name>Production_Outlet_Activity_Plan</name>
<priority>medium</priority>
<submit_paused>n</submit_paused>
<cancel_at_cutoff>n</cancel_at_cutoff>
<post_notice>y</post_notice>
<targets_computation>p</targets_computation>
<activity>
<application>SoftwareDistribution</application>
<name>db2udb_server^8.2#hubtmr-region[0]</name>
<target_resource_type>endpoint</target_resource_type>
<targets type=”list”>$(TARGET_LIST)</targets>
<targets_computation>p</targets_computation>
<operation>Install</operation>
<parameter>
<name>EnableMulticast</name>
Appendix A. Configuration files and scripts
629
<value>F</value>
</parameter>
<parameter>
<name>DistributionMode</name>
<value>CHNG_ALL</value>
</parameter>
<parameter>
<name>Transactional</name>
<value>TRAN_NO</value>
</parameter>
<parameter>
<name>Undo</name>
<value>UNDO_NO</value>
</parameter>
<parameter>
<name>RetryUnicast</name>
<value>F</value>
</parameter>
<parameter>
<name>RoamEp</name>
<value>T</value>
</parameter>
<parameter>
<name>Force</name>
<value>F</value>
</parameter>
<parameter>
<name>MobileForceMandatory</name>
<value>F</value>
</parameter>
<parameter>
<name>MobileHidden</name>
<value>F</value>
</parameter>
<parameter>
<name>FromCD</name>
<value>F</value>
</parameter>
<parameter>
<name>SoftwarePackage</name>
<value>db2udb_server^8.2#hubtmr-region</value>
</parameter>
<parameter>
<name>DependencyCheck</name>
<value>T</value>
</parameter>
<parameter>
<name>WakeOnLan</name>
<value>F</value>
630
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
</parameter>
<parameter>
<name>Reboot</name>
<value>REBOOT_NO</value>
</parameter>
<parameter>
<name>FromDepot</name>
<value>F</value>
</parameter>
<parameter>
<name>EnableNotification</name>
<value>F</value>
</parameter>
<parameter>
<name>AutoAccept</name>
<value>F</value>
</parameter>
<parameter>
<name>Ignore</name>
<value>F</value>
</parameter>
<parameter>
<name>LenientDistribution</name>
<value>T</value>
</parameter>
<parameter>
<name>DisconnectedOperation</name>
<value>F</value>
</parameter>
<parameter>
<name>Disposable</name>
<value>F</value>
</parameter>
<parameter>
<name>Priority</name>
<value>PRTY_MEDIUM</value>
</parameter>
<parameter>
<name>FromFileServer</name>
<value>F</value>
</parameter>
<parameter>
<name>AutoCommit</name>
<value>F</value>
</parameter>
</activity>
<activity>
<application>SoftwareDistribution</application>
<name>ihs_server^2.0.47#hubtmr-region[0]</name>
Appendix A. Configuration files and scripts
631
<target_resource_type>endpoint</target_resource_type>
<targets type=”list”>$(TARGET_LIST)</targets>
<targets_computation>p</targets_computation>
<operation>Install</operation>
<condition>ST(db2udb_server^8.2#hubtmr-region[0])</condition>
<parameter>
<name>EnableMulticast</name>
<value>F</value>
</parameter>
<parameter>
<name>DistributionMode</name>
<value>CHNG_ALL</value>
</parameter>
<parameter>
<name>Transactional</name>
<value>TRAN_NO</value>
</parameter>
<parameter>
<name>Undo</name>
<value>UNDO_NO</value>
</parameter>
<parameter>
<name>RetryUnicast</name>
<value>F</value>
</parameter>
<parameter>
<name>RoamEp</name>
<value>T</value>
</parameter>
<parameter>
<name>Force</name>
<value>F</value>
</parameter>
<parameter>
<name>MobileForceMandatory</name>
<value>F</value>
</parameter>
<parameter>
<name>MobileHidden</name>
<value>F</value>
</parameter>
<parameter>
<name>FromCD</name>
<value>F</value>
</parameter>
<parameter>
<name>SoftwarePackage</name>
<value>ihs_server^2.0.47#hubtmr-region</value>
</parameter>
632
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
<parameter>
<name>DependencyCheck</name>
<value>T</value>
</parameter>
<parameter>
<name>WakeOnLan</name>
<value>F</value>
</parameter>
<parameter>
<name>Reboot</name>
<value>REBOOT_NO</value>
</parameter>
<parameter>
<name>FromDepot</name>
<value>F</value>
</parameter>
<parameter>
<name>EnableNotification</name>
<value>F</value>
</parameter>
<parameter>
<name>AutoAccept</name>
<value>F</value>
</parameter>
<parameter>
<name>Ignore</name>
<value>F</value>
</parameter>
<parameter>
<name>LenientDistribution</name>
<value>T</value>
</parameter>
<parameter>
<name>DisconnectedOperation</name>
<value>F</value>
</parameter>
<parameter>
<name>Disposable</name>
<value>F</value>
</parameter>
<parameter>
<name>Priority</name>
<value>PRTY_MEDIUM</value>
</parameter>
<parameter>
<name>FromFileServer</name>
<value>F</value>
</parameter>
<parameter>
Appendix A. Configuration files and scripts
633
<name>AutoCommit</name>
<value>F</value>
</parameter>
</activity>
<activity>
<application>SoftwareDistribution</application>
<name>mq_series^5.1#hubtmr-region[0]</name>
<target_resource_type>endpoint</target_resource_type>
<targets type=”list”>$(TARGET_LIST)</targets>
<targets_computation>p</targets_computation>
<operation>Install</operation>
<condition>ST(ihs_server^2.0.47#hubtmr-region[0])</condition>
<parameter>
<name>SW_CCM_CB_OBJECT_0</name>
<value>1393424439.1.946#CCMEngine::CCM#</value>
</parameter>
<parameter>
<name>SW_CCM_CB_METHOD_0</name>
<value>ccm_receive_report</value>
</parameter>
<parameter>
<name>SW_CCM_REFMODEL_NAME</name>
<value>Outlet</value>
</parameter>
<parameter>
<name>SoftwarePackage</name>
<value>mq_series^5.1#hubtmr-region</value>
</parameter>
<parameter>
<name>EnableMulticast</name>
<value>F</value>
</parameter>
<parameter>
<name>RetryUnicast</name>
<value>F</value>
</parameter>
<parameter>
<name>SW_CCM_REFMODEL_VERSION</name>
<value>1.1.0</value>
</parameter>
</activity>
<activity>
<application>SoftwareDistribution</application>
<name>mq_series^5.1.FP01#hubtmr-region[0]</name>
<target_resource_type>endpoint</target_resource_type>
<targets type=”list”>$(TARGET_LIST)</targets>
<targets_computation>p</targets_computation>
<operation>Install</operation>
<condition>ST(mq_series^5.1#hubtmr-region[0])</condition>
634
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
<parameter>
<name>SW_CCM_CB_OBJECT_0</name>
<value>1393424439.1.946#CCMEngine::CCM#</value>
</parameter>
<parameter>
<name>SW_CCM_CB_METHOD_0</name>
<value>ccm_receive_report</value>
</parameter>
<parameter>
<name>SW_CCM_REFMODEL_NAME</name>
<value>Outlet</value>
</parameter>
<parameter>
<name>SoftwarePackage</name>
<value>mq_series^5.1.FP01#hubtmr-region</value>
</parameter>
<parameter>
<name>EnableMulticast</name>
<value>F</value>
</parameter>
<parameter>
<name>RetryUnicast</name>
<value>F</value>
</parameter>
<parameter>
<name>SW_CCM_REFMODEL_VERSION</name>
<value>1.1.0</value>
</parameter>
</activity>
<activity>
<application>SoftwareDistribution</application>
<name>was_applserver^5.1#hubtmr-region[0]</name>
<target_resource_type>endpoint</target_resource_type>
<targets type=”list”>$(TARGET_LIST)</targets>
<targets_computation>p</targets_computation>
<operation>Install</operation>
<condition>ST(mq_series^5.1.FP01#hubtmr-region[0])</condition>
<parameter>
<name>SW_CCM_CB_OBJECT_0</name>
<value>1393424439.1.946#CCMEngine::CCM#</value>
</parameter>
<parameter>
<name>SW_CCM_CB_METHOD_0</name>
<value>ccm_receive_report</value>
</parameter>
<parameter>
<name>SW_CCM_REFMODEL_NAME</name>
<value>Outlet</value>
</parameter>
Appendix A. Configuration files and scripts
635
<parameter>
<name>SoftwarePackage</name>
<value>was_applserver^5.1#hubtmr-region</value>
</parameter>
<parameter>
<name>EnableMulticast</name>
<value>F</value>
</parameter>
<parameter>
<name>RetryUnicast</name>
<value>F</value>
</parameter>
<parameter>
<name>SW_CCM_REFMODEL_VERSION</name>
<value>1.1.0</value>
</parameter>
</activity>
<activity>
<application>SoftwareDistribution</application>
<name>tmtp_ma^5.3#hubtmr-region[0]</name>
<target_resource_type>endpoint</target_resource_type>
<targets type=”list”>$(TARGET_LIST)</targets>
<targets_computation>p</targets_computation>
<operation>Install</operation>
<condition>ST(was_applserver^5.1#hubtmr-region[0])</condition>
<parameter>
<name>SW_CCM_CB_OBJECT_0</name>
<value>1393424439.1.946#CCMEngine::CCM#</value>
</parameter>
<parameter>
<name>SW_CCM_CB_METHOD_0</name>
<value>ccm_receive_report</value>
</parameter>
<parameter>
<name>SW_CCM_REFMODEL_NAME</name>
<value>Outlet</value>
</parameter>
<parameter>
<name>SoftwarePackage</name>
<value>tmtp_ma^5.3#hubtmr-region</value>
</parameter>
<parameter>
<name>EnableMulticast</name>
<value>F</value>
</parameter>
<parameter>
<name>RetryUnicast</name>
<value>F</value>
</parameter>
636
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
<parameter>
<name>SW_CCM_REFMODEL_VERSION</name>
<value>1.1.0</value>
</parameter>
</activity>
<activity>
<application>SoftwareDistribution</application>
<name>TimeCard_Application</name>
<description>Deply TimeCard Application</description>
<target_resource_type>endpoint</target_resource_type>
<targets type=”list”>$(TARGET_LIST)</targets>
<targets_computation>p</targets_computation>
<operation>Install</operation>
<condition>ST(tmtp_ma^5.3#hubtmr-region[0])</condition>
<parameter>
<name>EnableMulticast</name>
<value>F</value>
</parameter>
<parameter>
<name>DistributionMode</name>
<value>CHNG_ALL</value>
</parameter>
<parameter>
<name>Transactional</name>
<value>TRAN_NO</value>
</parameter>
<parameter>
<name>Undo</name>
<value>UNDO_NO</value>
</parameter>
<parameter>
<name>RetryUnicast</name>
<value>T</value>
</parameter>
<parameter>
<name>RoamEp</name>
<value>T</value>
</parameter>
<parameter>
<name>Force</name>
<value>F</value>
</parameter>
<parameter>
<name>MobileForceMandatory</name>
<value>T</value>
</parameter>
<parameter>
<name>MobileHidden</name>
<value>F</value>
Appendix A. Configuration files and scripts
637
</parameter>
<parameter>
<name>FromCD</name>
<value>F</value>
</parameter>
<parameter>
<name>SoftwarePackage</name>
<value>timecard^2.0#hubtmr-region</value>
</parameter>
<parameter>
<name>WakeOnLan</name>
<value>F</value>
</parameter>
<parameter>
<name>Reboot</name>
<value>REBOOT_NO</value>
</parameter>
<parameter>
<name>DependencyCheck</name>
<value>T</value>
</parameter>
<parameter>
<name>FromDepot</name>
<value>F</value>
</parameter>
<parameter>
<name>EnableNotification</name>
<value>F</value>
</parameter>
<parameter>
<name>Ignore</name>
<value>F</value>
</parameter>
<parameter>
<name>AutoAccept</name>
<value>F</value>
</parameter>
<parameter>
<name>LenientDistribution</name>
<value>T</value>
</parameter>
<parameter>
<name>DisconnectedOperation</name>
<value>F</value>
</parameter>
<parameter>
<name>Disposable</name>
<value>F</value>
</parameter>
638
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
<parameter>
<name>Priority</name>
<value>PRTY_MEDIUM</value>
</parameter>
<parameter>
<name>AutoCommit</name>
<value>F</value>
</parameter>
<parameter>
<name>FromFileServer</name>
<value>F</value>
</parameter>
</activity>
<activity>
<application>TaskLibrary</application>
<name>Discover_WebSphere_Resources</name>
<description>Discover WebSphere Application Servers</description>
<target_resource_type>managed_node</target_resource_type>
<targets type=”list”>$(MN)</targets>
<targets_computation>p</targets_computation>
<operation>ExecuteTask</operation>
<condition>SA(TimeCard_Application)</condition>
<parameter>
<name>ExecutionMode</name>
<value>EXEC_MODE_PARALLEL</value>
</parameter>
<parameter>
<name>OutputHost</name>
<value>hubtmr</value>
</parameter>
<parameter>
<name>OutputFormat</name>
<value>HROE</value>
</parameter>
<parameter>
<name>Library</name>
<value>WebSphere Application Server Utility
Tasks#hubtmr-region</value>
</parameter>
<parameter>
<name>Timeout</name>
<value>600</value>
</parameter>
<parameter>
<name>OutputFile</name>
<value>/tmp/task_was_discovery.out</value>
</parameter>
<parameter>
<name>Task</name>
Appendix A. Configuration files and scripts
639
<value>Discover_WebSphere_Resources</value>
</parameter>
<parameter>
<name>Argument2</name>
<value>$(EP)</value>
</parameter>
<parameter>
<name>Argument1</name>
<value>/opt/IBM/WebSphere/AppServer</value>
</parameter>
<parameter>
<name>Argument0</name>
<value>WebSphere Application Servers</value>
</parameter>
</activity>
<activity>
<application>TaskLibrary</application>
<name>ITM_WAS_AppSvr_RM_Distribution</name>
<description>Distributes ITM WAS RM for ApplicationServer
resource</description>
<target_resource_type>managed_node</target_resource_type>
<targets type=”list”>$(MN)</targets>
<targets_computation>p</targets_computation>
<operation>ExecuteTask</operation>
<condition>SA(Discover_WebSphere_Resources)</condition>
<parameter>
<name>OutputFile</name>
<value>/tmp/ITM_WAS_AppSvr_RM_Distribution.out</value>
</parameter>
<parameter>
<name>ExecutionMode</name>
<value>EXEC_MODE_PARALLEL</value>
</parameter>
<parameter>
<name>Timeout</name>
<value>600</value>
</parameter>
<parameter>
<name>Argument0</name>
<value>$(EP)</value>
</parameter>
<parameter>
<name>OutputHost</name>
<value>hubtmr</value>
</parameter>
<parameter>
<name>Library</name>
<value>Production_TL#hubtmr-region</value>
</parameter>
640
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
<parameter>
<name>OutputFormat</name>
<value>HROE</value>
</parameter>
<parameter>
<name>Task</name>
<value>itm_WAS_rm_distrib</value>
</parameter>
</activity>
<activity>
<application>TaskLibrary</application>
<name>Create_DB2_instance_objects</name>
<description>Creates a DB2 Instance object on an Endpoint with a DB2
server installation</description>
<target_resource_type>managed_node</target_resource_type>
<targets type=”list”>$(MN)</targets>
<targets_computation>p</targets_computation>
<operation>ExecuteTask</operation>
<condition>SA(ITM_WAS_AppSvr_RM_Distribution)</condition>
<parameter>
<name>OutputFile</name>
<value>/tmp/create_DB2_instance_objects.out</value>
</parameter>
<parameter>
<name>ExecutionMode</name>
<value>EXEC_MODE_PARALLEL</value>
</parameter>
<parameter>
<name>Timeout</name>
<value>600</value>
</parameter>
<parameter>
<name>Argument0</name>
<value>$(EP)</value>
</parameter>
<parameter>
<name>OutputHost</name>
<value>hubtmr</value>
</parameter>
<parameter>
<name>Library</name>
<value>Production_TL#hubtmr-region</value>
</parameter>
<parameter>
<name>OutputFormat</name>
<value>HROE</value>
</parameter>
<parameter>
<name>Task</name>
Appendix A. Configuration files and scripts
641
<value>Create_DB2_instance_objects</value>
</parameter>
</activity>
<activity>
<application>TaskLibrary</application>
<name>Create_DB2_database_objects</name>
<description>Creates a DB2 Database object on an Endpoint with a DB2
server installation</description>
<target_resource_type>managed_node</target_resource_type>
<targets type=”list”>$(MN)</targets>
<targets_computation>p</targets_computation>
<operation>ExecuteTask</operation>
<condition>SA(Create_DB2_instance_objects)</condition>
<parameter>
<name>OutputFile</name>
<value>/tmp/create_DB2_database_objects.out</value>
</parameter>
<parameter>
<name>ExecutionMode</name>
<value>EXEC_MODE_PARALLEL</value>
</parameter>
<parameter>
<name>Timeout</name>
<value>600</value>
</parameter>
<parameter>
<name>Argument0</name>
<value>$(EP)</value>
</parameter>
<parameter>
<name>OutputHost</name>
<value>hubtmr</value>
</parameter>
<parameter>
<name>Library</name>
<value>Production_TL#hubtmr-region</value>
</parameter>
<parameter>
<name>OutputFormat</name>
<value>HROE</value>
</parameter>
<parameter>
<name>Task</name>
<value>Create_DB2_database_objects</value>
</parameter>
</activity>
<activity>
<application>TaskLibrary</application>
<name>ITM_DB2_Database_RM_Distribution</name>
642
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
<description>Distributes ITM DB2 Resource Models for Database
Object(s)</description>
<target_resource_type>managed_node</target_resource_type>
<targets type=”list”>$(MN)</targets>
<targets_computation>p</targets_computation>
<operation>ExecuteTask</operation>
<condition>SA(Create_DB2_database_objects)</condition>
<parameter>
<name>OutputFile</name>
<value>/tmp/ITM_DB2_Database_RM_Distribution.out</value>
</parameter>
<parameter>
<name>ExecutionMode</name>
<value>EXEC_MODE_PARALLEL</value>
</parameter>
<parameter>
<name>Timeout</name>
<value>600</value>
</parameter>
<parameter>
<name>Argument0</name>
<value>$(EP)</value>
</parameter>
<parameter>
<name>OutputHost</name>
<value>hubtmr</value>
</parameter>
<parameter>
<name>Library</name>
<value>Production_TL#hubtmr-region</value>
</parameter>
<parameter>
<name>OutputFormat</name>
<value>HROE</value>
</parameter>
<parameter>
<name>Task</name>
<value>itm_DB2_database_rm_distrib</value>
</parameter>
</activity>
<activity>
<application>TaskLibrary</application>
<name>ITM_DB2_Instance_RM_Distribution</name>
<description>Distributes ITM DB2 Resource Models for Instance
Object(s)</description>
<target_resource_type>managed_node</target_resource_type>
<targets type=”list”>$(MN)</targets>
<targets_computation>p</targets_computation>
<operation>ExecuteTask</operation>
Appendix A. Configuration files and scripts
643
<condition>SA(ITM_DB2_Database_RM_Distribution)</condition>
<parameter>
<name>OutputFile</name>
<value>/tmp/ITM_DB2_Instance_RM_Distribution.out</value>
</parameter>
<parameter>
<name>ExecutionMode</name>
<value>EXEC_MODE_PARALLEL</value>
</parameter>
<parameter>
<name>Timeout</name>
<value>600</value>
</parameter>
<parameter>
<name>Argument0</name>
<value>$(EP)</value>
</parameter>
<parameter>
<name>OutputHost</name>
<value>hubtmr</value>
</parameter>
<parameter>
<name>Library</name>
<value>Production_TL#hubtmr-region</value>
</parameter>
<parameter>
<name>OutputFormat</name>
<value>HROE</value>
</parameter>
<parameter>
<name>Task</name>
<value>itm_DB2_instance_rm_distrib</value>
</parameter>
</activity>
</activity_plan>
644
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
B
Appendix B.
Obtaining the installation
images
This appendix shows you how to obtain the installation materials discussed in
this IBM Redbook.
© Copyright IBM Corp. 2005. All rights reserved.
645
IBM Business Partners
If you are a registered IBM Business Partner that has purchased the IBM
Software Access Option and signed the IBM PartnerWorld® Agreement
PartnerWorld Software Usage Attachment, you can download trail copies of all
the IBM software used in this book from the IBM Software Access Catalog Web
site:
http://www.developer.ibm.com/OrderingWeb/ordersw.do
1. Accept the Licence Agreement and select the Software Access Catalog Electronic Software Download site:
Figure B-1 Searching for Software Downloads
2. To find the needed packages for selected products at the Software Access
Catalog site, enter the product name as the search criteria and enable
searching for All of the words entered. Then, press Search, to view the list of
downloads that fulfill you search criteria.
3. In addition to downloadable images obtained from the PartnerWorld site, a
number of Fix Packs and Patches were used in the development of this book.
All of these can be downloaded from the IBM Support site at:
http://www.tivoli.com/support/patches
Table B-1 on page 647 outlines the downloadable installation images used in
the creation of this book.
646
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Table B-1 Installation image download reference
name
title
size (bytes)
Tivoli Management Framework 4.1.1
1,662,524,545
C531TML.tar
Tivoli Management Framework v4.1.1
1 of 2, Multiplatform, International
English, Brazilian Portuguese,
French, German, Italian, Spanish
690,575,360
C531UML.tar
Tivoli Management Framework v4.1.1
2 of 2, Multiplatform, International
English, Brazilian Portuguese,
French, German, Italian, Spanish
290,498,560
C53UXML.tar
Tivoli Management Framework
Compatibility v4.1.1, Multiplatform,
International English, Brazilian
Portuguese, French, German, Italian,
Spanish
419,543,040
C48E9IE.tar
Tivoli Management Framework Tier 2,
Multiplatform, International English
9,297,920
C531RIE.zip
Tivoli Management Framework
Documentation v4.1.1, Multiplatform,
International English
9,809,665
4.1.1-LCF-0008.tar a
Tivoli Framework Patch
4.1.1-LCF-0008
55,700,000
4.1.1-TMF-0011.tar a
Tivoli Framework Patch
4.1.1-TMF-0011
114,300,000
4.1.1-TMF-0021.tar a
Tivoli Framework Patch
4.1.1-TMF-0021
72,800,000
Tivoli Enterprise Console v3.9
1,920,552,303
C52J3IE.zip
IBM Tivoli Enterprise Console
Documentation V3.9 Multi Int Engl
312,525,800
C52IZIE.zip
IBM Tivoli Enterprise Console (TME
New Installations) V3.9 Multi Int
English
300,861,020
3.9.0-TEC-0003LA.tar a
IBM Tivoli Enterprise Console Version
3.9.0 LA Interim Fix 03 .
250,224,640
3.9.0-TEC-FP02.tar a
IBM Tivoli Enterprise Console Version
3.9.0 Fix Pack 2
1,056,940,843
Appendix B. Obtaining the installation images
647
name
title
Tivoli Configuration Manager v4.2.1
648
size (bytes)
2,440,060,622
C52NNML.tar
IBM Tivoli Configuration Manager
Installation v4.2.1, Multiplatform,
Brazilian Portuguese, French,
German, International English, Italian,
Japanese, Korean, Simplified
Chinese, Spanish
167,066,112
C52NKML.tar
IBM Tivoli Configuration Manager
Upgrade v4.2.1, Multiplatform,
Brazilian Portuguese, French,
German, International English, Italian,
Japanese, Korean, Simplified
Chinese, Spanish
678,571,008
C52NJML.tar
IBM Tivoli Configuration Manager
v4.2.1, Multiplatform, Brazilian
Portuguese, French, German,
International English, Italian,
Japanese, Korean, Simplified
Chinese, Spanish
482,354,176
C561XML.tar
IBM Tivoli Configuration Manager
Web Gateway v4.2.1, Multiplatform,
Brazilian Portuguese, French,
German, International English, Italian,
Japanese, Korean, Simplified
Chinese, Spanish
539,246,080
C52NLML.zip
IBM Tivoli Configuration Manager
Windows v4.2.1, Brazilian
Portuguese, French, German,
International English, Italian,
Japanese, Korean, Simplified
Chinese, Spanish
305,555,324
C52NQIE.zip
IBM Tivoli Configuration Manager
Documentation v4.2.1, International
English,
4.1.1-TCM-FP01_imag
es.tar a
IBM Tivoli Configuration
Manager,Version 4.2.1,Fix Pack
4.2.1-TCM-FP01 (U498122)
4.2.1-INV-0006.tar a
4.2.1-INV-0006, Tivoli Inventory 4.2.1
Interim Fix
18,754,242
241,735,680
6,778,000
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
name
title
size (bytes)
ITM v5.1.2
1,817,351,168
C560LML.tar
Tivoli Monitoring Install V5.1.2 Multi
Int Engl Braz Port French Italian
German Spanish Japanese Korean
Simp Chin Trad Chin
401,261,568
C560GIE.TAR
Tivoli Monitoring V5.1.2 Multi Int
English
155,426,304
C560KML.tar
Tivoli Monitoring Tools V5.1.2 Multi Int
English Braz Port French Italian
German Spanish Japanese Korean
Simp Chin Trad Chin
357,331,456
C57HEML.tar
Tivoli Monitoring Publications for the
UNIX User V5.1.2 Multiplatform ML
162,826,240
C46XCML.exe
IBM Tivoli Monitoring Web Health
Console V5.1.1 for Windows, Linux
Braz Port, French, Italian, German,
Spanish, Japanese, Korean, Simp
Chin, Trad Chin, Int English
330,798,592
C560IML.tar
Tivoli Monitoring Web Health Console
V5.1.2 Fixpack 6 Multi Int Engl Braz
Port French Italian German Spanish
Japanese Korean Simp Chin Trad
Chin
336,208,896
Obtain Web Health Console for
WebSphere 5.1 from your local Tivoli
Support organization
5.1.2-ITM-FP02.tar a
Fix Pack (5.1.2-ITM-FP02) for IBM
Tivoli Monitoring 5.1.2
66,801,152
5.1.1-ICS-FP02.tar a
IBM Tivoli Monitoring Component
Services 5.1.1 Fix Pack 2
6,696,960
IBM Monitoring for Databases
977,066,466
C508KML.tar
301,711,360
Tivoli Monitoring for Databases: Install
V5.1.1 AIX HP-UX Linux Solaris
Win2000 WinNT WinXP Int Engl Braz
Port French Italian German Spanish
Japan Korea Simp Chin Trad Chin
Appendix B. Obtaining the installation images
649
name
title
C476PML.exe
Tivoli Monitoring for Databases: Install
2 V5.1.1 AIX HP-UX Linux Solaris
Win2000 WinNT WinXP Int Engl Braz
Port French Italian German Spanish
Japan Korea Simp Chin Trad Chin
305,062,400
C508NIE.zip
Tivoli Monitoring for Databases:
Documentation V5.1.1 AIX HP-UX
Linux Solaris Win2000 WinNT WinXP
Int Engl
148,361,698
C476VIE.exe
Tivoli Monitoring for Databases: DB2
Component Software V5.1 AIX
HP-UX Linux Solaris Win2000 WinNT
WinXP Int Engl
110,550,528
5.1.0-ITMD-DB2-FP05.
image.tar a
IBM Tivoli Monitoring for Databases
5.1.0 - DB2 Component Software
5.1.0 Fix Pack 5
111,380,480
IBM Tivoli Monitoring for Web Infrastructure
650
size (bytes)
1,493,504,052
C54TSML.tar
Tivoli Monitoring for Web
Infrastructure: Install V5.1.2 AIX
HP-UX Linux Solaris Win2000 WinNT
WinXP Int Engl Braz Port French
Italian German Spanish Japan Korea
Simp Chin Trad Chin
401,285,120
C54TTML.tar
Tivoli Monitoring for Web
Infrastructure: Install 2 V5.1.2 AIX
HP-UX Linux Solaris Win2000 WinNT
WinXP Int Engl Braz Port French
Italian German Spanish Japan Korea
Simp Chin Trad Chin
249,835,520
C54TUML.tar
Tivoli Monitoring for Web
Infrastructure: Install 3 V5.1.2 AIX
HP-UX Linux Solaris Win2000 WinNT
WinXP Int Engl Braz Port French
Italian German Spanish Japan Korea
Simp Chin Trad Chin
344,043,520
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
name
title
size (bytes)
C54TVIE.tar
Tivoli Monitoring for Web
Infrastructure: WebSphere
Application Server Component
Software V5.1.2 AIX HP-UX Linux
Solaris Win2000 WinNT WinXP Int
Engl
267,028,480
C54TXIE.zip
Tivoli Monitoring for Web
Infrastructure: Documentation V5.1.2
AIX HP-UX Linux Solaris Win2000
WinNT WinXP Int Engl
187,760,692
5.1.2-WAS-FP02.tar
5.1.2-WAS-FP02 Tivoli Monitoring for
Web Infrastructure: WebSphere
Application
43,550,720
Tivoli Monitoring for Transaction Performance v5.3
3,139,604,480
C8061IE.tar
IBM Tivoli Monitoring for Transaction
Performance, Version 5.3.0: Web
Transaction Performance Component
Software Management Server (1 of 2)
579,205,120
C8062IE.tar
IBM Tivoli Monitoring for Transaction
Performance, Version 5.3.0: Web
Transaction Performance Component
Software Management Server (2 of 2)
363,960,320
C8064IE.tar
IBM Tivoli Monitoring for Transaction
Performance, Version 5.3.0: Web
Transaction Performance Component
Software Management Agent, Store
and Forward
692,951,040
C806AIE.ta
IBM Tivoli Monitoring for Transaction
Performance, Version 5.3.0:
Documentation CD (English only)
UNIX
399,667,200
C806CIE.tar
IBM Tivoli Monitoring for Transaction
Performance, Version 5.3.0: Rational
Robot, Warehouse Enablement Pack,
Tivoli Intelligent Orchestrator, TMTP
5.1 to TMTP 5.3 Upgrade
428,328,960
Appendix B. Obtaining the installation images
651
name
title
C8065IE.tar
IBM Tivoli Monitoring for Transaction
Performance, Version 5.3.0: Web
Transaction Performance Component
Software TMTP 5.2 to TMTP 5.3
Upgrade
675,491,840
DB2 UDB Enterprise Server v8.2
495,104,000
C58S8ML.tar
495,104,000
DB2 UDB Enterprise Server Edition
V8.2 for Linux for Intel 32-bit (English,
French, German, Spanish, Italian,
Brazilian Portuguese, Russian, Polish,
Czech, Japanese, Korean, Simplified
and Traditional Chinese)
IBM HTTP Server V2.0
HTTPServer.linux.2047
.tar b
20,400,000
The installation image for IBM HTTP
Server v2 for Linux can be
downloaded from
http://www-306.ibm.com/software/w
ebservers/httpservers/IHS20.html
WebSphere MQ v5.3
20,400,000
153,434,302
C48UBML.tar.gz
WebSphere MQ v5.3.0.2, Linux for
Intel, Brazilian, Portuguese, French,
German, International English, Italian,
Japanese, Korean, Simplified
Chinese, Spanish, Traditional Chinese
U489967.gskit.tar.gz a
WebSphere MQ for Linux Intel, v5.3
PTF U489967 (CSD06) - with SSL
support
WebSphere Application Server v5.1
652
size (bytes)
136,994,668
16,439,634
1,070,672,037
c53ipml.tar
WebSphere Application Server v5.1
for Linux, (Brazilian Portuguese,
French, German, Italian, Japanese,
Korean, Spanish, US English)
318,648,320
C81E6ML.taz
WebSphere Application Server V5.1.1
for Linux, Fixpack 1, English, Brazilian
Portuguese, French, German, Italian,
Spanish, Japanese, Korean,
Simplified Chinese, Traditional
Chinese
258,967,717
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
name
title
size (bytes)
c53tdml.tar
WebSphere Application Server
Network Deployment V5.1 Edge
Components for LINUX Brazilian
Portuguese, French, German, Italian,
Japanese, Korean, Simplified
Chinese, Spanish, Traditional
Chinese, US English
381,286,400
EdgeCachingProxy511
-Linux.tar c
WebSphere Application Server
Network Deployment V5.1 Edge
Components for LINUX
111,769,600
Total:
47 downloads
15,190,273,975
a. Obtain this fix from the Tivoli support site at: http://www.tivoli.com/support/patches/
b. Obtain this file from: http://www-306.ibm.com/software/webservers/httpservers/IHS20.html.
c. Obtain this fix from the Tivoli support site at:
http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&uid=swg24007420
Appendix B. Obtaining the installation images
653
654
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
C
Appendix C.
Additional material
This redbook refers to additional material that can be downloaded from the
Internet as described below.
Locating the Web material
The Web material associated with this redbook is available in softcopy on the
Internet from the IBM Redbooks Web server. Point your Web browser to:
ftp://www.redbooks.ibm.com/redbooks/SG246468
Alternatively, you can go to the IBM Redbooks Web site at:
ibm.com/redbooks
Select the Additional materials and open the directory that corresponds with
the redbook form number, SG246468.
Using the Web material
The additional Web material that accompanies this redbook includes the
following files:
File name
SG246468.zip
Description
Zipped Code Samples and scripts
© Copyright IBM Corp. 2005. All rights reserved.
655
System requirements for downloading the Web material
The following system configuration is recommended:
Hard disk space:
Operating System:
Processor:
Memory:
10 MB
Windows/UNIX
700 or higher
256 MB or more
How to use the Web material
Create a subdirectory (folder) on your workstation, and unzip the contents of the
Web material zip file into this folder.
Please refer to Appendix A., “Configuration files and scripts” on page 349 for a
detailed description of the content of, and instructions on how to unpack, the
additional material.
656
Implementing a Tivoli Solution for Central Management of Large Distributed Environments
Glossary
authorization role: A role assigned to Tivoli
administrators to enable them to perform their
assigned systems management tasks. A role can be
granted over the entire Tivoli Management Region
(TMR) or over a specific set of resources, such as
those contained in a policy region. Examples of
authorization roles include: super, senior, admin,
and user.
data packet: A data packet is a combination of the
actual data, plus additional information. This
information could consist of the following
information: priority, size, and encryption level.
bulletin board: The primary mechanism by which
the Tivoli Framework and Tivoli applications
communicate with Tivoli administrators. The bulletin
board is represented as an icon on the Tivoli desktop
through which the administrators can access
notices. Tivoli applications use the bulletin board as
an audit trail for important operations that the
administrators perform.
default policy: A set of resource property values
that are assigned to a resource when the resource is
created.
collection: A container that groups objects on a
Tivoli desktop, thus providing the Tivoli administrator
with a single view of related resources. Either the
Tivoli Framework or a Tivoli administrator can create
a collection. The contents of a collection are referred
to as its members. Examples of collections include
the administrator collection, the generic collection,
and the monitoring collection; the administrator
collection is an example of a collection generated by
the Tivoli Framework.
data: A piece of information that needs to be
communicated between the enterprise and the
outlet.
Deployment Request: A request created by the
solution deployer in the enterprise to arrange a
deployment in the outlet.
Downcall: A method invocation from the Tivoli
Management Region (TMR) server or gateway
“down” to an endpoint.
Employee Handhelds: Any handheld wireless
device.
EMR: Enterprise Management Region, the key
enterprise environment within the Outlet Inc.
configuration repository: In the Tivoli
environment, the relational database that contains
information collected or generated by Tivoli
applications. Following are examples of the
information stored in the configuration repository:
Tivoli Inventory stores information concerning
hardware, software, system configuration, and
physical inventory. Tivoli Software Distribution stores
information concerning file package
operations.Tivoli Enterprise Console stores
information concerning events.
© Copyright IBM Corp. 2005. All rights reserved.
657
endpoint : (1) A Tivoli client that is running an
endpoint service (or daemon). Typically, an endpoint
is a machine that is not used to perform daily
management operations. An endpoint
communicates only with its assigned gateway. (2)
Any managed resource that represents the final
destination for a profile distribution. Tivoli Distributed
Monitoring also uses the concept of a proxy
endpoint, which is a representation for a non-Tivoli
entity (such as a network device or a host) that
functions as a subscriber for Tivoli Distributed
Monitoring profiles. A Tivoli administrator associates
each proxy endpoint with a managed node; several
proxy endpoints can be associated with a single
managed node. (3) In the Tivoli environment, a
managed node, PC managed node, or SQL server
on which a task is run.
endpoint client: See endpoint.
endpoint gateway: See gateway.
endpoint list: A list of all endpoints in the Tivoli
Management Region (TMR) and their assigned
gateways. This list is maintained by the endpoint
manager.
endpoint manager: A service on the Tivoli server
that controls and configures gateways and
endpoints, assigns endpoints to gateways, and
maintains the endpoint list.
endpoint method: A method that runs on an
endpoint as the result of a request from other
managed resources in the Tivoli Management
Region (TMR). Results of the method are forwarded
to the gateway and then to the calling managed
resource.
Enterprise Application: An enterprise application
is an application that is installed in the enterprise. Its
design and operation are out of scope for this
solution.
Enterprise: An enterprise (or company) is
comprised of all the establishments that operate
under the ownership or control of a single
organization. For the purposes of this book,
Enterprise refers to a corporation, retailers or banks,
with large numbers of stores or branches throughout
a specific region or the world. Each retail store or
bank branch is referred as an outlet.
event repository: In the Tivoli environment, the
relational database in which TEC stores TEC
events.
fanout: In communications, the process of creating
copies of a distribution to be delivered locally or to be
sent through the network.
gateway method: A method that runs on the
gateway’s proxy managed node on behalf of the
endpoint. Results of the method are forwarded to the
calling m