Forgive me if this has been asked before, but shouldn't the sql_log module use the same SQL queries from as the normal sql module? Why does it have it's own set of queries in radiusd.conf? As far as I can tell it should simply ignore connection info and non accounting queries otherwise do exactly the same thing! -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon <listuser@peternixon.net> wrote:
Forgive me if this has been asked before, but shouldn't the sql_log module use the same SQL queries from as the normal sql module? Why does it have it's own set of queries in radiusd.conf?
Probably, and it was easier that way...
As far as I can tell it should simply ignore connection info and non accounting queries otherwise do exactly the same thing!
Yes. The other thing is that the SQL module should be updated to auto-discover more queries like rlm_sql_log, rather than having them hard-coded. This means that any new accounting status type can be supported by simply adding the queries. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Peter Nixon wrote:
Forgive me if this has been asked before, but shouldn't the sql_log module use the same SQL queries from as the normal sql module? Why does it have it's own set of queries in radiusd.conf?
rlm_sql_log isn't really a SQL module, as it doesn't talk to a SQL server. In fact, the module just feeds the radsqlrelay script and it doesn't share any code with rlm_sql. The module has it's own section because you're not supposed to configure both rlm_sql and rlm_sql_log at the same time. However, according to your SQL clean up idea, this section could be in a separate file etc/raddb/sql/sql_log.conf instead of radiusd.conf. Alan DeKok wrote:
The other thing is that the SQL module should be updated to auto-discover more queries like rlm_sql_log, rather than having them hard-coded. This means that any new accounting status type can be supported by simply adding the queries.
The only problem with the rlm_sql_log method is that it doesn't support the accounting_???_query_alt yet. I'm unsure if we still need the "alt" queries: since MySQL 4.1 the new syntax "INSERT ... ON DUPLICATE KEY UPDATE" allows to do something similar with a single statement. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
The module has it's own section because you're not supposed to configure both rlm_sql and rlm_sql_log at the same time. However, according to your SQL clean up idea, this section could be in a separate file etc/raddb/sql/sql_log.conf instead of radiusd.conf.
Sounds good to me. If we can have sql_log re-use the queries from the sql config, that would be great! Maybe have sql_log as a sub-type of SQL, rather than a separate module? Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Sat 02 Sep 2006 00:14, Alan DeKok wrote:
Nicolas Baradakis <nbk@sitadelle.com> wrote:
The module has it's own section because you're not supposed to configure both rlm_sql and rlm_sql_log at the same time. However, according to your SQL clean up idea, this section could be in a separate file etc/raddb/sql/sql_log.conf instead of radiusd.conf.
Sounds good to me.
If we can have sql_log re-use the queries from the sql config, that would be great! Maybe have sql_log as a sub-type of SQL, rather than a separate module?
The simplest way to clean this up immediately is to replace: # sql_log { # path = ${radacctdir}/sql-relay # acct_table = "radacct" # postauth_table = "radpostauth" # # Start = "INSERT INTO ${acct_table} (AcctSessionId, UserName, \ # NASIPAddress, FramedIPAddress, AcctStartTime, AcctStopTime, \ # AcctSessionTime, AcctTerminateCause) VALUES \ # ('%{Acct-Session-Id}', '%{User-Name}', '%{NAS-IP-Address}', \ # '%{Framed-IP-Address}', '%S', '0', '0', '');" # Stop = "INSERT INTO ${acct_table} (AcctSessionId, UserName, \ # NASIPAddress, FramedIPAddress, AcctStartTime, AcctStopTime, \ # AcctSessionTime, AcctTerminateCause) VALUES \ # ('%{Acct-Session-Id}', '%{User-Name}', '%{NAS-IP-Address}', \ # '%{Framed-IP-Address}', '0', '%S', '%{Acct-Session-Time}', \ # '%{Acct-Terminate-Cause}');" # Alive = "INSERT INTO ${acct_table} (AcctSessionId, UserName, \ # NASIPAddress, FramedIPAddress, AcctStartTime, AcctStopTime, \ # AcctSessionTime, AcctTerminateCause) VALUES \ # ('%{Acct-Session-Id}', '%{User-Name}', '%{NAS-IP-Address}', \ # '%{Framed-IP-Address}', '0', '0', '%{Acct-Session-Time}','');" # # Post-Auth = "INSERT INTO ${postauth_table} \ # (user, pass, reply, date) VALUES \ # ('%{User-Name}', '%{User-Password:-Chap-Password}', \ # '%{reply:Packet-Type}', '%S');" # } with: # sql_log { # path = ${radacctdir}/sql-relay # acct_table = "radacct" # postauth_table = "radpostauth" # $INCLUDE ${confdir}/sql/mysql-dialup.conf # } This should require about 4 lines of changes the sql_log to recognise "accounting_start_query " instead of "Start" etc and immediately gives a simple way to handle different SQL variants. On the other hand, I think the cleaner way would be to make sql_log a driver for rlm_sql. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Fri 01 Sep 2006 23:53, Nicolas Baradakis wrote:
Peter Nixon wrote:
Forgive me if this has been asked before, but shouldn't the sql_log module use the same SQL queries from as the normal sql module? Why does it have it's own set of queries in radiusd.conf?
rlm_sql_log isn't really a SQL module, as it doesn't talk to a SQL server. In fact, the module just feeds the radsqlrelay script and it doesn't share any code with rlm_sql.
The module has it's own section because you're not supposed to configure both rlm_sql and rlm_sql_log at the same time. However, according to your SQL clean up idea, this section could be in a separate file etc/raddb/sql/sql_log.conf instead of radiusd.conf.
Alan DeKok wrote:
The other thing is that the SQL module should be updated to auto-discover more queries like rlm_sql_log, rather than having them hard-coded. This means that any new accounting status type can be supported by simply adding the queries.
The only problem with the rlm_sql_log method is that it doesn't support the accounting_???_query_alt yet.
I'm unsure if we still need the "alt" queries: since MySQL 4.1 the new syntax "INSERT ... ON DUPLICATE KEY UPDATE" allows to do something similar with a single statement.
And one the other 7 or 8 SQL variants that we support? -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Sat 02 Sep 2006 01:04, Peter Nixon wrote:
On Fri 01 Sep 2006 23:53, Nicolas Baradakis wrote:
Peter Nixon wrote:
Forgive me if this has been asked before, but shouldn't the sql_log module use the same SQL queries from as the normal sql module? Why does it have it's own set of queries in radiusd.conf?
rlm_sql_log isn't really a SQL module, as it doesn't talk to a SQL server. In fact, the module just feeds the radsqlrelay script and it doesn't share any code with rlm_sql.
The module has it's own section because you're not supposed to configure both rlm_sql and rlm_sql_log at the same time. However, according to your SQL clean up idea, this section could be in a separate file etc/raddb/sql/sql_log.conf instead of radiusd.conf.
Alan DeKok wrote:
The other thing is that the SQL module should be updated to auto-discover more queries like rlm_sql_log, rather than having them hard-coded. This means that any new accounting status type can be supported by simply adding the queries.
The only problem with the rlm_sql_log method is that it doesn't support the accounting_???_query_alt yet.
I'm unsure if we still need the "alt" queries: since MySQL 4.1 the new syntax "INSERT ... ON DUPLICATE KEY UPDATE" allows to do something similar with a single statement.
And one the other 7 or 8 SQL variants that we support?
After reading the last 3 email I wrote to the list I figure it must be time to get some sleep as I don't appear to be making sense. This was supposed to be: "And what about the other 7 or 8 SQL variants that we support?" -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Fri 01 Sep 2006 01:51, Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
Forgive me if this has been asked before, but shouldn't the sql_log module use the same SQL queries from as the normal sql module? Why does it have it's own set of queries in radiusd.conf?
Probably, and it was easier that way...
As far as I can tell it should simply ignore connection info and non accounting queries otherwise do exactly the same thing!
Yes.
The other thing is that the SQL module should be updated to auto-discover more queries like rlm_sql_log, rather than having them hard-coded. This means that any new accounting status type can be supported by simply adding the queries.
Can't we just make it a driver for rlm_sql? -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon <listuser@peternixon.net> wrote:
The other thing is that the SQL module should be updated to auto-discover more queries like rlm_sql_log, rather than having them hard-coded. This means that any new accounting status type can be supported by simply adding the queries.
Can't we just make it a driver for rlm_sql?
Yes, sql_log can just be a driver for rlm_sql. But the queries in rlm_sql are hard-coded, and that's annoying. That should be fixed. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Fri 01 Sep 2006 22:49, Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
The other thing is that the SQL module should be updated to auto-discover more queries like rlm_sql_log, rather than having them hard-coded. This means that any new accounting status type can be supported by simply adding the queries.
Can't we just make it a driver for rlm_sql?
Yes, sql_log can just be a driver for rlm_sql.
But the queries in rlm_sql are hard-coded, and that's annoying. That should be fixed.
It also just occured to me that making sql_log a driver of rlm_sql would allow plm_sqlippool to use it also which would be usefull. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon <listuser@peternixon.net> wrote:
It also just occured to me that making sql_log a driver of rlm_sql would allow plm_sqlippool to use it also which would be usefull.
OK. I'm not sure how it would be useful, but OK. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Mon 04 Sep 2006 15:30, Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
It also just occured to me that making sql_log a driver of rlm_sql would allow plm_sqlippool to use it also which would be usefull.
OK. I'm not sure how it would be useful, but OK.
Its not usefull for selects (IP Assignment), but is usefull to keep the IP Allocation expiry updated (Alive Packets) and specifically to deallocate IP addresses on Stop records. (Consider that you have a single DB server which goes down, but have radiusd configured with "sql" and "sql_log" in a redundant config) Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon <listuser@peternixon.net> wrote:
Its not usefull for selects (IP Assignment), but is usefull to keep the IP Allocation expiry updated (Alive Packets) and specifically to deallocate IP addresses on Stop records. (Consider that you have a single DB server which goes down, but have radiusd configured with "sql" and "sql_log" in a redundant config)
Ah, OK. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (3)
-
Alan DeKok -
Nicolas Baradakis -
Peter Nixon