From: Ted Lemon Date: Fri, 26 Jun 1998 04:17:25 +0000 (+0000) Subject: New dhcpd.leases document X-Git-Tag: V2-BETA-1-PATCH-3~1 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=9e061adecc1a576aa61f23d5bc5a234197be551d;p=thirdparty%2Fdhcp.git New dhcpd.leases document --- diff --git a/server/dhcpd.leases.cat5 b/server/dhcpd.leases.cat5 index 9aab943a6..f509e6221 100644 --- a/server/dhcpd.leases.cat5 +++ b/server/dhcpd.leases.cat5 @@ -10,39 +10,161 @@ NNAAMMEE DDEESSCCRRIIPPTTIIOONN The Internet Software Consortium DHCP Server keeps a per­ sistent database of leases that it has assigned. This - 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 occurrance. + database is a free-form ASCII file containing a series of + lease declarations. Every time a lease is acquired, + renewed or released, its new value is recorded at the end + of the lease file. So if more than one declaration + appears for a given lease, the last one in the file is the + current one. When dhcpd is first installed, there is no lease database. - However, dhcpd requires that a lease database be present + However, dhcpd requires that a lease database be present before it will start. To make the initial lease database, just create an empty file called /var/db/dhcpd.leases. - In order to prevent the lease database from growing with­ - out bound, the file is rewritten from time to time. + In order to prevent the lease database from growing with­ + out bound, the file is rewritten from time to time. First, a temporary lease database is created and all known leases are dumped to it. Then, the old lease database is - renamed /var/db/dhcpd.leases~. Finally, the newly writ­ + renamed /var/db/dhcpd.leases~. Finally, the newly writ­ ten lease database is moved into place. There is a window of vulnerability where if the dhcpd pro­ - cess is killed or the system crashes after the old lease - database has been renamed but before the new one has been - moved into place, there will be no /var/db/dhcpd.leases. + cess is killed or the system crashes after the old lease + database has been renamed but before the new one has been + moved into place, there will be no /var/db/dhcpd.leases. In this case, dhcpd will refuse to start, and will require - manual intervention. DDOO NNOOTT simply create a new lease + manual intervention. DDOO NNOOTT simply create a new lease file when this happens - if you do, you will lose all your - old bindings, and chaos will ensue. Instead, rename - /var/db/dhcpd.leases~ to /var/db/dhcpd.leases, restoring - the old, valid lease file, and then start dhcpd. This + old bindings, and chaos will ensue. Instead, rename + /var/db/dhcpd.leases~ to /var/db/dhcpd.leases, restoring + the old, valid lease file, and then start dhcpd. This guarantees that a valid lease file will be restored. FFOORRMMAATT - The format of the lease declarations is not currently doc­ - umented. + Lease descriptions are stored in a format that is parsed + by the same recursive descent parser used to read the + ddhhccppdd..ccoonnff((55)) and ddhhcclliieenntt..ccoonnff((55)) files. Currently, the + only declaration that is used in the dhcpd.leases file is + the lleeaassee declaration. + + lleeaassee _i_p_-_a_d_d_r_e_s_s {{ _s_t_a_t_e_m_e_n_t_s_._._. }} + + Each lease declaration include the single IP address that + has been leased to the client. The statements within the + braces define the duration of the lease and to whom it is + assigned. + + The start and end time of a lease are recorded using the + ``starts'' and ``ends'' statements: + + + + + 1 + + + + + +dhcpd.leases(5) dhcpd.leases(5) + + + ssttaarrttss _d_a_t_e;; + eennddss _d_a_t_e;; + + Dates are specified as follows: + + _w_e_e_k_d_a_y _y_e_a_r//_m_o_n_t_h//_d_a_y _h_o_u_r::_m_i_n_u_t_e::_s_e_c_o_n_d + + 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. The day of week is + ignored on input. 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 sec­ + ond also a number between 0 and 59. + + Lease times are specified in Greenwich Mean Time (GMT), + not in the local time zone. Since Greenwich is actually + on Daylight Savings Time part of the year, there is proba­ + bly nowhere in the world where the times recorded on a + lease are always the same as wall clock times. On a unix + machine, one can often figure out the current time in GMT + by typing ddaattee --uu. + + The MAC address of the network interface that was used to + acquire the lease is recorded with the hhaarrddwwaarree statement: + + hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _m_a_c_-_a_d_d_r_e_s_s;; + + The MAC address is specified as a series of hexadecimal + octets, seperated by colons. + + If the client used a client identifier to acquire its + address, the client identifier is recorded using the uuiidd + statement: + + uuiidd _c_l_i_e_n_t_-_i_d_e_n_t_i_f_i_e_r;; + + The client identifier is recorded as a series of hexadeci­ + mal octets, regardless of whether the client specifies an + ASCII string or uses the newer hardware type/MAC address + format. + + If the client sends a hostname using the _C_l_i_e_n_t _H_o_s_t_n_a_m_e + option, as specified in some versions of the DHCP-DNS + Interaction draft, that hostname is recorded using the + cclliieenntt--hhoossttnnaammee statement. + + cclliieenntt--hhoossttnnaammee ""_h_o_s_t_n_a_m_e"";; + + If the client sends its hostname using the _H_o_s_t_n_a_m_e + option, as Windows 95 does, it is recorded using the + + + + 2 + + + + + +dhcpd.leases(5) dhcpd.leases(5) + + + hhoossttnnaammee statement. + + hhoossttnnaammee ""_h_o_s_t_n_a_m_e"";; + + The DHCP server may determine that a lease has been mis­ + used in some way, either because a client that has been + assigned a lease NAKs it, or because the server's own + attempt to see if an address is in use prior to reusing it + reveals that the address is in fact already in use. In + that case, the aabbaannddoonneedd statement will be used to indi­ + cate that the lease should not be reassigned. + + aabbaannddoonneedd;; + + Abandoned leases are reclaimed automatically. When a + client asks for a new address, and the server finds that + there are no new addresses, it checks to see if there are + any abandoned leases, and allocates the least recently + abandoned lease. The standard mechanisms for checking + for lease address conflicts are still followed, so if the + abandoned lease's IP address is still in use, it will be + reabandoned. + + If a client rreeqquueessttss an abandoned address, the server + assumes that the reason the address was abandoned was that + the lease file was corrupted, and that the client is the + machine that responded when the lease was probed, causing + it to be abandoned. In that case, the address is immedi­ + ately assigned to the client. FFIILLEESS //vvaarr//ddbb//ddhhccppdd..lleeaasseess @@ -61,6 +183,16 @@ AAUUTTHHOORR - 1 + + + + + + + + + + + 3