Zaf’s Blog

I’ve been playing with a VMWare image of Open-Xchange today. VMWare is a neat way to play with systems, especially ones as invasive as Open-Xchange.

But on to Open-Xchange, it’s a promising alternative to Microsoft Exchange. I’ve only had a chance to play with it a little bit, but it certainly feels nice to use.

My only concerns so far are:

• No LDAP integration. I feel this is a must these days. Very little of our systems do not authenticate back to the LDAP.
• No themes. It would be nice if we could theme the interface, but thats not a must by any means
• No Windows clients except web-based. Ok, there is the Outlook plugin, but thats not GPL. By now I would have hoped to see a real GPL/Open Source plugin for Outlook that actually worked.

Its certainly worth looking further into.

Apache2 + SSL + Client Cerificate Authenticate + Directory level + Uploading Large Files = Problem.

Ok, so I’ll explain… We have a company portal, which is secured using SSL Client Side Certificate authentication. This works very well. The portal is primarily a Wiki (MediaWiki actually), allowing a CMS of sorts. I tried to upload a PDF to the wiki, and got a strange error. Thinking it was a MediaWiki problem, I spent quite awhile looking through various forums.

In the end I found an error message in the apache logs for the portal:
request body exceeds maximum size for SSL buffer

This lead to the following bug report statement:

This does not work on directory level with large files, because we currently do
not buffer the request body on disk but only 128k at max in memory. Moving
SSLVerifyClient require to virtual host level will make it work (see also
PR12355)

So in the end, the problem was because I was using

• Apache
• With SSL
• With Client-Side Certificate Authentication
• With Directory based SSL rules

And I tried to upload a file bigger than 128kWhat an obscure bug.

The fix was to simply move the Authentication from the Location directive to the Virtual Server directive

So I’ve just finished Quarter Share, by Nathan Lowell. Its a rather happy tale of a young man, set in a universe where ships travel between systems hauling freight. I won’t do a full review of it, as I think the first book doesn’t really stand by itself well. I’m hoping the second book continues the great tale, and leads to the meat of the story.

Now I’m listening to the second part, Half Share.

The whole tale is worth a listen. Its very free.

So I tried upgrading two of our servers tonight from Ubuntu edgy to feisty.

I’m a seat-of-the-pants kinda guy, so I upgraded in-place, over a SSH connection. The only thing I did that was slightly sane was I firewalled off our webservices and email servers during the upgrade, that way if I broke anything, the big wide interweb wouldn’t see it broken (they’d just not be able to access the site at all).

Both upgrades were a partial failure. The firewall ran into major problems, I suspect with the init upgrade, init seemed to have run into a problem. The process was there (showing init –restart as its process name), but it didn’t reap any zombies. I had to hard restart the system (reboot -f) to get it to restart, but I’ll admit it came up cleanly. Well, Ubuntu’s side of things came up cleanly.

I found that I’ve modified the firewall quite a bit when it comes to routing an IPv6 stuff, and I was naughty and hadn’t saved all those settings into config files, boot scripts, etc.

This is actually a good thing, as I am planning to blog my entire IPv6 setup, which I feel is rather unique. So now I have a pretty good idea of what needs to be done to bring it up. I’m still tidying some loose ends, and may have found a kernel bug in the process (Dead loop on virtual device tun6to4, fix it urgently was logged by the kernel repeatedly for awhile).

The second server didn’t fair as well, but that was probably because I was logged in remotely. Maybe due to the v6 annoyances, I lost my SSH connection to the server, so I couldn’t continue the upgrade as it was. I was forced to use apt-get -f install, etc to get it back into a running state. There was also some funkyness with /tmp that I couldn’t explain, but after the reboot things were sane again.

I’m really not happy about having to reboot to fix things. Its not how its done in Linux. I’ll acknowledge that it could well be due to things like libc and kernel upgrades, but Debian does it much better. I can’t think of a single case where an upgrade has required a reboot before things are sane again. Yes, you have to restart processes, but not reboot. Oh, and yes, you have to reboot to install a new running kernel…. For now..

Hopefully I’ll get around to blogging the rest of my setup soonish.

Contra to popular belief, IPv6 is here, now, and is working.

In fact, you’re using it right now. There are a number of machines located in my “data-centre” network at my house. These machines all have IPv6 addresses. Actually, Cerberus, the firewall, is responsible for allocating the IPv6 addresses. Its an IPv6 router, and issues addresses to any machine in the network (think IPv6, but better).

The webserver that you are currently talking to is actually listening on an IPv6 address only. Cerberus runs an IPv4 to v6 reverse web proxy. If you actually are using an IPv6 connection, you will bypass Cerberus and connect directly to this machine (darwin.nrc.co.nz).

One of my websites, Psylon.co.nz is accessible only via IPv6.

Why am I doing it this way? One its a great learning process. Two it makes maintenance much easier. I don’t use name-based virtual hosting with my primary webserver. Each website gets its own IPv6 address. True the cerberus v4 gateway makes it all name-based when using v4, but when using v6, it all works very very well.

The only thing wrong with my setup is I have chosen not to set my system up with a tunneled v6 address as the primary address. My primary IP address range is 2002:3cea:9ce3::/48, which is a 6to4 IP address. (This IP address range is the range thats issued to all the clients on my network. In theory I could issue tunneled (see below) addresses to my clients and leave the routing decision to the client, but this would be inefficient). The end result is that any site which is properly configured for IPv6 can route to my sites without routing through slow tunnels.

I also have a tunnel (2001:388:c034::/48) provided by aarnet.net.au, which as far as I can figure, is the fastest tunnel broker for me. It adds about 200ms. At the moment, I only use the tunnel to route to non 6to4 addresses.

For my next blog entry, I’ll attempt to document how I’ve set all this up, and what problems I ran into.