There is maybe an opinion or explanation about this. Or do I miss something. Or is this related to some “inotify” packages I did not identify yet?
My work is security and compliance and I am running a known tool against AlmaLinux for testing. First aim is to see whether the “agents” in use are just working as expected, and they do. This tools are designed to look into anything, so I am not the perfect ultimate Linux SME when interpreting findings, but I am not an amateur.
At this point, I don’t say that something is wrong with “sysctl”.
The screen shot shows the file data from two dates. 14APR was the first data taken, let’s call it the baseline. This was after the installation of the OS and some updates (dnf update). On 26APR I find changes for /sbin/sysctl (see sha1 and length).
Now I am digging through the repos and cannot find a “sysctl” version with exactly this checksum.
On my server (Alrep) I am running a AlmaLinux repo mirror (rsync every 3 hours) and see in real-time any changes there.
My point is, that I have now a /sbin/sysctl version on server Alrep1 for which I cannot find any matching version with the same length and checksum in the repository.
Repo dirs I am looking at:
**# ./8.3/AppStream/x86_64/os/Packages **
**# ./8.3/BaseOS/x86_64/os/Packages
**# .8.3/PowerTools/x86_64/os/Packages
What am I looking for:
I am looking for an explanation, where the new version of /sbin/sysctl did came from. Unless clarified I would consider this binary (sysctl) as not genuine.
At this point I am not allowed to provide the full list of installed packages here (new user limits).
In my previous post I’ve given a link to the package that contain sysctl binary with checksum you’re looking for.
It comes from procps-ng-3.3.15-3.el8_3.1.x86_64 package.
Very Cool!!!
Verified and TRUE!
I will check why this slipped through on my side. I was most probably too focused explaining - sorry!
And good news for AlmaLinux: some very expensive enterprise tool (no runtime agent!) is working without troubles on this very promissing distro.
@Neon, considering the fact the binary changed in size. Your new binary, came from the version-revision of the package that @alukoshko suggested if you executed a dnf|yum update.
So execute a rpm changelog check and read the results for a deeper explanation, for your own comfort by executing the following: