Bug 475210 - package search do not work
package search do not work
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server (Show other bugs)
520
All Linux
low Severity medium
: ---
: ---
Assigned To: John Matthews
Brad Buckingham
:
Depends On:
Blocks: 456986 457073
  Show dependency treegraph
 
Reported: 2008-12-08 10:05 EST by Jan Hutař
Modified: 2009-08-27 13:33 EDT (History)
7 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-27 13:33:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
part of /var/log/rhn/rhn_serch.log (6.87 KB, text/plain)
2008-12-11 11:58 EST, Milan Zazrivec
no flags Details

  None (edit)
Description Jan Hutař 2008-12-08 10:05:33 EST
Description of problem:
Package search do not show expected results


Version-Release number of selected component (if applicable):
Red Hat Network release 5.2.0
(sputnik-stage.brq.redhat.com, sputnik-prod.brq.redhat.com)


How reproducible:
always


Steps to Reproduce:
1. go to Channels -> Red Hat Enterprise Linux AS (v. 4 for 32-bit x86) -> Red Hat Network Proxy (v4.1 for AS v4 x86) -> Packages
2. filter by "rhns"
 --and--
3. search for package ""


Actual results:
2. - you see "rhns-proxy-tools-4.1.0-11.rhel4.noarch" in the list
3. - no "rhns-proxy-tools" in the list


Expected results:
2. - you see "rhns-proxy-tools-4.1.0-11.rhel4.noarch" in the list
3. - you see "rhns-proxy-tools-4.1.0-11.rhel4.noarch" in the list


Additional info:
Once I find the package, I can download it, etc. - so it is in the satellite.
Comment 1 Milan Zazrivec 2008-12-11 11:58:10 EST
Created attachment 326636 [details]
part of /var/log/rhn/rhn_serch.log

Satellite machines mentioned in comment #0 were in fact new 5.2.0 RHEL-5
installations with database imported & converted from 5.1.1 satellites that
were previously installed on those machines.

For some reason rhn-search did not create any indexes for existing packages
(hence no results for "rhns-proxy-tools"). I'm not sure whether it's related
or not, but I'm attaching beginning of /var/log/rhn/rhn_search.log showing
a java exception (not sure what caused it).

Anyway, after I copied indexes from the old installation backup into
/usr/share/rhn/search/indexes/package, everything started to work again.
Comment 2 Brandon Perkins 2008-12-17 00:40:40 EST
I'm guessing that this is really an upgrade issue.  But I'm cross-accepting this for both Search and Upgrades to make sure we test this scenario.  I believe we did have a similar test in 5.1, but it doesn't hurt to investigate the exception and to try and reproduce.  This is working on my clean new install of 5.2, but it wasn't an upgrade.
Comment 3 John Matthews 2009-02-18 15:47:09 EST
Search-server didn't create the indexes because it looks to the database to know what to index. 

It looks in the table 'rhnIndexerWork' for the last_id/last_modified columns.
It uses those values to know what data is "new" and should be reindexed.

For the situation described here when the database is restored, but the indexes aren't it makes sense search-server will be broken. 

We can try to prevent this sort of error from happening in the future.  To do so we can attempt to read the indexes, if they aren't available then we will perform a reindex and reset the last_id/last_modified in 'rhnIndexerWork'.




Also note for upgrades, it's generally a good idea to reindex the data.
In sat 5.3 we added functionality to do this.

/etc/init.d/rhn-search cleanindex

That step should be added to the upgrade steps.
Comment 4 Milan Zazrivec 2009-02-19 07:15:24 EST
(In reply to comment #3)
> Search-server didn't create the indexes because it looks to the database to
> know what to index. 
> 
> It looks in the table 'rhnIndexerWork' for the last_id/last_modified columns.
> It uses those values to know what data is "new" and should be reindexed.
> 
> For the situation described here when the database is restored, but the indexes
> aren't it makes sense search-server will be broken. 
> 
> We can try to prevent this sort of error from happening in the future.  To do
> so we can attempt to read the indexes, if they aren't available then we will
> perform a reindex and reset the last_id/last_modified in 'rhnIndexerWork'.
> 
> 
> 
> 
> Also note for upgrades, it's generally a good idea to reindex the data.
> In sat 5.3 we added functionality to do this.
> 
> /etc/init.d/rhn-search cleanindex
> 
> That step should be added to the upgrade steps.

Documentation in rhn-upgrade for 5.3.0 was updated with the step to
rebuild search indexes during satellite upgrade.
Comment 5 Carsten Clasohm 2009-03-09 07:24:44 EDT
The Installation Guide also should be updated. Chapter 8.3, Backing Up the Satellite [1], should either mention /usr/share/rhn/search/indexes, or the commands necessary to recreate the indexes.

[1] http://www.redhat.com/docs/manuals/satellite/Red_Hat_Network_Satellite-5.2.0/html/Installation_Guide/s1-maintenance-backup.html

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