Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sunday, 2009-07-12 at 20:38 -0700, Marc Chamberlin wrote:
...
VIOLA! up pops a dialog box asking me for the password for ROOT!!! So I give it the Root's password for the SuSE printer server and VIOLA! Out comes a test page from the Windoz machine's attached printer!!! Another experiment revels that this dialog box only comes up when I place the KDE configuration manager in administrator mode. And a third experiment revels that it ONLY works for ROOT and not for any other valid users (including myself) of the SuSE computer acting as a printer server.
Weird!
(It is voilà , anyway, or perhaps voila - my French is not that good)
I think you should try command line utilities on the client machines, to determine if it is a kde issue.
You could also attach a local printer to the cups server, and that way get rid of samba for a moment; if the clients machines can print normally, then there is a samba interaction.
Don't forget to check what authentication is required in that server cups configuration, for printing. Ie, who is allowed to print, in theory.
I have heard weird reports before of people attempting to use cups client mode setup before, and, although I'm sleepy today, I think you should try installing one of those clients with the full, standard, cups, and try again.
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEUEARECAAYFAkpa2kUACgkQtTMYHG2NR9WxvgCfR1cJ/wrw4LIKApnifUaFEiDw 69EAl3lGBJa9hud8fCH1aftIGTspvxI= =gL7t -----END PGP SIGNATURE-----
Thanks Carlos for your suggestions, I haven't tried all of them yet, but have made some progress, so thought I would report back... Your suggestion to try printing from a command line, on a client machine (i.e. use the lp command) resulted in a very similar behavior to what I got when using the KDE manager to test the printer. The lp command defaults to sending in the logged in users id to the CUPs server and it then prompts for the password. For my own ID, that failed, so I decided to try the lp command with the -U option and override the user id with ROOT. Then I sent in the ROOT password (for ROOT on the CUP's server machine) and that worked! I then decided to risk another headache and dug into PAM further (what a freaking nightmare to understand!!! like iptables or Samba) and found that I could invoke it to send debug instrumentation messages to the messages log file by adding a DEBUG option to the Auth configuration. Then I sent another lp command from the client, this time using my login id and password, and I looked in the messages file at the results. I could see that cupsd was getting the login id ok but was apparently failing on the password. Now I KNOW I was sending the right password because I have to use it in order to log in to the CUPS server machine in the first place! But this tripped a memory and I have seen this exact same behavior somewhere else (can't remember exactly where and I KNOW this is going to sound a bit bizarre) but I decided to go into Yast (on the server) and reset my user Id password to the exact same password that I am using. (Not too long ago I had changed my own login password on all the machines around here, something I do periodically, and I remember this very same behavior occurring with some other service, and this was the way to fix it, when it too broke) Then just to follow my previous pattern, I also restarted the CUPs daemon. And going back to a client machine and sending a print job with my own id and password WORKED!! It is almost as if something, on the server, is caching passwords and unless it is forced to update it's own internal cached version of passwords, a daemon such as cupsd continues to look for the old password! Again I know this sounds bizarre but I cannot come up with any other hypothesis for what is happening!! (and I think this is the 3rd or 4th time I have seen this pattern...) So I guess that fundamentally, IF YOU GET THE CUPS server and PAM to correctly recognize passwords, that the architecture for sending a print job from a cups client to a cups server does work, but only IF you can also get the client side authentication part working properly and allow the users to authenticate their requests for doing a print. I still maintain that SuSE/KDE3.5 is SERIOUSLY broken in this regards, as GUI based applications are NOT asking the user for authentication information and I, for one, cannot find any way to supply the necessary info, either through the print dialogs, or via some underlying mechanism such as in the Yast printer setup/configuration menus or in the KDE desktop manager. I sure hope KDE4.0/SuSE/YaST combo gets this right! Like I said, I cannot use KDE4.0 as it currently stands so have no way to test/verify whether it works under KDE4.0 or not. I will fool around with setting up a full CUPs system on my client machines again, now that I understand the password issue a little better, and see if I can make headway.... Marc... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org