APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

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!



Got something to add? Send me email.





(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Converting SCO to Linux - Another one down, two left


5 comments



Increase ad revenue 50-250% with Ezoic


More Articles by © BigDumbDinosaur







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

gravatar


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





Tue Apr 5 14:51:33 2011: 9429   BigDumbDinosaur

gravatar


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.



Sat Oct 12 01:31:00 2013: http://bcstechnology.net12350   BigDumbDinosaur

gravatar


In the time since this article was posted in April 2011, one of the two clients mentioned had us switch them to Linux. The system cut-over was in June (2013) and all traces of SCO OSR5 have been eliminated. To say that they are astonished at the performance increase would be an understatement. The new Black Lightning server is a single AMD Opteron processor unit, but with quad cores. Linux reports a BogoMips of 22,000.

The one remaining client continues to experience slow business problems but has asked for a formal quote to be used for planning the 2014 budget.

Meanwhile, we still have a SCO box running on our network, but it has been relegated to menial duties, as I switched us to Linux to support the Windows clients support a few weeks ago. This Linux box is gross overkill, a dual processor AMD beast using dual core processors, and all SCSI storage (even the DVD drive). It runs the 64 bit Linux 3 kernel and a 64 bit Samba build. Its performance is well beyond what we need, but it's a good showpiece for demonstrating to clients what the Linux/Samba environment can do for them. :)



Tue Apr 14 17:28:33 2015: http://bcstechnology.net12659   BigDumbDinosaur

gravatar


Fast-forward to April 2015 and that final OSR5 installation has been converted to Linux, leaving us with no more clients running on SCO anything.

This final conversion coincided with a hardware makeover, resulting in more gross performance overkill. The 8-core AMD Opteron comes up with a BogoMips of nearly 45,000, making it the fastest uni-processor server we have ever shipped. This machine is running on SuSE Linux Enterprise SP3, which ships with the the 3.0.76 kernel. Windows support comes from Samba 3.6.24, which we build from (slightly modified) sources.

The only SCO box now remaining under our purview is the server sitting under my desk, which isn't seeing much use these days. I do use it for some engineering work unrelated to computers, but that's about it. Ironically, if SCO Group hadn't shot themselves in the foot with their "Linux stole our code." lawsuits, we might still be offering SCO OSR6 as an option on our new servers. However, given the state of Linux development at this time, why bother?



Tue Apr 14 17:33:02 2015: 12660   TonyLawrence

gravatar


Indeed, why bother?

Dumb management at SCO killed them. They deserved it.

------------------------
Kerio Samepage


Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us





640K ought to be enough for anybody. (Bill Gates)

Anyone who puts a small gloss on a fundamental technology, calls it proprietary, and then tries to keep others from building on it, is a thief. (Tim O'Reilly)












This post tagged: