Bugzilla – Bug 457104
Verify Installed Software reports problem in cups, Repair has no effect
Last modified: 2017-08-11 13:47:49 UTC
(Split off from bug 456981 as requested by Andreas Jaeger) On the installed system I see no problem: # rpm --verify cups # Rebooting from the RC1 DVD into "Repair Installed System" -> "Expert Tools" -> "Verify Installed Software" reports a problem in cups, illustrated by the attached screenshots. Checking "cups" and selecting "Repair" has no effect.
Created attachment 258484 [details] Problem report from "Verify Installed Packages"
Created attachment 258485 [details] Screenshot from "Show Log"
Your "show long" screenshot shows that you (or one of your packages) change group ownership of directory "/usr/share/cups/drivers". Don't know what to do here. It's not an issue with cups! The "Repair Installed System" should be able to allow such changes in the system, or repair this. At least I'm unable to change the situation. Reassign back to AJ.
It's IMO not up to the verification tool to decide whether some change is acceptable or not. If a file is likely to change, the packager should indicate this by using an appropriate %noverify entry in the spec file. /cups/drivers is group writable directory (0775), so it might be important to see which group now has write permissions. We IMO should not change the tool to not report those changes. AJ? --- - It may be an enhancement to display details e.g. like /usr/share/cups/drivers ......G. : drwxrwxr-x root ntadmin actual : drwxrwxr-x root soemthingelse - To allow the user to ignore certain 'errors'. - And to detect whether such a change was caused by e.g. /etc/permissions.
I don't know what YaST checks and what it should do. I'm also confused since rpm does not report problems but YaST does. If there's a packaging bug, it should be fixed in the package.
I agree with Michael, the above change of group ownership should be set back to ownership as it is in the original rpm package. The "ntadmin" group ownership is done with intention as samba can easily deploy its drivers there. Changing it to any different group can make the use of samba very hard. I think that's the primary job of the system repair function: fixing such changes in the system. It's only worth a discussion, whether this change should be done after asking back the user or not.
*** Bug 457105 has been marked as a duplicate of this bug. ***
*** Bug 457106 has been marked as a duplicate of this bug. ***
(In reply to comment #5 from Andreas Jaeger) > > I'm also confused since rpm does not report problems... That's the important piece! Now reading "rpm --verify shows no error msg" and looking again at the "Show Log" output, I suspect the (U)ser and (G)roup mismatches in the repair-system are due to incomplete /etc/passwd and /etc/group. If the repair-systems /etc/group e.g. does not contain ntadmin, rpm will use 'root' for it. Thus verification fails: # grep ntadmin /etc/group # rpm -V cups S.5....T c /etc/cups/cupsd.conf ......G. /usr/share/cups/drivers In the running system, ntadmin is known, thus verification succeeds: # grep ntadmin /etc/group ntadmin:!:71: # rpm -V cups S.5....T c /etc/cups/cupsd.conf
I try run rpm verify with root specified in mounted drive, but rpm still uses /etc/group instead /mnt/etc/group. Michael is it intended?
No, I think this is a bug in rpm. It should be consistent with '-i', where it uses the passwd/group from the chroot directory.
OK, so I reassign it. Steps to reproduce is easy - rescue mode mount /mnt rpm -r /mnt -V cups expected result is that it doesn't have any group problems.
Well, this bug has been open for ages and it is an issue in the software ("rpm") itself rather than in package/distribution, thus the report should go there.