Re: CUPS broadcasting print queue availability
On 2010-04-03 04:15, Liam O'Toole wrote:
On 2010-04-03, Ron Johnson <email@example.com> 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://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:
BrowseLocalProtocols CUPS dnssd
Allow from 192.168.1.*
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.
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
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.
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