Sysrepo

Sysrepo is a YANG-based configuration and operational state data store for Unix/Linux applications.

Applications can use sysrepo to store their configuration modeled by provided YANG model instead of using e.g. flat configuration files. Sysrepo will ensure data consistency of the data stored in the datastore and enforce data constraints defined by YANG model. Applications can currently use C language API of sysrepo Client Library to access the configuration in the datastore, but the support for other programming languages is planed for later, too.

Sysrepo can be easily integrated with management agents such as NETCONF or RESTCONF servers, using the same client library API that applications use to access their configuration. As of now, sysrepo is integrated with the Netopeer 2 NETCONF server. This means that applications that use sysrepo to store their configuration can automatically benefit from the ability to being controlled via NETCONF.

Branches

The project uses 2 main branches master and devel. Other branches should not be cloned. In master there are files of the last official release. Any latest improvements and changes, which were tested at least briefly are found in devel. On every new release, devel is merged into master.

This means that when only stable official releases are to be used, either master can be used or specific releases downloaded. If all the latest bugfixes should be applied, devel branch is the one to be used. Note that whenever a new issue is created and it occurs on the master branch, the first response will likely be to use devel before any further provided support.

Compatibility Between Versions

When upgrading Sysrepo to a newer major SO version, look into the compatibility directory for a summary of changes. Each directory describes the changes between the specific SO versions. Be aware that they do not match project versions.

Provided Features

• Ability to store / retrieve YANG-modeled data elements adressed by XPath
• Startup, running, candidate, and operational datastore support
• Data consistency and constraints enforcement according to YANG models
• No single point of failure design (is just a library)
• Full transaction and concurrency support
• Shared YANG context for the whole system (time and memory efficiency)
• Notifications of subscribed applications about the changes made in the datastore
• Commit verifiers (change verification by subscribed applications)
• Operational data support (publishing of application's state/configuration data to sysrepo)
• YANG 1.1 support
• Custom RPC, Event Notifications, YANG 1.1 Actions support
• Notification store & notification replay
• YANG Schema Mount support (RFC 8528)
• Factory Default Datastore support (RFC 8808)

Packages

Binary RPM or DEB packages of the latest release can be built locally using apkg, look into README in the distro directory.

Security Notes

Sysrepo does not have any master process that could enforce complex access control. So instead, it relies on and utilizes standard file system permissions but there are some things to bear in mind.

To prevent any sensitive data from being accessible by unauthorized processes, it is imperative to always set correct permissions and owner for all YANG modules being installed. The utility sysrepoctl can help with both displaying all the permissions (--list) and modifying them (--change <module>) in addition to this functionality being available in the API.

Having made certain of this, the default configuration should be suitable for a reasonably secure machine that has no malicious running processes. Specifically, it is trivial for such a process to completely break sysrepo by writing into shared files that must be accessible for all the processes linked with sysrepo. Also, with some reverse engineering, it may even be possible to access data by an unathorized process when they are being communicated in these shared files.

In order to avoid all such security issues, there are 2 cmake variables SYSREPO_UMASK and SYSREPO_GROUP that should be adjusted. Generally, a new system group should be created and set for SYSREPO_GROUP and then all outside access frobidden by setting SYSREPO_UMASK to 00007. If then all the users executing sysrepo processes belong to this group, none of sysrepo files and no sensitive information should be accessible to other users.

Requirements

Build Requirements

• C compiler (gcc >= 4.8.4, clang >= 3.0, ...)
• cmake >= 2.8.12
• libyang
• tar(1)

Optional

• pkg-config & libsystemd (to support sysrepo-plugind systemd service)
• mongodb-org; libmongoc >= 1.24.0; libbson >= 1.24.0 (for MONGO DS datastore plugin)
• redis-stack-server; hiredis >= 1.1.0 (for REDIS DS datastore plugin)
• doxygen (for generating documentation)
• cmocka >= 1.0.1 (for tests only, see Tests)
• valgrind (for enhanced testing)
• gcov; lcov; genhtml (for code coverage)

Building

$ mkdir build; cd build
$ cmake ..
$ make
# make install

Plugin development documentation

Another markdown document aimed at plugin developers is available in plugin_dev_doc.md. The goal of the document is to provide a single place where a complete overview of information required to start developing plugins is available. The document describes the basics of Sysrepo plugin development and the technologies required to work with Sysrepo like YANG, XPath, NETCONF and others.

Printed context

The printed context is an optional sysrepo feature designed to optimize performance. When enabled, sysrepo generates a "printed" context, a snapshot of all loaded YANG schemas. Subsequent sysrepo processes can then share this context, saving time and memory by not having to create it individually.

This feature is enabled by default on modern Linux kernels (version 4.17 and newer). For older kernel versions, or for greater control, the memory address for the printed context can be manually specified during the build process using the -DPRINTED_CONTEXT_ADDRESS CMake option. All sysrepo processes need to map this shared context to the same memory address. This address is generated by default. If you configure it yourself, ensure it is page-aligned and in a memory region unlikely to conflict with normal process allocation (try to avoid the stack and the heap). On systems without MAP_FIXED_NOREPLACE, you should consider disabling Address Space Layout Randomization (ASLR) to help avoid overwriting existing memory mappings. A 0 value for this option will disable the feature.

Useful CMake sysrepo Options

Set custom repository path:

-DREPO_PATH=/opt/sysrepo/my_repository

Set page aligned address of the printed libyang context, set to 0 to disable printed context:

-DPRINTED_CONTEXT_ADDRESS=0x3ffe1b849000

Set custom sysrepo DS and NTF plugins path:

-DSR_PLUGINS_PATH=/opt/sysrepo/plugins

Set custom sysrepo-plugind plugins path:

-DSRPD_PLUGINS_PATH=/opt/sysrepo-plugind/plugins

Set global umask for all sysrepo file and directory creation:

-DSYSREPO_UMASK=00007

Set system group to own all sysrepo-related files:

-DSYSREPO_GROUP=sysrepo

Set systemd system service unit path:

-DSYSTEMD_UNIT_DIR=/usr/lib/systemd/system

Set NACM recovery username with unrestricted access:

-DNACM_RECOVERY_USER=root

Set NACM configuration data and 'sysrepo-monitoring' default permissions:

-DNACM_SRMON_DATA_PERM=000

Set startup and factory-default datastore data for internal modules (such as ietf-netconf-acm):

-DINTERNAL_MODULE_DATA_PATH=/etc/config/factory_default_config.xml

Useful CMake Build Options

Changing Compiler

Set CC variable:

$ CC=/usr/bin/clang cmake ..

Changing Install Path

To change the prefix where the library, headers and any other files are installed, set CMAKE_INSTALL_PREFIX variable:

$ cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..

Default prefix is /usr/local.

Build Modes

There are two build modes:

• Release. This generates library for the production use without any debug information.
• Debug. This generates library with the debug information and disables optimization of the code.

The Debug mode is currently used as the default one. to switch to the Release mode, enter at the command line:

$ cmake -D CMAKE_BUILD_TYPE:String="Release" ..

Code Coverage

Based on the tests run, it is possible to generate code coverage report. But it must be enabled and these commands are needed to gener