The server supports many different configuration parameters. The standards allow different variants and implementation choices. Default choices are made for most parameters but if you do not want the default behavior then parameters have to be passed to the server somehow. The parameter processing is itself configurable and flexible, so only the simplest variants are described here.

  • The server processes parameters in a specific order.
    • Command Line
    • Main Configuration File
    • Configuration Directory Configuration Files
  • Leaf values use the value first found.
  • Leaf-list values are additive so all sources can provide these parameters

The main configuration file is specified with the --config parameter. It can only be entered from the command line.

The default main configuration file is /etc/yumapro/netconfd-pro.conf.

The configuration directory allows additional configuration files to be used in addition to the main configuration file.

The configuration directory is specified with the --confdir parameter. It can only be specified at the command line or in the main configuration file. The default value is /etc/yumapro/netconfd-pro.d.

Pick the NETCONF Datastore Variant

There are 4 different variants allowed in the original NETCONF datastore architecture.

The  --target and --with-startup parameters are used to select one of the four variants.

The default NETCONF datastore architecture is :candidate (target=candidate, --with-startup=false).

:writable+running + :startup--target=running--with-startup=true
:candidate + :startup--target=candidate--with-startup=true

Pick the File Location Scheme (FHS or $HOME/.yumapro)

The server supports the Filesystem Hierarchy Standard (FHS) for location of all server files and sockets generated at run-time. Log files, YANG config files and other run-time specific files are affected by this parameter. This parameter does not affect the location of YANG modules

Set the --fileloc-fhs parameter to 'true' to use the FHS locations. This usually requires 'root' user access so the default is 'false'. FHS may be required to run RESTCONF on some WEB servers and operating systems.

The FHS server log file will be created by default unless the --log parameter is used, then that location will be used instead.

The FHS audit log file will be created by default unless the --audit-log parameter is used, then that location will be used instead. If the  --no-audit-log parameter is present then no audit log will be created.

The config file and factory config file are XML representations of the <running> configuration datastore. They do not have to be used, depending on the database integration selected.  The config file is loaded at boot-time and a user-specified file can be used instead of the default if the --startup parameter is used,  The factory config file is loaded if the --factory-startup parameter is used, and a user-specified file can override the default if the --startup-factory-file parameter is also used.

File Type--fileloc-fhs=true--fileloc-fhs=false
server log /var/log/netconfd-pro/server.logSTDOUT; no server log created by default
audit log/var/log/netconfd-pro/audit.logSTDOUT; no audit log created by default
config file/var/lib/netconfd-pro/startup-cfg.xml$HOME/.yumapro/startup-cfg.xml
factory config file/var/lib/netconfd-pro/factory-startup-cfg.xml$HOME/.yumapro/factory-startup-cfg.xml
transaction ID tile/var/lib/netconfd-pro/startup-cfg-txid.txt$HOME/.yumapro/startup-cfg-txid.txt
backup configuration files/var/lib/netconfd-pro/backups/$HOME/.yumapro/backups/
PID file/var/run/netconfd-pro/$HOME/.yumapro/
AF_LOCAL socket/var/run/netconfd-pro/ncxserver.sock/tmp/ncxserver.sock

Setup the Initial Server Access Control

The server supports several mechanisms to control access to the server.

  • SSH Config File (/etc/ssh/sshd_config)
    • The Port and Subsystem parameters must be configured in the SSH server to support NETCONF
      • Port 22
      • Port 830
      • Subsystem netconf /usr/sbin/netconf-subsystem-pro
  • --port Parameter
    •  can be used to specify one or more ports that NETCONF over SSH sessions will be accepted.
    • This must be a subset of the values specified with the SSH Port parameter. 
    • By default only port 830 will be used. 
    • The standard port (830) does not have to be used at all, but it is recommended.
  • --allowed-user Parameter 
    • can be used to specify the user names that are allowed to start client sessions. 
    • By default, any valid user can create a client session. 
    • If this parameter is used, then only the user names specified will be allowed to start a client session. 
    •  By default the username 'restconf' is used for RESTCONF sessions where no user name was assigned to the session.
  • --access-control Parameter
    • Global control switch for the NETCONF Access Control Model (NACM)
    • Default is to enforce access control policies.
    • Set to 'disabled' or 'off' with caution! (E.g., Debugging only!)
  • --superuser Parameter
    • Allows one user to bypass access control rules (Very useful for initial configuration or preventing incorrect or ill-advised NACM rules from locking out all access).
    • By default there is no superuser defined!

Load and Configure YANG Modules and Bundles

The server supports several ways to control which built-in YANG modules are available in the server.

There are four types of modules used within the server:

  1. Built-in Mandatory Modules: These modules are required for NETCONF or server operation. They are loaded automatically and cannot be disabled.
  2. Built-in Optional Modules: These modules are implemented as part of the server and can be enabled or disabled with CLI parameters.
  3. Modular Optional Modules: These modules are implemented as SIL libraries as part of the server and can be loaded and unloaded like Vendor Modules.
  4. Vendor Modules: These modules are implemented by the vendor as SIL or SIL-SA libraries as part of the server and can be loaded and unloaded using CLI parameters and/or NETCONF operations.

YANG Bundles are implementation-specific to the YumaPro SDK. They allow multiple vendor modules to be implemented together as a single library, and used together as if they were a single module.

There are several CLI parameters that control how the server loads and configures YANG modules at boot-time:

Load a YANG module containing annotations that will not be advertised to clients
Load a SIL or SIL-SA bundle library and all its YANG modules
Load a YANG module containing deviations
Disable a YANG feature
Enable a YANG feature
Enable or disable YANG features if no feature-enable or feature-disable found
Do not advertise the specified module. Use with caution since clients may not work correctly if certain YANG modules are not known to the client when a session starts.
Load the SIL library and module for all YANG modules found in the specified path
Control where the server searches for YANG modules
Load a SIL or SIL-SA module library and its YANG module
Treat a missing SIL library as an error causing the server to exit. By default the server will continue if the YANG module is found but not a SIL library.

Configure Server Protocol Features

The server has many protocol features that can be enabled or disabled using a boolean CLI parameter.

There are often other parameters that must or can be provided if a particular protocol feature is enabled,

but those parameters are not shown here.

--with-callhomefalseEnable the CallHome protocol for NETCONF
--with-canonicaltrueEnable the automatic conversion of data types to their canonical format
--with-config-idtrueEnable the <config-id> attribute for return in <rpc-reply> messages
--with-db-lockfalseEnable the external database lock manager
--with-gnmifalseEnable the gNMI protocol
--with-maintenance-modetrueEnable the server maintenance mode APIs
--with-modtagstrueEnable the module-tags support
--with-netconftrueEnable the NETCONF protocol over SSH
--with-netconf-tlsfalseEnable the NETCONF protocol over TLS
--with-notificationstrueEnable NETCONF Notifications
--with-ocpatternfalseEnable the OpenConfig pattern replacement feature
--with-restconftrueEnable the RESTCONF protocol YANG Patch
--with-rollback-on-errortrueEnable the NETCONF rollback-on-error capability
--with-snmpfalseEnable the SNMP agent
--with-startupfalseEnable the NETCONF <startup> datastore
--with-support-savetrueEnable the <get-support-save> operation
--with-term-msgtrueEnable the yp-shell terminal message feature
--with-urltrueEnable the NETCONF :url capability
--with-url-ftpfalseEnable the FTP protocol for use with the <url> parameter
--with-url-tftpfalseEnable the TFTP protocol for use with the <url> parameter
--with-validatetrueEnable the NETCONF :validate capability
--with-warningsfalseEnable RPC warnings for NETCONF <rpc-error> messages
--with-yang11-hellofalseEnable the YANG 1.1 <hello> message for NETCONF
--with-yp-shelltrueEnable the CLI protocol
--with-yuma-systemfalseEnable the yuma-system YANG module
--with-yuma-time-filtertrueEnable the yuma-time-filter YANG module
--with-yumaworks-config-changefalseEnable the yumaworks-config-change YANG module
--with-yumaworks-event-filtertrueEnable the yumaworks-event-filter YANG module
--with-yumaworks-getbulktrueEnable the <get-bulk> operation
--with-yumaworks-idstrueEnable the yumaworks-ids YANG module
--with-yumaworks-systemtrueEnable the yumaworks-system YANG module
--with-yumaworks-templatestrueEnable the yumaworks-templates YANG module