[opensuse] Printer cups, pam and samba authentication problems
I guess I must be missing something so need some wonderful guru to bail me out... I am back at one of my most abhorrent tasks at the moment, trying to set up computers around my home/small business network to use a printer attached to a Windoz box. Every time I have to do this, or something similar, it usually involves several days of debugging and lots of cursing at all the incomprehensible layers of security and obtuse or lack of documentation that goes with it. And once again I am stumped... So to boil all this down to a simple example, I have a printer attached to a Windoz box and all of my Windoz machines can use it just fine. All my computers are attached to a simple single network. Trouble is that for Linux, I have to supply CUPS with a special printer driver, from Turboprint, to handle the formatting of data before passing it on to the Windoz machine for printing out. So I have one SuSE 11.0 machine acting as my print server, and I WANT all my other SuSE machines to send their print requests to this central SuSE print server. All are running either SuSE11.0 or 11.1 with KDE 3.5 (I tried KDE4.0 and had so many other problems that I had to give up on it.) The print server has CUPS set up an running, and it alone can successfully send documents to the Windoz computer and print things out on the Windoz printer. So I know I do not have a network/firewall issue between the SuSE printer server itself and the Windoz box. For all the rest of my SuSE machines, I have tried and tried and tried to use Yast to configure each one to "Do all my printing directly via one remote CUPS server" and when configured and testing the remote IPP access, I get a report that there it is successful in connecting to the CUPS server. To bad that YaST does not supply an actual print a test page button for this mode however!!!! That is the real proof in the pudding that one has successfully set things up, but apparently some brain dead designer dropped the ball on that one... (It does supply a print test page button for local CUPS servers, so the designer(s) of YaST got it half right at least) So next I go and try to use an application to print something out.. Zilch! nadda, no joy.. Looking in the cups error.log file all I get is brain dead message telling me that an authentication failure occurred. HUMP! More hours of investigation later I try to use the KDE configuration manager, on one of the client machines, to see if KDE is somehow interfering with my ability to print out remotely from my SuSE machines, and when I use it's Print Test Page 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. WELL GOOD GRIEF!!! This seems to indicate there may be a massive design flaw! If the CUPS server is asking for a user name and password to authenticate a remote request to print something, THEN WHY OH WHY AM I NOT BEING PRESENTED WITH THIS SAME DIALOG BOX EVERY TIME, from any application, to give the cups server a valid user name and password??? What is worse though, is that apparently ONLY ROOT is a valid user of the remote CUPS server, authorized with the remote ROOT's password, to print things out! I search for answers on the server side as well and my research revealed that some monstrosity called PAM is SUPPOSED to be handling the authentication processes. But I think it is ONLY the designers and perhaps someone with a PhD who will be capable of understanding and configuring that mess without receiving outside help. My attempt to do so only left me with a splitting headache! Whatever happened to the KISS principal in user interfaces and client/server model view control frameworks? Object Oriented design of architectures? Use case studies? Nowhere in Yast or the KDE manager, on either the server or client side, can I find a place to enter valid user name/password(s) for using a remote CUPS server, nor is there anyplace in the CUP'S web administrator, and if the apps themselves are not asking for it, via a common dialog utility, then HOW IN THE WORLD AM I SUPPOSE TO AUTHENTICATE MYSELF TO A REMOTE CUPS SERVER? I have tried other approaches as well, such as setting up my SuSE boxes to connect to the Samba server on the SuSE printer server, and have Samba handle to authentication/connection to CUPs but nada, zilch, and no joy there either. FRICK! WHAT A MESS! To make all this even harder, is that there is very little, easy to understand, documentation about the underlying models of how authentication takes place, how Samba, CUPs, and PAM interplay and it appears each is following an authentication model that is uniquely it's own.. And I cannot find any diagnostic tools anywhere for following the authentication process... Nor is there much documentation on how Yast and KDE work to set up printers.. For example, 80% of the time clicking on the help button in the printer setup menus of YaST, results in a blank help dialog coming up! So God only knows what some of the settings actually do or mean! .... So like I said, I am at wits end and need a kind guru to help bail me out! Any takers? Many thanks in advance and sorry if I sound a bit frustrated.. I HATE setting up printers, firewalls and networks in general, regardless of whether it is Windoz, Linux, Macs or Unix OS's; it ALWAYS turns out to be far more difficult than it should be, mostly due to all these layers and layers of obscure complex security features... Might be a good thing to have good security, but IMHO this growing incoherent design is breaking the usability of SuSE/Linux. I OUGHT to be the one in command of these machines but right now I feel like I am a General over a battalion of anarchist mutineers! Marc... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----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-----
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
-----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
Carlos E. R. wrote:
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.
To which all I can do is respond by saying "OMG"!! That scares the devil out of me! Caching passwords seems like it is going to create a LOT of confusion, I could ask why? but not sure I really want to know! I am running SuSE 11.0 on the server. I had troubles with 11.1 so dropped back to 11.0 as I could not have that machine down for very long...
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.
Ok I am attempting to follow your suggestion, and the path seems to have lead me deeper and deeper into the quagmire of PAM... According to the documentation, there are files under /etc/pam.d/ and each one handles the authentication process for the service for which they are named, AND there is a file called cups. So I started to mess around with this file, setting it up to deny all logins, accept any login etc and NOTHING I do to this file seems to have any affect on authentication when I invoke the lp command. Many of these service files don't directly specify how and what modules to use for the authentication process, instead they include a common file called common-auth (which is a link for some odd reason to another file in this same directory called common-auth-pc) so I put in a debug switch there for the pam.unix2.so module and that showed me that it was getting invoked to do authentication for su (super user) but not for cups!! So I tried to fool around with the SU authenticator file and again I could not affect the authentication process for lp and cups.. I don't understand how or why the debug messages are showing up and I am confused about how CUPs and PAM are working together... So bottom line is I am not having much luck figuring out how to turn off the request for a password for CUPS and client machines...
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 :-)
So far, in a word PAINFUL! Thanks again Carlos for your thoughts, I will plug away at it some more tomorrow, too tired myself to continue on tonight... Marc... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2009-07-13 at 23:37 -0700, Marc Chamberlin wrote:
Carlos E. R. wrote:
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.
To which all I can do is respond by saying "OMG"!! That scares the devil out of me! Caching passwords seems like it is going to create a LOT of confusion, I could ask why? but not sure I really want to know! I am running SuSE 11.0 on the server. I had troubles with 11.1 so dropped back to 11.0 as I could not have that machine down for very long...
A question for which I have no answer. Years ago I used to remove that service on small machines, but currently it seems that there are services or programs which relie on that daemon.
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.
Ok I am attempting to follow your suggestion, and the path seems to have lead me deeper and deeper into the quagmire of PAM... According to the documentation, there are files under /etc/pam.d/ and each one handles the authentication process for the service for which they are named, AND there is a file called cups. So I started to mess around with this file, setting it up to deny all logins, accept any login etc and NOTHING I do to this file seems to have any affect on authentication when I invoke the lp command.
Uh, oh... I should have mentioned that you only need to reconfigure cups, not pam, for this trick. It should be in /etc/cups/cupsd.conf. Most settings have this (I don't have a network): AuthType Default Require user @SYSTEM Order deny,allow There is an online manual in the cups server which should say how. http://localhost:631/help/ Getting Started Command-Line Printing and Options Glossary Managing Operation Policies Access Control Recipes http://localhost:631/help/policies.html?TOPIC=Getting+Started&QUERY=#TABLE02 it says you need: Order deny,allow Allow from @LOCAL at least for printing and job control operations, not for configuration. See in the table that you can select using system passwords, or cups mantained passwrods, too. That could be another option, and I thought it was the default. There are some samples on the help file. Pam and cups... I don't know how they interact, I have never touched there. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkpcokgACgkQtTMYHG2NR9X+cACgjlhrwdqhlrWLIwGAfFxjskg+ jvMAmQE0RKT/b9M9WoKtf0GR5Q9OjzJX =4vsM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (2)
-
Carlos E. R. -
Marc Chamberlin