Description of problem: When push to client is configured, updates to that client can no longer go via the next scheduled check-in Version-Release number of selected component (if applicable): 4.0.6 How reproducible: Every time Steps to Reproduce: 1. Configure a client for push-to-client from Satellite 2. Schedule some updates to the client Actual results: All updates are "sent" immediately via the push-to-client mechanism Expected results: Would like to be able to send updates via the standard rhn_check checkin schedule unless I *REALLY* need the update pushed. Additional info: Client of mine is running large numbers of RHEL 4 WS in stores all round the country. Can't afford to send updates during the day, so rhn_check will only be run once a day by the end-of-day script. This will be the normal mechanism for sending updates & new packages to the stores. If there is an emergency situation that requires updates to go out immediately, then we'd like the option to use the push-to-cliebt. The default sending mechanism, however, should be the next scheduled check-in by the client.
What the osad & osa-dispatcher do are merely alert the client that something has been scheduled. The clients will check in, as they do periodically anyway, but if the time is earlier than the "earliest action" value defined for the scheduled action, nothing should happen. As this behavior has not been reported, I'm going to close this bug. If you're seeing different behavior, please reopen the bug.
I guess what I'm asking for is an enhancement rather than a bug - but do I not put those in here too? Or should I just ask my sales rep so they can forget it? Anyway - enough sarcasm. I recently worked for a client deploying a large Red Hat base; 700 Workstation licenses and 4000 Desktop. They were planning to run WS licenses for their store servers and I think Desktop for everything else out in the field. They were using Satellite to manage all these systems, and deploy their own Java business app to the systems. The query about Push to Client came up because it proved somewhat inflexible in it's current configuration. The way things work is that a store would run a batch job called "End Of Day". This would do some kind of database reconciliation and stock ordering. Then it would communicate these things to the central server. We needed to ensure that a store would only ever check in to the Satellite server and install updates during this "End of Day" procedure. Only in emergencies would we want to update any software on a store machine during the online sales day. If we enabled push to client, we would be able to push emergency items out in an instant (e.g. an update to the cashpoint program was required one time due to a bug that was sent out. None of the stores that had applied the update could take any cash in via the till - this would have been an ideal scenario for Push to Client). However, this would then remove from us the ability to have updates processed by the End of Day process. The schedule by which all updates were to be done was when the manager of a store had manually run his/her End of Day process. If the process wasn't done, the updates wouldn't go out. Setting the updates to run not before a selected time isn't valid as we had instances where a store ran a special 24-hour opening (quite popular actually). The End of Day process wouldn't be run until the next evening - so that's when the updates should go out, but only for that store. What we effectively end up with is: (*) Push to Client (immediately) ( ) Not before selected time What we needed was: (*) Push to Client (immediately) ( ) Next rhn_check (during End of Day process) ( ) Not before selected time I know it's not a bug, but I thinks it's a pretty valid feature enhancement. At the end of the day, it prevented Provisioning Entitlements being ordered for all those machines. We had to hand code a system to systematically log into each of the 700 store servers and remotely run the rhn_check command via ssh. Not the messiest implementation in the world, but it would have been cleaner if all the scheduling requirements could have been dealt with directly by Satellite. Thanks Duncan Innes
Is there any comment on this? With RHEL 5 coming out soon it would be nice to see this included. I'm no longer in charge of the same 700 Satelite clients, but a slightly smaller 400 machine network. The same issue still applies: SOME updates should be pushed out via osa-dispatcher as they are urgent. MOST updates we want to be picked up by the NORMAL rhn_check service which is run as part of an overnight script that runs ONCE a day. The "Not before a selected time" option doesn't count for us as we can never be sure when the overnight script will actually get to the rhn_check section. Some machines have the script run manually by the user before they leave for the evening rather than let cron pick the job up. Duncan Innes
This sounds like a useful enhancement. I'll put this on the triage list for our RHEL 5-related satellite release so that it gets considered by project management.
moving to next release. we ran out of time to implement this in the upcoming 500 Release.
User wregglej's account has been closed
Ping. Looks like you ran out of time during the 5.1 development phase too. I've since come across 4 other large corporate users of Provisioning entitlements that find this impossible to use in it's current state. It surely can't be that difficult to have an extra scheduling algorithm that doesn't post a jabber message to the system and just waits for the system to check in?
Who is the customer? Rabobank AN#614568 What is the exact nature of the problem trying to be solved with this request? When a client is enabled for provisioning and has the osad service running properly, events can be picked up by the client in a matter of seconds. The customer has now lost the ability to schedule event to happen the next time a server checks in with the Satellite. What, if any, business requirements are satisfied by this request? (What is the use case context?) Rabobank has servers which only run rhn_check via a daily cron job once all other work is done. He needs to be able to pick some events up (like important package updates) at the end of this cron job so that updates only happen when the machine isn't processing. List the functional requirement(s) for performing the action(s) that are not presently possible. Please focus on describing the problem related requirements without projecting any specific solution. He needs to be able to schedule events to only be picked up when the server next checks in on it's regular rhnsd schedule. Something similar to: https://bugzilla.redhat.com/show_bug.cgi?id=190153 That the customer submitted nearly 2 years ago. He needs the ability to schedule actions as follows ( ) Push to Client (*) Next regular checkin ( ) Not before [Enter Date & Time here] Each functional requirement must have clear acceptance criteria so Red Hat understands what success looks like. If test cases can be provided this would be even more ideal (bonus points for RHTS test cases). There's a groups of servers in Rabobank that have a requirement that package installs are only to be handled through the end-of-day script which in some cases is run manually. At this point, the databases and services are offline and they permit package upgrades only in this state. They have no control over when the end-of-day script is run by the system users. The result is that despite purchasing a large number of provisioning licenses (247), they cannot use one of the key features of this license. Configuring Push to Client is NOT viewed as a feature enhancement at Rabobank as it REMOVES the ability to schedule updates for the next time rhn_check connects to the satellite. What is the desired release vehicle to satisfy these requirements? Major release Minor release RHN/satellite 5.0 Please justify with reference to the release vehicle policy described in the RHEL Inclusion Criteria wiki page Issues impactic strategic/important customer What package(s) are affected by this RFE? (List "new" if new technology is likely to be required) RHN Satellite Who is the sales sponsor? Will update later. What is the Red Hat business opportunity with this customer? Will update later. What is the status and risk to the contract if this RFE is not satisfied? Will update later. This event sent from IssueTracker by jwest issue 172399
*** This bug has been marked as a duplicate of bug 193268 ***
Since I raise this request, and it has been marked as a duplicate of a NEWER bug, I would very much like to see the progress it makes. Unfortunately, I don't have access to bug 193268. Could this be opened, or could I be granted access to track this please? Thanks