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).



Varianttargetwith-startup
:writable-running--target=running--with-startup=false
:writable+running + :startup--target=running--with-startup=true
:candidate--target=candidate--with-startup=false
: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/netconfd-pro.pid$HOME/.yumapro/netconfd-pro.pid
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:


ParameterDescription
--annotation
Load a YANG module containing annotations that will not be advertised to clients
--bundle
Load a SIL or SIL-SA bundle library and all its YANG modules
--deviation
Load a YANG module containing deviations
--feature-disable
Disable a YANG feature
--feature-enable
Enable a YANG feature
--feature-enable-default
Enable or disable YANG features if no feature-enable or feature-disable found
--hide-module
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.
--loadpath
Load the SIL library and module for all YANG modules found in the specified path
--modpath
Control where the server searches for YANG modules
--module
Load a SIL or SIL-SA module library and its YANG module
--sil-missing-error
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.



ParameterDefaultDescription
--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-maintenance-mode
true
Enable the server maintenance mode APIs
--with-modtags
true
Enable the module-tags support
--with-netconf
true
Enable the NETCONF protocol over SSH
--with-notifications
trueEnable NETCONF Notifications
--with-restconf
trueEnable the RESTCONF protocol YANG Patch
--with-rollback-on-error
trueEnable the NETCONF rollback-on-error capability
--with-support-save
trueEnable the <get-support-save> operation
--with-term-msg
trueEnable the yp-shell terminal message feature
--with-url
trueEnable the NETCONF :url capability
--with-validate
trueEnable the NETCONF :validate capability
--with-yp-shell
trueEnable the CLI protocol
--with-yuma-time-filter
trueEnable the yuma-time-filter YANG module
--with-yumaworks-event-filter
trueEnable the yumaworks-event-filter YANG module
--with-yumaworks-getbulk
trueEnable the <get-bulk> operation
--with-yumaworks-ids
trueEnable the yumaworks-ids YANG module
--with-yumaworks-system
trueEnable the yumaworks-system YANG module
--with-yumaworks-templates
trueEnable the yumaworks-templates YANG module
--with-callhome
false
Enable the CallHome protocol for NETCONF
--with-db-lock
false
Enable the external database lock manager
--with-gnmi
false
Enable the gNMI protocol
--with-grpc
false
Enable the gRPC protocol
--with-netconf-tls
false
Enable the NETCONF protocol over TLS
--with-ocpattern
false
Enable the OpenConfig pattern replacement feature
--with-snmp
false
Enable the SNMP agent
--with-startup
false
Enable the NETCONF <startup> datastore
--with-url-ftp
falseEnable the FTP protocol for use with the <url> parameter
--with-url-tftp
false
Enable the TFTP protocol for use with the <url> parameter
--with-warnings
false
Enable RPC warnings for NETCONF <rpc-error> messages
--with-yang11-hello
false
Enable the YANG 1.1 <hello> message for NETCONF
--with-yuma-system
false
Enable the yuma-system YANG module
--with-yumaworks-config-change
false
Enable the yumaworks-config-change YANG module



Next Lesson: Prepare a YANG Module