Moving an old SCO Unix Filepro box


2012/08/15

A few days ago I received an email from someone looking for help with an old SCO Unix system.

I have to tell you the truth: I turn down a lot of that work now. If the proposed work is at all messy - for example, virtualizing an older version or porting code or resuscitating a piece of ancient hardware - I usually say that I'm not interested. When I say not interested, I mean REALLY not interested: I've had people come back to me saying "Name your price!" and I still turn them down. I might need the money, but I don't need the stress.

Of course I'll still help any of my "old" customers - the folks who haven't been able to move off SCO. There are darn few of them left and honestly I'm getting closer to the time when I'll express my regrets to them also, but for now it's new work that I'm most apt to reject.

This particular piece of email tugged at my conscience, though.

The sender explained that the Filepro system was running on SCO Unix 5.0.7 and that her employers had decided to remove it entirely, which made her job particularly difficult as the replacement Windows system simply didn't do what the old wheezy Filepro system did. Somehow she convinced them to give her the hardware and she was going to install it in her home office, thereby allowing her to continue to do whatever she does without excessive teeth gnashing and frustration.

So far, so good. There were, however, a few interesting wrinkles.

Comcast Business Class

Her email explained that the company had also agreed to install a Comcast Business Class internet connection, with a public IP, in her home. This was because there are other employees who will still need to access the Filepro.

Yeah, I know: you are asking why they would scrap the system if people still have to use it. I don't know.

Anyway, she went on to explain that she (apparently with some help from another consultant or two) had tried to configure the SCO with the public IP she had been given, but it simply was not working at all. Someone had steered her in my direction. She ended by explaining that her company would NOT pay for my help; she'd have to do that herself.

Finally, she already had a high speed connection and would not be giving that up - the SCO would use the Comcast; her home office computers would not.

Damn conscience

Alarm bells were going off in my head. Connect a SCO 5.0.7 system to the Internet with a public IP? No, no, no.. this version was replaced in 2005 - it's ancient and it wasn't all that secure even then. It's probably good that she was having trouble - the darn thing should be behind a firewall!

I also felt badly that other people had let her down. I don't know if she paid them, but even if not, she still had to be frustrated by not having this working. I sighed and wrote back that I'd be happy to help and would charge her a flat $60 (my minimum charge). We arranged a time to tackle this the next morning.

Correct but wrong, wrong but correct

When we talked on the phone that morning, I explained my concerns about security. We set up a "join.me" session and she showed me what she had done for configuration. It was actually correct: the only change I would have made is to use Google DNS in resolv.conf. "Correct" doesn't mean working, though, so I asked her to switch her Windows PC into one of the Comcast router ports to find out why.

As I expected, the Comcast SMC router was handing out DHCP and the PC obtained a 10.1.10.x address immediately and had Internet access. Nothing wrong there, so all we needed to do was try DHCP with SCO. We did, but it didn't work, and ended up with a 192.168.2 address - oops!

Hmmm.. after some fumbling, I decided to put a specific 10.1.10 address on the SCO with a gateway pointing at the 10.1.10.1 router and Google DNS in resolv.conf. That didn't work though, and the indication was that no cable was plugged in. And yet, she insisted it was and that she could see lights both at the computer and the router. What the heck?

A quick scan of "hw -r pci | more" told me the problem: the system had an Intel ethernet on the motherboard, but we were configuring a PCI 3-Com in netconfig! She had plugged into the wrong ethernet jack!

She crawled under her desk and rectified that. The SCO could now reach the Internet. There were a few more things to be done, of course.

Securing it

I asked her to modify /etc/ssh/sshd_config to add an "AllowUsers" line for the handful of people who need to access this. She assured me that they all have strong passwords - of course I'd rather see them use key files, but that's probably too much to ask. There are other things she could and should do with ssh configuration, but I let it go. I'll send her an email about all that later and perhaps she will do more.

I then had her login into the SMC router (default "cusadmin/highspeed" - I advised her to change that later) and led her through forwarding port 22 to the 10.1.10 address I had her assign to the SCO box. I then had her disconnect from that network and reconnect to her own and try an SSH connection.

It didn't work.

Reconnecting to the router showed me why very quickly: Comcast had NOT configured her router with the public IP address they had sold her. I had her go try the public DHCP address and of course she was able to login with ssh. I told her to complain to them and make them fix it - I didn't want to mess things up if they had not completed provisioning that. I told her to insist that they stay on the phone with her while she power cycled all equipment: SCO, router and Comcast modem to be sure the public IP still worked after that.

Happiness is a working system

At this point, she had a working system and was a lot happier than she had been. I sent my $60.00 invoice and my conscience felt reasonably assuaged. I thought about advising her to switch to Linux, but she seems to be active in what is left of the Filepro community, so someone else has surely told her that. I've done what I could and I hope she stays safe.



Got something to add? Send me email.





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

Printer Friendly Version

-> -> Moving an old SCO Unix Filepro box


10 comments



Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Anthony Lawrence







Thu Aug 16 14:33:39 2012: 11241   BigDumbDinosaur

gravatar


the only change I would have made is to use Google DNS in resolv.conf.

Why?





Thu Aug 16 14:40:41 2012: 11242   TonyLawrence

gravatar


Because it's usually faster and more reliable than ISP's DNS servers and I suspect that's ALWAYS true with Crappy Comcast.



Thu Aug 16 14:44:11 2012: 11243   Tony

gravatar


Here some recent tests:

Fastest individual response (in milliseconds):
----------------------------------------------
SYS-68.105.28.16 ########### 11.06095
Qwest US ############### 15.65194
Verizon NYC-2 US ############### 15.77997
Level3-R1 ################ 16.16406
Level 3/GTEI-3 ################ 16.63113
UltraDNS ################ 16.80708
UU NYC9-6 US ################# 17.36999
OpenDNS-2 ##################### 22.54200
Google Public DN ###################### 22.67814
DynGuide-2 ###################### 22.96090
SYS-68.105.29.16 ##################################################### 56.94199

Mean response (in milliseconds):
--------------------------------
Google Public DN ###################### 52.56
Qwest US ####################### 53.88
OpenDNS-2 ########################### 62.93
UltraDNS ############################ 65.28
Verizon NYC-2 US ############################## 70.36
Level3-R1 ############################### 72.56
SYS-68.105.28.16 ############################### 72.81
Level 3/GTEI-3 ################################### 83.05
DynGuide-2 ######################################### 97.36
SYS-68.105.29.16 ############################################## 110.36
UU NYC9-6 US ##################################################### 127.91



Fri Aug 17 15:25:23 2012: 11247   BigDumbDinosaur

gravatar


Because it's usually faster and more reliable than ISP's DNS servers and I suspect that's ALWAYS true with Crappy Comcast.

No argument on that, except I wouldn't give Google the time of day, let alone an opportunity to serve an IP address that may not be the one you should have gotten. Google is the king of redirection and, in my opinion, not at all trustworthy.

On the servers we build and configure, resolv.conf is set to point to 4.2.2.2 and 4.2.2.3. There's no question about the authority and reliability of those two top-level DNS servers. Performance is never an issue, as it isn't a case of climbing up the DNS pyramid, only to climb back down to reach the server that is authoritative for the domain being resolved.



Sun Aug 19 14:04:02 2012: 11249   ClintonPownall

gravatar


Tony, We still do a lot of SCO support. So if you get one of those requests where you do not feel like doing the work send them our way. I'll give you a referral fee as you already know from a while back. www.SCOService.com is the website we use for SCO services & support. I can be reached directly @ 407-654-5600.

-- Clinton



Sun Aug 19 14:08:16 2012: 11250   TonyLawrence

gravatar


I don't recommend anyone I don't know personally and well, sorry.







Wed Sep 5 15:01:18 2012: 11269   NickBarron

gravatar


Its a funny old world. I would of thought you get some satisfaction with helping people either move off the box or keeping it running for longer?

How did you get onto the box originally before it had a network connection?

I too cannot bring myself to use 8.8.8.8 unless an emergency is afoot. 4.2.2.2 haven't seen them for a while :)






Wed Sep 5 15:53:03 2012: 11271   TonyLawrence

gravatar


My empathy has limits :)



Tue Sep 18 23:30:45 2012: 11337   anonymous

gravatar


You nevertheless need to watch out when using Google's DNS (or any open DNS server, for that matter). Here's what happened to me. I was initially using my ISP's DNS servers; then I switched to Google's. What I noticed not long after that was that certain sites I visit had really poor availability (Facebook, various video streaming services, etc.). In a nutshell, my machine asked for the IP for www.facebook.com. Google's DNS asked Facebook's DNS, which based its answer on the location of the requesting IP (8.8.8.8, in my case). 8.8.8.8 is in Mountain View. So Facebook's global load-balancing system gave back the IP of a server closest to Silicon Valley. So, in essence, I was backhauled all the way across the country and was getting sporadic routing issues. Once I switched back to my IPS's DNS, www.facebook.com resolved to a much closer, more available host, and I no longer experienced any issues. Watch out for that.



Tue Sep 18 23:52:48 2012: 11338   TonyLawrence

gravatar


I have never seen that. I see your point, though in fact google uses resolvers near you:

For closed resolvers, this is not really an issue. For open resolvers, the closer your servers are located to your users, the less latency they will see at the client end. In addition, having sufficient geographical coverage can indirectly improve end-to-end latency, as nameservers typically return results optimized for the DNS resolver's location. That is, if a content provider hosts mirrored sites around the world, that provider's nameservers will return the IP address in closest proximity to the DNS resolver.
.

See (link)

------------------------
Kerio Samepage


Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

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





Computers have been taught to distrust each other and will reject attempted connections most of the time. Nowadays, most computers and firewalls are utterly rude about it: it would be like asking someone to dance and having them ignore you as though you were invisible and inaudible. (Tony Lawrence)

Your computer needn't be the first thing your see in the morning and the last thing you see at night. (Simon Mainwaring)








This post tagged: