After having upgraded Splunk from 6.5.2 to 6.6, I have now the task to upgrade all the apps and addons on unclustered Indexers and forwarders which are being managed by a deployment server.
I noticed there are a number of apps in the deployment-apps folder that were downloaded from Splunkbase, however, folder name changed to something like abc_prod_cisco_esa_idx, x.x.x_hf, x.x.x_uf and so on.
Should I just download latest version of the app, unarchive it, rename the app to match with the custom app folder name and overwrite the older version of the app in deployment-apps folder ?
The main drawback of this method is its significant overhead of doing this for 30-40 apps.
Hence, I was wondering if anybody can please share a better efficient and particularly a safer way to upgrade the addons without losing any custom configuration if there is any.
IMO, you don't have any choice. This is the danger of customizing a splunkbase app (other than changes to local .conf files).
Unless there are corporate requirements to use that name scheme, you may want to take opportunity to revert to the original names to save yourself time and effort in the future.
/local on a forwarder means that forwarder is no longer in sync with the deployment server. It means a rogue system admin might make changes the Splunk admin cannot override. For that reason, apps downloaded from the DS overwrite
/local. This is different behavior from normal app installation/upgrade. See https://docs.splunk.com/Documentation/Splunk/8.0.1/Updating/Excludecontent
While overwriting, what files can get overwritten ?
I am sure, local folder doesn't get overwritten but just wondering if there is anything else other than that ?
take opportunity to revert to the original names to save yourself time and effort in the future.
Thats exactly what I have decided to do.
But just to add to that - Apps on splunkbase should not contain files in the local folder, so whilst it will overwrite with the package files, it "should" leave your apps ./local folder unmodified.
If you are concerned - you can open the package first and confirm that the ./local folder is missing (or empty) from the new version before applying it to your environment.