Tru64 UNIX
Sharing Software on a Local Area Network
Part Number:
June 2001
This manual describes Remote Installation Services (RIS) and Dataless Management Services (DMS) in CompaqTru64 UNIX. RIS is used to install software kits across a network instead of using locally mounted distribution media. DMS lets client systems share the /usr file system on a networked server while maintaining their own root (/) and /var file systems on a DMS server.
Compaq Computer Corporation
Houston, Texas
?? 2001 Compaq Computer Corporation
COMPAQ, the Compaq logo, and TruCluster Registered in the U.S. Patent and Trademark Office. Tru64 is a trademark of Compaq Information Technologies Group, L.P.
UNIX is a trademark of The Open Group. All other product names mentioned herein may be trademarks of their respective companies.
Confidential computer software. Valid license from Compaq required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor???s standard commercial license.
Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is provided ???as is??? without warranty of any kind and is subject to change without notice. The warranties for Compaq products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.
Contents
About This Manual
1Introduction to Sharing Software
2Remote Installation Services
3Preparing the RIS Server
4Setting Up a RIS Area
Contents iii
5Booting a RIS Client
6Managing RIS Clients and Environments
7Managing RIS Profile Sets
8Troubleshooting RIS
iv Contents
9Dataless Management Services
10 Preparing DMS Servers and Clients
11 Setting Up a DMS Environment
Contents v
12 Managing DMS Clients and Environments
13 Troubleshooting DMS
A RIS Worksheet
BDMS Worksheets
CUsing the utilupdate Utility
DHardware Update Releases in DMS
vi Contents
Glossary
Index
Examples
Figures
Tables
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:
x About This Manual
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:
GManuals for general users
S Manuals for system and network administrators
PManuals for programmers
RManuals 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:
???Internet electronic mail: readers_comment@zk3.dec.com
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.
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
1.1Overview
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
???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
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.2Understanding the Software Sharing Environment
The following components make up the environment for software sharing:
A server
The server???s system administrator prepares the server for RIS or DMS by creating the RIS or DMS areas on the server and ensuring that the server is connected to a LAN. A single server can serve both RIS and DMS clients, however a client cannot be registered to both RIS and DMS.
A distribution device on the server
For most servers, the distribution device is a CD???ROM drive or a software distribution copied directly to magnetic disk. You transfer or link the software subsets for one or more specific products and architectures from the distribution media to the RIS or DMS areas on the server. Registered clients can then access the software.
A local area network (LAN)
You must set up the server and all client processors as hosts on the LAN (using Ethernet, FDDI, or Token Ring for RIS and Ethernet or FDDI for DMS). Clients use the LAN to access the server???s RIS and DMS areas.
Clients
RIS clients are systems that can run the operating system for which the server provides kits. RIS clients also must be capable of booting over
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
There are many circumstances when you need to specify your
Use one of the following procedures to determine your
???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
To mount the device, insert the
# mount
The previous example uses a CD???ROM drive that is unit 4 and specifies /mnt as the mount point.
Introduction to Sharing Software
???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:
The
To mount the device, insert the
# mount
This example uses a CD???ROM drive that is unit 0 and specifies /mnt as the mount point.
???If you have multiple
For example, if you want to determine which
# hwmgr
You see the light on cdrom0c blink for 30 seconds.
See hwmgr(8) for more information.
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.1Overview
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
Remote Installation Services
Figure
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
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.
???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.2Starting 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
Remote Installation Services
Figure
/var/adm/ris
ris0.alpha
product_001
In Figure
Figure
The server itself usually does not use any of the RIS areas. System administrators can access the product area as required for maintenance and for installation or removal of product kits.
For more flexibility, you can establish multiple RIS areas in separate partitions. RIS areas on a given server can be exported to other servers using the Network File System (NFS). Servers that import such RIS areas can use them as if they were local, supplying the imported subsets to their own set of clients. Section 4.5 describes how to use NFS to mount a RIS area. The Network Administration: Services manual describes how to export and import file systems.
2.4 RIS Client Characteristics
A RIS installation uses the LAN as its installation media instead of a distribution CD???ROM. A RIS client can install any software kit for which
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
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
???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
>>> show dev
.
.
.
ewa0.0.0.0.1000.0 EWA0
.
.
.
???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
_hardware address:
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
.
.
.
_Interface, hardware address:
.
.
.
???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
PING atlanta.cities.xsamplex.com (nn.nn.nnn.nnn): 56 data bytes
1 packets transmitted, 1 packets received, 0% packet loss
atlanta (nn.nn.nnn.nnn) at
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.1Reviewing 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
???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
The previous example uses a CD???ROM drive that is unit 4 and specifies /mnt as the mount point; if your drive is a different unit, substitute the device special file name for that unit.
The
/dev/rrz4c.
Preparing the RIS Server
If you do not know your CD???ROM???s unit number, see Section 1.3.
???If you are using a newer version of the operating system that uses newer device naming conventions (/dev/disk/cdromNc), use a mount command similar to the following example:
# mount
The previous example uses a CD???ROM drive that is unit 0 and specifies /mnt as the mount point; if your drive is a different unit, substitute the device special file name for that unit.
The
/dev/disk/cdrom0c.
If you do not know your CD???ROM???s unit number, see Section 1.3.
3.Use the utilupdate command to update the necessary RIS utilities on the server, as shown in the following example:
# /mnt/isl/utilupdate
???The
???The
This command copies any files in the /usr/sbin directory to files with
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
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 Planning Disk Space for RIS
Before beginning to set up a RIS area, you must calculate the amount of disk storage required for the software subsets in the RIS areas on the server. If space on the server???s system disk is an issue and your server???s distribution media is a CD???ROM, you might want to create symbolic links from the RIS server area to the software on the CD???ROM. Section 4.2 briefly describes the advantages and disadvantages of establishing symbolic links instead of extracting the software subsets into the RIS server area.
See Chapter 1 for a description of the RIS area???s contents. A given server can have multiple RIS areas, in which some of the subsets can be duplicated. To organize your RIS server???s disk space, perform the following steps:
1.Determine how many RIS environments you want.
2.Choose the software subsets you want to install, organizing them by the environments where they are to be installed.
3.Use the subset size information in the Release Notes to ensure that you have adequate disk space.
3.3Installing 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
Preparing the RIS Server
Your output is similar to the following:
OSFOBSOLETE520 installed Obsolete Commands and Utilities (Obsolete Components)
OSFRIS520 installed Remote Installation Service
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
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.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
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
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.1Overview
The ris utility can be invoked in two ways:
???Interactively through a
???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
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
Setting Up a RIS Area
???If your server is running the current version of the operating system, use a command similar to the following example:
# mount
The previous example mounts a
See Section 1.3 if you do not know the
???If your server is running an earlier version of the operating system, use a command similar to the following example:
# mount
The previous example uses a
See Section 1.3 if you do not know the
____________________ 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
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:
The RIS Utility Main Menu does not display option letters for menu items that cannot be accessed. As you add environments, software, and clients to the system, other menu options become available.
4.Enter i to select Install software products. You see the following prompt:
RIS Software Installation Menu:
1)Install software into a new area
2)Add software into an existing area
3)Return to previous menu
Enter your choice:
5.Enter 1 to select Install software into a new area. You see the following prompt:
You have chosen to establish a new remote installation environment.
Enter the device special file name or the path of the directory where the software is located
(for example, /mnt/ALPHA/BASE):
6.Enter the full pathname or the device special file name for the distribution media.
???If your distribution media is CD???ROM mounted on /mnt, the directory where the software is located is /mnt/ALPHA/BASE.
???Enter a device specific file name only for magnetic tape media.
You see the following prompt:
Select the type of operating system base product to create. If the software you are offering supports
system, select
Choose one of the following options:
1)Standard boot method
2)
Enter your choice:
7.Select one of the available options.
???Select
???If you select Standard boot method, you see the following prompt:
Setting Up a RIS Area
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}
.
.
.
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
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
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.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
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
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.
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
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???
2 ???MYVGASTATIC software version 1???
The hardware product kit now is installed into the
Setting Up a RIS Area
4.5 Using a RIS Area Mounted on NFS
You can use an NFS mount point to install software from an extracted RIS area on another system or from an operating system distribution CD???ROM mounted on another system. You can use this method to create an extracted RIS area with the base operating system subsets.
_____________________ Caution _____________________
The information in this section can be used only if you are installing software on a client after you install the operating system software.
For example, if a system named chicago has a CD???ROM containing the operating system subsets mounted on /mnt and listed in its /etc/exports file, the system administrator on newyork can use mount that CD???ROM with a command similar to the following example:
NYroot# mount chicago:/mnt/ALPHA/BASE /mnt
After chicago is mounted, the newyork system administrator can use the ris utility to install software from the
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.
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
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
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
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
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
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.1Remote 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
Table
Booting a RIS Client
Table
/usr/sbin/inetd The Internet server daemon
/usr/sbin/joind 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
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
Example
.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
1The .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:
2The .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
.ris0.alpha entry, itself, contains common information about the boot file location.
???bf: Name of the boot file
3The 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
???ha: Client???s network hardware address
???ip: Client???s IP address
4The .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
.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
[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
2.The client processor firmware sends a BOOTP packet over the Ethernet contining the client???s hardware Ethernet address.
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
Booting a RIS Client
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.1Preregistration 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.1Obtaining 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
???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.2Registering 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
) MODIFY a client ) REMOVE a client
s) SHOW software products in remote installation environments x) EXIT
Enter your choice:
3.Enter a to select ADD a client. You see the following prompt:
You have chosen to add a client for remote installation services.
The following conditions must be met to add a client:
1.You must know the client processor???s hostname.
2.The client???s hostname must be in your system???s host database(s).
3.You must know whether the client is on an Ethernet, FDDI, or Token Ring network.
4.You must know the client???s hardware Ethernet, FDDI, or Token Ring address if the client is registering to install operating system software.
5.If the client and the server reside on different subnets, you will need the address of the gateway(s)
that the client can use to communicate with the server.
Do you want to continue? (y/n) [y]:
4.Enter y to continue. You see the following prompt:
Enter the client processor???s hostname: client1
5.Enter the client???s host name.
___________________ Caution ___________________
Only lowercase letters
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
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:
Enter one or more choices as a
(for example, 1 2 3) or all for all products [all]:
b.Enter the number of the product you want this client to be able to install, for example: 1. You see a prompt similar to the following:
You chose the following products:
1???Tru64 UNIX V5.1A Operating System (Rev nnn)???
Is that correct? (y/n) [y]:
???If you have hardware product kits installed on your RIS server, you see a prompt similar to the following, which shows (in this example) one RIS environment:
The existing environment is /var/adm/ris/ris0.alpha.
Select one or more products for the client to install from /var/adm/ris/ris0.alpha:
Product Description
1???Tru64 UNIX V5.1A Operating System (Rev nnn )??? with ???MYVGASTATIC software version 1???
2???MYVGASTATIC software version 1???
Enter one or more choices as a
Enter all.
___________________ Note ___________________
You must enter all for the new hardware support to be loaded during the installation process.
You see a prompt similar to the following:
You chose the following products:
1???Tru64 UNIX V5.1A Operating System (Rev nnn )??? with ???MYVGASTATIC software version 1???
2???MYVGASTATIC software version 1???
Is that correct? (y/n) [y]:
7.Enter y to confirm your selection.
What happens next depends upon whether profile sets reside on the RIS server. See Chapter 7 for information about profile sets.
???If no such profile sets reside on the RIS server, the ris utility proceeds to the next step.
???If profile sets reside on this RIS server, you see the following prompt:
Do you want to specify an Installation Profile Set for use during the installation of this client? [y/n] [n]:
Choose one of the following options:
???Enter n if you do not want to specify a profile set for Installation Cloning. The ris utility proceeds to the next step.
???Enter y to specify a profile set for Installation Cloning. You see a prompt similar to the following:
This RIS server has the following Installation Profile Sets available:
Astation400 Astation400a rz26
Enter a set name or press <Return> to exit set selection:
If you select a profile set, the ris utility validates it before proceeding. If you do not want to select an available profile set, press Return.
8.You see the following prompt:
Network type:
1)Ethernet or FDDI
2)Token Ring
Enter your choice:
Managing RIS Clients and Environments
9.Select the type of network where the client is connected, for example: 1 for Ethernet.
???If the server and client are connected to the same network, the ris utility proceeds to the next step.
???If the server and client are on different networks, the ris utility looks at the /var/adm/ris/gateways file and displays the gateway information needed for the client to connect to the server:
Using nn.nn.nnn.nnn for gateway address between client and server subnet. If this gateway address is incorrect, please refer to the Sharing Software on a Local Area Network book for information on how to correct it.
If the displayed gateway address is incorrect, follow the instructions in Section 6.9 to correct this information.
???After selecting the network type, you will see a prompt similar to the following:
Is this client a cluster alias? (y/n) [n]:
Enter y or n to specify whether the client is or is not a cluster alias. For example, if you select y, RIS does not need to get a hardware (ethernet) address for the client. If you select n, then you will see a prompt similar to the following:
Enter the client processor???s hardware network address. For example,
???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:
___________________ 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.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
For example:
# /usr/sbin/ris
If the client is a cluster alias, then the
6.4 Modifying RIS Clients
You can modify a RIS client???s network type, hardware network address, its RIS environment information, and the list of products it can install. You cannot modify a client???s IP or routing information. To modify a client???s entry, follow these steps:
1.Log in as root or use the su command to gain superuser privileges.
2.Start the ris utility:
# /usr/sbin/ris
You see the RIS Utility Main Menu:
*** RIS Utility Main Menu ***
Choices without key letters are not available.
a) ADD a client
d) DELETE software products i) INSTALL software products
l)LIST registered clients
m)MODIFY a client
r)REMOVE a client
s)SHOW software products in remote installation environments
x)EXIT
Enter your choice:
3.Enter m to select MODIFY a client. You see a prompt similar to the following:
The following clients are available to modify:
client01 client02 client03 client04
Enter the client processor???s hostname or press RETURN to quit:
Managing RIS Clients and Environments
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:
Enter one or more choices as a
6.Enter the numbers of the products you want to install, or press Return for all products. You see a prompt similar to the following:
You chose the following products:
1 ???Tru64 UNIX V5.1A Operating System ( Rev nnn )???
Is that correct? (y/n) [y]:
7.Enter y to verify your selection. You see a prompt similar to the following:
Network type:
1)Ethernet or FDDI
2)Token Ring
Enter your choice
8.Enter your network type, for example: 1 to select Ethernet. After selecting the network type, you will see a prompt similar to the following:
Is this client a cluster alias? (y/n) [n]:
9.Enter y or n to specify whether the client is or is not a cluster alias. For example, if you select y, RIS does not need to get a hardware (ethernet) address for the client. If you select n, then you will see a prompt similar to the following:
Enter the client processor???s hardware network address. For example,
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
Enter your choice:
3.Enter r to select REMOVE a client. You see a prompt similar to the following:
You have chosen to remove a client from the remote installation services.
Enter the client processor???s hostname or press RETURN to quit:
4.Enter the client???s host name, for example: client01. You see a prompt similar to the following:
Remove client01? (y/n) [n]:
5.Enter y to confirm the removal. You see the RIS Utility Main Menu.
You also can use a ris command line to remove several clients at once. The following example removes the clients boston and tulsa:
#/usr/sbin/ris
6.6Listing 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
The following clients are registered for /var/adm/ris/ris10.alpha: client02
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
# /usr/sbin/ris
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.8 Deleting Products from RIS Server Areas
To delete one or more of the current products in a RIS area, invoke the ris utility and choose the option to delete products. The utility asks you to choose a RIS area and then guides you through the procedure to delete products.
1.Log in as root or use the su command to gain superuser privileges.
2.Start the ris utility:
# /usr/sbin/ris
You see the RIS Utility Main Menu:
*** RIS Utility Main Menu ***
Choices without key letters are not available.
a) ADD a client
d) DELETE software products i) INSTALL software products
l)LIST registered clients
m)MODIFY a client
r)REMOVE a client
s)SHOW software products in remote installation environments
x)EXIT
Enter your choice:
3.Enter d to select DELETE software products. You see a prompt similar to the following:
Select the remote installation environment:
1)/usr/var/adm/ris/ris0.alpha ???Product 01???
???Product 02???
2)/usr/var/adm/ris/ris1.alpha ???Product 03???
???Product 04???
Enter your choice or press RETURN to quit:
4.Enter the number of the RIS area you want, for example: 2. You see a prompt similar to the following:
Select one or more products to delete from /usr/var/adm/ris/ris1.alpha:
Product Description
1???Product 03???
2???Product 04???
Enter one or more choices as a
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
Example
Example
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.
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
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.1Overview
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
???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
Managing RIS Profile Sets
???
???preinstall
???update_preinstall
???postload
???update_postload
???postreboot
???Any files called by the
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
You can organize CDFs and
???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
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
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
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
For example, if your CDFs and
#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.3Registering 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
In Example
Example
# /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
Example
Enter your choice: a
You have chosen to add a client for remote installation services.
The following conditions must be met to add a client:
1.You must know the client processor???s host name
2.The client???s host name must be in your system???s host database(s).
3.You must know whether the client is on an Ethernet, FDDI, or Token Ring network.
4.You must know the client???s hardware Ethernet, FDDI, or Token Ring address if the client is registering to install operating system software.
5.If the client and the server reside on different subnets, you will need the address of the gateway(s) that the client can use to communicate with the server.
Do you want to continue? (y/n) [y]: y
Enter the client processor???s hostname or press RETURN to quit: pubs08
Select the remote installation environment:
1)/var/adm/ris/ris0.alpha
???Operating System Release N ( Rev nnn )???
???OS Worldwide Language Support Version N ( Rev nnn )???
2)/var/adm/ris/ris1.alpha
???Something else in this RIS area???
Enter your choice or press RETURN to quit: 1
Select one or more products for the client to install from /var/adm/ris/ris0.alpha:
Product Description
1???Operating System Release N ( Rev nnn )???
2???OS Worldwide Language Support Version N ( Rev nnn )???
Enter one or more choices as a
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
Example
Network type:
1)Ethernet or FDDI
2)Token Ring
Enter your choice: 1
Enter the client processor???s hardware network address. For example,
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
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:
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:
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.1RIS 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.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
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
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.4.1 No Prompt for Client Hardware Address
The server requires a client???s hardware address in order to boot the client over the network. The ris utility prompts you for the client???s address during the registration process. If it does not, check the following:
???If the RIS area is linked to a CD???ROM
Check that the CD???ROM that is the target of the links is mounted.
???If the RIS area is serving a version of the operating system prior to Version 3.0
Check that the mandatory update subsets are installed in the server???s RIS area for the version of the operating system that is being
served. Install the mandatory update subsets from the /local_mnt /ALPHA/UPDATE directory on the distribution CD???ROM. For example, if the CD???ROM is installed on /mnt, install the mandatory update subsets from the /mnt/ALPHA/UPDATE directory.
???If the RIS area is serving Version 3.0
Check that the mandatory operating system subsets are installed into
the RIS area. Install the mandatory subsets from the /local_mnt /ALPHA/BASE directory on the distribution CD???ROM. For example, if the CD???ROM is installed on /mnt, install the mandatory update subsets from the /mnt/ALPHA/BASE directory.
???If the RIS area is serving Version 4.0 and later
Check that the OSFBASENNN subset is included in the RIS area and that the client is registered for that RIS area.
8.4.2Duplicate 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,
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
???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.3Cloned 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.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 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
3.Use the following command to find the process IDs for the Internet daemons. You see output similar to the following:
#ps x | grep
228 ?? I 0:00.93 /usr/sbin/inetd
243 ?? I 0:00.91 /usr/sbin/bootpd
9134 p2 S 0:00.23 grep
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
#kill
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
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
Example
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]:
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 2
Jul 28 16:35:47 stlouis bootpd[1228]: bootpd 2.1a #0: \ 3
Fri Feb 04 00:32:28 EST 2000
Jul 28 16:35:47 stlouis bootpd[1228]: reading "/etc/bootptab"
Troubleshooting RIS
Example
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
1Many daemons log information to this file.
2Result of sending a HUP signal to the inetd daemon and killing the bootpd daemon.
3A 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.
4A 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.
5A bootpd request by a system with hardware address nnnnnnnnnnnn. The system is a client of this RIS server.
8.5.2Servers 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 JOIN product by Competitive Automation. Ensure that the server???s information on the client is correct, namely information contained in the bootptab file of the server as shown in Section 5.1.3. If the server still fails to respond, enable logging of bootp messages on the server by using the following procedure:
1.Enter the following command to check that the joind daemon is servicing your bootp request:
# ps
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
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
Example
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.3Loading 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
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
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.1Overview
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.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.3Relationship 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.1DMS 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.
A DMS client???s system disk space (root and /usr areas) is physically connected to the server instead of to the client. The client accesses that disk area through a LAN connection with the server. Each DMS client is booted across the network from its private root area on the server. After it is booted, the client continues to use its root files and /usr files from the server???s DMS area. These files appear to the client as if they were on local disks, as shown in Figure
Figure
Local Area Network
As indicated in Figure
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
Dataless Management Services
copied to each client system. The /usr file system is read only and is shared among all client systems registered to the environment.
Figure
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.3.3 Client Portion of DMS Area
A DMS client area for individual DMS client systems also resides in a DMS area. Figure
Figure
/clients
Multiple copies of the root file system reside in the client area, one for each client, tailored from the generic root file system. Each client builds a customized kernel, which resides in the client???s root area if the client has a partial or full build environment. This customized kernel supports the client???s actual system configuration, including central processor, system memory, and peripheral devices. Figure
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
Dataless Management Services
Figure
In Figure
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.
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.1Requirements 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
???The DMS server must have the following software subsets installed:
???Additional Networking Services (OSFINET)
???Dataless Management Services (OSFDMS)
???The DMS server must have the
Preparing DMS Servers and Clients
See Software License Management for more information about software licensing.
???The DMS server must be able to install software into the DMS area:
???The DMS server can have a CD???ROM drive to install software subsets for one or more specific products from the CD???ROM to the DMS area on the server.
???The DMS server can use a Network File System (NFS) mount point
to install software from a Remote Installation Services (RIS) area or an operating system distribution CD???ROM from another processor. See Section 4.5 for more information about using an NFS mounted RIS area.
???The DMS server must have at least one separate disk partition where the DMS environment and client areas reside. The root would not be large enough for many client areas and var likely would fill up after one environment was added. Smaller disks may not hold an entire DMS area.
???NFS must be set up on the DMS server.
???The DMS server and all DMS clients must be connected to an Ethernet or FDDI local area network (LAN).
10.2Requirements 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.
???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.3Allocating 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
# ps ax | grep
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.6Planning 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)
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
______________________ 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
Table
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
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
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.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
???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.2Registering 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
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
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.1Ensuring 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
???If your server is running the current version of the operating system, use a command similar to the following example:
# mount
This example mounts a
???If your server is running an earlier version of the operating system, use a command similar to the following example:
# mount
This example uses a
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
Setting Up a DMS Environment
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
???In this example, the
???The
This procedure copies files in the /usr/sbin directory to files with a
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
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
???If your server is running the current version of the operating system, use a command similar to the following example:
# mount
This example mounts a
???If your server is running an earlier version of the operating system, use a command similar to the following example:
# mount
This example uses a
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
____________________ 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
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
Enter your choice:
5.Enter 1 to select Install software into a new area. You see the following prompt:
You have chosen to establish a new remote dataless environment.
Enter the device special file name or the path of the directory where the software is located (for example, /mnt/ALPHA/BASE):
6.Enter the software location, for example: /mnt/ALPHA/BASE.
???If your distribution media is CD???ROM mounted on /mnt, the directory where the software is located is /mnt/ALPHA/BASE.
???Enter a device specific file name only for magnetic tape media.
The dmu utility lists the mandatory and optional software subsets you can install.
The following subsets must be installed in the DMS environment:
???Additional Networking Services
???Dataless Management Services
7.Select the subsets that you want to extract; the dmu utility displays your list for confirmation. For example:
The following subsets are mandatory and will be installed automatically unless you choose to exit without installing any subsets:
.
.
.
{mandatory subset list}
.
.
.
Optional subsets are listed below. There may be more optional subsets than can be presented on a single screen. If this is the case, you can choose subsets screen by screen, or all at once on the last screen. All of the choices you make will be collected for your confirmation before any subsets are installed.
.
.
.
{optional subset list}
.
.
.
Or you may choose one of the following options:
94)ALL mandatory and all optional subsets
95)MANDATORY subsets only
96)CANCEL selections and redisplay menus
97)EXIT without extracting any subsets
Enter your choices or press RETURN to redisplay menus.
Choices (for example, 1 2
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 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.
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.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
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:
6.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
Enter your choice:
7.Enter 2 to select Add software to an existing area. You see a prompt similar to the following:
You have chosen to add a product to an existing environment.
The existing environment is /var/adm/dms/dms0.alpha.
____________________ Note _____________________
In the previous example, only one environment, dms0.alpha, exists. If you have more than one DMS environment, you see a prompt similar to the following:
Select the remote dataless environment:
1)/var/adm/dms/dms0.alpha
???Tru64 UNIX VAAA Operating System (Rev nnn)???
2)/var/adm/dms/dms1.alpha
???Tru64 UNIX VBBB Operating System (Rev nnn)???
Enter your choice:
Enter the number corresponding to the DMS environment where you want to install the software.
You see the following prompt:
Enter the device special file name or the path of the directory where the software is located (for example, /mnt/ALPHA/BASE):
8.Enter the software location, for example: /mnt/ALPHA/BASE.
???If your distribution media is CD???ROM mounted on /mnt, the directory where the software is located is /mnt/ALPHA/BASE.
???Enter a device specific file name only for magnetic tape media.
The dmu utility lists the mandatory and optional software subsets you can install.
Setting Up a DMS Environment
9.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:
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
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 dmu utility loads the subsets. If you enter n, the list of subsets is displayed again and you can restart your selection process.
The dmu utility installs the software subsets that you selected. This can take an hour or more.
After the dmu utility 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.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 dmu utility.
2.Building the environment???s kernel (Section 11.4.2). This step is mandatory and is performed through the CONFIGURE software environments option of the DMU Main Menu.
11.4.1Customizing /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 fstab file to include a server name:
1.Log in to the DMS server as root or use the su command to gain superuser privileges.
2.Define the DMS_ROOT environment variable to point to the affected DMS area, for example:
# DMS_ROOT=/var/adm/dms/dmsN.alpha/root
3.Delete the $DMS_ROOT/hosts file.
4.Modify the $DMS_ROOT/.proto..hosts file.
5.Use the dmu utility 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 .alpha in the /etc,
/bin, /var/adm/X11, and root directories. As an example, the /etc/.proto..hosts file is a file that you could modify in advance. Table
Setting Up a DMS Environment
Table
.proto..TIMEZONE
.proto..acucap
.proto..autopush
.proto..binlog.conf
.proto..conf
.proto..ddr.db
.proto..ddr.dbase
.proto..dhcptab
.proto..dvrdevtab
.proto..exports
.proto..fstab
.proto..ftpusers
.proto..gen_databases
.proto..gettydefs
.proto..group
.proto..hosts
.proto..hosts.equiv
.proto..ifaccess.conf
.proto..inet.local
.proto..inetd.conf
.proto..inittab
.proto..lprsetup.dat
.proto..magic
.proto..motd
.proto..networks
.proto..ntp.conf
.proto..passwd
.proto..phones
.proto..profile
.proto..proto.disktab
.proto..protocols
.proto..rc.config
.proto..remote
.proto..rpc
.proto..securettys
.proto..services
.proto..shells
.proto..slhosts
.proto..stresetup.conf
.proto..svc.conf
.proto..sysconfigtab
.proto..syslog.conf
For example, the /etc/.proto..hosts file contains no host names. Edit this file to include the network addresses, names, and aliases of
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..fstab file, you also should add the hosts to the etc/.proto..hosts file. 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 usr directory structure, make the directory mount points in the DMS usr directory 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.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 root or use the su command to gain superuser privileges.
2.Enter /usr/sbin/dmu to start the dmu utility. 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 c to 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
environment.
Do you want to (c)ontinue or (r)eturn to the main menu? (c/r) [c]:
???If you enter r, the dmu utility returns to the DMU Main Menu to let you exit the dmu utility and modify the /etc/.proto.. files.
???If you enter c to continue, the dmu utility displays progress messages as it configures each software subset, similar to the following output:
Configuring "Base System " (OSFBASE505)
Configuring "Base
.
.
.
{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.1Setting Up a DMS Server for WLS
Follow these steps to create a new dmsN .alpha environment and install WLS software from a base operating system
1.Log in to the DMS server as root or use the su command to gain superuser privileges.
2.Install the operating system into a DMS area before installing the Worldwide Language Support (WLS) software.
3.Load the
mount
4.Enter /usr/sbin/dmu to start the dmu utility. You see the DMU Main Menu.
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/WORLDWIDE to 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 environments to 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 wwconfig command as follows:
# /usr/sbin/wwconfig
See the Installation Guide ??? Advanced Topics and wwconfig(8) for more information about using the wwconfig command.
Setting Up a DMS Environment
12
Managing DMS Clients and Environments
This chapter describes how to use the dmu utility 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.1DMS 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:
In this example:
???client1 is the client???s host name
???
???/var/adm/dms/dms0.alpha is the DMS environment being served to the client
???/clients/client1 is the location of the client???s root area
???rz0b is the client???s swap device and partition
???RZ26 is the swap disk
???None specifies the client has no kernel build area
???ln0 is the network interface type
???255.255.255.0 is the network subnet mask
Managing DMS Clients and Environments
When you use add, modify, or delete a DMS client from the DMU Main Menu, the client???s entry in the dmsdb file 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 dmu utility 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/hosts file.
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 root or use the su command to gain superuser privileges.
2.Enter /usr/sbin/dmu to start the dmu 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:
3.Enter a to select ADD a client. You see a prompt similar to the following:
You have chosen to add a client for dataless service.
The following conditions must be met to add a client:
1.You must know the client processor???s hostname.
2.The client???s hostname must be in your system???s host database(s).
3.You must know the client???s interface type, subnet mask.
4.You must know the type of kernel build area.
5.You must know the swap device and partition on the client.
6.You must know the client???s hardware Ethernet or FDDI address.
7.If the client and the server reside on different subnets, you will need the address of the gateway(s) that the client can sue to communicate with the server.
Do you want to continue? (y/n) [y]:
4.Enter y to continue. You see the following prompt:
Enter the client processor???s hostname or press RETURN to quit:
5.Enter the host name for the DMS client.
If you enter a host name that is not in the server???s host database, you see a message similar to the following:
arp failed on hostname "client1"
In the above message, arp is the Address Resolution Protocol. If you receive this message, check the /etc/hosts file 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/hosts file, press Ctrl/C to exit the dmu utility and manually add the client to the /etc/hosts file 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 /clients directory.
You see a prompt similar to the following:
Enter the swap device and partition on client1. [dsk0b]:
Managing DMS Clients and Environments
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 ln0 for 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/gateways file 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/gateways file 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.
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:
Is this correct (y/n) [y]:
12.Enter y to confirm your selections or n to 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 y to confirm your selection or n to return to the DMU Main Menu. You see a prompt similar to the following:
Enter the client processor???s hardware network address. For example,
14.Enter the DMS client???s hardware network address.
____________________ Note _____________________
The dms utility 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
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/usr directory 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.
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 login prompt appears, enter root as 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 root or use the su command to gain superuser privileges.
2.Enter /usr/sbin/dmu to 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
3.Enter d to 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 dmu utility 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 dmu utility returns to the DMU Main Menu and does not delete the environment or its registered clients.
???If you enter y, you see a prompt similar to the following:
Do you want to remove the client???s root file system [/clients/client1]? (y/n) [n]:
This is your opportunity to save customized data in the root directory. If you enter n, all customized data in the root directory is lost.
The dmu utility also prompts you to remove the root and /var file systems for each client registered to the environment.
After you confirm your selections, the dmu utility proceeds to delete the DMS environment and all its registered clients.
After the DMS environment is deleted, the dmu utility returns to the DMU Main Menu.
12.5 Modifying Client Information
The dmu utility 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 root or use the su command to gain superuser privileges.
2.Enter /usr/sbin/dmu to start the dmu 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:
3.Enter m to select MODIFY a client. You see a prompt similar to the following:
The following clients are available to modify:
client4 client5 client6
Enter the client processor???s hostname or press RETURN to quit:
4.Enter the name of the client you want to modify, for example: client4.
Managing DMS Clients and Environments
You see a prompt similar to the following, with the DMS client???s current hardware network address as the default response:
Enter the client processor???s hardware network address. For example,
___________________ Caution ___________________
The dms utility 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 root or use the su command to gain superuser privileges.
2.Use the SysMan Menu or the shutdown
3.Log in to the DMS server as root or use the su command to gain superuser privileges.
4.Enter /usr/sbin/dmu to start the dmu 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:
5.Enter r to select REMOVE a client, and follow the instructions in Section 12.6. You see the DMU Main Menu again.
6.Enter a to select ADD a client, and follow the instructions in Section 12.2.
7.Restart the DMS client.
12.6Removing a Client
Follow these steps to remove a client from a DMS environment:
1.Log in to the DMS client as root or use the su command to gain superuser privileges.
2.Use the shutdown
3.Log in to the DMS server as root or use the su command to gain superuser privileges.
4.Enter /usr/sbin/dmu to start the dmu 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:
5.Enter r to select REMOVE a client. You see the following prompt:
You have chosen to remove a client from the remote dataless service.
Enter the client processor???s hostname or press RETURN to quit:
Managing DMS Clients and Environments
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 y to delete the client. The dmu utility 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 root or use the su command to gain superuser privileges.
2.Enter /usr/sbin/dmu to start the dmu 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:
3. Enter l to select LIST registered clients.
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 dmu utility lets you display a list of the current DMS environments:
1.Log in to the DMS server as root or use the su command to gain superuser privileges.
2.Enter /usr/sbin/dmu to start the dmu 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:
3.Enter s to 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
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.1Controlling Root File System Growth
The df command displays statistics about the amount of free space on a specified file system or on a file system that contains a specified file.
The du command 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 setld utility to determine which software subsets are installed into a particular dmsN .alpha area. For example, the following command produces a list of the subsets installed into the client root area of
/var/adm/dms/dms0.alpha:
# setld
See setld(8) for more information.
12.9.3 Removing Subsets
Use the setld utility 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
The Installation Guide contains a list of all software subsets.
_____________________ Caution _____________________
If the setld utility 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
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
???Correcting swap device problems (Section 13.6)
???Reconfiguring for a hardware update release (Section 13.7)
13.1Removing DMS Lock Files
To prevent multiple users from performing simultaneous operations on DMS areas, the dmu utility creates two lock files in the /tmp directory, dmslock and dms.tty.lock when 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 dmu utility 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 /tmp directory.
_____________________ Caution _____________________
Before deleting the lock files, ensure that no other user is using the dmu utility.
Troubleshooting DMS
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 nfsconfig to 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
You see process status for any of those daemons that are running, as well as a line showing your grep command. 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
DMS area:
/clients/client1
See exports(4) for information about the /etc/exports file.
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 dmu version 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
:"swap" using "disklabel
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 root or use the su command to gain superuser privileges.
2.Change directory to /dev.
#cd /dev
3.Run the MAKEDEV utility 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 disklabel utility. Remember to specify swapdev as a raw device.
#disklabel
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 root or use the su command 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 disklabel utility.
#disklabel
Troubleshooting DMS
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
1.At the ???>>>??? prompt type:
>>>boot
2.After the machine completes the boot process, do the following: disklabel
3.Reboot the machine.
13.7Reconfiguring 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
#rm
See Appendix D for information about hardware update releases in 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
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 /clients area. 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 .alpha environments
???Disk space allocation for the /clients area
???Individual DMS client information
DMS Worksheets
Disk Space Required for Dataless Environments
Use this worksheet to calculate the amount of space required for a single /var/adm/dms file system. If you want multiple /var/adm/dms 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/dms n.alpha environment on the top line.
Using the appropriate subset size information, follow these steps to find how much space you need for a /var/adm/dms/dms n.alpha 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.
Step 2 Add up the sizes from step 1 to arrive at the amount of space your dataless environment will require.
Subtotal:MB
Step 3 Allocate an additional 10% of the space from step 2 for file system administration and other information. Enter that number here:
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.
DMS Worksheets
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 /clients area by 30.
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.
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.
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.
Step 5 Add the above figures. The total is the amount of space you should allocate for the /clients area.
DMS Worksheets
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
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/dms N.alpha
The name of the /clients area.
For example, /clients/hostname
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)
DMS Worksheets
C
Using the utilupdate Utility
Use the utilupdate utility provided on your distribution media to update the ris and dmu utilities 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 utilupdate utility is as follows:
utilupdate
There are three parameters for the utilupdate utility:
This optional flag indicates that the ris utility and associated programs should be updated.
This optional flag indicates that the dmu utility 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
Using the utilupdate Utility
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
???You can install the new hardware release from a
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
???Which directory in the RIS area conains the operating system software. Examine the /usr/var/adm/ris/risN
.alpha/ProdNames file to determine this directory.
???If you install from a base operating system
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 dmu utility 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 setld command.
For example, the following command produces a list of the subsets installed into the client root area of /var/adm/dms/dms0.alpha:
# setld
See setld(8) for more information.
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 hosts database
boot command
The boot command performs the initial installation and bootstrap of the operating system. You invoke the boot utility from the >>> console prompt. See to your hardware documentation for information about valid parameters for the boot utility 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
CDSL
A
the cluster member accessing the file. CDSLs make it possible to maintain
See also cluster, cluster member,
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
cluster
A
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
See CDSL
D
Dataless Management Services
See DMS
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 /var file 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 /usr file system.
DMS server
A computer system that maintains the root, /usr, and /var file 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
between DMS servers and clients. The dmu utility 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
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.
H
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
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
L
layered product
A layered product is an optional software product designed to be installed as an added feature of the operating system.
M
A file used by a specific cluster member. The contents of a
See also cluster, cluster member, shared file
N
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
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
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
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
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/hosts entries. 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
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
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
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,
software kit
See kit
subset
The smallest installable software kit module that is compatible with the operating system???s setld software installation utility. It contains files of any type, usually related in some way.
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
A
adding
aDMS client,
aRIS client,
DMS clients to /etc/hosts file,
environment,
address
gateway,
allocating disk partitions for
DMS,
architecture
of RIS,
B
Berkeley Internet Name Domain
( See BIND )
BIND,
BIND Configuration Application,
booting
a DMS client,
problems with DMS clients,
BOOTP,
BOOTP protocol
requirement for,
bootpd
server daemon,
Index
C
C2 security in DMS,
C2 security in RIS,
disk space for DMS,
disk space for DMS file systems,
mounting,
CDF
converting to for profile set,
locating device name,
checking
status of daemons,
client
adding for DMS,
description of,
DMS
booting,
hardware compatibility for DMS,
hardware compatibility for RIS,
identifying hardware network address,
listing for RIS,
naming service registration for
DMS,
registering for DMS,
removing from DMS,
DMS,
software version compatibility for
RIS,
view of DMS areas,
client area
calculating disk space for DMS,
in DMS,
client areas
establishing multiple for DMS,
cloned client
registration problems,
cluster
rolling upgrade,
compatibility
DMS server and client,
RIS server and client,
configuring
DMS environments,
controlling
growth of DMS root area,
creating
RIS area,
D
daemon
bootpd,
checking status for DMS,
nfsd,
required by NFS,
tftpd,
Dataless Management Services
( See DMS )
deleting
a DMS client,
aDMS software environment,
aRIS client,
RIS product list,
determining
software subset size,
DHCP,
allocating for DMS,
disk space
allocating for DMS,
overhead for DMS administration,
planning for DMS,
displaying
disk usage,
distribution device description of,
distribution media,
( See also
adding a client,
troubleshooting,
client registration,
configuring environments,
definition of,
deleting an environment,
files in /usr area,
server,
installing required software subsets,
installing software in new environment,
listing clients,
maintaining the environment,
multiple environments,
root area,
server management tasks,
showing product list,
DMS area,
DMS client
booting problems,
full build support,
partial build support,
types of kernel builds for,
DMS clients
requirements for,
DMS environment,
adding software to existing,
DMS IP address
modifying for client,
DMS lock files,
DMS server
defined,
LAN installation,
partition information,
DMS servers requirements for,
dms.alpha areas,
Dynamic Host Configuration Protocol
( See DHCP )
E
environments area,
/etc/bootptab file,
/etc/hosts file
adding DMS clients to,
/etc/hosts file,
/etc/hosts file
adding DMS clients to,
/etc/inetd.conf file,
Ethernet,
( See also LAN )
address of RIS client,
Ethernet address
specifying for DMS client,
exports file,
F
FDDI,
( See also LAN )
setting up a client on,
FDDI address
specifying for DMS client,
file
.new..,
file system
DMS environments,
files
invoking during installation process,
full build support for DMS client,
G
gateway address,
correcting entries,
H
hardware
compatibility for DMS,
hardware address,
modifying for DMS client,
hardware network address
identifying,
hardware product kits
including into an existing RIS area,
RIS support of,
hardware update release
release installation,
host name
limitations on,
hosts file
adding DMS clients to,
I
identifying hardware network address,
including hardware product kits
in a RIS area,
inetd,
inetd daemon,
of hardware product kits,
of hardware update release,
in existing area,
of server operating system for RIS,
installation cloning,
LAN installation,
installing
NFS,
operating system on DMS server,
required software subsets for DMS,
rolling upgrade,
environment,
software in new DMS environment,
internet address
( See IP address )
Internet address
( See IP address )
Internet Boot Protocol
( See BOOTP )
internet daemon,
IP address
registering,
registering for DMS client,
J
joind,
joind daemon,
K
kernel
customized for DMS clients,
no build support for DMS client,
partial build support for DMS client,
types of build support for DMS clients,
kit
( See subset )
L
LAN,
host addresses on,
layered products
disk space on DMS servers,
License Management Facility
( See LMF )
listing
DMS clients,
installed subsets,
listing RIS products,
LMF
required for servers,
local area network
( See LAN )
lock files
DMS,
RIS,
M
management of RIS,
space required,
modifying
environment for DMS client,
client,
mountd daemon,
a
multiple client areas in DMS,
N
naming conventions
for DMS environments,
naming service,
registering DMS clients,
network
file system,
Network Configuration
Application
utility,
network daemons
for DMS,
Network File System
( See NFS )
network hardware address
modifying for DMS client,
network information
for DMS servers and clients,
Network Information Service
( See NIS )
network interface
for DMS clients,
network naming service
registering DMS client,
.new.. files,
NFS
checking server status,
used by DMS,
using a remote RIS area,
software,
NFS server
checking status,
NIS,
NIS utility,
no build support for DMS client,
O
operating system
installable by RIS,
overhead
disk space,
P
PAK
required for servers,
partial build support for DMS client,
partitions
on DMS server,
disk space for DMS,
planning disk space for RIS,
product
showing list of,
Product Authorization Key
( See PAK )
product environment,
profile set,
converting CDF to,
creating directories for,
deleting from RIS server,
registering for,
protected system files,
R
registering a client,
information required for DMS client,
information required for RIS clients,
problems in RIS,
with naming service,
cloned client,
remote boot
flow,
Remote Installation Services
( See RIS ) definition,
remove
DMS client root directory,
removing
a DMS client,
aDMS software environment,
aRIS client,
software subsets,
required software subsets
for DMS server,
requirements
for DMS clients,
response failures
servers using bootpd daemon,
restrictions
running bootpd and joind,
RIS,
architecture of,
checking client system registration,
converting CDF,
definition,
deleting profile set directory,
planning,
correcting entries,
listing products,
removing client system from registration,
removing multiple clients,
startup messages,
using an NFS mounted RIS area,
RIS area,
exporting and importing,
multiple,
RIS client
booting,
host naming conventions,
RIS daemons
inetd,
RIS files
bootptab,
RIS lock files,
RIS server defined,
risdb file,
controlling growth of DMS,
files in,
losing DMS customization during remove,
route for network
for DMS clients,
running bootpd and joind
restrictions,
S
security in DMS,
architecture of DMS,
description of,
DMS management tasks,
hardware compatibility for DMS,
hardware compatibility for RIS,
management tasks,
DMS,
operating system installation for
RIS,
planning disk space for DMS,
RIS setup preparation,
DMS,
software version compatibility for
RIS,
setld utility
listing subsets with,
sharing software
benefits,
showing
product list,
software sharing via servers,
choosing for DMS,
defined for RIS,
installing in existing DMS environment,
installing in existing RIS area,
removing,
required for DMS environments,
required for DMS server,
version compatibility for DMS,
space requirements
mandatory subsets,
startup messages
RIS,
startup process
RIS,
subnet mask
for DMS clients,
swap space
for DMS client,
SysMan Menu
using to install software for DMS,
system disk space,
limitations on,
T
TFTP,
TFTP protocol
requirement for,
tftpd,
tftpd daemon,
Token Ring
setting up a client on,
Trivial File Transfer Protocol
( See TFTP )
troubleshooting
client not in RIS database,
getname failure on RIS client,
loading incorrect kernel file,
bootpd daemon,
response failures on servers using the joind daemon,
RIS client password expiration,
RIS servers,
RIS server response problems,
troubleshooting DMS servers,
troubleshooting RIS problems,
U
copying to RIS server,
/usr area
files in,
utilities
utilupdate,
utilupdate utility,
V
/var/adm/ris/clients/risdb file,
version compatibility for RIS,
W
WLS
DMS client
building Asian kernel,
DMS server installation,
Y
Yellow Pages service
( See NIS )
YP
( See NIS )