Bug 180986
| Summary: | /etc/cups/* files overwritten regularly | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matt Domsch <matt_domsch> |
| Component: | cups | Assignee: | Tim Waugh <twaugh> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4 | CC: | stimits |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-10-12 16:24:15 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I can confirm that on x86 update to FC4 that imported PPD files are lost. Existing printer definitions remain, but won't allow editing...properties no longer show up, and anything trying to read properties locks up. Command line errors show that it fails to find the imported PPD file. After deleting the printer entry and re-importing the PPD file (this is for a true PostScript printer that does not require filters), the properties can again be listed. However, certain features which appear no longer actually have any effect. In particular, Tray numbers on Xerox printers are no longer honored. Individual PostScript applications which manually set a specific tray will print properly, but the default tray settings are completely ignored from then on in any case where an application does not set the tray (many apps don't understand IPP nor trays, e.g., mozilla, so this is a problem). The version I updated to via yum update are: cups-1.1.23-15.4 cups-devel-1.1.23-15.4 cups-libs-1.1.23-15.4 I'd suggest that during an upgrade some means be made to preserve PPD imports to make them available after the upgrade is done. There's a strong chance that this one problem could cause many of the issues of the original reporter of this bug, i.e., the PPD files are probably the most important component of behavior and individual printer settings relevant to hardware-specific features. 1. You mentioned 'command line errors' -- please show those. 2. Also, how are you importing PPDs? Using the system-config-printer tool, or some other means? In order to show you the command line errors, I would have to first remove or downgrade my cups version, create a configuration that uses import of a PPD file, and then upgrade again...not practical. I wish I had saved the whole output, but at the time I was just trying to get the system working again. The tool used is provided by system-config-printer-gui-0.6.131.3-1, called printconf-gui. This is a regular component under the KDE menu for "System Settings". When run by clicking on it through a menu, there is no way to track stderr. When running it on the command line through xterm/konsole or any other console system, the error says nothing useful other than complaining that the PPD file for the named queue doesn't exist. The import itself is also done with the system-config-printer-gui program printconf-gui. Under the "Action" menu is an item for importing PPD files. I wrote a little script per comment #1 that replaces the cups config files every day; that's kept me going. They get replaced even if an upgrade doesn't happen. Same behavior on FC5 too. Really odd... This will be fixed by Fedora Core 6, which no longer re-writes those files (except via CUPS when explicitly told to by the admin). |
Description of problem: This happens regularly, though I haven't established why yet. My /etc/cups/{cupsd.conf,mime.types,printers.conf} files get overwritten with the original files from the cups package, which causes printers to not work, network connectivity issues, and inability for Windows systems to print to a -raw device. It seems to happen on rpm upgrade, though I believe I've seen it happen even when no rpm upgrade had happened. It's just that every few days I've got to go back and fix these files contents. Furthermore, after manually fixing the files, I've got to run a 'fixfiles restore /etc/cups', though that's expected. Version-Release number of selected component (if applicable): cups-1.1.23-15.4 and earlier, all with FC4 How reproducible: occasional Steps to Reproduce: 1. install cups, configure it the way you want 2. wait a few days, perhaps for a cups upgrade to be released Actual results: /etc/cups/* files revert to preconfigured status Expected results: /etc/cups/* files stay configured Additional info: