Getting Data In

Why deployment server sees Linux UX univeral forwarder as the GUID even with a set ServerName?

t9445
Path Finder

Hello, we have what appears to be an incredibly weird scenario going on:

We commonly override the serverName for deployment purposes in the server.conf

(Please note: We have/are ongoing successfully been doing this for some time with Linux and Windows UFs)

However for a specific subset of Linux UX forwarders (v6.1.3 Build 220630) the serverName (as seen by the deployment server) is the GUID as configured in the instance.cfg file

Note: deployment-server is Linux, same version (Build 220630)
I have checked, and yes the serverName is set as desired in $SPLUNK_HOME/etc/system/local/server.conf and NO – there are no other server.conf files with a serverName entry

When (as an experiment) I removed the instance.cfg file and restarted the UF, a new instance.cfg file is generated and with a new GUID as expected – the UF then appears to the deployment-server as the new-GUID (e.g there is nothing "stuck" in any config files with the serverName set as the OLD-GUID)

The serverName consistently is coming through as seen at the deployment server as the GUID ?

Is this a 6.1.3 (Linux) Universal forwarder bug ? (we have other instances running 6.1.2 and earlier etc successfully ) or have others run into this and what is the fix please? (Note: I have tried setting the environment HOSTNAME per some others, no success)

Appreciate any insights – next step will be to migrate the 6.1.3 UFs to 6.1.4 , however not an easy task since we will have to re-deploy a number of images in the cloud if we take this approach, so would like to be certain it is a bug or if there is any workarounds for this scenario?

0 Karma
1 Solution

t9445
Path Finder

(Follwoing up) -- the reason for this issue was (yup...) human error - in this specific scenario we are automatically deploying instances to the cloud - as part of the "spin-up" we update the local deploymentclient.conf to the desired hostname for splunk-software-distribution to-pick-up within the cloud, long story short - the code was incorrectly updated (by an overzealous programmer 🙂 -- to use hostname instead of clientName (DOH!).

View solution in original post

0 Karma

t9445
Path Finder

(Follwoing up) -- the reason for this issue was (yup...) human error - in this specific scenario we are automatically deploying instances to the cloud - as part of the "spin-up" we update the local deploymentclient.conf to the desired hostname for splunk-software-distribution to-pick-up within the cloud, long story short - the code was incorrectly updated (by an overzealous programmer 🙂 -- to use hostname instead of clientName (DOH!).

0 Karma
Get Updates on the Splunk Community!

Optimize Cloud Monitoring

  TECH TALKS Optimize Cloud Monitoring Tuesday, August 13, 2024  |  11:00AM–12:00PM PST   Register to ...

What's New in Splunk Cloud Platform 9.2.2403?

Hi Splunky people! We are excited to share the newest updates in Splunk Cloud Platform 9.2.2403! Analysts can ...

Stay Connected: Your Guide to July and August Tech Talks, Office Hours, and Webinars!

Dive into our sizzling summer lineup for July and August Community Office Hours and Tech Talks. Scroll down to ...