Description of problem: Cisco would very much like to put the final nail in their internal update mechanism channel. This step will be to fully automate a single package's update. In the reproducability section I've outlined what should happen. It was represented to me by gdk this could be done already, so I expect it will be trivial. The channel name will be cisco-sudoers, I can create it if you like. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. script dumps package into tree 2. script uses rhn_package_manager to update package in rhn channel 3. upon update in channel, rhn automatically pushes package to all subscribed systems Additional info:
To address the issue in detail: In the past, we *did* have an "automatic update" functionality, more than a year ago now in the previous lifetime of RHN. We removed it -- in part because it was completely unreliable, in part because we felt that it was too dangerous to leave in the hands of the majority of our customers. When it did exist, it was a global pref, and was either "update this system automatically always" or "don't." There was no package granularity of any kind. The heart of this request is the ability to do things programatically according to certain criteria. Let's build a sample API and walk the code path: rhn.Login SystemsInChannelFoo = rhn.GetSystemList (channel=foo) SystemsWithPackageBar = rhn.GetSystemList (package=bar) for each System in union (SystemsInChannelFoo, SystemsWithPackageBar) { rhn.scheduleAction (action=update, system=System, package=bar) } rhn.Logout ...which, when run by the script that currently pushes packages to the proxy, would "automatically" update the correct machines. SO... this means API work. Which is an RFE, but an extremely important RFE. We'll be discussing the requirements around building a set of basic APIs, documenting them, and ensuring that they stay functional.
Has this been addressed further at all??? This is a general RHN RFE, so I'm changing the Product as well (ie. not RHN Proxy Server specific).
*** This bug has been marked as a duplicate of 116359 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.