<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Why deployment server sees Linux UX univeral forwarder as the GUID even with a set ServerName? in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/Why-deployment-server-sees-Linux-UX-univeral-forwarder-as-the/m-p/151288#M30786</link>
    <description>&lt;P&gt;Hello, we have what appears to be an incredibly weird scenario going on:&lt;/P&gt;

&lt;P&gt;We commonly override the serverName for deployment purposes in the server.conf &lt;/P&gt;

&lt;P&gt;(Please note: We  have/are ongoing successfully been doing this for some time with Linux and Windows UFs)&lt;/P&gt;

&lt;P&gt;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&lt;/P&gt;

&lt;P&gt;Note: deployment-server is Linux, same version (Build 220630)&lt;BR /&gt;
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&lt;/P&gt;

&lt;P&gt;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)&lt;/P&gt;

&lt;P&gt;The serverName consistently is coming through as seen at the deployment server as the GUID ?&lt;/P&gt;

&lt;P&gt;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)&lt;/P&gt;

&lt;P&gt;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? &lt;/P&gt;</description>
    <pubDate>Fri, 03 Oct 2014 21:08:07 GMT</pubDate>
    <dc:creator>t9445</dc:creator>
    <dc:date>2014-10-03T21:08:07Z</dc:date>
    <item>
      <title>Why deployment server sees Linux UX univeral forwarder as the GUID even with a set ServerName?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Why-deployment-server-sees-Linux-UX-univeral-forwarder-as-the/m-p/151288#M30786</link>
      <description>&lt;P&gt;Hello, we have what appears to be an incredibly weird scenario going on:&lt;/P&gt;

&lt;P&gt;We commonly override the serverName for deployment purposes in the server.conf &lt;/P&gt;

&lt;P&gt;(Please note: We  have/are ongoing successfully been doing this for some time with Linux and Windows UFs)&lt;/P&gt;

&lt;P&gt;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&lt;/P&gt;

&lt;P&gt;Note: deployment-server is Linux, same version (Build 220630)&lt;BR /&gt;
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&lt;/P&gt;

&lt;P&gt;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)&lt;/P&gt;

&lt;P&gt;The serverName consistently is coming through as seen at the deployment server as the GUID ?&lt;/P&gt;

&lt;P&gt;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)&lt;/P&gt;

&lt;P&gt;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? &lt;/P&gt;</description>
      <pubDate>Fri, 03 Oct 2014 21:08:07 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Why-deployment-server-sees-Linux-UX-univeral-forwarder-as-the/m-p/151288#M30786</guid>
      <dc:creator>t9445</dc:creator>
      <dc:date>2014-10-03T21:08:07Z</dc:date>
    </item>
    <item>
      <title>Re: Why deployment server sees Linux UX univeral forwarder as the GUID even with a set ServerName?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Why-deployment-server-sees-Linux-UX-univeral-forwarder-as-the/m-p/151289#M30787</link>
      <description>&lt;P&gt;(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 &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt; -- to use hostname instead of clientName (DOH!).&lt;/P&gt;</description>
      <pubDate>Mon, 03 Nov 2014 14:07:39 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Why-deployment-server-sees-Linux-UX-univeral-forwarder-as-the/m-p/151289#M30787</guid>
      <dc:creator>t9445</dc:creator>
      <dc:date>2014-11-03T14:07:39Z</dc:date>
    </item>
  </channel>
</rss>

