Commit ceb15098 authored by Robert Ricci's avatar Robert Ricci
Browse files

Added some new text about setting up named.

parent f0920a6f
......@@ -140,7 +140,71 @@ up, copy root's public identity from boss (created by the boss-install script)
to ops's authorized_keys file:
scp /root/.ssh/ ops:/root/.ssh/authorized_keys
##### Step 6 - Other miscellaneous things to set up
##### Step 6 - Setting up named
The testbed software manipulates DNS zone files for two reasons. First, it
adds your nodes to them so that you don't have to. Second, it creates CNAMEs
for all the nodes in every experiment. (so that you can use, for example,
'' to refer to your node regardless of which
physical node it got mapped to.)
The named_setup script does this by generating zone files - in general, it
concatenates a '.head' file, written by you, with it's own generated entries.
The main zone file is /etc/namedb/OURDOMAIN.db, where OURDOMAIN is from your
defs file. (OURDOMAIN, unless explicitly specified, is taken to be the domain
portion of BOSSNODE.) We also generate reverse zone files (for inverse
lookups, ie. turning IP addresses back into names) in
/etc/named/reverse/SUBNET.db, where SUBNET is the the class-C subnet in which
the addresses reside (ie. 10.0.0.db).
You'll need to create these .head files yourself. The easiest way to do this
is to start with the examples we've provided in this directory: - the forward zone file
example-155.101.128.db.head - a reverse zone file
If you have more than one class-C subnet for your testbed, you'll need a copy
of the reverse zone file for each one. Follow the examples in these .head
files, making sure to get boss, ops, and any 'infrastructure' equipment (such
as routers and switches) into the zone files. These zone files do not need to
include the nodes - the nodes will be added to them automatically.
Now edit /etc/namedb/named.conf, and add an entry like this for the forward
zone "" in {
type master;
file "";
And one of these for each reverse subnet:
zone "" in {
type master;
file "reverse/155.101.128.db";
Once you think you've got things set up, run /usr/testbed/sbin/named_setup,
and make sure that it doesn't give you any error messages.
##### If you are using unroutable private IP addresses for part of the
In order to handle this situation, we'll need to use a feature of bind called
`views` so that the private addresses are only exposed to clients within the
testbed. See the bind documentation for more details on this feature. Note
that you'll want to make sure that loopback queries from boss itself see the
internal view - you want boss to resolve its own hostname to its private
address, not its public one.
In order to use multiple views, we generate multiple zone files. In addition
to OURDOMAIN.db, which will be used for the 'external' view, we create
OURDOMAIN.internal.db for use with the 'internal' view. So, you'll also need
to create OURDOMAIN.internal.db.head . When we generate the zone files, only
publicly-routable addresses are put into OURDOMAIN.db .
OURDOMAIN.internal.db contains all addresses, both public and private. So,
basically, you'll want to put the public addresses for boss, ops, etc. into
OURDOMAIN.db.head, and their private addresses into
OURDOMAIN.internal.db.head .
##### Step 7 - Other miscellaneous things to set up
There are a few things we haven't been able to completely automate just yet,
though we hope to soon.
......@@ -187,7 +251,7 @@ disk images - You'll also, of course, need disk images to go on your nodes.
Right now, we have no automatic way of generating these, so you'll have to ask
Utah for some.
##### Step 7 - Filling the database
##### Step 8 - Filling the database
See the file setup-db.txt in this directory for instructions on getting the
proper information about your site and nodes into the database.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment