Chapter 1 Sun Update Connection - Automated Baseline Management Service 1.0 (Overview)

This chapter describes the Sun^SM Update Connection - Automated Baseline Management Service (ABMS) 1.0 service offering that uses the Traffic Light Patch Management (TLP) 2.3 tool. The TLP tool is used to automatically generate patch sets on multiple systems in large data centers. This chapter specifically provides overview information about the TLP 2.3 tool.

This is a list of the overview information in this chapter.

• Where to Find Additional Solaris System Administration and Patch Management Information

• What Is the TLP Tool?

• Advantages of Using the TLP Tool

• TLP Features and Benefits

• TLP Server and Client Software Installation Requirements

• TLP Concepts

• TLP Modules and Roles

• TLP Processes

• TLP Configuration

• TLP Command-Line Functionality

• TLP Reporting

• TLP Logging

For the step-by-step procedures that are associated with installing and using the TLP tool, see Chapter 2, Working With the Sun Update Connection - Automated Baseline Management Service 1.0 (Tasks). For TLP reference information, see Chapter 3, Sun Update Connection - Automated Baseline Management Service 1.0 (Reference).

Detailed information on the recommended patching strategy for the Solaris^TM Operating System (Solaris OS) is not included in this guide. For this information, go to http://docs.sun.com/db/doc/817-0574-12.

This guide is written for experienced engineers and system administrators. This guide neither explains the system administration tools in the Solaris OS, nor the fundamentals of patch management. For additional information on these topics, see Table 1–1.

Where to Find Additional Solaris System Administration and Patch Management Information

What Is the TLP Tool?

TLP is a command-line interface (CLI) tool that enables you to centralize patch set creation on multiple systems in large data centers. The TLP tool enables you to plan patch deployment cycles that fit into your change management policies. The tool also has an HTML interface that provides an overview of the patch status of all your systems. The TLP tool was designed to assist you in performing many of the complex and time-consuming tasks that exist in large data centers. The main focus of TLP is patch set creation for Solaris systems. TLP uses external analyzers to analyze each system. The analyzer tool selects the patches to include in a given patch set, based on the system information that is gathered.

The TLP tool's functionality differs from the Patch Manager software. With Patch Manager, the tasks of patch analysis, the downloading of patches, patch set creation, and patch installation all take place on the target system. With the TLP tool, patch analysis, the downloading of patches, and patch set creation are performed on the server. Patch installation is a separate task that you perform by using scripts that are provided by the TLP tool.

The TLP tool does not install patch sets. Patch set installation is a separate task that you perform after the tool automatically generates the patch sets for your systems.

Advantages of Using the TLP Tool

This section highlights several key advantages of using the TLP tool.

• High level of automation of patch generation is achieved.

• Only necessary patches are generated.

• Reliability of patch sets increases.

• Patch sets are subject to extensive testing.

• An overview of the patch status of the supported systems is provided.

TLP Features and Benefits

This section describes features and benefits of the TLP tool.

• Multiple patch analysis engines

  TLP uses external patch analyzers to recommend patches for a specific system, where the Sun Explorer (Explorer) dump of a system is the input, and the list of recommended patches is the output. Analyzers provide a list of recommended patches as output for further usage by TLP. You can easily exchange one analyzer for another by modifying the default configuration file.

• Automatic downloading of patches from the Internet

  If a patch cannot be located in the TLP patch repository, the TLP tool can download the patch from the SunSolve^SM web site.

• Highly configurable and able to be customized

  The TLP tool uses a default configuration file that you can customize to meet your specific needs. The command line is used to select the additional parameters and the running module. You can also provide command-line arguments that are located in this configuration files as the default values. This capability provides a very flexible framework for complex patch deployment issues that might arise in a large data center.

  ---

  Note –

  This guide does not contain in-depth information on customizing the TLP configuration file. Within this files are instructions for configuring the various TLP parameters. The TLP configuration file is located in the /opt/SUNWtlp/conf/default/tlp.cfg directory. To access this file, you must have installed the TLP software on your system. A copy of the default tlp.cfg file is always available in the default subdirectory for later reference.

  ---

• On-site usage

  The TLP tool is designed to automatically generate patch sets in a multisystem data center. You can choose to run the tool on a regular basis as a cron job. The tool is also able to send diagnostic results of the patch set creation process, per email notifications.

• Generalized phase concept

  The generalized concept for the on-site usage of the TLP tool is called the phase concept. The phase concept enables patch set creation, not only for the most current patches, but also for the patches from a former baseline. This capability minimizes the risk of introducing unknown bad patches to your systems. Each patch phase points to a baseline release. The phases are commonly named GREEN or AMBER, depending on the age of the baseline that was used. Phases are historical snapshots of patches. Within TLP, arbitrary phases and time intervals between phases can easily be defined by modifying the default configuration file.

• Extensible reports

  By default, TLP delivers two kinds of reports:

  • HTML reports

  • ASCII text reports

• Modular and extensible

  The TLP tool's architecture is based on a modular design. Every function of the tool is modeled as an abstract role, which in turn, is implemented by a certain module. Individual modules can be replaced by other modules. The role that is played by the new module must be identical to role of the module it replaces. Module replacement is done by modifying the default configuration file. For example, you could replace the default Analyzer module with another analyzer module that plays the same role. To do so, simply replace the existing information in the default configuration file with the new information. For more information about TLP modules, see TLP Roles and Modules.

• Quality control

  Because the TLP tool does extensive consistency checks on the patch lists that are produced by the analysis tools, it increases the quality of the patch sets that are created by doing the following:

  • Resolving patch dependencies

  • Removing nonapplicable patches

  • Applying whitelists and blacklists that can you can easily customize

  • Checking the WITHDRAWN patches list

• Stand-alone patch sets

  To save disk space, patch sets are symbolically linked directly to the locally installed Sun baselines. With TLP, it is also possible to create stand-alone patch sets that are independent from the locally installed patch repository. This way, you can burn the patch sets to a CD-ROM

• Sophisticated logging

  TLP logging is controlled by a special logging configuration. By default, TLP logs information to a simple text file. Other logging destinations, or an email notification logging method, can easily be configured by modifying the default configuration file. For more information, see TLP Logging.

• Additional commands

  Most TLP modules provide additional commands for enhanced functionality. For a detailed description of the TLP server modules and their functionality, see TLP Command-Line Functionality.

TLP Server and Client Software Installation Requirements

The TLP Tool consists of two software packages:

• Server software package – SUNWtlp-2.3

• Client software package – SUNWtlpc-1.0

The TLP server software is installed on a dedicated system. The TLP client software is installed on all the systems in the data center to be patched. To install the TLP client software, you need approximately 10 Mbytes of disk space. On the TLP client systems no further disk requirements apply.

On the TLP server system you will need to reserve additional space. For each set of baselines that you use, you will need an additional 3 to 4 Gbytes of disk space. The amount of space that is required for each client system can vary between 1 to 5 Mbytes. In rare instances, the amount of disk space that is required could reach 200 Mbytes. Because the created patch sets are built from symbolic links that point to the patch repository, each patch set only requires about 100 Kbytes of disk space.

The TLP tool is a pure Perl application and uses no native code. Because all of the required modules are distributed within the TLP tool, no additional Perl modules are needed. The minimum Perl version that is required to run TLP is 5.005_03. This version is bundled with the Solaris 7 OS.

TLP Concepts

This section describes the main concepts and functionality of the TLP tool.

TLP Definitions

This section defines some of the key terms that are used within TLP.

• Patch repository – Location for all of the patches that are installed on the TLP server.

• Snapshot – A set of patches that are frozen at a given point in time.

• Baseline – A tested set of patches that are frozen at a given point in time.

• Sun Baseline – A baseline that has been tested by Sun.

• Phase – A snapshot that has a color code designation and a name assigned to it.

• System-specific patch sets – A subset of a snapshot that is applicable to a specific system. This subset is also sometimes called an individual patch set or a patch set.

Patch Set Creation

The most important objective of the TLP tool is patch set creation. The tool's job is to create individual patch sets that you can easily install. One of the main components of TLP is its phase concept. A snapshot is a closed set of patches, for example a Sun Baseline or an Enterprise Installation Standards CD-ROM (EIS-CD). The snapshot is tagged with a date by the tool. A snapshot becomes a phase when a color designation and a name is assigned to it. Using historical patches ensures that the patches that are included in the snapshot have matured over time. Withdrawn patches, or bad patches, are regularly checked for and replaced in all of the snapshots. The patch analyzer is responsible for determining the applicable patches for a given system.

Patch Analysis

System analysis engines are used to analyze single system patch requirements. These analyzers gather information about installed and missing patches and provide an exact list of patches that are missing on a given system. All of these patches are applicable to the target system. The TLP tool then compares the output of the analyzer against a given baseline. TLP calculates the gap between both sets to create a system-specific patch set. TLP uses an EIS-CD to define a unique baseline for your data center. The tool takes the output of the selected baseline, and combines it with the patches on the selected baseline, to create a new patch set. You can then efficiently install these patch sets with minimal effort. In mathematical terms, this process is a simple intersection of sets. However, in practice, the process is much more complicated.

You can configure the TLP tool to run with several different external system analyzers. You can also combine two or more analyzers. Because TLP uses analysis engines to create system-specific patch sets, the number of patches that are actually installed are minimized, thus reducing required maintenance window times.

The following are examples of these external analyzers:

• PatchPro

• Sun Checkup

• Griffon

Utilization of EIS-CDs

Utilizing EIS-CDs enables you to bring all of the systems in your data center to a unique patch level, meaning that each system in the data center appears to have been installed with the underlying EIS-CD. Because the patch sets for all of the systems were created with the same baseline, these systems also appear to have gone through installation at the same time.

TLP Modules and Roles

TLP is based on a modular framework. Within the TLP tool, some modules are specific to the TLP server and other modules are specific to the client. This modular framework enables you to replace individual modules, which are independent from each other. You can add new functionality or modify the tool to changing conditions, such as replacing an existing patch analysis tool. You can also define different roles for different tasks. These roles are represented by interchangeable modules. The script that is used to create patch sets refers only to these roles, thereby enabling TLP to conform to changes in its environment. In addition, you can declaratively include new modules in the default configuration file. Existing modules can be used as a basis for the development of new modules. To fully understand TLP functionality, it is essential that you have a basic understanding of the modular architecture of the tool.

The following output shows a portion of the TLP server configuration file. In this example, you can see the association between roles and modules.

<Module sunsolve>
Class  Tlp::Loader::SunSolve	# Perl Module to use
       ....					 # Module specific config
</Module>

Loader sunsolve				 # Associate Module with Role

Note that the role Loader is associated with the module, sunsolve. The module sunsolve is associated with the class Tlp::Loader::SunSolve. If you chose to download patches from another location, you would modify the TLP configuration file, replacing this module with another Loader module.

For more information on the TLP server and client module definitions, see TLP Roles and Modules.

TLP Processes

This section describes TLP concepts and related processes, which include the following cycles:

• Baseline loop (Quarterly)

• Analysis loop (Weekly)

Figure 1–1 describes the TLP cycles and processes. Note that some of these processes are manually performed, while others are automatically or semiautomatically performed. These processes are described in greater detail in the sections that follow.

Figure 1–1 TLP Process Cycles for Patch Set Creation and Installation

The TLP tool's primary function is patch set creation. Although the TLP patch set installation process is included in Figure 1–1, the TLP tool does not provide this functionality. Patch set installation is a separate task that you perform after the tool has created the patch sets.

TLP Baseline Loop

TLP uses the concept of baselines, which are a set of patches and patch revisions that are frozen at a given point in time. This set is tested as a unity and doesn't change after it is released. Baselines enable you to bring all of your systems to the same patch level. The baselines are tested together, thereby reducing the risk of patch incompatibilities. Having all the systems in a large data center at the same patch level makes administration and error detection much easier.

Baselines usually change once per quarter. First, an appropriate baseline is selected. For example, an EIS-CD dated, January 2005 would contain all of the patches that were burned in January of 2005. The baseline is installed once per quarter. When a new baseline is installed, TLP automatically updates the various reports.

TLP Analysis Loop

The analysis Loop is central to the TLP process. It runs for each client system in the data center. After you have installed TLP, you can choose to set up a cron job that starts TLP automatically, once per week. The TLP Client will utilize PatchPro to analyze the target system. The output of all the target systems are collected on the TLP server. The TLP server then compares the output with the installed baseline and creates a patch list. TLP automatically adds or removes patches from whitelist or blacklist configuration files. These files enable you to add or remove patches, if necessary. Whitelist and blacklist files are manually configured. Note that some systems require special patches, such as when an application requirement exists. For more information on maintaining whitelist and blacklist configuration files, see How to Customize Whitelists and Blacklists. In addition, TLP checks the WITHDRAWN patches list and removes any bad patches from the baseline. You can modify this list by using the TLP CLI commands, or by setting up a cron job. You should plan to update the WITHDRAWN patches list on a weekly basis. For more information on working with the WITHDRAWN patches list, see How to Update the WITHDRAWN Patches List.

The TLP tool then takes the resulting list and checks for patch dependencies. If any missing patches are found, the tool attempts to download these patches from the SunSolve web site. Note that Internet connectivity is required to complete this task. In addition, you need a login and password to access the SunSolve web site to download patches.

The new SunSolve web site allows the downloading of patches with arbitrary revision levels, which is contrary to the old method. This capability is necessary for the proper working of the TLP tool.

If no Internet connection exists, you need to manually install any missing patches. After the patch dependencies are resolved, all of the patches are put in the correct order. At this time, the tool removes any patches that cannot be installed automatically. In addition, all firmware and OpenBoot^TM PROM patches that require special treatment are stored in a separate directory for manual installation at a later time. The result is a final patch set that is placed in a dedicated directory. For ease of use, TLP does the following:

• Checks all the patch README files

• Collects all of the special instructions

• Stores the collected information in a single file

• Creates installation scripts

• Automatically updates the HTML and text reports

The last step in this process in the installation of the patch sets. This step is a separate task that you perform after the TLP tool creates the patch sets for your systems. For more information on the patch set installation process, see How to Install a TLP Patch Set.

Deployment Method

To install patch sets, you can choose one of the following installation options:

• Take the system to single-user mode.

• Use Solaris Live Upgrade.

If you use Solaris Live Upgrade, the TLP patch sets fit the selected deployment method. For ease of deployment, TLP provides installation and back-out scripts, along with README files. These README files include additional useful data, such as a collection of special installation instructions. For more information about installing the TLP, software see TLP Software Installation (Task Map).

Sun Update Connection - Automated Baseline Management Service 1.0 Service Offering Activities and Deliverables

The Sun Update Connection - ABMS 1.0 service offering that uses the TLP 2.3 tool is divided into two stages, an initial stage and an ongoing stage. Table 1–2 describes these activities and deliverables.

This guide does not contain information on all of the tasks that are described in the previous table. Information about patch strategy, including the Patch Strategy Checklist, can be found at http://onestop/tlp. Information on Solaris patch management strategy can be found at http://docs.sun.com/db/doc/817-0574-12.

TLP Configuration

TLP configuration is divided into three parts:

• Global configuration

• Default command-line configuration

• Module-specific configuration

For a more detailed explanation of each part, see TLP Configuration Information.

TLP Server Configuration File

TLP obtains its server configuration information from a single file. The name of the default configuration file depends on the TLP script that is running when you call the application. For example, if you call tlp, then the default configuration file that is used is conf/tlp.cfg. If you create a symbolic link, cpc, and point to tlp from this link, the default configuration file that is used is conf/cpc.cfg. With this mechanism, you can easily select different default configurations. Note that you can always override the default configuration by using the command line option, --config. For more information, see TLP Default Command-Line Options and Arguments.

TLP Client Configuration File

TLP obtains its client configuration information from a single file. The name of the default configuration file depends on the TLPC script that is running. For example. if you call tlpc, then the default configuration file that is used is conf/tlpc.cfg. If you create a symbolic link, mytlpc and point to tlpc from this link, the default configuration file that is used is conf/mytlpc.cfg. With this mechanism, you can easily select different default configurations. Note that you can always override the default configuration by using the command line option , --config.

Example 1–1 TLP Server Configuration File

This example shows the beginning portion of the TLP server configuration file. This configuration is also used as the default configuration in the conf/tlp.cfg file.

###################################################################
#
# Configuration file for TLP Patch-Management
# 
###################################################################


# ===================================================================
# Global variables 

# The global variable BaseDirectory is implictly set to the TLP
# installation directory but can be overridden. Please note, that all
# relative pathes given here are relative to the current working
# directory.
# BaseDirectory /opt/SUNWtlp

# You can define you own variables here and refer later to it, e.g if
# you define "DataDirectory  /usr/local/tlp" you can later use it like
# in "SnapshotDirectory $DataDirectory/repository"

DataDirectory $BaseDirectory/data

# Helper-Programs
# Tar /usr/bin/tar
# Uncompress /usr/bin/uncompress
# Gzip /usr/bin/gzip
# Zip /usr/bin/zip
# Bzcat /usr/bin/bzcat
# Pkginfo /usr/bin/pkginfo
# Pkgadd /usr/bin/pkgadd

...

# ===================================================================
# Patch Repository. Only one repository can be used at a time.

<Module repo>
Class Tlp::Repository::DirRepository	  # A file repository

  # Directory holding all snapshots
  SnapshotDirectory  $DataDirectory/repository
  # Directory holding phases
  PhaseDirectory     $DataDirectory/phase
  # Directory holding all Patches
  PatchDirectory     $DataDirectory/patches


  # Phases. The following directives should be given in the order
  # "most current" to "least current" (e.g. Phase "GREEN" before Phase
  # "AMBER") The interval is given in month or day differences to the
  # previous phase
	<Phase GREEN>
		Interval 30 Days
	</Phase>
	<Phase AMBER>
		Interval 3 Months
	</Phase>
</Module>

Repository repo

...

The format of the TLP server and client configuration files is similar to the well-known Apache configuration format. Lines beginning with a hash mark (#) and empty lines are ignored. Spaces at the beginning and the end of a line, as well as tabulators, are also ignored. If you need to include spaces at the end or beginning of a value, you can use double quotation marks. A configuration variable is set by giving its name, followed by an assigned value. An equal sign is optional. Path variables that contain relative paths are resolved relative to the current directory from where you called tlp.

TLP Command-Line Functionality

The TLP 2.3 tool uses the following commands, options, and arguments:

tlp [global options] command [command options] [arguments] 

TLP behavior is steered by commands. These commands determine the mode of operation for the tool. For example, the command, tlp main, is used to generate patch sets. Other commands are used for maintenance or verification purposes. The name of a command reflects the name of the corresponding module, as it is defined in the default configuration file. See TLP Configuration Information. There are two different sets of options:

• Global options – These options influence the overall behavior of TLP and are valid for all commands.

• Command options – These options are specific to the command that is used.

TLP Global Options

The following are the TLP global options:

--conf config, -c config

Provides a configuration file. With this option, you can point TLP to a different configuration file. The default configuration file name depends on the name of the actual script, or the symbolic link that points to this script.

--help, -h

Prints out a help message. Depending on the use of the --verbose option, either the syntax alone or a detailed description is printed out.

--verbose, -v

Prints verbose output. This option influences help messages, as well as the output that is created during a TLP run.

--quiet

Avoids any screen output (Be quiet). This option is especially useful for automated operations, such as in the running of cron jobs.

--version

Prints version information. This option prints the version number of TLP, the version of Perl used, along with the version numbers of all the modules used within TLP, and the Perl module that is used.

TLP Server Command Options

You can obtain a list of all the available TLP commands by typing the following command:

$ tlp -h

The following are the tlp command options and their associated TLP modules:

main (Tlp::Main)

Main module for creating a patch set

dir-producer (Tlp::Producer::DirProducer)

Module for creating a patch set within a directory

patchdiag (Tlp::Resolver::PatchDiag)

Dependency resolver that use the patchdiag.xref file

snapshot (Tlp::Snapshot::Snapshot)

Module for handling snapshots

sunsolve (Tlp::Loader::SunSolve)

Module for downloading a patch by using a URL

repo (Tlp::Repository::DirRepository)

Module for handling snapshots stored in a directory

explorer (Tlp::Collector::Explorer)

This module is used for maintenance of Explorer dumps.

These TLP module options are module-specific and vary from module to module. To obtain the options for a specific command, use the following command:

$ tlp -h command

Or, you can use this command:

$ tlp -v -h command

where command is the name of the module, for example, main.

TLP Reporting

Every time you create a patch set, the TLP tool automatically generates a report in two formats, HTML and ASCII text. These reports are stored in a directory for later retrieval and interpretation. Generation of the HTML report is completed within a few seconds. These reports contain essentially the same information. However, the HTML report is easier to interpret.

Detailed information about the text report that is automatically generated is not included in this guide.

The tool reports the patch status for each system in the data center in the form of a dashboard. For each phase, a color is designated. This color designation is determined by the default configuration file. The following default color designations are used:

• GREEN – This phase is defined to be at least 30 days old.

• AMBER – This phase is defined to be at least 60 days old.

Any system that is not compliant with a given phase is displayed in the HTML report with a RED color designation.

These color designations are based on how much the system's patches differ from the current patch baseline. The local patch database is updated at agreed-upon intervals, which in turn initiates the analysis process and the patch set creation. These patch sets are installed at the appropriate time, typically during a maintenance window.

TLP Logging

The default configuration file for logging is conf/log.cfg. This file contains some examples for fine-tuning TLP logging. By default, errors are logged into the log/tlp.log file and rotated when 1 Mbyte of logging data has been recorded. Up to three backup logs are kept. With TLP logging, you can do the following:

• Switch on debugging.

• Send logs per email.

• Record logging in databases.

See the examples in log.cfg for additional ideas. A detailed description of all the logging features is not within the scope of this document.