Why are only some indexes listed in the available indexes pane under roles?

[lycollicott]

Only a fraction of our indexes are listed as available and there is nothing listed under selected. For example:

The index definitely exists and I can search it, so why is it missing on the Roles screen?

[rchudzinski]

The problem still exists in 7.2. I encountered it with the recent upgrade . The cause is as loatswil describes. The searchheads don't see the indexes on the index cluster when populating the UI.

The workaround given by support is to create 'dummie' indexes with the same names as the missing ones on the searchhead. This will populate the list.

Not very elegant but that is a workaround until they patch it.

[lycollicott]

It's resolved in 7.2.1

[lycollicott · Accepted solution]

This is a bug in 7.0.

Support gave me a workaround by editing etc/apps/search/default/data/ui/manager/authentication_roles.xml.

Here is the revised file, but you should always check with support before dropping in xml from strange Splunkers on the internet. Remember that.

link text

[lycollicott]

UPDATE:
This bug was resolved in 7.2.1

[cboillot]

Does this have to go into the default directory? Or will with work in the local directory?

[lycollicott]

@cboillot id had to be in default.

This was resolved in version 7.2.1.

[cboillot]

Thanks.

It's going to be a few months, if not near the end of the year, before we can upgrade.

[elewis1]

That fix is extremely inefficient for large sites. The 7.0 call to data/indexes appears to specify "splunk_server=local". Adding the stanza Support provided with a |rest call without the "local" works quickly.

<key name="keyName">entry.properties.get('index', 'index key not found')</key>
 <key name="keyValue">entry.properties.get('index', 'index key not found')</key>
 <key name="splunkSource">/search/jobs/oneshot</key>
 <key name="splunkSourceParams" type="dict">
   <key name="output_mode">"atom"</key>
   <key name="count">"1000"</key>
   <key name="search">"|rest /services/data/indexes |stats values(title) as index |mvexpand index"</key>
   </key>

[somesoni2]

When you search, you can see all the indexes that are available in your Indexers (which have data of course). But, on search heads, in the Splunk setting pages such as Access Control pages (edit/add users or roles), dropdown where summary indexing is enabled and data input pages, you'd only see indexes that are available on Search heads (indexes.conf available on Search heads). This is the reason you wouldn't see other indexes which are only available on Indexers. The right panel may be empty as the selected indexes for that role doesn't exist on SH.

You can see the indexes available on SH by using following:

REST query from search:

| rest splunk_server=local /services/data/indexes | table title splunk_server

Btool command on Search Head server:

 $Splunk_Home/bin/splunk btool indexes list --debug | grep "\["

[lycollicott]

We have always assigned indexes to roles in this fashion, so I'm afraid I have to disagree with the caveat that we recently upgraded to 7.0. Perhaps that version is the reason we are seeing different behavior now.

[somesoni2]

Wasn't aware of the upgrade. Could be a bug, but did you verify that above search/command gives you all the indexes?

[lycollicott]

Those commands just list local definitions on the SH and that is indeed a match to the pane.

[HeinzWaescher]

Same problem here, we are on 7.0.0 as well.
The search mentioned by somesoni2 does not show all available indexed on my SH as well. But I can search more indexes shown in the search result & in roles.

[loatswil]

Same results here. Rolling out a 7.0 SH that only sees a few of the available indexes (in Roles and using the REST call). On the 6.4.2 SH, ALL indexes show in the Roles pane but not in the REST call. The missing indexes are defined on the Indexers only. They show up in the Roles panel on 6.4.2 but NOT on 7.0.

[lycollicott]

@loatswil @HeinzWaescher

Did you try the solution support gave me?

[loatswil]

Not yet, I was waiting to check with support, as you'd suggested 😉