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.
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.