We upgraded our Jabber from Openfire 3.6.4 to 3.7.0 but suddenly it wasn’t talking to others who had self-signed certificates (despite having been told that was ok; in such circumstances Jabber offers a “dialback” to weakly establish TLS connectivity). It was breaking with messages like:

 Error trying to connect to remote server: net.au (DNS lookup: net.au:5269)

in the logs. Took a while to isolate that (Java stack traces in server logs, how I hate thee), but that led me to this discussion about the problem.

Turns out to be, more or less, this issue.

Back to the original thread, comment by Gordon Messmer turns the trick; he isolated the specific problem and provided a patch which you can reverse apply. Since I had already downloaded the 3.7.1 nightly build .deb and installed it (which did not fix the problem), but with a patch in hand, I was then able to follow the advice of “Devil” to rebuild the server and replace the openfire.jar manually.

Obviously I will rebuild the .deb in question shortly, but I can confirm that reverting that specific change does restore server to server functionality with people you used to be able to connect to fine.

Meanwhile 3.7.1, alpha though it may be, does seem to have a fair few fixes in it. We’ll keep that for now.

AfC

I don’t normally get too excited about threaded discussions, but I was impressed with the comments in response to a recent Ask Slashdot post asking for advice about building and distributing Linux binaries that will really work across various distros.

The replies were mostly thoughtful and the overall impression was the same sort of even handedness you’d expect from a wikipedia article. Unsurprisingly there was much discussion about static linking but there were links to several interesting looking projects I’d not heard of.

At another point, the thread considered what happens when you have to ship as binary (for whatever reason) instead of being able to ship source. Two comments in particular seemed insightful:

If you’re making games, a good solution is to make the game engine open source, and charge for the data. The game engine can get ported to dog knows what platforms without any effort from you, and you can still get compensated by charging for the data files. The real value of a game tends to be in the data files, as they control the story line, the graphics, the sound effects… ref

and

If you absolutely can’t have the source to your app open, you could do like the developers of binary kernel modules: ship your software in object format, with all the parts that interface with the rest of the system open source. That way …. they can compile and link the glue layer to make your code work on their system.

If you take this approach, be very careful to have everything that interfaces with the outside system in the open source part; I’ve worked with kernel modules where some OS calls were still made from inside the binary part, and they were hell. ref

I’m all for source distribution but there are times when its not appropriate; if you consider the above in best-practice abstraction and separation-of-concerns terms (as opposed to the usual religious licencing debate) there is food for thought especially for those who struggle to make widely available software.

Anyway, worth a read.

AfC