On 10/02/2013 07:14 AM, David Stainton wrote:
Hi,
I am wondering how I should combine various twisted interfaces
in a way that makes sense. It probably shows here... that I'm new to
twisted.
The Linux iptables can log packets to the netfilter_log which can give
access to user space.
I wrote a simple twisted Reader (IReadDescriptor implementation) that is
working functional code...
https://gist.github.com/david415/6789612
But since these are packets it returns... should I implement a "read
only Protocol"?
Well, if your transport is not writable, just don't implement that -
Exceptions will be raised if you mistakenly try to write, so nothing bad
will happen.
The protocol's dataReceive() method could be called from the
NFLogReader's doRead() method.
Since they're packets it should really be a DatagramProtocol and call
datagramReceived.
Does this mean that NFLogReader would be responsible for calling
buildProtocol to construct the NFLogProtocol?
Typically a factory is responsible for calling buildProtocol, but in
most datagram uses, there is only one protocol instance per port, so you
just instantiate it. See e.g.
http://twistedmatrix.com/documents/current/core/howto/udp.html
In the normal Twisted examples the buildProtocol seems to be called from
the react loop..
Should I pass the protocol factory and the reader to the service?
Sorry I don't know what this means.
If I want to drop privileges right after retrieving the filedescriptor
for netfilter_log, shall I use a Twisted Service/Application to drop the
root privs to a non-superuser?
That would be the "Twisted" way of doing it, yes.
Should the privileges be dropped by the privilegedStartService() method?
The manual says that method is for preparing to drop services...
What I want out of all of this is the most high performance and general
solution to utilizing netfilter_log in twisted...
Couple of general points:
The nflog_cffi code is... hard to read. But it's not obvious to me that
it sets the FD to nonblocking anywhere, or that it's (frankly weird)
generator construct will actually yield the "nonblock" marker object at
the right times. You might want to test this.
On a different note, a colleague wrote some code to process the IPQUEUE
target of iptables a while back. This code did something similar to your
example above, but it didn't bother integrating with the
protocol/factory machinery, and you could consider whether it makes
sense to do so - unlike a TCP or UDP port, you're unlikely to ever have
>1 nflog "connection" per-process, so it's not obvious that using the
full generality of the factory/protocol machinery is appropriate.
However if you do that, I would just copy what Twisted does for UDP;
don't model it on TCP.
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
