Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Apropos / Subsearch:
optional field

server.pcy(4)							server.pcy(4)


  server.pcy - BOOTP and DHCP server policy


  The server.pcy file is a text	database that governs the behavior of BOOTP
  and DHCP servers.  If	the joind daemon is invoked to use text	databases, it
  reads	the server.pcy file on startup.	 If the	JOINCONFIG variable is
  present in the joind environment, it specifies the directory for the
  server.pcy file; otherwise, joind searches the /etc/join directory.
  Defaults exist for all parameters and	switches, so it	is not an error	if
  the file does	not exist.


  Blank	lines are ignored. The number sign character (#) introduces a com-
  ment,	which continues	to the next newline.  Each new policy option must
  begin	and end	on a separate line.  Policy options are	introduced by a	key-
  word,	and may	be Boolean, or may take	a value	separated from the keyword by
  whitespace (but not a	newline).  If an option	is present more	than once,
  only the value attached to the last occurrence is used; earlier value(s)
  are ignored.

  Keywords and Values

      This Boolean tells the server that if a DHCP client needs	a boot file,
      send the name of that file in the	BOOTP file field and not as a DHCP
      option (option 67).  BOOTP clients always	receive	a boot file name in
      the file field.  This is disabled	by default.

      This Boolean tells the server to ignore the value	of the broadcast bit
      and always broadcast a reply, even when the client can receive a pseudo
      unicast reply.  This was needed by some Cabletron	smart bridges.	This
      is disabled by default.

      This Boolean is for clients that do not use DHCP client identifiers.
      The parameter tells the server to	use the	client's hardware address as
      its identifier, but to ignore the	hadware	type field. In the JOIN	data-
      base, the	identifier is stored with a type field of zero (which is also
      the type for those clients that are using	client idetfifiers).  This is
      disabled by default.

  provisional_ttl seconds
      For each subnet that the BOOTP and DHCP server administers, two lists
      are maintained in	memory:	a "free" list containing IP addresses avail-
      able for allocation and a	"provisional" list containing addresses	that
      have been	tentatively assigned, which are	awaiting client	approval in
      the form of a DHCPREQUEST	packet.

      The value	of seconds determines how long an address will remain on the
      free list	before the server determines that the client does not want
      the offered address.  The	free list does not contain every address
      available	to the server; instead it acts as a cache of addresses which
      the server can offer without reading the disk.

      If a new client makes a DHCPDISCOVER, and	no IP address exists for the
      client in	permanent store, the server first goes to the free list	for
      an unused	address.  If the free list is exhausted, the server first
      reclaims any addresses on	the provisional	list which have	expired.  It
      then extends this	list to	be free_list_size in length by reading from
      the disk.	 This has a benefit in that addresses are usually offered in
      numerically increasing order. Making the ttl too short will not give
      clients an opportunity to	confirm	offered	addresses; making it too long
      will waste memory.

      Default: 60

  free_list_size integer
      See the explanation under	provisional_ttl.  If this number is too	low,
      server response time will	suffer.	If it is too large it has the
      undesirable effect of requiring the server to reclaim expired leases
      before they are actually needed for reallocation to new clients.
      Although this is not an error, a desirable feature of server operation
      is that, whenever	possible, a client requesting a	new IP address should
      get back its old address,	unless that address has	been leased to a new

      Default: 8

      This option and the "assign_name_by_ipaddr" option are mutually
      exclusive.  They govern how the server assigns names to hosts.  This
      option tells the server to bind a	name to	the MAC	address. That way, if
      the client moves to a new	address, it keeps the same name.

      This tells the server that if a lookup to	the name service (gethost-
      byaddr(3)) succeeds, the client should receive the name that was found
      at the IP	address.

      This Boolean option is compatible	with previous options.	It instructs
      the server that if it is not able	to find	a name for the client by
      application of the two previous policies,	it can accept the name the
      client suggests for itself providing that	this is	not in contradiction
      with values currently in the name	service.  If a contradiction exists,
      or this policy is	not enabled, joind consults its	namepool or prefix.
      (See namepool(4)).

      This Boolean tells joind to support BOOTP	clients.  When replying	to
      BOOTP clients, the server	does not use the DHCP extensions to the	BOOTP
      protocol.	 This is enabled by default.

      This Boolean is only valid if the	support_bootp option is	enabled.
      When on support_bootp permits the	server to permanently assign an	IP
      address from its free pool to a BOOTP client in the event	that no	per-
      manent binding exists in bootptab.  Normally the BOOTP and DHCP server
      can only service BOOTP clients for which such a binding pre-exists.

  ping_timeout value
      Before the server	offers an IP address to	a client it may	first check
      that the address is not in use by	sending	an ICMP	echo request. If an
      echo is received,	it means that the address is in	use, and the server
      selects another.	This parameter specifies the time (in milliseconds)
      that the server waits for	the echo.  If this value is zero or negative,
      the server does not perform this check.  Disabling this check may	be
      necessary	in certain environments	to decrease server response time to
      an acceptable level; this	release	of joind is not	multithreaded, so the
      server idles while awaiting the response.


  Files: namepool(4)

  Specifications: RFC 1541, RFC	1542