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] [--url URL]
                           [--user USER] [--pass PASSWORD] [-k]
                           [--session-key SESSION_KEY] [--app APP]
                           [--owner OWNER] [--sharing {user,app,global}] [-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.
`--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.
`--app`	Set the namespace (app name) for the endpoint
`--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.
`-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