 HTE:
Host Table Editor
Daniel Speers
Many years ago, I worked for a large trading firm in New York
with about 100 different networks spanning 12 offices around the
United States and a few in other countries. The network subnets
were grouped by DNS domains and managed by several different systems
administrators. IP addresses were managed in a central host table
and in DNS zone files, all on one master server. This created several
problems, not the least of which was keeping the /etc/hosts file
and the DNS zone files in sync.
Other problems involved the security of different people editing
these tables, keeping track of what addresses were really in use,
and what devices were using those addresses. We also had reserved
addresses. This typically meant that the first 20 addresses on a
subnet were for network devices, and the following 10 were for DHCP-assigned
addresses.
The idea to manage the host table in a database evolved from these
problems. From this database, we could generate a proper /etc/hosts
file, DNS configuration and zone files, and the DHCP config files.
Address space could be reserved, and permissions assigned to each
admin for their assigned networks. One other critical tool that
helped ensure the accuracy of the host table was an IP discovery
program that regularly checked each address to see whether it was
in use, and by what type of device.
This article focuses on the host table editor. Apart from the
main requirement of solving the problems mentioned above, the users
of HTE had their own ideas about how it would work, ideas that were
often at odds with each other. Some wanted an interactive-style
program, while others preferred it to be command-line driven so
that scripts could be written around it. Therefore, I made the interface
work both ways. The same hierarchical command structure can be called
from the command line to make scripting easy.
Introducing HTE
Host Table Editor (HTE), available for download at http://www.samag.com/code/,
is a Perl program that manages a database of DNS information. See
the sidebar for a summary of HTE files available with the code.
The HTE system provides a uniform interface for entering DNS data
and generating DNS-related configuration files.
The advantages of storing Hostname, IP address, DNS, and DHCP
information in a database system such as HTE include:
- Centralized control — It allows administrators to keep
track of all host, IP address, DNS, and DHCP information in one
common database.
- Security — By using a database, remote admins can access
the host table data without requiring root access to the master
servers that host DNS and/or DHCP maps.
- Error checking — Data input rules and automated building
of host table, DHCP, and DNS configuration files helps ensure
syntactic accuracy.
- Uniform updates — By using a single system and database,
the data and the format of the automatically created files will
remain neat and consistent.
- Single source (only have to enter the data once) — This
eliminates the need to manage separate host table, DNS, and DHCP
configuration files, which can often reside on multiple servers.
- Automatic file generation — In a shop where several servers
are used to manage the network, changes will be propagated properly
without the need for manual intervention.
Some possible disadvantages to this HTE program may have to do
with unique or special needs of your environment. For example, the
configuration files that are built were designed for use with standard
DNS or DHCP servers on Unix-based systems. Where third party server
software is used, these files may not work, or there may be a number
of required options that are not supported.
This article describes how to set up HTE, how to enter DNS information
into the HTE database, and how to use HTE to automatically generate
host files, DNS zone files, and DHCP configuration files.
Installing HTE
You will need a current version of MySQL and Perl. If you plan
to run a DNS server, HTE was built with Bind 9.2.1, however, newer
and older versions may work just as well. (Keeping Bind up-to-date
is recommended.) Install the following Perl modules from CPAN: Term::Readline::Gnu,
DBI, DBD::MySQL, Getopt::Long, Config::Simple, Data::Dumper, and
Net::Netmask. The Net::Netmask module (by David Muir Sharnoff) provides
HTE the ability to keep your network structured. You may also want
to install MySQLCC to simplify database administration.
Unpack the HTE kit in a temporary directory and install it with
the following commands:
perl Makefile.PL
make
make test
make install
Create a MySQL database to store the host table data using a suitable
name such as “hosts”. Then, while still in the directory
into which you unpacked the HTE kit, run the following command to
initialize the database with a MySQL account that has create privileges:
mysql -u admin -p hosts < hte.sql
You then must create user accounts in MySQL. Begin with an account
with a name like “build” with SELECT only privileges. This
account will be used to create the hosts table, DNS, and DHCP files.
This may also be used to give average users read-only access to the
HTE editor.
Copy hte.conf to /etc/hte.conf and put the values for your database
and read-only user on the dsn, user, and pass lines.
Much of the security of the system is managed by the database.
If you want to specify sets of users who can create networks and
those who add and delete host table entries, provide different permissions
in your grant statements. For example, a MySQL account for Super_Admin
can be created with SELECT, INSERT, UPDATE, and DELETE on all tables
in the hosts database.
Super_Admin can create network definitions, DNS zones, and host
table entries. Joe_Admin, who is only allowed to create host table
entries, should have SELECT on all tables, and INSERT, UPDATE, and
DELETE on just the hosts table. Network_Guy will have INSERT, UPDATE,
and DELETE permissions on hosts and networks. You may not want Joe_Admin
to delete addresses once they are created, so only give INSERT and
UPDATE permissions. The editperms and glue tables are reserved to
manage HTE and should be read-only for all users. The htevars table
is where user-defined preferences are stored. If you want to allow
your users to save their preferences, make sure they can INSERT,
UPDATE, and DELETE. Thus, the permission schemes can be provisioned
in the manner most appropriate for your shop.
To simplify using HTE, add the HTE_USER environment variable to
your .cshrc or .bash_profile. You may also want to set HTE_PASS,
though it’s not recommended if security is a concern. HTE will
prompt you for a password if HTE_USER is set and HTE_PASS isn’t.
Take a Look Around
Get familiar with the interface. The command levels can be stepped
into one at a time, or chained together to jump to the desired level
or invoke a desired command. For example, if you type “show”
by itself, you will be at the show prompt and can then type any
sub-level command.
bash $> hte
hte > show
show > ip 192.168.254.12
or:
bash $> hte
hte > show ip 192.168.254.12
or, from the command line:
bash $> hte show ip 192.168.254.12
When you use commands from the command line, interactive mode is disabled.
The only exception is when you create something, you will be placed
into the entry editor to modify the values of the newly created item.
You can also skip the editor by adding a set value command. For example:
bash $> hte create zone fred.com set nameserver ns.myisp.com
Once created, editing the zone from the command line is done the same
way:
bash $> hte edit zone fred.com set nameserver ns.myisp.com
Typing help at any prompt will show the entire command tree
from that level down. The command-line version is --help. As
you can see, the interface is quite flexible.
Building Your Network
If you are going to use DNS, you will want to start by creating
your DNS zones. Create your zone records and make sure you set the
nameserver and SOA fields to the right values for your setup:
bash $> hte create zone fred.com set nameserver ns.myisp.com
bash $> hte edit zone fred.com set SOA master.fred.com
Now create at least one network to get started. The networks are created
using the CIDR format, which is common. When you edit or show a network,
leave off the /bits value at the end:
bash $> hte
hte $> create network 192.168.101.0/24
Network created.
description :
network_address: 192.168.101.0
bits : 24
create_date : 20030531204143
creator : dspeers
dns_id : []
group_id :
location :
edit network>
Type help to see what you can do in the edit mode and to see
which fields are read-only.
You will first describe your new network to make it different
from all the other networks. The set command takes the field
name you want to set as its first argument. Everything that follows
is the value:
set description My own private network
Typing sh at the edit network> prompt will redisplay
the record with your new description.
Next, place this network in the DNS zone you created earlier.
The DNS zone is assigned using the dns_id field. Notice how the
dns_id field has square brackets in it, because it is a lookup field.
If you try to assign any value that is not a valid key or a complete
value in the lookup table, the possible values will be listed, using
your argument as a filter:
edit network> set dns_id fred
The following are valid for dns_id (Filter: fred)
1 => fred.com
edit network> set dns_id 1
In the above example, “fred” was not a valid value for the
dns_id field. In such a case, the program will use that invalid value
as search criteria to find possible matches in the zone table. Each
matching item is listed by a number that can be used to set the dns_id
field. In this example, by setting dns_id to 1, the fred.com zone
was assigned. It is also valid to set the name to an exact match in
the zone table:
edit network> set dns_id fred.com
Once you have made your changes, press “Enter” once to leave
this level. The program will notice that you made changes and ask
you whether you want to save them. Congratulations! You have created
your first network. Look at your new network:
hte > show network 192.168.101.0
description => My own private network
network_address => 192.168.101.0
bits => 24
create_date => 20030604135652
creator => dspeers
dns_id => [fred.com]
location =>
Create a Host Table Entry
Creating a host table entry is done in the same way as creating
a network, which must already exist. HTE will already know to which
network the address belongs.
hte > create ip 192.168.101.10
Address created.
description =>
host_name =>
ip_address => 192.168.101.10
aliases =>
create_date => 20030531220751
creator => dspeers
device_id =>
last_seen =>
status_id => [assigned]
edit host>
The only other field that must be set is the host_name. The status_id
field is used to help provide guidance to other admins on which addresses
are in use, available, or reserved for future use.
Building the Host Table
Building a host table is as easy as typing “build host table”.
The table will be grouped by network to keep it looking neat:
###########################################
#
# Network : 192.168.101.0/24 Mask: 255.255.255.0
# Location : My House Domain: fred.com
# Description: Middle Earth
#
192.168.101.10 bilbo # Dan's server
192.168.101.11 frodo # File Server
192.168.101.12 epson # My Printer
You can capture the output in traditional Unix fashion by redirecting
the output to /etc/hosts, or by setting the output variable:
hte> build host
host > set output /etc/hosts
Building the DNS Maps
The host table editor will create both the named.conf file and
the individual zone files. Often the named.conf file will need more
options than the Host Table Editor will support. Your shop may also
have things that you don’t want the Host Table Editor to manage
for you, or other configuration settings you want to set. The best
practice is put your standard options in /etc/named.conf and use
an include file command to reference the Host Table Editor portions.
To do this, you have the Host Table Editor output its master DNS
configuration data to a file named /etc/named.auto, which would
look something like this in your /etc/named.conf file:
options {
directory "/var/named";
}
include "/etc/named.auto";
The default settings for the build dns maps command will create
the /etc/named.auto file and will put the zone files in the /var/named
directory. You must add the include statement to your /etc/named.conf
file.
The settings that determine where the files are saved can be changed
in interactive mode at the build dns level:
hte > build dns
dns > vars
config => /etc/named.auto
dir => /var/named
verify => /usr/sbin/named-checkzone
dns > set dir /var/named.d
If you have a current version of Bind installed, it comes with a helper
program to verify the format of the zone files. It will run as each
zone file is created.
Here is a practical example of how all these pieces of DNS will
fit together. Say you had a DNS domain called “myplace.com”
and in that network is a machine called foobar with the IP address
of 192.168.200.37. Your DNS server will live on a box called ns.myplace.com
and have an address of 192.168.200.5.
To begin, create your DNS zone:
hte > create zone myplace.com set nameserver ns.myplace.com
hte > edit zone myplace.com set SOA ns.myplace.com
Then, define the network where your hosts will live:
hte > create network 192.168.200.0/24 set dns_id myplace.com
Next, add the hostnames to the network:
hte > create ip 192.168.200.5 set host_name ns
hte > create ip 192.168.200.37 set host_name foobar
There may also be extra records you need in a zone file. For example,
you may want to define an alias for foobar and have it also known
as www.myplace.com. You may also want to define how email gets to
your mailserver. These are accomplished with the create zone_record
command. It takes no arguments and will allow a variety of record
types, including MX records to extra CNAME entries. A typical addition
of an MX record to handle mail will look like this:
hte > create zone_record
Zone entry created.
address =>
dns_id => []
entry_id => 3
priority => 0
record => IN
target =>
type => []
edit zone_entries> set address myplace.com.
edit zone_entries> set dns_id myplace.com
edit zone_entries> set target foobar
edit zone entries> set priority 10
edit zone_entries> set type MX
This MX record will allow mail bound for myplace.com to be handled
by foobar.myplace.com. Note the period at the end of the “set
address” line. Anytime you set the address or target fields to
a fully qualified domain name instead of just a hostname, you must
include the period to make sure the nameserver doesn’t automatically
add the local domain name for you.
To make people think that foobar also goes by the name of www.myplace.com,
you could create another zone record using the CNAME type using
these settings:
edit zone_entries> set address www
edit zone_entries> set dns_id myplace.com
edit zone_entries> set target foobar
edit zone_entries> set type CNAME
And the last step will create the DNS maps:
hte > build dns maps
The named.auto file will look something like this:
zone "myplace.com"{
type master;
file "myplace.com.zone";
};
zone "254.168.200.in-addr.arpa"{
type master;
file "254.168.200.in-addr.arpa.zone";
};
The myplace.com zone file may look a bit cryptic, which is why you
wanted a program like the Host Table Editor to make it for you:
;Zone built by HTE
$TTL 86400
@ IN SOA ns.myplace.com root.localhost (
11 ; serial
28800 ; refresh
7200 ; retry
604800 ; expire
86400 ; ttl
)
@ IN NS ns.myplace.com
myplace.com IN MX 10 foobar
www IN CNAME foobar
ns IN A 192.168.200.5
foobar IN A 192.168.200.37
Building DHCP Config Files
DHCP has become a required service as the popularity of wireless
networks increases. Automatically creating the configuration for
DHCP is a natural extension of the Host Table Editor. In just a
couple of easy steps, your DHCP server will be ready to go.
To keep things simple, a DHCP entry is associated with a network.
The network records already know things like the netmask and DNS
domain name, so the only required step is to define the range of
IP addresses that will be available for DHCP clients to borrow (or
lease in DHCP terms), which is done by giving the starting and ending
address range for the desired network.
hte > edit dhcp 192.l68.254.0 set range 192.168.254.100 192.168.254.120
DHCP as a protocol supports a number of optional convenience features
to help the weary transient user navigate around your network. These
include things like the address of the router to use to get off the
local network, and address of your DNS server:
hte > edit dhcp 192.168.254.0 set router 192.168.254.1
Many of the options you could provide depend largely on how your DHCP
clients are configured and the services your network offers. For example,
say your network has an NTP (Network Time Protocol) server to set
your workstation clock against. You would set the ntp-servers option:
hte > edit dhcp 192.168.254.0 set ntp-servers 192.168.254.1
For a list of valid options, see the dhcpd-options manual page that
comes with the ISC DHCP client or the IETF draft on DHCP agent options
at http://www.ietf.org.
Last, to build the dhcpd.auto configuration file, type “build
dhcp” at the hte> prompt. Here you can set the global
options of max-lease-time and default-least-time by using the set
command. The default values will be sufficient for most sites:
hte > build dhcp conf
Building dhcpd.auto file...
'192.168.254.0/24'
Done.
Here is what the resulting dhcpd.auto file will look like:
subnet 192.168.254.0 netmask 255.255.255.0 {
default-lease-time 21600;
max-lease-time 43200;
option subnet-mask 255.255.255.0;
option domain-name "myplace.com";
range dynamic-bootp 192.168.254.10 192.168.254.20;
option routers 192.168.254.1;
}
You will use an include statement in /etc/dhcpd.conf just same way
we did for /etc/named.conf, which will set a variety of static and
default options for your DHCP server.
Summary and Future Features
By now you have created DNS zones, networks, and host table entries.
You now have effective ways to manage access to the host table,
and automated ways to build your /etc/hosts file, DNS, and DHCP
configuration files. This should dramatically simplify the way you
manage your network addresses, improve security, and will keep all
addresses and related configuration files in sync.
At this point, will want to create a crontab entry to build the
various configuration files on a regular basis. An example contrab
entry looks like this:
0 * * * * /usr/bin/hte build host table;/usr/bin/hte build \
dns maps;/usr/bin/hte build dhcp conf
Some issues in how you manage your network remain, such as how to
know when an address is no longer in use, or whether one has been
taken without being allocated in the database. You may also want to
know what kind of devices are using those addresses. These features
are planned for in an add-on program called ip-discover that may be
available by the time you read this. In the original system, ip-discover
used both icmp requests and SNMP gets to determine which addresses
were in use and what was using them.
Dan Speers has been in the technology industry for 17 years
and is currently a Professional Services Engineer with VA Software.
He has been a Linux user since kernel 0.98. At every opportunity,
he helps promote the use of open source software in roles traditionally
filled by commercial products.
| 
