Roachys Weblog

Following a reboot (which is rare) I had problems connecting to our Exch 2003 server via Evolution in Intrepid – it simply wouldn’t authenticate. I deleted the mailbox account and tried to recreate, populating all the fields…..to be greeted with an “Exchange Account is Offline” message.

Following this I ran evolution from the command line – the output of which was:

e-data-server-ui-Message: Unable to find password(s) in keyring (Keyring reports: No matching results)
e-data-server-ui-Message: Key file does not have group ‘Passwords-Exchange’

I checked available keys in my keychain and the correct keys were there – along with appropriate passwords….

The I stumbled across the following bug report:

https://bugs.launchpad.net/ubuntu/+source/evolution-exchange/+bug/207723

Where I found this comment from Timothy Alexander:

“Something that worked for me was clearing the “mailbox name” under exchange settings, and reauthenticating on that page. The auth went through fine, and it filled out the mailbox again (exactly the same way) but after a restart of evolution it worked fine.”

I tried removing the mailbox name and clicking authenticate, was greeted with the usual errors, but following a restart of evolution it worked!

For a while I’ve been fighting the good fight with poor stability using the webDav Exchange connection in Novell evolution.  This has now been replaced with a more functional solution (proper native MAPI support) in Ubuntu 8.10 and will be soon in Fedora 10 with OpenChange.

Finally, Evolution is behaving as you might expect it to when connecting to an Exchange server – the improvements are immense, both in stability and functionality.

The OpenChange site is here for more information:

http://www.openchange.org/index.php?option=com_frontpage&Itemid=1

Hopefully this will be an end to using a buggy interface and the all to frequent crashes, along with the curse of occasional missing mail items.  I’ve only been using it for a day, but already I’m loving it!

I’ve just finished installing a pfSense firewall as a second gateway for a network that required a dedicated internet connection for some services. Some of the hosts on the network use the main office internet connection as their default gateway. As a result of this I was unable to connect to these hosts from remotely via the VPN, as the return path for the packets attempts to go via the primary internet connection, rather than via the VPN.

I had a quick glance at the pfSense/OpenVPN docs to see whether there was anything I could specify in pfSense and they stated that the machines needed to use the pfSense as the default gateway – this was unacceptable for our purposes here (one of the devices in question is the Asterisk VoIP server on the network which needs to use the other Internet connection for it’s external traffic). There is an easy solution to this however by simply adding a static route back to the IP range issued to DHCP clients via the pfSense’s internal IP.

This looks something like this:

Effectively any internal machines that need to be visible over the VPN need to have an appropriate return path configured. The DHCP scope I have used for VPN clients is 10.0.200.0/24.
For linux machines on the network, the route can be added on a temporary basis (ie. until reboot) by entering the following command on the host:

route add -net 10.0.200.0/24 gw 10.204.6.1

or permanently by adding an entry into the /etc/sysconfig/static-routes (on Centos as per http://www.centos.org/docs/5/html/5.1/Deployment_Guide/s1-networkscripts-static-routes.html)

On Windows hosts this can be achieved by adding a persistent route:

route add -p 10.0.200.0 mask 255.255.255.0 10.204.6.1