Query regarding redundant module and configurable failover codes
Dears I have a question regarding the configurable failover codes. Our accounting module is defined as follows Detail… Detail_hour_ae1 … … Redundant{ Sql2 { Fail=1 … … } Sql2_redundant { Fail= return … … } *Sql_update_xxxx* * * *Sql_update_yyyy* } The last two sql updates ie *"Sql_update_xxxx" and **"Sql_update_yyyy" *do not have a redundant module defined. The actions of these statement is not very critical. However we observe that if the radius is unable to execute these the radius drops the session and returns a FAIL. One way to avoid this session disconnection is to implement a redundant module for the last two statements as well. We are looking at a possibility of this second solution. And require help in this regard. If we modify our configuration to something like this Redundant{ Sql{ Ok=2 } Sql2 { Ok=3 } } Group{ * Sql_update_xxxx* * * * Sql_update_yyyy* … Fail =1 } } *Ok will override Fail because the priority is higher.* * * *So the accounting module will not return failure because of the third module (atleast in theory).* Does anyone have a solution/suggestions for this kind of a problem. Thanks & Regards Shweta
Shweta Khadse wrote:
The last two sql updates ie *"Sql_update_xxxx" and **"Sql_update_yyyy" *do not have a redundant module defined. The actions of these statement is not very critical. However we observe that if the radius is unable to execute these the radius drops the session and returns a FAIL.
One way to avoid this session disconnection is to implement a redundant module for the last two statements as well.
Yes. Just do: redundant { sql_update_xxxx sql_update_yyyy ok } Alan DeKok.
Thankyou Alan! You gave us an idea about how we can set "ok" to return a default ok for the section. We tested with our second approach as below and thrilled that it works/ This ensures radius returns ok even if the sql_update_**** modules fail. redundant{ ok } sql_update_xxxx { FAIL=1 } sql_update_yyyy { FAIL=1 } Regards Shweta On Sun, Dec 11, 2011 at 1:56 PM, Alan DeKok <aland@deployingradius.com>wrote:
Shweta Khadse wrote:
The last two sql updates ie *"Sql_update_xxxx" and **"Sql_update_yyyy" *do not have a redundant module defined. The actions of these statement is not very critical. However we observe that if the radius is unable to execute these the radius drops the session and returns a FAIL.
One way to avoid this session disconnection is to implement a redundant module for the last two statements as well.
Yes. Just do:
redundant { sql_update_xxxx sql_update_yyyy ok }
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Tue, Dec 13, 2011 at 1:54 PM, Shweta Khadse <shwetgk@gmail.com> wrote:
Thankyou Alan!
You gave us an idea about how we can set "ok" to return a default ok for the section.
We tested with our second approach as below and thrilled that it works/ This ensures radius returns ok even if the sql_update_**** modules fail.
redundant{ ok } sql_update_xxxx { FAIL=1 } sql_update_yyyy { FAIL=1 }
DId you REALLY test that? A quick glance says the OK block will always be used, thus making sql_update* pretty much useless. Why not use Alan's example? -- Fajar
Hi Fajar Yes we REALLY tested it :) "A quick glance says the OK block will always be used" is what we wanted! Because this block is critical. What was happening earlier was since we didnt have any return code for the sql_update_**** ,any failure at that level was making the accounting module return a false and thus the session disconnection. In our case the last two statements are not so critical that the sessions be dropped. So now with this approach - mission accomplished! Regards Shweta On Tue, Dec 13, 2011 at 10:59 AM, Fajar A. Nugraha <list@fajar.net> wrote:
On Tue, Dec 13, 2011 at 1:54 PM, Shweta Khadse <shwetgk@gmail.com> wrote:
Thankyou Alan!
You gave us an idea about how we can set "ok" to return a default ok for the section.
We tested with our second approach as below and thrilled that it works/ This ensures radius returns ok even if the sql_update_**** modules fail.
redundant{ ok } sql_update_xxxx { FAIL=1 } sql_update_yyyy { FAIL=1 }
DId you REALLY test that? A quick glance says the OK block will always be used, thus making sql_update* pretty much useless. Why not use Alan's example?
-- Fajar
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Tue, Dec 13, 2011 at 2:25 PM, Shweta Khadse <shwetgk@gmail.com> wrote:
Hi Fajar
Yes we REALLY tested it :)
"A quick glance says the OK block will always be used" is what we wanted! Because this block is critical.
Are you SURE that's what you want? redundant { ok sql1 sql2 } is basically the same as just ok -- Fajar
Redundant{ Sql1{ ok=2 } Sql2 { Ok= return } } * Sql_update_xxxx* { FAIL=1 } *Sql_update_yyyy* { FAIL=1 } } On Tue, Dec 13, 2011 at 11:32 AM, Fajar A. Nugraha <list@fajar.net> wrote:
On Tue, Dec 13, 2011 at 2:25 PM, Shweta Khadse <shwetgk@gmail.com> wrote:
Hi Fajar
Yes we REALLY tested it :)
"A quick glance says the OK block will always be used" is what we wanted! Because this block is critical.
Are you SURE that's what you want?
redundant { ok sql1 sql2 }
is basically the same as just
ok
-- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Tue, Dec 13, 2011 at 2:42 PM, Shweta Khadse <shwetgk@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
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@fajar.net> wrote:
On Tue, Dec 13, 2011 at 2:42 PM, Shweta Khadse <shwetgk@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
On Tue, Dec 13, 2011 at 3:57 PM, Shweta Khadse <shwetgk@gmail.com> wrote:
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).
There's no such thing as "override" in accounting section. At least not that I know of :) This section might best suit your needs: accounting { redundant-load-balance { sql1 sql2 } redundant { sql_update_xxxx ok } redundant { sql_update_yyyy ok } } that section translates to: - for every accounting request, it will choose randomly between sql1 and sql2. If both works, they will have equal load. If only one of them works, accounting can still continue. If both fail, accounting will fail - for every accounting request, it will TRY to run sql_update_xxxx and sql_update_yyyy. Even when both of them fail, accounting will still work as long as either sql1 or sql2 works. -- Fajar
Suggestion noted! As I said we tried our way and got our way! But then things always work during testing right! If at some point we do see that the radius disagrees with us , we will create a redundant set up for part2 as well. Thanks again! On Tue, Dec 13, 2011 at 1:19 PM, Fajar A. Nugraha <list@fajar.net> wrote:
On Tue, Dec 13, 2011 at 3:57 PM, Shweta Khadse <shwetgk@gmail.com> wrote:
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).
There's no such thing as "override" in accounting section. At least not that I know of :)
This section might best suit your needs:
accounting { redundant-load-balance { sql1 sql2 } redundant { sql_update_xxxx ok } redundant { sql_update_yyyy ok } }
that section translates to: - for every accounting request, it will choose randomly between sql1 and sql2. If both works, they will have equal load. If only one of them works, accounting can still continue. If both fail, accounting will fail - for every accounting request, it will TRY to run sql_update_xxxx and sql_update_yyyy. Even when both of them fail, accounting will still work as long as either sql1 or sql2 works.
-- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
Fajar A. Nugraha -
Shweta Khadse