...
| No Format |
|---|
# mysql -u root -p < /usr/local/targeted-id/etc/tid-grants.sql |
Set up the tid-syncd daemon
In all but exceptional cases, a generated ID will be the consistent result of hashing the username, provider ID, and secret strings, so the ID for a (user, SP) pair will be the same, no matter which node in a cluster it is generated on. This may not be true, though, in the (highly unlikely) case of a hash collision, or if an ID needs to be revoked. To make sure that the databases in a cluster remain in synch, therefore, we employ a tid-syncd daemon which propagates new IDs to the peer(s). This daemon should run on all nodes, and be started at boot time. The daemon logs at the LOCAL5 syslog facility, so /etc/syslog.conf should be adjusted accordingly:
| No Format |
|---|
# Targeted ID sync daemon
local5.* /var/log/tid-syncd
|
Start the daemon, and make sure it is started at boot time:
| No Format |
|---|
# /etc/init.d/tid-sync start
# chkconfig tid-sync on
|
Firewall
Make sure that the additional port used by the IdP are enabled in the firewall. Use the command "iptables --list -n --line-numbers" to determine the proper rule number; the following example assumes we are inserting rules beginning at number 36. Also replace 18.x.y.z with the appropriate IP address of the peer node in the cluster, not the local host.
...