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
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.
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Anthony Lawrence
Find me on Google+
© 2012-07-02 Anthony Lawrence