Or to restate the question : Why is Splunk Web reflecting the results of the CLI command, but inputs.conf file doesn't?
Here are the steps I took and results:
Hello.. It's my first day with Splunk 6.5.2 - Vbox running on 64 bit Windows 7 host.
GuestA : 64 bit Ubuntu 16.04 (6.5.2 installed successfully here)
GuestB : 64 bit Win 8.1 enterprise
Objective: I'd like acquire windows event logs as a data input
The docs say this:
The splunk enable listen command creates a [splunktcp] stanza in inputs.conf. For example, if you set the port to 9997, it creates the stanza [splunktcp://9997].
However, cat /opt/splunk/etc/system/local/inputs.conf show NO stanzas created. This is the entirety of the file contents:
[default] host = msutfin-VirtualBox
If you've been with us for a while... certain directives updated from the GUI at one time defaulted to $SPLUNK_HOME/etc/system/local things that would be at the "server" level. Then (and I'm not sure when) at some point the position in the GUI became important even when you were making server centric changes. Meaning the app context became even more important.
You don't mention if you were able to find what inputs.conf was updated by the CLI. I would guess... it was the one mentioned above. Second guess would be launcher.
Boiling it down... the best practice of utilizing the forwarder management (DS) and our own PS best practice of actually naming apps as to their purpose (indexer_all, forwarders_all, forwarders_unix_only) meant that you could actually put something like the listening port in an app and have that override any other settings... or simply be the place you set things... with the added benefit of being able to push them out with some identification of the destination.
This of course means that App context matters when you are using the GUI to change settings.
Did you go straight to settings from the launcher? What was the URI you were sitting on when you made the change?
For example... here's me about to change the listening port while navigating from the Team Fortress 2 application:
Long story short... you've got more rope now. Be careful you don't trip on it. 🙂
I always obsessively check what app I'm sitting in if I am making changes through the GUI. you only have to end up with an index definition in the launcher app once to learn the lesson. 🙂
.. using btool - I see that there are numerous inputs.conf. I'm still searching for the section of the docs makes a distinction as to WHICH inputs.conf to update to enable receiving. From the quick responses, it appears this is well known and feel foolish - like I didn't read some doc before posting.
1) Regardless of approach to enable receiving (CLI, manual conf update or SplunkWeb) am I responsible for which inputs.conf should be targeted / updated? (ie, how did SplunkWeb decide to create the stanza in /opt/splunk/etc/apps/launcher/local/inputs.conf vs one of the other inputs.conf returned by btool?
2) and more important to me at this point : is /apps/launcher/local/inputs.conf the correct inputs.conf to update to continue down the path of getting a forwarder working to pass eventlogs from the windows machine? (I'm only at the "receive" step, haven't even downloaded the Universal Forwarder for the windows machine yet..)
thanks - Mark
Configuration files are cumulative. Meaning you can have 5 inputs.conf files defined within different app contexts, and they all will be applied.
The way this reflects in the GUI is which app context you are currently in when you click to settings and make the configuration changes. This is by design, so that apps can import their own configurations easily and automatically.
Using btool with --debug will enable you to track down which file the configurations are being read and added from.
So to answer 2, you should define a company app standard (this is based on our best practices recommendations.) So, as an example, have an app : my_company_windows_inputs. Within this app context you can have a default/inputs.conf (or in local/) which defines your inputs and scripts. Then make sure no one adds any further inputs or outputs for your clients.
You can further this by using a deployment server to unify and manage these configurations.