Skip navigation
Share This:
Getting back a great deal of Ron's time, as well as empowering the end user with VMLMAT


I am going to go out on a limb and guess that if anyone in your shop is using Linux, they started using it on a PC of some kind. Probably an X86 box like a laptop or desktop. If Linux was studied in school for something like a compiler of OS architecture course, it was probably taught on small, desktop class gear. Point being, they are used to having control of their system.


In a small development group there is probably a re-purposed PC or small rack mounted server or a VMware Virtual Machine, and everyone accesses the Linux server via X or SSH from the Linux laptop or desktop in their office. Someone wants to reboot, they send out an email, IM, twitter, or just shout up and down the hall that the server is going down.


The traditional MF shop is the opposite of this. It only makes sense: the MF is too expensive to not have it be centrally managed. I often think that ITIL was developed by people that had MF background because a large number of the disciplines it discussed are things we had to do in the MF world long before they had formal names. Change Control for example: You make a change to the MF, you have the potential to blow up a whole bunch of people or a whole lot of batch work, all at one time. This tends to make people grumpy.


As one who has lived in both worlds, I have seen the culture shock of someone coming from the small Linux platform to the MF. Something like: "What do you mean I have to call the data center to get my VM recycled. Are you nuts? Just get me a 1U server and let me control it. I don't need these people in my way!" It is just not intuitive that they should not have control of their own Linux, unless it is the production web / app server or something. There is a sense of ownership: That is my Linux server.


This is compounded of course by the fact that with the general Hossness (TM) of the MF and the best OS on the planet, z/VM, there can be hundreds of Linux VM's. Thousands even. Now we get a real clash of cultures (the folks who want to own their compute resources vs. the central data center), and a real stress on time and resources (all the behind the scenes work it takes to keep the shop running and up to date vs. being responsive to the end user). If one runs this Linux shop the way that the MF has done it in the past, then a system programmer makes all the changes to the guest operating systems, and a system operator brings up and shuts down the same Guest OS's and the "owner" just uses it for whatever they need to do. And oddly, no one is happy.


  • The Sysprog or Sysprog team is/are stress cadets because      someone forgot to add more hours to the day to do all the work.

  • The Operators are really really tired of all the reboot phone      calls and emails and equally unhappy when they get a complaint that      the reboot did not happen in five minutes, even though they were      running backups over on MVS and mounting a tape, retrieving an      archive from the vault, or something similar at the time.

  • The end user is not happy because this is not nearly as good      as if they just had their own computer. They could install what they      wanted when they wanted and reboot all day long and no one would say      anything about it.


Part of the problem here is that, for the most part and to the end user, Linux is Linux regardless of the platform it is running on. If it does not look different, why must their behavior towards it be different.

Why Indeed?


VMLMAT solves this culture clash by returning control of the individual Linux VM's to the end user that "owns" them. It is not the exact same thing as having a physical big red button, or the server tucked under the desk, but via a standards compliant, any browser should work, web page they can shutdown, restart, or rebuild their Linux to any version of Linux in the repository. This is something like Vmware's VI Client, except that it adds provisioning to the mix, and where Vmware has snapshots, VMLMAT has archives. Not the same thing, though they can function in the same role more or less. Now the Operators are focused on the things that need their physical presence, the sysprogs are working on more technical things, such as putting the latest version of Linux into the archive so that all can benefit from it.


Install once, run many (tm).


And of course, the reboots are happening right when they are requested. Everyone is much happier


VMLMAT takes the paradigm of real machine ownership a bit further: In the real world, one person may have several Linux machines, or a group or people working together might have just one... or a group of people have a group of machines. In database-speak, it is a one to many, many to one, or many to many relationship. VMLMAT implements this so that there can be individual machine ownership, or group machine ownership, except that the 'machine(s)' is/are really Linux Virtual Machine(s).


The time saving are real too: Ron noted in his "Beyond Linux Cloning..." post that VMLMAT returned 30 hours a week to his time. Time that he used to spend working on tickets for the users to make various changes to their Linux VM's to match their current requirements he got back, plus now the end user was not waiting on him to have time to get to their tickets either. Everyone was more productive. A huge win-win.


Our savings may be a bit overstated: We are an R&D environment, and we make changes all the time. We have test versions and test versions and test versions. We need something at base level, another with a particular set of patches installed, another with a different set of patches, another totally bleeding edge current, plus Alphas and Betas... Still, I think that the savings are there for everyone.

Share This:
Fixed Block Architecture, Count Key Data, Lions, Tigers, and Bears


My days ... years really... as a mainframer covered a period of time where IBM did something very technically interesting (for a V/geek anyway) where mainframe disks are concerned. Back in the 1960's IBM designed the disk data architecture called Count Key Data (CKD) and it is a very different beastie than the Fixed Block Architecture (FBA) we are all used to from UNIX, Linux, and MS Windows disk formats. Follow the links on the terms for a deeper dive.


As the second link points out, FBA is a term that is hardly even used anymore since it is so common.


Modern mainframe disks from IBM, STK, and others are, as far as I have seen, all based off concepts introduced in STK's Iceburg project. This was the first place I came across them in any case. Among other things, what the 'berg did was to stuff a cabinet full of FBA SCSI disks, and then put a controller in front of them that emulated CKD to the mainframe. An early version of storage virtualization. Why go to all the trouble?


IBM had introduced real FBA devices for the mainframe much earlier: devices like the 3310 and the 3370. They were often hated and abused by the system programming community that was used to CKD. The reason for the dislike was mostly the granularity of addressing all the blocks on the disk. Despite this dislike (more on that in a bit) I was working in an IBM internal data center at the time and I was told by a hardware person that FBA was the future whether the mainframe folks liked it or not. They were partly right.


VM on the mainframe was into storage virtualization long before storage virtualization was cool. VM has what are called 'minidisks'. A real CKD device such as a 3350, 3380, or 3390 (in my time: there were other models) could be subdivided into many smaller virtual disks. This is not the same thing as disk slices either: nothing is written to a partition table on the disk, and the limit to the number of mini-disks was equal to the number of cylinders that the device had. A 3390 model 1 had 1113 cylinders, and each cylinder had 849,960 Bytes. So VM could create 1112 mini-disks. The 3390 model 54 (which is actually not real hardware, but was something that later disk products emulated on top of FBA SCSI disks) has 65520 cylinders.


To create a mini-disk meant going into the VM directory (the place that defines all the attributes for all the virtual machines that will be running on that computer) and entering the start and end cylinder of each mini-disk. You had to be sure that your new mini-disk did not overlay any other mini-disks. When one is working with numbers like 1113, the math is pretty easy. Minidisk 1 starts at cylinder 2 and ends at cylinder 10. Minidisk 2 starts at cylinder 11 and ends... where-ever. Point is, do not overlap them!


Enter FBA. The 3370-A2/B2 did not have cylinders, it had blocks. 712,752 blocks per disk. The data entry in the directory became very persnickity.


Here is a nifty table with all this kinds of data to continue that deeper dive.


The point of all that is this: IBM responded to the customer and did not put out any more FBA disk-stuffs for the mainframe. FBA was the future, but the customers (primarily, I was told, the MVS community) wanted CKD. This means in part that IBM was on the wrong side of history when it comes to commoditization of disk storage, even if they were doing the right thing by being responsive to the customer. There are a lot fewer CKD disks sold in the world than FBA, and in fact right now I am not aware of any real CKD. CKD looking disks are 'created' by smart storage controllers, essentially virtualized by microcode out of FBA disk arrays. The STK Iceburg led the way on that, and changed the way MF storage has been designed ever since. That is one of the reasons that there was never anything past the 3390 model in the IBM storage line of real CKD devices. Everything since then: the Ramacs, Sharks, and DS lines all use smart storage controllers that create "virtual" CKD devices out of real FBA ones. VM and MVS don't know they are not talking to 3390's for the most part.


The fact that the disk MF vendors have to emulate the old CKD architecture does have an effect on price. MF storage is far less expensive per Terabyte now than it was back then. It is more expensive than most of the straight FBA / SAN / NAS type solutions available today.



These days you can hook the mainframe to SAN disks, which are of course FBA. Last time I checked though, z/OS (the current name for MVS) could not use them at all, and while VM can see them, it can not fully utilize them. Linux guests of the MF can, even to the place of being able to boot off them, and that takes one to a funny place in mainframe-land. If one uses SAN disks of the MF, probably to save money, then they are also not getting full advantage of the mainframes monster I/O subsystem. In one of the oddities that is MF, even though it still uses arcane formats like ECKD (and I imagine I'll get some hate mail for saying ECKD is arcane) there is no getting around the fact that with 256 I/O channels,  multipathed devices, etc, that the MF is still the world champ for doing I/O. To the MF, doing I/O down one strand of fiber feels to it like drinking a real ice cream malt through a plastic coffee stirrer.

So: Sure, one can do FCP / SAN disks but we did not, and so there was no money to be saved there for us. We needed a different way to leverage the economies of FBA. This was something VMLMAT was created to do.

NAS and Archive


I have spend many many posts here talking about our various tiers of storage, and how we have built them out of commodity hardware. Most recently I have been talking about how we replaced the most mission critical NAS server in the shop that was a TruCluster with a CentOS cluster. This has had huge effect on our cost-per-Terabyte. Depending on how HA we need it to be, we are looking at anywhere from 1000 to 3000 USD per Terabyte now.

None of that is mainframe attached of course. No Escon or Ficon or even an external Fiber Channel connection (there is an internal-to-the-NAS-cluster FC SAN). To access this low cost storage requires a TCP/IP based protocol: NFS, ISCSI or CIFS. No problem for UNIX, Linux, or MS Windows based gear, and these days, no problem for the mainframe either... as long as you are talking about a MF with Ethernet connections, and most MF's these days have the "OSA" installed. The Open Systems Adapter sits where a channel adapter used to, and provides a number of industry standard Ethernet connections so that the MF is no longer isolated from the "Network is the Computer" world: Has not been for years actually, but the OSA has been a far better solution than what came before it, like the 3745 communications controller with an Ethernet adapter in it and a few other external, channel attached Ethernet (or FDDI or Token Ring...) communications adapters.


Now put Linux on the Mainframe. Native TCP/IP needs are met, and both Linux and VM understand the that protocol stack. NFS is there, NFS can be pretty fast, and it is inexpensive these days to use it.


Virtualization can lead pretty easily to server sprawl, and in some cases, like ours, there is a very strong business need to keep around all sorts of versions of Linux. It is not just the multiplicity of the Linux versions either, although there is that to consider. Here are some scenarios where there need to be a number of versions of Linux around on the Mainframe:


  • Test copies: After Linux is installed, someone comes along and configures it to meet a special need. Installed more applications, configures it all to work, and then wants to save that off as a template so that others can do destructive testing against the same environment.

  • Multi-Tier application roll out: One group writes the code, another Beta tests it, another QA's it, another stages it for production and another *is* production.

  • Disaster Recovery and Business continuance: A running production environment needs to be replicated to another location.


It *easily* can get more complicated than that. It is no effort at all to end up with 100 running Linux Virtual Machines and have three and four times that many non-running copies staged out on the disks in case they are needed. The Mainframe disks. The very expensive Mainframe Disks.

This was where Ron's vision of VMLMAT started in part. It was not originally just a cloning tool, but an archiving tool. Once he had the ability to clone a VM to a new VM, he had what he needed to create archives. The only bad thing was, even tarred and gzipped (tgz), it would still be on the expensive mainframe disks.


Ron had been involved from the very early days with our Linux based NAS servers, building several of them. He knew they were inexpensive and very fast, able to run NFS at near Ethernet wire speed. He wanted to be able to leverage them to store his tgz's from the mainframe, so he added that feature to VMLMAT.


With the mainframe on one end, and the speedy NAS server on the other, it was a matter of less than 10 minutes to recall an archive stored out on NAS, unpack it onto a target VM, customize its identity, and boot it. It became cheap to keep multiple copies of various archives. It became easy to take the storage tree and mirror or otherwise rsync it to other, different NAS anywhere in the network. It also was fairly inexpensive to keep off site tape archives of the MF archive tgz's. Nothing more special than just being sure the archive directory is being picked up by your backup systems of choice: To the backup software the tgz's are just large files, and they do not care that they came from the MF at all.


It is such a simple idea that it almost seems obvious in retrospect, but oddly it was not. When one works on the MF, there is a reticence to leverage non-MF gear sometimes. It just doesn't feel as safe.


There is also nothing that says that this has to be NFS. That is what we used, but VMLMAT is Open Source. Adding a different protocol, say FTP, to the archiving function would be trivial.


The ROI was immediate: All the MF storage we had been using to keep all the various versions, flavors, and configurations was returned for other projects: We avoided a MF disk upgrade because of it. Only the running Linux VM's are stored on the MF disks. If there is a downside it is that by reducing the cost of storing the archive, there is a tendency to now keep *everything*. Kind of like server sprawl, the cost of storage makes the cost of maintaining and cleaning the archives kind of expensive.


This is not a huge issue though: If you are getting that big then maybe you are also looking at HSM and data de-duplication as part of your data center plan, and VMLMAT's way of storing things plays right into that. Archives not recently referenced can be moved out to tape and deleted, and only one or three or whatever you policy it copies of them stored.

Best of Both Worlds


With VMLMAT you now have the best of both worlds: Your running, important MF Linux images are getting all the benefits of being on the mainframe, such as the bodacious I/O subsystem, and your inactive archives are stored at extremely low cost and are quickly accessible.

Share This:
VMLMAT ( comes in handy for something it was never originally intended for

I assume any reader of a technical blog has come across the "Law of Unintended Consequences". A decision, or path that leads to unexpected places. It usually has negative connotations, as in


"We (the generic we) decided not to spend any money on a new firewall, and with our savings we fought off a series of virus and malware incursions that cost us 100 times what the new firewall would have"




"We (still the generic we) designed the car to be light weight so it would get good fuel economy, and with the money we saved by not using higher strength materials we paid for all the lawsuits we were served with when it turned out the cars fold up like lawn chairs when hit by a Vespa.".


There are lessor and greater examples of the law than this, and I totally made those two up (although I am willing to bet my first example has happened someplace to someone). The law is well known though: It has a Wikipedia entry even, and as noted there, when there is an upside to the law, it is called a serendipity or a windfall. VMLMAT provided us with a windfall recently.

Rote Work


Computers are supposed to help us out with repetitive tasks. That is what they are good at, and we... at least I.. am not.


We had a situation not that long ago where we were re-doing some internal TCP/IP addresses, and all the Linux guest on the mainframe needed to have new IP addresses and new subnets. We were going to have to go manually through over 100 VM guests and change their IP settings.


The chances for error were high, and boredom even higher. Ron and I talked about it, and a little light went on for us. VMLMAT could be made to do this in very short order. Not only was it Open Source, it was *our* Open Source. VMLMAT had been written to be easy to extend. Ron thought he could add the feature in a fraction of what it would take to re-IP all the VM's manually.


The secret sauce was in the module Ron had already written that preserves  the TCP/IP identity of each Virtual Machine, regardless of which actual version of Linux was running at the time. VMLMAT had allowed us to treat VM's Virtual machines more like they were group or personally owned assets. Once we had set up the VM in the directory, VMLMAT updated to know whose VM this was, then we were pretty much done. The end user, or group of people could go into the web page and make the virtual machine into any version of Linux in our archive. No matter what they did, the identity code would chain through all the right places and set up the new Linux VM as having the same IP address, Subnet, Default Route, and DNS settings as it did before it was changed.


Since VMLMAT could do that, why couldn't we slightly change it so that it could be handed a list of VM names, IP addresses, and Subnets, and have it chain through *all* the guests, and reset them to the new IP? This module already knows all the different places the information is kept for each distro, so all it had to do was detect the distro, change the IP to the *new* one, and then run on to the next VM. VMLMAT could do in minutes what would take us days to do by hand.


And so it came to pass that we could schedule one short outage, pull the trigger on the re-IP mod, and be done. No mistakes. No long outages. R&D went home Friday night and their VM's had one IP address, came back Monday and they had another, and never knew anything had changed.

VMLMAT already had the habit of returning over 80% of Ron's time versus pre-VMLMAT days.


This was a bonus.


UPDATE: Ron has now posted an in depth look at the re-IP module over in his blog:  Open for Mainframe. Have a look!

Share This:
Replacing OpenSUSE 11 GA with a Beta of Ubuntu

A while back I replaced Mint 4 on my main production desktop system (A Dell 745) with OpenSUSE 11. Since then I have been loading up every update that OpenSUSE has released on a nearly daily basis. The good news is that in almost every way, OpenSUSE 11 is a terrific release, and light years ahead of where it was when I first started messing around with SUSE back in the release 5 days.


Everything is better: YAST. multihead graphics support. updating software. I did not leave OpenSUSE because I did not like it.


I left it because with its Gnome 2.22 desktop it was running by definition Evolution 2.22, and that was becoming a real problem. Evolution ultimately never turned out to be as stable on OpenSUSE 11 / Evo 2.22 as it was on Mint 4 with Evo 2.12. I stuck with it so that I could keep feeding the bug reports to Evolutions development team, and that in fact was why I decided to move.


Every single bug I had reported had turned out to be a duplicate of an already repaired bug, and most of the repairs were in Gnome 2.24 / Evolution 2.24. I was wasting my time and the Gnome teams time, so I quit reporting it every time Evolution crashed. But it did crash, all the time. A good week was a week of seven days of runtime before a crash, and a bad day was three or four times a day.


I get my email and calendars off an MS Exchange 2003 server. This stuff has to work for me!


At the same time that all this was going on I was watching the progress of the Evolution MAPI service provider.  They had hoped to make the 2.24 release, but unsurprisingly they had to move to 2.26 of Gnome instead: Even with the documentation of the MAPI and related protocols available due to the EU's Microsoft Anti-trust actions, it was / is a pile of work to unwind that and make it work with Evolution. MS has been continually updating MAPI for years with each new release of Outlook and MS Exchange, and it probably bears small resemblance at this point to the old Open Protocol Simple MAPI that MS published many years ago.


I had been hoping that MAPI would make 2.24 for one very simple reason: While I am on an MS Exchange 2003 server *now*, the minute the IT folks decide to upgrade to MS Exchange 2007, it is all over for the Evolution Connector. Connector relies on the fact the MS used a version of the WebDAV protocol to create the web interface to MS Exchange 2000 and 2003. MS, for whatever reason, dropped WebDAV for the web interface of MS Exchange 2007.

With MS Exchange 2007 in place, and with no native MAPI connector in Evolution, I would have to get to email via either Codeweavers running MS Outlook, the new Web interface, or possible IMAP if it is enabled, although that would not give me access to my calendar or contacts. In fact, if the EU had not done what they did, with MS Exchange 2007, I would have no chance of a native MS Exchange client ... even one that crashes.


So: OpenSUSE version of Evolution crashing. OpenSUSE 11.1 not out till December. MAPI not out till Gnome 2.26 at the earliest, but I am still on MS Exchange 2003 for the moment. Looking through the release notes for Ubuntu 8.10 beta I saw they were using Gnome 2.24, which meant Evolution 2.24, and all my crashes are supposed to be fixed there. May be new ones, but at least I'd be reporting real problems!

My history of Ubuntu installs made me feel that the chances of the Beta being stable were pretty good, so I decided to go for it.

Ubuntu 8.10 Install and Evolution 2.24 Upgrade


The 8.10 install was the now-normal Ubuntu install, and still has the graphical time zone chooser that I dislike. The disk partition stuff is much nicer looking, and worked well on manual to let me set up the disks the way I wanted. I keep '/' separate from '/home' so it was easy to re-format '/' and have OpenSUSE be totally gone.


After a very fast install, and the usual updates and re-adding packages I use, like 'hfsplus' and so forth, Ubuntu booted right up. I do mean right up. Fast! The OpenSUSE boot was not slow, but this one just flew.


Next, I moved .evolution to .evolution.suse11, brought up Evolution and redefined my WebDAV access to the MS Exchange server. I brought that down, then copied my filters and folders from the .evolution.suse11 back over to the fresh new .evolution, and brought Evolution back up.


Next I clicked on each folder I had just imported so that all it's meta would be re-created: Apparently the new Evolution 2.24 uses SQlite for folders metadata now. This might explain something, at least in part: The new Evolution 2.24 is fast. Way fast. Unbelievably fast. This is the most dramatic improvement in performance I have ever seen in any upgrade of Evolution, going *way* back to the early days.


One week of being up on Ubuntu 8.10 beta as my main, most production like system: No crashes of any kind. No OS, no Evolution. Nothing. Just clean and green.


FWIW: I still have OpenSUSE 11 on my IBM T41. Its too nifty not to have around someplace.

Its Even Better Than That Though


I would have been happy just having Evolution stable. Add in how fast it is, and I am really happy. But wait, there is *more*

The new hddtemp / Sensors Gnome toolbar applet is cool. For one thing, the nVidia GPU reports its temperature there now. After frying one of these, I like this a lot. Also I can edit the disk labels (which defaults to the manufacturers mode number now).


Getting the dual screen setup going required a little work, but it wasn't bad. After telling the restricted hardware driver I wanted to use it's recommended hardware drivers, it downloaded and installed them just fine. Going to 'system/administration' I ran the nVidia X server set up, and had my dual screens going in no time... but it would not save the config back to /etc/X11/xorg.conf.


I exited the setup, popped up a terminal, and ran 'sudo /usr/bin/nvidia-settings', and now it would save to xorg.conf, no problem.

OpenOffice is / was 2.4.1 on the Beta disk, and while it has been updated, it is still 2.4.1 rather than 3.0. Hopefully this will change soon. I have been running 3.0 on other systems and it is a very nice upgrade (and a whole different post...). Main thing is that the MS Office document compatibility continues to improve, and that is, next to having Evolution working, key to being a Linux desktop user in the MS Windows world.

Share This:
Introducing a new Open Source tool from BMC, available at Sourceforge, for managing Linux guests under VM on the mainframe.


If you have been following this blog, you know that my background is the mainframe. I started as a VM system programmer, and VM is still near and dear to my heart. When MF Linux became a reality, it was, to me, a natural thing that it would be a guest OS on VM the same way VM has hosted MF operating systems since it was invented over four decades ago (and the research that went into creating it stretches back even further).


Linux on the MF is just a logical progression of all the things that came before it on the mainframe... things like UTS and AIX/370. It is also natural for Linux: The ultimate in multi-platform OS's.




Linux on the mainframe, like any other technology deployment of human kind, is not without considerations and issues. If you have worked with the X86 spiritual baby brother of VM, VMware, you might know what some of those issues for Linux on the mainframe are: Things like server sprawl, and the tendency for many end users to treat the resources as essentially infinite.


There is also a cultural issue. If you have programmers working on Linux, be it web apps or anything else, and they are less than four decades of age, they probably learned Linux on their Laptop / Desktop / small-server-in-the-cube-next-to-them (shades of "departmental computing") kind of thing. To them, for the most part, Linux is Linux, and it does not really matter where it is, and they most certainly do *not* want to learn anything about the MF in order to access their Linux there.


That means that they don't want to call the data center and have the operator autolog their Linux VM, they don't want to learn how to log into VM, IPL the Linux system, and then do a #CP SET RUN ON#CP DISC. No TN3270 stuff. No green screen. It is not the way of the GUI world, and very much not the way of the Web 2.0 world. CMS is only for us VM'ers it usually seems. I know my track record in teaching people how to use the mainframe who started out in computing on Linux, UNIX, or MS Windows is not good. It is not zero, but it is not the next generation of MF people either. The MF is just too different, and its attractions are often not obvious at first glance. Sure XEDIT is the best text editor *ever*, but it takes a while to come to appreciate it....

In general, Linux users are used to owning the resource, and being able to boot it whenever they want (during development anyway). There is a sort of security in owning the "Big Red Button" so that one is the master of their own computers destiny.


This all stands at odds with a great deal of the culture of the MF: The ultimate in data center glass houses. To solve the problems above, often all the Linux VM's are just autologged when the MF is IPL'ed , and they run whether they are needed or not. This would not be a problem (at least not nearly as much of one) if these were all CMS VM's, but Linux in a VM turns out to have a few design points that operate against the "Just IPL and let it run" way of working. The main one is memory management. Think of the way Linux allocates memory, which is more or less "use everything I can". What is not programs is in-memory cache. It is a great design, and it makes perfect sense if you are running natively on real hardware: Why let the extra memory go to waste? Why not use it to speed things up? The idea is not even original to Linux. UNIX before it had it as a central design precept. The idea was that disks are way slow, and so if there was spare memory laying about, use it to cache the I/O, and speed up the programs. Let the I/O happen when it could. This design point is still valid today, as disks are still extremely slow relative to RAM.


As a guest on the MF though, that means to the host VM, it looks like the guest memory is 100% busy all the time, and the way the VM likes to page out unused memory on guests so that only active memory is in core is violated. The solution is to keep virtual memory trimmed to just what the guest actually needs to do it's job... At least it was before VMLMAT.


We do R&D on MF Linux. in the pre-VMLMAT days, at any given time, using the above autologging method, we had over 100 Linux VM's running. VM was running out of real memory. VM would look around, find the least recently referenced pages, and page / swap them out to DASD. But Linux would then reference the page, and back in they would come. Paging / swapping is fine when what is being moved is rarely referenced, but it is called thrashing when it goes out and then comes right back in over and over. There are limits to what you can do to tune this, and we were at them.


Many of the VM's were idle in reality, but we in the support group had no way of knowing what was being actively used, what was up as reference, and what was up because it was autologged.


Sure, things like the Build systems need to be up all the time. That was just a handful of the total systems we are talking about here though. We needed a way to make it so that end users could, without knowing *anything* about VM, bring up and down their own Linux VM's.





Virtual Machine / Linux Management and Archiving Tool.


As system's programmers, we are of course not marketers. Our name for our tool is descriptive, not beautiful. The VM part tells you right away this has nothing to do with LPARS or MVS of DOS/VSE. This is a VM tool, and that only makes sense: where else but the best hypervisor on the planet can you manipulate the guests without them knowing what you are up to?


The Linux part lets one know we are not dealing with CMS here. The Management and Archiving part is descriptive of function. Thats just the way we roll. Since this is Open Source, maybe someone can contribute a snazzier name some day.


VMLMAT runs a standards compliant bit of HTML under an Apache web server: This is the way that the Linux users interact with the program. The system programmer has a few things to do on the install that do not relate to the Web interface, but the idea is that Linux users are used to doing stuff via the web browser. Moreover, we did not want to assume anything about where the MF Linux user was starting from. Could be AIX, Solaris, Linux, or MS Windows (perhaps with some sort of X loaded up on it). Given the platform diversity, standard HTML was a requirement even if we were not already a pretty standards driven group.


Now when we IPL VM, just the Build and Packaging Linux guests are autologged, and the end users can go to the web interface and IPL their Linux whenever they want. Or bring it down. It seems a simple thing, but that one feature saved us an MF upgrade. Only the Linuxii we need... that we are actually actively using... are up at any given time. 100+ Linux VM's up and running at the same time dropped to one fifth that number.


That is just the tip of the VMLMAT ice burg though. Here is another nifty feature: Disk space savings



MF disks are very expensive things. One of the primary criticisms of Linux on the MF is that Linux was normally run on commodity priced hardware, and now by running it on MF gear all the price advantage was lost. Many saw of course that there were advantages: I/O pathing and monster transaction capabilities, best in the business HA, and so forth: Perfect for the production Linux environment. Not so perfect for all the possible iterations of a development environment.


Since we in R&D Support do care and feeding of all sorts of Linuxii internally on the MF, all the way back to the very first bootable kernels, before RedHat or SUSE were making MF versions of their distros, up to the latest and greatest stuff, we had a real diversity issue. All those VM's were sitting around.


Everyone needed a separate VM for each version they were  working on, plus a set of their minus one versions of code, plus the betas and alphas for announced code: This was not server sprawl from the "Its all free" point of view i mentioned earlier, but it was expensive server sprawl nonetheless.


VMLMAT takes a different route to this. We do not store all the versions on the MF DASD at all. Everything is archived to inexpensive NAS. If you have been following "Adventures", I have been writing about that inexpensive NAS for a while now. Now you know one of the things it holds: Our MF Linux images.


VMLMAT can package up via TAR any VM, and store it off to the NAS. Even better, it can restore that archive to ANY OTHER Virtual Machine. VMLMAT unrolls the archive, and then personalizes the archive to match the VM it is being restored to.


We then leverage that in many ways:

  1. When a new release comes out, we install it for the first time and then archive it. Now everyone can use that new version without anyone in tech support ever getting involved.

  2. If applications need to be added, the base archive can be installed, updated with, say for instance, Oracle. Now it can be archived again, and anyone who needs that release of Linux with that release of Oracle can leverage the work.

  3. Business Continuance / Disaster Recovery: Now we can take the NAS archives and replicate them wherever and however we like, and get back all this work, and it is simple and easy.


Only the currently being used copy of Linux is up on the MF DASD. The rest is spinning far less expensively out on the NAS. Multiply by the number of Linux VM's and the number of Linux versions and the number of application setups and that is a bunch of DASD being saved.


With the Web interface to VMLMAT, the end user is now an empowered individual. They can bring up their VM, shut it down, change it, install stuff, archive their changes, share their changes with other teams, and leverage other teams work. Say they are running RH AS 5 with Orcale, and they want SUSE with MySQL for their next test.  They can archive the work, retrieve SUSE with MySQL from archive, and start testing. The whole backup and restore take less then 30 minutes in our shop. The new SUSE VM has the same name and same IP as it did before: VMLMAT took care of editing all the stuff in /etc so that the VM name never changes. Just the Linux version.


At no point did a system programmer get involved in that transaction: We have seen a workload that was frankly swamping Ron drop to the place where rather than him needing to work crazy hours to keep up, he puts in a few hours a week on MF Linux maintenance (like creating new archives of new releases of Linux when they come out) and then moves on to other things. Not only was the end user enabled but we got back most of an employee for other tasks.

There is even more, and I'll write about that in future posts, but for now I want to tell you how anyone can get VMLMAT if they want it. Did I mention that BMC is Open Sourcing it yet?

Sourceforge and BSD


VMLMAT is available to anyone who is interested at Sourceforge:


VMLMAT is licensed under BSD, one of the most open and permissive of open source licenses, and the one that we at BMC have chosen to use when we release Open Source projects. Our little site was just set up yesterday, and we are still knocking around learning how to use Sourceforge, so bear with us. We are loading up the documentation on the Wiki, and the tarball for the current 1.1.0 version is there. We'll be checking it all into SVN soon, but till then this is the way to get it.


VMLMAT is created entirely out of Open Source projects like Apache, PHP, and Samba, and the VM portions are the very VM standard REXX. No C or assembler was harmed in the creation of the tool. The  HTML is scanned and certified as being 100% open standards compliant. As we have it written, it leverages NFS to archive Linux images to NAS.


Ron did a slideshow style presentation to walk through some of the features of VMLMAT, and it is loaded to Sourceforge as well.


I'll be your host on the project, along with the BMC internal author of VMLMAT, Ron Michael.


Ron also has a blog at TalkBMC called "Open for Mainframe", and he has a bunch of posts in various stages of readiness for posting there about VMLMAT. We'll also start cross-posting with the blogs over at Sourceforge soon, so stay tuned for that.


In the meantime, I am jazzed. VMLMAT is a simple concept, and an amazing tool, and it has been saving us all sorts of time and money. I am thrilled to be able to share it with anyone else who is interested out there in two of my great geek-loves: VM and Linux. Further, we knew going in that VMLMAT was created to meet our real world requirements, but it also matches our R&D Support environment. Knowing that it might be Open Sourced, Ron created it so that it can be easily enhanced to add new features. For example, we chose to use Active Directory for a end user authentication (via Samba) rather than maintaining a separate user / password file or perhaps having it in LDAP. The code is modular so that anyone can come in an write their own module to match their internal needs, and hopefully they will contribute that back so the VMLMAT can grow to meet a broader set of real world, Linux on the mainframe management challenges.


As Rachel Maddow says: "One More Thing:" Please do not confuse VMLMAT with BMC's VM Cloning Tool from a number of years ago. It shares no design and no code with that tool.

Share This:
Helpful information for running a CentOS Cluster continued


As noted at the end of last post, todays post is more tasty documentation, straight off our internal R&D Support Wiki and as written by the Czar of NAS, Dan Goetzman, for running a CentOS cluster. Admittedly, this is the kind of post that is more useful from Google than as exciting reading. When you need to know this stuff, you need to know it though, and so i am posting it to help out whomever might come down the same path we have.


Next post I'll be talking about a new BMC Open Source initiative that I am intimately involved with: that one will be one of the most fun posts I have ever had the pleasure to write. In fact, I am ready to write it now, so lets get into the meat of this HOW-TO.


Take it away Dan:


HOWTO Shutdown or reboot a single node

The cluster software is started and stopped using the standard system startup scripts. So all that is required is to use the normal Linux system reboot or shutdown commands.

  • shutdown -h now - To shutdown a single node
Note: 2 out of 3 nodes must remain running to keep the cluster "quorate", or running.
  • reboot - To reboot a single node

HOWTO Remove a node from the cluster

  • Stop applications using cluster resources
  1. uvscan - Currently running only on rnd-fs03
  2. nfs - Actually runs on all cluster nodes but not controlled by rgmanager
  3. Samba - Controlled by rgmanager
  4. bbd - Controlled by rgmanager
  5. vsftpd - Actually runs on all cluster nodes but not controlled by rgmanager

Notes: Services controlled by rgmanager will be stopped when rgmanager is stopped. Non cluster applications, like DNS and NIS slaves, do not need to be stopped.

  • Stop cluster services in this order
  1. service rgmanager stop
  2. service gfs stop
  3. service clvmd stop
  4. service cman stop


  • Optional, disable services on reboot
  1. chkconfig uvscan off
  2. chkconfig nfs off
  3. chkconfig vsftpd off
  4. chkconfig rgmanager off
  5. chkconfig gfs off
  6. chkconfig clvmd off
  7. chkconfig cman off

Note: To add the node back into the cluster, run this procedure in reverse order.


HOWTO Troubleshoot NFS serving

Local tests on the server

  • rpcinfo -p - Verify portmapper is responding
  • showmount -e - Verify mountd is responding
  • rpcinfo -u rnd-clunfs nfs - Verify NFS daemon is reponding to UDP requests
  • rpcinfo -t rnd-clunfs nfs - Verify NFS daemon is responding to TCP request

Test from a NFS client

  • rpcinfo -p rnd-clunfs - Verify portmapper is responding
  • showmount -e rnd-clunfs - Verify mountd is responding
  • rpcinfo -u rnd-clunfs nfs - Verify NFS daemon is reponding to UDP requests
  • rpcinfo -t rnd-clunfs nfs - Verify NFS daemon is responding to TCP request

HOWTO Troubleshoot Samba CIFS serving

The following procedure is what I do to verify that Samba is available. It starts from the server, and works it's way back to testing on the client.

Local tests on the server

  • smbstatus - Verify normal Samba status.
  • cd /var/log/samba - Check for errors in the Samba event logs.

Remote tests from a client

  • ping rnd-fs - Verify TCP/IP connectivity to Samba
  • nbtstat -s rnd-fs - Verify if a simple NetBIOS operation will respond
  • net view \\rnd-fs - Verify if the shares can be browsed
  • net use * \\rnd-fs\${SHARE} * /\username - Verify that a share can be mapped
Note: Samba is a cluster service and only runs on a single node at a time.

HOWTO start/stop/admin Samba

Samba is a layered software application that emulates a CIFS server, and on the cluster it is configured as a cluster service.

Note: You must use the cluster commands to start and stop the Samba service,
      NOT the normal scripts in /etc/init.d.

Query the cluster services

  • clustat - To verify if the Samba service is running and on what node.

Start and Stop Samba

  • clusvcadm -d Samba - Stop Samba
  • clusvcadm -e Samba - Start Samba

Query commands for Samba

  • smbstatus - Show status

Adding shares and permissions

  • vi /etc/samba/ - Add/Modify/Remove a share

That is it for today. Next time, as noted above, Open Source at BMC.

Share This:

Continuing to look at some of the useful things one needs to know when going production with Linux. Applies to any other OS too in most ways, but examples are all from our Linux deployments, specifically our first year on our Linux based NAS.


Last post I talked about using a special version of 'fsck" to repair GFS based file systems. As I thought about that post I realized that I had some more general things I wanted to get into in this area. I also noted that i would talk more specifics about useful commands and related things we have learned along the way that you should know about *before* your Linux based cluster fails.


As I also alluded to in my last post, the first year on the Linux cluster has not been utterly pain free. For one thing, we had the fencing set up wrong so that when a node failed for any reason, it could not be "shot in the head" and recovered by the surviving nodes. This has now been fixed: I know this because last night a heartbeat failed, the node was fenced, and the service recovered on a surviving node. Then, the heartbeat returned and the cluster was whole again. We did nothing, and there was no customer facing outage. Here is Dan's exact verbiage:


I see that node #1 on the file serving cluster here in Houston rebooted this morning. That's the node that normally handles the NFS service by default priority. It looks like node #1 lost the heartbeat token to the other nodes. Probably due to the NIC driver or something. This is the same thing that happened a couple of weeks back on node #3.

This time, the cluster recovered with out my help. As it should! With the fence configuration fixed now, node #2 was able to fence (reset) node #1 via the Sun ELOM (IPMI over LAN)  and node #1 then rebooted and joined the cluster again. All is well!

The cluster resource manager moved NFS to node #2 to maintain that service. For now, I have left NFS on node #2 with the Samba service that normally defaults to node #2.

The cluster did it's thing, no service outage. Although I suspect NFS stalled for a few moments and then took off again... Life is Good!

We don't yet know why heartbeat is getting lost from time to time, but at least we now totally survive it when it happens. More on that in a second...

This takes me to the things I wanted to say about a few design choices we made in setting up the cluster, and I want to tie these back to another, different cluster we deployed with far less success 8 or so years ago as well as the TruCluster that the Linux cluster replaced.


Design point / choice number one: If you have read the previous series about out NAS cluster design, you might have followed a link to this picture. If not, and you do so now, you will see that we chose to implement three nodes: Sun X2200's in our case. Why?


Our TruCluster (may it rest in peace, and in this case, pieces) had magnificent uptime. It ran and ran without rarely a burp. However, the TruCLuster was two ES40 nodes. If we took one down to apply patches, we were left literally "standing on one foot": We were not HA any more. At least one time, the *other* node failed while we had one down for service, which meant we had a customer facing outage.


With the price of an ES40, a third node would have been a significant bit of money for the insurance. Our thinking at the time: This is the best cluster software on the planet (when it was viable, before TruCluster was led to the firing line) so what are the chances we'll take a hit on a surviving node when we have one one down for service.


As with all Disaster Recovery / Business Continuance math, that question is tricky, and the real answer is: "There is a 100% chance of the surviving node going down while the other node is offline... given enough time.". In the seven years that the TruCluster was in service, it happened at least once to us.


Commodity hardware and Linux change the spare-hardware-insurance math. The price of a third X2200 plus Linux is an order of magnitude less than another ES40 node would have been. More than an order. There is the issue of increased complexity though, and I'll come back to that in a bit. To led into the complexity issue I want to go back to the heartbeat design.


Most clusters use a dedicated bit of hardware for the heartbeat internode signaling. If you use only one interconnect though, you have a single point of failure. The CentOS cluster software does not require a private network segment for heartbeat, and in fact the default is to use the public network segment. That appears to be thought to be "Best Practice".


If the cluster is done right, then at least two high speed, modern, supported, monitorable network switches are in play, and each of the three nodes connects to *both*. The heartbeat signaling is small, low bandwidth traffic. With the port to port switching, high speed switch backplane, and second switch redundancy, the heartbeat should be fine. To do this right on private networks would mean adding two *more* high speed switches, plus two more NIC's to each server. At some point the cost and complexity are not returning much in the way of value, and may in fact be adding more points of failure to your cluster such that it starts failing when nothing is really even wrong!


OK: That is the theory, but as Dan's note indicates the theory is being challenged by the occasional loss of heartbeat. I hate it when that happens!

That seems like a good way to move into my point about the cluster we used to have that lowered our uptime. A lot. it was not a Linux cluster, but it was a vendor supported, vendor installed, vendor configured solution using some of the better clustering technology of the day that was not TruCluster.

The problem was that the application that ran on the cluster was not cluster aware, and we were never able to fully script it so that all the bits and pieces from the application would fail over in cases where there was a problem. The app, not knowing all this redundant stuff was out there was often confused as to which node it was running on, and failed at least once a month. We finally took the cluster apart, created two stand alone servers, and uptime went up to over a year.


There were echoes of this when we first built the Linux cluster: NFS nor Samba are really cluster aware, at least not yet. I think Samba will be soon. NFS, being stateless, does not really need to be as cluster aware as one might think. Since GFS is keeping file state, and all the underlying addressing mechanisms for the files the same across all the nodes, NFS can stop and restart anywhere.


You can see the results of this design in what happened in Dan's account of the failure. We are doing most of our cluster magic by using GFS as the file system so that all nodes could mount the same FS, yet not overwrite each other. The CentOS cluster software only has to worry about where a particular service is running, and moving them around. File state is not it job. We then set it up so that NFS runs on one node, Samba on another, and the third was insurance... That inexpensive insurance we could not afford on the TruCluster.


The takeaway from all this then: Clusters do not, in and of themselves make everything magically more HA. You have to start with the best of breed in cluster software, but you also have to know the cluster environment, and test it seven ways from yesterday to be sure that in failure mode it is actually doing what you think it should be doing. This ties back to something I said last post. To paraphrase: There is no substitute for knowing what you are doing. Linux is not magic. Clustering is not magic. All the magic comes from your people. Your business is only as good as your process: Process designed by people who do not know what they are doing will land you in a world of hurt.

Today's Linux Cluster Commands

Hoping down off my soapbox now, here is another bit of Cluster Wisdom (tm) as documented by our NAS Wizard, Dan Goetzman. First off, I want to back up and establish some common terms, which Dan provides here:


The "TruCluster Replacement" project is a evolution of our LCFS (Low Cost File Server) project using Linux clustering (CentOS) and the "Snapple" (SuN x2200 servers and APPLE XServe Raid (XSR) storage) hardware platform.

Main Features:


  • In addition to the features of the "Snapple" based LCFS platform...  
  • CentOS 5 cluster technology to provide failover services for NFS and Samba.  
  • GFS Cluster/SAN/Parallel filesystems for user data.  
  • CLVM to make the SAN storage available on all cluster nodes.  
  • Public network failover using Linux "bonding" driver.  

The cluster consists of;


  1. rnd-fs - Main cluster name (NOT in dns).  
  2. rnd-fs01 - Cluster node #1 (default node for NFS service).  
  3. rnd-fs02 - Cluster node #2 (default node for Samba service).  
  4. rnd-fs03 - Cluster node #3 (default backup and virus scanning service.  

Cluster Services;

  1. - NFS server service.  
  2. - Samba server service.  
  3. - Big Brother service.  


So, now that we have some common terms and server names, the commands in this and future posts will have context. Finally for today, some helpful cluster commands:



  • clustat - To view the normal cluster configuration.  
# clustat
Member Status: Quorate
Member Name ID Status
------ ---- ---- ------
rnd-fs01 1 Online, Local, rgmanager
rnd-fs02 2 Online, rgmanager
rnd-fs03 3 Online, rgmanager
Service Name Owner (Last) State
------- ---- ----- ------ -----
service:NFS rnd-fs01 started
service:Samba rnd-fs02 started



  • clusvcadm -r NFS -m rnd-fs03 - To relocate the NFS service to node #3.  



  • system-config-cluster - To configure the cluster.  


  • ip addr show - To display the where the cluster is serving a cluster IP resource  


That should do it for this time. Next time, shutting down and rebooting a single node, and removing a node from a cluster, plus some troubleshooting.

Share This:

Just because a hurricane hit us doesn't mean I can't write a blog post!



Last September we "stood up", for the very first time, our CentOS Linux based cluster to replace the aged and unsupported Tru64 TruCluster. It was not all that long ago in fact that I wrote the wrap-up article to that adventure, so I guess this is a postscript.



First off, the fact that I have changed roles has influenced several things around the file server: A new manager took over my team, and when the server had a problem she suddenly found out she had a Linux file server she was responsible for. It is documented seven ways from Sunday on the Wiki : Dan is amazing about things like that. The problem of course is that when everything is working, no one reads the doc. When it fails they don't have time. Dan works with me on my new team, but went back and fixed the file server for the old team a couple of times, and here is the nut of what this article is about. What I am about to say here is going to be true about any and every complicated bit of technology that people rely on every day: it will not be limited to just Linux.



You have to know how to use the technology.



The Linux NAS was never advertised as being as good as the TruCluster that proceeded it, but when it failed it took people that understood TruCluster / Tru64 / ADVFS to fix it. Same thing with any technology stack I have ever worked with.



Technology is only as good as the people and process that support it. See ITIL for details.



This is a truth that I think about all the time in my new role as a technologist. 10% of the work is designing the solution. The rest of it is training, communicating, and then going back and retraining some more (more than likely).



Along comes this hurricane named Ike, and it is huge: As big as the state of Texas from side to side. Houston's power grid crumbled before Ike. The Linux NAS server has a weak spot in the design: It will not run without electrons. I know, I know: We should have had wind power as a backup. Next time....



Upon the return of power, the Global File System that underlies the core design of the NAS marks many high I/O, high usage file systems as needing repair and they will not mount. The log says that the file system has been "withdrawn":


--------------------- GFS Begin ------------------------

  WARNING: GFS filesystems withdraw
     GFS: fsid=rnd-fs:p4_gfs.1: withdrawn:

  WARNING: GFS withdraw events
      [<ffffffff884c3c94>] :gfs:gfs_lm_withdraw+0xc4/0xd3:
     GFS: fsid=rnd-fs:p4_gfs.1: about to withdraw from the cluster:
     GFS: fsid=rnd-fs:p4_gfs.1: telling LM to withdraw:

  WARNING: GFS fatal events
     GFS: fsid=rnd-fs:p4_gfs.1: fatal: filesystem consistency error:

  ---------------------- GFS End -------------------------


This is system admin 101 stuff: FSCK and fix stuff, and you are back running... except that in the cluster and GFS the commands name is not FSCK. And you can not just FSCK: here then is what Dan wrote on our Wiki about how to recover from this:




HOWTO: Recover a GFS filesystem from a "withdraw" state


When a corrupt GFS filesystem structure is discovered by a node, that node will "withdraw' from the filesystem. That is, all I/O for the corrupted filesystem will be blocked on that node to prevent further filesystem corruption. Note, other nodes may still have access to the filesystem as they have not discovered the corruption.


  • halt/reboot - Use a hardware halt on the node that is in the "withdraw" state and then reboot that node.  


Note: A simple reboot command should work, but on our version of the cluster it seems to hang in the GFS umount stage on the withdrawn filesystem. So a hard reboot of the node seems to be required at this time.


  • umount ${MOUNT_POINT} - Un-mount the filesystem on ALL NODES!  
  • gfs_fsck ${BLOCK_DEVICE} - To run a full fsck. Run on one node only!  
  • mount ${MOUNT_POINT} - On all nodes to restore service.  


Note: nfsd will hang on the withdrawn filesystem. You may
need to relocate the NFS service to a surviving node first!




Since being in production, Dan has had to do this particular recovery action about four times. Ike only gets credit for this last one. The other three times had to do with a single node failing and leaving I/O pending. This in turn appears to be the ILOM card in the node acting up.



Next time: Some other handy Linux cluster things to know before your Linux based cluster fails...

Mint 5 Revision 1

Posted by Steve Carl Aug 28, 2008
Share This:
Minor revision to a great Distro


I have made no secret here of my love for Mint. In the pantheon of Linux distros (and that is a huge pantheon full of worthies), it is the one that just works for me more than any other that I have tried. I admit I have not tried them all. That would be pretty well impossible. It is not just me that has found success with Mint either: I have corresponded with many people over the years of doing this blog who were having troubles installing Linux, tried Mint, and had it just slide in and solve their problem. Most recently someone with an IBM X30 laptop similar to mine, who was having issues getting their Wifi running with Fedora decided to install  Mint and that was it. Problem solved. This was with a Prism 2.5 chipped PCMCIA card too!.


As I recently noted in this blog, I am currently living between two cities.Unless I want to be schlepping hardware all the time that meant I set up a new set of Linux gear in my new office. One of these new systems was a Dell laptop that, while it has been dropped and looks rough, runs OK. It's main problem was that it was running only Windows XP. In my new role, I do use MS Windows for some things: Mostly for VMware's Virtual Center native client.


Aside: What in the world is up with that? No Linux native client? VMware started off a Linux based product!  ESX uses Linux on the control console!



A web interface would normally be my alternative as a Linux user (and as someone with as many feet as possible in the Web 2.0 world) but even the very most current version of Virtual Center does not support Firefox 3.0, and FF 3 is pretty much all I have everywhere. Grrr.

Mint 5r1 on a Dell Laptop Install


While I currently need XP from time to time for Virtual Center, the rest of the time I want to be on Linux, so I took the opportunity to install the new Mint 5 Revision 1 to the Dell laptop. Another aside: Odd nomenclature: Why 5r1 and not 5.1 or 5.0.1 I do not know. I  will take the liberty of call it 5r1 later here, just to speed my typing up.


Since I was planning on keeping XP, and it had a ton of tools installed, I needed to set aside 30 GB of the hard drive for XP. I know: Seems like alot, but  those tools look pretty useful, and the hard drive is big enough for both Linux and a 30 GB MSWin partition at 80GB.


First off, I ran XP's hard drive optimization program to make sure everything was compacted together, and I also ran chkdisk, just to be sure the hard drive looked healthy. Then I booted up Mint 5r1 and went through the very familiar install sequence.


5r1 does not do anything to the time zone picker (The graphical view of the Earth that slips and slides around under the mouse) to make it better. Still easier just to pick the TZ off the menu than to use the graphical selector. A case of a bad use of a graphical interface if there ever was one.


Once I got to the disk partitioner, I over-rode the disk size it selected to give XP a bit more room: It wanted to go with 26GB, but I wanted a round 30GB. If it turns out XP never needs it, I can still read and write to the NTFS space from Linux, so it will not be wasted.


Partitioner would fail, saying there was an error, but not what it was, or what to do about it. I was confused because I had done a 5.0 install on another Dell without issue at all.


I poked around at commandline, invoking the "ntfsresize" command to see what kinds of errors the MSWin disk might be throwing that was causing such a problem, but none of the error messages were all that clear. I thought about it, and decided that the problem must be that the MS Windows disk was "unclean". Even though I had cleaned it before starting the process, something was left undone. A quick boot back to XP, a clean shutdown, and a boot back to Mint 5r1 and now the install / resize went like a champ.


Note to self: boot one last time after a chkdisk so that MSWin will mark the NTFS file system clean.


The Mint (and therefore, the underlying 8.04 Ubuntu code base) could have been a bit more useful here. I am willing to bet that unclean MSWin NTFS disks are extremely common, and that they are in fact the most common issue when one is trying to install a dual boot setup like this. Instead of 'Error' and little else, a message saying 'Here is something you might try' would have been really nifty.

Mint 5 updates on the Houston Dell


Warmed by the success of the 5r1 install, upon returning to Houston I decided to update the other Dell laptop. I decided that a simple MintUpdate would more than likely get me to the Revision 1 version. Nothing is ever simple. Immediately hit a brick wall. The repositories for medibuntu and Hardy security would not refresh no matter what I did. Arg!


This one was not directly a Mint or Ubuntu thing either, but a nasty interaction between the "apt-get update" process and the Internet cache inside our firewall. Since I have no control over the way Internet content is cached, it required a bit a research to work around. The solution came from a posting in the Ubuntu forums.


sudo bash

apt-get clean
cd /var/lib/apt
mv lists lists.old
mkdir -p lists/partial
apt-get clean
apt-get update


I also did this for good measure:

Add the following lines:

Acquire::http::No-Cache "true";
Acquire::http::Max-Age "0";
to the file:


Finally, just for fun, I refreshed the Medibuntu security keys:

sudo apt-get update && sudo apt-get install medibuntu-keyring


That did the trick.

Mint Everywhere?


One might be tempted to think that I just run Mint on all my computers... and I have to admit that is a temptation sometimes. I do not run Mint everywhere. I would never learn anything about the other Distros if I did that, so I keep some computers in reserve and running other OS's:


  • My main Houston Desktop is OpenSUSE 11 as I write this, but it has had some stability issues, and will *not* do a clean shutdown or reboot, so I may move that unit over to Mint in the near future.
  • I have OpenSUSE 11 on my IBM T41 laptop, where it runs very well.
  • My IBM X30 laptop runs plain-vanilla Ubuntu 8.04 at the moment
  • My Acer 5610 dual boots Vista and Mint 5.  
  • Both Dell laptops dual boot XP and Mint 5.
  • Another desktop runs PCLinuxOS.
  • My main Austin desktop runs CentOS 5, and I have an upcoming post about that.


There are subtle differences between various distros that sometimes end up making a big difference to me personally: Here is one: OpenSUSE packages NVU (and it is very unstable there), but Mint packages Komposer (much more stable). NVU was developed by Linspire off the Mozilla Composer code base. Linspire stopped developing it some time ago: Well before they were acquired by Xandros in fact. Komposer is an updated NVU, in the sense that it is based off NVU's code but it is still active. There are versions for both Linux and OS.X so no matter which platform I am using I can be writing stuff for one blog or another. That all assume that I can not get to Google Docs of course. I wonder in the Open Source world how many projects there are like Composer / NVU / Komposer. And with Seamonkey actively maintaining the Composer code base, I wonder if they pull back in anything that was done in NVU or Komposer? But I digress.

Mint Still Going Strong


I have written about my brothers Mint system, and it bears repeating here as a proof point. My brother is not a computer person, and is not really interested in them other than as tools. Since he is a carpenter by trade, perhaps that is why to him everything is viewed from a tool-centric point of view. I built a computer out of parts that I later installed Ubuntu on and gave to him. Later, during a visit, I put Mint 4.0 on it. Last weekend I was at his house installing a new stick of RAM. He did not really need it: I just came into a spare 1 GB PC2700 stick from my mom and I thought it might fit his computer. It did, and now he has 2 GB RAM. Can you say "Disk Cache"?


In all the time he has had that computer, other than the time I had to replace his hard drive and update his video card, he has never called me about it. He and his wife have surfed the net, read email, taken classes at school, done papers in, etc. He doesn't even really see any reason to come up to Mint 5... or 5r1. It does everything he needs already. There is one big reason I have a tendency to put Mint everywhere. I don't have to support it. Stark contrast to when he and others in the family had MSWin systems.


Posted by Steve Carl Aug 25, 2008
Share This:
Moves and grooves


Behind the scenes a great deal has been going on for me personally. I have not been posting a great deal here for a reason, and it is not that I lost interest in it, or ran out of Linux things to say.



First off, I am changing BMC offices, moving from our headquarters location to Austin, Texas. There is nothing sinister about any of that really: I just want to live in Austin, nearer to the Open Source action... the Bar Camps, and so forth.



Secondly, you might have noticed a change in the description of my title: I have also left management and returned to 100% technical work. Again, there is nothing deeply mysterious about that either. After being a first line manager for 20 of my 30 year career, I noticed something: I had stayed technical. This blog is part of that, and herein over the last three years I have described in fair detail the technical things my team has been up to. In talking about that to my manager, we decided that perhaps it was time to be a full time techie again, and he helped me make that happen. That is also coincided with my move to Austin is no coincidence either. Everything sort of fell into place at the same time, and I have to say that while scary at first, I have been deeply looking forward to diving back in.



What that should mean for this blog is *more* material, not less.... once I get settled in to the groove of course. I have been doing my old job here for so long, it has taken me a while to get transitioned over. August also means vacation in Far West Texas for me of course, and I have been talking a little about my vacation adventures over in my personal blog.


Torn between two cities


Part of being straddled between two offices between now and December, when I make the big jump, is that I have two desks. Two offices. Two sets of machines to maintain. Fortunately, I can build computers with parts from the trash can and they are highly functional. My Houston office was stacked to the rafters with my computer resurrections. My PCLinuxOS unit came West as a place for me to land "here" (I'm in Austin as I write this) for starters. A test CentOS system also came out: the one that Dan had grabbed from me to set up a test system I talked about in the CentOS NAS cluster article series [part two ]. That is up and running, and so my new experiment was to look at CentOS as a user desktop OS. More on that in a different post, and later.



Another thing was resurrecting a Dell laptop and making it dual boot with WinXP and Mint 5. That too will be a different post. This is using the recently updated Mint 5 R1, so it will essentially be 'new'.



One other thing keeping me busy has been that, as BMC has bought a few companies, such as BladeLogic, we have had some opportunities to consolidate some of our regional R&D data centers. Here is a fun fact: about three years ago, we had over 15,000 computers in the CMDB listed as being assigned to various R&D missions. As we have moved towards various Green initiatives, and virtualized like crazy, we have taken that number to less than 9,000. I alluded to one small part of that in "Virtually Greener". Two data center consolidations will be coming up between now and next spring, and affect over 1500 of those computers. Getting that done and keeping R&D uninterrupted is a huge project, and this one does not generate a great deal of time with Linux other than as an end user. Lions and Tigers and Spreadsheets, oh my! Thank goodness has improved Calc with the 2.x releases!

Share This:

I did not actually have any plans to attend LinuxWorld this year, and I suppose that I barely actually did: I was there half a day as it turned out. Even in the little I saw today ("Today" being while I am writing this, which is Wednesday, August 6th, 2008) the show has changed. More about that in a bit.


I was in San Francisco for a completely different reason than LinuxWorld. I was in the Silicon Valley to do some work on a potential new BMC R&D datacenter. No new hidden announcements there: just consolidating six regional R&D data centers into one much larger and more modernly designed facility. It is amazing how fast a data center design goes retro.



Fun Fact: If you stacked all the computers we use for R&D in the Silicon Valley on top of each, in the shortest possible dimension, that would equal a stack of computers 29 stories tall... and this is after we have retired hundreds and hundreds via virtualization.  I know: Utterly useless knowledge, but kind of fun to know. If nothing else it helps me visualize the scope of the task it will be to move all this as smoothly as possible. Fortunately this is not my first time... and this isn't even our biggest R&D data center.



I finished up what I was in the Bay Area to do a little early, and someone at the BMC office had free passes to go to Linuxworld, and asked if I wanted to attend for a half day. Not one to turn down serendipity, I of course went. I had to pay, but with half a day to spend there I was just going to get a floor pass anyway.



I have not presented at the SanFran LinuxWorld for a couple of years, and I have never been as a non-speaking attendee, so it was very interesting. Here are some of things I noticed that seemed the same... and some that seemed very different. This is utterly my subjective experience of course. I was not really there long enough to square root the show, nor did I attend any sessions. From what I could see of the session list, that is still a very rich, fact filled experience.


  • Coming in, the lobby and the banners and the way everything was decorated was soothly familiar. Very much like coming home. There was Tux all over the place, and the familiar light blue on white signage I have seen at so many of these events.
  • The T shirts and other stuff at the event store looked to have even more, better selection than ever. I resisted another tie-die Linuxworld shirt only by sheer force of will.
  • There were fewer booths than last time I was here. I talked to one vendor in attendance but who did not have a booth about why that might be, and they said that that they used the Internet for a great deal of the things that they used to get from being on the floor. I get needing to spend the marketing money wisely, but it also made me sad: It looks like we have another endangered species on our hands.
  • The flavor of the vendor mix that was there was also interesting:
    • I saw lots of stuff about 10Gig Ethernet, FC over Ethernet, and 8Gig FC.
    • Lots of storage : I was especially interested in Promise technology in that regard because of their recently replacing Apples Xserve RAID product as Apples solution for low cost data center storage. We liked our Xserve RAID gear quite a bit, but this gear looks better in every way but one: It is not as cool a physical design. Oh well, you clearly get more bang for your buck than with the Apple product or days gone by. Promise also supports actively Linux, whichmoves it to a new level for me personally.
    • Rackable systems had a Semi-trailer filled with a portable datacenter. Not the first time for that I know, but the first time I got to touch one. Very cool.
    • The .org area was as fun as usual: This time I spent some time at the DRBL / Clonezilla booth, and I will definitely be looking into these tools when I get back from vacation.
  • There must have been 1.5 Bazillion Linux powered netbook class laptops. In vendors booths driving displays and in attendees hands as their mobile computing device. Makes sense, since they have sold those by the truckloads. If it wasn't a netbook, it was an Apple, and several of the Apples were running Linux. The MacBook in the Clonezilla booth was running Ubuntu.
  • When I first started going to LinuxWorld, RedHat, SuSE, Xandros, and so forth were there. Even though Wednesday (the day I was there, which as I write this is still today) was "OpenSUSE day", they had no booth I could find. Neither did RedHat or Xandros or MS. MS dropped out pretty early I think. That just could not have been comfortable.
    • Side Note: RedHat used to give away red Fedora hats at LW: I always thought that was the best gimme ever at a trade show ever, even beating BMC's own combo laser pointer / pen (or, "laserwriter" as I used to call them when I was giving them away)
  • Ubuntu / Canonical *was* there. There were not before.
    • Is it just me, or is Ubuntu pretty much everywhere now?
  • I saw several products listing Mandriva as supported: Never noticed that before. Good sign.
  • Saw one vendor listing PCLinuxOS as supported. Also good sign.
  • Linux based hardware appliances were all over the place: WAPS, Cells phones, general handhelds, and on and on.
  • Bumper sticker on an Apple: "My Other Computer is a Data Center": From Google.
    • At one point on this trip I could not get to the Internet... while I was writing this in fact, so I could not use Googles Docs as I often do. Had to go with Komposer, which is better for HTML generation anyway. Looking at all the Linux powered netbooks, and thinking about how Apple pulled the iPhone tethering application recently, it seemed to me that Suns "the network is the computer" is still in force, and that we are still a ways away from ubiquitous network access.


My general feel, after walking around and talking to people and looking at stuff was that Linux had turned a corner sometime between the last time I was here and this time. Where it used to be "Linux can do it" where "it" was defined pretty much as "Anything", from desktop replacement to embedded to server, the claim that it could do "it" was based on the fact that it factually could do it, not that it had huge market uptake or maturity.



This felt different. This looked like an event that was about something that was utterly mainstream. It felt like a mainframe conference of old, where all the vendors were selling things that made the MF work better  or analyzed it in some way or added missing functionality (Hey!  We do that!).



In a way it was a little hard to deal with. It was one thing to be an early adopter, but now, looking at all the netbook users running around I realized in some ways the Linux world has caught up to and even passed me a bit. For one thing, I left my XO-1 in Houston, although the netbooks looked more usable in the keyboard department than the XO-1 is in any case. Rats. Time to start saving my pennies.....



Welcome to the Linux World.

OpenSUSE 11 GA

Posted by Steve Carl Jun 29, 2008
Share This:

I mentioned a few posts back that I had a test system stack: four identical older systems that I set up to be able to test Linux. The idea was the I could do back to back comparisons and have a good idea how each Distro of Linux stacked up on the same hardware at the same time. No sequential reloading of Distros on the same computer. Just a quick switch of the console via the KVM to look at the same thing (, Gnumeric, Evolution, Firefox, whatever is peaking my interest...) on the same type of computer, but two different Distros.



I took it all apart today. I did not reckon with two problems.


  1. Heat and noise while they were up (I left it all down when I was not using 'the stack'). The noise came from the fans in the KVM. Note to self: data center grade gear is lousy for office use.
  2. Even if the hardware looks the same, and specs out the same, when it is old, it does not necessarily act the same. This is probably true even when hardware is new, but as it ages, it becomes more pronounced. In particular, the video cards and how well they worked with the KVM, and the hard drives, and how some systems seemed to be in I/O wait for no apparent reason against /dev/sda.



I had a third reason for doing what I did, which was to learn how our new data center standard KVM switches work from actual setup type experience. I am always looking to stay as current as I can on all sorts of tech, and I had not had a chance to "play" with these yet. that being done, it was time to move on.


OpenSUSE 11


I mentioned in that post about the test stack that I was testing OpenSUSE 11 Alpha. It has since GA'ed, so it was time to go back and have a look. Unlike Fedora 9, OpenSUSE 11 had installed fairly easily even in Alpha state. I expected the GA to be smooth, and it was. All you have to do is look at all the trade reviews of OpenSUSE 11, and read all the praise for the changes that it has brought to the OpenSUSE party to get the feeling the R11 is a significant upgrade over what came before it.



A great deal of the excitement surrounds the fact that the software installer and updating process are significantly improved. They are not yet quite Ubuntu / Mint easy, but they are light years better than they were, and are closing in on the leaders of the pack. It is now dead easy to enable alternate repositories, including ones that allow you to install binary only drivers like Nvidia and ATI's. This, as it turned out, would be key for me.


I did not want to install R11 on 'the stack'. I wanted to turn that off and take it out of my office. My IBM T41 was nominated instead. It has always worked well with SUSE in the past, so I assumed it would be easy, and it was. Boot the LiveCD, run the installer, answer a very similar to Ubuntu set of questions, lay out the hard drive manually as always, and then let it spin on down.



Since the T41 had been running Mint 4, the OpenSUSE look and feel was replaced from the get-go with my customized desktop: Space Shuttle landing at night picture, standard Gnome tool bar at the top of the screen. Some things are missing:


  • No gkrellm is available from any standard OpenSUSE repository. My favorite system monitor... well, other than Patrol of course. I am sure it is out there someplace, and when I get a spare moment, I'll find it.
  • Sensors, avahi, etc all have to be installed since they were not on the LiveCD image, but they are available.
  • HDDtemp is not available!


In no time at all the desktop looks more or less the way I like. The tool bars are stocked with goodies. The Wifi card works out of the box and with no muss or fuss (something that Fedora would not have done). Evolution finds the Mint created config files and appears to work well.




Phase 1 complete. No casualties.



Crispy Nvidia 7300


Shortly after I finished up the T41, my Dell 745 desktop, running Mint 4.0, starts acting flaky. It moaned and hummed and whined and wheezed. I opened the case, and watched the fan on the video card stop and start. Speed up, then slow down. Whine then run silently. Uh oh.



A few days later, video stops working on the second monitor. "lspci" says that there is no Nvidia card at all.



I do what any geek faced with such a situation would do. I went to Fry's (I gotta love a store that has parts to build your own Linux computer and also sells Apple stuff). There I picked up an Nvidia 7200CS that had a big heat sink rather than a fan on it.



In the 7200CS went, and no luck. Mint acts like it can not see it. I decided to try OpenSUSE and see what it would do. My thinking was that OpenSUSE, being from Novell and the Open Source members of that project, should have the worlds best implementation of Evolution on it: Novell bought Ximian, creators of Evolution and the Evolution connector. In the past the SUSE version of Evolution had always been at least workable. This would give me a chance to see how well OpenSUSE worked on desktop hardware, with dual heads, with the Nvidia repositories, and with Evolution.



Late that night, I booted the OpenSUSE 11 LiveCD that I had used on the T41, and it all worked pretty much the same as it had. For fun I tried to use the Open Source Nvidia drivers first but they would not enable the second monitor. The closed source ones worked fine, and enable the "twinhead" setup. I was back in business. Even Compiz worked, and that had never happened on the 745 with the Nvidia 7300 and Mint.



Evolution came up, found everything where Mint 4 had left it, and I was off and running. Well. Not so much


Stable for 24 hours, then a failure. Evolution Connector crashed.


Evolution 2.22



Evo 2.22 in SUSE has a slightly updated look and feel relative to that same app in Mint 5.0. A few more plugins appeared to ship, all though I did not compare them line by line.



My desktop can *not* have an unstable version of Evolution on it. It is my main place to read email, check my calendar, open tasks to myself, update contacts, filter emails from various mailing lists into folder for offline reading, etc.



I installed the debugging symbols for Evolution and Connector, and went into the business of sending crashes into the Gnome project. At first it crashed when I was using it. Then it started to crash even was I was no where near the computer. More and more, faster and faster, closer and closer together.


When I say crash, I mean Connector crashed. Evolution stayed up and running. It was just useless.



I created a clean ~/.evolution file, and slowly brought back over the mail folders from the backup copy now called I went through and disabled plugins that were not useful in our MS Exchange based shop, like Hula and Groupwise related things.


Crash. crash. crash.


And now, the secret sauce....



I was trying to decide what to do, and had just about opted to move to Mint 5.0 on the desktop, with a fall back plan to Mint 4, which has been stable. Then, I noticed something odd. A pattern emerged. Every single time Evolution Connector had crashed when I was there to observe it, it had been when the inbox was being filtered: When the rules were running that kept my inbox cleared out. A little status message in the taskbar about filters running was there every time, and always at 0% complete. It looked like a new message was arriving, triggering the rule to run and parse it, but that the rule was immediately freezing and Connector was crashing shortly after that. I have about 20 Rules in the ruleset. I would not think that was a large number, but who knows? My quick looks at the crash dumps before I sent them in to Gnome made me think the crash was happening in the same way every time.


I decided to try something.


  • I disabled filters aka 'Rules' in Evo-speak on INBOX for   Evolution Connector.
  • Created and enabled IMAP account to the same MS Exchange 2003 server Inbox
  • Turned on filtering on IMAP. Same exact rule set, same exact Inbox, just running via IMAP rather than Connector.
  • I made IMAP my default account. The Connector account was there and active, just not default. This means, among other things that outbound email is being delivered via SMTP rather than through the Connector's WebDAV protocol.


My idea and experiment: use Connector *only* for Calendaring, Tasks, and Contacts (including GAL lookups). Take the stress off the Connector code. If this was a timing related or load related issue.....


It has not failed even once since I did this, which means about 5 working days of uptime. Other than the first 24 hours of stability, I could not get Connector to stay up for more than a few hours at a time. It appears that Evolution Connector and the built in rules facility are not compatible at this time, at least with OpenSUSE 11 and Evolution 2.22.



In retrospect, it probably should have been a clue that the OpenSUSE 11 installation on my T41 laptop never had an Evolution crash. I do not run filters there.




As usual, I have to ask the question, is OpenSUSE 11 a viable desktop for an enterprise.  Not for geeks like me but for the average computer user that does not want to know anything about the computer itself: they just want a tool to get a job done.



The desktop itself is easy to use, easy to configure, easy to update, and a strong preview of what is to come in the next release of SLED (SUSE Linux Enterprise Desktop). It has all sorts of standard Open Support, from Wikis to mailing lists to online doc.



From what I have seen the system is pretty solid except for my corner case of Evolution against MS Exchange 2003 running a fairly large set of filters on my inbox via Connector. I'd have to say I would probably have no problem supporting it, and would prefer all the new shiny goodness of OpenSUSE R11 versus the getting-long-in-the-tooth SLED 10. For the first time ever, I have left OpenSUSE on my primary desktop to be used as my primary OS at the office.



Mint will stay my primary at-home Linux version. Instead of Mint-everywhere, I'll be jumping back and forth. A new experiment has begun.

Fedora 9 GA

Posted by Steve Carl Jun 16, 2008
Share This:

The problem with asking a technogeek whether or not something is possible is that you will almost always get back the answer "Yes".



"Can a program be written that monitors all the computers on the network, regardless of who makes it, or what OS it is running?"




"Can it be ready a week from Tuesday?"


"What year?"



There is the rub: a technical question needs a scale framed around it. Is Linux a viable desktop OS: Yes. Can we use Fedora at the office? Yes.


Those last two, while true, ignore scale and ignore training and ignore whether or not other 'flavors' of Linux would be better. Our recent experience with replacing our Tru64 TruCluster with a CentOS based cluster is a lesser example: yes it was possible, but it did require having a guy like Dan Goetzman to read the kernel code, read the traces, find the problem, and write a workaround. Since then, it has worked extremely well. You can not ignore the fact however that most companies do *not* have a Dan or even a Dan-like person on their team. Such skills, while not unavailable are rare enough that most folks just go with a vendor created solution.



That is the eternal tradeoff of IT: Roll your own and get exactly what you want, but then be forever locked in to being the maintenance and update group, or go with a vendor solution where all of this is essentially outsourced.



Our CentOS cluster is an enterprise grade solution, but in point of fact, only because Dan is standing behind it. CentOS has no vendor support. Without Dan, we would have used RedHat Enterprise Linux and bought support instead.



It is in this frame of reference that I went to look at Fedora 9. I know it is not supported, and that it is not meant to be an Enterprise Linux Desktop, any more than my recent foray with Mepis is or was. Fedora is a technology exploration, and I was exploring.


Back to the Stack



I started out a while back to create a test environment where I could compare various Linux environments side by side. At the time, Fedora 9 was pre-GA, and was not behaving well on the test gear. At the time I was trying out the LiveCD version of the install, but Fedora was just not getting the video right, where pre GA or just-recently-GA versions of Ubuntu, OpenSUSE, and Mandriva were working fine on the exact same type of computers. These are standard Dell desktops no less. Nothing to weird about them. Certainly not laptops and their more esoteric hardware.



Even before I did the test installs, I was starting to feel a certain level of frustration with Fedora. I could not quite figure it out. It used to be my *main* distro. I used it ahead of everything else: Where Mint sits today, once there sat Fedora: From Fedora releases 1-5, it was, for me, the *it* distro, replacing Mandrake.



With Fedora 1 through 5 I had to hack the wireless to work on all my laptops. I was getting downright fast at it. Either finding the unsupported-by-Fedora-but-Linux-native-driver-stuff, like MadWifi, or shortcutting it with NDISWrapper. Either way, Fedora was on the air in short order. It was no harder to get going than SUSE back then, and Fedora hacks were better documented on the Internet. it seemed like everyone used it.



When I started using Linux as my full time desktop here at the office, it was Fedora. Not any more, and not for a while. Now-a-days, I only install it to see what is happening in it, and it usually ends up being frustrating because in terms of ease of install and supported hardware it has been passed standing still. Fedora feels stuck in the past, with the Anaconda installer: In truth it is no different to install now, in terms of difficulty, and need to add in 3rd party repositories, than it was in the beginning, or at least that is the way that it feels. One person at the office (a fellow Linux desktop user) said that they felt that Anaconda itself was getting more fragile with every release.



Ubuntu, Mint, Xandros, OpenSUSE, Mandriva, PCLinuxOS... you name it. All of them are dead easy installs, and usually they just work out of the box.


Fedora stands alone



Fedora is outstanding in its field: That is where we found it. Out standing in a field... Sorry.



I have known intellectually for a long time that Fedora is different from all the other highly used Linux Distros. Knowing that and have a visceral understanding of it are not the same thing though. I used to think of OpenSUSE as being a kissing cousin to Fedora, once SUSE started to use the Fedora-like development model. But there is a big big difference, especially now.



Here is where I get into trouble sometimes when I am looking at things like this. I have to recall that Fedora may look exactly like any other Gnome based Linux; Same menus, same packages, same projects underneath it all, but it is assembled out of the bleeding edge stuff. Can it be made to work: yes. Is it interesting to see what some packages are doing? Yes. Should you use it as an ELD: Only of you don't need support.



The OLPC project has been working for a long time to create a production version of Fedora 7... and the Fedora project is two releases down the road from there. Support on OLPC is about what you'd get from Fedora too: online forums, Wiki pages for Doc, etc. No number to call, no throats to choke if you are so inclined.



You can get support, from a commercial company, for years, on Ubuntu (especially the LTS versions like the current 8.04). Mint is community supported but close enough to Ubuntu to be pretty supportable. Many of the things published in the Ubuntu forums work on Mint. Xandros and SUSE stand behind their versions with support options.



You want support on a Linux desktop from RH, you go with Red Hat Enterprise Linux 5 Desktop or one of its variants.



Part of what made relative lack of support for Fedora pop back into focus for me was a note I got from the CodeWeavers folks:



...The bad news is that extensive testing on Fedora Core 9 has revealed
severe problems with FC9 itself.  There's a serious font-drawing
problem, and also a periodic crashing bug.  Both of these are problems
in Fedora and outside of our control, so this latest release is likely
to exhibit those problems as much as the betas did...



That was interesting two ways: The obvious technical issue, but also that Codeweavers was *trying* to support Fedora as a viable desktop for Linux.


Looking at BMC for a moment, we only support versions of Linux that have vendor support for the version: currently Novell and RedHat GA releases. I personally would like to see Ubuntu added to that list, but I am sure that comes as no surprise to anyone that reads this blog. No I am not announcing or hinting at anything. Just wishing.


ELD and Fedora



Anyone who is a Linux maven could make a go of Fedora as an ELD. I know lots of people here at BMC that do just that. Fragile installers do not scare them, and fixing drivers is no big deal, etc. Fedora, for them, is beauty because it is bleeding edge. Sure the Xorg server in R9 is experimental and causing screen tearing. Now. In a few days or weeks it will get fixed, and then they'll have access to the latest greatest features. The speed. The bleeding edge hardware support. It will have been worth it. To them.



As an ELD for the masses though, all Fedora is going to do it give you a clue as to what you will see in some point in the future: maybe RH ELD 6.  And even that is not a dead certainty: RH will err to the side of stability, so some bleeding edge stuff will not make the cut. Maybe RH ELD 7. Maybe never.


For use in a shop like ours.. an MS Exchange based shop, I always look at what Evolution is looking like and how it is behaving. I have learned over the years that the point release of the project is not all you need to know. The way that the Distro packages and tests it is important. See what happened when I tried to run Evolution under Mepis for example.



I did test 2.22 on Fedora 9. It works almost the same as 2.12 did on the last Fedora, and it also works about the same as 2.12 or 2.22 does on Ubuntu or Mint. Recall the 2.12 and 2.22 are adjacent releases, despite the jump in the numbering. Evo has all the same features, and all the same problems. Do a mass delete from Evolution on one computer, and the other one will completely loose track of the inbox message count. Exchange back end crashes fairly often still. Finally, nothing has really happened (as I feared it would not) on the MAPI support front.



I did do one experiment I have never done before: I set up both IMAP and Connector at the same time and pointing at the same inbox on the same server. When the connector crashes, IMAP keeps right on running. This tells me that the instability is probably not in the base Evolution code, but in the protocol connector of "Connector" itself.


Install of Fedora 9


I originally planned this post to be about how the Fedora 9 installer has changed between the pre GA and GA code. I changed my mind. I was interested in the 'fragile' comment that had been made. It matched my experience with the pre-GA LiveCD. I decided to go conservative, and download the install CD set (the Dell test computers not having bootable DVD media). It was by and large the same Anaconda install I have seen for a while now except that it would not run in GUI mode. I had to run it in the ASCII character based curses based mode to see it. No big deal: Done that before.



When the final boot came, the same thing happened that did with the LiveCD: The video mode was whacked (same as the GUI install it appeared), and the boot messages were invisible. The Dell monitor said "This video mode can not be displayed".



I booted to single user, erased the /etc/X11 xorg.conf, ran 'system-config-monitor', and got past that problem. But now 'firstboot' had not run, so I manually added userids and config-ed things on the system that the firstboot stuff normally does.



I don't know if this is a global thing or not, but I have to agree now about the fragile comment my co-worker made: the installer is not very solid. We both have Dell gear to work with so it could just be a limited sample type problem. Given the ubiquity of Dell gear, and the fact no other OS is having these issues with the same hardware, that seems odd. Perhaps by being on the bleeding edge some backward compatibility was left behind?


Once up and running, it is a very standard Gnome desktop: None of that MS look-and-feel stuff that SLED or Mint is going in for. It is fairly crisp on the older hardware, but that is a Linux hallmark. I would have been shocked to see it going slowly. 2.0 Ghz and 512 MB of RAM is still a *big* Linux system, even if this hardware is over three years old.



Applying maintenance via yum makes the video break again on reboot. I guess a new xorg came in, and replaced the /etc/X11/xorg.conf on arrival, but that is just a guess. I powered it off and put it away. I know what I came here to find out. It will be there should I get curious about something else.


The Computer Pile


Fedora now lives in that same logical place in my pile of computers that MS Vista does. Something I fire up whenever I get curious about something. Not that Fedora is as bad as Vista: I got curious about how Vista works after SP1 is applied, and I came to test that last weekend. Answer: No idea: It needs 8 GB of free space just to unroll the patch bundle! Vista takes up 12GB of the 15GB partition. It would be all kinds of work to get it more space.



I decided to try applying point patches. Over two hours later, I had about 23 patches installed. When I did the patch update on Fedora I installed over 100 new or patched versions of things, on much slower hardware, in about 15 minutes. No: Fedora is not Vista. It just is not Mint-Ubuntu-SUSE-Xandros-PCLinuxOS-etc either. That is neither bad, nor good. It just is marching to the beat of a diffrent drummer and and I need to remind myself of that from time to time.

Share This:
This is a Beta? Wow....


These days the Distro I am always watching and waiting for a new release of, more than any other, is Mint. I have expressed that preference here quite a bit since I discovered Mint back in its 3.x release days. Mint 5.0 Beta is out now, and I am not really sure why it is considered Beta. All I have had with it so far is about 24 hours, but it is solid.


Good Parents


It helps that Mint starts with Ubuntu 8.04. I have been extremely impressed with that release on every computer I have put it on. The Mint team then layers on its own package selections as defaults, adds in its own themes and toolsets, probably does other things I don't know about, and creates Mint.


I really like the cool, dark themes of Mint. I also liked the earth tones of Ubuntu, and I really like the Heron desktop background artwork, but I think that, in the West, Mint's default colors are probably going to be more universally well liked, for the reasons I discussed in my last post at my personal blog.

Just an assumption though.

The Install


There is not much point going into depth on what a Mint install looks like here. It looks like an Ubuntu install with a Mint themed LiveCD desktop behind it. It is a LiveCD with and install icon on the desk. Seven panels. Same questions. Same annoying new time zone slippy sliddy map. I was glad to read in several full on Ubuntu install reviews that every one I read found that feature to be useless. It may take an impressive bit of graphical programming to make that happen, but I can not determine what useful purpose it has. I just use the TZ chooser pull-down menu below the graphic these days. In fact, one of the things I was curious about in Mint 5 was whether they would go to the trouble to take the Ubuntu-ism back out. Answer: No. Oh well.


The computer I used for this is my Dell D620 laptop. I had Ubuntu 8.04 on it already, so it was a pretty good bet that it would all work, and it does. With 2 GB RAM, dual core 2.0 Ghz T7200 processors, 1440x900 flat panel (detected and configured automatically!), and the Intel GMA 945 chipset, the D620 is a middle of the road laptop by today's standards. Ubuntu and now Mint make it act like a top of the line unit though. Everything is fast. The Compiz GUI effects are enabled by default and do not visibly slow the computer. The default effect choices are mostly useful rather than eye candy: Things like task bar preview, and window re-sizing feedback.


I have said it before, but it bears repeating: If Vista could feel shame it would be hanging its head. Linux and OS.X are living proof that you do not have to have top flight graphics cards to do all the fancy video compositing.


One other preference oft mentioned here: Mint does a SLED looking menu by default, with I just as quickly ignore (mostly) and restore the Gnome standard menus across the top.

First Pass

After I very quickly (less than 10 minutes) spun the Mint 5 Beta stuff to the laptops SATA hard drive, formatting over the "/"(sda2) but preserving "/home" (sda4). Layout like this as usual for me:


Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00019fb7

Device Boot Start End Blocks Id System
/dev/sda1 * 1 1824 14651248+ 7 HPFS/NTFS
/dev/sda2 1825 3040 9767520 83 Linux
/dev/sda3 3041 3283 1951897+ 82 Linux swap / Solaris
/dev/sda4 3284 9729 51777495 83 Linux


I booted back into Mint 5.0, logged back in to me, and it pretty much looked like the same desktop I had under Ubuntu. That in turn looked like the Mint 4.0 before that. All the look and feel elements, backgrounds, font settings, etc all there. A quick trip into Synaptic re-added all my default applications that I was missing. Things like HFS for reading Mac disks, Evolution plus debugging packages for email, and so forth: All told about 40 things not in the default LiveCD.


Things all worked, but I was having a bit of trouble with Evolution remembering a MS Exchange hosted IMAP server my email used to be on a while back. Nothing I could do surgically would convince it that the server no longer existed. It kept prompting me for my password to it. Very annoying. I used 'find' to search every file in my home directory for the server string, but nothing doing. It must have been coded or compressed in some way that a plain text search would not find.


I use HTML editing far more than standard OpenOffice file formats. It makes it easy to start a document in one place, load it up to Google Docs, and edit it there some more, then download it for a final polish in a different place. That means the OpenOffice writers default launch needs to be set to "ooffice -web %U". 'System / Preferences / Main Menu' makes short work of that tweak.

HTML Editor Digression


I did part of this post's edit is Quanta 3.5 under Mint 5.0. It crashed a couple of times, but saved the work so I did not lose anything. I am guessing it would be more stable in a KDE environment than a Gnome one... or it is just that this is a Beta. It is usable and useful though. Quanta is an interesting project, but it did manage to almost torch half this post. I had saved the post and exited Quanta... I thought. I then edited for a while in a few other editors. Then Quanta somehow got restarted, and saved a version from its project store back out to the disk, overwriting what was there with a much older copy. I cussed a bit, but then realized that the last editor I had been using, Komposer, kept a backup of the document, and was able to get most of it back.


I do not now really blame Quanta for this near erasure of my post. It is a sophisticated tool with tons of features, and it was working the same way many SDK's: Like my blog post was just part of a much larger project. It was trying to organize it into its internal data structures and not really assuming I was working from the external disk copy. Quanta wants to be used in the way it was designed to be used, within its project paradigm, not as a casual editor.

I did part of this post in Kompozer (yea backup files!), and for extra fun, part in Bluefish. I wish there was one really good HTML editor out there for Linux, but all of them bring something to the party I like, and other things I dislike, so that depending on what I am doing, I fire up one or the other.


  • OpenOffice Web: Good WYSIWYG, spell checking, but upper cases all the HTML tags, and drops in extra stuff at the drop of a hat. Trys way to hard to make things into paper documents rather than simple web pages like these posts.
  • Komposer: Based off NVU. Not being deeply developed anymore (which is better than NVU, which has not seen any work for years), has crashed a few times on me) tends to be more for WYSIWYG work. I like the tag cleanup tool, but wish it did more. If Komposer / NVU were being actively developed and had better spell checking I think that is what I would use more.
  • Google Docs:  Has taken to "severely uglifying" the HTML tags with "ID" stuff.  Its habit of dropping in unwanted <br> tags is unreformed, and Google has never fixed the screen presentation so it is more WYSIWYG. I mostly use it when I am doing a great deal of editing from all over the place or collaborating on something. One thing though: You just can't beat its revision system. It has saved my document-editing-bacon more than once. Makes its unruly behaviors all that much more irritating, because otherwise it would be my HTML editor of choice.
  • Bluefish: Reminds me a lot of Quanta: More project oriented, more raw HTML editor. WYSIWYG features are sort of grafted on, but handy for serious tag slinging.
  • Quanta: All noted above.

Back to Mint..


I ran 'Mintupdate' from 'System /  Administration' and downloaded the current stuff that Mint has defined as safe updates. About 40 packages altogether were in their safe classification of '3'.


When I was in Synaptic adding in packages like HDDtemp GkrellM, etc, I saw that there were updates to several packages available that I was not installing. MintUpdate does not offer then at all, or displays them in state other than three depending on your display preferences. One of the updates in Synaptic that is not in MintUpdate is ... MintUpdate. Looks like MintUpdate is not ready to replace itself...


This update safety system that MintUpdate brings to the table is probably at least part of the reason why this so-called Beta is so solid.

Pass Two


This D620's Gnome desktop has survived quite a number of OS upgrades, so it was time to clean out the whole thing and start over. I erased .gconf* and .gnome* and then logged back in and re-laid out my default desktop. It now looks the same as it did before I started, and only took about 10 minutes, but it does not have any weird behaviors anymore. Evolution has forgotten the old MS Exchange server. What 'find' could not find, 'rm' took care of. Brute force rather than finesse though. More of that in the Evolution section below.


I added a new panel to the top, and repopulated it Gnome style, but left the SLAB-looking panel thing (MintMenu and is at version 3.3) at its default location on the bottom for reference. MintMenu has one feature I really like, which is the ability to triage-filter applications as I type their names. If there is an application I do not use very often such that I do not know which menu they appear on, the triage-filter-feature is pressed into service. Example: Sometimes a thing like the Bluefish HTML editor shows up in one distro Gnome menus in the 'Internet' section and others like Mint place it in 'Programming'. With MintMenu I don't have to know where something is. Kind of like Spotlight on OS.X, but more focused.


While the screen resolution was configured correctly, the default DPI was not quite right. In System/Preferences/Appearance/Fonts it was set to 92 or so, and D620s flat panel is really 121. At 121 the fonts were a little bigger than I needed, so I set the DPI to 108 and that seems to work pretty well. Lovely anti-aliasing, smooth round easy to read shapes. Very very nice now.

Evolution 2.22.1


Since I am looking at this as a desktop for complete replacement of MS windows at the office and in am MS Exchange 2003 shop, naturally Evolution has to be considered. It worked fine under Ubuntu 8.04 though, and nothing really changes for Mint 5.0. It is in fact the Ubuntu packages: Mint does not version them:


dpkg -l | grep -i evolution
ii evolution 2.22.1-0ubuntu3.1 groupware suite with mail client and organizer
ii evolution-common 2.22.1-0ubuntu3.1 architecture independent files for Evolution
ii evolution-data-server 2.22.1-0ubuntu2.1 evolution database backend server
ii evolution-data-server-common 2.22.1-0ubuntu2.1 architecture independent files for Evolution Data Serv
ii evolution-dbg 2.22.1-0ubuntu3.1 debugging symbols for Evolution
ii evolution-exchange 2.22.1-0ubuntu1 Exchange plugin for the Evolution groupware suite
ii evolution-exchange-dbg 2.22.1-0ubuntu1 Exchange plugin for Evolution with debugging symbols
ii evolution-plugins 2.22.1-0ubuntu3.1 standard plugins for Evolution
ii evolution-webcal 2.21.92-0ubuntu1 webcal: URL handler for GNOME and Evolution
ii mail-notification-evolution 4.1.dfsg.1-4.1ubuntu1 evolution support for mail notification
ii nautilus-sendto 0.13.2-0ubuntu1 integrates Evolution and Pidgin into the Nautilus file
ii 1:2.4.0-3ubuntu6 Evolution Addressbook support for


For this list I deleted the libraries and compressed some whitespace for brevity....


There we have that big version jump: the last version of Evolution was 2.12 and these are 2.22, but there are no intervening releases. Evolution is now aligned to the Gnome release numbers.


A few settings I always do in Evolution later (like making Sunday the start of the week, setting my default calendar to be the one on the MS Exchange server, limiting GAL responses to 50, Turning off all the Groupwise plugins, etc) and it is ready to go. Stable so far, but...

Inbox State with Multiple Clients and Evolution


Evolution has one pretty ugly behavior, and it has been there for quite a while. I see it all the time but have not said too much about it here. I assume that my use of both MS Exchange and Evolution is not utterly typical. Others may not see this often. Just in case, here it is:


I do not run email from just one Linux system, but most of the time from at least two. My desktop, currently running Mint 4.0 on a Dell 745, has the mission of filtering my email. Evolutions filtering tools are pretty good, so I have it keeping all my various subscriptions to various email lists organized.

Further: MS Exchange is well known for being snarky about a users inbox getting too big. Unnatural things happen when a server side PST gets too large (although this has gotten better in successive releases of MS Exchange). Add to that inbox size limits: most shops, ours included, has server side limits for how much storage you can use for email.


If I am logged in to MS Exchange from both the desktop and the laptop, and am using Evolution to read my mail in both places, and I then archive a large amount of email from the desktop, the laptop utterly loses track of what is *left* in the inbox. It can only see emails that arrive *after* the archive happens. Log out and back in all you like: it never figures out that its view of the Server side Inbox is out of whack.


There is an easy fix though, and I put it into a batch file. I run this script every single time right before I log in to Evolution. It looks like this more or less:


rm ~/.evolution/mail/exchange/

rm ~/.evolution/mail/exchange/
rm -Rf ~./evolution/cache


Yeah: Its ugly. Brute force effective though.


Interestingly, it does not help to be logged out on the laptop instance of Evo. Logout, do a large archive from the desktop, and then log in from the laptop, and it has lost track of the MS Exchange hosted Inbox. There do not appear to be any 'clear cache at startup' or 'rebuild Inbox meta-data at startup' configuration settings, at least in the GUI.


It does not appear to slow down MS Exchange login to do the scorched earth script before starting Evo, so it is cheap insurance.

This is not a Mint thing, or an Ubuntu thing. The exact same thing happens no matter what Distro or release of Evolution I use. Evo just can't keep track of Inbox state all the time. Oddly if I delete a few files from one computer, the other copy of Evo on the other computer figures it out. Seems to be a size or number of items deleted related problem.

Other Office Stuff


This is a beta and it has only been about 24 hours of testing so I can not say that every single thing works as it should. That will require weeks of testing. I did have some emails with .pdf, .doc, and .xls attachments I needed to look at during the day, and everything seemed to work perfectly with the included OpenOffice 2.4. I will probably try out the Beta 3.0 version at some point as well, sinccne it is supposed to, like every release has so far, increase fidelity of MS format import.


I went to the web interface of Remedy to research an Incident, a Change Request and a task, and Firefox 3.0b5 functioned extremely well against the Remedy 7.0 Mid-Tier server. I pointed Firefox at an internal Oracle application and had no issues there. Finally, TSClient against an MS W2k3 virtual machine running in the VMware farm downstairs had no issues.


As Nero Wolfe often tells Archie: "Satisfactory"


PS: A note in the Mint Wiki about 5.0 says that they are watching Firefox 3.0 closely and want to ship that as soon as they can. I have been running the 3.0 Betas for a while on Linux and OS.X and it is looking very good. Solid. Fast. Cool new features. I am glad Mint 5.0 will have it when it GA's.... or at least goes Release Candidate.

Enterprise 8.04

Posted by Steve Carl Apr 30, 2008
Share This:
At work with Ubuntu's latest Long Term Support version of Linux


I have been experimenting with Ubuntu 8.04 codename "Hardy Heron" on two of my personal systems and the Linux test system stack I mentioned last post. I have not written much about 8.04 until now because, being pre-GA, there was not much I wanted to get into as far a discussion of its Enterprise Desktop Worthiness Quotient (EDWQ?)



I started testing with 8.04 Alpha 6, on my IBM X30 laptop. When that looked pretty good, I tried it on my Acer 5610 laptop, temporarily replacing Mint 4.0 there. I used both of those computers for while to do various things like write previous blogs and other perosnal documents, surf the web, and so forth. I kept them updated nearly daily, just to see how 8.04 was trending.



I later installed the Alpha 6 version at the office on one the Dell DX260's in the test stack. The point of this was to configure Evolution 2.22 to get a feel for how that was shaping up. Well, that and I had this cool new set of computers that were crying out to test something.


Personal GA



When 8.04 GA'ed, I did a clean install on the Acer 5610 and tested it for the evening.



To this point, I was looking at personal usability stuff, not Enterprise. My first off the cuff reactions to that were:



  1. I like the new artwork, especially the abstract Heron on the desktop background. I showed it to my wife, and she does too. I showed it to some folks at the office, and got a "Yuch: too brown" reaction. Looks like the preference stuff I talked about in "         Color Theory" are still true...
  2. When I first brought up 8.04, I had no network connections. 8.04 "saw" the wireless card, and configured it. The wireless card "saw" all the local access points. I just had to pick one and all was good. But I knew to click on that icon and map that AP. Not sure a new Linux person would not have been frustrated nice if a pop up or something mentioned "Pick an AP point to get started" or something.
  3. Compiz seems to work really nicely on the Intel GMA 950 chipset on the Acer 5610, and I did *not* have to tell xorg anything about the screen resolution: It was correct from the get-go. Compiz even works on the X30 with its tiny amount of graphics memory: Vista should be hanging its head in shame. I turned Compiz off on the X30, preferring a crisp screen response to a pretty one. No point turning it off on the Acer: It snaps along pretty well there.
  4. I'd have no issues installing this OS for a non-computer person. My brothers          Mint 4.0 install is not in danger of being replaced though.
  5. It seems like every Linux lately gets a bit faster: A bit crisper. I assume this is the latest set of tweaks to both Compiz and the Kernel. Ubuntu also tossed AT&T style Init a while back to get boot cracking along more quickly and that seems to be getting better all the time.
  6. The new version does the best job yet identifying and configuring the ENE Technologies chipped MMC card slot on the Acer. Still does not see the card insert event to mount the card automatically, but if it is there at boot it sees it, and data transfers from it are faster than before.





This particular release of Ubuntu is more interesting than Ubuntu-average as it pertains to the subject of its viability as an ELD (Enterprise Linux Desktop). This is one of the Long Term Support versions of Ubuntu (the last LTS version being 6.06), with the desktop version of 8.04 being supported for the next three years (April 2011) and the server version for the next five years (April 2013). Given the amount of time a large company takes to get a new release of a desktop image ready, tested with all the corporate apps, and then pushed out to all the desktops, three years support is pretty much a requirement.



Ubuntu, knowing 8.04 was going to need to be supported for a while would tend to focus more on functionality and security related issues than latest and greatest eye candy, or at least that is my assumption. This is the kind of assumption that I'll be looking to test.



While I read some things in the trades about 7.10 being unstable because of how much feature and glitz the Ubunites added, I have to say that I never saw that. 7.10, and its Mint 4.0 variant, have been dead reliable for me other than the few Evolution issues I have already documented in this blog.





With the arrival of the GA version, I installed it not only on my personal Acer 5610, but my BMC laptop, a Dell D620, and did a fresh install over the Alpha 6 version running on one of the DX260's in the test system stack. For the D620 and DX260 installs I took some notes:



First off, I used the 64 bit installer on the D620 because its Core 2 Duo CPU's support that. My first ever 64 bit personal computer install. Done 64 bit servers before, but for some reason, even with the 64 bit capable hardware like the D620, I had never installed a 64 bit OS. The Acer with its Core Duo processors (Not Core 2 Duo, surely one of the most ill advised processor naming conventions on the planet today, Isn't Core 2 Duo alot like say Core Two Dos?) and the DX260 with its P4 received 32 bit versions.





There are seven screens that appear after you click the 'Install' icon.



  1. For the first one, I picked "English". That seemed to make the most sense to me at the time.
  2. This makes one of the most annoying new features appear: The time zone chooser. The picture of the world zooms in when you try to pick a TZ (I was going for Chicago, and the picture kept sliding about trying to escape the mouse. There was an old program I used to have for MS Windows back in the 3.1 days that you could put on someones computer and then sit back to watch them scream. It made all the desktop icons dance out of the way of the mouse so that you could never click on anything. The new TZ set feature reminds me of that program. Easier to just use the pick list, which thankfully is still included.
  3. Screen 3 of 7 is what keyboard to use, and I have never once seen this program not know my keyboard type. I assume that there are issues here in other locales to make this screen worth stopping on.
  4. For 4 of 7, I picked the manual disk layout option. I tried the default option with Alpha 6 and everything was laid out in one partition. That was not what I wanted so for GA I went my usual way:


   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        1216     9767488+  83  Linux
/dev/sda2            1217        1459     1951897+  82  Linux swap / Solaris
/dev/sda3            1460        2434     7831687+  83  Linux


        SDA1 is '/' and SDA3 is '/home'.


  1. 5 of 7 I gave the computer my name, the name of the default account I wanted, and the name the computer should have on the network.
  2. 6 of 7 was the recently added screen where it tries to find old userids from which to derive the settings. It found nothing. This was odd. It did not find anything on my Acer 5610 either, yet it has Vista as a dual boot, and this D620 has XP. Both had previously existing Mint installs too. This feature has never really done me any good to date. Someone must find it useful though.
  3. 7 of 7 verified all my settings. I pulled the trigger, and for about 8 minutes things were copied off the CD. It spent about 2 minutes configuring things, and then was ready to boot to Ubuntu 8.04 LTS GA.


I am not complaining (much) because the install is so dead easy, but the thing is that it could be even easier. Four maybe five screens. Combine a few things. Be smarter about the disk layout so I don't have to keep overriding it. Not saying it has to be the same as mine, but putting everything in one partition is not as brilliant as most of the OS is.


The 2.6.24-16 versioned kernel stopped to check out my hard drives on the way up, which added some boot time the first time.



There were no updates in the package repositories even four days after the GA date, which might be a first. Usually there is a last minute something or the other. Maybe being LTS they are more cautious about releasing things.



I proceeded to add the packages I need: things like Avahi, Sensors, HDDTemp, Macutils, HFS support, the debug packages for Evolution, Pidgin-SIP, WINE, and the 32 bit compatibility libraries (on the 64 bit installed D620 only).



Evolution was then configured, same as I ever do, against the MS Exchange 2003 servers.


Why Evo: a quick review



i have stated some of these next things about using MS Exchange from Linux several times, but I can not assume that everyone who might be reading this right now is familiar with everything I have ever written on this topic. Too easy to get here via a direct Google transporter. If you are a pure Linux, or at least Open Standards based shop, you might be thinking to yourself "Using MS Exchange is just suboptimal: Why not use something else?". Reality is that 50% of the big shops out there use MS Exchange, so no matter: it is something that just has to be coped with.



To work as an Enterprise desktop here, I need to be able to get at my MS Exchange sourced Calendar and email from Linux. The only ways to do this that is viable *at the moment* is:



  • The Gnome Projects Evolution package, with the MS Exchange Connector (WebDAV)
  • Using a web browser to get email off the MS Exchange servers Webmail. I am on record as not really liking this option because the web client is very heavy without real benefit and could use a strong lesson from Gmail on how to do Webmail right.



I do not currently consider the KDE Office stuff as all that workable against MS Exchange, but I am waiting for KDE 4.1 to see if the rumored updates/improvements in this area are in fact there. <note from the far future: as of KDE 4.4, it still was not great against MS Exchange...>


Whats in a Name?



Evo is now at release 2.22, jumping from 2.12 in the last release. That is not as wide a jump as it sounds: they are just lining up the Evo release number with the Gnome release number. Nothing really new stands out in the user interface, although I have a feeling it has many subtle upgrades and tweaks and I just have not found them yet. Like those newspaper games in the comics section: "What is the difference between these two pictures?".


EVO Has Needs Too



Lots of them.



Evolution is a problematic beast. It is a large project, and none of the new tweaks appear to be in the code size reduction department. The only thing I noticed different during configuring the email client to use MS Exchange is that is appears to do a better job looking around for available GAL (Global Address List) servers. Every time I have configured it, it has presented a different one. Before, I always got the same wrong one. What algorithm it is using is still not obvious. I still have to over-ride it to put in the one I want it to use: the one nearest to me in the network.



I have noted in these early experiments with Evolution is that it is far more stable on the Dell D620 laptop than the Dell DX260 desktop. The laptop is far more powerful, with dual core 1.73 Ghz processors (7984.3 BogoMIPS) and 2 GB of RAM. The single 2.0 Ghz P4 (3989.49 BogoMIPS) and 512 MB of RAM of the DX260 just don't seem to be a good place for Evolution to live. It fails frequently there, and when it fails, I have to run my cleanup scripts before I restart it. Not a quality, Enterprise level experience. Sure, the DX260 is hardly what a current hardware shop would be using, but I expected Linux and its apps to work in 512MB.



Quick poking with a diagnostic sharp stick, and I have the performance problem down as not enough RAM on the DX260: With Evo up and running under the D620, only 15% of the RAM or 300 MB is in use for programs. With Evo running on the DX260, 50% of the RAM or 256MB is in use by programs.



I expected the desktop system to be crisper, given its faster hard drive, but the extra RAM on the laptop appears to more than compensate for the lower RPMS of the disk (4200 versus the desktops 7200), at least as far as Evolution is concerned.



When Evolution fails (and so far this is only on the DX260, but not the D620), it is always the MS Exchange connector that is failing. The main Evolution client stays up and running, but without access to the MS Exchange server, that is not very useful. I guess I really should say it is not useful unless you have other email protocols still up and running in any case. If you have Evo set up with IMAP, POP and other email protocols, the failure of the MS Exchange backend would only affect that one mail store, leaving the others to process email to their hearts content. I have in fact set up Evo from time to time to use IMAP and WebDAV-I.E,-Connector to the same mail store, so that when Evolution Connector fails I can still read email until such a time as it is convenient to blow out of Evo and run my cleanup scripts and restart Evo. That only works if you MS Exchange server is set up to run IMAP as well as the murky MAPI-plus-RPC protocols though at the same time though.



Based on the fact that it is working fine on my D620 I infer that my Dell 745 would run Evolution under 8.04 without issue, but will wait for Mint 5.0 before I do anything OS re-configuring there.


IM trying



Another of the suboptimal areas of MS Infrastructure that I have to deal with is our current IM standard.  MS Office "Communicator". Quotes because, like "Sharepoint", it only really works *at the moment* if you are running an MS sourced desktop. IE: you can communicate or share only if you are of the MS Windows population of computer users. Its like starting off a collaboration project by telling a part of your contributing population "we don't want to hear from you, because you think differently"



The Pidgin project is working on getting a SIP client going that will inter-operate, but I have had no luck to date with it, and neither have several of my Linux using compadres.



The good news is that unless I am running MS Windows someplace, like a VM, I do not have to deal with getting IM's. IM if hot hot hot out there, but for me it maps to YAIV: Yet Another Interruption Vector. Unless I need it for real time problem diagnosis, I tend to stay out of it.


Coming Soon



Ubuntu is out and looking good (even if Evolution needs a pretty stout system to run well), but that is only the beginning of the spring season. Still up are Mint 5.0, which of course is Ubuntu 8.04 polished to a fine sheen, Fedora 9, and OpenSUSE 11. More on those as they go GA.

Filter Blog

By date:
By tag: