Because LDAP implementations are so unique and flexible, there is no single configuration that will work for everyone. You should refer to the documentation and go through it step-by-step to set it up: http://www.splunk.com/base/Documentation/4.1/Admin/SetupuserauthenticationwithLDAP The authentication.conf.example page also provides 3 examples of canned LDAP configuration for AD, Sun/iPlanet and Openldap servers: http://www.splunk.com/base/Documentation/4.1/Admin/authenticationconf If you still need assistance after you've made an honest effort to get it working then feel free to file a support ticket. ... View more

The capability was added in 4.0.10 (forwarders) to forward on the license.version file. As a workaround for pre-4.0.10 forwarders, you can configure the following input on your forwarder's inputs.conf: [monitor://$SPLUNK_HOME/etc/splunk.version] index = _internal host=myLWF1 sourcetype=splunk_version _TCP_ROUTING = * This will forward the splunk.version file to your indexer. You can then easily figure out what version each forwarder host is running by searching on the LWF hostname and sourcetype=splunk_version. ... View more

Here's how I would do it: searchterms | eval idxtime=_indextime | convert ctime(idxtime) The added step of converting using ctime changes the epochtime (of _indextime) to human readable ascii time, like "03/31/2010 20:30:00". ... View more

For clarification, this is applies to Lightweight Forwarder. The default expected behavior (LWF forwards its internal logs as default) is not working in version 4.0.x. The workaround is to create a monitor input for the Splunk logs directory and whitelist specific files in the $SPLUNK_HOME/etc/apps/SplunkLightForwarder/local/inputs.conf: [monitor://$SPLUNK_HOME/var/log/splunk] _TCP_ROUTING = * _whitelist = (splunkd|metrics|license_audit)\.log$ Note: This is working without additional configuration in version 4.1. ... View more

If you have access to the filesystem, you can try forcing Splunk to rebuild the data files. There are 2 ways to do this: 1) Delete the the *.data files in $SPLUNK_HOME/var/lib/splunk/defaultdb/db/ (there should exist Hosts.data, Sources.data and SourceTypes.data files) and then Restart your Splunk instance. 2) cd to $SPLUNK_HOME/var/lib/splunk/defaultdb/db/ and 'touch meta.dirty'. Splunk should rebuild the *.data files within a few seconds. This method does not require a restart. ... View more

By default, AD imposes a sizelimit of 1000 entries. This is the max number of entries that can be returned in a single bind request. There is no way to modify this (outside of AD) so we must use userBaseFilters and/or groupBaseFilters to reduce the number of entries returned. A separate call is made on userBaseDN and groupBaseDN so the max is really 1000 user entries and 1000 group entries PER DN. If you specify multiple DNs in your configuration, multiple calls are made to AD, each which allows the max sizelimit. A workaround? Try using a more specific BaseDN. For example, instead of dc=SplunkSupport,dc=Com, use a combination of : ou=People,ou=USA,dc=SplunkSupport,dc=Com;ou=People,ou=Canada,dc=SplunkSupport,dc=Com; Use LDAP filters. See this blog post for examples of LDAP filters used to further reduce the number of entries returned. Use the AD GC port. ... View more

It is unlikely that Splunk is at fault for a kernel panic. Even though a kernel panic may be triggered by a Splunk installation and/or the error points to splunkd, the kernel panic is an indication of a bug in the kernel, not a bug in the installation software. You can take the information from the error to investigate. For example, from the above, I performed the following search using Google.com: kernel panic 2.6.9-788.Elsmp The first url returned is the following RedHat article regarding a sys_times bug in the kernel "Bug 456993 - kernel panic with kernel version 2.6.9-78.ELsmp" https://bugzilla.redhat.com/show_bug.cgi?id=456993 ... View more