<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Apr 22, 2009, at 3:19 PM, Paul Landers wrote:</div><blockquote type="cite"><div>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.<br></div></blockquote><div><br></div>Listen controls which address(es) the scheduler will accept connections on. For example, you might have a public and private network interface.  Using:</div><div><br></div><div>    Listen *:631</div><div><br></div><div>or:</div><div><br></div><div>    Port 631</div><div><br></div><div>would accept connections from both interfaces while:</div><div><br></div><div>    Listen privatehostname:631</div><div><br></div><div>would only accept connections using the address(es) defined for the private network interface (which are listed for "privatehostname"...)</div><div><br></div><div>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:</div><div><br></div><div>    Listen localhost:631</div><div><br></div><div><div>    <Location /></div><div>    Order allow,deny</div><div>    </Location></div><div><br></div><div>to:</div><div><br></div></div><div>    Port 631</div><div><br></div><div>    <Location /></div><div>    Order allow,deny</div><div>    Allow @LOCAL</div><div>    </Location></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite"><div>Also, from the CUPS SAM, the explanation for the directive 'Browsing On':<br><br>"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."<br><br>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?<br></div></blockquote><div><br></div>"Browsing On" by itself would just let your system see other shared printers.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br><blockquote type="cite"><div><br>I would be very grateful if someone could clarify and simplify these questions.<br><br>Thank you!<br>_______________________________________________<br>cups mailing list<br><a href="mailto:cups@easysw.com">cups@easysw.com</a><br>http://lists.easysw..com/mailman/listinfo/cups<br></div></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>________________________________________</div><div>Michael R Sweet, Senior Printing System Engineer</div></div></div></span></span>
</div>
<br></body></html>