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

SCO upgrade and CUPS

© March 2006 Bill Mohrhardt

Bill Mohrhard

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 defeat.

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 system name.

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.

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

Printer Friendly Version

-> SCO upgrade and CUPS

Inexpensive and informative Apple related e-books:

Take Control of iCloud, Fifth Edition

Take Control of the Mac Command Line with Terminal, Second Edition

Photos: A Take Control Crash Course

Take Control of Parallels Desktop 12

Take Control of Preview

More Articles by © Bill Mohrhardt

Printer Friendly Version

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