| Article Index |
|---|
| Radius Configuration for Fail-over |
| Page 2 |
| Page 3 |
| All Pages |
Radius Configuration for Fail-over
Contents
- 1 Configurable Module Fail Over
- 2 Rewriting results for single modules
- 3 Fail-over configuration entries
- 4 More Complex Configurations
- 5 More Complex Configuration using "if" and "else"
- 6 Virtual Modules
- 7 Redundancy and Load-Balancing
Configurable Module Fail Over
Before configurable module failover, we had this kind of entry in "radiusd.conf":
- authorize {
- preprocess
- files
- }
This entry instructed the "authorize" section to first process the request through the "preprocess" module, and if that returned success, to process it through "files" module. If that sequence returned success, then the "authorize" stage itself would then return success. Processing was strictly linear and if one module failed, the whole section would fail immediately.
Configurable failover provides more flexibility. It takes advantage of the tree structure of radiusd.conf to support a configuration language that allows you to "group" modules that should work together in ways other than simple lists. You can control the flow of any stage (e.g. "authorize") to fit your needs, without touching C code, just by altering radiusd.conf.
This configurable fail-over has a convenient short-hand, too. Administrators commonly want to say things like "try SQL1, if it's down, try SQL2, otherwise drop the request."
For example:
- modules {
- sql sql1 {
- # configuration to connect to SQL database one
- }
- sql sql2 {
- # configuration to connect to SQL database two
- }
- always handled {
- rcode = handled
- }
- sql sql1 {
- }
- # Handle accounting packets
- accounting {
- # always log to detail, stopping if it fails
- detail
- redundant {
- # try module sql1
- sql1
- # if that's down, try module sql2
- sql2
- # otherwise drop the request as
- # it's been "handled" by the "always"
- # module (see doc/rlm_always)
- handled
- }
- }
The "redundant" section is a configuration directive which tells the server to process the second module if the first one fails. Any number of modules can be listed in a "redundant" section. The server will process each in turn, until one of the modules succeeds. It will then stop processing the "redundant" list.
Rewriting results for single modules
Normally, when a module fails, the entire section ("authorize", "accounting", etc.) stops being processed. In some cases, we may want to permit "soft failures". That is, we may want to tell the server that it is "ok" for a module to fail, and that the failure should not be treated as a fatal error.
In this case, the module is treated as a "section", rather than just as a single line in "radiusd.conf". The configuration entries for that section are taken from the "configurable fail-over" code, and not from the configuration information for that module.
For example, the "detail" module normally returns "fail" if it is unable to write its information to the "detail" file. As a test, we can configure the server so that it continues processing the request, even if the "detail" module fails. The following example shows how:
- # Handle accounting packets
- accounting {
- detail {
- fail = 1
- }
- redundant {
- sql1
- sql2
- handled
- }
- detail {
- }
The "fail = 1" entry tells the server to remember the "fail" code, with priority "1". The normal configuration is "fail = return", which means "if the detail module fails, stop processing the accounting section".
Fail-over configuration entries
Modules normally return on of the following codes as their result:
| Code | Meaning |
|---|---|
| notfound | the user was not found |
| noop | the module did nothing |
| ok | the module succeeded |
| updated | the module updated information in the request |
| fail | the module failed |
| reject | the module rejected the user |
| userlock | the user was locked out |
| invalid | the user's configuration entry was invalid |
| handled | the module has done everything to handle the request |
In a configurable fail-over section, each of these codes may be listed, with a value. If the code is not listed, or a configurable fail-over section is not defined, then values that make sense for the requested "group" (group, redundant, load-balance, etc) are used.
The special code "default" can be used to set all return codes to the specified value. This value will be used with a lower priority than ones that are explicitly set.
The values for each code may be one of the following:
| Value | Meaning |
|---|---|
| <number> | Priority for this return code. |
| return | stop processing this configurable fail-over list. |
| reject | Stop processing this configurable fail-over list and immediately return a reject. |
The <number> used for a value may be any decimal number between 1 and 99999. The number is used when processing a list of modules, to determine which code is returned from the list. For example, if "module1" returns "fail" with priority "1", and a later "module2" returns "ok" with priority "3", the return code from the list of modules will be "ok", because it has higher priority than "fail".
This configurability allows the administrator to permit some modules to fail, so long as a later module succeeds.
