APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Another one bites the dust

© November 2007 Anthony Lawrence

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 https://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
nmblookup -A

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://

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.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Another one bites the dust


Inexpensive and informative Apple related e-books:

Take Control of High Sierra

Take Control of Automating Your Mac

iOS 8: A Take Control Crash Course

Take control of Apple TV, Second Edition

iOS 10: A Take Control Crash Course

More Articles by © Anthony Lawrence

Related Articles

Tue Nov 27 14:42:25 2007: 3277   BigDumbDinosaur

Why on earth to people insist on buy that Dell crap? Is the public that brainwashed?

Tue Nov 27 19:18:30 2007: 3278   TonyLawrence

In this case I suspect it was because Dell leases it to them..


Printer Friendly Version

Related Articles

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

If you don't know anything about computers, just remember that they are machines that do exactly what you tell them but often surprise you in the result. (Richard Dawkins)

Linux posts

Troubleshooting posts

This post tagged:





Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode