All Apps and Add-ons

CIS Critical Security Controls: How to troubleshoot these parsing errors in splunkd.log referencing default.meta?

/opt/splunk/etc/apps/cis-controls-app-for-splunk/metadata/default.meta, line 11: Error parsing setting: = ======  

/opt/splunk/etc/apps/cis-controls-app-for-splunk/metadata/default.meta, line 154: Cannot parse into key-value pair: <<<<<<< HEAD  
/opt/splunk/etc/apps/cis-controls-app-for-splunk/metadata/default.meta, line 366: Cannot parse into key-value pair: <<<<<<< HEAD

Context around line 11:

# Application-level permissions
  11 []
  12 access = read : [ * ], write : [ admin, power ]

Context around line 154:

 152 [savedsearches/summary%20-%20failed%20remote%20login%20src%20timechart]
 153 access = read : [ * ], write : [ admin, power ]
 154 export = none
 155 owner = admin
 156 version = 6.3.1
 157 modtime = 1451973404.805570000

and line 366:

 360 [savedsearches/Failed%20Logins%20Over%20Time%20-%20Privileged%20Accounts%20     %28Accelerated%29]
 361 access = read : [ * ], write : [ admin, power ]
 362 export = none
 363 owner = admin
 364 version = 6.3.1
 365 modtime = 1451971864.141449000
 367 [transforms/approved_software_servers]
 368 access = read : [ * ], write : [ admin, power ]

Any help would be appreciated in silencing these.

0 Karma

Splunk Employee
Splunk Employee

Hi @banderson7,

CIS app developer here -- Thanks for the outreach on this.

Where are you seeing these errors? index=_internal?

Looking at the snips you've attached, it looks like these are vestigial tags from merging files into the github repository during development.

Regarding your question on silencing these:
Assuming the errors you're referencing are showing up in index=_internal, you have a couple of options:

  1. Ignore the error messages now that you know why they're there
  2. Directly edit the default.meta file to remove these tags yourself (looking at the above errors, a simple "find and delete" for = ====== and <<<<<<< HEAD should do the trick for you).
  3. Wait for the next app uprev - Thanks to your question here, I've added an issue to the next development iteration to remove these extraneous tags (thanks for the heads-up)!

Most importantly, I wanted to make sure that the messages you've referenced above aren't affecting the functionality of the app. Please reply back here as appropriate and remember to "accept answer" if you don't have any follow-up questions.

Thanks again for the outreach!

0 Karma


Yep, they're showing in index=_internal, in splunkd.log.

Those characters aren't actually in the file on the deployment server, but they are on the search heads:

splunk@atlitpspdl1:~> grep HEAD /opt/splunk/etc/shcluster/apps/cis-controls-app-for-splunk/metadata/default.meta
splunk@atlitpspdl1:~> grep === /opt/splunk/etc/shcluster/apps/cis-controls-app-for-splunk/metadata/default.meta

splunk@atlitpspsh1:~> grep ==== /opt/splunk/etc/apps/cis-controls-app-for-splunk/metadata/default.meta
= ======

Why do you think that is? The files got onto the search heads via the deployment server, so I'm quite confused.

0 Karma

Splunk Employee
Splunk Employee

Hey again @banderson7,

Thanks for the additional details.

I just took a look at the 1.1.0 build on my dev server and am seeing these in $AppHome/metadata/local.meta versus $AppHome/metadata/default.meta. As a quick test, see if you can grep out the HEAD and = ====== from local.meta on your deployment server. If these tags are there, you can move local.meta from the deployment server into a temporary directory (e.g., /tmp/) then reload the Deployment Server ($SPLUNK_HOME/bin/splunk reload deploy-server) to push the update.

Off the top of my head, I'm not entirely sure why local.meta on the Deployment Server would end up in default.meta on the Search Heads in your Search Head Cluster (SHC), but "local" has file precedence over "default," so that's likely in the mix here...

As a last step/test after redeploying from the Deployment Server, try to grep out the tags from $AppHome/metadata/default.meta on a SH in your SHC to confirm that they were successfully replaced with the correct $AppHome/metadata/default.meta from the Deployment Server. Alternatively, check splunkd.log for evidence of the tags *after issuing the $SPLUNK_HOME/bin/splunk reload deploy-server

Looking forward to hearing your results,

0 Karma

Splunk Employee
Splunk Employee

Hi @banderson7,

Just checking back in with you on this.

Please take a moment to upvote the answer if you don't have any follow-up questions.


0 Karma
Get Updates on the Splunk Community!

.conf24 | Day 0

Hello Splunk Community! My name is Chris, and I'm based in Canberra, Australia's capital, and I travelled for ...

Enhance Security Visibility with Splunk Enterprise Security 7.1 through Threat ...

 (view in My Videos)Struggling with alert fatigue, lack of context, and prioritization around security ...

Troubleshooting the OpenTelemetry Collector

  In this tech talk, you’ll learn how to troubleshoot the OpenTelemetry collector - from checking the ...