[cups.bugs] [MOD] STR #3961: remote printers overriding Shared attriubte of local printers

russell-cups.stuart.id russell-cups at stuart.id.au
Tue Oct 18 09:52:52 PDT 2011


DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

We have two CUPS servers, on separate subnets.   One server sits on the
host whose DNS name is say xxx.vpn, and has a local printer called say
xxx-printer.  The second server sits on a host whose name is say yyy.vpn. 
It also has a printer called xxx-printer, whose DeviceURI is
ipp://xxx.vpn/printers/xxx-printer.

When I run "lpr -P xxx-printer something" on yyy.vpn, nothing gets
printed.  If I look at http://yyy.vpn/printers/xxx-printer, I see the
error message "Print file was not accepted (The printer or class is not
shared!)!".

Looking on xxx.vpn at xxx-printers printer definition, "Shared" is indeed
set to "No".  So I set it to "Yes", and restart CUPS.  CUPS immediately
sets it back to "No" again.

Problem 1: there is no hint as to why in the manual, or why this matters. 
The only description I can find for Shared is in lpadmin(8), which says
"Shared/published printers are publically announced by the server on the
LAN based on the browsing configuration in cupsd.conf, while
unshared/unpublished printers are not announced."  Well looking at
schedule/ipp.c:add_job it has more effect than that.  It prevents other
CUPS servers from using it at all.  Ie, we have a documentation bug.

Problem 2: is why it was being reset.  Again trolling the source code, I
see schedule/printers.c:cupsdSetPrinterAttrs resets it if
CUPS_PRINTER_REMOTE is set.  My guess is that is what is happening, but if
so it is odd because it isn't remote.  But I see
schedule/printers.c:cupsdLoadRemoteCache sets CUPS_PRINTER_REMOTE if a
remote printers cache is loaded.

So my guess is perhaps yyy.vpn's definition is being loaded into xxx.vpn,
over the top of the local definition.  I don't think that is a reasonable
thing to do under any circumstances, but in this case I couldn't see why
it happened at all as yyy.vpn has "Browsing off" set in cups.conf.  Ergo,
it should never be sending stuff???  Nonetheless xxx.vpn does have have
these settings:

Browsing True
BrowseOrder deny,allow
BrowseAllow from all
BrowseLocalProtocols CUPS dnssd
BrowseAddress 10.89.0.255
BrowseShortNames No

So to test the theory and I prevent xxx.vpn from accepting Browse
information from anybody but the local subnet:

BrowseOrder allow,deny
BrowseAllow from 10.89.0.0/24

After I do that "Shared" does not get reset to "No" when I restart cups,
and printing new a job works.

Unfortunately there is a 2nd chapter to go, but that is in the web UI so I
will raise another bug.

Link: http://www.cups.org/str.php?L3961
Version: 1.4.7





More information about the cups-devel mailing list