In 2.0.0 we had two sql drivers rlm_sql_freetds (db), and rlm_sql_sybase (ct-lib). They used two different APIs but the same protocol, TDS. The reason why they were bundled with the server was to support Sybase and MSSQL servers natively, without an ODBC connector. In 3.0.0 rlm_sql_sybase has been renamed to rlm_sql_freetds as it was more complete and used a newer API, and the old rlm_sql_freetds module has been removed. The following changes were made: * Integrate it into the build system (add configure.in and all.mk.in) * Code cleanup. * Don't leak connection handles or contexts or statements - the old code made no attempt to close connections, or free resources - it had the closure code copy/pasted from rlm_sql_oracle and then commented out. Um... * Pass userdata to message callbacks so they can write potential errors to the connection handle (which are later retrieved via sql_error(), if an actual error occurred). * Log informational messages from the client library and the client (I have no idea why there's this distinction) using INFO() in real time. * Select database on connection spawn. The API had no support for this, so we just issue a 'USE <db_name>;' statement every time a connection is created. The db context change seems to persist across multiple queries, at least with MSSQL. * Switch severity of server messages. During connection establishment they're INFO(), then, if they occur during a query, they're treated as ERROR()s (accessible from sql_error()). The reason for this is that there are no standard severity levels between TDS SQL servers, and so you have absolutely no idea whether the messages returned by the server are errors or not. The nice thing about sql_error() is it's only called when one of the API functions has returned an error code, so hopefully you won't get informational messages showing up as errors. It's the best hack I could think of. Blame Sybase (or whoever they bought the IP off) for coming up with such a shitty protocol. * Better and more consistent logging. To get rlm_sql_freetds you need to have the freetds libraries available (apt-get install freetds-dev), or something else which provides a ct-lib API. The configure script isn't picky so long as it can find ctpublic.h and ct_command in libct it'll build the module. The driver isn't marked as stable (once people test it and provide positive feedback it may be), but will build if you pass --with-experimental-modules or --enable-developer to configure, or build from .git (which automatically enables developer). There's no additional driver options, though there may be some advantage to setting client version dynamically (let me know if you want/need this). -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team