How can I control the client's Host Name that appears in Forwarder Management?

[fsalamo]

Question:
How can I control the client's "Host Name" that appears in Forwarder Management?

Configuration:
Splunk Server on EC2
Universal Forwarder on another EC2
On the client, I have

[default] 
host = mongod-eu-20141003

in ./search/local/inputs.conf, and that appears correctly in the Search plugin.

Where do I need to put that "host" declaration for that same value to be used in Forwarder Management? I've tried several locations, including directly in the deploymentclient.conf stanza where I tell it how to find the deployement server, but I always just see the DNS name in the list of available servers in Forwarder Management. So instead of mongod-eu-20141003 it just shows the basic EC2 hostname, i.e. ip-[local-vpc-ip-address].

[pellegrini]

The simple answer is: Host Name in Forwarder Management is the same as you would get using the hostname shell command in both *nix and Windows. The answer marked Solution is not entirely true. If you restart splunk you will also see this hostname in the splunkd.log. I don't think there is and should be any way to override that value. Also it is very useful to see the real hostname.

02-04-2021 22:05:22.836 +0100 INFO  ServerConfig - My hostname is "smarttest-old.band.com".

[Akeydel]

I strongly disagree, as the Forwarder Management in a Deployment Server does not allow you to search via Instance Name. 
It makes it difficult to match data you see in Splunk to the actual Host sending it. 

[pellegrini]

Correct, Instance Name is not searchable in Forwarder Management (and cannot be used in serverclass.conf).

Host Name in Forwarder Management is the real server name as perceived by Splunk and cannot be configured.

Host field in an event is coming from the host stanza in inputs.conf

If host in inputs.conf is set to a static value e.g. the server hostname, and the server hostname is changed, then event Host field and Host Name in Forwarder Management will differ. That situation is problematic.

[Akeydel]

As I've learned recently, there's nothing stopping someone from defining a different Host value in an input, and causing that problematic situation much more quickly and broadly. 
This seems like a huge oversight in functionality.

[ppeterson]

My apologies, I should have posted this. This works up to 6.4.3 UF's... I would still prefer to have the ability to overwrite the hostname as I needed to rewrite some validation scripts to account for this using the clientName field:

Windows
C:\Program Files\SplunkUniversalForwarder\splunkforwarder\etc\system\local\deploymentclient.conf" and change the "clientName = XXX" This requires creating a "deployment-client" stanza and adding a "clientName = XXX" before the target-broker and targetURI:

Example:

[deployment-client]

clientName = XXX

[target-broker:deploymentServer]

targetUri = 10.1.1.1:8089

[MarioM · Accepted solution]

there is different conf files you can set this depending if you are looking at setting the actual hostname or the instance name or custom client name:

inputs.conf for splunk actual hostname

[default]
host = <string>
* Sets the host key/field to a static value for this stanza.
* Primarily used to control the host field, which will be used for events coming in
  via this input stanza.
* Detail: Sets the host key's initial value. The key is used during parsing/indexing, 
  in particular to set the host field. It is also the host field used at search time.
* As a convenience, the chosen string is prepended with 'host::'.
* WARNING: Do not quote the <string> value: host=foo, not host="foo".
* If set to '$decideOnStartup', will be interpreted as hostname of executing machine;
  such interpretation will occur on each splunkd startup.  This is the default.

server.conf for splunk instance name :

[general]
serverName = <ASCII string>
    * The name used to identify this Splunk instance for features such as distributed search.
    * Defaults to <hostname>-<user running splunk>.
    * May not be an empty string
    * May contain environment variables
    * After any environment variables have been expanded, the server name (if not an IPv6
      address) can only contain letters, numbers, underscores, dots, and dashes; and
      it must start with a letter, number, or an underscore.  

deploymentclient.conf for custom client name

[deployment-client]
clientName = deploymentClient
    * Defaults to deploymentClient.
    * A name that the deployment server can filter on.
    * Takes precedence over DNS names.

[fsalamo]

Thanks! It was clientName that I was missing. I was assuming it could not be overridden because it was a GUID. I ran into the whitelist bug after that, but it was an easy workaround.

[ppeterson]

I am looking to override the Host Name in the Forwarder Management but I have been unsuccessful. Changing the clientName in deployment.conf changes the Client Name but not the Host Name.

We have changed the inputs.conf to reflect the new name but need to have consistency for scripting with the Host Name in Forwarder Management.

All changes/testing were done in C:\Program Files\SplunkUniversalForwarder\etc\system\local and we need to be able to do this in both Windows and Linux - any idea what I may be missing?

[ddrillic]

The following makes it clear that inputs.conf is the right place.

[ppeterson]

Thanks for your response, however the documentation doesn't align with the reality of my experience and testing.

[suarezry]

Same issue. I wish to override the Host Name in Forwarder Managment but changing clientName in deploymentclient.conf, serverName in server.conf, or hosts in inputs.conf has no effect. This is with universal forwarder v6.5.0

[sidekix24]

We're experiencing the same issue....Has anyone figured out a fix yet?

[emikulic]

Some years later and this is still the case. Neither inputs.conf, server.conf, or deploymentclient.conf will change the 'Host Name' for the forwarder under mangement of the Deployment Server.

It may take some environment variable or startup variable to change this. I am not sure.

Sad this is so difficult and should be far easier.

(IMHO Splunk puts far too much on their customers and now cutting support for non-paid apps means even MORE is put on the customers. I bet it comes back to bite them soon.)