Is it possible to create a role which can create a scheduled saved search and store result(s) into non-default summary index (another summary index created by admin , said summary_A )?
I tried to do above , I login as admin and create a index called summary_A, and I create a role (said role_A) inherit from power, and he can search summary_A index. then I create a user (said user_A) belongs to role_A .
I login as user_A , write a search and save it as a scheduled saved search, while I click "enable summary indexing" , I can only see "summary" index , I can not see "summary_A" index in dropdown list box ( if I login as admin, then I can see "summary_A" in dropdown list box) , I don't know why.
anyone have idea about this ? thanks.
After doing some more digging, it looks like there your new indexes don't show up because you haven't granted write access to any other roles yet. The "admin" role has access to all indexes by default, which is why the admin user could see all indexes. The index access you were talking about setting up, on pertains to searching on indexes--it has nothing to do with writing to indexes.
To add write access to your
summary_A index, modify your
local.meta file in whatever app you defined your index in. (For example, if summary_A is defined in
$SPLUNK_HOME/etc/system/local/indexes.conf, then put your entry in
[indexes/summary_A] access = read : [ * ], write : [ admin, power ]
This will let both the admin and power users write to this index. There doesn't seem to be any way to do this from the UI. And you'll have to restart, or use some other trickery to get splunk to refresh the metadata.
One thing that confused me when I was digging around is why "summary" index was showing up. This seems to be either because "summary" is the default index, or it's because of some config entry I haven't found yet. I'm not sure.
I'm not sure what restrictions
summaryindex command place on which index a user can write to. I think the controls are at the
summaryindex search command level; in other words, if a user can execute the
summaryindex search command (which is what the
summary_index alert action does behind the scenes), then a user can write to whatever index they choose.
I suspect that the summary_A index missing from drop-down is either (1) because you didn't restart (as ftk suggests), or (2) because that user doesn't have search access to that index. But I don't think that lacking search access really prevent the user from writing to that index. I'm prettys sure the user could still run a search command to do so manually:
... | summaryindex addtime=true index=summary_A name="my_unapproved_summary_index_search
In general, I would only suggest giving trusted users access to the summary indexing capability.
This could be some kind of user interface issue. I would try modifying the
savedsearches.conf file where user_A's saved search was saved. Try adding the following line to the appropriate stanza:
action.summary_index._name = summary_A
Then restart splunk and see if that works for you. This may not be the answer you are looking for, but it should help determine if the issues you're seeing is simply in the UI layer or if it's something within the core of splunk.
Ok, I just did some more digging, and I think I figured out what's really going on here, but I'll post a secondary answer. In the mean time, I think the right workaround is to specify the summary index manually in the