[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