YumaWorks

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

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.

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:

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.

Next Lesson: Prepare a YANG Module