Hi All,
A few changes to the SQL drivers.
* Biggest change is there are now no longer any socket close/free functions in
the driver API these are now all handled by talloc destructors. If you suspect
sockets aren't being closed properly, run with the extra -x and it'll print out
a message when the destructor is called.
* All the drivers now (optionally) can provide an instantiate method to do
their own config parsing. This method gets passed in the config sub section (if
it exists) matching the driver name.
So for sqlite it'd be
sql {
sqlite {
<this section>
}
}
This will let us do driver specific configuration. If there are any client side
options for MySQL / PostgreSQL that are useful for tuning/debugging feel free
to submit patches.
* Sqlite code has been pretty much rewritten so it works for everything (not
just clients), and a new set of schemas created for sqlite. Yes the S is for
simple not standardised *sigh*.
* The 'filename' config item in the main sql config (which specified where the
sqlite db was) has been moved into the sqlite {} section (where it should have
always been).
* There's a new bootstrap config item for sqlite. If bootstrap is set, and the
specified sqlite database doesn't exist, it'll be created, then the sql file
specified by bootstrap will be split on ;\n and each statement executed in turn
to create the schema for the boostrapped database.
The idea is to ship with a working configuration for sqlipool, so the DHCP just
works after you've configured the ranges.
If you're writing example configurations/modules that depend on SQL for
persistent storage, it'd probably be a good idea to use the sqlite driver and
bootstrap the database/schema that's required, then the examples work out of
the box, so long as you have sqlite available.
-Arran
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
