Hi Karl, I would be myself interested into it. Currently the situation is not too bad in the sense that who wants to separate client and server can still use ssh/rsh as a glue. This brings modularity, keeps everything out of pmacct (read: no dependencies) and possibly offers security if the underlying infrastructure can't be trusted.
The downside of it is inefficiency: aside from encryption, it is a "shell-based" solution. It's still OK for spawining macro-operations like retrieving the full memory table or erasing it: connect remotely once, then parse locally the results and feed them into the 3rd party application. It's definitely bad for micro-operations, say for example, to retrieve on a 5-minutes basis traffic statistics for tens or hundreds of individual IP addresses, as for each of them it should pay the ssh/ rsh toll. The toll would indeed be still there with socat but greatly mitigated, granted that i understand correctly that socat also comes as a library you can link against (otherwise the point would be the same). I agree on the fact that adding a (even optional) dependency is not optimal, expecially if the piece in the middle is not immediatly installable by the end-user because it's not packaged for his OS (might not be the case for socat, is it?). All this said, let me just shoot a proposal: as the in-memory table client/server communication is already based on request/reply headers, operation codes, etc. (so let's say the protocol is there) what about keeping it simple by encoding all of this in either UDP or TCP packets with a bit of socket programming? MTU is the only real thing to watch out. For encryption (or perhaps just message digesting would suffice?) OpenSSL is almost everywhere out there and ready to be linked. Cheers, Paolo On Mon, Feb 23, 2009 at 08:53:05PM -0600, Karl O. Pinc wrote: > Hi, > > I'm working on code that uses socat to re-create > the pmacctd socket on a machine elsewhere on the > network. The purpose is so that pmacctd can > be run with memory tables and be very lightweight, > and all the other work can be done on a > bigger box elsewhere on the network. > > I would like this code to eventually be > distributed with pmacct. > > What I've got now works, for some value of > "works". There's bugs to fix and features > to add. This is pre-alpha code. > > The big feature would be a pmacct-netd-spawn > program. I'm thinking it will talk directly > over the network to a daemon spawned by pmacct-netd-spwan > (or maybe that program will run as a deamon itself, > in which case I should probably change the name.) > Anyhow, pmacctd-netd-spawn will "publish" a list > of socketpath/port pairs, so that pmacct-netd-spawn > can spawn pmacct-netd daemons for every socket > on the pmacctd machine so the socket structure > can be re-created on the pmacct machine. > > I'd also like to (eventually) write some docbook to generate > man pages. I suppose this means a Makefile.in > as well. Stuff that's not documented is awfully > hard to use. > > The alternative is to build networking into > the pmacct/pmacctd client/server code. > > The downside of the "socat solution" is that > it adds an additional dependency (socat) > and an additional layer of complication > and a certain amount of inefficiency. > > The upside is that it's modular. People > who don't need network client/server don't > have to think about it. Socat can also > support OpenSSL for serious encryption, > logs, supports socks proxies, IPv6, UDP, > and so forth. (I've no particular plans > for these features, but I suppose if nothing > else there could be an option that > passes arguments through to socat so > the end-user can do what he wants.) > > I thought this would be a good time to post > what I've got so I can get feedback > earlier rather than later. Ultimately, > socat is glue, albeit versatile glue. > > Is the pmacct project interested in > this approach? > > What would be a good default port > number? (You need one port number > per exported Unix socket, so the > port numbers used would count up, > like xdm does per remote X display.) > > Regards, > > Karl <[email protected]> > Free Software: "You don't pay back, you pay forward." > -- Robert A. Heinlein _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
