Updated timestamp

[freeradius.git] / doc / configurable_failover

diff --git a/doc/configurable_failover b/doc/configurable_failover
index 07f0532..2598e89 100644 (file)
--- a/doc/configurable_failover
+++ b/doc/configurable_failover
@@ -62,8 +62,8 @@ 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 willthen stop processing the "redundant" list.
 
-  Rewriting results for single modules
-  ------------------------------------
+1. 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
@@ -100,8 +100,8 @@ 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
-  -------------------------------
+2. Fail-over configuration entries
+   -------------------------------
 
   Modules normally return on of the following codes as their result:
 
@@ -146,8 +146,8 @@ modules will be "ok", because it has higher priority than "fail".
 to fail, so long as a later module succeeds.
 
 
-  More Complex Configurations
-  ---------------------------
+3. More Complex Configurations
+   ---------------------------
 
   The "authorize" section is normally a list of module names.  We can
 create sub-lists by using the section name "group".  The "redundant"
@@ -201,8 +201,43 @@ return code found by processing the list.
 "group" section.
 
 
-  The Gory Details
-  ----------------
+4. Virtual Modules
+   ---------------
+
+  Some configurations may require using the same list of modules, in
+the same order, in multiple sections.  For those systems, the
+configuration can be simplified through the use of "virtual" modules.
+These modules are configured as named sub-sections of the
+"instantiate" section, as follows:
+
+       instantiate {
+               ...
+
+               redundant sql1_or_2 {
+                       sql1
+                       sql2
+               }
+       }
+
+  The name "sql1_or_2" can then be used in any other section, such as
+"authorize" or "accounting".  The result will be *exactly* as if that
+section was placed at the location of the "sql1_or_2" reference.
+
+  These virtual modules are full-fledged objects in and of themselves.
+One virtual module can refer to another virtual module, and they can
+contain "if" conditions, or any other configuration permitted in a
+section.
+
+
+5. Redundancy and Load-Balancing
+   -----------------------------
+
+  See "man unlang" or doc/load-balance.txt for information on simple
+redundancy (fail-over) and load balancing.
+
+
+6. The Gory Details
+   ----------------
 
 The fundamental object is called a MODCALLABLE, because it is something that
 can be passed a specific radius request and returns one of the RLM_MODULE_*