Bug 134702
Summary: | CUPS cannot access remote printer/cupd | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dave Knight <dmk> |
Component: | cups | Assignee: | Tim Waugh <twaugh> |
Status: | CLOSED WORKSFORME | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 2 | CC: | dmk |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-09-09 21:34:05 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dave Knight
2004-10-05 17:23:43 UTC
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. |