Looks a little like my question a couple of weeks back - 26/02/99
>Do something like this:
>
><Realm xxxx>
> AuthByPolicy ContinueWhileIgnore
> <AuthBy SQL>
> DBSource zzzz
> .....
>
> # This disables SQL auth
> AuthSelect
> # This enables SQL accounting
> AccountingTable yyy
> ActColumnDef ....
> ....
> </AuthBy>
> <AuthBy FILE>
> Filename whatever
> </AuthBy>
> AcctLogFileName youracctdetailflatfilename
></Realm>
--
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
> machine....Radiator 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.
>
===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
