ksconf rest-publish

Note

This command effectively replaces ksconf rest-export for nearly all use cases. The only thing that rest-publish can’t do that rest-export can, is handle a disconnected scenario. But for ALL other use cases, the rest-publish (this command) command is far superior.

Note

This commands requires the Splunk Python SDK, which is automatically bundled with the Splunk app for KSCONF.

Publish stanzas in a .conf file to a running Splunk instance via REST. This requires access to the HTTPS endpoint of Splunk. By default, ksconf will handle both the creation of new stanzas and the update of existing stanzas.

This can be used to push full configuration stanzas where you only have REST access and can’t directly publish an app.

Only attributes present in the conf file are pushed. While this may seem obvious, this fact can have profound implications in certain situations, like when using this command for continuous updates. This means that it’s possible for the source .conf to ultimately differ from what ends up on the server’s .conf file. One way to avoid this, is to explicitly remove an object using --delete mode first, and then insert a new copy of the object. Of course, this means that the object will be unavailable. The other impact is that diffs only compares and shows a subset of attribute.

Be aware, that for consistency, the configs/conf-TYPE endpoint is used for this command. Therefore, a reload may be required for the server to use the published config settings.

usage: ksconf rest-publish [-h] [--conf TYPE] [-m META] [--app APP]
                           [--owner OWNER] [--sharing {user,app,global}]
                           [--url URL] [--user USER] [--pass PASSWORD] [-k]
                           [--session-key SESSION_KEY] [--token TOKEN] [-D]
                           CONF [CONF ...]

Positional Arguments

CONF: Configuration file(s) to export settings from.

Named Arguments

--conf

Explicitly set the configuration file type. By default, this is derived from CONF, but sometimes it’s helpful to set this explicitly. Can be any valid Splunk conf file type. Examples include: ‘app’, ‘props’, ‘tags’, ‘savedsearches’, etc.

-m, --meta

Specify one or more .meta files to determine the desired read & write ACLs, owner, and sharing for objects in the CONF file.

--app

Set the namespace (app name) for the endpoint. Default ‘search’

--owner

Set the user who owns the content. The default of ‘nobody’ works well for app-level sharing.

--sharing

Possible choices: user, app, global

Set the sharing mode. Defaults to ‘app’.

--url

URL of Splunkd. Default: ‘https://localhost:8089’

--user

Login username Splunkd. Default: ‘admin’

--pass

Login password Splunkd. Default: ‘changeme’

-k, --insecure

Disable SSL cert validation.

--session-key

Use an existing session token instead of using a username and password to login.

--token

Use a Splunk token (bearer token)

-D, --delete

Remove existing REST entities. This is a destructive operation. In this mode, stanza attributes are unnecessary. NOTE: This works for ‘local’ entities only; the default folder cannot be updated.

Examples

A simple example:

ksconf rest-publish etc/app/Splunk_TA_aws/local/props.conf \
    --user admin --password secret --app Splunk_TA_aws --owner nobody --sharing global

This command also supports replaying metdata like ACLs:

ksconf rest-publish etc/app/Splunk_TA_aws/local/props.conf \
    --meta etc/app/Splunk_TA_aws/metdata/local.meta \
    --user admin --password secret --app Splunk_TA_aws