CUPS printers discovered via browsing appear as ///dev/null

Question

I have two servers on the same subnet, one CUPS server and one that needs to access printers configured on the CUPS server. CUPS browsing seems to be partially working, but according to lpstat on the client, the devices are ///dev/null instead of an ipp device.

[username@clienthost ~]$ lpstat -t
scheduler is running
no system default destination
device for boardroom: ipp://oldprintserver.my.network:631/printers/boardroom
device for br: ipp://oldprintserver.my.network:631/printers/br
device for its: ///dev/null      <------ THIS IS BAD?

• Print server is running Scientific Linux 6.4 with CUPS 1.4.2
• Printing client is running CentOS 5.8 with CUPS 1.3.7

Server configuration - cupsd.conf

Browsing On
BrowseRemoteProtocols
BrowseAddress @LOCAL
BrowseLocalProtocols CUPS dnssd

Client configuration - cupsd.conf

Browsing On
BrowseOrder allow,deny
BrowseAllow @LOCAL
BrowsePoll therealprintservername.my.network
BrowseInterval 30

Using tcpdump to analyze packets between hosts, it's clear that the client is polling the server over IPP. The server responds with 200 OK. Also, it seems that the client is only seeing the classes advertised by the print server, not the printer queues themselves.

So here's what I really want to know.

• What is the minimum required configuration for CUPS browsing to work on the same LAN?
• Does printer browsing work between different versions of CUPS?
• What other troubleshooting tools are available for problems with printer browsing?

[Edit: Even though lpstat -t says the device is ///dev/null, I can still send print jobs to the device. So it looks like basic printing works, but I'm still wondering why it shows as ///dev/null on the client.]

Answer 1

Most of my problems came down to misunderstanding the CUPS configuration file(s). I came across an excellent reference called HOWTO setup a small server - CUPS Print Server (chschneider.eu) that provided most of the answers I was looking for.

Printer classes have null devices

Q: According to lpstat on the client, the devices are ///dev/null instead of an ipp device.

Printer classes are never associated with a specific device or port. Instead, they contain other printers as members. Whether you're running lpstat on the CUPS server or a client, printer classes will always appear to have ///dev/null as the target device. This is the intended behaviour.

Using CUPS client without a local server

If you want all of your printing tasks to be handled by exactly one CUPS print server, you don't need to configure a local CUPS server at all. Just add the following line into /etc/cups/client.conf.

ServerName my_cups_server.my.network

In client mode, all of the regular printing commands like lpstat and lpr will be sent directly to the remote CUPS server. If client.conf is empty, printing commands will look for a local CUPS server.

Minimum configuration

Q: What is the minimum required configuration for CUPS browsing to work on the same LAN?

If CUPS client mode doesn't meet your needs, you'll need to configure the local CUPS server so that it can discover printers configured on other CUPS servers. There are two ways to do this.

Polling over IPP

This is ideal if you have only a few clients, and want more control over the printing environment. Polling is an integral part of CUPS, and no special directives are required to enable it. Just ensure the following:

• Each printer queue needs to have Sharing enabled individually.
• The <Location /> stanza must allow the appropriate subnets and/or users.
• Be careful about custom policies that might deny access.

Browsing via UDP broadcasts

This is ideal if you have a lot of clients or servers, and want to make it easy to use your print server. If browsing is enabled on the server, it will periodically send out UDP broadcasts.

Browsing On
BrowseOrder allow,deny
BrowseAllow all
BrowseAddress @LOCAL