About upgrading to 4.1 READ THIS FIRST

About upgrading to 4.1 READ THIS FIRST

This topic is about what you need to know before you upgrade to Splunk 4.1. If you're upgrading from 4.1 to a later version in the 4.1 version range (for example 4.1.1 to 4.1.3), refer to "Upgrade Splunk on Linux, Solaris, FreeBSD, AIX, and MacOS" or "Upgrade Splunk on Windows".

What's new and awesome in 4.1?

Check out Meet Splunk 4.1 in the Release Notes for a full list of the new features we've delivered in 4.1.

Review the Known issues in the Release Notes for a list of issues and workarounds in this release.

Always back up your existing deployment first

Get into the habit of backing up your existing deployment before any upgrade or migration. You can use any standard tool or utility to do this; the easiest way is to compress the entirety of $SPLUNK_HOME and all its subdirectories into a zip or tar file and save it aside.

Upgrading from 4.0 and later

Splunk supports a direct upgrade from versions 4.0 and later to version 4.1. Read the rest of this topic first before proceeding with the following instructions:

• Upgrade to 4.1 on Linux, Solaris, FreeBSD, HP-UX, and MacOS
• Upgrade to 4.1 on Windows

Migrating from 3.4.x and earlier

Migrating directly to 4.1 from versions older than 4.0 is not officially supported. Splunk 4.0 and later are built on a completely new architecture, and migration from 3.4.x to 4.0 is a significant undertaking. Read What to expect when upgrading to 4.0 before proceeding. Depending on the complexity of your deployment, you may want to perform a manual migration.

Once you've migrated from 3.4.x to 4.0, you can then upgrade from 4.0 to 4.1 using the UNIX and Windows instructions in this manual.

3.4.x forwarders work with 4.x indexers

You don't have to upgrade all your forwarders to get the benefit of Splunk 4.x on your indexers and search heads.

Migrating 3.x field actions to 4.1

Automatic migration of field actions from a 3.x installation to workflow actions in your 4.1 installation is not yet supported. A migration script will be provided in an upcoming release. If you have a lot of field actions and can wait for the script, you may want to do so, but don't let that stop you from checking out our new workflow actions in the meantime.

For instructions for creating workflow actions in 4.1, check out Create workflow actions in Splunk Web in the Knowledge Manager Manual

You want to know this stuff

Upgrading to 4.1 from 4.0 and later is pretty simple, but here are a few tips and gotchas:

Inputs are disabled by default in the *Nix and Windows apps

Inputs in the Windows or *Nix apps are disabled by default in 4.1. If you're using inputs that belong to the Windows or *Nix apps that shipped with 4.0.x and want to make sure they stay enabled after the upgrade, copy the inputs.conf file from $SPLUNK_HOME/etc/apps/<Windows_or_*Nix_app>/default and put it in $SPLUNK_HOME/etc/apps/<Windows_or_*Nix_app>/local .

If you have deployed forwarders that use one of these apps, use your deployment server or another method to push out an update to your forwarders that includes the inputs defined in the app's /local directory as described above.

Splunk for PCI app is now supported on 4.1 and later

If your Splunk deployment includes the Splunk for PCI app (Splunk PCI for Splunk version 3.x and Splunk PCI for Splunk version 4.0), you can now upgrade your Splunk instance as the Splunk for PCI app is now supported for Splunk 4.1 and later.

Splunk recommends you upgrade to the latest version of Splunk PCI (Splunk PCI 1.2). To schedule your upgrade, contact your Splunk Account Executive.

Failsafe user does not get replaced when switching to LDAP auth

Starting in 4.1, LDAP authentication's failsafe user is defined in Splunk's local authentication rather than the authentication.conf file. If the failsafe user you configured for LDAP in 4.0 also exists in Splunk's local authentication system, the local Splunk auth instance of that user will not be overwritten.

For more details on LDAP auth in 4.1, review Set up user authentication with LDAP in the Admin Manual.

Splunk Web user session timeout setting has been renamed and is now in minutes

If you changed the value(s) in web.conf and/or server.conf for your existing installation, these will be in minutes rather than milliseconds. Splunk will automatically convert the values in your existing deployment when you upgradeto 4.1; you do not need to do anything.

The name of the setting has also changed from poller_timeout_interval = <integer> to ui_inactivity_timeout = <integer>.

For more details on setting user session timeouts in 4.1, review this topic about configuring user timeouts in the Admin Manual.

Default timeout value for Splunk Web has changed

The new default Splunk Web user timeout is now 60 minutes. The 4.0 default session was 15 minutes. This change was made to allow users more time to interact with real-time searches. If you have not changed the default timeout in your 4.0 instance you should reconcile this new default value with your security posture to ensure you are still compliant.

Note: If your existing timeout value was less than 1 minute, the existing setting will not be migrated, and the timeout value will use the default, which is now 60 minutes.

For more details on setting user session timeouts in 4.1, review this topic about configuring user timeouts in the Admin Manual.

Upgrading apps doesn't delete their old /default directories

If you upgrade an app to a newer version and that app has differently-named UI elements and files, you may see a lot of errors in Splunk Web when you try to run the new version of the app because some old files are still there. Before you upgrade, move aside the old $SPLUNK_HOME/etc/apps/<app_name>/default directory.

For information about Splunk apps, refer to What's an app? in the Admin Manual.

For information about Splunk configuration files, refer to About configuration files in the Admin Manual.

Splunk's CLI is now much more significantly written in C

As of 4.1, much more of the CLI is written in C instead of Python. In the unlikely event that you have local customizations the cli's python, you will have to find an alternate approach to your problem.

Pre-4.1 tags.conf files might contain unrecognized punct syntax

If you have created tags on punct in pre-4.1 version of Splunk, Splunk 4.1 may not parse the syntax correctly. This can result in inaccurate search results when you search on punct tags. To work around this issue, recreate your punct tags using Splunk Web in 4.1.

The value of host for UDP inputs is no longer looked up in DNS by default

Starting in 4.1, Splunk does not use reverse DNS to look up a domain name for host IPs in UDP inputs by default. The reasons for this are:

• Reverse lookup can cause significant loss of UDP data.
• Most often, UDP data is syslog data, which gets its host from the events themselves.

You can turn this back on in inputs.conf by setting connection_host=dns for your UDP input. Do not make this change in $SPLUNK_HOME/etc/system/default/inputs.conf. Instead, make the change in $SPLUNK_HOME/etc/system/local/inputs.conf, or in the copy of inputs.conf for the app you're using.

Some saved searches might say they're over a 'custom' timerange

If when creating a saved search in 4.0.x, you used the @ notation to round down by a unit that the timerange itself was not expressed in, or if you specified an "up until now" value that results in +0s added to the saved search timerange in times.conf, these timeranges will now be displayed as "over custom relative range" in Splunk Web. The actual value of the timerange is not affected and your searches will run as expected.

Starting in 4.1.1, these "over custom relative range" designations will be updated to reflect the standard values available in Splunk Web.

2GB free space check is enforced for dispatch directory

If you've lowered the value of minFreeSpace in server.conf to something less than 2GB (and correspondingly, less space is available to Splunk on your system), you may see the following error when running searches: The minimum free disk space (2048MB) reached for /opt/splunk/var/run/splunk/dispatch. The search was not run. . This value will be configurable (and not hard-coded to 2GB) in a future release.

The light forwarder disables the search schedulers

This was done to further decrease the footprint of the light forwarder, but if you rely on scheduled searches for remote summary indexing, this will affect you.

Considerations for converting your dashboards to real-time

Real-time searches can eliminate the need to refresh your browser or run searches on a frequent schedule. They can also have lower resource impact compared to running scheduled searches, since they do not require Splunk to decompress data or hit disk.

However, if you have multiple real-time searches on a single dashboard that many users are viewing concurrently, it can generate significant load. This is due to the fact that currently real-time searches cannot be shared across users. For more information about the performance implications of real-time search, read Expected performance and known limitations of real-time search in the User Manual.

On the other hand, if it's just you and a few other folks that are looking at a dashboard that runs a scheduled search once an hour over the last hour, it's probably much more efficient to use a real-time search.

Learn how to use real-time search and reporting: read "Search and report in real-time" in the User Manual.

Drilldown, summary indexing, and you

Clicking to drill down into charts and tables on your dashboards is a really great way to learn more about the events that they're made out of, but it's important to note that if a table or chart is built using a summary index-based search, the results you get when you drill down come from a summary index, not the original index the data came from. Summary indexes are a special kind of index, and don't contain all the information associated with the original events. This abbreviated data is what you get back if you click on a cell or row.

If you want to see the original event data, you can just edit the search on the fly to be run against the original index by specifying index=[the desired index].

You can also customize the behavior of drilldown to launch a search against the original index the data came from. Find details for doing this in "How to customize drilldown options" in the Developer Manual.

Check out "Understand table and chart drilldown actions" in the User Manual for details on using the new configurable drilldown feature.

Name of search process has changed

The name of the search process that runs for each individual search has changed from splunk-search to splunkd search. For more information about search jobs, refer to "Manage jobs in the OS" in the Admin Manual.

• Was this topic useful?
• Post a comment