#
#
# Hayes modem connected to ttyS0: don't do fax, less logging
#
port ttyS0
debug 3
data-only y
#
# direct connection of a VT100 terminal which doesn't like DTR drops
#
port ttyS1
direct y
speed 19200
toggle-dtr n
#
The configuration file supports global and port-specific options. In our example we used a global option to set the speed to 38,400 bps. This value is inherited by the ttyS0 port. Ports we apply mgetty to use this speed setting unless it is overwritten by a port-specific speed setting, as we have done in the ttyS1 configuration.
The debug keyword controls the verbosity of mgetty logging. The data-only keyword in the ttyS0 configuration causes mgetty to ignore any modem fax features, to operate just as a data modem. The direct keyword in the ttyS1 configuration instructs mgetty not to attempt any modem initialization on the port. Finally, the toggle-dtr keyword instructs mgetty not to attempt to hang up the line by dropping the DTR (Data Terminal Ready) pin on the serial interface; some terminals don't like this to happen.
You can also choose to leave the mgetty.config file empty and use command-line arguments to specify most of the same parameters. The documentation accompanying the application includes a complete description of the mgetty configuration file parameters and command-line arguments. See the following example.
We need to add two entries to the /etc/inittab file to activate this configuration. The inittab file is the configuration file of the Unix System V init command. The init command is responsible for system initialization; it provides a means of automatically executing programs at boot time and re-executing them when they terminate. This is ideal for the goals of running a getty program.
T0:23:respawn:/sbin/mgetty ttyS0
T1:23:respawn:/sbin/mgetty ttyS1
Each line of the /etc/inittab file contains four fields, separated by colons. The first field is an identifier that uniquely labels an entry in the file; traditionally it is two characters, but modern versions allow four. The second field is the list of run levels at which this entry should be active. A run level is a means of providing alternate machine configurations and is implemented using trees of startup scripts stored in directories called /etc/rc1.d, /etc/rc2.d, etc. This feature is typically implemented very simply, and you should model your entries on others in the file or refer to your system documentation for more information. The third field describes when to take action. For the purposes of running a getty program, this field should be set to respawn, meaning that the command should be re-executed automatically when it dies. There are several other options, as well, but they are not useful for our purposes here. The fourth field is the actual command to execute; this is where we specify the mgetty command and any arguments we wish to pass it. In our simple example we're starting and restarting mgetty whenever the system is operating at either of run levels two or three, and are supplying as an argument just the name of the device we wish it to use. The mgetty command assumes the /dev/, so we don't need to supply it.
This chapter was a quick introduction to mgetty and how to offer login prompts to serial devices. You can find more extensive information in the Serial-HOWTO.
After you've edited the configuration files, you need to reload init to make the changes take effect. Simply send a hangup signal to the init process; it always has a process ID of one, so you can use the following command safely:
# kill -HUP 1
Chapter 5. Configuring TCP/IP Networking
In this chapter, we walk you through all the necessary steps to set up TCP/IP networking on your machine. Starting with the assignment of IP addresses, we slowly work our way through the configuration of TCP/IP network interfaces and introduce a few tools that come in handy when hunting down network installation problems.
Most of the tasks covered in this chapter will generally have to be done only once. Afterward, you have to touch most configuration files only when adding a new system to your network or when you reconfigure your system entirely. Some of the commands used to configure TCP/IP, however, have to be executed each time the system is booted. This is usually done by invoking them from the system /etc/rc* scripts.
Commonly, the network-specific part of this procedure is contained in a script. The name of this script varies in different Linux distributions. In many older Linux distributions, it is known as rc.net or rc.inet. Sometimes you will also see two scripts named rc.inet1 and rc.inet2; the former initializes the kernel part of networking and the latter starts basic networking services and applications. In modern distributions, the rc files are structured in a more sophisticated arrangement; here you may find scripts in the /etc/init.d/ (or /etc/rc.d/init.d/) directory that create the network devices and other rc files that run the network application programs. This book's examples are based on the latter arrangement.
This chapter discusses parts of the script that configure your network interfaces, while applications will be covered in later chapters. After finishing this chapter, you should have established a sequence of commands that properly configure TCP/IP networking on your computer. You should then replace any sample commands in your configuration scripts with your commands, make sure the script is executed from the basic rc script at startup time, and reboot your machine. The networking rc scripts that come along with your favorite Linux distribution should provide a solid example from which to work.
Mounting the /proc Filesystem
Some of the configuration tools of the Linux NET-2 and NET-3 release rely on the /proc filesystem for communicating with the kernel. This interface permits access to kernel runtime information through a filesystem-like mechanism. When mounted, you can list its files like any other filesystem, or display their contents. Typical items include the loadavg file, which contains the system load average, and meminfo, which shows current core memory and swap usage.
To this, the networking code adds the net directory. It contains a number of files that show things like the kernel ARP tables, the state of TCP connections, and the routing tables. Most network administration tools get their information from these files.
The proc filesystem (or procfs, as it is also known) is usually mounted on /proc at system boot time. The best method is to add the following line to /etc/fstab:
# procfs mount point:
none /proc proc defaults
Then execute mount /proc from your /etc/rc script.
The procfs is now configured into most kernels by default. If the procfs is not in your kernel, you will get a message such as: mount: fs type procfs not supported by kernel. You will then have to recompile the kernel and answer "yes" when asked for procfs support.