Software Distributor Administration Guide HP-UX 11i v1, 11i v2, and 11i v3 HP Part Number: 5900-2561 Published: February 2013
© Copyright 1997, 2000-2003, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 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.
Contents About This Document ..................................................................................13 Intended Audience..................................................................................................................13 HP-UX 11i Release Names and Release Identifiers.......................................................................13 Typographic Conventions.........................................................................................................
1.3.12.3 Using Help... ...................................................................................................34 1.3.12.4 Product Information... ........................................................................................34 1.3.13 XToolkit Options and Changing Display Fonts .............................................................34 1.4 Working from the Command Line........................................................................................34 1.4.
3.1.4.3 Creating Custom Lists .........................................................................................69 3.1.4.4 Listing Patches....................................................................................................70 3.1.4.5 Using Software Codewords and Customer IDs .......................................................70 3.1.4.6 Listing Software by Levels.....................................................................................70 3.1.4.6.
4.5.5 Managing Multiple Versions of HP-UX........................................................................100 4.5.6 Listing Registered Depots..........................................................................................100 4.5.7 Listing the Contents of a Depot (swlist -d) ...................................................................100 4.5.8 Source Depot Auditing.............................................................................................101 4.5.
.2.1 Target Selection Window..........................................................................................121 7.2.2 Performing Actions...................................................................................................121 7.2.3 Selecting Multiple Targets.........................................................................................122 7.2.4 Selecting Individual Targets.......................................................................................123 7.2.
9.3.4 Restricting Access to Depots .....................................................................................151 9.3.5 Adding Target Hosts ...............................................................................................152 9.3.6 Temporarily Restricting Access ..................................................................................152 9.3.7 Closing the SD-UX Network .....................................................................................152 9.3.
10.3 Adding Control Scripts...................................................................................................172 10.4 Creating a Product Specification File (PSF) .......................................................................173 10.4.1 Product Specification File Examples .........................................................................173 10.4.1.1 Minimal PSF ..................................................................................................173 10.4.1.
11.4.1.2 LC_ALL...........................................................................................................214 11.4.1.3 LC_CTYPE.......................................................................................................214 11.4.1.4 LC_MESSAGES................................................................................................214 11.4.1.5 LC_TIME.........................................................................................................214 11.4.1.6 TZ......
12.1.1 Who Can Benefit?...................................................................................................231 12.1.2 How Does It Work?................................................................................................231 12.1.3 Limitations..............................................................................................................231 12.2 Setting Up Nonprivileged Mode......................................................................................232 12.2.
Glossary..................................................................................................277 Index.......................................................................................................
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.
audit(5) An HP-UX manpage. audit is the name and 5 is the section in the HP-UX Reference. On the web and on the Instant Information CD, it may be a hot link to the manpage itself. From the HP-UX command line, enter “man audit” or “man 5 audit” to view the manpage. See man(1). Book Title The title of a book. On the web and on the Instant Information CD, it may be a hot link to the book itself. Emphasis Text that is emphasized. Emphasis Text that is strongly emphasized.
• Software Distributor Administration Guide for HP-UX 11i v1, 11i v2, and 11i v3; December 2007, 5992–2146 • Software Distributor Administration Guide for HP-UX 11i v1, 11i v2: June 2006, B2355-90979 • Software Distributor Administration Guide for HP-UX 11i v2: September 2003, B2355-90789 • Software Distributor Administration Guide for HP-UX 11i v1.6: June 2002, B2355-90754 • Managing HP-UX Software with SD-UX For HP-UX 11i Version 1.
Please include the document title, manufacturing part number, and any comment, error found, or suggestion for improvement you have concerning this document.
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 2 Chapter Topics Topics: “SD-UX Overview” (page 17) “SD-UX Concepts” (page 19) “Using the GUI and TUI Commands” (page 23) “Working from the Command Line” (page 34) 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 3 SD Commands (continued) Command & Manpage Description/Features More Information swcopy(1M) • Copies software from one depot to another • “Copying Software Depots” (page 86) • Optional GUI • Removes installed software or software in a depot • “Removing Installed Software (swremove)” (page 78) • Optional GUI • “Removing Software from Depots” (page 102) swpackage(1M) • Creates packages of software which can then be used as a source for other SD-UX commands • Chapter 10: “Creating Software P
The sd, swinstall, swcopy, swlist, and swremove commands each have an optional Graphical User Interface (GUI) with windows and pull-down menus. The GUI commands also work on text-based terminals, providing a Terminal User Interface (TUI), which uses the keyboard instead of the mouse for screen navigation. You can invoke all SD-UX commands and programs from the command line. The syntax, options, defaults and operands are similar for all commands.
For most operations, controller programs access hosts and depots using an agent called swagent, which performs the basic software management tasks. The agent is accessed via a daemon called swagentd. When SD-UX operates on the local host, both controller and agent run on the local host. For remote operations, the agent runs on a remote host.
Figure 2 Example of HP-UX Software Structure 1.2.3 Installed Products Database SD-UX uses the Installed Products Database (IPD) to keeps track of what software is installed on a system. The IPD is a series of files and subdirectories that contain information about all the products that are installed under the root directory (/). (For depots, this information is maintained in catalog files beneath the depot directory.
Unpostinstall Undoes operations performed by a postinstall script in case swinstall must initiate recovery during the installation process. (Executed by swinstall.) Unpreinstall Undoes operations performed by a 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.
1.2.6.3 Types of Dependencies Software packagers can define corequisites, prerequisites, and exrequisites as dependencies. These dependencies can be specified between filesets within a product, including expressions of which versions of the fileset meet the dependency. 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.
Figure 3 The Terminal User Interface (TUI) NOTE: All examples for GUI commands in this manual also apply to the TUI. 1.3.2 Starting the GUI/TUI Commands To start the GUI or TUI for swinstall, swcopy, or swremove, enter: /usr/sbin/swinstall —or— /usr/sbin/swcopy —or— /usr/sbin/swremove TIP: Put /usr/sbin in your PATH to avoid typing the /usr/sbin prefix. The TUI starts by default if you have not set the DISPLAY variable.
Figure 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. Items in the menus may or may not appear, depending on whether selections are highlighted or not. Some actions may also be grayed out to show they are not available for a specific item. Message area Provides messages and system information.
Flags (Yes, Partial or blank) show whether items in the list have been marked for an activity (see the Marked? column). (For the TUI, mark items by pressing Space when the cursor is on the item and then press the m key. Unmark items with the u key.) 1.3.6 Preselecting Host Files The defaults.hosts file contains lists of hosts that are used by the GUI/TUI programs. This lets you use preselected choices for source and target systems. These lists are stored in the $HOME/ .swdefaults.
1.3.8.1 GUI Session Files Each invocation of one of the GUI commands defines a session. All session information—including the options used to invoke the command, source specifications, software selections, and target hosts—are automatically saved. This lets you re-execute the command even if the session ends before proper completion. (See “Session Files” (page 39).) 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.
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. • To apply the changes made to the object list, select Apply. The list is updated to reflect any changes made, and the Column Editor dialog remains open. • To apply the changes and close the editor, select OK. • 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 8: “Sort Dialog”,), which lets you specify a sort method for the object list. All viewable object attributes are listed. For each attribute, you can specify the type of sort desired.
Figure 9 Options Dialog NOTE: Use caution when changing option values. They allow useful flexibility but can produce harmful results if changed to an inappropriate value. Use the online help and consult Appendix A (page 235) to understand fully each option before you change it. 1.3.11 Performing Actions—The Actions Menu Each Action menu in the GUI/TUI programs has a series of actions for that command. These actions vary according to which command you invoke.
product by double clicking on the object or by selecting Actions ->Open Item. The object list then shows a listing of the subproducts for that product. If you want to open the subproduct, double click on it and its filesets are displayed. (In the TUI, move the cursor to the item you want to open and click Return.) When the product is opened, all of its subproducts (and filesets that are not part of a subproduct) are shown in the list. At the product level, only products are listed together.
1.3.11.3 Change Source The Change Source... menu choice opens the Specify Source dialog (Figure 11: “Specify Source Dialog”,), which lets you change the source for the software to be used. Figure 11 Specify Source Dialog 1. (Optional) To specify another host system, type a source host name, or: 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.
Figure 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 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).
1.3.12.1 Overview... This menu item provides information about the currently active SD-UX screen. This includes a list of the tasks you can do in that screen and a short description of the different areas of the screen and links to related topics. 1.3.12.2 Keyboard... This menu item brings up help on how to use the keyboard to control the application, covering topics such as selection, menu bar activation and traversal, dialog box traversal, etc. 1.3.12.3 Using Help...
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 15 Sample Command The example shows that you have several ways to specify SD-UX behavior including command-line options (such as -f and -s), input files (mysoft and /mnt/cd), and target selections.
The version component has the form: [,r revision][,a arch] [,v vendor][,c category][,q=qualifier][,l=location] [,fr revision][,fa arch] where: • Fully qualified software specifications include the r=, a=, and v= version components, even if they contain empty strings. For installed software, l= is also required. • All version components are repeatable within a single specification (e.g. r>=A.12, r
1.4.2 Target Selections Target selections follow software and source depot selections. If no target selection is named, the target on which the operation will be performed is assumed to be the root (/) directory on your local host. So, you do not have to use the @ sign and [host][:][/directory] designation (described below) if you are operating on the local host or default depot directory. 1.4.2.
3. 4. Options read from a session file affect only that session. Options changed on the command line by the -X option_file or the -xoption=value arguments override the system-wide and personal options files but affect only that invocation of the command. 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.
1.4.4 Session Files Before any SD-UX task starts, the system automatically saves the current command options, source information, software selections, target selections, etc., into a session file. You can then re-use this session information at a later time, even if the command fails. Session information is saved in the $HOME/.sw/sessions/ directory as command.last in which command is the name of the command. Each time you save a session file, it overwrites the previously stored one.
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.
(See Chapter 11: “Using Control Scripts ” (page 207)) • Software can be installed to alternate root directories. 2.1.2 Installing with the GUI Overview This section provides an overview of the swinstall GUI. • In general, all information presented in “Installing from the Command Line” (page 47) also applies to the swinstall GUI. • This section also refers to additional information about standard GUI elements, discussed in “Using the GUI and TUI Commands” (page 23).
Figure 16 Specify Source Dialog 1. (Optional) To specify another host system, type a source host name, or: 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.
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.
Figure 18 Analysis Dialog The following actions are 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. • Logfile presents a scrollable view of detailed install information written to the logfile.
Figure 19 Disk Space Analysis Window 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.
Step V: Installation In this step, SD-UX proceeds with the actual installation. After you click OK in the Analysis window, SD-UX starts installation and displays the Install Window, which shows status information. Figure 20 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).
-i Run the command in interactive mode by invoking the GUI or TUI. See “Installing with the GUI” (page 42). -p Preview the install task (perform analysis only). -r Operate on an alternate root directories. See “Installing to an Alternate Root ” (page 52). -v Turn on verbose output to stdout and display all activity to the screen. -c catalog Store a copy of a response file or other files created by a request script in catalog. See “Requesting User Responses (swask)” (page 227).
Table 7 swinstall Command Options and Default Values • admin_directory=/var/adm/sw • max_targets=25 • agent_auto_exit=true • mount_all_filesystems=true • agent_timeout_minutes=10000 • os_name • allow_downdate=false • os_release • allow_incompatible=false • patch_filter=software_specification • allow_multiple_versions=false • patch_match_target=false • allow_split_patches=false • patch_save_files=true • ask=false • polling_interval=2 • autoreboot=false • preview=false • autorecover_product=
swinstall -p -s softsource -f softlist \ @ myhost:/mydirectory The @ myhost:/mydirectory is optional if you are installing to your local host and default directory (root). NOTE: If you do not specify a source, swinstall uses the local host’s default depot directory, /var/spool/sw.
2.1.4.4 Installing Software That Requires a System Reboot Software packaged with the is_reboot attribute set to true requires the host to be rebooted after the software is installed. However, when installing to alternate root file systems, the host will not be rebooted. If a local installation entails a reboot, the system reboots the target and the controller, so there is no process left to report success or failure. (SD-UX does not automatically reconnect to the target after a reboot.
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.
Table 8 Product Compatibility (continued) Product attribute Product value (Pattern to match) Target Root attribute os_release ?.11.* B.11.11 uname -r os_version * C uname -v If allow_incompatible=false (the default), swinstall restricts the installation of incompatible software and automatically filters the products on the source. The Software Selection window shows only those products compatible with the hardware and OS of all target systems.
• Filesets or products can include configure (unconfigure) scripts. • The swinstall and swremove commands do not automatically run configuration scripts when you specify an alternate root directory with these commands. You must run swconfig to configure or unconfigure alternate roots. • Automatic configuration can also be postponed on software installed to the root directory, / (for example, when multiple versions are installed), by using the defer_configure command option with swinstall or swremove.
3. 4. 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.
2.2.3 Using swconfig Syntax swconfig [-p] [-u] [-v] [-c catalog] [-C session_file] [-f software_file] [-Q date] [-S session_file] [-t target_file] [-x option=value] [-X option_file] [software_selections] [@ target_selections] Options and Operands -p Preview a configuration task by running it through the Analysis Phase and then exiting. -u Unconfigure the software instead of configuring it. -v Turn on verbose output to stdout and display all activity to the screen.
Table 9 swconfig Command Options and Default Values • admin_directory=/var/adm/sw • logdetail=false • agent_auto_exit=true • logfile=/var/adm/sw/swconfig.
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.3 Verifying Your Installation (swverify) The swverify command verifies depot, installed, or configured software products on the specified host. 2.3.1 Features and Limitations • Determines whether installed or configured software is compatible with the host on which that software is installed.
1. 2. Initiate analysis Process software selections. The system accesses the Installed Products Database (IPD) or depot catalog to get the product information for the selected software: For installed software, the system checks that all products are compatible with its uname attributes. This check is controlled by the default option allow_incompatible: 3. 4. 5. • If allow_incompatible is set to false, the system produces an error stating that the product is not compatible with the host.
2.3.3 Using swverify Syntax swverify [-d|-r] [-F][-v] [-C session_file] [-f software_file] [-Q date] [-S session_file] [-t target_file] [-x option=value] [-X option_file] [software_selections][@ target_selections] Options & Operands -d Operate on a depot rather than installed software. See “Verifying a Depot (swverify -d) ” (page 102) -r Operate on an alternate root rather than /. Verify scripts are not run. -v Turn on verbose output to stdout and display all activity to the screen.
Table 10 swverify Command Options and Default Values • admin_directory=/var/spool/sw • installed_software_catalog=products • agent_auto_exit=true • job_title= • agent_timeout_minutes=10000 • loadorder_use_coreqs=true • allow_incompatible=false • log_msgid=0 • allow_multiple_versions=false • logdetail=false • autoremove_job=false • logfile=/var/adm/sw/swverify.
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 11 Chapter Topics Topics: “Listing Your Software (swlist)” (page 63) “Modifying the IPD (swmodify)” (page 74) “Removing Installed Software (swremove)” (page 78) 3.
Figure 21 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.1 Searching and Moving Through the List The following features help you search and move through the list: • To search the current list, select File→Search... • To display a pop-up menu of viewing options for an item, right-click on the item.
3.1.2.3 Performing Actions Use the Actions menu to open and close items on the display, show logfile information, and show software descriptions: • Open Item opens an item. (Same as double-clicking on the item.) • Close Level closes the current level. (Same as double-clicking on ..(go up). • Change Target opens a dialog box that lets you enter a path to select an alternate root (for swlist -i) or alternate depot (for swlist -i -d). • Show Logfile displays the system logfile.
-l level List all software objects down to the specified level: depot, bundle, product, subproduct, fileset or file. (See the section “Listing Software by Levels” (page 70) for more information on levels.) You can use only one level designation per command. You cannot use software names, subproduct names, etc. to specify levels. This option does not apply if you use the -c option.
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.
In the following examples, swlist requests are sent to the standard output. All examples assume the one_liner= default is “revision size title” and the level= default is “product.” • To list the contents of the local tape depot, /dev/rmt/0m, type: swlist -d @ /dev/rmt/0m — or — swlist -s /dev/rmt/0m This produces the following output AUDIT 3.5 COMMANDS 1.7 C-LANG 2.5 NETWORKING 2.1 KERNEL 1.4 VUE 1.3 WINDOWS 2.
3.1.4.1 Using Options to Change List Appearance You can control the appearance and content of your lists by changing list default values in the options files. Instead of repeatedly specifying the software levels and attributes each time you invoke swlist, you can use: level This option pre-determines what level to list: product, subproduct, fileset or file.
You can also change the one_liner default value to {revision size title} in the defaults file. Then a listing of the C-LANG products on host2 would be as follows: swlist C-LANG @ host2 C-LANG.C-COMPILE 8.0 C-LANG.C-LIBS 8.0 C-LANG.C-MAN 8.0 1346 2356 1976 C Compiler Components Runtime Libraries Programming Reference 3.1.4.4 Listing Patches You can use swlist to list software patches and their status. 3.1.4.
2) a list that contains software attributes (-a and -v). For example, if you wanted to see all the products installed on your local host, your command would be: swlist -l product and the listing would look like this: NETWORKING SAM OPENVIEW PRODUCT A SOFTWARE Z PRODUCT B . . . Note that the product names are uncommented because that was the level you requested to display and there are no levels above. 3.1.4.6.
NETWORKING.ARPA_INC:/usr/include/arpa/ftp.h NETWORKING.ARPA_INC:/usr/include/arpa/telnet.h NETWORKING.ARPA_INC:/usr/include/arpa/tftp.h NETWORKING.ARPA_INC:/usr/include/protocols/rwhod.h . . . # NETWORKING.ARPA_RUN NETWORKING.ARPA_RUN:/etc/freeze NETWORKING.ARPA_RUN:/etc/ftpd NETWORKING.ARPA_RUN:/etc/gated NETWORKING.ARPA_RUN:/etc/named . . . # NETWORKING.ARPA_MAN NETWORKING.ARPA_MAN:/usr/man/man8/ftpd NETWORKING.
If the -v option is used with the -l option, the cases are: • To display all attributes for a bundle, use swlist -v -l bundle. • To display all attributes for a product, use swlist -v -l product. • To display all attributes for products and subproducts, use swlist -v -l subproduct. • 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.
revision title size state corequisite is_kernel file path type mode owner group uid gid mtime size file path type mode owner group uid gid mtime size ... 1.2 ARPA run_time commands 556 configured NETWORKING.LANLINK true etc/freeze /etc/freeze f 0755 bin bin 2 2 721589735 24 etc/ftpd /etc/ftpd file 0555 bin bin 2 2 721589793 9 This command: swlist -v NETWORKING.ARPA-RUN produces the following listing: # NETWORKING.ARPA fileset tag ARPA-RUN instance_id 1 revision 1.
• Change attribute values for any existing object. • Define attributes for new objects that you add. The equivalent IPD files for a depot are called catalog files. When a depot is created or modified using swcopy, catalog files are built (by default in /var/spool/sw/catalog) that describe the depot and its contents. 3.2.
-r Perform modifications on an alternate root instead of the primary root. Your target_selection must be an alternate root. -u If no -a attribute options are specified, then delete the specified software_selections from within your target_selection. This action deletes the definitions of the software objects from the depot catalog or Installed Products Database. If -a attribute options are specified, then delete them from within the given target_selection. -v Turns on verbose output to stdout.
software_selections from the software defined in the given (or default) target_selection. The product specification file (PSF) for swmodify uses the same swpackage PSF format as defined in “Creating a Product Specification File (PSF) ” (page 173). -S session_file Run the command based on values saved from a previous installation session, as defined in session_file. See “Session Files” (page 39). -x option=value Sets a command option to value and overrides default values or a values in options files.
For More Information See Appendix A (page 235) for complete descriptions of each default. 3.2.3 swmodify Tasks and Examples Here are some examples of how you can use swmodify to change catalog files or IPDs: 3.2.3.1 Adding Information to the IPD To add descriptions of files /tmp/a, /tmp/b, and /tmp/c to an existing fileset: swmodify -x files=/tmp/a /tmp/b /tmp/c PRODUCT.FILESET If a control script adds new files to the installed file system, the script can use swmodify to make a record of the new files.
Preremove Performs additional file operations, such as removing files created by a preinstall script. 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 207). • 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.
Figure 22 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.
Figure 23 Remove Analysis dialog After analysis, if any of the selected software can be removed, the status indicates Ready or Ready with Warnings. If none of the selected software can be removed, the status indicates Excluded from task. The Products Scheduled column shows the number of products ready for removal out of all products selected.
These action buttons are available: • Done returns you to the Software Selection Window. You can then begin another removal or exit the GUI (File→Exit). • Product Summary display removal and product information (name, revision, removal results, removal summary). • Logfile displays the logfile. Figure 24 Remove Window 3.3.
-S session_file Run the command based on values saved from a previous removal session, as defined in session_file. See “Session Files” (page 39). -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 37). -x option=value Sets a command option to value and overrides default values or a values in options files. See “Changing Command Options” (page 83).
To preview the remove of the C and Pascal products installed at the local host: swremove -p cc pascal To remove a particular version of HP Omniback: swremove Omniback,l=/opt/Omniback_v2.0 To remove the entire contents of a local depot: swremove -d * @ /var/spool/sw 3.3.4.1 Removing Bundles Removing a bundle does not always remove all filesets in that bundle. Because of SD-UX’s dependency management features, a fileset that is required by another bundle will not be removed.
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 20 Chapter Topics Topics: “Depot Management Commands and Concepts” (page 85) “Copying Software Depots” (page 86) “Registering and Unregistering Depots (swreg) ” (page 95) “Additional Depot Management Tasks and Examples” (page 98) 4.
Network depots offers these advantages over installing directly from media: • Several users can pull software down to their systems (over the network) without having to transport media to each user. • Installation from a network server is faster than from media. • You can combine different software products from multiple media or network servers into a single depot. 4.1.1.1 Types of Depots A depot usually exists as a directory location.
4.2.1 swcopy Features and Limitations • swcopy does not perform compatibility checking. • swcopy does not run control scripts. • swcopy does not perform kernel building or rebooting, although it does perform other pre-install and postinstall checks, such as disk space analysis and requisite selection. • When you create or modify a depot with swcopy, SD-UX automatically creates catalog files that describe the depot. These are stored in the IPD.
Figure 25 Select Target Depot Path Dialog 1. Enter a target path: • Type a new target path in the text box. — or — • 2. Click the Target Depot Path... button. The Depot Paths dialog appears, listing registered depots on the host. 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. Click OK. The Select Target Depot Path dialog disappears, and the Specify Source dialog is highlighted.
a. b. c. 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). Choose a host name from the list. 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.
3. • Change Source...cancels your software selections and returns you to the Specify Source dialog. • Add New Codeword lets you add a new codeword to unlock protected software. Up to 62 codewords can be entered during a single session using this option. (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.
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 29 Disk Space Analysis Window When Analysis completes, the status for any host displays as either Ready or Excluded from task. If any of the selected software can be copied onto the host, the status shows Ready. If none of the selected software can be copied onto the host, the status shows Excluded from task.
The Products Scheduled column shows the number of products ready for copying out of all products selected. These include: • Products selected only because of dependencies • Partially selected products • Other products and bundles that were selected Step VI: Copying In this step, SD-UX proceeds with the actual copy. After you click OK in the Analysis window, SD-UX starts copying and displays the Copy Window (Figure 30: “Copy Window”,), which shows status information.
-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 39). -f software_file Read a list of software selections from a separate file instead of (or in addition to) the command line. See “Software Files” (page 36). -Q date Schedules a job for the given date when remote operations are enabled.
Table 23 swcopy Command Options and Default Values • admin_directory=/var/adm/sw • polling_interval=2 • agent_auto_exit=true • preview=false • agent_timeout_minutes=10000 • recopy=false • allow_split_patches=false • register_new_depot=true • autoremove_job=false • reinstall=false • autoselect_dependencies=true • reinstall_files=true • autoselect_minimum_dependencies=false • reinstall_files_use_cksum=true • autoselect_patches=true • remove_obsolete_filesets=false • autoselect_reference_bundle
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.
registered before software may be installed or copied from it. This check is always performed before granting access, except when swinstall is run by the local superuser. NOTE: Registration of a depot does not enforce any access restrictions. Access enforcement is left to SD security (see Chapter 9: “SD-UX Security ” (page 145)). Registration with swreg requires insert permission in the host’s ACL. 4.3.
Table 24 swreg Command Options and Default Values • admin_directory=/var/adm/sw • distribution_target_directory=/var/spool/sw • level= • log_msgid=0 • logfile=/var/adm/sw/swreg.
If the depot is located on a remote machine, the remote machine must have a version of SD installed that supports signature verification. To see the details of signature verification, run the swjob command displayed at the end of the swverify session. To verify the signatures in a signed HP-UX DVD media prior to cold installation (Ignite), mount the DVD locally and run swsign –v –s /mnt/dvd, where mnt/dvd is the location of the mounted DVD.
# 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 171) for more information about swpackage. 4.5.
7. Merge all products on the mounted CD to the target depot, for example /update/update-depot: swcopy -s /cdrom \* @ /update/update-depot 8. Unmount the CD from directory /cdrom: umount /cdrom 9. Insert the HP-UX 11i CD2. Wait for the drive’s busy light to stop blinking. 10. Repeat Steps 6 through 8 using CD2 and the Support Plus CD. The network depot is now ready for you to use to update your HP-UX 10.20 or 11.0 system to HP-UX 11i. 4.5.
The swlist -d option lets you list software residing on the default depot on your local host. For browsing any depot in the GUI, you can use swlist -i -d. You can also view the associated session and audit log files. NOTE: By default the output of swlist will reflect the POSIX format for attributes. This may affect users who parse this output. In the following examples, swlist output requests are sent to standard output.
4.5.9 Verifying a Depot (swverify -d) To can use the swverify command to verify the software within a depot. swverify performs these tasks: • Verifies that all dependencies (prerequisites or corequisites) can be met. • Reports missing files. • Checks file attributes, including permissions, file types, size, checksum, mtime, and major/minor attributes. For example, to verify the entire contents of a local depot: swverify -d \* @ /var/spool/sw NOTE: depot.
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 they also deliver new functionality and features, enable new hardware, and update firmware. You can use HP-UX patches to update HP-UX software without reinstalling 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 119). Table 25 Chapter Topics Topics: “Introduction ” (page 105) “Using the Job Browser ” (page 106) “Monitoring Jobs from the Command Line” (page 114) “Managing and Tuning Jobs with Command Options” (page 116) 6.
6.2 Using the Job Browser Figure 31 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 23). 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.
This icon represents a copy job (depot to depot). A check mark indicates that the job has completed. Figure 33 Active Install Job Icon This icon represents an install job. The ruler on the side indicates that the job is active. Figure 34 Scheduled Install Job Icon This icon represents an install job that is scheduled for a later time. The clock face indicates that it is a scheduled job. Figure 35 Install Job with Warnings Icon This icon represents an install job that completed, but contained warnings.
Figure 37 Scheduled Remove Installed Software Job Icon This icon represents a scheduled remove job on installed software. Figure 38 Scheduled Remove Depot Software Job Icon This icon represents a scheduled remove job on software contained in a depot. Figure 39 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.
in “Changing Software Views—The View Menu” (page 27). Note, however, that the Columns... choice is only valid for View→By Properties (discussed below). Figure 40 Jobs Displayed by Properties 6.2.3.1 Viewing By Name and Icon • Choosing View→By Name and Icon displays the jobs list in name and icon format. • This menu item and the View→By Properties menu choice operate as radio buttons. When one is chosen, the other is un-chosen. 6.2.3.
Figure 41 Refresh Interval Dialog • Apply immediately applies the interval you have selected. • Save Interval as Default sets the selected refresh interval as the default for future sessions. To change the refresh interval for the SD-UX daemon, see “Managing and Tuning Jobs with Command Options” (page 116). 6.2.4.2 Refreshing the Jobs List To immediately update the Jobs List, choose Options→Refresh List. 6.2.
Table 26 Job Actions Options (continued) Job Actions & Selections Copy Software to a Depot... swcopy session. Remove Software from a Depot... swremove -d session. 6.2.5.3 Showing Job Results Selecting Actions→Show Job Results... displays the Job Results dialog, which lists results for the job selected. (You can also reach this dialog by double-clicking a Job Browser icon.) • The object list shows the list of targets for the job, their type, and job status.
Figure 42 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... opens the Job Description dialog, which contains all the information specified when the job was created, including: • All job attributes (ID, type of operation, scheduling, current state, results, when last updated, source) • Name and revision of the software • Targets involved and target type: ◦ primary root ◦ alternate root ◦ depot Figure 43 Show Job Description • Selecting Show Options...
6.2.5.6 Copying Jobs Copying a job consists of making the target and software selections available to a new session of swinstall, swcopy, or swremove. The new session is invoked automatically, using the same hosts, sources, software and target selections from the selected job. You can then re-use the same settings or make changes as needed. This feature gives you the same advantages as using a session file in swinstall, swremove, or swcopy session.
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 XToolkit_Options X window options for use with swjob -i. See “XToolkit Options and Changing Display Fonts ” (page 34). -i Starts the SD interactive job browser. See “Using the Job Browser ” (page 106). -u Causes swjob to remove the specified jobs.
For More Information See Appendix A (page 235) for more information about setting options and a complete listing and description of each option. 6.3.1 swjob Attributes Each job has its own set of attributes. These attributes include job title, date of scheduled execution, and results. The -a option selects a specific attribute to display. You can specify multiple -a options to display multiple attributes.
The format for date is: MM/DD[/YYYY][,HH:MM][AM|PM] For example, to install the C and Pascal products on June 23, 2001, at 10:14 a.m.: swinstall -Q 06/23/2001,10:15AM -s sw_server cc pascal 6.4.2 Adding Job Titles Purpose: to help you identify jobs. When running large numbers of jobs, you may want to add more information to help you identify a specific job. You can do this from the Job Browser or by invoking swconfig, swcopy, swinstall, swremove, and swverify with the job_title command option.
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.
either the command line interface (with the swjob command) or the interactive interface (with the sd command). 7.1.1.4 Compatible Software The swconfig, swinstall, and swverify commands let you detect and enforce the use of compatible software (i.e., ensure software products are compatible with system types and operating systems). When you select multiple targets for a remote operation, SD-UX lets you select only the software compatible with all targets. 7.1.1.
target lists, job preferences, and job monitoring windows. Otherwise, the GUI programs are identical to those used for local operations. After you set up remote operations and enable the remote operations GUI on the central controller, you can start the swinstall, swcopy, or swremove GUI as you normally would. For example: /usr/sbin/swinstall or /usr/sbin/swinstall -i NOTE: The Terminal User Interface (TUI) is not available with remote operations. 7.2.
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 124)). 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.
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. 2. Select Actions→Add Target Group.... The Select File dialog appears. All existing target groups appear in the list. Select the target group you want and click OK. The targets from that group are now marked, along with any other targets you had already marked. 7.3 Setting Up Remote Operations SD-UX uses Access Control Lists to authorize anyone who is attempting to create, modify, or read software products in a depot or to install software to a root file system.
4. Make sure your DISPLAY variable is properly set by typing: echo $DISPLAY 5. Ensure that the examples are installed. Enter: swlist SW-DIST.SD-EXAMPLES 6. Create the depot containing example package (i.e., SD-DATABASE): cd /usr/lib/sw/examples/swpackage/depot_src swpackage -s psf @ /var/adm/sw/examples/depot swreg -l depot @ /var/adm/sw/examples/depot 7.
Figure 47 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. Then select Actions→Mark for Install (or right-click to display the pop-up menu and select Mark for Install). b. Select Actions→Show Software for Selection... This displays the Specify Source dialog. If this is your first time through this tutorial, skip directly to “Step III: Select Source” (page 127).
Figure 48 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. Select OK in the Add Targets dialog. This updates the Target Selection Window with your target selection. Yes appears in the Marked column, indicating that the target is marked for installation. Choose Actions→Show Software for Selection. The Specify Source dialog appears.
Figure 49 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.
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 31 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.
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 52 (page 130)). 3. 4. If this is your first pass through the tutorial, proceed to Step V. (Optional) Previewing a Job a. Select the Preview button. This tells SD to analyze the software without installing it. b. Click OK. The Install Analysis dialog appears.
1. When the Analysis is complete, the status for the target you selected should show Ready, indicating no errors or warnings occurred during analysis. Select OK to proceed with the installation. The Install Window dialog (Figure 53: “Install Window dialog”,) appears, and the installation starts automatically. When the status in the dialog changes to Completed, the installation has successfully completed. Figure 53 Install Window dialog 2. 3. 4. Select Done to exit the Install Window dialog.
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.1 Syntax Software and source depot selections are followed by target selections. These operands are separated by the “@” (at) character. This syntax implies that the command operates on selections at targets. The target_selections syntax is identical for all Software Distributor commands that require it: @ [host][:][/directory] | [./relative_path] | [../relative_path] • Only one @ character is needed. • You can specify the host by its host name, domain name, or internet address.
7.6.2.
7.6.2.8 swreg To unregister the default depots on three remote hosts: # swreg -u -l depot /var/spool/sw @ hostA hostB hostC To unregister the default depots on the remote hosts with the IPv6 address ffe:ffff:101::230:6eff:fe04:d9ff: # swreg -u -l depot /var/spool/sw @ ffe:ffff:101::230:6eff:fe04:d9ff 7.6.2.
8 Reliability and Performance This chapter describes the interrelationship of Software Distributor reliability features and performance. Understanding how these features work together will help you improve the overall reliability of your software distribution system.
• Database checkpointing: SD-UX commands perform automatic checkpointing at the fileset level by recording database transactions in the SD-UX depot catalog (IPD). In addition, checkpointing at the file level is supported through attributes stored with the file. • Compression: SD-UX supports compression functionality to reduce the amount of data being transferred.
through 9. A 0 value means no retry is attempted; if the connection is lost, the command will fail. The default value is 1. For less stable networks, a value of 5 is recommended. NOTE: When setting retry_rpc to a value greater than 0, the reinstall_files option should also be set to false (the default value), so the same files are not recopied when a fileset is retried.
When the reinstall_files option is false, the user can also control which attributes are checked in order to determine if the fileset is already installed or available. If the reinstall_files_use_cksum option is set to true, the size, mtime, and cksum attributes are checked. 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.
8.8.1 INDEX and INFO Compression Another way to reduce your network traffic is by compressing INDEX and INFO files from the source depot to the target. You can turn on INDEX or INFO compression by setting the compress_index option to true in the defaults file (/var/adm/sw/defaults). The SD-UX controller and target agents will request compressed INDEX files from the source agent.
option is specified from either the CLI (i.e., -x use_alternate_source=true) or via the Options Editor window in the GUI. The default value is false. # swinstall -s master \ -x use_alternate_source=true \ -t targ_list NewApp The use_alternate_source=true option instructs each target to use its own configured source for the installation. The source that is specified on the swinstall CLI is used only by the controller for the validation of your software selections.
a. b. c. 3. execute the preinstall script install the files execute the postinstall script 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. In this case, patches can be removed (rolled back) or committed (by removing saved files).
Additionally, you can list a fully qualified software spec containing both the location and revision as well as the other version distinguishing attributes (vendor and architecture) with: swlist -l fileset -a software_spec After the new version is installed successfully for all products or on all hosts, the old version can be unconfigured, and the new version configured as the active version by using swconfig -u with the old version and swconfig with the new version.
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.
9.1.2 Depots and Depot Registration Software Distributor typically uses central depots to distribute software. You can control access to these depots by users who will install software. An important security consideration is that depots must be registered for nonlocal users to have access. Only a local superuser or a user with insert permission on the host can install from unregistered depots.
-X option_file Uses the option values in a specified option_file. See “Using Command Options” (page 37). software_selections The software objects for the swacl operation. See “Software Selections” (page 35). target_selections The target of the command. See “Target Selections” (page 37). 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.
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 55 Access Control Lists ACLs offer a greater degree of selectivity than do permission bits. An ACL extends the concept of the HP-UX file system’s permission bits by letting you specify different access rights to several individuals and groups instead of just one of each.
# # For host: swelter:/ # # Date: Wed Feb 28 14:58:02 2001 # # Object Ownership: User= root # Group=sys # Realm=swelter.fc.hp.com # # default_realm=swelter.fc.hp.com object_owner:crwit any_other:-r--- This ACL indicates that the file system is owned by the root user, and that as such, the owner has full ACL permissions (crwit). Additionally, all other users may read SD information about this root file system using the swlist command.
# # For host: newdist # # Date: Fri Nov 03 10:34:06 2001 # # Object Ownership: User= root # Group=sys # Realm=newdist.fc.hp.com # # default_realm=newdist.fc.hp.com user:fred:crwit user:root:crwit user:smp:crwit user:root@udltools.fc.hp.com:crwit user:fred@hpfred.fc.hp.com:crwit user:chrisr@prewd.fc.hp.
swacl -l root -M user:mary:a @ mysys To allow user mary to install software into the default root: swacl -l root -M user:mary:ri To give user mary the permission to open the root for reading: swacl -l root -M user:mary:r 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 's
# 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. To allow only user shelly on host swcrunch to access software in a depot located on swelter, it may appear that adding a user ACL for shelly would be sufficient: swacl -l depot -M user:shelly@swcrunch:r @ /simple_1.depot However, this is not enough.
NOTE: Do not change the default secret field unless you have also changed the default secret on the HP-UX SD-UX controller. These two secrets must match. The set of hosts that can be managed by SD-UX can be restricted by changing the default secret on all SD-UX controller and target hosts in the network. The default secret is found in /var/adm/sw/security/secrets.
# swacl -l product_template @ /var/spool/sw_dev >tmp_file Then edit the tmp_file and replace the ACL: # swacl -l product_template -F tmp_file \ @ /var/spool/sw_dev To delete entries for user barb and group swadm, use: # swacl -D user:barb -D group:swadm -l product FORTRAN To give user ramon permission to modify the product FORTRAN, type: # swacl -M user:ramon:trw -l product FORTRAN To add an entry for user pam with complete management permission (“a” is shorthand for crwit), use: # swacl -M user:pam:a
NOTE: You can specify crwit permissions in any order.
NOTE: The remote-host cannot be specified in IPv6 format. This feature is not supported in ACL entries. 9.5.2 ACL Permissions There are five different permissions grantable by the ACL: crwit. Table 37 ACL Permissions control (c) Permission to edit or change the ACL. test (t) Permission to test access to an object (i.e., read the ACL). insert (i) Permission to install a new product, depot or root. write (w) Permission to change a host, depot, root or product.
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.
A sample host-system ACL grants depot and root source creation, source listing, and ACL administration to a user named rob and give open permission to list the depots and roots on the host, would be: user:rob:r-icany_other:r Since any_other does not havet (test) permission, only rob can list this ACL, because he has c (control permission). 9.5.3.2 Root ACLs Principals (users) identified in ACLs that are protecting roots are granted permission to manage installed products.
9.5.3.4 Product ACLs Product ACLs only apply to products on depots. Products on roots are protected by the root’s ACL. There are two classes of principals that are granted access rights to products: Table 42 Product Principals users Granted various administrative permissions. This class includes groups and others, both local and remote. hosts Target systems (agent/daemons) granted read permissions to allow product installation.
Thus, there are three ACLs on the host: • Host ACL Attached to and controlling access to the host object itself. • Container ACL Template (global_soc_template) Used to initialize the ACL protecting new depots and roots created on the host. • Product ACL Template (global_product_template) The ACL that is used to initialize the product ACL template on depots that are created on the host. There are also two ACLs on product depots: • The depot’s ACL that is used to determine permissions on the depot.
entry, of each product. It also grants permission to read (i.e., install) and test the product to any host (the any_other entry). object_owner:crwit any_other:-r--- • In addition to encompassing all hosts, the any_other entry also applies to all other users except, in this case, the product’s owner.
• SD-UX files are protected from access by anyone other than the superuser by having the group and other permissions of crucial directory modes set to 0. • Only agents and daemons running on the local host access SD-UX files directly. All other facilities (controllers, utilities, etc.) go through the agents using RPC to indirectly access files. The agent or daemons perform authentication and authorization checks on all such operations.
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).
When you change a host’s secret, make sure you change it in the secrets files of all hosts with which you work. The secrets file may be produced in a single site, then copies distributed to all participating hosts. NOTE: The secrets discussed here does not grant any access to SD-UX objects, but do allow a host to participate in SD-UX operations. 9.
3. 4. SwagentA (running as principal H) forms a request to swagentB (running where depot D resides) to read the product. SwagentB checks the ACL protecting the product to make sure that both the destination system (principal H) and the user U have read permission before honoring the request, and the installation proceeds. The ACL on swagentB neither knows of nor depends on user U. The ACL on root R acts to screen U; then (and only then) the product’s ACL acts to screen H.
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.1 Security in Remote Distributions A common use of SD-UX remote operations capabilities is for a software administrator to push software from a local depot out to numerous remote targets. You can set up of this kind of configuration: 1. 2. Establish the group swadm on the controller host as described above.
You should also not have products that are being tested, coming and going on wide-use depots and roots. They might accidentally be installed or used before they are ready. The recommended method of development is to provide one or more development depots and roots for testing purposes, each with protections customized to meet the needs of the development group using them. To this end, the default ACL template mechanism described previously is handy, since products come and go quickly.
• The source agent verifies that the target agent system has read permission on the source product. • The source (depot) agent verifies that the depot is registered. If not, the agent verifies that the controller user and the target agent system each has insert permission on the source’s host. 9.10.5 Installing (swinstall) • Any list operations required to facilitate this function must be checked as described in the swlist section above.
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 44 Chapter Topics Topics: “Overview of the Packaging Process ” (page 171) “Identifying the Products to Package ” (page 171) “Adding Control Scripts” (page 172) “Creating a Product Specification File (PSF) ” (page 173) “Packaging the Software (swpackage) ” (page 195) “Packaging Tasks and Examples” (page 200) 10.
Key points in this structure are: • Where are shareable (for example, executables) and non-shareable (for example, configuration) files installed? • How is configuration used to put non-shareable files in place? 10.2.2 Determining Product Structure Determine the product structure that your software should follow.
Postremove Performs additional remove operations (such as restoring “rollback” files) immediately after a fileset or product has been removed. (Executed by swremove.) Preinstall Performs file operations (such as removing obsolete files) immediately before installation of software files. (Executed by swinstall.) Preremove Performs additional file operations (such as removing files created by a preinstall script) immediately before removal of software files. (Executed by swremove.
tag file NOTE: commands swcopy /usr/sbin/swcopy 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.hp category tag system_mgt title Systems Management Applications description These are the system management applications revision 1.
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...) directory ./nls=/usr/lib/nls/C file swinstall.cat file swpackage.cat directory ./ui=/var/adm/sw/ui file * # (...Other file definitions can go here...) end # Commands # (...Other fileset definitions can go here...
• Keywords marked with a + apply to products only. • Keywords marked with a - apply to bundles only. • Keywords marked with a * are of the version_component type, as well as the type indicated in the table. Table 45 Keywords Used in the Product Specification File Keyword Value Max Size in bytes Example revision_string tag_string multi_line_string multi_line_string one_line_string one_line_string 64 64 8K 8K 256 256 1.0 EXAMPLE_DEPOT < data/copyr.depot data/descr.
Table 45 Keywords Used in the Product Specification File (continued) Keyword Value Max Size in bytes Example tag_string repeatable list of product.fileset revision_string tag_string software_spec multi_line_string software_spec boolean boolean one_line_string boolean boolean uname_string uname_string uname_string uname_string software_spec revision_string software_spec one_line_string 64 none commands prod.oldfileset 64 64 none 8K none 9 9 256 9 64 64 64 64 64 none 64 none 256 HP-UX_B.11.
10.4.2.2 Selecting the PSF Layout Version You can select the layout version in the depot definition in the PSF (see “Product Specification File Semantics” (page 181)) or with the layout_version option for swpackage, swmodify, swcopy, or swlist. PSF syntax conforms to the layout_version=1.0 of the IEEE Standard 1387.2: Software Administration (POSIX). Previous versions of SD supported the POSIX layout_version=0.8 syntax, which continues to be supported.
file_specification • Maximum length: none • Explicitly specifies a file or directory to be packaged, using the format: [-m mode] [-o [owner[,]] [uid]] [-g [group[,]][gid]] [-v][source] [destination] multi_line_string • The source and destination can be paths relative to source and destination directories specified in the path_mapping_string. • You can also use * to include all files below the source directory specified by a directory keyword.
[-m mode|-u umask] [-o [owner[,]][uid]] [-g [group[,]][gid]] where each component defines a default permissions value for each file and directory defined in a fileset. The default values can be overridden in each file’s specific definition. The owner and group fields are of type tag_string. The uid and gid fields are of type unsigned integer. The mode and umask are unsigned integers, but only supports the octal character set, 0-7.
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.
title The full name of the target depot (tape) being created/modified by swpackage. end Ends the distribution specification, no value is required. This keyword is optional. If you use it and it is incorrectly placed, the specification will fail. 10.4.2.4.3 Vendor Specification The vendor attributes let you add a description to the PSF. The layout_version defined for the PSF file determines how vendor specifications are associated with products and bundles.
revision 0.0 end Each keyword defines an attribute of the category object. If a category specification is included in the PSF, swpackage requires only the category and tag keywords. category Keyword that begins the category specification. tag The category short name identifier. Associates this object with a product or bundle. This tag attribute must match the category_tag attribute in the product or bundle. title A one-line string that defines the full name for the category.
product Required keyword that begins the product specification. tag The product’s identifier (short name). architecture The target system on which the product or bundle will run. Provides a human-readable summary of the four uname attributes (machine_type, os_name, os_release and os_version), which define the exact target system(s) the product supports. bundle Required keyword that begins the bundle specification.
The value is matched against a target’s uname -m or getconf _CS_HW_CPU_SUPP_BITS result. number The part or order number of the product. os_name The operating system name on which the product will run. If not specified, the attribute is assigned a value of *, meaning it will run on all operating systems. If there are multiple operating systems, use wildcards or the | symbol to separate them. The value is matched against a target’s uname -s or getconf _CS_KERNEL_BITS result.
subproduct Keyword that begins a subproduct specification. tag The subproduct’s identifier (short name). 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.
and can be used independent of patches. The default value is an empty list or patch if the is_patch attribute is set to true.Like vendor_tag, this attribute can be used as a pointer to a category object that contains additional information about the category (for example, a one-line title definition and a description of the category). NOTE: The category tag patch is reserved.
9000/7??:32* Series 700, 32-bit capable hardware required. *:*64 64-bit capable hardware required. *:32: 32-bit capable hardware required. 9000/7??:*64 Series 700, 64-bit capable hardware required. 9000/[78]??:32* Series 800, 32-bit capable hardware required. 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.
(Note that a corequisite dependency does not imply any “run-time dependency” (load order). However, the corequisite dependency may affect the fileset load order. This behavior can be controlled by the loadorder_use_coreqs option. For more information on loadorder_use_coreqs, see “Options Listed Alphabetically” (page 236).) Exrerequisite Software that may not be present when the fileset is operated on by SD-UX.
swpackage generates an error if the PSF contains an unrecognized or unpackageable file type. The swpackage command supports specific mechanisms for specifying the files contained in a fileset: default permission specification For all or some of the files in the fileset, you can define a default set of permissions. directory mapping You can point swpackage at a source directory in which the fileset’s files are located.
The following examples illustrate the use of the file_permission keyword.
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.
This option marks the file as volatile, meaning it can be modified (that is, deleted) after it is installed without impacting the fileset. -v Files that may have their attributes (size, last modified time, etc.) changed through normal use after they are installed should be specified in the PSF file as volatile (by specifying -v on the line defining the file).
source directory in the fileset. (Partial wildcarding is not supported, e.g. file dm* to indicate all files starting with “dm”.) All attributes for the destination file object are taken from the source file, unless a file_permission keyword is active (this keyword is described below). The user can specify multiple directory file source[=destination] * pairs to gather all files from different source directories into a single fileset.
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. (See “Explicit File Specification ” (page 191)). 10.
Figure 58: “An Overview of the Packaging Process”, shows an overview of the swpackage session. Figure 58 An Overview of the Packaging Process Phase I: Selection When you run swpackage, you must specify a PSF and any other options you wish to include.
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.
Phase IV: Make Tape This optional phase occurs only when you package to a distribution tape. • In this phase, swpackage copies the source files and a temporary depot catalog to the tape. • swpackage does a tape space calculation to ensure that the tape can hold the software package. If one tape cannot hold it all, then swpackage will partition the software across multiple tapes. • swpackage cannot compress files when writing to a tape. 10.5.
software_selections The software objects to be installed. See “Software Selections” (page 35). If you do not include this specification, swpackage packages all the products listed in the PSF. @ target_ selections The target of the command. See “Target Selections” (page 37). If you are creating a distribution depot (directory), this operand defines the location of the directory. Without this operand, /var/spool/sw is used as the default depot directory.
10.5.1.1 Output of Logfile Messages The log file /var/adm/sw/swpackage.log captures output from the swpackage session. • Message logging by default sends verbose messages to stdout. (Setting the verbose option to 0 reduces the amount of information in stdout.) • Message logging also sends errors and warnings to stderr. • No logfile messages are written in preview (-p) mode. • The logfile is equal to stdout plus stderr.
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 95). 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.
the SD-UX security provisions for remote operations do not apply to swpackage. See Chapter 9: “SD-UX Security ” (page 145) for more information on ACLs. The swpackage command operates as setuid root, that is, the Package Selection phase operates as the invoking user, the Analysis and Packaging phases operate as the superuser. The superuser owns and manages all depots and therefore has all permissions for all operations on a depot.
The depot’s product_template ACL is generated from the host’s global_product_template ACL (that is, the host’s template ACL for new products). The user running swpackage is established as the owner of the new depot and is granted permissions as defined in the depot ACL (which come from the global_soc_template). New product swpackage creates an ACL for the product; the ACL is generated from the depot’s product_template ACL.
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 feature lets you package products in a development or test environment without consuming the full disk space of copying all the source files into the target depot.
If the superuser does have write permission on the remote file system and you set the write_remote_files to true, swpackage creates the new depot and package products into it. The constraints for an existing NFS mounted depot are the same as when creating a new depot. So, you must: 1. 2. Set the write_remote_files option to true and Make sure the superuser can write to the NFS file system to package a depot on an NFS-mounted file system.
To continue with the next tape, enter one of the following responses: Return Use the same device. pathname Use the new device/file pathname. quit Terminate the write-to-tape operation. Partitioning is done at the fileset level, so a product can span multiple tapes. A single fileset’s contents cannot span multiple tapes. If any single fileset has a size that exceeds the media capacity, swpackage generates an error and terminates. It also generates an error if the catalog will not fit on the first tape.
11 Using Control Scripts This chapter discusses how to use control scripts. Table 49 Chapter Topics Topics: “Types of Control Scripts ” (page 208) “Using Environment Variables ” (page 213) “Execution of Control Scripts ” (page 216) “Execution of Other Commands by Control Scripts ” (page 222) “Control Script Input and Output” (page 222) “File Management by Control Scripts ” (page 224) “Testing Control Scripts ” (page 224) “Requesting User Responses (swask)” (page 227) 11.
11.1.1 Types of Control Scripts Here are the control scripts that SD-UX supports: • Checkinstall Script This script is run by swinstall during its Analysis phase to insure that the installation (and configuration) can be attempted. For example, the OS run state, running processes, or other prerequisite conditions beyond dependencies could be checked. It should not change the state of the system.
For a product to be recoverable, no files should be removed by preinstall or postinstall scripts. Configure scripts are a good place to remove obsolete files. NOTE: • Product level unpostinstall scripts are not supported. Configure Script This script is run by swinstall or by swconfig to configure the host for the software, or configure the software for host-specific information.
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.
11.1.1.3 Control Script Format A control script should be a shell script (as opposed to a binary) and written to be interpreted by the Posix.2 shell /sbin/sh. Korn shell (formerly /bin/ksh) syntax is acceptable to the Posix.2 shell. A script written for csh is not supported. The script should have a simple header similar to the example below.
Table 50 Control Script Keywords (continued) Keyword Type Size in Bytes Example postinstall path_string 1024 /mfg/sd/scripts/postinstall unpreinstall path_string 1024 /mfg/sd/scripts/unpreinstall unpostinstall path_string 1024 /mfg/sd/scripts/unpostinstall configure path_string 1024 /mfg/sd/scripts/configure unconfigure path_string 1024 /mfg/sd/scripts/unconfigure verify path_string 1024 /mfg/sd/scripts/verify checkremove path_string 1024 /mfg/sd/scripts/checkremove preremove
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.
• Defines the location of the product, which may have been changed from the default product directory (if the product is locatable). When installing to (or removing from) the primary root directory (“/”), this variable is the absolute path to the product directory. For operations on an alternate root directory, the variable must be prefixed by SW_ROOT_DIRECTORY to correctly reference product files.
/stand/system cannot be accomplished from within the postinstall scripts, but instead must be accomplished by the configure scripts. This occurs whenever software is installed to a directory other than root(/). • This variable should be read only by the configure and postinstall scripts of a kernel fileset. 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.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.
• If you are using a request script as part of the install, the checkinstall script should: ◦ Verify that the response file exists. ◦ Prevent swinstall from “hanging” if: – A script tries to read a response file that does not exist, or – The install or configuration relies on information in the missing response file. • If the checkinstall script fails, the fileset will not be installed. The interactive interface of swinstall will notify you that the checkinstall script has failed.
11.5.5 Configure Scripts • Configure scripts are executed during the Configuration phase of a swinstall session. SD expects configure scripts at system start-up if the swinstall session triggers a system reboot. The swconfig command can also execute configure scripts. The pathname of the script being executed is: $ {SW_CONTROL_DIRECTORY}configure • A configure script is only executed for installations into the primary root (“/”).
• A verify script is the primary way to check the configuration tasks performed by a configure script for correctness and completeness. • A verify script is executed for installations into the primary root (“/”) or an alternate root. Since most of the actions of this script will involve checking the current conditions of a configured product/fileset (in the primary root), it may not need to perform any actions for a product/fileset installed into an alternate root directory.
• 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 recommendation for response file format is the SVR4 model of attribute/value pairs. Answers should be written to the response file inenv_var=value format so that the response files can be easily used by other control scripts. • When you use a request script to get install information, HP recommends that you use a checkinstall script to check for proper execution of the request script. The checkinstall script should: ◦ Verify that the response file exists.
Any messages generated by the script will follow. If the script returns a value other than 0 (SUCCESS), then a concluding message such as the following, is written: ERROR: The "unconfigure" script for "PRODUCT.FILESET" failed (exit code "1"). The script location was "/var/adm/sw/products/PRODUCT/FILESET/unconfigure". * This script had errors but the execution of this product will still proceed. Check the above output from the script for further details. WARNING: The "unconfigure" script for "PRODUCT.
echo “ERROR: Cannot find bletch in /etc/bagel.” |&>2 fi • Follow these conventions to ensure a control script’s messages have a similar look and feel to the messages generated by the agent (and the commands themselves). ◦ Use full sentences wherever possible. Avoid terseness. ◦ Start sentences and phrases with capital letter and end with period. ◦ Put two blanks after period; one after colons, semicolons, and commas. ◦ Use uppercase first letters of phrases after colons.
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. 2. 3. 4. 5. 6. 7. 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.
3. 4. Run swinstall to install the full product again. Set the defer_configure option to “false” to avoid executing the configure scripts. • After the installation completes, run swconfig to configure your product. • Study the resulting file system to see if the configure script performed the expected actions. • Test the product itself to see if the necessary configuration tasks were performed such that the product is ready to use. • Now run swconfig -u to unconfigure your product.
3. 4. 5. 6. If your checkremove script can generate error or warning conditions based on the current activity or configuration of the target system, then enable those conditions to ensure that the checkremove script correctly detects them. Re-run the first test by installing into an alternate root directory (swinstall -r) instead of the primary root directory (“/”). Make sure that the scripts perform all of their operations (if any) within the alternate root directory.
-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 39). -f software_file Read a list of software selections from a separate file instead of (or in addition to) the command line. See “Software Files” (page 36). -S session_file Run the command based on values saved from a previous installation session, as defined in session_file. See “Session Files” (page 39).
11.11.1 swask Examples Run all request scripts from the default depot (/var/spool/sw) and write the response file (response) back to the same depot: swask -s /var/spool/sw \* Run the request script for Product1 from depot /tmp/sample.depot.1 on remote host swposix, create the catalog /tmp/test1.depot on the local controller machine, and place the response file (response) in the catalog: # swask -s swposix:/tmp/sample.depot.1 \ -c /tmp/test1.depot Product1 Run request scripts from remote depot /tmp/sample.
12 Nonprivileged SD This chapter provides general guidelines on how to set up Software Distributor to run in nonprivileged mode. Table 52 Chapter Topics Topics: “Overview” (page 231) “Setting Up Nonprivileged Mode” (page 232) “Default Configuration” (page 233) “Alternative Configuration” (page 233) 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.
or created by a non super-user when the run_as_superuser option is set to true and using ACL permissions). This limitation does not apply to tape or CD-ROM source depots. • swinstall and swcopy in nonprivileged mode can read any remote source depot as allowed by ACLs, can read local source depots created by the invoking user in nonprivileged mode, and (depending on the umask of other users) can read local source depots created by other users in nonprivileged mode. 12.
12.2.3 How Nonprivileged Mode Changes SD-UX Behavior When the run_as_superuser option is set to the default value of true, SD-UX operations are performed normally, with permissions for operations either granted to a local super-user or set by SD ACLs. (See Chapter 9: “SD-UX Security ” (page 145) for details on ACLs.
The default value is /var/adm/sw for normal operations. For nonprivileged mode (that is, when the run_as_superuser option is set to true): • The default value is forced to /var/home/LOGNAME/sw. • The path element LOGNAME is replaced with the name of the invoking user, which SD-UX reads from the system password file. • If you set the value of this option to HOME/path, SD-UX replaces HOME with the invoking user’s home directory (from the system password file) and resolves path relative to that 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 53 Chapter Topics Topics: “Changing Command Options” (page 235) “Options Listed Alphabetically” (page 236) A.1 Changing Command Options Changing the option values lets you change command behavior and tailor SD-UX policies to your needs.
See Also “Using Command Options” (page 37) for examples. A.2 Options Listed Alphabetically • admin_directory=/var/adm/sw (for normal mode) admin_directory=/var/home/LOGNAME/sw (for nonprivileged mode) The location for logfiles and the default parent directory for the installed software catalog. The default value is /var/adm/sw for normal operations.
• allow_downdate=false Normally set to false, so installing an older version of software than already exists is disallowed. This keeps you from installing older versions by mistake. Additionally, many software products do not support this “downdating.” If set to true, a previous version can be installed but SD-UX issues a warning message. Applies to swinstall. • allow_incompatible=false Normally set to false, only software compatible with the local host is allowed to be installed or configured.
• allow_split_patches=false Controls the ability to install or copy part of a patch. Use this option only to resolve critical problems with the assistance of your HP support representative. When set to the default value of false, installation or copy of a single fileset from a multi-fileset patch automatically includes other, “sibling” filesets that are appropriate, based on the target’s ancestor attributes.
If the auto_kernel_build option is set to true, this option must also be set to true. Applies to swinstall and swremove. • autorecover=false This option permits automatic recovery of original filesets if an installation error occurs. The cost is a temporary increase in disk space and slower performance. The default value of false causes swinstall to overwrite original files as a fileset is updated. If an error occurs during the installation (e.g.
• autoselect_minimum_dependencies=false Controls the automatic selection (marked for ask/config/copy/install/verify) of the first left-most dependency in a list of OR dependencies that satisfies a requisite, when another dependency in the list that also satisfies the requisite is explicitly selected by the user. This option is ignored when the autoselect_dependencies option is set to false.
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.
compress_cmd=/usr/contrib/bin/gzip uncompress_cmd=/usr/contrib/bin/gunzip compression_type=gzip Applies to swpackage and swagent. • config_cleanup_cmd=/usr/lbin/sw/config_clean Defines the script called by the agent to perform release-specific configure cleanup steps. Applies only to swagent. • control_files= When adding or deleting control file objects, this option lists the tags of those control files. There is no supplied default.
• customer_id= This number, printed on the Software Certificate, “unlocks” protected software and restricts installation to a specific site or owner. You can enter the number with the -x customer_id=option or by using the Interactive User Interface. See thecodeword option for more information. Applies to swinstall, swcopy, swlist. • defer_configure=false Controls the automatic running of configure scripts after swinstall software selections are installed.
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. A failure to build a kernel causes the install process to exit if in non-interactive mode, or to suspend if in an interactive mode. If set to false, a failure return from a kernel build process is ignored, and the install session proceeds. The currently running kernel remains in place.
• global_srp= This option is only supported in a HP-UX Containers (SRP) enabled system. This is used in conjunction with the local_srp_list option to install software on the system. For more information, see the syntax of the local_srp_list option. The behavior is as follows: nl nl ◦ If neither global_srp nor local_srp_list option is specified, swinstall will install on the global view and all system containers.
• job_title= When running large numbers of jobs, you may want to add more information to help you identify a specific job. Providing a value for this lets you add an ASCII string that will be displayed along with the ID and other job attributes when you invoke swjob or the job browser. Applies to swconfig, swcopy, swinstall, swremove, and swverify. • kernel_build_cmd=/usr/sbin/mk_kernel This is the script called by the agent for kernel building. Applies only to swagent.
◦ subproduct -- show all objects down to the subproduct level. ◦ fileset -- show all objects down to the fileset level. Also use -l fileset -l subproduct to show subproducts. ◦ file -- show all objects down to the file level (depots, products, filesets, and files). ◦ control_file -- show all objects down to the control_file level. ◦ category -- show all categories of available software objects. ◦ patch -- show all applied patches. (See also the show_superseded_patches option.
• local_srp_list= This option is only supported in a HP-UX Containers (SRP) enabled system. This option is used in conjunction with the global_srp option to install software inside each system container. The list contains space separated system container names enclosed in quotes and can be a subset of all configured system containers. The behavior is as follows: nl ◦ If neither global_srp nor local_srp_list options are specified, swinstall will install on the global view and all system containers.
• logfile=/var/adm/sw/.log This is the default controller log file for each command. The agent log files are always located relative to the target depot or target root: /var/spool/sw/swagent.log and /var/adm/ sw/swagent.log, respectively. Applies to all commands except swacl, swlist and swjob.
SD-UX uses the same format across multiple directory media as it does for multiple serial media, including calculations of the correct size based partitioning of filesets and setting of the media_sequence_number attributes. Applies only to swpackage. • media_type=directory Defines the type of distribution to create. The recognized types are directory and tape. Without this option, swpackage creates a distribution directory (depot) by default. Applies only to swpackage.
• 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.
This option can be is used in conjunction with the autoselect_patches and patch_match_target options to filter the selected patches to meet the criteria specified by software_specification. The default software_specification value is *.*. Note that patch filtering is overridden if you specify software with a command or if you use the \* wildcard to select software. If multiple targets are specified, the first target in the list is used as the basis for patch selections.
By default, the public key from the depot at /catalog/dfiles/ _PUBLIC_KEY is used. If the public key is not available in the depot, the key at /usr/lib/ sw/swsign/hp_public_key.pem is used. This option is applicable when either verify_signatures or verify_signatures_only option is set to true. • reboot_cmd=/sbin/reboot This is the command called by the agent to reboot the system. Applies to swagent.
robust check for equivalency than size and time stamp.If set to false, SD-UX does not compute checksums and compares files only by size and timestamp. Applies to swcopy, swinstall and swpackage. • remove_empty_depot=true When the last product or bundle in a depot is removed, the depot itself is removed. The depot's swagent.log file and directory structure are not removed by default. If the swagent.log file and directory should be removed, the remove_empty_depot_directory option must also be set to “true”.
For example, if an agent session failed to start and retry_rpc was set to 9 and retry_rpc_interval was set to {1 2 4 8 15} to allow long waits to handle transient network failures, the controller would attempt to recontact the agent after 1 minute for the first retry, then 2 minutes for the second retry, 4 for the third retry, then 8, then 15 for all additional retries until nine retries were attempted.
• rpc_binding_info_alt_source=ncadg_ip_udp:[2121] Defines the protocol sequence(s) and endpoint(s) used when the agent attempts to contact an alternate source depot specified by the alternate_source option. SD-UX supports both the udp(ncadg_ip_udp:[2121]) and tcp(ncacn_ip_tcp:[2121])protocol sequence/endpoint. Applies to swagent. • rpc_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.
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. • select_local=true Normally set to true, selects the default depot or installation directory of the local host as the target of the command.
When source_depot_audit is set to its default value of true, a swaudit.log file is created on the source depot (for writable directory depots) or in /var/tmp (for tar images, CD-ROMs, or other nonwritable depots). To view, print, or save the audit information, invoke the swlist interactive user interface by typing: swlist -i -d You can view audit information based on language preference, as long as the system has the corresponding SD-UX message catalog files on it.
• 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. • targets= There is no supplied default (see also select_local). If there is more than one target, they must be separated by spaces. Targets are usually specified in a target input file, as options on the command line or in the GUI.
Error and warning messages are always written to stderr. For the swlist command, a verbose listing includes all attributes that have been defined for the appropriate level of each software_selection operand. The attributes are listed one per line, prefaced by the attribute keyword. The -v option overrides this default, if it is set to 0. Applies to all commands.
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 55 Chapter Topics Topics: “Error Logging ” (page 261) “Common Problems ” (page 262) 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.
WARNING: A version of fileset "SD-DATABASE.SD-DATABASE2,r=9.00.1C" is already installed in another location (see previous lines). Installing this version will create multiple installed versions. This new multiple version will be installed because the "allow_multiple_versions" option is set to "true". B.1.3 Notes Notes are used to notify you of an event that is not erroneous, unexpected or undesirable, but that you should be aware of: NOTE: The fileset "SD-DATABASE.SD-DATABASE1,r=9.00.
it means SD-UX could not contact the daemon program on a specific target system. Note that this may occur even if you haven’t specified any targets, for example, if the daemon on your local host is not running. Resolution If the SD-UX daemon/agent is not installed on a given target system, you must install it before you can use SD-UX. If you’ve verified that the daemon/agent component has been installed on a target system and you still have trouble contacting it, check to see that the daemon is running: 1.
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.
B.2.3.2 Do Not Modify ACL Files Without swacl Since SD-UX stores ACLs in the file system as plain text files, you may try to edit them with a conventional editor. This can lead to unexpected corruption of the ACL. Most cases of this corruption simply result in a message indicating the corruption, but inserting additions to the ACL file without updating the num_entries value can result in unreported problems and cause SD-UX to deny access.
The greatest throughput improvements are seen when transfers are across a slow network (approximately 50kbyte/sec or less), and the source depot server is serving a few target hosts at a time. NOTE: This option should be set to true only when network bandwidth is clearly restricting total throughput.
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. On networks where even this minor data transfer is a problem, you can increase this polling interval, thus decreasing the frequency of polling, and reducing an interactive session’s overall demands on the network. See Appendix A (page 235) for more information on the polling_interval option. B.2.
If you inadvertently remove the daemon logfile while it is running, you must kill and restart the daemon if you want to see subsequent daemon log messages and free up the disk space used by the logfile. You can stop (kill) a daemon by typing: /usr/sbin/swagentd -k You can also kill and restart a currently running daemon by typing: /usr/sbin/swagentd -r B.2.
# Initializing... ERROR: Could not contact host "a". Make sure the hostname is correct and an absolute pathname is specified (beginning with "/"). Resolution Type stty to see if the [ or ] character is mapped to any other function on your system. If it is mapped to any other function, then remove or change the mapping, or use \[ and \]. B.
C Replacing or Updating SD-UX This appendix describes how to replace or update SD-UX using the install-sd command. Table 57 Chapter Topics Topics: “Re-installing SD-UX ” (page 271) “Replacing an Unusable Version of SD-UX” (page 272) “Installing a Newer Version of SD-UX” (page 272) 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.
For example: swtest:/var/spool/sw Command Notes • The command returns a value of 0 to indicate successful completion and a value of 1 to indicate an error. • An install-sd session writes messages for major tasks and the begin and end of each session. All WARNING and ERROR conditions are written to stderr. • Detailed events are logged to /var/adm/sw/install-sd.log Example install-sd -s swtest:/var/spool/sw C.
D Software Distributor Files and File System Structure This chapter contains information on key Software Distributor files. For additional information, refer to the following manual reference pages: sd(5) For most current information on Software Distributor files sd(4) For file layouts of all Software Distributor files. swpackage(4) For file layouts of Software Distributor files created during packaging.
Table 59 Agent Component (continued) /var/adm/sw/swagentd.log Daemon log file containing details on host and security operations /var/adm/sw/sw.log Controller logfile containing a summary of each job, where is one of these values: • install • remove • config • modify • package • reg • verify /var/adm/sw/tmp Directory for temporary files /var/home/USER_NAME Default location for admin_directory during nonprivileged mode $HOME/.swdefaults File containing user-specified default values.
The equivalent IPD files for a depot are called catalog files. When a depot is created or modified using swcopy, catalog files are built (by default in /var/spool/sw/catalog) that describe the depot and its contents. The IPD also contains a swlock file that manages simultaneous read and/or write access to software objects, and ACLs. For More Information • “Modifying the IPD (swmodify)” (page 74) D.
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. Administrative Host See local host. Agent The agent (swagent) runs on the local host. It services all selection, analysis, execution and status requests.
C Cache File A file that contains the name and attributes of targets selected by swinstall or swcopy. Catalog/Catalog directory An area within a depot that contains all the information needed by SD-UX to define the organization and contents of the products stored in the depot. It includes a global INDEX file and a directory of information for each product version in the depot. It is sometimes referred to as the catalog directory.
Controller The SD-UX programs or commands (swinstall, swcopy, etc.) that are invoked by the user on the local host and that direct the actions of an SD-UX agent. Copyright A keyword that defines the copyright attribute for the destination depot (media) being created/modified by swpackage. It refers to the copyright information for the software product. Corequisite A dependency in which a fileset requires that another fileset be installed or configured at the same time.
Disk Space Analysis (DSA) A process that determines if a host’s available disk space is sufficient for the selected products to be installed. Downdating Overwriting an installed version of software with an older version. DSA See Disk Space Analysis E End An optional keyword that ends the software object specification in a PSF. No value is required. Exrequisite A dependency in which a fileset requires the absence of another fileset before it can be installed or configured.
Instance_ID A product attribute in the Installed Products Database (IPD) that lets you uniquely identify products with the same tag (name) or revision. IPD See Installed Products Database. IPv6 address IPv6 address is the next generation network address format. It is a 128-bit address represented as eight fields of up to four hexadecimal digits. A colon (:) separates each field. An example of an IPv6 address is 3ffe:ffff:101::230:6eff:fe04:d9ff.
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.
Product Directory The root directory of a product object, in which most of its files are contained. You can change (relocate) the default product directory when you installing a locatable product. Product Specification File (PSF) An input file that defines the structure and attributes of the files to be packaged by swpackage. Product Version A depot can contain multiple versions of a product. Product versions have the same tag attribute, but different version attributes.
Secret In SD-UX security, a password used to verify the authenticity of the caller’s host. SD-UX manages sets of hosts by restricting and changing the default secret on all controller and target hosts in the network. See shared secrets file. Security Controlling access to software objects. In SD-UX, security is achieved by a combination of Access Control Lists (ACLs) associated with objects and commands, and the security inherent in the file system permissions on which the software is stored.
swagent The SD-UX agent program that makes changes to depots and roots. It is directed by the controller and scheduled by the daemon swagentd The SD-UX daemon that provides various services, including: initiation of communication between the controller and agent; serving one or more depots to multiple requesting agents on remote hosts. swask A SD-UX command that lets you run an interactive request script to get a response from the user.
TUI Terminal user interface. A character-based display with windows and pull-down menus that works on ASCII terminals. The TUI uses the keyboard to navigate (no mouse). See also Command Line User Interface and Graphical User Interface. TUI See Terminal User Interface. 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).
Index Symbols $HOME/.
attributes definition, 63 listing, 250 sample, 73 audience for this guide, 13 authorization, depot, 96 authorization, RPC, 164 auto_kernel_build, 238 automatic recovery, 239 automatic scrolling, 45, 81, 90 autoreboot, 238 autorecover, 50, 239 autorecover_product, 239 autorecover_product= default, 50 autoremove_job, 117, 239 autoselect_dependencies, 239 autoselect_dependencies=true option, 22 autoselect_dependents, 239 autoselect_minimum_dependencies, 240 autoselect_patches, 240 autoselect_reference_bundles,
copy dialog, 92 copying software depots, 87 icon in Job Browser, 107 Job Browser, 114 corequisite, 23, 188 definition, 23 CORRUPT state, 54 cpio tape format, 197 create_target_acls, 201, 242, 265 create_target_path, 242 create_time_filter option, 242 creating a job, 110 creating jobs, 114 creation time, 252 credentials, 162 crwit, 156 custom lists, 69 customer identification number, 243 customer IDs, using, 51, 70, 95 customer_id, 243 customer_id, using, 51, 70, 95 customer_ids, 23 D daemon, 20 restarting,
/var/tmp, 271 directory depot, 86 directory mapping, 191 directory structures, 171 disk space analysis, 267 analysis by swpackage, 196 analysis dialog, 45 button, 45, 46, 90, 91 failure, 46, 91 space files, 210 specifying requirements, 210 diskless clusters, 17 distribution depot specification, 181 distribution directory, 243 distribution tape, 249 distribution tape format, 197 distribution tape, creating a, 198 distribution_source_directory, 243 distribution_target_directory, 243 distribution_target_serial
fixed width, 34 variable width, 34 G global_product_template, 148, 152, 159 global_soc_template, 148, 159 go up, 31 Graphical User Interface (GUI), 19, 23, 42, 79, 87 swlist, 63, 132 group access, 162 ACL, 155 GUI will not start, 263 GUI and TUI swlist, 63 H help f1 key, 33 menu, 33 on-line, 33 host definition, 19 re-using in Job Browser, 114 host ACL, 160 permissions, 157 hosts keyword, 122 HP-UX SD Controller definition, 119 I images, depot, 265 include file, 194 include_file_revisions, 245 input files
preremove script, details, 220 unconfigure script, details, 219 values, control scripts, 211 verify script, details, 219, 220 L LANG environment variable, 213 language environment variables, 213, 214 layout_version, 246 LC_ALL environment variable, 214 level designation, swlist, 65, 70 of detail, swlist, 63 level=, 246 level= default, 69, 70 list as input to other commands, 63 depot, 72 simple, 67 verbose, 72 listing interactive swlist, 63, 132 registered depots, 100 software, 63 UNIX depot contents, 100 l
and defaults, swremove, 83 changing, 37, 235 compress_index, 241 create_time_filter, 242 editor, 29 job-related, 116 menu, 29 precedence, 235 preserve_create_time, 252 OS update, 245, 254 os_name, 251 os_release, 251 overview, commands, 19 P package_in_place, 251 packaging ACLs, 201 CD-ROM, 201 failures, 267 for nonprivileged SD, 232 making tapes, 206 overview, 171, 195 registering depots, 200 remote file systems, 204 repackaging, 203 security, 201 writing to tapes, 205 packaging command, 195 Packaging Spe
read permission, 96 README, 69 ready, 46, 91 with errors, 46, 91 with warnings, 46, 91 realm, 162 reboot, system, 51 reboot_cmd, 253 reconfigure, 253 reconfigure=true/false option, 54 recopy, 253 recovering updated files, 50 recovery, 142 referenced bundle, 240 refresh interval, Job Browser, 109 register_new_depot, 253 register_new_root, 253 registering depots, 95 reinstall, 253 reinstall option, 95, 139 reinstall_files, 139, 253 reinstall_files_use_cksum, 139, 253 reinstalling SD, 271 reliability, 137 remo
for developers, 166 in "push" installations, 166 packaging, 201 pull distribution, 166 UNIX, 161 security checks configuration, 168 copying, 167 installing, 168 Job Browser, 167 listing, 167 packaging, 167 registering depots, 168 removal, 168 verifying, 168 security tasks, 148 select_local, 257 selecting software to copy, 89 selecting software to remove, 79 server, definition, 19 session file, example, 39 files, 39 session file option, -S, 47, 56, 60, 66, 75, 82, 92, 96, 115, 198, 227 setuid root, 202 share
swagentd, 20, 119 overview, 17 swask, 169, 227 examples, 229 syntax, 227 swconfig command, 53 security checks, 168 swcopy dependencies, 87 GUI overview, 87 overview, 17 security checks, 167 swgettools, 271 swinstall disk space analysis, 210 overview, 17 security checks, 168 swjob, 134 command information, 114 security checks, 167 swlist -a (attribute) option, 65 -d option, 65 -i option, 63, 65 -i option for remote operations, 132 -l depot option, 100 -l option, 65, 70 -R (shorthand) option, 65 -v (verbose)
target_directory, 259 target_tape, 259 target_type, 198, 259 targets option, 259 task specific permissions, 167 TCP/IP protocol, 266 template ACL, 159 default entries, 160 Terminal User Interface (TUI), 19, 23, 42, 79, 87 terminate write-to-tape command, 205 testing configuration scripts, 225 installation scripts, 225 removal scripts, 226 timeout, 256 connection, 266 options, 138 resolving problems, 266 too-restrictive permissions, 201 Trojan Horse, 165 troubleshooting SD, 261 tutorial prerequisites, 124 U
