Understanding Solaris Networking

The Solaris operating environment is built for networking. Although some operating systems function well as clients, and others are designed to be servers, Solaris has the flexibility to be a client or a server, and the power to be a client and a server at the same time. To get Solaris to work on a network, however, you need to properly configure the network support files. If you installed network support during initial installation of Solaris, these files will already be configured for you. If not, you will have to set them up manually.

Understanding networking isn't just about configuring local files, however. You also need to know how computers communicate over the network, and how to access remote machines. Included in this is the understanding of Remote Procedure Calls (RPCs) and the commands used for network access and troubleshooting.

This section covers the files you need to configure on your local computer in order to participate on a network, as well as some network procedures and commands used in networking.

Network Configuration Files

When configuring Solaris computers on a network, you have a choice between two modes: local files mode or network client mode.

In local files mode, all configuration information is stored in files on the computer. Network configuration servers, name servers, mail servers, Network File System (NFS) servers, and routers should always run in local files mode. Depending on the size of your network, all other machines, including workstations, can run in local files mode as well. If you have a large network, though, using local files can increase administrative overhead.

In network client mode, client computers retrieve network configuration information (such as an IP address, host name, and router configuration) from a network configuration server. There needs to be only one network configuration server per network. If your network is subnetted though, you will need to have one network configuration server per subnet. Although any computer (workstation, server, and so on) can be a network client, and running a network configuration server saves administrative overhead, it's recommended that you run servers in local files mode if at all possible.

Note 

Many network administrators will physically and logically break up their existing network into smaller networks called subnets. Subnetting has a few distinct advantages. The biggest is that network traffic is reduced between computers (think of having 20 computers trying to talk at once on the same line versus having 10 on their own private line and the other 10 on another private line). Also, as subnets are physically separated by routers (which don't pass broadcast traffic), network traffic is further reduced. Subnets can also provide greater network security for groups of computers. Each subnet on a network has its own unique network address that fits into the scheme of the overall network address.

Networks do not have to be entirely in local files mode or in network client mode. Mixed networks that include computers running in local files mode and network client mode are common. On such a network, client workstations will be running in network client mode, and servers (including file and print servers), routers, and printers will be running in local files mode. The workstations can run in network client mode because they don't always need to have the same IP address. Computers generally don't contact other client computers for files or other information. However, servers, routers, and printers need to remain in the same location (always have the same IP address) so that they can easily be located by clients. If clients can't find a server or a printer because its address has changed, you could experience network problems. Here are some of the parameters you will need to specify to get networking support to function on your Solaris computer:

  • IP address for every network interface

  • Subnet mask (if your network has multiple subnets or connects to the Internet)

  • Default router address, if applicable

  • Host names for every computer on the network

  • DNS, NIS, or NIS+ domain name, if you have a configured domain

How you specifically configure your computer depends on whether you're running in local files mode or network client mode.

Note 

When Solaris boots, the /etc/rc2.d/S30sysid.net run control script is responsible for configuring basic network parameters on all network interfaces.

Local Files Mode

The first file you need to configure when running in local files mode is /etc/nodename. This file needs to have your computer's host name (also called a node name) in it. Your computer's name should be the only entry in this file. When typing in your computer's name, remember that Solaris is case sensitive.

Next, you will need to create a host name interface file. The name of this file will be /etc/ hostname.interface. In the filename, the interface variable is replaced by the interface name of your primary network connection. For example, if your primary network interface is le0, the filename would be /etc/hostname.le0. If you have multiple network connections, you will have multiple /etc/hostname.interface files, one for each network connection. The only entry inside the file will be your host name, just as in /etc/nodename. You can also substitute the interface IP address instead of a host name in this file.

After creating or configuring /etc/hostname.interface, you will need to set up the /etc/inet/hosts file. This file is also known as the hosts database. This file needs to contain the IP address and corresponding host name for every computer on your network. When you attempt to access another computer on your network by host name, your computer will check the hosts database for the computer's name and then attempt to contact the computer by its IP address.

Note 

The /etc/hosts file is a symbolic link to the /etc/inet/hosts file.

For large networks, using hosts files can be impractical and cumbersome. Using a Domain Name Server (DNS), Network Information Server (NIS), or NIS+ server is recommended for large networks. Naming services are covered in detail in Chapter 15, "Naming Services."

Inside the hosts file, one line represents one entry. Information is always in the following order: IP address, host name, nicknames (if any), and an optional comment. Here's a sample hosts file:

 # # Internet host table # 127.0.0.1     localhost     loghost     Q-Sol     #admin computer 10.0.0.1      Q-Sol 10.0.0.2      rob           punnyboy 10.0.0.3      mike          macaholic 10.0.0.4      scott         #user on probationary period 

The IP address of each machine is on the left, followed by one or more names that identify the computer. A hosts file will always have the entry 127.0.0.1, which is known as the loopback address and always refers to the local machine. The computer with the address of 10.0.0.2 can be referenced by one of two names, rob or punnyboy. Any information preceded by a pound sign (#) is a comment, meaning that the computer ignores any information after the pound sign. If your computer has multiple network interfaces, each interface requires an entry in the hosts database.

The /etc/defaultdomain file needs to contain one entry, and that is the fully qualified domain name of the domain that your computer belongs to. Obviously, if you don't have a domain, you don't need to configure this file. For example, if your domain name is www.flyingsushi.com, you would type www.flyingsushi.com into the /etc/defaultdomain file.

Note 

If the domain that you are creating is not going to participate in the Internet, you can create any naming convention you want. Examples are network.solaris, local.net.solaris, or whatever you choose. However, if the computers you are setting up will participate in the Internet directly, the naming structure of your domain must conform to Internet standards, having a primary domain name such as .com, .edu, .net, or other accepted standard names.

If your network has routers, you will need to create an entry for each one in the /etc/ defaultrouter file. Although you can use the name of the router if you wish, it's recommended that you use the router's IP address.

One more file you might need to configure is the /etc/inet/netmasks file. You'll need this file only if you've configured subnetting on your network. Entries in this file consist of a list of networks (network IDs) and subnet masks for the networks. If your network is running NIS or NIS+, you will not need to configure the /etc/inet/netmasks file.

Finally, the name service switch file, /etc/nsswitch.conf, needs to be configured properly. This file tells your computer where to look to request naming service information. In other words, if you want your computer to use the hosts file for name resolution, this file needs to reflect that choice. The nsswitch.conf file is discussed in more detail in Chapter 15.

Network Client Mode

To set up your network to run in network client mode, you need to configure a network configuration server in addition to the network clients. You will need superuser permissions or an equivalent role to set up the network configuration server.

Instead of each client having its own local configuration files, you will be configuring a server to provide the same information. The server will use the bootstrap protocol (BOOTP) to relay information to clients. As you might imagine, this can save you a lot of administrative overhead. From the server, follow these steps:

  1. Create the /tftpboot directory. This will enable the in.tftpd daemon and configure the server as a Trivial File Transfer Protocol (TFTP), bootparams, and RARP server. TFTP and RARP are used to boot client computers.

     # mkdir /tftpboot 

  2. Create a symbolic link to the /tftpboot directory.

     # ln -s /tftpboot/. /tftpboot/tftpboot 

  3. In the inetd.conf file, enable the tftp line. The line should read as follows:

     tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot 

  4. Add the IP addresses and host names for each client on the network to the /etc/inet/ hosts file.

  5. Add an entry for every network client into the ethers database (/etc/ethers). The ethers database contains the client's Ethernet address (with separating colons), host name, and optional comments. Here is an example:

     0:3:ba:15:d:18    Q-Sol    :this computer 

  6. Create an entry for all client computers that will be running in network client mode in the bootparams database (/etc/bootparams). The bootparams file lists a client name, followed by a keyword value pair. Here is an example:

     client1    root=server1:/export/client/root 

  7. Run the following command to hang up (reset) the inetd daemon.

     # pkill -HUP inetd 

This server is now configured to provide network information to client computers. Now instead of configuring clients to have their own local network files, you need to configure clients to look to the network configuration server for information. Here's how to configure network clients to use a network configuration server:

  1. Delete the /etc/nodename file, if it exists. This will force the client computer to use the hostconfig program to obtain its host name, domain name, and router information from the network configuration server.

  2. Create the /etc/hostname.interface file, if it doesn't exist. Ensure that this file is empty. The client will then contact the network configuration server for IP configuration information.

  3. Make sure that the local hosts database contains only an entry for the loopback address.

  4. Delete the /etc/defaultdomain file if it exists.

  5. Configure the /etc/nsswitch.conf file to reflect your network's name service configuration.

If you have local copies of these files, along with configured files on a network configuration server, the local copies will override information provided from the server, if there is a conflict.

start sidebar
Real World Scenario: Bigger Network, Less Administration

You have been the network administrator for your company for two years. When you started, the company had fifteen Solaris workstations and two Solaris servers. Now, there are nearly one hundred client machines and five servers.

You have always used local files mode for network configuration. It was easy to set up, and you didn't need to dedicate a server to be a network configuration server. Now, however, you are running into some network problems: improper name resolution, duplicate IP addresses, and intermittent connectivity problems. You also need to attach your network to the Internet so that users can have Internet access. How do you solve your problems?

The first thing you want to do is to set up a network configuration server and have all clients use the server to obtain network configuration information. This will result in a uniform configuration for all clients. The good news is, you don't need a dedicated server for this function; you can use one of your three existing servers. Also, you can easily specify DNS servers for the clients to use after you are attached to the Internet. Using a network configuration server and network client mode for your client computers will greatly ease your administrative burden while streamlining your configurations.

end sidebar

Remote Procedure Calls

A Remote Procedure Call (RPC) is a protocol used to start processes on remote computers. Think of it as the language that client computers use to start a process on a server. Virtually every UNIX service, including NIS, NIS+, and NFS use RPCs to function properly. If a host is to use RPCs, the RPC server service (rpcbind) must be started. Services that use RPCs are located in /etc/inetd.conf. A list of network services is also maintained in the /etc/rpc file.

The critical component of RPC is the rpcbind service. It's responsible for mapping incoming RPC requests to TCP or UDP port numbers on the local machine, ultimately resulting in correct RPC operation. Also, rpcbind registers all RPC daemons as they start up. This service must be started before your computer can use RPCs.

The rpcbind service allows a network-aware application to use whichever port number it chooses, as long as that port number is not already in use. When a client application attempts to connect to the server, the rpcbind service intercepts the bind request and tells the client which port the application is using. After the client has the server's IP address and the port number of the application, the client-server application can communicate. Without rpcbind, all applications would have to use a predefined port number, which makes for difficult possible port number conflicts (if two applications are programmed to use the same port).

Accessing Remote Systems

In most client-server networks, if you want to access a hard disk on a server from a client, you must mount the remote file system on the client. This book already covered mounting hard disks in Chapter 7, "File System Management." Printing on a network simply means being a client on the network and having appropriate access to the print server. In other cases, however, you might need to access a remote machine but you might not need to mount hard disks or print. Some examples are remotely logging in to a machine or copying files from a remote computer. This section describes methods for accessing remote systems through TCP/IP commands.

rlogin

The rlogin command enables you to log in to a remote system. After you are logged in, you can navigate the computer's file system, based on your user's assigned permissions. You can also copy files and execute remote commands when logged in with rlogin. To remotely log in to the server1 computer, you would type rlogin server1.

Users attempting to use rlogin must be validated. Validation can be performed by the remote computer (the one you are logging into) or by the network environment. If the remote computer is to validate you, one of three conditions must exist. First, the user account you are using must be located on the remote machine, and you must provide a correct password when prompted. Second, the remote machine must have an /etc/hosts.equiv file set up. Third, the remote machine must have an .rhosts file configured. If you're being validated by the network, you won't be prompted for a password when trying to access the remote machine, because the network already knows who you are (based on your login to your local machine).

Warning 

Using the /etc/hosts.equiv and/or .rhosts files can pose a significant security risk. Use them with caution, and never give root access using these files.

Here are the details on /etc/hosts.equiv and .rhosts:

/etc/hosts.equiv This file contains a list of computers that are trusted for remote login. Computer names are listed, one per line. Any user attempting to remotely log in from a computer listed in /etc/hosts.equiv is considered trusted. You can, however, specify a username after the computer's host name. In that case, only that user from the specified computer will be allowed to remotely log in. This is a more secure method when you know who the remote users will be.

Maintaining an /etc/hosts.equiv file can pose a security problem. If you are using one, make sure that only trusted hosts are listed in the file. Misconfiguration can cause serious security problems. For example, a single entry of a plus sign (+) in the /etc/hosts.equiv file means that the computer trusts all hosts on the network.

.rhosts The .rhosts file is similar to /etc/hosts.equiv but is meant for users instead of computer names. This file must be located in the user's home directory and contains a computer-user pairing list. The specified user must be using the specified computer to log in remotely.

The biggest security problem with .rhosts is that users can configure their own .rhosts file, instead of the administrator being in control (as is the case with /etc/hosts.equiv).

Both /etc/hosts.equiv and .rhosts share the same syntax. The first entry is the host name, and the second entry is the username (if applicable). Acceptable wildcards are the plus sign (+) to allow access to all, and the minus sign (-) to deny access to all. Table 10.2 discusses some sample /etc/hosts.equiv entries. Many of the so-called r utilities (such as rlogin, rcp, rsh, and rexec) use the /etc/hosts.equiv and/or .rhosts files for authentication.

Table 10.2: /etc/hosts.equiv and .rhosts Syntax

Entry

Effect

+

Allows all users from all remote computers to access this computer as the local user

+ username

Allows the named user to access this computer from any remote host

hostname +

Allows any user from the specified host to access this computer

- username

Denies access to the named user from any host

hostname -

Denies access to any user from the named host

-@netgroup

Explicitly denies access from all hosts in the named netgroup

+ -@netgroup

Denies access by all users in the named netgroup from all hosts

To use rlogin, the in.rlogind daemon must be started on the server. By default, it is launched by the inetd daemon, which starts automatically at boot. The rlogin command enables you to attempt both direct and indirect remote logins. In a direct login, you attempt to log in by using your current username. An indirect login means that you supply a username during the remote login attempt.

Tip 

By default, rlogin attempts to log you in directly. To log in indirectly, use the rlogin -l command.

After you log in to the remote system, rlogin attempts to find your home directory. If it finds your home directory, it parses your .cshrc and .login files, and configures your remote session appropriately. Your prompt would be the same as if you were logged in locally, as will your current working directory. If your home directory cannot be located, you are temporarily assigned the remote system's root directory (/) as your working directory.

To log out of a remote system that you are logged into, use the exit command, ~, or Control+D.

telnet

The telnet (terminal emulation) utility is an alternative to logging in remotely with rlogin. The biggest difference between the two is that telnet always asks you to provide a username for login, whereas rlogin does not. The telnet command also works with non-UNIX computers, making it the most popular choice for remote logins. Perhaps the only negative to using telnet is that it doesn't natively encrypt passwords or data. This could cause security problems. When you are successfully logged in by using telnet, you will receive a telnet> prompt. For help, type the question mark (?).

The in.telnetd daemon manages telnet servers. This daemon is started automatically by inetd. To exit a telnet session, type close or quit.

ftp

FTP stands for File Transfer Protocol. It's also a utility you can use to transfer files from one computer to another. By using the ftp command, you are logging into a remote computer but you don't have the full functionality of a user shell as you do with rlogin. Instead, ftp is streamlined for file downloads. In addition, the computer that you ftp to does not have to be running UNIX, whereas the rlogin host does need to be UNIX-based. The ftp command is controlled by the in.ftpd daemon, which is started automatically by inetd.

You can configure user authentication for FTP by including your password entry in the remote system's /etc/passwd file or by using a network authentication service. However, most ftp connections are made anonymously. You might have used FTP and not known it. Chances are if you have downloaded anything from the Internet, you've used this protocol. It's designed for optimizing downloads, whereas the Internet protocol HTTP is not.

To ftp to a remote system, type ftp host_name, where host_name is the system you want to log into. When the system asks for a username, type anonymous (or use your username if the FTP server is secure). For a password, enter your password. If you ftp anonymously, most sites prefer that you use your e-mail address for your password, but there's no specific standard for providing anonymous ftp passwords. When you are successfully logged in by using ftp, you will receive an ftp> prompt.

Many standard file system navigation commands, such as ls, pwd, and cd, work just as you would expect them to. In addition, ftp provides the get and mget commands to download files, and the put and mput commands for uploading files to the remote machine. The close, bye, and quit commands can be used to end an ftp session. And as always, if you're stuck and don't know what to type, type help.

TCP/IP Commands

The TCP/IP protocol suite is considered public domain. No one company owns it, and no one organization has absolute authority over new TCP/IP developments-although, technically, the Internet Engineering Task Force (ITEF) is responsible for implementing changes. Therefore, literally anyone can suggest an improvement or addition to TCP/IP and have it considered. Each suggestion for TCP/IP improvements and TCP/IP standards is published as a paper called a Request for Comments (RFC). Each RFC has a number to identify it. You might hear someone comment, "Yeah, it meets RFC 2065 standards."

Note 

RFC 2065 is a DNS security standard (you don't need to memorize this-it's just for illustrative purposes). If you hear people quoting RFC numbers, odds are they have way too much time on their hands. Many Internet sites list RFCs. One such site is http://www.ietf.org/rfc.html.

Because of the open access to TCP/IP, a large number of improvements and utilities have been implemented over the years. This section describes some of the more common and useful utilities.

r Utilities

A whole series of utilities begin with the letter r. The r always stands for remote. Examples are rlogin (discussed previously), rcp, rsh, rwho, rusers, and rup.

The rcp utility is for copying files to or from a remote computer. It's like ftp, but with fewer options. After logging in to a remote machine with rlogin, you could use rcp to copy files.

If you wanted to start a shell on a remote computer (to remotely execute a program, for instance), you could use the rsh (remote shell) command. To use the rsh command, you must be authenticated by the remote computer.

To display the names of users on computers attached to the network, use the rwho command. You can also use rwho to see when the users logged in and the amount of time that their computer has been idle. In order for rwho to work, the rwhod daemon must be started. Although rwhod can provide helpful information about who is on the network, rwhod broadcasts its information, causing excessive network traffic. The rusers command provides the same information as rwho, but a computer name must be specified. The rusers command has more options than rwho.

The rup (remote up) command is used to see whether computers are online, and if so, gives uptime status on the machine.

finger

The finger utility is used to display login names of users, along with their full names, home directory location, login shell, device numbers, the number of times they have logged in, and other information. If you want to find out something about someone, finger is the command to use. The finger command can be used both locally and remotely.

In order for finger to run, the fingerd daemon must be running. Because searching for and finding detailed information about users can pose a security risk, a lot of network administrators disable the fingerd daemon.

ping

The ping (packet internet groper) utility is one of the most useful utilities for determining whether a remote computer is accessible. To ping a computer, you can type ping IPAddress or ping hostname. If your network is not using name resolution, you will not get a response from pinging a host name. The ping command sends ICMP packets to the remote computer.

Note 

The ping command uses the ICMP protocol. Some website administrators have configured their sites to not respond to ICMP packets, as hackers have been known to try to use this protocol. Besides, responding to hollow ICMP requests takes server time, and slows down legitimate website requests. Also, if you are behind a security firewall, the ping command may not work.

When you ping a computer, you will get one of three responses:

  • hostname is alive tells you that the remote computer is operational.

  • ping: no answer from hostname tells you that the computer is not functioning or is unable to respond to ICMP requests.

  • ping: unknown host hostname means that you typed in an invalid name or address and were unable to contact the machine. This message could result from an incorrect DNS setting or bad information in a hosts file.

You can also use ping to run a quick test to see whether your system's IP stack is working properly. To do this, ping your loopback IP address: ping 127.0.0.1. You should receive a response. If you get an error message, TCP/IP is not configured correctly on your computer.

Tip 

Pinging the loopback address (127.0.0.1) tests the validity of the TCP/IP installation on your computer, but does not test the physical hardware (network card).

spray

The spray command is used to spray a one-way stream of packets to a remote host. This command reports the number of packets that were received and the transfer rate between the two hosts. Although spray can give you an idea as to how well your network is performing, it should not be used as a network benchmark. The spray command is unreliable because it uses the UDP protocol.

traceroute

The traceroute utility is another helpful network troubleshooting tool. It traces the route of a packet from your computer to the destination host, listing all routers in the path, as well as how long the trip from one router to the next (called a hop) took. On small networks, traceroute has little value. However, on large networks, and even the Internet, traceroute can tell you how far a packet gets before running into network problems.

ifconfig

To configure network interface parameters, use the ifconfig command. It's used to assign addresses to network interfaces, configure other network interface parameters, and display network interface configuration information. The ifconfig -a command will print out the addressing information (including the Ethernet address) for each network interface.

netstat

The netstat command is a versatile command that shows network status and protocol statistics. Common uses for netstat are to show routing tables, protocol statistics, and the state of interfaces being used for IP traffic.

snoop

The snoop command is used to capture and inspect network packets. Because of the obvious security concerns, only the superuser can use snoop. If you were to capture unencrypted packets on a network, you could literally see all data (including unencrypted passwords) being transmitted on your network. Although this sounds powerful and it is, busy networks can generate tens of thousands of packets per minute.

Logging Incoming IP Connections

If your computer is part of a public domain, it is smart to keep a log of all incoming IP connections made to your computer. If you use logging, you will know the IP address of every computer that connects to your machine, which could be useful if trying to track down someone who tried to hack your computer. Without logging, you will have no idea who has accessed your machine through IP.

To turn on logging, edit the /etc/default/inetd file and add this line:

 ENABLE_CONNECTION_LOGGING=YES 

After adding this line, stop and restart the inetd daemon, and your computer will log all incoming IP connections.

Finding Network Configuration Information in OpenBoot

Although commands such as netstat and ifconfig can be used to gather network configuration information, some information is stored in the OpenBoot PROM (OBP). You need to know the commands to find network information in OBP.

When a Solaris computer boots, it displays a boot banner, similar to the following:

 Sun Blade 100 (UltraSPARC-IIe), Keyboard Present Copyright 1998-2002 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.5, 256 MB memory installed, Serial #8675309. Ethernet address 0:3:ba:15:d:18, Host ID: 84107d19. 

You will notice that the banner displays the host's Ethernet address.

Note 

Ethernet addresses are also called MAC addresses or hardware addresses.

If the banner appeared and disappeared too quickly for you to read, you can type the banner command at the ok prompt to display it again. If you just want the Ethernet address without the bother of the rest of the banner, type .enet-addr at the ok prompt.

OpenBoot also comes with a few network diagnostics. One is the test net command, which tests the network adapter. Another is watch-net, which scans the network for broadcast packets.




Solaris 9. Sun Certified System Administrator Study Guide
Solaris 9 Sun Certified System Administrator Study Guide
ISBN: 0782141811
EAN: 2147483647
Year: 2003
Pages: 194

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net