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://192.168.1.11
> device for Dell_3100cn@haggis: socket://192.168.1.11
> device for PDF: cups-pdf:/
>
> The server's /etc/cups/cupsd.conf looks like:
> Browsing On
> BrowseOrder allow,deny
> BrowseAllow 192.168.1.0/24
> BrowseAddress 192.168.1.255
> BrowseLocalProtocols CUPS dnssd
> DefaultAuthType Basic
><Location />
> Allow from 192.168.1.*
> Order allow,deny
></Location>
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.
>
> TIA
--
Liam O'Toole
Birmingham, United Kingdom
Reply to: