Hi there I am wondering if someone could help me with a vari

Question

Hi there I am wondering if someone could help me with a variation of this problem where osquery is unable to read the `augeas` table <https osquery slack com archives C08V7KTJB p1668118967997209> I m trying to use FleetDM live queries and additional queries to look at `augeas` on a Linux Mint device but even just `SELECT COUNT FROM augeas` returns 0 I ve had the user install `augeas lenses` locally which has fixed this issue for me before but it had no effect here `osqueryi` run locally on the machine is able to return results Has anyone run into this problem before or have any ideas for potential solutions osquery 5 2 2 Fleet 4 13 2

Andrew Zick · Answer

When I say that I ve run into this problem before I ve encountered it both when running live queries on Ubuntu and Mint devices and when running `osqueryi` locally on the same devices I ve managed to fix it every time by having the user install the augeas lenses `apt install augeas lenses` This is the first time that hasn t worked slightly frowning face

Kathy Satterlee · Answer

Hi If you check the host s installed packages through Fleet does `augeas lenses` show up there

Andrew Zick · Answer

Oh doh you re right that s a good thing to check Looks like it did install as the name is augeas lenses Query was `SELECT FROM deb packages WHERE name LIKE augeas `

Kathy Satterlee · Answer

And what happens if you query for a specific config ```SELECT FROM augeas WHERE path= etc ssh sshd config ```

Andrew Zick · Answer

disappointed

Kathy Satterlee · Answer

I figured but had to check My instinct here is that it s a permissions issue since it works with `osqueryi` but not `osqueryd` but let me dig in to it

Andrew Zick · Answer

More info that might be helpful we have Cloudflare in the mix for handling CDN web traffic stuff not my forte and previously I ve had to tweak or turn off SQLi protections that were blocking queries from running I don t think that s what s happening here but it is part of our setup

Kathy Satterlee · Answer

Are you using packages generated by Fleet or vanilla osquery on the host

Andrew Zick · Answer

I believe we use packages generated by Fleet project was set up by someone who has since left the company I had the user test both `osqueryi` and `osqueryd S` locally on their machine and they both successfully return results again just for more info

Andrew Zick · Answer

Poking around our internal docs Osquery lacks an auto updater and requires setting a large number of configuration settings to work for our use case We use Orbit a sub section of the FleetDM repository as our osquery runtime and auto updater Also included in FleetDM are commands to package Orbit into OS specific installers For Windows and Debian Linux a unique install package is generated per customer

sharvil · Answer

Another thing to check would be flags from fleet can you run this query `select name value from osquery flags where name = augeas lenses ` and see what the value of it is

Andrew Zick · Answer

The value for that query is ``` host hostname name value radiance augeas lenses opt osquery share osquery lenses ```

Michal Nicpon · Answer

Can you check if ` opt osquery share osquery lenses` actually exists You mentioned that you installed `augeas lenses` using `apt`

Andrew Zick · Answer

Actually I ve described that incorrectly The user installed it via dkpg iirc I m just accustomed to doing it via `apt` I ll go ask for confirmation from the user

Michal Nicpon · Answer

either way I suspect that osquery is looking for the lenses in the wrong location

Andrew Zick · Answer

Alright I ve been given a screenshot of what was in the ` opt osquery share osquery lenses` folder

Andrew Zick · Answer

I have an update Separately I was working on a different additional query made and deployed a change to it about 30 minutes ago then did a refresh of the data what I was getting from this Linux Mint device I now get 55459 as my result for `SELECT COUNT FROM augeas` neutral face which is plenty reasonable Works in both live query and in the additional query results that we process + store in a database What I changed for unrelated to augeas additional query it changed from ```SELECT COUNT AS result FROM disk encryption WHERE encrypted = 1 AND name IN SELECT device alias FROM mounts WHERE path = ``` to ```SELECT COUNT AS result FROM mounts WHERE path = AND device alias IN SELECT name FROM disk encryption WHERE encrypted = 1 ``` All I did was swap the outer and nested query neutral face I ll post an update on Monday to confirm whether or not it s still working Have a great weekend and thank you for helping me with this

roberto · Answer

Thanks for the update Andrew I think we will also follow up and investigate why a separate query might have affected yours and what we can do to prevent that in the future Hoping to hear from you on Monday have a great weekend

Michal Nicpon · Answer

Just following up Are you still experiencing the issue with augeas lenses

Andrew Zick · Answer

Ah sorry I must have missed my reminder to update y all on this I can confirm that I am still getting correct results from both additional queries and that it doesn t appear to have been a fluke other than that I have no idea why changing the seemingly unrelated query has fixed this