Thought I’d share this since it was something I unfortunately spent a good portion of my afternoon wrestling with. So you want to use an elasticsearch plugin within graylog2-server? I don’t care your reasons, but this will help you do it. I’m going to go out on a limb and assume you’re wanting to use the kopf plugin to view cluster state, but this will work for any plugin.1. Download the Plugins
This can be slightly tricky… I’ve found that the best option is to install ES 0.90.10 (or whatever version is compatible with your version of graylog2) and use it to install plugins. You’ll then move the one you want from /plugins to /plugins. But if you are familiar with the plugin structure that will be created, you can manually download and unzip the plugins to the graylog2 plugins directory you define.
So for example, I’d do the following for installing kopf (a site plugin) and cloud-aws (a java based plugin).2. Specify an Elasticsearch Config File For Graylog2
This easy, just specify make sure that elasticsearch_config_file = /etc/graylog2-elasticsearch.yml is set in your graylog2.conf. You can also just run this quick sed against the stock config file.3. Specify a Plugin Dir
You’ll need to tell elasitcsearch where to actually look for the plugins, so add this to /etc/graylog2-elasticsearch.yml:
4. Put Any Plugin Specific Configuration in graylog2-elasticsearch.yml
This is pretty much plugin specific, but you’ll do this following the plugin’s installation instructions.
I’m currently using this method to make my graylog2-server instance autojoin a specific cluster based on security group and EC2 tag and it works pretty well so far.
I previously blogged about what I thought was a good way to tie librarian-puppet and vagrant together in a way that allowed one to use librarian puppet without dealing with rubygems on their system (which despite the excellent tooling can be a pain for non-rubyists).
Today I discovered there is a handy vagrant plugin for this and found that using it is a much better approach.
For the quick and dirty on how to use it:
Suffice to say, you should just use this instead.
Before you start your day think of what is one thing you can do to enrich someone’s life? Whether your family, schoolteachers, co-workers or even a random person on the street. If you could find just one thing to do that will enrich someone’s live and then multiply that to each and every day, could you imagine what kind of impact that could have?
I still remember my first early forays into using vagrant and puppet together to provision local development environments. Everything was easy accept figuring out a proper way to bundle puppet modules with a project. Basically it was a three step phase of discovery.
1. Run “puppet module install” and adding them to the git repo (not a bright est idea but simple).
2. Add puppet modules as git submodules in the project. This turned out to be even more troublesome as adding/removing/updating modules became a real pain.
3. Use puppet-librarian to manage puppet modules as the dependencies they are.
The third option was the best… we could now just simply add, remove or upgrade puppet module versions in a Puppetfile and just run “librarian-puppet install” to install the modules. But a final caveat wound up being that users had to install rubygems on their host machine which can bring other troubles. So why not just install the modules within the vagrant box when it comes up and be done with it?
This effectively adds the Puppetfile in the root of the project to the guest machine and installs the modules, referencing the modules directory when running puppet apply. This works great as you can guarantee the same install across multiple environments where developers may or may not be familiar with rubygems.