[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse
Subject:    Re: [opensuse] Printer cups, pam and samba authentication problems
From:       Marc Chamberlin <marc () marcchamberlin ! com>
Date:       2009-07-13 20:41:21
Message-ID: 299825281.5121247517682163.JavaMail.root () bigbang
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]