(RADIATOR) Accounting database retry agressiveness...
Last Friday, the server that houses our Rodopi database had a massive hardware failure. As of yet, I am not 100% sure just what the extents of the damage is. Most of the server was replaced just to get it back online as quick as possible. To make a long story short, it was down for 6 days. Our Radiator Radius server reports accounting data to the aformentioned Rodopi database. Authentication is pulled off of a Linux MySQL server, so our users were still able to connect. Ironically enough, even though Rodopi has provisions for serving up Radius right from it's own database, I chose to serve Radius from a seperate out of concern for "What if the Rodopi machine goes down?". Once the Rodopi machine got back online, one of the NT admins noticed that radiusd was no longer connecting and reporting accounting data. I sent a -HUP to radiusd...nothing. Only after completely killing and restarting radiusd, did it resume reporting accounting data to the Rodopi database. I'm just curious what the timeouts and/or agressiveness of the accounting database connectivity is? Also...While I'm on the subject of database connectivity, this same NT admin noticed and commented on how radiusd connects and stays connected to the Rodopi database constantly. He is of the opinion that radiusd(and any other clients, for that matter) should connect and disconnect for every query/write. He feels that performance is not an issue since database servers are designed to, and expect to, take rapid connects, queries/writes and disconnects. "That's their job.", he says. Though I have an opinion on the subject, I promised I would just pose the question to the list and see what you guys had to say. What you about you, Hugh? What is the official word from the development team on this issue? -Danny === 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) Attribute number 39051 (vendor 429) is not defined in your dictionary
I'm getting a lot of these spewed out to the Radius log: begin snip Mon Apr 24 19:20:58 2000: ERR: Attribute number 38998 (vendor 429) is not defined in your dictionary Mon Apr 24 19:20:58 2000: ERR: Attribute number 39000 (vendor 429) is not defined in your dictionary Mon Apr 24 19:20:58 2000: ERR: Attribute number 39001 (vendor 429) is not defined in your dictionary Mon Apr 24 19:20:58 2000: ERR: Attribute number 39051 (vendor 429) is not defined in your dictionary end snip I understand *why* it's being generated. My question is, what can I do about it? Is there an updated dictionary file that addresses this specific attribute? Everything appears to be working. That is, my users are authenticating, etc... But, this is wasting a lot of space in the log file. Any suggestions? The NAS is a 3Com Total Control chassis using a HiPer ARC router. -Danny === 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) Authenticate from Postgres/Account to MSSQL?
Is it possible to authenticate off one datasource but account to another? We would like to authenticate off of a Postgres database, which we do now, but send the Accounting information to an MSSQL server.does Radiator allow for this? Brian Brian, I asked that same exact question, only worded a little different, a few months back. Here is the relevant parts of the response I got. Hope this helps. --- I now need some input on configuration. I would like to, if possible, use the MySQL database for authentication, yet have the accounting info available to Rodopi. How would one go about this? Is it possible to point Radiator to the MySQL database for security and point it to the Rodopi database for accounting? It is quite simple to do what you wish with cascaded AuthBy's, something like this would be close: # configure two AuthBy clauses # the first does accounting only (note empty AuthSelect) # the second does authentication only (empty AccountingTable) # and multiple AuthColumnDef's for reply items Handler AuthByPolicy ContinueAlways AuthBy RODOPI AuthSelect DBSource DBAuth DBUsername /AuthBy AuthBy SQL AccountingTable DBSource DBAuth DBUsername AuthSelect select AuthColumnDef . AuthColumnDef /AuthBy /Handler Have a look at section 6.24 in the Radiator 2.14.1 reference manual for further details. There are also examples in the Radiator distribution in the files radius.cfg and goodies/sql.cfg. hth Hugh === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Linux and AuthBy RODOPI (DBD::Sybase) - UPDATE
Hugh, It turns out it was an issue at the MS SQL server. The server was not accepting connections via TCP. After our resident NT guru went in and enable TCP connections at the SQL server, DBI hooked right up with no problem. -Danny === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Newbie check items question....
The past few weeks have been a self-help course in Radius for me. When I came on board here at Techcom roughly a year and a half ago, I was hired on as a help desk rep. In that time, I have moved up to the position of system/network administrator. Suffice it to say that one of my stengths is that I am a quick learner. It doesn't hurt, either that I very much enjoy what I do. A lot of the systems that were in place when I came here were...well, for lack of a better term, bubble gum and duct taped together. I am slowly getting in order areas that have been neglected over time. One of the largest areas of neglect has been our Radius authentication, which is currently being handled by an NT server with one foot in the digital grave running 3Com SA. Up to now, RADIUS has been an area I have not had to deal with much at all. If RADIUS starts acting screwy, just reboot the machine and hope it comes back up. Last week's east-coast "blizzard" afforded me some time at home without ringing telephones and other distractions to work a bit on getting Radiator cofigured, as well as hammering out the necessary code to get RODOPI managing the MySQL database that will back Radiator. In looking over the examples in /goodies, the documenation regarding AuthBy SQL and the example database created with mysqlCreate.sql, I am a bit confused over one issue. How do "check attributes" come into during a RADIUS authentication? Again, I am a bit new to RADIUS and do not yet have a full grasp on the protocol. As I understand it, the NAS send a RADIUS request to the RADIUS server consisting of an encrypted username and password. That username and password is checked against an authentication database of some type and is either rejected or athenticated. An authentication is accompanied by attributes that give the NAS certain configuration parameters for that particular session. This brings me to ask the question, "Where do "check attributes" come into play." I assume these "check attributes" are sent by the NAS? But, what determines their value? Do I need to implement any "check attributes" in my config? How will I know if I do? At present, our needs are pretty basic and straight forward: - one 3Com Total Control hub - one domain - mostly 56K dialups, but a handfull of ISDN centrexes rolling in which require static IPs and no timeouts Thanks in advance to anyone who can offer an explanation and/or point me in the right direction here. -Danny === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Linux and AuthBy RODOPI (DBD::Sybase)
Is anyone here using Radiator under Linux and Authby RODOPI? More to the point, has anyone successfuly hooked up to a MS SQL database using DBD::Sybase??? I have installed the Sybase client libraries. I have compiled the DBD_Sybase package. I have edited the "interfaces" file in the Sybase directory: --- MAIL1 query tcp eth0 209.96.160.15 1433 master tcp eth0 209.96.160.15 1433 --- I have set the envs SYBASE, DSQUERY and SYBPLATFORM. ...And, this is what gets kicked back at me when I try to connect: connection to database failed: DBI-connect failed: OpenClient message: LAYER = (5) ORIGIN = (3) SEVERITY = (5) NUMBER = (4) Message String: ct_connect(): network packet layer: internal net library error: Net-Lib protocol driver call to connect two endpoints failed Operating System Error: Socket connect failed - errno 111 I'm pretty certain that it's reading the interfaces file. I had attempted a few connects before setting up the interfaces file and the errors were indicating that it couldn't find the server name. After creating the above entry in the interfaces file, the errors changed to what you see above. Any thoughts? -Danny === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Help needed with hooking up to MySQL database!
Hello Danny - On Tue, 21 Dec 1999, Danny Whitesel wrote: We just recently purchased Radiator with the intention of using it with a MySQL database. The section of the configuration reference is a bit confusing as to exactly how to configure for MySQL. Following are the errors that I get when I try to launch radiusd. I've spaced the output out a little to make it easier to read here. And, yes...I know this reveals critical security information. Not knowing if the problem may be in an illegal character, I felt it was necessary to include everything. I fully intend on changing the passwords and/or logins after the problem is resolved. Sounds like you have not installed the DBI and DBD modules for Perl. http://www.perl.com/CPAN-local/modules/by-module/DBI/DBI-1.13.tar.gz http://www.perl.com/CPAN-local/modules/by-module/DBD/Msql-Mysql-modules-1.2 210.tar.gz hth Hugh After I posted that, I went back and started digging a deeper. I did install DBI and the MySQL modulesor, so I thought. I remembered seeing an error when I did the "make test" for the MySQL modules. But, when I ran "make test" a second time, there were no errors. At the time, like an idiot, I didn't think anything of it. Turns out, there is a problem with the MySQL module compiling on my system. From the docs in the tarball, the error I am seeing has something to do with Perl and MySQL not being comiled with the same comiler. Mysql was compile using GCC. I know because I installed MySQL from the tarball. Perl, on the other hand, was installed from a binary RPM...the one that came with RedHat 5.2. If I understand the issue correctly, the next step for me to do is remove the RPM install of Perl from that machine and compile/install Perl from a tarball, making sure the Makefile specifies GCC as the compiler? Has anyone else run into this before? Does anyone have any other suggestions or input? I am really not looking forward to re-compiling Perl. -Danny === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Help needed with hooking up to MySQL database!
We just recently purchased Radiator with the intention of using it with a MySQL database. The section of the configuration reference is a bit confusing as to exactly how to configure for MySQL. Following are the errors that I get when I try to launch radiusd. I've spaced the output out a little to make it easier to read here. And, yes...I know this reveals critical security information. Not knowing if the problem may be in an illegal character, I felt it was necessary to include everything. I fully intend on changing the passwords and/or logins after the problem is resolved. ---begin errors snip--- [root@amy goodies]# radiusd -config_file=tcm4.cfg -dictionary_file=../dictionary.usr Can't read $DBI::errstr, last handle unknown or destroyed at /usr/lib/perl5/site_perl/Radius/SqlDb.pm line 127, FILE chunk 33. Mon Dec 20 15:42:17 1999: ERR: Could not connect to SQL database with DBI-connect dbi:mysql:tcm_radius:209.96.160.7:3306, amyradiator, anl!^nwl: Mon Dec 20 15:42:17 1999: ERR: Could not connect to any SQL database. Request is ignored. Backing off for 600 seconds ---end errors snip--- The config file which produced those errors is basiscally the goodies/sql.cfg with the DBSource, DBUsername and DBAuth lines changed to reflect our MySQL setup. Here is the entire config file... ---begin tcm4.cfg--- # common-sql.cfg # # Example Radiator configuration file that allows you to # authenticate from an SQL database. # With Radiator you can interface with almost any databse schema, # and there are many more configurable parameters that allow you # to control database fallback, select statements, column names # and arrangements etc etc etc. # See the reference manual for more details. # This is a very simple exmaple to get you started. It will # work with the tables created by the goodies/*.sql scripts. # # You should consider this file to be a starting point only # $Id: sql.cfg,v 1.3 1999/07/29 02:38:10 mikem Exp $ Foreground LogStdout LogDir . DbDir . # You will probably want to change this to suit your site. Client DEFAULT Secret mysecret DupInterval 0 /Client # You can put client details in a database table # and get their details from there with something like this: ClientListSQL DBSourcedbi:mysql:tcm_radius:209.96.160.7:3306 DBUsername amyradiator DBAuth anl!^nwl /ClientListSQL # This will authenticate users from SUBSCRIBERS Realm DEFAULT AuthBy SQL # Adjust DBSource, DBUsername, DBAuth to suit your DB DBSourcedbi:mysql:tcm_radius:209.96.160.7:3306 DBUsername amyradiator DBAuth anl!^nwl # You may want to tailor these for your ACCOUNTING table AccountingTable ACCOUNTING AcctColumnDef USERNAME,User-Name AcctColumnDef TIME_STAMP,Timestamp,integer AcctColumnDef ACCTSTATUSTYPE,Acct-Status-Type 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 AcctColumnDef NASIDENTIFIER,NAS-Identifier AcctColumnDef NASPORT,NAS-Port,integer AcctColumnDef FRAMEDIPADDRESS,Framed-IP-Address /AuthBy /Realm ---end tcm4.cfg--- "tcm_radius" is the MySQL database name and "amyradiator" is the username which has privs from the IP address of the Radiator machine. From the Radiator machine, I can connect to the MySQL database "tcm_radius" using the MySQL command line client. This confirms it is not an access privilege issues at the MySQL server. I can connect and run SQL queries to view the sample data that the mysqlCreate.sql script inserted. Anyone have any ideas? I am stumped and need to get this up and running as soon as possbile. The accounting staff here would like RODOPI automatically handling dial-in account management by the start of the new year. Danny Whitesel Techcom.net, Inc === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
