Description of problem: When activating a certificate on a Satellite that has exhausted its entitlements, rather than entitling machines and allowing the Satellite to activate properly, it simple states "ERROR:: You do not have enough entitlements in the base org." Version-Release number of selected component (if applicable): 5.2 (I am pretty sure this happens on 5.1 and 5.0 as well) How reproducible: very Steps to Reproduce: 1. Register a Satellite to RHN with a number of entitlements 2. Register clients to the Satellite 3. Create a new certificate with less entitlements than there are machines registered to the Satellite (for example, if there are 200 machines registered as servers, create a certificate with only 10 server entitlements) 4. Register with the new certificate. Actual results: Registration fails with "ERROR:: You do not have enough entitlements in the base org." If the customer has an expired certificate, they cannot get into their Satellite to manually deactivate their machines--thus leaving them without a functioning Satellite. Expected results: Satellite automatically removes entitlements from machines until the maximum number is no long exceeded, then activates the Satellite allowing for full functionality. Additional info: To test, here is a simple for loop that will register 200 clients: #!/bin/bash for i in `seq 1 200` do rhnreg_ks --serverUrl=http://<satellite.url.here>/XMLRPC --username=admin --password=password --profilename=flood --force done ------ Here is full output of -vvv with rhn-satellite-activate: rhn-satellite-activate -vvv --rhn-cert=/root/break.cert RHN_PARENT: satellite.rhn.redhat.com HTTP_PROXY: None HTTP_PROXY_USERNAME: admin HTTP_PROXY_PASSWORD: <password> CA_CERT: /usr/share/rhn/RHNS-CA-CERT Checking cert XML sanity and GPG signature: '/usr/bin/validate-sat-cert.pl --keyring /etc/webapp-keyring.gpg /etc/sysconfig/rhn/rhn-entitlement-cert.xml-31275-1231518628.38701296' Executing: remote XMLRPC deactivation (if necessary). Executing: remote XMLRPC activation call. Database connectioned initialized: refer to default_db setting in /etc/rhn/rhn.conf Attempting local RHN Certificate push (and therefore activation) ERROR:: You do not have enough entitlements in the base org.
Closed. This was already implemented in Satellite 5.1.0. Please follow the instructions below: 1. In the /etc/rhn/rhn.conf file, set web.force_unentitlement=1 2. Restart Satellite (needed one time only) You should then be able to active your new Satellite certificate. Note that modifying the web.force_unentitlement variable is only necessary to decrement an organization's allocated entitlemetns below what they are using. If an organization has more entitlements than are being actively used, you do not need to set this variable to remove them. You can read more about it at: http://www.redhat.com/f/pdf/rhn/Multiorg-whitepaper_final.pdf Specifically look at the "Certificate Has Less Entitlements Than I Am Using" section. I know in this situation its not Multi-Org related, but the solution above should work for this situation. Please reopen if this does not cover your particular situation.
It still seems to be a bug--it still fails: [root@XXXXX ~]# cat /etc/rhn/rhn.conf|grep -i web.force_ web.force_unentitlement=1 [root@XXXXX ~]# rhn-satellite-activate --rhn-cert=break.cert RHN_PARENT: satellite.rhn.redhat.com ERROR:: You do not have enough entitlements in the base org. And, of course, the satellite was restarted. This is a big deal that a lot of our customers are hitting. If they let their old cert expire, we have to issue them a temporary cert with enough entitlements to login just to unentitle enough machines to use their new, permanent certificate. This is after the time wasted trying the new cert that fails. Thus resulting in a lengthy time without a Satellite. Let me know if I can be of any other help.
The whitepaper is completely wrong. web.force_unentitlement doesn't affect rhn-satellite-activate at all. It will always fail if there are not enough entitlements in the base org.
Actually i missread the whitepaper after reading brandon's comment. The whitepaper is correct.
Leaving on -triage - following up to comment #2 by emailing Matt Davis asking for specifics to be gathered. If we have no bug in our code, but our code is not flexible enough - we need to understand so we can look to make improvements in 530 if needed. Cliff
Still waiting for data. For now - leaving on -triage
Xixi, It appears that monitoring is the source of the problem. All of the old certs had monitoring, and had systems using monitoring, while none of the new certs have Monitoring Entitlements. I think we have 2 issues here: 1. Should the satellite code be robust enough to forcibly unentitle machines that lose appropriate entitlements? I know that there is that new tunable in rhn.conf, but it does not appear to work. 2. Why did we stop giving customer's the 20 complementary Monitoring entitlements? I remember vaguely this happening a few months ago, but as it may lead to many issues being created, should this be re-addressed? Thanks for finding the culprit : ) Now to find out the appropriate way to proceed. -- Brian Internal Status set to 'Waiting on SEG' This event sent from IssueTracker by bhamrick issue 264584
(In reply to comment #13) > I think we have 2 issues here: > 1. Should the satellite code be robust enough to forcibly unentitle > machines that lose appropriate entitlements? I know that there is that > new tunable in rhn.conf, but it does not appear to work. > Per Engineering, the rhn.conf configuration works, this is just an edge case it needs to handle, so that's the main issue with this BZ right now. I.e., if you don't have an entitlement anymore for some reason, we shouldn't block you from activating but instead activate while unentitling the existing ones being used if they're no longer entitled. Satellite Engineering: Would it be possible to either add an option to satellite-activate - telling user what's about to be unentitled, and giving them an option to choose not to activate for the time being and to purchase the entitlements instead? B/c it's alot harder if at all possible to track down what had been unentitled and to restore entitlements. It's also possible that occasionally certificates have wrong slots by mistake, in which case, this will alert the user and prevent unnecessary pain. > 2. Why did we stop giving customer's the 20 complementary Monitoring > entitlements? I remember vaguely this happening a few months ago, but as > it may lead to many issues being created, should this be re-addressed? > As discussed on IRC earlier, we're no longer giving away the 20 complementary each of Monitoring and Provisioning entitlements. Looking into official/public-facing statements. Thanks, Xixi
So after speaking with Todd Sanders, for the short term we're just going to add a message to rhn-satellite-activate to tell the user what entitlement is the problem. Here's some example text: ERROR: You do not have enough unused 'monitoring_entitled' entitlements in the base org. Please un-entitle systems from this entitlement until there are at most 0 used. Long term, we need to add logic to actually un-entitle systems after some warning. I'm going to clone this bz to another for the long term fix. commit 36328970c7b054675ed733585cb7ea5e610430f6 tree a92fee1dbc3a64feaff18f16483305d0da3f8c83 tree | snapshot parent 9a6c890561f61c47b9de774524fe2f5dd74a203a commit | diff
To reproduce issue: 1. activate certificate with monitoring 2. Register a system and add a monitoring entitlement 3. Activate a new certificate without monitoring
QA Verified this particular fix. There's a lot else going on with this message right now, but it's all out of scope of this bz.
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