Software Distributor Administration Guide HP-UX 11i v1, 11i v2, and 11i v3 HP Part Number: 5992-5875 Published: March 2009
© Copyright 1997, 2000-2003, 2006, 2007, 2008, 2009 Hewlett-Packard Development Company L.P Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The information contained herein is subject to change without notice.
Table of Contents About This Document ..................................................................................................................19 Intended Audience.............................................................................................................19 HP-UX 11i Release Names and Release Identifiers............................................................19 Typographic Conventions..............................................................................................
1.3.10 Changing Options and Refreshing the Object List—The Options Menu...........40 1.3.11 Performing Actions—The Actions Menu............................................................40 1.3.11.1 Open Item/Close Level................................................................................41 1.3.11.2 Add/Save Software Group..........................................................................41 1.3.11.3 Change Source..............................................................................
2.3 Verifying Your Installation (swverify)..........................................................................74 2.3.1 Features and Limitations.......................................................................................74 2.3.2 The Verification Process .......................................................................................75 2.3.3 Using swverify......................................................................................................77 2.3.
4 Managing Software Depots.....................................................................................................111 4.1 Depot Management Commands and Concepts..........................................................111 4.1.1 Depot Concepts...................................................................................................111 4.1.1.1 Types of Depots...........................................................................................112 4.1.1.1.1 Directory Depot..........
6.2.3 The View Menu ..................................................................................................140 6.2.3.1 Viewing By Name and Icon........................................................................140 6.2.3.2 Viewing By Properties.................................................................................140 6.2.4 The Options Menu ..............................................................................................141 6.2.4.1 Changing the Refresh Interval .........
7.4 Remote Operations Tutorial........................................................................................158 7.4.1 Tutorial Set-Up....................................................................................................158 7.4.2 How to Perform a Single-Target Installation......................................................159 7.5 Remote Interactive swlist............................................................................................167 7.
.3.1 Listing User Access ............................................................................................188 9.3.2 Allowing Users to Manage Products in a Depot ................................................190 9.3.3 Allowing Users to Manage Roots (Install/Remove) ...........................................190 9.3.4 Restricting Access to Depots ..............................................................................191 9.3.5 Adding Target Hosts ...........................................
9.10.7 Configuration (swconfig) .................................................................................214 9.10.8 Verify (swverify) ...............................................................................................214 9.10.9 Registering Depots (swreg) ..............................................................................214 9.10.10 Changing ACLs (swacl)...................................................................................214 9.10.11 Request Scripts (swask)........
10.6.4 Packaging Security ...........................................................................................258 10.6.4.1 ACL Creation ............................................................................................259 10.6.5 Repackaging or Modifying a Software Package ...............................................260 10.6.6 Packaging In Place ............................................................................................261 10.6.7 Following Symbolic Links in the Source ...
11.4.3.5 SW_SESSION_IS_REBOOT.......................................................................277 11.4.3.6 SW_SYSTEM_FILE_PATH .......................................................................277 11.4.4 Variables That Affect swverify..........................................................................277 11.4.4.1 SW_IS_COMPATIBLE...............................................................................277 11.5 Execution of Control Scripts ...............................................
A Command Options.................................................................................................................299 A.1 Changing Command Options....................................................................................299 A.2 Options Listed Alphabetically...................................................................................300 B Troubleshooting......................................................................................................................
List of Figures 1-1 1-2 1-3 1-4 1-5 1-6 1-7 1-8 1-9 1-10 1-11 1-12 1-13 1-14 1-15 2-1 2-2 2-3 2-4 2-5 3-1 3-2 3-3 3-4 4-1 4-2 4-3 4-4 4-5 4-6 6-1 6-2 6-3 6-4 6-5 6-6 6-7 6-8 6-9 6-10 6-11 14 SD-UX Systems............................................................................................................27 Example of HP-UX Software Structure ......................................................................28 The Terminal User Interface (TUI) .....................................................
6-12 6-13 6-14 7-1 7-2 7-3 7-4 7-5 7-6 7-7 7-8 7-9 7-10 9-1 9-2 9-3 10-1 Job Results Dialog .....................................................................................................143 Show Job Description ...............................................................................................144 Remove a Job dialog..................................................................................................145 Target Selection Window..................................................
List of Tables 1 1-1 1-2 1-3 2-1 2-2 2-3 2-4 2-5 2-6 3-1 3-2 3-3 3-4 3-5 3-6 3-7 3-8 3-9 4-1 4-2 4-3 4-4 4-5 6-1 6-2 6-3 6-4 7-1 7-2 7-3 8-1 9-1 9-2 9-3 9-4 9-5 9-6 9-7 9-8 9-9 16 HP-UX 11i Releases.....................................................................................................19 Chapter Topics............................................................................................................23 SD Commands.........................................................................
9-10 9-11 10-1 10-2 10-3 10-4 10-5 11-1 11-2 11-3 12-1 A-1 A-2 B-1 B-2 C-1 D-1 D-2 D-3 Product Principals.....................................................................................................201 Product Permissions..................................................................................................201 Chapter Topics...........................................................................................................217 Keywords Used in the Product Specification File .......
About This Document This guide describes using Software Distributor (SD) to deliver, manage and maintain HP-UX operating systems and layered software applications. This guide is written for experienced HP-UX system administrators who are responsible for setting up and maintaining HP-UX servers and workstations.
HPUX11i-TCOE B.11.23.0512 HP-UX Technical Computing Operating Environment Component The above revision string represents the following: B.11.23 = HP-UX 11i v2 0512 = December 2005 Update Release Typographic 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.
To ensure that you receive the new editions, you should subscribe to the appropriate product support service. See your HP sales representative for details.
• • • • • • • • Read Before Installing or Updating to HP-UX HP-UX Installation and Update Guide HP-UX Reference Managing Systems and Workgroups: A Guide for HP-UX System Administrators HP-UX Patch Management HP System Partitions Guide Getting Started with Software Package Builder VERITAS File System 4.1 (HP OnlineJFS/JFS) and VERITAS Volume Manager 4.1 Installation Guide Some or all of these documents are available on the Instant Information media and in printed form.
1 Introduction to Software Distributor This chapter contains overview information and explains important concepts that will help you use the Software Distributor (SD-UX) commands most effectively. Table 1-1 Chapter Topics Topics: “SD-UX Overview” (page 23) “SD-UX Concepts” (page 26) “Using the GUI and TUI Commands” (page 31) “Working from the Command Line” (page 46) 1.1 SD-UX Overview Software Distributor for HP-UX (SD-UX) provides you with a powerful set of tools for centralized HP-UX software management.
Table 1-2 SD Commands 24 Command & Manpage Description/Features More Information swinstall(1M) • Installs or updates software • Optional GUI • “Installation with swinstall” (page 53) swlist(1M) • Lists installed software or software • “Listing Your Software (swlist)” in depots or on media (page 81) • Optional GUI • “Listing Registered Depots” (page 129) swcopy(1M) • Copies software from one depot to another • Optional GUI • “Copying Software Depots” (page 113) swremove(1M) • Removes installed
Table 1-2 SD Commands (continued) Command & Manpage Description/Features More Information swmodify(1M) • Modifies the Installed Products • “Modifying the IPD (swmodify)” Database (IPD) and various catalog (page 96) files that contain information about the software on the system swreg(1M) • Registers newly created depots to • “Registering and Unregistering Depots make them visible to other systems (swreg) ” (page 123) sd(5) • Starts the Job Browser GUI to create, monitor, schedule, and delete jobs •
man 4 swpackage for packaging file layouts 1.2 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. 1.2.1 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.
Figure 1-1 SD-UX Systems Network Server Media Development System Depot n Local Host 1.2.2 Software Structure SD-UX commands work on a hierarchy of software objects that make up the applications or operating systems components you want to manage. Software Objects Bundles Collections of filesets, possibly from several different products, “encapsulated” for a specific purpose. Bundles can reside in software depots, and SD-UX commands act on bundles as single entities.
Filesets Filesets include all the files and control scripts that make up a product. Filesets can only be part of a single product but they can be included in several different HP-UX bundles or subproducts. Like products, different versions of a fileset may be defined for different platforms and OSs. Filesets are the lowest level of object managed by SD-UX.
Checkremove Analyzes each target to determine if removal and unconfiguration can take place. (Executed by swremove.) Configure Configures installed filesets or products. (Executed by swconfig and swinstall.) Fix Corrects and reports on problems in installed software. (Executed by swverify.) Postinstall Performs additional install operations immediately after a fileset or product has been installed. (Executed by swinstall.
1.2.6 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. 1.2.6.1 How Commands and Options Interact with Dependencies Command options let you control how software dependencies are handled.
Dependencies can also be specified between a fileset and another product. Expressions for revisions and other product attributes are supported. Corequisites An object requires another to operate correctly, but does not imply any load order. Prerequisites An object requires another to be installed and/or configured correctly before it can be installed or configured respectively. Prerequisites do control the order of operations.
1.3.1 The Terminal User Interface The terminal user interface lets you use the SD-UX GUI capabilities on systems with text-based terminals. With the TUI, you use the Arrow, Tab, Space, and Return keys to navigate. Figure 1-3 The Terminal User Interface (TUI) NOTE: All examples for GUI commands in this manual also apply to the TUI. 1.3.
NOTE: You can also launch the SD-UX GUIs from HP’s System Management Homepage (SMH) or System Administration Manager (SAM) applications. 1.3.3 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 Provides pull-down menus for File, View, Options, Actions, and Help. Each choice has additional submenus for more activities.
1.3.4 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. For example, to see the subproducts in the SD-DATABASE product, open SD-DATABASE by double clicking on it.
swinstall.hosts={hostA hostB hostC hostD hostE hostF} swcopy.hosts_with_depots={hostS} When you use the program, dialog boxes that let you choose a source system from a list will display all hosts specified in defaults.hosts or remembered from a previous session. Once a source is successfully accessed, that host is automatically added to the list in the defaults.hosts file and displayed in the dialog. If there are no hosts specified in defaults.
software selections, and target hosts—are automatically saved. This lets you re-execute the command even if the session ends before proper completion. (See “Session Files” (page 51).) You can save session information into a file at any time by selecting the Save Session or Save Session As choice from the File menu. The Recall Session choice lets you import the settings from a previously saved session file. Clear Session resets all options and operands to their default values.
Figure 1-6 Column Editor The editor displays values 1 through the total number of attributes, plus an Ignore option, which removes that attribute from display in the object list. You can specify an attribute’s justification by clicking on the Left or Right button in the Justify column. Set the column width by placing the cursor in the appropriate text field in the Width column, then entering the width (number of characters). Use an asterisk (*) to size the column automatically.
1.3.9.2 Filter... Figure 1-7 Filter Dialog The View→Filter... choice displays the Filter dialog (Figure 1-7: “Filter Dialog”,), which lets you specify the type of filtering desired for each attribute. The Operator menu button lets you specify the operator for a given attribute. The following table presents the operator types: Table 1-3 Operator Types Any Displays objects regardless of the value of the attribute.
• • • To return to the original default values, select System Defaults. Select Cancel to ignore any changes made and close the Filter dialog. To save the changes made for the next invocation of the application, choose View→Save View as Default. 1.3.9.3 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.
/var/adm/sw/ui/preferences/username.prefs. 1.3.10 Changing Options and Refreshing the Object List—The Options Menu The Options menu lets you refresh the object list and change the default values of options that control command behaviors and policies. Selecting Options→Refresh List updates the object list to reflect any changes. Selecting Options→Change Options opens the Options dialog (Figure 1-9: “Options Dialog”,), which lets you change a limited set of options for the command.
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. 1.3.11.1 Open Item/Close Level The Open Item or Close Level menu choices let you see the contents of a selected object or close it. Each object list is hierarchical. Objects that have an arrow (→) after the name can be opened to reveal other items.
NOTE: Software automatically marked due to dependencies is not included in a software group. Dependencies are recomputed each time you select Add Software Group. See “Software Dependencies ” (page 30) for more information about dependencies Figure 1-10 Save Software Group Dialog 1.3.11.3 Change Source The Change Source... menu choice opens the Specify Source dialog (Figure 1-11: “Specify Source Dialog”,), which lets you change the source for the software to be used. Figure 1-11 Specify Source Dialog 1.
a. Click on the Source Host Name button. The system displays a dialog that lists all host system names contained in the defaults.hosts file ($HOME/.sw/ defaults.hosts or /var/adm/sw/defaults.hosts). b. Choose a host name from the list. c. Click OK. The host name appears in the appropriate box in the Specify Source dialog. 2. (Optional) To specify the path to the depot, type a new path, or: a. Click on the Source Depot Path button to display a list of registered depots on the source host. b.
Figure 1-13 Shared Root Paths Dialog 1.3.12 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). This displays specific help for that item. To view overview information for each major screen, to get help on keyboard usage, or to view other product information, select the Help menu from in the menu bar. 1.3.12.1 Overview...
1.3.12.4 Product Information... This menu item displays copyright and revision information for SD-UX. 1.3.13 XToolkit Options and Changing Display Fonts The GUI commands support the following subset of the HP-UX XToolkit command line options: • • • • • -bgor -background -fgor -foreground -display -name -xrm Note that the SD-UX commands do not support the XToolkit -fn or the -font option used to change display fonts.
The command line is most effective for: • • • Quickly executing simple commands Executing tasks that take a long time to accomplish Creating commands for later execution by scripts A typical command line might look like this: Figure 1-15 Sample Command swinstall -f MySoft -s /mnt/cd @ targetB command file of software selections location of software depot target host The example shows that you have several ways to specify SD-UX behavior including command-line options (such as -f and -s), input files (
swinstall -s sw_server \*man • Bundles and products are recursive. Bundles can contain other bundles. For example: swinstall bun1.bun2.prod.sub1.fset,r=1.0 or (using expressions): swinstall bun[12].bun?.prod.sub*,a=HP-UX • The \* software specification selects all products. CAUTION: To avoid data loss, use the \* specification with considerable care (such as when removing software from the root directory, /).
is an integer that distinguishes versions of products and bundles with the same tag. 1.4.1.2 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.
swinstall -f mysoft -s /mnt/cd -t mytargs In this example, the file mytargs (which resides in the current working directory) contains a list of target selections for the swinstall command. In the target file, blank lines and comments (lines beginning with #) are ignored. Each target selection must be specified on a separate line and must consist of a host name or network address, optionally followed by a colon and a full path: host[:/directory] 1.4.
[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: You must restart the SD-UX daemon after changing swagentd options, or the daemon will not recognize the changes. To restart the daemon, type: /usr/sbin/swagentd -r 1.
Session information is saved in the $HOME/.sw/sessions/ directory as command.last in which command is the name of the command. Each time you save a session file, it overwrites the previously stored one. (To save multiple session files, you can rename each session file after you invoke the command.) To re-use the automatically saved session file, invoke the command with the -S swcommand.last argument. For example: swinstall -S swinstall.
2 Installing Software This chapter discusses how to use the swinstall, swconfig, and swverify commands to install, configure, and verify software. • • • swinstall installs software from a depot and performs automatic configuration of software. swconfig lets you configure, unconfigure, or reconfigure previously installed software. swverify lets you check that software was installed correctly and run scripts to perform additional verification tasks or fix specific problems.
Postinstall Performs additional install operations (such as resetting default files) immediately after a fileset or product has been installed. Unpostinstall Undoes a postinstall script in case swinstall must initiate recovery during the installation process. Unpreinstall An undo preinstall script in case SD must initiate recovery during the install process. (See Chapter 11: “Using Control Scripts ” (page 265)) • Software can be installed to alternate root directories. 2.1.
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.
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. (The flag Partial may appear if you select only a component of a software object or if such components are automatically selected due to dependencies.
• • • • • • 3. 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. Manage Patch Selections lets you select from a list of patches to install, select filters for patches, and set other patch options. (See “Installing Patches” (page 65) for more information.) Change Source...cancels your software selections and returns you to the Specify Source dialog.
• • • Product Summary gives additional information about the product or bundle and provides a Product Description button that displays information about additional information about dependencies, copyright, vendor, etc. Logfile presents a scrollable view of detailed install information written to the logfile.
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. Ready There were no errors or warnings during analysis.
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). Product Summary display installation and product information (name, revision, installation results, installation summary). Logfile displays the logfile. (Appears only for kernel installations) Resume restarts a suspended installation. This lets you fix problems before continuing.
Options and Operands XToolkit_Options X window options for the GUI. See “XToolkit Options and Changing Display Fonts ” (page 46). -i Run the command in interactive mode by invoking the GUI or TUI. See “Installing with the GUI” (page 54). -p Preview the install task (perform analysis only). -r Operate on an alternate root directories. See “Installing to an Alternate Root ” (page 67). -v Turn on verbose output to stdout and display all activity to the screen.
-x command_option=value Sets command_option to value, overriding default values or values in options files. See “Changing Command Options ” (page 62). -X option_file Read session options and behaviors from option_file. See “Changing Command Options ” (page 62). software_selections One or more software objects to be installed. See “Software Selections” (page 47). target_selections The target on which to install the software selections. See “Target Selections” (page 49).
Table 2-3 swinstall Command Options and Default Values • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • 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_minimum_dependencies=false autoselect_patches=true autoselect_reference_bundles=true codeword
2.1.4 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.” To start an install session via the command line, you must assemble any options (if needed), host and source names, and software selections into a command string.
This document and complete OS documentation is available on your HP-UX Instant Information CD-ROM and at: http://docs.hp.com/hpux/os/11i/ 2.1.4.2 Installing Patches The swinstall command has a variety of patch management features, including a patch management dialog in the GUI. See Chapter 5: “HP-UX Patching and Patch Management” (page 133) for complete details on patches and using the swinstall GUI patch features. 2.1.4.
2.1.4.5 Using Software Codewords and Customer IDs To protect software from unauthorized installation, HP (and other vendors) use special codewords and customer identification numbers to “lock” the software to a particular owner. These codewords and customer IDs are provided to you when you purchase the software (or receive it as update). HP lists them on the Software Certificate which is packaged with the software.
2.1.4.7 Installing Multiple Versions Your installation may commonly having multiple versions of a software product installed at various hosts on the network. Multiple installed version let you: • • Back out defective versions (by removing the new version and reconfiguring the old version, if necessary) Let users migrate to newer software versions at their own pace You can decide whether to allow multiple versions by controlling the allow_multiple_versions command option.
controlled by the allow_incompatible option and depend on the host’s uname attributes. 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 attribute Product value (Pattern to match) 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.
NOTE: Compatibility filtering does not apply to alternate root file systems. You must select software that you know to be compatible with the alternate root. 2.2 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.
• • The swconfig command moves software between the installed and configured states. The swconfig command uses dependencies to automatically select software on which to operate (in addition to any software you specify directly). See “Software Dependencies ” (page 30) for more information.
3. Check state of versions currently installed: • If the product is non-existent or corrupt, the task issues an error that says the product cannot be configured and to use swinstall to install and configure this product. • If the versions currently installed are not configured and if the -u (unconfigure) option is set, the system issues a note that the selected file or fileset is already unconfigured.
1. 2. (Un)configure each product. Run scripts for associated filesets, checking return values. If an error occurs, the fileset is left in the installed state. If a warning occurs, the fileset will still be configured. 3. Update the IPD to show the proper installed or configured state. Configure scripts must also adhere to specific guidelines. For example, these scripts are only executed in the context of the host that the software will be running on, so they are not as restrictive as customized scripts.
-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” (page 49). -x option=value Sets a command option to value and overrides default values or a values in options files. See “Changing Command Options” (page 73). -X option_file Read session options and behaviors from option_file. See “Changing Command Options” (page 73). software_selections The software objects to be configured. See “Software Selections” (page 47).
2.2.4 Configuration Tasks and Examples To configure productA, located in the root on the local host: swconfig productA To unconfigure the software selections in the file mysoft that are installed in the default directory on the local host: swconfig -u -f mysoft To reconfigure the Omniback product using the default option values: swconfig -x reconfigure=true Omniback To configure a particular version of Omniback: swconfig Omniback,r=2.
Fix Corrects and reports on problems in installed software. Typical uses are to create missing directories, correct file modifications (mode, owner, group, major, minor), and to recreate missing symbolic links. Verify Verifies the configuration of filesets or products, in addition to the standard swverify checks. (See Chapter 11: “Using Control Scripts ” (page 265) for more information.
3. Check for correct states in the filesets (installed, configured or available). For installed software, swverify also checks for multiple versions that are controlled by the allow_multiple_versions option: • If allow_multiple_versions is false, an error is produced that multiple versions of the product exist and the option is disabled. • If allow_multiple_versions is true, a warning is issued saying that multiple versions exist. 4. Check dependencies.
2.3.3 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) ” (page 130) -r Operate on an alternate root rather than /. Verify scripts are not run. -v Turn on verbose output to stdout and display all activity to the screen.
target_selections The target of the command. See “Target Selections” (page 49). Changing Command Options You can change the behavior of this command by specifying additional command-line options when you invoke the command (using the -xoption) or by reading predefined values from a file. The following table shows the defaults and options that apply to swverify.
To verify the HP Omniback product that is installed on the local host and display detailed messages from the process (-v) on stdout: swverify -v Omniback To verify the 2.0 version of Omniback that is installed on the local host at /opt/ Omniback: swverify Omniback,r=2.0 @ /opt/Omniback Verify a particular version of HP Omniback: swverify Omniback,1=/opt/Omniback_v2.0 Verify the entire contents of a local depot: swverify -d \*@/var/spool/sw 2.
3 Managing Installed Software This chapter presents an overview of managing non-depot software after you have installed it. The swlist, swmodify, and swremove commands help you perform these software management tasks: Table 3-1 Chapter Topics Topics: “Listing Your Software (swlist)” (page 81) “Modifying the IPD (swmodify)” (page 96) “Removing Installed Software (swremove)” (page 101) 3.
3.1.2 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. Double-clicking on a file displays the file attributes. 3.1.2.
3.1.2.2 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... displays a dialog from which you can filter the display list with logical and relational operators for each field. Sort...
-R Shorthand for -l bundle -l product -l subproduct -l fileset -a attribute Displays a specific attribute. To display multiple attributes, specify multiple -aoptions. To list the full set of attributes for a software object, use the -v option. Note that the tag attribute is always displayed for products, subproducts, and filesets. The path (filename) attribute is always displayed for file objects. This option does not apply if you use the -c option.
Table 3-2 The -l Options (continued) -s source Option Action swlist -l prroot Shows the private roots swlist -l bundle Shows only bundles swlist -l product Shows only products swlist -l subproduct Shows products and subproducts swlist -l fileset Shows products, subproducts and filesets swlist -l file Shows products, subproducts, filesets, files and numbers (used in software licensing).
Changing Command Options You can change the behavior of this command by specifying additional command-line options when you invoke the command (using the -xoption) or by reading predefined values from a file. The following table shows the defaults and options that apply to swlist.
# Product(s) not contained in a Bundle: HMS OBAM5_0 1.01 B.11.00 ObAM 5.0 Using swlist with no options set and no software selected gives you a listing of all software bundles plus all products that are not part of a bundle. Adding the -d option gives you the same listing of software residing in the default depot on your local host. In the following examples, swlist requests are sent to the standard output.
information about these features, refer to the appropriate product manuals. This document does not contain information about software changes made as a result of a Service Request; that information may be found in the Software Release Bulletin (SRB) for Release X.0. ******************** * Hardware Support * ******************** The HP 9000 Model XXX is no longer supported. ... • List the products stored in the software depot on host1 located at /swmedia.
3.1.4.2 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.
3.1.4.4 Listing Patches You can use swlist to list software patches and their status. 3.1.4.5 Using Software Codewords and Customer IDs The swlist command may prompt you for codewords if you try to view codeword protected software. You can also enter new codewords from the command line or from the GUI. This process is identical to that used by swinstall. See “Using Software Codewords and Customer IDs ” (page 66) for more information. 3.1.4.
NOTE: Examples in the following sections do not include a value for the one_liner option. 3.1.4.6.1 Specifying Product Level Specifying a level for a given software selection causes swlist to list the objects at that level plus all those that are above that level. Upper levels will be commented with a # sign. Therefore, only the level specified (product, subproduct, fileset or file) will be uncommented. This allows the output from swlist to be used as input to other commands.
Remember, the product name is always assumed; you don’t have to specify it in the -a option. 3.1.4.6.3 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.
3.1.4.6.5 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. To do this, you can use a combination of the -l depot option: Table 3-5 Listing Depots swlist syntax result swlist -l depot list all depots on the local host swlist -l depot @ hostA list all depots on hostA swlist -l depot -v @ hostB list, in verbose mode, all depots on hostB 3.1.4.6.
• • To display all attributes for products, subproducts and filesets, use swlist -v -l fileset. To display all attributes for products, subproducts, filesets and files, use swlist -v -l file. The table below provides a sample listing of the kinds of attributes that swlist will display. Not all these attributes exist for each software level or object. This list may change depending on vendor-supplied information. Do not use this list as the official list of all attributes.
Here are some examples of verbose listings: This command on the local host: swlist -v -l file NETWORKING.ARPA-RUN produces this listing: #NETWORKING.ARPA tag: ARPA-RUN instance_id 1 revision 1.2 title ARPA run_time commands size 556 state configured corequisite NETWORKING.LANLINK is_kernel true file etc/freeze path /etc/freeze type f mode 0755 owner bin group bin uid 2 gid 2 mtime 721589735 size 24 file etc/ftpd path /etc/ftpd type file mode 0555 owner bin group bin uid 2 gid 2 mtime 721589793 size 9 ...
is_kernel mod_time true 733507112 3.2 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.
features to gather billing data for such items as disk space usage, connect time or CPU resource usage. " timestamp 797724879 install_date 199504121614.39 install_source hpfclc.fc.hp.com:/release/11.00_gsL/goodsystem state configured ancestor HPUX10.20.ACCOUNTNG corequisite OS-Core.CMDS-MIN,r>=B.11.00,a=HP-UX_B.11.00_32/64,fa=HP-UX_B.11.00_32/64,v=HP Catalog files are the equivalent IPD files but they are for software stored in a depot.
-v Turns on verbose output to stdout. (The swmodify logfile is not affected by this option.) -V Lists all the SD layout_versions this command supports. -a attribute=value Add, change, or deletes the attribute value. Otherwise, it adds/changes the attribute for each software_selection by setting it to the given value. Multiple -a options can be specified. Each attribute modification will be applied to every software_selection.
swmodify will select all of the software defined in the PSF. The software selected from a PSF is then applied to the target_selection, with the selected software objects either added to, modified in, or deleted from it. If a PSF is not specified, then software_selections must be specified. swmodify will select the software_selections from the software defined in the given (or default) target_selection.
NOTE: In general, use caution when using the -u option with the -a option. If -u is used and -a is also specified, the -a option deletes the attribute from the given software_selections (or deletes the value from the set of values currently defined for the attribute). Changing Command Options You can change the behavior of this command by specifying additional command-line options when you invoke the command (using the -xoption) or by reading predefined values from a file.
If a product provides a more complex configuration process, a script can set the fileset’s state to configured upon successful completion. 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 3.2.3.
For more information, see Chapter 11: “Using Control Scripts ” (page 265). • swremove does not perform automatic unconfiguration when you remove software from alternate roots. 3.3.2 Using the swremove GUI This section provides an overview of the swremove GUI. • • • In general, all information presented in “Removing Installed Software (swremove)” (page 101) also applies to the swinstall GUI.
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. (The flag Partial may appear if you select only some component of a software object.) 2.
• • 3. 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. Show Description of Software (available only for a single item highlighted in the object list) displays more information on the selected software. Select Actions→Install to start the analysis (preview) step. The Analysis dialog appears. Step III: Analysis (Preview) In this step, SD-UX analyzes the software you have selected.
The following actions are also available: • Product Summary gives additional information about the product or bundle and provides a Product Description button that displays information about additional information about dependencies, copyright, vendor, etc. The Projected Action column describes what type of removal is being done. The possible types are: Remove The product exists and will be removed. Filesets Not Found The system did not find the filesets as specified.
Figure 3-4 Remove Window 3.3.3 Removing with the Command Line Syntax swremove [XToolkit_Options] [-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 106 XToolkit_Options X window options for the GUI. See “XToolkit Options and Changing Display Fonts ” (page 46). -d Operates on a depot rather than installed software.
-Q date Schedules a job for the given date when remote operations are enabled. See “Scheduling Jobs from the Command Line” (page 148) and Chapter 7: “Remote Operations Overview” (page 151) -S session_file Run the command based on values saved from a previous removal session, as defined in session_file. See “Session Files” (page 51). -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” (page 49).
Table 3-9 swremove Command Options and Default Values • • • • • • • • • • • • • • • • • • • admin_directory=/var/adm/sw agent_auto_exit=true agent_timeout_minutes=10000 auto_kernel_build=true autoreboot=false autoremove_job=false autoselect_dependents=false autoselect_reference_bundles= true compress_index=false controller_source= distribution_target_directory= /var/spool/sw enforce_dependencies=true enforce_scripts=true force_single_target=false installed_software_catalog=products job_title= log_msgid=0 l
will not be removed because it is also used by the bundle Pascal. This prevents the removal of one bundle from inadvertently causing the removal of a fileset needed by another bundle. 3.3.4.2 Removing Patches You cannot remove patch software unless: • Rollback files corresponding to the patch are available for re-installation. — or — • The base software modified by the patch is removed at the same time. (Removing the base software also removes the patches associated with that software.
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. Table 4-1 Chapter Topics Topics: “Depot Management Commands and Concepts” (page 111) “Copying Software Depots” (page 113) “Registering and Unregistering Depots (swreg) ” (page 123) “Additional Depot Management Tasks and Examples” (page 126) 4.
directly from physical media or by using swpackage to make a software package containing the depot. When a depot resides on a networked system, that system can act as a source for software: other systems on the network can install software products from that server instead of installing them each time from media.
4.1.1.2 Depot Registration To make the software in a depot available for use by SD-UX commands across a network, you must register the depot. You can also unregister a depot if you do not want it to be available. See “Registering and Unregistering Depots (swreg) ” (page 123) for more information. 4.2 Copying Software Depots The swcopy command copies software between depots.
Table 4-3 Copy Process Steps (continued) V. Analysis (Preview) swcopy determines if the copy operation can succeed. VI. Copy The actual software copying process. Step I: Start-Up To start the GUI or TUI for an copy session, type: /usr/sbin/swcopy The GUI is automatically invoked unless you also specify software on the command line. To invoke the GUI and specify software, include the -i option.
a. Click on a depot in the list. b. Click OK. The Target Depot Path dialog disappears. The depot you selected is now displayed in the Select Target Depot Path dialog. 2. Click OK. The Select Target Depot Path dialog disappears, and the Specify Source dialog is highlighted. Step III: Specify Source In this step, you must specify the source depot that contains the software you want to copy.
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.
• • • 3. Add New Codeword lets you add a new codeword to unlock protected software. (This option is available only when SD-UX detects that the source contains protected software.) Show Description of Software (available only for a single item highlighted in the object list) displays more information on the selected software. Change Target... returns you to the Select Target Depot Path dialog (“Step II: Specify Target” (page 114)). Select Actions→Copy to start the analysis (preview) step.
— How much will be available after the copy, — What percent of the disk’s capacity will be used. — How much space must be freed to complete the operation. Menu choices in this window let you: — Search the object list. — Open items to look at the projected size requirements for specific filesets. • Re-analyze repeats the analysis process. Figure 4-5 Disk Space Analysis Window When Analysis completes, the status for any host displays as either Ready or Excluded from task.
Ready with Errors At least one product selected will be copied. However, one or more products selected are excluded from the task because of analysis errors. Errors and warnings are logged in the logfile. Communication failure Contact or communication with the intended target or source has been lost. Excluded due to errors Some kind of global error has occurred. For example, the system might not be able to mount the file system.
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). Product Summary display copy and product information (name, revision, copy results, copy summary, product description). Logfile displays the logfile. 4.2.
-S session_file Run the command based on values saved from a previous session, as defined in session_file. See “Session Files” (page 51). -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” (page 49). -x option=value Sets a command option to value and overrides default values or a values in options files. See “Changing Command Options ” (page 121). -X option_file Read session options and behaviors from option_file.
Table 4-4 swcopy Command Options and Default Values • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • admin_directory=/var/adm/sw agent_auto_exit=true agent_timeout_minutes=10000 allow_split_patches=false autoremove_job=false autoselect_dependencies=true autoselect_minimum_dependencies=false autoselect_patches=true autoselect_reference_bundles=true codeword= compress_files=false compress_index=false controller_source= create_target_path=true customer_id= distribution_source_directory= /var/spoo
To copy a list of software selections (on a local CD-ROM) named in the file mysoft to a depot at the path /depots/mydep/ on the host named hostA and preview the process before actually copying the software: swcopy -p -f mysoft -s /mnt/cd @ hostA:/depots/mydep/ 4.2.4.2 Using Software Codewords and Customer IDs The swcopy command may prompt you for codewords if you try to access codeword protected software. You can also enter new codewords from the command line or from the GUI.
4.3.1 Register Media or Create Network Depot? When does it make sense to use your software media as a registered depot versus using the media to create a network depot? In general, using media as a depot makes sense for small-scale use, such as when only one or two other systems need to access the media. If more systems will need to access the media, performance will be better if you create a network depot from the individual media.
-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” (page 51). -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. See “Session Files” (page 51).
4.3.5 swreg Examples To unregister a CD-ROM depot mounted at /mnt/cd, you would type: swreg -l depot -u /mnt/cd To register the same depot (mounted at /mnt/cd on the local host) as a depot to be available on the network, type: swreg -l depot /mnt/cd The following example enables direct access from one or two other systems to the HWEnable11i depot on the Support Plus CD, assuming the Support Plus CD is mounted at/cdrom: swreg -l depot /cdrom/HWEnable11i 4.
# swpackage -x media_type=tape -s /depots/mypatches \ @ /tmp/mypatches.depot # swlist -d -s /tmp/mypatches.depot To create a tape depot from myproduct.psf, a valid product specification file: # swpackage -x media_type=tape -s myproduct.psf \ @ /tmp/myproduct.depot # swlist -d -s /tmp/myproduct.depot See Chapter 10: “Creating Software Packages ” (page 217) for more information about swpackage. 4.4.
2. 3. 4. create a new volume group or extend an existing volume group. For help, see either SAM help or the Managing Systems and Workgroups manual. Login as root and mount the logical volume on a new directory named /update. This directory will hold your network depot. Insert the HP-UX 11i CD1 and wait for the CD drive’s busy light to stop blinking. Find the CD-ROM device file name: ioscan -fn | more A typical CD-ROM device name is: /dev/dsk/c1t2d0 5.
swpackage -x layout_version=0.8 ... From then on, your 11i system can maintain the 10.20 depot. — SD-UX will generate warnings if you attempt to put layout_version=1.0 software (11.00 or 11i format) into a layout_version=0.8 (10.20) depot. 4.4.6 Listing Registered Depots swlist can display lists of registered depots residing on a host. To do this, use combinations of the -l depot option.
VUE WINDOWS 1.3 2.06 5489 10423 Vue (Instant Ignition Release) Windowing Products List the media attributes of the local tape depot, /dev/rmt/0: swlist -d -v -l depot @ /dev/rmt/0 type tag description number date distribution CORE OS HP-UX Core Operating System Software Disc B2358-13601 June 1991 List the products stored in the software depot on host1 located at /swmedia.
swverify -d \* @ /var/spool/sw NOTE: The swverify command does not execute vendor-supplied verification scripts within a depot. 4.4.10 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.
5 HP-UX Patching and Patch Management HP releases patches to deliver incremental updates to your system. Patches are best known for delivering defect fixes, but also deliver new functionality and features, enable new hardware, and update firmware. You can use HP-UX patches to update HP-UX software without having to completely reinstall your system application. The Patch Management User Guide for HP-UX 11.
6 Using Jobs and the Job Browser This chapter describes SD-UX jobs and the Job Browser interface for remote operations. For additional information on remote operations, see Chapter 7: “Remote Operations Overview” (page 151). Table 6-1 Chapter Topics Topics: “Introduction ” (page 135) “Using the Job Browser ” (page 136) “Monitoring Jobs from the Command Line” (page 145) “Managing and Tuning Jobs with Command Options” (page 148) 6.
6.2 Using the Job Browser Figure 6-1 The SD Job Browser Window The window is divided into three parts: • • • Menu bar, which contains most of the standard SD-UX menus discussed in “Using the GUI and TUI Commands” (page 31). 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. Under the icon is the job title. To select a job, click on the icon.
Figure 6-2 Copy Icon This icon represents a copy job (depot to depot). A check mark indicates that the job has completed. Figure 6-3 Active Install Job Icon This icon represents an install job. The ruler on the side indicates that the job is active. Figure 6-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. 6.
Figure 6-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 6-6 Install Job with Errors Icon This icon represents an install job that completed, but contained errors. The background around the icon is red. Figure 6-7 Scheduled Remove Installed Software Job Icon This icon represents a scheduled remove job on installed software.
Figure 6-8 Scheduled Remove Depot Software Job Icon This icon represents a scheduled remove job on software contained in a depot. Figure 6-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. 6.2.2 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 6.2.2.
6.2.3 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” (page 36). Note, however, that the Columns... choice is only valid for View→By Properties (discussed below). Figure 6-10 Jobs Displayed by Properties 6.2.3.
6.2.4 The Options Menu The Options menu allows you to control the optional behavior of the Job Browser. 6.2.4.1 Changing the Refresh Interval By default, the Jobs List is refreshed every minute. You may want the list updated more frequently if you are monitoring a lot of jobs. Or, you can turn off the automatic refresh feature to improve performance. To change how often the list is updated: 1. 2. Choose Options→Change Refresh Interval.... The Refresh Interval dialog is displayed.
6.2.5.1 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. Choose an action by clicking with either mouse button. Double clicking on a job displays the Job Results dialog (same as Actions→Show Job Results....) 6.2.5.2 Creating a Job To create a job, choose Actions→Create Job.
Figure 6-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. Showing only warnings or errors can reduce the number of targets displayed. 6.2.5.4 Showing Job Descriptions Selecting Actions→Show Job Description...
Figure 6-13 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... displays the Job Results dialog, which shows the latest status information on the job. Select OK in the Job Description dialog to return to the Job Browser. You can display the same information by double clicking on a job. 6.2.5.5 Showing Job Logs Selecting Actions→Show Job Log...
This feature gives you the same advantages as using a session file in swinstall, swremove, or swcopy session. This can help you: • • • Distribute the same software to a new set of targets Distribute new software to a previously defined set of targets Change a job from preview to full execution To copy a job: 1. 2. Select the desired job icon or listing in the job list. Choose Actions→Create Job from Selected Job.... The SD-UX program that matches the original job is automatically invoked.
Syntax swjob [XToolkit_Options][-i][-R][-u][-v][-a attribute] [-C session_file][-f jobid_file] [-S session_file][-t target_file][-x option=value] [-X option_file][jobid][@ target_selections] Options and Operands 146 XToolkit_Options X window options for use with swjob -i. See “XToolkit Options and Changing Display Fonts ” (page 46). -i Starts the SD interactive job browser. See “Using the Job Browser ” (page 136). -u Causes swjob to remove the specified jobs.
Changing Command Options You can change the behavior of this command by specifying additional command-line options when you invoke the command (using the -xoption) or by reading predefined values from a file. The following table shows the defaults and options that apply to swjob.
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 logoption lets you display log files for jobs. A job log file summarizes job details and target actions. For example, to display the depot log file for the job swbash3-0008 on remote system swbash3: swjob -a log swbash3-0008 @ swbash3:/var/spool/sw NOTE: log.
For example, to install the C and Pascal products from depot sw_server to three remote hosts with a job title of 02-HLLs: # swinstall -s sw_server -x job_title=02-HLLs cc pascal \ @ hostA hostB hostC 6.4.3 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.
7 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.
information on the task’s status. The controller also distributes software to remote target machines. On each target, the SD-UX daemon runs in the background, listening for requests coming from the controller. When a request is received, the daemon schedules the SD-UX agent to perform the task. The daemon also schedules the agent to answer requests from other agent programs that want to use one of the host’s depots as a source.
7.1.1.7 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” (page 153).) 7.1.1.8 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.
NOTE: The Terminal User Interface (TUI) is not available with remote operations. 7.2.1 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.
7.2.3 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” (page 158)). The Target Selection Window displays a list of targets may be displayed: • • If you have recalled a session file (File→Recall Session), any hosts defined in that session are displayed.
Window. Networking may cause delays; if the SD-UX daemon is not running on the target, the delay lasts until the daemon times out. From the Target Selection Window, any targets added using Add Targets... are automatically marked Yes. 6. If there are any other desired targets in the Target Selection List that are not marked and you want to install to them, highlight the target by clicking on it. Choose Actions→Mark for Install. The Marked? column is set to Yes for that target.
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/.sw/targets 2. To save the group, click OK. This saves all the target selections you have just marked (all targets listed with Yes in the Marked? Column).
• • • 2. controller is the name of the central management server. If the remote system is running HP-UX 11.00, make sure SD patch PHCO_22526 or a superseding patch is installed on the remote system before running setaccess. If the remote system is older than HP-UX 11.00, or for some other reason does not have setaccess in place, copy the setaccess script from an HP-UX 11.11 or higher system to the remote system. swinstall, swcopy, and swremove have enhanced GUI interfaces for remote operations.
swpackage -s psf @ /var/adm/sw/examples/depot swreg -l depot @ /var/adm/sw/examples/depot 7. To verify that the software is in the depot and is available for distribution to targets, enter: swlist -s /var/adm/sw/examples/depot You should see SD-DATABASE in the resulting list. 7.4.2 How to Perform a Single-Target Installation Overview The tutorial consists of these steps: Table 7-2 Installation Steps Overview of Installation Steps I. Start-up Start the Job Browser. II.
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 7-3: “Target Selection Window”,). Figure 7-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.
For remote targets: choose Actions→Add Targets to install to a different target. This takes you to the Add Targets dialog (Figure 7-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 7-4 Add Target Dialog (for multiple or non default targets) 3. 4. 5. Use the current root path (/) by selecting OK. This returns you to the Add Targets dialog.
Figure 7-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... field and the example depot that you created (/var/adm/sw/examples/depot) in the Source Depot Path... field. From this dialog, you can also: • • Click on the Source Host Name... button to display a list of hosts that you can select from. Click on the Source Depot Path... to display a list of registered depots that you can select from. Click OK.
Figure 7-6 Software Selection Window 1. 2. Highlight SD-DATABASE (i.e., the example software) by clicking on it with the left mouse button. 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. Table 7-3 Software Selection List Software Selection Window Object List The Software Selection Window object list is hierarchical: you can open each object in the list and show objects contained inside.
Step V: Specify Install Preferences The Install Preferences dialog box gives you the following optional selections: Preview, Schedule, and OK.You can also enter a Job Title. Figure 7-7 Install Preferences Dialog 1. Select the text area after Job Title and type: SDTESTJOB 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 7-8 (page 165)). 3. 4.
preview job progress from the Job Browser. See “Step VII: Monitor Results ” (page 166) for more information.) 5. (Optional) Scheduling a Job a. Select the Schedule button. This activates the fields that let you specify the time and date you at which you want your job to run. (For example, you may want to schedule a job at midnight when few users are logged in.) b. After you specify the schedule information, click OK. The system displays a note indicating that the job has been scheduled. c.
Figure 7-9 Install Window dialog 2. 3. 4. Select Done to exit the Install Window dialog. This returns you to the Target Selection Window. Select File→ Exit to return to the Job Browser. (Optional) Select another target for installation (i.e., Actions→Mark for Install). 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.
1. 2. 3. Select the job icon and right click. Select Actions→Remove Job... from the pop-up menu. The Remove a Job dialog appears, displaying SDTESTJOB. Select OK. The SDTESTJOB icon disappears from the Job Browser and the job is removed from the SD-UX database. 7.5 Remote Interactive swlist For remote operations, the swlist -i command starts a list browser that lets you interactively list installed software on remote hosts.
7.6.1 Target Selections By definition, you must specify a remote target for a remote operation. Unlike local operations, in which a target could be a directory on the local host system, you must specify remote systems as targets for remote operations. swinstall -s sw_server cc pascal @ hostA hostB hostC (This installs the C and Pascal products onto three remote hosts.) 7.6.1.1 Syntax Software and source depot selections are followed by target selections.
swacl -l global_product_template @ gemini 7.6.2.2 swask To run all request scripts from depot /var/spool/sw on the remote system swposix and write a response file back to the same depot: swask -s swposix:/var/spool/sw \* 7.6.2.3 swconfig To configure the C and Pascal products on three remote hosts: swconfig cc pascal @ hostA hostB hostC 7.6.2.4 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 7.6.2.
7.6.2.
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.
These options and features can be categorized as follows: • • • • • • • • • • Group and source options: SD-UX eliminates the need to duplicate specification of commonly used groups of targets and software. Also, using the source option to specify a main depot reduces the number of dialog boxes. Large numbers of targets: Options that limit the number of simultaneous targets.
8.3 Large Numbers of Targets The max_targetsoption 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.
The default value for retry_rpc is 1 and retry_rpc_interval is {0}. The recommended values for the retry_rpc_interval algorithm are {1 2 4 8 15} with retry_rpc set at 5. If the agent session fails to start for any reason, the controller and/or target will attempt to re-connect in the following way (i.e.
If the reinstall_files_use_cksum option is false, then only the size and mtime are checked. Checking the checksum attribute is more time consuming but more reliable. The size and mtime checks are very fast. The user can see which files were actually installed or copied and which were skipped due to being already up to date by setting the loglevel option to 2. 8.
You can use swcopy to compress files and leave them compressed in a target depot or compress before network transfer and uncompress afterward. Precompressing a depot is advantageous when installing or copying to multiple targets. If the source depot is not already compressed, then each file is recompressed for each target. You can set uncompress_files to true to leave a depot uncompressed after copying with swcopy.
By doing so, you also decrease the likelihood that a problem with the WAN will interrupt the installation step. Before you do a staged installation, you must first decide where the intermediate depots should reside. Here are two possible approaches: 1. 2. If the targets are grouped, you can put an intermediate depot on one system in each group and configure the other targets to use it as their alternate source.
depot specified by swagent.alternate_source. An alternate source is specified using the host:/path, /path, or host syntax. • • If there is a host:/depot_path specified in the target’s swagent.alternate_source option, the agent gets the software from this source. If only a host is specified, the target agent uses the same depot path used by the controller.
1. 2. Execute the product preinstall script For each fileset a. execute the preinstall script b. install the files c. execute the postinstall script 3. Execute the product postinstall script 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.
swlist -l product -a software_spec A common practice is to install a second version of the product. When installing this software, a new location must be selected. In the case of the product Foo, the new location might be /opt/foo.v2. After specifying the new location (i.e., by adding l=/opt/foo.v2 after the product tag in the GUI or CLI), swinstall will replace the product directory portion of all files with the new product location.
NOTE: The use of allow_multiple_versions=true command option and the l= software specification is not supported when updating HP-UX to a new version. 8.
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.
• • Whoever creates a root, depot, or product object has full access to it as the object_owner. If you set up systems for remote operations (using the procedure discussed in “Setting Up Remote Operations” (page 157)), root@central_controller has full access to all target objects via the user:root@central_controller ACL. If you are running as root@central_controller, the suggested security setup should be adequate to perform all tasks.
global_product_template. (See “ACL Templates ” (page 202) for a complete discussion.) 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. If you don’t specify a -D, -F, or -M option, swacl prints the specified ACLs. -D acl_entry Deletes an existing entry from the ACL associated with the specified object. You can enter multiple -D options.
Table 9-2 swacl Command Options and Default Values • • • • • • • admin_directory=/var/adm/sw distribution_target_directory=/var/spool/sw installed_software_catalog=products level= log_msgid=0 lookupcache_timeout_minutes=10 rpc_binding_info=ncacn_ip_tcp:[2121] ncadg_ip_udp:[2121] • • • • • • rpc_timeout=5 run_as_superuser=true select_local=true target_directory= targets= verbose=1 For More Information See Appendix A (page 299) for complete descriptions of each default. 9.2.
9.3 Basic Security Tasks Along with the traditional HP-UX file access protection, authorization to access all SD-UX objects (hosts, depots, roots, and products) is supplied by ACLs. Figure 9-1 Access Control Lists Host Object ACL Host Object Depot Object ACL Depot Object ACL Depot A Root Object ACL Depot B Root Object ACL Root A Product ACL Product ACL Product ACL Product ACL Product M Product N Product P Product Q M P Root B Q N M (Installed Products protected by Root ACLs.
• • • • • • Allowing users to manage roots Restricting read access to a depot Adding target hosts Temporarily restricting access to a depot Closing the SD-UX network Editing an ACL 9.3.1 Listing User Access The following examples show how to list users with access to depots, targets host, target root, and all products.
user:rmr:crwit user:root:crwit user:fred@hpfred.fc.hp.com:crwit user:root@hpfcpsm.fc.hp.com:crwit user:root@wookie.fc.hp.com:crwit any_other:-r--- • To show access to installed software: swacl -l root @ newdist # swacl Installed Software Access Control List # # For host: newdist: # # Date: Fri Nov 03 10:33:04 2001 # # Object Ownership: User= root # Group=other # Realm=newdist.fc.hp.com # # default_realm=newdist.fc.hp.
# # swacl Product Access Control Lists # # For depot: newdist:/var/spool/sw # # Date: Fri Nov 03 10:34:06 2001 # # For product: product1,r=1.0 # # 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--- 9.3.2 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.
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 on host swelter fully manage the root file system: swacl -l root -M user:allen@swelter:a To let remote user allen at any host having hostname starting with 'sw' fully manage the root file system: swacl -l root -M user:allen@sw*:a (In the above examples, change user to group and use a group name to add group access to the depot structures.
# # 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.
# swacl -l depot -M host:*:r # swacl -l product -M host:*:r \* # swacl -l global_product_template -M host:*:r To allow all hosts on domain fc.hp.com read permission: # swacl -l depot -M host:*.fc.hp.com:r # swacl -l product -M host:*.fc.hp.com:r \* # swacl -l global_product_template -M host:*.fc.hp.com:r NOTE: type. "*" and "?" wildcards are allowed anywhere in the hostname for host ACL 9.3.
You must have test permission within the ACL to produce the edit file (list the ACL) and control permission to modify it with -F, -D, or -M options. All ACL entries must contain test permission. If the replacement ACL contains no detectable errors and you have the proper permission on the ACL, the replacement will succeed. If the replacement fails because you lack permission to make the change, an error is generated, and the object is skipped.
# 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 user in group swadm at remote hosts dewd and stewd full management cont
9.5 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.
There may be many user, group, and host type entries per ACL, while there may be only one of each of object_owner, object_group and any_other. There may be at most one local (i.e., no key) other entry and an unlimited number of remote (i.e., keyed) other entries. 9.5.1 ACL Keys The second part of the ACL entry is the key. The table below lists the possible key values for specific entry types.
Product level protection is provided on depots in this way: the depot’s ACL protects the depot itself while product ACLs protect the products within the depot. The table below summarizes SD-UX object permissions and ACLs to which they may be applied.
The rationale for this protection scheme is borrowed from a mechanism introduced in the BSD file system. With write permissions on a BSD directory, you may create a file in the directory. If the sticky mode bit is set on the directory, only the file owner, the directory owner, or superuser may remove or rename the file. For example: In /tmp, owned by root, with “wide-open” write permission and the sticky bit set manually (i.e.
A sample host-system ACL grants depot and root source creation, source listing, and ACL administration to a user named rob and give open permission to list the depots and roots on the host, would be: user:rob:r-icany_other:r Since any_other does not havet (test) permission, only rob can list this ACL, because he has c (control permission). 9.5.3.2 Root ACLs Principals (users) identified in ACLs that are protecting roots are granted permission to manage installed products.
A sample depot ACL that grants its creator all permissions; user george permission to list and insert software products; members of group swadm permission to list and insert products, change the ACL and delete the depot itself; and everyone else permission to list the contents of the depot, would be: object_owner:crwit user:george:-r-igroup:swadm:crwiany_other:-r- When a depot source object is created, it is automatically protected by a default ACL derived from its host.
NOTE: When a product object is created, it is automatically protected by a default ACL from the depot/root source or, absent that, one from the host. 9.5.4 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).
Thus, there are three ACLs on the host: • Host ACL Attached to and controlling access to the host object itself. • Container ACL Template (global_soc_template) Used to initialize the ACL protecting new depots and roots created on the host. • 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.
Host ACL • The host ACL below allows global (any_other) permission to list the depots and roots on the host: object_owner:swadm:crwit any_other:-r--- NOTE: Remember, the local superuser always has all permissions, even without an ACL entry. 9.5.4.1.1 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.
shows that: • • • • • • File owner is user doug. File’s group is admin. Name of the file is datafile. Owner permissions are read, write and execute (rwx). Group permissions are read and execute (r-x). Other permissions are read only (r-). SD-UX commands are essentially object managers that use the SD-UX file system in which to store their objects.
9.7 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.
9.7.1.1 Controllers Run with the User’s Credentials and Privileges SD-UX controller programs such as swinstall or swremove operate with the privileges of the user who invokes them. The agent ensures that the user has the required permissions on the object by looking at the object’s ACL. If permissions are not granted, the operation fails. A controller may be run by anyone on the system, but its actions are restricted (based on permissions granted in various object ACLs).
For example, if the controller is running on alma.fc.hp.com and makes a request of an agent running on lehi.fc.hp.com, each of the two processes will look up the secret associated with alma.fc.hp.com (the controller’s host) from their respective secrets file. Here is an example of the format of the shared secrets file: default lehi.fc.hp.com alma.fc.hp.com newdist.fc.hp.com noway.fc.hp.
required for the operation are all granted by the entry, access is authorized, and SD-UX proceeds with the requested operation. 9.8.1 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.
As a special case, the superuser always has full permissions on a local system. 9.8.2 Local Superuser Authorization As a special case, SD-UX always allows the local superuser full access to all local objects regardless of ACL protections. This allows the local superuser to repair corrupted ACLs or to perform any other operations. 9.8.2.
provide the /etc/logingroup link to /etc/group to activate HP-UX supplementary groups. NOTE: /etc/logingroup is an HP-UX utility to support both SVR2/3 and BSD group semantics selectively. When /etc/logingroup is linked to /etc/group, HP-UX gives BSD (and SVR4) semantics. If the file /etc/logingroup does not exist on systems targeted as SD-UX Controllers, execute the following command (as superuser) on each appropriate system: ln -s /etc/group /etc/logingroup 9.9.
products is allowed by unrestricted read access to hosts, depots, and products. This is the basis of a pull model of software distribution. 9.9.2.1 Restricting Installation to Specific Target Systems by Specific Users Managers of software source depots may leave software openly installable, as described above, or may choose to limit distribution to specific systems.
9.10 Permission Requirements, by Command 9.10.1 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. 9.10.2 Listing (swlist) • • To list potential depots, the source agent verifies that the controller user has read permission on host.
9.10.5 Installing (swinstall) • • • • Any list operations required to facilitate this function must be checked as described in the swlist section above. The target agent verifies that the controller user has insert permission on the target root. The target agent verifies that the controller user has write permission on the target root, if the product already exists. The source (depot) agent verifies that the target agent system has read permission on the source product. 9.10.
9.10.11 Request Scripts (swask) • To query a user and obtain installation information, interactive control scripts are used. 9.10.12 Modify (swmodify) • To change or add information to the Installed Products Database (IPD) or depot catalog files, write permission is required. 9.
10 Creating Software Packages This chapter describes the tasks associated with packaging software for distribution. Table 10-1 Chapter Topics Topics: “Overview of the Packaging Process ” (page 217) “Identifying the Products to Package ” (page 218) “Adding Control Scripts” (page 219) “Creating a Product Specification File (PSF) ” (page 220) “Packaging the Software (swpackage) ” (page 249) “Packaging Tasks and Examples” (page 256) 10.
10.1.1 Prerequisites Before you begin packaging software, ensure the following: • • SD-UX is installed and configured on the system where you intend to create your software package. The software to package is installed on the packaging system, or that the necessary files are available remotely. 10.2 Identifying the Products to Package 10.2.1 Determining Product Contents The first step in packaging software is to determine what files and directories you want included in the software product.
NOTE: You can define different versions of products for different platforms and operating systems, as well as different revisions (releases) of the product itself. You can include different product versions on the same distribution media. 10.3 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.
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.) Unpreinstall An undo preinstall script in case SD must initiate recovery during the install process. (Executed by swinstall.) Verify Verifies the configuration of filesets or products in addition to the standard swverify checks. (Executed by swverify.) 10.
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. 10.4.1.2 Typical PSF Here is a sample PSF that describes the SD-UX product: # PSF defining SD as a sample product. depot layout_version 1.0 # Vendor definition: vendor tag HP title Hewlett-Packard Company description < data/description.
subproduct tag Manager title Management Utilities contents commands agent data man end subproduct tag Agent title Agent component contents agent data man end # Fileset definitions: fileset tag commands title Commands (management utilities) revision 2.42 description < data/descr.commands # Dependencies corequisites SD.data corequisites SD.agent # Control files: configure scripts/configure.commands # Files: directory ./commands=/usr/sbin file swinstall file swcopy # (...Other file definitions can go here...
10.4.2 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.
Table 10-2 Keywords Used in the Product Specification File (continued) Keyword Value Max Size in Example bytes vendor tag description title tag_string multi_line_string one_line_string 64 8K 256 HP
Table 10-2 Keywords Used in the Product Specification File (continued) Keyword fileset * tag ancestor architecture category_tag corequisite description exrequisite is_kernel is_patch dynamic_module is_reboot is_sparse machine_type os_name os_release os_version prerequisite * revision supersedes title Value Max Size in Example bytes tag_string repeatable list of product.
10.4.2.1.1 Control Files SD-UX supports execution of control files (also known as control scripts) at the product and fileset level. Control scripts let you perform additional checks and operations. The swinstall, swconfig, swverify, and swremove commands each execute one or more vendor supplied scripts. All scripts are optional but many times are needed correctly complete the task that you want your software package to perform.
For a more complete description of PSF requirements for layout_version=0.8, refer to the swpackage.4 manual page in a previous version of HP-UX. 10.4.2.3 PSF Value Types With the exception of vendor-defined attributes (see “Vendor-Defined Attributes” (page 230)), 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.
one_line_string • • • • path_mapping_string • • • path_string • • • permission_string • • Maximum length: 256 bytes One-line strings support a subset of isascii characters only. (Refer to the ctype(3) manpage.) No isspace characters, except for space and tab, are allowed. Examples: Hewlett-Packard Company Maximum length: none A value of the form: source[=destination] where the source defines the directory in which subsequently defined files are located.
• • revision_string • • • software_specification • • • tag_string uname_string SD-UX will not override existing permissions based on this attribute if a file already exists on a target. Examples: -u 0222 -o root -g sys Maximum length: 64 bytes Revision strings contain zero or more dot-separated one_line_string (above). Examples: 2.0, B.11.00 Maximum length: none Software specifications are used to specify software in dependencies, ancestors and other attributes, as well as command line selections.
• • Patterns can be “ORed” together using the separator: | Examples: 9000/7*:*|9000/8*:*, HP-UX, ?.11.* 10.4.2.4 Product Specification File Semantics The following sections describe how to specify a PSF and defines keywords. 10.4.2.4.1 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.
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.8 syntax, which continues to be supported. (You can also select the layout version with the layout_version option for swpackage, swmodify, swcopy, or swlist.) See “Selecting the PSF Layout Version ” (page 226) for more information. tag The short name of the target depot (tape) being created/modified by swpackage.
NOTE: The vendor specification is not the same as vendor-defined attributes. See “Vendor-Defined Attributes” (page 230) for more information. vendor Keyword that begins the vendor specification. tag Defines the identifier (short name) for the vendor. title Defines the full name (one line description) for the vendor. description Defines the multi-paragraph description of the vendor; the value is either the text itself (within double-quotes) or a pointer to the filename containing the text.
description A multi-line description of the category. The description value can consist of text or a filename for a text file. 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.
For each product object specified, swpackage requires only the product and tag keywords, plus one or more fileset definitions. For each bundle specified, swpackage requires the bundle, tag and contents keywords. 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.
is_patch A boolean flag that identifies a software object as a patch. The default value is false. When set to true, a built-in category_tag attribute of value patch is automatically included with the product definition. machine_type The system type on which the product will run. If not specified, the keyword is assigned a wildcard value of *, meaning it will run on all machines. If there are multiple platforms, you must separate each machine designation with a | (vertical bar).
postkernel Defines a kernel build script to be executed when kernel filesets are loaded. Kernel filesets have the is_kernel attribute set to true. The default kernel script is /usr/sbin/mk_kernel. (See the manual reference page for mk_kernel(1M) for more information.) The default script executes when the postkernel attribute is not specified. Only one kernel build script is allowed per product, and the script executes only once, even if defined for multiple filesets.
contents A whitespace-separated list of the subproduct’s fileset tag values (that is, contents fileset1 fileset2 fileset3 ...filesetN). In the PSF, fileset definitions are not contained within subproduct definitions. The contents keyword is used to assign filesets to subproducts. This linkage allows a fileset to be contained in multiple subproducts. description A multi-line description of the subproduct; either the text itself (within double-quotes), or a pointer to the filename that contains the text.
tag The fileset identifier (short name). architecture Describes the target system(s) on which the fileset will run if filesets for multiple architecture are included in a single product. Provides a human-readable summary of the four uname(1) attributes which define the exact target system(s) the product supports. Many filesets do not include an architecture; only a product architecture need be defined.
dynamic_module A space-separated list of strings specifies the list of dynamically loadable kernel modules (DLKMs) packaged into the fileset. The dynamic modules themselves must be delivered to /usr/ conf/mod/. If the dynamic_module attribute is omitted, no DLKMs may be delivered in the fileset. When a dynamic module is packaged, it is customary to include a call to the control_util mod_systemfile in a postinstall script to link the module to the kernel.
9000/[78]??:*64 Series 800, 64-bit capable hardware required. The value is matched against a target’s uname -m or getconf _CS_HW_CPU_SUPP_BITS result. 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.
You can also define dependencies between: • • • A fileset and another product (namely, a subset of that product). A particular fileset within that product. The entire product. SD-UX supports these types of dependencies: Corequisite Software that must be present for a fileset to operate correctly. For example, specifying a corequisite for an install fileset means that the corequisite must be installed or being installed when the fileset itself is installed.
10.4.2.4.10 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. You can write the scripts and include them in your software package.
10.4.2.4.11.1 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.
• Set the owner write permission in addition to the above: file_permissions • -u 022 -o 2 -g 2 If you do not define file_permissions, swpackage uses the default value file_permissions -u 000 for destination file objects based on existing source files. (Meaning the mode, owner/uid, group/gid are set based on the source file, unless specific overrides are specified for a destination file.) 10.4.2.4.11.
source This value defines the path to a file you want to include in the package. If this is a relative path, swpackage will search for it relative to the source directory set by the directory keyword. If no source directory is active, swpackage will search for it relative to the current working directory in which the command was invoked.
and gid attributes are set for the destination file based on the packaging host’s /etc/group. If only the gid specified, it is set as the destination’s gid attribute and no group name is assigned. If both are specified, each sets the corresponding attribute for the file object. On systems that support numeric groupnames, to specify a numeric groupname, both the numeric groupname and the gid must be supplied. If a numeric groupname alone is specified, it is interpreted as a gid.
• 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.cat nls/en_US.88591/swinstall.
The directory keyword must have been previously specified before the file * specification can be used. If not, swpackage generates an error. Error Messages When processing the directory recursively, swpackage encounters the following errors: • • • Cannot search directory (permission denied) Cannot read the file (permission denied) Unsupported file type encountered 10.4.2.4.11.5 PSF Extensions A PSF can contain extended file definitions. SD currently supports exclude and include files.
file -v 4 file -v 5 This also works well for permissions. For example, assume that nearly all the 100 files in the preceding example had the same permission attributes, but files 1, 2, and 3 required a different owner and mode: directory source = /product file_permissions -o bin -g bin -m 555 file * file_permissions -o root -g other -m -04555 file 1 file 2 file 3 This capability combines the recursive file specifications function with explicit file specification.
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. Build swpackage packages the source files and information into a product object, and inserts the product into the distribution depot.
Phase I: Selection When you run swpackage, you must specify a PSF and any other options you wish to include.
3. Check for software being repackaged. For each selected product, swpackage checks to see if the product already exists in the target depot. • • 4. If it does exist, swpackage checks to see which filesets are being added (new filesets) or modified. If it exists and all filesets are selected, swpackage checks to see if any existing filesets have been obsoleted by the new product.
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). To create the tape, swpackage first builds the products into a temporary distribution depot. (The depot is removed when swpackage completes.
-C session_file Run the command and save the current option and operand values to a session_file for reuse in another session. See “Session Files” (page 51). -d directory|device If creating a distribution directory, this option defines the pathname of the directory. If creating a distribution tape, this option defines the device file on which to write the distribution. When creating a distribution tape, the tape device (file) must exist, and the target_type=tape option must be specified.
operand, swpackage uses the device file, /dev/ swtape. Changing Command Options You can change the behavior of this command by specifying additional command-line options when you invoke the command (using the -xoption) or by reading predefined values from a file. The following table shows the options and default values that apply to swpackage.
======= 01/27/01 18:58:45 MST BEGIN swpackage SESSION * Session started for user "root@sdtest.myco.com". * Source: vewd:test.psf * Target: vewd:/var/spool/sw * Software selections: * * Options: preview true verbose 1 loglevel 1 logfile /var/adm/sw/swpackage.
Registration provides a type of public recognition for the packaged depot: • • You can see the depot in the swinstall/swcopy GUI and see it in swlist depot-level listings. You can read products from the depot (for example, to install). For more information about registering depots, see “Registering and Unregistering Depots (swreg) ” (page 123). NOTE: If the only use of a depot created with swpackage is local access by the packaging user, depot registration is not required. 10.6.
type with the compression_type option or specify a compression command with the compression_command option. This option should be set to true only when network bandwidth is clearly restricting total throughput. If it is not clear that this option will help, compare packaging operations both with and without compression before consistently using this option. See Appendix A (page 299) for more information on using command options. NOTE: swpackage cannot compress files when writing to a tape. 10.6.
3. Can you modify an existing product? Superuser Yes Other Yes, if the ACL for the existing product grants you write permission, i.e. permission to overwrite/change the contents of the product. If you are denied authorization to change an existing product, swpackage generates an error message and excludes the product from the session. If you are denied insert and write permission for all selected products, swpackage terminates with an error. 4.
When no ACL exists for a depot, only the superuser can create new products or add/modify depot attributes. When no ACL exists for a product, only the superuser can modify it. 10.6.5 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.
# swremove -d product @ depot # swpackage -s psf product @ depot 10.6.6 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. Instead, swpackage inserts references to the source files that make up the contents of each fileset. Control scripts are always copied.
This option is time consuming, especially when a what search fails and the ident command is then executed. The default value for this option is false, which causes swpackage to skip the examination. No value for the revision attribute is assigned to the files being packaged. 10.6.
(This example does not specify the depot location because it is assumed that the software is located in the default /var/spool/sw on svrhost.) For more information about verifying installed software, see “Verifying Your Installation (swverify)” (page 74) 10.6.11 Packaging Patch Software A number of software attributes are available to all software levels (bundles, products, subproducts, and filesets) that permit packaging of patch software.
10.6.13 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 ...
11 Using Control Scripts This chapter discusses how to use control scripts. Table 11-1 Chapter Topics Topics: “Types of Control Scripts ” (page 266) “Using Environment Variables ” (page 273) “Execution of Control Scripts ” (page 277) “Execution of Other Commands by Control Scripts ” (page 284) “Control Script Input and Output” (page 285) “File Management by Control Scripts ” (page 287) “Testing Control Scripts ” (page 287) “Requesting User Responses (swask)” (page 291) 11.
• • • • • • • Creating links to, or additional copies of, files after they have been installed. Copying configurable files into place on first-time installation. Conditionally copying configurable files into place on later updates. Modifying existing configuration files for new features. Rebuilding custom versions of configuration files. Creating device files or custom programs. Killing and/or starting daemons. 11.1.
The postinstall script is part of the Load phase of the swinstall command. 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. All undo scripts are executed in the reverse order of the normal scripts.
when installing to a system that will actually be using the software. They are deferred when installing to an alternate root (for example, for diskless or building test file systems) and run instead by the swconfig command when the alternate root is now the root of the system using the software. The swconfig command can also be used to rerun configure scripts that failed during a normal install.
This script and the postremove script are part of the Remove phase of swremove. Within each product, preremove scripts are run (in the reverse order dictated by any prerequisites), files are removed, then all postremove scripts are run. • Postremove Scripts This script is executed just after removing files. It is the companion script to the postinstall script.
interpreter interpreter_name For example: control_file source tag interpreter scripts checkinstall ksh SD checks that the interpreter is available. If the interpreter is not available, the script fails. (To avoid this problem, you can use a checkinstall script to verify the existence of any script interpreters that you specify.) If SD finds the interpreter, it processes the script normally using the interpreter that you specified. 11.1.1.
• • • • The control scripts you write may be executed several times (for example, configure, then unconfigure, then configure...) so they must be able to support multiple executions. You may have to re-execute or debug control scripts, especially when they generate error or warning conditions, so your scripts should be well-written and commented. Control script stdout and stderr are both logged, so you should restrict output to only the information the user requires.
Table 11-2 Control Script Keywords (continued) Keyword Type Size in Bytes Example fix path_string 1024 /mfg/sd/scripts/fix space path_string 1024 /mfg/sd/scripts/space The value of each keyword is the source filename for the specific control script. swpackage will copy the specified control script’s filename into the depot’s storage directory for the associated product or fileset, using the keyword as the tag of the stored script (for example, “configure”).
NOTE: All necessary directories under /var/adm/sw will be created by the SD-UX process. All files under those directories will be filled by SD-UX initiated processes. Files must never be delivered directly under /var; it is a private directory. 11.4 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.
11.4.1.2 LC_ALL • Determines the locale used to override any values for locale categories specified by the settings of LANG or any environment variables beginning with LC_. 11.4.1.3 LC_CTYPE • Determines the interpretation of sequences of bytes of text data as characters (e.g., single-versus multibyte characters in values for vendor-defined attributes). 11.4.1.4 LC_MESSAGES • Determines the language in which messages should be written. 11.4.1.
• 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. A control_file can query the SW_CONTROL_TAG variable to determine which tag is being executed. 11.4.2.
• 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.
11.4.3.2 SW_INITIAL_INSTALL • This variable is normally unset. If it is set, the swinstall session is being run as the back end of an initial system software installation (that is, a “cold” install). 11.4.3.3 SW_KERNEL_PATH • The path to the kernel. The default value is /stand/vmunix. 11.4.3.4 SW_SESSION_IS_KERNEL • • • • Indicates whether a kernel build is scheduled for the current install/remove session.
11.5.1 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. Each script must set its own PATH variable, using SW_PATH. Neither swinstall nor swremove require that the system be shut down.
• • • • A checkinstall script determines whether the product/fileset can be installed by performing checks beyond those performed by swinstall. Example checks include checking to see if the product/fileset is actively in use, or checking that the system run-level is appropriate. If you are using a request script as part of the install, the checkinstall script should: — Verify that the response file exists.
11.5.4 Postinstall Scripts • Postinstall scripts are executed during the Load phase of a swinstall session. The pathname of the script being executed is: $ {SW_CONTROL_DIRECTORY}postinstall • • • • The postinstall script for a product is executed immediately after the fileset’s files are installed. A postinstall script should perform specific tasks related to the files just installed.
• • • Configure scripts are for architecture-dependent actions because they will always be run on the architecture of the install target. Configure scripts are the best place for removing files and updating the IPD, since the system is not in transition (i.e. as in an update). A configure script can help with software updates as well as new installs. The script must also be able to handle reinstallation and should include appropriate error control if data destruction is possible. 11.5.
11.5.8 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. 11.5.9 Checkremove Scripts • Checkremove scripts are executed during the Analysis phase of a swremove session.
• • A preremove script is executed for installations into the primary root (“/”) or an alternate root. The scope of actions of a preremove script should be within the product itself (that is, the files within the product’s directory). The de-customization or unconfiguration-configuration tasks which must be performed to disable the product/fileset for general use must not be done in a preremove script, instead they should be done in an unconfigure script (described above). 11.5.
• The POSIX default for request scripts is a shell script. The shell script must be able to: — Ask questions of the user. — Read the user’s answer. — List all current user responses in a redrawn screen. — Ask the user to confirm an answer and continue or to go back. • The request script stores the user response in a response file. The path of the response file is accessible by the SW_CONTROL_DIRECTORY environment variable.
11.7 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.
1. 2. Never emit blank lines. All output lines must have one of these forms: — ERROR: text — WARNING: text — NOTE: text — text In each case, the keyword, if there is one, must begin in column 1, and the text must begin in column 10 (indented nine blanks). 3. Choose the keyword (ERROR, WARNING, NOTE, or blank) as follows: ERROR: Cannot proceed, may need corrective action. WARNING: Can proceed, but something went wrong and may need action.
— Use uppercase first letters of phrases after colons. (This helps break up the message into digestible “bites” of information.) — Surround product, fileset, directory, and file names, and other variable-valued strings with quotes. For example: echo "ERROR: Cannot open file \"$file\"." &>2 — Write in the present tense. Avoid “would”, “will”, and similar verb tenses. Also avoid past tense except where necessary.
11.9.1 Testing Installation Scripts For checkinstall, preinstall, and postinstall scripts you should perform at least these tests. All tests can be performed on the local system (that is, by doing local installs). 1. The basic test: • Run swinstall to install the full product (that is, all the filesets). To avoid testing the configure script(s), either do not include any in the product, or set the defer_configure option to “true.
1. Run swinstall to install the full product (that is, all the filesets). Let the installation process perform the configuration task (and run your configure script(s)). • After the installation and configuration completes, check the ${SW_ROOT_DIRECTORY}var/adm/sw/swagent.log file for any problems, either in the configure script or the format/contents of the messages generated by it. • Study the resulting file system to see if the configure script performed the expected actions.
7. 8. 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.
6. operations in the new location, and not the default location. (This verifies the correct use of $SW_LOCATION by your scripts.) If you have a complex script, run additional tests for your product that you feel will give you confidence your product has been installed correctly on the system. For example, only install certain subsets of your product instead of the full product, then perform the remove operations. (Or only remove subsets of the fully installed product.) 11.
The swask command creates the catalog if it does not already exist. If the -c catalog option is omitted and the source is local, swask copies the response files into the source depot: distribution.path/catalog. -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” (page 51). -f software_file Read a list of software selections from a separate file instead of (or in addition to) the command line.
Table 11-3 swask Command Options and Default Values • • • • • • • admin_directory=/var/adm/sw ask=true autoselect_dependencies=true autoselect_minimum_dependencies=false autoselect_patches=true enforce_scripts=true installed_software_catalog=products • • • • • • • • log_msgid=0 logdetail=false logfile=/var/adm/sw/swask.log loglevel=1 lookupcache_timeout_minutes=10 patch_filter=*.* run_as_superuser=true verbose=1 For More Information See Appendix A (page 299) for complete descriptions of each default.
To install Product1 from remote depot /tmp/sample.depot.1 on host swposix and use an existing response file (previously generated by the swask command) located in /tmp/bar.depot: # swinstall -s swposix:/tmp/sample.depot.1 \ -c /tmp/bar.depot Product1 To install all products in remote depot /tmp/sample.depot.1 on 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.
12 Nonprivileged SD This chapter provides general guidelines on how to set up Software Distributor to run in nonprivileged mode. Table 12-1 Chapter Topics Topics: “Overview” (page 295) “Setting Up Nonprivileged Mode” (page 296) “Default Configuration” (page 297) “Alternative Configuration” (page 298) 12.1 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.
12.1.3 Limitations • • • • 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.
12.2.2 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. For example: • • • Including -x run_as_superuser=false on the command line invokes nonprivileged mode for that command only.
You can enable nonprivileged mode for all users by setting the run_as_superuser option to false in /var/adm/sw/defaults. Individual users can override the default chosen by the system administrator, by setting the run_as_superuser option to true or false in their $HOME/.swdefaults file or on the command line. 12.4 Alternative Configuration An alternative configuration of nonprivileged mode sets up user-installed software catalogs in each user’s home directory.
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. Table A-1 Chapter Topics Topics: “Changing Command Options” (page 299) “Options Listed Alphabetically” (page 300) A.1 Changing Command Options Changing the option values lets you change command behavior and tailor SD-UX policies to your needs.
[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.
Applies to all commands except swagent, swagentd, and install-sd. • agent=/usr/lbin/swagent This is the default location of the executable invoked to perform agent tasks. Applies to swagentd. • 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.
If false (default), prohibit the packaging/modifying of a file with size greater than or equal to 2 gigabytes. If true, permit the packaging/modifying of a file with size greater than or equal to 2 gigabytes. If the file is packaged or modified in a depot, then the depot can only be used by HP-UX 11i v1 (B.11.11) December 2005 SD, 11i v2 (B.11.23) December 2005 SD, 11i v3 (B.11.31) SD, and newer releases of SD.
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. Likewise, removing a fileset when this option is false causes sibling filesets to be removed at the same time.
If the auto_kernel_build option is set to true, the autoreboot option must also be set to true. If the auto_kernel_build option is set to false the value of the autoreboot option does not matter. Applies only to swremove. 304 • autoreboot=false Normally set to false, indicating that installation of software requiring a reboot is not allowed from the command line. If set to true, this option allows installation or removal of the software and automatically reboots the local host.
Browser or with swjob. Running very large numbers of jobs may take up significant disk space. Setting this option to true prevents SD-UX from storing the job information. The trade-off is that you can no longer display the job information. This option is automatically set to true when run_as_superuser is set to true. Applies to swconfig, swcopy, swinstall, swremove and swverify. • autoselect_dependencies=true Causes SD-UX to automatically select requisites when software is being selected.
• autoselect_patches=true Automatically selects the latest patches (based on superseding and ancestor attributes) for a software object that a user selects for a swinstall or swcopy operation. When set to false, the patches corresponding to the selected object are not automatically selected. You can use the patch_filter= option in conjunction with autoselect_patches. Applies to swask, swinstall and swcopy.
Applies only to swverify. • 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.
Applies to swinstall, swcopy, swpackage, swmodify, swconfig, and swremove. 308 • compression_type=gzip Defines the default compression type used by the agent (or set by swpackage) when it compresses files during or after transmission. If uncompress_files is set to false, the compression type is recorded for each file compressed so that the correct uncompression can later be applied during a swinstall, or a swcopy with uncompress_files set to true.
• create_target_acls=true Normally set to true, this default determines whether swpackage creates Access Control Lists (ACLs) in the depot. If you set this option to false as superuser, ACLs for each new product being packaged (and for the depot, if it is new) are not created. When another user invokes swpackage, it always creates ACLs in the distribution depot. This default has no impact on the ACLs that already exist in the depot.
configure scripts. To configure the software later, you must run the swconfig command. — Multiple versions of a product will not be automatically configured if another version is already configured. Use the swconfig command to configure multiple versions separately. — SD-UX ignores this option (treats it as true) when it installs software that causes a system reboot. — Alternate root directories are not configured.
If set to false, space checks are still performed but a warning is issued that the system may not be usable if the disk fills past the minfree threshold. An installation will fail if you run out of disk space. Applies to swcopy, swinstall and swpackage. • enforce_kernbld_failure = true Controls whether or not a failure in either of the kernel build steps (system_prep and mk_kernel) is fatal to the install session.
• fix=false Controls whether or not to run vendor-specific scripts to correct and report problems on installed software. Fix scripts can create missing directories, correct file modifications (mode, owner, group, major, minor), and recreate symbolic links. If false (default), fix scripts are not run. If true, fix scripts are run. Applies to swverify. • follow_symlinks=false Do not follow symbolic links that exist in the packaging source; instead, package them as symlinks. Applies only to swpackage.
This option permits the simultaneous installation and removal of multiple software applications by multiple users or multiple processes, with each application or group of applications using a different IPD. Caution: use a specific installed_software_catalog to manage a specific application. SD-UX does not support multiple descriptions of the same application in multiple IPDs. See also the admin_directory option. Applies to swacl, swask, swconfig, swinstall, swlist, swmodify, swremove, and swverify.
In addition to adding new attributes and objects, layout version 1.0 changes the following preexisting 0.8 objects and attributes: — Replaces the depot media_sequence_number attribute for the media object with a sequence number attribute. — Replaces the vendor definition within products and bundles with a vendor_tag attribute and a corresponding vendor object defined outside the product or bundle. — Pluralizes the corequisite and prerequisite fileset attributes.
— 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.
Table A-2 loglevel and logdetail Combinations (continued) Log Level Log Detail Information Included loglevel=1 logdetail=true Event detail as above plus task progress messages. (Setting loglevel=1 is optional because 1 is the default value.) loglevel=2 logdetail=false Event and file level messages only. (Setting logdetail=false is optional because false is the default value.) loglevel=2 1 logdetail=true All information is logged. 1 This combination duplicates the logfile behavior as HP-UX 10.
This option overrides any other software selections. Selections cannot be ambiguous. Applies only to swinstall. • max_agents=-1 The maximum number of agents that are permitted to run simultaneously. The value of -1 means there is no limit. Applies only to swagentd. • max_targets=25 When set to a positive integer, this option limits the number of concurrent install or copy operations to the number specified.
• 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. • mount_cmd=/sbin/mount Specifies the command called by the agent to mount all file systems. Applies only to swagent.
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. — width specifies the word width in bits (either 32 or 64) of the OS to be installed. — operating_system and width must be separated by a colon (:). Applies only to swinstall. • os_release Specifies fileset selection for an HP-UX update. (This option should always be used with the os_name option.
This option can be is used in conjunction with the autoselect_patches and patch_match_target options to filter the selected patches to meet the criteria specified by software_specification. The default software_specification value is *.*. Note that patch filtering is overridden if you specify software with a command or if you use the \* wildcard to select software. If multiple targets are specified, the first target in the list is used as the basis for patch selections.
to a master depot can change the objects that are visible when you use the create_time_filter option. Applies to swcopy. • preview=false If true, run this command in preview mode only (complete the analysis phase and exit). This option has the same effect as specifying -p on the command line. Applies to swcopy, swinstall, swremove, and swconfig. • reboot_cmd=/sbin/reboot This is the command called by the agent to reboot the system. Applies to swagent.
• reinstall_files=false Controls the overwriting of files, which may enhance performance on slow networks or disks. At the default value of false, SD-UX compares each file in a source fileset to corresponding files on the target system. SD-UX compares the files based on size, timestamp, and (optionally) the checksum. If the files are identical the files on the target system are not overwritten.When set to true, SD-UX does not compare files and overwrites any identical files on the target.
not part of the most recent packaging of the product residing on the source depot or during the current packaging of the product defined in the source PSF. Applies to swcopy and swpackage. • remove_setup_cmd=/usr/lbin/sw/remove_setup Defines the script called by the agent to perform release-specific removal preparation. For an OS update, this script invokes the tlink command when a fileset is removed. Applies only to swagentd.
that are not removed before the ID numbers reach 9,999, SD-UX may have performance delays while it searches for unused job numbers. Setting reuse_short_job_numbers to false causes SD-UX to begin using numbers above 10,000. This avoids possible searching delays and lets the job ID numbers increase to 8 digits (99,999,999) if necessary. (This prevents roll-over from 9999 back to 1, so is usually not desirable.) See also the autoremove_job option. Applies to swconfig, swcopy, swinstall, swremove, and swverify.
• rpc_binding_info_target= Defines the protocol sequences and endpoints used to contact targets. If rpc_binding_info_target is not specified, rpc_binding_info is used. If both are specified, rpc_binding_info_target is used. Applies to swinstall and swcopy. • rpc_timeout=5 Relative length of the communications timeout. This is a value in the range from 0 to 9 and is interpreted by the DCE RPC. Higher values mean longer times; you may need a higher value for a slow or busy network.
Applies to swinstall and swremove. 326 • select_local=true Normally set to true, selects the default depot or installation directory of the local host as the target of the command. Applies to swacl, swconfig, swcopy, swinstall, swlist, swreg, swremove, swverify. • show_superseded_patches=false If false, swlist will not display superseded patches. To see them, you must set this option to true. Even if you explicitly swlist the superseded patch, it will not display unless this option is true.
A user running swinstall or swcopy from a target machine cannot set this option; only the administrator of the source depot machine can set it. When source_depot_audit is set to its default value of true, a swaudit.log file is created on the source depot (for writable directory depots) or in /var/tmp (for tar images, CD-ROMs, or other nonwritable depots).
Applies only to swagent. 328 • targets= There is no supplied default (see also select_local). If there is more than one target, they must be separated by spaces. Targets are usually specified in a target input file, as options on the command line or in the GUI. Applies to all commands. • target_directory See distribution_target_directory. • target_tape See distribution_target_serial. • target_type See media_type.
value at all for the alternate_source, the agent applies the controller-supplied path to its own local host. Applies to swcopy and swinstall. • 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.
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. Table B-1 Chapter Topics Topics: “Error Logging ” (page 331) “Common Problems ” (page 332) B.1 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.
minimum free space for this disk. You should free up at least 2280 Kbyte blocks to avoid installing beyond this threshold of available user disk space. If you are running interactive "swinstall", you must return to the Selection Window and Unmark this target before using "swremove" to free disk space. B.1.2 Warning Messages Warning messages let you know that something unexpected and potentially undesirable occurred. A warning does not prevent the SD session from continuing.
Table B-2 Common Problems (continued) Problem The packager fails Daemon logfile is too long Cannot read a tape depot Installation fails swinstall or swremove fails with a lock error B.2.1 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.
1. On the target system, type: ps -e | grep swagentd 2. If the daemon does not appear to be running, you can start it by typing (as root on the target system): /usr/sbin/swagentd 3. If you attempt to start a daemon when one is already running, you will see a message about the other daemon; this is harmless.
Resolution If you have invoked the GUI on a remote system, you may see the following error messages: Xlib: connection to refused by server Xlib: Client is not authorized to connect to Server Error: Can’t Open display. Check that you have set the $DISPLAY environment variable correctly on the remote system to identify your display. If it is correct, you may have to enable the remote host to make connections to your X server via the xhost(1) command or by modifying your /etc/X*.hosts file.
If any of these access permissions is absent, the whole operation is disallowed, and you must read the error message carefully to understanding the exact cause. To see more about what type of security or access problems exist, see the daemon log file on the target system: /var/adm/sw/swagentd.log B.2.3.1 The Effects of ACL Modifications The default ACLs make it fairly easy to administer ACLs, but do not always give the desired level of access control.
built-in knowledge of the host on which the depot originated. In particular, an ACL default realm will be wrong and local users will be confused with users on the originating host. For example, attempts to add local users to the access list will, in fact, grant access to remote users. There is no way to alter the default realm of an ACL from that set when it is created.
B.2.5 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.
A final WAN-related issue may arise when using the interactive GUI. During the analysis and execution phases of an interactive session, each target agent is periodically polled for up-to-date status information. The polling_interval option can be used to control the number of seconds that elapse between successive status polls of a given target system.
B.2.9 Daemon Logfile Is Too Long If you want to shorten (truncate) the SD-UX daemon logfile because it is getting too long, follow this procedure: Resolution If the daemon is currently running, DO NOT remove its logfile. The running daemon continues to log messages to its logfile even after you’ve removed it, causing any subsequent information to be lost. Also, the disk space used by the logfile will not be freed as long as the daemon is running.
Resolution SD-UX gives you several restart options: • Re-execute the same command from the command line. • Recall the session file swinstall.last that was automatically saved for you. (See “Session Files” (page 51).) • Reset the checkpointing options. By default, SD-UX checkpoints to the fileset level, meaning that the operation will start transferring files with the last fileset to be attempted.
C Replacing or Updating SD-UX This appendix describes how to replace or update SD-UX using the install-sd command. Table C-1 Chapter Topics Topics: “Re-installing SD-UX ” (page 343) “Replacing an Unusable Version of SD-UX” (page 344) “Installing a Newer Version of SD-UX” (page 345) C.1 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.
C.1.2 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.
3. Make install-sd executable: # chmod +x /var/tmp/install-sd 4. Execute install-sd: # /var/tmp/install-sd -s /SD_CDROM The SW-DIST product then installs itself onto your system from the CD-ROM. C.3 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.) 1.
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: 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.
Table D-2 Agent Component (continued) /var/adm/sw/host_object List of depots registered at the local host /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.
Table D-3 Controller File System Structure (continued) /usr/lib/X11/app-defaults X11 resource definitions for the GUIs /usr/lib/nls/msg/$LANG/sw*.cat Message catalogs for the daemon, agent, and shared messages /usr/newconfig/var/adm/sw Data files that are conditionally copied into /var/adm/sw. /var/adm/sw/queue Directory that contains all the data for jobs /var/adm/sw/sw.log Controller logfile /var/adm/sw/defaults.hosts System-level defaults.hosts file for the GUIs /var/adm/sw/.
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.
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. By specifying a bundle, all products or filesets under that bundle are automatically included in the operation. C Cache File A file that contains the name and attributes of targets selected by swinstall or swcopy.
Compatibility Filtering The ability of swinstall to filter the software available from a source according to the host’s uname attributes. Software products are created to run on specific computer hardware and operating systems. Many versions of the same products may exist, each of which runs on a different combination of computer hardware and operating system. By default, swinstall does not allow selection and installation of incompatible software.
Defaults File The file (either /var/adm/sw/defaults for system-wide defaults or $HOME/.sw/defaults for user- level defaults), which contains the default options and operands for each SD-UX command. Delegation SD-UX provides a controlled access to depot-resident products: both the host where the agent is running and the user initiating the call (delegation) must have read access. Dependency A relationship between fileset in which one requires another in a specific manner.
G Graphical User Interface (GUI) An OSF/Motif ™ user interface, with windows and pull-down menus, provided with the sd, swinstall, swcopy, swlist, and swremove commands. See also the Command Line User Interface (CLUI) and Terminal User Interface (TUI). Group In SD-UX security, a set of users. Group Name In SD-UX security, the user’s primary group. GUI See Graphical User Interface. H HOME A variable that contains the path of the current user’s local log-in directory.
IUI Interactive User Interface, a generic term that can mean either the Graphical User Interface (GUI) or the Terminal User Interface (TUI). J Job A SD-UX task created by the swinstall, swcopy, swremove, swverify, or swconfig commands. You create, monitor, schedule, and delete jobs using the Job Browser. You can also monitor jobs using the swjob command. Job Browser A GUI program that lets you create, monitor, schedule, and delete jobs. The GUI is activated by the sd command.
N Network Source There can be multiple network sources from a single host, each one a different depot served by that host’s single swagentd daemon. A network source is identified by the host name and depot directory. Nodes Another name for client host. See Client. 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.
installed before fileset A can be installed. Therefore, fileset B is a prerequisite for fileset A. See dependency, corequisite, and exrequisite. 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.
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. The revision information (release number, version) for the product. Root The root directory of a system (/). See Root Directory. Root Directory The directory on a target host in which all the files of the selected products will be installed.
Software selection A group of software objects you have selected for an operation. You can save these software selections for later reuse. See software group. Software Selection Window A GUI window that lets you select the software files you want to install, copy, or remove. Software source A depot used as the source of a swinstall or swcopy operation. Source See software source. SPA See Single Point Administration. Staged installation See staging.
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. swmodify A SD-UX command that lets you change information in the installed products database or depot catalog files. swpackage A SD-UX command that uses a product specification file (PSF) to organize software products and package them into a depot.
U UDP/IP User Datagram Protocol. Comparable with TCP/IP, but runs connections less and is intended to be used in more reliable network environments (LAN). Uname Attribute When a target is contacted for a software management operation, the system’s four uname attributes (operating system name, release, version and hardware machine type) are obtained. Used to determine software compatibility with the proposed host.
Index Symbols $HOME/.
ask option, 303 ask=, 303 assigning management responsibility, 211 attributes definition, 81 listing, 318 sample, 94 audience for this guide, 19 authorization, depot, 124 authorization, RPC, 208 auto_kernel_build, 303 automatic recovery, 304 automatic scrolling, 57, 105, 117 autoreboot, 304 autorecover, 65, 304 autorecover_product, 304 autorecover_product= default, 65 autoremove_job, 149, 304 autoselect_dependencies, 305 autoselect_dependencies=true option, 30 autoselect_dependents, 305 autoselect_minimum_d
writing, 265 control_files, 308 controller, 151 controller log file, 316 controller privileges, 207 controller_source, 308 controlling access, 204 copy dialog, 119 copying software depots, 113 icon in Job Browser, 137 Job Browser, 144 corequisite, 30, 241 definition, 31 CORRUPT state, 70 cpio tape format, 253 create_target_acls, 257, 309, 337 create_target_path, 309 create_time_filter option, 309 creating a job, 142 creating jobs, 144 creation time, 320 credentials, 206 crwit, 197 custom lists, 89 customer
registration, 123 removing software from, 102, 131 secure registration, 210 swreg command, 124, 126 tape, 112 unregistered, 124, 210 unregistering, 123 description file, 56, 103, 116 developers, security for, 212 development depots for testing purposes, 212 direct access to Support Plus, 124, 126 directory /var/tmp, 343 directory depot, 112 directory mapping, 244 directory structures, 218 disk space analysis, 339 analysis by swpackage, 251 analysis dialog, 58 button, 57, 59, 117, 118 failure, 59, 118 space
fileset, 27 level, specifying (swlist), 92 product structure, 218 specification, 237 filesystem structure SD-UX agent, 347 SD-UX controller, 348 filter, 38 fix, 312 fix script, 266 flag "yes", 33 Marked?, 56, 103, 116 follow_symlinks, 312 fonts fixed width, 46 variable width, 46 G global_product_template, 187, 192, 202 global_soc_template, 187, 202 glossary, 351 go up, 41 Graphical User Interface (GUI), 25, 31, 54, 102, 113 swlist, 82, 167 group access, 206 ACL, 196 GUI will not start, 334 GUI and TUI swli
jobs monitoring from command line, 145 options, 148 re-using job information, 144 removing with swjob, 146 K kernel rebuilding, 53 rebuilding for swcopy, 113 kernel build, 311 kernel fileset, 300 kernel_build_cmd, 313 kernel_path, 313 keyword syntax, PSF, 223 keywords checkinstall script, details, 278 checkremove script, details, 282 configure script, details, 280 postinstall script, details, 280 postremove script, details, 283 preinstall script, details, 279 preremove script, details, 282 unconfigure scri
network requirements, 23 network servers, 112 network source, 112 networking requirements, 23 nodes, definition, 26 nonprivileged SD, 295 limitations, 296 overview, 295 packaging requirements, 296 set up, 296 num_entries value, 336 O object list, 33 object permissions, 198 objects, software, 27 objects_to_register, 318 on-line Help, 44 one_liner, 318 one_liner= default, 88, 90 open item, 41 option menu, 141 options alphabetic list of, 300 and defaults, swconfig, 100 and defaults, swremove, 107 changing, 50
comment lines, 223 creating, 220 defining default, 327 dependency class, 241 depot class, 230 directory mapping, 244 example, 221 example file specifications, 246 example permission specifications, 243 exclude files, 248 explicit file specification, 244 extensions, 248 file class, 242 fileset class, 237 include files, 248 keyword value, 223 keywords, 223 product class, 233 quotes, 223 recursive file specification, 247 subproduct class, 236 syntax, 223 vendor class, 231 pull distribution, security in, 211 pu
S samples copying, 122 installation, 64 save session file option, -C, 61, 72, 77, 83, 97, 106, 120, 124, 146, 253, 291 save software group, 103 saving view information, 40 Scalability, 173 scheduling icon in Job Browser, 137 script fix, 266 interpreter, 269 other, 266 request, 266, 271, 283 sd invoking, 135 security checks, 213 SD internal authentication, 206 SD-UX commands, 25 manpages, 25 SD-UX controller, 151 secrets default, 208 inter-host, 336 matching, 336 security, 207 security default, 183 denied ac
software product, 27 stty, using to determine character mapping, 49, 168 subproduct, 27, 218 level, specifying (swlist), 91 specification, 236 superuser ACL access, 195 authorization, 210 privileges, 205 swpackage, 258 supporting files install-sd, 343 SW-DIST loading new version, 343 reloading if corrupt, 343 SW_CONTROL_DIRECTORY, 274 SW_DEFERRED_KERNBLD, 276 SW_INITIAL_INSTALL, 277 SW_KERNEL_PATH, 277 SW_LOCATION, 275 SW_PATH, 275 SW_ROOT_DIRECTORY, 275 SW_SYSTEM_FILE_PATH, 277 swacl, 214 -D option, 193 -F
swask, 291 swcopy, 120 swinstall, 60 swjob, 146 swlist, 83 swmodify, 97 swremove, 106 system definition, 26 system_file_path, 327 system_prep_cmd, 327 T table of contents, 81 tag attribute, always listed, 89 tags, 96 tape changing, 60 depot, 112 device, 310 partitioning filesets on multiple, 263 tape formats cpio, 253 tar, 253 tape is ready response, 263 tar archive, 112 tar tape format, 253 target changing, 103 definition, 26 definition for remote operations, 151 directory, 309 files, 49 groups, 156, 157,
script, details, 281, 282 scripts, executing, 75 versions, 179 view menu, 140 view preferences, changing, 36 volatile, 307 W WAN, 173, 176 WAN connection timeouts, 338 wide area network, 176 wildcard, 263 wildcarding, partial, 247 window GUI components, 33 Software Selection, 55, 116 swremove, 105 writable depot, 112 write permission, 124 write-to-tape, terminate, 263 write_remote_files, 262, 329 X XToolkit -fn option, 46 -font option, 46 374 Index
