Dashboards & Visualizations

Search Head Cluster: How to delete private pre-cluster dashboards?

gsumner
Explorer

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. /etc/shcluster/apps/search/local/data/ui/views/).

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?

0 Karma

esix_splunk
Splunk Employee
Splunk Employee

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.

User configurations

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 @ :
http://docs.splunk.com/Documentation/Splunk/6.3.1/DistSearch/PropagateSHCconfigurationchanges

0 Karma

gsumner
Explorer

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.

0 Karma
Get Updates on the Splunk Community!

Cloud Platform & Enterprise: Classic Dashboard Export Feature Deprecation

As of Splunk Cloud Platform 9.3.2408 and Splunk Enterprise 9.4, classic dashboard export features are now ...

Explore the Latest Educational Offerings from Splunk (November Releases)

At Splunk Education, we are committed to providing a robust learning experience for all users, regardless of ...

New This Month in Splunk Observability Cloud - Metrics Usage Analytics, Enhanced K8s ...

The latest enhancements across the Splunk Observability portfolio deliver greater flexibility, better data and ...