Bug 119115

Summary: RFE: real error mesage when dir repository backend can't access file
Product: Red Hat Enterprise Linux 3 Reporter: Mike MacCana <mmaccana>
Component: up2dateAssignee: Bret McMillan <bretm>
Status: CLOSED WONTFIX QA Contact: Fanny Augustin <fmoquete>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0Keywords: Reopened
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: 2007-10-19 19:28:32 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:
Bug Depends On:    
Bug Blocks: 120092    

Description Mike MacCana 2004-03-25 06:28:51 UTC
Description of problem:
When file permissions don't allow up2date to access a file, the
directory repository backend will spit tons of python. 
error: read failed: Permission denied (13)
Traceback (most recent call last):
  File "/usr/sbin/up2date", line 1188, in ?
    sys.exit(main() or 0)
  File "/usr/sbin/up2date", line 766, in main
    fullUpdate, dryRun=options.dry_run))
  File "/usr/sbin/up2date", line 1051, in batchRun
    batch.run()
  File "up2dateBatch.py", line 58, in run
  File "up2dateBatch.py", line 96, in __findPackagesToUpdate
  File "up2dateBatch.py", line 96, in __findPackagesToUpdate
  File "packageList.py", line 117, in run
  File "rhnPackageInfo.py", line 315, in getAvailableAllArchPackageList
  File "rhnPackageInfo.py", line 153, in availablePackageList
  File "rpcServer.py", line 110, in doCall
  File "repoDirector.py", line 20, in listPackages
  File "rpmSource.py", line 226, in listPackages
  File "/usr/share/rhn/up2date_client/repoBackends/dirRepo.py", line
129, in lis
tPackages
    hdr = rpmUtils.readHeaderBlob(hdrBuf.unload())
AttributeError: 'NoneType' object has no attribute 'unload'
done

The real error message tends to get lost amongst all the tracebacks. 

It'd be better to fail fail with a real error message explaing the
problem and listing the name of the file.



Version-Release number of selected component (if applicable):
up2date-4.3.11-2.1.1

How reproducible:
Always

Steps to Reproduce:
1.Attempt to install a package off an dir type repository that the
local root user doesn't have access to. For example, an NFS export.

Actual results:
up2date will spew tons of python, burying the import stuff amongst a
bunch of tracebacks. 


Expected results:
up2date should give an error message explaining that a file could not
be accessed and specifying the name(s) of the file(s)

Additional info:

Comment 1 Suzanne Hillman 2004-03-31 22:21:49 UTC
Internal RFE bug #119630 entered; will be considered for future releases.

Comment 2 Suzanne Hillman 2004-04-22 14:39:34 UTC
Thank you for the suggestion. It was passed along to product
management, but not committed for a future release.

Comment 3 Mike MacCana 2004-04-23 00:59:59 UTC
Closing this as notabug is *terrible*. 
* The message clearly is a bug. A Python traceback does not constitute
an error message.
* Having something like this in a supposedly finished OS look really
unprofessional. 
* The bug shouldn't be difficult to fix.

Comment 4 Mike MacCana 2004-07-21 04:50:19 UTC
Ping?

Seriously, we should not consider crashing Python an adequate error
message.

Comment 5 Adrian Likins 2004-08-25 21:11:24 UTC
I think the bug was originally closed because it was
marked as an RFE when it got imported into the feature
request tracker. 

Comment 6 Red Hat Bugzilla 2007-02-05 19:14:38 UTC
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.

Comment 7 RHEL Program Management 2007-10-19 19:28:32 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.