Software Distributor Administration Guide HP-UX 11i v1, 11i v2, and 11i v3 HP Part Number: 5900-0856 Published: September 2010
© Copyright 1997, 2000-2003, 2006, 2007, 2008, 2009, 2010 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.2.3 Using swconfig......................................................................................................74 2.2.4 Configuration Tasks and Examples......................................................................76 2.3 Verifying Your Installation (swverify)..........................................................................77 2.3.1 Features and Limitations.......................................................................................77 2.3.2 The Verification Process.......
3.3.4.3 Removing Multiple Versions ......................................................................111 3.3.4.4 Removing Software from an Alternate Root ..............................................111 4 Managing Software Depots.....................................................................................................113 4.1 Depot Management Commands and Concepts..........................................................113 4.1.1 Depot Concepts................................................
6.2 Using the Job Browser ................................................................................................138 6.2.1 Job Browser Icons................................................................................................138 6.2.2 The File Menu .....................................................................................................141 6.2.2.1 Printing the Jobs List...................................................................................141 6.2.3 The View Menu .
7.2.4 Selecting Individual Targets................................................................................158 7.2.5 Saving a Target Group.........................................................................................158 7.2.6 Adding a Target Group.......................................................................................159 7.3 Setting Up Remote Operations....................................................................................159 7.4 Remote Operations Tutorial......
.1.3 Modifying Target Systems...................................................................................188 9.2 The swacl Command ..................................................................................................188 9.2.1 swacl Output.......................................................................................................190 9.3 Basic Security Tasks ....................................................................................................191 9.3.
9.10.3 Job Browsing (sd, swjob) ..................................................................................217 9.10.4 Copying (swcopy) ............................................................................................217 9.10.5 Installing (swinstall) .........................................................................................218 9.10.6 Removal (swremove) ........................................................................................218 9.10.7 Configuration (swconfig) .
10.6 Packaging Tasks and Examples.................................................................................260 10.6.1 Registering Depots Created by swpackage ......................................................260 10.6.2 Creating and Mastering a CD-ROM Depot.......................................................261 10.6.3 Compressing Files to Increase Performance .....................................................261 10.6.4 Packaging Security ......................................................
11.4.3.1 SW_DEFERRED_KERNBLD ....................................................................280 11.4.3.2 SW_INITIAL_INSTALL ...........................................................................281 11.4.3.3 SW_KERNEL_PATH ................................................................................281 11.4.3.4 SW_SESSION_IS_KERNEL.......................................................................281 11.4.3.5 SW_SESSION_IS_REBOOT...............................................................
12.2.3 How Nonprivileged Mode Changes SD-UX Behavior.....................................301 12.3 Default Configuration...............................................................................................301 12.4 Alternative Configuration.........................................................................................302 12.4.1 Setting the Admin Directory Option.................................................................302 A Command Options............................................
D.2 Software Distributor Controller File System Structure .............................................352 D.3 Installed Products Database ......................................................................................353 Glossary...................................................................................................................................355 Index.......................................................................................................................................
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 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 16 Job Results Dialog .....................................................................................................145 Show Job Description ...............................................................................................146 Remove a Job dialog..................................................................................................147 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 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 18 Product Principals.....................................................................................................205 Product Permissions..................................................................................................205 Chapter Topics...........................................................................................................221 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.
Related Documents The most current edition of following documents, which are found at the HP Technical Documentation Web site at http://docs.hp.
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 55) swlist(1M) • Lists installed software or software • “Listing Your Software (swlist)” in depots or on media (page 83) • Optional GUI • “Listing Registered Depots” (page 131) swcopy(1M) • Copies software from one depot to another • Optional GUI • “Copying Software Depots” (page 115) 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 98) files that contain information about the software on the system swreg(1M) • Registers newly created depots to • “Registering and Unregistering Depots (swreg) ” (page 125) make them visible to other systems 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. However, corequisites modify the load order in some cases. For more information on options, see “Using Command Options” (page 50).
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 52).) 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.
• • • when no host is specified, the relative_path must start with ./ or ../; otherwise, the specified name is considered as a host. The internet address can be in IPv4 format with dot notation or in IPv6 format. When IPv6 internet address is specified, it can be optionally enclosed within square brackets [ and ]. The : (colon) is required if you specify both a host and directory. On some systems, the @ character is used as the kill function.
For system-wide policy setting, use the /var/adm/sw/defaults files. Keep in mind, however, that users may override these options with their own $HOME/.swdefaults file, session files, or command line changes. The template file /usr/lib/sw/sys.defaults provides an easy way to change system-wide or personal option files. The template file lists (as comments): • • • • All command options The commands to which each option applies Possible values for each option The resulting system behavior for each value.
To start an interactive install session and reset the use_alternate_source default for this session only: swinstall -i -x use_alternate_source See Appendix A (page 303) for a complete listing of defaults and their values and descriptions. CAUTION: Changing the default values for command options can cause harmful results if you specify inappropriate values. 1.4.
swinstall.compress_files = false swinstall.create_target_path = true ... (A typical swinstall session file has approximately 70 lines.) 1.
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 269)) • 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 67) 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 56). -p Preview the install task (perform analysis only). -r Operate on an alternate root directories. See “Installing to an Alternate Root ” (page 69). -v Turn on verbose output to stdout and display all activity to the screen.
-t target_file Read target selections from a target_file instead of (or in addition to) targets you specify on the command line. See “Target Files” (page 50). -x command_option=value Sets command_option to value, overriding default values or values in options files. See “Changing Command Options ” (page 64). -X option_file Read session options and behaviors from option_file. See “Changing Command Options ” (page 64). software_selections One or more software objects to be installed.
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 code
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 135) 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.
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. This lets you: • • • Execute scripts to address problems if a configuration fails, is deferred, or must be changed. Explicitly configure, unconfigure or reconfigure any installed software that has associated configuration scripts.
• • 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.
NOTE: Products are ordered by prerequisite dependencies, if any. Fileset operations are also ordered by any prerequisites or corequisites. The loadorder_use_coreqs option can modify load order of the filesets. For more information on loadorder_use_coreqs, see “Options Listed Alphabetically” (page 304). 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.
Command Line” (page 150) and Chapter 7: “Remote Operations Overview” (page 153) -S session_file Run the command based on values saved from a previous installation session, as defined in session_file. See “Session Files” (page 52). -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 50). -x option=value Sets a command option to value and overrides default values or a values in options files.
Table 2-5 swconfig Command Options and Default Values • • • • • • • • • • • • • • • • • • • admin_directory=/var/adm/sw agent_auto_exit=true agent_timeout_minutes=10000 allow_incompatible=false allow_multiple_versions=false ask=false autoremove_job=false autoselect_dependencies=true autoselect_dependents=true autoselect_minimum_dependencies=false compress_index=false controller_source= enforce_dependencies=true enforce_scripts=true enforce_selections=false installed_software_catalog=products job_title= loa
To reconfigure the HP Omniback product: swconfig -x reconfigure=true Omniback To configure the version of HP Omniback that was installed at /opt/Omniback_v2.0: swconfig Omniback,l=/opt/Omniback_v2.0 To unconfigure the software_selections listed in the file /tmp/install.products on the hosts listed in the file /tmp/install.hosts: # swconfig -u -f /tmp/install.products \ -t /tmp/install.hosts 2.
The swverify behavior can be controlled by the enforce_selections option. If set to false (default), swverify proceeds even when only one software selection is available in the source. If set to true, swverify proceeds only if all of the software selections are available. Phase II: Analysis The analysis phase for swverify takes place on the host. The host’s environment is not modified. The sequential analysis tasks on each host are: 1. 2. Initiate analysis Process software selections.
• • • • Determine active or inactive state of the product. Check for corruption of product configuration files. Check for (in)correct configuration of the product into the OS platform, services or configuration files. Check licensing factors. Vendor-supplied scripts are executed and the return values generate an ERROR (1) or a WARNING (2). Scripts are executed in prerequisite order. 6.
Command Line” (page 150) and Chapter 7: “Remote Operations Overview” (page 153) -S session_file Run the command based on values saved from a previous verify session, as defined in session_file. See “Session Files” (page 52). -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 50). -x option=value Sets a command option to value and overrides default values or a values in options files.
Table 2-6 swverify Command Options and Default Values • • • • • • • • • • • • • • • • • • admin_directory=/var/spool/sw agent_auto_exit=true agent_timeout_minutes=10000 allow_incompatible=false allow_multiple_versions=false autoremove_job=false autoselect_dependencies=true autoselect_minimum_dependencies=false check_contents=true check_contents_uncompressed=false check_contents_use_cksum=true check_permissions=true check_requisites=true check_scripts=true check_volatile=false controller_source= distributio
swverify Omniback,1=/opt/Omniback_v2.
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 83) “Modifying the IPD (swmodify)” (page 98) “Removing Installed Software (swremove)” (page 103) 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).
software_selections The software objects to be listed. See “Software Selections” (page 47). target_selections The target of the command. (For swlist, target_selections are just another way to list software selections. 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.
# Bundle(s): B3782CA B.11.00 HP-UX Media Kit (Reference Only. See Descr.) B3898AA B.11.00 HP C/ANSI C Developer’s Bundle for HP-UX 11.00 HPUXEngRT B.11.00 English HP-UX Run-time Environment # 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.
* Introduction * **************** The Release Notes for HP-UX Release X.0 contain an overview of the new/changed product features that are included in the release. For detailed 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.
subproducts and filesets, but the attribute architecture is only available for products. In the absence of the -v or -a option in your command, swlist displays the information as described in the one_liner default for each software object level (bundle, products, subproducts and filesets), not for files. 3.1.4.2 Listing Attributes You may specify only one attribute per -a option.
swlist C-LANG @ host2 C-LANG.C-COMPILE 8.0 C-LANG.C-LIBS 8.0 C-LANG.C-MAN 8.0 1346 2356 1976 C Compiler Components Runtime Libraries Programming Reference 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.
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.
3.2.3.2 Changing Existing IPD Information To create some new bundle definitions for products in an existing depot: # swmodify -d -s new_bundle_definitions \ \* @ /mfg/master_depot If a product provides a more complex configuration process, a script 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.
Postremove Performs additional remove operations (such as restoring "rollback" files) immediately after a fileset or product has been removed. For more information, see Chapter 11: “Using Control Scripts ” (page 269). • 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.
Step II: Selecting Software In this step, you use the Software Selection window to select the software you want to remove. 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 108 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 150) and Chapter 7: “Remote Operations Overview” (page 153) -S session_file Run the command based on values saved from a previous removal session, as defined in session_file. See “Session Files” (page 52). -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 50).
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 enforce_selections=false force_single_target=false installed_software_catalog=prod
fileset Debugger.Run and you try to remove FORTRAN, the fileset Debugger.Run 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.
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 113) “Copying Software Depots” (page 115) “Registering and Unregistering Depots (swreg) ” (page 125) “Additional Depot Management Tasks and Examples” (page 128) 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 125) 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 116)). 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.
host is specified, the relative_path must start with ./ or ../; otherwise, the specified name is considered as a host. -S session_file Run the command based on values saved from a previous session, as defined in session_file. See “Session Files” (page 52). -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 50).
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/sp
swcopy -s /dev/rmt/0m \* 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 52). -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 52).
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 221) 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 153). Table 6-1 Chapter Topics Topics: “Introduction ” (page 137) “Using the Job Browser ” (page 138) “Monitoring Jobs from the Command Line” (page 147) “Managing and Tuning Jobs with Command Options” (page 150) 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 148 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 138). -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 155).) 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 160)). 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 167)). 3. 4.
preview job progress from the Job Browser. See “Step VII: Monitor Results ” (page 168) 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.
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] NOTE: The host can be an internet address either in IPv4 format with dot notation or in IPv6 format. When IPv6 internet address is specified, it can be optionally enclosed within square brackets [ and ]. 7.6.2 Examples 7.6.2.
To copy C and Pascal products from a remote depot to a local depot with the IPv6 address 2620:0:a07:e020:21a:4bff:fef3:90e8: # swcopy -s [2620:0:a07:e020:21a:4bff:fef3:90e8]:/mydepot cc pascal @ /var/spool/sw 7.6.2.
To remove the C and Pascal products from the remote hosts with the IPv6 address ffe:ffff:101::230:6eff:fe04:d9ff: # swremove cc pascal @ ffe:ffff:101::230:6eff:fe04:d9ff 7.6.2.10 swverify To verify the C and Pascal products on three remote hosts: # swverify cc pascal @ hostA hostB hostC To verify the C and Pascal products on the remote hosts with the IPv6 address 2ffe:ffff:101::230:6eff:fe04:d9ff: # swverify cc pascal @ 2ffe:ffff:101::230:6eff:fe04:d9ff: 7.
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 159)), 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 206) 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 303) 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.
object_group entry type in an ACL causes the SD-UX ACL manager to look up the owner and group information on the object; and if a match to the requester is found, grant permissions as specified. 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.
In the ACL entry, these permissions are abbreviated c, t, i, w, and r. To grant all permissions, you may use the shorthand letter a instead of the crwit to denote all permissions. The meaning of permissions is different for different types of objects, and the permissions do not have to appear in any specific order. Roots do not provide product level protection, so all permissions on products installed on roots are controlled by the ACL protecting the root itself.
This is useful for product control, because it lets you assign management control for a specific product to a delegated administrator. Also, when a product is created on a depot, the user and group identity of the creator is recorded in the product information. If the product ACL contains an object_owner entry granting write permissions to the owner, then the product creator will automatically have rights to change or delete the product.
9.5.3.1 Host System ACLs The host system is the highest level of protected object in SD-UX. A host ACL protects each host system, controlling permission to create depots and roots. The host ACL may grant the following permissions: Table 9-7 Host ACL Permissions r (read) Permission to obtain host attributes, including a list of depots and roots on the host. w (write) Permission to change the host object. i (insert) Permission to create and register a new depot or root on the host.
9.5.3.3 Depot ACLs Principals identified in ACLs that are protecting depots are users who have been granted permission to manage the depot and to create new products. The permissions associated with a depot are: Table 9-9 Depot Permissions i(insert) Permission to copy a new product into the depot. r (read) Permission to list the contents (products) of the depot source. w (write) Permission to delete the depot (if it is empty), and unregister itself (not the products in the depot).
Table 9-11 Product Permissions (continued) c (control) Permission to edit or change the ACL. t (test) Permission to test access to an object.
SD-UX uses the product ACL template of the host system (global_product_template) to initialize the product ACL template of the new depot and uses the container ACL template of the host system (global_soc_template) to initialize depot and root ACLs. Thus, there are three ACLs on the host: • Host ACL Attached to and controlling access to the host object itself. • Container ACL Template (global_soc_template) Used to initialize the ACL protecting new depots and roots created on the host.
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 221) “Identifying the Products to Package ” (page 222) “Adding Control Scripts” (page 223) “Creating a Product Specification File (PSF) ” (page 224) “Packaging the Software (swpackage) ” (page 253) “Packaging Tasks and Examples” (page 260) 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 234)), 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 230) 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 234) 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.
corequisite P.F prerequisite ProdA | ProdB | ProdC.F | ProdC.FS corequisite ProdX | ProdY | ProdZ | ProdW.FS 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.
These mechanisms can all be used in combination with the others. 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.
• Set the same mode defaults, plus a uid and gid: file_permissions • -o 2 -g 2 Set the owner write permission in addition to the above: file_permissions • -u 222 -u 022 -o 2 -g 2 If you do not define file_permissions, swpackage uses the default value file_permissions -u 000 for destination file objects based on existing source files. (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.
file This keyword specifies an existing file (usually within the currently active source directory) to include in the fileset. 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.
-g [group[,]][gid] This option defines the file’s group name and/or gid at its destination. If only the group is specified, then the group 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.
• 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 52). -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 125). 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 303) 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 77) 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 270) “Using Environment Variables ” (page 277) “Execution of Control Scripts ” (page 281) “Execution of Other Commands by Control Scripts ” (page 288) “Control Script Input and Output” (page 289) “File Management by Control Scripts ” (page 291) “Testing Control Scripts ” (page 291) “Requesting User Responses (swask)” (page 295) 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.
11.5.2 Checkinstall Scripts • Checkinstall scripts are executed during the Analysis phase of a swinstall session. The pathname of the script being executed is: $ {SW_CONTROL_DIRECTORY}checkinstall • • • • • A checkinstall script must not modify the system. A checkinstall script determines whether the product/fileset can be installed by performing checks beyond those performed by swinstall.
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 52). -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 303) 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 299) “Setting Up Nonprivileged Mode” (page 300) “Default Configuration” (page 301) “Alternative Configuration” (page 302) 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 303) “Options Listed Alphabetically” (page 304) 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. 308 • 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. 312 • 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.
If there is more than one path name, they must be separated by white space and surrounded by double-quotes. Applies only to swmodify. 316 • 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.
option to determine the path to the IPD. For alternate roots, this path is resolved relative to the location of the alternate root. (This option does not affect where software is installed, only the IPD location.) 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.
Layout version 1.0 adds significant functionality not recognized by systems supporting only version 0.8, including: — Category class objects (formerly the category and category_title attributes within the bundle or product class). — Patch-handling attributes, including applied_patches, is_patch, and patch_state. — The fileset architecture attribute at the fileset level, which permits you to specify the architecture of the target system on which the software will run.
For swacl, this option specifies the level of ACLs to view or modify: — host -- view or modify the ACL protecting the host systems identified by the target_selections. — depot -- view or modify the ACL protecting the software depots identified by the target_selections. — root -- view or modify the ACL protecting the root file systems identified by the target_selections. — product -- view or modify the ACL protecting the software product identified by the software_selection.
• logdetail=false Controls the amount of detail written to the log file. When set to true, this option adds detailed task information, such as options specified, progress statements, and additional summary information, to the log file. Table A-2 shows the possible combinations of loglevel and logdetail options.
re-use lookup results. The maximum value allowed is 10080 minutes, which is one week. Applies to swacl, swagentd, swask, swconfig, swcopy, swinstall, swjob, swlist, swmodify, swpackage, swreg, swremove, and swverify. • match_target=false If set to true, forces selection of filesets from the source that match filesets already installed on the target system. Filesets on the source which specify an installed fileset as an “ancestor” will be selected. This option overrides any other software selections.
• minimum_job_polling_interval=1 Defines how often, in minutes, the daemon will “wake up” and scan the job queue to determine if any scheduled jobs need to be initiated or if any active jobs need their remote target status cached locally. If set to 0, no scheduled jobs will be initiated, and no caching of active jobs will occur. Applies only to swagentd.
• os_name Specifies fileset selection for an HP-UX update. (This option should always be used with the os_release option.) You must specify this option from the command line or when invoking the swinstall GUI. This options has the following syntax: os_name=operating_system:width — operating_system specifies the name of the operating system, such as HP-UX. See the uname(1) manual page for complete information. — width specifies the word width in bits (either 32 or 64) of the OS to be installed.
patch, you cannot remove the patch unless you remove the associated base software that the patch modified. Applies only to swmodify. 324 • patch_filter=*.* Specifies a software_specification for a patch filter. 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 *.*.
• preserve_create_time=false Preserves the original create time when you copy depots, which produces consistent results when you use the copies. The default of false sets the create_time of software bundles, products, and filesets equal to the time swcopy created the new depot. When set to true, the create_time is set to that specified in the source depot from which the current selections were copied.
• reinstall=false Prevents SD from reinstalling (overwriting) an existing revision of a fileset. If set to true, the fileset is reinstalled. The reinstall and recopy options are synonymous. Applies to swcopy and swinstall. • 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.
• remove_obsolete_filesets=false This command controls whether swcopy and swpackage automatically remove obsolete filesets from target products in the target depot. If set to true, swcopy and swpackage remove obsolete filesets from the target products that were written during the copy or package process. Removal occurs after the copy or package is complete.
Applies to swcopy and swinstall. • reuse_short_job_numbers=true When assigning job ID numbers, SD-UX uses numbers less than 10,000. Typically, old jobs are removed long before job number 9,999 is reached, so the job number quickly rolls over from 9999 back to 1. When you execute a large numbers of jobs that are not removed before the ID numbers reach 9,999, SD-UX may have performance delays while it searches for unused job numbers.
• rpc_binding_info_source= Defines the protocol sequences and endpoints used to contact a source depot. If rpc_binding_info_source is not specified, rpc_binding_info is used. If both are specified, rpc_binding_info_source is used. Applies to swinstall and swcopy. • 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.
• run_scripts=true Controls whether or not control scripts (such as preinstall, preremove, postremove, configure, etc.) are run during an install or remove session. Control scripts are an important part of software packages, and setting this to false might keep software from being installed correctly. Control scripts also provide important cleanup when software is removed. Setting this to false during swremove might result in some manual cleanup being required. Applies to swinstall and swremove.
[host][:][path] Applies only to swinstall. • source_depot_audit=true If both source and target machine are updated to SD-UX revision B.11.00 or later, the system administrator at the source depot machine can set this option to track which user pulls which software from a depot on the source machine and when the software is pulled. 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.
• system_file_path=/stand/system The path to the kernel’s template file. The path is passed to the system_prep_command via the SW_SYSTEM_FILE_PATH environment variable. Applies only to swagent. • system_prep_cmd=/usr/lbin/sysadm/system_prep The kernel build preparation script called by the agent. This script must do any necessary preparation so that control scripts can correctly configure the kernel that is about to be built. Applies only to swagent.
• use_alternate_source=false At the default value of false, swinstall or swcopy begins an analysis or task with a request that includes information describing the source binding and depot path for the local host to use as the software source. If true, the local host uses its own configured value. On the local host, the agent’s configured value for alternate_source is specified in host:/path format.
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 335) “Common Problems ” (page 336) 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 Use of square brackets ([ and ]) around IPv6 address causes an 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 52).) • 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 347) “Replacing an Unusable Version of SD-UX” (page 348) “Installing a Newer Version of SD-UX” (page 349) 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: For most current information on Software Distributor files sd(5) 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.
Is_Locatable In packaging, a keyword that defines whether a product can be installed to an alternate product directory or not. If specified, the attribute is set to a value of true. If not specified, the attribute is assigned a value of false. 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.
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, 307 ask=, 307 assigning management responsibility, 215 attributes definition, 83 listing, 322 sample, 96 audience for this guide, 19 authorization, depot, 126 authorization, RPC, 212 auto_kernel_build, 307 automatic recovery, 308 automatic scrolling, 59, 107, 119 autoreboot, 308 autorecover, 67, 308 autorecover_product, 308 autorecover_product= default, 67 autoremove_job, 151, 308 autoselect_dependencies, 309 autoselect_dependencies=true option, 30 autoselect_dependents, 309 autoselect_minimum_d
writing, 269 control_files, 312 controller, 153 controller log file, 320 controller privileges, 211 controller_source, 312 controlling access, 208 copy dialog, 121 copying software depots, 115 icon in Job Browser, 139 Job Browser, 146 corequisite, 30, 245 definition, 31 CORRUPT state, 72 cpio tape format, 257 create_target_acls, 261, 313, 341 create_target_path, 313 create_time_filter option, 313 creating a job, 144 creating jobs, 146 creation time, 325 credentials, 210 crwit, 201 custom lists, 91 customer
registration, 125 removing software from, 104, 133 secure registration, 214 swreg command, 126, 128 tape, 114 unregistered, 126, 214 unregistering, 125 description file, 58, 105, 118 developers, security for, 216 development depots for testing purposes, 216 direct access to Support Plus, 126, 128 directory /var/tmp, 347 directory depot, 114 directory mapping, 248 directory structures, 222 disk space analysis, 343 analysis by swpackage, 255 analysis dialog, 60 button, 59, 61, 119, 120 failure, 61, 120 space
files option, 315 fileset, 27 level, specifying (swlist), 94 product structure, 222 specification, 241 filesystem structure SD-UX agent, 351 SD-UX controller, 352 filter, 38 fix, 316 fix script, 270 flag "yes", 33 Marked?, 58, 105, 118 follow_symlinks, 316 fonts fixed width, 46 variable width, 46 G global_product_template, 191, 196, 206 global_soc_template, 191, 206 glossary, 355 go up, 41 Graphical User Interface (GUI), 25, 31, 56, 104, 115 swlist, 84, 169 group access, 210 ACL, 200 GUI will not start, 33
job_title, 150, 317 jobs monitoring from command line, 147 options, 150 re-using job information, 146 removing with swjob, 148 K kernel rebuilding, 55 rebuilding for swcopy, 115 kernel build, 315 kernel fileset, 304 kernel_build_cmd, 317 kernel_path, 317 keyword syntax, PSF, 227 keywords checkinstall script, details, 283 checkremove script, details, 286 configure script, details, 284 postinstall script, details, 284 postremove script, details, 287 preinstall script, details, 283 preremove script, details,
protocols, 342 network depot, creating, 129 network requirements, 23 network servers, 114 network source, 114 networking requirements, 23 nodes, definition, 26 nonprivileged SD, 299 limitations, 300 overview, 299 packaging requirements, 300 set up, 300 num_entries value, 340 O object list, 33 object permissions, 202 objects, software, 27 objects_to_register, 322 on-line Help, 44 one_liner, 322 one_liner= default, 90, 92 open item, 41 option menu, 143 options alphabetic list of, 304 and defaults, swconfig,
PSF and swmodify, 99 comment lines, 227 creating, 224 defining default, 331 dependency class, 245 depot class, 234 directory mapping, 248 example, 225 example file specifications, 250 example permission specifications, 247 exclude files, 252 explicit file specification, 248 extensions, 252 file class, 246 fileset class, 241 include files, 252 keyword value, 227 keywords, 227 product class, 237 quotes, 227 recursive file specification, 251 subproduct class, 240 syntax, 227 vendor class, 235 pull distribution
S samples copying, 124 installation, 66 save session file option, -C, 63, 74, 79, 85, 99, 108, 122, 126, 148, 257, 295 save software group, 105 saving view information, 40 Scalability, 177 scheduling icon in Job Browser, 139 script fix, 270 interpreter, 273 other, 270 request, 270, 275, 287 sd invoking, 137 security checks, 217 SD internal authentication, 210 SD-UX commands, 25 manpages, 25 SD-UX controller, 153 secrets default, 212 inter-host, 340 matching, 340 security, 211 security default, 187 denied ac
software product, 27 stty, using to determine character mapping, 49, 170 subproduct, 27, 222 level, specifying (swlist), 93 specification, 240 superuser ACL access, 199 authorization, 214 privileges, 209 swpackage, 262 supporting files install-sd, 347 SW-DIST loading new version, 347 reloading if corrupt, 347 SW_CONTROL_DIRECTORY, 278 SW_DEFERRED_KERNBLD, 280 SW_INITIAL_INSTALL, 281 SW_KERNEL_PATH, 281 SW_LOCATION, 279 SW_PATH, 279 SW_ROOT_DIRECTORY, 279 SW_SYSTEM_FILE_PATH, 281 swacl, 218 -D option, 197 -F
swask, 295 swcopy, 122 swinstall, 62 swjob, 148 swlist, 85 swmodify, 99 swremove, 108 system definition, 26 system_file_path, 332 system_prep_cmd, 332 T table of contents, 83 tag attribute, always listed, 91 tags, 98 tape changing, 62 depot, 114 device, 314 partitioning filesets on multiple, 267 tape formats cpio, 257 tar, 257 tape is ready response, 267 tar archive, 114 tar tape format, 257 target changing, 105 definition, 26 definition for remote operations, 153 directory, 313 files, 50 groups, 158, 159,
script, details, 285, 286 scripts, executing, 78 versions, 183 view menu, 142 view preferences, changing, 36 volatile, 311 W WAN, 177, 180 WAN connection timeouts, 342 wide area network, 180 wildcard, 267 wildcarding, partial, 251 window GUI components, 33 Software Selection, 57, 118 swremove, 107 writable depot, 114 write permission, 126 write-to-tape, terminate, 267 write_remote_files, 266, 333 X XToolkit -fn option, 46 -font option, 46 378 Index
*5900-0856* Printed in the US
