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

A SCO Openserver to Red Hat Linux Conversion

© April 2011 Bill Mohrhardt

Bill Mohrhardt

Any regular visitors to Tony's site know that he "encourages" users to get off of SCO and onto Linux. Well, our company had been running our integrated software, written in Providex (a Business BASIC variant) for many years, and finally it was time. Before telling the tale though, I just wanted to say a couple of nice things about SCO. I certainly don't agree with their litigation-as-a-business-strategy, but their OS did run our software very well with a minimum of problems. We started with 5.0.0 way back in late 1996, and had 5.0.7 running up until a couple of months ago. Here is how it went :

Step 1 : Serial Terminals from C/X Concentrators onto Portservers

This phase started before the server change, as Digi still provided SCO Openserver drivers for Portservers. Our existing C/X concentrators were linked throughout our site using Digi's Fiber-Link devices, which communicated over fiber at 1.2 Mbaud. I was looking to buy a spare pair of Fiber-Link devices, and learned that they were no longer available. So I researched the Portservers, and decided to move over to those, as we already had network switches at each fiber end-point anyway. That went well, and the Portservers worked well, but I had a funky problem with the Zebra label printers that were connected via the terminal's Aux port. They would somehow lose their handshaking, and would not come back even after resetting the Portserver. Luckily, most of the printers were the S4M model, which have a 9-pin female serial port. So I purchased some RJ45-DB9 adapters, and set up the printers with their own serial line. The nice thing about getting away from the C/X series, was that no host card was required. Also, If we had one server down, I could execute the drgp_cfg_node command from the other server, and provision the terminal sessions from the other site.

Step 2 : The Server Hardware Story

This ended up being a longer phase than I would have liked. Back in 2006 when we upgraded hardware from HP servers to IBM xseries 226 servers, I knew that the motherboards could accept 2 CPU's, and knew that when I upgraded to Linux I would make both servers dual CPU. At the same time, my RAID device vendor told me that they would no longer offer maintenance contracts, as our 36 GB SCSI drives were too old, and getting difficult to obtain. So, I found an excellent IBM reseller (findibm.com), and bought the 2nd CPU's, along with 2 IBM ServeRAID 6M controllers (made by Adaptec), and 2 pair of 73GB 15K RPM SCSI drives, with the carriers for the hot-swap backplane. So I planned to install Red Hat on the internal SCSI drives, and leave SCO on the external RAID array, thinking that I could freely move back and forth between the two OS'es as I was working on the upgrade. Also, the cost of the new hardware was less than it would be to keep the maintenance agreements on the external RAID arrays.

I installed the 2nd CPU, and the RAID controller, and the SCSI drives one fateful weekend back in July. Now, the mistake I made (one of them anyway), was that I did not update the BIOS prior to installing the 2nd CPU. So I got into a bad chicken versus the egg loop where the server would not boot up, as the old BIOS thought that the CPU's were at 2 different speeds. However, when a server believes that the CPU's are at 2 different speeds, you cannot reflash the BIOS either. After many attempts with the help of the IBM technical people, I had to give up, and remove the 2nd CPU, then update the BIOS, then re-install the 2nd CPU. I got to know the inside of the server quite well.

The server would now boot with the 2 CPU's, and I then installed and configured the RAID array as a simple RAID 1, and started installing Red Hat Enterprise Linux 5.3. That part went very well, and I even loaded some of the other software, including a demo version of Providex, ftp'ed some data files over, and ran some testing. It all went very well. So, at this point, it was about 11:30 PM on a Sunday night, so I figured I would re-boot the machine under SCO, and actually go home.

Well, as it turned out, the new BIOS, which was necessary for the dual CPU setup, did not like the combination of the SCSI card for the old RAID array, and the ServeRAID card. No matter what BIOS settings I changed, I could not get it to boot from the old RAID array. This of course, was a problem, given that people would be coming into work the next day. Once again the IBM techs were very helpful, and we tried everything under the Sun, but ultimately I had to remove the ServeRAID controller to get the machine to boot from the old RAID array. It was at this point that I realized that I needed a 3rd machine if I was to do these upgrades on our 2 existing servers. So, I ordered the machine with an identical configuration (and the BIOS update already installed). Long term this would be a better idea anyway, as once both servers were upgraded, I would have a hot spare machine, and could therefore drop the Hardware Maintenance Agreements on the 2 live machines. The cost of the 3rd machine would be recovered in 18 months' worth of Maintenance.

Step 3 : Software Additions and Changes.

The majority of this phase was already taken care of, as version 9.10 of Providex was already set to run on Linux. Our applications are still text-based, but Providex allows us to use windowing and colors, so it doesn't look too dated. Most of our data entry requires a keyboard anyway, so the utility of a mouse is diminished somewhat. We did not have to make any changes to the code, which was nice. We upgraded BackupEdge from 2.x to 3.x, and software for our APC UPS units was just a download. The major change was moving from Facetwin to Samba. Facetwin provided both access to our shared drive, as well as a snappy terminal emulator for the Windows clients. We purchased licenses of PowerTerm Lite from Ericom software for the Windows machines, actually installing those prior to the server upgrade. The share drive would now be provisioned via Samba, which is open source, so the zero upgrade cost for that item was nice. One thing that we did to simplify (so we thought) the setting up of the shared drive, was that we specified the User Id when creating the accounts on the Linux box, so that they matched the User Id numbers from SCO. Looking back on that now, we would have been better off just making new User numbers, and doing the chown - R and chgrp -R on the home directories. Linux sometimes gets a little fussy when User Id's are low numbers. Needless to say, the access to the shared drive is much quicker on Linux than it was on SCO, mostly due to the fact that Linux manages memory much better, and the dual 3.0 Ghz CPU's don't hurt either. Now that we are using Samba, we can change our Linux stations away from RHEL 4 onto Ubuntu 10.10. As we do this, we are creating new User Id's so that the stations and the server match, and we are keeping them consistent for users that have access to a share on both servers.

Editor's note: See maximum uid (SCO, Linux)

I had to change the remote access method, as I could not figure out how to setup a dial-in modem. There were many helpful articles on dialing-out, but I guess RHEL 5 assumes that everyone has a high-speed connection to login with. As it turned out, setting up ssh-2 was simply a matter of changing our firewall settings, generating ssh keys for each home machine that needs access, and writing the Public key to /home/user/.ssh/authorized_keys2 on the server side. When we set it up the first time, we did not restrict the incoming IP addresses. So I had a virtual United Nations of hackers trying various logins, obviously using scripts. Eventually, I called our vendor back, and we made the firewall only accept ssh connections from specific IP addresses. Moving to ssh allowed me to drop my 2nd telephone line at home, which was a nice plus. On ssh, I get not only a much faster connection, but I can have multiple sessions open with no degradation in speed.

We also changed from VSI-Fax to HylaFAX. Once again, the open source pricing model made this move attractive. Also, HylaFAX allows us to FAX a .pdf file directly, which our (extremely old admittedly) version of VSI-Fax did not. The new version of Providex allows us to create a .pdf directly from our application programs, so we were able to make our outbound documents look snappier. I also really like the fact that we can send a .pdf file to the print spooler directly via a command line. We also had an old version of WordPerfect running on the SCO boxes. We simply converted those documents over to OpenOffice.

So, to sum it up, the conversion went well, although it took longer than planned. I had the good fortune that our existing SCO servers continued to work without problems throughout the entire process. Going forward with Linux though, we will be better able to take advantage of new hardware options. The user desktop machines that we have moved from RHEL 4 to Ubuntu 10.10 work very nicely, and, given the same hardware, work more quickly. I was also able to drop some Hardware Maintenance Agreements, and saving money is a good thing.

Got something to add? Send me email.

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

Printer Friendly Version

-> A SCO Openserver to Red Hat Linux Conversion

1 comment

Inexpensive and informative Apple related e-books:

Are Your Bits Flipped?

Take Control of High Sierra

Photos for Mac: A Take Control Crash Course

Take Control of the Mac Command Line with Terminal, Second Edition

Take Control of Automating Your Mac

More Articles by © Bill Mohrhardt

Sat Apr 2 14:56:37 2011: 9419   TonyLawrence


It has been a long road, hasn't it? I had many a conversation with Bill during this process..

If those Linux clients ever HAVE to talk to a Window server, see (link) so as not to have to dump them..


Printer Friendly Version

Have you tried Searching this site?

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

Printer Friendly Version

Within C++, there is a much smaller and cleaner language struggling to get out. (Bjarne Stroustrup)

Linux posts

Troubleshooting posts

This post tagged:










Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode