> I have the CUPS printing working from windows desktops and Linux guest
to
> the printers when using IPP.
>
> I have a few printers that do not support IPP and require LPR/LPD.
Then you specify a lpd URI in CUPS from the CUPS server, not from the
clients. You want the server to do the actual I/O to the printer, not
the clients. The clients should need to speak only IPP. Your device URI
in CUPS for the printer should look something like this:
lpd://<hostname>/raw
Replace <hostname> with the actual hostname of the printer.
It helps if you think about it this way:
There are three parts here:
1) LPD server in the printer (speaks LPR/LPD only)
2) CUPS server (speaks LPD and IPP incoming, IPP, LPR and a bunch of
other stuff outgoing)
3) Windows client (IPP native, can do LPR outgoing with Printing for
Unix installed).
You want output mediated by the CUPS server so you get accounting data
and to have the server sequence stuff to the printer. This means that
the CUPS server needs to be a LPR client to the printer, but we want it
to be a IPP server to the Windows boxes so we don't need to go around to
all the Windows clients and install Printing for Unix.
So:
Windows -- IPP --> CUPS Server -- LPR ---> LPD in Printer
The CUPS server does the store and forward of the print file from the
Windows client at the CUPS server, then requeues it as a LPR client to
the LPD in the printer.
> I have done the following in setting up LPR/LPD with CUPS on Linux
System
> z.
>
> We are using zVM 5.3 and SuSE SLES10 SP2.
>
> /etc/xinetd.d/cups-lpd was changed to be disable = no:
>
> /etc/xinetd.d/cups-lpd
> service printer
> {
> disable = no
> flags = NAMEINARGS
> socket_type = stream
> protocol = tcp
> wait = no
> user = lp
> server = /usr/lib64/cups/daemon/cups-lpd:
> server_args = cups-lpd -o
document-format=application/octet-stream
Cups-lpd is incoming only. It plays no role in communicating to the
printer -- it's just a translator to turn a LPR transaction from a
client into IPP to be submitted internally to CUPS. You only need this
if you have hosts that cannot be upgraded to speak IPP outgoing.
> The printer has both PCL and PS type drivers. We have tried to use
both
> the
> PCL and the PS drivers
> when we define the printer in windows.
>
> When I define the printer on the windows platform I get the message
that
> either the printer was misspelled or it is not connected. Printer is
not
> created.
Define the printer on the CUPS server first as a LPD printer (remember
that the PRINTER is the LPD piece of the puzzle in this configuration),
and specify the host name and queue name (usually "raw" (note: case
sensitive!) in this case) because you don't want the printer trying to
do anything smart with the incoming data stream. Make sure the CUPS test
page prints on the printer. Look at /etc/printcap on a Unix machine that
can print to the printer in question for the details of the host and
queue name.
On the Windows client, define the printer using IPP to point to the CUPS
server queue you just created, and specify the printer driver as needed,
either manually or via Samba click-n-print. The CUPS server will take
care of the protocol translation.
I'd suggest you prefer the PostScript drivers for the printer; they tend
to be more functional.
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
