Bug 63359 - rhnreg_ks cryptedpassword does not function properly
Summary: rhnreg_ks cryptedpassword does not function properly
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rhn_register
Version: 7.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-04-12 22:19 UTC by Need Real Name
Modified: 2015-01-07 23:55 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-09-02 21:33:31 UTC
Embargoed:


Attachments (Terms of Use)

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.


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