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
This chapter describes how to use the ris utility to configure a RIS server.
This chapter includes the following topics:
• Establishing a new RIS area with the ris utility (Section 4.2)
• Installing software kits in an existing RIS area (Section 4.3)
• Including hardware product kits into an existing RIS area (Section 4.4)
• Using a RIS area mounted on NFS (Section 4.5)
• Modifying the /etc/exports file, if necessary, to export RIS areas
(Section 4.6)
4.1 Overview
The ris utility can be invoked in two ways:
• Interactively through a menu-driven interface
• From the command line by issuing commands to perform the various
tasks one at a time
4
Setting Up a RIS Area
This chapter describes how to use the ris utility’s menu-driven interface.
Chapter 6 describes how to use individual ris commands. See ris
more information.
4.2 Installing Software into a New RIS Area
After you create a RIS area and install the first software kit there, you can
install more kits into that area or create other areas as you need them.
Section 4.3 describes how to install additional software into an existing
RIS environment.
Follow these steps to create a new risN .alpha environment and install
the operating system:
1. Log in as root or use the su command to gain superuser privileges.
2. Insert the Operating System Volume 1 CD-ROM into the drive, then
mount the CD-ROM.
Setting Up a RIS Area 4–1
(8) for
• If your server is running the current version of the operating system,
use a command similar to the following example:
# mount -rd /dev/disk/cdrom0c /mnt
The previous example mounts a CD-ROM drive that is device 0 on
the mount point /mnt. If your drive is a different device, substitute
the correct device name. The mount point does not have to be /mnt.
See Section 1.3 if you do not know the CD-ROM drive’s device name.
• If your server is running an earlier version of the operating system,
use a 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.
See Section 1.3 if you do not know the CD-ROM drive’s device name.
____________________ Note _____________________
You can use a Network File System (NFS) mount point to
install software from a Remote Installation Services (RIS)
area or Operating System Volume 1 CD-ROM from another
processor. See Section 4.5 for more information about using
an NFS mounted RIS area.
3. Enter /usr/sbin/ris to start the ris utility. You see the RIS Utility
Main Menu:
*** RIS Utility Main Menu ***
Choices without key letters are not available.
) ADD a client
) DELETE software products
i) INSTALL software products
) LIST registered clients
) MODIFY a client
) REMOVE a client
) SHOW software products in remote installation environments
x) EXIT
Enter your choice:
4–2 Setting Up a RIS Area
The RIS Utility Main Menu does not display option letters for menu
items that cannot be accessed. As you add environments, software, and
clients to the system, other menu options become available.
4. Enter
i to select Install software products. You see the following
prompt:
RIS Software Installation Menu:
1) Install software into a new area
2) Add software into an existing area
3) Return to previous menu
Enter your choice:
5. Enter 1 to select Install software into a new area. You see
the following prompt:
You have chosen to establish a new remote installation
environment.
Enter the device special file name or the path of the directory
where the software is located
(for example, /mnt/ALPHA/BASE):
6. Enter the full pathname or the device special file name for the
distribution media.
• If your distribution media is CD
−ROM mounted on /mnt, the
directory where the software is located is /mnt/ALPHA/BASE.
• Enter a device specific file name only for magnetic tape media.
You see the following prompt:
Select the type of operating system base product to create. If the software you
are offering supports add-on hardware that is needed to boot the client
system, select "boot-link" as the type of RIS area to create. Otherwise,
select "standard". If you select "boot-link", the software will be extracted
(or copied) to the RIS area because symbolically linked RIS areas do not
support this feature.
Choose one of the following options:
1) Standard boot method
2) Boot-Link method
Enter your choice:
7. Select one of the available options.
• Select Boot-Link method if you are adding a hardware product
kit to this RIS area.
• If you select Standard boot method, you see the following prompt:
Setting Up a RIS Area 4–3
Choose one of the following options:
1) Extract software from /mnt/ALPHA/BASE
2) Create symbolic link to /mnt/ALPHA/BASE
Enter your choice:
– If you select Create symbolic link, the ris utility creates
symbolic links from the RIS area to the subset directories on the
specified source. Disk space planning is not required because
the subsets do not reside in the RIS area. The source must be on
line and mounted for clients to access the subsets. Unlike subset
extraction, no subset selection is required. Clients registered for
symbolically linked RIS product areas can access all subsets.
________________ Caution ________________
If you unmount, delete, or switch the source where
the RIS area is linked, the RIS area is corrupted.
Remount the source to restore the RIS area.
– If you select Extract software, the ris utility copies the
selected subsets from the source into the RIS area. You must
know the specific subsets to extract and whether there is
sufficient disk space. See Section 3.2 for information about
planning disk space for RIS.
Clients can install only the subsets that are extracted into
RIS product areas where they are registered. Using extracted
subsets improves RIS environment performance.
The ris utility lists the mandatory and optional software
subsets you can install. Select the subsets that you want to
extract; the ris utility displays your list for confirmation. For
example:
The following subsets are mandatory and will be installed
automatically unless you choose to exit without installing
any subsets:
{mandatory subset list}
Optional subsets are listed below. There may be more optional
subsets than can be presented on a single screen. If this is
the case, you can choose subsets screen by screen, or all at
once on the last screen. All of the choices you make will be
collected for your confirmation before any subsets are installed.
{optional subset list}
.
.
.
.
.
.
.
.
.
.
.
.
4–4 Setting Up a RIS Area
The following choices override your previous selections:
74) ALL mandatory and all optional subsets
75) MANDATORY subsets only
76) CANCEL selections and redisplay menus
Choices (for example, 1 2 4-6):
The following subsets will be loaded:
{selected subset list - all mandatory & optional in this example}
Are these the subsets that should be loaded (y/n) ?
.
.
.
.
.
.
74
If you enter y, the ris utility loads the subsets. If you enter n,
the list of subsets is displayed again and you can restart your
selection process.
When you confirm your selections, the ris utility extracts the
subsets and displays the name of the new RIS environment.
If you are installing a product that is not part of the base operating system
in the RIS environment, the ris utility tries to determine the system
architecture. If it cannot, you see a prompt similar to the following example:
Choose the architecture of the clients that the environment
will serve:
1) alpha
2) custom
3) mips
Enter your choice: 1
The new environment is in /usr/var/adm/ris/ris0.alpha.
After you set up the RIS areas and register clients in those areas, the clients
can access the areas they need. See Chapter 6 for a discussion of client
registration.
4.3 Installing Software into an Existing RIS Area
Follow these steps to install software subsets into an existing RIS
environment. The subsets must be compatible with the setld utility. This
means that the kit was produced in accordance with the instructions in
the Guide to Preparing Product Kits.
1. Log in as root or use the su command to gain superuser privileges.
2. Enter /usr/sbin/ris to start the ris utility. You see the RIS Utility
Main Menu:
*** RIS Utility Main Menu ***
Setting Up a RIS Area 4–5
Choices without key letters are not available.
a) ADD a client
d) DELETE software products
i) INSTALL software products
) LIST registered clients
) MODIFY a client
) REMOVE a client
s) SHOW software products in remote installation environments
x) EXIT
Enter your choice:
3. Enter i to select INSTALL software products. You see the RIS
Software Installation Menu:
RIS Software Installation Menu:
1) Install software into a new area
2) Add software into an existing area
3) Return to previous menu
Enter your choice:
4. Enter 2 to select Add software into an existing area. You see a
list of the existing RIS areas, similar to the following example:
You have chosen to add a product to an existing environment.
Select the remote installation environment:
1) /usr/var/adm/ris/ris0.alpha
’POLYCENTER Advanced File System’
’DECsafe Available Server Environment (ASE)’
’System V Environment’
2) /usr/var/adm/ris/ris1.alpha
’Sort Runtime Library’
’Free Software Foundation GNU Source (Rev nnn)’
’DEC Ada Support Library’
Enter your choice or press RETURN to quit:
5. Enter a number to select the corresponding RIS area.
6. Continue to mount distribution media and choose subsets as described
in Section 4.2 . Press the Return key if you want to return to the RIS
Utility Main Menu.
Repeat this procedure for each additional group of subsets you want to
install.
4–6 Setting Up a RIS Area
4.4 Including Hardware Product Kits into a RIS Area
In addition to the base operating system, you may need to install hardware
product kits onto client systems from the RIS server. For example, a
hardware product kit can be a third-party driver for a device not supported
in the base operating system. The
product kits into a RIS area for subsequent installation onto a client system.
Setting up a RIS area to serve hardware product kits is subject to the
following requirements:
• Hardware product kits can be installed only into an extracted RIS area
that has been set up for bootlinking. You cannot install a hardware
product kit into a RIS area containing a symbolically linked base
operating system.
• The hardware product kit must be compatible with the setld utility to
be installed into an existing RIS environment. This means that the
kit was produced in accordance with the instructions in the
Preparing Product Kits.
• At a minimum, the extracted RIS area where you install a hardware
product kit must contain all mandatory subsets.
Follow this procedure to install a hardware product kit into an existing
RIS environment:
1. Log in as root or use the su command to gain superuser privileges.
ris utility lets you include hardware
Guide to
2. Start the ris utility:
# /usr/sbin/ris
You see the RIS Utility Main Menu:
*** RIS Utility Main Menu ***
Choices without key letters are not available.
a) ADD a client
d) DELETE software products
i) INSTALL software products
l) LIST registered clients
m) MODIFY a client
r) REMOVE a client
s) SHOW software products in remote installation environments
x) EXIT
Enter your choice:
3. Enter i to select INSTALL software products. You see the RIS
Software Installation Menu:
Setting Up a RIS Area 4–7
RIS Software Installation Menu:
1) Install software into a new area
2) Add software into an existing area
3) Return to previous menu
Enter your choice:
4. Enter 2 to select Add software into an existing area. You see
the following prompt, including all available RIS environments:
You have chosen to add a product to an existing environment.
Select the remote installation environment:
1) /var/adm/ris/ris1.alpha
’Tru64 UNIX V5.1A Operating System (Rev nnn )’
Enter your choice or press RETURN to quit:
5. Enter 1 (in this example) to specify the RIS environment where you will
add the hardware product kit. You see the following prompt:
Enter the device special file name or the path of the directory where
the software is located (for example, /mnt/ALPHA/BASE):
6. Enter the location of the hardware product kit you are adding, for
example: /HWKIT/MYVGA. You see the following prompt:
The kit you have specified has been identified as a kernel kit.
This type of kit may contain software which is needed during the booting of
the kernel for the installation due to required hardware support. If you need
to add this kit to the base, select the option to integrate the kit. You may
otherwise choose to add this kit to the RIS area as a separate product.
1) Integrate with Base product and include product
2) Include as separate product
3) Return to Main Menu
Enter your choice: [1]:
7. Select 1 to integrate the software with the base product. You see the
following prompt:
Please select one of the following products to add the kit to.
1 ’Tru64 UNIX V5.1A Operating System (Rev nnn)’
Enter your selection or <return> to quit:
8. Select 1 (in this example) to select the base product where you will
integrate the hardware product kit.
4–8 Setting Up a RIS Area
You see the following prompt:
Choose one of the following options:
1) Extract software from /HWKIT/MYVGA/kit
2) Create symbolic link to /HWKIT/MYVGA/kit
Enter your choice:
9. Select 1 to extract the software. You see the following prompt:
The subsets listed below are optional:
There may be more optional subsets than can be presented on a single
screen. If this is the case, you can choose subsets screen by screen
or all at once on the last screen. All of the choices you make will
be collected for your confirmation before any subsets are extracted.
1) MYVGA Test kit
Or you may choose one of the following options:
2) ALL of the above
3) CANCEL selections and redisplay menus
4) EXIT without extracting any subsets
Enter your choices or press RETURN to redisplay menus.
Choices (for example, 1 2 4-6):
10. Select 1 (in this example) to select the subset. You see the following
prompt:
You are extracting the following optional subsets:
MYVGA Test kit
Is this correct? (y/n):
11. Select y to confirm your selection. You see a prompt similar to the
following:
Checking file system space required to extract selected subsets:
File system space checked OK.
Extracting MYGASTATIC100...
Media extraction complete.
The following software now exists in RIS product area
/var/adm/ris/ris1.alpha:
1 ’Tru64 UNIX V5.1A Operating System (Rev
with ’MYVGASTATIC software version 1’
2 ’MYVGASTATIC software version 1’
nnn)’
The hardware product kit now is installed into the newly-created RIS
product area.
Setting Up a RIS Area 4–9
4.5 Using a RIS Area Mounted on NFS
You can use an NFS mount point to install software from an extracted RIS
area on another system or from an operating system distribution CD−ROM
mounted on another system. You can use this method to create an extracted
RIS area with the base operating system subsets.
_____________________ Caution _____________________
The information in this section can be used only if you are
installing software on a client after you install the operating
system software.
For example, if a system named chicago has a CD−ROM containing the
operating system subsets mounted on /mnt and listed in its /etc/exports
file, the system administrator on newyork can use mount that CD−ROM
with a command similar to the following example:
NYroot# mount chicago:/mnt/ALPHA/BASE /mnt
After chicago is mounted, the newyork system administrator can use the
ris utility to install software from the CD-ROM as if it were local to the
newyork system.
If another system exports an extracted RIS area with the subsets you need
on a local system, you can create an extracted RIS area from the remote RIS
area. For example, if a system named seattle has the operating system
subsets in its ris0.alpha product environment, the system administrator
on newyork can NFS mount that product environment with the following
command:
NYroot# mount seattle:/var/adm/ris/ris0.alpha /mnt
After the remote product environment is mounted, the system administrator
for newyork can use the ris utility to install software from it as if it were
local to newyork.
4.6 Modifying the /etc/exports File
RIS client installations of the base operating system prior to this version rely
on files located in the server’s /var/adm/ris/risN.arch/kit directories.
The RIS server must export these directories.
For this version of the operating system base product, the
/var/adm/ris/risN.arch/product_1 product directory that is exported
contains the distribution image. In this directory path, N is the number of
the RIS area and arch is the architecture of the client systems that the
area serves.
4–10 Setting Up a RIS Area
When you create the risN.arch RIS area, the ris utility supplies you with
a name based on the choices you make when you create the RIS area.
The server’s /etc/exports file must include an entry for each RIS
area that it is exporting. When you create a RIS area, the ris utility
automatically edits the /etc/exports file and adds the correct entry for
that area. However, if you modify the path to a RIS area, you also must
modify the corresponding line in the /etc/exports file.
• The RIS area entries in the /etc/exports file of a system that acts as a
RIS server for two Alpha environments look similar to the following:
/var/adm/ris/ris0.alpha/kit -root=0 -ro
/var/adm/ris/ris1.alpha/kit -root=0 -ro
/ris/r2p1 -root=0 -ro
The previous example shows a /ris/r2p1 entry in /etc/exports.
This entry is created by RIS and is a symbolic link from /ris/r2p1 to
/var/adm/ris/ris2.alpha/product_1. This link shortens the path
sent to the client during the boot process.
• When you create a /risN .alpha area, the path to the kit directory
is /var/adm/ris/ris0.alpha/kit and the ris utility places the
following line in the /etc/exports file:
/var/adm/ris/ris0.alpha/kit -root=0 -ro
If you create another directory in this RIS area, for example, dsk1,
mount another file system there, move the contents of ris0.alpha to
that directory, and then link it to ris0.alpha, a listing of the RIS area
shows the following entry:
ris0.alpha -> ./dsk1/ris0.alpha
The path to the kit directory is now effectively
/var/adm/ris/dsk1/ris0.alpha/kit. You must edit the
corresponding line in the /etc/exports file, as shown in the following
example:
/var/adm/ris/dsk1/ris0.alpha/kit -root=0 -ro
If you do not edit the /etc/exports file in this case, you will have a kit
directory mount failure when you attempt a client installation.
Setting Up a RIS Area 4–11
Booting a RIS Client
You must register a RIS client on the RIS server before you can use RIS to
install the operating system on the RIS client. If you use RIS to install the
operating system on a client, the client must boot across the network by
issuing a BOOTP request. This chapter includes the following topics:
• Describing remote boot files and daemons (Section 5.1)
• Explaining the remote boot process flow (Section 5.2)
5.1 Remote Boot Files and Daemons
Several files and daemons are associated with booting a RIS client over the
network. This section includes the following topics:
• The inetd internet daemon and its configuration file, inetd.conf
(Section 5.1.1)
• The internet boot protocol (BOOTP) joind daemon (Section 5.1.2)
• The /etc/bootptab file (Section 5.1.3)
5
• The TFTP daemon tftpd (Section 5.1.4)
See the following reference pages for more information:
bootptab
inetd.conf(4)
inet(7)
inetd(8)
joind(8)
Table 5–1 describes the files and daemons used by RIS servers to boot a
remote client.
Table 5–1: Remote Boot Files and Daemons
Name Description
/etc/bootptab
/etc/inetd.conf
/sbin/init.d/dhcp
(4)
Contains information needed to boot remote clients
Contains start-up information for various
internet daemons
Script used to start joind
Booting a RIS Client 5–1
Table 5–1: Remote Boot Files and Daemons (cont.)
Name Description
/usr/sbin/inetd
/usr/sbin/joind
/usr/sbin/tftpd
The Internet server daemon
The BOOTP server daemon (handles both BOOTP
and DHCP requests, if configured)
The tftpd server daemon
5.1.1 The Internet Daemon and Configuration File
The inetd internet daemon starts networking-related daemons on the
system. Some of these daemons, such as tftpd, are related to RIS; others,
such as fingerd, are not. On request, the inetd daemon starts any of the
daemons listed in its configuration file, /etc/inetd.conf.
Network boots use the BOOTP protocol and are serviced by the joind
daemon, discussed in Section 5.1.2.
5.1.2 The BOOTP Daemon
The internet boot protocol (BOOTP) daemon joind processes any BOOTP
requests received by the RIS server. As it starts, the BOOTP daemon
reads the /etc/bootptab file to determine the systems from which it
will recognize remote boot requests. Whenever the /etc/bootptab file is
modified, the BOOTP daemon rereads it.
The joind daemon provides configuration to network clients using either
BOOTP or the Dynamic Host Configuration Protocol (DHCP). If joind is
not running, RIS restarts it with the /sbin/init.d/dhcp script.
Section 5.1.3 describes the content and format of the /etc/bootptab file.
See bootptab
(4) and dhcptags(4) for more information.
5.1.3 The /etc/bootptab File
The /etc/bootptab file is a text file containing information that a server
needs to boot a remote client. The ris utility adds and removes entries from
this file during client management. Other applications may place entries
in the /etc/bootptab file.
Example 5–1 shows the entries in an /etc/bootptab file for RIS clients.
5–2 Booting a RIS Client
Example 5–1: Sample /etc/bootptab File
.ris.dec:hn:vm=rfc1048 1
.ris0.alpha:tc=.ris.dec:bf=/var/adm/ris/ris0.alpha/vmunix: 2
atlanta:tc=.ris0.alpha:ht=ethernet:gw=nn.nn.nnn.nnn:\
ha=nnnnnnnnnnnn:ip=nn.nn.nnn.nnn :
.ris93.alpha:tc=.ris.dec:bf=/ris/ris93.a/vmunix: \
rp="ds9:/ris/ris93.a/product_001":
1 The .ris.dec entry defines characteristics common to all clients. The
3
4
fields specify the following:
• hn: Tells the boot server to send the name of the client system to the
client when it makes a boot request.
• vm: Vendor-specific information
2 The .risN.arch entry, in this example .ris0.alpha, defines
characteristics common to all clients using this RIS area. The fields
specify the following:
• tc: Table continuation
The tc field lets you follow pointers back to common entries. For
example, the tc entry for .ris0.alpha in Example 5–1 points to
the .ris.dec entry. The .ris.dec entry contains the common
hardware type (ht) and vendor specific (vm) information. The
.ris0.alpha entry, itself, contains common information about the
boot file location.
• bf: Name of the boot file
3 The hostname entry, in this example atlanta, defines characteristics
for a specific client. The fields specify the following:
• tc: Table continuation
The following describes the entry for the host atlanta: its tc entry
points to ris0.alpha, which contains its boot file information. The
ris0.alpha entry in turn points back to ris.dec, which contains
relevant hardware type and vendor specific information. If you
added another host entry to the /etc/bootptab file, it would look
similar to the following:
lee:tc=ris0.alpha:ht=ethernet:ha=nnnnnnnnnnnn :\
ip=nn.nn.nnn.nnn :
• ht: The client’s hardware type is either ethernet, fddi,or
ieee802 (for Token Ring)
Booting a RIS Client 5–3
• ha: Client’s network hardware address
• ip: Client’s IP address
4 The .ris93.alpha entry defines characteristics for the current version
of the operating system RIS area. The fields specify the following:
• tc: Table continuation
The tc field lets you follow pointers back to common entries. For
example, the tc entry for .ris93.alpha in Example 5–1 points to
the .ris.dec entry. The .ris.dec entry contains the common
hardware type (ht) and vendor specific (vm) information. The
.ris93.alpha entry contains common information about the boot
file location.
• bf: Name of the boot file
• rp: The client will mount its root on the server.
The general format for entries in the bootptab file is a label followed
by one or more colon-separated fields. Each of these fields consists of a
two-character tag field tg followed by an equal sign (=) and the tag value
value:
[label]:tg[=value][:tg[=value]:…]
See bootptab(4) for additional information. See dhcptags
information about valid tg tags.
(4)
for
5.1.4 The tftpd Daemon
The tftpd daemon uses the Trivial File Transfer Protocol (TFTP) to transfer
the boot file during a remote boot process. The tftpd daemon starts
when a file is ready to be transferred. See tftp
information.
5.2 Remote Boot Process Flow
Client systems use the bootp protocol to perform the remote boot operation
from a RIS server. The command used to initiate a remote boot is processor
specific. For additional information, see the Installation Guide — Advanced
Topics. However, after the remote boot operation has started, the underlying
process is the same for all versions of the operating system that support
network booting:
1. The processor-specific remote boot command is issued at the client
console prompt.
2. The client processor firmware sends a BOOTP packet over the Ethernet
contining the client’s hardware Ethernet address.
5–4 Booting a RIS Client
(1) and tftpd(8) for more
3. The BOOTP server daemon compares the Ethernet hardware address
in the packet with the client registration information stored in its
/etc/bootptab file to determine if the client requesting the remote
boot is registered to the RIS server.
4. If a matching address is found in the /etc/bootptab file, the BOOTP
daemon sends the client an information packet that includes the
server’s Internet address, the client’s Internet address, and the name
of the file to be loaded from the server. This information was placed in
the bootptab file by the ris utility when the client was registered
on the RIS server.
Internet addresses are used to download the
/var/adm/ris
N.alpha/vmunix file specified in the bootptab file to
the client processor, where risN.alpha corresponds to the RIS area
to which the client is registered. This file contains the standalone
operating system used to start the installation.
5. The client system requests the file from the server system.
6. The client and server system use the TFTP protocol to transfer the
vmunix file to the client.
7. After vmunix is loaded, the client system begins to execute the vmunix
file, and the operating system standalone system messages are
displayed on the client console terminal.
After the operating system is installed, the client is a self-supporting system.
Follow the procedures documented in the Installation Guide to boot the
system from its own local disk.
Booting a RIS Client 5–5
Managing RIS Clients and Environments
Use the ris utility to manage RIS environments and clients. This chapter
includes the following topics:
• Preparing to register RIS clients (Section 6.1)
• Adding a client with the ris utility (Section 6.2)
• Adding a client from the command line (Section 6.3)
• Modifying a client (Section 6.4)
• Removing a client (Section 6.5)
• Listing registered clients (Section 6.6)
• Listing software products in RIS areas (Section 6.7)
• Deleting software products from RIS areas (Section 6.8)
• Correcting entries in the RIS gateways file (Section 6.9)
6.1 Preregistration Tasks
6
Before you register RIS clients, gather the information required for each
one. The RIS Client Configuration Worksheet in Appendix A will help you
organize your information as you register clients. Fill out a worksheet for
each client you want to register.
Perform the following tasks to prepare to register clients:
1. Obtain information about each client and fill out a copy of the RIS Client
Configuration Worksheet from Appendix A. (Section 6.1.1)
2. Register each client’s host name and Internet Protocol (IP) address in
the RIS server’s /etc/hosts file and on your local area network with
any name servers for Berkeley Internet Name Domain (BIND) Service
and Network Information Service (NIS). (Section 6.1.2)
6.1.1 Obtaining Information About Each Client
You need the following information about each processor you plan to register
as a client:
• Host name (see Section 6.2 for host name restrictions)
• The RIS environments you want to make available to the client
Managing RIS Clients and Environments 6–1
• The client’s hardware network address
• The address of the gateway from the client to the server, if the server
and client are on different networks
• The type of network where the client is connected: Ethernet, FDDI,
or Token Ring
• Whether or not you want to use a profile set during installation (see
Chapter 7 for information about profile sets)
6.1.2 Registering Client Host Names and IP Addresses
Make sure that your clients are registered with the naming services
available on your LAN:
• The RIS server’s /etc/hosts file
• Any Berkeley Internet Name Domain (BIND) server
• Any Network Information Services (NIS) server
Use the Network Configuration Application to place each client processor’s
host name and IP (Internet Protocol) address in the /etc/hosts file when
you first set up your LAN. See the Network Administration: Connections
manual for information about the Network Configuration Application.
You also can place the host name and IP address in the /etc/hosts file
with a text editor such as vi. The host name and IP address for each client
processor must be unique. See hosts
/etc/hosts file.
(4) for more information about the
See the Network Administration: Services manual for information about
setting up NIS and the BIND Configuration Application.
6.2 Adding a RIS Client with the ris Utility
Follow this procedure to add a RIS client:
1. Log in as root or use the su command to gain superuser privileges.
2. Enter /usr/sbin/ris to start the ris utility. You see the RIS Utility
Main Menu:
*** RIS Utility Main Menu ***
Choices without key letters are not available.
a) ADD a client
d) DELETE software products
i) INSTALL software products
) LIST registered clients
6–2 Managing RIS Clients and Environments
) MODIFY a client
) REMOVE a client
s) SHOW software products in remote installation environments
x) EXIT
Enter your choice:
3. Enter a to select ADD a client. You see the following prompt:
You have chosen to add a client for remote installation services.
The following conditions must be met to add a client:
1. You must know the client processor’s hostname.
2. The client’s hostname must be in your system’s host
database(s).
3. You must know whether the client is on an Ethernet, FDDI,
or Token Ring network.
4. You must know the client’s hardware Ethernet, FDDI, or
Token Ring address if the client is registering to install
operating system software.
5. If the client and the server reside on different subnets,
you will need the address of the gateway(s)
that the client can use to communicate with the server.
Do you want to continue? (y/n) [y]:
4. Enter
y to continue. You see the following prompt:
Enter the client processor’s hostname: client1
5. Enter the client’s host name.
___________________ Caution ___________________
Only lowercase letters ( a-z ), numerals (0-9), and the period
(.) and dash (-) characters are permitted in host names,
which must begin with a letter. Invalid host names can
corrupt the RIS database. The client must not be registered
on another RIS or DMS server as a client.
The client processor must be registered with the appropriate
naming service (Section 6.1.2) or you cannot register the
client with RIS. If the client is not registered with the
appropriate naming service, the ris utility displays an error
message and repeats the prompt.
6. What you see next depends upon whether you have hardware product
kits installed on your RIS server.
• If you do not have hardware product kits installed on your RIS
server, you see a prompt similar to the following, which shows (in
this example) two RIS environments:
Managing RIS Clients and Environments 6–3
Select the remote installation environment:
1) /usr/var/adm/ris/ris2.alpha
’Tru64 UNIX V5.1 Operating System (Rev nnn)’
2) /usr/var/adm/ris/ris3.alpha
’Tru64 UNIX V5.1A Operating System (Rev nnn)’
Enter your choice or press RETURN to quit:
a. Enter the RIS environment where you want to add the client,
for example: 2. You see a prompt similar to the following:
Select one or more products for the client to install
from /usr/var/adm/ris/ris3.alpha:
Product Description
1 ’Tru64 UNIX V5.1A Operating System (Rev nnn)’
Enter one or more choices as a space-separated list
(for example, 1 2 3) or all for all products [all]:
b. Enter the number of the product you want this client to be
able to install, for example: 1. You see a prompt similar to
the following:
You chose the following products:
1 ’Tru64 UNIX V5.1A Operating System (Rev nnn)’
Is that correct? (y/n) [y]:
• If you have hardware product kits installed on your RIS server, you
see a prompt similar to the following, which shows (in this example)
one RIS environment:
The existing environment is /var/adm/ris/ris0.alpha.
Select one or more products for the client to install
from /var/adm/ris/ris0.alpha:
Product Description
1 ’Tru64 UNIX V5.1A Operating System (Rev nnn )’ with
’MYVGASTATIC software version 1’
2 ’MYVGASTATIC software version 1’
Enter one or more choices as a space-separated list
(for example, 1 2 3) or "all" for all products [all]:
Enter all.
6–4 Managing RIS Clients and Environments
___________________ Note ___________________
You must enter all for the new hardware support to be
loaded during the installation process.
You see a prompt similar to the following:
You chose the following products:
1 ’Tru64 UNIX V5.1A Operating System (Rev nnn )’ with
’MYVGASTATIC software version 1’
2 ’MYVGASTATIC software version 1’
Is that correct? (y/n) [y]:
7. Enter y to confirm your selection.
What happens next depends upon whether profile sets reside on the RIS
server. See Chapter 7 for information about profile sets.
• If no such profile sets reside on the RIS server, the ris utility
proceeds to the next step.
• If profile sets reside on this RIS server, you see the following prompt:
Do you want to specify an Installation Profile Set for use
during the installation of this client? [y/n] [n]:
Choose one of the following options:
– Enter n if you do not want to specify a profile set for Installation
Cloning. The ris utility proceeds to the next step.
– Enter y to specify a profile set for Installation Cloning. You see a
prompt similar to the following:
This RIS server has the following Installation Profile Sets available:
Astation400 Astation400a rz26
Enter a set name or press <Return> to exit set selection:
If you select a profile set, the ris utility validates it before
proceeding. If you do not want to select an available profile
set, press Return.
8. You see the following prompt:
Network type:
1) Ethernet or FDDI
2) Token Ring
Enter your choice:
Managing RIS Clients and Environments 6–5
9. Select the type of network where the client is connected, for example:
1 for Ethernet.
• If the server and client are connected to the same network, the ris
utility proceeds to the next step.
• If the server and client are on different networks, the ris utility
looks at the /var/adm/ris/gateways file and displays the
gateway information needed for the client to connect to the server:
Using nn.nn.nnn.nnn for gateway address between client and server subnet.
If this gateway address is incorrect, please refer to the Sharing Software
on a Local Area Network book for information on how to correct it.
If the displayed gateway address is incorrect, follow the instructions
in Section 6.9 to correct this information.
• After selecting the network type, you will see a prompt similar to
the following:
Is this client a cluster alias? (y/n) [n]:
Enter y or n to specify whether the client is or is not a cluster alias.
For example, if you select y, RIS does not need to get a hardware
(ethernet) address for the client. If you select n, then you will see a
prompt similar to the following:
Enter the client processor’s hardware network address.
For example, 08-00-2b-02-67-e1:
• Enter the RIS client’s hardware network address.
– If you do not know the RIS client’s hardware network address,
see Section 2.6.
– If you are adding a cluster member as a RIS client, enter the
cluster member’s actual hardware network address.
– If you are adding a cluster alias as a RIS client, enter a fictitious
hardware address, for example: 00–00–00–00–00–01.
___________________ Note ___________________
If you do not enter the address in the correct format, the
ris utility displays an error message and repeats the
prompt. The ris utility checks your entry’s format but
does not verify its validity.
You see a message similar to the following:
Client client1 has been added.
6–6 Managing RIS Clients and Environments
6.3 Adding a RIS Client from the Command Line
You can add a single RIS client from the command line by invoking the ris
utility with its −a option. Other options supply the network address, path,
and product list. Use the following syntax for the ris utility:
/usr/sbin/ris -a clientname -h network-address -p path,product [ ,product...]
For example:
# /usr/sbin/ris -a fargo -h xx-xx-xx-xx-xx-xx -p
ris0.alpha,product_1
If the client is a cluster alias, then the -h option should be "cluster
alias".
6.4 Modifying RIS Clients
You can modify a RIS client’s network type, hardware network address, its
RIS environment information, and the list of products it can install. You
cannot modify a client’s IP or routing information. To modify a client’s entry,
follow these steps:
1. Log in as root or use the su command to gain superuser privileges.
2. Start the ris utility:
# /usr/sbin/ris
You see the RIS Utility Main Menu:
*** RIS Utility Main Menu ***
Choices without key letters are not available.
a) ADD a client
d) DELETE software products
i) INSTALL software products
l) LIST registered clients
m) MODIFY a client
r) REMOVE a client
s) SHOW software products in remote installation environments
x) EXIT
Enter your choice:
3. Enter m to select MODIFY a client. You see a prompt similar to the
following:
The following clients are available to modify:
client01 client02 client03 client04
Enter the client processor’s hostname or press RETURN to quit:
Managing RIS Clients and Environments 6–7
4. Enter the client name, for example: client01. You see a prompt
similar to the following:
Select the remote installation environment:
1) /var/adm/ris/ris10.alpha
’Tru64 UNIX V5.1 Operating System ( Rev nnn )’
2) /var/adm/ris/ris11.alpha
’Tru64 UNIX V5.1A Operating System ( Rev nnn )’
Enter your choice or press RETURN to quit:
5. Enter the number of the RIS environment you want, for example: 2.
You see a prompt similar to the following:
Select one or more products for the client to install
from /var/adm/ris/ris11.alpha:
Product Description
1 ’Tru64 UNIX V5.1A Operating System ( Rev nnn )’
Enter one or more choices as a space-separated list
(for example, 1 2 3) or "all" for all products [all]:
6. Enter the numbers of the products you want to install, or press
Return
for all products. You see a prompt similar to the following:
You chose the following products:
1 ’Tru64 UNIX V5.1A Operating System ( Rev nnn )’
Is that correct? (y/n) [y]:
7. Enter y to verify your selection. You see a prompt similar to the
following:
Network type:
1) Ethernet or FDDI
2) Token Ring
Enter your choice
8. Enter your network type, for example: 1 to select Ethernet. After
selecting the network type, you will see a prompt similar to the
following:
Is this client a cluster alias? (y/n) [n]:
9. Enter y or n to specify whether the client is or is not a cluster alias. For
example, if you select y, RIS does not need to get a hardware (ethernet)
address for the client. If you select n, then you will see a prompt similar
to the following:
Enter the client processor’s hardware network address. For
example, 08-00-2b-02-67-e1 [xx-xx-xx-xx-xx-xx]:
6–8 Managing RIS Clients and Environments
Enter your client’s hardware network address, or press Return if the
default is correct. The default is the client’s existing hardware address.
See Section 2.6 for information about determining a system’s hardware
network address.
You see a message similar to the following:
Client client01 has been modified.
*** RIS Utility Main Menu ***
a) ADD a client
d) DELETE software products
i) INSTALL software products
l) LIST registered clients
m) MODIFY a client
r) REMOVE a client
s) SHOW software products in remote installation environments
x) EXIT
Enter your choice:
______________________ Note _______________________
To modify a RIS client’s IP or routing information, remove the
client and add it with the modified information.
6.5 Removing RIS Clients
To remove a RIS client, follow these steps:
1. Log in as root or use the su command to gain superuser privileges.
2. Start the ris utility:
# /usr/sbin/ris
You see the RIS Utility Main Menu:
*** RIS Utility Main Menu ***
Choices without key letters are not available.
a) ADD a client
d) DELETE software products
i) INSTALL software products
l) LIST registered clients
m) MODIFY a client
r) REMOVE a client
s) SHOW software products in remote installation environments
x) EXIT
Managing RIS Clients and Environments 6–9
Enter your choice:
3. Enter r to select REMOVE a client. You see a prompt similar to the
following:
You have chosen to remove a client from the remote installation
services.
Enter the client processor’s hostname or press RETURN to quit:
4. Enter the client’s host name, for example: client01. You see a prompt
similar to the following:
Remove client01? (y/n) [n]:
5. Enter y to confirm the removal. You see the RIS Utility Main Menu.
You also can use a ris command line to remove several clients at once. The
following example removes the clients boston and tulsa:
# /usr/sbin/ris -r boston tulsa
6.6 Listing Registered RIS Clients
Follow these steps to view registered RIS clients:
1. Log in as root or use the su command to gain superuser privileges.
2. Start the ris utility:
# /usr/sbin/ris
You see the RIS Utility Main Menu:
*** RIS Utility Main Menu ***
Choices without key letters are not available.
a) ADD a client
d) DELETE software products
i) INSTALL software products
l) LIST registered clients
m) MODIFY a client
r) REMOVE a client
s) SHOW software products in remote installation environments
x) EXIT
Enter your choice:
3. Enter l (lower-case L) to select LIST registered clients. You see a
message similar to the following:
The following clients are registered for /var/adm/ris/ris10.alpha:
client02
6–10 Managing RIS Clients and Environments
The following clients are registered for /var/adm/ris/ris11.alpha:
client01 client03 client04
6.7 Listing Products in RIS Server Areas
Follow these steps to list the available product in RIS server areas:
1. Log in as root or use the su command to gain superuser privileges.
2. Start the ris utility:
# /usr/sbin/ris
You see the RIS Utility Main Menu:
*** RIS Utility Main Menu ***
Choices without key letters are not available.
a) ADD a client
d) DELETE software products
i) INSTALL software products
) LIST registered clients
) MODIFY a client
) REMOVE a client
s) SHOW software products in remote installation environments
x) EXIT
Enter your choice:
3. Enter s to select SHOW software products in remote
installation environments. You see a prompt similar to the
following:
1) /var/adm/ris/ris10.alpha
’Tru64 UNIX VAAA Operating System ( Rev nnn )’
2) /var/adm/ris/ris11.alpha
’Tru64 UNIX VBBB Operating System ( Rev nnn )’
You also can use the ris -s command to show the products installed in a
server’s area. For example:
# /usr/sbin/ris -s
Show Products in RIS Server Areas:
1 /var/adm/ris/ris0.alpha
Tru64 UNIX V5.1A Operating System (Rev nnn)
Managing RIS Clients and Environments 6–11
6.8 Deleting Products from RIS Server Areas
To delete one or more of the current products in a RIS area, invoke the ris
utility and choose the option to delete products. The utility asks you to choose
a RIS area and then guides you through the procedure to delete products.
1. Log in as root or use the su command to gain superuser privileges.
2. Start the ris utility:
# /usr/sbin/ris
You see the RIS Utility Main Menu:
*** RIS Utility Main Menu ***
Choices without key letters are not available.
a) ADD a client
d) DELETE software products
i) INSTALL software products
l) LIST registered clients
m) MODIFY a client
r) REMOVE a client
s) SHOW software products in remote installation environments
x) EXIT
Enter your choice:
3. Enter d to select DELETE software products. You see a prompt
similar to the following:
Select the remote installation environment:
1) /usr/var/adm/ris/ris0.alpha
’Product 01’
’Product 02’
2) /usr/var/adm/ris/ris1.alpha
’Product 03’
’Product 04’
Enter your choice or press RETURN to quit:
4. Enter the number of the RIS area you want, for example: 2. You see a
prompt similar to the following:
Select one or more products to delete from
/usr/var/adm/ris/ris1.alpha:
Product Description
1 ’Product 03’
2 ’Product 04’
6–12 Managing RIS Clients and Environments
Enter one or more choices as a space-separated list
(for example, 1 2 3) or "all" for all products:
5. Enter the number of the product you want to delete, for example: 1.You
see a prompt similar to the following:
You chose the following products:
1 ’Product 03’
Is that correct? (y/n) [y]:
6. Enter y to confirm your selection.
RIS does not keep empty RIS areas. If there is only one product in the
RIS area you selected, the ris utility verifies your intentions.
a. You see a prompt similar to the following:
After this deletion, the area /usr/var/adm/ris/ris1.alpha will be empty.
The following clients are registered for /usr/var/adm/ris/ris1.alpha:
client02
This procedure will remove /usr/var/adm/ris/ris1.alpha altogether and
remove all clients registered to it. Do you wish to continue? (y/n) [n]:
b. Enter y if you want to delete the product, the RIS area, and all
clients registered to the RIS area.
You see the RIS Utility Main Menu.
6.9 Correcting RIS Gateways File Entries
The /var/adm/ris/gateways file contains information about the address
of the gateway between the client system and the RIS server. When you
register a new client (Section 6.2), the ris utility queries this file to
determine if a gateway is already specified for the client’s network subnet. If
not, you are prompted to supply the IP address of the gateway.
If you enter the gateway address incorrectly, log in as root (or
use the su command to gain superuser privileges) and edit the
/var/adm/ris/gateways file to correct the entry. Entries in the gateways
file have the following format:
subnet_addr:gateway_addr
Managing RIS Clients and Environments 6–13
Example 6–1 shows a typical /var/adm/ris/gateways file:
Example 6–1: Sample /var/adm/ris/gateways File
16.168.64:16.168.64.1
16.69.240:16.69.224.199
16.140.144:16.140.144.2
16.69.144:16.69.144.199
After you correct the entries in this file, you must use the ris utility to
remove all clients using the incorrect gateway address and register them
again.
6–14 Managing RIS Clients and Environments
7
Managing RIS Profile Sets
A profile set is a logically organized subdirectory of the
/var/adm/ris/clients/sets directory on a RIS server. It contains
configuration description files (CDFs) and user-supplied files that can be
invoked during a Full Installation and used for Installation Cloning. When
you register a RIS client for a RIS area, you can specify a profile set that
contains CDFs or user-supplied files that you want to execute when you
install software from the RIS area.
This chapter discusses the following topics:
• Creating profile set directories (Section 7.2)
• Registering RIS clients for profile sets (Section 7.3)
• Converting old configuration description files (Section 7.4)
• Determining a RIS client’s profile set registration (Section 7.5)
• Removing a RIS client’s profile set registration (Section 7.6)
• Deleting profile sets from the RIS server (Section 7.7)
7.1 Overview
A profile set can contain one or more of the following files:
• The install.cdf file is used for Installation Cloning.
This file is generated in the /var/adm/smlogs directory when you
install the current version of the operating system with the Full
Installation process. It contains a record of the file system layout, hostand site-specific information, and the software that was installed during
a Full Installation. This information can be used to clone the same
installation on other systems with similar hardware.
• The config.cdf file is used for Configuration Cloning.
This file contains network, internet, printer, and mail configuration
information that has been saved from a fully installed and configured
system. Use the sysman -clone -save command to create the
config.cdf file whenever you want to save configuration information.
The config.cdf file can be applied to a target system during a Full
Installation, or it can be applied manually to a running system.
Managing RIS Profile Sets 7–1
• User-supplied files are a way to extend and customize the installation
process, and can contain scripts, executables, or programs. The Full
Installation and Update Installation processes execute user-supplied
files at predetermined points during the installation.
User-installed files may include some or all of the following files:
preinstall
–
– update_preinstall
– postload
– update_postload
– postreboot
• Any files called by the user-supplied files.
If a RIS client system is registered for a profile set, the Full Installation
process searches the client system’s registered profile set and takes action if
it finds any of these user-supplied files.
You can organize CDFs and user-supplied files into profile sets to support
different functions or types of systems within your processing environment.
For example:
• If you install and configure engineering systems differently from
accounting department systems, you might create two profile set
directories: engineering and accounting. Those profile sets would
contain the CDFs and files you create to suit the configuration needs of
both departments.
• If you maintain separate CDFs and files for servers and workstations, you
might create profile set directories named server and workstation.
See the Installation Guide — Advanced Topics for information about
Installation Cloning, Configuration Cloning, creating and modifying CDFs,
and creating user-supplied files.
7.2 Creating Profile Sets
The /var/adm/ris/clients/sets directory can contain many profile
sets. Each of the profile set directories may contain CDFs and user-supplied
files, as well as any files called by them.
Use the following procedure to create profile sets:
1. Log in to the RIS server as root or use the su command to gain
superuser privileges.
2. Go to the profile sets directory:
# cd /var/adm/ris/clients/sets
7–2 Managing RIS Profile Sets
3. Create the profile set directory. For example:
# mkdir engineering
4. Go to the newly created directory to ensure that the necessary files are
copied to the correct destination. For example:
# cd engineering
5. Copy the CDFs, any user-supplied files, and all other related files from
your working area to the new
engineering profile set directory using a
copy tool such as cp, ftp,orrcp.
For example, if your CDFs and user-supplied files are in the
/users/dev/working directory on the same system:
# cp /users/dev/working/install.cdf .
# cp /users/dev/working/config.cdf .
# cp /users/dev/working/preinstall .
# cp /users/dev/working/update_preinstall .
# cp /users/dev/working/postload .
# cp /users/dev/working/update_postload .
# cp /users/dev/working/postreboot .
6. Use the chmod command to ensure that all files have execute
permission:
# chmod 755 *
7.3 Registering Clients for Profile Sets
After you copy CDFs and other files to the profile set directory, you can
register RIS clients for cloning or for user-supplied file invocation during a
full RIS installation. You do this by registering new clients to a profile set as
well as to a RIS environment.
In Example 7–1, you have established profile sets for client workstations
in different departments. You are registering the client pubs08 for the
operating system in the RIS area ris0.alpha and for the profile set
techpubs.
Example 7–1: Sample RIS Client Profile Set Registration
# /usr/sbin/ris
*** RIS Utility Main Menu ***
a) ADD a client
d) DELETE software products
i) INSTALL software products
l) LIST registered clients
m) MODIFY a client
r) REMOVE a client
s) SHOW software products in remote installation environments
x) EXIT
Managing RIS Profile Sets 7–3
Example 7–1: Sample RIS Client Profile Set Registration (cont.)
Enter your choice: a
You have chosen to add a client for remote installation services.
The following conditions must be met to add a client:
1. You must know the client processor’s host name
2. The client’s host name must be in your system’s host database(s).
3. You must know whether the client is on an Ethernet, FDDI, or Token
Ring network.
4. You must know the client’s hardware Ethernet, FDDI, or Token
Ring address if the client is registering to install operating
system software.
5. If the client and the server reside on different subnets, you will
need the address of the gateway(s) that the client can use to
communicate with the server.
Do you want to continue? (y/n) [y]: y
Enter the client processor’s hostname or press RETURN to quit: pubs08
Select the remote installation environment:
1) /var/adm/ris/ris0.alpha
Operating System Release N ( Rev nnn )’
’
’OS Worldwide Language Support Version N ( Rev nnn )’
2) /var/adm/ris/ris1.alpha
’Something else in this RIS area’
Enter your choice or press RETURN to quit: 1
Select one or more products for the client to install
from /var/adm/ris/ris0.alpha:
Product Description
1 ’Operating System Release N ( Rev nnn )’
2 ’OS Worldwide Language Support Version N ( Rev nnn )’
Enter one or more choices as a space-separated list
(for example, 1 2 3) or "all" for all products [all]: 1
You chose the following products:
1 ’Operating System Release N ( Rev nnn )’
Is that correct? (y/n) [y]: y
Do you want to specify an Installation Profile Set for use
during the installation of this client? [y/n] [n]: y
This RIS server has the following Installation Profile Sets available:
sys_admin engineering support techpubs accounting
Enter a set name or press <Return> to exit set selection: techpubs
You have selected the techpubs installation profile set.
This set contains the following files:
pubs_wksta
7–4 Managing RIS Profile Sets
Example 7–1: Sample RIS Client Profile Set Registration (cont.)
Network type:
Enter your choice: 1
Enter the client processor’s hardware network address. For
example, 08-00-2b-02-67-e1: xx-xx-xx-xx-xx-xx
Client pubs08 has been added.
*** RIS Utility Main Menu ***
a) ADD a client
d) DELETE software products
i) INSTALL software products
l) LIST registered clients
m) MODIFY a client
r) REMOVE a client
s) SHOW software products in remote installation environments
x) EXIT
Enter your choice: x
#
1) Ethernet or FDDI
2) Token Ring
If the CDF in the profile set you select requires software subsets that do not
exist in the selected RIS environment, you see the following message:
The selected CDF, /var/adm/ris/clients/sets/techpubs/install.cdf, specifies
software subsets that are not present in the selected RIS environment. The
missing software subsets are:
subsetname4 subsetname5 subsetname6
Please select a different set.
This RIS server has the following Installation Profile Sets available:
sys_admin engineering support techpubs accounting
Enter a set name or press <Return> to exit set selection:
subsetname1 subsetname2 subsetname3
Either choose a different profile set or exit without selecting a profile set. If
necessary, you can modify the RIS client to select a different RIS environment
or add the product containing the required subsets to the RIS area.
7.4 Converting Old Configuration Description Files
If you had existing CDFs in the /var/adm/ris/clients/cdf directory, RIS
must convert the old CDFs into profile sets. The first time you invoke the ris
utility after you install this version of the operating system, the ris utility
creates new profile set directories in the /var/adm/ris/clients/sets
directory and copies the old CDFs into these profile sets, renaming them if
necessary. You may see conversion messages similar to the following:
Managing RIS Profile Sets 7–5
Converting old cdf directory to new sets directory format...
CDF File acctng moved to set acctng and renamed install.cdf
CDF File acctng.cdf moved to set acctng1 and renamed install.cdf
CDF File acctng1.cdf moved to set acctng11 and renamed install.cdf
CDF File acctng.cdf2 moved to set acctng12 and renamed install.cdf
done
After the old CDFs are converted to profile sets, these messages are not
displayed again.
7.5 Determining RIS Client Profile Set Registration
To determine if a RIS client is registered to a profile set, examine the RIS
database file, /var/adm/ris/clients/risdb, on the RIS server. The
name of the profile set is specified in the fourth field; fields are separated by
a colon. In the following sample entry in the risdb file, the client system
portland is registered to the engineering profile set:
portland:xx-xx-xx-xx-xx-xx:ris2.alpha,product_1:engineering
7.6 Removing RIS Client Profile Set Registration
You can remove a client from profile set registration by using the Modify
option from the RIS Utility Main Menu. When you are prompted to specify a
profile set for the client, enter n or press
specifying a profile set.
Return to register the client without
7.7 Deleting Profile Sets from the RIS Server
If a profile set is no longer needed, you can delete it by removing its
subdirectory from the /var/adm/ris/clients/sets directory.
Examine the RIS database file on the RIS server,
/var/adm/ris/clients/risdb, before deleting a profile set to ensure
that no clients are registered to it. The name of the profile set is specified
in the fourth field; fields are separated by a colon ( : ). In the following
sample entry in the risdb file, the client vallejo is registered to the
accounting profile set:
vallejo:xx-xx-xx-xx-xx-xx:ris2.alpha,product_1:accounting
7–6 Managing RIS Profile Sets
This chapter contains information to help you troubleshoot problems with
your RIS system. These problems are grouped into the following categories:
• RIS lock files (Section 8.1)
• Client password expiration (Section 8.2)
• Root file system mounting (Section 8.3)
• RIS client registration (Section 8.4)
• RIS server response (Section 8.5)
8.1 RIS Lock Files
To prevent multiple users from performing simultaneous operations on RIS
areas, the ris utility creates two lock files in the /tmp directory, rislock
and ris.tty.lock when you are installing or deleting software in a RIS
area. If another user (or the same user on a different terminal) runs the ris
utility and attempts to install or delete software from the RIS Utility Main
Menu, they see a message similar to the following:
8
Troubleshooting RIS
The ris utility is currently locked while j_smith on /dev/ttyp3
is installing software. Try again later.
If the ris utility is stopped prematurely, these lock files may not be removed
and you see this message even though no other user is using RIS. You must
delete the lock files from the /tmp directory.
_____________________ Caution _____________________
Before deleting the lock files, ensure that no other user is using
the ris utility.
Troubleshooting RIS 8–1
8.2 Client Password Expiration
If the RIS server is using C2 security and the RIS password has been set
to allow expiration, it is possible for the RIS clients to be denied service. If
the RIS client receives a message similar to the following, the RIS password
on the server probably has expired:
Cannot find the name for client using bin/getname. Check with the system
manager of your RIS server
To fix this problem, see Section 3.6.
8.3 Root File System Mounting
RIS uses NFS to mount the root ( / ) file system on the client when booting the
client from the RIS server. If you see a message on the RIS client indicating
that the root file system cannot be mounted, use the ps -aef | grep
mountd command line to see if the NFS mount daemon mountd is running
on the server. If mountd is running, you see output similar to the following
ps -aef | grep mountd
#
root 308 1 0.0 17:24:28 ?? 0:00.02 /usr/sbin/mountd -i -n -n
root 3154 1053 0.0 12:52:55 ttyp3 0:00.00 grep mountd
#
If the mountd daemon is not running, use the SysMan Menu to restart
the NFS daemons. If you are running an earlier version of the operating
system, use the nfssetup command. See sysman
more information.
(8) and nfssetup
(8) for
The installation media is mounted as the root file system for both CD-ROM
and RIS installations, so it is important that the installation media is
mounted locally on the server. Due to NFS limitations, RIS cannot provide
client access to files that are mounted remotely from another system. The
distribution media or extracted RIS area must be available through a local
mount point on the RIS server.
8.4 RIS Client Registration
Problems with RIS client registration that are discussed in this section
include the following topics:
• No prompt for client hardware address (Section 8.4.1)
• Duplicate client hardware addresses (Section 8.4.2)
• Cloned client registration (Section 8.4.3)
• Client registered on multiple RIS servers (Section 8.4.4)
• Client not in RIS database (Section 8.4.5)
8–2 Troubleshooting RIS
8.4.1 No Prompt for Client Hardware Address
The server requires a client’s hardware address in order to boot the client
over the network. The ris utility prompts you for the client’s address during
the registration process. If it does not, check the following:
• If the RIS area is linked to a CD
Check that the CD−ROM that is the target of the links is mounted.
• If the RIS area is serving a version of the operating system prior to
Version 3.0
Check that the mandatory update subsets are installed in the
server’s RIS area for the version of the operating system that is being
served. Install the mandatory update subsets from the
/ALPHA/UPDATE directory on the distribution CD−ROM. For example, if
the CD−ROM is installed on /mnt, install the mandatory update subsets
from the /mnt/ALPHA/UPDATE directory.
• If the RIS area is serving Version 3.0
Check that the mandatory operating system subsets are installed into
the RIS area. Install the mandatory subsets from the /local_mnt
/ALPHA/BASE directory on the distribution CD−ROM. For example, if
the CD−ROM is installed on /mnt, install the mandatory update subsets
from the /mnt/ALPHA/BASE directory.
• If the RIS area is serving Version 4.0 and later
Check that the OSFBASENNN subset is included in the RIS area and that
the client is registered for that RIS area.
−ROM
/local_mnt
8.4.2 Duplicate Client Hardware Addresses
RIS checks to ensure that no other client has the same hardware address.
This can happen if a client’s name has changed but has not been removed
from the server. If a duplicate hardware address is found, a message is
displayed like the one in the following example:
The hardware address provided, nn-nn-nn-nn-nn-nn, has already been
specified for another client, albany. Please check the hardware address
to ensure it is correct. If it is correct, then you will need to
deregister the client albany before continuing. If this client is not
currently registered, please contact your RIS system administrator.
If you see this message, follow the instructions provided and verify the new
hardware address that you entered.
• If the hardware address you entered is not correct, reregister the new
client with the correct hardware address.
Troubleshooting RIS 8–3
• If the hardware address you entered is correct, deregister and reregister
the existing client (in this example, albany).
• If the existing client is not registered, contact your RIS system
administrator.
8.4.3 Cloned Client Registration
A CDF is created during a Full Installation. To use the CDF for Installation
Cloning, the hardware configuration and the software subsets to load must
be substantially similar. Before specifying a CDF for client Installation
Cloning, RIS attempts to verify that the subsets specified in the CDF exist in
the RIS area that the user has selected. If they do not match, the CDF is
rejected. This error can occur if the version numbers of the subset do not
match (for example, OSFBASE400 and OSFBASE505).
• The CDF can be used for Installation Cloning of a system that is
registered to a different RIS area. In this first case, it is possible that the
subsets contained in these RIS areas are different.
• The version of the operating system served by the RIS area can be
different from the version specified in the CDF. In this second case, there
would be many missing subsets because none of the subsets specified in
the CDF would be present in the RIS area.
In the event that a CDF is specified that contains the name of a software
subset that is not present in the selected RIS area, you see output similar to
the following example:
Enter a set name or press <Return> to exit set selection: rz26.cdf
The selected CDF, rz26.cdf, specifies software subsets that are not
present in the selected RIS environment. The missing software subsets are:
OSFSERPC505
Please select a different set.
8.4.4 Client Registered on Multiple RIS Servers
If the system will not boot or the system boots but is not able to mount
the root file system, you should check to ensure that the RIS client is not
registered for BOOTP service on multiple RIS or DMS servers. In order
for the BOOTP protocol to work properly, it is important that the client be
registered for BOOTP service on only one server. The client is registered for
BOOTP service when it is registered for an operating system base product or
when it is registered as a DMS client.
It is possible for a RIS client to be registered to two RIS servers at the
same time, given they are not both registered for the operating system base
product on both servers and attempt to boot their systems using BOOTP.
8–4 Troubleshooting RIS
8.4.5 Client Not in RIS Database
If a message appears on the client’s console while you are performing a RIS
installation that states that the client is not in the RIS database, look at
the following on the server:
• As shown in Section 8.5, look at the
file to see if the client’s name is entered correctly. If it is not, use the
utility to add or modify the client’s registration.
_____________________ Note _____________________
Do not edit the risdb file directly; use the ris utility to add
clients or modify client registration.
• If the /var/adm/ris/clients/risdb file contains the correct client
name, you must determine the client’s name as recognized by the name
servers (for example, BIND or NIS). If no name servers are in use, check
the /etc/hosts file and the /var/adm/ris/clients/risdb file.
– The /etc/hosts file contains the client name recognized by the
server.
– The /var/adm/ris/clients/risdb file contains the client name
recognized by RIS.
The two names must match. If you are using BIND or NIS name servers,
use the nslookup command to find the name by which the client is
known to the server.
/var/adm/ris/clients/risdb
ris
Compare the /etc/hosts file and the /var/adm/ris/clients/risdb
files. If one uses short name and one uses the fully qualified domain
name, edit the /etc/hosts file to include both the short name and the
fully qualified domain name. This may solve the problem.
If the /etc/hosts file uses the short name and the
/var/adm/ris/clients/risdb file uses the fully qualified domain
name, you may have a network configuration error. Review the
procedures used to configure your network and name servers and correct
them before continuing RIS installations.
Troubleshooting RIS 8–5
8.5 RIS Server Response
Problems with RIS server response comprise several categories. The
following topics are discussed in this section:
• Servers using the bootpd daemon (Section 8.5.1)
• Servers using the joind daemon (Section 8.5.2)
• Loading an incorrect kernel file (Section 8.5.3)
Boot failures often occur because the RIS server has invalid information.
The risdb and bootptab files are involved in handling RIS clients, and you
should check them in the order listed:
• /var/adm/ris/clients/risdb
This file is created and managed by the ris utility; it contains the
utility’s view of the environment. Run the ris utility to show the
configuration for the client in question. Verify that the client is registered
and that its registration information is correct. If not, use the ris utility
to add or modify the client’s registration.
• /etc/bootptab (only on servers running this operating system)
This file is not used exclusively by RIS, so it can be edited for other
purposes (such as Dataless Management Services). The entry for your
client may be corrupted. Examine the client’s bootptab entry to ensure
that the entry agrees with both the risdb entry and the addresses and
parameters of the equipment in your environment. See bootptab
dhcptags
(4) and Section 5.1.3 for more information..
(4) and
_____________________ Caution _____________________
A RIS server should run either the bootpd or the joind daemon.
A RIS server running both of these daemons is not supported,
and results are unpredictable.
8.5.1 Servers Using the bootpd Daemon
A server can respond to BOOTP requests from clients. If the server’s
information is correct for the client but the server still fails to respond,
enable BOOTP message logging on the server :
1. Edit the server’s /etc/inetd.conf file.
2. Modify the line for bootps to include the −d option as a bootpd
command argument. For example:
bootps dgram udp wait root /usr/sbin/bootpd bootpd -d
8–6 Troubleshooting RIS
3. Use the following command to find the process IDs for the Internet
daemons. You see output similar to the following:
# ps x | grep -E "inetd|bootpd"
228 ?? I 0:00.93 /usr/sbin/inetd
243 ?? I 0:00.91 /usr/sbin/bootpd
9134 p2 S 0:00.23 grep -E inetd|bootpd
4. Send a HUP (hangup) signal to the inetd daemon so it will reread the
/etc/inetd.conf configuration file and kill the bootpd daemon.
You must kill the inetd daemon before you kill the bootpd daemon.
Using the process IDs you identified in the previous step, issue the
following kill commands:
# kill -HUP 228
# kill -KILL 243
It is not necessary to restart the bootpd daemon manually; the inetd
daemon starts it automatically.
To track boot requests as they occur, run the tail −f command on the
/var/adm/syslog.dated/today’s-date /daemon.log file and boot the
client. Many daemons other than the bootpd daemon log information to
the daemon.log file; however, the log file shows a hardware address that
matches the address in the /etc/bootptab file for the client.
If the client’s boot requests are not logged, you can enable additional logging
by editing the /etc/inetd.conf file, and add a second −d option to the
bootpd command. Each additional instance (up to three) of the −d option
increases reporting; the second instance enables the server to report all boot
requests, even for client systems it does not recognize. This level of reporting
should help you determine where in the system the request is being lost.
If you modify the /etc/inetd.conf file, restart the inetd daemon by
sending it a HUP signal. Example 8–1 shows a section of a daemon.log file.
It shows the data logged by various system daemons, including the bootpd
daemon when run with two −d flags set.
Example 8–1: Sample daemon.log File
Jul 28 14:56:36 stlouis mountd[191]: startup
Jul 28 14:56:38 stlouis xntpd[235]: xntpd version 1.3
Jul 28 14:56:43 stlouis mold[269]: mold (V1.10) initialization complete
Jul 28 14:56:44 stlouis evd[272]: E003-evd (V1.10) initialization complete
Jul 28 14:56:45 stlouis internet_mom[275]: internet_mom - Initialization
complete...
Jul 28 14:56:45 stlouis snmp_pe[278]: M004 - snmp_pe (V1.10) initialization
complete
Jul 28 16:34:55 stlouis inetd[282]: /usr/sbin/bootpd: exit status 0x9
Jul 28 16:35:47 stlouis bootpd[1228]: bootpd 2.1a #0: \ 3
Fri Feb 04 00:32:28 EST 2000
Jul 28 16:35:47 stlouis bootpd[1228]: reading "/etc/bootptab"
1
2
Troubleshooting RIS 8–7
Example 8–1: Sample daemon.log File (cont.)
Jul 28 16:35:47 stlouis bootpd[1228]: read 3 entries from "/etc/bootptab"
Jul 28 16:35:47 stlouis bootpd[1228]: request from hardware address \
nnnnnnnnnnnn
Jul 28 16:36:08 stlouis bootpd[1228]: request from hardware address \
nnnnnnnnnnnn
Jul 28 16:36:08 stlouis bootpd[1228]: found: host1.xsamplex.com (nnnnnnnnnnnn)
at (nn.nn.nnn.nnn)
Jul 28 16:36:08 stlouis bootpd[1228]: file /var/adm/ris/ris0.alpha/\
vmunix.host1.xsamplex.com
Jul 28 16:36:08 stlouis bootpd[1228]: vendor magic field is 0.0.0.0
Jul 28 16:36:08 stlouis bootpd[1228]: sending RFC1048-style reply
1 Many daemons log information to this file.
2 Result of sending a HUP signal to the inetd daemon and killing the
bootpd daemon.
3 A new bootpd daemon starts up in response to a boot request. The
bootpd daemon reads the /etc/bootptab file as a part of its startup.
4 A bootpd request by a system with hardware address nnnnnnnnnnnn.
Because the system is not a client of this RIS server, its hardware
address is not in the server’s /etc/bootptab file.
5 A bootpd request by a system with hardware address nnnnnnnnnnnn.
The system is a client of this RIS server.
8.5.2 Servers Using the joind Daemon
4
5
To serve BOOTP requests from clients, the joind daemon, which also
services Dynamic Host Configuration Protocol (DHCP) requests, should be
running. DHCP enables the automatic assignment of IP address to clients
on networks from a pool of addresses. The IP address assignment and
configuration occurs automatically whenever client systems (workstations
and portable computers) attach to a network. The current implementation of
DHCP is based on the JOIN product by Competitive Automation. Ensure
that the server’s information on the client is correct, namely information
contained in the bootptab file of the server as shown in Section 5.1.3. If
the server still fails to respond, enable logging of bootp messages on the
server by using the following procedure:
1. Enter the following command to check that the joind daemon is
servicing your bootp request:
# ps -x | grep -E "joind"
393 ?? I 0:05.82 /usr/sbin/joind
26446 ttyp0 S + 0:00.01 grep -e joind
8–8 Troubleshooting RIS
2. Enter the following command to determine the current setting of
JOIND_FLAGS:
# rcmgr get JOIND.FLAGS
3. Enter the following command to stop the joind daemon:
# /sbin/init.d/dhcp stop
4. Enter the following commands to restart the daemon with debugging
turned on. Use the JOIND_FLAGS argument to indicate debugging is
turned on.
# rcmgr set JOIND_FLAGS y -dx
Where x is the level of debugging. A value from 0 to 9 is valid.
Where y is the previously determined setting of the JOIND_FLAGS.
# /sbin/init.d dhcp start -dx
Example 8–1 shows a section of a daemon.log file with the data logged
by various system daemons, including the joind daemon.
5. Enter the following commands to turn off debugging:
# /sbin/init.d/dhcp stop
# rcmgr set JOIND_FLAGS y
Where y is the previous determined setting of the JOIND_FLAGS.
@ determined.
# /sbin/init.d dhcp start
8.5.3 Loading an Incorrect Kernel File
If the server responds but an incorrect kernel is loaded, it is possible that
the server’s RIS area is configured incorrectly. You can observe the loading
process by editing the /etc/inetd.conf file and restarting the Internet
daemon as described in the previous section. To do this, add the
−d option to
the line containing the tftpd command:
tftp dgram udp wait root /usr/sbin/tftpd tftpd -d /tmp /var/adm/ris
Logging the server’s tftp traffic shows you the file being transferred and the
time that the transfer starts and finishes. Ensure that the proper vmunix
file is being loaded and that the loading operations are completed correctly.
Troubleshooting RIS 8–9
9
Dataless Management Services
Dataless Management Services (DMS) lets client systems share the /usr
file system on a centrally administered server over a network while still
maintaining their own root (/) and /var file systems that reside on the
DMS server. With DMS, you can save disk space by sharing the actual
operating system software between systems. A DMS server stores the
operating system software in a DMS area. DMS clients access the operating
system software across the local area network (LAN) instead of from their
local disks. Without DMS, each system maintains a copy of its operating
system software on its own local hard disk.
______________________ Note _______________________
DMS is not supported in a clusters environment.
This chapter includes the following topics:
• Defining the DMS environment (Section 9.1)
• Listing the benefits of DMS (Section 9.2)
• Explaining the relationship between DMS servers and clients
(Section 9.3)
9.1 Overview
In a Dataless Management Services (DMS) environment, a server system
maintains the root, /usr, and /var file systems for all client systems. The
server maintains one copy of the root file system for each client. The /usr
file system is exported read only and is shared by all clients registered to the
environment. Client systems have their own /var file system. All swapping
and dumping is done on the client’s local disk.
The dataless management utility (dmu) creates a root file system based on
the software subsets installed in the DMS environment area on the server.
This root file system is accessed by client systems over a local area network
(LAN). DMS lets system administrators customize the root and /usr file
systems before client systems access them.
You must have superuser privileges to perform many of the dmu functions.
Dataless Management Services 9–1
9.2 DMS Benefits
The advantages of installing DMS include the following:
• Less disk space is required on client systems. By sharing the /usr area,
you eliminate the need for disk space to hold a separate /usr area for
each client. For Alpha systems, you can save more than 425 megabytes
(Mb) for each client.
• Installation and setup of servers and clients are done by automated
scripts, thereby simplifying the task of the server system administrator.
Maintenance of the DMS areas is similarly straightforward.
• Because the DMS files reside on the server, the server’s system
administrator can perform most system management tasks. The
involvement of individual users with the complexities of system
management is reduced.
9.3 Relationship Between DMS Servers and Clients
The DMS utility, dmu, manages the sharing of installed operating system
software between servers and clients in a LAN. In addition to the server’s
normal disk area, one or more disk partitions are reserved as the DMS area,
made up of one or more product environments and client areas. This section
includes the following topics:
• Describing the DMS server (Section 9.3.1)
• Explaining the environment portion of a DMS area (Section 9.3.2)
• Explaining the client portion of a DMS area (Section 9.3.3)
• Describing DMS client characteristics (Section 9.3.4)
9.3.1 DMS Server
The DMS server maintains multiple copies of the root area, one for
each client. Each copy is in a client root directory in the DMS area and
is customized for the client in order to provide for differences between
hardware platforms or environmental requirements. Each of the client root
directories is private; this means that there is a directory for each client so
that no conflict or confusion exists between clients. The server’s DMS root
and /usr areas are made available to clients by means of the Network File
System (NFS). For more information about the NFS used by the operating
system, see the Network Administration: Services manual.
Beyond verifying clients’ identities, vectoring their boot requests, and
providing their system disk space, the server does not interact directly with
the clients. The server can support local timesharing users and need not
be dedicated to DMS.
9–2 Dataless Management Services
A DMS client’s system disk space (root and /usr areas) is physically
connected to the server instead of to the client. The client accesses that
disk area through a LAN connection with the server. Each DMS client is
booted across the network from its private root area on the server. After it
is booted, the client continues to use its root files and /usr files from the
server’s DMS area. These files appear to the client as if they were on local
disks, as shown in Figure 9–1.
Figure 9–1: File Sharing Between the DMS Server and Client
Local Area Network
Server Client
Dataless
Area
Local
Disk
System
Disk
Local
Disk
As indicated in Figure 9–1, clients must have local disks. In addition to local
disks, clients can import file systems from any other computer to which they
have network access. Clients use swap and dump space on their local disks.
9.3.2 Environment Portion of DMS Area
One or more DMS environments can reside in a partition. If you want to
prevent the dmu utility from putting all DMS environments in the same disk
partition, indicate a unique mount point for each DMS environment. The
DMS environment disk space requirements should be calculated using the
worksheets in Appendix B. Then the mount point of ./dmsn.alpha should
be added to the /etc/fstab file.
Each DMS environment contains a customized directory and file system,
consisting of root, /usr, and /var. The dmu utility copies the root area to
the client area when a client is added to the dataless environment.
ZK-0934U-AI
Figure 9–2 shows the /var/adm/dms portion of a DMS area, it contains
two DMS environments, dms0.alpha and dms1.alpha. Each DMS
environment contains a root and /usr file system. The root file system is
Dataless Management Services 9–3
copied to each client system. The /usr file system is read only and is shared
among all client systems registered to the environment.
Figure 9–2: Environment Portion of DMS Area
/var/adm/dms
rootroot
dms1.alpha
shared
/usr
ZK-0935U-AI
dms0.alpha
shared
/usr
The root file system contains copies of the kernel, .vmunix, vmunix and
other primary system files. These primary files can be in either new form
(files supplied in the operating system distribution kit and prefixed with
.new..) or in prototype form (files prefixed with .proto..).
Do not customize the .new.. version of a file.
The .proto.. files have special significance for DMS environments. By
modifying the .proto.. files, you can customize the DMS server to meet
specific needs. You can use these customized .proto.. files when you
configure the DMS client environments. You also can modify standard files
such as /etc/hosts and /etc/fstab so that DMS clients do not have
to modify them.
The /usr file system contains common files that can be used without being
tailored by clients registered to the DMS environment.
DMS environments can be created with different combinations of products to
allow servers to provide diversified service based on client’s software product
needs. For example, you could have a DMS environment with only the base
operating system. Another DMS environment could have the base operating
system plus any number of additional products (such as DECLadebug or
DEC Fortran) installed. Multiple environment areas can be established
in separate partitions to support a variety of environments, or to improve
performance, or to support more clients than allowed by the disk space
available in the /var/adm/dms directory.
The server does not use any of the DMS area. System administrators can
access the DMS area as required for maintenance and for installation or
removal of layered products, but the area is not used by the server itself.
9–4 Dataless Management Services
9.3.3 Client Portion of DMS Area
A DMS client area for individual DMS client systems also resides in a
DMS area. Figure 9–3 shows a DMS client area named /clients. Place
this DMS client area in its own partition after you calculate the required
size with the worksheets in Appendix B. Next, add the mount point of the
/clients DMS client area to the /etc/fstab file.
Figure 9–3: DMS Client Area
/clients
Multiple copies of the root file system reside in the client area, one for
each client, tailored from the generic root file system. Each client builds a
customized kernel, which resides in the client’s root area if the client has
a partial or full build environment. This customized kernel supports the
client’s actual system configuration, including central processor, system
memory, and peripheral devices. Figure 9–3 shows two client root areas,
named ClientA and ClientB. Each client sees its private root area and the
shared /usr area from the /var/adm/dms environment as local, although
these areas are actually on the DMS server and are accessed through NFS.
Figure 9–4 shows how clients share /usr and have their own root file system.
ClientBClientA
ZK-0936U-AI
You can establish multiple client areas but they must reside in different
partitions.
9.3.4 Characteristics of DMS Clients
Clients do not have access to the entire DMS area. Each DMS client has
access to the root area assigned to it on the server.
Common system files residing in the /usr area are shared among all the
clients registered to that particular /var/adm/dms environment. Mounted
with read-only access for the clients, this shared area is protected from
erroneous client activity. Figure 9–4 shows this concept.
Dataless Management Services 9–5
Figure 9–4: Client Views of the DMS Area
Server
ClientA
Client A
root
/usr
shared
/usr
ClientB
Client B
root
/usr
ZK-0937U-AI
In Figure 9–4, the small boxes represent what the clients think they see;
the arrows show how the real disk areas on the server are mounted by the
client to produce this view.
Clients can be timesharing systems or workstations. Because each client’s
root area is tailored specifically to the client’s needs and would contain
the software the client can run, there is no interference between clients
attempting to use identical resources that could, for example, have licensing
restrictions based on the number of concurrent users.
9–6 Dataless Management Services
10
Preparing DMS Servers and Clients
This chapter describes how to get DMS servers and clients ready to run in a
dataless environment. Perform the following steps to prepare DMS servers
and clients:
1. Meet requirements for DMS servers. (Section 10.1)
2. Meet requirements for DMS clients. (Section 10.2)
3. Allocate disk partitions for DMS. (Section 10.3)
4. Set up a local area network. (LAN) (Section 10.4)
5. Set up a Network File System. (NFS) (Section 10.5)
6. Plan and calculate DMS disk space requirements. (Section 10.6)
7. Install the operating system software on the DMS server. (Section 10.7)
8. Register DMS clients. (Section 10.8)
9. Understand DMS security issues. (Section 10.9)
10.1 Requirements for DMS Servers
Setting up a dataless environment requires that the following conditions be
met for DMS servers:
• A DMS server must have Version 3.0 or higher of the operating system
installed to serve client systems with the current version of the operating
system. The server can be any Alpha-based processor, with the exception
of those noted in Section 1.2. A single server can serve both RIS and
DMS clients, but a client cannot be registered to both RIS and DMS at
the same time. DMS servers can serve only clients running Version 3.0
or higher of the operating system.
• The DMS server must have the following software subsets installed:
– Additional Networking Services (
– Dataless Management Services (OSFDMS)
• The DMS server must have the OSF-SVR or UNIX-SERVER Product
Authorization Key (PAK) loaded and registered. The OSF-SVR or
UNIX-SERVER license allows an Alpha-based system to be a server.
OSFINET)
Preparing DMS Servers and Clients 10–1
See Software License Management for more information about software
licensing.
• The DMS server must be able to install software into the DMS area:
– The DMS server can have a CD
subsets for one or more specific products from the CD−ROM to the
DMS area on the server.
– The DMS server can use a Network File System (NFS) mount point
to install software from a Remote Installation Services (RIS) area or
an operating system distribution CD−ROM from another processor.
See Section 4.5 for more information about using an NFS mounted
RIS area.
• The DMS server must have at least one separate disk partition where the
DMS environment and client areas reside. The root would not be large
enough for many
environment was added. Smaller disks may not hold an entire DMS area.
• NFS must be set up on the DMS server.
• The DMS server and all DMS clients must be connected to an Ethernet
or FDDI local area network (LAN).
client areas and var likely would fill up after one
−ROM drive to install software
10.2 Requirements for DMS Clients
Setting up a dataless environment requires that the following conditions be
met for DMS clients:
• DMS clients must have a disk drive large enough to accommodate dump
and swap file systems (approximately 200 Mb).
• DMS clients must be registered with the server in one of the following
ways:
– Register the DMS client through either the NIS naming service using
Network Information Service (NIS) or the BIND naming
service using BIND Configuration Application.
– Create an entry for the DMS client in the server’s /etc/hosts file
either by using Network Configuration Application or by
manual entry using a text editor.
10–2 Preparing DMS Servers and Clients
• DMS clients must be capable of booting over Ethernet or FDDI using the
bootp and tftp protocols. This is the same requirement to be able to
install the operating system from a RIS server. Most Alpha workstations
and deskside servers have this capability, but most data center servers
would not be configured as DMS clients. Look at your system’s hardware
documentation to determine whether it supports bootp and tftp over
Ethernet or FDDI.
• The client must not be registered on another RIS or DMS server.
10.3 Allocating Disk Partitions on the DMS Server
The DMS server must have at least one separate disk partition to contain
the DMS environment and client areas. Otherwise, the root file system is not
large enough for many client areas and the var file system would fill up
after one environment was added. Deciding how to allocate disk partitions
is critical to the performance of dataless management. Consider the
following factors when allocating disk partitions for the DMS environment
(/var/adm/dms/dms
• The number of physical blocks available compared to the number of
blocks required by the environments you expect to create on the disk.
• Spreading environments with large numbers of registered clients among
different disks to reduce disk contention.
• Protecting against disk failures by using the Logical Storage Manager
(LSM).
N .alpha) and client (/clients) area:
• Using the Advanced File System (AdvFS) on certain disks for faster
system recovery. See the
and Tuning, and System Administration manuals and advfs
information.
See the System Administration guide for more information about disk
partitioning.
AdvFS Administration, System Configuration
10.4 Setting Up a Local Area Network (LAN)
You must connect the DMS server and all of the client processors to an
Ethernet or FDDI LAN. For instructions on setting up a LAN, see the
Network Administration: Connections manual.
10.5 Setting Up a Network File System
The Network File System (NFS) must be set up before you install DMS. For
instructions on setting up NFS, see the Network Administration: Services
manual. After you install NFS, ensure the portmap, mountd, nfsd, and
nfsiod daemons are running by entering the following command:
Preparing DMS Servers and Clients 10–3
(4) for more
# ps ax | grep -E "portmap|mountd|nfsd|nfsiod"
If these daemons are not all running, start the inoperative ones. See the
appropriate reference pages for information about starting these daemons.
For example, enter the following command to display the
reference page:
# man portmap
10.6 Planning Disk Space for DMS
You must calculate the amount of disk space required to ensure that you
have enough space in the DMS areas in which the dmu utility will be created.
DMS clients’ system disk space is located on the server in a DMS area. See
Section 9.3.2 for a description of the DMS area’s contents. A server can have
multiple DMS areas in which some of the files (for example the contents
of the /usr area) are duplicated. This necessary duplication imposes
additional space requirements on the server.
This section discusses the following topics:
• Disk space required for DMS environments (Section 10.6.1)
• Estimating disk space for DMS clients (Section 10.6.2)
• The types of kernel builds (Section 10.6.3)
Throughout this guide, the server’s environment file systems are designated
as /var/adm/dms/dmsN .alpha and /clients/hostname where
hostname is the name of the client. The root areas are designated dmsN
.alpha where the letter N represents the number assigned to the specific file
system or common root area when it is installed. The client’s private portion
of the common root area is designated /clients/hostname.
portmap
(8)
Disk space is required on the server for each DMS server area file system.
The following sections provide guidelines for estimating the disk space
required by the DMS area.
Appendix B contains worksheets to help you calculate your space
requirements.
10.6.1 Disk Space Required for DMS Environments
Each dmsN .alpha environment must have the following software subsets
installed:
• Additional Networking Services (OSFINET)
• Dataless Management Services (OSFDMS)
10–4 Preparing DMS Servers and Clients
Each dmsN .alpha environment also can contain additional software for the
clients registered to access that environment. Section 11.2 describes how to
install software in DMS environments.
Reserve the following space in addition to space needed for the mandatory
subsets and the subsets required by DMS:
• Enough space for any layered products that you plan to install at any
time in the future
• An additional 10 percent of the required disk space to allow for file
system administration tasks and file system information
Appendix B contains worksheets for calculating the amount of space you
need for a single DMS environment. Look at the first worksheet as you read
the calculation illustrated in Table 10–1.
______________________ Note _______________________
Subset sizes in this example are for illustration only. The actual
sizes for standard operating system subsets are listed in the
Release Notes. Subset size information for layered products is
included in the product installation documentation.
To determine the names of the subsets you want to install, look at
to the descriptions listed in the Installation Guide.
Assume that you want to install all of the mandatory and optional subsets
plus one layered product. You need at least one DMS environment,
/var/adm/dms/dmsN .alpha.
For example, you look at the Release Notes and determine the estimated
subset sizes in Table 10–1:
Table 10–1: Estimated Subset Sizes for DMS
Subsets Size in Mb
Mandatory subsets
All optional subsets
One layered product subset
SUBTOTAL
+10 percent for overhead
TOTAL
250
400
50
700
70
770
The subset sizes add up to 700 Mb. Allowing another 10 percent of this
space (70 Mb) for file system administration and information, you arrive at
a total size of 770 Mb for the /var/adm/dms/dmsN .alpha environment.
Preparing DMS Servers and Clients 10–5
Reserve additional space for any other software products you plan to install
later. These products’ space requirements must be factored into the 10
percent overhead allocation.
10.6.2 Estimating Disk Space for Clients
You must reserve disk space in the /clients file system on the server for
clients’ root areas. The amount of disk space required depends upon the type
of kernel build you choose for the client.
See the second DMS worksheet in Appendix B to calculate the amount of
space needed for a /clients area.
10.6.3 Considering Types of Kernel Builds
When you are adding clients to a DMS environment, you have the option
to choose: no build, full build, or partial build kernel support. When
determining the amount of space required by a client, you must keep in mind
the type of build support you choose for the client.
Clients’ volatile files, such as those in the /tmp, /var/spool, /var/sys,
and /var/adm directories are located in the individual client’s root area.
The client’s root area requires a minimum of 40 Mb of disk space. Use the
following guidelines for estimating disk space requirements, in addition to
the 30 Mb minimum required by the client:
• No build support
This type of kernel build is not recommended. Providing no build area
means that the clients cannot build kernels and must run the Generic
DATALESS kernel supplied by the system administrator. No build
support is available only when the server and client are on the same
version of the operating system. Additionally, no build support kernel
build type does not allow the client to build a customized kernel. If you
choose no build support, you do not need to allow for extra disk space
other than the required minimum 30 Mb.
• Full build support
A full build area creates an entire /sys area for the client and consumes
the most disk space. You should select this option if the client modifies
kernel objects and performs kernel builds. If you choose a full build,
allow an additional 100 Mb for each client’s root area.
• Partial build support
Default for clients running Version 3.2C or higher of the operating system
A partial build area creates a build area that contains only configuration
data. All kernel objects are obtained from the server. You should select
this type of build if the client performs kernel builds but does not modify
10–6 Preparing DMS Servers and Clients
kernel objects. If you choose a partial build, allow an additional 15 Mb
for each client’s root area.
The space required by individual clients will not be the same, but you can
add all the needed spaces together to arrive at the total requirement for the
/clients area. You also must remember to reserve additional space for
clients that add files to their root areas.
10.7 Installing the Operating System on the DMS Server
The Installation Guide describes how to install the operating system and
describes the standard operating system software subsets. Subset sizes are
listed in the Release Notes.
The following optional software subsets must be installed on the server to
set up a DMS environment:
• Additional Networking Services (OSFINET)
• Dataless Management Services (OSFDMS)
To install these software subsets, you can follow either one of these
procedures:
• Perform a Full Installation and choose the OSFINET and OSFDMS subsets
along with any other subsets you choose to install.
• Perform a Full Installation with mandatory subsets only. After the
installation is complete, use the SysMan Menu to install the subsets
listed previously and any additional software subsets.
For information about using the SysMan Menu to load software subsets, see
the Installation Guide or sysman
10.8 Registering DMS Clients
Before you can use DMS to serve a client, you must register the client with a
network naming service and with the DMS server. You must perform the
following tasks to prepare to register clients:
1. Obtain information about each client (Section 10.8.1).
2. Fill out a copy of the DMS Client Setup Worksheet for each client
(Appendix B).
3. Register each client’s host name and IP (Internet Protocol) address
with the appropriate naming service, either by using the NIS or BIND
Configuration Application or by placing an entry for the client in
the server’s /etc/hosts file, see Section 10.8.2.
(8).
Preparing DMS Servers and Clients 10–7
10.8.1 Obtaining DMS Client Information
You need to know the following information about each processor you plan
to add as a client to a /var/adm/dms/dmsN .alpha environment and to
register the client with the appropriate naming service:
• The host name
Only lowercase letters (a-z), numerals (0-9), and the period ( . ) and
dash (-) characters are permitted in host names, which must begin
with a letter.
• The DMS environment and client areas to which you want to register
the client
• The client’s network interface type, subnet mask and gateway address
for this network interface
The gateway address is required when the server and client are on
different networks.
See the
about network interfaces, subnet masks and route for network.
• The client’s Ethernet or FDDI hardware address
See the Network Programmer’s Guide or Section 6.2 for information
about how to obtain hardware addresses.
• The swap device and partition and swap device drive type (swapping
is done on the client’s local disk)
See the Installation Guide — Advanced Topics for guidelines on planning
swap space on the client’s local disk. However, keep in mind that because
the /usr file system is not on the client’s local disk, you have much more
space on the client to allocate for swap space.
Network Administration: Connections manual for information
• The type of kernel build to be supported (full, partial, or none). See
Section 10.6.3 for a description of the types of kernel build support for
the client.
10.8.2 Registering Clients Host Names and IP Addresses
If the host system is served by any of the following naming services, check
with your site administrator to be sure that your clients are registered with
the appropriate naming service servers:
• The server’s /etc/hosts file
• Berkeley Internet Name Domain (BIND)
• Network Information Services (NIS), formerly called Yellow Pages (YP)
By using the Network Configuration Application, you can place each client
processor’s host name and IP (Internet Protocol) address in the /etc/hosts
10–8 Preparing DMS Servers and Clients
file when you initially set up your LAN. The Network Configuration
Application is described in the Network Administration: Connections
manual.
You also can place the host name and IP address in the /etc/hosts file by
using a text editor such as vi. The host name and IP address for each client
processor must be unique.
See the Network Administration: Services manual for information about
setting up NIS and the BIND Configuration Application.
10.9 Considering Security Issues
C2 security may be installed on the server and the clients. However, DMS
uses the bootp protocol, which is not a secure protocol. Therefore, your
dataless environments may not be secure.
Preparing DMS Servers and Clients 10–9
Setting Up a DMS Environment
This chapter describes how to use the dmu utility to add software to a DMS
environment and how to configure the environment. The following topics
are discussed:
• Ensuring version compatibility between DMS servers and clients
(Section 11.1)
• Installing software into a new DMS area (Section 11.2)
• Adding software into an existing DMS environment (Section 11.3)
• Customizing and configuring a DMS environment (Section 11.4)
• Installing WLS support in DMS (Section 11.5)
11.1 Ensuring DMS Server and Client Compatibility
If you are installing this version of the operating system into a DMS
environment and the DMS server is running a previous version of the
operating system, you must perform the following procedure:
11
1. Log in to the DMS server as root or use the su command to gain
superuser privileges.
2. Insert the Operating System Volume 1 CD-ROM into the drive, then
mount the CD-ROM.
• If your server is running the current version of the operating system,
use a command similar to the following example:
# mount -rd /dev/disk/cdrom0c /mnt
This example mounts a CD-ROM drive that is device 0 on the mount
point /mnt.
• If your server is running an earlier version of the operating system,
use a command similar to the following example:
# mount -rd /dev/rz4c /mnt
This 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 correct device name. The
mount point does not have to be /mnt.
See Section 1.3 if you do not know the CD-ROM drive’s unit number.
Setting Up a DMS Environment 11–1
3. Use the mount command to update DMS on the server, as in the
following example (using /mnt as the mount point):
# /mnt/isl/utilupdate -d -m /mnt
• In this example, the -d copies several files from the distribution
CD to the server’s /usr/sbin directory. This ensures DMU
compatibility with the operating system.
• The -m
this example, directory is /mnt, and is a required parameter.
This procedure copies 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 a DMU client. See Appendix C for
more information about the utilupdate utility.
If the utility finds existing *.pre-V operating system files on your system,
no copies are made. If the server is already running the current version of
the operating system (or higher), a confirmation is displayed and no copies
are made.
directory is the mount point of the distribution media. In
11.2 Installing Software in a New DMS Environment
You must install and configure all the software you plan to use in a
DMS environment before you can add clients to share the environment.
Section 11.3 describes how to install additional software into an existing
DMS environment.
Follow these steps to install software into a new dmsN .alpha environment.
Repeat the installation procedures for each dmsN .alpha environment you
plan to set up.
1. Log in as root or use the su command to gain superuser privileges.
2. Insert the Operating System Volume 1 CD-ROM into the drive, then
mount the CD-ROM.
• If your server is running the current version of the operating system,
use a command similar to the following example:
# mount -rd /dev/disk/cdrom0c /mnt
This example mounts a CD-ROM drive that is device 0 on the mount
point /mnt.
• If your server is running an earlier version of the operating system,
use a command similar to the following example:
# mount -rd /dev/rz4c /mnt
11–2 Setting Up a DMS Environment
This 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 correct device name. The
mount point does not have to be /mnt.
See Section 1.3 if you do not know the CD-ROM drive’s unit number.
____________________ Note _____________________
You can use a Network File System (NFS) mount point to
install software from a Remote Installation Services (RIS)
area or Operating System Volume 1 CD-ROM from another
processor.
See Section 4.5 for more information about using an NFS
mounted RIS area.
3. Enter /usr/sbin/dmu to start the dmu utility. You see the DMU Main
Menu:
*** DMU Main Menu ***
Choices without key letters are not available.
) ADD a client
) CONFIGURE software environments
) DELETE software environments
i) INSTALL software environments
) LIST registered clients
) MODIFY a client
) REMOVE a client
) SHOW software environments
x) EXIT
Enter your choice:
If this is the first time you have accessed dmu, there are no DMS
software environments installed. The only option you have is to install
software into an environment or to exit from the utility.
4. Enter i to select INSTALL software environments. You see the
DMS Software Installation Menu:
DMU Software Installation Menu:
1) Install software into a new area
2) Add software to an existing area
3) Perform configuration phase on an existing area
4) Return to previous menu
Setting Up a DMS Environment 11–3
Enter your choice:
5. Enter 1 to select Install software into a new area. You see
the following prompt:
You have chosen to establish a new remote dataless environment.
Enter the device special file name or the path of the directory where
the software is located (for example, /mnt/ALPHA/BASE):
6. Enter the software location, for example: /mnt/ALPHA/BASE.
• If your distribution media is CD
−ROM mounted on /mnt, the
directory where the software is located is /mnt/ALPHA/BASE.
• Enter a device specific file name only for magnetic tape media.
The dmu utility lists the mandatory and optional software subsets you
can install.
The following subsets must be installed in the DMS environment:
• Additional Networking Services
• Dataless Management Services
7. Select the subsets that you want to extract; the dmu utility displays your
list for confirmation. For example:
The following subsets are mandatory and will be installed
automatically unless you choose to exit without installing
any subsets:
{mandatory subset list}
Optional subsets are listed below. There may be more optional
subsets than can be presented on a single screen. If this is
the case, you can choose subsets screen by screen, or all at
once on the last screen. All of the choices you make will be
collected for your confirmation before any subsets are installed.
{optional subset list}
Or you may choose one of the following options:
94) ALL mandatory and all optional subsets
95) MANDATORY subsets only
96) CANCEL selections and redisplay menus
97) EXIT without extracting any subsets
Enter your choices or press RETURN to redisplay menus.
Choices (for example, 1 2 4-6):
The following subsets will be loaded:
{selected subset list - all mandatory & optional in this example}
.
.
.
.
.
.
.
.
.
.
.
.
94
.
.
.
11–4 Setting Up a DMS Environment
.
.
Are these the subsets that should be loaded (y/n) ?
.
If you enter y, the dmu utility loads the subsets. If you enter n, the list
of subsets is displayed again and you can restart your selection process.
The new DMS environment is located in the /usr/v ar/dms/dmsN.alpha
directory.
If there is not enough disk space to perform the installation, you see a
prompt similar to the following:
fitset:
file system /usr needs 74683 Kbytes more to install the software specified.
setld:
There is not enough file system space to install the mandatory subsets.
setld failed.
Error(s) have occurred during subset load. The subset(s) that failed
are listed above and have not been installed into the environment.
Possible causes for failure include subset dependencies that have
not been met or the lack of disk space.
You will now be asked if you wish to keep this environment.
If you elect to keep the environment, you may install the subsets that failed
by choosing INSTALL from the DMS main menu and select an existing environment.
If you elect not to keep the environment, it will be completely removed.
Keep this environment (y/n) [y]:
• If you want to keep the new DMU environment, enter
y.
• If not, enter n, and the dmu utility terminates the installation and
returns to the DMU Main Menu. Either resize your disk partitions or
select fewer optional software subsets.
After the installation of software subsets is complete, the dmu utility displays
the name of the new DMS environment. If this is the first DMS environment,
it automatically is named dms0.alpha. Subsequent DMS environments are
numbered sequentially: the next environment is named dms1.alpha, the
one after that is named dms2.alpha, and so on.
If you delete an environment, for example dms4.alpha, the next time you
install a DMS environment, the dmu utility reuses the number 4 to name the
environment. The utility fills the holes left in the numbering sequence by
environments that have been deleted.
After you install software into the DMS environments, you must configure
and build the kernel for that environment. See Section 11.4.2 for instructions
on how to begin the kernel configuration phase. However, if you want to
add additional software to the environment before configuring the kernel,
see Section 11.3.
Setting Up a DMS Environment 11–5
11.3 Adding Software to an Existing DMS Environment
Perform the following steps to add software to an existing DMS environment:
1. Log in as root to each DMS client registered to the DMS environment
or use the su command to gain superuser privileges.
2. Use the shutdown command to shut down the DMS client.
___________________ Caution ___________________
If DMS clients that mount the usr area of the target
/var/adm/dms/dmsN .alpha area are running when you
install an additional software product, their usr area may
change unpredictably and cause destruction of software or
data or both.
Repeat this step for each DMS client registered to the DMS environment
where you are adding software.
3. Log in as root to the DMS server or use the su command to gain
superuser privileges.
4. Mount the CD-ROM that contains the software you want to install as
shown in Section 11.2, or mount the file system area that contains the
software kits.
5. Enter
/usr/sbin/dmu to start the dmu utility. You see the DMS Main
Menu:
*** DMU Main Menu ***
Choices without key letters are not available.
a) ADD a client
c) CONFIGURE software environments
d) DELETE software environments
i) INSTALL software environments
l) LIST registered clients
m) MODIFY a client
r) REMOVE a client
s) SHOW software environments
x) EXIT
Enter your choice:
11–6 Setting Up a DMS Environment
Loading...