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.
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.
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.
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.
(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.
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