Description of problem: Despite having being able to print CUPS test pages on both remote printers immediately after configuration, all subsequent attempts (the next day) to print or list remote printer status with "lpstat -t" produce a "client-error-forbidden" status. Reconfiguring the printers as LPD queues and enabling the cups-lpd service allowed the remote printers to be used. Version-Release number of selected component (if applicable): cups-1.1.20-11.3 (on both the local and remote printer hosts) How reproducible: This environment has printers connected to the parallel ports of two hosts (a and b) running FC2 with cups-1.1.20-11.3 and the cupsd service enabled. When host a is configured to have a remote CUPS printer on host b (and vice-versa) the initial printing of a CUPS Test page may work, but further attempts to access the remote printer(s) will fail with the "forbidden" error. Attempts to reconfigure the CUPS queues did not clear the error. There is also a router/firewall between the two hosts, and port 631 (IPP) is open - telnet from host a to port 631 on host b works fine. If the remote printers are reconfigured as LPD type queues, and the cupd-lpd service enabled, remote printing work properly. Steps to Reproduce: (see above) 1. 2. 3. Actual results: Expected results: Additional info: Actual printers used here are an HP LaserJet 3 and an HP DeskJet 5550C. The errors encountered with the CUPS type queues were symmetric (the same regardless of which printer was involved).
BTW, the system-config-printer script was used to perform all (re)configuration operations. DMK
It sounds like you are having to take some action on host A (for example) to get it to use the printer on host B. This should not be necessary, other than to make sure that the firewall on host A allows incoming UDP packets on port 631. Can you check the firewall please, and make sure that UDP port 631 is allowed in?
Actually, the client-error-forbidden failure is symmetric (i.e. it also occurs when host B tries to access host A's IPP-shared printer). I checked the firewall/router configuration between host A and host B and, indeed, forwarding for port 631 is enabled for both UPD and TCP packets travelling from host A to host B. Also, ALL tcp/udp ports are open for host B traffic going to host A, hence an unlikely source for the problem of host B printing on host A's printer. Furthermore, the symmetric nature of the error and the fact that the fw/router has port 631 is open in both directions for both udp and tcp traffic suggests the problem lies elsewhere - perhaps in the cupsd configuration. Since I used the system-config-printer script to configure the both printers on both hosts, perhaps copies of the resulting config files would be useful to your analysis. If so, please advise which files you would like to see and I will forward them directly or thru another attachment here.
The reason I asked about the firewall is this: Having configured the local printer on host A, and the local printer on host B, there should be nothing further to do. But it sounds like you needed to do more, so something's up. Did you configure each queue for sharing? If you right-click on the (local) queue name in the system-config-printer application and select 'Sharing...', does it show that the queue is allowed to be used by the other machine?
Both printers were configured for sharing on their respective host systems, and were reported as allowing access from all other systems. This is why the problem seemed so perplexing. I now suspect that the problems arose because I attempted to configure (using the std system-config-printer script) the remote/CUPS printers on the client hosts - a step that appears to be unnecessary when using CUPS. Relaizing this, I do not think that the problem lies in the CUPS server or firewall, but rather was caused by something that happened on the client host - perhaps as a result of something I did within the system-config-printer dialog. I regret that I cannot revisit this issue at this time, because the deployment schedule required a "workaround" which I accomplished using a traditional lpd-style configuration, which (still) works quite well.
Okay. I'll close this now then. If you have occasion to revisit this issue please re-open it.