Bug 63359

Summary: rhnreg_ks cryptedpassword does not function properly
Product: [Retired] Red Hat Linux Reporter: Need Real Name <joelmoses>
Component: rhn_registerAssignee: Adrian Likins <alikins>
Status: CLOSED CURRENTRELEASE QA Contact: Jay Turner <jturner>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2CC: gafton, mihai.ibanescu, srevivo
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-02 21:33:31 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:

Description Need Real Name 2002-04-12 22:19:08 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)

Description of problem:
When I attempt to use the --cryptedpassword option with any value, the script 
terminates abnormally with:

Traceback (innermost last):
  File "/usr/sbin/rhnreg_ks", line 244, in ?
    main()
  File "/usr/sbin/rhnreg_ks", line 205, in main
    ret = rhnreg.reserveUser(username, password)
  File "/usr/share/rhn/register/rhnreg.py", line 457, in reserveUser
    ret = doCall(s.registration.reserve_user, username, password)
  File "/usr/share/rhn/register/rhnreg.py", line 153, in doCall
    ret = apply(method, args)
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 689, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 731, in __request
    request = dumps(params, methodname)
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 505, in dumps
    data = m.dumps(params)
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 264, in dumps
    self.__dump(v)
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 275, in __dump
    raise TypeError, "cannot marshal %s objects" % type(value)
TypeError: cannot marshal <type 'None'> objects



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


How reproducible:
Always

Steps to Reproduce:
1. Use --cryptedpassword="anyvalue" on the command line for rhnreg_ks.

	

Actual Results:  Traceback (innermost last):
  File "/usr/sbin/rhnreg_ks", line 244, in ?
    main()
  File "/usr/sbin/rhnreg_ks", line 205, in main
    ret = rhnreg.reserveUser(username, password)
  File "/usr/share/rhn/register/rhnreg.py", line 457, in reserveUser
    ret = doCall(s.registration.reserve_user, username, password)
  File "/usr/share/rhn/register/rhnreg.py", line 153, in doCall
    ret = apply(method, args)
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 689, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 731, in __request
    request = dumps(params, methodname)
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 505, in dumps
    data = m.dumps(params)
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 264, in dumps
    self.__dump(v)
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 275, in __dump
    raise TypeError, "cannot marshal %s objects" % type(value)
TypeError: cannot marshal <type 'None'> objects

Expected Results:  The command should have completed successfully.

Additional info:

There is no documentation for rhnreg_ks (the kickstart register utility). 
Therefore I am unsure as to what type of crypt the command line option really 
needs. It's a moot point, as it doesn't seem to work with ANYTHING plugged in 
there.

Comment 1 Need Real Name 2002-05-08 15:21:00 UTC
Er, anyone out there on this one? This bug is holding up a few things on our 
side, and not knowing exactly what crypt method is accepted by RHN standards is 
keeping us from doing it ourselves.

Comment 2 Need Real Name 2002-05-09 16:15:35 UTC
Just noticed that the "crypted" items have been removed from rhnreg_ks in 7.3 
(seems to be commented out in the script). I'm assuming this is because this 
feature isn't ready within RHN yet? Or is it not going to be implemented?

Comment 3 Adrian Likins 2002-05-13 19:57:53 UTC
Yeah, it was never implemented. Were moving to a token/onetimepass
type of mechanism for this in the future instead, so the options
were removed in 7.3.

Comment 4 Need Real Name 2002-05-13 21:07:19 UTC
Oo. I'd be curious as to how that would work with automated installations.

I need to be able to make a kickstart file that force-registers a system that 
I've had to reload really quick via NFS. If it's a one-time-password situation, 
then I'd hope that the mechanism would still allow me to register the system 
using rhnreg_ks _without_ touching the kickstart file (our recovery process 
depends on that). If it's a token that I have to get from the RHN site FIRST, 
then that would be really difficult to manage.

I was just hoping for crypted support so we don't leave our passwords in the 
clear in the kickstart file itself.