Info about freeradius RPs and trustourter
authorSam Hartman <hartmans@debian.org>
Tue, 7 Jan 2014 20:57:46 +0000 (15:57 -0500)
committerSam Hartman <hartmans@debian.org>
Tue, 7 Jan 2014 20:57:46 +0000 (15:57 -0500)
trustrouterinfo.mdwn

index 93938fb..c1e0da7 100644 (file)
@@ -8,14 +8,14 @@ git clone --recursive git://git.project-moonshot.org/moonshot.git
 
 The Trust Router depends on MIT Kerberos, OpenSSL, jansson and SQLite Version 3.  The dependencies for freeradius are discussed in the freeradius documentation.
 
 
 The Trust Router depends on MIT Kerberos, OpenSSL, jansson and SQLite Version 3.  The dependencies for freeradius are discussed in the freeradius documentation.
 
-To build and install a Trust Router, you need to separately 'make' and 'make install' in both the moonshot/trust_router and moonshot/freeradius-server directories, in that order.
+To build and install a Trust Router, you need to separately 'make' and 'make install' in both the moonshot/trust_router and moonshot/freeradius-server directories, in that order.  The Moonshot Debian repositories include a moonshot-trust-router package and a freeradius package with Trust Router integration.  The Centos repository includes trust router packages but not Freeradius packages.
 
 <h2>CONFIGURING A TRUST ROUTER</h2>
 
 In addition to having a valid freeradius TLS/PSK configuration, a set of Trust Router and TID-specific configuration is required in order to use the Trust Router.
 
 The Trust Router reads its configuration from a set of JSON configuration files (anything with a .cfg file extension) in the directory from which it is run.  These files can be generated by the
 
 <h2>CONFIGURING A TRUST ROUTER</h2>
 
 In addition to having a valid freeradius TLS/PSK configuration, a set of Trust Router and TID-specific configuration is required in order to use the Trust Router.
 
 The Trust Router reads its configuration from a set of JSON configuration files (anything with a .cfg file extension) in the directory from which it is run.  These files can be generated by the
-Moonshot Management Portal or configured by hand.
+Moonshot Management Portal or configured by hand.  An example is found in the tr/portal.cfg and tr/manual.cfg files  in the trust_router sources.  Both files are needed.
 
 The TIDC also requires specific configuration in the freeradius raddb/mods-available/realm configuration file.  Three new parameters have been added to the realm configuration: a default community (default_community), an RP realm (rp_realm) and a trust router (trust_router).  The default community will be used when no community is specified in a AAA request (over-riding on a per-request basis is TBD).  The RP realm is used in all TID requests from this proxy, and the trust_router is the IP address to which those requests will be sent.
 
 
 The TIDC also requires specific configuration in the freeradius raddb/mods-available/realm configuration file.  Three new parameters have been added to the realm configuration: a default community (default_community), an RP realm (rp_realm) and a trust router (trust_router).  The default community will be used when no community is specified in a AAA request (over-riding on a per-request basis is TBD).  The RP realm is used in all TID requests from this proxy, and the trust_router is the IP address to which those requests will be sent.
 
@@ -29,6 +29,8 @@ realm suffix {<br/>
         trust_router = "10.0.2.15"<br/>
 }
 
         trust_router = "10.0.2.15"<br/>
 }
 
+In addition, the Freeradius RP will need credentials with which to access the trust router.  These credentials can be installed using the moonshot-webp command run as the same user freeradius runs as.  On debian, this is "freerad".
+
 <h2>BRINGING UP/VERIFYING A TRUST ROUTER</h2>
 
 To run all of the components needed to test the Trust Router, you will need to have at least two different nodes (or VMs) at different IP addresses.
 <h2>BRINGING UP/VERIFYING A TRUST ROUTER</h2>
 
 To run all of the components needed to test the Trust Router, you will need to have at least two different nodes (or VMs) at different IP addresses.