The redundant Statement

Syntax

redundant {
    [ statements ]
}

The redundant section executes a series of statements in sequence. As soon as one statement succeeds, the rest of the section is skipped.

[ statements ]: One or more unlang commands. Processing starts from the first statement in the list.

If the selected statement succeeds, then the server stops processing the redundant section. If, however, that statement fails, then the next statement in the list is chosen. This process continues until either one statement succeeds or all of the statements have failed.

All of the statements in the list should be modules, and of the same type (e.g., ldap or sql). All of the statements in the list should behave identically, otherwise different requests will be processed through different modules and will give different results.

In general, we recommend using the redundant-load-balance statement instead of redundant.

Example

redundant {
    sql1
    sql2
    sql3
}

Redundant Sections as Modules

It can be useful to use the same redundant section in multiple places. Instead of copying the same text multiple times, a redundant section can be defined as a module in the mods-enabled/ directory.

For example, the following text can be placed into the file mods-enabled/sql123. Once it is there, it can be used as a module named sql123, and used anywhere a module is allowed to use.

Example of Redundant SQL module

redundant sql123 {
    sql1
    sql2
    sql3
}

In previous versions of the server, this definition would be placed into the instantiate section of radiusd.conf. This configuration is no longer used, and the `sql123 definition can just be placed as a module definition into the mods-enabled/ directory.

Redundant Expansions

When the sql123 module is defined as above, it can also be used as in a dynamic expansion:

Example of Redundant SQL module

&Reply-Message := %sql123("SELECT message FROM table WHERE name='%{User-Name}'")
}

The expansion works exactly like a redundant block. First sql1 is tried. If that fails, sql2 is tried. Then if that fails, sql3 is tried.

The one caveat here is that the arguments passed to the underlying modules are expanded again for each call. If the expansion arguments have side effects, then those side effects can be applied multiple times, once for each redundant attempt.