|
The network database consists of files describing machines known
to the local installation and machines known publicly. The files
comprise multi–line tuples made up of attribute/value pairs of
the form attr=value or sometimes just attr. Each line starting
without white space starts a new tuple. Lines starting with #
are comments. A value containing white spaces or # characters
must be quoted using " double quotes.
The file /lib/ndb/local is the root of the database. Other files
are included in the database if a tuple with an attribute–value
pair of attribute database and no value exists in /lib/ndb/local.
Within the database tuple, each pair with attribute file identifies
a file to be included in the database. The
files are searched in the order they appear. For example:
| |
database=
| |
file=/lib/ndb/common
file=/lib/ndb/local
file=/lib/ndb/global
|
|
declares the database to be composed of the three files /lib/ndb/common,
/lib/ndb/local, and /lib/ndb/global. By default, /lib/ndb/local
is searched before the others. However, /lib/ndb/local may be
included in the database to redefine its ordering.
Within tuples, pairs on the same line bind tighter than pairs
on different lines.
Programs search the database directly using the routines in ndb(2)
or indirectly using ndb/cs and ndb/dns (see ndb(8)). Both ndb/cs
and the routine ndbipinfo impose structure on the otherwise flat
database by using knowledge specific to the network. The internet
is made up of networks which can be subnetted
multiple times. A network must have an ipnet attribute and is
uniquely identified by the values of its ip and ipmask attributes.
If the ipmask is missing, the relevant Class A, B or C one is
used.
A search for an attribute associated with a network or host starts
at the lowest level, the entry for the host or network itself,
and works its way up, bit by bit, looking at entries for nets/subnets
that include the network or host. The search ends when the attribute
is found. For example, consider the following entries:
| |
ipnet=murray–hill ip=135.104.0.0 ipmask=255.255.0.0
| |
dns=135.104.10.1
ntp=ntp.cs.bell–labs.com
|
ipnet=plan9 ip=135.104.9.0 ipmask=255.255.255.0
| |
ntp=oncore.cs.bell–labs.com
smtp=smtp1.cs.bell–labs.com
|
ip=135.104.9.6 sys=anna dom=anna.cs.bell–labs.com
| |
smtp=smtp2.cs.bell–labs.com
|
|
Here anna is on the subnet plan9 which is in turn on the class
B net murray–hill. Assume that we're searching for anna's NTP and
SMTP servers. The search starts by looking for an entry with sys=anna.
We find the anna entry. Since it has an smtp=smtp2.cs.bell–labs.com
pair, we're done looking
for that attribute. To fulfill the NTP request, we continue by
looking for networks that include anna's IP address. We lop off
the right most one bit from anna's address and look for an ipnet=
entry with ip=135.104.9.4. Not finding one, we drop another bit
and look for an ipnet= entry with
ip=135.104.9.0. There is such an entry and it has the pair, ntp=oncore.cs.bell–labs.com,
ending our search.
Ndb/cs can be made to perform such network aware searches by using
metanames in the dialstring. A metaname is a $ followed by an
attribute name. Ndb/cs looks up the attribute relative to the
system it is running on. Thus, with the above example, if a program
called
| |
| |
dial("tcp!$smtp!smtp", 0, 0, 0);
|
|
the dial would connect to the SMTP port of smtp2.cs.bell–labs.com.
A number of attributes are meaningful to programs and thus reserved.
They are:
sys system name (a short name)
dom Internet fully–qualified domain name (without the trailing period)
ip Internet address, v4 or v6.
ipv6 IPv6 Internet address. For DNS, an AAAA record.
ipnet Internet network name
ipmask Internet network mask
ipgw Internet gateway (ip address)
ether Ethernet address (must be lower–case hex)
vendor Specific vendor attribute for dhcp and bootp
bootf file to download for initial bootstrap; /386/9bootpxe to
boot a PC via PXE.
tftp an TFTP server to use for PXE bootstrap
fs Plan 9 file server to be used
auth Plan 9 authentication server to be used
authdom Plan 9 authentication domain. To specify an authentication
server for a particular domain, add a tuple containing both auth
and authdom attributes and values.
rootpath the NFS root for unix machines
rootserver the NFS server used with rootpath
dnsdomain a domain name that ndb/dns adds onto any unrooted names
when doing a search. There may be multiple dnsdomain pairs.
dns a DNS server to use for resolving (for DNS and DHCP)
dot a DNS over TLS server to use for resolving (for DNS). If found,
dns entries are ignored.
ntp an NTP server to use (for DHCP)
smtp an SMTP server to use (for DHCP)
time a time server to use (for DHCP)
wins a Windows name server (for DHCP)
mx mail exchanger (for DNS and DHCP); also pref.
srv host name of service location (for DNS); also pri, weight and
port.
soa start of area (for DNS)
txt a descriptive text. For DNS, a TXT record.
txtrr obsolete, same as txt above.
caa certificate authority authorization (for DNS)
tcp a TCP service name
udp a UDP service name
port a TCP or UDP port number
restricted a TCP service that can be called only by ports numbered
less than 1024
proto a protocol supported by a host. The pair proto=il was needed
by cs (see ndb(8)) in tuples for hosts that supported the IL protocol
aanport a range of ports to restrict aan(8) listeners started by
incoming rcpu(1) connections to; in the form of aanport=low–high.
Single ports are also allowed, as well as multiple entries of
either kind.
Cs defers to dns to translate dotted names to IP addresses, only
consulting the database files if dns cannot translate the name.
Cs allows network entries with sys and dom attributes but no ip
attribute. Searches for the system name are resolved by looking
up the domain name with dns.
The file /lib/ndb/auth is used during authentication to decide
who has the power to `speak for' other users; see authsrv(6).
|