*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->Tru64 Unix man pages -> bootptab (4)              



NAME    [Toc]    [Back]

       bootptab - BOOTP and DHCP server database

DESCRIPTION    [Toc]    [Back]

       The  bootptab  file  is one of several text database files
       employed by joind, the BOOTP and DHCP server.  The  file's
       format is similar to that of the termcap(4) file.

   Format    [Toc]    [Back]
       There  are  three  types of lines in this file: data, comments,
 and whitespace (for readability).

       Data lines can be logically continued onto the next physical
  line  by preceding the newline character with a backslash
 (\), but the backslash-newline pair is ignored elsewhere.

       A  comment has the number sign (#) as the first nonwhitespace
 character on a line that is not a  logical  continuation
  of  a  data  line; in no other context is the number
       sign treated specially.   Comments  and  blank  lines  are
       ignored when the file is parsed by joind but are preserved
       when editing with the xjoin GUI.

       Data is organized into groups, the end of  a  group  being
       identified by a newline. A data group begins with a label,
       an optional printable string and one or  more  colon-separated
  fields,  each  of  which carries an identifying tag
       used to represent configuration parameters and the clients
       to which they apply.

       label:tg=value. . . :tg:. . . :tg=value. . . .

       The  tags  currently  recognized by bootptab are listed in

       The tg is a two-character tag symbol.  If tg refers  to  a
       Boolean  data  type,  it  may  stand alone to indicate the
       Boolean is on or true; it may also take the (case-insensitive)
 values true, false, on, or off.  Other types require
       a value set off from the tag by an equals  sign.   Leading
       or   trailing  whitespace  surrounding  a  text  value  is
       removed, but is retained if the string is enclosed in double
 quotes (the quotes are stripped internally).  The following
 special syntax is also acceptable:

       There is also a generic tag, Tn, where n is an integer  in
       the range 1-254.  The value may be represented as either a
       stream of hexadecimal numbers or  as  a  string  of  ASCII
       characters.   If  the  numeric  option is not found in the
       dhcptags file, the former interpretation is  tried  first;
       if  an  invalid  hexadecimal  digit  is  found, the second
       interpretation is used.  The dhcptags  file  obviates  the
       need to use this syntax, but it is supported for backwardcompatibility.

   SEMANTICS    [Toc]    [Back]
       In this section, when a reference is made  to  a  specific
       option, that option is described by its standard two character
 identifier in the  dhcptags  file.  These  tags  are
       identical  to  those in the Carnegie Mellon implementation
       of BOOTP, though DHCP defines wholly new options as  well.

       The  label  is a printable string that groups together the
       tags that follow the label and that can be  referenced  by
       the  tc  tag in other entries.  It may be interpreted as a
       client host name in the following circumstances only:  The
       data  group refers to a specific BOOTP client The hostname
       ho tag is not explicitly used The string is a  valid  host

       Tags may appear in any order with one exception: the hardware
 type (ht) must  precede  the  hardware  address  (ha)
       (either explicitly or implicitly; see the tc description).
       The ht tag specifies the hardware type code as  either  an
       unsigned  decimal, octal, or hexadecimal integer or one of
       the following symbolic names:

       Value   Symbol       Hardware Type
       0                    Client Identifier
       1       ethernet     10MB Ethernet
       2       ethernet3    3 MB experimental Ethernet
       3       ax.25
       4       pronet       Proteon ProNET Token Ring
       5       chaos
       6       token-ring   IEEE 802 networks
       7       arcnet

       The ha tag takes a value that (except when the type  field
       is  zero)  is a hardware address specified in hexadecimal;
       optional periods,  dashes,  or  colons  may  separate  the
       octets for readability; a leading '0x' indicating hexadecimal
 data is also permissible. However, the common convention
  of  using  colons as octet delimiters conflicts with
       the use of that symbol as a field separator  and  requires
       that the address be enclosed in quotes.

       When  the type field is zero, it implies that the ha field
       will be used to match against a client identifier, a  DHCP
       concept.   The  client  identifier  is an opaque object of
       arbitrary length, but may be a printable  string.   Therefore,
  in  the  case  of ha, the value is first scanned as
       hexadecimal; if this scan does not succeed, the  value  is
       assumed to be a literal string and is used as such.

       Within  each data group, certain tags and the label determine
 how the database will be constructed and searched  to
       resolve  a  particular  client  query.   When  the  server
       starts, each data group is internally assigned to  exactly
       one  of  5 hash tables according to the presence of one or
       more of the following  tags:  network  IP  address  vendor
       class hardware address/client identifier hardware type

       The valid combinations are as follows:

       The  keys  to  the  hash  tables  correspond to the values
       assumed by the tag or tags.   A  particular  configuration
       for  a  client  (both  DHCP  and  BOOTP) is synthesized by
       searching these tables, in the order given,  for  a  match
       that  corresponds  to  data  explicit  or  implied  in the
       client's BOOTPREQUEST packet.  Client parameters  resolved
       earlier  in the search take precedence over those resolved
       later.  Thus,  a  client  configuration  is  assembled  by
       searching  for  parameters  starting from most restrictive
       match to least.  To support BOOTP clients in the manner to
       which  they  are  accustomed, you can omit any data groups
       with the other keys.  Any pre-existing bootptab file  fulfills
 this requirement.

       When  the  server  tries to match a data group (partially)
       keyed by ht - ha to a specific client,  it  normally  uses
       the client's hardware type and hardware address as sent in
       the htype and chaddr fields.  DHCP clients may  choose  to
       identify  themselves  by  the  so-called client identifier
       option, which they explicitly send to the server.  In this
       instance,  the  server  tries  to  match  to  a key in the
       database by using the client identifier in  place  of  the
       hardware  address  and  using  zero  for  the  type.  DHCP
       clients that choose to use this mechanism must do so  consistently,
  and  the  data  sent  must constitute a unique

       The client class (ct) is typically a  string  categorizing
       clients  having  attributes  in  common,  such  as the CPU
       architecture/operating  system  pair.   Clients   identify
       themselves  as  belonging to a particular class by sending
       this data to the server.  A data group in the dhcpcap file
       is  considered  keyed with the class in either of the following
 ways: Explicitly by the  presence  of  ct  and  its
       value  Implicitly  by the data group containing data items
       that are specific to a particular vendor

       It is illegal for a data group to contain data  items  for
       two or more vendors (though it is permissible for standard
       tags to be combined with vendor tags).  It is also illegal
       for  a  data group keyed to a specific class to refer to a
       data group of a different  class  with  tc.   Combinations
       missing  in  the  list  are  redundant:  for instance, the
       client ID always implies a  particular  vendor  class,  so
       there  is  no need for a hash having that pair as its key.
       If the data group contains tags  that  over-determine  the
       key, the extraneous tags are ignored.

       In  addition  to  the internal tables, another table whose
       purpose is different is formed by a hash on the label.  It
       allows  a  convenient  shorthand  by  grouping  subsets of
       parameters together and referencing them  as  an  ensemble
       with the reference tag, tc.  There may be more than one tc
       tag in  a  data  group,  and  when  encountered  they  are
       resolved.   However,  parameters that are explicitly named
       always take precedence over those implied by  tc,  regardless
  of their order within an entry.  If two or more continuation
 tags are found, values resolved from  the  first
       named  entity  take  precedence.  The converse is true for
       other tags: if the same parameter  is  tagged  twice,  the
       last value is chosen.

       Sometimes  it  is necessary to delete a specific tag after
       it has been implied by tc.  This can  be  done  using  the
       construction  tag @, which removes the effect of tag.  For
       example, to completely undo an IEN-116 name server  specification,
 use :ns@: at an appropriate place in the configuration
 entry.  After removal with @, a  tag  can  be  set
       again through the tc mechanism.

       The  remaining tags that imply special logic are described
       as follows:

       The hd (home directory) and bf (bootfile) tags  are  ASCII
       strings.   The  client's  request and the values of the hd
       and bf symbols determine how the server fills in the  file
       field of the DHCP/BOOTP reply packet.

       If  the client specifies an absolute pathname and the file
       exists on the server machine, that pathname is returned in
       the  reply  packet.  If the file cannot be found, no value
       is returned.  If the client specifies a relative pathname,
       a  full  pathname is formed by prepending the value of the
       hd tag.  If the hd tag is not supplied in  the  configuration
 file, no value is returned.

       If  the  client  sends a null value in the file field, the
       exact reply depends upon the hd and bf tags.   If  the  bf
       tag gives an absolute pathname, that pathname is returned.
       Otherwise, if the hd  and  bf  tags  together  specify  an
       accessible  file,  that filename is returned in the reply.
       If a complete filename cannot be determined  or  the  file
       does  not  exist,  the  file  field  in the reply contains

       All filenames are first  tried  as  filename.hostname  and
       then  as filename, providing for individual per-host bootfiles.
  The following table  summarizes  these  possibilities:

       hd tag   bf tag   Received File   Returned File
       any      any      /c              /c
       /a       any      /c              /a/c
       any      /b       null            /b
       /a       /b       null            /a/b

       In  all  these cases, existence of the file means that, in
       addition to actually being present, the file must have its
       public  read  access  bit  set,  since this is required by
       tftpd(8) to permit the file transfer.   (For  other  tftpd
       file access restrictions, see tftp(1).)

       Some  versions  of  tftpd  provide  a  security feature to
       change the root directory using the chroot(2) system call.
       You  can use the td tag to inform the joind daemon of this
       special root directory used by the tftpd daemon.   The  hd
       tag is specified relative to any such root directory.  For
       example, if the real absolute path to the  client's  bootfile
  is  /tftpboot/bootfiles/bootimage,  and  tftpd  uses
       /tftpboot as its secure directory, specify  the  following
       line in the bootptab file:


       If the bootfile is located in the /tftpboot directory, use
       following line in the bootptab file:


       You can use the sa tag to specify the IP  address  of  the
       particular  TFTP  server  the  client  is  to use.  In the
       absence of this tag, joind tells  the  client  to  perform
       TFTP to the same machine on which the joind daemon is running.

       Three options, bs, to, and vm, permit the  special  string
       auto to be used as their value string.

       The bootfile size (bs) is a decimal, octal, or hexadecimal
       integer specifying the size of the bootfile  in  512-octet
       blocks.  If  the  keyword  auto  is  specified, the server
       should consult the file system to determine  the  size  of
       the  boot image.  This assumes that the server is also the
       TFTP host for the client's boot image.  As with  the  time
       offset,  specifying  the  bs tag as a Boolean has the same
       effect as specifying auto as its value.

       The time offset (to) is a signed decimal integer  specifying
 the client's time zone offset in seconds from UTC.  If
       the keyword auto is specified, the client should  use  the
       server's  time zone offset.  Specifying the to symbol as a
       Boolean has the same effect  as  specifying  auto  as  its

       The vendor magic cookie selector (vm) tells the server the
       style  of  option-encoding  that  the  client  wishes   to
       receive.   The tag can take one of the following keywords:
       Indicates that vendor information  is  determined  by  the
       client's   request.    Always   forces   an  RFC  1048/RFC
       1033-style reply.   DHCP  clients  must  always  send  the
       rfc1048  cookie  or they will be treated as BOOTP clients.
       Always forces a CMU-style reply.

       The encoding chosen is based primarily on the value of the
       magic cookie in the options field of the BOOTPREQUEST from
       the client.  If it is present, the magic  cookie  must  be
       either  the  rfc1048  cookie  or  the cmu cookie.  If this
       cookie is not present, the server determines the  encoding
       from the value of vm.

       The  following  table  summarizes  the possibilities. None
       means that although the vendor field is  empty,  the  file
       and  sname  fields  are  returned  with  the  client's  IP
                                     bootptab file
               bootprequest    none     rfc1048  cmu      auto
               ------------    -------------------------------

               unrecognized    none     rfc1048  cmu      none
               rfc1048         rfc1048  rfc1048  rfc1048  rfc1048
               cmu             cmu      cmu      cmu      cmu

       The  remaining  tags  describe actual client configuration
       data.  The bw, bx, cs, ds, gw, im, lg, lp, ns, nt, ra, rl,
       sr,  ts,  xd, and xs tags take a whitespace-separated list
       of IP addresses or hostnames, while the ba,  ip,  sa,  si,
       sm,  and  sw tags each take a single IP address. The legal
       formats that may be used for character string  representations
   of   IP  addresses  are  described  in  join.ipaddresses(4).

       When a host name is specified instead of  an  IP  address,
       the  joind  daemon looks up the IP addresses for that host
       name using the gethostbyname routine.  If the  ip  tag  is
       not  specified, the joind daemon determines the IP address
       using the entry name as the host name.  (Dummy entries use
       an invalid host name to avoid automatic IP lookup.)

       Since  the  gw  tag  is an extendible tagged subfield, you
       must also specify the vm=rfc1048 tag in order to pass  the
       information  to  the client in an appropriate RFC 1048/RFC
       1033-style reply.

   BOOTP Semantics    [Toc]    [Back]
       For BOOTP usage, the label in the general file  format  is
       hostname,  the name of a BOOTP client.  Dummy entries have
       an invalid host name (one with a period (.) as  the  first
       character)  and are used to provide default values used by
       other entries through the tc=.dummy-entry mechanism.   The
       recognized  BOOTP tags are as follows: Boot file Boot file
       size (512 octet  blocks)  Cookie  servers  Dump  file  DNS
       domain  name  Domain name servers Encapsulate flavor Gateways
 (IP rosters) Hardware  address  Home  directory  Send
       host name Hardware type Impress servers Host or network IP
       address Log servers LPR servers IEN-116 name servers Reply
       address  override  Resource location protocol servers Root
       path TFTP server address (used  by  clients)  Subnet  mask
       (host)  Swap server address Template host (points to similar
 host entry) TFTP root directory (used by  secure  TFTP
       server)  Time  offset  (seconds) Time servers Vendor magic
       cookie selector

EXAMPLES    [Toc]    [Back]

       The following bootptab example is for a BOOTP server  that
       supports   remote   installation  service  (RIS)  clients:
 ip=  keewee:tc=.ris71.alpha:ht=ether-

       net:gw=\ ip=  turtle:tc=.ris71.alpha:ht=ether-

       net:gw=\       ip=
 ip=  isaiah:tc=.ris71.alpha:ht=ether-

       net:gw=\  ip=  You
       can use the /usr/sbin/ris utility to install software subsets
 onto a RIS server and also to manage the clients that
       can  load  software  from  the RIS server. The ris utility
       automatically adds, modifies, or deletes  entries  in  the
       bootptab  file  as  necessary.  See  Sharing Software on a
       Local Area Network and the Installation Guide --  Advanced
       Topics for more information about configuring RIS.

       The  following  bootptab  example  is  for  a DHCP server:
       admin:\           :tc=coop:\           :sm=\
             :sl:\         :lt=86400:   legal:\        :tc=coop:\
             :sl:\         :lt=21600:\         :sm=
       egghead:\          :ha=0203040506aa:\          :tc=admin:\
             :lt=12600:      coop:\             :sm=\
             :hn:\         :ms:\        :lt=43200:  bantam2dhcp:\
             :nw=\         :dn=delmonicos-eggs.com:\
             :ds=           \
             :gw=        \
             :sm=\                   :yd=bantamYP:\
             :ys=           \
       bantamdhcp:\       :nw=\       :dn=delmonicoseggs.com:\
             :gw=          \
             :sm=\               :bw=\           :yd=bantamYP:\
             :ys=\ You can configure a
       DHCP server and manage its  associated  clients  with  the
       xjoin  utility,  which  automatically  adds,  modifies, or
       deletes entries in the bootptab  file  as  necessary.  See
       xjoin(8)  and Network Administration: Connections for more

FILES    [Toc]    [Back]



       Daemons: joind(8), tftpd(8)

       Files: dhcptags(4)

       DARPA Internet Request  For  Comments:  DHCP  Options  and
       BOOTP  Vendor Extensions (RFC 1533), Dynamic Host Configuration
 Protocol (RFC 1541) delim off

[ Back ]
 Similar pages
Name OS Title
dhcptags Tru64 DHCP and BOOTP server database
joind Tru64 BOOTP and DHCP server daemon
server.pcy Tru64 BOOTP and DHCP server policy
netmasks Tru64 DHCP server database
namepool Tru64 DHCP server database
nets Tru64 JOIN DHCP server database
client.pcy Tru64 BOOTP and DHCP client policy
bootpquery HP-UX send BOOTREQUEST to BOOTP server
bootpd Tru64 Internet Boot Protocol (BOOTP) server
dhcpdb IRIX DHCP database manager
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service