Summary: | Printer jobs queued to a remote cups printer causes persistent root password dialog to appear in (all) user desktops, effectively renders desktop unusable. | ||
---|---|---|---|
Product: | [Frameworks and Libraries] print-manager | Reporter: | Knut Omang <knuto> |
Component: | general | Assignee: | Daniel Nicoletti <dantti12> |
Status: | RESOLVED WAITINGFORINFO | ||
Severity: | critical | CC: | orion |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
/etc/cups/cupsd.conf from client host
Diff from original cupsd.conf to .rpmnew version (eliminates local changes) |
Description
Knut Omang
2013-02-07 21:58:12 UTC
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 |