Experienceing a Delay When Updating RPMs from Redhat Satellite Sever
I've noticed this over the last few days that if I try to apply errata from the Red Hat Satellite, it is not instant. Matter of fact I just install three rpms starting around 7:00 am CST and they show successfully installed around 10:15 am CST.
However if I hit the logs on the server under /var/log , it still shows rpms that I installed manually and not the ones that were installed from the server, from last week:
[root@ameda4aisrx0236 log]# tail -25 yum.log
May 29 09:59:47 Installed: openscap-1.0.8-1.el5_10.x86_64
May 29 09:59:47 Installed: openscap-utils-1.0.8-1.el5_10.x86_64
May 29 09:59:49 Installed: spacewalk-oscap-2.3.0-2.el5sat.noarch
[root@ameda4aisrx0236 log]#
I just installed the following rpms from the Satellite:
tzdata-2014b-1.el5 x86_64 6/2/15 10:01:39 AM CDT
ksh-20100621-18.el5_10.1 x86_64 6/2/15 10:01:49 AM CDT
From the server itself:
[root@ameda4aisrx0236 log]# rpm -qa | grep ksh
ksh-20100621-18.el5_10.1
[root@ameda4aisrx0236 log]# rpm -qa | grep tzdata
tzdata-2014b-1.el5
[root@ameda4aisrx0236 log]#
[root@ameda4aisrx0236 log]# yum info ksh
Loaded plugins: rhnplugin, security
This system is receiving updates from RHN Classic or RHN Satellite.
Installed Packages
Name : ksh
Arch : x86_64
Version : 20100621
Release : 18.el5_10.1
Size : 3.1 M
Repo : installed
Summary : The Original ATT Korn Shell
URL : http://www.kornshell.com/
License : Common Public License Version 1.0
Description: KSH-93 is the most recent version of the KornShell by David Korn of
: AT&T Bell Laboratories.
: KornShell is a shell programming language, which is upward compatible
: with "sh" (the Bourne Shell).
Available Packages
Name : ksh
Arch : x86_64
Version : 20100621
Release : 20.el5
Size : 1.3 M
Repo : rhel-x86_64-server-5
Summary : The Original ATT Korn Shell
License : Common Public License Version 1.0
Description: KSH-93 is the most recent version of the KornShell by David Korn of
: AT&T Bell Laboratories.
: KornShell is a shell programming language, which is upward compatible
: with "sh" (the Bourne Shell).
Here yum shows that the available package is a more up-to-date Vs what rpm -qa showed.
The same with tzdata:
[root@ameda4aisrx0236 log]# yum info tzdata
Loaded plugins: rhnplugin, security
This system is receiving updates from RHN Classic or RHN Satellite.
Installed Packages
Name : tzdata
Arch : x86_64
Version : 2014b
Release : 1.el5
Size : 1.8 M
Repo : installed
Summary : Timezone data
URL : https://www.iana.org/time-zones
License : Public Domain
Description: This package contains data files with rules for various timezones around
: the world.
Available Packages
Name : tzdata
Arch : noarch
Version : 2010e
Release : 1.el5
Size : 794 k
Repo : rhel-x86_64-server-5
Summary : Timezone data
License : GPL
Description: This package contains data files with rules for various timezones around
: the world.
Name : tzdata
Arch : x86_64
Version : 2014h
Release : 2.el5
Size : 787 k
Repo : rhel-x86_64-server-5
Summary : Timezone data
License : Public Domain
Description: This package contains data files with rules for various time zones
: around the world.
[root@ameda4aisrx0236 log]#
Am I approaching this the correct way?
Responses
Name resolution can effect the speed of initial connections to a number of services. I know that when one of our repos was being afflicted with issues resolving clients, it markedly slowed things down since each RPM was being handled as a discreet GET transaction. Can't remember which project it was for, though (some projects I've worked on used Satellite and some only used bare HTTP-based repos).
Regarding viewing previous updated activity using /yum/log: that only works for actions performed specifically with the "yum" command. The yum.log file does not include install/update/remove actions initiated from a Satellite server. For that, you need the "yum history" command.
For the "not instant" timing issue...it depends on which version of Satellite you are using. Satellite 5.x does not directly initiate tasks on clients; it only queues up actions which are picked up the next time the client 'rhnsd' process on the client polls the Satellite server (by default, every 4 hours). Satellite 6.x seems to use something like RPC to (more or less) immediately communicate from the server to the client to initiate actions like a package install or update. From the 'yum info...' output above, I suspect you are using Satellite 5.x, hence the long delay before the packages were actually installed.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
