[sr-dev] rpc commands for permissions(k)
Olle E. Johansson
oej at edvina.net
Fri Dec 21 23:13:43 CET 2012
21 dec 2012 kl. 21:46 skrev Daniel-Constantin Mierla <miconda at gmail.com>:
> Hello,
>
> any developer with some spare time to add rpc commands to modules_k/permissions module? They should be the equivalent of existing mi commands. That should render modules_s/permissions obsolete.
These are the commands for modules_s/permissions
• ipmatch.reload - Reloads the cached ipmatch table. The original table remains active in case of any failure.
• ipset.clean(ipset_name) - Clear all entries in "pending" ipset.
• ipset.add(ipset_name, ip, netmask) - Add ip and mask into ipset. IPv6 should should be enclosed in brackets. Netmask may be identified as number or in IP form. Note that number requires leading slash, e.g. "/24" or "255.255.255.0".
• ipset.commit(ipset_name) - Makes pending ip set usable by ip_is_trusted. Pending ip set is cleared.
• ipset.list() - List declared ip sets.
• ipset.print(ipset_name, pending) - Dump ipset trees. If pending non zero then pending ipset is dumped.
They do not really match the set of mi commands in modules_k/permissions - the modules seems a bit different.
5.1. address_reload
5.2. address_dump
5.3. subnet_dump
5.4. trusted_reload
5.5. trusted_dump
5.6. allow_uri . test a URI
I have started implementing these commands as RPC like you wrote.
The module_s rpc commands seems to be based on the thinking with the config framework, where you change a set and then commit.
A big difference, apart from the different way of thinking, is that modules_s allow changes to the set over RPC - cleaning a group and
adding to a group. In modules_k this would lead to a difference between in-memory data and database, that would disappear at restart/reload.
In modules_k that would require a database operation (or text file) and then a reload.
Just so everyone is clear on this - we will loose some functionality over RPC but the general function is still around.
Have a great weekend!
/O
More information about the sr-dev
mailing list