Share trees, client trees, and swap trees should be created from an official release of Silicon Graphics software. Silicon Graphics software is originally distributed on compact disc with read-only memory (CD-ROM). On some networks, a copy of this software is available from a central distribution source on the network. You can use either source to install diskless software, as long as you use an official software release.

At minimum, the IRIX 6.5 source must include the Silicon Graphics Execution Only Environment product (eoe) and its supporting software, and the NFS product option, nfs. A group of subsystems from each of these products is required to install diskless software (see Table 2-2 for details).

Use the questions that follow to evaluate the suitability of a server on which you plan to install the diskless tree. If you determine that any procedure described in this section is necessary, complete the procedure before you begin diskless installation.

1. Is the server reliable?

The ideal choice for a diskless server is a network host that is able to provide uninterrupted service to its clients for extended periods of time. Hosts that are subject to frequent shutdowns, such as laboratory systems, those used for software builds, or hosts subject to interruptions in service, are not likely to prove satisfactory as diskless servers.

2. Does the server have ample disk space?

On average, approximately 1.5 gigabyte (GB) of disk space is required for a diskless tree with these characteristics:

3. Is the server running the necessary software?

The IRIX version implemented on a server must be the same as or more recent than the IRIX version of any share tree that it supports. In addition, a server running 32-bit IRIX cannot support share trees of 64-bit IRIX. See the release notes shipped with your software for more specific compatibility information.

To determine the version of IRIX running on a server, use the uname command with the release option (-r), as shown in the following example. Do not install a share tree with a higher revision level than appears in the output from this command:

% uname -r
6.5 

You should also verify that the host acting as the diskless server is running nfs.sw.diskless_server, the software subsystem that supports the diskless server function. To verify, enter the versions command and look for the diskless server subsystem in the command bitoutput, as shown in this example:

% versions nfs
I  nfs.sw.dskless_server  08/18/97  Diskless Server Support

4. Is the TFTP environment set up correctly?

Client boot files are transferred from the server by means of the trivial file transfer protocol (TFTP). The server must contain a user account that owns TFTP (see the tftp reference page). By default, the owner of TFTP is guest. If you want a user other than guest to own TFTP (for security reasons, for example), you must modify the file /etc/inetd.conf to specify a different owner (see the inetd reference page). If you plan to install software by downloading it from a remote host, be sure that TFTP security is correctly configured on the remote system (see tftpd).

You must add /var/boot to the end of the tftp entry in the /etc/inetd.conf file; this is because in order to boot a diskless client the path defined as /var/boot needs to be defined for TFTP to allow the client to find its kernel.

Additionally, the second tftp line containing udp6 should be commented out.

5. Is an NIS domain name assigned to the server?

To support diskless clients, a server must have an NIS domain name, whether or not it is running the network information service (NIS). To determine whether a server has an NIS domain name, use the domainname command:

% domainname
my.domain.name

If this command returns no output, the server has no NIS domain name. It must be assigned a domain name (even a fictitious one) for diskless software to operate correctly. To set a domain name, enter this command as the superuser:

# domainname fakedomain

If you would like the domain name to be set automatically when the server is rebooted, issue this command:

# echo fakedomain > /var/yp/ypdomain

The system looks for the file ypdomain that contains the domain name.

6. Are there NFS export conflicts?

Be sure that the parent directory of your diskless tree is not listed as an NFS export. This condition causes NFS conflicts, which prevents the installation scripts from exporting diskless directories correctly and can also compromise security on the exported files. For example, if the diskless tree is installed in the directory /usr/diskless, the /usr directory should not be exported. To check for export conflicts, examine the server's /etc/exports file. If the parent directory of the diskless tree is listed, adjust the NFS configuration before implementing the diskless server.

7. Is the notation in the host database correct?

Client hostnames must be listed in the server's /etc/hosts in dot notation (see hosts(4)). For example, your entries in hosts should look something like this:

192.0.2.5 starlite.fakedomain.com starlite

8. Can BOOTP requests from clients reach the server?

If the server is on a different network from any of its clients, BOOTP forwarding must be enabled on the routers between the networks. See question 1 in the “Checking a Client” for details.

In addition, it may be desirable to edit /etc/inetd.conf to uncomment the simpler bootp line and comment out the bootp line containing the DHCP options.

9. Is bootparams enabled on the server?

If the bootparams argument commented out in the inetd.conf file, it prevents the server from responding to client requests for boot information. Remove the comment character (#) to set bootparams on.

Use the questions below to check the suitability of a client for diskless operation. Some changes that might be required as a result of this checkout are changes you can make yourself; others might require additional members of your technical team. Any changes indicated by this check must be made before you begin diskless installation.

1. Is the client on the same network as the server?

Client systems initially request critical information from the server using the Internet Bootstrap Protocol (BOOTP). If a client is and its server are located on different networks, the routers connecting the networks must be configured to perform BOOTP forwarding (see the bootp(1M) reference page for details). If you do not have responsibility for configuring network routers, contact your network administrator about this router configuration requirement.

2. What hardware components does the client contain?

When you prepare the share tree configuration file, it helps to know the model names of your diskless workstations and the designations for the hardware components that the workstations contain. You can use the hinv command at client workstations to get component information. Make a list of these components to help you during the procedures in Chapter 3.

Table 2-1 shows the components of Silicon Graphics workstation models.

---

Note: Additional information about workstation architecture is provided in the /var/boot/client.dat file and in Chapter 4 of this guide.

---

Every client in a diskless implementation must be assigned a unique Internet address so that it can be recognized as a network host. On some networks, the addresses of hosts with which a server communicates (including its diskless clients) are maintained in the server's /etc/hosts file. On networks using NIS or DNS services, diskless server and client entries must be added to the database used by these services.

If you are not the administrator for these services, advise the appropriate person to make the necessary entries for your diskless hosts. If you plan to assign Internet addresses yourself and need more information, see the instructions for adding hosts to a network in one of these Silicon Graphics publications:

The diskless tree is implemented as server directories that contain a share tree, client trees, and swap trees for each release of IRIX that a server supports. When these directories are well organized, diskless software is easier to install and maintain than when directories are organized in a random fashion. The directory organization scheme in this section can serve as a guide to organizing your own diskless tree.

Diskless Filesystems

If possible, a diskless tree should be contained in its own filesystem; for large installations, an entire disk might be dedicated to the diskless tree. Using a dedicated filesystem makes administering NFS software easier. If the diskless tree is not in its own filesystem, the parent directory of the diskless tree should not be listed in the server's /etc/exports file (see “Checking a Server” for details).

Figure 2-1 shows the organization and naming of the first- and second-level directories of a filesystem for the diskless tree.

Figure 2-1. Level 1 and 2 Directories in the Diskless Trees

The top directory of the diskless tree, /diskless in Figure 2-1, is referred to as the root of the diskless tree. Similarly, /diskless/share, /diskless/client, and /diskless/swap are considered the root of the share, client, and swap trees, respectively.

Planning Share Trees

The root directory for share trees, /diskless/share in Figure 2-1, contains a share tree for each release of IRIX that the server supports. Each share tree contains the files normally located in the /usr, /sbin, /lib, and /stand directories on a standalone workstation.

Figure 2-2 illustrates the directory structure and typical contents of a share tree.

Figure 2-2. Typical Share Tree Contents

A share tree of IRIX 6.5 that supports clients with a minimum software configuration and the IRIX desktop requires approximate 700 megabytes of disk space. However, the subsystems that you install in a share tree greatly influence disk space requirements. To save space on the server, do not include applications in the share tree; instead, mount the applications from other NFS servers where they are already installed.

---

Note: If you plan to mount NFS directories from a server other than the diskless server, you must edit the automatically generated copy of /etc/fstab (describe in “Automatic File Updates”) to contain these entries.

---

Table 2-2 provides a list of the required subsystems for an IRIX 6.5 share tree and the size and description of each subsystem, assuming a 64-bit client such as Silicon Graphics Tezro or Silicon Graphics Fuel.

The base minimal share tree size is 695,932 KB.

Table 2-2. Space Requirements for a Basic Share Tree

Subsystem Name	Size (KB)	Description
4Dwm	816	Desktop Window Manager Man Pages
desktop_base	10,728	Desktop Base Software
desktop_eoe	14,296	Desktop Environment
desktop_tools	1,716	Desktop Tools
eoe	307,804	IRIX Execution Environment
nfs	8,340	NFS Support
x_eoe	119,388	X11 Execution Environment
Viewkit_eoe	10,804	Viewkit Execution Environment
c++_eoe	5,900	Standard Execution Environment (C++)
compiler_eoe	47,864	IRIX Standard Execution Environment (Base Compiler)
dmedia_eoe	125,044	Digital Media Execution Environment
ifl_eoe	17,940	Image Format Execution Environment
il_eoe	44,628	ImageVision Library Execution Environment
media_warehouse	2,032	Desktop MediaWarehouse
motif-eoe	30,960	IndigoMagic Execution Software (Motif0
tooltalk_eoe	9,492	ToolTalk Execution Environment
websupport_eoe	6,036	Websupport
webviewer	12,588	WebViewer Library Execution Environment
field_diags_sysco	39,484	Standalone System Controller Environment
insight	1,104	Online Documentation Software
insight_base	8,532	Online Documentation Base Software
inventor_eoe	42,444	Inventor Execution Only Environment
kerberos	9,404	MIT Kerberos
openssh	9,016	OpenSSH Server and Client
openssl	22,620	OpenSSL Libraries
accessx	396	Access for Movement-Impaired Users
mam	3,112	Motif Accessibility Module
netscape	4,000	Netscape Communicator Client

If you need additional space-requirement information, see the space requirements listed in the release notes that accompany the software you plan to install.

Planning Client Trees

The root directory for client trees, /diskless/client in Figure 2-1, contains a directory for each client that it supports. Each client tree contains the files normally located in the root (/) directory on a standalone workstation.

Figure 2-3 illustrates the organization of client tree directories and the typical contents of a client tree.

Figure 2-3. Typical Client Tree Organization and Contents

A newly installed client tree requires approximately 58 megabytes of disk space. However, because the client tree allows read and write access, space requirements may increase as a result of usage patterns on the client. This increase should be considered in your planning.

To save disk space and simplify software maintenance on the diskless server, mount /usr/people and /var/tmp from a different NFS server. This configuration makes it easier to upgrade system software and relocate user files when these changes become necessary.

---

Note: If you plan to mount NFS directories from a server other than the diskless server, you must edit the automatically generated copy of /etc/fstab (describe in “Automatic File Updates”) to contain these entries.

---

Planning Swap Trees

The root directory for swap trees, /diskless/swap in Figure 2-1, contains a swap tree for each client that it supports. The swap tree for an individual client is a directory containing a raw data file that provides swap space for virtual memory functions. By default, the size of the swap set up during diskless installation is 64 megabytes. But swap space size is a configurable variable that you can set during a client tree installation and change after the swap tree is installed.

To determine the amount of swap space to allocate, consider the application requirements of your users. In cases where gui applications for email, news, and web surfing are the principal applications, consider increasing swap space to 128 megabytes. In cases where swap space usage is heavy—when users run compute-intensive applications, for example—consider increasing the default swap space size or adding a local swap disk to the client workstation (see Chapter 6 for details).

Figure 2-4 illustrates the organization of swap tree directories.

Figure 2-4. Typical Swap Tree Organization

Diskless software consists of installation utilities and configuration files that set up the share tree, client trees, and swap trees for a diskless implementation:

The installation procedure is always done on the host that will act as the server system. The procedure consists of five basic steps:

If you have more than one client class, you need to repeat steps 3, 4, and 5 for each class that is being installed (see “Influence of Client Classes”). If you are installing multiple IRIX releases, you need to repeat the entire procedure for each IRIX version that you install (remember that 32-bit and 64-bit versions of the same IRIX release are considered two separate operating systems in a diskless implementation).

Figure 2-5 illustrates the flow of tasks in the installation process. Notice that the share tree is always installed before any of its client trees. This order is critical, because client trees are built from software contained in the share tree. The swap tree for a client is automatically built at the same time as its client tree.

Figure 2-5. Flow Diagram of Installation Tasks