UNIX Hints & Hacks

ContentsIndex

Chapter 2: Networking

 

Previous ChapterNext Chapter

Sections in this Chapter:

2.1 OSI Networking Model

 

2.4 Remote Network Configurations

 

2.7 Unmounting and Busy Devices

2.2 Finding the Failure

 

2.5 Shutdown, Halt, or Reboot over the Network

 

2.8 Static Routing or routed

2.3 Hiding Files with NFS

 

2.6 Talking NFS3 to NFS2

 

2.9 Get the Ethernet Address with arp

 

2.4 Remote Network Configurations

2.4.1 Description

2.4.1 Description

Avoid configuring the network from a remote machine at all cost. Believe it or not, there are times when you need to.

Think about it. If you are in a remote system and you diagnose that something is not quite configured correctly with the network, you change the network configuration and, the next thing you know, your remote connections are closed.

You just took the system off the network. Don't attempt to make changes to the network interface or any configurations to the network if at all possible while logged in over the network. But if you must, here are some things that might help you.

Example One: Using the ifconfig Command

Flavors: Most all AT&T and BSD

Syntax:

ifconfig interface [up|down] Ipaddress

The ifconfig command is the worst command to use while remotely logged in to a computer. This command controls how the network interface is configured. The following are ways that this command can bring a system off the network.

# ifconfig le0
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
      inet 139.102.9.16 netmask ffffff00 broadcast 139.102.9.255
# ifconfig le0 down # ifconfig le0 139.102.9.21

When the down argument is passed to the ifconfig command, the interface is shut down and no traffic is transmitted to or received from the network interface card. If a new IP address is set without bringing down the network interface first, the system drops off the network.

If the IP address needs to be changed on a system and you are coming in from over the network, there is one possible way to change it. Shut down the interface, change the IP address, and bring the interface up. Here is the catch. Do it all in one command.

# (ifconfig le0 down; ifconfig le0 139.102.9.21;ifconfig le0 up) &

When you execute this command, you lose connection to the system. This is all right, because all you have to do is telnet back in to the system under the new IP address.

Note - If an IP address can wait to be changed, make the change to the /etc/hosts table and reboot the system at the user's convenience.


# vi /etc/hosts
#139.102.9.16    xinu     xinu.ugu.com
139.102.9.21    xinu     xinu.ugu.com
# reboot

Example Two: Changing the Gateway

Syntax:

route -f

Another taboo is flushing the route tables, default router, or gateway information, if you are connecting to the system across a router or through a gateway. Flushing the tables only leaves you disconnected from the remote machine.

# route -f

Example Three: Changes to NIS/YP

When working on changes dealing with NIS/YP on a remote system, be very careful. Do not log in to the remote system using an account that is in NIS. If you do, exit and log in again as a local user such as guest; then switch to a single user account that is local to the remote system, if your system is enabled for a superuser account to login. Always use accounts that are local to the remote box.

If you are logged in to the remote system with an account that is in NIS, the second you manipulate or kill NIS with the ypbind daemons, you lose access to the remote system. Also, you should make sure that any users log off who are logged in with NIS accounts. This enables you to make your changes, without worrying about any processes possibly going into a zombie state.

By always using local accounts on the remote machines, you are not affected by the changes you are making to NIS.

Example Four: Kill Network Daemons

When logged in remotely, be careful of which daemons you kill off from the process table. Some daemons that are running control the connectivity of the machine to the network. If these daemons are killed, you might not be able to establish any new remote connections or take the system off the network all together. The following list includes daemons that you need to be careful with when deciding to kill them or not. Your flavor might not include all these daemons, so don't be scared if one of these daemons is not running on your system:

Reason

So why even mess with the network configurations while logged in over the network? There are times when network changes take place over the net. It does depend on the change though. Some are nonvolatile changes, but there are many that you need to be aware of that can take the system down or off the network.

Real World Experience

There are times when a change might need to take place on many systems on the network. Test the change out on one remotely to see whether the process can be scripted and propagated out to all the rest of the systems. When network configuration files are changed, the result is to restart the related network daemon. In development environments I've worked in, IP addresses were often changed on-the-fly and, in many cases, the users would enable us to reboot their systems. You might not get this luxury.

Other Resources

Man pages:

ftpd, ifconfig, inetd, listen, mountd, named, nfsd, portmap, reboot, routed, sendmail

UNIX Hints & Hacks

ContentsIndex

Chapter 2: Networking

 

Previous ChapterNext Chapter

Sections in this Chapter:

2.1 OSI Networking Model

 

2.4 Remote Network Configurations

 

2.7 Unmounting and Busy Devices

2.2 Finding the Failure

 

2.5 Shutdown, Halt, or Reboot over the Network

 

2.8 Static Routing or routed

2.3 Hiding Files with NFS

 

2.6 Talking NFS3 to NFS2

 

2.9 Get the Ethernet Address with arp

 

© Copyright Macmillan USA. All rights reserved.