• No results found

Part II Foundation Elements

Chapter 3 Workstations

3.1 The Basics

3.1.3 Network Configuration

The third component you need for a large workstation environment is an automated way to updatenetwork parameters, those tiny bits of information that are often related to booting a computer and getting it onto the network. The information in them is highly customized for a particular subnet or even for a particular host. This characteristic is in contrast to a system such as

application deployment, in which the same application is deployed to all hosts in the same configuration. As a result, your automated system for updating network parameters is usually separate from the other systems.

The most common system for automating this process is DHCP. Some vendors have DHCP servers that can be set up in seconds; other servers take considerably longer. Creating a global DNS/DHCP architecture with dozens or hundreds of sites requires a lot of planning and special knowledge. Some DHCP vendors have professional service organizations that will help you through the process, which can be particularly valuable for a global enterprise.

A small company may not see the value in letting you spend a day or more learning something that will, apparently, save you from what seems like only a minute or two of work whenever you set up a machine. Entering an IP address manually is no big deal, and, for that matter, neither is manually entering a netmask and a couple of other parameters. Right?

Wrong. Sure, you’ll save a day or two by not setting up a DHCP server. But there’s a problem: Remember those hidden costs we mentioned at the beginning of this chapter? If you don’t use DHCP, they’ll rear their ugly heads sooner or later. Eventually, you’ll have to renumber the IP subnet or change the subnet netmask, Domain Name Service (DNS) server IP address, or modify some network parameter. If you don’t have DHCP, you’ll spend weeks or months making a single change, because you’ll have to orchestrate teams of people to touch every host in the network. The small investment of using DHCP makes all future changes down the line nearly free.

Anything worth doing is worth doing well. DHCP has its own best and worst practices. The following section discusses what we’ve learned.

3.1.3.1 Use Templates Rather Than Per-Host Configuration

DHCP systems should provide a templating system. Some DHCP systems store the particular parameters given to each individual host. Other DHCP systems store templates that describe what parameters are given to various classes of hosts. The benefit of templates is that if you have to make the same change to many hosts, you simply change the template, which is much better than scrolling through a long list of hosts, trying to find which ones require the change. Another benefit is that it is much more difficult to introduce a syntax error into a configuration file if a program is generating the file. Assuming that templates are syntactically correct, the configuration will be too.

Such a system does not need to be complicated. Many SAs write small programs to create their own template systems. A list of hosts is stored in a

3.1 The Basics 59

database—or even a simple text file—and the program uses this data to pro- gram the DHCP server’s configuration. Rather than putting the individual host information in a new file or creating a complicated database, the infor- mation can be embedded into your current inventory database or file. For ex- ample, UNIXsites can simply embed it into the/etc/ethersfile that is already being maintained. This file is then used by a program that automatically gen- erates the DHCP configuration. Sample lines from such a file are as follows:

8:0:20:1d:36:3a adagio #DHCP=sun 0:a0:c9:e1:af:2f talpc #DHCP=nt 0:60:b0:97:3d:77 sec4 #DHCP=hp4 0:a0:cc:55:5d:a2 bloop #DHCP=any

0:0:a7:14:99:24 ostenato #DHCP=ncd-barney 0:10:4b:52:de:c9 tallt #DHCP=nt

0:10:4b:52:de:c9 tallt-home #DHCP=nt 0:10:4b:52:de:c9 tallt-lab4 #DHCP=nt 0:10:4b:52:de:c9 tallt-lab5 #DHCP=nt

The token#DHCP=would be treated as a comment by any legacy program

that looks at this file. However, the program that generates the DHCP server’s configuration uses those codes to determine what to generate for that host. Hosts adagio, talpc, and sec4 receive the proper configuration for a Sun workstation, a Windows NT host, and an HP LaserJet 4 printer respectively. Hostostenatois an NCD X-Terminal that boots off a Trivial File Transfer Protocol (TFTP) server calledbarney. The NCD template takes a parameter, thus making it general enough for all the hosts that need to read a configu- ration file from a TFTP server. The last four lines indicate that Tom’s laptop should get a different IP address, based on the four subnets to which it may be connected: his office, at home, or the fourth- or fifth-floor labs. Note that even though we are using static assignments, it is still possible for a host to hop networks.4

By embedding this information into an/etc/ethersfile, we reduced the

potential for typos. If the information were in a separate file, the data could become inconsistent.

Other parameters can be included this way. One site put this informa- tion in the comments of its UNIX /etc/hostsfile, along with other tokens

4. SAs should note that this method relies on an IP address specified elsewhere or assigned by DHCP via a pool of addressees.

that indicated JumpStart and other parameters. The script extracts this information for use in JumpStart configuration files, DHCP configuration files, and other systems. By editing a single file, an SA was able to perform huge amounts of work! The open source project HostDB5 expands on this

idea, you edit one file to generate DHCP and DNS configuration files, as well as to distribute them to appropriate servers.

3.1.3.2 Know When to Use Dynamic Leases

Normally, DHCP assigns a particular IP address to a particular host. The dynamic leasesDHCP feature lets one specify a range of IP addresses to be handed out to hosts. These hosts may get a different IP address every time they connect to the network. The benefit is that it is less work for the system administrators and more convenient for the customers.

Because this feature is used so commonly, many people think that DHCP

has to assign addresses in this way. In fact, it doesn’t. It is often better to lock a particular host to a particular IP address; this is particularly true for servers whose IP address is in other configuration files, such as DNS servers and firewalls. This technique is termed static assignment by the RFCs or permanent leaseby Microsoft DHCP servers.

The right time to use a dynamic pool is when you have many hosts chasing a small number of IP addresses. For example, you may have a remote access server (RAS) with 200 modems for thousands of hosts that might dial into it. In that situation, it would be reasonable to have a dynamic pool of 220 addresses.6 Another example might be a network with a high turnover of

temporary hosts, such as a laboratory testbed, a computer installation room, or a network for visitor laptops. In these cases, there may be enough physical room or ports for only a certain number of computers. The IP address pool can be sized slightly larger than this maximum.

Typical office LANs are better suited to dynamically assigned leases. However, there are benefits to allocating static leases for particular machines. For example, by ensuring that certain machines always receive the same IP address, you prevent those machines from not being able to get IP addresses when the pool is exhausted. Imagine a pool being exhausted by a large influx of guests visiting an office and then your boss being unable to access anything because the PC can’t get an IP address.

5. http://everythingsysadmin.com/hostdb/

6. Although in this scenario you need a pool of only 200 IP addresses, a slightly larger pool has benefits. For example, if a host disconnects without releasing the lease, the IP address will be tied up until its lease period has ended. Allocating 10 percent additional IP addresses to alleviate this situation is reasonable.

3.1 The Basics 61

Another reason for statically assigning IP addresses is that it improves the usability of logs. If people’s workstations always are assigned the same IP address, logs will consistently show them at a particular IP address. Finally, some software packages deal poorly with a host changing its IP address. Although this situation is increasingly rare, static assignments avoid such problems.

The exclusive use of statically assigned IP addresses is not a valid secu- rity measure. Some sites disable any dynamic assignment, feeling that this will prevent uninvited guests from using their network. The truth is that someone can still manually configure network settings. Software that permits one to snoop network packets quickly reveals enough information to permit some- one to guess which IP addresses are unused, what the netmask is, what DNS settings should be, the default gateway, and so on.

IEEE 802.1x is a better way to do this. This standard for network access controldetermines whether a new host should be permitted on a net- work. Used primarily on WiFi networks, network access control is being used more and more on wired networks. An Ethernet switch that supports 802.1x keeps a newly connected host disconnected from the network while performing some kind of authentication. Depending on whether the authenti- cation succeeds or fails, traffic is permitted, or the host is denied access to the network.

3.1.3.3 Using DHCP on Public Networks

Before 802.1x was invented, many people crafted similar solutions. You may have been in a hotel or a public space where the network was configured such that it was easy to get on the network but you had access only to an authorization web page. Once the authorization went through—either by providing some acceptable identification or by paying with a credit card— you gained access. In these situations, SAs would like the plug-in-and-go ease of an address pool while being able to authenticate that users have permission to use corporate, university, or hotel resources. For more on early tools and techniques, see Beck (1999) and Valian and Watson (1999) Their systems permit unregistered hosts to be registered to a person who then assumes responsibility for any harm these unknown hosts create.