SCO Unix ® section

SCO 5.0.7V

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.

6 comments

More Articles by Anthony Lawrence - Find me on Google+

Click here to add your comments




Sat Feb 20 18:47:02 2010:   SteveSmith


Hi Tony,

Thanks for the timely article. I've got a potential customer with a similar situation, but I've been a bit reluctant to dive in.

The thing about Vmware is that so many people expect hardware level performance when in reality it's the hardware layer plus a software abstraction layer. I'm not surprised when things slow down a bit.

As I understand it, the SCO VM instance is licensed on a yearly basis through SCO. I'm curious if your customer had any issues with that? I would imagine that they owned their previous version.



Sat Feb 20 18:56:21 2010:   TonyLawrence


As these systems are often running on older hardware, the VMware can actually be an improvement. It was here - reports that formerly took 20 minutes to run now complete in 13 minutes.

As to the licensing, no, that wasn't an issue. It's reasonably priced.



Wed Jun 9 12:32:31 2010:   Skully


So now we are faced with the job of making backups to store offsite.
It is my understanding that tape drives are not supported with 5.0.7V.
Are we to make backups to files and FTP them for storage?
BTW, thanks for the great info, you've saved countless lives and systems with this website!



Wed Jun 9 13:35:57 2010:   TonyLawrence


I strongly recommend using Microlite BackupEdge to backup to FTP servers.

You can download a fully functional demo from http://www.microlite.com and when you are ready to buy, I can save you money on the purchase.



Tue Jan 4 15:42:54 2011:   LindaR


Thanks for a great article. We have a client entertaining the idea of moving 2 existing 5.0.7 servers to VMware. Possibly a naive question, but I've been unable to find this answered anywhere. Will 5.0.7 executables run under 5.0.7v?



Tue Jan 4 15:57:09 2011:   TonyLawrence


Yes, 5.0.7v is 5.0.7 as far as apps are concerned.

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.