![[Previous Section]](b_prev.gif){kind=small}
![[Back to Table of Contents]](b_toc.gif){kind=small}
![[Next Section]](b_next.gif){kind=small}
IRIX Advanced Site and Server Administration Guide |
This chapter contains procedures for:
Configuring an IRIS for network connectivity. See "Configuring
an IRIS for a Network".
Connecting to an Ethernet Network and checking your Ethernet connection.
See "Attaching
Your Station to an Ethernet Network".
Setting up routers. See "Setting
Up a Router".
Setting up an anonymous ftp account. See "Setting
Up Anonymous ftp".
Setting up a system as the InSight file server. See "Setting
Up an InSight File Server".
Modifying the network interface configuration. See "Modifying
the Network Interface Configuration".
Changing network parameters. See "Changing
Network Parameters".
Creating a custom network script. See "Creating
a Local Network Script".
Setting up remote logging. See "Turning On Remote Access Logging".
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.
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.
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.)
This section addresses some of the common ethernet related 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:
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.
Check the machine's transceiver.
Check the transceiver cable, and try swapping it out with one that is
working on another machine.
Check for a problem with a 10baseT hub.
If you try all the troubleshooting techniques and you still cannot access the network, contact your service provider; the network itself may be temporarily out of order.
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.
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:
Check other machines on the network for bad Ethernet controllers.
Check other machines on the network for bad transceivers.
Check to see if removing a certain machine from the network makes the problem change or disappear.
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 system is not running.
Physically go to the system or call the system's Primary User or Administrator
to check to see if the system is powered up and running.
The network is not running.
To check, try to access another system on the network:
The network administrator changed some information about the system or about the system's logical location on the network.
Check whether this is the case, and get the appropriate information
to fix the problem.
The system has too many users or systems using its resources. It cannot provide services to you at this time.
Contact the system's Primary User or Administrator to check on this.
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.
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.
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.
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.
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.
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.
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.
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
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:
Suppress or force publicizing of routing information
Enable tracing of all received packets
Filter packets destined for specific networks
See the routed(1M) online reference page for more details.
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.
Figure 17-1 shows an example network with three routers. Each bubble labeled Host represents a system on the network.
Figure 17-1 : A network with multicast routers.
If people on networks A, C, and D are listening for packets, as shown
in the figure, all four networks receive the multicast packets.
If people on networks A and C are listening for packets, networks A,
B, and C receive the multicast packets.
If three or more people on network A are listening for packets, networks A and B receive the multicast packets. The multicast routing protocol prevents packets from being sent to "leafs" of the network, such as networks C and D; however, it doesn't prevent packets from being sent to interior networks, such as network B.
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.
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.
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
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.
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.
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
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
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.
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.
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.
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 &
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:
The station has more than two interfaces.
You don't like or use the default naming conventions.
The default order is incorrect.
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.
| 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.
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.
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:
secondary address: fddi-$HOSTNAME
third interface address: gate-goofy
fourth interface address: 192.30.28.26
Follow these instructions to modify your network interface address according to the above example:
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.
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.
There are four nondefault network parameters that can be set in the ifconfig-#.options file:
Netmask
Broadcast Address
ARP
Route Metric
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.
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.
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.
|
|
Copyright © 1997, Silicon Graphics, Inc. All Rights Reserved. Trademark Information