rlm_redis module "patch"
Attached is two new modules. Apologies ahead of time for submitting this as a tgz. rlm_redis allows you to connect and query a redis key-store database. Basically same idea as memcached except the keys don't expire if you allow them to. http://redis.io/ rlm_redis requires a redis server instance and the hiredis libraries to be installed https://github.com/antirez/hiredis Preferably redis should be running version 2.2 as it allows you to expire keys. rlm_rediswho is a module that is similar to rlm_radwho, it obviously uses the rlm_redis module. What it does is that it basically "dumps" all the accounting data/sessions into this key store database. Once a user has so many sessions (defined by trim-count) rlm_radwho will start trimming out old data. If there is no update for said user for expiry-time, the redis server itself will expire the key. I anticipate the rlm_redis module could be used for something else, since it is _considerably_ faster than any sql module (about 100,000 queries per second) . But I thought that this was perfect for a radwho module as it allows you to expire stale sessions automatically, therefore the db won't grow an insane amount. Obviously this is all work in progress, but it appears to run stable. It compiles clean on my Mac but may need some configure script magic to make it a little more portable.
Gabriel Blanchard wrote:
Attached is two new modules. Apologies ahead of time for submitting this as a tgz.
rlm_redis allows you to connect and query a redis key-store database. Basically same idea as memcached except the keys don't expire if you allow them to.
I like redis, but haven't had much time to play with it. It looks interested.
rlm_redis requires a redis server instance and the hiredis libraries to be installed https://github.com/antirez/hiredis
Preferably redis should be running version 2.2 as it allows you to expire keys.
rlm_rediswho is a module that is similar to rlm_radwho, it obviously uses the rlm_redis module. What it does is that it basically "dumps" all the accounting data/sessions into this key store database. Once a user has so many sessions (defined by trim-count) rlm_radwho will start trimming out old data. If there is no update for said user for expiry-time, the redis server itself will expire the key.
That looks very useful.
I anticipate the rlm_redis module could be used for something else, since it is _considerably_ faster than any sql module (about 100,000 queries per second) . But I thought that this was perfect for a radwho module as it allows you to expire stale sessions automatically, therefore the db won't grow an insane amount.
Exactly. It will use a lot of memory, but for ~100K users, it shouldn't use more than a 1G. And memory is cheap these days.
Obviously this is all work in progress, but it appears to run stable. It compiles clean on my Mac but may need some configure script magic to make it a little more portable.
It looks good. Some comments: - please use "github" to fork the freeradius repository - add the files to the v2.1.x branch: rlm_redis/Makefile.in, configure.in, rlm_redis.[ch] rlm_rediswho/Makefile.in, configure.in, rlm_rediswho.c - send me a "pull" request, or just email me, and I can pull the changes over. - re-creating the "configure" script will be done for the next release - I suggest reformatting the code to follow the rest of the FreeRADIUS programming conventions - the rediswho_expand() function is horrible. Instead, see the function xlat_client() in src/main/mainconfig.c. It's smaller, simpler, and more capable. - some sample configuration / documentation would be good, but not required. :) - a Perl script to replace "radwho" would be spectacular. The redis DB looks to be very interesting. A fast key-value store has a lot of usefulness. Alan DeKok.
On 2011-01-13, at 4:30 AM, Alan DeKok wrote:
- please use "github" to fork the freeradius repository
- add the files to the v2.1.x branch: rlm_redis/Makefile.in, configure.in, rlm_redis.[ch]
rlm_rediswho/Makefile.in, configure.in, rlm_rediswho.c
- send me a "pull" request, or just email me, and I can pull the changes over.
k, will do when I get a chance.
- I suggest reformatting the code to follow the rest of the FreeRADIUS programming conventions
What is the convention?
- the rediswho_expand() function is horrible. Instead, see the function xlat_client() in src/main/mainconfig.c. It's smaller, simpler, and more capable.
I agree, ok. To be honest and I'm sure it's quite obvious, I reused a lot of existing code in Freeradius.
- some sample configuration / documentation would be good, but not required. :)
mmmm....sure..maybe ;-)
- a Perl script to replace "radwho" would be spectacular.
I'm plaining on coding something like that, but it will likely be in php (I know, I know...) -Gabe
Gabriel Blanchard wrote:
- I suggest reformatting the code to follow the rest of the FreeRADIUS programming conventions
What is the convention?
To look like the existing code. Braces go in consistent place, extraneous blank lines don't belong, etc.
- a Perl script to replace "radwho" would be spectacular.
I'm plaining on coding something like that, but it will likely be in php (I know, I know...)
A Perl script shouldn't be hard to do... Alan DeKok.
On 2011-01-13, at 4:30 AM, Alan DeKok wrote:
- the rediswho_expand() function is horrible. Instead, see the function xlat_client() in src/main/mainconfig.c. It's smaller, simpler, and more capable.
There's something I don't understand though, once you've registered your xlat function using xlat_register(inst->xlat_name, <function name here>, inst); Where/how do you call it?
Gabriel Blanchard wrote:
There's something I don't understand though, once you've registered your xlat function using
xlat_register(inst->xlat_name, <function name here>, inst);
Where/how do you call it?
Instead of a configuration like: foo_query = "hello %T" you use: foo_query = "hello %{rediswho:trim_count}" The first is specific to the rediswho module, and can't be used *anywhere* else. The second is a little more awkward to read, but more generic. Or, you could do what the SQL module does: foo_query = "hello ${trim_count}" in which case "trim_count" is taken from the configuration when the module loads. The server core parses the string, and when the module "init" routine is called, it sees: foo_query = "hello 5" Much better... Alan DeKok.
participants (2)
-
Alan DeKok -
Gabriel Blanchard