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

SCO upgrade and CUPS

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.





Increase ad revenue 50-250% with Ezoic


More Articles by © Bill Mohrhardt



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





A Perl script is "correct" if it gets the job done before your boss fires you. (Larry Wall)

The best of us would rather be popular than right. (Mark Twain)












This post tagged: