Bug 67267 - Up2Date fails half way through install when RedHat servers are under high load.
Up2Date fails half way through install when RedHat servers are under high load.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
7.2
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Mihai Ibanescu
Jay Turner
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-21 14:20 EDT by Aaron Freed
Modified: 2015-01-07 18:57 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-12 03:56:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aaron Freed 2002-06-21 14:20:27 EDT
Description of Problem:  
After successfully logging in with up2date, the following procedures succeed:  
1.  Package Conflict Resolution/Package Set Testing  
2.  Removing headers for already installed packages  
3.  Downloading all packages and RPMs as needed  
 BUT  
Installing Updates may fail right in the middle of the process (In at least  
two cases, whilst in the middle of installing a kernel update!!!) with an  
error message to the effect of "A Fatal Error has occurred:  Due to high load,  
Free Access to the update service has been restricted".  
  
This is absolutely unforgivable and unacceptable.  Either offer a free  
service, or don't offer it.  But don't offer a service that fails in the  
middle of installing critical system components.  As a consequence of your  
"service restriction due to high load", one of my servers was trashed with a  
partially installed update.    
  
To make matters worse, evidently, the RPM database gets updated first, then  
the updates get installed, so subsequent runs of Up2date indicate that the  
system has already been updated, when, in fact, the update failed due to the  
error mentioned above.  Again, this is ABSOLUTELY UNFORGIVABLE and is not the  
type of support I have come to expect from RedHat. Regrettably, this problem  
has resulted in the destruction of one of my servers!  
  
Version-Release number of selected component (if applicable):  
  
  
How Reproducible:  
Should be nearly 100 %  
  
Steps to Reproduce:  
1. Attempt to use up2date to install updated software from an account with   
"basic" (Free) upgrade service.  Do so right after a new kernel or Apache  
patch is released (when the servers are under a high load and access to the   
free update service is likely to be restricted.)  
  
   
  
Actual Results:  
In at least once case, a server with a completely corrupted kernel--had to  
rebuild it from scratch and restore data from backups.  
  
At the time of this writing, I am trying to download the patches using Up2Date  
WITH THE OPTION TO INSTALL THEM DISABLED.  With a little luck, I may be able  
to manually install the patches and recover my server.  
  
  
Expected Results:  
I expected that Up2Date would  
1.  Refuse to connect at all if your servers report too high a load and that  
free/basic service has been temporarily suspended.  
2.  If successful in downloading packages, that it would install the  
downloaded packages from the local disk, rather than trying to install  
packages over the internet, and THEN downloading the packages (and  
source-code).  
3.  A successful package install OR an error telling me to try again when your  
servers are less busy:  NOT to have the install fail at a critical point half  
way through because your servers have suddenly decided to drop my connection.  
  
  
  
Additional Information:  
 
I have marked this "Security" as I feel that a failure of installation of a 
security-related kernel patch, for example, in the middle of the installation 
procedure would presumably constitute a security risk.   
Available at your request--I will let you know if the manual update works well  
enough to be a work-around for this rather disasterous "gotcha".
Comment 1 Adrian Likins 2002-06-21 17:45:45 EDT
As far as I know, existing authentication sessions should be
allowed to continue when throttling is put into place.
Testing that now to determine if that is no longer the case. 

But, going on the assumption that you can be denied access
mid session, I'm not sure I understand how this could "cripple"
a system.

Authentication checks are done on each package and header
GET, and on each rpc call. No packages will be installed
untill all headers and packages are downloaded, then the
md5sum and gpg of each on disk package is verifyed, and 
then the packages are installed. There are no network
connections attempted again until after the package are
installed. And even then, the rpm database isnt updated
untill after each package sucessfully installs. Then there
are some network connections to update the server side
package profile information.


You mention the package database indicates that the package
is installed. Whats the output of:

          rpm -V kernel

(or kernel-smp if thats the package in question)
This verifys the state of the files on disk that
are part of the package.

Also could you provide the Version-Release number of the
up2date package you have installed. 

How exactly was the update partially installed? The only
scenario that I can think that might be broken is:
     1. You start your free Red Hat Network session
     2. You correctly download all the packages (kernel in this case)
     3. md5sums and gpgs keys check out
     4. up2date installs the package (none of the errors mentioned indicate
        that there was a problem installing the package).
     5. While attempting to update the server side package list, you
        get an authentication error.
     6. Program exits

     What doesnt happen in this case, is the bootloader (lilo or grub) doesnt
     get updated properly. Looking at the code, this case could happen 
     and is a bug. But because of the way up2date installs the bootloader, the
     machine should still continue to run, and even to reboot by default to
     an existing older kernel. 

     I'll take a look at changing the boot loader code to happen before 
     making anymore network calls. If you can provide me the logs, and 
     the rpm -V output, I'll take a look and see if it could be something
     else.
    



 
A copy of the relevant bits of /var/log/up2date could
be useful as well.
Comment 2 Aaron Freed 2002-06-27 01:24:01 EDT
     
Samples of failed sessions (Downloading) with up2date.  (Both occurred at   
stages of less than 13 % complete.)   
   
I have disabled the "Install updates" feature of up2date, since I can no   
longer trust the program to even download updates successfully without getting   
shut down "because the access to Red Hat Network is currently restricted to   
subscription customers only".    
   
Regrettably, since RPM cannot resolve dependency problems and UP2DATE cannot  
seem to download updates reliably, it seems that the only alternative is to  
obtain a paid subscription if one expects to keep one's copy of RedHat Linux  
anywhere near current.    
  
Sun does not charge for patches.  Even Microsoft does not charge for service  
packs!  
  
Following the sample sessions is the entirety of /var/log/up2date.   
   
Last login: Wed Jun 26 21:44:53 2002 from marinduque.alabang.edu   
[21:55:46] 1001 [root@zamboanga: ~]$ up2date   
Traceback (innermost last):   
  File "/usr/share/rhn/up2date_client/gui.py", line 659, in doRetrieval   
    self.setRetrievalProgress)   
  File "/usr/share/rhn/up2date_client/up2date.py", line 956, in getPackage   
    buffer = doCall(packageSource.getPackage, pkg, msgCallback,   
progressCallback)   
  File "/usr/share/rhn/up2date_client/up2date.py", line 308, in doCall   
    updateLoginInfo()   
  File "/usr/share/rhn/up2date_client/up2date.py", line 430, in   
updateLoginInfo   
    loginInfo = login()   
  File "/usr/share/rhn/up2date_client/up2date.py", line 339, in login   
    loginInfo = doCall(server.up2date.login, systemId)   
  File "/usr/share/rhn/up2date_client/up2date.py", line 287, in doCall   
    ret = apply(method, args, kwargs)   
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 689, in __call__   
    return self.__send(self.__name, args)   
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 746, in __request   
    self.__protocol   
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 652, in request   
    return self.parse_response(fd)   
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 667, in   
parse_response   
    return u.close()   
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 366, in close   
    raise apply(Fault, (), self._stack[0])   
xmlrpclib.Fault: <Fault -51 """   
Error Message:   
    Free service limited due to high load, please try again later (server   
1000927985)   
Error Class Code: 51   
Error Class Info:   
     Due to extremely high traffic, access to Red Hat Network is currently   
     limited to subscription customers.  Please try again later.  If you   
     would like to become a subscription customer, go to   
     https://rhn.redhat.com/preview/priority_service.pxt for more information.   
Explanation:   
     An error has occurred while processing your request. If this problem   
     persists please submit a bug report to rhn-help@redhat.com.   
 If you choose to submit the bug report, please be sure to include   
     details of what you were trying to do when this error occurred and   
     details on how to reproduce this problem.   
""">   
[23:24:23] 1002 [root@zamboanga: ~]$ up2date   
[23:24:39] 1003 [root@zamboanga: ~]$ up2date   
[23:52:09] 1004 [root@zamboanga: ~]$ up2date-config   
[23:52:40] 1005 [root@zamboanga: ~]$ up2date   
Traceback (innermost last):   
  File "/usr/share/rhn/up2date_client/gui.py", line 659, in doRetrieval   
    self.setRetrievalProgress)   
  File "/usr/share/rhn/up2date_client/up2date.py", line 956, in getPackage   
    buffer = doCall(packageSource.getPackage, pkg, msgCallback,   
progressCallback)   
  File "/usr/share/rhn/up2date_client/up2date.py", line 308, in doCall   
    updateLoginInfo()   
  File "/usr/share/rhn/up2date_client/up2date.py", line 430, in   
updateLoginInfo   
    loginInfo = login()   
  File "/usr/share/rhn/up2date_client/up2date.py", line 339, in login   
    loginInfo = doCall(server.up2date.login, systemId)   
  File "/usr/share/rhn/up2date_client/up2date.py", line 287, in doCall   
    ret = apply(method, args, kwargs)   
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 689, in __call__   
    return self.__send(self.__name, args)   
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 746, in __request   
    self.__protocol   
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 652, in request   
    return self.parse_response(fd)   
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 667, in   
parse_response   
    return u.close()   
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 366, in close   
    raise apply(Fault, (), self._stack[0])   
xmlrpclib.Fault: <Fault -51 """   
Error Message:   
    Free service limited due to high load, please try again later (server   
1000927985)   
Error Class Code: 51   
Error Class Info:   
     Due to extremely high traffic, access to Red Hat Network is currently   
     limited to subscription customers.  Please try again later.  If you   
     would like to become a subscription customer, go to   
     https://rhn.redhat.com/preview/priority_service.pxt for more information.   
Explanation:   
     An error has occurred while processing your request. If this problem   
     persists please submit a bug report to rhn-help@redhat.com.   
     If you choose to submit the bug report, please be sure to include   
     details of what you were trying to do when this error occurred and   
     details on how to reproduce this problem.   
"""   
   
================================================================================   
================================================================================   
				/var/log/up2date   
===============================================================================   
===============================================================================   
[01:03:52] 1006 [root@zamboanga: ~]$   
[01:03:52] 1006 [root@zamboanga: ~]$ cat /var/log/up2date   
[Sun Jun 23 04:43:08 2002] up2date updating login info   
[Sun Jun 23 04:43:08 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Sun Jun 23 04:43:08 2002] up2date logging into up2date server   
[Sun Jun 23 06:43:11 2002] up2date updating login info   
[Sun Jun 23 06:43:11 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Sun Jun 23 06:43:11 2002] up2date logging into up2date server   
[Sun Jun 23 08:43:14 2002] up2date updating login info   
[Sun Jun 23 08:43:14 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Sun Jun 23 08:43:14 2002] up2date logging into up2date server   
[Sun Jun 23 10:43:16 2002] up2date updating login info   
[Sun Jun 23 10:43:16 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Sun Jun 23 10:43:16 2002] up2date logging into up2date server   
[Sun Jun 23 12:43:19 2002] up2date updating login info   
[Sun Jun 23 12:43:19 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Sun Jun 23 12:43:19 2002] up2date logging into up2date server   
[Sun Jun 23 14:43:22 2002] up2date updating login info   
[Sun Jun 23 14:43:22 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Sun Jun 23 14:43:22 2002] up2date logging into up2date server   
[Sun Jun 23 16:43:24 2002] up2date updating login info   
[Sun Jun 23 16:43:24 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Sun Jun 23 16:43:24 2002] up2date logging into up2date server   
[Sun Jun 23 18:43:27 2002] up2date updating login info   
[Sun Jun 23 18:43:27 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Sun Jun 23 18:43:27 2002] up2date logging into up2date server   
[Sun Jun 23 20:43:30 2002] up2date updating login info   
[Sun Jun 23 20:43:30 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Sun Jun 23 20:43:30 2002] up2date logging into up2date server   
[Sun Jun 23 22:43:33 2002] up2date updating login info   
[Sun Jun 23 22:43:33 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Sun Jun 23 22:43:33 2002] up2date logging into up2date server   
[Mon Jun 24 00:43:35 2002] up2date updating login info   
[Mon Jun 24 00:43:35 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Mon Jun 24 00:43:35 2002] up2date logging into up2date server   
[Mon Jun 24 02:43:38 2002] up2date updating login info   
[Mon Jun 24 02:43:38 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Mon Jun 24 02:43:38 2002] up2date logging into up2date server   
[Mon Jun 24 04:43:41 2002] up2date updating login info   
[Mon Jun 24 04:43:41 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Mon Jun 24 04:43:41 2002] up2date logging into up2date server   
[Mon Jun 24 06:43:44 2002] up2date updating login info   
[Mon Jun 24 06:43:44 2002] up2date Openingrpmdb in /var/lib/rpm/ with option   
0   
[Mon Jun 24 06:43:44 2002] up2date logging into up2date server   
[Mon Jun 24 08:43:47 2002] up2date updating login info   
[Mon Jun 24 08:43:47 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Mon Jun 24 08:43:47 2002] up2date logging into up2date server   
[Mon Jun 24 10:43:50 2002] up2date updating login info   
[Mon Jun 24 10:43:50 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Mon Jun 24 10:43:50 2002] up2date logging into up2date server   
[Mon Jun 24 12:43:52 2002] up2date updating login info   
[Mon Jun 24 12:43:52 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Mon Jun 24 12:43:52 2002] up2date logging into up2date server   
[Mon Jun 24 14:43:55 2002] up2date updating login info   
[Mon Jun 24 14:43:55 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Mon Jun 24 14:43:55 2002] up2date logging into up2date server   
[Mon Jun 24 16:43:58 2002] up2date updating login info   
[Mon Jun 24 16:43:58 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Mon Jun 24 16:43:58 2002] up2date logging into up2date server   
[Mon Jun 24 18:44:01 2002] up2date updating login info   
[Mon Jun 24 18:44:01 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Mon Jun 24 18:44:01 2002] up2date logging into up2date server   
[Mon Jun 24 20:44:06 2002] up2date updating login info   
[Mon Jun 24 20:44:06 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Mon Jun 24 20:44:06 2002] up2date logging into up2date server   
[Mon Jun 24 22:44:08 2002] up2date updating login info   
[Mon Jun 24 22:44:08 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Mon Jun 24 22:44:08 2002] up2date logging into up2date server   
[Tue Jun 25 00:44:11 2002] up2date updating login info   
[Tue Jun 25 00:44:11 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Tue Jun 25 00:44:11 2002] up2date logging into up2date server   
[Tue Jun 25 02:44:14 2002] up2date updating login info   
[Tue Jun 25 02:44:14 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Tue Jun 25 02:44:14 2002] up2date logging into up2date server   
[Tue Jun 25 04:44:16 2002] up2date updating login info   
[Tue Jun 25 04:44:16 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Tue Jun 25 04:44:16 2002] up2date logging into up2date server   
[Tue Jun 25 06:44:19 2002] up2date updating login info   
[Tue Jun 25 06:44:19 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Tue Jun 25 06:44:19 2002] up2date logging into up2date server   
[Tue Jun 25 20:59:52 2002] up2date updating login info   
[Tue Jun 25 20:59:52 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Tue Jun 25 20:59:52 2002] up2date logging into up2date server   
[Tue Jun 25 22:59:55 2002] up2date updating login info   
[Tue Jun 25 22:59:55 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Tue Jun 25 22:59:55 2002] up2date logging into up2date server   
[Wed Jun 26 00:59:58 2002] up2date updating login info   
[Wed Jun 26 00:59:58 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 00:59:58 2002] up2date logging into up2date server   
[Wed Jun 26 03:00:00 2002] up2date updating login info   
[Wed Jun 26 03:00:00 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 03:00:00 2002] up2date logging into up2date server   
[Wed Jun 26 05:00:03 2002] up2date updating login info   
[Wed Jun 26 05:00:03 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 05:00:03 2002] up2date logging into up2date server   
[Wed Jun 26 07:00:06 2002] up2date updating login info   
[Wed Jun 26 07:00:06 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 07:00:06 2002] up2date logging into up2date server   
[Wed Jun 26 21:54:14 2002] up2date updating login info   
[Wed Jun 26 21:54:14 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 21:54:14 2002] up2date logging into up2date server   
[Wed Jun 26 21:54:14 2002] up2date successfully retrived authentication token   
from up2date server   
[Wed Jun 26 21:55:50 2002] up2date updating login info   
[Wed Jun 26 21:55:50 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 21:55:50 2002] up2date logging into up2date server   
[Wed Jun 26 21:55:50 2002] up2date successfully retrived authentication token   
from up2date server   
[Wed Jun 26 21:55:50 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 21:55:50 2002] up2date getAvailablePackageList from network   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 21:55:50 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 21:55:50 2002] up2date solving dep for: ['libnspr4.so',   
'libplc4.so', 'libplds4.so', 'libnspr4.so', 'libplc4.so', 'libplds4.so',   
'mozilla-nspr', 'libnspr4.so', 'libplc4.so', 'libplds4.so', 'libnspr4.so',   
'libplc4.so', 'libplds4.so', 'libnspr4.so', 'libnss3.so', 'libplc4.so',   
'libplds4.so', 'libsmime3.so', 'libsoftokn3.so', 'libssl3.so', 'mozilla-nss',   
'libnspr4.so', 'libplc4.so', 'libplds4.so', 'poptmodule.so']   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date see if we need to login again   
[Wed Jun 26 21:55:50 2002] up2date A protocol error occured: 401:   
"Authorization Required" while attempting to get   
$RHN/redhat-linux-i386-7.2/getPackage/XFree86-Xvfb-4.1.0-25.i386.rpm , attempt   
#1   
[Wed Jun 26 21:55:50 2002] up2date Auth token time out occured   
 errmsg:   
Error Message:   
    Expired client authentication token   
Error Class Code: 34   
Error Class Info: Client session token has expired.   
Explanation:   
     An error has occurred while processing your request. If this problem   
     persists please submit a bug report to rhn-help@redhat.com.   
     If you choose to submit the bug report, please be sure to include   
     details of what you were trying to do when this error occurred and   
     details on how to reproduce this problem.   
   
[Wed Jun 26 21:55:50 2002] up2date updating login info   
[Wed Jun 26 21:55:50 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 21:55:50 2002] up2date logging into up2date server   
[Wed Jun 26 23:24:30 2002] up2date updating login info   
[Wed Jun 26 23:24:30 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 23:24:30 2002] up2date logging into up2date server   
[Wed Jun 26 23:27:55 2002] up2date updating login info   
[Wed Jun 26 23:27:55 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 23:27:55 2002] up2date logging into up2date server   
[Wed Jun 26 23:27:55 2002] up2date successfully retrived authentication token   
from up2date server   
[Wed Jun 26 23:27:55 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 23:27:55 2002] up2date getAvailablePackageList from network   
[Wed Jun 26 23:27:55 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 23:27:55 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 23:27:55 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 23:27:55 2002] up2date solving dep for: ['libnspr4.so',   
'libplc4.so', 'libplds4.so', 'libnspr4.so', 'libplc4.so', 'libplds4.so',   
'mozilla-nspr', 'libnspr4.so', 'libplc4.so', 'libplds4.so', 'libnspr4.so',   
'libplc4.so', 'libplds4.so', 'libnspr4.so', 'libnss3.so', 'libplc4.so',   
'libplds4.so', 'libsmime3.so', 'libsoftokn3.so', 'libssl3.so', 'mozilla-nss',   
'libnspr4.so', 'libplc4.so', 'libplds4.so', 'poptmodule.so']   
[Wed Jun 26 23:41:31 2002] up2date updating login info   
[Wed Jun 26 23:41:31 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 23:41:31 2002] up2date logging into up2date server   
[Wed Jun 26 23:41:31 2002] up2date successfully retrived authentication token   
from up2date server   
[Wed Jun 26 23:27:55 2002] up2date see if we need to login again   
[Wed Jun 26 23:27:55 2002] up2date see if we need to login again   
[Wed Jun 26 23:27:55 2002] up2date see if we need to login again   
[Wed Jun 26 23:27:55 2002] up2date see if we need to login again   
[Wed Jun 26 23:52:45 2002] up2date updating login info   
[Wed Jun 26 23:52:45 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 23:52:45 2002] up2date logging into up2date server   
[Wed Jun 26 23:52:45 2002] up2date successfully retrived authentication token   
from up2date server   
[Wed Jun 26 23:52:45 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 23:52:45 2002] up2date getAvailablePackageList from network   
[Wed Jun 26 23:52:45 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 23:52:45 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 23:52:45 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 23:52:45 2002] up2date solving dep for: ['libnspr4.so',   
'libplc4.so', 'libplds4.so', 'libnspr4.so', 'libplc4.so', 'libplds4.so',   
'mozilla-nspr', 'libnspr4.so', 'libplc4.so', 'libplds4.so', 'libnspr4.so',   
'libplc4.so', 'libplds4.so', 'libnspr4.so', 'libnss3.so', 'libplc4.so',   
'libplds4.so', 'libsmime3.so', 'libsoftokn3.so', 'libssl3.so', 'mozilla-nss',   
'libnspr4.so', 'libplc4.so', 'libplds4.so', 'poptmodule.so']   
[Wed Jun 26 23:52:45 2002] up2date see if we need to login again   
[Wed Jun 26 23:52:45 2002] up2date see if we need to login again   
[Wed Jun 26 23:52:45 2002] up2date see if we need to login again   
[Wed Jun 26 23:52:45 2002] up2date see if we need to login again   
[Wed Jun 26 23:52:45 2002] up2date see if we need to login again   
[Wed Jun 26 23:52:45 2002] up2date see if we need to login again   
[Wed Jun 26 23:52:45 2002] up2date see if we need to login again   
[Wed Jun 26 23:52:45 2002] up2date see if we need to login again   
[Wed Jun 26 23:52:45 2002] up2date see if we need to login again   
[Wed Jun 26 23:52:45 2002] up2date see if we need to login again   
[Wed Jun 26 23:52:45 2002] up2date A protocol error occured: 401:   
"Authorization Required" while attempting to get   
$RHN/redhat-linux-i386-7.2/getPackage/XFree86-Xvfb-4.1.0-25.i386.rpm , attempt   
#1   
[Wed Jun 26 23:52:45 2002] up2date Auth token time out occured   
 errmsg:   
Error Message:   
    Expired client authentication token   
Error Class Code: 34   
Error Class Info: Client session token has expired.   
Explanation:   
     An error has occurred while processing your request. If this problem   
     persists please submit a bug report to rhn-help@redhat.com.   
     If you choose to submit the bug report, please be sure to include   
     details of what you were trying to do when this error occurred and   
     details on how to reproduce this problem.   
   
[Wed Jun 26 23:52:45 2002] up2date updating login info   
[Wed Jun 26 23:52:45 2002] up2date Opening rpmdb in /var/lib/rpm/ with option   
0   
[Wed Jun 26 23:52:45 2002] up2date logging into up2date server   
[01:04:00] 1007 [root@zamboanga: ~]$   
>
Comment 3 jdg 2002-06-27 14:31:24 EDT
My personal favorite:

Everything goes fine - but the very last step hangs, just before you get the
list of things that installed.
Go run another up2date session, and you get the busy server message.

Here's an idea:   two-phase-commit.  That's an RDBMS term.

Nothing is considered DONE until both CLIENT and SERVER have INDEPENDENT success
status flags.  These flags exist ONLY on the individual machines, and are
PRODUCED on those machines, - INDIVIDUALLY.  That's important - because all you
have to xfer across the 'net is the status flags.  In anything other than
COMPLETE AGREEMENT situations, it is assumed on the SERVER side that the
operation failed.  The CLIENT side bears no responsibility for repeating
(unnecessarily) steps that the server should be doing - and vice versa.

Calling the thing an RPM DATABASE gives you the idea that it'll ACT like one.

The design is currently not up to par with ANY actual (commercial quality)
database standards.

My other favorite - what does the RPMDB consider the 'composite key' for
puroposes of general queries?  The package name?  name+version?? 
name+version+release???

I get the sneaking suspicion that your Bitchin' Update Tool is playing
fast-and-loose with this idea, with (potentially) 'fatal' results.

After all, you can't actually have two different versions of a package running
concurrently, why store records that some goober (such as myself) thinks he can
delete, (old versions - BY NAME and VERSION and RELEASE #'s).

Until he gets down to glibc, that is.  Then realizes (too late!?!?), that he
just hosed half the /usr/lib directory  YOU SHOULD NEVER DELETE FILES THAT ARE
IN USE BY ANOTHER PACKAGE, regardless of the dependency check smoke-and-mirrors
funhouse option.

Put a file-by-file delete confirmation in, turned ON by default, (that's for
goobers like me), until you get used to the idea that most of your newer
customers are coming from - 

The Plug-And-Pray Evil Empire.

Sorry I yelled...

:^P
Comment 4 Adrian Likins 2002-06-27 18:38:59 EDT
abcde.fz@verizon.net:

    I dont think you correctly understand how the packages are installed. 
Packages are installed about as atomically as is feasiable. When
a package is installed, all the new files are put on the file system
along side the files for the current installed version (the new version
gets a unique tmp name). When all the new files are on disk, rpm goes
though and moves the new file over the existing file (saving the old file to
a temp name). Directories are handled in a similar way. If any of these 
moves fail, rpm restores all the original files, and exists. 

    Given the file system semantics, this is about as atomic as you can
get and seems to be very robust. I havent seen any probablems with this
aspect of rpm in a long time (4 years?). 

    The rpm database itself is very much a database (berkeley db4 based,
see http://www.sleepycat.com/products.html for more info on the db that
lies at the heart of rpm).

    If you consider the design of the rpm database and it's interaction
somehow flawed, you might want to file a bug report against the "rpm" component.
Up2date is merely a tool for gettings packages to the client to be inserted
into the rpm database (and of course, onto the file system)


Comment 5 Adrian Likins 2002-06-27 18:45:52 EDT
 afreed@voicesignal.com:

Updates for Red Hat Linux products have always been freely available at
ftp://ftp.redhat.com and many mirrors sites. 

Checking the log files now to see whats going on.

if you could provide me the output of "rpm -V kernel"
and the version of the up2date packge installed, it would
be helpful in debugging the problem.
Comment 6 jdg 2002-06-28 07:45:56 EDT
I'll fully admit to not understanding, (yet), how rpm handles what "up2date"
does.  To me it's a 'black box' problem - (remember those?). - I'm a Linux/Red
Hat newbie, but the first Wintel (UNIX) flavor I worked with was SCO Xenix, and
the first RDBMS was Unify... 
Also, I worked at (www.empress.com) for 6 years.  That was the _first_
commercially available 32-bit database, and the _first_ database blessed by Cray
Research for its 64-bit arch. running Unicos.  I know a little bit about
distributed database problems...

So, the "up2date" problem - yes, it's critical that the network connection not
die during any 'individual' phase of [what should be considered] an 'atomic'
operation.

So, if [let's say for _discussion_purposes_only_] we're convinced that the DB
operations are bulletproof, that leaves one "up2date" flaw.

The instant _ANY_ up2date session grabs the attention of the Red Hat server, it
should be handed a key, added to every IP packet, (hey, I'm on a _modem_, and
I'll _still_ happily give up that bandwidth), 

Said key, once in place, serving as an absolute back-stage-pass-type
'top-priority' flag, good until the CLIENT, yes, I said client, PAID or UNPAID,
reports back to the server, (that's you), that all operations completed happily,
and the goober, (that's me), at the console got the Last Big "Installed
Successfully" splash screen.

I mean, come on, the _last_ time the server died on me, I was in the middle of
one tiny, leetle download  -- "rpm4.0.4" and "up2date2.3.whatever"....HELLO!!!

:^p   

Thanx for the help so far,

jdg
Comment 7 jdg 2002-06-28 08:34:38 EDT
OK, the second issue.

D.  Cook helped me out when I was new, telling me a little bit about how my
RPMDB was hosed.

Turns out I was banking on being able to run:
rpm -v -i -h --force --test *.rpm
then:
rpm -v -i -h --force *.rpm

...on the _saved_ binary rpms in my /titanium/up2date directory.  (I did this
'cause my system's new, and I'm still playing around with enough shit that I
have to re-install occasionally)...

Anyhoo, the idea is that old packages, (and their _database_keys_!!), would be
erased and updated in one 'fell swoop'.

This worked great, from the COMMAND LINE, that is.  Using kpackage, or gnorpm,
however, I saw that I had multilple instances of, say, "rpm" in my system.  (D.
Cook told me that was why my RHN web listing showed ungodly numbers of 'errata'
waiting to be fixed...).  OK.  Mea culpa and all that.  I went and started
deleting OLDER versions of programs.  Then I got to 'glibc' and said, "wait a
minute, something smells fishy in Denmark",...Yup.  Hosed my system.  Big time.
 Because the GUI gave me (yes, even me, the goober...) the idea that I could
safely delete _references_ to old packages, without hosing _currently_running_
packages...

Here's the question:  Ever hear of 'normalization'?  Just because your RPMDB is
using a DB, (again, I'll settle that later, see above)...

Does _NOT_ mean that the guy who wrote the database schema knew what the hell he
was doing!!!  OR - that the OTHER guy, who wrote the cute lil' GUI interface,
knew what havoc _HE_ could wreak, without 'goober-proof' - (that's me)... -
exception handling algorithms!!!

The database _will_allow_ you to get away with some pretty awful shenanigans, if
your schema is not bulletproof.  I know.  I've designed enough of them myself. 
I forget, there's 5 or 12 rules for normalization, and they're all there for a
reason.

The Prime Directive is "Data Integrity", (not "Database Integrity", tha't s a
whole different metaphysical realm)..."Data Integrity"!!!

Now, is this an up2date problem, or an rpm problem?

Thanx for the feedback..
Comment 8 Aaron Freed 2002-06-28 09:37:24 EDT
  
Here you go: (Maybe more useful to you than to me: 
 
NOTE:  Command was run on Liberty, rather than Marinduque, but both machines 
have had this problem, and both have almost identical hardware and have 
exactly the same version of RedHat Linux, so the information should be the 
same: 
 
[root@liberty Castor]# rpm -V kernel 
.M......   /dev/shm 
.M......   /dev/shm 
 
Does that mean much to you?  It doesn't to me (other than that I have 2 
processors, perhaps). 
 
The kernel version, for what it is worth (on both machines) is  
 
vmlinuz-2.4.18-4smp 
up2date-2.7.86-7.x.3 
 
Montpeller (Slightly newer machine--also had problem with up2date) 
 
vmlinux-2.4.18-5 
up2date-2.7.86-7.x.3 
 
Thanks!
Comment 9 Aaron Freed 2002-06-28 09:43:47 EDT
 Sounds like JDG, above, has had very much the same problem I have, though 
perhaps he has not nearly had a server destroyed because your up2date system 
decided to drop him in the middle of a kernel download.  This problem started 
several months ago during an update of Marinduque, one of my dual processor 
servers, which, at the time, was running RedHat 7.2, and trying to download 
Kernel 2.4.9-31.  The disconnect came during the download, and, consequently, 
when I rebooted the machine, I had the joy of discovering that all but the 
debug kernel images (neither of which support SMP) had been removed, but new 
ones not yet added.  Add to that, the missing and half-applied updates, and I 
just gave up and nuked the whole thing (except /home) and rebuilt it.  It took 
considerable time and effort to get the server back to the way it had been. 
 
So, I have to say, JDG is right.  There IS a problem with UP2DATE and it is 
very SERIOUS.  Looking at the history of this bug, I see a several people 
(like maybe 12) with the same or similar complaints.  I know of at least one 
professional sys admin (NOT me--yet) who has just given up RedHat and is 
converting all of his servers to Debian "because they have a package manager 
that actually works".) 
 
Comment 10 jdg 2002-06-28 16:40:24 EDT
It's happening RIGHT NOW!!!!

I'm sitting here waiting for the stupid splash-screen-cum-shot, and your network
is HOSED!!!

I seriously doubt you can fix this now, but how's about telling me _exactly_ how
to run rpm locally so that I can fix it myself!!!

Better yet, why don't you e-mail me an up2date program that I can run _strictly_
local - no network?

Are you aware that I can't get up2date --version to tell me anything other than
who to bitch at?  WHERE'S the darn VERSION NUMBER???

Arrghhh....       (I'm still having fun, tho...)   :^p

jdg
Comment 11 Chip Turner 2002-07-01 09:39:05 EDT
moving to high priority and assigning to misa since he owns the throttling side
of the server code
Comment 12 Aaron Freed 2002-07-29 09:30:17 EDT
 So, guys... Anything happening with this? 
 
A. 
 
P. S.  I posted a "work around" for this on bug 64049. 
 
Hopefully a permanent fix is coming soon!
Comment 13 Frank Jones 2002-08-12 01:41:59 EDT
I'm not sure if this is an additional problem, or just a symptom of the same
problem.  I think the latter.

Yesterday, I got notice of an update to 'bind' being available... just 3
packages totalling perhaps 2 or 3 Mb.

I used the handy 'up2date' icon and got the GUI up and connected quickly, and
the program worked through its dependency check, and then downloaded the
.rpms... it then did the install.  At this point I had to run out of hte office.
 When I got back, the gui told me that "due to high load... disconnected... try
later".

Well, that's pretty weird.  I thought it did the download, and then it doesn't
need to talk to RHN anymore.  What's that all about?

But, perhaps up2date needs to tell RHN what it did.  But it's not very nice to
disconnect me and prevent the program from completing, when all was fine up to
that point.

I then tried to rerun up2date, because the RedHat Notification GUI  (front end
to rhnsd I think) *still* tells me that my 'bind' packages are out of date (at
the same version they were at before yesterday's problem).  But now a problem
appears: when I go to run up2date, it decides (CORRECTLY) that I don't need to
update anything, and presents me with an empty list of packages that are
available for me to install.  I say this is "correct" because when I run 'rpm -q
bind' I get what I had expected yesterday: the latest version of 'bind' (&
friends) has been installed already.

This means that my rpm database is correct (it agrees with the bind that is now
installed), but my rhnsd is feeding me bogus information.  So I'll probably be
receiving some false requests to update my 'bind' from now on, unless I can fix
the situation manually.

So, I think that 'up2date' still has a problem (a previous posting on this bug
indicated that this was given to someone about a month ago).  At the very least,
I think what this shows is that there is another point in the operation of
up2date at which --- if a failure occurs --- there is a corruption of status
reporting between the server & client.

Like the previous writers said, this is nae guid.
Comment 14 Frank Jones 2002-08-12 02:16:36 EDT
Just thought I'd write the specifics of what the "Red Hat Network Alert
Notification Tool" is telling me, and which is incorrect.  Here is what the GUI
shows me:

Package Name | Version Installed       | Available
======================================================================
bind           bind-9.2.1-1.7x.2         bind-9.2.1-1.7x.2:,bind-9.2.1-1.7x.2:
bind-devel     bind-devel-9.2.1-1.7x.2  
bind-devel-9.2.1-1.7x.2:,bind-devel-9.2.1-1.7x.2:
bind-utils     bind-utils-9.2.1-1.7x.2  
bind-utils-9.2.1-1.7x.2:,bind-utils-9.2.1-1.7x.2:


======================================================================

Sorry for the poor formatting.

The point to note though is that the "available" version is wrong --- it is just
the same as the "installed" version plus a colon (':') at the end, repeated
twice.  The 'installed' version is actually the most recent version ofthese
packages, and was actually installed correctly (yesterday) when up2date appeared
to fail at the end of its operation, with the result that the "Red Hat Network
Alert Notification Tool" now seems to have corrupted information.

Frank
Comment 15 Mihai Ibanescu 2002-08-21 13:28:37 EDT
fjones: please file the applet bug in a separate bug report.
This bug has been fixed in the current release.
Comment 16 Aaron Freed 2002-09-17 17:42:54 EDT
Looks like we still have a problem, though this may be a SPURIOUS REPORT as the
system experiencing the difficulty is running RedHat 7.2, Kernel 2.4.9-31smp.

(Repeated messages about high load, servicing subscription clients only are
caused by the fact that I am running a script which runs "up2date --nox -u"
repeatedly, once every 10 minutes until it successfully downloads all the needed
RPMs.  Up2date does NOT attempt to install the updates due to the bug--I do that
manually with rpm -Fvh *.rpm.)

So far, this seems to be the only way to (patiently and inellegantly) get around
this defect.




Traceback (innermost last):
  File "/usr/sbin/up2date", line 1014, in ?
    main()
  File "/usr/sbin/up2date", line 341, in main
    sys.exit(batchRun(argObj.getLong("list"), pkgNames, fullUpdate))
  File "/usr/sbin/up2date", line 959, in batchRun
    up2date.getPackage(pkg, printPkg, printRetrieveHash)
  File "/usr/share/rhn/up2date_client/up2date.py", line 967, in getPackage
    progressCallback)
  File "/usr/share/rhn/up2date_client/up2date.py", line 308, in doCall
    updateLoginInfo()
  File "/usr/share/rhn/up2date_client/up2date.py", line 430, in updateLoginInfo
    loginInfo = login()
  File "/usr/share/rhn/up2date_client/up2date.py", line 339, in login
    loginInfo = doCall(server.up2date.login, systemId)
  File "/usr/share/rhn/up2date_client/up2date.py", line 287, in doCall
    ret = apply(method, args, kwargs)
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 689, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 746, in __request
    self.__protocol
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 652, in request
    return self.parse_response(fd)
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 667, in
parse_response
    return u.close()
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 366, in close
    raise apply(Fault, (), self._stack[0])
xmlrpclib.Fault: <Fault -51 """
Error Message:
    Free service limited due to high load, please try again later (server
1000927985)
Error Class Code: 51
Error Class Info:
     Due to extremely high traffic, access to Red Hat Network is currently
     limited to subscription customers.  Please try again later.  If you
     would like to become a subscription customer, go to
     https://rhn.redhat.com/preview/priority_service.pxt for more information.
Explanation:
     An error has occurred while processing your request. If this problem
     persists please submit a bug report to rhn-help@redhat.com.
     If you choose to submit the bug report, please be sure to include
     details of what you were trying to do when this error occurred and
     details on how to reproduce this problem.
""">
Exit status is now 1.
Will try again in 10 minutes.
Attempt at:
Tue Sep 17 17:21:40 EDT 2002
Running up2date...

Error Message:
    Free service limited dueto high load, please try again later (server
1000927985)
Error Class Code: 51
Error Class Info:
     Due to extremely high traffic, access to Red Hat Network is currently
     limited to subscription customers.  Please try again later.  If you
     would like to become a subscription customer, go to
     https://rhn.redhat.com/preview/priority_service.pxt for more information.
Explanation:
     An error has occurred while processing your request. If this problem
     persists please submit a bug report to rhn-help@redhat.com.
     If you choose to submit the bug report, please be sure to include
     details of what you were trying to do when this error occurred and
     details on how to reproduce this problem.

Exit status is now 1.
Will try again in 10 minutes.
Attempt at:
Tue Sep 17 17:31:43 EDT 2002
Running up2date...

Error Message:
    Free service limited due to high load, please try again later (server
1000927985)
Error Class Code: 51
Error Class Info:
     Due to extremely high traffic, access to Red Hat Network is currently
     limited to subscription customers.  Please try again later.  If you
     would like to become a subscription customer, go to
     https://rhn.redhat.com/preview/priority_service.pxt for more information.
Explanation:
     An error has occurred while processing your request. If this problem
     persists please submit a bug report to rhn-help@redhat.com.
     If you choose to submit the bug report, please be sure to include
     details of what you were trying to do when this error occurred and
     details on how to reproduce this problem.

Comment 17 Mihai Ibanescu 2002-09-19 11:09:16 EDT
If the amount of updates to be downloaded takes longer than a certain amount of
time, yes, this problem will still happen. When I closed the bug I intended to
show that kernel installs (and package installs for that matter) should be
transactional now. Not sure how can I fix the software to compensate for the
lack of bandwidth. Am I misunderstanding the defect you are reporting?

Your workaround is not 100% correct, rpm -F is not a replacement for up2date.
There are cases where rpm -F will fail (like packages with multiple
architectures or split packages). You can do it and get away with it, but don't
advertise it as _the_ solution.
Comment 18 Aaron Freed 2002-09-19 12:30:18 EDT
I know that this workaround is not _THE_solution. (Otherwise, there would be no
need for up2date, would there?  For example, rpm -Fvh doesn't resolve
dependencies either).  But, if I can get up2date to download all required
packages, and then do rpm -Fvh *.rpm, perhaps followed by rpm -Uvh *.rpm.  It
ain't perfect, and may not even be that good.  But it sure is better than
letting up2date try to do the update and then fail with that assinine message
about restricting access to subscription customers due to high load right in the
middle of a kernel upgrade.  I've already lost two servers that way before I
clued in and scrapped up2date for upgrade purposes.

I mean, really, even Microsoft doesn't suddenly abort a service pack download
and install in the middle of the process, leaving the user's machine partially
or totally hosed.

As a matter of fact, I have one server that has been trying to download updates
for two days now (That's me hitting your site once a minute.  Sorry--tell me if
you want me to stop) , but ALWAYS getting the complaint about high user load,
restricted to subscription customers, yada yada.

Please don't tell me that you don't know how to fix the software to compensate
for lack of bandwidth.  I don't buy that for a minute.  Either you offer a
"free" service or you don't.   But, as sure as those subscription users never
get cut off in the middle of an up2date operation, I am sure that you could
either modify the software to work properly for all users, add more
servers/bandwidth so the problem doesn't arrive, or simply stop offering the
free service.

A "Free" service like this should work as advertised.  If it runs a risk of this
failure mode, whereby my machines get trashed because I am using the up2date
program, then you need to include a warning with the Free service to the effect
of "WARNING: PURCHASE OF A SUBSCRIPION IS STRONGLY RECOMMENDED:  Use of this
service without a subscription MAY result in damage to your machines.  Under
certain conditions of high load, we will AUTOMATICALLY terminate your connection
in order to maintain a minimum acceptable bandwidth for our subscription
customers.  We apologize for any inconvenience that this may cause you.  In
order to minimize the chances of this happening, we suggest that you attempt
your up2date operations at <insert lowest use time here>."

Or, simply just stop offering the free update service.  But don't offer a
service that randomly but fairly frequently destroys customer installations with
no warning.  Debian, Mandrake and SuSE don't do that.  Not even MicroSoft does
that.
Comment 19 Mark J. Cox (Product Security) 2003-12-12 03:56:59 EST
7.2 is unsupported for errata past the end of this year and we've made
some significant changes to new releases, in particularly Fedora Core
uses its own update service.  For details see: 
http://www.redhat.com/software/rhelorfedora/

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