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

[Buchan Milne]

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

-- 
Buchan Milne
ISP Systems Specialist
B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/rhn-users/attachments/20060222/1c0da64b/attachment.sig>