Managing HP-UX Software With SD-UX - CiteSeerX

Managing HP-UX Software With SD-UX

HP 9000 Computers

B2355-90154

November 1997

© Copyright 1997 Hewlett-Packard Company

ii

NoticesUse of this manual and flexible disc(s) or tape cartridge(s) supplied forthis pack is restricted to this product only. Additional copies of theprograms can be made for security and back-up purposes only. Resale ofthe programs in their present form or with alterations, is expresslyprohibited.

This document contains information which is protected by copyright. Allrights are reserved. Reproduction, adaptation, or translation withoutprior written permission is prohibited, except as allowed under thecopyright laws.

Hewlett-Packard Co.3000 Hanover St.Palo Alto, CA 94304

The information contained in this document is subject to change withoutnotice.

Hewlett-Packard makes no warranty of any kind with regard to thismanual, including, but not limited to, the implied warranties ofmerchantability and fitness for a particular purpose. Hewlett-Packardshall not be liable for errors contained herein or direct, indirect, special,incidental or consequential damages in connection with the furnishing,performance, or use of this material.

A copy of the specific warranty terms applicable to your Hewlett-Packardproduct and replacement parts can be obtained from your local Sales andService Office.

UNIX is a registered trademark in the United States and othercountries, licensed exclusively through X/Open Company Limited.

Copyright © The Regents of the University of California 1979, 1980,1983, 1987, 1993

This software and documentation is based in part on the Fourth BerkeleySoftware Distribution under license from the Regents of the Universityof California.

Copyright © The Regents of the University of Colorado, a body corporate1979

iii

This document has been reproduced and modified with the permission ofthe Regents of the University of Colorado, a body corporate.

Use, duplication or disclosure by the U.S. Government Department ofDefense is subject to restrictions as set forth in paragraph (b)(3)(ii) of theRights in Technical Data and Software clause in FAR 52.227-7013.

Rights for non-DOD U.S. Government Departments and Agencies are asset forth in FAR 52.227-19(c)(1,2).

Printing HistoryNovember 1997 ... Edition 6.

This Edition documents new features applicable to the HP-UX 11.00operating system. The first edition's Part Number was B2355-90054. Thesecond edition's Part Number was B2355-90080. The third edition's PartNumber was B2355-90089. The fourth edition's Part Number wasB2355-90107. The fifth edition’s part number was B2355-90127.

This guide's printing date and part number indicate its current edition.The printing date changes when a new edition is printed. (Minorcorrections and updates which are incorporated at reprint do not causethe date to change.) The part number changes when extensive technicalchanges are incorporated.

New editions of this manual will incorporate all material updated sincethe previous edition.

HP Printing Division:

Open Systems Software DivisionHewlett-Packard Co.3404 E. Harmony Rd.Fort Collins, CO 80525

Contents

v

1. Introduction to Software Distributor

SD-UX Commands Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

Understanding SD-UX Terms and Concepts . . . . . . . . . . . . . . . . . . . . . . .5The Roles Systems Play . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Local Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6Distribution Depots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6Network Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8Development Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Installing “Protected” Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

SD-UX Software Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

Executing SD-UX Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12Using the Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14Using the Graphical or Terminal User Interfaces . . . . . . . . . . . . . . . .15

XToolkit Options and Changing Display Fonts . . . . . . . . . . . . . . . . .17Using the On-line Help System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18Installed Products Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

2. Installing and Copying Software

Installing or Copying Software (swinstall and swcopy) . . . . . . . . . . . . .25Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25Example Install/Copy Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

Installing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26Copying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

Command Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28Command Operands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

Software Selections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31Target Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

Changing Default Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33Session File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

vi

Contents

Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Software and Target Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Using Software Codewords and Customer IDs . . . . . . . . . . . . . . . . . . 39Recovering Updated Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Installing/Copying Software with the Graphical or Terminal UserInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Installation Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Selecting the Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Adding Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Adding Depots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Managing Sessions - The File Menu. . . . . . . . . . . . . . . . . . . . . . . . . 44Changing Preferences - The View Menu . . . . . . . . . . . . . . . . . . . . . 45Changing Options - The Options Menu . . . . . . . . . . . . . . . . . . . . . . 46Choosing Software - The Actions Menu . . . . . . . . . . . . . . . . . . . . . . 46Opening a Software Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Getting More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Analyzing Your Installation Or Copy. . . . . . . . . . . . . . . . . . . . . . . . . . 49Analysis Progress and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Getting More Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Projected Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Seeing the Logfile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Analyzing Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Installing/Copying the Product - the Install (Copy) Dialog . . . . . . . . 55Monitoring the Install or Copy Process . . . . . . . . . . . . . . . . . . . . . . 56

Advanced Topics for swinstall and swcopy . . . . . . . . . . . . . . . . . . . . . . . 58Using swinstall to Perform an OS Update . . . . . . . . . . . . . . . . . . . . . 58

Required Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59New and Old Directories, Files, and Links. . . . . . . . . . . . . . . . . . . . 59Symbolic Link Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Installing to an Alternate Root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Interactively Changing Default Options . . . . . . . . . . . . . . . . . . . . . . . 62

Contents

vii

Compressing Files to Increase Performance. . . . . . . . . . . . . . . . . . . . .65Software Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66Compatibility Filtering and Checking. . . . . . . . . . . . . . . . . . . . . . . . . .68Installing Multiple Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70Installing Software That Requires a System Reboot . . . . . . . . . . . . . .71Installing Patches Interactively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72Using the Source Depot Audit Log . . . . . . . . . . . . . . . . . . . . . . . . . . . .72

3. Configuring and Verifying Software

Configuring Your Installation (swconfig) . . . . . . . . . . . . . . . . . . . . . . . . .74Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76Sample Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76Command Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77Command Operands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78Changing Default Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79Using Session Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80Understanding the Configuration Process . . . . . . . . . . . . . . . . . . . . . .81

Selection Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81Analysis Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81

Configure Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83Executing Configure Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84

Verifying Your Installation (swverify) . . . . . . . . . . . . . . . . . . . . . . . . . . .85Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86Command Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87Command Operands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88Changing Default Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89Using Session Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90Understanding the Verification Process . . . . . . . . . . . . . . . . . . . . . . . .91

viii

Contents

Selection Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Analysis Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4. Registering Software Depots

Registering Your Software (swreg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Command Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Command Operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Changing Default Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Using Session Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Registering Depots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5. Listing Software

Listing Your Software (swlist) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Command Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Command Operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Changing Default Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Using Session Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Creating Software Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Specifying Product Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Specifying Subproduct Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Specifying Fileset Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Specifying Files Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Depot Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Verbose List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Contents

ix

Using Interactive swlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116Searching and Moving Through the List . . . . . . . . . . . . . . . . . . . . . .117Changing the View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117Performing Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118

Advanced Topics for swlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119List Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119Creating Custom Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120More swlist Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121Listing Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122

6. Removing Software

Introduction to swremove . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124

Removing Installed Software Using the Command Line (swremove) .126Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126Command Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127Command Operands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127Changing Default Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128Using Session Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129

Removing Installed Software with the GUI/TUI . . . . . . . . . . . . . . . . . .130Selecting Software to Remove . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131

Opening and Closing an Object . . . . . . . . . . . . . . . . . . . . . . . . . . . .131Analyzing a Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132

Analysis Progress and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132Getting More Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133

Summarizing Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133Seeing the swremove Logfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133

The Remove Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134Monitoring the Removal Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134

x

Contents

Removing Software from Depots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Selecting The Target Depot Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Selecting Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Analyzing the Removal from a Depot . . . . . . . . . . . . . . . . . . . . . . . . 135Removing the Product from a Depot . . . . . . . . . . . . . . . . . . . . . . . . . 135

Advanced Topics for swremove . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Changing swremove Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Removing Software from an Alternate Root . . . . . . . . . . . . . . . . . . . 136Removing Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Dependencies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Multiple Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

7. Modifying IPD or Catalog Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140swmodify and the Product Specification File (PSF) . . . . . . . . . . . . . 140

Changing and Adding Software Information (swmodify) . . . . 141

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Adding Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Changing Existing Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Defining New Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Command Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Command Operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Changing Default Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Using Session Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

8. Managing Patches

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150HP-UX 11.0 Patch Installation Paradigm . . . . . . . . . . . . . . . . . . . . . 151

Contents

xi

Patch-Related Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152Patch Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152Default Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152

Patch Operations Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155Installing Patches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155

Installing Patches in Same Session as Base Product . . . . . . . . . . .156Installing Patches After Base Product Installation . . . . . . . . . . . .157Patch Filtering with Multiple Criteria. . . . . . . . . . . . . . . . . . . . . . .157Explicitly Specifying Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158Patching Kernel and Library Files. . . . . . . . . . . . . . . . . . . . . . . . . .158Patch Load Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158

Copying Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159

Interactive Patch Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160Editing the Patch Filter List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162

Listing Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163Listing Available Patch Categories . . . . . . . . . . . . . . . . . . . . . . . . .163

Patch Removal, Rollback, and Committal. . . . . . . . . . . . . . . . . . . . . .164Verifying Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165Updating Patched Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165

Packaging Patch Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166Patch Software Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166Patch Software Objects and Attributes . . . . . . . . . . . . . . . . . . . . . . . .167Patch Fileset Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168

User-specified Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168Attributes Generated by SD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170

Patch File Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171PSF Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172

9. Controlling Access to Software Objects

Using Access Control Lists (swacl) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .174

xii

Contents

ACL Entries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174ACL Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175ACL Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178Command Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Command Operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Changing Default Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Understanding swacl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182How ACLs are Matched to the User . . . . . . . . . . . . . . . . . . . . . . . . . 183

How ACLs Protect Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184Host System ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Root ACLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Depot ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Product ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188ACL Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Default ACL Template Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Task-Specific Permission Requirements . . . . . . . . . . . . . . . . . . . . . . . . 192Packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Copying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Installing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Verify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Registering Depots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194Sample ACLs for Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

10. Creating Software Packages

Contents

xiii

Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198

Overview of the UNIX Packaging Process . . . . . . . . . . . . . . . . . . . . . . .199

Identifying the Products to Package. . . . . . . . . . . . . . . . . . . . . . . . . . . .200Determining Product Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200Determining Product Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200

Writing a UNIX Control Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202

Creating a Product Specification File (PSF) . . . . . . . . . . . . . . . . . . . . .203Product Specification File Examples . . . . . . . . . . . . . . . . . . . . . . . . . .203

Minimal PSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203Typical PSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204

PSF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .206PSF Object Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .206Selecting the PSF Layout Version . . . . . . . . . . . . . . . . . . . . . . . . . .210PSF Value Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211Product Specification File Semantics. . . . . . . . . . . . . . . . . . . . . . . .217Re-Specifying Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237

Packaging the Software (swpackage) . . . . . . . . . . . . . . . . . . . . . . . . . . .239swpackage Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241

Command Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242Package Selection Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244Package Analysis Phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244The Package Building Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .246Output of Logfile Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247

Verifying the Software Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248

Advanced Packaging Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249Changing Options in the Defaults File . . . . . . . . . . . . . . . . . . . . . . . .249Registering Depots Created by swpackage . . . . . . . . . . . . . . . . . . . . .250Packaging Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251

xiv

Contents

ACL Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Repackaging or Modifying a Software Package. . . . . . . . . . . . . . . . . 254Packaging In Place . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256Following Symbolic Links in the Source . . . . . . . . . . . . . . . . . . . . . . 257Generating File Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257Overriding Disk Space Analysis Errors. . . . . . . . . . . . . . . . . . . . . . . 258Writing to Multiple Tapes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Making Tapes from an Existing Depot . . . . . . . . . . . . . . . . . . . . . . . 260Creating a Depot and Mastering It to CD-ROM . . . . . . . . . . . . . . . . 261Depots on Remote File Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262Packaging Patch Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

11. Using Control Scripts

Introduction to Control Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

Types of Control Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268Control Script Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Control Script Location on the File System . . . . . . . . . . . . . . . . . . 274General Script Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276Variables That Affect All SD-UX Commands . . . . . . . . . . . . . . . . . . 276

LANG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276Variables That Affect All SD-UX Scripts . . . . . . . . . . . . . . . . . . . . . . 277

SW_CONTROL_DIRECTORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277SW_LOCATION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277SW_PATH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277SW_ROOT_DIRECTORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278SW_SESSION_OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278SW_SOFTWARE_SPEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

Variables That Affect swinstall and swremove . . . . . . . . . . . . . . . . . 279SW_DEFERRED_KERNBLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279SW_INITIAL_INSTALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Contents

xv

SW_KERNEL_PATH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279SW_SESSION_IS_KERNEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279SW_SESSION_IS_REBOOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279SW_SYSTEM_FILE_PATH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280

Execution of Control Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .281Details Common to All Control Scripts . . . . . . . . . . . . . . . . . . . . . . . .281Checkinstall Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282Preinstall Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283Postinstall Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283Configure Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .284Unconfigure Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285Verify Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285Checkremove Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .286Preremove Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .286Postremove Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287Request Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .288

Execution of Other Commands by Control Scripts . . . . . . . . . . . . . . . .289

Input To and Output From Control Scripts . . . . . . . . . . . . . . . . . . . . . .290

File Management by Control Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . .293

Testing Control Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294Testing Installation Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294Testing Configuration Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .295Testing Removal Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297

12. Requesting User Responses

The swask Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .300Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .300Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .300Command Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301

xvi

Contents

Command Operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302Changing Default Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Using the ask Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305Using Session Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

Running Request Scripts from swinstall or swconfig. . . . . . . . . . . . . . 306Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

swinstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306swconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Writing Request Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

A. Default Options and Keywords

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

Defaults Listed Alphabetically . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

B. Troubleshooting SD

SD Error Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344Cannot Contact Target Host Daemon/Agent . . . . . . . . . . . . . . . . . . . 344

Resolution: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344Tip: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

Access To An Object Is Denied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346Resolution: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346The Effects of ACL Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . 346The Effects Of Modifying ACL Files Without swacl . . . . . . . . . . . 347Inter-host Secrets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347Working With Depot “Images” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

Contents

xvii

Slow Network Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349Resolution: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349

Connection Timeouts and Other WAN Problems . . . . . . . . . . . . . . . .350Resolution: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .350

Disk Space Analysis Is Incorrect . . . . . . . . . . . . . . . . . . . . . . . . . . . . .352Resolution: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .352

The Packager Fails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .352Resolution: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .352

Truncating The Daemon Logfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . .353Resolution: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .353

Cannot Read a Tape Depot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .353Resolution: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .353

Installation Fails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .354

C. Replacing or Updating SD-UX

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .356

Getting SD-UX Tools from Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .357Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .357Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .358

swgettools Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .359Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .359Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .359

SW-DIST Installation Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .360Updating SD Without Root Access to the Remote Depot . . . . . . . . . .361

xviii

Contents

xix

About This ManualThis guide provides information on how to install, distribute and manageHP-UX application and operating system software on HP 9000 Series700 or 800 computer systems using a series of HP-UX commands calledSD-UX or Software Distributor-UX.

Audience This guide has three audiences:

• System and network administrators who are responsible forinstalling, distributing, maintaining and administering inventories ofsoftware for their system users.

• Software developers or HP Value-Added Business (VAB) vendors whowill be packaging their software so it can be used by the SD-UXsoftware management commands.

• Users of “self-administered,” stand-alone systems who will also usethese utilities to locate, download and update software on theirsystem.

Conventions The following typographical conventions are used in this manual:

Table 1

% A percent sign represents the C shell system prompt.

$ A dollar sign represents the system prompt for theBourne and Korn shells.

# A number sign represents the Superuser prompt.

%cat Boldface type represents command or keywords thatyou must type. In text, bold words are those that areincluded in the glossary. In examples, text that youenter appears in bold.

italic Italic text indicates variable values, place holders andfunction argument names.

Computertext

Computer typeface or information that the computerdisplays. Examples of source code and file contentlisting appear in this typeface.

xx

Related Documents In addition to this guide, you can read the following books to give you amore complete view of your HP-UX system and managing software:

• Installing HP-UX 11.00 and Updating HP-UX 10.x to 11.00(B2355-90153)

• Using HP-UX (B2355-90164)

• Managing Systems and Workgroups (B2355-90157)

• HP-UX Reference (B2355-90166) 5 Vols.

Problem Reporting If you have any problems with the software or documentation, pleasecontact your local Hewlett-Packard Sales Office or Customer ServiceCenter.

[ ] Brackets enclose optional items in formats andcommand descriptions.

{ } Braces enclose a list from which you must choose anitem in formats and command descriptions.

Return or<Return>

Represents a specific key cap on the keyboard. Can beenter, return, shift escape, etc.

Menu Item Shaded and boxed computer text signifies a menuchoice.

| A vertical bar separates items in a list of choices.

<Ctrl-x> Indicates a control character sequence. Hold down thecontrol key while you depress the key that appears inthe place of the x. For example, <Ctrl-e> means thatyou hold down the Ctrl key while pressing e.

EnteringCommands

When instructed to enter a command, type thecommand name and then press Return . For example, theinstruction “enter the ls command” means that youtype ls and then press Return .

Chapter 1 1

Introduction to Software Distributor

1 Introduction to SoftwareDistributor

This chapter introduces the HP-UX software management commandsand presents a short overview of the software management process.These commands are referred to as SD-UX (for SoftwareDistributor-HP-UX).

This chapter explains important concepts that you need to know tounderstand the SD-UX commands and their operation.

• SD-UX commands are included with the HP-UX operating systemand manage software on a local host only. To install and managesoftware simultaneously on multiple remote hosts (including HP-UX,other UNIX platforms, Windows NT, and PCs) from a centralcontroller, you must purchase the HP OpenView Software Distributor,which provides extended software management and multi-sitesoftware distribution capabilities.

• SD-UX is based on distributed, client/server technology, and requiressome networking functionality on the host system for properexecution. These networking services are only available in UNIX RunLevel 2 (Multi-User mode) and above. SD-UX cannot run inSingle-User mode.

• SD-UX running under HP-UX version 11.0 and higher does notsupport NFS diskless clusters.

2 Chapter 1

Introduction to Software DistributorSD-UX Commands Overview

SD-UX Commands OverviewYou can invoke all SD-UX commands from the command line. Inaddition, the swinstall , swcopy , swlist , and swremove commandsoffer an interactive Graphical User Interface (GUI) with windows andpull-down menus and a text-based Terminal User Interface (TUI), whichuses the keyboard instead of the mouse for screen navigation. See“Executing SD-UX Commands” on page 12 in this chapter and Chapter2, “Installing and Copying Software,” for more information.

The syntax, options, defaults and operands are similar for all theseSD-UX commands:

Command Description

swacl SD-UX software objects can be protected fromunauthorized access by Access Control Lists (ACLs).swacl lets you specify, view and change these accesspermissions. See Chapter 9, “Controlling Access toSoftware Objects,” for more information on SD-UXSoftware Security.

swask Asks for a user response. This command runs aninteractive request script that prompts the user for aresponse and stores the result in a response file forlater use by the swinstall or swconfig commands. SeeChapter 12, “Requesting User Responses,” for moreinformation.

swagentd Software destinations and sources require daemonsand agents to accomplish SD-UX software managementtasks. SD-UX commands interact with the daemon(swagentd ) and agent (swagent ) running on sourceand destination systems. The swagentd daemonprocess must be scheduled before a system is availableas a destination. The swagent process is executed byswagentd and is never invoked by the user.

swconfig Prepares your system to run software that wasinstalled with swinstall . Although configuration isautomatically performed as part of the swinstallcommand, swconfig explicitly configures, reconfigures

Chapter 1 3


or unconfigures a host when these actions are neededseparately. See Chapter 3, “Configuring and VerifyingSoftware,” for more information.

swcopy Copies software from a CD-ROM/tape into one or more“depots” on the local host. Software that is copied into adepot cannot be used; it must be installed from thatdepot to make it usable. If your system is to act as asoftware “source” by other systems, you must first copythe software from the physical media into a depot.swcopy can consolidate many different softwareproducts and versions into a depot. Configuration is notdone with swcopy . See Chapter 2, “Installing andCopying Software,” for more information.

swgettools To load software products from a new SD media, thelocal system must first have the SD tools in place thatare compatible with the new SD media. This commandis used to load these tools from the new media ontosystems that do not have updated tools. See AppendixC, “Replacing or Updating SD-UX,” for moreinformation.

swinstall Installs or updates software to the local host from aCD-ROM/tape or from a special SD-UX directory calleda depot (see section “Distribution Depots” on page 6).When you use swinstall , software is installeddirectly into the default directory (/ ) or into analternate directory which you specify. swinstallautomatically configures your system to run thesoftware when it is installed into the default directory.See Chapter 2, “Installing and Copying Software,” formore information.

swlist Displays or lists information about software that isinstalled on your system, contained in depots or onphysical media. See Chapter 5, “Listing Software,” formore information.

swmodify SD-UX commands automatically keep track of softwaremanagement operations by creating an InstalledProducts Database (IPD) and various “catalog files”(see section “Installed Products Database” on page 20in this chapter for more information) that containinformation about the software on the system.

4 Chapter 1


Although neither the IPD or catalog files can be editeddirectly, the swmodify command allows you to changethe contents of these files via the command line. SeeChapter 7, “Modifying IPD or Catalog Contents,” formore information.

swpackage Allows software vendors and system administrators to“package” software products onto a tape or depot whichis then used as a software source. Systemadministrators can also use this command torepackage existing product filesets for installation. SeeChapter 10, “Creating Software Packages,” for moreinformation.

swreg Normally, the swcopy command automaticallyregisters newly created depots to make them “visible”to other systems and the swremove commandautomatically “unregisters” them. swreg registers orunregisters depots when these actions are neededseparately. See Chapter 4, “Registering SoftwareDepots,” for more information.

swremove Deletes software that has been installed on yoursystem. It also removes software from depots. SeeChapter 6, “Removing Software,” for more information.

swverify Compares the original software files on the sourceagainst those that were installed to verify theirintegrity. Also verifies software that was copied to adepot. See Chapter 3, “Configuring and VerifyingSoftware,” for more information.

SD-UX functionality is provided by a software product called SW-DIST,which is included on your HP-UX 11.0 Core OS Disk or Tape.

NOTE If SW-DIST is missing or corrupted on your system, you will not be ableto install or copy any HP-UX software that is in the SD-UX format,including a new SW-DIST product. Refer to Appendix C, “Replacing orUpdating SD-UX,” for information on how to re-load the SD-UXfunctionality.

Chapter 1 5

Introduction to Software DistributorUnderstanding SD-UX Terms and Concepts

Understanding SD-UX Terms andConceptsThroughout this guide, the term host is used to mean an individualcomputer, standing alone or connected to a network of other computers.The local host is the system on which you are invoking the SD-UXcommands. Hosts may also be called nodes, servers, clients orsystems.

This book also refers to target, which is the destination host or directory(root or depot) on which the SD-UX operation is to be performed. Formost SD-UX operations, the target is the local host or depots that are onit.

A software source is a physical medium (CD-ROM or Tape) ordirectory location (depot) that contains software that is to be installed.

The role of SD-UX controller is assumed by the local host on which youinvoke the SD-UX commands. Controller programs are the front ends inthe SD-UX process, providing the user interface for the managementtasks. A controller's role is to collect and validate the data it needs tostart a task, and to display information on the task's status.

The SD-UX controller programs communicate with hosts and depotsthrough the SD-UX agent called swagent . An agent is the part ofSD-UX that actually performs the basic software management tasks.The SD-UX daemon that executes the agent is called swagentd . OnHP-UX 11.0 systems, the SD-UX controller and agent both run on thelocal host.

The Roles Systems PlayThere are three roles an individual host may play in the SD-UX softwaremanagement process - Local Host, Distribution Depot (or Server) andDevelopment System. The role a host plays depends on which commandis used.

6 Chapter 1


Figure 1-1 SD-UX Systems

Local HostA local host is any system on which software is to be installed ormanaged using the SD-UX commands. It is sometimes referred to as thecontroller host.

However, a local host that contains a depot could play a source as well asa destination or target role when other client systems obtain softwarefrom that depot via the network.

Distribution DepotsA depot is a directory location on the local host which is used as a“gathering place” for software products. It is a customizable source ofsoftware used for direct installations by the local host or by other hostson the network.

A depot is created by copying software directly to it from the physicalmedia (using the SD-UX swcopy command) or by creating a softwarepackage on it (using the swpackage command) and then “registering”

Chapter 1 7


the depot with swreg , see Chapter 10, “Creating Software Packages,”. Itcan then be used as the source for installation tasks by the swinstallcommand which is executed on the target machine.

There are two types of depots:

DirectoryDepot Software in a directory depot is stored under a normal

directory on your file system (usually/var/spool/sw ). This software is in a hierarchy ofsubdirectories and filesets organized according to aspecific media format. A directory depot can be“writable” or read-only.

When using the SD-UX commands, you refer to adirectory depot via its top-most directory. In a CD-ROMdepot, this directory would be the CD-ROM’s “mountpoint.”

Tape Depot Software in a tape depot is formatted as a tar archive.Tape depots such as cartridge tapes, DAT and 9-tracktape are referred to by the file system path to the tapedrive's device file.

A tape depot can only be created by using swpackageand it cannot be verified or modified with SD-UXsoftware management commands. You cannot copysoftware (using swcopy ) directly to a tape; useswpackage for this operation (see Chapter 10,“Creating Software Packages,” for more information).

Software in a tape depot must first be transferred to adirectory depot before it can be “pulled” by other hostson the network. A tape depot can be accessed by onlyone command at a time.

A depot usually exists as a directory location (that is, a directory depot).Therefore, a host may contain several depots. For example, a designatedsoftware distribution server on your network might contain a depot ofword processing software, a depot of CAD software, and a spreadsheetsoftware depot, all on the same server.

8 Chapter 1


Network SourcesIf a depot resides on a system that is connected to a network, then thatsystem can be a network source for software. Other systems on thenetwork can install software products from that server instead ofinstalling them each time from a tape or CD-ROM.

A network source offers these advantages over installing directly fromtape or CD-ROM:

• Several users can “pull” software down to their systems (over thenetwork) without having to transport the tapes or disks to each user.

• Installation from a network server is faster than from tape orCD-ROM.

• Many different software products from multiple tapes, CD-ROMs andnetwork servers can be combined into a single depot serving allothers on the network.

Development SystemsAs a software application is developed, files are taken from theprogrammer's environment and placed on a developer host where theyare “integrated” for distribution. The SD-UX swpackage commandprepares these software files by organizing them into specific product,subproduct and fileset structures. It also uses special information files(see “Creating a Product Specification File (PSF)” in Chapter 10,“Creating Software Packages,”) that are used to help other commandsidentify, distribute and manage the application.

After it is organized, the software on a developer host is then “mastered”or copied onto CD-ROMs or tapes for further distribution to users orcustomers. The resulting package can also be made network-accessible tousers.

Installing “Protected” SoftwareMost HP software products are shipped to you on CD-ROM as“protected” products. That is, they cannot be installed or copied unless a“codeword” and “customer ID” are provided by you. Software that isunlocked by a codeword may only be used on computers for which youhave a valid license to use that software. It is your responsibility toensure that the codeword and software are used in this manner. Thecustomer ID uniquely identifies the owner of the codeword.

Chapter 1 9


The codeword for a particular software product is found on the CD-ROMcertificate you received from HP. It shows the codeword along with thecustomer ID for which this codeword is valid. One codeword usuallyunlocks all the products on a CD-ROM which you have purchased. Whenan additional HP software product is purchased, an additional codewordwill be provided by HP. Just enter the new codeword and customer IDand they will be merged with any previously entered codewords.

The customer_id, also found on the Software Certificate, lets you restrictinstallation to a specific owner. SD-UX provides defaults in which youmay specify your codeword and customer_id via the command line or theSD-UX Interactive User Interface. See Appendix A, “Default Options andKeywords,” and “Using Software Codewords and Customer IDs” inChapter 2, “Installing and Copying Software,” for more information oncodeword and customer_id defaults.

10 Chapter 1

Introduction to Software DistributorSD-UX Software Structure

SD-UX Software StructureSD-UX commands work on a hierarchy of software objects - bundles,products, subproducts and filesets - that make up the applications oroperating systems you want to manage.

Bundles Collections of filesets, possibly from several differentproducts, that are “encapsulated” by HP for a specificpurpose. Bundles can be stored in software depots andcopied, installed, removed, listed, configured andverified as single entities. All HP-UX OS software ispackaged in bundles. Bundles, since they are groups offilesets, are NOT necessarily supersets of products.Customer creation of bundles is not supported

Products Collections of subproducts (optional) and filesets. TheSD-UX commands maintain a product focus but stillallow you to specify subproducts and filesets.

Different versions of software can be defined fordifferent platforms and operating systems, as well asdifferent revisions (releases) of the product itself.Several different versions could be included on onedistribution media or depot.

Subproducts Subproducts are used to group logically related filesetswithin a product if the product contains several filesets.

Filesets Filesets include the all the files and control scriptsthat make up a product. They are the smallestmanageable (selectable) SD-UX software object.Filesets can only be part of a single product but theycould be included in several different HP-UX bundles.

SD-UX commands refer to this product structure in the form withperiods separating each level:

bundle[.]orproduct[.[subproduct.]fileset]

Chapter 1 11

Introduction to Software DistributorSD-UX Software Structure

Figure 1-2 HP-UX Software Structure

12 Chapter 1

Introduction to Software DistributorExecuting SD-UX Commands

Executing SD-UX CommandsYou can invoke all SD-UX software management commandsnon-interactively via the command line. The command line interface isused effectively when you want to write command scripts to be executedat a later time or to execute tasks that take a long time to accomplish.

The swinstall , swcopy , swlist , and swremove commands alsoprovide a Graphical User Interface (GUI). A Terminal User Interface(TUI) for these commands is also supplied for those computers withoutgraphics terminal capabilities. For those management tasks you want tomonitor as they are being performed, the GUI (or TUI) is a quick andefficient way to work with the commands, analyze the effects of a taskand retry those that might fail.

Figure 1-3 The Terminal User Interface (TUI)

Chapter 1 13


The GUI or TUI are the primary and suggested methods of interactingwith the install, copy and remove operations. The command lineinterface requires you to be familiar with a broad range of defaults,options and other variables that are available in the SD-UX softwaremanagement environment.

Using the Command Line InterfaceSD-UX command behaviors, source/host designations and softwareselections are specified on the command line in one of two ways:

1. By specifying (often multiple) software selections, host names andoption values individually on the command line or

2. By using input files that contain lists of software selections,variables and operands to use in the command (see the section “InputFiles” below for more information).

Here is what a typical SD-UX command line looks like:

Figure 1-4 Sample Command

NOTE The @ (“at”) character and the required single space following it areoptional, but important, to the successful operation of SD-UX commandlines that specify host locations. They are not necessary if you arespecifying the local host and default depot as the recipient system. If theyare used, they act as a separator between operands and the destination.Only one @ character is needed.

On some systems, the @ character is used as the “kill” function. Typestty on your system to see if the @ character is mapped to any otherfunction on your system. If it is, remove or change the mapping.

14 Chapter 1


Input FilesBoth the command line and graphical interfaces can be influenced byvarious input files:

Defaults File The file /usr/lib/sw/sys.defaults contains all theSD-UX software management defaults and theirvalues. It is the master “template” file and is not useddirectly by SD-UX. Individual defaults are copied fromthis template file, added to your system defaults filestored in /var/adm/sw/defaults or$HOME/.swdefaults and then their values changed.These values can then be customized, added to,changed or overridden from the command-line.

See Appendix A, “Default Options and Keywords,” for acomplete listing of defaults and their values anddescriptions.

Session Files Before any SD-UX task actually starts, the systemautomatically saves the current command options,source information, software selections and hostdesignation into a session file (in the$HOME/.sw/sessions/ directory) as<swcommand>.last . Each time you save a session file,it will overwrite the previously stored one. To savemultiple session files, just rename the<swcommand>.last file.

Once you have performed an installation, you need not“start from scratch” the next time; just recall apreviously stored session file. See “Managing Sessions -The File Menu” in Chapter 2, “Installing and CopyingSoftware,” for more information.

SoftwareSelection Files The /var/adm/sw/software/ directory is reserved

for files containing the names of software selections tobe installed, copied or removed. To keep the commandline shorter, software selection input files let youspecify long lists of software products. You can imaginehow long the command would be if you were installingten different software products and had to specify each

Chapter 1 15


one by name on the command line. With a softwareselection file , you only have to specify the singlefile name.

Host Files The defaults.hosts file contains lists of hosts thatare used by the GUI and TUI to allow pre-selectedchoices for sources and targets. These lists are stored inthe $HOME/.swdefaults.hosts or/var/adm/defaults.hosts files.

Patch Filter FilesThe swinstall and swcopy interactive userinterfaces read a default list of patch filters that youcan use as selection criteria for patch software. The listis stored in: /var/adm/sw/defaults.patchfiltersthe system-wide default list of patch filters, and$HOME/.sw/defaults.patchfiltersthe user-specific default list of patch filters.

See each command's chapter in this guide for complete descriptions ofthe options, defaults, input files and operands.

Using the Graphical or Terminal UserInterfacesThe Graphical User Interface helps you designate sources, specifysoftware products and perform other operations by choosing actions frompull-down menus, filling out dialog boxes and highlighting choices fromobject lists. It also allows you to visually monitor a particular processand get a better overall picture. The Terminal User Interface also allowsinteraction with menus and object lists via ASCII character screens. TheGraphical User Interface can also be launched from inside He’s SystemsAdministration Manager (SAM) application.

Only the swinstall , swcopy , swlist , and swremove commandsfeature this Graphical or Terminal Interface. The swverify , swconfig ,swreg , swmodify , swacl , and swpackage commands rely on thecommand line interface for specification and execution.

To start the Graphical or Terminal User Interface for an install, copy orremove session, type:

16 Chapter 1


/usr/sbin/swinstallor

/usr/sbin/swcopyor

/usr/sbin/swremove

If you put /usr/sbin in your PATH, you do not need the /usr/sbinprefix.

Figure 1-5 GUI Window Components

The major Graphical and Terminal User Interface Windows contain aMenu bar across the top, a Message Area, Column Headings and anObject List

Menu bar The Menu bar provides menu choices such as: FileView Options Actions ...... Help. Each of these choiceshave additional “pull-down” menus for more activities.Placing your mouse cursor on the appropriate Menubar choice and “clicking” (pressing the left mousebutton) causes additional menus to appear. In the TUIuse the Arrow, Tab, and Return keys. Items within themenus may appear or disappear depending on whetherselections are highlighted or not. Some items may alsobe “grayed” to show they are not available for a specificaction.

Chapter 1 17


Message Area The Message Area provides information on how tonavigate through the various windows and how toselect items. The Message area is for your informationonly; items in it cannot be changed by the user.

Object List The Object List contains the name of the targets,selections or other information regarding selections,analysis and details. Flags (“Yes,” “Partial” or blank)are used to denote whether items in the list have been“marked” for an activity (see the “Marked?” column).Items in the Object List can be marked by highlighting(clicking on them with the left mouse button). If youhave a Terminal User Interface, you can mark (choose)objects by pressing Return when the focus is on theitem and then pressing the m key on your keyboard.Unmark items in the TUI by using the u key.

The Graphical User Interface also allows you to change window viewpreferences to fit your requirements. Using a Columns Editor dialog (seeChapter 2, “Installing and Copying Software,”), accessible through theView menu item, you can customize window appearances by changingObject List column content, width, justification and the position ofattributes or headers.

NOTE The TUI is the default mode of interacting with swinstall , swcopy ,and swremove if you have not set the DISPLAY variable. If you have setyour DISPLAY variable, invoking these commands automatically startsthe GUI.

To invoke the swlist GUI, you must use the swlist -i option.

XToolkit Options and Changing Display FontsThe SD-UX commands support the following subset of the HP-UXXToolkit command line options:

• -bg or -background

• -fg or -foreground

• -display

• -name

• -xrm

18 Chapter 1


Note that the SD-UX software management commands do not supportthe XToolkit -fn or -font option used to change display fonts. However,there is an alternative method for controlling your display fonts.

SD-UX commands recognize most Motif™ standard resources whenrunning in the X11/Motif environment, plus the following additionalresources:

*systemFont Specifies the variable width font used in the GUI menubars and other areas where a variable width font isapplicable. The default size is 8x13.

*userFont Specifies the fixed width font used in all other GUIdisplays. This font should be the same basic size as the*systemFont only in the fixed width style. The defaultsize is also 8x13.

Here is an example of how to change the size of your fixed width fontfrom 8x13 to 6x13:

swinstall -xrm 'Swinstall*userFont: user6x13'

Here is how to change the variable width font style to 12 point HPRoman 8:

swinstall -xrm 'Swinstall*systemFont: -adobe-courier-medium-r-normal12-120-75-75-m-70-hp-roman8'

You can also create a defaults file (in /usr/lib/X11/app-defaults )for each command with a Graphical User Interface so that a resource willbe set each time you invoke a specific command. Here is an example of anapp-defaults file for swremove :

# Swremove app-defaults

Swremove*foreground: redSwremove*background: whiteSwremove*userFont: hp8.8x16bSwremove*systemFont: -adobe-courier-medium-r-normal12-120-75-75-m-70-hp-roman8

Using the On-line Help SystemThe SD-UX swinstall , swcopy , and swremove commands have anon-line help system to assist you in working with the GUI or TUI. SD-UXmenu choices and activities have associated help screens that explain theactivity, provide examples and answer your questions about softwaremanagement tasks.

Chapter 1 19


Figure 1-6 A Typical On-line Help Screen

For a description of each menu choice in the various screens, windowsand menus, place the cursor on an item with the left mouse button orarrow keys and press the F1 key on your keyboard. This displays a HelpScreen that provides additional information on that item. For anoverview of each major screen, plus help on the keyboard and otherproduct information, choose the Help menu item in the Menu bar.

For more complete technical information on each of the SD-UXcommands, use the HP-UX man command to see the individual SD-UXmanual pages:

man 5 sd For SD-UX overview manual page.

man 4 sd For SD-UX file layouts.

man 4 swpackage For packaging file layouts.

man <SD-UX command> For all other SD-UX commands.

20 Chapter 1


Installed Products DatabaseSD-UX keeps track of software installations, products and filesets onyour system with an Installed Products Database (IPD) for rootinstalled software and catalog files for software in depots.

Located in the directory /var/adm/sw/products , the IPD is a series offiles and subdirectories that contain information about all the productsthat are installed under the root directory (/ ). This information includes14-character “tags” or product names, one-line title fields,paragraph-or-longer description text, long README files, copyrightinformation, vendor information and part numbers on each productinstalled. In addition, the IPD contains revision information and auser-targeted architecture field including the four uname attributes -operating system name, release, version and hardware machine type.Here is what the IPD INFO file for a product called “Accounting” lookslike:

filesettag ACCOUNTNGdata_model_revision 2.4instance_id 1control_directory ACCOUNTNGsize 292271revision B.11.00description Vendor Name: Hewlett-Packard CompanyProduct Name: AccountingFileset Name: ACCOUNTING

Text: "HP-UX System Accounting feature set. Use these features togather billing data for such items as disk space usage, connecttime or CPU resource usage."timestamp 797724879install_date 199504121614.39install_source hpfclc.fc.hp.com:/release/11.00_gsL/goodsystemstate configuredancestor HPUX10.20.ACCOUNTNGcorequisite OS-Core.CMDS-MIN,r>=B.11.00,a=HP-UX_B.11.00_32/64,fa=HP-UX_B.11.00_32/64,v=HP

Catalog files are the equivalent IPD files but they are for software storedin a depot. When a depot is created or modified using swcopy , these filesare created and placed in the specified depot (or in the default/var/spool/sw depot). They describe the depot and its contents.

The swinstall , swconfig , swcopy , and swremove tasks automaticallyadd to, change and delete IPD and catalog file information as thecommands are executed. swlist and swverify tasks read the IPDinformation and use it to affect command behavior.

Chapter 1 21


NOTE You cannot manually edit the IPD or catalog files, However, the SD-UXswmodify command can be used to alter individual pieces of informationin the IPD and catalog files (see Chapter 7, “Modifying IPD or CatalogContents,” for more information).

The IPD also contains a swlock file that manages simultaneous readand/or write access to software objects.

22 Chapter 1


Chapter 2 23

Installing and Copying Software

2 Installing and Copying Software

As stated in Chapter 1, “Introduction to Software Distributor,” theswinstall command installs or updates software from a softwaresource (a depot or physical media) to your local host. The swcopycommand copies software from a source to a depot which can then beused as an installation source. Software that is copied into a depot cannotbe used directly; it is placed there only to act as a source for otherinstallations.

Other differences between swinstall and swcopy include:

• Compatibility checking (that is, making sure the software will run onthe installed system) is done for swinstall , but not done in swcopy .

• Control scripts are not run for swcopy .

• Kernel rebuilding or rebooting is not done for swcopy . Other pre- andpost-install checks, such as disk space analysis and requisiteselection, are still performed.

• When a depot is created or modified with swcopy , “catalog files” arebuilt that describe the depot (catalog files are similar to the filescreated in the SD-UX Installed Products Database for products andinstallations).

• A depot source may contain software for a variety of machines orarchitectures. swinstall 's compatibility filtering ensures thatthe product architecture matches the host when that software isinstalled to the target's default directory (/ ).

Topic Page

“Installing or Copying Software (swinstall and swcopy)” 25

“Installing/Copying Software with the Graphical or TerminalUser Interface”

41

“Advanced Topics for swinstall and swcopy” 58

24 Chapter 2

Installing and Copying Software

Introduction

Software to be used on the local host is normally installed relative to theroot directory (/ ), so that is the SD-UX default “target” location. You canalso install to an alternate root directory of your choosing (see“Installing to an Alternate Root”).

SD-UX installed software is automatically configured by swinstall torun on the local host only if the software is loaded into the host's default/ directory or root file system. If the installation is to an alternate root,software configuration is not automatically done, but may be performedlater using the swconfig command (see Chapter 3, “Configuring andVerifying Software.”).

NOTE If the SD-UX filesets (that is, the SW-DIST product on your ProductMedia) are corrupted or missing from your system disk, you cannotinstall any software packaged in SD format. If this happens, please referto Appendix C, “Replacing or Updating SD-UX,” for instructions on howto load (or re-load) SD-UX from the media using standard HP-UXcommands.

Chapter 2 25

Installing and Copying SoftwareInstalling or Copying Software (swinstall and swcopy)

Installing or Copying Software(swinstall and swcopy )To start an install or copy session via the command line, assemble anyoptions (if needed), host and source names, and software selections into acommand string that might look like this:

swinstall -p -s softsource -f softlist \@ myhost:/mydirectory

The @myhost:/ mydirectory is optional if you are installing to your localhost and default directory. If you have several selections, use thecommand options to point to input files that contain lists of softwareselections (-f softlist, above), default modifications and other variables(see “Input Files” for more information).

SyntaxThe syntax for swcopy and swinstall is:

swinstall [XToolkit Options][-i ][-l ][-p ][-r ][-v ][-c catalog][-C session file][-f software_file][-s source][-S session_file][-x option=value][-X option_file][software_selections][@target_selections]

swcopy [XToolkit Options][-i ][-p ][-v ][-C session_file][-f software_file][-s source][-S session_file][-x option=value][-X option file][software_selections][@target_selections]

Using SD-UX syntax, you can specify:

• which software selections to install or copy (using the -f software_fileoption or named software_selections)

• where those selections are located (the -s source name) and

• what host and/or depot location is to receive them (the @ host:/depotdesignation).

26 Chapter 2


NOTE In the swinstall command, if no source is specified, the local host'sdefault depot directory (/var/spool/sw ) is assumed. If no host isnamed, the system to receive the software is assumed to be the root (/ )directory on your local host. So, you do not have to use the @ sign and[host][: ][/ directory] designation if you are operating on the local hostand/or default depot directory.

Example Install/Copy OperationsThis section provides examples of commands for installing or copyingsoftware products. The \* is an optional shorthand wildcard meaning“all products and filesets or all available software.”

Installing

1. To install a pre-determined list of software products in the file mysoftthat are physically on a CD-ROM (mounted locally at /mnt/cd ) to thedefault directory (/ ) on the local host:

swinstall -f mysoft -s /mnt/cd

Note: The @ sign was not used because it is assumed that theinstallation will be to the default directory on the local host.

2. To pull all the software selections that are in the default depot(/var/spool/sw ) located on a host named server to the defaultdirectory on your local host named myhost and preview the process(-p ) before actually installing:

swinstall -p -s server \* @ myhost

A depot location (:/ depot) is not specified because it is assumed thatthe software is located in the default /var/spool/sw on server andwill be installed at / on myhost. The -p analysis option is explainedbelow under “Command Options.”

3. To select all the products named “C” and “Pascal” from the defaultdepot on the host named sw_server and start an interactive GUIsession (-i ):

swinstall -i -s sw_server C Pascal

4. To update HP Omniback software (already installed in the defaultdirectory on the local host) with a newer version from a CD-ROMmounted at /mnt/cd :

Chapter 2 27


swinstall -s /mnt/cd Omniback

“Updating” in SD-UX means that you are completely overwriting theold version filesets with the new (see “Using swinstall to Perform anOS Update”).

Copying

1. To copy all products from the DAT tape at /dev/rmt/0m to thedefault depot (/var/spool/sw ) on the local host:

swcopy -s /dev/rmt/0m \*

2. To copy a list of software selections (on a local CD-ROM) named in thefile mysoft to a depot at the path /var/spool/sw on the host namedhostA and preview the process before actually copying the software:

swcopy -p -f mysoft -s /mnt/cd @ hostA:/var/spool/sw

28 Chapter 2


Command OptionsMany of the options listed here for swinstall and swcopy are the samefor other SD-UX commands.

Option Action

-i Run the command in interactive mode by invoking theGraphical User Interface (GUI). (The GUI is onlysupported on HP=UX.) Displays the first Graphical orTerminal Interface Window.

-l (Applies only to HP-UX 10.X) There is no -l(linkinstall ) option for swcopy .

Runs the command in linkinstall mode, which makessoftware installed under a server’s shared_rootavailable to a diskless client’s private_root (HP-UXonly).

When run in the linkinstall mode, swinstall :

• Creates NFS mounts to the software to make itaccessible from the target. This may involve delayedmounting for alternate roots.

• Modifies the target’s fstab file.

• Modifies the source’s exportsfile to add mount permission for the target.

Mounts are created by examining the share_linkproduct attribute. Not all products supportlinkinstall . Some products may be visible withoutcreating a new mount if they reside under an old one.

-p Preview an install or copy task from the command lineby running it through the Analysis Phase and thenexiting. This option can be used with any of the otheroptions to understand the impact of a command beforethe system actually does it.

-r (Optional) Specify alternate root directories. See“Advanced Topics for swinstall and swcopy” on page 58for more information about installing to alternateroots. There is no -r option for swcopy .

Chapter 2 29


-v Turn on verbose output to stdout and display allactivity to the screen. Lets you see the results of thecommand line activity while it is being performed.

-c catalog Specifies the pathname of an exported catalog whichstores copies of the response file or files created by arequest script (if -x ask=true or -xask=as_needed) . The response files are also stored inthe Installed Products Database after the installationprocess is complete.

-C session file Run the command and save the current option andoperand values to a session_file for re-use in anothersession. You can enter a relative or absolute path withthe file name. The default directory for session files is$HOME/.sw/sessions/ .You can recall a session file with the -S option.

-f software file Read a list of software selections from a separate fileinstead of (or in addition to) the command line. In thisseparate file, blank lines and lines beginning with #(comments) are ignored. Each software selection mustbe specified on a separate line. For an example of asoftware selection file, see “Command Operands” onpage 31.

-s source Specify which software source is to be used for theinstallation or copy. For an installation, the defaultsource type is a directory or depot (usually/var/spool/sw ) on the local host, not a tape device.The default source for linkinstall is the shared root/export/shared_roots/OS_700 .

The syntax is:

[host][: ][/ directory]

A host may be specified by its host name, domain name,or internet address. A directory must be specified by anabsolute path.

-S session file Run the command based on values saved from aprevious installation session, as defined insession_file . You can save session information froma command line session with the -C session_file option.

30 Chapter 2


-x option=value Set the session option to value and override the defaultvalue or a value in an options file (-X option file).Multiple -x options can be specified. See the section“Advanced Topics for swinstall and swcopy” for moreinformation on defaults.

-X option file Read session options and behaviors fromoption_file . The default values for system optionsare provided in the file /var/adm/sw/defaults . Youcan also provide a personal option file,$HOME/.swdefaults . This option file overrides thosevalues in the system defaults file. For a complete listingof system options, see the file/usr/lib/sw/sys.defaults . This file lists thepossible values and behaviors for each option for eachcommand.

Chapter 2 31


Command OperandsSoftware selections and source/target designations must be named usinga particular syntax and format so SD-UX can identify and locate them.

The swinstall and swcopy commands support two types of operands:software selections followed by target selections. These operands areseparated by the “@” (at) character. This syntax implies that thecommand operates on “selections at targets”.

Software SelectionsThe selections operands consist of software_selections.

swinstall and swcopy support the following syntax for eachsoftware_selection:

bundle[.product[.subproduct][.fileset]][,version]product[.subproduct][.fileset][,version]

The version component has the form:

[,r <op> revision][,a <op> arch][,v <op> vendor][,c <op> category][,l= location][,fr <op> revision][,fa <op> arch]

where:

• location applies only to installed software and refers to softwareinstalled to a location other than the default product directory.

• fr and fa apply only to filesets.

• The <op> (relational operator) component can be of the form:

==, >=, <=, <, >, or !=

which performs individual comparisons on dot-separated fields.

For example, r>=B.10.00 chooses all revisions greater than or equalto B.10.00. The system compares each dot-separated field to findmatches.

• The = (equals) relational operator lets you specify selections with theshell wildcard and pattern-matching notations: [ ], *, ?, !. Forexample, the expression r=1[01].* returns any revision in version10 or version 11.

32 Chapter 2


• All version components are repeatable within a single specification(e.g. r>=A.12, <A.20 ). If multiple components are used, theselection must match all components.

• Fully qualified software specs include the r= , a=, and v= versioncomponents even if they contain empty strings. For installedsoftware, l= is also included.

• No space or tab characters are allowed in a software selection.

• The software instance_id can take the place of the version component.It has the form:

[instance_id]

within the context of an exported catalog, where instance_id is aninteger that distinguishes versions of products and bundles with thesame tag.

The \* software specification selects all products. It is not allowed whenremoving software from the root directory / .

Target SelectionThe swinstall and swcopy commands support the following syntax foreach target_selection. The : (colon) is required if both a host anddirectory are specified.

[host][: ][/directory]

A host may be specified by its host name, domain name, or internetaddress. A directory must be specified by an absolute path.

Chapter 2 33


Changing Default OptionsIn addition to the command options listed in “Command Options” onpage 28, the /usr/lib/sw/sys.defaults template file lists andexplains nearly sixty different SD-UX command options, their possiblevalues, and the resulting system behavior. These options are listed ascomments that you can copy (uncommented) into the system defaults file(/var/adm/sw/defaults ) or your personal defaults file($HOME/.swdefaults ).

Each value (known as a default option value) in this file is specifiedusing the command.option=value syntax. For example:

swinstall.allow_downdate=false

If you placed this line in your /var/adm/sw/defaults (for system-widecontrol) or $HOME/.swdefaults file (for individual user control) andchanged the value from “false” to “true”, the system would allowinstallation of older versions over newer versions for all future sessions.(This is called downdating as opposed to updating).

These rules govern the way the defaults work:

1. Defaults in /usr/lib/sw/sys.defaults are hard-coded and areused only when there are no other default files or session files thatcontain different values.

2. Defaults in /var/adm/sw/defaults file affect all users in a system.

3. Defaults in your personal $HOME/.swdefaults file affect only youand not the entire system.

4. Defaults in a session file affect activities only for that session andrevert when that session is completed.

5. Defaults changed on the command line affect only that activity.

For system-wide policy setting, use the /var/adm/sw/defaults files.Keep in mind, however, that individual users may override thesedefaults with their own $HOME/.swdefaults file. Defaults can also beoverridden by session files or command line changes.

To change a default value or behavior for an SD-UX command, simplycopy the specific default line (the un-commented line) from the file/usr/lib/sw/sys.defaults , add it to the file/var/adm/sw/defaults (for system-wide changes) or$HOME/.swdefaults (for individual user changes) and then change itsvalue.

34 Chapter 2


See “Advanced Topics for swinstall and swcopy” for more information onhow to modify these defaults and options. Appendix A, “Default Optionsand Keywords,” and the file /usr/lib/sw/sys.defaults have acomplete list of all system default options, their values and a briefdescription of their effects.

NOTE Use caution when changing default option values. They allow usefulflexibility but can produce harmful results if changed to a value that isinappropriate for your needs. Use the On-Line Help or consult theappendix Appendix A, “Default Options and Keywords,” in this manualto understand fully each option and value.

Altering default values can help when you don't want to specifycommand behavior every time the command is invoked. Default valuesare specified in the defaults file using a command. option=valuesyntax.

These values can be individually overridden on the command line byspecifying an alternative optionfile with the -X option or with the -xoption=value option. For example, to start an interactive install sessionthat lets you install software that is not compatible with the proposedhost system, type

swinstall -i -x allow_incompatible=true

Defaults can also be edited directly in the /var/adm/sw/defaults or$HOME/.swdefaults files or changed using the GUI Options Editor.

The defaults and options that apply to swinstall and swcopy areshown in the Table 2-1:

Chapter 2 35


Table 2-1 Install Defaults

agent_auto_exit=true match_target=false

agent_timeout_minutes=10000 mount_all_filesystems=true

allow_downdate=false os_name

allow_incompatible=false os_release

allow_multiple_versions=false patch_filter=software_specification

ask=false patch_match_target=false

autoreboot=false patch_save_files=true

autorecover_product=false polling_interval=2

autoremove_job=false recopy=false

autoselect_dependencies=true register_new_depot=true

autoselect_patches=true register_new_root=true

autoselect_reference_bundles=true reinstall=false

codeword= reinstall_files=true

compress_files=false reinstall_files_use_cksum=true

controller_source= remove_obsolete_filesets=false

create_target_path=true retry_rpc=1

customer_id= rpc_binding_info=ncacn_ip_tcp:[2121]ncadg_ip_udp:[2121]

defer_configure=false rpc_timeout=5

distribution_source_directory=/var/spool/sw

select_local=true

distribution_target_directory=/var/spool/sw

software=

enforce_dependencies=true software_view=all_bundles

enforce_dsa=true source_cdrom=/SD_CDROM

36 Chapter 2


enforce_kernbld_failure=true source_tape=/dev/rmt/0m

enforce_scripts=true source_type=directory

layout_version=1.0 targets=

logdetail=false uncompress_files=false

logfile=/var/adm/sw/swcommand.log use_alternate_source=false

loglevel=1 verbose=1

log_msgid=0 write_remote_files=true

Chapter 2 37


Session FileEach invocation of the swinstall or swcopy command defines aninstallation or copy session. The invocation options, source information,software selections, and target hosts are saved before the installation orcopy task actually commences. This lets you re-execute the commandeven if the session ends before proper completion.

Each session is saved to the file:

$HOME/.sw/sessions/swinstall{swcopy}.last

This file is overwritten by each invocation of swinstall or swcopy .

You can also save session information from interactive or command-linesessions. From an interactive session, you can save session informationinto a file at any time by selecting the Save Session or Save Session Asoption from the File menu. From a command line session, you can savesession information by executing swinstall or swcopy with the-C session_file option.

A session file uses the same syntax as the defaults files. You can specifyan absolute path for a session file. If you do not specify a directory, thedefault location for a session file is $HOME/.sw/sessions/ .

To re-execute a saved session from an interactive session, use the RecallSession option from the File menu. To re-execute a session from acommand line, specify the session file as the argument for the-S session_file option of swinstall or swcopy .

Note that when you re-execute a session file, the values in the session filetake precedence over values in the system defaults file. Likewise, anycommand line options or parameters that you specify when you invokeswinstall or swcopy take precedence over the values in the sessionfile.

38 Chapter 2


Environment VariablesSD programs are affected by external environment variables andenvironment variables set for use by control scripts. For a description ofexternal environment variables, see Chapter 11, Control Scripts.

Software and Target ListsThe swinstall and swcopy commands support software selections,target selections, and patch filter selections from separate input files.

You can specify software and target selection lists with the -f and -toptions. Software and targets specified in these files are selected foroperation instead of (or in addition to) files listed in the command line.(See the -f and -t options for more information.)

Additionally, the swinstall and swcopy interactive user interfacesread a default list of hosts on which to operate. The list is stored in:

/var/adm/sw/defaults.hostsThe system-wide default list of hosts.

$HOME/.swdefaults.hostsThe user-specific default list of hosts.

For each interactive command, target hosts containing roots, depots, andhosts serving as PC controllers are specified in separate lists (hosts ,hosts_with_depots , and pc_controllers , respectively). The list ofhosts are enclosed in {} braces and separated by white space (blank, taband newline). For example:

swinstall.hosts={hostA hostB hostC hostD hostE hostF}swinstall.pc_controllers={pc1 pc2}swcopy.hosts_with_depots={hostS}swcopy.pc_controllers={pc1 pc2}

The swinstall and swcopy interactive user interfaces read a defaultlist of patch filters that you can use as selection criteria for patchsoftware. See “Editing the Patch Filter List” on page 162 for moreinformation.

Chapter 2 39


Using Software Codewords and Customer IDsTo protect software from unauthorized installation, HP (and othervendors) use special codewords and customer identification numbers to“lock” the software to a particular owner. These codewords and customerIDs are provided to you when you purchase the software (or receive it asupdate). HP lists them on the Software Certificate which is packagedwith the software.

A codeword for a particular customer ID and CD-ROM only needs to beentered once per target system. The codeword and customer ID arestored for future reference in the /var/adm/sw/.codewords file.

SD-UX will prompt you for these codewords or numbers prior to theinstallation of protected software. You can enter or change the numbersvia the Graphical User Interface (GUI) using the Add New Codewordchoice from the Actions menu in the GUI, or by using the appropriatedefault option (-x codeword=xxxx and -x customer_id=xxx) on thecommand line.

See Appendix A, “Default Options and Keywords,” for more informationon codeword and customer_id defaults.

SD searches the .codewords file on the server that is providingprotected software to other hosts. It looks for valid customer_id/codewordpairs. In doing so, SD eliminates the need to enter codewords andcustomer_ids on every host that is “pulling” the software.

To properly store the customer_id/codeword for a CD-ROM, runswinstall or swcopy on the host serving the CD-ROM. After thecodeword has been stored, clients installing or copying software usingthat host and CD-ROM as a source will no longer require a codeword orcustomer_id.

This is a time saver if you are updating multiple systems.

For example, if you want to store the codeword 123456789101bcdf (fromthe /CD-ROM mount point) and your customer_id was xyzCorp, youwould enter on the command line:

swinstall -x customer_id=xyzCorp \-x codeword=123456789101bcdf \-s /CD_ROM

Error messages can be ignored since you are only storing codewords andcustomer_ids.

40 Chapter 2


Recovering Updated FilesIf you should start an install operation and, in the middle, the processfails, in certain instances SD-UX may allow you to automatically recoveror “rollback” to the original product files.

Placing the swinstall.autorecover_product=true default line in/var/adm/sw/defaults or $HOME/.swdefaults lets you recoverproduct files that are normally removed as they are updated. If youencounter an error while loading new filesets, the product being loadedwill be marked CORRUPT and you must re-try the installation.

CAUTION Due to the complexities of the preinstall and postinstall scriptsassociated with all products delivered as part of HP-UX, autorecovery ofthese products is not supported. All HP-UX products have preinstall andpostinstall scripts without accompanying undo scripts. Consequently, donot change the autorecover_products option to “true” prior to installingany HP-UX software.

If the software uses no preinstall or postinstall scripts or has theappropriate undo scripts, autorecover will work.

By setting the autorecover_product= option to “true”, all files that areremoved will be saved as backup copies until all filesets in the producthave completed loading. This allows automatic recovery of all filesets ifthe load fails.

If autorecover_product is set to “false” (the default value), files that havealready been removed cannot be recovered.

Chapter 2 41

Installing and Copying SoftwareInstalling/Copying Software with the Graphical or Terminal User Interface

Installing/Copying Software with theGraphical or Terminal User InterfaceThis section provides a quick overview of the Graphical User Interface(GUI) and Terminal User Interface (TUI) features, pointing out themajor capabilities. It is not a step-by-step procedure guide or road-map.As you use the GUI or TUI, you will become more familiar with theprocesses and menu items. If you have questions about specific menuchoices, use the On-Line Help feature (place the cursor/focus on the itemand press f1 on your keyboard) for more information. You can also pressthe Help button in the Menubar or the button at the lower right of thescreen for information on the whole screen.

NOTE The TUI is the default mode of interacting with swinstall , swcopy ,and swremove if you have NOT set your DISPLAY variable. If you haveset your DISPLAY variable correctly, invoking these commandsautomatically starts the GUI.

To start the Graphical or Terminal User Interface for an install or copysession, type:

/usr/sbin/swinstall

or

/usr/sbin/swcopy

If you put /usr/sbin in your PATH, you do not need the /usr/sbinpath prefix.

42 Chapter 2


Installation PhasesThere are three phases in the install or copy process:

Phase Description

Selection Specifying the software you want to install or copy(software selections) and where that software is located(source) and where it is to be installed or copied(target). You can also change default options in thisphase and specify target paths for swcopy andinstallations to alternate roots. The SD-UX GUI andTUI offer two interactive screens for this phase: theSource Selection Dialog and the Software SelectionScreen.

Analysis An analysis of the task is performed BEFORE actuallyinstalling or copying the software to make sure theprocess will be successful. The process is monitoredand you can see the results as they occur. SD-UXprovides an Analysis Dialog that overlays the SoftwareSelection screen for this phase.

Load/Execution

The actual software installation or copy and furthermonitoring of the process. SD-UX provides a separateInstall/Copy Dialog for this phase. For swinstall , anyinstall and configure scripts are executed and kernelbuilding or rebooting is done at this time, as needed.See Appendix 11, “Using Control Scripts,” for moreinformation on control scripts.

swinstall and swcopy also automatically save the current commandoptions, source information, software selections and hosts into a sessionfile before the operation actually starts. This session file can then berecalled and re-executed. This session file is saved as$HOME/.sw/sessions/swinstall (swcopy).last (see “ManagingSessions - The File Menu” for more information).

Chapter 2 43


Selecting the SourceWhen you type swinstall or swcopy , the Software Selection Windowappears on your screen with the Specify Source Dialog superimposedover it. The dialog automatically lists the local host and default depotpath, but you can also specify some other the host and depot where thesoftware is located. You can also choose what level of software to “view”:All Bundles, Products, or Bundles of One Category.

Figure 2-1 Specify Source Dialog

Adding SourcesIf you click on the Source Host Name button in the Specify SourceDialog, the system will display a box with all the hosts that are in yourdefaults.hosts file ($HOME/.sw/defaults.hosts or/var/adm/sw/defaults.hosts ). You can highlight (choose) one of thehosts and press OK and it will appear in the appropriate box in theSpecify Source Dialog. You can also manually enter a source host namein the text box next to the Source Host Name button if the source youwant does not appear in the dialog.

44 Chapter 2


Here is a sample $HOME/.sw/defaults.hosts file:

swinstall.hosts = { hostA hostB hostC}swinstall.hosts_with_depots = { host-depotA host-depotB}

swcopy.hosts_with_depots = { SourceA SourceB}

swremove.hosts = { SourceX SourceY SourceZ}swremove.hosts_with_depots = { Source1 Source2 Source3}

Multiple host names must be separated by a space. You must edit thisfile manually to add or delete hosts and depots. If your list of hosts will fiton one line, you do not need to delimit the list with brackets ({}).

If there are no hosts specified in the defaults.hosts file, only the localhost and default depot path appear in the object lists.

Clicking on the Source Depot Path button will bring up a list ofregistered depots on the source host. You can highlight one of the depotsand press OK and it will appear in the Specify Source Dialog. You can alsomanually enter a depot path in the text box next to the button.

Adding DepotsSelecting depots for copying involves a source host and target depot pathpair. For example, on the command line, depots are specified with the[host][: ][/ depot_path] syntax. The same is true in the GUI/TUI.

If a target depot specified does not exist, the system creates a new depot.

Managing Sessions - The File MenuThe Menubar for the Software Selection Window has five activities: File,View, Options, Actions, and Help.

Each of these choices provide additional pulldown menus for moreactivities. Placing your mouse cursor on the appropriate Menu choiceand clicking the left mouse button causes additional menus to appear.

Each invocation of a command is considered a session. When you invokea command, it automatically saves the current command options, sourceinformation, software selections and host designation before the taskactually starts. The File Menu, which is common to all GUI windows,manages these session files.

Chapter 2 45


A session file, which is used in the -C or -S session file option describedin “Syntax” on page 25, can be recalled and re-executed if you often usethe same functionality. All selections are always saved in$HOME/.sw/sessions/<swcommand>.last file just before starting theactual installation.

At the end of each session the system will overwrite the previous sessionfile. If you want to save a session file for use later, you must rename thatsession file.

Here is an example of a session file:

# swinstall session file## Filename /users/fred/.sw/sessions/swinstall.last# Date saved 05/26/93 15:59:41 MDT

swinstall.allow_downdate = trueswinstall.allow_incompatible = falseswinstall.allow_multiple_versions = falseswinstall.autoreboot = falseswinstall.autorecover_product = falseswinstall.compress_files = falseswinstall.create_target_path = true..

The session file uses the same syntax as the defaults files(command.option=value). Session file values are, in turn, overridden bythe corresponding command line options, if they are specified. See“Advanced Topics for swinstall and swcopy” for more information ondefaults.

For a description of each menu choice in the Menubar, click on a specificmenu choice or use the arrow keys to highlight a particular menu choiceand press the [f1] key on your keyboard. This brings up a Help Screenthat provides additional information on that menu choice.

Changing Preferences - The View MenuThe Graphical and Terminal User Interfaces can be modified to fit yourindividual display requirements or view preferences. The View menumanages these view preferences by providing a Columns Editor tocustomize the window by changing the names and arrangement of theitems in the Object List. The Columns Editor is accessed through theView–>Columns... menu choice. Changes you make can also be saved(View–>Save View as Default) and are treated as the default the nexttime you invoke the command.

46 Chapter 2


You can change your Software View (in the Software Selection Window)with the Change Software View menu choice or the Change SoftwareFilter button. You can specify Bundle, Product or Bundle Category views(that is, which level of the software object hierarchy you want to displayat the topmost level). You can also sort your list of selections in a varietyof different ways. Sorting is specified in a separate Sort Dialog.

Changing Options - The Options MenuThe Options menu lets you change the default options file that controlscommand behaviors and policies. This is the same as editing the defaultsoptions file /var/adm/sw/defaults or $HOME/.swdefaults . For acomplete description of the Options Editor and how to change optionswith this dialog, see the section “Advanced Topics for swinstall andswcopy”.

Choosing Software - The Actions MenuWhen you have specified the host, source and depot (or shared_root), youare ready to select software to install or copy. Software is selected fromthe Object List by highlighting items and then invoking the Mark ForInstall (or Copy) menu choice. In the TUI, you can also use the m and u

keys to mark and unmark highlighted objects.

The Marked? flag in the Object List is automatically updated to “Yes” toreflect the selection. An additional flag - “Partial” - is provided to showthat only some component of the software selection has been selected forthe install.

Chapter 2 47


Figure 2-2 Software Selection Window

NOTE Only one version of a product can be selected during a single installationsession.

Once software is selected, the system then provides some additionalcapabilities (via the Actions menu choice):

• Match-What-Target-Has examines your current Installed ProductDatabase to match your existing filesets with new filesets (those withthe same names) that you are going to install. This feature is mosthelpful when you are updating a system to newer versions of thesame software. This feature is controlled by the match_target= option(see Appendix A, “Default Options and Keywords.”).

• Change Source prompts you for a new source selection.

If you elect to pick a new source, a Change Source Dialog Box isautomatically displayed so you can specify another source. You cantype it in or select it from the host and path lists.

• Install (analysis) (or Copy (analysis)) launches the next phase(analysis).

48 Chapter 2


Also in the Actions menu:

• Open Item or Close Level lets you see the contents of a selected objector close it. In the TUI, pressing Return opens a highlighted object.

• Manage Patch Selection lets you select from a list of patches toinstall, select filters for patches, and set other patch options. (See“Installing Patches Interactively” below for more information.)

• Show Description of Software displays more information on theselected software.

• Mark or Unmark marks or unmarks software for an operation.

• Change Product Location lets you revise the software source.

• Add New Codeword lets you add a new codeword. (This option isavailable if SD-UX detects that the source contains protectedsoftware.

Opening a Software SelectionThe Software Selection Window Object List is a hierarchical object list.That is, each object in the list may be opened to show its contents. Forexample, to see the subproducts in a particular product, you can openthat product by double clicking on the object with your mouse. In theTUI, move the cursor to the item you want to open and press Return . TheObject List then shows a listing of the subproducts for that product. Ifyou want to open the subproduct, double click on it and its filesets aredisplayed. Objects that have an arrow (–>) after the name can be openedto reveal other items.

To close an object and return to the previous list, double click on the firstitem in the list (. .(go up) ). In the TUI, you must use Close Level inthe Actions menu or press Return while highlighting the (. .(go up) )item.

When the product is opened, all of its subproducts (and filesets that arenot part of a subproduct) are shown in the list. At the product level, onlyproducts are listed together. If the software_view is “Bundle” and thebundle is opened, all HP-UX OS products that are wholly or partiallycontained in the bundle will be shown. When one of the products isopened, only subproducts and filesets in the open product and openbundle are shown.

Chapter 2 49


Getting More InformationThe first line of the Message Area is used to show which source has beenchosen. The second line of the Message Area displays where the softwarewill be installed or copied using the [host][: ][/ depot] syntax. These linescan be modified with the Change Source menu choice under the Actionsmenu. If an error occurs when the source is read, the Change SourceDialog is automatically displayed for input.

The Object List shows the software's attributes (Name, Revision,Information, Size (Kb), Architecture and Category). The Show SoftwareDescription menu choice also provides more information.

Choosing Install analysis... (or Copy - analysis) in the menu moves you tothe next phase of the process by opening the Install (or Copy) AnalysisDialog. If software selections or host selections have not been made, anerror box gives instructions on what items still need to be selected beforethe Analysis Dialog appears. The Software Selection Window remainsopen so you can examine your selections at any time. Canceling theAnalysis will also return you this window to change selections.

Analyzing Your Installation Or CopyWhen the Analysis Dialog appears, analysis checks are automaticallystarted on the selected target and source.

Figure 2-3 Analysis Dialog

50 Chapter 2


The buttons in the Analysis Dialog let you investigate the logfile fordetails on the process, display more information about a product, checkdisk space analysis or restart the analysis.

Analysis Progress and ResultsThe Status column in the Analysis Dialog shows the progress and theresults of the Analysis Phase. The possible values for the Status are:“Analyzing Targets”, “Analyzing Software”, “Finishing Analysis” and“Ready”.

When the Analysis is done, the status for any host will either be “Ready”or “Excluded from task”. If any of the selected software can be installedonto the host, the status will be “Ready”. If none of the selected softwarecan be installed onto the host, status will be “Excluded from task”.

Here is a summary of the status results:

Status Explanation

Ready There were no errors or warnings during analysis. Theinstallation or copy may proceed without problems.

Ready withWarnings Warnings were generated during the analysis. Errors

and warnings are logged in the logfile. To see thelogfile, press the Logfile button.

Ready withErrors At least one product selected will be installed or copied.

However, one or more products selected are excludedfrom the task because of analysis errors. Errors andwarnings are logged in the logfile. To see the logfile,press the Logfile button.

Communicationfailure

Contact or communication with the intended target orsource has been lost.

Excluded due to errors

Some kind of global error has occurred. For example,the system might not be able to mount the file system.See the Logfile for details.

Chapter 2 51


Disk SpaceFailure The installation (or copy) will exceed the space

available on the intended disk storage. For moredetails, press the Disk Space. button.

The Products Ready column shows the number of products ready forinstallation or copy out of all products selected. These include:

• products selected only because of dependencies

• partially selected products

• other products and bundles that were selected.

See the section “Advanced Topics for swinstall and swcopy” for moreinformation regarding dependencies.

Only “Ready” products are shown. Bundles may also be ready. If theyare, their products are reflected in the product contents and list.

A product may be automatically excluded from the task if an error occurswith the product. The host is automatically excluded from the task onlyif ALL products and bundles have been excluded.

Getting More DetailsThe Product Summary button in the Analysis Dialog gives additionalinformation regarding the product (or bundle) and provides a ProductDescription button that displays information about dependencies,copyright, vendor, etc.

The Logfile button presents a scrollable view of the information that iswritten in the logfile.

The Disk Space button shows the file system mount point, how muchdisk space was available before the installation, how much will beavailable after the operation, and what percent of the disk's capacity willbe used. It also shows how much space must be freed to complete theoperation.

52 Chapter 2


Figure 2-4 Disk Space Analysis Dialog

Projected ActionsWhen you press the Product Summary button in the Analysis Dialoganother dialog appears that gives you additional information about theproduct and the operation. The Projected Actions column describes whattype of installation or copy is being done. All actions are listed if morethan one applies. For example, a product may be a New Install (Copy)and an Update (some filesets are new, some are an update). The possibletypes are:

Action Explanation

New Install(Copy) The product does not currently exist on the host. This

product will be a new installation or copy.

Reinstall(Recopy)

Some parts of the product already exist on the host (atthe configured location). Note that this effect is onlypossible if reinstall=true. Otherwise, this same product

Chapter 2 53


would be skipped. See Appendix A, “Default Optionsand Keywords,” for more information on the reinstalloption.

Update An older version of the product already exists on thehost (at the configured location) and the selectedcomponent will be an update to the existing product.

Downdate (allow previous versions)

A newer version of the product already exists on thehost (at the configured location) and the selectedproduct will be a older version of the existing product.Note that this effect is only possible ifallow_downdate= is set to “true”. Otherwise, this sameproduct would be excluded because of a downdate error.See the section Appendix A, “Default Options andKeywords,” for more information on theallow_downdate option.

MultipleVersion No component of the product currently exists on the

host at the configured location, but some version of theproduct does exist at some other location. If installed,this product creates a multiple version of the producton the host. (Note that this effect is only possible if theoption to allow_multiple_versions is “true”. Otherwise,this same product would be excluded because of amultiple version error.) See section “Advanced Topicsfor swinstall and swcopy” for more information on theallow_multiple_versions option.

Skipped The product will not be installed or copied because of acondition that is NOT considered an ERROR. Forexample, the same product may already be installed onthe target (and reinstall=false)

Excluded The product will not be installed because of someanalysis phase errors. See the logfile for details aboutthe error. Current reasons a product would be excludedfrom the installation are:

• the checkinstall script failed for the product or afileset in the product

54 Chapter 2


• installing the product at the configured locationwould create a multiple version andallow_multiple_versions is set to “false”.

• the product depends on another product that hasalso been excluded because of errors, or was notselected and is not installed. See the section“Advanced Topics for swinstall and swcopy” formore information about dependencies.

If a global error occurs, e.g., a disk space error occurs or file systems can'tbe mounted, all products would be excluded. After the installation theResult will show:

Result Explanation

Installed The product was successfully installed, but notautomatically configured.

Configured The product was successfully installed ANDconfigured.

Corrupt Because of errors during the execution phase, theproduct was not completely installed. The product isnow corrupt and cannot be used.

After a copy has completed, the Copy Summary also displays the state ofthe product - AVAILABLE or CORRUPT. The AVAILABLE state is themost common.

The Summary column shows any warnings or errors that occurred.

Seeing the LogfileThe Logfile contains detailed information about the installation or copyprocess. If the current host is still in Analysis Phase, the logfile isupdated periodically with the in-coming results. Pressing the Logfilebutton in the Analysis Dialog displays the Logfile.

Moving the scrollbar at the right side of the Logfile Dialog controlsscrolling. By default, when the Logfile Dialog is first opened, Automaticscrolling is toggled on and the text of the logfile continually scrolls up asnew information is added. The old information scrolls off the top of thelist while the new information is added to the bottom of the list. You mayturn automatic scrolling off by clicking on the Automatic scrolling buttonor by moving the scrollbar),

Chapter 2 55


When automatic scrolling is turned off, the new information is still addedto the bottom of the list but the list itself does not scroll. In this way, youcan move to a particular place in the logfile and not be bothered by theautomatic scrolling.

A source depot audit log also exists. See “Using the Source Depot AuditLog” for more information.

Analyzing Disk SpaceThe Disk Space button in the Analysis Dialog brings up a Disk SpaceAnalysis Window that displays the status of the file systems on yourdisk. It shows the file system, the amount of space available on the diskBEFORE you attempted to load the software, how much room will beavailable AFTER the installation is completed, the capacity remaining,and how much free disk space is required (if any).

Opening the software (via the Open Item menu choice in the Actionsmenu) and double clicking on one of the filesets in the software will tellyou the projected size of fileset on this file system and what the changewill be in + or - Kbytes.

Installing/Copying the Product - the Install (Copy) Dialog

If the host has a status of Ready, you can press OK to start theinstallation or copy. The Analysis Dialog is then replaced by the Install(Copy) Dialog and a confirmation dialog appears explaining that once theload is started, you cannot return to the Selection or the Analysis phase.If you say “No” in the Confirmation Dialog, you return to the analysis.The installation or copy has not started and no Install or Copy Dialog ispresented.

Before the Copy phase is started and if you are copying from a tape, acheck is made to detect if the source tape will need to be changed duringthe phase. If the source tape must be changed, a Final Copy Dialognotifies you.

The Install or Copy phase may be suspended if an error occurs in a scriptwhich causes the load to be suspended. For this situation, the ResumeCopy/Install and Abort Copy/Install menu items are available. There arealso Logfile and Product Summary buttons so you can see the results.The resume and abort buttons are not shown when the functions are notavailable.

Only the host on which software is being installed or copied is displayedin the Install (Copy) Window.

56 Chapter 2


Figure 2-5 Install Dialog

The Resume button allows you to continue the install process if it issuspended. The install phase may suspend if:

• a tape change is needed (for multi-tape media),

• file loading fails,

• customization for kernel-related filesets fails or

• building a new kernel fails.

If the install phase suspends on a host, fix the problem(s) and continuethe install phase.

Monitoring the Install or Copy ProcessThe Status row displays the progress and the results of the phase. Thepossible Status attributes and their meanings are:

Table 2-2 Install Status

Status Meaning

Completed No errors or warnings

Completed with Warnings Warnings

Completed with Errors Errors

User Aborted User Initiated

See Logfile Details are available on Logfile

Chapter 2 57


The Object List displays other install status attributes:

• The name of the target.

• The name of the software currently being loaded.

• The estimated time (in minutes) remaining to complete the InstallPhase.

• The total number of Kbytes already installed.

If the Install (Copy) Phase is suspended on a host, a warning dialog isdisplayed to notify you that the install has been suspended.

When the Install (Copy) Phase completes on the host, a dialog isdisplayed to notify you that the task is completed. At this point, you may:

• review all selection windows,

• display details on any target host,

• save the session before exiting,

• start a new session,

• recall a session or

• exit.

58 Chapter 2

Installing and Copying SoftwareAdvanced Topics for swinstall and swcopy

Advanced Topics for swinstall andswcopyThe topics discussed in this section are for those who have a firmunderstanding of the SD-UX commands and want more control overtheir installation or copy process.

Using swinstall to Perform an OS UpdateBefore using swinstall to perform an OS update, you must get thelatest version of SD-UX from the new OS media. This process andadditional instructions for using swinstall are described in AppendixC, “Replacing or Updating SD-UX,” on page 355.

For more information on updating HP-UX or SD-UX from the media,refer to Installing and Updating HP-UX 10.x (B2355-90126).

NOTE You cannot use a tape device (DAT) on a remote host as a source becauseyou cannot control (change tapes, rewind, etc.) that remote device.

CAUTION Ensure that the booted kernel is /stand/vmunix before installing anykernel software. The swinstall process assumes that the system hasbeen booted using the kernel at /stand/vmunix . Installing kernelsoftware or performing an operating system update with another kernelmight result in loss of data or other errors.

CAUTION Due to the complexities of the preinstall and postinstall scriptsassociated with all products delivered as part of HP-UX, autorecovery ofthese products is not supported. All HP-UX products have preinstall andpostinstall scripts without accompanying undo scripts. Consequently, donot change the autorecover_products option to “true” prior to installingany HP-UX software.

If the software uses no preinstall or postinstall scripts or has theappropriate undo scripts, autorecover will work.

Chapter 2 59


Required OptionsAs of HP-UX 11.0, there are two new required default options forperforming an OS update with swinstall (you must also include theseparameters when invoking the swinstall GUI):

-x os_name

-x os_release

See Appendix C, “Replacing or Updating SD-UX,” on page 355 for moreinformation.

New and Old Directories, Files, and LinksWhen you use swinstall to update or install newer (later) versions ofsoftware that already exist on your system, SD-UX treats the new andold files, directories and symbolic links as indicated in the following lists.

• Regular files and directories on the media:

• If the file or directory to be installed does not exist on the target,SD-UX creates it and installs the file (or directory and contents)from the media to the target.

• If a file with the same name already exists on the target, SD-UXoverwrites that file with the new one. In this case, previous filecontents are lost. Note that the new file may or may not be thesame size as the old one.

• If the object to be loaded is a file, and a directory by the same namealready exists on the local host, SD-UX renames the old directoryand installs the new file in its place (that is, replacing a directorywith a file).

• If the object to be loaded is a directory and a file by the same namealready exists on the local host, SD-UX renames the file on thesystem and creates a directory at that location (that is, replacing afile with a directory).

• Symbolic links on the media:

• Symbolic links are shipped unresolved. If the link's target does notexist on the system, the result of installing the link is anunresolved symbolic link.

60 Chapter 2


• If the symbolic link target is an existing file or directory on thesystem, the contents of the target file or directory are overwritten.Mode of the link target is set to the mode of the file on the sourcemedia. Owner and group of the link target are unchanged.

• If a directory link's target is a file on the system, SD-UX renamesthe file into a directory at the target path.

• If a file link's target is a directory on the system, SD-UX removesthe target directory and its contents and installs the new file tothe target path.

• Linking to another symbolic link - if the link is unresolved orresolves to a file or directory it is handled as above.

Symbolic Link LoopsA pre-existing symbolic link loop will cause an error message in theswinstall process regardless of the path it takes over hard mountedvolumes. However, if the loop is the result of installing another symboliclink, there will be no error until a process attempts to write to it. Fileload order is important in determining if a symbolic link loop will cause aproblem with SD-UX operations.

For example, suppose you have a file called Alpha on your system andBeta is a symbolic link to Alpha . During an update, you attempt toinstall a new file called Beta that has a link to it called Alpha . Alpha isloaded from the media first. Since Alpha is a symbolic link to Beta , thefile at Alpha is overwritten and there is now a loop. When the new Betais loaded, it fails, having encountered the loop.

Make sure the load order on your update does not cause these link loopsand also make sure that links are not pointing to each other after theupdate.

Chapter 2 61


Installing to an Alternate RootSoftware is usually installed relative to the primary root directory (/)but it can also be installed relative to an alternate root directory.

Installing to an alternate root is usually used to set up a shared rootsource to be used later for installing clients with HP's SystemAdministration Manager (SAM).

The automatic configuration and compatibility filtering that is part ofthe swinstall command is not performed when installing to analternate root.

62 Chapter 2


Interactively Changing Default OptionsDefaults can also be edited directly in the /var/adm/sw/defaults or$HOME/.swdefaults files or changed using the GUI Options Editor,available from the Change Options choice in the Options menu.

NOTE Using this Options Editor does NOT change the option permanently. Theoption is only changed for the duration of the session. To change optionspermanently, you must edit the defaults file or save your session for laterreuse (see “Managing Sessions - The File Menu” on page 44).

Use caution when changing default option values. They allow usefulflexibility but can produce harmful results if changed to a value that isinappropriate for your needs. Use the On-Line Help or consult theappendix Appendix A, “Default Options and Keywords,” in this manualto understand fully each option and value.

The defaults and options that apply to swinstall and swcopy areshown in “Install Defaults” on page 35. Figure 2-6 shows the OptionsEditor dialog window.

Chapter 2 63


Figure 2-6 Options Editor Dialog

In this dialog, each default or policy option is shown in the left column ofthe Editor and to the right of each option is a push button. The “True” or“False” values for each option are listed in a menu hidden beneath thepush button. To select a value, push the button with the left mousebutton and hold it down. A pop-up menu replaces the push button whilethe mouse is suppressed. While still holding down on the mouse button,move the cursor to the desired value. Release the mouse button. Thepop-up menu disappears and the push button is re-labeled with thedesired value.

64 Chapter 2


The OK button may bring up a warning box if any of the options in theOptions Editor have been modified and there are existing softwareselections, that is, if the Software Selection Window has been displayedpreviously and selections have already been made. If no options havebeen changed, selecting the OK button closes the Options Editor.

The Cancel button closes the Options Editor without applying anychanges to the options.

For a description of each default and its values, place the focus on thedefault and press f1.

Chapter 2 65


Compressing Files to Increase PerformanceSD-UX processes pass large amounts of data back and forth over thenetwork, from depots to hosts, which might slow down networkperformance. The compress_files option can improve performance by firstcompressing files that are to be transferred. This can reduce networkusage by 50% depending on the type of files. Binary files compress lessthan 50%, text files generally compress more. Improvements are bestwhen transfers are across a slow network (approximately 50Kbytes/secor less).

If set to “true”, the compress_files= option will compress files, if notcompressed previously by SD-UX, before transfer from a source. You mayalso choose the compression type and compression command to use whencompressing and uncompressing files.

This option should be set to “true” only when network bandwidth isclearly restricting total throughput. If it is not clear that this option willhelp, compare the throughput of a few install or copy tasks (both withand without compression) before changing this option value. SeeAppendix A, “Default Options and Keywords,” for more information oncompression defaults.

66 Chapter 2


Software DependenciesSoftware that depends on other software to install or run correctly isconsidered to have a dependency. You can define how thosedependencies are handled at installation. Dependency handling inswinstall and swcopy is affected by the enforce_dependencies=default, see Appendix A, “Default Options and Keywords,”. In anupgrade to a new operating system version, it is strongly suggested thatthe enforce_dependencies default be set to “true”.

Another default option that regulates dependencies is theautoselect_dependencies=true option. It determines if the system shouldautomatically mark software for installation or copying based onwhether it meets dependencies. Dependencies and their related softwaremust BOTH be marked for installation or copying.

Software vendors can define two types of dependencies: corequisitesand prerequisites. Dependencies can be specified between filesetswithin a product, including expressions of which revisions of the filesetmeet the dependency. Dependencies can also be specified between afileset and another product (the minimum subset of that product is aparticular fileset within that product). Expressions for revisions andother product attributes are supported.

Dependency Explanation

Corequisites A corequisite relationship states that one filesetrequires another to operate correctly, but DOES NOTIMPLY ANY LOAD ORDER.

Prerequisites A prerequisite relationship states that one filesetrequires another to be installed and/or configuredcorrectly before it can be installed or configuredrespectively. Prerequisites DO control the order ofoperations.

If a dependency exists and there is more than one available object thatresolves it, the latest compatible version that resolves it is automaticallyselected during the Selection Phase.

For a dependency to be resolved during swinstall or swcopy (if it isavailable from the source), it must be:

• complete (if the dependency is an entire product or subproduct itmust completely exist in the source)

• in the proper software state on the source (that is, AVAILABLE)

Chapter 2 67


• free of errors (for example, no incompatibility errors).

If the dependency is NOT available from the source during swinstallor swcopy (or during swverify or swconfig ), for SD-UX to resolve thedependency it must:

• exist on the target system

• be complete (if the dependency is an entire product or subproduct itmust be completely installed)

• be in the proper software state (the dependency must beCONFIGURED if the software dependent on it is to be installed andconfigured, INSTALLED if software dependent on it is to be installedbut not configured, or AVAILABLE if the software dependent on it isto be copied) and

• be free of errors (for example, no incompatibility errors).

The enforce_dependencies option controls the behavior of the agent independencies.

To list the state of a dependency:

swlist -a state <fileset_name>or (for a depot)swlist -d -a state <fileset_name> @ /var/spool/sw

To list the complete contents of a product dependency:

swlist -a all_filesets <product_name>

To list the complete contents of a subproduct dependency:

swlist -a contents <product_name>

You can combine all these with multiple -a options (and the -d option ifyou are listing from a depot), see Chapter 5, “Listing Software,” for moreinformation on listing attributes.

You can also find out what an object's dependencies are by pressing theDependencies ... button in the Software Description Dialog (see “GettingMore Information”).

68 Chapter 2


Compatibility Filtering and CheckingBy default, swinstall restricts the installation of incompatiblesoftware and automatically filters bundles, products, and filesets on thesource. In the interactive interface, only those items compatible with thehardware and operating system of the marked targets are shown in theSoftware Selection Window.

For example, if have selected a target system with HP-UX version 10.20,the Software Selection Window displays only the software objectscompatible with HP-UX 10.20.

To be compatible:

• The architecture of the hardware matches that required by thesoftware (determined by the system's uname parameters).

• The OS version is the proper one for the software.

The actual check for incompatible software is performed during theanalysis phase.

The following rules govern compatibility filtering:

• No compatibility filtering or checking is performed in swcopy becausejust as your network may include many different host machines andarchitectures, a depot may also contain a wide variety of productsdesigned for varied computers or operating systems.

• Note that when installing to alternate root file systems, compatibilityfiltering does not apply. HP-UX cannot assume the stand-alonesystem will be identical to the hardware and operating system of thealternate root system. It is up to you to know what will be compatiblefor the alternate root.

• Only those products compatible with the hardware and operatingsystem of ALL selected hosts are shown in the Object List.

Compatibility filtering and checking are controlled by theallow_incompatible default option and depend on the host's unameattributes (machine_type, os_name, os_release, os_version).

In the default mode of allow_incompatible=false, swinstall restrictsthe installation of incompatible software and automatically filters theproducts on the source.

When this option is “false”, the Software Selection Window contains thismessage:

Chapter 2 69


Only software compatible with the target is available.

If allow_incompatible=true, swinstall allows the installation of anysoftware. All products on the source are displayed for selection.

When this option is “true”, the Software Selection Window contains themessage:

All software on the source is available for selection.

CAUTION Installing incompatible software may leave the target system unusable.HP strongly advises that you do not install software that is incompatiblewith the host.

70 Chapter 2


Installing Multiple VersionsHaving multiple versions (and copies) of a software product installed atvarious hosts on the network is common because users may not all beusing the same version or even running on the same machine platform.At least one copy or different version could exist on each host.

With swcopy , multiple versions of products are inherently possible in adepot. No special handling or checks are required.

With multiple version support, you can manage a diverse environmentand even have multiple versions on a single host by installing relocatableversions into different product directories on the host. In addition toallowing different users to use different versions of the software,multiple version support also allows multiple copies of the same versionin different locations (locatable products) if the software supports it.This may be needed if some users want significantly differentconfigurations of the same software.

You can decide whether to allow multiple versions or not by controllingthe allow_multiple_versions default option. If set to “false”, installed orconfigured multiple versions (that is, the same product, but a differentrevision, installed into a different location) are not allowed. Whilemultiple installed versions of software are allowed, multiple configuredversions are not recommended.

Managing multiple versions of a software product on your systemrequires close attention to the cross-product dependencies that may existfor each version. When installing multiple versions, make sure you alsoinstall multiple versions of the cross-product dependencies. If thedependencies are not relocatable and each version you want to installdepends on a different version of the same product, multiple versions ofthe original product cannot be installed.

Once a multiple version is installed into a location, it is managed byspecifying the product attribute (in contrast to specifying depot softwareby product tags or by other version attributes such as revision andarchitecture). This allows old and new versions of software to be installedat the same time and both configured, if the software supports it.Multiple installed version supports both backing out of a defectiveversion (by removing the new version and reconfiguring the old version,if necessary,) and training and migration of users to the new version attheir own pace.

Chapter 2 71


Unauthorized, privately installed copies are avoided by controllingaccess to the IPD and restricting the use of the swinstall tool.

Installing Software That Requires a SystemRebootSoftware packaged with the is_reboot=true attribute requires the host tobe rebooted after the software is installed. However, when installing toalternate root file systems, the host will not be rebooted.

If a local installation is done that entails a reboot, the system reboots thetarget and, more importantly, the controller, so there is no process left toreport SUCCESS or FAILURE. SD-UX does not do a reconnect afterreboot.

To find out if a software product requires the local host to be rebooted,get a description of the software either from the Software SelectionWindow, using the menu item Show Description of Software, or from theAnalysis Dialog using the Product Summary and Product Descriptionpushbuttons.

72 Chapter 2


Installing Patches InteractivelyThe swinstall GUI lets you perform patch installation interactively.See Chapter 8, “Managing Patches,” for complete details on patches andusing the swinstall GUI patch features.

Using the Source Depot Audit LogIf both the source and target machines are updated to HP-UX version10.30 or later, the system administrator at the source depot machine canset the swagent.source_depot_audit option to track which userpulls which software from a depot on the source machine and when thesoftware is pulled.

A user running swinstall or swcopy from a target machine cannot setthis option; only the administrator of the source depot machine can set it.

The system administrator at the source depot machine controls theauditing feature by setting the swagent.source_depot_audit optionin the /var/adm/sw/defaults file. The default value is “true”(auditing turned on). The auditing feature creates the swaudit.log fileon the source depot (for writable directory depots) or in /var/tmp (fortar images, CD-ROM, or other nonwritable depots).

You can view the audit log file from the swlist interactive user interface(invoked with swlist -i -d ). See Chapter 5, “Listing Software,” formore details.

The audit log can display in different languages if the appropriate SDmessage catalog is present and the proper system variables are set. Forexample, you can view the source audit information in Japanese duringone session, then view the same information in English in anothersession.

Chapter 3 73

Configuring and Verifying Software

3 Configuring and VerifyingSoftware

The swconfig command lets you explicitly configure, unconfigure andreconfigure software products that are installed on a local host.

The SD-UX swverify command verifies available (copied), installed orconfigured software products on the specified host.

Topic Page

“Configuring Your Installation (swconfig)” 74

“Verifying Your Installation (swverify)” 85

74 Chapter 3

Configuring and Verifying SoftwareConfiguring Your Installation (swconfig)

Configuring Your Installation (swconfig)The swconfig command lets you explicitly configure, unconfigure andreconfigure software products that are installed on a local host byexecuting the configure script . These scripts are only executed onthe host that will actually be running the software. A fileset can alsoinclude an unconfigure script to undo a configuration. For moreinformation on scripts, see Chapter 11, “Using Control Scripts.”

You can use the swinstall and swremove commands to perform manyconfiguration or unconfiguration tasks. However, the swconfigcommand lets you work independently of these commands. For example,you can configure or unconfigure hosts that share software from anotherhost where the software is actually installed. swconfig can also beuseful when a configuration fails, is deferred, or must be changed.

The swconfig command runs only from the command line interface.There is no Graphical or Terminal User Interface for swconfig .

The swconfig command provides the following features:

• It configures the host on which the software will be run. A fileset caninclude a configure script to perform these actions on the host.

The swconfig command also allows software to unconfigure the hoston which it no longer will be run. That is, a fileset can include anunconfigure script that will undo the configuration done by theconfigure script.

The configure and unconfigure scripts are usually run by swinstalland swremove , respectively. They are not run when an alternate rootdirectory is specified. Instead, the swconfig command must be usedafter that software has been made available to client hosts, toconfigure those hosts. Similarly, swconfig must be used on clienthosts to unconfigure those hosts.

Automatic configuration can also be postponed on software installedto the root directory / (for example, when multiple versions areinstalled), by using the defer_configure default.

• It only supports configuration of compatible software, controllablethrough the allow_incompatible default.

Chapter 3 75


• If a fileset relies on another software product for proper operation,that software product must be in a “configured” state and is controlledby the enforce_dependencies option.

• swconfig configures only one version of a fileset at a time,controllable through the allow_multiple_versions default.

• By default, when swinstall installs software relative to the rootdirectory /, it configures that software (controllable through thedefer_configuration default). Software cannot be configured froman alternate root directory (that is, the alternate root directory mustbecome some host's root directory before the software can beconfigured).

• A vendor's configure script is as useful for those operations requiredfor software updates as it is for new installs. The script must also beable to handle reinstallation and should attempt to design-inappropriate error control if data destruction is possible duringdowndates.

• swconfig performs an analysis to see if the requested softwareexists, is in the proper state (“installed”) and prerequisites are (or canbe) met.

• swconfig moves software between “installed” and “configured”states.

NOTE When the swinstall session includes a reboot fileset (such as whenupdating the core HP-UX operating system to a newer release), theconfigure scripts are run as part of the system start-up processes afterthe system reboots.

76 Chapter 3


SyntaxThe syntax for swconfig is:

swconfig [-p ][-u ][-v ][ -c catalog] [-C session_file][-f software_file] [-S session file] [-t target_file][-x option=value] [-X option_file][software_selections] [@target_selections]

Sample ConfigurationsTo configure productA, located in the default depot on the local host:

swconfig productA

To unconfigure the software selections in the file mysoft that areinstalled in the default directory on the local host

swconfig -u -f mysoft

To reconfigure the Omniback product using the default option

swconfig -x reconfigure=true Omniback

To configure a particular version of Omniback:

swconfig Omniback,r=2.0

To configure the C and Pascal products on the local host:

swconfig cc pascal

To configure Product1, use any associated response files generated by arequest script, and save response files under /tmp/resp1 :

swconfig -x ask=true -c /tmp/resp1 Product1

To reconfigure the HP Omniback product:

swconfig -x reconfigure=true Omniback

To configure the version of HP Omniback that was installed at/opt/Omniback_v2.0 :

swconfig Omniback,l=/opt/Omniback_v2.0

To unconfigure the software_selections listed in the file/tmp/install.products on the hosts listed in the file/tmp/install.hosts :

swconfig -u -f /tmp/install.products \-t /tmp/install.hosts

Chapter 3 77


Command OptionsThe swconfig command supports the following options. (Except for the-u option, all swconfig options are a subset of those for swinstall .)

Option Action

-p Preview a configuration task from the command line byrunning it through the Analysis Phase and thenexiting. You can use this option with any other optionsto understand the impact of a command before thesystem actually performs the task.

-u Causes swconfig to unconfigure the software insteadof configuring it.

-v Turn on verbose output to stdout and display allactivity to the screen. Lets you see the results of thecommand as it executes.

-c catalog Specifies the pathname of an exported catalog, whichstores copies of the response file or files created by arequest script (if -x ask=as_needed or-x ask=true ). Response files are also stored in theInstalled Products Database.

-C session file Run the command and save the current option andoperand values to a file for re-use in another session.

-f software file Read a list of software selections from a separate fileinstead of from the command line. In this software file,blank lines and lines beginning with # (comments) areignored. Each software selection must be specified on aseparate line. For an example of a software selectionfile, see “Command Operands” on page 31.

-S session file Run the command based on values saved from aprevious session.

-t target file Specifies multiple shared roots on the local host. -treads a list of these targets from a separate file insteadof from the command line.

-u Causes swconfig to unconfigure the software insteadof configuring it.

78 Chapter 3


-v Turns on verbose output to stdout . (The swconfiglog file is not affected by this option.) Verbose output isenabled by default.

-x option=value Specify a value to override a default value or a value inan options file (see the -X option file option). Seesection “Changing Default Options” for moreinformation on changing defaults.

-X option file Specifies a new option file. The default values forsystem options are provided in the file/var/adm/sw/defaults . You can also provide apersonal option file, $HOME/.swdefaults . This optionfile overrides those values in the system defaults file.For a complete listing of system options, see the file/usr/lib/sw/sys.defaults . This file lists thepossible values and behaviors for each option for eachcommand. See Appendix A, “Default Options andKeywords,” for a complete listing and description ofthese defaults.

Command OperandsThe swconfig command supports the standard software_selectionssyntax. For more details on software selection syntax and an example ofa software selection file, see “Software Selections” on page 31.

Chapter 3 79


Changing Default OptionsIn addition to the command-line option listed above, several swconfigbehaviors and policy options can also be changed by editing extendedoption and default values found in the system-wide defaults file:/var/adm/sw/defaults

or in the user-specific defaults file:

$HOME/.swdefaults

Values in these files are specified using the command.option=valuesyntax. For example:

swconfig.agent_auto_exit=true

Table 3-1 Configuration Default Options

See Appendix A, “Default Options and Keywords,” for a complete listingand description of default options.

agent_auto_exit=true logdetail=false

agent_timeout_minutes=10000 logfile=/var/adm/sw/swconfig.log

allow_incompatible=false loglevel=1

allow_multiple_versions=false mount_all_filesystems=true

ask=false reconfigure=false

autoremove_job=false rpc_binding_info=ncacn_ip_tcp:2121ncadg_ip_udp:[2121]

autoselect_dependencies=true rpc_timeout=5

autoselect_dependents=false select_local=true

controller_source= software=

enforce_dependencies=true targets=

job_title= verbose=1

log_msgid=0 write_remote_files=false

80 Chapter 3


Using Session FilesEach invocation of the swconfig command defines a configurationsession. The invocation options, source information, softwareselections, and target hosts for this session are saved before theinstallation or copy task actually commences. This lets you re-executethe command even if the session ends before proper completion.

Each session configuration is automatically saved to the file$HOME/.sw/sessions/swconfig.last . This file is overwritten ateach invocation of swconfig .

You can save a session configuration to a specific file by executingswconfig with the -C session_file option.

If you do not specify a specific path for the session file, the defaultlocation is $HOME/.sw/sessions/ .

To re-execute a session file, specify the session file as the argument forthe -S session__file option of swconfig .

Note that when you re-execute a session file, the values in the session filetake precedence over values in the system defaults file. Likewise, anycommand line options or parameters that you specify when you invokeswconfig take precedence over the values in the session file


Chapter 3 81


Understanding the Configuration ProcessThe configure process also has three phases:

• A Selection phase in which the local host resolves the list of softwareto configure

• An Analysis phase where the process goes through analysis to ensurethat the software selected can be configured successfully (existence,prerequisites, etc.)

• A Configure phase (the actual software configuration) where theconfigure or unconfigure scripts are executed and the software's stateis changed between “installed” and “configured” (or “unconfigured”).

Selection PhaseFor information on how to start a session, specify hosts, select softwareand specify products see Chapter 2, “Installing and Copying Software,”for complete information.

Analysis PhaseThis phase takes place on the local host. The analysis phase occursbefore the loading of files begins and involves executing checks todetermine whether the installation should be attempted. The load phasecannot be entered if there are any errors from the analysis phase.

NOTE No aspect of the local host's environment is changed (except wherenoted) during the analysis phase. Running the “preview” option (-p ) onthese tasks will not have a negative effect.

You can run the preview option to see if there are any errors or warnings.You can also return to the selection phase at this point and changeselections. Errors in the analysis phase will only exclude those productsthat had errors in them. If only warnings occur, the task will continue.

The sequential analysis tasks on the host are:

1. Initiate analysis

2. Process software selections

Get information from the Installed Product Database and check forcompatibility.

82 Chapter 3


The system checks that all software is compatible with the host'suname attributes. This check is controlled by the default optionallow_incompatible . If it is set to “false,” the system produces anerror; if set to “true,” it produces a warning.

3. Check state of versions currently installed

If the product is “non-existent” or “corrupt”, the task issues an errorthat says the product cannot be configured and to use swinstall toinstall and configure this product.

If the versions currently installed are not “configured” and if the -uoption is set (unconfigure), the system issues a note that the selectedfile or fileset is already unconfigured.

If the state of versions currently installed is “configured” (ifconfiguring), the check is affected by the reconfigure option. A notesaying the fileset is already configured and will(reconfigure=true ) or will not (reconfigure=false ) bereconfigured is issued.

4. Check for configuring a second version.

This check is controlled by the allow_multiple_versions option.If it is set to “false,” an error is generated stating that another versionof this product is already configured and the fileset will not beconfigured. If it is set to “true,” the second version will also beconfigured.

5. Check states of dependencies needed.

An error or warning is issued if a dependency cannot be met. This iscontrolled by the enforce_dependencies option. Ifenforce_dependencies is set to “true” the fileset will not beconfigured. If enforce_dependencies is “false,” the fileset will beconfigured anyway.

If the dependency is a prerequisite, the configuration will likely fail.

If the dependency is a corequisite, the configuration of this fileset willlikely succeed, but the product may not be usable until its corequisitedependency is installed and configured.

Chapter 3 83


Configure PhaseThe configure phase is entered once the selections have passed theanalysis phase. This takes place on the local host.

The sequence of configure tasks is shown below. Products are ordered byprerequisite dependencies, if any. Fileset operations are also ordered byany prerequisites.

1. (Un)configure each product

2. Run each fileset's (un)configure script

3. Update the Installed Product Database to state (“installed” or)“configured”

84 Chapter 3


Executing Configure ScriptsIn this step, swconfig executes vendor-supplied configure orunconfigure scripts. The purpose of configuration is to configure the hostfor the software and configure the product for host specific information.For example, software may need to change the host's .rc setup, or thedefault environment set in /etc/profile . Or you may need to ensurethat proper codewords are in place for that host or do some compilations.Unconfiguration reverses these steps.

1. The scripts are executed, checking the return values.

If an error occurs, the fileset is left in the state “installed”. If awarning occurs, the fileset will still be configured.

2. Scripts are executed in prerequisite order.

Configure scripts must also adhere to specific guidelines. For example,these scripts are only executed in the context of the host that thesoftware will be running on, so they are not as restrictive as customizescripts. With the exception of request scripts, configure and unconfigurescripts must be non-interactive.

For more information on scripts, see Chapter 11, “Using ControlScripts.”.

Chapter 3 85

Configuring and Verifying SoftwareVerifying Your Installation (swverify)

Verifying Your Installation (swverify)The SD-UX swverify command verifies available (copied), installed, orconfigured software products on the specified host. swverify also:

• determines whether installed or configured software is compatiblewith the host on which that software is installed.

• makes sure that all dependencies (prerequisites, corequisites) arebeing met (for installed software) or can be met (for copied software).

• executes vendor-specific verification scripts (that is, scripts thattestify to the correctness of the product's configuration) if theinstalled state of the software is “configured”.

• reports missing files, checks all file attributes including permissions,file types, size, checksum, mtime, link source and major/minorattributes.

86 Chapter 3


SyntaxThe swverify command does not feature a GUI. All verify interactionwith the system is done on the command line.

The syntax for swverify is:

swverify [-d |-r ] [-v ] [-C session_file] [-f software_file][-S session_file] [-t target_file] [-x option=value][-X config_file] [software_selections][@target_selections]

ExamplesThe following are examples of some swverify commands:

To verify an installed fileset mysoft.myfileset located on the default depotat myhosts, you would type:

swverify -d mysoft.myfileset @ myhosts

(You could also omit the @ sign and the myhost designation since thesoftware being verified is assumed to be located in the default depot onthe local host.)

To verify the C and Pascal products that are installed on the local host:

swverify C Pascal

To verify the HP Omniback product that is installed on the local host andwatch the process (-v ) on stdout :

swverify -v Omniback

To verify the 2.0 version of Omniback that is installed on the local host at/opt/Omniback :

swverify Omniback,r=2.0 @ /opt/Omniback

Verify a particular version of HP Omniback:

swverify Omniback,1=/opt/Omniback_v2.0

Verify the entire contents of a local depot:

swverify -d \*@/var/spool/sw

Chapter 3 87


Command OptionsThe swverify command options are a subset of those for swinstallexcept the -d option, which verifies software on a depot instead ofinstalled software.

Option Description

-d Operate on a depot rather than installed software.

-r (Optional) Operate on an alternate root rather than / .Verify scripts are not run.

-v Turn on verbose output to stdout and display allactivity to the screen. Lets you see the results of thecommand as it executes.

-C session file Run the command and save the current option andoperand values to a file for re-use in another session.

-f software file Read a list of software selections from a separate fileinstead of from the command line. In this software file,blank lines and lines beginning with # (comments) areignored. Each software selection must be specified on aseparate line. For an example of a software selectionfile, see “Command Operands” on page 31.

-S session file Run the command based on values saved from aprevious installation session.

-t target file Specifies multiple shared roots on the local host. -treads a list of these targets from a separate file insteadof from the command line.

-x option=value Specify a value to override a default value or a value inan options file (see the -X option file option). Seesection “Changing Default Options” for moreinformation on changing defaults.

-X option file Specifies a new option file. The default values forsystem options are provided in the file/var/adm/sw/defaults . You can also provide apersonal option file, $HOME/.swdefaults . This optionfile overrides those values in the system defaults file.For a complete listing of system options, see the file

88 Chapter 3


/usr/lib/sw/sys.defaults . This file lists thepossible values and behaviors for each option for eachcommand.

Command OperandsThe swverify command supports the standard software_selectionssyntax. For more details on software selection syntax and an example ofa software selection file, see “Command Operands” on page 31.

Chapter 3 89


Changing Default OptionsIn addition to the command-line option listed above, several swverifybehaviors and policy options can also be changed by editing extendedoption and default values found in the system-wide defaults file:/var/adm/sw/defaults


$HOME/.swdefaults


swverify.agent_auto_exit=true

Table 3-2 Verification Default Options


agent_auto_exit=true job_title=

agent_timeout_minutes=10000 log_msgid=0

allow_incompatible=false logdetail=false

allow_multiple_versions=false logfile=/var/adm/sw/swverify.log

autoselect_dependencies=true loglevel=1

check_contents=true mount_all_filesystems=true

check_permissions=true reconfigure=false

check_requisites=true rpc_binding_info=ncacn_ip_tcp:2121ncadg_ip_udp:[2121]

check_scripts=true rpc_timeout=5

check_volatile-false select_local=true

controller_source= software=


verbose=1

enforce_dependencies=true

90 Chapter 3


Using Session FilesEach invocation of the swverify command defines a configurationsession. The invocation options, source information, softwareselections, and target hosts for this session are saved before theinstallation or copy task actually commences. This lets you re-executethe command even if the session ends before proper completion.

Each session configuration is automatically saved to the file$HOME/.sw/sessions/swconfig.last . This file is overwritten ateach invocation of swconfig .

You can save a session configuration to a specific file by executingswverify with the -C session_file option.


To re-execute a session file, specify the session file as the argument forthe -S session_file option of swverify , using the above syntax.

Note that when you re-execute a session file, the values in the session filetake precedence over values in the system defaults file. Likewise, anycommand line options or parameters that you specify when you invokeswverify take precedence over the values in the session file


Chapter 3 91


Understanding the Verification ProcessThe software verification process has only two key phases: a selectionphase and an analysis phase.

Selection PhaseFor information on how to start a session, specify the host, selectsoftware and specify products see Chapter 2, “Installing and CopyingSoftware,” for complete information.

Analysis PhaseThe analysis phase for swverify takes place on the host. The host'senvironment is not modified.

The sequential analysis tasks on each host are:

1. Initiate analysis

2. Process software selections

The system accesses the Installed Products Database (IPD) or depotcatalog to get the product information for the selected software.

For installed software, the system checks that all products arecompatible with its uname attributes. This check is controlled by thedefault option allow_incompatible .

If allow_incompatible is set to “false”, the system produces anerror stating that the product is not compatible with the host.

If allow_incompatible is set to “true”, a warning is issued statingthat the product is not compatible.

3. Check states of versions

The swverify command checks for correct states in the filesets(“installed”, “configured” or “available”). For “installed” software, italso checks for multiple versions that are controlled by theallow_multiple_versions option.

If allow_multiple_versions is “false”, an error is produced thatmultiple versions of the product exist and the option is disabled.

If allow_multiple_versions is “true”, a warning is issued sayingthat multiple versions exist.

4. Check dependencies

92 Chapter 3


An error or warning is issued if a dependency cannot be met.Dependencies are controlled by the enforce_dependencies option:

If enforce_dependencies is “true”, an error is generated tellingyou the type of dependency and what state the product is in.

If enforce_dependencies is “false”, a warning is issued with thesame information.

If the dependency is a corequisite, it must be present before thesoftware will operate.

If the dependency is a prerequisite, it must be present before thesoftware can be installed or configured.

5. Execute verify scripts

In this step, swverify executes vendor-supplied verify scripts onlyon installed software.

A verify script is used to ensure that the configuration of the softwareis correct. Possible vendor-specific tasks for a verify script include:

• Determine active or inactive state of the product.

• Check for corruption of product configuration files.

• Check for (in)correct configuration of the product into the OSplatform, services or configuration files.

• Check licensing factors.

Vendor-supplied scripts are executed and the return values generatean error (if 1) or a warning (if 2).

Scripts are executed in prerequisite order.

For more information on scripts, see Appendix 11, “Using ControlScripts.”.

6. File level checks

File level checks are made with swverify for:

• Contents (mtime, size and checksum) for control_files andfiles

• Missing control_files , files and directories

• Permissions (owner, group, mode) for installed files

• Proper symlink values

Chapter 4 93

Registering Software Depots

4 Registering Software Depots

SD-UX automatically registers some depots. For example, swcopyregisters newly created depots and swremove unregisters a depot afterremoving the depot software.

swreg explicitly registers or unregisters depots. For example, you woulduse swreg to:

• Make a CD-ROM or other removable media available as a registereddepot.

• Register a depot created directly from swpackage . (See “RegisteringDepots Created by swpackage” on page 250.)

• Unregister a depot without physically removing it, making the depot“invisible” to other SD-UX commands.

Topic Page

“Registering Your Software (swreg)” 94

94 Chapter 4

Registering Software DepotsRegistering Your Software (swreg)

Registering Your Software (swreg )Just as with any other SD-UX command, swreg requires that youassemble options, targets and defaults into a command line or usecommand options to “point” to files containing targets, default behaviorchanges and other variables.

The swreg command uses the command line interface only. There is noGraphical User Interface for swreg .

SyntaxThe syntax for swreg is:

swreg -l level [-u ] [-v ] [ -C session_file] [-f object_file][-S session_file] [-t target_file] [-x option=value][-X option_file][objects_to_(un)register][@target_selections]

ExamplesTo create a new depot with swpackage , then register it with swreg :

swpackage -s psf -d /var/spool/swswreg -l depot /var/spool/sw

To unregister a specific depot at the local host:

swreg -u -l depot/cdrom

To unregister a CD-ROM depot mounted at /mnt/cd , type:

swreg -l depot -u @ /mnt/cd

To register the same depot (mounted at /mnt/cd on the local host) as adepot to be available on the network, type:

swreg -l depot @ /mnt/cd

(The @ sign is optional on the local host.)

Chapter 4 95


Command OptionsThe swreg command supports the following options:

Option Action

-l level (required)

List all objects at the specified level. Only one level maybe specified. Supported levels are:

root Show the root level (all the roots onthe host).

shroot Show shared roots on the local host.

prroot Show private roots on the local host.

depot Show depots on the local host.

-u Unregister the depot.

-v Cause verbose logging to stdout.

-C session_file Run swreg and save the current option and operandvalues to a file for re-use in another session.

-f object_file Read a list of objects to (un)register from a file.

-S session_file Run swreg based on a previous session.

-t target_file Read the list of target hosts on which to register thedepot or root objects from the target_file instead of (orin addition to) the command line.

-x option=value Set a specific option value to value. Multiple -x optionscan be specified.

-X option_file Read a list of options and behaviors from a separatefile.

96 Chapter 4


Command OperandsThe swverify command supports the standard software selectionsyntax. For more details on software_selections syntax, see “CommandOperands” on page 31.

The software_selections and target_selection operands are:

OperandAction

objects_to_(un)registerSpecifies the path to the object to be registered orunregistered.

target_selections Specifies the absolute pathname of the depot to beoperated on using the host: path syntax.

Chapter 4 97


Changing Default OptionsIn addition to the command-line options listed above, several swregbehaviors and policy options can be changed by editing extended optionand default values found in the system-wide defaults file:/var/adm/sw/defaults .


$HOME/.swdefaults .

Table 4-1 shows the default options supported by swreg . See AppendixA, “Default Options and Keywords,” for a complete listing anddescription of these defaults.

Table 4-1 Registration Default Options

distribution_target_directory =/var/spool/sw

level=

logfile=/var/adm/sw/swreg.log

logdetail=false

loglevel=1

log_msgid=0

objects_to_register

rpc_binding_info=ncacn_ip_tcp:2121 ncadg_ip_udp:[2121]

rpc_timeout=5

select_local=true

targets=

verbose=1

98 Chapter 4


Using Session FilesEach invocation of the swreg command defines a registration session.The invocation options, source information, software selections, andtarget hosts for this session are saved before the installation or copy taskactually commences. This lets you re-execute the command even if thesession ends before proper completion.

Each session configuration is automatically saved to the file$HOME/.sw/sessions/swconfig.last . This file is overwritten ateach invocation of swreg .

You can save a session configuration to a specific file by executing swregwith the -C session_file option.


To re-execute a session file, specify the session file as the argument forthe - S session_file option of swreg .

Note that when you re-execute a session file, the values in the session filetake precedence over values in the system defaults file. Likewise, anycommand line options or parameters that you specify when you invokeswreg take precedence over the values in the session file


Chapter 4 99


Registering DepotsThe registration of depots (and roots) determines which hosts areavailable for software management tasks (that is, which hosts have adaemon/agent running). It enables the controller system to retrieveand present (via swlist ) a list of existing depots or roots from which aselection can be made. Registration information consists of the depot orroot's identifier (its path in the host file system).

Note that registration does not imply access enforcement. Accessenforcement is left to security (see Chapter 9, “Controlling Access toSoftware Objects.”).

AuthorizationTo register a new depot or to unregister-register an existing depot,swreg requires “read” permission on the depot in question and “write”permission on the host. To unregister a registered depot, the swregcommand requires “write” permission on the depot. See Chapter 9,“Controlling Access to Software Objects,” for more information onpermissions.

100 Chapter 4


Chapter 5 101

Listing Software

5 Listing Software

The swlist utility creates customizable listings of software productsthat are installed on your local host or stored in depots for laterdistribution.

With swlist you can:

• Specify the level (bundles, products, subproducts, filesets or files) toshow in your list.

• Display a table of contents for a software source.

• Specify a set of software attributes to display for each level. Softwareattributes are items of information about products contained in theInstalled Products Database or in catalog files. These items caninclude the product's name or “tag”, its size (in Kbytes), revisionnumber, etc.

• Display selected or all software attributes for each level.

• Show the product structure of software selections.

• List software stored in an alternate root directory.

• Display the depots on a specified host.

• Create a list of products, subproducts and/or filesets to use as input tothe swinstall or swremove commands.

• List the categories of available or applied patches.

• List the values of a fileset's applied patches.

Topic Page

“Listing Your Software (swlist)” 102

“Creating Software Lists” 109

“Using Interactive swlist” 116

“Advanced Topics for swlist” 119

102 Chapter 5

Listing SoftwareListing Your Software (swlist)

Listing Your Software (swlist)The swlist command has a Graphical User Interface (GUI) invoked bythe swlist -i option.

A swlist session consists of only the Selection Phase, which takes placeon the local host.

SyntaxThe syntax for swlist is:

swlist [-d|-r] ] [-i ] [-R ] [-v ] [-a attribute] [-C session_file][-f software_file] [-l level] [-s source] [-S session_file][-t target_file] [-x option=value][-X option_file][software_selections] [@target_selections]

You can specify which products to list (-f software_file orsoftware_selections), what additional software information you want inthe list (-a attribute), the level to which you want to list (-l leveldesignation) and where the products are (on a local host, depot ordirectory). As with other commands, you can also specify sources,software and option changes.

The -t option is applicable to the HP OpenView Software Distributorproduct.

Remember, the @ character and the space following it, if used, areimportant to the proper operation of the command.

NOTE If you are piping the output of a swlist command to more (for example,swlist -vl file | more which would create a very large listing) andwant to terminate the process, use ctrl -C. If you use q to quit, swlist mayhang.

Chapter 5 103


ExamplesTo run the swlist interactive interface:

swlist -i @ host1

To use interactive swlist to view a depot:

swlist -i -d @ /tmp/depot

To produce a list of the software (by name) installed at root (/ ) on yourlocal host, you would simply type:

swlist

Which might produce a listing on your display like this:

# Initializing...# Contacting target "xxyyzz"...## Target: xxyyzz:/

# Bundle(s):

B3782CA B.11.00 HP-UX Media Kit (Reference Only. See Description)B3898AA B.11.00 HP C/ANSI C Developer's Bundle for HP-UX 11.00HPUXEngRT B.11.00 English HP-UX Run-time Environment

# Product(s) not contained in a Bundle:

HMS 1.01OBAM5_0 B.11.00 ObAM 5.0

Using swlist with no options set and no software selected gives you alisting of all software bundles plus all products that are not part of abundle.

By adding the -d option you would get the same listing of softwareresiding in the default depot on your local host.

For a more information see:

• “Creating Software Lists” on page 109 for additional examples of howto create software lists.

• “Advanced Topics for swlist” on page 119 for thorough discussion ofhow to customize your lists using the swlist defaults and options.

104 Chapter 5


Command OptionsThe swlist command supports the standard options as described inChapter 2, “Installing and Copying Software,” plus these additionaloptions:

Option Action

-d List products available from a depot rather thansoftware installed on the local host.

-i Invokes the interactive user interface. (See “UsingInteractive swlist” on page 116.)

-r (Optional) List products on an alternate root (instead of/ ).

-R Shorthand for -l bundle -l subproduct-l fileset .

-v List all the attributes for the level given, one per line.These descriptive, state or relational attributes aredisplayed for each software selection (bundle, product,subproduct, fileset) or depot given.

If the -v option (verbose) is used in front of the -loption (that is, -vl level designator), all the attributesfor each of the levels implied in the -l level designationspecification are given. This lets you see all theattributes that are available for each software level andproduces a lengthy list.

-a attribute Each listing level has its own set of attributes orinformation items. These attributes include suchthings as revision numbers, description, vendorinformation, size in Kbytes and many others.

-C session_file Save the current options and operands to session_file.You can enter a relative or absolute path with the filename. The default directory for session files is/.sw/sessions/ . You can recall a session file with the-S option. (Note that session management does notapply to the swlist interactive user interface invokedby the -i option.)

-f software_file Read the list of software_selections from software_fileinstead of (or in addition to) the command line.

Chapter 5 105


-l level List all software objects down to the specified “leveldesignation.” Level designations are the literals: depot,bundle, product, subproduct, fileset or file. You may useonly one level designation per command. Do not usesoftware names, subproduct names, etc. to specifylevels.

The syntax is to choose a level as a starting point andlist items only down to that level.

The -l Options

See the section “Advanced Topics for swlist” on page119 for more information on levels.

Option Action

swlist -l root shows the root level (roots on thespecified target hosts)

swlist -l shroot Shows the shared roots

swlist -l prroot Shows the private roots

swlist -l bundle Shows only bundles

swlist -l product Shows only products

swlist -l subproduct Shows products and subproducts

swlist -l fileset Shows products, subproducts andfilesets

swlist -l file Shows products, subproducts,filesets, files and numbers (used insoftware licensing).

swlist -l category Shows all categories of availablepatches for patches that haveincluded category objects in theirdefinition.

swlist -l patch Shows all applied patches.

106 Chapter 5


-s source Specifies the software source to list. This is analternate way to list a source depot. Sources can also bespecified as target depots and listed using the -doption.

-S session_file Execute swlist based on the options and operandssaved from a previous session, as defined insession_file. You can save session information to a filewith the -C option. (Note that session managementdoes not apply to the swlist interactive user interfaceinvoked by the -i option.)

-t target_file Read the list of target_selections from target_fileinstead of (or in addition to) the command line.

-x option=value Set the session option to value and override the defaultvalue (or a value in an alternate option_file withthe -X option). Multiple -x options can be specified.

-X option_file Read the session options and behaviors fromoption_file.

You may specify only one attribute per -a option. However, the tagattribute is always included by default, so specifying -a revision lists allproduct names AND their revision numbers.

For example, to list whether software bundles on a CD-ROM (mounted tothe directory /SD_CDROM) require a codeword or not, use the command:swlist -d -a is_protected @ /SD_CDROM

See the section “Advanced Topics for swlist” on page 119 for moreinformation on attributes.

An attribute containing a large amount of information (for example, aREADME) is physically stored as a separate file and is displayed by itselfif -a README is requested.

Chapter 5 107


Command OperandsIn addition to the operands for the -l and -a options above, the swlistcommand supports the standard software selection syntax.For moredetails on software selection syntax and an example of a softwareselection file, see “Command Operands” on page 31.

Changing Default OptionsIn addition to the command-line option listed above, several swlistbehaviors and policy options can also be changed by editing extendedoption and default values found in the system-wide defaults file:/var/adm/sw/defaults


$HOME/.swdefaults

Values in these files are specified using the command. option=valuesyntax.

Table 5-1 Configuration Default Options


agent_timeout_minutes=10000 patch_one_liner=title patch_state

codeword= rpc_binding_info=ncacn_ip_tcp:2121ncadg_ip_udp:[2121]

customer_id= rpc_timeout=5


select_local=true

layout_version=1.0 software_view=all_bundles

level= targets=

one_liner=revision title verbose=1

108 Chapter 5


Using Session FilesEach invocation of the swlist command defines a configuration session.The invocation options, source information, software selections, andtarget hosts for this session are saved before the installation or copy taskactually commences. This lets you re-execute the command even if thesession ends before proper completion.

Each session configuration is automatically saved to the file$HOME/.sw/sessions/swlist.last . This file is overwritten at eachinvocation of swlist .

You can save a session configuration to a specific file by executingswlist with the -C session_file option.


To re-execute a session file, specify the session file as the argument forthe -S session__file option of swlist .

Note that when you re-execute a session file, the values in the session filetake precedence over values in the system defaults file. Likewise, anycommand line options or parameters that you specify when you invokeswlist take precedence over the values in the session file


Chapter 5 109

Listing SoftwareCreating Software Lists

Creating Software ListsThe starting point for a software list is always taken from the operandsin the -l and -a options (or from the level= or one_liner= defaults,see the “Advanced Topics for swlist” section). You must decide whatlevels you want and what software attributes to list in addition to theproduct name.

NOTE Examples in this section were created with the one-liner= option leftblank.

Specifying Product LevelSpecifying a level for a given software selection causes swlist to list theobjects at that level plus all those that are above that level. Upper levelswill be “commented” with a # sign. Therefore, only the level specified(product, subproduct, fileset or file) will be uncommented. This allowsthe output from swlist to be used as input to other commands. Theexceptions are:

1) a list that contains only files; file-level output is not accepted byother commands

2) a list that contains software attributes (-a and -v ).

For example, if you wanted to see all the products installed on your localhost, your command would be:

swlist -l product

and the listing would look like this:

NETWORKINGSAMOPENVIEWPRODUCT ASOFTWARE ZPRODUCT B...

Note that the product names are uncommented because that was thelevel you requested to display and there are no levels above.

110 Chapter 5


Specifying Subproduct LevelFor this example, on the local host, the NETWORKING product containsthe subproducts ARPA and NFS and you want to see how big each objectis (in Kbytes).

swlist -l subproduct -a size NETWORKING

# NETWORKING 9072NETWORKING.ARPA 4412NETWORKING.NFS 4660

The list does not show the files or filesets because you didn't specify thatlevel on the command line.

If you wanted to see the names and revision numbers for theNETWORKING product on the local host, the command would be:

swlist -l subproduct -a revision NETWORKING

Remember, the product name is always assumed; you don't have tospecify it in the -a option.

Specifying Fileset LevelAn example of using the -l option to generate a listing that includes allfilesets for the product NETWORKING on the local host and adescriptive title for each:

swlist -l fileset -a title NETWORKING

# NETWORKING Network Software# NETWORKING.ARPA ARPA/Berkeley Services

NETWORKING.ARPA-INC ARPA include filesNETWORKING.ARPA-RUN ARPA run-time commandsNETWORKING.ARPA-MAN ARPA manual pagesNETWORKING.LANLINK CORE ARPA software

# NETWORKING.NFS Network File System ServicesNETWORKING.NFS-INC NFS include filesNETWORKING.NFS-RUN NFS run-time commandsNETWORKING.NFS-MAN NFS manual pages

Again, note the commented lines (#) representing the subproduct(NETWORKING.ARPA and NETWORKING.NFS) and product(NETWORKING) levels. The other lines are filesets.

If you are listing filesets on a depot (swlist -l fileset -a title-d NETWORKING), make sure the -d is in the proper position. The -dmust PRECEDE the fileset name.

Chapter 5 111


Specifying Files LevelAn example of the -l option to generate a comprehensive listing thatincludes all files for the subproduct NETWORKING.ARPA:

swlist -l file NETWORKING.ARPA

# NETWORKING.ARPA# NETWORKING.ARPA_INC

NETWORKING.ARPA_INC:/usr/include/arpa/ftp.hNETWORKING.ARPA_INC:/usr/include/arpa/telnet.hNETWORKING.ARPA_INC:/usr/include/arpa/tftp.hNETWORKING.ARPA_INC:/usr/include/protocols/rwhod.hNETWORKING.ARPA_INC:/usr/adm/sw/products/NETWORKING/ARPA-INC/in

dex

.

.

.

# NETWORKING.ARPA_RUNNETWORKING.ARPA_RUN:/etc/freezeNETWORKING.ARPA_RUN:/etc/ftpdNETWORKING.ARPA_RUN:/etc/gatedNETWORKING.ARPA_RUN:/etc/named

.

.

.

# NETWORKING.ARPA_MANNETWORKING.ARPA_MAN:/usr/man/man8/ftpdNETWORKING.ARPA_MAN:/usr/man/man8/gated

.

.

.

Note that the commented lines represent the requested level(NETWORKING.ARPA) plus one level up (fileset) from the specified filelevel (NETWORKING.ARPA_INC, NETWORKING.ARPA_RUN andNETWORKING.ARPA_RUN are all filesets). The uncommented linesare files.

112 Chapter 5


Depot ListsAnother class of objects that swlist can display are depot lists. Thisallows you to list all the registered depots residing on a local host. To dothis, you can use a combination of the -l depot option:

Table 5-2 Listing Depots

swlist syntax result

swlist -l depot list all depots on the local host

swlist -l depot @ hostA list all depots on hostA

swlist -l depot -v @ hostB list, in verbose mode, all depots onhostB

Chapter 5 113


Verbose ListThe -v option causes a verbose listing to be generated. A verbose listingis used to display all attributes for products, subproducts, filesets or files.

The verbose output lists each attribute with its name (keyword). Theattributes are listed one per line. Given the length of this listing, youcould post-process (filter) the output with grep and/or sed to see specificfields.

Attributes for a particular software level are displayed based on thesoftware product name given with the swlist command. For example,swlist -v NETWORKING gives:

tag NETWORKINGinstance_id 7869control_directorysize 9072revision 2.1title Network Softwaremod_timedirectoryvendor.information Hewlett-Packard Companyis_locatable truearchitecture HP-UX_9000machine_type 9000os_name HP-UXtarget.os_release B.11.00*

If the -v option is used with the -l option, the cases are:

• To display all attributes for a bundle, use swlist -vl bundle .

• To display all attributes for a product, use swlist -vl product .

• To display all attributes for products and subproducts, use swlist-vl subproduct .

• To display all attributes for products, subproducts and filesets, useswlist -vl fileset .

• To display all attributes for products, subproducts, filesets and files,use swlist -vl file .

The table below provides a sample listing of the kinds of attributes thatswlist will display. Not all these attributes exist for each software level orobject. This list may change depending on vendor-supplied information.Do not use this list as the official list of all attributes. To get a completelist of the attributes for a particular level or object, use the swlist -vllevel command (see above) or swlist -v software_selections (seeexample below) on your system.

114 Chapter 5


Table 5-3 Sample Attributes

Here are some examples of verbose listings:

This command on the local host:

swlist -v NETWORKING.ARPA-RUN

produces this listing:

Attribute Description

architecture Describes the target system(s) supported by theproduct

category Type of software

copyright Copyright information about the object

mod_time Production time for a distribution media

description Detailed descriptive information about the object

instance_id Uniquely identifies this software product

title Long/official name for the object

mode Permission mode of the file

mtime Last modification time for the file

owner Owner of file (string)

path Full pathname for the file

corequisite A fileset that the current fileset needs(CONFIGURED) to be functional

prerequisite A fileset that the current fileset needs to install orconfigure correctly

readme Traditional readme-like information, release notes,etc.

revision Revision number for an object

size Size in bytes; reflects the size of all contained filesets

state Current state of the fileset

Chapter 5 115


# NETWORKING.ARPAfilesettag ARPA-RUNinstance_id 1revision 1.2title ARPA run_time commandssize 556state configuredcorequisite NETWORKING.LANLINKis_kernel truemod_time 733507112

This command:

swlist -vlfile NETWORKING.ARPA-RUN

produces this listing:

#NETWORKING.ARPAtag: ARPA-RUNinstance_id 1revision 1.2title ARPA run_time commandssize 556state configuredcorequisite NETWORKING.LANLINKis_kernel true

file etc/freezepath /etc/freezetype fmode 0755owner bingroup binuid 2gid 2mtime 721589735size 24

file etc/ftpdpath /etc/ftpdtype filemode 0555owner bingroup binuid 2gid 2mtime 721589793size 9...

116 Chapter 5

Listing SoftwareUsing Interactive swlist

Using Interactive swlistThe swlist -i command lets you interactively list installed software onyour host system. swlist -i also displays information about thesoftware. The swlist -i -d command lets you display informationabout the software available in a depot or on a physical media.

Figure 5-1 The swlist Browser

Bundles and products are the default top-level display.

To open an item on the list, double-click on the item. Double-clicking on afile-level item displays the file attributes.

Chapter 5 117


Searching and Moving Through the ListThe following features are available to help you search and movethrough the list:

• To search the current list, select Search... from the File menu.

• To open an item on the list, double-click on the item. Double-clickingon a file-level item displays the file attributes.

• To display a pop-up menu of viewing options for an item, click on theitem with the right mouse button. The available options are:

• Open Item to the contents of the item.

• Close Level closes the current item and displays the next higherlevel of objects.

• Show Description of Software... displays attribute informationabout the currently selected item.

Changing the ViewYou can use the View menu options to change the columns displayed,select filters, and sort information:

• Columns displays the Columns Editor. You can then choose whichcolumns of software information to display (i.e. software name,revision number, information, size in Kbytes, architecture, category,etc.) and their order.

• Filter... displays a dialog from which you can filter the display listwith logical and relational operators for each field.

• Sort... lets you select sort fields, order, and criteria for the informationdisplayed.

• Change Software View lets you toggle between a top-level view and aproducts view.

• Change Software Filter... lets select from a list of predefined filters.(Only applies to top-level software objects.)

118 Chapter 5


Performing ActionsYou can use the Actions Menu options to open and close items on thedisplay, show logfile information, and show software descriptions:

• Open Item opens an item. (Same as double-clicking on the item.)

• Close Level closes the current level. (Same as double-clicking on..(go up) .

• Change Target opens a dialog box that lets you enter a path to selectan alternate root (for swlist -i ) or alternate depot (for swlist -i-d ).

• Show Logfile displays the system logfile.

• Show Audit Log displays software depot audit information stored inthe audit log (for swlist -i -d only). See “Using the Source DepotAudit Log” in Chapter 2, “Installing and Copying Software,” for moreinformation.

• Show Description of Software displays attribute information aboutthe currently selected item.

Chapter 5 119

Listing SoftwareAdvanced Topics for swlist

Advanced Topics for swlistYou can control the appearance and content of your lists by changing listdefault values in the defaults file /var/adm/sw/defaults or$HOME/.sw/defaults . Values in this file are specified using thecommand. option=value syntax. You can also change option valuesfrom the command line via the -x option=value option.

List DefaultsInstead of repeatedly specifying the software levels and attributes on thecommand line each time you invoke swlist , you may use two specialdefaults: level= and one_liner= .

level= This default pre-determines what level to list: product,subproduct, fileset or file. For example, by setting thisdefault to level=fileset , future swlist commandswould always list everything down to, and including,filesets for each host, depot or product selected.

one_liner=”attribute attribute attribute"

Specifies the attributes (revision, size, title, etc.) thedefault listing should present. These attributes areseparated by <tab> or <space> and enclosed in quotes(" "). Several attributes may be chosen but a particularattribute may not exist for all applicable softwarelevels (product/subproduct/fileset). For example, thesoftware attribute title is available for bundles,products, subproducts and filesets, but the attributearchitecture is only available for products.

In the absence of the -v or -a option in your command, swlist willalways display the information as described in the one_liner= defaultfor each software object level (bundle, products, subproducts andfilesets), not for files.

120 Chapter 5


Creating Custom ListsThe swlist options and defaults allow you to create lists to fit yourspecific requirements. These lists can be as simple as listing the softwareproducts installed on your local host or as complex as a multiple columnlisting of files, filesets, subproducts, products and bundles installed.

For example, if you were to change the one-liner= option on thecommand line, the command:

swlist -x one_liner="name revision size title"

produces this list of all the products installed on the local host:

RX 1.98 9845 RX X Terminal - all softwareALLBASE 8.00.1 6745 Database ProductsC-LANG 2.5 5678 Programming LanguageDIAGNOSTICS 2.00 56870 Hardware Diagnostic ProgramsDTP68 2.00 26775 Desktop PublishingLISP-LANG 8.00.1 90786 LISP Programming LanguageWINDOWS 2.06 10423 Windowing Products

This listing shows, in columns from left to right, the product's tag, itsrevision number, its size in Kbytes and its title or full name.

NOTE Whatever you specify in the command line for software level andattributes will override the values in the default option files.

You can also change the one_liner= default value to {revision size title}in the defaults file. Then a listing of the C-LANG products on host2would be:

swlist C-LANG @ host2

C-LANG.C-COMPILE 8.0 1346 C Compiler ComponentsC-LANG.C-LIBS 8.0 2356 Runtime LibrariesC-LANG.C-MAN 8.0 1976 Programming Reference

Chapter 5 121


More swlist ExamplesIn the following examples, swlist requests are sent to the standardoutput. All examples assume the one_liner= default is “revision sizetitle” and the level= default is “product.”

• List the contents of the local tape depot, /dev/rmt/0m:

swlist -d @ /dev/rmt/0mor

swlist -s /dev/rmt/0m

AUDIT 3.5 9834 Trusted Systems Auditing UtilsCOMMANDS 1.7 4509 Core Command SetC-LANG 2.5 5678 C Programming LanguageNETWORKING 2.1 9072 Network SoftwareKERNEL 1.4 56908 Kernel Libraries and HeadersVUE 1.3 5489 Vue (Instant Ignition Release)WINDOWS 2.06 10423 Windowing Products

• List all the media attributes of the local tape depot, /dev/rmt/0m:

swlist -v -l depot @ /dev/rmt/0mor

swlist -vl depot -s dev/rmt/0m

type distributiontag CORE OSdescription HP-UX Core Operating System Software Disknumber B2358-13601mod_date June 1998

• List the README file for product, OS_CORE installed on the localhost:

swlist -a readme OS_CORE

readme:***************** Introduction *****************

The Release Notes for HP-UX Release X.0 contain an overview of thenew/changed product features that are included in the release. Fordetailed information about these features, refer to the appropriateproduct manuals. This document does not contain information aboutsoftware changes made as a result of a Service Request; thatinformation may be found in the Software Release Bulletin (SRB) forRelease X.0.

********************* Hardware Support *********************

The HP 9000 Model XXX is no longer supported....

122 Chapter 5


• List the products stored in the software depot on host1 located at/swmedia. For this example assume the swlist one_liner is: “titlesize architecture”:

swlist -d @ host1:/swmedia

FRAME Frame Documentation Pkg 2319 HP-UX_9000_Series_AorBFRAME Frame Documentation Pkg 2458 OSF1_9000_Series_1.0ME30 3-D Mechanical Eng 5698 HP-UX_9000_Series300_AorBSOFTBENCH Softbench Development Env 4578 HP-UX_9000_Series300TEAMWORK Teamwork Design/Analysis 3478 HP-UX_9000_Series300/400

Note that the media contains two revisions of the FRAME product.

Listing PatchesYou can use swlist to list software patches and their status. See “ListingPatches” on page 163 for more information.

Chapter 6 123

Removing Software

6 Removing Software

The swremove command removes software that has been installed on ahost. Before its removal, the software is first unconfigured (if it wasinstalled in the default directory). swremove also removes softwareproducts that have been copied to a software depot.

Topic Page

“Introduction to swremove” 124

“Removing Installed Software Using the Command Line(swremove)”

126

“Removing Installed Software with the GUI/TUI” 130

“Removing Software from Depots” 135

“Advanced Topics for swremove” 136

124 Chapter 6

Removing SoftwareIntroduction to swremove

Introduction to swremoveThe swremove command offers the following features:

• Removes files from the specified location. It removes symbolic links,but not the targets of symbolic links. It also lists busy files that werenot removed.

• Supports the execution of control scripts (both product and fileset)including:

• checkremove scripts that make sure the removal will succeed(if this check fails, the product cannot be removed). For example,the script could check to see if anyone is currently using thesoftware.

• unconfigure scripts that unconfigure the software on the host.For example, removing configuration from the host's/etc/profile or /sbin/rc files. This moves the software fromthe CONFIGURED state back to the INSTALLED state.

• preremove scripts that perform actions before the removal suchas moving a specific fileset to another location before removing therest of the filesets in the product.

• postremove scripts that perform actions after the removal suchas replacing the above example fileset (that was moved to anotherlocation) back to its original location after removing the filesets.

Preremove and postremove scripts cannot be used to unconfigurethe host for the software or to unconfigure the software for thehost. They are to be used for simple file management needs suchas restoring files moved during installation.

• Before removal, swremove allows software to unconfigure the host onwhich it has been running. See Chapter 3, “Configuring and VerifyingSoftware,” for more details.

• swremove also removes software products that have been copied to asoftware depot but unconfigure scripts are not run on depot software(see “Removing Software from Depots” on page 135)

For more information on scripts, see Appendix 11, “Using ControlScripts.”

Chapter 6 125

Removing SoftwareIntroduction to swremove

NOTE Removing a bundle does not always remove all filesets in that bundle. If acertain fileset is required by another bundle, that fileset will not beremoved. For example, if the bundles Pascal and FORTRAN both use thefileset Debugger.Run and you try to remove FORTRAN, the filesetDebugger.Run will not be removed because it is also used by the bundlePascal . This is done to prevent the removal of one bundle frominadvertently causing the removal of a fileset needed by another bundle.

126 Chapter 6

Removing SoftwareRemoving Installed Software Using the Command Line (swremove)

Removing Installed Software Using theCommand Line (swremove)Just as with other SD-UX commands, to start a remove session via thecommand line you must assemble options, selections and defaults into acommand line or use command options to point to files containing defaultchanges and other variables.

SyntaxThe syntax for swremove is:

swremove [XToolkit Option] [-d |-r |-l ] [-i ] [-p ] [-v ][-C session_file] [-f software_file] [-s source] [-S session_file][-t target_file] [-x option=value] [-X option_file][software_selections] [@target_selections]

ExamplesTo remove a software product called MYSOFT from the default depot onthe local host, type:

swremove -d MYSOFT

To preview the remove of the C and Pascal products installed at the localhost:

swremove -p cc pascal

To remove a particular version of HP Omniback:

swremove Omniback,l/opt/Omniback_v2.0

To remove the entire contents of a local depot:

swremove -d * @ /var/spool/sw

Chapter 6 127


Command OptionsThe swremove command supports the following standard options:

Option Action

-d Operates on a depot rather than installed software. See“Removing Software from Depots” on page 135 for moreinformation.

-i Runs a GUI or TUI interactive session. Used to“pre-specify” software selections for use in theGUI/TUI.

-p Previews the remove operation without actuallyremoving anything. In the GUI/TUI, this optionprecludes advancing to the remove phase. You can onlygo through the Analysis phase.

-r (Optional) Specifies an alternate root directory. See“Advanced Topics for swremove” on page 136 for moreinformation on removing software from alternate roots.

-v Turns on verbose output.

-C session_file Run the command and save the current option andoperand values to a file for re-use in another session.

-f software_file Reads the list of software selections from a file.

-S session_file Runs swremove based on a previous session.

-t target_file Reads the list of target hosts from a file. This optionapplies to the HP OpenView Software Distributorproduct.

-x option=value Allows setting of an option on the command line.

-X option_file Uses the options in the specified options file.

Command OperandsThe swremove command supports the standard software selectionsyntax. For more details on software selection syntax and an example ofa software selection file, see “Command Operands” on page 31.

128 Chapter 6


Changing Default OptionsIn addition to the command-line options listed above, several commandbehaviors and policy options can be changed by editing default valuesfound in the defaults file:

/var/adm/sw/defaults


$HOME/.swdefaults .

Values in this file are specified using the command.option=valuesyntax. See “Advanced Topics for swremove” on page 136 for moreinformation on changing the values in these defaults and extendedoptions.

Table 6-1 Removal Default Options

agent_auto_exit=true logdetail=false

agent_timeout_minutes=10000 logfile=/var/adm/sw/swremove.log

auto_kernel_build=true loglevel=1

autoreboot=false mount_all_filesystems=true

autoremove_job=false polling_interval=2

autoselect_dependents=false remove_empty_depot=true

autoselect_reference_bundles=true

rpc_binding_info=ncacn_ip_tcp:2121ncadg_ip_udp:[2121]

controller_source= rpc_timeout=5


software=

enforce_dependencies=true software_view=products

enforce_scripts=true targets=

force_single_target=false target_shared_root=

job_title= verbose=1

log_msgid=0 write_remote_files=false

Chapter 6 129


Using Session FilesEach invocation of the swremove command defines a configurationsession. The invocation options, source information, softwareselections, and target hosts for this session are saved before theinstallation or copy task actually commences. This lets you re-executethe command even if the session ends before proper completion.

Each session configuration is automatically saved to the file$HOME/.sw/sessions/swconfig.last . This file is overwritten ateach invocation of swremove .

You can save a session configuration to a specific file by executingswremove with the -C session_file option.


To re-execute a session file, specify the session file as the argument forthe -S session__file option of swremove .

Note that when you re-execute a session file, the values in the session filetake precedence over values in the system defaults file. Likewise, anycommand line options or parameters that you specify when you invokeswconfig take precedence over the values in the session file


130 Chapter 6

Removing SoftwareRemoving Installed Software with the GUI/TUI

Removing Installed Software with theGUI/TUIThe swremove Graphical User Interface (GUI) and Terminal UserInterface (TUI) are based on the swinstall and swcopy user interfacesthat are described in detail in Chapter 2, “Installing and CopyingSoftware.”.

The swremove GUI and TUI also feature the same On-Line Helpassistance as the swinstall interface. Choosing Help in the Menu bar orusing the f1 key will present help topics that will further explain thevarious menu choices and options.

The swremove command behaves differently when removing from theprimary root file systems versus alternate root file systems versusdepots. The changes for alternate root file systems are noted in thesection “Advanced Topics for swremove” on page 136. The changes to theinterface for removing from depots are summarized in “RemovingSoftware from Depots” on page 135.

The swremove session also consists of a Selection phase, an Analysisphase and a Remove phase. The Remove phase is the actual removal andmonitoring of the process. The unconfigure scripts, preremove scriptsand postremove scripts are executed in this phase.

swremove also automatically saves the current command options, sourceinformation, software selections and host/depots into a session file beforethe removal actually starts. This session file can then be recalled andre-executed. This session file is saved as$HOME/.sw/sessions/swremove.last .

To start the Graphical or Terminal User Interface for a remove session,simply type:

/usr/sbin/swremove

The Software Selection Window appears, displaying software on the localhost.

Note that the -r and -d options must be specified for all root or depotremovals, even when running the GUI/TUI.

Chapter 6 131


You do not need to specify the -i option unless you want to pre-specifysoftware to be marked in the GUI or TUI (see Chapter 2, “Installing andCopying Software.”).

Selecting Software to RemoveWhen you invoke swremove (without the -i or -r options), the SoftwareSelection Window appears with all the software currently installed onthe local host (at / ) displayed in the Object List. Software is chosen byhighlighting objects and “marking” them or by using the Actions–>MarkFor Remove menu choice. The Marked? flag is automatically updated toreflect the selection. The possible values for the Marked? flag are: “Yes”,“Partial” and blank.

Opening and Closing an ObjectAs in swinstall , the objects in the swremove Object List can bebundles, products, subproducts or filesets. The column headers areidentical to the attributes in the swinstall interface. These productattributes can also be modified with the Columns Editor.

The objects in the lists may be opened to show their contents. Forexample, if you wish to see the subproducts of a particular product, youmay open that product by double clicking on the item (GUI only) ormoving the focus to that item and pressing Return (TUI only). Thecontents of the Object List will be replaced with a listing of thesubproducts for that product. If you want to open the subproduct, doubleclick on it to display its filesets. Objects that have an arrow (–>) after thename can be opened to reveal other items.

To close an object in the GUI and return to the previous list, double clickon the first item in the list (. .(go up) ). In the TUI, move the focus to. .(go up) and press Return .

To open and close objects in the TUI, use the Open Item and Close Levelmenu choices.

When the product is opened, the subproducts and the filesets are shownin the list together. However, at the product level, only products arelisted together.

132 Chapter 6


Analyzing a RemovalWhen the Actions–>Remove analysis menu choice is made on theSoftware Selection Window, the Remove Analysis Dialog appears.

The Remove Analysis Dialog and its sub-menus are the same as those inthe swinstall windows. See Chapter 2, “Installing and CopyingSoftware,” for complete descriptions.

Analysis Progress and ResultsThe attributes available in the Analysis Object List are identical to theattributes available in the swinstall Analysis Dialog.

Once analysis has completed, the Status should be “Ready.” If any of theselected software can be removed, the status will be “Ready” or “Readywith Warnings.” If none of the selected software can be removed, statuswill be “Excluded from task.”

The Errors and Warnings are the same as those for swinstall . Refer toChapter 2, “Installing and Copying Software,” for complete details.

The Products Ready column shows the number of products ready forremoval out of all products selected. The total products ready includesthose products that are:

• only marked because of dependencies

• marked inside of bundles

• partially and wholly marked.

See the section “Advanced Topics for swremove” on page 136 for moreinformation regarding dependencies.

A product may be automatically excluded from the removal if an erroroccurs with the product. The remove cannot proceed if the host target isexcluded from the removal.

If the host fails the analysis, a Warning Dialog appears.

Chapter 6 133


Getting More DetailsThe Analysis Dialog presents more in-depth information regarding thehost and the products being removed. There are three areas of additionalinformation: the Product Summary, an overview of the products beingremoved, their revision numbers, the results of the attempt, the type ofremoval being attempted and a summary of any errors or warnings —the Product Description, a more complete presentation of the product, itssize, vendor name, dependencies and other important information — theLogfile, a scrollable view of the information that is written in the logfile.

These dialogs can be displayed from the either the Remove AnalysisDialog or from the Remove Dialog by choosing the appropriate button.

Details for removals using the -i and -r options can only be displayedfor one host at a time.

Summarizing DetailsThe Product Summary describes the products to be removed andpresents the effect of starting the removal on each product selected.

The Projected Action column describes what type of removal is beingdone. The possible types are:

Remove The product exists and will be removed.

Filesets NotFound The system did not find the filesets as specified.

Skipped The product will not be removed.

Excluded The product will not be removed because of someanalysis phase errors. See the logfile for details aboutthe error.

The Product Summary List is not an object-list; the products can not beopened and closed and actions can not be applied to the products. Youcannot change the columns of the Product Summary List. To see moreinformation about the products in the Product Summary, highlight anobject in the list and select the Product Description button.

Seeing the swremove LogfileThe swremove Logfile Dialog behaves exactly as the Logfile Listing inswinstall .

134 Chapter 6


The Remove WindowWhen the OK button choice is made in the Analysis Dialog, theConfirmation Dialog appears. The dialog explains that the remove phasewill now be started on objects with a status of “Ready.” To start theremove phase, press the Yes button on this dialog. (There are no “FinalRemove Warnings”).

The removal is then started on all objects with a status of “Ready” in theRemove Analysis Dialog. The Remove Analysis Dialog is replaced by theRemove Dialog.

The buttons are the same as those in the swinstall windows exceptthere are no buttons for continuing, retrying unconfigure, aborting, orrebooting. See “Installing/Copying Software with the Graphical orTerminal User Interface” on page 41 for complete descriptions.

Monitoring the Removal ProcessThe columns available for the selected hosts in the Remove Dialog Listare identical to those described in the swinstall Install Dialog. Unlikeswinstall , however, you are not allowed to abort the removal UNLESSSD-UX suspends the task. Since removals can't suspend, the Abort andResume buttons are not available.

When the remove phase is completed, a dialog is displayed to notify youof the completion. The only actions available at this point are:

• displaying the logfile,

• saving the session before exiting or starting with a new session,

• starting a new session,

• recalling a session, or

• exiting.

The Product Summary Dialog reflects the results of the removal on eachproduct selected.

Chapter 6 135

Removing SoftwareRemoving Software from Depots

Removing Software from DepotsWhen you invoke swremove with the -d option, software is removedfrom depots instead of root file systems. This also creates somedifferences in the swremove GUI/TUI. This section provides a briefdescription of the depot interface. Where possible, you are referred toeither the normal swremove GUI/TUI or the swinstall/swcopy GUIdescribed in Chapter 2, “Installing and Copying Software.”

Selecting The Target Depot PathSelecting depots for removal involves a depot path on the local host. Forexample, on the command line, depots are specified with the syntaxlocal_host:<depot_path> .

swremove -d can determine what depots currently exist on a host. Whenyou invoke it, a Select Target Depot Path Dialog appears, superimposedover the Software Selection Window. It allows you to list all the depotsregistered on the Target Host (press the Target Depot Path button). Youmay choose a path from the list or enter one in the test box. When youhave specified the depot path, the software in the depot will be listed inthe Software Selection Window.

If no depots are currently registered on the local host, an error dialogappears with instructions to enter the name into the text area of thisdialog.

Selecting SoftwareThe software selection menu items are identical to those available in thiswindow during the normal swremove .

Analyzing the Removal from a DepotThere are no changes in the Analysis Dialog.

Removing the Product from a DepotThe only change to the Remove Window is that “Unconfiguring” is not avalid value for the Status attribute. There are no changes in the RemovePhase Details Window.

136 Chapter 6

Removing SoftwareAdvanced Topics for swremove

Advanced Topics for swremoveThe topics discussed in this section are for those users who have a firmunderstanding of the commands and who want to have additional controlover their software removal process.

Changing swremove Defaultsswremove default values can be changed in three ways: they can beindividually overridden on the command line by specifying analternative options file with the -X option or individually with the -xoption=value option, they can be edited directly in the defaults file or youcan use the GUI or TUI Options Editor Dialog to change theminteractively. See “Changing Default Options” on page 33 for moreinformation.

Removing Software from an Alternate RootSoftware can be removed relative to the primary root directory (/ ) orrelative to an alternate root directory. An alternate root is a non-rootlocation that can function as the root of a stand-alone system; that is, asystem that can be unmounted and function as a self-contained system.Any information files used in software removal are retrieved from theInstalled Product Database (see “Installed Products Database” on page20) beneath this alternate root, not the IPD on the root volume.

The difference in behavior between swremove and swinstall is thatswremove checks for the existence of the alternate root file system whenit is specified. The GUI “Target Path Dialog” will appear first whenswremove -r is invoked. It asks you to enter an alternate root path onthe local host or choose one from the list of registered shared roots on thesystem. The default shared root that appears in the “Target Path Dialog”will be /export/shared_roots/OS_700.

If the alternate root directory you choose does not exist (that is, is notregistered), an error is generated and the dialog that prompted you forthe path to the alternate root file system remains displayed.

Chapter 6 137


Removing PatchesPatch software cannot be removed unless:

• Rollback files corresponding to the patch are available forre-installation.

or

• The base software modified by the patch is removed at the same time.(Removing the base software also removes the patches associatedwith that software.)

For more information on removing patches, see Chapter 8, “ManagingPatches,” on page 149.

DependenciesDependents are enforced at Selection phase when theautoselect_dependent default is set to “true.” This defaultdetermines if the system should automatically mark software forremoval based on whether it depends on software you mark.

During Selection phase, if a dependent will be left on the system in anunusable state because of the removal of another software object, adialog shows it. The software object that the dependent requires is notremoved. This error can be overridden by setting theenforce_dependencies option in the defaults file to “false”. AWARNING will still be generated, but swremove will show that it isbeing overridden.

When an object is selected (and autoselect_dependent is “true”), ifthere is more than one dependent available in the Software SelectionsWindow, they are all automatically selected (not just the latest version ofthe dependent like swinstall dependency selection).

When removing from a depot, dependencies are handled the same as thenormal swremove . Dependencies handling is controlled by the defaultsenforce_dependencies and autoselect_dependents .

No compatibility filtering or checking is performed in any removecommands. There is nothing to be compatible with; software is alreadyon the local host.

138 Chapter 6


Multiple VersionsEach separate version of a product along with its location directory islisted in the Object List. Selecting a multiple version implies aproduct:/location directory pair. By default, the location is not displayedin the Software Selection Window. It can be displayed using the ColumnsEditor View–>Columns .. menu item. During the analysis phase, if theversion of the product exists on the host but at a different location, aWARNING is generated.

More than one version of a product can be selected during the selectionphase. During the analysis phase, if the product exists on the host, it willbe removed. If it does not exist on the host, the product is simply skipped.The analysis Product Summary Window gives a product-by-productsummary of what will be removed if the remove phase is started.

Multiple versions of products are inherently possible in a depot. Nospecial handling or checks are required when removing from depots.

Chapter 7 139

Modifying IPD or Catalog Contents

7 Modifying IPD or CatalogContents

The swmodify command adds, modifies, or deletes software objectsand/or attributes defined in a software depot, primary root or alternateroot. It is a direct interface with a depot's catalog files or a root'sInstalled Products Database. It does not change the files that make upthe object, it only manipulates the information that describes the object.

Using swmodify , you can

• add new bundle, product, subproduct, fileset, control script or filedefinitions to existing objects

• remove software objects from a depot catalog file or root IPD

• change attribute values for any existing object (if you are adding anew object, you can define attributes for it at the same time).

Topic Page

“Introduction” 140

“Changing and Adding Software Information (swmodify)” 141

140 Chapter 7

Modifying IPD or Catalog ContentsIntroduction

IntroductionThe SD-UX Installed Products Database (IPD) keeps track ofinstallations, products and filesets on the system. Located in thedirectory /var/adm/sw/products , the IPD is a series of files andsubdirectories that contain information about all the products that areinstalled under the root directory (/ ). See Chapter 1, “Introduction toSoftware Distributor,” for more information on the IPD.

The equivalent IPD files for a depot are called catalog files. When adepot is created or modified using swcopy , catalog files are built (bydefault in /var/spool/sw/catalog ) that describe the depot and itscontents.

Since both the IPD and catalog files are created and constantly modifiedby other SD-UX operations (swinstall , swcopy , and swremove ), theyare not directly accessible if you want to change the information theycontain. If you need to edit the information in either the IPD or in anydepots' catalog files, you must use the SD-UX swmodify command.

swmodify and the Product Specification File(PSF)The product specification file (PSF) for swmodify uses the sameswpackage PSF format as defined in “Creating a Product SpecificationFile (PSF)”.

A full PSF contains at least product, fileset, and file definitions. It canserve as valid input to the swmodify command, and provides swmodifywith the information needed to create a new product, with filesets andfiles. A full PSF can also be specified when adding new filesets or files toexisting products or filesets. A full PSF can also be specified whenremoving filesets (or files) from existing products (or filesets).

Chapter 7 141

Modifying IPD or Catalog ContentsChanging and Adding Software Information (swmodify)

Changing and Adding SoftwareInformation (swmodify)

SyntaxThe syntax for the swmodify command is:

swmodify [-d ] [-p ] [-r ] [-u ] [-v [v ]] [-V ] [-a attribute=[value]][-C session file] [-f file] [-P pathname_file][-s product_specification_file] [-S session_file] [-x option=value][-X option_file] [software_selections]

ExamplesHere are some examples of how you can use swmodify to change catalogfiles or IPDs:

Adding InformationTo add files (/tmp/a, /tmp/b. /tmp/c) to an existing fileset:

swmodify -x files=/tmp/a /tmp/b /tmp/c PRODUCT.FILESET

If a control script adds new files to the installed file system, the scriptcan use swmodify to make a record of the new files.

Changing Existing InformationTo create some new bundle definitions for products in an existing depot:

swmodify -d -s new_bundle_definitions \\* @ /mfg/master_depot

If a product provides a more complex configuration process, a script canset the fileset's state to CONFIGURED upon successful completion.

To change the values of a fileset's attributes:

swmodify -a state=installed PRODUCT.FILESET

142 Chapter 7


To change the attributes of a depot:

swmodify -a title=Master Depot \-a description=/tmp/mfg.description \@ /mfg/master_depot

Defining New ObjectsYou can import an existing application (not installed by SD-UX) byconstructing a simple Product Specification File (PSF) describing theproduct and then invoke swmodify to load that definition into the IPD.

To create a new fileset definition (if the PSF contains file definitions,then add those files to the new fileset):

swmodify -s new_fileset_definition

Chapter 7 143


Command OptionsMany of the options listed here for swmodify are the same for otherSD-UX commands.

Option Action

-d Perform modifications on a depot (not on a primary oralternate root). Your target_selection must be a depot.

-p Previews a modify session without changing anythingwithin the target_selection.

-r Perform modifications on an alternate root (and not theprimary root). Your target_selection must be analternate root.

-u If no -a attribute options are specified, then delete thespecified software_selections from within yourtarget_selection. This action deletes the definitions ofthe software objects from the depot catalog or InstalledProducts Database.

If -a attribute options are specified, then delete themfrom within the given target_selection.

-v[v] Turns on verbose output to stdout . (The swmodifylogfile is not affected by this option.) A second v willturn on very verbose output.

-V Lists all the SD layout_versions this commandsupports.

-a attribute=valueAdd, change, or deletes the attribute value. Otherwise,it adds/changes the attribute for eachsoftware_selection by setting it to the given value.

Multiple -a options can be specified. Each attributemodification will be applied to every software_selection.

The -s and -a options are also mutually exclusive: the-s option cannot be specified when the -a option isspecified.

144 Chapter 7


NOTE In general, you should not use -u option with the -a option. If -u is usedand -a is also specified, the -a option deletes the attribute from the givensoftware_selections (or deletes the value from the set of values currentlydefined for the attribute).

NOTE You cannot use the -a option to change the following attributes: tag ,revision , instance_id , vendor_tag , or corequisite .

-C session_file Run the command and save the current option andoperand values to a file for re-use in another session.

-f file Read the list of software_selections from file instead of(or in addition to) the command line.

-P pathname_fileLets you specify a file containing the pathnames of filesbeing added to or deleted from the IPD instead ofhaving to specify them individually on the commandline.

-s product_specification_file

The source Product Specification File (PSF) describesthe product, subproduct, fileset, and/or file definitionsthat will be added or modified by swmodify .

If a product_specification_file (PSF) is specified,swmodify selects the individual software_selectionsfrom the full set that is defined in the PSF. If nosoftware_selections are specified, then swmodify willselect all of the software defined in the PSF. Thesoftware selected from a PSF is then applied to thetarget_selection, with the selected software objectseither added to, modified in, or deleted from it.

If a PSF is not specified, then software_selections mustbe specified. swmodify will select thesoftware_selections from the software defined in thegiven (or default) target_selection.

-S session_file Execute swmodify based on the options and operandssaved from a previous session, as defined insession_file.

Chapter 7 145


-x option=value Set the session option to value and override the defaultvalue (or a value in an alternate options_file specifiedwith the -X option). Multiple -x options can bespecified.

-X option_file Read the session options and behaviors fromoptions_file.

swmodify lets you specify a single, local target_selection. If you areoperating on the primary root, you do not need to specify atarget_selection because the target / is assumed.

When operating on a software depot, the target_selection specifies thepath to that depot. If the -d option is specified and no target_selection isspecified, then the default depot_directory is assumed.


Command OperandsThe swmodify command supports the standard software selectionsyntax. For more details on software selection syntax and an example ofa software selection file, see “Command Operands” on page 31.

146 Chapter 7


Changing Default OptionsIn addition to the command-line option listed above, several swmodifybehaviors and policy options can also be changed by editing extendedoption and default values found in the system-wide defaults file:/var/adm/sw/defaults


$HOME/.swdefaults


swmodify.agent_auto_exit=true

Table 7-1 Modify Default Options

control_files= loglevel=1


patch_commit=false

files= software=

layout_version=1.0 source_file=

logdetail=false targets=

logfile=/var/adm/sw/swmodify.log

verbose=1

Chapter 7 147


Using Session FilesEach invocation of the swmodify command defines a modify session.The invocation options, source information, software selections, andtarget hosts for this session are saved before the modify task actuallycommences. This lets you re-execute the command even if the sessionends before proper completion.

Each session configuration is automatically saved to the file$HOME/.sw/sessions/swmodify.last . This file is overwritten ateach invocation of swmodify .

You can save a session configuration to a specific file by executingswmodify with the -C session_file option.


To re-execute a session file, specify the session file as the argument forthe -S session__file option of swmodify .

Note that when you re-execute a session file, the values in the session filetake precedence over values in the system defaults file. Likewise, anycommand line options or parameters that you specify when you invokeswmodify take precedence over the values in the session file


148 Chapter 7


Chapter 8 149

Managing Patches

8 Managing Patches

SD-UX contains features to help you develop, install, and managesoftware patches:

• Default options for patch management functions.

• Software objects and attributes for identifying and managing patches.

• Ability to perform patch management operations includinginstallation, interactive installation, copying, listing, removing,rollback, and committal.

Topic Page


“Patch-Related Features” 152

“Patch Operations Summary” 155

“Packaging Patch Software” 166

150 Chapter 8

Managing PatchesIntroduction

IntroductionThe following general information applies to patch software.

• A patch is defined as software packaged with the is_patch attributeset to “true”.

• Most patches apply at the fileset level.

• Patches usually have product and fileset names different from theproduct or fileset they patch. For example, a patch may be namedafter the defect number it fixes. The fileset or filesets to which a patchapplies is defined by the ancestor attribute.

• You can manage patches separately from regular software items.Selection for installation and listing is supported by thecategory_tag attribute and special patch management options toSD commands.

• You can include explicit patches directly in software selections.

See “Patch Attributes” on page 152 in this chapter for completeinformation on patch-related attributes and objects.

Chapter 8 151

Managing PatchesIntroduction

HP-UX 11.0 Patch Installation ParadigmTo install patches with HP-UX 10.X, HP recommended that you use thematch_target option to match patches to the target. However, SD couldnot identify specific software as patches.

The patch installation paradigm for HP-UX 11.00 has changed:

• With HP-UX 11.00, SD can recognize patches based on their internalattributes.

• The match_target option still functions, but no longer matchespatches to targets. Instead, the patch_match_target option selectspatches and matches them to targets when you install patches topreviously installed software.

• The autoselect_patches options automatically selects patches tosoftware selected for installation. This lets you install patches at thesame time you install base software.

Patch management options are discussed fully in the following sections.

152 Chapter 8

Managing PatchesPatch-Related Features

Patch-Related FeaturesSD’s patch-related features include default options and softwareattributes.

Patch AttributesPatch attributes are discussed in “Packaging Patch Software” on page166 in this chapter.

Default OptionsPatch default options are available at the command line. You can changetheir default values by using the -x option or by editing the defaultsfiles. For complete information on default options, see Appendix A,“Default Options and Keywords,” on page 309

The following table summarizes by command the SD-UX default optionsfor managing patches:

Table 8-1 Patch Options Listed by Corresponding Command

Each option is discussed below:

Command Patch Option

swask autoselect_patchespatch_filter

swcopy autoselect_patchespatch_filterpatch_match_target

swinstall autoselect_patchespatch_filterpatch_match_targetpatch_save_files

swlist levelpatch_one_liner

swmodify patch_commit

Chapter 8 153


• autoselect_patches

Automatically selects the latest patches (if any) for a software objectthat you have selected for a swinstall or swcopy operation.(Selection is based on the patch object’s supersedes and ancestorattributes.) The default value is “true.” The patches must reside inthe same depot as the selected software.

This option is useful for installing patches at the same time that youinstall the base software to which the patches apply.

You can use this option with the patch_filter option to limit yourautomatic patch selection.

Applies to swask , swinstall , and swcopy .

• level=patch

Controls the depth of swlist output. When set to the value “patch,”swlist lists patches and their state (“applied”, “committed”, or“superseded”).

Applies to swlist only.

• patch_commit

Commits a patch by removing files saved for patch rollback. Thedefault value is “false.” When set to “true,” this option removes thesaved files for the patches specified in the software selections for thecommand and changes the associated patch_state attribute from“applied” to “committed”.

Applies only to swmodify .

• patch_filter

Specifies a filter used during the automatic patch selection process.

This option is used in conjunction with the autoselect_patchesand patch_match_target options to filter out patches that do notmeet the specified criteria (tag, version, etc.). The default value of thisoption is “*.* ”.

Applies to swask , swcopy and swinstall .

154 Chapter 8


• patch_match_target

Automatically selects the latest patches (software packaged with theis_patch attribute set to “true”) that correspond to software on thetarget root or depot. The default value is “false.”

This option is useful when you are installing patches on previouslyinstalled software.

This option can be used with the patch_filter andautoselect_patches options to filter out patches that do not meetthe specified criteria.

Applies to swcopy and swinstall .

• patch_one_liner

Specifies the attributes shown on the one-line display for each objectlisted by swlist . Applies when the -l option is invoked and when no-a or -v option is specified. The default display attributes are titleand patch_state .

Applies to swlist only.

• patch_save_files

Saves files to be patched before they are overwritten by the patches.This permits future rollback of patches. When set to “false,” patchescannot be rolled back (removed) unless the base (non-patch) softwaremodified by the patch is removed at the same time. The default valueis “true.”

Applies to swinstall only.

Chapter 8 155

Managing PatchesPatch Operations Summary

Patch Operations SummaryThis section summarizes how to use SD commands for patchmanagement, including these activities:

• Installation (command-line and interactive)

• Copying

• Listing

• Removal

• Rollback

• Commit

• Verification

• Updating

Installing PatchesInstallation of patch products follows the same rules as any other SDinstallation. The key difference is that patch filtering mechanisms letyou select only the patches that meet specified criteria. Filteringmechanisms for patches are:

• The category_tag attribute and corresponding category objects.

• The patch_filter , patch_match_target , andautoselect_patches options.

When you install a patch, SD updates the applied_patches attributeof the fileset that has been patched and updates the INFO fileinformation to include the patched file’s attributes. Also (if thepatch_save_files option is set to “true”), files to be altered by a patchare stored to the Installed Products Database (IPD).

When a patch is installed, by default it has the patch_state ofapplied. When the patch is committed (rollback files are removed) or ithas been installed without saving rollback files, it has the state ofcommitted. When the patch is superseded, the patch_state is set tosuperseded, and the superseded_by attribute is set to thesoftware_specification of the superseding patch fileset.

156 Chapter 8


Installing Patches in Same Session as Base ProductIf you select a non-patch fileset for installation and patch filesets for that“base” fileset exist in the same source depot, all applicable patches areselected by default as long as the autoselect_patches option is set toits default value of “true.” The following rules also apply:

• Patch software selections are filtered as defined by thepatch_filter option.

• If more than one patch to a base fileset exists, patches to that filesetare examined to determine if any patches have been superseded bylater versions. The “superseding” patch is installed and “superseded”patches are not selected.

• You can also explicitly specify patches on the command line. See“Explicitly Specifying Patches” on page 158 for more information.

Examples. The following examples demonstrate the use of patchoptions in command lines. Note that the autoselect_patches optiondefaults to “true”.

The example below shows the default behavior for patch installation. Allpatches applying to the software being installed (in this case, X11) areselected by default:

swinstall -s sw_server X11

To select all applicable patches that include the category_tag“critical_patch” and install them along with the selected software:

swinstall -s sw_server \-x patch_filter=”*.*,c=critical_patch” X11

The following example installs a product and an explicitly defined patch.

swinstall -s sw_server \ -x autoselect_patches=false X11 PHSS-12345

Chapter 8 157


Installing Patches After Base Product InstallationWhen you want to install patches after installation of the base product,you can select the patches explicitly or by matching the installedsoftware using the patch_match_target option, which automaticallydetermines the latest patches for a fileset.

Examples. To select all patches in the depot that correspond tocurrently installed software:

swinstall -s sw_server -x patch_match_target=true

To select all patches in the depot that correspond to currently installedsoftware and that contain the category_tag “critical_patch”:

swinstall -s sw_server -x patch_match_target=true \-x patch_filter=” *.*,c=critical_patch”

Patch Filtering with Multiple CriteriaYou can repeat a version qualifier (for “AND” criteria) and use the pipesymbol (“|”) within qualifiers (for “OR” criteria). This is consistent withthe current level-of-expression support in POSIXstandard software specifications.

Example. To install any patches that have the category_tag“critical” AND either the category_tag “test_level_4” OR thecategory_tag “hand_certified”.

swinstall -s sw_server -x patch_match_target=true \-x patch_filter=”*.*,c=critical,\c=test_level_4|hand_certified”

158 Chapter 8


Explicitly Specifying PatchesYou can explicitly specify and install a patch (without autoselection ormatching the target) by specifying one or more software_specificationoperands.

Examples. To explicitly install a patch:

swinstall -x autoselect_patches=false PHCO_1234

NOTE Filtering does not apply to explicitly selected patches.

CAUTION Superseding patches will not override an explicit patch selection. Makesure that you do not select a patch that might later be superseded.

Patching Kernel and Library FilesTo permit patching of kernel files or libraries (e.g. libc.a ), SD uses anarchive file type of “a”. When loading a file of type “a”, swinstalltemporarily installs the .o file to the target path specified, integrates itinto the archive specified by the archive_path attribute of the file, andthen removes the .o file.

If patch rollback is enabled (see “Patch Removal, Rollback, andCommittal” on page 164), the original .o file is automatically extractedfirst and saved so that it can be replaced. Disk Space Analysis isperformed as needed to account for these operations.

Patch Load OrderIf you install patch filesets and normal filesets in the same session, theneach patch fileset is considered to have an “implied prerequisite” on thefileset that it is patching, with respect to ordering. In other words, aproduct containing the patch fileset is installed (or copied into serialdistributions) after installation of the one or more products that containthe patch “ancestors”.

If a base fileset has the is_kernel attribute set to “true,” then thefileset patching it must also have the is_kernel attribute set to “true”to be installed in the kernel phase of the execution. Otherwise, the patchis installed along with other non-kernel filesets.

If a bundle contains both normal and patch filesets, the filesets areinstalled in their normal order except that any base fileset must beinstalled before its patch or patches.

Chapter 8 159


Copying PatchesFor copying patches, swcopy usage of the autoselect_patches ,patch_filter , and patch_match_target options corresponds to theusage in swinstall.

ExamplesThe following example copies X11 software from the default depot andcopies all patches for this software at the same time. (Note thatautoselect_patches is “true” by default.)

swcopy X11 @ hostA:/tmp/sw

The following example copies all software from the default depot andcopies (at the same time and from the same depot) a filtered set ofpatches (category_tag=”critical_patch” ) for the base softwarebeing copied. (Note that autoselect_patches is “true” by default.)

swcopy -x patch_filter=”*.*,c=critical_patch” \\* @ hostB:/tmp/newdepot

To copy all patches for the base filesets that are already present in thetarget depot, starting from a depot that contains patch and non-patchsoftware:

swcopy -x patch_match_target=true \@ hostC:/var/spool/sw

To copy a filtered set of patches for the base filesets that are alreadypresent in the target depot, starting from a depot that contains patchesand that may contain non-patch software:

swcopy -x patch_match_target=true \-x patch_filter=”*.*,c=critical_patch” \\* @ hostD:/var/spool/sw/sample.depot

160 Chapter 8


Interactive Patch ManagementThe swinstall and swcopy GUIs lets you perform interactive patchinstallation and copying. (See Chapter 2, “Installing and CopyingSoftware,” for complete details on using the swinstall/swcopy GUIs.)

The Manage Patch Selection... option in the Actions menu opens theManage Patch Selection dialog. This dialog lets you:

• Select from a list of patches available to install.

• Select filters for patches.

• Set other patch options.

Figure 8-1 Manage Patch Selection Dialog

The main object list contains a read-only list of available patchcategories. The list contains the name of the category and a shortdescription. You can use the list as an aid to selecting and filteringpatches.

Chapter 8 161


The following options are also available:

• Automatically select patches for software to be installed(selection box)

Sets the autoselect_patches option. (Default is “true”.) You canuse the Filter field with this option to specify a filter for the selectionprocess.

• Automatically select patches for software installed on thetarget (selection box)

Sets the patch_match_target option. (Default is “false”.) You canuse the Filter button/specification field with this option to specify afilter for the selection process.

• Filter (button/specification field)

This field sets patch_filter option by letting you specify a patchfilter for the automatic patch selection process. Patches for softwareto be installed are automatically marked as you enter the analysisphase of installation. Only patches that match the filter criteria aremarked.

Clicking on the Filter button displays a list of example filters that youcan select from. To change the filters in the list, see “Editing thePatch Filter List” on page 162.

You can also set Save Patch Files for Rollback in the Options menu. Thissets the patch_save_files option. (The default is “true”.)

See “Default Options” on page 152 in this chapter for more informationon patch options.

NOTE As with all system options, the patch management options revert to theirdefault values at the next session unless you save and re-use the sessioninformation. See “Managing Sessions - The File Menu” on page 44 formore information.

162 Chapter 8


Editing the Patch Filter ListTo change the default list of patch filters displayed by the swinstalland swcopy GUI read a default list of patch filters that you can use asselection criteria for patch software. The list is stored in:

/var/adm/sw/defaults.patchfiltersThe system-wide default list of patch filters.

$HOME/.swdefaults.patchfiltersThe user-specific default list of patch filters.

The list of patch filters is enclosed in braces {} and separated by whitespace (blank, tab, or newline). For example:

swinstall.patch_filter_choices={*.*,c=enhancement*.*,c=critical}swcopy.patch_filter_choices={*.*,c=halts_system}

Chapter 8 163


Listing PatchesSoftware objects with the is_patch attribute set to “true” have thebuilt-in, reserved category of patch. This lets you list available patchesand patches with a certain name.

For example, to list all products and bundles in a depot that have theis_patch attribute set to true:

swlist -d -l product -l bundle -a software_spec \*,c=patch

PH003-23245,r=1.0,a=,v= PH056-45545,r=1.0,a=,v=X11,r=5.00.01,a=FLUX,v=FLB

SD automatically updates the fileset attribute applied_patches toinclude any applied patches (because it is in the patch fileset’s ancestorlist).This includes patches that may not share the same product tag asthe base filesets (ancestors) that they patch.

For example, to show patches to X11 filesets:

swlist -l fileset -a applied_patches X11

X11.Libraries PH056-45545.PH056-45545,r=1.0,a=FLUX,v=FLB

You can list the products and filesets to which a patch applies by listingthe ancestor attribute. Also, you can generate a list of patches that agiven patch superseded by listing the supersedes attribute of the patchfileset.

NOTE You can also list patches with the swlist GUI (invoked by swlist -i ).

Listing Available Patch CategoriesYou can use the -l category specification to list the categories ofavailable patches for patches that are defined with category objects.

Examples. To list the categories defined for patches in the depotmounted at /CD:

swlist -d -l category @ /CD

critical_patch Patches that fix system hangs ordata corruption S747_upgrade Patches to upgrade to an S747\security_patch Patches affecting system security

164 Chapter 8


To list a particular attribute of a category object identified by the tagcritical_patch :

swlist -a description -l category critical_patch

Patch Removal, Rollback, and CommittalTo permit future “rollback” of a patch, use the patch_save_filesoption. This option (set to “true” by default) automatically saves any filesreplaced by a patch. You can then restore the original files if you laterdecide to remove the patch.

For example,

swinstall -s sw_server -x patch_save_files=true

Rollback files are saved to the directory:

/var/adm/sw/save/ product_name/ fileset_name/ path

where product_name refers to the name of the patch that was applied.

The following rules govern patch removal and rollback:

• Removal of the “base” fileset of a patch fileset using swremoveremoves all patches to that fileset. For example, if swinstalloverwrites a particular base fileset in an update operation, allpatches for that base are removed.

• Files saved for rollback are also removed when the base fileset towhich they apply is updated or removed from the system.

• Removal of a patch automatically rolls back the saved files, unless:

• The patch_save_files option was set to “false” when thepatches were installed.

• The base fileset is also removed or updated.

• The patch_commit option (which removes the rollback files) wasrun against the patch. (This option is discussed below.)

• An installed patch that has been superseded may not be rolled backunless the “superseding” patch is also rolled back.

• SD performs disk space analysis (DSA) on the save area in the sameway it performs DSA on regular file locations.

Chapter 8 165


To save disk space when you are certain a patch operates correctly, youmay wish to “commit” the patch by removing the rollback files saved bythe patch_save_files option.

To commit a patch, invoke swmodify on the patch with the -xpatch_commit=true option. (The default value is “false”.)

For example, to commit the patch PHLK_1234 and remove itscorresponding rollback files:

swmodify -x patch_commit=true PHLK_1234

Verifying PatchesThe verify operation on a normal fileset checks that the latest files areproperly installed: when installing a patch, the ancestor fileset isupdated to have the correct attributes of the patched files.

SD verifies patch filesets by checking that files in a patch are stillproperly installed (or in the depot correctly).

Updating Patched SoftwareInstallation of a new version of a base fileset results in removal of allfilesets that patch the base fileset that you are replacing, along with anyfiles saved for potential rollback.

166 Chapter 8

Managing PatchesPackaging Patch Software

Packaging Patch SoftwareThis section contains information for users who want to package patchsoftware. Packaging involves the unique patch attributes and behaviorsdescribed below.

For complete information on packaging, objects, and attributes, seeChapter 10, “Creating Software Packages.”

Patch Software Characteristics• Each patch fileset only patches files in one base fileset. If a patch

needs to modify multiple filesets, the patch product must contain afileset for each base fileset to be modified.

• A patch fileset defines the files to be patched, and the fileset attributeis_patch must be set to “true”.

• The ancestor attribute identifies the product or fileset beingpatched.

• If a patch has the same product tag and fileset tag as the fileset it ispatching, a unique product revision or a unique fileset revision isspecified for the patch fileset

• The first patch of any particular patch stream, such as a point patch,does not have a supersedes attribute. A patch that replaces one ormore patches has the appropriate supersedes attribute.

• All patch software objects with the is_patch attribute areautomatically assigned the built-in category of patch , which is thenautomatically included in the list of category_tag attributes.

• A fileset that has the is_patch attribute will not update a filesetwith the same tag. If a fileset’s is_patch is set to “true”, therevision attribute is used to distinguish the version at the filesetlevel.

• The category_tag and is_patch attributes at all other levels ofsoftware objects besides fileset are for display and selection purposesonly. (They are not version-distinguishing attributes.)

Chapter 8 167


Patch Software Objects and AttributesSD contains attributes specifically for handling patch software. Thefollowing attributes are available to all software levels (bundles,products, subproducts, and filesets).

category objectsA software collection can contain a list of categoryobjects, which are used as a selection mechanism.Category objects are identified by the keyword“category” and contain additional information aboutthis category (a title, tag, revision, and a description ofthe category). The category_tag attribute points to aparticular category object and can appear within aproduct, bundle, subproduct, or fileset.

All software objects with the attribute of is_patch setto “true” are automatically assigned the category of“patch.” (Note that category objects and thecategory_tag attribute can be used independently ofpatches.)

See “Category Specification” on page 220 for acomplete description of category objects.

is_patch Indicates that a software object is identified as a patch.The default is “false”. Only filesets with the is_patchattribute have patched files. Other levels can beidentified as patches for the listing utilities to facilitateidentification of patch software at any level.

All software objects with the attribute of is_patch setto “true” are automatically assigned a category of“patch”.

168 Chapter 8


Patch Fileset AttributesPatch filesets generally operate like normal filesets. Differences are:

• Patch filesets have an explicit or implicit ancestor.

• Patch filesets can be installed in the same session as their base, orancestor, fileset. (The base fileset is always installed first.)

• Patch filesets can be rolled back.

• Patch filesets maintain catalog information to support these features.

• Control scripts delivered with the patch fileset run only when thatpatch fileset is installed. They do not replace the control scripts forthe base fileset.

See “Fileset Specification” on page 226 for a complete description of allpatch and non-patch fileset attributes.

Patch fileset attributes include attributes that you can specify in aproduct specification file (PSF) and attributes generated by SD.

User-specified AttributesYou can specify the following patch fileset attributes in a PSF:

ancestor software_specificationDesignates the base fileset to be patched when thepatch_match_target option is set to “true”.

If you do not provide an explicit specification, thedefault ancestor is defined as any fileset with the samefileset and product tag and a lower revision number:

product_tag. fileset_tag,r<= revision,\a=architecture,v= vendor_tag

is_sparse Indicates that a fileset contains only a subset of files inthe base (ancestor) fileset. If the is_patch attribute is“true”, is_sparse is also set to “true” for the fileset,but can be forced to “false” explicitly.

Chapter 8 169


revision The revision information (release number, version).(Determines which category object definition tomaintain in a depot when a definition being installed orcopied does not match a definition already in the depotwith the same category tag.)

A fileset revision must be specified if the patch has thesame product version and fileset tag as the fileset itpatches. Two filesets with the same revision can existin the same product version: the base fileset and one ormore patch filesets.

You can explicitly specify a fileset revision in a softwarespecification using the fr syntax. For example:

product. fileset,r=P1,fr=1.0.1

The following PSF sample specifies a patch thatsupersedes a previous patch:

filesetrevision 1.0.10supersedes product.fileset,r=P1,fr<1.0.10

supersedes software_specification

Used when a patch is replaced by a later patch. Theattribute indicates which previous patches are replacedby the patch being installed or copied. This attribute isrepeatable.

This attribute consists of a list of softwarespecifications of other patch filesets that the patchsupersedes:

supersedes product. fileset,fr= revision

When a patch supersedes another patch, thesuperseding patch is automatically selected by default.A superseding patch replaces the files of the patch itsupersedes when installed after that patch.

Patches may supersede other patches to the same base(non-patch) fileset, or they may be applied to the samebase fileset in parallel with other patches. This permitspoint patches (separate patches that patch separateparts of the same base fileset).

170 Chapter 8


You can specify superseding (cumulative) patches(patches that supersede all previous patches) with asingle software_specification if a patch strategy usesthe same product and fileset tags and an ascendingfileset revision numbering scheme.

Attributes Generated by SDThe following patch fileset attributes are generated by SD and stored inthe IPD:

applied_patchesApplies to base (non-patch) software only. Indicatespatches that have been applied to a base fileset. Anempty list for this attribute indicates the fileset hashad no patches applied.

patch_state Applies to installed patches only. Indicates the currentstate of the patch:

applied A current patch.

committed Rollback files have been deleted.

superseded A patch superseded by another patch.

saved_files_directoryThe directory used by swinstall to save the base fileswhen the patch_save_files option is set to true.Used to access the saved files when rolling back orcommitting a patch.

superseded_by Applies to installed patches only. Lists the patch thatsuperseded the fileset.

Chapter 8 171


Patch File AttributesPatches to the kernel or other libraries can be implemented and removedwith the following file level attributes:

type Designates an archive file and marks it for an archiveaction during an install or update. An archive file is a.o file that needs to be replaced in an existing archiveusing the “ar ” command.

archive_path Designates the path to the archive to which the fileshould be added (instead of installing it to the “path”location).

When used with the patch_save_files option, the.o file that previously existed in the archive is saved,and can be restored.

Sample PSF usage:

file -t a newfile.o /usr/lib/foolib.a

filetype aarchive_path /usr/lib/foolib.asource_path /usr/lib/newfile.o

172 Chapter 8


PSF ExampleThis sample PSF shows a patch for the file /build/sbin/who in the fileset:

OS-Core.CMDS-MIN,l=/,r=B.11.00,\a=HP-UX_B.11.00_32/64,v=HP

Note that the patch uses a different patch product tag than the(ancestor) fileset it patches.

category

tag normal_patchrevision 0.0title Patches of this category are for normal usedescription Normal patches for normal problems....

end

producttag PHKL_12345revision B.11.00architecture r=B.11.00,a=HP-UX_B.11.00_32/64

vendor_tag HPtitle Core Operating System (patch)machine_type *os_name HP-UXos_release ?.11.0*os_version *is_patch truecategory_tag normal_patch

filesettag CMDS-MINrevision B.10.01.001title “Patch of /sbin/who for ... “description “Patch of /sbin/who ... ”ancestor OS-Core.CMDS-MIN,\

r=B.10.01_700,a=HP-UX_B.10.01_700,v=HPis_patch truefile /build/sbin/who /sbin/who

endend

Notes:

• The ancestor attribute identifies the fileset to be patched.

• The “true” value of the is_patch attribute at the fileset level flagsthis fileset as a patch and permits rollback if you use thepatch_save_files option when you install the patch.

Chapter 9 173

Controlling Access to Software Objects

9 Controlling Access to SoftwareObjects

Along with the traditional HP-UX file access protection, all SD-UX hosts,depots, roots and products can also be protected from unauthorizedaccess by special Access Control Lists (ACLs). These ACLs offer a greaterdegree of selectivity than do HP-UX permission bits.

Topic Page

“Using Access Control Lists (swacl)” 174

“Understanding swacl” 182

“How ACLs Protect Objects” 184

“Task-Specific Permission Requirements” 192

174 Chapter 9

Controlling Access to Software ObjectsUsing Access Control Lists (swacl)

Using Access Control Lists (swacl)An ACL allows you to specify different access rights to many individualsand groups instead of just one of each.

NOTE With SD-UX, you can control ACLs only on your local host. If you need tomodify ACLs on remote hosts, you must purchase the HP OpenViewSoftware Distributor (HP Prod. No. B1996AA) which provides extendedsoftware management plus multi-site software distribution capabilities.

An ACL is a set of entries that are attached to a software object when itis created.

ACL EntriesACL entries define which users, groups and/or hosts have permission toaccess the objects. They consist of three fields (entry_type, key andpermissions) separated by colons:

entry_type[: key]: permissions

For example, an ACL entry for an object might be:

user:fred:r-ctw

which means that a user named fred can r ead, control, t est, and writethe object, but the dash signifies that he cannot i nsert or create newobjects. Permissions (c r w i t) are explained later in this chapter. Theorder in which the permissions are specified is not critical.

The ACL entry_type must be one of these values:

Table 9-1 ACL Entry Types

Type Permissions Apply To

user user principal, whose name is to be specified in thekey field

group group principal, whose name is specified in the keyfield

object_owner the owner of the object

Chapter 9 175


The user and group of the object's owner are determined andautomatically recorded at the time the object is created, based on theidentity of the person who creates it. This information is recorded asuser, group and realm. An object_owner or object_group entry type in anACL causes the ACL Manager to look up the owner and groupinformation on the object and, if a match to the requester is found, grantpermissions as specified.

There may be many user, group, and host type entries per ACL, whilethere may be only one of each of the object_owner, object_group andany_other types. There may be at most one “local” (that is, no key) otherentry and an unlimited number of “remote” (that is, keyed) other entries.

ACL KeysThe second part of the ACL entry is the key . The table below lists thepossible key values for specific entry types.

Table 9-2 ACL Entry Key Values

When listing the ACL, the host is printed in its Internet address form(for example, 15.12.89.10 ) if the local system cannot resolve theaddress from its host lookup mechanism (DNS, NIS, or /etc/hosts).

object_group members of the group to which an object belongs

other principals with no matching user and group entries

host host systems (agents acting for users)

any_other principals not matching any other entry

Type Permissions Apply To

Entry Type Key Content

user a user's name

group a group name

other I

any_other no key allowed

host a host's name

176 Chapter 9


ACL PermissionsSix different permissions are grantable by the ACL:

Permission Meaning

control Permission to edit or change the ACL.

read Permission to list depot, roots and products andattributes.

write Permission to change a host, depot, root or product.

insert Permission to install a new product, depot or root.

test Permission to test access to an object (that is, read theACL)

all A wildcard that grants all the above permissions. It isexpanded by swacl to crwit .

In the ACL entry, these permissions are abbreviated c , r , w, i , t and a.The meaning of permissions is different for different types of objects andthe permissions do not have to appear in any specific order. Roots do notprovide product level protection, so all permissions on products installedon roots are controlled by the ACL protecting the root itself. Product levelprotection is provided on depots in this way: the depot's ACL protects thedepot itself while product ACLs protect the products within the depot.

The table below summarizes object permissions and ACLs to which theymay be applied.

Table 9-3 ACL Permission Definitions

Permission Allows You To:

Hostsystem

Root Depot Producton depot

[c]ontrol ModifyACLs

ModifyACLs

ModifyACLs

ModifyACLs

[t]est Test access to an object, read (list) the ACL itself

Chapter 9 177


a. Write permission means permission to change or delete theobject, except the host source object may not be deleted.

b. Read permission on containers (i.e. hosts, roots and depots) ispermission to list the contents; on products it is permission tocopy/install the product.

[i]nsert Insert anew depotor root

Insert anewproduct

Insert anewproduct

N/A

[w]rite a change host changeroot orproducts

changedepot

changeproduct

[r]ead b list depotsand roots

list root&prod attrs

list depot& prodattrs

readproductfiles

Permission Allows You To:

178 Chapter 9


SyntaxYou can view or change ACL entries and permissions by using the swaclcommand, an SD-UX tool that allows you to list and change ACLs.

The syntax for swacl is:

swacl -l level[-D acl_entry|-F acl_file|-M acl_entry][-f software_file][-x option=value][-X option_file] [software_selections] [@targets]

ExamplesTo list the ACLs for the COBOL and FORTRAN products in depot/var/spool/swtest :

swacl -l product COBOL FORTRAN @ /var/spool/swtest

To list the product template ACL on host newdist:

swacl -l host

To read, edit, then replace the ACL protecting the default depot/var/spool/sw :

swacl -l depot > new_acl_file

vi new_acl_file

swacl -l depot -M user:steve:- -M user:george:- \@ newdist:/var/spool/sw

To delete entries for local user rick from all products in the default localdepot:

swacl -l product -D user:rick \*

Chapter 9 179


Command OptionsThe swacl command supports these options:

Option Action

-v Turn on verbose output to stdout. Lets you see theresults of the activity while it is being performed.

-f software file Read a list of software selections from a separate fileinstead of (or in addition to) the command line. In thisseparate file, blank lines and lines beginning with #(comments) are ignored. Each software selection mustbe specified on a separate line. For an example of asoftware selection file, see “Command Operands” onpage 31.

-l level Level to edit. Level designations are the literals: host,depot, root, product, product_template,global_soc_template or global_product_template. ACLtemplates are discussed in “ACL Templates” on page189 in this chapter.

You can change an ACL with of any of the followingoptions (if none are used, swacl just prints thespecified ACLs). These options are mutually exclusive.

-M acl_entry Adds a new ACL entry or changes the permissions ofan existing entry. You can enter multiple -M options.

-D acl_entry Deletes an existing entry from the ACL associated withthe specified object. You can enter multiple -D options.

-F acl_file Assigns the ACL information contained in acl_file tothe object. All existing entries are removed andreplaced by the entries in the file. You can enter onlyone -F option.

-x option=value Set the session option to value and override the defaultvalue or a value in an options file (-X option file).Multiple -x options can be specified. See the section“Changing Default Options” on page 181 for moreinformation on defaults.

-X option file Read session options and behaviors fromoption_file . The default values for system optionsare provided in the file /var/adm/sw/defaults . You

180 Chapter 9


can also provide a personal option file,$HOME/.swdefaults . This option file overrides thosevalues in the system defaults file. For a complete listingof system options, see the file/usr/lib/sw/sys.defaults . This file lists thepossible values and behaviors for each option for eachcommand.

Command OperandsThe swacl command supports the standard software selection syntax.For more details on software selection syntax and an example of asoftware selection file, see “Command Operands” on page 31.

Chapter 9 181


Changing Default OptionsIn addition to the command-line option listed above, several swaclbehaviors and policy options can also be changed by editing extendedoption and default values found in the system-wide defaults file:/var/adm/sw/defaults


$HOME/.swdefaults


swacl.agent_auto_exit=true

Table 9-4 ACL Default Options




select_local=true

level= software=

rpc_binding_info=ncacn_ip_tcp:2121 ncadg_ip_udp:[2121]

targets=

rpc_timeout=5 verbose=1

182 Chapter 9

Controlling Access to Software ObjectsUnderstanding swacl

Understanding swaclA typical acl_file looks like this:

# swacl Installed Software Access Control List## For host: prewd:/## Date: Wed May 19 16:39:58 1993## Object Ownership: User=root

Group=sysRealm=prewd.fc.hp.com

# default_realm=prewd.fc.hp.comobject_owner:crwituser:rml:crwituser:[email protected]:crwitgroup:swadm:crwitany_other:crwit

The header information (lines marked with #) gives the object's nameand owner and the name of the user's realm or host name of his/hersystem.

The swacl command, when invoked without the -M, -D or -F options,reads the specified ACL, converts it into plain text and prints it to thescreen so you can see it. If you re-direct the output of the command to afile, you can then edit that file and change the permissions in it. Afterediting, you can use the -F file option described above to replace the oldACL. This procedure gives you full ACL editing capabilities.

You must have “test” permission within the ACL to produce the edit file(list the ACL) and “control” permission to change it with -F , -D or -Moptions.

If the replacement ACL contains no detectable errors and you have theproper permission on the ACL, the replacement succeeds. If thereplacement fails because you lack permission to make the change, anerror is generated and the object is skipped.

You may change or delete existing entries, or you may add additionalentries to the ACL.

CAUTION It is possible to edit an ACL so that you cannot access it! Caution shouldbe used to avoid accidentally removing your own control (c) permissionson an ACL. As a safeguard, the local superuser should always edit ACLs.

Chapter 9 183

Controlling Access to Software ObjectsUnderstanding swacl

How ACLs are Matched to the UserIt is important to note that permissions in ACLs are determined by amatch to a single ACL entry (except for group entries), not to anaccumulation of matching entries. Simply put, checking is done from themost restrictive entry types to the broadest. If a match is found in a userentry type, no further checking is done, and the permissions for that userare fully defined by the permissions field of the matched entry. That thematched user may be a member of a group with broader permissions is ofno consequence.

NOTE The local host superuser has access to all local objects, irrespective ofACLs.

The ACL matching algorithm is:

1. If user is local superuser, then grant all permissions, else

2. If user is owner of the object, then grant “object_owner” permissions,else

3. If user matches a “user” entry, then grant “user” permissions, else

4. If any “group” entries match, then accumulate the permissionsgranted by all group_entries that match the user's primary andsupplementary groups, else

5. If an appropriate “other” entry matches, then grant “other”permissions, else

6. If an “any_other” entry, then grant “any_other” permissions, else

7. Grant no permissions

184 Chapter 9

Controlling Access to Software ObjectsHow ACLs Protect Objects

How ACLs Protect ObjectsThe control of product insert/delete permissions differ on roots anddepots.

The permission for anyone to insert or delete a product on a root iscontained within the root's ACL. If you have write permission on a root,you can change or delete any product on that root; there is no productlevel control on roots.

Figure 9-1 Access Control Lists

The depot ACL controls insertion (that is, creation) of new products,while the inserted object has its own ACL controlling modification anddeletion. This allows the creator (that is, the owner) of a product on adepot to make changes to, or even delete, the product without requiringthe broader write permission that could affect other users' products onthe same depot.

This is useful for product control, because it allows you to assignmanagement control for a specific product, once it is created, to adelegated administrator. Also, when a product is created on a depot, theuser and group identity of the creator is recorded in the productinformation.

Chapter 9 185


If the product ACL contains an object_owner entry granting writepermissions to the owner, then the product creator will automaticallyhave rights to change or delete the product. Therefore, the depot can bemore widely opened to insertion because users with insert permissioncan only copy in new products or delete their own products: you don'thave to worry about a user erroneously (or maliciously) deleting somecritical product that they shouldn't control.

The rationale for this protection scheme is borrowed from a mechanismintroduced in the BSD file system. With “write” permissions on a BSDdirectory, you may create a file in the directory. If the sticky mode bit isset on the directory, only the file owner, the directory owner or superusermay remove or rename the file.

For example: In /tmp , owned by root, with wide-open “write” permissionand the sticky bit set (that is, mode 1777), anyone can create files thatnobody else (except themselves and superuser) can remove, making /tmpa more secure place to store temporary work because someone else can'tdelete your files there.

Installing or copying from an unregistered depot requires you to haveinsert permission on the depot's host. If this permission is denied, thedepot's daemon log will contain the message:

ERROR: Access denied to SD agent at host lucille on behalf ofrob@lucille to start agent on unregistered depot"/users/rob/depot". No (i)nsert permission on host.07/23/93 15:51:06 MDT

This message shows that it is the AGENT at lucille that did not haveinsert permission on the depot's host, not the user rob@lucille.

The remote host ACL must have two entries granting insert permission:one for the user, and one for the target host.

For example, for user “rob” to be allowed to install a product on his host“lucille” from an UNREGISTERED depot on source host “desi”, thecommand

swacl -l host @ desi

must show the minimum ACL entries:

user:rob@lucille:-i-host:lucille:-i-

Note that “rob” could alternatively register the depot with the swregcommand with only the first entry above before running swinstall orswcopy .

186 Chapter 9


Host System ACLsThe host system is the highest level of protected object. An ACL protectseach host, controlling permission to create depots and roots on the host.A host ACL may grant the following permissions:

Permission Meaning

read (r ) Permission to obtain host attributes, including a list ofdepots and roots on the host.

write (w) Permission to change the host object.

insert (i ) Permission to create and register a new depot or rooton the host.

control (c ) Permission to edit or change the ACL.

test (t ) Permission to test access to an object and list the ACL.

A sample host system ACL that grants depot and root source creation,source listing and ACL administration to a user named “rob” and giveopen permission to list the depots and roots on the host, would be:

user:rob:r-ic-any_other:r

Note that since any_other does not have (t )est permission, only rob canlist this ACL, because he has (c )ontrol permission.

Root ACLsPrincipals (users) identified in ACLs that are protecting roots aregranted permission to manage installed products. The permissionsassociated with a root are:

Permission Meaning

insert (i ) Permission to install a new product.

read (r ) Permission to list the contents of the root.

write (w) Permission to delete the root itself or the products inthe root.

control/test (c /t ) Same as host ACLs above.

A sample root ACL that grants a user named “lois” permission to read,write and insert software and members of the group named “swadm” allpossible permissions is:

Chapter 9 187


user:lois:rwi-group:swadm:crwit

When a root is created, it is automatically protected by a default ACLderived from its host. swacl can be used to change the initial values ofthis ACL. See the section on “ACL Templates.”

Depot ACLsPrincipals identified in ACLs that are protecting depots are users whohave been granted permission to manage the depot and to create newproducts. The permissions associated with a depot are:

Permission Meaning

insert (i ) Permission to copy a new product into the depot.

read (r ) Permission to list the contents (products) of the depotsource.

write (w) Permission to delete the depot (if it is empty), andunregister itself (not the products in the depot).

control (c ) Same as above.

test (t ) Same as above.

A sample depot ACL that grants

1. its creator all permissions;

2. user “george” permission to list and insert software products;

3. members of group “swadm” permission to list and insert products,change the ACL and delete the depot itself; and

4. everyone else permission to list the contents of the depot,

would be:

object_owner:crwituser:george:-r-i-group:swadm:crwi-any_other:-r-

When a depot is created, it is automatically protected by a default ACLderived from its host. Products inserted in that depot will automaticallybe protected by an ACL derived from the depot. This concept is discussedin the section “ACL Templates.”

188 Chapter 9


Product ACLsProduct ACLs only apply to products on depots. Products on roots areprotected by the root's ACL. There are two classes of principal that aregranted access rights to products:

Principal Access Rights

users Granted various administrative permissions. This classincludes groups and others, both local and remote.

hosts Target systems (agent/daemons) granted readpermissions to allow product installation.

Permissions on products are:

Permission Meaning

write (w) Permission to users to change and delete the productand/or product information.

read (r ) Permission granted to target_hosts to read thesource-depot product. (that is, grant permission to aremote system to install the protected product).

control (c ) Permission to edit or change the ACL.

test (t ) Permission to test access to an object.

A sample product ACL that grants user “swadm” and the creator of theproduct all permissions and allows open read permission (allowing freedistribution to all systems) would be:

user:swadm:crwobject_owner:crwany_other:-r-

Note again, that when a product object is created, it is automaticallyprotected by a default ACL from the depot/root source or, absent that,one from the host.

Chapter 9 189


ACL TemplatesThere are two special ACLs that are used to create initial ACLs toprotect newly created objects - product ACL templates(global_product_templates or product_templates) and container ACLtemplates (global_soc_templates).

Figure 9-2 ACL Templates

When a product is installed on a depot with swcopy or swpackage , thesystem uses a product ACL template (provided by the depot thatcontains that product) to define the initial permissions of the newproduct's ACL.

The system uses the product ACL template of the host system(global_product_template) to initialize the product ACL template of thenew depot and uses the container ACL template of the host system(global_soc_template) to initialize depot and root ACLs.

Thus, there are three ACLs on the host:

• Host ACL

Attached to, and controlling access to the host object itself.

• Container ACL Template (global_soc_template)

Used to initialize the ACL protecting new depots and roots created onthe host.

190 Chapter 9


• Product ACL Template (global_product_template)

The ACL that is used to initialize the product ACL template ondepots that are created on the host.

There are also two ACLs on product depots:

• The depot's ACL that is used to determine permissions on the depot.

• The depot's product ACL template (product_template) that is used toinitialize the ACLs protecting new products on the depot.

There is one ACL on the installation (root):

• The root ACL that protects the root and products installed on it.

And finally, there is one ACL on the product:

• The product's ACL that is used to determine permissions on theproduct.

Every host must have an ACL protecting it and a pair of template ACLs(product and container) to provide initialization data for implicit depotand product ACLs. All three are created when HP-UX is installed on thehost.

Default ACL Template EntriesThe host system's container ACL template dictates initial permissions onall depots and roots that are introduced on that host. The host alsocontains a master copy of a product ACL template that is copied to eachnew depot. A default set of host ACLs is provided at the time HP-UX isinstalled that can be altered by the system administrator. The contentsof these host-system ACLs immediately after installation are:

Host ACL

The Host ACL below grants permission to group “swadm” to insert anddelete depots and roots on the host and to change this ACL. It also allowsglobal (any_other) permission to list the depots and roots on the host andto list the ACL itself:

object_owner:swadm:crwitgroup:swadm:crwitany_other:-rt

Remember, the local superuser always has all permissions, even withoutan ACL entry.

Chapter 9 191


To take advantage of “swadm” entries in these examples, the “swadm”group must be created by the system administrator.

Container ACL Template

The container ACL template below grants the owner or creator(object_owner) of a new depot or root permission to manage that newdepot or root and to change its ACL. It also grants global permission(any_other) to list products in the new depot or root.

object_owner:crwitgroup:swadm:crwitany_other:-rt

Product ACL Template

The product ACL template below grants permission to perform alloperations on products installed on depots on this host to the respectivecreator (that is, owner), via the object_owner entry, of each product. Italso grants permission to read (that is, install) and test the product to“any host” (the any_other entry).

object_owner:crwitgroup:swadm:crwitany_other:-rt

In addition to encompassing all hosts, the any_other entry also applies toall other users except, in this case, the product's owner. However, productread permission has meaning only to host principals, and other possibleproduct permissions never apply to hosts, therefore the any_other entrymay be overloaded with user and host permissions, if desired, withoutany danger of ambiguity. This overloading should be kept in mind whenusing the SD-UX commands to execute solutions.

These host ACL defaults provide a good starting point for control overthe management functions while providing open access to read thesoftware for installation on root targets.

192 Chapter 9

Controlling Access to Software ObjectsTask-Specific Permission Requirements

Task-Specific Permission Requirements

Packaging• If the depot does not exist, swpackage verifies that the user has

insert permission on the host.

• swpackage verifies that the user has insert permission on a depot.

• swpackage verifies that the user has write permission on a product,if it already exists.

Listing• To list potential depots, the source agent verifies that the user has

read permission on host.

• To list potential products, the source agent verifies that the user hasread permission on depot or root.

Copying• Any list operations required to facilitate this function must be

checked as described in the swlist section above.

• If the depot does not exist, swcopy verifies that the user has insertpermission on the target host.

• The agent verifies that the user has insert permission on the depot.

• The agent verifies that the controller user has write permission onthe product, if it already exists.

• The source agent verifies that the system has read permission on thesource product.

• The source (depot) agent verifies that the depot is registered. If not,the agent verifies that the controller user and the target agent systemeach has insert permission on the source's host.

Chapter 9 193


Installing• Any list operations required to facilitate this function must be

checked as described in the swlist section above.

• The agent verifies that the user has insert permission on the targetroot.

• The agent verifies that the user has write permission on the root, ifthe product already exists.

• The source (depot) agent verifies that the system has read permissionon the source product.

• The source (depot) agent verifies that the depot is registered. If not,the agent verifies that the controller user and the target agent systemeach has insert permission on the source's host.

Removal• If the object is a product on a depot, the agent verifies that the user

has write permission on the product.

• If the object is a product on a root, the agent verifies that the user haswrite permission on the root.

• If the object is a depot or a root, or the last product contained in one ofthese, before removing the container the agent must verify that theuser has delete permission on the root or depot.

ConfigurationThe same permission checks are made as for the swremove operationabove, except that this command does not apply to depots.

Verify• If the object is a product on a depot, the agent verifies that the user

has read permission on the product.

• If the object is a product on a root, the agent verifies that the user hasread permission on the root.

194 Chapter 9


Registering Depots• To register a new depot, swreg requires “read” permission on the

depot in question and “insert” permission on the host.

• To unregister a registered depot, the swreg command requires“write” permission on the host.

Sample ACLs for EditingHere are some examples based on the following ACL that is protecting aproduct (FORTRAN) created by user rob whose local host islehi.fc.hp.com :

# swacl Product Access Control Lists## For host: lehi:/## Date: Wed May 19 16:39:58 1993## For product: FORTRAN,r=9.0,v=HP# Object Ownership: User=root

Group=sysRealm=lehi.fc.hp.com

# default_realm=lehi.fc.hp.comobject_owner:crwituser:barb:-rtuser:ramon:-rtgroup:swadm:crwithost:alma.fc.hp.com:-rtany_other:-rt

To list the ACL for the product FORTRAN in depot /var/spool/sw (thedefault depot) and prepare it for editing, type:

swacl -l product FORTRAN &>acl_tmp

which will bring the above ACL into the file acl_tmp , ready for editing.Edit the acl_tmp file with any suitable text editor.

To replace the modified ACL, type:

swacl -l product -F acl_tmp FORTRAN

To edit the default product template on a depot /var/spool/sw_dev ,use:

swacl -l product_template @ /var/spool/sw_dev $>tmp_file

then edit the tmp_file and replace the ACL:

Chapter 9 195


swacl -l product_template -F tmp_file \@ /var/spool/sw_dev

To delete user barb's and group swadm's entries:

swacl -D user:barb -D group:swadm -l product FORTRAN

To give user ramon permission to change the product FORTRAN:

swacl -M user:ramon:trw -l product FORTRAN

To add an entry for user pam with complete management permission:

swacl -M user:pam:a [“a” is shorthand for “crwit ”]

To add an entry to grant every user in group swadm at remote hostsdewd and stewd full management control of the product FORTRAN onthe default local depot:

swacl -M group:swadm@dewd:a -M group:swadm@stewd:a \-l product FORTRAN

To list the ACL protecting the default depot at host dewd:

swacl -l depot @ dewd

196 Chapter 9


Chapter 10 197

Creating Software Packages

10 Creating Software Packages

SD provides a flexible packaging specification that lets you createpackages to fit many software build and manufacturing processes.

This chapter describes the tasks associated with packaging software fordistribution.

Topic Page

“Prerequisites” 198

“Overview of the UNIX Packaging Process” 199

“Identifying the Products to Package” 200

“Writing a UNIX Control Script” 202

“Creating a Product Specification File (PSF)” 203

“Packaging the Software (swpackage)” 239

“Verifying the Software Package” 248

“Advanced Packaging Topics” 249

198 Chapter 10

Creating Software PackagesPrerequisites

PrerequisitesBefore you begin packaging software, ensure the following:

• SD is installed and configured on the machine where you intend tocreate your software package.

• The software to package is installed, or its files are available to bepackaged.

Chapter 10 199

Creating Software PackagesOverview of the UNIX Packaging Process

Overview of the UNIX PackagingProcessThe software objects that SD packages, distributes, installs andmanages are files. The SD packager uses these files after they have beenbuilt (compiled) and installed into specific directory locations by thesoftware build process. These directory locations range from separate,unconnected directory trees to the specific file locations that are requiredto make the software run on your system. You can specify files by a rootdirectory (gathering all files below it) or by individual files. The fileattributes can be taken from the files themselves, specified separately foreach file or specified for a set of files.

The packaging process consists of the following tasks:

1. Identifying the package.

Determine what files and directories you want to include in yoursoftware package, and determine product structure. Your softwarepackage can consist of files, filesets, subproducts, and products.

2. Write UNIX control scripts (optional).

You can write control scripts and include them in your SD package.These scripts let you perform additional checks and operationsbeyond those supported by SD.

3. Create a file of package attributes (PSF file).

SD uses a Product Specification File (PSF) to define the productpackage. Create a PSF file to describe your package.

4. Run the swpackage command.

The SD swpackage command reads the PSF file, analyzes theproduct definitions, and packages the source files and informationinto product objects. It then creates and inserts the product into thedistribution depot.

200 Chapter 10

Creating Software PackagesIdentifying the Products to Package

Identifying the Products to Package

Determining Product ContentsThe first step in packaging software is to determine what files anddirectories you want included in the software product. These files anddirectories must follow certain guidelines to support the configurationyou want.

Key points in this structure are:

• Where are shareable (for example, executables) and non-shareable(for example, configuration) files installed?

• How is configuration used to put non-shareable files in place?

Determining Product StructureDetermine the product structure that your software should follow. SDprovides four levels of software objects:

Level Objects

Filesets (Required) Filesets include the actual product files,information that describes those files (attributes) andseparate control scripts that are run before, during orafter the fileset is installed, copied or removed. Filesetsare the smallest manageable (selectable) softwareobject. Files must be grouped into one or more filesets.Filesets must be grouped into one or more products.(Filesets can be members of only a single product.)

Subproducts (Optional) Subproducts are used to group relatedfilesets within a product if the product contains severalfilesets. Subproduct definitions are optional.

Products (Required) Filesets (and/or subproducts) must begrouped into one or more products. They are usuallygrouped into collections that form a set of relatedsoftware, or match the products that a customer

Chapter 10 201

Creating Software PackagesIdentifying the Products to Package

purchases. The SD commands maintain a productfocus, while still allowing the flexibility to managesubsets of the products via subproducts and filesets.

Bundles (Optional) Bundles are provided only by the HP factory.You cannot package in bundles.

NOTE You can define different versions of products for different platforms andoperating systems, as well as different revisions (releases) of the productitself. You can include different product versions on the samedistribution media.

202 Chapter 10

Creating Software PackagesWriting a UNIX Control Script

Writing a UNIX Control ScriptSD supports execution of product and fileset control scripts that allowyou to perform additional checks and operations beyond those supportedby SD. The swask , swinstall , swconfig , swverify , and swremovecommands each execute one or more control scripts on the UNIX primaryroots. SD supports the following types of scripts, which can be defined fora product or fileset:

• checkinstall

• preinstall

• postinstall

• unpreinstall

• unpostinstall

• configure

• verify

• unconfigure

• checkremove

• preremove

• postremove

• request

You can write the scripts and include them in your SD package. All thesescripts are optional, but are typically needed in the product to correctlycomplete the installation.

See Appendix 11, “Using Control Scripts,” for additional informationabout writing control scripts.

Chapter 10 203

Creating Software PackagesCreating a Product Specification File (PSF)

Creating a Product Specification File(PSF)SD uses a Product Specification File (PSF) to define the physical productpackage. The PSF provides a “road map” that identifies the productaccording to its attributes, contents, compatibilities, dependencies anddescriptions. The PSF drives the swpackage session. It describes howthe product is structured and defines the attributes that apply to it.

The PSF can:

• Define vendor information (optional) for groups of products (includingall products), or for individual products.

• Specify one or more products (required).

• For each product, define attributes for one or more subproducts(optional), filesets (required), and files (required).

• Define attributes for the distribution depot/media (optional).

• Specify what computer(s) and operating system(s) the productsupports.

• Define attributes that describe the software objects.

Product Specification File Examples

Minimal PSFHere is an example of the minimum PSF: one that includes only therequired keywords:

producttag SD

filesettag commands

file swcopy /usr/sbin/swcopy

NOTE You must use an absolute path for the second file term in this minimumformat.

204 Chapter 10


Typical PSFHere is a portion of a typical PSF; it describes the SD product:

# PSF which defines an example product.depot

layout_version 1.0# Vendor definition:vendor

tag HPtitle Hewlett-Packard Companydescription < data/description.hp

category tag system_mgt title Systems Management Applications description These are the system management applications revision 1.0

end# Product definition:product

tag SDrevision A.01.00architecture HP-UX_B.11_32/64

vendor_tag HP is_patch false

title HP OpenView Software Distributornumber B1991Acategory_tag system_mgtdescription < data/descr.sdcopyright < data/copyr.sdreadme < data/README.sdmachine_type *os_name HP-UXos_release ?.11.*

os_version ?directory /is_locatable false

# Create a product script which executes during the swremove# analysis phase. (This particular script returns an ERROR,# which prevents the removal of the SD product.)

checkremove scripts/checkremove.sd

# Subproduct definitions:subproduct

tag Managertitle Management Utilitiescontents commands agent data man

endsubproduct

tag Agenttitle Agent componentcontents agent data man

end

Chapter 10 205


# Fileset definitions:fileset

tag commandstitle Commands (management utilities)revision 2.42description < data/descr.commands

# Dependenciescorequisites SD.data

corequisites SD.agent# Control files:

configure scripts/configure.commands# Files:

directory ./commands=/usr/sbinfile swinstallfile swcopy. . .directory ./nls=/usr/lib/nls/Cfile swinstall.catfile swpackage.cat

directory ./ui=/var/adm/sw/uifile *. . .

end# commands# other filesets

. . .fileset

tag mantitle Manual pages for the Software Distributorrevision 2.05directory ./man/man1m=/usr/man/man1m.Zfile *directory ./man/man4=/usr/man/man4.Zfile *directory ./man/man5=/usr/man/man5.Zfile *

end#man

end#SD

From the above example, the packager can get all the informationneeded to package the product properly into a distribution depot.

206 Chapter 10


PSF SyntaxEach SD object (product, subproduct, filesets, and file) has its own set ofattributes and each attribute has a keyword that defines it. Mostattributes are optional; they do not all need to be specified in the PSF.Each attribute has its own specific requirements, but the following rulesapply:

• Keyword syntax is:

keyword value

• All keywords require one or more values, except as noted. If thekeyword is there but the value is missing, a warning message isgenerated and the keyword is ignored.

• Place comments on a line by themselves or after the keyword-valuesyntax. Comment lines are designated by preceding them with #.

• Use quotes when defining a value (for example, description) that canspan multiple lines. Quotes are not required when defining asingle-line value that contains embedded whitespace.

• Any errors encountered while reading the PSF cause swpackage toterminate. Errors are also logged to both stderr and the logfile.

PSF Object SyntaxThe following tables and sections describe the PSF keywords, theallowable values for each keyword, and the syntax for the objects you candefine in a PSF. Keywords marked with a + apply to products only.Keywords marked with a - apply to bundles only. Keywords marked witha * are of the version_component type, as well as the type indicated inthe table.

Chapter 10 207


Table 10-1 Keywords Used in the Product Specification File

Keyword Value Size(bytes Example

Distribution Class

distributionlayout_versiontagcopyrightdescriptionnumbertitle

end

revision_stringtag_stringmulti_line_stringmulti_line_stringone_line_stringone_line_string

64648 k8 k64256

1.0EXAMPLE_DEPOT <data/copyr.depotdata/descr.depotB2358-13601Example packages

Vendor Class

vendortagdescriptiontitle

end

tag_stringmulti_line_stringone_line_string

648 k256

HP<data/desc.hpHewlett-Packard Co.

Category Class

categorytagdescriptionrevisiontitle

end

tag_stringmulti_line_stringrevision_stringone_line_string

648k64256

patch_normalFor normal problems0.0Category of Patches

208 Chapter 10


Product Class

product or bundle*tag*architecturecategory_tag

-contents

copyrightdescriptiondirectoryis_locatableis_patchmachine_typenumberos_nameos_releaseos_version+postkernel+readme+revision+share_linktitle*vendor_tagend

tag_stringone_line_stringone_line_stringrepeatable list ofsoftware specsmulti_line_stringmulti_line_stringpath_stringbooleanbooleanuname_stringone_line_stringuname_stringuname_stringuname_stringpath_stringmulti_line_stringrevision_stringone_line_stringone_line_stringtag_string

64642568 k8 k8 k8 k1 k9964646464642551 M6425625664

SDHP-UX_B.11.00_32/64Systems Managementpr.fs,r=1.0,a=,v=

<data/copyr.sd<data/descr.sd/falsefalse*B1998AHP-UX?.11.*?/usr/bin/kernel_build<data/README.sdA.01.00

Software DistributorHP

Subproduct Class

subproducttagcontents

descriptiontitle

end

tag_stringone-line list of tagstring valuesmulti_line_stringone_line_string

64

8 k256

Managercommands agent datadata man<data/desc.mgrManagement Utilities


Chapter 10 209


Fileset Class

fileset*tagancestor

architecturecategory_tagcorequisitedescriptionis_kernelis_patchis_rebootis_sparsemachine_typeos_nameos_releaseos_versionprerequisite

*revisionsupersedestitle

end

tag_stringrepeatable list ofproduct. filesetrevision_stringtag_stringsoftware_specmulti_line_stringbooleanbooleanbooleanbooleanuname_stringuname_stringuname_stringuname_stringsoftware_specrevision_stringsoftware_specone_line_string

64

8064

8 k999964646464

648192256

commandsproduct.oldfilesetoldproduct.filesetHP-UX_B.11.00_32/64patch_normalSD.man.r>=2.0<data/descr.cmdfalsefalsefalsefalse-*HP-UX?.11.*?SD.agent,r>=2.02.42product.fileset, fr=revisionSD Commands

control_files Class

control_filesdirectoryexrequisitesfile_permissionsfile

end

path_mapping_stringsoftware_specpermission_stringfile_specification

./commands=/usr/sbinSD.man.r>=2.0-u 0222 -o root -g sys-m 04555 bin/swinstall (or) *


210 Chapter 10


Table 10-2 Control File Attributes

Selecting the PSF Layout Version

NOTE PSF syntax conforms to the layout_version=1.0 of the IEEEStandard 1387.2: Software Administration(POSIX). Previous versions ofSD supported the POSIX layout_version=0.8 syntax, whichcontinues to be supported.

You can select the layout version in the depot definition in the PSF (see“Product Specification File Semantics” below) or with thelayout_version option for swpackage , swmodify , swcopy , orswlist .

Differences between the two layout versions include the following:

• The vendor is handled differently.

For the current standard (layout_version=1.0 ), each vendor class definition is associated only with subsequent products orbundles that contain a vendor_tag attribute that matches the tagattribute within the vendor class definition.

For the previous standard (layout_version=0.8) or if you do notspecify a layout_version , products or bundles are automaticallyassociated with the last vendor class you defined at the distribution

Keyword Type Size Example

checkinstallcheckremoveconfigurecontrol_filepostinstallpostremovepreinstallpreremoverequestunconfigureunpreinstallunpostinstallverify

path_stringpath_stringpath_stringpath_stringpath_stringpath_stringpath_stringpath_stringpath_stringpath_stringpath_stringpath_stringpath_string

1 k1 k1 k1 k1 k1 k1 k1 k1 k1 k1 k1 k1 k

./scripts/checkinstall

./scripts/checkremove

./scripts/configure

./scripts/subscripts

./scripts/postinstall

./scripts/postremove

./scripts/preinstall

./scripts/preremove

./scripts/request

./scripts/unconfigure

./scripts/unpreinstall

./scriipts/unpostinstall

./scripts/verify

Chapter 10 211


level, or from a vendor that you define within the product or bundle.Explicitly defined vendor_tag attributes (with or without a value)take precedence.

• The corequisites and prerequisites have singular titles forlayout_version=0.8 (that is, corequisite and prerequisite ).(See “Dependency Specification” below.)

• Category objects and keywords are handled differently.

For layout_version=1.0 (current standard):

• category_tag is a valid product attribute that replaces thecategory and category_title attributes.

• You can define category class objects.

For layout_version=0.8 (previous standard:

• category and category_title are valid product attributes thatreplace the category_tag attribute.

• category class objects are not recognized.

For a more complete description of PSF requirements forlayout_version=0.8 , refer to the swpackage.4 manual page in aprevious version of HP-UX.

PSF Value TypesThe values for each attribute keyword in your PSF must be of a specifictype discussed below.

NOTE PSF syntax conforms to the layout_version=1.0 of the POSIX 1387.2Software Administration standard. Previous versions of SD supportedthe POSIX layout_version=0.8 syntax, which continues to besupported. See “Selecting the PSF Layout Version” above for moreinformation.

212 Chapter 10


Value Parameters

boolean • Maximum length: 9 bytes

• One of the values “true” or “false”.

• Examples: true , false

file_specification

• Maximum length: none

• Explicitly specifies a file or directory to be packaged,using the format:

[-m mode] [-o [owner[,]] [uid]] [-g [group[,]][gid]][-v ][source] [destination]

• The source and destination can be paths relative tosource and destination directories specified in thepath_mapping_string .

• You can also use * to include all files below thesource directory specified by a directory keyword.

• Examples: -m 04555 sbin/swinstall or * (todenote all files and directories)

multi_line_string

• Maximum length: 8 kbyte (1Mbyte for a readme file)

• Multi-line strings support all isascii () characters.They represent one or more paragraphs of text.They can be specified in-line, surrounded bydouble-quotes. They can also be stored in a file, andspecified using the syntax:

< filename

• Example: </mfg/sd/description

one_line_string• Maximum length: 256 bytes

• One-line strings support a subset of isasciicharacters only.

• No isspace characters, except for space and tab, areallowed.

• Examples: Hewlett-Packard Company

Chapter 10 213


path_mapping_string


• A value of the form: source[=destination] where thesource defines the directory in which subsequentlydefined files are located. The optional destinationmaps the source to a destination directory in whichthe files will actually be installed.

• Examples: /mfg/sd/files/usr = /usr

path_string • Maximum length: 255 bytes for tapes, 1024 bytesfor depots

• An absolute or relative path to a file. Manyattributes of this type are restricted to 255 bytes inlength. This restriction is due to the tar(1)command, which requires a file’s basename(1) be<= 100 bytes, and a file’s dirname(1) to be <= 155bytes. (Some implementations of tar enforce < andnot <=.)

• Examples: /usr /mfg/sd/scripts/configure

permission_string• Maximum length: none

• A value of the form:

[-m mode|-u umask] [-o [ owner[,]][ uid]][-g [ group[,]][ gid]]

where each component defines a defaultpermissions value for each file and directory definedin a fileset. The default values can be overridden ineach file’s specific definition. The owner and groupfields are of type tag_string . The uid and gidfields are of type unsigned integer. The mode andumask are unsigned integers, but only supports theoctal character set: “0”-“7”.

• Examples: -u 0222 -o root -g sys

214 Chapter 10


revision_string• Maximum length: 64 bytes

• Revision strings contain zero or more dot-separatedone_line_string (above).

• Examples: 2.0 , B.11.00

software_specification


• Software specifications are used to specify softwarein dependencies, ancestors and other attributes, aswell as command line selections. The SD commandsand attributes support the following syntax for eachsoftware_specification:

bundle[. product[. subproduct][. fileset]][, version]orproduct[. subproduct][. fileset][, version]

• The version component has the form:

[,r <op> revision] [,a <op> arch] [,v <op> vendor][,c <op> category] [,l =location] [,fr <op> revision][,fa <op> arch]

• location applies only to installed software andrefers to software installed to a location otherthan the default product directory.


• The <op> (relational operator) component can beof the form: ==, >=, <=, < , >, or !=, whichperform individual comparisons ondot-separated fields.

For example, r>=B.10.00 chooses all revisionsgreater than or equal to B.10.00. The systemcompares each dot-separated field to findmatches. Shell patterns are not allowed withthese operators.

• The = (equals) relational operator lets youspecify selections with the shell wildcard andpattern-matching notations: [ ] , * , ?, and !

Chapter 10 215


For example, the expression r=1[01].* returnsany revision in version 10 or version 11.

• All version components are repeatable within asingle specification (e.g. r>=A.12, r<A.20 ). Ifmultiple components are used, the selectionmust match all components.

• Fully qualified software specs include the r= , a=,and v= version components even if they containempty strings.

• No space or tab characters are allowed in asoftware selection.

• The software instance_id can take the place ofthe version component. It has the form:

[instance_id]

within the context of an exported catalog, whereinstance_id is an integer that distinguishesversions of products and bundles with the sametag.

• Examples: SD.agent orSD,r=2.0,a=HP-UX_B.11.00_32

tag_string • Maximum length: 64 bytes

• Tag strings support a subset of isascii() charactersonly:

• Requires one or more characters from: “A-Z”,“a-z”, “0-9”, including the first character.

• The isspace() characters are not allowed.

• SDU metacharacters not allowed:. , : =

• Shell metacharacters not allowed:# ; & () {} | < >

• Shell quoting characters not allowed:“ ‘ ’ \

• Directory path character not allowed: /

• Examples: HP, SD

216 Chapter 10


uname_string

• Maximum length: 64 bytes

• Uname strings containing a subset of isascii()characters only.

• No isspace() characters are allowed.

• Shell pattern matching notation allowed: [ ] * ? !

• Patterns can be “ORed” together using theseparator: |

• Examples: 9000/7*:*|9000/8*:* , HP-UX,?.11.*

Chapter 10 217


Product Specification File SemanticsThe following sections describe how to specify a PSF and defineskeywords.

Distribution (Depot) Specification. Distribution attributes aredesigned for distribution tapes and CD-ROMs to allow you to listinformation about the media (that is, find out what media it is).

The distribution (tape) specification for a PSF looks like this:

distributionlayout_version 1.0tag APPLICATIONS_CDcopyright < data/copyright.cddescription <data/description.cdnumber B2358-13601title HP-UX Applications Software Disk

[<vendor specification>] optional<product specification> required[<product specification>] optional. . .

end

Each keyword above defines an attribute of a distribution depot. Thedistribution keyword is always required; all other attributes areoptional.

Keyword Definition

distribution or depot

Keyword that begins the distribution specification.Each keyword defines an attribute of the distributiondepot or tape itself. All keywords are optional, even if adistribution specification is included in a PSF.

layout_version PSF syntax conforms to the layout_version=1.0 ofthe POSIX 1387.2 Software Administration standard.Previous versions of SD supported the POSIXlayout_version=0.8 syntax, which continues to besupported. (You can also select the layout version withthe layout_version option for swpackage ,swmodify , swcopy , or swlist .) See “Selecting thePSF Layout Version” on page 210 for moreinformation.

tag The short name of the target depot (tape) beingcreated/modified by swpackage .

218 Chapter 10


copyright The text (or a pointer to a filename) for the copyrightinformation for the depot's contents.

description The description of the target depot; either the textitself or a pointer to a filename that contains the text.

number The part or manufacturing number of the distributionmedia (CD or tape depot).

title The full name of the target depot (tape) beingcreated/modified by swpackage .

end Ends the distribution specification, no value isrequired. This keyword is optional. If you use it and itis incorrectly placed, the specification will fail.

Chapter 10 219


Vendor Specification . The vendor attributes let you add adescription to the PSF. The layout_version defined for the PSF filedetermines how vendor specifications are associated with products andbundles. If a layout_version is not defined or is defined as 1.0, vendorspecifications will be associated with all subsequent products andbundles that define a matching vendor_tag attribute.

If a layout_version of 0.8 is specified, all subsequent products andbundles will automatically be assigned to a vendor_tag from the lastvendor object defined at the distribution level, if any, or from a vendorobject defined within a product or bundle, unless a vendor_tag isexplicitly defined.

The following is an example of a vendor specification:

vendortag HPdescription < data/description.hptitle Hewlett-Packard Company

end

Each keyword defines an attribute of a vendor object. If a vendorspecification is included in the PSF, swpackage requires the vendor andtag keywords.

vendor Keyword that begins the vendor specification.

tag Defines the identifier (short name) for the vendor.

title Defines the full name (one line description) for thevendor.

description Defines the multi-paragraph description of the vendor;the value is either the text itself (within double-quotes)or a pointer to the filename containing the text.

end Ends the vendor specification. This keyword isoptional.

220 Chapter 10


Category Specification . A software collection can contain a list ofcategory objects that are used as a selection mechanism. Categoryobjects are identified by the keyword “category” and contain additionalinformation about the category. The category_tag attribute points to aparticular category object and can appear anywhere within a product,bundle, subproduct, or fileset.

All sofware objects with the attribute of is_patch set to “true” areautomatically assigned a category of “patch.”

NOTE The layout_version keyword in the distribution class affects howcategories are associated with products and bundles. See “Selecting thePSF Layout Version” and “Product Specification File Semantics” abovefor more information.

The category specification looks like this:

categorytag patch_normaltitle Category of patchesdescription For normal problemsrevision 0.0

end

Each keyword defines an attribute of the category object. If a categoryspecification is included in the PSF, swpackage requires only thecategory and tag keywords.

KeywordDefinition

category Keyword that begins the category specification.

tag The category short name identifier. Associates thisobject with a product or bundle. This tag attributemust match the category_tag attribute in theproduct or bundle.

title A one-line string that defines the full name for thecategory.

description A multi-line description of the category. The descriptionvalue can consist of text or a filename for a text file.

revision The revision information (release number, version).Determines which category object definition tomaintain in a depot when a definition being installed orcopied does not match a definition already in the depotwith the same category tag.

Chapter 10 221


end An optional keyword that ends the specification. Novalue is required. If you place this keyword incorrectlyin the PSF, the specification will fail.

Product or Bundle Specification . The product specification is arequired class in the PSF. It lets you identify the product you arepackaging.

NOTE The layout_version keyword in the distribution class affects howcategory and vendor objects are associated with products and bundles.See “Selecting the PSF Layout Version” and “Product Specification FileSemantics” above for more information.

The product specification looks like this:

producttag SDarchitecture HP-UX_B.11.00_32/64category_tag systems_management- contents prod.fsl,r=1.0,a=,v=copyright </mfg/sd/data/copyrightdescription </mfg/sd/data/descriptiondirectory /usris_locatable falseis_patch falsemachine_type *number J2326AAos_name HP-UXos_release ?.11.00.*os_version [A-Z]postkernel /usr/lbin/kernel_build+ readme </mfg/sd/data/READMErevision 2.0title Software Distributorvendor_tag HP

+ [<vendor specification>] optional+ [<subproduct specification>] optional+ <fileset specification> required+ [<fileset specification>] optional. . .

end

For each product object specified, swpackage requires only the productand tag keywords, plus one or more contained fileset definitions. Foreach bundle specified, swpackage requires the bundle , tag andcontents keywords.

222 Chapter 10


Keyword Definition

product Required keyword that begins the productspecification.

tag The product's identifier (short name).

architecture The UNIX target system on which the product orbundle will run. Provides a human-readable summaryof the four uname attributes (machine_type ,os_name , os_release and os_version ), whichdefine the exact target system(s) the product supports.

bundle Required keyword that begins the bundle specification.

category_tag A repeatable tag-based attribute identifying a set ofcategories of which the software object is a member.This is used as a selection mechanism and can be usedindependent of patches. The default value is an emptylist or patch if the is_patch attribute is set to true .Like vendor_tag , this attribute can be used as apointer to a category object that contains additionalinformation about the category (for example, a one-linetitle definition and a description of the category).

NOTE The category tag patch is reserved. When the is_patch productattribute is set to “true”, a built-in category_tag attribute of valuepatch is automatically included with the product definition.

contents The list of fully qualified (all versiondistinguishing attributes included) software specs forthe bundle.

copyright A multi-line description of the product's copyright;either the text itself (in double quotes) or a pointer tothe filename that contains the text.

description A multi-paragraph description of the product; eitherthe text itself (within double-quotes) or a pointer to thefilename that contains the text.

directory The default, absolute pathname to the directory inwhich the product’s files will be installed (the rootdirectory of the product). If not specified, swpackageassigns a value of /.

Chapter 10 223


is_locatable Defines whether a product or bundle can be installed toany product directory, or whether it must be installedinto a specific directory. The attribute can be set to“true” or “false”. If not defined, swpackage sets thedefault attribute to “false.”

is_patch A boolean flag that identifies a software object as apatch. The default value is “false”. When set to “true”, abuilt-in category_tag attribute of value patch isautomatically included with the product definition.

machine_type The machine type on which the product will run. If notspecified, the keyword is assigned a wildcard value of *,meaning it will run on all machines. If there aremultiple machine platforms, you must separate eachmachine designation with a | (vertical bar). Forexample, a keyword value of 9000/7*|9000/8* meansthe product will run on all HP Series 9000 Model 7XXor all HP 9000 Series 8XX machines. Alternatively, thevalue 9000/[78]* would also work.

Other examples:

* If not concerned with the machinetype.

9000/7??:32* Series 700, 32-bit capable hardwarerequired.

*:*64 64-bit capable hardware required.

*:32: 32-bit capable harware required.

9000/7??:*64 Series 700, 64-bit capable hardwarerequired.

9000/[68]??:32* Series 800, 32-bit capable hardwarerequired.

9000/[68]??:*64 Series 800, 64-bit capable hardwarerequired.

The value is matched against a UNIX target'suname -m [: getconf _CS_HW_CPU_SUPP_BITSresult.

number The part or order number of the product.

224 Chapter 10


os_name The operating system name on which the product willrun. If not specified, the attribute is assigned a value of* , meaning it will run on all operating systems. If thereare multiple operating systems, use wildcards or the |symbol to separate them. The value is matched againsta UNIX target'suname -s [: getconf _CS_KERNEL_BITS r esult.

os_release The release number of the product's operating system.If not specified, the attribute is assigned a value of * ,meaning it will run on all operating systems. If thereare multiple operating systems, use wildcards or the |symbol to separate them. The value is matched againsta UNIX target's uname -r result.

os_version The version number of the operating system(s) onwhich the product will run. If not specified, theattribute is assigned a value of * , meaning it runs onany version. If there are multiple operating systems,use wildcards or the | symbol to separate them. Thevalue is matched against a UNIX target's uname -vresult.

readme A text file of the README information for the product.The value must be a pointer to the filename containingthe text

revision The revision information (release number, version) forthe product or bundle.

title A one-line string that further identifies the product orbundle.

vendor_tag Associates this product or bundle with a vendor objectdefined separately in the PSF, if that object has amatching tag attribute.

end Ends the product or bundle specification. No value isrequired. This keyword is optional. If you use it and itis incorrectly placed, the specification will fail.

Chapter 10 225


Subproduct Specification . The subproduct specification lets yougroup filesets within a larger product specification. Subproducts areoptional. A subproduct specification looks like this:

subproducttag Managercontents manager agent packager man docdescription </mfg/sd/data/manager/descriptiontitle SD Management Interfaces Subset

end

Each keyword defines an attribute of a subproduct object. If a subproductobject is specified, swpackage requires the subproduct , tag , andcontents keywords.

Keyword Definition

subproduct Keyword that begins a subproduct specification.

tag The subproduct's identifier (short name).

contents A whitespace-separated list of the subproduct’s filesettag values (that is, contents fileset fileset filesetfileset...).

In the PSF, fileset definitions are not contained withinsubproduct definitions. The contents keyword is usedto assign filesets to subproducts. This linkage allows afileset to be contained in multiple subproducts.

description A multi-line description of the subproduct; either thetext itself (within double-quotes), or a pointer to thefilename that contains the text.

title A one-line string that further identifies the subproduct.

end Ends the subproduct specification. No value isrequired. This keyword is optional. If you use it and itis incorrectly placed, the specification will fail.

226 Chapter 10


Fileset Specification . The fileset specification is required in thePSF. Use filesets to group files together.

A fileset specification looks like this:

filesettag manBancestor OLDSD.MANarchitecture HP-UX_B.11.00_32/64category_tag manpgdescription </mfg/sd/data/man/descriptionis_kernel falseis_patch falseis_reboot falseis_sparse falsemachine_type *os_name HP-UXos_release ?.11.00.*os_version ?revision 2.40supersedes product.fileset,fr=revisiontitle Commands (management utilities)

[<control script specification>] optional. . .[<dependency specification>] optional. . .<file specification> required[<file specification>] optional. . .

end

Each keyword defines an attribute as a fileset object. For each filesetobject specified, swpackage requires the fileset and tag keywords,plus zero or more file specifications.

Keyword Definition

tag The fileset identifier (short name).

architecture Describes the target system(s) on which the fileset willrun if filesets for multiple architecture are included ina single product. Provides a human-readable summaryof the four uname(1) attributes which define the exacttarget system(s) the product supports. Many filesets donot include an architecture; only a product architectureneed be defined.

ancestor A list of filesets that will match the current filesetwhen installed on a target system, if thematch_target installation option is specified. Alsodesignates an ancestor fileset to check for whenpatch_match_target is defined.

Chapter 10 227


category_tag A repeatable tag-based attribute identifying a set ofcategories of which the software object is a member.This is used as a selection mechanism and can be usedindependent of patches. The default value is an emptylist or patch if the is_patch attribute is set to “true”.

Like vendor_tag , this attribute can be used as apointer to a category object that contains additionalinformation about the category (for example, a one-linetitle definition and a description of the category).

NOTE The category tag patch is reserved. When the is_patch file attribute isset to “true”, a built-in category_tag attribute of value patch isautomatically included with the file definition.

description Defines the multi-paragraph description of the fileset;the value is either the text itself (within double-quotes)or a pointer to the filename containing the text.

is_kernel A value of “true” defines the fileset as being acontributor to the operating system kernel; the targetsystem(s) kernel build process will be invoked after thefileset is installed. If this attribute is not specified,swpackage assumes a default value of “false”.

is_patch Identifies a software object as a patch. The defaultvalue is “false”. When set to “true”, a built-incategory_tag attribute of value patch isautomatically included.

is_reboot A value of “true” declares that the fileset requires asystem reboot after installation. If this attribute is notspecified, swpackage assumes a default value of“false”.

is_sparse Indicates that a fileset contains only a subset of files inthe base (ancestor) fileset and that the contents are tobe merged with the base fileset. The default value is“false”. If the is_patch attribute is “true”, is_sparseis also set to “true” for the fileset, although it can beforced to “false”.

machine_type The machine type on which the product will run. If notspecified, the keyword is assigned a wildcard value of *,meaning it will run on all machines. If there are

228 Chapter 10


multiple machine platforms, you must separate eachmachine designation with a | (vertical bar). Forexample, a keyword value of 9000/7*|9000/8* meansthe product will run on all HP Series 9000 Model 7XXor all HP 9000 Series 8XX machines. Alternatively, thevalue 9000/[78]* would also work.

Other examples:

* If not concerned with the machinetype.

9000/7??:32* Series 700, 32-bit capable hardwarerequired.

*:*64 64-bit capable hardware required.

*:32: 32-bit capable harware required.

9000/7??:*64 Series 700, 64-bit capable hardwarerequired.

9000/[68]??:32* Series 800, 32-bit capable hardwarerequired.

9000/[68]??:*64 Series 800, 64-bit capable hardwarerequired.

The value is matched against a UNIX target'suname -m [: getconf _CS_HW_CPU_SUPP_BITSresult.

os_name Defines the operating system(s) on which the files willrun if a fileset architecture has been defined. (If notspecified, swpackage assigns a value of *, meaning thefiles run on all operating systems.) If there are multipleoperating systems, use wildcards or use the ’|’character to separate them. This attribute shouldpattern match to the value ofuname -s [: getconf KERNEL_BITS]on the supported target system(s).

os_release Defines the operating system release(s) on which thefiles will run. (If not specified, swpackage assigns avalue of *, meaning the files run on all releases.) Ifthere are multiple operating system releases, use

Chapter 10 229


wildcards or use the ’|’ character to separate them.This attribute should pattern match to the value ofuname -r on the supported target system(s).

os_version Defines the operating system release(s) on which thefiles will run. (If not specified, swpackage assigns avalue of *, meaning the files run on all releases.) Ifthere are multiple operating system releases, usewildcards or use the ’|’ character to separate them.This attribute should pattern match to the value ofuname -r on the supported target system(s).

revision Defines the revision (release number, version number)of the fileset.

supersedes Used when a patch is replaced by (or merged into) alater patch. The attribute indicates which previouspatches are replaced by the patch being installed orcopied. This attribute value is a list of softwarespecifications of other patches that this patchsupersedes.

title Defines the full name (one-line description)of the fileset.

end Optional keyword to end the fileset specification. Novalue is required. If you place this keyword incorrectly,the file specification will fail.

230 Chapter 10


Dependency Specification . You can use the PSF to specifydependencies between filesets. You can also define dependenciesbetween:

• A fileset and another product (namely, a subset of that product).

• A particular fileset within that product.

• The entire product.

Dependencies are defined within the fileset class definition. (See “FilesetSpecification” above.)

SD supports two types of dependencies:

Dependency Definition

Corequisites A corequisite dependency states that a fileset requiresanother software to operate correctly.

NOTE A corequisite dependency DOES NOT IMPLY ANY LOAD ORDER(run-time dependency).

Prerequisites A prerequisite dependency states that a fileset requiresthe other software to be installed and/or configuredcorrectly BEFORE it can be installed and configured.Prerequisites control the order of an installation withswinstall . (Install-time dependency).

The swinstall , swcopy , swverify , and swremove commandsunderstand dependencies. You can control whether dependencies mustbe present to install the software. By default, swinstall will not installunless dependencies can be met.

NOTE A dependency must always be specified using a software specificationthat starts with the product tag for the requisite software.

Chapter 10 231


Control Script Specification . SD supports execution of productand fileset control scripts that allow you to perform additionalchecks and operations beyond those supported by SD. The swinstall ,swconfig , swverify , and swremove commands each execute one ormore vendor supplied scripts. All these scripts are optional.

For a complete description of control scripts and guidelines for their use,see Appendix 11, “Using Control Scripts.”

File Specification . Within a fileset specification, you can specify thefollowing file types to be packaged into the fileset by swpackage :

• control script

• directory

• hard link

• regular file

• symbolic link

• archive

swpackage generates an error if the PSF contains an unrecognized orunpackageable file type.

The swpackage command supports specific mechanisms for specifyingthe files contained in a fileset:

Mechanism Operation

default permissionspecification For all or some of the files in the fileset, you can

define a default set of permissions.

directory mapping You can point swpackage at a source directoryin which the fileset's files are located. Inaddition, you can map this source directory tothe appropriate (destination) directory in whichthis subset of the product's files will be located.

explicit filespecification For all or some of the files in the fileset, you can

name each source file and destination location.

232 Chapter 10


recursive (implicit)file specification If directory mapping is active, you can simply

tell swpackage to recursively include all files inthe directory into the fileset.

These mechanisms can all be used in combination with the others.

Default Permission Specifications. By default, a destination file willinherit the mode, owner, and group of the source file. You can use thefile_permissions keyword to set a default permission mask, owner,and group for all the files being packaged into the fileset:

file_permissions [-m mode| -u umask] [-o [owner[,]] [uid]] \[-g [group[,]][gid]]

Specification Operation

file_permissions

This keyword applies only to the fileset in which it isdefined. You can specify multiple file_permissions ;later definitions replace previous definitions.

-m mode This option defines a default (octal) mode for all files.

-u umask Instead of specifying an octal mode as the default, youcan specify an octal umask ( 1) value that gets“subtracted” from an existing source file's mode togenerate the mode of the destination file.

By specifying a umask, you can set a default mode forexecutable files, non-executable files, and directories. (Aspecific mode can be set for any file using -m.)

-o [owner[,]][uid]

This option defines the destination file's owner nameand/or or uid. See the discussion of the -o option in“Explicit File Specification” on page 234 for moreinformation.

-g [group[,]][gid]

This option defines the destination file's group nameand/or or gid. See the discussion of the -g option in“Explicit File Specification” on page 234 for moreinformation.

-t type Defines files that need not exist before packaging.

Chapter 10 233


The following examples illustrate the use of the file_permissionkeyword.

• Set a read only 444 mode for all file objects (requires override forevery executable file and directory):

file_permissions -m 444

• Set a read mode for non-executable files, and a read/execute mode forexecutable files and directories:

file_permissions -u 222

• Set the same mode defaults, plus an owner and group:

file_permissions -u 222 -o bin -g bin

• Set the same mode defaults, plus a uid and gid:

file_permissions -u 222 -o 2 -g 2

• Set the owner write permission in addition to the above:

file_permissions -u 022 -o 2 -g 2

• If you do not define file_permissions , swpackage uses thedefault value file_permissions -u 000 for destination file objectsbased on existing source files. (Meaning the mode, owner/uid,group/gid are set based on the source file, unless specific overridesare specified for a destination file.)

Directory Mapping. (Optional) The directory source [= destination]specification defines the source directory under which subsequentlylisted files are located. In addition, you can map the source directory to adestination directory under which the packaged files will be installed.

For example, the definition:

directory /build/hpux/mfg/usr = /usr

causes files from the /build/hpux/mfg/ directory to have the prefix/usr/sbin when installed. The destination directory must be a supersetof the product's directory attribute, if defined in the productspecification. If the product's directory is defined, and the destinationis not a superset, swpackage generates an error.

The destination directory must be an absolute pathname. If not, thenswpackage generates an error.

234 Chapter 10


The source directory can be either an absolute pathname, or a relativepathname. If relative, swpackage interprets it relative to the currentworking directory in which the command was invoked.

If the source directory does not exist, swpackage generates an error.

Explicit File Specification . You can explicitly specify the files to bepackaged into a fileset. If you want to recursively include all files anddirectories, use the recursive file specification (file * ).

You can use the directory keyword to define a source (and destination)for explicitly specified files. If no directory keyword is active, then thefull source path and the absolute destination path must be specified foreach file. An explicit file specification overrides or adds to, on a file-by-filebasis, the specifications set by the directory and/orfile_permissions keywords.

An explicit file specification uses this form:

file [-v] [-m mode] [-o [owner[,]][uid]] [-g [group[,]][gid]][-t type] [ source] [destination]

Specification Operation

file This keyword specifies an existing file (usuallywithin the currently active source directory) toinclude in the fileset.

source This value defines the path to a file you want toinclude in the package.

If this is a relative path, swpackage will search for itrelative to the source directory set by the directorykeyword. If no source directory is active, swpackagewill search for it relative to the current workingdirectory in which the command was invoked.

All attributes for the destination file object are takenfrom the source file, unless a file_permissionkeyword is active, or the -m, -o , or -g options arealso included in the file specification.

destination This value defines the destination path at which thefile will be installed. If destination is a relative path,the active destination directory set by the directorykeyword will be prefixed to it. If it is a relative path,and no destination directory is active, swpackagegenerates an error. If the destination is not specified,

Chapter 10 235


then the source path is used as the destination, withthe appropriate mapping done with the activedestination directory (if any).

-m mode This option defines the (octal) mode for a file ordirectory at its destination.

-o[owner[,]][uid] This option defines the file's owner name and/or uid at

its destination. If only the owner is specified, then theowner and uid attributes are set for the destinationfile based on the packaging host's. If only the uid isspecified, it is set as the destination's uid and noowner name is assigned. If both are specified, eachsets the corresponding attribute for the file object.

During an installation, the owner attribute is used toset the owner name and uid, unless the owner name isnot specified or is not defined in the UNIX Targetsystem's /etc/passwd . In this case, the uid attributeis used to set the uid.

-g[group[,]][gid] This option defines the file's group name and/or gid at

its destination. If only the group is specified, then thegroup and gid attributes are set for the destinationfile based on the packaging host's /etc/group . Ifonly the gid specified, it is set as the destination's gidattribute and no group name is assigned. If both arespecified, each sets the corresponding attribute for thefile object.

During an installation, the group attribute is used toset the group name and gid, unless the group name isnot specified or is not defined in the UNIX Targetsystem's /etc/group . In this case, the gid attributeis used to set the gid.

-t type Defines a file of type d (directory), s (symbolic) or h(hard link) for files that need not exist beforepackaging.

-v This option marks the file as volatile, meaning it canbe modified (that is, deleted) after it is installedwithout impacting the fileset.

236 Chapter 10


Files that may have their attributes (size, lastmodified time, etc.) changed through normal useafter they are installed should be specified in the PSFfile as volatile (by specifying -v on the line definingthe file). swverify will not, by default, check fileattributes for files that have the is_volatileattribute set to “true” (see the check_volatileoption for swverify ).

Error Messages

When processing existing files in a source directory, swpackageidentifies the following four kinds of errors:

• Cannot search directory (permission denied)

• Cannot read the file (permission denied)

• Unsupported file type encountered (source file must be a controlscript, regular file, directory, hard link or symbolic link)

• File does not exist

Using Directory and File Keywords

The following examples illustrate the use of the directory and filekeywords.

• Include all files under /build/hpux/mfg to be rooted under /usr :

directory /build/hpux/mfg=/usrfile *

• Include only certain files under /build/hpux/mfg/ , to be rootedunder /usr and /var/adm/sw :

directory /build/hpux/mfg=/usrfile sbin/swinstallfile sbin/swcopy. . .directory /build/hpux/mfg=/var/adm/swfile nls/swinstall.cat nls/en_US.88591/swinstall.catfile defaults newconfig/defaultsfile defaults defaults

• Explicitly list files, no directory mapping specified:

file /build/hpux/mfg/usr/bin/swinstall /usr/sbin/swinstallfile /build/hpux/mfg/usr/bin/swcopy /usr/sbin/swcopyfile /build/hpux/mfg/data/nls/swinstall.cat

/var/adm/sw/nls/en_US.88591/swinstall.catfile /build/hpux/mfg/data/defaults /var/adm/sw/newconfig/\

defaultsfile /build/hpux/mfg/data/defaults /var/adm/sw/defaults

Chapter 10 237


• Use all specification types to include files:

directory /build/hpux/mfg/usr=/usrfile *directory /build/hpux/mfg/data=/var/adm/swfile defaults newconfig/defaultsfile /build/hpux/mfg/data/defaults=/var/adm/sw/defaults

Recursive File Specification . The file * keyword directsswpackage to include every file (and directory) within the current sourcedirectory in the fileset. swpackage attempts to include the entire,recursive contents of the source directory in the fileset. (Partialwildcarding is not supported, e.g. file dm* to indicate all files startingwith “dm”.)

All attributes for the destination file object are taken from the source file,unless a file_permission keyword is active (this keyword is describedbelow).

The user can specify multiple

directory source[= destination]file *

pairs to gather all files from different source directories into a singlefileset.

If you do not want to recursively include all files and directories, use theexplicit file specification.

The directory keyword must have been previously specified before thefile * specification can be used. If not, swpackage generates an error.

Error Messages

When processing the directory recursively, swpackage encounters thefollowing errors:

• Cannot search directory (permission denied)

• Cannot read the file (permission denied)

• Unsupported file type encountered

Re-Specifying FilesIn addition to being able to specify files as a group (with file * ) forgeneral attributes, the PSF also allows you to “re-specify” files withinthat definition to modify individual attributes.

238 Chapter 10


For example, suppose you wanted to specify all the files in a fileset whichcontained 100 files. All these files were to be recursively “discovered” andpackaged into the fileset. Most of them would have the same owner,group, and mode (and other file attributes).

Out of those 100 files, there might be five that are volatile (that is, youdon't care if they get modified or deleted). So, instead of listing all 100files individually, and using the -v option for the five, you could specifyall 100 with file * and then modify the five individually in their ownway:

directory source = /product file *

file -v 1file -v 2file -v 3file -v 4file -v 5

This also works well for permissions. If nearly all the 100 files above hadthe same permission attributes, but three should have a different ownerand mode, you could specify:

directory source = /product

file_permissions -o bin -g bin -m 555file *

file_permissions -o root -g other -m -04555file 1file 2file 3

Essentially, this capability combines the recursive file specificationsfunction with explicit file specification (as described above).

Chapter 10 239

Creating Software PackagesPackaging the Software (swpackage)

Packaging the Software (swpackage )The swpackage command packages software products into adistribution depot. You can use the software in the depot to create aCD-ROM or tape; or you can use it as a source to install or update from,using the SD swinstall command. Both depot and tape distributionsuse the same format.

The swpackage command:

• Uses the PSF to organize files into products, subproducts, andfilesets.

• Can include control scripts and PSFs to further specify how to handlethe software when installing it onto the target system.

• Sets permissions of the files being packaged.

• Packages both a simple, one-fileset product and a complex productwith many filesets (and many subproducts).

• Provides a way to repackage (change) existing products.

swpackage OverviewWhen you run the swpackage command, you define the PSF (amongother options). swpackage begins the session by telling you the source,target, software selections, and options used, then performs up to fourphases:

Phase Operation

Package Selection

The system reads the PSF to determine the product,subproduct, and fileset required for the structure; which filesare contained in each fileset; and the attributes associatedwith these objects. The swpackage command checks the PSFfor syntax errors during this phase. If it encounters an error,the swpackage session terminates.

240 Chapter 10


Analysis The swpackage command analyzes the packagingtasks and requirements BEFORE actually packagingthe software to the target depot or tape. swpackagecompares the software to be packaged against thetarget depot (tape) to make sure it can attempt thepackaging operation. If it encounters an error duringanalysis, the session terminates.

Package Building

swpackage packages the source files and informationinto a product object, and creates/inserts the productinto the distribution depot. If the depot does not exist,swpackage will create it (but not register it). You musthave appropriate SD permission to create this newdepot on the local host.

If the target (destination) is a tape media, a temporarydepot is created.

Make Tape This phase is performed only if you are packaging to adistribution tape. This phase copies the source files anda temporary depot catalog to the tape.

swpackage cannot compress files when writing to atape.

Figure 10-1 shows an overview of the swpackage session.

Chapter 10 241


Figure 10-1 An Overview of the Packaging Process

Command Syntax

NOTE The swpackage command provides only a command line user interface.There is no Graphical User Interface for the SD packaging tasks.

The syntax for swpackage is:

swpackage [-p][-v[v]][-V][-d directory| device][-f software_file][-s product_specification_file| directory][-S session_file][-x option=value][-X option_file][ software_selections][@ target_selection]

For example, to package the software products defined in the PSFproduct.psf into the distribution depot /var/spool/sw and previewthe task at the “very verbose” level before actually performing it, type:

swpackage -p -vv -s product.psf @ /var/spool/sw

242 Chapter 10


Command OptionsThe swpackage command supports the following options:

Option Action

-p Previews the specified package session withoutactually creating or modifying the distribution depot(tape).

-v Turns on verbose output to stdout and lists messagesfor each product, subproduct and fileset beingpackaged. Adding a second v to the command (-vv )turns on “very verbose” output that displays all verbosemessages plus messages for each file being packaged.(The swpackage logfile in/var/adm/sw/swpackage.log is not affected by thisoption.) SD is shipped with -v enabled by default. Toreduce messages to the minimum, setswpackage.verbose=0 in the defaults file, or use the-x command line option. See Appendix A, “DefaultOptions and Keywords.”.

-V List the SDU data model revision(s) which swpackagecan read. swpackage always packages using the latestSDU data model revision.

product_specification_file |directory

Specifies the PSF to use. Alternatively, use it to specifyan existing directory as the source for the packagingsession.

-d directory|device

If creating a distribution directory, this option definesthe pathname of the directory.

If creating a distribution tape, this option defines thedevice file on which to write the distribution. Whencreating a distribution tape, the tape device (file) mustexist, and the target_type=tape option must bespecified.

-x option=value Allows setting or changing an option on the commandline. Overrides the defaults set in the defaults file.

Chapter 10 243


-X option_file Uses the options in a specific options file. Forinformation on changing packaging options or defaults,refer to “Changing Options in the Defaults File”.

-f software_file Reads the list of software_selections from a file. See thedescription below for software_selections.

software_selections

The swpackage command supports the standard SDsoftware_selections operand:

product[.subproduct][.fileset][,version]

If this specification is used, swpackage packages onlythose software selections from the full set specified inthe PSF. You can specify the software_selections eitheron the command line or in a file (-f ) option.

If this specification is NOT used, swpackage packagesall the products listed in the PSF.

target_selection

If you are creating a distribution depot (directory), thisoperand defines the location of the directory. Withoutthis operand, /var/spool/sw is used as the defaultdepot directory.

If you are creating a distribution tape, this operandnames the device file on which to write the tar archive.The device file must exist so that swpackage candetermine if the media is a DDS tape or a disk file.Without this operand, swpackage uses the device file/dev/swtape .

244 Chapter 10


Package Selection PhaseIn the Package Selection Phase, swpackage reads the specified PSF anduses it to identify the products, filesets, and depots.

Package Analysis PhaseThere are four checks performed on your packaging process during thePackage Analysis Phase:

1. Check for unresolved dependencies.

For every fileset in each selected product, swpackage checks to see ifa requisite of the fileset is NOT also selected or NOT already presentin the target depot. Any unresolved dependency within the productwill generate an ERROR. An unresolved dependency across productswould produce a NOTE.

2. Check your authorization to package (or re-package)products.

For each new product (a product that does NOT exist on the targetdepot) swpackage checks the target depot to see if you havepermission to create a new product on it (“insert” permission). If youdo not, the product is not selected.

For each existing product (one you are re-packaging) swpackagechecks to see if you have permission to change it (“write” permission).If you do not, the product is unselected.

If all products are not selected because permission is denied, thesession terminates with an ERROR.

If the depot is a new depot or if you are packaging to a tape, thisauthorization check is skipped. If you have permission to create a newdepot, then you have permission to create products within it. Since atape session first writes to a temporary depot then copies it to tape, ifyou have permission to create a new (temporary) depot, you canpackage to tape.

3. Check for software being repackaged.

For each selected product, swpackage checks to see if the productalready exists in the target depot.

• If it does exist, swpackage checks to see which filesets are beingadded (new filesets) or modified.

Chapter 10 245


• If it exists and all filesets are selected, swpackage checks to see ifany existing filesets have been obsoleted by the new product.

4. Performing Disk Space Analysis (DSA)

swpackage will check to see if you have enough free disk space on thetarget depot to package the selected products.

There are three possible results:

• Part of the package will encroach into minfree space on the disk,causing an ERROR.

• The package phase will require more space on the disk than isavailable, causing an ERROR.

• A NOTE will show the impact the packaging phase will have onavailable disk space.

The disk space analysis check is not performed for tape targets.Instead, the Copy to Tape Phase does a “tape space calculation” toensure that the tape can accommodate all the software beingpackaged. If one tape cannot hold it all, then swpackage willpartition the software across multiple tapes.

See the section “Advanced Packaging Topics” later in this chapter forinformation on how to override disk space analysis.

246 Chapter 10


The Package Building PhaseWhen packaging a product, if the target depot does not exist, swpackagecreates it. If it does exist, swpackage will merge new product(s) into it.For each different version of the product, a directory is created using thedefined product tag attribute and a unique instance number (instanceID) for all the product versions that have the same tag.

Before a new storage directory is created, swpackage checks to see ifthis product version has the same identifying attributes as an existingproduct version.

If all the identifying attributes match, you are re-packaging (modifying)an existing version. Otherwise, swpackage creates a new version in thetarget distribution.

The packaging process uses an explicit ordering to avoid corrupting thetarget distribution if a fatal error occurs. Each product is packaged in itsentirety and when all specified products have been packagedsuccessfully, the distribution's global INDEX file is built/rebuilt. Withineach product construction, the following order is adhered to:

1. Check if the product is new or already exists. If it is new, create theproduct's storage directory.

2. For each fileset in the product, copy the fileset's files into their storagelocation (within the product's storage directory), and create thefileset's catalog (database information) files.

3. After the individual filesets, create the product's informational files(meta-files).

A target depot is only the first step in creating a CD-ROM. If the ISO9660 standard format is desired, a utility to perform this conversionwould be necessary. This conversion is not supported by swpackage .

Distribution tapes are created in tar format. To create the tape,swpackage first builds the products into a temporary distribution depot.(The depot is removed when swpackage completes.) To conserve space,all files exist as references to the real source files. After the distributiondepot is constructed, swpackage then archives it, along with the realfiles, onto the tape device.

When archiving a product that contains kernel filesets onto a tapemedia, swpackage puts these filesets first within the archive to provideefficient access by swinstall . swpackage also orders filesets based onprerequisite dependency relationships.

Chapter 10 247


Output of Logfile MessagesThe log file /var/adm/sw/swpackage.log captures the output fromthe swpackage session. swpackage by default logs messages at theverbose level.

Message logging for swpackage :

• Sends verbose messages to stdout .

You can set the verbose option to 0 which causes reduced output tobe sent to stdout .

• Sends ERRORS/WARNINGS to stderr .

• No logfile messages are written in preview mode.

• The logfile is equal to stdout plus stderr .

A sample log:

======= 01/27/95 18:58:45 MST BEGIN swpackage SESSION

* Session started for user "[email protected]".

* Source: vewd:test.psf* Target: vewd:/var/spool/sw* Software selections:

** Options:

preview trueverbose 1loglevel 1logfile /var/adm/sw/swpackage.log

source_type filetarget_type directory

package_in_place falsefollow_symlinks falseinclude_file_revisions falseenforce_dsa truereinstall_files truereinstall_files_use_cksum falsewrite_remote_files falsecreate_target_acls true

* Beginning Selection Phase.* Reading the Product Specification File (PSF) "test.psf".* Reading the product "SD" at line 1.* Reading the fileset "commands" at line 4.

======= 01/27/95 18:58:45 MST END swpackage SESSION

248 Chapter 10

Creating Software PackagesVerifying the Software Package

Verifying the Software PackageIf swpackage created a depot (rather than storing the package in anexisting registered depot), you must still register the depot with theswreg command. For information on how to register the depot, refer to“Registering Depots Created by swpackage”.

To verify the integrity of the product Pascal in the local default depot:

swverify -d Pascal

You may also want to test the package by installing it on a system. Toinstall, use the swinstall command. For example, to install thepackage named Pascal , located on the default depot /var/spool/sw inthe host svrhost , onto the primary root of a host named myhost :

swinstall -s svrhost Pascal @ myhost

This example does not specify the depot location because it is assumedthat the software is located in the default /var/spool/sw on svrhost .

For more information about the swverify command, refer to Chapter 3,“Configuring and Verifying Software.”.

Chapter 10 249

Creating Software PackagesAdvanced Packaging Topics

Advanced Packaging TopicsThe topics discussed in this section are for those who have a firmunderstanding of the SD packaging process and who want to have morecontrol over it. Included are:

• Changing Options in the Defaults File

• Registering Depots Created by swpackage

• Packaging Security

• Repackaging or Modifying a Software Package

• Packaging In Place

• Following Symbolic Links in the Source

• Generating File Revisions

• Overriding Disk Space Analysis Errors

• Writing to Multiple Tapes

• Making Tapes from an Existing Depot

• Creating a Depot and Mastering It to CD-ROM

• Depots on Remote File Systems

• Packaging Patch Software

Changing Options in the Defaults FileYou can change several swpackage behaviors and policy options byediting option values found in the SD defaults file or by specifying themon the command line with the -x option.

The SD defaults file ($HOME/.sw/defaults or/var/adm/sw/defaults ) contains the values for all the options(behaviors), defaults and operands (target hosts and software selections)you have chosen to modify. These values can be added to, changed, oroverwritten from the command-line.

The options and defaults are described in Appendix A, “Default Optionsand Keywords.”.

250 Chapter 10


Registering Depots Created by swpackage

When a new depot is created by swpackage , it is NOT automaticallyregistered with the local host's swagentd daemon.

To verify that the depot is registered, type:

swlist -l depot [@ host:depot]

To register the depot, you must execute the swreg command:

swreg -l depot depot_to_register

Registering a depot makes it generally available as a source forswinstall and swcopy tasks.

In general, a depot that is not registered can be used as a source depotonly by the superuser or the local user who created the depot. The depotis also not available for remote operations (for example, SPA or “pull”).This SD restriction prevents someone from creating a “Trojan Horse”depot with a process other than swpackage . If this depot was then usedas the source for a swinstall operation, it would cause the TrojanHorse to be installed on every target system and potentially activated.

Registration provides a type of public recognition for the packaged depot:

• You can see the depot in the swinstall / swcopy GUI and see it inswlist depot-level listings.

• You can read products from the depot (for example, to install).

If the only uses of a depot created with swpackage are local accesses bythe packaging user, depot registration is not required.

Chapter 10 251


Packaging SecuritySD provides Access Control Lists (ACLs) to authorize who haspermission to perform specific operations on depots. Because theswpackage command creates and modifies local depots only, the SDsecurity provisions for remote operations do not apply to swpackage .See Chapter 9, “Controlling Access to Software Objects.” for moreinformation on ACLs.

The swpackage command is setuid root , that is, the PackageSelection phase operates as the invoking user, the Analysis andPackaging phases operate as the superuser. The superuser owns andmanages all depots and therefore has all permissions for all operationson a depot. If the depot happens to be on an NFS volume, accessproblems will not arise from SD ACLs, but will arise if the localsuperuser does not have NFS root access on the NFS mounted filesystem.

If you are not the local superuser, you will not have permission to createor modify a depot unless the local superuser grants you permission.

swpackage checks and enforces the following permissions:

1. Can you create a new depot?

Status Permission

Superuser Yes

Non-superuser Yes, if the ACL for the local host grants the user“insert” permission, i.e. permission to insert a newdepot into the host.

If the proper permissions are not in place and thedepot is a new one, swpackage terminates with anerror.

2. Can you create a new product?

Status Permission

Superuser Yes

Non-superuser Yes, if the depot is new and you passed check #1above or if the ACL for an existing depot grants youinsert permission, i.e. permission to change thecontents of the depot (by adding a new product).

252 Chapter 10


If you are denied authorization to create a newproduct, swpackage generates an error messageand excludes the product from the session.

3. Can you modify an existing product?

Status Permission

Superuser Yes

Non-superuser Yes, if the ACL for the existing product grants youwrite permission, i.e. permission tooverwrite/change the contents of the product. If youare denied authorization to change an existingproduct, swpackage generates an error messageand excludes the product from the session.

If you are denied insert and write permission for allselected products, swpackage terminates with anerror.

4. Can you change the depot-level attributes?

Status Permission

Superuser Yes

Non-superuser Yes, if the depot is a new one and you passed check#1 above or if the ACL for an existing depot grantsyou write permission, i.e. permission towrite/change the contents of the depot (same as #2above).

If you are denied authorization to change anexisting depot, and if the PSF specifies somedepot-level attributes, then swpackage produces awarning message and does not change the depotattributes.

Chapter 10 253


ACL CreationWhen swpackage creates a new depot or a new product, it also createsan ACL for it:

Object ACL

New depot swpackage creates an ACL for the depot and atemplate ACL for all the products that will be packagedinto it.

The depot ACL is generated from the host'sglobal_soc_template ACL (that is, the template ACLestablished for new depots and new root file systems).

The depot's product_template ACL is generated fromthe host's global_product_template ACL (that is, thehost's template ACL for new products).

The user running swpackage is established as theowner of the new depot and is granted permissions asdefined in the depot ACL (which come from theglobal_soc_template).

New product swpackage creates an ACL for the product; the ACL isgenerated from the depot's product_template ACL.

ACL creation can be disabled with the command:

-x create_target_acls=false

When no ACL exists for a depot, only the superuser cancreate new products or add/modify depot attributes.When no ACL exists for a product, only the superusercan modify it.

254 Chapter 10


Repackaging or Modifying a SoftwarePackage

NOTE For more information on repackaging, refer to the details on modifyingan existing product found in “Repackaging or Modifying a SoftwarePackage” on page 254.

There are two types of repackaging:

1. Adding to or modifying a fileset in an existing product.

• Editing the PSF by adding a new fileset definition or changing anexisting fileset's definition.

• Running swpackage on the edited PSF, specifying thenew/changed fileset on the command line:

swpackage -s psf <other options> product.fileset @depot

This invocation works regardless of whether subproducts aredefined in the product.

• If you change a fileset by changing its tag attribute, swpackagecannot correlate the existing, obsolete fileset with the new fileset.Both become part of the changed product. To get rid of the obsolete(renamed) fileset, use swremove :

swremove -d product.old_fileset @ depot

2. Modifying an entire existing product.

• Editing the PSF by adding new fileset definitions, changingexisting fileset definitions, deleting existing fileset definitions orchanging the product's definition (product-level attributes).

• Running swpackage on the PSF, specifying the product on thecommand line:

swpackage -s psf <other options> product @ depot

• If you have deleted some fileset definitions in the PSF or modifieda fileset by changing it's tag attribute, swpackage will producewarning messages about the existing filesets that are not part ofthe modified product's definition (in the PSF). The existing filesetsplus the new filesets in the product's definition (in the PSF) willall be contained in the modified product.

Chapter 10 255


The warnings are produced during analysis phase, and are onlyproduced when the whole product is being repackaged (as opposedto subsets of the product).

• To get rid of the obsolete (renamed) filesets, use swremove :

swremove -d product.old_fileset @ depot

• You may want to swremove the product entirely beforerepackaging the changes:

swremove -d product @ depotswpackage -s psf <other options> product @ depot

256 Chapter 10


Packaging In PlaceIf you specify the option -x package_in_place=true , swpackage willpackage each of the specified products such that the source files are notcopied into the target depot. Instead, swpackage inserts references tothe source files that make up the contents of each fileset. Control scriptsare always copied.

This feature lets you package products in a development or testenvironment without consuming the full disk space of copying all thesource files into the target depot. Disk space analysis is skipped whenthe package_in_place option is true .

The source files must remain in existence — if some are deleted, anyoperations that use the depot as a source (for example, installing theproduct with swinstall ) will fail when they try to access the missingsource file(s).

If a source file changes and the product is not repackaged, theinformation that describes the source file will be incorrect (for example,the file checksum ). This incorrect information will not prevent the use ofthat target depot as a source (for example, installing with swinstall ).However, the incorrect information will be propagated along each timethe product is copied or installed from the depot. The result will be that aswverify of the installed product will always flag the inconsistencieswith an ERROR (unless you disable the check of file contents).

Chapter 10 257


Following Symbolic Links in the SourceIf you specify the option -x follow_symlinks=true , swpackage willfollow every source file that is a symbolic link and include the file itpoints to in the packaged fileset.

swpackage will also follow each source directory that is a symbolic link— which will affect the behavior of the file * keyword (recursive filespecification). Instead of including just the symbolic link in the packagedfileset, the directory it points to and all files contained below it will beincluded in the packaged fileset.

The default value for this option is “false”, which causes symbolic linksthat are encountered in the source to be packaged as symbolic links. Thesymbolic link can point to a file that is also part of the fileset, or to a filethat is not.

Generating File RevisionsIf you specify the option -x include_file_revisions=true ,swpackage will examine each source file using the what and identcommands to extract an SCCS or RCS revision value and assign it as thefile's revision attribute.

Because a file can have multiple revision strings embedded within it,swpackage uses the first one returned. It extracts the revision valuefrom the full revision string and stores it.

This option is time consuming, especially when a what search fails andthe ident command is then executed.

The default value for this option is “false”, which causes swpackage toskip the examination. No value for the revision attribute is assigned tothe files being packaged.

258 Chapter 10


Overriding Disk Space Analysis ErrorsThe swpackage command performs a Disk Space Analysis (DSA) duringthe analysis phase. If the file systems that contain the target depot donot have enough free space to store the products being packaged,swpackage will print an error message and then terminate the session.It checks both the absolute free space threshold, and the minimum freethreshold (minfree). Crossing either threshold will generate the errorcondition.

If you specify the option -x enforce_dsa=false , swpackage willchange the error to a warning and continue. This flexibility lets you crossinto the minfree space to complete a packaging operation.

Chapter 10 259


Writing to Multiple TapesWhen you package products to a distribution tape, the media_capacityoption defines the size of the tape media (in one million byte units). Thedefault value for this option is media_capacity=1330 , which is the sizeof an HP DDS tape. If the target tape is not a DDS tape, you must specifythe media_capacity value.

NOTE The capacity of the DDS tape is in one million byte units (1,000,000bytes), NOT Mbyte units (1,048,576 bytes). Most tape drivemanufacturers specify capacity in one-million byte units.

If the products being packaged require more space than the specifiedmedia capacity, swpackage will partition the products across multipletapes.

To find out if multiple tapes will be required, swpackage will calculatethe tape blocks required to store the depot catalog and each product'scontents.

When multiple tapes are necessary, swpackage will write the entirecatalog on to the first tape plus any product contents that will also fit.For each subsequent tape, swpackage will prompt you for a “tape isready” response before continuing.

To continue with the next tape, enter one of the following responses:

Response Meaning

Return Use the same device.

pathname Use the new device/file “pathname”.

quit Terminate the write-to-tape operation.

Partitioning is done at the fileset level, so a product can span multipletapes. A single fileset's contents cannot span multiple tapes. If any singlefileset has a size that exceeds the media capacity, swpackage generatesan error and terminates. It also generates an error if the catalog will notfit on the first tape.

260 Chapter 10


Making Tapes from an Existing DepotYou can copy one or more products from an existing depot to a tape usingswpackage . Instead of specifying a PSF as the source for a packagingsession, just specify an existing depot. For example:

swpackage -s /var/spool/sw ...

To copy all of the products in a depot to a tape:

swpackage -s depot -d tape -x target_type=tape

To copy only some of the products in a depot to a tape, specify theproducts as software selections:

swpackage -s depot -d tape -x target_type=tape productproduct ...

You can also use the -f file option can be used to specify several softwareselections instead of listing them on the command line.

When products are copied from a depot to a tape, the ACLs within thedepot are NOT copied. (The swpackage command never creates ACLswhen software is packaged onto a tape.)

swpackage cannot compress files when writing to a tape.

Chapter 10 261


Creating a Depot and Mastering It to CD-ROMWhen swpackage creates a new depot or packages a new product, italways creates an ACL for the depot/product. If you were to create adepot and then master it onto a CD-ROM, the CD-ROM would containall those ACLs, which could cause the following problems:

• it may result in too-restrictive permissions on the CD-ROM depot.

• you could have too many user-specific ACLs on the CD-ROM.

To solve these problems, you can tell swpackage to NOT create ACLs inthe depot by setting the create_target_acls option to false .

This feature is provided only for the superuser because only the localsuperuser can change, delete, or add ACLs to a depot that has no ACLs.The local superuser always has all permissions.

The -x create_target_acls=false option causes swpackage to skipthe creation of ACLs for each new product being packaged (and for thedepot, if it is new). This option has no impact on the ACLs that alreadyexist in the depot.

When a depot is used as a source for other SD operations, its ACLs (orlack thereof) have no bearing on the ACLs created for the targets of theoperation. Source ACLs are not related to target ACLs.

The swpackage command never creates ACLs when software ispackaged onto a tape.

262 Chapter 10


Depots on Remote File SystemsBecause the swpackage analysis and build phases operate as thesuperuser, there are constraints on how swpackage creates, adds to, ormodifies products on a depot that exists in an NFS-mounted file system.

If the superuser DOES NOT have write permission on the remote filesystem, swpackage will be unable to create a new depot−it willterminate before the analysis phase begins.

If the superuser DOES have write permission on the remote file systembut the option write_remote_files is “false”, swpackage will beunable to create a new depot − it will terminate before the analysisphase begins.

If the superuser DOES have write permission on the remote file systemand you specify the option -x write_remote_files=true ,swpackage will create the new depot and package products into it.

The constraints for an existing NFS mounted depot are the same aswhen creating a new depot.

So, you must:

1. Set the write_remote_files option to true and

2. Make sure the superuser can write to the NFS file system to packagea depot on an NFS-mounted file system.

When these constraints are satisfied, the SD ACL protection mechanismcontrols operations on NFS mounted depots the same way it controlsoperations on local depots.

Chapter 10 263


Packaging Patch SoftwareA number of software attributes are available to all software levels(bundles, products, subproducts, and filesets) that permit packaging ofpatch software. For complete information on patch attributes and asample PSF, see Chapter 8, “Managing Patches.”

264 Chapter 10


Chapter 11 265

Using Control Scripts

11 Using Control Scripts

Control scripts can perform a wide variety of customization andconfiguration tasks, such as:

• Verifying if someone is actively using the product and, if so,preventing reinstallation, update or removal.

• Ensuring the local host system is compatible with the software(scripts can check beyond the compatibility enforced by the product'suname attributes).

• Removing obsolete files or previously installed versions of theproduct.

• Creating links to, or additional copies of, files after they have beeninstalled.

• Copying configurable files into place on first-time installation.

• Conditionally copying configurable files into place on later updates.

• Modifying existing configuration files for new features.

• Rebuilding custom versions of configuration files.

• Creating device files or custom programs.

• Killing and/or starting daemons.

Topic Page

“Types of Control Scripts” 268

“Environment Variables” 276

“Execution of Control Scripts” 281

“Execution of Other Commands by Control Scripts” 289

266 Chapter 11

Using Control Scripts

“Input To and Output From Control Scripts” 290

“File Management by Control Scripts” 293

“Testing Control Scripts” 294

Topic Page

Chapter 11 267

Using Control ScriptsIntroduction to Control Scripts

Introduction to Control ScriptsSD-UX supports execution of both product and fileset control scripts.These shell scripts allow you to perform additional, customized checksand operations as part your regular software management tasks. Theswinstall , swconfig , swverify , swask , and swremove commandscan execute one or more of these scripts. Control scripts are usuallysupplied by the software vendor, but you can write your own. All controlscripts are optional.

Product level control scripts are run when any fileset within that productis selected for installation or removal so the activities in product controlscripts must pertain to all filesets in that product, but not to any filesetin particular. Actions you want to apply to every fileset in a productshould be in the appropriate product level control script.

Fileset scripts must pertain only to the installation, configuration, orremoval of that fileset, and not to any other fileset or to the parentproduct.

268 Chapter 11

Using Control ScriptsTypes of Control Scripts

Types of Control ScriptsHere are the control scripts that SD-UX supports:

• Checkinstall Script

This script is run by swinstall during its Analysis phase to insurethat the installation (and configuration) can be attempted. Forexample, the OS run state, running processes, or other prerequisiteconditions beyond dependencies could be checked. It should notchange the state of the system.

A checkinstall script's chief merit is its ability to detect if the systemcontains a hardware configuration that might lead to catastrophe - anunbootable system or file system corruption - if the installation of theselected software was allowed to proceed. It also acts as the test forconflicts with other software selections or with software alreadyinstalled.

• Preinstall Script

This script is run by swinstall before loading the software files. Forexample, this script could remove obsolete files, or move an existingfile aside during an update.

This script and the postinstall script are part of swinstall 's Loadphase. In the Load phase, a product's preinstall script (if any) runsfirst. Then, for each selected fileset in that product, the fileset'spreinstall script runs. The files are then loaded, and the fileset'spostinstall script runs. Finally, the product's postinstall script (if any)runs. Then SD loads the next product that has selected filesets andthe process repeats for that product.

• Postinstall Script

This script is run by swinstall after loading the software files. Forexample, this script could move a default file into place.

• Unpreinstall Script Unpreinstall scripts are executed during theload phase of swinstall if recovery is initiated.

All undo scripts are executed in the reverse order of the normalscripts. For each fileset being recovered, the unpostinstall script isrun, the fileset files are restored, and the unpreinstall script is run.An undo script is executed if its corresponding script was executed.

Chapter 11 269


An unpreinstall script should undo any operation that the preinstallscript did. For example, if the preinstall script moved a file, theunpreinstall script should move it back. If the preinstall script copieda file, the unpreinstall script should remove it.

For a product to be recoverable, no files should be removed bypreinstall or postinstall scripts. Configure scripts are a good place toremove obsolete files.

A product unpreinstall script is run after the fileset unpreinstallscripts.

• Unpostinstall Script

Unpostinstall scripts are executed during the load phase ofswinstall if recovery is initiated.

All undo scripts are executed in the reverse order of the normalscripts. An undo script is executed if its corresponding script wasexecuted.

An unpostinstall script should undo any operation that thepostinstall script did. For example, if the postinstall script moved afile, the unpostinstall script should move it back. If the postinstallscript copied a file, the unpostinstall script should remove it.

For a product to be recoverable, no files should be removed bypreinstall or postinstall scripts. Configure scripts are a good place toremove obsolete files.

NOTE Product level unpostinstall scripts are not supported.

• Configure Script

This script is run by swinstall or by swconfig to configure the hostfor the software, or configure the software for host-specificinformation. For example, this script could change a host's specificconfiguration file such as /etc/services , add the host name orother host resources such as available printers to its ownconfiguration file, or perform compilations.

Configure scripts are run by swinstall for all products (inprerequisite order) after the products have completed the Load phase.However, they are only run when installing to a system that willactually be using the software. They are deferred when installing to

270 Chapter 11


an alternate root (for example, for diskless or building test filesystems) and run instead by the swconfig command when thealternate root is now the root of the system using the software.

The swconfig command can also be used to rerun configure scriptsthat failed during a normal install. A successful execution of theconfigure step (whether there is a script or not) moves the softwarefrom the INSTALLED state to the CONFIGURED or ready-to-usestate. Configure scripts (and all others) must be able to be run manytimes (that is, they must be re-executable).

Configure scripts are not run for installations to alternate roots.

• Verify Script

Verify scripts are run by the swverify command any time after thesoftware has been installed and configured. Like other scripts, theyare intended to verify anything that the SD-UX softwaremanagement tools do not verify by default. For example, this scriptcould check to see that the software is configured properly and thatyou have a proper license to use it.

• Unconfigure Script

This script is run by swconfig or by swremove to undo theconfiguration of the host or the software that was done by theconfigure script. For example, it could remove its configuration fromthe /etc/services file. (The unconfigure task moves the softwarefrom the CONFIGURED state back to the INSTALLED state.)

Only the swremove command actually removes software. You shouldbe able to unconfigure and reconfigure using swconfig . Unconfigurescripts are not run for removals from alternate roots.

• Checkremove Scripts

The checkremove script is run by swremove during the removeAnalysis phase to allow any vendor-defined checks before thesoftware is permanently removed. For example, the script could checkwhether anyone was currently using the software.

• Preremove Scripts

This script is executed just before removing files. It can be destructiveto the application because files will be removed next. It could removefiles that the postinstall script created.

Chapter 11 271


This script and the postremove script are part of the Remove phase ofswremove . Within each product, preremove scripts are run (in thereverse order dictated by any prerequisites), files are removed, thenall postremove scripts are run.

• Postremove Scripts

This script is executed just after removing files. It is the companionscript to the postinstall script. For example, if this was a patch fileset,then the preinstall script could move the original file aside, and thispostremove script could move the original file back if the patch wasremoved.

• Request Scripts

This interactive script requests a response from the user as part ofsoftware installation or configuration. Request scripts writeinformation into a response file for later use by the configure script orother scripts. You can run requests scripts by executing the swaskcommand or using the ask option with swinstall or swconfigafter selection and before the analysis phase.

• Other Scripts

The software vendor can include other control scripts, such as asubscript that is sourced by the above scripts. The location of thecontrol scripts is passed to all scripts via theSW_CONTROL_DIRECTORY environment variable.

272 Chapter 11


Control Script FormatA control script should be a shell script (as opposed to a binary) andwritten to be interpreted by the Posix.2 shell /sbin/sh . Korn shell(formerly /bin/ksh ) syntax is acceptable to the Posix.2 shell. A scriptwritten for csh is not supported.

The script should have a simple header similar to the example below.Included in the header should also be comment lines which state theproduct and fileset to which the script belongs, the name of the script,the revision string as required by the what(1) command, and a simplecopyright statement.

#! /sbin/sh######### Product: <PRODUCT># Fileset: <FILESET># configure# @(#) $Revision: 10.30 $########## (c) Copyright MyCompany, 1996#########

Chapter 11 273


The following table describes the control script keywords:

Table 11-1 Control Script Keywords

The value of each keyword is the source filename for the specific controlscript. swpackage will copy the specified control script's filename intothe depot's storage directory for the associated product or fileset, usingthe keyword as the tag of the stored script (for example, “configure”).

Additional control scripts or data files can be included with the productor fileset and stored alongside the real control scripts (for example, asubscript called by the supported control scripts, or a data file read bythese scripts). These additional scripts are specified using the syntax:

PATH[=tag]

If the optional tag component of the value is not specified, swpackageuses the basename(1) of the source pathname as the tag for the controlscript. (Otherwise, the tag value is used.)

Keyword Value Example

checkinstall path_string, 1024 bytes /mfg/sd/scripts/checkinstall

preinstall path_string, 1024 bytes /mfg/sd/scripts/preinstall

postinstall path_string, 1024 bytes /mfg/sd/scripts/postinstall

unpreinstall path_string, 1024 bytes /mfg/sd/scripts/unpreinstall

unpostinstall path_string, 1024 bytes /mfg/sd/scripts/unpostinstall

configure path_string, 1024 bytes /mfg/sd/scripts/configure

unconfigure path_string, 1024 bytes /mfg/sd/scripts/unconfigure

verify path_string, 1024 bytes /mfg/sd/scripts/verify

checkremove path_string, 1024 bytes /mfg/sd/scripts/checkremove

preremove path_string, 1024 bytes /mfg/sd/scripts/preremove

postremove path_string, 1024 bytes /mfg/sd/scripts/postremove

request path_string, 1024 bytes /mfg/sd/scripts/request

control_file path_string, 1024 bytes /mfg/sd/scripts/subscripts

274 Chapter 11


Control Script Location on the File SystemThe checkinstall, preinstall, postinstall, and auxiliary scripts for a filesetwill be downloaded to a temporary directory from which they will beinvoked:

<FILESET>/control_script/var/tmp/< CATALOG_DIR>/ \catalog/< PRODUCT>/

The form of the <CATALOG_DIR> is: aaaa <pid>, where <pid> is theswinstall process ID number.

The scripts are delivered to that location from the depot immediatelyafter Product Selection has completed, at the beginning of the Analysisphase and before any system checks have begun. The temporarydirectory is removed automatically upon exiting swinstall .

After successful fileset installation, all other control scripts will belocated in the Installed Product Database (IPD). They will be deliveredto that location from the depot as part of the installation of the fileset'sother files:

/var/adm/sw/products/<PRODUCT>/<FILESET>/control_script

The location of the IPD is relative to the root directory under which thesoftware installation is done. If the installation is to an alternate root,/mnt/disk2 for example, then the IPD for that software will be under:

/mnt/disk2/var/adm/sw/products/<PRODUCT>/<FILESET>

NOTE All necessary directories under /var/adm/sw will be created by theSD-UX process. All files under those directories will be filled by SD-UXinitiated processes. Files must never be delivered directly under /var ; itis a private directory.

Chapter 11 275


General Script GuidelinesHere are some guidelines for writing control scripts:

• All scripts are executed serially and directly impact the total timerequired to complete an installation, configuration, or removal task.Consider the impact control scripts will have on performance.

• The current working directory in which the agent executes a controlscript is not defined. Use the environment variables provided by theagent for all pathname references.

• Disk space analysis does not account for files created, copied orremoved by control scripts.

• The control scripts you write may be executed several times (forexample, configure, then unconfigure, then configure…) so they mustbe able to support multiple executions.

• You may have to re-execute or debug control scripts, especially whenthey generate error or warning conditions, so your scripts should bewell-written and commented.

• Control script stdout and stderr are both logged, so you shouldrestrict output to only the information the user requires.

• Make sure you specify the path to a shell that is proper for yoursystem. If you get the following message when you execute a script:

Cannot execute /var/adm/sw/products/PRODUCT/FILESET/configure.Bad file number (9).

it means the shell in your script has a path that is not correct for yoursystem. (HP-UX 9.X scripts = #!/bin/sh and HP-UX 10.X and 11.Xscripts = #!/sbin/sh .)

276 Chapter 11

Using Control ScriptsEnvironment Variables

Environment VariablesAll control scripts are invoked as the superuser and executed by theagent process. HP-UX provides environment variables that affect SD-UXcommands and scripts. These variables fall are catgorized as follows:

• Variables that affect all SD-UX commands.

• Variables that affect all SD-UX scripts.

• Variables that affect swinstall and swremove .

Variables That Affect All SD-UX Commands

LANG

• This external variable applies to all SD commands exceptswgettools .

• Determines the language in which messages are displayed. If LANGis not specified or is set to the empty string, a default value of “C” isused.

• The language in which the SD agent and daemon log messages aredisplayed is set by the system configuration variable script,/etc/rc.config.d/LANG . For example,/etc/rc.config.d/LANG must be set to “LANG=ja_JP.SJIS ” or“LANG=ja_JP.eucJP ” to make the agent and daemon log messagesdisplay in Japanese.

• See the lang(5) man page for more information.

Chapter 11 277


Variables That Affect All SD-UX Scripts

SW_CONTROL_DIRECTORY

• Defines the full pathname to the directory containing the script. Thistells other scripts where other control scripts for the software arelocated (for example, subscripts.

Also contains the response file generated by a request script. Otherscripts that reference the response file access the file by referencingthis variable.

The directory is either a temporary catalog directory, or a directorywithin in the Installed Products Database (IPD).

To source a subscript or reference a data file packaged along with acontrol script:

. ${SW_CONTROL_DIRECTORY}subscriptgrep something ${SW_CONTROL_DIRECTORY}datafile

SW_LOCATION

• Defines the location of the product, which may have been changedfrom the default product directory (if the product is locatable).

When installing to (or removing from) the primary root directory (“/”),this variable is the absolute path to the product directory. Foroperations on an alternate root directory, the variable must beprefixed by SW_ROOT_DIRECTORY to correctly reference productfiles.

If a product is not locatable, then the value of SW_LOCATION willalways be the default product directory defined when the product ispackaged.

SW_PATH

• The search path for commands. A PATH variable defines theminimum set of commands available for use in a control script (forexample, /sbin:/usr/bin:/usr/ccs/sbin ).

A control script should always set its own PATH variable, and thePATH variable must begin with $SW.PATH. The PATH should be setas follows:

PATH=$SW_PATHexport PATH

278 Chapter 11


Additional directories, like /usr/local/bin , can be appended toPATH, but you must make sure that the commands in thosedirectories exist.

SW_ROOT_DIRECTORY

• Defines the root directory in which the session is operating, either “/”or an alternate root directory. This variable tells control scripts theroot directory in which the products are installed. A script must usethis directory as a prefix to SW_LOCATION to locate the product'sinstalled files.

All control scripts (except for the configure and unconfigure scripts)can be executed during an install or remove task on an alternate root.If the scripts reference any product files, each reference must includethe {SW_ROOT_DIRECTORY} in the file pathname.

The scripts may only need to perform actions when installing to(removing from) the primary root directory (“/”). If so, then theSW_ROOT_DIRECTORY can be used to cause a simple exit 0 whenthe task is operating in an alternate root directory:

if test "${SW_ROOT_DIRECTORY}" != "/"then

exit 0fi

SW_SESSION_OPTIONS

• Contains the pathname of a file containing the value of every optionfor a particular command, including software and target selections.This lets scripts retrieve any command options and values other thanthe ones provided explicitly by other environment variables.

SW_SOFTWARE_SPEC

• Contains the fully qualified software specification of the currentproduct or fileset. The software specification allows the product orfileset to be uniquely identified. (Fully qualified software specsinclude the r= , a=, and v= version components even if they containempty strings. For installed software, l= must also be included.)

Chapter 11 279


Variables That Affect swinstall and swremove

SW_DEFERRED_KERNBLD

• This variable is normally unset. If it is set, the actions necessary forpreparing the system file /stand/system cannot be accomplishedfrom within the postinstall scripts, but instead must be accomplishedby the configure scripts. This occurs whenever software is installed toa directory other than /.

• This variable should be read only by the configure and postinstallscripts of a kernel fileset.

SW_INITIAL_INSTALL

• This variable is normally unset. If it is set, the swinstall session isbeing run as the back end of an initial system software installation(that is, a “cold” install).

SW_KERNEL_PATH

• The path to the kernel. The default value is /stand/vmunix .

SW_SESSION_IS_KERNEL

• Indicates whether a kernel build is scheduled for the currentinstall/remove session.

• A “true” value indicates that the selected kernel fileset is scheduledfor a kernel build and that changes to /stand/system are required.

• A null value indicates that a kernel build is not scheduled and thatchanges to /stand/system are not required.

• The value of this variable is always equal to the value ofSW_SESSION_IS_REBOOT.

SW_SESSION_IS_REBOOT

• Indicates whether a reboot is scheduled for a fileset selected forremoval. Because all HP-UX kernel filesets are also reboot filesets,the values of this variables is always equal to the value ofSW_SESSION_IS_KERNEL.

280 Chapter 11


SW_SYSTEM_FILE_PATH

• The path to the kernel's system file. The default value is/stand/system .

Chapter 11 281

Using Control ScriptsExecution of Control Scripts

Execution of Control ScriptsThis section details how each control script is executed.

Details Common to All Control Scripts• The agent runs as the superuser, therefore control scripts are always

executed as the superuser. Use appropriate caution.

• Control scripts are only executed for software being installed,removed or verified in the primary root (“/”) or an alternate rootdirectory. Scripts are never executed for software in a depot.

• Each script must set its own PATH variable, using SW_PATH.

• Neither swinstall nor swremove require that the system be shutdown. Control scripts must work correctly on both quiet single-usersystems and active multi-user systems. They must deal properly withunremovable running programs. They might have to shut down orstart up processes that they own themselves to succeed.

• Control scripts can be re-executed. If a script is run more than once, itshould produce the same results each time. The second executionshould not produce any error messages or leave the system in a statedifferent than before it was run.

A script should be executable after its fileset was loaded withoutdamaging the new fileset with which it is associated.

For example, if you must copy a file from under /usr/newconfig toanother location, use the cpio -p command to copy it rather thanthe cp command to move it, or check for the absence of the/usr/newconfig version before attempting the move. (The cpio(1)command may be preferred over cp(1) because cpio copies themode, owner, and group permissions.)

• Control scripts must exit with a return value of zero (exit 0 ) if noserious errors occur (no ERROR or WARNING messages printed, asdescribed in the “Input To and Output From Control Scripts” on page290.) They must return 1 (exit 1 ) in case of any serious errors, and 2(exit 2 ) for warnings.

All messages produced by control scripts are redirected to the agentlogfile.

282 Chapter 11


• The set of control scripts executed during a particular phase of a taskare always executed in prerequisite order the scripts of eachprerequisite product/fileset are executed before the script of thedependent fileset.

• All control scripts are readable by any other control script.

Checkinstall Scripts• Checkinstall scripts are executed during the Analysis phase of a

swinstall session. The pathname of the script being executed is:

[$ {SW_CONTROL_DIRECTORY}checkinstall ]

• A checkinstall script must not modify the system.

• A checkinstall script determines whether the product/fileset can beinstalled by performing checks beyond those performed byswinstall . Example checks include checking to see if theproduct/fileset is actively in use, or checking that the system run-levelis appropriate.

• If you are using a request script as part of the install, the checkinstallscript should:

• Verify that the response file exists.

• Prevent swinstall from “hanging” if:

• A script tries to read a response file that does not exist.

• The install or configuration relies on information in themissing response file.

• If the checkinstall script fails, the fileset will not be installed. Theinteractive interface of swinstall will notify you that thecheckinstall script has failed. Then you can: diagnose the problem, fixit and re-execute the analysis phase; or unselect the product/fileset.The non-interactive interface tells you about each individualcheckinstall failure and the filesets are not installed.

• A checkinstall script is executed for installations into the primaryroot (“/”) or an alternate root. Since most of the actions of this scriptwill involve checking the current conditions of a running system (thatis, the primary root), it may not need to perform any actions when theproduct/fileset is being installed into an alternate root.

Chapter 11 283


Preinstall Scripts• Preinstall scripts are executed during the Load phase of a


[$ {SW_CONTROL_DIRECTORY}preinstall ]

• The preinstall script for a product is executed immediately before thefileset's files are installed.

• A preinstall script should perform specific tasks preparatory to thefiles being installed. The swinstall session will proceed withinstalling the files regardless of the return value from a preinstallscript. Example actions include removing obsolete files (in an updatescenario).

• A preinstall script is executed for installations into the primary root(“/”) or an alternate root. The scope of actions of a preinstall scriptshould be within the product itself (that is, the files within theproduct's directory).

Postinstall Scripts• Postinstall scripts are executed during the Load phase of a


[$ {SW_CONTROL_DIRECTORY}postinstall ]

• The postinstall script for a product is executed immediately after thefileset's files are installed.

• A postinstall script should perform specific tasks related to the filesjust installed. The swinstall session will proceed with theremainder of the session (for example, configuration) regardless of thereturn value from a postinstall script. Example actions includeadding a kernel driver to the system file or moving a file from under/usr/newconfig to its correct place in the file system.

• A postinstall script is executed for installations into the primary root(“/”) or an alternate root. The scope of actions of a postinstall scriptshould be within the product itself (that is, the files within theproduct's directory).

• The customization or configuration tasks that must be performed toenable the product/fileset for general use should not be done in thepostinstall script, but the configure script (described below).

284 Chapter 11


Configure Scripts• Configure scripts are executed during the Configuration phase of a

swinstall session. SD expects configure scripts at system start-up ifthe swinstall session triggers a system reboot. The swconfigcommand can also execute configure scripts. The pathname of thescript being executed is:

[$ {SW_CONTROL_DIRECTORY}configure ]

• A configure script is only executed for installations into the primaryroot (“/”). If you choose to defer configuration in the swinstallsession, then the configure script will be executed by a swconfigsession at some time after the installation completes.

• A configure script is usually executed only when the product/fileset isin the INSTALLED state.

• A configure script is the primary way to move a product/fileset fromthe INSTALLED state to the CONFIGURED state. The script shouldperform all (or most of) the activities needed to enable theproduct/fileset for use.

• A configure script can use configuration information provided by theuser and collected by a request script.

• When an existing version of a product is updated to a new version,the configure script(s) for the new version must perform anyunconfigurations-configurations of the old version that are necessaryto properly configure the new version. The unconfigure script(s) forthe old version are not executed.

• Configure scripts are for architecture-dependent actions because theywill always be run on the architecture of the install target.

Chapter 11 285


Unconfigure Scripts• Unconfigure scripts are executed during the

Unconfiguration-Configuration phase of a swremove session. Theycan also be executed by the swconfig command. The pathname ofthe script being executed is:

[$ {SW_CONTROL_DIRECTORY}unconfigure ]

• An unconfigure script is executed only for software installed into theprimary root (“/”).

• An unconfigure script is re-executed even when the product/fileset isin the CONFIGURED state.

• An unconfigure script is the primary way to move a product/filesetfrom the CONFIGURED state back to the INSTALLED state. Thescript should perform all (or most of) the activities needed to disablethe product/fileset for use.

• An unconfigure script must undo all configuration tasks performed byits companion configure script. The user should be able to configure,unconfigure, configure, etc. an installed product/fileset and alwaysend up with the same configured result.

Verify Scripts• Verify scripts are executed by the swverify command. The

pathname of the script being executed is:

[$ {SW_CONTROL_DIRECTORY}verify ]

• A verify script must not modify the system.

• A verify script is the primary way to check the configuration tasksperformed by a configure script for correctness and completeness.

• A verify script is executed for installations into the primary root (“/”)or an alternate root. Since most of the actions of this script willinvolve checking the current conditions of a CONFIGUREDproduct/fileset (in the primary root), it may not need to perform anyactions for a product/fileset installed into an alternate root directory.

286 Chapter 11


Checkremove Scripts• Checkremove scripts are executed during the Analysis phase of a

swremove session. The pathname of the script being executed is:

[$ {SW_CONTROL_DIRECTORY}checkremove ]

• A checkremove script must not modify the system.

• A checkremove script determines whether the product/fileset can beremoved by performing checks beyond those performed by swremove .Example checks include checking to see if the product/fileset isactively in use.

• If the checkremove script fails, no filesets in the product will beremoved. The GUI/TUI interface of swremove notifies you that thecheckremove script has failed. You can then: diagnose the problem, fixit, and re-execute the analysis phase; unselect the target system(s) inquestion; or unselect the product/fileset. The command line interfacenotifies you for each individual checkremove failure, and no filesets inthat product are removed.

• A checkremove script is executed for installations into the primaryroot (“/”) or an alternate root. Since most of the actions of this scriptwill involve checking the current conditions of a running system (thatis, the primary root), it may not need to perform any actions when theproduct/fileset is being removed from an alternate root.

Preremove Scripts• Preremove scripts are executed during the Remove phase of a


[$ {SW_CONTROL_DIRECTORY}preremove ]

• All preremove scripts for a product are executed immediately beforethe product's files are removed.

• A preremove script should perform specific tasks preparatory to thefiles being removed. The swremove session will proceed withremoving the files regardless of the return value from a preremovescript. Example actions include removing files created in thepostinstall script.

Chapter 11 287


• A preremove script is executed for installations into the primary root(“/”) or an alternate root. The scope of actions of a preremove scriptshould be within the product itself (that is, the files within theproduct's directory).

• The de-customization or unconfiguration-configuration tasks whichmust be performed to disable the product/fileset for general use mustnot be done in a preremove script, instead they should be done in anunconfigure script (described above).

Postremove Scripts• Postremove scripts are executed during the remove phase of a


[$ {SW_CONTROL_DIRECTORY}postremove ]

• All postremove scripts for a product are executed immediately afterthe product's fileset files are removed.

• A postremove script should perform specific tasks related to the filesjust removed. The swremove session will proceed with the remainderof the session regardless of the return value from a postremove script.Example actions include:

• Removing any files still remaining after preremove and theswremove file removal have completed.

• Removal of directories wholly owned by the fileset and which havebeen emptied by the file removal.

• A postremove script is executed for installations into the primary root(“/”) and an alternate root. The scope of actions of a postremove scriptshould be within the product itself (that is, the files within theproduct's directory).

• The de-customization or unconfiguration-configuration tasks whichmust be performed to disable the product/fileset for general useshould not be done in the postremove script, instead they should bedone in the unconfigure script (described above).

288 Chapter 11


Request Scripts• Request scripts are interactive scripts that request a response from

the user as part of software installation or configuration. Thepathname of the script being executed is:

[$ {SW_CONTROL_DIRECTORY}request ]

• Request scripts write information into a response file for later use bythe configure script or other scripts. You can run requests scripts byexecuting the swask command or using the ask option withswinstall or swconfig after selection and before the analysisphase.

• The POSIX default for request scripts is a shell script. The shellscript must be able to:

• Ask questions of the user.

• Read the user’s answer.

• List all current user responses in a redrawn screen.

• Ask the user to confirm an answer and continue or to go back.

• The request script stores the user response in a response file. Thepath of the response file is accessible by theSW_CONTROL_DIRECTORY environment variable.

• The POSIX recommendation for response file format is the SVR4model of attribute/value pairs. Answers should be written to theresponse file in env_var= value format so that the response files canbe easily used by other control scripts.

• When you use a request script to get install information, HPrecommends that you use a checkinstall script to check for properexecution of the request script. The checkinstall script should:





Chapter 11 289

Using Control ScriptsExecution of Other Commands by Control Scripts

Execution of Other Commands byControl ScriptsEvery command executed by a control script is a potential source offailure because the command may not exist on the target system. Yourscript can use any command conditionally, if it checks first for itsexistence and executability, and if it does not fail when the command isunavailable.

• If the target system(s) conform with the POSIX 1003.2 Shells andUtilities standard, then the Execution Environment Utilities of thisstandard will also be available.

• If a fileset has a prerequisite dependency on another product/fileset,then most of the control scripts for the dependent fileset can use thecommands of the required product/fileset, if the$ROOT_DIRECTORY is / . (All commands perform their tasks inprerequisite order).

• Commands should be referenced relative to the path componentsspecified in the PATH variable. (See the discussion of PATH and theSW_PATH environment variable above.)

290 Chapter 11

Using Control ScriptsInput To and Output From Control Scripts

Input To and Output From ControlScripts• Except for request scripts, control scripts must not be interactive.

This includes messages such as, Press return to continue .

• Except for request scripts, all control scripts are executed by theagent on the target systems. Request scripts are executed by thecontroller (swinstall , swconfig , or swask ).

• Except for request scripts, no method of input to control scripts issupported. Request script data is input by the user through theswask command or the ask option for swinstall or swconfig .

• Control scripts must write messages for error and warning conditionsto stderr (echo &>2 ), and write all other messages to stdout.Control scripts must not write directly to /dev/console or attemptany other method of writing directly to the display.

The stdout and stderr from a control script is redirected by theagent to the log file (var/adm/sw/swagent.log ) within the primaryor alternate root directory in which the task is being performed.

For interactive swinstall and swremove sessions, you can displayand browse this logfile.

• Only minimal, essential information should be emitted by controlscripts. Ideally, no output is emitted if the script successfullyperforms all of its actions.

• In the agent logfile, the execution of each control script is prefaced bya “begin execution” message:

* Running "checkinstall" script for product "PRODUCT".* Running "checkinstall" script for fileset "PRODUCT.FILESET".

Any messages generated by the script will follow. If the script returnsa value other than 0 (SUCCESS), then a concluding message iswritten:

ERROR: The "unconfigure" script for "PRODUCT.FILESET" failed (exit code "1"). The script location was "/var/adm/sw/products/PRODUCT/FILESET/unconfigure".

* This script had errors but the execution of this product will still proceed. Check the above output from the script for further details.

Chapter 11 291


WARNING: The "unconfigure" script for "PRODUCT.FILESET" failed (exit code "2"). The script location was

"/var/adm/sw/products/PRODUCT/FILESET/unconfigure".* This script had warnings but the execution of this

product will still proceed. Check the above output from thescript for further details.

• The messages written by a control script must conform to thefollowing format conventions whenever possible.

1. Never emit blank lines.

2. All output lines must have one of these forms:

ERROR: textWARNING: textNOTE: textblank text

In each case, the keyword must begin in column 1, and the textmust begin in column 10 (indented nine blanks).

3. Choose the keyword (ERROR, WARNING, NOTE, or blank) as follows:

ERROR: Something happened that must grab yourattention. Cannot proceed, or need correctiveaction (to be taken later).

WARNING:Can continue, but it's important that you knowsomething went wrong or requires attention.

NOTE: Something out of the ordinary or worth specialattention; not just a status message.

blank Generic progress and status messages (keepthem to a necessary minimum).

Do not start a line with an asterisk (*) character. This is reservedfor operational messages printed by the agent so they can beeasily distinguished from other messages.

4. If the message text requires more than one, 72-character line,break it into several 72-character lines. Indent all lines after thefirst. For example:

NOTE: To install your new graphics package, it was necessary to turn on the lights in the next room. Please turn them off when you leave.

5. Do not use tab characters in any messages.

292 Chapter 11


• Scripts execute other commands which may unexpectedly fail andemit output not in the above format. Wherever you suspect a failureis possible or likely (and it is reasonable to do so) redirect thestandard output or error of the executed command to </dev/null orto a temporary file. Then emit a proper-format message based on thereturn code or on output from the command. For example:

if /bin/grep bletch /etc/bagel 2 &>/dev/nullthen echo "ERROR: Cannot find bletch in /etc/bagel." &>2fi

• Follow these conventions to ensure a control script's messages have asimilar look and feel to the messages generated by the agent (and thecommands themselves).

• Use full sentences wherever possible. Avoid terseness.

• Start sentences and phrases with a capital letter and end with aperiod.

• Put two blanks after a period; one after colons, semicolons, andcommas.

• Use uppercase first letters of phrases after colons. (This helpsbreak up the message into digestible “bites” of information.)

• Surround product, fileset, directory, and file names, and othervariable-valued strings with quotes. For example:

echo "ERROR: Cannot open file \"$file\"." &>2

• Write in the present tense. Avoid “would”, “will”, and similar verbtenses. Also avoid past tense except where necessary.

• Use “cannot” rather than “can't”, “could not”, “couldn't”, “unableto”, “failed to”, and similar phrases.

Chapter 11 293

Using Control ScriptsFile Management by Control Scripts

File Management by Control Scripts• If any files in the previous revision of a product have changed names

or became obsolete, a product/fileset preinstall or postinstall script inthe new revision of the product must remove the old files. The agentdoes not remove the files in an existing product/fileset beforeupdating it to a newer revision.

NOTE It is necessary to perform the cleanup task of any previous revision thatcan be updated to the new revision. Sometimes this is more than just theprevious revision.

• All files created by a preinstall, postinstall, or configure script mustbe removed by a companion postremove, preremove or unconfigurescript.

Files created by scripts are not known by the swremove command,and will not get removed when it removes those files installed byswinstall .

294 Chapter 11

Using Control ScriptsTesting Control Scripts

Testing Control ScriptsThe following testing suggestions do not cover all test scenarios. Theremay still be problems with a control script even after doing this testing.For example, you may test installing/removing individual filesets. Butthere might be some interactions that are discovered only after all thefilesets are installed on or removed from the system.

Similarly, you may test the control scripts on a fully loaded system andmiss a problem when you execute a command in your script that is notpart of the base (or core) system. If your target system does not containthe particular command, your script may fail.

Testing Installation ScriptsFor checkinstall, preinstall, and postinstall scripts you should perform atleast these tests. All tests can be performed on the local system (that is,by doing local installs).

1. The basic test:

• Run swinstall to install the full product (that is, all the filesets).To avoid testing the configure script(s), either do not include anyin the product, or set the defer_configure option to “true.”

• After the installation completes, check the<${SW_ROOT_DIRECTORY}var/adm/sw/swagent.log file forany problems, either in the scripts or the format/contents of themessages generated by the scripts.

• Study the resulting file system to see if the scripts performed theexpected actions.

• Re-run the test by re-installing the same product.

2. If you want to avoid the time spent loading files, then set thereinstall_files option to “false” and thereinstall_files_use_cksum option to “false.”

3. If a previous version of the product can be updated to this version,then re-run the test by updating this product where the previousversion has been installed.

Chapter 11 295


4. If your checkinstall script can generate ERROR or WARNINGconditions based on the current activity or configuration of the targetsystem, then enable those conditions to ensure that the checkinstallscript correctly detects them.

5. Re-run the test by installing into an alternate root directory(swinstall -r ) instead of the primary root directory (“/”). Makesure that the scripts perform all of their operations (if any) within thealternate root directory. (This verifies the correct use of${SW_ROOT_DIRECTORY} by your scripts.)

6. If your product is locatable (that is, it can be installed into a differentlocation), then re-run the tests by installing the product into adifferent location (swinstall product:new_location ). Make surethat the scripts perform all of their operations in the new location,and not the default location. (This verifies the correct use of$SW_LOCATION by your scripts.)

7. If you have a complex script, run additional tests for your productthat you feel will give you confidence your product has been installedcorrectly on the system. For example, only install certain subsets ofyour product instead of the full product.

Testing Configuration ScriptsFor configure, verify, and unconfigure scripts you should perform at leastthese tests. All tests can be performed on the local system (that is, bydoing local installs).

1. Run swinstall to install the full product (that is, all the filesets).Let the installation process perform the configuration task (and runyour configure script(s)).

• After the installation and configuration completes, check the${SW_ROOT_DIRECTORY}var/adm/sw/swagent.log file forany problems, either in the configure script or the format/contentsof the messages generated by it.

• Study the resulting file system to see if the configure scriptperformed the expected actions.

• Test the product itself to see if the necessary configuration taskswere performed such that the product is ready to use.

2. Run swremove to removed the configured product.

296 Chapter 11


• After the unconfiguration and removal completes, check the${SW_ROOT_DIRECTORY}var/adm/sw/swagent.log file forany problems, either in the unconfigure script or theformat/contents of the messages generated by it.

• Study the resulting file system to see if the unconfigure scriptperformed the expected “undo” actions.

3. Run swinstall to install the full product again. Set thedefer_configure option to “false” to avoid executing the configurescripts.

• After the installation completes, run swconfig to configure yourproduct.


• Test the product itself to see if the necessary configuration taskswere performed such that the product is ready to use.

• Now run swconfig -u to unconfigure your product.

• Study the resulting file system to see if the unconfigure scriptperformed the expected “undo” actions.

• Run swconfig again to re-configure your product.


4. Run swverify to execute the verify script(s).

• After the verification completes, check the${SW_ROOT_DIRECTORY}var/adm/sw/swagent.log file forany problems, either in the verify script or the format/contents ofthe messages generated by it.

5. If a previous version of the product can be updated to this version,then re-run the first test by updating this product to a system wherethe previous version has been installed and configured.

6. Note that configure and unconfigure scripts are never run unless the${SW_ROOT_DIRECTORY} is / . However, verify scripts are run in bothcases.

Chapter 11 297


7. If your product is locatable (that is, it can be installed into a differentlocation), then re-run the tests by installing and configuring theproduct in a different location. Make sure that the scripts perform alltheir operations in the new location, and not the default location.(This verifies the correct use of $SW_LOCATION by your scripts.)

8. If you have a complex script, run additional tests for your productthat you feel will give you confidence your product has been installedcorrectly on the system. For example, only install certain subsets ofyour product instead of the full product.

Testing Removal ScriptsFor checkremove, preremove, and postremove scripts you should performat least these tests. All tests can be performed on the local system (thatis, by doing local installs). There is no value gained by testing yourscripts by installing to remote target systems.

1. Run swinstall to install the full product (that is, all the filesets).Avoid configuration by setting the defer_configure option tofalse .

• Run swremove to removed the unconfigured product.

• After the removal completes, check the${SW_ROOT_DIRECTORY}var/adm/sw/swagent.log file forany problems, either in the removal scripts or the format/contentsof the messages generated by the scripts.

• Study the resulting file system to see if the removal scriptsperformed the expected actions.

2. Run swinstall to install the full product (that is, all of the filesets).Let the installation process perform the configuration task (and runyour configure script(s)).

• Run swremove to removed the configured product.

• After the unconfiguration and removal completes, check the${SW_ROOT_DIRECTORY}var/adm/sw/swagent.log file forany problems, either in the removal scripts or the format/contentsof the messages generated by the scripts.

• Study the resulting file system to see if the removal scriptsperformed the expected actions.

298 Chapter 11


3. If your checkremove script can generate ERROR or WARNINGconditions based on the current activity or configuration of the targetsystem, then enable those conditions to ensure that the checkremovescript correctly detects them.

4. Re-run the first test by installing into an alternate root directory(swinstall -r ) instead of the primary root directory (“/”). Makesure that the scripts perform all of their operations (if any) within thealternate root directory. (This verifies the correct use of${SW_ROOT_DIRECTORY} by your scripts.)

5. If your product is locatable (that is, it can be installed into a differentlocation), then re-run the tests by installing the product into adifferent location. When removing the product, make sure that theremoval scripts perform all of their operations in the new location,and not the default location. (This verifies the correct use of$SW_LOCATION by your scripts.)

6. If you have a complex script, run additional tests for your productthat you feel will give you confidence your product has been installedcorrectly on the system. For example, only install certain subsets ofyour product instead of the full product, then perform the removeoperations. (Or only remove subsets of the fully installed product.)

Chapter 12 299

Requesting User Responses

12 Requesting User Responses

SD-packaged applications can use interactive control scripts to query auser and obtain installation or configuration information that cannot beknown at package time. For example, a different hardware or OS mayrequire the software to be installed to be configured differently. Or, somesoftware may need information such as IP address, hostname, for itsconfiguration.

SD runs the interactive control scripts by the swask command or by theask default option for the swinstall and swconfig commands. (SDdoes not query the user but the control script does.)

Topic Page

“The swask Command” 300

“Running Request Scripts from swinstall or swconfig” 306

“Writing Request Scripts” 307

300 Chapter 12

Requesting User ResponsesThe swask Command

The swask CommandThe swask command runs interactive software request scripts for thesoftware objects selected. These scripts store the responses in aresponse file (named “response”) for later use by the swinstall orswconfig commands. (The swinstall or swconfig commands canalso run the interactive request scripts directly, using the ask option.)

As with any other SD-UX command, swask requires that you assembleoptions, targets and defaults into a command line or use commandoptions to “point” to files containing targets, default behavior changesand other variables.

The swask command uses the command-line interface only; there is noGraphical User Interface.

SyntaxThe command syntax for swask is:

swask [-v ] [-c catalog] [-C session_file] [-f software_file][-s source][-S session_file][-x option=value][-X options_file][software_selections]

ExamplesRun all request scripts from the default depot (/var/spool/sw ) and write theresponse file (response ) back to the same depot:

swask -s /var/spool/sw \*

Run the request script for Product1 from depot/tmp/sample.depot.1 on remote host swposix , create the catalog/tmp/test1.depot on the local controller machine, and place theresponse file (response ) in the catalog:

swask -s swposix:/tmp/sample.depot.1 \-c /tmp/test1.depot Product1

Run request scripts from remote depot /tmp/sample.depot.1on host swposix only when a response file is absent, create the catalog/tmp/test1.depot on the local controller machine, and place theresponse file (response ) in the catalog:

Chapter 12 301


swask -s swposix:/tmp/sample.depot.1 \-c /tmp/test1.depot -x ask=as_needed \*

Command OptionsThe swask command supports the following options. Note that if the -soption is specified, software is selected from the distribution source. Ifthe -s option is not specified, software installed on the target systems isselected. For each selected software that has a request script, executingthat script generates a response file. By specifying the -c catalog option,swask stores a copy of the response file to that catalog for later use byswinstall or swconfig .

Option Action

-v Turns on verbose output to stdout.

-c catalog Specifies the pathname of an exported catalog whichstores the response files created by the request script.swask creates the catalog if it does not already exist.

If the -c catalog option is omitted and the source islocal, swask copies the response files into the sourcedepot: distribution. path / catalog.

-C session_file Saves the current options and operands to session_filefor re-use in another session. You can enter a relativeor absolute path with the file name. The defaultdirectory for session files is $HOME/.sw/sessions/ .You can recall a session file with the -S option.

-f software_file Reads the list of software_selections from software_fileinstead of (or in addition to) the command line.

-s source Specifies the source depot (or tape) from whichsoftware is selected for the ask operation.

-S session_file Executes swask based on the options and operandssaved from a previous session, as defined insession_file. You can save session information from acommand-line session with the -C session_file option.

-x option=value Sets a specific default option to value and overrides thedefault value (or a value in an alternate option_filespecified with the -X option). You can specify multiple-x options on a single command line.

302 Chapter 12


-X option_file Read a list of options and behaviors from option_file.

Command OperandsThe swask command operates on the host software_selections operand.This operand specifies the depot to be operated on by its absolutepathname (host: path, as with other commands).

The \* software specification selects all products. It is not allowed whenremoving software from the root directory / .

swask supports the following syntax for each software_selection:

bundle[. product[. subproduct][. fileset]][, version]product[. subproduct][. fileset][, version]

The version component has the form:

[,r <op> revision][,a <op> architecture][,v <op> vendor][,c <op> category][,l= location][,fr <op> revision][,fa <op> architecture]

• location applies only to installed software and refers to softwareinstalled to a location other than the default product directory.


• The <op> (relational operator) component can be of the form: ==, >=,<=, <, >, or != which performs individual comparisons ondot-separated fields. For example, r>=B.11.00 chooses all revisionsgreater than or equal to “B.11.00”. The system compares eachdot-separated field to find matches.

• The = (equals) relational operator lets you specify selections with theshell wildcard and pattern-matching notations: [ ] , * , ?, ! Forexample, the expression r=1[01].* returns any revision in version10 or version 11.

• All version components are repeatable within a single specification(e.g. r>=AA.12, r<AA.20 ). If multiple components are used, theselection must match all components.

• Fully qualified software specs include the r= , a=, and v= versioncomponents even if they contain empty strings. For installedsoftware, l= must also be included.

• No space or tab characters are allowed in a software selection.

Chapter 12 303


• The software instance_id can take the place of the version component.It has the form: [instance_id] within the context of an exportedcatalog, where instance_id is an integer that distinguishes versions ofproducts and bundles with the same tag.

304 Chapter 12


Changing Default OptionsIn addition to the command-line options listed above, swask behaviorsand policy options can be changed by editing the default option valuesfound in either of these two files:

/var/adm/sw/defaults The system-wide defaults file.

$HOME/.swdefaults The user-specific defaults file.

Values must be specified in the defaults file using this syntax:

[command_name. ]option=value

The optional command_name prefix denotes one of the SD commands.Using the prefix limits the change in the default value to that command.If you leave the prefix off, the change applies to all commands.

You can also override default values from the command line with the -xor -X options:

command -x option=valuecommand -X option_file

The following table lists all of the default option keywords supported byswask . If a default value exists, it is listed after the “=”. See Appendix A,“Default Options and Keywords,” for a complete listing and description ofthese defaults.

Table 12-1 swask Default Options

ask=true

autoselect_dependencies=true

autoselect_patches=true

enforce_scripts=true

log_msgid=0

logdetail=false

logfile=/var/adm/sw/swask.log

loglevel=1

patch_filter

verbose=1

Chapter 12 305


Using the ask OptionThe ask option has three possible values;

true (Default for swask ) Executes the request script (if oneexists for the selected software) and stores the userresponse in a file named response .

false Does not execute request scripts.

as_needed Before executing a request script, swask firstdetermines if a response file already exists andexecutes the request script only if the response file isabsent.

Using Session FilesEach invocation of the swask command defines an ask session. Theinvocation options, source information, software selections, and targethosts for this session are saved before the installation or copy taskactually commences. This lets you re-execute the command even if thesession ends before proper completion.

Each session configuration is automatically saved to the file$HOME/.sw/sessions/swask.last . This file is overwritten at eachinvocation of swask .

You can save a session configuration to a specific file by executing swaskwith the -C session_file option.


To re-execute a session file, specify the session file as the argument forthe -S session__file option of swask .

Note that when you re-execute a session file, the values in the session filetake precedence over values in the system defaults file. Likewise, anycommand line options or parameters that you specify when you invokeswask take precedence over the values in the session file


306 Chapter 12

Requesting User ResponsesRunning Request Scripts from swinstall or swconfig

Running Request Scripts fromswinstall or swconfigYou can run request scripts from the swinstall or swconfigcommands by setting the ask option to “true”. This tells the commandsto run request scripts (if any exist) in addition to performing install orconfiguration tasks. (Note that the value of the ask option if “false” forboth swinstall and swconfig but is “true” for swask .)

Examples

swinstallTo install all the software from local depot tmp/sample.depot.1 usingany response files generated by request scripts:

swinstall -s /tmp/sample.depot.1 -x ask=true \*

To install Product1 from remote depot /tmp/sample.depot.1 on hostswposix and use an existing response file (previously generated by theswask command) located in /tmp/bar.depot :

swinstall -s swposix:/tmp/sample.depot.1 \-c /tmp/bar.depot Product1

To install all products in remote depot /tmp/sample.depot.1 on hostswposix , use any response files generated by request scripts, createcatalog /tmp/bar.depot and copy all response files to the new catalog:

swinstall -s swposix:/tmp/sample.depot.1 \-c /tmp/bar.depot -x ask=true \*

To install all products in remote depot /tmp/sample.depot.1 on hostswposix , use response files, run request scripts only when a responsefile is absent, create catalog /tmp/bar.depot and copy all response filesto the new catalog:

swinstall -s swposix:/tmp/sample.depot.1 \-c swposix:/tmp/bar.depot -x ask=as_needed \*

Chapter 12 307

Requesting User ResponsesWriting Request Scripts

swconfigTo configure Product1 , use any associated response files generated by arequest script, and save response files under /tmp/resp1 :

swconfig -x ask=true -c /tmp/resp1 Product1

Writing Request ScriptsFor information about writing control scripts, see Chapter 11, “UsingControl Scripts.”.

• Request scripts are interactive scripts that request a response fromthe user as part of software installation or configuration. Thepathname of the script being executed is:

[$ {SW_CONTROL_DIRECTORY}request ]

• Request scripts write information into a response file for later use bythe configure script or other scripts. You can run requests scripts byexecuting the swask command or using the ask=true option withswinstall or swconfig after selection and before the analysisphase.

• The POSIX default for request scripts is a shell script. The shellscript must be able to:

• Ask questions of the user.

• Read the user’s answer.

• List all current user responses in a redrawn screen.

• Ask the user to confirm an answer and continue or to go back.

• The request script stores the user response in a response file. Thepath of the response file is accessible by theSW_CONTROL_DIRECTORY environment variable.

• The POSIX recommendation for response file format is the SVR4model of attribute/value pairs. Answers should be written to theresponse file in env_var= value format so that the response files canbe easily used by other control scripts.

308 Chapter 12

Requesting User ResponsesWriting Request Scripts

• When you use a request script to get install information, HPrecommends that you use a checkinstall script to check for properexecution of the request script. The checkinstall script should:





Appendix A 309

Default Options and Keywords

A Default Options and Keywords

This appendix lists all SD-UX default options.

Topic Page


“Defaults Listed Alphabetically” 311

310 Appendix A

Default Options and KeywordsIntroduction

IntroductionSD-UX command behaviors and policy options may be changed bymodifying default values found in /usr/lib/sw/sys.defaults andstoring them in the system level (/var/adm/sw/defaults ) or user level($HOME/.sw/defaults ) defaults files. Values in these defaults arespecified using this syntax:

command.option=value

For example, to change the use_alternate_source default from“false” to “true” for an installation, edit the defaults file to include thisline:

swinstall.use_alternate_source=true

These values can also be overridden by the -X options_file option (whichuses the same format as the defaults files) or with the -x option=valueoption directly on the command line. They can also be changed using theGUI Options Editor.

Altering default values and storing them in a defaults file can help whenyou want the command to behave the same way each time the commandis invoked.

Appendix A 311

Default Options and KeywordsDefaults Listed Alphabetically

Defaults Listed Alphabetically• agent=/usr/lbin/swagent

This is the default location of the executable invoked to perform agenttasks.

Applies to swagentd .

• agent_auto_exit=true

Causes the target agent to automatically exit after execute phase, orafter a failed analysis phase. This is forced to “false” when thecontroller is using an interactive UI, or when -p (preview) is used.

Enhances network reliability and performance.

The default is “true” - the target agent will automatically exit whenappropriate.

If set to “false”, the target agent will not exit until the controllerexplicitly ends the session.

Applies to swconfig , swcopy , swinstall , swremove , andswverify .

• agent_timeout_minutes=10000

Causes a target agent to exit if it has been inactive for the specifiedtime.

You can use this default value to make target agents more quicklydetect lost network connections. (RPC can take as long 130 minutes todetect a lost connection.) The recommended value is the longestperiod of inactivity expected in your environment.

For command line invocation, a value between 10 and 60 minutes issuitable. More than 60 minutes is recommended when a graphicalinterface will be used.

The default is 10,000 minutes, which is slightly less than seven days.

Applies to swcopy , swinstall , swlist , swremove , and swverify.

312 Appendix A


• allow_downdate=false

Normally set to “false,” so installing an older version of software thanalready exists is disallowed. This keeps you from installing olderversions by mistake. Additionally, many software products will notsupport this “downdating.”

If set to “true,” a previous version can be installed but a warningmessage will be issued.

Applies to swinstall .

• allow_incompatible=false

Normally set to “false,” only software compatible with the local host isallowed to be installed or configured.

If set to “true,” no compatibility checks are made.

Applies to swconfig , swinstall , and swverify .

• allow_multiple_versions=false

Normally set to “false,” so installed or configured multiple versions(for example, the same product, but a different revision, installed intoa different location) are disallowed. Even though multiple installedversions of software are supported if the software is locatable,multiple configured versions will not work unless the productsupports it.

If set to “true,” you are allowed to install and manage multipleversions of the same software.

Applies to swconfig, swinstall, and swverify.

• alternate_source=

Syntax is host:path , used when use_alternate_source defaultis set to “true.”

By default, this option is not defined. If the host portion is notspecified, the local host is used. If the path is not specified, the pathsent by the command is used. See the use_alternate_sourcedefault.

The protocol sequence and endpoint given by the optionrpc_binding_info_alt_source are used when the agent attemptsto contact an alternate source depot.

Applies only to swagent .

Appendix A 313


• ask=true

Executes a request script, which asks for a user response.

The ask option has three possible values;

true (Default for swask ) Executes the request script (ifone exists for the selected software) and stores theuser response in a file named response .

false (Default for swinstall and swconfig .) Does notexecute request scripts.

as_needed Before executing a request script, swask firstdetermines if a response file already exists andexecutes the request script only if the response fileis absent from the control directory.

See Chapter 12, “Requesting User Responses,” on page 299 for moreinformation on the swask command. See Chapter 11, “Using ControlScripts,” on page 265 for more information on request scripts.

Applies to swask , swconfig , and swinstall .

• ask=false

See ask=true .

• auto_kernel_build=true[false]

Normally set to true. Specifies whether the removal of a kernel filesetshould rebuild the kernel or not. If the kernel rebuild succeeds, thesystem will automatically reboot. If set to false, the system willcontinue to run the current kernel.

If the auto_kernel_build option is set to “true”, the autorebootoption must also be set to “true”. If the auto_kernel_build optionis set to “false” the value of the autoreboot option does not matter.

Applies only to swremove .

314 Appendix A


• autoreboot=false

Normally set to “false,” installation of software requiring a reboot isnot allowed from the command line.

If set to “true,” this option allows installation or removal of thesoftware and automatically reboots the local host.

If the auto_kernel_build option is set to “true,” this option mustalso be set to “true.”

Applies to swinstall and swremove .

• autorecover_product=false

Normally “false,” files are removed as they are updated byswinstall . If there is a load error, the product loading will bemarked “corrupt” and the install must be retried.

When this option is “true,” all files are saved as backup copies untilall filesets in the current product loading are complete; then they areremoved. At the cost of a temporary increase in disk space and slowerperformance, this allows for automatic recovery of filesets in thatproduct if the load fails.

Note: The autorecover operation will not work properly if anysoftware has pre-install scripts that move or remove files. Thisincludes HP-UX operating system files.

Applies only to swinstall .

• autoselect_dependencies=true

Causes SD-UX to automatically select requisites when software isbeing selected. When set to “true,” and any software which hasrequisites is selected, it makes sure that the requisites are met. Ifthey are not already met, they are automatically selected for you. Ifset to “false,” automatic selections are not made to resolve requisites.

Applies to swconfig , swcopy , swinstall and swverify .

Appendix A 315


• autoselect_dependents=false

Causes swconfig to automatically select dependents when softwareis being selected. When set to “true,” and any software on which othersoftware depends is selected, SD-UX makes sure that the dependentsare also selected. If they are not already selected, they areautomatically selected for you. If set to “false,” dependents are notautomatically selected.

Applies to swconfig and swremove .

• autoselect_patches=true

Automatically selects the latest patches (based on superseding andancestor attributes) for a software object that a user selects for aswinstall or swcopy operation. When set to “false,” the patchescorresponding to the selected object are not automatically selected.

You can use the patch_filter= option in conjunction withautoselect_patches .

Applies to swask , swinstall and swcopy .

• autoselect_reference_bundles=true

If “true,” a bundle that is “referenced” will be installed along with thesoftware from which it is made.

Applies to swcopy , swinstall and swremove .

• check_contents=true

Normally set to “true,” verify mtime, size and cksum of files.

If “false,” the software can be installed without the bundle thatcontains it.

Applies only to swverify .

• check_permissions=true

Normally set to “true,” verify owner, uid, group, gid and modeattributes of files.


• check_requisites=true

Normally set to “true,” verify that the prerequisites and corequisitesof filesets are being met.


316 Appendix A


• check_scripts=true

Normally set to “true,” run the vendor-supplied verify scripts wheninstalling software.


• check_volatile=false

Normally set to “false,” include installed files in the verification thathave the is_volatile attribute set. By default, installed volatilefiles do not have their attributes verified because they are volatile bydefinition.


• codeword=

This default allows you to enter your codeword for the softwarelicensing procedure. Once entered you need not re-enter thecodeword.

If a new HP product is purchased and a previous codeword has beenentered for that CD-ROM, enter the new codeword normally, and thecodewords will be merged internally.

• compress_cmd=/usr/contrib/bin/gzip

This is the command called by the source agent to compress filesbefore installing, copying or packaging.

If the compression_type option is set to other than “gzip” or“compress”, this path must be changed.

Applies to swagent and swpackage .

• compress_files=false

Normally set to “false,” files will not be compressed before transferfrom a remote source and uncompressed after transfer.

If set to “true,” compressing files will enhance performance on slowernetworks (50 Kbytes/sec. or less) However, it may not improve fastnetworks.

If set to “true,” depots will be smaller, unless uncompress_files isalso set to “true.”

Applies to swcopy , swinstall and swpackage .

Appendix A 317


• compression_type=gzip

Defines the default compression type used by the agent (or set byswpackage ) when it compresses files during or after transmission.

If uncompress_files is set to “false,” the compression type isrecorded for each file compressed so that the correct uncompressioncan later be applied during a swinstall , or a swcopy withuncompress_files set to “true.”

The compress_cmd specified must produce files with thecompression_type specified.

The uncompress_cmd must be able to process files of thecompression_type specified unless the format is “gzip” which isuncompressed by the internal uncompressor (“funzip”). To use “gzip”you must load the SW-DIST.GZIP fileset. If the SW-DIST.GZIP fileset(which is optional freeware) is loaded, then you may set thecompression options to:

compress_cmd=/usr/contrib/bin/gzip

uncompress_cmd=/usr/contrib/bin/gunzip

compression_type=gzip

Applies to swpackage and swagent .

• config_cleanup_cmd=/usr/lbin/sw/config_clean

Defines the script called by the agent to perform release-specificconfigure cleanup steps.


• control_files=

When adding or deleting control file objects, this option lists the tagsof those control files. There is no supplied default. (Control file objectsbeing added can also be specified in the given product specificationfile.)

If there is more than one tag, they must be separated by white spaceand surrounded by quotes.


318 Appendix A


• controller_source=

Specifies the location of a depot for the controller to access to resolveselections. Setting this option can reduce network traffic between thecontroller and the target. Use the target selection syntax to specifythe location:

[host ][:][path ]

This option has no effect on which sources the target uses and isignored when used with an Interactive User Interface.

Applies to swconfig , swcopy , swinstall , swremove andswverify .

• create_target_acls=true

Normally set to “true,” this default determines whether swpackagewill create Access Control Lists (ACLs) in the depot.

If you are superuser and this option is set to “false,” ACLs for eachnew product being packaged (and for the depot, if it is new) will not becreated.

When swpackage is invoked by any other user, it will always createACLs in the distribution depot. This default has no impact on theACLs that already exist in the depot. The swpackage commandnever creates ACLs when software is packaged onto a distributiontape.

Applies only to swpackage .

• create_target_path=true

Normally set to “true,” creates the target directory if it does notalready exist.

If “false,” target directory is not created. This option can be used toavoid creating new depots by mistake.


Appendix A 319


• customer_id=

This default allows you to enter your customer identification numberfor the software licensing procedure. Once entered, you need notre-enter the customer_id.

The customer_id is printed next to the codeword on your HP SoftwareCertificate which you receive with the software.

The customer_id must be typed in using either the -x customer_id=option or the Interactive User Interface.

• defer_configuration=false

Causes swinstall to automatically configure software_selectionsafter they are installed. When an alternate root directory is specified,swinstall never performs the configuration task, since only hostsusing the software should be configured. If set to “true,” this optionallows configuration to be deferred, even when the root directory is /.

When installing a successive version of a product, it will not beconfigured if another version is already configured. The swconfigcommand must be run separately.

Applies only to swinstall

• distribution_source_directory=:/var/spool/sw

Defines the default distribution directory to read as the source whensource_type is “directory”. The -s option overrides this default.

Applies to swcopy , swinstall , and swpackage .

• distribution_target_directory=/var/spool/sw

Defines the default distribution directory of the target depot. Thetarget_selection operand overrides this default.

Applies to swacl , swcopy , swlist , swmodify , swpackage , swreg ,swremove and swverify .

• distribution_target_serial=/dev/rmt/0m

Defines the default location of the target tape device file. Thetarget_selection operand overrides this default.


320 Appendix A


• enforce_dependencies=true

Normally set to “true,” dependencies will be enforced. The install,configure and copy commands will not proceed unless necessarydependencies have been selected, or already exist in the proper state(“installed,” “configured” or “available”, respectively). This preventsunusable software from being installed on the system. It also ensuresthat depots contain usable sets of software. The swremove commandalso supports this option, which means that, by default, dependentsoftware cannot be removed.

If set to “false,” dependencies will still be checked, but not enforced.Corequisite dependencies, if not enforced, may keep the software fromworking properly. Prerequisite dependencies, if not enforced, maycause the installation or configuration to fail.

Applies to swconfig , swcopy , swinstall , swremove andswverify .

• enforce_dsa=true

Normally set to “true,” installations will not proceed if the disk spacerequired to install the software is more than the available free space.Use this option to allow installation into minfree space, or to attemptthe load even though it may fail because the disk reaches its absolutelimit.

If set to “false,” space checks are still performed but a warning isissued that the system may not be usable if the disk fills past theminfree threshold. An installation will fail if you run out of diskspace.


• enforce_kernbld_failure = true

Controls whether or not a failure in either of the kernel build steps(system_prep and mk_kernel) is fatal to the install session. A failureto build a kernel will cause the install process to exit if innon-interactive mode, or to suspend if in an interactive mode.

If set to “false”, a failure return from a kernel build process will beignored, and the install session will proceed. The currently runningkernel will remain in place.


Appendix A 321


• enforce_scripts=true

Normally set to “true,” if a product or fileset checkinstall orcheckremove script fails (that is, returns with exit code 1), none of thefilesets in that product will be loaded.

If set to “false,” the operation will proceed even though a check scriptfails. This option can be used to force installation or removal bycircumventing check scripts.

Applies to swinstall and swremove .

• files=

When adding or deleting file objects, this option can list the pathnames of those files. There is no supplied default. File objects beingadded can also be specified in the given product specification file.

If there is more than one path name, they must be separated by whitespace and surrounded by double-quotes.


• follow_symlinks=false

Do not follow symbolic links that exist in the packaging source;instead, package them as symlinks.


• include_file_revisions=false

Normally set to “false,” controls whether swpackage includes eachsource file's revision attribute in the product(s) being packaged.Because this operation is very time consuming, the revisionattributes are not included by default.

A value of “true” for this keyword causes swpackage to executewhat(1) and possibly ident(1) (in that order) to try to determine afile's revision.


• install_cleanup_cmd= /usr/lbin/sw/install_clean

The script called by the agent to perform release-specific installcleanup steps immediately after the last postinstall script has beenrun. For an OS update, this script should at least remove commandsthat were saved by the install_setup script.


322 Appendix A


• install_setup_cmd=/usr/lbin/sw/install_setup

Defines the script called by the agent to perform release-specificinstall preparation. For an OS update, this script should at least copycommands needed for the checkinstall, preinstall, and postinstallscripts to a path where they can be accessed while the real commandsare being updated.

This script is executed before any kernel filesets are loaded.


• kernel_build_cmd=/usr/sbin/mk_kernel

This is the script called by the agent for kernel building.


• kernel_path=/stand/vmunix

The path to the system's bootable kernel. It is passed to thekernel_build_cmd via the SW_KERNEL_PATH environmentvariable.


Appendix A 323


• layout_version=1.0

Specifies the POSIX layout version to which the SD commandsconform when writing distributions and swlist output. Supportedvalues are 1.0 (default) and 0.8. The SD commands for HP-UX version10.10 and later can read or write either version.

SD object and attribute syntax conforms to layout version 1.0 of theIEEE Standard 1387.2, Software Administration (POSIX). SDcommands still accept the keyword names associated with the olderlayout version, but you should only use layout version 0.8 to createdistributions readable by older versions of SD.

The version used by swpackage can be controlled by specifying thelayout version attribute in the product specification file (PSF).However, if the layout version attribute in the PSF is 1.0, theis_locatable attribute defaults to “true” in all cases, and must beexplicitly set to “false.”

Layout version 1.0 adds significant functionality not recognized bysystems supporting only version 0.8, including:

• Category class objects (formerly the category andcategory_title attributes within the bundle or product class).

• Patch-handling attributes, including applied_patches ,is_patch , and patch_state .

• The fileset architecture attribute, which permits you to specifythe architecture of the target system on which the product willrun.

In addition to adding new attributes and objects, layout version 1.0changes the following preexisting 0.8 objects and attributes:

• Replaces the depot media_sequence_number with the mediaobject with a sequence number attribute.

• Replaces the vendor definition within products and bundles with avendor_tag attribute and a corresponding vendor object definedoutside the product or bundle.

• Pluralizes the corequisite and prerequisite filesetattributes.

• Changes the timestamp attribute to mod_time .

• Applies to swcopy , swlist , swmodify and swpackage .

324 Appendix A


•• level=

Specifies a software level for swacl , swlist and swreg .

For swlist -- lists all objects down to the specified level. Both thespecified levels and the depth of the specified software_selectionscontrol the depth of the swlist output. The supported softwarelevels are:

• bundle -- show all objects down to the bundle level.

• product -- show all objects down to the product level. Also use -lbundle -l product to show bundles.

• subproduct -- show all objects down to the subproduct level.

• fileset -- show all objects down to the fileset level. Also use -lfileset -l subproduct to show subproducts.

• file -- show all objects down to the file level (depots, products,filesets, and files).

• category -- show all categories of available software objects.

• patch -- show all applied patches.

The supported depot and root levels are:

• depot -- show only the depot level (depots that exist at thespecified target hosts.

• root -- list all alternate roots.

• shroot -- list all registered shared roots (HP-UX 10.X only).

• prroot -- list all private roots (HP-UX 10.X only).

For swacl -- the level option defines the level of ACLs to view ormodify:

• host -- view or modify the ACL protecting the host systemsidentified by the target_selections.

• depot -- view or modify the ACL protecting the software depotsidentified by the target_selections.

• root -- view or modify the ACL protecting the root file systemsidentified by the target_selections.

Appendix A 325


• product -- view or modify the ACL protecting the software productidentified by the software_selection. Applies only to products indepots, not installed products in roots

• product_template -- view or modify the template ACL used toinitialize the ACLs of future products added to the software depotsidentified by the target_selections.

• global_soc_template -- view or modify the template ACL used toinitialize the ACLs of future software depots or root file systemsadded to the hosts identified by the target_selections.

• global_product_template -- view or modify the template ACL usedto initialize the product_template ACLs of future software depotsadded to the hosts identified by the target_selections.

For swreg -- the level option defines the level of object to register orunregister.

• depot -- depots that exist at the specified target hosts.

• root -- all alternate roots.

• shroot -- all registered shared roots (HP-UX 10.X only).

• prroot -- all registered private roots (HP-UX 10.X only).

Applies to swacl , swlist , and swreg .

• log_msgid=0

Controls whether numeric identification numbers are prepended tolog file messages produced by SD-UX. The default value of 0 indicatesno such identifiers are attached. Values of 1-4 indicate that identifiersare attached to messages:

• 1 applies to ERROR messages only

• 2 applies to ERROR and WARNING messages

• 3 applies to ERROR, WARNING, and NOTE messages

• 4 applies to ERROR, WARNING, NOTE, and certain other log filemessages.

Applies to swconfig , swcopy , swinstall , swreg , swremove andswverify .

326 Appendix A


• logdetail=false

The logdetail option controls the amount of detail written to thelog file. When set to “true,” this option adds detailed task information,such as options specified, progress statements, and additionalsummary information, to the log file.

Table A-1 shows the possible combinations of loglevel andlogdetail options.

Table A-1 loglevel and logdetail Option Combinations

a. Requiredb. Setting both the loglevel=2 and logdetail=true options is

required. With this combination you may get the same logfilebehavior as previous HP-UX 10.x releases.

Applies to swconfig , swcopy , swinstall , swreg , swremove andswverify .

• logfile=/var/adm/sw/<command>.log

This is the default controller log file for each command. The agent logfiles are always located relative to the target depot or target root:/var/spool/sw/swagent.log and /var/adm/sw/swagent.log ,respectively.

Applies to all commands except swacl , swlist and swjob .

Log Level Log Detail Information Included

loglevel=0 No information is written to thelog file

loglevel=1 logdetail=false Only key events are logged. This isthe default.

loglevel=1 logdetail=true Event detail as above plus taskprogress messages. (Settingloglevel=1 is not necessary; it is thedefault.)

loglevel=2 a logdetail=false Event and file level messages only.Setting the logdetail=false optionis not necessary.

loglevel=2 b logdetail=true All information is logged.

Appendix A 327


• loglevel=1

This option controls the log level for events logged to the command logfile, the target agent log file and the source agent log file byprepending identification numbers to SD log file messages. Thisinformation is in addition to the detail controlled by the logdetailoption. A value of:

• 0 -- provides no information to the log files

• 1 -- enables verbose logging to the log files

• 2 -- enables very verbose logging to the log files.

Applies to swconfig , swcopy , swinstall , swmodify , swpackage ,swremove and swverify .

• match_target=false

If set to “true,” forces selection of filesets from the source that matchfilesets already installed on the target system.

Filesets on the source which specify an installed fileset as an“ancestor” will be selected.

This option overrides any other software selections.

Selections cannot be ambiguous.


• max_agents=-1

The maximum number of agents that are permitted to runsimultaneously. The value of -1 means there is no limit.

Applies only to swagentd .

• media_capacity=1330

If you are creating a distribution tape, this default specifies thecapacity of the tape in one million byte units (not Mbytes). Thisoption is required if the media is not a DDS tape or a disk file.Without this option, swpackage sets the size to:

tape 1330 megabytesdisk file free space on the disk up to minfree


328 Appendix A


• media_type=directory

Defines the type of distribution to create. The recognized types aredirectory and tape. Without this option, swpackage creates adistribution directory (depot) by default.


• mount_all_filesystem=true

Normally set to “true,” the commands automatically try to mount allfile systems in the file system table (/etc/checklist ) at thebeginning of the analysis phase and make sure that all those filesystems are mounted before proceeding.

When set to “false,” no additional file systems are mounted.

Applies to swconfig , swcopy , swinstall , swremove , swverify .

• mount_cmd=/sbin/mount

This is the command called by the agent to mount all file systems.


• objects_to_register=

Defines the default objects to register or unregister. If there is morethan one object, they must be separated by spaces.

There is no supplied default. See also select_local .

Applies only to swreg .

• one_liner=<attributes>

Defines the attributes listed in the non-verbose listing.

If there is more than one attribute, they must be separated by a spaceand surrounded by quotes.

one_liner="revision size title"

You must choose which attributes (that is, revision, size, title, etc.) adefault listing of software should use. Note: the tag attribute isalways displayed for bundles, products, subproducts and filesets; thepath will always be displayed for files.

Appendix A 329


Any attributes may be chosen but a particular attribute may not existfor all applicable software classes (bundle, product, subproduct,fileset). For example, the software attribute, title is available forbundles, products, subproducts and filesets, but the attributearchitecture is only available for products.

In the absence of the -v or -a option, swlist will display one_linerinformation for each software object (bundles, products, subproductsand filesets).

Applies only to swlist .

• os_name

Specifies fileset selection for an HP-UX update. (This option shouldalways be used with the os_release option.) You must specify thisoption from the command line or when invoking the swinstall GUI.

This options has the following syntax:

os_name=operating_system: width

• operating_system specifies the name of the operating system, suchas HP-UX. See the uname(1) manual page for completeinformation.

• width specifies the word width in bits (either 32 or 64) of the OS tobe installed.

• operating_system and width must be separated by a colon (: ).


• os_release

Specifies fileset selection for an HP-UX update. (This option shouldalways be used with the os_name option.) You must specify thisoption from the command line or when invoking the swinstall GUI.

This options has the following syntax:

os_release= release

release specifies the HP-UX release. Values include:

B.10.01B.10.10B.10.20B.10.30B.11.00


330 Appendix A


• package_in_place=no

Normally set to “no,” a value of “yes” for this keyword causesswpackage to build the specified products such that the depot willnot actually contain the files that make up a product. Instead,swpackage inserts references to the original source files used to builda product. This behavior allows the packaging of products in adevelopment or test environment without consuming the full diskspace of copying all the source files into the distribution depot.


• patch_commit=false

Commits a patch by removing files saved for patch rollback. Thedefault value is “false.” When set to “true,” this option removes thesaved files for the patches specified in the software selections for thecommand. Once you have run this option on a patch, you cannotremove the patch unless you remove the associated base softwarethat the patch modified.


• patch_filter=*.*

Specifies a software_specification for a patch filter.

This option can be is used in conjunction with theautoselect_patches and patch_match_target options to filterthe selected patches to meet the criteria specified bysoftware_specification. The default software_specification value is*.* .

Applies to swask , swcopy and swinstall .

• patch_match_target=false

If set to “true,” this option selects the latest patches (softwarepackaged with the is_patch attribute set to “true”) that correspondto software on the target root or depot.

The patch_filter= option can be used with thepatch_match_target option.


Appendix A 331


• patch_one_liner=title patch_state

Use this command to specify the attributes displayed for each objectlisted when the -l patch option is invoked and when no -a or -voption is specified. The default display attributes are title andpatch_state.

Applies to swlist and swjob .

• patch_save_files=true

Saves patched files, which permits future rollback of patches. Whenset to “false,” patches cannot be rolled back (removed) unless the basesoftware modified by the patch is removed at the same time.

Applies to swinstall .

• polling_interval=2

Normally set to 2. The polling_interval option applies only tointeractive sessions. It specifies how often each target will be polledfor status information during the analysis and execution phases.When operating across wide-area networks, the polling interval canbe increased (higher number=longer interval between polls) to reducenetwork overhead.

Applies to swcopy , swinstall and swremove .

• reboot_cmd=/sbin/reboot

This is the command called by the agent to reboot the system.

Applies to swagent .

• reconfigure=false

This option prevents software that is already in the configured statefrom being reconfigured. If set to “true,” configured software can bereconfigured.

Applies to swconfig .

332 Appendix A


• register_new_depot=true

Normally set to “true,” a newly created depot is registered on its host.This allows other commands to automatically see this depot.

If set to “false,” new depots are not registered. This could allow you tocreate a private depot on which to test, then later register it withswreg.

Applies only to swcopy .

• register_new_root=true

Causes swinstall to register a newly-created alternate root withthe local swagentd . This allows other SD commands to automaticallysee this root.

If set to “false,” a new root will not be automatically registered. It canbe registered later with the swreg command.


• reinstall=false

Normally set to “false,” an existing revision of a fileset that is alreadyinstalled or available will not be reinstalled or recopied.

If set to “true,” the fileset will be reinstalled or recopied.


• reinstall_files=true

Normally set to “true,” all files within a fileset will be reinstalled(overwritten) when that fileset is installed or reinstalled (seereinstall=false option above).

When set to “false,” files that have the same checksum (see nextoption), size and mtime will not be reinstalled. This enhancesperformance on slower networks.


Appendix A 333


• reinstall_files_use_cksum=true

Normally set to “true,” this option affects the operation when thereinstall_files option is set to “false.” Using cksum is slower, butis a more robust way to check for files being equivalent. This is thedefault for swinstall and swcopy . The default is “false” forswpackage , a less reliable, but faster option.


• remove_empty_depot=true

When the last product (or bundle) in a depot is removed, the depotitself will be removed.

If set to “false,” the depot is not removed when the last product (orbundle) in it is removed. This preserves that depot’s ACL.

Applies only to swremove .

• remove_obsolete_filesets=false

This command controls whether swcopy automatically removesobsolete filesets from target products in the target depot. If set to“true,” swcopy removes obsolete filesets from the target products thatwere written during the copy process. Removal occurs after the copyis complete. Filesets are defined as obsolete if they were not part ofthe most recent packaging of the product residing on the sourcedepot.

Applies only to swcopy .

• remove_setup_cmd=/usr/lbin/sw/remove_setup

Defines the script called by the agent to perform release-specificremoval preparation. For an OS update, this script invokes the tlinkcommand when a fileset is removed.

Applies only to swagentd .

334 Appendix A


• retry_rpc=1

This command defines the number of times a lost source connectionwill be retried during file transfers. A lost connection is one that hastimed out. When used in conjunction with the rpc_timeout option,the success of installing over slow or busy networks can be increased.If set to zero, any rpc_timeout to the source causes the task toabort. If set from 1 to 9, the install of each fileset is attempted thatnumber of times. The reinstall_files option should also be set to falseto avoid installing files that were successfully installed within thefileset.


• rpc_binding_info=ncacn_ip_tcp:[2121] ncadg_ip_udp:[2121]

An advanced feature that determines on what protocol sequence(s)and endpoint(s) the daemon listens. If the connection fails for oneprotocol sequence, the next is attempted. SD supports both the tcpand udp protocols on most platforms.

The value (values for swagentd) can have the following form:

• A DCE string binding containing a protocol sequence and anendpoint (a port number). The syntax is:

protocol_sequence:[ endpoint]

The name of a DCE protocol sequence with no endpoint specified.This syntax is:

ncadg_ip_udp or ncacn_ip_tcp

Since no endpoint is specified, the DCE endpoint mapper rpcdmust be running and is used to find the endpoint registered byswagentd

• The literal string “all.” This entry means to use all protocolsequences supported by the DCE Remote Procedure Call (RPC)runtime. It should be the only entry in the list. The rpcd must berunning.

Applies to all commands except swask , swmodify , and swpackage .

Appendix A 335


• rpc_timeout=5

Relative length of the communications timeout. This is a value in therange from 0 to 9 and is interpreted by the DCE RPC. Higher valuesmean longer times; you may need a higher value for a slow or busynetwork. Lower values will give faster recognition of attempts tocontact hosts that are not up or are not running swagentd .

Each value is approximately twice as long as the lower one. A value of5 is about 30 seconds for the ncadg_ip_udp protocol sequence. Thisoption may not have noticeable impact when using the ncacn_ip_tcpprotocol sequence.

Applies to all commands except swmodify and swpackage .

• select_local=true

Normally set to “true,” selects the default depot or installationdirectory of the local host as the target of the command.

Applies to swacl , swconfig , swcopy , swinstall , swlist , swreg ,swremove , swverify .

• software=

Defines the default software_selections.

There is no supplied default. If there is more than onesoftware_selection, they must be surrounded by brackets { } or quotes.Software is usually specified in a software_selections input file, asoptions on the command line or in the GUI or TUI.

Applies to all commands except swreg .

• software_view=products

Indicates which software view is to be used in the GUI. It can be setto products, all_bundles, or a bundle category tag (shows only bundlesof that category). The default view is all_bundles plus products thatare not part of a bundle.

Applies to swcopy , swinstall , swlist and swremove .

• source_cdrom=/SD_CDROM

Defines the default location of the source CD-ROM. The syntax canbe: host:path .


336 Appendix A


• source_depot_audit=true

If both source and target machine are updated to HP-UX version10.30 or later, the system administrator at the source depot machinecan set this option to track which user pulls which software from adepot on the source machine and when the software is pulled.

A user running swinstall or swcopy from a target machine cannotset this option; only the administrator of the source depot machinecan set it.

When source_depot_audit is set to its default value of “true,” aswaudit.log file is created on the source depot (for writabledirectory depots) or in /var/tmp (for tar images, CD-ROMs, or othernonwritable depots).

To view, print, or save the audit information, invoke the swlistinteractive user interface (using swlist -i -d ).

You can view audit information based on language preference, as longas the system has the corresponding SD message catalog files on it.For example, you can view the source audit information in Japaneseduring one invocation of swlist , then view the same information inEnglish at the next invocation.

Applies to swagent , swinstall , and swlist .

• source_file=psf

This keyword defines the default product_specification_file to read asinput to the packaging or swmodify session. It may be a relative orabsolute path.

Applies to swpackage and swmodify .

• source_tape=:/dev/rmt/0m

Defines the default tape location, usually the character-special file ofa local tape device. If the host:path syntax is used, the host mustmatch the local host. The -s option overrides this value.


• source_type=directory

The default source type (choices are “cdrom”, “file”, “directory”, or“tape”) that points to one of the next three options. The source typederived from the -s source file option overrides this default.

Appendix A 337


The “cdrom” and “tape” values apply to swcopy and swinstall . The“file” value applies only to swpackage .

• system_file_path=/stand/system

The path to the kernel's template file. The path is passed to thesystem_prep_command via the SW_SYSTEM_FILE_PATHenvironment variable.


• system_prep_cmd=/usr/lbin/sysadm/system_prep

The kernel build preparation script called by the agent. This scriptmust do any necessary preparation so that control scripts cancorrectly configure the kernel that is about to be built.


• targets=

There is no supplied default (see also select_local). If there is morethan one target, they must be separated by spaces. Targets areusually specified in a target input file, as options on the command lineor in the GUI.

Applies to all commands.

• uncompress_cmd=

This is the command called by the source agent to uncompress fileswhen installing, copying or packaging.

This command processes files that were stored on the media incompressed format. If the compression_type of the file is gzip , theinternal compression (funzip ) is used instead of the externaluncompress command.

Applies to swagent and swpackage .

338 Appendix A


• uncompress_files=false

When set to “true,” files are uncompressed using the currentuncompress_cmd before storing them on the target depot.

Only one of the uncompress_files and compress_files optionsmay be set to “true” during a swpackage session.

The uncompress_files option may not be set to “true” ifpackage_in_place is set to “true” or if the media_type is set to“tape.”

Applies to swcopy and swpackage .

• use_alternate_source=false

When the local host begins an analysis or task, the request usuallyincludes information describing the source binding and depot paththat the local host should use as the software source.

If “false” (the normal case), the local host will use this information tocontact the source.

If “true,” the local host will instead use its own configured value.

On the local host, the agent's configured value foralternate_source is specified in host:/path format. If this valuecontains only a path component (for example,alternate_source=:/path ), the agent applies this path to the filesystem of its own local host.

If only the host component exists (for example,alternate_source=host ), the agent applies the controller-suppliedpath to this host. If there is no configured value at all for thealternate_source , the agent applies the controller-supplied pathto its own local host.


Appendix A 339


• verbose=1

By default, the command sends output to stdout for task summarymessages. Alternatively, the verbose option can be set to 0 for sessionlevel messages (no output to stdout ) or (for swpackage andswmodify ) to 2 for file level messages.

Error and warning messages are always written to stderr .

For the swlist command, a verbose listing includes all attributesthat have been defined for the appropriate level of eachsoftware_selection operand. The attributes are listed one per line,prefaced by the attribute keyword.

The -v option overrides this default, if it is set to 0.

Applies to all commands.

• write_remote_files=false

Prevents installation, copying or packaging of files to a target thatexists on a remote (NFS) file system. By default, files that would beinstalled, copied or removed on a remote (NFS) file system or arealready there will be skipped.

If set to “true” and superuser has write permission on the remote filesystem, the remote files will be installed, copied, packaged orremoved.

Applies to swcopy , swinstall , swpackage , and swremove .

340 Appendix A


Appendix B 341

Troubleshooting SD

B Troubleshooting SD

This appendix explains how SD's error messages are used, reviews SD'serror logging process and lists several common problems you mightencounter and how to resolve them.

Table B-1

Topic Page

“SD Error Logging” 342

“Problems” 344

342 Appendix B

Troubleshooting SDSD Error Logging

SD Error LoggingAll SD commands (except swlist and swacl ) log error messages,summary information about the session, and operation details to acommand-specific logfile located (by default) in/var/adm/sw/< command>.log . For example, if you wanted to examinethe logfile for swinstall , you would look in the file/var/adm/sw/swinstall.log . You can also examine target agentlogfiles for a current session from the swinstall , swcopy , or swremoveGUIs.

If you have log-in access to a target host, you can see its agent logfile(s)directly. The location of the agent logfile varies, depending on the type oftarget:

• /var/adm/sw/swagent.log when operating on a host's “primary”root.

• /<root_path>/var/adm/sw/swagent.log for an alternate root.

• /<depot_path>/swagent.log for a target or source depot.

The default location of a host's daemon logfile is/var/adm/sw/swagentd.log . This logfile contains information forproblems starting agents, particularly for problems where you haveaccess denied to a depot or root.

NOTE When both the source and target machine are updated to HP-UX 10.30or later, the system administrator at the source depot machine can trackwhich user pulls which software from a depot and when the software ispulled. Refer to the source_depot_audit option in Appendix A,“Default Options and Keywords,” or “Using the Source Depot Audit Log”on page 72.

Appendix B 343

Troubleshooting SDSD Error Logging

Error MessagesSD error messages indicate that a problem occurred that will influencethe overall outcome of an operation.

For example, if a target in an install session fails the analysis phase dueto insufficient disk space, you would find the following error message inthe agent log file:

ERROR: The estimated disk space used on filesystem "/" is14104 Kbyte blocks. This operation will exceed the minimumfree space for this disk. You should free up at least 2280Kbyte blocks to avoid installing beyond this threshold ofavailable user disk space. If you are running interactive"swinstall", you must return to the Selection Window andUnmark this target before using "swremove" to free diskspace.

Warning MessagesWarning messages let you know that something unexpected andpotentially undesirable occurred. A warning event will not prevent theSD session from continuing. Warning messages during the analysisphase of an interactive session give you the opportunity to continue orstop (at your own discretion).

For example, if the fileset SD-DATABASE.SD-DATABASE2 is beinginstalled in multiple locations on a target system, you would find thefollowing warning message in the agent log file:

WARNING:A version of fileset "SD-DATABASE.SD-DATABASE2,r=9.00.1C"is already installed in another location (see previouslines). Installing this version will create multipleinstalled versions. This new multiple version will beinstalled because the "allow_multiple_versions" option isset to "true".

NotesNotes are used to notify you of an event that is not erroneous,unexpected or undesirable, but you should be aware of it:

NOTE: The fileset "SD-DATABASE.SD-DATABASE1,r=9.00.1C" is alreadyinstalled. If you wish to reinstall this fileset, change the"reinstall" option to "true".

344 Appendix B

Troubleshooting SDProblems

ProblemsThis section presents a selection of problems you might encounter andhow to resolve them.

Cannot Contact Target Host Daemon/AgentIf you see the following error message:

ERROR: Could not contact host <hostname>. Make sure the hostnameis correct.

it means that the hostname you specified could not be found in the hostsdatabase. Make sure you have typed the hostname correctly (you can usethe nslookup(1) command to verify hostnames). If the target hostnameis not in the hosts database, but you know its network address, you canuse it (in standard “dot” notation) in place of the hostname.

If you see this error message:

ERROR: A Remote Procedure Call to a daemon has failed. Could notstart a management session for <target>. Make sure thehost is accessible from the network, and that its daemon,swagentd, is running. If the daemon is running see thedaemon logfile on this target for more information.

it means SD could not contact the daemon program on a specific targetsystem. Note that this may occur even if you haven't specified anytargets, for example, if the daemon on your local host is not running andthe select_local option is set to “true.”

Resolution:If the SD daemon/agent is not installed on a given target system, youmust install it before you can begin managing the system with SD.

If you've verified that the daemon/agent component has been installed ona target system and you still have trouble contacting it, check to see thatthe daemon is running:

1. On the target system, type:

ps -e | grep swagentd

Appendix B 345


2. If the daemon does not appear to be running, you can start it bytyping (as root on the target system):

/usr/sbin/swagentd

3. If you attempt to start a daemon when one is already running, youwill see a message about the other daemon; this is harmless.

You can also kill and restart a currently running daemon by typing:

/usr/sbin/swagent -r

Other possible causes for this problem are listed in the section“Connection Timeouts and Other WAN Problems” on page 350.

Tip:An easy way to determine if a target system has the SD daemon installedand running is to type:

/usr/sbin/swlist -l depot @ < one or more target hostnames>

which will attempt to contact each target to get a list of registereddepots. Those targets which have the SD daemon installed will reporteither:

# Initializing...# Target <hostname> has the following depot(s):<list of depots>...

or

# Initializing...WARNING: No depot was found for <hostname>.

For more information on daemon activity, see the daemon logfile in/var/adm/sw/swagentd.log .

346 Appendix B


Access To An Object Is DeniedThere are a number of things that can cause denial of access to SDobjects.

• ACL Permissions

• The effects of ACL modifications

• Modifying ACLs without using swacl

• Inter-host Secrets

• Working with “image” copies of depots

Resolution:Generally, when you are denied access to an SD object, the system tellsyou that you do not have the required access permission for the object.Sometimes it may be unclear which object is not accessible. For example,when using swcopy to copy a product from system A to a depot, anumber of ACLs may be checked:

1. If the destination depot does NOT exist, the host ACL is checked toverify that the user has “insert” permission.

2. If the destination depot does exist, the depot ACL is checked to verifythat the user has “write” permission.

3. The source depot's ACL is checked to make sure the user has “read”permission on the source depot.

4. The source product's ACL is also checked to make sure that the userand the destination system both have “read” access to the product.

If any of these access permissions is absent, the whole operation isdisallowed and the error message becomes critical in understanding thecause. To see more about what type of security or access problems exist,see the daemon log file on the target system:/var/adm/sw/swagentd.log

The Effects of ACL ModificationsThe default SD ACLs make it fairly easy to administer ACLs, but do notalways give the desired level of access control. When restricting access,especially by removing the any_other “read” permission, it is fairly easy

Appendix B 347


to restrict access in unexpected ways. Remember that “host” entries arerequired for any destination systems for swcopy and swinstalloperations.

Review Chapter 7, “Modifying IPD or Catalog Contents,” on page 139 fora full discussion of the access tests performed by SD for each operation.

The Effects Of Modifying ACL Files Without swacl

Since ACLs in SD are stored in the file system as plain text files, it maybe tempting to edit them with a conventional editor. This can lead tounexpected corruption of the ACL. Most cases of this corruption simplyresult in a message indicating the corruption, but inserting additions tothe ACL file without updating the num_entries value can result inunreported problems leading only to denial of access. A common failurecould occur, for instance, if a user entry were inserted, pushing the“any_other” entry down beyond the num_entries limit, resulting in theSD ACL manager never reading the any_other entry and causingproblems. The best guard against this is to always use the swaclcommand to manipulate ACLs.

Inter-host SecretsThe default /var/adm/sw/security/secrets file shipped with SDcontains a single entry:

default -sdu-

The “-sdu-” should be replaced by a different default secret, or the entireentry eliminated if you wish to explicitly name all hosts from whichcontrollers can be run. See Chapter 7, “Modifying IPD or CatalogContents,” on page 139 for a thorough discussion of the secrets file.

The controller (for swinstall , swcopy , etc.) looks up the secret for thesystem on which it runs and passes it in an encrypted form to its agent.The agent receiving a request from the controller looks up the secret forthe host from which the call comes, encrypts it and compares theencryption to that provided by the controller. If the two secrets do notmatch, access is denied. If you have problems with this mechanism,make sure that all systems have matching entries. You can also revert tothe original secrets file (/etc/newconfig/sd/secrets on 9.x and/usr/newconfig/var/adm/sw/security/secrets on 10.x) on allhosts, or simply copy a single secrets file to all hosts.

348 Appendix B


Working With Depot “Images”There is a problem in using cp , tar , cpio , dd , and other commands tocopy images of depots for use on other systems. The problem is that depotand product ACLs in the image have built-in knowledge of the host onwhich the depot originated. In particular, the ACL's default realm will bewrong and local users will be confused with users on the originating host.For example, attempts to add local users to the access list will, in fact,grant access to remote users.

Other problems can also arise. Since there is no way to alter the defaultrealm of an ACL from that set when it is created, this is an intractableproblem. Another common problem with such images occurs when theyare imported to systems which cannot resolve all the hostnames (seeresolver(4) and nslookup(1) ) which exist in the ACLs.

If your purpose is to create a “staged” installation, use swcopy topropagate the depot. This will create new ACLs, based on localtemplates, for each instance of the depot.

If the sole intent of a depot is for such image distribution, you may wishto set the swpackage.create_target_acls option to false toprevent ACL creation on the depot and products during the swpackageoperation. This is the option used to create tape and CD-ROM images.ACL-less depots and products grant the local superuser all privileges,while all other users and systems have read access. Note that when youcopy or install this ACL-less depot with swcopy or swinstall , thecopies (installations) are automatically protected by ACLs based ontemplates on the destination host.

Appendix B 349


Slow Network PerformanceWhen using swinstall or swcopy in an environment where networkbandwidth is the “bottleneck,” the file transfer rate between source andtarget(s) can become very slow.

Resolution:The compress_files=true option compresses files transferred from asource depot to a target. This can reduce network usage byapproximately 50%; the exact amount of compression depends on thetype of files. Binary files compress less than 50%, text files generallycompress more.

The greatest throughput improvements are seen when transfers areacross a slow network (approximately 50kbyte/sec or less), and thesource depot server is serving a few target hosts at a time.

NOTE This option should be set to “true” only when network bandwidth isclearly restricting total throughput. If this option is used with a fastnetwork or with a depot server simultaneously connected to many targethosts, this option can actually reduce overall throughput or performance,unless the source depot is already compressed.

If it is not clear that this option will help in your situation, compare thethroughput of a few install or copy tasks (both with and withoutcompression) before changing this option value.

350 Appendix B


Connection Timeouts and Other WANProblemsLow-throughput, wide-area networks can cause SD to encountertime-out problems when establishing and maintaining networkconnections with remote agents on other systems.

If you see the following messages:

ERROR: A Remote Procedure Call to a daemon has failed. Couldnot start a management session for <target>. Make sure thehost is accessible from the network, and that its daemon,swagentd, is running. If the daemon is running see thedaemon logfile on this target for more information.

or

ERROR: Could not perform the requested operation for <target>,possibly due to a network communications failure. Checkthat the host is still accessible from the network.

and you have verified that the system is up and the daemon program(swagentd ) is running on it, it may be that network delays are causingthe connection to time-out.

Resolution:Increase the time-out value used by SD when performing RemoteProcedure Calls (RPCs) by specifying a higher value for therpc_timeout option, either via the command line or in the defaults file.RPC time-out values range from 0 to 9, with 9 being the longest time-out.The SD default RPC time-out value is 5. Note that these values do notrepresent any specific time units. See Appendix A, “Default Options andKeywords,” on page 309 for more information on the rpc_timeoutoption.

Increasing the rpc_timeout can also help in situations where thetarget agents in an install or copy session are timing out when trying tocontact the source agent. This problem is indicated by the following errormessages in the agent log file:

ERROR: Could not open remote depot/root <path> due to an RPCor network I/O error.

ERROR: Cannot open source. Check above for errors, as well as thedaemon logfile on the source host (default location:/var/adm/sw/swagentd.log).

ERROR: Cannot continue the Analysis Phase until the previouserrors are corrected.

Appendix B 351


Another factor that can affect RPC timeouts on a slow network is thechoice of network protocol. SD supports both UDP- and TCP-basedcommunication (the default is UDP). TCP communication can be morereliable on a WAN because it is connection-based. If you are still havingtime-out problems on a slow-throughput WAN, you can tell SD to use theTCP-based communication instead, via the rpc_binding_info option:

rpc_binding_info=ncacn_ip_tcp:[2121]

As with any controller option, you can specify this option on thecommand line using the -x option or by editing the defaults file. Notethat the daemon program (swagentd ) listens for both UDP- andTCP-based RPCs by default. See Appendix A, “Default Options andKeywords,” on page 309 for more information on therpc_binding_info option.

A final WAN-related issue may arise when using the interactive GUI.During the analysis and execution phases of an interactive SD session,each target agent is periodically “polled” for up-to-date statusinformation. The polling_interval option can be used to control thenumber of seconds that elapse between successive status polls of a giventarget system. On networks where even this minor data transfer is aproblem, you can increase this polling interval, thus decreasing thefrequency of polling, and reducing an interactive session's overalldemands on the network. See Appendix A, “Default Options andKeywords,” on page 309 for more information on thepolling_interval option.

352 Appendix B


Disk Space Analysis Is IncorrectYour installation or copy operation runs out of space even though thedisk space analysis succeeded.

Upon further checking, you find that the results of the disk spaceanalysis differ from the actual space available.

Resolution:Possible causes of this problem:

• A control script associated with the installation has consumed diskspace by creating or copying additional files that aren't accounted forduring analysis.

• Your target systems were not idle when the analysis was done andsome other activity (unrelated to SD or another active SD session)was consuming disk space.

• The depot from which the product was installed or copied was createdby swpackage with the package_in_place option set to true , andsource files have been modified since the product was packaged. Theswverify command can be used to diagnose this problem.

The Packager FailsA swpackage operation may fail because of the incorrect use of the endkeyword in the Product Specification File (PSF).

Resolution:The end keyword marks the end of a depot, vendor, product, subproductor fileset specification in a PSF. It requires no value and is optional.However, if you use it and it is incorrectly placed, the specification willfail. Check to make sure, if you use it, there is an end keyword for everyobject specification (especially the last one).

Appendix B 353


Truncating The Daemon LogfileIf you want to shorten (truncate) the SD daemon logfile because it isgetting too long, follow this procedure:

Resolution:If the daemon is currently running, DO NOT remove its logfile. Therunning daemon will continue to log messages to its logfile even afteryou've removed it, causing any subsequent information to be lost. Also,the disk space used by the logfile will not be freed as long as the daemonis running.

Instead, truncate the logfile by typing (as root):

echo > /var/adm/sw/swagentd.log

which replaces the data that was there with an empty string.

If you inadvertently remove the daemon logfile while it is running, youmust kill and restart the daemon if you want to see subsequent daemonlog messages and free up the disk space used by the logfile. You can stop(kill) a daemon by typing:

usr/sbin/swagentd -k

You can also kill and restart a currently running daemon by typing:

usr/sbin/swagentd -r

Cannot Read a Tape DepotIf you are trying to access a tape depot and see the following errormessage in the daemon logfile, it means that the tape is either corrupt oris not in SD format.

ERROR: The INDEX file on the source did not exist or could not beread.

ERROR: The target <depot_path> could not be opened.

Resolution:Make sure that you have correctly specified the tape device and that thecorrect tape is in the drive. SD will only read tapes that are in SD format(for example, SD does not read update(1m) format tapes).

354 Appendix B


Installation FailsIf an installation fails part way through the install, SD lets you easilyrestart the operation (either by just re-executing the same commandfrom the command line, or by recalling the session file swinstall.lastthat was automatically saved for you).

By default, SD checkpoints to the fileset level, meaning that theoperation will start transferring files with the last fileset to beattempted. By setting the reinstall_files option to false, thedistribution and installation of files will begin with the file that was lastattempted. SD does not support checkpointing below the file level. Also,all checkpointing can be overridden by setting both the reinstall andreinstall_files options to true.

See Appendix A, “Default Options and Keywords,” on page 309 for moreinformation on these options.

Appendix C 355

Replacing or Updating SD-UX

C Replacing or Updating SD-UX

Topic Page


“Getting SD-UX Tools from Media” 357

“swgettools Information” 359

“SW-DIST Installation Examples” 360

356 Appendix C

Replacing or Updating SD-UXIntroduction

IntroductionThis appendix describes how to extract a new SW-DIST from the 11.00tape or CD-ROM, or from a software depot.

The software product called SW-DIST provides all SD-UX functionality,commands, and tools. (SW-DIST is included on your HP-UX 11.X Core OSDisk or Tape.)

You need the 11.00 version of SW-DIST to install or copy any HP-UXsoftware that has been packaged in the 11.00 SD-UX format.

This means you must replace or update SW-DIST when:

• You upgrade your operating system to HP-UX Version 11.00. You canthen use the latest SD-UX commands to update your system.

• Your current copy of SW-DIST is damaged, corrupted, or missing.

NOTE For complete instructions regarding updating HP-UX, refer to InstallingHP-UX 11.00 and Updating HP-UX 10.x to 11.0 (B2355-90153).

Appendix C 357

Replacing or Updating SD-UXGetting SD-UX Tools from Media

Getting SD-UX Tools from MediaTo update SD-UX, you must first load and run the swgettools script.This script creates the SW-GETTOOLS product, which updates SW-DISTand then removes itself.

Prerequisites• The swgettools script needs a temporary directory with at least 2

MB of free space. If there is not enough space in the temporarydirectory, swgettools will fail.

By default, swgettools uses the /var/tmp directory. Use thecommand bdf /var/tmp to determine if /var/tmp has adequatespace.

If you do not have 2 MB free in /var/tmp , use the -t option tospecify a different temporary directory. (See “Options” below.)

• The SW-GETTOOLS product requires enough space to install thefollowing files:

/var/adm/sw/lbin (1 MB)/var/adm/sw/sbin (3 MB)/var/adm/sw/lib (6 MB)/usr/lbin/sw/bin (5 MB)

(These files are automatically removed when you reboot.)

• Your system needs at least 32 MB of RAM to successfully update theoperating system.

358 Appendix C

Replacing or Updating SD-UXGetting SD-UX Tools from Media

Procedure1. Load swgettools .

swgettools is shipped in the catalog/SW-GETTOOLS/pfilesdirectory. Depending on the source media, use cp (for CD-ROM), tar(for tape), or rcp (for a software depot on a remote system) to loadswgettools onto your system. (HP recommends that you putswgettools into the /var/tmp directory.)

2. Run swgettools .

The swgettools script creates the SW-GETTOOLS product, whichupdates SW-DIST.

3. If you are reinstalling SW-DIST, reboot the system after you have runswgettools .

4. If you are updating the operating system:

• Use swinstall and the other SD-UX commands to complete theupdate. (See “Using swinstall to Perform an OS Update” onpage 58.)

• Reboot the system.

See “swgettools Information” below for syntax and option information.See “SW-DIST Installation Examples” below for examples.

CAUTION Do NOT use any previous versions of swinstall to update the system to11.00. The update will fail.

CAUTION Ensure that the booted kernel is /stand/vmunix before you install anykernel software. The swinstall process assumes that the system hasbooted using the kernel at /stand/vmunix . Installing kernel softwareor performing an operating system update with any other kernel mightresult in loss of data or other errors.

NOTE For complete instructions regarding updating HP-UX, refer to InstallingHP-UX 11.00 and Updating HP-UX 10.x to 11.0 (B2355-90153).

Appendix C 359

Replacing or Updating SD-UXswgettools Information

swgettools Information

Syntaxswgettools -s source [-t temp_dir_path]

Options-s source Specifies the absolute path of the source media

location. Possible locations are:

• (Default) A local directory that is an SD depot.

• A character-special tape device file connected to atape drive that has an SD media tape loaded.

• A CD-ROM mount point that has an SD mediaCD-ROM loaded.

• A remote machine and depot combination.

The syntax for a remote machine and depotcombination is:

[host]:[/directory]

Specify the remote machine first, followed by theabsolute path to the remote depot, separated by a colonwith no spaces. The host can be specified by its hostname, domain name, or Internet address. For example:

swperf:/var/spool/sw

-t temp_dir_pathSpecifies the absolute path of the temporary directoryused by swgettools process. The default directory is/var/tmp . The temporary directory must exist andhave 2 MB of free space or swgettools will fail.

360 Appendix C

Replacing or Updating SD-UXSW-DIST Installation Examples

SW-DIST Installation Examples

From CD-ROM To install the new SW-DIST product from CD-ROM at/mount/cdrom_depot :

cp /mount/cdrom_depot/catalog/SW-GETTOOLS\/pfiles/swgettools var/tmp

/var/tmp/swgettools -s /mount/cdrom_depot

From Tape To install the new SW-DIST product from tape at /dev/rmt/0m :

cd /var/tmp

tar -xvf /dev/rmt/0m catalog/SW-GETTOOLS/pfiles\/swgettools

cp /var/tmp/catalog/SW-GETTOOLS/pfiles/swgettools \/var/tmp/swgettools

rm -rf /var/tmp/catalog

/var/tmp/swgettools -s /dev/rmt/0m

From Remote Depot To install the new SW-DIST from a remote depot on system swperf at/var/spool/sw , enter the following:

rcp swperf:/var/spool/sw/catalog/SW-GETTOOLS\/pfiles/swgettools /var/tmp

/var/tmp/swgettools -s swperf:/var/spool/sw

Appendix C 361


Updating SD Without Root Access to theRemote Depot

If you are a system administrator and want to permit your users toupdate SD but do not want to grant root access to a remote depot, youhave two options.

Option 1: You can make the swgettools script and the swagent.Z file availableto users via FTP.

1. Copy the swgettools and swagent.Z files from the tape or CD (inthe catalog/SW-GETTOOLS/pfiles directory) to a location to whichyour users have FTP access.

2. Tell the user to:

a. FTP the two files into the /var/tmp directory on the system to beupdated.

b. Use chmod +x to make the swgettools script executable.

c. Run swgettools and specify the remote depot location with the-s option (and, if necessary, use the -t option to specify atemporary directory other than /var/tmp ).

NOTE If you plan to use a temporary directory other then /var/tmp , then cpthe swgettools script and the swagent.Z file to the directory you willuse and specify the directory location on the swgettools command lineusing the -t dir_path command-line option.

Option 2: Users can use the SD swcopy command to copy the SW-GETTOOLS andSW-DIST products from a registered remote source depot to a local depotbefore extracting the files. The remote source depot can be either aCD-ROM or a disk depot.

Tell the user to:

1. Use the swcopy command to copy both the SW-GETTOOLS andSW-DIST products to the local depot. For example, to copySW-GETTOOLS and SW-DIST from the remote CD-ROM depot locatedat swperf:/mount/cdrom to a local depot in /tmp/depot :

swcopy -s swperf:/mount/cdrom SW-GETTOOLS @ \/tmp/depot

362 Appendix C


swcopy -s swperf:/mount/cdrom SW-DIST @ /tmp/depot

2. Copy the swgettools script from the local depot to /var/tmp :

cp /tmp/depot/catalog/SW-GETTOOLS/pfiles\/swgettools /var/tmp

3. Execute the swgettools script, specifying the remote depot toupdate the SW-DIST product:

/var/tmp/swgettools -s swperf:/mount/cdrom

This updates the SD-UX commands on the host system, pulling thenew versions from /tmp/depot .

4. Once the SD-UX commands are updated, use the swremovecommand to remove the temporary depot /tmp/depot to free upspace:

swremove /tmp/depot

5. The user can then use the new SD-UX commands to update the hostsystem's operating system to 11.00:

cp /tmp/depot/catalog/SW-GETTOOLS/pfiles/sw* \/usr/tmp

/usr/tmp/swgettools -s swperf:/mount/cdrom -t \/usr/tmp

For More Information • For complete instructions regarding updating HP-UX, refer toInstalling HP-UX 11.00 and Updating HP-UX 10.x to 11.0(B2355-90153).

• Consult the swgettools(1M) man page (on a 10.10 or later system) forassistance:

• If you encounter an error during the execution of the swgettoolsscript and wish to evaluate the return codes.

• For more information about the files used.

Glossary 363

Glossary

A

Access Control Lists (ACL) Astructure, attached to a softwareobject, that defines accesspermissions for multiple users andgroups. It extends the securityconcepts defined by the HP-UX filesystem mode bits by allowingspecification of the access rights ofmany individuals and groupsinstead of just one of each.

Agent The agent (swagent ) runson the local host. It services allselection, analysis, execution andstatus requests.

Alternate Depot Directory SD-UX allows you to change thedefault location of a depotdirectory.

Alternate Root Directory SD-UX allows you to change thelocation of a root directory to adirectory that may eventually bethe root of another system.

Analysis, Analysis Phase Thesecond phase of a softwareinstallation, copy, or removeoperation, during which the hostexecutes a series of checks todetermine if the selected productscan be installed, copied or removed

on the host. The checks include theexecution of check scripts and DSA(disk space analysis).

Ancestor An “attribute” whichsignifies the name of a previousversion fileset used in the “Match-What-Target-Has” functionality. Ifthe match_target option is set totrue, the system will match theancestor fileset name to the newfileset name.

Architecture This keyworddefines the “architecture” attributefor the product object. It refers tothe operating system platform onwhich the product runs.

Archive file A .o file that needsto be replaced in an existingarchive using the “ar ” command.Used for patch files.

Ask An operation in which SDruns an interactive request scriptto get a response from the user.Request scripts can be run by theswask , swconfig , andswinstall commands.

Attributes Information describinga software object's characteristics.For example, product attributesinclude revision number, tag(name), and contents (list offilesets). Fileset attributes include

364 Glossary

Glossary

tag, revision, kernel, and reboot.File attributes include mode,owner, and group. An essentialpart of the PSF, attributes includesuch information as the product'sshort name or tag, a one-line fullname title or a one paragraphdescription of the object. Otherattributes include a multi-paragraph README file, acopyright information statementand others.

B

Base software Software that willbe modified by a patch.

Building Phase Packaging thesource files and information into aproduct, and creating/merging theproduct into the destination depot/media.

Bundles A collection of filesetsthat are encapsulated for a specificpurpose. By specifying a bundle,all filesets under that bundle areautomatically included in theoperation.

C

Catalog Files This is the areawithin a depot that contains all theinformation needed by SD-UX to

understand the organization andcontents of the products stored inthe depot. It includes a globalINDEX file and a directory ofinformation for each productversion in the depot. It issometimes referred to as thecatalog directory.

Category This keyword definesthe “category” attribute for theproduct object. It refers to the typeof software being packaged.

CD-ROM Media Compact Disc-Read Only Memory. One type ofmedia. Essentially, it is a depotthat resides on a CD-ROM.

CD-ROMs See CD-ROM Media.

Checkinstall Script Anoptional, vendor-supplied scriptassociated with a product or filesetthat is executed during theswinstall analysis phase. Theresult returned by the scriptdetermines if the fileset can beinstalled or updated.

Checkremove Scripts Anoptional, vendor-supplied scriptassociated with a fileset that isexecuted during the swremoveanalysis phase. The resultreturned by the script determinesif the fileset can be removed.

Glossary 365

Glossary

Clients Usually refers to disklessserver computer. SD-UX is oftenused from a diskless server toinstall software.

CLUI Command line userinterface. All SD-UX commandscan be run from the command line.See also GUI, TUI, and IUI.

Compatibility Filtering Thecapability in swinstall to filterthe software available from asource according to the host'suname attributes. Softwareproducts are created to run onspecific computer hardware andoperating systems. Many versionsof the same products may exist,each of which runs on a differentcombination of computer hardwareand operating system. The defaultcondition for compatibility filteringin swinstall is to NOT allowselection and installation ofincompatible software.

Compatible Software A softwareproduct that will operate on agiven hardware system. Softwarethat passes compatibility filteringfor a local host. See IncompatibleSoftware.

Configure Script An optional,vendor-supplied script ofcheckinstall associated with a

fileset that is executed byswinstall (or swconfig ) afterthe installation of filesets iscomplete.

Container ACL Templates Aspecial ACL (global_soc_template)that is used to create initial ACLsfor depot and roots.

Controller The controller is thecomponent of the SD-UX softwaremanagement command that isinvoked by the user on the localhost.

Control Scripts Optional,vendor- or administrator-suppliedscripts that are run duringswinstall and swremove .Includes checkinstall, preinstall,postinstall and configure scriptsfor swinstall ; the checkremove,unconfigure, preremove, andpostremove scripts for swremove ;and the verify script for swverify .

Copyright This keyword definesthe “copyright” attribute for thedestination depot (media) beingcreated/modified by swpackage .It refers to the copyrightinformation that pertains to thesoftware product.

366 Glossary

Glossary

Corequisites A corequisitedependency requires anothersoftware object to be installed inorder for the dependent fileset tobe usable. See Dependency.

Critical Filesets Critical filesetscontain software that is critical tothe correct operation of the host.Critical filesets are those with thereboot and/or kernel fileset flags.During the load phase, criticalfilesets are loaded and customizedbefore other filesets.

Cumulative patch Seesuperseding patches.

D

Daemon/agent See agent orswagentd .

Defaults File The file /var/adm/sw/defaults (system level defaults)or $HOME/.sw/defaults (userlevel defaults), which contains thedefault options and operands foreach SD-UX software managementcommand.

Default Option Value Thechangeable values contained in thedefault option file (above) whichare modified with the syntaxswcommand.option=value .

Dependent A relationshipbetween a fileset and anothersoftware object in which the filesetdepends on the other object in aspecific manner. Also used toidentify the software object uponwhich the dependency exists: forexample, if fileset A depends onfileset B, then B is a dependent ordependency of A. SD-UX supportscorequisite and prerequisitedependencies.

Dependency See Dependent

Depot A repository of softwareproducts and a catalog organizedsuch that the SD-UX softwaremanagement commands can use itas a source. The contents of a depotreside in a directory structure witha single, common root. A depot canexist as a directory tree on a SD-UX file system or on CD-ROMmedia, and it can exist as a tararchive on a serial media. Alldepots share a single logicalformat, independent of the type ofmedia on which the depot resides.

Depot Source A depot that isavailable for use as a source ofsoftware products. A depot sourcein directory format is identified bythe path to a directory where a CD-ROM containing a depot ismounted, or the path to the root

Glossary 367

Glossary

directory of a depot in the filesystem. A depot source in tarformat is identified by the path to atape device containing a tapemedia, or the path to a regular filecontaining a depot in a tararchive. A depot source indirectory format can be remotelyaccessed as a network sourcethrough a swagentd server.

Developer Host Where softwareapplication files are placed forfurther integration andpreparation for distribution.Developer hosts assemble,organize and create product tapesor depots.

Description Vendor-defineddescriptive attribute for productsand filesets. A paragraphdescription of the product orfileset.

Details Dialog The DetailsDialog allows you to obtain moreinformation regarding the specificprocess and monitor its progress.

Directory This keyword definesthe “directory” attribute for theproduct object. The default,absolute pathname to the directoryin which the product will be

installed. Defines the rootdirectory in which the product filesare contained.

Directory Depot The directoryon a target host where the depot islocated. The default is /var/spool/sw.

Disk Space Analysis (DSA)

This process determines if a host'savailable disk space is likely to besufficient for the selected productsto be installed.

Downdating Overwriting aninstalled version of software withan older version.

E

End Ends the depot specification,no value is required. This keywordis optional.

F

Filesets A collection of files. Thesoftware object upon which mostSD-UX software managementoperations are performed.

368 Glossary

Glossary

G

GUI Graphical User Interface. TheOSF/Motif ™ user interfaceprovided with the swinstall ,swcopy and swremove commands(compare to the CLUI or TUI).

H

Host A computer system uponwhich SD-UX softwaremanagement operations areperformed. See local host.

Host ACL The ACL that isattached to, and controls access to,the host object.

I

Incompatible Software

Software products are created torun on specific computer hardwareand operating systems. Manyversions of the same products mayexist, each of which runs on adifferent combination of computerhardware and operating system.Incompatible software does notoperate on the host(s) because ofthe host's computer hardware oroperating system. The default

condition in swinstall is todisallow selection and installationof incompatible software.

INDEX An INDEX file definesattribute and organizationalinformation about an object (forexample, depot, product, or fileset).INDEX files exist in the depotcatalog and the Installed ProductsDatabase to describe theirrespective contents.

INFO An INFO file providesinformation about the filescontained within a fileset. Thisinformation includes type, mode,ownership, checksum, size, andpathname attributes. INFO filesexist in the depot catalog and theInstalled Products Database todescribed the files contained ineach existing fileset.

Input Files Defaults files, optionfiles, software_selection files,target_host files and session_filesthat modify and control thebehavior of the SD-UX softwaremanagement commands.

Installed Products A productthat has been installed on a host sothat its files can be used by end-users. Contrast with a product

Glossary 369

Glossary

residing in a depot on a host's filesystem, sometimes referred to asan “available product.”

Installed Products Database(IPD) Describes the products thatare installed on any given host (orwithin an alternate root). Installedproduct information is created byswinstall , and managed byswremove . The contents of anInstalled Product Database residein a directory structure with asingle common root.

Instance_ID A product attributein the Installed Products Database(IPD) that allows the vendor touniquely identify products withthe same tag (name) or revision.

IPD Installed Products Database.

Is_Locatable This keyworddefines the “is_locatable” attributefor the product object. Defineswhether a product can be installedto an alternate product directory ornot. If specified, the attribute is setto a value of TRUE. If notspecified, the attribute is assigneda value of FALSE.

IUI Interactive User Interface. AllSD-UX commands can be invokedon the command line (commandline user interface or CLUI). In

addition, the swinstall,swcopy, swlist, and swremovecommands offer an interactiveGraphical User Interface (GUI)with windows and pull-downmenus, or a text-based TerminalUser Interface (TUI) in whichscreen navigation is done with thekeyboard (i.e. using tab andcharacter keys; no mouse). IUI is ageneric term that can mean eitherthe GUI or TUI.

I - K

Kernel Filesets A fileset thatcontains files used to generate theoperating system kernel. Duringthe swinstall load phase, kernelfilesets are loaded and customizedbefore other filesets.

Keyword A word (or statement)that tells swpackage about thestructure or content of thesoftware objects being packaged bythe user. Packaging information isinput to swpackage using aProduct Specification File.

L

Load, Load Phase The thirdphase of a software installation orcopy operation; when swinstalland swcopy load product files on

370 Glossary

Glossary

to the host; and when swinstallperforms product-specificcustomization.

Local Host The host on which anSD-UX software managementcommands are being executed.Equivalent to the administrativehost.

Locatable Products A productthat can be relocated to analternate product directory when itis installed. (If a product is notlocatable, then it must always beinstalled within the definedproduct directory.)

Logging Each of the SD-UXsoftware management commandsrecord their actions in log files (theswlist command is an exception).The default location for the variouslog files is /var/adm/sw/

<command>.log .

M

Machine_Type This keyworddefines the “machine_type”attribute for the product object.The machine type(s) on which theproduct will run. (If not specified,the keyword is assigned a wildcardvalue of “*”, meaning it will run onall machines.) If there are multiple

machine platforms, you mustseparate each machine designationwith a | (vertical bar).

Make Tape Phase In packagingsoftware to a distribution tape, thisphase actually copies the contentsof the temporary depot to the tape.

Media See Software Media.

N

Network Source A swagentddaemon that makes products in alocal depot available forswinstall and swcopy access.There can be multiple networksources from a single host, eachone a different depot served bythat host's single swagentddaemon. A network source isidentified by the host name anddepot directory.

Nodes Another name for clienthost. See Client.

Number This keyword definesthe “number” attribute for thedestination depot (media) beingcreated/modified by swpackage .The part or manufacturingnumber of the distribution media(CD or tape depot).

Glossary 371

Glossary

O - P

OS Operating System.

Package Selection Phase Inswpackage , reading theproduct_specification_file todetermine the product,subproduct and fileset structure;the files contained in each filesetand the attributes associated withthese objects.

Patch Software designed toupdate specific bundles, products,subproducts, filesets, or files onyour system. There are pointpatches and superseding(cumulative) patches. Bydefinition, patch software ispackaged with the is_patchattribute set to “true”.

Point patches Separate patchesthat patch separate parts of thesame base fileset.

Postinstall Script An optional,vendor-supplied script associatedwith a fileset that is executed byswinstall after thecorresponding fileset has beeninstalled or updated.

Postremove Scripts Anoptional, vendor-supplied scriptassociated with a fileset that is

executed by swremove after thecorresponding fileset has beenremoved.

Prerequisites A prerequisitedependency requires anothersoftware object to be installed(configured) in order for the firstfileset to be installed (configured).See Dependency.

Preinstall Script An optional,vendor-supplied script associatedwith a fileset that is executed byswinstall before installing orupdating the fileset.

Preremove Scripts An optional,vendor-supplied script associatedwith a fileset that is executed byswremove before removing thefileset.

Principal In SD Security, the user(or host system, for agents makingRPCs) who is originating the call.

Private Roots Directories ondiskless servers that contain theprivate files of the diskless clients.

Products Collections ofsubproducts and filesets. The SD-UX software object that directlyrelates to the software purchasedby the user.

372 Glossary

Glossary

Product ACL Templates Insoftware security, the ACL used toinitialize the ACLs protecting newproducts on depots that arecreated by the host.

Product Directory The rootdirectory of a product object, inwhich (nearly) all its files arecontained. A user can change(relocate) the default productdirectory when installing alocatable product.

Product Specification File(PSF) The input file used to definethe structure and attributes of theproducts to be packaged byswpackage .

Product Versions A depot cancontain multiple versions of aproduct. Product versions havethe same tag attribute, butdifferent version attributes. SeeMultiple Version. An IPD supportsmultiple installed versions of aproduct. Installed product versionshave the same tag attribute, butdifferent version attributes and/ora different product directory.

PSF See Product SpecificationFile.

Push A “push” installation meansthat the administrator can, from acentralized point, simultaneouslyplace one or several copies of thesoftware onto each of severalremote target hosts (that is, “singlepoint administration”).

R

Readme This keyword definesthe “readme” attribute for theproduct object. A text file of theREADME information for theproduct; either the text value itselfor a file name that contains thetext.

Realm The scope of the authorityby which the Principal isauthenticated in software security.

Registers Or Registration.Determines which hosts areavailable for tasks (that is, whichhosts have a daemon running).Also determines what depots areon a given host. Registrationinformation consists of the depot orroot's identifier (its path in thehost file system). This informationis maintained by the daemonwhich reads its own file at start-up.

Glossary 373

Glossary

Request script An interactivecontrol script that gets a responsefrom the user. A request scriptprompts the user for a response,reads the user’s answer, and storesthe results in a response file.Request scripts can be run by theswask , swconfig , andswinstall commands.

Response file A file that isgenerated by an interactive requestscript and contains the user’sresponse.

Revision This keyword definesthe “revision” attribute for theproduct object. The revisioninformation (release number,version) for the product.

Root Directory The directory ona target host in which all the filesof the selected products will beinstalled. The default (/), can bechanged to install into a directorythat will eventually act as the rootto another system. See AlternateRoot Directory.

S

Selection, Selection Phase Thefirst phase of a softwareinstallation, copy, or removeoperation, during which the user

selects the software products to beinstalled on, copied to, or removedfrom the host.

Servers A system on the networkthat acts as a software source forother nodes or clients on thenetwork. Can be a network serveror diskless server.

Session Files Each invocation ofan SD-UX software managementcommand defines a session. Thecontroller automatically savesinvocation options, sourceinformation, software selectionsand host selections in special filelocations before the operationactually starts.

Shared Roots Directories locatedon a diskless server that are thelocation of operating system orapplication software that isshared among the system'sdiskless clients.

Software Depots A system thatcontains one or more softwareproducts that can be installed onother systems. See Depot.

Software Objects The term usedto describe the objects that arepackaged, distributed, installedand managed. The softwarefilesets.

374 Glossary

Glossary

Software Selection Window

The second window to appear inthe GUI. Helps you select thesoftware or data files you want toinstall, copy or remove.

Software Source The term usedto reference a depot being used asthe source of a swinstall orswcopy operation.

Source See Software Source.

Subproducts An optionalgrouping of filesets, used topartition a product which containsmany filesets or to offer the userdifferent views of the filesets.

Superseding patches Patchesthat supersede all previouspatches to a given fileset.

Systems Computers, either stand-alone or networked to othercomputers.

SW-DIST A software product thatprovides all of the SD-UXfunctionality. SW-DIST is includedon your HP-UX 10.X Core OS Diskor Tape. If SW-DIST is damaged,missing, or corrupted on yoursystem, you will NOT be able toinstall or copy any HP-UX

software that is packaged in theSD-UX format, including a newSW-DIST product.

swacl The SD-UX command thatallows you to modify AccessControl List permissions thatprovide software security.

swask The SD-UX command thatallows you to run an interactiverequest script to get a responsefrom the user. Request scripts canalso be run by the swconfig andswinstall commands.

swagentd The daemon thatprovides various services,including initiation ofcommunication between thecontroller and agent, and servingone or more depotssimultaneously to multiplerequesting agents on the host.

swconfig The SD-UX commandthat configures software that hasbeen installed, to make thesoftware ready for use.

swcopy The SD-UX commandthat copies software from anysoftware source to a depot. Theswcopy command can addproducts to an existing depot,replace products already on adepot and create a new depot.

Glossary 375

Glossary

swgettools The SD-UX commandthat lets you install the new SW-DIST product from new SD mediawhen you are updating theoperating system. swgettools isnecessary because the new mediaformat may be different from theSD product that is alreadyinstalled on the host system. Thiscommand is loaded from the newSD media using cp , rcp or tar .

swinstall The SD-UX commandthat installs or updates software.

swlist The SD-UX command thatlists software objects, theirattributes and their organization.It lists both installed software andsoftware contained within a depot.

swmodify The SD-UX commandthat allows you, from the commandline, to change or add to theinformation in the IPD or depotcatalog files.

swpackage The SD-UXcommand used by a softwaresupplier or system administratorto organize software products andpackage them into a depot. Thedepot can be accessed directly bythe SD-UX software managementtools, it can be mastered onto a

CD-ROM depot, or it can be madeavailable to other hosts by theswagentd command.

swreg The command SD-UX usesto register depots.

swremove The SD-UX commandthat removes software that isinstalled, or software containedwith a (writable) depot.

swverify The SD-UX commandthat verifies (for correctness andcompleteness) software that isinstalled, or software containedwithin a depot.

T

Tag This keyword defines thedistribution.tag or product “name”attribute for the destination depot(media) being created/modified byswpackage .

Tape Media One type of softwaremedia. It uses tar to storesoftware products and control filesneeded by the SD to use the media.It usually resides on a serial mediasuch as a DDS, cartridge, nine-track, or other tape, though it canalso be a regular file that containsthe tar archive. Within the tar

376 Glossary

Glossary

archive, directory and file entriesare organized using the samestructure as any other depot.

Tape Depot The software in atape depot is formatted as a tararchive. Encoded in this archive isthe same SD media formatdirectory hierarchy that is used ina directory depot. Tape depots suchas cartridge tapes, DAT and 9-track tape are referred to by thefile system path to the tape drive'sdevice file.

Tape Source A tape media beingused as a source of softwareproducts. A tape source isidentified by the name of thespecial file used to access thedevice where the media resides, orby the name of a regular file thatcontains the tar archive.

Targets A directory on a host inwhich software is installed, copiedor removed. They can operate oneither a target root directory or atarget depot.

TUI Terminal user interface. Acharacter-based display that workson a ASCII terminals and uses thekeyboard to navigate (no mouse).See also CLUI, GUI, and IUI.

Title A one-line, full nameattribute that further identifiesthe product.

U

UUID This keyword defines thevendor's “uuid” attribute for thevendor object. Useful for NetLSvendors and for those who want toselect products from two vendorswho have chosen the samevendor_tag.

Uname Attributes When a targetis contacted for a softwaremanagement operation, thesystem's four uname attributes -operating system name, release,version and hardware machinetype - are obtained. Used todetermine software compatibilitywith the proposed host.

Unconfigure Scripts Anoptional, vendor-supplied scriptassociated with a fileset that isexecuted by swremove before theremoval of filesets begins.

Updates Overwriting softwareobjects already installed on thesystem and replacing them withnew objects.

Glossary 377

Glossary

V - Z

Vendor If a vendor specification isincluded in the PSF, swpackagerequires the “vendor” and “tag”keywords.

Vendor_tag Associates theproduct or bundle with the last-defined vendor object, if that objecthas a matching tag attribute.

378 Glossary

Glossary

Index

Index 379

Symbols$HOME/.sw/defaults.hosts file,

sample, 44$HOME/.sw/sessions/ directory,

14*systemFont, 18*userFont, 18/ (root directory), 24/.sw/defaults.hosts file, 15/.sw/sessions/swcommand>.last

file, 45/.sw/sessions/swinstall

(swcopy).last, 42/.sw/sessions/swremove.last, 130/stand/vmunix kernel, 58, 358/usr/bin/swcopy command, 15,

41/usr/bin/swinstall command, 15,

41/usr/lib/sw/sys.defaults file, 14,

33/var/adm/defaults.hosts file, 15/var/adm/sw/defaults file, 14/var/adm/sw/defaultsor $HOME/

.sw/defaults file, 33/var/adm/sw/products file, 20/var/adm/sw/software/ directory,

14/var/spool/sw/catalog file, 20,

140/var/tmp directory, 357, 361@ ("at") sign, 13

Aabort copy/install, 55Access Control Lists, (ACLs),

173editing, 178entries, 174keys, 175samples, for editing, 194

ACL

creation, swpackage, 253denied access, 346depot, 348effects of modification, 346modifying ACL files without

using swacl, 347packaging, 251

acl_file sample, 182actions menu, 46adding depots, 44adding sources, 43Advanced Topics

swcopy, 58swinstall, 58swlist, 119swremove, 136

agent polling, 351agent=, 311agent_auto_exit=, 311agent_timeout_minutes=1000,

311allow_downdate default, 53allow_downdate=, 312allow_incompatible default, 68

for swconfig, 74allow_incompatible=, 312allow_multiple_versions default,

53, 70allow_multiple_versions=, 312alternate root

directory, 24installing to, 61option -r, 28removing software from, 136

alternate_source=, 312analysis

progress and results,swremove, 132

status, 50Analysis Dialog, 49Analysis Phase, 42analyzing

removal, 132

software, 50targets, 50

any_other permissions, 174app-defaults file, 18architecture field, 20ask option, 305, 313ask=, 313attribute listing, 328attributes, 49

definition, 101patch software, 167patch, file, 171sample, 113

audience for this manual, xixaudit log file, 72authorization, swreg, 99auto_kernel_build=, 313automatic configuration, 24automatic recovery, 314automatic scrolling, 54autoreboot=, 314autorecover, not supported on

HP-UX 10.X products, 40,58

autorecover_product=, 314autorecover_product= default,

40autorecover_product=false

default, 40autoselect_dependencies=, 314autoselect_dependencies=true

option, 66autoselect_dependents=, 315autoselect_patches=, 315autoselect_reference_bundles=,

315AVAILABLE, 54

Bbrackets, 44bundles, 10, 201busy files, swremove, 124

380 Index

Index

C-C option, 29, 77, 87, 95, 127,

144c r w i t, 174, 176catalog files, 20, 140

editing, 20CD-ROM, mastering to, 261change

default option, -x, 30, 78, 87,179

product location, 48software view, 46source, 47, 49source dialog box, 47

changingIPD or catalog files, 140

changing tapes, 55character conventions, xixcheck volatile=, 316check_permissions=, 315check_requisites=, 315check_scripts=, 316check_volatile option, 236checking

dependencies, 91states of versions, 91

checkinstall script, 268details, 282

checkremove script, 124, 270details, 286

client, definition, 5client/server, 1close level, 48codeword=, 316codewords, 8codewords, using, 39, 48Columns Editor, 45command

behavior, 13description, 2operands, 31operands swremove, 127overview, 2

Command Line Interface (CLUI,13

command lines, executing, 12command options

swacl, 179swask, 301swconfig, 77swinstall/swcopy, 28swlist, 104swremove, 127swverify, 87

command.option=value syntax,33

committing patches, 164communication failure, 50compatibility checking

and filtering, 68swremove, 137

COMPLETED, 56completed

with errors, 56with warnings, 56

compress_cmd=, 316compress_files option, 65, 349compress_files=, 316compressing files, 65compression

performance, 349compression_type=, 317config_cleanup_cmd=, 317configuration

automatic, 24permissions, 193phases, 81samples, 76

configure cleanup, 317Configure Phase, 83configure script, 269

definition, 73details, 284executing, 84

Configured, 54CONFIGURED state, 75

configuring software, 73container ACL templates, 189control permission, 176control script

details, 281environment variables, 276execution of other commands,

289file management, 293format, 272guidelines, 275input and output, 290location and execution of, 281request, 271, 273, 288, 307shells, 275swask command, 299testing, 294types, 268writing, 267

control script location, 274control scripts, 202control_files=, 317controller host, 6controller log file, 326controller_source=, 318controlling access to software,

173conventions for this manual, xixcopying

patches, 159permissions, 192software, 23

corequisite, 66, 230definition, 66

Corrupt, 54CORRUPT state, 82create_target_acls option, 261,

348create_target_acls=, 318create_target_path=, 318creating new depots, 44cumulative patches, 150custom lists, 120

Index

Index 381

customer identification number,319

customer IDs, using, 39customer_id, using, 39customer_id=, 319customer_ids, 8

Ddaemon logfile, 353daemon/agent, swreg, 99default

values, changing (swremove),136

default options, listing of, 34default secret, replacing, 347default values, changing, 33defaults

and options list, install andcopy, 34, 62

file, 14for patch management, 152listing of SD-UX, 310option values, 33policy setting, 33precedence, 33swask, 304swlist, 119

defaults.hosts file, 15defer_configuration=, 319defer_configure default, 74definition

Access Control Lists, 173agent, 5architecture field, 20attributes, 101bundles, 10catalog files, 20client, 5compatibility filtering, 23corequisite, 66defaults file, 14depot, 6

depot ACLs, 187depot source, 23developer host, 8fileset, 10host, 5host ACLs, 186host files, 15input files, 14Installed Products Database,

20local host, 5locatable products, 70nodes, 5permission (ACL), 176prerequisite, 66product, 10product ACLs, 188realm, 182root ACLs, 186server, 5session files, 14software objects, 10software selection files, 14software source, 5subproduct, 10system, 5tags, 20target, 5uname attributes, 20

denied access, troubleshooting,346

dependencies, 66, 320listing state of, 67swconfig, 82swremove, 137

dependents, 315depot

ACL samples, 187ACLs, definition, 187adding, 44cannot read, 353commands, swreg, 94creating a new, 44

definition, 6directory, 7distribution, 6images, 348lists, 112multiple, 7on remote file systems, 262registering, 99removing software from, 130,

135source, 23tape, 7

description file, 48designation

default, 26host, 26source, 26syntax, 31

developer host, definition, 8development system, 8directory

/stand/vmunix, 358/var/tmp, 357, 361

directory depot, 7directory mapping, 233directory structures, 200disk space

analysis, 55analysis dialog, 52analysis errors, overriding, 258button, 51, 55failure, 51removing rollback files, 165

disk space analysis, 352DISPLAY variable, 17distribution depot specification,

217distribution directory, 319distribution tape, 327distribution tape format, 246distribution tape, creating a, 243distribution_source_directory=,

319

382 Index

Index

distribution_target_directory=,319

distribution_target_serial=, 319documents related to this

manual, xxdouble click, 48downdate, 33

definition, 53

Eedit permission, swacl, 182editing ACLs, 178enforce_dependencies default,

66swconfig, 75

enforce_dependencies=, 320enforce_dsa option, 258enforce_dsa=, 320enforce_kernbld_failure=, 320enforce_scripts=, 321entry_type, 174

values, 174environment variables, control

scripts, 276error message, control scripts,

275errors

cannot read tape depot, 353daemon logfile, 353denied access, 346disk space analysis is

incorrect, 352installation fails, 354messages, 343network, 350overriding disk space errors,

258PSF syntax, 239reading the PSF, 206RPC timeouts, 350swpackage, 236, 237UNIX packaging, 352

WAN connection timeouts, 350errors and warnings, swremove,

132examples

request scripts, 306swask, 300SW-DIST installation, 360swgettools, 360swmodify, 141

Excluded, 53excluded

due to errors, 50from task, 50

F-f option, 29, 77, 87, 179f1 key, Help, 19failed operations, 343features, swpackage, 241file

attributes, patch, 171catalog, 20level checks, swverify, 92level specifying (swlist), 111response, 288, 301

file revisions (swpackage), 257file specification, 231

explicit, 234recursive (implicit), 237

file structures, 200file system mounting, 328file, audit log, 72files

shareable, 200files=, 321fileset, 10

level, specifying (swlist, 110patch, attributes, 168

fileset specification, 226filesets, 200final copy dialog, 55finishing analysis, 50

flag"yes", 17Marked?, 46

follow_symlinks option, 257follow_symlinks=, 321fonts

changing, 18controlling display, 18fixed width, 18used in this book, xixvariable width, 18

form, product structure, 10

Gglobal_product_templates, 189global_soc_templates, 189go up, 48Graphical User Interface (GUI),

2, 12, 15, 41swlist, 116

grouppermissions, 174

GUI and TUIswlist, 116

GUI and TUI, swremove, 130

HHelp

f1 key, 19menu, 19On-line, 18

hostACLs, definition, 186and depot path pair, 135definition, 5designation, 26files, 15local, 6permissions, 174system ACL, sample, 186system ACLs, 186

Index

Index 383

I-i option, 28images, depot, 348include_file_revisions option,

257include_file_revisions=, 321initial permissions, 190input files, 13, 14, 25insert permission, 176install

analysis, 47dialog, 55

install_cleanup_cmd=, 321install_setup_cmd=, 322Installed, 54Installed Products Database

(IPD), 20INSTALLED state, 75installing

failure, 354from the command line, 25patches, 155permissions, 193software, 23

interactive option, -i, 28, 116inter-host secrets, 347IPD, 20

editing, 20is_kernel attribute, 227is_locatable attribute, 223is_reboot attribute, 71, 227

Kkernel

/stand/vmunix, 58, 358boot file location, 58, 358rebuilding for swcopy, 23

kernel build, 320kernel fileset, 313kernel_build_cmd=, 322kernel_path=, 322key, 174

key values, ACL, 175keyword syntax, PSF, 206keywords

checkinstall script, details, 282checkremove script, details,

286configure script, details, 284postinstall script, details, 283postremove script, details, 287preinstall script, details, 283preremove script, details, 286unconfigure script, details, 285values, control scripts, 273verify script, details, 285

LLANG, 276language, environment variable,

276layout_version=, 323level

designation, swlist, 105of detail, swlist, 101to edit, swacl, 179

level=, 324level= default, 109, 119list

as input to other commands,101

depot, 112simple, 103verbose, 113

listinginteractive swlist, 116patches, 163permissions, 192software, 101

load phase, 42local host, 6

definition, 5local other ACL entries, 175locatable products, 70

locked software, 39log file messages, 325log_msgid=, 325logdetail=, 326logfile, 54

button, 50, 51dialog, 54dialog, swremove, 133swremove, 133too long, 353

logfile, audit, 72logfile, swpackage, 247logfile=, 326loglevel=, 327loops, symbolic link, 60

Mmaking tapes (existing depot),

260man command, 19managing multiple versions, 70managing patches, 149

committal, 164copying, 159default options, 152features, 152HP-UX 11.00 paradigm, 151introduction, 150listing, 163packaging, 166removal, 164rollback, 164updating patched software,

165verifying, 165

managing sessions, 44manpages, 19manual

conventions, xixintended audience, xixoverview, xixpages, 19

384 Index

Index

related documents, xxmark, 48

for copy, 46for install, 46for remove, 131

marked, 17Marked? flag, 46master copy, ACL template, 190mastering a depot to a CD-ROM,

261mastering, CD-ROMs or tapes, 8match_target option, 226match_target=, 327match_target= option, 47matching ACLs to users, 183matching algorithm, ACL, 183Match-What-Target-Has, 47max_agents=, 327media_capacity option, 259media_capacity=, 327media_type=, 328menubar, 16menus, pull-down, 16message area, 17, 49modifying default values, 33modifying the IPD, 140Motif resources, 18mount_all_filesystems=, 328mount_cmd=, 328mouse, clicking, 16multiple depots, 7multiple tapes, writing to, 259multiple version, 53multiple versions, 70

swconfig, 82swremove, 138

Multi-User mode, 1

Nnetwork

errors, 350problems (UNIX), 349

protocols, 351network requirements, 1network servers, 8network source, 8New Copy, 52New Install, 52nodes, definition, 5nslookup command, 348num_entries value, 347

Oobject list, 17object_group permissions, 174object_owner permissions, 174objects

patch software, 167objects, software, 10objects_to_register=, 328one_liner=, 328one_liner= default, 109, 119On-line Help, 18open item, 48opening and closing objects,

swremove, 131OpenView Software Distributor,

1operands

swask, 302operands, command, 31operands, swremove, 127operating system update, 58,

356option, 143option file option, -X, 78, 87options

and defaults, swask, 304and defaults, swconfig, 79, 89,

107, 146, 181and defaults, swremove, 128command, swask, 301command, swconfig, 77

command, swinstall/swcopy,28

command, swverify, 87editor dialog, 62menu, 46values, default, 33

options file, 310options, changing from the GUI/

TUI, 62OS update, 58, 322, 333, 356os_name=, 329os_release=, 329other permissions, 174overview, commands, 2overwriting files and directories,

59, 60

P-p option, 28, 77package_in_place option, 256package_in_place=, 330packaging

ACLs, 251CD-ROM, 261defaults, 249disk space analysis errors, 258failures, 352following symbolic links, 257in place, 256making tapes, 260overview, 197, 239patch software, 166permissions, 192registering depots, 250remote file systems, 262repackaging, 254revisions, 257security, 251writing to tapes, 259

packaging command, 241Packaging Specification File

(PSF)

Index

Index 385

and swmodify, 140, 144pair, host and depot path, 135partitioning filesets on multiple

tapes, 259patch

default options, 152operations, 155

patch filter, 153patch match target, 154patch one liner, 154patch save files, 154patch_commit=, 330patch_filter=, 330patch_match_target=, 330patch_one_liner=, 331patch_save_files=, 331patches, 315, 330

commit, 164committing, 164copying, 159cumulative, 150default options, 152explicit specification, 158features for managing, 152HP-UX 11.00 paradigm, 151installing, 155interactive installation, 160introduction, 150kernel and library files, 158listing, 163load order, 158managing, 149packaging, 166point, 150removal, 164rollback, 164superseding, 150updating, 165verifying, 165

permission, 174"a" (shorthand), 176ACL, 176any_other, 174

configuration, 193copying, 192definitions (ACL), 176group, 174host, 174installing, 193listing, 192object_group, 174object_owner, 174other, 174packaging, 192register, 194removal, 193swreg, 99to access software, 173to edit, swacl, 182user, 174verify, 193

permission specification, default,232

point patches, 150policy-setting, 33polling, 331polling interval, increasing, 351polling_interval option, 351polling_interval=, 331pop-up menu, 62postinstall script, 268

details, 283postremove script, 124, 271

details, 287preinstall script, 268

details, 283preremove script, 124, 270

details, 286prerequisite, 66, 230

definition, 66pre-specified selections, 28preview option, -p, 28, 77problem reporting, xxproduct, 10

ACL templates, 189ACL, sample, 188

ACLs, definition, 188control, ACL, 184description button, 51description, swremove, 133level, specifying (swlist), 109summary button, 51

product specification, 221Product Specification File (PSF),

323, 336product specification file, PSF,

203Product Summary, swremove,

133product_specification_file (PSF)

for swmodify, 140product_templates, 189products, 200Products Ready column, 51Projected Actions, 52

swremove, 133protected software, 8protected software, installing

example, 39protection, software object, 184protocol sequence, 312, 334PSF, 203

comment lines, 206creating, 203dependency class, 230depot class, 217directory mapping, 233example, 204example file specifications, 236example permission

specifications, 233explicit file specification, 234file class, 231fileset class, 226keyword value, 206keywords, 206patch example, 172product class, 221quotes, 206

386 Index

Index

recursive file specification, 237subproduct class, 225syntax, 206vendor class, 219

pull-down menus, 16, 44

R-r option, 28read permission, 176README, 106ready, 50

with errors, 50with warnings, 50

realm, 182reboot, system, 71reboot_cmd=, 331reconfigure=, 331reconfigure=true/false option, 82Recopy, 52recovering updated files, 40referenced bundle, 315register permissions, 194register_new_depot=, 332register_new_root=, 332registering depots, 93Reinstall, 52reinstall=, 332reinstall=true, 52reinstall_files=, 332reinstall_files_use_cksum=, 333remote

other ACL entries, 175remove

permissions, 193phases, 130process, monitoring, 134simple, 126window, 134

remove_empty_depot=, 333remove_obsolete_filesets=, 333remove_setup_cmd=, 333removing

patches, 164software, 123software from an alternate

root, 136software from depots, 135

repackaging software, 254replacing modified ACL, 194request script, 271, 288, 307

keyword, 273request scripts

examples, 306response file, 288running from swinstall or

swconfig, 306swask command, 299

required permissions.troubleshooting, 346

requisites, 314resolver command, 348response file, 288, 301Resume button, 56resume copy/install, 55retry_rpc=, 334re-using packages, 254revision attributes, 321roll back

patches, 164rollback, 40

patches, 164root

ACL, sample, 186ACLs, definition, 186directory, 24restricting access to, 361

RPC timeouts, 350rpc_binding_info option, 351rpc_binding_info=, 334rpc_timeout option, 350rpc_timeout=, 335Run Level requirements, 1

S-S option, 29, 77, 87-s option, 29SAM, adding a client, 61samples

ACLs for editing, 194copying, 27installation, 26

save session file option, -C, 29,77, 87, 95, 127, 144

save view as default, 45script

request, 273, 288, 307scripts

request, 271scripts, other, 271secrets

inter-host, 347matching, 347

securitydenied access, 346packaging, 251

select_local=, 335selecting software to remove,

131Selection Phase, 42selections syntax, 31Series 700 and 800 software,

coexisting on same depot, 7,44

server, definition, 5session

file, example, 45files, 14managing, 44

session file option, -S, 29, 77, 87setuid root, 251shareable files, 200shells, control script, 275show description of software, 48show software for selection, 43Single-User mode, 1Skipped, 53

Index

Index 387

softwaredependencies, 66objects, 10selection file option, -f, 29, 77,

87, 179selection files, 14source option, -s, 29source, definition, 5view, 46

Software Certificate, 8software compatibility, 312software configuration, 319Software Distributor

introduction, 1OpenView version, 1

software installation, 314software level, 324Software Selection Window, 43software view, 335software view default, 335software=, 335software_view=, 335Sort Dialog, 46source

adding a, 43depot path, 44designation, 26host name, 43network, 8

source_cdrom=, 335source_depot_audit=, 336source_file=, 336source_tape=, 336source_type=, 336Specify Source Dialog, 43states of versions, 91status column, 50

install or copy, 56sticky bit, 185structure

determining product, 200software, 200

structure, software product, 10

stty, using to determinecharacter mapping, 13

subproduct, 10level, specifying (swlist, 110

subproduct specification, 225subproducts, 200superseding patches, 150superuser

swpackage, 251supporting files

swgettools, 357SW_CONTROL_DIRECTORY,

277SW_DEFERRED_KERNBLD,

279SW_INITIAL_INSTALL, 279SW_KERNEL_PATH, 279SW_LOCATION, 277SW_PATH, 277SW_ROOT_DIRECTORY, 278SW_SYSTEM_FILE_PATH, 280swacl

command, 173-D option, 179-F option, 179-l option, 179-M option, 179overview, 2syntax, 178using, 182-v option, 179

swagent, 5swagentd

overview, 2swask, 299

command options, 301default options, 304examples, 300operands, 302syntax, 300

swconfigcommand, 74overview, 2

syntax, 76swcopy

overview, 3SW-DIST, 4

loading new version, 356reloading if corrupt, 4, 356

swgettoolsoptions, 359overview, 3supporting files, 357syntax, 359updating SD with, 356

swinstalloverview, 3

swlist-a (attribute) option, 104command, 102command options, 104-d option, 104examples, 121-i option, 104-l option, 105overview, 3piping to more, 102-R (shorthand) option, 104-r option, 104syntax, 102-v (verbose) option, 104

swlist -i, -i option, 116swlock file, 21swmodify

-a option, 143-C option, 144command, 140-d option, 143-f option, 144overview, 3-P option, 144-p option, 143-r option, 143-S option, 144-s option, 144syntax, 141

388 Index

Index

-u option, 143-V option, 143-X option, 145-x option, 145

swpackagelogfile, 247operands, 243options, 242overview, 4, 239syntax, 241

swregauthorization, 99command options, 95overview, 4syntax, 94

swremove-C option, 127-d option, 127, 135-f option, 127-i option, 127overview, 4-p option, 127-r option, 127-S option, 127syntax, 126-t option, 127-v option, 127-X option, 127-x option, 127

swverifycommand, 86-d option, 87overview, 4syntax, 86

symbolic linkloops, 60

symbolic links, 321file and directory, 59

symlinksswpackage, 257swremove, 124values, swverify, 92

syntax

swacl, 178swask, 300swconfig, 76swcopy, 25swgettools, 359swinstall, 25swlist, 102swmodify, 141swreg, 94swremove, 126

systemdefinition, 5development, 8

system_file_path=, 337system_prep_cmd=, 337

T-t option, 77, 87table of contents, 101tag attribute, always listed, 106tags, 20tape

changing, 56depot, 7

tape device, 319tape is ready response, 259tape, partitioning filesets on

multiple, 259tar archive, 7target

definition, 5selection file option, -t, 77, 87selection, swmodify, 145

Target Depot Path, swremove,135

target directory, 318target_type option, 242targets=, 337TCP/IP

protocol, 351templates

ACL, 179, 189

ACL default entries, 190Terminal User Interface (TUI),

2, 12, 15, 41terminate write-to-tape

command, 259test permission, 176testing

configuration scripts, 295installation scripts, 294removal scripts, 297

timeout, 335connection, 350resolving problems, 350

too-restrictive permissions, 261troubleshooting SD, 343typographical conventions, xix

U-u option

swconfig, 77swreg, 95

UDP communications, 351umask value, 232uname attributes, 20, 68uncompress_cmd=, 337uncompress_files=, 338unconfigure script, 124, 270

definition, 73details, 285

UNCONFIGURED state, 81unconfiguring

host, swremove, 124removed software, 123

UNIXRun Level, 1user mode, 1

unmark, 48unpostinstall script, 269unpreinstall script, 268unregistering depots, 93unusable state, 137update, 53

Index

Index 389

update, using swinstall to, 59updating

operating system, 58, 356patches, 165SD-UX, 356

use, software copied to depot notintended for, 23

use_alternate_source=, 338user aborted, 56user permissions, 174

Vswmodify

-v, 143-v option, swreg, 95VAB, xixvalues, default option, 33var/spool/sw, 7vendor specification, 219verbose

listings, samples, 114lists, 113option, -v, 29, 77, 87

verbose option, 242verbose=, 339verify

analysis phase, 91installations, 85operations, samples, 86patches, 165permissions, 193script, 270script, details, 285scripts, executing, 92software, 73

verify script, 316view menu, 45view preferences, changing, 17,

45viewing, audit log file, 72volatile, 316

WWAN connection timeouts, 350wildcard, 248wildcarding, partial, 237window

GUI components, 16Software Selection, 43swremove, 134

writable depot, 7write permission, 176write_remote_files option, 262write_remote_files=, 339write-to-tape, terminate, 259

X-x codeword=, 39-x customer_id=, 39-X option, 78, 87-x option, 30, 78, 87, 179XToolkit

-fn option, 18-font option, 18options, 17

390 Index

Index

Managing HP-UX Software With SD-UX - CiteSeerX

Documents

Transcript of Managing HP-UX Software With SD-UX - CiteSeerX