Ascend-Data-Filter Issues

[Hugh Messenger]

Jeff <jeffa at jahelpdesk.com> said
> 
> Actually the best answer for me if I were alittle stronger in mysql to
> create the import query would be
> a script that I could run to convert the users and import them into the
> radius database

As you noticed, users2mysql is a good place to start.  And don't be put off
by the SQL itself.  The queries and data structures in rlm_sql are very,
straight forward.  No funky "third normal forms" or complex relations.  It's
all very basic select, insert and update, on a really simple schema.

> when our billing software adds removes locks accounts, then dealing with
> the filters, etc.
> That way billing program creates file, query imports to sql, radius
> operates through the sql end and not users file
> I have seen the one in the source, users2mysql just not sure its actually
> the correct format to import usersfor what i need.  I was thinking del all
> imported items when a new users file is ready for import then repopulate
> with the import query the new.

As long as you selectively remove specific groups of users, rather than
dropping entire tables, there's nothing wrong with that approach.  Then you
can have other groups (like 'staff') that might not be featured in the
billing file, which don't get blown away when your import script runs.  And
as you grow your service, and start synchronizing SQL user data from other
sources, you just use the same approach so that nothing is stomping on
everyone elses toes by blowing the tables away.

The user2mysql script is still a good place to start looking, though.  It
wouldn't take much modification to do what you need.  Really just a 'garbage
collection' pass back the other way, iterating through the db users and
removing those that are no longer in the billing file.  If you aren't
familiar with perl, it's worth learning.  It's not that hard, plenty of
great online resources, and essential for the kind of work you need to do.

> Then auths, etc would be handled through the sql end where the control is
> alot easier and appears more effective
> And I could be running things as freeradius is designed to run.
> Thus my stuff adapts to the workiing model, instead of me trying to change
> a working model to mine.

Yes.  That's the idea.  Part of good provisioning is providing the 'shims'
between different components, such that you minimize (and hopefully
eliminate) any customization of the components themselves.  It's a common
issue when bolting together packages that deal with data that has no formal
standard (like a RADIUS users file!).  Which is why Alan's repeated advice
was 'modify the source data'.  I think he only mentioned modifying C code as
a piece of negative reinforcement!

   -- hugh