Bug 475210

Summary: package search do not work
Product: Red Hat Satellite 5 Reporter: Jan Hutař <jhutar>
Component: ServerAssignee: John Matthews <jmatthew>
Status: CLOSED CURRENTRELEASE QA Contact: Brad Buckingham <bbuckingham>
Severity: medium Docs Contact:
Priority: low    
Version: 520CC: bbuckingham, clasohm, cperry, gkhachik, jha, jmatthew, mzazrivec
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: sat530 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-08-27 17:33:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 456986, 457073    
Attachments:
Description Flags
part of /var/log/rhn/rhn_serch.log none

Description Jan Hutař 2008-12-08 15:05:33 UTC 
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 Zázrivec 2008-12-11 16:58:10 UTC 
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 05:40:40 UTC 
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 20:47:09 UTC 
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 Zázrivec 2009-02-19 12:15:24 UTC 
(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 11:24:44 UTC 
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