Converting SCO to Linux - Another one down, two left

BigDumbDinosaur
BCS Technology Limited
Web Site: http://www.bcstechnology.net

A few weeks ago, we switched a client from SCO OpenServer Release 5 (OSR5) to Linux. This particular client is a busy law office that handles wills, trusts, estates and other "wealth maintenance" legal matters. The "lawsuit business," as I sometimes call it, produces huge numbers of documents, sometimes running to hundreds of pages each. This client scans all paperwork into portable document format (PDF) files for storage. Microsoft Word is used to prepare new documents and once they have been finalized, the Word files are converted to PDF for publication, as well as for long-term safekeeping. Hence a lot of storage is needed, as well as ample processing power to manage the storage.

The server, one of our Uni-FI Black Lightning models, is a dual AMD Opteron box, using dual core processors, effectively seen by Linux as a four-way machine. As RAM is like money (there's no such thing as too much), the box has 16 gigs of it, with room for plenty more, allowing all running jobs to remain in core at all times with the expected load. Excepting the DVD/CD reader, the machine's mass storage subsystem is 100 percent SCSI and includes multiple hard drives, as well as an LTO-2 tape drive (200 GB uncompressed on a single cartridge) for daily backups. We use the x86-64 version of SuSE Linux Enterprise, installed from DVDs that we burn here using freely downloadable ISO images. Linux reports a bogomips in excess of 5000 on this machine, so it's pretty fast. I've "tuned" the kernel to increase the total disk buffers over the usual level, which has the effect of increasing the perceived IO-bound performance.

Interesting aside about hardware: a file and print server is best optimized for IO-bound performance, rather than compute-bound performance. Achieving the latter is actually relatively easy to do with today's processors, without incurring a lot of expense. However, IO-bound performance is very much limited by raw disk performance. You can't do much about that except to utilize disks that feature low latency and seek times. Despite the big push in recent years toward SATA (serial ATA) disks, SCSI (small computer system interface) drives continue to lead in performance. SCSI mechanisms are generally faster and more rugged than the SATA equivalents, and the SCSI bus is consistently capable of higher throughput due to the characteristics of the bus protocol.

As just about every law office in existence uses Windows workstations, this server has Samba loaded to provide file and print services. Our usual practice is to build from source, as the compiled binaries available at the Samba site are often out of date (ditto for the RPMs maintained at various locations). Since this server runs a 64 bit kernel, we built a 64 bit Samba installation. This has some important operational ramifications, in that file size limitations associated with 32 bit versions are effaced. For example, it is possible with a 64 bit kernel and 64 bit Samba to image a PC workstation's entire hard drive into a single file using Norton Ghost, something which is not possible with the 32 bit environment of OSR5.

Prior to delivering a server to a client, we do as much configuration to the operating system as possible, which reduces the time required on site to get the conversion completed. In this case, the switch, aside from a bit of arm-wrestling with a Windows 7 box to get it to join the Samba domain, was largely uneventful and was completed over a weekend. The lengthiest part of the conversion was in transferring a huge amount of customer data to the new machine. That was done with SCP (secure copy), which all current Linux distributions include. SCP wasn't installed on the old OSR5 box but was available from my skunkworks repository that I maintain on one of our shop servers. Without SCP, the alternative would have been NFS, which is painfully slow, even when both machines are on the same subnet.

Since the conversion, the client has reported that they are pleased with the new setup and that a significant improvement in server response has been noted. The old OSR5 machine was reliable and had achieved uptimes well in excess of a year, but wasn't capable of the throughput produced by the new server. Although throughput is obviously influenced by the hardware itself, it has been our experience that the Linux kernel is substantially more efficient with IO-bound processing than OSR5. So some of the performance improvement can clearly be credited to Linux itself.

At one time we had many clients running on OSR5, as well as some on the even older SCO UNIX (which we started using in 1988). OSR5 is kind of like an old pickup truck: it doesn't go too fast, has a manual transmission, and lacks some of the features that come with the new models. However, OSR5 starts every time, is always is able to haul the load and doesn't break down at inconvenient times. Getting a client to switch away from OSR5 is not easy for the same reason light truck salesmen have trouble making a buck from people who won't purchase something just because it's new. Why would one want to get rid of an old truck that still does the job?

The problem, to continue with the pickup truck analogy, is that the manufacturer is no longer producing parts and all of their dealerships have closed down, or are selling that other brand of pickup truck called "Linux." Getting support for the OSR5 truck has become a trial of patience and meanwhile, the old beast is getting older, the clutch slips on occasion, oil leaks are getting worse, too much fuel is used for the performance gotten, and it is increasingly difficult to adapt the vehicle to present-day needs.

Our efforts to get clients off OSR5 and on to Linux commenced in earnest in 2004, which was right after SCO (then Caldera) started with their "Linux stole our code" lawsuits. The lawsuit nonsense definitely inspired me to get serious about Linux conversions, although I had been thinking about adopting Linux for live installations since the late 1990s, when I had spent quite a bit of time messing around with Red Hat on our "mule" server. I liked the way Linux worked, especially on older 486 hardware, and how I could transfer just about all of my UNIX knowledge and experience without incurring a steep learning curve. About 95 percent of what was in UNIX at the time related directly to Linux, and the remaining five percent was stuff that had to do with system configuration, networking differences and package management. Linux was clearly the wave of the future, although I was not particularly impressed with the Red Hat distribution (and I am still not impressed).

However, Linux was rough around the edges at the time, and while Tony and some others may have argued to the contrary, I did not feel Linux was ready for the sort of small (and I do mean "small") business installations that are our bread and butter. Working with the Linux of 12 or 13 years ago in a setting such as my business was okay -- we could deal with almost any problem that might arise. Subjecting a paying client to technical oddities was a different matter. Businesses use computers to get work done and don't want to be distracted by technical issues, as frequently occurs with Microsoft Windows. The system had to function without constant tinkering. Hence, other than cost per seat, the business case favoring Linux simply wasn't there back then.

Now it has all changed. A key factor for us was Novell getting involved with SuSE and adapting the latter's Linux package to the North American market. Novell, of course, was preeminent in the networked PC arena with their excellent Netware, and thus had the business pedigree that was needed to make Linux palatable to smaller businesses. Ergo we shipped our first production Linux server, based upon Novell's SuSE distribution, in 2004, and in 2006, shipped our first 64 bit dual processor (AMD) unit to a tool and die engineering firm. That one server replaced four Windows servers -- making it crystal-clear that Linux uses less "fuel" to haul the same load carried by Windows.

Since then, we have steadily whittled away at our OSR5 base until, with the installation I described above, we are down to two clients remaining on OSR5. I have made a sales call to one extolling the virtues of Linux on their next server, and they are interested. This client has asked for a quote to not only replace their existing OSR5 server (one of the few dual processor OSR5 boxes we have built) but to rewrite their custom vertical software package. The other remaining client and I have had some discussion on making the switch, but their business conditions are getting in the way of allocating capital to do so -- they have middleware that will have to be replaced at not-insignificant cost.

Once these two clients take the plunge and convert to Linux, there will be but one server left to convert, and that is our office file and print server, which still runs on OSR 5.0.6 and an equally ancient version of Samba. This box has been in service since November 2000, and other than one hardware upgrade performed in 2004, has been running around the clock (current uptime at this writing is 1,431 days). I haven't fooled around with it because, like an old pickup truck that is still running, OSR 5.0.6 continues to haul the load. However, I know that a day will come when the old beast will have to be sent to the junk yard, at which time my OSR5-to-Linux campaign will be completed and I can retire. Just kidding about the retirement part!

2 comments

More Articles by BigDumbDinosaur

Click here to add your comments




Mon Apr 4 14:51:39 2011: 9422   rbailin




The old saying about the cobbler's children going unshod comes to mind.





Tue Apr 5 14:51:33 2011: 9429   BigDumbDinosaur
http://bcstechnology.net



Or the doctor's kids that are always sick.

I'll have get to that server pretty soon, as the disks are nearly seven years old and past rated life. So their replacement can coincide with OSR5's replacement.

Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments

If you want a picture to show with your comment, go get a Gravatar

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.