Bug 169203

Summary: Upload config files to sandbox causes traceback
Product: Red Hat Satellite 5 Reporter: Kyle Gonzales <kgonzale>
Component: Configuration ManagementAssignee: Pradeep Kilambi <pkilambi>
Status: CLOSED CURRENTRELEASE QA Contact: Fanny Augustin <fmoquete>
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: benoc, jfautley, rhn-bugs, tao, tsanders
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: rhn405 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-01-25 05:40:38 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: 170825    

Description Kyle Gonzales 2005-09-24 19:04:04 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 Red Hat/1.0.7-1.4.1 Firefox/1.0.7

Description of problem:
I am unable to upload files into any of my system's sandboxes.  I have used examples from one particular system, but the problem is present on all of them.

I schedule files to be uploaded from the system into its config channel sandbox.  The action gets scheduled successfully.  I run "rhn_check -v" on the system, and I get a traceback which is included below.  In RHN, it shows the action as failed, with this error:

Client execution returned "Fatal error in Python code occured [[6]]" (code -1)

Version-Release number of selected component (if applicable):
rhncfg-4.0-32

How reproducible:
Always

Steps to Reproduce:
1. On system, type "rhncfg-actions-control --enable-all"
2. In RHN web interface, schedule files for upload
3. On system, run "rhn_check" with or without "-v"

Actual Results:  The action failed, and will show the traceback in rhn_check if the verbose flag is set.

Expected Results:  Files should have been uploaded into the system sandbox.

Additional info:

*** From System Event History:
This action will be executed after 2005-09-24 14:41:00 EDT.

This action's status is: Failed.
The client picked up this action on 2005-09-24 14:56:26 EDT.
The client completed this action on 2005-09-24 14:56:27 EDT.
Client execution returned "Fatal error in Python code occured [[6]]" (code -1)
Config Files:
/etc/dhcpd.conf	
/etc/named.conf	
/var/named/172.31.1.rev	
/var/named/ultrasound

*** System Traceback:
[root@shuttle rhn]# rhn_check -v
configfiles.upload (28157517, ['/etc/dhcpd.conf', '/etc/named.conf', '/var/named/172.31.1.rev', '/var/named/ultrasound'])
Traceback (most recent call last):
  File "/usr/sbin/rhn_check", line 174, in run_action
    (status, message, data) = do_call(method, params)
  File "/usr/sbin/rhn_check", line 91, in do_call
    retval = apply(method, params)
  File "/usr/share/rhn/actions/configfiles.py", line 168, in upload
    r = rpc_cli_repository.ClientRepository()
TypeError: __init__() takes exactly 2 arguments (1 given)

Comment 1 benjamin oconnor 2005-10-25 15:16:41 UTC
Verified that this also occurs when trying to import files into a system's local
config channel.  Same version as original complainant.  I believe that this bug
means that there is pretty much no way to get new config files into config
channels, other than copy&paste into the web interface.



same error message follows:
[root@cowboys conf]# /usr/sbin/rhn_check -v
Traceback (most recent call last):
  File "/usr/sbin/rhn_check", line 174, in run_action
    (status, message, data) = do_call(method, params)
  File "/usr/sbin/rhn_check", line 91, in do_call
    retval = apply(method, params)
  File "/usr/share/rhn/actions/configfiles.py", line 168, in upload
    r = rpc_cli_repository.ClientRepository()
TypeError: __init__() takes exactly 2 arguments (1 given)

Comment 2 David Lehman 2005-11-30 18:18:48 UTC
I have a patch in bug 174613
(https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=121643), which
incidentally is the same as this. The patch works for me. Sorry about creating
the dup.

Comment 3 Jason Connor 2005-12-06 16:32:13 UTC
*** Bug 174613 has been marked as a duplicate of this bug. ***

Comment 4 Jason Connor 2005-12-06 18:39:19 UTC
I believe that this has been taken care as a result of fixing bug 170825
Please verify that this now works.

Comment 5 Pradeep Kilambi 2005-12-07 19:02:41 UTC
(In reply to comment #4)
> I believe that this has been taken care as a result of fixing bug 170825
> Please verify that this now works.

1. Reproduced the bug.

2. The bug was not fixed without the patch.

3. Fixed the bug and verified that it works.

4. The fix is on my local tree and waiting to commit.

Comment 6 Mike McCune 2005-12-22 21:54:35 UTC
If this is already fix, any reason it can't go in 406 instead of 410?

Comment 7 Jon Fautley 2006-01-04 15:33:48 UTC
I had a customer with a similar issue to this (in so far as they were also
getting an error saying "TypeError: __init__() takes exactly 2 arguments (1
given)").

I've provided them the test packages, and they've confirmed that this fixes
their issue. I can provide the full logs from this customer if required.

Comment 10 Todd Warner 2006-01-20 22:05:44 UTC
Dupe of bug 170825 - that is PASSES_QA... so this is PASSES_QA. Will be released
with RHN 405.

Comment 11 Todd Warner 2006-01-25 05:40:38 UTC
Released.

Comment 14 Issue Tracker 2007-07-06 17:15:28 UTC
CRM closed, closing this



Internal Status set to 'Resolved'
Status set to: Closed by Tech
Resolution set to: 'Auto Closed'

This event sent from IssueTracker by pdemauro 
 issue 83793