https://community.splunk.com/t5/Deployment-Architecture/Serverclass-conf-Using-the-same-app-name-under-different-classes/m-p/172929#M6471 <P>I've been trying to upgrade our Splunk v5.0.4 deployment server to v6.0.</P> <P>It appears that our existing serverclass is now broken under v6.0</P> <P>The situation is that we have a few base configurations that are pushed out to all clients and are based on their client type. forwarders, indexers, search heads, job servers and so on. These contain such things as where the deployment server is. Where to forward internal logs (very useful for sos) etc.</P> <P>We used a naming standard in which they were all called the same name. ie. "sys_conf".<BR /> They used the respositoryLocation parameter per class definition (which is a still supported configuration according to current v6.0 documentation - <A href="http://docs.splunk.com/Documentation/Splunk/6.0/Admin/Serverclassconf#serverclass.conf.example" target="_blank">http://docs.splunk.com/Documentation/Splunk/6.0/Admin/Serverclassconf#serverclass.conf.example</A> ).</P> <P>So an example config.</P> <P>INDEXERS - ONLY indexers should get this app.<BR /> [serverClass:sys_indexer]<BR /> filterType= blacklist<BR /> blacklist.0=*<BR /> whitelist.0=idx<BR /> restartSplunkd = true<BR /> repositoryLocation = $SPLUNK_HOME/etc/deployment-apps/sys_config/indexer/<BR /> [serverClass:sys_indexer:app:sys_conf]</P> <P>FORWARDERS - ONLY forwarders should get this app.<BR /> [serverClass:sys_forwarder]<BR /> filterType= blacklist<BR /> blacklist.0=*<BR /> whitelist.0=fwder<BR /> restartSplunkd = true<BR /> repositoryLocation = $SPLUNK_HOME/etc/deployment-apps/sys_config/forwarder/<BR /> [serverClass:sys_forwarder:app:sys_conf]</P> <P>Each unique repository location contains a "sys_conf" system app containing unique base configurations for that platform type.</P> <P>In each clients deploymentclient.conf they have their clientName set to "idx" or "fwder". Checking splunkd.log shows they the correct endpoint is called.</P> <P>However on the deployment server if we check /opt/splunk/var/run/tmp/ we will find all bundles for sys_conf.xxxxx will be identical and will only contain the contents of the very first defined repository location for a that unique app name.</P> <P>A splunk btool serverclass list output shows the correct order of black listing and classes.</P> <P>The issue I have is that its not just for base splunk configurations we have this for but right across various apps and TA's also!</P> <P>I can verify this behaviour by picking a previously broken base app and calling the app something unique.</P> <P>Has this functionality of being able to use the same app name in different classes and repository locations changed in v6.0?</P> Mon, 28 Sep 2020 15:27:10 GMT Lucas_K 2020-09-28T15:27:10Z https://community.splunk.com/t5/Deployment-Architecture/Serverclass-conf-Using-the-same-app-name-under-different-classes/m-p/172929#M6471 <P>I've been trying to upgrade our Splunk v5.0.4 deployment server to v6.0.</P> <P>It appears that our existing serverclass is now broken under v6.0</P> <P>The situation is that we have a few base configurations that are pushed out to all clients and are based on their client type. forwarders, indexers, search heads, job servers and so on. These contain such things as where the deployment server is. Where to forward internal logs (very useful for sos) etc.</P> <P>We used a naming standard in which they were all called the same name. ie. "sys_conf".<BR /> They used the respositoryLocation parameter per class definition (which is a still supported configuration according to current v6.0 documentation - <A href="http://docs.splunk.com/Documentation/Splunk/6.0/Admin/Serverclassconf#serverclass.conf.example" target="_blank">http://docs.splunk.com/Documentation/Splunk/6.0/Admin/Serverclassconf#serverclass.conf.example</A> ).</P> <P>So an example config.</P> <P>INDEXERS - ONLY indexers should get this app.<BR /> [serverClass:sys_indexer]<BR /> filterType= blacklist<BR /> blacklist.0=*<BR /> whitelist.0=idx<BR /> restartSplunkd = true<BR /> repositoryLocation = $SPLUNK_HOME/etc/deployment-apps/sys_config/indexer/<BR /> [serverClass:sys_indexer:app:sys_conf]</P> <P>FORWARDERS - ONLY forwarders should get this app.<BR /> [serverClass:sys_forwarder]<BR /> filterType= blacklist<BR /> blacklist.0=*<BR /> whitelist.0=fwder<BR /> restartSplunkd = true<BR /> repositoryLocation = $SPLUNK_HOME/etc/deployment-apps/sys_config/forwarder/<BR /> [serverClass:sys_forwarder:app:sys_conf]</P> <P>Each unique repository location contains a "sys_conf" system app containing unique base configurations for that platform type.</P> <P>In each clients deploymentclient.conf they have their clientName set to "idx" or "fwder". Checking splunkd.log shows they the correct endpoint is called.</P> <P>However on the deployment server if we check /opt/splunk/var/run/tmp/ we will find all bundles for sys_conf.xxxxx will be identical and will only contain the contents of the very first defined repository location for a that unique app name.</P> <P>A splunk btool serverclass list output shows the correct order of black listing and classes.</P> <P>The issue I have is that its not just for base splunk configurations we have this for but right across various apps and TA's also!</P> <P>I can verify this behaviour by picking a previously broken base app and calling the app something unique.</P> <P>Has this functionality of being able to use the same app name in different classes and repository locations changed in v6.0?</P> Mon, 28 Sep 2020 15:27:10 GMT https://community.splunk.com/t5/Deployment-Architecture/Serverclass-conf-Using-the-same-app-name-under-different-classes/m-p/172929#M6471 Lucas_K 2020-09-28T15:27:10Z https://community.splunk.com/t5/Deployment-Architecture/Serverclass-conf-Using-the-same-app-name-under-different-classes/m-p/172930#M6472 <P>Support confirms this as a reproducible v6.0 issue so I will just have to wait on a fix.</P> Fri, 13 Dec 2013 04:08:58 GMT https://community.splunk.com/t5/Deployment-Architecture/Serverclass-conf-Using-the-same-app-name-under-different-classes/m-p/172930#M6472 Lucas_K 2013-12-13T04:08:58Z