For reference, we use that everywhere, because it can handle post-auth logging, which the detail file reader can't. linelog also doesn't do the same job because it doesn't have the locking. So I guess I'll have to maintain it out-of-tree? Any other modules scheduled for deletion?
On 2 Dec 2012, at 10:19, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
For reference, we use that everywhere, because it can handle post-auth logging, which the detail file reader can't.
rlm_sql_log was deprecated and subsequently removed in favour of the rlm_sql_null, which just runs the logging code in the rlm_sql module. If you find functionality missing from rlm_sql, send a patch, or let me know and i'll add it. It makes a lot more sense to have one well maintained set of queries and configs for each SQL flavour.
Any other modules scheduled for deletion?
hmm, been eyeing rlm_perl for a while now :p rlm_realm, because it's functionality is completely duplicated by unlang, but Alan won't let me delete it. rlm_policy should go but apparently there are still a few operations we don't support in unlang, that it does. We've discussed rlm_eap2 and didn't come to any real conclusion. -Arran
On 2 Dec 2012, at 11:28, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 2 Dec 2012, at 10:19, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
For reference, we use that everywhere, because it can handle post-auth logging, which the detail file reader can't.
rlm_sql_log was deprecated and subsequently removed in favour of the rlm_sql_null,
*driver
On 2 Dec 2012, at 11:28, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 2 Dec 2012, at 11:28, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 2 Dec 2012, at 10:19, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
For reference, we use that everywhere, because it can handle post-auth logging, which the detail file reader can't.
rlm_sql_log was deprecated and subsequently removed in favour of the rlm_sql_null,
*driver - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
This was actually discussed on the users list a while back (11/08/2012): Arran Cudbard-Bell wrote:
Crazy idea, but could we just junk the sql_log module, and add a null driver to rlm_sql?
Geez, get with the program already: https://github.com/alandekok/freeradius-server/tree/master/src/modules/rlm_s... :) It's had minimal testing, of course. I also fixed a few issues with the SQL module. It should no longer reference uninitialized variables. Alan DeKok. -Arran
On 12/02/2012 11:28 AM, Arran Cudbard-Bell wrote:
On 2 Dec 2012, at 10:19, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
For reference, we use that everywhere, because it can handle post-auth logging, which the detail file reader can't.
rlm_sql_log was deprecated and subsequently removed in favour of the rlm_sql_null, which just runs the logging code in the rlm_sql module. If you find functionality missing from rlm_sql, send a patch, or let me know and i'll add it.
Hmm. Are you sure the "rad_lockfd" locking scheme is compatible with the one rlm_sql_log / radsqlrelay use(d)? Bear in mind that lockf is not guaranteed to be a mapping to fcntl (it is on Linux currently, IIRC). flock() is completely unrelated (and also doesn't work across NFS, in case this matters). I know the Unix file locking APIs are vile, but having the locking method the server uses on files which external processes might access be a compile-time variable might make things difficult for people who have to read those files in external processes. They have to implement all three, and know which one the server binary is using right now...
Phil Mayers wrote:
Hmm. Are you sure the "rad_lockfd" locking scheme is compatible with the one rlm_sql_log / radsqlrelay use(d)?
It can be. :)
Bear in mind that lockf is not guaranteed to be a mapping to fcntl (it is on Linux currently, IIRC). flock() is completely unrelated (and also doesn't work across NFS, in case this matters).
OK.
I know the Unix file locking APIs are vile, but having the locking method the server uses on files which external processes might access be a compile-time variable might make things difficult for people who have to read those files in external processes. They have to implement all three, and know which one the server binary is using right now...
It might be simpler to just make everything use fcntl locks. The rad_lockfd() code is a decade old. Many of the assumptions behind it may be no longer true. I'm OK with changing it to use fcntl locks. I'm OK with adding locking to rlm_sql_null. I'm OK with making rlm_sql_null do locking *all* the time, even when there's no sqlrelay program reading it. The extra locking costs very little. Alan DeKok.
On 2 Dec 2012, at 15:04, Alan DeKok <aland@DEPLOYINGRADIUS.COM> wrote:
Phil Mayers wrote:
Hmm. Are you sure the "rad_lockfd" locking scheme is compatible with the one rlm_sql_log / radsqlrelay use(d)?
It can be. :)
Yeah....
It might be simpler to just make everything use fcntl locks. The rad_lockfd() code is a decade old. Many of the assumptions behind it may be no longer true.
I'm OK with changing it to use fcntl locks.
Done, and rlm_sql always acquires a lock when writing to the log file. -Arran
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
Brian Candler -
Phil Mayers