I want to make sure that the applet honors the server configured setting of when to check back in for further updates. Current settings are: # Close to an outage, setting checkin interval really high server.applet.checkin_interval = 86400 # Big offset too - 4 hours server.applet.checkin_interval_max_offset = 14400
This is fixed in CVS, for the next U release(s)
Please insert more information, e.g., a test plan.
Test plan: The best way to test this is the following: o Log onto the backend box for the stack you are testing against (rhnxml.back-webdev.redhat.com, for webdev). o edit /etc/rhn/rhn.conf, and set the checkin interval fairly low (or check to see what the existing interval is - you'll just have to wait longer to see the results) """ # applet - testing bug #172705 server.applet.checkin_interval = 15 server.applet.checkin_interval_max_offset = 5 """ These values are in seconds - so the applet will be directed to check in no more often than 15-20 seconds. o Install the latest applet on the test box, and configure it to point to the chosen environment. In /etc/sysconfig/rhn/rhn-applet : """ server_url=https://xmlrpc.rhn.webdev.redhat.com/APPLET """ (for webdev) o Note that the applet itself is configured to refresh no more than every 15 minutes. You can speed this up if you edit /usr/share/rhn/rhn_applet/rhn_applet.py: """ REFRESH_INTERVAL = 900 # 15 minutes """ The value is in seconds. So here's the way it works. When the applet starts, it checks in with the server to see if updated packages are available. The server replies, and also sets a 'checkin_interval', which is server.applet.checkin_interval plus between 0 and server.applet.checkin_interval_max_offset seconds. After that, every $REFRESH_INTERVAL seconds, the applet 'wakes up'. It checks some things, including to see if the checkin_interval set the last time it checks in has passed. If so, it checks in again, and gets a new checkin interval also. So, after you have set up the above, and let the applet check in for a time, grep the /etc/httpd/logs/combined_log on the backend server for your test system's ip address. Here are some sample results: """ 172.16.56.86 [11/Jan/2006:10:36:21 -0500] - "POST /APPLET HTTP/1.1" 200 291 0 23278 "rhn.rpclib.py/$Revision: 1.40 $" "-" 172.16.56.86 [11/Jan/2006:10:36:21 -0500] - "POST /APPLET HTTP/1.1" 200 203 0 23279 "rhn.rpclib.py/$Revision: 1.40 $" "-" 172.16.56.86 [11/Jan/2006:10:41:21 -0500] - "POST /APPLET HTTP/1.1" 200 291 0 23280 "rhn.rpclib.py/$Revision: 1.40 $" "-" 172.16.56.86 [11/Jan/2006:10:41:21 -0500] - "POST /APPLET HTTP/1.1" 200 203 0 23281 "rhn.rpclib.py/$Revision: 1.40 $" "-" 172.16.56.86 [11/Jan/2006:10:46:32 -0500] - "POST /APPLET HTTP/1.1" 200 291 0 23249 "rhn.rpclib.py/$Revision: 1.40 $" "-" 172.16.56.86 [11/Jan/2006:10:46:32 -0500] - "POST /APPLET HTTP/1.1" 200 203 0 23250 "rhn.rpclib.py/$Revision: 1.40 $" "-" 172.16.56.86 [11/Jan/2006:10:51:42 -0500] - "POST /APPLET HTTP/1.1" 200 291 0 23251 "rhn.rpclib.py/$Revision: 1.40 $" "-" 172.16.56.86 [11/Jan/2006:10:51:42 -0500] - "POST /APPLET HTTP/1.1" 200 203 0 23252 "rhn.rpclib.py/$Revision: 1.40 $" "-" 172.16.56.86 [11/Jan/2006:10:56:52 -0500] - "POST /APPLET HTTP/1.1" 200 291 0 23254 "rhn.rpclib.py/$Revision: 1.40 $" "-" 172.16.56.86 [11/Jan/2006:10:56:52 -0500] - "POST /APPLET HTTP/1.1" 200 203 0 23255 "rhn.rpclib.py/$Revision: 1.40 $" "-" """ This is with the server.applet.checkin_interval set to about 5 minutes. Notice that there are two requests each cycle - this is normal. So the key is, the system should check in no more often than server.applet.checkin_interval, no matter how often client is configured to refresh. Oh, and don't forget to clean up any config changes on the backend server when you're done testing.
The system isn't checking in at all. Or, more accurately, the combined_log file isn't getting any action.
I must have been grepping the log file for the wrong client IP. This bug passes QA.
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 the 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/RHBA-2006-0118.html
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 the 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/RHBA-2006-0100.html