Bug 114481 - Errata not showing as applicable
Errata not showing as applicable
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Todd Warner
Fanny Augustin
Depends On:
Blocks: rhn360sat
  Show dependency treegraph
Reported: 2004-01-28 11:26 EST by Kevin Otte
Modified: 2007-07-31 10:34 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-10 11:20:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kevin Otte 2004-01-28 11:26:52 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030922

Description of problem:
After new errata are released and synced to our satellite in the
nightly satellite-sync, said errata are not showing as applicable to
my machines. If I force a package profile update, the errata then show
as applicable.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Wait for errata to come out
2. Perform satellite-sync
3. Check list of machines that are out of date

Actual Results:  All profiles still indicate they are up-to-date

Expected Results:  All profiles should have indicated they have errate
available to them.

Additional info:

Versions of relevant packages installed:
Comment 1 Bret McMillan 2004-01-28 11:36:52 EST
Is taskomatic running on the box?
Comment 2 Kevin Otte 2004-01-28 11:47:23 EST
Yes, it is.
Comment 4 Kevin Otte 2004-02-20 12:44:59 EST
I just noticed something interesting.  The errata are not showing
applicable in the web interface, but I just got an email from the
satellite informing me that most of my 200 machines require the latest
kernerl errata.  This tells me that the satellite is aware of the
errata to machine mapping at some level, but it's not showing it to me
on the website so I can schedule it.
Comment 5 Greg DeKoenigsberg 2004-04-20 14:46:25 EDT
We definitely need to check to see if this is happening in latest
satellite code.
Comment 6 Robin Norwood 2004-05-13 10:26:26 EDT
Ok, it looks like the erratacache is not being scheduled when a
satellite_sync is run.  We should be scheduling it for each channel
that satellite_sync touches.

How I reproduced it:

1. I took a (3.2) satellite that had not yet received the latest update.

2. I registered an AS3 system against it.  Two errata applied to the

3. I ran 'satellite-sync' with no arguments.

4. When the sync was complete, I checked the errata page for the
system, and the same two errata apply.

5. I scheduled an errata cache update from

6. Now 56 errata apply to my system.

The sat is rhnblade4.perf.redhat.com - it is a 3.2 satellite, which is
the newest I have access to.

Re-assigning to taw - unless this is fixed in 3.3, please fix.
Comment 7 Robin Norwood 2004-05-13 10:29:43 EDT
This is what the perl code does when a channel is modified:

SELECT task_data
  FROM rhnTaskQueue
 WHERE task_data = :cid

if rows are returned {
UPDATE rhnTaskQueue
   SET earliest = TO_DATE(:now, 'YYYY-MM-DD HH24:MI:SS') + :delay
 WHERE task_data = :cid

(:delay is '0' for immediate update)
else {
INSERT INTO rhnTaskQueue
       (org_id, task_name, task_data, priority, earliest)
VALUES (:org_id, 'update_errata_cache_by_channel', :cid, 0,
TO_DATE(:now, 'YYYY-MM-DD HH24:MI:SS') + :delay)

Comment 8 Todd Warner 2004-05-24 10:58:06 EDT
This sucks big time. Working on it.
Comment 9 Todd Warner 2004-05-24 14:40:25 EDT
Kevin... does the problem go away if you do a
satellite-sync --cache-refresh-level=6
Comment 10 Kevin Otte 2004-05-26 09:41:26 EDT
Kambiz ran your satellite-sync command on Monday, and it did update
the errata counts for errata that had already been published.  I got
an errata update email this morning for the RHEL 3WS tcpdump errata
indicating that it was applicable to most of my machines, but the web
interface on the satellite only indicates it being applicable to 4

Short answer to your question: nope :(
Comment 11 Todd Warner 2004-05-27 11:29:42 EDT
I think this might be a RHN 260 issue. We fixed a major issue with
packages that reside in multiple channels. It was not really an issue
until RHEL3 where it reared it's ugly head.

I recommend scheduling an upgrade.
Comment 12 Todd Warner 2004-05-27 11:30:28 EDT
Oh... also NOTE. I was *not* able to reproduce this in RHN 320. I
think rnorwood is on crack! :)
Comment 13 Todd Warner 2004-05-27 11:34:03 EDT
Can you confirm something for me?

Does the problem go away if you:
satellite-sync --list-channels # to get the labels
Sync each channel individually:
satellite-sync --cache-refresh-level=6 -c CHANNEL_LABEL

I don't know if this will fix it, but we'll see.
I am going to get an RHN 260 box set up to try to duplicate all of this.
Comment 14 Todd Warner 2004-06-01 15:24:01 EDT
Ok... I think this is CURRENTRELEASE but I want QA to take a look at this.

o install RHN Satellite
o sync RHEL 3 WS
  sync RHEL 3 WS, ES and AS
o register a client machine to each distro. The client machines need
  to have the some of the same errata needed for each, so making them
  all QU1 should be fine.
o verify that all relavent errata are available for each of these   
  clients... and reported as needed by the clients.
Comment 15 Todd Warner 2004-06-01 15:28:40 EDT
o install RHN Satellite
o service taskomatic stop
o sync RHEL 3 WS
  sync RHEL 3 WS, ES and AS
o register a client machine to each distro. The client machines need
  to have the some of the same errata needed for each, so making them
  all QU1 should be fine.
  select * from rhnTaskQueue;
  ...there should be a list of channels there for WS, ES, and AS
o service taskomatic start
o verify that all relavent errata are available for each of these   
  clients... and reported as needed by the clients.
Comment 16 Fanny Augustin 2004-06-22 10:19:20 EDT
I received the error below while trying to satellite-sync the RHEL 3
WS channel to my satellite (https://farm03.rhndev.redhat.com):

Exception Handler Information
Traceback (innermost last):
  File "/usr/bin/satellite-sync", line 129, in main
    return satsync.main()
  File "/var/www/rhns/satellite_tools/satsync.py", line 1709, in main
  File "/var/www/rhns/satellite_tools/satsync.py", line 770, in
  File "/var/www/rhns/satellite_tools/syncContainerHandlers.py", line
371, in processErrata
  File "/var/www/rhns/server/importlib/importLib.py", line 515, in run
  File "/var/www/rhns/server/importlib/errataImport.py", line 110, in fix
  File "/var/www/rhns/server/importlib/errataImport.py", line 232, in
    for nevrao, package in erratum['packages'].items():
AttributeError: items

Comment 17 Todd Warner 2004-07-01 02:09:47 EDT
I can't duplicate that error as much as I have tried. Everything seems
to work for me. It was possibly environmental? Regardless, I am
kicking  this back to ON_QA for testing.

If you encounter this problem again: stop testing, and immediately
fetch me to troubleshoot the system directly.

Comment 18 Todd Warner 2004-07-01 13:40:29 EDT
Copying part of the discussion I had with Jamo:
The fix:
satellite-sync --cache-refresh-level=6

What I think is going on: I think you are switching environments (webdev
to webqa) without blowing away your sync cache. What this does is leave
all kinds of cruft sitting in the cache that doesn't match what is in
hosted. An example: kernel erratum X has a bunch of packages with
incorrect IDs in it, etc.

So... that traceback is NOTABUG IMHO. We need to document this issue
though as a test-environment concern.

Comment 19 Kambiz Aghaiepour 2004-07-01 15:21:06 EDT
The fix did _not_ work.  That is, satellite-sync
--cache-refresh-level=6 did not do the trick.

Granted, this was on satellite code based on 2.6, and now we are
running version 3.2.0.

Kevin, can you verify if this problem has gone away, or if it still
stands since we upgraded the satellite to 3.2.0?

Comment 20 Fanny Augustin 2004-08-10 12:56:50 EDT
This require a lot of time to test "syncing channels"...  Deferring to
rhn360sat since it is not critical.
Comment 21 Fanny Augustin 2004-12-10 11:20:21 EST
this problem seems to have disappeared in RHN Sat 3.6. I am closing
this bug CURRENTRELEASE and we simply have to keep on a lookout for
this problem resurfacing. - Todd Warner (sitting at Fanny's desk :)

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