UNIX Hints & Hacks |
||||||||||||||||||||||
Chapter 2: Networking |
|
|||||||||||||||||||||
|
2.4 Remote Network Configurations
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.
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
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
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.
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:
in.named--If you kill this daemon you'd better pray that you have a secondary DNS defined in your computing environment. This is the primary Domain Name Server, so if a large number of systems are dependent on the this server, it would be very wise to kill this daemon only when diagnosing DNS issues.
in.ftpd--Killing this daemon denies all inbound FTP connections. If this daemon is started from the inetd daemon, the inetd daemon has to be killed first. If not, a new ftp daemon is started when the next request comes in over the network for FTP.
in.telnetd--As with in.ftpd, this daemon too can be started from within the inetd daemon when a Telnet request comes in from the network. If it is and it is killed, the current request is disconnected and a new connection can be established when a Telnet request is made.
portmap--Although one of the most dangerous to kill, if dead, RPC server connections do not know what network service port to send the RPC packets to. RPC serves such ports for rusersd, rwalld, lockd, mountd, nsfd and are not able to function.
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.
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.
Man pages:
ftpd, ifconfig, inetd, listen, mountd, named, nfsd, portmap, reboot, routed, sendmail
UNIX Hints & Hacks |
||||||||||||||||||||||
Chapter 2: Networking |
|
|||||||||||||||||||||
|
© Copyright Macmillan USA. All rights reserved.