Clean up README files. Mostly this means changing them to pointers to

the real consolidated documentation.

Delete old Doxygen-based rpkid manual and stuff that went with it,
while retaining ability to generate Doxygen manual of internals for
the libraries.

This closes #232.

svn path=/trunk/; revision=4424

1 files changed, 4 insertions, 142 deletions

diff --git a/rtr-origin/README b/rtr-origin/README
index aa8befd2..dae53010 100644
--- a/rtr-origin/README
+++ b/rtr-origin/README
@@ -2,148 +2,10 @@ $Id$
 
 Sample implementation of draft-ymbk-rpki-rtr-protocol.
 
-This depends on rcynic (../rcynic/) to collect and validate the RPKI
-data.  This program's job is to serve up that data in a lightweight
-format suitable for routers that want to do prefix origin
-authentication.
+See:
 
-To use this, you need to do two things beyond setting up rcynic:
+- The  primary documentation at http://trac.rpki.net/
 
-1) Add an invocation of this program in --cronjob mode to the cron job
-   you're already running to run rcynic.  In cronjob mode this program
-   needs write access to a directory where it can store pre-digested
-   versions of the data it pulls from rcynic.
+- The PDF manual in ../doc/manual.pdf, or
 
-   The program will create a collection of data files, as well as a
-   subdirectory in which each instance of the program running in
-   --server mode can write a PF_UNIX socket file.  At present, it
-   creates these files under the directory in which you run the program.
-
-   So if this script is installed in /usr/local/bin, rcynic writes its
-   data files under /var/rcynic/data/authenticated, and you want this
-   program to write its datafiles to /var/rpki-rtr, you'd add
-   something like the following to your cronjob:
-
-     cd /var/rpki-rtr
-     /usr/local/bin/rtr-origin --cronjob /var/rcynic/data/authenticated
-
-   You should make sure this program runs at least once before
-   attempting to configure --server mode.  Nothing terrible will
-   happen if you don't, but --server invocations started before the
-   first --cronjob run may behave oddly.
-
-2) You need to to set up a server listener that invokes this program
-   in --server mode.  What kind of server listener you set up depends
-   on which network protocol you're using to transport this protocol.
-   The specification says that the rpki-rtr protocol will run under
-   ssh, but not all clients support that yet.  rtr-origin doesn't
-   really care, it just reads from stdin and writes to stdout.
-
-   --server mode should be run as a non-privileged user (it is
-   read-only for a reason).  You may want to set up a separate UNIX
-   userid for this purpose so that you can give that user its own home
-   directory and ssh configuration files.
-
-   --server mode takes an optional argument specifying the path to its
-   data directory; if you omit this argument, it uses the directory in
-   in which you run it.
-
-   The details of how you set up a listener for this vary depending on
-   the network protocol and the operating system on which you run it.
-   Here are two examples, one for running under inetd, the other for
-   running under sshd.
-
-   Running under inetd with plain TCP is insecure and should only be
-   done for testing, but you can also run it with TCP-MD5 or TCP-AO,
-   or over IPsec.  The inetd configuration is generally the same, the
-   details of how you set up TCP-MD5, TCP-AO, or IPsec are platform
-   specific.
-
-   To run under inetd, you need to:
-
-   a) Add an entry to /etc/services defining a symbolic name for the
-      port, if one doesn't exist already.  At present there is no
-      well-known port defined for this protocol, for this example we'll
-      use port 42420 and the symbolic name rpki-rtr.
-
-	Add to /etc/services:
-
-	rpki-rtr          42420/tcp
-
-   b) Add the service line to /etc/inetd.conf:
-
-	rpki-rtr stream tcp nowait nobody /usr/local/bin/rtr-origin rtr-origin --server /var/rpki-rtr
-
-      This assumes that you want the server to run as user "nobody",
-      which is generally a safe choice, or you could create a new
-      non-priviledged user for this purpose.  DO NOT run the server as
-      root; it shouldn't do anything bad, but it's a network server
-      that does not need root access and therefore should not have it.
-
-   To run under sshd, you need to:
-
-   a) Decide whether to run a new instance of sshd on a separate port
-      or use the standard port.  The server doesn't care, but some
-      people seem to think that it's somehow more secure to run this
-      service on a different port.  Setting up sshd in general is
-      beyond the scope of this document, but most likely you can copy
-      the bulk of your configuration from the standard config.
-
-   b) Configure sshd to know about the rpki-rtr subsystem.  Add
-      something like this to your sshd.conf:
-
-	Subsystem rpki-rtr /usr/local/bin/rtr-origin
-
-   c) Configure the userid(s) you expect ssh clients to use to connect
-      to the server.  For operational use you almost certainly do NOT
-      want this user to have a normal shell, instead you should
-      configure its shell to be the server (/usr/local/bin/rtr-origin
-      or wherever you've installed it on your system) and its home
-      directory to be the rpki-rtr data directory (/var/rpki-rtr or
-      whatever you're using).  If you're using passwords to
-      authenticate instead of ssh keys (not recommended) you will
-      always need to set the password(s) here when configuring the
-      userid(s).
-
-   d) Configure the .ssh/authorized_keys file for your clients; if
-      you're using the example values given above, this would be
-      /var/rpki-rtr/.ssh/authorized_keys.  You can have multiple ssh
-      clients using different keys all logging in as the same ssh
-      user, you just have to list all of the ssh keys here.  You may
-      want to consider using a command= parameter in the key line (see
-      the sshd(8) man page) to lock down the ssh keys listed here so
-      that they can only be used to run the rpki-rtr service.
-
-      If you're running a separate sshd for this purpose, you might
-      also want to add an AuthorizedKeysFile entry pointing at this
-      authorized_keys file so that the server will only use this
-      authorized_keys file regardless of what other user accounts
-      might exist on the machine:
-
-	AuthorizedKeysFile /var/rpki-rtr/.ssh/authorized_keys
-
-   There's a sample sshd.conf in the source directory.  You will have
-   to modify it to suit your environment.  The most important part is
-   the Subsystem line, which runs the server.sh script as the
-   "rpki-rtr" service, as required by the protocol specification.
-
-   You can also run this code under xinetd, or the netpipes "faucet"
-   program, or stunnel...other than a few lines that might need
-   hacking to log the connection peer properly, the program really
-   doesn't care.
-
-   You, however, SHOULD care whether the channel you have chosen is
-   secure; it doesn't make a lot of sense to go to all the trouble of
-   checking RPKI data then let the bad guys feed bad data into your
-   routers anyway because you were running the rpki-rtr link over an
-   unsecured TCP connection.
-
-The program has two other modes, which might be useful for debugging:
-
-a) --client mode implements a dumb client program for this protocol,
-   over ssh, raw tcp, or by invoking --server mode directly in a
-   subprocess.  The output is not expected to be useful except for
-   debugging.
-
-b) --show mode will display a text dump of pre-digested data files in
-   the current directory.
+- The flat text page ../doc/doc.RPKI.RP.rpki-rtr