A few weeks ago, I thought I’d try to fix some printing problems but upgrading the version of CUPS that was installed on our print server.  Of course, since the print server runs Solaris 9, this wasn’t the easiest of tasks.  My first stop was to look on Sun Freeware for a package.  Unfortunately, CUPS was not among the hundreds of packages available.  So I Googled around a bit and found a package on Sun’s website.  Too bad it was the same version I already have.  Finally, I surrendered and grabbed the source.  Which refused to compile.  Granted, a smarter admin could probably have compiled it no problem, but I couldn’t get it working.  We were now about 2 business days from the outage I had scheduled.

Then I had one of my more brilliant thoughts.  Why not just set up a VM and run a Linux CUPS server?  So I did.  Not to brag or anything, but I had it up and running and the old server is forwarding port 631 to the new so the change is mostly invisible to the users.  Go me.  But there were a few problems.

The morning of the switch, one of the secretaries reported that the main office printers weren’t working.  One of them had a funky job that killed the queue, so I cleared it and restarted the queue.  But the other one looked fine.  My colleague went downstairs and checked it out, but couldn’t find any problem with the printer itself.  Around lunch, I was looking through /etc/cups/printers.conf and I came to a sudden realization.

HP JetDirect cards listen on port 9100 for incoming print jobs.  When setting up that particular printer, I forgot to include the port number.  That would explain why the socket process was still running and the load was so high.  Once that error was fixed, I was back in business.

There was still one more problem to be worked out.  A rather cranky professor let me know a while later that the printers on the 3rd floor weren’t working.  We have two printers there, with a CUPS class that splits the load between them.  The idea being that if one of the printers jams, the other keeps going.  This keeps the users from complaining.  Except when no print jobs finish for several days.

So I took a look at the 3rd floor printers on my way into the office one morning.  One of them had jammed, there was no question about that.  Several sheets were stuck in whatever that doohickey is that sits under the toner cartridge in the LaserJet 8150.  When that was cleared, the printer began catching up.  But the other printer…no jams, no other obvious problems.  I went up to my office to take a look at the server side of things.

Wiser from my previous experience, I checked that the config was correct.  It was.  Because I couldn’t think of anything else to do, I tried to telnet to the printer.  Connection refused.  Well that sounds like a problem.  So I tried from the old server.  Success.  Nosing around in the printer config, I realized that someone had set access controls on the printer so that only the old server could access it.  Once that was updated, all was well.  For now?