Description of problem: At work we have a working CUPS server, version 1.7.5. Accessing/pinging the CUPS server from my Fedora 28 machine works. Trying to connect to it by modifying /etc/cups/client.conf with ServerName cups_server_domain does not work. It seems that CUPS can only be connected to localhost. Version-Release number of selected component (if applicable): The installed CUPS version is cups-2.2.6-18.fc28.src.rpm How reproducible: A fedora machine tries to connect to a remote cups server. Steps to Reproduce: 1. echo "ServerName enter_cups_domain_here"> /etc/cups/client.conf 2. sudo systemctl restart cups (or enable and start if not already done) Actual results: lpstat -t Fails with an error message: lpstat: Service Unavailable system-config-printer fails with the same error message Service Unavailable and cannot start. Expected results: lpstat -t lists the printers connected to the remote server system-config-printer shows the printers connected to the remote server Additional info: Folks with Ubuntu 16.04/Debian 9 can connect without any issues. So can MacOS guys. system-config-printer starts only if no connection to a remote cups server is specified. systemctl -a | grep cups outputs one not-found service: org.cups.cupsd.service. I assume its harmless because it is just requested somewhere. This ticket seems pretty similar: https://bugzilla.redhat.com/show_bug.cgi?id=1494848
Hi Vasil, thank you for reporting this issue! Are cups.service or cups.socket services running? If they are, would you mind sending me logs from journal for cups (see https://fedoraproject.org/wiki/How_to_debug_printing_problems ). I suspect the latest TLS enhancement can be the reason, so would you mind trying to downgrade cups too for now?
Hi Zdenek , yes, both cups.service and cups.socket were running while I was testing. I can confirm that downgrading from cups-1:2.2.6-18.fc28.x86_64 to cups-1:2.2.6-14.fc28.x86_64 is a workaround. Now it's possible to connect and print from the remote CUPS server without any issues. Therefore your suspicion is probably correct. Now back to debugging the problem. It was not possible to turn on cupsctl LogLevel=debug2 while the /etc/cups/client.conf file was pointing to the remote CUPS server. cupsctl was failing with "Bad file descriptor". I needed to repoint it to localhost and restart cups.service and cups.socket. The journal log after restoring cups to point to the remote server is in the attached archive file. The log is captured after a direct restart of cups.service and cups.socket and an attempt to open system-config-printer, which, as mentioned in the ticket's description, also fails with "Bad file descriptor". Hope this helps. Cheers, Vasil
Created attachment 1479875 [details] Cups journal log with enabled debug flag
Vasil, would you mind attaching files from your /etc/cups directory? I'll revert the patch for now, you can try it from this scratch build. https://koji.fedoraproject.org/koji/taskinfo?taskID=29395052
And when you have cups-2.2.6-18 installed, if you set 'SSLOptions MinTLS1.0', are you able to connect to remote server?
cups-2.2.6-22.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-7b9711d0f6
cups-2.2.6-22.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-7b9711d0f6
cups-2.2.6-22.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days