Re: (RADIATOR) AuthRADIUS (non)forking problem
Hugh Irvine [EMAIL PROTECTED] writes: Hello Damir - As always, many thanks for your very valuable contributions. Mike will apply the fixes for the next release. My coleagues I are discussing an interesting idea. Would it be possible to handle slow AuthRADIUS proxy requests in a single process (forked out of main radiusd)? That process would have a communication line with main radius daemon through some socket (or whatever) and handle all slow requests in one big select loop (instead of forking an extra process to do the job for less then a few packets). That would make more efficient use of system resources. -d === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Authby ROUNDROBIN not using new hosts when sending HUP
Frank Danielson wrote: We're using a Radiator with Authby ROUNDROBIN to forward requests out to the other servers. The problem that I am running in to is that if I do a kill -HUP to get Radiator to reread the config file it doesn't seem to use the new Host directives in the config file and keeps forwarding requests to the old hosts. Do I just need to kill and restart Radiator? What I'm trying Frank, this is very similar to what I experienced (i'm not sure how long you've been on the list, but if you look at the thread (RADIATOR) Strange authlog behaviour, bug? (originally started by Sam Nilsson, it's the same thing. Changes made to config files are not picked up after a HUP, and only seem to take affect after a full restart (ie, kill -TERM pid of radius perl ./radiusd). In turning this over in my head, the only thing I could come up with is that it might have something to do with mulitple levels of includes. radius.cfg : Include %D/includes.cfg includes.cfg: Include %D/realms/somerealm somerealm: actual AuthBy's and what-not but I haven't had the opportunity to trace this out just yet. Hugh? Anyone else? -- Peter Moody Systems Administrator [EMAIL PROTECTED] :wq === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Authby ROUNDROBIN not using new hosts when sending HUP
Hello Peter, Hello Frank - I sent the results of my testing here to Peter yesterday, mentioning that I had not been able to reproduce his problem, although I had discovered another bug in the AuthLog FILE clause (the full path was not being created). At this stage we would like to hold off on looking at problems of this sort (-HUP related), as there are significant architectural changes in Radiator 3.0 that should resolve all of these sorts of issues. We would very much appreciate you testing Radiator 3.0 when it is released (within the next month of so), and verifying the operations that are currently causing difficulties. many thanks Hugh On Thu, 28 Feb 2002 09:02, peter moody wrote: Frank Danielson wrote: We're using a Radiator with Authby ROUNDROBIN to forward requests out to the other servers. The problem that I am running in to is that if I do a kill -HUP to get Radiator to reread the config file it doesn't seem to use the new Host directives in the config file and keeps forwarding requests to the old hosts. Do I just need to kill and restart Radiator? What I'm trying Frank, this is very similar to what I experienced (i'm not sure how long you've been on the list, but if you look at the thread (RADIATOR) Strange authlog behaviour, bug? (originally started by Sam Nilsson, it's the same thing. Changes made to config files are not picked up after a HUP, and only seem to take affect after a full restart (ie, kill -TERM pid of radius perl ./radiusd). In turning this over in my head, the only thing I could come up with is that it might have something to do with mulitple levels of includes. radius.cfg : Include %D/includes.cfg includes.cfg: Include %D/realms/somerealm somerealm: actual AuthBy's and what-not but I haven't had the opportunity to trace this out just yet. Hugh? Anyone else? -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Authby ROUNDROBIN not using new hosts when sending HUP
Hi Frank - Please see my other mail on this topic. Basically we would like you to test this with Radiator 3.0, and in the meantime just kill and restart Radiator so it recreates everything from scratch. thanks Hugh On Thu, 28 Feb 2002 07:40, Frank Danielson wrote: We're using a Radiator with Authby ROUNDROBIN to forward requests out to the other servers. The problem that I am running in to is that if I do a kill -HUP to get Radiator to reread the config file it doesn't seem to use the new Host directives in the config file and keeps forwarding requests to the old hosts. Do I just need to kill and restart Radiator? What I'm trying to accomplish is a dynamic method of updating the remote RADIUS servers. I looked at AuthBy SQLRADIUS but it didn't give the load balancing of ROUNDROBIN and I didn't want the overhead of performing a database query for every request. My config file includes a perl script that fetches the current list of remote servers out of a database and returns appropraitely formatted Host statements. My config file and sample output of get_agents.pl follows: cat radius.cfg LogDir /usr/local/radius/log DbDir /usr/local/radius/bin Trace 4 Foreground LogFile %L/radius.log PidFile %L/radius.pid Client DEFAULT Secret mysecret DupInterval 0 Identifier 1 /Client Handler AuthBy ROUNDROBIN Secret xxx Retries 1 RetryTimeout 12 FailureBackoffTime 300 include %D/get_agents.pl| /AuthBy /Handler ./get_agents.pl Host 209.137.104.54 AuthPort 16450 AcctPort 16450 /Host Host 209.137.104.54 AuthPort 16451 AcctPort 16451 /Host Host 209.137.104.54 AuthPort 16452 AcctPort 16452 /Host Host 209.137.104.54 AuthPort 16453 AcctPort 16453 /Host Frank Danielson [Infrastructure Architect] wireless: 407.467.7832 wireline: 407.515.8633 Data On Air 301 E. Pine St. Suite 450 Orlando, Fl 32801 http://www.dataonair.com http://www.dataonair.com/ -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) AuthRADIUS (non)forking problem
Hello Damir - Mike and I have discussed this issue at length over a long period of time, and indeed the topic has also been discussed on the mailing list several times as well. Basically, it is our intention to extend Radiator to use multi-threading so that each request runs in a separate thread, which we feel is the best approach for dealing with all these sorts of problems (not just with AuthBy RADIUS clauses). The only reason that this has not been done yet is due to the fact that although there is experimental support for multi-threading in Perl now, it is specifically stated that it is not to be considered production-quality code. This being the case, we have opted to wait until there is a solid multi-threading release of Perl first before spending more time on it. regards Hugh On Wed, 27 Feb 2002 19:55, Damir Dzeko wrote: Hugh Irvine [EMAIL PROTECTED] writes: Hello Damir - As always, many thanks for your very valuable contributions. Mike will apply the fixes for the next release. My coleagues I are discussing an interesting idea. Would it be possible to handle slow AuthRADIUS proxy requests in a single process (forked out of main radiusd)? That process would have a communication line with main radius daemon through some socket (or whatever) and handle all slow requests in one big select loop (instead of forking an extra process to do the job for less then a few packets). That would make more efficient use of system resources. -d -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) AuthRADIUS (non)forking problem
From what I have seen with my own (meager) experiments with Perl threading, it appears to behave radically different on different OSes, presumably because every OS treats threading differently. This may be the reason for the non-production-quality aspect. Chris From: Hugh Irvine [EMAIL PROTECTED] Organization: Open System Consultants Reply-To: [EMAIL PROTECTED] Date: Thu, 28 Feb 2002 11:17:15 +1100 To: Damir Dzeko [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: (RADIATOR) AuthRADIUS (non)forking problem Hello Damir - Mike and I have discussed this issue at length over a long period of time, and indeed the topic has also been discussed on the mailing list several times as well. Basically, it is our intention to extend Radiator to use multi-threading so that each request runs in a separate thread, which we feel is the best approach for dealing with all these sorts of problems (not just with AuthBy RADIUS clauses). The only reason that this has not been done yet is due to the fact that although there is experimental support for multi-threading in Perl now, it is specifically stated that it is not to be considered production-quality code. This being the case, we have opted to wait until there is a solid multi-threading release of Perl first before spending more time on it. regards Hugh On Wed, 27 Feb 2002 19:55, Damir Dzeko wrote: Hugh Irvine [EMAIL PROTECTED] writes: Hello Damir - As always, many thanks for your very valuable contributions. Mike will apply the fixes for the next release. My coleagues I are discussing an interesting idea. Would it be possible to handle slow AuthRADIUS proxy requests in a single process (forked out of main radiusd)? That process would have a communication line with main radius daemon through some socket (or whatever) and handle all slow requests in one big select loop (instead of forking an extra process to do the job for less then a few packets). That would make more efficient use of system resources. -d -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Re: Problem about SQL 7 SP3
Hello Hugh,
Now I can start Radaitor Service by
re-setting ODBC SystemDSN. But the problem still occure when I use
Radmin. Error Message belowis shown when I use web-browser to open
Radmin
ErrorA
serious error has occurred: Could not connect to SQL database
dbi:ODBC:Radmin: [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for
user 'RADTEMP\IUSR_RADTEMP'. (SQL-28000)(DBD: db_login/SQLConnect err=-1)
So how can I fix it?
Regards,
Chairath
P.S. Our system is running Radiator
2.18 and Radmin 1.4 on Windows NT
- Original Message -
From: Chairath K
To: Hugh
Irvine
Sent: Wednesday, February 27, 2002 10:52 AM
Subject: Problem about SQL 7 SP3
Hello Hugh,
I have install Service Pack 3 of
Microsoft SQL server 7.0 for NT in oder for Replication Application . But
afterIinstall it , I
can't start Radiator Service . So how can I fix it to work provperly with SQL 7
SP3 ?
Regards,
Chairath
Wed Feb 27 10:37:33 2002: DEBUG:
Adding Clients from SQL databaseWed Feb 27 10:37:33 2002: DEBUG: Query is:
select
NASIDENTIFIER,SECRET,IGNOREACCTSIGNATURE,DUPINTERVAL,DEFAULTREALM,NASTYPE,SNMPCOMMUNITY,LIVINGSTONOFFS,LIVINGSTONHOLE,FRAMEDGROUPBASEADDRESS,FRAMEDGROUPMAXPORTSPERCLASSC,REWRITEUSERNAME,NOIGNOREDUPLICATES,PREHANDLERHOOK
from RADCLIENTLIST
Wed Feb 27 10:37:33 2002: ERR:
Execute failed for 'select
NASIDENTIFIER,SECRET,IGNOREACCTSIGNATURE,DUPINTERVAL,DEFAULTREALM,NASTYPE,SNMPCOMMUNITY,LIVINGSTONOFFS,LIVINGSTONHOLE,FRAMEDGROUPBASEADDRESS,FRAMEDGROUPMAXPORTSPERCLASSC,REWRITEUSERNAME,NOIGNOREDUPLICATES,PREHANDLERHOOK
from RADCLIENTLIST': [Microsoft][ODBC SQL Server Driver][SQL Server]Invalid
object name 'RADCLIENTLIST'. (SQL-S0002)[Microsoft][ODBC SQL Server
Driver][SQL Server]Statement(s) could not be prepared. (SQL-37000)(DBD:
st_prepare/SQLPrepare err=-1)Wed Feb 27 10:37:33 2002: ERR: Execute failed
for 'select
NASIDENTIFIER,SECRET,IGNOREACCTSIGNATURE,DUPINTERVAL,DEFAULTREALM,NASTYPE,SNMPCOMMUNITY,LIVINGSTONOFFS,LIVINGSTONHOLE,FRAMEDGROUPBASEADDRESS,FRAMEDGROUPMAXPORTSPERCLASSC,REWRITEUSERNAME,NOIGNOREDUPLICATES,PREHANDLERHOOK
from RADCLIENTLIST': [Microsoft][ODBC SQL Server Driver][SQL Server]Invalid
object name 'RADCLIENTLIST'. (SQL-S0002)[Microsoft][ODBC SQL Server
Driver][SQL Server]Statement(s) could not be prepared. (SQL-37000)(DBD:
st_prepare/SQLPrepare err=-1)
---
ForegroundLogStdoutLogDird:/Radiator-2.18/logDbDird:/Radiator-2.18LogFile
%L/logfile-%d-%m-%Y
# Dont turn this up too high, since all log
messages are logged# to the RADMESSAGES table in the database. 3 will give
you everything# except debugging messagesTrace 4
# PreClientHook to add NAS-Port attributePreClientHook
file:"%D/addNASPort"
# You will probably want to change this to suit your site.# You should
list all the clients you have, and their secrets# If you are using the
Radmin Clients table, you wil probably# want to disable this.#Client
DEFAULT#Secretmysecret#DupInterval
0#/Client
# You can put additonal (or all) client details in your Radmin#
database table# and get their details from there with something like
this:# You can then use the Radmin 'Add Radius Client' to add new
clients.ClientListSQLDBSourcedbi:ODBC:RadminDBUsernameDBAuth/ClientListSQL
#AuthBy RADIUS#Identifier ProxyTofunk#Host
10.2.0.6#Secret test#/AuthBy
#Realm funk# strip Realm#RewriteUsername
s/^([^@]+).*/$1/#AuthBy ProxyTofunk#/Realm
AuthBy RADMINIdentifier RADMINAUTH# Change
DBSource, DBUsername, DBAuth for your database# See the reference
manual. You will also have to # change the one in SessionDatabse
SQL below# so its the
sameDBSourcedbi:ODBC:RadminDBUsernamexxxDBAuthxxxDateFormat
%e %m %Y %TAuthSelect select
PASS_WORD,STATICADDRESS,TIMELEFT,MAXLOGINS from RADUSERS where USERNAME='%n' and
BADLOGINS 8 and VALIDFROM %t and VALIDTO %t#
You can add to or change these if you want, but you# will probably
want to change the database schema
firstAccountingTableRADUSAGEAcctColumnDefUSERNAME,User-NameAcctColumnDefTIME_STAMP,Timestamp,integerAcctColumnDefACCTSTATUSTYPE,Acct-Status-Type,integerAcctColumnDefACCTDELAYTIME,Acct-Delay-Time,integerAcctColumnDefACCTINPUTOCTETS,Acct-Input-Octets,integerAcctColumnDefACCTOUTPUTOCTETS,Acct-Output-Octets,integerAcctColumnDefACCTSESSIONID,Acct-Session-IdAcctColumnDefACCTSESSIONTIME,Acct-Session-Time,integerAcctColumnDefACCTTERMINATECAUSE,Acct-Terminate-Cause,integerAcctColumnDefFRAMEDIPADDRESS,Framed-IP-AddressAcctColumnDefNASIDENTIFIER,NAS-IdentifierAcctColumnDefNASIDENTIFIER,NAS-IP-AddressAcctColumnDefNASPORT,NAS-Port,integerAcctColumnDefDNIS,Called-Station-IdAcctColumnDefDATE,Timestamp,integer-date#
This updates the time and octets left# for this
userAcctSQLStatement update RADUSERS set
TIMELEFT=TIMELEFT-0%{Acct-Session-Time},
