Another SCO Unix Filepro System Bites The Dust
I spent most of yesterday on the phone helping another consultant port a SCO Unix Filepro system over to Linux.
Actually, we had started this more than a month back but ran into a Filepro snag: she had done all her menus using a product called Softa, apparently no longer in business, so although we did an initial transfer then, she had to re-write some menus before we could bring it live.
The Linux was SUSE Linux Enterprise Server 10, which caused me more than a little confusion because I had it firmly in my mind that it was RedHat ES and kept looking for RedHat utilities that of course were not there.
I transferred data by FTP, including user home directories, and used my script at http://aplawrence.com/SCOFAQ/FAQ_scotec1ilinuxpass.html to bring over password info. At that point we were technically "working", but some problems remained.
The first was that I had installed Microlite Edge and had tested it previously, but now it was failing with a library error. And although Filepro was still happily working, the consultant "on the ground" told me she no longer had a GUI screen. I tried restarting xdm and saw that it too was failing complaining about libraries. Huh? Well, there apparently had been an automatic system update since I had installed Microlite, maybe it just needed a reboot? Nope, that did not help. Crossing my fingers and wishing heavily, I ran "ldconfig" and bingo, everything started working again.. I rebooted once more just to eliminate any remaining issues and all was fine.
The next issue was printers. On the SCO system we had one parallel printer, one serial, and several Windows printers handled through Visionfs (a Samba-like product that SCO used). The parallel was no problem, but the consultant physically on site insisted there was no serial port on the new machine. I insisted that couldn't be true, because I could see it in /proc/ioports, and frankly, given that it was a new Dell, I was surprised to find parallel, but surely there had to be serial. No, she insisted again. OK, we'll move on and come back to that: let's set up the Windows printers
I had her switch to the GUI on ALT-F7 and look for the System Menu. She couldn't find it. I assumed that the monitor must be out of adjustment and tried leading her through manually adjusting it - that didn't seem to help, but eventually she did find the right menu. I probably wasn't helping as I still had RedHat firmly in my head, but anyway, there we were and I led her through adding the first Windows printer - I had already done the parallel at the command line with "lpadmin".
The printer did not work. It timed out trying to reach the host, and eventually disabled itself. As the host was ready and waiting, and still printing from SCO, that seemed odd. More than odd, because if there was any odd little network issue, you certainly wouldn't expect SCO Visionfs to work where Samba doesn't.
I don't like to print through Samba anyway; I'd rather have print servers, but I dug in and immediately got into oh-so-weird land. The first thing I did was restart Samba, and ta-da, the printer worked. Once, and then it timed out again. I added another printer at the command line and that worked three or four times and then also timed ot. What the heck?
I did nmblookups:
nmblookup -A 192.168.1.8
nmblookup -A 192.168.1.9
and the results were unsettling: apparently randomly sometimes I would get a correct response, and other times it would say "No reply". Same symptoms for smbclient; if "smbclient -N '//bobv/boblabel'" connected, of course I could "put" a file and it would print. But most of the time it would not connect.
It didn't seem like Samba was at fault because it could happily talk to the Visionfs still running on the SCO. But it couldn't be the network, because Visionfs could print reliably. Maybe somehow Visionfs was interfering and confusing things? I shut it off and rebooted the Windows boxes; no change.
Well, darn it, this won't work. And there is still that serial printer to deal with - aw, the heck with it: I sent them out to buy print servers.
While someone was off doing that, the Filepro consultant complained that Filepro didn't work well in the GUI and looked nice in a character login except for the fonts were too small. I looked in /usr/share/kbd/consolefonts and saw a "suse12x22.psfu" (which was when I finally accepted that no, this really is not RedHat). I edited /etc/sysconfig/console to use that:
and then did "/etc/init.d/kbd reload" and all was fine. We spent a few minutes talking about cron and how different it is from SCO, and I warned her about commands like "sort" that take slightly different flags, and by then the print servers had arrived. These were Linksys PSUS4 models, which made me a little nervous, but once they had IP addresses, it was dead simple:
lpadmin -p purchasing -E -m raw -v lpd://192.168.1.13/LPT1
and so on did the trick instantly and happy printing ensued. Print servers are a better idea than Windows CIFS printers anyway, so I wasn't unhappy about this, but I do wonder what the heck is going on with Samba.
Just about then, disaster struck. The consultant on site reported that the console had gone completely dark - looked like the monitor was unplugged, she said. Well, maybe it is, I suggested. Nope, all tight and happy and powered on. Hmmm. Try the monitor from the old SCO? Nope, same symptoms. OK, let's shut her down and power cycle it.. nope, still dead as a doornail.
Arrgh.. this was toward the end of the day and neither of us needed it. I brought it down once more and we left it powered off for five minutes - after this rest, all came back up fine, which makes me very suspicious of a bad video card, which of course is on the mother board. I warned her that this is probably going to bite them again and they might as well get a call into Dell about it. No doubt Dell will say it's Linux, but that should be easy enough to disprove: just boot from any old Windows CD and if it's still dead, well, that proves it.
The consultant did say that her Filepro reports are now blindingly fast compared to the SCO. Part of that is just newer hardware, part is from newer Filepro binaries, but most of it is Linux doing aggressive disk caching. It certainly does make the day easier, though.
So, yet another SCO box heads for recycling. It did serve them well for many a year, but it is time to move on.
*Originally published at APLawrence.com
View All Articles by A.P. Lawrence
Our Daily Email of Breaking eBusiness News
About the Author:
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com
WebProNews RSS Feed
More Expert Articles Articles