SECONDARIES

This file describes what you have to do to run a secondary copy of the
RIPE database.

First of all you have to make a choice: do you want to run a copy of
the RIPE database where the database is one big file, or do you want
to run this in so-called "SPLIT" mode. If you run in split mode, every
object type has its own file (available from
ftp://ftp.ripe.net/ripe/dbase/split/) and in normal mode, all objects
are in one big file (ftp://ftp.ripe.net/ripe/dbase/ripe.db)

If you decide to run this in "split" mode, see below what you have to
do to get a secondary copy running. If you are NOT running in split
mode, see at B what to do.

A For a SPLIT RIPE database:

Make sure you have something like the following in your config
for this secondary copy:

DBFILE  RIPE    /wherever/it/is/ripe.db         SPLIT

As you notice the config file only knows about the basename of the
database file, it does not know about all the split files. The fact
that the third argument SPLIT is there will take care of that.

The filename mentioned here should be the path name where the real
database will be. During indexing of a new version you will need a
temporary directory.

Transfer all split files with the 2 letter short format extension from
ftp.ripe.net and put them in a temporary directory (make sure you have
enough space for database files and indexes). The files must be the
files that end in the two letter short format for the objects that are
in the file, ie use ripe.db.in and NOT ripe.db.inetnum.

Now, for each of the split database files in the temporary directory
you say: 

netdbm filename

You can specify the -V option if you want to see what netdbm is doing.

Then, for database files that contain IP addresses as keys
(specifically ripe.db.in and ripe.db.ir, for inetnum and inet-rtr
objects) you will have to run a classless index after the normal
index:

netdbm -c -p ripe.db.in
netdbm -c ripe.db.ir

Again here you can specify the -V option. If the ripe.db.ir is getting
big (which it is not now) you may want to specify the -p option for
that database as well. See the netdbm manual page for more details on
what -p does.

Next, you remove all old database information (the database files and
their indexes) and copy all of the newly generated files and indexes
to the place you specified in the configuration file. If you already
have a running whoisd, this will pick up the new files and indexes
automatically. If not, you can fire off a whoisd.

You now have a running secondary copy of the RIPE database.



B For NON SPLIT RIPE database

Make sure you have something like the following in your config
for this secondary copy:

DBFILE  RIPE    /wherever/it/is/ripe.db

The filename mentioned here should be the path name where the real
database will be. During indexing of a new version you will need a
temporary directory.

Transfer the complete RIPE database from ftp.ripe.net and put it in a
temporary directory. Go to that directory and say:

netdbm ripe.db
netdbm -c -p ripe.db

You can use a -V flag for both to see what netdbm is doing.

The first netdbm run will do a normal index of the database. Depending
on your machine you run this on this could take an hour or more. The
second index will do the classless index (primed, see netdbm manual
page for details) and will probably take something like an hour as
well. I know this is slow, but a fast machine (SPARC 5,10,20 or
equivalent) can make quite an improvement. 

Now you will see that netdbm has created a lot of index files in the
temporary directory.

Next, remove the current ripe.db and all index files, and copy all
these newly generated files into the place you specified in the
configuration. 

Now you can start a whoisd and your secondary database is running. If
you already have a whoisd running, it will automatically see the new
database file and indexes.
