Description of problem: I select in system-config-printer 'publish shared printer...' in server settings but the printers are not accessible from other hosts. Version-Release number of selected component (if applicable): system-config-printer-1.0.16-2.fc10.i386 cups-1.3.10-1.fc10.i386 How reproducible: It was working before, but after an update some days ago, it does not work anymore. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Are your clients using a hostname for the CUPS server that the server itself does not associate with any of its interfaces? Add "ServerAlias hostname" to cupsd.conf for each hostname that clients will use that the CUPS server does not know to associate with itself. This was mentioned in the update notes: https://www.redhat.com/archives/fedora-package-announce/2009-April/msg00510.html https://admin.fedoraproject.org/updates/F9/FEDORA-2009-3753 Was this the problem?
No. I have all other PCs listed in /etc/hosts. Anyway, it was not necessary before. If I need to install a new Fedora desktop computer, I just install it, connect to the network (with dhcp) and Fedora automatically detects all shared printer in the network.
Did you try adding ServerAlias lines? Can you try adding a line 'ServerAlias *'? No, this was not necessary before, but a security attack is possible if the hostname used by the client is not checked.
Today I tried. I added the line 'ServerAlias *' to the server's and client's cupsd.conf. But it doesn't work.
Does this pending test update for Fedora 10 fix the problem for you?: https://admin.fedoraproject.org/updates/cups-1.3.10-2.fc10
URL changed due to rebuild: https://admin.fedoraproject.org/updates/cups-1.3.10-4.fc10
(In reply to comment #6) > URL changed due to rebuild: > https://admin.fedoraproject.org/updates/cups-1.3.10-4.fc10 No, it doesn't work with it.
Please attach the /var/log/cups/error_log file from the CUPS server. Also, can you explain in more detail what you are doing, and what happens, compared with what you expect to happen? Are the printers visible to other hosts, do they accept jobs, are there any error messages? etc...
Created attachment 341604 [details] /var/log/cups/error_log
(In reply to comment #8) > Also, can you explain in more detail what you are doing, and what happens, > compared with what you expect to happen? Are the printers visible to other > hosts, do they accept jobs, are there any error messages? etc... I want to print from a Fedora 10 desktop to another F10 Desktop. It usually worked fine out of the box. I only needed to share my printer and publish all shared printers. Before the recommended update, in the client only disables the print button of the gtk+ dialog. After the update, in the client it hangs the application when I select the remote printer in the gtk+ print dialog. The error_log in the server is the attached before this comment. The printers are visible from the client computer. In system-config-printer, when I select the remote printer and ask for properties it says "there was a problem to connect to the cups server" after a while. In the cups server, printing works fine.
The file you've attached has no entries since before Christmas last year, so is no good. Please attach cupsd.conf from the CUPS server, and also please show me the output of 'rpm -q cups'.
(In reply to comment #11) > The file you've attached has no entries since before Christmas last year, so is > no good. > Really ? What I see is the following: *** begin of copy of the last lines of error_log in the attachments I [28/Apr/2009:13:18:08 -0300] Full reload complete. I [28/Apr/2009:13:18:08 -0300] Cleaning out old temporary files in "/var/spool/cups/tmp"... I [28/Apr/2009:13:18:08 -0300] Listening to 0.0.0.0:631 on fd 4... I [28/Apr/2009:13:18:08 -0300] Listening to :::631 on fd 5... I [28/Apr/2009:13:18:08 -0300] Listening to /var/run/cups/cups.sock on fd 6... I [28/Apr/2009:13:18:08 -0300] Resuming new connection processing... W [28/Apr/2009:13:18:08 -0300] DNS-SD registration of "Epson-FX880" failed with -65537 W [28/Apr/2009:13:18:08 -0300] DNS-SD registration of "hp-LaserJet-1150" failed with -65537 W [28/Apr/2009:13:18:08 -0300] DNS-SD registration of "hp2600n" failed with -65537 W [28/Apr/2009:13:18:08 -0300] DNS-SD registration of "hp_LaserJet_1150" failed with -65537 I [28/Apr/2009:13:18:15 -0300] Saving subscriptions.conf... I [28/Apr/2009:13:18:38 -0300] Saving subscriptions.conf... I [28/Apr/2009:13:19:55 -0300] Saving subscriptions.conf... I [28/Apr/2009:13:28:56 -0300] Started "/usr/lib/cups/cgi-bin/admin.cgi" (pid=4957) *** end of copy of the last lines You may see there that the date is Apr 28th, 2009 (this year) > Please attach cupsd.conf from the CUPS server, and also please show me the > output of 'rpm -q cups'. [user@cupsserver ~]$ rpm -q cups cups-1.3.10-4.fc10.i386
Oh, sorry, not sure how I ended up seeing the wrong file. This log file doesn't show any remote connection attempts failing, so I'd like to ask you for more information: 1. Run 'cupsctl --debug-logging' on the server as root 2. Run '/sbin/service cups restartlog' on the server as root 3. On the client, run 'strace -s1000 gedit 2>gedit.txt' and press Control-P in the gedit window, then select a printer from the server. Quit gedit. Please attach: i. the gedit.txt file from the client, ii. the /var/log/cups/error_log file from the server, iii. the output of 'iptables -n -L | grep -w 631' from the server, run as root iv. the output of 'cupsctl' from the server, run as root Thanks.
Created attachment 341742 [details] new error_log after comment 13
Created attachment 341744 [details] gedit.txt file with strace output
i. see attached file gedit.txt.zip ii. see attached file new error_log after comment 13 iii. [root@cupsserver ~]# iptables -n -L | grep -w 631 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:631 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:631 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:631 iv. [root@cupsserver ~]# cupsctl MaxLogSize=0 SystemGroup=sys root DefaultAuthType=Basic _debug_logging=1 _remote_admin=0 _remote_any=1 _remote_printers=1 _share_printers=1 _user_cancel_any=0 I enabled Test Updates repo, and after updated the client doesn't hange forever anymore when selecting the cups server's printer, it only hangs a little while like testing availability.
The client just has to download the PPD from the server. So it's fixed after the client was updated from updates-testing? Any idea which particular package fixed it?
(In reply to comment #17) > The client just has to download the PPD from the server. How do I do that? In the client I have the package hpijs-2.8.12-6.fc10.i386 installed. In the server, the printer's make and model is 'HP LaserJet 1150 Foomatic/hpijs (recommended)' > So it's fixed after the client was updated from updates-testing? Any idea > which particular package fixed it? I don't know. It didn't fix it. It only does not hang the client forever anymore. Now I'm back in the beginning, where the Print button appears disabled in the client machine.
(In reply to comment #18) > (In reply to comment #17) > > The client just has to download the PPD from the server. > > How do I do that? No, the client does it automatically (the GTK+ print dialog does it). Once it has the PPD, it enables the Print button. So it hasn't managed to fetch the PPD. Please try the previous test and attach the new gedit.txt and error_log files.
Created attachment 341942 [details] new error_log after comment 19
Created attachment 341943 [details] gedit.txt file with strace output after comment 19
(In reply to comment #19) > No, the client does it automatically (the GTK+ print dialog does it). Once it > has the PPD, it enables the Print button. > > So it hasn't managed to fetch the PPD. > How was it deleted ? I only updated my fedora. It was working before the update ! If it's not there, how do I copy the PPD by hand ? > Please try the previous test and attach the new gedit.txt and error_log files. Done, see comment 20 and 21.
(In reply to comment #22) > How was it deleted ? No, it's cached for the life of the application. It is re-fetched each time you want to print -- the server may have different options in the PPD since last time, you see. > I only updated my fedora. It was working before the update ! I think the problem is on the client side. It still isn't even trying to connect to the server. Show me 'lpstat -s' from the client and let me know which of the queues shown is the one you want to use.
(In reply to comment #23) > Show me 'lpstat -s' from the client and let me know which of the queues shown > is the one you want to use. [usuario@secretaria ~]$ lpstat -s destino por omisión del sistema: HP-LaserJet-M1120-MFP dispositivo para Epson-FX880: ipp://bce.no-ip.org:631/printers/Epson-FX880 dispositivo para hp-1200-coord: ipp://192.168.1.9:631/printers/hp-1200-coord dispositivo para hp-LaserJet-1150: /dev/null dispositivo para hp-LaserJet-1150.org: ipp://bce.no-ip.org:631/printers/hp-LaserJet-1150 dispositivo para HP-LaserJet-1200: ipp://192.168.1.14:631/printers/HP-LaserJet-1200 dispositivo para HP-LaserJet-M1005-MFP: ipp://192.168.1.90:631/printers/HP-LaserJet-M1005-MFP dispositivo para HP-LaserJet-M1120-MFP: hp:/usb/HP_LaserJet_M1120_MFP?serial=NZ01JT7 dispositivo para hp2600n: /dev/null dispositivo para hp2600n.org: ipp://bce.no-ip.org:631/printers/hp2600n dispositivo para hp_LaserJet_1150: /dev/null dispositivo para hp_LaserJet_1150.org: ipp://bce.no-ip.org:631/printers/hp_LaserJet_1150 dispositivo para KonicaPagePro1350W: /dev/null [usuario@secretaria ~]$ Some URI are /dev/null, how did this happen ? Is it because of the new checking of 'ServerAlias *'? The bce.no-ip.org is a Fedora 10 computer in the LAN. From Internet (outside world) I access it through bce.no-ip.org. But from the LAN it's name is proglinux. Is it because it has two names ? Adding bce.no.ip.org to the /etc/hosts file works fine. So, consider the bug closed. Now, how do I delete the printers with a wrong URI ? I wasn't able to do it through s-c-p and http://localhost:631.
You should have had a line "ServerAlias *" added to the end of /etc/cups/cupsd.conf when you installed cups-1.3.10-4.fc10, which would disable checking of the hostname. Looking at comment #16 this doesn't seem to have happened. I wonder if it's because it didn't restart cupsd on upgrade. The strange-looking URIs are because cups has made an implicit class from the (apparently) 2 hosts with different names. Should all be fine if you stop cups, rm /var/cache/cups/remote.cache, then restart cups.
(In reply to comment #25) > You should have had a line "ServerAlias *" added to the end of > /etc/cups/cupsd.conf when you installed cups-1.3.10-4.fc10, which would disable > checking of the hostname. Looking at comment #16 this doesn't seem to have > happened. I wonder if it's because it didn't restart cupsd on upgrade. > No problem if I have to add it by hand. It's a special situation for me. > The strange-looking URIs are because cups has made an implicit class from the > (apparently) 2 hosts with different names. Should all be fine if you stop > cups, rm /var/cache/cups/remote.cache, then restart cups. This solves the delay mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=478400#c13 Is it possible to have that 'rm /var/cache/cups/remote.cache' in the 'stop' option of cups service? Many thanks for your support.
(In reply to comment #26) > Is it possible to have that 'rm /var/cache/cups/remote.cache' in the 'stop' > option of cups service? No. The point of that file is that it is persistent across restarts. Any bad entries in there should eventually time out -- or else are being broadcast by incorrectly-configured servers elsewhere on the network.
(In reply to comment #27) > No. The point of that file is that it is persistent across restarts. Any bad > entries in there should eventually time out -- or else are being broadcast by > incorrectly-configured servers elsewhere on the network. They are being broadcast by other servers on the network. I have to clean them all. It's not easy when they are more than 10 computers. Thank you anyway. I'm glad it's me and not Fedora. I'm really happy because it's becoming more stable.
cups-1.3.10-5.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
cups-1.3.10-5.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.