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.
