cups shared state backwards compatibility issues

Hans-Peter Jansen hpj at urpla.net
Fri Jul 11 06:40:15 PDT 2008


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




More information about the cups mailing list