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:
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.
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: