This chapter discusses the Dynamic Host Configuration Protocol (DHCP) client DHCPv4, which enables DHCP servers to pass configuration parameters such as IPv4 network addresses to IPv4 nodes. The chapter explains how the client works, and how you can affect the behavior of the client. This chapter contains the following information:About the Solaris DHCP Client Enabling and Disabling a Solaris DHCP Client DHCP Client Administration DHCP Client Systems With Multiple Network Interfaces DHCP Client Host Names DHCP Client Systems and Name Services DHCP Client Event Scripts The Solaris DHCP client is the dhcpagent daemon, which is part of the Solaris Operating System (Solaris OS). When you install the Solaris OS, you are prompted to use DHCP to configure network interfaces. If you specify Yes, the DHCP client software is enabled on your system during Solaris installation. You do not need to do anything else with the Solaris client to use DHCP. The DHCP server's configuration determines what information is given to DHCP client systems that use the DHCP service.If a client system is already running the Solaris OS, but not using DHCP, you can reconfigure the client system to use DHCP. You can also reconfigure a DHCP client system so that it stops using DHCP and uses static network information that you provide. See Enabling and Disabling a Solaris DHCP Client for more information.In the DHCPv4 client, each logical interface is independent and is an administrative unit. In addition to the zeroth logical interface (which defaults to the interface MAC address as an identifier), the user may configure specific logical interfaces to run DHCP by specifying a CLIENT_ID in the dhcpagent configuration file. For example:hme0:1.CLIENT_ID=orangutan The dhcpagent daemon obtains configuration information that is needed by other processes involved in booting the system. For this reason, the system startup scripts start dhcpagent early in the boot process and wait until the network configuration information from the DHCP server arrives.The presence of the file /etc/dhcp.interface (for example, /etc/dhcp.ce0 on a Sun Fire 880 system) indicates to the startup scripts that DHCP is to be used on the specified interface. Upon finding a dhcp.interface file, the startup scripts start dhcpagent.After startup, dhcpagent waits until it receives instructions to configure a network interface. The startup scripts issue the ifconfig interface dhcp start command, which instructs dhcpagent to start DHCP as described in How DHCP Works. If commands are contained within the dhcp.interface file, they are appended to the dhcp start option of ifconfig. See the ifconfig1M man page for more information about options used with the ifconfig interface dhcp command. After the information packet is obtained from a DHCP server, dhcpagent configures the network interface and brings up the interface. The daemon controls the interface for the duration of the lease time for the IP address, and maintains the configuration data in an internal table. The system startup scripts use the dhcpinfo command to extract configuration option values from the internal table. The values are used to configure the system and enable it to communicate on the network.The dhcpagent daemon waits passively until a period of time elapses, usually half the lease time. The daemon then requests an extension of the lease from a DHCP server. If dhcpagent finds that the interface is down or that the IP address has changed, the daemon does not control the interface until instructed by the ifconfig command to do so. If dhcpagent finds that the interface is up and the IP address hasn't changed, the daemon sends a request to the server for a lease renewal. If the lease cannot be renewed, dhcpagent takes down the interface at the end of the lease time.Each time dhcpagent performs an action related to the lease, the daemon looks for an executable file called /etc/dhcp/eventhook. If an executable file with this name is found, dhcpagent invokes the executable. See DHCP Client Event Scripts for more information about using the event executable. When the DHCP client system shuts down normally, dhcpagent writes the current configuration information to the file /etc/dhcp/interface.dhc. The lease is dropped rather than released, so the DHCP server does not know that the IP address is not in active use.If the lease is still valid when the system reboots, dhcpagent sends an abbreviated request to use the same IP address and network configuration information. If the DHCP server permits this request, dhcpagent can use the information that it wrote to disk when the system shut down. If the server does not permit the client to use the information, dhcpagent initiates the DHCP protocol sequence described in How DHCP Works. As a result, the client obtains new network configuration information. To enable the DHCP client on a system that is already running the Solaris OS and is not using DHCP, you must first unconfigure the system. When the system boots, you must issue some commands to set up the system and enable the DHCP client.If your DHCP client is not a Solaris DHCP client, consult the client documentation for instructions.Routers, NIS or NIS+ servers, DNS servers, and other hosts that are critical to the network should not be DHCP clients. Hosts that provide services to the network should not rely on the network to obtain their IP addresses. Hosts that are print servers or file servers should have consistent IP addresses as well. However, print servers and file servers can become DHCP clients to receive their network configurations through DHCP. You can configure the DHCP server to provide consistent IP addresses to such DHCP clients, as described in Assigning a Reserved IP Address to a DHCP Client. This procedure is necessary only if DHCP was not enabled during Solaris installation. Become superuser on the client system. If this system uses preconfiguration instead of interactive configuration, edit the sysidcfg file. Add the dhcp subkey to the network_interface keyword in the sysidcfg file.For example, network_interface=hme0 {dhcp}. See the sysidcfg4 man page for more information. Unconfigure and shut down the system.# sys-unconfigSee the sys-unconfig1M man page for more information about the configuration information that is removed by this command. Reboot the system after shutdown is complete.If the system uses preconfiguration, the dhcp subkey in the sysidcfg file configures the system to use the DHCP client as the system boots.If the system does not use preconfiguration, you are prompted for system configuration information by sysidtool programs when the system reboots. See the sysidtool1M man page for more information. When prompted to use DHCP to configure network interfaces, specify Yes. Become superuser on the client system. If you used a sysidcfg file to preconfigure the system, remove the dhcp subkey from the network_interface keyword. Unconfigure and shut down the system.# sys-unconfigSee the sys-unconfig1M man page for more information about the configuration information that is removed by this command. Reboot the system after shutdown is complete.If the system uses preconfiguration, you are not prompted for configuration information, and the DHCP client is not configured.If the system does not use preconfiguration, you are prompted for system configuration information by sysidtool programs when the system reboots. See the sysidtool1M man page for more information. When prompted to use DHCP to configure network interfaces, specify No. The Solaris DHCP client software does not require administration under normal system operation. The dhcpagent daemon automatically starts when the system boots, renegotiates leases, and stops when the system shuts down. You cannot manually start and stop the dhcpagent daemon directly. However, as superuser on the client system, you can use the ifconfig command to affect dhcpagent's management of the network interface, if necessary.The ifconfig command enables you to do the following:Start the DHCP client – The command ifconfig interface dhcp start initiates the interaction between dhcpagent and the DHCP server to obtain an IP address and a new set of configuration options. This command is useful when you change information that you want a client to use immediately, such as when you add IP addresses or change the subnet mask. Request network configuration information only – The command ifconfig interface dhcp inform causes dhcpagent to issue a request for network configuration parameters, with the exception of the IP address. This command is useful when the network interface has a valid IP address, but the client system needs updated network options. For example, this command is useful if you do not use DHCP to manage IP addresses, but you do use it to configure hosts on the network. Request a lease extension – The command ifconfig interface dhcp extend causes dhcpagent to issue a request to renew the lease. The client does automatically request to renew leases. However, you might want to use this command if you change the lease time and want clients to use the new lease time immediately, rather than waiting for the next attempt at lease renewal. Release the IP address – The command ifconfig interface dhcp release causes dhcpagent to relinquish the IP address used by the network interface. Release of the IP address happens automatically when the lease expires. You might want to issue this command if the lease time is long and you need to take down the network interface for an extended period of time. You should use this command when you remove the system from the network. Drop the IP address – The command ifconfig interface dhcp drop causes dhcpagent to take down the network interface without informing the DHCP server. This command enables the client to use the same IP address when it reboots. Ping the network interface – The command ifconfig interface dhcp ping lets you determine if the interface is under the control of DHCP. View the DHCP configuration status of the network interface – The command ifconfig interface dhcp status displays the current state of the DHCP client. The display indicates the following items:If an IP address has been bound to the client The number of requests sent, received, and declined If this interface is the primary interface Times when the lease was obtained, when it expires, and when renewal attempts are scheduled to begin For example:# ifconfig hme0 dhcp status Interface State Sent Recv Declined Flags hme0 BOUND 1 1 0 [PRIMARY] (Began,Expires,Renew)=(08/16/2005 15:27, 08/18/2005 13:31, 08/17/2005 15:24) The /etc/default/dhcpagent file on the client system contains tunable parameters for the dhcpagent. You can use a text editor to change several parameters that affect client operation. The /etc/default/dhcpagent file is well documented, so for more information, you should refer to the file as well as to the dhcpagent1M man page.The /etc/dhcp.interface file is another location in which parameters affecting the DHCP client are set. Parameters set in this file are used by system startup scripts with the ifconfig command.By default, the DHCP client is configured as follows:The client system uses DHCP on one physical network interface.If you want to use DHCP on more than one physical network interface, see DHCP Client Systems With Multiple Network Interfaces. The client system does not require a particular host name.If you want a client to request a specific host name, see DHCP Client Host Names. The client is not automatically configured as a name service client if the DHCP client was configured after the Solaris installation.See DHCP Client Systems and Name Services for information about using name services with DHCP clients. The client requests only the subnet mask, router IP address, client host name, and encapsulated vendor options.The DHCP client's parameter file can be set up to request more options in the PARAM_REQUEST_LIST keyword in the /etc/default/dhcpagent file. The DHCP server can be configured to provide options that were not specifically requested. See About DHCP Macros and Working With DHCP Macros (Task Map) for information about using DHCP server macros to send information to clients. The DHCP client can simultaneously manage several different interfaces on one system. The interfaces can be physical interfaces or logical interfaces. Each interface has its own IP address and lease time. If more than one network interface is configured for DHCP, the client issues separate requests to configure them. The client maintains a separate set of network configuration parameters for each interface. Although the parameters are stored separately, some of the parameters are global in nature. The global parameters apply to the system as a whole, rather than to a particular network interface.The host name, NIS domain name, and time zone are global parameters and should have the same values for each interface. However, these values may differ due to errors in the information specified by the DHCP administrator. To ensure that there is only one answer to a query for a global parameter, only the parameters for the primary network interface are requested. You can insert the word primary in the /etc/dhcp.interface file for the interface that you want to be treated as the primary interface. If the primary keyword is not used, the first interface in alphabetical order is considered to be the primary interface.The DHCP client manages leases for logical interfaces and physical interfaces identically, except for the following limitations on logical interfaces:The DHCP client does not manage the default routes that are associated with logical interfaces.The Solaris kernel associates routes with physical interfaces, not logical interfaces. When a physical interface's IP address is established, the necessary default routes should be placed in the routing table. If DHCP is used subsequently to configure a logical interface associated with that physical interface, the necessary routes should already be in place. The logical interface uses the same routes.When a lease expires on a physical interface, the DHCP client removes the default routes that are associated with the interface. When a lease expires on a logical interface, the DHCP client does not remove the default routes associated with the logical interface. The associated physical interface and possibly other logical interfaces might need to use the same routes.If you need to add or remove default routes that are associated with a DHCP-controlled interface, you can use the DHCP client event script mechanism. See DHCP Client Event Scripts. The DHCP client does not automatically generate client identifiers for logical interfaces.The client identifier is used to uniquely identify a DHCP client so that it can receive configuration information that is specifically targeted to that client. For physical interfaces, the DHCP client identifier is derived from the media access control (MAC) address of the system's network interface hardware. However, no Internet standard exists for the format of DHCP client identifiers for physical interfaces that have multiple leases. You must create your own client identifier for any logical interface that you want to be configured through DHCP. The client identifier must be specified in the /etc/default/dhcpagent file with the interface.CLIENT_ID keyword. For example, to specify the client identifier orangutan-ce0–1 for the logical interface ce0:1, you would use the following entry:ce0:1.CLIENT_ID=orangutan-ce0-1See the /etc/default/dhcpagent file and the dhcpagent1M man page for more information about the parameters you can set in the file.If you do not configure a client identifier, ifconfig fails when it tries to configure the logical interface to use DHCP. The error message is:ifconfig: ce0:1: interface does not have a configured DHCP client id By default, the Solaris DHCP client does not supply its own host name, because the client expects the DHCP server to supply the host name. The Solaris DHCP server is configured to supply host names to DHCP clients by default. When you use the Solaris DHCP client and server together, these defaults work well. However, when you use the Solaris DHCP client with some third-party DHCP servers, the client might not receive a host name from the server. If the Solaris DHCP client does not receive a host name through DHCP, the client system looks at the /etc/nodename file for a name to use as the host name. If the file is empty, the host name is set to unknown.If the DHCP server supplies a name in the DHCP Hostname option, the client uses that host name, even if a different value is placed in the /etc/nodename file. If you want the client to use a specific host name, you can enable the client to request that name. See the following procedure.On the client system, edit the /etc/default/dhcpagent file as superuser. Find the REQUEST_HOSTNAME keyword in the /etc/default/dhcpagent file and modify the keyword as follows:REQUEST_HOSTNAME=yesIf a comment sign (#) is in front of REQUEST_HOSTNAME, remove the #. If the REQUEST_HOSTNAME keyword is not present, insert the keyword. Edit the /etc/hostname.interface file on the client system to add the following line:inet hostnamehostname is the name that you want the client to use. Type the following commands to have the client perform a full DHCP negotiation upon rebooting:# pkill dhcpagent # rm /etc/dhcp/interface.dhc # rebootThe DHCP data that is cached on the client is removed. The client restarts the protocol to request new configuration information, including a new host name. The DHCP server first makes sure that the host name is not in use by another system on the network. The server then assigns the host name to the client. If configured to do so, the DHCP server can update name services with the client's host name.If you want to change the host name later, repeat Step 3 and Step 4. Solaris systems support the following name services: DNS, NIS, NIS+, and a local file store (/etc/inet/hosts). Each name service requires some configuration before it is usable. The name service switch configuration file (see nsswitch.conf4) must also be set up appropriately to indicate the name services to be used.Before a DHCP client system can use a name service, you must configure the system as a client of the name service.The following table summarizes issues that are related to each name service and DHCP. The table includes links to documentation that can help you set up clients for each name service.Name Service Client Setup Information NIS If you are using Solaris DHCP to send Solaris network install information to a client system, you can use a configuration macro that contains the NISservs and NISdmain options. These options pass the IP addresses of NIS servers and the NIS domain name to the client. The client then automatically becomes an NIS client.If a DHCP client system is already running the Solaris OS, the NIS client is not automatically configured on that system when the DHCP server sends NIS information to the client.If the DHCP server is configured to send NIS information to the DHCP client system, you can see the values given to the client if you use the dhcpinfo command on the client as follows:# /sbin/dhcpinfo NISdmain# /sbin/dhcpinfo NISservsUse the values returned for the NIS domain name and NIS servers when you set up the system as an NIS client.You set up an NIS client for a Solaris DHCP client system in the standard way, as documented in Chapter 5, Setting Up and Configuring NIS Service, in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). You can write a script that uses dhcpinfo and ypinit to automate NIS client configuration on DHCP client systems. NIS+ If the DHCP client system receives a nonreserved IP address, the address might not always be the same. You must set up the NIS+ client for a DHCP client system in a nonstandard way, which is documented in Setting Up DHCP Clients as NIS+ Clients. This procedure is necessary because NIS+ uses security measures to authenticate requests for service. The security measures depend upon the IP address.If the DHCP client system has been manually assigned an IP address, the client's address is always the same. You can set up the NIS+ client in the standard way, which is documented in Setting Up NIS+ Client Machines in System Administration Guide: Naming and Directory Services (NIS+). /etc/inet/hosts You must set up the /etc/inet/hosts file for a DHCP client system that is to use /etc/inet/hosts for its name service.The DHCP client system's host name is added to its own /etc/inet/hosts file by the DHCP tools. However, you must manually add the host name to the /etc/inet/hosts files of other systems in the network. If the DHCP server system uses /etc/inet/hosts for name resolution, you must also manually add the client's host name on the system. DNS If the DHCP client system receives the DNS domain name through DHCP, the client system's /etc/resolv.conf file is configured automatically. The /etc/nsswitch.conf file is also automatically updated to append dns to the hosts line after any other name services in the search order. See System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)for more information about DNS. You can use the NIS+ name service on Solaris systems that are DHCP clients. However, to do so requires you to partially circumvent one of the security-enhancing features of NIS+, the creation of Data Encryption Standard (DES) credentials. When you set up an NIS+ client that is not using DHCP, you add unique DES credentials for the client to the NIS+ server. There are several ways to create credentials, such as using the nisclient script or the nisaddcred command.For DHCP clients, you cannot use these methods. NIS+ credential generation requires a client to have a static host name to create and store the credentials. If you want to use NIS+ and DHCP, you must create identical credentials to be used for all the host names of DHCP clients. In this way, no matter what IP address and associated host name that a DHCP client receives, the client can use the same DES credentials.Before performing the following procedure, be aware that NIS+ was designed for increased security. This procedure weakens that security by allowing random DHCP clients to receive NIS+ credentials. The following procedure shows you how to create identical credentials for all DHCP host names. This procedure is valid only if you know the host names that DHCP clients use. For example, when the DHCP server generates the host names, you know the possible host names that a client can receive.A DHCP client system that is to be an NIS+ client must use credentials that belong to another NIS+ client system in the NIS+ domain. This procedure only produces credentials for the system, which apply only to the superuser logged in to the system. Other users who log in to the DHCP client system must have their own unique credentials in the NIS+ server. These credentials are created according to a procedure in the System Administration Guide: Naming and Directory Services (NIS+). Create the credentials for a client by typing the following command on the NIS+ server:# nisgrep nisplus-client-name cred.org_dir > /tmp/fileThis command writes the cred.org_dir table entry for the NIS+ client to a temporary file. Use the cat command to view the contents of the temporary file.Or, use a text editor. Copy the credentials to use for DHCP clients.You must copy the public key and private key, which are long strings of numbers and letters separated by colons. The credentials are to be pasted into the command issued in the next step. Add credentials for a DHCP client by typing the following command:# nistbladm -a cname=" dhcp-client-name@nisplus-domain" auth_type=DES \ auth_name="unix.dhcp-client-name@nisplus-domain" \ public_data=copied-public-key \ private_data=copied-private-keyFor the copied-public-key, paste the public key information that you copied from the temporary file. For the copied-private-key, paste the private key information that you copied from the temporary file. Remote copy files from the NIS+ client system to the DHCP client system by typing the following commands on the DHCP client system:# rcp nisplus-client-name:/var/nis/NIS_COLD_START /var/nis # rcp nisplus-client-name:/etc/.rootkey /etc # rcp nisplus-client-name:/etc/defaultdomain /etcIf you get a “permission denied” message, the systems might not be set up to allow remote copying. In this case, you can copy the files as a regular user to an intermediate location. As superuser, copy the files from the intermediate location to the proper location on the DHCP client system. Copy the correct name service switch file for NIS+ by typing the following command on the DHCP client system:# cp /etc/nsswitch.nisplus /etc/nsswitch.conf Reboot the DHCP client system.The DHCP client system should now be able to use NIS+ services. The following example assumes that you have one system nisei, which is an NIS+ client in the NIS+ domain dev.example.net. You also have one DHCP client system, dhow, and you want dhow to be an NIS+ client.(First log in as superuser on the NIS+ server) # nisgrep nisei cred.org_dir > /tmp/nisei-cred # cat /tmp/nisei-cred nisei.dev.example.net.:DES:unix.nisei@dev.example.net:46199279911a84045b8e0 c76822179138173a20edbd8eab4:90f2e2bb6ffe7e3547346dda624ec4c7f0fe1d5f37e21cff63830 c05bc1c724b # nistbladm -a cname="dhow@dev.example.net." \ auth_type=DES auth_name="unix.dhow@dev.example.net" \ public_data=46199279911a84045b8e0c76822179138173a20edbd8eab4 \ private_data=90f2e2bb6ffe7e3547346dda624ec4c7f0fe1d5f37e21cff63830\ c05bc1c724b # rlogin dhow (Log in as superuser on dhow) # rcp nisei:/var/nis/NIS_COLD_START /var/nis # rcp nisei:/etc/.rootkey /etc # rcp nisei:/etc/defaultdomain /etc # cp /etc/nsswitch.nisplus /etc/nsswitch.conf # rebootThe DHCP client system dhow should now be able to use NIS+ services. If you want to set up a large number of DHCP client systems as NIS+ clients, you can write a script. A script can quickly add the entries to the cred.org_dir NIS+ table. The following example shows a sample script.#! /usr/bin/ksh # # Copyright (c) by Sun Microsystems, Inc. All rights reserved. # # Sample script for cloning a credential. Hosts file is already populated # with entries of the form dhcp-[0-9][0-9][0-9]. The entry we're cloning # is dhcp-001. # # PUBLIC_DATA=6e72878d8dc095a8b5aea951733d6ea91b4ec59e136bd3b3 PRIVATE_DATA=3a86729b685e2b2320cd7e26d4f1519ee070a60620a93e48a8682c5031058df4 HOST="dhcp-" DOMAIN="mydomain.example.com" for i in 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 do print - ${HOST}${i} #nistbladm -r [cname="${HOST}${i}.${DOMAIN}."]cred.org_dir nistbladm -a cname="${HOST}${i}.${DOMAIN}." \ auth_type=DES auth_name="unix.${HOST}${i}@${DOMAIN}" \ public_data=${PUBLIC_DATA} private_data=${PRIVATE_DTA} cred.org_Dir done exit 0 You can set up the Solaris DHCP client to run an executable program or script that can perform any action that is appropriate for the client system. The program or script, which is called an event script, is automatically executed after certain DHCP lease events occur. The event script can be used to run other commands, programs, or scripts in response to specific lease events. You must provide your own event script to use this feature.The following event keywords are used by dhcpagent to signify DHCP lease events:Event KeywordDescription BOUNDThe interface is configured for DHCP. The client receives the acknowledgement message (ACK) from the DHCP server, which grants the lease request for an IP address. The event script is invoked immediately after the interface is configured successfully. EXTENDThe client successfully extends a lease. The event script is invoked immediately after the client receives the acknowledgement message from the DHCP server for the renew request. EXPIREThe lease expires when the lease time is up. The event script is invoked immediately before the leased address is removed from the interface and the interface is marked as down. DROPThe client drops the lease to remove the interface from DHCP control. The event script is invoked immediately before the interface is removed from DHCP control. RELEASEThe client relinquishes the IP address. The event script is invoked immediately before the client releases the address on the interface and sends the RELEASE packet to the DHCP server. With each of these events, dhcpagent invokes the following command:/etc/dhcp/eventhook interface eventwhere interface is the interface that is using DHCP and event is one of the event keywords described previously. For example, when the ce0 interface is first configured for DHCP, the dhcpagent invokes the event script as follows:/etc/dhcp/eventhook ce0 BOUNDTo use the event script feature, you must do the following:Name the executable file /etc/dhcp/eventhook. Set the owner of the file to be root. Set permissions to 755 (rwxr-xr-x). Write the script or program to perform a sequence of actions in response to any of the documented events. Because Sun might add new events, the program must silently ignore any events that are not recognized or do not require action. For example, the program or script might write to a log file when the event is RELEASE, and ignore all other events. Make the script or program noninteractive. Before the event script is invoked, stdin, stdout, and stderr are connected to /dev/null. To see the output or errors, you must redirect to a file. Enable the script or program to be run with the following command:/etc/dhcp/eventhook interface event The event script inherits its program environment from dhcpagent, and runs with root privileges. The script can use the dhcpinfo utility to obtain more information about the interface, if necessary. See the dhcpinfo1 man page for more information.The dhcpagent daemon waits for the event script to exit on all events. If the event script does not exit after 55 seconds, dhcpagent sends a SIGTERM signal to the script process. If the process still does not exit after three additional seconds, the daemon sends a SIGKILL signal to kill the process.The dhcpagent1M man page includes one example of an event script.Example 16–3 shows how to use a DHCP event script to keep the content of the /etc/resolv.conf file up to date. When the BOUND and EXTEND events occur, the script replaces the names of the domain server and name server. When the EXPIRE, DROP and RELEASE events occur, the script removes the names of the domain server and name server from the file.The example script assumes that DHCP is the authoritative source for the names of the domain server and the name server. The script also assumes that all interfaces under DHCP control return consistent and current information. These assumptions might not reflect conditions on your system. #!/bin/ksh -p PATH=/bin:/sbin export PATH umask 0222 # Refresh the domain and name servers on /etc/resolv.conf insert () { dnsservers=`dhcpinfo -i $1 DNSserv` if [ -n "$dnsservers" ]; then # remove the old domain and name servers if [ -f /etc/resolv.conf ]; then rm -f /tmp/resolv.conf.$$ sed -e '/^domain/d' -e '/^nameserver/d' \ /etc/resolv.conf > /tmp/resolv.conf.$$ fi # add the new domain dnsdomain=`dhcpinfo -i $1 DNSdmain` if [ -n "$dnsdomain" ]; then echo "domain $dnsdomain" >> /tmp/resolv.conf.$$ fi # add new name servers for name in $dnsservers; do echo nameserver $name >> /tmp/resolv.conf.$$ done mv -f /tmp/resolv.conf.$$ /etc/resolv.conf fi } # Remove the domain and name servers from /etc/resolv.conf remove () { if [ -f /etc/resolv.conf ]; then rm -f /tmp/resolv.conf.$$ sed -e '/^domain/d' -e '/^nameserver/d' \ /etc/resolv.conf > /tmp/resolv.conf.$$ mv -f /tmp/resolv.conf.$$ /etc/resolv.conf fi } case $2 in BOUND | EXTEND) insert $1 exit 0 ;; EXPIRE | DROP | RELEASE) remove exit 0 ;; *) exit 0 ;; esac