System Preparation

Install RHEL/CentOS/SL 6

The first thing that is required is a RHEL/CentOS/SL 6 machine - this can be physical or virtual.

Install

Configure CentOS 6

Next, there are a few CentOS configuration options that need to be set in advance.

Networking configuration

Trust Router

Firewall configuration

The following ports are required to be accessible from the outside world, both in local firewall and in any external firewalls:

• 2083/tcp (for RadSec connections to other Moonshot entities)
• 12309/tcp (for Trust Router client connections - if using the Trust Router to broker trust relationships between entities)

Add the Required Repositories

Trust Router requires two yum repositories to be added to the system - EPEL (home of some required dependencies), and the Moonshot repository.

Install EPEL by, running the following command:

Install the Moonshot repository by creating a new file at /etc/yum.repos.d/moonshot.repo with the following content:

Install the Moonshot GPG key:

Install Trust Router

We’re now ready to install the Trust Router software and its required dependencies. Install the software by running the following command:

Configure Trust Router

Next, we need to configure the Trust Router.

RadSec

APC TLS

First, you will need a copy of a client key and certificate (and appropriate CA) from the APC(s) that your Trust Router serves. Copy them onto the filesystem.

Connection to APC

Next, we need to configure the RadSec configuration for the APC. We do this by creating a file at /etc/radsec.conf with the following:

Then check the file and the certificates can be read by the Trust Router user:

Trust Router

Daemon Configuration

Your Trust Router will need to have a few core configuration items set. To do this:

1. Open the default instance's main configuration file at /etc/trust_router/conf.d/default/main.cfg for editing.
   
   1. Change the hostname to the (fully qualified) hostname of your Trust Router.
   2. Change the port that it runs on, if necessary.
2. Open the /etc/sysconfig/trust_router file for editing. Make sure the configuration items are correct. Items you will most likely have to change are:

   • TR_DEFAULT_TEST_ACCEPTOR - this will need to be set to the (fully qualified) hostname of your Trust Router.

   • TR_DEFAULT_TEST_RPREALM - this will need to be set to the (fully qualified) hostname for your APC.

   • TR_DEFAULT_TEST_COMMUNITY - this will need to be set to the (fully qualified) hostname for your APC.

   • TR_DEFAULT_TEST_REALM - this will need to be set to the (fully qualified) hostname for your APC.

3. Open the default instance's main configuration file at /etc/trust_router/conf.d/main.cfg for editing.
   1. Change the hostname to the (fully qualified) hostname of your Trust Router.
   2. Change the port that it runs on, if necessary.

Moonshot Configuration

Moonshot, you say? Yes, Trust Router uses Moonshot to authenticate and secure all communications between Trust Router clients and servers. So, you will need to configure the trust router user to make use of the Moonshot flatstore (i.e. telling Moonshot that this is a special system account, not a regular user account), and you will need to import a set of credentials for your Trust Router to use.

1. Enable the trustrouter user to use the Moonshot UI flatstore:

   bash

2. Import it using the moonshot-webp command (as the trustrouter user):

   There is currently an error in the home directory for the trustrouter user in /etc/passwd.

   Edit the file and change the home directory from /var/lib/trustrouter to /var/lib/trust_router before executing the below commands.

   bash

   The credentials file will be given to you by the administrator of the APC.

Shibboleth

Shibboleth, you say? Yes, Shibboleth is used by the Moonshot components to be able to deal with incoming SAML. However, this feature typically isn't used in Trust Router, but its logging will appear in your Trust Router's log files. So, to simplify your log files, it is recommended that you silence the Shibboleth logging. To do this:

1. Open /etc/shibboleth/console.logger for editing.

2. Change WARN to NONE on the first line, i.e.

   true

Default Peer

If it your Trust Router is going to run in a wider trust network, then you can configure your Trust Router's default peer - i.e. the Trust Router it sends its clients to when they ask it to locate a Moonshot entity that your Trust Router doesn't know about. To do this: 

1. Open /etc/trust_router/conf.d/default/peering.cfg for editing. Change the content as follows:

   true
   If the /etc/trust_router directory does not exist, you may need to create it yourself, along with the subdirectories mentioned.
   Example

   If you were configuring your default Trust Router peer to be Janet's Trust Router at

   tr1

   tr.moonshot.ja.net, its peering.cfg file would look like this:

   true

Configure your Trust Router

A trust router requires a trust configuration to function correctly. See for more information.

Place an appropriate trusts.cfg file info the /etc/trust_router directory and symbolically link it into the default configuration directory:

Start your Trust Router

You are now ready to restart your Trust Router and test it. To do this:

1. As root, restart start the Trust Router daemon:

   bash

Testing

service trustrouter status. Default should work, tr-test shouldn'tTo test your trust router, you should attempt a TIDC request on a Moonshot service connected to your trust router. If you have defined a default peer, the TIDC request may take a little longer, but it should succeed.

If it fails, please contact us.

Next Steps

At this point, you now have a Trust Router. Blimey.

/etc/trust_router/trusts.cfg with trust config

Automatically start the software

Trust Router

To automatically start Trust Router, issue the following command (as root):

If this is working correctly, you should see trust_router running as a daemon process.