Getting Data In

Updating Remote Forwarders

Communicator

Hello,

I have about 80 remote forwarders that forward back to a central Splunk server. I was wondering if anyone had come up with a solution to updating these remote forwarders. My desired functionality would be to be able to have the forwarder check a repository for the following:

  • latest version of Splunk. If the version in the repository is newer, upgrade.
  • check props.conf & transforms.conf. These differ slightly among the forwarders so I would have to be able to point to sub-types for the machines.
  • check inputs.conf & update if newer. However, in inputs.conf there is a hostname field that is different on every machine so this would have to be left alone.

I was starting to write something to accomplish this but it seems like this would be a common need so I was wondering if anyone had implemented something similar.

Thanks for your help.

Kevin

Explorer

Hi.

i know this is a old topic, but i want to now, do you found a good solution?

thanks.

0 Karma

Splunk Employee
Splunk Employee

Have you considered using Puppet or Chef?

Communicator

Thanks for the link and suggestions.

I ran into a bunch of issues with deployment server where it showed it was contacting the server but never actually pulled anything down, so I was planning to replace that with something else while also including the splunk installer. All boxes in a group are the same, all are Windows. I would want something that allowed it to install automatically after it was triggered by an admin.

0 Karma

Super Champion

Super Champion

Great question. I use the deployment server for keeping all the .conf files updated, and I have a custom per-server app for a number of my boxes with unique inputs settings. But, that's only half of your request. We have a much small number of forwards, so for now I'm doing all of that by hand. It would be possible to deploy a custom app with a "scripted input" script that downloads and installs the latest version (when needed), but there are tons of potential problems with that kind of approach; such as permissions, and failed/partial upgrades, in-use files, 32 vs 64 bit, tar/rpm/deb?

0 Karma