RE: (RADIATOR) Question: Authenticate by unix, but use SQL accounting?
Looks a little like my question a couple of weeks back - 26/02/99 >Do something like this: > > > AuthByPolicy ContinueWhileIgnore > > DBSource > . > > # This disables SQL auth > AuthSelect > # This enables SQL accounting > AccountingTable yyy > ActColumnDef > > > > Filename whatever > > AcctLogFileName youracctdetailflatfilename > -- Stephen Ollis <[EMAIL PROTECTED]> Ph: +61 2 9911 1606(BH) Team Leader, Server Systems - Network Engineering +61 2 9911 1555(FAX) AT&T EasyLink Services, Lvl 8, 15 Orion Rd, Lane Cove, NSW 2066 Australia 'There is no traffic jam on the extra mile.' - Zig Ziegler > -Original Message- > From: Lon R. Stockton, Jr. [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 11, 1999 9:33 AM > To: mike grommet > Cc: [EMAIL PROTECTED] > Subject: Re: (RADIATOR) Question: Authenticate by unix, but use SQL > accounting? > > > > On Wed, 10 Mar 1999, mike grommet wrote: > > > For management purposes, I would like to be able to keep my > authentication > > working as it is with my unix users file, but I would like to > > store all accounting information, and session limit stuff in a SQL > > database... > > 'Tis what I'm doing at the moment, albeit I have my previous radius > server still doing authentication on another > machineRadiator doesn't > even see the auth requests at this point in time. Basically, I'm > giving Radiator (and the server I constructed for it) a 'shakedown > cruise' prior to making it do mission-critical work. So my config > is fairly simple since all my Radiator is seeing is accounting packets > and stuffing them in a SQL (Postgres) database. > > Further, as soon as I'm satisfied with the stability of my new server, > I'll be doing auth on it too, but the auth will be by another SQL > database...I want to get away from that unix passwd file crap asap. > > > >From reading the docs, it seems radiator can do this if I > am doing authby > > SQL, > > but doesnt seem to include possibilities for this > scenario... Am I missing > > something? > > I'm shooting in the dark kinda as a newbie to the Radiator > configuration, > but I suspect that you'd have two authby clauses and a > ContinueWhileAccept > keyword or somesuch. The first authby clause deals with your > passwd file > authentication and doesn't do any accounting. The second authby clause > doesn't do auth but stuffs the accounting in a SQL database. > The Continue* > keyword (whichever one it really is) ensures that a packet has to pass > thru both. > > I'm sure there's a way to config it, but if all else fails, you could > always just run two instances of Radiator on different ip's on the > server in question, and config one to do authby unix for your auth > stuff and the other to do authby sql for your acco stuff. Messy and > inelegant if you ask me, but it's always nice to have a last-resort > that is sure to work. (: > > > It sure would be nice to be able to do queries to an sql > database to check > > customer usage and such. > > That's what I thought, and boy did I underestimate how nice it really > is. I knew it'd be nice, but I really had no idea how great it was > until the db was there and AnyDataIWanted suddenly became no more of > an issue than how to properly word my sql query. I've spent a couple > of entire nights playing with all the queries that I can now do and > finding out all kinds of stuff about my statistics. I can only say > that I shoulda been doing this from the beginning. > > > I realize I could make an SQL database out of the unix > password file, but I > > would prefer to not > > have to do this to achieve this functionality... > > That's my current plan, as soon as my new server with its > linux, radiator, > postgres, perl and apache shows me a month of continous troublefree > uptime, I'm switching to doing my auth via sql as well. Same reason; > having data in a *real* database makes everything easier. No more > greppin' through a passwd file to find out who's on that server or > how many accounts or or or. > > Especially when it comes to interesting things like having different > check/reply items. I'm seeing a web page my customers can go to and > specify that their child's account can't log in after 11pm, or that > all their packets get routed thru our in-h
Re: (RADIATOR) Question: Authenticate by unix, but use SQL accounting?
On Wed, 10 Mar 1999, mike grommet wrote: > For management purposes, I would like to be able to keep my authentication > working as it is with my unix users file, but I would like to > store all accounting information, and session limit stuff in a SQL > database... 'Tis what I'm doing at the moment, albeit I have my previous radius server still doing authentication on another machineRadiator doesn't even see the auth requests at this point in time. Basically, I'm giving Radiator (and the server I constructed for it) a 'shakedown cruise' prior to making it do mission-critical work. So my config is fairly simple since all my Radiator is seeing is accounting packets and stuffing them in a SQL (Postgres) database. Further, as soon as I'm satisfied with the stability of my new server, I'll be doing auth on it too, but the auth will be by another SQL database...I want to get away from that unix passwd file crap asap. > >From reading the docs, it seems radiator can do this if I am doing authby > SQL, > but doesnt seem to include possibilities for this scenario... Am I missing > something? I'm shooting in the dark kinda as a newbie to the Radiator configuration, but I suspect that you'd have two authby clauses and a ContinueWhileAccept keyword or somesuch. The first authby clause deals with your passwd file authentication and doesn't do any accounting. The second authby clause doesn't do auth but stuffs the accounting in a SQL database. The Continue* keyword (whichever one it really is) ensures that a packet has to pass thru both. I'm sure there's a way to config it, but if all else fails, you could always just run two instances of Radiator on different ip's on the server in question, and config one to do authby unix for your auth stuff and the other to do authby sql for your acco stuff. Messy and inelegant if you ask me, but it's always nice to have a last-resort that is sure to work. (: > It sure would be nice to be able to do queries to an sql database to check > customer usage and such. That's what I thought, and boy did I underestimate how nice it really is. I knew it'd be nice, but I really had no idea how great it was until the db was there and AnyDataIWanted suddenly became no more of an issue than how to properly word my sql query. I've spent a couple of entire nights playing with all the queries that I can now do and finding out all kinds of stuff about my statistics. I can only say that I shoulda been doing this from the beginning. > I realize I could make an SQL database out of the unix password file, but I > would prefer to not > have to do this to achieve this functionality... That's my current plan, as soon as my new server with its linux, radiator, postgres, perl and apache shows me a month of continous troublefree uptime, I'm switching to doing my auth via sql as well. Same reason; having data in a *real* database makes everything easier. No more greppin' through a passwd file to find out who's on that server or how many accounts or or or. Especially when it comes to interesting things like having different check/reply items. I'm seeing a web page my customers can go to and specify that their child's account can't log in after 11pm, or that all their packets get routed thru our in-house filtering software. I'm also seeing policies such as 'if your bill is 30 days past due, you can only log on if 10% of my modems are idle; if you're 60 days past due, you can only access email and local resources...no surfin for you ya bum, and if you're 90 everything you do takes you to a 'pay your bill' webpage. And at 120...well, the results of a simple sql query gets auto-emailed to my lawyer. *grin*) Lon Stockton MoonStar === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Question: Authenticate by unix, but use SQL accounting?
HI Mike, You sure can. Do something like this : (For an ODBC DB...but similar for others) AuthByPolicy ContinueUntilReject AuthSelect DBSourcedbi:ODBC: DBUsername xxx DBAuth AccountingTable %Y%m AccountingStopsOnly ## TABLE COLUMN ## NAS RESPONSE ##type AcctColumnDef ACCTSESSIONID,Acct-Session-Id AcctColumnDef USERNAME,User-Name ... AcctColumnDef ASCENDXMITRATE,Ascend-Xmit-Rate,integer AcctColumnDef ASCENDDATARATE,Ascend-Data-Rate,integer Identifier NTSystem Domain .xxx.xxx (Or replace the last one with Unix or File or whatever) Regards, Anton Sparrius --- Smarter Wayhttp://www.smart.net.au Email[EMAIL PROTECTED] Phone (03) 9846 1711 Melb 1800-240-829 Sydn 1800-888-761 -Original Message- From: mike grommet <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Thursday, March 11, 1999 4:12 AM Subject: (RADIATOR) Question: Authenticate by unix, but use SQL accounting? >For management purposes, I would like to be able to keep my authentication >working as it is with my unix users file, but I would like to >store all accounting information, and session limit stuff in a SQL >database... > >From reading the docs, it seems radiator can do this if I am doing authby >SQL, >but doesnt seem to include possibilities for this scenario... Am I missing >something? > > >It sure would be nice to be able to do queries to an sql database to check >customer usage and such. > >I realize I could make an SQL database out of the unix password file, but I >would prefer to not >have to do this to achieve this functionality... > > > > > >=== >To unsubscribe, email '[EMAIL PROTECTED]' with >'unsubscribe radiator' in the body of the message. === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
