This is a note from a customer who transferred SCO 5.0.7 over
the weekend. I had completely forgotten about CUPS, which
caused him quite a bit of grief.
By the way, he had considered moving to Linux, and had set up
test machines. He says it was "close", but had just enough
problems with Digi serial ports to convince him to
stay with SCO for now.
Yes, I did get the new server going. However, it was more work than
it should have been. was pretty much committed to getting the new
machine on-line, as there were production guys coming in at 5:00
A.M. on Saturday. And boy, were they surprised to see me! And
relenting and plugging the old box back in would have meant admitting
The transfer of the data went smoothly, I did cd /1 and rm -rf *
to clean the mount point, then did :
rcp -r -p narcoa:/1/* . Since that copied about 3 GB, that
gave me time to grab some supper.
When I came back, I configured the Digi concentrators, and did the
Port Configurations. The mpi menu is great for this task.
When I was doing the Print Queues in scoadmin, I noticed that the
menu would not let me 'Allow Remote Printing', as the option was in
parentheses, and was not selectable. The mkdev command did not even show
'rlp' as a valid option. Being adventurous, I fould the command and
executed it from its location, and it went through the motions as if it
had indeed worked, and Remote Printing was set-up. Now here is where the
fun started. The scoadmin utility still would not let me choose the
Remote Printing option, and to make matters worse, lpstat -t was not
working properly, and in fact, no print jobs were going through to any
spooled destinations. Sending jobs to the raw port (ie: /dev/lp0) worked
great though, so I knew that my attempt at activating rlp had somehow
messed up the print spooler. Executing lpshut & lpsched did nothing to
improve the situation, so I dug deeper.
I got onto SCO's website (obviously desperate by that time), and lo
and behold, deep within an article about cups vs. sysv printing systems
was a warning that said: "... if you have not run mkdev rlp to create
remote printing, make sure that you remove the cups printing system
first, then do mkdev rlp, then re-install it ..." (if you need to, I did
not). It would have been nice to have known THAT little fact earlier.
(See I cannot enable remote printing (mkdev rlp) after the installation of an Update Pack 2/3 or a Maintenance Pack)
I tried to do an "Upgrade" install, thinking that would allow me to
just re-load the lp printing system, but that did not work.
I looked on the old 5.0.5 system to see the size & save dates of the
lpstat, lp, lpmove, lpr & cancel binaries, but I knew better than to
copy those over to 5.0.7. So I did a find, and while most of the
references to lpstat are symlinks, I actually found the binaries in
/opt/K/SCO/Unix/5.0.7Hw/.softmgmt/var/usr/bin (intuitive, I know), and
copied them to /usr/lpd/local. Printing worked again, so I went out to
the Converting Office in the mill to test some of the label printers
that the guys would be needing to use in a few hours. Now, here is where
I made a crucial error, or maybe my contacts were drying out, and I just
didn't see it well enough. The binaries have to have '---x--s--x' for
permissions, but when I copied them, they became '---x--x--x' and I
missed the subtle yet very important difference. This led to every
sysadmin's favorite situation where root could print, and nobody else
could. I tried several things before I clued into the 'chmod g+s' which
turned that middle x back to an s.
This allowed other users to print, and to execute lpstat to see
print jobs in the queue. The Digi's seemed to be reverting back to 9600
baud on a couple of the wyse60 terminals, but I will figure that out
later. I had to chown & chgrp all of the users' home directories, as rcp
did not preserve ownership, but did keep the last modified dates. I then
ran a few more tests with the 5:00 A.M. gang starting to arrive, and
then found out that backupedge stopped working, as I had changed the
I uninstalled and
re-installed BackupEdge, and was able to do a Backup of 8+ GB in 9:
minutes!. The Verify was even faster. I still have a funky VSIFax
permissions issue somewhere, as some users can FAX and others cannot.
That will be easy enough to figure out. IQ worked, and WordPerfect was
fine. FacetWin allowed access to the shared drive, and all of the
printers that I tested were okay. I have to check the remaining user
accounts, and set up a few print queues including the remote ones on
the othr server, but I will probably do that sometime on Sunday.
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Bill Mohrhardt
© 2009-11-07 Bill Mohrhardt