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

OE

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

information may not be invalid. Additionally, after the user exits the runcmd environment, the process
becomes an unterminated process. (See

3.2 Unterminated Process for more details.)

3.2 Unterminated Process

A process that is started in the runcmd environment and remains active after drd runcmd completes
is not DRD-safe because it is using data from the inactive system image, but is now running in the
booted system image. Processes that are not associated with a user terminal (for example, tty), such
as a daemon that is started in a control script from within the runcmd environment, will remain active
even after the user exits the runcmd environment. The unmount of the inactive system image at the
end of drd runcmd processing—or in response to any subsequent drd unmount command—will
fail because the process is still running, making the root file system of the inactive system image busy.

The following example is an illustration of an unsafe action related to an unterminated process.

Example 3.2.1 – Illegal Persistence: A process started in the runcmd environment continues to
execute after the shell exits. Upon request from a process started in the booted system image, the
persistent process will return information from the inactive system image. For example, if the inactive
system image is running version 2 of a software application and the booted system image is running
version 1, the persistent process will respond on the running system with version 2 information.

In addition, the persistent process will have an open file reference to the program it is running,
causing an unmount of the inactive system image to fail.

3.4 Firmware Patches and Other Unsafe Packages

A firmware patch affects both the inactive system image and the booted system image, and as a
result, it is not considered DRD-safe. All firmware patches should exclude themselves from being
installed or removed from within a runcmd environment. This can be accomplished by setting the
is_drd_safe attribute to false for all of its filesets or by adding the following logic to the fileset
level checkinstall and checkremove scripts:

#
# Check if running in runcmd environment and exclude if
# so because firmware patch cannot be applied within runcmd
# environment.
#

if [[ $SW_SESSION_IS_DRD -eq 1 ]]
then

msg NOTE “${PRODUCT}.${FILESET} cannot be installed in a DRD

session.”
exit $EXCLUDE
fi

Note that if software is safe to be installed in a DRD environment, but is not safe to be removed, then
is_drd_safe can be set to true and the above method used in the checkremove script.

4 Making Control Scripts and Commands DRD-Safe

This chapter describes the type of logic a packager or developer should look for to determine if a
given control script or command is DRD-safe. For each of the following descriptions (sections), a set
of examples and suggestions on how to make the control script or commands DRD-safe are provided.

Note:

Control scripts and commands are executing in a runcmd
environment if the SW_SESSION_IS_DRD environment
variable is set to 1

4.1 Control Scripts Stopping, Starting or Restarting Processes/Daemons

Control scripts stopping, starting or restarting processes/daemons—any use of kill, init script,
or invocation of any command that accepts a parameter of start, stop, or restart—are suspect.
While the use of kill_named_procs is safe, its behavior in a runcmd environment is different (see
A.1 HP-UX 11i v2 control_utils).

Unsafe Examples:

• kill -9 $PID

• /sbin/init.d/comsec start

• vxdctl stop >/dev/null 2>&1

• init q

• inetd -c

Suggested Resolutions:
Follow the steps below to make the logic DRD-safe:

1. If the logic is in a configure control script, no action is required. There are no DRD

restrictions on configure scripts, which are executed during the boot of the system image
rather than in the runcmd environment.

2. If the logic is part of a control script and is stopping a process, use the control_util

kill_named_procs to stop the process because that control utility is DRD-safe. (That is, if
running in a runcmd environment, it does not kill the process.)

3. If the logic is in a checkinstall, preinstall, or postinstall control script, and it

can be moved to the configure script, move it to the configure script.

4. If none of the above solutions fit the situation, detect that the command is running in a runcmd

environment using the SW_SESSION_IS_DRD environment variable, and change the logic to
be DRD-safe. In many cases this may mean skipping the stopping, starting, or restarting of
the process/daemon: When the files on the inactive system image are being updated, the
daemon running from the original system does not need to be stopped and restarted. Though
this is a likely solution, the packager must make the assessment of whether it will work for a
particular package.

Safe Examples:

• [[ $SW_SESSION_IS_DRD != 1 ]] && kill -9 $PID

• if [[ $SW_SESSION_IS_UPDATE -ne 1 && $SW_SESSION_IS_DRD –ne 1 ]]

then
/sbin/init.d/comsec start
fi

.

• if [[ $SW_SESSION_IS_UPDATE -ne 1 && $SW_SESSION_IS_DRD -ne 1 ]]

then
vxdctl stop >/dev/null 2>&1
fi

• kill_named_procs wlmcomd SIGTERM > /dev/null 2>&1

4.2 Commands that Communicate with Other Processes

Look for commands that communicate with other process—for example, communications through
sockets, RPC calls, or named pipes.

Unsafe Examples:

• vxdg bootdg

The vxdg command attempts to contact the vxconfigd daemon, which was
started on the booted system.

Suggested Resolutions:
Follow the steps below to make the logic DRD-safe:

1. First, determine if the communication is DRD-safe (or not):
a. If the communication occurs with a process started within the runcmd environment,

the communication is DRD-safe and no action is needed. A process has been started
within the runcmd environment if the environment variable SW_SESSION_IS_DRD is
set to 1 inside that process.

b. If the communication occurs with a process on a different system (that is, remote

communication), the communication is DRD-safe and no action is needed. Remote
communication is considered safe because the information obtained from a remote
system is unlikely to differ based on whether it was obtained on behalf of the booted
system image or the inactive system image.

c. If the communication occurs with a process started outside of the runcmd

environment, the communication may not be DRD-safe. Whether or not the
communication is DRD-safe depends on the results of the communication. For
example, if the communication is just to establish if a process is currently running, the
result is DRD-safe. If the communication is to retrieve information from the running
process and that information is not relevant to the inactive system image, the result is
not DRD-safe. The owner of the logic must examine the information returned and
how it is used to determine if the result will adversely affect the inactive system
image. While making this examination, it is important to remember that the inactive
system image could have an entirely different software configuration than the booted
system image. If the logic is not safe, it may be necessary to detect that this is a
runcmd environment (that is, SW_SESSION_IS_DRD=1), and modify the logic to
retrieve the information from the inactive system image instead of the running system
image.

2. If the logic is unsafe, use the SW_SESSION_IS_DRD environment variable to determine that

the command is executing in a runcmd environment and either skip the unsafe logic or re­write the logic in a safe manner. For example, a command may have a “DRD mode” that
can be activated by a command-line option. In this case, the unsafe logic could be modified
to detect the runcmd environment and add the “DRD mode” option to the command line, thus
making the execution of the command DRD-safe.

Safe Examples:

• lvlnboot –v

The lvlnboot command uses files on the inactive image.

• cat /etc/fstab | grep -e vxfs -e hfs | grep " / " | \

grep "/dev/vx/dsk" | awk '{FS="/"; print $5}'

The preceding command can be used to determine if the system is
installed on a VxVM disk group. The command looks for a file system
mounted at “/”, checks for a prefix indicating VxVM, then uses awk
to parse out the group name.

4.4 Unsafe Logic in an Unconfigure Script

The unconfigure script is meant to reverse the steps performed by the configure script.
However, though configure scripts have no DRD restrictions, unconfigure scripts, which run in
the runcmd environment, are restricted to use DRD-safe logic. Unsafe logic in an unconfigure
script must be modified to be safe (see examples above). If the logic cannot be made safe, it may be
necessary to move the logic to a preremove script and provide a checkremove script that returns
EXCLUDE when SW_SESSION_IS_DRD is set to 1.

During a drd runcmd swinstall operation, the configure script packaged with a fileset or
product is run when the inactive system image is booted. Therefore, packagers can often put any
control script code that is not DRD-compliant (DRD-safe), but must be run when the package is
installed, into the configure script.

For example, creation of device files is often done in a configure script. This is because extracting
the device driver’s major number must be extracted from the kernel of the system image where the
device file is used.

all

In contrast, when drd runcmd swremove is executed,
are run before the inactive image is booted. A mechanism is needed for executing control script code
that is not DRD-compliant (DRD-safe), but is necessary for complete removal of the software.

Unsafe Examples:

• /sbin/init.d/comsec stop

• setup_tftp -d dirname

Suggested Resolution:

The mechanism that HP recommends is the creation of an rc script, usually run as S900 that will run
once when the inactive image is booted, and then remove itself. This method is used by the Ignite-
UX.BOOT-SERVICES fileset. In non-DRD environments, this fileset’s unconfigure script runs the
command:

setup_tftp –d _directory_name

This command communicates with the tfptd service to remove certain Ignite directories from tftp
access. This command cannot be run in a DRD session, because it would communicate with the
daemon running on the booted system, thus removing tftp access to directories on the booted rather
than inactive system image.

remove control scripts in the package

However, the directories on the inactive system image must be removed from tftp access the next
time the image it booted. To accomplish this, the unconfigure script takes the following steps
when running in a DRD session:

1. Create an rc script in sbin/init.d and an S900* symlink to the script

2. Include the setup_tftp call in the script

3. Include code in the script to remove itself as well as the S900 link before exiting

The actual code used by the Ignite unconfigure script is shown in text box below.

#
# Remove the Ignite entries
#
if [[ $SW_SESSION_IS_DRD -ne 1 ]]; then

for dir in $INST_DIR $VAR_DIR
do
setup_tftp -d $dir
done

#
# Issue a message that the Ignite directories have been
# removed from tftp access, but that the tftp service itself is
# still enabled.
# This was changed for JAGad47307.
#

echo "\
NOTE: tftp access to $INST_DIR and $VAR_DIR has been
removed from /etc/inetd.conf. The tftp service is
still enabled. To disable tftp service, run SAM."

else

echo "\
NOTE: tftp access to $INST_DIR and $VAR_DIR will be
removed from /etc/inetd.conf when the inactive
image is booted. The tftp service will remain
enabled. To disable tftp service, run SAM."

initfile=/sbin/init.d/iux_unconf
rcfile=/sbin/rc2.d/S900iux_unconf
rm -rf $rcfile $initfile

print "#!/sbin/sh" > $initfile
print " for dir in $INST_DIR $VAR_DIR" >> $initfile
print " do" >> $initfile
print " /usr/sbin/setup_tftp -d \$dir" >> $initfile
print " done" >> $initfile
print " rm $initfile $rcfile " >> $initfile
print " exit \$? " >> $initfile

chmod 555 $initfile
chown bin:bin $initfile
ln -s $initfile $rcfile
fi

An additional step is needed to address the following scenario: A system administrator may use DRD
to remove a product or fileset from the inactive system image and then use DRD to install (the same or
a different version of) the product or fileset to the inactive system image. Both operations may be
done without an intervening reboot.

In the case described above, an install control script must remove the rc script and the S900
symlink that were deployed by the remove script. The Ignite product uses a product preinstall
script for this purpose, but a BOOT-SERVICES control script could easily have been used. Note that
this code need not be conditional on running in a DRD session. The file system changes will be on the
inactive system image if the install is running in a DRD session. However, there is no harm in
removing them from the booted system in the unlikely event that they are found in a non-DRD
installation.

The code used by the Ignite preinstall script is shown below.

#
# Clean up DRD-safety files that may have been left by unconfigure
# when a swremove of Ignite was done to a DRD clone, then swinstall
# Ignite was performed before the DRD was rebooted. These files
# are defined in the BOOT-SERVICES unconfigure script.
#

initfile=/sbin/init.d/iux_unconf
rcfile=/sbin/rc2.d/S900iux_unconf
rm -rf $rcfile $initfile

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

While logic to support NFS diskless is obsolete and should be removed from the control script, the
presence of such logic (that is, check for SW_DEFFERRED_KERNBLD) is a good indication of logic
that may not be DRD-safe and should be examined closely to determine if it is safe or not.

5 Making Control Script Invocations of swremove DRD-Safe

This chapter describes how to safely invoke swremove in a control script. This assumes that
swremove has been determined to be the best way to remove the desired files and update the IPD.

Invoking swremove in a control script is often done in new software to obsolete old software.

5.1 How to Make Packages DRD-Safe for swremove

If either of the following is true, the invocation of swremove in your control script is already DRD­safe:

1. If the software being removed does not have any remove control scripts (checkremove,

preremove, postremove, or unconfigure), and updates are only delivered as new
revisions (no current patches and no chance that it will have patches), then the use of
swremove on that software is DRD-safe.

2. If the software being removed has the is_drd_safe attribute set, it is safe to swremove

that software (from a DRD perspective). All HP-provided software for HP-UX 11i v3 and later
is required to be DRD-safe and have the is_drd_safe attribute set.

If the software being removed is not DRD-safe, one of the following solutions should be used to make
its removal DRD-safe, while keeping it update safe.

Solution 1:
Put the swremove invocation in the update_prep control script. New for HP-UX 11i v3 is the
ability to deliver the update_prep script with an SD-product package (as a control_file specified in
the PSF).
Cautions:

• A swremove in an update_prep script will only get executed during an OE update.

Therefore, software not included in OEs should not use this method.

• A swremove in an update_prep script will remove the software so that it is not there

during the update operation.

When to Use this Solution:
This solution is useful for:

• OE software.

• When removing HP-UX 11i v1 and/or HP-UX 11i v2 software.

• When the software does not need to be there during the OE update operation.

Solution 2:
Put the invocation of the swremove command in a preinstall control script and include: –x
run_scripts = false. This will avoid running control scripts that may not be DRD-safe.
Cautions:
No swremove control scripts will execute, so logic that is required for the removal of the software
needs to be duplicated in the install

When to use this solution:

This can be used for products not included in an OE that need to remove software:

• And the software being removed has no logic required for the removal

• Or the logic can be put in the preinstall from which the swremove is invoked.

Note that products not in an OE are usually updated by using swinstall rather than update_ux.

control scripts invoking the swremove command.

Solution 3:
The invocation of swremove can be moved to the configure script.
Cautions:

• This only works when there are no files in the swremoved software that are replaced by new

software. If any of the files are overwritten by new software, new files would get removed
during execution of the configure scripts.

• If the product being removed has startup scripts, these also get executed on the reboot.

Timing of the remove versus the startup is uncertain.

When to use this solution:

• This solution can be used for products not included in an OE that need to remove software

that has no startup scripts and no files delivered by a new product.

6 DRD-Safe Packaging Changes

6.1 The is_drd_safe Attribute

The is_drd_safe fileset attribute is introduced in HP-UX 11i v2.

Attribute: fileset.is_drd_safe

• Status: For HP-created HP-UX software—optional for HP-UX 11i v2, required for 11i v3

• Description: Indicates that the fileset can be managed (installed, removed, verified and

unconfigured) in a runcmd environment without affecting the running system environment; defaults
to false (except for HP-UX 11i v2 patches as explained in the table below). A fileset can only
be considered DRD-safe if both the fileset and product control scripts are DRD-safe. If a product
level control script is not DRD-safe, all of the filesets for that product must be listed as unsafe (that
is, the is_drd_safe attribute for each fileset in the product is set to false). If any fileset is
selected for management (install, remove, verify, or unconfigure) and that fileset does not have
is_drd_safe set to true, that fileset will be excluded from the list of software to be managed
in a runcmd environment. This includes any filesets selected due to dependencies.

• Values:

o false: The fileset cannot be managed safely in a runcmd environment.
o true: The fileset can be managed safely in a runcmd environment.

To be safely managed in a runcmd environment, the fileset should adhere to the
guidelines in the other sections of this document.

• Policy:

General policy: Though it is possible for different filesets within a product to have different

is_drd_safe values, this should not be done. (For example, one fileset has true and another
has false.) Doing this reduces the overall usefulness of DRD and can create problems for the
system administrator. Therefore, as a DRD policy, all filesets within a product should have the
same value (true or false) for the is_drd_safe attribute.

is_drd_safe Attribute Policy

Release Package

Policy

Type

11i v2 Patches

Attribute does not need to be set for 11i v2 patches.

Though all new HP-UX 11i v2 patches (that is, patches created
after November 1, 2004) must be DRD-safe, they are not required
to set the is_drd_safe attribute. All existing patches have
been checked and all but a small subset have been verified to be
safe. The small subset of unsafe patches will be handled
internally. As a result, even though the patches will not have the
attribute set, they will be assumed to be safe (that is, the attribute
defaults to true for 11i v2 patches). All other packages have a
default of false. This difference in behavior for 11i v2 patches
has been introduced to allow existing 11i v2 patches (most of
which are safe) to be installed in a runcmd environment without
requiring the patches to be superseded just to set the attribute.

11i v2 Products If a product (non-patch) has been validated to be DRD-safe, the

is_drd_safe attribute should be set to true for all filesets
within the product; otherwise, it should not be set for any of the
filesets.

11i v3

(and

All
packages

Required to be true for almost all HP-created software—patches,
OE contents, and all other software. Exceptions are firmware
patches and a few OpenView products.

later)

7 Making Special Installation Instructions DRD-Safe

When installing patches during a DRD session, the user MUST not stop/kill or restart processes, and
should only make kernel tunable changes using drd runcmd kctune. If you have included Special
Installation Instructions with your patch that instructs the user to do either of these things, please
include the following text at the top of your Special Installation Instructions:

If you are installing this patch on the inactive DRD system image:

• You need not and MUST not stop/kill or restart any processes or

daemons. Because the patch is being installed on a DRD clone, these
actions are not needed, and in fact could leave the running system in an
undesirable state. When the DRD clone is booted, all processes will be
stopped and restarted.

• Only make kernel tunable changes by running drd runcmd kctune.

You can find additional information regarding DRD-safe packaging on the DRD Safe Packaging Web
page:

http://swupport.fc.hp.com/drd/

Appendix A

A.1 HP-UX 11i v2 control_utils

The table below describes the SD control_utils, whether they are DRD-safe or not, and any special
information related to DRD that might be of interest to packagers.

DRD-Safe SD control_utils

Function name DRD-

safe

check_SD_revision

chmog
clean_swlist_output
cond_cp
cond_cp_set
cond_mkdir
cp_retain
cp_set
cu_html
cu_hw_scan
cu_man
cu_obsolete_ancestors
cu_run_cmd
cu_uniq
cu_usage
export_master
find_ancestor
get product_name
get_arch
get_fileset_name
get_install_state
get_kernel_path
get_os_rev
get_owner_group
get_sw_rev
get_sw_spec
get_version
Increase_tunable
IPD_addBundleWrapper
IPD_addfile
IPD_delBundleWrapper
IPD_delete_ancestors
IPD_delfile
is_number
is_software_selected
kill_named_procs

Yes This function was written specifically for use by OS-

Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­N/A Defunct for 11i v2 and above
Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­Yes --
Yes -­Yes -­Yes -­Yes -­Yes
Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­Yes When kill_named_procs is run during a drd

Comments

Core.UX-CORE. Other packages should not be
using this function.

--

runcmd execution, it returns 0 without killing any
processes. Packagers need to examine control
scripts calling kill_named_procs () to determine
if not terminating the process requires additional

script changes for proper functioning during a drd

runcmd execution.

mod_pathfile
mod_systemfile
msg

msg79 Yes --

newconfig_cp
newconfig_msgs
newconfig_prep
patch_newconfig_cp
patch_newconfig_rollback
patch_newconfig_rollcheck
patch_newconfig_rollsave
patch_newconfig_save
query_systemfile

r_mkdir
strip_off_fr

Yes -­Yes -­Yes --

Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­Yes The kc* commands called by query_systemfile are

aware of running during a drd runcmd execution
Yes -­Yes --

A.2 HP-UX 11i v2 Commands

The commands used in a control script when SW_SESSION_IS_DRD is set to 1 are limited by the
need to be DRD-safe as well as the need to be acceptable for control script use. During a DRD
session, restrictions apply to all control scripts except the configure script. This imposes an
additional restriction on checkinstall, checkremove, preremove, postremove, and
unconfigure scripts, which are less severely restricted during an install to a booted system image.

The following commands may be used in control scripts when SW_SESSION_IS_DRD is set to 1:

• Commands that are part of the POSIX shell, which can be found in the sh-posix(1) man page,

EXCEPT FOR kill
the runcmd environment. Using kill on processes started outside of the runcmd
environment is not DRD-safe.

• Functions in /usr/lbin/sw/control_utils that are listed as DRD-safe in

control_utils

Commands that are DRD-safe are listed in the table below.

DRD-Safe Commands

Command DRD-safe Comments

awk
cat
chgrp
chmod
chown
ch_rc
cmp
cp
efi_cp

.

,

which should only be used to modify processes started within

A.1 HP-UX 11i v2

Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­Yes -­Yes The

efi_cp command itself is DRD-safe, however this

command is often used in conjunction with other logic
that is not DRD-safe. As such, any control script that

efi_ls

grep
ioscan

kill

lifcp

lifls

ln
ls
lvlnboot
mkboot

mkdir
mknod
mount

mv
nettlconf
ps

contains this command needs closer examination to
determine if the other logic is DRD-safe.

Yes The

Yes --

Varies The ioscan –M command is not DRD-safe.

Yes* The kill command should only be used to modify

Yes* The

Yes* The

Yes -­Yes -­Yes -­Yes* The mkboot command itself is DRD-safe, however this

Yes -­Yes -­Yes Although mount is DRD-safe, it should not be used in SD

Yes -­Yes
Yes* The ps command itself is DRD-safe; however, the use of

efi_ls command itself is DRD-safe, however this

command is often used in conjunction with other logic
that is not DRD-safe. As such, any control script that
contains this command needs closer examination to
determine if the other logic is DRD-safe.

Further, any use of ioscan to determine kernel
information is not DRD-safe. For example,
looking at the “CLAIMED” field or the name of
the driver that claims the device provides
information about the running kernel, NOT the
kernel that will be built on the inactive system
image.
Similarly, any use of the control_util

cu_hw_scan to determine kernel information is

not DRD-safe.

processes started within the runcmd environment. Using

kill on processes started outside of the runcmd
environment is not DRD-safe.

lifcp command itself is DRD-safe, however this

command is often used in conjunction with other logic
that is not DRD-safe. As such, any control script that
contains this command needs closer examination to
determine if the other logic is DRD-safe.

lifls command itself is DRD-safe, however this

command is often used in conjunction with other logic
that is not DRD-safe. As such, any control script that
contains this command needs closer examination to
determine if the other logic is DRD-safe.

command is often used in conjunction with other logic
that is not DRD-safe. As such, any control script that
contains this command needs closer examination to
determine if the other logic is DRD-safe. A large concern
with the use of mkboot is the logic to determine the
device to be modified. In a runcmd environment, the
mkboot command should be operating on the boot disk
of the inactive system image and not the device from
which the system is currently booted.

control scripts.

--

this command often precedes logic that modifies the
process table. Because modifications to the process
table are usually not safe, the presence of ps in a control
script is a good indicator that the script needs closer
examination to determine if the surrounding logic is safe.

pwd
rm
rmdir
sed

swlist, swmodify &

Yes -­Yes -­Yes -­Yes -­Yes --

swverify
swremove

Varies

It is safe to swremove software that has is_drd_safe
attribute set. It is safe to execute swremove in the

update_prep script. It is safe to execute swremove –
x run_scripts=false.

tail
umount

Yes -­Yes Although unmount is DRD-safe, it should not be used in

SD control scripts.

uname

Varies

Whether or not the use of uname is DRD-safe depends
on which options are sued with the command. As such
the control script needs to be examined to determine if it
is using uname in a safe manner.

Use of the following options is DRD-safe:

• Machine identification/node name (-i)

• License level (-l)

• Machine hardware and model names (-m)

• Node name (-n)

• Name of operating system (-s)

Use of the following fields is NOT DRD-safe:

• Release level (-r)

• Version level (-v)

• Changing of node name (-S)

• All (-a)

wc
what

Yes -­Yes --

© 2008 Hewlett-Packard Development Company, L.P. The information contained
herein is subject to change without notice. The only warranties for HP products
and services are set forth in the express warranty statements accompanying such
products and services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial errors or
omissions contained herein.

5992-4030, May 2008