If you use an installer (as opposed to expanding a tarball) then the user was created for you and all files were given to that user. To be able to read local files, check out this document: https://docs.splunk.com/Documentation/Forwarder/9.1.2/Forwarder/Installleastprivileged . It's written for forwarders, but may work for Splunk Enterprise, as well.  If it doesn't work then you'll need to change file permissions or add user 'splunk' to a group that has read access to the file(s).

You might check out https://splunkbase.splunk.com/app/2949 "Meta Woot!". It's not nearly as robust or customizable compared to TrackMe, but it appears to be a simpler alternative that shows latency and lag. 

The process for upgrading standalone and distributed Splunk installation is the same.  For distributed environments, there is a prescribed upgrade order.  See https://docs.splunk.com/Documentation/Splunk/9.1.2/Installation/HowtoupgradeSplunk and https://docs.splunk.com/Documentation/Splunk/9.1.2/Installation/UpgradeyourdistributedSplunkEnterpriseenvironment

This is an area where I feel Splunk is severely lacking. It would be great if there was a mechanism for sharing one password with a group of users without having to give out list_storage_passwords, then retroactively update all of our apps to limit access. We have custom SPL commands that require passwords to be entered on a setup screen. We cannot give everyone list_storage_passwords, so the ability to use these commands is limited to our admins. Edit: Just saw the ideas links. Added my Vote.

@richgalloway , I'm aiming to upgrade my Splunk Enterprise on the deployment server, but I'm uncertain whether it's configured as standalone or distributed. How can we verify this and proceed with the upgrade accordingly? Additionally, does the upgrade process differ between standalone and distributed setups?

I'm not sure you'd be able to prevent the user from having the ability to view the secret at *all*, but you can get more granular than just all-or-nothing with `list_storage_passwords`. I just answered a similar question here with some details that might help you out: https://community.splunk.com/t5/Splunk-Dev/What-are-secret-storage-permissions-requirements/m-p/670685/highlight/true#M11281

My understanding is that credentials created by POST request to the `storage/passwords` endpoint end up encrypted in `passwords.conf`, where they are treated like any other knowledge object. By default they will be accessible to any user with the `admin_all_objects` or `list_storage_passwords` capabilities, but you should be able to perform more granular access control via `metadata/local.meta` like with any other knowledge object in Splunk. This would allow admins to lock down access to specific credentials with more specificity (or, if you're building this app yourself, you could use the app's setup page where configuration is performed to complete this additional step).  I believe that this app includes functionality for managing permissions on existing secrets as described above: REST storage/passwords Manager for Splunk

Nothing will happen.  Splunk will run just fine when installed as root.  Doing so, however, is not a good security practice.  Everything Splunk does will be as root - including any unknown vulnerabilities.  User scripts will run as root, which means they have the potential to cause great harm to the system. Install Splunk as a normal user.  User "splunk" is common.  If it's necessary to install using root (when using rpm files, for instance), then use the chown command to give ownership to 'splunk' afterwards.

I see,  should I copy and paste the event data into the search bar to do as the example you provided? Edit: I used: index="my_index" "log_id_here" logid responseMessage | spath input=data | transpose Strangely most if not all vital data was stored inside _raw as a single str

Hi @cplunk - the support email address for Splunkbase-related enquiries is: splunkbase-admin@splunk.com  The display name for your app is tied to whichever Splunk.com user account is the "owner" of the app listing.  I think your options for changing this are either:  create a new Splunk.com account to own your app listing and ask splunkbase-admin@splunk.com to transfer ownership update the information on your Splunk.com account (which might require contacting Splunk Support?) 

Hi @nithesh - since your original post, we've released updates to the Splunk AppInspect API that refined the behavior of this check. If you are still having issues, please reach out to appinspect@splunk.com and we'll help investigate. 

Hi @Shohel.Tamboli, I'm still working with the Docs team to see if we can get some revisions made. In the meantime, have you found a solution or anything else you can share? If you're still seeking help, you can also try contacting Support. How do I submit a Support ticket? An FAQ 

I find it interesting that you claim the spath command does not work yet none of your searches use spath.  The command won't work if it isn't invoked.  See my example above. Once the spath command has extracted the fields, then you can reference those fields in other commands.

You may find our documentation on custom search commands helpful: https://dev.splunk.com/enterprise/docs/devtools/customsearchcommands/ This topic includes some useful information on building different types of custom search commands as well as links to examples.