After upgrading a working setup for a remote shared cups printer from Fedora 17 to Fedora 18, it seems if anything at all enters the local queue for the remote printer, all desktop users logged in on the local system gets a popup dialog: "Enter an username and a password to complete the task" Username: root Password: No matter what the user attempts to do (except actually providing the root password) causes the window to pop back up again. If the user were lucky enough to have a terminal application up, it can be user to kill/restart the plasma-desktop application. If the window is minimized, it cannot be un-minimized (another bug!) and the whole desktop locks up. I had a very hard time tracking it down to this component as I was mislead by the title of the window and no additional information as to why the root password would be necessary. Version: kde-print-manager-0.2.0-8.fc18.x86_64 (latest from fc18 repo) The remote system owning the printer also runs an up-to-date fc18. Reproducible: Always Steps to Reproduce: 1. Share out a cups printer on a remote system 2. Make that printer available locally 3. Print something to it. Actual Results: In the initial case it does not seem to matter whether the printer actually works or not, in any case all desktops on the system, current and future, that happens to have the print-manager applet enabled in the system tray, are blocked with the dialog. But when I first encountered the problem, the printer was not enabled on the remote node. In that case the printer job got queued, as it should, locally, and the dialog problem seemed completely persistent, even for users logging in after the job was submitted (by another user) to the print queue. In a normal case where the printer is all ok and prints everything successfully, the dialog box still persists for all "old" users, but those logging in after the print job has completed and the queue is empty avoid the issue. Expected Results: * If asking for the root password, please make it clear who you are and why the root password is needed. * in this case I can't see why it is needed - must be a bug in itself? * If a password is requested, please make it possible to avoid supplying it by cancelling the operation. Workaround: - remove the kde-print-manager package from the system and reboot.
Ok, I have a similar setup and I don't have such issue, can you please describe which uri the printer queue that causes problems has? also are you able to compile print-manager from git master? I really want to fix this but I can't see what could be different from my setups, do the remote queue has any special setting such as password or something? is this your work enviroment? Thanks.
Hi, thanks for taking this seriously, I'll try to provide more details: This is a small home network setup. A main Fedora 18 system, the server (fresh install of Fedora 18 reconstructed from a recent backup after a system disk crash) which hosts the printer, a small desktop usb laser printer and home directories via NFS to a second linux system, the client. The client was recently upgraded from Fedora 17 using yum and the procedure documented on the Fedora wiki. On the server, the printer is set up as: --- Name: brother Device URI: usb://Brother/HL-1250%20series (automatically detected and configured by the printer config tools in fc18 !) Policies: Enabled, Accepting, Shared, Access control: Allow printing for everyone (no exceptions) On the client, the printer is set up as: --- Name: brother Device URI: ipp://<server ip address>:631/printers/brother Policies: Enabled, Accepting Access control: Allow printing for everyone (no exceptions) There should be no special password settings.
One difference from a default setup may be that the systems are both set up with static IP addresses and the good-old network service rather than using NetworkManager. To eliminate NFS I created a dummy user with home directory automounted from a local partition, but this user sees the same behaviour.
I also tried to build/and rpm install the latest fedora source from git://pkgs.fedoraproject.org/kde-print-manager.git - did not seem to change anything sources points to print-manager-4.10.0.tar.xz I have set up and built from git://anongit.kde.org/print-manager using similar parameters as the fedora build uses, but there seems to have been som name changes since the Fedora version, I assume these are the ones loaded by plasma-desktop: rpm -ql kde-print-manager | grep plasma_ /usr/lib64/kde4/plasma_engine_printers.so /usr/lib64/kde4/plasma_engine_printjobs.so However my build only contains find install -name '*.so' ./usr/lib64/kde4/kcm_printer_manager.so ./usr/lib64/kde4/plasma_applet_printmanager.so ./usr/lib64/kde4/kded_printmanager.so ./usr/lib64/libkcupslib.so It would be helpful if could give me some "fast path" hints as to how to best proceed.
Sorry for delay, does the other linux users are in the lpadmin group?
My systems have no lpadmin group - they have an lp group but users are not a member of it.
please attach then the cups.conf file
Created attachment 78255 [details] /etc/cups/cupsd.conf from client host
Hi, I failed to setup an environment that presents this bug, however I fixed one of the problems that is blocking plasma when an error occurs. Can you use the git version? so that I can see the debug log and figure out which request is causing the ask for a password. Thanks
Since last time I have got another, new machine with a fresh Fedora install (as opposed to the upgraded one from 17 to 18) On that machine which has the same printer configuration, I have not been able to reproduce with kde-print-manager-4.10.3-1.fc18.x86_64, however the problem persists on the older machine.
Can you please check the groups your users are in? Normally such password requests are due an user which is not on the proper group, on Kubuntu it is lpadmin on fedora it's probably a different one.
Users are only members of their own group both on the working machine and on the machine with this issue. NFS mounted home directories from the same printer server.
It seems the problem disappears if I move to the latest .rpmnew cupsd.conf on the client host
Can you make a diff of both files then? :D
Created attachment 80452 [details] Diff from original cupsd.conf to .rpmnew version (eliminates local changes) Could it be that some part of kde-print-manager tries to access the queue via the default host name for local access instead of using localhost (127.0.0.1) ? Tests were done with printer 'brother'
Hmm I'd put my bets on the Listen on localsocket because the rules seems to be for localhost only. Listen /var/run/cups/cups.sock It's a bit of a guess, we can try removing things by parts?
This fix for this appears to have caused bug 328014