Description of problem: I just updated a Fedora 12 to Fedora 13 (beta) using preupgrade, and in this process all my old printer configurations were wiped out. So, I decided that I'd at least add my local network (LPD) printer. Starting the program and clicking "+ Add" immediately brings up a requester for the root password "Authentication is needed to read and modify firewall settings". Then a popup appears asking me if I want to adjust the firewall. There is absolutely NO reason why printing from my laptop should require ANY modification to the firewall, so I decline. Another window pops up, and immediately another request for the root password appears: "Privilegies are required to get devices." Now, this one I first tried denying, since I'm configuring a network device over which this laptop administrator account has zero control. This, as it turns out, means that the configuration utility will not even display options for configuring LPR or IPP. So... I enter the root password a second time. I pick the LPR option, fill in the details, wait a loong while as it "searches for drivers", after which I'm still forced to pick manufacturer and model out of the list - I have no idea if this means it failed some automatic search, or this just is how long it took it to put together the list of manufacturers. I pick my manufacturer, model and driver. Enter the name of the queue and apply... And is asked, once more, for the root password as "Privielgies are required to add/remove a printer". Well.. DUH!? And guess what? If I want to configure a second printer, I have to go through another three root-password entries. And if you dawdle at prompt two or three, another, different looking, prompt for the root password will pop up WHILE the other one is still onscreen. How about you just trash this whole configuring-as-the-user crap, and just put a sudo-wrapper around the whole program instead? Version-Release number of selected component (if applicable): system-config-printer-1.2.1-1.fc13.i686 How reproducible: Just try to add a printer. No, really, try - I dare you. Steps to Reproduce: 1. Kiss your sanity goodbye 2. System->Administration->Printing 3. Select "Add" 4. Type root password 5. Click "no" 6. Type root password 7. Select "LPD/LPR host printer" 8. Enter host + queue 9. Wait. 10. Wait 11. Grab a coffee 12. Wait 13. Check google news/slashdot 14. Select manufacturer, model and driver. 15. Wait 16. Wait 17. Select name for printer, click Apply 18. Type root password Actual results: Grey hairs, bladder issues and having to type the root password a lot. Expected results: Under no circumstances should adding a printer require you to enter the root password more than a single time. And it used to be that adding a printer was something you could do in less than half a minute, but in this version, you're looking at many minutes of just waiting for god-knows-what. Additional info: Also tested on another machine, this time with IPP and a password protected printer. It used to be you could just enter this as user:password@printerhost, even though there were no fields for entry of user/password. But in the latest version, it appears the tool actively strip these out, thus making it impossible to configure such a printer using system-config-printer. I suppose I shouldn't be surprised...
(In reply to comment #0) > I just updated a Fedora 12 to Fedora 13 (beta) using preupgrade, and in this > process all my old printer configurations were wiped out. So, I decided that > I'd at least add my local network (LPD) printer. This is problem number 1. You shouldn't have lost any printer configuration. Problem number 2 is that you're seeing lots of password dialogs. Unfortunately the default Fedora policy prevents us from shipping a 'user-friendly' security policy for PolicyKit-enabled applications in the "main" Fedora distribution (but I hope there will be a 'desktop' spin or something similar soon). Here is how to adjust your configuration in the mean time: https://fedoraproject.org/wiki/Printing/ConfigurationTool#PolicyKit_configuration > I pick the LPR option, fill in the details, wait a loong while as it "searches > for drivers", after which I'm still forced to pick manufacturer and model out > of the list - I have no idea if this means it failed some automatic search, or > this just is how long it took it to put together the list of manufacturers. It's how long it takes the first time. CUPS caches some parts which makes it faster for subsequent tries, but it's still pretty slow. > And if you dawdle at prompt two or three, > another, different looking, prompt for the root password will pop up WHILE the > other one is still onscreen. This is problem number 3. Sounds like the D-Bus call timeout is too short. > How about you just trash this whole configuring-as-the-user crap, and just put > a sudo-wrapper around the whole program instead? Not going to happen. The real solution is to have PolicyKit configured correctly. > Under no circumstances should adding a printer require you to enter the root > password more than a single time. That's not how PolicyKit works -- it protects specific operations, as per the system's security policy. > Also tested on another machine, this time with IPP and a password protected > printer. It used to be you could just enter this as user:password@printerhost, > even though there were no fields for entry of user/password. But in the latest > version, it appears the tool actively strip these out, thus making it > impossible to configure such a printer using system-config-printer. This is problem number 4. CUPS strips this out intentionally when retrieving this information, but not when setting it. It may be that it shows without 'user:password@' in the printer properties but is correctly set in the configuration. Could you check in /etc/cups/printers.conf to see if that's the case here? So, 4 problems: 1. Printer configuration is lost, presumably a preupgrade bug 2. Default PolicyKit configuration, nothing can be done about this for Fedora 13, cups-pk-helper is contrained by the Fedora policy on this 3. IPP authentication dialog appears after a while (how long?) when PolicyKit dialog on-screen 4. IPP auth URI elements are stripped, which may be intentional
> So, 4 problems: > > 1. Printer configuration is lost, presumably a preupgrade bug This one I'm prepared to live with, if nothing else, I jumped the gun on F13 and installed the pre-release. > 2. Default PolicyKit configuration, nothing can be done about this for > Fedora 13, cups-pk-helper is contrained by the Fedora policy on this I'm not clear on what this Fedora policy is, but I'd have hoped there also existed a don't-make-the-users-go-ape policy that supersede other policies? (I do understand the technical reasons why I see three+ root-password entries. I just don't agree that those are good enough to motivate the pain users are subjected to.) > 3. IPP authentication dialog appears after a while (how long?) when PolicyKit > dialog on-screen A minute? Two? It happened once while doing the original config, and several times while writing up the bug report (as I then stepped through the process while writing). > 4. IPP auth URI elements are stripped, which may be intentional It used to be (until F12) that the UI didn't show the user/pass, but that they were actually there, as you describe. With F13 pre-release, they appear to be stripped out completely. Which, if intentional, is bad. Tried to configure another printer using the interface on the machine I previously had problems setting the printer up on (a x86_64). Now, I can't get the IPP/LPD etc options to show even after giving the correct root password. (On this machine, I set the printer up using CUPS directly, so perhaps this makes system-config-printers upset?) On another system (an i686), I tried setting the password protected IPP printer up as I did in F12, and it worked.
I've filed bug #596711 to track problem 2. Remaining: 1. Printer configuration is lost, presumably a preupgrade bug - still think this is worth investigating but might be hard to reproduce 3. Two auth dialogs at once - needs investigation 4. IPP auth URI elements are stripped - CUPS has been stripping user/pass elements from URIs since about F-11 as far as I remember (In reply to comment #2) > Tried to configure another printer using the interface on the machine I > previously had problems setting the printer up on (a x86_64). Now, I can't get > the IPP/LPD etc options to show even after giving the correct root password. > (On this machine, I set the printer up using CUPS directly, so perhaps this > makes system-config-printers upset?) No, system-config-printer is just another CUPS client, like lpadmin and like the web interface.
I recently upgraded a system from f8 to f14. It is on a smb network and password changes are required every few months to access my network printers. Previously with f8, the printer config gui allowed you to go in and enter a new password. Now, that seems to not be immediately available (unless possibly you delete and re-add the printer, requiring much searching, waiting and many password entries as described in this bug). Now, with f14, to change the password, on smb:// based printers at least, you have to edit the /etc/cups/printers.conf file and change your password in there and restart cupsd. For me this is not really bad but it is a change from the way f8 worked from a 3 years ago. I was going to enter this as a new bug (or issue) but saw that this bug report kind of touched on this already.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
gene: I think you ought to open a new bug report, really. This one already touches enough issues.
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.