[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CUPS broadcasting print queue availability

On 2010-04-03 04:15, Liam O'Toole wrote:
On 2010-04-03, Ron Johnson <ron.l.johnson@cox.net> wrote:

I did this once a *long* time ago, but don't remember how. Also, I've read the (seemingly relevant sections of the sorely lacking) CUPS SAM, and Googled around to no avail.

My server has a print queue that looks like this:
$ lpstat -v
device for Dell_3100cn: socket://
device for Dell_3100cn@haggis: socket://
device for PDF: cups-pdf:/

The server's /etc/cups/cupsd.conf looks like:
Browsing On
BrowseOrder allow,deny
BrowseLocalProtocols CUPS dnssd
DefaultAuthType Basic
<Location />
   Allow from 192.168.1.*
   Order allow,deny

I got broadcasting to work by setting BrowseAddress to the IP address of
the interface to broadcast on.

Do you mean haggis' IP address???

                               Alternatively you can use the notation
@IF(eth1) or similar.

That's doable!

                       On a dual-homed server, I also find it necessary
fot the cups daemon to listen on all interfaces, even though
broadcasting is only done on one. Hardly intuitive.

I created this on the client:
$ cat /etc/cups/cups.conf
ServerName haggis

Shouldn't cups on the server (haggis) be broadcasting network messages announcing the availability of it's print queues, and shouldn't some program from cups-client be listening?

Or do even client computers need the cups server package?

No, you can simply hard-code the name of the cups server in the file
/etc/cups/client.conf on the client.

Did that...

                                      You can then remove the cups
package on the client, but ensure that cups-client remains.

So, the cups server package must be installed on the client during configuration, but can be removed afterward?

"History does not long entrust the care of freedom to the weak
or the timid."  Dwight Eisenhower

Reply to: