Query regarding redundant module and configurable failover codes

[Shweta Khadse]

Fajar

Appreciate the time you are taking to help out!

Its like this. We have two parts right

Part 1 -

Redundant module having sql1 and sql2
This is a critical module ,so if sql1 fails it tries sql2. So far so good!

Part 2 -

sql_update_xxxx , sql_update_yyyy

The above two update a different schema with some additional information.
This action is not very critical and does NOT have a redundant set up. What
we want is that the outcome of part2 should not affect the overall
accounting response.

So if Part 2 fails , the result of Part 1 should override it (whatever the
result of Part 1 maybe).






On Tue, Dec 13, 2011 at 12:13 PM, Fajar A. Nugraha <list at fajar.net> wrote:

> On Tue, Dec 13, 2011 at 2:42 PM, Shweta Khadse <shwetgk at gmail.com> wrote:
> > Redundant{
> >
> >      Sql1{
> >
> > ok=2
> >
> >      }
> >
> >     Sql2
> >
> >      {
> >
> > Ok= return
> >
> >      }
> >
> > }
> >
> >
> >  Sql_update_xxxx
> >                      {
> >
> > FAIL=1
> >
> >      }
> >
> >
> > Sql_update_yyyy
> >                      {
> >
> > FAIL=1
> >
> >      }
> >
> > }
>
> Looks like you misunderstood what I meant. DId you read
> http://wiki.freeradius.org/Fail-over ? Looks like you're confusing
> "group" and "redundant".
>
> Let me try this another way.
>
> What are you trying to do? Is it:
> (1) run ALL sql1, sql2, Sql_update_xxxx, and Sql_update_yyyy, and if
> any of them fail, the entire accounting block fail. OR
> (2) run EITHER ONE (and ONLY one) of sql1, sql2, Sql_update_xxxx, and
> Sql_update_yyyy, in that order. OR
> (3) TRY to run ALL of sql1, sql2, Sql_update_xxxx, and
> Sql_update_yyyy, but if any of them fail return OK for that particular
> module.
> (4) simply return Accounting-Response to the NAS no matter what
>
> If it's (1), then the block should be
>
> accounting {
>  sql1
>  sql2
>  sql_update_xxx
>  sql_update_yyy
> }
>
> if it's (2), then the block should be
>
> accounting {
>  redundant {
>    sql1
>    sql2
>    sql_update_xxx
>    sql_update_yyy
>    ok
>  }
> }
>
> if it's (3), then the block should be
>
> accounting {
>  redundant {
>    sql1
>    ok
>  }
>  redundant {
>    sql2
>    ok
>  }
>  redundant {
>    sql_update_xxx
>    ok
>  }
>  redundant {
>    sql_update_yyy
>    ok
>  }
> }
>
> If it's (4), then a simple
>
> accounting {
>  ok
> }
>
> is enough. Note that this block:
>
> accounting {
>  redundant {
>    ok
>    sql1
>    sql2
>    sql_update_xxx
>    sql_update_yyy
>  }
> }
>
> will also do the same thing as the one before (4), but anything under
> "ok" is useless as it's never used.
>
> --
> Fajar
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20111213/ba4e17e0/attachment.html>