Description of problem: obtainReactivationKey api generates a key with leading org Id which gives error when trying to register. If we create reactivation key in webUI, it doesnt prepend org-id and the key works fine when registering. Steps to Reproduce: 1. register a system to satellite 2. give provisioning entitlements 3. server.system.obtainReactivationKey(key, sysemid) 4. try to register using above activation key: rhnreg_ks --activationkey="1-846fae7de1b2ac2019f5ff006d21cbe2" --force Actual results: An error has occurred: Error Message: Maximum usage count of 0 reached Error Class Code: 61 Error Class Info: Too many systems registered using this registration token Explanation: An error has occurred while processing your request. If this problem persists please enter a bug report at bugzilla.redhat.com. If you choose to submit the bug report, please be sure to include details of what you were trying to do when this error occurred and details on how to reproduce this problem. Traceback in /var/log/up2date: Traceback (most recent call last): File "/usr/sbin/rhnreg_ks", line 266, in ? cli.run() File "/usr/share/rhn/up2date_client/rhncli.py", line 65, in run sys.exit(self.main() or 0) File "/usr/sbin/rhnreg_ks", line 145, in main other = other) File "/usr/share/rhn/up2date_client/rhnreg.py", line 451, in registerSystem ret = s.registration.new_system(auth_dict) File "/usr/share/rhn/up2date_client/rhnserver.py", line 52, in __call__ raise self.__exception_from_fault(f) up2date_client.up2dateErrors.ActivationKeyUsageLimitError: Expected results: Correct key generated so that we can register system without error.
Although there does appear to be a difference in the syntax of the re-activation key created in the UI (e.g. 'asdf') and the API (e.g. '1-asdf'), the reason for the registration failure is that the activation key is created with a usage limit of 0. As a result, the key is created, but cannot be used. In order to address this issue, the update will be to ensure that the usage-limit is set to 1. This will allow the key to be used once. Regarding the difference between the syntax of the keys generated, have created the following bug to address the inconsistency: 496731
master git commit: 6012c09020776b1edeaf001f35c49dc80200ef85 vader git commit: 128d4d5f96fbab26175c6f0c03bfc1b83cace640
mass move to ON_QA
Brad, So, here are two issues that I am seeing. #1. I register a system and create reactivation key using api client.system.obtainReactivationKey(key, sysemid). It shows up created key in webUI for first time but not after that. [root@rlx-3-20 ~]# rhnreg_ks --activationkey="1-aa3b47975110ee23d6ac98cb6c72229d" --force [root@rlx-3-20 ~]# The system is registered without error and with usage-limit set to 1. So when you generate reactivation key multiple times, call seems to succeed however key cannot be seen in webui after first couple of times. #2. If I invoke api multiple times without actually using reactivation key, old key doesnt seem to have replaced by new key. I can still register systems using old key. (unlike the behavior when we create reactivation key using webui.) If we follow above 2 sequences just using generate reactivation key in webui, we can see the key every time and also the new key is replaced by old key. So, if we try to register using old key it gives invalid key which makes sense. It seems like its a different issue, so I am creating a separate bug on this: Moving this bug to verified as the original issue is resolved.
New bz created is 498275.
Verified on staged (Satellite-5.3.0-RHEL5-re20090724.0) with updates from Aug 20, 2009 [jsefler@jsefler rpcapi]$ ant -Dtestcase=obtainReactivationKey ... invoke-tests-testcase: [echo] [echo] -------------------------------------------------------------------- [echo] Running obtainReactivationKey ... [echo] -------------------------------------------------------------------- [echo] [mkdir] Created dir: /home/jsefler/workspace/rpcapi/reports [junit] Running com.redhat.rhn.rpc.api.system.obtainReactivationKey [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 10.638 sec moving to RELEASE_PENDING
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-1434.html