Setting Up a Server

Examples

Each of the following examples specifies one or more systems:

Specifying a Subnet

When you set up a server, you frequently need to specify the clients that are allowed to connect to that server. Sometimes it is convenient to specify a range of IP addresses, called a subnet. The discussion on page 397 explains what a subnet is and how you can use a subnet mask to specify a subnet. Usually, you can specify a subnet as

n.n.n.n/m.m.m.m

or

n.n.n.n/mbits

where n.n.n.n is the base IP address and the subnet is represented by m.m.m.m (the subnet mask) or mbits (the number of bits used for the subnet mask). For example, 192.168.0.1/255.255.255.0 represents the same subnet as 192.168.0.1/24 . In binary, decimal 255.255.255.0 is represented by 24 ones followed by 8 zeros. The /24 is shorthand for a subnet mask with 24 ones. Each line in Table 11-4 presents two notations for the same subnet followed by the range of IP addresses that the subnet includes.

Table 11-4. Different ways to represent a subnet

Property List Files

A property list is a structured data file, usually with a filename extension of . plist , that stores settings or configuration information. Each element in a property list is a key/value pair. A list of key/value pairs is called a dictionary . A key is typically a string, and a value is either a string, binary data, an array of values, or another (embedded) dictionary. The launchd.plist man page provides examples of the elements of a property list.

Mac OS X stores a property list in one of three formats: plain text, XML, or binary. The application or utility that accesses the property list does not need to know which format the list is inthe operating system provides the application with the information in a format it can use. Many system defaults are implemented through property lists, so even applications that do not access property lists directly are likely to use them indirectly.

The plutil utility (page 815) checks the syntax of property list files and converts them from one format to another.

Plain-Text Property Lists

The original property list format was a human-readable text file, but this format may be phased out in future releases of Mac OS X. A plain-text property list key is a string that must be quoted in the rare case where it contain SPACEs . A string value is represented as a quoted string, an array as a comma-separated list of quoted strings surrounded by parentheses, and a dictionary as a list of name/value pairs enclosed between braces. Following is an example of a plain-text property list:

$

cat /System/Library/StartupItems/Samba/StartupPreferences.plist

{
  Description     = "SMB File Service";
  Provides        = ("SMB File Service");
  Requires        = ("Disks", "DirectoryServices");
  OrderPreference = "None";
  Messages =
  {
    start = "Starting SMB File Service";
    stop  = "Stopping SMB File Service";
  };
}

The Description key is associated with a simple string value. The Provides and Requires keys are each associated with an array, although Provides has only one element in its array. The Messages key is associated with a dictionary that contains two name/value pairs.

The plutil utility does not generate plain-text property lists.

XML Property List Files

Many property list files are stored in XML (page 962) format. This format, which is the most commonly used under OS X, is human readable, can be edited by hand, and allows easy and reliable syntax checking.

XML uses tags to identify elements in a file. XML tags start with an opening angle bracket ( < ) and end with a closing angle bracket ( > ). Opening tags comprise a word surrounded by angle brackets (such as <key> ). Closing tags generally comprise the same word, preceded with a slash ( / ) and surrounded by angle brackets (such as </key> ).

The next example uses plutil to convert the plain-text property list shown in the preceding example to XML format and cat to display the converted file:

$

plutil -convert xml1 StartupParameters.plist

$

cat StartupParameters.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
           <key>Description</key>
           <string>SMB File Service</string>
           <key>Messages</key>
           <dict>
                   <key>start</key>
                   <string>Starting SMB File Service</string>
                   <key>stop</key>
                   <string>Stopping SMB File Service</string>
           </dict>
           <key>OrderPreference</key>
           <string>None</string>
           <key>Provides</key>
           <array>
                   <string>SMB File Service</string>
           </array>
           <key>Requires</key>
           <array>
                   <string>Disks</string>
                   <string>DirectoryServices</string>
           </array>
</dict>
</plist>

The XML format is more verbose, but clearer than the plain-text format. It also supports additional data types, such as integer and Boolean, as shown in the following XML property list fragment:

<key>Display</key>
<integer>0</integer>
<key>DockSwitch</key>
<true/>

Some XML elements do not have opening and closing tags. These elements use a trailing slash to indicate that they have just one tag. The <true/> element in the preceding example demonstrates such a case.

Binary Property List Files

The binary property list file format is the most space efficient, but is not human readable. If you need to edit a binary property list file, you must convert it to XML, edit the XML, and then convert it back to binary, as in the following example:

$

plutil -convert xml1 -o copy.plist original.plist

$

vim copy.plist

[...]
$

plutil -convert binary1 -o original.plist copy.plist

lookupd : Which Service to Look at First

In addition to NetInfo (page 441), Mac OS X supports a number of other ways to search for information about users and hosts. With the advent of NIS and DNS, it was no longer a simple matter of searching a local file for user and system information. Whereas you once looked in /etc/passwd to get user information and looked in /etc/hosts to find system address information, you can now use several methods to find this type of information. The lookupd daemon provides a centralized source for lookups from DNS, NetInfo, text files on the local disk, and directory services. Directory services, in turn , provide a way to access other directory systems, such as LDAP (page 940).

The /etc/lookupd directory holds files that override defaults. For example, if a users file exists in this directory, it changes the way that lookupd obtains user records. Alternatively, lookupd can get configuration information from NetInfo in the corresponding NetInfo directories /config/lookupd or /locations/lookupd . For more information refer to the lookupd man page.

The Superserver

The superserver is a daemon that launches, on demand, other daemons that provide services. Starting service daemons on demand, as opposed to allowing them to run constantly, conserves system resources. The superserver under OS X version 10.4 and later is launchd and under version 10.3 and earlier is xinetd .

The launchd Superserver

Mac OS X 10.4

The launchd daemon, which was introduced in Mac OS X 10.4, replaces several core system daemons from earlier versions, including xinetd, init , and cron . This section focuses on the launchd functionality that replaces xinetd .

The launchd daemon is responsible for the services that have property lists in the /System/Library/LaunchDaemons and /Library/LaunchDaemons directories. Each program launchd controls is called a job . A job is defined by an XML property list (configuration) file and identified by a unique label, denoted by the Label key, in that file. Once it loads (reads) a configuration file, launchd controls the job defined by that file and launches the associated program as needed. The launchd daemon can launch a program at system startup, periodically, or on demand.

The launchd daemon controls only programs it has started; it does not control programs started in other ways. The following property list configuration file, which is associated with the sshd daemon, shows some of the keys used by launchd :

$

cat /System/Library/LaunchDaemons/ssh.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Label</key>
        <string>com.openssh.sshd</string>
        <key>Program</key>
        <string>/usr/libexec/sshd-keygen-wrapper</string>
        <key>ProgramArguments</key>
        <array>
                 <string>/usr/sbin/sshd</string>
                 <string>-i</string>
        </array>
        <key>SessionCreate</key>
        <true/>
         <key>Sockets</key>
         <dict>
                  <key>Listeners</key>
                  <dict>
                         <key>Bonjour</key>
                         <array>
                                <string>ssh</string>
                                <string>sftp-ssh</string>
                         </array>
                         <key>SockServiceName</key>
                         <string>ssh</string>
                  </dict>
          </dict>
          <key>StandardErrorPath</key>
          <string>/dev/null</string>
          <key>inetdCompatibility</key>
          <dict>
                  <key>Wait</key>
                  <false/>
          </dict>
</dict>
</plist>

Only the Label and ProgramArguments keys are required. The Label key identifies the job. You can use the Label key as an argument to launchctl (next) to start, stop, load, or unload a job. Give the command launchctl list to display the Label key of each loaded job.

The ProgramArguments key provides launchd with the pathname of the program to run and the arguments to call it with. The preceding example instructs launchd to execute /usr/sbin/sshd with the i option, which indicates that sshd is being launched by another daemon.

Internet servers are generally run on demand, in response to incoming connections. The Sockets key, if present, indicates that launchd should listen on the specified port and launch the program whenever it detects an incoming connection. In the preceding example, the sshd daemon is run whenever a connection is received on the port associated with the ssh service, as defined in /etc/services . The Bonjour key is used with the Bonjour system for automatic service discovery.

You can use the Mac OS X graphical system administration utilities to start and stop jobs. Typically you do not need to edit the launchd configuration files.

Daemons obtain configuration information from their own configuration files. For example, the sshd daemon uses /etc/sshd_config , a standard UNIX configuration file (page 451).

The jobs specified by the property lists in the /System/Library/LaunchDaemons and /Library/LaunchDaemons directories are loaded when the system boots. The jobs specified by the property lists in /System/Library/LaunchAgents , /Library/LaunchAgents , and ~/Library/LaunchAgents are loaded when a user logs in. These directories are discussed in "Important Standard Directories and Files" on page 444.

launchctl : Controls launchd

The launchd daemon runs all the time. You can change the behavior of launchd while it is running by using launchctl (page 765). The first argument to launchctl is called a subcommand . For example, the list subcommand requests a list of all jobs that launchd controls. When you give a launchctl list command as a non root user, launchctl lists jobs controlled by your private instance of launchd . The following example shows typical output of this command when given by root :

#

launchctl list

com.apple.KernelEventAgent
com.apple.mDNSResponder
com.apple.nibindd
com.apple.periodic-daily
com.apple.periodic-monthly
com.apple.periodic-weekly
com.apple.portmap
com.apple.servermgrd
com.apple.syslogd
com.apple.watchdogtimerd
com.vix.cron
com.apple.ntalkd
org.postfix.master
org.xinetd.xinetd
com.openssh.sshd
com.apple.ls
com.apple.atprintd.i9900
com.apple.cups-lpd
com.apple.fingerd

The load subcommand of launchctl causes launchd to read a job's configuration file(s) and start the job as specified (at system startup [immediately if the system is running], periodically, or on demand). However, if the configuration file specifies a value of <true/> for the Disabled key, launchd does not load the job. The unload subcommand tells launchd to unload the configuration files and not to run the job. You must load an unloaded job if you want to run it.

The stop subcommand of launchctl causes launchd to stop running a (loaded) job but not to unload it. Thereafter, a periodic or demand-driven job may start up again from a stopped state. A start subcommand starts a loaded job that has been stopped but has no effect on a job that is not loaded.

When you modify the configuration file of a loaded job, you must instruct launchd to read the new values from the file. Because a load subcommand has no effect on a loaded job, you must first unload the job and then load it again when you change a configuration file.

Job Requirements

The launchd daemon monitors the programs it starts. If a program terminates quickly, launchd restarts it; if it keeps terminating, however, launchd stops the job until an administrator fixes the problem and restarts the job. Many traditional UNIX daemons detach themselves from their calling process. This behavior causes launchd to believe that the daemon has failed and is prohibited in programs started by launchd .

Because launchd provides resource management and security features in a standardized way, programs run by launchd should not handle their own resource management or security. For instance, a daemon being started by launchd should specify the user and group it will run as using the UserName and GroupName keys, respectively, in its property list file rather than setting them from some other configuration file.

In some cases, such as when a daemon needs to bind to a privileged port (page 414), a daemon may need to initially run with root privileges and subsequently drop these privileges. Such a daemon would be launched once, using the RunAtLoad key, rather than run on demand.

Multiple Instances

There is always at least one launchd daemon running on a Mac OS X system, and there may be more. Non root users can start their own copies of launchd to run jobs and services they submit. If you use launchctl to start a new service and you do not have root privileges, the job will be attached to a new instance of launchd running with your privileges.

The xinetd Superserver

The xinetd daemon, which is used under OS X 10.3 and earlier, is a more secure replacement for the inetd superserver that originally shipped with 4.3BSD. The Internet superserver listens for network connections. When one is made, it launches a specified server daemon and forwards the data from the socket (page 101) to the daemon's standard input. The xinetd superserver performs these tasks and provides additional features to control access.

The version of xinetd distributed with Mac OS X is built with TCP wrappers support, so it uses the /etc/hosts.allow and /etc/hosts.deny files for access control (see the hosts_access man page for more information). Using TCP wrappers can simplify configuration but hides some of the more advanced features of xinetd .

The base configuration for xinetd is stored in the /etc/xinetd.conf file. Additional services are configured through files in /etc/xinetd.d .

The following xinetd configuration file allows telnet connections from the local system and any system with an IP address that starts with 192.168. This configuration file does not rely on TCP wrappers, so it does not depend on the hosts.allow and hosts.deny files.

$

cat /etc/xinetd.d/telnet

service telnet
{
       socket_type     = stream
       wait            = no
       user            = root
       server          = /usr/sbin/in.telnetd
       only_from       = 192.168.0.0/16 127.0.0.1
       disable         = no
}

The socket_type indicates whether the socket uses TCP or UDP. TCP-based protocols establish a connection between the client and the server and are identified by the type stream . UDP-based protocols rely on the transmission of individual datagrams and are identified by the type dgram .

When wait is set to no, xinetd handles multiple, concurrent connections to this service. Setting wait to yes causes xinetd to wait for the server process to complete before handling the next request for that service. In general, UDP services should set wait to yes and TCP services should set wait to no . If you were to set wait to yes for a service such as telnet , only one person would be able to use the service at a time.

The user specifies the user that the server runs as. If the user is a member of multiple groups, you can also specify the group on a separate line using the keyword group . The user directive is ignored if xinetd is not run as root . The server provides the pathname of the server program that xinetd runs for this service.

The only_from specifies which systems xinetd allows to use the service. Use IP addresses only because using hostnames can render the service unavailable if DNS fails. Zeros at the right of an IP address are treated as wildcards; thus 192.168.0.0 allows access from any system in the 192.168 subnet.

The disable line can disable a service without removing the configuration file. For more information see the xinetd man page.

Securing a Server Under Mac OS X 10.4 and Later

When you open a local system to access from other systems you must ensure that you:

• Open the local system only to systems you want to allow to access it.

• Allow each remote system to access only the data you want it to access.

• Allow each remote system to access data only in the manner you want it to (read only, read/write, write only).

You can restrict which remote systems have access to a given service by using the operating system's builtin firewall. Under Mac OS X you can configure the firewall using System Preferences; under Mac OS X Server you need to use Server Admin.

You can also restrict a local server's access to the local system. A server can be run with resource limits to keep it from consuming too much memory or creating files that consume too much disk space, it can be run with the privileges of an ordinary user, and it can be restricted to part of the filesystem. Every limitation you impose on a server makes it more difficult for a potential security flaw in that server to affect the rest of the system.

The launchd daemon provides control over all of these restrictions.

Setting Up Resource Limits

Resource limits can control the amount of memory and CPU time as well as the disk space used by a process. You can set both hard and soft resource limits in a launchd configuration file. Soft limits are enforced, but a program can request that the limits be raised. Soft resource limits cannot be raised above the hard resource limits, however, and hard resource limits cannot be raised at all. For example, the following resource limits from a property list file prevent a daemon from consuming more than five seconds of CPU time. (On a multitasking system, it will likely take more than five seconds of real time before a single process has used five seconds of CPU time.)

<key>HardResourceLimits</key>
<dict>
         <key>CPU</key>
         <integer>5</integer>
         <key>Data</key>
         <integer>33554432</integer>
         <key>ResidentSetSize</key>
         <integer>33554432</integer>
         <key>NumberOfFiles</key>
         <integer>16</integer>
         <key>Stack</key>
         <integer>33554432</integer>
         <key>NumberOfProcesses</key>
         <integer>96</integer>
         <key>FileSize</key>
         <integer>33554432</integer>
</dict>

If you specify any HardResourceLimits , any limits that you do not specify are implicitly set to 0, which will normally prevent a job from running. The NumberOfProcesses limit is not merely the number of processes that are part of a job, but includes all processes owned by the user. An idle graphical console might have 50 processes running. To limit a job's resources without impeding a user's normal tasks, it is best to create a new account with limited privileges that runs the job and does nothing else.

The NumberOfProcesses limit used in the preceding example is high. The default limit under Mac OS X is 100 processes per user, with a systemwide limit of 532 processes in total. You can alter these values using sysctl (page 858). The default limits are much higher (1,000 and 2,048 respectively) under Mac OS X Server.

Setting Up a chroot Jail

On early UNIX systems, the root directory was a fixed point in the filesystem. On modern UNIX variants, including Mac OS X, you can define the root directory on a per-process basis. The chroot utility allows you to run a process with a root directory other than / .

The root directory is the top of the directory hierarchy and has no parents: A process cannot access files above the root directory (because they do not exist). If, for example, you run a program (process) and specify its root directory as /Users/sam/jail , the program would have no concept of any files in /Users/sam or above: jail is the program's root directory and is labeled / (not jail ).

By creating an artificial root directory, frequently called a (chroot) jail, you prevent a program from being able to access and modifypossibly maliciouslyfiles outside the directory hierarchy starting at its root. You must set up a chroot jail properly to increase security: If you do not set up a chroot jail correctly, you can actually make it easier for a malicious user to gain access to a system than if there were no chroot jail.

Using chroot

Creating a chroot jail is simple: Working as root , give the command /usr/sbin/chroot directory . The directory becomes the root directory and the process attempts to run the default shell. Working as root from the /Users/sam directory, the following example attempts to set up a chroot jail in the (existing) /Users/sam/jail directory:

#

/usr/sbin/chroot jail

chroot: /bin/sh: No such file or directory

In this example, chroot sets up the chroot jail, but when it attempts to run the sh shell, it fails. Once the jail is set up, the directory that was named jail takes on the name of the root directory: / and chroot cannot find the file identified by the pathname /bin/sh . The chroot jail is working perfectly but is not very useful.

Getting a chroot jail to work the way you want is more complicated. To have the preceding example run bash in a chroot jail, you need to create a bin directory in jail ( /Users/sam/jail/bin ) and copy /bin/sh to this directory. Because the bash binary (and the copy of bash named sh ) is dynamically linked to shared libraries (page 486), you need to copy these libraries into jail as well. The libraries go in /lib . The following example creates the necessary directories, copies bash , uses otool to display the shared library dependencies of bash , and copies the necessary libraries, and the dyld dynamic linker to load them, into lib :

$

pwd

/Users/sam/jail
$

mkdir -p bin usr/lib

$

cp /bin/sh bin

$

otool -L bin/bash

bin/sh:
        /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.0.0)
$

cp /usr/lib/libncurses.5.4.dylib usr/lib

$

cp /usr/lib/libSystem.B.dylib usr/lib

$

cp /usr/lib/dyld usr/lib

Now that everything is set up, you can try starting the chroot jail again. All of the setup can be done by an ordinary user but you have to run chroot as Superuser:

$

su

Password:
#

/usr/sbin/chroot .

dyld: Library not loaded: /usr/lib/system/libmathCommon.A.dylib
  Referenced from: /usr/lib/libSystem.B.dylib
  Reason: image not found
Trace/BPT trap
#

This attempt is closer, but it turns out that the libSystem dynamic library has additional dependencies. Creating the usr/lib/system subdirectory and copying libmathCommon into it solves the problem:

#

mkdir usr/lib/system

#

cp /usr/lib/system/libmathCommon.A.dylib usr/lib/system

#

chroot .

sh-2.05b#

pwd

/
sh-2.05b#

ls

sh: ls: command not found

This time chroot finds and starts sh , which displays its default prompt ( sh-2.05b# ). The pwd command works because it is a shell builtin (page 138). However, bash cannot find the ls utility (it is not in the chroot jail). You can copy /bin/ls into the jail if you want users in the jail to be able to use ls .

To set up a useful chroot jail, you need to determine which utilities the users of the chroot jail will need. Then you can copy the necessary binaries and their libraries into the jail.

For jobs using launchd 's InetdCompatibility mode, you need the program /usr/libexec/launchproxy in the jail. This program provides an environment similar to that provided by inetd or xinetd .

Because users are looked up dynamically from a database, you do not need any password files or authentication programs in the jail unless the program you are using accesses these files or programs directly.

Tip: Keeping multiple chroot jails

If you plan to deploy multiple chroot jails, it is a good idea to keep a clean copy of the files in bin , usr/lib , and usr/lib/system somewhere other than in one of the active jails.

Running a Service in a chroot Jail

Running a shell inside a jail has limited use. You are more likely to need to run a specific service inside the jail. To do so, you need make sure all the files needed by that service are inside the jail. Once you have set up a functional jail, you can specify the jail as the RootDirectory of the service in the launchd configuration file.

Several servers are set up to take advantage of chroot jails. For example, the FTP server ( ftpd ) can automatically start chroot jails for clients; see the ftpd.conf man page.

Security Considerations

Some services need to be run as root , but they relinquish their root privileges once started (Procmail and tnftpd are examples). If you are running such a service, you do not need to specify a user for it in the launchd configuration file.

It is possible for a process run as root to escape from a chroot jail. For this reason, you should always run a service as another user before starting a program running inside the jail. Also, be careful about which setuid (page 90) binaries you allow inside a jail: A security hole in one of these can compromise the security of the jail. Also, make sure the user cannot access executable files that she uploads.

Running Without root Privileges

Some services can run with restricted privileges, rather than with full root privileges. Services should never be run with root privileges unless it is absolutely necessary. The most common reasons for a server to need root privileges are to run in a chroot jail or to listen on a privileged port (page 414). A service started from launchd does not need root privileges for these functions; because launchd runs with root privileges, it can listen on a privileged port, run the program inside a chroot jail, and still run the program as a non root user. To specify that a program runs with a specific user's privileges, give the user's name in the UserName key. Group privileges can be specified with the GroupName or InitGroups keys.

DHCP

Instead of having network configuration information stored in local files on each system, DHCP (Dynamic Host Configuration Protocol) enables client systems to retrieve network configuration information each time they connect to the network. A DHCP server assigns temporary IP addresses from a pool of addresses to clients as needed.

This technique has several advantages over storing network configuration information in local files:

• DHCP enables a new user to set up an Internet connection without having to work with IP addresses, netmasks , DNS addresses, and other technical details. DHCP also makes it faster for an experienced user to set up a connection.

• DHCP facilitates assignment and management of IP addresses and related network information by centralizing the process on a server. A system administrator can configure new systems, including laptops that connect to the network from different locations, to use DHCP. DHCP then assigns IP addresses only when each system connects to the network. The pool of IP addresses is managed as a group on the DHCP server.

• DHCP enables IP addresses to be used by more than one system, reducing the total number of IP addresses needed. This conservation of addresses is important given that the Internet is quickly running out of IPv4 addresses. Although one IP address can be used by only one system at a time, many end-user systems require addresses only occasionally, when they connect to the Internet. By reusing IP addresses, DHCP lengthens the life of the IPv4 protocol. DHCP applies to IPv4 only, as IPv6 forces systems to configure their IP addresses automatically (called autoconfiguration) when they connect to a network (page 400).

DHCP is particularly useful for administrators who are responsible for a large number of systems because it removes the requirement for individual systems to store unique configuration information. DHCP allows an administrator to set up a master system and deploy new systems with a copy of the master's hard disk. In educational establishments and other open-access facilities, it is common to store the hard disk image on a shared drive and have each workstation automatically restore itself to pristine condition at the end of each day.

You can obtain more information from the DHCP Web site (www.dhcp.org) and from the DHCP FAQ (www.dhcp-handbook.com/dhcp_faq.html).

How DHCP Works

The client system contacts the server daemon ( bootpd on a Macintosh) to obtain the IP address, netmask , broadcast address, nameserver address, and other networking parameters. The server, in turn, provides a lease on the IP address to the client. The client can request specific terms of the lease, including its duration, and the server can limit these terms. While connected to the network, a client typically requests extensions of its lease as necessary so its IP address remains the same. The lease can expire once the client is disconnected from the network, or the server can give the client a new IP address when it requests a new lease. You can also set up a DHCP server to provide static IP addresses for specific clients (refer to "Static Versus Dynamic IP Addresses" on page 394).

DHCP is broadcast based, so the client and server must be on the same subnet (page 397).

DHCP Client

A DHCP client requests network configuration parameters from the DHCP server and uses those parameters to configure the client's network interface. Under Mac OS X, DHCP setup is controlled by a setting in the Network preference pane (Figure 11-1). To enable DHCP, select the interface that you want to use DHCP for from the Network preference pane and click the TCP/IP tab. Using DHCP is the default setting.

Figure 11-1. The Network preference pane

If the local network requires a DHCP client ID (a name used to identify your computer to the server), enter it in the appropriate box. Most networks do not require a client ID.

If you run into configuration problems, try clicking Renew DHCP Lease . Clicking this button restarts the DHCP negotiation.

If no DHCP server is available, the client assigns itself an address in the 169.254.0.0169.254.255.255 block. The system does not assign itself an address when no network cable is plugged in.

DHCP Server

The DHCP server maintains a list of IP addresses and other configuration parameters. When requested , the DHCP server provides configuration parameters to a client. DHCP service is supported under Mac OS X Server only and should be configured using the Server Admin application. The bootpd server can provide DHCP, BOOTP, and NetBoot services, all of which are used to allow network booting of client systems. See the bootpd man page for more information.