Although many an old SCO box has been replaced by Linux or (shudder) Windows, many others still chug along in server rooms across the country. Sometimes the server remains alive because of stubbornness, sometimes it is just rank ignorance, but more often it's simply that any replacement is economically difficult. The SCO server is kept alive because the company using it can't afford any alternative.
I have a number of resources here about converting or maintaining SCO systems.
Most of these old systems run on SCO's 3.2v5 operating systems. These date from 1995 (3.2v5.0.0) to 2003 (3.2v5.0.7), so the newest of them is seven years old and are often running on hardware of the same age. Never mind security, operability or anything else: it's downright scary to be running on hardware that old. Unfortunately, installing SCO on anything current can be difficult or even impossible as driver support melts away.
As of this writing, it is still possible to install SCO 5.0.7 on generic hardware but when you start getting into RAID systems it can be very hard to find drivers and even network cards can cause some difficulty - it's all become nasty enough that I refuse to do any such work on anything but a flat time and materials basis with no guarantees of success. If the system is older than 5.0.6 and can't be upgraded to at least 5.0.7, I may refuse it anyway - it's just too unpleasant. Life sucks for old SCO owners.
SCO has made things a bit easier by providing SCO 3.2v5.0.7V, which is a VMware image - that is, it's not an operating system installation disk, it's an image of an already installed (partially unconfigured) SCO 5.0.7 system. That's important because it means you don't "install" the OS within VMware, you "import" or (depending upon your flavor of VMware) "deploy" it. After VMware is done bringing it in, you boot it and it asks for the system configuration info needed - see all this at the 5.0.7V for VMware Getting Started Guide.
I was involved with one of these earlier this week. The customer had an old Compaq running a Synergy DBL system under SCO 5.05. I was simply contracted to install the SCO (their VMware vendor had attempted part of that but didn't realize that the CD was a VM image) and to transfer data.
This was a fairly easy process. I transferred users using "ap" (see SCO Unix Upgrades for more on that and other upgrade issues), tarred up their home directories and transferred them with "rcp" after establishing user equivalence.. I suppose I could have taken the trouble to install ssh on the old system, but why look for trouble? The old "rcp" works.
To establish user equivalence, the simplest thing is to login to the new server from the old. Do a "w -x" to see the source of your login - it will either be an ip address or a name. Whatever it is, put that in /.rhosts and chmod 600 /.rhosts. You'll then be able to rcp from the old to the new.
We added a second drive which was actually a NAS. VMware abstracts that as scsi id 1, so SCO doesn't know that this is actually a network device. However..
While transferring data, I observed WRITE_10 errors. Specifically:
Mon Feb 15 15:47:11 2010 WARNING: "WRITE_10" command timed out 12 seconds after its start on ha=0 id=1 lun=0 Request=C102F6A0 WARNING: "WRITE_10" command timed out 12 seconds after its start on ha=0 id=1 lun=0 Request=C1035B80
The VMware consultant expressed no interest whatsoever except to observe that we were hammering heavily transferring data and that he was trying to install Exchange on the same NAS concurrently.
OK - color me naive, but if you can't transfer data to one VM while installing another, is this really usable? I would think not, but what do I know?
After the Exchange install finished, we didn't see any more problems. Until two days later, that is:
Wed Feb 17 09:19:13 2010 WARNING: "WRITE_10" command timed out 12 seconds after its start on ha=0 id=1 lun=0 Request=C102F100
That upset me. but it turned out that the VMware folks had needed to take the NAS down at about that time. You'd think they would have realized that no operating system likes its drives disappearing, but they did not mention this until I sent email to the customer's IT person warning about the error. I'm left HOPING everything is in fact as it should be - I'm not completely confident.
But - maybe there WAS something misconfigured, maybe that's why they bounced it, maybe I'm worried for nothing. I left instructions for checking /usr/asdm/messages and with luck they won't see that again.
We did have a minor issue with Synergy. On the old system, all that stuff was installed under /usr/asa/synergy. Apparently new binaries were needed to transfer to 5.0.7, and these were all installed in /usr/asa/synergyde. As there were an unknown number of scripts referring to the old paths, I created a symlink: ln -s /usr/asa/synergyde /usr/asa/synergy to fix that.
Printers were easy as these were all netcat printers. I simply rcp'd the interface scripts to /usr/spool/lp/model and than ran lpadmin for each printer:
for i in printer1 printer2 printer3 do /usr/lib/admin -p $i -m $i -v /dev/null /usr/lib/accept $i enable $i done
I transferred the mmdf information and was able to send mail. There were some cron entries I extracted from "crontab -l" and added them to the new machine. That was about it for me. I headed home and sent them my bill.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Anthony Lawrence © 2012-07-12 Anthony Lawrence
The successful construction of all machinery depends on the perfection of the tools employed; and whoever is a master in the arts of tool-making possesses the key to the construction of all machines... The contrivance and construction of tools must therefore ever stand at the head of the industrial arts. (Charles Babbage)