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".
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.
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. 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. 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. 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. 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: ~]$ >
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
abcde.fz: 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)
afreed: 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.
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
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..
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!
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".)
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
moving to high priority and assigning to misa since he owns the throttling side of the server code
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!
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.
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
fjones: please file the applet bug in a separate bug report. This bug has been fixed in the current release.
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. 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. 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. 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.
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.
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.
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/