Skip navigation
Outline of the recent problems with Evolution email client, and some SUSE 10 notes


I mentioned a few entrys ago that this article would be coming along. Now it as good a time as any to write it.  Most folks reading a Linux column probably know at least a little about Evolution, but a quick levelset:


Evolution is an office application sort of like MS Outlook. It has email, calendaring, task lists and so on.  Early versions implemented a slavish Outlook look as well, but later versions "got better". Evolution was written originally by a company names Ximian, and while Evolution was open source, they made a proprietary add in called "Exchange Connector" that allowed Evolution to work as a "native" protocol client against MS Exchange 2000 and 2003. I bought a copy of Connector back then, and ran it on my Mandrake desktop, so that I never had to use MS Outlook, not even under Codeweavers Crossover product (although I could, because I bought that too).


Novell bought Ximian, and open-sourced the Connector, which all the major distros picked up, and that is where my trouble started.


The last totally working version I had of Evolution and Connector was the very first open source version I could find: Fedora Core 2, running Evolution 1.4.5 (or may 1.4.6... been a while...). I practically skipped Fedora Core 3 because in my tests, I could never get its version of Connector to work. This was early in the 2.0 days... 2.0.2 or thereabouts. Towards the end FC3 shipped 2.0.4, and this started working, although Connector crashed quite a bit. But it worked enough that I finally upgraded the main laptop I use (the IBM T41) to FC3.


Oddly, SUSE 9.3 was a non-starter: even though Novell owns both SUSE and Ximian, I could never get the Connector to work right there either (although turning off all the Groupwise plugins seemed to make it nearly work.). Fedora Core 4 shipped 2.2.2, later updated to 2.2.3 and that also works, and is slightly more stable but still not great.


Along the way of this testing, I also a couple Debian derived distros to see how that version of Evolution Connector would work. Xandros and Knoppix (locally installed) pulled their .debs from the same repositorys for Evolution Connector though, so I was not really testing a different level of Connector as it turned out. Neither worked.


At this point, the only version of Evolution / Connector that I could get to work at all was the one that shipped late in FC3 and then later the Fedora Core 4 version. To make matters even more confusing, some of the people on my team could not get the Fedora Core 4 version to work: the only one that really worked well was back in the release 1.4.x days of Fedora Core 2!


The would be OK, but Evolution 2.x implemented look and feel changes that I wanted, and it also had Spam filtering that was very nice: one option even allows you to tie it in to Spam Assassin, although that is .... very....slow.... Span Assassin works better when you do not run it in the client, but rather up at the transport layer. But it worked (on Fedora) and was handy for me because I get hundreds of Spam's a day *after* BMC drops over 70% of the incoming email on the floor because it is known spam.


I have of course googled around trying to find out why Evolution has so many problems (for me anyway), and why Fedora's version works when SUSE's 9.3 and Debians versions did not. And I can find nothing. I have to assume that there is something about our environment that is just plain hostile to Evolution.


Connector works by accessing MS Exchange the same way that the Web version of Outlook does. MS used WebDAV to export the files to the client, and layered their HTML based interface over that. Connector uses WebDAV to get at the files, and uses it's own, non-web, regular email "heavy" client interface instead. The same Evolution user interface that also works via IMAP or POP: WebDAV is just an access protocol.


I assume Ximian had to do a fair amount of work to crack the files that WebDAV presents, but given the low noise ratio out in "googlespace", and the high level of Evolution uptake, I have to assume that they did this part pretty well. I also have tested MS Exchange servers that I use for my LinuxWorld lab that I have absolutely no issues with. My lab is a straight install of MS Exchange: no mucking around with the defaults.


One other data point here: Thunderbird and Kmail have no problems accessing MS Exchange via IMAP, but Evolution 2.x won't work that way either. We have POP turned off, so I can't test that.


Here is the good news though: SUSE 10 shipped with 2.4.0... which works but blows up now and again. But it does work. And an update today brought every up to these levels:




But it still has limited runtime before the Connector crashes. And Evolution leaves a great deal of itself still running so that I have to run evolution --force-shutdown, and then poke around with PS and kill to make sure all the bits are gone (or just reboot, but that is way too Windowsey).


I have not tested every single thing in SUSE 10 yet, but everything I have looked at is a real refinement over 9.3. Kontact gets better and better, and SUSE 10 shipped Kontact version 1.1.2. The MS Exchange calendar download feature of Kontact is working great: I have not looked to see if they have upload (which has never worked quite right) going yet. LDAP address books in Kmail also still elude me: I have locked my self out of my MS Exchange account twice today with a bit of experimentation with them. Or maybe it's Evolution doing that lockout thing.... hard to be sure. I have it all up and running, so I guess I'll need to step though it later and see if I can figure it out.


Why bother with all of this?


The easy way out here would of course be to just give up: I only control the client side of this problem, but here is where it gets a little odder. I have crashed MS Exchange itself 3 times over the last few months. And every time I did it I was in MS Outlook 2003, under MS Windows XP. At this point, I live it terror of doing that again (because it takes down hundreds of people when I do), so I pretty much *have* to stay out of MS Outlook. Gotta love the irony of that.


Crashing everyone else on the server is only one reason of course: I live on a Linux Desktop, and while MS Outlook runs fine under Codeweavers Crossover product, I really prefer to stay in Linux native applications when I can.  The one and only time I have to be in Evolution for is for calendaring. I can do email just fine with Thunderbird. The new 1.5 beta implemented inline spell checking, which was the big missing feature for me. I'm spell checker dependent. All the Evolution crashes are easier to live with since I only have to be in that application long enough to send and receive meetings. And, if need be, I can always use the Web client to MS Outlook for basic calendaring.


Calendaring is a lot like the big open standards based to-do around OpenDoc right now (referenced in previous weblog entries). If you have implemented a non-standards ready calendaring solution, then you are stuck with the consequences of that. For a long long time. These things are not easy to get pried out of your infrastructure once they take hold, unless they are fully standards compliant and interoperable. That is the beauty of OpenDoc.


We'll be going to MS Exchange 2003 soon, and when that happens, the web interface gets better. Who knows... maybe Evolution will work better there too.  I might even risk firing up MS Outlook again then! But not during business hours, just in case.

There is another story buried in all the Google/ Sun news I have yet to see written.


We have learned now that there are no immediate plans for an AJAX / StarOffice technology based, web enabled Office. This one, No Office suite from us : Google is from "The Register" , and the rather 'raw' picture included probably is pretty indicative of how some people are feeling about the idea that this is not yet to be.


The story within the story is that there are so very many people that were hoping and praying that Google would do an a web enabled office suite.  You know: A real web app: the kind that works from multiple browsers and multiple platforms. Like all the Google web apps already do.


If I was sitting in my office, reading email after email from other folks at BMC about how they really wanted someone else to form a group to do R&D Support, to exactly duplicate and replace what my team does, I would have to be doing some pretty serious soul searching about what my team did to get my customers so utterly riled up. I hope to never see such emails!


I wonder how MS feels about issues like OpenDoc and MS Office for Linux after seeing such hope, energy, and angst portrayed around the idea that people were hoping against hope that Google / Sun might “save them”. It is clear who they were hoping to be "saved" from.

Quick thoughts about the Sun Google announcement, a new Linux NFS client discovery, and other new Linux activities


This was one busy week. Between all the quarter close activities here at the office, the busy news week, and a huge amount of work testing various NFS clients against a new Apple OS.X file server, there were hardly two minutes to rub together to write this!


The week started with a great deal of excitement about the Sun / Google announcement. It was interesting for me, after looking at all the AJAX news from last week, to watch how this seemed to unfold. It started with “Google is finally going to do it! They are going to take over the desktop!” or things that boiled down to thoughts along those lines. The actual announcement brought deep bewilderment to most: “Huh? An unspecified server deal, an OS co-development thing, and a Java agreement? Where's the story?”. And finally, the more serious analysts settling in to realize that this announcement is only the start... or maybe only the potential start... you never really know how company cultures will mesh.


The real thing that was missing for me, as it was for many people was “AJAX StarOffice”. So many missed that non-announcement that you'd have to use Google to find all the links. It would be faster and more up-to-date than linking them here. There might be another point in there someplace too. I would imagine Google search was lit up like a holiday tree with people looking for that bit of news. And another, which is that search is easier and more useful than static pointers: That is one of the cool things about Spotlight on OS.X 10.4 to be sure. But I digress.


I am sitting here at my house typing this on my iBook, using NeoOffice 1.1 as my word-processor, and thinking how very cool it would be to be able to store this stuff “Out there” like Gmail, searchable like Gmail, spell-checkable, in OpenDoc format, where I could get at it from work or from home, and then pop it to the weblog when it was done. The thin client dream that was not announced this week. Oh well, at least I have it in OpenDoc format already.


To be fair: Google has hardly had time to write/port such a thing as “AJAX StarOffice”. They may be pretty good at AJAX, world class even, but taking the millions of lines of StarOffice and making them presentable as a thin client via AJAX... I would think that might take a little while anyway.


Linux NFS client not full NFS V3 standards compliant!


We learned an interesting thing this week. We had a short test window in which we could try an experiment, working with R&D build engineers to determine some new things about possible file server configurations. We moved a test copy of one of the new R&D projects we were working on supporting to an Apple Xserve running OS.X 10.4.2. The CIFS side of the server was then benchmarked at about twice as fast as the Alpha-chipped ES40 running Tru64 that used to be our TruCluster, which was and is pretty fast itself. That was not a surprise. Tru64 uses ASU to create it's CIFS protocol layer, and OS.X uses Samba. Our theory going in was that Samba would be faster, not even counting all the differences between the 2 hardware platforms. Both servers can keep a Gig-E wire fully occupied.


What was a surprise was that we found a range of Linux based NFS clients that would not work against it. What was worse was that once we dug into the problem, ran some traces and some test programs the problem turned out to be Linux behaving badly.


OS.X is a 64 bit OS, based in part on BSD. It's NFS server is 64 bit, and NFS Version 3 has built in support for 64 bit servers and clients. OS.X in 10.4.0 enabled some new 64 bit features in the NFS server code, in agreement with the NFS V3 standard.


And to the dismay of a Linux maven such as myself, some Linux NFS clients break on it. It is a very esoteric little problem. My understanding of it after talking to my team about it all through the testing this last week is that the NFS Version 3 standard describes a process where the client can cache directory information locally, in order to speed things up on the network. To keep track of this the NFS server hands out “cookies”, with each cookie being essentially a pointer of sorts to a file on the server. The “cookies” are numbered, and OS.X numbers them very very big. 64 bit big. And the NFS protocol says that is an OK thing to do. But the 2.6 kernel, prior to 2.6.13, has an NFS client that can only deal with 32 bit “cookies”. Even though the 2.6 kernel also is supposed to support NFS Version 3.


Apple, like SGI who had this same issue in Irix before them, will add a new NFS export option "-32bitclients" (available starting in 10.4.3) to deal with this problem. That is goodness, but it would be better if Linux did the right, standard compliant thing.


Over at we found a developer talking about the whole thing: his mission in life right now it to make Linux fully NFS client standards compliant, and the new Fedora 2.6.13 kernel released this week tested out just fine. So the good news is (and I have seen this over and over) “Even when Linux is not standards compliant now, it soon will be”. Also note that it looks like they are doing a great deal of work on NFS V4 for Linux, which is good too, but it will be a while before we could run that in our heterogeneous R&D world.


We worked around the 64 bit NFS client issue by using NFS Version 2 overrides on the NIS export, which fixed that problem, but caused the clients, especially those on the WAN, to slow down to an unacceptable level. If it isn't one thing, it's three others of course. Just to keep all our testing spicy, one of the test systems also had memory errors to help us.

We are headed back to using the Tru64 file server, as our time for testing this is at an end. R&D needs to get this product build environment nailed down and production ready. And the Tru64 file server has worked extremely well for 4.5 years, and is working well again, now that it is not in cluster mode.


Other Linux stuff


The new motherboard was ordered this week, and we hope to have it in and installed in the test Linux file server by the 15th, and our troubled 2.6.5-kerneled NFS server upgraded to 2.6.12 or so shortly after that.


Knoppix 4.02 landed on my desk today, and I'll start working with that next week to see how it will work in my Linuxworld lab setup. The current version we use for the lab is 3.6, and while it works very well, we like to stay current for the lab.  I did a quick boot of the DVD before I left work, just to be sure the disk was OK. Tons of new software to poke around on that: I am used to the CD version of Knoppix, not the DVD. Amazing what you can cram in 4 GB.


OpenSUSE 10.0 is being downloaded as I type, and I'll get that onto the soon-to-be-former SUSE 9.3 laptop next week as well.  I tried a quick test of a borrowed iPod Nano on the 9.3 system, and unlike my full size iPod, it did not appear right away in Konqeror or GTKPod. But the Nano was not initialized yet either, so maybe that was the issue.

Mandriva released a new version this last week, and Ubantu has a new RC out. Time to find some more test hardware.


Mozilla Firefox released 1.5 Beta 2 which it running quite nicely already on the iBook, so it will need to be spun down to Linux and MS Windows test places next week.

A busy busy week coming up, I can see already.


A few items related to the news from last week, plus an update on the Linux file server.


Two items related to last Fridays post showed up this morning, both on ZDNet:



Lest you think I get all my news from ZDNet, here is an interesting one from Vista's licensing speeds NSW govt move to Linux desktops


The latter is not a massive move of zillions of desktops away from MS Windows or anything. The point of all this is that in the future, in the production world, one will be less and less able to determine what the client side platform is, and the good news is that if it is done right, such a thing will not matter.


Here on my team we pay very close attention to standards such as these. Our main R&D Support web server for example runs MediaWIKI so that we do not have to care what client OS or browser our customer is using. With over 600 BMC products across so many different platforms, they won’t be using the same platform all the time even inside of one development team! Because of the magic of open standards, We can deliver a high grade, collaborative web site no matter if they are sitting at a Solaris system, an AIX system, an MS Windows system, Linux... you name it. As long as the browser that is installed there supports open standards we are good to go.


Linux File server update


At the end of this week I had hoped to be able to report how our move from the 2.6.5 kernel based file servers, discussed in “When Linux Breaks” was coming along,  after doing an update-in-place to Fedora Core 4 and the 2.6.12 kernel. But it will be a while, and now it is a bit more complicated.

The idea of the low cost file servers was to use commodity based parts, and to shelve spares against the day that we could not easily get the parts anymore. But to get the testing of the upgrade in place we needed done,we assembled the spare parts into a small working system. And then we found out something ahead of time that is good to know: the shelfed CPU we have had a bad fan on it: that is to say the fan had an infant death, and died less than a month after being powered up. It took the spare CPU with it in a very crispy way. And we can not get another Athelon XP 1900+ from our supplier.


We could look around eBay and other places, and maybe scare one up, but we are still faced with something we knew would happen sooner or latter: Commodity based gear has passed this generation by.


We are now looking at the current generation specifications: 64 bit, dual core, current speeds and feeds, and seeing how this changes our assumptions. One thing we had decided early on in the original design was to use only dual processors for these servers. This was not because we needed the speed: an AMD 1900+ can keep a single Gig-E wire fully occupied as a file server, and still have cycles to burn. The idea was that if we had a runaway process, we’d still have a way in to the server to stop the runaway, and maintain a higher customer facing service level. Even on the tier II NAS applications we use these on, it would not even take one outage avoided to pay for the 2nd processor. And part of this exercise was to learn what we needed to know in order to someday possible make these tier I NAS servers.


But now we are wondering if dual core meets the same need as dual processor, and are kicking that around. This will in turn inform our motherboard choice. The goal at the end will be to have a new generation of hardware on the shelve, and a procedure in place to upgrade the older gear to the new standard when the time comes.  We’ll use the 2.6.5 kernel issue and it’s test server to verify all of it. We normally don’t like multivariate problems like this though, so we’ll have to be sure we can control all the factors, or else find a way to break this down into several steps.


In any case, that won’t be finished this week.

Filter Blog

By date:
By tag: