Compaq TRU64 User Manual
Tru64 UNIX
Sharing Software on a Local Area Network
Part Number: AA-RH9DC-TE
June 2001
Product Version: Tru64 UNIX Version 5.1A
This manual describes Remote Installation Services (RIS) and Dataless
Management Services (DMS) in CompaqTru64 UNIX. RIS is used to
install software kits across a network instead of using locally mounted
distribution media. DMS lets client systems share the /usr file system
on a networked server while maintaining their own root (/) and /var file
systems on a DMS server.
Compaq Computer Corporation
Houston, Texas
© 2001 Compaq Computer Corporation
COMPAQ, the Compaq logo, and TruCluster Registered in the U.S. Patent and Trademark Office. Tru64 is
a trademark of Compaq Information Technologies Group, L.P.
UNIX is a trademark of The Open Group. All other product names mentioned herein may be trademarks
of their respective companies.
Confidential computer software. Valid license from Compaq 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.
Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information
in this document is provided “as is” without warranty of any kind and is subject to change without
notice. The warranties for Compaq products are set forth in the express limited warranty statements
accompanying such products. Nothing herein should be construed as constituting an additional warranty.
About This Manual
1 Introduction to Sharing Software
1.1
1.2
1.3
Overview .. .............................................................
Understanding the Software Sharing Environment ........... . 1–2
Identifying a CD-ROM Drive Device Name ....................... 1–3
2 Remote Installation Services
2.1
2.2
2.3
2.4
2.5
2.6
Overview .. .............................................................
Starting RIS ...........................................................
RIS Areas and Product Environments ............................ 2–3
RIS Client Characteristics . . . . . ...................................... 2–4
Registering Clients ...................................................
Identifying a Client Hardware Network Address ................ 2–5
3 Preparing the RIS Server
3.1
3.2
3.3
3.4
3.5
3.6
Reviewing RIS Server/Client Version Compatibility .. . . . . ...... 3–1
Planning Disk Space for RIS . . ...................................... 3–3
Installing the Operating System on the RIS Server . ........... . 3–3
Setting Up a Local Area Network . . ................................ 3–4
Loading and Registering the Server Extensions License . . . . ... 3–4
Preparing RIS for C2 Security ..... . . . . . ............................ 3–5
Contents
1–1
2–1
2–3
2–5
4 Setting Up a RIS Area
4.1
4.2
4.3
4.4
4.5
4.6
Overview .. ............................................................. 4–1
Installing Software into a New RIS Area ..... . ................... 4–1
Installing Software into an Existing RIS Area ................... 4–5
Including Hardware Product Kits into a RIS Area . . ........... . 4–7
Using a RIS Area Mounted on NFS .. . . ............................ 4–10
Modifying the /etc/exports File ...................................... 4–10
Contents iii
5 Booting a RIS Client
5.1
5.1.1
5.1.2
5.1.3
5.1.4
5.2
Remote Boot Files and Daemons .. . . . . . ............................
The Internet Daemon and Configuration File ............... 5–2
The BOOTP Daemon ............................................
The /etc/bootptab File ............................................
The tftpd Daemon .. . .............................................
Remote Boot Process Flow . . ........... . . ............................ 5–4
6 Managing RIS Clients and Environments
6.1
6.1.1
6.1.2
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
Preregistration Tasks . . . .............................................
Obtaining Information About Each Client ................... 6–1
Registering Client Host Names and IP Addresses ...... . . . . 6–2
Adding a RIS Client with the ris Utility . ..... . ................... 6–2
Adding a RIS Client from the Command Line ................... 6–7
Modifying RIS Clients ................................................
Removing RIS Clients . . . . ............................................
Listing Registered RIS Clients . . . . . ................................ 6–10
Listing Products in RIS Server Areas ............................. 6–11
Deleting Products from RIS Server Areas ....... ................. 6–12
Correcting RIS Gateways File Entries ............................ 6–13
7 Managing RIS Profile Sets
7.1
7.2
7.3
7.4
7.5
7.6
7.7
Overview . . .. . ..........................................................
Creating Profile Sets . ................................................ 7–2
Registering Clients for Profile Sets ................................ 7–3
Converting Old Configuration Description Files ................. 7–5
Determining RIS Client Profile Set Registration . ............... 7–6
Removing RIS Client Profile Set Registration . . . ................ 7–6
Deleting Profile Sets from the RIS Server . . . . . ................... 7–6
5–1
5–2
5–2
5–4
6–1
6–7
6–9
7–1
8 Troubleshooting RIS
8.1
8.2
8.3
8.4
8.4.1
8.4.2
8.4.3
iv Contents
RIS Lock Files ......................................................... 8–1
Client Password Expiration ........ . . . . . ............................ 8–2
Root File System Mounting ........... . . ............................ 8–2
RIS Client Registration .............................................. 8–2
No Prompt for Client Hardware Address . . . . . . ............... 8–3
Duplicate Client Hardware Addresses . . ...................... 8–3
Cloned Client Registration . . ..... .............................. 8–4
8.4.4
8.4.5
8.5
8.5.1
8.5.2
8.5.3
Client Registered on Multiple RIS Servers .................. 8–4
Client Not in RIS Database ...... . . ............................
RIS Server Response .................................................
Servers Using the bootpd Daemon ............................
Servers Using the joind Daemon ..............................
Loading an Incorrect Kernel File . . ............................
9 Dataless Management Services
9.1
9.2
9.3
9.3.1
9.3.2
9.3.3
9.3.4
Overview . . .. . ..........................................................
DMS Benefits ..........................................................
Relationship Between DMS Servers and Clients ................ 9–2
DMS Server ......... . . ............................................
Environment Portion of DMS Area ............................ 9–3
Client Portion of DMS Area .................................... 9–5
Characteristics of DMS Clients . . . ............................. 9–5
10 Preparing DMS Servers and Clients
10.1
10.2
10.3
10.4
10.5
10.6
10.6.1
10.6.2
10.6.3
10.7
10.8
10.8.1
10.8.2
10.9
Requirements for DMS Servers ....... .............................. 10–1
Requirements for DMS Clients ....... . . ............................ 10–2
Allocating Disk Partitions on the DMS Server ................... 10–3
Setting Up a Local Area Network (LAN) .. . . .. . ................... 10–3
Setting Up a Network File System . . . . ............................. 10–3
Planning Disk Space for DMS . . . ................................... 10–4
Disk Space Required for DMS Environments ............... 10–4
Estimating Disk Space for Clients ............................ 10–6
Considering Types of Kernel Builds . . . . . . . . ................... 10–6
Installing the Operating System on the DMS Server . . . . . ...... 10–7
Registering DMS Clients ............................................ 10–7
Obtaining DMS Client Information . . . . . . . . ................... 10–8
Registering Clients Host Names and IP Addresses . . . ...... 10–8
Considering Security Issues ........... . . ............................ 10–9
8–5
8–6
8–6
8–8
8–9
9–1
9–2
9–2
11 Setting Up a DMS Environment
11.1
11.2
11.3
11.4
11.4.1
11.4.2
11.5
Ensuring DMS Server and Client Compatibility . ............... 11–1
Installing Software in a New DMS Environment ................ 11–2
Adding Software to an Existing DMS Environment . ........... . 11–6
Configuring DMS Environments . . . ................................ 11–9
Customizing /etc/.proto..* Files . . . ............................. 11–9
Configuring the DMS Environment .... . . . . . . . ................ 11–11
Installing WLS Support in DMS .. ................................. 11–12
Contents v
11.5.1
11.5.2
11.5.3
Setting Up a DMS Server for WLS ............................
Setting Up a DMS Client for WLS ............................
Building an Asian Kernel for DMS Clients . . . ............... 11–13
12 Managing DMS Clients and Environments
12.1
12.2
12.3
12.4
12.5
12.6
12.7
12.8
12.9
12.9.1
12.9.2
12.9.3
DMS Client Database File . . ........... . . ............................ 12–1
Adding a DMS Client . ................................................
Booting a DMS Client ................................................
Deleting a Software Environment .. ................................ 12–7
Modifying Client Information . ...................................... 12–9
Removing a Client ....................................................
Listing DMS Clients ..................................................
Showing Software Environments . . ................................ 12–13
Maintaining the DMS Environment . . ............................. 12–14
Controlling Root File System Growth .. . ...................... 12–14
Listing Installed Software Subsets ............................ 12–14
Removing Subsets . . . .............................................
13 Troubleshooting DMS
13.1
13.2
13.3
13.4
13.5
13.6
13.7
Removing DMS Lock Files . . . . ...................................... 13–1
Checking NFS Server Status ... . . . . .. . ............................. 13–2
Checking Network Daemon Status ................................ 13–2
Checking Directory Exports .. . ... ................................... 13–2
Checking Version Compatibility . ... ................................ 13–3
Correcting Swap Device Problems . ................................ 13–3
Reconfiguring for a Hardware Update Release .................. 13–4
11–12
11–13
12–2
12–6
12–11
12–12
12–15
A RIS Worksheet
B DMS Worksheets
C Using the utilupdate Utility
D Hardware Update Releases in DMS
D.1 Overview . . .. . .......................................................... D–1
D.2 Installing a Hardware Release into a DMS Area . ............... D–2
vi Contents
Glossary
Index
Examples
5–1
6–1
7–1
8–1
Figures
2–1
2–2
9–1
9–2
9–3
9–4
Tables
5–1
10–1
11–1
Sample /etc/bootptab File ............................................
Sample /var/adm/ris/gateways File .. . ............................. 6–14
Sample RIS Client Profile Set Registration . . . . . . ................ 7–3
Sample daemon.log File . . ............................................
RIS Server and Client .. . . ............................................
Sample RIS Area Overview ........... . . ............................ 2–4
File Sharing Between the DMS Server and Client . ......... . . . . 9–3
Environment Portion of DMS Area . . . ............................. 9–4
DMS Client Area ........ . . ............................................
Client Views of the DMS Area . . . ................................... 9–6
Remote Boot Files and Daemons . . . ................................ 5–1
Estimated Subset Sizes for DMS ..... . . ............................ 10–5
List of /etc/.proto.* Files .............................................
5–3
8–7
2–2
9–5
11–10
Contents vii
About This Manual
This manual describes the Remote Installation Services (RIS) and Dataless
Management Services (DMS) environments and utilities maintained on a
Compaq Tru64™ UNIX operating system.
• RIS lets you install software kits across a network from a centrally
administered server instead of using locally mounted media.
• DMS lets client systems share the
administered server over a network while still maintaining their own
root ( / ) and /var file systems that reside on the DMS server.
Audience
This manual is intended for anyone using RIS or DMS, especially
those system administrators responsible for maintaining RIS and DMS
environments on your LAN.
When you are using this manual, the following conditions apply:
• Your hardware is working properly.
• You have read the owner’s manuals supplied with your hardware.
• You know the location and function of the controls and indicators on
your hardware.
• You understand how to load and unload the installation media and any
disks needed during the installation.
• You know how to use the operating system software.
New and Changed Features
The following changes have been made since the Version 5.1 Release:
• Added information about rolling upgrade from a RIS server (Section 2.5)
/usr file system on a centrally
• Added information concerning cluster environments when adding a RIS
client (Section 6.2)
• Added information concerning cluster environments when modifying
a RIS client (Section 6.4)
• Added a troubleshooting procedure to address insufficient memory and
swap volume problems when booting a DMS client in multi user mode
(Section 13.6)
About This Manual ix
The Tru64 UNIX documentation is available on the World Wide Web at the
following URL:
http://www.tru64unix.compaq.com/docs/
Organization
This manual is organized as follows:
Chapter 1 Introduces the concept of servers and clients, explaining
Chapter 2 Describes the relationship between the RIS
Chapter 3
Chapter 4 Describes the procedure for setting up a RIS server,
Chapter 5 Describes networking-related files and daemons used
Chapter 6
Chapter 7 Describes how to manage profile sets to support Full
Chapter 8 Provides information on troubleshooting RIS
Chapter 9
Chapter 10 Describes how to prepare a server system for DMS.
Chapter 11 Describes the steps necessary to configure a DMS server
Chapter 12
Chapter 13 Provides information on troubleshooting DMS
Appendix A Contains a worksheet to use when you install RIS.
Appendix B Contains worksheets to calculate space require-
what they are and how they work together. It also describes
the basic architecture of the server/client environment.
server and RIS clients.
Lists the formats in which distribution media are available
and describes the preliminary setup procedures for RIS.
including installing and updating software.
by the remote installation services (
process a client goes through to boot over the network.
Describes processes and procedures for maintaining
and managing a RIS system, including adding,
deleting, and modifying clients.
Installation and Installation Cloning.
client problems.
Introduces DMS and the dataless management utility (dmu).
including how to install software into a DMS environment.
Describes how to use the dmu utility to add, modify,
remove, and list DMS clients, and how to list or
delete a DMS environment.
client problems.
ments on DMS servers and clients, and a DMS
client setup worksheet.
ris) utility and the
x About This Manual
Appendix C
Appendix D Describes how to install a hardware update release into a
Describes the utilupdate utility, used to update the
the ris and dmu utilities on a server that is running
an older version of the operating system.
DMS area serving an older version of the operating system.
Related Documentation
You should have the following documentation available:
• The hardware documentation for your system
• Release Notes
• Reference Pages Sections 8 and 1m
• System Administration
• Installation Guide
• Installation Guide — Advanced Topics
• Documentation Overview
The Tru64 UNIX documentation is available on the World Wide Web at the
following URL:
http://www.tru64unix.compaq.com/docs/
Icons on Tru64 UNIX Printed Manuals
The printed version of the Tru64 UNIX documentation uses letter icons on
the spines of the manuals to help specific audiences quickly find the manuals
that meet their needs. (You can order the printed documentation from
Compaq.) The following list describes this convention:
G Manuals for general users
S Manuals for system and network administrators
P Manuals for programmers
R Manuals for reference page users
Some manuals in the documentation help meet the needs of several
audiences. For example, the information in some system manuals is also
used by programmers. Keep this in mind when searching for information
on specific topics.
The Documentation Overview provides information on all of the manuals in
the Tru64 UNIX documentation set.
About This Manual xi
Reader’s Comments
Compaq welcomes any comments and suggestions you have on this and
other Tru64 UNIX manuals.
You can send your comments in the following ways:
• Fax: 603-884-0120 Attn: UBPG Publications, ZKO3-3/Y32
• Internet electronic mail:
A Reader’s Comment form is located on your system in the following
location:
/usr/doc/readers_comment.txt
Please include the following information along with your comments:
• The full title of the manual and the order number. (The order number
appears on the title page of printed and PDF versions of a manual.)
• The section numbers and page numbers of the information on which
you are commenting.
• The version of Tru64 UNIX that you are using.
• If known, the type of processor that is running the Tru64 UNIX software.
The Tru64 UNIX Publications group cannot respond to system problems
or technical support inquiries. Please address technical questions to your
local system vendor or to the appropriate Compaq technical support office.
Information provided with the software media explains how to send problem
reports to Compaq.
readers_comment@zk3.dec.com
xii About This Manual
Conventions
The following conventions are used in this manual:
%
$
A percent sign represents the C shell system prompt.
A dollar sign represents the system prompt for the
Bourne, Korn, and POSIX shells.
#
% cat
file
[|]
{ | } In syntax definitions, brackets indicate items that
cat
(1)
Return In an example, a key name enclosed in a box
A number sign represents the superuser prompt.
Boldface type in interactive examples indicates
typed user input.
Italic (slanted) type indicates variable values,
placeholders, and function argument names.
are optional and braces indicate items that are
required. Vertical bars separating items inside
brackets or braces indicate that you choose one item
from among those listed.
A cross-reference to a reference page includes
the appropriate section number in parentheses.
For example, cat
information on the cat command in Section 1 of
the reference pages.
indicates that you press that key.
(1) indicates that you can find
Ctrl/x This symbol indicates that you hold down the
first named key while pressing the key or mouse
button that follows the slash. In examples, this
key combination is enclosed in a box (for example,
Ctrl/C ).
About This Manual xiii
This chapter introduces software sharing and the components that make up
a software sharing environment. This chapter includes the following topics:
• Software sharing concepts, components, and benefits (Section 1.1)
• Describing the software sharing environment (Section 1.2)
• Identifying your CD-ROM drive’s device name (Section 1.3)
1.1 Overview
A server is a computer system that provides another computer system with
required or useful information or resources. The system that uses the
information or resources from the server is called a client. A given server
can serve one or many clients. Computers in a network can share disk space,
lists of names, software kits, processing services, and other entities.
For sharing software using Remote Installation Services (RIS) and Dataless
Management Services (DMS), the server supplies software, software kits,
and disk space for clients to use.
1
Introduction to Sharing Software
The RIS and DMS services let you share software in the following ways:
• RIS sets up a system where one or more installable software kits are
stored for installation across a local area network (LAN). With RIS, one
computer, the RIS server, stores the kit in a special area (called the RIS
area) on its disk. Other computers, called RIS clients, can install the
software onto their own disks by accessing it across the network instead
of from locally mounted distribution media (such as CD-ROM).
• DMS sets up a system where you can save disk space by sharing the
actual operating system software between computers. Without DMS,
each computer has a copy of its operating system software on its own
disk. With DMS, one computer, acting as a DMS server, stores the
software in a special area (called the DMS area) on its disk. Other
computers, called DMS clients, run by accessing the software across the
local area network (LAN) instead of from their local disks.
_____________________ Note _____________________
DMS is not supported in a clusters environment.
Introduction to Sharing Software 1–1
The RIS and DMS utilities share architectural similarities; the primary
differences are in the contents of their respective server disk areas.
The following list illustrates some of the benefits of sharing software:
• You can reduce your software and hardware costs by sharing software
between computers.
• You are not limited to sharing one piece of software; you can share
virtually all of your operating system software.
• When you share software with RIS, you have a central location for all
the software to install on your system and can install the same software
simultaneously on several clients.
• When you share software with DMS, several of the computers in your
local area network (LAN) use a single copy of a given piece of software.
This reduces the need for multiple copies of the same software, reduces
the disk space required for software storage, and allows central
administration of software resources.
1.2 Understanding the Software Sharing Environment
The following components make up the environment for software sharing:
A server
The server’s system administrator prepares the server for RIS or DMS
by creating the RIS or DMS areas on the server and ensuring that
the server is connected to a LAN. A single server can serve both RIS
and DMS clients, however a client cannot be registered to both RIS
and DMS.
A distribution device on the server
For most servers, the distribution device is a CD−ROM drive or a
software distribution copied directly to magnetic disk. You transfer
or link the software subsets for one or more specific products and
architectures from the distribution media to the RIS or DMS areas on
the server. Registered clients can then access the software.
A local area network (LAN)
You must set up the server and all client processors as hosts on the LAN
(using Ethernet, FDDI, or Token Ring for RIS and Ethernet or FDDI for
DMS). Clients use the LAN to access the server’s RIS and DMS areas.
Clients
RIS clients are systems that can run the operating system for which the
server provides kits. RIS clients also must be capable of booting over
1–2 Introduction to Sharing Software
Ethernet or FDDI using the BOOTP and TFTP protocols to install the
base operating system from a server. Layered products can be installed
after the client’s operating system is running with the SysMan Menu.
DMS clients must be capable of booting over Ethernet or FDDI
using the BOOTP and TFTP protocols. Most Alpha workstations and
servers have this capability, but some data center servers cannot be
configured as DMS clients. See your system’s user guide and related
documentation to determine whether it supports BOOTP and TFTP over
Ethernet or FDDI.
____________________ Note ____________________
You cannot use RIS or DMS to install software on DEC 2000
series or DEC 7000 series servers.
1.3 Identifying a CD-ROM Drive Device Name
There are many circumstances when you need to specify your CD-ROM
drive’s device name and you do not know the unit number of the CD-ROM
drive. How you identify this unit number depends on whether your system
is running a version of the operating system that uses traditional device
naming conventions or newer device naming conventions.
Use one of the following procedures to determine your CD-ROM drive’s unit
number:
• If you are using an older version of the operating system that uses
traditional device naming conventions (/dev/rrzNc), use the file
command, specifying the raw device, as shown in the following example:
# file /dev/rrz*c
/dev/rrz1c: char special (8/1026) SCSI #0 RZ25 disk #8 (SCSI ID #1)
/dev/rrz2c: char special (8/2050) SCSI #0 RZ25 disk #16 (SCSI ID #2)
/dev/rrz3c: char special (8/3074) SCSI #0 RZ25 disk #24 (SCSI ID #3)
/dev/rrz4c: char special (8/4098) SCSI #0 RRD43 disk #32 (SCSI ID #4)
/dev/rrz9c: char special (8/17410) SCSI #1 RZ57 disk #72 (SCSI ID #1)
#
In the previous example, the CD-ROM device corresponds to the RRD
device RRD43, and the CD-ROM drive’s unit number is 4. The raw
device name is /dev/rrz4c.
To mount the device, insert the CD-ROM into the drive and use a
mount command, specifying the character special device, similar to the
following:
# mount -rd /dev/rz4c /mnt
The previous example uses a CD−ROM drive that is unit 4 and specifies
/mnt as the mount point.
Introduction to Sharing Software 1–3
• If you are using a later version of the operating system that uses newer
device naming conventions (/dev/disk/cdromNc), use the ls command
as shown in the following example:
# ls -l /dev/disk/cdrom*
brw------- 1 root system 19, 69 Nov 18 06:11 /dev/disk/cdrom0a
brw------- 1 root system 19, 71 Nov 18 06:11 /dev/disk/cdrom0c
#
The CD-ROM drive’s unit number is 0, and in the character special
device name in this example is /dev/disk/cdrom0c. Raw devices have
the same name but reside in the /dev/rdisk directory.
To mount the device, insert the CD-ROM into the drive and use a mount
command similar to the following:
# mount -rd /dev/disk/cdrom0c /mnt
This example uses a CD−ROM drive that is unit 0 and specifies /mnt
as the mount point.
• If you have multiple CD-ROM drives and are not sure which drive
corresponds to which device name, use the hwmgr command to flash
the light on the drive.
For example, if you want to determine which CD-ROM drive corresponds
to /dev/disk/cdrom0c and you have two CD-ROM drives, place
CD-ROMs in both drives and enter the following command:
# hwmgr -flash light -dsf /dev/disk/cdrom0c
You see the light on cdrom0c blink for 30 seconds.
See hwmgr
1–4 Introduction to Sharing Software
(8) for more information.
This chapter introduces Remote Installation Services (RIS) and the ris
utility, and explains the relationship between RIS servers and clients. The
following topics are included:
• Understanding RIS concepts and the benefits of using RIS (Section 2.1)
• Starting RIS (Section 2.2)
• Introducing RIS areas and product environments (Section 2.3)
• Understanding RIS client characteristics (Section 2.4)
• Registering RIS clients (Section 2.5)
• Identifying a client’s hardware network address (Section 2.6)
2.1 Overview
Remote Installation Services (RIS) uses the ris utility to set up a central
computer system (a server) to service multiple computer systems (clients) on
a local area network (a LAN) with required software.
2
Remote Installation Services
With RIS, the server has a disk area set aside as the RIS area. The RIS
area contains copies of software kits that are available for installation on to
registered clients. Figure 2–1 shows how the RIS system works.
Remote Installation Services 2–1
Figure 2–1: RIS Server and Client
Local Area Network
Server Client
RIS
Area
Kits
Local
Disk
Local
Disk
ZK-0268U-AI
The server maintains information in the RIS areas about what software
kits clients can access. Kits are organized so that RIS can serve different
versions of a software product to multiple hardware platforms and operating
systems. The server’s RIS area uses the Network File System (NFS) to
provide read-only access to RIS clients.
Beyond verifying RIS clients’ identities and managing their kit load
requests, the RIS server does not interact directly with the clients. You do
not have to set aside a system as a dedicated RIS server; you can use the
same system to support local timesharing users.
A RIS client uses the setld utility to install software kits from the RIS
server instead of from local distribution media.
The benefits and advantages of RIS include the following:
• Installation and setup of servers and clients are done by scripts, thereby
simplifying the server system administrator’s task. Maintenance of the
server’s disk areas is similarly straightforward. The system interface is
the same regardless of system type.
• Because RIS supports different hardware platforms and different
software versions, it is adaptable to a wide variety of client systems
and requirements. Servers running a given version of an operating
system can serve clients running the same version or an earlier version
of the operating system. In addition, if the ris utility on the server is
updated to the current version with the utilupdate utility available
on distribution media, RIS servers running an earlier version of the
operating system can make later versions of the operating system
available to RIS clients.
2–2 Remote Installation Services
• RIS uses a single set of kit files for all clients having the same
architecture.
• You can perform a cloned installation on a RIS client, letting you
duplicate a similar system installation or configuration. See the
Installation Guide — Advanced Topics for information about installation
cloning and configuration cloning.
2.2 Starting RIS
You always should run the ris utility as superuser. To start the ris utility,
enter the following command:
# /usr/sbin/ris
When RIS starts up, it checks the status of the RIS areas.
If RIS can access all the products it was able to access the last time RIS was
started, the ris utility displays the following message:
Checking accessibility of RIS areas... done
If RIS cannot access all the products it was able to access previously, it
displays the following message:
No Products Available in /var/adm/ris/ris0.alpha
Delete RIS environment? [y]:
This may occur because the source for this RIS environment is no longer
mounted, and can be corrected by remounting the source. If the source is no
longer available, you may delete this RIS environment. If you remount the
source, you must restart RIS so that the environment is available.
If you try to start RIS without superuser privileges, the following message
may be displayed:
Checking accessibility of RIS areas...
No permission to write /usr/var/adm/ris/ris0.alpha/ProdNames
done
Correct this problem by logging in as root or using the su command to gain
superuser privileges before you start RIS.
2.3 RIS Areas and Product Environments
In addition to the server’s normal disk area, an area is reserved to hold RIS
software kits. This RIS area contains one or more product environments.
Each product environment contains one or more product kits suitable for
installation on a given hardware or software platform. Figure 2–2 shows a
generalized illustration of a sample RIS area.
Remote Installation Services 2–3
Figure 2–2: Sample RIS Area Overview
/var/adm/ris
ris0.alpha
product_001 product_002
subsets
subsets
kit/isl
Client Installation
Tools
ZK-0620U-AI
In Figure 2–2, the RIS area /var/adm/ris contains one product
environment, ris0.alpha. Each product environment contains products
for a specific platform. In Figure 2–2, the target platform is machines using
Alpha processors. Multiple product environments can exist in a single RIS
area. Each product environment contains one or more product directories,
each product directory contains several product kit archives, called software
subsets. Figure 2–2 shows a product environment named ris0.alpha
containing directories called product_001 and product_002.
Figure 2–2 also shows the kit/isl directory. The kit/isl directory
contains installation tools required by clients when they install software
over the network. If your environment is in Direct CD-ROM (DCD) format,
the kit/isl directory does not exist. An environment in DCD format is the
same as a system disk format, it includes root, /usr, and so on.
The server itself usually does not use any of the RIS areas. System
administrators can access the product area as required for maintenance and
for installation or removal of product kits.
For more flexibility, you can establish multiple RIS areas in separate
partitions. RIS areas on a given server can be exported to other servers
using the Network File System (NFS). Servers that import such RIS areas
can use them as if they were local, supplying the imported subsets to their
own set of clients. Section 4.5 describes how to use NFS to mount a RIS area.
The Network Administration: Services manual describes how to export and
import file systems.
2.4 RIS Client Characteristics
A RIS installation uses the LAN as its installation media instead of a
distribution CD−ROM. A RIS client can install any software kit for which
2–4 Remote Installation Services
it is registered on the server. The installation procedure runs entirely
on the client and, after the necessary software is installed, no continuing
relationship is required between the RIS server and client.
The operating system itself can be among the kits that are available from the
server. To install the operating system, the client processor is booted across
the network using a minimal generic kernel that is part of the software
kit. The RIS area is NFS mounted and becomes the client’s root file system
during the installation.
When the client is booted, either the text-based or graphical installation
interface is launched. After all installation responses are entered, the
installation software configures the file system, and then uses the setld
utility to load the software you selected. See setld
After the installation is complete, the system reboots with the newly
installed software. For information on installation procedures, see the
Installation Guide.
2.5 Registering Clients
A client must be registered with only one server for the base operating
system. If you register a client with more than one server for the base
operating system, each server the client is registered on will attempt to
respond to the client’s network boot request with unpredictable results.
(8) for more information.
To change the server with which a client is registered for the base operating
system, first remove the client from the current server’s client database and
then register it with the new server. See Chapter 6 for information about
registering and removing RIS clients.
A client can be registered with multiple servers for optional subsets and
products other than the base operating system. When you load optional
subsets or layered products with the SysMan Menu, you specify the name
of the server from which you will copy the kits.
If you are performing a rolling upgrade from a RIS server, you must register
both the cluster alias and the lead cluster member as RIS clients before you
execute the installation phase of the rolling upgrade. For information on
rolling upgrade procedures, see the TruCluster Server Cluster Installation
manual and the Installation Guide.
2.6 Identifying a Client Hardware Network Address
You need to know your client’s hardware network address when you are
registering a client to a RIS server. There are several ways to identify this
information:
Remote Installation Services 2–5
• Log in to the RIS client as root or use the su command to gain superuser
privileges, then shut down the system to the console prompt ( >>> ).
Use the show dev command to show all devices, and look for
the hardware address of your network interface in the form
xx-xx-xx-xx-xx-xx. For example:
>>> show dev
ewa0.0.0.0.1000.0 EWA0 xx-xx-xx-xx-xx-xx
.
.
.
.
.
.
• Log in to the RIS client as root or use the su command to gain superuser
privileges.
Use the uerf −r 300 command and look for the string hardware
address in the ouput. Either that line or the next one contains the
hardware network address. For example:
# uerf -r 300 | grep -i "hardware address" | uniq
_hardware address: xx-xx-xx-xx-xx-xx
If the hardware address is not on the line that contains the string
hardware address, search the output from the uerf command to find
the correct hardware address. For example:
# uerf -r 300 | more
.
.
.
_Interface, hardware address:
_xx-xx-xx-xx-xx-xx
.
.
.
• Log in to the RIS server as root or use the su command to gain
superuser privileges.
Use the ping and arp commands to determine the hardware address
of a running client from the RIS server. For example, to determine the
hardware address of the RIS client atlanta, enter a command similar
to the following example:
# /usr/sbin/ping -q -c1 atlanta ; arp atlanta
PING atlanta.cities.xsamplex.com (nn.nn.nnn.nnn): 56 data bytes
----atlanta.cities.xsamplex.com PING Statistics---1 packets transmitted, 1 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0 ms
atlanta (nn.nn.nnn.nnn)atxx-xx-xx-xx-xx-xx
2–6 Remote Installation Services
Preparing the RIS Server
This chapter provides the steps you must follow to prepare a RIS server.
These steps include the following:
1. Review RIS server/client version compatibility. (Section 3.1)
2. Plan disk space for RIS. (Section 3.2)
3. Install the operating system on the RIS server. (Section 3.3)
4. Set up a local area network. (Section 3.4)
5. Load and register the server extensions license. (Section 3.5)
6. If necessary, prepare RIS for running on a server that has C2 security
enabled. (Section 3.6)
3.1 Reviewing RIS Server/Client Version Compatibility
This section only applies if you are installing a new version of the operating
system into a RIS environment on a server that is running a previous version
of the operating system. If not, go to section Section 3.2.
3
Perform the following steps to install the operating system into a RIS
environment on a RIS server running a previous version of the operating
system:
1. Log in to the RIS server as root, or use the su command to gain
superuser privileges.
2. Mount the distribution media. For example, if your distribution media
is a CD-ROM:
• If you are using an older version of the operating system that uses
traditional device naming conventions (/dev/rrzNc), use a mount
command similar to the following example:
# mount -rd /dev/rz4c /mnt
The previous example uses a CD−ROM drive that is unit 4 and
specifies /mnt as the mount point; if your drive is a different unit,
substitute the device special file name for that unit.
The CD-ROM drive’s unit number is 4, and in this example is
/dev/rrz4c.
Preparing the RIS Server 3–1
If you do not know your CD−ROM’s unit number, see Section 1.3.
• If you are using a newer version of the operating system that uses
newer device naming conventions (
/dev/disk/cdromNc), use a
mount command similar to the following example:
# mount -rd /dev/disk/cdrom0c /mnt
The previous example uses a CD−ROM drive that is unit 0 and
specifies /mnt as the mount point; if your drive is a different unit,
substitute the device special file name for that unit.
The CD-ROM drive’s unit number is 0, and in this example is
/dev/disk/cdrom0c.
If you do not know your CD−ROM’s unit number, see Section 1.3.
3. Use the utilupdate command to update the necessary RIS utilities on
the server, as shown in the following example:
# /mnt/isl/utilupdate -r -m /mnt
• The -r option causes the utilupdate utility to copy files from
the distribution media to the server’s /usr/sbin directory. This
ensures RIS compatibility with the operating system.
• The -m /mnt argument specifies the mount point of the distribution
media and is a required parameter.
This command copies any files in the /usr/sbin directory to files with
a .pre-V5.1A suffix. For example: /usr/sbin/setld is copied to
/usr/sbin/setld.pre-V5.1A.
When the utilupdate script completes, this RIS server can serve the
current version of the operating system to RIS clients. Appendix C describes
the utilupdate utility.
When you are installing the operating system, if the utility finds existing
*.pre-V files on your system, the existing utilities are updated with no
changes to the saved *.pre-V files. If the server is already running the
new or updated version of the operating system, a confirmation message is
displayed and no copies are made.
After a client’s operating system is installed and running, a server can
serve additional product subsets to a client running a compatible operating
system. The client loads the additional subsets with the SysMan Menu.
A RIS client can be booted by a RIS server by using the BOOTP protocol. This
means that a server can serve both the base operating system as well as
additional product subsets to the client over the network. The client loads
additional product subsets with the SysMan Menu.
3–2 Preparing the RIS Server
3.2 Planning Disk Space for RIS
Before beginning to set up a RIS area, you must calculate the amount of disk
storage required for the software subsets in the RIS areas on the server. If
space on the server’s system disk is an issue and your server’s distribution
media is a CD
server area to the software on the CD−ROM. Section 4.2 briefly describes
the advantages and disadvantages of establishing symbolic links instead of
extracting the software subsets into the RIS server area.
See Chapter 1 for a description of the RIS area’s contents. A given server
can have multiple RIS areas, in which some of the subsets can be duplicated.
To organize your RIS server’s disk space, perform the following steps:
1. Determine how many RIS environments you want.
2. Choose the software subsets you want to install, organizing them by the
environments where they are to be installed.
3. Use the subset size information in the Release Notes to ensure that you
have adequate disk space.
−ROM, you might want to create symbolic links from the RIS
3.3 Installing the Operating System on the RIS Server
The Installation Guide describes how to install the operating system on
the server, and lists all of the supported software subsets along with their
names and descriptions. This information helps you organize the process
before you perform the installation.
Because RIS areas are created in the /var/adm/ris directory, you may
want to specify a separate /var file system during the installation for
extra disk space. See the instructions in the Installation Guide to specify a
separate /var file system.
Install the Remote Installation Service and Additional
Networking Services subsets on the system to be used as a RIS server.
These subsets contain the tftp networking utility and the joind bootstrap
daemon. If you want to use the Internet Boot Protocol (BOOTP) server
daemon bootpd, install the Obsolete Commands and Utilities (Obsolete
Components) subset OSFOBSOLETE520.
After you install the operating system, enter the following command to see if
these subsets are installed:
# /usr/sbin/setld -i | grep -E "RIS|INET|OBSOLETE"
Preparing the RIS Server 3–3
Your output is similar to the following:
OSFCLINET520 installed Basic Networking Services
(Network-Server/Communications)
OSFINET520 installed Additional Networking Services
(Network-Server/Communications)
OSFOBSOLETE520 installed Obsolete Commands and Utilities
(Obsolete Components)
OSFRIS520 installed Remote Installation Service
(Network-Server/Communications)
The Basic Networking Services subset is mandatory and is installed
as a mandatory subset when you install the base operating system. If the
Additional Networking Services, Remote Installation Service,
or Obsolete Commands and Utilities subsets are not installed, you
must install them with the SysMan Menu.
See the Installation Guide and sysman
(8) for more information about
installing subsets.
3.4 Setting Up a Local Area Network
You must connect the RIS server and all of the client processors to a LAN
using either Ethernet, FDDI, or Token Ring. The server and clients all must
be on the same network or subnetwork unless the router connecting the
networks or subnetworks can forward BOOTP requests.
For instructions on setting up a local area network, see the Network
Administration: Connections manual.
3.5 Loading and Registering the Server Extensions License
The Server Extensions license (OSF-SVR or UNIX-SERVER) provides the
right to use the RIS software if you are running this operating system.
A product authorization key (PAK) accompanies the license. You must
register the PAK information for your system before it can be configured as
a RIS server. Register the PAK information by using the License Manager
application.
See dxlicense
License Manager online help for more information about registering license
PAKs.
(8), the Software License Management manual, and the
After you have registered the PAK information, you can complete the server
setup tasks described in Chapter 4.
3–4 Preparing the RIS Server
3.6 Preparing RIS for C2 Security
If your RIS server will have C2 security enabled, the ris user file must be
changed to ensure that the ris password does not expire and deny client
access.
Perform the following steps on the RIS server as superuser to modify the
ris user file if you are going to use RIS with C2 security enabled:
1. Edit the file /tcb/files/auth/r/ris. Each field is delimited by
a colon (:).
2. Set the current password field u_pwd to an asterisk ( *).
3. Set the u_succhg value to any non-zero value. This value is a time_t
type printed with %ld.
4. Set the u_life and u_exp fields to zero.
The following is an example of a modified /tcb/files/auth/r/ris user
file:
ris:u_name=ris:u_id#11:\
u_oldcrypt#0:\
u_pwd=*:\
u_exp#0:u_life#0:\
u_succhg#79598399:\
u_suclog#79598399:\
u_lock@:chkent:
After you make these changes, the RIS password should not expire and
cause a denial of service to clients.
Preparing the RIS Server 3–5
Loading...