Give this a try your current search giving columns host col1 col2 col3 col4 | untable host column val | stats count by column val | eval col=val."-".count | eval temp=1 | chart values(col) over temp by column | fields - temp ... View more

This was a known issue (SPL-41061) reported under 4.2.1 and 4.2.2 It is targeted to be fixed in the next maintenance release. ... View more

This has been reported to support and is a known issue in 4.1.4 +. See the following: splunk.com/base/Documentation/4.1.4/ReleaseNotes You may be able to workaround this by creating a whitelist that excludes explicitly the files you'd normally blacklist. ... View more

We just left the data in the index and for future tests where we will be deleting data on a regular basis have created a 'test' index. With the test index we can run "./splunk clean eventdata test" that will clean that index completely so we can re-test an import. Having to do a csv export/import is more effort than we wanted to do. I am still not sure why splunk has issues causing errors when deleting (hiding) some data from an index with the | delete. ... View more

UPDATE: this was implemented as of Splunk 4.3. Please see: http://blogs.splunk.com/2012/01/10/splunk4-3-shiny-new-security-features/ Old answer: We are considering implementing the option for a non-persistent cookie, which means that it would go away when the browser closes. However, if a user never closes their browser, they would not be subject to the 24 hour expiration that our current cookie content expiration provides. Either way, this is largely mitigated by server-side UI activity and session timeouts, which you can set to as low as 5 minutes. These settings can be found in the server-side settings can be set in $SPLUNK_HOME/etc/system/local/web.conf: ui_inactivity_timeout = <integer> * Specifies the length of time lapsed (in minutes) for notification when there is no user interface clicking, mouseover, scrolling or resizing. * Notifies client side pollers to stop, resulting in sessions expiring at the tools.sessions.timeout value. * If less than 1, results in no timeout notification ever being triggered (Sessions will stay alive for as long as the browser is open). * Defaults to 60 minutes tools.sessions.timeout = <integer> * Specifies the number of minutes of inactivity before a user session is expired * The countdown is effectively reset by browser activity minute until ui_inactivity_timeout inactivity timeout is reached. * Use a value of 2 or higher, as a value of 1 will race with the browser refresh, producing unpredictable behavior. (Low values aren't very useful though except for testing.) * Defaults to 60 Here is an example configuration that would produce sessions that timeout after 5 minutes of inactivity: [settings] ui_inactivity_timeout = 2 tools.sessions.timeout = 3 ... View more

There is not. This is kind a failsafe in case SSO is not configured correctly. The right way to ensure this is to configure SiteMinder (I'm assuming from SM-USER ) to only allow the same set of users as you configure for Splunk to access the Splunk/Apache resource. I don't know if SM has a way to force a session or browser cookies to be cleared when you auth with a new user. Perhaps it doesn't by default clear the CherryPy cookie, which is called session_id_<port> , e.g. session_id_8000 . This is kind of a general problem with SSO and web applications, so I would expect it to be the case that the proxy would intercept and clear those when switching users. This is a good Enhancement Request for Splunk that you should file. In the meantime, you would have to edit $SPLUNK_HOME/share/splunk/search_mrsparkle/modules/nav/AccountBar.html. Unfortunately any change you make to this will probably be overwritten with every patch or upgrade of Splunk, but hopefully the change should be pretty minor. The HTTP header name REMOTE_USER should refer to the name of the header that contains the trusted/authenticated user ID. By default, SiteMinder puts this id into the header SM-USER , but other SSO systems use a different header name. ... View more

Yes you can. If using a self-signed certificate, it is insufficient to just install and configure the server certificate on the server. You must also install and configure the public key of CA who signed the server certificate on each client that is to connect to that server. I am not certain, but I believe that you can. The communications between forwarders and indexers can be configured not to check hostnames anyway, so whether the certificate is wildcarded or not may not matter. Simple possession of a certificate signed by the configured CA may be sufficient. ... View more