...
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 |
|---|
# Targetedtargeted ID sync daemon local5.* /var/log/tid-syncd |
...