Hello everyone Two parter. First of all, am I correct in assuming that /appname/metadata/local.meta takes precedence over /appname/metadata/local.meta The reason for this question is that while applying changes in a SH cluster from a deployer, changes made to default.meta in an app has no effect and changes in local.meta are retained. Second, what is the best praxis for editing the local.meta file? I think I, at least, need to completely remove the read/write permissions so it falls back on the default.meta file [] access = read : [ ], write : [ ] export = none version = x.x.x.x modtime = tttttttttt.tttttttt Otherwise any future edits made and rolled out will not take effect as there is a local.meta file. Though I was hoping that I could just delete the entire local.meta file? To be clear, the actual question, can I     a) delete the entire local.meta file or do I have to     b) edit out the desired section in the local.meta file? I know I can edit access to alerts/dashboards etc via the GUI though I'd like to edit for everything in the app in one single move from the CLI. All the best // f ... View more

I am fairly confident that there is a clever workaround for this though I am not 100% sure how. I have alerts stored in apps on a deployer which makes use of the email function when triggered. I if I need to add/remove recipients from the email alert I have to manually edit several different recipient lists for several different alerts. What I wan't is a clever way to set up som sort of "list" of recipients which I can name "developers" for instance, and instead of having 20 email adresses as recipients in the alert I could do something like "$devops$". Then just edit recipients at a single location for all alerts instead of each one separately. I hope this is a clear enough explanation for what I am hoping is possible and welcome all suggestions.   ... View more

After upgrading a distributed Splunk Enterprise environment from 9.0.5 to 9.1.1 a lot of issues observed. The most pressing one was the unexpected wiping of all input.conf and output.conf files from heavy forwarders. All configuration files are still present and intact on the deployment server, though after unpacking the updated version and bringing Splunk back up on the heavy forwarders, all input/output files were wiped from all apps and are not being fetched from the deployment server. So none of them were listening for incoming traffic or forwarding to indexers. Based on previous experience, there is no way to "force push" configuration from the deployment server when all instances are "happy", which means manual inspection and repair of all affected apps. So now I am curious as to why this happened? If there was something wrong with the configuration I'd expect there to be some errors thrown and not just having the entire files deleted. Any input regarding why this happend, how to find out would be appreciated. UPDATE: So by now it is very clear what happened, a bunch of default folder were simply deleted afterduring the update, there are a few indications of this in different log files. 11-08-2023 12:21:19.816 +0100 INFO AuditLogger - Audit:[timestamp=11-08-2023 12:21:19.816, user=n/a, action=delete-parent,path="/opt/splunk/etc/apps/<appname>/default/inputs.conf" This was unfortunate as the deploymentclient.conf file was stored in <appname>/default and got erased together with almost all input/output.conf and a bunch of other things stored in the default folder. I don't get the impression that this is expected behaviour, so now I am curious regarding the cause of this highly strange outcome. ... View more

Hello community We installed the CIM app in our SH cluster. The installation seemed to work as expected, all defaults no modifications. Afterwards when trying to launch the app we landed on a "ta_nix_configuration" page, trying to access the "cim_setup" page we got a 404. We removed the app, rolled all members and re-installed. Once again it all seemed to work just fine. This time around we can access the cim_setup page, though if we try to access the "<baseurl>/app/Splunk_SA_CIM/" directly or use the "launch app" link in the GUI we land on the "<baseurl>/app/Splunk_SA_CIM/ta_nix_configuration" site. Is this somehow the expected behaviour or have we got some crossed wires somewhere? ... View more