Failover

Privilege Management for Unix and Linux can be configured to provide backup user request processing and activity logging. This capability is referred to as failover.

To configure backup request processing, specify the backup policy server hosts by using the submitmasters keyword in /etc/pb.settings on the submit host.

To configure backup logging, specify the backup log hosts by using the logservers keyword in /etc/pb.settings on the policy server host.

For more information on failover, please see the following:

Fine Tuning Policy Server and Failover Connection Timing

masterdelay

  • Version 4.0.0 and later: masterdelay setting available.

When a request is submitted, the policy server hosts that are listed in the submitmasters line are tried in the order they appear, from left to right. The masterdelay setting enables the administrator to adjust the amount of time between failover attempts.

Without a specified time-out, the client tries the first policy server host on the submitmasters line. If it does not receive a response within 500 milliseconds, then the client adds the second policy server host. If neither responds in the next 500 milliseconds, then the client adds the third policy server host, and so on. By specifying a masterdelay, you can change the 500 millisecond waiting period before the client goes on to the next policy server host.

With a masterdelay of 0 milliseconds, you get the fastest possible connection, but the policy server you connect to may not be predictable. You might also increase network traffic, depending on the number of connections that are opened.

With a larger masterdelay, you can increase the predictability, but you might also increase the time needed to form a failover connection. The longer the delay, the more predictable the sequence is.

masterdelay 200
masterdelay 500

Submit hosts

masterprotocoltimeout

  • Version 4.0.0 and later: masterprotocoltimeout setting available.

After a connection is established, the programs perform some protocol checks to verify a proper and working connection. Some types of protocol failures could take a long time to determine (for example, wrong service running on the policy server port, or mismatched encryption types/keys).

The masterprotocoltimeout setting enables the administrator to control the maximum time to wait for protocol completion. If a protocol step does not complete within the specified number of milliseconds, then the client continues to try the next policy server host in sequence. A value of -1 indicates no protocol timeout.

masterprotocoltimeout 2000
masterprotocoltimeout 500
  • Policy server hosts
  • Run hosts
  • Submit hosts

Fine Tuning Log Servers and Failover Connection Timing

logserverdelay

  • Version 4.0.0 and later: logserverdelay setting available.

When a log request is processed, the log servers that are listed in the logservers line are tried in the order they appear, from left to right. The logserverdelay setting enables the administrator to adjust the amount of time between failover attempts.

Without a specified time-out, the logging program (for example, pbrun, pbmasterd, pblocald, etc.) tries the first log server on the logservers line. If it does not receive a response within 500 milliseconds, then it adds the second log host. If neither responds in the next 500 milliseconds, then it adds the third log host, and so on. By specifying a logserverdelay, you can change the 500 millisecond waiting period before the logging program goes on to the next log server.

With a logserverdelay of 0 milliseconds, you get the fastest possible connection, but the log server that you connect to may not be predictable. You might also increase network traffic, depending on the number of connections that are opened.

With a larger logserverdelay you can increase the predictability, but you might also increase the time needed to form a failover connection. The longer the delay, the more predictable the sequence is.

logserverdelay 2500
logserverdelay 500
  • Policy server hosts
  • Run hosts
  • Submit hosts by pbksh and pbsh when a policy server is not available

logserverprotocoltimeout

  • Version 4.0.0 and later: logserverprotocoltimeout setting available.

After a connection is established, the programs perform some protocol checks to verify a proper and working connection. Some types of protocol failures can take a very long time to determine. For example, the wrong service running on the log server port, or mismatched encryption types/keys.

The logserverprotocoltimeout setting enables the administrator to control the maximum time to wait for protocol completion. If a protocol step does not complete within the specified number of milliseconds, then the logging program continues to try the next log server in sequence. A value of -1 indicates no protocol timeout.

If the iologack setting is used, then the logserverprotocoltimeout setting also controls how long a submit host should wait for an acknowledgment from the log host.

logserverprotocoltimeout 2000
logserverprotocoltimeout 500
  • Log hosts
  • Policy server hosts
  • Run hosts
  • Submit hosts by pbksh and pbsh when a policy server host is not available

For more information, please see iologack.

randomizelogservers

  • Version 9.2.0 and earlier: randomizelogservers setting not available.
  • Version 9.3.0 and later: randomizelogservers setting available.

The randomizelogservers setting forces the policy server/submit host/run host to choose a log server host at random, rather than choosing the first available log server host that is specified in the logservers setting. This feature balances the load among multiple log server hosts.

The use of randomizelogservers can cause accept and finish events to be located on different log servers if the log servers are configured with eventdestinations set to a flat file (authevt=<file>) or an SQLite Database (authevt=db). However, if eventdestinations is set to authevt=<DSN> (same ODBC Oracle or MySQL database on all the log servers), then the accept and finish events are stored on the same Oracle or MySQL server. The default randomizelogservers setting is no.

The randomizelogservers keyword should not be used with the use of DNS SRV lookups. The randomizelogservers keyword can result in accept and finish events logged on different logservers, causing the need to merge iologs.

randomizelogservers yes
randomizelogservers no
  • Submit hosts
  • Run hosts
  • Policy servers

Acknowledge Failovers

transparentfailover

  • Version 5.1.1 and earlier: transparentfailover setting not available.
  • Version 5.1.2 and later: transparentfailover setting available.

A transparentfailover occurs when an initial connection to a policy server host has failed and the program performs a failover to another available policy server host in the list. To acknowledge that a user failover has occurred, error messages from the failed connection are displayed to the user.

The transparentfailover setting enables you to suppress the following failover error messages:

  • Any Kerberos initialization error
  • 3084 initMangle failure during startup
  • 3089 Could not send initial protocol header to Policy Server
  • 3090 Did not receive initial protocol header from Policy Server
  • 8534 Policy Server on %s is not SSL enabled
  • 1913 Invalid Policy Server daemon on Policy Server host %s

When transparentfailover is set to yes, failover error messages listed above are suppressed. To display failover error messages, set transparentfailover to no in the pb.settings file.

transparentfailover yes
transparentfailover yes

Submit hosts