/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
10
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
366
367 [transforms/approved_software_servers]
368 access = read : [ * ], write : [ admin, power ]
Any help would be appreciated in silencing these.
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:
= ======
and <<<<<<< HEAD
should do the trick for you).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!
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.
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,
AP
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.
Thanks!
AP