Software Distributor Administration Guide for HP-UX 11i HP Computers Manufacturing Part Number: B2355-90754 June 2002, Edition 3 © Copyright 2002 Hewlett-Packard Company.
Legal Notices The information in this document is subject to change without notice. Hewlett-Packard makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Hewlett-Packard shall not be held liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material.
This software is based in part on the Fourth Berkeley Software Distribution under license from the Regents of the University of California. copyright 1979, 1980, 1983, 1985-93 Regents of the University of California copyright 1986-2000 Sun Microsystems, Inc. copyright 1985-86, 1988 Massachusetts Institute of Technology copyright 1989-93 The Open Software Foundation, Inc. copyright 1986-1997 FTP Software, Inc.
MS-DOS and Microsoft are U.S. registered trademarks of Microsoft Corporation. NTRIGUE is a trademark of Insignia Solutions, Inc. NetMeeting is a registered trademark of Microsoft Corporation. Netscape is a registered trademark of Netscape Communications Corporation. OpenGL is a registered trademark of Silicon Graphics, Inc. OpenView is a registered trademark of the Hewlett-Packard Company. Oracle is a registered trademark of Oracle Corporation. Oracle8 is a trademark of Oracle Corporation.
This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). This product includes PHP, freely available from the PHP Group (http://www.php.net). Publication History The manual’s publication date and part number indicate its current edition. The publication date will change when a new edition is released. The manual part number will change when extensive changes are made. To ensure that you receive the new editions, you should subscribe to the appropriate product support service.
Please direct comments regarding this guide to: Hewlett-Packard Company HP-UX Learning Products 3404 East Harmony Road Fort Collins, Colorado 80528-9599 Or, use this web form to send us feedback: http://docs.hp.com/assistance/feedback.
Conventions We use the following typographical conventions. audit (5) An HP-UX manpage. audit is the name and 5 is the section in the HP-UX Reference. On the web and on the Instant Information CD, it may be a hot link to the manpage itself. From the HP-UX command line, enter “man audit” or “man 5 audit” to view the manpage. See man (1). Book Title The title of a book. On the web and on the Instant Information CD, it may be a hot link to the book itself. Emphasis Text that is emphasized.
Contents 1. Introduction to Software Distributor About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SD-UX Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SD-UX Programs and Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Installing from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation Tasks and Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Your Installation (swconfig) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Features and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Configuration Process . . . . . . . . . . .
Contents Copy Tasks and Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Registering and Unregistering Depots (swreg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Register Media or Create Network Depot? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Registration and Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authorization . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Patch File Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 PSF Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Attributes Generated by SD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 6. Remote Operations Overview Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Scheduling Jobs from the Command Line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Adding Job Titles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Removing Job Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 8. Reliability and Performance Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents ACL Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Object Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ACL Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security on SD-UX Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Creating a Product Specification File (PSF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Product Specification File Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PSF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packaging the Software (swpackage) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using swpackage. . . . . . . . . . . . . . . . . .
Contents Verify Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fix Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checkremove Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preremove Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents B. Troubleshooting Error Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents 18
Introduction to Software Distributor 1 Introduction to Software Distributor This chapter contains overview information and explains important concepts that will help you use the SD-UX commands most effectively.
Introduction to Software Distributor About This Guide About This Guide This guide describes how to use Software Distributor to install, configure, package, and manage software for HP-UX on HP 9000 systems This guide is written for: NOTE • Stand-alone HP-UX users, primarily concerned with quick and easy access to the right software management tools to get their normal work done. This may include software installation, viewing, or removal and basic depot management.
Introduction to Software Distributor About This Guide Related Documentation and Training Check the SD-UX web site often for announcements, updates to the SD-UX FAQ, and to download the latest version of SD-UX: http://software.hp.com/SD_AT_HP For additional information on topics covered in this guide: • SD-UX FAQ: http://software.hp.com/SD_AT_HP/faq.html • For details on SD-UX training included in HP-UX system administration classes: http://software.hp.
Introduction to Software Distributor SD-UX Overview SD-UX Overview Software Distributor for HP-UX (SD-UX) provides you with a powerful set of tools for centralized HP-UX software management. When connected by a LAN or WAN, each computer running SD-UX can act as a server, allowing its resources to be managed or accessed by other machines, or as a client, managing or using the resources of other machines.
Introduction to Software Distributor SD-UX Overview SD-UX Programs and Commands The following list provides a brief description of each command and references for more detailed information.
Introduction to Software Distributor SD-UX Overview Table 1-2 SD Commands (Continued) Command & Manpage swask (1M) 24 Description/Features • More Information Runs interactive request scripts that gather information for later use by swinstall or swconfig • Chapter 11, “Using Control Scripts,” on page 369 • “Requesting User Responses (swask)” on page 407 swacl (1M) • Specifies, lists, and changes Access Control Lists (ACLs) for SD security.
Introduction to Software Distributor SD-UX Overview Table 1-2 SD Commands (Continued) Command & Manpage swjob (1M) Description/Features • Monitors jobs from the command line • Requires that remote operations are enabled More Information • “Monitoring Jobs from the Command Line” on page 230 • Chapter 6, “Remote Operations Overview,” on page 189 • Chapter 7, “Using Jobs and the Job Browser,” on page 215 install-sd (1M) • Re-installs SD-UX from media • Appendix C, “Replacing or Updating SD-UX,
Introduction to Software Distributor SD-UX Overview SD-UX Online Documentation To view the a manpage for each command, type: man command_name For additional technical information, type: man 5 sd for SD-UX overview man 4 sd for file layouts man 4 swpackage for packaging file layouts 26 Chapter 1
Introduction to Software Distributor SD-UX Concepts SD-UX Concepts Understanding SD-UX concepts, terms, and model of software management will help you use the commands and programs most effectively. For additional definitions, see the Glossary. Important Terminology Host refers to any system on which software is to be installed or managed using the SD-UX commands. A local host is the system on which you invoke SD-UX commands.
Introduction to Software Distributor SD-UX Concepts A basic copy operation (using the swcopy command) is very similar, except that the target is a depot on the host, rather than the host itself. For most operations, controller programs access hosts and depots using an agent called swagent, which performs the basic software management tasks. The agent is accessed via a daemon called swagentd. When SD-UX operates on the local host, both controller and agent run on the local host.
Introduction to Software Distributor SD-UX Concepts OS software is packaged in bundles. Bundles can consist of groups of filesets or of products. Customer creation of bundles is not supported. Products Collections of filesets or (optionally) subproducts and control scripts. The SD-UX commands maintain a product focus but still allow you to specify subproducts and filesets.
Introduction to Software Distributor SD-UX Concepts Figure 1-2 Example of HP-UX Software Structure Bundle B Product A Subproduct X Fileset A1 Fileset A2 Fileset A3 Product B Fileset A4 Fileset B1 Fileset A5 Fileset B2 Fileset B3 Fileset A6 Installed Products Database SD-UX uses the Installed Products Database (IPD) to keeps track of what software is installed on a system.
Introduction to Software Distributor SD-UX Concepts Control Scripts Products and filesets can contain control scripts that perform checks and other tasks not performed by SD-UX commands. SD-UX supports the following types of scripts: Chapter 1 Checkinstall Analyzes each target to determine if the installation and configuration can take place. (Executed by swinstall.) Checkremove Analyzes each target to determine if removal and unconfiguration can take place. (Executed by swremove.
Introduction to Software Distributor SD-UX Concepts For More Information Preremove Performs additional file operations (such as removing files created by a preinstall script) immediately before removal of software files. (Executed by swremove.) Request Requests an interactive response from the user as part of the installation or configuration process. (Executed by swask, swconfig, and swinstall.) Unconfigure Undoes configurations performed by configure scripts. (Executed by swconfig and swremove.
Introduction to Software Distributor SD-UX Concepts Software Dependencies Software that depends on other software to install or run correctly is considered to have a dependency. When you specify software for the swconfig, swcopy, swinstall, swremove, swverify commands, these commands may automatically select additional software to meet dependencies. How Commands and Options Interact with Dependencies Command options let you control how software dependencies are handled.
Introduction to Software Distributor SD-UX Concepts If you select software that has a dependency and more than one available object resolves that dependency, SD-UX automatically selects the latest compatible version. Types of Dependencies Software packagers can define corequisites, prerequisites, and exrequisites as dependencies. These dependencies can be specified between filesets within a product, including expressions of which versions of the fileset meet the dependency.
Introduction to Software Distributor Using the GUI and TUI Commands Using the GUI and TUI Commands The swinstall, swcopy, swlist, swremove commands each provide a Graphical User Interface and Terminal User Interface. Advantages of the GUI/TUI include: • You can quickly create and visually monitor software management tasks interactively • You can easily analyze the effects of tasks and retry tasks that fail.
Introduction to Software Distributor Using the GUI and TUI Commands NOTE All examples for GUI commands in this manual also apply to the TUI. Starting the GUI/TUI Commands To start the GUI or TUI for swinstall, swcopy, or swremove, enter: /usr/sbin/swinstall —or— /usr/sbin/swcopy —or— /usr/sbin/swremove TIP Put /usr/sbin in your PATH to avoid typing the /usr/sbin prefix. The TUI starts by default if you have not set the DISPLAY variable.
Introduction to Software Distributor Using the GUI and TUI Commands Window Components The main GUI/TUI windows (Figure 1-4, “GUI Window Components,”) contain the following components: Figure 1-4 GUI Window Components Menu bar Message area View/selections Columns/ headings Object list Menu bar Provides pull-down menus for File, View, Options, Actions, and Help. Each choice has additional submenus for more activities.
Introduction to Software Distributor Using the GUI and TUI Commands Opening and closing items in the object list The Software Selection window object list is hierarchical: you can open each object in the list and show its contents. Objects in the list that contain other objects that can be opened have an arrow (→) after the name. • To open a subproduct, double click on it, or highlight the name and then select Actions→Open Item.
Introduction to Software Distributor Using the GUI and TUI Commands Preselecting Host Files The defaults.hosts file contains lists of hosts that are used by the GUI/TUI programs. This lets you use preselected choices for source and target systems. These lists are stored in the $HOME/.swdefaults.hosts or /var/adm/defaults.hosts files. For each interactive command, target hosts containing roots or depots are specified in this file by separate lists (hosts, hosts_with_depots).
Introduction to Software Distributor Using the GUI and TUI Commands Software Selection Window The Software Selection Window (Figure 1-5, “Software Selection Window,”) is the standard window for all SD-UX GUI programs. It features the standard menu bar, message area, and object list of software available for selection. Menu items are discussed in the following sections.
Introduction to Software Distributor Using the GUI and TUI Commands Session and File Management—The File Menu The File menu is the primary tool for managing session files, searching, and printing. GUI Session Files Each invocation of one of the GUI commands defines a session. All session information—including the options used to invoke the command, source specifications, software selections, and target hosts—are automatically saved.
Introduction to Software Distributor Using the GUI and TUI Commands Changing Software Views—The View Menu The View menu manages your window view preferences. Columns… The View→Columns... choice brings up the Column Editor dialog (Figure 1-6, “Column Editor,”), which lets you reformat the columns for the current object list. All viewable object attributes are listed.
Introduction to Software Distributor Using the GUI and TUI Commands • To return to the original default values, select System Defaults. • To cancel any changes and return to the object list window, select Cancel. • To save the changes made for the next invocation of the application, choose View→Save View as Default. Filter… Figure 1-7 Filter Dialog The View→Filter...
Introduction to Software Distributor Using the GUI and TUI Commands Table 1-3 44 Operator Types Any Displays objects regardless of the value of the attribute. Matches Displays objects if their attribute value exactly matches the value specified in the Value column. Not Displays objects whose attribute value does not match the value specified in the Value column. Less Than Displays objects if their attribute value is less than the value specified in the Value column.
Introduction to Software Distributor Using the GUI and TUI Commands Sort… The View→Sort... choice displays the Sort dialog (Figure 1-8, “Sort Dialog,”), which lets you specify a sort method for the object list. All viewable object attributes are listed. For each attribute, you can specify the type of sort desired. Figure 1-8 Sort Dialog The Priority column displays values 1 through the total number of attributes, plus an Ignore option, which excludes the attribute from the sort.
Introduction to Software Distributor Using the GUI and TUI Commands Save View as Default To save any changes for future sessions, choose View→Save View as Default. Any changes you made to your view preferences are saved in the following file, in which username is your log-in name: /var/adm/sw/ui/preferences/username.prefs.
Introduction to Software Distributor Using the GUI and TUI Commands NOTE Chapter 1 Use caution when changing option values. They allow useful flexibility but can produce harmful results if changed to an inappropriate value. Use the online help and consult Appendix A, “Command Options,” on page 421 to understand fully each option before you change it.
Introduction to Software Distributor Using the GUI and TUI Commands Performing Actions—The Actions Menu Each Action menu in the GUI/TUI programs has series of actions for that command. These actions vary according to which command you invoke. (You may have to click on an item in the object list to enable some of the actions that are grayed out.) The following actions are common to swinstall, swcopy, swlist, and swremove.
Introduction to Software Distributor Using the GUI and TUI Commands Add/Save Software Group These choices let you save and re-use groups of marked software. The Save Software Group menu choice opens the Save Software Group dialog (Figure 1-10, “Save Software Group Dialog,”), which saves the current list of marked software as a group. SD stores the group definition in $HOME/.sw/software/ or a directory you specify.
Introduction to Software Distributor Using the GUI and TUI Commands Change Source The Change Source... menu choice opens the Change Source dialog (Figure 1-11, “Change Source Dialog,”), which lets you change the source for the software to be used. The Root Path button opens a list of target paths from which to select (Figure 1-13, “Root Path Dialog,”). Figure 1-11 Change Source Dialog 1. (Optional) To specify another host system, type a source host name, or: a. Click on the Source Host Name button.
Introduction to Software Distributor Using the GUI and TUI Commands Change Target The Change Target... menu choice opens the Change Target dialog (Figure 1-12, “Change Target Dialog,”), which lets you change the targets of your software operation. The Root Path button opens a list of target paths from which to select (Figure 1-13, “Root Path Dialog,”). For SD-UX local operations, the target is always a directory on the local host.
Introduction to Software Distributor Using the GUI and TUI Commands Getting Help—The Help Menu All the GUI and TUI programs have an on-line help system. Each screen, dialog, or menu choice has associated help instructions that explain the activity. Figure 1-14 Typical On-Line Help Screen To get “context-sensitive” help for individual menu choices, fields, options, or buttons on the various windows and menus, place the cursor on an item and press the F1 key on your keyboard (Ctrl-F in the TUI).
Introduction to Software Distributor Using the GUI and TUI Commands Overview… This menu item provides information about the currently active SD-UX screen. This includes a list of the tasks you can do in that screen and a short description of the different areas of the screen and links to related topics. Keyboard… This menu item brings up help on how to use the keyboard to control the application, covering topics such as selection, menu bar activation and traversal, dialog box traversal, etc.
Introduction to Software Distributor Using the GUI and TUI Commands *userFont Specifies the fixed-width font used in all other GUI displays. This font should be the same basic size as the *systemFont only in the fixed width style. The default size is also 8x13.
Introduction to Software Distributor Working from the Command Line Working from the Command Line You can invoke all SD-UX commands non-interactively via the command line. This section provides reference information about command-line features available across most of the commands.
Introduction to Software Distributor Working from the Command Line Software Selections Software selections let you specify software in great detail. You can also use an input file to specify software. Syntax The software_selections syntax is identical for all SD-UX commands that require it: bundle[.product[.subproduct][.fileset]][,version] product[.subproduct][.
Introduction to Software Distributor Working from the Command Line The version component has the form: [,r revision][,a arch][,v vendor] [,c category][,q=qualifier][,l=location] [,fr revision][,fa arch] where: • Fully qualified software specifications include the r=, a=, and v= version components, even if they contain empty strings. For installed software, l= is also required. • All version components are repeatable within a single specification (e.g. r>=A.12, r
Introduction to Software Distributor Working from the Command Line Software Files To keep the command line shorter, software selection input files let you specify long lists of software products. With a software selection file, you only have to specify the single file name. The -f command-line option lets you specify a software selection file.
Introduction to Software Distributor Working from the Command Line Target Files To keep the command line shorter, target selection input files let you specify long lists of targets. With a target selection file, you only have to specify the single file name. The -t command-line option lets you specify a target file.
Introduction to Software Distributor Working from the Command Line The template file lists (as comments): • All command options • The commands to which each option applies • Possible values for each option • The resulting system behavior for each value. You can copy values from this file into the system defaults file (/var/adm/sw/defaults), your personal defaults file ($HOME/.swdefaults), or an input file (with the -X input_file option) and edit them to affect SD-UX behavior.
Introduction to Software Distributor Working from the Command Line To start an interactive swinstall session using the options stored in my_install_defaults to override any system-wide or personal defaults file values: swinstall -i -X my_install_defaults=true To start an interactive install session and reset the use_alternate_source default for this session only: swinstall -i -x use_alternate_source See Appendix A, “Command Options,” on page 421 for a complete listing of defaults and their values and descri
Introduction to Software Distributor Working from the Command Line Note that when you re-execute a session file, the session file values take precedence over values in the system defaults file or personal defaults file. Likewise, any command line options or parameters that you specify when you invoke the command take precedence over the values in the session file. Here is a sample a session file. It uses the same syntax as the defaults files: # swinstall session file # # Filename /users/fred/.
Installing Software 2 Installing Software This chapter discusses how to use the swinstall, swconfig, and swverify commands to install, configure, and verify software. Table 2-1 • swinstall installs software from a depot and performs automatic configuration of software. • swconfig lets you configure, unconfigure, or reconfigure previously installed software.
Installing Software Installation with swinstall Installation with swinstall The swinstall command installs software from a software source (a depot or physical media) to your local host. Features and Limitations • Optional GUI. • Compatibility filtering to ensure the software will run on the installed system. • Ability to perform kernel rebuilding or rebooting. • Automatic use of dependencies to automatically select software on which to operate (in addition to any software you specify directly).
Installing Software Installation with swinstall Installing with the GUI Overview This section provides an overview of the swinstall GUI. • In general, all information presented in “Installing from the Command Line” on page 73 also applies to the swinstall GUI. • This section also refers to additional information about standard GUI elements, discussed in “Using the GUI and TUI Commands” on page 35. • All information in this section also applies to the TUI program unless otherwise noted.
Installing Software Installation with swinstall The Software Selection window appears with the Specify Source dialog superimposed over it. Step II: Select Source In this step, you must specify the source depot that contains the software you want to install. The Specify Source dialog (Figure 2-1, “Specify Source Dialog,”) automatically lists the local host and default depot path. (This step is skipped if you include the -s source option when you invoke the GUI.) Figure 2-1 Specify Source Dialog 1.
Installing Software Installation with swinstall Step III: Select Software In this step, you use the Software Selection window to select the software you want to install. Figure 2-2 swinstall Software Selection Window 1. Select software from the object list: a. Highlight an item b. Select Actions→Mark For Install — or — Right-click to display the pop-up, then select Mark For Install The Marked? flag in the object list changes to Yes to match your selection.
Installing Software Installation with swinstall 2. (Optional) Use choices from the Actions menu: • Match What Target Has examines your current Installed Product Database to match your existing filesets with new filesets (those with the same names) that you are going to install. This feature is most helpful when you are updating a system to newer versions of the same software. This option can be set from the Options Editor.
Installing Software Installation with swinstall Step IV: Analysis (Preview) In this step, SD-UX analyzes the software you have selected. The Analysis window displays status information about the analysis process. When the analysis is complete and the host status shows Ready, click OK to start the actual installation (see “Step V: Installation” on page 72). The Analysis dialog is then replaced by the Install dialog. If you started a preview session, the install stops after the analysis.
Installing Software Installation with swinstall Menu choices in this window let you: — Search the object list. — Open items to look at the projected size requirements for specific filesets. • Figure 2-4 70 Re-analyze repeats the analysis process.
Installing Software Installation with swinstall When Analysis completes, the status for any host displays as either Ready or Excluded from task. If any of the selected software can be installed onto the host, the status shows Ready. If none of the selected software can be installed onto the host, the status shows Excluded from task. The following list summarizes the status results. You can find details about most problems by clicking the Logfile button.
Installing Software Installation with swinstall Step V: Installation In this step, SD-UX proceeds with the actual installation. After you click OK in the Analysis window, SD-UX starts installation and displays the Install Window, which shows status information. Figure 2-5 Install Window These action buttons are available: • Done returns you to the Software Selection Window. You can then begin another install or exit the GUI (File→Exit).
Installing Software Installation with swinstall Installing from the Command Line Swinstall syntax The syntax for swinstall is: swinstall [XToolkit Options] [-i] [-p] [-r] [-v] [-ccatalog] [-C session_file] [-f software_file] [-Q date] [-s source] [-S session_file] [-t target_file] [-x option=value] [-X option_file] [software_selections] [@ target_selections] Options and Operands XToolkit Options X window options for the GUI. See “XToolkit Options and Changing Display Fonts” on page 53.
Installing Software Installation with swinstall host may be a host name, domain name, or internet address (for example, 15.1.48.23). directory is an absolute path. -S session_file Use option and operand values saved from a previous installation session and stored in session_file. See “Session Files” on page 61. -t target_file Read target selections from a target_file instead of (or in addition to) targets you specify on the command line. See “Target Files” on page 59.
Installing Software Installation with swinstall Table 2-3 swinstall Command Options and Default Values • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Chapter 2 admin_directory=/var/adm/sw agent_auto_exit=true agent_timeout_minutes=10000 allow_downdate=false allow_incompatible=false allow_multiple_versions=false allow_split_patches=false ask=false autoreboot=false autorecover_product=false autoremove_job=false autoselect_dependencies=true autoselect_patches=true autoselect_reference_bu
Installing Software Installation with swinstall For More Information See Appendix A, “Command Options,” on page 421 for more information about setting options and a complete listing and description of each option. Installation Tasks and Examples This section provides examples of commands for installing software products. Note that The \* is an optional shorthand wildcard meaning “all products and filesets or all available software.
Installing Software Installation with swinstall • To update HP Omniback software (already installed in the default directory on the local host) with a newer version from a CD-ROM mounted at /mnt/cd: swinstall -s /mnt/cd Omniback Updating to HP-UX 11i For complete instructions for updating from a previous HP-UX release to HP-UX 11i, use the new update-ux command, as explained in Chapter 2 of HP-UX 11i Installation and Update Guide.
Installing Software Installation with swinstall CAUTION Most HP-UX products have preinstall and postinstall scripts without accompanying undo scripts. This negates any advantage of using the autorecover_products option. Use autorecover_products only with software that has the associated undo scripts.) Installing Software That Requires a System Reboot Software packaged with the is_reboot attribute set to true requires the host to be rebooted after the software is installed.
Installing Software Installation with swinstall SD-UX prompts you for these codewords or numbers prior to the installation of protected software. You can enter or change the numbers via the GUI using the Add New Codeword choice from the Actions menu in the GUI, or by using the appropriate default option (-x codeword=xxxx and -x customer_id=xxx) on the command line.
Installing Software Installation with swinstall Once multiple versions of software are installed into a location, you can manage them by specifying the product attribute in the software specification of SD-UX commands. (This is as opposed to specifying other version attributes such as revision and architecture). This lets you install old and new versions of software at the same time and configure both versions (if the software packaging supports it).
Installing Software Installation with swinstall NOTE HP strongly advises that you do not install software that is incompatible unless you are advised to do so by your HP Support representative. Table 2-4 Product Compatibility Product value (Pattern to match) Product attribute Target Root attribute machine_type ia64* IA uname -m machine_type 9000/* IA or PA uname -m os_name HP-UX HP-UX uname -s os_release ?.11.* B.11.
Installing Software Configuring Your Installation (swconfig) Configuring Your Installation (swconfig) The swconfig command runs configuration scripts. Although swinstall and swremove automatically run configuration or unconfiguration scripts, swconfig lets you work independently of these commands. This lets you: • Execute scripts to address problems if a configuration fails, is deferred, or must be changed.
Installing Software Configuring Your Installation (swconfig) NOTE • Automatic configuration can also be postponed on software installed to the root directory, / (for example, when multiple versions are installed), by using the defer_configure command option with swinstall or swremove. • By default, swconfig only supports configuration of compatible software. You can switch this feature on or off with the allow_incompatible option.
Installing Software Configuring Your Installation (swconfig) Analysis takes place on the local host. The configuration phase will not take place if any errors occur during analysis. Errors in the analysis phase will only exclude those products that had errors in them. If only warnings occur, the task continues. The sequential analysis tasks on the host are: 1. Initiate analysis. 2. Process software selections: Get information from the Installed Product Database and check for compatibility.
Installing Software Configuring Your Installation (swconfig) Phase III: Configuration • If the dependency is a prerequisite, the configuration fails. • If the dependency is a corequisite, the configuration of this fileset will likely succeed, but the product may not be usable until its corequisite dependency is installed and configured. In this phase, the actual software configuration takes place.
Installing Software Configuring Your Installation (swconfig) Using swconfig Syntax swconfig [-p] [-u] [-v] [-c catalog] [-C session_file] [-f software_file] [-Q date] [-S session_file] [-t target_file] [-x option=value] [-X option_file] [software_selections] [@ target_selections] Options and Operands -p Preview a configuration task by running it through the Analysis Phase and then exiting. -u Unconfigure the software instead of configuring it.
Installing Software Configuring Your Installation (swconfig) -x option=value Sets a command option to value and overrides default values or a values in options files. See “Changing Command Options” on page 87. -X option_file Read session options and behaviors from option_file. See “Changing Command Options” on page 87. software_selections The software objects to be configured. See “Software Selections” on page 56. target_selections The target of the command. See “Target Selections” on page 58.
Installing Software Configuring Your Installation (swconfig) For More Information See Appendix A, “Command Options,” on page 421 for more information about setting options and a complete listing and description of each option.
Installing Software Verifying Your Installation (swverify) Verifying Your Installation (swverify) The swverify command verifies depot, installed, or configured software products on the specified host. Features and Limitations • Determines whether installed or configured software is compatible with the host on which that software is installed. • Makes sure that all dependencies (prerequisites, corequisites) are being met (for installed software) or can be met (for copied software).
Installing Software Verifying Your Installation (swverify) The Verification Process The software verification process has only two phases: selection and analysis. Phase I: Selection This phase consist of swverify resolving all information on the command line, including all necessary host, software, dependency, and product information. Phase II: Analysis The analysis phase for swverify takes place on the host. The host’s environment is not modified. The sequential analysis tasks on each host are: 1.
Installing Software Verifying Your Installation (swverify) • If enforce_dependencies is false, a warning is issued with the same information. • If the dependency is a corequisite, it must be present before the software will operate. • If the dependency is a prerequisite, it must be present before the software can be installed or configured. 5. Execute verify or fix scripts on installed software in prerequisite order. A verify script is used to ensure that the configuration of the software is correct.
Installing Software Verifying Your Installation (swverify) Using swverify Syntax swverify [-d|-r] [-F][-v] [-C session_file] [-f software_file] [-Q date] [-S session_file] [-t target_file] [-x option=value] [-X option_file] [software_selections][@ target_selections] Options & Operands -d Operate on a depot rather than installed software. See “Verifying a Depot (swverify -d)” on page 161 -r Operate on an alternate root rather than /. Verify scripts are not run.
Installing Software Verifying Your Installation (swverify) -X option_file Read session options and behaviors from option_file. See “Changing Command Options” on page 93. software_selections The software objects to be verified. See “Software Selections” on page 56. target_selections The target of the command. See “Target Selections” on page 58.
Installing Software Verifying Your Installation (swverify) Verification Tasks and Examples To verify an installed fileset mysoft.myfileset located on the default depot at myhosts, type: swverify -d mysoft.myfileset @ myhosts (The @ sign and the myhost target designation are optional because the software being verified located in the default depot on the local host.
Managing Installed Software 3 Managing Installed Software This chapter presents an overview of managing non-depot software after you have installed it.
Managing Installed Software Listing Your Software (swlist) Listing Your Software (swlist) The swlist command creates customizable listings of the software products installed on your local host or stored in depots for later distribution. swlist Features and Limitations With swlist you can: 96 • Use an optional GUI. • Specify the level (bundles, products, subproducts, filesets or files) to show in your list. • Specify a set of software attributes to display for each level.
Managing Installed Software Listing Your Software (swlist) Using the swlist GUI The swlist -i command starts a swlist GUI program that lets you interactively list software and display software information. The swlist -i -d command lets you display information about the software available in a depot or on a physical media. Figure 3-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.
Managing Installed Software Listing Your Software (swlist) Changing the View Use the View menu to change the columns displayed, select filters, and sort information: • Columns displays the Columns Editor. You can choose which columns of software information to display (i.e. software name, revision number, information, size in Kbytes, architecture, category, etc.) and their order. • Filter...
Managing Installed Software Listing Your Software (swlist) Using the Command Line Syntax swlist [-d|-r]] [-i] [-R] [-v] [-a attribute] [-c catalog] [-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] Options and Operands -d List products available from a depot. See “Listing the Contents of a Depot (swlist -d)” on page 159. -i Start the GUI. (See “Using the swlist GUI” on page 97.
Managing Installed Software Listing Your Software (swlist) -f software_file Read a list of software selections from a separate file instead of (or in addition to) the command line. See “Software Files” on page 58. List all software objects down to the specified level: depot, bundle, product, subproduct, fileset or file. (See the section “Listing Software by Levels” on page 107 for more information on levels.) You can use only one level designation per command.
Managing Installed Software Listing Your Software (swlist) -s source Specify which software source is to be listed. The default source type is a directory or depot (usually /var/spool/sw) on the local host. 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 an absolute path. -S session_file Run the command based on values saved from a previous installation session, as defined in session_file.
Managing Installed Software Listing Your Software (swlist) Changing You can change the behavior of this command by specifying additional Command Options command-line options when you invoke the command (using the -x option) or by reading predefined values from a file. The following table shows the defaults and options that apply to swinstall.
Managing Installed Software Listing Your Software (swlist) Software Listing Tasks and Examples To 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 your local 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.
Managing Installed Software Listing Your Software (swlist) This produces the following output AUDIT 3.5 9834 Trusted Systems Auditing Utils COMMANDS 1.7 4509 Core Command Set C-LANG 2.5 5678 C Programming Language NETWORKING 2.1 9072 Network Software KERNEL 1.4 56908 Kernel Libraries and Headers VUE 1.3 5489 Vue (Instant Ignition Release) WINDOWS 2.
Managing Installed Software Listing Your Software (swlist) ******************** * Hardware Support * ******************** The HP 9000 Model XXX is no longer supported. ... • List the products stored in the software depot on host1 located at /swmedia. For this example assume the swlist one_liner is: “title size architecture”: swlist -d @ host1:/swmedia FRAME FRAME ME30 SOFTBENCH TEAMWORK Frame Doc. Pkg 2319 Frame Doc. Pkg 2458 3-D Mech.
Managing Installed Software Listing Your Software (swlist) Listing Attributes You may specify only one attribute per -a option. However, the tag attribute is always included by default, so specifying -a revision lists all product names and their revision numbers.
Managing Installed Software Listing Your Software (swlist) 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 host2 would be as follows: swlist C-LANG @ host2 C-LANG.C-COMPILE 8.0 C-LANG.C-LIBS 8.0 C-LANG.C-MAN 8.0 1346 2356 1976 C Compiler Components Runtime Libraries Programming Reference Listing Patches You can use swlist to list software patches and their status.
Managing Installed Software Listing Your Software (swlist) Table 3-4 The -l Options (Continued) Option Action swlist -l subproduct Shows products and subproducts swlist -l fileset Shows products, subproducts and filesets swlist -l file Shows products, subproducts, filesets, files and numbers (used in software licensing). swlist -l category Shows all categories of available patches for patches that have included category objects in their definition. swlist -l patch Shows all applied patches.
Managing Installed Software Listing Your Software (swlist) For example, if you wanted to see all the products installed on your local host, your command would be: swlist -l product and the listing would look like this: NETWORKING SAM OPENVIEW PRODUCT A SOFTWARE Z PRODUCT B . . . Note that the product names are uncommented because that was the level you requested to display and there are no levels above.
Managing Installed Software Listing Your Software (swlist) Specifying Fileset Level An example of using the -l option to generate a listing that includes all filesets for the product NETWORKING on the local host and a descriptive title for each: swlist -l fileset -a title NETWORKING # NETWORKING NETWORKING.ARPA-INC NETWORKING.ARPA-RUN NETWORKING.ARPA-MAN NETWORKING.LANLINK NETWORKING.NFS-INC NETWORKING.NFS-RUN NETWORKING.
Managing Installed Software Listing Your Software (swlist) Note that the commented lines represent the requested level (NETWORKING.ARPA) plus one level up (fileset) from the specified file level (NETWORKING.ARPA_INC, NETWORKING.ARPA_RUN and NETWORKING.ARPA_RUN are all filesets). The uncommented lines are files. Depot Lists Another class of objects that swlist can display are depot lists. This allows you to list all the registered depots residing on a host.
Managing Installed Software Listing Your Software (swlist) vendor.information is_locatable architecture machine_type os_name target.os_release Hewlett-Packard Company true HP-UX_9000 9000 HP-UX 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 -v -l bundle. • To display all attributes for a product, use swlist -v -l product. • To display all attributes for products and subproducts, use swlist -v -l subproduct.
Managing Installed Software Listing Your Software (swlist) Table 3-6 Sample Attributes (Continued) Attribute Description 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 functiona
Managing Installed Software Listing Your Software (swlist) corequisite is_kernel file path type mode owner group uid gid mtime size file path type mode owner group uid gid mtime size ... NETWORKING.LANLINK true etc/freeze /etc/freeze f 0755 bin bin 2 2 721589735 24 etc/ftpd /etc/ftpd file 0555 bin bin 2 2 721589793 9 This command: swlist -v NETWORKING.ARPA-RUN produces the following listing: # NETWORKING.ARPA fileset tag ARPA-RUN instance_id 1 revision 1.
Managing Installed Software Modifying the IPD (swmodify) Modifying the IPD (swmodify) SD-UX keeps track of software installations, products, and filesets on your system with the Installed Products Database (IPD) for installed software and with catalog files for software in depots. Both the IPD and catalog files are created and constantly modified by other SD-UX operations (swinstall, swcopy, and swremove), they are not directly accessible if you want to change the information they contain.
Managing Installed Software Modifying the IPD (swmodify) 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” looks like: fileset tag ACCOUNTNG data_model_revision 2.4 instance_id 1 control_directory ACCOUNTNG size 292271 revision B.11.00 description Vendor Name: Hewlett-Packard Company Product Name: Accounting Fileset Name: ACCOUNTING Text: "HP-UX System Accounting feature set.
Managing Installed Software Modifying the IPD (swmodify) Using swmodify Syntax swmodify [-d] [-p] [-r] [-u] [-v [-V] [-a attribute=[value]] [-c catalog][-C session file] [-f software_file] [-P pathname_file] [-s product_specification_file] [-S session_file] [-x option=value][-X option_file] [software_selections] [@ target_selection] Options and Operands -d Perform modifications on a depot (not on a primary or alternate root). Your target_selection must be a depot.
Managing Installed Software Modifying the IPD (swmodify) You cannot use the -a option to change the following attributes: tag, revision, instance_id, vendor_tag, corequisite or prerequisite. -c catalog Writes full catalog structure information into the directory specified by catalog. All attributes down to the file level and control scripts are written. See “Requesting User Responses (swask)” on page 407.
Managing Installed Software Modifying the IPD (swmodify) -S session_file Run the command based on values saved from a previous installation session, as defined in session_file. See “Session Files” on page 61. -x option=value Sets a command option to value and overrides default values or a values in options files. See “Changing Command Options” on page 120. -X option_file Read session options and behaviors from option_file. See “Changing Command Options” on page 120.
Managing Installed Software Modifying the IPD (swmodify) Changing You can change the behavior of this command by specifying additional Command Options command-line options when you invoke the command (using the -x option) or by reading predefined values from a file. The following table shows the defaults and options that apply to swmodify.
Managing Installed Software Modifying the IPD (swmodify) To change the values of a fileset’s attributes: swmodify -a state=installed PRODUCT.FILESET To change the attributes of a depot: swmodify -a title=Master Depot \ -a description=/tmp/mfg.description \ @ /mfg/master_depot Defining New Objects You can import an existing application (not installed by SD-UX) by constructing a simple Product Specification File (PSF) describing the product and then invoke swmodify to load that definition into the IPD.
Managing Installed Software Removing Installed Software (swremove) Removing Installed Software (swremove) The swremove command removes software that has been installed on a host. Before its removal, the software is first unconfigured. swremove also removes software products that have been copied to a software depot. swremove Features and Limitations • Removes files from the specified location. It removes symbolic links, but not the targets of symbolic links.
Managing Installed Software Removing Installed Software (swremove) Using the swremove GUI This section provides an overview of the swremove GUI. • In general, all information presented in “Removing Installed Software (swremove)” on page 122 also applies to the swinstall GUI. • This section refers to additional information about standard GUI elements, discussed in “Using the GUI and TUI Commands” on page 35. • All information in this section also applies to the TUI program unless otherwise noted.
Managing Installed Software Removing Installed Software (swremove) Step II: Selecting Software In this step, you use the Software Selection window to select the software you want to install. Figure 3-2 swremove Software Selection Window 1. Select software from the object list: a. Highlight an item b. Select Actions→Mark For Remove — or — Right-click to display the pop-up, then select Mark For Remove The Marked? flag in the object list changes to Yes to match your selection.
Managing Installed Software Removing Installed Software (swremove) 2. (Optional) Use choices from the Actions menu to make additional software selections: • Change Target lets you select an alternate root from which to remove software. • Add Software Group lets you recall and re-use a group of previously saved software selections. • Save Software Group saves the current list of marked software as a group. SD stores the group definition in $HOME/.sw/software/ or a directory you specify.
Managing Installed Software Removing Installed Software (swremove) After analysis, if any of the selected software can be removed, the status indicates Ready or Ready with Warnings. If none of the selected software can be removed, the status indicates Excluded from task. The Products Scheduled column shows the number of products ready for removal out of all products selected.
Managing Installed Software Removing Installed Software (swremove) Step IV: Removal In this step, SD-UX proceeds with the actual removal. After you click OK in the Analysis window, SD-UX starts removal and displays the Remove Window (Figure 3-4, “Remove Window,”), which shows status information. These action buttons are available: • Done returns you to the Software Selection Window. You can then begin another removal or exit the GUI (File→Exit).
Managing Installed Software Removing Installed Software (swremove) Removing with the Command Line Syntax swremove [XToolkit Option] [-d|-r] [-i] [-p] [-v] [-C session_file] [-f software_file] [-Q date] [-s source] [-S session_file] [-t target_file] [-x option=value] [-X option_file] [software_selections] [@ target_selections] Options and Operands XToolkit Options X window options for the GUI. See “XToolkit Options and Changing Display Fonts” on page 53.
Managing Installed Software Removing Installed Software (swremove) -t target_file Read a list of target selections from a separate file instead of (or in addition to) the command line. See “Target Files” on page 59. -x option=value Sets a command option to value and overrides default values or a values in options files. See “Changing Command Options” on page 130. -X option_file Read session options and behaviors from option_file. See “Changing Command Options” on page 130.
Managing Installed Software Removing Installed Software (swremove) Changing You can change the behavior of this command by specifying additional Command Options command-line options when you invoke the command (using the -x option) or by reading predefined values from a file. The following table shows the defaults and options that apply to swremove.
Managing Installed Software Removing Installed Software (swremove) 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 Removing Bundles Removing a bundle does not always remove all filesets in that bundle. Because of SD-UX’s dependency management features, a fileset that is required by another bundle will not be removed. For example, if the bundles Pascal and FORTRAN both use the fileset Debugger.
Managing Installed Software Removing Installed Software (swremove) You can select more than one version of a product during the selection phase. During analysis, a warning is generated if the version of the product exists on the target but at a different location. If the product exists on the target, it will be removed. If it does not exist on the target, the product is simply skipped. The Product Summary...
Managing Software Depots 4 Managing Software Depots SD-UX uses software that is packaged and stored in a registered depot. This chapter discusses copying, listing, registering, removing, and verifying depot software.
Managing Software Depots Depot Management Commands and Concepts Depot Management Commands and Concepts The following commands will help you perform depot management tasks: Table 4-2 Commands for Depot Management Depot Task Copy Create List swcopy swcopy, swpackage swlist -d More Information/Examples • “Copying Software Depots” on page 137 • “Combining Patch Depots” on page 155 • Chapter 10, “Creating Software Packages,” on page 301 • “Creating a Tape Depot for Distribution” on page 156 • “L
Managing Software Depots Depot Management Commands and Concepts Depot Concepts A depot is a special type of directory formatted for use by SD-UX commands, and used to contain software products. You can create a depot by using swcopy to copy software directly from physical media or by using swpackage to make a software package containing the depot.
Managing Software Depots Depot Management Commands and Concepts Tape Depot • Tape (serial) depots offer advantages when you must copy or install software over slow or unreliable network connections, including the web. (First copy the depot to a local host, then install from the local depot.) • Software in a tape depot is formatted as a tar archive. • Depots for actual cartridge, DAT and 9-track tape are referred to by the path to the tape drive’s device file. For example: /dev/rmt/0m.
Managing Software Depots Copying Software Depots Copying Software Depots The swcopy command copies software between depots. Software that is copied into a depot cannot be used directly; it is placed there only to act as a source for installation and other SD-UX operations. swcopy Features and Limitations Chapter 4 • swcopy does not perform compatibility checking. • swcopy does not run control scripts.
Managing Software Depots Copying Software Depots Using the swcopy GUI Overview This section provides an overview of the swcopy GUI. • In general, all information presented in “Using the swcopy Command Line” on page 147 also applies to the swcopy GUI. • This section also refers to information about standard GUI elements discussed in “Using the GUI and TUI Commands” on page 35. • All information in this section also applies to the TUI program unless otherwise noted.
Managing Software Depots Copying Software Depots Step II: Specify Target In this step, you specify the target to which SD-UX will copy the software. (This step is skipped if you include the -t target option when you invoke the GUI. See “Using the swcopy Command Line” on page 147.) The Select Target Depot Path dialog displays the default target depot. Since this matches the default source depot path, you must select a new target: Figure 4-1 Select Target Depot Path Dialog 1.
Managing Software Depots Copying Software Depots Step III: Specify Source In this step, you must specify the source depot that contains the software you want to copy. The Specify Source dialog (Figure 4-2, “Specify Source Dialog,”) automatically lists the local host and default depot path. (This step is skipped if you include the -s source option when you invoke the GUI. See “Using the swcopy Command Line” on page 147.) Figure 4-2 Specify Source Dialog 1.
Managing Software Depots Copying Software Depots Step IV: Select Software In this step, you use the Software Selection window (Figure 4-3, “Software Selection Window,”) to select the software you want to copy. Figure 4-3 Software Selection Window 1. Select software from the object list: a. Highlight an item b. Select Actions→Mark For Copy — or — Right-click to display the pop-up, then select Mark For Copy The Marked? flag in the object list changes to Yes to match your selection.
Managing Software Depots Copying Software Depots 2. (Optional) Use additional choices from the Actions menu: • • Add Software Group displays a list of previously saved software group files or lets you specify a directory. Selecting a file adds the software selections in the file to any selections you have already made in the Software Selection window. Save Software Group lets you save your current list of marked software as a group.
Managing Software Depots Copying Software Depots Step V: Analysis (Preview) In this step, SD-UX analyzes the software you have selected. The Analysis window displays status information about the analysis process. When the analysis is complete and the host status shows Ready, click OK to start the actual copy (see “Step VI: Copying” on page 146). The Analysis dialog is then replaced by the Copy dialog. If you started a preview session, the copy stops after the analysis.
Managing Software Depots Copying Software Depots Menu choices in this window let you: — Search the object list. — Open items to look at the projected size requirements for specific filesets. • Figure 4-5 144 Re-analyze repeats the analysis process.
Managing Software Depots Copying Software Depots When Analysis completes, the status for any host displays as either Ready or Excluded from task. If any of the selected software can be copied onto the host, the status shows Ready. If none of the selected software can be copied onto the host, the status shows Excluded from task. The following list summarizes the status results. You can find details about most problems by clicking the Logfile button. Ready There were no errors or warnings during analysis.
Managing Software Depots Copying Software Depots Step VI: Copying In this step, SD-UX proceeds with the actual copy. After you click OK in the Analysis window, SD-UX starts copying and displays the Copy Window (Figure 4-6, “Copy Window,”), which shows status information. Figure 4-6 Copy Window These action buttons are available: • Done returns you to the Software Selection Window. You can then begin another copy or exit the GUI (File→Exit).
Managing Software Depots Copying Software Depots Using the swcopy Command Line swcopy Syntax swcopy [XToolkit Options] [-i] [-p] [-v] [-C session_file] [-f software_file] [-Q date] [-s source] [-S session_file] [-x option=value] [-X option_file] [software_selections] [@ target_selections] Options and Operands XToolkit Options X window options for the GUI. See “XToolkit Options and Changing Display Fonts” on page 53. -i Run the GUI program. See “Using the swcopy GUI” on page 138.
Managing Software Depots Copying Software Depots -t target_file Read a list of target selections from a separate file instead of (or in addition to) the command line. See “Target Files” on page 59. -x option=value Sets a command option to value and overrides default values or a values in options files. See “Changing Command Options” on page 148. -X option_file Read session options and behaviors from option_file. See “Changing Command Options” on page 148.
Managing Software Depots Copying Software Depots Table 4-4 swcopy Command Options and Default Values • • • • • • • • • • • • • • • • • • • • • • • • • • For More Information Chapter 4 admin_directory=/var/adm/sw agent_auto_exit=true agent_timeout_minutes=1000 0 allow_split_patches=false autoremove_job=false autoselect_dependencies=true autoselect_patches=true autoselect_reference_bundles =true codeword= compress_files=false compress_index=false controller_source= create_target_path=true customer_id= di
Managing Software Depots Copying Software Depots Copy Tasks and Examples This section provides examples of commands for copying software products. (See also “Additional Depot Management Tasks and Examples” on page 155.
Managing Software Depots Registering and Unregistering Depots (swreg) Registering and Unregistering Depots (swreg) To make the software in a depot available for use across a network by other SD-UX commands, you must register the depot. You can also unregister a depot if you do not want it to be available. Depots are registered or unregistered in these ways: • The swcopy command automatically registers newly created depots. (You can turn this function on or off with the register_new_depot option.
Managing Software Depots Registering and Unregistering Depots (swreg) Registration and Security Because SD-UX stores its objects in the file system, someone could build a “Trojan Horse” file system image of a software depot. This could breech the security of any system that installed products from the false depot. To protect systems from such a situation, SD-UX requires that depots be registered before software may be installed or copied from it.
Managing Software Depots Registering and Unregistering Depots (swreg) -C session_file Run the command and save the current option and operand values to a session_file for re-use in another session. See “Session Files” on page 61. -f object_file Reads a list of depots or root objects to register or unregister from a object_file instead of (or in addition to) the command line. -S session_file Run the command based on values saved from a previous session, as defined in session_file.
Managing Software Depots Registering and Unregistering Depots (swreg) Changing You can change the behavior of this command by specifying additional Command Options command-line options when you invoke the command (using the -x option) or by reading predefined values from a file.
Managing Software Depots Additional Depot Management Tasks and Examples Additional Depot Management Tasks and Examples This section illustrates some typical depot management tasks and provides extended examples of how you can use SD-UX to manage your environment. Combining Patch Depots This example shows how to combine into a single depot five downloaded patches (which are tape depots) from HP.
Managing Software Depots Additional Depot Management Tasks and Examples Creating a Tape Depot for Distribution This example shows you how to create a tape depot as a single file that can be distributed via ftp or the web. This example uses the five patches from the previous example (which are formatted as tape depots) and uses an existing depot at /depots/mypatches. The swlist command shows the depot contents (see “Listing the Contents of a Depot (swlist -d)” on page 159).
Managing Software Depots Additional Depot Management Tasks and Examples Creating a Network Depot Creating a network depot from which to install software can improve performance and ease of use when you have to install software to large numbers of systems. For example, HP-UX 11i is delivered on two CDs, requiring you to swap CDs during the update process.
Managing Software Depots Additional Depot Management Tasks and Examples 9. Insert the HP-UX 11i CD2. Wait for the drive’s busy light to stop blinking. 10. Repeat Steps 6 through 8 using CD2 and the Support Plus CD. The network depot is now ready for you to use to update your HP-UX 10.20 or 11.0 system to HP-UX 11i. Managing Multiple Versions of HP-UX You can use your HP-UX 11i system to manage depots for HP-UX 11.00 and 10.
Managing Software Depots Additional Depot Management Tasks and Examples To list all depots on a remote machine (hostA), type: swlist -l depot @ hostA To list all the depots on a system from newest to oldest (by time last modified): swlist -l depot -a mod_date -a mod_time | sort -rn -k 7,7 TIP Use the mod_time as a convenient sort field (a single integer), and use mod_date to include human-readable output. (Place mod_time at the end of the display where it’s less visible.
Managing Software Depots Additional Depot Management Tasks and Examples List the media attributes of the local tape depot, /dev/rmt/0: swlist -d -v -l depot @ /dev/rmt/0 type distribution tag CORE OS description HP-UX Core Operating System Software Disc number B2358-13601 date June 1991 List the products stored in the software depot on host1 located at /swmedia.
Managing Software Depots Additional Depot Management Tasks and Examples Verifying a Depot (swverify -d) To can use the swverify command to verify the software within a depot. swverify performs these tasks: • Verifies that all dependencies (prerequisites or corequisites) can be met. • Reports missing files. • Checks file attributes, including permissions, file types, size, checksum, mtime, and major/minor attributes.
Managing Software Depots Additional Depot Management Tasks and Examples Removing Software from Depots Invoking swremove with the -d option removes software from depots instead of root file systems. This also means that you must specify a path to identify the depot from which you want to remove the software. For example: swremove -d Old-Software @ /var/spool/sw For the swremove -d GUI, you are prompted to specify the depot by a dialog that appears after you invoke the GUI.
Managing Patches 5 Managing Patches This chapter discusses Software Distributor features that help you develop, install, and manage software patches.
Managing Patches Introduction Introduction SD-UX gives you the ability to perform patch management operations including installation, copying, listing, removing, rollback, and committal. Patch-related features of SD-UX include: • Command options for patch management functions. • Software objects and attributes for identifying and managing patches. • An interactive patch management tool. NOTE You can use the SD-UX remote operations features for patch management.
Managing Patches Introduction Patches that have been applied to an ancestor fileset are listed in the ancestor’s applied_patches attribute. HP patches are required to completely replace earlier patches. A newer version of a patch is said to supersede an earlier version. A patch fileset’s supersedes attribute lists all previous patch filesets that it supersedes. Patch filesets can have dependencies on other patches as well as non-patch software.
Managing Patches Introduction • Another new option, autoselect_patches, causes SD to automatically select patches that are appropriate for any non-patch software that has been selected. • Patch dependencies are now enforced. See “Patch Supersession and Dependency Resolution” on page 166 and “Using swlist to Resolve Manual Dependencies” on page 179. Patch management command options are discussed in the following sections.
Managing Patches Patch-Related Features Patch-Related Features SD’s patch-related features include command options and software attributes. Patch attributes are discussed in “Packaging Patch Software” on page 182 in this chapter. Command Options Patch default options are available at the command line.
Managing Patches Patch-Related Features Table 5-2 Patch Options Listed by Corresponding Command (Continued) Command Patch Option swlist level=patch (equivalent to -l patch) patch_one_liner=title patch state show_superseded_patches=false swmodify patch_commit=false swremove allow_split_patches=false • allow_split_patches=false Permits the independent management of individual patch filesets within a patch product.
Managing Patches Patch-Related Features • patch_commit=false Commits a patch by removing files saved for patch rollback. The default value is false. When set to true, this option removes the saved files for the patches specified in the software selections for the command and changes the associated patch_state attribute from applied to committed or from superseded to committed/superseded. (See also patch_save_files.
Managing Patches Patch-Related Features • patch_one_liner=title patch_state Specifies the attributes shown on the one-line display for each object listed by swlist. Applies when the -l patch option is invoked and when no -a or -v option is specified. The default display attributes are title and patch_state. Applies to swlist only. • patch_save_files=true Saves files to be patched before they are overwritten during an installation. This permits future rollback of patches.
Managing Patches Patch Management Tasks and Examples Patch Management Tasks and Examples installing copying, interactive patch management, removal, rollback, committing patches, verifying patches Installing Patches Installation of patch products follows the same rules as any other SD installation. The key difference is that patch selection and mechanisms let you select only the patches that meet specified criteria.
Managing Patches Patch Management Tasks and Examples • If more than one patch for a base fileset exists, only the latest patches (i.e., those that are not superseded) will be automatically selected for installation, unless overridden by an explicit patch selection. • You can also explicitly specify patches on the command line. See “Explicitly Specifying Patches” on page 173 for more information. The following examples demonstrate the use of patch options on the command line.
Managing Patches Patch Management Tasks and Examples Patch Filtering with Multiple Criteria You can repeat a version qualifier (for AND criteria) and use the pipe symbol (|) within qualifiers (for OR criteria). This is consistent with the current level of expression support in POSIX standard software specifications. To install any patches that have the category tag of critical AND the category tag of either special_release OR hardware_enablement.
Managing Patches Patch Management Tasks and Examples Installing Patches to Kernel and Library Files To permit patching of kernel files or libraries (e.g. libc.a), SD uses an archive file type of a. When loading a file of type a, swinstall temporarily installs the .o file to the target path specified, integrates it into the archive specified by the archive_path attribute of the file, and then removes the .o file.
Managing Patches Patch Management Tasks and Examples Copying Patches The swcopy command uses the autoselect_patches, patch_filter, and patch_match_target options in the same way that swinstall does, except that there is no filtering based on architecture (either 32-bit or 64-bit). The following example copies X11 software from the default depot and copies all patches for this software at the same time. (Note that autoselect_patches is true by default.
Managing Patches Patch Management Tasks and Examples Interactive Patch Management The swinstall or swcopy GUI lets you perform interactive patch installation and copying. (See “Installing with the GUI” on page 65 and “Using the swcopy GUI” on page 138.) The Manage Patch Selection... option in the Actions menu opens the Manage Patch Selection dialog. This dialog lets you: Figure 5-1 • Select from a list of patches available to install or copy. • Select filters for patches. • Set other patch options.
Managing Patches Patch Management Tasks and Examples • Filter (button and specification field) Click on the Filter button to display a list of example filters that you can select from. (To change the filters in the list, see “Editing the Patch Filter List” on page 177.) This field sets the patch_filter option, which lets you specify a filter for automatic patch selection. Patches for software to be installed or copied are automatically marked as you enter the analysis phase.
Managing Patches Patch Management Tasks and Examples swinstall.patch_filter_choices={ *.*,c=enhancement *.*,c=critical } swcopy.patch_filter_choices={ *.*,c=halts_system } Listing Patches Software objects with the is_patch attribute set to true have the built-in, reserved category of patch. This lets you list available patches and patches with a certain name. You can also list patches with the swlist GUI (invoked by swlist -i).
Managing Patches Patch Management Tasks and Examples Listing Available Patch Categories You can use the -l category specification to list the categories of available patches for patches that are defined with category objects.
Managing Patches Patch Management Tasks and Examples These rules govern patch removal and rollback: • Using swremove to remove the base fileset of a patch fileset also removes all patches to that fileset. • Files saved for rollback are also removed when the base fileset to which they apply is updated or removed from the system. • Removal of a patch automatically rolls back the saved files, unless: — You set the patch_save_files option to false at the time you installed the patches.
Managing Patches Patch Management Tasks and Examples Verifying Patches The swverify operation on a normal fileset checks that the latest files are properly installed. When installing a patch, the ancestor fileset is updated to have the correct attributes of the patched files. SD verifies patch filesets by checking that files in a patch are still properly installed (or in the depot correctly).
Managing Patches Packaging Patch Software Packaging Patch Software This section contains information about packaging patch software. Packaging involves the unique patch attributes and behaviors described below. For complete information on packaging, objects, and attributes, see Chapter 10, “Creating Software Packages,” on page 301. Patch Software Characteristics 182 • Each patch fileset only patches files in one base fileset.
Managing Patches Packaging Patch Software Patch Software Objects and Attributes SD contains attributes specifically for handling patch software. The following attributes are available to all software levels (bundles, products, subproducts, and filesets). category objects A software collection can contain a list of category objects, which are used as a selection mechanism.
Managing Patches Packaging Patch Software • Control scripts delivered with the patch fileset run only when that patch fileset is installed. They do not replace the control scripts for the base fileset. See “Fileset Specification” on page 331 for a complete description of all patch and non-patch fileset attributes. Patch fileset attributes include attributes that you can specify in a product specification file (PSF) and attributes generated by SD.
Managing Patches Packaging Patch Software Patch File Attributes Patches to the kernel or other libraries can be implemented and removed with the following file level attributes: type If set to a, designates an archive file and marks it for an archive action during an install or update. An archive file is a .o file that needs to be replaced in an existing archive using the ar command.
Managing Patches Packaging Patch Software PSF Example This 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 HP-UX convention is for patches to use unique product tags but that the fileset tags match those of the ancestor filesets.
Managing Patches Packaging Patch Software Notes: • The ancestor attribute identifies the fileset to be patched. • The true value of the is_patch attribute at the fileset level flags this fileset as a patch and permits rollback if you use the patch_save_files option when you install the patch. Attributes Generated by SD SD-UX generates the following patch fileset attributes and stores them in the IPD: • applied_patches Set for base (non-patch) software only.
Managing Patches Packaging Patch Software 188 Chapter 5
Remote Operations Overview 6 Remote Operations Overview This chapter presents an overview of remote operations, describing set-up, features, and important concepts to help you effectively manage software across multiple systems.
Remote Operations Overview Introduction Introduction In addition to its ability to “pull” software from a central depot, Software Distributor also provides powerful features for remote operations that let you “push” software to remote systems (targets) from the local host. You can use these features interactively and monitor results of all SD-UX commands with the Job Browser or from the command line with the swjob command. NOTE The Terminal User Interface (TUI) is not available for remote operations.
Remote Operations Overview Introduction NOTE You must restart the SD-UX daemon if you change daemon options, or the system will not recognize the changes. See “Using Command Options” on page 59 for more information. Job Management With SD-UX remote operations, you can create jobs for immediately execution or schedule them for later execution.
Remote Operations Overview Introduction Additional GUI Components SD-UX adds extra components to the GUI programs when remote operations are enabled. Otherwise, the programs are almost identical to those used for local operations. (See “Using the Remote Operations GUI” on page 193.) Software and Target Lists Most SD-UX commands let you read lists of software selections from separate input files. With remote operations, you can also read target lists from separate files.
Remote Operations Overview Using the Remote Operations GUI Using the Remote Operations GUI SD-UX adds extra components to the GUI programs when remote operations are enabled. The extra components for remote operations include a target selection window and features for managing target lists, job preferences, and job monitoring windows. Otherwise, the GUI programs are identical to those used for local operations.
Remote Operations Overview Using the Remote Operations GUI Target Selection Window The Target Selection Window always appears first with the remote GUI programs. Like the Software Selection Window, it features the standard menu bar, message area, and object list of targets available for selection. Instead of selecting software, you select the remote targets on which the remote operation will take place. Menu items and target selection are discussed in the following sections.
Remote Operations Overview Using the Remote Operations GUI 4. When you have selected all targets for your operation, select Actions→Show Software for Selection.... to display the Software Selection Window. Selecting Multiple Targets This section discusses how to install to multiple targets, create target groups, and how to save these groups for future software installations. (For single-target installations to your local (default) target, see the procedures in “Remote Operations Tutorial” on page 200).
Remote Operations Overview Using the Remote Operations GUI 2. Enter the primary root name in the Hostname: area and select Add. 3. The Select Target Path dialog appears. The default path is root (/). To accept the default root (/), click OK. 4. After selecting the root path, the Hostname and Root Path are automatically updated in the Add Target dialog (Figure 6-2, “Add Targets Dialog,”). To add additional targets, repeat 2. 5. Select OK in the Add Targets dialog.
Remote Operations Overview Using the Remote Operations GUI Selecting Individual Targets You can add or delete individual targets. To add a new target: 1. Select Actions→Add Targets....The Add Targets dialog appears. 2. Type in the name of the desired target and click on Add. The Select Target Path dialog appears. 3. Click OK to accept the default (/) or click on the Root Path...button to display the Shared Root Paths dialog, which contains more selection options. 4.
Remote Operations Overview Using the Remote Operations GUI Saving a Target Group You may want to re-use your list of targets for a later session. To do so, 1. Select Actions→Save Target Group... The Select File dialog appears. If target groups already exist, the first file path appears in the text box in the bottom of the dialog. Type a name for a new group or re-use an existing group (saving your current list to existing target group overwrites that group). Groups are saved in the directory: $HOME/.
Remote Operations Overview Setting Up Remote Operations Setting Up Remote Operations SD-UX uses Access Control Lists to authorize anyone who is attempting to create, modify, or read software products in a depot or to install software to a root file system. (ACLs are discussed in detail in Chapter 9, “SD-UX Security,” on page 255.) To enable the remote operations, you must install a special HP ServiceControl Manager fileset on each remote system to be managed. You can then enable the remote operations GUI.
Remote Operations Overview Remote Operations Tutorial Remote Operations Tutorial This tutorial introduces you to the remote operations user interface and to the general flow for distributing software to other systems. Also, you will learn how to preview, schedule, and monitor your distribution jobs. Although this tutorial uses swinstall for the example GUI, the swcopy and swremove GUI programs are almost identical. You can apply the knowledge you gain from this tutorial to those tasks.
Remote Operations Overview Remote Operations Tutorial How to Perform a Single-Target Installation Overview The tutorial consists of these steps: Table 6-2 Installation Steps Overview of Installation Steps Step I: Start-up I. Start-up Start the Job Browser. II. Select Targets Specify the targets where you want the software installed. You can use the default local target or specify another target. III.
Remote Operations Overview Remote Operations Tutorial Step II: Select Targets The Target Selection Window displays the local, default target. A target is where you want the installation to go (in the example below, the target is the system swbash3). By default, the current system is listed (Figure 6-3, “Target Selection Window,”). Figure 6-3 Target Selection Window Specify the desired target for the installation: 1. For local default: a. Highlight the local target system with a left mouse click.
Remote Operations Overview Remote Operations Tutorial — or — For remote targets: choose Actions→Add Targets to install to a different target. This takes you to the Add Targets dialog (Figure 6-4, “Add Target Dialog (for multiple or non default targets),”). 2. Enter the target name in the Hostname: area (e.g., system_two) and select Add. This takes you to the Select Target Path dialog. Figure 6-4 Add Target Dialog (for multiple or non default targets) 3. Use the current root path (/) by selecting OK.
Remote Operations Overview Remote Operations Tutorial Step III: Select Source In this step, the Specify Source dialog lets you select the Source Host Name (the source system where the depot resides) and Source Depot Path (path of the depot containing the software). Figure 6-5 Specify Source Dialog 1. The Specify Source dialog should list your controller name or your remote test system name in the Source Host Name...
Remote Operations Overview Remote Operations Tutorial Step IV: Select Software Use the Software Selection Window to select the software you want to install. Figure 6-6 Software Selection Window 1. Highlight SD-DATABASE (i.e., the example software) by clicking on it with the left mouse button. 2. Choose Actions→Mark for Install (or right-click to display the pop-up menu and select Mark for Install). The Marked? column is set to Yes for SD-DATABASE.
Remote Operations Overview Remote Operations Tutorial Table 6-3 Software Selection List (Continued) Software Selection Window Object List For example: • To see the subproducts in the product SD-DATABASE, double click on it. The object list displays the subproducts. To open a subproduct, double click on the name. (Or highlight the name and then select Actions→Open Item...) • To close an object and return to the previous list, double click on the first item in the list (..
Remote Operations Overview Remote Operations Tutorial This is the name of your install job. 2. Select OK to install the software now. For single-target installations such as this tutorial, the Install Analysis dialog appears (Figure 6-8 on page 208). 3. If this is your first pass through the tutorial, proceed to Step V. 4. (Optional) Previewing a Job a. Select the Preview button. This tells SD to analyze the software without installing it. b. Click OK. The Install Analysis dialog appears.
Remote Operations Overview Remote Operations Tutorial Step VI: Analysis and Installation SD-UX analyzes the target before performing the actual install, copy, or remove operation. (If you set up a preview job in Step IV, the install stops after the analysis.) Figure 6-8 Install Analysis Dialog 1. When the Analysis is complete, the status for the target you selected should show Ready, indicating no errors or warnings occurred during analysis. Select OK to proceed with the installation.
Remote Operations Overview Remote Operations Tutorial Step VII: Monitor Results When you exit the Target Selection Window, you return to the Job Browser. The icons in the job list change to show the status of jobs. Different icons indicate different job status. (See “Job Browser Icons” on page 218 for sample icons.) Your job, labeled SDTESTJOB, should show with either a check mark or a ruler icon.
Remote Operations Overview Remote Interactive swlist Remote Interactive swlist For remote operations, the swlist -i command starts a list browser that lets you interactively list installed software on remote hosts. The only difference between remote and local operations is the name of the target displayed in the message area of the Software Browsing window. Figure 6-10 The swlist Browser For more information about swlist, see “Listing Your Software (swlist)” on page 96.
Remote Operations Overview Remote Operations from the Command Line Remote Operations from the Command Line Running remote operations from the command line is almost identical to those for local operations. Key differences are: • You must specify target selections. • You can monitor jobs using the swjob command, as discussed in “Monitoring Jobs from the Command Line” on page 230. • You can use additional command options to schedule and manage jobs.
Remote Operations Overview Remote Operations from the Command Line • On some systems, the @ character is used as the kill function. Type stty on your system to see if the @ character is mapped to any other function on your system. If it is, remove the mapping, change the mapping, or use \@. Target Files You can also use an input file to specify targets. To keep the command line shorter, target selection input files let you specify long lists of targets.
Remote Operations Overview Remote Operations from the Command Line swcopy To copy the C and Pascal products to one local and two remote depots: swcopy -s sw_server cc pascal @ /var/spool/sw \ hostA:/tmp/sw hostB swinstall To install the C and Pascal products to three remote hosts: swinstall -s sw_server cc pascal @ hostA hostB hostC swjob The swjob command lets you monitors jobs from the command line.
Remote Operations Overview Remote Operations from the Command Line 214 Chapter 6
Using Jobs and the Job Browser 7 Using Jobs and the Job Browser This chapter describes SD-UX jobs the Job Browser interface for remote operations. For additional information on remote operations, see Chapter 6, “Remote Operations Overview,” on page 189.
Using Jobs and the Job Browser Introduction Introduction The Job Browser GUI, an interactive interface for managing remote operations. The Job Browser lets you: • Create copy, install, or remove jobs • Monitor job status and logfiles • List job information • Schedule jobs The swjob command lets you monitors jobs from the command line. Various command options help you manage and tune performance of jobs and remote operations.
Using Jobs and the Job Browser Using the Job Browser Using the Job Browser Figure 7-1 The SD Job Browser Window The window is divided into three parts: NOTE Chapter 7 • Menu bar, which contains most of the standard SD-UX menus discussed in “Using the GUI and TUI Commands” on page 35. Menu items specific to the Job Browser are discussed later in this chapter. • Message area, which displays the current time. • Jobs List, which displays job icons (the default) representing each job.
Using Jobs and the Job Browser Using the Job Browser Job Browser Icons Figure 7-2 • A clock indicates that the job is scheduled but hasn’t run yet. • A check mark indicates that a job has completed. • A ruler indicates that the job is active. • A red background indicates that the job contained errors. • A yellow background indicates that the job contained warnings. Copy Icon This icon represents a copy job (depot to depot). A check mark indicates that the job has completed.
Using Jobs and the Job Browser Using the Job Browser Figure 7-4 Scheduled Install Job Icon This icon represents an install job that is scheduled for a later time. The clock face indicates that it is a scheduled job. Figure 7-5 Install Job with Warnings Icon This icon represents an install job that completed, but contained warnings. The background around the icon is yellow. Figure 7-6 Install Job with Errors Icon This icon represents an install job that completed, but contained errors.
Using Jobs and the Job Browser Using the Job Browser Figure 7-7 Scheduled Remove Installed Software Job Icon This icon represents a scheduled remove job on installed software. Figure 7-8 Scheduled Remove Depot Software Job Icon This icon represents a scheduled remove job on software contained in a depot. Figure 7-9 Verify Job Icon This icon represents a verify job (represented by a magnifying glass) that completed, but contained errors. The background around the icon is red.
Using Jobs and the Job Browser Using the Job Browser The File Menu The File menu has the following options: Search Performs text searches for job IDs or titles. Print Lets you print the jobs list. Exit Exits the Job Browser Printing the Jobs List This option prints the Jobs List to a specified printer or saves it to a file. (The Jobs List can only be printed if it is listed by properties—see “The View Menu” on page 222.
Using Jobs and the Job Browser Using the Job Browser The View Menu The View menu lets you change the way information is presented in the Job Browser. The standard choices on this menu (Columns..., Filter... , Sort... and Save View as Default) match those described in “Changing Software Views—The View Menu” on page 42. Note, however, that the Columns... choice is only valid for View→By Properties (discussed below).
Using Jobs and the Job Browser Using the Job Browser • Any modifications made in the View→Columns..., View→Filter..., or View→Sort... menu selections affect how the property list is displayed. • This menu item and the By Name and Icon menu choice operate as radio buttons. When one is chosen, the other is un-chosen. • You can print the job list from this view by choosing File→Print.... The Options Menu The Options menu optional behavior of the Job Browser.
Using Jobs and the Job Browser Using the Job Browser To change the refresh interval for the SD-UX daemon, see “Managing and Tuning Jobs with Command Options” on page 234. Refreshing the Jobs List To immediately update the Jobs List, choose Options→Refresh List.
Using Jobs and the Job Browser Using the Job Browser The Actions Menu Items in the Actions menu let you perform job creation and management tasks. If you have selected a job selected, the actions available apply specifically to that job. If you do not have a job selected, the only action available is job creation. Shortcuts To display a pop-up menu of job-specific actions, right-click on a job icon, then left-click. This displays a pop-up Actions menu items.
Using Jobs and the Job Browser Using the Job Browser • Select the Show Log button or double-click on a target in the object list opens the log for that target. • Select OK to return to the Job Browser. (Closing the dialog does not stop the jobs displayed if they are active.) Figure 7-12 Job Results Dialog NOTE For performance reasons, a maximum of 250 targets are listed at once. If there are more then 250 targets for the job, Next and Previous buttons appear to let you view groups of 250 targets.
Using Jobs and the Job Browser Using the Job Browser • All job attributes (ID, type of operation, scheduling, current state, results, when last updated, source) • Name and revision of the software • Targets involved and target type: — primary root — alternate root — depot Figure 7-13 Chapter 7 Show Job Description • Selecting Show Options... displays the Job Options dialog. This lets you see the options used to create this job. • Selecting Show Results...
Using Jobs and the Job Browser Using the Job Browser Showing Job Logs Selecting Actions→Show Job Log... displays the Job Log dialog, which displays the controller (summary) log of a selected job. Buttons let you refresh or print the log file. Select OK to return to the Job Browser. (This menu item is greyed-out if the selected job is not active or completed.) Copying Jobs Copying a job consists of making the target and software selections available to a new session of swinstall, swcopy, or swremove.
Using Jobs and the Job Browser Using the Job Browser Removing a Job The Actions→ Remove a Job... menu choice lets you remove the currently selected jobs from the Jobs List. (To select more than one job, hold down the CTRL key while selecting jobs in the Job Browser window.) The Remove a Job dialog displays, listing information about the selected jobs. Figure 7-14 Chapter 7 Remove a Job dialog • If you remove a scheduled job that has not yet run, the job is never run.
Using Jobs and the Job Browser Monitoring Jobs from the Command Line Monitoring Jobs from the Command Line The swjob command lets you display and monitor jobs information using the command line. This command provides a quick, low-bandwidth alternative to the Job Browser when you want to check on specific jobs.
Using Jobs and the Job Browser Monitoring Jobs from the Command Line -t target_file Read a list of target selections from a separate file instead of (or in addition to) those you specify on the command line. See “Target Files” on page 59. -x option=value Sets a command option to value and overrides default values or a values in options files. See “Using Command Options” on page 59. -X option_file Read session options and behaviors from option_file. See “Using Command Options” on page 59.
Using Jobs and the Job Browser Monitoring Jobs from the Command Line swjob Attributes Each job has its own set of attributes. These attributes include job title, date of scheduled execution, and results. The -a option selects a specific attribute to display. You can specify multiple -a options to display multiple attributes. Table 7-4 Typical job attributes jobid 232 The job identification number assigned by SD-UX operation The type of operation (install, copy, remove, verify, etc.
Using Jobs and the Job Browser Monitoring Jobs from the Command Line swjob Tasks and Examples To simply list the jobs available, type: swjob To display attributes of jobs on the local system, type: swjob -v To display attributes of jobs on remote system swbash3, type: swjob -v @ swbash3:/var/spool/sw Using the -a log option lets you display log files for jobs. A job log file summarizes job details and target actions.
Using Jobs and the Job Browser Managing and Tuning Jobs with Command Options Managing and Tuning Jobs with Command Options SD-UX command options let you manage and tune job behavior to best fit your environment, particularly when you run large numbers of jobs. See “Using Command Options” on page 59 for additional information on setting command options. Scheduling Jobs from the Command Line The -Q date option lets you schedule jobs without starting the Job Browser.
Using Jobs and the Job Browser Managing and Tuning Jobs with Command Options Removing Job Information Purpose: to increase performance and free up disk space when you run very large numbers of jobs. SD-UX stores small amounts of information (such as job status or controller or agent logfiles) about each job. You can display this information from the Job Browser or with swjob. Keeping very large numbers of job information files may affect performance and reduce the usability of the Job Browser.
Using Jobs and the Job Browser Managing and Tuning Jobs with Command Options 236 Chapter 7
Reliability and Performance 8 Reliability and Performance This chapter describes the interrelationship of Software Distributor reliability features and performance. Understanding how these features work together will help you improve the overall reliability of your software distribution system.
Reliability and Performance Overview Overview SD-UX install and copy throughput are dependent on the following factors: • Speed of the network • Size (i.e., number of bytes) of the product being transferred • Number of files being transferred • Number of targets any one source is serving simultaneously SD-UX provides many features that can be used together to increase the speed and success rates of distributed installations and copies.
Reliability and Performance Overview • Compression: SD-UX supports compression functionality to reduce the amount of data being transferred. • Staging: SD-UX supports staging software to intermediate depots either on the installation target or onto a source more accessible to the target, which has been preconfigured to use the alternate source. • Recovery: SD-UX supports automatic procedures to recover from failed installations, leaving the system in the same state as previous.
Reliability and Performance Groups and Source Options Groups and Source Options Group and source options can help increase performance of some commands. Target and software selections can be saved as group files and re-used. This reduces the need to re-specify commonly used selections, which reduces the time required to perform swinstall, swcopy, or swremove commands. See “Add/Save Software Group” on page 49, and “Software and Target Lists” on page 192 for more information.
Reliability and Performance Large Numbers of Targets Large Numbers of Targets The max_targets option applies to swinstall and swcopy operations. This option lets you manage hundreds of targets with a single job by limiting the number of simultaneous targets to a defined value. As each target completes the install or copy, another target is selected and started until all targets have been completed. This keeps the number of active operations at or below the user-defined limit.
Reliability and Performance Timeout Options Timeout Options Timeout options control how long a task continues to retry low-level communications for file transfers before giving up. One control is the amount of time each single RPC call waits before giving up. This timeout is set by the rpc_timeout option. Legal values are 0 through 9. The default value is 5, which corresponds to about 30 seconds for the UDP protocol. Each value doubles the time of the preceding value (i.e.
Reliability and Performance Retry RPC and Retry Interval Retry RPC and Retry Interval During a swinstall or swcopy operation, retry_rpc_interval controls the interval schedule for repeated attempts to make a connection to a target or the source agent after an initial failure. This option works in conjunction with retry_rpc, which controls the number of times the target or source is re-contacted. The default value for retry_rpc is 1 and retry_rpc_interval is {0}.
Reliability and Performance Retry Command Retry Command SD-UX supports options that facilitate retrying operations that have failed. These can be used in conjunction with the checkpointing features or can start the task from the beginning. Each execution of a command records all of the target, software, and option selections automatically in a session file, command.last. You can also save the session information to a different file using the GUI. The session files are stored in the directory $HOME/.
Reliability and Performance Database Checkpointing Database Checkpointing The tools perform automatic checkpointing, recording transactions in the SD-UX depot catalog, or Installed Products Database (IPD) at the fileset level. Additionally, checkpointing at the file level is supported through attributes stored with the file. During a swinstall or swcopy operation, all filesets in the current product being loaded are recorded in the depot catalog or IPD as having a state of transient.
Reliability and Performance Compression Compression The swinstall and swcopy commands can transfer large amounts of data over the network from depots to targets. The SD-UX compress_files option can improve performance by first compressing files that are to be transferred. This can reduce network usage by approximately 50%; the exact amount of compression depends on the type of files. Binary files compress less than 50%; text files generally compress more.
Reliability and Performance Staging Staging The standard way to install software onto multiple targets is to specify a single source depot and each target that is to receive the software. However, some software distribution environments require that you manage software on large numbers of geographically dispersed target systems. This may require the use of one or more intermediate source depots or staging areas. This variant on the standard model is referred to as a staged installation.
Reliability and Performance Staging To do a staged installation: 1. First, decide on the location of the intermediate depots and use the swcopy command to copy the software from your master depot to them. This step is no different from a normal multi-target copy operation. swcopy -s master -t depot_list NewApp In this example, the master source depot containing the product NewApp is in the default /var/spool/sw depot location and a file named depot_list contains the list of intermediate depots.
Reliability and Performance Staging • If the target doesn’t have an alternate source, the agent uses the same depot path used by the controller, but it will apply this path to its own file system. This lets you do staged installations without any target configuration at all, by locating the intermediate depot on each target system at the same file system location as the master depot (approach 2 above).
Reliability and Performance Recovery (Install Only) Recovery (Install Only) NOTE This section applies only to customer-created software with unpreinstall and unpostinall scripts. HP-supplied software does not include these scripts. SD-UX supports automatic procedures to recover from failed installation if the autorecover_product option is set to true, attempting to leave the system in the same state as it was previously. Also, manual means are available (refer to “Multiple Versions” on page 253).
Reliability and Performance Recovery (Install Only) If any of these steps fails (e.g., a lost source or a script error) then the undo scripts are run, and the files restored from the point of failure in reverse order. NOTE Patches created using the features capabilities described may maintain saved files. In this case, patches can be removed (rolled back) or committed (by removing saved files). See Chapter 5, “Managing Patches,” on page 163 for more information on patches.
Reliability and Performance Installation With Separate Configuration Installation With Separate Configuration NOTE Because deferring configuration of OS software and patches can leave the system in an unusable state, do not use this technique with HP-supplied software. If you create your own software that includes configuration scripts to be performed automatically after installation, performing the configuration separately can increase the reliability of the overall installation process.
Reliability and Performance Multiple Versions Multiple Versions SD-UX supports installing multiple revisions of the same software on a system at the same time, if the software supports it. By using multiple installed versions, recovery can be supported at the system or task (all systems) level. Installing a second version requires some careful planning, as well as understanding how to identify multiple versions on the system. Each product has a product directory attribute.
Reliability and Performance Multiple Versions Additionally, you can list a fully qualified software spec containing both the location and revision as well as the other version distinguishing attributes (vendor and architecture) with: swlist -l fileset -a software_spec After the new version is installed successfully for all products or on all hosts, the old version can be unconfigured, and the new version configured as the active version by using swconfig -u with the old version and swconfig with the new ve
SD-UX Security 9 SD-UX Security During the SD-UX installation, a default security setup is created. This chapter explains basic SD-UX security, introduces the swacl command, presents examples of common tasks, and provides in-depth discussion of how SD-UX manages security.
SD-UX Security Overview Overview Along with the traditional HP-UX file access protection, SD-UX uses Access Control Lists (ACLs) to protect the primary objects on which it manages software: • Hosts • Roots (software installed on a host) • Depots • Products within depots An ACL consists of a set of entries associated with an object when it is created. Default Security The following security scheme exists by default: • The local superuser always has access to all local objects.
SD-UX Security Overview Depots and Depot Registration Software Distributor typically uses central depots to distribute software. You can control access to these depots by users who will install software. An important security consideration is that depots must be registered for nonlocal users to have access. Only a local superuser or a user with insert permission on the host can install from unregistered depots.
SD-UX Security The swacl Command The swacl Command The swacl command lets you view or change ACL entries and permissions. swacl Syntax swacl ] -l level [-D acl_entry|-F acl_file|-M acl_entry] [-f software_ file][-t target_ file] [-x option=value] [-X option_file] [software_selections] [@ target_selection] Options and Operands -l level NOTE You can change an ACL with -D, -F, or -M command options. You can only specify one of these options per command because they are mutually exclusive.
SD-UX Security The swacl Command -t target file Reads a list of target host selections from a separate file instead of from the CLI. (See “Target Files” on page 59.) -x option=value Lets you change an option on the command line interface (CLI) that overrides the default value or a value in an alternate options file (-X option file). See “Changing Command Options” on page 259. -X option file Uses the option values in a specified option file. See “Using Command Options” on page 59.
SD-UX Security The swacl Command swacl Output A typical list output from the swacl command looks like the following: # swacl Installed Software Access Control List # # For host: prewd:/ # # Date: Mon Nov 06 16:39:58 2001 # # Object Ownership: User=root # Group=sys # Realm=prewd.fc.hp.com # default_realm=prewd.fc.hp.com object_owner:crwit user:rml:crwit user:root@newdist.fc.hp.
SD-UX Security Basic Security Tasks Basic Security Tasks Along with the traditional HP-UX file access protection, all SD-UX objects (hosts, depots, roots and products) are also protected by ACLs. Figure 9-1 Access Control Lists ACLs offer a greater degree of selectivity than do permission bits. An ACL extends the concept of the HP-UX file system’s permission bits by letting you specify different access rights to several individuals and groups instead of just one of each.
SD-UX Security Basic Security Tasks the source host was added. This lets the controller system’s superuser perform software distribution tasks on the remote system without having to reconfigure ACLs. If you need to change security, the following tasks can be performed (i.e.
SD-UX Security Basic Security Tasks This ACL indicates that the file system is owned by the root user, and that as such, the owner has full ACL permissions (crwit). Additionally, all other users may read SD information about this root file system using the swlist command.
SD-UX Security Basic Security Tasks # # default_realm=newdist.fc.hp.com object_owner:crwit user:root:crwit user:root:crwit any_other:-r--• To show permission to create depots and roots on the target host: swacl -l host @ newdist # # swacl Host Access Control List # # For host: newdist # # Date: Fri Nov 03 10:34:06 2001 # # Object Ownership: User= root # Group=sys # Realm=newdist.fc.hp.com # # default_realm=newdist.fc.hp.com user:fred:crwit user:root:crwit user:smp:crwit user:root@udltools.fc.hp.
SD-UX Security Basic Security Tasks # # Object Ownership: User= root # Group=other # Realm=newdist.fc.hp.com # # default_realm=newdist.fc.hp.com object_owner:crwit user:root:crwit user:root@prewd.fc.hp.com:crwit any_other:-r--- Allowing Users to Manage Products in a Depot Users that are packaging products may need access to the SD-UX depots to store their products. In ACLs, a is a shorthand notation for all permissions (crwit).
SD-UX Security Basic Security Tasks To give user mary the permission to install new software into the root object: swacl -l root -M user:mary:i To let remote user allen@swelter fully manage the root file system on swcrunch: swacl -l root -M user:allen@swelter:a (In the above examples, change user to group and use a group name to add group access to the depot structures.
SD-UX Security Basic Security Tasks swacl -l depot -D any_other @ /simple_1.depot swacl -l depot -M other:r @ /simple_1.depot swacl -l depot @ /simple_1.depot # # swacl Depot Access Control List # # For depot: swelter:/simple_1.depot # # Date: Thu Mar 1 16:19:57 2001 # # Object Ownership: User= allen # Group=users # Realm=swelter.fc.hp.com # # default_realm=swelter.fc.hp.com object_owner:crwit other:-r--Local users can now access this depot as a result of the other ACL, but remote users are refused.
SD-UX Security Basic Security Tasks Adding Target Hosts For swinstall and swcopy, both the user and target host are validated (i.e., to protect from unauthorized users at remote hosts switching to an authorized user). The following adds read permission for the host named target to the default depot on the local host, the products currently in the depot, and any future products added to the depot (using global_product_template).
SD-UX Security Basic Security Tasks NOTE Do not change the default secret field unless you have also changed the default secret on the HP-UX SD-UX controller. These two secrets must match. The set of hosts that can be managed by SD-UX can be restricted by changing the default secret on all SD-UX controller and target hosts in the network. The default secret is found in /var/adm/sw/security/secrets.
SD-UX Security Basic Security Tasks NOTE It is possible to edit an ACL so that you cannot access it! Caution should be used to avoid accidentally removing your own control (c) permissions on an ACL. As a safeguard, the local superuser may always use swacl to edit SD-UX ACLs. Here are some examples based on the following ACL that is protecting a product (FORTRAN) created by user rob whose local host is lehi.fc.hp.
SD-UX Security Basic Security Tasks Then edit the tmp_file and replace the ACL: swacl -l product_template -F tmp_file \ @ /var/spool/sw_dev To delete entries for user barb and group swadm, use: swacl -D user:barb -D group:swadm -l product FORTRAN To give user ramon permission to modify the product FORTRAN, type: swacl -M user:ramon:trw -l product FORTRAN To add an entry for user pam with complete management permission (“a” is shorthand for crwit), use: swacl -M user:pam:a To add an entry to grant every us
SD-UX Security How ACLs are Matched to the User How ACLs are Matched to the User ACL permissions are determined by a match to a single ACL entry, not to an accumulation of matching entries. Checking is done from the most restrictive entry types to the broadest. If a match is found in a user entry type, no further checking is done, and the permissions for that user are fully defined by the permissions field of the matched entry.
SD-UX Security ACL Entries ACL Entries An ACL consists of a set of entries attached to an object when it is created. These entries define which users, groups, and/or hosts have permission to access the objects. ACL entries include the concept of a principal, which is the user, group or host system (for agents making RPCs) that originates a call to another system.
SD-UX Security ACL Entries Table 9-3 SD-UX ACL Entry Types (Continued) Type Permissions Apply To any_other Principals not matching any other entry object_owner Owner of the object object_group Members of the group to which an object belongs Do not confuse the host object (which is a computer system that contains depots, roots, and software) with the host entry type (which defines permissions for access to target systems).
SD-UX Security ACL Entries Table 9-4 SD-UX ACL Entry Key Values (Continued) Entry Type Key Content other [optionally, @ remote-host] any_other no key allowed When listing the ACL, the remote-host is printed in its Internet address form (e.g., 15.12.89.10) if the local system cannot resolve the address from its host lookup mechanism (DNS, NIS, or /etc/hosts). The remote-host must be recognized (resolvable) when used in the -M and -D options.
SD-UX Security ACL Entries The table below summarizes SD-UX object permissions and ACLs to which they may be applied.
SD-UX Security ACL Entries The depot ACL controls insertion (creation) of new products, while the inserted object has its own ACL that controls modification and deletion. This lets the creator (owner) of a product on a depot change or delete the product without requiring the broader write permission that could affect other users’ products on the same depot. This is useful for product control, because it lets you assign management control for a specific product to a delegated administrator.
SD-UX Security ACL Entries 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 target host lucille from an unregistered depot on source host desi, the command swacl -l host @ desi must show the minimum ACL entries user:rob@lucille:-ihost:lucille:-iRob could alternatively register the depot with the swreg command with only the first entry above before running swinstall or swcopy.
SD-UX Security ACL Entries Root ACLs Principals (users) identified in ACLs that are protecting roots are granted permission to manage installed products. The permissions associated with a root are: Table 9-8 Root Permissions i (insert) Permission to install a new product. r (read) Permission to list the contents of the root. w (write) Permission to delete the root itself or the products in the root. c (control) Permission to edit or change the ACL.
SD-UX Security ACL Entries Table 9-9 Depot Permissions (Continued) Permission to test access to an object and list the ACL.
SD-UX Security ACL Entries Table 9-11 Product Permissions (Continued) r (read) Permission granted to target_hosts to read the source-depot product. (that is, grant permission to a remote system to install the protected product). c (control) Permission to edit or change the ACL. t (test) Permission to test access to an object.
SD-UX Security ACL Entries ACL Templates There are two ACLs that are used to create the initial ACLs that protect newly created objects: product ACL templates (global_product_template or product_template) and container ACL templates (global_soc_template). Figure 9-2 ACL Templates When a product is put into a depot with swcopy or swpackage, SD-UX uses a product ACL template (provided by the depot that contains that product) to define the initial permissions of the new product’s ACL.
SD-UX Security ACL Entries • Product ACL Template (global_product_template) The ACL that is used to initialize the product ACL template on depots 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 to initialize the ACLs protecting new products on the depot.
SD-UX Security ACL Entries NOTE Remember, the local superuser always has all permissions, even without an ACL entry. 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 new depot or root and to change its ACL. It also grants global permission (any_other) to list products in the new depot or root.
SD-UX Security Security on SD-UX Systems Security on SD-UX Systems Controlling access to data is a key concern of computer security. In SD-UX, file owners and superusers allow or deny access to files on a need-to-know basis by setting or manipulating the file’s permission bits to grant or restrict access by owner, group and others. For example, the following file listing: -rwxr-xr 1 doug admin 738 Mar 26 12:25 datafile shows that: • File owner is user doug. • File’s group is admin.
SD-UX Security Security on SD-UX Systems security files. Controllers are set-uid root programs that run with the superuser privilege in effect only briefly to do critical privileged operations, then they switch to the real uid of the user. Here is a summary of the SD-UX file system protection scheme: • SD-UX files are protected from access by anyone other than the superuser by having the group and other permissions of crucial directory modes set to 0.
SD-UX Security SD-UX Internal Authentication SD-UX Internal Authentication This section discusses the following topics: • SD-UX Credentials — Controllers Run with the User’s Credentials and Privileges — Agents Run with the System’s Identity • Security Between Hosts: The Shared Secrets File SD-UX security does not replace DCE Security. It seeks to provide a usable protection scheme based on the assumption that there is no hostile, concerted effort by users to do damage.
SD-UX Security SD-UX Internal Authentication When you start an RPC (as an SD-UX controller), a structure describing your identity accompanies each call to an agent; the controller sends the user and group name of the person invoking the RPC, as well as the host name of the system on which it is running (in DCE, called the realm). This structure is called your credentials.
SD-UX Security SD-UX Internal Authentication While local superuser privilege is necessary for the agent to do required local file system operations such as file creation and deletion, ACL management, etc., this level of permission is neither required nor desired for DCE RPC operations with other SD-UX processes. When SD-UX agents perform RPCs, they assume the identity of the system on which they run, rather than that of a particular user.
SD-UX Security SD-UX Internal Authentication The first column represents the controller’s host name and the second column represents the controller’s secret. There is also a provision for a default secret (quicksilver in the example above), to be used when no system name match is found in the secrets file. The entry is identified with the default pseudo-host name. This entry allows open SD-UX interconnect between hosts sharing the same default entry.
SD-UX Security RPC Authorization RPC Authorization This section discusses how agents handle controller requests, local superuser authorization, depot registration, and daemon/agent security In SD-UX, objects are protected by ACLs. An ACL is a structure, attached to an object, that defines access permissions for multiple users and groups.
SD-UX Security RPC Authorization How Agents Handle Controller Requests When a controller requests an agent to do an operation requiring the participation of another agent, the two agents must each grant access to the objects under their control before the operation can complete. Figure 9-3 SD-UX Security Process For example, to install a product P from depot D to root R: 1. User U sends an RPC request to swagentA on the target host H. User U wants to install the product in root R (on the target host). 2.
SD-UX Security RPC Authorization 4. SwagentB checks the ACL protecting the product to make sure that both the destination system (principal H) and the user U have read permission before honoring the request, and the installation proceeds. The ACL on swagentB neither knows of nor depends on user U. The ACL on root R acts to screen U; then (and only then) the product’s ACL acts to screen H. As a special case, the superuser always has full permissions on a local system.
SD-UX Security RPC Authorization As a special case, an unregistered depot may be used for local installation (i.e., the depot and destination root exist on the same system) if the initiator is the local superuser or has permission to register the depot (insert permission on the host). The administrator of a host system must ensure the integrity of new depots before registering them and ensure that only trustworthy users are granted permission to insert on the host.
SD-UX Security Security Use Models Security Use Models The use models below use the swadm group that is provided in the default host ACLs, which are installed at SD-UX install-time. This group is not a part of the default HP-UX configuration, but can be easily added. First, add the swadm group and the appropriate group members by using the HP-UX System Administration Manager product. Next, provide the /etc/logingroup link to /etc/group to activate HP-UX supplementary groups.
SD-UX Security Security Use Models swacl -M swacl -M swacl -M -l host \ group:swadm@`hostname`:a @ -l global_soc_template\ group:swadm@`hostname`:a @ -l global_product_template group:swadm@`hostname`:a @ remsys1. . .remsysN remsys1. . .remsysN \ remsys1. . .remsysN You may want to grant permissions to specific users to manage particular products on the primary depot.
SD-UX Security Security Use Models user:swadm:rwict host:systemA.loc.company.com:r host:systemB.fc.hp.com:r Security for Software Developers Software developers iteratively package their products and test them before distribution. This involves packaging products into depots and installing them to Roots for testing. Since it may require several iterations to get all the customization right, it is not helpful to prevent software developers from having free access to depots and Roots for this testing.
SD-UX Security Permission Requirements, by Command Permission Requirements, by Command Packaging (swpackage) • If the depot does not exist, swpackage verifies that the user has insert permission on the target host. • swpackage verifies that the user has insert permission on a target depot. • swpackage verifies that the user has write permission on target product, if it already exists.
SD-UX Security Permission Requirements, by Command • The target agent verifies that the controller user has write permission on the target product, if it already exists. • The source agent verifies that the target agent system has read permission on 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 system each has insert permission on the source’s host.
SD-UX Security Permission Requirements, by Command Verify (swverify) • If the object is a product on a depot, the target agent verifies that the controller user has read permission on the target product. • If the object is a product on a root, the target agent verifies that the controller user has write permission on the target root (since scripts are executed).
Creating Software Packages 10 Creating Software Packages This chapter describes the tasks associated with packaging software for distribution.
Creating Software Packages Overview of the Packaging Process Overview of the Packaging Process To help you distribute software from depots, Software Distributor lets you package software into SD-UX format. The packaging process lets you create depots directly or create packages that you can add to depots later. The packaging specification is flexible enough to fit many software build and manufacturing process needs. The packaging process consists of the following tasks: 1. Identifying the package.
Creating Software Packages Identifying the Products to Package Identifying the Products to Package Determining Product Contents The first step in packaging software is to determine what files and directories you want included in the software product. These files and directories must follow certain guidelines to support the configuration you want.
Creating Software Packages Identifying the Products to Package purchases. The SD-UX commands maintain a product focus, while still allowing the flexibility to manage subsets of the products via subproducts and filesets. Bundles NOTE 304 (Optional) Bundles are provided only by the HP factory. Customer packaging of bundles is not supported. You can define different versions of products for different platforms and operating systems, as well as different revisions (releases) of the product itself.
Creating Software Packages Adding Control Scripts Adding Control Scripts SD-UX supports execution of product and fileset control scripts that allow you to perform additional checks and operations with other HP-UX commands and functions. The swask, swinstall, swconfig, swverify, and swremove commands each can execute one or more control scripts on the primary roots. You can write the scripts and include them in your software package.
Creating Software Packages Adding Control Scripts Request Requests an interactive response from the user as part of the installation or configuration process. (Executed by swask, swconfig, and swinstall.) Unconfigure Undoes configurations performed by configure scripts. (Executed by swconfig and swremove.) Unpostinstall Undoes a postinstall script in case swinstall must initiate recovery during the installation process. (Executed by swinstall.
Creating Software Packages Creating a Product Specification File (PSF) Creating a Product Specification File (PSF) SD-UX uses a Product Specification File (PSF) to define the physical product package. The PSF provides a “road map” that identifies the product according to its attributes, contents, compatibilities, dependencies and descriptions. The PSF drives the swpackage session. It describes how the product is structured and defines the attributes that apply to it.
Creating Software Packages Creating a Product Specification File (PSF) Product Specification File Examples Minimal PSF Here is an example of the minimum PSF, which includes only the required keywords. This PSF creates a product SD with fileset commands and contains one file, /usr/sbin/swcopy: product tag SD fileset tag commands file swcopy /usr/sbin/swcopy NOTE You must use an absolute path for the second file term in this minimum format.
Creating Software Packages Creating a Product Specification File (PSF) vendor_tag HP is_patch false title HP-UX Distributor number B2000A category_tag system_mgt description < data/descr.sd copyright < data/copyr.sd readme < data/README.sd machine_type * os_name HP-UX os_release ?.11.* os_version ? directory / is_locatable false # Specify a checkremove script that executes during the # swremove analysis phase. (This script prevents the # removal of the SD product and returns an ERROR.
Creating Software Packages Creating a Product Specification File (PSF) directory file file # (...Other file directory file file ./commands=/usr/sbin swinstall swcopy definitions can go here...) ./nls=/usr/lib/nls/C swinstall.cat swpackage.cat directory ./ui=/var/adm/sw/ui file * # (...Other file definitions can go here...) end # Commands # (...Other fileset definitions can go here...) # Manpage fileset definitions: fileset tag man title Manual pages for the SD-UX revision 2.05 directory .
Creating Software Packages Creating a Product Specification File (PSF) PSF Syntax Each SD-UX object (product, subproduct, filesets, and file) has its own set of attributes and each attribute has a keyword that defines it. Most attributes are optional; they do not all need to be specified in the PSF. Each attribute has its own specific requirements, but the following rules apply: • Keyword syntax is: keyword value • All keywords require one or more values, except as noted.
Creating Software Packages Creating a Product Specification File (PSF) Table 10-2 Keyword Keywords Used in the Product Specification File Value Max. Size in bytes Example Distribution Class distribution layout_version tag copyright description number title end revision_string tag_string multi_line_string multi_line_string one_line_string one_line_string 64 64 8K 8K 256 256 1.0 EXAMPLE_DEPOT < data/copyr.depot data/descr.
Creating Software Packages Creating a Product Specification File (PSF) Table 10-2 Keywords Used in the Product Specification File (Continued) Keyword Value Max.
Creating Software Packages Creating a Product Specification File (PSF) Table 10-2 Keywords Used in the Product Specification File (Continued) Keyword Value Max. Size in bytes Example Fileset Class fileset * tag ancestor architecture category_tag corequisite description exrequisite is_kernel is_patch is_reboot is_sparse machine_type os_name os_release os_version prerequisite * revision supersedes title end commands prod.oldfileset oldprod.fileset HP-UX_B.11.
Creating Software Packages Creating a Product Specification File (PSF) Table 10-3 Control File Attributes Keyword checkinstall checkremove configure control_file fix postinstall postremove preinstall preremove request unconfigure unpreinstall unpostinstall verify Type path_string path_string path_string path_string path_string path_string path_string path_string path_string path_string path_string path_string path_string path_string Size in Bytes 1K 1K 1K 1K 1K 1K 1K 1K 1K 1K 1K 1K 1K 1K Example .
Creating Software Packages Creating a Product Specification File (PSF) Differences between the two layout versions include the following: • The vendor specification is handled differently. For the current standard (layout_version=1.0), each vendor class definition is associated only with subsequent products or bundles that contain a vendor_tag attribute that matches the tag attribute within the vendor class definition. For the previous standard (layout_version=0.
Creating Software Packages Creating a Product Specification File (PSF) PSF Value Types With the exception of vendor-defined attributes (see “Vendor-Defined Attributes” on page 321), the values for each attribute keyword in your PSF must match one of the specific types discussed below. NOTE PSF syntax conforms to the layout_version=1.0 of the POSIX 1387.2 Software Administration standard. Previous versions of SD-UX supported the POSIX layout_version=0.8 syntax, which continues to be supported.
Creating Software Packages Creating a Product Specification File (PSF) • Each multi-line strings support all isascii characters. (Refer to the ctype(3) manpage.) It represent one or more paragraphs of text. It can be specified in-line, surrounded by double-quotes or read from a files. File entries must use this syntax: < filename • Example:
Creating Software Packages Creating a Product Specification File (PSF) 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 default permissions value for each file and directory defined in a fileset. The default values can be overridden in each file’s specific definition. The owner and group fields are of type tag_string. The uid and gid fields are of type unsigned integer.
Creating Software Packages Creating a Product Specification File (PSF) — 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.
Creating Software Packages Creating a Product Specification File (PSF) Product Specification File Semantics The following sections describe how to specify a PSF and defines keywords. Vendor-Defined Attributes You can create your own software attributes when packaging software. Vendor-defined attributes are noted during packaging or when modified with swmodify. You can list these attributes with swlist.
Creating Software Packages Creating a Product Specification File (PSF) distribution or depot Keyword that begins the distribution specification. Each keyword defines an attribute of the distribution depot or tape itself. All keywords are optional, even if a distribution specification is included in a PSF. layout_version PSF syntax conforms to the layout_version=1.0 of the POSIX 1387.2 Software Administration standard. Previous versions of SD-UX supported the POSIX layout_version=0.
Creating Software Packages Creating a Product Specification File (PSF) Vendor Specification The vendor attributes let you add a description to the PSF. The layout_version defined for the PSF file determines how vendor specifications are associated with products and bundles. If a layout_version is not defined or is defined as 1.0, vendor specifications will be associated with all subsequent products and bundles that define a matching vendor_tag attribute. If a layout_version of 0.
Creating Software Packages Creating a Product Specification File (PSF) Category Specification (Does not apply to layout version 0.8.) A software collection can contain a list of category objects that are used as a selection mechanism. Category objects are identified by the keyword “category” and contain additional information about the category. The category_tag attribute points to a particular category object and can appear anywhere within a product, bundle, subproduct, or fileset.
Creating Software Packages Creating a Product Specification File (PSF) Chapter 10 revision The revision information (release number, version). Determines which category object definition to maintain in a depot when a definition being installed or copied does not match a definition already in the depot with the same category tag. end An optional keyword that ends the specification. No value is required. If you place this keyword incorrectly in the PSF, the specification will fail.
Creating Software Packages Creating a Product Specification File (PSF) Product or Bundle Specification The product specification is a required class in the PSF. It lets you identify the product you are packaging. NOTE The layout_version keyword in the distribution class affects how category and vendor objects are associated with products and bundles. See “Selecting the PSF Layout Version” on page 315 and “Product Specification File Semantics” on page 321 for more information.
Creating Software Packages Creating a Product Specification File (PSF) product Required keyword that begins the product specification. tag The product’s identifier (short name). architecture The target system on which the product or bundle will run. Provides a human-readable summary of the four uname attributes (machine_type, os_name, os_release and os_version), which define the exact target system(s) the product supports. bundle Required keyword that begins the bundle specification.
Creating Software Packages Creating a Product Specification File (PSF) is_locatable Defines whether a product or bundle can be installed to any product directory, or whether it must be installed into a specific directory. The attribute can be set to true or false. If not defined, swpackage sets the default attribute to “false.” is_patch A boolean flag that identifies a software object as a patch. The default value is false.
Creating Software Packages Creating a Product Specification File (PSF) are multiple operating systems, use wildcards or the | symbol to separate them. The value is matched against a target’s uname -s or getconf _CS_KERNEL_BITS result. Chapter 10 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 there are multiple operating systems, use wildcards or the | symbol to separate them.
Creating Software Packages Creating a Product Specification File (PSF) Control Script Specification SD-UX supports execution of product and fileset control scripts that allow you to perform additional checks and operations with other HP-UX commands and functions. The swask, swinstall, swconfig, swverify, and swremove commands each can execute one or more control scripts on the primary roots.
Creating Software Packages Creating a Product Specification File (PSF) Fileset Specification The fileset specification is required in the PSF. Use filesets to group files together. A fileset specification looks like this: fileset tag manB ancestor OLDSD.MAN architecture HP-UX_B.11.00_32/64 category_tag manpg description
Creating Software Packages Creating a Product Specification File (PSF) ancestor A list of filesets that will match the current fileset when installed on a target system, if the match_target installation option is specified. Also designates an ancestor fileset to check for when patch_match_target is defined. category_tag A repeatable tag-based attribute identifying a set of categories of which the software object is a member. This is used as a selection mechanism and can be used independent of patches.
Creating Software Packages Creating a Product Specification File (PSF) is_reboot A value of true declares that the fileset requires a system reboot after installation. If this attribute is not specified, swpackage assumes a default value of false. is_sparse Indicates that a fileset contains only a subset of files in the base (ancestor) fileset and that the contents are to be merged with the base fileset. The default value is false.
Creating Software Packages Creating a Product Specification File (PSF) 334 os_name Defines the operating system(s) on which the files will run if a fileset architecture has been defined. (If not specified, swpackage assigns a value of *, meaning the files run on all operating systems.) If there are multiple operating systems, use wildcards or use the ’|’ character to separate them. This attribute should pattern match to the value of uname -s or getconf KERNEL_BITS on the supported target systems.
Creating Software Packages Creating a Product Specification File (PSF) Dependency Specification The swinstall, swcopy, swverify, and swremove commands recognize software dependencies. The default behavior for swinstall, for example, prevents an install unless all dependencies are met. The PSF specifies dependencies between filesets. Dependencies are defined within the fileset class definition. (See “Fileset Specification” on page 331.
Creating Software Packages Creating a Product Specification File (PSF) NOTE A dependency must always be specified using a software specification that starts with the product tag for the requisite software. You can specify multiple dependencies to define AND relationships between the dependencies (AND meaning that all dependencies must be satisfied). You can also define OR relationships using the or (|) character. The following rules apply: • White spaces are allowed around the OR character.
Creating Software Packages Creating a Product Specification File (PSF) File Specification Within a fileset specification, you can specify the following 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 or unpackageable file type.
Creating Software Packages Creating a Product Specification File (PSF) Default Permission Specifications By default, a destination file will inherit the mode, owner, and group of the source file. You can use the file_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]][-t type] file_permissions This keyword applies only to the fileset in which it is defined.
Creating Software Packages Creating a Product Specification File (PSF) • Set the same mode defaults, plus a uid and gid: file_permissions • -o 2 -g 2 Set the owner write permission in addition to the above: file_permissions • -u 222 -u 022 -o 2 -g 2 If you do not define file_permissions, swpackage uses the default value file_permissions -u 000 for destination file objects based on existing source files.
Creating Software Packages Creating a Product Specification File (PSF) Explicit File Specification You can explicitly specify the files to be packaged into a fileset. If you want to recursively include all files and directories, 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 the full source path and the absolute destination path must be specified for each file.
Creating Software Packages Creating a Product Specification File (PSF) During an installation, the owner attribute is used to set the owner name and uid, unless the owner name is not specified or is not defined in the target system’s /etc/passwd file. In this case, the uid attribute is used to set the uid. -g [group[,]][gid] This option defines the file’s group name and/or gid at its destination.
Creating Software Packages Creating a Product Specification File (PSF) Using Directory and File Keywords The following examples illustrate the use of the directory and file keywords. • Include all files under /build/hpux/mfg to be rooted under /usr: directory file • Include only certain files under /build/hpux/mfg/, to be rooted under /usr and /var/adm/sw: directory file file . . . directory file file file • /build/hpux/mfg=/usr sbin/swinstall sbin/swcopy /build/hpux/mfg=/var/adm/sw nls/swinstall.
Creating Software Packages Creating a Product Specification File (PSF) The user can specify multiple directory source[=destination] file * pairs to gather all files from different source directories into a single fileset. If you do not want to recursively include all files and directories, use the explicit file specification. The directory keyword must have been previously specified before the file * specification can be used. If not, swpackage generates an error.
Creating Software Packages Creating a Product Specification File (PSF) For example, suppose you wanted to specify all the files in a fileset which contained 100 files. All these files were to be recursively “discovered” and packaged 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, you don’t care if they get modified or deleted).
Creating Software Packages Packaging the Software (swpackage) Packaging the Software (swpackage) The swpackage command packages software products defined in a PSF into a depot. You can then use the software in the depot with other SD-UX commands. Overview Chapter 10 Features and limitations include: • Uses the PSF to organize files into products, subproducts, and filesets. • Can include control scripts and PSFs to further specify how to handle the software when installing it onto the target system.
Creating Software Packages Packaging the Software (swpackage) The swpackage Process The swpackage process includes up to four phases: Table 10-4 swpackage Process Phases I. Selection swpackage reads the PSF II. Analysis swpackage analyzes the packaging tasks and requirements before actually packaging the software to the target depot or tape. swpackage compares the software to be packaged against the target depot to make sure the packaging operation will be successful. III.
Creating Software Packages Packaging the Software (swpackage) Figure 10-1, “An Overview of the Packaging Process,” shows an overview of the swpackage session. Figure 10-1 An Overview of the Packaging Process Phase I: Selection When you run swpackage, you must specify a PSF and any other options you wish to include.
Creating Software Packages Packaging the Software (swpackage) Phase II: Analysis swpackage performs four checks during this phase: 1. Check for unresolved dependencies. For every fileset in each selected product, swpackage checks to see if a requisite of the fileset is not also selected or not already present in the target depot. Unresolved dependencies within the product generate errors. Unresolved dependencies across products produce notes. 2. Check your authorization to package (or re-package) products.
Creating Software Packages Packaging the Software (swpackage) 4. Performing Disk Space Analysis (DSA) swpackage verifies that the target depot has enough free disk space to package the selected products. Phase III: Build • If adequate disk space is available for the packaging operation to proceed, swpackage writes a note to the log file to note the impact on disk space. • An error results if the package will encroach into the disk’s minfree space.
Creating Software Packages Packaging the Software (swpackage) 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 ISO 9660 standard format is desired, a utility to perform this conversion would be necessary. This conversion is not supported by swpackage. Distribution tapes are created in tar format (although SD-UX commands can also read depots from cpio format tapes).
Creating Software Packages Packaging the Software (swpackage) Using swpackage swpackage Syntax swpackage [-p] [-v] [-V] [-C session_file] [-d directory|device] [-f software_file] [-s product_specification_file|directory] [-S session_file] [-x option=value] [-X option_file] [software_selections] [@ target_selection] Options and Operands -p Previews the specified package session without actually creating or modifying the depot or tape.
Creating Software Packages Packaging the Software (swpackage) -S session_file Run the command based on values saved from a previous installation session, as defined in session_file. See “Session Files” on page 61. -x option=value Sets a command option to value and overrides default values or a values in options files. See “Changing Command Options” on page 353. -X option_file Read session options and behaviors from option_file. See “Changing Command Options” on page 353.
Creating Software Packages Packaging the Software (swpackage) Changing You can change the behavior of this command by specifying additional Command Options command-line options when you invoke the command (using the -x option) or by reading predefined values from a file. The following table shows the options and default values that apply to swconfig.
Creating Software Packages Packaging the Software (swpackage) Output of Logfile Messages The log file /var/adm/sw/swpackage.log captures output from the swpackage session. • Message logging by default sends verbose messages to stdout. (Setting the verbose option to 0 reduces the amount of information in stdout.) • Message logging also sends errors and warnings to stderr. • No logfile messages are written in preview (-p) mode. • The logfile is equal to stdout plus stderr.
Creating Software Packages Packaging the Software (swpackage) * 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.
Creating Software Packages Packaging Tasks and Examples Packaging Tasks and Examples To package the software products defined in the PSF product.psf into the distribution depot /var/spool/sw and preview the task at the verbose level before actually performing it, type: swpackage -p -v -s product.psf @ /var/spool/sw Registering Depots Created by swpackage When a new depot is created by swpackage, it is not automatically registered with the local host’s swagentd daemon.
Creating Software Packages Packaging Tasks and Examples Creating and Mastering a CD-ROM Depot When swpackage creates a new depot or packages a new product, it always creates an ACL for the depot/product. If you were to create a depot and then master it onto a CD-ROM, the CD-ROM would contain all 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.
Creating Software Packages Packaging Tasks and Examples Compressing Files to Increase Performance The packaging process may pass large amounts of data back and forth over the network and might slow down network performance. The compress_files option can improve performance by first compressing files that are to be transferred. This performance gained depends on the type of files transferred. Binary files compress less than 50%, text files generally compress more.
Creating Software Packages Packaging Tasks and Examples swpackage checks and enforces the following permissions: 1. Can you create a new depot? Superuser Yes Other Yes, if the ACL for the local host grants the user “insert” permission, i.e. permission to insert a new depot into the host. If the proper permissions are not in place and the depot is a new one, swpackage terminates with an error. 2.
Creating Software Packages Packaging Tasks and Examples Other Yes, if the depot is a new one and you passed check #1 above or if the ACL for an existing depot grants you write permission, i.e. permission to write/change the contents of the depot (same as #2 above). If you are denied authorization to change an existing depot, and if the PSF specifies some depot-level attributes, then swpackage produces a warning message and does not change the depot attributes.
Creating Software Packages Packaging Tasks and Examples Repackaging or Modifying a Software Package 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 an existing fileset’s definition. • Running swpackage on the edited PSF, specifying the new/changed fileset on the command line: swpackage -s psf \ product.
Creating Software Packages Packaging Tasks and Examples • To get rid of the obsolete (renamed) filesets, use swremove: swremove -d product.old_fileset @ depot • You may want to swremove the product entirely before repackaging the changes: swremove -d product @ depot swpackage -s psf product @ depot Packaging In Place If you set the package_in_place option to true, swpackage packages each of the specified products such that the source files are not copied into the target depot.
Creating Software Packages Packaging Tasks and Examples Following Symbolic Links in the Source If you set the follow_symlinks option to true, swpackage follows every source file that is a symbolic link and include the file it points to in the packaged fileset. swpackage also follows each source directory that is a symbolic link, which affects the behavior of the file * keyword (recursive file specification).
Creating Software Packages Packaging Tasks and Examples Depots on Remote File Systems Because the swpackage analysis and build phases operate as the superuser, there are constraints on how swpackage creates, adds to, or modifies products on a depot that exists in an NFS-mounted file system. If the superuser does not have write permission on the remote file system, swpackage will be unable to create a new depot-it will terminate before the analysis phase begins.
Creating Software Packages Packaging Tasks and Examples Verifying the Software Package If swpackage created a depot rather than storing the package in an existing registered depot, you must register the depot with the swreg command. (See “Registering Depots Created by swpackage” on page 356.) After the depot is registered, you can verify it with the swverify command.
Creating Software Packages Packaging Tasks and Examples Writing to Multiple Tapes When you package products to a distribution tape, the media_capacity option defines the size of the tape media (in one million byte units). The default value for this option is media_capacity=1330, which is the size of an HP DDS tape. If the target tape is not a DDS tape, you must specify the media_capacity value.
Creating Software Packages Packaging Tasks and Examples Making Tapes from an Existing Depot You can copy one or more products from an existing depot to a tape using swpackage. Instead of specifying a PSF as the source for a packaging session, just specify an existing depot. For example: swpackage -s /var/spool/sw ...
Creating Software Packages Packaging Tasks and Examples 368 Chapter 10
Using Control Scripts 11 Using Control Scripts This chapter discusses how to use control scripts.
Using Control Scripts Introduction to Control Scripts Introduction to Control Scripts SD-UX supports execution of both product and fileset control scripts. These shell scripts allow you to perform additional, customized checks and operations as part your regular software management tasks. The swinstall, swconfig, swverify, swask, and swremove commands can execute one or more of these scripts. Control scripts are usually supplied by software vendors, but you can write your own.
Using Control Scripts Introduction to Control Scripts Types of Control Scripts Here are the control scripts that SD-UX supports: • Checkinstall Script This script is run by swinstall during its Analysis phase to insure that the installation (and configuration) can be attempted. For example, the OS run state, running processes, or other prerequisite conditions beyond dependencies could be checked. It should not change the state of the system.
Using Control Scripts Introduction to Control Scripts • Postinstall Script This script is run by swinstall after loading the software files. For example, this script could move a default file into place. The postinstall script is part of swinstall’s Load phase. After the files are loaded, the fileset’s postinstall script is run. Then, the products’s postinstall script (if any) is run. • Unpreinstall Script Unpreinstall scripts are executed during the load phase of swinstall if recovery is initiated.
Using Control Scripts Introduction to Control Scripts Product level unpostinstall scripts are not supported. NOTE • Configure Script This script is run by swinstall or by swconfig to configure the host for the software, or configure the software for host-specific information. For example, this script could change a host’s specific configuration file such as /etc/services, add the host name or other host resources such as available printers to its own configuration file, or perform compilations.
Using Control Scripts Introduction to Control Scripts • Fix Script Defines the fix script run by swverify to correct and report problems on installed software. The fix script can create missing directories, correct file modifications (mode, owner, group, major, and minor), and recreate symbolic links. • Unconfigure Script A script run by swconfig or swremove to undo a host or software configuration originally performed by a configure script.
Using Control Scripts Introduction to Control Scripts • Request Scripts This interactive script requests a response from the user as part of software installation or configuration. Request scripts write information into a response file for later use by the configure script or other scripts. You can run requests scripts by executing the swask command or using the ask option with swinstall or swconfig after selection and before the analysis phase.
Using Control Scripts Introduction to Control Scripts Script Interpreter By default, SD interprets scripts with a POSIX shell (sh). You can specify other script interpreters in two ways. First, any control script can define an interpreter in the first line of the script. Second, you can use the interpreter keyword to define a different interpreter for specific scripts.
Using Control Scripts Introduction to Control Scripts Control Script Format A control script should be a shell script (as opposed to a binary) and written to be interpreted by the Posix.2 shell /sbin/sh. Korn shell (formerly /bin/ksh) syntax is acceptable to the Posix.2 shell. A script written for csh is not supported. The script should have a simple header similar to the example below.
Using Control Scripts General Script Guidelines General Script Guidelines Here are some guidelines for writing control scripts: • Consider doing most control script work within the configure script. • All scripts are executed serially and directly impact the total time required 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 control script is not defined.
Using Control Scripts Packaging Control Scripts Packaging Control Scripts The following table describes the control script keywords for use in a PSF.
Using Control Scripts Packaging Control Scripts You can include control script specifications or data files with the product or fileset. These are stored alongside the standard SD-UX control scripts. For example, you could specify a subscript called by the supported control scripts, or a data file read by these scripts. These additional scripts are specified using the syntax: PATH[=tag] If you do not specify the tag component, swpackage uses the basename(1) value of the source pathname as the tag.
Using Control Scripts Using Environment Variables Using Environment Variables All control scripts are invoked as the superuser and executed by the agent process. HP-UX provides environment variables that affect SD-UX commands 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.
Using Control Scripts Using Environment Variables LC_MESSAGES • Determines the language in which messages should be written. LC_TIME • Determines the format of dates (create_date and mod_date) when displayed by swlist. Used by all utilities when displaying dates and times in stdout, stderr, and logging. TZ • Determines the time zone for use when displaying dates and times.
Using Control Scripts Using Environment Variables Here is an example of sourcing: . ${SW_CONTROL_DIRECTORY}subscript grep something ${SW_CONTROL_DIRECTORY}datafile SW_CONTROL_TAG • Holds the tag name of the control_file being executed. When packaging software, you can define a physical name and path for a control file in a depot. This lets you define the control_file with a name other than its tag and lets you use multiple control_file definitions to point to the same file.
Using Control Scripts Using Environment Variables SW_ROOT_DIRECTORY • Defines the root directory in which the session is operating, either “/” or an alternate root directory. This variable tells control scripts the root directory in which the products are installed. A script must use this directory as a prefix to SW_LOCATION to locate the product’s installed files. All control scripts (except for the configure and unconfigure scripts) can be executed during an install or remove task on an alternate root.
Using Control Scripts Using Environment Variables Variables That Affect swinstall and swremove SW_DEFERRED_KERNBLD • This variable is normally unset. If it is set, the actions necessary for preparing the system file /stand/system cannot be accomplished from within the postinstall scripts, but instead must be accomplished by the configure scripts. This occurs whenever software is installed to a directory other than /.
Using Control Scripts Using Environment Variables SW_SYSTEM_FILE_PATH • The path to the kernel’s system file. The default value is /stand/system. Variables That Affect swverify SW_IS_COMPATIBLE 386 • Designed to help you determine if installed software is incompatible and should be removed from a system. • For use during the execution of a verify script, which is called by the swverify command.
Using Control Scripts Execution of Control Scripts Execution of Control Scripts This 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 root directory. Scripts are never executed for software in a depot.
Using Control Scripts Execution of Control Scripts • The set of control scripts executed during a particular phase of a task are always executed in prerequisite order the scripts of each prerequisite product/fileset are executed before the script of the dependent 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.
Using Control Scripts Execution of Control Scripts Preinstall Scripts • Preinstall scripts are executed during the Load phase of a swinstall session. The pathname of the script being executed is: $ {SW_CONTROL_DIRECTORY}preinstall • The preinstall script for a product is executed immediately before the fileset’s files are installed. • A preinstall script should perform specific tasks preparatory to the files being installed.
Using Control Scripts Execution of Control Scripts Configure Scripts • Configure scripts are executed during the Configuration phase of a swinstall session. SD expects configure scripts at system start-up if the swinstall session triggers a system reboot. The swconfig command can also execute configure scripts. The pathname of the script being executed is: $ {SW_CONTROL_DIRECTORY}configure 390 • A configure script is only executed for installations into the primary root (“/”).
Using Control Scripts Execution of Control Scripts Unconfigure Scripts • Unconfigure scripts are executed during the Unconfiguration-Configuration phase of a swremove session. They can also be executed by the swconfig command. The pathname of the script being executed is: $ {SW_CONTROL_DIRECTORY}unconfigure • An unconfigure script is executed only for software installed into the primary root (“/”). • An unconfigure script is re-executed even when the product/fileset is in the configured state.
Using Control Scripts Execution of Control Scripts Fix Scripts • Fix scripts are executed by the swverify command. The pathname of the script being executed is: $ {SW_CONTROL_DIRECTORY}fix • A fix script can be used to correct attribute problems detected by a verify script. • A fix script can create missing directories, correct file modifications (mode, owner, group, major, and minor), and recreate symbolic links.
Using Control Scripts Execution of Control Scripts Preremove Scripts • Preremove scripts are executed during the Remove phase of a swremove session. The pathname of the script being executed is: $ {SW_CONTROL_DIRECTORY}preremove • All preremove scripts for a product are executed immediately before the product’s files are removed. • A preremove script should perform specific tasks preparatory to the files being removed.
Using Control Scripts Execution of Control Scripts • A postremove script is executed for installations into the primary root (“/”) and an alternate root. The scope of actions of a postremove script should be within the product itself (that is, the files within the product’s directory).
Using Control Scripts Execution of Control Scripts — 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 the missing response file.
Using Control Scripts Execution of Other Commands by Control Scripts Execution of Other Commands by Control Scripts Every command executed by a control script is a potential source of failure because the command may not exist on the target system. Your script can use any command conditionally, if it checks first for its existence and executability, and if it does not fail when the command is unavailable. 396 • If the target system(s) conform with the POSIX 1003.
Using Control Scripts Control Script Input and Output Control Script Input and Output • 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 the agent on the target systems. Request scripts are executed by the controller (swinstall, swconfig, or swask). • Except for request scripts, no method of input to control scripts is supported.
Using Control Scripts Control Script Input and Output 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. WARNING: The "unconfigure" script for "PRODUCT.FILESET" failed (exit code "2").
Using Control Scripts Control Script Input and Output 4. If the message text requires more than a single 72-character line, break it into several 72-character lines. Indent all lines after the first. For example: NOTE: To install your new graphics package, you must turn on the lights in the next room. Please turn them off when you leave. 5. Do not use tab characters in any messages. • Scripts execute other commands which may unexpectedly fail and emit output not in the above format.
Using Control Scripts Control Script Input and Output — Write messages that make sense to system administrators and users. Consider your audience.
Using Control Scripts File Management by Control Scripts File Management by Control Scripts • All files created by a preinstall, postinstall, or configure script must be removed by a companion postremove, preremove or unconfigure script. Files created by scripts are not known by the swremove command, and will not get removed when it removes those files installed by swinstall.
Using Control Scripts Testing Control Scripts Testing Control Scripts The following testing suggestions do not cover all test scenarios. There may still be problems with a control script even after doing this testing. For example, you may test installing/removing individual filesets. But there might be some interactions that are discovered only after all the filesets are installed on or removed from the system.
Using Control Scripts Testing Control Scripts 4. If your checkinstall script can generate error or warning conditions based on the current activity or configuration of the target system, then enable those conditions to ensure that the checkinstall script correctly detects them. 5. Re-run the test by installing into an alternate root directory (swinstall -r) instead of the primary root directory (“/”). Make sure that the scripts perform all of their operations (if any) within the alternate root directory.
Using Control Scripts Testing Control Scripts 2. Run swremove to remove the configured product. • After the unconfiguration and removal completes, check the ${SW_ROOT_DIRECTORY}var/adm/sw/swagent.log file for any problems, either in the unconfigure script or the format/contents of the messages generated by it. • Study the resulting file system to see if the unconfigure script performed the expected “undo” actions. 3. Run swinstall to install the full product again.
Using Control Scripts Testing Control Scripts 7. If your product is locatable (that is, it can be installed into a different location), then re-run the tests by installing and configuring the product in a different location. Make sure that the scripts perform all their operations in the new location, and not the default location. (This verifies the correct use of $SW_LOCATION by your scripts.) 8.
Using Control Scripts Testing Control Scripts 3. If your checkremove script can generate error or warning conditions based on the current activity or configuration of the target system, then enable those conditions to ensure that the checkremove script correctly detects them. 4. Re-run the first test by installing into an alternate root directory (swinstall -r) instead of the primary root directory (“/”).
Using Control Scripts Requesting User Responses (swask) Requesting User Responses (swask) SD-UX packaged applications can use interactive control scripts to query a user and obtain installation or configuration information that cannot be known at package time. For example, different hardware or OS versions may require different configuration, or some software may need a specific IP address or hostname for configuration.
Using Control Scripts Requesting User Responses (swask) -C session_file Run the command and save the current option and operand values to a session_file for re-use in another session. See “Session Files” on page 61. -f software_file Read a list of software selections from a separate file instead of (or in addition to) the command line. See “Software Files” on page 58. -S session_file Run the command based on values saved from a previous installation session, as defined in session_file.
Using Control Scripts Requesting User Responses (swask) Changing You can change the behavior of this command by specifying additional Command Options command-line options when you invoke the command (using the -x option) or by reading predefined values from a file. The following table shows the options and default values that apply to swconfig.
Using Control Scripts Request Script Tasks and Examples Request Script Tasks and Examples You can run request scripts from the swinstall or swconfig commands by setting the ask option to true. This tells the commands to run request scripts (if any exist) in addition to performing install or configuration tasks. (Note that the value of the ask option if false for both swinstall and swconfig but is true for swask.
Using Control Scripts Request Script Tasks and Examples To install all products in remote depot /tmp/sample.depot.1 on host swposix, use any response files generated by request scripts, create catalog /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.
Using Control Scripts Request Script Tasks and Examples 412 Chapter 11
Nonprivileged SD 12 Nonprivileged SD This chapter provides general guidelines on how to set up Software Distributor to run in nonprivileged mode.
Nonprivileged SD Overview Overview The nonprivileged mode of SD-UX lets users access application software based on their file system permissions rather than super-user privilege implemented by SD-UX ACLs. Nonprivileged mode is honored by almost all SD commands. You can use nonprivileged mode for all aspects of developing, distributing, and managing applications.
Nonprivileged SD Overview Limitations Chapter 12 • Remote targets are not allowed with SD-UX remote operations, except for swlist access to remote systems and commands that can normally access remote depots. Access to such remote systems is determined by the SD ACLs on the remote system. • Nonprivileged mode cannot be used to manage HP-UX operating system software or patches to it.
Nonprivileged SD Setting Up Nonprivileged Mode Setting Up Nonprivileged Mode Nonprivileged SD is controlled by two options: • admin_directory • run_as_superuser The run_as_superuser option turns nonprivileged mode on or off and is all that is necessary to run the default configuration. (See “Turning On Nonprivileged Mode” on page 417 and “Default Configuration” on page 418.) The admin_directory option lets you set up an alternative configuration. (See “Alternative Configuration” on page 419.
Nonprivileged SD Setting Up Nonprivileged Mode Turning On Nonprivileged Mode SD functions in nonprivileged mode only when the run_as_superuser option is set to false and the invoking user is not super-user. This option applies to all SD-UX commands except swagent, swagentd, swjob, and install-sd. When you set this option to false, any command to which it applies will run in nonprivileged mode.
Nonprivileged SD Default Configuration Default Configuration The default configuration of nonprivileged mode is to have a central location for user-installed software catalogs. When the run_as_superuser option is false and the admin_directory option is not set, SD-UX logfiles and installed software catalogs are stored in user-specific directories at /var/home/USER_NAME/sw (where USER_NAME is replaced by the invoking user name).
Nonprivileged SD Alternative Configuration Alternative Configuration An alternative configuration of nonprivileged mode sets up user-installed software catalogs in each user’s home directory. You can use the admin_directory option in /var/adm/sw/defaults to indicate a path beginning with HOME or /HOME, so that the default administration directory used by SD-UX during nonprivileged mode is in each user’s home directory. (A value of HOME/.sw works well for this purpose.
Nonprivileged SD Alternative Configuration 420 Chapter 12
Command Options A Command Options This appendix reviews the basics of altering SD-UX command options and provides an alphabetic list of all options and their default values.
Command Options Changing Command Options Changing Command Options Changing the option values lets you change command behavior and tailor SD-UX policies to your needs. You can change options using predefined files, values you specify directly on the command-line, or the GUI Options Editor from the Options menu. Altering option values using files can help when you don’t want to specify command behavior every time you invoke the command.
Command Options Changing Command Options Option files use the syntax: [command.]option=value • The optional command is the name of a SD-UX command. Specifying a command name changes the default behavior for that command only. A period must follow a command name. • option is the name of the default option. An equals sign must follow the option name. • value is one of the allowable values for that option. NOTE Use caution when changing default option values.
Command Options Options Listed Alphabetically Options Listed Alphabetically • admin_directory=/var/adm/sw (for normal mode) admin_directory=/var/home/LOGNAME/sw (for nonprivileged mode) The location for logfiles and the default parent directory for the installed software catalog. The default value is /var/adm/sw for normal operations.
Command Options Options Listed Alphabetically • agent_auto_exit=true Causes the target agent to automatically exit after execute phase, or after a failed analysis phase. This is forced to false when the controller is using an interactive UI, or when -p (preview) is used. Enhances network reliability and performance. The default is true. The target agent automatically exits when appropriate. If set to false, the target agent does not exit until the controller explicitly ends the session.
Command Options Options Listed Alphabetically • allow_incompatible=false Normally set to false, only software compatible with the local host is allowed 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 into a different location) are disallowed.
Command Options Options Listed Alphabetically When set to the default value of false, installation or copy of a single fileset from a multi-fileset patch automatically includes other, “sibling” filesets that are appropriate, based on the target’s ancestor attributes. This behavior applies to any filesets you select directly and to filesets automatically selected to meet dependencies for a patch filesets.
Command Options Options Listed Alphabetically false (Default for swinstall and swconfig.) Does not execute request scripts. as_needed Before executing a request script, swask first determines if a response file already exists and executes the request script only if the response file is absent from the control directory. See “Requesting User Responses (swask)” on page 407 for more information on the swask command and writing request scripts. Applies to swask, swconfig, and swinstall.
Command Options Options Listed Alphabetically If set to true, all files are saved as backup copies until the current fileset finishes loading. If an error occurs during installation, the fileset’s original files are restored, and swinstall continues to the next fileset in the product or the product postinstall script. When set to true, this option also affects scripts. For example, if a preinstall script fails, this option causes the corresponding unpreinstall script to execute. Applies only to swinstall.
Command Options Options Listed Alphabetically • autoselect_dependencies=true Causes SD-UX to automatically select requisites when software is being selected. At the default value of true, dependent software is automatically selected when you select software with requisites. If set to false, automatic selections are not made to resolve requisites. Applies to swconfig, swcopy, swinstall and swverify.
Command Options Options Listed Alphabetically • check_contents=true Normally set to true, verify mtime, size and cksum of files. If false, the software can be installed without the bundle that contains it. Applies only to swverify. • check_contents_uncompressed=false When a file is compressed, SD-UX uses it with check_contents and check_contents_use_cksum to determine whether or not to compute and verify the uncompressed checksum and size of a compressed file.
Command Options Options Listed Alphabetically • check_requisites=true Normally set to true, verify that the prerequisites and corequisites of filesets are being met. Applies only to swverify. • check_scripts=true Normally set to true, run the vendor-supplied verify scripts when verifying software. Applies only to swverify. • check_volatile=false When set to true, swverify verifies installed files that have the is_volatile attribute set.
Command Options Options Listed Alphabetically If set to true during swcopy or swpackage, the resulting depots are smaller, unless you also set uncompress_files to true. Applies to swcopy, swinstall and swpackage. • compress_index=false Enhances performance on slower networks, although it may increase disk space usage due to a larger Installed Products Database and depot catalog. The default of false does not compress INDEX and INFO files. When set to true, INDEX and INFO files are compressed.
Command Options Options Listed Alphabetically • control_files= When adding or deleting control file objects, this option lists the tags of those control files. There is no supplied default. (Control file objects being added can also be specified in the given product specification file.) If there is more than one tag, they must be separated by white space and surrounded by quotes. Applies only to swmodify.
Command Options Options Listed Alphabetically • create_target_path=true Normally set to true, creates the target directory if it does not already exist. If false, target directory is not created. This option can be used to avoid creating new depots by mistake. Applies to swcopy and swinstall. • create_time_filter=0 Controls time settings for cumulative source depots.
Command Options Options Listed Alphabetically — SD-UX ignores this option (treats it as true) when it installs software that causes a system reboot. — Alternate root directories are not configured. Applies only to swinstall • distribution_source_directory=/var/spool/sw Defines the default source depot when the value for the source_type option is directory. You can also use the host:path syntax. The -s option overrides this default. Applies to swcopy, swinstall, and swpackage.
Command Options Options Listed Alphabetically • enforce_dsa=true When set to the default value of true, SD-UX does not proceed if the disk space required for a software operation is more than the available free space. You can use this option to allow installation into minfree space, or to attempt an install, copy, or package operation even though it may fail because the disk reaches its absolute limit.
Command Options Options Listed Alphabetically was successful. Where appropriate, the message identifies the phase in which the error occurred (configure/unconfigure, preinstall/postinstall, preremove/postremove, etc.). Applies to swask, swconfig, swinstall and swremove. • files= When adding or deleting file objects, this option can list the path names of those files. There is no supplied default. File objects being added can also be specified in the given product specification file.
Command Options Options Listed Alphabetically When this option contains a relative path, the controller appends the path to the path specified by the admin_directory option to determine the path to the IPD. For alternate roots, this path is resolved relative to the location of the alternate root. (This option does not affect where software is installed, only the IPD location.
Command Options Options Listed Alphabetically • kernel_path=/stand/vmunix The path to the system’s bootable kernel. It is passed to the kernel_build_cmd via the SW_KERNEL_PATH environment variable. Applies only to swagent. • layout_version=1.0 Specifies the POSIX layout version to which the SD-UX commands conform when writing distributions and swlist output. Supported values are 1.0 (default) and 0.8. SD-UX for HP-UX version 11.10 and later can read or write either version.
Command Options Options Listed Alphabetically • level= Specifies a software level for swacl, swlist and swreg. For swlist, this option lists all objects down to the specified level. Both the specified levels and the depth of the specified software_selections control the depth of the swlist output. The supported software levels are: — bundle -- show all objects down to the bundle level. — product -- show all objects down to the product level. Also use -l bundle -l product to show bundles.
Command Options Options Listed Alphabetically — product -- view or modify the ACL protecting the software product identified by the software_selection. Applies only to products in depots, not installed products in roots — product_template -- view or modify the template ACL used to initialize the ACLs of future products added to the software depots identified by the target_selections.
Command Options Options Listed Alphabetically • logdetail=false Controls the amount of detail written to the log file. When set to true, this option adds detailed task information, such as options specified, progress statements, and additional summary information, to the log file. Table A-1 shows the possible combinations of loglevel and logdetail options.
Command Options Options Listed Alphabetically • logfile=/var/adm/sw/.log This is the default controller log file for each command. The agent log files 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.
Command Options Options Listed Alphabetically • max_targets=25 When set to a positive integer, this option limits the number of concurrent install or copy operations to the number specified. As each copy or install operation completes, another target is selected and started until all targets are completed. Server and network performance determines the optimal setting; a recommended starting point is 25 (the default value).
Command Options Options Listed Alphabetically • mount_all_filesystems=true Normally set to true, the commands automatically try to mount all file systems in the file system table (/etc/fstab) at the beginning of the analysis phase and make sure that all those file systems are mounted before proceeding. When set to false, no additional file systems are mounted. Applies to swconfig, swcopy, swinstall, swremove, swverify.
Command Options Options Listed Alphabetically • os_name Specifies fileset selection for an HP-UX update. (This option should always be used with the os_release option.) You must specify this option 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, such as HP-UX. See the uname(1) manual page for complete information.
Command Options Options Listed Alphabetically • patch_commit=false Commits a patch by removing files saved for patch rollback. The default value is false. When set to true, this option removes the saved files for the patches specified in the software selections for the command. Once you have run this option on a patch, you cannot remove the patch unless you remove the associated base software that the patch modified. Applies only to swmodify. • patch_filter=*.
Command Options Options Listed Alphabetically • patch_save_files=true Saves patched files, which permits future rollback of patches. When set to false, patches cannot be rolled back (removed) unless the base software modified by the patch is removed at the same time. Applies to swinstall. • polling_interval=2 Applies only to interactive sessions. Specifies how often, in seconds, SD-UX polls each target for status information during the analysis and execution phases.
Command Options Options Listed Alphabetically • reconfigure=false This option prevents software that is already in the configured state from being reconfigured. If set to true, configured software can be reconfigured. Applies to swconfig. • 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.
Command Options Options Listed Alphabetically • reinstall_files_use_cksum=true reinstall_files_use_cksum=false (swpackage only) Controls the use of checksum comparisons when the reinstall_files option is set to false. The default value of true causes SD-UX to compute and compare checksums to determine if a new file should overwrite an old file. Use of checksums slows the comparison but is a more robust check for equivalency than size and time stamp.
Command Options Options Listed Alphabetically • retry_rpc=1 This command defines the number of times a lost source connection is retried during file transfers. If set from 1 to 9, the install of each fileset is attempted that number of times. The reinstall_files option should also be set to false to avoid installing files that were successfully installed within the fileset. This option also applies to the controller contacting the agent.
Command Options Options Listed Alphabetically • reuse_short_job_numbers=true When assigning job ID numbers, SD-UX uses numbers less than 10,000. Typically, old jobs are removed long before job number 9,999 is reached, so the job number quickly rolls over from 9999 back to 1. When you execute a large numbers of jobs that are not removed before the ID numbers reach 9,999, SD-UX may have performance delays while it searches for unused job numbers.
Command Options Options Listed Alphabetically • rpc_binding_info_alt_source=ncadg_ip_udp:[2121] Defines the protocol sequence(s) and endpoint(s) used when the agent attempts to contact an alternate source depot specified by the alternate_source option. SD-UX supports both the udp(ncadg_ip_udp:[2121]) and tcp(ncacn_ip_tcp:[2121])protocol sequence/endpoint. Applies to swagent. • rpc_timeout=5 Relative length of the communications timeout.
Command Options Options Listed Alphabetically Nonprivileged mode is intended only for managing applications that are specially designed and packaged. This mode cannot be used to manage the HP-UX operating system or patches to it. This option is not compatible with remote operations. Setting this option to true forces the autoremove_job option to true. For a full explanation of nonprivileged SD-UX, see Chapter 12, “Nonprivileged SD,” on page 413. See also the admin_directory option.
Command Options Options Listed Alphabetically • source= Specify a source to automatically bypass the GUI and CLI source selection dialog box. This has the same effect as the -s source command line option. Specify the source using the following syntax: [path] Applies to swcopy and swinstall. • source_cdrom=/SD_CDROM Defines the default location of the source CD-ROM. The syntax is: [host][:][path] Applies only to swinstall.
Command Options Options Listed Alphabetically • source_file=psf This keyword defines the default product_specification_file to read as input to the packaging or swmodify session. It may be a relative or absolute path. Applies to swpackage and swmodify. • source_tape=/dev/rmt/0m Defines the default tape location, usually the character-special file of a local tape device. You can also use the host:path syntax, but the host must match the local host. The -s option overrides this value.
Command Options Options Listed Alphabetically • target_type See media_type. • uncompress_cmd= This is the command called by the source agent to uncompress files when installing, copying or packaging. This command processes files that were stored on the media in compressed format. If the compression_type of the file is gzip, the internal compression (funzip) is used instead of the external uncompress command. Applies to swagent and swpackage.
Command Options Options Listed Alphabetically • verbose= By default, the command sends output to stdout for task summary messages. Alternatively, the verbose option can be set to 0 for session level messages (no output to stdout) or (for swpackage and swmodify) to 2 for file level messages. Error and warning messages are always written to stderr. For the swlist command, a verbose listing includes all attributes that have been defined for the appropriate level of each software_selection operand.
Command Options Options Listed Alphabetically 460 Appendix A
Troubleshooting B Troubleshooting This appendix explains how SD-UX error messages are used, reviews the SD-UX error logging process. lists common problems you might encounter, and suggests how to resolve them.
Troubleshooting Error Logging Error Logging All SD-UX commands (except swlist and swacl) log error messages, summary information about the session, and operation details to a command-specific logfile located (by default) in /var/adm/sw/.log. For example, if you wanted to examine the logfile for swinstall, you would look in the file /var/adm/sw/swinstall.log. You can also examine target agent logfiles for a current session from the swinstall, swcopy, or swremove GUIs.
Troubleshooting Error Logging Error Messages SD-UX error messages indicate that a problem occurred that will influence the overall outcome of an operation. For example, if a target in an install session fails the analysis phase due to insufficient disk space, you would find the following error message in the agent log file: ERROR:The estimated disk space used on filesystem "/" is 14104 Kbyte blocks. This operation will exceed the minimum free space for this disk.
Troubleshooting Common Problems Common Problems This section presents a selection of problems you might encounter and how to resolve them: Table B-2 Common Problems Problem Cannot contact target host’s daemon or agent GUI won’t start or missing support files Access to an object is denied Slow network performance Connection timeouts and other WAN problems Disk space analysis is incorrect The packager fails Daemon logfile is too long Cannot read a tape depot Installation fails swinstall or swremove fails wi
Troubleshooting Common Problems Cannot Contact Target Host’s Daemon or Agent If you see the following error message: ERROR: Could not contact host . Make sure the hostname is correct. it means that the hostname you specified could not be found in the hosts database. Make sure you have typed the hostname correctly (you can use the nslookup command to verify hostnames).
Troubleshooting Common Problems Other possible causes for this problem are listed in the section “Connection Timeouts and Other WAN Problems” on page 472. TIP An easy way to determine if a target system has the SD-UX daemon installed and running is to type: /usr/sbin/swlist -l depot @ which will attempt to contact each target to get a list of registered depots. Those targets which have the SD-UX daemon installed will report either: # Initializing...
Troubleshooting Common Problems GUI Won’t Start or Missing Support Files You can start the GUI in these ways: • For swinstall, swcopy, or swremove, type the command with no additional options or arguments. • Include the -i option with any other options and arguments when you type the command on the command line. (Required for swlist.) • For the Job Browser, type sd on the command line.
Troubleshooting Common Problems Access To An Object Is Denied Denial of access to SD-UX objects may have a number of causes, including: Resolution • ACL permissions • Inter-host secrets • Working with image copies of depots Generally, when SD-UX denies access to an object, a message tells you that you do not have the required access permission. Yet, it may be unclear which object is not accessible.
Troubleshooting Common Problems Do Not Modify ACL Files Without swacl Since SD-UX stores ACLs in the file system as plain text files, you may try to edit them with a conventional editor. This can lead to unexpected corruption of the ACL. Most cases of this corruption simply result in a message indicating the corruption, but inserting additions to the ACL file without updating the num_entries value can result in unreported problems and cause SD-UX to deny access.
Troubleshooting Common Problems example, attempts to add local users to the access list will, in fact, grant access to remote users. There is no way to alter the default realm of an ACL from that set when it is created. Another common problem with such images occurs if you import them to systems that cannot resolve all the hostnames (see resolver(4) and nslookup(1)) that exist in the ACLs. If your purpose is to create a “staged” installation, use swcopy to propagate the depot.
Troubleshooting Common Problems Slow Network Performance When using swinstall or swcopy in an environment where network bandwidth is the “bottleneck,” the file transfer rate between source and target can become very slow. Resolution The compress_files=true option compresses files transferred from a source depot to a target. This can reduce network usage by approximately 50%; the exact amount of compression depends on the type of files. Binary files compress less than 50%, text files more.
Troubleshooting Common Problems Connection Timeouts and Other WAN Problems Low-throughput, wide-area networks can cause SD-UX to encounter time-out problems when establishing and maintaining network connections with remote agents on other systems. If you see the following messages: ERROR:A Remote Procedure Call to a daemon has failed. Could not start a management session for . Make sure the host is accessible from the network, and that its daemon, swagentd, is running.
Troubleshooting Common Problems Another factor that can affect RPC timeouts on a slow network is the choice of network protocol. SD-UX supports both UDP- and TCP-based communication (the default is TCP). TCP communication is more reliable on a WAN because it is connection-based. SD will fall back to a UDP connection if the TCP connection fails for some reason. The default binding can be set with the -x rpc_binding_info option.
Troubleshooting Common Problems Disk Space Analysis Is Incorrect Your installation or copy operation runs out of space even though the disk space analysis succeeded. Upon further checking, you find that the results of the disk space analysis differ from the actual space available. Resolution Possible causes of this problem: • A control script associated with the installation has consumed disk space by creating or copying additional files that aren’t accounted for during analysis.
Troubleshooting Common Problems Command Logfile Grows Too Large If you want to reduce the contents of a SD-UX command logfile, follow this procedure: Resolution To reduce messages to a minimum, set the verbose command option to 0 in one of the option files or by using the -x option on the command line. For example, entering -x spackage.verbose=0 on the command line when you run swpackage would reduce the number of entries to the swpackage log to a minimum.
Troubleshooting Common Problems Cannot Read a Tape Depot If you are trying to access a tape depot and see the following error message in the daemon logfile, it means that the tape is either corrupt or is not in SD-UX format. ERROR:The INDEX file on the source did not exist or could not be read. ERROR:The target could not be opened. Resolution Make sure that you have correctly specified the tape device and that the correct tape is in the drive. SD-UX only reads tapes that are in SD-UX format.
Troubleshooting Common Problems Swinstall or Swremove Fails With a Lock Error Swinstall or swremove fails with the following message: Cannot lock “/” because another command holds a conflicting lock. The process id of that command is ####. Resolution Appendix B Another SD command is running that prevents the swinstall or swremove command from running. Wait for that command to finish and try again.
Troubleshooting Common Problems 478 Appendix B
Replacing or Updating SD-UX C Replacing or Updating SD-UX This appendix describes how to replace or update SD-UX using the install-sd command.
Replacing or Updating SD-UX Re-installing SD-UX Re-installing SD-UX The software product called SW-DIST provides all SD-UX functionality, commands, and tools. This product is included on your HP-UX 11i media. If the files that make up SW-DIST are deleted or corrupted, you may need to re-install the product. The install-sd command lets you install the SD-UX product from HP-UX 11i media or a depot. This command also installs any SD-UX patches that exist in the source depot.
Replacing or Updating SD-UX Re-installing SD-UX Using install-sd Syntax install-sd -s source_depot_location Options and Operands The source_depot_location option specifies an absolute path to the source media location.
Replacing or Updating SD-UX Replacing an Unusable Version of SD-UX Replacing an Unusable Version of SD-UX If the version of SD-UX on the target system is unusable, you must first load install-sd and the swagent.Z file onto your system into /var/tmp, then use install-sd to re-install SW-DIST. The install-sd utility ships in the catalog/SW-DIST/pfiles directory.
Replacing or Updating SD-UX Installing a Newer Version of SD-UX Installing a Newer Version of SD-UX If you want to install a newer version of SD-UX on your system and/usr/sbin/install-sd is not yet on your system, use this procedure. (In both steps, source_depot_location is the absolute path to the depot or media that contains the newer version of SD-UX.) Step 1. As root, enter: /usr/sbin/swinstall -r -s \ source_depot_location\SW-DIST.SD-UPDATE \ @ /var/adm/sw/install-sd.root 2>/dev/null Step 2.
Replacing or Updating SD-UX Installing a Newer Version of SD-UX 484 Appendix C
Software Distributor Files and File System Structure D Software Distributor Files and File System Structure This chapter contains information on key Software Distributor files. For additional information, refer to the following manual reference pages: Table D-1 sd(5) For most current information on Software Distributor files sd(4) For file layouts of all Software Distributor files. swpackage(4) For file layouts of Software Distributor files created during packaging.
Software Distributor Files and File System Structure Agent File System Structure Agent File System Structure The agent component is organized as follows: Table D-2 486 Agent Component /dev/rmt/Om Default location of the target tape device file /usr/contrib/bin Location of the gzip executables used in file compression /usr/lbin/swagent The SD-UX agent /usr/lbin/sw Directory containing utilities used by swinstall and swremove /usr/lbin/sw/control_utils File containing common utilities used by SD c
Software Distributor Files and File System Structure Agent File System Structure Table D-2 Agent Component (Continued) /var/adm/sw/host_object_np List of depots registered at the local host during nonprivileged mode /var/adm/sw/products The Installed Products Database (IPD), a series of files and subdirectories that contain information about all products installed under the root (/) directory /var/adm/sw/queue Directory that contains the Jobs database.
Software Distributor Files and File System Structure Agent File System Structure Table D-2 488 Agent Component (Continued) /var/adm/sw/tmp Directory for temporary files /var/home/USER_NAME Default location for admin_directory during nonprivileged mode $HOME/.swdefaults File containing user-specified default values. If this file does not exist, Software Distributor looks for user-specific defaults in $HOME/.
Software Distributor Files and File System Structure Software Distributor Controller File System Structure Software Distributor Controller File System Structure The controller file system structure is comprised of all files in agent (see “Agent File System Structure” on page 486) plus the following files: Table D-3 Appendix D Controller File System Structure /usr/lib/sw/help Directory that contains the help files for on-line help /usr/lib/sw/ui Directory that contains the description files used by the
Software Distributor Files and File System Structure Installed Products Database Installed Products Database Software Distributor commands keep track of installations, products, and filesets on the system with the Installed Product Database (IPD). Located in the directory /var/adm/sw/products, the IPD is a series of files and subdirectories that contain information about all the products that are installed under the root directory (/).
Glossary NOTE: A glossary term appears in boldface when defined for the first time in the text of this manual. Italicized terms in the following glossary refer to other terms in the glossary. A Access Control Lists (ACL) A structure attached to a software object that defines access permissions for multiple users and groups. It extends the permissions defined by the HP-UX file system’s mode bits by letting you specify the access rights of many individuals and groups instead of just one of each.
Glossary Authorization Authorization In SD-UX security, checking that a user has the necessary permissions to perform a specific action, as defined by an Access Control List. B Base software Software that will be modified by a patch. Building phase Packaging the source files and information into a product, and creating/merging the product into the destination depot/media. Bundles A collection of filesets that are encapsulated for a specific purpose.
Glossary Corequisite Command line options Optional parameters for a command entered with the command itself at the HP-UX command line prompt. See also default options. Command Line User Interface (CLI/CLUI) Text-formatted commands and options entered at an HP-UX command line prompt or executed by a script. SD-UX also has a Graphical User Interface (GUI) and a Terminal User Interface (TUI) for the sd, swinstall, swcopy, swlist, and swremove commands.
Glossary Critical Fileset Critical Fileset A fileset containing software critical to the correct operation of the host. Critical filesets are those with the reboot and/or kernel fileset flags. During swinstall’s load phase, critical filesets are loaded and customized before other filesets. Cumulative patch See superseding patch. D Daemon The SD-UX program that schedules the agent to perform software management tasks. On a SD-UX controller, the daemon polls the job queue for scheduled jobs.
Glossary Incompatible Software Developer Host A system where software application files are placed for further integration and preparation for distribution. You may use a developer host to assemble, organize, and create product tapes or depots. Description An attribute for products and filesets, usually a paragraph description of that product or fileset. Details Dialog In the GUI or TUI, a dialog box that lets you get more information about a specific process to monitor its progress.
Glossary INDEX/INDEX file each of which runs on a different combination of hardware and operating system. Incompatible software does not operate on the host(s) because of the host’s computer hardware or operating system. The default condition in swinstall is to disallow selection and installation of incompatible software. INDEX/INDEX file In packaging, an INDEX file defines attribute and organizational information about an object (for example, depot, product, or fileset).
Glossary Nodes K M Kernel Fileset A fileset that contains files used to generate the operating system kernel. During the swinstall load phase, kernel filesets are loaded and customized before other filesets. Machine_Type In packaging, a keyword that type of systems on which the product will run. (If not specified, the keyword is assigned a wildcard value of * (meaning it will run on all machines.
Glossary Number Number In packaging, a keyword that defines the part or manufacturing number of the distribution media (CD or tape depot). O Object The pieces of software that SD-UX packages, distributes, installs, and manages. There are three classes of objects: software (installed on target roots or available in depots), containers (depot, roots, alternate roots), and jobs. Patch Software designed to update specific bundles, products, subproducts, filesets, or files on your system.
Glossary Remote Procedure Call (RPC) Primary Root A system on which software is installed and configured. Principal In SD-UX security, the user (or host system, for agents making RPCs) that originates a call to another system. Product A collection of subproducts and/or filesets. Pull Getting software products from a depot to be installed or copied onto the local system. See also push.
Glossary Request script Request script An interactive control script that gets a response from the user. A request script prompts the user for a response, reads the user’s answer, and stores the results in a response file. Request scripts can be run by the swask, swconfig, and swinstall commands. Response file A file that is generated by an interactive request script and contains the user’s response. Revision This keyword defines the “revision” attribute for the product object.
Glossary SW-DIST Shared Secrets File In SD-UX security, a file containing the passwords used to encrypt and decrypt distributed communications for added security. Single Point Administration (SPA) The ability to simultaneously distribute to, manage, or monitor multiple remote targets from a single controller system. See remote management. Software depot An SD-UX format structure that contains one or more software products that can be installed on other systems or copied to other depots.
Glossary swacl swacl A SD-UX command that allows you to modify Access Control List permissions that provide software security. swadm In SD-UX security, the default user identification group. swlist A SD-UX command that lists software objects, their attributes, and their organization. It lists both installed software and software contained within a depot. swlock A file that contains the read or write access to software objects and ACLs.
Glossary Update format depot.) Tape depots such as cartridge tapes, DAT and 9-track tape are referred to by the file system path to the tape drive’s device file. navigate (no mouse). See also Command Line User Interface and Graphical User Interface. TUI See Terminal User Interface. Tape Media Software media that uses tar to store SD-UX software products and control files.
Glossary update-ux update-ux A command that automates part of the HP-UX update process. It replaces the swgettools script used in previous versions of SD-UX. The install-sd updates the SD-UX product without performing an OS update. User name The user (or host system for agents making remote procedure calls (RPCs) to other agents) that is originating the RPC call. UUID In packaging, a keyword that for the vendor object.
Index Symbols $HOME/.sw/sessions/ directory, 61 *systemFont, 53 *userFont, 53 / (root directory), 64 /var/adm/sw/defaultsor $HOME/.
Index audience, 20 authorization, depot, 152 authorization, RPC, 291 auto_kernel_build=, 428 automatic recovery, 428 automatic scrolling, 69, 126, 143 autoreboot=, 428 autorecover, 78, 428 autorecover_product=, 429 autorecover_product= default, 77 autoremove_job, 235, 429 autoselect_dependencies=, 430 autoselect_dependencies=true option, 33 autoselect_dependents=, 430 autoselect_patches=, 430 autoselect_reference_bundles=, 430 B bundles, 28, 303 busy files, swremove, 122 C -C option, 73, 86, 92, 99, 117, 12
Index input and output, 397 location and execution of, 387 request, 371, 379, 394 shells, 378 swask command, 407 testing, 402 types, 371 writing, 370 control script location, 380 control scripts, 305 must run as superuser, 285 unpostinstall, 250 unpreinstall, 250 control_files=, 434 controller, 190 controller log file, 444 controller privileges, 288 controller_source=, 434 controlling access, 285 copy dialog, 146 copying patches, 175 copying software depots, 138 icon in Job Browser, 218 Job Browser, 228 cor
Index software selection files, 58, 59 subproduct, 28 system, 27 tags, 115 target, 27 terminology, 491 uname attributes, 115 delegation, 293 denied access, troubleshooting, 468 dependencies, 33, 82, 89, 436 swconfig, 84 swcopy, 137 dependents, 430 depot ACL control, 276 ACL permissions, 279 advertising, 151 authorization, 152 cannot read, 476 CD-ROM, 357 copying, 138 definition, 27, 135 directory, 135 distribution, 27, 135 images, 470 listing, 158 listing contents, 159 lists, 111 management, 135 multiple, 1
Index RPC timeouts, 472 swpackage, 341, 343 troubleshooting, 461 UNIX packaging, 474 WAN connection timeouts, 472 examples command options, 60 request scripts, 410 session file, 62 swask, 410 swconfig, 88 swmodify, 120 swremove, 130 swverify, 94 exclude file, 343 excluded due to errors, 71, 145 from task, 71, 145 exrequisite, 335 F -f option, 58, 73, 86, 92, 99, 101, 117, 128, 147, 152, 230, 351, 407 f1 key, Help, 52 failed operations, 463 FAQ, SD-UX, 21 features, swpackage, 351 file catalog, 30, 115 exclu
Index I -i option, 73, 147, 230 images, depot, 470 important terms, 491 include file, 343 include_file_revisions=, 438 input files, 76 insert permission, 152 install analysis, 67, 124, 141 dialog, 72, 127 install preferences, 206 install_cleanup_cmd=, 438 install_setup_cmd=, 439 installation staged, 247 installed products database, 490 Installed Products Database (IPD), 30, 115 INSTALLED state, 82 installed_software_catalog, 438 installing compatibility filtering, 80 failure, 476 icon in Job Browser, 218 pa
Index LC_ALL environment variable, 381 level designation, swlist, 99, 107 of detail, swlist, 96 level=, 441 level= default, 105, 108 list as input to other commands, 96 depot, 111 simple, 103 verbose, 111 listing interactive swlist, 97, 210 patches, 178 software, 96 listing software registered depots, 158 UNIX depot contents, 159 local host definition, 27 local superuser, 293 locatable products, 79 locked software, 78, 107, 150 log file messages, 442 log_msgid=, 442 logdetail=, 443 logfile, 69, 126, 143 but
Index networking requirements, 22 nodes, definition, 27 nonprivileged SD, 413 limitations, 415 overview, 414 packaging requirements, 416 set up, 416 num_entries value, 469 O object list, 37 object permissions, 276 objects patch software, 183 objects, software, 28 objects_to_register=, 446 one_liner=, 446 one_liner= default, 105, 108 on-line Help, 52 open item, 48 option menu, 223 options alphabetic list of, 424 and defaults, swconfig, 120 and defaults, swremove, 130 changing, 59, 422 compress_index, 433 cre
Index details, 393 preinstall script, 371 details, 389 preremove script, 371 details, 393 prerequisite, 34, 335 definition, 34 preserve_create_time option, 449 pre-specified selections, 73, 147, 230 preview, 449 preview option, -p, 73, 86, 128, 147 privileged functions, 285 problem solving, 461 product, 28 description button, 69, 126, 143 description, swremove, 126 level, specifying (swlist), 108 summary button, 69, 126, 143 product ACL control, 277 permissions, 280 templates, 282, 284 product specification
Index preferences, 206 software selection, 204 swlist, 210 target selection, 202 Remote Procedure Call (RPC), 285 remove simple, 130 window, 127 remove_empty_depot=, 451 remove_obsolete_filesets=, 451 remove_setup_cmd=, 451 removing jobs, 230 patches, 179 software, 122 software from an alternate root, 132 software from depots, 162 removing software icon in Job Browser, 220 Job Browser, 229 repackaging software, 361 request script, 371, 394 keyword, 379 request scripts examples, 410 response file, 394 runnin
Index for developers, 297 in "push" installations, 295 packaging, 358 pull distribution, 296 UNIX, 285 security checks configuration, 299 copying, 298 installing, 299 Job Browser, 298 listing, 298 packaging, 298 registering depots, 300 removal, 299 verifying, 300 security tasks, 261 select_local=, 455 selecting software to copy, 141 selecting software to remove, 124 server, definition, 27 session file, example, 62 files, 61 session file option, -S, 73, 86, 92, 101, 117, 128, 147, 152, 230, 351, 407 setuid
Index swacl, 300 -D option, 269 -F option, 269 -l depot option, 262 -l host option, 262 -l product option, 262 -l root option, 262 listing user access, 262 -M option, 269 overview, 23 swacl command, 258 options, 258 swadm group, 260 swagent, 28, 190 swagentd, 28, 190 overview, 23 swask, 300, 407 examples, 410 syntax, 407 swconfig command, 82 security checks, 299 swcopy dependencies, 137 GUI overview, 138 overview, 23 security checks, 298 SW-DIST loading new version, 479 reloading if corrupt, 479 swgettools,
Index swremove, 128 system definition, 27 system_file_path=, 457 system_prep_cmd=, 457 T -t option, 59 table of contents, 96 tag attribute, always listed, 106 tags, 115 tape changing, 72 depot, 136 tape device, 436 tape formats cpio, 350 tar, 350 tape is ready response, 366 tape, partitioning filesets on multiple, 366 tar archive, 136 tar tape format, 350 target changing, 124 definition, 27 definition for remote operations, 190 files, 59 remote, 190 re-using in Job Browser, 228 selection, 58 selection, swmo
Index V var/spool/sw, 135 vendor defined attributes, 321 keyword, 323 specification, 323 vendor specification, 323 verbose listings, samples, 114 lists, 111 option, -v, 73, 81, 92, 128, 147, 152, 230 verbose option, 351 verbose=, 459 verify analysis phase, 90 installations, 89 operations, samples, 94 patches, 181 script, 371 script, details, 391, 392 scripts, executing, 90 verify script, 432 versions, 253 view menu, 222 view preferences, changing, 42 volatile, 432 W WAN, 242, 247 WAN connection timeouts, 47
