Environment:
Splunk version: 7.2.5
Distributed deployment with multiple Heavy Forwarders managed by Deploymentserver.
I wrote an app for the Heavy forwarders to handle the inputs:
-TA-HF-ListenToInput/local/inputs.conf
[http]
port = 8088
disabled = 0
enableSSL = 1
[splunktcp-ssl:9997]
disabled = 0
Rolling out this app has the following effect regarding HEC:
If I roll out the [http] part of this config using the splunk_httpinput app as deployment-app, HEC works just fine as desired.
Only way i now see to enable HEC on Heavy Forwarders via Deploymentserver is rolling out splunk_httpinput, however this has the downside, that i need to checkin the default folder of the app in version control without making any changes to it, because it will otherwise be deleted and Splunk will throw warnings for failed File integrity check as a result.
I am also not looking to handle HEC centrally from Deploymentserver, since it reduces the modularity of my deployment.
In my opinion, this behaviour is a bug solely based on the fact that btool check does not reflect state of the system, but before I raise it as a bug report, I want to ask whether anyone else has encountered similar issues and knows a better workaround than what I can come up with.
Finally it would probably be worth noting that my app has lower precedence than splunk_httpinput lexicographically in my case but 'local' should of course still take precedence over 'default'.
I see similar behavior. I added an app that creates a new index, and defines HEC token and added the app to a fresh install (8.0.2) with no other changes. For me. the HEC is enabled (I can curl a request and see the data ingested to the new index). Btool shows the app's effect in the runtime config.
/opt/splunk/etc/apps/docker_hec_inputs/local/inputs.conf [http]
/opt/splunk/etc/system/default/inputs.conf _rcvbuf = 1572864
/opt/splunk/etc/apps/splunk_httpinput/default/inputs.conf ackIdleCleanup = true
/opt/splunk/etc/apps/splunk_httpinput/default/inputs.conf allowSslCompression = true
/opt/splunk/etc/apps/splunk_httpinput/default/inputs.conf allowSslRenegotiation = true
/opt/splunk/etc/apps/splunk_httpinput/default/inputs.conf dedicatedIoThreads = 2
--> /opt/splunk/etc/apps/docker_hec_inputs/local/inputs.conf disabled = 0 <--
--> /opt/splunk/etc/apps/docker_hec_inputs/local/inputs.conf enableSSL = 0 <--
/opt/splunk/etc/system/local/inputs.conf host = splunktest
/opt/splunk/etc/system/default/inputs.conf index = default
/opt/splunk/etc/apps/splunk_httpinput/default/inputs.conf maxSockets = 0
/opt/splunk/etc/apps/splunk_httpinput/default/inputs.conf maxThreads = 0
/opt/splunk/etc/apps/splunk_httpinput/default/inputs.conf port = 8088
/opt/splunk/etc/apps/splunk_httpinput/default/inputs.conf sslVersions = *,-ssl2
/opt/splunk/etc/apps/splunk_httpinput/default/inputs.conf useDeploymentServer = 0
As far as I can tell it's a UI bug more than a issue with the config not taking effect. The UI only seems to remove the red ! warning and stop showing "disabled' tokens if the splunk_httpinput/local/inputs.conf file exists with a [http] stanza and disabled=0 exists.