devscripts.conf

package: devscripts

title: devscripts.conf(5)

text:
# devscripts.conf(5)

## NAME
devscripts.conf - configuration file for the devscripts package

## DESCRIPTION
The devscripts package provides a collection of scripts which may be of use to Debian developers and others wishing to build Debian packages. Many of these have options which can be configured on a system-wide and per-user basis.

Every script in the devscripts package which makes use of values from these configuration files describes the specific settings recognised in its own manpage. (For a list of the scripts, either see /usr/share/doc/devscripts/README.gz or look at the output of dpkg -L devscripts | grep /usr/bin.)

The two configuration files are /etc/devscripts.conf for system-wide defaults and ~/.devscripts for per-user settings. They are written with bash(1) syntax, but should only have comments and simple variable assignments in them; they are both sourced (if present) by many of the devscripts scripts. Variables corresponding to simple switches should have one of the values yes and no; any other setting is regarded as equivalent to the default setting.

All variable names are written in uppercase, and begin with the script name. Package-wide variables begin with "DEVSCRIPTS", and are listed below, as well as in the relevant manpages.

For a list of all of the available options variables, along with their default settings, see the example configuration file /usr/share/doc/devscripts/devscripts.conf.ex. This is copied to /etc/devscripts.conf when the devscripts package is first installed. Information about configuration options introduced in newer versions of the package will be appended to /etc/devscripts.conf when the package is upgraded.

Every script which reads the configuration files can be forced to ignore them by using --no-conf as the first command-line option.

## PACKAGE-WIDE VARIABLES
The currently recognised package-wide variables are:

DEVSCRIPTS_CHECK_DIRNAME_LEVEL, DEVSCRIPTS_CHECK_DIRNAME_REGEX

These variables control scripts which change directory to find a debian/changelog file or suchlike, and some other miscellaneous cases. In order to prevent unwanted, even possibly dangerous, behaviour, these variables control when actions will be performed. The scripts which currently make use of these variables are: debc, debchange/dch, debclean, debi, debrelease, debuild and uscan, but this list may change with time (and I may not remember to update this manpage). Please see the manpages of individual scripts for details of the specific behaviour for each script.

## SEE ALSO
devscripts(1) and /usr/share/doc/devscripts/README.gz.

## AUTHOR
This manpage was written for the devscripts package by the package maintainer Julian Gilbey <jdg@debian.org>.


dgenrc

package: dgen-sdl

title: dgenrc(5)

summary: file containing settings for

text:
# dgenrc(5)

## NAME
dgenrc — file containing settings for dgen(1)

## SYNOPSIS
$HOME/.dgen/dgenrc

## DESCRIPTION
The file $HOME/.dgen/dgenrc is parsed by dgen(1) when the emuator is started. It is used to set controller keys, as well as other characteristics of the emulation. The contents of this file may be overriden with the contents of another similarly-formatted file, via the -r commandline switch.

## FILE FORMAT
Each rc file consists of an unlimited number of lines, which each have the format 'fieldname = value'. A line may also be a comment, if it begins with the hash mark (#) character.

Each fieldname is prepended by a name, which identifies the type of this field:

key_*

A key value. May be set to a key identifier listed in the KEY IDENTIFIERS section below.

joy_*

A joystick/joypad value. May be set to a joystick identifier listed in the JOYSTICK IDENTIFIERS section below.

mou_*

A mouse action. May be set to a mouse identifier listed in the MOUSE IDENTIFIERS section below.

bool_*

A boolean value. "false", "no", and "0" values are taken as false, while "true", "yes", and any number except 0 are taken as true.

int_*

An integer value, greater than or equal to 0.

str_*

A string value, can be empty.

Some fields take special value sets, which are addressed in their respective sections. None of the field names or values are case-sensitive.

The fields fall under a few basic groups. They are listed below, with their default values in brackets ([]):

All of them can be modified interactively from the prompt, as described in dgen(1).

## CONTROLLERS
key_pad1_up [up]

key_pad1_down [down]

key_pad1_left [left]

key_pad1_right [right]

key_pad1_a [a]

key_pad1_b [s]

key_pad1_c [d]

key_pad1_x [q]

key_pad1_y [w]

key_pad1_z [e]

key_pad1_mode [backspace]

key_pad1_start [return]

Map keys to the first Genesis controller. Each of these fields has a corresponding "key_pad2" field, to map to the second controller.

joy_pad1_up [joystick0-axis1-min]

joy_pad1_down [joystick0-axis1-max]

joy_pad1_left [joystick0-axis0-min]

joy_pad1_right [joystick0-axis0-max]

joy_pad1_a [joystick0-button0]

joy_pad1_b [joystick0-button3]

joy_pad1_c [joystick0-button1]

joy_pad1_x [joystick0-button6]

joy_pad1_y [joystick0-button4]

joy_pad1_z [joystick0-button5]

joy_pad1_mode [joystick0-button9]

joy_pad1_start [joystick0-button8]

Map joystick/joypad buttons to the first Genesis controller. Each of these fields has a corresponding "joy_pad2" field, to map to the second controller.

bool_joystick [true]

Use joysticks to emulate the controllers. Note that the keyboard keys will still work if this value is set. This field is only available if you have joystick support enabled.

int_mouse_delay [50]

Number of milliseconds to wait after the last mouse motion event to release buttons bound to such events.

## USER-DEFINED BINDINGS
bind_{keysym} action

bind_{joypad} action

bind_{mouse} action

Defines a new keyboard, joystick/joypad or mouse binding to an arbitrary action. These variables use the keysym format as defined in KEY IDENTIFIERS, the joypad format as defined in JOYSTICK IDENTIFIERS, or the mouse format as defined in MOUSE IDENTIFIERS. When action is prefixed with "key_", "joy_" or "mou_", it becomes an alias to the corresponding variable in CONTROLLERS. Otherwise, it is interpreted as if entered at the prompt, and can be used to modify variables or execute commands (see dgenrc(5) for more information). No bindings are defined by default.

bind_"{keysym|joypad|mouse} [{keysym|joypad|mouse} [...]]" action

Alternate syntax that supports combining several identifiers to perform action. Controller types can be mixed. Identifiers are separated by spaces. To avoid syntax errors, spaces must be properly escaped or quoted.

## AUDIO
bool_sound [true]

Enable the sound subsystem.

int_soundrate [44100]

Sound frequency to play at, in hertz (Hz).

int_soundsegs [8]

Number of sound segments to use for sound buffering. Lower values guarantee low latency. Increment this only if the sound becomes choppy.

int_soundsamples [0]

Size of the system sound buffer, in samples (samples are the sound unit, sound rate is how many of them are played every second). Specifying 0 automatically choses the safest value. If you experience sound issues int_soundsegs is unable to solve, try to change this. Increasing it will cause noticeable audio lag (it is unfortunately often required on slower machines).

int_volume [100]

Volume level, in percent. Values above 100 cause distorsion.

key_volume_inc [=]

key_volume_dec [-]

joy_volume_inc []

joy_volume_dec []

mou_volume_inc []

mou_volume_dec []

Bindings for volume control.

bool_mjazz [false]

MJazz option - puts 2 more FM chips in the Megadrive for a sort of 22 channel sound boost. Can sound good. Slows things down a lot.

## VIDEO
int_depth [0]

Color depth (bits per pixel). Allowed values are 0 (automatic), 8, 15, 16, 24 and 32. Ignored in OpenGL mode.

int_width [-1]

int_height [-1]

Desired window width and height.

bool_opengl [true]

Use the OpenGL renderer, if it is available.

bool_opengl_stretch [true]

Let OpenGL stretch the screen.

bool_opengl_linear [true]

Use GL_LINEAR for textures filtering instead of GL_NEAREST.

bool_opengl_32bit [true]

Use 32 bit textures. They require more memory but are usually faster than 16 bit textures.

bool_opengl_square [false]

Use square textures. Wastes a lot of memory but may solve OpenGL initialization failures.

bool_fullscreen [false]

Try to run fullscreen, if possible.

int_scale [-1]

int_scale_x [-1]

int_scale_y [-1]

Amount by which to scale the rendered screen from the default resolution. See scaling filters.

bool_aspect [true]

Retain original aspect ratio when resizing window.

key_fullscreen_toggle [alt-enter]

joy_fullscreen_toggle []

mou_fullscreen_toggle []

Button to toggle fullscreen mode (this may do nothing if SDL doesn't support fullscreen toggling on your platform.)

int_info_height [-1]

Height of the text area at the bottom of the screen, in pixels. This also affects the font size. Values smaller than the minimum font size make DGen redirect text to stdout instead. The default value of -1 makes DGen choose the proper height.

bool_fps [false]

Display the current number of frames per second.

bool_buttons [false]

Display pressed buttons. Can be used to help configuring them.

bool_swab [false]

Swap bytes in the video output. Sometimes useful when video output is located on a different system. This is implemented as a CTV filter which must be compiled-in to work.

bool_doublebuffer [true]

Toggle double buffering. Enabling this should prevent screen tearing from happening. Disabling this may improve the number of displayed frames per second on some systems.

bool_screen_thread [false]

When enabled, a separate thread is created to offload the displaying of frames. This is only useful on slower machines where flipping video buffers takes time, especially when V-sync is enabled and doing so blocks until the next frame without consuming CPU time (sometimes the case when bool_doublebuffer is enabled). This currently has no effect when OpenGL is enabled and only works if multi-threading support is compiled-in.

## SAVE STATES
key_slot_X [X]

joy_slot_X []

mou_slot_X []

Sets the current save-state slot to number X.

key_slot_next [f8]

joy_slot_next []

mou_slot_next []

Switch to the next save-slot.

key_slot_prev [f7]

joy_slot_prev []

mou_slot_prev []

Switch to the previous save-slot.

key_save [f2]

joy_save []

mou_save []

Saves state to the current slot.

key_load [f3]

joy_load []

mou_load []

Loads state from the current slot.

## MISCELLANEOUS KEYS
key_fix_checksum [f1]

joy_fix_checksum []

mou_fix_checksum []

Fixes the checksum value. Some older games will freeze with a red screen if the ROM has been hacked or modified with Game Genie codes. If it does, pressing this, and resetting should fix the problem.

key_quit [escape]

joy_quit []

mou_quit []

Exit DGen or switch to the next ROM on the command-line.

key_craptv_toggle [f5]

joy_craptv_toggle []

mou_craptv_toggle []

Toggles Crap-TV image filters. These filters aren't available in 8 bpp mode.

key_scaling_toggle [f6]

joy_scaling_toggle []

mou_scaling_toggle []

Toggles scaling algorithms. See scaling_startup below.

key_reset [tab]

joy_reset []

mou_reset []

Restart the Genesis emulation.

key_cpu_toggle [f11]

joy_cpu_toggle []

mou_cpu_toggle []

Switch CPU emulators. The x86 assembly CPU emulator StarScream is fast, but has glitches which affect a few games. Switching to the slower Musashi core will fix these problems, at a speed penalty.

key_z80_toggle [f10]

joy_z80_toggle []

mou_z80_toggle []

Switch Z80 emulators. MZ80 is a bit faster than CZ80, particularly in its assembly version (only available for x86), but CZ80 works with more games. This key can also disable Z80 emulation.

key_stop [z]

joy_stop []

mou_stop []

Pause emulation, so you can concentrate on real life for a few seconds. :)

key_game_genie [f9]

joy_game_genie []

mou_game_genie []

Enter a Game Genie or Hex code. This key also works in stopped mode.

key_screenshot [f12]

joy_screenshot []

mou_screenshot []

Take a screenshot. Not available in 8 bpp mode.

key_prompt [:]

joy_prompt []

mou_prompt []

Pause emulation and display interactive prompt. Also works in stopped mode.

key_debug_enter [`]

joy_debug_enter []

mou_debug_enter []

Break into the debugger. Only meaningful if debugger support is compiled-in.

## PREFERENCES
int_hz [60]

Video refresh rate. The default is 60 as in NTSC consoles.

bool_pal [false]

When true, a PAL console is emulated. This should be used in combination with int_hz above for 50Hz emulation.

region [' ']

U for America (NTSC), E for Europe (PAL), J for Japan (NTSC), X for Japan (PAL), or empty space for autodetection (the default). Overrides bool_pal and int_hz.

str_region_order [JUEX]

Regions DGen is allowed to emulate when autodetection is enabled, ordered by preference.

emu_m68k_startup [musa]

Useful when both Musashi and StarScream are compiled-in. This option selects the default emulator to use ("musa" for Musashi, "star" for StarScream, "none" for neither). See key_cpu_toggle.

emu_z80_startup [cz80]

Useful when both CZ80 and MZ80 are compiled-in. This option selects the default emulator to use ("cz80", "mz80" or "none", if you want to disable it altogether). See key_z80_toggle.

bool_autoload [false]

Automatically load the saved state from slot 0 when DGen starts.

bool_autosave [false]

Automatically save the saved state to slot 0 upon exit. Setting both of these fields true, you can exit DGen, and automatically start a game where you left off when you start it again.

bool_autoconf [true]

Automatically dump the current configuration to dgenrc.auto before exiting. This file is always loaded before dgenrc at startup.

bool_frameskip [true]

Automatically skip frames, when it is necessary to maintain proper emulation speed. You may want to disable sound or set int_nice to a nonzero value when setting this to false.

int_nice [0]

If set to a non-zero value, DGen will call usleep(3) with the specified parameter after rendering each frame. This will slow the program down (if it is running too fast on your computer), and allow the operating system to reclaim some CPU time.

ctv_craptv_startup [off]

CTV filter to use by default. Available filters are "blur", "scanline", "interlace" and "swab".

scaling_startup [stretch]

Scaler to use when display resolution is larger than original screen. Available filters are "stretch", "scale", "hqx", "hqx stretch", "scale2x", "scale2x stretch" and "none".

bool_show_carthead [false]

Show cartridge header info at startup.

bool_raw_screenshots [false]

Generate unfiltered screenshots.

str_rom_path ["roms"]

Directory where DGen should look for ROMs by default. It's relative to DGen's home directory, unless an absolute path is provided.

## DEBUGGING
bool_vdp_hide_plane_a [false]

bool_vdp_hide_plane_b [false]

bool_vdp_hide_plane_w [false]

bool_vdp_hide_sprites [false]

Hide various planes during frame rendering. Require VDP debugging to be compiled-in.

bool_vdp_sprites_boxing [false]

int_vdp_sprites_boxing_fg [0xffff00] (yellow)

int_vdp_sprites_boxing_bg [0x00ff00] (green)

Toggle sprites boxing and configure its colors. Require VDP debugging to be compiled-in. "fg" is for sprites with the high priority bit set, "bg" is for the others. Color format is 0xRRGGBB.

## EXAMPLES
See the file "sample.dgenrc" in the DGen/SDL distribution.

## KEY IDENTIFIERS
A key identifier can have the prefixes "shift-", "ctrl-", "alt-" and "meta-", or any combination thereof, to require that the specified modifier be pressed in combination with the key. For example, the identifier "alt-enter" would correspond to holding down the Alt key while pressing Enter.

The "shift-" modifier only works with keys that don't generate symbols (such as arrow keys). Otherwise their UTF-8 representation must be used directly.

The numbers "0" through "9" ("kp_0" through "kp_9" for the numeric keypad), letters "A" through "Z", and function keys "F1" through "F12" map to their key equivalents. In addition, the following identifiers map to their similarly-labeled key counterparts. Identifiers on the same line map to the same key:

```
escape
backspace
tab
capslock	caps_lock
lshift		shift_l
rshift		shift_r
lctrl		ctrl_l
lmeta		meta_l
lalt		alt_l
ralt		alt_r
rmeta		meta_r
rctrl		ctrl_r
return		enter
space

scrollock	scroll_lock
numlock		num_lock

insert
home
page_up		pageup
delete
end
page_down	pagedown
left
right
up
down

kp_home
kp_up
kp_pageup	kp_page_up
kp_left
kp_right
kp_end
kp_down
kp_pagedown	kp_page_down
kp_insert
kp_delete	kp_period

kp_enter
kp_divide
kp_minus
kp_multiply
kp_plus
```

## JOYSTICK IDENTIFIERS
Like key identifiers, joystick (or joypad) identifiers describe a joystick event. Each detected joystick is numbered starting from 0. Three different event types are supported.

Buttons: joystickX-buttonY

For joystick/joypad number X, button number Y. "button" can be abbreviated as "b".

Axes: joystickX-axisY-min, joystickX-axisY-max

For joystick/joypad number X, axis number Y, and its position, which is either "min" (also "n", "negative") or "max" (also "p", "positive"). "axis" can be abbreviated as "a".

Hats: joystickX-hatY-{direction}

For joystick/joypad number X, hat number Y and direction. "hat" can be abbreviated as "h". Possible directions are "up", "right", "down", "left".

## MOUSE IDENTIFIERS
These identifiers describe a mouse event. Each detected mouse is numbered starting from 0. Two different event types are supported.

Buttons: mouseX-buttonY

For mouse number X, button number Y. "button" can be abbreviated as "b".

Motions: mouseX-{direction}

For mouse number X and direction. Possible directions are "up", "right", "down", "left".

## SEE ALSO
dgen(1)

## AUTHORS
This manual page was written by Joe Groff ⟨joe@pknet.com⟩.

Updated by zamaz ⟨zamaz@users.sourceforge.net⟩.


dhclient.conf

package: dhcp-client

title: dhclient.conf(5)

text:
# dhclient.conf(5)

## NAME
dhclient.conf - DHCP client configuration file

## DESCRIPTION
The dhclient.conf file contains configuration information for dhclient, the Internet Systems Consortium DHCP Client.

The dhclient.conf file is a free-form ASCII text file. It is parsed by the recursive-descent parser built into dhclient. The file may contain extra tabs and newlines for formatting purposes. Keywords in the file are case-insensitive. Comments may be placed anywhere within the file (except within quotes). Comments begin with the # character and end at the end of the line.

The dhclient.conf file can be used to configure the behaviour of the client in a wide variety of ways: protocol timing, information requested from the server, information required of the server, defaults to use if the server does not provide certain information, values with which to override information provided by the server, or values to prepend or append to information provided by the server. The configuration file can also be preinitialized with addresses to use on networks that don't have DHCP servers.

## PROTOCOL TIMING
The timing behaviour of the client need not be configured by the user. If no timing configuration is provided by the user, a fairly reasonable timing behaviour will be used by default - one which results in fairly timely updates without placing an inordinate load on the server.

If required the following statements can be used to adjust the timing behaviour of the DHCPv4 client. The DHCPv6 protocol provides values to use and they are not currently configurable.

The timeout statement

timeout time;

The timeout statement determines the amount of time that must pass between the time that the client begins to try to determine its address and the time that it decides that it's not going to be able to contact a server. By default, this timeout is sixty seconds. After the timeout has passed, if there are any static leases defined in the configuration file, or any leases remaining in the lease database that have not yet expired, the client will loop through these leases attempting to validate them, and if it finds one that appears to be valid, it will use that lease's address. If there are no valid static leases or unexpired leases in the lease database, the client will restart the protocol after the defined retry interval.

The retry statement

retry time;

The retry statement determines the time that must pass after the client has determined that there is no DHCP server present before it tries again to contact a DHCP server. By default, this is five minutes.

The select-timeout statement

select-timeout time;

It is possible (some might say desirable) for there to be more than one DHCP server serving any given network. In this case, it is possible that a client may be sent more than one offer in response to its initial lease discovery message. It may be that one of these offers is preferable to the other (e.g., one offer may have the address the client previously used, and the other may not).

The select-timeout is the time after the client sends its first lease discovery request at which it stops waiting for offers from servers, assuming that it has received at least one such offer. If no offers have been received by the time the select-timeout has expired, the client will accept the first offer that arrives.

By default, the select-timeout is zero seconds - that is, the client will take the first offer it sees.

The reboot statement

reboot time;

When the client is restarted, it first tries to reacquire the last address it had. This is called the INIT-REBOOT state. If it is still attached to the same network it was attached to when it last ran, this is the quickest way to get started. The reboot statement sets the time that must elapse after the client first tries to reacquire its old address before it gives up and tries to discover a new address. By default, the reboot timeout is ten seconds.

The backoff-cutoff statement

backoff-cutoff time;

The client uses an exponential backoff algorithm with some randomness, so that if many clients try to configure themselves at the same time, they will not make their requests in lockstep. The backoff-cutoff statement determines the maximum amount of time that the client is allowed to back off, the actual value will be evaluated randomly between 1/2 to 1 1/2 times the time specified. It defaults to fifteen seconds.

The initial-interval statement

initial-interval time;

The initial-interval statement sets the amount of time between the first attempt to reach a server and the second attempt to reach a server. Each time a message is sent, the interval between messages is incremented by twice the current interval multiplied by a random number between zero and one. If it is greater than the backoff-cutoff amount, it is set to that amount. It defaults to ten seconds.

The initial-delay statement

initial-delay time;

initial-delay parameter sets the maximum time client can wait after start before commencing first transmission. According to RFC2131 Section 4.4.1, client should wait a random time between startup and the actual first transmission. Previous versions of ISC DHCP client used to wait random time up to 5 seconds, but that was unwanted due to impact on startup time. As such, new versions have the default initial delay set to 0. To restore old behavior, please set initial-delay to 5.

## DHCPv6 LEASE SELECTION
In the DHCPv6 protocol the client will wait a small amount of time to allow ADVERTISE messages from multiple servers to arrive. It will then need to choose from all of the messages that may have arrived before proceeding to making a request of the selected server.

The first selection criteria is the set of options and addresses in the message. Messages that don't include an option specified as required will be given a score of 0 and not used. If the -R option is given on the command line then messages that don't include the correct number of bindings (IA-NA, IA-TA or IA-PD) will be discarded.

The next criteria is the preference value from the message. With the highest preference value being used even if leases with better addresses or options are available.

Finally the lease is scored and the lease with the highest score is selected. A lease's score is based on the number of bindings, number of addresses and number of options it contains:

```
	bindings * X + addresses * Y + options
```

By default X = 10000 and Y = 100, this will cause the client to select a lease with more bindings over a lease with less bindings but more addresses. The weightings were changed as part of implementing RFC 7550. Previously they were X = 50 and Y = 100 meaning more addresses were preferred over more bindings. If you wish to continue using the old style you may do so by editing the file includes/site.h and uncommenting the define for USE_ORIGINAL_CLIENT_LEASE_WEIGHTS.

## LEASE REQUIREMENTS AND REQUESTS
The DHCP protocol allows the client to request that the server send it specific information, and not send it other information that it is not prepared to accept. The protocol also allows the client to reject offers from servers if they don't contain information the client needs, or if the information provided is not satisfactory.

There is a variety of data contained in offers that DHCP servers send to DHCP clients. The data that can be specifically requested is what are called DHCP Options. DHCP Options are defined in

dhcp-options(5).

The request statement

[ also ] request [ [ option-space . ] option ] [, ... ];

The request statement causes the client to request that any server responding to the client send the client its values for the specified options. Only the option names should be specified in the request statement - not option parameters. By default, the DHCPv4 client requests the subnet-mask, broadcast-address, time-offset, routers, domain-search, domain-name, domain-name-servers, host-name, ntp-servers and interface-mtu options while the DHCPv6 client requests the dhcp6 name-servers and domain-search options. Note that if you enter a ´request´ statement, you over-ride these defaults and these options will not be requested.

In some cases, it may be desirable to send no parameter request list at all. To do this, simply write the request statement but specify no parameters:

```
	request;
```

In most cases, it is desirable to simply add one option to the request list which is of interest to the client in question. In this case, it is best to ´also request´ the additional options:

```
	also request domain-search, dhcp6.sip-servers-addresses;
```

The require statement

[ also ] require [ [ option-space . ] option ] [, ... ];

The require statement lists options that must be sent in order for an offer to be accepted. Offers that do not contain all the listed options will be ignored. There is no default require list.

```
	require name-servers;
	interface eth0 {
		also require domain-search;
	}
```

The send statement

send [ option declaration ] ;

The send statement causes the client to send the specified option to the server with the specified value. This is a full option declaration as described in dhcp-options(5). Options that are always sent in the DHCP protocol should not be specified here, except that the client can specify a requested dhcp-lease-time option other than the default requested lease time, which is two hours. The other obvious use for this statement is to send information to the server that will allow it to differentiate between this client and other clients or kinds of clients.

## DYNAMIC DNS
The client now has some very limited support for doing DNS updates when a lease is acquired. This is prototypical, and probably doesn't do what you want. It also only works if you happen to have control over your DNS server, which isn't very likely.

Note that everything in this section is true whether you are using DHCPv4 or DHCPv6. The exact same syntax is used for both.

To make it work, you have to declare a key and zone as in the DHCP server (see dhcpd.conf(5) for details). You also need to configure the fqdn option on the client, as follows:

```
  send fqdn.fqdn "grosse.example.com.";

  send fqdn.encoded on;

  send fqdn.server-update off;

  also request fqdn, dhcp6.fqdn;
```

The fqdn.fqdn option MUST be a fully-qualified domain name. You MUST define a zone statement for the zone to be updated. The fqdn.encoded option may need to be set to on or off, depending on the DHCP server you are using.

The do-forward-updates statement

do-forward-updates [ flag ] ;

If you want to do DNS updates in the DHCP client script (see dhclient-script(8)) rather than having the DHCP client do the update directly (for example, if you want to use SIG(0) authentication, which is not supported directly by the DHCP client, you can instruct the client not to do the update using the do-forward-updates statement. Flag should be true if you want the DHCP client to do the update, and false if you don't want the DHCP client to do the update. By default, the DHCP client will do the DNS update.

## OPTION MODIFIERS
In some cases, a client may receive option data from the server which is not really appropriate for that client, or may not receive information that it needs, and for which a useful default value exists. It may also receive information which is useful, but which needs to be supplemented with local information. To handle these needs, several option modifiers are available.

The default statement

default [ option declaration ] ;

If for some option the client should use the value supplied by the server, but needs to use some default value if no value was supplied by the server, these values can be defined in the default statement.

The supersede statement

supersede [ option declaration ] ;

If for some option the client should always use a locally-configured value or values rather than whatever is supplied by the server, these values can be defined in the supersede statement.

The prepend statement

prepend [ option declaration ] ;

If for some set of options the client should use a value you supply, and then use the values supplied by the server, if any, these values can be defined in the prepend statement. The prepend statement can only be used for options which allow more than one value to be given. This restriction is not enforced - if you ignore it, the behaviour will be unpredictable.

The append statement

append [ option declaration ] ;

If for some set of options the client should first use the values supplied by the server, if any, and then use values you supply, these values can be defined in the append statement. The append statement can only be used for options which allow more than one value to be given. This restriction is not enforced - if you ignore it, the behaviour will be unpredictable.

## LEASE DECLARATIONS
The lease declaration

lease { lease-declaration [ ... lease-declaration ] }

The DHCP client may decide after some period of time (see PROTOCOL TIMING) that it is not going to succeed in contacting a server. At that time, it consults its own database of old leases and tests each one that has not yet timed out by pinging the listed router for that lease to see if that lease could work. It is possible to define one or more fixed leases in the client configuration file for networks where there is no DHCP or BOOTP service, so that the client can still automatically configure its address. This is done with the lease statement.

NOTE: the lease statement is also used in the dhclient.leases file in order to record leases that have been received from DHCP servers. Some of the syntax for leases as described below is only needed in the dhclient.leases file. Such syntax is documented here for completeness.

A lease statement consists of the lease keyword, followed by a left curly brace, followed by one or more lease declaration statements, followed by a right curly brace. The following lease declarations are possible:

bootp;

The bootp statement is used to indicate that the lease was acquired using the BOOTP protocol rather than the DHCP protocol. It is never necessary to specify this in the client configuration file. The client uses this syntax in its lease database file.

interface "string";

The interface lease statement is used to indicate the interface on which the lease is valid. If set, this lease will only be tried on a particular interface. When the client receives a lease from a server, it always records the interface number on which it received that lease. If predefined leases are specified in the dhclient.conf file, the interface should also be specified, although this is not required.

fixed-address ip-address;

The fixed-address statement is used to set the ip address of a particular lease. This is required for all lease statements. The IP address must be specified as a dotted quad (e.g., 12.34.56.78).

filename "string";

The filename statement specifies the name of the boot filename to use. This is not used by the standard client configuration script, but is included for completeness.

server-name "string";

The server-name statement specifies the name of the boot server name to use. This is also not used by the standard client configuration script.

option option-declaration;

The option statement is used to specify the value of an option supplied by the server, or, in the case of predefined leases declared in dhclient.conf, the value that the user wishes the client configuration script to use if the predefined lease is used.

script "script-name";

The script statement is used to specify the pathname of the dhcp client configuration script. This script is used by the dhcp client to set each interface's initial configuration prior to requesting an address, to test the address once it has been offered, and to set the interface's final configuration once a lease has been acquired. If no lease is acquired, the script is used to test predefined leases, if any, and also called once if no valid lease can be identified. For more information, see dhclient-script(8).

vendor option space "name";

The vendor option space statement is used to specify which option space should be used for decoding the vendor-encapsulate-options option if one is received. The dhcp-vendor-identifier can be used to request a specific class of vendor options from the server. See dhcp-options(5) for details.

medium "media setup";

The medium statement can be used on systems where network interfaces cannot automatically determine the type of network to which they are connected. The media setup string is a system-dependent parameter which is passed to the dhcp client configuration script when initializing the interface. On Unix and Unix-like systems, the argument is passed on the ifconfig command line when configuring the interface.

The dhcp client automatically declares this parameter if it uses a media type (see the media statement) when configuring the interface in order to obtain a lease. This statement should be used in predefined leases only if the network interface requires media type configuration.

renew date;

rebind date;

expire date;

The renew statement defines the time at which the dhcp client should begin trying to contact its server to renew a lease that it is using. The rebind statement defines the time at which the dhcp client should begin to try to contact any dhcp server in order to renew its lease. The expire statement defines the time at which the dhcp client must stop using a lease if it has not been able to contact a server in order to renew it.

These declarations are automatically set in leases acquired by the DHCP client, but must also be configured in predefined leases - a predefined lease whose expiry time has passed will not be used by the DHCP client.

Dates are specified in one of two ways. The software will output times in these two formats depending on if the db-time-format configuration parameter has been set to default or local.

If it is set to default, then date values appear as follows:

<weekday> <year>/<month>/<day> <hour>:<minute>:<second>

The weekday is present to make it easy for a human to tell when a lease expires - it's specified as a number from zero to six, with zero being Sunday. When declaring a predefined lease, it can always be specified as zero. The year is specified with the century, so it should generally be four digits except for really long leases. The month is specified as a number starting with 1 for January. The day of the month is likewise specified starting with 1. The hour is a number between 0 and 23, the minute a number between 0 and 59, and the second also a number between 0 and 59.

If the db-time-format configuration was set to local, then the date values appear as follows:

epoch <seconds-since-epoch>; # <day-name> <month-name> <day-number> <hours>:<minutes>:<seconds> <year>

The seconds-since-epoch is as according to the system's local clock (often referred to as "unix time"). The # symbol supplies a comment that describes what actual time this is as according to the system's configured timezone, at the time the value was written. It is provided only for human inspection, the epoch time is the only recommended value for machine inspection.

Note that when defining a static lease, one may use either time format one wishes, and need not include the comment or values after it.

If the time is infinite in duration, then the date is never instead of an actual date.

## ALIAS DECLARATIONS

alias { declarations ... }

Some DHCP clients running TCP/IP roaming protocols may require that in addition to the lease they may acquire via DHCP, their interface also be configured with a predefined IP alias so that they can have a permanent IP address even while roaming. The Internet Systems Consortium DHCP client doesn't support roaming with fixed addresses directly, but in order to facilitate such experimentation, the dhcp client can be set up to configure an IP alias using the alias declaration.

The alias declaration resembles a lease declaration, except that options other than the subnet-mask option are ignored by the standard client configuration script, and expiry times are ignored. A typical alias declaration includes an interface declaration, a fixed-address declaration for the IP alias address, and a subnet-mask option declaration. A medium statement should never be included in an alias declaration.

## OTHER DECLARATIONS

db-time-format [ default | local ] ;

The db-time-format option determines which of two output methods are used for printing times in leases files. The default format provides day-and-time in UTC, whereas local uses a seconds-since-epoch to store the time value, and helpfully places a local timezone time in a comment on the same line. The formats are described in detail in this manpage, within the LEASE DECLARATIONS section.

The lease-id-format parameter

lease-id-format format;

The format parameter must be either octal or hex. This parameter governs the format used to write certain values to lease files. With the default format, octal, values are written as quoted strings in which non-printable characters are represented as octal escapes - a backslash character followed by three octal digits. When the hex format is specified, values are written as an unquoted series of hexadecimal digit pairs, separated by colons.

Currently, the values written out based on lease-id-format are the default-duid and the IAID value (DHCPv6 only). The client automatically reads the values in either format. Note that when the format is octal, rather than as an octal string, IAID is output as hex if it contains no printable characters or as a string if contains only printable characters. This is done to maintain backward compatibility.

reject cidr-ip-address [, ... cidr-ip-address ] ;

The reject statement causes the DHCP client to reject offers from servers whose server identifier matches any of the specified hosts or subnets. This can be used to avoid being configured by rogue or misconfigured dhcp servers, although it should be a last resort - better to track down the bad DHCP server and fix it.

The cidr-ip-address configuration type is of the form ip-address[/prefixlen], where ip-address is a dotted quad IP address, and prefixlen is the CIDR prefix length of the subnet, counting the number of significant bits in the netmask starting from the leftmost end. Example configuration syntax:

reject 192.168.0.0/16, 10.0.0.5;

The above example would cause offers from any server identifier in the entire RFC 1918 "Class C" network 192.168.0.0/16, or the specific single address 10.0.0.5, to be rejected.

interface "name" { declarations ... }

A client with more than one network interface may require different behaviour depending on which interface is being configured. All timing parameters and declarations other than lease and alias declarations can be enclosed in an interface declaration, and those parameters will then be used only for the interface that matches the specified name. Interfaces for which there is no interface declaration will use the parameters declared outside of any interface declaration, or the default settings.

Note well: ISC dhclient only maintains one list of interfaces, which is either determined at startup from command line arguments, or otherwise is autodetected. If you supplied the list of interfaces on the command line, this configuration clause will add the named interface to the list in such a way that will cause it to be configured by DHCP. Which may not be the result you had intended. This is an undesirable side effect that will be addressed in a future release.

pseudo "name" "real-name" { declarations ... }

Under some circumstances it can be useful to declare a pseudo-interface and have the DHCP client acquire a configuration for that interface. Each interface that the DHCP client is supporting normally has a DHCP client state machine running on it to acquire and maintain its lease. A pseudo-interface is just another state machine running on the interface named real-name, with its own lease and its own state. If you use this feature, you must provide a client identifier for both the pseudo-interface and the actual interface, and the two identifiers must be different. You must also provide a separate client script for the pseudo-interface to do what you want with the IP address. For example:

```
	interface "ep0" {
		send dhcp-client-identifier "my-client-ep0";
	}
	pseudo "secondary" "ep0" {
		send dhcp-client-identifier "my-client-ep0-secondary";
		script "/etc/dhcp/dhclient-secondary";
	}
```

The client script for the pseudo-interface should not configure the interface up or down - essentially, all it needs to handle are the states where a lease has been acquired or renewed, and the states where a lease has expired. See dhclient-script(8) for more information.

media "media setup" [ , "media setup", ... ];

The media statement defines one or more media configuration parameters which may be tried while attempting to acquire an IP address. The dhcp client will cycle through each media setup string on the list, configuring the interface using that setup and attempting to boot, and then trying the next one. This can be used for network interfaces which aren't capable of sensing the media type unaided - whichever media type succeeds in getting a request to the server and hearing the reply is probably right (no guarantees).

The media setup is only used for the initial phase of address acquisition (the DHCPDISCOVER and DHCPOFFER packets). Once an address has been acquired, the dhcp client will record it in its lease database and will record the media type used to acquire the address. Whenever the client tries to renew the lease, it will use that same media type. The lease must expire before the client will go back to cycling through media types.

hardware link-type mac-address;

The hardware statement defines the hardware MAC address to use for this interface, for DHCP servers or relays to direct their replies. dhclient will determine the interface's MAC address automatically, so use of this parameter is not recommended. The link-type corresponds to the interface's link layer type (example: ´ethernet´), while the mac-address is a string of colon-separated hexadecimal values for octets.

anycast-mac link-type mac-address;

The anycast-mac statement over-rides the all-ones broadcast MAC address dhclient will use when it is transmitting packets to the all-ones limited broadcast IPv4 address. This configuration parameter is useful to reduce the number of broadcast packets transmitted by DHCP clients, but is only useful if you know the DHCP service(s) anycast MAC address prior to configuring your client. The link-type and mac-address parameters are configured in a similar manner to the hardware statement.

bootp-broadcast-always;

The bootp-broadcast-always statement instructs dhclient to always set the bootp broadcast flag in request packets, so that servers will always broadcast replies. This is equivalent to supplying the dhclient -B argument, and has the same effect as specifying 'always-broadcast' in the server's dhcpd.conf. This option is provided as an extension to enable dhclient to work on IBM s390 Linux guests.

## SAMPLE
The following configuration file was used on a laptop running NetBSD 1.3, though the domains have been modified. The laptop has an IP alias of 192.5.5.213, and has one interface, ep0 (a 3com 3C589C). Booting intervals have been shortened somewhat from the default, because the client is known to spend most of its time on networks with little DHCP activity. The laptop does roam to multiple networks.

```
timeout 60;
retry 60;
reboot 10;
select-timeout 5;
initial-interval 2;
reject 192.33.137.209;
interface "ep0" {

    send host-name "andare.example.com";

    hardware ethernet 00:a0:24:ab:fb:9c;

    send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;

    send dhcp-lease-time 3600;

    supersede domain-search "example.com", "rc.isc.org", "home.isc.org";

    prepend domain-name-servers 127.0.0.1;

    request subnet-mask, broadcast-address, time-offset, routers,
	    domain-search, domain-name, domain-name-servers, host-name;

    require subnet-mask, domain-name-servers;

    script "CLIENTBINDIR/dhclient-script";

    media "media 10baseT/UTP", "media 10base2/BNC";
}
alias {

  interface "ep0";

  fixed-address 192.5.5.213;

  option subnet-mask 255.255.255.255;
}
```

This is a very complicated dhclient.conf file - in general, yours should be much simpler. In many cases, it's sufficient to just create an empty dhclient.conf file - the defaults are usually fine.

## SEE ALSO
dhcp-options(5), dhcp-eval(5), dhclient.leases(5), dhcpd(8), dhcpd.conf(5), RFC2132, RFC2131.

## AUTHOR
dhclient(8) Information about Internet Systems Consortium can be found at https://www.isc.org.


dhclient.leases

title: dhclient.leases(5)

text:
# dhclient.leases(5)

## NAME
dhclient.leases - DHCP client lease database

## DESCRIPTION
The Internet Systems Consortium DHCP client keeps a persistent database of leases that it has acquired that are still valid. The database is a free-form ASCII file containing one valid declaration per lease. If more than one declaration appears for a given lease, the last one in the file is used. The file is written as a log, so this is not an unusual occurrence.

The format of the lease declarations is described in dhclient.conf(5).

## FILES
/var/lib/dhcp/dhclient/state/dhclient.leases

## SEE ALSO
dhclient(8), dhcp-options(5), dhclient.conf(5), dhcpd(8), dhcpd.conf(5), RFC2132, RFC2131.

## AUTHOR
dhclient(8) Information about Internet Systems Consortium can be found at https://www.isc.org.


dhcp-eval

package: dhcp-server

title: dhcp-eval(5)

text:
# dhcp-eval(5)

## NAME
dhcp-eval - ISC DHCP conditional evaluation

## DESCRIPTION
The Internet Systems Consortium DHCP client and server both provide the ability to perform conditional behavior depending on the contents of packets they receive. The syntax for specifying this conditional behaviour is documented here.

## REFERENCE: CONDITIONAL BEHAVIOUR
Conditional behaviour may be specified using the if statement and the else or elsif statements or the switch and case statements. A conditional statement can appear anywhere that a regular statement (e.g., an option statement) can appear, and can enclose one or more such statements.

CONDITIONAL BEHAVIOUR: IF

A typical conditional if statement in a server might be:

```
if option dhcp-user-class = "accounting" {

  max-lease-time 17600;

  option domain-name "accounting.example.org";

  option domain-name-servers ns1.accounting.example.org,
			     ns2.accounting.example.org;
} elsif option dhcp-user-class = "sales" {

  max-lease-time 17600;

  option domain-name "sales.example.org";

  option domain-name-servers ns1.sales.example.org,
			     ns2.sales.example.org;
} elsif option dhcp-user-class = "engineering" {

  max-lease-time 17600;

  option domain-name "engineering.example.org";

  option domain-name-servers ns1.engineering.example.org,
			     ns2.engineering.example.org;
} else {

  max-lease-time 600;

  option domain-name "misc.example.org";

  option domain-name-servers ns1.misc.example.org,
			     ns2.misc.example.org;
}
```

On the client side, an example of conditional evaluation might be:

```
# example.org filters DNS at its firewall, so we have to use their DNS
# servers when we connect to their network.  If we are not at
# example.org, prefer our own DNS server.
if not option domain-name = "example.org" {

  prepend domain-name-servers 127.0.0.1;
}
```

The if statement and the elsif continuation statement both take boolean expressions as their arguments. That is, they take expressions that, when evaluated, produce a boolean result. If the expression evaluates to true, then the statements enclosed in braces following the if statement are executed, and all subsequent elsif and else clauses are skipped. Otherwise, each subsequent elsif clause's expression is checked, until an elsif clause is encountered whose test evaluates to true. If such a clause is found, the statements in braces following it are executed, and then any subsequent elsif and else clauses are skipped. If all the if and elsif clauses are checked but none of their expressions evaluate true, then if there is an else clause, the statements enclosed in braces following the else are evaluated. Boolean expressions that evaluate to null are treated as false in conditionals.

CONDITIONAL BEHAVIOUR: SWITCH

The above example can be rewritten using a switch construct as well.

```
switch (option dhcp-user-class) {

  case "accounting":

    max-lease-time 17600;

    option domain-name "accounting.example.org";

    option domain-name-servers ns1.accounting.example.org,
			       ns2.accounting.example.org;

  case "sales":

    max-lease-time 17600;

    option domain-name "sales.example.org";

    option domain-name-servers ns1.sales.example.org,
			       ns2.sales.example.org;

    break;

  case "engineering":

    max-lease-time 17600;

    option domain-name "engineering.example.org";

    option domain-name-servers ns1.engineering.example.org,
			       ns2.engineering.example.org;

    break;

  default:

    max-lease-time 600;

    option domain-name "misc.example.org";

    option domain-name-servers ns1.misc.example.org,
			       ns2.misc.example.org;

    break;
}
```

The switch statement and the case statements can both be data expressions or numeric expressions. Within a switch statement they all must be the same type. The server evaluates the expression from the switch statement and then it evaluates the expressions from the case statements until it finds a match.

If it finds a match it starts executing statements from that case until the next break statement. If it doesn't find a match it starts from the default statement and again proceeds to the next break statement. If there is no match and no default it does nothing.

## BOOLEAN EXPRESSIONS
The following is the current list of boolean expressions that are supported by the DHCP distribution.

data-expression-1 = data-expression-2

The = operator compares the values of two data expressions, returning true if they are the same, false if they are not. If either the left-hand side or the right-hand side are null, the result is also null.

data-expression-1 ~= data-expression-2 data-expression-1 ~~ data-expression-2

The ~= and ~~ operators (not available on all systems) perform extended regex(7) matching of the values of two data expressions, returning true if data-expression-1 matches against the regular expression evaluated by data-expression-2, or false if it does not match or encounters some error. If either the left-hand side or the right-hand side are null or empty strings, the result is also false. The ~~ operator differs from the ~= operator in that it is case-insensitive.

boolean-expression-1 and boolean-expression-2

The and operator evaluates to true if the boolean expression on the left-hand side and the boolean expression on the right-hand side both evaluate to true. Otherwise, it evaluates to false. If either the expression on the left-hand side or the expression on the right-hand side are null, the result is null.

boolean-expression-1 or boolean-expression-2

The or operator evaluates to true if either the boolean expression on the left-hand side or the boolean expression on the right-hand side evaluate to true. Otherwise, it evaluates to false. If either the expression on the left-hand side or the expression on the right-hand side are null, the result is null.

not boolean-expression

The not operator evaluates to true if boolean-expression evaluates to false, and returns false if boolean-expression evaluates to true. If boolean-expression evaluates to null, the result is also null.

exists option-name

The exists expression returns true if the specified option exists in the incoming DHCP packet being processed.

known

The known expression returns true if the client whose request is currently being processed is known - that is, if there's a host declaration for it.

static

The static expression returns true if the lease assigned to the client whose request is currently being processed is derived from a static address assignment.

## DATA EXPRESSIONS
Several of the boolean expressions above depend on the results of evaluating data expressions. A list of these expressions is provided here.

substring (data-expr, offset, length)

The substring operator evaluates the data expression and returns the substring of the result of that evaluation that starts offset bytes from the beginning, continuing for length bytes. Offset and length are both numeric expressions. If data-expr, offset or length evaluate to null, then the result is also null. If offset is greater than or equal to the length of the evaluated data, then a zero-length data string is returned. If length is greater then the remaining length of the evaluated data after offset, then a data string containing all data from offset to the end of the evaluated data is returned.

suffix (data-expr, length)

The suffix operator evaluates data-expr and returns the last length bytes of the result of that evaluation. Length is a numeric expression. If data-expr or length evaluate to null, then the result is also null. If suffix evaluates to a number greater than the length of the evaluated data, then the evaluated data is returned.

lcase (data-expr)

The lcase function returns the result of evaluating data-expr converted to lower case. If data-expr evaluates to null, then the result is also null.

ucase (data-expr)

The ucase function returns the result of evaluating data-expr converted to upper case. If data-expr evaluates to null, then the result is also null.

option option-name

The option operator returns the contents of the specified option in the packet to which the server is responding.

config-option option-name

The config-option operator returns the value for the specified option that the DHCP client or server has been configured to send.

gethostname()

The gethostname() function returns a data string whose contents are a character string, the results of calling gethostname() on the local system with a size limit of 255 bytes (not including NULL terminator). This can be used for example to configure dhclient to send the local hostname without knowing the local hostname at the time dhclient.conf is written.

hardware

The hardware operator returns a data string whose first element is the type of network interface indicated in packet being considered, and whose subsequent elements are client's link-layer address. If there is no packet, or if the RFC2131 hlen field is invalid, then the result is null. Hardware types include ethernet (1), token-ring (6), and fddi (8). Hardware types are specified by the IETF, and details on how the type numbers are defined can be found in RFC2131 (in the ISC DHCP distribution, this is included in the doc/ subdirectory).

packet (offset, length)

The packet operator returns the specified portion of the packet being considered, or null in contexts where no packet is being considered. Offset and length are applied to the contents packet as in the substring operator.

string

A string, enclosed in quotes, may be specified as a data expression, and returns the text between the quotes, encoded in ASCII. The backslash ('\') character is treated specially, as in C programming: '\t' means TAB, '\r' means carriage return, '\n' means newline, and '\b' means bell. Any octal value can be specified with '\nnn', where nnn is any positive octal number less than 0400. Any hexadecimal value can be specified with '\xnn', where nn is any positive hexadecimal number less than or equal to 0xff.

colon-separated hexadecimal list

A list of hexadecimal octet values, separated by colons, may be specified as a data expression.

concat (data-expr1, ..., data-exprN)

The expressions are evaluated, and the results of each evaluation are concatenated in the sequence that the subexpressions are listed. If any subexpression evaluates to null, the result of the concatenation is null.

reverse (numeric-expr1, data-expr2)

The two expressions are evaluated, and then the result of evaluating the data expression is reversed in place, using hunks of the size specified in the numeric expression. For example, if the numeric expression evaluates to four, and the data expression evaluates to twelve bytes of data, then the reverse expression will evaluate to twelve bytes of data, consisting of the last four bytes of the input data, followed by the middle four bytes, followed by the first four bytes.

leased-address

In any context where the client whose request is being processed has been assigned an IP address, this data expression returns that IP address. In any context where the client whose request is being processed has not been assigned an ip address, if this data expression is found in executable statements executed on that client's behalf, a log message indicating "there is no lease associated with this client" is syslogged to the debug level (this is considered dhcpd.conf debugging information).

binary-to-ascii (numeric-expr1, numeric-expr2, data-expr1, data-expr2)

Converts the result of evaluating data-expr2 into a text string containing one number for each element of the result of evaluating data-expr2. Each number is separated from the other by the result of evaluating data-expr1. The result of evaluating numeric-expr1 specifies the base (2 through 16) into which the numbers should be converted. The result of evaluating numeric-expr2 specifies the width in bits of each number, which may be either 8, 16 or 32. As an example of the preceding three types of expressions, to produce the name of a PTR record for the IP address being assigned to a client, one could write the following expression:

```
        concat (binary-to-ascii (10, 8, ".",

                                 reverse (1, leased-address)),

                ".in-addr.arpa.");
```

encode-int (numeric-expr, width)

Numeric-expr is evaluated and encoded as a data string of the specified width, in network byte order (most significant byte first). If the numeric expression evaluates to the null value, the result is also null.

pick-first-value (data-expr1 [ ... exprn ] )

The pick-first-value function takes any number of data expressions as its arguments. Each expression is evaluated, starting with the first in the list, until an expression is found that does not evaluate to a null value. That expression is returned, and none of the subsequent expressions are evaluated. If all expressions evaluate to a null value, the null value is returned.

host-decl-name

The host-decl-name function returns the name of the host declaration that matched the client whose request is currently being processed, if any. If no host declaration matched, the result is the null value.

## NUMERIC EXPRESSIONS
Numeric expressions are expressions that evaluate to an integer. In general, the maximum size of such an integer should not be assumed to be representable in fewer than 32 bits, but the precision of such integers may be more than 32 bits.

In addition to the following operators several standard math functions are available. They are:

```
operation    symbol
add            +
subtract       -
divide         /
multiply       *
modulus        %
bitwise and    &
bitwise or     |
bitwise xor    ^
```

extract-int (data-expr, width)

The extract-int operator extracts an integer value in network byte order from the result of evaluating the specified data expression. Width is the width in bits of the integer to extract. Currently, the only supported widths are 8, 16 and 32. If the evaluation of the data expression doesn't provide sufficient bits to extract an integer of the specified size, the null value is returned.

lease-time

The duration of the current lease - that is, the difference between the current time and the time that the lease expires.

number

Any number between zero and the maximum representable size may be specified as a numeric expression.

client-state

The current state of the client instance being processed. This is only useful in DHCP client configuration files. Possible values are: •

Booting - DHCP client is in the INIT state, and does not yet have an IP address. The next message transmitted will be a DHCPDISCOVER, which will be broadcast.

•

Reboot - DHCP client is in the INIT-REBOOT state. It has an IP address, but is not yet using it. The next message to be transmitted will be a DHCPREQUEST, which will be broadcast. If no response is heard, the client will bind to its address and move to the BOUND state.

•

Select - DHCP client is in the SELECTING state - it has received at least one DHCPOFFER message, but is waiting to see if it may receive other DHCPOFFER messages from other servers. No messages are sent in the SELECTING state.

•

Request - DHCP client is in the REQUESTING state - it has received at least one DHCPOFFER message, and has chosen which one it will request. The next message to be sent will be a DHCPREQUEST message, which will be broadcast.

•

Bound - DHCP client is in the BOUND state - it has an IP address. No messages are transmitted in this state.

•

Renew - DHCP client is in the RENEWING state - it has an IP address, and is trying to contact the server to renew it. The next message to be sent will be a DHCPREQUEST message, which will be unicast directly to the server.

•

Rebind - DHCP client is in the REBINDING state - it has an IP address, and is trying to contact any server to renew it. The next message to be sent will be a DHCPREQUEST, which will be broadcast.

## REFERENCE: ACTION EXPRESSIONS
log (priority, data-expr)

Logging statements may be used to send information to the standard logging channels. A logging statement includes an optional priority (fatal, error, info, or debug), and a data expression.

Logging statements take only a single data expression argument, so if you want to output multiple data values, you will need to use the concat operator to concatenate them.

execute (command-path [, data-expr1, ... data-exprN]);

The execute statement runs an external command. The first argument is a string literal containing the name or path of the command to run. The other arguments, if present, are either string literals or data- expressions which evaluate to text strings, to be passed as command-line arguments to the command.

execute is synchronous; the program will block until the external command being run has finished. Please note that lengthy program execution (for example, in an "on commit" in dhcpd.conf) may result in bad performance and timeouts. Only external applications with very short execution times are suitable for use.

Passing user-supplied data to an external application might be dangerous. Make sure the external application checks input buffers for validity. Non-printable ASCII characters will be converted into dhcpd.conf language octal escapes ("\nnn"), make sure your external command handles them as such.

It is possible to use the execute statement in any context, not only on events. If you put it in a regular scope in the configuration file you will execute that command every time a scope is evaluated.

parse-vendor-option;

The parse-vendor-option statement attempts to parse a vendor option (code 43). It is only useful while processing a packet on the server and requires that the administrator has already used the vendor-option-space statement to select a valid vendor space.

This functionality may be used if the server needs to take different actions depending on the values the client placed in the vendor option and the sub-options are not at fixed locations. It is handled as an action to allow an administrator to examine the incoming options and choose the correct vendor space.

## REFERENCE: DYNAMIC DNS UPDATES
See the dhcpd.conf and dhclient.conf man pages for more information about DDNS.

## SEE ALSO
dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-options(5), dhcpd(8), dhclient(8), RFC2132, RFC2131.

## AUTHOR
Information about Internet Systems Consortium can be found at https://www.isc.org.