[freeside-devel] OpenRADIUS support

[Emile van Bergen]

Hi,

On Tue, Dec 14, 2004 at 02:22:50PM -0800, ivan wrote:

> Configuring OpenRADIUS to use the same sort of database schema as
> FreeRADIUS and ICRADIUS certainly isn't all that unreasonable an idea,
> especially since that schema is becoming a de-facto standard (RADIATOR
> can also be configured to use a schema like this too).  Personally I
> don't see anything particularly inelegant about going this route for new
> installations.

Well, although OpenRADIUS can support check items (operation specified
in DB table) and reply items from a different table, its model is really
different. 

What you do with OpenRADIUS is that you script the authentication flow
inside the server: you receive a request, pull in your data from
databases, whatever they are, and then make your decisions wrt. what
response to send.

Considering the wild things people do with RADIUS, this model seemed to
me much better than a semi-fixed function server with all kinds of hooks
to escape the model, and requiring a complete C module simply for
mangling A/V pairs.

And for accounting I don't really like that table format either: it's a
layering violation and tries to be a sessions table and accounting log
in one.

At one side it performs a half-hearted attempt to match Stop records to
Start records, but it doesn't do duplicate stripping.

I think that a log should be cleanly separated from a sessions table,
should be time ordered (ie. no folding start and stop together) and
should be stripped from duplicates.

That's what I do with OpenRADIUS, and I would hate to throw that all out
of the window if I don't need to.

> It doesn't do anything for users with existing OpenRADIUS databases, of 
> course, so if you wanted to work on an OpenRADIUS-specific export I'd be 
> happy to include it.
> 
> > At one extreme, I could write an OpenRADIUS behaviour file that uses
> > Freesides own database schema directly, in real time.
> 
> Not that it matters, but I'm not personally too keen on this sort of
> architecture.  I think of Freeside as a central, private database that
> pushes information to (and pulls information from) external, public
> databases and servers.

The problem is that OpenRADIUS isn't specific. Think of it as a simpler
RADIUS equivalent of Apache + PHP: a server plus a single purpose
(sorry, PHP fans) scripting language that can access databases.

So if neither Freeside nor OpenRADIUS dictates anything, then we may as
well create the best solution we can think of.

> > At the other extreme, Freeside could get an export to tie in to one of
> > the current example database setups that come with OpenRADIUS.
> 
> This would be my preference if you'd like to work on an
> OpenRADIUS-specific export.  I'd suggest creating
> FS::part_export::openradius by starting with FS::part_export::sqlradius
> and modifying it to suit your needs.
> 
> If there's any sort of standard / most-popular / best-practice schema
> that is distributed with OpenRADIUS that's probably what the export 
> should work against.

Well, there are two: a basic one and one that does pre-paid accounts
tracking and balancing, with possibility to lock an account to the first 
CLI to use it, and to set an expiry time based on the first login
(timeslot accounts).

The second one uses an extra table and a different behaviour file, but
the same server.

> > Another question is for a pointer to a reference what Freeside needs at
> > the minimum from a RADIUS server in order to offer its full
> > functionality. Eg. other than the flexible exports mechanism to push
> > accounts to the RADIUS server, what type of mechanisms exist to get
> > accounting data?
> 
> If your export offers a "usage_sessions" method like
> FS::part_export::sqlradius, it should be trivial to get all the
> usage-based functionality working (looking at sessions, billing on 
> time/data, the new RADIUS VoIP billing, and so on).

I'll have a look at what sqlradius does currently. You're sure it
doesn't jump through hoops to match the accounting table to Freeside's
own model? Or can I create something that makes life easier for both of
us?

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile at e-advies.nl      
tel. +31 (0)70 3906153           http://www.e-advies.nl