rlm_sql_ocioracle driver v. 0.1
Hi, in attachment patch to add rlm_sql_ocioracle driver to freeradius 2.1.x tree (it seems work yet on 3.x tree). This drivers permit to use function/procedure with CURSOR (through :Ret_Cursor string) like for example: group_membership_query = "begin :Ret_Cursor := \ pkRadius.group_membership_query('%{SQL-User-Name}'); end;" TODO for next release: - add support to oracle connection pool instead of open a new connection for every socket on startup; - enhancement on handle error (through error callback) on do query; - add documentation. Module need oracle instantclient library and ocilib library (http://orclib.sourceforge.net/). Good luck to rlm_sql_ocioracle driver!! Geaaru
Ge@@ru wrote:
in attachment patch to add rlm_sql_ocioracle driver to freeradius 2.1.x tree (it seems work yet on 3.x tree). .. Module need oracle instantclient library and ocilib library (http://orclib.sourceforge.net/).
OK... the module is rather large. i.e. it implements all kind of generic functions (field.c, list.c). The other SQL modules don't need those functions, so why does this one need them? As a comparison, the code here is ~2500 lines. The other SQL modules are ~1000 lines. Alan DeKok.
Hi, module is create to permit different solutions. Have a structure that permit to receive only string it's very poor. Probably, these generic functions can be insert to radius common library so it can be used by other SQL module. Are there functions like these on radius that permit to remove files inserted on driver? TODO for next release: - recover error message from thread instead of use OCI_LastError(); - use oracle connection pool. On Mon, 2011-03-07 at 07:39 +0100, Alan DeKok wrote:
Ge@@ru wrote:
in attachment patch to add rlm_sql_ocioracle driver to freeradius 2.1.x tree (it seems work yet on 3.x tree). .. Module need oracle instantclient library and ocilib library (http://orclib.sourceforge.net/).
OK... the module is rather large. i.e. it implements all kind of generic functions (field.c, list.c). The other SQL modules don't need those functions, so why does this one need them?
As a comparison, the code here is ~2500 lines. The other SQL modules are ~1000 lines.
Alan DeKok.
Hi, i haven't received feedback from my previous mail. Driver will be added to freeradius tree or not? Thanks On Mon, 2011-03-07 at 07:39 +0100, Alan DeKok wrote:
Ge@@ru wrote:
in attachment patch to add rlm_sql_ocioracle driver to freeradius 2.1.x tree (it seems work yet on 3.x tree). .. Module need oracle instantclient library and ocilib library (http://orclib.sourceforge.net/).
OK... the module is rather large. i.e. it implements all kind of generic functions (field.c, list.c). The other SQL modules don't need those functions, so why does this one need them?
As a comparison, the code here is ~2500 lines. The other SQL modules are ~1000 lines.
Alan DeKok.
Ge@@ru wrote:
Hi, i haven't received feedback from my previous mail.
Driver will be added to freeradius tree or not?
I need to understand why it's so much more complicated than any of the other drivers. The previous reply of "the code is useful for other drivers" isn't true. None of the other drivers have needed that code in the last 10 years. I am opposed to needless complexity. What, exactly, is the cause of the complexity? Why is it required here, and not elsewhere? We are not in the business of adding random code to the server. it requires review and audit before it goes in. Alan DeKok.
Hi guys, with some years of delay, i'm back. I rewrite rlm_sql_ocioracle module and follow yours indications: * I simplify code and remove complex structure; * I move sources to freeradius-3.x implementation. Currently sources and project is available on my githup account: https://github.com/geaaru/rlm_sql_ocioracle On tag 0.1.0, there is old implementation complaints with freeradius-2.2.x with complex structure. In the next weeks I will test new implementation for check presence of issue. I hope for integration of rlm_sql_ocioracle module to official freeradius tree. Thanks for Freeradius project. Bye Geaaru On Mon, 2011-03-14 at 15:31 +0100, Alan DeKok wrote:
Ge@@ru wrote:
Hi, i haven't received feedback from my previous mail.
Driver will be added to freeradius tree or not?
I need to understand why it's so much more complicated than any of the other drivers. The previous reply of "the code is useful for other drivers" isn't true. None of the other drivers have needed that code in the last 10 years.
I am opposed to needless complexity. What, exactly, is the cause of the complexity? Why is it required here, and not elsewhere?
We are not in the business of adding random code to the server. it requires review and audit before it goes in.
Alan DeKok.
participants (2)
-
Alan DeKok -
Ge＠＠ru