[rhn-users] Frequent checks for updated packages via RHN

[Clifford Perry]

I would suggest to look at using the API to do the same task. API uses 
the username/password to login and allow you to query Errata and 
packages associated with channels. Currently any time up2date runs and 
performs any type of action against RHN, it has to check-in. Since there 
are counters that monitor the rate of check-in for each system, (as you 
found out) frequent check-ins for a system cause it to be flagged as an 
abuse of service. You can avoid this by using the API for 
username/password login and queries.

https://rhn.redhat.com/rpc/api/   shows the current API's available. 
There is documentation and example script usage within the RHN Reference 
Guide as well.

Cliff.

Buchan Milne wrote:

>Due to requirements from our corporate monitoring team and other stakeholders, 
>we need to:
>1)Not apply updates automatically
>2)Check for updates via our monitoring system
>
>We also have our own custom packages in a yum-style repo, which we initially 
>deploy using smart (smartpm.org) if possible, or yum (if we have no other 
>option), and add this repo to /etc/sysconfig/rhn/sources after registering 
>the host (also done in kickstart).
>
>To reduce the bandwidth used, and make application of updates less 
>time-consuming, we have a squid proxy (configured to work nicely with RHN) 
>dedicated for proxying packages, and have configured RHN with 
>"useNoSSLForPackages=1".
>
>The monitoring system needs to have updates for any check at least every 30 
>minutes, so we have currently got a perl script that runs 'up2date --list' 
>and parses the output (ensuring required channels are available, warning if 
>updates are required) at less than 30-minute intervals.
>
>We initially deployed in this scenario in our disaster recovery site, and a 
>number of hosts in this site now get this error:
>
>"Abuse of Service detected for server ..."
>
>This is covered in the FAQ:
>
>https://rhn.redhat.com/help/faq/policy.pxt#268
>
>However, there is no solution to my problem:
>
>"Note: up2date should not be run in a cron job."
>
>Well, we're not running up2date via cron, but it is running at regular 
>intervals.
>
>Now, I would be happy to not have to contact RHN on every run of the check, 
>but I don't see any up2date option that prevents this (equivalent of yum's 
>-C, or the default operation of urpmi/smart etc).
>
>Is there any solution, or do I have to cache the output of 'up2date --list' to 
>a temporary file in a script that runs once in 2 hours, and have the script 
>that reports to the monitoring system parse this temporary file? The up2date 
>man page is not very clear on *exactly* what happens regarding contacting RHN 
>w.r.t options, such as --dry-run etc.
>
>The same implementation was done in our production deployment a few days 
>later, so I imagine the production site will run into this quite soon ...
>
>We don't have time to investigate using an RHN Satellite or RHN Proxy at 
>present, due to other projects (and our existing deployment solutions mean 
>that RHN Satellite may not actually provide any substantial benefits either).
>
>Regards,
>Buchan
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>rhn-users mailing list
>rhn-users at redhat.com
>https://www.redhat.com/mailman/listinfo/rhn-users
>