Add librpm.so.9 to the names dlopen searches#19275
Conversation
Fedora 31 and 32 use librpm.so.9, but Auditbeat's system/package dataset doesn't try to load this version of the library. Fixes elastic#19253
|
Pinging @elastic/siem (Team:SIEM) |
leehinman
left a comment
There was a problem hiding this comment.
Long term I'm wondering if we should take advantage of ldconfig, something along the lines of
ldconfig -p | grep "librpm\.so"
|
Yes, I totally agree a solution like that is the optimal path. I'm just not sure what the right way to make that work is. In general search the library paths for librpm and prefer the newest (or newest that Auditbeat is compatible with).
|
We should probably open a new Issue for tracking the improvement. I'm totally fine with the current fix. That's weird, I was testing on Fedora31 from beats vagrant file too and got: I wonder what is different? Suggests this isn't robust enough. Maybe is more reliable. |
|
I had two windows open testing auditbeat related stuff and I must have got them confused. It works for too when I use the right OS 🤦 . |
Fedora 31 and 32 use librpm.so.9, but Auditbeat's system/package dataset doesn't try to load this version of the library. Fixes elastic#19253 (cherry picked from commit 6fedaef)
Fedora 31 and 32 use librpm.so.9, but Auditbeat's system/package dataset doesn't try to load this version of the library. Fixes elastic#19253 (cherry picked from commit 6fedaef)
|
@leehinman Issue created: #19287 |
Fedora 31 and 32 use librpm.so.9, but Auditbeat's system/package dataset doesn't try to load this version of the library. Fixes elastic#19253
What does this PR do?
Fedora 31 and 32 use librpm.so.9, but Auditbeat's system/package dataset doesn't try to load
this version of the library.
Why is it important?
It makes the system/package dataset work on newer Fedora releases.
Checklist
CHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.Related issues