Description of problem: Candlepin servers will let you re-register a system that is already registered (in case the system forgot its registration info, or is reinstalled). Katello does not allow this and will lock a system out permanently, the katello logs show a primary key error since the system already exists. There is not even a way to delete the system in the katello ui, you need to use the CLI. Need to support the --force option in RHSM. Version-Release number of selected component (if applicable): katello-0.1.92-1.git.34.2858cdd.fc15.noarch How reproducible: Steps to Reproduce: 1. Register a system to katello with RHSM 2. on the client system, "subscription-manager clean" so the system forgets its registration info. 3. try to run "subscription-manager register" again 4. Also try "subscription-manager register --force" Actual results: Cannot reregister Expected results: 2nd register succeeds with --force Additional info: The error on the 2nd register can be fixed by running katello -uadmin -padmin system unregister --org ACME_Corporation --name [client hostname] on the katello server
*** Bug 798999 has been marked as a duplicate of this bug. ***
Investigating the bug I found out following: Help for --force is a little ambiguous --force register the system even if it is already registered It looks like --force is meant for re-registration when system is registered and RHSM knows that, see [1]. So --force is not applicable in this situation. I also found related bug [2], It looks like described behavior could be intended. [1] https://fedorahosted.org/candlepin/browser/client/java/src/main/java/org/candlepin/client/cmds/RegisterCommand.java#L106 [2] https://bugzilla.redhat.com/show_bug.cgi?id=760548
Like Petr said, --force option is intended to be used in case the consumer is already registered AND knows about it, which means the consumer cert is on the system (which is deleted by clean command). However, subscription-manager has another option, that might be useful in this situation: subscription-manager register --consumerid 1234-5678-1234-5678 This utilizes already generated consumer on server side: no new consumer is created. After calling this command the --force option works, because the consumer cert is on the consumer system again. Another way would be to reimplement subscription-manager in a way, that if the server refuses to register the machine for the reason that the machine already exists, --force option is provided and user is authorized to unregiser the already-existing machine, it would unregister this machine. This would be more or less only Katello specific feature in subscription-manager, because Candlepin itself doesn't restrict the consumers on unique names.
Ivan, if there's a way to use SM to get the consumer ID, then this may just be a doc issue.
OK using consumer id from the katello UI system details page does work. The question is, will a user account that can register also be able to retrieve his own consumer ids with the same credentials (no matter how his permissions are set)?
This is not possible just with permissions to register a machine. We could add the information about the current consumerid that the user could use, but I'm not sure it's secure enough: it would enable to take identity of another system. Therefore the user should be also have the permission to read systems, and with this permissions he already could use katello UI or CLi to do that.
Just a note: "There is not even a way to delete the system in the katello ui" in the original bug description is seems to be incorrect.
The proper solution is one-liner. Comment out this line: validates_uniqueness_of :name, :scope => :environment_id Then we get multiple systems, we should maybe add "Registered" column to help users to distinguis bethween systems with the same name. UI is fine (it also shows the green/red bulb which is perfect), in the CLI we may need to add column. But this should NOT definitely be in the errata. Example: ----------------------------------------------------------------------------------------------------------------------- Systems List For Org [ ACME_Corporation ] Name Uuid Ipv4 Address Service Level ----------------------------------------------------------------------------------------------------------------------- sys1 806f130c-9922-4f4b-b4b1-ed706c824fa9 None znig.lan e1ae92bb-bd9c-4c8d-a0e7-bc4d79f92439 127.0.0.1 znig.lan f165cea1-6e5b-47aa-94d0-fb21126525ad 127.0.0.1 znig.lan 277463bf-9d76-421b-852d-a21d8a7b55bb 127.0.0.1
Aaaah it't not one-liner at all: # kk system info --name znig.lan Found ambiguous Systems [ znig.lan ] in Environment [ None ] in Org [ ACME_Corporation ] It seems we rely heavily on name/environment combinations instead UUIDs. Than the constraint is correct and we should only doco that the system should be removed first to re-register it. For security reasons we can not leverage --force for this. Mike? Bryan? (see last three comments).
I am not sure if this is clear. I don't know how to fix this. We have a constraint on name/environment combination while in Satellite/Hosted there is no such a constraint. In other words: In Katello it is not possible to register two systems with the same name within one environment. In Satellite/Hosted it is possible to do this. We cannot remove this constraint because we rely on this, e.g. CLI command "katello system xxxx --name systemname --env environmentname" would not work anymore (returning more than one - expected - entry). Suggestions?
*** Bug 829722 has been marked as a duplicate of this bug. ***
In CFSE 1.1 we will remove the uniqueness name constraint for systems and allow duplicates.
Mike, should I remove the constraint now?
I would vote that we : 1) remove the contraint and 2) Allow users to use --id in addition to --name in the cli. If they pass in --name and it is ambiguous, I am fine with failing with text if we include the "try --id"
https://github.com/Katello/katello/pull/550
QE Verified CloudForms System Engine Version: 1.1.12-7.el6cf
Not sure how this was passed (by me...) I might've written into the wrong browser tab. Will retest.
QE Verified for real this time. [root@dhcp129-83 ~]# subscription-manager clean All local data removed [root@dhcp129-83 ~]# subscription-manager register --user admin --password admin --force eb26103b-fbad-4242-ae0b-cae64e529b2b dhcp129-83.rdu.redhat.com CloudForms System Engine Version: 1.1.12-12.el6cf
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-1543.html