-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2009-07-13 at 13:41 -0700, Marc Chamberlin wrote:
Carlos E. R. wrote: ... 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!
Ah...
I then decided to risk another headache and dug into PAM further (what a freaking nightmare to understand!!!
It is indeed :-(
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!
Wow.
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!
It could be the nscd daemon, it is configured to do that. Did you say which version of suse runs the server? It is weird, because that daemon crashes quite often, it is buggy as hell. Thus, in your situation, "rcnscd restart" should have worked as well.
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.
Maybe you can configure the print server not to request password from the client machines - depends on your needs, maybe being on your local network is enough auth.
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....
It will be interesting to learn of your further investigations :-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkpbsPsACgkQtTMYHG2NR9VrCgCggiBY3BQQYhZpl6FDWVSM3b72 u7wAoIk3YUhoIc3oKgTudLbs9zYcVmoR =Cf0V -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org