-
Notifications
You must be signed in to change notification settings - Fork 0
deployment
Prior to distributing osquery to your infrastructure, please:
- Verify you have a working build
- Verify you understand your configuration options
- Verify you have a good understanding of osqueryi and the commands and tables available to you
Build a a package by following the instructions here.
You can now distribute and install the package across your infrastructure. Note that today, although we offer vagrant virtual machines to compile osquery, on older versions of some operating systems, some of our dependencies don't have nice packages in mainline. For development, to get around this, we compile our dependencies from source. We don't offer packages for our dependencies right now (although we're actively working on it) so if you want to distribute osquery on Linux, distributing the binary dependencies is implied.
A high-level overview:
- leverage homebrew to install all build dependencies
- distribute all dependencies with a packaged build
- don't conflict with existing package manager installations
Once you've built the code and set up a config, run the following command from the root of the osquery repository:
$ ./tools/make_osx_package.sh -c ~/path/to/my/osquery.conf
This tool will recursively identify the specific versions of homebrew dependencies you used to compile osquery. The dependencies will be packaged into an OS X pkg installer, along with:
- the osqueryi and osqueryd binaries
- the LaunchDaemon that is responsible for osqueryd
- the osqueryd config file that was specified via the command line
make_osx_package.sh uses homebrew to create an exact replica of your installed packages. This ensures osquery has it's specific dependencies bundled (ex: Boost 1.56.0), but also ensures that existing environment/system dependencies aren't clobbered.
If you have OSX hosts that are used for C++ development or have package managers other than Homebrew, you don't have to worry about osquery negatively impacting developers or existing package managers. Core libraries are installed in a unique directory (not /usr/local/Cellar).
Here is the output from us running make_osx_package.sh:
$ ./tools/make_osx_package.sh -c ~/Desktop/osquery.conf
[+] calculating dependency tree
[+] copying dependencies
- rocksdb (/usr/local/Cellar/rocksdb/3.5)
- boost (/usr/local/Cellar/boost/1.56.0)
- gflags (/usr/local/Cellar/gflags/2.0)
- glog (/usr/local/Cellar/glog/0.3.3)
- thrift (/usr/local/Cellar/thrift/0.9.1)
- lz4 (/usr/local/Cellar/lz4/r116)
- pkg-config (/usr/local/Cellar/pkg-config/0.28)
- snappy (/usr/local/Cellar/snappy/1.1.1)
[+] copying osquery binaries
[+] copying osquery configurations
[+] finalizing preinstall and postinstall scripts
[+] creating package
[+] package created at ~/git/osquery/osqueryd.pkg
As you can see, the distributable package can be found at ~/git/osquery/osqueryd.pkg.
You can now use your existing package distribution system (JAMF, Chef, etc) to push this package to your infrastructure.
If you want to modify the command-line arguments used to start osquery, copy and modify the LaunchDaemon which is included with this repository to suit your liking. When you run make_osx_package.sh, include a -l/--launchd-path flag which indicates the path of your new LaunchDaemon. If specified, this will be used instead of the default LaunchDaemon. For example:
./tools/make_osx_package.sh -c /internal/osquery/osquery.conf -l /internal/osquery/com.facebook.osqueryd.plist
Perhaps you just want to deploy the osquery binaries via a pkg and you'd like to manage the scheduling of osqueryd via some other mechanism. To do this, when you run make_osx_package.sh, include a -n/--no-launchd flag. This will make the package just lay the binaries down. The LaunchDaemon won't be included and no LaunchDaemon will be unloaded or loaded by the post-install script of the package. For example:
./tools/make_osx_package.sh --no-launchd