Hi, got a wierd case here.
I tried to install 4.6.0 of Splunk CIM (https://splunkbase.splunk.com/app/1621/), and while the install goes fine, tclicking "Set Up" doe snot so much.
I only get a page saying
I am Legend
setup_stub
I bit wierd. I haven't really had time to dig into the app itself to see what is going on, but maybe someone else has seen this?
This is the part of the page source:
<div class="fieldsetWrapper " id="item-blockFieldset-0">
<fieldset id="">
<legend>I am Legend</legend>
<div id="item-textNode-0-0" class="standaloneHelp " >
<p class="helpText">setup_stub</p>
</div>
</fieldset>
</div>
But the question is why 🙂
CIM 4.6.0 is only supported on Splunk platform 6.4.X or later. If you use it on an earlier version, the setup page will not work.
This is on Splunk Enterprise 6.4.3, so that should not be the problem.
Works for me fine.
What version of Splunk Enterprise are you using?
http://localhost:8000/en-US/app/Splunk_SA_CIM/cim_setup?action=edit
I think you are looking at a bit of the undercovers.
root@splunk_docker:/opt/splunk/etc/apps/Splunk_SA_CIM# find . -type f | xargs grep "I am Legend"
Splunk Enterprise 6.4.3
An it does not look like this text is part of the CIM app:
[splunk@search1 Splunk_SA_CIM]$ find . -type f | xargs grep "Legend"
[splunk@search1 Splunk_SA_CIM]$
Also, the only place I've found the whole string (in text files) is in $SPLUNK_HOME/lib/python2.7/site-packages/splunk/appserver/mrsparkle/controllers/admin.py:
[splunk@search1 lib]$ find . -type f | xargs grep "I am Legend"
./python2.7/site-packages/splunk/appserver/mrsparkle/controllers/admin.py: "legend" : block.get("title", "I am Legend"),
It's actually part of this definition:
def generateUIHelperFromEntity(self, entity, namespace='search'):
uiHelper = {}
uiHelper["header"] = "%s setup" % namespace
uiHelper["elements"] = []
hasInputElements = False
setupXml = entity.get("eai:setup", None)
# logger.debug(setupXml)
import xml.etree.cElementTree as et
root = et.fromstring(setupXml)
block_nodes = root.findall('block')
i = 0
for block in block_nodes:
# Refer to JIRA STEWIE-531 for the all details regarding this change !!
# code below allows apps to have setup.xml to define a custom setup UI, example of setup.xml below:
# <setup><block task="mycustomsetupui" type="redirect"/></setup>
# Pickup the custom partial URL from task attribute of block and redirect to custom setup ui
# <locale>/app/<app-name>/<value of task attribute>?redirect_to_custom_setup=1
# Look in view.py for consumption of redirect_to_custom_setup query param, which is used to bypass
# the setup dialog !!
if 'task' in block.attrib and 'type' in block.attrib and block.attrib['type'] == 'redirect':
redirect_to = '/app/%s/%s' % (namespace, block.attrib['task'])
logger.info("Redirecting to custom setup for app=%s url=%s" % (namespace, redirect_to))
self.redirect_to_url(redirect_to, _qs={"redirect_to_custom_setup":"1"})
return
fieldsetElement = {
"elementName" : "blockFieldset-%s" % i,
"showInView" : [ "edit" ],
"type" : "fieldset",
"legend" : block.get("title", "I am Legend"),
"elements" : []
}
j = 0
for node in block:
# go through everything in the block and add to this fieldset
logger.debug(node.tag)
if node.tag == "text":
# for <text> nodes, put them into a type: helpstring
element = {
"elementName" : "textNode-%s-%s" % (i, j),
"type" : "helpstring",
"helpText" : node.text,
"showInView" : [ "edit" ]
}
fieldsetElement["elements"].append(element)
elif node.tag == "input":
# for <input> nodes, put them into the appropriate type per the input
type = node.find("type").text
if type == "bool":
elementType = "checkbox"
elif type == 'password':
elementType = "password"
else:
elementType = "textfield"
elementLabel = node.find("label").text
element = {
"elementName" : node.get("id"),
"type" : elementType,
"label" : elementLabel,
"showInView" : [ "edit" ]
}
fieldsetElement["elements"].append(element)
hasInputElements = True
j = j + 1
uiHelper["elements"].append(fieldsetElement)
i = i + 1
if not hasInputElements:
uiHelper["_noInputElements"] = True
return uiHelper
Thanks, @hcpr. I've never heard of it coming up on more recent versions of the platform before, so this is very helpful to know. Filing a bug.
I am seein the same issue on 6.4.3 and 4.6 version of the cim.
We have the same issue with CIM 4.6 and 4.7 we are having the issue on 6.4.3 of Splunk as well.
Since upgrading Splunk to 6.5 this problem has gone away for me.
Not the quick and easy fix, but we were planning to upgrade anyway.