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
Contents
About This Manual
1 Introduction to Sharing Software
1.1
1.2
1.3
Overview ...............................................................
Understanding the Software Sharing Environment ............
Identifying a CD-ROM Drive Device Name .......................
1–1
1–2
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 ............................
RIS Client Characteristics ...........................................
Registering Clients ...................................................
Identifying a Client Hardware Network Address ................
2–1
2–3
2–3
2–4
2–5
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 ............
Planning Disk Space for RIS ........................................
Installing the Operating System on the RIS Server .............
Setting Up a Local Area Network ..................................
Loading and Registering the Server Extensions License .......
Preparing RIS for C2 Security ......................................
3–1
3–3
3–3
3–4
3–4
3–5
4 Setting Up a RIS Area
4.1
4.2
4.3
4.4
4.5
4.6
Overview ...............................................................
Installing Software into a New RIS Area .........................
Installing Software into an Existing RIS Area ...................
Including Hardware Product Kits into a RIS Area ..............
Using a RIS Area Mounted on NFS ................................
Modifying the /etc/exports File ......................................
4–1
4–1
4–5
4–7
4–10
4–10
Contents iii
5 Booting a RIS Client
5.1
Remote Boot Files and Daemons ...................................
The Internet Daemon and Configuration File ...............
The BOOTP Daemon ............................................
The /etc/bootptab File ............................................
The tftpd Daemon ................................................
Remote Boot Process Flow ...........................................
5–1
5–2
5–2
5–2
5–4
5–4
5.1.1
5.1.2
5.1.3
5.1.4
5.2
6 Managing RIS Clients and Environments
6.1
Preregistration Tasks ................................................
Obtaining Information About Each Client ...................
Registering Client Host Names and IP Addresses ..........
Adding a RIS Client with the ris Utility ..........................
Adding a RIS Client from the Command Line ...................
Modifying RIS Clients ................................................
Removing RIS Clients ................................................
Listing Registered RIS Clients .....................................
Listing Products in RIS Server Areas .............................
Deleting Products from RIS Server Areas ........................
Correcting RIS Gateways File Entries ............................
6–1
6–1
6–2
6–2
6–7
6–7
6–9
6–10
6–11
6–12
6–13
6.1.1
6.1.2
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
7 Managing RIS Profile Sets
7.1
7.2
7.3
7.4
7.5
7.6
7.7
Overview ...............................................................
Creating Profile Sets .................................................
Registering Clients for Profile Sets ................................
Converting Old Configuration Description Files .................
Determining RIS Client Profile Set Registration ................
Removing RIS Client Profile Set Registration ...................
Deleting Profile Sets from the RIS Server ........................
7–1
7–2
7–3
7–5
7–6
7–6
7–6
8 Troubleshooting RIS
8.1
8.2
8.3
8.4
8.4.1
8.4.2
8.4.3
RIS Lock Files .........................................................
Client Password Expiration .........................................
Root File System Mounting .........................................
RIS Client Registration ..............................................
No Prompt for Client Hardware Address .....................
Duplicate Client Hardware Addresses ........................
Cloned Client Registration .....................................
8–1
8–2
8–2
8–2
8–3
8–3
8–4
iv Contents
8.4.4
8.4.5
8.5
8.5.1
8.5.2
8.5.3
Client Registered on Multiple RIS Servers ..................
Client Not in RIS Database ....................................
RIS Server Response .................................................
Servers Using the bootpd Daemon ............................
Servers Using the joind Daemon ..............................
Loading an Incorrect Kernel File ..............................
8–4
8–5
8–6
8–6
8–8
8–9
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 ................
DMS Server .......................................................
Environment Portion of DMS Area ............................
Client Portion of DMS Area ....................................
Characteristics of DMS Clients ................................
9–1
9–2
9–2
9–2
9–3
9–5
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
Requirements for DMS Servers .....................................
Requirements for DMS Clients .....................................
Allocating Disk Partitions on the DMS Server ...................
Setting Up a Local Area Network (LAN) ..........................
Setting Up a Network File System .................................
Planning Disk Space for DMS ......................................
Disk Space Required for DMS Environments ...............
Estimating Disk Space for Clients ............................
Considering Types of Kernel Builds ...........................
Installing the Operating System on the DMS Server ...........
Registering DMS Clients ............................................
Obtaining DMS Client Information ...........................
Registering Clients Host Names and IP Addresses .........
Considering Security Issues .........................................
10–1
10–2
10–3
10–3
10–3
10–4
10–4
10–6
10–6
10–7
10–7
10–8
10–8
10–9
10.8
10.8.1
10.8.2
10.9
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 ................
Installing Software in a New DMS Environment ................
Adding Software to an Existing DMS Environment .............
Configuring DMS Environments ...................................
Customizing /etc/.proto..* Files ................................
Configuring the DMS Environment ...........................
Installing WLS Support in DMS ...................................
11–1
11–2
11–6
11–9
11–9
11–11
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–12
11–13
11–13
12 Managing DMS Clients and Environments
12.1
12.2
12.3
12.4
12.5
12.6
12.7
12.8
DMS Client Database File ...........................................
Adding a DMS Client .................................................
Booting a DMS Client ................................................
Deleting a Software Environment ..................................
Modifying Client Information .......................................
Removing a Client ....................................................
Listing DMS Clients ..................................................
Showing Software Environments ..................................
Maintaining the DMS Environment ...............................
Controlling Root File System Growth .........................
Listing Installed Software Subsets ............................
Removing Subsets ................................................
12–1
12–2
12–6
12–7
12–9
12–11
12–12
12–13
12–14
12–14
12–14
12–15
12.9
12.9.1
12.9.2
12.9.3
13 Troubleshooting DMS
13.1
13.2
13.3
13.4
13.5
13.6
13.7
Removing DMS Lock Files ..........................................
Checking NFS Server Status .......................................
Checking Network Daemon Status ................................
Checking Directory Exports .........................................
Checking Version Compatibility ....................................
Correcting Swap Device Problems .................................
Reconfiguring for a Hardware Update Release ..................
13–1
13–2
13–2
13–2
13–3
13–3
13–4
A RIS Worksheet
B DMS Worksheets
C Using the utilupdate Utility
D Hardware Update Releases in DMS
D.1
D.2
Overview ...............................................................
Installing a Hardware Release into a DMS Area ................
D–1
D–2
vi Contents
Glossary
Index
Examples
5–1
6–1
7–1
8–1
Sample /etc/bootptab File ............................................
Sample /var/adm/ris/gateways File ................................
Sample RIS Client Profile Set Registration ......................
Sample daemon.log File ..............................................
5–3
6–14
7–3
8–7
Figures
2–1
2–2
9–1
9–2
9–3
9–4
RIS Server and Client ................................................
Sample RIS Area Overview .........................................
File Sharing Between the DMS Server and Client ..............
Environment Portion of DMS Area ................................
DMS Client Area ......................................................
Client Views of the DMS Area ......................................
2–2
2–4
9–3
9–4
9–5
9–6
Tables
5–1
10–1
11–1
Remote Boot Files and Daemons ...................................
Estimated Subset Sizes for DMS ...................................
List of /etc/.proto.* Files .............................................
5–1
10–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 /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.
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)
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
what they are and how they work together. It also describes
the basic architecture of the server/client environment.
Chapter 2
Chapter 3
Chapter 4
Chapter 5
Describes the relationship between the RIS
server and RIS clients.
Lists the formats in which distribution media are available
and describes the preliminary setup procedures for RIS.
Describes the procedure for setting up a RIS server,
including installing and updating software.
Describes networking-related files and daemons used
by the remote installation services (ris) utility and the
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.
Chapter 6
Chapter 7
Chapter 8
Chapter 9
Describes how to manage profile sets to support Full
Installation and Installation Cloning.
Provides information on troubleshooting RIS
client problems.
Introduces DMS and the dataless manage-
ment utility (dmu).
Chapter 10
Chapter 11
Describes how to prepare a server system for DMS.
Describes the steps necessary to configure a DMS server
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.
Chapter 12
Chapter 13
Provides information on troubleshooting DMS
client problems.
Appendix A
Appendix B
Contains a worksheet to use when you install RIS.
Contains worksheets to calculate space require-
ments on DMS servers and clients, and a DMS
client setup worksheet.
x
About This Manual
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.
Appendix C
Appendix D
Describes how to install a hardware update release into a
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
S
Manuals for general users
Manuals for system and network administrators
Manuals for programmers
P
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: [email protected]
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.
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.
#
A number sign represents the superuser prompt.
% cat
Boldface type in interactive examples indicates
typed user input.
file
Italic (slanted) type indicates variable values,
placeholders, and function argument names.
[| ]
{| }
In syntax definitions, brackets indicate items that
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.
cat(1)
A cross-reference to a reference page includes
the appropriate section number in parentheses.
For example, cat(1) indicates that you can find
information on the cat command in Section 1 of
the reference pages.
Return
In an example, a key name enclosed in a box
indicates that you press that key.
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
1
Introduction to Sharing Software
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.
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 LANto 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-------
brw-------
#
1 root
1 root
system
system
19, 69 Nov 18 06:11 /dev/disk/cdrom0a
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(8) for more information.
1–4 Introduction to Sharing Software
2
Remote Installation Services
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.
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
kit/isl
Client Installation
Tools
subsets
subsets
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 LANas 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(8) for more information.
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.
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) at xx-xx-xx-xx-xx-xx
2–6 Remote Installation Services
3
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.
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−ROM, you might want to create symbolic links from the RIS
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.
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(8), the Software License Management manual, and the
License Manager online help for more information about registering license
PAKs.
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
4
Setting Up a RIS Area
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
This chapter describes how to use the ris utility’s menu-driven interface.
Chapter 6 describes how to use individual ris commands. See ris(8) for
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
•
•
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): 74
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)
?
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 ris utility lets you include hardware
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 Guide to
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.
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 nnn)’
with ’MYVGASTATIC software version 1’
’MYVGASTATIC software version 1’
2
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
5
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)
The TFTP daemon tftpd (Section 5.1.4)
See the following reference pages for more information:
bootptab(4)
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
Contains information needed to boot remote clients
Contains start-up information for various
internet daemons
/sbin/init.d/dhcp
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
The Internet server daemon
The BOOTP server daemon (handles both BOOTP
and DHCP requests, if configured)
/usr/sbin/tftpd
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 : 3
.ris93.alpha:tc=.ris.dec:bf=/ris/ris93.a/vmunix: \
rp="ds9:/ris/ris93.a/product_001": 4
1
2
The .ris.dec entry defines characteristics common to all clients. The
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
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(4) for
information about valid tg tags.
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(1) and tftpd(8) for more
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
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/risN.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
6
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
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(4) for more information about the
/etc/hosts file.
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
1
Description
’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
1
Description
’Tru64 UNIX V5.1A Operating System (Rev nnn )’ with
’MYVGASTATIC software version 1’
’MYVGASTATIC software version 1’
2
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
2
’Tru64 UNIX V5.1A Operating System (Rev nnn )’ with
’MYVGASTATIC software version 1’
’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
1
Description
’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
’Product 03’
’Product 04’
1
2
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, host-
and 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, or rcp.
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
2
’Operating System Release N ( Rev nnn )’
’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:
1) Ethernet or FDDI
2) Token Ring
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
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: subsetname1 subsetname2 subsetname3
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:
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 Return to register the client without
specifying a profile set.
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
8
Troubleshooting RIS
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:
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
0:00.00 grep mountd
root 3154 1053 0.0 12:52:55 ttyp3
#
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(8) and nfssetup(8) for
more information.
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−ROM
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 /local_mnt
/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.
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 /var/adm/ris/clients/risdb
file to see if the client’s name is entered correctly. If it is not, use the ris
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.
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(4) and
dhcptags(4) and Section 5.1.3 for more information..
_____________________ 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 ??
243 ??
9134 p2
I
I
S
0:00.93 /usr/sbin/inetd
0:00.91 /usr/sbin/bootpd
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
1
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
2
Jul 28 16:35:47 stlouis bootpd[1228]: reading "/etc/bootptab"
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 \ 4
nnnnnnnnnnnn
Jul 28 16:36:08 stlouis bootpd[1228]: request from hardware address \ 5
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
2
Many daemons log information to this file.
Result of sending a HUP signal to the inetd daemon and killing the
bootpd daemon.
3
4
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.
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
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 JOINproduct 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 ??
26446 ttyp0
I
0:05.82 /usr/sbin/joind
0:00.01 grep -e joind
S +
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 LANconnection 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
System
Disk
Dataless
Area
Local
Disk
Local
Disk
ZK-0934U-AI
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.
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
dms1.alpha
dms0.alpha
shared
/usr
shared
/usr
root
root
ZK-0935U-AI
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
ClientA
ClientB
ZK-0936U-AI
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.
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
shared
/usr
ClientA
ClientB
Client A
Client B
root
root
/usr
/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 (OSFINET)
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.
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−ROM drive to install software
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 client areas and var likely would fill up after one
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).
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/dmsN .alpha) and client (/clients) area:
•
•
•
•
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).
Using the Advanced File System (AdvFS) on certain disks for faster
system recovery. See the AdvFS Administration, System Configuration
and Tuning, and System Administration manuals and advfs(4) for more
information.
See the System Administration guide for more information about disk
partitioning.
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
# 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 portmap(8)
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.
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
250
Mandatory subsets
All optional subsets
One layered product subset
SUBTOTAL
400
50
700
70
+10 percent for overhead
TOTAL
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(8).
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.
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 Network Administration: Connections manual for information
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.
•
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
11
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:
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 directory is the mount point of the distribution media. In
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.
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): 94
The following subsets will be loaded:
.
.
.
{selected subset list - all mandatory & optional in this example}
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
6. Enter ito 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
Enter your choice:
7. Enter 2to select Add software to an existing area. You see a
prompt similar to the following:
You have chosen to add a product to an existing environment.
The existing environment is /var/adm/dms/dms0.alpha.
____________________
Note _____________________
In the previous example, only one environment, dms0.alpha,
exists. If you have more than one DMS environment, you see
a prompt similar to the following:
Select the remote dataless environment:
1) /var/adm/dms/dms0.alpha
’Tru64 UNIX VAAA Operating System (Rev nnn)’
2) /var/adm/dms/dms1.alpha
’Tru64 UNIX VBBB Operating System (Rev nnn)’
Enter your choice:
Enter the number corresponding to the DMS environment
where you want to install the software.
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):
8. 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 dmuutility lists the mandatory and optional software subsets you
can install.
Setting Up a DMS Environment 11–7
9. Select the subsets that you want to extract; the dmuutility 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:
24) ALL mandatory and all optional subsets
25) MANDATORY subsets only
26) CANCEL selections and redisplay menus
27) EXIT without extracting any subsets
Enter your choices or press RETURN to redisplay menus.
Choices (for example, 1 2 4-6): 24
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) ?
If you enter y, the dmuutility loads the subsets. If you enter n, the list
of subsets is displayed again and you can restart your selection process.
The dmuutility installs the software subsets that you selected. This
can take an hour or more.
After the dmuutility installs the software, you see the DMU Main Menu.
10. Follow the instructions in Section 12.4 to delete the DMS clients
registered to the DMS area where you installed the software.
11. Follow the instructions in Section 11.4.2 to reconfigure the DMS area
where you installed the software.
12. Follow the instructions in Section 12.2 to add the DMS clients deleted
in the previous step to the DMS area where you installed the software.
When you remove and add clients to the reconfigured environment,
customized information in the root (/) directory is lost.
11–8 Setting Up a DMS Environment
11.4 Configuring DMS Environments
After you install software into a new or existing DMS environment, you
must configure the environment. Configuring the environment includes the
following steps:
1. Customizing the .proto.. system files (Section 11.4.1). This step is
optional; you do not have to customize these files for the environment.
This step is performed outside of the dmuutility.
2. Building the environment’s kernel (Section 11.4.2). This step is
mandatory and is performed through the CONFIGURE software
environmentsoption of the DMU Main Menu.
11.4.1 Customizing /etc/.proto..* Files
If you already have configured the DMS environment and later decide to
modify .proto.. files, you must delete the files created by the configuration
process. Follow these steps to modify the fstabfile to include a server name:
1. Log in to the DMS server as rootor use the sucommand to gain
superuser privileges.
2. Define the DMS_ROOTenvironment variable to point to the affected DMS
area, for example:
# DMS_ROOT=/var/adm/dms/dmsN.alpha/root
3. Delete the $DMS_ROOT/hostsfile.
4. Modify the $DMS_ROOT/.proto..hostsfile.
5. Use the dmuutility to configure the DMS area as described in
Section 11.4.2.
Modify the .proto.. files to customize each environment for the clients
that you will add to a DMS environment. If you do this customization
before you configure and build the kernel and before you add clients to the
DMS environment, you reduce the amount of customization required at
each client.
You may want to modify several of the .proto.. files located in
the DMS environment /var/adm/dms/dmsN .alphain the /etc,
/bin, /var/adm/X11, and root directories. As an example, the
/etc/.proto..hostsfile is a file that you could modify in advance.
Table 11–1 lists the .proto.. files in the /etcdirectory that you can
customize.
Setting Up a DMS Environment 11–9
Table 11–1: List of /etc/.proto.* Files
.proto..TIMEZONE
.proto..lprsetup.dat
.proto..magic
.proto..acucap
.proto..autopush
.proto..binlog.conf
.proto..conf
.proto..motd
.proto..networks
.proto..ntp.conf
.proto..passwd
.proto..ddr.db
.proto..ddr.dbase
.proto..dhcptab
.proto..dvrdevtab
.proto..exports
.proto..phones
.proto..profile
.proto..proto.disktab
.proto..protocols
.proto..rc.config
.proto..remote
.proto..fstab
.proto..ftpusers
.proto..gen_databases
.proto..gettydefs
.proto..group
.proto..rpc
.proto..securettys
.proto..services
.proto..shells
.proto..hosts
.proto..slhosts
.proto..hosts.equiv
.proto..ifaccess.conf
.proto..inet.local
.proto..inetd.conf
.proto..inittab
.proto..stresetup.conf
.proto..svc.conf
.proto..sysconfigtab
.proto..syslog.conf
For example, the /etc/.proto..hostsfile contains no host names. Edit
this file to include the network addresses, names, and aliases of well-known
systems in your environment. Enter server information so that you do not
have to enter this information for each client when setting up network
services. See hosts(4) for more information about the layout of this file.
You should list commonly mounted NFS file systems, as well as the /proc
file system if it will be used by clients. When you add NFS file systems
to the etc/.proto..fstabfile, you also should add the hosts to the
etc/.proto..hostsfile. If the NFS mount points are in the client root
partition, make the directory mount points in the DMS root area as well. If
they are in the shared usrdirectory structure, make the directory mount
points in the DMS usrdirectory area.
After you modify the .proto.. files in the DMS environment, configure the
DMS environment by following the steps in Section 11.4.2.
11–10 Setting Up a DMS Environment
11.4.2 Configuring the DMS Environment
After you modify the .proto.. files, use the following procedures to
configure the DMS environment:
1. Log in to the DMS server as rootor use the sucommand to gain
superuser privileges.
2. Enter /usr/sbin/dmuto start the dmuutility. You see the DMU Main
Menu:
*** DMU Main Menu ***
) ADD a client
c) CONFIGURE software environments
d) DELETE software environments
i) INSTALL software environments
) LIST registered clients
) MODIFY a client
) REMOVE a client
s) SHOW software environments
x) EXIT
Enter your choice:
3. Enter cto select CONFIGURE software environments. You see a
prompt similar to the following example, which contains two DMS areas:
You have chosen to configure an existing dataless
environment.
Select the remote dataless environment:
1) /var/adm/dms/dms0.alpha
’Tru64 UNIX VAAA Operating System (Rev nnn)’
2) /var/adm/dms/dms1.alpha
’Tru64 UNIX VBBB Operating System (Rev nnn)’
Enter your choice:
4. Enter the number corresponding with the DMS environment you want
to configure. You see the following prompt:
There are several files prefixed by .proto.. within the
environment area that should be modified before performing
a configuration of the area. Performing this customization
of the environment before you register clients will reduce the
amount of customization required at each client.
You may now choose to continue with the configuration or return
to the main menu and exit to perform customization of the
Setting Up a DMS Environment 11–11
environment.
Do you want to (c)ontinue or (r)eturn to the main menu? (c/r)
[c]:
•
If you enter r, the dmuutility returns to the DMU Main Menu to let
you exit the dmuutility and modify the /etc/.proto.. files.
•
If you enter cto continue, the dmuutility displays progress messages
as it configures each software subset, similar to the following output:
Configuring "Base System " (OSFBASE505)
Configuring "Base System-Hardware Support" (OSFHWBASE505)
.
.
.
{subset list}
.
.
.
Configuring "Remote Installation Service" (OSFRIS505)
Configuring "Dataless Management Services" (OSFDMS505)
After you have created at least one DMS environment, installed software,
customized the .proto.. files, and configured the DMS environment, you
can add clients to the environment as discussed in Chapter 12.
11.5 Installing WLS Support in DMS
This section tells you how to install WLS support in DMS, and includes
the following topics:
•
•
•
Setting up a DMS server for WLS (Section 11.5.1)
Setting up a DMS client for WLS (Section 11.5.2)
Building an Asian kernel for DMS clients (Section 11.5.3)
11.5.1 Setting Up a DMS Server for WLS
Follow these steps to create a new dmsN .alphaenvironment and install
WLS software from a base operating system CD-ROM:
1. Log in to the DMS server as rootor use the sucommand to gain
superuser privileges.
2. Install the operating system into a DMS area before installing the
Worldwide Language Support (WLS) software.
3.
Load the CD-ROM containing the WLS subsets into your CD-ROM
drive and enter a mountcommand similar to the following:
mount -dr -t cdfs -o rrip /dev/disk/cdrom0c /mnt
4. Enter /usr/sbin/dmuto start the dmuutility. You see the DMU Main
Menu.
11–12 Setting Up a DMS Environment
5. Select INSTALL software environments. You see the DMU
Software Installation Menu.
6. Select Add software to an existing area.
If you have more than one DMS environment, you see a list of available
DMS environments and you are prompted to select the environment
for adding software.
7. Select the DMS area where the operating system is installed. You are
prompted for the location of the software.
8. Enter the full pathname of the device special file or mount points for
the distribution media. Enter /mnt/ALPHA/WORLDWIDEto install WLS
subsets. You see a menu listing the countries for which you can install
worldwide language support.
9. Select the software to support the countries that you want to install.
You see a list of available subsets.
See Section 11.3 for instructions on installing subsets.
After installing the subsets, you see the DMU Main Menu.
10. Select CONFIGURE software environmentsto configure newly
installed subsets into the DMS environment.
See Section 11.4.2 for instructions on configuring DMS environments.
11.5.2 Setting Up a DMS Client for WLS
After you have set up the DMS areas and registered the clients, they can
access the configured areas. See Section 10.8 on how to register the client
with a network naming service. You must register the client with the full
or partial (default) kernel option for the client to use the Asian kernel
functionality.
11.5.3 Building an Asian Kernel for DMS Clients
When the DMS client boots for the first time from a newly configured DMS
area, an Asian kernel is built. Reboot the system if you want to use the
Asian terminal driver functions. You also can reconfigure the Asian kernel
on the client machine by using the wwconfigcommand as follows:
# /usr/sbin/wwconfig -a
See the Installation Guide — Advanced Topics and wwconfig(8) for more
information about using the wwconfigcommand.
Setting Up a DMS Environment 11–13
12
Managing DMS Clients and Environments
This chapter describes how to use the dmuutility to manage Dataless
Management Services (DMS) environments and clients. The information in
this chapter includes the following topics:
•
•
•
•
•
•
•
•
•
Locating and interpreting the DMS client database file (Section 12.1)
Adding a client to a DMS environment (Section 12.2)
Booting a DMS client (Section 12.3)
Deleting a DMS environment (Section 12.4)
Modifying a DMS client (Section 12.5)
Removing a DMS client (Section 12.6)
Listing registered DMS clients (Section 12.7)
Showing software environments in the server’s DMS area (Section 12.8)
Maintaining the server’s DMS areas (Section 12.9)
12.1 DMS Client Database File
The DMS client database is located in the /var/adm/dms/clients/dmsdb
file. Entries in this file are similar to the following:
client1:xx-xx-xx-xx-xx-xx:/var/adm/dms/dms0.alpha:/clients/client1:
rz0b:RZ26:None:ln0:255.255.255.0
In this example:
• client1is the client’s host name
•
xx-xx-xx-xx-xx-xx is the client’s hardware network address
• /var/adm/dms/dms0.alphais the DMS environment being served
to the client
• /clients/client1is the location of the client’s root area
• rz0bis the client’s swap device and partition
• RZ26is the swap disk
• Nonespecifies the client has no kernel build area
• ln0is the network interface type
• 255.255.255.0is the network subnet mask
Managing DMS Clients and Environments 12–1
When you use add, modify, or delete a DMS client from the DMU Main Menu,
the client’s entry in the dmsdbfile is added, modified, or deleted, respectively.
12.2 Adding a DMS Client
The information you need to add a DMS client is shown in the Client Setup
Worksheet in Appendix B. Fill out a worksheet for each client you want to
add before you use the dmuutility to add clients to a DMS environment.
Before you can add a client, you already must have followed the procedures in
Chapter 11 to install software in at least one DMS environment. Optionally,
you may want to customize the .proto.. files as described in Section 11.4.1.
The DMS client must be connected to a local area network (LAN) and must be
registered with the DMS server through one of the network naming services
(see Section 10.8) or must have an entry in the server’s /etc/hostsfile.
When you add a client to a DMS environment, the root directory from the
server’s DMS environment gets copied to the client area.
Follow these steps to add a client to a DMS environment:
1. Log in to the DMS server as rootor use the sucommand to gain
superuser privileges.
2. Enter /usr/sbin/dmuto start the dmuutility. You see the DMU Main
Menu:
*** DMU Main Menu ***
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:
3. Enter ato select ADD a client. You see a prompt similar to the
following:
You have chosen to add a client for dataless service.
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).
12–2 Managing DMS Clients and Environments
3. You must know the client’s interface type, subnet
mask.
4. You must know the type of kernel build area.
5. You must know the swap device and partition on the
client.
6. You must know the client’s hardware Ethernet or FDDI
address.
7. If the client and the server reside on different subnets,
you will need the address of the gateway(s) that the
client can sue to communicate with the server.
Do you want to continue? (y/n) [y]:
4. Enter yto continue. You see the following prompt:
Enter the client processor’s hostname or press RETURN to quit:
5. Enter the host name for the DMS client.
If you enter a host name that is not in the server’s host database, you
see a message similar to the following:
arp failed on hostname "client1"
In the above message, arpis the Address Resolution Protocol. If you
receive this message, check the /etc/hostsfile to determine the
correct host name. If the client was never registered with a network
naming service (such as BIND or NIS) or was never entered in the
/etc/hostsfile, press Ctrl/C to exit the dmuutility and manually add
the client to the /etc/hostsfile before you restart the procedure.
____________________
Note _____________________
For the remaining examples, assume that the Return key is
pressed to accept the default response.
You see a prompt similar to the following:
Enter the path to contain the root file system. [/clients/client1]:
6. Enter a path, or press Return for the default, /clients/hostname. If
you specify a path other than the default , the directories in that path
already must exist. The path must begin with /clients, and can be no
longer than 25 characters.
For example, if you want to differentiate between client
systems in different departments at your site, you could specify
/clients/deptname/hostname as the root location. The deptname
directory must exist already under the /clientsdirectory.
You see a prompt similar to the following:
Enter the swap device and partition on client1. [dsk0b]:
Managing DMS Clients and Environments 12–3
7. Enter the swap device and partition on the DMS client. You see a
prompt similar to the following:
Enter the swap device drive type for dsk0b. [RZ26]:
8. Enter the swap device drive type for your previous entry. You see a
prompt similar to the following:
Enter the network interface for client1
(nn.nn.nnn.nnn) [ln0]:
9. Enter the DMS client’s network hardware address. You see a prompt
similar to the following:
Enter the subnet mask for ln0. [255.255.255.0]:
10. Enter the DMS client’s network subnet mask.
You may see the following prompts:
•
If the DMS client is on a different subnet from the DMS server, you
see a prompt similar to the following:
Enter the default route for network nn.nn.nnn
[nn.nn.nnn.nnn]:
___________________ Note
___________________
The default network interface is ln0for the DEC 3000
series and other systems that use the Lance Ethernet
module. Some systems such as the EB64+ use the Tulip
Ethernet module, which may be identified as tu0. Be
sure to enter the correct network device identifier for the
Ethernet or FDDI interface on the client system.
•
•
If there is an entry for the client’s subnet in the
/var/adm/dms/gatewaysfile on the server, the following message
is displayed:
The following are the known gateway[s] between the client subnet and
server subnet. If these value[s] are not correct, please enter the
proper address[s]. If these value[s] are correct, press Return. (For
example, nn.nn.nnn.???) [nn.nn.nnn.nnn]:
If there is no entry for the client’s subnet in the
/var/adm/dms/gatewaysfile on the server, you see a prompt
similar to the following:
Enter the IP address of the gateway[s] between the client subnet and
server subnet. (For example, nn.nn.nnn.???) :
See the Network Administration: Connections manual for information
about obtaining the client’s network information.
12–4 Managing DMS Clients and Environments
You see a prompt similar to the following:
Enter the type of kernel build area for client1.
You may select one of [F]ull, [P]artial, [N]one or
[H]elp for more information. [P]:
11. Enter the letter corresponding with the type of kernel build that you
want. You see a prompt similar to the following:
You have specified the following configuration for client1:
ROOT: /clients/client1
SWAP_DEVICE: /dev/disk/dsk0b
SWAP_TYPE: RZ26
BUILD_TYPE: Partial
INTERFACE: ln0 (nn.nn.nnn.nnn)
SUBNET_MASK: 255.255.255.0
ROUTE: network: nn.nn.nnn gateway: nn.nn.nnn.nnn
Is this correct (y/n) [y]:
12. Enter yto confirm your selections or nto return to the DMU Main Menu.
If you enter y, you see a prompt similar to the following:
The existing environment is /var/adm/dms/dms0.alpha.
The following environment will be installed from
/var/adm/dms/dms0.alpha:
Description
1
’Tru64 UNIX VAAA Operating System (Rev nnn)’
Is that correct? (y/n) [y]:
If there is more than one DMS environment, you are prompted to select
one and confirm your selection.
13. Enter yto confirm your selection or nto return to the DMU Main Menu.
You see a prompt similar to the following:
Enter the client processor’s hardware network
address. For example, 08-00-2b-02-67-e1:
14. Enter the DMS client’s hardware network address.
____________________
Note _____________________
The dmsutility does not check the validity of the address you
enter, but it does check to make sure the address you enter is
in the correct format.
Managing DMS Clients and Environments 12–5
You see a prompt similar to the following:
Checking file system space required for client
root and var file systems.
•
If there is not enough free space available to create the file systems,
you see a prompt similar to the following:
There is not enough free space in /clients
to create the root and var file systems
for client1. client1 has not been added.
•
If there is enough free space to create file systems, you see the
following prompt:
Creating the root and var file systems for client1
Client client1 has been added.
You see the DMU Main Menu.
Notify the client’s system administrator when client registration is complete
and inform them that they now can boot the client across the network. See
Section 12.3 for basic information about booting a client. See the Installation
Guide — Advanced Topics for additional information.
12.3 Booting a DMS Client
After a DMS client is added to the appropriate environment, the client’s
system administrator can boot the client over the network. When
the client starts to boot, the kernel that boots over the network is:
/clients/hostname /.vmunix
The following steps occur when the client boots:
1. The /clients/hostname directory is mounted by NFS as root (/).
2. The /var/adm/dms/dmsN.alpha/root/usrdirectory is mounted by
NFS as /usr.
The network information you entered about the client when you added it to
the DMS environment is sufficient to boot the DMS client across the LAN.
DMS clients must be able to boot over Ethernet or FDDI LAN. The basic
procedure for booting a processor over the network from a server is to shut
down the client system to console mode and then issue a boot command
from the client.
See the Installation Guide — Advanced Topics for information about booting
systems over the network.
12–6 Managing DMS Clients and Environments
When the client system boots, the client system administrator is prompted
to enter a superuser password:
*** SUPERUSER PASSWORD SPECIFICATION **
Changing password for root.
Enter root password:
Retype root password:
System information is displayed while the client system boots. When the
Common Desktop Environment (CDE) login window or the loginprompt
appears, enter rootas the login name. At the prompt for a password, enter
the superuser password that was specified previously.
12.4 Deleting a Software Environment
When you delete a software environment, the environment itself and all
clients registered to that environment are deleted. After you confirm your
choice, there is no opportunity to undo the deletion.
_____________________ Caution
_____________________
Make sure that the clients registered to the environment have
been notified and shut down before you delete the environment.
Failure to do so will cause a running client to lose its operating
system.
To delete a software environment, follow these steps:
1. Log in to the DMS server as rootor use the sucommand to gain
superuser privileges.
2. Enter /usr/sbin/dmuto start the DMS utility. You see the DMU Main
Menu:
*** DMU Main Menu ***
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:
Managing DMS Clients and Environments 12–7
3. Enter dto select DELETE software environments. You see a prompt
similar to the following example, which lists three DMS environments:
Select the remote dataless environment:
1) /var/adm/dms/dms0.alpha
’Tru64 UNIX VAAA Operating System (Rev nnn)’
2) /var/adm/dms/dms1.alpha
’Tru64 UNIX VBBB Operating System (Rev nnn)’
3) /var/adm/dms/dms2.alpha
’Tru64 UNIX VCCC Operating System (Rev nnn)’
Enter your choice:
4. Enter the number that corresponds to the DMS environment you want
to delete, for example: 1. You see a prompt similar to the following:
After you select the dataless environment to delete, a confirmation
displays your choice:
The following environment will be deleted from
/var/adm/dms/dms0.alpha:
Description
’Tru64 UNIX VAAA Operating System (Rev nnn)’
Is that correct? (y/n) [y]:
5. Confirm your selection.
•
•
If you enter n, the dmuutility returns to the DMU Main Menu.
If you enter y, you see a prompt similar to the following:
After this deletion, the area /var/adm/dms/dms0.alpha will
be empty. The following clients are registered for
/var/adm/dms/dms0.alpha:
client1 client2 client3
This procedure will completely remove /var/adm/dms/dms0.alpha.
Do you want to continue? (y/n) [n]:
–
–
If you enter n, the dmuutility returns to the DMU Main Menu
and does not delete the environment or its registered clients.
If you enter y, you see a prompt similar to the following:
Do you want to remove the client’s root file system
[/clients/client1]? (y/n) [n]:
This is your opportunity to save customized data in the root
directory. If you enter n, all customized data in the root directory
is lost.
12–8 Managing DMS Clients and Environments
The dmuutility also prompts you to remove the root and /var
file systems for each client registered to the environment.
After you confirm your selections, the dmuutility proceeds to delete
the DMS environment and all its registered clients.
After the DMS environment is deleted, the dmuutility returns to the DMU
Main Menu.
12.5 Modifying Client Information
The dmuutility lets you modify the network hardware address of a client.
See Section 1.3 for instructions about how to obtain the hardware address of
a client.
Perform the following steps to modify a DMS client’s information:
1. Log in to the DMS server as rootor use the sucommand to gain
superuser privileges.
2. Enter /usr/sbin/dmuto start the dmuutility. You see the DMU Main
Menu:
*** DMU Main Menu ***
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:
3. Enter mto select MODIFY a client. You see a prompt similar to the
following:
The following clients are available to modify:
client4 client5 client6
Enter the client processor’s hostname or press RETURN to quit:
4. Enter the name of the client you want to modify, for example: client4.
Managing DMS Clients and Environments 12–9
You see a prompt similar to the following, with the DMS client’s current
hardware network address as the default response:
Enter the client processor’s hardware network address. For
example, 08-00-2b-02-67-e1 [xx-xx-xx-xx-xx-xx]:
___________________ Caution
___________________
The dmsutility checks the format of the address you enter
but does not check its validity.
5. Enter the DMS client’s hardware network address or press Return to
accept the default. You see a message similar to the following:
Client client4 has been modified.
*** DMU Main Menu ***
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:
If you want to change the client’s IP address or the environment to which
the client is registered, follow these steps:
1. Log in to the DMS client as rootor use the sucommand to gain
superuser privileges.
2. Use the SysMan Menu or the shutdown -hcommand to shut down
the DMS client.
3. Log in to the DMS server as rootor use the sucommand to gain
superuser privileges.
4. Enter /usr/sbin/dmuto start the dmuutility. You see the DMU Main
Menu:
*** DMU Main Menu ***
a) ADD a client
c) CONFIGURE software environments
d) DELETE software environments
12–10 Managing DMS Clients and 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:
5. Enter rto select REMOVE a client, and follow the instructions in
Section 12.6. You see the DMU Main Menu again.
6. Enter ato select ADD a client, and follow the instructions in
Section 12.2.
7. Restart the DMS client.
12.6 Removing a Client
Follow these steps to remove a client from a DMS environment:
1. Log in to the DMS client as rootor use the sucommand to gain
superuser privileges.
2. Use the shutdown -hcommand to shut down the DMS client.
3. Log in to the DMS server as rootor use the sucommand to gain
superuser privileges.
4. Enter /usr/sbin/dmuto start the dmuutility. You see the DMU Main
Menu
*** DMU Main Menu ***
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:
5. Enter rto select REMOVE a client. You see the following prompt:
You have chosen to remove a client from the remote
dataless service.
Enter the client processor’s hostname or press RETURN to quit:
Managing DMS Clients and Environments 12–11
6. Enter the DMS client’s host name, for example: client5. You see a
prompt similar to the following:
Remove client5? (y/n) [n]:
7. Enter yto delete the client. The dmuutility removes the client’s
registration to the DMS environment, along with the following
additional items:
•
The client’s root directory (including any customized files that may
have been added to that directory)
•
•
•
The DMS client’s entries in /etc/exports(described in Chapter 13)
The DMS client’s entries in /etc/bootptab
The DMS client’s entry in the DMS client database file (described in
Section 12.1).
If you remove a client but save the root (/) file system, you cannot reuse that
root file system if you subsequently add a client with the same client name.
12.7 Listing DMS Clients
Follow these steps to view registered DMS clients:
1. Log in to the DMS server as rootor use the sucommand to gain
superuser privileges.
2. Enter /usr/sbin/dmuto start the dmuutility. You see the DMU Main
Menu:
*** DMU Main Menu ***
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:
3. Enter lto select LIST registered clients.
12–12 Managing DMS Clients and Environments
You see output similar to the following:
The following clients are registered for /var/adm/dms/
dms0.alpha: client1 client2 client3
The following clients are registered for /var/adm/dms/
dms1.alpha: client4 client5 client6
The following clients are registered for /var/adm/dms/
dms2.alpha: client7 client8 client9
12.8 Showing Software Environments
The dmuutility lets you display a list of the current DMS environments:
1. Log in to the DMS server as rootor use the sucommand to gain
superuser privileges.
2. Enter /usr/sbin/dmuto start the dmuutility. You see the DMU Main
Menu:
*** DMU Main Menu ***
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:
3. Enter sto select SHOW software environments. You see output
similar to the following:
1) /var/adm/dms/dms0.alpha
’Tru64 UNIX VAAA Operating System (Rev nnn)’
2) /var/adm/dms/dms1.alpha
’Tru64 UNIX VBBB Operating System (Rev nnn)’’
3) /var/adm/dms/dms2.alpha
’Tru64 UNIX VCCC Operating System (Rev nnn)’’
*** DMU Main Menu ***
a) ADD a client
c) CONFIGURE software environments
d) DELETE software environments
Managing DMS Clients and Environments 12–13
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:
12.9 Maintaining the DMS Environment
The following sections contain information about maintaining the DMU
server area, and includes the following topics:
•
•
•
Controlling root file system growth (Section 12.9.1)
Listing installed software subsets (Section 12.9.2)
Removing software subsets (Section 12.9.3)
12.9.1 Controlling Root File System Growth
The dfcommand displays statistics about the amount of free space on a
specified file system or on a file system that contains a specified file.
The ducommand displays a summary of disk usage for file systems. Use
this command to monitor the file growth in each client’s root directory. If
clients use too much space, performance is adversely affected. Users must be
told then to delete all unnecessary files from their file systems. Monitor disk
usage periodically depending upon the systems’ use.
See df(1) and du(1) for more information about monitoring file system
growth.
12.9.2 Listing Installed Software Subsets
Use the setldutility to determine which software subsets are installed
into a particular dmsN .alphaarea. For example, the following command
produces a list of the subsets installed into the client root area of
/var/adm/dms/dms0.alpha:
# setld -D /var/adm/dms/dms0.alpha/root -i
See setld(8) for more information.
12–14 Managing DMS Clients and Environments
12.9.3 Removing Subsets
Use the setldutility to remove software subsets from a dmsN .alpha
area. For example, if you want to remove the Document Preparation Tools
Extensions subset, OSFDCMTEXT505, use a command similar to the following:
# setld -D /var/adm/dms/dms0.alpha/root -d OSFDCMTEXT505
The Installation Guide contains a list of all software subsets.
_____________________ Caution
_____________________
If the setldutility placed files in the root file system during
the installation, the product may not be fully removed from the
client’s root file system. Be careful about removing any subset
that may be used by client systems. For example:
•
If you remove a subset that contains kernel build files, the
clients may not be able to build new kernels.
•
If you remove a subset that contains NFS components, the
clients may not be able to reboot.
You should understand client dependencies before you remove a
software component. You may need to delete and reregister all
clients before you can reload a subset.
Managing DMS Clients and Environments 12–15
13
Troubleshooting DMS
This chapter contains information to assist you in troubleshooting problems
with DMS. If a DMS client has trouble booting, you can check several aspects
of server operation to ensure that the server’s end of the network connection
is functioning properly. These are grouped into the following categories:
•
•
•
•
•
•
•
Removing DMS lock files (Section 13.1)
Checking NFS server status (Section 13.2)
Checking network daemon status (Section 13.3)
Checking directory exports (Section 13.4)
Checking server-client compatibility (Section 13.5)
Correcting swap device problems (Section 13.6)
Reconfiguring for a hardware update release (Section 13.7)
13.1 Removing DMS Lock Files
To prevent multiple users from performing simultaneous operations on DMS
areas, the dmuutility creates two lock files in the /tmpdirectory, dmslock
and dms.tty.lockwhen you are installing or deleting software in a DMS
area. If another user (or the same user on a different terminal) runs the dmu
utility and attempts to install or delete software from the DMU Main Menu,
they see a message similar to the following:
The dmu utility is currently locked while j_smith on /dev/ttyp3
is installing software. Try again later.
If the dmuutility is stopped prematurely, these lock files may not be removed
and you see this message even though no other user is using DMS. You must
delete the lock files from the /tmpdirectory.
_____________________ Caution
_____________________
Before deleting the lock files, ensure that no other user is using
the dmuutility.
Troubleshooting DMS 13–1
13.2 Checking NFS Server Status
Some DMS client boot problems occur if the DMS server is not a Network
File System (NFS) server. To check whether or not a DMS server is an NFS
server, enter the following command on the DMS server:
# rcmgr get NFSSERVING
If the response is a 1, the system is an NFS server. If the response is a 0, the
system is not an NFS server. Run nfsconfigto configure the server to be
an NFS server. See nfsconfig(8X) for more information.
13.3 Checking Network Daemon Status
Some DMS client boot problems occur if the network daemons are not
running on the DMS server. This condition is indicated on the DMS client
with a message similar to the following:
panic: vfs_mountroot: cannot mount root
If you see this message on the DMS client, make sure that the following
daemons are running on the DMS server:
• portmap
• mountd
• nfsd
• nfsiod
Enter the following command on the DMS server to see if the network
daemons are running:
# ps ax | grep -E "portmap|mountd|nfsd|nfsiod"
You see process status for any of those daemons that are running, as well
as a line showing your grepcommand. If the daemons are not all running,
you must start the inoperative ones.
13.4 Checking Directory Exports
Some DMS client boot problems occur if the client’s directories are not
exported correctly. If the DMS client boots to single-user mode but will
not boot to multiuser mode, look at the entries in the DMS server’s
/etc/exportsfile and ensure that the /usrfile system and dmsN root area
entries in /etc/exportsare correct, similar to the following example for a
DMS client named client1registered to the /var/adm/dms/dms0.alpha
DMS area:
/clients/client1 -r=0 client1
/var/adm/dms/dms0.alpha/root/usr -r=0 -ro
See exports(4) for information about the /etc/exportsfile.
13–2 Troubleshooting DMS
13.5 Checking Version Compatibility
If you cannot execute commands on the DMS client and the DMS server and
client are running different versions of the operating system, look to see if
you copied the client’s dmuversion to the server. See Section 11.1 for more
information.
13.6 Correcting Swap Device Problems
If there is a problem with the disk or disk partition that was designated as
the swap device when the client was registered, you may see a message
similar to the following:
WARNING: /dev/device/name swap partition has unused fstype, failed to add swap.
: Swap is being set to lazy (over commitment) mode. The system will
: come up to single-user mode. Set fstype for swap partition to
: "swap" using "disklabel -s swap" command and reboot.
Use one of the following procedures to correct this problem:
•
If you are using an older version of the operating system that uses
traditional device naming conventions (/dev/rrzNc), follow these steps:
1. Log in to the DMS client as rootor use the sucommand to gain
superuser privileges.
2. Change directory to /dev.
# cd /dev
3. Run the MAKEDEVutility on the disk or disk partition designated
as the swap device.
# ./MAKEDEV swapdev
4. Set the file system type for the swap device by running the
disklabelutility. Remember to specify swapdev as a raw device.
# disklabel -sF /dev rswapdev swap
5. Shut down and reboot the DMS client.
•
If you are using a later version of the operating system that uses newer
device naming conventions (/dev/disk/cdromNc), follow these steps:
1. Log in to the DMS client as rootor use the sucommand to gain
superuser privileges.
2. Change directory to /dev/rdisk.
# cd /dev/rdisk
3. Set the file system type for the swap device by running the
disklabelutility.
# disklabel -sF /dev/rdisk swapdev swap
Troubleshooting DMS 13–3
4. Shut down and reboot the DMS client.
You may encounter a situation where the client cannot boot to multi
user mode because the client machine has insufficient memory and the
disk specified to serve as the swap volume does not have the correct file
system type in the disklabel. If this occurs, it will be necessary to reboot
the client to single-user mode and set the disklabel correctly.
1. At the “>>>” prompt type:
>>>boot -flag s {network boot device}
2. After the machine completes the boot process, do the following:
disklabel -sF /dev/rdisk/{swap device} swap
3. Reboot the machine.
13.7 Reconfiguring for a Hardware Update Release
If you are installing a hardware update release and you configure the DMS
environment before you add the operating system hardware update, you
must connect to the root directory in the DMS environment and issue the
following two commands to undo the configuration:
# rm -rf usr/sys/conf/DATALESS
# rm -rf usr/sys/DATALESS
See Appendix D for information about hardware update releases in DMS.
13–4 Troubleshooting DMS
A
RIS Worksheet
This appendix contains a worksheet for recording setup information for the
RIS client. Make as many copies of this worksheet as you need.
RIS Worksheet A–1
RIS Client Configuration Worksheet
Network
System name:
Network hardware address:
IP network address:
Internet domain:
RIS Info
Client operating system:
Processor architecture:
Server system name:
RIS environment name:
Products:
Duplication
Duplicate another client? No
Name of client to copy:
Yes
ZK-0618U-AI
RIS Worksheet A–2
B
DMS Worksheets
This appendix contains three DMS worksheets. Two of the worksheets
are used to calculate the amount of disk space required for the DMS
environments and /clientsarea. The third worksheet is used to record
individual DMS client information. Make as many copies of these worksheets
as you need. The worksheets are printed on only one side of the page so
you can photocopy them easily. To keep all your calculations together, use
the back side of each worksheet for additional notes or for calculating the
numbers you insert into fields on the worksheet.
The following worksheets are included:
•
•
•
Disk space allocation for the /var/adm/dms/dmsN .alphaenvironments
Disk space allocation for the /clientsarea
Individual DMS client information
DMS Worksheets B–1
Disk Space Required for Dataless Environments
Use this worksheet to calculate the amount of space required for a single
/var/adm/dms
/var/adm/dms file system. If you want multiple
environments, you must prepare a separate sheet for each environment.
Each environment has a number: the first is /var/adm/dms/dms0.alpha,
the second is /var/adm/dms/dms1.alpha,and so on. Fill in the number of
this /var/adm/dms/dmsn.alpha environment on the top line.
Disk Space for the /var/adm/dms/dms
.alphaFile System
Using the appropriate subset size information, follow these steps to find how
/var/adm/dms/dmsn.alpha
much space you need for a
environment:
Step 1
Decide which subsets and layered products you want to install,
add up their total sizes in megabytes, and enter the sums here.
Subset names and descriptions are located in the Installation Guide;
subset sizes are located in the Release Notes.
MANDATORY subset space:
OPTIONAL subset space:
Layered product space:
MB
MB
MB
Step 2
Step 3
Add up the sizes from step 1 to arrive at the amount of space
your dataless environment will require.
Subtotal:
MB
Allocate an additional 10% of the space from step 2 for file
system administration and other information. Enter that
number here:
10% overhead space:
MB
Step 4
Add together the amounts of space from steps 2 and 3.
The total is the amount of space you should allocate for this
environment.
Total space for
:
.alpha
MB
/var/adm/dms/dms
ZK-1017U-AI
DMS Worksheets B–2
Disk Space for the /clients File System
Using the appropriate memory size information for your clients, follow these
steps to find how much space you need for the/clients area.
Step 1
To allow at least 30 megabytes(MB) for an individual client’s root
area, multiply the number of clients in the/clientsarea by 30.
Number of clients (
) x 30 =
MB
Step 2
Allocate an additional 15 MB per client for files added by users.
Multiply the number of clients by 15 and enter that value here.
Number of clients (
) x 15 =
MB
Step 3
Allocate an additional 15 MB for clients that have partial kernel
build areas. Multiply the number of clients with partial kernel
build areas by 15 and enter that value here.
Number of clients (
) x 15 =
MB
Step 4
Allocate an additional 100 MB for clients that have full kernel build
areas. Multiply the number of clients with full kernel build areas
by 100 and enter that value here.
Number of clients (
) x 100 =
MB
Step 5
Add the above figures. The total is the amount of space
you should allocate for the /clients area.
Total space for /clientsfile system:
MB
ZK-1018U-AI
DMS Worksheets B–3
DMS Client Setup Worksheet
This worksheet is used for recording the information you need to know when
adding a client to a DMS environment using the ADD a client menu
option. If you are adding multiple clients, you must prepare a separate sheet
for each client. Fill in the client’s system name (host name) on the next line.
Registration Information for DMS Client
Network
The client’s Ethernet or FDDI hardware address in the form
of six two-character groups separated by minus signs.
For example, 08-00-2f-03-f5-08
The client’s network interface type.
For example, ln0 or tu0, etc.
The client’s subnet mask.
For example, 255.255.255.0
The client’s route address.
(gateway FROM the client TO the server)
For example, 16.69.144.199
The route address is only required if the server and client are on different networks.
DMS Information
The name of the dataless environment to which this client
will be added. For example,
/var/adm/dms/dmsN.alpha
/clients
/clients/hostname
The name of the
For example,
area.
The client’s swap device and partition.
For example, /dev/disk/dsk0b
The client’s swap device type.
For example, RZ26
The kernel build type (Full, Partial,
or None)
ZK-1520U-AI
DMS Worksheets B–4
C
Using the utilupdate Utility
Use the utilupdateutility provided on your distribution media to update
the risand dmuutilities on a server that is running an older version of
the operating system. This enables you to serve the latest version of the
operating system to client systems.
Syntax for the utilupdateutility is as follows:
utilupdate [-r] [-d] -m directory
There are three parameters for the utilupdateutility:
-r
This optional flag indicates that the risutility and associated
programs should be updated.
-d
-m
This optional flag indicates that the dmuutility and associated
programs should be updated.
This required flag is used to specify the directory where the
operating system distribution is mounted.
______________________
Note _______________________
If you do not specify the -ror -dparameter, the utilupdate
utility only updates the components of the setldutility needed to
support the risand dmuutilities on the server. This updates the
version of the setldutility in the /var/adm/ris/bindirectory,
but does not change the server’s version of the setldutility. See
setld(8) for more information.
Using the utilupdate Utility C–1
D
Hardware Update Releases in DMS
A hardware release is a version of the operating system that includes new
or updated kernel modules to support hardware devices. In the current
version of the operating system, the function of hardware releases has been
superseded by the New Hardware Delivery (NHD) process and, to a lesser
degree, hardware product kits.
This appendix includes the following topics:
•
An overview of hardware releases, describing how to prepare for the
installation (Section D.1)
•
Instructions for installing a hardware release into a DMS area
(Section D.2)
D.1 Overview
If you are serving an older version of the operating system from DMS where
hardware releases are applicable, you may need to install a hardware
release into a DMS environment. The procedures in this appendix assume
that the DMS area is serving a version of the operating system no earlier
than Version 3.2C and no later than Version 4.0C.
Depending upon how you are installing the hardware release, you should
check the following information before you start:
•
You can install the new hardware release from a locally mounted
CD-ROM. See Section 1.3 if you do not know your CD-ROM drive’s
device name.
•
You can install the new hardware release from a CD-ROM mounted
using NFS from a remote server or from a RIS area exported using
NFS from a RIS server where the new release has been installed. See
Section 4.5 for information about using a RIS area mounted on NFS.
If you install the new hardware release from a RIS area, you must know
the following information:
–
Which product areas in your /usr/var/adm/ris/risN .alpha
contain each of the product kits you need to install. See Section 6.7 to
list products in a RIS area.
Hardware Update Releases in DMS D–1
–
Which directory in the RIS area conains the operating
system software. Examine the /usr/var/adm/ris/risN
.alpha/ProdNamesfile to determine this directory.
•
If you install from a base operating system CD-ROM mounted on the
mount point /mnt, the /mnt/ALPHA/UPDATEdirectory contains the
operating system hardware update release.
D.2 Installing a Hardware Release into a DMS Area
Follow these steps to install the operating system hardware update release
into an existing DMS area:
1. Follow the instructions in Section 11.2 to install the previous version of
the operating system into a new DMS environment.
____________________
Note _____________________
Do not configure the DMS environment at this time.
2. Follow the instructions in Section 11.3 to install the hardware update
release into the same DMS environment that you created in the
previous step.
3. Follow the instructions in Section 11.4 to configure the DMS
environment.
You can now serve DMS clients from the updated operating system hardware
release.
______________________
Note _______________________
Section 12.8 explains how to use the dmuutility to show DMS
software environments. This procedure displays only the
operating system product name in each DMS environment.
To determine if a hardware release is installed in a DMS
environment, use the setldcommand.
For example, the following command produces a list of the subsets
installed into the client root area of /var/adm/dms/dms0.alpha:
# setld -D /var/adm/dms/dms0.alpha/root -i
See setld(8) for more information.
D–2 Hardware Update Releases in DMS
Glossary
This glossary defines terms and concepts related to software sharing.
B
BIND
The Berkeley Internet Name Domain. A distributed database lookup service
that allows you to distribute the hostsdatabase network-wide.
boot command
The bootcommand performs the initial installation and bootstrap of the
operating system. You invoke the bootutility from the >>>console prompt.
See to your hardware documentation for information about valid parameters
for the bootutility on your system.
BOOTP
The bootstrap protocol provides a framework for passing configuration
information to hosts on a TCP/IP network. BOOTP allows a diskless client
machine to discover its own IP address, the address of a server host, and
the name of a file to be loaded into memory and executed. The bootstrap
operation can be thought of as consisting of two phases. The first phase is
address determination and bootfile selection and the second phase is file
transfer.
C
CDF
Configuration description file. There are two kinds of CDFs:
•
An installation CDF (install.cdf) contains the results of the questions
answered during the installation and is stored in the /var/adm/smlogs
directory. You can copy and modify this file to use for Installation
Cloning.
•
A configuration CDF (config.cdf) contains network, internet, printer,
and mail configuration information that are saved from a fully installed
and configured system with the sysman -clone -savecommand. This
file can be applied to a target system during a Full Installation, or it can
be applied manually to a running system.
CDSL
A context-dependent symbolic link (CDSL) is a special form of symbolic
link that dynamically resolves to a member-specific file, depending upon
Glossary–1
the cluster member accessing the file. CDSLs make it possible to maintain
system-specific configuration and data files on file systems shared by the
cluster.
See also cluster, cluster member, member-specific file, shared file
client
A computer system that uses resources provided by another computer,
called a server.
See also server
client area
In DMS, an area containing a single client’s custom-tailored root files
including the operating system kernel.
cluster
A loosely-coupled collection of servers that share storage and other
resources, providing high availability of applications and data. A cluster
consists of communications media, member systems, peripheral devices, and
applications. One system can form a single-member cluster.
See also cluster member
cluster alias
An IP address used to address all or a subset of the cluster members. A
cluster alias makes some or all of the systems in a cluster look like a single
system when viewed from outside the cluster.
See also cluster, cluster member
cluster member
A system configured with TruCluster software that is capable of joining a
cluster. A cluster member must be connected physically to a private physical
bus for intracluster communications and at least one shared SCSI bus.
See also cluster
configuration description file
See CDF
context-dependent symbolic link
See CDSL
D
Dataless Management Services
See DMS
Glossary–2
DHCP
Dynamic Host Configuration Protocol. Enables the automatic assignment
of an IP address to clients on networks from a pool of addresses. The IP
address assignment and configuration occurs automatically whenever
appropriate client systems (workstations and portable computers) attach to
a network. The current implementation of DHCP is based on the JOIN
product by Competitive Automation.
DMS
Dataless Management Services. A service where a server maintains the root,
/usr, and /varfile systems for client computer systems connected to the
server by a local area network (LAN).
DMS area
A reserved disk area physically connected to a DMS server, which contains
multiple copies of the root area, one for each DMS client.
DMS client
A computer system whose system disk area is physically connected to a DMS
server rather than to the client itself, and is accessed across the network
by the client.
DMS client area
A DMS client area resides in each DMS area and is called /clients.
Multiple copies of the root area reside in the client area, each tailored from
the appropriate generic root for an individual client.
DMS environment
A portion of a DMS area, containing software to support one or more
clients. A DMS environment contains one or more DMS root areas. DMS
environments are located in /var/adm/dms.
DMS root area
One root area is required for each client that is to be supported in the DMS
environment. DMS root areas are located in /var/adm/dms/dmsN.alpha.
Each root area contains a generic root directory and a shared /usrfile
system.
DMS server
A computer system that maintains the root, /usr, and /varfile systems
for DMS client systems. The DMS servers can contain multiple DMS
environments to which clients are added. DMS clients are booted over a
local area network (LAN). Swapping and dumping is not supported over the
network and must be done on the clients’ local disks.
dmu
Dataless management utility, located at /usr/sbin/dmu. A text-based
interface used to manage the sharing of installed operating software
Glossary–3
between DMS servers and clients. The dmuutility allows users to install,
configure, show, and delete DMS environments and add, list, modify, and
remove DMS clients.
Dynamic Host Configuration Protocol
See DHCP
G
H
generic root
In DMS, a portion of the DMS environment that contains system software in
a generic form, ready to be copied for tailoring to fit an individual client’s
requirements.
hardware product
A hardware product includes kernel modules to support hardware devices.
A hardware product kit, such as a device driver, can be installed during
the initial installation.
With bootlinking, a method to include kernel modules during the boot
process, the device driver can be loaded and the device used during the
device installation process.
See also NHD
K
L
kit
A kit is a collection of files and directories that represent one or more
layered products. It is the standard mechanism by which layered product
modifications are delivered and maintained on the operating system.
See also layered product
layered product
A layered product is an optional software product designed to be installed as
an added feature of the operating system.
Glossary–4
M
N
member-specific file
A file used by a specific cluster member. The contents of a member-specific
file differ for each cluster member, and each member has its own copy of a
member-specific file.
See also cluster, cluster member, shared file
Network File System
See NFS
new hardware delivery
See NHD
NFS
Network File System, an open operating system that allows all network
users to access shared files stored on computers of different types. Users
can manipulate shared files as if they were stored locally on the user’s own
hard disk.
NHD
New hardware delivery (NHD) provides support for new hardware without
providing a new release of the operating system, and can be offered on
a regular basis. The kit is usually provided on CD-ROM, and includes
installation and testing instructions.
See also hardware product
NIS
Network Information Service. A distributed data lookup service for sharing
information on a local area network (LAN). NIS allows you to coordinate
the distribution of database information throughout your networked
environment.
new file
In DMS, refers to files that are exactly as supplied in the software
distribution kit and have not been customized. These files are used by the
Update Installation process and allow the files to be delivered onto the
system without overwriting the existing, and possibly customized version of
the file. New files have a .new. prefix, and should never be modified.
See also prototype file
Glossary–5
P
private area
In DMS, a portion of the DMS area that is reserved for the exclusive use of a
single client. The private area contains the client’s custom-tailored copy of
certain operating system software files, including the kernel.
product environment
In RIS, a portion of the RIS area containing a set of software kits that are
intended for installation on a particular client type, such as RISC processors.
product kit
See kit
profile set
A profile set is a 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 and user-supplied files that
you want to execute when you install software from the RIS area.
See also CDF
prototype file
In DMS, refers to files that can be modified by the server’s system
administrator so that they can be customized for a particular client site,
such as /etc/hostsentries. Prototype files are prefixed with .proto..
and can be customized before the DMS environment is configured.
See also new file
R
Remote Installation Services
See RIS
RIS
Remote Installation Services. A remote software distribution method where
a server is set up to allow installation of software products over a local area
network (LAN). RIS clients are registered on the RIS server to allow them
access to specific software products. Using a RIS server makes installation
of layered products faster and easier for all the clients on the network.
RIS area
A reserved disk area physically connected to a RIS server, containing one
or more product environments. These contain software kits that can be
Glossary–6
installed on registered clients. Kits are organized so that a software product
can supply several different versions for multiple hardware platforms.
RIS client
A computer system that has permission to install software across the
network by accessing kits stored in the server’s RIS area.
RIS server
A computer system that serves other computers by providing operating
system software for them to install; the software is stored on disks belonging
to the server and is accessed across the network by the clients.
ris
Remote Installation Services utility, located at /usr/sbin/ris. A
text-based interface used to set up the RIS server and maintain RIS areas,
the software products within the RIS areas, and RIS client registrations.
rolling upgrade
A software upgrade of a cluster that is performed while the cluster is in
operation. One member at a time is rolled and returned to operation while
the cluster transparently maintains a mixed-version environment for the
base operating system, cluster, and Worldwide Language Support (WSL)
software. Clients accessing services are not aware that a rolling upgrade is
in progress.
S
server
A computer system that serves one or more other computers, called clients,
by providing resources to them.
See also client
shared file
A file used by all members of a cluster. There is only one copy of a shared file.
See also cluster, cluster member, member-specific file
software kit
See kit
subset
The smallest installable software kit module that is compatible with the
operating system’s setldsoftware installation utility. It contains files of
any type, usually related in some way.
Glossary–7
T
TFTP
Trivial File Transfer Protocol. TFTP is used during the RIS startup
procedure to transfer the network kernel and supporting files from the RIS
server to the RIS client. See tftp(1) and tftpd(8) for more information.
U
user-supplied file
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 preinstall,
update_preinstall, postload, update_postload, and postreboot
files.
Glossary–8
Index
A
C
adding
a DMS client, 12–2
C2security in DMS , 10–9
C2security in RIS , 3–5
calculating
a RIS client, 6–2
DMS clients to /etc/hosts file, 10–2
RIS clients to /etc/hosts file, 6–2
software to existing DMS
environment, 11–6
disk space for DMS, 10–4
disk space for DMS file systems,
10–4
CD-ROM
address
mounting, 4–1, 11–1
CDF
converting to for profile set, 7–5
copying to RIS server, 7–2
CD-ROM
locating device name, 1–3
checking
status of daemons, 13–2
client
adding for DMS, 12–2
architecture of DMS, 9–2
characteristics of DMS client, 9–5
compatibility with the server, 11–1
defined, 1–1
gateway, 6–1
hardware, 6–1
allocating disk partitions for
DMS, 10–3
architecture
of RIS, 2–1
B
Berkeley Internet Name Domain
( See BIND )
BIND, 6–2, 10–8
BIND Configuration Application,
10–8
description of, 1–2
DMS
booting
booting, 12–6
a DMS client, 12–6
a RIS client, 5–1
problems with DMS clients, 13–1
BOOTP, 5–1
troubleshooting, 13–1
hardware compatibility for DMS,
10–1, 11–1
hardware compatibility for RIS,
3–2
daemon, 5–2
BOOTP protocol
requirement for, 3–3
bootpd
identifying hardware network
address, 2–5
listing for RIS, 6–10
listing in DMS, 12–12
server daemon, 3–3
bootptab file, 5–1, 8–6
Index–1
naming service registration for
DMS, 10–8
registering for DMS, 10–7
registration for RIS, 6–1
registration information, 12–2
registration information for DMS,
10–8
removing from DMS, 12–11
removing from RIS, 6–9
software version compatibility for
DMS, 10–1, 11–1
nfsd, 10–3
nfsiod, 10–3
portmap, 10–3
required by NFS, 10–3
tftpd, 5–4, 8–9
Dataless Management Services
( See DMS )
deleting
a DMS client, 12–11
a DMS software environment, 12–7
a RIS client, 6–9
RIS product list, 6–12
determining
software subset size, 10–7
DHCP, 5–1
disk partitions
allocating for DMS, 10–3
on DMS server, 10–2
disk space
software version compatibility for
RIS, 3–2
view of DMS areas, 9–5
client area
calculating disk space for DMS,
10–6
in DMS, 9–5
client areas
allocating for DMS, 10–3
for DMS client area, 10–6
overhead for DMS administration,
10–5
establishing multiple for DMS, 9–5
cloned client
registration problems, 8–4
cluster
planning for DMS, 10–4, 10–5
planning for RIS, 3–3
showing use of, 12–14
displaying
rolling upgrade, 2–5
compatibility
DMS server and client, 11–1
RIS server and client, 3–2
configuring
disk usage, 12–14
distribution device
description of, 1–2
distribution media, 4–1, 11–2
( See also CD-ROM )
DMS, 1–1, 9–1
DMS environments, 11–11
controlling
growth of DMS root area, 12–14
creating
RIS area, 4–1
adding a client, 12–2
booting a client, 12–6
C2 security, 10–9
D
daemon
bootpd, 8–6
client
troubleshooting, 13–1
client area, 9–5
inetd, 5–2
internet, 5–2
joind, 5–2
mountd, 10–3
network
client registration, 10–7
client system disk space, 10–4
configuring environments, 11–11
controlling growth of root area,
12–14
checking status for DMS, 13–2
Index–2
definition of, 9–1
types of kernel builds for, 10–6
DMS clients
deleting an environment, 12–7
disk space for environments, 10–4
environment, 9–3
files in /usr area, 9–4
installing operating system on
server, 10–7
requirements for, 10–2
DMS environment, 9–4
adding software to existing, 11–6
modifying for client, 12–10
naming conventions for, 11–5
DMS IP address
installing required software
modifying for client, 12–10
DMS lock files, 13–1
DMS server
defined, 1–1
LANinstallation , 10–3
subsets, 10–7
installing software in new
environment, 11–2
listing clients, 6–10, 12–12
lock files, 13–1
maintaining the environment,
12–14
multiple environments, 9–4
planning disk space, 10–4
problems booting a client, 13–1
removing a client, 6–9, 12–11
required software for environments,
10–4
maintaining, 12–14
NFS installation, 10–3
partition information, 10–2
planning disk space, 10–4
DMS servers
requirements for, 10–1
dms.alpha areas, 10–4
du command, 12–14
Dynamic Host Configuration
Protocol
root area, 9–2, 9–3
server management tasks, 12–1
server preparation, 10–1
showing product list, 6–11, 12–13
software version on server, 10–1
system components, 1–2
DMS area, 9–2
( See DHCP )
E
environments area, 9–3
calculating disk space, 10–4
/etc/bootptab file, 5–2, 8–6
/etc/exports file, 13–2
/etc/hosts file
adding DMS clients to, 10–8
/etc/hosts file, 10–8
/etc/hosts file
adding DMS clients to, 10–2
/etc/inetd.conf file, 8–6
Ethernet, 3–4, 10–3
( See also LAN)
address of RIS client, 6–1
setting up a client on, 3–4
Ethernet address
contents of, 9–2, 9–3
defined, 1–1
DMS client
booting problems, 13–1
database file, 12–1
defined, 1–1
full build support, 10–6
information required for, 10–8
modifying environment for, 12–10
no build support, 10–6
partial build support, 10–6
planning disk space, 10–4
planning swap space, 10–8
Index–3
specifying for DMS client, 12–5
exported file systems for DMS,
13–2
RIS support of, 4–7
hardware update release
release installation, D–1
troubleshooting, 13–4
host name
exports file, 13–2
limitations on, 10–8
restrictions, 6–3
F
hosts file
FDDI, 3–4
adding DMS clients to, 10–8
adding RIS clients to, 6–2
( See also LAN)
setting up a client on, 3–4
FDDI address
specifying for DMS client, 12–5
file
I
identifying hardware network
address, 2–5
including hardware product kits
in a RIS area, 4–7
.new.., 9–4
root area, 9–3
/usr area, 9–4
file system
inetd, 5–2
DMS environments, 10–4
exported for DMS client, 13–2
files
inetd daemon, 5–1
inetd.conf file, 5–1, 8–6
installation
invoking during installation
of hardware product kits, 4–7
of hardware update release, D–1
of RIS software subsets
in existing area, 4–5
in new area, 4–1
of server operating system for RIS,
3–3
installation cloning, 7–1
installation of RIS server
LANinstallation , 3–4
installing
NFS, 10–3
operating system on DMS server,
10–7
required software subsets for DMS,
10–7
rolling upgrade, 2–5
software in existing DMS
environment, 11–6
process, 7–1
full build support for DMS client,
10–6
G
gateway address, 6–1
gateways file
correcting entries, 6–13
H
hardware
compatibility for DMS, 10–1, 11–1
compatibility for RIS, 3–2
hardware address, 6–1
modifying for DMS client, 12–9
specifying for DMS client, 12–5
hardware network address
identifying, 2–5
hardware product kits
including into an existing RIS area,
4–7
software in new DMS environment,
11–2
internet address
( See IP address )
Index–4
Internet address
installed subsets, 12–14
RIS clients, 6–10
listing RIS products, 6–11
LMF
( See IP address )
Internet Boot Protocol
( See BOOTP )
internet daemon, 5–2
required for servers, 10–1
local area network
( See LAN)
IP address
registering, 6–2
registering for DMS client, 10–8
lock files
DMS, 13–1
RIS, 8–1
J
joind, 5–2
joind daemon, 5–1, 8–6
M
management of RIS, 6–1
mandatory subsets
space required, 10–5
K
trouble with, 8–3
modifying
kernel
customized for DMS clients, 9–5
environment for DMS client, 12–10
IP address for DMS client, 12–10
network hardware address for DMS
client, 12–9
mountd daemon, 10–3
mounting
full build support for DMS client,
10–6
generic, 9–3
no build support for DMS client,
10–6
partial build support for DMS
client, 10–6
types of build support for DMS
a CD-ROM, 4–1, 11–1
multiple client areas in DMS, 9–5
clients, 10–6
kit
( See subset )
N
naming conventions
for DMS environments, 11–5
naming service, 6–1
registering DMS clients, 10–8
registering RIS clients, 6–2
network
L
LAN, 1–1
host addresses on, 10–8
installation of RIS server, 3–4
installing DMS server, 10–3
layered products
file system, 9–2
naming service, 6–1
Network Configuration
Application
disk space on DMS servers, 10–5
License Management Facility
( See LMF )
utility, 10–8
network daemons
for DMS, 13–2
listing
DMS clients, 12–12
Index–5
Network File System
( See NFS )
required for servers, 10–1
partial build support for DMS
client, 10–6
network hardware address
modifying for DMS client, 12–9
specifying for DMS client, 12–5
network information
for DMS servers and clients, 10–2
Network Information Service
( See NIS )
partitions
on DMS server, 10–2
planning
disk space for DMS, 10–4
planning disk space for RIS, 3–3
portmap daemon, 10–3
problems, 13–1
network interface
for DMS clients, 10–8
network naming service
registering DMS client, 10–7
.new.. files, 9–4
product
showing list of, 12–13
Product Authorization Key
( See PAK )
product environment, 2–3
deleting products in, 6–12
listing RIS products in, 6–11
multiple in single RIS area, 2–3
RIS products in listing, 6–11
profile set, 7–1
converting CDF to, 7–5
creating, 7–2
creating directories for, 7–2
definition, 7–1
deleting from RIS server, 7–6
populating, 7–2
NFS
checking server status, 13–2
daemons required by, 10–3
installation, 10–3
used by DMS, 9–2
using a remote RIS area, 4–10
using mount point to install
software, 4–2n, 10–2, 11–3n
NFS server
checking status, 13–2
nfsd daemon, 10–3
nfsiod daemon, 10–3
NIS, 6–2, 10–8
registering for, 7–3
registering RIS client for, 7–3
protected system files, 9–4
NIS utility, 10–8
no build support for DMS client,
10–6
R
O
registering a client, 6–1
for DMS, 10–8
information required for DMS
client, 10–8, 12–2
information required for RIS clients,
6–1
problems in RIS, 8–3
with naming service, 6–2, 10–8
registration problems
cloned client, 8–4
remote boot
flow, 5–4
operating system
installable by RIS, 2–4
installing on DMS server, 10–7
installing on RIS server, 3–3
tailored for DMS client, 9–5
overhead
disk space, 10–5
P
PAK
Index–6
Remote Installation Services
( See RIS )
definition, 2–1
remove
DMS client root directory, 11–6
removing
removing client system from
registration, 7–6
removing multiple clients, 6–9
server setup, 4–1
startup messages, 2–3
startup process, 2–3
system components, 1–2
troubleshooting, 8–1
using an NFS mounted RIS area,
4–10
RIS area, 2–1
contents of, 2–3
creating, 4–1
defined, 1–1
exporting and importing, 2–3
including hardware product kits,
4–7
multiple, 2–3
RIS client
booting, 5–1
defined, 1–1
Ethernet address, 6–1
host naming conventions, 6–3
preparing to register, 6–1
registering for profile set, 7–3
RIS daemons
inetd, 5–1
joind, 5–1
tftpd, 5–1
RIS files
bootptab, 5–1
inetd.conf, 5–1
RIS lock files, 8–1
RIS server
defined, 1–1
risdb file, 8–6
root area
controlling growth of DMS, 12–14
files in, 9–3
in DMS, 9–2
root directory
a DMS client, 12–11
a DMS software environment, 12–7
a RIS client, 6–9
software subsets, 12–15
required software subsets
for DMS server, 10–1
requirements
for DMS clients, 10–2
for DMS servers, 10–1
response failures
servers using bootpd daemon, 8–6
servers using joind daemon, 8–8
restrictions
running bootpd and joind, 8–6n
RIS, 1–1
architecture of, 2–1
checking client system registration,
7–6
converting CDF, 7–5
correcting gateways file entries,
6–13
definition, 2–1
deleting products, 6–12
deleting profile set directory, 7–6
disk space
planning, 3–3
gateways file
correcting entries, 6–13
installing software subsets, 4–1
listing clients, 6–10
listing products, 6–11
lock files, 8–1
management tasks, 6–1
product environment, 2–3
remote booting, 5–1, 5–4
removing a client, 6–9
Index–7
losing DMS customization during
remove, 11–6
product list, 12–13
RIS product list, 6–11
software sharing via servers, 1–2
software subsets
choosing for DMS, 11–4, 11–7
choosing for RIS, 4–4
defined for RIS, 2–3
descriptions of, 3–3, 10–7
for RIS, 2–3
route for network
for DMS clients, 10–8
running bootpd and joind
restrictions, 8–6n
S
security in DMS, 10–9
security in RIS, 3–5
server
installing in existing DMS
environment, 11–6
installing in existing RIS area, 4–5
installing in new RIS area, 4–1
listing installed, 12–14
removing, 12–15
required for DMS, 10–7
required for DMS environments,
10–4
required for DMS server, 10–1
sizes of, 10–7
version compatibility for DMS,
10–1
space requirements
mandatory subsets, 10–5
startup messages
RIS, 2–3
startup process
RIS, 2–3
subnet mask
for DMS clients, 10–8
swap space
for DMS client, 10–8
SysMan Menu
using to install software for DMS,
10–7
system disk space, 10–4
system name
limitations on, 10–8
architecture of DMS, 9–2
compatibility with the client, 11–1
defined, 1–1
description of, 1–2
DMS management tasks, 12–1
function in DMS, 9–2
function in RIS, 2–1
hardware compatibility for DMS,
10–1, 11–1
hardware compatibility for RIS,
3–2
management tasks, 12–15
management tasks for RIS, 6–1
operating system installation for
DMS, 10–7
operating system installation for
RIS, 3–3
planning disk space for DMS, 10–4
planning disk space for RIS, 3–3
preparing DMS server, 10–1
RIS setup preparation, 3–1
software version compatibility for
DMS, 10–1, 11–1
software version compatibility for
RIS, 3–2
setld utility
listing subsets with, 12–14
removing subsets with, 12–15
sharing software
T
TFTP, 5–1, 5–4
TFTP protocol
benefits, 1–1
overview, 1–1
requirement for, 3–3
showing
Index–8
tftpd, 5–4
tftpd daemon, 5–1, 8–9
Token Ring
copying to RIS server, 7–2
installation cloning, 7–1
/usr area
setting up a client on, 3–4
Trivial File Transfer Protocol
( See TFTP )
files in, 9–4
utilities
utilupdate, C–1
utilupdate utility, C–1
troubleshooting
client not in RIS database, 8–5
duplicate client hardware address,
8–3
V
getname failure on RIS client, 8–2
hardware update release, 13–4
inability to mount root file system,
8–2
/var/adm/ris/clients/risdb file, 8–6
/var/adm/ris/gateways file, 6–13
version compatibility for DMS,
10–1, 11–1
loading incorrect kernel file, 8–9
problems booting RIS client, 8–4
response failures on servers using
bootpd daemon, 8–6
response failures on servers using
the joind daemon, 8–8
RIS client password expiration, 8–2
RIS client registered on multiple
RIS servers, 8–4
version compatibility for RIS, 3–2
view by client of DMS areas, 9–5
W
WLS
DMS client
building Asian kernel, 11–13
DMS client setup, 11–13
RIS server response problems, 8–6
system panics on boot, 8–2
troubleshooting DMS servers,
13–1
DMS server installation, 11–12
Y
troubleshooting RIS problems,
8–1
Yellow Pages service
( See NIS )
YP
( See NIS )
U
user-supplied files
Index–9
|