We moved from a single search head set up to a Search Head cluster running 6.2.1. We are manually doing cleanup on knowledge objects created pre-cluster that can't be deleted or have permissions changed via the UI (a known, annoying bug).
We have had pretty good success deleting these searches from the appropriate /etc/shcluster savedsearches.conf on the deployer and doing a bundle push. I tried to do the same thing with dashboards today, deleting the XML files on the deployer.
This works with dashboards that were under the app context (i.e.
This does not work with dashboards that were under the user context (i.e.
etc/shcluster/users/USERNAME/search/local/data/ui). The file is deleted from the deployer, but remains in the default dir on the search heads.
The docs are not particularly clear on this, it does seem like the deployer logic for pushing out /shcluster/users is different than shcluster/apps. I'm assuming only .conf files under /shcluster/users get updated and deletions don't propagate?
Have others tried this? Any tricks? Am I stuck manually deleting the files on every search head?
The behavior for pushing User knowlegde objects works different then when Apps are pushed.
Basically, User objects wont be deleted from the SHC members. If you copy from deployer to members, and then delete of deployer, the deployer wont delete off the clients.
Apps will however delete everything when deployed.
The deployer copies user configurations to the captain only. The captain then replicates the settings to all the cluster members through its normal method for replicating configurations, as described in "Configuration updates that the cluster replicates."
Unlike app configurations, the user configurations reside in the normal user locations on the cluster members, and are not merged into default directories. They behave just like any runtime settings created by cluster users through Splunk Web.
The deployment of user configurations is of value mainly for migrating settings from a standalone search head or a search head pool to a search head cluster. See "Migrate from a search head pool to a search head cluster."
When you migrate user configurations to an existing search head cluster, the deployer respects stanzas that already exist on the cluster. It does not overwrite any existing stanzas.
Further Reading @ :
Thanks for your answer. However some parts don't really make sense. First of all, your statement that user configs reside on in the normal user location rather than being merged to default is in contrast to the docs, which state:
"All files placed under both default and local subdirectories get merged into default subdirectories on the members, post-deployment. This holds true for both app and user subdirectories"
I'm assuming you are referencing something that is specific to 6.3, as I mentioned we are on 6.2.1.
Also, we have found that changes to savedsearches.conf in the users directories do get updated when pushed out via the deployer.
But pretty much what I'm taking away is that we are SOL and have to make the deletions from the file system on every search head.