[Previous Section] [Back to Table of Contents] [Next Section]

IRIX Advanced Site and Server Administration Guide


Chapter 17
Setting Up a Network

This chapter contains procedures for:


Configuring an IRIS for a Network

The procedure in this section explains how to configure an IRIS station, with one interface, for an Ethernet network using its local /etc/hosts file (without BIND or NIS). Configuring the station takes six steps:

    bringing the station down

    attaching the station to the network

    checking the station's network configuration

    modifying the /etc/hosts database

    naming the station

    testing the connection

Each of these steps is explained in the sections that follow.

Attaching Your Station to an Ethernet Network

Attach your station to the network by connecting one end of the Attachment Unit Interface (AUI) cable to the Ethernet I/O port and the other end to the network transceiver or Medium Access Unit (MAU).

If your transceiver model has status lights, make sure that the power light on the transceiver comes on when you attach the AUI cable to your workstation and the transceiver. This light indicates that the Ethernet card or the integral Ethernet controller is alive. Your station must be powered on to activate the power light on the transceiver.You may also see another light which indicates that your link to the network is activated.

If the power light on the transceiver is lit or if your transceiver or MAU has no lights, bring your station back up into multi-user mode now.

Checking Your Ethernet Connection

To make sure your ethernet connection is functional, perform the steps outlined in this section. You will use ping -r to check the connection. This command ensures that you can connect with at least one other system on the ethernet network. Perform the following steps:

    Obtain the hostname of at least one reliable station on the local area network to which your system is connected. If possible, get the fully qualified hostname and the IP address. (For example, a hostname might be hancock, and the fully qualified hostname might be hancock.corp.gen.com, while the IP address might be 192.70.0.356.) It is important that the station you select have a reliable ethernet connection and that it is up and running.

    Once you have obtained a hostname and IP address, give the command:

    ping -r hostname 

    You should see a series of records indicating the returned packets from the remote host. For example (using our example system):

    PING hancock (192.70.0.356): 56 data bytes
    64 bytes from 192.70.0.356: icmp_seq=0 ttl=255 time=2 ms
    64 bytes from 192.70.0.356: icmp_seq=1 ttl=255 time=2 ms
    64 bytes from 192.70.0.356: icmp_seq=2 ttl=255 time=2 ms
    64 bytes from 192.70.0.356: icmp_seq=3 ttl=255 time=2 ms
    64 bytes from 192.70.0.356: icmp_seq=4 ttl=255 time=2 ms

    Press <Ctrl>-C or your Delete key to stop the ping command. You will see the tallied results of the ping command. For example:

    ----hancock PING Statistics----
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min/avg/max = 2/2/2 ms

    If your network connection is working, you should see results comparable to those above. Your ping results should show 0% packet loss and an equal number of packets transmitted and received. If some packets are being lost, the first thing you should check is the tightness and quality of the cable connections. Loose cables are frequently the cause of lost packets. The round-trip time factors are a function of the size and general load of your network, and not necessarily an indication of a problem with your ethernet connection.

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

    Try to ping the station by its IP address. For example, using our sample host hancock, use the command:

    ping -r 192.70.0.356 

    Try to ping a different station on your local network.

    Check the network configuration on your system with the netstat -in command. You should see information similar to this:

    Name Mtu  Network  Address    Ipkts Ierrs Opkts Oerrs
    ec0  1500 192.70.0 192.70.0.9 18    0     18    0 

    The ec0 entry indicates your primary ethernet connection. The Ipkts and Opkts fields indicate the number of inbound and outbound packets the network interface has processed. The Ierrs and Oerrs fields indicate the number of errors in input and output, respectively.

    For the purposes of this troubleshooting session, though, check that the portion of the IP address shown under the Network heading match the IP address of the hostname that you attempted to ping. If the network addresses are not the same, the station is on a different network and the ping likely failed for that reason. Find a system to ping that is on your immediate local network.

    Check the /var/adm/SYSLOG file for ethernet error messages.

    Check to ensure that other stations are operating normally on the local network.

    Check to ensure that the correct software (eoe2.sw.tcp) package has been installed on your system.

    Check the physical connections to the ethernet cables and transceivers for tightness and connection. A good indicator is the status light display on your transceiver (if your transceiver has these lights.). If your ethernet hardware is loose or disconnected, the /var/adm/SYSLOG file and your system console should both show messages such as:

    ec0: no carrier: check Ethernet cable

    If all connections are tight and you still receive errors, replace the pieces of the ethernet connection outside your system. (The cable and transceiver.) Different transceivers require different wire connections, and sometimes the wrong cables are used.

    If you receive a message indicating that another host has the same IP address, find out which host has the same address and determine which host has set their address incorrectly. (It is more likely that the same address was accidentally assigned to a second system, or that the new system being tested incorrectly set the address.)

Troubleshooting Your Ethernet Connection

This section addresses some of the common ethernet related problems.

Cable Problems

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 carrier was not detected when attempting to transmit. Some recommendations are:

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). See the "Troubleshooting" chapter in the Personal System Administration Guide for detailed instructions on troubleshooting network problems.

Packet Size

An error message regarding the packet size is explained here.

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

The ethernet controller received a packet that was smaller than the minimum Ethernet packet size of 60 bytes. 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).

Unable to Contact Server System

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:

Checking Additional Network Interfaces

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, give the netstat -in command. You see output similar to the following:

Name Mtu   Network    Address    Ipkts Ierrs Opkts Oerrs Coll
ec0  1500  192.70.0   192.70.0.9  15    0     15    0     24
ec1  1500  192.70.2   192.70.2.5  15    0     15    0     24
sl0  1006  (pt-to-pt) 192.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 192.70.2, a different LAN from the first ethernet connection. The address of the local station on the second LAN is 192.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.

Checking the Network Software Configuration

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

Issue the chkconfig(1M) 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.

Modifying the hosts database

Before you modify the hosts database, you should have a list of station names and valid Internet addresses of all stations in your network. If the network has routers (stations with multiple network interfaces), there must be a valid Internet address and name for each interface. See "Internet Addresses" for addressing information.

The hosts file is the host name database. It contains information regarding known stations, from the perspective of the local station. This example assumes that you are not using NIS or BIND. If you are using NIS, refer to the NFS and NIS administration guides for more information. If you are using BIND, refer to Chapter 19, "The BIND Name Server," for more information.

Edit the /etc/hosts file and add the host names and Internet addresses for all stations on your network, including this station. Each station on the network must have all station names in the local /etc/hosts file. You can use the rcp or rdist programs by means of cron to ensure that the hosts files stay in sync.

Caution: Do not remove or modify in any way the loopback host address 127.0.0.1. This is a special Internet address that must be present for testing and loopback facilities.

Modify the /etc/hosts file. For this example, the local station is setup1 and the network includes three other stations, setup2, setup3, and setup4. The network is a Class C network, 192.60.31.

vi /etc/hosts 
127.0.0.1       localhost loghost
192.60.31.1     setup1
192.60.31.2     setup2
192.60.31.3     setup3
192.60.31.4     setup4

Save and exit the /etc/hosts file.

Naming Your Station

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

    Remove the default station name (IRIS) and replace it with the new station name (setup1 for this example). You can use this command:

    echo setup1 > /etc/sys_id 

    For the change to take affect, reboot your station with this command:

    reboot 

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

Testing Your Network Connectivity

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.

    Issue the rup command to determine if your station can contact the other stations on the network:

    /usr/bin/rup 

    You should get output on each of the stations on your network. The other stations on your network must be up for your station to get a user-friendly response. If the other stations are powered on and attached to the network but not up in user mode, the information comes back in hexadecimal.

    Issue the ping command to see if your station can communicate with the other stations on the network:

    /usr/etc/ping station_name 

    Let the output run a few seconds, then use <Ctrl-C> to break it. Pay particular attention to the ping statistics. ping gives you the number of packets transmitted, number of packets received, percentage packet loss, and round trip time (min/avg/max). These are all good indicators as to the general condition of your network. Obviously, you want 0% packet loss and a fast round trip time.


Setting Up a Router

A router is a station with multiple network connections that forwards packets between networks. This section provides the configuration procedure for a router with two and a router with more than two interfaces. A station can have multiple interfaces and not act as a router. The procedure for turning forwarding off on a station with multiple interfaces is also provided in this section.

Configuring a Router with Two Interfaces

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:

    Log in as root.

    Assign valid Internet names and addresses to both interfaces in the /etc/hosts file. For example, the /etc/hosts file entries for the primary and secondary interfaces on the station biway might look like this:

    192.26.75.2     biway
    192.26.80.3     gate-biway

    Ensure that the router has the appropriate name in its /etc/sys_id file. Following this example, the /etc/sys_id file should look like this:

    biway

    Reconfigure the kernel and reboot the station to initialize your changes and interfaces. Some systems will prompt you for permission, as in the following example. Others will simply return a shell prompt. In either case, you must explicitly give the command to reboot the system.

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

Note: If you do not want to use the standard router naming scheme, you must modify the /etc/config/netif.options file. "Modifying the Network Interface Configuration" details the procedure for changing an interface name.

Configuring a Router with More Than Two Interfaces

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" for the detailed procedure.

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

    Log in as root.

    Assign valid Internet names and addresses to all interfaces in the /etc/hosts file. For example, the /etc/hosts file entries for the router freeway, with four interfaces, would look like this:

    192.26.30.1     freeway
    192.26.32.4     gate-freeway
    192.26.41.5     gate2-freeway
    192.26.59.6     gate3-freeway

    Ensure that the router has the appropriate name in its /etc/sys_id file. Following this example, the /etc/sys_id file should look like this:

    freeway

    Modify the netif.options file to define your interface types. For this example, the third and fourth interfaces are FDDI (ipg*). Change the if3name and if4name variables from:

    if3name=
    if4name=

    to

    if3name=ipg0
    if4name=ipg1

    Save your changes to the netif.options file.

    Reconfigure the kernel and reboot the station to initialize your changes and interfaces. Some systems will prompt you for permission, as in the following example. Others will simply return a shell prompt. In either case, you must explicitly give the command to reboot the system.

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

Turning Forwarding Off

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 forward (route) packets between the networks, you must disable supplied routing information and IP forwarding.

    Modify the /etc/config/routed.options file so the router will not supply routing information about general network routes (-q) or local interface routes (-h). Type:

    echo -qh > /etc/config/routed.options

    Using the chkconfig(1M) command, turn the network off momentarily, then start it again.

    When the network comes up, verify that it is not forwarding packets with the netstat tool. Type:

    netstat -s -p ip |grep forward

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.

Turning On Multicast Routing

If you're using Silicon Graphics workstations as routers, you can turn on multicast routing by doing the following:

    Identify the routers on each network that need to support multicasting. Make sure that the routers you select are running IRIX Version 5.2 or later.

    If you haven't already done so, install on each router the eoe2.sw.ipgate subsystem from your IRIX Version 5.2 distribution source. Run autoconfig(1M) if necessary.

    As root, enter the command:

    chkconfig mrouted on 

    Restart the system with the reboot command.

Understanding Where Multicast Packets are Forwarded

Figure 17-1 shows an example network with three routers. Each bubble labeled Host represents a system on the network.

ch17-1.gif

Figure 17-1 : A network with multicast routers.

Setting Up Tunnels to Support Multicast Packets

If your routers do not support multicast routing, you can support multicast packets by creating "tunnels" between the networks. Any Silicon Graphics 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 17-2 shows an example of a setup with tunnels.

ch17-2.gif

Figure 17-2 : Diagram showing tunnels between networks.

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

    Select the systems on each network that you will use for the sending and receiving end of the tunnel.

    Choose a system that's running IRIX Version 5.2 or later, is fast, and is not used extensively. The audio and video data may be intermittent if the system you select is slow or overloaded.

    If you haven't already done so, install the eoe2.sw.ipgate subsystem from your IRIX distribution source.

    As root, edit the file /etc/mrouted.conf on the sending and receiving end of the tunnel. Note that these endpoints can be separated by many routers; you can use any machine on the network that is running IRIX Version 5.2 or later.

    Add the following line for each network to which you want to establish a tunnel.

    tunnel <local IP address> <remote IP address>

    In the above example, the system on network D would have the following entry:

    tunnel 192.26.58.1 192.48.170.2 

    The system on network A would have the following entry:

    tunnel 192.48.170.2 192.26.58.1 

    You can specify other optional settings for the tunnel. For details, see the mrouted(1M) man page.

    Restart the system.

Note: One copy of the multicast packets is sent for each tunnel entry in mrouted.conf. This results in extra network traffic. For example, suppose you have a workstation with one network interface and you set up tunnels to workstations on three other networks. The packets are replicated three times.

Update /etc/rpc for NIS Users

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

sgi_iphone 391010
sgi_videod 391011


Subnetting a Network

Implementing the subnet address scheme is a very simple procedure. The following must be done to implement subnetting:

    Setting the netmask

    Rebooting the station

Note: If you have not done so already, read Chapter 16, "Planning a Network." It contains information about partitioning Internet addresses for subnetting.

Setting the Netmask

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.

Rebooting the Station

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, since they provide routing information to other stations and networks.

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

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


Setting Up Anonymous ftp

This section summarizes how to set up an anonymous ftp account. If you have not done so already, read "Planning for Network Security". It contains security information pertaining to ftp.

Follow these procedures to set up an anonymous ftp account:

    Create the anonymous ftp password entry. You may choose the location of the home directory. This example uses /usr/local/ftp as the home directory. The example entry would look like this:

    ftp:*:997:999:Anon FTP Account:/usr/local/ftp:/dev/null

    Make a home directory for the anonymous ftp account:

    mkdir -p /usr/local/ftp 

    Set permissions, owner, and group for ftp directory with the following command:

    cd /usr/local; chmod 555 ftp; chown ftp.other ftp 

    Create the mini file system with the following commands:

    cd /usr/local/ftp 
    mkdir bin etc pub lib dev 

    Set permissions, owner, and group for bin, lib, dev, and etc directories with the following commands.

    chown root.sys bin etc lib dev 
    chmod 555 bin etc lib dev 

    Set permissions, owner, and group for pub directory with the following commands.

    chown ftp.other pub 
    chmod 777 pub 

    Copy the ls command from /bin to ftp's bin directory and make it executable only with the following commands.

    cp /bin/ls bin 
    chmod 111 bin/ls 

    Copy the password and group files from /etc to ftp's etc directory and set restrictive permissions with the following commands (note the lack of a leading slash (/) on the second argument of the copy commands):

    cp /etc/passwd etc/passwd 
    cp /etc/group etc/group 
    chmod 444 etc/* 

    Copy some library files to ftp's lib directory and change their permissions:

    cd /usr/public/ftp/lib 
    cp /lib/rld . 
    cp /lib/libc.so.1 . 
    chmod 555 * 

    Please check to make sure that the guest account is listed in the /etc/passwd file.

    To place files in the restricted/anonymous area, local users must place the files in the /usr/local/ftp/pub subdirectory.

    Caution: An important issue to consider is the passwd file in ftp's /etc directory. This file can be copied by users who use the account. They may then try to break the passwords of users on your machine for further access. Therefore, remove any unnecessary users and change all passwords in this file to an invalid password such as "*". A good choice of users to include in this copy of the /etc/passwd file might be root, bin, sys, and ftp.

    Copy the run-time libraries from /lib to the ftp/lib directory and create a special zero file in the ftp/dev directory with the following commands:

    cp /lib/rld lib
    cp /lib/libc.so.1 lib
    chmod -R 555 lib dev
    /etc/mknod dev/zero c 37 0
    chmod 444 dev/zero


Setting Up an InSight File Server

The files and directories that make up the InSight system of on-line 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 InSight documents as long as all systems are at substantially the same software revision level. If the InSight software revision level is the same across several systems, you can designate one system to serve the others with the InSight files, thus freeing up disk space on the client systems.

You should be sure to choose a server system that is not called upon to carry a heavy workload, and you should also take your network performance into account before you begin. If your users use InSight a great deal and your network is already burdened, you may find that your users will not appreciate the decreased response time from both InSight and your network in general. Also, if a person is to use the InSight 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 InSight server. These will be detailed in following 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 NFS Administration 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 InSight distribution media.

A Conventional InSight Server/Client System

To install the IRIS InSight Viewer and Document Library on a remote server and retrieve the information from a local client system, follow these steps:

On the server system:

    Log in as root (The Superuser).

    Bring up inst(1M) and install the complete IRIS InSight product image (from your CD-ROM drive or distribution directory) with the commands:

    Inst> install insight insight_gloss *.books.* 
    Inst> go 

    The total size of the viewer and document library is a little less than 23 Megabytes.

    Export the /usr/share/Insight/library/SGI_bookshelves directory using the System Manager or the exportfs(1M) command:

    exportfs -i /usr/share/Insight/library/SGI_bookshelves 

    If the server does not have a graphical display, a warning is generated during the exit. This warning relates to updating the X server's font directory and can be ignored.

On the client system:

    Log in as root (The Superuser).

    Give the command:

    versions remove *.books.* 

    to remove the books on your bookshelves.

    Bring up inst(1M) on your client system and give the following commands to install the insight.sw.client subsystem (you may want to install the insight.man.man and the insight.man.relnotes subsystems as well).

    Inst> keep insight insight_gloss 
    Inst> install insight.sw.client 
    Inst> go 

    Mount the SGI_bookshelves directory from your server on your client system. In the example below, the name of the server machine is capra.

    mkdir /usr/share/Insight/library/SGI_bookshelves 
    mount capra:/usr/share/Insight/library/SGI_bookshelves /usr/share/Insight/library/SGI_bookshelves 

    Note that when you enter the mount 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.

Note: If you have remote-mounted your InSight books, the SGI desktophelp system will not operate correctly while the books are mounted. To view the desktophelp, unmount the books temporarily.

A CD-ROM InSight Server/Client System

With this method, you need not use up your disk space for the InSight files if you have a CD-ROM drive you can dedicate to InSight. You simply leave the CD with the InSight distribution in the drive and link the mounted distribution to the directory where InSight 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 IRIS InSight 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/Insight/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 IRIS InSight Viewer and Document Library from the CD-ROM and access the information from a local or remote system, follow these steps:

On the server system with the CD-ROM drive:

    Log in as root (The Superuser).

    Insert the IRIS InSight CD into the CD-ROM drive. If the drive is not mounted, use the System Manager or the mount(1M) 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 IRIS InSight CD. To see the files use the command:

    cd /CDROM/insight 

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

    mkdir -p /usr/share/Insight/library 
    ln -s /CDROM/insight/SGI_bookshelves /usr/share/Insight/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 InSight 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.

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

    exportfs -i /CDROM 

On each client system, perform the following steps:

    Log in as root (The Superuser).

    Bring up inst(1M) and give the following commands to install the insight.sw.client subsystem (you may want to install the insight.man.man and the insight.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 insight.sw.client 
    Inst> go 

    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/insight/SGI_bookshelves /usr/share/Insight/library/SGI_bookshelves 

    Note that when you enter the mount 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.

Using Remote InSight

After the software has been installed, you should force your shell to remake its list of available programs and commands with the command:

rehash 

You can now invoke the IRIS InSight Viewer. The command to invoke the viewer is iiv. The name iiv is an acronym for IRIS InSight Viewer. The Viewer process does not automatically put itself in the background because it sends some error messages to the console. You can place it in the background by typing the command with the backgrounding operator (&):

iiv & 


Modifying the Network Interface Configuration

You do not always need to modify (configure) a station's network interface; in most situations the default configuration suits the site's needs. Modifying the network interface configuration requires that you modify the /etc/config/netif.options file. You modify this file if:

There are two configurable variables in the netif.options file: interface name and interface address. The interface name variable designates the order (primary, secondary, third, or fourth) and type of interface involved. The interface address variable assigns a valid Internet address to each interface. There must be a valid Internet address for each interface in the /etc/hosts file. Table 17-1 summarizes the interface name and interface address variables.

Table 17-1 : Variables for the netif.options File

Variable Name Variable Examples
Interface Name ifxname=

where:

x = 1, 2, 3, or 4

name=ec0, et0, enp0, enp1, fxp1, ipg0, ipg1, etc.

if1name=enp0

if2name=ipg0

if3name=enp1

if4name=enp2

Interface Address ifxaddress=

where:

x = 1, 2, 3, or 4

address=$HOSTNAME, station name, or Internet address

if1address=$HOSTNAME

if2address=fddi-$HOSTNAME

if3address=gate-goofy

if4address=192.30.28.2



You can modify either or both variables. Instructions for modifying both variables are provided below.

Modifying the Interface Name

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 only assigned to the first two interfaces. Additionally, if you want to change the order (primary, secondary, etc.) 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.

    Using the netstat command, verify the network interface's name:

    /usr/etc/netstat -ina

    Using vi or any editor, open the netif.options file for editing:

    vi /etc/config/netif.options

    Locate and modify the appropriate interface name variable. For this example, search for the secondary interface name variable (if2name) and change it from the default configuration to a configuration that supports the first FDDI interface as secondary:

    Change from this:

    : if2name = 

    to this:

    if2name=ipg0

    Caution: Note that all default variables (primary and secondary) start with a leading colon (:). You must remove the leading colon(:) and enter the interface type to change the default interface name.

    Save and exit the file.

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=primary, b=secondary, and c=third), if you were to make the default secondary the primary (b=primary), the remaining interfaces would be configured a=secondary and c=third.

Modifying the Interface Address

To change the default interface address, you must 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 secondary, third, and fourth interface addresses as follows:

    Verify or assign a valid entry for each interface in the /etc/hosts file. Note down the name and address for each interface.

    Using vi or any editor, open the netif.options file for editing:

    vi /etc/config/netif.options

    Locate and modify the appropriate interface address variable. For this example, we want to modify the secondary, third, and fourth interface address variables. Find and modify each variable as follows:

    Change from this:

    : if2addr=gate-$HOSTNAME
    if3addr=gate2-$HOSTNAME
    if4addr=gate3-$HOSTNAME

    to this:

    if2addr=fddi-$HOSTNAME
    if3addr=gate-goofy
    if4addr=192.30.28.26

    Caution: Note that all default variables (primary and secondary) start with a leading colon (:). You must remove the leading colon(:) and enter the interface address to change the default interface address.

    Save and exit the file.

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


Changing Network Parameters

Network parameters are those settings that determine how an interface processes or supplies certain network information. Modifying network parameters requires that you create and modify the appropriate /etc/config/ifconfig-#.options file (where "#" can be 1, 2, 3, or 4, based on the interface name).

The default parameter settings are known to function well and suit most site needs. Changing the settings can cause a network to become dysfunctional. It is recommended that these parameters be changed only by experienced or trained Network Managers.

Modifying the ifconfig-#.options File

There are four nondefault network parameters that can be set in the ifconfig-#.options file:

These steps show how to set the nondefault network parameters:

    Using the netstat command, determine the order assigned to the network interface at configuration time:

    /usr/etc/netstat -i

    Using vi or any editor, open or create the file /etc/config/ifconfig-#.options, where the pound sign (#) represents the network interface's name. For example, to configure a primary interface, open or create the file /etc/config/ifconfig-1.options.

    To change the network mask value for a network interface, enter a line with the word netmask followed by a space and either the 32-bit hexadecimal value, Internet address dot-notation, or the pseudo-network name.

    netmask 0xffffff00

    See "Turning On Multicast Routing" for more details regarding netmasks.

    To change the broadcast address for a network interface, enter a line with the word broadcast followed by a space and the dotted decimal IP broadcast address.

    broadcast 189.92.6.0

    To enable or disable the Address Resolution Protocol (ARP), enter a line with arp (to enable) or -arp (to disable).

    arp

    The ARP tables are used by some of the network management tools (netstat, ifconfig, etc.) and provide the administrator with invaluable network information.

    To change the routing metric count for a network interface, enter a line with the word metric followed by a space and the count:

    metric 7

    The default metric count, also called hops, is 0. The routed daemon monitors the number of hops required to route data from one network to another. If you want to reduce network traffic on a particular route, increase the metric count on the appropriate router.

The interface configuration file for the secondary interface might look like the following:

cat /etc/config/ifconfig-2.options

netmask 255.255.255.0
broadcast 129.38.50.0
-arp
metric 4

The interface configuration file above indicates that the Class B network is subnetted using 8 bits of the host ID for the subnet. It uses 0 as the broadcast address instead of the default 1. ARP has been disabled and the metric (hop) count has been set to 4 to discourage router traffic.


Creating a Local Network Script

To start and terminate locally developed network daemons, or to publish ARP entries and set routes, create the separate shell script /etc/init.d/network.local. Make symbolic links in /etc/rc0.d and /etc/rc2.d to this file to have it called during station start-up and shutdown:

ln -s /etc/init.d/network.local /etc/rc0.d/K39network
ln -s /etc/init.d/network.local /etc/rc2.d/S31network

See /etc/init.d/network for the basic format of the script. Also refer to network(1M), rc2(1M), and rc0(1M) for more information.


Turning On Remote Access Logging

Several network daemons have an option that lets you log remote accesses to the station log file /var/adm/SYSLOG by using syslogd(1M). Sites connected to the Internet should use this feature. To enable logging for ftpd(1M), tftpd(1M), and rshd(1M), edit /etc/inetd.conf and add "-l " after the right-most instance of ftpd and tftpd. Add "-L" after the right-most instance of rshd. For additional ftp logging, add "-ll" to the ftpd entry. Signal inetd to reread its file after you have added your changes:

/etc/killall -HUP inetd 

Remote logins by means of rlogin(1), telnet(1), and the 4DDN sethost(1) programs can be logged by login(1). Edit /etc/default/login and add the keywords "SYSLOG=ALL" or "SYSLOG=FAIL" to it. For example, this command in the login file logs successful and failed local and remote login attempts to syslogd(1M):

syslog=all

See the login(1) reference page for details.


[Previous Section] [Back to Table of Contents] [Next Section]


Send feedback to Technical Publications.

Copyright 1997, Silicon Graphics, Inc. All Rights Reserved. Trademark Information