ABOUT
Revisiting the Temple of Zorp
Forgive me, dear readers, for I have been lazy. I haven’t worked on anything noteworthy during the past month, except some internal stuff, which I have high hopes for, but can’t go into more details just yet. Nevertheless, it wasn’t all that bad, since I spent a lot of time going over my various todo items, refining them, thinking about the best way to get them done. That was actually useful, as it turned out that there’s far more use in some of these ideas than I anticipated. But, that’s not what I want to talk about today.
Today marks my return to the Temple of Zorp, at least, partly. There are two things I want to do with Zorp in the near future: one is to provide Debian and Ubuntu packages of the latest and greatest Zorp GPL, the same way I provide packages for syslog-ng (of which, I will soon start providing experimental 3.4 debs, too).
The next thing is a new proxy, and a series of blog posts explaining how the proxy is implemented, and various stages of its implementation. This post happens to be the first in the series, and I will try to summarize and explain what kind of proxy I wish to write, and why.
It all started with me attempting to play some weird games with my MongoDB cluster, and it fell apart. But that’s no big deal, I break it every day in, for fun. The problem is when it comes to debugging problems: I hate the mongodb logs, can’t make heads and tails out of them, so I ended up trying to sniff the communication between my clients, my nodes and the rest with Wireshark. Sadly, wireshark’s mongodb/bson dissector isn’t all that useful, either.
So there I stood, wishing I had an easy way to debug the wire protocol, only the parts I’m interested in, when it dawned on me: if I had a Zorp proxy, I could just configure that appropriately, and voila! It would also have some other benefits, like restricting access based on things not available to the mongodb server.
And from these ideas, the plan was born: I will write a MongoDB proxy for Zorp, and document the process on this very blog! Let us begin!
I plan to implement the proxy in three stages: the first will be a fairly bare-bones thing, one that’s able to validate and forward the wire protocol, and log some interesting stuff, depending on the configured log level.
The second stage will introduce hooks, so one can change what happens from python, on both sides. This will allow me to trigger artificial errors, and setup situations that I want to test easier.
The third stage will introduce convenience helpers, to make some common tasks easier and more straightforward. In the end, I want to be able to do things like, allowing inserts only on specific collections, and return a custom getLastError message for others, and at the same time, have sane logging features.
All of these stages will be throughly documented, and appropriately tagged in a git repository I’m about to set up. With a bit of luck, this will end up being an experiment useful to not just myself, but others aswell.
