Cannot control attribute ordering via "rlm_perl"

claude.brown Claude.Brown at
Mon Jan 16 00:35:49 CET 2012

In the end we implemented our solution as a new C module rather than perl
called by "rlm_perl".  Thanks.

Our new module was designed to replace "rlm_sql" and meet these goals:
- Be roughly equivalent to "rlm_files" in terms of speed
- Utilise all the features of "rlm_files" - avoid re-inventing that wheel
- Allow high rate of user-by-user updates; i.e. avoid config re-write as per
- Simple for stability: no shared in-memory state (avoid locking and races)
- Simple for stability: avoid complex on-disk structures like databases with
dubious libraries
- Simple for stability: easy mechanism to re-write entire config (say daily)
to iron our errors
- Simple for stability: re-use as much of freeRADIUS as possible; avoid
writing lots of new code

We acheived all these goals and can now process bring all our customers back
onto our service in about
five minutes. The price is a lot of i-nodes - we end up with one file per
user in a dir tree.

With "rlm_sql" it would take an hour or two only then with careful (and
human driven) rate management.
The main issues driving this delay were:
- "rlm_sql" calls during EAP negotation instead of just at the end of EAP
- Performance issues on our MySQL backend that we didn't have budget to
- Thread lock-up's inside MySQL library yet no MySQL server queries were

If this module is of interest to the community we are happy to contribute



View this message in context:
Sent from the FreeRadius - User mailing list archive at

More information about the Freeradius-Users mailing list