Bug 405681

Summary: RFE: fail-safe option
Product: Red Hat Enterprise Linux 4 Reporter: Jay Turner <jturner>
Component: rhn_registerAssignee: Mike Orazi <morazi>
Status: CLOSED DUPLICATE QA Contact: Beth Nackashi <bnackash>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: srevivo
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-09 03:08:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jay Turner 2007-11-30 09:34:20 UTC
+++ 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 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 09:35:56 UTC
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-09 03:08:22 UTC

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