linux


Configuring the DHCP Server After dhcpd is installed, it must be configured. The DHCP daemon is configured through the dhcpd.conf file. The file can contain an extensive list of configuration commands that provide direction to the server and configuration information to the clients. A DHCP server can be configured to provide service to individual hosts and to entire subnets of hosts. The dhcpd configuration language includes host and subnet statements that identify the scope of systems being serviced. A host statement might contain the following: host osprey { hardware ethernet 00:00:0C:43:8D:FB ; fixed-address 172.16.70.8 ; } This statement defines the hostname, Ethernet address, and IP address of the client. When configured in this way, dhcpd provides a static address assignment similar to the service provided by a BootP server. This statement matches the client’s Ethernet address against the configuration entry, and returns a static IP address to the client. Using this technique, DHCP can be used to assign static addresses to systems, such as name servers, that require static addresses. The format of the subnet statement is subnet 172.16.70.0 netmask 255.255.255.0 { range 172.16.70.100 172.16.70.250 ; } The subnet statement declares that the system is providing DHCP service to network 172.16.70.0. Furthermore, the range clause says that the server is providing dynamic addressing, and that the

Hint: If you are looking for very good and affordable webspace to host and run your j2ee hosting application check Virtualwebstudio j2ee web hosting services

This causes dhcpd to read its configuration from /var/dhcp/test.conf, but the /etc/dhcpd.conf file is still required! The /etc/init.d/dhcpd script does not run dhcpd unless it finds both the /etc/ dhcpd.conf file and the /var/lib/dhcp/dhcpd.leases file. Initializing the dhcpd.leases File dhcpd stores a database of the address leases it has assigned in the dhcpd.leases file. The file must exist for dhcpd to boot. When the server is first installed, create an empty dhcpd.leases file to ensure that the daemon starts correctly. dhcpd writes database entries into the file as ASCII text. If you’re curious, you can view the file to see what leases have been assigned. Entries in the file have the following format: lease address {statements} Each lease begins with the keyword lease and the IP address that is assigned by the lease. This is followed by a group of statements that define the characteristics of the lease. Possible values that might appear in the list of statements include the following: starts date Records the start time of the lease. date contains the weekday, year, month, day, hour, minute, and second when the lease started. ends date Records the time when the lease will end. date contains the weekday, year, month, day, hour, minute, and second when the lease will end. hardware hardware-type mac-address Records the client’s physical-layer address. On an Ethernet, the hardware-type is ethernet, and the mac-address is the Ethernet address. uid client-identifier Records the client’s DHCP identifier if one was used by the client when it obtained the lease. Most clients are identified by their MAC addresses, and do not require a separate DHCP identifier. client-hostname “name” Records the client’s hostname if the client provided it using the client-hostname DHCP option. (Much more will be said about DHCP options later in this chapter.) hostname “name” Records the client’s hostname if the client provided a hostname using the hostname DHCP option. Microsoft Windows clients send their hostnames to the server using the hostname option. abandoned Identifies this as an abandoned lease. If the server has trouble assigning an address (either because the client rejects the address, or the server determines that an unassigned address is already in use), the server marks it “abandoned” until it runs short of available addresses and needs to try this one again. Use this information when you want to examine the contents of the dhcpd.leases file. Beyond that, you don’t need to be concerned about these commands. When you create the file, you create it empty. After you create it, you can forget about it because dhcpd maintains the file. The file that does require your input, however, is the dhcpd.conf file that is used to configure the server. 234
Note: If you are looking for cheapest and affordable webspace to host and run your servlet application check Astra servlet hosting services

Running dhcpd Under Red Hat Linux 7.2, the DHCP daemon is started by the /etc/init.d/dhcpd script. The script accepts the same arguments as the /etc/init.d/named script described in Chapter 4. The most commonly used arguments are start, stop, and restart. For example, the following command will start dhcpd: [root]# service dhcpd start Starting dhcpd: [ OK ] Use a tool such as chkconfig or tksysv to ensure that the /etc/init.d/dhcpd startup script is run whenever the system reboots. On our sample Red Hat system, the following chkconfig commands cause the dhcpd script to run whenever the system reboots in runlevel 3 or 5: [root]# chkconfig –list dhcpd dhcpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off [root]# chkconfig –level 35 dhcpd on [root]# chkconfig –list dhcpd dhcpd 0:off 1:off 2:off 3:on 4:off 5:on 6:off The /etc/init.d/dhcpd script uses the dhcpd command to start the DHCP server. The syntax of the dhcpd command is dhcpd [-p port] [-f] [-d] [-q] [-cf file] [-lf file] [interface-list] -p port Defines an alternate port. Normally, dhcpd listens for client requests on port 67, and responds on port 68. Use the -p option to change to non-standard ports. This is used only for testing. -f Runs dhcpd as a foreground process. This is used only for debugging. -d Sends error messages to stderr instead of to syslogd. -q Prevents dhcpd from printing out its startup message. -cf file Identifies the file from which dhcpd should read its configuration. By default, dhcpd reads its configuration from /etc/dhcpd.conf. -lf file Identifies the file to which dhcpd should write address lease information. By default, dhcpd writes lease information to /var/lib/dhcp/dhcpd.leases. interface-list Lists the names of the interfaces that dhcpd should monitor for client request. By default, dhcpd listens to all interfaces that support broadcasts. To set dhcpd command-line arguments on a Red Hat system, store the arguments in the file /etc/ sysconfig/dhcpd. The /etc/init.d/dhcpd script reads arguments from that file before starting the DHCP daemon. For example, to make dhcpd read its configuration from a file named /var/dhcp/ test.conf, create a /etc/sysconfig/dhcpd file that contains the following: [root]# cat /etc/sysconfig/dhcpd # Command line options here DHCPDARGS=-cf /var/dhcp/test.conf 233
Note: If you are looking for cheapest and affordable webspace to host and run your servlet application check Astra servlet hosting services

Using dhcpd with Old Linux Kernels dhcpd works well with the Linux 2.4 kernel. However, if your Linux system uses an outdated kernel, installing dhcpd may not be all that is required to get it running. In that case, there are a few potential problems that need to be addressed by system-specific configurations. The best way to solve these problems is to update to a new kernel. If, for some reason, you are unwilling to update your kernel, you should read this sidebar. If you provide service to Microsoft Windows DHCP clients, you may encounter problems with the limited broadcast address. If it appears that Microsoft Windows clients do not see DHCP messages from the server while other types of clients do, you need to define a specific route for the limited broadcast address on your Linux server. To do so, first add the name all-ones to the /etc/hosts table: 255.255.255.255 all-ones Then, add a route for the limited broadcast address: route add -host all-ones dev eth0 To reinstall the special route after each boot, add the route statement to the rc.local startup script. Old distributions with the versions of the kernel that require it often include the code to add the limited broadcast route in the /etc/rc.d/init.d/dhcpd script used to start dhcpd. In addition to the limited broadcast problem, there are some other problems that relate to old Linux kernels. Multiple network interfaces dhcpd cannot use multiple interfaces with Linux kernels prior to version 2.0.31. SO_ATTACH_FILTER undeclared This error may occur when compiling dhcpd under Linux 2.2. If it occurs, the symbolic link /usr/include/asm may be broken. That link should point to the Linux asm headers. Protocol not configured To run under Linux 2.1 and 2.2, dhcpd needs the CONFIG_PACKET and CONF_FILTER options configured in the kernel. If the message Set CONFIG_PACKET=y and CONFIG_FILTER=y in your kernel configuration is displayed during the dhcpd build, you need to reconfigure the kernel and enable these options. See Chapter 13, “Troubleshooting,” for information on configuring the kernel. IP BootP agent Linux 2.1 will run dhcpd only if the BootP agent is enabled. (The BootP agent is part of dhcpd.) Check to see whether /proc/sys/net/ipv4/ip_bootp_ agent exists. If it does, check to see if it contains a 1. If it doesn’t exist or contain a 1, insert the following line into a startup script to write a 1 to the ip_bootp_agent file: echo 1 > /proc/sys/net/ipv4/ip_bootp_agent Linux kernel 2.4 solves all of these problems. However, as the Linux kernel versions change and new releases of dhcpd are issued, new problems may emerge. See the README file that comes with the dhcpd distribution for the latest information. 232
Note: If you are looking for cheapest and affordable webspace to host and run your servlet application check Astra servlet hosting services

Reverse Address Resolution Protocol Before leaving the topic of configuration protocols, we should quickly mention Reverse Address Resolution Protocol (RARP). As the name implies, it is the reverse of ARP. Instead of asking for an Ethernet address in response to an IP addresses, this protocol broadcasts an Ethernet address, and asks for an IP address in response. A RARP server uses the /etc/ethers file to map Ethernet addresses to IP addresses. It then sends the IP address from the ethers file to the client system. A sample /etc/ethers file is shown here: 00:00:C0:4F:3E:DD bluejay 00:10:4B:87:D4:A8 duck 08:00:20:82:D5:1D raven 00:00:0C:43:8D:FB osprey Each line in the file contains an Ethernet address, followed by a hostname or IP address. Hostnames are most commonly used, but they must be valid names that map to IP addresses. We mention this protocol because the nsswitch.conf file covered in Chapter 4, “Linux Name Services,” includes /etc/ethers as a part of the NIS service, which might make you curious about it. However, you should not use RARP. RARP only provides the client with an IP address. No other configuration information is provided. Much better configuration servers are available for Linux, including DHCP, which is the right configuration server for most networks. Installing the DHCP Server Many Linux distributions include the DHCP daemon (dhcpd). dhcpd is the server side of DHCP, and is required only on the DHCP server. The clients do not run dhcpd. Information on configuring a DHCP client is provided later in the chapter. The DHCP server software is a component that can be selected during the initial Linux installation. If the DHCP server software was not installed as part of the initial installation, install it now using a package manager such as the rpm command or the X Windows tool gnorpm. If you use gnorpm, DHCP can be found in the System Environment/Daemons display. Note For an example of using the rpm command to install a software package, see the “Using Package Manager” section in Chapter 5, “The Apache Web Server.” Of course, it is possible that your Linux system does not come with the DHCP software, or that you want a more recent version than the one that comes with your system. In either case, you can download the source code for dhcpd from http://www.isc.org/ or (via anonymous FTP) from ftp.isc.org/isc/dhcp , where it is stored in a gzipped tar file. Restore the tar file, change to the directory it creates, and run the ./configure script located there. configure determines the type of system you’re running, and creates the correct Makefile for that system. Run make to compile the software. (If you have an outdated Linux system, see the following sidebar, “Using dhcpd with Old Linux Kernels,” for information about problems that you might encounter.) On current Linux systems, dhcpd should compile without errors. Of course, things may change with future releases. If you get errors, send mail to the dhcp-server@isc.org mailing list, describing your configuration and the exact problem you have. The list is read by most of the people using dhcpd, and someone may have already solved your problem. To join the mailing list, go to www.isc.org/services/public/lists/dhcp-lists.html and fill out the form. 231
Note: If you are looking for high quality webhost to host and run your jsp application check Vision jsp hosting services

The client puts all of the information it knows about itself in the BOOTREQUEST packet, which might be only its physical-layer address. When a BootP server receives a packet on port 67, it creates a BOOTREPLY packet by filling in as much of the missing configuration information as it can. The server then broadcasts the packet back to the network using UDP port 68. The client listens on port 68. When it receives a packet on the port that contains its physical-layer address, it uses the information from the packet to configure TCP/IP. Dynamic Host Configuration Protocol BootP is simple and effective. So effective, in fact, that it became the basis for Dynamic Host Configuration Protocol. DHCP operates over the same UDP ports, 67 and 68, as BootP. It provides all of the services of BootP as well as some important extensions. DHCP is designed to provide all possible TCP/IP configuration parameters to its clients. DHCP includes every parameter that was defined in the “Requirements for Internet Hosts” RFC, which means that everything necessary for TCP/IP can be configured from the DHCP server. The other, and probably more important, extension is that DHCP permits IP addresses to be dynamically assigned. Manually configuring a system with ifconfig permanently assigns an address to the interface. The address assigned to a host through BootP is also a permanent assignment. Both of these techniques are static the address is permanently assigned and cannot be used for any other host. With DHCP, an address is “leased” to the host for a specific period of time. When the time expires, the host must either renew the lease or return the address to the server so that it can be assigned to another system. The advantages of dynamic address assignment are as follows: You don’t need to create a custom configuration for each host. On a BootP server, you must create a configuration for every client because you are responsible for assigning each system a unique IP address. With a DHCP server, the server is responsible for the address assignments. It makes more effective use of scarce IP addresses. Unused addresses are returned to the address pool, from where they can be used again. Dynamic address assignment, like everything else, is not perfect. DNS may not know about addresses that are assigned through DHCP, which means that remote computers could not look up the address of a system that got its address from DHCP. In that case, a system using a dynamically assigned address could not offer services to other systems. This is a shortcoming, but it’s not a fatal flaw. First, only officially recognized servers should offer services to other systems, and skilled technical people who don’t have any trouble doing a TCP/IP configuration run most servers. Second, the number of servers on a network is small compared with the total number of systems, and therefore the burden of server configuration is correspondingly small. Third, the bulk of the systems on a network are desktop systems that shouldn’t offer TCP/IP services to remote users, so they do not need static IP addresses. This makes desktop clients perfect candidates for dynamic address assignment. And finally, there are techniques for coordinating addresses between DHCP and DNS using Dynamic DNS (DDNS). To find out more about DDNS, see Linux DNS Server Administration by Craig Hunt, Sybex 2001. Even without DDNS, DHCP works fine for most systems, and can dramatically decrease the configuration workload. 230
Note: If you are looking for high quality webhost to host and run your jsp application check Vision jsp hosting services

Chapter 8: Desktop Configuration Servers Overview TCP/IP is able to link the world together into a global Internet because it does not depend on any one physical network technology. It can run over the modem attached to a PC or over the fiber-optic network attached to a super computer. It does this by creating a logical network on top of the physical networks that is independent of the specific characteristic of any one network. However, this flexibility comes at the price of complexity. It is more difficult to configure a computer to run TCP/IP than it is to configure it for some other networks. You’re a technical person that’s why you run the network. Configuring TCP/IP may seem very simple to you, but it can be a daunting task for the average user setting up a PC. If your network is small, you can manually configure all of the desktop systems yourself. On a large network, manual configuration becomes an impossible task. Even on a small network, fixing the configuration every time a user upgrades is a thankless and boring job. The solution is to create a server that does this job for you, which is the topic of this chapter. Understanding Configuration Protocols Protocol developers have worked to reduce the burden of manual system configuring for a long time. Some of the documents that define the configuration protocols are more than 15 years old. Surprisingly, these protocols have come into widespread use only in the past few years. This is partly because the early users of the Internet were technical people who liked to configure their own systems, and partly because of the tremendous growth in the number of systems running TCP/IP that occurred at the end of the 1990s. Microsoft also deserves some credit for pushing hard to get people to use Dynamic Host Configuration Protocol (DHCP), which is the best of the configuration protocols. This section examines DHCP, as well as the other configuration protocols used to configure desktop systems. Bootstrap Protocol Bootstrap Protocol (BootP) was the first comprehensive configuration protocol. It can provide all of the information commonly used to configure TCP/IP from the client’s IP address to which print server the client should use. The BootP protocol is designed to deliver this information to the client, even though the client doesn’t have an IP address. Here’s how it works. The BootP client broadcasts a BOOTREQUEST packet to UDP port 67, using a special IP broadcast address of 255.255.255.255 that is called the limited broadcast address. The broadcast address assigned in Chapter 2, “The Network Interface,” with the ifconfig command was made up of the network address with a host field of all ones; for example, 172.16.55.255. Clearly, a BootP client that doesn’t know the network address couldn’t use such a broadcast address, which is why the limited broadcast address is used. Note Unless specially configured to do so, routers do not forward the limited broadcast address. For this reason, configuration servers are traditionally departmental servers, with one server placed on each subnet. Later in this chapter, we will see how relay servers can be used to support a centralized configuration server for organizations that prefer centralization over distributed departmental servers. 229
Note: If you are looking for high quality webhost to host and run your jsp application check Vision jsp hosting services

Part III: Departmental Server Configuration Chapter List Chapter 8: Desktop Configuration Servers Chapter 9: File Sharing Chapter 10: Printer Services Chapter 11: More Mail Services Part Overview Featuring: Configuring a DHCP server, client, and relay agent Understanding Linux file permissions Configuring an NFS server and client Using mount, fstab, and automounter to access filesystems Understanding NetBIOS and SMB Configuring an SMB server or client with Samba Installing, configuring, and sharing printers Creating a mailbox server with POP or IMAP Controlling spam e-mail Filtering e-mail with procmail 228
Note: If you are looking for cheapest and affordable webspace to host and run your servlet application check Astra servlet hosting services

calls masquerading, two special rule chains are used: The prerouting chain that handles packets before the router processes the packet for routing The postrouting chain that handles packets after the router processes the packet for routing The iptables command has three policies that are specific to address translation. Policies, sometimes called targets in the iptables syntax, are procedures that process packets. Several policies have been predefined for security processing, and three have been predefined for NAT processing: MASQUERADE This is used to translate an address to the address assigned to the NAT box. SNAT This is used to statically map one specific address to another specific address. DNAT This is used to dynamically map an address to the next available address in a group of addresses. Assume that the small office network attaches to a Linux router acting as a NAT box through the router’s eth0 interface. Further, assume that the Linux router connects to the outside world through its eth1 interface, and that the address assigned to that interface is the official address provided by the ISP. The following iptables command will do the job: # iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE The -t nat option tells iptables that it is working with the address translation chains. The -A option adds this rule to the POSTROUTING chain, which means that this translation will happen after the router determines how to deliver the packet. The -o eth1 option tells iptables that the rule should be applied to any packet that is heading out of the eth1 interface. (-i is used for packets coming in an interface.) The -j MASQUERADE option tells iptables that when a packet matches the conditions of having been processed for routing and of being routed out of interface eth1, iptables should jump to the MASQUERADE policy to complete processing. As noted earlier, the MASQUERADE policy converts the source address of the packet to the address assigned to the router in this case, it converts the source address to the address assigned to interface eth1. With this rule, the one official address assigned to the router can be used to connect all four of the systems on our small network to the Internet at large. Combined with the Linux routing features discussed earlier, when the NAT rule is installed, Linux completely meets the routing needs of our small office network. In Sum This chapter concludes the Internet server operations part of this book. All of the basic services needed for an Internet server have been covered: remote login, file transfer, e-mail, web service, and routing. The next chapter begins Part Three, “Departmental Server Configuration,” in which the services needed on a departmental server are examined. To begin, Chapter 8 covers the DHCP server that simplifies the configuration of desktop computers. 227
Note: If you are looking for cheapest and affordable webspace to host and run your servlet application check Astra servlet hosting services

Network 10.0.0.0 Networks 172.16.0.0 to 172.31.0.0 (Network 172.16.0.0 is used for the examples in this book) Networks 192.168.0.0 to 192.168.255.0 Private network numbers are popular, and for some good reasons: Using a private network number reduces paperwork. You don’t have to ask anyone’s permission to use these addresses. No applications, no fees. Just do it. The addresses are yours. If you change ISPs, there is no need to renumber the hosts on the network. You may need to change the configuration of the NAT box, but that is probably easier than changing the configuration of all of your desktop systems. You conserve IP addresses. Having more addresses than you really need can make designing a network much easier, but you don’t want more than you need if you’re wasting valuable IP addresses. When you use private addresses, you don’t waste any IP addresses. These addresses are reuseable, and the same addresses you’re using are probably being used by hundreds of other private networks around the world. Private IP addresses reduce address spoofing. Spoofing is a security attack in which someone at a remote location pretends to be on your local network by using one of your network addresses. Private IP addresses should not be forwarded through the Internet, so spoofing one of these addresses won’t do the attacker much good. Private network numbers are explicitly defined for private use. They cannot be routed through the Internet because any number of private networks might be using the same addresses. Before packets originating from a host that uses a private IP address can be forwarded to an external network, the source address in the packet must be converted to a valid Internet address. Weigh all of the factors before you decide to use NAT. Network address translation has some problems: It places a small additional overhead on the router, which reduces the router’s performance. It doesn’t work well with all protocols. TCP/IP protocols were not designed with NAT in mind. It interferes with end-to-end authentication schemes that authenticate the source address. Linux 2.4 implements IP address translation in the kernel using the iptables command. Linux includes IP address translation as part of the firewall software that comes with the system. Firewalls and how to configure a Linux server as a firewall are discussed in Chapter 12, “Security.” Chapter 12 provides the real details of the iptables command. This chapter looks at the one aspect of the iptables command that allows you to translate addresses. Configuring a Linux NAT Server Despite the fact that address translation is included in the packet-filtering software used to build a firewall, it is not specifically a security feature. A very common use for address translation is to connect a small network to the Internet. Assume that you have a small office network that connects to the Internet through a local ISP. Further, assume that the ISP assigns the office only one IP address, even though you have four computers on your network. Using a Linux NAT box, all four computers can communicate with the Internet with only one valid IP address. The iptables command processes packets through sets of filtering rules. These sets of rules are called chains. The primary reason to construct these rules is security, and the chains that apply to security are described in Chapter 12. When iptables is used for address translation, which Linux 226
Note: If you are looking for cheapest and affordable webspace to host and run your servlet application check Astra servlet hosting services

Next Page »