I have a couple RHEL5 servers in my environment that won’t report anything relating to the RPM database. All queries return no results as if the RPM database is emtpy. I don’t have access to these serves directly but I wonder if anyone can tell me how exactly the RPM inspector queries the database and why would it fail to find anything?
I don’t have an answer to your question, but something you can try.
Can you run actions on these servers?
If so, you could run a command that would query RPM and output the data to a file, then read that with relevance. This would allow you to sanity check the inspector.
1 Like
Well I know the RPM service is working because I had an SA check it and it seems to be functioning normally but for some reason, the inspector used to query it doesn’t seem to function as it should and it seems all the patch relevance uses the RPM inspector to determine relevance because obviously it’s the easiest way to check. It doesn’t happen on a lot of servers but all the servers it does happen on are related in that they all host the same internal application. I can only assume a change was made to it in terms of compatibility with that application but I’m not sure what that was which is why I asked about how the inspector works so I know where to focus my efforts within RPM.
2 Likes
Hi @jmaple
One of a BigFix user @usman was also having the same problem and we are able to resolve the issue by applying the following workaround.
If your server is 64bit then :
Navigate into /var/opt/BESClient/__BESData/__Global/ and type ls -la if you find the results like :
lrwxrwxrwx 1 root root 51 Feb 16 15:19 /usr/lib64/libbfrpmdb.so
lrwxrwxrwx 1 root root 51 Feb 16 15:19 /usr/lib64/libbfrpmio.so
lrwxrwxrwx 1 root root 49 Feb 16 15:19 /usr/lib64/libbfrpm.so
Then proceed to /usr/lib64/ and search for aforementioned three .so files, probably they don’t exist there. Then all you have to do is to copy these three files from /var/opt/BESClient/__BESData/__Global/ and place them into /usr/lib64/ and restart the besclient service.
I hope this will solve your problem 
1 Like
I have been informed that the files you are referencing in /var/opt/BESClient/__BESData/__Global/ are softlinks to files in /usr/lib64/ that already exist. I’m not sure what copying them would accomplish.
1 Like
If they are proper soft links, then probably nothing, but I think @MirzaUsama is talking about a case where something is screwed up, in a case where the files don’t exist in /usr/lib64/ for some reason.
Also, why is the solution to go to the computer and not to check an analysis or run a task?
It seems like it would be simple enough to use relevance to say if it is a 64 bit linux computer and the files exist here, but not there, then copy them.
Well yeah in that case files were not exist on client’s machine. So inspecting the soft link and then /usr/lib64 told the whole story copying the files works in that case though.
Make sure those three .so files pointing towards usr/lib64 directory if you have 64 bit operating system.In my case they are pointing but by going manually on the location, files didnt exists.
So by copying files to the directory works for me.
The files they are pointed at exist according to my SA.