Re: [RADIATOR] ActiveState Win32 and FailureBackoffTime
Hello Robert,
FailureBackoffTime doesn't specify when database connection is tried
next time. After FailureBackoffTime there must be outside trigger to
attempt database connection.
For example in your case you should see ClientListSQL to make a database
connection again after 900 seconds. Can you see then attempts to connect
SQL database.
If you are using it in a AuthBy it will try to create SQL connection
when request goes to AuthBy that needs connection to database. If it
timeouts it needs a new request to create database connection.
So it won't attempt to create automatically connection to database.
Best Regards,
Sami
On 07/30/2013 09:33 PM, Robert Fisher wrote:
OK...Upgraded from ActivePerl 5.8 to 5.16 as well as making sure all the
relavent packages were updated as well and updated Radiator from 3.14
to 4.11 -- but I'm still not seeing a reconnect attempt if the service loses
connectivity. So apparently I missed something -- can someone spot what
that might be? Here's a cleaned up snippet from a Trace 3 log (far too
much
traffic to sit with Trace 4) and the relevant parts of my config. As
you can see,
I'm definining the FailureBackOffTime in my ClientListSQL and in the AuthBy
clause (AuthBy Sitestar is essentially a customized AuthBy EMERALD module
which still inherits the DB connection parameters from AuthBy SQL...I
also use
some AuthBy SQL clauses with the same parameters as well) -- and then in
addition to defining the FailureBackOffTime -- I also define the
RefreshPeriod
of the ClientListSQL -- but the log shows 'backing off for 0 seconds'
and never
indicates an attempt to reconnect.
Tue Jul 30 13:50:59 2013: ERR: Could not connect to SQL database with
DBI-connect dbi:ODBC:RADIUSDB, raduser, raddbpass: [Microsoft][ODBC
SQL Server Driver]Timeout expired (SQL-HYT00)
Tue Jul 30 13:50:59 2013: ERR: Could not connect to any SQL database.
Request is ignored. Backing off for 0 seconds
Tue Jul 30 13:51:00 2013: NOTICE: Server started: Radiator 4.11 on freedom
# Let's define several variables.
DefineGlobalVarSUBSCRIBER_DBdbi:ODBC:RADIUSDB
DefineGlobalVar ACCOUNTING_DBdbi:ODBC:RadiusAcct
DefineGlobalVar PROPELACCT_DBdbi:ODBC:RadiusAcct
DefineGlobalVardatabaseuserraduser
DefineGlobalVardatabasepassraddbpass
DefineGlobalVardatabackofftime300
ClientListSQL
DBSource%{GlobalVar:SUBSCRIBER_DB}
DBUsername%{GlobalVar:databaseuser}
DBAuth %{GlobalVar:databasepass}
FailureBackoffTime%{GlobalVar:databackofftime}
# Re-read Servers table every 15 minutes.
RefreshPeriod900
GetClientQuerySELECT \
IPAddress AS NASIdentifier, \
Secret, \
NULL AS IgnoreAcctSignature, \
DupInterval, \
DefaultRealm, \
NasType, \
Community AS SNMPCommunity, \
NULL AS LivingstonOffs, \
NULL AS LivingstonHole, \
NULL AS FramedGroupBaseAddress, \
NULL AS FramedGroupMaxPortsPerClassC, \
RewriteUsername, \
NoIgnoreDuplicates, \
NULL AS PreHandlerHook, \
Comments AS Identifier, \
DefaultReply, \
NULL AS FramedGroup, \
StripFromReply, \
AllowInReply, \
AddToReply, \
AddToReplyIfNotExist, \
DynamicReply, \
AddToRequest, \
StripFromRequest, \
AddToRequestIfNotExist, \
Flags \
FROM Servers
/ClientListSQL
AuthLog FILE
Identifiersitestar-log
Filename%L/rad-auth-%Y-%m.log
LogSuccess1
LogFailure1
SuccessFormat%l:%c:%N:%u:%U:%P:%1:OK
FailureFormat%l:%c:%N:%u:%U:%P:%1:FAIL
/AuthLog
AuthBy SITESTAR
IdentifierSitestarAuth
DBSource%{GlobalVar:SUBSCRIBER_DB}
DBUsername%{GlobalVar:databaseuser}
DBAuth %{GlobalVar:databasepass}
FailureBackoffTime%{GlobalVar:databackofftime}
AuthSelectRadUserLookup '%U', '%R', '%{Request:Called-Station-Id}'
# Empty AccountingTable turns off Accounting.
IgnoreAccounting
AccountingTable
CaseInsensitivePasswords
AddATDefaults
/AuthBy
Handler
AuthLogsitestar-log
AuthBySitestarAuth
/Handler
Robert Fisher
Systems Administrator
Sitestar Internet Services
On 7/23/2013 9:01 AM, Robert Fisher wrote:
Hrmm -- Don't have a trace 4 log, but did see where the logs have a
backing off
for 0 seconds, and my ClientListSQL clause has a refresh of 900 -- but
it's still
not triggering a reconnect, though I do notice I'm running a rather old
version
of 3.14 -- so going to try updating Perl and Radiator before continuing
to tweak
settings.
Robert Fisher
Systems Administrator
Sitestar Internet Services
On
Re: [RADIATOR] ActiveState Win32 and FailureBackoffTime
OK...Upgraded from ActivePerl 5.8 to 5.16 as well as making sure all the
relavent packages were updated as well and updated Radiator from 3.14
to 4.11 -- but I'm still not seeing a reconnect attempt if the service loses
connectivity. So apparently I missed something -- can someone spot what
that might be? Here's a cleaned up snippet from a Trace 3 log (far too
much
traffic to sit with Trace 4) and the relevant parts of my config. As
you can see,
I'm definining the FailureBackOffTime in my ClientListSQL and in the AuthBy
clause (AuthBy Sitestar is essentially a customized AuthBy EMERALD module
which still inherits the DB connection parameters from AuthBy SQL...I
also use
some AuthBy SQL clauses with the same parameters as well) -- and then in
addition to defining the FailureBackOffTime -- I also define the
RefreshPeriod
of the ClientListSQL -- but the log shows 'backing off for 0 seconds'
and never
indicates an attempt to reconnect.
Tue Jul 30 13:50:59 2013: ERR: Could not connect to SQL database with
DBI-connect dbi:ODBC:RADIUSDB, raduser, raddbpass: [Microsoft][ODBC
SQL Server Driver]Timeout expired (SQL-HYT00)
Tue Jul 30 13:50:59 2013: ERR: Could not connect to any SQL database.
Request is ignored. Backing off for 0 seconds
Tue Jul 30 13:51:00 2013: NOTICE: Server started: Radiator 4.11 on freedom
# Let's define several variables.
DefineGlobalVarSUBSCRIBER_DBdbi:ODBC:RADIUSDB
DefineGlobalVar ACCOUNTING_DBdbi:ODBC:RadiusAcct
DefineGlobalVar PROPELACCT_DBdbi:ODBC:RadiusAcct
DefineGlobalVardatabaseuserraduser
DefineGlobalVardatabasepassraddbpass
DefineGlobalVardatabackofftime300
ClientListSQL
DBSource%{GlobalVar:SUBSCRIBER_DB}
DBUsername%{GlobalVar:databaseuser}
DBAuth %{GlobalVar:databasepass}
FailureBackoffTime%{GlobalVar:databackofftime}
# Re-read Servers table every 15 minutes.
RefreshPeriod900
GetClientQuerySELECT \
IPAddress AS NASIdentifier, \
Secret, \
NULL AS IgnoreAcctSignature, \
DupInterval, \
DefaultRealm, \
NasType, \
Community AS SNMPCommunity, \
NULL AS LivingstonOffs, \
NULL AS LivingstonHole, \
NULL AS FramedGroupBaseAddress, \
NULL AS FramedGroupMaxPortsPerClassC, \
RewriteUsername, \
NoIgnoreDuplicates, \
NULL AS PreHandlerHook, \
Comments AS Identifier, \
DefaultReply, \
NULL AS FramedGroup, \
StripFromReply, \
AllowInReply, \
AddToReply, \
AddToReplyIfNotExist, \
DynamicReply, \
AddToRequest, \
StripFromRequest, \
AddToRequestIfNotExist, \
Flags \
FROM Servers
/ClientListSQL
AuthLog FILE
Identifiersitestar-log
Filename%L/rad-auth-%Y-%m.log
LogSuccess1
LogFailure1
SuccessFormat%l:%c:%N:%u:%U:%P:%1:OK
FailureFormat%l:%c:%N:%u:%U:%P:%1:FAIL
/AuthLog
AuthBy SITESTAR
IdentifierSitestarAuth
DBSource%{GlobalVar:SUBSCRIBER_DB}
DBUsername%{GlobalVar:databaseuser}
DBAuth %{GlobalVar:databasepass}
FailureBackoffTime%{GlobalVar:databackofftime}
AuthSelectRadUserLookup '%U', '%R', '%{Request:Called-Station-Id}'
# Empty AccountingTable turns off Accounting.
IgnoreAccounting
AccountingTable
CaseInsensitivePasswords
AddATDefaults
/AuthBy
Handler
AuthLogsitestar-log
AuthBySitestarAuth
/Handler
Robert Fisher
Systems Administrator
Sitestar Internet Services
On 7/23/2013 9:01 AM, Robert Fisher wrote:
Hrmm -- Don't have a trace 4 log, but did see where the logs have a
backing off
for 0 seconds, and my ClientListSQL clause has a refresh of 900 -- but
it's still
not triggering a reconnect, though I do notice I'm running a rather old
version
of 3.14 -- so going to try updating Perl and Radiator before continuing
to tweak
settings.
Robert Fisher
Systems Administrator
Sitestar Internet Services
On 7/23/2013 5:43 AM, Sami Keski-Kasari wrote:
Hello Robert,
On 07/22/2013 05:59 PM, Robert Fisher wrote:
Even though I have the FailureBackoffTime defined to 300 or 5 minutes,
it seems to be ignored.
It is supported on windows. FailureBackoffTime applies when none of
the configured DBs can be connected. The next connection attempt is
done when the FailureBackoffTime has elapsed.
Can you see Backing off for a seconds messages in the log?
Could you reply with trace 4 logfile from this event?
The documentation does state the optional Timeout
parameter is ignored on ActiveState Win32, and I suspect that has more
to do with the level of control of TCP sockets in Win32 more than
anything
else.
True, Timeout is ignored and the command runs as long as it returns
for some reason. The reason it is ignored has to
Re: [RADIATOR] ActiveState Win32 and FailureBackoffTime
Hello Robert, On 07/22/2013 05:59 PM, Robert Fisher wrote: Even though I have the FailureBackoffTime defined to 300 or 5 minutes, it seems to be ignored. It is supported on windows. FailureBackoffTime applies when none of the configured DBs can be connected. The next connection attempt is done when the FailureBackoffTime has elapsed. Can you see Backing off for a seconds messages in the log? Could you reply with trace 4 logfile from this event? The documentation does state the optional Timeout parameter is ignored on ActiveState Win32, and I suspect that has more to do with the level of control of TCP sockets in Win32 more than anything else. True, Timeout is ignored and the command runs as long as it returns for some reason. The reason it is ignored has to do with how signals are implemented in Win32 perl. What I don't understand is why the FailureBackoffTime doesn't cause Radiator to attempt a reconnect, and can see there's no second attempt to reconnect because nothing new about the connection makes it into the logs 5 - 10 - 15 minutes or even hours after the event until the service/daemon is restarted. If there is activity that requires DB access and there is currently no connection to the DB, it should reconnect. Note that if you have e.g., ClientListSQL with no refresh, there is only one attempt to fetch the client list. If that fails, then no retries are done. You can configure a refresh interval that should make periodic connections. So my questions are: 1) Is some extra step required to use FailureBackoffTime in Windows? No 2)Alternatively, is there any way to hook into the connection lost as an event so I can kill the radiator instance -- since that would at least be able to signal to Windows that the service has died and can then use the MS tools to try and restart the service and thus resynch the connection. There is currently undocumented hook that is called when no databases can be connected to. Currently the hook just logs the above Backing off... massage and does nothing else.: ConnectionAttemptFailedHook (see SqlDb.pm). Best Regards, Sami Thanks in advance, -- Sami Keski-Kasari sam...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] ActiveState Win32 and FailureBackoffTime
Hrmm -- Don't have a trace 4 log, but did see where the logs have a backing off for 0 seconds, and my ClientListSQL clause has a refresh of 900 -- but it's still not triggering a reconnect, though I do notice I'm running a rather old version of 3.14 -- so going to try updating Perl and Radiator before continuing to tweak settings. Robert Fisher Systems Administrator Sitestar Internet Services On 7/23/2013 5:43 AM, Sami Keski-Kasari wrote: Hello Robert, On 07/22/2013 05:59 PM, Robert Fisher wrote: Even though I have the FailureBackoffTime defined to 300 or 5 minutes, it seems to be ignored. It is supported on windows. FailureBackoffTime applies when none of the configured DBs can be connected. The next connection attempt is done when the FailureBackoffTime has elapsed. Can you see Backing off for a seconds messages in the log? Could you reply with trace 4 logfile from this event? The documentation does state the optional Timeout parameter is ignored on ActiveState Win32, and I suspect that has more to do with the level of control of TCP sockets in Win32 more than anything else. True, Timeout is ignored and the command runs as long as it returns for some reason. The reason it is ignored has to do with how signals are implemented in Win32 perl. What I don't understand is why the FailureBackoffTime doesn't cause Radiator to attempt a reconnect, and can see there's no second attempt to reconnect because nothing new about the connection makes it into the logs 5 - 10 - 15 minutes or even hours after the event until the service/daemon is restarted. If there is activity that requires DB access and there is currently no connection to the DB, it should reconnect. Note that if you have e.g., ClientListSQL with no refresh, there is only one attempt to fetch the client list. If that fails, then no retries are done. You can configure a refresh interval that should make periodic connections. So my questions are: 1) Is some extra step required to use FailureBackoffTime in Windows? No 2)Alternatively, is there any way to hook into the connection lost as an event so I can kill the radiator instance -- since that would at least be able to signal to Windows that the service has died and can then use the MS tools to try and restart the service and thus resynch the connection. There is currently undocumented hook that is called when no databases can be connected to. Currently the hook just logs the above Backing off... massage and does nothing else.: ConnectionAttemptFailedHook (see SqlDb.pm). Best Regards, Sami Thanks in advance, ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
