A Blog by Tim Bishop

I’ve spent the past couple of weeks on and off trying to figure out why the OOF (Out Of Office) and Free/Busy availability information were broken in our Outlook 2007 clients. They generated errors saying the service was not available. They worked fine in OWA.

After some digging I thought I’d try some of the EWS URLs manually in a web browser. I’d tried some of the others and although they produced odd things, they at least did something. The EWS URLs just produced a 404.

Looking in IIS there were clearly files in the EWS directory with the correct names, so something else must have been missing. I started a comparison with another reference system. Eventually I noticed a difference in the web.config file located in C:\Program Files\Microsoft\Exchange Server\ClientAccess\exchweb\ews.

The copy on our production system contained entries like this:

<codeBase version=”0.0.0.0″ href=”file:///%ExchangeInstallDir%bin\Microsoft.Exchange.Common.IL.dll” />

Whilst our reference system contained entries like this:

<codeBase version=”0.0.0.0″ href=”file:///C:\Program Files\Microsoft\Exchange Server\bin\Microsoft.Exchange.Common.IL.dll” />

As far as I could tell %ExchangeInstallDir% was not set on either system. Further, looking at the autodiscover and OWA web.config files I noticed they did it the same way as the reference system.

So I ducked over to a Unix system, did a proper comparison of the production file versus the reference one and determined that the only difference was the expansion of the variable. So I simply dropped the reference one in to place on the production system and restarted IIS.

And it worked!

I’m not sure how we got in to that state, but I’m pleased it’s sorted out. I’m not particularly getting on with this Exchange stuff, and peculiar issues like this really don’t help. Given we installed both the production and reference systems in the same way I can’t understand how this happened.

Now to fix the remaining issues…

Update: Now that I know what the issue was I can google for it. I found this post (better formatted here for non-IE users) which shows that the issue occured with the accidently released update for Exchange a while back. We got this update in the small window in which it was available and later uninstalled it. Looks like that caused the problem.

I’ve been looking at filesystem snapshots on FreeBSD lately and I have to say I wasn’t too impressed. Yes, the functionality is there, but the interface sucks. For UFS you have to create a snapshot, which takes a while, and which appears as a file within the filesystem you’re snapshotting. Then you have to use an md device to mount it. ZFS is easier, but different. What we need is a simple and standard interface to both.

Fortunately I discovered Ralf Engelschall’s snapshot management utilities. He’s written a couple of tools that make creating and managing snapshots really easy.

Using cron one can schedule creation of hourly, daily and weekly snapshots for filesystems. You can specify that you want 3 hourly snapshots, 2 daily and 1 weekly for a given filesystem. The system takes care of everything else. And by using amd (the FreeBSD automounter) these snapshots can automatically be made available through a given mount point. It couldn’t get any easier!

Well, actually, it could get slightly easier. Currently these tools are available from Ralf’s site or from the FreeBSD ports collection. It strikes me that something as useful and fundamental as this should really make its way in to the base system.

Update: Whilst this worked well in testing, once I applied it to my server with a large (approx, but not over, 2TB) filesystem it hung the machine completely, even on the console. I haven’t investigated further yet.

Update 2: Well, I have to say I’m disappointed. Ralf’s scripts worked great, but the snapshotting of large UFS filesystems in FreeBSD is as good as broken. When it takes hours to create a snapshot, locking out the filesystem (and maybe even the machine) for hours, it might as well not be there. There seems to be an attitude of “just accept it”, which I’m not impressed about either. Roll on ZFS… (yes - I know it’s there now, but I’d like it to mature just a little more ).

A few days I wrote about my new Soekris net5501 router. In that post I mentioned that the only thing left to sort out was the wireless card. It turned out to be simpler to do than I thought.

I decided to go for a Netgear WG311T. It’s a 802.11b/g PCI card that’s compatible with FreeBSD through the Atheros chipset and ath driver, and it fits in the net5501 just fine. As expected I had to remove the net5501 board from the case to attach the card, but that only involved undoing a handful of screws.

Getting it working on FreeBSD was trivial. I added the following lines to my kernel configuration (they’re already there in GENERIC, I believe, but I built my own kernel because of the net5501):

device wlan
device wlan_ccmp
device wlan_scan_ap
device wlan_scan_sta
device wlan_xauth
device ath
device ath_hal
device ath_rate_sample

Then it was a simple case of initialising the card in /etc/rc.conf:

ifconfig_ath0="inet 1.2.3.4 netmask 255.255.255.0 ssid myssid mode 11g mediaopt hostap"
ipv6_ifconfig_ath0="1:2:3::4 prefixlen 64"

And I also added ath0 to rtadvd_interfaces and dhcpd_interfaces.

With that done the final step was to configure hostapd through /etc/hostapd.conf:

interface=ath0
debug=1
ctrl_interface=/var/run/hostapd
ctrl_interface_group=wheel
ssid=myssid
country_code=GB
wpa=2
wpa_passphrase=my passphrase
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP

This enables WPA2 using AES (rather than TKIP).

Connecting clients was no problem. My laptop and my squeezeboxes all connected fine.

One concern I had doing this was whether a PCI wireless card would have the same signal strength as a purpose access point. I seem to be getting the same signal power from this new setup as I did from my old 3com 802.11b access point. What does that tell me? I’m not sure. I would have expected technology to have come on a bit over the years. Maybe it has, but the fact that the card is lower powered balances it out? Regardless, it covers my whole house, so it’s not an issue.

So now I’m done. I’ve switched off my last piece of old equipment. My power draw has dropped significantly, the noise levels have decreased, and I’m a happy geek with a cupboard full of shiny new stuff.

We use the Eduroam wireless network at the University of Kent. There’s various guides for getting it working on Linux, but I thought I’d try on FreeBSD. It’s pretty simple.

First create /etc/wpa_supplicant.conf with the following content:

network={
ssid="eduroam"
proto=WPA WPA2
key_mgmt=WPA-EAP
eap=PEAP
group=TKIP
identity="tdb@kent.ac.uk"
password="YourPassword"
}

Then add the following to /etc/rc.conf:

ifconfig_ath0="WPA DHCP"

Replacing ath0 with your wireless adapter if it’s different.

Then start it up as follows (or reboot):

# /etc/rc.d/netif start

You can use ifconfig to confirm the link is up, and ping to test.

For more general information about wireless networking in FreeBSD please see this section of the handbook.

It seems to be the “in thing” to do at the moment; get a Current Cost electricity meter and produce pretty graphs. I couldn’t resist, so I picked one up with a USB cable to connect it to my server.

The system itself is trivial to install. There’s a box with a clamp that attaches to your mains supply (your side of the house meter), and a display which can be placed anywhere in your house (within the wireless range of the two units). Turn it on and it just works. I adjusted the electricity prices, but it’s not clear how accurate that’ll be given the multiple tiers of pricing we have.

So even without connecting it to a PC it’s a pretty useful device. Although I am developing a habit of running around looking for what’s caused the usage to jump up. Hopefully that’ll pass

Connecting it to my FreeBSD server took a bit of effort. It needed the ucom module, but (I think) because I had ugen built in to the kernel it was using that instead. A kernel rebuild to include both fixed it. I also got some strange issues connecting to the device. On the first connect I got the expected XML output, but on the second connect I got messed up output. Turns out not to happen when I use my script to parse the data, so I don’t think I’ll worry about it.

I did the graphing using rrdtool. I’d like to take the credit for doing that, but I just stole all of Paul’s work. Thanks Paul

The excitement has gone now, but I’m sure over time the data will prove to be interesting and useful.

A few months back I wrote about building a new server. It turned out to be more complicated than I thought, but 5 months on it’s still working well. Over the last few weeks I’ve been working on my next project - replacing my router.

The old router was an old dual CPU Pentium 3 machine with a couple of small SCSI hard disks in it. It was a full tower case and took up a lot of room and made a lot of noise. And, surprisingly, the power consumption was pretty similar to the server I recently built (which has way more in it). It even still had the original Speedtouch USB modem that BT once gave to me. So it had to go.

I spent quite some time deliberating the way forward. I could have gone for a domestic router like most other people do, but I’m a geek, and I like the flexibility of doing it myself. But at the same time, a small sized unit, with low power requirements, and no noise, is what I wanted. The solution came in the form of a Soekris net5501.

I went for the net5501-70 which has a 500Mhz CPU and 512MB of RAM. Not a lot by today’s standards, but more than sufficient for what I needed. And incidently, it’s quicker than the old router. I got the model with a case, and got the mounting brackets for a hard drive (which although I don’t intend to use at this stage, it was cheaper to get it now than later). I also purchased a pair of 4GB SanDisk Extreme III Compact Flash cards to run the thing from. It’s worth noting that Soekris recommend SanDisk CF cards, and they’re peanuts at play.com.

The next point to consider was how to connect to the ADSL line. I could have stuck with the USB modem, but the drivers were aging, I wasn’t sure if it was the cause of the odd disconnections and failures to reconnect that I’d been getting. I looked at internal ADSL cards, but it seemed to be a bit of a gamble as to how they worked and if I’d be able to get the right drivers. In the end I settled on the Draytek Vigor 110.

The Vigor 110 is basically just a PPPoA to PPPoE bridge. PPPoE isn’t widely used in the UK, but is in other parts of the world, so the support in FreeBSD was good (via ppp and the ng_pppoe module). It worked perfectly. It really was just a case of plugging it in and pointing ppp at it - no configuration required! And, just like the USB modem, it gives the router IP directly to the PC, so there’s no messing around to get that working either.

Longer term I plan to fill the net5501’s PCI slot with a wireless card, but I haven’t decided which to go for yet. This would turn the unit in to my wifi access point as well, but for now I’ll just stick with the separate one. I’d welcome advice on cards that are supported by FreeBSD.

So, that’s hardware all sorted. Next came the software. If you’ve been following my other posts you’ll know I’m a big fan of FreeBSD, so it’s pretty clear what route I was going to take here. But given the use of CF cards I had to approach things differently. I also wanted to be able to power the system off without causing any filesystem problems, so this required the card to be mounted read-only.

NanoBSD to the rescue! NanoBSD is a script that builds an image containing FreeBSD that can be written directly to a CF card (or anything else, really). It’s customisable, and I wrote a few bits to pull down the packages I wanted, and to make some configuration tweaks. It has a read-only root filesystem on the card, and uses memory-backed filesystems for /var and /etc. Config is stored in a separate partition on the disk and is copied to the memory-backed /etc during the boot process. But the best bit is the way it handles upgrades.

Upgrades are neatly done by having two root filesystems on the card. When you’re running off one you’re free to upgrade the other. NanoBSD generates two images; one for the entire card, and one that can be written to a single root filesystem. It also provides a script to write the image to the card and update the boot loader to boot from the right partition. So upgrading is as simple as re-running the NanoBSD script, writing the new image to the “other” partition, and rebooting. It can all be done live, and the only downtime is the time taken for a reboot (which is under a minute).

Of course, to use NanoBSD you need another system to do the builds on. Fortunately I’ve got a nice beefy server that can handle the job (although it took a few hacks to build the i386 image on an amd64 system). I’ve also got a nice Tinderbox setup which I already use for testing ports and which provided a nice supply of up-to-date packages.

So I’m happy, at last. Apart from my wifi access point I’ve managed to replace all my aging, power hungry, noisy equipment with nice new stuff. I guess I’ll be doing it all again in a few years .