netconfd-pro CLI Reference

--access-control

The --access-control parameter specifies how access control is enforced in the netconfd-pro program.

It is an enumeration with the following values:

enforcing: All configured access control rules will be enforced.
permissive: All configured access control rules will be enforced for write and execute requests. All read requests will be allowed, unless the requested object contains the nacm:default-deny-all extension. In that case, all configured access control rules will be enforced, and no default access will be allowed.
disabled: All read, write, and execute requests will be allowed, unless the object contains the nacm:default-deny-write or nacm:default-deny-all extension.
- If the nacm:default-deny-write extension is in effect, then all configured access control rules will be enforced for write and execute requests.
- If the nacm:default-deny-all extension is in effect, then all configured access control rules will be enforced for all requests. Use this mode with caution.
off: All access control enforcement is disabled. Use this mode with extreme caution.
- Debug: normally set this parameter to off unless the testing requires NACM.

leaf access-control {
  type ywt:access-control-mode;
  default enforcing;
}

Syntax	enumeration: enforcing permissive disabled off
Default:	enforcing
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --access-control=permissive

--allow-leaflist-delete-all

The --allow-leaflist-delete-all parameter controls whether the YumaPro extension “delete-all” operation should be allowed for leaf-list objects. This parameter affects the <edit-config> operation.

If 'true', then the client can send nc:operation=”delete-all” or nc:operation=”remove-all”, and the server will accept the edit if the target node is a leaf-list object. Do not provide a value for the leaf-list.

If 'false' then the "delete-all" and "remove-all" operations are disabled for leaflists.

leaf allow-leaflist-delete-all {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Recommend:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --allow-leaflist-delete-all=true

--allow-list-delete-all

The --allow-list-delete-all parameter controls whether the YumaPro extension “delete-all” operation should be allowed for list objects. This parameter affects the <edit-config> operation.

If 'true', then the client can send nc:operation=”delete-all” or nc:operation=”remove-all”, and the server will accept the edit if the target node is a list object. The key leaf values should not be provided.

If 'false' then the "delete-all" and "remove-all" operations are disabled for lists.

leaf allow-list-delete-all {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Recommend:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --allow-list-delete-all=true

--allowed-user

The --allowed-user parameter specifies a set of user names that are allowed to login and use the server.

If none are configured then this parameter will have no effect on access control.
If the “superuser” account name is configured, then logins to the superuser account will bypass access control and not be checked against the allowed-user list.
If any allowed-user names are configured, then the user name for a new session must be in the configured allowed-user list. If not, then the session will be denied with an NCX_ERR_ACCESS_DENIED status code.
Refer to the Session Admission Control section for more details.

leaf-list allowed-user {
  type nt:NcxName;
}

Syntax	string (NcxName)
Default:	none
Min Allowed:	0
Max Allowed:	no limit
Supported by:	netconfd-pro
Example:	netconfd-pro --allowed-user=fred allowed-user=barney allowed-user=admin

--annotation

The --annotation parameter is a leaf-list of modules that should be loaded automatically when the program starts, as a deviation module containing annotations. In this mode, only the deviation statements are parsed and then made available later when the module that contains the objects being deviated is parsed. The annotation file is not advertised to clients or shown in the YANG library.

Note

An annotation module is the same as a deviation module except it is not visible to clients. It should only be used when the client does not need the information.

The following example module shows how an annotation such as ncx:sil-delete-children-first could be added to the ietf-interfaces.yang module:

module devtest1-d {

  namespace "http://netconfcentral.org/ns/devtest1-d";
  prefix dt1-d;
  import ietf-interfaces { prefix if; }
  import yuma-ncx { prefix ncx; }

  revision "2016-04-10";

  deviation /if:interfaces {
    deviate add {
      ncx:sil-delete-children-first;
    }
  }

  deviation /if:interfaces/if:interface {
    deviate add {
      ncx:sil-delete-children-first;
    }
  }
}

The program will attempt to load each module in annotation parsing mode, in the order the parameters are entered. All deviation parameters will be processed, then all annotation parameters. An annotation module is just a YANG module that contains only 'deviation' statements with “deviate add” sub-statements.

leaf-list annotation {
    type yt:NcModuleSpec;
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	unlimited
Supported by:	netconfd-pro
Example:	netconfd-pro --annotation=devtest1-d

--audit-log

The --audit-log parameter specifies the file path of the configuration edit audit log. If this parameter is present, then edits to the running database will cause an audit log entry to be created for each edit point. This is done in addition to normal logging, but it is not affected by the --log-level parameter. The --no-audit-log parameter cannot be present if this parameter is present. The --audit-log-events parameter selects the event types that are recorded in the audit log file.

choice audit-log-choice {
  leaf audit-log {
    type string;
  }
  leaf no-audit-log {
    type empty;
  }
}

Syntax	filespec
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --audit-log=/var/log/nc-audit.log

--audit-log-append

The --audit-log-append parameter specifies that the existing audit log file (if any) should be appended, instead of deleted. It is ignored unless the --audit-log parameter is present.

leaf audit-log-append {
  type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --audit-log=/var/log/ncaudit.log --audit-log-append

--audit-log-candidate

The --audit-log-candidate parameter specifies whether edit transactions on the candidate datastore are recorded in the audit log or not. If true, then edits to the candidate datastore are recorded. If false, then edits to the candidate datastore are not recorded.

leaf audit-log-candidate {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --audit-log=/var/log/ncaudit.log --audit-log-candidate=false

--audit-log-console-level

The --audit-log-console-level parameter controls the minimum logging level needed to log datastore audit records to the server console log. This does not affect output to the audit log.

This parameter uses the same values as the --log-level parameter.

leaf audit-log-console-level {
  type nt:NcDebugType;
  default debug;
}

Syntax	enumeration: off error warn info debug debug2 debug3 debug4
Default:	debug
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --audit-log-console-level=info

--audit-log-events

The --audit-log-events parameter controls the event types that are output to the audit log. It has no effect unless the audit-log is enabled.

Debug: make sure this parameter includes the 'rpc-error' bit. This bit was introduced in the 23.10-6 release.

This parameter uses the YANG “bits” type, so any combination of the following bit definitions are permitted:

leaf audit-log-events {
  type bits {
    bit edit-candidate {
      description
        "Save candidate datastore edit events in the audit log.
         If the --audit-log-candidate parameter is set to true,
         or the <candidate> datastore is not present, then this
         bit will be ignored.";
    }
    bit edit-running {
      description
        "Save running datastore edit events in the audit log";
    }
    bit update-startup {
      description
        "Save startup datastore update events in the audit log.
         If the <startup> datastore is not present then this
         bit will be ignored.";
    }
    bit client-session {
      description
       "Save client session start and end events in the audit log";
    }
    bit control-session {
      description
       "Save YControl session start and end events in the audit log";
    }
    bit acm-write-error {
      description
       "Save access control write access denied events in
        the audit log";
    }
    bit acm-exec-error {
      description
       "Save access control execute access denied events in
        the audit log";
    }
    bit rpc-summary {
      description
       "Save <rpc> summary records in the audit log.";
    }
    bit edit-data {
      description
       "Add plain display output of the data that is being
        edited in an edit transaction. This bit has no effect
        unless the edit-candidate or edit-running bit is
        also set.

        Note that this added data could represent a security risk
        since it could expose sensitive configuration data contents.
        Use this option with caution!";
    }
    bit rpc-error {
      description
        "Add an audit record for an RPC operation that causes
         an 'rpc-error' element to be returned to the client.


         If the 'rpc-summary' bit is enabled, then an rpc-error
         report will be added to the RPC summary records that
         have a 'status' or 'error'.

         If the 'rpc-summary' bit is not enabled then an RPC summary
         with rpc-error report will be added for RPC operations
         that cause an error to be returned.";
    }
  }
  default "edit-running";
}

Syntax	bits: edit-candidate edit-running update-startup client-session control-session acm-write-error acm-exec-error rpc-summary edit-data rpc-error
Default:	edit-running
Recommend:	edit-running rpc-error
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --audit-log-events=”edit-candidate edit-data edit-running client-session”

edit-candidate Audit Event

Save candidate datastore edit events in the audit log.

If the --audit-log-candidate parameter is set to true, or the <candidate> datastore is not present, then this bit will be ignored.

By default, the --audit-log-candidate parameter is set to “true” so this event type will be present in the audit log by default. To remove these events, set --audit-log-candidate=false and do not set this bit.

Example audit log entry:

edit-transaction 9616: on session 3 by [email protected]
  time: 2018-09-04T20:44:44Z
  message-id: 2
  trace-id: --
  datastore: candidate
  operation: create
  target: /t:int16.1
  comment: none

edit-running Audit Event

Save running datastore edit events in the audit log.

Example audit log entry:

edit-transaction 9617: on session 3 by [email protected]
  time: 2018-09-04T20:44:47Z
  message-id: 3
  trace-id: --
  datastore: running
  operation: create
  target: /t:int16.1
  comment: none

update-startup Audit Event

Save startup datastore update events in the audit log. If the <startup> datastore is not present then this bit will be ignored.

Example audit log entry:

update-startup on session 3 by [email protected]
  time: 2018-09-04T20:44:52Z
  message-id: 5
  sourcetype: datastore
  source: running

client-session Audit Event

Save client session start and end events in the audit log.

Example audit log entry (start-client-session)

start-client-session:
  time: 2018-09-04T20:44:31Z
  protocol: NETCONF
  transport: netconf-ssh
  username: andy
  peeraddr: 127.0.0.1
  session ID: 3

Example audit log entry (end-client-session)

end-client-session:
  time: 2018-09-04T20:50:23Z
  protocol: NETCONF 1.1
  transport: netconf-ssh
  username: andy
  peeraddr: 127.0.0.1
  session ID: 3
  term reason: closed
  killed-by: 3

control-session Audit Event

Save YControl session start and end events in the audit log.

Example audit log entry (start-control-session)

start-control-session:
  time: 2018-09-04T20:53:59Z
  protocol: YControl
  transport: netconf-aflocal
  username: andy
  peeraddr: 127.0.0.1
  session ID: 3

Example audit log entry (end-control-session)

end-control-session:
  time: 2018-09-04T21:02:39Z
  protocol: YControl
  transport: netconf-aflocal
  username: andy
  peeraddr: 127.0.0.1
  session ID: 3
  term reason: dropped
  killed-by: 0

acm-write-error Audit Event

Save access control write access denied events in the audit log.

Example audit log entry:

nacm-write-error:
  time: 2018-09-04T21:04:51Z
  username: andy
  operation: create leaf int32.1
  path:: /t:int32.1

acm-exec-error Audit Event

Save access control execute access denied events in the audit log.

Example audit log entry:

nacm-exec-error:
  time: 2018-09-04T21:08:54Z
  username: andy
  module name: yumaworks-system
  RPC name: load

rpc-summary Audit Event

Save RPC summary events in the audit log.

Example audit log entry:

RPC <get> on session 3 by* [email protected]
  start-time: 2019-12-12T01:35:47Z
  end-time: 2019-12-12T01:35:47Z
  message-id: 2
  reply-type: data
  status: 0:ok

edit-data Audit Event

Add plain display output of the data that is being edited in an edit transaction. This bit has no effect unless the edit-candidate or edit-running bit is also set.

Warning

This added data could represent a security risk since it could expose sensitive configuration data contents. Use this option with caution.

The ‘new value’ data will be added if the edit has a new value (create, modify).
The ‘current value’ will be added if the edit has a current value (modify, delete)

Example audit log entries for create a leaf “uint16.1”:

edit-transaction 187: on session 3 by [email protected]
  time: 2020-06-06T01:19:52Z
  message-id: 3
  trace-id: --
  datastore: running
  operation: create
  target: /t:uint16.1
  comment: none
  new value:
    t:uint16.1 10

Example audit log entries for modify a leaf “uint16.1”:

edit-transaction 189: on session 3 by [email protected]
  time: 2020-06-06T01:21:11Z
  message-id: 5
  trace-id: --
  datastore: running
  operation: replace
  target: /t:uint16.1
  comment: none
  new value:
    t:uint16.1 20
  old value:
    t:uint16.1 10

Example audit log entries for delete a leaf “uint16.1”:

edit-transaction 191: on session 3 by [email protected]
  time: 2020-06-06T01:21:24Z
  message-id: 7
  trace-id: --
  datastore: running
  operation: delete
  target: /t:uint16.1
  comment: none
  old value:
    t:uint16.1 20

rpc-error Audit Event

Save RPC error events in the audit log.

Initial Release: 23.10-6
If 'rpc-summary' set, then this bit adds error detail to the RPC Summary, if the 'status' is non-zero (error).
If 'rpc-summary' not set, then generate an RPC summary and rpc-error only if the 'status' is non-zero (error).

Example audit log entry for a 'get-config' operation without any parameters:

RPC <get-config> on session 3 by [email protected]
  start-time: 2024-02-21T18:34:30Z
  end-time:   2024-02-21T18:34:30Z
  message-id: 4
  reply-type: error
  status:     296:missing mandatory choice

RPC Error 296:
rpc-error: (296) data-missing L:rpc S:error app-tag:missing-choice
  path: /get-config/input/source/config-source
  lang: en
  msg: missing mandatory choice
  error-info: missing-choice T:string = config-source
  error-info: error-number T:uint32 = 296

--audit-log-level

The --audit-log-level parameter controls the minimum logging level needed to log datastore audit records to the audit log. This does not affect debug logging to the server console log. This parameter has no effect unless the --audit-log parameter is also used.

This parameter uses the same values as the --log-level parameter.

leaf audit-log-level {
  type nt:NcDebugType;
  default info;
}

Syntax	enumeration: off error warn info debug debug2 debug3 debug4
Default:	info
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --audit-log-level=debug --audit-log=~/server-audit.log&

--autodelete-pdu-error

The --autodelete-pdu-error parameter specifies whether auto-deletion of a configuration parameter provided in an edit PDU is treated as an error or not.

If true, then configuration nodes provided in the edit payload (e.g., <config> element) that are conditional on 'when' statements must evaluate to true or else an operation-failed error will be returned.
If false, then such 'false when' will be silently removed from the target datastore.

leaf autodelete-pdu-error {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --autodelete-pdu-error=false

--bundle

The --bundle parameter is a leaf-list of SIL bundle names that should be loaded automatically when the program starts.

The program will attempt to load each SIL bundle in the order the parameters were entered.

If any SIL bundle initialization callback functions return any error, then the program will terminate. There cannot be any errors in any of the YANG modules in the SIL bundle.

leaf-list bundle {
  type nt:NcxName;
}

Syntax	SIL bundle name
Default:	none
Min Allowed:	0
Max Allowed:	unlimited
Supported by:	netconfd-pro
Example:	netconfd-pro --bundle=interfaces

--callhome-reconnect

The --callhome-reconnect parameter specifies whether server will reconnect after client closes the session.

If 'true' the server will attempt to start a new Call Home connection if the client closes the session.
If 'false' the server will not attempt to start a new Call Home session after the client closes the session.

Be careful that the server is running with proper permissions because a successful connection that fails during authentication will cause a reconnect loop if this parameter is set to 'true'.

leaf callhome-reconnect {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --callhome-reconnect=true

--callhome-retry-interval

The --callhome-retry-interval parameter specifies the number of seconds to wait after a connect attempt to the Call Home server has failed before attempting another connect attempt to that server.

leaf callhome-retry-interval {
  units "seconds";
  type uint16 {
    range "1 .. max";
  }
  default 60;
}

Syntax	uint16 [1..max]
Default:	60 seconds
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --callhome-retry-interval=30

--callhome-retry-max

The --callhome-retry-max parameter specifies the number of retry attempts the server should attempt to the Call Home server before giving up. The value 0 indicates the server should never give up.

leaf callhome-retry-max {
  type uint16;
  default 10;
}

Syntax	uint16
Default:	10
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --callhome-retry-max=0

--callhome-server

The --callhome-server parameter specifies a Call Home/SSH server that this server should attempt to initiate a Call Home connection at boot-time. This is a leaf-list parameter and multiple entries are supported.

This string has the format:

<server-id> '@' <server-addr> [ ':' <port-num> ]

Examples:

[email protected]

[email protected]:12040

The server-id parameter is used for logging purposes.

This parameter is ignored if the --with-callhome parameter is set to 'false'.

leaf-list callhome-server {
  type string;
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	unlimited
Supported by:	netconfd-pro
Example:	netconfd-pro --callhome-server=ch1@192.168.0.40

--callhome-sshd-command

The --callhome-sshd-command parameter specifies the command string used to invoke the SSH server when a Call Home session is initiated.

leaf callhome-sshd-command {
  type string;
  default "/usr/sbin/sshd";
}

Syntax	string
Default:	/usr/sbin/sshd
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --callhome-sshd-command=/bin/sshd

--callhome-sshd-config

The --callhome-sshd-command parameter specifies the SSH server configuration file to use when invoking the SSH server when a Call Home session is initiated. The default config file to use is a dynamic string using the pattern ch_sshd_config.<client>. It is located in the $HOME/.yumapro directory.

leaf callhome-sshd-config {
  type string;
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --callhome-sshd-config=/etc/ssh/callhome_config

--callhome-subsys-command

The --callhome-subsys-command parameter specifies the netconf subsystem to use in the default ch_sshd_config files to specify the NETCONF subsystem for the incoming NETCONF session expected on the callhome session.

leaf callhome-subsys-command {
  type string;
  default "/usr/sbin/netconf-subsystem-pro";
}

Syntax	string
Default:	/usr/sbin/netconf-subsystem-pro
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --callhome-subsys-command=/bin/netconf-subsystem-pro

--callhome-tls-server

The --callhome-tls-server parameter specifies a Call Home/TLS server that this server should attempt to initiate a Call Home connection at boot-time. This is a leaf-list parameter and multiple entries are supported.

This string has the format:

<server-id> '@' <server-addr> [ ':' <port-num> ]

Examples:

netconfd-pro {
  [email protected]
  [email protected]:12040
}

The server-id parameter is used for logging purposes.

This parameter is ignored if the --with-callhome parameter is set to 'false'.

leaf-list callhome-tls-server {
  type string;
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	unlimited
Supported by:	netconfd-pro
Example:	netconfd-pro --callhome-tls-server=ch1@192.168.0.40

--cert-default-user

The --cert-default-user parameter specifies a user-name that should be used if no certificate mapping is found for a NETCONF over TLS session. This is the username to use if no username mapping is found for a NETCONF over TLS session. This parameter is non-standard and should only be used for debugging. This parameter is not available unless image is built with DEBUG=1 parameter.

This parameter is ignored if the --with-netconf-tls parameter is set to 'false'.

leaf cert-default-user {
  type string;
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --cert-default-user=admin

--cert-usermap

The --cert-usermap parameter specifies a user-name to certificate mapping.

Each entry specifies a certificate to user name mapping for NETCONF over TLS sessions. A mapping is a structured string using the form <user>@<fingerprint>.

The 'user' field is the case-sensitive user name for the mapping.

The 'fingerprint' field is a hex-string representation of the SHA-1 fingerprint for the X.509 certificate. It does not have to be complete. Usually 6 bytes should be sufficient to ensure uniqueness. The hex digits are not case-sensitive. At least 6 hex digits must be provided. A maximum of 20 hex digits can be provided.

Note

The full client fingerprint should be used for better security.

Example:

admin@DF:4A:D4:92:1C:53:A5:91:1B:78:C5:E5:71:40:3F:E5:99:FC:AB:D4

A printable fingerprint can be generated with the openssl command:

> openssl x509 -noout -fingerprint -sha1 -inform pem -in [certificate-file.crt]

This parameter is ignored if the --with-netconf-tls parameter is set to 'false'.

leaf-list cert-usermap {
  ordered-by user;
  type string;
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	unlimited
Supported by:	netconfd-pro
Example:	netconfd-pro --cert-usermap=admin@60:C8:5C:08:82:55

--confdir

The --confdir parameter specifies the CLI parameter configuration directory to use for extra configuration files. The server will check this directory for files that end with the suffix '.conf' and process them similar to the main configuration file. Other files will be ignored. Sub-directories will not be checked.

This parameter is ignored if the --no-nvstore parameter is used.

Files will be processed in alphabetical order. The server will keep the first value set if a CLI leaf parameter is set multiple times.

The CLI parameters are set in the following order:

netconfd-pro command line

--config file or /etc/yumapro/netconfd-pro.conf

--confdir files or /etc/yumapro/netconfd-pro.d/

If the --no-config parameter is present in step (1) then steps (2) and (3) will be skipped, and this parameter will be ignored. If this parameter is encountered in step (3) it will be ignored.

Extra configuration files in step (3) have the exact same syntax as the configuration file used in step (2).

Example extra config file testmods.conf:

netconfd-pro {
  module acme-test1
  module acme-test2
  log-level debug2
  message-indent 1
  idle-timeout 0
}

Refer to the Configuration Files section for details on the format of configuration files.

leaf confdir {
  type string;
  default "/etc/yumapro/netconfd-pro.d";
}

Syntax	string: complete directory specification of the directory to look for more configuration files
Default:	/etc/yumapro/netconfd-pro.d
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --confdir=/mnt/conf/device12

--convert-subtree-filter

The --convert-subtree-filter parameter specifies whether subtree filters will be converted to XPath filters for internal processing. If set to 'true' then subtree filters for retrieval operations might be converted to XPath expressions for processing.

The subtree filtering algorithm has a minor flaw which can cause subtree containment nodes to be printed in the output even though a nested selection filter does not match. A containment node should be completely pruned from the result no selection filters within it produce a match. This only affects data that needs to be retrieved by the server with a GET2 callback.

This issue has been fixed by converting a subtree filter to XPath and processing as if it were an XPath filter. If this parameter is set to 'true' then the conversion will be attempted. The conversion will be skipped if any of the following conditions are true:

output format is not XML
input format is not XML
subtree filter contains any attribute match expressions

This bugfix is not enabled by default because it might change filter output which was previously incorrect, but a client might be relying on the incorrect output anyway.

leaf convert-subtree-filter {
   type boolean;
   default false;
 }

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --convert-subtree-filter=true

--create-empty-npcontainers

The --create-empty-npcontainers parameter specifies whether empty configuration NP containers will be created by the server.

This only affects config=true non-presence container definitions with no config=true child nodes present in the configuration. If child nodes are present, then the parent container is not empty.
An empty NP container is only returned in a retrieval operation if defaults are requested (or configured) in the operation.
The --default-style CLI parameter affects the behavior of this parameter. It determines what is considered a default value. If this is set to 'report-all' then empty NP containers will always be returned.
Refer to the Empty NP Container section for more details.

Warning

The YANG Xpath validation within the server may not function properly if this parameter is set to 'false'.
This parameter MUST be set to 'true' for XPath technical support to be provided.
This parameter is deprecated and may be removed from future release trains.
Set --return-empty-npcontainers='false' instead of changing this setting to 'false'

An empty non-presence container has no meaning in NETCONF/YANG so it may be created by the server or not. It is an implementation choice. All clients must be capable of receiving empty NP containers in a response.

If this parameter is set to 'true', then the server will automatically create empty NP containers.
- The empty NP container will treated as a default node and normally it is only returned from the retrieval operation if the 'with-defaults' parameter is set to 'report-all' or 'report-all-tagged'.
- The following retrieval operations are affected by this parameter:
If this parameter is set to 'false', then the server will not automatically create empty NP containers.
- The configuration data node will not exist and will not be returned even if the 'with-defaults' parameter is used.

leaf create-empty-npcontainers {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --create-empty-npcontainers=false

Empty NP Container Example

The following example show the difference in server behavior for this parameter.

Assume the configuration contains a simple NP container with a config=false child node named 'get2con':

container npcon1 {
  container get2con {
    config false;
    leaf A { type string; }
  }
}

If 'create-empty-npcontainers' set to 'true' then a retrieval operation will return the /npcon1 node.

This behavior can also be achieved if set to 'false', but the --create-empty-npcontainers-ro parameter is set to 'true'.

Example <get> request:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="3"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <get>
  <filter type="subtree">
   <npcon1 xmlns="urn:yumaworks:new9"/>
  </filter>
 </get>
</rpc>

Example <get> response:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="3"
 xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx"
 ncx:last-modified="2022-07-25T17:49:18Z" ncx:etag="1003"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data>
  <npcon1 xmlns="urn:yumaworks:new9">
   <get2con>
    <A>test value</A>
   </get2con></npcon1>
 </data>
</rpc-reply>

If 'create-empty-npcontainers' set to 'false' then a retrieval operation will not return the /npcon1 node:

Example <get> response (to the same request)

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="4"
 xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx"
 ncx:last-modified="2022-07-25T18:01:07Z" ncx:etag="1004"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data></data>
</rpc-reply>

Note

An empty NP container must be manually created if the create-empty-npcontainers parameter is 'false' and access to operational data child nodes is required.

After the NP container is manually created (e.g., with <edit-config>) then the operational data will be accessible. However the empty NP container will appear in the configuration.

Empty NP Container Example With <get-bulk>

The following example show the difference in server behavior for the --return-empty-npcontainers parameter.

Assume the configuration contains a simple list with some NP container child nodes:

container test2 {
  list T2 {
    key idx;
    leaf idx { type uint8; }
    container T3 {
      leaf string1 { type string; }
    }
    container T4 {
      leaf string2 { type string; }
    }
  }
}

If the server is configured with this parameter set to 'true' (default):

All the empty 'T3' and 'T4' containers are returned

andy@localhost> get-bulk list-target=/test2/T2 with-defaults=report-all count=5

RPC Data Reply 4 for session 3 [default]:

rpc-reply {
  bulk {
    data {
      T2  1 {
        idx 1
        T3 {
        }
        T4 {
        }
      }
      T2  2 {
        idx 2
        T3 {
        }
        T4 {
        }
      }
      T2  3 {
        idx 3
        T3 {
        }
        T4 {
        }
      }
    }
    last-keys {
      idx 3
    }
  }
}

If the server is configured with this parameter set to 'false' (recommended):

None of the empty 'T3' and 'T4' containers are returned

andy@localhost> get-bulk list-target=/test2/T2 with-defaults=report-all count=5

RPC Data Reply 3 for session 3 [default]:

rpc-reply {
  bulk {
    data {
      T2  1 {
        idx 1
      }
      T2  2 {
        idx 2
      }
      T2  3 {
        idx 3
      }
    }
    last-keys {
      idx 3
    }
  }
}

--create-empty-npcontainers-ro

The --create-empty-npcontainers-ro parameter specifies whether empty configuration NP containers with read-only children will be created by the server.

Warning

Set --return-empty-npcontainers='false' instead using this parameter.

If the --create-empty-npcontainers parameter is set to 'true' then this parameter is not relevant and ignored.

Otherwise this parameter controls whether empty non-presence containers will be created if there are no default child nodes but there are read-only child nodes.

If this parameter is set to 'false', then the server will not create empty NP containers in this case.

If this parameter is set to 'true', then the server will create empty NP containers in this case.

All behavior is the same as --create-empty-npcontainers except only the NP containers with config=false child nodes are affected.

Refer to the Empty NP Container section for more details.

leaf create-empty-npcontainers-ro {
  type boolean;
  default false;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Introduced:	23.10-4
Supported by:	netconfd-pro
Example:	netconfd-pro --create-empty-npcontainers=false --create-empty-npcontainers-ro=true

--db-lock-retry-interval

The --db-lock-retry-interval parameter specifies the number of milliseconds to wait before attempting to get a DB-Config-Lock from the DB-API subsystem. The server will wait this amount of time after a db-lock request fails.

--db-lock-retry-interval parameter

Syntax	number: 10 .. 60000 milliseconds
Default:	500 milliseconds
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --db-lock-retry-interval=1000

--db-lock-timeout

The --db-lock-timeout parameter specifies the total number of seconds to wait before giving up on a DB-Config-Lock from the DB-API subsystem. The value zero indicates that no retries will be attempted if the lock is busy.

leaf db-lock-retry-interval {
  type uint32 {
    range "10 .. 60000";
  }
  units "milli-seconds";
  default 500;
}

Syntax	number: 0 .. 3600 seconds
Default:	30 seconds
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --db-lock-timeout=120

--default-style

The --default-style parameter specifies the way leafs with default values are returned from the server for data retrieval operations. This setting will be used as the default behavior when processing the operations that support the <with-defaults> extension, and no value is provided.

The values and their meanings are defined in ietf-netconf-with-defaults.yang. Here is a summary:

report-all: Report all nodes as the default behavior. The will be the behavior used if this parameter is not specified.
trim: Report only nodes that do not have the server-assigned value, as the default behavior. This includes all leafs with a YANG default and any other node created by the server.
explicit: Report only nodes that have been set by client action, as the default behavior. Any node created via the <startup> configuration at boot-time is considered to be a client-created node. It does not matter what the actual values are, with respect to YANG defaults or server-supplied defaults. Any nodes created by the server are skipped.

leaf default-style {
     type enumeration {
       enum report-all;
       enum trim;
       enum explicit;
     }
     default explicit;
  }

Syntax	enumeration: report-all trim explicit
Default:	explicit
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --default-style=trim

--delete-empty-npcontainers

The --delete-empty-npcontainers parameter is a boolean that indicates whether the server should keep or delete empty non-presence containers in the database.

If 'true', empty NP containers will be deleted. If 'false', they will not be deleted.

Note

This parameter is obsolete!
The server ignores this parameter!
Do not use!

The value 'false' is always used!!!

leaf delete-empty-npcontainers {
  type boolean;
  default false;
  status obsolete;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --delete-empty-npcontainers=true

--errmsg

The --errmsg parameter specifies a language specific error message, for a specific error code.

Specifies a replacement string for a specific error number. Can specify error message for 1 specific language.

The string has the format:

<num>:<lang>:error string

where:

<num> = error number to use for error message
<lang> = language code (en for English)
error string = error string text

The 'num' component must match the <error-number> found in status_enum.h. New error enums are always added at the end of the list, so the numbers will not change.
The 'lang' component should use the ISO-639-1 code Max length is 7 characters.

Example:

Replace error 117 (ERR_WB_WRITE_FAILED) 'db write failed'

errmsg='117:en:The database could not be written'

There are several pre-defined error message configuration files, found in directory:

/usr/share/yumapro/util/errmsg-lang

To use an error message configuration file, copy the file to the netconfd.d configuration directory:

The --errmsg-lang parameter must be set to the correct language code for the server to use this configuration file.

Example: Copy the Russian (ru) error codes to the configuration directory:

> sudo mkdir /etc/yumapro/netconfd-pro.d
> sudo cp /usr/share/yumapro/util/errmsg-lang/errmsg-ru.conf /etc/yumapro/netconfd-pro.d/

leaf-list errmsg {
  type string;
  description
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	unbounded
Supported by:	netconfd-pro
Example:	netconfd-pro --errmsg="117:en:Database write failed"

--errmsg-lang

The --errmsg-lang parameter specifies the language to use for <error-message> content.

The --errmsg parameter must be used to configure the language-specific error message strings.

This value should use the ISO-639-1 code for the language.

leaf errmsg-lang {
  type string {
    length "1 .. 7";
  }
  default "en";
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	unbounded
Supported by:	netconfd-pro
Example:	netconfd-pro --errmsg-lang=ru

--eventlog-size

The --eventlog-size parameter controls the maximum number of events that will be stored in the notification replay buffer by the netconfd-pro server. .. container:

.. warning::

   -  This parameter can cause a lot of memory to be used by the server
   -  Change the default if notification replay not used
      -  Set to '0' to disable but will enable subscription auto-cleanup
      -  Set to a low value such as ``3`` to prevent subscription auto-cleanup

If set to '0', then notification replay will be disabled, meaning that all requests for replay subscriptions will cause the <replayComplete> Event to be sent right away, since there are no stored notifications.

Subscription auto-cleanup is used in the server to cleanup notifications after they have been delivered to all clients subscribing to the event stream. A pending notification will be replaced when a new notification added.

If set to a value higher than '0', the server will delete the oldest entry when this limit is reached and a new event is added to the replay buffer.

No memory is actually set aside for the notification replay buffer, so memory limits may be reached before the maximum number of events is actually stored, at any given time.

leaf eventlog-size {
   type uint32;
   default 1000;
}

Syntax	uint32
Default:	1000
Recommend:	3
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --eventlog-size=20000

--event-stream

The --event-stream parameter specifies the name of a NETCONF event stream that should be created by the server.

Note

The yumaworks-event-stream.yang module can be used instead of this parameter to configure event streams.

Each event stream has its own subscriptions and notification replay buffer. Each event stream has the same replay buffer size, using the shared eventlog-size parameter. Each generated notification is sent to one event stream.

The YANG module instrumentation will select an event stream to use or the default event stream will be used. Copies of the same notification can be sent to multiple event streams. If the event-stream specified by the instrumentation is not available, then a warning will be generated in the log and the default event stream will be used instead.

The default event stream is named 'NETCONF'. It cannot be replaced or removed. No other event stream can have this name. The standard NETCONF notification events are always sent to this event stream, unless there is an event-stream-map assigning the module to a different event stream.

leaf-list event-stream {
   type ywt:NcxNumName;
}

Syntax	NcxName (string)
Default:	none
Min Allowed:	0
Max Allowed:	unbounded
Introduced:	19.10
Supported by:	netconfd-pro
Example:	netconfd-pro --event-stream=hardware --event-stream=routing

--event-stream-map

The --event-stream-map parameter specifies a module name to event-stream mapping for notification handling.

Note

The yumaworks-event-stream.yang module can be used instead of this parameter to configure event streams.

A mapping is a structured string using the form

<module-name>@<stream-name>

The 'module-name' field is the case-sensitive module name for the mapping.
The 'stream-name' field is the case-sensitive stream name for the mapping. It must match an 'event-stream' parameter or the default 'NETCONF'.
Note there is no need to define a mapping for the 'NETCONF' stream since it will be picked if no other stream is selected.

The built-in notifications such as <replayComplete> Event and <notificationComplete> Event are subscription-specific and always sent only to the subscription, not the event stream. Therefore these notifications are not affected by this parameter.

leaf-list event-stream-map {
  type string;
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	unbounded
Introduced:	19.10
Supported by:	netconfd-pro
Example:	netconfd-pro --event-stream-map=ietf-hardware@hardware

--factory-startup

The --factory-startup CLI parameter forces the server to over-write the startup configuration file and replace it with the factory installed default configuration.

Force the system to use the factory configuration and delete the startup config file if it exists. Force the NV-storage startup to contain the factory default configuration.

Use this parameter with caution!!! Use the backup operation to save the current configuration first.

Debug: This parameter is often useful to make sure a test server does not start with any left over configuration from a previous test.

leaf factory-startup {
  type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --factory-startup

--ha-enabled

The --ha-enabled parameter is used to enable or disable the High Availability protocol (YP-HA). This allows redundant systems to stay up-to-date with all configuration changes, and other server state.

If 'true', then YP-HA will be enabled
If 'false', then YP-HA will be disabled.

If this parameter is enabled then the following parameters must be configured or the server will exit with an error:

--ha-server
--ha-server-key
--server-id
--socket-type=tcp
--socket-address
--socket-port

leaf ha-enabled {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --ha-enabled=true

--ha-initial-active

The --ha-initial-active parameter specifies the server name for the initial YP-HA active server. This is ignored unless --ha-enabled=true. There is no default.

This parameter is used to hardwire the initial High Availability roles instead of setting it in the yp-system init1 or init2 callback functions. If this parameter is the same as 'server-id' then this server will be the initial YP-HA active server.

This parameter is intended for debug mode only. The real operational mode should use signaling only to set the HA mode. Otherwise if the server reboots it will use the configured HA mode, which may not be correct if it has been changed during runtime.

leaf ha-initial-active {
  type nt:NcxName;
}

Syntax	string (NcxName)
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --ha-initial-active=ha-1

--ha-server

The --ha-server parameter specifies a server in the YP-HA server pool.

This parameter must be configured if the --ha-enabled parameter is set to true.

This string has the format:

<server-id> '@' <server-addr> [ ':' <port-num> ]

Examples:

[email protected]

[email protected]:12040

If no port number is used then the port '8088' is used.

The server-addr field must match the --socket-address parameter for the server.

The port-num field must match the --socket-port parameter for the server.

The server running with this configuration must be listed in the ha-server pool. The --server-id parameter must match the entry for this server.

There must be at least 2 entries present to configure an HA server pool.

leaf-list ha-server {
  type string;
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	unlimited
Supported by:	netconfd-pro
Example:	netconfd-pro --ha-server=ha-1@192.168.0.100 --ha-server=ha-2@192.168.0.10:8090

--ha-server-key

The --ha-server-key parameter specifies the string the standby server must present to the active server during registration. Used to prevent servers from going the wrong HA pool. If not set then the active server will reject the YP-HA connection. This parameter must be set if the ha-enabled parameter is set to 'true'. It is ignored unless --ha-enabled=true. There is no default.

leaf ha-server-key {
  type string;
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --ha-server-key=ha-pool-1

--ha-sil-standby

The --ha-sil-standby parameter specifies whether the edit callbacks such as SIL, SIL-SA and HOOK instrumentation will be invoked if the server is operating in HA standby mode.

leaf ha-sil-standby {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --ha-sil-standby=true

--hello-timeout

The --hello-timeout parameter controls the maximum number of seconds that the netconfd-pro server will wait for a <hello> PDU, for each session.

If set to 0, then hello state timeouts will be disabled, meaning that no sessions will be deleted while waiting for a <hello> PDU.

The hello timer starts when a session is started within the server, and therefore using a session resource that counts against the 'max-sessions' limit.

For NETCONF over SSH sessions the session starts after the SSH session is setup and the 'netconf' subsystem is invoked. The SSH server has its own timeout values for maximum session startup time. For NETCONF over TLS sessions the session starts when the TCP connection is accepted.

Note

It is strongly suggested that this parameter not be disabled, since a denial-of-service attack will be possible if sessions are allowed to remain in the 'hello wait' state forever.

A finite number of SSH and NETCONF sessions are supported, so if an attacker simply opened lots of SSH connections to the netconf subsystem, the server would quickly run out of available sessions.

Sessions cannot be deleted manually via <kill-session> operation if no new sessions are being allocated by the server.

leaf hello-timeout {
   type uint32 {
      range "0 | 10 .. 3600";
   }
   units seconds;
   default 600;    // 10 minutes
}

Syntax	uint32; 0 == disabled; range 10 .. 3600 seconds (1 hour max)
Default:	600 (10 minutes)
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --hello-timeout=300

--hide-module

The --hide-module parameter specifies the name of a module to hide from advertisements to client sessions. If the specified module name is loaded into the server, then this parameter will cause it to be omitted from the following data structures:

YANG 1.0 <hello> message
/netconf-state/schemas/schema list
/modules-state/module list

This parameter will prevent the client from knowing about the hidden module. If an advertised module imports a hidden module then it is very likely a client will not be able to use the advertised module because of the missing imports.

This parameter can be dangerous! It does not prevent loading or enabling of the module. The SIL code is responsible for not returning any data to a client using a hidden module.

Warning

Use of this parameter violates conformance to NETCONF, RESTCONF, and the YANG Library. Use with caution, only for modules that are not accessible by clients.

leaf-list hide-module {
   type nt:NcxName;
}

Syntax	string: module name
Default:	none
Min Allowed:	0
Max Allowed:	unbounded
Supported by:	netconfd-pro
Example:	netconfd-pro --hide-module=mysecretmod

--highres-event-time

The --highres-event-time parameter controls how the date-and-time string used in the notification 'eventTime' leaf will be output.

If set to 'true' then the 'eventTime' leaf value in all <notification> messages will contain a microseconds field.
If 'false' then this field will not contain a microseconds field.
This field is always 6 digits long and represents a fraction of one second as the number of microseconds.

Note

The default behavior is different than the low resolution format used in previous releases. The date-and-time data type includes this optional field so a client should accept the value.

leaf highres-event-time {
  type boolean;
  default true;
}

Syntax	boolean
Default:	TRUE
Min Allowed:	0
Max Allowed:	1
Introduced:	22.10-1
Supported by:	netconfd-pro
Example:	netconfd-pro --highres-event-time=true

Example:

The 'eventTime' leaf in the following notification for a 'netconf-config-change' includes the microseconds field:

 <?xml version="1.0" encoding="UTF-8"?>
  <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
   <eventTime>2022-09-18T15:57:21.402308Z</eventTime>
   <netconf-config-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications">
    <changed-by>
     <username>andy</username>
     <session-id>3</session-id>
     <source-host>127.0.0.1</source-host>
    </changed-by>
    <datastore>running</datastore>
    <edit>
     <target
      xmlns:nacm="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">/nacm:nacm/nacm:groups/nacm:group[nacm:name="test-group"]</target>
     <operation>create</operation>
    </edit>
   </netconf-config-change>
  </notification>

--idle-timeout

The --idle-timeout parameter controls the maximum number of seconds that the netconfd-pro server will wait for a <rpc> PDU, for each session.

If set to 0, then idle state timeouts will be disabled, meaning that no sessions will be deleted while waiting for a <rpc> PDU.

A session will never be considered idle while a notification subscription is active.

Debug: It is often useful to set this parameter to '0' so breakpoint debugging and other pauses to not cause client sessions to be dropped.

Warning

It is strongly suggested that this parameter not be disabled, since a denial-of-service attack will be possible if sessions are allowed to remain in the 'idle wait' state forever.

A finite number of SSH and NETCONF sessions are supported, so if an attacker simply opened lots of SSH connections to the netconf subsystem, the server would quickly run out of available sessions.

This parameter will affect a <confirmed-commit> operation!

Make sure this timeout interval is larger than the value of the <confirm-timeout> parameter used in the confirmed commit procedure. Otherwise, it is possible that the session will be terminated before the confirm-timeout interval has expired, effectively replacing that timer with this one.

leaf idle-timeout {
   type uint32 {
      range "0 | 10 .. 360000";
   }
   units seconds;
   default 3600;    // 1 hour
}

Syntax	uint32
Default:	3600 (1 hour)
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --idle-timeout=30000

--import-version-bestmatch

The --import-version-bestmatch parameter specifies if the bestmatch search feature should be used for import resolution when no revision-date field is specified in the import-stmt.

If 'true' then the server will scan the module search path during startup and determine the most recent revisions of each module. If a module is loaded or imported and no revision date is specified then the best match revision will be used.

This feature requires some additional memory and bootup processing time. It should be avoided if possible. The module search path on the server should only contain the modules and revisions that are needed by the server.

If set to 'false', then the best match feature will not be enabled. It is possible for the server to find and load the wrong version of a module during imports processing.

For example, while loading module A, it imports module B. Then module B is loaded but a revision is specified (e.g., --module=B@2019-06-20). This can cause errors during callback registration such as 'definition not found' or 'segment not found', depending on how the module has changed.

leaf import-version-bestmatch {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --import-version-bestmatch=true

--library-mode

The --library-mode parameter is used to run the server in YANG library mode.

Note

Refer to the Using the Server in Library Mode section for details on Library Mode usage.

The NETCONF <get-schema> operation will support retrieval of the YANG modules found in the search path.

Warning

Normal server operation is not possible in this mode. Only a small number of operations are permitted.

leaf library-mode {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --library-mode=true

--loadpath

The --loadpath parameter specifies the YANG module load path to use while loading YANG modules at boot-time. It consists of a colon (':') separated list of path specifications, commonly found in Unix, such as the $PATH environment variable.

This parameter overrides the $YUMAPRO_LOADPATH environment variable, if it is present.

leaf loadpath {
  type yt:NcPathList;
}

Syntax	string: list of directory specifications
Default:	$YUMAPRO_LOADPATH environment variable
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --loadpath =”~/testmodules:~/modules:~/trunk/netconf/modules”

--log-event-drops

The --log-event-drops parameter indicates if a log entry would be generated when a notification is dropped because the specific notification events are disabled with an event-filter configuration entry.

This parameter has no effect if the --with-notifications CLI parameter is set to false.

leaf log-event-drops {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --log-event-drops=true

--log-pthread-level

The --log-pthread-level parameter controls the verbosity level of thread-specific messages printed to the log file or STDOUT, if no log file is specified. Note that this parameter is only effective in thread-based images.

This parameter uses the same values as the --log-level parameter.

leaf log-pthread-level {
  type nt:NcDebugType;
}

Syntax	enumeration: off error warn info debug debug2 debug3 debug4
Default:	info (debug for DEBUG builds)
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro > --log-pthread-level=debug --log=~/server.log&

--log-vendor

The --log-vendor parameter directs log output to be sent to a customer-written and registered callback function, rather than to STDOUT.

This functionality is defined by an API specified in the Syslog Interface section.

In the absence of a registered callback, this parameter will direct logging messages to syslog. See the --log-console parameter for information on how log output may also be duplicated via STDOUT.

leaf log-vendor {
  type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro yangcli-pro
Example:	netconfd-pro --log-vendor

--log-vendor-level

The --log-vendor-level parameter sets the vendor debug logging level filter for output to the vendor-specific log output file stream for the program.

This parameter uses the same values as the --log-level parameter.

leaf log-vendor-level {
  type yt:NcDebugType;
}

Syntax	enumeration: off error warn info debug debug2 debug3 debug4
Default:	info
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --log-vendor-level=debug

--max-burst

The --max-burst parameter specifies the maximum number of notifications to send in a burst, to one session. Even though TCP will control the transmission rate, this parameter can limit the memory usage due to buffering of notifications waiting to be sent.

The value zero means no limit will be used at all.

leaf max-burst {
  type uint32;
  default 10;
}

Syntax	uint32
Default:	10
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --max-burst=100

--max-cli-sessions

The --max-cli-sessions parameter specifies the maximum number of concurrent CLI sessions to allow at any time.

The value zero means no artificial limit will be used at all. The --max-sessions parameter has precedence, so setting this parameter to a value larger than --max-sessions will have no effect.

This parameter does not apply to YControl sessions.

leaf max-cli-sessions {
  type uint16 {
    range "0 .. 1024";
  }
  default 0;
}

Syntax	uint16 (0 .. 1024)
Default:	0
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --max-cli-sessions=2

--max-getbulk

The --max-getbulk parameter specifies the maximum number of getbulk entries to request from a GET2 callback.

This value will be used in the get2cb 'max_entries' field.
The value 0 is used to indicate there is no max and the GET2 callback can return as many getbulk entries as desired.

Note

A GET2 callback is expected to ignore this value for a leaf-list object and always return all instances of the leaf-list.

leaf max-getbulk {
  type uint32;
  default 10;
}

Syntax	uint32
Default:	10
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --max-getbulk=100

--max-lock-hold-time

The --max-lock-hold-time parameter specifies the maximum number of seconds to allow a session to hold a global NETCONF datastore lock.

If zero, then no maximum lock hold time will be used. This is the behavior specified by RFC 6241.
If non-zero, then the standard will not be followed. Instead, a global lock will be released if held by a session too long.
- This timeout only applies to the 'lock' operation.
- Partial locks are not affected at all by this parameter.
- Does not affect any edit transaction that may be in progress.

Note

If a lock is released, then the locking session will not be warned or notified in anyway.

If a session has an active notification subscription, or if the client sends at least one request periodically, then the --idle-timeout parameter will not be enforced. It is possible for a NETCONF session to hold a global datastore lock indefinitely.

This parameter allows the datastore lock time to be configured so it does not depend on the --idle-timeout parameter setting.

Warning

Using this parameter with a value greater than zero will violate RFC 6241 procedures for the 'lock' operation.

A minimum lock hold time of 5 seconds is allowed.
If a timeout occurs the datastore lock will be dropped, but the session will not be dropped.
If an edit is in progress, it will not be affected. Only the NETCONF lock will be released.
The server will output an 'info' log message if a datastore lock is released by the server due to the lock hold time exceeding this value. Example:
```
Max Lock Hold Time timeout for datastore running
Locked by session 3 at 2023-03-21T23:35:55Z
```

leaf max-lock-hold-time {
  type uint16 {
    range "0 | 5 .. max";
  }
  units seconds;
  default 0;
}

Syntax	uint16
Default:	0
Min Allowed:	0
Max Allowed:	1
Introduced:	22.10-7
Supported by:	netconfd-pro
Example:	netconfd-pro --max-lock-hold-time=120

--max-per-user-sessions

The --max-per-user-sessions parameter specifies the maximum number of concurrent CLI sessions to allow at any time by a specific single user.

This parameter will override the --max-user-sessions parameter for the specified username, if both are present.
The --max-sessions parameter has precedence, so setting this parameter higher than 'max-sessions' will have no effect.
This parameter does not apply to YControl sessions.
The value is a formatted string and it must not contain any whitespace.
The username field must be followed by a single colon ':' character, which must be followed by the number field.
```
username:number
```
username Field:
- The username field must be between 1 and 1024 characters, and must not contain a colon ':' character.
- This value will be compared to the username assigned to a client session when it is started. The client session will be dropped if the session limit is exceeded.
number Field:
- The number field must be between 0 and 1024.
- This must be in decimal with no leading zeroes, and must contain between 1 and 4 characters.
- The value 0 indicates that no artificial session limit should be used for the specified user.

Example:

limit total concurrent client sessions to 10
limit total number of concurrent sessions by a single user to 2
except user 'admin1', and a limit of 5 for user 'admin2':

max-sessions 10
max-user-sessions 2
max-per-user-sessions admin1:0
max-per-user-sessions admin2:5

Errors:

Invalid entries will cause the server to terminate with an error.
A duplicate username will be ignored and a warning will be printed to the log.

leaf-list max-per-user-sessions {
  type string {
    length "3 .. 1029";
  }
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	unbounded
Introduced:	23.10-5
Supported by:	netconfd-pro
Example:	netconfd-pro --max-per-user-sessions=admin1:5

--max-sessions

The --max-sessions parameter specifies the maximum number of concurrent sessions to allow at any time.

The value zero means no artificial limit will be used at all.

This parameter does not apply to YControl sessions.

leaf max-sessions {
  type uint16 {
    range "0 .. 1024";
  }
  default 8;
}

Syntax	uint16 (0 .. 1024)
Default:	8
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --max-sessions=10

--max-strlen

The --max-strlen parameter specifies the maximum number of bytes in length that will be accepted for a quoted string, by the internal token parser.

This affects YANG and JSON input processing.
Set this value to allow large binary leafs to be parsed by the server.
This value includes 1 byte for the string termination character.
The minimum size is 64 KBytes.
The maximum is 2 billion bytes.
The default is 256 KBytes.

leaf max-strlen {
  type int32 {
     range "65536 .. max";  // 64KB to 2G-1
  }
  units bytes;
  default 262144;  // 256K
}

Syntax	int32 (65536 .. INT_MAX)
Default:	262144
Min Allowed:	0
Max Allowed:	1
Supported by:	netconfd-pro
Example:	netconfd-pro --max-strlen=1000000

--max-user-sessions

The --max-user-sessions parameter specifies the maximum number of concurrent CLI sessions to allow at any time by a single user.

The value zero means no artificial limit will be used at all. The --max-sessions parameter has precedence, so setting this parameter to a value larger than --max-sessions will have no effect.

This parameter does not apply to YControl sessions.

leaf max-user-sessions {
  type uint16 {
    range "0 .. 1024";
  }
  default 0;
}

Syntax	uint16 (0 .. 1024)
Default:	0
Min Allowed:	0
Max Allowed:	1
Introduced:	22.10-1
Supported by:	netconfd-pro
Example:	netconfd-pro --max-user-sessions=3

--module-tagmap

The --module-tagmap parameter is a leaf-list of module name to module-tag mappings.

Specifies a module tag mapping for use in module tags registry.
The format is <modname>@<tag-string>.
Strings should follow the format in the ietf-module-tags YANG module.

The <get> and <get-config> operations accept this parameter, which is used as a filter to include only data nodes from modules that match the specified module-tag.

Examples:

ietf-system@ietf:system-management
openconfig-system@vendor:openconfig:system-management
example-system@vendor:example.com:system-management

leaf-list module-tagmap {
  type string;
}

Syntax	structured string
Default:	none
Min Allowed:	0
Max Allowed:	unlimited
Supported by:	netconfd-pro
Example:	netconfd-pro --module-tagmap=test1@test --module-tagmap=test2@test

--netconf-capability

The --netconf-capability parameter is a leaf-list of URI values that should be added to the server NETCONF <hello> message as a NETCONF <capability> URI and monitoring data in the /netconf-state/capabilities container.

To add vendor capabilities:

NETCONF: Use this parameter
RESTCONF: Use the --restconf-capability parameter

leaf-list netconf-capability {
  type inet:uri;
}

Syntax	inet:uri
Default:	none
Min Allowed:	0
Max Allowed:	unlimited
Supported by:	netconfd-pro
Example:	netconfd-pro --netconf-capability=urn:acme:test

--netconf-tls-address

The --netconf-tls-address parameter specifies the IP address to listen on for NETCONF over TLS messages.