HP Dynamic Root Disk White Paper

DRD-Safe Concepts for HP-UX 11i v2 and Later

1 Introduction...................................................................................................................................... 2

1.1 Abstract .................................................................................................................................... 2

1.2 Purpose of Document.................................................................................................................. 3

1.3 Audience .................................................................................................................................. 3

1.4 Release Information.................................................................................................................... 3

1.5 Terms and Definitions ................................................................................................................. 3

2 What must be DRD-Safe?................................................................................................................... 6

3 DRD-Safe Problem Areas ................................................................................................................... 7

3.1 Process Communications............................................................................................................. 7

3.2 Unterminated Process ................................................................................................................. 9

3.4 Firmware Patches and Other Unsafe Packages ............................................................................ 10

4 Making Control Scripts and Commands DRD-Safe .............................................................................. 11

4.1 Control Scripts Stopping, Starting or Restarting Processes/Daemons .............................................. 11

4.2 Commands that Communicate with Other Processes..................................................................... 12

4.4 Unsafe Logic in an Unconfigure Script ........................................................................................ 13

4.3 Logic to Support NFS Diskless may not be DRD-safe ..................................................................... 16

5 Making Control Script Invocations of swremove DRD-Safe ................................................................... 17

5.1 How to Make Packages DRD-Safe for swremove .......................................................................... 17

6 DRD-Safe Packaging Changes.......................................................................................................... 19

6.1 The is_drd_safe Attribute........................................................................................................... 19

7 Making Special Installation Instructions DRD-Safe ............................................................................... 21

Appendix A ...................................................................................................................................... 22

A.1 HP-UX 11i v2 control_utils......................................................................................................... 22

A.2 HP-UX 11i v2 Commands ......................................................................................................... 23

1 Introduction

1.1 Abstract

System administrators often want to upgrade software and apply patches to their HP-UX systems in as short a maintenance window as possible. In addition, they also need a quick and reliable way to return to the pre-updated system in the event that the modifications do not work as expected.

The Dynamic Root Disk (DRD) utilities create and manage the inactive copy of the HP-UX operating system (or inactive system image). Utilization of DRD allows for the installation of patches and products to the inactive system image while the booted system image continues to run.

Note:

The installation of HP-UX that is currently in use is known as the booted system image. The booted system image includes all aspects of the HP-UX installation, including the file system layout, kernel definition, configuration information, installed software, processes, memory layout, and daemons servicing the system.

The other installation of HP-UX that is not currently in use is known as the inactive system image. Because the inactive system image is not running, processes, memory layout, and daemons are not part of it. However, the inactive system image does include the file system layout, kernel definition, installed software, configuration information, and all other parts of the operating system that persist across boots of the system.

A system administrator can reduce a maintenance window by applying patches and software updates to the inactive system image that has been produced as a clone of the booted system image. Because the booted system image remains unchanged, this use model is known as hot maintenance When the software changes have been successfully applied, the system administrator boots the inactive system image, making it the booted system image. The interruption to application availability is thus reduced to the time needed to boot the system, rather than the entire period needed to upgrade the software.

In addition, if a (newly) booted system image has a problem with disk hardware or an incompatibility in installed software, the system administrator can resolve the issue by booting the inactive system image, making it the booted system image. This use model is known as hot recovery eliminates the need for a time-consuming restore from a tape or network backup.

The core functionality in the DRD utilities is the ability to modify the inactive system image while the booted system image is active, yet keep the changes isolated to the inactive system image. There are three basic methods that are all employed to ensure the inactive system is isolated:

• drd runcmd – With drd runcmd, DRD runs a command in a special modification

environment. This environment is called the runcmd environment. The runcmd tool uses chroot(1M) to create an environment where it runs software management commands such as

Hot recovery

swinstall and swremove. Using chroot prevents modification of files on the booted system image. Such use of chroot is sometimes known as a chroot jail.

• SW_SESSION_IS_DRD – drd runcmd sets the environment variable

SW_SESSION_IS_DRD to 1 when it is executed. Packaging control scripts can use this

variable to check for the presence of a runcmd environment.

• Packaging – Restrictions on software packages are needed to ensure that the booted system

image is not modified. A software package that conforms to these restrictions is known as

DRD-safe

The remainder of this document describes what it means to be DRD-safe and how to create DRD-safe packages.

1.2 Purpose of Document

After reading this document, the reader should be able to accomplish both of the following:

• Identify unsafe logic in a software package or application and implement appropriate

revisions to make the package or application DRD-safe

• Create DRD-safe packaging

1.3 Audience

This document is intended to be used by software packagers and software developers as a source of information about DRD-safe issues and guidelines.

1.4 Release Information

The DRD utilities are supported on both HP-UX 11i v2 and 11i v3. For 11i v2, HP-created patches are required to be DRD-safe. Non-patch products and filesets for 11i v2 can be DRD-safe, but they are not required to be DRD-safe. All HP-created 11i v3 and later packages (patches and products) are required to be DRD-safe.

1.5 Terms and Definitions

Term Definition

booted system environment

CLI clone

cloned system image

The system environment that is currently running, also known as the current, active, or running system environment

Command line user interface

• (noun) clone – a system image clone

• (verb) clone – to clone a system image

A copy of the critical file systems from the system image of a booted system image, produced by the drd clone command.

A cloned system image may be inactive, or the cloned system image may be booted, in which case the system activities are started and the clone becomes the system image in the booted system image. When a particular system image is booted, all other system images are inactive.

control scripts

A system administrator may modify a cloned system image by installing software on it using the drd runcmd command

Shell scripts provided with software packages that are used to customize the install or other software management operation

critical file systems The subset of file systems in a system image that will be cloned during a drd

DRD

clone operation Currently, the critical file systems are those in the LVM volume group or VxVM

disk group containing the root (“/”) file system Dynamic Root Disk. The collection of utilities that manages creation, modification,

and booting of system images

DRD-safe

hot maintenance

hot recovery inactive system image IPD

Refers to software packages for HP-UX, as well as to HP-UX commands A package is DRD-safe if it can be swinstalled, swremoved, and swverified on the

inactive system image without modifying any part of the booted system image. There is no requirement that the package can be configured (using swconfig) on

the inactive system image installed on the inactive system image and the inactive system image is subsequently

booted, or when it is installed directly to a booted system image Examples of components of the booted system image that cannot be changed are the

installed software, file systems, device configuration, proce ss space, ker nel definition, networking configuration, users and passwords, and auditing and

security A command is DRD-safe if it can be run in the runcmd environment without

modifying any part of the booted system image. The ability to perform modifications to the inactive system image, using commands

issued on the booted system image, without affecting the booted system image See recovery A system image that is not the booted system image. This system image can be

modified while the booted system image remains in production Installed Product Database. This is the database used by software management tools

to keep track of what is installed on a system and information about the installed software state

. The package should be fully functional, either when it is

LVM

original system environment

PSF

recovery

restore root file system The file system that is mounted at /.

runcmd environment

shared file systems The subset of file systems in a system image that will NOT be cloned during a drd

Logical Volume Manager. The logical volume manager (LVM), a subsystem that manages disk space, is supplied at no charge with HP-UX

Operating Environments are tested and integrated application bundles designed to work with the operating system and provide the functionality needed for your system’s purpose.

A booted system image whose system image is cloned to create another system image. Each system image has exactly one original system environment (that is, the

booted system image at the time the drd clone command was issued) Product Specification File. A file created to define a software package created with

HP Software Distributor (SD) The ability to boot the inactive system image in the event of critical system

problems. Also referred to as system recovery or hot recovery The ability to retrieve user data that was previously archived

The environment provided by drd runcmd to isolate changes to the inactive system image.

clone operation, but will be mounted when the clone is booted

system activities

All of the running processes that correspond to programs on a booted system. This includes the running kernel, all network processes, all daemons, and all other

processes—both system and user System activities frequently access in-memory copies of data. Thus, any change to

in-memory data may affect system activities

system environment

system image

system recovery VxVM

The combination of the system image and the system activities that comprise a running installation of HP-UX

The file systems and their contents that comprise an installation of HP-UX, residing on disk, and therefore persisting across reboots

See recovery Veritas Volume Manager

2 What must be DRD-Safe?

System administrators execute the drd runcmd command to install, remove, modify, and verify software on the inactive system image. The following entities must be DRD-Safe:

• The software deployment commands:

o swinstall o swremove o swmodify o swlist

o swverify (without -F and -x fix=true options

• The control scripts for the software being installed, removed, or verified. Note that the

configure script is not in this list. It does not need to be DRD-safe because it runs after the inactive system image is booted:

o checkinstall o preinstall o postinstall o checkremove o preremove o postremove o unconfigure o verify

• The commands and control_utils invoked (directly or indirectly) as part of control script

execution within the runcmd environment

• The OE update scripts (HP-UX 11i v3 and later operating systems)

o update_prep o pre_update

Note:

The minimal release, or a subsequent release, of HP Software Distributor (SD) that is required to install the DRD

DynRootDisk software product, provides swinstall, swlist, swmodify, swremove, and swverify

commands that are DRD-safe. The minimal release of SD required for DRD can be found on the

Note:

Though the update utilities support update paths from HP-UX 11i v1 to 11i v2 and from HP-UX 11i v2 to 11i v3, these OE updates are not supported using DRD.

To be DRD-safe, one basic guideline must be followed:

DRD home page.

All commands run in the runcmd environment must only access or modify the inactive system image and not access or modify the booted system image

3 DRD-Safe Problem Areas

Before discussing the details of how to create DRD-safe scripts and how to identify DRD-unsafe commands in current scripts, we will take a look at the activities that are not DRD-safe and thus must not take place in a DRD session. After we have described what types of activities are DRD-unsafe, we will then move on to describing how to create control scripts and packages that avoid these activities and are DRD-safe.

3.1 Process Communications

When running in the runcmd environment, commands can be executed that modify the inactive system image. These commands can communicate with other processes that may not have been started within the runcmd environment. These other processes may illegally change the booted system image, or may provide information that is correct for the booted system image, but incorrect for the inactive system image.

Following are three examples of unsafe actions related to process communications.

Example 3.1.1 – Illegal Kill: A command executed within the runcmd environment terminates a process that was started outside of the runcmd environment. This is unsafe because the running system expects the process to be running and could be actively communicating with that process.

Example 3.1.2 – Illegal Request: A command executed within the runcmd environment communicates with a daemon started outside of the runcmd environment. For example, assume a daemon is started before the runcmd environment. When the daemon was started, it read information from a configuration file on the booted system image. When a process starts in the runcmd environment and asks for data from the daemon, the data returned is for the booted system image and not for the inactive system image. The inactive system image may have a different configuration and the information retrieved from the daemon may be incorrect.

Note:

The minimal release of HP Software Distributor (SD) that is required to install the DRD DynRootDisk software product prevents inappropriate communication between an SD daemon started during a drd runcmd execution and an SD daemon started outside of a drd runcmd command

The minimal release of SD required for DRD can be found on the

DRD home page.

Example 3.1.3 – Illegal Restart: A command executed within the runcmd environment restarts a daemon that was originally started outside of the runcmd environment. Not only does it terminate an existing daemon that may be in use by the booted system image, but it also starts a new daemon that is based on the inactive system image and not the booted system image. Because the new daemon is started by a command inside the runcmd environment, the daemon that is started is the version of the daemon on the inactive system image. This version of the daemon may not be compatible with the booted system image. Even if the versions are compatible, any file access from the daemon would be performed against the inactive system image, and not the booted system image image, and the

+ 17 hidden pages