osquery has two RFCs related to backend infrastructure[1] and distributed queries[2]. Have you looked at their proposals? How do you think Envdb compares?
I'm curious about the choice of wrapping osquery instead of implementing a logger plugin[3]. Was it easier to implement and deploy as a wrapper?
Yea, I looked at them. EnvDB has plans to extend past just using osquery. Work could be done to connect deeper or use libosquery directly. I chose to wrap it and plan to build a plugin system for wrapping other processes. It would make wrapping other stuff to conform to a sql question/answer model easier and faster to implement imho. (either way.. whatever they add wont break envdb ;) hehe)
1. Security is a huge one. One of the saved queries is checking for processes running that don't have the original binary still on disk. etc. Being able to query stuff like that on demand is powerful. It also has a lot of ops related wins.
2. Well, agree but when you're solo and doing it for fun.. getting it working is half the battle. I know my expectations for the app now and that makes it much easier to write meaningful tests. I must have redid the node/server setup 3 times.. writing tests for failed implementation just sounds like a poor use of time. Also, the project is 0.1.1.. thats super beta man.. give it time.
Indeed! Whats also great about osquery is the security related tables available. I.e process_memeory_map, crontab, passwd_changes, shell_history etc. A lot of the stuff osquery gets is right from the kernel (system calls etc.)
osquery has two RFCs related to backend infrastructure[1] and distributed queries[2]. Have you looked at their proposals? How do you think Envdb compares?
I'm curious about the choice of wrapping osquery instead of implementing a logger plugin[3]. Was it easier to implement and deploy as a wrapper?
[1] https://github.com/facebook/osquery/issues/881
[2] https://github.com/facebook/osquery/issues/201
[3] https://github.com/facebook/osquery/wiki/registering-logger-...