Description of suggestion: firewalld currently uses system calls (fork/spawn) to interact with the kernel netfilter tables. The Python code maintains a cache of what it expects the kernel tables to be and so does iptables(-multi). A Python library exists that uses the iptc C library to directly interface to the kernel data. This is the same C library that iptables itself uses to do the job. Before the Python code "matures" it might be worth while exploring the use of this Python library to eliminate the additional caching and, possibly, run firewalld without requiring the iptables binaries, just the -libs. I stumbled across the project while looking to do something similar some time ago but the IPv6 capability was not available then. IPv6 is now integrated and the project refactored. Python (ctypes, in-process) classes for tables, chains, rules, matches and targets, all cached (weak-ref) with auto-commit options. Link: http://ldx.github.com/python-iptables/ Thanks for your efforts in this complex area and I hope this can be of help in future developments. --DaveG.
Sounds nice to me at first glance, however ... and now I'll cite from [1]: " The recommended solution given by iptables developers is to spawn the iptables command with execl() or system(). It’s explicitly stated that there’s no stable/public API to do that [2] " Given that python-iptables is just a libiptc/libxtables bindings, the situation is similar. We've been also planning a re-write to C for a long time so I'm not sure we want to experiment with another library meanwhile. [1] http://www.bani.com.br/lang/en/2012/05/programmatically-managing-iptables-rules-in-c-iptc/ [2] http://www.netfilter.org/documentation/FAQ/netfilter-faq-4.html#ss4.5
Thanks for the prompt reply. Just thought I'd float the idea. Happy to close the issue. Good luck with the C rewrite! --DaveG.
Thanks for the suggestion, but I'm sure we won't go this way so closing right now.