Bug 463240 - Internal Server / Permission Denied Error while adding or removing packages after 0.1 to 0.2 update
Internal Server / Permission Denied Error while adding or removing packages a...
Product: Spacewalk
Classification: Community
Component: Installation (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Pradeep Kilambi
Jesus M. Rodriguez
Depends On:
Blocks: space05
  Show dependency treegraph
Reported: 2008-09-22 13:11 EDT by Brian Beaudoin
Modified: 2009-09-17 03:08 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-17 03:08:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Brian Beaudoin 2008-09-22 13:11:41 EDT
Description of problem:

After updating from Spacewalk version 0.1 to 0.2 using the instructions at https://hosted.fedoraproject.org/spacewalk/wiki/HowToUpgrade, "Permission denied" errors were received when attempting to upload new packages to the Spacewalk server.

Steps to Reproduce:
1.  Install Spacewalk 0.1
2.  Upload a good number of packages using "rhnpush"
3.  Upgrade (https://hosted.fedoraproject.org/spacewalk/wiki/HowToUpgrade)
4.  Upload a package whose md5sum matches the first three characters of another packages's md5sum

Expected Result:  Package will be uploaded without issue
Actual Result:

Internal server error 500 Internal Server Error
Error pushing updates/packages/tomcat5-admin-webapps-5.5.23-0jpp.7.el5_2.1.i386.rpm: Error 500Error Message:
    Package upload failed: [Errno 13] Permission denied: '/var/satellite/redhat/1/1cc/tomcat5-admin-webapps'
Error Class Code: 50
Error Class Info: Invalid information uploaded to the server (500)
Waiting 3 seconds and trying again...
Giving up after 3 attempts

Additional info:

It appears the issue is caused by incorrect ownership (root:root) of the directories between /var/satellite/redhat/1/ and the package.  The package itself was owned by apache:apache and both /var/satellite/redhat/1/ and /var/satellite/redhat/ were owned by apache:apache.

Running the command "chown -hR apache:apache /var/satellite/redhat/" corrected this for me.
Comment 1 Jesus M. Rodriguez 2009-01-16 20:37:16 EST
Let's make sure the upgrade scripts retain proper permissions.
Comment 2 Jan Pazdziora 2009-01-19 05:58:19 EST

could you review update-packages and/or updatePackages.py and retain the permissions / ownership?

Thanks, Jan
Comment 3 Pradeep Kilambi 2009-02-19 17:17:33 EST
the update script always retains the permissions on that directory:

# update-packages --db user/password@sid
Connecting to user/password@sid
standby: ######################################## - Complete!
Transaction Committed! 
# ls -l /var/satellite/
total 16
drwxr-xr-x 4 apache root 4096 Feb 11 16:40 redhat
drwxr-xr-x 3 apache root 4096 Feb 12 16:35 rhn
Comment 4 Jesus M. Rodriguez 2009-04-14 10:11:34 EDT
Spacewalk 0.5 released.
Comment 5 Miroslav Suchý 2009-09-17 03:08:19 EDT
Spacewalk 0.5 has been released for long time ago.

Note You need to log in before you can comment on or make changes to this bug.