I'm still thinking about my hobbitfetch/msgcache replacement I asked about a few weeks ago. Using only ssh from the Hobbit server. Client machine is out in DMZ, thus unable to talk to Hobbit server. I cannot run a listener (msgcache) on the client (policy reasons, not technical ones).
Here are my thoughts. Maybe someone can expand on them or suggest a different approach.
(1) Run normal Hobbit client on DMZ machine. (1a) Client appears to collect data just fine into ~hobbit/tmp/msg.XXX.txt (1b) Client would try to connect to Hobbit server to transmit this file, and fail. Fine. Let it fail. It appears to do so gracefully. Question: Any simple way to make it stop trying to connect and still behave gracefully? chmod 000 ~hobbit/bin/bb? Change BBDISP="" in ~hobbit/etc/hobbitclient.cfg?
(2) Create a Hobbit server script to use socks/ssh to retrieve that ~hobbit/tmp/msg.XXX.txt file from the client machine (it's trivial to write such a thing)
(3) Have this server script feed the raw data retrieved in step (2) into the Hobbit listener (which would be localhost:1984), such that it appears to the Hobbit listener the data came in from the client computer in the normal manner.
Step (3) is what I don't quite know how to implement yet. I'm familiar with using the bb command to send messages, but those are formatted messages, not raw data as would be present in the retrieved msg.XXX.tmp file. I want to assure that the guts of the Hobbit server processes this proxied client raw data just as if the client had sent it instead of my custom server script.
Is there some trivial way to accomplish (3) that I'm just missing searching through the man pages? I could have my custom server script parse the raw data itself and then create individual Hobbit messages (to send via the bb command), but that sounds like I'd be reinventing the wheel. Hobbit server processes already know how to parse this data ... if I could just tap into that part of it.
Thanks!