netconf-console2
================
A console application for interacting with NETCONF servers built on top
of `ncclient <http://https://pypi.org/project/ncclient/>`__.
*Note:* this is a continuation (or a rename) of the project
``netconf-console``; the old name was clashing with another product. Use
``netconf-console2`` instead of ``netconf-console``.
Requirements and installation
-----------------------------
This application runs both in Python 2 and Python 3 environments. The
only package required for running this application is ``ncclient``; if
this is installed, all other necessary packages are installed as
dependencies. This means that if you can (successfully) run something
like ``pip install ncclient`` on the target platform, all requirements
should be met.
If you cannot, there still is a chance you can run it if the target platform
supports at least packages ``six`` and ``lxml``, which are commonly present;
and if it contains ``paramiko`` or at least ``cryptography``, you will be able
to use SSH (without them you can only use plain and nonstandard TCP
transport). The missing piece, ``ncclient``, can be `cloned
<https://github.com/ncclient/ncclient>`__ and compiled to a "Python Wheel" -
you can do this on any computer and copy the resulting ``.whl`` file to the
target platform, it should work there. Pretty much the same holds for
``paramiko``. You may also want to create a wheel for the application itself by
running ``python setup.py bdist_wheel``.
Installing and running the application
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you can and want to install the application and all necessary
libraries, just run ``python setup.py install``. Otherwise prepare all
necessary .whl files and the script ``netconf-console2`` to the target
platform. If they are in the same directory, nothing else is needed,
otherwise you may need to add the wheel files to ``PYTHONPATH`` before
running the script.
Once installed or copied, you can just run the script with appropriate
options - see below.
Command-line mode
-----------------
The application can be run in two different modes: command-line mode and
interactive (console) mode. The command-line mode allows you to request
several RPC operations in one shell command. The command line would
contain the operation command options (``--get``, ``--lock``, etc.) in
the desired order, all common options (such as ``--host``, ``--port``
etc.) as well as command options (``--db``, ``--style``); the command
options are all used for the commands that accept them, so for example
no two commands can address different datastores.
An example of such command line:
::
# netconf-console2 --host=example.com --db candidate --lock --edit-config=fragment1.xml \
--rpc=commit-confirmed.xml --unlock --sleep 5 --rpc=confirm.xml
Interactive mode
----------------
The interactive mode is started by ``--interactive`` (or ``-i``). During
an interactive session the user issues commands, one per line, with
required arguments or options. The options are isolated now, so it is
possible to have two commands in one session accessing different
datastores. The interactive console provides limited support for
tab-completion of commands, options, and their arguments.
The previous example can look like this:
::
# netconf-console2 --host=example.com -i
netconf> lock
netconf> edit-config fragment1.xml --db candidate
netconf> rpc commit-confirmed.xml
netconf> unlock
netconf> get-config
netconf> rpc confirm.xml
netconf>
Note: some commands (``rpc``, ``edit-config`` and others) may accept
data from standard input in the command-line mode; this does not work in
the interactive mode.
Some capabilities of the interactive mode can be used in command-line
mode too using ``--expr`` pseudo-command: the argument is a command
(including options) as if it was added in the interactive mode, such as
::
# netconf-console2 --expr 'get-config --db candidate' 'get-config'
Commands
--------
A command may accept an argument and a number of options. In
command-line mode, all option values are shared (see above); conversely,
in interactive mode the option needs to be provided for every command
where its desired value differs from the default. If a command does not
accept given option, it is a syntax error to provide it in interactive
mode (in command-line mode such situations are ignored).
``hello``
Send just the initial ``hello`` message and display the reply. Does
not accept any arguments or options.
``get``
Send ``get`` RPC. Accepts options ``outputStyle``, ``with-defaults``,
``xpath``. As an alternative to ``xpath``, ``get`` accepts path as an
argument.
``get-config``
Send ``get-config`` RPC. Accepts the same set of options as ``get``
plus ``db``.
``set``
Send ``edit-config`` with single leaf assignment. Requires the assignment
in the form ``<path>=<value>`` as an argument, accepts ``db``, ``test``,
and ``operation``. The path may contain (or actually needs to contain, in
case it descends into a list instance) simple predicates in the form
``node[key1=value1][key2=value2]...``.
``delete``
Sends ``edit-config`` with a single node to be deleted. The node is
determined by the path provided as an argument, see ``set`` for the path
format. Accepts ``db``, ``test``, and ``del-operation`` options.
``create``
Sends ``edit-config`` with a single node to be created. The node is
determined by the path provided as an argument, see ``set`` for the path
format.
``kill-session``
Send ``kill-session`` RPC. Requires session identifier as an
argument, accepts no options.
``discard-changes``
Send ``discard-changes`` RPC. Accepts no arguments or options.
``lock``
Send ``lock`` RPC towards the datastore indicated by ``db`` option.
``unlock``
Send ``unlock`` RPC, counterpart of ``lock``.
``commit``
Send ``commit`` request. Accepts optional ``confirmed`` as an
argument and option ``timeout``.
``validate``
Send ``validate`` RPC. Accepts one argument, which can be either the
literal ``candidate`` (to validate the contents of the candidate
datastore) or a filename pointing to a file with full configuration
to be validated; defaults to ``-``, standard input.
``copy-running-to-startup``
Send ``copy-config`` RPC with ``running`` datastore as the source
and ``startup`` datastore as target. Accepts no arguments or
options.
``copy-config``
Send ``copy-config`` RPC. Accepts a filename for the source
configuration as a argument (defaults to ``-``), and the ``db``
option for the target datastore.
``edit-config``
Send ``edit-config`` RPC. Accepts the same set of arguments and
options as ``copy-config``.
``get-schema``
Send ``get-schema`` RPC. Requires schema identifier as an argument.
``create-subscription``
Send ``create-subscription`` RPC. Requires notification stream
identifier as an argument. The notifications received from the
server are displayed on standard output while the session is active
- i.e. makes sense either in an interactive mode or in command-line
mode with the command ``sleep``.
``rpc``
If none of the commands above is sufficient, a custom RPC can be
send using this command. Accepts a filename (or ``-`` as default) as
an argument; the file contents is sent to the server enveloped in
the ``rpc`` element.
``sleep``
Do nothing, just sleep for given number of seconds provided as an
argument.
As a backward-compatibility option, it is possible to provide a filename (or
``-`` for standard input) containing all messages that are supposed to be sent
to the server, separated by the NETCONF transport v1.0 message separator. This
option cannot be used with any other command. Note that RPC message-id is not
preserved.
Options
-------
There are two sets of options: global options and command options.
Global options affect overall behavior of the tool and can be provided
in the shell command line (i.e. not to individual commands in the
interactive mode). Command options affect individual commands and in
interactive mode they need to be provided per command.
Global options
~~~~~~~~~~~~~~
``help``
Display a usage message and exit.
``host``
Hostname or IP address of the NETCONF server.
``port``
Port number of the NETCONF server.
``user``
Username for the authentication on the server (defaults to
``admin``).
``password``
Password for the authentication on the server (defaults to
``admin``). If the option is provided without a value, the password
is read from the terminal.
``privKeyFile``
File containing the user's private key.
``raw``
Print all received replies in the original form. The option accepts
one argument, name of file where the text should be stored; defaults
to standard output.
``tcp``
Use plain TCP for the communication with the server (without this
option SSH is used).
``dry``
Do not actually send any RPCs, just display them to standard output.
Local options
~~~~~~~~~~~~~
As written above, local (or command) options are meaningful only for
certain command.
``outputStyle``
Affects the format of the displayed RPC reply. By default, the reply
is pretty-printed, but otherwise kept as is. The option accepts
``plain`` (do no pretty-printing) and ``noaaa`` (remove the ``aaa``
subtree from the reply from ``get`` or ``get-config`` requests).
``db``
Target datastore for some of the RPC operations. Defaults to
``running``.
``timeout``
Timeout in seconds for confirmed commit.
``with-defaults``
Set default values handling. Accepted values are ``explicit``,
``trim``, ``report-all``, ``report-all-tagged``.
``xpath``
Set the XPath filter for get or subscribe requests.
``ns``
Set a namespace prefix list; useful in case ``xpath`` option uses
namespace prefixes.
``test``
Test-option value. Accepted values are ``test-only``,
``test-then-set`` and ``set``.
``operation``
Value of the attribute ``nc:operation``. Useful with the ``set``
operation, can be ``merge`` (the default), ``replace``, ``create``.
``del-operation``
Value of the attribute ``nc:operation`` when used with the ``delete``
operation, can be ``remove`` (the default) or ``delete``.
Raw data
{
"_id": null,
"home_page": "https://bitbucket.org/martin_volf/ncc",
"name": "netconf-console2",
"maintainer": null,
"docs_url": null,
"requires_python": null,
"maintainer_email": null,
"keywords": "NETCONF CLI client",
"author": "Martin Volf",
"author_email": "martin.volf@cetin.cz",
"download_url": null,
"platform": null,
"description": "netconf-console2\n================\n\nA console application for interacting with NETCONF servers built on top\nof `ncclient <http://https://pypi.org/project/ncclient/>`__.\n\n*Note:* this is a continuation (or a rename) of the project\n``netconf-console``; the old name was clashing with another product. Use\n``netconf-console2`` instead of ``netconf-console``.\n\nRequirements and installation\n-----------------------------\n\nThis application runs both in Python 2 and Python 3 environments. The\nonly package required for running this application is ``ncclient``; if\nthis is installed, all other necessary packages are installed as\ndependencies. This means that if you can (successfully) run something\nlike ``pip install ncclient`` on the target platform, all requirements\nshould be met.\n\nIf you cannot, there still is a chance you can run it if the target platform\nsupports at least packages ``six`` and ``lxml``, which are commonly present;\nand if it contains ``paramiko`` or at least ``cryptography``, you will be able\nto use SSH (without them you can only use plain and nonstandard TCP\ntransport). The missing piece, ``ncclient``, can be `cloned\n<https://github.com/ncclient/ncclient>`__ and compiled to a \"Python Wheel\" -\nyou can do this on any computer and copy the resulting ``.whl`` file to the\ntarget platform, it should work there. Pretty much the same holds for\n``paramiko``. You may also want to create a wheel for the application itself by\nrunning ``python setup.py bdist_wheel``.\n\nInstalling and running the application\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nIf you can and want to install the application and all necessary\nlibraries, just run ``python setup.py install``. Otherwise prepare all\nnecessary .whl files and the script ``netconf-console2`` to the target\nplatform. If they are in the same directory, nothing else is needed,\notherwise you may need to add the wheel files to ``PYTHONPATH`` before\nrunning the script.\n\nOnce installed or copied, you can just run the script with appropriate\noptions - see below.\n\nCommand-line mode\n-----------------\n\nThe application can be run in two different modes: command-line mode and\ninteractive (console) mode. The command-line mode allows you to request\nseveral RPC operations in one shell command. The command line would\ncontain the operation command options (``--get``, ``--lock``, etc.) in\nthe desired order, all common options (such as ``--host``, ``--port``\netc.) as well as command options (``--db``, ``--style``); the command\noptions are all used for the commands that accept them, so for example\nno two commands can address different datastores.\n\nAn example of such command line:\n\n::\n\n # netconf-console2 --host=example.com --db candidate --lock --edit-config=fragment1.xml \\\n --rpc=commit-confirmed.xml --unlock --sleep 5 --rpc=confirm.xml\n\nInteractive mode\n----------------\n\nThe interactive mode is started by ``--interactive`` (or ``-i``). During\nan interactive session the user issues commands, one per line, with\nrequired arguments or options. The options are isolated now, so it is\npossible to have two commands in one session accessing different\ndatastores. The interactive console provides limited support for\ntab-completion of commands, options, and their arguments.\n\nThe previous example can look like this:\n\n::\n\n # netconf-console2 --host=example.com -i\n netconf> lock\n netconf> edit-config fragment1.xml --db candidate\n netconf> rpc commit-confirmed.xml\n netconf> unlock\n netconf> get-config\n netconf> rpc confirm.xml\n netconf>\n\nNote: some commands (``rpc``, ``edit-config`` and others) may accept\ndata from standard input in the command-line mode; this does not work in\nthe interactive mode.\n\nSome capabilities of the interactive mode can be used in command-line\nmode too using ``--expr`` pseudo-command: the argument is a command\n(including options) as if it was added in the interactive mode, such as\n\n::\n\n # netconf-console2 --expr 'get-config --db candidate' 'get-config'\n\nCommands\n--------\n\nA command may accept an argument and a number of options. In\ncommand-line mode, all option values are shared (see above); conversely,\nin interactive mode the option needs to be provided for every command\nwhere its desired value differs from the default. If a command does not\naccept given option, it is a syntax error to provide it in interactive\nmode (in command-line mode such situations are ignored).\n\n``hello``\n Send just the initial ``hello`` message and display the reply. Does\n not accept any arguments or options.\n\n``get``\n Send ``get`` RPC. Accepts options ``outputStyle``, ``with-defaults``,\n ``xpath``. As an alternative to ``xpath``, ``get`` accepts path as an\n argument.\n\n``get-config``\n Send ``get-config`` RPC. Accepts the same set of options as ``get``\n plus ``db``.\n\n``set``\n Send ``edit-config`` with single leaf assignment. Requires the assignment\n in the form ``<path>=<value>`` as an argument, accepts ``db``, ``test``,\n and ``operation``. The path may contain (or actually needs to contain, in\n case it descends into a list instance) simple predicates in the form\n ``node[key1=value1][key2=value2]...``.\n\n``delete``\n Sends ``edit-config`` with a single node to be deleted. The node is\n determined by the path provided as an argument, see ``set`` for the path\n format. Accepts ``db``, ``test``, and ``del-operation`` options.\n\n``create``\n Sends ``edit-config`` with a single node to be created. The node is\n determined by the path provided as an argument, see ``set`` for the path\n format.\n\n``kill-session``\n Send ``kill-session`` RPC. Requires session identifier as an\n argument, accepts no options.\n\n``discard-changes``\n Send ``discard-changes`` RPC. Accepts no arguments or options.\n\n``lock``\n Send ``lock`` RPC towards the datastore indicated by ``db`` option.\n\n``unlock``\n Send ``unlock`` RPC, counterpart of ``lock``.\n\n``commit``\n Send ``commit`` request. Accepts optional ``confirmed`` as an\n argument and option ``timeout``.\n\n``validate``\n Send ``validate`` RPC. Accepts one argument, which can be either the\n literal ``candidate`` (to validate the contents of the candidate\n datastore) or a filename pointing to a file with full configuration\n to be validated; defaults to ``-``, standard input.\n\n``copy-running-to-startup``\n Send ``copy-config`` RPC with ``running`` datastore as the source\n and ``startup`` datastore as target. Accepts no arguments or\n options.\n\n``copy-config``\n Send ``copy-config`` RPC. Accepts a filename for the source\n configuration as a argument (defaults to ``-``), and the ``db``\n option for the target datastore.\n\n``edit-config``\n Send ``edit-config`` RPC. Accepts the same set of arguments and\n options as ``copy-config``.\n\n``get-schema``\n Send ``get-schema`` RPC. Requires schema identifier as an argument.\n\n``create-subscription``\n Send ``create-subscription`` RPC. Requires notification stream\n identifier as an argument. The notifications received from the\n server are displayed on standard output while the session is active\n - i.e. makes sense either in an interactive mode or in command-line\n mode with the command ``sleep``.\n\n``rpc``\n If none of the commands above is sufficient, a custom RPC can be\n send using this command. Accepts a filename (or ``-`` as default) as\n an argument; the file contents is sent to the server enveloped in\n the ``rpc`` element.\n\n``sleep``\n Do nothing, just sleep for given number of seconds provided as an\n argument.\n\nAs a backward-compatibility option, it is possible to provide a filename (or\n``-`` for standard input) containing all messages that are supposed to be sent\nto the server, separated by the NETCONF transport v1.0 message separator. This\noption cannot be used with any other command. Note that RPC message-id is not\npreserved.\n\n\nOptions\n-------\n\nThere are two sets of options: global options and command options.\nGlobal options affect overall behavior of the tool and can be provided\nin the shell command line (i.e. not to individual commands in the\ninteractive mode). Command options affect individual commands and in\ninteractive mode they need to be provided per command.\n\nGlobal options\n~~~~~~~~~~~~~~\n\n``help``\n Display a usage message and exit.\n\n``host``\n Hostname or IP address of the NETCONF server.\n\n``port``\n Port number of the NETCONF server.\n\n``user``\n Username for the authentication on the server (defaults to\n ``admin``).\n\n``password``\n Password for the authentication on the server (defaults to\n ``admin``). If the option is provided without a value, the password\n is read from the terminal.\n\n``privKeyFile``\n File containing the user's private key.\n\n``raw``\n Print all received replies in the original form. The option accepts\n one argument, name of file where the text should be stored; defaults\n to standard output.\n\n``tcp``\n Use plain TCP for the communication with the server (without this\n option SSH is used).\n\n``dry``\n Do not actually send any RPCs, just display them to standard output.\n\nLocal options\n~~~~~~~~~~~~~\n\nAs written above, local (or command) options are meaningful only for\ncertain command.\n\n``outputStyle``\n Affects the format of the displayed RPC reply. By default, the reply\n is pretty-printed, but otherwise kept as is. The option accepts\n ``plain`` (do no pretty-printing) and ``noaaa`` (remove the ``aaa``\n subtree from the reply from ``get`` or ``get-config`` requests).\n\n``db``\n Target datastore for some of the RPC operations. Defaults to\n ``running``.\n\n``timeout``\n Timeout in seconds for confirmed commit.\n\n``with-defaults``\n Set default values handling. Accepted values are ``explicit``,\n ``trim``, ``report-all``, ``report-all-tagged``.\n\n``xpath``\n Set the XPath filter for get or subscribe requests.\n\n``ns``\n Set a namespace prefix list; useful in case ``xpath`` option uses\n namespace prefixes.\n\n``test``\n Test-option value. Accepted values are ``test-only``,\n ``test-then-set`` and ``set``.\n\n``operation``\n Value of the attribute ``nc:operation``. Useful with the ``set``\n operation, can be ``merge`` (the default), ``replace``, ``create``.\n\n``del-operation``\n Value of the attribute ``nc:operation`` when used with the ``delete``\n operation, can be ``remove`` (the default) or ``delete``.\n\n\n\n",
"bugtrack_url": null,
"license": "MIT",
"summary": "Netconf client CLI tool and interactive console",
"version": "3.0.1",
"project_urls": {
"Homepage": "https://bitbucket.org/martin_volf/ncc"
},
"split_keywords": [
"netconf",
"cli",
"client"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "4e85aa1c8fd6a7ec954023caf603762fa0b793506f0ca5cf4dd4fecd3342a2a5",
"md5": "4079c7b8c9557d5bc10a90aed1113bd2",
"sha256": "be96f993e50f85da264b59c9ab470ba6db5e1948bb843d7bf9242c1a1810a7e7"
},
"downloads": -1,
"filename": "netconf_console2-3.0.1-py2.py3-none-any.whl",
"has_sig": false,
"md5_digest": "4079c7b8c9557d5bc10a90aed1113bd2",
"packagetype": "bdist_wheel",
"python_version": "py2.py3",
"requires_python": null,
"size": 19528,
"upload_time": "2024-05-17T10:51:50",
"upload_time_iso_8601": "2024-05-17T10:51:50.159855Z",
"url": "https://files.pythonhosted.org/packages/4e/85/aa1c8fd6a7ec954023caf603762fa0b793506f0ca5cf4dd4fecd3342a2a5/netconf_console2-3.0.1-py2.py3-none-any.whl",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-05-17 10:51:50",
"github": false,
"gitlab": false,
"bitbucket": true,
"codeberg": false,
"bitbucket_user": "martin_volf",
"bitbucket_project": "ncc",
"lcname": "netconf-console2"
}
JSON