Bug 405681 - RFE: fail-safe option
RFE: fail-safe option
Status: CLOSED DUPLICATE of bug 428068
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rhn_register (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike Orazi
Beth Nackashi
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-30 04:34 EST by Jay Turner
Modified: 2015-01-07 19:16 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-08 22:08:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jay Turner 2007-11-30 04:34:20 EST
+++ This bug was initially created as a clone of Bug #405671 +++

As a result of the client-tools being the preferred and predominant method for
customers to apply updates to their systems, it's critically important that the
tools actually work and are able to download and apply the updates.  For this
reason, I would recommend we implement a fail-safe loop in the client tools. 
Something along the lines of:

- a location is identified on Red Hat's public network (could be a path on RHN
or merely a directory on our FTP site)
- at client tools execution, the tools would initially check the location
described above to see if there's an update available and if so, would utilize
standard file retrieval methods (wget is probably the most base) to retrieve the
updated packages, apply them and re-exec the client tools
- Red Hat would only populate this look-aside location in the event that a
critical bug were identified with the client tools which would prevent retrieval
of updated packages viathe normal channels and methods
- the updated packages would need to be signed with Red Hat's key and the client
tools should only apply an update which is signed with Red Hat's key; this to
prevent someone from posting rogue packages and hi-jacking the initial check-in

There are far more details to sort out (what happens with disconnected clients,
satellite customers, etc.) but the high-level above is where we need to be for
all customers.

-- Additional comment from jturner@redhat.com on 2007-11-30 04:33 EST --
I realize this is late for 5.2, but I really feel this is important to land as
soon as possible, especially given some of the recent problems we've encountered
with client tools bugs.  Proposing as 5.2 exception.
Comment 1 Jay Turner 2007-11-30 04:35:56 EST
Narf, meant to strike that part about 5.2.  Salt to taste with
s/client-tools/rhn_register/g
Comment 2 Clifford Perry 2008-01-08 22:08:22 EST

*** This bug has been marked as a duplicate of 428068 ***

Note You need to log in before you can comment on or make changes to this bug.