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

Re: CUPS broadcasting print queue availability

On 2010-04-03, Ron Johnson <ron.l.johnson@cox.net> wrote:
> Hi,
> 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
> BrowseAllow
> BrowseAddress
> 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. Alternatively you can use the notation
@IF(eth1) or similar. 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. You can then remove the cups
package on the client, but ensure that cups-client remains.


Liam O'Toole
Birmingham, United Kingdom

Reply to: