Cannot control attribute ordering via "rlm_perl"

[claude.brown]

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
"rlm_fastfile"
- 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
resolve
- Thread lock-up's inside MySQL library yet no MySQL server queries were
active

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

Cheers,

Claude.



--
View this message in context: http://freeradius.1045715.n5.nabble.com/Cannot-control-attribute-ordering-via-rlm-perl-tp4875309p5147457.html
Sent from the FreeRadius - User mailing list archive at Nabble.com.