[cups.general] Listen vs. <Location />

Michael Sweet msweet at apple.com
Wed Apr 22 16:35:50 PDT 2009


On Apr 22, 2009, at 3:19 PM, Paul Landers wrote:
> One of the most confusing things for me had been what appear to be  
> overlapping directives.  For example, why is it necessary to specify  
> both a Listen directive as well as the <Location /> directive?  They  
> both appear to control the same access, and I have not yet found a  
> clear explanation of the differences.

Listen controls which address(es) the scheduler will accept  
connections on. For example, you might have a public and private  
network interface.  Using:

     Listen *:631

or:

     Port 631

would accept connections from both interfaces while:

     Listen privatehostname:631

would only accept connections using the address(es) defined for the  
private network interface (which are listed for "privatehostname"...)

Location controls access to specific resources once you are connected  
to the server. For example, when you enable printer sharing from the  
web interface (or cupsctl command-line utility) the cupsd.conf file is  
updated from:

     Listen localhost:631

     <Location />
     Order allow,deny
     </Location>

to:

     Port 631

     <Location />
     Order allow,deny
     Allow @LOCAL
     </Location>

The change from Listen to Port allows connections on any network  
interface, however the "Allow @LOCAL" only allows access beyond the  
initial connection to systems on the same subnets as your server.

You'll also see a Policy directive in the default cupsd.conf file - it  
serves a similar purpose, just for IPP operations instead of file and  
directories.

FWIW, the same rules apply to the Apache HTTP server (I used the same  
syntax and rules when designing the cupsd.conf format), so any good  
Apache book should provide more examples to explain how Listen/Port  
and Location/Order/Allow/Deny/AuthType/Require interact.

> Also, from the CUPS SAM, the explanation for the directive 'Browsing  
> On':
>
> "This directive does not enable sharing of local printers by itself;  
> you must also use the BrowseAddress or BrowseProtocols directives to  
> advertise local printers to other systems."
>
> My question is simply 'why not'?  In other words, if I set 'Browsing  
> On' but did not set any BrowseAddress or BrowseProtocols, then how  
> would CUPS behave?

"Browsing On" by itself would just let your system see other shared  
printers.

Setting a BrowseAddress tells CUPS to advertise its shared printers to  
other systems on the corresponding network, with @LOCAL advertising to  
all of the networks you are directly connected to.

BrowseProtocols (and now more formally BrowseLocalProtocols and  
BrowseRemoteProtocols) allows you to control which protocols are used  
for printer sharing. The defaults vary based on the platform, but  
always include CUPS so specifying the BrowseLocalProtocols directive  
is optional.

BrowseRemoteProtocols specifies the protocols used to discover  
printers shared by other systems; on Mac OS X this defaults to "none",  
while other platforms use "CUPS" by default.

>
> I would be very grateful if someone could clarify and simplify these  
> questions.
>
> Thank you!
> _______________________________________________
> cups mailing list
> cups at easysw.com
> http://lists.easysw.com/mailman/listinfo/cups

________________________________________
Michael R Sweet, Senior Printing System Engineer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cups.org/pipermail/cups/attachments/20090422/e506992f/attachment-0001.html>


More information about the cups mailing list