Attach your station to the network by connecting one end of the Ethernet cable to the I/O port on the back of your station, and the other end into the network.

You can use the ping command to check your Ethernet connection. This command tests whether you can connect with another system on the Ethernet network. Perform the following steps:

If your ping command is not successful, there are several things you should check. Perform these steps:

When the station comes up, verify the station's software configuration. Log into the station as root.

Enter the chkconfig command to check that your station's standard networking software is correctly configured:

/etc/chkconfig 

You see information similar to this:

named      off
network    on
rwhod      off
timed      on
timeslave  off
gated      off
mrouted    off
rtnetd     off
snmpd      on
routed     on

---

Note: Your output will vary from the output above depending upon installed software and configuration flag settings.

---

If you are familiar with the network-related daemons, you can customize your configuration flags to suit your network needs. If you are not familiar with the network-related daemons, set your network-related flags as shown above. In particular, make sure that the network variable is configured on.

The hosts file is the hostname database. It contains information regarding known stations, from the perspective of the local station.

The /etc/hosts database is an ASCII file that you can modify with any text editor. The file contains lines of text that specify a station's address, its “official” name, and any aliases. The “official” name should be the fully qualified domain name. The address and name(s) are separated by blanks, tabs, or both. Comments begin with a pound sign (#) and continue to the end of the line.

Before you modify the hosts database, you should have a list of station names and valid Internet addresses of all stations in your network, as discussed in “IP Address Allocation” in Chapter 2. If the network has routers (stations with multiple network interfaces), there must be a valid Internet address and name for each interface. See “Internet Protocol Addresses” in Chapter 2 for a description of IP addresses.  

This example assumes that you are not using NIS or BIND. If you are using NIS, refer to the NIS Administration Guide for more information. If you are using BIND, refer to Chapter 6, “BIND Name Server”, for more information.

An /etc/hosts database is shown in this sample /etc/hosts file:

# This is a comment 
127.0.0.1   localhost
119.0.3.20  tuna.salad.com tuna  # tuna is an alias
119.0.3.21  chicken.salad.com  salad
119.0.3.22  walrus.salad.com  walrus

Each system must have a copy of /etc/hosts that contains entries for localhost and all of its network interfaces. As shipped, the /etc/hosts database contains two entries. The first entry is a name you can use to test the local network software:

127.0.0.1 localhost

When you reference localhost, the message is looped back internally; it is never transmitted across the network.

---

Caution: Many important programs depend on the localhost entry—do NOT remove or modify it. If the master copy of /etc/hosts is not maintained on that system or if you are using BIND or NIS, make sure that the host database contains the localhost entry .

---

---

Note: The address 192.0.2.1 is a special address; networking will not be enabled if the system is given that address.

---

You need to edit two files to enable a system to access the network:

If you change the system's name in /etc/sys_id, update the entry in /etc/hosts; if not, the network software will not initialize properly. If the following message appears during station startup, then the /etc/hosts and /etc/sys_id files are inconsistent and must be fixed:

*** Can't find hostname's Internet address in /etc/hosts

If your system is a gateway, each network interface must be assigned an Internet address, each on a different network, and have an entry in /etc/hosts, as described in “Setting Up a Router”.

It is important that each station have a consistent version of the host database. The proper method for maintaining the consistency depends on the size of your network and whether the network is connected to the Internet. You can use the rcp or rdist programs by means of a cron job to ensure that the hosts files stay in sync.

Edit the /etc/hosts file and add the hostnames and Internet addresses for all stations on your network. Each station on the network must have all station names in the local /etc/hosts file. If you have a large /etc/hosts file, the easiest way to install it on a new system is to set up a minimal hosts file with entries for the new system and for another system that has an authoritative copy of the hosts file. This allows you to get the new system on the net and copy the more complete hosts file from the other system (using rcp or ftp). Another option is to transfer the hosts file on tape or disk.  

Once you have determined your station's name, edit the /etc/sys_id file to give your station its new identity.

When your station comes back up, it should have the new station name as the login prompt.

Two network management tools, rup and ping, provide quick information about network connectivity. rup indicates if there is a physical problem with the network, such as your station being unable to contact the other stations. Since rup uses broadcasts as a default, it does not go through routers. If your station can see the other stations on the network, use ping to test communication abilities. ping uses the Internet Control Message Protocol (ICMP), which requests an echo from the designated station. It lets you know if you can transmit and receive packets to and from specific stations.

The /etc/init.d/network script is designed to automatically detect and configure a router with two interfaces if the default naming scheme for the interfaces is used. By default, the Internet addresses of the primary and secondary interfaces are derived from the /etc/sys_id file. The primary interface uses the name in the sys_id file. The secondary interface prefixes gate- to the name specified in the sys_id file.

To set up a router with two interfaces using the default naming scheme, follow this procedure:

If the router contains more than two interfaces, you must modify the /etc/config/netif.options file in addition to the /etc/hosts and /etc/sys_id files. In the netif.options file, you must define the interface type (enp1, ipg0, and so on). By default, the names for the third and fourth interfaces are gate2-$HOSTNAME and gate3-$HOSTNAME, where $HOSTNAME is the value returned when you issue the hostname command. If you want to modify the interface names, see “Modifying the Network Interface Configuration With the /etc/config/netif.options File”, for the detailed procedure.

To set up a router with more than two interfaces and using the default naming scheme, follow this procedure:

By default, when a station has two or more network interfaces, it automatically forwards (routes) packets between the two interfaces. If you do not want the station to serve as a router on its network, disable its route advertising.

To change forwarding dynamics, create or edit the /etc/config/routed.options file to contain the desired options. Some of the behaviors that can be altered by means of the /etc/config/routed.options file are listed below:

See the routed(1M) online reference page for more details.

Multicast routing is a delivery method in which a message is sent to a designated group of receivers by the shortest delivery path (see Figure 3-1). SGI systems implement the Distance-Vector Multicast Routing Protocol (DVMRP, originally specified by RFC-1075) with the mrouted process.

---

Note: As of IRIX 6.3, multicast routing can be used in combination with Network Information Service (NIS) to reduce the number of NIS servers needed throughout the network. For details, see the information on multicast-YP in the portmap(1M) and nisserv(7P) reference pages.

---

To turn on multicast routing:

Figure 3-1 shows an example network with three routers.

Figure 3-1. Network With Multicast Routers

If your routers do not support multicast routing, you can support multicast packets by creating tunnels between the networks. Any SGI workstation running IRIX Version 5.2 or later can be configured as the endpoint of a tunnel. With tunneling, the multicast packets are encapsulated inside unicast packets, and then are sent to the other end of the tunnel. They are converted back into multicast packets when they are received.

Figure 3-2 shows an example of a setup with a tunnel between networks A and C.

Figure 3-2. A Tunnel Between Networks A and C

To create the tunnel, edit the file /etc/mrouted.conf. Step-by-step instructions follow:

The IRIX copy of the /etc/rpc file contains additions that are essential for using certain multicast utilities if you're running the Network Information Service (NIS). If the NIS master is not running IRIX Version 5.2 or later, or is not a SGI workstation, verify that the /etc/rpc file on the NIS master includes these additions:

sgi_iphone 391010
sgi_videod 391011

The netmask option of the ifconfig command is used to interpret and define the network portion (subnets included) of the Internet address. A network mask defines the portion of the Internet address that is to be considered the network part. This mask normally contains the bits corresponding to the standard network part as well as the portion of the host part that has been assigned to subnetworks. If no network mask is specified when the address is set, it will be set according to the class of the network.

To configure a station's primary interface to recognize a subnetted Class B address that is using 8 bits of the host ID for defining the subnets, create or modify the /etc/config/ifconfig-1.options file and insert the following line:

netmask 0xffffff00

This netmask value indicates that for the primary interface, the upper 24 bits of the Internet address represent the network portion of the address, and the remaining 8 bits represent the host ID. The nonsubnetted netmask for a Class B address (in hexadecimal) would be 0xffff0000. The netmask value can be set using hexadecimal, dot-notation Internet address, or pseudo-network name formats. This entry must be made on all stations on the subnet.

---

Note: For stations with multiple interfaces, the network mask should be set for each interface in the appropriate ifconfig-*.options file.

---

Although variable subnet masks, that is, different masks on different interfaces, are supported as of IRIX 6.2, they are difficult to set up and maintain. It is therefore strongly recommended that you avoid using them unless there is no other way of accomplishing your site requirements.

When the netmask value is set, the station must be reconfigured and rebooted to incorporate the new network address into the stations routing tables. Always reboot routers before regular stations, because they provide routing information to other stations and networks.

Reconfigure the kernel and reboot the station to initialize your changes and interfaces. Some systems prompt for permission before reconfiguring the kernel, while others simply return a shell prompt. In either case, enter the reboot command explicitly:

/etc/autoconfig 
Automatically reconfigure the operating system? (y/n)y 
reboot 

When a station has more than two network interfaces, you must modify the name entries in the /etc/config/netif.options file to assign the interface order. Default order is assigned only to the first two interfaces. Additionally, if you want to change the order (first, second, and so on) or interface type assigned to a network interface, you must modify the /etc/config/netif.options file. This example makes the first FDDI interface secondary.

If you have no other changes, autoconfigure and reboot the station. Otherwise, repeat this procedure for each interface name change.

---

Note: When you alter the order of one network interface, the other interfaces in the station remain in their default relative ordering. For example, on a three-interface station (a=first, b=second, and c=third), if you were to make the default second the first (b=first), the remaining interfaces would be configured a=second and c=third.

---

To change the default interface address, modify the /etc/config/netif.options file. All interface names require valid Internet addresses as found in the /etc/hosts file. The $HOSTNAME variable pulls the station name from the /etc/sys_id file. This example changes the second, third, and fourth interface addresses as follows:

Follow these instructions to modify your network interface address according to the above example:

Repeat this procedure for each interface address change. If you have no other changes, reconfigure and reboot the station.

You can assign multiple IP addresses to a single network interface using the IP aliasing feature of the ifconfig command (see ifconfig(1M) ). This feature is useful if you find it necessary to use the same network interface for connections to several networks; it is also useful for maintaining an obsolete address for a host until users learn its new address. IP aliasing is supported on all network interface types.

The following subsections will help you understand and implement IP aliasing:

Manually Implementing IP Aliasing

When IP aliasing is implemented on a host, the address that the /etc/host file assigns to the hostname in /etc/sys_id is considered the primary address for the interface, and alternative names assigned by the ifconfig command are considered IP aliases. When you display network information (see “Collecting Network Statistics With netstat” in Chapter 4), the primary address of an interface is listed first, followed by its aliases.

To assign an IP alias, use this form of the ifconfig command :

# ifconfig interface alias address [netmask mask_num] [broadcast address]

---

Note: Be sure to read the information in “Guidelines for Assigning IP Aliases” (below) before assigning IP aliases.

---

You can specify a hostname from /etc/hosts instead of an IP address as the value of alias. For example, either command below assigns an IP alias to the ec0 interface. The interface in this example uses a netmask and broadcast address, but these fields are optional:

# ifconfig ec0 alias 128.70.40.93 netmask 0xffffff00 broadcast 128.70.40.255 # ifconfig ec0 alias plum netmask 0xffffff00 broadcast 128.70.40.255

Entrie in the /etc/gateways file should include all gateways reachable on the ATM or HIPPI network in the following formats:

The /etc/gateways file includes a series of lines, each in one of the following two formats.

Format 1:

host Nname [mask value] gateway Gname metric value [passive|active|external] 

Format 2:

host Hname gateway Gname metric value [passive|active|external] 

These are described as follows:

Lines that do not start with net or host must consist of one or more of the following parameter settings, separated by commas or blanks:

Also, rather than running routed with the -P parm options, you can instead add the parameter line parm to the /etc/gateways file.

The /etc/gateways file in Example 3-1 belongs to a host that has two HIPPI interfaces, one on the 192.168.0.0/27 subnet and the other on subnet 192.168.0.96/27. This host functions as a client. It sends RIP requests to one gateway on the 192.168.0.0/27 subnet, and to two gateways on the 192.168.0.96/27 subnet. It should neither generate nor process RIP packets on its et0 interface.

#if brodcast is not supported
#-- 192.168.0.0/27 subnet
host 192.168.0.1 gateway 192.168.0.1 metric 1 active i
#-- 192.168.0.96/27 subnet 
host 192.168.0.97 gateway 192.168.0.97 metric 1 active 
host 192.168.0.99 gateway 192.168.0.99 metric 1 active
 
ripv2_out 
rdisc_interval=45 
if=et0 passive 
if=et1 passive 

The /etc/gateways file in Example 3-2 belongs to a host that functions as a gateway. It has two HIPPI interfaces, one on subnet 192.168.0.96/27 and one on subnet 192.168.0.128/27. There is one other gateway with which this host should exchange routing updates on the 192.168.0.96/27 subnet, and one on the 192.168.0.128/27 subnet.

This host solely and permanently owns an IP address in the 192.168.0.202 subnet; this IP address is actually an alias that we want advertised as long as there is at least one active interface left, thus the subnet=192.168.0.202/31,1 entry. It should neither generate nor process RIP packets on its et0 interface.

#if brodcast is not supported 
#-- 192.168.0.96/27 subnet
host 192.168.0.97 gateway 192.168.0.97 metric 1 active 
host 192.168.0.99 gateway 192.168.0.99 metric 0 active 
#-- 192.168.0.128/27 subnet 
host 192.168.0.129 gateway 192.168.0.129 metric 1 active 
host 192.168.0.131 gateway 192.168.0.131 metric 0 active
 
subnet=192.168.0.202/31,1
 
ripv2_out 
rdisc_interval=45 
if=ef0 passive 

For further information, see the routed(1M) reference page.

The DHCP server is started by inetd(1M), as configured in the inetd.conf file. The basic operation of the DHCP protocol is a series of packet exchanges as follows:

If no entry is found, the server generates an appropriate IP address and hostname using its configuration files; see dhcp_bootp(1M).

The dhcp_bootp program is a server that communicates with DHCP and proclaim clients to provide host configuration information, including an IP address at minimum. If your site uses DNS to maintain the hosts map, you need some external mechanism (such as a script) to update the DNS map from the DHCP server. If your site uses NIS to maintain the hosts and ethers maps, dhcp_bootp must be run on the same machine as the NIS master server.

The DHCP server generally uses configuration parameters based upon the subnet number of the originating client request. The configuration files are all placed in the directory /var/dhcp/config and are named in the form config.<netnumber>. For example, the configuration file for clients on the 128.78.61 network should be named config.128.78.61.0. If the subnet configuration file does not exist, then the config.Default file applies instead. If the default configuration file is missing or unreadable, clients are configured to match the DHCP server itself.

To configure the DHCP server, you can do one of the following:

ProclaimServerMgr

ProclaimServerMgr is a graphical front end that displays the status and configuration of the proclaim server running on the local host. It displays the set of IP addresses and lease times that are currently assigned. Proclaim is an implementation of DHCP (dynamic host configuration protocol). Use the following command to invoke ProclaimServerMgr.

/usr/sbin/ProclaimServerMgr

Figure 3-3 shows the graphical interface for the proclaim server configuration.

Figure 3-3. ProclaimServerMgr Graphical User Intefrace

The File button on the main window opens a pull-down menu for editing options and configuration files as show in Figure 3-4.

Figure 3-4. ProclaimServerMgr File Button Pulldown Menu

The Options menu choice allows you to edit proclaim server options defined in the /etc/config/proclaim_server.options file.

The Configuration menu choice allows you to add, delete, and edit configuration parameters. Configurations are saved in files and define the IP addresses, lease times, and other options returned to clients. See “DHCP Server Configuration Parameters”, and the dhcp_bootp(1M) for details about configuration parameters.

To view messages logged by the server in the system log file (/var/adm/SYSLOG), launch sysmon(1M) from the main window by choosing the System Log Viewer menu item.

You can disable or enable DHCP by clicking the Proclaim Server On/Off button in the main window.

		 Serve_This_Network: 1
pro_address_counter: 1
pro_host_pfx_counter: 1
pro_netmask: 255.255.255.0
pro_lease: 604800
pro_host_prefix: n6634
pro_choose_name: 1
pro_ipaddress_range: 1-254
pro_dns_domain: engr.sgi.com
pro_nis_domain: engr.sgi.com
pro_mtu: 1500
pro_allnets_local: 1
pro_domask_disc: 0
pro_resp_mask_req: 0

The dhcp_relay program is a subnet agent that communicates with the main DHCP server to provide DHCP clients with host configuration information. If your site uses DNS to maintain the hosts map, you need some external mechanism (such as a script) to update the DNS map from the DHCP server. If your site uses NIS to maintain the hosts and ethers maps, your site's main DHCP server must be on the same machine as the NIS master. In any case, you should run dhcp_relay on all subnets besides the one with the main DHCP server.

The DHCP relay agent reads the configuration file /var/dhcp/config/dhcp_relay.servers to determine the location of the main DHCP server. This configuration file should contain the IP address and hostname of the DHCP server, on two separate lines.

Use the following command to invoke ProclaimRelayMgr.

/usr/sbin/ProclaimRelayMgr

The the ProclaimRelayMgr graphical interface (GUI) appears, as shown in Figure 3-5

Figure 3-5. ProclaimRelayMgr Graphical Interface (GUI)

The main window allows you to add and delete addresses and names of proclaim servers. You can enable or disable the relay-agent by clicking the Relay On/Off button in the main window.

The File button opens a pull-down menu for saving the options and server addresses displayed in the main window to a file (using the Save button). To view messages logged by the relay-agent in the system log file (/var/adm/SYSLOG), launch sysmon(1M) from the pull-down menu by choosing the System Log Viewer item.

To control the execution of dhcp_relay, perform the following:

For more information on how to configure the relay agent by running the ProclaimRelayMgr GUI, see the ProclaimRelayMgr(1M) reference page. If you prefer, you can configure relay agent options using your favorite text editor, following the steps documented on the dhcp_relay(1M) reference page.

The proclaim client communicates with a DHCP server to obtain host configuration parameters, including an IP address and an IP address lease at minimum. You can use proclaim to set up and configure new systems automatically, and also to move systems from one network to another without administrative intervention. The proclaim client can also verify configurations at reboot time.

Only the superuser can employ proclaim. If the primary network interface is changed, proclaim updates the netaddr variable in the NVRAM.

In the absence of the DHCPoptionsToGet keyword, proclaim requests the following configuration parameters from an available DHCP server:

If the server is configured in a manner where clients from specific subnets are allowed to choose their own hostname, then at the receipt of the DHCPOFFER message the client requests user input to either accept the offered hostname or specify a different one. This dialog between the server and client continues until a valid and unique mutually acceptable name is selected. Alternately, the -w option can be used to request a hostname and/or IP address non-interactively. The client will print an error and exit if the requested hostname or address is invalid.

Proclaim sleeps after obtaining a new lease or after verifying an existing lease, until it is time to renew the lease. The client wakes up at times specified by the DHCP protocol and attempts to renew the lease until it succeeds or the current lease expires. If the client is unable to renew the lease then it can shutoff network access depending on the use of the -E option.

To set up a the DHCP Proclaim Client, follow these steps:

The command is as follows:

/usr/etc/proclaim [ -B ] [ -b lease_time ] [ -d -s server_addr ] [ -E ] [ -e 2nd_interface ] [ -I ] [ -i ] [ -l lease_time ] [ -p ] [ -r lease_time -s server_addr ] [ -t repeat ] [ -x max_timeout ] [ -H hostname ] [ -w -h host_name -a ip_addr ]

The proclaim(1M) command accepts the following options:

Options File

Options may also be specified in the /etc/config/proclaim.options file. Options specified on the command line supersede those specified in this file. Lines beginning with a '#' are treated as comments. The option keywords in this file must be followed immediately by a colon, then by any number of tabs or spaces, and finally by the value of the option

The following keywords are supported:

The values for DHCPoptionsToGet and DHCPoptionsRenew are specified by listing the option numbers separated only by a comma. For example,

DHCPoptionsToGet:       3,6,26,27,41

DHCPoptionsToGet lists options to get in addition to the standard (default) configuration. This affects the initial lease request.

For a complete list of options, see RFC 2132.

DHCPoptionsRenew specifies what options should be included in the renew/rebind request. DHCPoptionsRenew is expected to be a subset of the options requested when the lease is acquired (the standard configuration parameters plus the additional ones listed in DHCPoptionsToGet).

Options returned from a renew/rebind request will be checked. If basic values have changed (IP address, host name, subnet mask, DNS domain, NIS domain) the host will be reconfigured and the /usr/etc/dhcpcopt script will be run. If only non-basic values have changed, only the script will be run. The dhcpcopt script file contains processing of the gateway, DNS domain and NIS domain. A script file /usr/etc/dhcpcopt.local may be created to add processing of options. If this file exists, dhcpcopt calls it for additional actions for the options returned.

Additional options which are not keywords specify whether the run-proclaim script should try to obtain configuration parameters for all the network interfaces on the system. If none of these options are present then the proclaim client is invoked for the primary interface only.

The options are:

Primary on|off
Interface 

The presence of an on invokes the proclaim client and off does not invoke it for the specified interface when the run-proclaim script is executed with a start argument. The value of interface is the name, for example, ec1, xpi1, etc.

For more information about setting up proclaim on client systems, see the proclaim(1M) reference page.

The following restrictions and limitations are present in this release:

An anonymous FTP account is a way for you to make information on your system available to anybody, while still restricting access to your system. An anonymous FTP account lets anybody log in to your system as the “anonymous” or “ftp” user. The FTP daemon does a chroot to the FTP home directory (~ftp) for anonymous FTP users, which effectively prevents them from accessing parts of the system that are not subdirectories of ~ftp; see chroot(1M) . If you prefer to limit access to users with passwords, after setting up an anonymous account continue with “Setting Up a Password-Protected FTP Account”.

The following procedure is designed to help you set up a network-accessible anonymous FTP account. As usual, understanding the various steps and continually monitoring how the account is used are necessary to protect your system security.

---

Note: If you are using IRIX 6.3, 6.4, or 6.5, you must copy certain files into the /lib32 and /usr directories. See “Updating FTP for IRIX 6.3, 6.4, and 6.5” for details. Otherwise follow the steps below.

---

If you place text in the /etc/issue file, it displays when a user connects to your system, before the FTP login prompt. You might want to include information here about the kind of services your FTP site offers, and whom to contact in case of problems. In addition, text in the ~/ftp/README file displays after an FTP user logs in.

Refer to crontab(1) , syslogd(1M) , and the file /var/spool/cron/crontabs/root for information on changing the frequency or nature of system log file maintenance—you may, for example, want to increase the length of time you keep log files. To help you keep track of the demands made on your public FTP server, see the

Password-protected FTP accounts allow only valid users to access your system. This is a way to make file transfer available to selected people, while still restricting access to the rest of your system. Only users with a password in /etc/passwd may connect to these FTP services. Additionally, restricted FTP users cannot access any part of a system that is not part of their home directory; the system does this with chroot.

The following procedure is designed to help you set up a network-accessible secure FTP account. As usual, understanding the various steps and continually monitoring how the account is used are necessary to protect system security. Before beginning this procedure, you must have completed all steps in “Setting Up an Anonymous FTP Account”..

The files and directories that make up the InfoSearch system of online documentation take up a great deal of space. In your network, there is no reason for each system to maintain a separate copy of the InfoSearch documents as long as all systems are at substantially the same software revision level. If the InfoSearch software revision level is the same across several systems, you can designate one system to serve the others with the InfoSearch files, thus freeing up disk space on the client systems.

Be sure to choose a server system that is not called upon to carry a heavy workload, and take your network performance into account before you begin. If your users use InfoSearch a great deal and your network is already burdened, you may find that your users will not appreciate the decreased response time from both InfoSearch and your network in general. Also, if a person is to use the InfoSearch server as his or her workstation, that person must be prepared to accept a certain (possibly substantial) amount of disk, CPU, and network overhead as a result.

There are two convenient ways to set up an InfoSearch server. These will be detailed in the next two subsections. Both methods require that you have the NFS software option installed. If you do not understand the terms and concepts behind NFS, you should read the ONC3/NFS Administrator's Guide and the NIS Administration Guide before undertaking these projects. The second method described here also requires a dedicated CD-ROM drive to hold the InfoSearch distribution media.

Setting Up a CD-ROM InfoSearch Server/Client System

With this method, you need not use up your disk space for the InfoSearch files if you have a CD-ROM drive you can dedicate to InfoSearch. You simply leave the CD with the InfoSearch distribution in the drive and link the mounted distribution to the directory where InfoSearch would have installed the files. The drawback of this system is that you must dedicate a CD-ROM drive to the purpose, but this method can be used with NFS to provide server access to your entire network.

---

Note: If you have a version of the InfoSearch Document Library installed on your client disk but you want to mount the books from the CD-ROM, you must remove all the files in /usr/share/InfoSearch/library before creating the symbolic link described in step 2. Use the versions remove command to cleanly remove the books, then check the directory to be sure all files have been removed.

---

If you wish to use the InfoSearch Viewer and Document Library from the CD-ROM and access the information from a local or remote system, follow the steps below.

On the server system with the CD-ROM drive:

1. Log in as root (superuser).

2. Insert the InfoSearch CD into the CD-ROM drive. If the drive is not mounted, use the System Manager or the mount command to mount the drive. The most common mount point is /CDROM. If the drive is mounted correctly, you should be able to change directories to /CDROM and see all the files in the InfoSearch CD. To see the files, use the command

   cd /CDROM/InfoSearch

   
   

3. As root, create a symbolic link from /usr/InfoSearch/library/SGI_bookshelves to the CD InfoSearch directory. You may need to create the directory /usr/InfoSearch/library if it doesn't exist. Use these commands:

   mkdir -p /usr/share/InfoSearch/library  ln -s /CDROM/InfoSearch/SGI_bookshelves /usr/share/InfoSearch/library

   Note that when you enter the link command on your client system, the entire command line goes on a single line. The command is broken across two lines in this example due to formatting limitations.

   At this point, the InfoSearch bookshelves are mounted on your server and available for use on that system. To allow users on other systems on your network to use the bookshelves, proceed to step 4.

4. If you want to share the bookshelves with other users on your network, export the /CDROM directory using the System Manager or the exportfs command:

   exportfs -i /CDROM

   
   

On each client system, perform the following steps:

1. Log in as root (superuser).

2. Run the inst command and give the following commands to install the InfoSearch.sw.client subsystem (you may want to install the InfoSearch.man.man and the InfoSearch.man.relnotes subsystems as well). You can get the installation software from the CD in the /CDROM/dist directory on the server.

   Inst> keep *  Inst> install InfoSearch.sw.client  Inst> go

   
   

3. Mount the bookshelves from the server. In the example below, the name of the server machine is capra. Use the following command:

   mount capra:/CDROM/InfoSearch/SGI_bookshelves /usr/share/InfoSearch/library/SGI_bookshelves

   
   

   ---

   Note: When you enter the mount command on your client system, type the entire command on a single line. The command in the previous example is broken across two lines due to formatting limitations.

   ---

   
   

Before attempting to use RSVP, make sure a supported network interface together with the appropriate driver are installed on the system. To determine which network interfaces are present on the system, use the hinv command:

% hinv

The output should reveal the output as listed in Table 3-2.

With the supported hardware installed, verify that the appropriate level of the IRIX operating system is installed. You can check currently installed software using the desktop Software Manager, or from the command line, using showprods. If you need to install the software, refer to IRIX Admin: Software Installation and Licensing for instructions.

When your system is configured to handle RSVP, the next step is to start the RSVP daemon, /usr/etc/rsvpd. To have rsvpd start automatically during system boot, use the chkconfig command:

# chkconfig rsvpd on

This should then activate your system to use the RSVP facility next time you boot. The rsvpd(1M) reference page provides details of available command line options.

The state of network bandwidth reservation may be monitored using the command rstat. The output of the command identifies each interface, line by line, the session address and port, and the next hop address. If no reservations exist for the session, no resv is displayed. See the rstat(1M) reference page for details and options.

RSVP can be configured on a particular interface using the command psifconfig. You can set the reservable bandwidth on the interface, see how much bandwidth is currently reserved, or completely disable or restore RSVP on that interface. See the psifconfig(1M) reference page for details of options.

If you prefer, you can configure rsvpd and monitor current RSVP status in graphical form using the Internet Gateway, see “Accessing Network Services through Internet Gateway”. The following options may be handled in this way:

You can, however, use RSVP from the command line, without the Internet Gateway.

Because RSVP is an extremely new technology, some troubleshooting should be expected. The following represent the first effort at determining what may occur.

# killall -TERM rsvpd

Unplugged or loose cables are the most common problem that causes Ethernet-related error messages. For example:

unix: <ethernet_device>: no carrier: check Ethernet cable

This message means that the carrier was not detected when attempting to transmit. One recommendation is to check to see if the Ethernet cable is unplugged from the back of the machine. For detailed instructions on connecting the cable, see your owner's guide. You do not need to shut down the system to connect or disconnect the cable. If you re-connected the cable, test the network connection.

After determining that the transceiver cable is plugged into the back of the machine and also into the transceiver box, look for other possible reasons for failure.:

For more information on this error, see the reference page for ethernet(7) .

Often the controller tried to transmit a packet but received a late collision signal from another machine. This usually indicates a problem in the Ethernet cable layout. The most frequent causes of this problem are excessively long cables and loose cable connections.

To isolate the problem, first look for violations of the Ethernet cable limits. For 10BASE5 cable (thicknet) the maximum segment length is 500 m; for 10BASE2 cable (thinnet) the maximum segment length is 200 m. The length of a transceiver cable (the cable that goes between a machine's Ethernet port and its transceiver) should not exceed 50 meters. If all cables are within the specified limits and all connectors are firmly seated, this error could indicate a hardware problem in an Ethernet controller or transceiver. Some recommendations are:

A bad Ethernet controller somewhere on the network can cause problems by sending packets that are too large or too small, causing errors like this:

unix: <ethernet_device>: packet too small (length = <packet size>)

unix: <ethernet_device>: packet too large (length = <packet size>)

The Ethernet controller received a packet that was smaller than the minimum packet size or larger than the maximum packet size allowed by Ethernet. This problem is caused by another machine with a bad Ethernet controller or transceiver. Some recommendations are

For more information on this error, see the reference page for ethernet(7) .

When your system cannot contact a network system, an error message similar to this is displayed:

portmapper not responding: giving up

This problem occurs in one of these situations:

The two most common errors messages are:

If your system has more than one network interface (additional interfaces are usually fiber-optic [FDDI] links or SLIP connections or other Ethernet boards) you can easily perform the above checks on each network interface.

To check your other network interfaces, enter the netstat -in command. You see output similar to the following:

Name Mtu   Network    Address    Ipkts Ierrs Opkts Oerrs Coll
ec0  1500  128.70.0   128.70.0.9  15    0     15    0     24
ec1  1500  128.70.2   128.70.2.5  15    0     15    0     24
sl0  1006  (pt-to-pt) 128.70.0.9  0     0     0     0     0
lo0  8304  loopback   localhost   8101  0     8101  0     0

The second Ethernet connection is to the network 128.70.2, a different LAN from the first Ethernet connection. The address of the local station on the second LAN is 128.70.2.5. To check that connection, use the ping command to test the connection to another station on that network.

There is also a SLIP link running in this example. The SLIP link extends the same LAN as ec0 to another system in a different location. To test this link, find the hostname or IP address of the station at the other end of the SLIP link and use the ping command to test connectivity.

The lo0 interface is the loopback network interface on the local host.

To determine which piece of hardware controls which interface, enter the command

ls -lS /hw/net/XXN

where N is the network interface number of type XX. For example:

% ls -lS /hw/net/ef0
crw-------    1 root     sys            0 Jun 6 14:14 /hw/net/ef0 -> /hw/module/4/slot/io1/baseio/pci/2/ef