Clobbering of the Nav menu is clearly a significant bug and will be fixed. As you noted, the short-term fix is to go in and re-scope it manually. People who have customized their default nav menu in search or elsewhere typically won't be affected, which is probably why it wasn't noticed sooner. Much of the global exporting is quite intentional. We have users who want access to OSSEC information through the search app. That includes saved searches, views, lookups, and search commands (i.e., most of the app). Regardless, the scoping is something that has been on the radar to tighten down, or possibly provided as an install-time option. It's a significant enough change that it won't be done before th a 1.2 release of the app, which will hopefully come reasonably soon. Setting the Nav menu aside, as you noted, there are a few cases where this sort of thing crops up elsewhere, particularly for saved searches and views. Any app that needs to share elements outside itself has this problem, and is going to pollute other app menus. For now, the safest approach is for any app other than search to be very specific when defining its own nav.xml. I've been meaning to file an ER to ask for a way to scope across multiple apps without resorting to global. Perhaps you and any others who've been bitten by this could make a similar request? ... View more

Yes. For search-time, use: MV_ADD = True ... View more

There isn't a CLI argument to do that. You would likely be better served by going through the REST API if possible. When you run a splunk CLI search, it will look in ~/.splunk for an existing authToken, and prompts you for credentials if a valid authToken is not found. Typically that file is written when you run splunk login . There's nothing to prevent you from writing that file out yourself before calling the CLI, but give careful consideration to the implications of doing so. First, any user who could read that directory could use those credentials (which is already true). Second, if you also run CLI commands directly as root (or splunk's service account), either the interactive user or the scripted input could get the wrong credentials. If you absolutely must call CLI commands directly, there's a workaround. Use mktemp to create a temporary directory, and make sure the permissions are restricted. Write the authToken to $TMPDIR/.splunk/authToken_<hostname>_<portnum> . Then, set the $HOME environment variable to your $TMPDIR before calling the CLI command(s). Once you're done, delete the authToken and the temporary directory. ... View more

It should not, provided you leave the sourcetype alone. See this question: http://splunk-base.splunk.com/answers/8015/how-does-splunk-determine-data-is-being-summarized-and-thus-not-counted-towards-license-usage ... View more

It isn't 100% clear what you're trying to do, but it sounds like you may want to add span=1h to your chart command... Have you looked at this page? http://www.splunk.com/base/Documentation/latest/SearchReference/Chart ... View more

Here are a couple of possibilities, depending on what the rest of your data looks like... Assuming the possibility of other multi-value fields, then you can extract the full recipient list into an intermediate field. Once you have that, split it into the individual recipients. transforms.conf: [mailsec-recipient-list] # Match starting with option 21, and keep # going until we hit another option or the end REGEX = ,21=(.*?)(,\d+=)|$ FORMAT = recipient_list::$1 [mailsec-recipient] # Split each recipient out from the full list SOURCE_KEY = recipient_list MV_ADD = True REGEX = ([^,\\]+) FORMAT = recipient::$1 In props.conf: [mailsec] # Order matters; make sure that the full list # gets extracted first... REPORT-0-mailsec = mailsec-recipient-list REPORT-1-mailsec = mailsec-recipient If this is the only multi-value field, and there are no other cases where you have a comma followed by a space, then you can just look for option 21 or a space after the comma: transforms.conf: [mailsec-recipient] REGEX = ,(\s+|(21=))([^,]+) FORMAT = recipient::$3 MV_ADD = True props.conf: [mailsec] REPORT-mailsec = mailsec-recipient ... View more