[OpenSIPS-Users] CDRTool - opensips.radacct201211 doesn't exist

Duane Larson duane.larson at gmail.com
Thu Nov 8 18:08:39 CET 2012


Tijmen,

For the new MySQL server I am not able to log into it and do any iptables
redirects since it is a "managed" mysql solution.  But with my old server I
configured mysql to work off of port 19994 and pointed CDRTools global.inc
to port 19994 on the old server and everything works fine.  So something is
up with the new mysql servers database.  I did a backup of the old database
and moved it over to the new database and I also added
the radius_accounting.proc to the radius database.  If you can think of why
CDRTool would want to look in the opensips database let me know.

The only thing I can think to do is to blow away the database that I
restored on the new mysql server and start from scratch to see if anything
is missing.



On Thu, Nov 8, 2012 at 6:18 AM, Tijmen de Mes <tijmen at ag-projects.com>wrote:

>  Hi,
>
> I am unable to reproduce it. Just as a quick test can you insert an
> iptables rule on the mysql server to divert requests on port 3306 from the
> cdr machine to 19994? That way we can check if CDRTool tries to use that
> port even though you specified an other and rule. You can even put the
> config back then and see if it works then.
>
> In my testing I changed the config to use 19994 and redirected the port
> 19994 to 3306 on the mysql server. I got no errors an all was working.
>
>
> Best regards,
>
> --
> Tijmen de Mes
> AG Projects
>
>
> On 11/07/2012 05:27 PM, Duane Larson wrote:
>
> Ok.  Just to test I swung back over to the old CDRTool mysql database and
> everything works like normal (plus CDRTool is now version 9 instead of the
> older version I was running).  Here is the global.inc config for database
> connectivity.
>
>  class DB_CDRTool extends DB_Sql {
>   var $Host     = "10.178.225.*";
>   var $Database = "cdrtool";
>   var $User     = "user";
>   var $Password = "pass";
>   var $Halt_On_Error ="yes";
> }
>
>  class DB_Locker extends DB_Sql {
>   var $Host     = "10.178.225.*";
>   var $Database = "cdrtool";
>   var $User     = "locker";
>   var $Password = "pass";
>   var $Halt_On_Error ="yes";
> }
>
>  class DB_radius extends DB_Sql {
>   var $Host     = "10.178.225.*";
>   var $Database = "radius";
>   var $User     = "radadmin";
>   var $Password = "pass";
>   var $Halt_On_Error ="yes";
> }
>
>  class DB_opensips extends DB_Sql {
>   var $Host     = "10.178.225.*";
>   var $Database = "opensips";
>   var $User     = "opensips";
>   var $Password = "aether1234";
>   var $Halt_On_Error ="yes";
> }
>
>  class DB_mediaproxy extends DB_Sql {
>   var $Host     = "10.178.225.*";
>   var $Database = "mediaproxy";
>   var $User     = "mediaadmin";
>   var $Password = "pass";
>   var $Halt_On_Error ="yes";
> }
>
>
>  So it works with the old mysql server but not with the new server.
>
>
>
> On Wed, Nov 7, 2012 at 9:18 AM, Tijmen de Mes <tijmen at ag-projects.com>wrote:
>
>>  Hi,
>>
>> Ok, I can't see quickly where it goes wrong, in my opinion it should just
>> work.
>>
>> Tomorrow I can do some tests to see if I can track where it goes wrong.
>>
>>
>> Best regards,
>>
>> --
>> Tijmen de Mes
>> AG Projects
>>
>>
>>   On 11/07/2012 04:02 PM, Duane Larson wrote:
>>
>> Hey Tijmen,
>>
>>  Yes
>> show processlist
>> | 386 | aethercom | 10.179.74.213:57335 | cdrtool  | Sleep   |    6 |
>>     | NULL
>>
>>  I even changed the the mysql server name on my global.inc to be
>> something wrong to see if restarting cdrtool would fail and it did fail.
>>  So its not failing when the info is correct.  This is what I have.
>>
>>  class DB_CDRTool extends DB_Sql {
>>   var $Host     = "int.serverdnsname:19994";
>>   var $Database = "cdrtool";
>>   var $User     = "user";
>>   var $Password = "password";
>>   var $Halt_On_Error ="yes";
>> }
>>
>>  class DB_Locker extends DB_Sql {
>>   var $Host     = "int.serverdnsname:19994";
>>   var $Database = "cdrtool";
>>   var $User     = "user";
>>   var $Password = "password";
>>   var $Halt_On_Error ="yes";
>> }
>>
>>  class DB_radius extends DB_Sql {
>>   var $Host     = "int.serverdnsname:19994";
>>   var $Database = "radius";
>>   var $User     = "user";
>>   var $Password = "password";
>>   var $Halt_On_Error ="yes";
>> }
>>
>>  class DB_opensips extends DB_Sql {
>>   var $Host     = "int.serverdnsname:19994";
>>   var $Database = "opensips";
>>   var $User     = "user";
>>   var $Password = "password";
>>   var $Halt_On_Error ="yes";
>> }
>>
>>  class DB_mediaproxy extends DB_Sql {
>>   var $Host     = "int.serverdnsname:19994";
>>   var $Database = "mediaproxy";
>>   var $User     = "user";
>>   var $Password = "password";
>>   var $Halt_On_Error ="yes";
>> }
>>
>>
>>  On Wed, Nov 7, 2012 at 8:33 AM, Tijmen de Mes <tijmen at ag-projects.com>wrote:
>>
>>>  Hi Duane,
>>>
>>> So to narrow it down, CDRTool is able to connect to the db ( you see
>>> them in the processlist?), but then it looks in the wrong databases?
>>>
>>> Best regards,
>>>
>>> --
>>> Tijmen de Mes
>>> AG Projects
>>>
>>>
>>> On 11/07/2012 05:27 AM, Duane Larson wrote:
>>>
>>>  I have been running CDRTool for a long time (about 2 or 3 years) and
>>> today I moved the mysql database over to a new server.  For some reason
>>> when I log into CDRTool I see the following at the bottom of the screen
>>>
>>>  MySQL error: 1146 (Table 'opensips.active_sessions' doesn't exist)
>>> Session halted.
>>>
>>>  then if I click the "search" button it says
>>>
>>>  MySQL error: 1146 (Table 'opensips.radacct201211' doesn't exist)
>>> Session halted.
>>>
>>>  The only big change that I made was in the global.inc for CDRTool I
>>> set the $Host variables to point to "server.dns.name:19994".  So the
>>> only real difference is that I have added a port that isn't 3306.
>>>
>>>  I don't see any issues with CDRTool connecting to the database but I
>>> have no clue why it now wants to try and look in the opensips database for
>>> the active_sessions and radacct201211 table.
>>>
>>>  Like I say all I did was move over to a new mysql server so the
>>> configs for freeradius and cdrtool didn't change except for pointing to the
>>> new server.
>>>
>>>  I went ahead and upgraded to the latest version of CDRTool and I still
>>> see the issue.  So the upgrade didn't help any.
>>>
>>>
>>>
>>>
>>>  _______________________________________________
>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>>
>>  --
>> --
>> *--*--*--*--*--*
>> Duane
>> *--*--*--*--*--*
>> --
>>
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
>  --
> --
> *--*--*--*--*--*
> Duane
> *--*--*--*--*--*
> --
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>


-- 
--
*--*--*--*--*--*
Duane
*--*--*--*--*--*
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20121108/160c19e2/attachment-0001.htm>


More information about the Users mailing list