Bugzilla – Bug 139370
SWAT fails to start because it cannot contact a CUPS server
Last modified: 2008-06-25 09:53:11 UTC
My machine has samba-3.0.20-4 installed. The error is /var/log/samba/log.swat: [2005/12/15 08:27:48, 0] printing/print_cups.c:cups_cache_reload(85) Unable to connect to CUPS server 10.0.0.72 - Connection timed out The problem is that /etc/cups/client.conf contains the following line: ServerName 10.0.0.72 SWAT started up and I was able to access SWAT via the web browser once I removed the ServerName line listed above.
What led to the false configuration? Did you use YaST? How can this be reproduced? The YaST logfiles would be required as well then. Thanks.
I did not use YAST. I installed the SAMBA server package (version listed above). I then enabled the SWAT in the /etc/xinetd.d/swat file. Started xinetd using rcxinetd start. Tried to connect using a web browser to http://localhost:901. When the login page did not display, I started to figure out why. I saw that swat was listening on port 901 (netstat -na | grep :901). Then viewed to /var/log/messages but did not see any error related to swat. Then reviewed the /var/log/samba/log.swat file. This is where I discovered that SWAT was trying to contact a CUPS server at 10.0.0.72. I looked at the /etc/cups/client.conf and found the ServerName entry for 10.0.0.72. I removed the ServerName line, restarted xinetd, and succesfully connected to swat using at http://localhost:901.
Where do you suspect the server line to come from? I guess the configuration file was written by YaST before that... do you have any server in your network with that IP? I cannot impress this would be a default value at installation time...
I thought that the client.conf file might have a ServerName entry in it that should not be there. I believe you are saying this is not true and the ServerName line was added during the install of SUSE Linux 10. I do not have a 10.0.0.x network that I have been connected to so I am not quite sure how YAST would have added this specific network. I wanted to report this so you could check the client.conf file to verify that it does not contain an extra ServerName entry. If it does not, then this bug report should be closed. Thanks for the quick response!
Please attach the YaST logfiles (/var/log/YaST2) here. The reason for this configuration might be located there. Further I verified that per default there is only a commented ServerName directive in the client.conf, so this was obviously caused by YaST...
Created attachment 61473 [details] YAST2 logs
Michal: Is this something for you? I think the problem was a faulty printer configuration done by YaST. If not, assign it back to us.
I think not. The original config is from cups package. I have a fresh installation of SL10.0 and have only commented lines. And Mike wrote he didn't use YaST. I will check log files in a moment
No is not mine When yast2-printer module starts (in intallation process) this line was already writen. I see it in y2log-6 line 1964 CUPS.ycp:101 Read server host name: >>10.0.0.72<<
A suggest to look at samba configuration. Maybe when samba starts, any server fron neighborhood offers network printer and samba writed it.
So we're back where we started. Mike: I suggest you remove all packages and the configuration (you might create a backup before) and reinstall them. Then use YaST for configuration and see if there is an actual problem.
Mike: Please reopen this if the same problem occurrs after you tried a fresh installation of this subsystem. Thanks.
mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)
Closing old LATER+REMIND bugs as WONTFIX - if you still plan to work on it, feel free to reopen and set to ASSIGNED. In case the report saw repeated reopen comments, it's due to bugzilla timing out on the huge request ;(