cups shared state backwards compatibility issues

Helge Blischke h.blischke at srz.de
Fri Jul 11 07:45:38 PDT 2008


Hans-Peter Jansen wrote:
> Dear Masters of CUPS,
> 
> Basic setup: two cups servers ("local" and "remote") are connected via a vpn connection. The remote one is a heavily used company server with lots of clients and printers. It is still running SuSE 9.3 with cups-1.1.23.
> 
> The only deviation from the default setup is the addition of the local and remote ip ranges on both sides; E.g. in global section:
> 
> BrowseAddress @LOCAL
> BrowseAddress xxx.xxx.xxx.xxx/xx
> 
> BrowseAllow @LOCAL
> BrowseAllow xxx.xxx.xxx.xxx/xx
> BrowseDeny All
> 
> and in location "/":
> Allow From @LOCAL
> Allow From xxx.xxx.xxx.xxx/xx
> 
> Now, since I upgraded my local server from openSUSE 10.2 to 11.0 (cups-1.2.7 to cups-1.3.7), I cannot print from my local _clients_ to _remote printers_ anymore. Yes, I can print from my local server to local/remote printers, from remote server/clients to local printers, just not from local clients (running 10.2 or 11.0) to remote printers. When I do that with lp, I get:
> 
> ~> lp -d remote-printer 1.lp
> lp: The printer or class is not shared!
> 
> Local cups-1.3.7 server does not even try to communicate with the remote server, it just silently flags the remote printers "non shared" and throws this error:
> 
> D [01/Jul/2008:23:37:41 +0200] cupsdAcceptClient: 12 from xxx.xxx.xxx.xxx:631 (IPv4)
> D [01/Jul/2008:23:37:41 +0200] cupsdReadClient: 12 POST / HTTP/1.1
> D [01/Jul/2008:23:37:41 +0200] cupsdAuthorize: No authentication data provided.
> D [01/Jul/2008:23:37:41 +0200] CUPS-Get-Printers
> D [01/Jul/2008:23:37:41 +0200] cupsdProcessIPPRequest: 12 status_code=0 (successful-ok)
> D [01/Jul/2008:23:37:41 +0200] cupsdReadClient: 12 POST / HTTP/1.1
> D [01/Jul/2008:23:37:41 +0200] cupsdAuthorize: No authentication data provided.
> D [01/Jul/2008:23:37:41 +0200] CUPS-Get-Classes
> D [01/Jul/2008:23:37:41 +0200] cupsdProcessIPPRequest: 12 status_code=0 (successful-ok)
> D [01/Jul/2008:23:37:41 +0200] cupsdCloseClient: 12
> D [01/Jul/2008:23:37:41 +0200] cupsdAcceptClient: 12 from xxx.xxx.xxx.xxx:631 (IPv4)
> D [01/Jul/2008:23:37:41 +0200] cupsdReadClient: 12 POST /printers/hp4000 HTTP/1.1
> D [01/Jul/2008:23:37:41 +0200] cupsdAuthorize: No authentication data provided.
> D [01/Jul/2008:23:37:41 +0200] Print-Job ipp://localhost/printers/hp4000
> D [01/Jul/2008:23:37:41 +0200] print_job: auto-typing file...
> D [01/Jul/2008:23:37:41 +0200] Print-Job client-error-not-authorized: The printer or class is not shared!
> D [01/Jul/2008:23:37:41 +0200] cupsdProcessIPPRequest: 12 status_code=403 (client-error-not-authorized)
> D [01/Jul/2008:23:37:41 +0200] cupsdCloseClient: 12
> 
> ~> lpoptions -p hp4000
> copies=1 job-hold-until=no-hold job-priority=50 number-up=1 auth-info-required=none printer-info='HP 4000'
> printer-is-accepting-jobs=1 printer-is-shared=0 printer-location=Verwaltung/Fibu printer-make-and-model='HP LaserJet 2100 Series Postscript (recommended) on lisa5' printer-state=4 printer-state-change-time=1214947927 printer-state-reasons=none
> printer-type=18911302
> 
> Now I tried to modify the remote printers on my local server.
> Changing the shared state via web interface resulted in:
> "set-sharing" operation not permitted (retranslated from german)
> 
> Doing so with lpadmin (e.g.: 'lpadmin -p hp4000 -o printer-is-shared=true') does something funny: while remote cups printers usually don't show up in /etc/cups/printers.conf, that command created a local printer there:
> 
> <Printer hp4000>
> Info hp4000
> DeviceURI file:/dev/null
> State Stopped
> StateMessage
> StateTime 1215770101
> Accepting No
> Shared Yes
> JobSheets none none
> QuotaPeriod 0
> PageLimit 0
> KLimit 0
> OpPolicy default
> ErrorPolicy stop-printer
> </Printer>
> 
> Consequently, the web interface shows two printers now: hp4000 and
> hp4000 at remote (in order to distinguish them, I suppose). That brought me to my next idea, where I stopped cups, fixed the DeviceURI, State and Accepting values, started cups again, and bingo, I finally can print on _some_ of the remote printers, while others resist from being brought into sharing mode (which one can be shared, and which one don't doesn't follow any simple logic).
> 
> To summarize:
> printers controlled by older cups servers doesn't provide the means of a shared state ("implicit sharing"). Connecting to an older cups server (1.1) from a new one (1.3) doesn't handle this state properly. It should automatically set them to shared mode, but does it the other way around.
> 
> The "DefaultShared Yes" directive is meaningless in this area, since that only specifies whether _local_ printers are shared by default.
> 
> Hopefully someone is able to confirm this issue, and/or a fix would be highly appreciated. I'm prepared to apply patches..
> 
> P.S.: Here's my first (pretty confusing) try to report this issue:
> https://bugzilla.novell.com/show_bug.cgi?id=400588

Weird ...
We have an 1.1.19 installation for serving some weird printers (which fail to
function properly with newer CUSP version) and use 1.3.5 by default. We
routinely print from 1.3.5 clients to printers set up in the 1.1.19 installation
without any problems.

Helge


PS: Maybe there are some SuSE hacks in between - we always compile CUPS
grom the sources.

-- 
Helge Blischke
Softwareentwicklung
SRZ Berlin | Firmengruppe besscom

H.Blischke at acm.org




More information about the cups mailing list