Can't Point Universal Forwarder to an Indexer from Deployment Server

[BenjaminWyatt]

Hi everyone,
I have several forwarders in my environment that aren't currently sending any data to indexers. I've been trying to link them up to indexer by pushing an app to them from their deployment server (which they were linked up to in the installation). I've been working with a test case at this point, but I've been having trouble pushing the app to the Splunk Universal Forwarder.

Here's the process I followed:

1. Create a new app on the deployment server in /opt/splunk/etc/deployment-apps. Create an outputs.conf file in /opt/splunk/etc/deployment-apps//local with the following syntax:

   [tcpout]
   
   indexAndForward=false
   
   defaultGroup=my_LB_indexers

   [tcpout:my_LB_indexers]
   
   disabled=false
   
   server=indexer_name:port#

2. Edit serverclass.conf in ~etc/system/local to apply the app to the desired forwarders by adding the following stanzas:

   [serverClass:my_test_serverclass_name]
   
   filterType = whitelist
   
   repositoryLocation = /opt/splunk/etc/deployment-apps
   
   restartSplunkd = true
   
   whitelist.0 = hostname_pattern

   [serverClass:my_test_serverclass_name:app:deployment_app_name]

3. Restart the deployment server to push the config changes. I use the command: splunk reload deploy-server

I can see the new serverclass and my desired hosts on the deployment server. However, it seems that the application has never been pushed to my forwarders. I've checked splunkd.log for error messages after the restart, but I haven't seen any error messages pertaining to my app. What am I missing here? Any help is greatly appreciated!

[BenjaminWyatt · Accepted solution]

I figured it out, but I wanted to post my answer here in case anyone else has the same problem!

If you look in SplunkUniversalForwarder/etc/system/local, there's a file called server.conf that defines your hostname. In my case, the whitelist provided did not match this hostname; I had provided the fully-qualified domain name, but server.conf did not. Once I fixed this problem, everything worked fine.