Kernel Configuration and The Internet Daemon

Kernel Configuration and The Internet Daemon
GregDeamons Profile Pic
GregDeamons,New Zealand,Professional
Published Date:03-08-2017
Your Website URL(Optional)
Comment
Chapter 5 CHAPTER 5 In this chapter: • Kernel Configuration • Startup Files Basic Configuration • The Internet Daemon • The Extended Internet Daemon Every Unix computer that runs TCP/IP has a technique for incorporating the basic transport and IP datagram services into its operating system. This chapter discusses two techniques for incorporating the basic TCP/IP configuration into a Unix system: recompiling the kernel, and loading dynamically linked kernel modules. We’ll study these techniques and the role they play in linking TCP/IP and Unix. With this infor- mation, you should be able to understand how the vendor builds the basic configura- tion and how to modify it to create your own custom configuration. The transport and datagram services installed in the operating system are used by the application services described in Chapter 3. There are two different techniques for starting application services: they are either run at boot time or launched on an on- demand basis. This chapter covers both of these techniques and shows you how to configure and control this startup process. But first let’s look at how TCP/IP is incor- porated into the Unix operating system. Kernel Configuration Kernel configuration is not really a network administration task—rather, it is a basic part of Unix system administration, whether or not the computer is connected to a network. But TCP/IP networking, like other system functions, is integrated into the kernel. There are two very different approaches to kernel configuration. Some systems are designed to eliminate the need for you to recompile the kernel, while others encour- age you to compile your own custom kernel. Linux is an example of the latter philos- ophy: its documentation encourages you to create your own configuration. Solaris is an example of the former. The Solaris system comes with a generic kernel that supports all basic system services. When a Solaris system boots, it detects all system hardware and uses dynamically 108 This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.loadable modules to support that hardware. Solaris can rely on this technique because Sun is primarily a hardware vendor. Sun designs its hardware to work with the Solaris kernel, and has a well-defined device driver interface so that third-party hardware ven- dors can design hardware that clearly identifies itself to the kernel. Using Dynamically Loadable Modules Most versions of Unix support dynamically loadable modules, which are kernel modules that can be dynamically linked into the kernel at runtime. These modules provide the system with a great deal of flexibility because the kernel is able to load support for new hardware when the hardware is detected. Dynamically loadable modules are used to add new features to the system without requiring the system administrator to perform a manual reconfiguration. Solaris depends on dynamically loadable modules. Solaris does have a kernel config- uration file, defined in the /etc/system file, but this file is very small, has only limited applicability, and is not directly edited by the system administrator. When a new software package is added to the system, the script that installs that package makes any changes it requires to the /etc/system file. But even that is rare. Most drivers that are delivered with third-party hardware carry their own configuration files. On a Solaris system, optional device drivers are installed using the pkgadd command. The syntax of the command is: pkgadd -d device packagename device is the device name. packagename is the name of the driver software package provided by the vendor. The device driver installation creates the proper entry in the /dev directory as well as in the /kernel/drv directory. As an example, look at the Ethernet device driver for adapters that use the DEC 21140 chipset. The name of the driver is dnet. There is a device named /dev/dnet defined in the device directory. There is a dynamically load- able module named /kernel/drv/dnet in the kernel driver directory, and there is a con- figuration file for the driver named /kernel/drv/dnet.conf. dnet is a standard driver, but the installation of an optional driver will create similar files. After installing a new device driver, create an empty file named /reconfigure. Shut down the system and install the new hardware. Then restart the system. The /recon- figure file is a flag to the system to check for new hardware. When the Solaris system reboots, it will detect the new hardware and load the dynamic module that provides the device driver for that hardware. dnet is not an optional device. It is a standard part of Solaris and it is the Ethernet device we use in all of our Solaris examples. Kernel Configuration 109 This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.The Solaris ifconfig command, which is covered in extensive detail in Chapter 6, provides the modlist option to let you see the kernel modules that are associated with a TCP/IP network interface. For example: ifconfig dnet0 modlist 0 arp 1 ip 2 dnet The purpose of each kernel module in this list is clear. arp provides the ARP proto- col for the Ethernet interface. ip provides the TCP/IP protocols used for this net- work. Each of these modules has a configuration file in the /kernel/drv directory. There is an arp.conf file, an ip.conf file, and a dnet.conf file. However, these files pro- vide very limited capacity for controlling the function of the modules. On Solaris sys- tems, use the ndd command to control the module. To see what configuration options are available for a module, use the ndd command with a ? as an argument. For example, use the following command to see the vari- ables available for the arp module: ndd /dev/arp ? ? (read only) arp_cache_report (read only) arp_debug (read and write) arp_cleanup_interval (read and write) arp_publish_interval (read and write) arp_publish_count (read and write) The arp module offers six values: ? A read-only value that displays this list. arp_cache_report A read-only value that displays the permanent values in the ARP cache. The arp command gives a better display of the cache. See the description of the arp com- mand in Chapter 2. arp_debug A variable that enables ARP protocol debugging. By default, it is set to 0 and debugging is disabled. Setting it to 1 enables debugging. The ARP protocol is very old and very reliable. ARP debugging is never needed. arp_cleanup_interval A variable that defines how long temporary entries are kept in the cache. arp_publish_interval A variable that defines how long the system waits between broadcasts of an Ethernet address that it is configured to publish. 110 Chapter 5: Basic Configuration This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.arp_publish_count A variable that defines how many ARP broadcasts are sent in response to a query for an address that this system publishes. The default configuration values set for the arp module have worked well for every Solaris system I have ever worked with. I have never had a need to change any of these settings. The second module displayed by modlist provides a slightly more interesting example. Use the ndd /dev/ip ? command to list the configuration options for the ip module. There are almost 60 of them Of all of these, there is only one that I have ever needed to adjust: ip_forwarding. The ip_forwarding variable specifies whether the ip module should act as if the sys- tem is a router and forward packets to other hosts. By default, systems with one net- work interface are hosts that do not forward packets, and systems with more than one interface are routers that do forward packets. Setting ip_forwarding to 0 turns off packet forwarding, even if the system has more than one network interface. Setting ip_forwarding to 1 turns on packet forwarding, even if the system has only one net- work interface. On occasion you will have a multi-homed host, which is a host connected to more than one network. Despite multiple network connections, the system is a host, not a router. To prevent that system from acting as a router and potentially interfering with the real routing configuration, disable IP forwarding as follows: ndd /dev/ip ip_forwarding 1 ndd -set /dev/ip ip_forwarding 0 ndd /dev/ip ip_forwarding 0 The first ndd command in this example queries the ip module for the value set in ip_ forwarding. In this example it is set to 1, which enables forwarding. The second ndd command uses the -set option to write the value 0 into the ip_forwarding variable. The last command in the example redisplays the variable to show that it has indeed been changed. The pkgadd command, the ifconfig modlist option, and the ndd command are all specific to Solaris. Other systems use dynamically loadable modules but use a differ- ent set of commands to control them. Linux also uses loadable modules. Linux derives the same benefit from loadable modules as Solaris does, and like Solaris usually you have very little involvement with loadable modules. Generally the Linux system detects the hardware and deter- mines the correct modules needed during the initial installation without any input from the system administrator. But not always. Sometimes hardware is not detected Kernel Configuration 111 This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.during the installation, and other times new hardware is added to a running system. To handle these situations, you need to know the Linux commands used to work with loadable modules. Use the lsmod command to check which modules are installed in a Linux system. Here’s an example from a Red Hat system: lsmod Module Size Used by ide-cd 26848 0 (autoclean) cdrom 27232 0 (autoclean) ide-cd autofs 11264 1 (autoclean) smc-ultra 6048 1 (autoclean) 8390 6816 0 (autoclean) smc-ultra ipchains 38976 0 (unused) nls_iso8859-1 2880 1 (autoclean) nls_cp437 4384 1 (autoclean) vfat 9392 1 (autoclean) fat 32672 0 (autoclean) vfat Loadable modules perform a variety of tasks. Some modules are hardware device drivers, such as the smc-ultra module for the SMC Ultra Ethernet card. Other mod- ules provide support for the wide array of filesystems available in Linux, such as the ISO8859 filesystem used on CD-ROMs or the DOS FAT filesystem with long file- name support (vfat). Each entry in the listing produced by the lsmod command begins with the name of the module followed by the size of the module. As the size field indicates, modules are small. Often modules depend on other modules to get the task done. The interre- lationships of modules are called module dependencies, which are shown in the list- ing. In the sample, the smc-ultra driver depends on the 8390 module, as indicated by the 8390 entry ending with the string “smc-ultra”. The 8390 entry lists the mod- ules that depend on it under the heading Used by. The listing shows other dependen- cies, including that vfat depends on fat and cdrom depends on ide-cd. Most of the lines in the sample include the string “(autoclean)”. This indicates that the specified module can be removed from memory automatically if it is unused. autoclean is an option. You can select different options by manually loading mod- ules with the insmod command. Modules can be manually loaded using the insmod command. This command is very straightforward—it’s just the command and the module name. For example, to load the 3c509 device driver, enter insmod 3c509. This does not install the module with the autoclean option. If you want this driver removed from memory when it is not in use, add the -k option to the insmod command: insmod -k 3c509. A critical limitation with the insmod command is that it does not understand module dependencies. If you used it to load the smc-ultra module, it would not automati- cally load the required 8390 module. For this reason, modprobe is a better command 112 Chapter 5: Basic Configuration This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.for manually loading modules. As with the insmod command, the syntax is simple. To load the smc-ultra module, simply enter modprobe smc-ultra. modprobe reads the module dependencies file that is produced by the depmod command. Whenever the kernel or the module libraries are updated, run depmod to produce a new file containing the module dependencies. The command depmod -a searches all of the standard module libraries and creates the necessary file. After it is run, you can use modprobe to install any modules and have the other modules it depends on automatically installed. Use the rmmod command to remove unneeded modules. Again, the syntax is simple: rmmod appletalk removes the appletalk driver from your system. There is rarely any need to remove unneeded modules because, as noted in the discussion of autoclean, the system automatically removes unused modules. The smc-ultra module is an Ethernet device driver. It is in fact the device driver used for the network interface on our sample Linux system. Device drivers can be com- piled into the kernel, as described later, or they can be dynamically loaded from a module. Most Ethernet device drivers are handled as dynamically loadable modules. The Ethernet driver modules are found in the /lib/modules directory. On a Red Hat 7.2 system, Ethernet device drivers are in the /lib/modules/2.4.7-10/kernel/drivers/net directory, as the following listing shows: ls /lib/modules/2.4.7-10/kernel/drivers/net 3c501.o atp.o eexpress.o ni5010.o smc-ultra.o 3c503.o bcm epic100.o ni52.o starfire.o 3c505.o bonding.o eql.o ni65.o strip.o 3c507.o bsd_comp.o es3210.o pcmcia sundance.o 3c509.o cipe eth16i.o pcnet32.o sunhme.o 3c515.o cs89x0.o ethertap.o plip.o tlan.o 3c59x.o de4x5.o ewrk3.o ppp_async.o tokenring 8139too.o de600.o fc ppp_deflate.o tulip 82596.o de620.o hamachi.o ppp_generic.o tun.o 8390.o defxx.o hp100.o ppp_synctty.o via-rhine.o ac3200.o depca.o hp.o rcpci.o wan acenic.o dgrs.o hp-plus.o sb1000.o wavelan.o aironet4500_card.o dmfe.o irda shaper.o wd.o aironet4500_core.o dummy.o lance.o sis900.o winbond-840.o aironet4500_proc.o e1000.o lne390.o sk98lin yellowfin.o appletalk e100.o natsemi.o skfp arlan.o e2100.o ne2k-pci.o sk_g16.o arlan-proc.o eepro100.o ne3210.o slip.o at1700.o eepro.o ne.o smc-ultra32.o All loadable network device drivers are listed here. Some, such as plip.o, are not for Ethernet devices. Most are easily identifiable as Ethernet drivers, such as the 3COM drivers, the SMC drivers, the NE2000 drivers, and the Ethernet Express drivers. The Linux system detects the Ethernet hardware during the initial installation, and if Linux has the correct driver for that hardware, it installs the appropriate driver. If the Kernel Configuration 113 This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.Ethernet adapter is not detected during the operating system installation or if it is added after the system is installed, use the modprobe command to load the device driver manually. If the correct driver for the adapter is not included with your Linux system, you may need to compile the module yourself. For a device driver to operate correctly, it must be compiled with the correct librar- ies for your kernel. Sometimes this means downloading the driver source code and compiling it yourself on your system. Ethernet driver source code is available for many adapters from http://www.scyld.com, which has a great repository of Linux net- work driver software. The comments in the driver source code includes the correct compiler command to compile the module. After compiling, copy the object file to the correct /lib/modules directory. Then use modprobe to load and test the driver. Alternatively, most device drivers are now avail- able in RPM format, eliminating the need for compilation. Linux frequently uses dynamically loadable modules for device drivers. But most other components of TCP/IP are not loaded at runtime; they are compiled into the kernel. Next we look at how Unix kernels are recompiled. Recompiling the Kernel This text uses Linux and FreeBSD as examples of systems that encourage you to com- pile a custom kernel. This chapter’s examples of kernel configuration statements come from these two Unix systems. While kernel configuration involves all aspects of system configuration, we include only statements that directly affect TCP/IP configuration. Both of the Unix systems used in the examples come with a kernel configuration file preconfigured for TCP/IP. During the initial installation, you may need to select a preconfigured kernel that includes network support, but you probably won’t need to modify the kernel configuration for networking. The kernel configuration file is nor- mally changed only when you wish to: • Produce a smaller, more efficient kernel by removing unneeded items • Add a new device • Modify a system parameter While there is rarely any need to modify the kernel network statements, it is useful to understand what these statements do. Looking into the kernel configuration file shows how Unix is tied to the hardware and software of the network. The kernel configuration process of other BSD systems, such as SunOS 4.1.3, is similar to the FreeBSD example. 114 Chapter 5: Basic Configuration This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.The procedures and files used for kernel configuration vary dramati- cally depending on Unix implementation. These variations make it essential that you refer to your system documentation before trying to configure the kernel on your system. Only your system documenta- tion can provide you with the accurate, detailed instructions required to successfully complete this task. Linux Kernel Configuration The source code for the Linux kernel is normally delivered with a Linux distribu- tion. If your system does not have the source code or you want a newer version of the Linux kernel, it can be downloaded from http://www.kernel.org as a compressed tar file. If you already have a directory named /usr/src/linux, rename it before you unpack the tarball: cd /usr/src tar -zxvf linux-2.1.14.tar.gz The Linux kernel is a C program compiled and installed by make. The make command customizes the kernel configuration and generates the files (including the Makefile) needed to compile and link the kernel. There are three variations of the command: make config This form of the make command is entirely text-based. It takes you through a very long sequence of questions that ask about every aspect of the kernel config- uration. Because it asks every question in a sequential manner, this can be the most cumbersome way to reconfigure the kernel, particularly if you wish to change only a few items. make menuconfig This form of the make command uses curses to present a menu of configuration choices. It provides all of the capabilities of the make config command but is much easier to use because it allows you to jump to specific areas of interest. The make menuconfig command works from any terminal and on any system, even one that does not support X Windows. make xconfig This form of the make command uses X Windows to provide a “point and click” interface for kernel configuration. It has all the power of the other commands and is very easy to use. Choose the form of the command you like best. In this example we use make xconfig. On Linux systems, the kernel source is found in /usr/src/linux. To start the configura- tion process, change to the source directory and run make xconfig: cd /usr/src/linux make xconfig Kernel Configuration 115 This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.The make xconfig command displays the screen shown in Figure 5-1. Figure 5-1. Linux xconfig main menu The menu displays more than 30 buttons that represent different configuration cate- gories. Click on a button to view and set the configuration options in that category. Because our focus is on the kernel configuration options that affect TCP/IP, the two menu items we’re interested in are Networking options and Network device support. Figure 5-2 shows the window that appears if the Network device support button is selected. Figure 5-2. Linux kernel network device support 116 Chapter 5: Basic Configuration This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.This window lists the network device drivers that can be compiled into or loaded by the kernel and shows the three choices for most configuration options: y Selecting y compiles the option into the new kernel. m Selecting m causes the option to be loaded as a dynamically loadable module by the kernel. Not every option is available as a loadable module. When a configu- ration question must be answered yes or no, the module selection is not avail- able. Notice the FDDI driver support option. Choosing y for that option enables FDDI driver support and highlights a selection of possible FDDI interface adapt- ers, which are “grayed-out” in Figure 5-2. Frequently, interface support must be selected before an individual adapter can be selected. n Selecting n tells the kernel not to use the configuration option. Each configuration option also has a Help button. Clicking on the Help button pro- vides additional information about the option and advice about when the option should be set. Even if you think you know what the option is about, you should read the description displayed by the Help button before you change the default setting. Two items shown in Figure 5-2, Ethernet (10 or 100 Mbit) and Ethernet (1000 Mbit), open separate windows with extensive menu selections because Linux supports a very large number of Ethernet adapters. The Ethernet adapters available through those windows are selected using the same y, m, and n settings described above. The Network device support window and the Ethernet adapter windows show that it is possible to compile specific adapter support into the kernel, but it is not necessary. As we saw in the previous section on dynamically loadable modules, network interfaces are usually controlled by loadable modules. All Linux systems need a network inter- face to run TCP/IP, but that interface does not need to be compiled into the kernel. Selecting Networking options from the main menu in Figure 5-1 opens the Network options window, which contains over 60 menu selections because Linux supports a wide range of network services. Some of these are experimental and some relate to protocols other than IPv4. Here we limit ourselves to those options that directly relate to IPv4. Yet there are still a substantial number of options. They are: Packet socket This service allows applications to communicate directly with the network device. It is required for applications such as tcpdump that do packet capture and packet filtering. If Packet socket is enabled, Packet socket: mmapped IO can be selected to use memory-mapped I/O for the packet socket service. Packet socket service is usually enabled while packet socket memory mapped I/O is usually disabled. Kernel/User netlink socket This service provides communication between the kernel and user space pro- grams. If enabled, Routing messages and Netlink device emulation can also be selected. Netlink sockets permit user space programs to interface with IPv4 rout- ing and ARP tables and with kernel firewall code. Kernel Configuration 117 This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.Network packet filtering This service provides the IP packet filtering services that are required to make the system function as a firewall or a network address translation box. If Network packet filtering is enabled, Network packet filtering debugging can also be selected. Network packet filtering is normally enabled on routers and disabled on hosts, although it can be used to improve server security as described in the iptables section of Chapter 12. TCP/IP networking This selection installs kernel support for TCP/IP. It provides all basic TCP/IP transport and datagram protocols. Once TCP/IP networking is selected, many other optional TCP/IP services become available, listed below: IP: multicasting This provides IP multicasting support. Multicasting is described in Chapter 2. IP: advanced router This menu selection highlights several options that configure the kernel for advanced routing protocols. Advanced routing does not need to be enabled for basic routing to work, and is not needed for a host or a small interior router. Advanced routing is used only if the Linux system is configured as the primary router or an exterior router between autonomous systems. Chapter 7 describes how gated is used to run advanced routing protocols on Unix systems. The kernel configuration advanced routing options are: IP: policy routing enables kernel-level policy-based routing, which is dis- cussed in Chapter 7 in relationship to the BGP routing protocol, and in Chapter 2 in relationship to the Policy Routing Database (PRDB). This option is not needed by gated, which implements policy-based routing at the user level. IP: equal cost multipath enables kernel support for multiple routes to the same destination. Multipath routing is described in Chapter 7 in relation- ship to the OSPF routing protocol. IP use TOS value as routing key enables a type of tag switching (also called label switching) that uses the Type of Service (TOS) field of the IP header to hold the tag. Both OSPF and RIP version 2 can use a tag field. Appendix B touches upon the gated syntax used for tag fields. IP: verbose route monitoring increases the number and length of the routing table update messages. IP: large routing tables increases the memory reserved for the routing table. IP: kernel level autoconfiguration This service is used on diskless clients. When selected, two additional selec- tions become available, IP: BOOTP support and IP: RARP support, that are used to specify whether the configuration comes from BOOTP or RARP. See Chapter 3 for a description of BOOTP and RARP. 118 Chapter 5: Basic Configuration This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.IP: tunneling This service encapsulates IPv4 datagrams within an IP tunnel, which makes a host appear to be on a different network than the one to which it is physi- cally connected. This service is occasionally used on laptop machines to facilitate mobility. IP: GRE tunnels over IP This enables the Generic Routing Encapsulation (GRE) protocol that is used to encapsulate IPv4 or IPv6 datagrams in an IPv4 tunnel. Selecting this option makes the IP: broadcast GRE over IP option available, which pro- vides support for multicasting with the tunnel. GRE is the preferred encap- sulation protocol when dealing with Cisco routers. IP: multicast routing This selection provides support for multicast routing. It is needed only if your system acts as a multicast router, i.e., runs mrouted. When selected, you are given the options IP: PIM-SM version 1 support and IP: PIM-SM version 2 support that set the level of the PIM-SM protocol used by your system. IP: TCP Explicit Congestion Notification support This enables Explicit Congestion Notification (ECN). ECN messages are sent from a router to a client to alert the client of congestion. This would be enabled only if the Linux system is a router. Because many firewalls are incompatible with ECN, it is recommended that ECN not be enabled. IP: TCP syncookie support This enables support for SYN cookies, which are used to counteract SYN flooding denial-of-service attacks. IP: Netfilter Configuration Selecting this menu item opens a window that allows you to select a range of services for the kernel’s Netfilter firewall. The iptables discussion in Chapter 12 describes how the Netfilter service is used. QoS and/or fair queueing This specifies options that change the way network packets are handled by the server. Because it is experimental, this option should be set to n for an opera- tional server. The optional packet handlers require special software to adminis- ter them. After completing the network configuration, run make dep; make clean to build the dependencies and clean up the odds and ends. When the makes are complete, com- pile the kernel. The make bzImage command builds a compressed kernel and puts it into the /usr/src/linux/i386/boot directory. When you’re sure that the new kernel is Most Linux systems use a compressed kernel that is automatically decompressed during the system boot. Kernel Configuration 119 This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.ready to run, simply copy the new kernel file, bzImage, to the vmlinuz file your sys- tem uses to boot. Linux’s list of network configuration options is long. Linux is yin to the Solaris yang: Linux permits the system administrator to configure everything while Solaris configures everything for the administrator. BSD kernel configuration lies some- where between these two extremes. The BSD Kernel Configuration File Like Linux, the BSD Unix kernel is a C program compiled and installed by make. The config command reads the kernel configuration file and generates the files (includ- ing the Makefile) needed to compile and link the kernel. On FreeBSD systems, the † kernel configuration file is located in the directory /usr/src/sys/i386/conf. A large kernel configuration file named GENERIC is delivered with the FreeBSD sys- tem. The GENERIC kernel file configures all of the standard devices for your sys- tem—including everything necessary for TCP/IP. In this section, we look at just those items found in the GENERIC file that relate to TCP/IP. No modifications are necessary for the GENERIC kernel to run basic TCP/IP services. The reasons for modifying the BSD kernel are the same as those discussed for the Linux kernel: to make a smaller, more efficient kernel, or to add new features. There is no standard name for a BSD kernel configuration file. When you create a configuration file, choose any name you wish. By convention, BSD kernel configura- tion filenames use uppercase letters. To create a new configuration, copy GENERIC to the new file and then edit the newly created file. The following creates a new con- figuration file called FILBERT: cd /usr/src/sys/i386/conf cp GENERIC FILBERT If the kernel has been modified on your system, the system administrator will have created a new configuration file in the /usr/src/sys/i386/conf directory. The kernel configuration file contains many configuration commands that cover all aspects of the system configuration. This text discusses only those parameters that directly affect TCP/IP configuration. See the documentation that comes with the FreeBSD ‡ system for information about the other configuration commands. Not only is this list long, it is bound to change. Always check the system documentation before starting a kernel reconfiguration. † /usr/src/sys is symbolically linked to /sys. We use /usr/src/sys only as an example. Your system may use another directory. ‡ The book The Complete FreeBSD by Greg Lehey (published by Walnut Creek CDROM Books) is a good source for information on recompiling a BSD kernel. 120 Chapter 5: Basic Configuration This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.TCP/IP in the BSD Kernel For a network administrator, it is more important to understand which kernel state- ments are necessary to configure TCP/IP than to understand the detailed structure of each statement. Three types of statements are used to configure TCP/IP in the BSD kernel: options, pseudo-device, and device statements. The options statement The options statement tells the kernel to compile a software option into the system. The options statement that is most important to TCP/IP is: options INET basic networking supportmandatory Every BSD-based system running TCP/IP has an options INET statement in its kernel configuration file. The statement produces a -DINET argument for the C compiler, which in turn causes the IP, ICMP, TCP, UDP, and ARP modules to be compiled into the kernel. This single statement incorporates the basic transport and IP data- gram services into the system. Never remove this statement from the configuration file. options ICMP_BANDLIM Rate limit bad replies This option limits the amount of bandwidth that can be consumed by ICMP error messages. Use it to protect your system from denial-of-service attacks that deliber- ately cause errors to overload your network. options "TCP_COMPAT_43" Compatible with BSD 4.3 KEEP THIS This option prevents connections between BSD 4.3 and FreeBSD systems from hang- ing by adjusting FreeBSD to ignore mistakes made by 4.3. In addition, setting this parameter prevents some applications from malfunctioning. For these reasons, keep this parameter as is. The pseudo-device statement The second statement type required by TCP/IP in all BSD configurations is a pseudo- device statement. A pseudo-device is a device driver not directly associated with an actual piece of hardware. The pseudo-device statement creates a header (.h) file that is identified by the pseudo-device name in the kernel directory. For example, the statement shown below creates the file loop.h: pseudo-device loop loopback networkmandatory The loop pseudo-device is necessary to create the loopback device (lo0). This device is associated with the loopback address 127.0.0.1; it is defined as a pseudo-device because it is not really a piece of hardware. Another pseudo-device that is used on many FreeBSD TCP/IP systems is: pseudo-device ether basic Ethernet support Kernel Configuration 121 This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.This statement is necessary to support Ethernet. The ether pseudo-device is required for full support of ARP and other Ethernet specific functions. While it is possible that a system that does not have Ethernet may not require this statement, it is usually configured and should remain in your kernel configuration. Other commonly configured pseudo-devices used by TCP/IP are those that support SLIP and PPP. pseudo-device sl 2 Serial Line IP This statement defines the interface for the Serial Line IP protocol. The number, 2 in the example, defines the number of SLIP pseudo-devices created by the kernel. The two devices created here would be addressed as devices sl0 and sl1. pseudo-device ppp 2 Point-to-point protocol The ppp pseudo-device is the interface for the Point-to-Point Protocol. The number, 2 in the example, defines the number of PPP pseudo-devices created by the kernel. The two devices created here would be addressed as devices ppp0 and ppp1. One other pseudo-device is directly related to PPP. pseudo-device tun 1 Tunnel driver(user process ppp) The tun pseudo-device is a tunnel driver used by user-level PPP software. Tunneling is when a system passes one protocol through another protocol; tun is a FreeBSD feature for doing this over PPP links. The number, 1 in the example, is the number of tunnels that will be supported by this kernel. One pseudo-device is used for troubleshooting and testing. pseudo-device bpfilter 4 Berkeley packet filter The bpfilter statement adds the support necessary for capturing packets. Capturing packets is an essential part of protocol analyzers such as tcpdump; see Chapter 13. When the bpfilter statement is included in the BSD kernel, the Ethernet interface can be placed into promiscuous mode. An interface in promiscuous mode passes all pack- ets, not just those addressed to the local system, up to the software at the next layer. This feature is useful for a system administrator troubleshooting a network. But it can also be used by intruders to steal passwords and compromise security. Use the bpfilter pseudo-device only if you really need it. The number, 4 in the example, indi- cates the maximum number of Ethernet interfaces that can be monitored by bpfilter. The device statement Real hardware devices are defined using the device statement. Every host connected to a TCP/IP network requires some physical hardware for that attachment. The hard- ware is declared with a device statement in the kernel configuration file. There are This assumes that the Ethernet hardware is capable of functioning in promiscuous mode. Not all Ethernet boards support this feature. 122 Chapter 5: Basic Configuration This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.many possible network interfaces for TCP/IP, but the most common are Ethernet interfaces. The device statements for Ethernet interfaces found in the GENERIC ker- nel are listed below: device de DEC/Intel DC21x4x (``Tulip'') device fxp Intel EtherExpress PRO/100B (82557, 82558) device tx SMC 9432TX (83c170 ``EPIC'') device vx 3Com 3c590, 3c595 (``Vortex'') device wx Intel Gigabit Ethernet Card (``Wiseman'') device dc DEC/Intel 21143 and various workalikes device rl RealTek 8129/8139 device sf Adaptec AIC-6915 (``Starfire'') device sis Silicon Integrated Systems SiS 900/SiS 7016 device ste Sundance ST201 (D-Link DFE-550TX) device tl Texas Instruments ThunderLAN device vr VIA Rhine, Rhine II device wb Winbond W89C840F device xl 3Com 3c90x (``Boomerang'', ``Cyclone'') device ed0 at isa? port 0x280 irq 10 iomem 0xd8000 device ex device ep device wi WaveLAN/IEEE 802.11 wireless NIC device an Aironet 4500/4800 802.11 wireless NICs device ie0 at isa? port 0x300 irq 10 iomem 0xd0000 device fe0 at isa? port 0x300 device le0 at isa? port 0x300 irq 5 iomem 0xd0000 device lnc0 at isa? port 0x280 irq 10 drq 0 device cs0 at isa? port 0x300 device sn0 at isa? port 0x300 irq 10 The device statement used to configure an Ethernet interface in the FreeBSD kernel comes in two general formats: device ed0 at isa? port 0x280 net irq 10 iomem 0xd8000 device de0 The format varies depending on whether the device is an ISA device or a PCI device. The ed0 device statement defines the bus type (isa), the I/O base address (port 0x280), the interrupt number (irq 10) and the memory address (iomem 0xd8000). These values should match the values configured on the adapter card. All of these are standard items for configuring PC ISA hardware. On the other hand, the de0 device statement requires very little configuration because it configures a card attached to the PCI bus. The PCI is an intelligent bus that can determine the configuration directly from the hardware. Ethernet is not the only TCP/IP network interface supported by FreeBSD. It sup- ports several other interfaces. The serial line interfaces necessary for SLIP and PPP are shown below: device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 device sio2 at isa? disable port IO_COM3 irq 5 device sio3 at isa? disable port IO_COM4 irq 9 Kernel Configuration 123 This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.The four serial interfaces, sio0 through sio3, correspond to the MS-DOS interfaces COM1 to COM4. These are needed for SLIP and PPP. Chapter 6 covers other aspects of configuring PPP. The device statement varies according to the interface being configured. But how do you know which hardware interfaces are installed in your system? Remember that the GENERIC kernel that comes with your FreeBSD system is configured for a large number of devices. A simple way to tell which hardware interfaces are installed in your system is to look at the messages displayed on the console at boot time. These messages show all of the devices, including network devices, that the kernel found during initialization. Look at the output of the dmesg command. It displays a copy of the console messages generated during the last boot. Customizing the kernel for your network device more often than not means removing unneeded devices from the ker- nel configuration. The options, pseudo-device, and device statements found in the kernel configura- tion file tell the system to include the TCP/IP hardware and software in the kernel. The statements in your configuration may vary somewhat from those shown in the previous examples. But you have the same basic statements in your kernel configura- tion file. With these basic statements, FreeBSD Unix is ready to run TCP/IP. You may never change any of the variables discussed in this section. Like everything else in the kernel configuration file, they usually come correctly configured to run TCP/IP. You will, however, frequently be called upon to control the network ser- vices your server runs over TCP/IP. We’ll now look at how network services are started and how you control which ones are started. Startup Files The kernel configuration brings the basic transport and IP datagram services of TCP/IP into Unix. But there is much more to the TCP/IP suite than just the basic services. How are these other protocols included in the Unix configuration? Some protocols are explicitly started by including them in the boot files. This tech- nique is used, for example, to start the Routing Information Protocol (RIP) and the Domain Name System (DNS). Network services that either have a long startup pro- cedure or are in constant demand are normally started by a script at boot time, and run as daemon processes the entire time the system is running. Anything that can be run from a shell prompt can be stored in a file and run as a shell script. Systems use this capability to automate the startup of system services. There are two basic Unix startup models that control how startup files are invoked: the BSD model and the System V model. The BSD model is the simplest: a limited number of startup scripts are executed in order every time the system boots. At its simplest, there are three basic scripts, /etc/rc, /etc/rc.boot, and /etc/rc.local, executed in that order for system initialization, service 124 Chapter 5: Basic Configuration This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.initialization, and local customization. On BSD Unix systems, network services are usually started by the /etc/rc.boot file or the /etc/rc.local file. On systems that use the BSD startup model, place customized network configura- tion commands in the rc.local script. rc.local executes at the end of the startup pro- cess. Any configuration values set in this file override the earlier configuration commands. The BSD startup model is used on BSD systems and SunOS systems. Linux and Solaris systems use the System V startup model. The System V startup model employs a much more complex set of startup files. This model uses whole directo- ries of scripts executed by the init process, with different directories being used depending on the runlevel of the system. Startup Runlevels To understand System V startup, you need to understand runlevels, which are used to indicate the state of the system when the init process is complete. There is noth- ing inherent in the system hardware that recognizes runlevels; they are purely a soft- ware construct. init and /etc/inittab—the file used to configure init—are the only reasons why the runlevels affect the state of the system. We use Red Hat Linux as an example of how runlevels are used. Linux defines several runlevels that run the full gamut of possible system states from not-running (halted) to running multiple processes for multiple users: • Runlevel 0 shuts down all running processes and halts the system. • Runlevel 1 places the system in single-user mode. Single-user mode is used by the system administrator to perform maintenance that cannot be done when users are logged in. This runlevel may also be indicated by the letter Sinstead of the number 1. Solaris uses S for single-user mode. • Runlevel 2 is a special multiuser mode that does not support file sharing. • Runlevel 3 provides full multiuser support with the full range of services, includ- ing NFS file sharing. It is the default mode used on Solaris systems. • Runlevel 4 is unused. You can design your own system state and implement it through runlevel 4. • Runlevel 5 initializes the system as a dedicated X Windows terminal. Linux sys- tems use this to provide an X Windows console login. When Linux systems boot at runlevel 3, they provide a text-based console login. Solaris does not use this runlevel. Entering runlevel 5 on a Solaris system causes a system shutdown. • Runlevel 6 shuts down all running processes and reboots the system. A good description of the maze of System V initialization files is provided in Essential System Administration by Æleen Frisch (O’Reilly & Associates). Startup Files 125 This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.As these notes make clear, different systems use the same runlevels in different ways. That is because runlevels are software. They are boot command arguments that tell init which startup scripts should be run. The scripts that are run can contain any valid commands. init maps runlevels to startup scripts using the inittab file. Understanding /etc/inittab All of the lines in the inittab file that begin with a sharp sign () are comments. A lib- eral dose of comments is needed because the syntax of inittab configuration lines is terse and arcane. An inittab entry has this general format: label:runlevel:action:process The label is a one- to four-character tag that identifies the entry. Because some sys- tems support only two-character labels, most configurations limit all labels to two characters. The labels can be any arbitrary character string; they have no intrinsic meaning. The runlevel field indicates the runlevels to which the entry applies. For example, if the field contains a 3, the process identified by the entry must be run for the system to initialize runlevel 3. More than one runlevel can be specified. Entries that have an empty runlevel field are not involved in initializing specific runlevels. For example, Linux systems have an inittab entry to handle the three-finger salute (Ctrl+Alt+Del); it does not have a value in the runlevel field. The action field defines the conditions under which the process is run. Table 5-1 lists the action values used on Red Hat, Mandrake, and Caldera Linux systems. Table 5-1. Linux inittab action values Action Meaning Boot Runs when the system boots. Runlevels are ignored. Bootwait Runs when the system boots, and init waits for the process to complete. Runlevels are ignored. Ctrlaltdel Runs when Ctrl+Alt+Del is pressed, which passes the SIGINT signal to init. Runlevels are ignored. Initdefault Doesn’t execute a process. It sets the default runlevel. Kbrequest Runs when init receives a signal from the keyboard. This requires that a key combination be mapped to KeyBoardSignal. Off Disables the entry so the process is not run. Once Runs one time for every runlevel. Ondemand Runs when the system enters one of the special runlevels A, B, or C. Powerfail Runs when init receives the SIGPWR signal. Powerokwait Runs when init receives the SIGPWR signal and the file /etc/powerstatus contains the word OK. Powerwait Runs when init receives the SIGPWR signal, and init waits for the process to complete. Respawn Restarts the process whenever it terminates. sysinit Runs before any boot or bootwait processes. wait Runs the process upon entering the run mode, and init waits for the process to complete. 126 Chapter 5: Basic Configuration This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.The last field in an inittab entry is process. It contains the process that init executes. The process appears in the exact format that it is executed from the command line. Therefore the process field starts with the name of the program that is to be executed followed by the arguments that will be passed to that process. For example, /sbin/ shutdown –t3 –r now, which is the process executed by some Linux systems when Ctrl+Alt+Del is pressed, is the same command that could be typed at the shell prompt to reboot the system. On most inittab entries, the process field contains the name of a startup script. Two main types of startup scripts are used: the system initialization script and the runlevel initialization scripts. These sample lines from a Red Hat Linux system show both: System initialization. si::sysinit:/etc/rc.d/rc.sysinit l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6 These seven lines are the real heart of the inittab file—they invoke the startup scripts. The first line tells init to run the boot script located at /etc/rc.d/rc.sysinit to initialize the system. This entry has no runlevel value. It is run every time the system starts. The system initialization script performs certain essential tasks. For example, the Red Hat rc.sysinit script: • Initializes the swap space • Runs the filesystem check • Mounts the /proc filesystem • Mounts the root filesystem as read-write after the fsck completes • Loads the loadable kernel modules Other initialization scripts may look different than Red Hat’s, but they perform very similar functions. For example, a Caldera system begins by loading the loadable modules. It then activates the swap space, does the filesystem check, and remounts the root filesystem as read-write. The order is different, but the major functions are the same. After the system initialization script is run, init runs a script for the specific run- level. The remaining six lines in the sample are used to invoke the startup scripts for individual runlevels. Except for the runlevel involved, each line is identical. Let’s use the line with label l3 as an example. This line starts all of the processes and services needed to provide the full multiuser support. The runlevel is 3. The action wait directs init to wait until the startup script terminates before going on to any Startup Files 127 This is the Title of the Book, eMatter Edition Copyright © 2010 O’Reilly & Associates, Inc. All rights reserved.

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.