Compaq Washer Dryer TRU64 User Manual

Tru64 UNIX  
Sharing Software on a Local Area Network  
Part Number: AA-RH9DC-TE  
June 2001  
Product Version:  
Tru64 UNIX Version 5.1A  
This manual describes Remote Installation Services (RIS) and Dataless  
Management Services (DMS) in CompaqTru64 UNIX. RIS is used to  
install software kits across a network instead of using locally mounted  
distribution media. DMS lets client systems share the /usr file system  
on a networked server while maintaining their own root (/) and /var file  
systems on a DMS server.  
Compaq Computer Corporation  
Houston, Texas  
 
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 CDROM 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 CDROM 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 CDROM 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 CDROM. 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 CDROM 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 CDROM’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 CDROM 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 CDROM’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 CDROM, you might want to create symbolic links from the RIS  
server area to the software on the CDROM. 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 CDROM 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 CDROM  
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 CDROM containing the  
operating system subsets mounted on /mnt and listed in its /etc/exports  
file, the system administrator on newyork can use mount that CDROM  
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 processors hostname.  
2. The clients hostname must be in your systems host  
database(s).  
3. You must know whether the client is on an Ethernet, FDDI,  
or Token Ring network.  
4. You must know the clients 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 processors 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 processors 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 processors 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 processors 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 processors 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 processors host name  
2. The clients host name must be in your systems host database(s).  
3. You must know whether the client is on an Ethernet, FDDI, or Token  
Ring network.  
4. You must know the clients 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 processors 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 processors 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 CDROM  
Check that the CDROM 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 CDROM. For example, if  
the CDROM 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 CDROM. For example, if  
the CDROM 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 CDROM drive to install software  
subsets for one or more specific products from the CDROM 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 CDROM 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 CDROM 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 CDROM 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 processors hostname.  
2. The clients hostname must be in your systems host  
database(s).  
12–2 Managing DMS Clients and Environments  
 
3. You must know the clients 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 clients 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 processors 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 processors 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 clients 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 processors 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 processors 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 processors 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  
 

Coleman Tent 2000007824 User Manual
Continental Waffle Iron CM43615 User Manual
Cowon Systems MP3 Player O2PMP User Manual
Creda Refrigerator 46105 User Manual
Dixon Lawn Mower Accessory 966 004901 User Manual
Ducane Gas Grill 27010357 User Manual
Eclipse Fujitsu Ten Car Stereo System CD8053 User Manual
Edifier Enterprises Canada Speaker R133 User Manual
Electro Voice Portable Speaker DL18X User Manual
Generac Portable Generator 004917 5 User Manual