[SR-Users] permissions module address_reload not working

[Daniel-Constantin Mierla]

On 7/1/10 1:18 PM, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>    
>> Juha, I just committed on master and tested over MI where works fine.
>> Can you do some tests over rpc? If all ok then can be backported.
>>      
> daniel,
>
> i deleted whole sr git repo and downloaded a new one.  after that i did
> address_reload tests.  it works from command line:
>
> # sip-proxy_ctl mi address_reload
> #
>
> but not via xmlrpc:
>
> Jul  1 14:12:29 localhost /usr/sbin/sip-proxy[11821]: INFO: Handling XMLRPC POST from<127.0.0.1>  with body<<?xml version="1.0" ?><methodCall><methodName>mi</methodName><params><param><value><string>address_reload</string></value></param></params></methodCall>>
> Jul  1 14:12:29 localhost /usr/sbin/sip-proxy[11821]: ERROR:<core>  [db.c:421]: invalid parameter value
> Jul  1 14:12:29 localhost /usr/sbin/sip-proxy[11821]: ERROR: permissions [address.c:84]: failed to use table
>
>    
this is another issue ... the mi commands were designed to be run from 
special processes, created by mi transport modules (mi_fifo, 
mi_datagram, etc). There are special init functions called for these 
processes. However, with 3.0 xmlrpc module can call these functions but 
the module re-uses SIP tcp processes, meaning that what is called in mi 
init child function should be called in child init functions.

There are two options:
- call all mi child init functions in mi_rpc child_init even for SIP 
worker process - in the previous commit I added execution only for 
PROC_RPC. But then each module exporting mi commands has to be reviewed 
to see if there is no overlapping (usually is about opening db 
connection, thus make sure it is not opened twice in same process)
- execute per module mi init fuction specific for that module. This will 
ensure that mi command become available to xmlrpc module gradually but 
safe. It has a drawback of initializing MI specific stuff for each 
process even when mi_rpc is not loaded, thus such things are not needed 
at runtime

Both options requires check over the mi cmd modules. Right now I think 
option 1 is better, because it does not initialize db connections when 
not needed, other opinions?

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://www.asipto.com/