Re: (RADIATOR) unclas mysql socket file
Hugh: Ive sent about 3 unsubscribe requests and I keep getting messages and no messages back from the MajorDomo server one way or another. Can you please remove me? I'm no longer employed where I was so no longer have use of keeping uptodate on Radiator. Thanks much -- Ron Hensley ([EMAIL PROTECTED]) CCNA #10082337 -- - Original Message - From: Michael Hockey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, September 02, 2001 10:27 PM Subject: (RADIATOR) unclas mysql socket file I want to move my mysql mysql.sock= from /tmp to a more suitable directory. I can do this for mysql and other mysql clients by creating a system system my.cnf in /etc. eg [client] socket=/xxx/mysql.sock The other mysql clients recognize this file but I cant seem to get it to work with radiator. What am I missing ? === 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)
Good Morning, Ive been trying to bring up a second server to service a remote POP as a local Radius Server. Whenever Ive brought up the POP, which consists of 30 PRIs worth of lines (690 lines) things will work fine it seems, for a while, then all of the sudden we have only 1 out of 10 at best getting on. The rest show on our Bay Terminal servers as a call in progress, still waiting for a Radius Response of Yes or Not. That is, it shows a call but no username yet. On the radius log side we seem to get radius.log entries that users are being Authenticated and Accepted whom never make it on (Thus those no named entries on our Terminal Servers). So it sounds as if the Term Servers are sending the Auth Requests, Radius Server is getting it, and the Reply is never getting there perhaps. The Term Servers Are Bay Networks 5399s and the Radius Server is on a Sparc running Solaris 2.7 Can you tell me the step by step way to Intelligently get to the bottom of whats happening when this goes on? Id Imagine a combination of Trace 4 logs, and an Ethernet Sniffer on both sides to be assured traffic is making it back and forth. But as you have more then likely run into this before, Id like to hear thoughts on getting to the root of it the fastest and 'Gotchas' to be looking out for. Thanks much === 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) Got error -1 from table handler
Table's damaged, connect to your SQL server, mysql USE RADIUS; mysql CHECK TABLE RADONLINE; You should see it report that the RADONLINE table has errors mysql REPAIR TABLE RADONLINE; Once it finishes you should not get table handler errors anymore and if you run check table again it should report as clean, - Original Message - From: "Jess M Daz" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 15, 2001 5:20 AM Subject: (RADIATOR) Got error -1 from table handler what is the problem? mysql select * from RADONLINE where NASIDENTIFIER = 'xxx.xxx.xxx.xxx'; ERROR 1030: Got error -1 from table handler mysql thank you Jesus M Diaz [EMAIL PROTECTED] Telia Iberia, S.A. Planificacin y Diseo de Red Tfno: +34 91 623 2909 Fax: +34 91 623 2911 === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) IMPORTANT Needed Pakages for MySql
Title: IMPORTANT - multiple accounting records in SQL Due to a crash I need to reinstall Radiator on one of my Solaris boxes, running Perl, and using MySql support to another box. I failed to properly document the steps I took to get it all working on the other maches and more specifically the exact packages I need. Docs say perl 5.004 or better. Ive got that Docs say MD5 1.7 or better which I take it to be Digest-MD5-2.12.tar.gz Docs say DBI 0.9 or better, what file name is that? There are so many DBI related file names im confused at the CPAN archive. I guessed at DBI-1.14.tar.gz Docs say the DBD module for your SQL version, this is where I get real lost as there are so many DBD modules at CPAN. Im running mysql 3.23.2 , what file name would that be? Guessed at DBD-Solid, fail as it says it requires other Solid Packages (ERROR: solid include files not found.)Guessed at DBD-DB2 failed (DB2_HOME environment variable must be set to installed location of DB2.) Has anyone got a file list of the required package names to go from scratch on Solaris to installed with Radiator?
Re: (RADIATOR) radwho stopped working after changing IP addresses
As the RADONLINE databases is ever changing you can just whack it 'delete from RADONLINE;' and let it start over. Within an hour or two (Once everyone on before you reset it has logged off) you'll be back in sync. I had errors like that once when trying to import mysql update.log files from a primary to a secondary server. If there are entries in there, that are beleived to be gone already (Things got really out of whack somehow), the UPDATE statements can cause an error, duplicate key value or something like that. Deleting all records cures that. If not that, you should be able to see the exact errors in your mysql logfile 'tail -f /usr/local/mysql/data/logfile' and watch the exact query (After all radiators variables have been processed and mysql has been called) and hopefully see what the error is more specifically. That and running your server in trace level 4 and watching there, what queries radiator is sending to mysql 'tail -f /var/log/radius/log' - Original Message - From: "Andrew P. Kaplan" [EMAIL PROTECTED] To: "Radiator" [EMAIL PROTECTED] Sent: Thursday, November 02, 2000 9:07 AM Subject: (RADIATOR) radwho stopped working after changing IP addresses I have a pressing issue. I turned off the Global Crossing "T" this past Saturday. The IP block was 206.165.153.x. The main IP address on my Radiator server was 206.165.153.185, however there were other working IP's. With my NAS server pointed at the new IP address. Ever since then radwho stopped working. I can still make a connection to the website http://mozart.cshore.com/cgi-bin/radwho.cgi. But it doesn't display any current data. I couldn't find anything in mysql that was referring to a particular IP address. I did see an error message on the screen: "You have an error in your SQL syntax . . at usr/local/lib/site_perl/Radius/SqlDb.pm line 228" I saw nothing strange on that line. I tried stopping mysql, touching the mysql.log file and restarting. Radwho will then work, but for only one entry. It will only list a single new entry and then stop displaying new logins. Do you have any ideas as to how I could fix it. Andrew P. Kaplan, CNE, MCSE+Internet, MCT, CCNA, CCDA CyberShore, Inc. -- Premium Internet Services -- http://www.cshore.com "The ultimate measure of a man is not where he stands in moments of comfort, but where he stands at times of challenge and controversy." -Martin Luther King, Jr. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) multipul authby's in one realm.
Title: multipul authby's in one realm. Is there away to do this? We are migrating from a flatfile auth system, to a hacked version of AuthBySQL.pm, called AuthbyQIP. Now we need to keep authenticating people off of the flat file, while also authenticating new people off the sql database. Is there a way to do this? Here's what I'm thinking, it doesn't work, but I think it better illustrates what I'm trying to do... This is explained pretry well in the AuthBy secions of the Handlers documentaion. http://www.open.com.au/radiator/ref.html 6.15.15 AuthBy This specifies that the Handler is to be authenticated with an AuthBy clause that is defined elsewhere. The argument must specify the Identifier of the AuthBy clause to use. The AuthBy clause may be defined anywhere else: at the top level, or in a Realm or Handler clause. You can have as many AuthBy parameters as you wish. They will be used in the order that they appear in the configuration file (subject to AuthByPolicy) in the same way as AuthBy clauses. -- So according to this, you can place multiple AuthBy types in the same handler or realm block, and the way its parsed is controlled by the AuthByPolicy setting. Looks like you'd perhaps want a ContinueWhileReject type, so you'll only enter the 2nd AuthBy if the first one didnt get them in, and not bother if they got authenticated by the first method. -- 6.21.1 AuthByPolicy This parameter allows you to control the behaviour of multiple AuthBy clauses inside this AuthBy GROUP. In particular, it allows you to specify under what conditions Radiator will try the next AuthBy clause. If you only have one AuthBy clause, AuthByPolicy is not relevant and is ignored. Recall that for a single Realm, Handler or AuthBy GROUP, you can specify more than one AuthBy clause. The normal behaviour of Radiator is to try to authenticate with the first one. If that authentication method either Accepts or Rejects the request, then Radiator will immediately send a reply to the NAS. If on the other hand the AuthBy Ignores the request, then the next one will be tried. That is the normal and default behaviour, but with AuthByPolicy, you can change it. The permissible values of AuthByPolicy are: ContinueWhileIgnore This is the default. Continue trying to authenticate until either Accept or Reject ContinueUntilIgnore Continue trying to authenticate until Ignore ContinueWhileAccept Continue trying to authenticate as long as it is Accepted ContinueUntilAccept Continue trying to authenticate until it is Accepted ContinueWhileReject Continue trying to authenticate as long as it is Rejected ContinueUntilReject Continue trying to authenticate until it is Rejected anything else Always do every authentication method. Returns the result of the last one.
(RADIATOR)
Evening,
I've got 99% of everything coverted over to use SQL, logging, sessions, and
tested with a few users
as auth-type. However currently I am using Auth-Type = System for unix
password authentication, due
to the way we're setup. I need to block users who belong to a certain unix
group. (only concerned with Primary Group)
This is working fine. However id like to totally switch to SQL. All my users
are in my SQL database, and I added
a field, UNIXGROUP, which holds the unix group for that user.
From what I can tell, the way to do this will be a GlobalVar to hold the
currently being processed users group:
GlobalVar UnixGroup 9002
and then use a PreHandlerHook, to make an SQL query,
SELECT UNIXGROUP FROM SUBSCRIBERS WHERE USERNAME = ' %n';
and store the return in the global %{UnixGroup} variable.
Then, to actually use the group id have
HANDLER UnixGroup=9002
..
/Handler
Is this the correct way to do this, right hook spot and right way to utilize
it in a hanlder?
Any Perl whizzes (Perl Whiz Im not :P ), that know what code would work in a
sub to run that query and
stuff the results in that variable, using Radiators hook system?
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR)
Oh I guess I did skip over the easier way, default AuthSelect is
select PASSWORD from SUBSCRIBERS where USERNAME='%n'
So assuming I wanted to not let users in with the UNIXGROUP Field in the
SUBSCRIBERS Table
of 9206, id do
select PASSWORD from SUBSCRIBERS where USERNAME='%n' AND UNIXGROUP != 9206
Id thought about that, query will come back empty for a user with 9206 in
UNIXGROUP, so they will get an Auth-Reject.
Much simpler...
- Original Message -
From: "Hugh Irvine" [EMAIL PROTECTED]
To: "Ron Hensley" [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, October 18, 2000 8:10 PM
Subject: Re: (RADIATOR)
Hello Ron -
On Thu, 19 Oct 2000, Ron Hensley wrote:
Evening,
I've got 99% of everything coverted over to use SQL, logging, sessions,
and
tested with a few users
as auth-type. However currently I am using Auth-Type = System for unix
password authentication, due
to the way we're setup. I need to block users who belong to a certain
unix
group. (only concerned with Primary Group)
This is working fine. However id like to totally switch to SQL. All my
users
are in my SQL database, and I added
a field, UNIXGROUP, which holds the unix group for that user.
From what I can tell, the way to do this will be a GlobalVar to hold
the
currently being processed users group:
GlobalVar UnixGroup 9002
and then use a PreHandlerHook, to make an SQL query,
SELECT UNIXGROUP FROM SUBSCRIBERS WHERE USERNAME = ' %n';
and store the return in the global %{UnixGroup} variable.
Then, to actually use the group id have
HANDLER UnixGroup=9002
..
/Handler
Is this the correct way to do this, right hook spot and right way to
utilize
it in a hanlder?
Any Perl whizzes (Perl Whiz Im not :P ), that know what code would work
in a
sub to run that query and
stuff the results in that variable, using Radiators hook system?
I think you can do this more simply by changing your AuthSelect statement
to do
the right thing.
However, if you do want to use a PreHandlerHook, you should store your
UnixGroup pseudo-attribute in the current request packet ($p in your
hook),
otherwise you will not be able to set up your Handler(s) as you have shown
above. Do not use GlobalVar's for this, as GlobalVar's are expected to be
used
for unchanging global variables, and there is no guarantee in the future
(with
a threaded version of Radiator) that a GlobalVar will have any relevance
to a
particular radius request packet.
Have a look at the example hooks in "goodies/hooks.txt".
regards
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) RE: Proxy getting no reply
If you haven't overridden it in the radius.cfg file, then its getting its
default ports from the /etc/services file
If you edit that file to have 1645 and 1646 instead of 1812 and 1813(?) and
restart radius, it should
bind to those ports.
You can also override the /etc/services file by adding to the radius.cfg
AuthPort1645
AcctPort1645
- Original Message -
From: "Lisa Goulet" [EMAIL PROTECTED]
To: "'Radiator@Open. Com. Au'" [EMAIL PROTECTED]
Sent: Monday, October 16, 2000 10:58 AM
Subject: (RADIATOR) RE: Proxy getting no reply
Hello again,
Here's a follow up question.
Now I'm seeing on the console that the proxy server is sending on port
1645.
Both servers are listening on 1812. Where is the sending port configured?
Thanks again,
Lisa
-Original Message-
From: Lisa Goulet
Sent: Monday, October 16, 2000 4:05 PM
To: Radiator@Open. Com. Au
Subject: Proxy getting no reply
Hello,
I have a simple set up with one Radiator master and one proxy. When
testing with radpwtst I'm getting a "no reply". I've double checked the
ip address, secret and the ports. I don't see much in the log files.
Here
are my configs:
Proxy:
Trace 4
Foreground
LogStdout
LogDir .
DbDir .
# Handle everyone with RADIUS
Realm DEFAULT
AuthBy RADIUS
AuthPort 1812
AcctPort 1813
Host xxx.xxx.xxx.xxx
Secret mysecret
CachePasswords
CachePasswordExpiry
/AuthBy
/Realm
Master radiator server:
Trace 4
Foreground
LogStdout
LogDir .
DbDir .
AuthPort1812
# AcctPort specifies the port to list on for accounting requests
AcctPort1813
Client DEFAULT
Secret mysecret
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.
ClientListSQL
DBSourcedbi:Pg:dbname=radmin;host=localhost
DBUsername radmin
DBAuth radmin
/ClientListSQL
# Handle everyone with RADMIN
Realm DEFAULT
AuthBy RADMIN
# 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 same
DBSourcedbi:Pg:dbname=radmin;host=localhost
DBUsername radmin
DBAuth radmin
# You can add to or change these if you want, but
you
# will probably want to change the database schema
first
AccountingTable RADUSAGE
AcctColumnDef USERNAME,User-Name
AcctColumnDef TIME_STAMP,Timestamp,integer
AcctColumnDef
ACCTSTATUSTYPE,Acct-Status-Type,integer
AcctColumnDef
ACCTDELAYTIME,Acct-Delay-Time,integer
AcctColumnDef
ACCTINPUTOCTETS,Acct-Input-Octets,integer
AcctColumnDef
ACCTOUTPUTOCTETS,Acct-Output-Octets,integer
AcctColumnDef ACCTSESSIONID,Acct-Session-Id
AcctColumnDef
ACCTSESSIONTIME,Acct-Session-Time,integer
AcctColumnDef
ACCTTERMINATECAUSE,Acct-Terminate-Cause,integer
AcctColumnDef FRAMEDIPADDRESS,Framed-IP-Address
AcctColumnDef NASIDENTIFIER,NAS-Identifier
AcctColumnDef NASIDENTIFIER,NAS-IP-Address
AcctColumnDef NASPORT,NAS-Port,integer
AcctColumnDef DNIS,Called-Station-Id
# This updates the time and octets left
# for this user
AcctSQLStatement update RADUSERS set
TIMELEFT=TIMELEFT-0%{Acct-Session-Time},
OCTETSINLEFT=OCTETSINLEFT-0%{Acct-Input-Octets},
OCTETSOUTLEFT=OCTETSOUTLEFT-0%{Acct-Output-Octets} where USERNAME='%n'
# These are the classic things to add to each users
# reply to allow a PPP dialup session. It may be
# different for your NAS. This will add some
# reply items to everyone's reply
AddToReply Framed-Protocol = PPP,\
Framed-IP-Netmask = 255.255.255.255,\
Framed-Routing = None,\
Framed-MTU = 1500,\
Framed-Compression = Van-Jacobson-TCP-IP
/AuthBy
/Realm
SessionDatabase SQL
# This database spec usually should be exactly the same
# as in AuthBy RADMIN above
DBSourcedbi:Pg:dbname=radmin;host=localhost
DBUsername radmin
Re: (RADIATOR) Load Balancing Radiator
In the main global section
BindAddress 10.0.0.1
Thats the one for the normal auth/accounting information to listen and
respond with.
Make it whichever ip bound to the nic, you want it to use and reload.
- Original Message -
From: "Chris" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, October 16, 2000 1:18 PM
Subject: (RADIATOR) Load Balancing Radiator
I'm trying to load balance radiator across three seperate servers
with an Extreme Summit 7i switch. All servers respond correctly to
requests out of the server farm. However when put in the server farm they
respond to the authentication request with the ethernet ip even though the
request was sent to an ip on the loopback. Because it is responding with
a different ip than what the request was sent to, my portmasters are
ignoring the response. I noticed the 6.27.11 LocalAddress tag but seems
to only work with AuthBy Radius. Is there a way to have radiator respond
with the ip that the request was sent to with AuthBy Unix? The manual
implies that this is default but it doesn't seem to be doing it. (perhaps
because the address is on the loopback?)
Has anyone run into the same problem?
Here is my config:
Foreground
LogStdout #THIS LINE IS FOR TESTING, OUTPUT GOES TO SCREEN
LogDir /var/log/radiator
DbDir /etc/raddb
PidFile /var/run/radiusd.pid
DictionaryFile /etc/raddb/dictionary.livingston
AuthPort1812
AcctPort1813
SnmpgetProg /usr/local/bin/snmpget
Trace 4
SocketQueueLength 10
Client 1.2.3.4
Secretx
DefaultRealm xxx
/Client
Client 2.3.4.5
Secretx
DefaultRealm xxx
/Client
Client 3.4.5.6
Secretx
/Client
Client 7.8.9.1
Secretxx
/Client
Client DEFAULT
Secretxx
DupInterval 2
NasType Livingston
SNMPCommunity frii
LivingstonOffs22
LivingstonHole1
/Client
AuthBy GROUP
Identifier Frii
AuthByPolicy ContinueWhileReject
AuthBy SQL
AuthSelect
AccountingStopsOnly
DBSource x
DBUsernamex
DBAuthxx
AcctSQLStatement insert into data values ('%n',%t,%{Acct
/AuthBy
AuthBy GROUP
AuthByPolicy ContinueUntilReject
AuthBy FILE
Filename /etc/raddb/users-pop
/AuthBy
AuthBy FILE
Filename /etc/raddb/users
/AuthBy
/AuthBy
/AuthBy
AuthBy UNIX
Identifier FriiSystem
Filename /etc/mypasswd
/AuthBy
SessionDatabase SQL
Identifier FriiSessions
DBSource
DBUsernamex
DBAuthxx
AddQuery replace into Sessions values.
CountQuery select NASIDENTIFIER
DeleteQuery delete from Sessions where .
/SessionDatabase
Realm /realm1/i
RewriteUsername s/^([^@]+).*/$1/
AuthBy Frii
SessionDatabase FriiSessions
/Realm
Realm /realm2/i
RewriteUsername s/^([^@]+).*/$1/
AuthBy Frii
SessionDatabase FriiSessions
/Realm
Handler
AuthBy Frii
SessionDatabase FriiSessions
/Handler
Chris Bissell| Front Range Internet, Inc.
[EMAIL PROTECTED]| www.frii.com [EMAIL PROTECTED]
Technical Operations | 970-224-3668 800-935-6527
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Load Balancing Radiator
That is odd. I didnt mention it, but I also use load balancing, though with
a Linux Server doing the clustering
rather then a layer 2 switch. Same concept though, it intercepts the packets
destined for the radius server
ip address, and redirects them to the cluster nodes, who have the ips bound
as loopback addresses, so
that they will not respond to ARP broadcasts and interfere with the cluster
server doings its job.
Anyways, the BindAddress is working on my 3 Suns, Solaris 2.6 and 7.0, when
using the loopback, clustered
address. The only other time I had the problem like that, is when my NAS
servers were speaking to
the radius servers, by way of a different ip address then the replies were
coming back from, as you surmised.
However on every flavor of radius ive used, using a localaddress or
bindaddress to force the issue has solved it.
Heh sounds like a packet sniffer is the only way to go, as well as trace 4
logs on Radiator and any debug
logs your NASs can produce.
- Original Message -
From: "Chris" [EMAIL PROTECTED]
To: "Ron Hensley" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, October 16, 2000 5:21 PM
Subject: Re: (RADIATOR) Load Balancing Radiator
I tried this, so also to listen only on that ip, however this also did not
appear to work possibly because the ip is bound to the loopback (it has to
be bound to the loopback because of the method of load balancing the
Summit 7i is doing.
So when I did this, radiator only responded to requests on 1.2.3.4 (which
is configured on the loopback) but replied to those requests with the
ethernet ip.
I'm setting up a packet sniffer to confirm this wednesday AM so I don't
have to rely on lucent debug.
Chris
In the main global section
BindAddress 10.0.0.1
Thats the one for the normal auth/accounting information to listen and
respond with.
Make it whichever ip bound to the nic, you want it to use and reload.
- Original Message -
From: "Chris" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, October 16, 2000 1:18 PM
Subject: (RADIATOR) Load Balancing Radiator
I'm trying to load balance radiator across three seperate servers
with an Extreme Summit 7i switch. All servers respond correctly to
requests out of the server farm. However when put in the server farm
they
respond to the authentication request with the ethernet ip even though
the
request was sent to an ip on the loopback. Because it is responding
with
a different ip than what the request was sent to, my portmasters are
ignoring the response. I noticed the 6.27.11 LocalAddress tag but
seems
to only work with AuthBy Radius. Is there a way to have radiator
respond
with the ip that the request was sent to with AuthBy Unix? The manual
implies that this is default but it doesn't seem to be doing it.
(perhaps
because the address is on the loopback?)
Has anyone run into the same problem?
Here is my config:
Foreground
LogStdout #THIS LINE IS FOR TESTING, OUTPUT GOES TO SCREEN
LogDir /var/log/radiator
DbDir /etc/raddb
PidFile /var/run/radiusd.pid
DictionaryFile /etc/raddb/dictionary.livingston
AuthPort1812
AcctPort1813
SnmpgetProg /usr/local/bin/snmpget
Trace 4
SocketQueueLength 10
Client 1.2.3.4
Secretx
DefaultRealm xxx
/Client
Client 2.3.4.5
Secretx
DefaultRealm xxx
/Client
Client 3.4.5.6
Secretx
/Client
Client 7.8.9.1
Secretxx
/Client
Client DEFAULT
Secretxx
DupInterval 2
NasType Livingston
SNMPCommunity frii
LivingstonOffs22
LivingstonHole1
/Client
AuthBy GROUP
Identifier Frii
AuthByPolicy ContinueWhileReject
AuthBy SQL
AuthSelect
AccountingStopsOnly
DBSource x
DBUsernamex
DBAuthxx
AcctSQLStatement insert into data values ('%n',%t,%{Acct
/AuthBy
AuthBy GROUP
AuthByPolicy ContinueUntilReject
AuthBy FILE
Filename /etc/raddb/users-pop
/AuthBy
AuthBy FILE
Filename /etc/raddb/users
/AuthBy
/AuthBy
/AuthBy
AuthBy UNIX
Identifier FriiSystem
Filename /etc/mypasswd
/AuthBy
SessionDatabase SQL
Identifier FriiSessions
DBSource
DBUsernamex
DBAuthxx
AddQuery replace into Sessions values.
CountQuery select NASIDENTIFIER
DeleteQuery delete from Sessions where .
/SessionDatabase
Realm /realm1/i
RewriteUsername s/^([^@]+).*/$1/
AuthBy Frii
SessionDatabase FriiSessions
/Realm
Realm /realm2/
Re: (RADIATOR) (Fwd) can i have two accounting tables?
From the Documentation, Section 6.26 AuthBy SQL 6.26.8 AccountingTable This is the name of the table that will be used to store accounting records. Defaults to "ACCOUNTING". If AccountingTable is defined to be an empty string, all accounting requests will be accepted and acknowledged, but no accounting data will be stored. You must also define at least one AcctColumnDef before accounting data will be stored. The AccountingTable table name can contain special formatting characters: table names based on the current year and/or month might be useful, so you can rotate your accounting tables. # store accounting records in RADUSAGEmm table AccountingTable RADUSAGE%Y%m So you just need to add an ACcountingTable entry to each AuthBy SQL statement, telling it what table to use. ------ Ron Hensley ([EMAIL PROTECTED]) CCNA #10082337 Network Administrator - ICNet Internet Services -- - Original Message - From: "Mike McCauley" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 16, 2000 9:00 AM Subject: (RADIATOR) (Fwd) can i have two accounting tables? --- Forwarded mail from "Hakim Tass" [EMAIL PROTECTED] From: "Hakim Tass" [EMAIL PROTECTED] To: "Radiator mailing list" [EMAIL PROTECTED] Subject: can i have two accounting tables? Date: Sun, 15 Oct 2000 15:28:34 +0300 hello!!! can i have different accountingtables for each AuthBy SQL clause that i write. i wanted to keep the accounting information in separate tables for different group of users. Regards Hakim ---End of forwarded mail from "Hakim Tass" [EMAIL PROTECTED] -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 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 etc etc on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Accounting
I get that from Connect-Info. I guess it would depend on what information your NAS is sending over, but a quick look with trace 4 of what information is getting sent from your NAS should show what Attribute has the information you want. I use this: AcctColumnDef CONNECTINFO,Connect-Info (Of course I had to add the CONNECTINFO field to the ACCOUNTING table) A search of your dictionary for the word connect should pull up any usable Attributes [ronh@shore]$grep -i connec /etc/Radiator/dictionary ATTRIBUTE Connect-Info77 string ATTRIBUTE Connect-Rate1007integer -- Ron Hensley ([EMAIL PROTECTED]) CCNA #10082337 Network Administrator - ICNet Internet Services -- On Thu, 12 Oct 2000, Matthias Fechner (Temp) wrote: Hi i need in the accounting the connection speed(like 64000 for one isdn-channel or 128000 for two isdn channel). With the Line: AcctColumnDef ACCTTERMINATECAUSE,Acct-Terminate-Cause I can specify the column in the database, but what keyword(variable) i need(the name) for the connectionspeed? Matthias Fechner === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Multiple databases
I dont get the Framed-IP-Address on Start records, thus my SQL doesn't log them to the RADONLINE database A look at the printout detail files, shows that information is not sent by my NAS terminal servers, Bay 5399's. When a user gets assigned a static ip address, with a reply item of Framed-IP-Address = x.y.z.a then that does get logged, and does therefore make it into SQL. However for the regular users whom get Framed-IP-Address = 255.255.255.254 which tells the NAS to dynamically assign the address, it doesn't get sent in accounting packets. Is this normal or is there a way to pluck the dynamic ip address the NAS assigns and get it logged? The Framed-IP-Address does show on all Stop records. Don't know if this is something the NAS would have to be taught to do perhaps, to send that info after its assigned the ip address? Thu Oct 12 04:07:23 2000 Acct-Status-Type = Start Acct-Session-Id = "ae0b0862" Acct-Delay-Time = 24 NAS-Port = 41 Annex-83 = "00N133" NAS-Port-Type = Async Annex-Unauthenticated-Time = 27 User-Name = "qism" Service-Type = Framed-User Framed-Protocol = PPP Called-Station-Id = "xxx" Calling-Station-Id = "xx" Idle-Timeout = 900 Connect-Info = "48000 21600 V.90" Annex-Transmit-Speed = 48000 Annex-Receive-Speed = 21600 Annex-96 = "V.90" Annex-86 = "V.42bis" Annex-97 = "V.42" Annex-89 = "00031" Annex-94 = "00022" Annex-82 = "0001" Annex-81 = "0001" Acct-Authentic = RADIUS NAS-IP-Address = x.y.z.a Timestamp = 971338019 - Original Message - From: "Hugh Irvine" [EMAIL PROTECTED] To: "Elias" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, October 12, 2000 9:10 PM Subject: Re: (RADIATOR) Multiple databases Hello Elias - Hi, I want to set-up a multiple database environment so that if one database goes down, the backup will take over. My config is as shown below. Is there anything wrong with it? When radiusxx goes down, radiator does not switch over to radiusyy automatically. Thanks. Realm xxx.xxx.xxx AuthBy SQL DBSource radiusxx .. .. /AuthBy AuthBy SQL DBSource radiusyy .. .. /AuthBy /Realm SessionDatabase SQL DBSource radiusyy .. .. /SessionDatabase To set up multiple databases, you specify them like this: Realm xxx.xxx.xxx AuthBy SQL DBSource radiusxx DBSource radiusyy .. .. /AuthBy /Realm Have a look at section 6.26 in the Radiator 2.16.3 reference manual for further details on AuthBy SQL. regards Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) SQL Logging
I need 2 AuthBy's, but only the first one, AuthBy RADIUS, does the pass checking, (Proxy to third party radius server), but then a second AuthBy SQL gets entered which logs the Start-Stop records for accounting purposes. The users on those remote realms dont exist in my database however, so this second AuthBy cant do anything but log, as it would Reject the users name/pass if it tried. Here's a Realm statement from my radius.cfg with the passes removed. Seems I need a second AuthBy SQL/AuthBy with the appropriate connection string, username, password so it can talk to the SQL server. However how to just accept whats there and log it to ACCOUNTING. Realm realm.net RewriteUsername s/^([^@]+).*/$1/ AuthBy RADIUS Host remote.server.net Secret password LocalAddress 216.240.X.X AddToReply Port-Limit=1 /AuthBy /Realm === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL Logging
This worked like a charm. Hugh. you are an amazing, workaholic individual. Thanks once again. - Original Message - From: "Hugh Irvine" [EMAIL PROTECTED] To: "Ron Hensley" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, October 09, 2000 7:40 PM Subject: Re: (RADIATOR) SQL Logging Hello Ron - On Tue, 10 Oct 2000, Ron Hensley wrote: I need 2 AuthBy's, but only the first one, AuthBy RADIUS, does the pass checking, (Proxy to third party radius server), but then a second AuthBy SQL gets entered which logs the Start-Stop records for accounting purposes. The users on those remote realms dont exist in my database however, so this second AuthBy cant do anything but log, as it would Reject the users name/pass if it tried. Here's a Realm statement from my radius.cfg with the passes removed. Seems I need a second AuthBy SQL/AuthBy with the appropriate connection string, username, password so it can talk to the SQL server. However how to just accept whats there and log it to ACCOUNTING. You would do something like this: # configure AuthBy SQL for accounting only # note empty AuthSelect # Identifier will be used later AuthBy SQL Identifier SQLAccountingOnly DBSource DBUsername DBAuth . AuthSelect AccountingTable ACCOUNTING AcctColumnDef . /AuthBy # configure AuthBy RADIUS # Identifier will be used later AuthBy RADIUS Identifier CheckRADIUS Host remote.server.net Secret password LocalAddress 216.240.X.X AddToReply Port-Limit=1 /AuthBy # configure Realm with AuthByPolicy # AuthBy CheckRADIUS is last, as it forks and doesn't return Realm realm.net RewriteUsername s/^([^@]+).*/$1/ AuthByPolicy ContinueAlways AuthBy SQLAccountingOnly AuthBy CheckRADIUS /Realm hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Stop Responding
Hugh, Think i keyed onto the problem already, so im goign to hold off. The one change that has been made was to start limited simultaneous usage, with DBM and with BayFinger as the NasTYPE. I believe the fingers were backing up, or slow to respond and were the culprit. After switching to Bay, (snmp version), its run consitantly overnight and thismorning on the problem server. The one other possibilty is the 10bT link between the 2 radius servers, sharinf an NFS link to the SessionDatabase file, perhaps a file locking problem. The computer having the problems is the one with the actual local file however, so i wouldnt think its nfs access time problems, as that would show on the other serer that actually has to write to the file over the network. If it continues to behave strangely ill send over the configs requested. Thanks much. -- Ron Hensley ([EMAIL PROTECTED]) CCNA #10082337 Network Administrator - ICNet Internet Services -- On Tue, 26 Sep 2000, Hugh Irvine wrote: Hello Ron - On Tue, 26 Sep 2000, Ron Hensley wrote: Ive had a strange occurance today on one of my radius servers. It just stops responding though its still running after being up no more then 5 minutes. Stopped/Started many times, a few times with trace level 4 for heavy debug info. Nothing... just stops apparantly in the middle of logging someone in. Its been working fine for the week ive been using it. At one point i noticed my server getting slow as well, and TOP showed the radiusd taking up 25% CPU resources. Any hints on how to track down what could be making it hang? Could you please send me what version of Perl you are using, what version of Radiator, and what hardware and software platform you are running on. I will also need to see a copy of your configuration file (no secrets), together with the trace 4 debug. thanks Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Stop Responding
Ive had a strange occurance today on one of my radius servers. It just stops responding though its still running after being up no more then 5 minutes. Stopped/Started many times, a few times with trace level 4 for heavy debug info. Nothing... just stops apparantly in the middle of logging someone in. Its been working fine for the week ive been using it. At one point i noticed my server getting slow as well, and TOP showed the radiusd taking up 25% CPU resources. Any hints on how to track down what could be making it hang? === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Blocking by Unix Group Membership
Greets. I've just migrated from Cistron to Radiator. Just about everything is setup to work as it did with Cistron except for blocking by Unix Group. DEFAULT Group = "ssby", Auth-Type = Reject Reply-Message = "Error: Email Only Account, Please use your dialup account username!" DEFAULT Group = "seaston", Auth-Type = Reject Reply-Message = "Error: Email Only Account, Please use your dialup account username!" That worked in Cistron but wont in Radiator. (In the users file of course) In my radius.cfg I use AuthBy File and use a users file which has AuthType = System Checks. A few uses who get static ips, and the rest a default clause to login and let the NAS dynamically assign ips from its own pools. Somewhere along the way i need to Reject mail account groups as defined in the /etc/group file. Thanks for any pointers. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
