This app allows you to back up and use version control to manage your Splunk knowledge objects, such as saved searches and macros.
Splunk (as of the time of writing in 2022) has no native ability to use version control on its knowledge objects. This can lead to issues where an object is accidentally changed or deleted and there is no way to restore them beyond using OS-level backups, which are difficult to use in a search head cluster.
The app uses two modular inputs to back up and restore configurations, Splunk Version Control Backup (or splunkversioncontrol_backup) and and Splunk Version Control Restore (or splunkversioncontrol_restore).
The backup portion of the app provides a Splunk modular input with the ability to serialize various Splunk knowledge objects into JSON format, which are then stored in a remote git repository with a git tag.
These two inputs do not have to be on the same machine, however, they must be pointing to the same git repository and the gitTempDir must be unique on the filesystem if sharing the same machine.
The restore portion provides a Splunk modular input and a dashboard (SplunkVersionControl Restore) that can be used to request the restoration of a knowledge object.
Use the SplunkVersionControl Restore dashboard to request that a knowledge object be restored to a prior version. You must be the author of the knowledge objects you wish to restore, or have an admin role. The Splunk application must still exist on the Splunk server for the restore to work.
There are two unique dashboards with two different restoration methods, the original version is described below:
When a knowledge object restore is requested the dashboard (SplunkVersionControl Restore) outputs the knowledge object information to a lookup with the definition splunkversioncontrol_restorelist. The modular input then triggers the restore based on the contents of this lookup, the modular input either creates or updates the knowledge object with the requested git tag, or logs the failure to find the object in the logs.
Note that the above option is the option used with Splunk Cloud, the below option can be used on on-prem instances...
The newer dynamic version follows a similar process, but instead of adding the knowledge object restore information to a lookup file it runs a Splunk custom command postversioncontrolrestore that hits a REST endpoint on either a local or a remote server.
The REST endpoint then performs a few functions:
- Queries the source system and passes in the authentication token of the current user, this includes restore information and the splunkversioncontrol_restore input stanza name
- The remote system then sends a query back to the source ip it received the request from, using the token to check the username logged in
- The remote system then looks up the login information for the relevant splunkversioncontrol_restore input stanza and runs a remote query against it
- The said remote query runs a saved search named Splunk Version Control Audit Query POST
- To prevent issues just before running the above query there is a sleep period involved (configurable via the splunk_vc_timeout macro)
- If the report confirms the relevant user did indeed request a restore of some kind, the restore continues
- The restore now followed the previous process from this point triggering a restore process
- If multiple users attempt to run the restore at the same time, one of them will receive an error to advise a restore is in progress and to try again later
The ability to restore/create configuration opens up a few obvious issues:
- What if the lookup file storing the list of objects to restore and the user who is performing the restoration is manually edited to add additional rows?
- What if a user attempts to restore the objects of another user?
- What if a user attempts to restore an object to re-own it to a different user?
To address these issues, a report named "SplunkVersionControl Audit Query" runs a query against the audit logs to determine if the lookup was updated by the saved search "SplunkVersionControl AddToLookup". This audit query returns a username and a time (it looks back/forwards one second from when the lookup was created).
The restoration script then validates that the username entered in the lookup file and the time match those found in the audit log. If they do not match then the restoration is rejected.
If you are using the dynamic version of the restore dashboard (custom command postversioncontrolrestore, an alternative report named "Splunk Version Control Audit Query POST" runs to check the audit logs, this report determines if the restoration request was made by the user in question. The report returns 0 or more results and if it returns results for the particular user, the restore proceeds.
Due to the above there is the possiblity that multiple users may trigger a restore while a restore is in progress, a kvstore is used to prevent this from occurring and an additional restore attempt when the restore process is in progress results in an error message to try again.
If a user attempts to restore the objects of another user, or attempts to restore the objects as a different user, this is allowed if the user has the admin role (which is determined by the saved search "SplunkVersionControl CheckAdmin").
A custom command named postversioncontrolrestore and the accompanying dashboard splunkversioncontrolrestore_dynamic were created for this purpose in version 1.0.7
This is not supported in SplunkCloud (the lookup file will work instead)
The assumptions are:
- git is accessible on the command line, this has been tested on Linux & Windows with git for Windows installed
- git is using an SSH-based URL and the remote git repository allows the machine running the SplunkVersionControl application to remotely access the repository without a username/password prompt (i.e. SSH keys are in use)
- git will work from the user running the Splunk process over SSH, note that on Windows this will be the system account by default, on Linux the splunk user
- the git repository is dedicated to this particular backup as the root / top level of the git repo will be used to create backups
No. However, the backup/restore modular input must have access to its own git temporary directory on the OS filesystem, the temporary directory should be unique for both backup and restore operations
During the first run of the script (at which point the lookup file is empty) all applications and all objects will be backed up.
During each subsequent run of the script, if an application is found in the Splunk system but not on the filesystem then the backup of all objects within that application will occur
Otherwise an incremental backup of knowledge objects occurs (see below)
There are two searches used to determine "what" has changed since the last run of the modular input:
- SplunkVersionControl ChangeDetector Non-Directory
- SplunkVersionControl ChangeDetector Directory
These two searches are passed in an epoch value, they then return a list of applications and the type of config that has changed.
For example if application search has had macros changed, then all macros in the search app will be backed up, however the savedsearches/dashboards/et cetera will not be backed up unless at least one of them in that app has changed.
Each backup run that results in more than 0 file changes will auto-commit all changes into git and tag with the current date/time including the minute of the hour. This will create tags such as 2019-01-10_0136, these tags can later be used to "restore from" in the "SplunkVersionControl Restore" dashboard.
The tags are recorded by outputting the tag list into the lookup definition splunkversioncontrol_taglist within the app, this same lookup definition is read by the dashboard to list available tags to restore from.
The restoration is based on a git tag, the relevant tag is checked out on the filesystem after running a git checkout master; git pull command.
Once checked out, the app/user/global directories are checked (depending on which scope was requested) to see if there is a relevant config item to restore, if found the remote object is either updated with the contents of git or created if it does not exist. By default the knowledge object is created with the same username that was in the backup, however there is an option on the SplunkVersionControl Restore dashboard to override the user on restoration, this is only able to be done by a user with an admin role.
splunkversioncontrol_globalexclusionlist, this lookup definition records a list of excluded applicationssplunkversioncontrol_restorelist, this lookup definition records what must be restored by the restore modular input (this is used by the non-dynamic dashboard)splunkversioncontrol_taglist, this lookup definition records the tags available in gitOn a Linux-based system
- /opt/splunk/var/log/splunk/splunkversioncontrol_restore.log -- this log will contain information about the splunk restore modular input
- /opt/splunk/var/log/splunk/splunkversioncontrol_backup.log -- this log will contain information about the splunk backup modular input
- /opt/splunk/var/log/splunk/splunkversioncontrol_postversioncontrolrestore.log -- this log contains information about the | postversioncontrol command
- /opt/splunk/var/log/splunk/splunkversioncontrol_rest_restore.log -- log log contains information about hits to the REST endpoint /services/splunkversioncontrol_rest_restore
The _internal index has the logs stored with the sourcetype splunkversioncontrol
splunkversioncontrol_restore_dynamic dashboard the macros splunk_vc_name, splunk_vc_url, splunk_vc_timeout may need customisation to match your environment. In particular the splunk_vc_name assumes you have called your SplunkVersionControlRestore modular input "Prod". See the macros section of this document for more informationsplunkversioncontrol_restore_dynamic dashboard then you do not need to set a run interval, if you are using the older method you want to run this on an interval to check if the lookup file has been updated and if a restore is required...splunkversioncontrol_restore dashboard, the dynamic dashboard cannot be used in SplunkCloudgithub and other websites may offer to initialize the repository for you, if they do not the steps are usually similar to:
- git clone git@<website>:testing.git
- cd testing
- touch README.md
- git add README.md
- git commit -m "add README"
- git push -u origin master
There are also many online resources to help with learning git
Please refer to github or the README.md for the details
To get passwords into or out of the passwords.conf you may wish to use https://splunkbase.splunk.com/app/4013/
The context of the application name (default of SplunkVersionControl) will be checked first for the password, if that fails a query to all contexts /-/-/ will occur, realms will be ignored, only the name of the password is used for searching so any realm (or lack of realm) will work for storing the password
The following macros exist and are relate to the splunkversioncontrol_restore_dynamic dashboard
- splunk_vc_name - this macro is the name of the splunkversioncontrol_restore modular input name on the remote (or local) system where the restore occurs
- splunk_vc_url - this macro is the URL endpoint of the remote system, defaults to https://localhost:8089/services/splunkversioncontrol_rest_restore, you will need to change this if you have a remote instance performing the backup/restore operations, for example if you are on a search head cluster
- splunk_vc_timeout - this is the time delay between triggering the remote command and waiting for the _audit index to catchup with a log entry to advise the command was run, if set too short the restore may fail because the | postversioncontrolrestore search has not appeared in the _audit index yet
- sslVerify - defaults to "False", this can be set to the location of a CA file to be used by the python requests library to validate the SSL certificates in use
- requestingAddress - by default the REST endpoint splunkversioncontrol_rest_restore will make a HTTPS call back to the calling IP address, this overrides the address to call back, the default of False results in a call back to the requesting IP address which is used in most use cases
- splunk_vc_ko_query, should be configured to point to an appname:searchname, the default is splunk_kom:splunk_vc_kom_audit_summary
Please refer to the full README.md or github for all the details
Both inputs follow a similar validation process:
- Run a request against <srcURL>/servicesNS/nobody/<remoteAppName>/search/jobs/export?search=makeresults (where remoteAppName is SplunkVersionControl unless specified)
- Run the OS command (as the user running splunk) git ls-remote <gitRepoURL>
- If the above fails attempt to run ssh -n -o \"BatchMode yes\" -o StrictHostKeyChecking=no <gitRepoURL>
- If the previous step was required re-attempt the git ls-remote step again
In 7.3.0 the Splunk process will kill -9 the modular input if it takes more than 30 seconds, if this occurs you can bypass validation by updating the inputs.conf file manually
Yes but do not configure the modular inputs to run on the search head cluster, modular inputs run on each member at the same time which would not work well. What you want to do is configure a standalone server with the modular inputs for backup/restore and set the srcURL/destURL to the remote search head cluster member (or load balanced URL) on the REST port.
This would allow the modular inputs to run backup/restore and any customers to use the dashboard on the search head cluster member to request restoration of a knowledge object
Yes, please refer to the full README.md or github for all the details
This application, no. But this application can be used to backup a SplunkCloud instance from a remote Splunk instance, the same remote instance could also be used to restore to the SplunkCloud instance.
Refer to VersionControl for SplunkCloud for the cloud version of this app
SplunkVersionControl github
SplunkVersionControlCloud github
As of October 2022, there are still no signs of version control within the Splunk Enterprise (or cloud) product, however you do have a few options in terms of a version control app, these include:
- Git Version Control for Splunk - this app provides a modular input to help with getting configuration into a git repository from the filesystem. Note: on-prem instances only, no Splunk Cloud support.
- FN1315 - Cover Your Assets: Protect Your Knowledge Objects from Yourself (and Others) - A Paychex story github - this git location provides a list of searches that produce curl commands you can use to restore objects. This can work on-prem or in Splunk Cloud
- Splunk2Git - Paychex's script to move Splunk knowledge objects into git using REST API
- Version Control for Splunk (this app) - this app uses the REST API to download configuration and store inside a git repository in JSON format. Supports restoration of objects via dashboard (no admin support required). This can work on-prem or on Splunk Cloud remotely (this app runs on prem)
- VersionControl for SplunkCloud - VersionControl for SplunkCloud, these are the dashboards and savedsearches that are installed on the SplunkCloud instance to support the version control app running remotely.
Please refer to the full README.md or github for all the details
Library updates:
- Updated Splunk python SDK to 2.0.1
Code updates:
- Added filename= to commands.conf to pass appinspect checks
Updates:
- Disabled urllib3 warnings
- Added timeout=0 on SplunkVersionControl ChangeDetector Directory savedsearch
- Added some minor comments about /services/properties/savedsearches/default (no changes in this version)
- Updated various internal calls to use sslVerify setting. Hopefully nothing will break but this will result in more SSL verification in various parts of the code
Library updates:
- Updated Splunk python SDK to 1.7.3
New features:
- Added wildcard support for restores, so restore a savedsearch of Test* will now restore any savedsearch starting with Test, wildcards can be used on any knowledge object
- Created a new file called test_git.py
Updates:
- Re-factored splunkversioncontrol_restore_class.py
- Added more debug logging in case something does fail on restoration
- Updated the savedsearches for the _audit index query to look for info=completed as well as info=granted, as this does not appear in Splunk 9
- Added more time for the _audit log entry to appear, previously it would appear on the same second the dashboard was run, now there is an approx 10 second delay
Library updates:
- Updated Splunk python SDK to 1.7.2
Updated README.md
Updated Splunk python SDK to 1.6.20
Updated Splunk python SDK to 1.6.18
Corrected an issue where a DELETE combined with other operations could cause a stacktrace if using the run_ko_diff option
Updates to:
splunkversioncontrol_backup_class.py
To correct an issue with recording the git_location of file changes in more cases
Updates to: splunkversioncontrol_backup_class.py
splunkversioncontrol_restore_class.py
To remove passwords in more cases
Updates to dashboards: splunkversioncontrol_restore.xml
splunkversioncontrol_restore_dynamic.xml
To provide a drop down list of available knowledge objects in addition to the text field option
Updated reports: SplunkVersionControl CheckAdmin - simplified to use the Splunk users list
splunk_vc_kom_audit_summary - updated to ignore the manager URI's and handle proxied REST calls from the KOM report
Updated splunk_vc_kom_audit_summary report
Added i=StanzaName to the indexed data when running the audit query
Now attempting to hide (most) passwords from the logs by default (for example when an OS error occurs don't print the stdout including the password in use)
git diff now uses --no-pager to prevent trucation of the diff command with -U0 (no context)
New options:
disable_file_deletion - do not delete files in remote git repo that are not found during backup, useful for testing
use_wdiff - sends the output of the diff command to Unix command wdiff to provide a nicer diff output
Updated report:
SplunkVersionControl ChangeDetector Non-Directory, this now excludes the CIM Risk and Incident_Management datamodels as they update very frequently with close to zero changes (calculationId changes only)
New option disable_git_ssl_verify
Support for password: syntax for the gitRepoURL parameter when using http/https
Bugfix for proxy code to work with git & HTTP proxies
This version includes a few changes, these include two new parameters on the version control backup:
run_ko_query - if enabled this runs a Splunk savedsearch and adds the additional information of tag=git_tag_name into the output of the modular input which is then indexed
run_ko_diff - if enabled in combination with run_ko_query this additionally adds a diff=git_difference_result from comparing the new version with HEAD~1
To run the query the macro splunk_vc_ko_query, should be configured to point to an appname:searchname, the default is splunk_kom:splunk_vc_kom_audit_summary
If you have the Knowledge Object Overview App for Splunk (https://splunkbase.splunk.com/app/5399/) installed then there is a savedsearch called splunk_vc_kom_audit_summary which can be moved or copied into the splunk_kom app for this new functionality to work as expected
Boolean tickboxes are now used for options that should be true or false
Various bugfixes such as setting email/name after cloning the repo
This version includes some changes that should reduce the storage size of savedsearches, in particular:
listDefaultActionArgs=false is now used on the savedsearches REST endpoint
display.visualization.* is only backed up if display.general.type = visualizations, this should reduce the storage size of savedsearches
Note that I have also created https://ideas.splunk.com/ideas/EID-I-1052 as a request to reduce the savedsearches data from the REST API
Version 1.2.0 includes a few major changes:
- file_per_ko mode, disabled by default, if enabled outputs 1 file per knowledge object instead of including all knowledge objects of a type within 1 file
- next_scheduled_time attribute removed from savedsearches (this results in less unnnessary git commits)
- newlines in json data
- support added for http/https based git repositories in addition to ssh-based repo's
(See details or 1.2.0 for more information)
This version includes a few major changes:
- file_per_ko mode, disabled by default, if enabled outputs 1 file per knowledge object instead of including all knowledge objects of a type within 1 file
- next_scheduled_time attribute removed from savedsearches (this results in less unnnessary git commits)
- code updated so that newlines are used in the json files, this makes the files stored in git more human readable and easier to see what changed between backups
- support added for http/https based git repositories in addition to ssh-based repo's
If you would like to use file_per_ko this will result in a lot more files in the git repository but this will make it easier to see the history of changes in each file
Note that you must set file_per_ko to true in both the backup & restore for this to work as expected, also if you change the setting you will need to re-create or wipe the repo as the files are stored differently
Merged pull request from bre77 to make sslVerify option on restore equivalent to the backup version
Note that 1.1.13 had a bug in it, I will release a new version soon...
1.1.11: Fix sslVerify option
1.1.10: Added new parameters into the splunkversioncontrol_backup modular input for:
git_name
git_email
By default the git global settings will be used, but if specified these will run a git config user.name/git config user.email after cloning the repo
1.1.9 updates:
README.md update - git repositories must be dedicated per-backup and not shared with other items as the root level / top level directory is used
Merged pull request from calesanz #16 to allow a new sslVerify option to pass in the CA certificate file, or to leave SSL validation disabled
In addition this pull request adds a requestingAddress which optionally controls the call-back ip when using the postversioncontrolrestore command
Finally this pull requests adds scripts and a testing suite using docker into the github version, for SplunkBase the test directory is removed (you can access it on https://github.com/gjanders/SplunkVersionControl)
Updated Splunk python SDK to 1.6.15
Added new parameters into the splunkversioncontrol_backup modular input for:
git_name
git_email
By default the git global settings will be used, but if specified these will run a git config user.name/git config user.email after cloning the repo
1.1.9 updates:
README.md update - git repositories must be dedicated per-backup and not shared with other items as the root level / top level directory is used
Merged pull request from calesanz #16 to allow a new sslVerify option to pass in the CA certificate file, or to leave SSL validation disabled
In addition this pull request adds a requestingAddress which optionally controls the call-back ip when using the postversioncontrolrestore command
Finally this pull requests adds scripts and a testing suite using docker into the github version, for SplunkBase the test directory is removed (you can access it on https://github.com/gjanders/SplunkVersionControl)
Updated Splunk python SDK to 1.6.15
README.md update - git repositories must be dedicated per-backup and not shared with other items as the root level / top level directory is used
Merged pull request from calesanz #16 to allow a new sslVerify option to pass in the CA certificate file, or to leave SSL validation disabled
In addition this pull request adds a requestingAddress which optionally controls the call-back ip when using the postversioncontrolrestore command
Finally this pull requests adds scripts and a testing suite using docker into the github version, for SplunkBase the test directory is removed (you can access it on https://github.com/gjanders/SplunkVersionControl)
Updated Splunk python SDK to 1.6.15
Updates include:
Increase timeout for commands to a default of 60 seconds
Ensure a valid message is sent back to the user if a dynamic restore fails
If git checkout times out, cancel the restore attempt
Updates include:
Allow the backup process to run on search head clusters for those that wish to do this...
Corrected a bug where the lookup could be updated even if the git check-in failed
Updated python SDK to 1.6.14
Version 1.1.5 corrects a minor issue the removal of the git temp directory
Version 1.1.4 and 1.1.3 allow password: to be used in dynamic/rest restore
Version 1.1.2 fixes an issue in python 3 / Splunk 8
Corrected useLocalAuth setting so that it works
Corrected imports so that post version control method works as well as the cloud version
Now tested on Windows and Splunk Cloud (note this version of the app is not installed on SplunkCloud, the VersionControl for SplunkCloud is the app to install on the SplunkCloud instance, this variation of the app includes only what is required to remotely backup/restore a SplunkCloud instance
This app is still used for SplunkCloud instances, but this app is installed on-prem
Updates include:
- Updated python SDK to 1.6.13
- New options in both backup & restore so that you can specify the location of the git / SSH command
- The ability to only backup particular apps by default rather than to backup all
- Support passwords.conf
- Proxy support
- Re-wrote runOSProcess
Version 1.1.4 and 1.1.3 allows password: to be used in dynamic/rest restore
Version 1.1.2 fixes an issue in python 3 / Splunk 8
Previous release notes:
Corrected useLocalAuth setting so that it works
Corrected imports so that post version control method works as well as the cloud version
Now tested on Windows and Splunk Cloud (note this version of the app is not installed on SplunkCloud, the VersionControl for SplunkCloud is the app to install on the SplunkCloud instance, this variation of the app includes only what is required to remotely backup/restore a SplunkCloud instance
This app is still used for SplunkCloud instances, but this app is installed on-prem
Updates include:
- Updated python SDK to 1.6.13
- New options in both backup & restore so that you can specify the location of the git / SSH command
- The ability to only backup particular apps by default rather than to backup all and rely on an exclusion list (appsList)
- Support for passwords.conf
- Proxy support
- Re-wrote runOSProcess function
Version 1.1.3 allows password: to be used in dynamic/rest restore
Version 1.1.2 fixes an issue in python 3 / Splunk 8
Previous release notes:
Corrected useLocalAuth setting so that it works
Corrected imports so that post version control method works as well as the cloud version
Now tested on Windows and Splunk Cloud (note this version of the app is not installed on SplunkCloud, the VersionControl for SplunkCloud is the app to install on the SplunkCloud instance, this variation of the app includes only what is required to remotely backup/restore a SplunkCloud instance
This app is still used for SplunkCloud instances, but this app is installed on-prem
Updates include:
- Updated python SDK to 1.6.13
- New options in both backup & restore so that you can specify the location of the git / SSH command
- The ability to only backup particular apps by default rather than to backup all and rely on an exclusion list (appsList)
- Support for passwords.conf
- Proxy support
- Re-wrote the runOSProcess function
Version 1.1.2 fixes an issue in python 3 / Splunk 8
Previous release notes:
Corrected useLocalAuth setting so that it works as expected
Corrected imports so that post version control method works as well as the cloud version
Now tested on Windows and Splunk Cloud (note this version of the app is not installed on SplunkCloud, the VersionControl for SplunkCloud is the app to install on the SplunkCloud instance, this variation of the app includes only what is required to remotely backup/restore a SplunkCloud instance
This app is still used for SplunkCloud instances, but this app is installed on-prem
Updates include:
- Updated python SDK to 1.6.13
- New options in both backup & restore so that you can specify the location of the git / SSH command
- The ability to only backup particular apps by default rather than to backup all and rely on an exclusion list (appsList)
- Support for passwords.conf instead of plain text passwords
- Proxy support
- Re-wrote the runOSProcess function
Corrected useLocalAuth setting so that it works as expected
Corrected imports so that post version control method works as well as the cloud version
Version 1.1.0 release notes:
Now tested on Windows and Splunk Cloud (note this version of the app is not installed on SplunkCloud, the VersionControl for SplunkCloud is the app to install on the SplunkCloud instance, this variation of the app includes only what is required to remotely backup/restore a SplunkCloud instance
This app is still used for SplunkCloud instances, but this app is installed on-prem
Updates include:
- Updated python SDK to 1.6.13
- New options in both backup & restore so that you can specify the location of the git / SSH command
- The ability to only backup particular apps by default rather than to backup all and rely on an exclusion list (appsList)
- Support for passwords.conf instead of plain text passwords
- Proxy support
- Re-wrote the runOSProcess function so that it works on Windows as expected
The README.md has had various updates
Now tested on Windows and Splunk Cloud (note this version of the app is not installed on SplunkCloud, the VersionControl for SplunkCloud is the app to install on the SplunkCloud instance, this variation of the app includes only what is required to remotely backup/restore a SplunkCloud instance
This app is still used for SplunkCloud instances, but this app is installed on-prem
Updates include:
- Updated python SDK to 1.6.13
- New options in both backup & restore so that you can specify the location of the git / SSH command
- The ability to only backup particular apps by default rather than to backup all and rely on an exclusion list (appsList)
- Support for passwords.conf instead of plain text passwords
- Proxy support
- Re-wrote the runOSProcess function so that it works on Windows as expected
The README.md has had various updates including more details around setup and how this was tested on Windows
Please refer to https://splunkbase.splunk.com/app/5061/ for the SplunkCloud version of this app
Fixed missing sys import from splunkversioncontrol_rest_restore.py
Updated README.md instructions
Updated python SDK to version 1.6.12
Updated inputs.conf.spec and restmap.conf to specify python3 as the default version to pass appinspect
Corrected errors in the import of the six library which stopped this from working
Minor updates to README.md
Changed import to use local Splunk python SDK to ensure this works on older Splunk versions
Added the (experimental) apps list option to attempt to make this work with Splunk Cloud instances
1.0.9 provides python 3 / Splunk 8 support (no other changes), and fixes a bug in 1.0.8
Version 1.0.7 has a few major changes:
- Restoration immediately after clicking the restore button
- The previous lookup file method remains supported, the splunkversioncontrol_restore modular input must still exist, but it is not required to run on a schedule
- Changes to the way the OS processes are executed in python which makes it more reliable during validation of the modular inputs
- Improved logging
The new dashboard splunkversioncontrol_restore_dynamic is now the default dashboard is an alternative to the splunkversioncontrol_restore dashboard which remains lookup based (the latter dashboard assumes the splunkversioncontrol_restore modular input is running on a schedule
Note that if you are running this app on a search head cluster, and restoring from a different server you may wish to remove the files:
- web.conf
- restmap.conf
from the default directory, this removes the ability to trigger a remote restore
1.0.8 provides python 3 / Splunk 8 support (no other changes)
Version 1.0.7 has a few major changes:
- Restoration immediately after clicking the restore button
- The previous lookup file method remains supported, the splunkversioncontrol_restore modular input must still exist, but it is not required to run on a schedule
- Changes to the way the OS processes are executed in python which makes it more reliable during validation of the modular inputs
- Improved logging
The new dashboard splunkversioncontrol_restore_dynamic is now the default dashboard is an alternative to the splunkversioncontrol_restore dashboard which remains lookup based (the latter dashboard assumes the splunkversioncontrol_restore modular input is running on a schedule
Note that if you are running this app on a search head cluster, and restoring from a different server you may wish to remove the files:
- web.conf
- restmap.conf
from the default directory, this removes the ability to trigger a remote restore
This version has a few major changes:
- Restoration immediately after clicking the restore button rather than using lookup files
- The previous lookup file method remains supported, in fact the splunkversioncontrol_restore modular input must still exist, but it is not required to run on a schedule
- Changes to the way the OS processes are executed in python which makes it more reliable during validation of the modular inputs
- Improved logging, in particular relating to the validation procedure
The new dashboard splunkversioncontrol_restore_dynamic is now the default dashboard is an alternative to the splunkversioncontrol_restore dashboard which remains lookup based (the latter dashboard assumes the splunkversioncontrol_restore modular input is running on a schedule
Note that if you are running this app on a search head cluster, and restoring from a different server you may wish to remove the files:
- web.conf
- restmap.conf
from the default directory, this removes the ability to trigger a remote restore
Dashboard backups no longer include version attribute (appears on some dashboards and prevents restoration)
Updated README.md to include an installation and troubleshooting guide
Additional tweak to handle first run of the backup modular input when backing up macros
Changes to the code to wipe the git directory re-clone on failure in both the clone failure & checkout master / git pull scenarios
Testing for this app has been completed on dashboards, savedsearches, eventtypes, datamodels, fieldaliases, navmenus (update only) and a few other misc types.
If there are any issues either open a request via github or contact me on SplunkBase
If you like this app you may also be interested in Alerts For Splunk Admins https://splunkbase.splunk.com/app/3796/
Contributions welcome!
Minor changes to the code to wipe the git directory re-clone on failure in both the clone failure & checkout master / git pull scenarios
Testing for this app has been completed on dashboards, savedsearches, eventtypes, datamodels, fieldaliases, navmenus (update only) and a few other misc types.
If there are any issues either open a request via github or contact me on SplunkBase
If you like this app you may also be interested in Alerts For Splunk Admins https://splunkbase.splunk.com/app/3796/
Contributions welcome!
Version 1.0.3, correction for first backup run to check that lastRunEpoch is None
Mild tweaks to logging to handle failures in the saved searches
Testing for this app has been completed on dashboards, savedsearches, eventtypes, datamodels, fieldaliases, navmenus (update only) and a few other misc types.
If there are any issues either open a request via github or contact me on SplunkBase
If you like this app you may also be interested in Alerts For Splunk Admins https://splunkbase.splunk.com/app/3796/
Contributions welcome!
Version 1.0.1/2, have improvements to logging for updated objects only, no functional changes
Version 1.0.0, improvements to logging for git related errors and auto-wipe of the git repo on failure (this handles corruption of git repos on disk)
Version 0.0.7, change of app icons only, no functional changes
Version 0.0.6, adds the sort_keys option into the python code, this should ensure the output files for git are in a consistent order (previously random). The goal is to reduce the git repository size increase over time
Added Troubleshooting section in details/README.md about "OPENSSL not found" issues on Ubuntu
Testing for this app has been completed on dashboards, savedsearches, eventtypes, datamodels, fieldaliases, navmenus (update only) and a few other misc types.
If there are any issues either open a request via github or contact me on SplunkBase
If you like this app you may also be interested in Alerts For Splunk Admins https://splunkbase.splunk.com/app/3796/
Contributions welcome!
Version 1.0.0, improvements to logging for git related errors and auto-wipe of the git repo on failure (this handles corruption of git repos on disk)
Version 0.0.7, change of app icons only, no functional changes
Version 0.0.6, adds the sort_keys option into the python code, this should ensure the output files for git are in a consistent order (previously random). The goal is to reduce the git repository size increase over time
Added Troubleshooting section in details/README.md about "OPENSSL not found" issues on Ubuntu
Testing for this app has been completed on dashboards, savedsearches, eventtypes, datamodels, fieldaliases, navmenus (update only) and a few other misc types.
If there are any issues either open a request via github or contact me on SplunkBase
If you like this app you may also be interested in Alerts For Splunk Admins https://splunkbase.splunk.com/app/3796/
Contributions welcome!
Version 0.0.8, improvements to logging for git related errors
Version 0.0.7, change of app icons only, no functional changes
Version 0.0.6, adds the sort_keys option into the python code, this should ensure the output files for git are in a consistent order (previously random). The goal is to reduce the git repository size increase over time
Added Troubleshooting section in details/README.md about "OPENSSL not found" issues on Ubuntu
Version 0.0.5, increased the timeouts for git commands to 120 seconds instead of 30 seconds as it was too short for larger repositories
Testing for this app has been completed on dashboards, savedsearches, eventtypes, datamodels, fieldaliases, navmenus (update only) and a few other misc types.
If there are any issues either open a request via github or contact me on SplunkBase
If you like this app you may also be interested in Alerts For Splunk Admins https://splunkbase.splunk.com/app/3796/
Contributions welcome!
Version 0.0.7, change of app icons only, no functional changes
Version 0.0.6, adds the sort_keys option into the python code, this should ensure the output files for git are in a consistent order (previously random). The goal is to reduce the git repository size increase over time
Added Troubleshooting section in details/README.md about "OPENSSL not found" issues on Ubuntu
Version 0.0.5, increased the timeouts for git commands to 120 seconds instead of 30 seconds as it was too short for larger repositories
Testing for this app has been completed on dashboards, savedsearches, eventtypes, datamodels, fieldaliases, navmenus (update only) and a few other misc types.
If there are any issues either open a request via github or contact me on SplunkBase
If you like this app you may also be interested in Alerts For Splunk Admins https://splunkbase.splunk.com/app/3796/
Contributions welcome!
Version 0.0.6, adds the sort_keys option into the python code, this should ensure the output files for git are in a consistent order (previously random). The goal is to reduce the git repository size increase over time
Added Troubleshooting section in details/README.md about "OPENSSL not found" issues on Ubuntu
Version 0.0.5, increased the timeouts for git commands to 120 seconds instead of 30 seconds as it was too short for larger repositories
Testing for this app has been completed on dashboards, savedsearches, eventtypes, datamodels, fieldaliases, navmenus (update only) and a few other misc types.
If there are any issues either open a request via github or contact me on SplunkBase
If you like this app you may also be interested in Alerts For Splunk Admins https://splunkbase.splunk.com/app/3796/
Contributions welcome!
Version 0.0.5, increases the timeouts for git commands to 120 seconds instead of 30 seconds as it was too short for larger repositories
Testing for this app has been completed on dashboards, savedsearches, eventtypes, datamodels, fieldaliases, navmenus (update only) and a few other misc types.
If there are any issues either open a request via github or contact me on SplunkBase
If you like this app you may also be interested in Alerts For Splunk Admins https://splunkbase.splunk.com/app/3796/
Contributions welcome!
Version 0.0.4, this has been tested and working on the knowledge objects I have tested so far (backup & restore), this includes dashboards, savedsearches, eventtypes, datamodels, fieldaliases, navmenus (update only) and a few others.
Additional features from 0.0.3 include the help menu on the Splunk Version Control Restore dashboard
And the addition of the Knowledge objects by app dashboard
Testing has been completed on 7.0.x and 7.2.x, I believe this will work just fine on 6.6 but if it does not let me know
If there are any issues either open a request via github or contact me on SplunkBase
If you like this app you may also be interested in Alerts For Splunk Admins https://splunkbase.splunk.com/app/3796/
Contributions welcome!
Version 0.0.3, this has been tested and working on the knowledge objects I have tested so far (backup & restore), this includes dashboards, savedsearches, eventtypes, datamodels, fieldaliases, navmenus (update only) and a few others.
Testing has been completed on 7.0.x and 7.2.x, I believe this will work just fine on 6.6 but if it does not let me know
If there are any issues either open a request via github or contact me on SplunkBase
If you like this app you may also be interested in Alerts For Splunk Admins https://splunkbase.splunk.com/app/3796/
Contributions welcome!
Version 0.0.2, this has been tested and working on the knowledge objects I have tested so far (backup & restore)
Testing has been completed on 7.0.x and 7.2.x, I believe this will work just fine on 6.6 but if it does not let me know
Version 0.0.1, this has been tested and working on my current instance but may require further tweaking
Note testing has been completed on 7.0.x and 7.2.x, I believe this will work just fine on 6.6 but if it does not let me know
As a Splunkbase app developer, you will have access to all Splunk development resources and receive a 10GB license to build an app that will help solve use cases for customers all over the world. Splunkbase has 1000+ apps from Splunk, our partners and our community. Find an app for most any data source and user need, or simply create your own with help from our developer portal.