What to do when yum or up2date command fails with RHN account has been disabled for 'Abuse of Service' ?

Solution Verified - Updated -

Environment

  • Red Hat Network (RHN) Classic
  • Red Hat Enterprise Linux (RHEL)

Issue

  • While trying to execute yum or up2date it fails with Error Class Code: 49. How can it be fixed?
  • Command yum or up2date fails with Abuse of Service detected for server test.example.com :
Error Message:
    Abuse of Service detected for server test.example.com (1030392459)
Error Class Code: 49
  • Using yum or up2date the following error is given:
Error Message: 
    Abuse of Service detected for server server1.example.com (123456789) 
Error Class Code: 49 
Error Class Info: 
     You are getting this error because RHN has detected an abuse of 
     service from this system and account, This error is triggered when 
     your system makes too many connections to Red Hat Network, This 
     error can not be triggered under a normal use of the Red Hat Network 
     service as configured by default on Red Hat Linux, 

     The Red Hat Network services for this system will remain disabled until 
     you reduce the RHN network traffic from your system to 
     acceptable limits.

     Please log into RHN and visit https://rhn.redhat.com/help/contact.pxt 
     to contact technical support if you think you have received this message in error
  • Abuse of Service detected.

Resolution

To avoid this, we need to ensure that there are no combinations of Red Hat Update Agent polls, cron jobs, puppet, etc. that access Red Hat Network with greater frequency than once every hour. In the event that a machine has been blocked due to a detected abuse of service, it can be re-enabled by two ways:

  • A registered system gets 100 checkins per day. However the checkin counter is incremented on both failed checkin attempts as well as successful attempts. Hence Waiting till "Tomorrow" so that the system would be unblocked and should be allowed more checkins without being rejected. But sometimes it is possible that the user built up so many failed checkin attempts that it would take multiple days (with each day providing 100 more checkin attempts) for the user to be allowed to checkin again. Hence, the user will need to re-register their systems.

  • Login to the Red Hat Network web interface, delete the existing system profile, and re-register the system. To register the system, run either up2date --register (for a Red Hat Enterprise Linux 3 or 4 machine) or rhn_register (for a Red Hat Enterprise Linux 2.1, 3, 4, 5, or 6 machine) on the machine as root user in order to recreate system profile.

    • Note to remove profiles
      To remove the system profile, can be done by logging into the Customer Portal
    • If you registered profiles with Subscription Manager you can access:
      -> Customer Portal -> Subscriptions -> Red Hat Subscription Management -> Subscriber Inventory
    • If registered with RHN Classic you can acccess:
      -> Customer Portal -> Subscriptions -> RHN Classic Management -> All Registered Systems
  • For additional issues involving Error Class Code: 49 see Error Class Code: 49.

Root Cause

This occurs when a System has been flagged as connecting to Red Hat Network (RHN) more frequently than 100 times per day after the first 1500 check-ins since the system was first registered with Red Hat Network. A machine that has been registered for a week would be rejected after 2200 check-ins.

There is no advantage to be gained by checking in every 5 minutes that cannot be achieved by checking in every 60 or 120 minutes.  If the default check-in interval of 240 minutes is not enough, then you can configure cron jobs or the Red Hat Update Agent daemon to connect with Red Hat Network every hour or every other hour, which should be sufficient, and is recommended. The Red Hat Update Agent is configured by editing the file /etc/sysconfig/rhn/rhnsd and modifying the value of INTERVAL, which specifies the number of minutes between checks.

This can also occur if the system if a cloned virtual machine and the systemID (/etc/sysconfig/rhn/systemid) was not removed prior to cloning the system.

If the system was running a reposync command, this can also cause the error message as it uses the rhnplugin

Comments

There was a bug (Red Hat Bugzilla # 546676) affecting Red Hat Enterprise Linux 5 Xen hosts (Dom0) with rhn-virtualization-*12 packages installed which has been fixed with Red Hat errata RHBA-2010-003. If still the issue persists then feel free to contact Red Hat Support.

Diagnostic Steps

  • An RHN API script like the following may be helpful for showing how frequently systems are checking-in with RHN.
  • The script can be run via cron every, say, 5 or 10 minutes to get a list of systems and their last check-in time.
  • It shows the 20 (or less) systems that have most recently checked-in with RHN.
#!/usr/bin/python
import xmlrpclib
from operator import itemgetter

saturl = "http://xmlrpc.rhn.redhat.com/rpc/api"
username = "rhn-username"
password = "rhn-password"

client = xmlrpclib.Server(saturl, verbose=0)
sessionKey = client.auth.login(username, password)

systemList = sorted(client.system.listUserSystems(sessionKey), key=itemgetter('last_checkin'), reverse=True)
count = 1
for system in systemList:
    print "ID: %s  Profile: %-40s  Last Checkin: %s" % (system['id'], system['name'], system['last_checkin'])
    count += 1
    if count > 20: break

client.auth.logout(sessionKey)
  • Example output:
$ python ./rhnGetCheckins.py
ID: 1022788801  Profile: test-system                               Last Checkin: 2014-02-17 22:21:46.0
ID: 1029581923  Profile: pili.example.com                          Last Checkin: 2014-02-17 22:21:40.0
ID: 1029963794  Profile: s1-satellite.example.com                  Last Checkin: 2014-02-17 22:21:39.0
ID: 1030083779  Profile: vm209.example.com                         Last Checkin: 2014-02-17 22:21:18.0
ID: 1021950006  Profile: dim3k.hometest                            Last Checkin: 2014-02-17 22:21:06.0
ID: 1023375478  Profile: dhcp210-63.example.com                    Last Checkin: 2014-02-17 22:20:47.0
ID: 1018017654  Profile: ibm-x3650m2-1.example.com                 Last Checkin: 2014-02-17 22:20:47.0
...

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

6 Comments

The solution is available now. Please update Comments.

How can i go over a proxy with this script http_proxy does not work? Is there a possibility to Display a counter how many checkins are left?

Hello BBZ Bedag,

Python's xmlrpclib module does not have a native support for use through an HTTP proxy. One way to provide such ability is to add a layer using the httplib module.
Please refer KCS article https://access.redhat.com/solutions/58488 for more information.

this solution is not working

I am sorry but this is not even a solution or a workaround. Nothing is done from the Redhat side and the entire responsibility is shifted to the customer by requesting they delete the system profile and then add it back in to the customer portal. Perhaps Redhat could implement some type of sanity check to prevent this lockout from happening. The message I am getting from this is that something is broken on the Redhat side and this is how they tell us they are unable to fix it.

This happened on a system that was formerly registered to RHN and now registered to in-house satellite. Worked alright for sometime and started coming up with error 49. After all other suggestions failed I moved the systemid to my home dir:

mv /etc/sysconfig/rhn/systemid /home/me && yum clean metadata && yum update
puppet agent -tv

Everything started working gr8!

So remove systemid and see if that helps