netopeer2-cli(1)

πŸ“¦
version 2.4.5 Β· 2 versions
, in fedora 43, fedora 44

🌸 netopeer2-cli(1) β€” General Commands Manual 🌸

πŸ’– NAME πŸ’–

netopeer2-cli β€” a NETCONF client with a command line interface built on libnetconf2.

✨ DESCRIPTION ✨

Okay bestie, here's the vibe: netopeer2-cli is your generic NETCONF client with a simple interactive command line interface. It lets you establish a NETCONF session with a NETCONF-enabled device on the network and then obtain and manipulate its configuration data. The catch? netopeer2-cli is limited to a single NETCONF connection at a time via a forward or a reverse (Call Home) connecting method.

Here's the list of NETCONF capabilities supported by netopeer2-cli:

  • NETCONF protocol version 1.0 and 1.1 (RFC 6241)
  • SSH transport (RFC 6242)
  • TLS transport (RFC 7589)
  • Call Home (RFC 8071)
  • Event Notifications (RFC 5277)
  • Access Control (RFC 6536)
  • :writable-running capability
  • :startup capability
  • :candidate capability
  • :confirmed-commit capability
  • :validate capability version 1.1
  • :with-defaults capability (RFC 6243)
  • :url capability
  • :xpath capability
  • NMDA operations (RFC 8526)
  • YANG Schema Mount (RFC 8528)
  • YANG notification subscriptions (RFC 8639)
  • YANG Push subscriptions (RFC 8641)

πŸš€ TRANSPORT πŸš€

The supported transport protocols are detected automatically based on how libnetconf2 was compiled. Unsupported (sub)commands are then not available and are hidden in the help. This page, however, contains them all. ✨

πŸ’… COMMANDS πŸ’…

πŸ¦‹ auth πŸ¦‹

Manage SSH authentication options β€” authentication preferences and private keys.

πŸ’‘ This command is available with SSH support.
auth (--help | pref [(publickey | interactive | password) preference] |
keys [add private_key_path] [remove key_index])
  • pref β€” Print the current authentication method preferences or change a specific method preference.
  • preference β€” The new preference of the authentication method. Negative values disable the authentication method.
  • keys β€” Manage keys used for authentication.
  • path_to_the_key β€” If specified, add or remove the keys. If not, show the current keys.
  • remove cert_name β€” Removes the cert_name certificate from the trusted CA dir ~/.netopeer2-cli/certs and recalculates hashes of all the certificates. cert_name is the certificate file name, as displayed in the cert display command output.
  • displayown β€” Shows information about the status of the default client certificates and displays information about any relevant found client certificates ~/.netopeer2-cli/client.crt and ~/.netopeer2-cli/client.pem.
  • replaceown cert_path [key_path] β€” Replaces the default client certificates with the PEM certificate in cert_path or the CRT certificate cert_path and private key key_path. All previous client certificates are deleted.

πŸ¦‹ cancel-commit πŸ¦‹

Cancel a pending confirmed commit.

cancel-commit [--help] [--persist-id commit-id]
  • --persist-(i)d commit-id β€” Cancel a specific commit-id pending confirmed commit.

πŸ¦‹ cert πŸ¦‹

Manage client and trusted Certificate Authority certificates that are used for TLS verification stored in ~/.netopeer2-cli/client.* and ~/.netopeer2-cli/certs respectively.

πŸ’‘ This command is available with TLS support.
cert [--help] [display] [add cert_path] [remove cert_name] [displayown]
[replaceown (cert_path.pem | cert_path.crt key_path.key)]
  • display β€” Displays all the recognized certificates in ~/.netopeer2-cli/certs. First the file name and serial number, then subject, issuer and validity are shown for each certificate.
  • add cert_path β€” Adds the cert_path certificate to the trusted CA dir ~/.netopeer2-cli/certs and recalculates hashes of all the certificates.
πŸ‘€ Heads up: the deets for remove cert_name, displayown, and replaceown are chillin' under the auth section above, exactly where the original page put them. We're not moving them, periodt.

πŸ¦‹ commit πŸ¦‹

Perform NETCONF <commit> operation. For more details see RFC 6241 section 8.3.4.1.

commit [--help] [--confirmed] [--confirm-timeout sec] [--persist new-
commit-id] [--persist-id commit-id]
  • --(c)onfirmed β€” Make the <commit> a confirmed commit. See RFC 6421 section 8.4.
  • --confirm-(t)imeout sec β€” Specify the confirmed commit timeout. Can be used only with --confirmed.
  • --(p)ersist new-commit-id β€” Make the commit a persistent commit. new-commit-id is the identificator of the commit.
  • --persist-(i)d commit-id β€” Confirm a persistent commit with the commit-id identificator.

πŸ¦‹ connect πŸ¦‹

Connect to a NETCONF server.

connect [--help] [--host hostname] [--port num]
    [--ssh] [--login username]
    --tls  [--cert cert_path [--key key_path]] [--trusted
trusted_CA_store.pem]
  • --h(o)st hostname β€” Specifies the hostname of the NETCONF server to connect to. If not specified, localhost is used.
  • --(p)ort num β€” Port to connect to the NETCONF server on. By default, port 830 for SSH or 6513 for TLS transport is used.
  • --(s)sh β€” Use NETCONF over SSH transport. This is the default, when both SSH and TLS are enabled.
  • --(l)ogin username β€” Specify the SSH username to connect with. By default, the current system user is used.
  • --(t)ls β€” Use NETCONF over TLS transport.
  • --(c)ert cert_path β€” Use a specific certificate for TLS handshake. cert_path specifies path to the client certificate in CRT format. If the --key option is not specified, cert_path is expected to contain also the private key for the client certificate, in PEM format.
  • --(k)ey key_path β€” Specifies path to the private key for the client certificate in KEY format. If not specified, cert_path is expected to contain also the private key for the client certificate, in PEM format.
  • --t(r)usted trusted_CA_store.pem β€” Specifies path to a trusted CA certificate bundle in PEM format to be used exclusively for server verification for this connection instead of the default CA directory.

πŸ¦‹ copy-config πŸ¦‹

Perform NETCONF <copy-config> operation. For more details see RFC 6241 section 7.3.

copy-config [--help] --target running|startup|candidate|url:url
(--source running|startup|candidate|url:url | --src-config [file])
[--defaults report-all|report-all-tagged|trim|explicit]
  • --(t)arget running|startup|candidate|url:url β€” Specifies the target of the <copy-config> operation. Either a datastore or a specific URL can be specified.
  • --(s)ource running|startup|candidate|url:url β€” Specifies the source of the <copy-config> operation. Either a datastore or a specific URL can be specified.
  • --src-(c)onfig [file] β€” Specifies the source of the <copy-config> operation. If a file with the configuration is not specified, the configuration is read from the standard input.
  • --(d)efaults report-all|report-all-tagged|trim|explicit β€” Use :with-defaults capability with the specified retrieval mode. For more details see RFC 6243 section 3.

πŸ¦‹ delete-config πŸ¦‹

Perform NETCONF <delete-config> operation. For more details see RFC 6241 section 7.4.

delete-config [--help] --target startup|url:url
  • --(t)arget startup|url:url β€” Specifies the target of the <delete-config> operation. Either the startup datastore or a specific URL can be specified.

πŸ¦‹ delete-sub πŸ¦‹

Perform YANG notifications <delete-subscription> operation. For more details see RFC 8639 section 2.4.4..

delete-sub [--help] --id <sub-ID> [--out <file>] [--rpc-timeout
<seconds>]
  • --(i)d sub-ID β€” ID of the subscription to delete.

πŸ¦‹ discard-changes πŸ¦‹

Perform NETCONF <discard-changes> operation. It reverts the candidate configuration to the current running configuration. For more details see RFC 6241 section 8.3.4.2.

πŸ¦‹ disconnect πŸ¦‹

Disconnect from a NETCONF server.

πŸ¦‹ edit-config πŸ¦‹

Perform NETCONF <edit-config> operation. For more details see RFC 6241 section 7.2.

edit-config [--help] --target running|candidate (--config [file] | --url
url) [--defop merge|replace|none] [--test set|test-only|test-then-set]
[--error stop|continue|rollback]
  • --(t)arget running|candidate β€” Specifies the target of the <edit-config> operation.
  • --(c)onfig [file] β€” Specifies the content of the <edit-config> operation. If a file with the configuration is not specified, the configuration is read from the standard input.
  • --(u)rl ur β€” Specifies the content of the <edit-config> operation. It is retrieved from that specific URL.
  • --def(o)p merge|replace|none β€” Specifies default operation for applying configuration data.
    • merge β€” Merge configuration data at the corresponding level. This is the default value.
    • replace β€” Edit configuration data completely replaces the configuration in the target datastore.
    • none β€” The target datastore is unaffected by the edit configuration data, unless and until the edit configuration data contains the operation attribute to request a different operation.
  • --t(e)st set|test-only|test-then-set β€” Perform validation of the modified configuration data. This option is available only if the server supports :validate:1.1 capability (see RFC 6241 section 8.6).
    • set β€” Do not perform validation test.
    • test-only β€” Do not apply the modified data, only perform the validation test.
    • test-then-set β€” Perform a validation test before attempting to apply modified configuration data. This is the default value.
  • --e(r)ror stop|continue|rollback β€” Set reaction to an error.
    • stop β€” Abort the operation on first error. This is the default value.
    • continue β€” Continue to process configuration data on error. The error is recorded and negative response is returned.
    • rollback β€” Stop the operation processing on error and restore the configuration to its complete state at the start of this operation. This action is available only if the server supports :rollback-on-error capability (see RFC 6241 section 8.5).

πŸ¦‹ edit-data πŸ¦‹

Perform NMDA <edit-data> operation. For more details see RFC 8526 section 3.1.2..

✏️ edit-data

Bestie, this one edits a datastore. That's the whole vibe. πŸ’…

edit-data [--help] --datastore running|startup|candidate
          (--config[=<file>] | --url <url>) [--defop merge|replace|none]
          [--rpc-timeout <seconds>]
  • --(d)atastore running|startup|candidate β€” picks which datastore you're editing, no cap.
  • --(c)onfig [file] β€” sets the content of the <edit-config> operation. If you don't hand it a file with the configuration, it just reads from standard input instead. iconic behaviour tbh.
  • --(u)rl *url* β€” same idea, but the content of the <edit-config> operation gets retrieved from that specific URL.
  • --def(o)p merge|replace|none β€” the default operation used for applying configuration data:
    • merge β€” merge configuration data at the corresponding level. This is the default value. ✨
    • replace β€” edit configuration data completely replaces the configuration in the target datastore. full send.
    • none β€” the target datastore is unaffected by the edit configuration data, unless and until the edit configuration data contains the operation attribute asking for a different operation. periodt.

✏️ editor

Manage the external editor used for modifying raw input data. your lil text-editing sidekick πŸŽ€

editor [--help] [path/name_of_the_editor]
  • path/name_of_the_editor β€” the full path, or literally just the name, of the editor you wanna use.

πŸ“‘ establish-push

Performs the YANG push <establish-subscription> operation. It must be either periodic or on-change β€” pick a lane bestie. For more details see RFC 8641 section 4.4.1..

establish-push [--help] --datastore running|startup|candidate|operational
               [--filter-subtree[=<file>] | --filter-xpath <XPath> |
               --filter-ref <name>] [--end <time>] [--encoding <encoding>]
               (--periodic --period <period> [--anchor-time <time>] |
               --on-change [--dampening-period <period>] [--no-sync-on-start]
               [--excluded-change <change>]*) [--out <file>]
               [--rpc-timeout <seconds>]
  • --(d)atastore running|startup|candidate|operational β€” selects the datastore to subscribe to for YANG push updates. πŸ‘‘
  • --filter-(s)ubtree [file] β€” says whether the request will carry a subtree filter (RFC 6241 section 6). The file is expected to contain the filter specification, and if you don't specify one, it's read from standard input.
  • --filter-(x)path *XPath* β€” says whether the request will carry an XPath filter. The XPath is the expression used for filtering.
  • --filter-(r)ef *name* β€” says whether the request will carry a referenced stored filter.
  • --(e)nd *time* β€” specifies when the event replay stops. The format of the time parameter goes like this:
    • +time β€” current time plus the given number of seconds.
    • time β€” absolute time as number of seconds since 1970-01-01.
    • -time β€” current time minus the given number of seconds.
  • --(e)ncoding *encoding* β€” encoding to use for the notification. The default is XML, which is only what NETCONF supports. ngl that's just how it is πŸ’€
  • --period *period* β€” periodic push subscription period, aka the interval between notifications.
  • --anchor-time *time* β€” periodic push subscription point in time to anchor the period to.
  • --dampening-period *period* β€” on-change push subscription dampening period, to prevent too many subscriptions being sent.
  • --no-sync-on-start β€” on-change push subscription option to not send an initial subscription with the current configuration.
  • --excluded-change *change* β€” on-change push subscription changes that will be excluded and not reported in the notifications.

πŸ“‘ establish-sub

Performs the YANG notifications <establish-subscription> operation. For more details see RFC 8639 section 2.4.2..

establish-sub [--help] --stream <stream> [--filter-subtree[=<file>] |
              --filter-xpath <XPath> | --filter-ref <name>] [--begin <time>]
              [--end <time>] [--encoding <encoding>] [--out <file>]
              [--rpc-timeout <seconds>]
  • --s(t)ream *stream* β€” the NETCONF event stream to subscribe to. yes, the t is hiding in the middle, that's just how it's written 🫢
  • --filter-(s)ubtree [file] β€” says whether the request will carry a subtree filter (RFC 6241 section 6). The file is expected to contain the filter specification; if it's not specified, it's read from standard input.
  • --filter-(x)path *XPath* β€” says whether the request will carry an XPath filter. The XPath is the expression used for filtering.
  • --filter-(r)ef *name* β€” says whether the request will carry a referenced stored filter.
  • --(b)egin *time* β€” start to replay event notifications from the past (a future time is not valid, so don't try it πŸ™ˆ). If the start time is not specified, the replay feature is not activated and only new event notifications are received. The format of the time parameter is described below. ⬇️
  • --(e)nd *time* β€” specifies when the event replay stops. The format of the time parameter goes like this:
    • +time β€” current time plus the given number of seconds.
    • time β€” absolute time as number of seconds since 1970-01-01.
    • -time β€” current time minus the given number of seconds.
  • --(e)ncoding *encoding* β€” encoding to use for the notification. The default is XML, which is only what NETCONF supports.

πŸšͺ exit

Quit the program. that's it, that's the whole thing, bye bestie πŸ‘‹πŸ’–


πŸ“₯ get

Performs the NETCONF <get> operation. It retrieves both status and configuration data from the current running datastore. For more details see RFC 6241 section 7.7.

get [--help] [--filter-subtree [file] | --filter-xpath XPath]
    [--defaults report-all|report-all-tagged|trim|explicit] [--out file]
  • --filter-(s)ubtree [file] β€” says whether the request will carry a subtree filter (RFC 6241 section 6). The file is expected to contain the filter specification; if it's not specified, it's read from standard input.
  • --filter-(x)path *XPath* β€” says whether the request will carry an XPath filter. The XPath is the expression used for filtering.
  • --(d)efaults report-all|report-all-tagged|trim|explicit β€” use the :with-defaults capability with the specified retrieval mode. For more details see RFC 6243 section 3.

πŸ“₯ get-config

Performs the NETCONF <get-config> operation. Retrieves only configuration data from the specified source. For more details see RFC 6241 section 7.1.

get-config [--help] --source running|startup|candidate [--filter-subtree
           [file] | --filter-xpath XPath] [--defaults report-all|report-all-
           tagged|trim|explicit] [--out file]
  • --(s)ource running|startup|candidate β€” specifies the source of the <get-config> operation.
  • --filter-(s)ubtree [file] β€” says whether the request will carry a subtree filter (RFC 6241 section 6). The file is expected to contain the filter specification; if it's not specified, it's read from standard input.
  • --filter-(x)path *XPath* β€” says whether the request will carry an XPath filter. The XPath is the expression used for filtering.
  • --(d)efaults report-all|report-all-tagged|trim|explicit β€” use the :with-defaults capability with the specified retrieval mode. For more details see RFC 6243 section 3.

πŸ“₯ get-data

Performs the NMDA <get-data> operation. For more details see RFC 8526 section 3.1.1..

get-data [--help] --datastore running|startup|candidate|operational
         [--filter-subtree[=<file>] | --filter-xpath <XPath>] [--config
         true|false] [--origin <origin>]* [--negated-origin] [--depth
         <subtree-depth>] [--with-origin] [--defaults
         report-all|report-all-tagged|trim|explicit] [--out <file>]
         [--rpc-timeout <seconds>]
  • --(d)atastore running|startup|candidate|operational β€” selects the datastore to get the data of. πŸŽ€
  • --filter-(s)ubtree [file] β€” says whether the request will carry a subtree filter (RFC 6241 section 6). The file is expected to contain the filter specification; if it's not specified, it's read from standard input.
  • --filter-(x)path *XPath* β€” says whether the request will carry an XPath filter. The XPath is the expression used for filtering.
  • --(c)onfig true|false β€” limit the retrieved data to only configuration or only state data, respectively.
  • --(O)rigin *origin* β€” limit the retrieved data to include only the data with the specified origin. (Capital O, bestie, don't fumble it πŸ’…)
  • --(n)egated-origin β€” limit the retrieved data by origin, but don't include data with the specified origin.
  • --d(e)pth *subtree-depth* β€” limit the retrieved data to include only subtrees to the specified depth.
  • --(w)ith-origin β€” include the origin metadata in the retrieved data.
  • --de(f)aults report-all|report-all-tagged|trim|explicit β€” use the :with-defaults capability with the specified retrieval mode. For more details see RFC 6243 section 3.

πŸ“₯ get-schema

Performs the NETCONF <get-schema> operation, which retrieves a specified data model used by the server. This operation is available only if the server implements the YANG Module for NETCONF Monitoring. The list of available schemas can be retrieved from the /netconf-state/schemas subtree via the <get> operation. For more details see RFC 6022 sections 3.1 and 4.

get-schema [--help] --model identifier [--version version] [--format
           format] [--out file]
  • --(m)odel *identifier* β€” identifier for the schema list entry.
  • --(v)ersion *version* β€” version of the requested schema.
  • --(f)ormat *format* β€” the data modeling language (format) of the requested schema. Default value is yang.
  • --(o)ut *file* β€” print the result of the command into a file rather than to the standard output. (yes it's the o inside out, keep up πŸ¦‹)

πŸ“₯ help

Display list of commands. The --(h)elp option is also accepted by all commands to show detailed information about the command. when in doubt, ask for help, it's giving self-care ✨


πŸ’€ kill-session

Performs the NETCONF <kill-session> operation to terminate a specified NETCONF session. To terminate the current session, use the disconnect command instead. For more details see RFC 6241 section 7.9.

kill-session [--help] --sid sesion-ID
  • --(s)id *session-ID* β€” session identifier of the NETCONF session to be terminated.

πŸ’€ kill-sub

Performs the YANG notifications <kill-subscription> operation. For more details see RFC 8639 section 2.4.5..

kill-sub [--help] --id <sub-ID> [--out <file>] [--rpc-timeout <seconds>]
  • --(i)d *sub-ID* β€” ID of the subscription to kill. it's over bestie 🫢

knownhosts

Okay bestie, knownhosts is literally the backstage pass to your SSH host key list. It manages the user knownhosts file where all the known SSH server host keys are stored. πŸ’–

knownhosts (--help | --del <key_index> | --mode <accept|accept-
new|ask|skip|strict>)
  • --(d)el key_index β€” Remove a host key on a specific index. Super handy when the server host key changed and the client refuses to connect. But bestie, listen: unless the change is known (such as the key being newly generated), it is not safe to blindly trust a modified host key. 🚨
  • --(m)ode accept|accept-new|ask|skip|strict β€” Set the host key checking mode used when connecting over SSH.
    • accept β€” Add the host key to the knownhosts file without prompting and allow connections to servers that changed their host key. ✨
    • accept-new β€” Add the host key to the knownhosts file without prompting, but only if it is not already there. πŸ†•
    • ask β€” Prompt the user to accept the host key. This is the default mode. πŸ‘‘
    • skip β€” Skip the host key and do not add it to the knownhosts file. πŸ™ˆ
    • strict β€” Do not add the host key to the knownhosts file and refuse to connect to hosts whose host key is not known or has changed. πŸ’€

listen

Listen for a NETCONF Call Home connection. πŸ“ž

listen [--help] [--timeout sec] [--host hostname] [--port num] [--ssh]
[--login username] --tls  [--cert cert_path [--key key_path]] [--trusted
trusted_CA_store.pem]
  • --t(i)meout sec β€” Specifies the time for how long the CLI will listen for the Call Home connection. By default, 60 (a minute) is used. ⏱️
  • --h(o)st hostname β€” Specifies the hostname (interface) to listen on. By default, ::0 is used. 🌐

Other options? The rest of the options have similar meaning as in connect. iykyk πŸ’…


lock

Perform the NETCONF <lock> operation to lock the entire configuration datastore of a server. For more details see RFC 6241 section 7.5. πŸ”’

lock [--help] --target running|startup|candidate
  • --(t)arget running|startup|candidate β€” Target datastore to lock.. (yes, double period, we keep it exactly bestie) πŸ’–

modify-push

Perform YANG push <modify-subscription> operation. For more details see RFC 8641 section 4.4.2.. ✨

modify-push [--help] --id <sub-ID> --datastore
running|startup|candidate|operational [--filter-subtree[=<file>] |
--filter-xpath <XPath> | --filter-ref <name>] [--end <time>] (--periodic
--period <period> [--anchor-time <time>] |--on-change [--dampening-
period <period>]) [--out <file>] [--rpc-timeout <seconds>]
  • --(I)d sub-ID β€” ID of the subscription to modify. πŸ†”
  • --(d)atastore running|startup|candidate|operational β€” Modifies the datastore to subscribe to for YANG push updates. πŸ—„οΈ
  • --filter-(s)ubtree [file] β€” Modifies the subtree filter of the subscription. 🌳
  • --filter-(x)path XPath β€” Modifies the XPath filter of the subscription. 🧭
  • --(f)ilter-ref name β€” Modifies the referenced filter of the subscription. πŸ”—
  • --(e)nd time β€” Modifies the subscription end time. ⏳
  • --per(i)od period β€” Modifies the periodic push subscription period. πŸ”
  • --(a)nchor-time time β€” Modifies the periodic push subscription point in time to anchor the period to. βš“
  • --da(m)pening-period period β€” Modifies the on-change push subscription dampening period. 🌊

modify-sub

Perform YANG notifications <modify-subscription> operation. For more details see RFC 8639 section 2.4.3.. πŸ’Œ

modify-sub [--help] --id <sub-ID> [--filter-subtree[=<file>] |
--filter-xpath <XPath> | --filter-ref <name>] [--end <time>] [--out
<file>] [--rpc-timeout <seconds>]
  • --(i)d sub-ID β€” ID of the subscription to modify. πŸ†”
  • --filter-(s)ubtree [file] β€” Specifies whether the request will contain a subtree filter (RFC 6241 section 6). The file is expected to contain the filter specification. If it is not specified, it is read from standard input. 🌳
  • --filter-(x)path XPath β€” Specifies whether the request will contain an XPath filter. XPath is the expression used for filtering. 🧭
  • --(f)ilter-ref name β€” Specifies whether the request will contain a referenced stored filter. πŸ”—
  • --(e)nd time β€” Specifies when the event replay stops. Format of the time parameter is as follows:
    • +time β€” Current time plus the given number of seconds.
    • time β€” Absolute time as number of seconds since 1970-01-01.
    • -time β€” Current time minus the given number of seconds.

monitor

Monitor the client connection status. πŸ‘€

monitor [--help] [on | off]

outputformat

Set the format for all the output data. XML is the default. 🎨

outputformat (xml | xml_noformat | json)

resync-sub

Perform YANG push <resync-subscription> operation. For more details see RFC 8641 section 4.4.4.. πŸ”„

resync-sub [--help] --id <sub-ID> [--out <file>] [--rpc-timeout
<seconds>]
  • --(i)d sub-ID β€” ID of the on-change subscription to resync. πŸ†”

searchpath

Set the directory, which will be used when searching for modules. Modules are always needed to be able to work with the same data as a NETCONF server. They are searched locally (in this directory) only if the server does not support the <get-schema> NETCONF operation. If it does, all the modules (except ietf-netconf-monitoring, which includes the definition of the <get-schema> RPC itself) are downloaded from the server. πŸ—‚οΈ

searchpath model-dir-path

status

Print information about the current NETCONF session. πŸ“Š


subscribe

Perform NETCONF Event Notifications <create-subscription> operation. For more details see RFC 5277 section 2.1.1. πŸ””

subscribe [--help] [--filter-subtree [file] | --filter-xpath XPath]
[--begin time] [--end time] [--stream stream] [--out file]
  • --filter-(s)ubtree [file] β€” Specifies whether the request will contain a subtree filter (RFC 6241 section 6). The file is expected to contain the filter specification. If it is not specified, it is read from standard input. 🌳
  • --filter-(x)path XPath β€” Specifies whether the request will contain an XPath filter. XPath is the expression used for filtering. 🧭
  • --(b)egin time β€” Start to replay event notifications from past (future time is not valid). If the start time is not specified, replay feature is not activated and only new event notifications are received. Format of the time parameter is described below. βͺ
  • --(e)nd time β€” Specifies when the event replay stops. Format of the time parameter is as follows:
    • +time β€” Current time plus the given number of seconds.
    • time β€” Absolute time as number of seconds since 1970-01-01.
    • -time β€” Current time minus the given number of seconds.
  • --s(t)ream stream β€” Specifies which event stream is of the interest. If not specified, default NETCONF stream is received. The list of available streams can be retrieved from /netconf/streams subtree via the <get> operation. 🌊

timed

Time all the commands (that communicate with a server) from issuing an RPC to getting a reply. ⏱️

timed [--help] on|off

unlock

Perform the NETCONF <unlock> operation to release a configuration lock, previously obtained with the <lock> operation. For more details see RFC 6241 section 7.6. πŸ”“

lock [--help] --target running|startup|candidate
The synopsis says lock but this is the unlock command β€” we keep it exactly as the manpage says, bestie. πŸ’…
  • --(t)arget running|startup|candidate β€” Target datastore to unlock.

user-rpc

Send your own content in an RPC envelope. βœ‰οΈ

user-rpc [--help] [--content file] [--out file]
  • --(c)ontent file β€” Specifies a file containing NETCONF RPC operation in XML format. Only the NETCONF <rpc> envelope is added to the file content and then it is sent to a server. If the file is omitted, the RPC content is read from the standard input. πŸ“„
  • --(o)ut file β€” Print the command result into a file rather than to the standard output. πŸ’Ύ

validate

Perform the NETCONF <validate> operation to validate configuration data. For more details see RFC 6241 section 8.6.4.1. βœ…

validate [--help] (--source running|startup|candidate|url:url | --src-
config [file])
  • --(s)ource running|startup|candidate|url:url β€” Specifies the source of the <validate> operation. Either a datastore or a specific URL can be specified. πŸ—„οΈ
  • --src-(c)onfig [file] β€” Specifies the source of the <validate> operation. If a file with the configuration is not specified, the configuration is read from the standard input. πŸ“₯

verb

Set CLI verbosity. Only errors are printed by default. πŸ—£οΈ

verb (error/0 | warning/1 | verbose/2 | debug/3)

version

Print the CLI version. 🏷️


?

Display list of commands. --(h)elp option is also accepted by all commands to show detailed information about the command. ❓


quit

Quit the program. πŸ‘‹


πŸ“ FILES πŸ“

  • ~/.netopeer2-cli/config.xml β€” Per user configuration for NETCONF <hello> message (see RFC 6241 for further details). πŸ“
  • ~/.netopeer2-cli/history β€” Per user history of executed commands. πŸ•°οΈ
  • ~/.netopeer2-cli/client.pem β€” Per user certificate with its private key that is sent to the server for verification. If present together with client.crt and client.key it is not utilized. Only with TLS support. πŸ”
  • ~/.netopeer2-cli/client.crt β€” Per user certificate that is sent to the server for verification. Needs a corresponding private key to be utilized. Only with TLS support. πŸ“œ
  • ~/.netopeer2-cli/client.key β€” Per user private key for the user certificate. Needs a corresponding certificate to be utilized. Only with TLS support. πŸ”‘
  • ~/.netopeer2-cli/certs β€” Per user trusted Certificate Authority directory that is searched when verifying a server certificate. Only with TLS support. πŸ›οΈ

πŸ‘€ SEE ALSO πŸ‘€


πŸ’– AUTHORS πŸ’–

  • Michal Vasko <mvasko@cesnet.cz>
  • Radek Krejci <rkrejci@cesnet.cz>

  • Copyright Β© 2012-2022 CESNET, a.l.e.
  • Copyright Β© 2018-2022 Deutsche Telekom AG.

And that's the whole vibe check, bestie! This iconic manual page comes from Netopeer, dated 2022-11-25, and it's the netopeer2-cli(1) manpage. Slay! πŸ’…βœ¨

πŸ“¦ where this page comes from