Remote printing to Windows printservers from Solaris

Recently I found myself in the situation that we had gotten an incident about some application that couldn’t print anymore to the printers it was printing before. This was a big issue and we had to work on it immediately, since it had to be fixed yesterday.

Sounds familiar?

Apparently a project had moved people from one location to an other in the corporate network and now the printing issue occured. So what’s the issue?

People used to schedule a print job in the application that’s using an Oracle database as the datastore. A batch job on the Solaris server checks every once in a while whether there is a print job to be executed. If so it kicks of some fancy script that creates a postscript file and basically uses the ‘lp’ command (Available on every unix/linux flavor) to print to a remote printer.

Since the people were moved they had to move the printers as well, but forgot to tell us in advance. Not a big deal. We’d just changed the IP adresses to the new onces the printers were assigned. But no result.

Digging a little deeper we got the message that we had to print to these printers via a windows printserver because the new location was outside our departments network and now was separated from us by a firewall. That firewall would only be allowed let one IP adress print to other printers within that network. Thus the windows printserver had to be used.

That windows printserver had different printqueue’s for the different printers. But we were used to print to an IP adress without using any queue name whatsoever. In fact nothing had changed there for several years thus the people that had created that solution were long gone.

Not to worry, we have Google these days. Right?

Googling using keywords like ‘remote printing’ and ‘Solaris’ only resulted in one solution: CUPS. And there is nothing wrong with that. In fact at a different client we used that in combination with Suse Linux to print to Novell printers. Worked like a charm.

But the package for Solaris that we could find used an older version of CUPS and while testing this solution it turned out that the cups daemon would crash too often. We just wanted a stable solution while not having to install too much software that SUN would probably not support. Or that would/could introduce more security concerns on the Solaris systems.

The ‘man’ pages for ‘lp’, ‘lpadmin’ etc were not so easy to read. And while testing the CUPS solution I had gotten some more insight into to possibilities/protocols etc etc. And when it turned out that we could just use the lpd/lpr protocol to print to these printservers I could not shake the thought that it must be possible to use the existing software to print.

It’s just a matter of finding the correct options to use…

Something with lpadmin xxx -s printserver!queuename. But when trying that we got the message “unknown event”. What event?!? It puzzled me and I couldn’t let go of it.

Suddenly I thought hit me. What if…? What if it is an other shell issue? So I exited the bash shell we normally use since we’re so familiar with that and got back to the ksh shell.

That gave me a different error. Something about not being allowed to use a certain option in combination with remote printing.

That was it! Breakthrough!

To create the printer with the name of the queue it is supposed to use on the windows printserver:

/usr/sbin/lpadmin -p ${PRINTER_QUEUE} -s ${PRINT_SERVER}!${PRINTER_QUEUE} -n /usr/lib/lp/model/ppd/system/foomatic/Generic/Generic-PCL_6_PCL_XL_Printer-pxlmono.ppd.gz -I postscript -u allow:all

Ofcourse do check if the parameters used above suit your situation. Specially the “-u allow:all” part.

And to give the printer some nice description:

“Other Network File and Print Services -> Print Services for Unix ”

I hope this saves someone a lot of time (searching the internet).

Patrick